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

[Peter Green]

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

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

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

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

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

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

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

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

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

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

I uploaded these changes as 0.5.6-2.

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

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

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

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

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

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

[peter green]

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


The relavent change is.


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


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

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

[Peter Green]

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


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

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

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

Finally I got test failures.


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

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



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

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

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

--
Ran 796 tests in 80.565s

FAILED (failures=4, expected failures=1)


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

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

[Peter Green]

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



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

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

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

[Peter Green]

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

rust-synstructure was recently updated to version 0.13.1

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


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

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

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


I'm also going to report this upstream.

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

[Peter Green]

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

rust-synstructure was recently updated to version 0.13.1

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


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

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

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

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

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

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

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

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

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

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

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


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

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

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

[Peter Green]

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

rust-synstructure was recently updated to version 0.13.1

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



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

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

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

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

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

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


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

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

[Peter Green]

Looking at the changelog, I see


Build with --as-needed.


I suspect this is responsible for the build failure on armel

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

[Peter Green]

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

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

> My understanding of the issue.

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

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

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

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

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

[Peter Green]

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

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

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

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

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

[Peter Green]

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

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

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

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

* kdeedu

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

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

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

* science-chemistry

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

* debichem-visualisation

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

[Peter Green]

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


My understanding of the issue.

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

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

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

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

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

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

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

[Peter Green]

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

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

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

[Peter Green]

Tags 1068159 +patch
Thanks

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

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

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

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

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

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

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

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

[peter green]

block 1036884 by 1066134
tags 1066134 +patch
thanks

Hi.

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

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

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

[Peter Green]

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

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


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





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





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

4 out of 21 tests failed (0.03s)



I strongly suspect this is related to the time64 transition.

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

[Peter Green]

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

Changelog for version 1.5.18-1ubuntu6 says

"Fix installation of cupshelpers module with Python 3.12."

Changelog for version 1.5.18-1ubuntu7 says

"Drop build dependency on python3-distutils."

Diffs are available at

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

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

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

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

[Peter Green]

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

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

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

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

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

[Peter Green]

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

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

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

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

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

[Peter Green]

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

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

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

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

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

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

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

[Peter Green]

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

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

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

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

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

[Peter Green]

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

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

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

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

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

[Peter Green]

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

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

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

[Peter Green]

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

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

Ubuntu appear to have already fixed this.

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

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

[Peter Green]

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

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

Ubuntu has applied a fix for this.

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

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

[Peter Green]

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

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

Ubuntu has applied a fix for this.

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

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

[Peter Green]

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

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

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

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

[Peter Green]

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

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

Ubuntu has applied a fix for this.

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

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

[Peter Green]

tags 1065980 +patch
thanks

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

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

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

[Peter Green]

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

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

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

[Peter Green]

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

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

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

[Peter Green]

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

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

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

[Peter Green]

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

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

Ubuntu seem to have already fixed this.

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

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

[Peter Green]

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

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

Ubuntu seem to have already fixed this.

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

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

[Peter Green]

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

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

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

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

[Peter Green]

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

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

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

[Peter Green]

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

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

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

[Peter Green]

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

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

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

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

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

[Peter Green]

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

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

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


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


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

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

[Peter Green]

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

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

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

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

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

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

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

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

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

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

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

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

[Peter Green]

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

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

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

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

[Peter Green]

Package: atril
Version: 1.26.2-2
Severity: serious

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

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

[Peter Green]

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

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

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


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

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

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

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

Bug#1066794: consider retrying git binnmus.

[Peter Green]

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

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

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

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

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

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

[Peter Green]

On 17/03/2024 13:01, Jérémy Lal wrote:


The last missing piece seems to be version >= 3 of
https://tracker.debian.org/pkg/rust-pem

I've uploaded this to experimental, please tell me when you are ready for it
to be uploaded to unstable.

Bug#1066972: [Pkg-rust-maintainers] Bug#1066972: rust-python-pkginfo: FTBFS on mips64el: missing librust-rfc2047-decoder-0.2+default-dev

[Peter Green]

severity 1066972 important
thanks


Indeed, there is no librust-rfc2047-decoder-0.2+default-dev package.


librust-rfc2047-decoder-0.2+default-dev is a virtual package provided
by librust-rfc2047-decoder-dev which is built from the
rust-rfc2047-decoder source package.

Following the dependency chain, it looks like the root cause
(or at least one of the root causes) is that the testsuite for
rust-stacker is segfaulting on mips64el.

Bug#1066866: railway-gtk: FTBFS on i386 "type annotations needed"

[Peter Green]

Package: railway-gtk
Version: 2.4.0-1
Severity: serious

railway-gtk FTBFS on i386 (and will probablly FTBFS on other
32-bit architectures but builds on those architectures are
currently blocked by the time64 transition).


error[E0283]: type annotations needed for `std::option::Option`
   --> src/backend/journeys_result.rs:207:17
|
207 | let index = list
| ^
...
215 | if position <= index && index < position + n_items {
| -- type must be known at this point
|
= note: multiple `impl`s satisfying `u32: PartialOrd<_>` found in the 
following crates: `core`, `glib`:
- impl PartialOrd for u32;
- impl PartialOrd for u32;
help: consider giving `index` an explicit type, where the placeholders `_` are 
specified
|
207 | let index: std::option::Option = list
|  


Looking at the code, I'm pretty confident that the intended type was
Option. The attached debdiff adds the annotation. I have tested
that railway-gtk builds succesfully with this patch on both i386
and amd64.diff -Nru railway-gtk-2.4.0/debian/changelog railway-gtk-2.4.0/debian/changelog
--- railway-gtk-2.4.0/debian/changelog  2024-03-04 13:13:51.0 +
+++ railway-gtk-2.4.0/debian/changelog  2024-03-14 16:10:58.0 +
@@ -1,3 +1,10 @@
+railway-gtk (2.4.0-1.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix FTBFS with "type annotation needed" error on i386.
+
+ -- Peter Michael Green   Thu, 14 Mar 2024 16:10:58 +
+
 railway-gtk (2.4.0-1) unstable; urgency=medium
 
   * New upstream release
diff -Nru railway-gtk-2.4.0/debian/patches/add-type-annotation.patch 
railway-gtk-2.4.0/debian/patches/add-type-annotation.patch
--- railway-gtk-2.4.0/debian/patches/add-type-annotation.patch  1970-01-01 
00:00:00.0 +
+++ railway-gtk-2.4.0/debian/patches/add-type-annotation.patch  2024-03-14 
16:10:58.0 +
@@ -0,0 +1,13 @@
+Index: railway-gtk-2.4.0/src/backend/journeys_result.rs
+===
+--- railway-gtk-2.4.0.orig/src/backend/journeys_result.rs
 railway-gtk-2.4.0/src/backend/journeys_result.rs
+@@ -204,7 +204,7 @@ mod imp {
+ let list = self.journeys.borrow();
+ let selection = self.selected.borrow();
+ 
+-let index = list
++let index: Option = list
+ .iter()
+ .position(|j| {
+ j.refresh_token() == selection.as_ref().and_then(|j| 
j.refresh_token())
diff -Nru railway-gtk-2.4.0/debian/patches/series 
railway-gtk-2.4.0/debian/patches/series
--- railway-gtk-2.4.0/debian/patches/series 2024-03-04 13:13:51.0 
+
+++ railway-gtk-2.4.0/debian/patches/series 2024-03-14 16:10:14.0 
+
@@ -1,3 +1,4 @@
 relax-deps.diff
 disable-cargo-home-meson-build.diff
 build-set-project-name-to-railway-gtk.patch
+add-type-annotation.patch

Bug#1061618: src:haskell-misfortune: unsatisfied build dependency in testing: libghc-regex-pcre-doc

[Peter Green]

On 07/03/2024 19:43, Peter Green wrote:

In raspbian, I removed the reference from misfortune.cabel, removed the
build-dependencies on libghc-regex-pcre* and also (for unrelated reasons)
removed the build-dependency on ghc-doc. After doing so I was able to
successfully build the package.

Scratch that, I thought the build had finished, but it hadn't. It did
in fact fail. The reference in the code to PCRE was in all caps which
is why my grep did not find it.

Bug#1061618: src:haskell-misfortune: unsatisfied build dependency in testing: libghc-regex-pcre-doc

[Peter Green]

Can you please investigate the situation and figure out how to resolve
it? 


I'm no haskell expert, but to me the dependency looks vestigal. Grepping
the source tree for "pcre" finds a mention in the misfortune.cabal
file but no mentions in the actual code, and there are no corresponding
binary dependencies.

In raspbian, I removed the reference from misfortune.cabel, removed the
build-dependencies on libghc-regex-pcre* and also (for unrelated reasons)
removed the build-dependency on ghc-doc. After doing so I was able to
successfully build the package.

Bug#1063601: tailspin: FTBFS: error[E0407]: method `backtrace` is not a member of trait `Error`

[Peter Green]

reassign 1063601 tailspin 3.0.0+dfsg-1
retitle 1063601 tailspin FTBFS error: environment variable `CARGO_CHANNEL` not 
defined at compile time
thanks

>> [eyre 0.6.8] error[E0407]: method `backtrace` is not a member of trait 
`Error`
>> [eyre 0.6.8]   --> 
/<>/target/x86_64-unknown-linux-gnu/release/build/eyre-eb1eb971e427fb49/out/probe.rs:19:9

The above seems like a failure not in tailspin but in librust-eyre-dev.


I don't think the errors Sebastian quoted are the cause of the build failure
at all. I think they are just noise from a test compilation performed to
determine what the compiler supports. Those same errors are present
in the successful build log for tailspin 2.0.0

The actual error seems to be.


error: environment variable `CARGO_CHANNEL` not defined at compile time
  --> tests/utils.rs:11:48
   |
11 | PathBuf::from(format!("./target/{}/tspin", env!("CARGO_CHANNEL")))
   |^
   |
   = help: Cargo sets build script variables at run time. Use 
`std::env::var("CARGO_CHANNEL")` instead
   = note: this error originates in the macro `env` (in Nightly builds, run 
with -Z macro-backtrace for more info)


I also notice the following earlier in the build log.


"debian cargo wrapper: WARNING: falling back to simply calling upstream cargo, 
because CARGO_HOME does not end with debian/cargo_home:"


This message appears in the failed logs for 3.0.0 but not in the succesful logs
for 2.0.0.

After serching for CARGO_CHANNEL I think may be the actual cause of the failure.
All the results on codesearch.debian.net for CARGO_CHANNEL seem to relate to 
dh_cargo
or your fork thereof. So I think these are probablly related.

Bug#1061120: rust-ahash-0.7 autopkgtest failure

[Peter Green]

Package: rust-ahash-0.7
Version: 0.7.7-1
Severity: serious

The autopkgtests for rust-ahash-0.7 are failing, this is blocking the
migration of rust-ahash-0.7 to testing which is in turn blocking the
migration of at least one rc bug fix to testing.

There are two issues, the first is that the autopkgtests are trying
to test a "runtime-rng" feature, but no such feature exists. My guess
is that there was some confusion between versions of ahash. I removed
the tests and the corresponding provides.

The second issue is more subtle. The "atomic-polyfill" feature
enables the dependency on the atomic-polyfill crate. However the
dependency on the atomic-polyfill crate is disabled on linux
(among many other targets). Disabling of a dependency on a target
overrides enabling the dependency in a feature. However the code
is not aware of this. The result is that building on Linux with
the atomic-polyfill feature enabled fails.

I see three possible routes for dealing with this.

1. Add target guards to the imports in the code, matching those
   in Cargo.toml
2. Remove the target restrictions from the atomic-polyfill dependency
3. Simply accept that the atomic-polyfill feature is broken on linux
   and stop testing it (this would also mean not having an "all features"
   test.

My patch implements the first option but I don't have a strong
preference for any of them.
diff -Nru rust-ahash-0.7-0.7.7/debian/changelog 
rust-ahash-0.7-0.7.7/debian/changelog
--- rust-ahash-0.7-0.7.7/debian/changelog   2023-12-30 10:22:55.0 
+
+++ rust-ahash-0.7-0.7.7/debian/changelog   2024-01-18 17:11:34.0 
+
@@ -1,3 +1,13 @@
+rust-ahash-0.7 (0.7.7-1.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix autopkgtests
++ Remove provides and autopkgtests for feature runtime-rng which does not
+  exist.
++ Only import atomic-polyfill on platforms where the dependency is enabled
+
+ -- Peter Michael Green   Thu, 18 Jan 2024 17:11:34 +
+
 rust-ahash-0.7 (0.7.7-1) unstable; urgency=medium
 
   [ upstream ]
diff -Nru rust-ahash-0.7-0.7.7/debian/control 
rust-ahash-0.7-0.7.7/debian/control
--- rust-ahash-0.7-0.7.7/debian/control 2023-12-30 10:18:50.0 +
+++ rust-ahash-0.7-0.7.7/debian/control 2024-01-18 17:11:27.0 +
@@ -40,7 +40,6 @@
  librust-ahash-0.7+atomic-polyfill-dev (= ${binary:Version}),
  librust-ahash-0.7+compile-time-rng-dev (= ${binary:Version}),
  librust-ahash-0.7+default-dev (= ${binary:Version}),
- librust-ahash-0.7+runtime-rng-dev (= ${binary:Version}),
  librust-ahash-0.7+serde-dev (= ${binary:Version}),
  librust-ahash-0.7+std-dev (= ${binary:Version}),
  librust-ahash-0.7.7-dev (= ${binary:Version}),
diff -Nru rust-ahash-0.7-0.7.7/debian/patches/1002_atomic_polyfill.patch 
rust-ahash-0.7-0.7.7/debian/patches/1002_atomic_polyfill.patch
--- rust-ahash-0.7-0.7.7/debian/patches/1002_atomic_polyfill.patch  
1970-01-01 00:00:00.0 +
+++ rust-ahash-0.7-0.7.7/debian/patches/1002_atomic_polyfill.patch  
2024-01-18 17:11:34.0 +
@@ -0,0 +1,23 @@
+Description: limit atomic-polyfill import architectures
+ The atomic-polyfill dependency is target limited, but the import
+ is not. This leads to import errors when building with the
+ atomic-polyfill feature enabled (or building with --all-features).
+
+ This patch makes the imports reflect the dependency
+Author: Peter Michael Green 
+Last-Update: 2024-01-18
+
+--- rust-ahash-0.7-0.7.7.orig/src/random_state.rs
 rust-ahash-0.7-0.7.7/src/random_state.rs
+@@ -29,9 +29,9 @@ extern crate alloc;
+ #[cfg(feature = "std")]
+ extern crate std as alloc;
+ 
+-#[cfg(feature = "atomic-polyfill")]
++#[cfg(all(feature = "atomic-polyfill",not(any(target_os = "linux", target_os 
= "android", target_os = "windows", target_os = "macos", target_os = "ios", 
target_os = "freebsd", target_os = "openbsd", target_os = "netbsd", target_os = 
"dragonfly", target_os = "solaris", target_os = "illumos", target_os = 
"fuchsia", target_os = "redox", target_os = "cloudabi", target_os = "haiku", 
target_os = "vxworks", target_os = "emscripten", target_os = "wasi"]
+ use atomic_polyfill as atomic;
+-#[cfg(not(feature = "atomic-polyfill"))]
++#[cfg(not(all(feature = "atomic-polyfill",not(any(target_os = "linux", 
target_os = "android", target_os = "windows", target_os = "macos", target_os = 
"ios", target_os = "freebsd", target_os = "openbsd", target_os = "netbsd", 
target_os = "dragonfly", target_os = "solaris", target_os = "illumos", 
target_os = "fuchsia", target_os = "redox", target_os = "cloudabi", target_os = 
"haiku", target_os = "vxworks", target_os = "emscripten", target_os = 
"wasi")]
+ use core::sync::atomic;
+ 
+ use alloc::boxed::Box;
diff -Nru rust-ahash-0.7-0.7.7/debian/patches/series 
rust-ahash-0.7-0.7.7/debian/patches/series
--- rust-ahash-0.7-0.7.7/debian/patches/series  2023-12-30 09:53:32.0 
+
+++ rust-ahash-0.7-0.7.7/debian/patches/series  2024-01-18 17:11:34.0 

Bug#1057451: rust-ahash: autopkgtests failing

[Peter Green]

tags 1057451 +patch
thanks

I just looked at the remaining autopkgtest failures in rust-ahash, I found and
fixed two issues and after doing so the autopkgtests passed.

The first issue was some arithmetic overflows in summations in tests/bench.rs
these cause panics if built/run in Debug mode (as "cargo test --all-targets"
does by default). The results of the summations were not used for anything.

I'm not sure what the original intent of the summations was, perhaps it was
just to shut compiler warnings up, perhaps it was an attempt to stop the
compiler optimizing stuff away. I just commented out the summations, another
possibility would be to replace them with calls to std::hint::black_box

The second issue was some tests that failed to build when the std feature
was enabled but none of the rng features (runtime-rng, compile-time-rng
or no-rng) were enabled. I added/adjusted feature gaurds to fix this
issue.

Debdiff attached, if I get no response I will likely NMU this in a week
or so.diff -Nru rust-ahash-0.8.5/debian/changelog rust-ahash-0.8.5/debian/changelog
--- rust-ahash-0.8.5/debian/changelog   2023-12-10 23:06:48.0 +
+++ rust-ahash-0.8.5/debian/changelog   2023-12-26 10:08:52.0 +
@@ -1,3 +1,13 @@
+rust-ahash (0.8.5-3.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix autopkgtest. (Closes: #1057451)
++ Disable overflowing additions whose results are not used in 
tests/bench.rs
++ Add/Adjust feature gaurds to fix build of tests when the std feature is
+  enabled but no rng feature is enabled.
+
+ -- Peter Michael Green   Tue, 26 Dec 2023 10:08:52 +
+
 rust-ahash (0.8.5-3) unstable; urgency=medium
 
   * update patch;
diff -Nru rust-ahash-0.8.5/debian/patches/1001_bench_overflow.patch 
rust-ahash-0.8.5/debian/patches/1001_bench_overflow.patch
--- rust-ahash-0.8.5/debian/patches/1001_bench_overflow.patch   1970-01-01 
00:00:00.0 +
+++ rust-ahash-0.8.5/debian/patches/1001_bench_overflow.patch   2023-12-26 
10:08:52.0 +
@@ -0,0 +1,84 @@
+Description:  Disable overflowing additions whose results are not used in 
tests/bench.rs
+Author: Peter Michael Green 
+Bug-Debian: https://bugs.debian.org/1057451
+
+--- rust-ahash-0.8.5.orig/tests/bench.rs
 rust-ahash-0.8.5/tests/bench.rs
+@@ -118,10 +118,10 @@ fn bench_map(c:  Criterion) {
+ group.bench_function("aHash-alias", |b| {
+ b.iter(|| {
+ let hm: ahash::HashMap = (0..1_000_000).map(|i| (i, 
i)).collect();
+-let mut sum = 0;
++//let mut sum = 0;
+ for i in 0..1_000_000 {
+ if let Some(x) = hm.get() {
+-sum += x;
++//sum += x;
+ }
+ }
+ })
+@@ -129,10 +129,10 @@ fn bench_map(c:  Criterion) {
+ group.bench_function("aHash-hashBrown", |b| {
+ b.iter(|| {
+ let hm: hashbrown::HashMap = (0..1_000_000).map(|i| 
(i, i)).collect();
+-let mut sum = 0;
++//let mut sum = 0;
+ for i in 0..1_000_000 {
+ if let Some(x) = hm.get() {
+-sum += x;
++//sum += x;
+ }
+ }
+ })
+@@ -140,10 +140,10 @@ fn bench_map(c:  Criterion) {
+ group.bench_function("aHash-hashBrown-explicit", |b| {
+ b.iter(|| {
+ let hm: hashbrown::HashMap = 
(0..1_000_000).map(|i| (i, i)).collect();
+-let mut sum = 0;
++//let mut sum = 0;
+ for i in 0..1_000_000 {
+ if let Some(x) = hm.get() {
+-sum += x;
++//sum += x;
+ }
+ }
+ })
+@@ -151,10 +151,10 @@ fn bench_map(c:  Criterion) {
+ group.bench_function("aHash-wrapper", |b| {
+ b.iter(|| {
+ let hm: ahash::AHashMap = (0..1_000_000).map(|i| 
(i, i)).collect();
+-let mut sum = 0;
++//let mut sum = 0;
+ for i in 0..1_000_000 {
+ if let Some(x) = hm.get() {
+-sum += x;
++//sum += x;
+ }
+ }
+ })
+@@ -162,10 +162,10 @@ fn bench_map(c:  Criterion) {
+ group.bench_function("aHash-rand", |b| {
+ b.iter(|| {
+ let hm: std::collections::HashMap = 
(0..1_000_000).map(|i| (i, i)).collect();
+-let mut sum = 0;
++//let mut sum = 0;
+ for i in 0..1_000_000 {
+ if let Some(x) = hm.get() {
+-sum += x;
++//sum += x;
+ }
+ }
+ })
+@@ -174,10 +174,10 @@ fn bench_map(c:  Criterion) {
+ b.iter(|| 

Bug#1059034: Impossible to install: Depends on missing package,librust-ego-tree-0.6+default-dev

[Peter Green]

Impossible to install: Depends on missing package
librust-ego-tree-0.6+default-dev


rust-ego-tree was uploaded but rejected.

https://alioth-lists.debian.net/pipermail/pkg-rust-maintainers/2023-December/037170.html

Bug#1051521: rust-palette: autopkgtest failures

[Peter Green]

tags 105121 +patch
thanks


rust-palette is unable to migrate to Testing because its
autopkgtests are failing.


I prepared a fix for the autopkgtest issues. While I was at
it I also bumped the clap dev-dependency and the associated
build and test dependencies to version 4 as we would like
to phase out clap version 3.

I discussed the clap upgrade with upstream, they said it was
only used for examples but they did not want to bump it
upstream at this time due to msrv.

https://github.com/Ogeon/palette/issues/364

If I get no response I will likely NMU this in a week or so.

Bug#1059009: hime: build-depends on dropped package.

[Peter Green]

Package: hime
Version: 0.9.11+dfsg-2
Severity: serious
Tags: trixie, sid
Justification: rc-policy - packages must be buildable within the same release.
User: debian...@lists.debian.org
Usertags: edos-uninstallable

Hime build-depends on libayatana-indicator-dev which is no longer built
by the libayatana-indicator source package. It is still present in
unstable as a cruft package but is gone from testing on most architectures
meaning your package cannot be built on most architectures in testing.

Bug#1058074: rust-hyper-rustls - autopkgtest failure

[Peter Green]

Package: rust-hyper-rustls
Version: 0.24.2-1
Severity: serious
Tags: patch

The autopkgtest for rust-hyper-rustls is failing, because the code in
test_alpn_http2 requires a runtime, but the feature requirements for
the test do not specify one.

A debdiff fixing this is attatched.diff -Nru rust-hyper-rustls-0.24.2/debian/changelog 
rust-hyper-rustls-0.24.2/debian/changelog
--- rust-hyper-rustls-0.24.2/debian/changelog   2023-12-02 20:25:28.0 
+
+++ rust-hyper-rustls-0.24.2/debian/changelog   2023-12-12 01:18:39.0 
+
@@ -1,3 +1,11 @@
+rust-hyper-rustls (0.24.2-1.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix feature requirements for test_alpn_http to prevent autopkgtest
+failure.
+
+ -- Peter Michael Green   Tue, 12 Dec 2023 01:18:39 +
+
 rust-hyper-rustls (0.24.2-1) unstable; urgency=medium
 
   * unfuzz patches
diff -Nru 
rust-hyper-rustls-0.24.2/debian/patches/1002_test-requires-runtime.patch 
rust-hyper-rustls-0.24.2/debian/patches/1002_test-requires-runtime.patch
--- rust-hyper-rustls-0.24.2/debian/patches/1002_test-requires-runtime.patch
1970-01-01 00:00:00.0 +
+++ rust-hyper-rustls-0.24.2/debian/patches/1002_test-requires-runtime.patch
2023-12-12 01:18:17.0 +
@@ -0,0 +1,20 @@
+Description: tests_alpn_http2 fails to build if no runtime is enabled
+ Add feature guards so it doesn't cause autopkgtest failure.
+Author: Peter Michael Green 
+Last-Update: 2023-12-12
+---
+This patch header follows DEP-3: http://dep.debian.net/deps/dep3/
+
+Index: rust-hyper-rustls-0.24.2/src/connector/builder.rs
+===
+--- rust-hyper-rustls-0.24.2.orig/src/connector/builder.rs
 rust-hyper-rustls-0.24.2/src/connector/builder.rs
+@@ -353,7 +353,7 @@ mod tests {
+ }
+ 
+ #[test]
+-#[cfg(all(not(feature = "http1"), feature = "http2"))]
++#[cfg(all(not(feature = "http1"), feature = "http2", any(feature = 
"native-tokio", feature = "tokio-runtime")))]
+ fn test_alpn_http2() {
+ let roots = rustls::RootCertStore::empty();
+ let tls_config = rustls::ClientConfig::builder()
diff -Nru rust-hyper-rustls-0.24.2/debian/patches/series 
rust-hyper-rustls-0.24.2/debian/patches/series
--- rust-hyper-rustls-0.24.2/debian/patches/series  2022-12-06 
11:57:28.0 +
+++ rust-hyper-rustls-0.24.2/debian/patches/series  2023-12-12 
01:16:36.0 +
@@ -1,3 +1,4 @@
 1001_http1.patch
+1002_test-requires-runtime.patch
 2001_webpki-roots.patch
 2004_tests_broken.patch

Bug#1054156: librust-env-logger-0.7+default-dev shouldn't provide librust-env-logger+default-dev

[Peter Green]

On the one hand I'm not at all convinced this bug is rc, on the other
hand I don't think shipping a four year old version of env-logger
in the next release of Debian is a great idea.

So I decided to look at the reverse dependencies, I found three

safe-vdash - this is a Jonas package, the dependency on rust-env-logger-0.7 
seems bogus, I filed a bug.
rust-tracing-log - the new version no longer depends on env-logger, I updated 
it along with it's reverse dependency tracing-subscriber.
rspotify - this package is long term broken, noctis expressed an interest in 
fixing it back in January but I don't know what if-any progress he has made 
since then.

Bug#1057198: rust-wasmtime: FTBFS error[E0599]: no function or associated item named `from_str` found for struct `Triple` in the current scope

[Peter Green]

Package: rust-wasmtime
Version: 15.0.0+dfsg-3
Severity: serious
Control: block 1055090 by -1

https://buildd.debian.org/status/fetch.php?pkg=rust-wasmtime=all=15.0.0%2Bdfsg-3=1701097543=0


error[E0599]: no function or associated item named `from_str` found for struct 
`Triple` in the current scope
   --> cranelift/codegen/src/isa/mod.rs:118:12
|
118 | lookup(triple!(name))
|^ function or associated item not found in `Triple`
|
= help: items from traits can only be used if the trait is in scope
= note: this error originates in the macro `triple` (in Nightly builds, run 
with -Z macro-backtrace for more info)
help: the following trait is implemented but not in scope; perhaps add a `use` 
for it:
|
46  + use core::str::FromStr;
|

For more information about this error, try `rustc --explain E0599`.
The following warnings were emitted during compilation:

Bug#1055099: rust-async-task: Failing autopkgtests

[Peter Green]

On 21/11/2023 11:41, Jonas Smedegaard wrote:

Quoting Peter Green (2023-11-21 09:16:21)

Tags 1055099 +patch
thanks


The autopkgtests for rust-async-task began failing after the upgrade
to from 4.4.1-1 to 4.5.0-1. This prevents its migration to Testing.

I have prepared a patch which adds a feature guard to the example in
question and hence fixes the autopkgtest. A debdiff is attatched, if
I get no response I intend to NMU this soon.

Thanks.

Seems the intended attachment is missing, however.


Sorry, attatched now.
diff -Nru rust-async-task-4.5.0/debian/changelog 
rust-async-task-4.5.0/debian/changelog
--- rust-async-task-4.5.0/debian/changelog  2023-10-19 12:46:47.0 
+
+++ rust-async-task-4.5.0/debian/changelog  2023-11-21 08:05:37.0 
+
@@ -1,3 +1,10 @@
+rust-async-task (4.5.0-1.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Add patch 1001 to add feature requirement to example (Closes: #1055099)
+
+ -- Peter Micheal Green   Tue, 21 Nov 2023 08:05:37 +
+
 rust-async-task (4.5.0-1) unstable; urgency=medium
 
   [ upstream ]
diff -Nru 
rust-async-task-4.5.0/debian/patches/1001_example_feature_requirements.patch 
rust-async-task-4.5.0/debian/patches/1001_example_feature_requirements.patch
--- 
rust-async-task-4.5.0/debian/patches/1001_example_feature_requirements.patch
1970-01-01 00:00:00.0 +
+++ 
rust-async-task-4.5.0/debian/patches/1001_example_feature_requirements.patch
2023-11-21 08:05:31.0 +
@@ -0,0 +1,16 @@
+Description: add feature requirement for example
+ Avoids build failure in autopkgtest.
+Author: Peter Micahel Green 
+Forwarded: no
+Last-Update: 2023-11-21
+---
+This patch header follows DEP-3: http://dep.debian.net/deps/dep3/
+Index: rust-async-task-4.5.0/examples/spawn-local.rs
+===
+--- rust-async-task-4.5.0.orig/examples/spawn-local.rs
 rust-async-task-4.5.0/examples/spawn-local.rs
+@@ -1,3 +1,4 @@
++#![cfg(feature = "std")]
+ //! A simple single-threaded executor that can spawn non-`Send` futures.
+ 
+ use std::cell::Cell;
diff -Nru rust-async-task-4.5.0/debian/patches/series 
rust-async-task-4.5.0/debian/patches/series
--- rust-async-task-4.5.0/debian/patches/series 2023-10-10 17:25:47.0 
+
+++ rust-async-task-4.5.0/debian/patches/series 2023-11-21 08:05:37.0 
+
@@ -1 +1,2 @@
+1001_example_feature_requirements.patch
 2001_flaky-test.patch

Bug#1055099: rust-async-task: Failing autopkgtests

[Peter Green]

Tags 1055099 +patch
thanks


The autopkgtests for rust-async-task began failing after the upgrade
to from 4.4.1-1 to 4.5.0-1. This prevents its migration to Testing.


I have prepared a patch which adds a feature guard to the example in
question and hence fixes the autopkgtest. A debdiff is attatched, if
I get no response I intend to NMU this soon.

Bug#1055895: [Pkg-rust-maintainers] Bug#1055895: rust-self-cell: RUSTSEC-2023-0070

[Peter Green]

Please see https://rustsec.org/advisories/RUSTSEC-2023-0070.html


I have read the upstream advisory and the linked bug report and while
I don't fully understand the nitty gritty details my understanding of
the issue is.

* It was discovered that code (which was not marked as unsafe)
  could mis-use self-cell in a way that invoked undefined
  behaviour.
* This was fixed by adding an additional compile time check
  which will cause the build to fail in such cases.

Based on this understanding I have

* Uploaded the new version of rust-self-cell
* Performed a rebuild test of the only reverse dependency
  rust-coreutils, it built successfully, so presumably it is
  not impacted by this issue.

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

[Peter Green]

Package: rust-rustls-webpki
Version: 0.101.6-1
Severity: serious

The autopkgtest for rust-rustls-webpki fails with


238s error[E0583]: file not found for module `test_utils`
238s   --> src/lib.rs:65:1
238s|
238s 65 | pub(crate) mod test_utils;
238s| ^^
238s|
238s= help: to create the module `test_utils`, create file "src/test_utils.rs" or 
"src/test_utils/mod.rs"


This bug affects both the versions in unstable and experimental. It
does not affect the version currently in testing.

It appears that the file src/test_utils.rs is included in the source package
but is not making it into the binary package for some reason.

Bug#1054568: breezy - broken rust regex build-dependency

[Peter Green]

Package: breezy
Version: 3.3.4-1
Severity: serious
Tags: patch

Breezy build-depends on librust-regex+aho-corasick-dev which is no longer
provided (in either physical or virtual form) by rust-regex.

Looking at the Cargo.toml files I belive the correct build-dependency is
librust-regex-1+default-dev (>= 1.5.4), after changing the build-dependency
I was able to get a succesful build.

If there are no objections I will likely NMU this in the not too distant
future.diff -Nru breezy-3.3.4/debian/changelog breezy-3.3.4/debian/changelog
--- breezy-3.3.4/debian/changelog   2023-09-04 17:39:38.0 +
+++ breezy-3.3.4/debian/changelog   2023-10-26 02:55:52.0 +
@@ -1,3 +1,12 @@
+breezy (3.3.4-1.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Replace broken build-dependency on "librust-regex+aho-corasick-dev"
+with build-dependency on "librust-regex-1+default-dev (>= 1.5.4)"
+based on the contents of Cargo.toml.
+
+ -- Peter Michael Green   Thu, 26 Oct 2023 02:55:52 +
+
 breezy (3.3.4-1) unstable; urgency=low
 
   * New upstream release.
diff -Nru breezy-3.3.4/debian/control breezy-3.3.4/debian/control
--- breezy-3.3.4/debian/control 2023-09-04 17:39:38.0 +
+++ breezy-3.3.4/debian/control 2023-10-26 02:55:40.0 +
@@ -31,7 +31,7 @@
debhelper-compat (= 13),
librust-pkg-version-dev,
librust-pyo3-dev,
-   librust-regex+aho-corasick-dev,
+   librust-regex-1+default-dev (>= 1.5.4),
rustc
 Standards-Version: 4.6.2
 Rules-Requires-Root: no

Bug#1054141: fd - incompatible with clap 4.4.6

[Peter Green]

Package: rust-fd-find
Version: 8.7.0-3
Severity: serious

This bug affects both 8.7.0-3 in testing and 8.7.0-4 in unstable.

I recently uploaded clap 4.4.6, since this was not a semver bump I was not
expecting any breakage. Unfortunately it turns out it broke fd.

There are (at least) two issues, the first is that the "unstable-grouped"
feature was removed in clap 4.2.0 by the commit
https://github.com/clap-rs/clap/commit/d5089b267235db72a6ea146ac4f1cb7f79a170a6
"fix!: Remove stablized unstable-grouped feature". By removing the reference to
the "unstable-grouped" feature I was able to successfully build fd and run it's
tests against clap versions 4.2.0 through 4.2.4.

The second issue arises starting with clap version 4.2.5, a bunch of tests fail
with errors like.

 test_custom_ignore_files stdout 
thread 'test_custom_ignore_files' panicked at '`fd --ignore-file custom.ignore 
foo` did not exit successfully.
stdout:
---
---
stderr:
---
thread 'main' panicked at 'Command fd: Argument group 'execs' conflicts with 
non-existent 'has_results' id', 
/root/.cargo/registry/src/github.com-1ecc6299db9ec823/clap_builder-4.2.5/src/builder/debug_asserts.rs:317:13
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
---', tests/testenv/mod.rs:238:13

I'm not sure what should be done about this second issue. I've filed a bug 
upstream
at https://github.com/sharkdp/fd/issues/1397

Bug#1053632: [Pkg-rust-maintainers] Bug#1053632: rust-libslirp: Remove from Debian?

[Peter Green]

rust-libslirp has no reverse dependencies in Debian.

https://codesearch.debian.net/search?q=path%3Adebian%2Fcontrol+rust-libslirp=1

It is also one of the blockers for removing the old rust-zbus-1 from
Debian. See https://bugs.debian.org/1053631

Can we remove rust-libslirp and rust-libslirp-sys from Debian?


We discussed this on irc a while back, and apparently the package is important
to debos. Though the package relationship is only a "suggests".


rust-libslirp depends on the obsolete rust-zbus-1 (instead of the
current rust-zbus-3) and rust-zvariant-2 (instead of rust-zvariant-3).


I looked at porting this, but came to the conclusion that is beyond what
I could reasonablly do. IIRC zbus moved from sync rust to async rust
and there was no porting guide.

Bug#1053630: flask-dance: build-depends on package that is not in testing.

[Peter Green]

Package: flask-dance
Version: 6.2.0.2-1
Severity: serious
Justification: rc policy - "packages must be buildable within the same release".
Tags: trixie, sid

flask-dance build-depends on python3-sphinxcontrib.seqdiag which is not in 
testing,
it was removed because it FTBFS and was badly broken, but for some reason
flask-dance was not removed at the same time (dependency handling in 
auto-removals
is far from perfect).

This issue affects both versions 6:2.0.2-1 in testing and 7.0.0-1 which is
trying to migrate to testing but failing to do so due to the aforementioned
build-dependency.

Bug#1053536: squeekboard FTBFS with version 0.18 of rust gtk stack.

[Peter Green]

Package: squeekboard
Version: 1.22.0-4
Severity: serious
Tags: patch

The rust gtk stack was recently updated, and squeekboard needs a few
tweaks to build with the new version.

I have whipped up a patch and tested that squeekboard builds with it,
I have not tested it beyond that.diff -Nru squeekboard-1.22.0/debian/changelog 
squeekboard-1.22.0/debian/changelog
--- squeekboard-1.22.0/debian/changelog 2023-08-23 08:47:31.0 +
+++ squeekboard-1.22.0/debian/changelog 2023-10-05 19:31:30.0 +
@@ -1,3 +1,10 @@
+squeekboard (1.22.0-4.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * update patches for gtk-rs 0.18
+
+ -- Peter Michael Green   Thu, 05 Oct 2023 19:31:30 +
+
 squeekboard (1.22.0-4) unstable; urgency=medium
 
   [ Peter Michael Green ]
diff -Nru 
squeekboard-1.22.0/debian/patches/0001-Cargo.deps.newer-update-for-gtk-rs-0.17.patch
 
squeekboard-1.22.0/debian/patches/0001-Cargo.deps.newer-update-for-gtk-rs-0.17.patch
--- 
squeekboard-1.22.0/debian/patches/0001-Cargo.deps.newer-update-for-gtk-rs-0.17.patch
2023-08-23 08:47:31.0 +
+++ 
squeekboard-1.22.0/debian/patches/0001-Cargo.deps.newer-update-for-gtk-rs-0.17.patch
1970-01-01 00:00:00.0 +
@@ -1,53 +0,0 @@
-From: Arnaud Ferraris 
-Date: Tue, 27 Jun 2023 12:31:30 +0200
-Subject: Cargo.deps.newer: update for gtk-rs 0.17
-

- Cargo.deps.newer | 20 ++--
- 1 file changed, 10 insertions(+), 10 deletions(-)
-
-diff --git a/Cargo.deps.newer b/Cargo.deps.newer
-index 197dfa3..c236cc5 100644
 a/Cargo.deps.newer
-+++ b/Cargo.deps.newer
-@@ -9,30 +9,30 @@ zvariant = "2.10.*"
- zvariant_derive = "2.10.*"
- 
- [dependencies.cairo-rs]
--version = "0.14.*"
-+version = "0.17.*"
- 
- [dependencies.cairo-sys-rs]
--version = "0.14.*"
-+version = "0.17.*"
- 
- [dependencies.gdk]
--version = "0.14.*"
-+version = "0.17.*"
- 
- [dependencies.gio]
--version = "0.14.*"
-+version = "0.17.*"
- features = ["v2_58"]
- 
- [dependencies.glib]
--version = "0.14.*"
-+version = "0.17.*"
- features = ["v2_58"]
- 
- [dependencies.glib-sys]
--version = "0.14.*"
-+version = "0.17.*"
- features = ["v2_58"]
- 
- [dependencies.gtk]
--version = "0.14.*"
--features = ["v3_22"]
-+version = "0.17.*"
-+features = ["v3_24"]
- 
- [dependencies.gtk-sys]
--version = "0.14.*"
--features = ["v3_22"]
-+version = "0.17.*"
-+features = ["v3_24"]
diff -Nru 
squeekboard-1.22.0/debian/patches/0001-Cargo.deps.newer-update-for-gtk-rs-0.18.patch
 
squeekboard-1.22.0/debian/patches/0001-Cargo.deps.newer-update-for-gtk-rs-0.18.patch
--- 
squeekboard-1.22.0/debian/patches/0001-Cargo.deps.newer-update-for-gtk-rs-0.18.patch
1970-01-01 00:00:00.0 +
+++ 
squeekboard-1.22.0/debian/patches/0001-Cargo.deps.newer-update-for-gtk-rs-0.18.patch
2023-10-05 19:31:30.0 +
@@ -0,0 +1,55 @@
+Modified by Peter Michael Green for version 0.18 of rust gtk stack.
+
+From: Arnaud Ferraris 
+Date: Tue, 27 Jun 2023 12:31:30 +0200
+Subject: Cargo.deps.newer: update for gtk-rs 0.17
+
+---
+ Cargo.deps.newer | 20 ++--
+ 1 file changed, 10 insertions(+), 10 deletions(-)
+
+diff --git a/Cargo.deps.newer b/Cargo.deps.newer
+index 197dfa3..c236cc5 100644
+--- a/Cargo.deps.newer
 b/Cargo.deps.newer
+@@ -9,30 +9,30 @@ zvariant = "2.10.*"
+ zvariant_derive = "2.10.*"
+ 
+ [dependencies.cairo-rs]
+-version = "0.14.*"
++version = "0.18.*"
+ 
+ [dependencies.cairo-sys-rs]
+-version = "0.14.*"
++version = "0.18.*"
+ 
+ [dependencies.gdk]
+-version = "0.14.*"
++version = "0.18.*"
+ 
+ [dependencies.gio]
+-version = "0.14.*"
++version = "0.18.*"
+ features = ["v2_58"]
+ 
+ [dependencies.glib]
+-version = "0.14.*"
++version = "0.18.*"
+ features = ["v2_58"]
+ 
+ [dependencies.glib-sys]
+-version = "0.14.*"
++version = "0.18.*"
+ features = ["v2_58"]
+ 
+ [dependencies.gtk]
+-version = "0.14.*"
+-features = ["v3_22"]
++version = "0.18.*"
++features = ["v3_24"]
+ 
+ [dependencies.gtk-sys]
+-version = "0.14.*"
+-features = ["v3_22"]
++version = "0.18.*"
++features = ["v3_24"]
diff -Nru 
squeekboard-1.22.0/debian/patches/0004-Cargo.-use-xkbcommon-v0.5.patch 
squeekboard-1.22.0/debian/patches/0004-Cargo.-use-xkbcommon-v0.5.patch
--- squeekboard-1.22.0/debian/patches/0004-Cargo.-use-xkbcommon-v0.5.patch  
2023-08-23 08:47:31.0 +
+++ squeekboard-1.22.0/debian/patches/0004-Cargo.-use-xkbcommon-v0.5.patch  
2023-10-05 19:31:30.0 +
@@ -26,14 +26,10 @@
 index c236cc5..b36e616 100644
 --- a/Cargo.deps.newer
 +++ b/Cargo.deps.newer
-@@ -7,6 +7,7 @@ zbus = "1.9.*"
- zvariant = "2.10.*"
- # Newer versions seem to confuse the version of Cargo on Debian Bullseye
+@@ -9,2 +9,3 @@ zbus = "1.9.*"
  zvariant_derive = "2.10.*"
 +xkbcommon = { version = "0.5.*", features = ["wayland"] }
  
- [dependencies.cairo-rs]
- version = "0.17.*"
 diff --git a/Cargo.toml.in b/Cargo.toml.in
 index c9b2064..557e6c6 100644
 --- a/Cargo.toml.in
diff -Nru 

Bug#1053440: rust-sequoia-openpgp - incompatible with new regex-syntax.

[Peter Green]

Package: rust-sequoia-openpgp
Version: 1.16.0-3
Severity: serious

rust-sequoia-openpgp depends on an old version of regex-syntax, I tried bumping
the dependency but the build failed.

I have filed an issue about this upstream at
https://gitlab.com/sequoia-pgp/sequoia/-/issues/1056

Bug#1053431: rust-grep-regex - depends/build-depends on old version of regex-syntax

[Peter Green]

Package: rust-grep-regex
Version: 0.1.11-1
Severity: serious

rust-grep-regex depends on an old version of rust-regex-syntax, this
is fixed in upstream git, but looking at the commit messages it's not
something I feel comfortable cherry-picking.

I have opened an upstream issue enquiring about the possibility of a
new release at https://github.com/BurntSushi/ripgrep/issues/2619

Bug#1053420: rust-matchers - incompatible with mew regex-automata

[Peter Green]

Package: rust-matchers
Version: 0.1.0-1
Severity: serious
tas: trixie, sid

rust-regex-automata was recently updated to 0.3, rendering
the dependencies and build-dependencies of rust-matchers
uninstallable.

The changes seem to be fairly major, there is an upstream
pull request but details are still being discussed, so I
don't think we should pull it into Debian at this time.

Bug#1052490: rust-async-task, build-depends on old version of rust-flume.

[Peter Green]

Package: rust-async-task
Version: 4.4.0-3
Severity: serious
Tags: patch

rust-async-task's build-dependencies are unsatisfiable in testing/unstable
due to a recent update to rust-flume.

upstream bumped the dependency with no code changes, and after adding the
patch to the Debian package and adjusting the rest of the packaging
accordingly I was able to get a succesfull build and autopkgtest run.

debdiff attached.diff -Nru rust-async-task-4.4.0/debian/changelog 
rust-async-task-4.4.0/debian/changelog
--- rust-async-task-4.4.0/debian/changelog  2023-09-10 13:43:24.0 
+
+++ rust-async-task-4.4.0/debian/changelog  2023-09-23 05:20:54.0 
+
@@ -1,3 +1,14 @@
+rust-async-task (4.4.0-3.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Add patch 0001_update_flume.patch
++ Trivial upstream patch to bump flume depdency to 0.11
+  * Reduce context in 2001_flaky-test.patch so it will apply on top of
+0001_update_flume.patch
+  * Update build and autopkgtest dependencies for flume 0.11.
+
+ -- Peter Michael Green   Sat, 23 Sep 2023 05:20:54 +
+
 rust-async-task (4.4.0-3) unstable; urgency=medium
 
   * omit testing examples for autopkgtest without feature std;
diff -Nru rust-async-task-4.4.0/debian/control 
rust-async-task-4.4.0/debian/control
--- rust-async-task-4.4.0/debian/control2023-07-16 09:24:09.0 
+
+++ rust-async-task-4.4.0/debian/control2023-09-23 05:20:54.0 
+
@@ -7,7 +7,7 @@
  librust-async-task-4+default-dev ,
  librust-atomic-waker-1+default-dev ,
  librust-easy-parallel-3+default-dev ,
- librust-flume-0.10-dev ,
+ librust-flume-0.11-dev ,
  librust-once-cell-1+default-dev ,
  librust-smol-1+default-dev ,
  libstring-shellquote-perl,
diff -Nru rust-async-task-4.4.0/debian/patches/0001_update_flume.patch 
rust-async-task-4.4.0/debian/patches/0001_update_flume.patch
--- rust-async-task-4.4.0/debian/patches/0001_update_flume.patch
1970-01-01 00:00:00.0 +
+++ rust-async-task-4.4.0/debian/patches/0001_update_flume.patch
2023-09-23 05:17:33.0 +
@@ -0,0 +1,29 @@
+commit c42a143176fbf5201411f97f27247ba52e054135
+Author: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com>
+Date:   Mon Aug 21 00:25:27 2023 +
+
+Update flume requirement from 0.10 to 0.11
+
+Updates the requirements on [flume](https://github.com/zesterer/flume) to 
permit the latest version.
+- [Changelog](https://github.com/zesterer/flume/blob/master/CHANGELOG.md)
+- [Commits](https://github.com/zesterer/flume/commits)
+
+---
+updated-dependencies:
+- dependency-name: flume
+  dependency-type: direct:production
+...
+
+Signed-off-by: dependabot[bot] 
+
+diff --git a/Cargo.toml b/Cargo.toml
+index 4345762..fb239ba 100644
+--- a/Cargo.toml
 b/Cargo.toml
+@@ -23,5 +23,5 @@ std = []
+ easy-parallel = "3"
+ flaky_test = "0.1"
+-flume = { version = "0.10", default-features = false }
++flume = { version = "0.11", default-features = false }
+ futures-lite = "1.12.0"
+ once_cell = "1"
diff -Nru rust-async-task-4.4.0/debian/patches/2001_flaky-test.patch 
rust-async-task-4.4.0/debian/patches/2001_flaky-test.patch
--- rust-async-task-4.4.0/debian/patches/2001_flaky-test.patch  2023-08-14 
09:47:35.0 +
+++ rust-async-task-4.4.0/debian/patches/2001_flaky-test.patch  2023-09-23 
05:19:12.0 +
@@ -7,14 +7,8 @@
 This patch header follows DEP-3: http://dep.debian.net/deps/dep3/
 --- a/Cargo.toml
 +++ b/Cargo.toml
-@@ -21,7 +21,6 @@
- [dev-dependencies]
- atomic-waker = "1"
- easy-parallel = "3"
+@@ -24,1 +24,0 @@
 -flaky_test = "0.1"
- flume = { version = "0.10", default-features = false }
- futures-lite = "1.12.0"
- once_cell = "1"
 --- a/tests/waker_panic.rs
 +++ b/tests/waker_panic.rs
 @@ -238,60 +238,6 @@
diff -Nru rust-async-task-4.4.0/debian/patches/series 
rust-async-task-4.4.0/debian/patches/series
--- rust-async-task-4.4.0/debian/patches/series 2023-02-03 11:05:22.0 
+
+++ rust-async-task-4.4.0/debian/patches/series 2023-09-23 05:16:50.0 
+
@@ -1 +1,2 @@
+0001_update_flume.patch
 2001_flaky-test.patch
diff -Nru rust-async-task-4.4.0/debian/tests/control 
rust-async-task-4.4.0/debian/tests/control
--- rust-async-task-4.4.0/debian/tests/control  2023-09-10 13:40:58.0 
+
+++ rust-async-task-4.4.0/debian/tests/control  2023-09-23 05:20:54.0 
+
@@ -6,7 +6,7 @@
  librust-async-task-4-dev,
  librust-atomic-waker-1+default-dev,
  librust-easy-parallel-3+default-dev,
- librust-flume-0.10-dev,
+ librust-flume-0.11-dev,
  librust-once-cell-1+default-dev,
  librust-smol-1+default-dev,
 Restrictions: allow-stderr
@@ -19,7 +19,7 @@
  librust-async-task-4+default-dev,
  librust-atomic-waker-1+default-dev,
  librust-easy-parallel-3+default-dev,
- librust-flume-0.10-dev,
+ librust-flume-0.11-dev,
  librust-once-cell-1+default-dev,
  librust-smol-1+default-dev,
 Restrictions: allow-stderr
@@ 

Bug#1052334: rust-leptonica-sys - Debian and Cargo dependencies inconsistent.

[Peter Green]

Package: rust-leptonica-sys
Version: 0.4.6-3
Severity: serious

The Debian dependencies for rust-leptonica-sys allow versions of
rust-bindgen from 0.60.x to 0.66.x, however the Cargo dependencies
only allow versions from 0.64.x to 0.66.x. This is causing
autopkgtest failures and blocking rust-leptonica-sys
and hence rust-bindgen from migrating to testing.

Please make the dependencies consistent, either by changing the
Debian depndencies to match the Cargo ones or by changing the
Cargo dependency to match the Debian ones.

Bug#1051815: wasmedge - autopkgtest failure with rustc 1.68

[Peter Green]

On 12/09/2023 23:30, Faidon Liambotis wrote:

Control: reassign -1 rustc 1.68.2+dfsg1-1
Control: retitle -1 Builds invalid wasm32 binaries (1.67->1.68 regression)

On Tue, Sep 12, 2023 at 10:56:57PM +0100, Peter Green wrote:

The autopkgtests for wasmedge fail with rustc 1.68, I have observed this with
both testing and unstable's versions of wasmedge, and with both testing and
unstable's versions of wasi-lib.

Thanks for the report. Actually, I think the WasmEdge autopkgtests are
catching a rustc 1.68 regression, whereas rustc compiles wasm32 binaries
that do not work with neither WasmEdge, nor Wasmtime (the latter is not
in Debian).

And it seems the issue persists with rustc 1.69 :(

https://ci.debian.net/data/autopkgtest/unstable/amd64/w/wasmedge/37797497/log.gz


Very simple test case:

$ podman run --rm -it debian:sid  # or bookworm to test with rustc 1.67

root@ad697f1c195f:~# apt install rustc libstd-rust-dev-wasm32
[...]
root@ad697f1c195f:~# rustc -V
rustc 1.68.2
root@ad697f1c195f:~# cat > hello.rs <https://github.com/bytecodealliance/wasmtime/releases/download/v12.0.1/wasmtime-v12.0.1-x86_64-linux.tar.xz
 | tar --wildcards --strip-components=1 -xJ  '*/wasmtime'

root@ad697f1c195f:~# ./wasmtime hello.wasm
Error: failed to run main module `hello.wasm`

Caused by:
 0: failed to invoke command default
 1: error while executing at wasm backtrace:
0: 0x9cd6 - !__stack_chk_fail
1: 0x9d3c - !__wasilibc_init_ssp
2:  0x320 - !__wasm_call_ctors
3:  0x342 - !_start
note: using the `WASMTIME_BACKTRACE_DETAILS=1` environment variable may 
show more debugging information
 2: wasm trap: wasm `unreachable` instruction executed


Thanks,
Faidon

Bug#1051815: wasmedge - autopkgtest failure with rustc 1.68

[Peter Green]

Package: wasmedge
Version: 0.13.3+dfsg-1
Severity:serious

The autopkgtests for wasmedge fail with rustc 1.68, I have observed this with
both testing and unstable's versions of wasmedge, and with both testing and
unstable's versions of wasi-lib.

https://ci.debian.net/data/autopkgtest/unstable/amd64/w/wasmedge/37793933/log.gz

https://ci.debian.net/data/autopkgtest/unstable/amd64/w/wasmedge/37778163/log.gz

https://ci.debian.net/data/autopkgtest/testing/amd64/w/wasmedge/37770138/log.gz



 93s autopkgtest [14:54:23]: test capi-wasi-env: [---
 93s 1..2
 94s ok 1 build wasi_get_env.wasm with cargo/rustc
 94s not ok 2 build set_wasm_env with gcc
 94s # (in test file debian/tests/capi-wasi-env, line 24)
 94s #   `assert_output --partial "ENV1: VAL1"' failed
 94s #
 94s # -- output does not contain substring --
 94s # substring (1 lines):
 94s #   ENV1: VAL1
 94s # output (4 lines):
 94s #   [2023-09-12 14:54:24.910] [error] execution failed: unreachable, Code: 
0x89
 94s #   [2023-09-12 14:54:24.910] [error] In instruction: unreachable 
(0x00) , Bytecode offset: 0x9efb
 94s #   [2023-09-12 14:54:24.910] [error] When executing function name: 
"print_env"
 94s #   Execution Failed. Error message: unreachable
 94s # --
 94s #
 95s autopkgtest [14:54:25]: test capi-wasi-env: ---]
 95s autopkgtest [14:54:25]: test capi-wasi-env:  - - - - - - - - - - results - 
- - - - - - - - -
 95s capi-wasi-envFAIL non-zero exit status 1

Bug#1050299: [Pkg-rust-maintainers] Bug#1050299: rust-webpki: RUSTSEC-2023-0052

[Peter Green]

I think this indicates that it can indeed be safely removed from Debian? I'm
CC'ing developers that have made uploads to this packages in the past for
additiponal opinions as I suspect the issue is more subtle than that.


dak rm does not take account of virtual packages. So for rust packages
it is generally useless.

In terms of reverse dependencies, a number have already moved to the fork
rustls-webpki. However there are still a few left. Specifically
rust-async-tls, rust-trust-dns-proto and rust-trust-dns-client.

async-tls has not switched upstream. On the other hand I don't
see any packages in Debian using it yet. ccing mjt to see what
the reason for packaging it was.

trust-dns-proto and trust-dns-server have switched upstream, however
updating the trust-dns-packages has proved a bit more involved than
I would have liked. I pushed my current efforts to the branch
trust-dns-0.23 in the debcargo-conf repo.

The main thing left to deal with regarding the trust-dns is
aardvark-dns, the code changes needed were beyond my skills,
so I reported an issue upstream. Upstream has come up with
a patch but has not merged it yet.

https://github.com/containers/aardvark-dns/pull/381

Bug#1040837: rust-log situation update.

[Peter Green]

On 22/08/2023 04:47, Peter Green wrote:

Fabian: is sval-serde ready for sponsorship? if so can you add the RFS
file?


I couldn't see anything wrong with the sval-serde package, so I decided to
go ahead and upload it, it is now in NEW.

Bug#1040837: rust-log situation update.

[Peter Green]

A bunch of packages just cleared new, and I made a bunch of follow up uploads.
The result is that the situation surrounding the log package has improved
a bit, but it still less than ideal.

The "kv_unstable" and "kv_unstable_sval" features are now enabled, the
"kv_unstable_serde" feature is currently disabled because it requires
the serde feature in the value-bag package, which in turn requires the
serde1 feature in the value-bag-serde1 crate, which in turn requires the
sval_serde crate which is not currently in debian.

I belive the net result of this is that

* kv-log-macro's binary dependencies are  satisfiable but it's 
build-dependencies are not.
* femme's dependencies and build-dependencies are still unsatisfiable.

Looking in the debcargo-conf repository it seems that Fabian Grünbichler
has made a start on packaging sval_serde.

Fabian: is sval-serde ready for sponsorship? if so can you add the RFS
file?

Bug#1050185: rust-derive-builder-core - depends on old version of darling.

[Peter Green]

Package: rust-derive-builder-core
Version: 0.12.0-1
Severity: serious

Recently a new version of the darling crates was uploaded,
(Alexander Kajil prepared the uploads, Sylvestre uploaded
darling-core and I uploaded the rest of the darling crates).

Most of the reverse dependencies either already had uploads
prepared, or I was able to prepare uploads. Unfortunately
things were not so fortunate with derive-builder-core.

Bumping darling generally also implies bumping syn,
otherwise one runs into issues. We currently have both
versions 1.x and 2.x of syn in Debian, so this is not
an issue in itself but it means more API changes.

I tried to patch derive-builder-core for the new syn,
but I failed. Looking upstream it seems they are also
currently stuck.

https://github.com/colin-kiegel/rust-derive-builder/issues/292

Bug#1049977: rust-hyper-rustls - please update to match new rust-tokio-rustls

[Peter Green]

Package: rust-hyper-rustls
Version: 0.23.2-4
Severity: serious

I just updated tokio-rustls to 0.24.1, hyper-rustls needs updating to 0.24.1
to match.

Bug#1049447: minexpert2 build-dependencies unsatisfiable on many architectures due to change in daps.

[Peter Green]

Package: minexpert2
Version: 8.6.3-1
Severity: serious
Tags: trixie, sid
Justification: rc-policy - packages must be buildable within the same release.
User: debian...@lists.debian.org
Usertags: edos-uninstallable
x-debbugs-cc: lopi...@debian.org

daps 3.3.2+cleaned1-5 moved calibre from suggests to depends.
This means that daps can no longer be installed on architectures
where calibre is not available.

This in turn means that minexpert2 cannot be built on those
architectures. This applies to both the version of minexpert2 in
testing and the version in unstable.

Bug#1049445: massxpert build-dependencies unsatisfiable on many architectures due to change in daps.

[Peter Green]

Package: massxpert
Version: 7.0.0-2
Severity: serious
Justification: rc-policy - packages must be buildable within the same release.
User: debian...@lists.debian.org
Usertags: edos-uninstallable
x-debbugs-cc: lopi...@debian.org

daps 3.3.2+cleaned1-4 moved calibre from suggests to depends.
This means that daps can no longer be installed on architectures
where calibre is not available.

This in turn means that massxpert cannot be built on those
architectures.

Bug#1049440: calculix-cgx - build-depends on dropped transitional package.

[Peter Green]

Package: calculix-cgx
Version: 2.17+dfsg-2
Severity: serious
Tags: trixie, sid

calculix-cgx build-depends on libgl1-mesa-glx which is no longer built by the
mesa source package. It is still present in unstable and on a couple of
architectures in testing as a cruft package, but it is completely gone
from most architectures in testing.

Please update your build-dependencies as appropriate.

Bug#1043418: rust-rustls-webpki - autopkgtest failure, file not found errors.

[Peter Green]

tags 1043418 +patch
thanks


The autopkgtest for rust-rustls-webpki is failing with a bunch of file not 
found errors.


Investigating a bit more, the issue is that the data files in question are
included in the source package, but not in the binary package. I'm not sure if 
this is
a result of your debcargo fork. In any case, I wrote a patch to allow the 
autpkgtest
to use the test data from the source package.

I also ran into a second issue, there is a patch that removes the 
dev-dependencies
needed for the benches and also removes the bench declaration in Cargo.toml, but
cargo has a feature for auto-detecting tests/benches/examples, so it was still
trying to build the benches. I added autobenches=false to disable this.

With the attatched debdiff, the autopkgtest passes. I'd like to see this fixed
fairly quickly, as fixes blocked by the stalled rustls transition are 
threatening
a bunch of packages with auto-removal. If I get no response I'll likely NMU it
next weekend.

diff -Nru rust-rustls-webpki-0.101.3/debian/changelog 
rust-rustls-webpki-0.101.3/debian/changelog
--- rust-rustls-webpki-0.101.3/debian/changelog 2023-08-13 11:24:24.0 
+
+++ rust-rustls-webpki-0.101.3/debian/changelog 2023-08-15 16:01:55.0 
+
@@ -1,3 +1,14 @@
+rust-rustls-webpki (0.101.3-1.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Add patch 2004 and alter debian/tests/control to use test data from the 
source
+package during autopkgtest as the test data is not included in the binary
+package (Closes: #1043418)
+  * Extend patch 2001 to add autobenches=false so that the benches
+are really disabled
+
+ -- Peter Michael Green   Tue, 15 Aug 2023 16:01:55 +
+
 rust-rustls-webpki (0.101.3-1) unstable; urgency=medium
 
   [ upstream ]
diff -Nru rust-rustls-webpki-0.101.3/debian/patches/2001_bencher.patch 
rust-rustls-webpki-0.101.3/debian/patches/2001_bencher.patch
--- rust-rustls-webpki-0.101.3/debian/patches/2001_bencher.patch
2023-08-13 11:24:24.0 +
+++ rust-rustls-webpki-0.101.3/debian/patches/2001_bencher.patch
2023-08-15 15:56:54.0 +
@@ -1,11 +1,22 @@
-Description: drop bench-only build-dependencies
+Description: drop bench-only build-dependencies and disable benches
 Author: Jonas Smedegaard 
-Last-Update: 2023-07-29
+Author: Peter Michael Green 
+Last-Update: 2023-08-15
 ---
 This patch header follows DEP-3: http://dep.debian.net/deps/dep3/
 a/Cargo.toml
-+++ b/Cargo.toml
-@@ -72,9 +72,6 @@
+Index: rust-rustls-webpki-0.101.3/Cargo.toml
+===
+--- rust-rustls-webpki-0.101.3.orig/Cargo.toml
 rust-rustls-webpki-0.101.3/Cargo.toml
+@@ -22,6 +22,7 @@ name = "rustls-webpki"
+ readme = "README.md"
+ repository = "https://github.com/rustls/webpki;
+ version = "0.101.3"
++autobenches = false
+ 
+ include = [
+ "Cargo.toml",
+@@ -72,9 +73,6 @@ untrusted = "0.7.1"
  
  [dev-dependencies]
  base64 = "0.21"
@@ -15,7 +26,7 @@
  serde = { version = "1.0", features = ["derive"] }
  serde_json = "1.0"
  
-@@ -94,11 +91,6 @@
+@@ -94,11 +92,6 @@ lto = true
  debug-assertions = false
  codegen-units = 1
  
diff -Nru 
rust-rustls-webpki-0.101.3/debian/patches/2004_use_test_data_from_source_package_during_autopkgtest.patch
 
rust-rustls-webpki-0.101.3/debian/patches/2004_use_test_data_from_source_package_during_autopkgtest.patch
--- 
rust-rustls-webpki-0.101.3/debian/patches/2004_use_test_data_from_source_package_during_autopkgtest.patch
   1970-01-01 00:00:00.0 +
+++ 
rust-rustls-webpki-0.101.3/debian/patches/2004_use_test_data_from_source_package_during_autopkgtest.patch
   2023-08-15 16:01:55.0 +
@@ -0,0 +1,43 @@
+Description: allow using an environment variable to specify where to find 
test-data
+ This allows the test data, which is included in the source package, but not 
in the
+ binary package to be used during the autopkgtest.
+Author: Peter Michael Green 
+Last-Update: 2023-08-15
+---
+This patch header follows DEP-3: http://dep.debian.net/deps/dep3/
+diff -urN rustls-webpki-0.101.3/build.rs rustls-webpki-0.101.3/build.rs
+--- rustls-webpki-0.101.3/build.rs 1970-01-01 00:00:00.0 +
 rustls-webpki-0.101.3/build.rs 2023-08-15 17:04:24.774078929 +
+@@ -0,0 +1,7 @@
++use std::env::VarError::NotPresent;
++fn main() {
++println!("cargo:rerun-if-env-changed=SOURCEPACKAGEDIR");
++if std::env::var("SOURCEPACKAGEDIR") == Err(NotPresent) {
++
println!("cargo:rustc-env=SOURCEPACKAGEDIR={}",std::env::current_dir().unwrap().to_str().unwrap());
++}
++}
+diff -urN rustls-webpki-0.101.3/src/signed_data.rs 
rustls-webpki-0.101.3/src/signed_data.rs
+--- rustls-webpki-0.101.3/src/signed_data.rs   2006-07-24 01:21:28.0 
+
 rustls-webpki-0.101.3/src/signed_data.rs   2023-08-15 16:39:39.669690115 
+
+@@ -441,7 +441,8 @@
+ macro_rules! test_file_bytes {
+ ( $file_name:expr ) => {
+ 

Bug#1042194: netavark: FTBFS: unsatisfiable build-dependencies: librust-netlink-packet-core-0.4+default-dev (>= 0.4.2-~~), librust-netlink-packet-core-0.4+default-dev (>= 0.4.2-~~)

[Peter Green]

tags 1042194 +patch
thanks


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


The attached patch makes netavark build again (note: some of the packages
it depends on have only just been accepted, so it may be a little time
before binaries are available in sid).diff -Nru netavark-1.4.0/debian/changelog netavark-1.4.0/debian/changelog
--- netavark-1.4.0/debian/changelog 2023-02-03 11:31:00.0 +
+++ netavark-1.4.0/debian/changelog 2023-08-10 22:42:37.0 +
@@ -1,3 +1,13 @@
+netavark (1.4.0-3.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Apply upstream patches for new netlink crates. (Closes: #1042194)
+  * Bump env-logger dependency.
+  * Stop patching zbus cargo dependency and update debian dependency, Debian
+now has zbus 3.x
+
+ -- Peter Michael Green   Thu, 10 Aug 2023 22:42:37 +
+
 netavark (1.4.0-3) unstable; urgency=medium
 
   * Install aardvark-dns by default with netavark
diff -Nru netavark-1.4.0/debian/control netavark-1.4.0/debian/control
--- netavark-1.4.0/debian/control   2023-02-03 11:31:00.0 +
+++ netavark-1.4.0/debian/control   2023-08-10 22:42:37.0 +
@@ -9,7 +9,7 @@
  librust-atty-dev,
  librust-chrono-dev,
  librust-clap-3+derive-dev (>= 3.2.23),
- librust-env-logger-dev (>> 0.9),
+ librust-env-logger-0.10-dev,
  librust-futures-dev,
  librust-fs2-dev,
  librust-humantime-dev,
@@ -17,7 +17,7 @@
  librust-iptables-dev,
  librust-libc-dev,
  librust-log-dev,
- librust-netlink-packet-route-dev,
+ librust-netlink-packet-route-0.17-dev,
  librust-nix-dev,
  librust-rand-dev,
  librust-rtnetlink-dev,
@@ -31,7 +31,7 @@
  librust-termcolor-dev,
  librust-tokio+full-dev,
  librust-url-dev,
- librust-zbus-dev (>= 1.9.2-4),
+ librust-zbus-3-dev (>= 3.6.1),
  librust-zvariant-dev,
  libstd-rust-dev,
  rustc:native ,
diff -Nru netavark-1.4.0/debian/patches/netlink-0.5.patch 
netavark-1.4.0/debian/patches/netlink-0.5.patch
--- netavark-1.4.0/debian/patches/netlink-0.5.patch 1970-01-01 
00:00:00.0 +
+++ netavark-1.4.0/debian/patches/netlink-0.5.patch 2023-08-10 
22:42:37.0 +
@@ -0,0 +1,65 @@
+This patch is based on the upstream commit described below, adapted for
+use in the Debian package by Peter Michael Green.
+
+commit 88a2a7a5a896d9b64d48b95f12e78cf91ee2b05f
+Author: Paul Holzinger 
+Date:   Fri Feb 17 15:03:19 2023 +0100
+
+update netlink-packet-{route,core} to 0.15 and 0.5
+
+They contain breaking changes but nothing major, just moved same type
+definitions.
+
+Signed-off-by: Paul Holzinger 
+
+diff --git a/Cargo.toml b/Cargo.toml
+index de0b465..2620f80 100644
+--- a/Cargo.toml
 b/Cargo.toml
+@@ -44,2 +44,2 @@ zbus = { version = "3.10.0" }
+-netlink-packet-route = "0.13"
+-netlink-packet-core = "0.4.2"
++netlink-packet-route = "0.15"
++netlink-packet-core = "0.5"
+diff --git a/src/network/netlink.rs b/src/network/netlink.rs
+index 4b11a28..dcf165a 100644
+--- a/src/network/netlink.rs
 b/src/network/netlink.rs
+@@ -9,11 +9,14 @@ use crate::{
+ wrap,
+ };
+ use log::{info, trace};
++use netlink_packet_core::{
++NetlinkHeader, NetlinkMessage, NetlinkPayload, NLM_F_ACK, NLM_F_CREATE, 
NLM_F_DUMP, NLM_F_EXCL,
++NLM_F_REQUEST,
++};
+ use netlink_packet_route::{
+ nlas::link::{Info, InfoData, InfoKind, Nla},
+-AddressMessage, LinkMessage, NetlinkHeader, NetlinkMessage, 
NetlinkPayload, RouteMessage,
+-RtnlMessage, AF_INET, AF_INET6, IFF_UP, NLM_F_ACK, NLM_F_CREATE, 
NLM_F_DUMP, NLM_F_EXCL,
+-NLM_F_REQUEST, RTN_UNICAST, RTPROT_STATIC, RTPROT_UNSPEC, 
RT_SCOPE_UNIVERSE, RT_TABLE_MAIN,
++AddressMessage, LinkMessage, RouteMessage, RtnlMessage, AF_INET, 
AF_INET6, IFF_UP, RTN_UNICAST,
++RTPROT_STATIC, RTPROT_UNSPEC, RT_SCOPE_UNIVERSE, RT_TABLE_MAIN,
+ };
+ use netlink_sys::{protocols::NETLINK_ROUTE, SocketAddr};
+ 
+@@ -369,10 +372,7 @@ impl Socket {
+ }
+ 
+ fn send( self, msg: RtnlMessage, flags: u16) -> NetavarkResult<()> {
+-let mut packet = NetlinkMessage {
+-header: NetlinkHeader::default(),
+-payload: NetlinkPayload::from(msg),
+-};
++let mut packet = NetlinkMessage::new(NetlinkHeader::default(), 
NetlinkPayload::from(msg));
+ packet.header.flags = NLM_F_REQUEST | flags;
+ packet.header.sequence_number = {
+ self.sequence_number += 1;
+@@ -440,6 +440,7 @@ impl Socket {
+ return Ok(result);
+ }
+ }
++_ => {}
+ };
+ 
+ offset += rx_packet.header.length as usize;
diff -Nru netavark-1.4.0/debian/patches/netlink-0.7.patch 
netavark-1.4.0/debian/patches/netlink-0.7.patch
--- netavark-1.4.0/debian/patches/netlink-0.7.patch 1970-01-01 
00:00:00.0 +
+++ netavark-1.4.0/debian/patches/netlink-0.7.patch 2023-08-10 
22:42:37.0 +
@@ -0,0 +1,83 @@
+This patch is 

Bug#1043421: rust-rustls FTBFS: file not found error.

[Peter Green]

Package: rust-rustls
Version: 0.21.6-1
Severity: serious

rust-rustls fails to build from source.


error: couldn't read rustls/build.rs: No such file or directory (os error 2)

error: could not compile `rustls` due to previous error

Bug#1043418: rust-rustls-webpki - autopkgtest failure, file not found errors.

[Peter Green]

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

The autopkgtest for rust-rustls-webpki is failing with a bunch of file not 
found errors.
the first of which is pasted below.


199s error: couldn't read 
src/../third-party/chromium/data/verify_signed_data/ecdsa-prime256v1-sha512-spki-params-null.pem:
 No such file or directory (os error 2)
199s--> src/signed_data.rs:443:13
199s |
199s 443 | / include_bytes!(concat!(
199s 444 | | "../third-party/chromium/data/verify_signed_data/",
199s 445 | | $file_name
199s 446 | | ))
199s | |__^
199s ...
199s 573 | / test_verify_signed_data!(
199s 574 | | test_ecdsa_prime256v1_sha512_spki_params_null,
199s 575 | | "ecdsa-prime256v1-sha512-spki-params-null.pem",
199s 576 | | Err(Error::UnsupportedSignatureAlgorithm)
199s 577 | | );
199s | |_- in this macro invocation
199s |
199s = note: this error originates in the macro `include_bytes` which comes 
from the expansion of the macro `test_verify_signed_data` (in Nightly builds, 
run with -Z macro-backtrace for more info)

Bug#1043279: musicbrainzngs build-depends on dropped package

[Peter Green]

Package: musicbrainzngs
Version: 0.7.1-4
Severity: serious
Tags: trixie, sid
Justification: rc policy - "Packages must be buildable within the same release"
User: debian...@lists.debian.org
Usertags: edos-uninstallable

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

Bug#1043176: sccache - update for new serial-test

[Peter Green]

Package: sccache
Severity: serious
Tags: trixie, sid

I just updated the serial-test crate to version 2.0. sccache
needs a small update to the Debian dependency to match. (the Cargo
dependency already allows both versions).

Debdiff attatched.
diff -Nru sccache-0.5.4/debian/changelog sccache-0.5.4/debian/changelog
--- sccache-0.5.4/debian/changelog  2023-07-30 16:13:02.0 +
+++ sccache-0.5.4/debian/changelog  2023-08-06 13:14:32.0 +
@@ -1,3 +1,11 @@
+sccache (0.5.4-7.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Update Debian dependency on serial-test to version 2
+(Cargo dependencies already allow it).
+
+ -- root   Sun, 06 Aug 2023 13:14:32 +
+
 sccache (0.5.4-7) unstable; urgency=medium
 
   * fix yet again: reduce lto further on mipsel
diff -Nru sccache-0.5.4/debian/control sccache-0.5.4/debian/control
--- sccache-0.5.4/debian/control2023-07-27 16:54:09.0 +
+++ sccache-0.5.4/debian/control2023-08-06 13:13:12.0 +
@@ -58,7 +58,7 @@
  librust-serde-1+default-dev,
  librust-serde-1+derive-dev,
  librust-serde-json-1+default-dev,
- librust-serial-test-0.9+default-dev ,
+ librust-serial-test-2+default-dev ,
  librust-sha2-0.10+default-dev,
  librust-strip-ansi-escapes-0.1+default-dev,
  librust-tar-0.4+default-dev,

Bug#1043175: rust-rustls-native-certs - update for new serial-test

[Peter Green]

Package: rust-rustls-native-certs
Severity: serious
Tags: trixie, sid

I just updated the serial-test crate to version 2.0. rust-rustls-native-certs
needs a small update to the Debian dependency to match. (the Cargo
dependency already allows both versions).

Debdiff attatched.
diff -Nru rust-rustls-native-certs-0.6.3/debian/changelog 
rust-rustls-native-certs-0.6.3/debian/changelog
--- rust-rustls-native-certs-0.6.3/debian/changelog 2023-07-29 
21:03:41.0 +
+++ rust-rustls-native-certs-0.6.3/debian/changelog 2023-08-06 
13:08:55.0 +
@@ -1,3 +1,11 @@
+rust-rustls-native-certs (0.6.3-1.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Update debian dependencies for rust-serial-test 2
+(Cargo dependencies already allow that version).
+
+ -- Peter Michael Green   Sun, 06 Aug 2023 13:08:55 +
+
 rust-rustls-native-certs (0.6.3-1) unstable; urgency=medium
 
   [ upstream ]
diff -Nru rust-rustls-native-certs-0.6.3/debian/control 
rust-rustls-native-certs-0.6.3/debian/control
--- rust-rustls-native-certs-0.6.3/debian/control   2023-07-29 
21:03:41.0 +
+++ rust-rustls-native-certs-0.6.3/debian/control   2023-08-06 
13:07:44.0 +
@@ -9,7 +9,7 @@
  librust-rustls-0.21+default-dev ,
  librust-rustls-pemfile-1+default-dev ,
  librust-rustls-webpki-0.101+default-dev ,
- librust-serial-test-0.9+default-dev ,
+ librust-serial-test-2+default-dev ,
  librust-untrusted-0.7+default-dev ,
  libstring-shellquote-perl,
 Maintainer: Jonas Smedegaard 
diff -Nru rust-rustls-native-certs-0.6.3/debian/tests/control 
rust-rustls-native-certs-0.6.3/debian/tests/control
--- rust-rustls-native-certs-0.6.3/debian/tests/control 2023-07-29 
21:03:41.0 +
+++ rust-rustls-native-certs-0.6.3/debian/tests/control 2023-08-06 
13:08:50.0 +
@@ -8,7 +8,7 @@
  librust-rustls-0.21+default-dev,
  librust-rustls-native-certs-0.6-dev,
  librust-rustls-webpki-0.101+default-dev,
- librust-serial-test-0.9+default-dev,
+ librust-serial-test-2+default-dev,
  librust-untrusted-0.7+default-dev,
 Restrictions: allow-stderr, flaky
 
@@ -22,7 +22,7 @@
  librust-rustls-0.21+default-dev,
  librust-rustls-native-certs-0.6+default-dev,
  librust-rustls-webpki-0.101+default-dev,
- librust-serial-test-0.9+default-dev,
+ librust-serial-test-2+default-dev,
  librust-untrusted-0.7+default-dev,
 Restrictions: allow-stderr, flaky
 
@@ -36,6 +36,6 @@
  librust-rustls-0.21+default-dev,
  librust-rustls-native-certs-0.6-dev,
  librust-rustls-webpki-0.101+default-dev,
- librust-serial-test-0.9+default-dev,
+ librust-serial-test-2+default-dev,
  librust-untrusted-0.7+default-dev,
 Restrictions: allow-stderr, flaky

Bug#1043174: precious - update for new serial-test

[Peter Green]

Package: precious
Severity: serious
Tags: trixie, sid

I just updated the serial-test crate to version 2.0. Precious
needs a small update to the Debian dependency to match. (the Cargo
dependency already allows both versions).

Debdiff attatched.diff -Nru precious-0.5.1+20230704/debian/changelog 
precious-0.5.1+20230704/debian/changelog
--- precious-0.5.1+20230704/debian/changelog2023-07-11 21:20:29.0 
+
+++ precious-0.5.1+20230704/debian/changelog2023-08-06 12:48:08.0 
+
@@ -1,3 +1,11 @@
+precious (0.5.1+20230704-1.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Update Debian dependency on serial-test to 2.0.
+(cargo dependency already allows the new version)
+
+ -- Peter Michael Green   Sun, 06 Aug 2023 12:48:08 +
+
 precious (0.5.1+20230704-1) unstable; urgency=medium
 
   [ upstream ]
diff -Nru precious-0.5.1+20230704/debian/control 
precious-0.5.1+20230704/debian/control
--- precious-0.5.1+20230704/debian/control  2023-07-11 21:20:29.0 
+
+++ precious-0.5.1+20230704/debian/control  2023-08-06 12:47:55.0 
+
@@ -33,7 +33,7 @@
  librust-regex-1+default-dev (>= 1.7),
  librust-serde-1+default-dev (>= 1.0.147),
  librust-serde-1+derive-dev (>= 1.0.147),
- librust-serial-test-0.9+default-dev ,
+ librust-serial-test-2.0+default-dev ,
  librust-tempfile-3+default-dev (>= 3.3) ,
  librust-test-case-2+default-dev ,
  librust-thiserror-1+default-dev (>= 1.0.37),

Bug#1042983: squeekboard - rust gtk stack update.

[Peter Green]

Package: squeekboard
Version: 1.22.0-3
Severity: serious

The rust gtk stack is currently being updated in Debian,
squeekboard needs a small patch

Please test that squeekboard works with this patch and
if-so apply it.diff -Nru squeekboard-1.22.0/debian/changelog 
squeekboard-1.22.0/debian/changelog
--- squeekboard-1.22.0/debian/changelog 2023-07-01 15:14:45.0 +
+++ squeekboard-1.22.0/debian/changelog 2023-08-03 16:41:53.0 +
@@ -1,3 +1,10 @@
+squeekboard (1.22.0-3.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Update for gtk-rs 0.17.
+
+ -- Peter Michael Green   Thu, 03 Aug 2023 16:41:53 +
+
 squeekboard (1.22.0-3) unstable; urgency=medium
 
   * debian: update build dependencies.
diff -Nru squeekboard-1.22.0/debian/control squeekboard-1.22.0/debian/control
--- squeekboard-1.22.0/debian/control   2023-07-01 15:14:45.0 +
+++ squeekboard-1.22.0/debian/control   2023-08-03 16:39:01.0 +
@@ -17,11 +17,11 @@
  librust-aho-corasick-dev,
  librust-bitflags-1-dev (>= 1.0),
  librust-clap-4+std-dev (>= 4.0),
- librust-gio+v2-58-dev (>= 0.16),
- librust-glib+v2-58-dev (>= 0.16),
- librust-glib-sys-dev (>= 0.16),
- librust-gtk+v3-24-dev (>= 0.16),
- librust-gtk-sys-dev (>= 0.16),
+ librust-gio+v2-58-dev (>= 0.17),
+ librust-glib+v2-58-dev (>= 0.17),
+ librust-glib-sys-dev (>= 0.17),
+ librust-gtk+v3-24-dev (>= 0.17),
+ librust-gtk-sys-dev (>= 0.17),
  librust-maplit-1-dev (>= 1.0),
  librust-serde-derive-1-dev (>= 1.0),
  librust-serde-yaml-0.8-dev (>= 0.8),
diff -Nru squeekboard-1.22.0/debian/patches/0005-gtk-rs-0.17.patch 
squeekboard-1.22.0/debian/patches/0005-gtk-rs-0.17.patch
--- squeekboard-1.22.0/debian/patches/0005-gtk-rs-0.17.patch1970-01-01 
00:00:00.0 +
+++ squeekboard-1.22.0/debian/patches/0005-gtk-rs-0.17.patch2023-08-03 
16:41:53.0 +
@@ -0,0 +1,56 @@
+Index: squeekboard-1.22.0/Cargo.deps.newer
+===
+--- squeekboard-1.22.0.orig/Cargo.deps.newer
 squeekboard-1.22.0/Cargo.deps.newer
+@@ -10,30 +10,30 @@ zvariant_derive = "2.10.*"
+ xkbcommon = { version = "0.5.*", features = ["wayland"] }
+ 
+ [dependencies.cairo-rs]
+-version = "0.16.*"
++version = "0.17.*"
+ 
+ [dependencies.cairo-sys-rs]
+-version = "0.16.*"
++version = "0.17.*"
+ 
+ [dependencies.gdk]
+-version = "0.16.*"
++version = "0.17.*"
+ 
+ [dependencies.gio]
+-version = "0.16.*"
++version = "0.17.*"
+ features = ["v2_58"]
+ 
+ [dependencies.glib]
+-version = "0.16.*"
++version = "0.17.*"
+ features = ["v2_58"]
+ 
+ [dependencies.glib-sys]
+-version = "0.16.*"
++version = "0.17.*"
+ features = ["v2_58"]
+ 
+ [dependencies.gtk]
+-version = "0.16.*"
++version = "0.17.*"
+ features = ["v3_24"]
+ 
+ [dependencies.gtk-sys]
+-version = "0.16.*"
++version = "0.17.*"
+ features = ["v3_24"]
+Index: squeekboard-1.22.0/src/popover.rs
+===
+--- squeekboard-1.22.0.orig/src/popover.rs
 squeekboard-1.22.0/src/popover.rs
+@@ -326,7 +326,7 @@ pub fn show(
+ let layout_action = gio::SimpleAction::new_stateful(
+ "layout",
+ Some(current_layout_name.to_variant().type_()),
+-_layout_name.to_variant()
++current_layout_name.to_variant()
+ );
+ 
+ let menu_inner = menu.clone();
diff -Nru squeekboard-1.22.0/debian/patches/series 
squeekboard-1.22.0/debian/patches/series
--- squeekboard-1.22.0/debian/patches/series2023-07-01 15:14:45.0 
+
+++ squeekboard-1.22.0/debian/patches/series2023-08-03 16:40:41.0 
+
@@ -2,3 +2,4 @@
 0002-src-popover-fix-build-with-newer-gtk-rs.patch
 0003-src-style-fix-build-with-newer-gtk-rs.patch
 0004-Cargo.-use-xkbcommon-v0.5.patch
+0005-gtk-rs-0.17.patch

Bug#1042419: rust-ureq - update for new cookie-store

[Peter Green]

On 28/07/2023 08:07, Jonas Smedegaard wrote:

Control: block -1 by 1042427

Quoting Peter Green (2023-07-28 05:20:53)

I just updated rust-cookie-store. Ureq needs it's debian
dependencies adjusting to account for this (the cargo
dependencies already allow the new version.

Thanks for the update, and the notice.
Your package update is however blocked by bug#1042427 :-(


Looks like this is now fixed.

https://tracker.debian.org/news/1448563/accepted-rust-digest-0107-2-source-into-unstable/

* Enable oid feature and const-oid optional dependency

Bug#1042419: rust-ureq - update for new cookie-store

[Peter Green]

Package: rust-ureq
Tags: trixie, sid
Severity: serious

I just updated rust-cookie-store. Ureq needs it's debian
dependencies adjusting to account for this (the cargo
dependencies already allow the new version.

Debdiff attatched, I may or may not NMU this later.diff -Nru rust-ureq-2.7.1/debian/changelog rust-ureq-2.7.1/debian/changelog
--- rust-ureq-2.7.1/debian/changelog2023-07-16 22:38:59.0 +
+++ rust-ureq-2.7.1/debian/changelog2023-07-28 02:54:32.0 +
@@ -1,3 +1,11 @@
+rust-ureq (2.7.1-1.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Bump debian dependency on cookie_store to 0.19
+(cargo dependency already allows this version)
+
+ -- Peter Michael Green   Fri, 28 Jul 2023 02:54:32 +
+
 rust-ureq (2.7.1-1) unstable; urgency=medium
 
   [ upstream ]
diff -Nru rust-ureq-2.7.1/debian/control rust-ureq-2.7.1/debian/control
--- rust-ureq-2.7.1/debian/control  2023-07-16 10:47:12.0 +
+++ rust-ureq-2.7.1/debian/control  2023-07-28 02:54:27.0 +
@@ -8,7 +8,7 @@
  librust-brotli-decompressor-2+default-dev ,
  librust-chunked-transfer-1+default-dev ,
  librust-cookie-0.16-dev ,
- librust-cookie-store-0.16+preserve-order-dev ,
+ librust-cookie-store-0.19+preserve-order-dev ,
  librust-encoding-rs-0.8+default-dev ,
  librust-env-logger-0.9+default-dev ,
  librust-flate2-1+default-dev (>= 1.0.22) ,
@@ -42,7 +42,7 @@
  librust-brotli-decompressor-2+default-dev,
  librust-chunked-transfer-1+default-dev,
  librust-cookie-0.16-dev,
- librust-cookie-store-0.16+preserve-order-dev,
+ librust-cookie-store-0.19+preserve-order-dev,
  librust-encoding-rs-0.8+default-dev,
  librust-flate2-1+default-dev (>= 1.0.22),
  librust-http-0.2+default-dev,

Bug#1042413: rust-rustls-webpki - autopkgtest failure building with only the alloc feature is broken.

[Peter Green]

Package: rust-rustls-webpki
Version: 0.101.1
Severity: serious

building the rustls-webpki crate with only the alloc feature
(and not the std feature) is broken. I took a look at fixing
it but came to the conclusion that doing so was beyond what
was reasonable to do in a distribution patch.

Since the only reverse dependency is rust-rustls which
unconditionally enables the std and alloc features, I think
it probably makes sense to just remove/disable the "alloc
feature only" autopkgtest for now.
diff -Nru rust-rustls-webpki-0.101.1/debian/changelog 
rust-rustls-webpki-0.101.1/debian/changelog
--- rust-rustls-webpki-0.101.1/debian/changelog 2023-07-20 14:22:18.0 
+
+++ rust-rustls-webpki-0.101.1/debian/changelog 2023-07-27 21:08:16.0 
+
@@ -1,3 +1,12 @@
+rust-rustls-webpki (0.101.1-2.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Remove "--no-default-features --features alloc" autopkgtest, the
+upstream code fails to build when built with only the alloc
+feature.
+
+ -- Peter Michael Green   Thu, 27 Jul 2023 21:08:16 +
+
 rust-rustls-webpki (0.101.1-2) unstable; urgency=medium
 
   * no-changes source-only upload to enable testing migration
diff -Nru rust-rustls-webpki-0.101.1/debian/tests/control 
rust-rustls-webpki-0.101.1/debian/tests/control
--- rust-rustls-webpki-0.101.1/debian/tests/control 2023-07-16 
16:52:39.0 +
+++ rust-rustls-webpki-0.101.1/debian/tests/control 2023-07-27 
21:08:04.0 +
@@ -17,15 +17,6 @@
 Restrictions: allow-stderr
 
 Test-Command: /usr/share/cargo/bin/cargo-auto-test rustls-webpki 0.101.1
- --all-targets --no-default-features --features alloc
-Features: test-name=rust-rustls-webpki-0.101:alloc
-Depends:
- dh-cargo,
- librust-base64-0.21+default-dev,
- librust-rustls-webpki-0.101+alloc-dev,
-Restrictions: allow-stderr
-
-Test-Command: /usr/share/cargo/bin/cargo-auto-test rustls-webpki 0.101.1
  --all-targets
 Features: test-name=rust-rustls-webpki-0.101:default
 Depends:

Bug#1042401: sccache FTBFS multiple issues

[Peter Green]

Package: sccache
Version: 0.5.4
Severity: serious

sccache has a couple of FTBFS issues.

The first is that a couple of dependencies have been updated, dealing
with this is a simple matter of dropping patches and updating
dependencies.

The second is that the build runs out of address space on mipsel.
The workaround seems to be to use "thin" lto rather than full
lto. Unfortunately i'm not aware of a good way to do this other
than editing Cargo.toml. I did so with sed in debian/rules,
conditioned behind architecture conditionals.

Debdiff attatched, I may or may not NMU this later.diff -Nru sccache-0.5.4/debian/changelog sccache-0.5.4/debian/changelog
--- sccache-0.5.4/debian/changelog  2023-07-05 18:31:19.0 +
+++ sccache-0.5.4/debian/changelog  2023-07-25 23:06:38.0 +
@@ -1,3 +1,14 @@
+sccache (0.5.4-2.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Drop patch 2023 and update debian dependency, directories 5.x is now in
+Debian.
+  * Drop patch 2016 and update debian dependency, daemonise 0.5 is now in
+Debian.
+  * Use thin lto on mipsel to avoid running out of address space.
+
+ -- Peter Michael Green   Tue, 25 Jul 2023 23:06:38 +
+
 sccache (0.5.4-2) unstable; urgency=medium
 
   * drop patch 2019, obsoleted by Debian package updates
diff -Nru sccache-0.5.4/debian/control sccache-0.5.4/debian/control
--- sccache-0.5.4/debian/control2023-06-27 13:20:11.0 +
+++ sccache-0.5.4/debian/control2023-07-25 23:06:38.0 +
@@ -22,8 +22,8 @@
  librust-chrono-0.4+default-dev,
  librust-clap-4+default-dev,
  librust-counted-array-0.1+default-dev,
- librust-daemonize-0.4+default-dev,
- librust-directories-4+default-dev,
+ librust-daemonize-0.5+default-dev,
+ librust-directories-5+default-dev,
  librust-env-logger-0.9+default-dev,
  librust-encoding-0.2+default-dev,
  librust-filetime-0.2+default-dev,
diff -Nru sccache-0.5.4/debian/patches/2016_daemonize.patch 
sccache-0.5.4/debian/patches/2016_daemonize.patch
--- sccache-0.5.4/debian/patches/2016_daemonize.patch   2023-06-27 
13:26:13.0 +
+++ sccache-0.5.4/debian/patches/2016_daemonize.patch   1970-01-01 
00:00:00.0 +
@@ -1,17 +0,0 @@
-Description: relax dependency on crate daemonize
- Needed to match Debian-packaged daemonize v0.4.1.
-Author: Jonas Smedegaard 
-Last-Update: 2023-05-21

-This patch header follows DEP-3: http://dep.debian.net/deps/dep3/
 a/Cargo.toml
-+++ b/Cargo.toml
-@@ -108,7 +108,7 @@
- serial_test = ">= 0.9, < 3"
- 
- [target.'cfg(unix)'.dependencies]
--daemonize = "0.5"
-+daemonize = ">= 0.4, < 0.6"
- 
- [features]
- all = [
diff -Nru sccache-0.5.4/debian/patches/2023_directories.patch 
sccache-0.5.4/debian/patches/2023_directories.patch
--- sccache-0.5.4/debian/patches/2023_directories.patch 2023-07-05 
18:31:19.0 +
+++ sccache-0.5.4/debian/patches/2023_directories.patch 1970-01-01 
00:00:00.0 +
@@ -1,17 +0,0 @@
-Description: relax dependency on crate directories
- Needed to match Debian-packaged directories v4.0.1.
-Author: Jonas Smedegaard 
-Last-Update: 2023-05-21

-This patch header follows DEP-3: http://dep.debian.net/deps/dep3/
 a/Cargo.toml
-+++ b/Cargo.toml
-@@ -33,7 +33,7 @@
- byteorder = "1.0"
- bytes = "1"
- clap = { version = "4.1.11", features = ["derive", "env", "wrap_help"] }
--directories = "5.0.0"
-+directories = ">= 4, < 6"
- encoding = "0.2"
- env_logger = ">= 0.9, < 0.11"
- filetime = "0.2"
diff -Nru sccache-0.5.4/debian/patches/series 
sccache-0.5.4/debian/patches/series
--- sccache-0.5.4/debian/patches/series 2023-07-04 08:18:27.0 +
+++ sccache-0.5.4/debian/patches/series 2023-07-25 23:06:38.0 +
@@ -15,9 +15,7 @@
 2013_is-terminal.patch
 2014_hyper.patch
 2015_uuid.patch
-2016_daemonize.patch
 2017_memmap2.patch
 2018_regex.patch
 2021_chrono.patch
 2022_reqwest_trust-dns.patch
-2023_directories.patch
diff -Nru sccache-0.5.4/debian/rules sccache-0.5.4/debian/rules
--- sccache-0.5.4/debian/rules  2023-07-05 18:31:19.0 +
+++ sccache-0.5.4/debian/rules  2023-07-25 23:06:38.0 +
@@ -26,6 +26,10 @@
dh $@ --buildsystem cargo
 
 override_dh_auto_build:
+   #use thin rather than full lto on mipsel to avoid running out of 
address space.
+ifeq ($(DEB_HOST_ARCH),mipsel)
+   sed -i 's/lto = true/lto = "thin"/' Cargo.toml
+endif
dh_auto_build --buildsystem cargo -- $(CARGO_BUILD_ARGS)
 
 # ensure ccache is not in use during tests
@@ -43,3 +47,8 @@
--name "a fast C/C++/Rust compiler cache" \
--output $@ $< \
|| { $< --help; false; }
+
+ifeq ($(DEB_HOST_ARCH),mipsel)
+execute_after_dh_auto_clean:
+   sed -i 's/lto = "thin"/lto = true/' Cargo.toml
+endif

Bug#1042156: rust-droid-juicer- call for testing of goblin update.

[Peter Green]

I've just patched rust-droid-juicer to use the new version of goblin.
It built fine, but given the lack of any meaningful tests in the
package I don't feel comfortable uploading it to unstable until
someone more familiar with the software has tested it.

I have uploaded the patched version to experimental to make it
easier for people to test.

Bug#1042064: rust-rustls-0.20, autopkgtest failure, missing test ca

[Peter Green]

Package: rust-rustls-0.20
Version: 0.20.8-8
Severity: serious

The autopkgtests for rust-rustls-0.20 fail due to a missing test CA.
I missed this when filing my previous bug due to not testing in a
clean environment.

I can think of several potential solutions for this.

1. Have the tests for the 0.20 package depend on the 0.21 package
   to get the test CA.
2. Include a copy of the test CA in the 0.20 package, presumably
   this would have to be in a different path to avoid file conflicts
3. Skip the tests that involve the test CA.

I will leave it to your judgement as maintainer to decide what
solution to implement.

Bug#1042063: rust-rustls- autopkgtest failure due to error in test dependency

[Peter Green]

Package: rust-rustls
Version: 0.21.5-4
Severity: serious

The autopkgtest for rust-bencher depends on librust-bencher-0.4+default-dev,
however version 0.4 of bencher does not exist, so I presume this was a typo.

After fixing the dependency the autopkgtest passed in my local testing.
A debdiff is attatched, I may or may not NMU this later.diff -Nru rust-rustls-0.21.5/debian/changelog 
rust-rustls-0.21.5/debian/changelog
--- rust-rustls-0.21.5/debian/changelog 2023-07-22 09:04:42.0 +
+++ rust-rustls-0.21.5/debian/changelog 2023-07-25 23:24:10.0 +
@@ -1,3 +1,10 @@
+rust-rustls (0.21.5-4.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix bencher test dependency.
+
+ -- Peter Michael Green   Tue, 25 Jul 2023 23:24:10 +
+
 rust-rustls (0.21.5-4) unstable; urgency=medium
 
   * fix: depend on package for crate rustls-webpki (not webpki)
diff -Nru rust-rustls-0.21.5/debian/tests/control 
rust-rustls-0.21.5/debian/tests/control
--- rust-rustls-0.21.5/debian/tests/control 2023-07-22 09:02:51.0 
+
+++ rust-rustls-0.21.5/debian/tests/control 2023-07-25 23:24:10.0 
+
@@ -5,7 +5,7 @@
 Depends:
  dh-cargo (>= 18),
  librust-base64-0.21+default-dev,
- librust-bencher-0.4+default-dev,
+ librust-bencher-0.1+default-dev (>= 0.1.5),
  librust-docopt-1+default-dev,
  librust-env-logger-0.9+default-dev,
  librust-log-0.4+default-dev,
@@ -28,7 +28,7 @@
 Depends:
  dh-cargo (>= 18),
  librust-base64-0.21+default-dev,
- librust-bencher-0.4+default-dev,
+ librust-bencher-0.1+default-dev (>= 0.1.5),
  librust-docopt-1+default-dev,
  librust-env-logger-0.9+default-dev,
  librust-mio-0.8+default-dev,
@@ -49,7 +49,7 @@
 Depends:
  dh-cargo (>= 18),
  librust-base64-0.21+default-dev,
- librust-bencher-0.4+default-dev,
+ librust-bencher-0.1+default-dev (>= 0.1.5),
  librust-docopt-1+default-dev,
  librust-env-logger-0.9+default-dev,
  librust-mio-0.8+default-dev,
@@ -70,7 +70,7 @@
 Depends:
  dh-cargo (>= 18),
  librust-base64-0.21+default-dev,
- librust-bencher-0.4+default-dev,
+ librust-bencher-0.1+default-dev (>= 0.1.5),
  librust-docopt-1+default-dev,
  librust-env-logger-0.9+default-dev,
  librust-mio-0.8+default-dev,
@@ -91,7 +91,7 @@
 Depends:
  dh-cargo (>= 18),
  librust-base64-0.21+default-dev,
- librust-bencher-0.4+default-dev,
+ librust-bencher-0.1+default-dev (>= 0.1.5),
  librust-docopt-1+default-dev,
  librust-env-logger-0.9+default-dev,
  librust-mio-0.8+default-dev,
@@ -112,7 +112,7 @@
 Depends:
  dh-cargo (>= 18),
  librust-base64-0.21+default-dev,
- librust-bencher-0.4+default-dev,
+ librust-bencher-0.1+default-dev (>= 0.1.5),
  librust-docopt-1+default-dev,
  librust-env-logger-0.9+default-dev,
  librust-mio-0.8+default-dev,
@@ -134,7 +134,7 @@
 Depends:
  dh-cargo (>= 18),
  librust-base64-0.21+default-dev,
- librust-bencher-0.4+default-dev,
+ librust-bencher-0.1+default-dev (>= 0.1.5),
  librust-docopt-1+default-dev,
  librust-env-logger-0.9+default-dev,
  librust-mio-0.8+default-dev,
@@ -155,7 +155,7 @@
 Depends:
  dh-cargo (>= 18),
  librust-base64-0.21+default-dev,
- librust-bencher-0.4+default-dev,
+ librust-bencher-0.1+default-dev (>= 0.1.5),
  librust-docopt-1+default-dev,
  librust-env-logger-0.9+default-dev,
  librust-mio-0.8+default-dev,
@@ -176,7 +176,7 @@
 Depends:
  dh-cargo (>= 18),
  librust-base64-0.21+default-dev,
- librust-bencher-0.4+default-dev,
+ librust-bencher-0.1+default-dev (>= 0.1.5),
  librust-docopt-1+default-dev,
  librust-env-logger-0.9+default-dev,
  librust-log-0.4+default-dev,

Bug#1041908: rust-rustls-0.20: broken test dependencies.

[Peter Green]

Package: rust-rustls-0.20
Version: 0.20.8-7
Severity: serious
Tags: patch

rust-rustls-0.20 has test-dependencies that contain "0.20-0.20", these
are unsatisfiable and I assume are the result of a search and replace
gone wrong.

After replacing "0.20-0.20" with just "0.20" the autopkgtest passes
successfully.

Debdiff attatched, I may or may not NMU this later.diff -Nru rust-rustls-0.20-0.20.8/debian/changelog 
rust-rustls-0.20-0.20.8/debian/changelog
--- rust-rustls-0.20-0.20.8/debian/changelog2023-07-20 14:31:37.0 
+
+++ rust-rustls-0.20-0.20.8/debian/changelog2023-07-25 08:07:49.0 
+
@@ -1,3 +1,10 @@
+rust-rustls-0.20 (0.20.8-7.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix autopkgtest dependencies.
+
+ -- Peter Michael Green   Tue, 25 Jul 2023 08:07:49 +
+
 rust-rustls-0.20 (0.20.8-7) unstable; urgency=medium
 
   * no-changes source-only upload to enable testing migration
diff -Nru rust-rustls-0.20-0.20.8/debian/tests/control 
rust-rustls-0.20-0.20.8/debian/tests/control
--- rust-rustls-0.20-0.20.8/debian/tests/control2023-07-20 
14:30:29.0 +
+++ rust-rustls-0.20-0.20.8/debian/tests/control2023-07-25 
08:07:38.0 +
@@ -13,7 +13,7 @@
  librust-mio-0.8+net-dev,
  librust-mio-0.8+os-poll-dev,
  librust-regex-1+default-dev,
- librust-rustls-0.20-0.20-dev,
+ librust-rustls-0.20-dev,
  librust-rustls-native-certs-0.6+default-dev,
  librust-rustls-pemfile-1+default-dev,
  librust-rustversion-1-dev,
@@ -35,7 +35,7 @@
  librust-mio-0.8+net-dev,
  librust-mio-0.8+os-poll-dev,
  librust-regex-1+default-dev,
- librust-rustls-0.20-0.20+dangerous-configuration-dev,
+ librust-rustls-0.20+dangerous-configuration-dev,
  librust-rustls-native-certs-0.6+default-dev,
  librust-rustls-pemfile-1+default-dev,
  librust-serde-1+default-dev,
@@ -56,7 +56,7 @@
  librust-mio-0.8+net-dev,
  librust-mio-0.8+os-poll-dev,
  librust-regex-1+default-dev,
- librust-rustls-0.20-0.20+quic-dev,
+ librust-rustls-0.20+quic-dev,
  librust-rustls-native-certs-0.6+default-dev,
  librust-rustls-pemfile-1+default-dev,
  librust-serde-1+default-dev,
@@ -77,7 +77,7 @@
  librust-mio-0.8+net-dev,
  librust-mio-0.8+os-poll-dev,
  librust-regex-1+default-dev,
- librust-rustls-0.20-0.20+secret-extraction-dev,
+ librust-rustls-0.20+secret-extraction-dev,
  librust-rustls-native-certs-0.6+default-dev,
  librust-rustls-pemfile-dev,
  librust-serde-1+default-dev,
@@ -98,7 +98,7 @@
  librust-mio-0.8+net-dev,
  librust-mio-0.8+os-poll-dev,
  librust-regex-1+default-dev,
- librust-rustls-0.20-0.20+tls12-dev,
+ librust-rustls-0.20+tls12-dev,
  librust-rustls-native-certs-0.6+default-dev,
  librust-rustls-pemfile-dev,
  librust-serde-1+default-dev,
@@ -119,7 +119,7 @@
  librust-mio-0.8+net-dev,
  librust-mio-0.8+os-poll-dev,
  librust-regex-1+default-dev,
- librust-rustls-0.20-0.20+read-buf-dev,
+ librust-rustls-0.20+read-buf-dev,
  librust-rustls-native-certs-0.6+default-dev,
  librust-rustls-pemfile-dev,
  librust-rustversion-1-dev,
@@ -141,7 +141,7 @@
  librust-mio-0.8+net-dev,
  librust-mio-0.8+os-poll-dev,
  librust-regex-1+default-dev,
- librust-rustls-0.20-0.20-dev,
+ librust-rustls-0.20-dev,
  librust-rustls-native-certs-0.6+default-dev,
  librust-rustls-pemfile-1+default-dev,
  librust-serde-1+default-dev,
@@ -162,7 +162,7 @@
  librust-mio-0.8+net-dev,
  librust-mio-0.8+os-poll-dev,
  librust-regex-1+default-dev,
- librust-rustls-0.20-0.20+default-dev,
+ librust-rustls-0.20+default-dev,
  librust-rustls-native-certs-0.6+default-dev,
  librust-rustls-pemfile-1+default-dev,
  librust-serde-1+default-dev,
@@ -184,7 +184,7 @@
  librust-mio-0.8+net-dev,
  librust-mio-0.8+os-poll-dev,
  librust-regex-1+default-dev,
- librust-rustls-0.20-0.20+logging-dev,
+ librust-rustls-0.20+logging-dev,
  librust-rustls-native-certs-0.6+default-dev,
  librust-rustls-pemfile-1+default-dev,
  librust-serde-1+default-dev,

Bug#1041284: rust-ureq - please update to support new serde-json

[Peter Green]

Package: rust-ureq
Version: 2.7.0-1
Severity: serious

Hi.

A change to error reporting in serde_json 1.0.94, intended to prevent
duplicate error messages broke an error-handling code-path in ureq.

ureq's initial fix was to impose an upper limit on the version of
serde_json. Later a proper fix was made by adding a new method
to serde_json::error and changing ureq to use it.

I've just updated serde_json, please update ureq to match.