Bug#1075860: FTBFS: rustc 1.78

[Peter Michael Green]

I'm getting a bunch of "unnecessary qualification" issues:

The unnessacery qualifications issues are trivial to fix, just remove
unused_qualifications from the list of lints to deny in lib.rs

Unfortunately though, I was unable to get parsec-interface to build
with the new version of prost.

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#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#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#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#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#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#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#1050891: sccache - update for new addr2line.

[Peter Michael Green]

On 31/08/2023 08:50, Jonas Smedegaard wrote:


, but it is a risky game,


Letting stuff  fall ever more out of date is also a risky game as
it tends to mean stuff gets even more intertwined when we
do finally try to update it and if the version of rust-cargo used
by debcargo gets too far out of date then things can get
*really* painful.



We do have the option of using semver-suffix packages, but
we try to use those sparingly for several reasons.

* Debian in general discourages multiple copies of what is
  essentially the same codebase.
* It's more packages to maintain (or fail to maintain)
* The packages need to pass NEW, which introduces unpredictable
   delay to the whole process.

It's worth noting that most languages in Debian don't normally
put any upper limits on dependencies used at build time,
despite having far less ability to detect problems at compile
time than rust does.

I'm not at all convinced that these dependency bumps are any
riskier than many uploads for packages in other languages that
happen, unnoticed, all the time.


Allow those responsible for maintaining packages to actually do that.
Please in future coordinate *before* doing breaking changes (unless it
happens accidentally, of course).


How exactly do you want this coordination to work? how long
do you think it is reasonable for us to give you to respond? how
should the actual uploads be handled given that ideally for
minimum breakage the packages would be uploaded at the
same time?

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#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#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#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#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#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#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#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#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#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#1020779: slic3r-prusa: FTBFS on 32-bit arches

[Peter Michael Green]

To clarify the situation for people stumbling across this bug.

The issue in cereal was fixed, however slic3r-prusa still FTBFS because of

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

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#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#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#1014034: rust-hdrhistogram: autopkgtest failure on i386

[Peter Michael Green]

Package: rust-hdrhistogram
Version: 7.5.0-1
Severity: serious

I recently updated the hdrhistogram package and as part of that I 
resolved the issues that were blocking the tests from running on as 
autopkgtests.


Unfortunately when running the autopkgtests on i386 two tests failed, I 
can also reproduce this locally.


|
|failures:  iter_quantiles_saturated_count_before_max_value stdout 
 thread 'iter_quantiles_saturated_count_before_max_value' panicked 
at 'capacity overflow', library/alloc/src/raw_vec.rs:518:5 stack 
backtrace: 0: rust_begin_unwind at 
/usr/src/rustc-1.59.0/library/std/src/panicking.rs:498:5 1: 
core::panicking::panic_fmt at 
/usr/src/rustc-1.59.0/library/core/src/panicking.rs:116:14 2: 
core::panicking::panic at 
/usr/src/rustc-1.59.0/library/core/src/panicking.rs:48:5 3: 
alloc::raw_vec::capacity_overflow at 
/usr/src/rustc-1.59.0/library/alloc/src/raw_vec.rs:518:5 4: 
alloc::raw_vec::handle_reserve at 
/usr/src/rustc-1.59.0/library/alloc/src/raw_vec.rs:489:34 5: 
alloc::raw_vec::RawVec::reserve::do_reserve_and_handle at 
/usr/src/rustc-1.59.0/library/alloc/src/raw_vec.rs:287:13 6: 
alloc::raw_vec::RawVec::reserve at 
/usr/src/rustc-1.59.0/library/alloc/src/raw_vec.rs:291:13 7: 
alloc::vec::Vec::reserve at 
/usr/src/rustc-1.59.0/library/alloc/src/vec/mod.rs:809:9 8: 
alloc::vec::Vec::extend_desugared at 
/usr/src/rustc-1.59.0/library/alloc/src/vec/mod.rs:2642:17 9: 
 as 
alloc::vec::spec_extend::SpecExtend>::spec_extend at 
/usr/src/rustc-1.59.0/library/alloc/src/vec/spec_extend.rs:18:9 10: 
 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:37:9 
11:  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 12: 
 as 
core::iter::traits::collect::FromIterator>::from_iter at 
/usr/src/rustc-1.59.0/library/alloc/src/vec/mod.rs:2541:9 13: 
core::iter::traits::iterator::Iterator::collect at 
/usr/src/rustc-1.59.0/library/core/src/iter/traits/iterator.rs:1745:9 
14: iterators::iter_quantiles_saturated_count_before_max_value at 
./tests/iterators.rs:569:55 15: 
iterators::iter_quantiles_saturated_count_before_max_value::{{closure}} 
at ./tests/iterators.rs:561:1 16: 
core::ops::function::FnOnce::call_once at 
/usr/src/rustc-1.59.0/library/core/src/ops/function.rs:227:5 17: 
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.  
iter_quantiles_iterates_to_quantile_10_as_it_reaches_last_bucket 
stdout  thread 
'iter_quantiles_iterates_to_quantile_10_as_it_reaches_last_bucket' 
panicked at 'capacity overflow', library/alloc/src/raw_vec.rs:518:5 
stack backtrace: 0: rust_begin_unwind at 
/usr/src/rustc-1.59.0/library/std/src/panicking.rs:498:5 1: 
core::panicking::panic_fmt at 
/usr/src/rustc-1.59.0/library/core/src/panicking.rs:116:14 2: 
core::panicking::panic at 
/usr/src/rustc-1.59.0/library/core/src/panicking.rs:48:5 3: 
alloc::raw_vec::capacity_overflow at 
/usr/src/rustc-1.59.0/library/alloc/src/raw_vec.rs:518:5 4: 
alloc::raw_vec::handle_reserve at 
/usr/src/rustc-1.59.0/library/alloc/src/raw_vec.rs:489:34 5: 
alloc::raw_vec::RawVec::reserve::do_reserve_and_handle at 
/usr/src/rustc-1.59.0/library/alloc/src/raw_vec.rs:287:13 6: 
alloc::raw_vec::RawVec::reserve at 
/usr/src/rustc-1.59.0/library/alloc/src/raw_vec.rs:291:13 7: 
alloc::vec::Vec::reserve at 
/usr/src/rustc-1.59.0/library/alloc/src/vec/mod.rs:809:9 8: 
alloc::vec::Vec::extend_desugared at 
/usr/src/rustc-1.59.0/library/alloc/src/vec/mod.rs:2642:17 9: 
 as 
alloc::vec::spec_extend::SpecExtend>::spec_extend at 
/usr/src/rustc-1.59.0/library/alloc/src/vec/spec_extend.rs:18:9 10: 
 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:37:9 
11:  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 12: 
 as 
core::iter::traits::collect::FromIterator>::from_iter at 
/usr/src/rustc-1.59.0/library/alloc/src/vec/mod.rs:2541:9 13: 
core::iter::traits::iterator::Iterator::collect at 
/usr/src/rustc-1.59.0/library/core/src/iter/traits/iterator.rs:1745:9 
14: 
iterators::iter_quantiles_iterates_to_quantile_10_as_it_reaches_last_bucket 
at ./tests/iterators.rs:717:55 15: 
iterators::iter_quantiles_iterates_to_quantile_10_as_it_reaches_last_bucket::{{closure}} 
at ./tests/iterators.rs:703:1 16: 
core::ops::function::FnOnce::call_once at 
/usr/src/rustc-1.59.0/library/core/src/ops/function.rs:227:5 17: 
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. failures: 

Bug#1012221: [Pkg-rust-maintainers] Bug#1012221: rust-stdweb-internal-macros (build-)depends on old version of rust-sha1.

[Peter Michael Green]

reopen 1012221
thanks

On 02/06/2022 13:29, Sylvestre Ledru wrote:
4. Remove the stdweb features in instant and parking-lot and allow 
stdweb to be removed from testing.


I think I implemented this solution.


Thanks,

That solves the issue for instant, parking-lot and their reverse 
dependencies, but stdweb-internal-macros remains rc buggy, hence this 
bug should stay open until it is removed.




I opened #1012261 for the removal of the packages.
It appears the ftpmasters responded to that bug by only removing stdweb, 
not the other stdweb related packages.

Bug#1012284: elan - FTBFS unsatisfiable cargo dependencies

[Peter Michael Green]

Package: elan
Version: 1.3.1-3
Severity: serious
Tags: patch

A number of rust crates have been updated recently, as a result your 
package no longer builds, I have updated the patches to relax the 
dependencies and was able to succesfully build the package, I have not 
tested it beyond that.
From: Christopher Hoskin 
Date: Wed, 26 Jan 2022 19:46:47 +
Subject: Revert "feat: support tar.zst archives"

This reverts commit 3241c307cfcff08f02ae9856aa505c05fc14fcd7.
---
 Cargo.lock | 39 --
 src/elan-dist/Cargo.toml   |  1 -
 src/elan-dist/src/component/package.rs | 16 --
 src/elan-dist/src/download.rs  |  4 ++--
 src/elan-dist/src/manifestation.rs | 25 +++---
 5 files changed, 15 insertions(+), 70 deletions(-)

Index: elan-1.3.1/Cargo.lock
===
--- elan-1.3.1.orig/Cargo.lock
+++ elan-1.3.1/Cargo.lock
@@ -394,7 +394,6 @@ dependencies = [
  "winapi 0.3.9",
  "winreg 0.8.0",
  "zip",
- "zstd",
 ]
 
 [[package]]
@@ -778,15 +777,6 @@ source = "registry+https://github.com/ru
 checksum = "b71991ff56294aa922b450139ee08b3bfc70982c6b2c7562771375cf73542dd4"
 
 [[package]]
-name = "jobserver"
-version = "0.1.24"
-source = "registry+https://github.com/rust-lang/crates.io-index;
-checksum = "af25a77299a7f711a01975c35a6a424eb6862092cc2d6c72c4ed6cbc56dfc1fa"
-dependencies = [
- "libc",
-]
-
-[[package]]
 name = "js-sys"
 version = "0.3.55"
 source = "registry+https://github.com/rust-lang/crates.io-index;
@@ -1873,32 +1863,3 @@ dependencies = [
  "thiserror",
  "time 0.1.43",
 ]
-
-[[package]]
-name = "zstd"
-version = "0.9.0+zstd.1.5.0"
-source = "registry+https://github.com/rust-lang/crates.io-index;
-checksum = "07749a5dc2cb6b36661290245e350f15ec3bbb304e493db54a1d354480522ccd"
-dependencies = [
- "zstd-safe",
-]
-
-[[package]]
-name = "zstd-safe"
-version = "4.1.1+zstd.1.5.0"
-source = "registry+https://github.com/rust-lang/crates.io-index;
-checksum = "c91c90f2c593b003603e5e0493c837088df4469da25aafff8bce42ba48caf079"
-dependencies = [
- "libc",
- "zstd-sys",
-]
-
-[[package]]
-name = "zstd-sys"
-version = "1.6.1+zstd.1.5.0"
-source = "registry+https://github.com/rust-lang/crates.io-index;
-checksum = "615120c7a2431d16cf1cf979e7fc31ba7a5b5e5707b29c8a99e5dbf8a8392a33"
-dependencies = [
- "cc",
- "libc",
-]
Index: elan-1.3.1/src/elan-dist/Cargo.toml
===
--- elan-1.3.1.orig/src/elan-dist/Cargo.toml
+++ elan-1.3.1/src/elan-dist/Cargo.toml
@@ -14,7 +14,6 @@ itertools = "0.10.0"
 url = "2.2.1"
 tar = "0.4.33"
 flate2 = "1.0.14"
-zstd = "0.9"
 walkdir = "2.3.1"
 toml = "0.5.8"
 sha2 = ">= 0.9.2, <0.11"
Index: elan-1.3.1/src/elan-dist/src/component/package.rs
===
--- elan-1.3.1.orig/src/elan-dist/src/component/package.rs
+++ elan-1.3.1/src/elan-dist/src/component/package.rs
@@ -4,7 +4,6 @@
 
 extern crate filetime;
 extern crate flate2;
-extern crate zstd;
 extern crate tar;
 
 use errors::*;
@@ -140,21 +139,6 @@ impl<'a> TarGzPackage<'a> {
 
 TarPackage::unpack(stream, path)
 }
-pub fn unpack_file(path: , into: ) -> Result<()> {
-let file = File::open(path).chain_err(|| ErrorKind::ExtractingPackage)?;
-Self::unpack(file, into)
-}
-}
-
-#[derive(Debug)]
-pub struct TarZstdPackage<'a>(TarPackage<'a>);
-
-impl<'a> TarZstdPackage<'a> {
-pub fn unpack(stream: R, path: ) -> Result<()> {
-let stream = zstd::stream::read::Decoder::new(stream)?;
-
-TarPackage::unpack(stream, path)
-}
 pub fn unpack_file(path: , into: ) -> Result<()> {
 let file = File::open(path).chain_err(|| ErrorKind::ExtractingPackage)?;
 Self::unpack(file, into)
Index: elan-1.3.1/src/elan-dist/src/download.rs
===
--- elan-1.3.1.orig/src/elan-dist/src/download.rs
+++ elan-1.3.1/src/elan-dist/src/download.rs
@@ -99,9 +99,9 @@ impl<'a> DownloadCfg<'a> {
 Ok(())
 }
 
-pub fn download_and_check(, url_str: ) -> Result> {
+pub fn download_and_check(, url_str: , ext: ) -> Result> {
 let url = utils::parse_url(url_str)?;
-let file = self.temp_cfg.new_file()?;
+let file = self.temp_cfg.new_file_with_ext("", ext)?;
 
 utils::download_file(, , None, &|n| (self.notify_handler)(n.into()))?;
 
Index: elan-1.3.1/src/elan-dist/src/manifestation.rs
===
--- elan-1.3.1.orig/src/elan-dist/src/manifestation.rs
+++ elan-1.3.1/src/elan-dist/src/manifestation.rs
@@ -1,6 +1,6 @@
 //! Manifest a particular Lean version by installing it from a distribution server.
 
-use component::{TarGzPackage, TarZstdPackage, ZipPackage};
+use component::{TarGzPackage, ZipPackage};
 use download::DownloadCfg;
 use elan_utils::utils;
 use errors::*;
@@ 

Bug#1010505: golang-gopkg-libgit2-git2go.v31 autopkgtest failure with libgit2 1.3

[Peter Michael Green]

Package: golang-gopkg-libgit2-git2go.v31
Version: 31.4.3-4
Severity: serious

The autopkgtest for golang-gopkg-libgit2-git2go.v31 is failing with 
libgit2 1.3

and hence blocking the transition.

https://ci.debian.net/data/autopkgtest/testing/amd64/g/golang-gopkg-libgit2-git2go.v31/21329197/log.gz




github.com/libgit2/git2go/v31
# github.com/libgit2/git2go/v31
src/github.com/libgit2/git2go/v31/git_system_dynamic.go:11:3: error: #error "Invalid 
libgit2 version; this git2go supports libgit2 between v1.1.0 and v1.1.0"
11 | # error "Invalid libgit2 version; this git2go supports libgit2 between 
v1.1.0 and v1.1.0"
   |   ^

Bug#1009888: [Pkg-rust-maintainers] Bug#1009888: rust-h2, existing version is badly broken, new upstream needs new package

[Peter Michael Green]

On 01/05/2022 14:00, Fabian Grünbichler wrote:

currently progress is blocked on
- itoa/serde_json transition (anybody working actively on that?)


I just uploaded the new itoa to experimental and took a quick look 
through the reverse dependencies.


rust-cssparser - already broken and not in testing.
rust-csv - built/tested fine after patching to use itoa 1, upstream also 
has an unreleased change switching to itoa1 with no code changes.
rust-http - fixed version in debcargo-conf (semver breaking, but all 
rdeps are broken right now anyway)

rust-hyper - already broken and not in testing.
rust-num-format - already broken and not in testing.
rust-serde-json - fixed version in debcargo-conf (not semver breaking)
rust-serde-urlencoded - fixed upstream (semver breaking, but all rdeps 
are broken right now anyway)

rust-time - fixed upstream (not semver breaking)

I'm not seeing any reason not to go ahead with pushing this to unstable, 
anyone have any comments before I go ahead?

Bug#970104: rust-gstreamer has unsatisfiable dependency on non-existent rust-futures-core-preview

[Peter Michael Green]

I took a look at updating rust-gstreamer to 0.17.4 (this is not the 
latest version, but it is the version corresponding to the current rust 
gtk stack in Debian) and hence solving the dependency issues with the 
current package. There were two unsatisfied dependencies: muldiv 1.x and 
pretty-hex 0.2. The former simply needed an update to the latest 
upstream (there are no other reverse dependencies in Debian), but the 
latter looks like it will need packaging from scratch.

Bug#1008847: rust-atk-sys (autopkgtest failure with new atk)

[Peter Michael Green]

Thanks for the bug report, but i'm not convinced your patch is a good 
solution.


First off afaict your patch will break the tests with the old version of 
atk, which

may create some chicken and egg issues with getting it into testing.

There are  ways around that with extra dependenices, breaks etc
but i'm not convinced it's worth it for a constant that doesn't seem to
actually be used by any rust applications (in Debian or otherwise)
and that upstream has shown they are prepared to change without
bumping the soversion (so user code needs to cope with the case
where the value of the constant the user code was built against is
different from the one atk was built against).

Secondly I don't think adding new constants is something we should
be doing in Debian patches.

I'm more inclined towards simply ignoring this failure, the situation 
doesn't

seem any different from the case where an application is compiled against
one version of atk and run against another and as I mentioned no rust code
seems to actually use the constant in question.

I've whipped up a patch to do that, anyone else have any thoughts before
I upload?

Description: allow increase in c value of ATK_STATE_LAST_DEFINED
 The new version of atk increased the value of ATK_STATE_LAST_DEFINED,
 upstream did not bump the soversion, so clearly they do not consider
 this a change that is likely to break downstream applictions.

 Futhermore the only code I can find that actually uses the constant
 in question is some code in rust-atk that translates it to an enum
 the corresponding enum value doesn't seem to actually be used for
 anything.

Author: Peter Michael Green 

--- rust-atk-sys-0.14.0.orig/tests/abi.rs
+++ rust-atk-sys-0.14.0/tests/abi.rs
@@ -134,6 +134,14 @@ fn cross_validate_constants_with_c() {
 continue;
 }
 
+if *rust_name == "(gint) ATK_STATE_LAST_DEFINED" {
+// ATK_STATE_LAST_DEFINED may increase in newer versions of the atk library.
+if c_value.parse::().unwrap_or(0) > rust_value.parse::().unwrap_or(i32::MAX) {
+results.record_passed();
+continue;
+}
+}
+
 if rust_value != c_value {
 results.record_failed();
 eprintln!(

Bug#1008020: precious: build-depends on obsolete package.

[Peter Michael Green]

Package: precious
Version: 0.1.3-2
Severity: serious

The upstream of  the rust which crate dropped the optional dependency on
the rust failure crate. As a result of this the rust-which source 
package no longer

builds a librust-which+failure-dev package.

The librust-which+failure-dev binary package is still present in 
unstable as a

cruft package, but is uninstallable. It is completely gone from testing.

After updating the build-dependency to librust-which+default-dev
(reflecting the fact that your Cargo.toml depends on the which crate
with default features enabled), I was able to build the package succesfully.
I have not tested it though.

Bug#1007977: android-platform-system-core: builds adb which is also built (at a higher version) by android-platform-tools

[Peter Michael Green]

Package: android-platform-system-core
Version: 1:10.0.0+r36-9
Severity: serious

The android-platform-system-core source package builds the adb and fastboot
binary packages which are also built (with a higher version number) by
android-platform-tools, I belive this is what lead to the rejection of 
the amd64
build, it would certainly cause rejections if the package was reuploaded 
now.


Please consider dropping the build of the adb binary package so your package
can be accepted on all architectures and the fix for migrate to testing.

Bug#1000618: ruby-gtk2: crashes with openssl: superclass mismatch for class Socket (TypeError)

[Peter Michael Green]

I noticed this bug while working on a derivative and decided to take a look.
Note though that I am NOT a ruby guy.

Upstream hasn't fixed the underlying issue, but has suggested it can be 
worked around by reordering

requires/imports and has closed the bug.

I took upstreams suggestion and turned it into a patch that could be 
applied to origami-pdf, unfortunately

when I tried to build origami-pdf it failed with.

ArgumentError: wrong number of arguments (given 1, expected 0; required 
keyword: year)

    /origami-pdf-2.0.0/lib/origami/string.rb:383:in `initialize'
    /origami-pdf-2.0.0/lib/origami/string.rb:453:in `new'
    /origami-pdf-2.0.0/lib/origami/string.rb:453:in `now'
    /origami-pdf-2.0.0/lib/origami/signature.rb:517:in `pre_build'
    /origami-pdf-2.0.0/lib/origami/pdf.rb:798:in `block in physicalize'
    /origami-pdf-2.0.0/lib/origami/pdf.rb:808:in `block (2 levels) in 
physicalize'

    /origami-pdf-2.0.0/lib/origami/dictionary.rb:137:in `block in map!'
    /origami-pdf-2.0.0/lib/origami/dictionary.rb:136:in `each_pair'
    /origami-pdf-2.0.0/lib/origami/dictionary.rb:136:in `map!'
    /origami-pdf-2.0.0/lib/origami/pdf.rb:802:in `block in physicalize'
    /origami-pdf-2.0.0/lib/origami/pdf.rb:808:in `block (2 levels) in 
physicalize'

    /origami-pdf-2.0.0/lib/origami/pdf.rb:802:in `map!'
    /origami-pdf-2.0.0/lib/origami/pdf.rb:802:in `block in physicalize'
    /origami-pdf-2.0.0/lib/origami/pdf.rb:817:in `block (2 levels) in 
physicalize'

    /origami-pdf-2.0.0/lib/origami/pdf.rb:816:in `each_value'
    /origami-pdf-2.0.0/lib/origami/pdf.rb:816:in `block in physicalize'
    /origami-pdf-2.0.0/lib/origami/pdf.rb:808:in `block (2 levels) in 
physicalize'

    /origami-pdf-2.0.0/lib/origami/dictionary.rb:137:in `block in map!'
    /origami-pdf-2.0.0/lib/origami/dictionary.rb:136:in `each_pair'
    /origami-pdf-2.0.0/lib/origami/dictionary.rb:136:in `map!'
    /origami-pdf-2.0.0/lib/origami/pdf.rb:802:in `block in physicalize'
    /origami-pdf-2.0.0/lib/origami/pdf.rb:828:in `block in physicalize'
    /origami-pdf-2.0.0/lib/origami/pdf.rb:827:in `each'
    /origami-pdf-2.0.0/lib/origami/pdf.rb:827:in `physicalize'
    /origami-pdf-2.0.0/lib/origami/pdf.rb:722:in `compile'
    /origami-pdf-2.0.0/lib/origami/signature.rb:200:in `sign'
    /origami-pdf-2.0.0/test/test_pdf_sign.rb:43:in `test_sign'

I beleive this is related to changes in ruby 3.0, 
https://rubyreferences.github.io/rubychanges/3.0.html#keyword-arguments-are-now-fully-separated-from-positional-arguments 
I fixed the

code according to the information on that page and did another build.

After installing that, I tested that pdfwalker now crashes with an 
apparently unrelated error,

so the workaround appears to be effective.

/usr/share/origami/gui/treeview.rb:54:in `': 
'Pango::WEIGHT_NORMAL' has been deprecated. Use 
'Pango::Weight::NORMAL' or ':normal'.
/usr/share/origami/gui/treeview.rb:54:in `': 
'Pango::STYLE_NORMAL' has been deprecated. Use 'Pango::Style::NORMAL' 
or ':normal'.
/usr/share/origami/gui/treeview.rb:376:in `reset_appearance': 
'Pango::WEIGHT_BOLD' has been deprecated. Use 'Pango::Weight::BOLD' or 
':bold'.
/usr/share/origami/gui/treeview.rb:385:in `reset_appearance': 
'Pango::STYLE_ITALIC' has been deprecated. Use 'Pango::Style::ITALIC' 
or ':italic'.
/usr/share/origami/gui/treeview.rb:390:in `reset_appearance': 
'Pango::STYLE_OBLIQUE' has been deprecated. Use 
'Pango::Style::OBLIQUE' or ':oblique'.
/usr/lib/ruby/vendor_ruby/glib2/deprecatable.rb:112:in 
`const_missing': uninitialized constant Pango::FontDescription::Weight 
(NameError)

Did you mean?  Pango::Weight
    from /usr/share/origami/gui/treeview.rb:63:in `initialize'
    from /usr/share/origami/gui/treeview.rb:28:in `new'
    from /usr/share/origami/gui/treeview.rb:28:in `create_treeview'
    from /usr/share/origami/gui/walker.rb:94:in `initialize'
    from /usr/share/origami/gui/walker.rb:60:in `new'
    from /usr/share/origami/gui/walker.rb:60:in `start'
    from /usr/bin/pdfwalker:6:in `'


IMO bug 1000618 should be downgraded. Given that there is a known workaround
and given that only one of the three reverse dependencies seems to be 
affected,
I don't think the bug can reasonably be regarded as rendering ruby-gtk2 
unusable.


origami-pdf clearly needs more work though, by someone with more ruby 
knowlege
than me if it is to get back into testing, I've attached a debdiff of 
what I have done

so far anyway.

diff -Nru origami-pdf-2.0.0/debian/changelog origami-pdf-2.0.0/debian/changelog
--- origami-pdf-2.0.0/debian/changelog  2016-10-28 19:21:34.0 +
+++ origami-pdf-2.0.0/debian/changelog  2022-03-05 19:11:29.0 +
@@ -1,3 +1,10 @@
+origami-pdf (2.0.0-1+rpi1) bookworm-staging; urgency=medium
+
+  * Apply workaround for ruby gtk2/openssl conflict.
+  * Fix tests with ruby 3.0.
+
+ -- Peter Michael Green   Sat, 05 Mar 2022 19:11:29 
+
+
 origami-pdf (2.0.0-1) unstable; urgency=medium

Bug#1006537: dask: autopkgtest failure on 32 bit, mismatch in size of data structure.

[Peter Michael Green]

Package: dask
Version: 2022.01.0+dfsg-1
Severity: serious

The autopkgtest for dask is once-again failing on 32-bit architectures,
this is blocking the fix for 
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1005962

from migrating to testing.


>   assert buf.getvalue() == expected
E   assert "
E   Int64Index: 4 entries, 0 to 3
E   Data columns (total 3 columns):
E#   Column  Non-Null Count  Dtype
E   ---  --  --  -
E0   x   4 non-null  int64
E1   y   4 non-null  category...
E
E ...Full output truncated (7 lines hidden), use '-vv' to show

/usr/lib/python3/dist-packages/dask/dataframe/tests/test_dataframe.py:3612: 
AssertionError

I think the most likely explanation is that the memory usage of the
data structure is indeed lower on 32-bit architectures and that this
does not indicate a bug. As such I have prepared a patch that adjusts
the expected result in the test based on the pointer size on the current
architecture.

diff -Nru dask-2022.01.0+dfsg/debian/changelog 
dask-2022.01.0+dfsg/debian/changelog
--- dask-2022.01.0+dfsg/debian/changelog2022-02-21 01:11:53.0 
+
+++ dask-2022.01.0+dfsg/debian/changelog2022-02-27 07:27:00.0 
+
@@ -1,3 +1,11 @@
+dask (2022.01.0+dfsg-1.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Adjust test_dataframe.py for different data structure sizes on 32-bit
+architectures.
+
+ -- Peter Michael Green   Sun, 27 Feb 2022 07:27:00 +
+
 dask (2022.01.0+dfsg-1) unstable; urgency=medium
 
   * New upstream release
diff -Nru dask-2022.01.0+dfsg/debian/patches/series 
dask-2022.01.0+dfsg/debian/patches/series
--- dask-2022.01.0+dfsg/debian/patches/series   2022-02-20 22:18:36.0 
+
+++ dask-2022.01.0+dfsg/debian/patches/series   2022-02-27 07:27:00.0 
+
@@ -9,3 +9,4 @@
 use-youtube-nocookie.patch
 reproducible-config-autofunction.patch
 32bit-comatibility.patch
+test-dataframe-32-bit.patch
diff -Nru dask-2022.01.0+dfsg/debian/patches/test-dataframe-32-bit.patch 
dask-2022.01.0+dfsg/debian/patches/test-dataframe-32-bit.patch
--- dask-2022.01.0+dfsg/debian/patches/test-dataframe-32-bit.patch  
1970-01-01 00:00:00.0 +
+++ dask-2022.01.0+dfsg/debian/patches/test-dataframe-32-bit.patch  
2022-02-27 07:27:00.0 +
@@ -0,0 +1,25 @@
+Description:  Adjust test_dataframe.py for different data structure sizes on 
32-bit architectures.
+Author: Peter Michael Green 
+
+Index: dask-2022.01.0+dfsg/dask/dataframe/tests/test_dataframe.py
+===
+--- dask-2022.01.0+dfsg.orig/dask/dataframe/tests/test_dataframe.py
 dask-2022.01.0+dfsg/dask/dataframe/tests/test_dataframe.py
+@@ -3597,6 +3597,8 @@ def test_categorize_info():
+ # Verbose=False
+ buf = StringIO()
+ ddf.info(buf=buf, verbose=True)
++pointersize = np.array([0],dtype=np.uintp).itemsize
++bytecount = 128 + pointersize * 46
+ expected = (
+ "\n"
+ "Int64Index: 4 entries, 0 to 3\n"
+@@ -3607,7 +3609,7 @@ def test_categorize_info():
+ " 1   y   4 non-null  category\n"
+ " 2   z   4 non-null  object\n"
+ "dtypes: category(1), object(1), int64(1)\n"
+-"memory usage: 496.0 bytes\n"
++"memory usage: "+str(bytecount)+".0 bytes\n"
+ )
+ assert buf.getvalue() == expected
+ 

Bug#1006535: sphinx-remove-toctrees - source-only upload required.

[Peter Michael Green]

Package: sphinx-remove-toctrees
Version: 0.0.3-1
Severity: serious

The release team have decreed that only binaries build on the buildd network
can migrate to testing, please make a source-only upload so your package can
migrate.

Bug#1006141: supertuxkart: FTBFS on armhf: Error: selected FPU does not support instruction -- `vldmia.64 r10,{d0-d7}'

[Peter Michael Green]

Tags 1006141 +patch
thanks

This was fixed in ubuntu a few months ago by adding ".fpu vfp" to the 
assembler file in question.
(within the block of code that is only used on systems with the hard 
float ABI).


https://patches.ubuntu.com/s/supertuxkart/supertuxkart_1.3+dfsg1-2ubuntu1.patch

I have just built the same fix successfully in raspbian bookworm-staging 
and uploaded it
to raspbian. I haven't tested it in Debian myself but I'd be extremely 
surprised if it doesn't work.

Bug#1002402: python-sparse: FTBFS: dh_auto_test: error: pybuild --test --test-pytest -i python{version} -p "3.10 3.9" returned exit code 13

[Peter Michael Green]

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


I'm no expert on this particular package, but this looks to me like it 
is not actually caused by a problem in python-sparse, but is instead a 
symptom of python3-numba not being built against python 3.10 due to

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

Bug#1005050: rust-csv - autopkgtest failure

[Peter Michael Green]

Package: rust-csv
Version: 1.1.5-2
Severity: serious

rust-csv's autopkgtest is failing, which is blocking it's migration to 
testing.



--- cookbook_read_basic stdout 
thread 'cookbook_read_basic' panicked at 'command spawns successfully: Os { code: 2, 
kind: NotFound, message: "No such file or directory" }', tests/tests.rs:412:33
stack backtrace:
0: rust_begin_unwind
  at /usr/src/rustc-1.56.0/library/std/src/panicking.rs:517:5
1: core::panicking::panic_fmt
  at /usr/src/rustc-1.56.0/library/core/src/panicking.rs:101:14
2: core::result::unwrap_failed
  at /usr/src/rustc-1.56.0/library/core/src/result.rs:1617:5
3: core::result::Result::expect
  at /usr/src/rustc-1.56.0/library/core/src/result.rs:1259:23
4: tests::cmd_output_with
  at ./tests/tests.rs:412:21
5: tests::cookbook_read_basic
  at ./tests/tests.rs:27:15
6: tests::cookbook_read_basic::{{closure}}
  at ./tests/tests.rs:25:1
7: core::ops::function::FnOnce::call_once
  at /usr/src/rustc-1.56.0/library/core/src/ops/function.rs:227:5
8: core::ops::function::FnOnce::call_once
  at /usr/src/rustc-1.56.0/library/core/src/ops/function.rs:227:5
note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose 
backtrace.
Doing some experiments running the tests manually, it appears the 
culprit is the "--all-targets" option
passed to cargo test by the autopkgtests. This seems to stop cargo from 
building the examples in a

runnable form.

I'm not sure what the best way forward here is, one could override 
debian/tests/control, but experiance
shows that is a maintinance burden, because debian/tests/control 
hardcodes the crate version.


The other option would be to just disable the tests in question. Not 
ideal but probablly not a disaster

either.

Does anyone have any better ideas?

Bug#1003829: python-igraph: build-depends unsatisfiable on s390x

[Peter Michael Green]

Source: python-igraph
Version: 0.9.8-1
Severity: serious
Justification: rc policy - packages must be buildable within the same 
release


python-igraph build-depends on libigraph-dev which was recently removed on
s390x. So the package's build-depends are no longer satisfiable on that
architecture.

=
[Date: Mon, 10 Jan 2022 14:40:32 -] [ftpmaster: Scott Kitterman]
Removed the following packages from unstable:

libigraph-dev | 0.8.5+ds1-1 | s390x
libigraph1 | 0.8.5+ds1-1 | s390x
Closed bugs: 1003445

--- Reason ---
ROM; Fails to build on s390x since using Debian packaged plfit
--
=


Looking at the build logs it seems that while python-igraph depends on 
the libigraph-dev
package, it doesn't seem to actually use it instead using it's own 
bundled copy of igraph,

so maybe the build-dependency can simply be dropped.

Bug#1002164: rust-alacritty-terminal: FTBFS: build-dependency not installable: librust-signal-hook-registry-1.2+default-dev

[Peter Michael Green]

reopen 1002164
thanks

On 21/12/2021 20:27, plugwash wrote:


The more immediate fix, which I have just uploaded as rust-signal-hook
0.1.13-3 is to do what upstream did in signal-hook 0.1.17 and use a caret
dependency instead of a tilde dependency on signal-hook-registry.

Signal-hook 0.3 has now been uploaded, but signal-hook-mio is still in NEW,
so alacritty-terminal's build-depedencies are once-again broken.

Bug#1002065: scipy build-depenencies unsatisfiable in testing/unstable

[Peter Michael Green]

Package: scipy
Version: 1.7.1-2
Severity: serious

scipy build-depends on python3-pybind11 (<< 2.8) but testing and unstable
have version 2.8.1-3

Bug#1001548: php-oscarotero-gettext, build-depends on package that is no longer in testing

[Peter Michael Green]

Package: php-oscarotero-gettext
Version: 4.8.2-6
Severity: serious
Justification: rc policy - "Packages must be buildable within the same release"

php-oscarotero-gettext build-depends on the php-illuminate-database binary 
package,
which is built by the php-laravel-framework source package which was recently 
removed
from testing, presumablly due to it's dependency on an old version of 
php-symphony.

I see two possible approaches to fixing this

1. Eliminate the build-dependency, given the content of the package I would 
assume
   it is most likely only used for testing
2. Get php-laravel-framework fixed and back into testing.

Bug#1001547: azure-cli: build-depends on removed package.

[Peter Michael Green]

Package: azure-cli
Version: 2.31.0-1
Severity: serious

azure-cli build-depends on pylint3 which is no longer built by the pylint
source package, it is still present in unstable as a cruft package, but is
completely gone from testing.

Since the package was previously an empty (other than /usr/share/doc
files) fixing this should be a simple matter of updating your 
build-depedency.

(I have not done a test build though)

Bug#1001546: crystal, build-depends on package that is no longer in testing

[Peter Michael Green]

Package: crystal
Version: 1.2.1+dfsg-6
Severity: serious
Justification: rc policy - "Packages must be buildable within the same 
release"


crystal build-depends on libllvm9 or libllvm8, neither of these packages are
available in testing anymore. Please investigate migration to a newer 
version

of llvm.

(Also it's slightly strange to be build-depending on binary libraries 
rather than

dev packages, and also strange to have the build-dependencies without
corrsponding runtime dependencies)

Bug#1001545: pyopencl, build-depends on package that is no longer in testing

[Peter Michael Green]

Package: pyopencl
Tags: bookworm
Severity: serious
Justification: rc policy - "Packages must be buildable within the same 
release"


pyopencl build-depends on pocl-opencl-icd which is no longer in testing.

Bug#996375: chromium build-depends on removed package.

[Peter Michael Green]

Package: chromium
Version: 93.0.4577.82-1
Severity: serious

chromium build-depends on python-jinja2 which is no longer built by the 
jinja2 source package.
It is still present in unstable as a cruft package but is completely 
gone from testing.

Bug#977489: rust-rand: autopkgtest regression in testing: error: could not compile `packed_simd`.

[Peter Michael Green]

Looking at 
https://ci.debian.net/data/autopkgtest/testing/amd64/r/rust-rand/9312542/log.gz


It looks like the packed_simd feature test passes with unstable's 
version of rust-packed-simd

but the all features test is still failing with


error[E0433]: failed to resolve: use of undeclared crate or module `__m64`
--> src/distributions/integer.rs:161:13
 |
161 | simd_impl!((__m64, u8x8), (__m128i, u8x16), (__m256i, u8x32),);
 | ^ use of undeclared crate or module `__m64`
I don't think it's worth opening a separate bug, so I'll close this one 
with an upload that fixes

the __m64 issue.

Bug#939594: vmtk build-depends on cruft package

[Peter Michael Green]

package: vmtk
severity: serious
version: 1.3+dfsg-2.3

vmtk build-depends on libvtk6-java which is no longer built by the vtk6 
source package.

Bug#939399: libgeotiff FTBFS in bullseye (possiblly armhf specific), test discrepancies.

[Peter Michael Green]

package: libgeotiff\
version: 1.5.1-1
severity: serious
tags: bullseye

Hi, libgeotiff just failed to build in raspbian bullseye with the 
following message.




Running ../test/testlistgeo using ../bin/listgeo:

proj_create: unrecognized format / unknown name
proj_create: unrecognized format / unknown name
proj_create: unrecognized format / unknown name
proj_create: unrecognized format / unknown name
proj_create: unrecognized format / unknown name
proj_create: unrecognized format / unknown name
proj_create: unrecognized format / unknown name
proj_create: unrecognized format / unknown name
proj_create: unrecognized format / unknown name
proj_create: unrecognized format / unknown name
diff testlistgeo_out with testlistgeo_out.dist
--- testlistgeo_out 2019-09-04 06:58:26.979704475 +
+++ ../test/testlistgeo_out.dist2019-09-04 06:57:50.0 +
@@ -1697,11 +1697,11 @@
 Keyed_Information:
GTModelTypeGeoKey (Short,1): ModelTypeProjected
GTRasterTypeGeoKey (Short,1): RasterPixelIsArea
-  ProjectedCSTypeGeoKey (Short,1): Code-3035 (ETRS89-extended / LAEA 
Europe)
+  ProjectedCSTypeGeoKey (Short,1): Code-3035 (ETRS89 / LAEA Europe)
End_Of_Keys.
 End_Of_Geotiff.
  
-PCS = 3035 (ETRS89-extended / LAEA Europe)

+PCS = 3035 (ETRS89 / LAEA Europe)
  Projection = 19986 (Europe Equal Area 2001)
  Projection Method: CT_LambertAzimEqualArea
 ProjCenterLatGeoKey: 52.00 ( 52d 0' 0.00"N)

PROBLEMS HAVE OCCURRED
test file testlistgeo_out saved
It also failed in the same way on the Debian reproducible builds site 
for bullseye armhf. The reproducible builds site has not yet tested it 
on other architectures in bullseye. It seems to be fine in unstable.

Bug#935714: python-os-net-config (build-) depends on cruft package.

[Peter Michael Green]

Package: python-os-net-config
Version: 0.1.0-1
Severity: serious
Tags: bullseye, sid

python-os-net-config (build-)depends on the python-oslo.config binary 
package which is no longer built by the corresponding source package.


I see no reverse-depends, should this package simply be removed?

Bug#933821: python-tuskarclient (build-)depends on cruft package.

[Peter Michael Green]

Package: python-tuskarclient
Severity: serious
Version: 0.1.18-1
Tags: bullseye, sid

python-tuskarclient depends on the python-cliff, python-keystoneclient, 
python-openstackclient and python-stevedore binary packages which are no 
longer built by the corresponding source packages.


If this is going to stay around it looks like it needs to migrate to 
python 3.

Bug#933757: Firefox-esr FTBFS "failed to open: /sbuild-nonexistent/.cargo/.package-cache"

[Peter Michael Green]

Package: firefox-esr
Version: 60.8.0esr-1
Severity: serious
x-debbugs-cc: pkg-rust-maintain...@alioth-lists.debian.net

While trying to update firefox-esr in raspbian bullseye I ran into a 
"failed to open: /sbuild-nonexistent/.cargo/.package-cache" error. The 
failure also shows up on the reproducible builds site for i386 and arm64 
so it's not raspbian specific. I suspect it is only reproducible in 
builds with a nonexistent homedir (as is the standard sbuild configuration).


I would guess this was triggered by the recent upload of a new version 
of cargo.



error: failed to acquire package cache lock

Caused by:
   failed to open: /nonexistent/first-build/.cargo/.package-cache

Caused by:
   Permission denied (os error 13)
/usr/bin/g++ -o buddhcal.o -c 
-I/build/1st/firefox-esr-60.8.0esr/build-browser/dist/system_wrappers -include 
/build/1st/firefox-esr-60.8.0esr/config/gcc_hidden.h -DNDEBUG=1 -DTRIMMED=1 
-DU_I18N_IMPLEMENTATION -DUCONFIG_NO_TRANSLITERATION 
-DUCONFIG_NO_REGULAR_EXPRESSIONS -DUCONFIG_NO_LEGACY_CONVERSION 
-DU_USING_ICU_NAMESPACE=0 -DU_NO_DEFAULT_INCLUDE_UTF_HEADERS=1 
-DU_CHARSET_IS_UTF8 -DU_HAVE_NL_LANGINFO_CODESET=0 
-I/build/1st/firefox-esr-60.8.0esr/config/external/icu/i18n 
-I/build/1st/firefox-esr-60.8.0esr/build-browser/config/external/icu/i18n 
-I/build/1st/firefox-esr-60.8.0esr/intl/icu/source/common 
-I/build/1st/firefox-esr-60.8.0esr/build-browser/dist/include 
-I/usr/include/nspr -I/usr/include/nss -fPIC -DMOZILLA_CLIENT -include 
/build/1st/firefox-esr-60.8.0esr/build-browser/mozilla-config.h -Wdate-time 
-D_FORTIFY_SOURCE=2 -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=2 -Wall -Wempty-body 
-Wignored-qualifiers -Woverloaded-virtual -Wpointer-arith -Wsign-compare 
-Wtype-limits -Wunreachable-code -Wwrite-strings -Wno-invalid-offsetof 
-Wc++1z-compat -Wduplicated-cond -Wimplicit-fallthrough 
-Wno-error=maybe-uninitialized -Wno-error=deprecated-declarations 
-Wno-error=array-bounds -Wno-error=free-nonheap-object -Wformat 
-Wformat-overflow=2 -fno-sized-deallocation -fstack-protector-strong -Wformat 
-Werror=format-security -fno-schedule-insns2 -fno-lifetime-dse 
-fno-delete-null-pointer-checks -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=2 
-fno-exceptions -fno-strict-aliasing -fno-rtti -ffunction-sections 
-fdata-sections -fno-exceptions -fno-math-errno -pthread -pipe -g 
-freorder-blocks -O2 -fomit-frame-pointer -frtti  -MD -MP -MF 
.deps/buddhcal.o.pp   
/build/1st/firefox-esr-60.8.0esr/intl/icu/source/i18n/buddhcal.cpp
make[6]: *** [/build/1st/firefox-esr-60.8.0esr/config/rules.mk:979: 
force-cargo-library-build] Error 101
make[6]: Leaving directory 
'/build/1st/firefox-esr-60.8.0esr/build-browser/toolkit/library/rust'
make[5]: *** [/build/1st/firefox-esr-60.8.0esr/config/recurse.mk:73: 
toolkit/library/rust/target] Error 2
make[5]: *** Waiting for unfinished jobs

Bug#933751: mini-buildd (build-)depends on cruft package.

[Peter Michael Green]

Package: mini-buildd
Version: 1.0.41
Severity: serious

python-mini-buildd depends on and the mini-buildd source package 
build-depends on the python-django-registration binary package which is 
no longer built by the python-django-registration source package.


I notice this already seems to be fixed in experimental, are there any 
blockers for uploading the experimental version to unstable?

Bug#933509: oz depends on cruft package.

[Peter Michael Green]

Package: oz
Version: 0.16.0-2
Severity: serious
Tags: bullseye, sid

oz depends on the python-monotonic binary package which is no longer 
built by the python-monotonic source package.

Bug#933364: lua-geoip depends on cruft package.

[Peter Michael Green]

Package: lua-geoip
Version: 0.1.2+git20160613-3
Severity: serious
Tags: bullseye, sid

lua-geoip depends on geoip-database-extra which is no longer built by 
the geoip-database source package.

Bug#933318: python-os-cloud-config (build-)depends on cruft packages.

[Peter Michael Green]

Package: python-os-cloud-config
Severity: serious
Tags: bullseye, sid

python-os-cloud-config depends on a number of binary packages that are 
no longer built by their corresponding source packages, including


python-glanceclient
python-ironicclient
python-keystoneclient
python-neutronclient
python-novaclient
python-oslo.config
python-oslo.i18n
python-pbr

Presumablly this package needs to migrate to python3 if it is going to 
stay around at all.

Bug#933106: d-shlibs: binary not built on buildd.

[Peter Michael Green]

Package: d-shlibs
Version: 0.85
Severity: serious

The release team have decreed that binaries not built on buildds can no 
longer migrate to testing. Please make a source only upload so the fix 
for 932632 can migrate to testing.

Bug#929448: acorn build-depends on cruft package node-unicode-11.0.0

[Peter Michael Green]

package: node-regexpu-core
version: 4.4.0+ds-1
severity: serious

node-regexpu-core build-depends on node-unicode-11.0.0 which is no 
longer built by source package node-unicode-data. It appears to have 
been replaced by node-unicode-12.0.0

Bug#929447: acorn build-depends on cruft package node-unicode-11.0.0

[Peter Michael Green]

package: node-regenerate-unicode-properties
version: 7.0.0+ds-1
severity: serious

node-regenerate-unicode-properties build-depends on node-unicode-11.0.0 
which is no longer built by source package node-unicode-data. It appears 
to have been replaced by node-unicode-12.0.0

Bug#929426: acorn build-depends on cruft package node-unicode-11.0.0

[Peter Michael Green]

package: acorn
version: 5.5.3+ds3-2
severity: serious

acorn build-depends on node-unicode-11.0.0 which is no longer built by 
source package node-unicode-data. It appears to have been replaced by 
node-unicode-12.0.0

Bug#835427: s/XML_NO_ERROR/XML_SUCCESS/

[Peter Michael Green]

tags 835427 +patch
thanks

Older versions of tinyxml defined both XML_NO_ERROR and XML_SUCCESS to 0. Never
versions define only XML_SUCCESS.


Attatched is a patch that replaces XML_NO_ERROR with XML_SUCCESS


diff -Nru gazebo-7.3.0+dfsg/debian/changelog gazebo-7.3.0+dfsg/debian/changelog
--- gazebo-7.3.0+dfsg/debian/changelog  2016-07-21 15:33:10.0 +
+++ gazebo-7.3.0+dfsg/debian/changelog  2016-08-27 16:02:33.0 +
@@ -1,3 +1,9 @@
+gazebo (7.3.0+dfsg-2+rpi1) stretch-staging; urgency=medium
+
+  * Change XML_NO_ERROR to XML_SUCCESS (Closes: 835427)
+
+ -- Peter Michael Green <plugw...@raspbian.org>  Sat, 27 Aug 2016 16:02:33 
+
+
 gazebo (7.3.0+dfsg-2) unstable; urgency=medium
 
* Patch to fix linking with gcc6 (Closes: #831176)
diff -Nru gazebo-7.3.0+dfsg/debian/patches/0010-xml-no-error.patch 
gazebo-7.3.0+dfsg/debian/patches/0010-xml-no-error.patch
--- gazebo-7.3.0+dfsg/debian/patches/0010-xml-no-error.patch1970-01-01 
00:00:00.0 +
+++ gazebo-7.3.0+dfsg/debian/patches/0010-xml-no-error.patch2016-08-27 
16:02:33.0 +
@@ -0,0 +1,24 @@
+Description:  Change XML_NO_ERROR to XML_SUCCESS (Closes: 835427)
+Author: Peter Michael Green <plugw...@raspbian.org>
+Bug-Debian: https://bugs.debian.org/835427
+
+--- gazebo-7.3.0+dfsg.orig/gazebo/util/LogPlay.cc
 gazebo-7.3.0+dfsg/gazebo/util/LogPlay.cc
+@@ -72,7 +72,7 @@ void LogPlay::Open(const std::string &_l
+ 
+   // Flag use to indicate if a parser failure has occurred
+   bool xmlParserFail = this->dataPtr->xmlDoc.LoadFile(_logFile.c_str()) !=
+-tinyxml2::XML_NO_ERROR;
++tinyxml2::XML_SUCCESS;
+ 
+   // Parse the log file
+   if (xmlParserFail)
+@@ -105,7 +105,7 @@ void LogPlay::Open(const std::string &_l
+ 
+   // Retry loading the log file.
+   xmlParserFail = this->dataPtr->xmlDoc.LoadFile(_logFile.c_str()) !=
+-tinyxml2::XML_NO_ERROR;
++tinyxml2::XML_SUCCESS;
+ }
+   }
+ }
diff -Nru gazebo-7.3.0+dfsg/debian/patches/series 
gazebo-7.3.0+dfsg/debian/patches/series
--- gazebo-7.3.0+dfsg/debian/patches/series 2016-07-21 15:35:01.0 
+
+++ gazebo-7.3.0+dfsg/debian/patches/series 2016-08-27 16:02:33.0 
+
@@ -2,3 +2,4 @@
 0005-fix-problems-on-manpage.patch
 0008-arial-font-removed-in-dfsg.patch
 0009-fix-gcc6-linking.patch
+0010-xml-no-error.patch

Bug#828089: consul fails to build on arm64 due to missing poll

[Peter Michael Green]

Package: golang-1.6
Severity: serious

consul failed to build on arm64 with

src/golang.org/x/sys/unix/zsyscall_linux_arm64.go:57: undefined: SYS_POLL


Googling this error finds https://github.com/golang/go/issues/16052 
which links to a commit fixing the issue. 
https://github.com/golang/sys/commit/5a8c7f28c1853e998847117cf1f3fe96ce88a59f 
can we get this fix in the Debian golang-1.6 package so that consul can 
be built successfully and migrate to testing. There is already at least 
one package in testing that build-depends on the new consul.

Bug#751005: new hg doesn't seem to be enough to build clisp for arm*

[Peter Michael Green]

Note that the experimental package is failing with a different error:

gcc -I/«BUILDDIR»/clisp-2.49+hg.2015.05.31/src 
-I/«BUILDDIR»/clisp-2.49+hg.2015.05.31/debian/build/gllib 
-I/«BUILDDIR»/clisp-2.49+hg.2015.05.31/src/gllib -falign-functions=4 -W 
-Wswitch -Wcomment -Wpointer-arith -Wreturn-type -Wmissing-declarations 
-Wimplicit -O2 -DENABLE_UNICODE -DDYNAMIC_FFI -DDYNAMIC_MODULES -c lisparit.c
In file included from /«BUILDDIR»/clisp-2.49+hg.2015.05.31/src/lisparit.d:28:0:
/«BUILDDIR»/clisp-2.49+hg.2015.05.31/src/arilev1.d:270:26: fatal error: 
ariarm.c: No such file or directory
compilation terminated.
Makefile:1299: recipe for target 'lisparit.o' failed
make[1]: *** [lisparit.o] Error 1

Bug#651626: pearpc: FTBFS(kfreebsd-amd64):'MAP_32BIT' was not declared in this scope

[Peter Michael Green]

Severity 651626 important
thanks

>Your package failed to build on the kfreebsd-amd64 buildds:
kfreebsd-amd64 is no longer a release architecture, downgrading.

Bug#794498: sorry closed wrong bug

[Peter Michael Green]

reopen 794498
thanks

Bug#665017: build-depends are now installable but package still ftbfs.

[Peter Michael Green]

Testing now shows the build-depends are installable but trying to 
actually build the package gives


make[3]: /usr/bin/ldc: Command not found
Makefile:109: recipe for target 
'stamps/build-d-file-tango-core-tools-LinuxStackTrace.d' failed
make[3]: *** [stamps/build-d-file-tango-core-tools-LinuxStackTrace.d] 
Error 127

Makefile:112: recipe for target 'stamps/build-dir-tango-core-tools' failed
make[2]: *** [stamps/build-dir-tango-core-tools] Error 2
Makefile:121: recipe for target 'stamps/build-lib-base' failed
make[1]: *** [stamps/build-lib-base] Error 2
make[1]: Leaving directory '/libtango-0.99.9.dfsg'
debian/rules:13: recipe for target 'build-stamp-ldc' failed
make: *** [build-stamp-ldc] Error 2
dpkg-buildpackage: error: debian/rules build gave error exit status 2

Doing a search and replace of ldc with ldc2 in the Makefile the build 
gets further but fails with


c tango/util/digest/Ripemd128.d -ofobjs/user/tango-util-digest-Ripemd128.o
make[3]: c: Command not found
Makefile:109: recipe for target 
'stamps/build-d-file-tango-util-digest-Ripemd128.d' failed
make[3]: [stamps/build-d-file-tango-util-digest-Ripemd128.d] Error 127 
(ignored)

ar rcu objs/user/libtango-user-ldc.a objs/user/*.o
ar: `u' modifier ignored since `D' is the default (see `U')
ar: objs/user/*.o: No such file or directory
Makefile:121: recipe for target 'stamps/build-lib-user' failed
make[1]: *** [stamps/build-lib-user] Error 1
make[1]: Leaving directory '/libtango-0.99.9.dfsg'
debian/rules:13: recipe for target 'build-stamp-ldc' failed
make: *** [build-stamp-ldc] Error 2
dpkg-buildpackage: error: debian/rules build gave error exit status 2

Bug#797416: cqrlog FTBFS in unstable lazbuild hangs

[Peter Michael Green]

package: cqrlog
version: 1.9.0-3
severity: serious
tags: patch sid

As you are probablly already aware lazbuild is currently broken on arm 
in sid (see bug 793991) and it looks like it may be some time before 
it's fixed. In the meantime  there are some cqrlog rc bugs that need 
fixing in testing.


So as a short to medium term fix for cqrlog here is a patch to build it 
without using lazbuild. Colin, can you test that the results of building 
with this patch work and if-so upload it to sid.



diff -Nru cqrlog-1.9.0/debian/changelog cqrlog-1.9.0/debian/changelog
--- cqrlog-1.9.0/debian/changelog   2015-08-24 15:38:07.0 +
+++ cqrlog-1.9.0/debian/changelog   2015-08-30 12:37:53.0 +
@@ -1,3 +1,10 @@
+cqrlog (1.9.0-3.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Avoid using lazbuild for now as it's broken on arm* in sid.
+
+ -- Peter Michael Green plugw...@debian.org  Sun, 30 Aug 2015 12:37:31 +
+
 cqrlog (1.9.0-3) unstable; urgency=medium
 
   * Fix build dependency on fp-units-gtk - fp-units-gtk2
diff -Nru cqrlog-1.9.0/debian/patches/makefile-no-lazbuild 
cqrlog-1.9.0/debian/patches/makefile-no-lazbuild
--- cqrlog-1.9.0/debian/patches/makefile-no-lazbuild1970-01-01 
00:00:00.0 +
+++ cqrlog-1.9.0/debian/patches/makefile-no-lazbuild2015-08-30 
13:56:31.0 +
@@ -0,0 +1,20 @@
+Description:  Avoid using lazbuild for now as it's broken on arm* in sid.
+Author: Peter Michael Green plugw...@debian.org
+
+Index: cqrlog-1.9.0/Makefile
+===
+--- cqrlog-1.9.0.orig/Makefile
 cqrlog-1.9.0/Makefile
+@@ -4,9 +4,11 @@ datadir  = $(DESTDIR)/usr/share/cqrlog
+ bindir   = $(DESTDIR)/usr/bin
+ sharedir = $(DESTDIR)/usr/share
+ tmpdir   = /tmp
++fpcarch := $(shell fpc -iTP)-$(shell fpc -iTO)
+ 
+ cqrlog: src/cqrlog.lpi
+-  $(CC) --ws=gtk2 --pcp=$(tmpdir)/.lazarus src/cqrlog.lpi
++  #$(CC) --ws=gtk2 --pcp=$(tmpdir)/.lazarus src/cqrlog.lpi
++  cd src  fpc -B -MObjFPC -Sghi -O3 -g -gl -l -vn- -vh- -vewilbq 
-Fl/usr/lib/lazarus/default/lcl -Fl/opt/gnome/lib -Fu$(CURDIR)/src/lnet/lib 
-Fu$(CURDIR)/src/mysql 
-Fu/usr/lib/lazarus/default/components/turbopower_ipro/units/$(fpcarch)/gtk2 
-Fu/usr/lib/lazarus/default/components/tachart/lib/$(fpcarch)/gtk2 
-Fu/usr/lib/lazarus/default/components/sqldb/lib/$(fpcarch)/gtk2 
-Fu/usr/lib/lazarus/default/components/rtticontrols/lib/$(fpcarch)/gtk2 
-Fu/usr/lib/lazarus/default/components/memds/lib/$(fpcarch)/gtk2 
-Fu/usr/lib/lazarus/default/components/tdbf/lib/$(fpcarch)/gtk2 
-Fu/usr/lib/lazarus/default/components/printers/lib/$(fpcarch)/gtk2 
-Fu/usr/lib/lazarus/default/components/ideintf/units/$(fpcarch)/gtk2 
-Fu/usr/lib/lazarus/default/components/synedit/units/$(fpcarch)/gtk2 
-Fu/usr/lib/lazarus/default/components/sdf/lib/$(fpcarch)/gtk2 
-Fu/usr/lib/lazarus/default/components/lazcontrols/lib/$(fpcarch)/gtk2 
-Fu/usr/lib/lazarus/default/components/cairocanvas/lib/$(fpcarch)/gtk2 
-Fu/usr/lib/lazarus/default/lcl/units/$(fpcarch)/gtk2 
-Fu/usr/lib/lazarus/default/lcl/units/$(fpcarch) 
-Fu/usr/lib/lazarus/default/components/codetools/units/$(fpcarch) 
-Fu/usr/lib/lazarus/default/components/lazutils/lib/$(fpcarch) 
-Fu/usr/lib/lazarus/default/packager/units/$(fpcarch) -Fu$(CURDIR)/src/ -dLCL 
-dLCLgtk2 -dNO_CONTEST cqrlog.lpr
+   $(ST) src/cqrlog
+   gzip tools/cqrlog.1 -c  tools/cqrlog.1.gz
+ 
diff -Nru cqrlog-1.9.0/debian/patches/series cqrlog-1.9.0/debian/patches/series
--- cqrlog-1.9.0/debian/patches/series  2015-07-28 19:18:07.0 +
+++ cqrlog-1.9.0/debian/patches/series  2015-08-30 12:39:32.0 +
@@ -1,3 +1,4 @@
 makefile-no-homedir-use
 desktop-keywords
 apparmor.patch
+makefile-no-lazbuild

Bug#753820: atril build-depends on obsolete transiionall package

[Peter Michael Green]

Package: atril
Severity: serious
Tags: patch

atril depends on the obsolete transitional package libtiff4-dev which 
has been removed in the latest version of the tiff source package.


The fix is trivial and obvious, change the build-dependency to libtiff-dev


--
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org