Bug#1071998: 389-ds-base - upcoming rust-lru update.

[Peter Michael Green]

Package: 389-ds-base
Version: 3.0.2+dfsg1-1

I hope to update rust-lru to the latest upstream
(0.12.x) soon. The Debian dependencies in 389-ds-base
allow the new version but the cargo dependencies do not.

I was able to build the package succesfully after relaxing
the cargo dependency, a debdiff doing that is attatched.

diff -Nru 389-ds-base-3.0.2+dfsg1/debian/changelog 
389-ds-base-3.0.2+dfsg1/debian/changelog
--- 389-ds-base-3.0.2+dfsg1/debian/changelog2024-04-25 10:34:47.0 
+
+++ 389-ds-base-3.0.2+dfsg1/debian/changelog2024-05-27 07:44:54.0 
+
@@ -1,3 +1,10 @@
+389-ds-base (3.0.2+dfsg1-1.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Relax cargo dependency on lru
+
+ -- Peter Michael Green   Mon, 27 May 2024 07:44:54 +
+
 389-ds-base (3.0.2+dfsg1-1) experimental; urgency=medium
 
   * New upstream release.
diff -Nru 389-ds-base-3.0.2+dfsg1/debian/vendor/concread/.cargo-checksum.json 
389-ds-base-3.0.2+dfsg1/debian/vendor/concread/.cargo-checksum.json
--- 389-ds-base-3.0.2+dfsg1/debian/vendor/concread/.cargo-checksum.json 
2024-04-22 15:15:53.0 +
+++ 389-ds-base-3.0.2+dfsg1/debian/vendor/concread/.cargo-checksum.json 
2024-05-27 07:44:54.0 +
@@ -1 +1 @@
-{"files":{"CACHE.md":"258e585db81ee9582e1f7e7246026b49b3f617dae4459ec52437024b00ba5dff","CODE_OF_CONDUCT.md":"f32933e0090f012d336e8b2f2301967e8a27cbc896aa3860811a944d05b58964","CONTRIBUTORS.md":"1edff6e840fc50412ac698cd7e5ebe660574760b492d4febe94feb0c066b062f","Cargo.toml":"5f835dd7ba73fa096d0dc20b1a1ab77cd326a7b31518c43d201fccc1a8766bc9","LICENSE.md":"32ee9dbf6196874fc9d406c54a888a6c4cbb9aa4a7f35b46befeaff43a78fe85","Makefile":"de35f7df990b5c047785da63ad560ecadac746bf19d2ab8457fc2ba0224ad46a","README.md":"f70aafccb01764a1aa4d83e3f7fbeab245f7bfa3d3bafecea9614439ff97b487","asan_test.sh":"7355f359e34a6198e895c18fbb616fa45a44666c0a82787f704454e83687be4c","benches/arccache.rs":"6f1f23abb2b577c21aa7ee3d4bd7413fcb49a60d59b1220e1afaeda99f4e6b0e","benches/hashmap_benchmark.rs":"306d085f88f7ce40b8709aff37375482f8edb3c891cbb3da5d9d70a95c2d6cca","src/arcache/ll.rs":"2bd7eb2e73f80112765a0e1792edc27b58269dfc419498ef02ad68fb63141abc","src/arcache/mod.rs":"5911e162123373e241a6bf2b6355cda5480f9ff2f3fa2901c08a7010ad82c00a","src/arcache/traits.rs":"09ea380ea38efe3e35c2036a2ae233388a5367706d155c4aa3c9234d03eef8ea","src/bptree/asynch.rs":"69eff00e05b7b85a12468304374422b2ce1d8598b50918b0efe6eb77036249a4","src/bptree/impl.rs":"b54a7d53e23bf0ff23ebd43ea7ab19708cc383766706051f207bfb62f5e64793","src/bptree/mod.rs":"5e8d2004865dd2064a550070ca3b49a1975ac877cd6749f035806335f3a393a1","src/cowcell/asynch.rs":"04a1c424c083625f92524547bd21d20aadec4d20e2eedfff4db90f2aef920d6c","src/cowcell/mod.rs":"621c243c301f80ebcf65a636489c9450e22940bc5bc9cfb1e5db7943f4e3543f","src/ebrcell/mod.rs":"cf2a2042ac41039ca5fb4212f1fec58bfa1695b88f9c7f7864e01dafa84ccf35","src/hashmap/asynch.rs":"f8418906a23cf06e73fb1330988da4ab0f53ae58c4d5fd58ab5105f8fcbcc414","src/hashmap/impl.rs":"9695dcfde2fd6b27766a225d6390a44cc757ebf9b2f5879f6f1b9a7f29dc","src/hashmap/mod.rs":"bbd33d7f50a28b9a1254d4aaed72f5122e9f01e68e0c43331f90582a17056657","src/internals/bptree/cursor.rs":"83b250db73eb09e1cf7367e8c33700e9b9659695fd565e813549b7f20f9ba777","src/internals/bptree/iter.rs":"dfcf50a3ff5b052dc719b2c68b0bafcfdd0c0c8d8173f3e227a7dd6c8f1be773","src/internals/bptree/macros.rs":"568826a43238474d1f92f7dbf1671690790b35a3b8c88d0d6c5dd35aca54857a","src/internals/bptree/mod.rs":"67ba38e16d96c0d239b72cf0b7be5f27a7a82a29e3a31afc5477175f92b4c57f","src/internals/bptree/node.rs":"afe7217f187d5d7a086dab3bc6fadbae0456e4f8518aa12153f877590380d585","src/internals/bptree/states.rs":"da1ce34cbe6bc449e9e5172ed1fd2a296f2ac197b17ca855f2d40aada7d32a63","src/internals/hashmap/cursor.rs":"7d9c47d7e31e984670cd2161be54475dc468df5b00df26dc89f9848eb1a587ea","src/internals/hashmap/iter.rs":"f02f372e34d2af685eebbcc4db71cc5985c904c1bbd14dd13f48921ea58e5c5f","src/internals/hashmap/macros.rs":"f1236cd794e0e8d7ee2e89428b60c1c3437f34e6be32217de2d61dddce7c6b90","src/internals/hashmap/mod.rs":"ffa693b755ef92da14b001e08a1154e263bd9540ae993d4f79ddf5979e2dcbd6","src/internals/hashmap/node.rs":"7d86f28969185f28de91b2c816990f231adb2c5985c4cbf0efcfdd07ae94ef9a","src/inter

Bug#1070706: gtk4 - udebs broken.

[Peter Michael Green]

Package: gtk4
Version: 4.12.5+dfsg-6
Severity: serious

According to britney, gtk4's udebs are uninstallable.

 * ∙ ∙ libgtk-4-1-udeb/amd64 has unsatisfiable dependency
 * ∙ ∙ libgtk-4-1-udeb/arm64 has unsatisfiable dependency
 * ∙ ∙ libgtk-4-1-udeb/i386 has unsatisfiable dependency
 * ∙ ∙ libgtk-4-1-udeb/mips64el has unsatisfiable dependency
 * ∙ ∙ libgtk-4-1-udeb/ppc64el has unsatisfiable dependency
 * ∙ ∙ libgtk-4-1-udeb/s390x has unsatisfiable dependency
 * ∙ ∙ migrating libgtk-4-1-udeb/4.12.5+ds-6/amd64 to testing makes
   libvte-2.91-0-udeb/0.75.92-1/amd64
    uninstallable
 * ∙ ∙ migrating libgtk-4-1-udeb/4.12.5+ds-6/arm64 to testing makes
   libvte-2.91-0-udeb/0.75.92-1/arm64
    uninstallable
 * ∙ ∙ migrating libgtk-4-1-udeb/4.12.5+ds-6/i386 to testing makes
   libvte-2.91-0-udeb/0.75.92-1/i386
    uninstallable
 * ∙ ∙ migrating libgtk-4-1-udeb/4.12.5+ds-6/mips64el to testing makes
   libvte-2.91-0-udeb/0.75.92-1/mips64el
    uninstallable
 * ∙ ∙ migrating libgtk-4-1-udeb/4.12.5+ds-6/ppc64el to testing makes
   libvte-2.91-0-udeb/0.75.92-1/ppc64el
    uninstallable
 * ∙ ∙ migrating libgtk-4-1-udeb/4.12.5+ds-6/s390x to testing makes
   libvte-2.91-0-udeb/0.75.92-1/s390x
    uninstallable


This is preventing gtk4 migrating to testing which is leaving many
packages uninstallable in testing on time64 architectures.

Bug#1068608: tfortune dependencies unsatisfiable on 32-bit non-i386 architectures.

[Peter Michael Green]

Package: tfortune
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, tfortune
depends on both liblopsub1 and liblopsub1t64. 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 liblopsub1.

https://launchpadlibrarian.net/720835658/tfortune_1.0.1-1build1_1.0.1-1ubuntu1.diff.gz

Bug#1068602: swtpm-libs - still depends on old libglib2.0-0 after binnmu

[Peter Michael Green]

Package: swtpm-libs
Version: 0.7.1-1.3
Severity: grave
Tags: trixie, sid
User: debian-...@lists.debian.org
Usertag: time-t

After being rebuilt for the time64 transition, swtpm-libs still depends
on libglib2.0-0 rather than libglib2.0-0t64. As a result swtpm-tools
is uninstallable on architectures that are undergoing the time64 transition
(armel, armhf and some debian-ports architectures).

https://qa.debian.org/dose/debcheck/unstable_main/1712466002/packages/swtpm-tools.html#d4ad4752e7c19dd554b6071ae9396bd1

Bug#1068599: ruby-xapian - still depends on old libruby3.1 after binnmu

[Peter Michael Green]

Package: ruby-xapian
Version: 1.4.22-1
Severity: grave
Tags: trixie, sid
User: debian-...@lists.debian.org
Usertag: time-t

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

The following lines in the build log look like a likely culprit.


# The module(s) are linked against libruby2.x but use none of its
# symbols, so there's no dependency generated.  That's unhelpful for
# users and for transitions (https://bugs.debian.org/816775) so
# generate a suitable dependency.
#
# If RUBY_VERSIONS is 2.1 2.2 2.3, Depends: libruby2.3|libruby2.1 |libruby2.2
echo "ruby:Depends=libruby3.1" \
 >> debian/ruby-xapian.substvars

Bug#1068598: spice-client-gtk - still depends on old libusbredir packages after binnmu

[Peter Michael Green]

Package: spice-client-gtk
Version: 0.42-2
Severity: grave
Tags: trixie, sid
User: debian-...@lists.debian.org
Usertag: time-t

After being rebuilt for the time64 transition,
spice-client-gtk still depends on libusbredirhost1 and libusbredirparser1,
rather than the t64 versions of those libraries. 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 extracting the package names from 
dpkg-query.


http://launchpadlibrarian.net/720831479/spice-gtk_0.42-2build2_0.42-2ubuntu1.diff.gz

Alternatively I wonder if the dependencies should simply be dropped, 
spice-client-gtk
depends on libspice-client-glib-2.0-8, which depends on both 
libusbredirhost1t64 and

libusbredirparser1t64.

Bug#1068226: libtrantor1, hardcoded dependency on libssl3

[Peter Michael Green]

Package: libtrantor1
Version: 1.5.12+ds-1
Severity: grave
User: debian-...@lists.debian.org
Usertag: time-t

libtrantor1 was recently binnmu'd for the time_t transition,
however, despite the binnmu, it still depends on the old libssl3
because said dependency is hardcoded in the source package.

Ubuntu removed the dependency with the following changelog
entry.

trantor (1.5.12+ds-1ubuntu1) noble; urgency=medium

  * Drop spurious Depends on libssl3 as package is currently built with no TLS
provider.

 -- Michael Hudson-Doyle   Thu, 21 Mar 2024 15:06:24 
+1300

Please review the situation, and either drop the dependency or
change it to libssl3t64 as you deem appropriate.

Bug#1068224: deepin-movie, dependencies unsatisfiable on 32-bit non-i386 architectures.

[Peter Michael Green]

Package: deepin-movie
Version: 5.10.8-2
Severity: grave
User: debian-...@lists.debian.org
Usertag: time-t

After being rebuilt for the time64 transition, deepin-movie
still depends on libqt5concurrent5. As a
result it is uninstallable on architectures that are undergoing
the time64 transition (armel, armhf and some debian-ports
archictures).

Ubuntu seem to have fixed this by manually changing the
dependency.

Bug#1068223: cyrus-imapd - FTBFS on 32-bit non-i386 architectures

[Peter Michael Green]

Package: cyrus-imapd
Version: 3.8.2-1
Severity: serious
User: debian-...@lists.debian.org
Usertag: time-t

cyrus-imapd is failing to build on the architectures affected by the
time_t transition (armel, armhf, several debian-ports architectures)
with the following error.


unit: fatal(Internal error: assertion failed: cunit/timeofday.c: 113: 
tv.tv_usec != 0x)

A quick look at the code, suggests that the testsuite is trying to
intercept gettimeofday, and this interception is broken by the
time64 changes.

The specific error appears to be cause by calling
the non-time64 gettimeofday function from glibc with the time64
definition of struct timeval, but I suspect there are other issues
with the interception code that will rear their ugly head if that one
is fixed.

Bug#1068222: libappmenu-gtk3-parser0, dependencies unsatisfiable on 32-bit non-i386 architectures.

[Peter Michael Green]

Package: libappmenu-gtk3-parser0
Version: 0.7.6-2.1
Severity: grave
User: debian-...@lists.debian.org
Usertag: time-t

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

Ubuntu already seem to have prepared a fix for this.

Bug#1068221: comet-ms, dependencies unsatisfiable on 32-bit non-i386 architectures.

[Peter Michael Green]

Package: comet-ms
Version: 2019015+cleaned1-4
Severity: grave
User: debian-...@lists.debian.org
Usertag: time-t

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

Bug#1068219: chatty, dependencies unsatisfiable on 32-bit non-i386 architectures.

[Peter Michael Green]

Package: chatty
Version: 0.8.2-1
Severity: serious
User: debian-...@lists.debian.org
Usertag: time-t

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

Bug#1066248: librnd: FTBFS: ../src/librnd/plugins/hid_lesstif/main.c:261:25: error: implicit declaration of function ‘lesstif_attr_sub_update_hidlib’ [-Werror=implicit-function-declaration]

[Peter Michael Green]

tags 1066248 +patch
thanks

The functions in question are defined in 
src/librnd/plugins/hid_lesstif/dialogs.c

and used in src/librnd/plugins/hid_lesstif/main.c

My first attempt at fixing the issue was to declare the functions in 
dialogs.h

and include dialogs.h in main.c, however doing so caused errors with
conflicting type definitions, so I just defined them directly in main.c 
instead.


while working on this issue I discovered that the clean target was not
cleaning up properly, so I fixed that too.

A debdiff is attatched.

Review and upload would be appreciated since this blocks the time_t
transition
diff -Nru librnd-4.1.1/debian/changelog librnd-4.1.1/debian/changelog
--- librnd-4.1.1/debian/changelog   2024-02-28 17:20:34.0 +
+++ librnd-4.1.1/debian/changelog   2024-04-02 04:43:46.0 +
@@ -1,3 +1,11 @@
+librnd (4.1.1-1.2) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Add missing function declarations.
+  * Fix clean target.
+
+ -- Peter Michael Green   Tue, 02 Apr 2024 04:43:46 +
+
 librnd (4.1.1-1.1) unstable; urgency=medium
 
   * Non-maintainer upload.
diff -Nru librnd-4.1.1/debian/patches/add-missing-function-declaration.patch 
librnd-4.1.1/debian/patches/add-missing-function-declaration.patch
--- librnd-4.1.1/debian/patches/add-missing-function-declaration.patch  
1970-01-01 00:00:00.0 +
+++ librnd-4.1.1/debian/patches/add-missing-function-declaration.patch  
2024-04-02 04:42:54.0 +
@@ -0,0 +1,14 @@
+Index: librnd-4.1.1/src/librnd/plugins/hid_lesstif/main.c
+===
+--- librnd-4.1.1.orig/src/librnd/plugins/hid_lesstif/main.c
 librnd-4.1.1/src/librnd/plugins/hid_lesstif/main.c
+@@ -51,6 +51,9 @@
+ 
+ #include 
+ 
++void lesstif_attr_dlg_free_all(void);
++void lesstif_attr_sub_update_hidlib(void *hid_ctx, rnd_design_t *new_dsg);
++
+ const char *lesstif_cookie = "lesstif HID";
+ 
+ rnd_design_t *ltf_hidlib;
diff -Nru librnd-4.1.1/debian/patches/series librnd-4.1.1/debian/patches/series
--- librnd-4.1.1/debian/patches/series  2024-01-13 09:12:54.0 +
+++ librnd-4.1.1/debian/patches/series  2024-04-02 04:21:58.0 +
@@ -0,0 +1 @@
+add-missing-function-declaration.patch
diff -Nru librnd-4.1.1/debian/rules librnd-4.1.1/debian/rules
--- librnd-4.1.1/debian/rules   2024-01-13 09:12:54.0 +
+++ librnd-4.1.1/debian/rules   2024-04-02 04:43:46.0 +
@@ -21,6 +21,10 @@
 override_dh_auto_clean:
# only try to run dh_auto_clean if configure has been run
test -f Makefile.conf && dh_auto_clean || true
+   find . -name *.o -delete
+   find . -name *.so.* -delete
+   rm -f scconfig/aru
+   rm -f doc/conf/tree/editor_global_grid.html 
doc/conf/tree/editor_local_grid.html src/librnd/plugins/lib_hid_gl/draw_INIT.h 
src/librnd/poly/polyconf.h src/librnd/polybool/polyconf.h
 
 override_dh_auto_configure:
./configure \

Bug#1067391: bitlbee-facebook: redundant dependency on libglib2.0-0

[Peter Michael Green]

severity 1067391 serious
thanks

After rebuilding for the time64 transition, bitlbee-facebook depends on
both libglib2.0-0 and libglib2.0-0t64. As a result it is uninstallable on
architectures affected by the time64 transition (armel, armhf and
several unofficial ports).

Bug#1068217: atomes, dependencies unsatisfiable on 32-bit non-i386 architectures.

[Peter Michael Green]

Package: atomes
Version: 1.1.12+repack-2
Severity: grave
User: debian-...@lists.debian.org
Usertag: time-t

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

This applies to both versions 1.1.12+repack-2 and 1.1.14-1

Bug#1066392: gtk2-engines-murrine: FTBFS: ./src/murrine_style.c:133:30: error: implicit declaration of function ‘murrine_widget_is_ltr’; did you mean ‘murrine_widget_is_rgba’? [-Werror=implicit-functi

[Peter Michael Green]

tags 1066392 +patch
thanks

I've whipped up a patch that adds the missing function declarations to
the headers.

Review and upload would be appreciated as this is needed for the
time64 transition (and is a key package, so can't simply be autoremoved).
diff -Nru gtk2-engines-murrine-0.98.2/debian/changelog 
gtk2-engines-murrine-0.98.2/debian/changelog
--- gtk2-engines-murrine-0.98.2/debian/changelog2019-11-18 
08:32:18.0 +
+++ gtk2-engines-murrine-0.98.2/debian/changelog2024-04-02 
02:51:30.0 +
@@ -1,3 +1,11 @@
+gtk2-engines-murrine (0.98.2-3.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Add declarations for functions to fix implicit function declaration
+errors.
+
+ -- Peter Michael Green   Tue, 02 Apr 2024 02:51:30 +
+
 gtk2-engines-murrine (0.98.2-3) unstable; urgency=medium
 
   [ Mike Gabriel ]
diff -Nru 
gtk2-engines-murrine-0.98.2/debian/patches/add-missing-function-declarations.patch
 
gtk2-engines-murrine-0.98.2/debian/patches/add-missing-function-declarations.patch
--- 
gtk2-engines-murrine-0.98.2/debian/patches/add-missing-function-declarations.patch
  1970-01-01 00:00:00.0 +
+++ 
gtk2-engines-murrine-0.98.2/debian/patches/add-missing-function-declarations.patch
  2024-04-02 02:51:30.0 +
@@ -0,0 +1,31 @@
+Description: Add declarations for functions to fix implicit function 
declaration errors.
+Author: Peter Michael Green 
+
+--- gtk2-engines-murrine-0.98.2.orig/src/murrine_rc_style.h
 gtk2-engines-murrine-0.98.2/src/murrine_rc_style.h
+@@ -155,4 +155,6 @@ struct _MurrineRcStyleClass
+ 
+ GType murrine_rc_style_get_type   (void);
+ 
++void murrine_rc_style_register_types (GTypeModule *module);
++
+ #endif /* MURRINE_RC_STYLE_H */
+--- gtk2-engines-murrine-0.98.2.orig/src/murrine_style.h
 gtk2-engines-murrine-0.98.2/src/murrine_style.h
+@@ -102,5 +102,6 @@ struct _MurrineStyleClass
+ };
+ 
+ GType murrine_style_get_type (void);
++void murrine_style_register_types (GTypeModule *module);
+ 
+ #endif /* MURRINE_STYLE_H */
+--- gtk2-engines-murrine-0.98.2.orig/src/support.h
 gtk2-engines-murrine-0.98.2/src/support.h
+@@ -149,4 +149,7 @@ G_GNUC_INTERNAL void murrine_get_noteboo
+ gboolean  *start,
+ gboolean  *end);
+ 
++gboolean murrine_object_is_a (const GObject * object, const gchar * 
type_name);
++gboolean murrine_widget_is_ltr (GtkWidget *widget);
++
+ #endif /* SUPPORT_H */
diff -Nru gtk2-engines-murrine-0.98.2/debian/patches/series 
gtk2-engines-murrine-0.98.2/debian/patches/series
--- gtk2-engines-murrine-0.98.2/debian/patches/series   2019-11-12 
09:31:57.0 +
+++ gtk2-engines-murrine-0.98.2/debian/patches/series   2024-04-02 
02:51:30.0 +
@@ -1,2 +1,3 @@
 02_fix-linking-lm.patch
 pango_cairo_update_layout.patch
+add-missing-function-declarations.patch

Bug#1068216: aqemu, dependencies unsatisfiable on 32-bit non-i386 architectures.

[Peter Michael Green]

Package: aqemu
Version: 0.9.2-3
Severity: serious
User: debian-...@lists.debian.org
Usertag: time-t

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

Bug#966249: appstream-generator FTBFS with gdc

[Peter Michael Green]

severity 966249 serious
thanks


That's actually an issue with GDC, it only supports a really old
standard library version currently (will be resolved with GDC 11,
apparently), and supporting multiple standard library versions is a
massive pain. I lowered the issue priority to wishlist, since GDC has
never built this package successfully on the platforms where it is
default so far - maybe GCC 11 will resolve this for good :-)

Versions 0.8.8-1 and versions 0.9.0-1 built successfully with
gdc on armel, armhf and s390x.

However 0.9.1-1 failed to build with an internal compiler
error on those architectures.

Either a fix/workaround needs to be found for the internal
compiler error, or if this is not possible the outdated
binaries need to be removed.

Bug#1064708: pygame: FTBFS: AssertionError: "No video mode" does not match "Parameter 'surface' is invalid"

[Peter Michael Green]

severity 1064708 important

Can you explain why you downgraded this bug? it looks rc to me
and is blocking the time_t transition.

Bug#1068170: 'rust-apr: FTBFS on non-amd64/mips64el: error[E0308]: arguments to this function are incorrect'

[Peter Michael Green]

It looks like there are two separate issues here.

arm64, ppc64el, riscv64, s390x and ppc64el are failing because
the c type char is unsigned on those platforms, which means the
rust type c_char is an alias for u8 instead of i8. Probably just
needs some casts adjusting.

armel, armhf, i386 and powerpc are failing with

> thread 'main' panicked at 'Failed to generate bindings: 
ClangDiagnostic("/usr/include/apr-1.0/apr.h:381:10: error: unknown type 
name 'off64_t'\n")', build.rs:60:10


From some googling, it looks like _LARGEFILE64_SOURCE needs to
be defined when calling bindgen.

Bug#1068178: aegean, dependencies unsatisfiable on 32-bit non-i386 architectures.

[Peter Michael Green]

Package: aegean
Version: 0.16.0+dfsg-3
Severity: serious
User: debian-...@lists.debian.org
Usertag: time-t

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

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

[Peter Michael Green]

Package: python-cryptography
Version: 41.0.7-5
Severity: serious
x-debbugs-cc: eam...@debian.org, kapo...@melix.org


python-cryptography build-depends on python3-cryptography-vectors (<< 
41.0.8~)

but unstable has version 42.0.5-1

If you need rust package updates to fix this issue, please tell me what 
they are and

I will see what I can do.

This is blocking the time64 transition for python-cryptography.

Bug#1019042: [Pkg-rust-maintainers] Bug#1019042: rust-qwertone: FTBFS - dep issue

[Peter Michael Green]

I partially started to patch gtk3-rs to use the newer glib from
experimental. However,  this is not really supported and I'd rather
remove it now that it's EOL. For qwertone we can employ partial
vendoring; this will also need to be done for squeekboard (in progress).
I'd appreciate if you agree on vendoring gtk3-rs in so I can go ahead
with my removal plans.

This might be the best solution going forward.

Personally, if we are going to keep gtk3-rs around, particularly
if two or more apps are using it, I'd much rather it be in
the form of individually packaged crates than as vendored
copies in application packages.

How much overlap is there between the gtk3-rs and gtk4-rs
stacks? how many semver-suffix packages would we have
to introduce if we wanted to keep the gtk3 stack the way
it is while upgrading the gtk4 stack.

Bug#1065787: [Pkg-rust-maintainers] Bug#1065787: cargo: 0.70.1+ds1-2+b1 FTBFS on armhf/armel due to uninstallable dependencies

[Peter Michael Green]

The armhf build complains about Extra-Depends: dpkg-dev (>= 1.22.5),
gcc-13 (>= 13.2.0-16.1), libssl-dev (>= 3.1.5-1.1), but I checked and
all of these exists in armhf, so not sure what is going on.

There is a little more information further down the page.

cargo build-depends on:
- cargo:armel (>= 0.56.0)
cargo depends on:
-libssl3  :armel 
(>= 3.0.0)
libssl3t64 conflicts with:
-libssl3  :armel 
(< 3.1.5-1.1)

Rustc and cargo require rustc and cargo to build. Normally this isn't
a huge problem. The previous version is just used to build the new
version. Old and new libraries are normally co-installable.

However, as a result of the time_t transition, many libraries have
had an incompatible ABI change on 32-bit architectures (excluding i386),
but *not* an upstream soname bump. Since the soname has not changed,
the old and new libraries cannot be co-installed.

This will require manual intervention to resolve, either through
cross-building or through building manually in a hacked-up build
environment.

I've certainly seen mention of rustc on #debian-devel recently,
so I think the people handling the time_t transition are already
aware of this.

Bug#1063735: python-maturin - upcoming rust-indexmap update.

[Peter Michael Green]

Package: python-maturin

Now that rust-ahash 0.8 is in trixie and noble I hope to update
rust-hashbrown and rust-indexmap soon to versions 0.14.x
and version 2.x.x respectively. The new versions are currently
available in experimental.

Currently the debian dependency on rust-indexmap
has no upper limit, but the cargo dependency does have
an upper limit.

python-maturin upstream did not make any code changes
when bumping the dependency to 2.x and after removing
the upper limit I was able to build python-maturin
successfully against the new indexmap.

A debdiff is attatched which removes the upper limit
diff -Nru python-maturin-1.3.2/debian/changelog 
python-maturin-1.3.2/debian/changelog
--- python-maturin-1.3.2/debian/changelog   2024-01-21 00:21:43.0 
+
+++ python-maturin-1.3.2/debian/changelog   2024-02-11 03:59:53.0 
+
@@ -1,3 +1,10 @@
+python-maturin (1.3.2-1.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Relax cargo dependency on indexmap.
+
+ -- Peter Michael Green   Sun, 11 Feb 2024 03:59:53 +
+
 python-maturin (1.3.2-1) unstable; urgency=medium
 
   [ Andreas Tille ]
diff -Nru python-maturin-1.3.2/debian/patches/relax-rust-indexmap 
python-maturin-1.3.2/debian/patches/relax-rust-indexmap
--- python-maturin-1.3.2/debian/patches/relax-rust-indexmap 1970-01-01 
00:00:00.0 +
+++ python-maturin-1.3.2/debian/patches/relax-rust-indexmap 2024-02-11 
03:59:33.0 +
@@ -0,0 +1,13 @@
+Index: python-maturin-1.3.2/Cargo.toml
+===
+--- python-maturin-1.3.2.orig/Cargo.toml
 python-maturin-1.3.2/Cargo.toml
+@@ -61,7 +61,7 @@ once_cell = "1.7.2"
+ rustc_version = "0.4.0"
+ semver = "1.0.13"
+ target-lexicon = "0.12.8"
+-indexmap = "1.9.3"
++indexmap = ">= 1.9.3"
+ pyproject-toml = "0.7.0"
+ python-pkginfo = "0.5.5"
+ textwrap = "0.16.0"
diff -Nru python-maturin-1.3.2/debian/patches/series 
python-maturin-1.3.2/debian/patches/series
--- python-maturin-1.3.2/debian/patches/series  2024-01-21 00:21:43.0 
+
+++ python-maturin-1.3.2/debian/patches/series  2024-02-11 03:59:15.0 
+
@@ -18,3 +18,4 @@
 relax-pyproject-toml
 relax-python-pkginfo
 relax-tracing-subscriber
+relax-rust-indexmap

Bug#1063685: closed by Debian FTP Masters (reply to Jonas Smedegaard ) (Bug#1063685: fixed in precious 0.6.0-4)

[Peter Michael Green]

reopen 1063685
thanks

On 11/02/2024 18:27, Debian Bug Tracking System wrote:

This is an automatic notification regarding your Bug report
which was filed against the precious package:

#1063685: precious - upcoming rust-indexmap update.

It has been closed by Debian FTP Masters  (reply to 
Jonas Smedegaard ).
building the new version of precious with the indexmap from experimental 
results in


error: failed to select a version for the requirement `indexmap = 
">=1.9.3, <=2.0.2"`

candidate versions found which didn't match: 2.2.2

Please change the upper limit on the cargo dependency to either < 3 or <= 2.
(personally I think the former is less confusing).

Bug#1063685: precious - upcoming rust-indexmap update.

[Peter Michael Green]

Package: precious

Now that rust-ahash 0.8 is in trixie and noble I hope to update
rust-hashbrown and rust-indexmap soon to versions 0.14
and version 2 respectively. The new versions are currently
available in experimental.

precious does not use hashbrown directly, and already uses
indexmap 2 upstream, so the fix is a simple matter of
dropping a patch and updating the build dependency.

Debdiff is attatched.
diff -Nru precious-0.6.0/debian/changelog precious-0.6.0/debian/changelog
--- precious-0.6.0/debian/changelog 2024-01-30 14:43:30.0 +
+++ precious-0.6.0/debian/changelog 2024-02-11 01:24:39.0 +
@@ -1,3 +1,10 @@
+precious (0.6.0-3.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Drop 2001_indexnap.patch and update build-depends for indexmap 2.
+
+ -- Peter Michael Green   Sun, 11 Feb 2024 01:24:39 +
+
 precious (0.6.0-3) unstable; urgency=medium
 
   * update patch 2001_toml;
diff -Nru precious-0.6.0/debian/control precious-0.6.0/debian/control
--- precious-0.6.0/debian/control   2024-01-30 14:34:12.0 +
+++ precious-0.6.0/debian/control   2024-02-11 01:24:24.0 +
@@ -21,8 +21,8 @@
  librust-filetime-0.2+default-dev (>= 0.2.18),
  librust-globset-0.4+default-dev (>= 0.4.9),
  librust-ignore-0.4+default-dev (>= 0.4.18),
- librust-indexmap-1+default-dev (>= 1.9.1),
- librust-indexmap-1+serde-dev (>= 1.9.1),
+ librust-indexmap-2+default-dev (>= 2.0.2),
+ librust-indexmap-2+serde-dev (>= 2.0.2),
  librust-itertools+default-dev (<< 0.11),
  librust-log-0.4+default-dev (>= 0.4.17),
  librust-md5-0.7+default-dev,
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   2023-12-19 
20:58:05.0 +
+++ precious-0.6.0/debian/patches/2001_indexmap.patch   1970-01-01 
00:00:00.0 +
@@ -1,18 +0,0 @@
-Description: accept older branch of crate indexmap
-Author: Jonas Smedegaard 
-Bug-Debian: https://bugs.debian.org/1053953
-Forwarded: not-needed
-Last-Update: 2023-12-19

-This patch header follows DEP-3: http://dep.debian.net/deps/dep3/
 a/Cargo.toml
-+++ b/Cargo.toml
-@@ -35,7 +35,7 @@
- filetime = "0.2.22"
- globset = "0.4.13"
- ignore = "0.4.20"
--indexmap = { version = "2.0.2", features = ["serde"] }
-+indexmap = { version = ">= 1.9.3, <= 2.0.2", features = ["serde"] }
- itertools = ">= 0.9.0, < 0.11.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/series2023-11-28 23:56:05.0 
+
+++ precious-0.6.0/debian/patches/series2024-02-11 01:23:59.0 
+
@@ -1,4 +1,3 @@
 2001_comfy-table.patch
-2001_indexmap.patch
 2001_toml.patch
 2002_privacy.patch

Bug#1063682: loupe - upcoming rust-hashbrown update.

[Peter Michael Green]

Package: loupe

Now that rust-ahash 0.8 is in trixie and noble I hope to update
rust-hashbrown and rust-indexmap soon to versions 0.14
and version 2 respectively. The new versions are currently
available in experimental.

loupe does not use hashbrown directly, and already uses
indexmap 2 upstream, so the fix is a simple matter of
dropping a patch and updating the build dependency.

Debdiff is attatched.diff -Nru loupe-45.3/debian/changelog loupe-45.3/debian/changelog
--- loupe-45.3/debian/changelog 2024-02-08 13:16:52.0 +
+++ loupe-45.3/debian/changelog 2024-02-10 22:30:45.0 +
@@ -1,3 +1,10 @@
+loupe (45.3-2.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Stop patching indexmap dependency and update build-depends accordingly.
+
+ -- Peter Michael Green   Sat, 10 Feb 2024 22:30:45 +
+
 loupe (45.3-2) unstable; urgency=medium
 
   * Enable sandboxing for glycin-loaders; this was wrongfully enabled
diff -Nru loupe-45.3/debian/control loupe-45.3/debian/control
--- loupe-45.3/debian/control   2024-02-08 12:55:23.0 +
+++ loupe-45.3/debian/control   2024-02-10 22:30:45.0 +
@@ -36,7 +36,7 @@
  librust-gtk4-0.7+v4-12-dev (>= 0.7.1-~~),
  librust-gtk4-0.7+xml-validation-dev (>= 0.7.1-~~),
  librust-gvdb-macros-0.1+default-dev (>= 0.1.10-~~),
- librust-indexmap-1+default-dev,
+ librust-indexmap-2+default-dev,
  librust-kamadak-exif-0.5+default-dev (>= 0.5.5-~~),
  librust-libadwaita-0.5+default-dev (>= 0.5.2-~~),
  librust-libadwaita-0.5+v1-4-dev (>= 0.5.2-~~),
diff -Nru loupe-45.3/debian/patches/relax-deps.diff 
loupe-45.3/debian/patches/relax-deps.diff
--- loupe-45.3/debian/patches/relax-deps.diff   2024-02-08 12:55:23.0 
+
+++ loupe-45.3/debian/patches/relax-deps.diff   1970-01-01 00:00:00.0 
+
@@ -1,25 +0,0 @@
-From: Matthias Geiger 
-Date: Wed, 4 Oct 2023 14:44:44 -0400
-Subject: Relax dependencies in Cargo.toml
-
-Debian and upstream crates versions often differ. So we relax the versions.
-
-Forwarded: not-needed
-Last-Update: 2023-10-05

- Cargo.toml | 2 +-
- 1 file changed, 1 insertion(+), 1 deletion(-)
-
-diff --git a/Cargo.toml b/Cargo.toml
-index 0242c68..837e3e2 100644
 a/Cargo.toml
-+++ b/Cargo.toml
-@@ -21,7 +21,7 @@ env_logger = "0.10.0"
- futures = "0.3.25"
- glycin = "0.1.0"
- gvdb-macros = "0.1.6"
--indexmap = "2.0.0"
-+indexmap = "1.9"
- kamadak-exif = "0.5.5"
- libgweather = "4.3.0"
- log = "0.4.17"
diff -Nru loupe-45.3/debian/patches/series loupe-45.3/debian/patches/series
--- loupe-45.3/debian/patches/series2024-02-08 12:55:23.0 +
+++ loupe-45.3/debian/patches/series2024-02-10 22:29:37.0 +
@@ -1,2 +1 @@
-relax-deps.diff
 patch-meson-build.diff

Bug#1063676: rust-ahash - upcoming rust-hashbrown update.

[Peter Michael Green]

Package: rust-ahash

Now that rust-ahash 0.8 is in trixie and noble I hope to update
rust-hashbrown and rust-indexmap soon to versions 0.14
and version 2 respectively.

ahash has a dev-dependency on hashbrown which the current
packaging translates into a build-dependency and a
test-dependency. After bumping these dependencies the
package builds/and runs autopkgtests fine.
diff -Nru rust-ahash-0.8.7/debian/changelog rust-ahash-0.8.7/debian/changelog
--- rust-ahash-0.8.7/debian/changelog   2024-02-06 19:01:40.0 +
+++ rust-ahash-0.8.7/debian/changelog   2024-02-10 21:45:21.0 +
@@ -1,3 +1,10 @@
+rust-ahash (0.8.7-4.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Bump hasbrown dev-dependency to 0.14.
+
+ -- Peter Michael Green   Sat, 10 Feb 2024 21:45:21 +
+
 rust-ahash (0.8.7-4) unstable; urgency=medium
 
   * relax to declare most package relations unversioned:
diff -Nru rust-ahash-0.8.7/debian/control rust-ahash-0.8.7/debian/control
--- rust-ahash-0.8.7/debian/control 2024-02-06 18:58:48.0 +
+++ rust-ahash-0.8.7/debian/control 2024-02-10 21:43:07.0 +
@@ -12,7 +12,7 @@
  librust-fnv-1+default-dev ,
  librust-fxhash-0.2+default-dev ,
  librust-getrandom-0.2+default-dev ,
- librust-hashbrown-0.12+default-dev ,
+ librust-hashbrown-0.14+default-dev ,
  librust-hex-0.4+default-dev ,
  librust-no-panic-0.1+default-dev ,
  librust-once-cell-1+alloc-dev ,
diff -Nru rust-ahash-0.8.7/debian/patches/1003_hashbrown.patch 
rust-ahash-0.8.7/debian/patches/1003_hashbrown.patch
--- rust-ahash-0.8.7/debian/patches/1003_hashbrown.patch1970-01-01 
00:00:00.0 +
+++ rust-ahash-0.8.7/debian/patches/1003_hashbrown.patch2024-02-10 
21:45:21.0 +
@@ -0,0 +1,14 @@
+Description: Bump hasbrown dev-dependency to 0.14.
+Author: Peter Michael Green 
+
+--- rust-ahash-0.8.7.orig/Cargo.toml
 rust-ahash-0.8.7/Cargo.toml
+@@ -95,7 +95,7 @@ fxhash = "0.2.1"
+ hex = "0.4.2"
+ rand = "0.8.5"
+ serde_json = "1.0.59"
+-hashbrown = "0.12.3"
++hashbrown = "0.14"
+ 
+ [package.metadata.docs.rs]
+ rustc-args = ["-C", "target-feature=+aes"]
diff -Nru rust-ahash-0.8.7/debian/patches/series 
rust-ahash-0.8.7/debian/patches/series
--- rust-ahash-0.8.7/debian/patches/series  2024-02-01 20:48:14.0 
+
+++ rust-ahash-0.8.7/debian/patches/series  2024-02-10 21:45:21.0 
+
@@ -1,5 +1,6 @@
 0_bigendian.patch
 1001_bench_overflow.patch
 1002_test_feature_requirements.patch
+1003_hashbrown.patch
 2001_zerocopy.patch
 2002_no_nightly.patch
diff -Nru rust-ahash-0.8.7/debian/tests/control 
rust-ahash-0.8.7/debian/tests/control
--- rust-ahash-0.8.7/debian/tests/control   2024-02-06 18:58:28.0 
+
+++ rust-ahash-0.8.7/debian/tests/control   2024-02-10 21:45:21.0 
+
@@ -8,7 +8,7 @@
  librust-criterion-0.3+html-reports-dev,
  librust-fnv-1+default-dev,
  librust-fxhash-0.2+default-dev,
- librust-hashbrown-0.12+default-dev,
+ librust-hashbrown-0.14+default-dev,
  librust-hex-0.4+default-dev,
  librust-no-panic-0.1+default-dev,
  librust-rand-0.8+default-dev,
@@ -26,7 +26,7 @@
  librust-criterion-0.3+html-reports-dev,
  librust-fnv-1+default-dev,
  librust-fxhash-0.2+default-dev,
- librust-hashbrown-0.12+default-dev,
+ librust-hashbrown-0.14+default-dev,
  librust-hex-0.4+default-dev,
  librust-no-panic-0.1+default-dev,
  librust-rand-0.8+default-dev,
@@ -44,7 +44,7 @@
  librust-criterion-0.3+html-reports-dev,
  librust-fnv-1+default-dev,
  librust-fxhash-0.2+default-dev,
- librust-hashbrown-0.12+default-dev,
+ librust-hashbrown-0.14+default-dev,
  librust-hex-0.4+default-dev,
  librust-no-panic-0.1+default-dev,
  librust-rand-0.8+default-dev,
@@ -62,7 +62,7 @@
  librust-criterion-0.3+html-reports-dev,
  librust-fnv-1+default-dev,
  librust-fxhash-0.2+default-dev,
- librust-hashbrown-0.12+default-dev,
+ librust-hashbrown-0.14+default-dev,
  librust-hex-0.4+default-dev,
  librust-no-panic-0.1+default-dev,
  librust-rand-0.8+default-dev,
@@ -80,7 +80,7 @@
  librust-criterion-0.3+html-reports-dev,
  librust-fnv-1+default-dev,
  librust-fxhash-0.2+default-dev,
- librust-hashbrown-0.12+default-dev,
+ librust-hashbrown-0.14+default-dev,
  librust-hex-0.4+default-dev,
  librust-no-panic-0.1+default-dev,
  librust-rand-0.8+default-dev,
@@ -98,7 +98,7 @@
  librust-criterion-0.3+html-reports-dev,
  librust-fnv-1+default-dev,
  librust-fxhash-0.2+default-dev,
- librust-hashbrown-0.12+default-dev,
+ librust-hashbrown-0.14+default-dev,
  librust-hex-0.4+default-dev,
  librust-no-panic-0.1+default-dev,
  librust-rand-0.8+default-dev,
@@ -116,7 +116,7 @@
  librust-criterion-0.3+html-reports-dev,
  librust-fnv-1+default-dev,
  librust-fxhash-0.2+default-dev,
- librust-hashbrown-0.12+default-dev,
+ librust-hashbrown-0.14+default-dev,
  librust-hex-0.4+default-dev,
  librust-no-panic-0.1+default-dev,
  librust-rand-0.8+default-de

Bug#1061677: settle - upcoming dialoguer update.

[Peter Michael Green]

Package: settle
Version: 0.40-1-2

I'm currently looking at updating rust-dialoguer, settle is one of
the reverse dependencies.

Looking at the upstream changelog, I don't see anything too
scary and I've done a test build with the dependency bumped
and it built successfully.

I've uploaded the new version of dialoguer to experimental if
you want to do further testing.

Bug#1060157: librust-asn1-dev: please update to a more recent version

[Peter Michael Green]

a more recent version of librust-asn1-dev (>= 0.15) is needed
to be able to update to python3-cryptography (>= 0.41) which
in turn is required by some other package.

I've uploaded the new versions of rust-asn1 and rust-asn1-derive
to experimental,  python-cryptography seems to be the only reverse
dependency so you should be ok to re-upload them to
unstable at the same time as you upload the corresponding
version of python-cryptography.

Bug#1059812: elan - dependency updates.

[Peter Michael Green]

Package: elan
Version: 3.0.0-1
Severity: serious

I just updated the rust-term package, from 0.5 to 0.7
as a result elan needs to stop patching it's cargo
dependency on term and update it's Debian
build-dependency.

While doing test builds I noticed a couple of other
dependency issues.

The Debian build-dependency for the toml crate
was not strict enough, debian currently ships two
versions of the toml crate and only the wrong one
was installed in my test environment resulting in
a build failure. So I tightened the dependency to
only allow the correct one.

The package has a cargo dependency on the
"dirs" crate, but there was no corresponding
Debian build-dependency. I presume it was
missed because it was previously pulled in
indirectly but this was no longer the case in
my tests. So I added a Debian build-dependency.

A debdiff is attached. If I get no response I'll
probablly NMU this in a week or so.diff -Nru elan-3.0.0/debian/changelog elan-3.0.0/debian/changelog
--- elan-3.0.0/debian/changelog 2023-09-26 19:22:31.0 +
+++ elan-3.0.0/debian/changelog 2024-01-01 18:34:48.0 +
@@ -1,3 +1,17 @@
+elan (3.0.0-1.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Dependency updates/fixes:
++ Stop patching Cargo dependency on "term" crate and update Debian
+  dependency accordingly. Debian has now updated to term 0.7
++ Be more specific in Debian dependency for "toml" crate, Debian currently
+  has multiple versions of toml and the previous dependency could be
+  satisfied by the wrong one.
++ Add a Debian dependency on "dirs" crate (which appeard to simply be
+      missing before.
+
+ -- Peter Michael Green   Mon, 01 Jan 2024 18:34:48 +
+
 elan (3.0.0-1) unstable; urgency=medium
 
   * Fix "FTBFS: dh_auto_test: error: /usr/share/cargo/bin/cargo build
diff -Nru elan-3.0.0/debian/control elan-3.0.0/debian/control
--- elan-3.0.0/debian/control   2023-09-26 19:19:14.0 +
+++ elan-3.0.0/debian/control   2024-01-01 18:34:48.0 +
@@ -19,9 +19,9 @@
  librust-sha2-dev,
  librust-tar-dev,
  librust-tempfile-dev,
- librust-term-dev,
+ librust-term-0.7+default-dev,
  librust-time-dev,
- librust-toml-dev,
+ librust-toml-0.7+default-dev (>= 0.7.6),
  librust-url-dev,
  librust-wait-timeout-dev,
  librust-zip-dev,
@@ -30,6 +30,7 @@
  librust-clap-2+vec-map-dev (>= 2.33.3),
  librust-clap-2+ansi-term-dev (>= 2.33.3),
  librust-curl-dev,
+ librust-dirs-5+default-dev,
  librust-walkdir-dev,
  librust-openssl-dev,
  librust-semver-0.9-dev,
diff -Nru elan-3.0.0/debian/patches/0002-dependencies.patch 
elan-3.0.0/debian/patches/0002-dependencies.patch
--- elan-3.0.0/debian/patches/0002-dependencies.patch   2023-09-26 
19:19:14.0 +
+++ elan-3.0.0/debian/patches/0002-dependencies.patch   2024-01-01 
18:33:54.0 +
@@ -27,8 +27,7 @@
 -sha2 = "0.9.2"
 +sha2 = "0.10.5"
  tempfile = "3.2.0"
--term = "0.7.0"
-+term = "0.5.2"
+ term = "0.7.0"
  time = "0.3.4"
 -toml = "0.5.8"
 +toml = "0.7.6"

Bug#1059701: sccache - upcoming rust-object update

[Peter Michael Green]

Package: sccache
Version: 0.7.4-3

I have been working on an update of rust-backtrace and it's
dependencies, backtrace itself is not semver breaking, but
several of it's dependencies are.

backtrace 0.3.68 -> 0.3.69
addr2line 0.20.0 -> 0.21.0
fallible-iterator 0.2.0 -> 0.3.0
gimli 0.27.3 -> 0.28.1
object 0.31.1 -> 0.32.1

Your package depends on object, I have looked at the
upstream changelog and didn't see anything too scary
and I've built your package with the dependency bumped,
the package has no autopkgtests.

If you want to do further testing the new version of
the packages are available in experimental.

Bug#1059675: rust-ahash - autopkgtest failure on s390x.

[Peter Michael Green]

Package: rust-ahash
Version: 0.8.5-4
Severity: serious

Thanks for uploading my autopkgtest fixes, the tests now pass on most
architectures.

Unfortunately they still fail on s390x.



290s  operations::test::test_add_length stdout 
290s thread 'operations::test::test_add_length' panicked at 'assertion 
failed: `(left == right)`

290s left: `18446744073709551614`,
290s right: `18446744073709551615`', src/operations.rs:373:9
290s stack backtrace:
290s 0: rust_begin_unwind
290s at /usr/src/rustc-1.70.0/library/std/src/panicking.rs:578:5
290s 1: core::panicking::panic_fmt
290s at /usr/src/rustc-1.70.0/library/core/src/panicking.rs:67:14
290s 2: core::panicking::assert_failed_inner
290s 3: core::panicking::assert_failed
290s at /usr/src/rustc-1.70.0/library/core/src/panicking.rs:228:5
290s 4: ahash::operations::test::test_add_length
290s at ./src/operations.rs:373:9
290s 5: ahash::operations::test::test_add_length::{{closure}}
290s at ./src/operations.rs:370:26
290s 6: core::ops::function::FnOnce::call_once
290s at /usr/src/rustc-1.70.0/library/core/src/ops/function.rs:250:5
290s 7: core::ops::function::FnOnce::call_once
290s at /usr/src/rustc-1.70.0/library/core/src/ops/function.rs:250:5
290s note: Some details are omitted, run with `RUST_BACKTRACE=full` 
for a verbose backtrace.


This smells like an endian issue to me, but I don't know how serious
it is, so I've filed an upstream issue.

Bug#1057059: rust-serde-with: please update to v3.4.0

[Peter Michael Green]

Version 3.4.0-1


Please update to at least v3.4.0.

Done

Bug#1057368: git-delta - updates for new rust-libgit2-sys and rust-bat

[Peter Michael Green]

Package: git-delta
Version: 0.16.5-3

Due to the recent upload of libgit2, I have just uploaded
new versions of rust-libgit2-sys, rust-git2 and a number
of their reverse dependencies.

We enforce a version match (at the major.minor level)
between the rust libgit2 bindings and the libgit2
libraries because we have seen mismatches cause
runtime misbehaviour in the past.

Your package build-depends on two packages which
have bumped semver as part of this update, rust-git2
and rust-bat. The upstream changelogs don't look too
scary and your package built succesfully with the
dependencies bumped. I have attatched a debdiff.

Sorry for the lack of prior warning on this one, we should
have engaged with the libgit2 maintainer earlier, but
noone got around to it and the libgit2 maintainer
and release team eventually went ahead without
waiting for us.
diff -Nru git-delta-0.16.5/debian/changelog git-delta-0.16.5/debian/changelog
--- git-delta-0.16.5/debian/changelog   2023-08-09 08:27:30.0 +
+++ git-delta-0.16.5/debian/changelog   2023-12-03 13:41:55.0 +
@@ -1,3 +1,10 @@
+git-delta (0.16.5-3.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Bump git2 to 0.18 and bat to 0.24.
+
+ -- Peter Michael Green   Sun, 03 Dec 2023 13:41:55 +
+
 git-delta (0.16.5-3) unstable; urgency=medium
 
   * mention unrelated but similarly named package and binary executable
diff -Nru git-delta-0.16.5/debian/control git-delta-0.16.5/debian/control
--- git-delta-0.16.5/debian/control 2023-08-09 07:25:59.0 +
+++ git-delta-0.16.5/debian/control 2023-12-03 13:41:55.0 +
@@ -12,7 +12,7 @@
  librust-ansi-term-0.12+default-dev,
  librust-anyhow-1+default-dev,
  librust-atty-0.2+default-dev,
- librust-bat-0.23+regex-onig-dev,
+ librust-bat-0.24+regex-onig-dev,
  librust-bitflags-2+default-dev,
  librust-box-drawing-0.1+default-dev,
  librust-bytelines-2+default-dev,
@@ -27,7 +27,7 @@
  librust-console-0.15+default-dev,
  librust-ctrlc-3+default-dev,
  librust-dirs-5+default-dev,
- librust-git2-0.16-dev,
+ librust-git2-0.18-dev,
  librust-grep-cli-0.1+default-dev,
  librust-itertools-0.10+default-dev,
  librust-lazy-static-1+default-dev,
diff -Nru git-delta-0.16.5/debian/patches/1001_deps.patch 
git-delta-0.16.5/debian/patches/1001_deps.patch
--- git-delta-0.16.5/debian/patches/1001_deps.patch 2023-08-07 
16:17:37.0 +
+++ git-delta-0.16.5/debian/patches/1001_deps.patch 2023-12-03 
13:41:55.0 +
@@ -10,7 +10,7 @@
  
  [dependencies]
 -bat = { version = "0.22.1", default-features = false, features = 
["regex-onig"] }
-+bat = { version = ">= 0.22.1, < 0.24", default-features = false, features = 
["regex-onig"] }
++bat = { version = ">= 0.22.1, < 0.25", default-features = false, features = 
["regex-onig"] }
  chrono = "0.4.23"
  chrono-humanize = "0.2.2"
 -ansi_colours = "1.2.1"
@@ -49,7 +49,7 @@
  
  [dependencies.git2]
 -version = "0.16.1"
-+version = "0.16"
++version = "0.18"
  default-features = false
  features = []
  

Bug#1055090: rust-backtrace: please update to v0.3.69

[Peter Michael Green]

> Please update to (at least) newer upstream release v0.3.69.

Backtrace itself is not semver breaking, but some of it's dependencies
are.

backtrace 0.3.68 -> 0.3.69
addr2line 0.20.0 -> 0.21.0
fallible-iterator 0.2.0 -> 0.3.0
gimli 0.27.3 -> 0.28.1
object 0.31.1 -> 0.32.1

I've uploaded these to experimental.

Checking out the reverse dependencies:

dwarf2sources - builds ok against new packages, dependency tweak 
required, no autopkgtests
rust-cargo-auditable - builds ok against new packages, dependency tweak 
required, no autopkgtests
rust-elfx86exts - new version builds ok against new packages, no 
autopkgtests.
rust-framehop - needs a patch 
https://github.com/mstange/framehop/issues/12 no rdeps
pdb - has a pre-existing test issue, after dealing with that builds and 
tests fine with dependency bumped.

postgres-protocol - builds and tests ok after dependency bump.
postgres-types - builds and tests ok after dependency bump
tokio-postgres - builds ok after dependency bump, but tests are already 
broken (and marked as such)
postgres - builds ok after dependency bump, but tests are already broken 
(and marked as such)
rusqlite - builds and tests ok after dependency bump, upstream bumped 
with no code changes.
rust-wasmtime (librust-cranelift-dev) - jonas package, builds and 
autopkgtests ok with dependency bumped. 
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1056924

sccache - jonas package, already broken and not in testing.

I've uploaded this to experimental, now waiting to see what
(if-any) responses I get to the bug reports.

Bug#1056924: rust-wasmtime - upcoming rust-object update.

[Peter Michael Green]

Package: rust-wasmtime
Version: 10.0.1+dfsg-7

I currently working on an update of rust-backtrace and it's
dependencies, backtrace itself is not semver breaking, but
several of it's dependencies are.

backtrace 0.3.68 -> 0.3.69
addr2line 0.20.0 -> 0.21.0
fallible-iterator 0.2.0 -> 0.3.0
gimli 0.27.3 -> 0.28.1
object 0.31.1 -> 0.32.1

Your package depends on gimli, I have looked at the
upstream changelog and didn't see anything too scary
and I've built your package with the dependency bumped
and run it's autopkgtests successfully.

If you want to do further testing the new version of
the packages are available in experimental.

Bug#1056735: dgit - improve web interface to git.dgit.debian.org

[Peter Michael Green]

Package: dgit

(this bug report is a result of a question discussion in IANs tag2upload 
talk at the cambridge miniconf 2023)


In the talk Ian made the following points

* the current Salsa approach leads to users accidentlly receiving 
patches unapplied git trees
* In a later slide git.dgit.debian.org was identified as a "canonical 
git repo" where users could
   obtain the "patches applied" trees that correspond to the archive 
contents.
* It was also stated (and is already the case with dgit) that 
git.dgit.debian.org would store
   both the maintainers original git tag (which may or may not be 
patches applied, but usually
   is not), and the "patches applied" tag that corresponds to the 
archive content.


The problem is when a user visits git.dgit.debian.org they just meet a 
generic git web
interface with a list of branches, tags etc. It is not at all clear to a 
user what each

tag means and in particular what the difference between debian/ and
archive/debian/ are (IIRC one is the maintainer tree and one is the
"standardised" tree but it's not at all obvious which is which)

Bug#1056695: dwarf2sources - dependency fix for upcoming update of rust-backtrace and friends.

[Peter Michael Green]

Package: dwarf2sources
Version: 0.2.1-1
Tags: trixie, sid

I am currently preparing an update of rust-backtrace and related crates.
they have been uploaded to experimental and I hope to upload them
to unstable in the not too distant future.

backtrace 0.3.68 -> 0.3.69
addr2line 0.20.0 -> 0.21.0
fallible-iterator 0.2.0 -> 0.3.0
gimli 0.27.3 -> 0.28.1
object 0.31.1 -> 0.32.1

Your package does nor enforce any upper limit on these crates and
seems to build ok against the new versions.

However, your package has a build dependency on
"librust-gimli-0+indexmap-dev (>= 0.26)", the new version of gimli
no longer has an "indexmap" feature (and I don't think it was ever
intended to be a public feature in the first place).

The Cargo dependency makes no mention of indexmap, so I
presume this dependency was set in error.

The attached debdiff changes the dependency to
librust-gimli-0+default-dev (>= 0.26), if I get no response I
will probablly NMU this when I upload the backtrace update.



diff -Nru dwarf2sources-0.2.1/debian/changelog 
dwarf2sources-0.2.1/debian/changelog
--- dwarf2sources-0.2.1/debian/changelog2023-01-01 00:18:06.0 
+
+++ dwarf2sources-0.2.1/debian/changelog2023-11-24 16:51:35.0 
+
@@ -1,3 +1,10 @@
+dwarf2sources (0.2.1-1.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix gimli dependency to not use indexmap feature.
+
+ -- root   Fri, 24 Nov 2023 16:51:35 +
+
 dwarf2sources (0.2.1-1) unstable; urgency=medium
 
   * New upstream release.
diff -Nru dwarf2sources-0.2.1/debian/control dwarf2sources-0.2.1/debian/control
--- dwarf2sources-0.2.1/debian/control  2023-01-01 00:18:06.0 +
+++ dwarf2sources-0.2.1/debian/control  2023-11-24 16:48:07.0 +
@@ -7,7 +7,7 @@
dh-cargo,
librust-anyhow-1-dev,
librust-fallible-iterator-0-dev,
-   librust-gimli-0+indexmap-dev (>= 0.26),
+   librust-gimli-0+default-dev (>= 0.26),
librust-memmap-0-dev (>= 0.7),
librust-object-0+default-dev (>= 0.29),
librust-serde-1+derive-dev,

Bug#1056278: safe-vdash - upcoming rust-crossterm and rust-ratatui updates.

[Peter Michael Green]

Package: safe-vdash

I'm currently in the process of preparing updates for crossterm
to 0.27 and ratatui to 0.23.

save-vdash's cargo dependencies already allow the new
versions (indeed the new versions will allow patches to be
dropped) but the Debian dependencies currently do not.
After bumping the Debian dependecies I was able to build
the package successfully.

If you want to do further testing the new versions of crossterm
and ratatui are available in experimental.

If no problems come to light I intend to upload them to
unstable in a week or so.

Bug#1056275: btm - upcoming rust-ratatui update.

[Peter Michael Green]

Package: btm

I'm currently in the process of preparing updates for crossterm
to 0.27 and ratatui to 0.23.

Btm's dependencies (both cargo and Debian) already allow the
new version of crossterm, but they don't allow the new version
of ratatui. I don't see anything too scary in the upstream
changelog and I've bumped the dependency and was able
to succesfully build the package.

If you want to do further testing the new versions of crossterm
and ratatui are available in experimental.

If no problems come to light I intend to upload them to
unstable in a week or so.

Bug#1056253: rust-ripasso-cursive - FTBFS with rust-ripasso 0.6.4

[Peter Michael Green]

On 19/11/2023 12:14, Peter Michael Green wrote:


Package: rust-ripasso-cursive
Version: 0.6.1-1
Severity: serious
Tags: trixie, sid

It appears, that despite the version number indicating a compatible 
release, that the new

version of ripasso broke the build of ripasso-cursive.

https://tests.reproducible-builds.org/debian/rb-pkg/trixie/amd64/rust-ripasso-cursive.html


error[E0425]: cannot find function `push` in module `pass`
--> src/main.rs:941:29
 |
941 | let push_result = pass::push(().unwrap().lock().unwrap());
 |  not found in `pass`
 |
help: consider importing this function
 |
18  + use ripasso::git::push;
 |
help: if you import `push`, refer to it directly
 |
941 - let push_result = pass::push(().unwrap().lock().unwrap());
941 + let push_result = push(().unwrap().lock().unwrap());
 |

error[E0425]: cannot find function `pull` in module `pass`
--> src/main.rs:953:19
 |
953 | let _ = pass::pull(().unwrap().lock().unwrap())
 |    not found in `pass`
 |
help: consider importing this function
 |
18  + use ripasso::git::pull;
 |
help: if you import `pull`, refer to it directly
 |
953 - let _ = pass::pull(().unwrap().lock().unwrap())
953 + let _ = pull(().unwrap().lock().unwrap())
 |

error[E0603]: function `init_git_repo` is private
   --> src/wizard.rs:32:26
|
32 | let init_res = 
pass::init_git_repo(::password_dir(password_store_dir, home).unwrap());
|  ^ private function
|
note: the function `init_git_repo` is defined here
   --> /usr/share/cargo/registry/ripasso-0.6.4/src/pass.rs:34:60
|
34 | add_and_commit_internal, commit, find_last_commit, init_git_repo, 
match_with_parent,
|^


I tried to update ripasso-cursive to 0.6.4 to match ripasso but I got.

Applying patch unbreak-new-user-wizard.patch
patching file src/main.rs
Hunk #1 succeeded at  with fuzz 1 (offset -58 lines).
Hunk #2 FAILED at 1189.
Hunk #3 succeeded at 1324 with fuzz 1 (offset 109 lines).
Hunk #4 FAILED at 1773.
Hunk #5 FAILED at 1789.
Hunk #6 FAILED at 1798.
Hunk #7 succeeded at 1849 with fuzz 2 (offset 43 lines).
4 out of 7 hunks FAILED -- rejects in file src/main.rs
Patch unbreak-new-user-wizard.patch does not apply (enforce with -f)


Can someone confirm whether this patch is still needed, and if-so
update it for the new upstream version?


For what it's worth I was able to get a succesful build by.

1. Upgrading ripasso-cursive to 0.6.3 (0.6.4 has a new dependency that 
is not in Debian)

2. Disabling unbreak-new-user-wizard.patch and translation-locations.patch

I would still like feedback from Alexander on whether those patches are 
still

relavent.

Bug#1056253: rust-ripasso-cursive - FTBFS with rust-ripasso 0.6.4

[Peter Michael Green]

Package: rust-ripasso-cursive
Version: 0.6.1-1
Severity: serious
Tags: trixie, sid

It appears, that despite the version number indicating a compatible 
release, that the new

version of ripasso broke the build of ripasso-cursive.

https://tests.reproducible-builds.org/debian/rb-pkg/trixie/amd64/rust-ripasso-cursive.html


error[E0425]: cannot find function `push` in module `pass`
--> src/main.rs:941:29
 |
941 | let push_result = pass::push(().unwrap().lock().unwrap());
 |  not found in `pass`
 |
help: consider importing this function
 |
18  + use ripasso::git::push;
 |
help: if you import `push`, refer to it directly
 |
941 - let push_result = pass::push(().unwrap().lock().unwrap());
941 + let push_result = push(().unwrap().lock().unwrap());
 |

error[E0425]: cannot find function `pull` in module `pass`
--> src/main.rs:953:19
 |
953 | let _ = pass::pull(().unwrap().lock().unwrap())
 |    not found in `pass`
 |
help: consider importing this function
 |
18  + use ripasso::git::pull;
 |
help: if you import `pull`, refer to it directly
 |
953 - let _ = pass::pull(().unwrap().lock().unwrap())
953 + let _ = pull(().unwrap().lock().unwrap())
 |

error[E0603]: function `init_git_repo` is private
   --> src/wizard.rs:32:26
|
32 | let init_res = 
pass::init_git_repo(::password_dir(password_store_dir, home).unwrap());
|  ^ private function
|
note: the function `init_git_repo` is defined here
   --> /usr/share/cargo/registry/ripasso-0.6.4/src/pass.rs:34:60
|
34 | add_and_commit_internal, commit, find_last_commit, init_git_repo, 
match_with_parent,
|^


I tried to update ripasso-cursive to 0.6.4 to match ripasso but I got.

Applying patch unbreak-new-user-wizard.patch
patching file src/main.rs
Hunk #1 succeeded at  with fuzz 1 (offset -58 lines).
Hunk #2 FAILED at 1189.
Hunk #3 succeeded at 1324 with fuzz 1 (offset 109 lines).
Hunk #4 FAILED at 1773.
Hunk #5 FAILED at 1789.
Hunk #6 FAILED at 1798.
Hunk #7 succeeded at 1849 with fuzz 2 (offset 43 lines).
4 out of 7 hunks FAILED -- rejects in file src/main.rs
Patch unbreak-new-user-wizard.patch does not apply (enforce with -f)


Can someone confirm whether this patch is still needed, and if-so
update it for the new upstream version?

Bug#1053637: rust-arrayvec-0.5: Obsolete version of rust-arrayvec

[Peter Michael Green]

It would be nice to remove rust-arrayvec-0.5 to only have one version of
rust-arrayvec in Debian.

We can patch out the arrayvec feature in zvariant-derive-2 to unblock this.

Bug#1053638: [Pkg-rust-maintainers] Bug#1053638: rust-pbr: Remove from Debian?

[Peter Michael Green]

It has no reverse dependencies and is one of the last things keeping
rust-time-0.1 in Debian.

Not speaking for or against removal, but updating it to the latest
version would get rid of the dependency on time 0.1.

Bug#1051149: rust-leptonica-sys, upcoming rust-bindgen update.

[Peter Michael Green]

Package: rust-leptonica-sys
Version: 0.4.6-2

In the rust team we are working on upgrading rust-bindgen from 0.60 to
0.66, there are a few reasons for this. Firstly it's part of the 
dependency stack
for the new version of rust-cargo. Secondly the version currently in sid 
has a
compatibility issue with new versions of llvm. Thirdly Jonas has filed a 
bug report

requesting the new upstream version.

bindgen bumps semver on most releases, however the changes tend to be
relatively minor. You can read the changelog at
https://github.com/rust-lang/rust-bindgen/blob/main/CHANGELOG.md#0610
I don't see anything too scary in there.

The new version of rust-bindgen has been uploaded to experimental so people
can test against it. After bumping the dependencies your package built
successfully and the autopkgtests passed.

The attatched debdiff, raises the upper limit for the bindgen dependency.diff -Nru rust-leptonica-sys-0.4.6/debian/changelog 
rust-leptonica-sys-0.4.6/debian/changelog
--- rust-leptonica-sys-0.4.6/debian/changelog   2023-08-14 12:07:09.0 
+
+++ rust-leptonica-sys-0.4.6/debian/changelog   2023-09-03 14:19:09.0 
+
@@ -1,3 +1,10 @@
+rust-leptonica-sys (0.4.6-2.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Relax dependeny to allow bindgen 0.66.
+
+ -- Peter Michael Green   Sun, 03 Sep 2023 14:19:09 +
+
 rust-leptonica-sys (0.4.6-2) unstable; urgency=medium
 
   * update DEP-3 patch headers
diff -Nru rust-leptonica-sys-0.4.6/debian/control 
rust-leptonica-sys-0.4.6/debian/control
--- rust-leptonica-sys-0.4.6/debian/control 2023-07-29 23:47:09.0 
+
+++ rust-leptonica-sys-0.4.6/debian/control 2023-09-03 14:19:02.0 
+
@@ -6,7 +6,7 @@
  debhelper-compat (= 13),
  dh-cargo (>= 25),
  libleptonica-dev ,
- librust-bindgen-0+default-dev (<< 0.65) ,
+ librust-bindgen-0+default-dev (<< 0.67) ,
  librust-bindgen-0+default-dev (>= 0.60) ,
  librust-pkg-config-0.3+default-dev (>= 0.3.25) ,
  libstring-shellquote-perl,
@@ -22,7 +22,7 @@
 Multi-Arch: foreign
 Depends:
  libleptonica-dev,
- librust-bindgen-0+default-dev (<< 0.65),
+ librust-bindgen-0+default-dev (<< 0.67),
  librust-bindgen-0+default-dev (>= 0.60),
  librust-pkg-config-0.3+default-dev (>= 0.3.25),
  ${misc:Depends},
diff -Nru rust-leptonica-sys-0.4.6/debian/patches/2001_bindgen.patch 
rust-leptonica-sys-0.4.6/debian/patches/2001_bindgen.patch
--- rust-leptonica-sys-0.4.6/debian/patches/2001_bindgen.patch  2023-08-14 
09:55:41.0 +
+++ rust-leptonica-sys-0.4.6/debian/patches/2001_bindgen.patch  2023-09-03 
14:18:19.0 +
@@ -1,7 +1,9 @@
 Description: relax dependency to cover older crate bindgen 0.60.1
+ and newer crate bindgen 0.66.1.
 Author: Jonas Smedegaard 
+Author: Peter Michael Green 
 Forwarded: not-needed
-Last-Update: 2023-08-14
+Last-Update: 2023-09-03
 ---
 This patch header follows DEP-3: http://dep.debian.net/deps/dep3/
 --- a/Cargo.toml
@@ -11,7 +13,7 @@
  
  [build-dependencies]
 -bindgen = "0.64.0"
-+bindgen = ">= 0.60, < 0.65"
++bindgen = ">= 0.60, < 0.67"
  
  [target.'cfg(windows)'.build-dependencies]
  vcpkg = "0.2.15"
diff -Nru rust-leptonica-sys-0.4.6/debian/patches/2002_no_windows.patch 
rust-leptonica-sys-0.4.6/debian/patches/2002_no_windows.patch
--- rust-leptonica-sys-0.4.6/debian/patches/2002_no_windows.patch   
2023-08-14 09:55:44.0 +
+++ rust-leptonica-sys-0.4.6/debian/patches/2002_no_windows.patch   
2023-09-03 14:19:09.0 +
@@ -8,7 +8,7 @@
 +++ b/Cargo.toml
 @@ -14,8 +14,5 @@
  [build-dependencies]
- bindgen = ">= 0.60, < 0.65"
+ bindgen = ">= 0.60, < 0.67"
  
 -[target.'cfg(windows)'.build-dependencies]
 -vcpkg = "0.2.15"

Bug#1051146: rust-laurel, upcoming rust-bindgen update.

[Peter Michael Green]

On 03/09/2023 14:58, Peter Michael Green wrote:


The attatched debdiff,

Sorry, really attached nowdiff -Nru rust-laurel-0.5.3/debian/changelog rust-laurel-0.5.3/debian/changelog
--- rust-laurel-0.5.3/debian/changelog  2023-07-18 14:26:32.0 +
+++ rust-laurel-0.5.3/debian/changelog  2023-09-02 17:04:14.0 +
@@ -1,3 +1,10 @@
+rust-laurel (0.5.3-1.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Remove upper limit from bindgen dependency.
+
+ -- Peter Michael Green   Sat, 02 Sep 2023 17:04:14 +
+
 rust-laurel (0.5.3-1) unstable; urgency=medium
 
   * New upstream version 0.5.3
diff -Nru rust-laurel-0.5.3/debian/control rust-laurel-0.5.3/debian/control
--- rust-laurel-0.5.3/debian/control2023-07-18 14:26:05.0 +
+++ rust-laurel-0.5.3/debian/control2023-09-02 17:01:16.0 +
@@ -6,7 +6,7 @@
  cargo:native,
  rustc:native,
  libstd-rust-dev,
- librust-bindgen-0.60+default-dev,
+ librust-bindgen+default-dev (>= 0.60),
  librust-caps-0.5+default-dev,
  librust-exacl+default-dev (>= 0.6-~~),
  librust-getopts-0.2+default-dev,
diff -Nru rust-laurel-0.5.3/debian/patches/fix-deps.patch 
rust-laurel-0.5.3/debian/patches/fix-deps.patch
--- rust-laurel-0.5.3/debian/patches/fix-deps.patch 2023-07-18 
14:04:16.0 +
+++ rust-laurel-0.5.3/debian/patches/fix-deps.patch 2023-09-02 
17:03:46.0 +
@@ -1,7 +1,7 @@
-Index: rust-laurel/Cargo.toml
+Index: rust-laurel-0.5.3/Cargo.toml
 ===
 rust-laurel.orig/Cargo.toml
-+++ rust-laurel/Cargo.toml
+--- rust-laurel-0.5.3.orig/Cargo.toml
 rust-laurel-0.5.3/Cargo.toml
 @@ -62,7 +62,7 @@ version = "0.2"
  version = "0.4"
  
@@ -11,3 +11,12 @@
  
  [dependencies.nom]
  version = "7"
+@@ -101,7 +101,7 @@ version = "0"
+ version = "0"
+ 
+ [build-dependencies.bindgen]
+-version = "0.60"
++version = ">= 0.60"
+ 
+ [badges.maintenance]
+ status = "actively-developed"

Bug#1051146: rust-laurel, upcoming rust-bindgen update.

[Peter Michael Green]

Package: rust-laurel
Version: 0.5.3-1

In the rust team we are working on upgrading rust-bindgen from 0.60 to
0.66, there are a few reasons for this. Firstly it's part of the 
dependency stack
for the new version of rust-cargo. Secondly the version currently in sid 
has a
compatibility issue with new versions of llvm. Thirdly Jonas has filed a 
bug report

requesting the new upstream version.

bindgen bumps semver on most releases, however the changes tend to be
relatively minor. You can read the changelog at
https://github.com/rust-lang/rust-bindgen/blob/main/CHANGELOG.md#0610
but I don't see anything too scary in there.

The new version of rust-bindgen has been uploaded to experimental so people
can test against it. After bumping the dependencies your package built
successfully. Unfortunately your package doesn't seem to have any 
autopkgtests.


The attatched debdiff, removes the upper limit from the bindgen dependency,
(similar to how you have already removed the upper limit from the nix 
dependency)
given the history of the bindgen package I think this is a sensible way 
forward

OTOH if you would preffer to simply bump the dependency when the new
bindgen is uploaded that would be fine too.

Bug#1050113: unblock: rust-rustls-webpki/0.101.3-1.1

[Peter Michael Green]

Reopen 1050113
thanks


Bumped the hint to 0.101.3-2.

Testing migration was unfortunately interrupted by a security bug.
then some follow-up issues with the new upstream version uploaded
to fix the security bug.

Can you update the hint to 0.101.4-4?

Bug#1050891: sccache - update for new addr2line.

[Peter Michael Green]

Package: sccache
Version: 0.5.4-11
Severity: serious
Tags: patch

I just updated addr2line to version 0.20.0, sccache builds succesfully
with the new version after bumping the dependency.

Debdiff attatched.
diff -Nru sccache-0.5.4/debian/changelog sccache-0.5.4/debian/changelog
--- sccache-0.5.4/debian/changelog  2023-08-24 08:23:51.0 +
+++ sccache-0.5.4/debian/changelog  2023-08-28 13:25:35.0 +
@@ -1,3 +1,10 @@
+sccache (0.5.4-11.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Bump dependency on object crate to 0.31.
+
+ -- nobody   Mon, 28 Aug 2023 13:25:35 +
+
 sccache (0.5.4-11) unstable; urgency=medium
 
   * drop patch 2018, obsoleted by Debian package changes
diff -Nru sccache-0.5.4/debian/control sccache-0.5.4/debian/control
--- sccache-0.5.4/debian/control2023-08-13 09:04:02.0 +
+++ sccache-0.5.4/debian/control2023-08-28 13:15:03.0 +
@@ -44,7 +44,7 @@
  librust-mime-0.3+default-dev,
  librust-num-cpus-1+default-dev,
  librust-number-prefix-0.4+default-dev,
- librust-object-0.30+default-dev,
+ librust-object-0.31+default-dev,
  librust-once-cell-1+default-dev (>= 1.17),
  librust-predicates-2+default-dev ,
  librust-rand-0.8+default-dev,
diff -Nru sccache-0.5.4/debian/patches/1007_update_object.patch 
sccache-0.5.4/debian/patches/1007_update_object.patch
--- sccache-0.5.4/debian/patches/1007_update_object.patch   1970-01-01 
00:00:00.0 +
+++ sccache-0.5.4/debian/patches/1007_update_object.patch   2023-08-28 
13:17:51.0 +
@@ -0,0 +1,7 @@
+Index: sccache-0.5.4/Cargo.toml
+===
+--- sccache-0.5.4.orig/Cargo.toml
 sccache-0.5.4/Cargo.toml
+@@ -92,1 +92,1 @@ zip = { version = "0.6", default-feature
+-object = "0.30"
++object = "0.31"
diff -Nru sccache-0.5.4/debian/patches/2001_no_dist-server.patch 
sccache-0.5.4/debian/patches/2001_no_dist-server.patch
--- sccache-0.5.4/debian/patches/2001_no_dist-server.patch  2023-08-24 
08:23:51.0 +
+++ sccache-0.5.4/debian/patches/2001_no_dist-server.patch  2023-08-28 
13:18:19.0 +
@@ -30,7 +30,7 @@
 -# dist-server only
  memmap2 = "0.6.2"
 -nix = { version = "0.26.2", optional = true }
- object = "0.30"
+ object = "0.31"
 -rouille = { version = "3.5", optional = true, default-features = false, 
features = [
 -  "ssl",
 -] }
diff -Nru sccache-0.5.4/debian/patches/2008_assert_cmd.patch 
sccache-0.5.4/debian/patches/2008_assert_cmd.patch
--- sccache-0.5.4/debian/patches/2008_assert_cmd.patch  2023-08-24 
08:23:51.0 +
+++ sccache-0.5.4/debian/patches/2008_assert_cmd.patch  2023-08-28 
13:18:39.0 +
@@ -8,7 +8,7 @@
 --- a/Cargo.toml
 +++ b/Cargo.toml
 @@ -100,7 +100,7 @@
- object = "0.30"
+ object = "0.31"
  
  [dev-dependencies]
 -assert_cmd = "2.0.10"
diff -Nru sccache-0.5.4/debian/patches/2017_memmap2.patch 
sccache-0.5.4/debian/patches/2017_memmap2.patch
--- sccache-0.5.4/debian/patches/2017_memmap2.patch 2023-08-24 
08:23:51.0 +
+++ sccache-0.5.4/debian/patches/2017_memmap2.patch 2023-08-28 
13:19:01.0 +
@@ -13,6 +13,6 @@
  
 -memmap2 = "0.6.2"
 +memmap2 = ">= 0.5.10, < 0.7"
- object = "0.30"
+ object = "0.31"
  
  [dev-dependencies]
diff -Nru sccache-0.5.4/debian/patches/series 
sccache-0.5.4/debian/patches/series
--- sccache-0.5.4/debian/patches/series 2023-08-18 15:13:19.0 +
+++ sccache-0.5.4/debian/patches/series 2023-08-28 13:16:36.0 +
@@ -1,5 +1,6 @@
 1001_optional_tests.patch
 1006_tests_network.patch
+1007_update_object.patch
 2001_no_dist-server.patch
 2002_no_opendal_backends.patch
 2003_no_windows.patch

Bug#1050678: rust-async-process - update for new rustix.

[Peter Michael Green]

Package: rust-async-process
Version: 1.7.0-2

I'm preparing an update for rustix, it's a new semver but so-far everything
seems to build with just the dependency bumped. I've uploaded it to 
experimental.
and assuming no showstoppers show up I hope to re-upload it to 
experimental soon.


I have prepared a patch for this package, are you ok if I just NMU it at 
the same time
as I'm uploading the rest of the reverse dependencies or do you want to 
handle the

update yourself?

diff -Nru rust-async-process-1.7.0/debian/changelog 
rust-async-process-1.7.0/debian/changelog
--- rust-async-process-1.7.0/debian/changelog   2023-08-14 10:57:58.0 
+
+++ rust-async-process-1.7.0/debian/changelog   2023-08-27 19:54:23.0 
+
@@ -1,3 +1,10 @@
+rust-async-process (1.7.0-2.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Apply upstream patch to bump rustix dependency.
+
+ -- Peter Michael Green   Sun, 27 Aug 2023 19:54:23 +
+
 rust-async-process (1.7.0-2) unstable; urgency=medium
 
   * update dh-cargo fork;
diff -Nru rust-async-process-1.7.0/debian/control 
rust-async-process-1.7.0/debian/control
--- rust-async-process-1.7.0/debian/control 2023-07-16 09:41:54.0 
+
+++ rust-async-process-1.7.0/debian/control 2023-08-27 19:52:22.0 
+
@@ -12,8 +12,8 @@
  librust-futures-lite-1+default-dev ,
  librust-async-io-1+default-dev ,
  librust-libc-0.2+default-dev ,
- librust-rustix-0.37+fs-dev ,
- librust-rustix-0.37+std-dev ,
+ librust-rustix-0.38+fs-dev ,
+ librust-rustix-0.38+std-dev ,
  librust-signal-hook-0.3+iterator-dev ,
  libstring-shellquote-perl,
 Maintainer: Jonas Smedegaard 
@@ -34,8 +34,8 @@
  librust-futures-lite-1+default-dev,
  librust-async-io-1+default-dev,
  librust-libc-0.2+default-dev,
- librust-rustix-0.37+fs-dev,
- librust-rustix-0.37+std-dev,
+ librust-rustix-0.38+fs-dev,
+ librust-rustix-0.38+std-dev,
  librust-signal-hook-0.3+iterator-dev,
  ${misc:Depends},
 Provides:
diff -Nru rust-async-process-1.7.0/debian/patches/0001_update-rustix.patch 
rust-async-process-1.7.0/debian/patches/0001_update-rustix.patch
--- rust-async-process-1.7.0/debian/patches/0001_update-rustix.patch
1970-01-01 00:00:00.0 +
+++ rust-async-process-1.7.0/debian/patches/0001_update-rustix.patch
2023-08-27 19:49:35.0 +
@@ -0,0 +1,26 @@
+commit 171561685961330d561e660d8608f230f6a208f1
+Author: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com>
+Date:   Sun Jul 2 19:05:21 2023 -0700
+
+m: Update rustix requirement from 0.37 to 0.38
+
+Updates the requirements on 
[rustix](https://github.com/bytecodealliance/rustix) to permit the latest 
version.
+- [Release notes](https://github.com/bytecodealliance/rustix/releases)
+- 
[Commits](https://github.com/bytecodealliance/rustix/compare/v0.37.0...v0.38.2)
+
+---
+updated-dependencies:
+- dependency-name: rustix
+  dependency-type: direct:production
+...
+
+Signed-off-by: dependabot[bot] 
+Co-authored-by: dependabot[bot] 
<49699333+dependabot[bot]@users.noreply.github.com>
+
+diff --git a/Cargo.toml b/Cargo.toml
+index c42a1db..7963bdd 100644
+--- a/Cargo.toml
 b/Cargo.toml
+@@ -26,1 +26,1 @@ futures-lite = "1.11.0"
+-rustix = { version = "0.37", default-features = false, features = ["std", 
"fs"] }
++rustix = { version = "0.38", default-features = false, features = ["std", 
"fs"] }
diff -Nru rust-async-process-1.7.0/debian/patches/series 
rust-async-process-1.7.0/debian/patches/series
--- rust-async-process-1.7.0/debian/patches/series  2023-07-04 
08:20:52.0 +
+++ rust-async-process-1.7.0/debian/patches/series  2023-08-27 
19:41:57.0 +
@@ -1 +1,2 @@
+0001_update-rustix.patch
 2001_windows.patch

Bug#1050655: rust-rustls-webpki - autopkgtest failure.

[Peter Michael Green]

Package: rust-rustls-webpki
Version: 0.101.4-2
Severity serious

https://ci.debian.net/data/autopkgtest/testing/amd64/r/rust-rustls-webpki/37179484/log.gz


  92s debian cargo wrapper: running subprocess (['env', 'RUST_BACKTRACE=1', 
'/usr/bin/cargo', '-Zavoid-dev-deps', 'test', '--verbose', '--verbose', '-j64', 
'--target', 'x86_64-unknown-linux-gnu', '--all-targets', 
'--no-default-features'],) {}
  92s error: no matching package found
  92s searched package name: `rcgen`
  92s perhaps you meant:  regex or rayon
  92s location searched: registry `crates-io`
  92s required by package `rustls-webpki v0.101.4 
(/usr/share/cargo/registry/rustls-webpki-0.101.4)`
  92s autopkgtest [04:21:34]: test rust-rustls-webpki-0.101:: 
---]
  92s autopkgtest [04:21:34]: test rust-rustls-webpki-0.101::  - - - - - - - - 
- - results - - - - - - - - - -
  92s rust-rustls-webpki-0.101: FAIL non-zero exit status 101
Dev-dependencies are not feature specific, so the dependency needs to be 
present for all autopkgtests.

Bug#1050535: rust-rustls-webpki FTBFS, tests require rcgen.

[Peter Michael Green]

Package: rust-rustls-webpki
Version: 0.101.4-1
Severity: serious
Tags: patch

It seems that in addition to the security fix, the new version of 
rustls-webpki added some new tests, these depend on "rcgen" which is 
currently patched away by 2001_bencher.patch.


After reinstating the dependency (but NOT the "patch.crates-io" section) 
and adding corresponding build and test dependencies I was able to 
successfully build the package and run it's autopkgtests.


Debdiff attatched, I may NMU this later (but I'd appreciate a prompt 
maintainer upload).
diff -Nru rust-rustls-webpki-0.101.4/debian/changelog 
rust-rustls-webpki-0.101.4/debian/changelog
--- rust-rustls-webpki-0.101.4/debian/changelog 2023-08-24 08:06:53.0 
+
+++ rust-rustls-webpki-0.101.4/debian/changelog 2023-08-25 18:57:05.0 
+
@@ -1,3 +1,13 @@
+rust-rustls-webpki (0.101.4-1.1) UNRELEASED; urgency=high
+
+  * Non-maintainer upload.
+  * Adjust patch 2001, reinstate rcgen dependency, some newly added tests need
+it. Do not reinstate the "patch.crates-io" section since we want to build
+against debian packaged crates, not stuff from github.
+  * Add build and test dependencies on librust-rcgen-0.11+default-dev (>= 
0.11.1-2)
+
+ -- Peter Michael Green   Fri, 25 Aug 2023 18:57:05 +
+
 rust-rustls-webpki (0.101.4-1) unstable; urgency=high
 
   * bump project version in virtual packages and autopkgtests;
diff -Nru rust-rustls-webpki-0.101.4/debian/control 
rust-rustls-webpki-0.101.4/debian/control
--- rust-rustls-webpki-0.101.4/debian/control   2023-08-24 08:05:29.0 
+
+++ rust-rustls-webpki-0.101.4/debian/control   2023-08-25 18:57:05.0 
+
@@ -6,6 +6,7 @@
  dh-cargo,
  librust-base64-0.21+default-dev ,
  librust-ring-0.16+default-dev ,
+ librust-rcgen-0.11+default-dev (>= 0.11.1-2) ,
  librust-serde-1+default-dev ,
  librust-serde-1+derive-dev ,
  librust-serde-json-1+default-dev ,
diff -Nru rust-rustls-webpki-0.101.4/debian/patches/2001_bencher.patch 
rust-rustls-webpki-0.101.4/debian/patches/2001_bencher.patch
--- rust-rustls-webpki-0.101.4/debian/patches/2001_bencher.patch
2023-08-24 08:06:28.0 +
+++ rust-rustls-webpki-0.101.4/debian/patches/2001_bencher.patch
2023-08-25 18:56:43.0 +
@@ -15,16 +15,15 @@
  
  include = [
  "Cargo.toml",
-@@ -72,9 +73,6 @@
+@@ -72,8 +73,6 @@
  
  [dev-dependencies]
  base64 = "0.21"
 -bencher = "0.1.5"
 -once_cell = "1.17.2"
--rcgen = { version = "0.11.1", default-features = false }
+ rcgen = { version = "0.11.1", default-features = false }
  serde = { version = "1.0", features = ["derive"] }
  serde_json = "1.0"
- 
 @@ -93,12 +91,3 @@
  lto = true
  debug-assertions = false
diff -Nru rust-rustls-webpki-0.101.4/debian/tests/control 
rust-rustls-webpki-0.101.4/debian/tests/control
--- rust-rustls-webpki-0.101.4/debian/tests/control 2023-08-24 
08:05:35.0 +
+++ rust-rustls-webpki-0.101.4/debian/tests/control 2023-08-25 
18:57:05.0 +
@@ -8,6 +8,7 @@
  librust-serde-1+default-dev,
  librust-serde-1+derive-dev,
  librust-serde-json-1+default-dev,
+ librust-rcgen-0.11+default-dev (>= 0.11.1-2),
 Restrictions: allow-stderr
 
 Test-Command: SOURCEPACKAGEDIR=$PWD /usr/share/cargo/bin/cargo-auto-test 
rustls-webpki 0.101.4
@@ -20,6 +21,7 @@
  librust-serde-1+default-dev,
  librust-serde-1+derive-dev,
  librust-serde-json-1+default-dev,
+ librust-rcgen-0.11+default-dev (>= 0.11.1-2),
 Restrictions: allow-stderr
 
 Test-Command: SOURCEPACKAGEDIR=$PWD /usr/share/cargo/bin/cargo-auto-test 
rustls-webpki 0.101.4
@@ -32,6 +34,7 @@
  librust-serde-1+default-dev,
  librust-serde-1+derive-dev,
  librust-serde-json-1+default-dev,
+ librust-rcgen-0.11+default-dev (>= 0.11.1-2),
 Restrictions: allow-stderr
 
 Test-Command: SOURCEPACKAGEDIR=$PWD /usr/share/cargo/bin/cargo-auto-test 
rustls-webpki 0.101.4
@@ -44,6 +47,7 @@
  librust-serde-1+default-dev,
  librust-serde-1+derive-dev,
  librust-serde-json-1+default-dev,
+ librust-rcgen-0.11+default-dev (>= 0.11.1-2),
 Restrictions: allow-stderr
 
 Test-Command: SOURCEPACKAGEDIR=$PWD /usr/share/cargo/bin/cargo-auto-test 
rustls-webpki 0.101.4
@@ -56,4 +60,5 @@
  librust-serde-1+default-dev,
  librust-serde-1+derive-dev,
  librust-serde-json-1+default-dev,
+ librust-rcgen-0.11+default-dev (>= 0.11.1-2),
 Restrictions: allow-stderr

Bug#1050138: rust-wasmer-enumset-derive should not be in trixie

[Peter Michael Green]

Package: rust-wasmer-enumset-derive
Version: 0.5.0-2
Severity: serious
Tags: trixie, sid

rust-wasmer-enumset-derive and it's reverse dependency 
rust-wasmer-enumset are an abandoned fork of rust-enumset-dervive and 
rust-enumset, no applications use them anymore so there is no reason to 
keep them around creating more busywork for the rust team to prevent 
them blocking semver transitions.

Bug#1050134: rust-leptonica-plumbing - autopkgtest depends on non-existent virtual package.

[Peter Michael Green]

Package: rust-leptonica-plumbing
Version: 1.0.1-4
Severity: serious

https://ci.debian.net/data/autopkgtest/testing/amd64/r/rust-leptonica-plumbing/36970458/log.gz


118s The following packages have unmet dependencies:
118s  autopkgtest-satdep : Depends: librust-leptonica-plumbing-1.0+default-dev 
but it is not installable
118s E: Unable to correct problems, you have held broken packages.
118s autopkgtest: WARNING: Test dependencies are unsatisfiable - calling apt 
install on test deps directly for further data about failing dependencies in 
test logs

librust-leptonica-plumbing-dev provides 
|librust-leptonica-plumbing-1+default-dev and||
librust-leptonica-plumbing-1.0-dev but not 
|librust-leptonica-plumbing-1.0+default-dev

Bug#1050132: rust-hyper-rustls - debian/tests/control still references rustls 0.20

[Peter Michael Green]

Package: rust-hyper-rustls
Version: 0.24.1-2
Severity: minor

debian/tests/control in rust-hyper-rustls still refers to rustls 0.20, 
even though

the package itself is now using rustls 0.21.

Bug#1041384: librust-derive-builder-dev: impossible to install

[Peter Michael Green]

Version: 0.12.0-1

rust-derive-builder has now been updated to match rust-derive-builder-core.

Bug#1041233: [Pkg-rust-maintainers] Bug#1041233: librust-heapless-dev: impossible to install: depends on missing package librust-heapless-0.7-dev

[Peter Michael Green]

As subject says, this package depends on librust-heapless-0.7-dev which
is missing, rendering the package impossible to install.

I don't see any such dependency, was this a typo.

It does however seem to depend on librust-defmt-0.3+default-dev,
rust-defmt hasn't been uploaded yet, but it seems Alexander Kjäll
is working on it.

Bug#1039534: squeekboard: Fails to build on Debian Unstable

[Peter Michael Green]

tags 1039534 +patch
thanks

squeekboard build-depends on missing:
- librust-gtk+v3-22-dev:amd64 (>= 0.14)

The current version of rust-gtk provides librust-gtk+v3-24-dev

After updating the dependencies (both Debian and cargo) to allow a build
to be attempted I discovered there were also a couple of real code issues.

The first is that gtk::rectangle is now an opaque type, so you have to
call "new" instead of assembling it field by field.

The second is that "property" appears to have been renamed first to
"property_value", then to "try_property_value". Then the non-panicing
version was removed completely. I modified the code to add an explicit
check if the property exists before calling the panicing version of
the function (now called "property_value") but I have no idea if this
is overkill or not.

I'm not really in a position to test this patch as I don't use Debian
on an appropriate device.

Anyway, a debdiff is attached, if there is no maintainer response,
*and* I get feedback from a user that the patched squeekboard is
usable then I may NMU it.
diff -Nru squeekboard-1.22.0/debian/changelog 
squeekboard-1.22.0/debian/changelog
--- squeekboard-1.22.0/debian/changelog 2023-06-13 14:43:56.0 +
+++ squeekboard-1.22.0/debian/changelog 2023-06-28 18:54:50.0 +
@@ -1,3 +1,16 @@
+squeekboard (1.22.0-2.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Remove upper limit on cargo dependencies.
+  * Update for rust-gtk 0.16 and related packages. (Closes: #)
++ Use v3_24 feature instead of v3_22 feature for rust-gtk as the former
+  no longer exists.
++ Patch code to build with rust-gtk 0.16
++ Bump rust-gtk/rust-glib dependencies to 0.16 as the fixes for 0.16
+  will break builds with older versions of the rust gtk stack.
+
+ -- Peter Michael Green   Wed, 28 Jun 2023 18:54:50 +
+
 squeekboard (1.22.0-2) unstable; urgency=medium
 
   * Release to unstable
diff -Nru squeekboard-1.22.0/debian/control squeekboard-1.22.0/debian/control
--- squeekboard-1.22.0/debian/control   2023-06-13 14:43:56.0 +
+++ squeekboard-1.22.0/debian/control   2023-06-28 18:16:36.0 +
@@ -18,9 +18,9 @@
  librust-bitflags-1-dev (>= 1.0),
  librust-clap-4+std-dev (>= 3.1),
  librust-gio+v2-58-dev (>= 0.14),
- librust-glib+v2-58-dev (>= 0.14),
+ librust-glib+v2-58-dev (>= 0.16),
  librust-glib-sys-dev (>= 0.14),
- librust-gtk+v3-22-dev (>= 0.14),
+ librust-gtk+v3-24-dev (>= 0.16),
  librust-gtk-sys-dev (>= 0.14),
  librust-maplit-1-dev (>= 1.0),
  librust-serde-derive-1-dev (>= 1.0),
diff -Nru squeekboard-1.22.0/debian/patches/rust-gtk-0.16.patch 
squeekboard-1.22.0/debian/patches/rust-gtk-0.16.patch
--- squeekboard-1.22.0/debian/patches/rust-gtk-0.16.patch   1970-01-01 
00:00:00.0 +
+++ squeekboard-1.22.0/debian/patches/rust-gtk-0.16.patch   2023-06-28 
18:51:46.0 +
@@ -0,0 +1,92 @@
+Index: squeekboard-1.22.0/Cargo.deps.newer
+===
+--- squeekboard-1.22.0.orig/Cargo.deps.newer
 squeekboard-1.22.0/Cargo.deps.newer
+@@ -9,30 +9,30 @@ zvariant = "2.10.*"
+ zvariant_derive = "2.10.*"
+ 
+ [dependencies.cairo-rs]
+-version = "0.14.*"
++version = ">= 0.14"
+ 
+ [dependencies.cairo-sys-rs]
+-version = "0.14.*"
++version = ">= 0.14"
+ 
+ [dependencies.gdk]
+-version = "0.14.*"
++version = ">= 0.14"
+ 
+ [dependencies.gio]
+-version = "0.14.*"
++version = ">= 0.14"
+ features = ["v2_58"]
+ 
+ [dependencies.glib]
+-version = "0.14.*"
++version = ">= 0.14"
+ features = ["v2_58"]
+ 
+ [dependencies.glib-sys]
+-version = "0.14.*"
++version = ">= 0.14"
+ features = ["v2_58"]
+ 
+ [dependencies.gtk]
+-version = "0.14.*"
+-features = ["v3_22"]
++version = ">= 0.14"
++features = ["v3_24"]
+ 
+ [dependencies.gtk-sys]
+-version = "0.14.*"
+-features = ["v3_22"]
++version = ">= 0.14"
++features = ["v3_24"]
+Index: squeekboard-1.22.0/Cargo.toml.in
+===
+--- squeekboard-1.22.0.orig/Cargo.toml.in
 squeekboard-1.22.0/Cargo.toml.in
+@@ -31,5 +31,5 @@ clap_v4 = []
+ maplit = "1.0.*"
+ serde = { version = "1.0.*", features = ["derive"] }
+ serde_yaml = "0.8.*"
+-xkbcommon = { version = "0.4.*", features = ["wayland"] }
++xkbcommon = { version = ">= 0.4", features = ["wayland"] }
+ # Here is inserted the Cargo.deps file
+Index: squeekboard-1.22.0/src/popover.rs
+===
+--- squeekboard-1.22.0.orig/src/popover.rs
+++

Bug#1039048: php-doctrine-cache: unsatisfiable build dependency

[Peter Michael Green]

Package: php-doctrine-cache
Version: 2.2.0-1
Severity: serious
Tags: trixie, sid

php-doctrine-cache build-depends on php-nrk-predis which
was a transitional dummy package in bookworm and no
longer exists in trixie or sid.

Presumablly the build-dependency should be changed to
php-predis.

Bug#1038746: (python-cryptography) build dependency missing in testing

[Peter Michael Green]

tags 1038746 +patch
thanks


Dose [1] is reporting issues with your packages. Normally your build
dependencies shouldn't be removed from testing without removal all
reverse build dependencies too, nor should a package be allowed to
migrate unless all build dependencies are candidate for migration too.
However, somehow we ended up in the current state

The "somehow" is that testing migration only checks build
dependencies in the forward direction, not in reverse. So a
new version of a package that breaks your build-dependencies
can and often does migrate. Specifically this was caused by
the recent update of rust-pyo3.

Anyway, a debdiff is attatched, I may or may not NMU this
later.
diff -Nru python-cryptography-38.0.4/debian/changelog 
python-cryptography-38.0.4/debian/changelog
--- python-cryptography-38.0.4/debian/changelog 2023-02-28 05:36:13.0 
+
+++ python-cryptography-38.0.4/debian/changelog 2023-06-25 00:58:26.0 
+
@@ -1,3 +1,13 @@
+python-cryptography (38.0.4-3.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Don't depend on librust-indoc-dev, it's not used directly,
+instead depend on the "default" feature of librust-pyo3-dev.
+  * Apply adjusted upstream patch for py03 0.19 and bump
+dependencies accordingly.
+
+ -- Peter Michael Green   Sun, 25 Jun 2023 00:58:26 +
+
 python-cryptography (38.0.4-3) unstable; urgency=medium
 
   [ Salvatore Bonaccorso ]
diff -Nru python-cryptography-38.0.4/debian/control 
python-cryptography-38.0.4/debian/control
--- python-cryptography-38.0.4/debian/control   2023-02-28 05:36:13.0 
+
+++ python-cryptography-38.0.4/debian/control   2023-06-25 00:58:26.0 
+
@@ -12,12 +12,12 @@
librust-asn1-0.12-dev,
librust-asn1-derive-0.12-dev,
librust-chrono-0.4-dev,
-   librust-indoc-dev,
librust-ouroboros-0.15-dev,
librust-paste-dev,
librust-pem-1.0-dev,
-   librust-pyo3-0.17-dev,
-   librust-pyo3-macros-0.17-dev,
+   librust-pyo3-0.19-dev,
+   librust-pyo3-0.19+default-dev,
+   librust-pyo3-macros-0.19-dev,
libssl-dev,
pybuild-plugin-pyproject,
python3-all-dev,
diff -Nru python-cryptography-38.0.4/debian/patches/Bump-pyo3-dep.patch 
python-cryptography-38.0.4/debian/patches/Bump-pyo3-dep.patch
--- python-cryptography-38.0.4/debian/patches/Bump-pyo3-dep.patch   
1970-01-01 00:00:00.0 +
+++ python-cryptography-38.0.4/debian/patches/Bump-pyo3-dep.patch   
2023-06-25 00:58:26.0 +
@@ -0,0 +1,13 @@
+Index: python-cryptography-38.0.4.new/src/rust/Cargo.toml
+===
+--- python-cryptography-38.0.4.new.orig/src/rust/Cargo.toml
 python-cryptography-38.0.4.new/src/rust/Cargo.toml
+@@ -7,7 +7,7 @@ publish = false
+ 
+ [dependencies]
+ once_cell = "1"
+-pyo3 = { version = "0.17" }
++pyo3 = { version = "0.19" }
+ asn1 = { version = "0.12", default-features = false, features = ["derive"] }
+ pem = ">= 1.0, < 1.2"
+ chrono = { version = "0.4", default-features = false, features = ["alloc", 
"clock"] }
diff -Nru python-cryptography-38.0.4/debian/patches/series 
python-cryptography-38.0.4/debian/patches/series
--- python-cryptography-38.0.4/debian/patches/series2023-02-28 
05:36:13.0 +
+++ python-cryptography-38.0.4/debian/patches/series2023-06-25 
00:58:26.0 +
@@ -6,3 +6,4 @@
 ease-chrono-dependency-from-0.4.22-to-0.4.patch
 drop-cffi-dep.patch
 Don-t-allow-update_into-to-mutate-immutable-objects-.patch
+Upgrade-to-pyo3-0.19.patch
diff -Nru python-cryptography-38.0.4/debian/patches/Upgrade-to-pyo3-0.19.patch 
python-cryptography-38.0.4/debian/patches/Upgrade-to-pyo3-0.19.patch
--- python-cryptography-38.0.4/debian/patches/Upgrade-to-pyo3-0.19.patch
1970-01-01 00:00:00.0 +
+++ python-cryptography-38.0.4/debian/patches/Upgrade-to-pyo3-0.19.patch
2023-06-25 00:58:26.0 +
@@ -0,0 +1,71 @@
+This patch is based on the upstream commit described below, adapted for use
+in the Debian package by Peter Michael Green.
+
+commit b1cfa3adef986ef3466b080263911e8d79ec6141
+Author: Alex Gaynor 
+Date:   Wed May 31 16:27:10 2023 -0400
+
+pyo3 0.19 (#8999)
+
+* Bump pyo3 from 0.18.3 to 0.19.0 in /src/rust
+
+Bumps [pyo3](https://github.com/pyo3/pyo3) from 0.18.3 to 0.19.0.
+- [Release notes](https://github.com/pyo3/pyo3/releases)
+- [Changelog](https://github.com/PyO3/pyo3/blob/main/CHANGELOG.md)
+- [Commits](https://github.com/pyo3/pyo3/compare/v0.18.3...v0.19.0)
+
+---
+updated-dependencies:
+- dependency-name: pyo3
+  dependency-type: direct:production
+ 

Bug#1038420: rust-rustls - autopkgtest failure with new base64.

[Peter Michael Green]

Package: rust-rustls
Version: 0.20.8-4
Severity: serious
Tags: trixie, sid

The autopkgtest for rust-rustls autopkgtest depends on rust-base64 0.13 but
unstable now has 0.21 and we are trying to get it into trixie.

Since your package does not use skip-not-installable this is a hard failure
and is blocking the testing migration of rust-rustls-pemfile and hence
rust-base64.

When upstream bumped the dependency they made some code
changes, but it looks like said code changes were only needed
to fix deprecation warnings. Simply bumping the dependency in
Cargo.toml and debian/tests/control is enough to make the autopkgtest
pass.

Debdiff attatched, if this is still outstanding in a week or so and other
blockers for testing migration are cleared, I will probablly NMU it.
diff -Nru rust-rustls-0.20.8/debian/changelog 
rust-rustls-0.20.8/debian/changelog
--- rust-rustls-0.20.8/debian/changelog 2023-02-03 13:57:58.0 +
+++ rust-rustls-0.20.8/debian/changelog 2023-06-18 01:01:18.0 +
@@ -1,3 +1,10 @@
+rust-rustls (0.20.8-4.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Bump base64 dev-dependency to 0.21.
+
+ -- Peter Michael Green   Sun, 18 Jun 2023 01:01:18 +
+
 rust-rustls (0.20.8-4) unstable; urgency=medium
 
   * add patch 1001 to add feature constraints to tests
diff -Nru rust-rustls-0.20.8/debian/patches/2004_bump_base64.patch 
rust-rustls-0.20.8/debian/patches/2004_bump_base64.patch
--- rust-rustls-0.20.8/debian/patches/2004_bump_base64.patch1970-01-01 
00:00:00.0 +
+++ rust-rustls-0.20.8/debian/patches/2004_bump_base64.patch2023-06-18 
01:01:00.0 +
@@ -0,0 +1,11 @@
+--- rust-rustls-0.20.8.orig/rustls/Cargo.toml
 rust-rustls-0.20.8/rustls/Cargo.toml
+@@ -37,7 +37,7 @@ log = "0.4.4"
+ rustls-native-certs = "0.6"
+ criterion = "0.3.0"
+ rustls-pemfile = "1.0.0"
+-base64 = "0.13.0"
++base64 = "0.21.0"
+ 
+ [[example]]
+ name = "bogo_shim"
diff -Nru rust-rustls-0.20.8/debian/patches/series 
rust-rustls-0.20.8/debian/patches/series
--- rust-rustls-0.20.8/debian/patches/series2023-02-03 13:56:11.0 
+
+++ rust-rustls-0.20.8/debian/patches/series2023-06-18 01:00:10.0 
+
@@ -1,3 +1,4 @@
 1001_feature_constraints.patch
 2001_native_certs.patch
 2003_network_access.patch
+2004_bump_base64.patch
diff -Nru rust-rustls-0.20.8/debian/tests/control 
rust-rustls-0.20.8/debian/tests/control
--- rust-rustls-0.20.8/debian/tests/control 2023-02-02 19:14:08.0 
+
+++ rust-rustls-0.20.8/debian/tests/control 2023-06-18 00:58:44.0 
+
@@ -4,7 +4,7 @@
 Features: test-name=rust-rustls-0.20:@
 Depends:
  dh-cargo (>= 18),
- librust-base64-0.13+default-dev,
+ librust-base64-0.21+default-dev,
  librust-criterion-0.3+default-dev,
  librust-docopt-1+default-dev,
  librust-env-logger-0.9+default-dev,
@@ -27,7 +27,7 @@
 Features: test-name=rust-rustls-0.20:dangerous_configuration
 Depends:
  dh-cargo (>= 18),
- librust-base64-0.13+default-dev,
+ librust-base64-0.21+default-dev,
  librust-criterion-0.3+default-dev,
  librust-docopt-1+default-dev,
  librust-env-logger-0.9+default-dev,
@@ -48,7 +48,7 @@
 Features: test-name=rust-rustls-0.20:quic
 Depends:
  dh-cargo (>= 18),
- librust-base64-0.13+default-dev,
+ librust-base64-0.21+default-dev,
  librust-criterion-0.3+default-dev,
  librust-docopt-1+default-dev,
  librust-env-logger-0.9+default-dev,
@@ -69,7 +69,7 @@
 Features: test-name=rust-rustls-0.20:secret_extraction
 Depends:
  dh-cargo (>= 18),
- librust-base64-0.13+default-dev,
+ librust-base64-0.21+default-dev,
  librust-criterion-0.3+default-dev,
  librust-docopt-1+default-dev,
  librust-env-logger-0.9+default-dev,
@@ -90,7 +90,7 @@
 Features: test-name=rust-rustls-0.20:tls12
 Depends:
  dh-cargo (>= 18),
- librust-base64-0.13+default-dev,
+ librust-base64-0.21+default-dev,
  librust-criterion-0.3+default-dev,
  librust-docopt-1+default-dev,
  librust-env-logger-0.9+default-dev,
@@ -111,7 +111,7 @@
 Features: test-name=rust-rustls-0.20:read_buf
 Depends:
  dh-cargo (>= 18),
- librust-base64-0.13+default-dev,
+ librust-base64-0.21+default-dev,
  librust-criterion-0.3+default-dev,
  librust-docopt-1+default-dev,
  librust-env-logger-0.9+default-dev,
@@ -133,7 +133,7 @@
 Features: test-name=rust-rustls-0.20:
 Depends:
  dh-cargo (>= 18),
- librust-base64-0.13+default-dev,
+ librust-base64-0.21+default-dev,
  librust-criterion-0.3+default-dev,
  librust-docopt-1+default-dev,
  librust-env-logger-0.9+default-dev,
@@ -154,7 +154,7 @@
 Features: test-name=rust-rustls-0.20:default
 Depends:
  dh-cargo (>= 18),
- librust-base64-0.13+default-dev,
+ librust-base64-0.21+default-dev,
  librust-criterion-0.3+default-dev,
  librust-docopt-1+default-dev,
  librust-env-logger-0.9+default-dev,
@@ -175,7 +175,7 @@
 Features: test-name=rust-rustls-0.20:logging
 Depends:
  dh-cargo (>= 18),
- librust-base64-0.13+defaul

Bug#1034443: python3-brial: uninstallable on arcitectures where sagemath is unavailable, breaks building of singular

[Peter Michael Green]

On 23/04/2023 21:07, Paul Gevers wrote:
Can you point to a discussion where we might draw the conclusion that 
this is common practice or consensus? I *personally* [no hats on] find 
that distinction a bit weird although I can see how we would come to 
it and also why.
No, I can't point to a discussion. I vaugely remember hearing it from a 
more experianced developer (possiblly a release team member) on IRC 
years ago.


But it has been consistent with how I have seen bugs handled in practice 
over my years in Debian.


It's also consistent with how britney behaves or at least did until very 
recently. My understanging is that britney performs architecture checks 
on all release architectures where a package is built for arch specific 
packages, but only performs architecture checks on a small subset of 
architectures (when I first started with Debian it was i386 only, I 
think now it's amd64 and arm64, maybe also i386) for arch all packages.


I have vauge reccollections of a document descirbing the different 
behaviour for arch all packages in britney as a "hack", so I presume 
this is something that started as a hack and then just became the status 
quo. If you wanted your package in testing and it was arch specific you 
had to make sure it was installable on all architectures where it was 
built, but if it was arch all you did not (and often could not).


I have seen people ask the release team for exceptions when their 
arch-all package is not installable on one of the architectures where 
arch all packages are checked but I can't recall ever seeing such a 
request for an arch-specific package.


And when I look at 
https://qa.debian.org/dose/debcheck/testing_main/index.html this seems 
to back up my observation.


That does leave the question of how brial with this bug migrated to 
testing in the first place. Whether there was a recent intentional 
change in britney, whether there was a bug/glitch, or whether it was 
forced in (and if-so who forced it).


This seems to be your real issue. Why file the bug against 
python3-brial?
When an issue involving multiple packages shows up on my radar, I 
tend to start by filing a bug with the package where a fix could 
potentially have the most impact and cc the maintainers of other 
packages that are involved.


Ack. And I agree with this approach. However, we are *also* in the 
Hard Freeze, so RC bugs reports have more severe results if not 
treated swiftly.
Agreed, given where we are in the Freeze, enough time has passed to file 
a rc bug against singular with an expression of intent to NMU. I'll do 
that later today.


I also hereby announce that I intend to NMU brial if I don't get a 
maintainer response soon.
(I am assuming Paul is posting as a release team member and not as a 
maintainer of the package, if that is wrong please speak up)

Bug#1034443: python3-brial: uninstallable on arcitectures where sagemath is unavailable, breaks building of singular

[Peter Michael Green]

On 23/04/2023 19:19, Paul Gevers wrote:


I claim this is wrong. Would python3-sage one day build on more 
architectures, this list would need manual updating. Instead of 
hard-coding the list, it's better to ensure the build doesn't happen 
or fails on architectures where python3-sage is not available. E.g. by 
build-depending (ideally with a build profile indicating that the 
*build* itself works; I suggest ). 


That works in some cases, but it's a bad option here for two reasons.

1. It would create a build-dependency loop between brial and sagemath.
2. It would mean that other binary packages built from the brial source 
package had their architecture list unnecessarily limited.


> Technically I even think that this isn't a bug in python3-brial.

One of the criteria (indeed the first on the list) for grave is "makes 
the package in question unusable or mostly so". I consider that a 
package that cannot be installed is unusable.


My understanding has always been that for source packages that build 
multiple binaries, the test of "is the package unusable" is applied for 
each binary package individually and that for packages that are built 
separately for multiple architectures (not arch all packages) it is 
applied for each architecture individually. I don't think that is 
officially written down anywhere though.



This seems to be your real issue. Why file the bug against python3-brial?
When an issue involving multiple packages shows up on my radar, I tend 
to start by filing a bug with the package where a fix could potentially 
have the most impact and cc the maintainers of other packages that are 
involved.


If the maintainer of brial came back and said that the fix for bug 
1033878 was wrong, and that python3-brial could in-fact be made usable 
on all architectures then there would.


On the other hand whatever changes were made in singular we would still 
have unusable python3-brial packages.


So I started out with a bug against python3-brial.

Bug#1034723: rust-hyper: CVE-2023-26964

[Peter Michael Green]

reassign 1034723 rust-h2
thanks


The following vulnerability was published for rust-hyper.

CVE-2023-26964[0]:
|/An issue was discovered in hyper v0.13.7. h2-0.2.4 Stream stacking /|/occurs 
when the H2 component processes HTTP2 RST_STREAM frames. As a /|/result, the 
memory and CPU usage are high which can lead to a Denial /|/of Service (DoS). /
https://github.com/hyperium/hyper/issues/2877
https://github.com/hyperium/h2/commit/5bc8e72e5fcbd8ae2d3d9bc78a1c0ef0040bcc39  
(v0.3.17)

I've just read though the github threads, it seems that although
this was initially filed against the hyper crate the actual
issue/fix was in the h2 crate. This has also been filed in the
rustsec database at https://rustsec.org/advisories/RUSTSEC-2023-0034.html

Bug#1032826: dgit infrastructure broken for git package.

[Peter Michael Green]

Package: dgit

dget -d http://deb.debian.org/debian/pool/main/g/git/git_2.39.2-1.1.dsc
mkdir dgittest
cd dgittest
git init
dgit import-dsc ../git_2.39.2-1.1.dsc +workingbranch

results in.

Dgit metadata in .dsc: specified git info (debian)
dgit: import-dsc of .dsc with Dgit field, using git hash
.dsc names distro debian: fetching rewrite map
fatal: repository 'https://git.dgit.debian.org/git/' not found
dgit: failed command: git ls-remote -q --refs 
https://git.dgit.debian.org/git refs/dgit-rewrite/map


dgit: error: subprocess failed with error exit status 128


Doing some poking around it appears to me that the repo
does exist, but access to it with git is blocked by some kind
of redirection rule.

Bug#1004869: python-xarray autopkgtest fail on i386

[Peter Michael Green]

This patch was dropped in the next upload (probably by accident), and
hence this bug has reappeared.

I have prepared a NMU reinstating Jochen's changes and uploaded
it to delayed/5, please tell me if you have any objections.
diff -Nru python-xarray-2023.01.0/debian/changelog 
python-xarray-2023.01.0/debian/changelog
--- python-xarray-2023.01.0/debian/changelog2023-01-22 11:21:51.0 
+
+++ python-xarray-2023.01.0/debian/changelog2023-02-19 00:50:57.0 
+
@@ -1,3 +1,15 @@
+python-xarray (2023.01.0-1.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+
+  [ Jochen Sprickerhof ]
+  * Add patch to fix FTBFS on i386.
+Thanks to Adrian Bunk (Closes: 1004869)
+  * Use execute_after_ in d/rules
+  * Set R³ in d/control
+
+ -- Peter Michael Green   Sun, 19 Feb 2023 00:50:57 +
+
 python-xarray (2023.01.0-1) unstable; urgency=medium
 
   * Mew upstream release
diff -Nru python-xarray-2023.01.0/debian/control 
python-xarray-2023.01.0/debian/control
--- python-xarray-2023.01.0/debian/control  2023-01-22 11:21:51.0 
+
+++ python-xarray-2023.01.0/debian/control  2023-02-19 00:50:21.0 
+
@@ -48,6 +48,7 @@
 Vcs-Browser: https://salsa.debian.org/science-team/python-xarray
 Vcs-Git: https://salsa.debian.org/science-team/python-xarray.git
 Homepage: http://xarray.pydata.org/
+Rules-Requires-Root: no
 
 Package: python3-xarray
 Architecture: all
diff -Nru 
python-xarray-2023.01.0/debian/patches/0015-Mark-failing-test-on-i386-as-xfail.patch
 
python-xarray-2023.01.0/debian/patches/0015-Mark-failing-test-on-i386-as-xfail.patch
--- 
python-xarray-2023.01.0/debian/patches/0015-Mark-failing-test-on-i386-as-xfail.patch
1970-01-01 00:00:00.0 +
+++ 
python-xarray-2023.01.0/debian/patches/0015-Mark-failing-test-on-i386-as-xfail.patch
2023-02-19 00:50:21.0 +
@@ -0,0 +1,20 @@
+From: Adrian Bunk 
+Date: Thu, 29 Dec 2022 09:05:39 +0100
+Subject: Mark failing test on i386 as xfail
+
+---
+ xarray/tests/test_interp.py | 1 +
+ 1 file changed, 1 insertion(+)
+
+diff --git a/xarray/tests/test_interp.py b/xarray/tests/test_interp.py
+index b3c94e3..1dc8aff 100644
+--- a/xarray/tests/test_interp.py
 b/xarray/tests/test_interp.py
+@@ -854,6 +854,7 @@ def test_interpolate_chunk_1d(
+ @requires_dask
+ @pytest.mark.parametrize("method", ["linear", "nearest"])
+ @pytest.mark.filterwarnings("ignore:Increasing number of chunks")
++@pytest.mark.xfail
+ def test_interpolate_chunk_advanced(method: InterpOptions) -> None:
+ """Interpolate nd array with an nd indexer sharing coordinates."""
+ # Create original array
diff -Nru python-xarray-2023.01.0/debian/patches/series 
python-xarray-2023.01.0/debian/patches/series
--- python-xarray-2023.01.0/debian/patches/series   2023-01-22 
11:21:51.0 +
+++ python-xarray-2023.01.0/debian/patches/series   2023-02-19 
00:50:21.0 +
@@ -12,3 +12,4 @@
 xfail-pad-constant.patch
 no-sphinx-design.patch
 xfail-on-random-patch
+0015-Mark-failing-test-on-i386-as-xfail.patch
diff -Nru python-xarray-2023.01.0/debian/rules 
python-xarray-2023.01.0/debian/rules
--- python-xarray-2023.01.0/debian/rules2023-01-22 11:21:51.0 
+
+++ python-xarray-2023.01.0/debian/rules2023-02-19 00:50:21.0 
+
@@ -4,7 +4,7 @@
 export DH_VERBOSE=1
 
 export PYBUILD_NAME=xarray
-PY3VERS:= $(shell py3versions -s)
+export http_proxy=127.0.0.1:9 https_proxy=127.0.0.1:9
 
 # Disable checking for this release:
 DEB_BUILD_OPTIONS += nocheck
@@ -12,30 +12,19 @@
 %:
dh $@  --buildsystem=pybuild
 
-override_dh_auto_clean:
-   dh_auto_clean
+execute_after_dh_auto_clean:
 ifeq (,$(findstring nodoc,$(DEB_BUILD_PROFILES)))
$(MAKE) -C doc clean
 endif
 
-override_dh_auto_install: $(PYTHON3:%=install-python%)
-   dh_auto_install
+execute_after_dh_auto_install: $(PYTHON3:%=install-python%)
find debian/python3-xarray -name '*.idx' -exec chmod -x {} \;
 
-override_dh_auto_build:
-   http_proxy=127.0.0.1:9 https_proxy=127.0.0.1:9 dh_auto_build
+execute_after_dh_auto_build:
 ifeq (,$(findstring nodoc,$(DEB_BUILD_PROFILES)))
PYTHONPATH=$(CURDIR) $(MAKE) -C doc html
 endif
 
-override_dh_auto_test:
-ifeq (,$(filter nocheck,$(DEB_BUILD_OPTIONS)))
-   for p in $(PY3VERS); do \
-   PY3VERNUM=`echo $$p | sed -e 's/python//' `; \
-   pybuild --test --test-pytest -i $$p -p $$PY3VERNUM  ;  \
-   done
-endif
-
 override_dh_sphinxdoc:
dh_sphinxdoc --exclude=MathJax.js
find debian/python-xarray-doc -name '*.html' \

Bug#1030941: librsb: build-depends unsatisfiable on armhf

[Peter Michael Green]

On 09/02/2023 23:43, Michele Martone wrote:

On 20230209@17:50, Peter Green wrote:

Package: librsb
Version: 1.3.0.2+dfsg-1
Tags: bookworm, sid
Severity: serious
Justification: rc policy - "packages must be buildable within the same release"
User: debian...@lists.debian.org
Usertags: edos-uninstallable

librsb build-depends on coccinelle which appears to have been removed
on armhf, presumablly because it fails to build with an out of memory
error. This leaves your package in violation of the rc policy.

In general in cases like this there are three possible ways forward,
in roughly descending order of preference.

1. Fix the package you depend on so that it once again builds on
 all release architectures.
2. Modify your package to eliminate the build-dependency in question
 on architectures where it is not available.
3. Decide it is not reasonable to support your package on armhf and
 file a removal request with the ftp team.

I do not know enough about your individual package to say which are
feasible in your particular case.

The coccinelle-based patch was there only for gcc-11, which had a bug
in -O3 and generated buggy code.

So if one is sure to build with a different compiler thant gcc-11,
one can drop the coccinelle patch.
Otherwise one can remedy by using '-O3 -fno-tree-loop-vectorize'
instead of '-O3'.

Is it safe to assume gcc-11 is *not* being used?


It should be safe, but I would suggest adding a
build-dependency on gcc (>= 12) to make sure
the package is not inadvertently built in an out of
date environment.

Bug#1024373: rust-reqwest: feature "socks" is missing

[Peter Michael Green]

Please consider enabling feature socks now: Package rust-socks is now in Debian.


The socks feature of rust-reqwest depends on the tokio-socks crate, not the 
socks
crate.

Bug#1029931: pushpin: build-dependencies unsatisfiable on mips*, ppc64el and s390x.

[Peter Michael Green]

Package: pushpin
Version: 1.36.0-1
Severity: serious

The new version of pushpin added a dependency on jsonwebtoken,
unfortunately jsonwebtoken depends in ring, which is only available
on x86* and arm*. There is work upstream to make ring more
portable but it seems unlikely to feature in a stable release before
the bookworm freeze.

Not sure what can be done about this, I tried reverting the
upstream commit in question using a Debian patch, but it did not
seem to revert cleanly.

Bug#1028432: debcargo patch to build with clap 4.

[Peter Michael Green]

Package: rust-debcargo

I've attached a patch which makes debcargo build with clap 4, debcargo
builds and it's cargo tests run succesfully, but I haven't actually done any
testing of the command line interface with this patch.

Fabian and I have agreed on irc that it probablly doesn't make sense to
switch debcargo to clap 4 in bookworm. I'm posting this patch here to
preserve it for trixie.
--- debcargo.orig/Cargo.toml
+++ debcargo/Cargo.toml
@@ -39,3 +39,3 @@
 [dependencies.clap]
-version = "3"
+version = "4"
 features = [
--- debcargo.orig/src/bin/debcargo.rs
+++ debcargo/src/bin/debcargo.rs
@@ -1,3 +1,3 @@
 use ansi_term::Colour::Red;
-use clap::{crate_version, AppSettings, Parser};
+use clap::{crate_version, CommandFactory, FromArgMatches, Parser};
 
@@ -50,3 +50,3 @@
 
-#[test]
+/*#[test]
 fn verify_app() {
@@ -54,11 +54,10 @@
 Opt::into_app().debug_assert()
-}
+}*/
 
 fn real_main() -> Result<()> {
-let m = Opt::clap()
+let m = Opt::command()
 .version(crate_version!())
-.global_setting(AppSettings::ColoredHelp)
 .get_matches();
 use Opt::*;
-match Opt::from_clap() {
+match Opt::from_arg_matches().unwrap() {
 Update => invalidate_crates_io_cache(),

Bug#1027775: cctbx, autopkgtest failure, errors about directory not being empty and being unable to find files.

[Peter Michael Green]

Package: cctbx
Version: 2022.9+ds2+~3.11.2+ds1-5
Severity: serious

Despite the fix uploaded for bug 1024859 the cctbx autopkgtest is still 
failing

and preventing the package from migrating to testing.


Testing cctbx with python3.10:
Sorry: Please run this program in an empty directory.
autopkgtest [21:28:30]: test command1: ---]
command1 FAIL non-zero exit status 1



=== 316 passed, 429 skipped, 2 xfailed, 8 warnings in 14.64s ===
cp: cannot stat 'dxtbx/tests': No such file or directory
cp: cannot stat 'dxtbx/conftest.py': No such file or directory
autopkgtest [21:28:55]: test command2: ---]
command2 FAIL non-zero exit status 1

Bug#1027484: commons-vfs build-depends on dropped package.

[Peter Michael Green]

Source: commons-vfs
Version: 2.1-2
Tags: bookworm, sid
Severity: serious
Justification: rc policy - "packages must be buildable within the same 
release"

User: debian...@lists.debian.org
Usertags: edos-uninstallable

commons-vfs build-depends on libcommons-net-java-doc which
is no longer built by the libcommons-net-java source package
and has been removed from both testing and unstable.

Bug#1027148: sccache - update build-dependency for rust-zip 0.6

[Peter Michael Green]

Package: sccache
Version: 0.4.0~~pre1-1
Severity: serious
Tags: patch

I've just uploaded rust-zip 0.6, the cargo dependencies in sccache 
already allow both

0.5 and 0.6 but the Debian dependencies currently only allow 0.5.

Trivial debdiff attached.diff -Nru sccache-0.4.0~~pre1/debian/changelog 
sccache-0.4.0~~pre1/debian/changelog
--- sccache-0.4.0~~pre1/debian/changelog2022-12-22 09:52:02.0 
+
+++ sccache-0.4.0~~pre1/debian/changelog2022-12-28 16:57:19.0 
+
@@ -1,3 +1,10 @@
+sccache (0.4.0~~pre1-1.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Depend on librust-zip-0.6-dev instead of rust-zip-0.5-dev
+
+ -- Peter Michael Green   Wed, 28 Dec 2022 16:57:19 +
+
 sccache (0.4.0~~pre1-1) unstable; urgency=medium
 
   [ upstream ]
diff -Nru sccache-0.4.0~~pre1/debian/control sccache-0.4.0~~pre1/debian/control
--- sccache-0.4.0~~pre1/debian/control  2022-12-22 09:50:54.0 +
+++ sccache-0.4.0~~pre1/debian/control  2022-12-28 16:57:19.0 +
@@ -66,7 +66,7 @@
  librust-uuid-1+v4-dev,
  librust-walkdir-2+default-dev,
  librust-which-4-dev,
- librust-zip-0.5-dev,
+ librust-zip-0.6-dev,
  librust-zstd-0.11+default-dev,
  libstring-shellquote-perl,
 Standards-Version: 4.6.2

Bug#1025005: Please upgrade to newer upstream release v7.3.2.

[Peter Michael Green]

> Please upgrade to newer upstream release v7.3.2.

dkg - do you have an opinion on this? I see you updated this package
to 6.x a few months ago and added yourself as an uploader,
presumably in support of some packaging effort, but without
knowing what you were packaging, I can't tell if the update to
7.x is likely to pose a problem or not.

Bug#1026969: ruby-aruba - build-dependencies unsatisfiable in bookworm/sid

[Peter Michael Green]

Package: ruby-aruba
Version: 2.1.0-1
Severity: serious
Justification: rc policy - "Packages must be buildable within the same release"
User:debian...@lists.debian.org
Usertags: edos-uninstallable

ruby-aruba build-depends on rubocop (<< 1.0) but bookworm and sid have version 
1.39.0+dfsg-1

Bug#1024086: [Pkg-rust-maintainers] Bug#1024086: rust-zip: please upgrade to v0.6

[Peter Michael Green]

On 15/11/2022 20:52, Peter Green wrote:

Please upgrade to v0.6, needed by projects I am preparing for Debian.


Unfortunately upstream do not seem to provide a changelog.

There seem to be three reverse dependencies, elan, rust-grcov and
rust-coreutils.

And since this message was written, more reverse dependencies have
appears, rust-tealdear and sccache.

Anyway I've now prepared an updated rust-zip package, uploaded it
to experimental and gone through the reverse dependencies, status
is as follows.

elan - needs code changes, I've made a patch but ideally i'd like
feedback from upstream and/or from the package's maintainer
in debian.

rust-coreutils - no changes needed

rust-grcov - needs hunk removing from dependency patch

tealdeer - needs dependency patch (or update, but I had other issues 
trying to update), no code changes needed


sccache - needs dependency change in Debian packaging.

Bug#1026304: obantoo build-depends on dropped package.

[Peter Michael Green]

Package: obantoo
Version: 2.1.12+ds1-3
Severity: serious
Justification: rc policy - "packages must be buildable within the same 
release"

User: debian...@lists.debian.org
Usertags: edos-uninstallable

obantoo build-depends on libitext5-java-doc which is no longer built
by the libitext5-java source package. It is still present in unstable as
a cruft package, but is completely gone from testing.

Bug#1025685: [Pkg-rust-maintainers] Bug#1025685: rust-pyo3: please upgrade to v0.17

[Peter Michael Green]

I've prepared an upload of verion 0.17 of pyo3 and built/tested breezy 
with it. It built successfully the autopkgtest passed. Any objections if 
I go ahead and update to this version?

Bug#1024890: ntcard - build-dependencies unsatisfiable on 32-bit.

[Peter Michael Green]

Package: ntcard
Version: 1.2.2+dfsg-4
Severity: serious

ntcard build-depends on libnthash-dev which is no longer available on 
32-bit architectures.


There are in general 3 potential soloutions for this (in roughly 
descending order of preference)


1. Fix your build-dependencies so they are once again available on all 
release architectures.
2. Eliminate the build-dependencies in question, either generally or on 
those specific architectures.
3. Declare your package unsupported on 32-bit architectures and file a 
removal bug with the ftpmasters.


I do not know which are pratical in the case of your particular package.

Bug#1024889: pplacer: build-depedends on dropped package.

[Peter Michael Green]

Package: pplacer
version: 1.1~alpha19-6
Severity: serious
Justification: rc policy: "packages must be buildable within the same 
release"


pplacer build-depends on libmcl-ocaml-dev which is no longer built by the
mcl source package. It is still present in unstable as a cruft package, but
is completely gone from testing.

Bug#1024376: [Pkg-rust-maintainers] Bug#1024376: rust-derive-builder: please update to to v0.11

[Peter Michael Green]

Please upgrade to newer upstream branch v0.11.
The new version depends on rust-derive-builder-macro which is not 
currently in Debian.

Bug#1024009: rust-wasmer-enumset - should this package be removed

[Peter Michael Green]

Package: rust-wasmer-enumset

rust-wasmer-enumset and it's support crate rust-wasmer-enumset-derive 
are a fork of the enumset/enumset-derive crates to fix a specific issue. 
The issue has now been fixed in the enumset crates and the 
wasmer-enumset crates are unmaintained


The only reverse-dependency in Debian was cursive-core which was patched 
to use wasmer-enumset, I have now (after discussion with it's maintainer 
on IRC) switched that over to using enumset. So there doesn't seem any 
reason to keep wasmer-enumset around.

Bug#1023144: rust-coreutils FTBFS after textwrap update.

[Peter Michael Green]

Package: rust-coreutils
Version: 0.0.15-1
Severity: serious




cargo build  --features "arch base32 base64 basename basenc cat chcon 
chgrp chmod chown chroot cksum comm cp csplit cut date dd df dir 
dircolors dirname du echo env expand expr factor false fmt fold groups 
hashsum head hostid hostname id install join kill link ln logname ls 
mkdir mkfifo mknod mktemp more mv nice nl nohup nproc numfmt od paste 
pathchk pinky pr printenv printf ptx pwd readlink realpath relpath rm 
rmdir runcon seq shred shuf sleep sort split stat stdbuf sum sync tac 
tail tee test timeout touch tr true truncate tsort tty uname unexpand 
uniq unlink uptime users vdir wc who whoami yes" --release 
--no-default-features

error: failed to select a version for the requirement `textwrap = "^0.15"`
candidate versions found which didn't match: 0.16.0
location searched: directory source 
`/rust-coreutils-0.0.15/debian/cargo_registry` (which is replacing 
registry `crates-io`)

required by package `coreutils v0.0.15 (/rust-coreutils-0.0.15)`
perhaps a crate was updated and forgotten to be re-vendored?
make[2]: *** [GNUmakefile:279: build-coreutils] Error 101

Bug#1019296: tt-rss - build-dependencies unsatisfiable

[Peter Michael Green]

Package: tt-rss
Version: 21~git20210204.b4cbc79+dfsg-1
Serverity: serious
Tags: bookworm, sid

tt-rss build-depends on libjs-prototype (= 1.7.1-3.1) but 
testing/unstable has version 1.7.3-1

Bug#1019163: rust-smol - unsatisfiable build-dependency

[Peter Michael Green]

Package: rust-smol
Version: 1.2.5-2
Severity: serious

rust-smol build-depends on librust-nix-0.24+default-dev but the nix 
crate in debian testing/unstable is now at 0.25

Bug#1019090: librust-petgraph-dev: impossible to satisfy dependency

[Peter Michael Green]

There is a new upstream version of petgraph that uses the new version of 
fixedbitset, I suspect the most sensible way to fix this bug is 
uploading it and it has been prepared in debcargo-conf (initially 
byBlair Noctis with some further tweaking by myself)


However before I upload it, I wanted to check the reverse dependencies, 
I go started on doing so but rust-cargo-lock proved to be a fair bit of 
effort to update. I'll probablly look at the remaining packages soon, 
but if others want to take a look that is fine too.


rust-cargo-lock - update prepared in debcargo-conf (along with updates 
for gumdrop and gumdrop-derive which it depends on)

rust-lalrpop -update prepared in debcargo-conf
rust-rust-code-analysis - already broken and not in testing.
rust-tree-magic - update prepared in debcargo-conf
rust-tree-magic-mini - fixed upstream, but Debian packaging not 
investigated yet.

librust-ena+congruence-closure-dev - not investigated yet
librust-parking-lot-core+petgraph-dev - already depends on new version 
of petgraph

librust-parking-lot-core-0.4+petgraph-dev - not investigated yet
rust-code-analysis-cli - indirect depedency/built-using, already broken 
and not in testing.

Bug#1019099: rust-ahash - autopkgtest failure

[Peter Michael Green]

Package: rust-ahash
Version: 0.7.6-4
Severity: serious

The autopkgtest of rust-ahash is failing

https://ci.debian.net/data/autopkgtest/testing/amd64/r/rust-ahash/25673987/log.gz


Testing aeshash/u8
thread 'main' panicked at 'aes must be enabled', tests/bench.rs:20:5
stack backtrace:
0: std::panicking::begin_panic
  at /usr/src/rustc-1.59.0/library/std/src/panicking.rs:525:12
1: ahash::aeshash
  at ./tests/bench.rs:20:5
2: ahash::bench_ahash::{{closure}}::{{closure}}
  at ./tests/bench.rs:92:81
3: criterion::bencher::Bencher::iter
  at 
/tmp/tmp.wNUW0kfuKe/registry/criterion-0.3.5/src/bencher.rs:88:23
4: ahash::bench_ahash::{{closure}}
  at ./tests/bench.rs:89:54
5:  as 
criterion::routine::Routine>::bench::{{closure}}
  at 
/tmp/tmp.wNUW0kfuKe/registry/criterion-0.3.5/src/routine.rs:209:17
6: core::iter::adapters::map::map_fold::{{closure}}
  at 
/usr/src/rustc-1.59.0/library/core/src/iter/adapters/map.rs:84:28
7: core::iter::traits::iterator::Iterator::fold
  at 
/usr/src/rustc-1.59.0/library/core/src/iter/traits/iterator.rs:2171:21
8:  as 
core::iter::traits::iterator::Iterator>::fold
  at 
/usr/src/rustc-1.59.0/library/core/src/iter/adapters/map.rs:124:9
9: core::iter::traits::iterator::Iterator::for_each
  at 
/usr/src/rustc-1.59.0/library/core/src/iter/traits/iterator.rs:736:9
   10:  as 
alloc::vec::spec_extend::SpecExtend>::spec_extend
  at 
/usr/src/rustc-1.59.0/library/alloc/src/vec/spec_extend.rs:40:17
   11:  as 
alloc::vec::spec_from_iter_nested::SpecFromIterNested>::from_iter
  at 
/usr/src/rustc-1.59.0/library/alloc/src/vec/spec_from_iter_nested.rs:56:9
   12:  as 
alloc::vec::spec_from_iter::SpecFromIter>::from_iter
  at 
/usr/src/rustc-1.59.0/library/alloc/src/vec/spec_from_iter.rs:33:9
   13:  as 
core::iter::traits::collect::FromIterator>::from_iter
  at /usr/src/rustc-1.59.0/library/alloc/src/vec/mod.rs:2541:9
   14: core::iter::traits::iterator::Iterator::collect
  at 
/usr/src/rustc-1.59.0/library/core/src/iter/traits/iterator.rs:1745:9
   15:  as 
criterion::routine::Routine>::bench
  at 
/tmp/tmp.wNUW0kfuKe/registry/criterion-0.3.5/src/routine.rs:205:9
   16: criterion::routine::Routine::test
  at 
/tmp/tmp.wNUW0kfuKe/registry/criterion-0.3.5/src/routine.rs:18:9
   17: criterion::benchmark_group::BenchmarkGroup::run_bench
  at 
/tmp/tmp.wNUW0kfuKe/registry/criterion-0.3.5/src/benchmark_group.rs:339:21
   18: criterion::benchmark_group::BenchmarkGroup::bench_with_input
  at 
/tmp/tmp.wNUW0kfuKe/registry/criterion-0.3.5/src/benchmark_group.rs:269:9
   19: ahash::bench_ahash
  at ./tests/bench.rs:87:5
   20: ahash::benches
  at 
/tmp/tmp.wNUW0kfuKe/registry/criterion-0.3.5/src/macros.rs:71:17
   21: ahash::main
  at 
/tmp/tmp.wNUW0kfuKe/registry/criterion-0.3.5/src/macros.rs:127:17
   22: core::ops::function::FnOnce::call_once
  at /usr/src/rustc-1.59.0/library/core/src/ops/function.rs:227:5
note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose 
backtrace.

error: test failed, to rerun pass '--bench ahash'
autopkgtest [16:38:41]: test 
librust-ahash+compile-time-rng-dev:compile-time-rng: ---]
autopkgtest [16:38:41]: test 
librust-ahash+compile-time-rng-dev:compile-time-rng:  - - - - - - - - - - 
results - - - - - - - - - -
librust-ahash+compile-time-rng-dev:compile-time-rng FAIL non-zero exit status 
101
autopkgtest [16:38:41]:  summary
rust-ahash:@ FAIL non-zero exit status 101
librust-ahash-dev:default FAIL non-zero exit status 101
librust-ahash-dev:std FAIL non-zero exit status 101
librust-ahash-dev:   FAIL non-zero exit status 101
librust-ahash+compile-time-rng-dev:compile-time-rng FAIL non-zero exit status 
101


Thanks to an annoyance with the way testing migration autopkgtests 
interact with skip-not-installable this is blocking the migration of the 
new version of rust-once-cell to testing. So we would appreciate a quick 
fix.

Bug#952159: rust-nodrop-union: FTBFS: dh_auto_test: error: /usr/share/cargo/bin/cargo build returned exit code 101

[Peter Michael Green]

I have written a merge request [1] to fix FTBFS on all platforms. Tested on my
dev machine on amd64 and riscv64. If more helps are needed, please let me know.

Thanks for the patch,

Was this patch just a result of general QA activity or is there some 
program you are trying to package?


We can fix this up if there is a good reason, but i'm more inclined to 
say a crate that is abandoned upstream, fails to build with current 
rustc and has been superseeded by funcationality in the standard library 
probablly doesn't belong in Debian.

Bug#998306: dwarf2sources FTBFS with rust-object 0.20

[Peter Michael Green]

severity 998306 serious
thanks


I have uploaded rust-backtrace and related packages to experimental for now.


rust-backtrace and related packages have now been uploaded to unstable,
bumping to serious.

Bug#1016808: debcargo does not handle extra features for dev-dependencies declared in the features section.

[Peter Michael Green]

Package: debcargo
Version: 2.5.0-3

Alexander Kjäll was working on packaging wl-clipboard-rs when he ran 
into an autopkgtest failure.

debian cargo wrapper: options, profiles, parallel: ['parallel=4'] [] ['-j4']
debian cargo wrapper: rust_type, gnu_type: x86_64-unknown-linux-gnu, 
x86_64-linux-gnu
debian cargo wrapper: linking /usr/share/cargo/registry/* into 
/tmp/tmp.Zo0aVr3cJs/registry/
debian cargo wrapper: options, profiles, parallel: ['parallel=4'] [] ['-j4']
debian cargo wrapper: rust_type, gnu_type: x86_64-unknown-linux-gnu, 
x86_64-linux-gnu
debian cargo wrapper: running subprocess (['env', 'RUST_BACKTRACE=1', 
'/usr/bin/cargo', '-Zavoid-dev-deps', 'test', '--verbose', '--verbose', '-j4', 
'--target', 'x86_64-unknown-linux-gnu', '--all-targets', 
'--no-default-features', '--features', 'native_lib'],) {}
error: no matching package named `parking_lot` found
location searched: registry `crates-io`
required by package `wayland-server v0.29.4`
 ... which satisfies dependency `wayland-server = "^0.29.4"` of package 
`wl-clipboard-rs v0.6.0 (/usr/share/cargo/registry/wl-clipboard-rs-0.6.0)`


Investigating showed that Cargo.toml contains the following


[dev-dependencies.wayland-server]
version = "0.29.4"

[features]
dlopen = ["native_lib", "wayland-client/dlopen", "wayland-server/dlopen"]
native_lib = ["wayland-client/use_system_lib", 
"wayland-server/use_system_lib"]
If I am reading this correctly this means that when running tests with 
the "native_lib" feature enabled, the "use_system_lib" feature of the 
wayland-server package will be enabled.


However debcargo does not generate a test dependency on 
librust-wayland-server+use-system-lib-dev


I believe this is the result of the error Alexander encountered (and I 
reproduced)


The packaging for wl-clipboard-rs ia available in the 
WIP-wl-clipboard-rs branch of debcargo-conf.

Bug#1015187: orthanc-dicomweb, build-depedencies unsatisfiable on armel.

[Peter Michael Green]

Package: orthanc-dicomweb
Version: 1.7+dfsg-5

The build-dependencies of orthanc-dicomweb are not satisfiable on armel


  package: orthanc-dicomweb
  version: 1.7+dfsg-5
  architecture: any
  type: src
  status: broken
  reasons:
   -
    missing:
 pkg:
  package: node-ms
  version: 2.1.3+~cs0.7.31-2
  architecture: all
  unsat-dependency: nodejs:armel
 depchains:
  -
   depchain:
    -
 package: orthanc-dicomweb
 version: 1.7+dfsg-5
 architecture: any
 type: src
 depends: node-axios:armel
    -
 package: node-axios
 version: 0.26.1+dfsg-2
 architecture: all
 depends: node-follow-redirects:armel (>= 1.13.0)
    -
 package: node-follow-redirects
 version: 1.15.1+~1.14.1-2
 architecture: all
 depends: node-debug:armel
    -
 package: node-debug
 version: 4.3.4+~cs4.1.7-1
 architecture: all
 depends: node-ms:armel
This in itself is nothing new, it was not previously rc however as there 
were no binary packages on armel.


However, a few days ago, the node-undici source package which builds the 
node-llhttp binary package was accepted into unstable, there was a 
screw-up in the packaging leading to the node-llhttp package briefly 
providing node-debug. As a result of this the build-dependencies of 
orthanc-dicomweb breifly became satisfiable on armel. The Debian 
autobuilders spotted this and succesfully built orthanc-dicomweb. Then a 
few days later the mistake in node-undici was fixed with the result that 
the build-dependencies of orthanc-dicomweb are once-again unsatisfiable 
on armel.


So now we have a binary package in testing and unstable that can't be 
rebuilt or updated, that is rc.


I see two possible routes forward.

1. Make dependency adjustments, either in orthanc-dicomweb or in 
packages it depends on so that it can be built on armel, I do not know 
how practical this is to do without causing other problems.
2. Declare orthanc-dicomweb unsupported on armel and file a removal 
request with the ftpmasters.

Bug#1011620: newsboat - needs update for new gettext crates.

[Peter Michael Green]

While I did not originally plan to NMU this, the bug has gone well over 
a month with no maintainer response, and Fabian Grünbichler said on irc 
that he had tested the patched newsboat and it worked for him, so I have 
decided to NMU it.


Final debdiff attatched.
diff -Nru newsboat-2.21/debian/changelog newsboat-2.21/debian/changelog
--- newsboat-2.21/debian/changelog  2022-03-06 00:26:54.0 +
+++ newsboat-2.21/debian/changelog  2022-07-16 19:13:03.0 +
@@ -1,3 +1,11 @@
+newsboat (2.21-1.3) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Bump dependencies on gettext-sys, gettext-rs and proptest crates.
+(Closes: #1011620, #1013539)
+
+ -- Peter Michael Green   Sat, 16 Jul 2022 19:13:03 +
+
 newsboat (2.21-1.2) unstable; urgency=medium
 
   * Non-maintainer upload.
diff -Nru newsboat-2.21/debian/control newsboat-2.21/debian/control
--- newsboat-2.21/debian/control2022-03-05 21:46:48.0 +
+++ newsboat-2.21/debian/control2022-06-23 16:47:20.0 +
@@ -26,14 +26,14 @@
librust-nom-7-dev,
librust-curl-sys-0.4+ssl-dev,
librust-libc-0.2-dev,
-   librust-gettext-rs-0.4-dev,
+   librust-gettext-rs-0.7-dev,
librust-natord-1-dev,
librust-clap-2-dev,
-   librust-gettext-sys-0.19-dev,
+   librust-gettext-sys-0.21-dev,
librust-tempfile-3-dev,
-   librust-proptest-0.9+bit-set-dev,
-   librust-proptest-0.9+rusty-fork-dev,
-   librust-proptest-0.9+timeout-dev,
+   librust-proptest-1+bit-set-dev,
+   librust-proptest-1+rusty-fork-dev,
+   librust-proptest-1+timeout-dev,
librust-percent-encoding-2-dev,
librust-section-testing-0.0.4-dev
 Standards-Version: 4.5.0
diff -Nru newsboat-2.21/debian/patches/relax-deps.diff 
newsboat-2.21/debian/patches/relax-deps.diff
--- newsboat-2.21/debian/patches/relax-deps.diff2022-03-05 
21:43:42.0 +
+++ newsboat-2.21/debian/patches/relax-deps.diff2022-06-23 
16:45:28.0 +
@@ -20,7 +20,7 @@
  curl-sys = "0.4.5"
  libc = "0.2"
 -gettext-rs = "0.5.0"
-+gettext-rs = "0.4"
++gettext-rs = "0.7.0"
  natord = "1.0.9"
  lazy_static = "1.4.0"
  
@@ -29,7 +29,7 @@
  
  [dependencies.gettext-sys]
 -version = "0.19.9"
-+version = "0.19.8"
++version = "0.21.0"
  # Don't let the crate build its own copy of gettext; force it to use the one
  # built into glibc.
  features = [ "gettext-system" ]
@@ -38,7 +38,7 @@
  tempfile = "3"
 -# 0.9.6 fixes build failures on Nightly >=2020-04-08: 
https://github.com/newsboat/newsboat/issues/870
 -proptest = ">=0.9.6"
-+proptest = "0.9"
++proptest = "1.0"
  section_testing = "0.0.4"
 Index: newsboat-2.21/rust/regex-rs/Cargo.toml
 ===
@@ -49,4 +49,4 @@
  bitflags = "1.2"
  libc = ">=0.2.69"
 -gettext-rs = "0.5.0"
-+gettext-rs = "0.4.0"
++gettext-rs = "0.7.0"

Bug#1014663: vk3d - build-dependencies not satisfiable on most architectures.

[Peter Michael Green]

reassign 1014663 vkd3d 1.2-13
thanks
vk3d's build-dependencies are unsatisfible on most architectures, 
because debian/control was not updated to reflect the new version number.

Sorry messed up the package name, it's vkd3d not vk3d

Bug#1014663: vk3d - build-dependencies not satisfiable on most architectures.

[Peter Michael Green]

Package: vk3d
version: 1.2-13

vk3d's build-dependencies are unsatisfible on most architectures, 
because debian/control was not updated to reflect the new version number.

Bug#1013729: rust-zbus: Please upgrade to version 2.2.0

[Peter Michael Green]

There seems to be a group of 4 closely related packages, zbus, 
zbus-macros, zvariant and zvariant-derive which

should probably be upgraded in lockstep.

2.x (3.x for zvariant) is a semver break, so reverse dependencies need 
to be investigated.


rust-ashpd - fixed upstream, upstream fix involves a semver bump but 
there are no rdeps.
rust-libslirp - no upstream fix, no rdeps, but does produce a binary 
crate. Popcon is low, but we did get a bug report from a real user, so 
it's not totally unused.

rust-secret-service - no upstream fix, no rdeps, no binarys
squeekboard - no upstream fix, seems to be used by the "phosh" desktop.

I can't find any upstream changelog, but I did a quick attempt at 
bumping the dependencies in libslirp-helper and came to the conclusion 
it would be a non-trivial porting job.


There is also the problem that squeekboard is currently failing to build 
on ppc64el due to what may or may not

be a rust bug ( https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1013273 )

The other option would be to introduce seperate packages for the old 
versions of the crates, so that the
main packages could be upgraded to the new semver, we try to avoid such 
duplication if possible

though and I do not intend to introduce packages myself.

I belive hntourne was also showing an interest in zbus, putting him in cc.

Bug#969609: rust-zstd: unbuildable, uninstallable, depends on non-existent rust-zstd-safe

[Peter Michael Green]

The rust-zstd package has both a dependency and a build-dependency on
librust-zstd-safe-2.0.3+experimental-dev, which does not exist anywhere in
Debian.  Presumably it would be built by a rust-zstd-safe package, but no
such package exists, including in the Debian NEW queue.

Specifically looking through the mailing list archives.

rust-zstd-sys, rust-zstd-safe and rust-zstd were all uploaded
to NEW in mid January 2020. In late Febuary 2020 the ftpmasters
processed the uploads, zstd was accepted but zstd-sys and zstd-safe
were rejected.

zstd-sys and zstd-safe were re-uploaded to new in march 2020
and rejected again in may 2020.

zstd-sys was once-again uploaded to NEW in october 2020
and this time was accepted. At around the same time a
source-only upload of zstd was also made, but zstd-safe
was not touched.

The route to fixing rust-zstd, thus involves fixing the ftpmaster's
objection to the previous upload, checking the package for
any other such issues and if-so fixing them and then re-uploading
it. The reject mail can be found at
https://alioth-lists.debian.net/pipermail/pkg-rust-maintainers/2020-May/012388.html

Bug#1014198: deepin-movie: binary packages still depend on old libav* packages after rebuild.

[Peter Michael Green]

Package: deepin-movie
Version: 5.7.15-3
Severity: serious

The deepin-movie-reborn source package was recently binnmu'd for the 
ffmpeg transtion,
unfortunately though the resulting binary packages still depend on the 
old libav* packages.

Bug#1014106: RM: rust-common-failures -- ROM; needs removed rust-failure

[Peter Michael Green]

I just uploaded new package rust-common-failures now sitting in NEW, but
then realized that rust-failure which it depends on is removed from
Debian (see bug#973298).

Please drop rust-common-failures from NEW queue - it is useless.

This is not entirely correct, rust-failure was indeed removed
from unstable, but it was re-instated the next day.