Bug#1082246: qtsystems-opensource-src - dependency updates needed for time64 transition.

[Peter Green]

Package: qtsystems-opensource-src
Version: 5.0~git20230712.81e08ee+dfsg-2
Severity: serious

libqt5publishsubscribe5 was renamed to libqt5publishsubscribe5t64 and
libqt5serviceframework5 was renamed to libqt5serviceframework5t64 as
part of the time64 transition, but the package names in the
corresponding symbols files were not updated.

This leads to qml-module-qtpublishsubscribe, qml-module-qtserviceframework
,qtsystems5-tools and qml-module-qtsysteminfo having dependencies on the
old libraries. As a result qml-module-qtpublishsubscribe,
qml-module-qtserviceframework and qtsystems5-tools are not installable
in testing on armel and armhf qml-module-qtsysteminfo is technically
installable but only because of a cruft package still being present.

Fixing the symbols file is pretty trivial, I do wonder though, if
uploading this package rename to unstable was intentional in the
first place. I recall reading that the QT team had decided that
just renaming the core qt packages was sufficient to ensure that
all qt stuff was upgraded in lock-step, and this rename was uploaded
to sid way after the main time64 uploads.

Bug#1081977: libsis-jhdf5-java build-depends on dropped package.

[Peter Green]

Package: libsis-jhdf5-java
Version: 19.04.1+dfsg-7
Severity: serious
User: debian...@lists.debian.org
Usertags: edos-uninstallable

libsis-jhdf5-java build-depends on libeclipse-jdt-compiler-apt-java
which is no longer built by the eclipse-jdt-core source package.
This package is still present in unstable as a cruft package, but
is completely gone from testing.

Bug#1081756: loupe - build-depends unsatisfiable

[Peter Green]

Package: loupe
Version: 46.2-2
Severity: serious

loupe build-depends on librust-ashpd-0.8+default-dev but testing/unstable
has version 0.9.

Bug#1081753: gnome-metronome - unsatisfiable build-dependencies

[Peter Green]

Package: gnome-metronome
Version: 1.3.0-5
Severity: serious

gnome-metronome build-depends on librust-gtk4-0.8+v4-10-dev but
unstable has version 0.9.

Bug#1081752: glycin-loaders - unsatisfiable build-dependencies.

[Peter Green]

Package: glycin-loaders
Version: 1.0.1+ds-3
Severity: serious

glycin-loaders build-depends on librust-gio-0.19+default-dev but
testing/unstable now has version 0.20.

Bug#1081706: camlimages FTBFS: Unbound module "Caml.Filename"

[Peter Green]

Package: camlimages
Version: 1:5.0.5-1
Severity: serious

It seems that about a fortnight ago camlimages started to FTBFS
on the "reproducible builds" tests server. This seems contempory
with the upload of ocaml 5.2.0-3

https://tests.reproducible-builds.org/debian/rbuild/unstable/arm64/camlimages_5.0.5-1.rbuild.log.gz

https://tests.reproducible-builds.org/debian/history/camlimages.html

I am also seeing this build failure in raspbian, so I don't think
it's specific to the "reproducible builds" test setup.




(cd _build/default && /usr/bin/ocamlopt.opt -w -40 -w -3-6 -g -I 
config/.ciconfig.eobjs/byte -I config/.ciconfig.eobjs/native -I 
/usr/lib/aarch64-linux-gnu/ocaml/5.2.0/base -I 
/usr/lib/aarch64-linux-gnu/ocaml/5.2.0/base/base_internalhash_types -I 
/usr/lib/aarch64-linux-gnu/ocaml/5.2.0/base/shadow_stdlib -I 
/usr/lib/aarch64-linux-gnu/ocaml/5.2.0/dune-configurator -I 
/usr/lib/aarch64-linux-gnu/ocaml/5.2.0/findlib -I 
/usr/lib/aarch64-linux-gnu/ocaml/5.2.0/ocaml_intrinsics_kernel -I 
/usr/lib/aarch64-linux-gnu/ocaml/5.2.0/sexplib0 -I 
/usr/lib/aarch64-linux-gnu/ocaml/5.2.0/stdio -I 
/usr/lib/aarch64-linux-gnu/ocaml/5.2.0/stdune/csexp -I 
/usr/lib/aarch64-linux-gnu/ocaml/5.2.0/unix -intf-suffix .ml -no-alias-deps -open 
Dune__exe -o config/.ciconfig.eobjs/native/dune__exe__XConfigurator.cmx -c -impl 
config/xConfigurator.ml)
File "config/xConfigurator.ml", line 11, characters 15-35:
11 |   let ( ^/ ) = Caml.Filename.concat

Error: Unbound module "Caml.Filename"
dh_auto_build: error: dune build -j 12 -p camlimages returned exit code 1

Bug#1080982: unblock: rust-unicode-width/0.1.13-1

[Peter Green]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock

rust-unicode-width is blocked from migrating to testing by
autopkgtest failures in rust-tui. rust-tui is abandoned
upstream and we intend to get rid of it (see bugs
1080293 and 1080400). Upstream states that
ratatui is an actively maintained fork.

All the reverse dependencies of rust-tui in Debian
sid have moved to rust-ratatui, however two of
them, rust-ansi-to-tui and rust-kmon are blocked
from migrating to testing behind rust-ratatui, which
in turn is blocked behind the new version of
unicode-width.

I would therefore like to request the release team
set two hints.

1. A hint allowing rust-unicode-width to migrate
    despite the autopkgtest failure in rust-tui.
2. A removal hint for rust-tui.

Bug#1080496: gnome-metronome, build-dependencies unsatisfiable due to rust gtk stack update.

[Peter Green]

Package: gnome-metronome
Version: 1.3.0-4
Severity: serious

gnome-metronome's build-dependencies are unsatisfiable due to the recent
rust gtk stack update.

After bumping the build-dependencies and cargo dependencies I was able
to build the package and run it's (superficial) autopkgtest succesfully.

Debdiff is attatched.
diff -Nru gnome-metronome-1.3.0/debian/changelog 
gnome-metronome-1.3.0/debian/changelog
--- gnome-metronome-1.3.0/debian/changelog  2024-05-29 17:50:50.0 
+
+++ gnome-metronome-1.3.0/debian/changelog  2024-09-05 03:29:26.0 
+
@@ -1,3 +1,10 @@
+gnome-metronome (1.3.0-5.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Bump dependencies for rust-gtk4 0.9 and related packages..
+
+ -- Peter Michael Green   Thu, 05 Sep 2024 03:29:26 +
+
 gnome-metronome (1.3.0-5) unstable; urgency=medium
 
   * Update debian/watch
diff -Nru gnome-metronome-1.3.0/debian/control 
gnome-metronome-1.3.0/debian/control
--- gnome-metronome-1.3.0/debian/control2024-05-29 17:50:50.0 
+
+++ gnome-metronome-1.3.0/debian/control2024-09-05 03:29:26.0 
+
@@ -14,11 +14,11 @@
  libgstreamer-plugins-bad1.0-dev,
  libgstreamer1.0-dev,
  librust-gettext-rs-0+gettext-system-dev,
- librust-gtk4-0.8+v4-10-dev,
- librust-libadwaita-0.6+v1-4-dev,
+ librust-gtk4-0.9+v4-10-dev,
+ librust-libadwaita-0.7+v1-4-dev,
  librust-log-0-dev,
  librust-pretty-env-logger-0.5-dev,
- librust-gstreamer-play-0.22-dev,
+ librust-gstreamer-play-0.23-dev,
  gsettings-desktop-schemas-dev (>= 0.1.0),
  meson,
  rustc,
diff -Nru gnome-metronome-1.3.0/debian/patches/rust-gtk-0.9.patch 
gnome-metronome-1.3.0/debian/patches/rust-gtk-0.9.patch
--- gnome-metronome-1.3.0/debian/patches/rust-gtk-0.9.patch 1970-01-01 
00:00:00.0 +
+++ gnome-metronome-1.3.0/debian/patches/rust-gtk-0.9.patch 2024-09-05 
03:29:26.0 +
@@ -0,0 +1,16 @@
+Index: gnome-metronome-1.3.0/Cargo.toml
+===
+--- gnome-metronome-1.3.0.orig/Cargo.toml
 gnome-metronome-1.3.0/Cargo.toml
+@@ -9,7 +9,7 @@ log = "0.4"
+ pretty_env_logger = "0.5.0"
+ gettext-rs = { version = "0.7", features = ["gettext-system"] }
+ once_cell = "1.18"
+-gtk = { version = "0.8", package = "gtk4", features = ["v4_10"] }
+-adw = { version = "0.6", package = "libadwaita", features = ["v1_4"] }
+-gst = { version = "0.22", package = "gstreamer" }
+-gstreamer-play = "0.22"
++gtk = { version = "0.9", package = "gtk4", features = ["v4_10"] }
++adw = { version = "0.7", package = "libadwaita", features = ["v1_4"] }
++gst = { version = "0.23", package = "gstreamer" }
++gstreamer-play = "0.23"
diff -Nru gnome-metronome-1.3.0/debian/patches/series 
gnome-metronome-1.3.0/debian/patches/series
--- gnome-metronome-1.3.0/debian/patches/series 2024-05-29 17:50:50.0 
+
+++ gnome-metronome-1.3.0/debian/patches/series 2024-09-05 03:29:26.0 
+
@@ -4,3 +4,4 @@
 meson-Don-t-set-CARGO_HOME.patch
 relax-deps.patch
 gnome46.patch
+rust-gtk-0.9.patch

Bug#1079368: [Pkg-rust-maintainers] Bug#1079368: please upgrade to v0.36

[Peter Green]

Please upgrade to, or separately provide, quick-xml branch v0.36.

Raising severity, since oxigraph needs the bugfixes, and is crippled by
being forced to patch to use an older branch.


The new version is in experimental.

I've started looking through the rdeps but it may take a bit of time.
I belive at least two of the rdeps, oxigraph and rust-rio are yours,
can you prepare updates for them.

Bug#1079387: rust-typenum - test failure on i386.

[Peter Green]

Package: rust-typenum
Severity: serious

rust-typenum is suffering from a failing test on i386, this
has been the case for some time as evidenced by debci and
reproducible builds test history but did not come to my
attention until a new version was uploaded and a "fails
to migrate to testing for a long time" bug was filed.

I tried to dig into the bug by making the assert more
verbose, and that is when things started to get weird,
the calculated value *does* seem to be less than the
epsilon (specifically the calculated value appears to
be zero) but the assert neverthless fails. The patch I
used for this is in debcargo-conf if anyone else wants
to play with it.

I presume this was triggered by an update of rustc,
but I'm not sure exactly which one. Looking at the
dates of the tests in testing and unstable and comparing
them to rustc's history on the tracker it looks like the
last successful test probablly used 1.66 and the
first failing test probablly used 1.70.

If someone wants to try and write up a compiler bug
based on this they are welcome to do so, I don't have
the energy to do that right now.

Since this is not a regression with respect to testing
and the root cause is probably not in this package,
if there is no better solution I intend to skip the
test. If/when I do so I will downgrade this bug to
"important".

Bug#1079355: unblock: rust-sqlx/0.7.3-4

[Peter Green]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock

Please unblock rust-sqlx, it is currently blocked
by an autopkgtest "regression" of rust-debversion on
riscv64, which is caused by the fact that rust-debversion
is uninstable in testing on riscv64. This causes the fallback
dependency solver to be triggered, which leads to a mismatch
between the version of the package being tested and the
version of the tests.

Bug#1079040: unblock: rust-debian-copyright/0.1.13-1

[Peter Green]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock

Please unblock rust-debian-copyright, it is currently blocked
by an autopkgtest "regression" of rust-debian-analyzer on
riscv64, which is caused by the fact that rust-debian-analyzer
is uninstable in testing on riscv64. This causes the fallback
dependency solver to be triggered, which leads to a mismatch
between the version of the package being tested and the
version of the tests.

Bug#1077284: unblock: rust-debian-copyright/0.1.13-1

[Peter Green]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock

Please unblock rust-debian-copyright, it is currently blocked
by an autopkgtest "pregression" of rust-debian-analyzer on
riscv64, which is caused by the fact that rust-debian-analyzer
is uninstable in testing on riscv64. This causes the fallback
dependency solver to be triggered, which leads to a mismatch
between the version of the package being tested and the
version of the tests.

Bug#1078919: oxigraph - upcoming rust-clap-lex update

[Peter Green]

Package: oxigraph

I am currently working on upgrading rust-clap and it's dependencies.

rust-clap 4.4.18 -> 4.5.15
rust-clap-derive 4.4.7 -> 4.5.13
rust-clap-builder 4.4.18 -> 4.5.15
rust-clap-complete 4.4.9 -> 4.5.18
rust-clap-lex 0.6.0 -> 0.7.2

Of these only clap-lex is semver-breaking.

The new versions have been uploaded to experimental (though they
may not be built yet)

Looking at oxigraph, I see a debian build-dependency on
librust-clap-dev (<< 0.7) but I don't see any corresponding cargo
dependencies. I therefore conclude that this dependency is a
leftover from a previous version and should simply be removed.

After removing the build-dependency I was able to successfully
build the package and run it's autopkgtests with the new version
of clap.

Bug#1068667: rust-futures-lite: please upgrade to branch v2

[Peter Green]

Please upgrade to, or separately provide, upstream branch v2.


rdeps:

Package: loupe - bug report filed with patch
Package: rust-async-channel - no changes needed.
Package: rust-async-executor - no changes needed
Package: rust-async-fs - no changes needed
Package: rust-async-global-executor - fix uploaded to unstable.
Package: rust-async-io - no changes needed
Package: rust-async-lock - no changes needed
Package: rust-async-net - no changes needed
Package: rust-async-process - no changes needed
Package: rust-async-std - bug report filed with trivial fix
Package: rust-async-task - no changes needed
Package: rust-async-zip - fix uploaded to unstable.
Package: rust-blocking - no changes needed
Package: rust-event-listener - bug report filed with trivial fix.
Package: rust-oo7 - fix uploaded to unstable.
Package: rust-smol - no changes needed
Package: rust-crosstermion - no changes needed
Package: rust-gix-packetline - no changes needed
Package: rust-gix-protocol - fix uploaded to unstable
Package: rust-gix-transport - no changes needed.
Package: rust-glycin-utils - fix uploaded to unstable
Package: rust-prodash - no changes needed

Bug#1078658: rust-event-listener - upcoming rust-futures-lite update.

[Peter Green]

Package: rust-event-listener
Version: 5.3.1-6

I hope to update rust-futures-lite to version 2 in sid soon,
the new version is available in experimental.

The Cargo dev-dependencies and Debian build-dependencies
for event-listener allow the new version, but the autopkgtest
dependencies currently do not. Please update the
autopkgtest dependencies to match the build-dependency.

After the dependency updates, the autopkgtests pass
successfully with the new version.

Bug#1078652: rust-async-std - upcoming rust-futures-lite update.

[Peter Green]

Package: rust-async-std
Version: 1.12.0-21

I hope to update rust-futures-lite in sid soon, the new
version is available in experimental.

After relaxing the dependencies (debian and cargo)
rust-async-std builds successfully with the new version
of rust-futures-lite.

Bug#1078650: loupe - upcoming rust-futures-lite update

[Peter Green]

Package: loupe
Version: 46.2-1
Tags: patch

I hope to update rust-futures-lite to version 2 soon,
loupe builds successfully after relaxing the dependency
(indeed version 2 is what upstream asks for)

The new version of rust-futures-lite is available
in experimental if you want to do further testing.

Debdiff is attatched.diff -Nru loupe-46.2/debian/changelog loupe-46.2/debian/changelog
--- loupe-46.2/debian/changelog 2024-08-02 12:14:06.0 +
+++ loupe-46.2/debian/changelog 2024-08-13 18:57:52.0 +
@@ -1,3 +1,10 @@
+loupe (46.2-1.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Relax dependencies on futures-lite.
+
+ -- Peter Michael Green   Tue, 13 Aug 2024 18:57:52 +
+
 loupe (46.2-1) unstable; urgency=medium
 
   * New upstream release (Closes: #1071876, #1063682)
diff -Nru loupe-46.2/debian/control loupe-46.2/debian/control
--- loupe-46.2/debian/control   2024-08-01 23:29:23.0 +
+++ loupe-46.2/debian/control   2024-08-13 18:57:52.0 +
@@ -24,7 +24,7 @@
  librust-async-channel-2+default-dev (>= 2.1.0-~~),
  librust-env-logger-0.10+default-dev,
  librust-futures-channel-0.3+default-dev (>= 0.3.25-~~),
- librust-futures-lite-1+default-dev (>= 1.13.0-~~),
+ librust-futures-lite+default-dev (>= 1.13.0-~~),
  librust-gettext-rs-0.7+default-dev,
  librust-gettext-rs-0.7+gettext-system-dev,
  librust-gettext-sys-0.21+default-dev (>= 0.21.3-~~),
diff -Nru loupe-46.2/debian/patches/relax-deps.diff 
loupe-46.2/debian/patches/relax-deps.diff
--- loupe-46.2/debian/patches/relax-deps.diff   2024-08-01 23:13:54.0 
+
+++ loupe-46.2/debian/patches/relax-deps.diff   2024-08-13 18:57:52.0 
+
@@ -27,7 +27,7 @@
 +env_logger = "0.10.0"
  futures-channel = "0.3.25"
 -futures-lite = "2.1.0"
-+futures-lite = "1.13"
++futures-lite = ">= 1.13"
  
  gvdb-macros = "0.1.6"
  indexmap = "2.0.0"

Bug#1072696: rust-tokio: please update to v1.38

[Peter Green]

> rust-tokio: please update to v1.38

tokio itself is not semver-breaking, but one of it's closely
coupled dependencies mio is. The new versions of tokio,
tokio-macros, mio and signal-hook-mio are now available
in experimental.

rdeps:

Package: pushpin - bug report filed with patch.
Package: rust-condure - fix prepared but not uploaded
Package: rust-crossterm - fix prepared but not uploaded
Package: rust-erbium-net - fix uploaded to unstable
Package: rust-notify - fix uploaded to unstable.
Package: rust-rustls - bug report filed, ack received back
Package: rust-signal-hook-mio - fix uploaded to experimental
Package: rust-netlink-sys - fix uploaded to unstable
Package: rust-udev-dev - fix prepared but not uploaded.

Bug#1077958: nmu: rust-async-broadcast_0.7.1-1

[Peter Green]

That's why the test timeout on riscv64 is double that of other architectures: 


Unfortunately in many cases, the performance difference seems a lot more
than a factor of two.

Take rust-gix for example, looking at the results for testing migration
tests I see

18-28m on amd64
53-59m on arm64
33-47m on armel
33-48m on armhf
1h59m-2h2m on i386
49m-1h37m on ppc64el
23m-55m on s390x

on riscv64 it was timing out after over 8 hours. To unblock things I modified it
to only test a single feature configuration. It then passed in 29 minuites.

If we assume all feature configurations take the same time (very rough) then
that suggests running the full set of tests on riscv64 would take of the order
of 23 hours. Over 10 times worse than the next-slowest architecture.


So this hints at missing *versioned* dependencies.


It seems to me that britney's autopkgtest scheduler sometimes fails to pick
up that stuff needs to go in together. Even though the main part of britney
knows that they do.

The end result of this is frequently that the fallback dependency solver
gets triggered and autopkgtest tries to run the tests from testing against
the package from unstable. This often results in a "crate directory not
found" error. In other cases the fallback depsolver is not invoked or
doesn't succeed and the testsuite fails with a "fail badpkg" error.

Why this is happening I'm not entirely sure. Though I have some theories

In some cases I suspect it happens because the dependencies are indirect.
or even involve going down the tree and back up again.

In some cases I suspect it happens because riscv64 testing is currently
a basket case, so the packages are already uninstallable in testing.

In some cases I suspect it happens due to the special treatment of arch
all packages (rust team packages are arch any, but Jonas's packages
are arch all). For example if we look at the migration page for
rust-event-listener, it seems britney has done the right thing on amd64
and arm64 (where arch all packages are required to be installable) but
not done the right thing on architectures where arch all packages are
not required to be installable.

Bug#1077224: python3-utidylib - depends on cruft package

[Peter Green]

Package: python-utidylib
Version: 0.10-1
Severity: serious

python3-utidylib depends on libtidy5deb0 which is no longer built by
the tidy-html5 source package. It appears to have been replaced by
libtidy58.

Since this is an arch all package, and a hard-coded depdency this
cannot be fixed by a binnmu.

Bug#1077223: python3-tidylib - depends on cruft package

[Peter Green]

Package: python-tidylib
Version: 0.3.3~dfsg-7
Severity: serious

python3-tidylib depends on libtidy5deb0 which is no longer built by
the tidy-html5 source package. It appears to have been replaced by
libtidy58.

Since this is an arch all package, and a hard-coded depdency this
cannot be fixed by a binnmu.

Bug#1074652: rust-sequoia-chameleon-gnupg: FTBFS: unsatisfiable build-dependencies

[Peter Green]

Found 1074652 0.8.0-5
Thanks

With the recent migration of a bunch of sequoia packages to testing,
rust-sequoia-chameleon-gnupg's build-dependencies are also unsatisfiable
in testing.

Bug#1043016: rust-fastrand: please update to v2

[Peter Green]

On 01/07/2024 07:21, Jonas Smedegaard wrote:

Quoting Peter Michael Green (2024-06-30 13:41:42)

I am aware that v2 is already pending in experimental, but given the
pace of transitioning to a new branch, it is helpful to have the
rng.fill() function available faster, for packages to prepare for the
transition, which is then in more cases possible to handle by loosenig
crate depenency to ">= 1.9, <= 2".

Done,


Excellent. Thanks!


Can you post in the bug for updating to 2.x when your packages
are ready and I'll look at the rust team ones.


Do you need something else/more than my confirmation post in February?


I see rsass and blocking are fixed, thanks. That leaves the async packages

Given that the async* packages seem to be increasingly important to the
rust ecosystem, I'd like confirmation that they can be fixed in a
coordinated manner.

Taking a look at them now, it looks like rust-async-executor will need
a coordinated upload, consisting of.

1. Taking the version from experimental
2. Bumping the Debian dependency on concurrent-queue to match the
   cargo dependency.
3. Dropping patch 2001_fastrand.patch
4. Updating the debian dependencies on fastrand.
5. Uploading to unstable.

When I look at the patch used for fastrand 1.x it doesn't look
like it would be easilly adapted to support both the old and new versions.

In rust-async-lock, for the version in unstable, the Cargo dev-dependencies
allow the new version, but the Debian build/test dependencies do not. This is
fixed in the experimental version but the experimental version is
semver-breaking. So an update to the version in sid would seem sensible
to decouple the transitions.

Bug#1060875: rust-itertools: please upgrade to v0.12

[Peter Green]

Please upgrade to (or separately provide) branch v0.12.


This looks ready to go once rust-criterion and rust-test-case are fixed.

done

Package: btm
Package: elan
Package: git-delta
Package: hippotat
Package: precious
Package: python-maturin
Package: rust-av-metrics
Package: rust-cargo
Package: rust-cargo-c
Package: rust-cargo-lichking
Package: rust-cargo-mutants
Package: rust-coreutils
Package: rust-criterion-0.3
Package: rust-criterion-plot
Package: rust-debcargo
Package: rust-drt-tools
Package: rust-gping
Package: rust-gstreamer
Package: rust-lalrpop
Package: rust-prost-build
Package: rust-prost-derive
Package: rust-ratatui
Package: rust-rav1e
Package: rust-sequoia-sq
Package: rust-ruma-state-res
Package: rust-rustpython-common
Package: rust-rustpython-compiler-core
Package: rust-rustpython-parser
Package: sccache

Fixed in experimental:

Package: rust-itertools-num
Package: rust-malachite-base
Package: rust-predicates
Package: rust-shrinkwraprs
Package: rust-sqlformat
Package: rust-zxcvbn

Bugs filed:

Package: rust-criterion
Package: rust-test-case

Broken and not in testing:

Package: rust-pdf
Package: rust-rspotify

Bug#1074770: rust-test-case - upcoming rust-itertools update.

[Peter Green]

Package: rust-test-case
Version: 3.3.1-1
Tags: patch

We are currently looking at updating rust-itertools to 0.12,
the new version is available in experimental.

The Debian build-dependencies and test-dependencies have no
upper limit on the version, but the Cargo dev-dependency does,
so building rust-test-case with rust-itertools from
experimental fails with.


error: failed to select a version for the requirement `itertools = ">=0.10, 
<=0.11"`
candidate versions found which didn't match: 0.12.0


After removing the upper limit from the cargo dev-dependency
the package builds and it's autopkgtests run succesfully.

Debdiff is attatched.
diff -Nru rust-test-case-3.3.1/debian/changelog 
rust-test-case-3.3.1/debian/changelog
--- rust-test-case-3.3.1/debian/changelog   2024-01-14 17:27:53.0 
+
+++ rust-test-case-3.3.1/debian/changelog   2024-07-02 15:50:56.0 
+
@@ -1,3 +1,10 @@
+rust-test-case (3.3.1-1.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Relax cargo dev-dependency on itertools.
+
+ -- Peter Michael Green   Tue, 02 Jul 2024 15:50:56 +
+
 rust-test-case (3.3.1-1) unstable; urgency=medium
 
   [ upstream ]
diff -Nru rust-test-case-3.3.1/debian/patches/2001_itertools.patch 
rust-test-case-3.3.1/debian/patches/2001_itertools.patch
--- rust-test-case-3.3.1/debian/patches/2001_itertools.patch2024-01-14 
17:22:56.0 +
+++ rust-test-case-3.3.1/debian/patches/2001_itertools.patch2024-07-02 
15:50:56.0 +
@@ -1,8 +1,8 @@
-Description: accept older branch of crate itertools
+Description: accept older and newer branches of crate itertools
 Author: Jonas Smedegaard 
 Bug-Debian: https://bugs.debian.org/1054075
 Forwarded: not-needed
-Last-Update: 2024-01-14
+Last-Update: 2024-07-02 by Peter Michael Green
 ---
 This patch header follows DEP-3: http://dep.debian.net/deps/dep3/
 --- a/Cargo.toml
@@ -12,7 +12,7 @@
  [dev-dependencies]
  insta   = "1.12"
 -itertools   = "0.11"
-+itertools   = ">= 0.10, <= 0.11"
++itertools   = ">= 0.10"
  regex   = "1.5"
  
  [workspace]

Bug#1074370: ffmpeg: Fails to build on armel & armhf

[Peter Green]

On 27/06/2024 12:33, Jeremy Bícha wrote:

Source: ffmpeg
Version: 7:6.1.1-4
Severity: serious
Tags: ftbfs
User: debian-...@lists.debian.org
Usertags: armel armhf
X-Debbugs-CC: debian-...@lists.debian.org

ffmpeg is failing to build on armel & armhf (but not arm64). This was
noticed while rebuilding ffmpeg for the ongoing jpeg-xl 0.9
transition. I don't believe the build failure is related to the new
version of jpeg-xl. The last successful official build before this was
on June 9.


I belive binutils has recently got stricter about assembler syntax
(see for example https://gitlab.com/postmarketOS/pmaports/-/issues/2401  )
but given that this particular assembler involves macros, I don't feel
confident trying to fix this myself.

Bug#1074384: slurm-wlm-basic-plugins, depends on 64-bit only library

[Peter Green]

Package: slurm-wlm-basic-plugins
Version: 23.11.7-1
Severity: serious

slurm-wlm-basic-plugins depends on libpmix2t64 and slum-wlm
build-depends on , which is no longer
available on 32-bit architectures.

I notice that the build-dependency is already architecture
restricted, but the runtime dependency is not, please
investigate this discrepancy.

Bug#1074243: sccache - please remove build-dependency on librust-counted-array-0.1+default-dev

[Peter Green]

Package: sccache
Version: 0.8.1-3
Severity: serious
x-debbugs-cc: n...@sail.ng

sccache build-depends on librust-counted-array-0.1+default-dev which was 
recently
removed from Debian. The removal request was filed by Blair Noctis who gave the
reasoning.


Please kindly remove rust-counted-array from unstable. It didn't see maintenance
upstream for a long time, and is no longer used by other packages, either
upstream or in Debian. Thank you.


Investigating deeper, it seems that sccache replaced the counted-array crate 
with
a simplified internal implementation a couple of years ago but the Debian 
package
still has a build-dependency on it.

I was able to succesfully test-build sccache with the build-dependency removed.

Bug#1074241: opensnitch can no longer be built on ppc64el.

[Peter Green]

Package: opensnitch
Severity: serious
Justification: rc policy - packages must be buildable within the same release.

The build-dependencies for opensnitch are no longer satisfiable
on ppc64el, because bpfcc no longer supports that architecture.

  package: opensnitch
  version: 1.5.8.1-1
  architecture: any,all
  type: src
  status: broken
  reasons:
   -
missing:
 pkg:
  package: golang-github-iovisor-gobpf-dev
  version: 0.2.0-6
  architecture: all
  unsat-dependency: libbpfcc-dev:ppc64el
 depchains:
  -
   depchain:
-
 package: opensnitch
 version: 1.5.8.1-1
 architecture: any,all
 type: src
 depends: golang-github-iovisor-gobpf-dev:ppc64el

Either this needs to be dealt with somehow such that opensnitch
can be built on ppc64el again, or the ppc64el binaries for
opensnitch need to be removed.

Bug#1073845: pesign FTBFS sometimes on armhf, linker errors.

[Peter Green]

Package: pesign
Version: 116-7

While working on the time64 transition in raspbian, I discovered pesign failing
to build with a linker error.


cc -g -O2 -Werror=implicit-function-declaration 
-ffile-prefix-map=/build/reproducible-path/pesign-116=. -fstack-protector-strong 
-fstack-clash-protection -Wformat -Werror=format-security  -Wall -Wextra -Wsign-compare 
-Wno-unused-result -Wno-unused-function -Wno-missing-field-initializers  -Werror 
-Wno-error=cpp -Wno-free-nonheap-object -std=gnu11 -fshort-wchar -fPIC 
-fno-strict-aliasing -D_GNU_SOURCE -DCONFIG_aarch64 -I../include 
'-DRUNDIR="/run/"'   -Wmaybe-uninitialized -grecord-gcc-switches  
-Wl,-z,relro  -fno-merge-constants -fvar-tracking -fvar-tracking-assignments 
-fkeep-inline-functions -Wl,--fatal-warnings,--no-allow-shlib-undefined,--default-symver 
-Wl,-O2 -Wl,--no-undefined-version -Wl,-z,relro,-z,now 
-Wl,--no-add-needed,--no-copy-dt-needed-entries,--as-needed -pie  -D_LARGEFILE_SOURCE 
-D_FILE_OFFSET_BITS=64 -D_TIME_BITS=64 -Wdate-time -D_FORTIFY_SOURCE=2 -shared \
-Wl,-soname,libdpe.so.0.116 \
	-o libdpe.so libdpe.o pe_addcert.o pe_allocspace.o pe_begin.o pe_end.o pe_error.o pe_getdatadir.o pe_getpehdr.o pe_getscn.o pe_getshdr.o pe_nextscn.o pe_opthdr.o pe_rawfile.o pe_readall.o pe_update.o pe_updatefile.o pe_updatenull.o -lpthread 
/usr/bin/ld: warning: libdpe.o uses 2-byte wchar_t yet the output is to use 4-byte wchar_t; use of wchar_t values across objects may fail

/usr/bin/ld: warning: pe_addcert.o uses 2-byte wchar_t yet the output is to use 
4-byte wchar_t; use of wchar_t values across objects may fail
/usr/bin/ld: warning: pe_allocspace.o uses 2-byte wchar_t yet the output is to 
use 4-byte wchar_t; use of wchar_t values across objects may fail
/usr/bin/ld: warning: pe_begin.o uses 2-byte wchar_t yet the output is to use 
4-byte wchar_t; use of wchar_t values across objects may fail
/usr/bin/ld: warning: pe_end.o uses 2-byte wchar_t yet the output is to use 
4-byte wchar_t; use of wchar_t values across objects may fail
/usr/bin/ld: warning: pe_error.o uses 2-byte wchar_t yet the output is to use 
4-byte wchar_t; use of wchar_t values across objects may fail
/usr/bin/ld: warning: pe_getdatadir.o uses 2-byte wchar_t yet the output is to 
use 4-byte wchar_t; use of wchar_t values across objects may fail
/usr/bin/ld: warning: pe_getpehdr.o uses 2-byte wchar_t yet the output is to 
use 4-byte wchar_t; use of wchar_t values across objects may fail
/usr/bin/ld: warning: pe_getscn.o uses 2-byte wchar_t yet the output is to use 
4-byte wchar_t; use of wchar_t values across objects may fail
/usr/bin/ld: warning: pe_getshdr.o uses 2-byte wchar_t yet the output is to use 
4-byte wchar_t; use of wchar_t values across objects may fail
/usr/bin/ld: warning: pe_nextscn.o uses 2-byte wchar_t yet the output is to use 
4-byte wchar_t; use of wchar_t values across objects may fail
/usr/bin/ld: warning: pe_opthdr.o uses 2-byte wchar_t yet the output is to use 
4-byte wchar_t; use of wchar_t values across objects may fail
/usr/bin/ld: warning: pe_rawfile.o uses 2-byte wchar_t yet the output is to use 
4-byte wchar_t; use of wchar_t values across objects may fail
/usr/bin/ld: warning: pe_readall.o uses 2-byte wchar_t yet the output is to use 
4-byte wchar_t; use of wchar_t values across objects may fail
/usr/bin/ld: warning: pe_update.o uses 2-byte wchar_t yet the output is to use 
4-byte wchar_t; use of wchar_t values across objects may fail
/usr/bin/ld: warning: pe_updatefile.o uses 2-byte wchar_t yet the output is to 
use 4-byte wchar_t; use of wchar_t values across objects may fail
/usr/bin/ld: warning: pe_updatenull.o uses 2-byte wchar_t yet the output is to 
use 4-byte wchar_t; use of wchar_t values across objects may fail
collect2: error: ld returned 1 exit status
make[2]: *** [/build/reproducible-path/pesign-116/Make.rules:29: libdpe.so] 
Error 1


I checked over on reproducible builds to determine if this was raspbian 
specific,
and it seems that on the reproducible builds tests for armhf, "rbuild" is 
succeeding
but "build2" is failing.

https://tests.reproducible-builds.org/debian/rb-pkg/trixie/armhf/pesign.html

Bug#1071297: btrfs-progs: FTBFS: convert/source-ext2.c:733:13: error: implicit declaration of function ‘inode_includes’ [-Werror=implicit-function-declaration]

[Peter Green]

tags 1071297 +patch
thanks

It looks like e2fsprogs 1.47.1 renamed the inode_includes macro to
ext2fs_inode_includes.

A debdiff for the upload I made to raspbian to deal with this is
attached.diff -Nru btrfs-progs-6.6.3/debian/changelog btrfs-progs-6.6.3/debian/changelog
--- btrfs-progs-6.6.3/debian/changelog  2024-02-28 05:21:59.0 +
+++ btrfs-progs-6.6.3/debian/changelog  2024-06-12 11:42:41.0 +
@@ -1,3 +1,10 @@
+btrfs-progs (6.6.3-1.1+rpi1) trixie-staging; urgency=medium
+
+  * Change inode_includes to ext2fs_inode_includes (Closes: #1071297)
+  * Bump dependency on libext2fs-dev.
+
+ -- Peter Michael Green   Wed, 12 Jun 2024 11:42:41 
+
+
 btrfs-progs (6.6.3-1.1) unstable; urgency=medium
 
   * Non-maintainer upload.
diff -Nru btrfs-progs-6.6.3/debian/control btrfs-progs-6.6.3/debian/control
--- btrfs-progs-6.6.3/debian/control2024-02-28 05:21:59.0 +
+++ btrfs-progs-6.6.3/debian/control2024-06-12 11:42:41.0 +
@@ -3,7 +3,7 @@
 Priority: optional
 Maintainer: Adam Borowski 
 Build-Depends: dpkg-dev (>= 1.22.5), debhelper-compat (= 13),
-   libext2fs-dev,
+   libext2fs-dev (>= 1.47.1),
pkg-config,
libacl1-dev,
libblkid-dev,
diff -Nru btrfs-progs-6.6.3/debian/patches/debian-changes 
btrfs-progs-6.6.3/debian/patches/debian-changes
--- btrfs-progs-6.6.3/debian/patches/debian-changes 1970-01-01 
00:00:00.0 +
+++ btrfs-progs-6.6.3/debian/patches/debian-changes 2024-06-12 
11:42:41.0 +
@@ -0,0 +1,27 @@
+Description: Autogenerated patch header for a single-debian-patch file.
+ The delta against upstream is either kept as a single patch, or maintained
+ in some VCS, and exported as a single patch instead of more manageable
+ atomic patches.
+Forwarded: not-needed
+
+---
+--- btrfs-progs-6.6.3.orig/convert/source-ext2.c
 btrfs-progs-6.6.3/convert/source-ext2.c
+@@ -730,7 +730,7 @@ static inline void ext4_decode_extra_tim
+ #define EXT4_COPY_XTIME(xtime, dst, tv_sec, tv_nsec)  
\
+ do {  
\
+   tv_sec = src->i_ ## xtime ; 
\
+-  if (inode_includes(inode_size, i_ ## xtime ## _extra)) {
\
++  if (ext2fs_inode_includes(inode_size, i_ ## xtime ## _extra)) { 
\
+   tv_sec = src->i_ ## xtime ; 
\
+   ext4_decode_extra_time(&tv_sec, &tv_nsec, src->i_ ## xtime ## 
_extra);  \
+   btrfs_set_stack_timespec_sec(&dst->xtime , tv_sec); 
\
+@@ -771,7 +771,7 @@ static int ext4_copy_inode_timespec_extr
+   EXT4_COPY_XTIME(ctime, dst, tv_sec, tv_nsec);
+ 
+   tv_sec = src->i_crtime;
+-  if (inode_includes(inode_size, i_crtime_extra)) {
++  if (ext2fs_inode_includes(inode_size, i_crtime_extra)) {
+   tv_sec = src->i_crtime;
+   ext4_decode_extra_time(&tv_sec, &tv_nsec, src->i_crtime_extra);
+   btrfs_set_stack_timespec_sec(&dst->otime, tv_sec);
diff -Nru btrfs-progs-6.6.3/debian/patches/series 
btrfs-progs-6.6.3/debian/patches/series
--- btrfs-progs-6.6.3/debian/patches/series 1970-01-01 00:00:00.0 
+
+++ btrfs-progs-6.6.3/debian/patches/series 2024-06-12 11:42:41.0 
+
@@ -0,0 +1 @@
+debian-changes

Bug#1072982: lime - build-depends on package that is not in testing.

[Peter Green]

Package: lime
Version: 5.2.0+dfsg-3
Severity: serious
Justification: rc policy - "packages must be buildable within the same release"
User: debian...@lists.debian.org
Usertags: edos-uninstallable

lime build-depends on boost1.74, which is no longer in testing. It seems that
lime was removed from testing at the same time as boost1.74, but for some
reason it then re-migrated.

Please update your package to use the current version of boost.

Bug#1072979: beast-mcmc - build-dependencies unsatisfiable on i386.

[Peter Green]

Package: beast-mcmc
Version: 1.10.4+dfsg-5
Severity: serious
x-debbugs-cc: r-cran-rj...@packages.debian.org

beast-mcmc build-depends on r-cran-rjava, which is no longer available
on i386. It appears that the package failed to build, and the old
binaries were then removed.

Bug#1072980: guestfs-tools - build-depends unsatisfiable on armel

[Peter Green]

Package: guestfs-tools
Version: 1.52.0-2
Severity: serious
User: debian...@lists.debian.org
Usertags: edos-uninstallable

guestfs-tools on armel build-depends on linux-image-marvell:armel | 
linux-image-versatile:armel
neither of which is available anymore.

It looks like the only kernel now available on armel is linux-image-rpi, I do 
not know
if this is suitable for your purposes.

Bug#1072261: precious - upcoming rust-itertools update.

[Peter Green]

Package: precious
Version: 0.6.0-5

I hope to update rust-itertools to 0.12 soon. The new version is
available in experimental (and has been for some time).

I was able to sucessfully build precious with the new version
after patching the dependency. The debdiff I used for testing
is attatched.
diff -Nru precious-0.6.0/debian/changelog precious-0.6.0/debian/changelog
--- precious-0.6.0/debian/changelog 2024-02-11 22:04:24.0 +
+++ precious-0.6.0/debian/changelog 2024-05-31 03:20:52.0 +
@@ -1,3 +1,10 @@
+precious (0.6.0-5.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Relax dependency on itertools.
+
+ -- Peter Michael Green   Fri, 31 May 2024 03:20:52 +
+
 precious (0.6.0-5) unstable; urgency=medium
 
   * update patch 2001_indexmap to relax dependency;
diff -Nru precious-0.6.0/debian/control precious-0.6.0/debian/control
--- precious-0.6.0/debian/control   2024-02-11 17:45:40.0 +
+++ precious-0.6.0/debian/control   2024-05-31 03:20:47.0 +
@@ -22,7 +22,7 @@
  librust-globset-0.4+default-dev (>= 0.4.9),
  librust-ignore-0.4+default-dev (>= 0.4.18),
  librust-indexmap-dev (<< 3),
- librust-itertools+default-dev (<< 0.11),
+ librust-itertools+default-dev (<< 0.13),
  librust-log-0.4+default-dev (>= 0.4.17),
  librust-md5-0.7+default-dev,
  librust-once-cell-1+default-dev (>= 1.16),
diff -Nru precious-0.6.0/debian/patches/1001_itertools.patch 
precious-0.6.0/debian/patches/1001_itertools.patch
--- precious-0.6.0/debian/patches/1001_itertools.patch  1970-01-01 
00:00:00.0 +
+++ precious-0.6.0/debian/patches/1001_itertools.patch  2024-05-31 
03:20:51.0 +
@@ -0,0 +1,13 @@
+Index: precious-0.6.0/Cargo.toml
+===
+--- precious-0.6.0.orig/Cargo.toml
 precious-0.6.0/Cargo.toml
+@@ -37,7 +37,7 @@ filetime = "0.2.22"
+ globset = "0.4.13"
+ ignore = "0.4.20"
+ indexmap = { version = "2.0.2", features = ["serde"] }
+-itertools = ">= 0.9.0, < 0.11.0"
++itertools = ">= 0.9.0, < 0.13.0"
+ log = "0.4.20"
+ md5 = "0.7.0"
+ once_cell = "1.18.0"
diff -Nru precious-0.6.0/debian/patches/2001_indexmap.patch 
precious-0.6.0/debian/patches/2001_indexmap.patch
--- precious-0.6.0/debian/patches/2001_indexmap.patch   2024-02-11 
22:03:20.0 +
+++ precious-0.6.0/debian/patches/2001_indexmap.patch   2024-05-31 
03:20:52.0 +
@@ -13,6 +13,6 @@
  ignore = "0.4.20"
 -indexmap = { version = "2.0.2", features = ["serde"] }
 +indexmap = { version = ">= 1.9.3, <= 2", features = ["serde"] }
- itertools = ">= 0.9.0, < 0.11.0"
+ itertools = ">= 0.9.0, < 0.13.0"
  log = "0.4.20"
  md5 = "0.7.0"
diff -Nru precious-0.6.0/debian/patches/series 
precious-0.6.0/debian/patches/series
--- precious-0.6.0/debian/patches/series2024-02-11 17:43:30.0 
+
+++ precious-0.6.0/debian/patches/series2024-05-31 03:20:03.0 
+
@@ -1,3 +1,4 @@
+1001_itertools.patch
 2001_comfy-table.patch
 2001_indexmap.patch
 2001_toml.patch

Bug#1072259: git-delta - upcoming rust-itertools update

[Peter Green]

Package: git-delta
Version: 0.17.0-1

I hope to update rust-itertools to 0.12 soon. I was able to succesfully
build git-delta with the new version of

The new version of rust-itertools is availilable in experimental, and
the debdiff I used for the test build is attatched.diff -Nru git-delta-0.17.0/debian/changelog git-delta-0.17.0/debian/changelog
--- git-delta-0.17.0/debian/changelog   2024-04-02 09:12:49.0 +
+++ git-delta-0.17.0/debian/changelog   2024-05-31 02:36:38.0 +
@@ -1,3 +1,10 @@
+git-delta (0.17.0-1.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Bump itertools dependency to 0.12.
+
+ -- Peter Michael Green   Fri, 31 May 2024 02:36:38 +
+
 git-delta (0.17.0-1) unstable; urgency=medium
 
   [ upstream ]
diff -Nru git-delta-0.17.0/debian/control git-delta-0.17.0/debian/control
--- git-delta-0.17.0/debian/control 2024-04-02 09:12:49.0 +
+++ git-delta-0.17.0/debian/control 2024-05-31 02:36:32.0 +
@@ -32,7 +32,7 @@
  librust-dirs-5+default-dev,
  librust-git2-0.18-dev,
  librust-grep-cli-0.1+default-dev,
- librust-itertools-0.10+default-dev,
+ librust-itertools-0.12+default-dev,
  librust-lazy-static-1+default-dev,
  librust-palette-0.7+default-dev,
  librust-pathdiff-0.2+default-dev,
diff -Nru git-delta-0.17.0/debian/patches/1001_itertools.patch 
git-delta-0.17.0/debian/patches/1001_itertools.patch
--- git-delta-0.17.0/debian/patches/1001_itertools.patch1970-01-01 
00:00:00.0 +
+++ git-delta-0.17.0/debian/patches/1001_itertools.patch2024-05-31 
02:36:38.0 +
@@ -0,0 +1,13 @@
+Index: git-delta-0.17.0/Cargo.toml
+===
+--- git-delta-0.17.0.orig/Cargo.toml
 git-delta-0.17.0/Cargo.toml
+@@ -40,7 +40,7 @@ console = "0.15.0"
+ ctrlc = "3.2.5"
+ dirs = "5.0.1"
+ grep-cli = "0.1.8"
+-itertools = "0.10.5"
++itertools = "0.12"
+ lazy_static = "1.4"
+ palette = "0.7.2"
+ pathdiff = "0.2.1"
diff -Nru git-delta-0.17.0/debian/patches/2002_terminal-colorsaurus.patch 
git-delta-0.17.0/debian/patches/2002_terminal-colorsaurus.patch
--- git-delta-0.17.0/debian/patches/2002_terminal-colorsaurus.patch 
2024-04-02 09:12:49.0 +
+++ git-delta-0.17.0/debian/patches/2002_terminal-colorsaurus.patch 
2024-05-31 02:36:38.0 +
@@ -5,9 +5,11 @@
 Last-Update: 2024-04-02
 ---
 This patch header follows DEP-3: http://dep.debian.net/deps/dep3/
 a/Cargo.toml
-+++ b/Cargo.toml
-@@ -54,7 +54,6 @@
+Index: git-delta-0.17.0/Cargo.toml
+===
+--- git-delta-0.17.0.orig/Cargo.toml
 git-delta-0.17.0/Cargo.toml
+@@ -54,7 +54,6 @@ unicode-segmentation = "1.10.1"
  unicode-width = "0.1.10"
  xdg = "2.4.1"
  clap_complete = "4.4.4"
@@ -15,9 +17,11 @@
  
  [dependencies.git2]
  version = "0.18.1"
 a/src/cli.rs
-+++ b/src/cli.rs
-@@ -3,7 +3,7 @@
+Index: git-delta-0.17.0/src/cli.rs
+===
+--- git-delta-0.17.0.orig/src/cli.rs
 git-delta-0.17.0/src/cli.rs
+@@ -3,7 +3,7 @@ use std::ffi::OsString;
  use std::path::{Path, PathBuf};
  
  use bat::assets::HighlightingAssets;
@@ -26,7 +30,7 @@
  use clap_complete::Shell;
  use lazy_static::lazy_static;
  use syntect::highlighting::Theme as SyntaxTheme;
-@@ -294,29 +294,6 @@
+@@ -294,29 +294,6 @@ pub struct Opt {
  /// set this in per-repository git config (.git/config)
  pub default_language: Option,
  
@@ -56,7 +60,7 @@
  #[arg(long = "diff-highlight")]
  /// Emulate diff-highlight.
  ///
-@@ -1147,17 +1124,6 @@
+@@ -1147,17 +1124,6 @@ pub enum InspectRawLines {
  False,
  }
  
@@ -74,9 +78,11 @@
  impl Opt {
  pub fn from_args_and_git_config(
  env: DeltaEnv,
 a/src/features/side_by_side.rs
-+++ b/src/features/side_by_side.rs
-@@ -592,7 +592,6 @@
+Index: git-delta-0.17.0/src/features/side_by_side.rs
+===
+--- git-delta-0.17.0.orig/src/features/side_by_side.rs
 git-delta-0.17.0/src/features/side_by_side.rs
+@@ -592,7 +592,6 @@ pub mod ansifill {
  pub mod tests {
  use crate::ansi::strip_ansi_codes;
  use crate::features::line_numbers::tests::*;
@@ -84,7 +90,7 @@
  use crate::tests::integration_test_utils::{make_config_from_args, 
run_delta, DeltaTest};
  
  #[test]
-@@ -643,7 +642,6 @@
+@@ -643,7 +642,6 @@ pub mod tests {
  
  #[test]
  fn test_two_plus_lines_spaces_and_ansi() {
@@ -92,9 +98,11 @@
  DeltaTest::with_args(&[
  "--side-by-side",
  "--width",
 a/src/options/set.rs
-+++ b/src/options/set.rs
-@@ -43,7 +43,6 @@
+Index: git-delta-0.17.0/src/options/set.rs
+===
+--- git-delta-0.17.0.orig/src/options/set.rs
 git-delta-0.17.0/src/options/set.rs
+@@ -43,7 +43,6 @@ macro_rules! set_options {
  "24-bit-co

Bug#1072257: btm - upcoming rust-itertools update

[Peter Green]

Package: btm
Version: 0.9.6-6

I hope to update rust-itertools from 0.10 to 0.12 soon. Looking at btm
the version currently in Debian uses 0.11 upstream and is currently
patched to allow 0.10. I checked the upstream git and they did not
seem to make any code changes when upgrading from 0.11 to 0.12 and
after patching the dependencies to allow 0.12, btm built successfully
with it.

The debdiff I used for testing is attatched.diff -Nru btm-0.9.6/debian/changelog btm-0.9.6/debian/changelog
--- btm-0.9.6/debian/changelog  2024-05-17 05:43:16.0 +
+++ btm-0.9.6/debian/changelog  2024-05-31 01:59:04.0 +
@@ -1,3 +1,10 @@
+btm (0.9.6-6.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Relax itertools dependency to allow 0.12.
+
+ -- Peter Michael Green   Fri, 31 May 2024 01:59:04 +
+
 btm (0.9.6-6) unstable; urgency=medium
 
   * update copyright info: fix file path
diff -Nru btm-0.9.6/debian/control btm-0.9.6/debian/control
--- btm-0.9.6/debian/control2024-05-17 05:40:13.0 +
+++ btm-0.9.6/debian/control2024-05-31 01:58:45.0 +
@@ -24,7 +24,7 @@
  librust-hashbrown-0.14+default-dev,
  librust-humantime-2+default-dev,
  librust-indexmap-2+default-dev,
- librust-itertools-dev (<< 0.12),
+ librust-itertools-dev (<< 0.13),
  librust-kstring-2+arc-dev,
  librust-kstring-2+default-dev,
  librust-libc-0.2+default-dev,
diff -Nru btm-0.9.6/debian/patches/2001_itertools.patch 
btm-0.9.6/debian/patches/2001_itertools.patch
--- btm-0.9.6/debian/patches/2001_itertools.patch   2024-05-17 
05:36:12.0 +
+++ btm-0.9.6/debian/patches/2001_itertools.patch   2024-05-31 
01:53:41.0 +
@@ -1,8 +1,8 @@
-Description: accept older branch of crate itertools
+Description: accept older and newer branches of crate itertools
 Author: Jonas Smedegaard 
 Bug-Debian: https://bugs.debian.org/1054075
 Forwarded: not-needed
-Last-Update: 2024-02-17
+Last-Update: 2024-05-31 by Peter Michael Green
 ---
 This patch header follows DEP-3: http://dep.debian.net/deps/dep3/
 --- a/Cargo.toml
@@ -12,7 +12,7 @@
  humantime = "2.1.0"
  indexmap = "2.0.0"
 -itertools = "0.11.0"
-+itertools = ">= 0.10.5, <= 0.11"
++itertools = ">= 0.10.5, < 0.13"
  kstring = { version = "2.0.0", features = ["arc"] }
  log = { version = "0.4.20", optional = true }
  nvml-wrapper = { version = "0.9.0", optional = true }

Bug#1072255: elan - upcoming rust-itertools and rust-zstd updates

[Peter Green]

Package: elan
Version: 3.1.1-1

I hope to update rust-itertools to 0.12 and rust-zstd to 0.13 soon.

For itertools the debian dependency allows the new versions, but the
Cargo dependencies do not. For zstd, neither the debian or cargo
dependencies

After relaxing the dependencies I was able to build elan successfully
with the new itertools and zstd.

A debdiff is attatched and the new versions of rust-itertools are
available in experimental if you want to do further testing.diff -Nru elan-3.1.1/debian/changelog elan-3.1.1/debian/changelog
--- elan-3.1.1/debian/changelog 2024-05-03 19:04:40.0 +
+++ elan-3.1.1/debian/changelog 2024-05-31 01:25:52.0 +
@@ -1,3 +1,11 @@
+elan (3.1.1-1.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Remove upper limit from Cargo dependency on itertools crate.
+  * Remove upper limit from Debian and Cargo dependencies on zstd crate.
+
+ -- Peter Michael Green   Fri, 31 May 2024 01:25:52 +
+
 elan (3.1.1-1) unstable; urgency=medium
 
   * Import new upstream version (3.1.1)
diff -Nru elan-3.1.1/debian/control elan-3.1.1/debian/control
--- elan-3.1.1/debian/control   2024-05-03 19:04:30.0 +
+++ elan-3.1.1/debian/control   2024-05-31 01:25:52.0 +
@@ -42,7 +42,7 @@
  librust-openssl-probe-dev,
  librust-backtrace-sys-dev,
  librust-markdown-dev,
- librust-zstd-0.12-dev,
+ librust-zstd-dev (>= 0.12.1),
  bash-completion
 Standards-Version: 4.6.2
 Homepage: https://github.com/leanprover/elan
diff -Nru elan-3.1.1/debian/patches/remove-upperlimits.patch 
elan-3.1.1/debian/patches/remove-upperlimits.patch
--- elan-3.1.1/debian/patches/remove-upperlimits.patch  1970-01-01 
00:00:00.0 +
+++ elan-3.1.1/debian/patches/remove-upperlimits.patch  2024-05-31 
01:25:52.0 +
@@ -0,0 +1,31 @@
+Index: elan-3.1.1/Cargo.toml
+===
+--- elan-3.1.1.orig/Cargo.toml
 elan-3.1.1/Cargo.toml
+@@ -29,7 +29,7 @@ elan-utils = { path = "src/elan-utils" }
+ download = { path = "src/download" }
+ clap = "2.33.3"
+ error-chain = "0.12.4"
+-itertools = "0.10.0"
++itertools = ">= 0.10.0"
+ libc = "0.2.82"
+ markdown = "0.3.0"
+ rand = "0.8.2"
+Index: elan-3.1.1/src/elan-dist/Cargo.toml
+===
+--- elan-3.1.1.orig/src/elan-dist/Cargo.toml
 elan-3.1.1/src/elan-dist/Cargo.toml
+@@ -10,11 +10,11 @@ license = "MIT OR Apache-2.0"
+ 
+ [dependencies]
+ regex = "1.4.3"
+-itertools = "0.10.0"
++itertools = ">= 0.10.0"
+ url = "2.2.1"
+ tar = "0.4.33"
+ flate2 = "1.0.14"
+-zstd = "0.12.1"
++zstd = ">= 0.12.1"
+ walkdir = "2.3.1"
+ toml = "0.5.8"
+ sha2 = "0.10.5"
diff -Nru elan-3.1.1/debian/patches/series elan-3.1.1/debian/patches/series
--- elan-3.1.1/debian/patches/series2024-05-03 18:52:38.0 +
+++ elan-3.1.1/debian/patches/series2024-05-31 01:25:52.0 +
@@ -1,2 +1,3 @@
 build.patch
 0002-dependencies.patch
+remove-upperlimits.patch

Bug#1050934: rust-der-parser: Please upgrade to v0.8

[Peter Green]

Please upgrade (or separately package) newer upstream branch v0.8.


I presume this was meant to say 8.x, rather than 0.8

It seems version 8 of der-parser depends on two crates that
are not currently in debian. asn1-rs and displaydoc.

Bug#1030823: rust-inotify: please provide v0.10

[Peter Green]

I tried updating inotify and applying the upstream patch to make notify
use the new version of inotify, but after doing so I got a bunch
of test failures when building python-watchfiles.

Bug#1071831: rust-rio - upcoming quick-xml update

[Peter Green]

Package: rust-rio
Version: 0.8.3-3

I hope to update rust-quick-xml to 0.31 soon. rust-rio
will need an update for this.

I was able to build rust-rio and run it's autopkgtests
successfully after bumping the dependency.

The debdiff I used for testing is attatched.diff -Nru rust-rio-0.8.3/debian/changelog rust-rio-0.8.3/debian/changelog
--- rust-rio-0.8.3/debian/changelog 2023-08-19 21:59:37.0 +
+++ rust-rio-0.8.3/debian/changelog 2024-05-25 11:17:53.0 +
@@ -1,3 +1,10 @@
+rust-rio (0.8.3-3.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Bump quick-xml to 0.31
+
+ -- Peter Michael Green   Sat, 25 May 2024 11:17:53 +
+
 rust-rio (0.8.3-3) unstable; urgency=medium
 
   * update dh-cargo fork;
diff -Nru rust-rio-0.8.3/debian/control rust-rio-0.8.3/debian/control
--- rust-rio-0.8.3/debian/control   2023-06-20 18:36:23.0 +
+++ rust-rio-0.8.3/debian/control   2024-05-25 11:17:53.0 +
@@ -6,7 +6,7 @@
  dh-cargo (>= 25),
  librust-oxilangtag-0.1+default-dev ,
  librust-oxiri-0.2+default-dev ,
- librust-quick-xml-0.27+default-dev ,
+ librust-quick-xml-0.31+default-dev ,
  libstring-shellquote-perl,
 Maintainer: Jonas Smedegaard 
 Standards-Version: 4.6.2
@@ -65,7 +65,7 @@
  librust-oxilangtag-0.1+default-dev,
  librust-oxiri-0.2+default-dev,
  librust-rio-api-0.8+default-dev,
- librust-quick-xml-0.27+default-dev,
+ librust-quick-xml-0.31+default-dev,
  ${misc:Depends},
 Provides:
  librust-rio-xml-0-dev (= ${binary:Version}),
diff -Nru rust-rio-0.8.3/debian/patches/2001_quick-xml.patch 
rust-rio-0.8.3/debian/patches/2001_quick-xml.patch
--- rust-rio-0.8.3/debian/patches/2001_quick-xml.patch  2023-08-13 
15:50:00.0 +
+++ rust-rio-0.8.3/debian/patches/2001_quick-xml.patch  2024-05-25 
11:17:53.0 +
@@ -1,7 +1,7 @@
 Description: relax dependency to match older system crate quick-xml 0.27.1
 Author: Jonas Smedegaard 
 Forwarded: not-needed
-Last-Update: 2023-08-13
+Last-Update: 2024-05-25 by Peter Michael Green
 ---
 This patch header follows DEP-3: http://dep.debian.net/deps/dep3/
 --- a/xml/Cargo.toml
@@ -11,4 +11,4 @@
  oxiri = "0.2"
  rio_api = { version = "0.8", path="../api" }
 -quick-xml = "0.28"
-+quick-xml = ">= 0.27, < 0.29"
++quick-xml = ">= 0.27, < 0.32"

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 lintian-brush-0.152/debi

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 `&Attribute`
   --> 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 `&Attribute`
   --> 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 
&&syn::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 `&MetaNameValue`
   --> 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 `&Attribute` 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 `&Attribute` 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 `&MetaList`
   --> 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 `&Attribute`
  --> 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 `&Attribute` 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
 gfarm-2.7.20+dfsg/bench

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)