Bug#1067027: python-cryptography build-dependencies unsatisfiable.

2024-03-18 Thread Peter Green

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

2024-03-16 Thread Peter Green

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"

2024-03-14 Thread Peter Green

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

2024-03-12 Thread Peter Green


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

2024-03-10 Thread Peter Green

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

2024-03-07 Thread Peter Green

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

2024-03-07 Thread Peter Green

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

2024-03-07 Thread Peter Green
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.

2024-03-04 Thread Peter Green

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.

2024-02-24 Thread Peter Green

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)

2024-02-23 Thread Peter Green

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.

2024-02-22 Thread Peter Green

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.

2024-02-22 Thread Peter Green

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.

2024-02-22 Thread Peter Green

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

2024-02-15 Thread Peter Green

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.

2024-02-15 Thread Peter Green

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.

2024-02-15 Thread Peter Green

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.

2024-02-15 Thread Peter Green

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.

2024-02-13 Thread Peter Green

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`

2024-02-13 Thread Peter Green

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

2024-02-13 Thread peter green

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.

2024-02-06 Thread Peter Green

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

2024-02-01 Thread Peter Green

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.

2024-01-30 Thread Peter Green

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

2024-01-30 Thread Peter Green

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

2024-01-27 Thread Peter Green

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.

2024-01-23 Thread Peter Green

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

2024-01-23 Thread Peter Green

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.

2024-01-23 Thread Peter Green

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

2024-01-18 Thread Peter Green

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.

2024-01-14 Thread Peter Green

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

2024-01-13 Thread Peter Green

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

2023-12-27 Thread Peter Green

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

2023-12-26 Thread Peter Green

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

2023-12-19 Thread Peter Green

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

2023-12-19 Thread Peter Green

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

2023-12-19 Thread Peter Green

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.

2023-12-19 Thread Peter Green

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.

2023-12-14 Thread Peter Green

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

2023-12-11 Thread Peter Green

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.

2023-12-07 Thread Peter Green

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

2023-12-06 Thread Peter Green

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

2023-12-06 Thread Peter Green

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

2023-12-03 Thread Peter Green

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

2023-12-01 Thread Peter Green

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

2023-11-28 Thread Peter Green

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

2023-11-21 Thread Peter Green

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

2023-11-21 Thread Peter Green

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

2023-11-16 Thread Peter Green

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

2023-11-16 Thread Peter Green

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

2023-11-13 Thread Peter Green


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.

2023-11-10 Thread Peter Green

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

2023-11-09 Thread Peter Green

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.

2023-11-07 Thread Peter Green

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

2023-11-07 Thread Peter Green

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.

2023-11-07 Thread Peter Green

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

2023-11-07 Thread peter green

> 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.

2023-11-03 Thread Peter Green

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.

2023-11-03 Thread Peter Green

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

2023-11-03 Thread Peter Green

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.

2023-10-31 Thread Peter Green

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.

2023-10-27 Thread Peter Green

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.

2023-10-26 Thread Peter Green

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

2023-10-25 Thread Peter Green

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

2023-10-24 Thread Peter Green

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

2023-10-17 Thread Peter Green

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.

2023-10-08 Thread Peter Green

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?

2023-10-07 Thread Peter Green

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.

2023-10-07 Thread Peter Green

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.

2023-10-05 Thread Peter Green

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.

2023-10-03 Thread Peter Green

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

2023-10-03 Thread Peter Green

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

2023-10-03 Thread Peter Green

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.

2023-09-22 Thread Peter Green

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.

2023-09-20 Thread Peter Green

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.

2023-09-19 Thread Peter Green

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.

2023-09-14 Thread Peter Green

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

2023-09-12 Thread Peter Green

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

2023-09-12 Thread Peter Green

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?

2023-09-12 Thread Peter Green

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

2023-09-12 Thread Peter Green

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

2023-09-08 Thread Peter Green

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

2023-09-08 Thread Peter Green

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.

2023-09-04 Thread Peter Green

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

2023-08-23 Thread Peter Green

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

2023-08-22 Thread Peter Green

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.

2023-08-22 Thread Peter Green

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.

2023-08-21 Thread Peter Green

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.

2023-08-21 Thread Peter Green

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

2023-08-19 Thread Peter Green

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

2023-08-17 Thread Peter Green

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

2023-08-17 Thread Peter Green

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

2023-08-15 Thread Peter Green

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.

2023-08-15 Thread Peter Green

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.

2023-08-15 Thread Peter Green

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.

2023-08-15 Thread Peter Green

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.

2023-08-15 Thread Peter Green

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

2023-08-11 Thread Peter Green

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

2023-08-11 Thread Peter Green




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-~~)

2023-08-10 Thread Peter Green

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 

  1   2   3   4   5   6   7   8   9   10   >