Bug#1071597: rust-laurel - autopkgtest failure on s390x

[Peter Green]

Package: rust-laurel
Version: 0.6.2-1
Severity: serious

rust-laurel's autopkgtest fails on s390x. I belive the patch
skip-parse_syslog-on-big-endian.patch should be reinstated
but I do not want to get into a revert war with the
maintainer.

So I feel I need to lay out, in more detail than
is visible in the changelog and git history, what I have
done regarding this package and why.

My main role in the rust team has been trying to keep the
"greater whole" of rust packages in a consistent state and
moving forward. Since upstream rust dependencies tend to be
pessimistic and Debian frowns upon packaging multiple
versions of the same software, this inevitablly involves
patching a bunch of packages.

I use autopkgtests as a tool to help minimize the chances
that these changes cause undetected breakage. As such when
bumping a dependency in a package that has no functional
autopkgtests, I will usually try to get at least some test
coverage.

Regarding rust-laurel specifically, up to version 0.5.6-1,
the tests were skipped.

In version 0.5.6-2, as part of preparing for the nix 0.27
update, I patched rust-laurel to get tests running. The
tests passed in my local tests on amd64 and so I uploaded
it.

Tests on debci revealed some failures though, there was
a test failure on 32-bit systems due to an integer
overflow in some time calculation code, and a failure
on s390x architectures which I determined to be down
to endian-specific test date in the test.

I prepared a fix for the time calculation code, which I
also posted upstreamed.

I decided that fixing the test data would probablly not
have a positive effort/benefit ratio and therefore added
a patch to skip the test on big-endian architectures. This
was still an improvement over the prior situation
where no tests were being run at all.

I uploaded these changes as 0.5.6-2.

The time overflow issue was fixed upstream in versions
0.6.0 and later. When Hilko uploaded version 0.6.1-1
he dropped my patches. The time overflow issue was fixed
upstream, so this made sense but nothing had been done
upstream to address the big endian issue. So this lead
to the tests once again failing on s390x.

I figured that this was a mistake, that Hilko had
incorrectly assumed that the big endian issue had been
taken care of upstream and after nearly a month of the
package sitting unable to migrate to testing, I
reinstated the patch and tweaked it to apply to the
new upstream version.

I made further uploads of 0.6.1 to address issues
related to the time64 and nix transitions.

When preparing the upload of 0.6.2-1, Hilko once again
dropped the patch with a changelog entry of
"Drop unneeded patches".

So that brings us to where we are now, the package
fails it's autopkgtests on s390x and I do not feel
it's appropriate to reinstate the patch for the second
time without first trying to get some feedback from
the maintainer.

Bug#1071240: rust-ahash, autopkgtest failure.

[peter green]

Package: rust-ahash
Version: 0.8.11-2

rust-hashbrown was recently updated to 0.14.5, and as a result the autopkgtest
for rust-ahash is failing.

https://ci.debian.net/packages/r/rust-ahash/testing/ppc64el/46811732/


 97s error: failed to select a version for the requirement `hashbrown = ">=0.12.3, 
<=0.14.3"`
 97s candidate versions found which didn't match: 0.14.5


Please adjust the dev-dependency to allow all 0.14.x versions, a debdiff
doing that is attatched.diff -Nru rust-ahash-0.8.11/debian/changelog rust-ahash-0.8.11/debian/changelog
--- rust-ahash-0.8.11/debian/changelog  2024-03-18 05:44:43.0 +
+++ rust-ahash-0.8.11/debian/changelog  2024-05-17 03:52:01.0 +
@@ -1,3 +1,10 @@
+rust-ahash (0.8.11-2.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Allow all 0.14.x versions of rust-hashbrown.
+
+ -- Peter Michael Green   Fri, 17 May 2024 03:52:01 +
+
 rust-ahash (0.8.11-2) unstable; urgency=medium
 
   * fix or tighten patch 1002
diff -Nru rust-ahash-0.8.11/debian/patches/2001_hashbrown.patch 
rust-ahash-0.8.11/debian/patches/2001_hashbrown.patch
--- rust-ahash-0.8.11/debian/patches/2001_hashbrown.patch   2024-03-17 
17:00:00.0 +
+++ rust-ahash-0.8.11/debian/patches/2001_hashbrown.patch   2024-05-17 
03:52:01.0 +
@@ -11,7 +11,7 @@
  pcg-mwc = "0.2.1"
  serde_json = "1.0.59"
 -hashbrown = "0.14.3"
-+hashbrown = ">= 0.12.3, <= 0.14.3"
++hashbrown = ">= 0.12.3, < 0.15"
  smallvec = "1.13.1"
  
  [package.metadata.docs.rs]
diff -Nru rust-ahash-0.8.11/debian/patches/2001_pcg-mwc.patch 
rust-ahash-0.8.11/debian/patches/2001_pcg-mwc.patch
--- rust-ahash-0.8.11/debian/patches/2001_pcg-mwc.patch 2024-03-17 
17:05:31.0 +
+++ rust-ahash-0.8.11/debian/patches/2001_pcg-mwc.patch 2024-05-17 
03:52:01.0 +
@@ -12,7 +12,7 @@
  rand = "0.8.5"
 -pcg-mwc = "0.2.1"
  serde_json = "1.0.59"
- hashbrown = ">= 0.12.3, <= 0.14.3"
+ hashbrown = ">= 0.12.3, < 0.15"
  smallvec = "1.13.1"
 --- a/tests/map_tests.rs
 +++ b/tests/map_tests.rs
diff -Nru rust-ahash-0.8.11/debian/patches/2001_smallvec.patch 
rust-ahash-0.8.11/debian/patches/2001_smallvec.patch
--- rust-ahash-0.8.11/debian/patches/2001_smallvec.patch2024-03-17 
17:13:21.0 +
+++ rust-ahash-0.8.11/debian/patches/2001_smallvec.patch2024-05-17 
03:52:01.0 +
@@ -10,7 +10,7 @@
 @@ -99,7 +99,7 @@
  rand = "0.8.5"
  serde_json = "1.0.59"
- hashbrown = ">= 0.12.3, <= 0.14.3"
+ hashbrown = ">= 0.12.3, < 0.15"
 -smallvec = "1.13.1"
 +smallvec = "1.11.2"
  

Bug#1071212: rust-roadmap - upcoming rust-serde-yaml update.

[Peter Green]

Package: rust-roadmap
Version: 0.6.0-2

I hope to update rust-serde-yaml to 0.9 in unstable soon
(this was requested a long time ago, but squeekboard
stalled the process)

rust-serde-yaml 0.9 is available in experimental. I
have built a version of rust-roadmap with the dependency
bumped and was able to build it and run it's
autopkgtests succesfully.

The debdiff I used for testing is attached.diff -Nru rust-roadmap-0.6.0/debian/changelog 
rust-roadmap-0.6.0/debian/changelog
--- rust-roadmap-0.6.0/debian/changelog 2024-01-14 19:47:20.0 +
+++ rust-roadmap-0.6.0/debian/changelog 2024-05-16 08:34:24.0 +
@@ -1,3 +1,10 @@
+rust-roadmap (0.6.0-2.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Bump serde-yaml to 0.9
+
+ -- Peter Michael Green   Thu, 16 May 2024 08:34:24 +
+
 rust-roadmap (0.6.0-2) unstable; urgency=medium
 
   * update copyright info: update coverage
diff -Nru rust-roadmap-0.6.0/debian/control rust-roadmap-0.6.0/debian/control
--- rust-roadmap-0.6.0/debian/control   2024-01-13 18:57:13.0 +
+++ rust-roadmap-0.6.0/debian/control   2024-05-16 08:34:24.0 +
@@ -9,7 +9,7 @@
  librust-anyhow-1+default-dev ,
  librust-serde-1+default-dev ,
  librust-serde-1+derive-dev ,
- librust-serde-yaml-0.8+default-dev ,
+ librust-serde-yaml-0.9+default-dev ,
  librust-textwrap-0.16+default-dev ,
  librust-thiserror-1+default-dev ,
  libstring-shellquote-perl,
@@ -26,7 +26,7 @@
  librust-anyhow-1+default-dev,
  librust-serde-1+default-dev,
  librust-serde-1+derive-dev,
- librust-serde-yaml-0.8+default-dev,
+ librust-serde-yaml-0.9+default-dev,
  librust-textwrap-0.16+default-dev,
  librust-thiserror-1+default-dev,
  ${misc:Depends},
diff -Nru rust-roadmap-0.6.0/debian/patches/1002_serde-yaml.patch 
rust-roadmap-0.6.0/debian/patches/1002_serde-yaml.patch
--- rust-roadmap-0.6.0/debian/patches/1002_serde-yaml.patch 1970-01-01 
00:00:00.0 +
+++ rust-roadmap-0.6.0/debian/patches/1002_serde-yaml.patch 2024-05-16 
08:27:50.0 +
@@ -0,0 +1,12 @@
+Index: rust-roadmap-0.6.0/Cargo.toml
+===
+--- rust-roadmap-0.6.0.orig/Cargo.toml
 rust-roadmap-0.6.0/Cargo.toml
+@@ -12,6 +12,6 @@ repository = "https://gitlab.com/larswir
+ [dependencies]
+ anyhow = "1"
+ serde = { version = "1.0.134", features = ["derive"] }
+-serde_yaml = "0.8"
++serde_yaml = "0.9"
+ textwrap = ">= 0.15, <= 0.16"
+ thiserror = "1"
diff -Nru rust-roadmap-0.6.0/debian/patches/series 
rust-roadmap-0.6.0/debian/patches/series
--- rust-roadmap-0.6.0/debian/patches/series2023-12-29 19:06:14.0 
+
+++ rust-roadmap-0.6.0/debian/patches/series2024-05-16 08:14:27.0 
+
@@ -1 +1,2 @@
 1001_textwrap.patch
+1002_serde-yaml.patch

Bug#1071054: 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

[Peter Green]

Package: ftp.debian.org

Please remove the cruft 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 were formerly physical packages, but are now virtual packages.
Unfortunately dak's dependency checks do not take proper account of virtual
packages, which leads dak to incorrectly believe that removing these packages
will cause broken dependencies.

While I am not 100% sure, I belive the presense of these cruft packages is
the cause of superious puipart's regression reports from britney which are
preventing the new version of rust-bindgen from migrating to testing.

Bug#1070836: rust-apple-nvram: Switch from rust-nix 0.26 to 0.27

[peter green]

I got the following error when trying the same thing.
I have no idea why, since the ioctl_write_ptr and ioctl_read macros are
still supposed to be around. I can't spot any relevant change in nix
that would cause this to happen. Help would be appreciated.


The relavent change is.


All Cargo features have been removed from the default set. Users will
need to specify which features they depend on in their Cargo.toml.


I've bumped the dependency, added the feature, run the autopkgtest
and uploaded the package.

Bug#1065459: rust-smol - upcoming rust-nix update.

[Peter Green]

On 04/03/2024 23:24, Peter Green wrote:

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.

I have now uploaded the new version of nix to unstable and uploaded
this as a NMU, final 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-05-02 17:16:46.0 +
@@ -1,3 +1,10 @@
+rust-smol (1.3.0-5.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Allow building with nix 0.27 (Closes: #1065459).
+
+ -- Peter Michael Green   Thu, 02 May 2024 17:16:46 +
+
 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-05-02 17:16:01.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-05-02 
17:16:01.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-05-02 
17:16:01.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-05-02 
17:16:01.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#1064580: netavark - diff for NMU 1.4.0-4.1

[Peter Green]

A debdiff is attatched, if I get no response I will likely NMU this when the
new rust-nix is uploaded to unstable.


As promised I have uploaded this.



During a rebuild of all packages in sid, your package failed to build
on arm64.


This fit the zero-day NMU guidelines, and my NMU would have FTBFS if I
didn't fix it. So I added a fix for is to the NMU.

Final debdiff is attatched.diff -Nru netavark-1.4.0/debian/changelog netavark-1.4.0/debian/changelog
--- netavark-1.4.0/debian/changelog 2023-09-06 22:46:22.0 +
+++ netavark-1.4.0/debian/changelog 2024-05-02 17:08:20.0 +
@@ -1,3 +1,11 @@
+netavark (1.4.0-4.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Apply upstream patch for new version of rust-nix (Closes: #1064580)
+  * Relax cargo dependency on sysctl crate (Closes: #1069350)
+
+ -- Peter Michael Green   Thu, 02 May 2024 17:08:20 +
+
 netavark (1.4.0-4) unstable; urgency=medium
 
   [ Peter Michael Green ]
diff -Nru netavark-1.4.0/debian/control netavark-1.4.0/debian/control
--- netavark-1.4.0/debian/control   2023-09-06 22:46:22.0 +
+++ netavark-1.4.0/debian/control   2024-05-02 16:54:53.0 +
@@ -18,7 +18,7 @@
  librust-libc-dev,
  librust-log-dev,
  librust-netlink-packet-route-0.17-dev,
- librust-nix-dev,
+ librust-nix-0.27-dev,
  librust-rand-dev,
  librust-rtnetlink-dev,
  librust-serde+derive-dev,
diff -Nru netavark-1.4.0/debian/patches/nix-0.27.patch 
netavark-1.4.0/debian/patches/nix-0.27.patch
--- netavark-1.4.0/debian/patches/nix-0.27.patch1970-01-01 
00:00:00.0 +
+++ netavark-1.4.0/debian/patches/nix-0.27.patch2024-05-02 
17:02:52.0 +
@@ -0,0 +1,42 @@
+This patch is based on the upstream commit described below, adapted for use
+in the Debian package by Peter Michael Green.
+
+commit 61b8e62f4205b1b2609054bb0d07771b56a5ef9c
+Author: Paul Holzinger 
+Date:   Mon Sep 11 18:13:13 2023 +0200
+
+bump nix to 0.27.1
+
+The nix crate removes all features by default so we need to explicitly
+list what we use.
+Second, the io API's changed and all use the AsFd trait now. This is
+great for IO safety but will require larger changes to migrate from
+RawFd. Thus I went the easy way and use unsafe (not really unsafe here)
+and construct and a new BorrowedFd object (which impl AsFd) for the
+setns call.
+
+Signed-off-by: Paul Holzinger 
+
+Index: netavark-1.4.0/Cargo.toml
+===
+--- netavark-1.4.0.orig/Cargo.toml
 netavark-1.4.0/Cargo.toml
+@@ -34,1 +34,1 @@ serde_json = "1"
+-nix = "0.26.1"
++nix = { version = "0.27.1", features = ["sched", "signal", "user", "fs"] }
+Index: netavark-1.4.0/src/network/core_utils.rs
+===
+--- netavark-1.4.0.orig/src/network/core_utils.rs
 netavark-1.4.0/src/network/core_utils.rs
+@@ -260,7 +260,10 @@ impl CoreUtils {
+ }
+ 
+ pub fn join_netns(fd: RawFd) -> NetavarkResult<()> {
+-match sched::setns(fd, sched::CloneFlags::CLONE_NEWNET) {
++match sched::setns(
++unsafe { BorrowedFd::borrow_raw(fd) },
++sched::CloneFlags::CLONE_NEWNET,
++) {
+ Ok(_) => Ok(()),
+ Err(e) => Err(NetavarkError::wrap(
+ "setns",
diff -Nru netavark-1.4.0/debian/patches/relax-deps.patch 
netavark-1.4.0/debian/patches/relax-deps.patch
--- netavark-1.4.0/debian/patches/relax-deps.patch  2023-09-06 
22:46:22.0 +
+++ netavark-1.4.0/debian/patches/relax-deps.patch  2024-05-02 
16:59:29.0 +
@@ -19,7 +19,7 @@
 +serde = { version = "1", features = ["derive"], optional = true }
 +serde-value = "0.7"
 +serde_json = "1"
-+sysctl = "0.4"
++sysctl = ">= 0.4"
  url = "2.3.1"
  zbus = { version = "3.6.1" }
  nix = "0.26.1"
diff -Nru netavark-1.4.0/debian/patches/series 
netavark-1.4.0/debian/patches/series
--- netavark-1.4.0/debian/patches/series2023-09-06 22:46:22.0 
+
+++ netavark-1.4.0/debian/patches/series2024-05-02 16:54:53.0 
+
@@ -3,3 +3,4 @@
 debian-paths.patch
 netlink-0.5.patch
 netlink-0.7.patch
+nix-0.27.patch

Bug#1064480: aardvark-dns - upcoming rust-nix update.

[Peter Green]

On 29/02/2024 12:22, Marc Dequènes (duck) wrote:


I do not have a proper Internet connexion in my new Pond yet so I'd gladly let you upload it :-). 

Done

Final debdiff is attatched.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-05-02 16:30:23.0 +
@@ -1,3 +1,11 @@
+greetd (0.9.0-6.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Add upstream patch for nix 0.27 (Closes: #1064480)
+  * Tighten build-dependency on nix.
+
+ -- Peter Michael Green   Thu, 02 May 2024 16:30:23 +
+
 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-05-02 16:26:04.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-05-02 16:26:04.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-05-02 
16:26:04.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-05-02 16:26:04.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.

[Peter Green]

if I get no response I will likely NMU this when the
new rust-nix is uploaded to unstable.


I have now uploaded rust-nix to unstable and uploaded
the nmu for this package.

Final debdiff is attatched (really this time)
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-05-02 16:14:54.0 +
@@ -1,3 +1,12 @@
+aardvark-dns (1.4.0-5.1) unstable; 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.
+(Closes: #1064479)
+
+ -- Peter Michael Green   Thu, 02 May 2024 16:14:54 +
+
 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-05-02 
16:14:43.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#1064479: aardvark-dns - upcoming rust-nix update.

[Peter Green]

if I get no response I will likely NMU this when the
new rust-nix is uploaded to unstable.


I have now uploaded rust-nix to unstable and uploaded
the nmu for this package.

Final debdiff is attatched.

Bug#1061435: lintian-brush ftbfs with updated pyo3 version

[Peter Green]

relaxing that in Cargo.toml to >= 0.19 lets the build succeed (and build 
with python3-defaults from experimental).


I was doing a test build of lintian brush to test I could build it
with the version of rust-distro-info I was preparing (now uploaded)
and ran into a couple of other issues.

Firstly there was a missing build-dependency on librust-pyo3-file-dev,
I added it.

Secondly in version 0.1.81, rust-breezyshim added an extra variant
"NoWhoami" to the "CommitError" enum, causing serveral match
statements to fail to build. I made a quick extension of the code
to accomodate this, but it could probablly do with some more
thinking about by someone with a better understanding of the code.

Finally I got test failures.


==
FAIL: fixer test: multiple-references for upstream-metadata-invalid
--
Traceback (most recent call last):
  File "/lintian-brush-0.152+nmu1/lintian_brush/tests/fixers.py", line 129, in 
runTest
raise AssertionError("unexpected output: %s" % diff.decode())
AssertionError: unexpected output: diff --no-dereference -x '*~' -ur 
/lintian-brush-0.152+nmu1/lintian_brush/tests/../../tests/upstream-metadata-invalid/multiple-references/out/debian/upstream/metadata
 /tmp/tmpbyzt2qq8/testdir/debian/upstre  am/metadata
--- 
/lintian-brush-0.152+nmu1/lintian_brush/tests/../../tests/upstream-metadata-invalid/multiple-references/out/debian/upstream/metadata
2023-10-28 00:41:32.0 +
+++ /tmp/tmpbyzt2qq8/testdir/debian/upstream/metadata   2024-04-27 
13:33:40.537269350 +
@@ -10,13 +10,15 @@
   Journal: LinuxUser
   Year: 2003
   Volume: 12
-  URL: 
https://www.linux-community.de/ausgaben/linuxuser/2003/12/woerterbuecher-und-textdateien-durchsuchen-mit-grafischem-frontend/
+  URL:
+
https://www.linux-community.de/ausgaben/linuxuser/2003/12/woerterbuecher-und-textdateien-durchsuchen-mit-grafischem-frontend/
 - Author: Michael Vogelbacher
   Title: Service und Informationen aus dem Netz
   Journal: LinuxUser
   Year: 2001
   Volume: 01
-  URL: 
https://www.linux-community.de/ausgaben/linuxuser/2001/01/service-und-informationen-aus-dem-netz/
+  URL: 
+https://www.linux-community.de/ausgaben/linuxuser/2001/01/service-und-informationen-aus-dem-netz/

 - Author: Redaktion pcmagazin
   Title: Ding - das Linuxlexikon
   Journal: PC Magazin



==
FAIL: fixer test: from-upstream-metadata for copyright-missing-upstream-info
--
Traceback (most recent call last):
  File "/lintian-brush-0.152+nmu1/lintian_brush/tests/fixers.py", line 108, in 
runTest
self.assertEqual(p.returncode, 0)
AssertionError: 1 != 0

==
FAIL: fixer test: meta.yml for upstream-metadata-file
--
Traceback (most recent call last):
  File "/lintian-brush-0.152+nmu1/lintian_brush/tests/fixers.py", line 108, in 
runTest
self.assertEqual(p.returncode, 0)
AssertionError: 1 != 0

==
FAIL: fixer test: cran for debian-watch-file-is-missing
--
Traceback (most recent call last):
  File "/lintian-brush-0.152+nmu1/lintian_brush/tests/fixers.py", line 108, in 
runTest
self.assertEqual(p.returncode, 0)
AssertionError: 1 != 0

--
Ran 796 tests in 80.565s

FAILED (failures=4, expected failures=1)


A debdiff is attached, which fixes the compile errors but not the test failures.
diff -Nru lintian-brush-0.152/Cargo.toml lintian-brush-0.152+nmu1/Cargo.toml
--- lintian-brush-0.152/Cargo.toml  2023-10-28 00:41:32.0 +
+++ lintian-brush-0.152+nmu1/Cargo.toml 2024-04-27 11:28:42.0 +
@@ -40,7 +40,7 @@
 
 [workspace.dependencies]
 breezyshim = "0.1.34"
-pyo3 = "0.19"
+pyo3 = ">=0.19"
 debversion = ">=0.1.8"
 serde_yaml = ">=0.8"
 reqwest = "0.11"
diff -Nru lintian-brush-0.152/debian/changelog 
lintian-brush-0.152+nmu1/debian/changelog
--- lintian-brush-0.152/debian/changelog2023-10-28 00:41:32.0 
+
+++ lintian-brush-0.152+nmu1/debian/changelog   2024-04-27 11:28:42.0 
+
@@ -1,3 +1,12 @@
+lintian-brush (0.152+nmu1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Relax cargo dependency on pyo3 crate (Closes: #106435)
+  * Add missing build-dependency on librust-pyo3-file-dev
+  * Fix build with newer versions of rust-breezyshim.
+
+ -- Peter Michael Green   Sat, 27 Apr 2024 11:28:42 +
+
 lintian-brush (0.152) unstable; urgency=medium
 
   * Fix compatibility with newer rust crates. Closes: #1054839
diff -Nru 

Bug#1069195: librust-prost-build-dev: FTBFS

[Peter Green]

Unsatisfiable build-dependency on librust-heck-0.5+default-dev



There seems to be an error here. the version of librust-prost-dev in sid
(build-)depends on librust-heck-0.4+default-dev.

The version in experimental does depend on librust-heck-0.5+default-dev
as it's first choice, but that's fine because version 0.5 of rust-heck
is available in experimental.

Bug#1069799: rust-multihash-derive-impl - (build-)depends unsatisfiable.

[Peter Green]

Package: rust-multihash-derive-impl
Version: 0.7.0-1
Severity: serious

rust-synstructure was recently updated to version 0.13.1

I tried bumping the dependency but that caused failures due to
mismatched versions of syn. Bumping the dependency on syn as well
resulted in.


error[E0609]: no field `tokens` on type ``
   --> src/multihash.rs:100:74
    |
100 | let attr: Result, _> = 
syn::parse2(attr.tokens.clone());
| ^^ unknown field
    |
    = note: available fields are: `pound_token`, `style`, `bracket_token`, 
`meta`

error[E0609]: no field `tokens` on type ``
   --> src/multihash.rs:141:82
    |
141 | let derive_attrs: Result, _> = 
syn::parse2(attr.tokens.clone());
| ^^ unknown field
    |
    = note: available fields are: `pound_token`, `style`, `bracket_token`, 
`meta`

error[E0061]: this method takes 2 arguments but 1 argument was supplied
   --> src/utils.rs:25:29
    |
25  | let attrs = content.parse_terminated(A::parse)?;
    | -- an argument is 
missing
    |


I'm also going to report this upstream.

Bug#1069798: rust-failure-derive - (build-)depends unsatisfiable.

[Peter Green]

Package: rust-failure-derive
Version: 0.1
Tags: trixie, sid
Severity: serious

rust-synstructure was recently updated to version 0.13.1

I tried bumping the dependency but that caused failures due to
mismatched versions of syn. Bumping the dependency on syn as well
resulted in.


error[E0433]: failed to resolve: could not find `NestedMeta` in `syn`
   --> src/lib.rs:129:18
    |
129 | syn::NestedMeta::Meta(syn::Meta::NameValue(ref nv)) if 
nv.path.is_ident("display") => {
    |  ^^ could not find `NestedMeta` in `syn`

error[E0433]: failed to resolve: could not find `NestedMeta` in `syn`
   --> src/lib.rs:140:18
    |
140 | syn::NestedMeta::Lit(syn::Lit::Int(ref i)) => {
    |  ^^ could not find `NestedMeta` in `syn`

error[E0433]: failed to resolve: could not find `NestedMeta` in `syn`
   --> src/lib.rs:144:18
    |
144 | syn::NestedMeta::Meta(syn::Meta::Path(ref path)) => {
    |  ^^ could not find `NestedMeta` in `syn`

error[E0433]: failed to resolve: could not find `NestedMeta` in `syn`
   --> src/lib.rs:252:39
    |
252 | if let 
&::NestedMeta::Meta(syn::Meta::Path(ref path)) = pair {
    |   ^^ could not find 
`NestedMeta` in `syn`

error[E0609]: no field `nested` on type `MetaList`
   --> src/lib.rs:121:16
    |
121 | if msg.nested.is_empty() {
    |    ^^ unknown field
    |
    = note: available fields are: `path`, `delimiter`, `tokens`

error[E0609]: no field `nested` on type `MetaList`
   --> src/lib.rs:128:39
    |
128 | let format_string = match msg.nested[0] {
    |   ^^ unknown field
    |
    = note: available fields are: `path`, `delimiter`, `tokens`

error[E0609]: no field `lit` on type ``
   --> src/lib.rs:130:20
    |
130 | nv.lit.clone()
    |    ^^^ unknown field
    |
    = note: available fields are: `path`, `eq_token`, `value`

error[E0609]: no field `nested` on type `MetaList`
   --> src/lib.rs:139:24
    |
139 | let args = msg.nested.iter().skip(1).map(|arg| match *arg {
    |    ^^ unknown field
    |
    = note: available fields are: `path`, `delimiter`, `tokens`

error[E0599]: no method named `parse_meta` found for reference `` in 
the current scope
   --> src/lib.rs:202:32
    |
202 | if let Ok(meta) = attr.parse_meta() {
    |    ^^ help: there is a method with a 
similar name: `parse_nested_meta`

error[E0599]: no method named `parse_meta` found for reference `` in 
the current scope
   --> src/lib.rs:242:32
    |
242 | if let Ok(meta) = attr.parse_meta() {
    |    ^^ help: there is a method with a 
similar name: `parse_nested_meta`

error[E0609]: no field `nested` on type ``
   --> src/lib.rs:251:50
    |
251 | if let Some(ref pair) = list.nested.first() {
    |  ^^ unknown field
    |
    = note: available fields are: `path`, `delimiter`, `tokens`


rust-failure has long been deprecated upstream, and rdeps have been gradually 
migrating away.
Looking at the remaining list of rdeps I see.

rust-assert-cli - no rdeps
rust-bendy - no rdeps
rust-coreutils - already broken and scheduled for autoremoval from testing soon
rust-distro-info - upstream has a patch switching to anyhow but hasn't yet 
included it in a release, only rdep is lintian-brush which is not in testing 
and already has a FTBFS bug.
rust-exitfailure - no rdeps
rust-include-dir-impl - no rdeps
rust-mdl - no rdeps
rust-rspotify - already broken and not in testing
rust-rustc-cfg - I have uploaded a new version of this that no longer depends 
on failure, and updated the rdeps to use it.

Bug#1069796: rust-abscissa-derive - (build-)depends unsatisfiable.

[Peter Green]

Package: rust-abscissa-derive
Version: 0.7.0-1
Severity: serious

rust-synstructure was recently updated to version 0.13.1

I tried bumping the dependency but that caused failures due to
mismatched versions of syn. Bumping the dependency on syn as well
resulted in.



error[E0432]: unresolved import `syn::NestedMeta`
 --> src/component.rs:5:60
  |
5 | use syn::{DeriveInput, Lit, Meta, MetaList, MetaNameValue, NestedMeta};
  |^^ no 
`NestedMeta` in the root

error[E0615]: attempted to take value of method `path` on type ``
  --> src/component.rs:56:22
   |
56 | if !attr.path.is_ident("component") {
   |   method, not a field
   |
help: use parentheses to call the method
   |
56 | if !attr.path().is_ident("component") {
   |  ++

error[E0599]: no method named `parse_meta` found for reference `` in 
the current scope
  --> src/component.rs:60:24
   |
60 | match attr.parse_meta().expect("error parsing meta") {
   |^^ help: there is a method with a similar 
name: `parse_nested_meta`

error[E0026]: struct `MetaList` does not have a field named `nested`
  --> src/component.rs:61:39
   |
61 | Meta::List(MetaList { nested, .. }) => {
   |   ^^ struct `MetaList` does not 
have this field

error[E0026]: struct `MetaNameValue` does not have a field named `lit`
   --> src/component.rs:135:17
|
135 | lit: Lit::Str(lit_str),
| ^^^ struct `MetaNameValue` does not have this field

Some errors have detailed explanations: E0026, E0432, E0599, E0615.


Since rust-abscissa-derive has no reverse dependencies I did not investigate 
further.

Bug#1068185: llvm-toolchain-16: FTBFS on armel: cxa_guard.cpp:(.text.unlikely.__cxa_guard_acquire+0xc): undefined reference to `__atomic_load_1'

[Peter Green]

Looking at the changelog, I see


Build with --as-needed.


I suspect this is responsible for the build failure on armel

Bug#1025912: rust-serde-yaml: please upgrade to v0.9

[Peter Green]

On 23/04/2024 15:52, Arnaud Ferraris wrote:

Hi,

On Thu, 27 Jul 2023 20:19:19 +0100 Peter Green  wrote:

> squeekboard - not investigated yet.

Tests fail after bumping dependency.

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1042405


I've just uploaded the new version of squeekboard to experimental, built using 
serde-yaml 0.9.

IIUC that was the last blocker, so feel free to upload to unstable whenever you 
see fit.


It looks like at least one new rdep has popped up, and it's a binary crate, so 
it this is
done now it will entangle itself with the time_t transition.

Will take a closer look when the time_t transition is over.

Bug#1067561: FTBFS: Error: symbol `open64' is already defined

[Peter Green]

On 14/04/2024 20:21, Yves-Alexis Perez wrote:

On Sat, 2024-04-13 at 16:11 +0100, Peter Green wrote:
>> Hi, thanks for the patch. It looks a bit strong though, undefining stuff
>> like
>> that unconditionally. Do you have pointers to the Ubuntu bug or something?
>> I've looked at upstream commits and issues and couldn't see anything
>> there.

> My understanding of the issue.

Hi Peter, thanks for the details. They really should be transmitted to the
upstream maintainer so I took the liberty to copy/paste it to the upstream bug
at https://github.com/canonical/lightdm/issues/352

Thanks, upstream has now accepted a patch that takes a slightly different
approach to fixing the issue.

https://github.com/canonical/lightdm/issues/352

Could we get this uploaded to sid, so that the lightweight desktops
are installable on armel/armhf again?

Bug#1069088: libvdeplug-slirp - dependencies unsatisfiable on 32-bit non-i386 architectures.

[Peter Green]

Package: libvdeplug-slirp
Version: 0.1.0-2
Tags: trixie, sid
Severity: grave
User: debian-...@lists.debian.org
Usertag: time-t

After being rebuilt for the time64 transition, libvdeplug-slirp
still depends on the pre-time64 libraries libvdeplug2 and
libvdeslirp0. It also depends on libvdeplug2t64. As a result
it is uninstallable on architectures that are undergoing
the time64 transition (armel, armhf and some debian-ports
architectures).

Ubuntu has already fixed this issue by removing the hardcoded
dependencies and adding code to debian/rules to calculate
a correct libvdeplug dependency.

http://launchpadlibrarian.net/721384619/vdeplug-slirp_0.1.0-2build1_0.1.0-2ubuntu1.diff.gz

Bug#1057565: state of kalzium package, and metapackage dependencies on it.

[Peter Green]

kalzium needs to be rebuilt for the time64 transition, but it has had
a FTBFS bug with no maintainer response for 4 months. The only reverse
dependencies seem to be a number of metapackages.

In particular, the kdeedu package is a key package and has a hard
dependency on kalzium. This means that it can't be autoremoved from
testing, making it a blocker the time64 transition.

Is there someone who can step up and fix kalzium? or should
it be dropped from the metapackages so it can be removed from testing?

Metapackages built from the meta-kde source (key, hard dependencies)

* kdeedu

Metapackages built from the debian-edu source (key, but only reccomends):

* education-chemistry
* education-highschool
* education-primaryschool
* education-secondaryschool

Metapackages built from the debian-science source (not key, only reccomends):

* science-chemistry

Metapackages built from the debichem source (not key, only reccomends):

* debichem-visualisation

Bug#1067561: FTBFS: Error: symbol `open64' is already defined

[Peter Green]

Hi, thanks for the patch. It looks a bit strong though, undefining stuff like
that unconditionally. Do you have pointers to the Ubuntu bug or something?
I've looked at upstream commits and issues and couldn't see anything there.


My understanding of the issue.

In glibc _FILE_OFFSET_BITS=64 is used to substitute the standard file
handling types and functions with versions that use 64-bit file
offsets. Similarly _TIME_BITS=64 is used to susbstitute time handling
types and functions with versions that use 64-bit seconds counts.

All of this only applies to 32-bit architectures, on 64-bit
architectures the default types in glibc are 64-bit.

The "time64" transition was implemented by defining _TIME_BITS=64 and
_FILE_OFFSET_BITS=64 by default in both dpkg-buildflags and the compiler.

That's fine for normal code, but tests/src/libsystem.c is not normal
code, it's a file of "test mocks" that override functions in glibc
for testing purposes. If _FILE_OFFSET_BITS=64 is defined, it ends up
trying to override "open64" twice, rather than trying to override both
"open" and "open64"

If we undef _FILE_OFFSET_BITS then we must also undef _TIME_BITS,
otherwise the glibc headers will refuse to compile.

So the patch seems reasonable to me, and since this is only test
code, it appears to be pretty low risk. We would appreciate having
this fix in unstable so the time_t transition can move forward.

Bug#1054795: system-config-printer: FTBFS: dh_install: error: missing files, aborting

[Peter Green]

Since there was no apparent maintainer response (the only responses were from
me and from one of the people working on the time64 transition) I went ahead
and uploaded a NMU'd with Ubuntu's fix.

Debdiff is attatched.
diff -Nru system-config-printer-1.5.18/debian/changelog 
system-config-printer-1.5.18/debian/changelog
--- system-config-printer-1.5.18/debian/changelog   2022-12-12 
21:04:11.0 +
+++ system-config-printer-1.5.18/debian/changelog   2024-04-12 
23:24:56.0 +
@@ -1,3 +1,11 @@
+system-config-printer (1.5.18-1.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix installation of cupshelpers module with Python 3.12. Patch taken from
+Ubuntu 1.5.18-1ubuntu6 upload by Till Kamppeter (Closes: #1054795).
+
+ -- Peter Michael Green   Fri, 12 Apr 2024 23:24:56 +
+
 system-config-printer (1.5.18-1) unstable; urgency=medium
 
   [ Jeremy Bicha ]
diff -Nru 
system-config-printer-1.5.18/debian/patches/makefile-am-fix-setup-py-install.patch
 
system-config-printer-1.5.18/debian/patches/makefile-am-fix-setup-py-install.patch
--- 
system-config-printer-1.5.18/debian/patches/makefile-am-fix-setup-py-install.patch
  1970-01-01 00:00:00.0 +
+++ 
system-config-printer-1.5.18/debian/patches/makefile-am-fix-setup-py-install.patch
  2024-04-12 23:03:53.0 +
@@ -0,0 +1,11 @@
+--- a/Makefile.am
 b/Makefile.am
+@@ -63,7 +63,7 @@
+ 
+ # Use distutils to install the module.
+ install-exec-local: .stamp-distutils-in-builddir
+-  $(PYTHON) setup.py install --prefix=$(DESTDIR)$(prefix)
++  $(PYTHON) setup.py install --root=$(DESTDIR) --prefix=$(prefix) 
--install-layout=deb
+ 
+ # Uninstall the module, crossing our fingers that we know enough
+ # about how distutils works to do this.  Unfortunately, distutils
diff -Nru system-config-printer-1.5.18/debian/patches/series 
system-config-printer-1.5.18/debian/patches/series
--- system-config-printer-1.5.18/debian/patches/series  2022-12-12 
21:04:11.0 +
+++ system-config-printer-1.5.18/debian/patches/series  2024-04-12 
23:05:12.0 +
@@ -3,3 +3,4 @@
 Allow-installing-packages-from-OpenPrinting.patch
 Do-not-autostart-the-applet-on-LXDE-or-Unity.patch
 Show-Printer-Settings-in-Unity-Control-Center.patch
+makefile-am-fix-setup-py-install.patch
diff -Nru system-config-printer-1.5.18/debian/python3-cupshelpers.install 
system-config-printer-1.5.18/debian/python3-cupshelpers.install
--- system-config-printer-1.5.18/debian/python3-cupshelpers.install 
2022-12-12 21:04:11.0 +
+++ system-config-printer-1.5.18/debian/python3-cupshelpers.install 
2024-04-12 23:03:53.0 +
@@ -1,5 +1,4 @@
 etc/cupshelpers/
-usr/lib/python3*/*-packages/cupshelpers
-usr/lib/python3*/*-packages/cupshelpers-1.0*.egg-info
+usr/lib/python3*/*-packages/cupshelpers*
 debug.py usr/lib/python3/dist-packages/cupshelpers/
 smburi.py usr/lib/python3/dist-packages/cupshelpers/

Bug#1068159: openjfx: FTBFS on arm{el,hf}: /usr/include/features-time64.h:26:5: error: #error "_TIME_BITS=64 is allowed only with _FILE_OFFSET_BITS=64"

[Peter Green]

Tags 1068159 +patch
Thanks

The build failure is caused by the following in
modules/javafx.media/src/main/native/gstreamer/gstreamer-lite/projects/build/linux/common/config.h

> /* Number of bits in a file offset, on hosts where this is settable. */
> #undef _FILE_OFFSET_BITS

Looking at the file, this looks like output from autotools that was
copied to become a static configuration file when code was vendored.

One option would be to remove this line completely, however to minimise
the risk of causing regressions on architectures not involved in the
time64 transition I choose instead to place it behind a #ifndef
guard.

> /* Number of bits in a file offset, on hosts where this is settable. */
> #ifndef _TIME_BITS
> # undef _FILE_OFFSET_BITS
> #endif

With this change, I was able to build the package successfully on
armhf.

Debdiff attached, if I get no response I will probablly NMU this
in a week or so.diff -Nru openjfx-11.0.11+1/debian/changelog openjfx-11.0.11+1/debian/changelog
--- openjfx-11.0.11+1/debian/changelog  2023-07-16 03:30:26.0 +
+++ openjfx-11.0.11+1/debian/changelog  2024-04-11 15:34:39.0 +
@@ -1,3 +1,10 @@
+openjfx (11.0.11+1-3.2) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Don't undefine _FILE_OFFSET_BITS if _TIME_BITS is set (Closes: #1068159)
+
+ -- root   Thu, 11 Apr 2024 15:34:39 +
+
 openjfx (11.0.11+1-3.1) unstable; urgency=medium
 
   * Team upload.
diff -Nru 
openjfx-11.0.11+1/debian/patches/40-dont-unset-file-offset-bits-if-time-bits-set.patch
 
openjfx-11.0.11+1/debian/patches/40-dont-unset-file-offset-bits-if-time-bits-set.patch
--- 
openjfx-11.0.11+1/debian/patches/40-dont-unset-file-offset-bits-if-time-bits-set.patch
  1970-01-01 00:00:00.0 +
+++ 
openjfx-11.0.11+1/debian/patches/40-dont-unset-file-offset-bits-if-time-bits-set.patch
  2024-04-11 15:34:39.0 +
@@ -0,0 +1,29 @@
+Description:  Don't undefine _FILE_OFFSET_BITS if _TIME_BITS is set.
+ Having _TIME_BITS set to 64 but _FILE_OFFSET_BITS not set on a 32-bit
+ architectureis not supported by glibc. As a result of this, unsetting
+ _FILE_OFFSET_BITS on a 32-bit architecture with 64-bit time causes a build
+ failure.
+ 
+ I suspect the unsetting of _FILE_OFFSET_BITS is a leftover from an
+ autogenerated file that became a static file rather than a deliberate
+ choice to override system settings.
+
+ I suspect that unsetting _FILE_OFFSET_BITS is unnessacery in general and the
+ line could be completely removed. However to minimise the risk of regressions
+ I instead used an ifndef gaurd
+Author: Peter Michael Green 
+Bug-Debian: https://bugs.debian.org/1068159
+
+--- 
openjfx-11.0.11+1.orig/modules/javafx.media/src/main/native/gstreamer/gstreamer-lite/projects/build/linux/common/config.h
 
openjfx-11.0.11+1/modules/javafx.media/src/main/native/gstreamer/gstreamer-lite/projects/build/linux/common/config.h
+@@ -544,7 +544,9 @@
+ #endif
+ 
+ /* Number of bits in a file offset, on hosts where this is settable. */
+-#undef _FILE_OFFSET_BITS
++#ifndef _TIME_BITS
++# undef _FILE_OFFSET_BITS
++#endif
+ 
+ /* Define to 1 to make fseeko visible on some hosts (e.g. glibc 2.2). */
+ #undef _LARGEFILE_SOURCE
diff -Nru openjfx-11.0.11+1/debian/patches/series 
openjfx-11.0.11+1/debian/patches/series
--- openjfx-11.0.11+1/debian/patches/series 2023-07-16 03:30:26.0 
+
+++ openjfx-11.0.11+1/debian/patches/series 2024-04-11 15:34:39.0 
+
@@ -21,3 +21,4 @@
 disable-ffmpeg.patch
 38-javadoc.patch
 webkit-217079-only-use-jumpislands-with-JIT.patch
+40-dont-unset-file-offset-bits-if-time-bits-set.patch

Bug#1066134: ppp: FTBFS due -Werror=implicit-function-declaration

[peter green]

block 1036884 by 1066134
tags 1066134 +patch
thanks

Hi.

The build failure of ppp in unstable is a blocker for the time_t
transition, since ppp needs to be rebuilt against the new versions
of libpcap and openssl. The version in experimental seems to build fine.

Can you fix this, either by adding a backported patch (see
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1066134#12 ),
or by uploading the version in experimental to unstable? or would
you prefer that someone prepares a NMU?

Bug#1068696: haskell-hourglass FTBFS on armel and armhf

[Peter Green]

Package: haskell-hourglass
Version: 0.2.15-5
Severity: serious
User: debian-...@lists.debian.org
Usertag: time-t

The recent binnmus of haskell-hourglass on armel and armhf
failed to build with test failures.


calendar: FAIL
  *** Failed! (after 44 tests):
  Exception:
expected: -10088515868s got: -1498581276s
CallStack (from HasCallStack):
  error, called at tests/Tests.hs:120:25 in main:Main
  -10088515868s
  Use --quickcheck-replay=164206 to reproduce.
  Use -p '/calendar/' to rerun this test only.





iso8601 date: FAIL
  *** Failed! (after 42 tests):
  Exception:
expected: "2085-11-16" got: "1949-10-11"
CallStack (from HasCallStack):
  error, called at tests/Tests.hs:120:25 in main:Main
  3656792852s
  Use --quickcheck-replay=277582 to reproduce.
  Use -p '/formating.iso8601 date/' to rerun this test only.





custom-1: FAIL
  *** Failed! (after 2 tests):
  Exception:
expected: DateTime {dtDate = Date {dateYear = 2081, dateMonth = 
December, dateDay = 8}, dtTime = TimeOfDay {todHour = 13h, todMin = 59m, todSec 
= 21s, todNSec = 24752790ns}} got: DateTime {dtDate = Date {dateYear = 1945, 
dateMonth = November, dateDay = 2}, dtTime = TimeOfDay {todHour = 7h, todMin = 
31m, todSec = 5s, todNSec = 24752790ns}}
CallStack (from HasCallStack):
  error, called at tests/Tests.hs:120:25 in main:Main
  DateTime {dtDate = Date {dateYear = 2081, dateMonth = December, dateDay = 
8}, dtTime = TimeOfDay {todHour = 13h, todMin = 59m, todSec = 21s, todNSec = 
24752790ns}}
  Use --quickcheck-replay=893847 to reproduce.
  Use -p '/custom-1/' to rerun this test only.
custom-2: FAIL
  *** Failed! (after 1 test):
  Exception:
expected: DateTime {dtDate = Date {dateYear = 2132, dateMonth = August, 
dateDay = 11}, dtTime = TimeOfDay {todHour = 16h, todMin = 38m, todSec = 47s, 
todNSec = 5036393ns}} got: DateTime {dtDate = Date {dateYear = 1996, dateMonth 
= July, dateDay = 5}, dtTime = TimeOfDay {todHour = 10h, todMin = 10m, todSec = 
31s, todNSec = 5036393ns}}
CallStack (from HasCallStack):
  error, called at tests/Tests.hs:120:25 in main:Main
  DateTime {dtDate = Date {dateYear = 2132, dateMonth = August, dateDay = 
11}, dtTime = TimeOfDay {todHour = 16h, todMin = 38m, todSec = 47s, todNSec = 
5036393ns}}
  Use --quickcheck-replay=738259 to reproduce.
  Use -p '/custom-2/' to rerun this test only.
  Regression Tests
Real instance of ElapsedP (#33):  OK
Real instance of ElapsedP (#33) (2):  OK

4 out of 21 tests failed (0.03s)



I strongly suspect this is related to the time64 transition.

Bug#1054795: system-config-printer: FTBFS: dh_install: error: missing files, aborting

[Peter Green]

Ubuntu has made a couple of changes that look like they may relate to this 
issue.

Changelog for version 1.5.18-1ubuntu6 says

"Fix installation of cupshelpers module with Python 3.12."

Changelog for version 1.5.18-1ubuntu7 says

"Drop build dependency on python3-distutils."

Diffs are available at

http://launchpadlibrarian.net/720405816/system-config-printer_1.5.18-1ubuntu5_1.5.18-1ubuntu6.diff.gz

http://launchpadlibrarian.net/720655573/system-config-printer_1.5.18-1ubuntu6_1.5.18-1ubuntu7.diff.gz

Can someone review whether these changes are appropriate and fix the issue?
system-config-printer is a blocker for the time_t transition.

Bug#1068689: urfkill dependencies unsatisfiable on 32-bit non-i386 architectures.

[Peter Green]

Package: urfkill
Version: 0.5.0-7.1
Tags: trixie, sid
Severity: grave
User: debian-...@lists.debian.org
Usertag: time-t

After being rebuilt for the time64 transition, urfkill
depends on both libglib2.0-0 and libglib2.0-0t64. As a
result it is uninstallable on architectures that are undergoing
the time64 transition (armel, armhf and some debian-ports
architectures).

Ubuntu has already fixed this issue by removing the hardcoded
dependency on libglib2.0-0.

http://launchpadlibrarian.net/720796799/urfkill_0.6.0~20150318.103828.5539c0d.1-0ubuntu10_0.6.0~20150318.103828.5539c0d.1-0ubuntu11.diff.gz

Bug#1068688: tpm2-initramfs-tool dependencies unsatisfiable on 32-bit non-i386 architectures.

[Peter Green]

Package: tpm2-initramfs-tool
Version: 1.0.1-1
Tags: trixie, sid
Severity: grave
User: debian-...@lists.debian.org
Usertag: time-t

After being rebuilt for the time64 transition, tpm2-initramfs-tool
depends on both libtss2-esys-3.0.2-0 and libtss2-esys-3.0.2-0t64. As a
result it is uninstallable on architectures that are undergoing
the time64 transition (armel, armhf and some debian-ports
architectures).

Ubuntu has already fixed this issue by replacing the hardcoded
dependency on libtss2-esys-3.0.2-0 with code in debian/rules
that generates a dependency (not sure why they didn't just
remove it).

http://launchpadlibrarian.net/720835666/tpm2-initramfs-tool_0.2.2-2build1_0.2.2-2ubuntu1.diff.gz

Bug#1068526: samba-dsdb-modules dependencies unsatisfiable on 32-bit non-i386 architectures.

[Peter Green]

Package: samba-dsdb-modules
Version: 2:4.19.5+dfsg-4
Tags: trixie, sid
Severity: grave
User: debian-...@lists.debian.org
Usertag: time-t

After being rebuilt for the time64 transition, samba-dsdb-modules
depends on both libgpgme11 and libgpgme11t64. As a
result it is uninstallable on architectures that are undergoing
the time64 transition (armel, armhf and some debian-ports
architectures).

Ubuntu has already fixed this issue by removing the hardcoded
dependency on libgpgme11

http://launchpadlibrarian.net/720831431/riseup-vpn_0.21.11+ds1-5build3_0.21.11+ds1-5ubuntu1.diff.gz

While poking through the ubuntu changelog, I noticed another
change that looks relavent (but non-rc)

http://launchpadlibrarian.net/720831431/riseup-vpn_0.21.11+ds1-5build3_0.21.11+ds1-5ubuntu1.diff.gz

Bug#1068433: riseup-vpn dependencies unsatisfiable on 32-bit non-i386 architectures.

[Peter Green]

Package: riseup-vpn
Version: 0.21.11+ds1-5
Tags: trixie, sid
Severity: grave
User: debian-...@lists.debian.org
Usertag: time-t

After being rebuilt for the time64 transition, riseup-vpn
depends on both libqt5widgets5 and libqt5widgets5t64. As a
result it is uninstallable on architectures that are undergoing
the time64 transition (armel, armhf and some debian-ports
architectures).

Ubuntu has already fixed this issue by removing the hardcoded
dependency on shared libraries.

http://launchpadlibrarian.net/720831431/riseup-vpn_0.21.11+ds1-5build3_0.21.11+ds1-5ubuntu1.diff.gz

Bug#1068432: reapr dependencies unsatisfiable on 32-bit non-i386 architectures.

[Peter Green]

Package: reapr
Version: 1.0.18+dfsg-5
Tags: trixie, sid
Severity: grave
User: debian-...@lists.debian.org
Usertag: time-t

After being rebuilt for the time64 transition, reapr
depends on both libtabixpp0 and libtabixpp0t64. As a
result it is uninstallable on architectures that are undergoing
the time64 transition (armel, armhf and some debian-ports
architectures).

Ubuntu has already fixed this issue by removing the hardcoded
dependency on libtabixpp0.

http://launchpadlibrarian.net/721505761/reapr_1.0.18+dfsg-5build2_1.0.18+dfsg-5ubuntu1.diff.gz

Bug#1068431: rakarrack dependencies unsatisfiable on 32-bit non-i386 architectures.

[Peter Green]

Package: rakarrack
Version: 0.6.1-8
Tags: trixie, sid
Severity: grave
User: debian-...@lists.debian.org
Usertag: time-t

After being rebuilt for the time64 transition, rakarrack
depends on both libasound2 and libasound2t64. As a
result it is uninstallable on architectures that are undergoing
the time64 transition (armel, armhf and some debian-ports
architectures).

Bug#1068430: libqt5-ukui-style1 dependencies unsatisfiable on 32-bit non-i386 architectures.

[Peter Green]

Package: libqt5-ukui-style1
Version: 1.0.8-1
Tags: trixie, sid
Severity: grave
User: debian-...@lists.debian.org
Usertag: time-t

After being rebuilt for the time64 transition, libqt5-ukui-style1
depends on both libqt5widgets5 and libqt5widgets5. As a
result it is uninstallable on architectures that are undergoing
the time64 transition (armel, armhf and some debian-ports
architectures).

Ubuntu appear to have already fixed this.

http://launchpadlibrarian.net/721518881/qt5-ukui-platformtheme_1.0.8-1build9_1.0.8-1ubuntu1.diff.gz

Bug#1068424: populations - still depends on old libqt5gui5 after binnmu

[Peter Green]

Package: populations
Version: 1.2.33+svn0120106+dfsg-6
Severity: grave
Tags: trixie, sid
User: debian-...@lists.debian.org
Usertag: time-t

After being rebuilt for the time64 transition,
populations still depends on libqt5xml5,
rather than libqt5xml5t64. As a result it is uninstallable on
architectures that are undergoing the time64 transition
(armel, armhf and some debian-ports architectures).

Ubuntu has applied a fix for this.

https://launchpadlibrarian.net/721519148/populations_1.2.33+svn0120106+dfsg-6_1.2.33+svn0120106+dfsg-6ubuntu2.diff.gz

Bug#1068420: pidgin-gnome-keyring - still depends on old libpurple after binnmu

[Peter Green]

Package: pidgin-gnome-keyring
Version: 2.0-2
Severity: grave
Tags: trixie, sid
User: debian-...@lists.debian.org
Usertag: time-t

After being rebuilt for the time64 transition,
obs-advanced-scene-switcher still depends on libpurple0,
rather than libpurple0t64. As a result it is uninstallable on
architectures that are undergoing the time64 transition
(armel, armhf and some debian-ports architectures).

Ubuntu has applied a fix for this.

https://launchpadlibrarian.net/721511958/pidgin-gnome-keyring_2.0-2_2.0-2ubuntu1.diff.gz

Bug#1068419: perdition: dependencies unsatisfiable after binnmu for time64 transition.

[Peter Green]

Package: perdition
Version: 2.2-3.3
Severity: grave
User: debian-...@lists.debian.org
Usertag: time-t

After being rebuilt for the time64 transition, perdition
depends on both libvanessa-socket2 and libvanessa-socket2.
As a result it is uninstallable.

Interesting in this case, the uninstallability seems to apply
to all architectures and not just those undergoing the
time64 transition.

Bug#1068414: obs-advanced-scene-switcher - still depends on old libcurl after binnmu

[Peter Green]

Package: obs-advances-scene-switcher
Version: 1.23.1-2
Severity: grave
User: debian-...@lists.debian.org
Usertag: time-t

After being rebuilt for the time64 transition,
obs-advanced-scene-switcher still depends on libcurl4,
rather than libcurl4t64. As a result it is uninstallable on
architectures that are undergoing the time64 transition
(armel, armhf and some debian-ports architectures).

Ubuntu has applied a fix for this.

https://launchpadlibrarian.net/720928573/obs-advanced-scene-switcher_1.23.1-2build2_1.23.1-2ubuntu1.diff.gz

Bug#1065980: gfarm: FTBFS on arm{el,hf}:

[Peter Green]

tags 1065980 +patch
thanks

This build failure was caused by missing "feature test macros" meaning that
the relevant functions were not enabled in the system headers.

A debdiff adding them is attached.diff -Nru gfarm-2.7.20+dfsg/debian/changelog gfarm-2.7.20+dfsg/debian/changelog
--- gfarm-2.7.20+dfsg/debian/changelog  2024-02-28 17:35:22.0 +
+++ gfarm-2.7.20+dfsg/debian/changelog  2024-04-04 04:41:24.0 +
@@ -1,3 +1,11 @@
+gfarm (2.7.20+dfsg-1.2) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Add include of unistd.h to lib/libgfarm/gfarm/gfp_xdr.c to fix
+implicit declaration error.
+
+ -- Peter Michael Green   Thu, 04 Apr 2024 04:41:24 +
+
 gfarm (2.7.20+dfsg-1.1) unstable; urgency=medium
 
   * Non-maintainer upload.
diff -Nru gfarm-2.7.20+dfsg/debian/patches/missing-feature-test-macros.patch 
gfarm-2.7.20+dfsg/debian/patches/missing-feature-test-macros.patch
--- gfarm-2.7.20+dfsg/debian/patches/missing-feature-test-macros.patch  
1970-01-01 00:00:00.0 +
+++ gfarm-2.7.20+dfsg/debian/patches/missing-feature-test-macros.patch  
2024-04-04 04:41:24.0 +
@@ -0,0 +1,173 @@
+Index: gfarm-2.7.20+dfsg/lib/libgfarm/gfarm/gfp_xdr.c
+===
+--- gfarm-2.7.20+dfsg.orig/lib/libgfarm/gfarm/gfp_xdr.c
 gfarm-2.7.20+dfsg/lib/libgfarm/gfarm/gfp_xdr.c
+@@ -1,3 +1,4 @@
++#define _XOPEN_SOURCE 500
+ #include 
+ #include 
+ #include 
+Index: 
gfarm-2.7.20+dfsg/bench/gfperf/gfperf-autoreplica/gfperf-autoreplica-main.c
+===
+--- 
gfarm-2.7.20+dfsg.orig/bench/gfperf/gfperf-autoreplica/gfperf-autoreplica-main.c
 gfarm-2.7.20+dfsg/bench/gfperf/gfperf-autoreplica/gfperf-autoreplica-main.c
+@@ -2,6 +2,7 @@
+  * $Id$
+  */
+ 
++#define _GNU_SOURCE
+ #include "gfperf-lib.h"
+ #include 
+ #include 
+Index: gfarm-2.7.20+dfsg/bench/gfperf/gfperf-copy/gfperf-copy-gfarm2fs.c
+===
+--- gfarm-2.7.20+dfsg.orig/bench/gfperf/gfperf-copy/gfperf-copy-gfarm2fs.c
 gfarm-2.7.20+dfsg/bench/gfperf/gfperf-copy/gfperf-copy-gfarm2fs.c
+@@ -2,7 +2,7 @@
+  * $Id$
+  */
+ 
+-
++#define _GNU_SOURCE
+ #include 
+ #include 
+ #include 
+Index: gfarm-2.7.20+dfsg/bench/gfperf/gfperf-copy/gfperf-copy-main.c
+===
+--- gfarm-2.7.20+dfsg.orig/bench/gfperf/gfperf-copy/gfperf-copy-main.c
 gfarm-2.7.20+dfsg/bench/gfperf/gfperf-copy/gfperf-copy-main.c
+@@ -2,7 +2,7 @@
+  * $Id$
+  */
+ 
+-
++#define _GNU_SOURCE
+ #include "gfperf-lib.h"
+ #include 
+ #include 
+Index: gfarm-2.7.20+dfsg/bench/gfperf/gfperf-lib/gfperf-util.c
+===
+--- gfarm-2.7.20+dfsg.orig/bench/gfperf/gfperf-lib/gfperf-util.c
 gfarm-2.7.20+dfsg/bench/gfperf/gfperf-lib/gfperf-util.c
+@@ -2,7 +2,8 @@
+  * $Id$
+  */
+ 
+-
++#define _DEFAULT_SOURCE
++#define _XOPEN_SOURCE 500
+ #include 
+ #include 
+ #include 
+Index: gfarm-2.7.20+dfsg/bench/gfperf/gfperf-metadata/gfperf-metadata-main.c
+===
+--- gfarm-2.7.20+dfsg.orig/bench/gfperf/gfperf-metadata/gfperf-metadata-main.c
 gfarm-2.7.20+dfsg/bench/gfperf/gfperf-metadata/gfperf-metadata-main.c
+@@ -2,7 +2,7 @@
+  * $Id$
+  */
+ 
+-
++#define _GNU_SOURCE
+ #include "gfperf-lib.h"
+ #include 
+ #include 
+Index: 
gfarm-2.7.20+dfsg/bench/gfperf/gfperf-parallel-read/gfperf-parallel-read-main.c
+===
+--- 
gfarm-2.7.20+dfsg.orig/bench/gfperf/gfperf-parallel-read/gfperf-parallel-read-main.c
 
gfarm-2.7.20+dfsg/bench/gfperf/gfperf-parallel-read/gfperf-parallel-read-main.c
+@@ -3,6 +3,7 @@
+  */
+ 
+ 
++#define _GNU_SOURCE
+ #include "gfperf-lib.h"
+ #include 
+ #include 
+Index: 
gfarm-2.7.20+dfsg/bench/gfperf/gfperf-parallel-write/gfperf-parallel-write-main.c
+===
+--- 
gfarm-2.7.20+dfsg.orig/bench/gfperf/gfperf-parallel-write/gfperf-parallel-write-main.c
 
gfarm-2.7.20+dfsg/bench/gfperf/gfperf-parallel-write/gfperf-parallel-write-main.c
+@@ -3,6 +3,7 @@
+  */
+ 
+ 
++#define _GNU_SOURCE
+ #include "gfperf-lib.h"
+ #include 
+ #include 
+Index: gfarm-2.7.20+dfsg/bench/gfperf/gfperf-read/gfperf-read-main.c
+===
+--- gfarm-2.7.20+dfsg.orig/bench/gfperf/gfperf-read/gfperf-read-main.c
 gfarm-2.7.20+dfsg/bench/gfperf/gfperf-read/gfperf-read-main.c
+@@ -2,7 +2,7 @@
+  * $Id$
+  */
+ 
+-
++#define _GNU_SOURCE
+ #include "gfperf-lib.h"
+ #include 
+ #include 
+Index: gfarm-2.7.20+dfsg/bench/gfperf/gfperf-replica/gfperf-replica-main.c
+===
+--- gfarm-2.7.20+dfsg.orig/bench/gfperf/gfperf-replica/gfperf-replica-main.c
 

Bug#1068404: mariadb-plugin-s3 dependencies unsatisfiable on 32-bit non-i386 architectures.

[Peter Green]

Package: mariadb-plugin-s3
Version: 1:10.11.7-3
Severity: grave
User: debian-...@lists.debian.org
Usertag: time-t

After being rebuilt for the time64 transition, mariadb-plugin-s3
depends on both libcurl4 and libcurl4t64. As a
result it is uninstallable on architectures that are undergoing
the time64 transition (armel, armhf and some debian-ports
architectures).

Bug#1068403: mariadb-plugin-hashicorp-key-management dependencies unsatisfiable on 32-bit non-i386 architectures.

[Peter Green]

Package: mariadb-plugin-hashicorp-key-management
Version: 1:10.11.7-3
Severity: grave
User: debian-...@lists.debian.org
Usertag: time-t

After being rebuilt for the time64 transition, 
mariadb-plugin-hashicorp-key-management
depends on both libcurl4 and libcurl4t64. As a
result it is uninstallable on architectures that are undergoing
the time64 transition (armel, armhf and some debian-ports
architectures).

Bug#1068402: lua-lxc dependencies unsatisfiable on 32-bit non-i386 architectures.

[Peter Green]

Package: lua-lxc
Version: 1:3.0.2-2
Severity: grave
User: debian-...@lists.debian.org
Usertag: time-t

After being rebuilt for the time64 transition, lua-lxc
depends on both liblxc1 and libliblxc1t64. As a
result it is uninstallable on architectures that are undergoing
the time64 transition (armel, armhf and some debian-ports
architectures).

Bug#1068401: ltrsift dependencies unsatisfiable on 32-bit non-i386 architectures.

[Peter Green]

Package: ltrsift
Version: 1.0.2-9
Severity: grave
User: debian-...@lists.debian.org
Usertag: time-t

After being rebuilt for the time64 transition, ltrsift
depends on both libgenometools0 and libgenometools0t64. As a
result it is uninstallable on architectures that are undergoing
the time64 transition (armel, armhf and some debian-ports
architectures).

Ubuntu seem to have already fixed this.

https://launchpadlibrarian.net/720967127/ltrsift_1.0.2-9build5_1.0.2-9ubuntu1.diff.gz

Bug#1068400: lomiri-filemanager-app dependencies unsatisfiable on 32-bit non-i386 architectures.

[Peter Green]

Package: lomiri-filemanager-app
Version: 1.0.4+dfsg-1
Severity: grave
User: debian-...@lists.debian.org
Usertag: time-t

After being rebuilt for the time64 transition, lomiri-filemanager-app
depends on both libsmbclient and libsmbclient0. As a
result it is uninstallable on architectures that are undergoing
the time64 transition (armel, armhf and some debian-ports
architectures).

Ubuntu seem to have already fixed this.

https://launchpadlibrarian.net/721510452/lomiri-filemanager-app_1.0.4+dfsg-1_1.0.4+dfsg-1ubuntu2.diff.gz

Bug#1068399: lomiri-system-settings - uninstallable on armel, armhf and mips64el due to depends/build-depends cycles.

[Peter Green]

Package: lomiri-system-settings
Version: 1.1.0-2
Severity: grave

lomiri-system-settings depends on lomiri-system-settings-security-privacy, which
is not availble on armel, armhf or mips64el.

The reason, or at least one reason, it is not available is because
lomiri-system-settings-security-privacy build-depends on lomiri-system-settings.

Bug#1068398: qml-module-lomiri-components-extras dependencies unsatisfiable on 32-bit non-i386 architectures.

[Peter Green]

Package: qml-module-lomiri-components-extrasVersion: 0.10.0-5
Severity: grave
User: debian-...@lists.debian.org
Usertag: time-t

After being rebuilt for the time64 transition, 
qml-module-lomiri-components-extras
depends on both libqt5printsupport5 and libqt5printsupport5t64. As a
result it is uninstallable on architectures that are undergoing
the time64 transition (armel, armhf and some debian-ports
architectures).

Bug#1068371: indi-apogee dependencies unsatisfiable on 32-bit non-i386 architectures.

[Peter Green]

Package: indi-apogee
Version: 0.10.0-5
Severity: grave
User: debian-...@lists.debian.org
Usertag: time-t

After being rebuilt for the time64 transition, indi-apogee depends
on both libapogee3 and libapogee3t64. As a
result it is uninstallable on architectures that are undergoing
the time64 transition (armel, armhf and some debian-ports
architectures).

Bug#1068361: gpa, dependencies unsatisfiable on 32-bit non-i386 architectures.

[Peter Green]

Package: gpa
Version: 0.10.0-5
Severity: grave
User: debian-...@lists.debian.org
Usertag: time-t

After being rebuilt for the time64 transition, gpa depends
on both libgpgme11 and libgpg11t64. As a
result it is uninstallable on architectures that are undergoing
the time64 transition (armel, armhf and some debian-ports
archictures).

Ubuntu fixed this by removing the hardcoded dependency
and relying on shlibs

https://launchpadlibrarian.net/720869650/gpa_0.10.0-5build3_0.10.0-5ubuntu1.diff.gz

Bug#1068359: gir1.2-keybinder-0.0 still depends on libkeybinder0 on most architectures.

[Peter Green]

Package: gir1.2-keybinder-0.0
Version: 0.3.1-2.3
Severity: grave
User: debian-...@lists.debian.org
Usertag: time-t

libkeybinder0 has been renamed to libkeybinder0t64, however gir1.2keybinder0.0
still depends on the former on most architectures. As a result it is
uninstallable on architectures subject to the time64 transition (armel, armhf
and several debian-ports architectures).

I see the following lines in debian/control which look like they may be
related.


override_dh_makeshlibs:
dh_makeshlibs -V 'libkeybinder0 (>= 0.3.0)'


What I don't get though is that on amd64 the package seems to have picked
up the correct dependency.

Bug#1068068: bobcat, time_t transition lead to apparent ABI break (was: Need rebootstrapping on armel and armhf).

[Peter Green]

Also, the bootstrapping procedure is only required when icmake isn't avaialble
yet. For the construction of the bobcat library icmake 11.01.02-1 is required,
and icmake.01.02-1 needs libbobcat-dev >= 5.07.00, which is available since
bullseye (oldstable).

So maybe you can also provide some info about why the bootstrapping procedure
is needed/used?

When doing the time64 transition, it was decided to change the
package names, but *not* the sonames. This avoids soname
divergence from upstream but also means that the old (pre-time64)
and new (post time64) packages cannot be co-installed, at least
not without hacks.

Note that this only affects architectures that are actually
undergoing the time64 changes (that is 32-bit architectures
other than i386). On other architectures some "provides"
trickery is used to avoid the need for a hard transition.

This is why some form of manual intervention was needed, the
dev packages for readline/openssl depend on the "t64" version
of those libraries while the libbobcat6 package depended
on the "non-t64" version of those libraries. icmake depends on
libbobcat6, which lead to the following when trying to binnmu
bobcat for the time64 transition.

bobcat build-depends on:
-icmake  :armel 
(>= 10.06.00)
icmake    
depends on:
- libbobcat6:armel (>= 6.04.00)
libbobcat6 depends on:
-libssl3  :armel 
(>= 3.0.0)
libssl3t64 conflicts with:
-libssl3  :armel 
(< 3.1.5-1.1)

That said, in such cases it is usually not nessacery to re-bootstrap
from scratch. Usually it is possible to force install the old packages
and they will work "well enough" to build the new packages. I was
able to re-build bobcat against the new readline and libssl with the
following approach.

1. Install all the build-dependencies of bobcat except icmake normally.
2. Forcibly install the old icmake and libbobcat6
3. Build bobcat.

I did so, and uploaded the resulting bobcat packages for armel and
armhf (as +b1). This make bobcat's build-dependencies installable again
and allowed the buildds to attempt to build binnmus of bobcat

Unfortunately, those builds failed with a segmentation fault. It appears
icmake is crashing when run with the new libbobcat6 package.

Presumably this means that, while it was not identified in pre-transition
planning, bobcat's ABI has changed as a result of the time64 transition
and libbobcat6 will need to be renamed to libbobcat6t64.

Bug#1067906: qtwebengine-opensource-src - FTBFS on armhf.

[Peter Green]

Package: qtwebengine-opensource-src
Version: 5.15.15+dfsg-2
Severity: serious

qtwebengine-opensource-src failed to build on armhf when binnmu'd for the time_t
transition due to symbol changes.
(qtwebengine does not support any of the other architectures affected by
the time64 transition.

grep MISSING qtwebengine-opensource-src.log | grep -v optional
+#MISSING: 5.15.15+dfsg-2+b3# 
_ZN15QtWebEngineCore14ProfileAdapter21determineDownloadPathERK7QStringS3_RKl@Qt_5
 5.14.1
+#MISSING: 5.15.15+dfsg-2+b3# _ZN7sandbox18localtime_overrideEPKl@Qt_5 5.12.2
+#MISSING: 5.15.15+dfsg-2+b3# _ZN7sandbox20localtime64_overrideEPKl@Qt_5 5.12.2
+#MISSING: 5.15.15+dfsg-2+b3# _ZN7sandbox20localtime_r_overrideEPKlP2tm@Qt_5 
5.12.2
+#MISSING: 5.15.15+dfsg-2+b3# _ZN7sandbox22localtime64_r_overrideEPKlP2tm@Qt_5 
5.12.2

Bug#1067898: atril, dependencies unsatisfiable on 32-bit non-i386 architectures.

[Peter Green]

Package: atril
Version: 1.26.2-2
Severity: serious

The latest version of atril depends on both libatrildocument3 and
libatrildocument3t64. As a result it is uninstallable on
architectures that are undergoing the time64 transition
(armel, armhf and some debian-ports archictures).

Bug#1067897: rust-coreutils - FTBFS with new rust-uutils-term-grid.

[Peter Green]

Package: rust-coreutils
Version: 0.0.24-2
Severity: serious

rust-coreutils FTBFS with the new version of rust-uutils-term-grid.
The Debian build-dependency allows the new version, but the Cargo
dependency does not.

After bumping the cargo dependency, the code fails to build with a
bunch of errors.


error[E0432]: unresolved import `term_grid::Cell`
  --> src/uu/ls/src/ls.rs:37:17
   |
37 | use term_grid::{Cell, Direction, Filling, Grid, GridOptions};
   |  no `Cell` in the root
   |
   = help: consider importing one of these items instead:
   std::cell::Cell
   core::cell::Cell
error[E0063]: missing field `width` in initializer of `GridOptions`
--> src/uu/ls/src/ls.rs:2598:34
 |
2598 | let mut grid = Grid::new(GridOptions { filling, direction });
 |  ^^^ missing `width`

error[E0061]: this function takes 2 arguments but 1 argument was supplied
--> src/uu/ls/src/ls.rs:2598:24
 |
2598 | let mut grid = Grid::new(GridOptions { filling, direction });
 |^ -- an 
argument of type `Vec<_>` is missing
error[E0599]: no method named `add` found for struct `Grid` in the current scope
--> src/uu/ls/src/ls.rs:2609:18
 |
2609 | grid.add(formatted_name);
 |  ^^^ method not found in `Grid<_>`

error[E0599]: no method named `fit_into_width` found for struct `Grid` in the 
current scope
--> src/uu/ls/src/ls.rs:2612:20
 |
2612 | match grid.fit_into_width(width as usize) {
 |^^ method not found in `Grid<_>`

error[E0599]: no method named `fit_into_columns` found for struct `Grid` in the 
current scope
--> src/uu/ls/src/ls.rs:2618:40
 |
2618 | write!(out, "{}", grid.fit_into_columns(1))?;
 | method not found in 
`Grid<_>`

Bug#1066794: consider retrying git binnmus.

[Peter Green]

git failed to build when binnmu'd for the time64 transition and also
in lucas's test build a few days earlier. This was filed as bug 1066794.

Andrey Rakhmatullin responded to the bug report saying he was unable to
reproduce the failure. Michael Hudson replied with a post suggesting
that the failure may be related to libcgi-pm-perl, though he did not
make it clear which version of libcgi-pm-perl he was testing with.

Andrey noted that the version of libcgi-pm-perl in his local tests was
newer than the version used in the failed builds.

Ubuntu temporally disabled tests in git, but have since re-enabled
them, and the package built successfully on all Ubuntu architectures.

I would suggest therefore that it makes sense to retry the binnmus
as there is a good chance that whatever caused the issue has since
been fixed.

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

[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

[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"

[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

[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

[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

[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

[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

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

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

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

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

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

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

[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

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

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

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

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

[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`

[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

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

[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

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

[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

[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

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

[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

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

[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

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

[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

[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

[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

[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

[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

[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

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

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

[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

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

[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

[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

[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

[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

[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

[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

[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