Bug#1067027: python-cryptography build-dependencies unsatisfiable.
On 17/03/2024 13:01, Jérémy Lal wrote: The last missing piece seems to be version >= 3 of https://tracker.debian.org/pkg/rust-pem I've uploaded this to experimental, please tell me when you are ready for it to be uploaded to unstable.
Bug#1066972: [Pkg-rust-maintainers] Bug#1066972: rust-python-pkginfo: FTBFS on mips64el: missing librust-rfc2047-decoder-0.2+default-dev
severity 1066972 important thanks Indeed, there is no librust-rfc2047-decoder-0.2+default-dev package. librust-rfc2047-decoder-0.2+default-dev is a virtual package provided by librust-rfc2047-decoder-dev which is built from the rust-rfc2047-decoder source package. Following the dependency chain, it looks like the root cause (or at least one of the root causes) is that the testsuite for rust-stacker is segfaulting on mips64el.
Bug#1066866: railway-gtk: FTBFS on i386 "type annotations needed"
Package: railway-gtk Version: 2.4.0-1 Severity: serious railway-gtk FTBFS on i386 (and will probablly FTBFS on other 32-bit architectures but builds on those architectures are currently blocked by the time64 transition). error[E0283]: type annotations needed for `std::option::Option` --> src/backend/journeys_result.rs:207:17 | 207 | let index = list | ^ ... 215 | if position <= index && index < position + n_items { | -- type must be known at this point | = note: multiple `impl`s satisfying `u32: PartialOrd<_>` found in the following crates: `core`, `glib`: - impl PartialOrd for u32; - impl PartialOrd for u32; help: consider giving `index` an explicit type, where the placeholders `_` are specified | 207 | let index: std::option::Option = list | Looking at the code, I'm pretty confident that the intended type was Option. The attached debdiff adds the annotation. I have tested that railway-gtk builds succesfully with this patch on both i386 and amd64.diff -Nru railway-gtk-2.4.0/debian/changelog railway-gtk-2.4.0/debian/changelog --- railway-gtk-2.4.0/debian/changelog 2024-03-04 13:13:51.0 + +++ railway-gtk-2.4.0/debian/changelog 2024-03-14 16:10:58.0 + @@ -1,3 +1,10 @@ +railway-gtk (2.4.0-1.1) UNRELEASED; urgency=medium + + * Non-maintainer upload. + * Fix FTBFS with "type annotation needed" error on i386. + + -- Peter Michael Green Thu, 14 Mar 2024 16:10:58 + + railway-gtk (2.4.0-1) unstable; urgency=medium * New upstream release diff -Nru railway-gtk-2.4.0/debian/patches/add-type-annotation.patch railway-gtk-2.4.0/debian/patches/add-type-annotation.patch --- railway-gtk-2.4.0/debian/patches/add-type-annotation.patch 1970-01-01 00:00:00.0 + +++ railway-gtk-2.4.0/debian/patches/add-type-annotation.patch 2024-03-14 16:10:58.0 + @@ -0,0 +1,13 @@ +Index: railway-gtk-2.4.0/src/backend/journeys_result.rs +=== +--- railway-gtk-2.4.0.orig/src/backend/journeys_result.rs railway-gtk-2.4.0/src/backend/journeys_result.rs +@@ -204,7 +204,7 @@ mod imp { + let list = self.journeys.borrow(); + let selection = self.selected.borrow(); + +-let index = list ++let index: Option = list + .iter() + .position(|j| { + j.refresh_token() == selection.as_ref().and_then(|j| j.refresh_token()) diff -Nru railway-gtk-2.4.0/debian/patches/series railway-gtk-2.4.0/debian/patches/series --- railway-gtk-2.4.0/debian/patches/series 2024-03-04 13:13:51.0 + +++ railway-gtk-2.4.0/debian/patches/series 2024-03-14 16:10:14.0 + @@ -1,3 +1,4 @@ relax-deps.diff disable-cargo-home-meson-build.diff build-set-project-name-to-railway-gtk.patch +add-type-annotation.patch
Bug#1066055: rust-symphonia-core: FTBFS on i386 units::tests::verify_timebase panic
rust-symphonia-core appears to FTBFS from an i386 sbuild chroot with a test 'units::tests::verify_timebase' panicking units::tests::verify_timebase stdout thread 'units::tests::verify_timebase' panicked at 'assertion failed: `(left == right)` left: `4503599627370496`, right: `4503599627370497`', src/units.rs:257:9 The code in question is. >assert_eq!( >tb1.calc_timestamp(Time::new(14_073_748_835_532, 0.803125)), >0x10___0001 >); Given the appearance of a floating point number in the test, this is almost certainly caused by a difference in floating point rounding behaviour on x87 (which is used by the Debian i386 port) compared to modern FPUs. On modern FPUs, values are rounded to their "storage format" after every operation. On x87 this is not the case, floating point values have more precision when stored in registers than when stored in memory. Usually this just results in calculations being slightly more accurate than they would be on a modern FPU, but it can become a problem if repeatability is more important than accuracy, or if algorithms are carefully designed to take account of rounding and then the rounding they expect does not happen. The questions this leaves are as follows. 1. Does this (and any other similar test failures) represent a significant behavioural difference that would render symphonia unwise to use on Debian i386? or does it just represent an overzealous test? This is something that should ideally be discussed with upstream, though I don't know if their response will be positive. 2. Is it worth expending effort on getting symphonia available on i386? to me that depends on what software is using or planning to use it. For a port in it's twilight years, keeping existing software working seems more important than making new software available.
Bug#1065677: rust-quick-xml: please upgrade to branch v0.31
preliminary analysis upstream changelog doesn't look too scary, no obvious breakage there. rdeps: 0123456789001234567890012345678900123456789001234567890012345678900123456789001234567890 oxigraph (librust-sparesults-dev): jonas package, upstream version in Debian uses 0.30, upstream did make code changes when updating dependency to allow 0.32 but they look fairly minor https://github.com/oxigraph/oxigraph/commit/ab5f5c1c6066df8ca528811322947e045f96e925 rust-bmap-parser: new upstream uses 0.31, but new upstream is semver breaking, upstream did not appear to make any code changes when bumping dep. rust-grcov: latest upstream release uses 0.29, debian currently has 0.29 and is relaxing dependency to allow any 0.x version. Upstream git uses 0.31 and didn't make rust-gsetings-macro: upstream version in Debian already depends on 0.31, Debian is currently downpatching rust-gtk4-macros upstream version in sid depends on 0.30, upstream version in experimental depends on 0.31, debian is currently downpatching. Upstream did not make any code changes when moving from 0.30 to 0.31. rust-gvdb upstream version in sid uses 0.31, debian is currently downpatching. rust-numbat-exchange-rates: upstream version in Debian already depends on 0.32, Debian is currently relaxing rust-plist upstream version in Debian already depends on 0.31, Debian is currently downpatching downpatch includes code changes. rust-quick-junit new upstream depends on 0.31 and is not semver breaking rust-reqsign new upstream depends on 0.31 and is not semver breaking rust-rio (librust-rio-xml-dev) jonas package - debian package is currently downpatching from 0.28 to 0.27 upstream git still uses 0.28 rust-wayland-scanner new upstream uses 0.31, but is semver breaking. Upstream did not appear to make any code changes when bumping dep. rust-xcb new upstream uses 0.30 and is not semver breaking. rust-zbus upstream version in sid uses 0.27, new upstream seems to have moved the quick-xml dependency to the zbus-xml crate. Upstream did not seem to make any code changes when bumping dep. Jonas, can you look at your packages (oxigraph and rust-rio) and prepare them for the new version of quick-xml? I uploaded the new version of quick-xml to experimental yesterday (though at the time of writing it still hasn't built on amd64)
Bug#1061618: src:haskell-misfortune: unsatisfied build dependency in testing: libghc-regex-pcre-doc
On 07/03/2024 19:43, Peter Green wrote: In raspbian, I removed the reference from misfortune.cabel, removed the build-dependencies on libghc-regex-pcre* and also (for unrelated reasons) removed the build-dependency on ghc-doc. After doing so I was able to successfully build the package. Scratch that, I thought the build had finished, but it hadn't. It did in fact fail. The reference in the code to PCRE was in all caps which is why my grep did not find it.
Bug#1061618: src:haskell-misfortune: unsatisfied build dependency in testing: libghc-regex-pcre-doc
Can you please investigate the situation and figure out how to resolve it? I'm no haskell expert, but to me the dependency looks vestigal. Grepping the source tree for "pcre" finds a mention in the misfortune.cabal file but no mentions in the actual code, and there are no corresponding binary dependencies. In raspbian, I removed the reference from misfortune.cabel, removed the build-dependencies on libghc-regex-pcre* and also (for unrelated reasons) removed the build-dependency on ghc-doc. After doing so I was able to successfully build the package.
Bug#1065587: rust-polling: Please try to rebuild rust-polling for loong64
I have built the rust-polling successfully in my local loong64 environment, without modifications required. Make sure you are not using DEB_BUILD_OPTIONS=nocheck since rust crates don't have stable ABIs and cargo doesn't support pre-built rust crates, librust* packages contain source code rather than binaries of any sort. The package build process does a test build to check that the code is actually buildable before packaging but this is skipped if DEB_BUILD_OPTIONS=nocheck is set. Please try to rebuild rust-polling for loong64 in the Debian Package Auto-Building environment. It failed again. I've taken a quick look at the code, but I'm not seeing anything obvious. The definitions in linux-raw-sys seem to exist, at least accoding to the error messages. I notice that the reexports of those definitions are gaurded behind a target_pointer_bits guard, it may be worth checking if rustc is setting that correctly on your architecture (though if it isn't, I'd expect that to cause a lot of problems)
Bug#1065459: rust-smol - upcoming rust-nix update.
Package: rust-smol I am currently preparing to update the rust-nix pacakge to version 0.27. The smol crate has a dev-dependency on the nix crate, which the Debian packaging translates to build and autopkgtest dependencies. After relaxing the dependencies to allow the new version. The new rust-nix package is available in experimental. A debdiff is attached.diff -Nru rust-smol-1.3.0/debian/changelog rust-smol-1.3.0/debian/changelog --- rust-smol-1.3.0/debian/changelog2024-02-01 19:28:09.0 + +++ rust-smol-1.3.0/debian/changelog2024-03-04 23:06:03.0 + @@ -1,3 +1,10 @@ +rust-smol (1.3.0-5.1) UNRELEASED; urgency=medium + + * Non-maintainer upload. + * Allow building with nix 0.27. + + -- Peter Michael Green Mon, 04 Mar 2024 23:06:03 + + rust-smol (1.3.0-5) unstable; urgency=medium * add patches 2001_async_* to accept older crates; diff -Nru rust-smol-1.3.0/debian/control rust-smol-1.3.0/debian/control --- rust-smol-1.3.0/debian/control 2024-02-01 19:14:29.0 + +++ rust-smol-1.3.0/debian/control 2024-03-04 23:06:00.0 + @@ -24,7 +24,7 @@ librust-hyper-0.14+stream-dev , librust-inotify-0-dev (<< 0.11) , librust-native-tls-0.2+default-dev , - librust-nix-0+default-dev (<< 0.27) , + librust-nix-0+default-dev (<< 0.28) , librust-nix-0+default-dev (>= 0.23) , librust-signal-hook-0.3+default-dev , librust-tempfile-3+default-dev , diff -Nru rust-smol-1.3.0/debian/patches/1001_nix.patch rust-smol-1.3.0/debian/patches/1001_nix.patch --- rust-smol-1.3.0/debian/patches/1001_nix.patch 2023-08-20 08:25:51.0 + +++ rust-smol-1.3.0/debian/patches/1001_nix.patch 2024-03-04 23:05:13.0 + @@ -10,7 +10,7 @@ [target.'cfg(target_os = "linux")'.dev-dependencies] inotify = { version = "0.10", default-features = false } -nix = "0.24" -+nix = ">= 0.24, < 0.27" ++nix = ">= 0.24, < 0.28" timerfd = "1" [target.'cfg(windows)'.dev-dependencies] diff -Nru rust-smol-1.3.0/debian/patches/2001_inotify.patch rust-smol-1.3.0/debian/patches/2001_inotify.patch --- rust-smol-1.3.0/debian/patches/2001_inotify.patch 2023-08-20 08:25:51.0 + +++ rust-smol-1.3.0/debian/patches/2001_inotify.patch 2024-03-04 23:05:51.0 + @@ -13,5 +13,5 @@ [target.'cfg(target_os = "linux")'.dev-dependencies] -inotify = { version = "0.10", default-features = false } +inotify = { version = ">= 0.9, < 0.11", default-features = false } - nix = ">= 0.24, < 0.27" + nix = ">= 0.24, < 0.28" timerfd = "1" diff -Nru rust-smol-1.3.0/debian/patches/2001_windows.patch rust-smol-1.3.0/debian/patches/2001_windows.patch --- rust-smol-1.3.0/debian/patches/2001_windows.patch 2023-08-20 08:25:51.0 + +++ rust-smol-1.3.0/debian/patches/2001_windows.patch 2024-03-04 23:05:33.0 + @@ -8,7 +8,7 @@ +++ b/Cargo.toml @@ -50,6 +50,3 @@ inotify = { version = "0.10", default-features = false } - nix = ">= 0.24, < 0.27" + nix = ">= 0.24, < 0.28" timerfd = "1" - -[target.'cfg(windows)'.dev-dependencies]
Bug#1064581: nsncd - upcoming rust-nix update.
Package: nsncd Version: 1.4.1-2 We are preparing an update of rust-nix to version 0.27, the new version has been uploaded to experlmental. In the new version of the nix crate, No features are enabled by default, you must enable the features you require. The attached patch relaxes the cargo dependency on nix to allow the new version and expliciltly enables the "fs" feature. A debdiff is attatched, if I get no response I will likely NMU this when the new rust-nix is uploaded to unstable. diff -Nru nsncd-1.4.1/debian/changelog nsncd-1.4.1/debian/changelog --- nsncd-1.4.1/debian/changelog2023-12-23 10:08:38.0 + +++ nsncd-1.4.1/debian/changelog2024-02-24 13:29:45.0 + @@ -1,3 +1,10 @@ +nsncd (1.4.1-2.1) UNRELEASED; urgency=medium + + * Non-maintainer upload. + * Relax cargo dependency on nix crate and explicitly enable "user" feature. + + -- Peter Michael Green Sat, 24 Feb 2024 13:29:45 + + nsncd (1.4.1-2) unstable; urgency=medium * debian: Delete README.source. diff -Nru nsncd-1.4.1/debian/patches/nix-0.27.patch nsncd-1.4.1/debian/patches/nix-0.27.patch --- nsncd-1.4.1/debian/patches/nix-0.27.patch 1970-01-01 00:00:00.0 + +++ nsncd-1.4.1/debian/patches/nix-0.27.patch 2024-02-24 13:28:08.0 + @@ -0,0 +1,13 @@ +Index: nsncd-1.4.1/Cargo.toml +=== +--- nsncd-1.4.1.orig/Cargo.toml nsncd-1.4.1/Cargo.toml +@@ -19,7 +19,7 @@ slog = "^2.5" + slog-async = "^2.7" + slog-term = "^2.6" + crossbeam-channel = "^0.5" +-nix = "^0.26" ++nix = { version = ">= 0.26", features = ["user"] } + num-derive = "^0.3" + num-traits = "^0.2" + sd-notify = "^0.4" diff -Nru nsncd-1.4.1/debian/patches/series nsncd-1.4.1/debian/patches/series --- nsncd-1.4.1/debian/patches/series 2023-12-23 10:08:38.0 + +++ nsncd-1.4.1/debian/patches/series 2024-02-24 13:24:37.0 + @@ -2,3 +2,4 @@ nsncd.service-load-nsncd-from-usrlibexec.patch nsncd.service-read-default-environmentfi.patch x-.gitignore-ignore-vim-swapfiles.patch +nix-0.27.patch
Bug#1064490: closed by Debian FTP Masters (reply to Andrej Shadura ) (Bug#1064490: fixed in inputplug 0.4.0-3)
reopen 1064490 thanks On 23/02/2024 10:21, Debian Bug Tracking System wrote: This is an automatic notification regarding your Bug report which was filed against the inputplug package: #1064490: inputplug - upcoming rust-nix and rust-x11rb updates. It has been closed by Debian FTP Masters (reply to Andrej Shadura ). Thanks for adopting the patches, however the package still build-depends on librust-x11rb-0.8+default-dev, so it can't currently be built with the rust-x11rb from experimental.
Bug#1064490: inputplug - upcoming rust-nix and rust-x11rb updates.
Package: inputplug Version: 0.4.0-2 We are preparing an update of rust-nix to version 0.27 and rust-x11rb to 0.13, the new versions are available in experimental. The new version of rustix does not seem to require any code changes, but it does require the "process" feature to be explicitly enabled. The new version of x11rb changed HierarchyInfo.flags from a u32 to a HierarchyMask. Heirachymask implements into, so I just added a conversion. A debdiff is attached, if I get no response I will probablly NMU this when I upload the new nix and x11rb packages to unstable. diff -Nru inputplug-0.4.0/debian/changelog inputplug-0.4.0/debian/changelog --- inputplug-0.4.0/debian/changelog2021-07-22 10:08:15.0 + +++ inputplug-0.4.0/debian/changelog2024-02-23 00:48:38.0 + @@ -1,3 +1,13 @@ +inputplug (0.4.0-2.1) UNRELEASED; urgency=medium + + * Non-maintainer upload. + * Explicitly enable the "process" feature in nix dependency (needed for nix 0.27) + * Use u32::from on info.flags, with x11rb 0.10 and lower, this is a no-op +because flags is already a u32. With x11rb 0.13 this will convert the flags +to a u32. + + -- Peter Michael Green Fri, 23 Feb 2024 00:48:38 + + inputplug (0.4.0-2) unstable; urgency=medium * Fix the copyright file. diff -Nru inputplug-0.4.0/debian/control inputplug-0.4.0/debian/control --- inputplug-0.4.0/debian/control 2021-07-22 10:08:15.0 + +++ inputplug-0.4.0/debian/control 2024-02-23 00:48:38.0 + @@ -14,7 +14,7 @@ librust-nix-0+default-dev (>= 0.19.0-~~), librust-pidfile-rs-0.1+default-dev, librust-structopt-0.3+default-dev, - librust-x11rb-0.8+default-dev, + librust-x11rb+default-dev (>= 0.8), pkgconf | pkg-config Standards-Version: 4.5.1 Homepage: https://github.com/andrewshadura/inputplug diff -Nru inputplug-0.4.0/debian/patches/nix-features.patch inputplug-0.4.0/debian/patches/nix-features.patch --- inputplug-0.4.0/debian/patches/nix-features.patch 1970-01-01 00:00:00.0 + +++ inputplug-0.4.0/debian/patches/nix-features.patch 2024-02-23 00:48:38.0 + @@ -0,0 +1,12 @@ +Index: inputplug-0.4.0/Cargo.toml +=== +--- inputplug-0.4.0.orig/Cargo.toml inputplug-0.4.0/Cargo.toml +@@ -23,6 +23,7 @@ version = "1.0" + + [dependencies.nix] + version = ">= 0.19, <1.0" ++features = ["process"] + + [dependencies.pidfile-rs] + version = "0.1" diff -Nru inputplug-0.4.0/debian/patches/series inputplug-0.4.0/debian/patches/series --- inputplug-0.4.0/debian/patches/series 1970-01-01 00:00:00.0 + +++ inputplug-0.4.0/debian/patches/series 2024-02-23 00:48:38.0 + @@ -0,0 +1,2 @@ +nix-features.patch +x11rb-0.13.patch diff -Nru inputplug-0.4.0/debian/patches/x11rb-0.13.patch inputplug-0.4.0/debian/patches/x11rb-0.13.patch --- inputplug-0.4.0/debian/patches/x11rb-0.13.patch 1970-01-01 00:00:00.0 + +++ inputplug-0.4.0/debian/patches/x11rb-0.13.patch 2024-02-23 00:48:38.0 + @@ -0,0 +1,26 @@ +Index: inputplug-0.4.0/Cargo.toml +=== +--- inputplug-0.4.0.orig/Cargo.toml inputplug-0.4.0/Cargo.toml +@@ -33,7 +34,7 @@ version = "0.3" + default-features = false + + [dependencies.x11rb] +-version = "0.8" ++version = ">= 0.8" + features = ["xinput"] + + [features] +Index: inputplug-0.4.0/src/main.rs +=== +--- inputplug-0.4.0.orig/src/main.rs inputplug-0.4.0/src/main.rs +@@ -222,7 +222,7 @@ fn main() -> Result<()> { + continue; + } + for info in hier_event.infos { +-let flags = IterableMask::from(info.flags) ++let flags = IterableMask::from(u32::from(info.flags)) + .map(|x| HierarchyMask::from(x as u8)) + .collect::>(); +
Bug#1064480: aardvark-dns - upcoming rust-nix update.
Package: greetd Version: 0.9.0-6 We are preparing an update of rust-nix to version 0.27, the new version has been uploaded to experlmental. To build with this new version of nix, aardvark-dns needs a small patch taken from upstream. A debdiff is attached, if I get no response I will likely NMU this once the new version of rust-nix is in unstable.diff -Nru greetd-0.9.0/debian/changelog greetd-0.9.0/debian/changelog --- greetd-0.9.0/debian/changelog 2023-12-21 14:17:58.0 + +++ greetd-0.9.0/debian/changelog 2024-02-22 22:50:17.0 + @@ -1,3 +1,11 @@ +greetd (0.9.0-6.1) UNRELEASED; urgency=medium + + * Non-maintainer upload. + * Add upstream patch for nix 0.27 + * Tighten build-dependency on nix. + + -- Peter Michael Green Thu, 22 Feb 2024 22:50:17 + + greetd (0.9.0-6) unstable; urgency=medium * Relax dependency on rpassword (Closes: #1057931). diff -Nru greetd-0.9.0/debian/control greetd-0.9.0/debian/control --- greetd-0.9.0/debian/control 2023-12-21 14:17:58.0 + +++ greetd-0.9.0/debian/control 2024-02-22 22:50:17.0 + @@ -6,7 +6,7 @@ debhelper-compat (= 13), dh-cargo, # greetd & greetd_ipc - librust-nix-dev (>= 0.25), + librust-nix-0.27-dev, librust-pam-sys-dev (>= 0.5.6), librust-users-dev (>= 0.11.0), librust-serde-derive-dev (>= 1.0), diff -Nru greetd-0.9.0/debian/patches/nix-0.27.patch greetd-0.9.0/debian/patches/nix-0.27.patch --- greetd-0.9.0/debian/patches/nix-0.27.patch 1970-01-01 00:00:00.0 + +++ greetd-0.9.0/debian/patches/nix-0.27.patch 2024-02-22 22:46:40.0 + @@ -0,0 +1,43 @@ +This patch is based on the upstream commit described below, adapted for use +in the Debian package by Peter Michael Green. + +commit 161218164d366482ab7fab9dcc59cbd40623ac2c +Author: Kenny Levinsen +Date: Wed Feb 7 15:14:24 2024 +0100 + +Update dependencies + +diff --git a/greetd/Cargo.toml b/greetd/Cargo.toml +index c206ac1..3b1446f 100644 +--- a/greetd/Cargo.toml b/greetd/Cargo.toml +@@ -14,1 +14,1 @@ repository = "https://git.sr.ht/~kennylevinsen/greetd/; +-nix = "0.26" ++nix = { version = "0.27", features = ["ioctl", "signal", "user", "fs", "mman"] } +diff --git a/greetd/src/main.rs b/greetd/src/main.rs +index b88c6dc..92a53d4 100644 +--- a/greetd/src/main.rs b/greetd/src/main.rs +@@ -22,7 +22,7 @@ use crate::{error::Error, session::worker}; + + async fn session_worker_main(config: config::Config) -> Result<(), Error> { + let raw_fd = config.internal.session_worker as RawFd; +-let mut cur_flags = unsafe { FdFlag::from_bits_unchecked(fcntl(raw_fd, FcntlArg::F_GETFD)?) }; ++let mut cur_flags = FdFlag::from_bits_retain(fcntl(raw_fd, FcntlArg::F_GETFD)?); + cur_flags.insert(FdFlag::FD_CLOEXEC); + fcntl(raw_fd, FcntlArg::F_SETFD(cur_flags))?; + let sock = unsafe { UnixDatagram::from_raw_fd(raw_fd) }; +diff --git a/greetd/src/session/interface.rs b/greetd/src/session/interface.rs +index f1d3f04..b31f47f 100644 +--- a/greetd/src/session/interface.rs b/greetd/src/session/interface.rs +@@ -99,8 +99,7 @@ impl Session { + UnixDatagram::pair().map_err(|e| format!("could not create pipe: {}", e))?; + + let raw_child = childfd.as_raw_fd(); +-let mut cur_flags = +-unsafe { FdFlag::from_bits_unchecked(fcntl(raw_child, FcntlArg::F_GETFD)?) }; ++let mut cur_flags = FdFlag::from_bits_retain(fcntl(raw_child, FcntlArg::F_GETFD)?); + cur_flags.remove(FdFlag::FD_CLOEXEC); + fcntl(raw_child, FcntlArg::F_SETFD(cur_flags))?; + diff -Nru greetd-0.9.0/debian/patches/relax_deps.patch greetd-0.9.0/debian/patches/relax_deps.patch --- greetd-0.9.0/debian/patches/relax_deps.patch2023-12-21 14:17:58.0 + +++ greetd-0.9.0/debian/patches/relax_deps.patch2024-02-22 22:48:38.0 + @@ -15,15 +15,4 @@ getopts = "0.2" enquote = "1.1" -nix = "0.26" -+nix = ">=0.26" a/greetd/Cargo.toml -+++ b/greetd/Cargo.toml -@@ -11,7 +11,7 @@ - debug = [] - - [dependencies] --nix = "0.26" -+nix = ">=0.26" - pam-sys = "0.5.6" - users = "0.11.0" - serde = { version = "1.0", features = ["derive"] } ++nix = ">= 0.26" diff -Nru greetd-0.9.0/debian/patches/series greetd-0.9.0/debian/patches/series --- greetd-0.9.0/debian/patches/series 2023-12-21 14:17:58.0 + +++ greetd-0.9.0/debian/patches/series 2024-02-22 22:46:06.0 + @@ -2,3 +2,4 @@ config_tweaks.patch relax_deps.patch rpassword_6.0_adaptation.patch +nix-0.27.patch
Bug#1064479: aardvark-dns - upcoming rust-nix update.
Package: aardvark-dns Version: 1.4.0-5 We are preparing an update of rust-nix to version 0.27, the new version has been uploaded to experlmental. To build with this new version of nix, aardvark-dns needs the cargo dependency on nix relaxing, and needs some features of the nix crate specifying explicitly. A debdiff is attatched, if I get no response I will likely NMU this when the new rust-nix is uploaded to unstable.diff -Nru aardvark-dns-1.4.0/debian/changelog aardvark-dns-1.4.0/debian/changelog --- aardvark-dns-1.4.0/debian/changelog 2023-09-07 00:45:48.0 + +++ aardvark-dns-1.4.0/debian/changelog 2024-02-22 22:11:17.0 + @@ -1,3 +1,11 @@ +aardvark-dns (1.4.0-5.1) UNRELEASED; urgency=medium + + * Non-maintainer upload. + * Relax cargo dependency on nix to support 0.27 and explicitly enable +required features, since nix no longer enables any features by default. + + -- Peter Michael Green Thu, 22 Feb 2024 22:11:17 + + aardvark-dns (1.4.0-5) unstable; urgency=medium * Build against clap version 4, Closes: #1040876, #1040877 diff -Nru aardvark-dns-1.4.0/debian/patches/update-dependencies.patch aardvark-dns-1.4.0/debian/patches/update-dependencies.patch --- aardvark-dns-1.4.0/debian/patches/update-dependencies.patch 2023-09-07 00:45:48.0 + +++ aardvark-dns-1.4.0/debian/patches/update-dependencies.patch 2024-02-22 22:10:55.0 + @@ -25,7 +25,7 @@ +async-broadcast = ">= 0.4.1" resolv-conf = "0.7.0" -nix = "0.25.0" -+nix = "0.26" ++nix = { version = ">= 0.25.0", features = ["fs", "signal"] } libc = "0.2" [build-dependencies]
Bug#1055092: hashbrown/indexmap status update
I've finally finished working through the rdeps of rust-hashbrown and rust-indexmap, damn that took a while. Hopefully we are not far off being ready to upload, mostly waiting for a response from jonas on the wasmtime bug at this point. btm: jonas package, no changes needed for this update, though currently FTBFS for unrelated reasons. loupe gnome team package, patch needs dropping, bug filed, Matthias has said he will deal with it. precious jonas package, package in unstable is ready for the hashbrown/indexmap update python-maturin python team package, bug filed with patch rust-ahash: joanas package, package in unstable is ready for the hashbrown/indexmap update rust-carapace-spec-clap: package in unstable is ready for the hashbrown/indexmap update rust-cargo fix prepared but not uploaded. rust-cbindgen package in unstable is ready for the hashbrown/indexmap update rust-chumsky update uploaded to experimental, autopkgtests currently skipped. rust-clap-3: package in unstable is ready for the hashbrown/indexmap update rust-configparser: package in unstable is ready for the hashbrown/indexmap update rust-cookie-store: package in unstable is ready for the hashbrown/indexmap update rust-dashmap update uploaded to experimental rust-elsa fix prepared but not uploaded. rust-gimli package in unstable is ready for the hashbrown/indexmap update rust-h2 fix uploaded to unstable rust-hashlink fix prepared in debcargo-conf but not uploaded. rust-imara-diff fix prepared in debcargo-conf but not uploaded. rust-laurel: package in unstable is ready for the hashbrown/indexmap update rust-lru: package in unstable is ready for the hashbrown/indexmap update rust-minijinja broken and not in testing. rust-no-std-compat fix prepared but not uploaded rust-object package in unstable is ready for the hashbrown/indexmap update rust-ordered-multimap: fix prepared in debcargo-conf but not uploaded. rust-petgraph package in unstable is ready for the hashbrown/indexmap update rust-publicsuffix package in unstable is ready for the hashbrown/indexmap update rust-plist fix prepared in debcargo-conf but not uploaded. rust-pyo3 package in unstable is ready for the hashbrown/indexmap update rust-pyproject-toml package in unstable is ready for the hashbrown/indexmap update rust-quick-junit fix prepared in debcargo-conf but not uploaded. rust-regalloc2 jonas package, package in unstable is ready for the hashbrown/indexmap update rust-rkyv package in unstable is ready for the hashbrown/indexmap update rust-ron fix prepared in debcargo-conf but not uploaded. rust-rowan fix prepared in debcargo-conf but not uploaded. rust-ruma-common fix prepared in debcargo-conf but not uploaded. rust-schemars fix uploaded to experimental rust-scraper broken and not in testing rust-sequoia-chameleon-gnupg fix prepared in debcargo-conf but not uploaded. rust-serde-json package in unstable is ready for the hashbrown/indexmap update rust-serde-with fix prepared in debcargo-conf but not uploaded. note: rust-serde-with-macros needs uploading at the same time. rust-serde-yaml package in unstable is ready for the hashbrown/indexmap update rust-sqlx-core package in unstable is ready for the hashbrown/indexmap update rust-tokio-util package in unstable is ready for the hashbrown/indexmap update rust-toml package in unstable is ready for the hashbrown/indexmap update rust-toml-0.5 package in unstable is ready for the hashbrown/indexmap update rust-toml-edit package in unstable is ready for the hashbrown/indexmap update rust-tre-command fix prepared in debcargo-conf but not uploaded. rust-tower fix prepared in debcargo-conf but not uploaded. rust-tree-sitter-cli package in unstable is ready for the hashbrown/indexmap update rust-unicode-linebreak package in unstable is ready for the hashbrown/indexmap update rust-wasmtime jonas package, bug filed.
Bug#1064014: dgit - unable to import dscs due to server issues.
On 15/02/2024 20:48, Ian Jackson wrote: Hrm. Can you point me to an example dsc (eg dgit.dsc?) and semd me the output with -D ? dget -d https://deb.debian.org/debian/pool/main/g/giada/giada_0.22.0-4.dsc mkdir dgittest cd dgittest/ git init dgit -D import-dsc ../giada_0.22.0-4.dsc +workingbranch | git rev-parse --show-toplevel => `/home/plugwash/dgittest' | git config -z --get-regexp --local '.*' | git config -z --get-regexp --local '.*' | git config -z --get-regexp --global '.*' | git config -z --get-regexp --system '.*' | git check-ref-format --normalize refs/heads/workingbranch => `refs/heads/workingbranch' | git symbolic-ref -q HEAD => `refs/heads/master' | git for-each-ref '--format=%(objectname)' '[r]efs/heads/workingbranch' => `' Dgit metadata in .dsc: specified git info (debian) dgit: import-dsc of .dsc with Dgit field, using git hash .dsc names distro debian: fetching rewrite map git_lrfetch_sane suppl=1 specs dgit-rewrite/map git_lrfetch_sane specre=(?:refs/dgit\-rewrite\/map) git_lrfetch_sane iteration 0 | git ls-remote -q --refs https://git.dgit.debian.org/giada refs/dgit-rewrite/map fatal: Could not read from remote repository. Please make sure you have the correct access rights and the repository exists. dgit: failed command: git ls-remote -q --refs https://git.dgit.debian.org/giada refs/dgit-rewrite/map dgit: error: subprocess failed with error exit status 128
Bug#1064015: rust-wasmtime - upcoming rust-hashbrown update.
Package: rust-wasmtime Now that rust-ahash 0.8 is in trixie and noble I hope to update rust-hashbrown and rust-indexmap soon to versions 0.14 and version 2 respectively. I have tested that simply relaxing the (build-)dependencies is enough to make rust-wasmtime build and pass it's autopkgtests with the new hashbrown. The debdiff I used for testing is attached. diff -Nru rust-wasmtime-16.0.0+dfsg/debian/changelog rust-wasmtime-16.0.0+dfsg/debian/changelog --- rust-wasmtime-16.0.0+dfsg/debian/changelog 2024-01-01 15:01:24.0 + +++ rust-wasmtime-16.0.0+dfsg/debian/changelog 2024-02-15 18:27:59.0 + @@ -1,3 +1,10 @@ +rust-wasmtime (16.0.0+dfsg-2.1) UNRELEASED; urgency=medium + + * Non-maintainer upload. + * Bump hashbrown dependencies to 0.14. + + -- Peter Michael Green Thu, 15 Feb 2024 18:27:59 + + rust-wasmtime (16.0.0+dfsg-2) unstable; urgency=medium * no-changes source-only upload to enable testing migration diff -Nru rust-wasmtime-16.0.0+dfsg/debian/control rust-wasmtime-16.0.0+dfsg/debian/control --- rust-wasmtime-16.0.0+dfsg/debian/control2023-12-30 16:07:22.0 + +++ rust-wasmtime-16.0.0+dfsg/debian/control2024-02-15 18:27:59.0 + @@ -13,8 +13,8 @@ librust-bumpalo-3+default-dev , librust-capstone-0.11+default-dev , librust-gimli-dev (<< 0.29) , - librust-hashbrown-0.12+default-dev , - librust-hashbrown-0.12+raw-dev , + librust-hashbrown-0.14+default-dev , + librust-hashbrown-0.14+raw-dev , librust-log-0.4-dev , librust-regalloc2-0.9+checker-dev , librust-regalloc2-0.9+default-dev , @@ -46,8 +46,8 @@ librust-capstone-0.11+default-dev, librust-codespan-reporting-0.11+default-dev, librust-gimli-dev (<< 0.29), - librust-hashbrown-0.12+default-dev, - librust-hashbrown-0.12+raw-dev, + librust-hashbrown-0.14+default-dev, + librust-hashbrown-0.14+raw-dev, librust-log-0.4-dev, librust-regalloc2-0.9+checker-dev, librust-regalloc2-0.9+default-dev,
Bug#1064014: dgit - unable to import dscs due to server issues.
Package: dgit Something seems to be wrong with the dgit infrastructure, I've been unable to import any dscs from Debian that include a dgit: header for a week or two now. I get messages like ['dgit', 'import-dsc', '/build/workingrepo/pool/main/g/giada/giada_0.22.0-4.dsc', '+workingbranch'] "my" variable $date masks earlier declaration in same scope at /usr/bin/dgit line 2188. Dgit metadata in .dsc: specified git info (debian) dgit: import-dsc of .dsc with Dgit field, using git hash .dsc names distro debian: fetching rewrite map fatal: Could not read from remote repository.
Bug#1063883: rust-regalloc2 - upcoming rust-hashbrown update.
Package: rust-regalloc2 Now that rust-ahash 0.8 is in trixie and noble I hope to update rust-hashbrown and rust-indexmap soon to versions 0.14 and version 2 respectively. The release of regalloc2 currently in Debian, depends on hashbrown 0.13 as does the latest upstream release. Upstream git has upgraded to 0.14, when they did so they decided to make some changes to the feature settings, setting "default_features=false" and manually enabling the "ahash" feature. https://github.com/bytecodealliance/regalloc2/commit/5d79e12d0a93b10fc181f4da409b4671dd365228 The default features for hashbrown are currently "ahash", "inline-more" and "allocator-api2" so this amounts to not enabling the "inline-more" and "allocator-api2" features. I have tested that simply relaxing the dependency is enough to make rust-regalloc2 build with the new hashbrown. The debdiff I used for testing is attached.diff -Nru rust-regalloc2-0.9.2/debian/changelog rust-regalloc2-0.9.2/debian/changelog --- rust-regalloc2-0.9.2/debian/changelog 2023-09-21 17:38:27.0 + +++ rust-regalloc2-0.9.2/debian/changelog 2024-02-14 02:21:52.0 + @@ -1,3 +1,10 @@ +rust-regalloc2 (0.9.2-2.1) UNRELEASED; urgency=medium + + * Non-maintainer upload. + * Bump hashbrown to 0.14 + + -- Peter Michael Green Wed, 14 Feb 2024 02:21:52 + + rust-regalloc2 (0.9.2-2) unstable; urgency=medium * generate documentation during build; diff -Nru rust-regalloc2-0.9.2/debian/control rust-regalloc2-0.9.2/debian/control --- rust-regalloc2-0.9.2/debian/control 2023-09-21 07:02:26.0 + +++ rust-regalloc2-0.9.2/debian/control 2024-02-14 02:21:52.0 + @@ -9,7 +9,7 @@ librust-bincode-1+default-dev, librust-clap-4+default-dev, librust-clap-4+derive-dev, - librust-hashbrown-0.12+default-dev, + librust-hashbrown-0.14+default-dev, librust-log-0.4-dev, librust-pretty-env-logger-0.5+default-dev, librust-rustc-hash-1-dev, @@ -30,7 +30,7 @@ Architecture: all Multi-Arch: foreign Depends: - librust-hashbrown-0.12+default-dev, + librust-hashbrown-0.14+default-dev, librust-log-0.4-dev, librust-rustc-hash-1-dev, librust-serde-1+alloc-dev, diff -Nru rust-regalloc2-0.9.2/debian/patches/2002_hashbrown.patch rust-regalloc2-0.9.2/debian/patches/2002_hashbrown.patch --- rust-regalloc2-0.9.2/debian/patches/2002_hashbrown.patch2023-09-19 17:10:38.0 + +++ rust-regalloc2-0.9.2/debian/patches/2002_hashbrown.patch2024-02-14 02:21:23.0 + @@ -12,7 +12,7 @@ rustc-hash = { version = "1.1.0", default-features = false } slice-group-by = { version = "0.3.0", default-features = false } -hashbrown = "0.13.2" -+hashbrown = ">= 0.12, < 0.14" ++hashbrown = ">= 0.12, < 0.15" # Optional serde support, enabled by feature below. serde = { version = "1.0.136", features = [
Bug#1063601: tailspin: FTBFS: error[E0407]: method `backtrace` is not a member of trait `Error`
reassign 1063601 tailspin 3.0.0+dfsg-1 retitle 1063601 tailspin FTBFS error: environment variable `CARGO_CHANNEL` not defined at compile time thanks >> [eyre 0.6.8] error[E0407]: method `backtrace` is not a member of trait `Error` >> [eyre 0.6.8] --> /<>/target/x86_64-unknown-linux-gnu/release/build/eyre-eb1eb971e427fb49/out/probe.rs:19:9 The above seems like a failure not in tailspin but in librust-eyre-dev. I don't think the errors Sebastian quoted are the cause of the build failure at all. I think they are just noise from a test compilation performed to determine what the compiler supports. Those same errors are present in the successful build log for tailspin 2.0.0 The actual error seems to be. error: environment variable `CARGO_CHANNEL` not defined at compile time --> tests/utils.rs:11:48 | 11 | PathBuf::from(format!("./target/{}/tspin", env!("CARGO_CHANNEL"))) |^ | = help: Cargo sets build script variables at run time. Use `std::env::var("CARGO_CHANNEL")` instead = note: this error originates in the macro `env` (in Nightly builds, run with -Z macro-backtrace for more info) I also notice the following earlier in the build log. "debian cargo wrapper: WARNING: falling back to simply calling upstream cargo, because CARGO_HOME does not end with debian/cargo_home:" This message appears in the failed logs for 3.0.0 but not in the succesful logs for 2.0.0. After serching for CARGO_CHANNEL I think may be the actual cause of the failure. All the results on codesearch.debian.net for CARGO_CHANNEL seem to relate to dh_cargo or your fork thereof. So I think these are probablly related.
Bug#1063475: RM: lazarus -- NVIU; Newer version is available
retitle 1063475 RM: lazarus 2.2.6+dfsg2-2 -- NVIU; Newer version is available lazarus| 2.2.6+dfsg2-2 | unstable | source, all lazarus| 3.0+dfsg1-7 | unstable | source, all To clarify, this is a request to remove the outdated lazarus packages that are still hanging around, not to remove lazarus completely. Looking at the cruft report it seems that the packages are still hanging round because some formerly arch all packages became arch specific and this is confusing dak's dependency checks.
Bug#1063357: rust-ahash - debian and cargo dependencies inconsistent.
Package: rust-ahash Version: 0.8.7-3 rust-ahash has a cargo dependency on const-random = { version = "0.1.17", optional = true } but the debian dependency is librust-const-random-0.1+default-dev (>= 0.1.12). This discrepancy is causing autopkgtest failures in Ubuntu. There is also a similar discrepancy with the once-cell dependency, this doesn't seem to be causing any actual problems but I figured it may as well be updated at the same time. a debdiff updating the Debian dependencies is attached.diff -Nru rust-ahash-0.8.7/debian/changelog rust-ahash-0.8.7/debian/changelog --- rust-ahash-0.8.7/debian/changelog 2024-02-01 20:50:15.0 + +++ rust-ahash-0.8.7/debian/changelog 2024-02-06 15:36:46.0 + @@ -1,3 +1,11 @@ +rust-ahash (0.8.7-3.1) UNRELEASED; urgency=medium + + * Non-maintainer upload. + * Update debian dependencies on rust-const-random and rust-once-cell crates +to match cargo dependencies. + + -- Peter Michael Green Tue, 06 Feb 2024 15:36:46 + + rust-ahash (0.8.7-3) unstable; urgency=medium * add patch cherry-picked upstream to fix test diff -Nru rust-ahash-0.8.7/debian/control rust-ahash-0.8.7/debian/control --- rust-ahash-0.8.7/debian/control 2024-01-18 21:07:25.0 + +++ rust-ahash-0.8.7/debian/control 2024-02-06 15:36:46.0 + @@ -6,7 +6,7 @@ dh-cargo (>= 25), librust-atomic-polyfill-1+default-dev , librust-cfg-if-1+default-dev , - librust-const-random-0.1+default-dev (>= 0.1.12) , + librust-const-random-0.1+default-dev (>= 0.1.17) , librust-criterion-0.3+default-dev , librust-criterion-0.3+html-reports-dev , librust-fnv-1+default-dev , @@ -15,7 +15,7 @@ librust-hashbrown-0.12+default-dev , librust-hex-0.4+default-dev (>= 0.4.2) , librust-no-panic-0.1+default-dev , - librust-once-cell-1+alloc-dev (>= 1.13.1) , + librust-once-cell-1+alloc-dev (>= 1.18.0) , librust-once-cell-1+atomic-polyfill-dev , librust-rand-0.8+default-dev , librust-seahash-4+default-dev , @@ -37,9 +37,9 @@ Depends: librust-atomic-polyfill-1+default-dev, librust-cfg-if-1+default-dev, - librust-const-random-0.1+default-dev (>= 0.1.12), + librust-const-random-0.1+default-dev (>= 0.1.17), librust-getrandom-0.2+default-dev (>= 0.2.7), - librust-once-cell-1+alloc-dev (>= 1.13.1), + librust-once-cell-1+alloc-dev (>= 1.18.0), librust-once-cell-1+atomic-polyfill-dev, librust-serde-1+default-dev (>= 1.0.117), librust-version-check-0.9+default-dev (>= 0.9.4),
Bug#1061669: rust-async-io: please upgrade to v2.2.1
Please upgrade to, or separately provide, at least v2.2.1. Hi jonas. I've uploaded this to experimental. In terms of uploads to unstable, This needs to be updated together together with at least polling (which James recently uploaded to experimental). A number of your packages will need either updates or patching to go together with this update. I prepared patches for some of them so I could use them for testing, but it may make more sense to update these crates to new upstream releases too. rdep list: rust-async-executor - Jonas package, build/test dependency only, not investigated. rust-async-global-executor - Rust team package, fix uploaded. rust-async-net - Jonas package, debdiff attached. rust-async-process - Jonas package, debdiff attached. rust-async-std - Jonas package, debdiff attached rust-if-watch - Jonas package, debian build/test dependencies allow the new version, cargo dependencies do not. rust-isahc - Jonas package, not investigated, not in testing. rust-smol - Jonas package, debdiff attatched. rust-zbus - Rust team package, upstream still uses 1.x not investigated further. rust-zbus-1 - old version of zbus, we will presumablly have to backport. rust-expectrl - Rust team package, still uses 1.x upstream. rust-netlink-sys - rust team package, I prepared a patch and it passes tests but would preffer to get upstream's feedback as it's quite intrustive. rust-prodash - rust team package, upstream seems to have updated. rust-quinn - rust team package, upstream still on 1.x, not investigated further rust-sqlx-core - rust team package, not in testing, still uses 1.x upstream. diff -Nru rust-smol-1.3.0/debian/changelog rust-smol-1.3.0/debian/changelog --- rust-smol-1.3.0/debian/changelog2023-08-20 08:26:43.0 + +++ rust-smol-1.3.0/debian/changelog2024-02-01 14:15:48.0 + @@ -1,3 +1,10 @@ +rust-smol (1.3.0-4.1) UNRELEASED; urgency=medium + + * Non-maintainer upload. + * Bump async-io dependency to 2. + + -- Peter Michael Green Thu, 01 Feb 2024 14:15:48 + + rust-smol (1.3.0-4) unstable; urgency=medium * drop patch 2002_async-io, obsoleted by Debian package updates diff -Nru rust-smol-1.3.0/debian/control rust-smol-1.3.0/debian/control --- rust-smol-1.3.0/debian/control 2023-02-03 09:29:58.0 + +++ rust-smol-1.3.0/debian/control 2024-02-01 14:15:48.0 + @@ -8,7 +8,7 @@ librust-async-channel-1+default-dev , librust-async-executor-1+default-dev (>= 1.5) , librust-async-fs-1+default-dev , - librust-async-io-1+default-dev (>= 1.11) , + librust-async-io-2+default-dev (>= 1.11) , librust-async-lock-2+default-dev , librust-async-net-1+default-dev , librust-async-process-1+default-dev (>= 1.6) , @@ -46,7 +46,7 @@ librust-async-channel-1+default-dev, librust-async-executor-1+default-dev (>= 1.5), librust-async-fs-1+default-dev, - librust-async-io-1+default-dev (>= 1.11), + librust-async-io-2+default-dev, librust-async-lock-2+default-dev, librust-async-net-1+default-dev, librust-async-process-1+default-dev (>= 1.6), diff -Nru rust-smol-1.3.0/debian/patches/2004-bump-async-io.patch rust-smol-1.3.0/debian/patches/2004-bump-async-io.patch --- rust-smol-1.3.0/debian/patches/2004-bump-async-io.patch 1970-01-01 00:00:00.0 + +++ rust-smol-1.3.0/debian/patches/2004-bump-async-io.patch 2024-02-01 14:15:48.0 + @@ -0,0 +1,14 @@ +Description: Bump async-io dependency to 2. +Author: Peter Michael Green + +--- rust-smol-1.3.0.orig/Cargo.toml rust-smol-1.3.0/Cargo.toml +@@ -21,7 +21,7 @@ autoexamples = false + async-channel = "1.4.2" + async-executor = "1.5.0" + async-fs = "1.3.0" +-async-io = "1.12.0" ++async-io = "2" + async-lock = "2.6.0" + async-net = "1.4.3" + async-process = "1.6.0" diff -Nru rust-smol-1.3.0/debian/patches/series rust-smol-1.3.0/debian/patches/series --- rust-smol-1.3.0/debian/patches/series 2023-08-13 12:03:01.0 + +++ rust-smol-1.3.0/debian/patches/series 2024-02-01 14:15:48.0 + @@ -3,3 +3,4 @@ 2002_inotify.patch 2002_tests.patch 2003_network.patch +2004-bump-async-io.patch diff -Nru rust-async-process-1.7.0/debian/changelog rust-async-process-1.7.0/debian/changelog --- rust-async-process-1.7.0/debian/changelog 2023-10-10 18:08:32.0 + +++ rust-async-process-1.7.0/debian/changelog 2024-02-01 14:27:49.0 + @@ -1,3 +1,10 @@ +rust-async-process (1.7.0-3.1) UNRELEASED; urgency=medium + + * Non-maintainer upload. + * Bump async-io to 2. + + -- Peter Michael Green Thu, 01 Feb 2024 14:27:49 + + rust-async-process (1.7.0-3) unstable; urgency=medium * add patch cherry-picked upstream diff -Nru rust-async-process-1.7.0/debian/control rust-async-process-1.7.0/debian/control --- rust-async-process-1.7.0/debian/control 2023-10-10 18:05:44.0 + +++ rust-async-process-1.7.0/debian/control 2024-02-01 14:27:43.0 + @@ -4,13 +4,13 @@ Build-Depends:
Bug#1061949: elan - upcoming rust-toml update.
Package: elan Version: 3.0.0-2 I hope to update the rust-toml package to version 0.8 soon. I have tested that elan builds with the dependency bumped. However, given https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1061550 I think it probably makes more sense for your package to switch back to using toml 0.5, as your upstream expects. toml 0.5 is maintained in a seperate source package and is unlikely to be going away any time soon. The debdiff for doing so is posted over in the other bug.
Bug#1061948: precious - upcoming rust-toml-update
Package: precious Version: 0.6.0-2 I plan to update rust-toml to 0.8 soon, to accommodate this, precious will need a patch dropping and an update to it's build-dependencies. Since this is moving closer to what upstream wants I see it as low risk. I have tested that the package builds succesfully with the changes in question. If you want to do further testing, the new version of toml is available in experimental. diff -Nru precious-0.6.0/debian/changelog precious-0.6.0/debian/changelog --- precious-0.6.0/debian/changelog 2023-12-19 20:56:31.0 + +++ precious-0.6.0/debian/changelog 2024-01-30 08:22:29.0 + @@ -1,3 +1,11 @@ +precious (0.6.0-2.1) UNRELEASED; urgency=medium + + * Non-maintainer upload. + * Bump toml build-dependency to use 0.8. + * Drop patch 2001_toml.patch + + -- Peter Michael Green Tue, 30 Jan 2024 08:22:29 + + precious (0.6.0-2) unstable; urgency=medium * drop patches 2001_anyhow 2001_rayon 2001_serde, diff -Nru precious-0.6.0/debian/control precious-0.6.0/debian/control --- precious-0.6.0/debian/control 2023-09-20 23:10:32.0 + +++ precious-0.6.0/debian/control 2024-01-30 08:22:29.0 + @@ -37,7 +37,7 @@ librust-tempfile-3+default-dev (>= 3.3) , librust-test-case-3+default-dev , librust-thiserror-1+default-dev (>= 1.0.37), - librust-toml-0.7+default-dev, + librust-toml-0.8+default-dev, librust-which+default-dev (<< 5), libstring-shellquote-perl, Standards-Version: 4.6.2 diff -Nru precious-0.6.0/debian/patches/2001_toml.patch precious-0.6.0/debian/patches/2001_toml.patch --- precious-0.6.0/debian/patches/2001_toml.patch 2023-12-19 20:56:31.0 + +++ precious-0.6.0/debian/patches/2001_toml.patch 1970-01-01 00:00:00.0 + @@ -1,18 +0,0 @@ -Description: accept older branch of crate toml -Author: Jonas Smedegaard -Bug-Debian: https://bugs.debian.org/1053955 -Forwarded: not-needed -Last-Update: 2023-12-19 -This patch header follows DEP-3: http://dep.debian.net/deps/dep3/ a/Cargo.toml -+++ b/Cargo.toml -@@ -52,7 +52,7 @@ - tempfile = "3.8.0" - test-case = "3.2.1" - thiserror = "1.0.49" --toml = "0.8.2" -+toml = ">= 0.7.6, <= 0.8.2" - which = ">= 3.0.0, < 5.0.0" - - [workspace] diff -Nru precious-0.6.0/debian/patches/series precious-0.6.0/debian/patches/series --- precious-0.6.0/debian/patches/series2023-11-28 23:56:05.0 + +++ precious-0.6.0/debian/patches/series2024-01-30 08:22:29.0 + @@ -1,4 +1,3 @@ 2001_comfy-table.patch 2001_indexmap.patch -2001_toml.patch 2002_privacy.patch
Bug#1061550: elan: creates invalid settings file on startup
It seems that the cause of this bug is probably the Debian patch that changes the version of the toml crate. There are breaking changes, so the toml functions used in elan need to be updated to reflect these changes. We have a rust-toml-0.5 package in Debian and you are welcome to use it, we have no immediate plans to get rid of it. toml 0.5 has more rdeps tha toml 0.7 at the moment and toml 0.7 is going to be replaced by 0.8 and probablly beyond before 0.5 goes away. And I just tested and confirmed that rebuilding with toml 0.5 makes this problem go away. A debdiff is attached.diff -Nru elan-3.0.0/debian/changelog elan-3.0.0/debian/changelog --- elan-3.0.0/debian/changelog 2024-01-12 07:48:39.0 + +++ elan-3.0.0/debian/changelog 2024-01-27 07:49:52.0 + @@ -1,3 +1,11 @@ +elan (3.0.0-2.1) UNRELEASED; urgency=medium + + * Non-maintainer upload. + * Switch back to using toml-0.5, toml-0.7 seems to cause incorrect config +generation (Closes: #1061550). + + -- Peter Michael Green Sat, 27 Jan 2024 07:49:52 + + elan (3.0.0-2) unstable; urgency=medium [ Peter Michael Green ] diff -Nru elan-3.0.0/debian/control elan-3.0.0/debian/control --- elan-3.0.0/debian/control 2024-01-12 07:34:29.0 + +++ elan-3.0.0/debian/control 2024-01-27 07:48:36.0 + @@ -21,7 +21,7 @@ librust-tempfile-dev, librust-term-0.7+default-dev, librust-time-dev, - librust-toml-0.7+default-dev (>= 0.7.6), + librust-toml-0.5+default-dev (>= 0.5.8), librust-url-dev, librust-wait-timeout-dev, librust-zip-dev, diff -Nru elan-3.0.0/debian/patches/0002-dependencies.patch elan-3.0.0/debian/patches/0002-dependencies.patch --- elan-3.0.0/debian/patches/0002-dependencies.patch 2024-01-12 07:34:29.0 + +++ elan-3.0.0/debian/patches/0002-dependencies.patch 2024-01-27 07:49:52.0 + @@ -13,7 +13,7 @@ index 6bf922e..def0d9f 100644 --- a/Cargo.toml +++ b/Cargo.toml -@@ -34,17 +34,17 @@ libc = "0.2.82" +@@ -34,13 +34,13 @@ libc = "0.2.82" markdown = "0.3.0" rand = "0.8.2" regex = "1.4.3" @@ -29,11 +29,6 @@ tempfile = "3.2.0" term = "0.7.0" time = "0.3.4" --toml = "0.5.8" -+toml = "0.7.6" - url = "2.2.0" - wait-timeout = "0.2.0" - zip = "0.6" @@ -52,11 +52,6 @@ tar = ">=0.4.36" flate2 = "1.0.14" json = "0.12.4" @@ -61,10 +56,9 @@ -zstd = "0.10" +zstd = "0.12.1" walkdir = "2.3.1" --toml = "0.5.8" + toml = "0.5.8" -sha2 = "0.9.3" -remove_dir_all = "0.8.0" -+toml = "0.7.6" +sha2 = "0.10.5" +remove_dir_all = "0.8.2" elan-utils = { path = "../elan-utils" } @@ -94,10 +88,9 @@ scopeguard = "1.1.0" -semver = "0.11.0" -sha2 = "0.9.3" --toml = "0.5.8" +semver = "0.9.0" +sha2 = "0.10.5" -+toml = "0.7.6" + toml = "0.5.8" url = "2.2.1" curl = "0.4.34" openssl = { version = "0.10", features = ["vendored"] }
Bug#1061374: rust-version-sync - upcoming rust-toml update.
On 23/01/2024 16:07, Jonas Smedegaard wrote: I have also searched to see if there are any reverse dependencies of said feature and did not find any (though it's possible that something is using the feature without declaring it). Virtual package librust-version-sync-0.9+default-dev, provided by librust-assert-json-diff-dev and built from src:rust-version-sync, is a reverse build-dependency of src:rust-assert-json-diff. Thanks for spotting my mistake, I had somehow failed to spot that markdown_deps_updated was in the default feature set. Anyway I just built and ran the autopkgtests for rust-assert-json-diff with the patched rust-version-sync and it passed fine. I also tested a bunch of other packages that have autopkgtest dependencies on rust-version-sync. I didn't find any regressions.
Bug#1059104: rust-toml: please upgrade to v0.8
preliminary analysis. rdeps of rust-toml-0.7: elan uses 0.5 upstream, can presumablly go back to 0.5 if going forward is not possible. precious uses 0.8 upstream, debian is currently downpatching rust-cargo uses 0.8 upstream, debian is currently some way behind upstream, but upstream did not make any code changes when bumping dep. rust-cargo-c uses 0.8 upstream, debian is currently some way behind upstream, but upstream did not make any code changes when bumping dep. rust-cargo-config2 latest upstream has moved from toml to toml-edit which will be updated as part of this task. Latest upstream tested and uploaded to experimental. rust-cargo-mutants uses 0.8 upstream, debian is currently some way behind upstream, but upstream did not make any code changes when bumping dep. rust-cargo-outdated still on 0.7 upstream, builds and tests ok with the new version, upstream issue opened (but I may still go ahead without them if they don't respond). https://github.com/kbknapp/cargo-outdated/issues/382 rust-debcargo still on 0.7 upstream, builds and tests ok with the new version, "upstream" issue opened. https://salsa.debian.org/rust-team/debcargo/-/issues/65 rust-ntpd allows versions 0.5 through 0.7 upstream. upstream issue opened, not in testing. Test situation seems no worst with dependency bumped I've filed an upstream issue but I probablly won't wait for this. https://github.com/pendulum-project/ntpd-rs/issues/1307 rust-parsec-service upstream uses 0.8, Debian is currently downpatching. rust-repro-env upstream uses 0.8, Debian is currently downpatching. rust-sniffglue upstream uses 0.8, Debian is currently downpatching. rust-system-deps upstream uses 0.8, Debian is currently downpatching. rust-tree-sitter-cli uses 0.5 upstream, build-time dependency only. can presumablly go back to 0.5 if going forward is not possible. rust-version-sync jonas package, still on 0.7 upstream, optional dependency that does not seem to be used by anything in Debian. rust-toml-edit reverse dependencies btm bumped to 0.21 in upstream git, upstream bumped with no code changes. jonas already acked update in https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1053955#17 python-maturin uses 0.21 upstream, debian package currently has no upper limit and builds succesfully with 0.21. No autopkgtests. rust-cargo uses 0.20 upstream, did not make any code changes when bumping from 0.19 to 0.20 rust-gst-plugin-version-helper uses 0.20 in latest upstream release. Upstream git uses 0.21, upstream dependency bump involved no code changes but did involve a feature change https://gitlab.freedesktop.org/gstreamer/gst-plugins-rs/-/commit/a8205d5b5d1178873ad0ba4d1cfa2c71ae922a3a rust-rstest-test uses 0.19 upstream, only used as a test crate for rust-rstest-*. builds and tests ok with dependency bumped. rust-trycmd upstream uses 0.21, dependency is already relaxed in Debian.
Bug#1061374: rust-version-sync - upcoming rust-toml update.
Package: rust-version-sync Tags: trixie, sid I hope to update rust-toml to 0.8 soon, probably in a week or so. The upstream changelog mentions the following under breaking changes Serialization and deserialization of tuple variants has changed from being an array to being a table with the key being the variant name and the value being the array toml is an optional (in the cargo sense) dependency of version-sync, it is used by the markdown_deps_updated feature. I have tested that rust-version-sync package builds and runs it's autopkgtests successfully with the new version of toml. I have also searched to see if there are any reverse dependencies of said feature and did not find any (though it's possible that something is using the feature without declaring it). If you would like to do further testing, then the new version of toml is available in experimental.
Bug#1061120: rust-ahash-0.7 autopkgtest failure
Package: rust-ahash-0.7 Version: 0.7.7-1 Severity: serious The autopkgtests for rust-ahash-0.7 are failing, this is blocking the migration of rust-ahash-0.7 to testing which is in turn blocking the migration of at least one rc bug fix to testing. There are two issues, the first is that the autopkgtests are trying to test a "runtime-rng" feature, but no such feature exists. My guess is that there was some confusion between versions of ahash. I removed the tests and the corresponding provides. The second issue is more subtle. The "atomic-polyfill" feature enables the dependency on the atomic-polyfill crate. However the dependency on the atomic-polyfill crate is disabled on linux (among many other targets). Disabling of a dependency on a target overrides enabling the dependency in a feature. However the code is not aware of this. The result is that building on Linux with the atomic-polyfill feature enabled fails. I see three possible routes for dealing with this. 1. Add target guards to the imports in the code, matching those in Cargo.toml 2. Remove the target restrictions from the atomic-polyfill dependency 3. Simply accept that the atomic-polyfill feature is broken on linux and stop testing it (this would also mean not having an "all features" test. My patch implements the first option but I don't have a strong preference for any of them. diff -Nru rust-ahash-0.7-0.7.7/debian/changelog rust-ahash-0.7-0.7.7/debian/changelog --- rust-ahash-0.7-0.7.7/debian/changelog 2023-12-30 10:22:55.0 + +++ rust-ahash-0.7-0.7.7/debian/changelog 2024-01-18 17:11:34.0 + @@ -1,3 +1,13 @@ +rust-ahash-0.7 (0.7.7-1.1) UNRELEASED; urgency=medium + + * Non-maintainer upload. + * Fix autopkgtests ++ Remove provides and autopkgtests for feature runtime-rng which does not + exist. ++ Only import atomic-polyfill on platforms where the dependency is enabled + + -- Peter Michael Green Thu, 18 Jan 2024 17:11:34 + + rust-ahash-0.7 (0.7.7-1) unstable; urgency=medium [ upstream ] diff -Nru rust-ahash-0.7-0.7.7/debian/control rust-ahash-0.7-0.7.7/debian/control --- rust-ahash-0.7-0.7.7/debian/control 2023-12-30 10:18:50.0 + +++ rust-ahash-0.7-0.7.7/debian/control 2024-01-18 17:11:27.0 + @@ -40,7 +40,6 @@ librust-ahash-0.7+atomic-polyfill-dev (= ${binary:Version}), librust-ahash-0.7+compile-time-rng-dev (= ${binary:Version}), librust-ahash-0.7+default-dev (= ${binary:Version}), - librust-ahash-0.7+runtime-rng-dev (= ${binary:Version}), librust-ahash-0.7+serde-dev (= ${binary:Version}), librust-ahash-0.7+std-dev (= ${binary:Version}), librust-ahash-0.7.7-dev (= ${binary:Version}), diff -Nru rust-ahash-0.7-0.7.7/debian/patches/1002_atomic_polyfill.patch rust-ahash-0.7-0.7.7/debian/patches/1002_atomic_polyfill.patch --- rust-ahash-0.7-0.7.7/debian/patches/1002_atomic_polyfill.patch 1970-01-01 00:00:00.0 + +++ rust-ahash-0.7-0.7.7/debian/patches/1002_atomic_polyfill.patch 2024-01-18 17:11:34.0 + @@ -0,0 +1,23 @@ +Description: limit atomic-polyfill import architectures + The atomic-polyfill dependency is target limited, but the import + is not. This leads to import errors when building with the + atomic-polyfill feature enabled (or building with --all-features). + + This patch makes the imports reflect the dependency +Author: Peter Michael Green +Last-Update: 2024-01-18 + +--- rust-ahash-0.7-0.7.7.orig/src/random_state.rs rust-ahash-0.7-0.7.7/src/random_state.rs +@@ -29,9 +29,9 @@ extern crate alloc; + #[cfg(feature = "std")] + extern crate std as alloc; + +-#[cfg(feature = "atomic-polyfill")] ++#[cfg(all(feature = "atomic-polyfill",not(any(target_os = "linux", target_os = "android", target_os = "windows", target_os = "macos", target_os = "ios", target_os = "freebsd", target_os = "openbsd", target_os = "netbsd", target_os = "dragonfly", target_os = "solaris", target_os = "illumos", target_os = "fuchsia", target_os = "redox", target_os = "cloudabi", target_os = "haiku", target_os = "vxworks", target_os = "emscripten", target_os = "wasi"] + use atomic_polyfill as atomic; +-#[cfg(not(feature = "atomic-polyfill"))] ++#[cfg(not(all(feature = "atomic-polyfill",not(any(target_os = "linux", target_os = "android", target_os = "windows", target_os = "macos", target_os = "ios", target_os = "freebsd", target_os = "openbsd", target_os = "netbsd", target_os = "dragonfly", target_os = "solaris", target_os = "illumos", target_os = "fuchsia", target_os = "redox", target_os = "cloudabi", target_os = "haiku", target_os = "vxworks", target_os = "emscripten", target_os = "wasi")] + use core::sync::atomic; + + use alloc::boxed::Box; diff -Nru rust-ahash-0.7-0.7.7/debian/patches/series rust-ahash-0.7-0.7.7/debian/patches/series --- rust-ahash-0.7-0.7.7/debian/patches/series 2023-12-30 09:53:32.0 + +++ rust-ahash-0.7-0.7.7/debian/patches/series 2024-01-18 17:11:34.0
Bug#1060824: tailspin - upcoming rust-terminal-size update.
Package: tailspin I intend to update rust-terminal-size in unstable to 0.3 soon (probablly a week or so). Tailspin upstream already uses 0.3, and your Cargo.toml already allows 0.3, so this should be a simple matter of tweaking the Debian build-dependency. I've tested that the package builds with the build-depenency tweaked, if you want to do further testing the new version of terminal-size has been uploaded to experimental.
Bug#1060762: oxigraph - upcoming rust-clap-lex update
Package: oxigraph I am currently working on updating rust-clap, clap itself is not semver breaking, but clap_lex is. The upstream changes seem fairly minimal and I was able to build your package successfully with the new version after adjusting the dependencies. The new versions of clap_lex and clap have been uploaded to experimental if you want to test further. I intend to upload them to unstable in a week or so. diff -Nru oxigraph-0.3.22/debian/changelog oxigraph-0.3.22/debian/changelog --- oxigraph-0.3.22/debian/changelog2023-12-30 12:11:38.0 + +++ oxigraph-0.3.22/debian/changelog2024-01-13 18:31:47.0 + @@ -1,3 +1,10 @@ +oxigraph (0.3.22-3.1) UNRELEASED; urgency=medium + + * Non-maintainer upload. + * Update for clap-lex 0.6 + + -- Peter Michael Green Sat, 13 Jan 2024 18:31:47 + + oxigraph (0.3.22-3) unstable; urgency=medium * tighten resolving binary package versions diff -Nru oxigraph-0.3.22/debian/control oxigraph-0.3.22/debian/control --- oxigraph-0.3.22/debian/control 2023-12-30 11:29:47.0 + +++ oxigraph-0.3.22/debian/control 2024-01-13 18:31:33.0 + @@ -15,7 +15,7 @@ librust-cc-1+parallel-dev , librust-clap-4+default-dev , librust-clap-4+derive-dev , - librust-clap-lex-0.5+default-dev , + librust-clap-lex-0.6+default-dev , librust-console-error-panic-hook-0.1+default-dev, librust-criterion-0.5+default-dev , librust-digest-0.10+default-dev, diff -Nru oxigraph-0.3.22/debian/patches/1001_clap.patch oxigraph-0.3.22/debian/patches/1001_clap.patch --- oxigraph-0.3.22/debian/patches/1001_clap.patch 2023-12-30 11:40:23.0 + +++ oxigraph-0.3.22/debian/patches/1001_clap.patch 2024-01-13 18:31:11.0 + @@ -1,6 +1,6 @@ Description: accept newer releases of crate clap and newer branches of crate clap_lex Author: Jonas Smedegaard -Last-Update: 2023-12-02 +Last-Update: 2024-01-13 by Peter Michael Green. --- This patch header follows DEP-3: http://dep.debian.net/deps/dep3/ --- a/server/Cargo.toml @@ -12,7 +12,7 @@ -clap = { version = "=4.0", features = ["derive"] } -clap_lex = "=0.3.0" +clap = { version = "4", features = ["derive"] } -+clap_lex = ">= 0.3, <= 0.5" ++clap_lex = ">= 0.3, <= 0.6" oxigraph = { version = "0.3.22", path = "../lib", features = ["http_client"] } sparesults = { version = "0.1.8", path = "../lib/sparesults", features = ["rdf-star"] } rand = "0.8"
Bug#1055092: rust-hashbrown: please upgrade to v0.14
preliminary analysis of reverse dependencies. btm upstream uses 0.14 debian is currently down-patching. rust-ahash dev dependency only, tests pass with dependency bumped. rust-chumsky new upstream uses 0.14 and is not semver breaking. rust-dashmap new upstream uses 0.14 and is not semver breaking. rust-hashlink new upstream uses 0.14 and is not semver breaking. rust-imara-diff upstream has bumped dependency to 0.14 in git but hasn't released yet no code changes were made with dependency bump. rust-indexmap new upstream uses 0.14 but new upstreram is semver breaking I think it makes most sense to do these two together. rust-lru new upstream uses 0.14 but new upstream is semver breaking, upstream made no code changes when bumping dependency, I think patching is the way to go here. I was able to get a successful test with the dependeny bumped. rust-ordered-multimap new upstream uses 0.14 but new upstream is semver breaking and has too high msrv. I think patching is the way to go here. Version in debian builds ok after bumping dependency. rust-regalloc2 jonas package upstream still on hashbrown 0.13 builds ok and tests pass after bumping dependency. rust-rkyv upstream has bumped in git, but not yet included in a release. builds ok and tests pass after bumping dependency note: building with --all-features fails for unrelated reasons. rust-unicode-linebreak new upstream has moved to shipping pre-generated tables, eliminating the dependency on hashbrown. version in Debian builds/tests ok with dependency bumped. rust-wasmtime (librust-cranelift-dev) jonas package version in unstable/experimental is broken. version in testing is rather old. hoping the release team will file a "fails to migrate to testing for too long" in the not to distant future. upstream version in unstable/experimental uses 0.14, downpatched in Debian upstream version in testing uses 0.13, downpatched in Debian.
Bug#1057451: rust-ahash: autopkgtests failing
tags 1057451 +patch thanks I just looked at the remaining autopkgtest failures in rust-ahash, I found and fixed two issues and after doing so the autopkgtests passed. The first issue was some arithmetic overflows in summations in tests/bench.rs these cause panics if built/run in Debug mode (as "cargo test --all-targets" does by default). The results of the summations were not used for anything. I'm not sure what the original intent of the summations was, perhaps it was just to shut compiler warnings up, perhaps it was an attempt to stop the compiler optimizing stuff away. I just commented out the summations, another possibility would be to replace them with calls to std::hint::black_box The second issue was some tests that failed to build when the std feature was enabled but none of the rng features (runtime-rng, compile-time-rng or no-rng) were enabled. I added/adjusted feature gaurds to fix this issue. Debdiff attached, if I get no response I will likely NMU this in a week or so.diff -Nru rust-ahash-0.8.5/debian/changelog rust-ahash-0.8.5/debian/changelog --- rust-ahash-0.8.5/debian/changelog 2023-12-10 23:06:48.0 + +++ rust-ahash-0.8.5/debian/changelog 2023-12-26 10:08:52.0 + @@ -1,3 +1,13 @@ +rust-ahash (0.8.5-3.1) UNRELEASED; urgency=medium + + * Non-maintainer upload. + * Fix autopkgtest. (Closes: #1057451) ++ Disable overflowing additions whose results are not used in tests/bench.rs ++ Add/Adjust feature gaurds to fix build of tests when the std feature is + enabled but no rng feature is enabled. + + -- Peter Michael Green Tue, 26 Dec 2023 10:08:52 + + rust-ahash (0.8.5-3) unstable; urgency=medium * update patch; diff -Nru rust-ahash-0.8.5/debian/patches/1001_bench_overflow.patch rust-ahash-0.8.5/debian/patches/1001_bench_overflow.patch --- rust-ahash-0.8.5/debian/patches/1001_bench_overflow.patch 1970-01-01 00:00:00.0 + +++ rust-ahash-0.8.5/debian/patches/1001_bench_overflow.patch 2023-12-26 10:08:52.0 + @@ -0,0 +1,84 @@ +Description: Disable overflowing additions whose results are not used in tests/bench.rs +Author: Peter Michael Green +Bug-Debian: https://bugs.debian.org/1057451 + +--- rust-ahash-0.8.5.orig/tests/bench.rs rust-ahash-0.8.5/tests/bench.rs +@@ -118,10 +118,10 @@ fn bench_map(c: Criterion) { + group.bench_function("aHash-alias", |b| { + b.iter(|| { + let hm: ahash::HashMap = (0..1_000_000).map(|i| (i, i)).collect(); +-let mut sum = 0; ++//let mut sum = 0; + for i in 0..1_000_000 { + if let Some(x) = hm.get() { +-sum += x; ++//sum += x; + } + } + }) +@@ -129,10 +129,10 @@ fn bench_map(c: Criterion) { + group.bench_function("aHash-hashBrown", |b| { + b.iter(|| { + let hm: hashbrown::HashMap = (0..1_000_000).map(|i| (i, i)).collect(); +-let mut sum = 0; ++//let mut sum = 0; + for i in 0..1_000_000 { + if let Some(x) = hm.get() { +-sum += x; ++//sum += x; + } + } + }) +@@ -140,10 +140,10 @@ fn bench_map(c: Criterion) { + group.bench_function("aHash-hashBrown-explicit", |b| { + b.iter(|| { + let hm: hashbrown::HashMap = (0..1_000_000).map(|i| (i, i)).collect(); +-let mut sum = 0; ++//let mut sum = 0; + for i in 0..1_000_000 { + if let Some(x) = hm.get() { +-sum += x; ++//sum += x; + } + } + }) +@@ -151,10 +151,10 @@ fn bench_map(c: Criterion) { + group.bench_function("aHash-wrapper", |b| { + b.iter(|| { + let hm: ahash::AHashMap = (0..1_000_000).map(|i| (i, i)).collect(); +-let mut sum = 0; ++//let mut sum = 0; + for i in 0..1_000_000 { + if let Some(x) = hm.get() { +-sum += x; ++//sum += x; + } + } + }) +@@ -162,10 +162,10 @@ fn bench_map(c: Criterion) { + group.bench_function("aHash-rand", |b| { + b.iter(|| { + let hm: std::collections::HashMap = (0..1_000_000).map(|i| (i, i)).collect(); +-let mut sum = 0; ++//let mut sum = 0; + for i in 0..1_000_000 { + if let Some(x) = hm.get() { +-sum += x; ++//sum += x; + } + } + }) +@@ -174,10 +174,10 @@ fn bench_map(c: Criterion) { + b.iter(||
Bug#1059034: Impossible to install: Depends on missing package,librust-ego-tree-0.6+default-dev
Impossible to install: Depends on missing package librust-ego-tree-0.6+default-dev rust-ego-tree was uploaded but rejected. https://alioth-lists.debian.net/pipermail/pkg-rust-maintainers/2023-December/037170.html
Bug#1051521: rust-palette: autopkgtest failures
tags 105121 +patch thanks rust-palette is unable to migrate to Testing because its autopkgtests are failing. I prepared a fix for the autopkgtest issues. While I was at it I also bumped the clap dev-dependency and the associated build and test dependencies to version 4 as we would like to phase out clap version 3. I discussed the clap upgrade with upstream, they said it was only used for examples but they did not want to bump it upstream at this time due to msrv. https://github.com/Ogeon/palette/issues/364 If I get no response I will likely NMU this in a week or so.
Bug#1059019: rm: librust-bindgen+clap-dev librust-bindgen+default-dev librust-bindgen+env-logger-dev librust-bindgen+log-dev librust-bindgen+logging-dev librust-bindgen+runtime-dev librust-bindgen+sta
Package: ftp.debian.org Please remove the binary packages librust-bindgen+clap-dev librust-bindgen+default-dev librust-bindgen+env-logger-dev librust-bindgen+log-dev librust-bindgen+logging-dev librust-bindgen+runtime-dev librust-bindgen+static-dev librust-bindgen+which-dev These packages have been converted from physical packages to virtual packages. The cruft report claims that various packages will have their dependencies and/or build-dependencies broken, but this is because the dependency analysis used in the cruft report does not take into account virtual packages. dak rm -o -m "[auto-cruft] NBS (no longer built by rust-bindgen)" -s unstable -a amd64,arm64,armel,armhf,i386,mips64el,ppc64el,riscv64,s390x -p -R -b librust-bindgen+clap-dev librust-bindgen+default-dev librust-bindgen+env-logger-dev librust-bindgen+log-dev librust-bindgen+logging-dev librust-bindgen+runtime-dev librust-bindgen+static-dev librust-bindgen+which-dev
Bug#1059009: hime: build-depends on dropped package.
Package: hime Version: 0.9.11+dfsg-2 Severity: serious Tags: trixie, sid Justification: rc-policy - packages must be buildable within the same release. User: debian...@lists.debian.org Usertags: edos-uninstallable Hime build-depends on libayatana-indicator-dev which is no longer built by the libayatana-indicator source package. It is still present in unstable as a cruft package but is gone from testing on most architectures meaning your package cannot be built on most architectures in testing.
Bug#1057760: settle - upcoming rust-rusqlite update.
severity 1057760 serious tags 1057760 +ftbfs thanks On 09/12/2023 08:06, Jonas Smedegaard wrote: Quoting Peter Green (2023-12-08 04:09:31) Package: settle Version: 0.40.1-1 I intend to update rust-rusqlite in unstable to 0.29 soon. The cargo dependencies for settle already allow 0.29 but the Debian dependencies will need updating. I don't expect any issues as 0.29 is what upstream asks for and I already tested this a while ago but I'm filing this bug report to give you a heads up if you want to do any further testing. Thanks. Appreciated! Please just go ahead with the upgrade, Done.
Bug#1058074: rust-hyper-rustls - autopkgtest failure
Package: rust-hyper-rustls Version: 0.24.2-1 Severity: serious Tags: patch The autopkgtest for rust-hyper-rustls is failing, because the code in test_alpn_http2 requires a runtime, but the feature requirements for the test do not specify one. A debdiff fixing this is attatched.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 2023-12-02 20:25:28.0 + +++ rust-hyper-rustls-0.24.2/debian/changelog 2023-12-12 01:18:39.0 + @@ -1,3 +1,11 @@ +rust-hyper-rustls (0.24.2-1.1) UNRELEASED; urgency=medium + + * Non-maintainer upload. + * Fix feature requirements for test_alpn_http to prevent autopkgtest +failure. + + -- Peter Michael Green Tue, 12 Dec 2023 01:18:39 + + rust-hyper-rustls (0.24.2-1) unstable; urgency=medium * unfuzz patches diff -Nru rust-hyper-rustls-0.24.2/debian/patches/1002_test-requires-runtime.patch rust-hyper-rustls-0.24.2/debian/patches/1002_test-requires-runtime.patch --- rust-hyper-rustls-0.24.2/debian/patches/1002_test-requires-runtime.patch 1970-01-01 00:00:00.0 + +++ rust-hyper-rustls-0.24.2/debian/patches/1002_test-requires-runtime.patch 2023-12-12 01:18:17.0 + @@ -0,0 +1,20 @@ +Description: tests_alpn_http2 fails to build if no runtime is enabled + Add feature guards so it doesn't cause autopkgtest failure. +Author: Peter Michael Green +Last-Update: 2023-12-12 +--- +This patch header follows DEP-3: http://dep.debian.net/deps/dep3/ + +Index: rust-hyper-rustls-0.24.2/src/connector/builder.rs +=== +--- rust-hyper-rustls-0.24.2.orig/src/connector/builder.rs rust-hyper-rustls-0.24.2/src/connector/builder.rs +@@ -353,7 +353,7 @@ mod tests { + } + + #[test] +-#[cfg(all(not(feature = "http1"), feature = "http2"))] ++#[cfg(all(not(feature = "http1"), feature = "http2", any(feature = "native-tokio", feature = "tokio-runtime")))] + fn test_alpn_http2() { + let roots = rustls::RootCertStore::empty(); + let tls_config = rustls::ClientConfig::builder() diff -Nru rust-hyper-rustls-0.24.2/debian/patches/series rust-hyper-rustls-0.24.2/debian/patches/series --- rust-hyper-rustls-0.24.2/debian/patches/series 2022-12-06 11:57:28.0 + +++ rust-hyper-rustls-0.24.2/debian/patches/series 2023-12-12 01:16:36.0 + @@ -1,3 +1,4 @@ 1001_http1.patch +1002_test-requires-runtime.patch 2001_webpki-roots.patch 2004_tests_broken.patch
Bug#1057760: settle - upcoming rust-rusqlite update.
Package: settle Version: 0.40.1-1 I intend to update rust-rusqlite in unstable to 0.29 soon. The cargo dependencies for settle already allow 0.29 but the Debian dependencies will need updating. I don't expect any issues as 0.29 is what upstream asks for and I already tested this a while ago but I'm filing this bug report to give you a heads up if you want to do any further testing.
Bug#1054156: librust-env-logger-0.7+default-dev shouldn't provide librust-env-logger+default-dev
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.
Bug#1057673: safe-vdash - mismatch between Debian and Cargo dependencies
Package: safe-vdash Version: 0.15.5-1 Your Debian and Cargo dependencies on env-logger are not consistent with each other. > debian/control: librust-env-logger-0.7+default-dev > Cargo.toml:env_logger = "0.10.0" Your package built successfully because the new version of env-logger was pulled in indirectly, but please fix the Debian dependency to match the Cargo one in the next upload.
Bug#1053800: transition: libgit2
The Rust Team did not react. Too bad. Please raise the bug to RC. Apologies for not engaging with this sooner, I had mentally filed it as "deal with this once the cargo update is done" but the cargo update has been taking a lot longer than hoped. I've uploaded a new version of the rust bindings, this also involved updating a bunch of other rust packages for the new version of the rust bindings. Going through the packages on the transition tracker. that currently show red x's on architectures other than mips64el and that have something to do with rust. git-delta (sid only): Maintained by Jonas. Will need a sourcefull upload for semver bumps, I will file a bug once the packages it depends on are built. rust-bat: I've uploaded a fixed package. rust-cargo-c: Uses the rust git bindings indirectly, a binnmu should suffice here. rust-cargo-outdated: Doesn't enforce an upper limit on the version of the git bindings, a binnmu should suffice here. rust-debcargo: I've uploaded a fixed package. rust-exa: I've Uploaded a fixed package. rust-ripasso-cursive: Suffers from unrelated FTBFS issue. cargo: f_g has uploaded a fix.
Bug#1057198: rust-wasmtime: FTBFS error[E0599]: no function or associated item named `from_str` found for struct `Triple` in the current scope
Package: rust-wasmtime Version: 15.0.0+dfsg-3 Severity: serious Control: block 1055090 by -1 https://buildd.debian.org/status/fetch.php?pkg=rust-wasmtime=all=15.0.0%2Bdfsg-3=1701097543=0 error[E0599]: no function or associated item named `from_str` found for struct `Triple` in the current scope --> cranelift/codegen/src/isa/mod.rs:118:12 | 118 | lookup(triple!(name)) |^ function or associated item not found in `Triple` | = help: items from traits can only be used if the trait is in scope = note: this error originates in the macro `triple` (in Nightly builds, run with -Z macro-backtrace for more info) help: the following trait is implemented but not in scope; perhaps add a `use` for it: | 46 + use core::str::FromStr; | For more information about this error, try `rustc --explain E0599`. The following warnings were emitted during compilation:
Bug#1055364: rust-rayon: please update to v1.8.0
Please update to (at least) newer upstream release v1.8.0. I just looked at this, the new version of rayon requires a new version of rayon-core, unfortunately when updating rayon-core I ran into a test failure that looks like it may indicate an unintentional API break. I'm not comfortable uploading this until I get feedback from upstream.
Bug#1055099: rust-async-task: Failing autopkgtests
On 21/11/2023 11:41, Jonas Smedegaard wrote: Quoting Peter Green (2023-11-21 09:16:21) Tags 1055099 +patch thanks The autopkgtests for rust-async-task began failing after the upgrade to from 4.4.1-1 to 4.5.0-1. This prevents its migration to Testing. I have prepared a patch which adds a feature guard to the example in question and hence fixes the autopkgtest. A debdiff is attatched, if I get no response I intend to NMU this soon. Thanks. Seems the intended attachment is missing, however. Sorry, attatched now. diff -Nru rust-async-task-4.5.0/debian/changelog rust-async-task-4.5.0/debian/changelog --- rust-async-task-4.5.0/debian/changelog 2023-10-19 12:46:47.0 + +++ rust-async-task-4.5.0/debian/changelog 2023-11-21 08:05:37.0 + @@ -1,3 +1,10 @@ +rust-async-task (4.5.0-1.1) UNRELEASED; urgency=medium + + * Non-maintainer upload. + * Add patch 1001 to add feature requirement to example (Closes: #1055099) + + -- Peter Micheal Green Tue, 21 Nov 2023 08:05:37 + + rust-async-task (4.5.0-1) unstable; urgency=medium [ upstream ] diff -Nru rust-async-task-4.5.0/debian/patches/1001_example_feature_requirements.patch rust-async-task-4.5.0/debian/patches/1001_example_feature_requirements.patch --- rust-async-task-4.5.0/debian/patches/1001_example_feature_requirements.patch 1970-01-01 00:00:00.0 + +++ rust-async-task-4.5.0/debian/patches/1001_example_feature_requirements.patch 2023-11-21 08:05:31.0 + @@ -0,0 +1,16 @@ +Description: add feature requirement for example + Avoids build failure in autopkgtest. +Author: Peter Micahel Green +Forwarded: no +Last-Update: 2023-11-21 +--- +This patch header follows DEP-3: http://dep.debian.net/deps/dep3/ +Index: rust-async-task-4.5.0/examples/spawn-local.rs +=== +--- rust-async-task-4.5.0.orig/examples/spawn-local.rs rust-async-task-4.5.0/examples/spawn-local.rs +@@ -1,3 +1,4 @@ ++#![cfg(feature = "std")] + //! A simple single-threaded executor that can spawn non-`Send` futures. + + use std::cell::Cell; diff -Nru rust-async-task-4.5.0/debian/patches/series rust-async-task-4.5.0/debian/patches/series --- rust-async-task-4.5.0/debian/patches/series 2023-10-10 17:25:47.0 + +++ rust-async-task-4.5.0/debian/patches/series 2023-11-21 08:05:37.0 + @@ -1 +1,2 @@ +1001_example_feature_requirements.patch 2001_flaky-test.patch
Bug#1055099: rust-async-task: Failing autopkgtests
Tags 1055099 +patch thanks The autopkgtests for rust-async-task began failing after the upgrade to from 4.4.1-1 to 4.5.0-1. This prevents its migration to Testing. I have prepared a patch which adds a feature guard to the example in question and hence fixes the autopkgtest. A debdiff is attatched, if I get no response I intend to NMU this soon.
Bug#1053955: rust-toml: please update to v0.7.8
On 16/11/2023 18:41, Jonas Smedegaard wrote: Quoting Peter Green (2023-11-16 10:55:33) Please update to (at least) newer upstream release v0.7.8. toml itself is not semver-breaking, but it's closely coupled dependency toml_edit is. [...] My overall conclusion is that btm is the main blocker. Jonas, btm is one of your packages, can you work with upstream to prepare and test an update? Updated versions of toml_edit and toml are availble in experimental for you to test with. Please go ahead without waiting for btm: Upstream has swiftly responded with an uncomplicated change. Sorry I screwed up with my earlier analysis. I mixed up toml 0.7.8 with toml 0.8.8. Only the latter requires the new toml_edit. So it seems I won't be semver bumping toml_edit at this time after all.
Bug#1053955: rust-toml: please update to v0.7.8
Please update to (at least) newer upstream release v0.7.8. toml itself is not semver-breaking, but it's closely coupled dependency toml_edit is. Relavent parts of the upstream changelog. 0.21.0 - 2023-11-06 Breaking Change Split default-features=false APIs into parse and display features 0.20.0 - 2023-09-13 Compatibility Serialization and deserialization of tuple variants has changed from being an array to being a table with the key being the variant name and the value being the array 0.20->0.21 looks low risk to me, but 0.19->0.20 looks potentially riskier. With that in mind lets look at the reverse dependencies. btm - still on 0.19 upstream. python-maturin - uses 0.21 upstream, did not make any code changes when bumping from 0.19 to 0.21, already broken and not in testing. rust-cargo - uses 0.20 upstream, did not make any code changes when bumping from 0.19 to 0.20 rust-rstest-test - uses 0.19 upstream, not in testing, no rdeps rust-trycmd - uses 0.20 upstream My overall conclusion is that btm is the main blocker. Jonas, btm is one of your packages, can you work with upstream to prepare and test an update? Updated versions of toml_edit and toml are availble in experimental for you to test with.
Bug#1055895: [Pkg-rust-maintainers] Bug#1055895: rust-self-cell: RUSTSEC-2023-0070
Please see https://rustsec.org/advisories/RUSTSEC-2023-0070.html I have read the upstream advisory and the linked bug report and while I don't fully understand the nitty gritty details my understanding of the issue is. * It was discovered that code (which was not marked as unsafe) could mis-use self-cell in a way that invoked undefined behaviour. * This was fixed by adding an additional compile time check which will cause the build to fail in such cases. Based on this understanding I have * Uploaded the new version of rust-self-cell * Performed a rebuild test of the only reverse dependency rust-coreutils, it built successfully, so presumably it is not impacted by this issue.
Bug#1042386: Please upgrade to or separately provide newer upstream branch v0.10.
On 09/08/2023 11:30, Jonas Smedegaard wrote: Quoting Peter Green (2023-08-09 10:55:07) 2. hashbrown has moved to ahash 0.8, ahash 0.8 is available in unstable, but is not in testing due to autopkgtest failures. Jonas, since ahash is one of your packages can you investigate and deal with these. Thanks for nudging. rust-ahash should be fixed now. Unfortuntaly the "fix" upload FTBFS. Any ETA on a fix? do you need help fixing it?
Bug#1053953: rust-indexmap: please upgrade to v2
preliminary analysis. upstream changelog: https://github.com/bluss/indexmap/blob/master/RELEASES.md nothing looks two scary forward dependencies: the new version of indexmap depends on the new version of hasbrown, and my attempts at relaxing have been unsuccesful, so it looks like we will need to do hashbrown first. reverse dependencies: The reverse dependency situation looks pretty good in general, details of individual packages below. btm - jonas package, already uses 2.x upstream. precious - jonas package, already uses 2.x upstream. python-maturin - non rust team package, has not bumped dependency upstream already rc buggy and not in testing rust-carapace-spec-clap - already uses 2.x upstream, debian package has dependency with no upper limit. rust-cargo - uses 2.x since upstream version 0.74, upstream made no code changes when bumping indexmap version. rust-cbindgen - upstream has not bumped but preliminary tests don't show any issues. rust-clap-3 - clap 3.x still uses indexmap 1 clap 4.x no longer uses indexmap, but that patch is too big to reasonablly backport. Preliminary tests with a bumped version seem ok. rust-gimli - upstream is on 2.x and appears to have bumped the dependency with no code changes (there are code changes in the commit, but they appear to relate to other dependency changes) rust-h2 - upstream git (not yet included in a release) is on 2.x and appears to have bumped the dependency with no code changes (there are code changes in the commit, but they appear to relate to other dependency changes) rust-laurel - non rust team package, upstream bumped dependency with no code changes. rust-petgraph - upstream already uses 2.x, debian package has no upper limit on dependency. rust-plist - upstream already uses 2.x rust-pyproject-toml - upstream already uses 2.x rust-quick-junit - upstream already uses 2.x rust-ron - upstream uses 2.x in the latest (semver-breaking) version. The dependency bump was made with no code changes (though there was a feature name change) rust-ruma-common - upstream uses 2.x in the latest (semver-breaking) version. The dependency bump was made with no code changes rust-serde-with - upstream depends optionally on both versions 1.x and 2.x of indexmap. Debian currently disables the latter, looks like it needs to switch to disabling the former. rust-serde-yaml - upstream uses 2.x in the latest (semver-breaking) version. The dependency bump was made with no code changes (though there was a feature change) rust-sqlx-core - upstream uses 2.x, debian package has no upper limit on version. rust-toml-edit - upstream uses 2.x, debian package has no upper limit on version. rust-tre-command - upstream has not bumped but preliminary tests don't show any issues. rust-tree-sitter-cli - upstream has not bumped but preliminary tests don't show any issues. rust-configparser - upstream has not bumped but preliminary tests don't show any issues. rust-cookie-store - upstream has not bumped but preliminary tests don't show any issues. rust-elsa - upstream has not bumped but preliminary tests don't show any issues. rust-object - upstream dependency bumped with no code changes rust-py03 - upstream allows both versions 1.x and 2.x debian package has no upper limit on version. rust-rkyv - upstream has not bumped, tests pass after bumping dependency and adding std feature to it. rust-schemars - upstream has features for both versions of indexmap, currently the indexmap2 feature is disabled, no rdeps seem to depend on the indexmap feature rust-serde-json - upstream uses 2.x rust-toml - upstream uses 2.x in the latest (semver-breaking) version. The dependency bump was made with no code changes rust-toml-0.5 - upstream uses 2.x in the latest (semver-breaking) version. The dependency bump was made with no code changes rust-toml-edit - upstream uses 2.x in the latest (semver-breaking) version. The dependency bump was made with no code changes rust-tower - upstream has not bumped, test failures look no worse than before.
Bug#1055534: sq-wot - should the binary be dropped.
Package: sq-wot x-debbugs-cc: alexander.kj...@gmail.com, d...@fifthhorseman.net Since it seems we now (fingers crossed) finally have a version of ring that should build on all release architectures I decided it was time to fix sequoia-sq which has been languishing in a rc buggy state since soon after the bookworm release. As part of doing this I looked at sequoia-wot. While checking what was going on, I discovered that the sq-wot binary had been dropped in a git commit by Alexander Kjäll (capitol), even more strangely the same commit that disabled building the binaries added manpages for them. I discussed this with capitol on irc capitol, can you explain e2c9d5396d09ed7d3105dfd2cdf2ac4fbf594926 because it really doesn't make much sense to me It seems to add a bunch of manpages for the binaries, yet disable actually building/packaging them! and none of the (pretty substantial) changes other than the new upstream release are documented in the changelog. (sorry if it wasn't clear in my first message, the hex string was a debcargo-conf commit ID https://salsa.debian.org/rust-team/debcargo-conf/-/commit/e2c9d5396d09ed7d3105dfd2cdf2ac4fbf594926 ) * hiddenman_ (~and...@broadband-46-242-8-154.ip.moscow.rt.ru) has joined plugwash: i followed the pattern of a couple of other binaries with man pages here, to add the man pages to the package, and add a .manpages file to get them into the correct place i have a memory of checking that they got into the package, but let me verify that again and sorry for not documenting this in the changelog, i'll make an effort on being more verbose in that +bin = false overlay = "." -uploaders = ["Daniel Kahn Gillmor "] -bin_name = "sq-wot" +uploaders = ["Daniel Kahn Gillmor ", "Alexander Kjäll "] that's the bit I don't get, you seem to be disabling building of binaries at all. ohh... yes, now i realize, the sq-wot binary have been deprecated from sequoia, and replace with a 'wot' subcommand to the sq binary and since the original package had only gone to experimental i thought it best to not get it into debian i should have cleaned up the man pages, those where done before i talked to sequoia about it and they asked it to not be packaged and now the package seem to have bit-rotted and can't be built anymore, due to usage of a deprecated function, I can look at that tomorrow umm sq-wot is in stable, testing and unstable i must remember this totally wrong :/ After this conversation I decided to revert the change dropping the binary package for now. I don't object to removing the binary package in principle if it is clear that people fully understand the situation and have decided that is the best way forward but equally i'm not going to upload a version including said removal until/unless it is clear to me that there is said consensus. Especially given that while removing a binary package is easy, adding one back requires dealing with the random delay and nitpicking of the NEW queue. I would particularly like dkg, as the person who initially packaged sequoia-wot a year and a half ago to weigh in on this.
Bug#1049388: rust-rusqlite: Please upgrade to v0.29
Please upgrade to (or separately provide) newer upstream branch v0.29. Preliminary analysis looks pretty good in general, but parsec-service has some issues with it's migration to testing that need to be sorted before going ahead with this in unstable. I've just made some uploads that will hopefully sort them, but may need to wait a while to see if they have worked due to the mips64el buildd issues. One of the rdeps "settle" is yours, i've done a test build and it seems to build fine after updating the dependency. Ive uploaded the new rusqlite to experimenta. Feel free to do any further testing.
Bug#1055116: rust-rustls, please prepare update for new ring.
On 02/11/2023 05:51, Jonas Smedegaard wrote: That's wonderful news. I am happy to update rust-rustls, as soon as possible. Seems to only blocker is an transitive dependency on rust-rcgen needing an update as well: See bug#1055132. The package rust-sct needs relinking as well. Thanks for preparing the updates, I think we are now ready to move on this in unstable, afaict the following steps are needed. 1. re-upload the new untrusted, ring, rcgen and sct packages to unstable. 2. re-upload the new rustls-webpki and rustls packages to unstable 3. re-upload the remaining rust team packages that depend on ring to unstable. 4. upload a version of rust-rustls-native-certs with updated dev-dependencies (less critical, but needed to avoid rust-rustls-native-certs becoming rc buggy and may also be needed for testing migration) To minimise the time things are broken in unstable are you ok if I perform step 2 (and maybe also step 4) as a NMU?
Bug#1043016: rust-fastrand: Please upgrade to v2
> Please updagre to (or separately provide) newer upstream branch v2. I've taken a priliminary look at this and it looks like it's probably good to go. I've uploaded it to experimental. Four of the rdeps are your packages, can you prepare updates for them Package: rsass Package: rust-async-executor Package: rust-async-lock Package: rust-blocking
Bug#1055320: rust-snow, upcoming ring update.
Package: rust-snow As you are probablly aware, i'm currently working on an update of rust-ring. rust-snow depends on ring, it seems to build and run tests fine after bumping the dependency. Upstream, dependabot has submitted a PR to update ring, but upstream has not responded to it yet. I've left a comment there to see if they can shed any light. Anyway, a debdiff is attached.diff -Nru rust-snow-0.9.3/debian/changelog rust-snow-0.9.3/debian/changelog --- rust-snow-0.9.3/debian/changelog2023-10-16 18:17:30.0 + +++ rust-snow-0.9.3/debian/changelog2023-11-04 03:51:25.0 + @@ -1,3 +1,10 @@ +rust-snow (0.9.3-2.1) UNRELEASED; urgency=medium + + * Non-maintainer upload. + * Bump ring dependency to 0.17. + + -- Peter Michael Green Sat, 04 Nov 2023 03:51:25 + + rust-snow (0.9.3-2) unstable; urgency=medium * extend patch 2001 to omit feature vector-tests, diff -Nru rust-snow-0.9.3/debian/control rust-snow-0.9.3/debian/control --- rust-snow-0.9.3/debian/control 2023-09-10 17:01:45.0 + +++ rust-snow-0.9.3/debian/control 2023-11-04 03:51:25.0 + @@ -11,8 +11,8 @@ librust-rand-core-0.6+default-dev , librust-rand-core-0.6+getrandom-dev , librust-rand-core-0.6+std-dev , - librust-ring-0.16+default-dev , - librust-ring-0.16+std-dev , + librust-ring-0.17+default-dev , + librust-ring-0.17+std-dev , librust-rustc-version-0.4-dev , librust-serde-1+default-dev , librust-serde-derive-1+default-dev , @@ -33,8 +33,8 @@ librust-rand-core-0.6+default-dev, librust-rand-core-0.6+getrandom-dev, librust-rand-core-0.6+std-dev, - librust-ring-0.16+default-dev, - librust-ring-0.16+std-dev, + librust-ring-0.17+default-dev, + librust-ring-0.17+std-dev, librust-subtle-2+default-dev, ${misc:Depends}, Provides: diff -Nru rust-snow-0.9.3/debian/patches/1001_ring.patch rust-snow-0.9.3/debian/patches/1001_ring.patch --- rust-snow-0.9.3/debian/patches/1001_ring.patch 1970-01-01 00:00:00.0 + +++ rust-snow-0.9.3/debian/patches/1001_ring.patch 2023-11-04 03:50:31.0 + @@ -0,0 +1,13 @@ +Index: rust-snow-0.9.3/Cargo.toml +=== +--- rust-snow-0.9.3.orig/Cargo.toml rust-snow-0.9.3/Cargo.toml +@@ -51,7 +51,7 @@ pqcrypto-kyber = { version = "0.7", opti + pqcrypto-traits = { version = "0.3", optional = true } + + # ring crypto provider +-ring = { version = "^0.16.2", optional = true, features = ["std"] } ++ring = { version = "^0.17", optional = true, features = ["std"] } + # libsodium crypto provider + sodiumoxide = { version = "0.2", optional = true } + byteorder = { version = "1.4", optional = true } diff -Nru rust-snow-0.9.3/debian/patches/2001_features.patch rust-snow-0.9.3/debian/patches/2001_features.patch --- rust-snow-0.9.3/debian/patches/2001_features.patch 2023-09-10 16:59:13.0 + +++ rust-snow-0.9.3/debian/patches/2001_features.patch 2023-11-04 03:51:16.0 + @@ -39,7 +39,7 @@ -pqcrypto-traits = { version = "0.3", optional = true } - # ring crypto provider - ring = { version = "^0.16.2", optional = true, features = ["std"] } + ring = { version = "^0.17", optional = true, features = ["std"] } -# libsodium crypto provider -sodiumoxide = { version = "0.2", optional = true } -byteorder = { version = "1.4", optional = true } diff -Nru rust-snow-0.9.3/debian/patches/series rust-snow-0.9.3/debian/patches/series --- rust-snow-0.9.3/debian/patches/series 2023-08-24 09:19:45.0 + +++ rust-snow-0.9.3/debian/patches/series 2023-11-04 03:49:30.0 + @@ -1,3 +1,4 @@ +1001_ring.patch 2001_features.patch 2002_x25519-dalek.patch 2003_no_bench.patch diff -Nru rust-snow-0.9.3/debian/source/include-binaries rust-snow-0.9.3/debian/source/include-binaries --- rust-snow-0.9.3/debian/source/include-binaries 1970-01-01 00:00:00.0 + +++ rust-snow-0.9.3/debian/source/include-binaries 2023-11-04 03:48:32.0 + @@ -0,0 +1,631 @@ +target/debug/.fingerprint/atty-1c8233b00b5d42d5/dep-lib-atty +target/debug/.fingerprint/autocfg-ebc62869343c4f5c/dep-lib-autocfg +target/debug/.fingerprint/bitflags-7c49c9267eabca2a/dep-lib-bitflags +target/debug/.fingerprint/cc-0bea097c188cf75f/dep-lib-cc +target/debug/.fingerprint/cfg-if-0deb1cbf488332ce/dep-lib-cfg-if +target/debug/.fingerprint/clap-ec35a29a6847014b/dep-lib-clap +target/debug/.fingerprint/clap_lex-4acb92bec96d72aa/dep-lib-clap_lex +target/debug/.fingerprint/getrandom-61d5dab8b4c2d45d/dep-lib-getrandom +target/debug/.fingerprint/hashbrown-19ec0a3c02dca951/dep-lib-hashbrown +target/debug/.fingerprint/hex-491dc1f1836d305b/dep-lib-hex +target/debug/.fingerprint/indexmap-078c8d4830b8147a/dep-build-script-build-script-build +target/debug/.fingerprint/indexmap-956fce6b53aefb0f/dep-lib-indexmap +target/debug/.fingerprint/itoa-33ec9bdf767cbbb3/dep-lib-itoa
Bug#1055319: rust-rustls-webpki autopkgtest failure.
Package: rust-rustls-webpki Version: 0.101.6-1 Severity: serious The autopkgtest for rust-rustls-webpki fails with 238s error[E0583]: file not found for module `test_utils` 238s --> src/lib.rs:65:1 238s| 238s 65 | pub(crate) mod test_utils; 238s| ^^ 238s| 238s= help: to create the module `test_utils`, create file "src/test_utils.rs" or "src/test_utils/mod.rs" This bug affects both the versions in unstable and experimental. It does not affect the version currently in testing. It appears that the file src/test_utils.rs is included in the source package but is not making it into the binary package for some reason.
Bug#1055318: rust-rustls-native-certs - dev-dependency update for new untrusted/ring
Package: rust-rustls-native-certs Version: 0.6.3-3 As you are probablly aware, I'm preparing an update of the untrusted and ring crates (currently in experimental). The rustls-native-certs crate doesn't use untrusted or ring at runtime, but it does have dev-dependencies on them. After bumping the dev-dependencies the package builds and runs autopkgtests fine.diff -Nru rust-rustls-native-certs-0.6.3/debian/changelog rust-rustls-native-certs-0.6.3/debian/changelog --- rust-rustls-native-certs-0.6.3/debian/changelog 2023-08-19 22:13:08.0 + +++ rust-rustls-native-certs-0.6.3/debian/changelog 2023-11-04 02:42:29.0 + @@ -1,3 +1,11 @@ +rust-rustls-native-certs (0.6.3-3.1) UNRELEASED; urgency=medium + + * Non-maintainer upload. + * Bump dev-dependencies on untrusted and ring to 0.9 and 0.17 +and update build-dependencies and test dependencies accordingly. + + -- Peter Michael Green Sat, 04 Nov 2023 02:42:29 + + rust-rustls-native-certs (0.6.3-3) unstable; urgency=medium * renumber patch 2006 -> 1001; diff -Nru rust-rustls-native-certs-0.6.3/debian/control rust-rustls-native-certs-0.6.3/debian/control --- rust-rustls-native-certs-0.6.3/debian/control 2023-08-07 00:24:56.0 + +++ rust-rustls-native-certs-0.6.3/debian/control 2023-11-04 02:42:29.0 + @@ -5,12 +5,12 @@ debhelper-compat (= 13), dh-cargo (>= 25), librust-openssl-probe-0.1+default-dev (>= 0.1.2) , - librust-ring-0.16+default-dev (>= 0.16.5) , + librust-ring-0.17+default-dev , librust-rustls-0.21+default-dev , librust-rustls-pemfile-1+default-dev , librust-rustls-webpki-0.101+default-dev , librust-serial-test-2+default-dev , - librust-untrusted-0.7+default-dev , + librust-untrusted-0.9+default-dev , libstring-shellquote-perl, Maintainer: Jonas Smedegaard Standards-Version: 4.6.2 diff -Nru rust-rustls-native-certs-0.6.3/debian/patches/1002_untrusted_ring.patch rust-rustls-native-certs-0.6.3/debian/patches/1002_untrusted_ring.patch --- rust-rustls-native-certs-0.6.3/debian/patches/1002_untrusted_ring.patch 1970-01-01 00:00:00.0 + +++ rust-rustls-native-certs-0.6.3/debian/patches/1002_untrusted_ring.patch 2023-11-04 02:37:54.0 + @@ -0,0 +1,17 @@ +Description: Bump ring and rustls dev-dependencies to 0.17 and 0.9 +Author: Peter Michael Green +Last-Update: 2023-11-04 +--- +This patch header follows DEP-3: http://dep.debian.net/deps/dep3/ +--- rust-rustls-native-certs-0.6.3.orig/Cargo.toml rust-rustls-native-certs-0.6.3/Cargo.toml +@@ -16,3 +16,3 @@ + [dev-dependencies] +-ring = "0.16.5" ++ring = "0.17" + rustls = "0.21.0" +@@ -20,3 +20,3 @@ + serial_test = "2" +-untrusted = "0.7.0" # stick to the version ring depends on for now ++untrusted = "0.9.0" # stick to the version ring depends on for now + webpki-roots = "0.23" diff -Nru rust-rustls-native-certs-0.6.3/debian/patches/2004_x509-parser.patch rust-rustls-native-certs-0.6.3/debian/patches/2004_x509-parser.patch --- rust-rustls-native-certs-0.6.3/debian/patches/2004_x509-parser.patch 2023-08-14 10:13:20.0 + +++ rust-rustls-native-certs-0.6.3/debian/patches/2004_x509-parser.patch 2023-11-04 02:38:56.0 + @@ -8,7 +8,7 @@ +++ b/Cargo.toml @@ -20,7 +20,6 @@ serial_test = "2" - untrusted = "0.7.0" # stick to the version ring depends on for now + untrusted = "0.9.0" # stick to the version ring depends on for now webpki-roots = "0.23" -x509-parser = "0.15" diff -Nru rust-rustls-native-certs-0.6.3/debian/patches/2005_webpki-roots.patch rust-rustls-native-certs-0.6.3/debian/patches/2005_webpki-roots.patch --- rust-rustls-native-certs-0.6.3/debian/patches/2005_webpki-roots.patch 2023-08-19 22:13:08.0 + +++ rust-rustls-native-certs-0.6.3/debian/patches/2005_webpki-roots.patch 2023-11-04 02:39:56.0 + @@ -9,7 +9,7 @@ @@ -19,7 +19,6 @@ rustls-webpki = ">= 0.100, < 0.102" serial_test = "2" - untrusted = "0.7.0" # stick to the version ring depends on for now + untrusted = "0.9.0" # stick to the version ring depends on for now -webpki-roots = "0.23" [target.'cfg(all(unix, not(target_os = "macos")))'.dependencies] diff -Nru rust-rustls-native-certs-0.6.3/debian/patches/series rust-rustls-native-certs-0.6.3/debian/patches/series --- rust-rustls-native-certs-0.6.3/debian/patches/series2023-08-14 10:14:25.0 + +++ rust-rustls-native-certs-0.6.3/debian/patches/series2023-11-04 02:34:55.0 + @@ -1,4 +1,5 @@ 1001_rustls-webpki.patch +1002_untrusted_ring.patch 2001_security-framework.patch 2002_schannel.patch 2004_x509-parser.patch diff -Nru rust-rustls-native-certs-0.6.3/debian/tests/control rust-rustls-native-certs-0.6.3/debian/tests/control --- rust-rustls-native-certs-0.6.3/debian/tests/control 2023-08-07 00:25:15.0 + +++ rust-rustls-native-certs-0.6.3/debian/tests/control 2023-11-04 02:42:29.0 + @@ -4,12
Bug#1055116: rust-rustls, please prepare update for new ring.
Package: rust-rustls After a long wait, ring released version 0.17 which is far more portable than previous versions. The lack of portability of ring has been a thorn in the side of the rust team for some time so we would really like to upgrade. The good news is that rustls has updated to the new version of ring *without* bumping semver. So hopefully this transition can be kept relatively small. I've uploaded the new version of ring to experimental, could you prepare new versions of the rustls packages to work with it.
Bug#1054630: dgit - cant import llvm-toolchain-15.
On 27/10/2023 11:37, Ian Jackson wrote: Peter Green writes ("Bug#1054630: dgit - cant import llvm-toolchain-15."): Now on the one hand, the changelog in llvm-toolchain-15 is indeed broken. I filed a bug about that. Thanks. (FMR that's #1051961) On the other hand, the package was accepted by the Debian archive and related tooling. Not being able to import it is blocking things up for raspbian. I'd appreciate a way to downgrade this error to a warning. *sigh* what a mess. Quite so. I might be able to look at this in the next few days. It's not 100% straightfrward, because dgit uses that information to construct the commit messages for the dsc import. So I think some dummy information will have to be provided. Or maybe we should be using the dsc Maintainer instead. Presumably the archive is better at rejecting a missing dsc Maintainer. Correct me if I'm wrong here, but doesn't the import process only use information from the topmost changelog entry.
Bug#1054630: dgit - cant import llvm-toolchain-15.
Package: dgit Version: 11.3 dgit can't import the current version of llvm-toolchain-15 dgit import-dsc ../llvm-toolchain-15_15.0.7-10.dsc ..workingbranch Dgit metadata in .dsc: NO git hash using existing llvm-toolchain-15_15.0.7.orig.tar.xz using existing llvm-toolchain-15_15.0.7-10.debian.tar.xz dpkg-source: info: extracting llvm-toolchain-15 in llvm-toolchain-15-15.0.7 dpkg-source: info: unpacking llvm-toolchain-15_15.0.7.orig.tar.xz dpkg-source: info: unpacking llvm-toolchain-15_15.0.7-10.debian.tar.xz dpkg-source: warning: unexpected end of diff 'llvm-toolchain-15-15.0.7/debian/patches/gcc-13-build-fix.patch' dpkg-parsechangelog: warning: debian/changelog(l124): found start of entry where expected more change data or trailer LINE: llvm-toolchain-14 (1:14.0.6-16) unstable; urgency=medium dgit: error: missing field Maintainer in package changelog, entry no.11 Now on the one hand, the changelog in llvm-toolchain-15 is indeed broken. I filed a bug about that. On the other hand, the package was accepted by the Debian archive and related tooling. Not being able to import it is blocking things up for raspbian. I'd appreciate a way to downgrade this error to a warning.
Bug#1054568: breezy - broken rust regex build-dependency
Package: breezy Version: 3.3.4-1 Severity: serious Tags: patch Breezy build-depends on librust-regex+aho-corasick-dev which is no longer provided (in either physical or virtual form) by rust-regex. Looking at the Cargo.toml files I belive the correct build-dependency is librust-regex-1+default-dev (>= 1.5.4), after changing the build-dependency I was able to get a succesful build. If there are no objections I will likely NMU this in the not too distant future.diff -Nru breezy-3.3.4/debian/changelog breezy-3.3.4/debian/changelog --- breezy-3.3.4/debian/changelog 2023-09-04 17:39:38.0 + +++ breezy-3.3.4/debian/changelog 2023-10-26 02:55:52.0 + @@ -1,3 +1,12 @@ +breezy (3.3.4-1.1) UNRELEASED; urgency=medium + + * Non-maintainer upload. + * Replace broken build-dependency on "librust-regex+aho-corasick-dev" +with build-dependency on "librust-regex-1+default-dev (>= 1.5.4)" +based on the contents of Cargo.toml. + + -- Peter Michael Green Thu, 26 Oct 2023 02:55:52 + + breezy (3.3.4-1) unstable; urgency=low * New upstream release. diff -Nru breezy-3.3.4/debian/control breezy-3.3.4/debian/control --- breezy-3.3.4/debian/control 2023-09-04 17:39:38.0 + +++ breezy-3.3.4/debian/control 2023-10-26 02:55:40.0 + @@ -31,7 +31,7 @@ debhelper-compat (= 13), librust-pkg-version-dev, librust-pyo3-dev, - librust-regex+aho-corasick-dev, + librust-regex-1+default-dev (>= 1.5.4), rustc Standards-Version: 4.6.2 Rules-Requires-Root: no
Bug#1051820: eza
reopen 1051820 thanks > eza was accepted into unstable Indeed. > replacing exa. exa is still there. Someone still needs to decide what to do about it (pprobablly turning it into a transitional package is appropriate)
Bug#1054141: fd - incompatible with clap 4.4.6
Package: rust-fd-find Version: 8.7.0-3 Severity: serious This bug affects both 8.7.0-3 in testing and 8.7.0-4 in unstable. I recently uploaded clap 4.4.6, since this was not a semver bump I was not expecting any breakage. Unfortunately it turns out it broke fd. There are (at least) two issues, the first is that the "unstable-grouped" feature was removed in clap 4.2.0 by the commit https://github.com/clap-rs/clap/commit/d5089b267235db72a6ea146ac4f1cb7f79a170a6 "fix!: Remove stablized unstable-grouped feature". By removing the reference to the "unstable-grouped" feature I was able to successfully build fd and run it's tests against clap versions 4.2.0 through 4.2.4. The second issue arises starting with clap version 4.2.5, a bunch of tests fail with errors like. test_custom_ignore_files stdout thread 'test_custom_ignore_files' panicked at '`fd --ignore-file custom.ignore foo` did not exit successfully. stdout: --- --- stderr: --- thread 'main' panicked at 'Command fd: Argument group 'execs' conflicts with non-existent 'has_results' id', /root/.cargo/registry/src/github.com-1ecc6299db9ec823/clap_builder-4.2.5/src/builder/debug_asserts.rs:317:13 note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace ---', tests/testenv/mod.rs:238:13 I'm not sure what should be done about this second issue. I've filed a bug upstream at https://github.com/sharkdp/fd/issues/1397
Bug#1050678: rust-async-process - update for new rustix.
severity 1050678 serious thanks On 27/08/2023 23:19, Peter Michael Green wrote: Package: rust-async-process Version: 1.7.0-2 I'm preparing an update for rustix, it's a new semver but so-far everything seems to build with just the dependency bumped. I've uploaded it to experimental. and assuming no showstoppers show up I hope to re-upload it to experimental soon. I have prepared a patch for this package, are you ok if I just NMU it at the same time as I'm uploading the rest of the reverse dependencies or do you want to handle the update yourself? The new version of rustix is now in unstable.
Bug#1053632: [Pkg-rust-maintainers] Bug#1053632: rust-libslirp: Remove from Debian?
rust-libslirp has no reverse dependencies in Debian. https://codesearch.debian.net/search?q=path%3Adebian%2Fcontrol+rust-libslirp=1 It is also one of the blockers for removing the old rust-zbus-1 from Debian. See https://bugs.debian.org/1053631 Can we remove rust-libslirp and rust-libslirp-sys from Debian? We discussed this on irc a while back, and apparently the package is important to debos. Though the package relationship is only a "suggests". rust-libslirp depends on the obsolete rust-zbus-1 (instead of the current rust-zbus-3) and rust-zvariant-2 (instead of rust-zvariant-3). I looked at porting this, but came to the conclusion that is beyond what I could reasonablly do. IIRC zbus moved from sync rust to async rust and there was no porting guide.
Bug#1053630: flask-dance: build-depends on package that is not in testing.
Package: flask-dance Version: 6.2.0.2-1 Severity: serious Justification: rc policy - "packages must be buildable within the same release". Tags: trixie, sid flask-dance build-depends on python3-sphinxcontrib.seqdiag which is not in testing, it was removed because it FTBFS and was badly broken, but for some reason flask-dance was not removed at the same time (dependency handling in auto-removals is far from perfect). This issue affects both versions 6:2.0.2-1 in testing and 7.0.0-1 which is trying to migrate to testing but failing to do so due to the aforementioned build-dependency.
Bug#1053536: squeekboard FTBFS with version 0.18 of rust gtk stack.
Package: squeekboard Version: 1.22.0-4 Severity: serious Tags: patch The rust gtk stack was recently updated, and squeekboard needs a few tweaks to build with the new version. I have whipped up a patch and tested that squeekboard builds with it, I have not tested it beyond that.diff -Nru squeekboard-1.22.0/debian/changelog squeekboard-1.22.0/debian/changelog --- squeekboard-1.22.0/debian/changelog 2023-08-23 08:47:31.0 + +++ squeekboard-1.22.0/debian/changelog 2023-10-05 19:31:30.0 + @@ -1,3 +1,10 @@ +squeekboard (1.22.0-4.1) UNRELEASED; urgency=medium + + * Non-maintainer upload. + * update patches for gtk-rs 0.18 + + -- Peter Michael Green Thu, 05 Oct 2023 19:31:30 + + squeekboard (1.22.0-4) unstable; urgency=medium [ Peter Michael Green ] diff -Nru squeekboard-1.22.0/debian/patches/0001-Cargo.deps.newer-update-for-gtk-rs-0.17.patch squeekboard-1.22.0/debian/patches/0001-Cargo.deps.newer-update-for-gtk-rs-0.17.patch --- squeekboard-1.22.0/debian/patches/0001-Cargo.deps.newer-update-for-gtk-rs-0.17.patch 2023-08-23 08:47:31.0 + +++ squeekboard-1.22.0/debian/patches/0001-Cargo.deps.newer-update-for-gtk-rs-0.17.patch 1970-01-01 00:00:00.0 + @@ -1,53 +0,0 @@ -From: Arnaud Ferraris -Date: Tue, 27 Jun 2023 12:31:30 +0200 -Subject: Cargo.deps.newer: update for gtk-rs 0.17 - - Cargo.deps.newer | 20 ++-- - 1 file changed, 10 insertions(+), 10 deletions(-) - -diff --git a/Cargo.deps.newer b/Cargo.deps.newer -index 197dfa3..c236cc5 100644 a/Cargo.deps.newer -+++ b/Cargo.deps.newer -@@ -9,30 +9,30 @@ zvariant = "2.10.*" - zvariant_derive = "2.10.*" - - [dependencies.cairo-rs] --version = "0.14.*" -+version = "0.17.*" - - [dependencies.cairo-sys-rs] --version = "0.14.*" -+version = "0.17.*" - - [dependencies.gdk] --version = "0.14.*" -+version = "0.17.*" - - [dependencies.gio] --version = "0.14.*" -+version = "0.17.*" - features = ["v2_58"] - - [dependencies.glib] --version = "0.14.*" -+version = "0.17.*" - features = ["v2_58"] - - [dependencies.glib-sys] --version = "0.14.*" -+version = "0.17.*" - features = ["v2_58"] - - [dependencies.gtk] --version = "0.14.*" --features = ["v3_22"] -+version = "0.17.*" -+features = ["v3_24"] - - [dependencies.gtk-sys] --version = "0.14.*" --features = ["v3_22"] -+version = "0.17.*" -+features = ["v3_24"] diff -Nru squeekboard-1.22.0/debian/patches/0001-Cargo.deps.newer-update-for-gtk-rs-0.18.patch squeekboard-1.22.0/debian/patches/0001-Cargo.deps.newer-update-for-gtk-rs-0.18.patch --- squeekboard-1.22.0/debian/patches/0001-Cargo.deps.newer-update-for-gtk-rs-0.18.patch 1970-01-01 00:00:00.0 + +++ squeekboard-1.22.0/debian/patches/0001-Cargo.deps.newer-update-for-gtk-rs-0.18.patch 2023-10-05 19:31:30.0 + @@ -0,0 +1,55 @@ +Modified by Peter Michael Green for version 0.18 of rust gtk stack. + +From: Arnaud Ferraris +Date: Tue, 27 Jun 2023 12:31:30 +0200 +Subject: Cargo.deps.newer: update for gtk-rs 0.17 + +--- + Cargo.deps.newer | 20 ++-- + 1 file changed, 10 insertions(+), 10 deletions(-) + +diff --git a/Cargo.deps.newer b/Cargo.deps.newer +index 197dfa3..c236cc5 100644 +--- a/Cargo.deps.newer b/Cargo.deps.newer +@@ -9,30 +9,30 @@ zvariant = "2.10.*" + zvariant_derive = "2.10.*" + + [dependencies.cairo-rs] +-version = "0.14.*" ++version = "0.18.*" + + [dependencies.cairo-sys-rs] +-version = "0.14.*" ++version = "0.18.*" + + [dependencies.gdk] +-version = "0.14.*" ++version = "0.18.*" + + [dependencies.gio] +-version = "0.14.*" ++version = "0.18.*" + features = ["v2_58"] + + [dependencies.glib] +-version = "0.14.*" ++version = "0.18.*" + features = ["v2_58"] + + [dependencies.glib-sys] +-version = "0.14.*" ++version = "0.18.*" + features = ["v2_58"] + + [dependencies.gtk] +-version = "0.14.*" +-features = ["v3_22"] ++version = "0.18.*" ++features = ["v3_24"] + + [dependencies.gtk-sys] +-version = "0.14.*" +-features = ["v3_22"] ++version = "0.18.*" ++features = ["v3_24"] diff -Nru squeekboard-1.22.0/debian/patches/0004-Cargo.-use-xkbcommon-v0.5.patch squeekboard-1.22.0/debian/patches/0004-Cargo.-use-xkbcommon-v0.5.patch --- squeekboard-1.22.0/debian/patches/0004-Cargo.-use-xkbcommon-v0.5.patch 2023-08-23 08:47:31.0 + +++ squeekboard-1.22.0/debian/patches/0004-Cargo.-use-xkbcommon-v0.5.patch 2023-10-05 19:31:30.0 + @@ -26,14 +26,10 @@ index c236cc5..b36e616 100644 --- a/Cargo.deps.newer +++ b/Cargo.deps.newer -@@ -7,6 +7,7 @@ zbus = "1.9.*" - zvariant = "2.10.*" - # Newer versions seem to confuse the version of Cargo on Debian Bullseye +@@ -9,2 +9,3 @@ zbus = "1.9.*" zvariant_derive = "2.10.*" +xkbcommon = { version = "0.5.*", features = ["wayland"] } - [dependencies.cairo-rs] - version = "0.17.*" diff --git a/Cargo.toml.in b/Cargo.toml.in index c9b2064..557e6c6 100644 --- a/Cargo.toml.in diff -Nru
Bug#1053440: rust-sequoia-openpgp - incompatible with new regex-syntax.
Package: rust-sequoia-openpgp Version: 1.16.0-3 Severity: serious rust-sequoia-openpgp depends on an old version of regex-syntax, I tried bumping the dependency but the build failed. I have filed an issue about this upstream at https://gitlab.com/sequoia-pgp/sequoia/-/issues/1056
Bug#1053431: rust-grep-regex - depends/build-depends on old version of regex-syntax
Package: rust-grep-regex Version: 0.1.11-1 Severity: serious rust-grep-regex depends on an old version of rust-regex-syntax, this is fixed in upstream git, but looking at the commit messages it's not something I feel comfortable cherry-picking. I have opened an upstream issue enquiring about the possibility of a new release at https://github.com/BurntSushi/ripgrep/issues/2619
Bug#1053420: rust-matchers - incompatible with mew regex-automata
Package: rust-matchers Version: 0.1.0-1 Severity: serious tas: trixie, sid rust-regex-automata was recently updated to 0.3, rendering the dependencies and build-dependencies of rust-matchers uninstallable. The changes seem to be fairly major, there is an upstream pull request but details are still being discussed, so I don't think we should pull it into Debian at this time.
Bug#1052490: rust-async-task, build-depends on old version of rust-flume.
Package: rust-async-task Version: 4.4.0-3 Severity: serious Tags: patch rust-async-task's build-dependencies are unsatisfiable in testing/unstable due to a recent update to rust-flume. upstream bumped the dependency with no code changes, and after adding the patch to the Debian package and adjusting the rest of the packaging accordingly I was able to get a succesfull build and autopkgtest run. debdiff attached.diff -Nru rust-async-task-4.4.0/debian/changelog rust-async-task-4.4.0/debian/changelog --- rust-async-task-4.4.0/debian/changelog 2023-09-10 13:43:24.0 + +++ rust-async-task-4.4.0/debian/changelog 2023-09-23 05:20:54.0 + @@ -1,3 +1,14 @@ +rust-async-task (4.4.0-3.1) UNRELEASED; urgency=medium + + * Non-maintainer upload. + * Add patch 0001_update_flume.patch ++ Trivial upstream patch to bump flume depdency to 0.11 + * Reduce context in 2001_flaky-test.patch so it will apply on top of +0001_update_flume.patch + * Update build and autopkgtest dependencies for flume 0.11. + + -- Peter Michael Green Sat, 23 Sep 2023 05:20:54 + + rust-async-task (4.4.0-3) unstable; urgency=medium * omit testing examples for autopkgtest without feature std; diff -Nru rust-async-task-4.4.0/debian/control rust-async-task-4.4.0/debian/control --- rust-async-task-4.4.0/debian/control2023-07-16 09:24:09.0 + +++ rust-async-task-4.4.0/debian/control2023-09-23 05:20:54.0 + @@ -7,7 +7,7 @@ librust-async-task-4+default-dev , librust-atomic-waker-1+default-dev , librust-easy-parallel-3+default-dev , - librust-flume-0.10-dev , + librust-flume-0.11-dev , librust-once-cell-1+default-dev , librust-smol-1+default-dev , libstring-shellquote-perl, diff -Nru rust-async-task-4.4.0/debian/patches/0001_update_flume.patch rust-async-task-4.4.0/debian/patches/0001_update_flume.patch --- rust-async-task-4.4.0/debian/patches/0001_update_flume.patch 1970-01-01 00:00:00.0 + +++ rust-async-task-4.4.0/debian/patches/0001_update_flume.patch 2023-09-23 05:17:33.0 + @@ -0,0 +1,29 @@ +commit c42a143176fbf5201411f97f27247ba52e054135 +Author: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com> +Date: Mon Aug 21 00:25:27 2023 + + +Update flume requirement from 0.10 to 0.11 + +Updates the requirements on [flume](https://github.com/zesterer/flume) to permit the latest version. +- [Changelog](https://github.com/zesterer/flume/blob/master/CHANGELOG.md) +- [Commits](https://github.com/zesterer/flume/commits) + +--- +updated-dependencies: +- dependency-name: flume + dependency-type: direct:production +... + +Signed-off-by: dependabot[bot] + +diff --git a/Cargo.toml b/Cargo.toml +index 4345762..fb239ba 100644 +--- a/Cargo.toml b/Cargo.toml +@@ -23,5 +23,5 @@ std = [] + easy-parallel = "3" + flaky_test = "0.1" +-flume = { version = "0.10", default-features = false } ++flume = { version = "0.11", default-features = false } + futures-lite = "1.12.0" + once_cell = "1" diff -Nru rust-async-task-4.4.0/debian/patches/2001_flaky-test.patch rust-async-task-4.4.0/debian/patches/2001_flaky-test.patch --- rust-async-task-4.4.0/debian/patches/2001_flaky-test.patch 2023-08-14 09:47:35.0 + +++ rust-async-task-4.4.0/debian/patches/2001_flaky-test.patch 2023-09-23 05:19:12.0 + @@ -7,14 +7,8 @@ This patch header follows DEP-3: http://dep.debian.net/deps/dep3/ --- a/Cargo.toml +++ b/Cargo.toml -@@ -21,7 +21,6 @@ - [dev-dependencies] - atomic-waker = "1" - easy-parallel = "3" +@@ -24,1 +24,0 @@ -flaky_test = "0.1" - flume = { version = "0.10", default-features = false } - futures-lite = "1.12.0" - once_cell = "1" --- a/tests/waker_panic.rs +++ b/tests/waker_panic.rs @@ -238,60 +238,6 @@ diff -Nru rust-async-task-4.4.0/debian/patches/series rust-async-task-4.4.0/debian/patches/series --- rust-async-task-4.4.0/debian/patches/series 2023-02-03 11:05:22.0 + +++ rust-async-task-4.4.0/debian/patches/series 2023-09-23 05:16:50.0 + @@ -1 +1,2 @@ +0001_update_flume.patch 2001_flaky-test.patch diff -Nru rust-async-task-4.4.0/debian/tests/control rust-async-task-4.4.0/debian/tests/control --- rust-async-task-4.4.0/debian/tests/control 2023-09-10 13:40:58.0 + +++ rust-async-task-4.4.0/debian/tests/control 2023-09-23 05:20:54.0 + @@ -6,7 +6,7 @@ librust-async-task-4-dev, librust-atomic-waker-1+default-dev, librust-easy-parallel-3+default-dev, - librust-flume-0.10-dev, + librust-flume-0.11-dev, librust-once-cell-1+default-dev, librust-smol-1+default-dev, Restrictions: allow-stderr @@ -19,7 +19,7 @@ librust-async-task-4+default-dev, librust-atomic-waker-1+default-dev, librust-easy-parallel-3+default-dev, - librust-flume-0.10-dev, + librust-flume-0.11-dev, librust-once-cell-1+default-dev, librust-smol-1+default-dev, Restrictions: allow-stderr @@
Bug#1052334: rust-leptonica-sys - Debian and Cargo dependencies inconsistent.
Package: rust-leptonica-sys Version: 0.4.6-3 Severity: serious The Debian dependencies for rust-leptonica-sys allow versions of rust-bindgen from 0.60.x to 0.66.x, however the Cargo dependencies only allow versions from 0.64.x to 0.66.x. This is causing autopkgtest failures and blocking rust-leptonica-sys and hence rust-bindgen from migrating to testing. Please make the dependencies consistent, either by changing the Debian depndencies to match the Cargo ones or by changing the Cargo dependency to match the Debian ones.
Bug#1051146: rust-laurel, upcoming rust-bindgen update.
Severity 1051146 serious Thanks The new version of rust-bindgen has been uploaded to experimental so people can test against it. The new version of rust-bindgen has now been uploaded to unstable.
Bug#1051961: llvm-toolchain-15 - broken changelog.
Package: llvm-toolchain-15 While trying to import the llvm-toolchain-15 package from trixie using dgit import-dsc, dgit gave the error.> LINE: llvm-toolchain-14 (1:14.0.6-16) unstable; urgency=medium dgit: error: missing field Maintainer in package changelog, entry no.11 Looking at the changelog it does indeed seem to be broken. llvm-toolchain-15 (1:15.0.7-2) unstable; urgency=medium [ Sylvestre Ledru ] * Yeah, we would like to have this version in bookworm (Closes: #1032316) * Adjust some lintian overrides * Disable flang on s390x. Seems that it is breaking [ Gianfranco Costamagna ] * Update print lldb python patch, following what was done in automake for newer python [ Samuel Thibault ] * Fix disabling amdgpu on non-Linux. llvm-toolchain-14 (1:14.0.6-16) unstable; urgency=medium [ Sylvestre Ledru ] * also apply the wasm build fix -- Gianfranco Costamagna Fri, 08 Sep 2023 00:41:35 +0200 I presume this was a case of a merge conflict resoloution gone wrong. I would appreciate if you could fix the changelog on the next upload.
Bug#1051815: wasmedge - autopkgtest failure with rustc 1.68
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 Very simple test case: $ podman run --rm -it debian:sid # or bookworm to test with rustc 1.67 root@ad697f1c195f:~# apt install rustc libstd-rust-dev-wasm32 [...] root@ad697f1c195f:~# rustc -V rustc 1.68.2 root@ad697f1c195f:~# cat > hello.rs <https://github.com/bytecodealliance/wasmtime/releases/download/v12.0.1/wasmtime-v12.0.1-x86_64-linux.tar.xz | tar --wildcards --strip-components=1 -xJ '*/wasmtime' root@ad697f1c195f:~# ./wasmtime hello.wasm Error: failed to run main module `hello.wasm` Caused by: 0: failed to invoke command default 1: error while executing at wasm backtrace: 0: 0x9cd6 - !__stack_chk_fail 1: 0x9d3c - !__wasilibc_init_ssp 2: 0x320 - !__wasm_call_ctors 3: 0x342 - !_start note: using the `WASMTIME_BACKTRACE_DETAILS=1` environment variable may show more debugging information 2: wasm trap: wasm `unreachable` instruction executed Thanks, Faidon
Bug#1051808: [Pkg-rust-maintainers] Bug#1051808: rust-users: RUSTSEC-2023-0059
rust-users is currently unmaintained upstream. In a fork a proposed patch can be found. What is the rust-users situation with respect of Debian as it is unmantained upstream? So we have two options, patch it or move away from it to a fork The crate "uzers" which is a fork of this crate was recently uploaded to Debian and I have just uploaded version 0.11.3 of it. I believe that said version includes a fix for this issue. Uzers is listed as an alternative on the rustsec entry, but at least so-far there doesn't seem to have been a whole lot of uptake. crates.io only lists one reverse dependency of said fork, which is itself a fork of exa.
Bug#1051820: exa is unmaintained, should we migrate to eza?
Package: exa Version: 0.10.1-4 It has come to my attention that exa is unmaintained, with the last upstream release being over 2 years ago. However there is a fork "eza" which does appear to be maintained. Should we be preparing a transition to it?
Bug#1051815: wasmedge - autopkgtest failure with rustc 1.68
Package: wasmedge Version: 0.13.3+dfsg-1 Severity:serious 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. https://ci.debian.net/data/autopkgtest/unstable/amd64/w/wasmedge/37793933/log.gz https://ci.debian.net/data/autopkgtest/unstable/amd64/w/wasmedge/37778163/log.gz https://ci.debian.net/data/autopkgtest/testing/amd64/w/wasmedge/37770138/log.gz 93s autopkgtest [14:54:23]: test capi-wasi-env: [--- 93s 1..2 94s ok 1 build wasi_get_env.wasm with cargo/rustc 94s not ok 2 build set_wasm_env with gcc 94s # (in test file debian/tests/capi-wasi-env, line 24) 94s # `assert_output --partial "ENV1: VAL1"' failed 94s # 94s # -- output does not contain substring -- 94s # substring (1 lines): 94s # ENV1: VAL1 94s # output (4 lines): 94s # [2023-09-12 14:54:24.910] [error] execution failed: unreachable, Code: 0x89 94s # [2023-09-12 14:54:24.910] [error] In instruction: unreachable (0x00) , Bytecode offset: 0x9efb 94s # [2023-09-12 14:54:24.910] [error] When executing function name: "print_env" 94s # Execution Failed. Error message: unreachable 94s # -- 94s # 95s autopkgtest [14:54:25]: test capi-wasi-env: ---] 95s autopkgtest [14:54:25]: test capi-wasi-env: - - - - - - - - - - results - - - - - - - - - - 95s capi-wasi-envFAIL non-zero exit status 1
Bug#1042891: rust-ron: Please upgrade to v0.8
Please upgrade to (or separately provide) newer upstream branch v0.8. I think this may be a bit premature. I see two reverse dependencies, rust-palette and rust-insta. rust-palette has only a dev-dependency upstream and a build/test dependency in debian. rust-insta is still on 0.7.x upstream.
Bug#1050299: [Pkg-rust-maintainers] Bug#1050299: rust-webpki: RUSTSEC-2023-0052
I think this indicates that it can indeed be safely removed from Debian? I'm CC'ing developers that have made uploads to this packages in the past for additiponal opinions as I suspect the issue is more subtle than that. dak rm does not take account of virtual packages. So for rust packages it is generally useless. In terms of reverse dependencies, a number have already moved to the fork rustls-webpki. However there are still a few left. Specifically rust-async-tls, rust-trust-dns-proto and rust-trust-dns-client. async-tls has not switched upstream. On the other hand I don't see any packages in Debian using it yet. ccing mjt to see what the reason for packaging it was. trust-dns-proto and trust-dns-server have switched upstream, however updating the trust-dns-packages has proved a bit more involved than I would have liked. I pushed my current efforts to the branch trust-dns-0.23 in the debcargo-conf repo. The main thing left to deal with regarding the trust-dns is aardvark-dns, the code changes needed were beyond my skills, so I reported an issue upstream. Upstream has come up with a patch but has not merged it yet. https://github.com/containers/aardvark-dns/pull/381
Bug#1051244: rust-tesseract-sys, upcoming rust-bindgen update.
Package: rust-tesseract-sys Version: 0.5.14-3 In the rust team we are working on upgrading rust-bindgen from 0.60 to 0.66, there are a few reasons for this. Firstly it's part of the dependency stack for the new version of rust-cargo. Secondly the version currently in sid has a compatibility issue with new versions of llvm. Thirdly Jonas has filed a bug report requesting the new upstream version. bindgen bumps semver on most releases, however the changes tend to be relatively minor. You can read the changelog at https://github.com/rust-lang/rust-bindgen/blob/main/CHANGELOG.md#0610 I don't see anything too scary in there. The new version of rust-bindgen has been uploaded to experimental so people can test against it. After bumping the dependencies your package built successfully and the autopkgtests passed. I Checked upstream and it seems they have bumped to 0.64 with a commit that did not contain any code changes. The attatched debdiff, raises the upper limit for the bindgen dependency. diff -Nru rust-tesseract-sys-0.5.14/debian/changelog rust-tesseract-sys-0.5.14/debian/changelog --- rust-tesseract-sys-0.5.14/debian/changelog 2023-08-20 09:21:50.0 + +++ rust-tesseract-sys-0.5.14/debian/changelog 2023-09-05 00:09:36.0 + @@ -1,3 +1,10 @@ +rust-tesseract-sys (0.5.14-3.1) UNRELEASED; urgency=medium + + * Non-maintainer upload. + * Bump bindgen dependency to 0.66 + + -- Peter Michael Green Tue, 05 Sep 2023 00:09:36 + + rust-tesseract-sys (0.5.14-3) unstable; urgency=medium * update DEP-3 patch headers diff -Nru rust-tesseract-sys-0.5.14/debian/control rust-tesseract-sys-0.5.14/debian/control --- rust-tesseract-sys-0.5.14/debian/control2023-02-03 09:53:28.0 + +++ rust-tesseract-sys-0.5.14/debian/control2023-09-05 00:09:36.0 + @@ -5,7 +5,7 @@ clang , debhelper-compat (= 13), dh-cargo (>= 25), - librust-bindgen-0.60+default-dev , + librust-bindgen-0.66+default-dev , librust-leptonica-sys-0.4+default-dev , librust-pkg-config-0.3+default-dev (>= 0.3.19) , libstring-shellquote-perl, @@ -22,7 +22,7 @@ Architecture: all Multi-Arch: foreign Depends: - librust-bindgen-0.60+default-dev, + librust-bindgen-0.66+default-dev, librust-leptonica-sys-0.4+default-dev, librust-pkg-config-0.3+default-dev (>= 0.3.19), libtesseract-dev, diff -Nru rust-tesseract-sys-0.5.14/debian/patches/1001_bindgen.patch rust-tesseract-sys-0.5.14/debian/patches/1001_bindgen.patch --- rust-tesseract-sys-0.5.14/debian/patches/1001_bindgen.patch 1970-01-01 00:00:00.0 + +++ rust-tesseract-sys-0.5.14/debian/patches/1001_bindgen.patch 2023-09-05 00:09:32.0 + @@ -0,0 +1,20 @@ +Description: update bindgen to 0.66 + Upstream has already updated bindgen to 0.64, they did not seem to make + any code changes as part of the process +Author: Peter Michael Green +Forwarded: no +Last-Update: 2023-09-05 + +Index: rust-tesseract-sys-0.5.14/Cargo.toml +=== +--- rust-tesseract-sys-0.5.14.orig/Cargo.toml rust-tesseract-sys-0.5.14/Cargo.toml +@@ -15,7 +15,7 @@ build = "build.rs" + leptonica-sys = "~0.4" + + [build-dependencies] +-bindgen = "0.60" ++bindgen = "0.66" + [target.'cfg(windows)'.build-dependencies] + vcpkg = "0.2.8" + [target.'cfg(any(target_os="macos", target_os="linux"))'.build-dependencies] diff -Nru rust-tesseract-sys-0.5.14/debian/patches/2002_no_windows.patch rust-tesseract-sys-0.5.14/debian/patches/2002_no_windows.patch --- rust-tesseract-sys-0.5.14/debian/patches/2002_no_windows.patch 2023-08-14 10:19:32.0 + +++ rust-tesseract-sys-0.5.14/debian/patches/2002_no_windows.patch 2023-09-05 00:05:54.0 + @@ -9,7 +9,7 @@ @@ -16,7 +16,5 @@ [build-dependencies] - bindgen = "0.60" + bindgen = "0.66" -[target.'cfg(windows)'.build-dependencies] -vcpkg = "0.2.8" [target.'cfg(any(target_os="macos", target_os="linux"))'.build-dependencies] diff -Nru rust-tesseract-sys-0.5.14/debian/patches/series rust-tesseract-sys-0.5.14/debian/patches/series --- rust-tesseract-sys-0.5.14/debian/patches/series 2022-10-24 15:06:57.0 + +++ rust-tesseract-sys-0.5.14/debian/patches/series 2023-09-05 00:08:00.0 + @@ -1 +1,2 @@ +1001_bindgen.patch 2002_no_windows.patch
Bug#1049975: rust-oxhttp - consider moving to rustls 0.21
On 17/08/2023 19:26, Peter Green wrote: It would be nice to only need a single version of rustls in Debian, with my recent round of uploads, most of the reverse dependencies are now moved to version 0.21, leaving oxhttp as one of the few remaining on 0.20. rust-oxhttp is now the last one remaining. Upstream has moved in git, but have not yet made a release based on the new version Upstream has now make a new release, including the switch to rustls 0.21 and also switching from rust-webpki (which we would like to get rid of) to rust-rustls-webpki. Please consider uploading it.
Bug#1050296: rust-rustls needs a source-only upload
Package: rust-rustls Version: 0.21.6-3 The most recent upload of rust-rustls included a binary package and hence cannot migrate to testing. Since the package is arch all this cannot be fixed with a binnmu. Please make a new source-only upload so the package can migrate.
Bug#1040837: rust-log situation update.
On 22/08/2023 04:47, Peter Green wrote: Fabian: is sval-serde ready for sponsorship? if so can you add the RFS file? I couldn't see anything wrong with the sval-serde package, so I decided to go ahead and upload it, it is now in NEW.
Bug#1040837: rust-log situation update.
A bunch of packages just cleared new, and I made a bunch of follow up uploads. The result is that the situation surrounding the log package has improved a bit, but it still less than ideal. The "kv_unstable" and "kv_unstable_sval" features are now enabled, the "kv_unstable_serde" feature is currently disabled because it requires the serde feature in the value-bag package, which in turn requires the serde1 feature in the value-bag-serde1 crate, which in turn requires the sval_serde crate which is not currently in debian. I belive the net result of this is that * kv-log-macro's binary dependencies are satisfiable but it's build-dependencies are not. * femme's dependencies and build-dependencies are still unsatisfiable. Looking in the debcargo-conf repository it seems that Fabian Grünbichler has made a start on packaging sval_serde. Fabian: is sval-serde ready for sponsorship? if so can you add the RFS file?
Bug#1050185: rust-derive-builder-core - depends on old version of darling.
Package: rust-derive-builder-core Version: 0.12.0-1 Severity: serious Recently a new version of the darling crates was uploaded, (Alexander Kajil prepared the uploads, Sylvestre uploaded darling-core and I uploaded the rest of the darling crates). Most of the reverse dependencies either already had uploads prepared, or I was able to prepare uploads. Unfortunately things were not so fortunate with derive-builder-core. Bumping darling generally also implies bumping syn, otherwise one runs into issues. We currently have both versions 1.x and 2.x of syn in Debian, so this is not an issue in itself but it means more API changes. I tried to patch derive-builder-core for the new syn, but I failed. Looking upstream it seems they are also currently stuck. https://github.com/colin-kiegel/rust-derive-builder/issues/292
Bug#1049977: rust-hyper-rustls - please update to match new rust-tokio-rustls
Since rust-hyper-rustls has reverse dependencies as well, its move to to v0.24 will involve NEW queue and potentially take some time. According to my searches the only direct reverse dependency of rust-hyper-rustls is rust-reqwest. I have the new version of that (which is not semver-breaking) ready to upload as soon as hyper-rustls is uploaded to unstable. I don't see any need for introducing NEW packages here.
Bug#1049977: rust-hyper-rustls - please update to match new rust-tokio-rustls
Package: rust-hyper-rustls Version: 0.23.2-4 Severity: serious I just updated tokio-rustls to 0.24.1, hyper-rustls needs updating to 0.24.1 to match.
Bug#1049975: rust-oxhttp - consider moving to rustls 0.21
Package: rust-oxhttp Version: 0.1.6-2 It would be nice to only need a single version of rustls in Debian, with my recent round of uploads, most of the reverse dependencies are now moved to version 0.21, leaving oxhttp as one of the few remaining on 0.20. Upstream has moved in git, but have not yet made a release based on the new version, the patch however is trivial and applies cleanly to the Debian package. After applying the patch I was able to succesfully build the package and run the autopkgtests.diff -Nru rust-oxhttp-0.1.6/debian/changelog rust-oxhttp-0.1.6/debian/changelog --- rust-oxhttp-0.1.6/debian/changelog 2023-08-14 13:06:01.0 + +++ rust-oxhttp-0.1.6/debian/changelog 2023-08-17 18:10:33.0 + @@ -1,3 +1,10 @@ +rust-oxhttp (0.1.6-2.1) UNRELEASED; urgency=medium + + * Non-maintainer upload. + * Apply upstream patch for rustls 0.21 + + -- Peter Michael Green Thu, 17 Aug 2023 18:10:33 + + rust-oxhttp (0.1.6-2) unstable; urgency=medium * update dh-cargo fork; diff -Nru rust-oxhttp-0.1.6/debian/patches/0001_update_rustls.patch rust-oxhttp-0.1.6/debian/patches/0001_update_rustls.patch --- rust-oxhttp-0.1.6/debian/patches/0001_update_rustls.patch 1970-01-01 00:00:00.0 + +++ rust-oxhttp-0.1.6/debian/patches/0001_update_rustls.patch 2023-08-17 18:09:52.0 + @@ -0,0 +1,32 @@ +commit 9590e31bfc7db3fe19ed2236d697abefb84f3de3 +Author: Tpt +Date: Sun Jun 11 21:59:12 2023 +0200 + +Upgrades Rustls + +diff --git a/.github/workflows/build.yml b/.github/workflows/build.yml +index 4983b10..64e978f 100644 +--- a/.github/workflows/build.yml b/.github/workflows/build.yml +@@ -1,6 +1,7 @@ + name: build + +-on: [push, pull_request] ++on: ++ - pull_request + + jobs: + fmt: +diff --git a/Cargo.toml b/Cargo.toml +index 2e4c7f0..138dc6a 100644 +--- a/Cargo.toml b/Cargo.toml +@@ -17,7 +17,7 @@ httparse = "1" + lazy_static = "1" + native-tls = { version = "0.2", optional = true } + rayon-core = { version = "1", optional = true } +-rustls-crate = { version = "0.20", optional = true, package = "rustls" } ++rustls-crate = { version = "0.21", optional = true, package = "rustls" } + rustls-native-certs = { version = "0.6", optional = true } + url = "2" + diff -Nru rust-oxhttp-0.1.6/debian/patches/series rust-oxhttp-0.1.6/debian/patches/series --- rust-oxhttp-0.1.6/debian/patches/series 2022-06-24 19:28:17.0 + +++ rust-oxhttp-0.1.6/debian/patches/series 2023-08-17 18:10:18.0 + @@ -1 +1,2 @@ +0001_update_rustls.patch 2001_disable_doctest.patch
Bug#1049389: rust-regex: Please update to v1.8.4
Please update to (at least) newer upstream release v1.8.4. regex 1.8.x bumps the aho-corasick dependency to 1.x, I took a look through the reverse dependencies. * elan - debian dependency but no cargo dependency probablly not an issue * rust-cpp-macros - patch written but package has very little in the way of tests. https://github.com/mystor/rust-cpp/issues/108 * rust-globset- fixed upstream, not semver breaking. * rust-grep-regex - fixed in upstream git, but not release yet, and doesn't look reasonable to backport https://github.com/BurntSushi/ripgrep/commit/1035f6b1ff502eb5b1a5fc49a79f45971c772d47 * rust-code-analysis - fixed upstream, not released yet, but patch looks pretty minor https://github.com/mozilla/rust-code-analysis/commit/9b7ead60efb153020133deaa9e6a32b40d40a676 * squeekboard - debian dependency but no cargo dependency probablly not an issue My conclusion is that we need to wait for a new release of grep-regex before moving on this. 1.9.x also adds a dependency on a new version of regex-automata which is it's own issue.
Bug#1049447: minexpert2 build-dependencies unsatisfiable on many architectures due to change in daps.
Package: minexpert2 Version: 8.6.3-1 Severity: serious Tags: trixie, sid Justification: rc-policy - packages must be buildable within the same release. User: debian...@lists.debian.org Usertags: edos-uninstallable x-debbugs-cc: lopi...@debian.org daps 3.3.2+cleaned1-5 moved calibre from suggests to depends. This means that daps can no longer be installed on architectures where calibre is not available. This in turn means that minexpert2 cannot be built on those architectures. This applies to both the version of minexpert2 in testing and the version in unstable.
Bug#1049445: massxpert build-dependencies unsatisfiable on many architectures due to change in daps.
Package: massxpert Version: 7.0.0-2 Severity: serious Justification: rc-policy - packages must be buildable within the same release. User: debian...@lists.debian.org Usertags: edos-uninstallable x-debbugs-cc: lopi...@debian.org daps 3.3.2+cleaned1-4 moved calibre from suggests to depends. This means that daps can no longer be installed on architectures where calibre is not available. This in turn means that massxpert cannot be built on those architectures.
Bug#1049440: calculix-cgx - build-depends on dropped transitional package.
Package: calculix-cgx Version: 2.17+dfsg-2 Severity: serious Tags: trixie, sid calculix-cgx build-depends on libgl1-mesa-glx which is no longer built by the mesa source package. It is still present in unstable and on a couple of architectures in testing as a cruft package, but it is completely gone from most architectures in testing. Please update your build-dependencies as appropriate.
Bug#1043418: rust-rustls-webpki - autopkgtest failure, file not found errors.
tags 1043418 +patch thanks The autopkgtest for rust-rustls-webpki is failing with a bunch of file not found errors. Investigating a bit more, the issue is that the data files in question are included in the source package, but not in the binary package. I'm not sure if this is a result of your debcargo fork. In any case, I wrote a patch to allow the autpkgtest to use the test data from the source package. I also ran into a second issue, there is a patch that removes the dev-dependencies needed for the benches and also removes the bench declaration in Cargo.toml, but cargo has a feature for auto-detecting tests/benches/examples, so it was still trying to build the benches. I added autobenches=false to disable this. With the attatched debdiff, the autopkgtest passes. I'd like to see this fixed fairly quickly, as fixes blocked by the stalled rustls transition are threatening a bunch of packages with auto-removal. If I get no response I'll likely NMU it next weekend. diff -Nru rust-rustls-webpki-0.101.3/debian/changelog rust-rustls-webpki-0.101.3/debian/changelog --- rust-rustls-webpki-0.101.3/debian/changelog 2023-08-13 11:24:24.0 + +++ rust-rustls-webpki-0.101.3/debian/changelog 2023-08-15 16:01:55.0 + @@ -1,3 +1,14 @@ +rust-rustls-webpki (0.101.3-1.1) UNRELEASED; urgency=medium + + * Non-maintainer upload. + * Add patch 2004 and alter debian/tests/control to use test data from the source +package during autopkgtest as the test data is not included in the binary +package (Closes: #1043418) + * Extend patch 2001 to add autobenches=false so that the benches +are really disabled + + -- Peter Michael Green Tue, 15 Aug 2023 16:01:55 + + rust-rustls-webpki (0.101.3-1) unstable; urgency=medium [ upstream ] diff -Nru rust-rustls-webpki-0.101.3/debian/patches/2001_bencher.patch rust-rustls-webpki-0.101.3/debian/patches/2001_bencher.patch --- rust-rustls-webpki-0.101.3/debian/patches/2001_bencher.patch 2023-08-13 11:24:24.0 + +++ rust-rustls-webpki-0.101.3/debian/patches/2001_bencher.patch 2023-08-15 15:56:54.0 + @@ -1,11 +1,22 @@ -Description: drop bench-only build-dependencies +Description: drop bench-only build-dependencies and disable benches Author: Jonas Smedegaard -Last-Update: 2023-07-29 +Author: Peter Michael Green +Last-Update: 2023-08-15 --- This patch header follows DEP-3: http://dep.debian.net/deps/dep3/ a/Cargo.toml -+++ b/Cargo.toml -@@ -72,9 +72,6 @@ +Index: rust-rustls-webpki-0.101.3/Cargo.toml +=== +--- rust-rustls-webpki-0.101.3.orig/Cargo.toml rust-rustls-webpki-0.101.3/Cargo.toml +@@ -22,6 +22,7 @@ name = "rustls-webpki" + readme = "README.md" + repository = "https://github.com/rustls/webpki; + version = "0.101.3" ++autobenches = false + + include = [ + "Cargo.toml", +@@ -72,9 +73,6 @@ untrusted = "0.7.1" [dev-dependencies] base64 = "0.21" @@ -15,7 +26,7 @@ serde = { version = "1.0", features = ["derive"] } serde_json = "1.0" -@@ -94,11 +91,6 @@ +@@ -94,11 +92,6 @@ lto = true debug-assertions = false codegen-units = 1 diff -Nru rust-rustls-webpki-0.101.3/debian/patches/2004_use_test_data_from_source_package_during_autopkgtest.patch rust-rustls-webpki-0.101.3/debian/patches/2004_use_test_data_from_source_package_during_autopkgtest.patch --- rust-rustls-webpki-0.101.3/debian/patches/2004_use_test_data_from_source_package_during_autopkgtest.patch 1970-01-01 00:00:00.0 + +++ rust-rustls-webpki-0.101.3/debian/patches/2004_use_test_data_from_source_package_during_autopkgtest.patch 2023-08-15 16:01:55.0 + @@ -0,0 +1,43 @@ +Description: allow using an environment variable to specify where to find test-data + This allows the test data, which is included in the source package, but not in the + binary package to be used during the autopkgtest. +Author: Peter Michael Green +Last-Update: 2023-08-15 +--- +This patch header follows DEP-3: http://dep.debian.net/deps/dep3/ +diff -urN rustls-webpki-0.101.3/build.rs rustls-webpki-0.101.3/build.rs +--- rustls-webpki-0.101.3/build.rs 1970-01-01 00:00:00.0 + rustls-webpki-0.101.3/build.rs 2023-08-15 17:04:24.774078929 + +@@ -0,0 +1,7 @@ ++use std::env::VarError::NotPresent; ++fn main() { ++println!("cargo:rerun-if-env-changed=SOURCEPACKAGEDIR"); ++if std::env::var("SOURCEPACKAGEDIR") == Err(NotPresent) { ++ println!("cargo:rustc-env=SOURCEPACKAGEDIR={}",std::env::current_dir().unwrap().to_str().unwrap()); ++} ++} +diff -urN rustls-webpki-0.101.3/src/signed_data.rs rustls-webpki-0.101.3/src/signed_data.rs +--- rustls-webpki-0.101.3/src/signed_data.rs 2006-07-24 01:21:28.0 + rustls-webpki-0.101.3/src/signed_data.rs 2023-08-15 16:39:39.669690115 + +@@ -441,7 +441,8 @@ + macro_rules! test_file_bytes { + ( $file_name:expr ) => { +
Bug#1043449: [Pkg-rust-maintainers] Bug#1043449: rust-tera: Please provide feature date-locale
Please provide feature date-locale. The date-locale feature in tera depends on the "unstable-locales" feature in chrono. There are a couple of issues I see here. 1. It's an unstable feature, it's not clear how much of a maintinance burden that will be going forward. 2. It requires the "pure-rust-locales" crate which is not currently in Debian.
Bug#1042490: rust-assert-cmd: Please update to v2.0.10
Please update to (at least) newer upstream release v2.0.10. The new version of assert_cmd has switched to anstream instead of yansi, the anstream crate is not currently in Debian. As I've said before I don't like to package new things if they aren't personally important to me The update also looks like it will bring with it a new version of the predicates crate, but that doesn't seem to be a huge deal. I've pushed my work in progress on this update to the "update-assert-cmd" branch if anyone else wants to pick it up.
Bug#1042194: netavark: FTBFS: unsatisfiable build-dependencies: librust-netlink-packet-core-0.4+default-dev (>= 0.4.2-~~), librust-netlink-packet-core-0.4+default-dev (>= 0.4.2-~~)
tags 1042194 +patch thanks During a rebuild of all packages in sid, your package failed to build on amd64. The attached patch makes netavark build again (note: some of the packages it depends on have only just been accepted, so it may be a little time before binaries are available in sid).diff -Nru netavark-1.4.0/debian/changelog netavark-1.4.0/debian/changelog --- netavark-1.4.0/debian/changelog 2023-02-03 11:31:00.0 + +++ netavark-1.4.0/debian/changelog 2023-08-10 22:42:37.0 + @@ -1,3 +1,13 @@ +netavark (1.4.0-3.1) UNRELEASED; urgency=medium + + * Non-maintainer upload. + * Apply upstream patches for new netlink crates. (Closes: #1042194) + * Bump env-logger dependency. + * Stop patching zbus cargo dependency and update debian dependency, Debian +now has zbus 3.x + + -- Peter Michael Green Thu, 10 Aug 2023 22:42:37 + + netavark (1.4.0-3) unstable; urgency=medium * Install aardvark-dns by default with netavark diff -Nru netavark-1.4.0/debian/control netavark-1.4.0/debian/control --- netavark-1.4.0/debian/control 2023-02-03 11:31:00.0 + +++ netavark-1.4.0/debian/control 2023-08-10 22:42:37.0 + @@ -9,7 +9,7 @@ librust-atty-dev, librust-chrono-dev, librust-clap-3+derive-dev (>= 3.2.23), - librust-env-logger-dev (>> 0.9), + librust-env-logger-0.10-dev, librust-futures-dev, librust-fs2-dev, librust-humantime-dev, @@ -17,7 +17,7 @@ librust-iptables-dev, librust-libc-dev, librust-log-dev, - librust-netlink-packet-route-dev, + librust-netlink-packet-route-0.17-dev, librust-nix-dev, librust-rand-dev, librust-rtnetlink-dev, @@ -31,7 +31,7 @@ librust-termcolor-dev, librust-tokio+full-dev, librust-url-dev, - librust-zbus-dev (>= 1.9.2-4), + librust-zbus-3-dev (>= 3.6.1), librust-zvariant-dev, libstd-rust-dev, rustc:native , diff -Nru netavark-1.4.0/debian/patches/netlink-0.5.patch netavark-1.4.0/debian/patches/netlink-0.5.patch --- netavark-1.4.0/debian/patches/netlink-0.5.patch 1970-01-01 00:00:00.0 + +++ netavark-1.4.0/debian/patches/netlink-0.5.patch 2023-08-10 22:42:37.0 + @@ -0,0 +1,65 @@ +This patch is based on the upstream commit described below, adapted for +use in the Debian package by Peter Michael Green. + +commit 88a2a7a5a896d9b64d48b95f12e78cf91ee2b05f +Author: Paul Holzinger +Date: Fri Feb 17 15:03:19 2023 +0100 + +update netlink-packet-{route,core} to 0.15 and 0.5 + +They contain breaking changes but nothing major, just moved same type +definitions. + +Signed-off-by: Paul Holzinger + +diff --git a/Cargo.toml b/Cargo.toml +index de0b465..2620f80 100644 +--- a/Cargo.toml b/Cargo.toml +@@ -44,2 +44,2 @@ zbus = { version = "3.10.0" } +-netlink-packet-route = "0.13" +-netlink-packet-core = "0.4.2" ++netlink-packet-route = "0.15" ++netlink-packet-core = "0.5" +diff --git a/src/network/netlink.rs b/src/network/netlink.rs +index 4b11a28..dcf165a 100644 +--- a/src/network/netlink.rs b/src/network/netlink.rs +@@ -9,11 +9,14 @@ use crate::{ + wrap, + }; + use log::{info, trace}; ++use netlink_packet_core::{ ++NetlinkHeader, NetlinkMessage, NetlinkPayload, NLM_F_ACK, NLM_F_CREATE, NLM_F_DUMP, NLM_F_EXCL, ++NLM_F_REQUEST, ++}; + use netlink_packet_route::{ + nlas::link::{Info, InfoData, InfoKind, Nla}, +-AddressMessage, LinkMessage, NetlinkHeader, NetlinkMessage, NetlinkPayload, RouteMessage, +-RtnlMessage, AF_INET, AF_INET6, IFF_UP, NLM_F_ACK, NLM_F_CREATE, NLM_F_DUMP, NLM_F_EXCL, +-NLM_F_REQUEST, RTN_UNICAST, RTPROT_STATIC, RTPROT_UNSPEC, RT_SCOPE_UNIVERSE, RT_TABLE_MAIN, ++AddressMessage, LinkMessage, RouteMessage, RtnlMessage, AF_INET, AF_INET6, IFF_UP, RTN_UNICAST, ++RTPROT_STATIC, RTPROT_UNSPEC, RT_SCOPE_UNIVERSE, RT_TABLE_MAIN, + }; + use netlink_sys::{protocols::NETLINK_ROUTE, SocketAddr}; + +@@ -369,10 +372,7 @@ impl Socket { + } + + fn send( self, msg: RtnlMessage, flags: u16) -> NetavarkResult<()> { +-let mut packet = NetlinkMessage { +-header: NetlinkHeader::default(), +-payload: NetlinkPayload::from(msg), +-}; ++let mut packet = NetlinkMessage::new(NetlinkHeader::default(), NetlinkPayload::from(msg)); + packet.header.flags = NLM_F_REQUEST | flags; + packet.header.sequence_number = { + self.sequence_number += 1; +@@ -440,6 +440,7 @@ impl Socket { + return Ok(result); + } + } ++_ => {} + }; + + offset += rx_packet.header.length as usize; diff -Nru netavark-1.4.0/debian/patches/netlink-0.7.patch netavark-1.4.0/debian/patches/netlink-0.7.patch --- netavark-1.4.0/debian/patches/netlink-0.7.patch 1970-01-01 00:00:00.0 + +++ netavark-1.4.0/debian/patches/netlink-0.7.patch 2023-08-10 22:42:37.0 + @@ -0,0 +1,83 @@ +This patch is