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

[Peter Green]

tags 1071297 +patch
thanks

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

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

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

[Peter Green]

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

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

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

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

[Peter Green]

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

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

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

[Peter Green]

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

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

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

Bug#1072816: sploitscan: Configuration files installed in Python modules directory

[Peter Wienemann]

Package: sploitscan
Version: 0.9.1-1
Severity: serious

Hi,

sploitscan installs configuration files in the system Python modules
directory:

/usr/lib/python3/dist-packages/sploitscan/templates/report_template.html
/usr/lib/python3/dist-packages/sploitscan/config.json

As per Debian Policy 10.7.2 configuration files must reside in /etc (or
in case of multiple configuration files it is suggested to put them in
a subdirectory named after the package).

Best regards,

Peter

Bug#1060573: nitrokey-app: Please switch Build-Depends to systemd-dev

[Peter Wienemann]

Hi,

I looked into this issue and it seems to me that the build dependency on 
udev is outdated since handling udev rules was migrated to libnitrokey 
(see [0]). Therefore I think that an easy fix for this issue is to 
remove the build dependency on udev.


Best regards,

Peter

[0] 
https://github.com/Nitrokey/nitrokey-app/commit/8b9480cae1dc5983a1b1e581b2de084cc08e3733

Bug#1067912: nitrokey-app: Update Build-Depends for the time64 library renames

[Peter Wienemann]

Hi,

I looked into this issue and it seems to me that the build dependency on 
libqt5concurrent5 is not necessary since it is already covered by 
qtbase5-dev. Thus I think that an easy fix for this issue is to remove 
libqt5concurrent5 from the build dependencies.


Best regards,

Peter

Bug#1071683: confget: autopkgtest regression in testing

[Peter Pentchev]

control: found -1 2.1.0-1

G'luck,
Peter


signature.asc
Description: PGP signature

Bug#1071683: confget: autopkgtest regression in testing

[Peter Pentchev]

control: reassign -1 feature-check
control: retitle -1 feature-check: Rust: -O fails on values starting with dashes
control: affects -1 src:confget
control: tag -1 + upstream

On Thu, May 23, 2024 at 06:17:48PM +, Graham Inggs wrote:
> Source: confget
> Version: 5.1.2-1
> Severity: serious
> User: debian...@lists.debian.org
> Usertags: regression
> 
> Hi Maintainer
> 
> Sometime around 2024-02-27, confget's autopkgtest regressed in testing
> [1].  I've copied what I hope is the relevant part of the log below.
> 
> Regards
> Graham
> 
> 
> [1] https://ci.debian.net/packages/c/confget/testing/amd64/
> 
> 
> 95s autopkgtest [19:08:12]: test feature-check: [---
> 95s error: unexpected argument '-q' found
> 95s
> 95s tip: to pass '-q' as a value, use '-- -q'
> 95s
> 95s Usage: feature-check [OPTIONS] [EXPRESSIONS]...
> 95s autopkgtest [19:08:12]: test feature-check: ---]

Thanks, this was exactly what was needed to reveal the problem.
The Rust implementation of feature-check that I switched the Debian
package to recently uses the Clap library for command-line options
parsing, and apparently Clap needs one more flag to be explicitly set on
the definitions of optional arguments to allow their values to start
with dashes.

Thanks a lot for reporting this; it actually affects all my Clap-using
Rust command-line utilities! (come to think of it, that includes
the Rust implementation of confget itself, although the Debian package
does not install that yet)

G'luck,
Peter

-- 
Peter Pentchev  r...@ringlet.net r...@debian.org pe...@morpheusly.com
PGP key:http://people.FreeBSD.org/~roam/roam.key.asc
Key fingerprint 2EE7 A7A5 17FC 124C F115  C354 651E EFB0 2527 DF13


signature.asc
Description: PGP signature

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#1070706: gtk4 - udebs broken.

[Peter Michael Green]

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

According to britney, gtk4's udebs are uninstallable.

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


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

Bug#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 +
+
 

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#1069554: [Pkg-pascal-devel] Bug#1069554: this is no bug in the package, bug in the script doing the rebuild?

[Peter Blackman]

On 24/04/2024 20:38, Rene Engelhard wrote:


My point is  that you don't need the alternative.



Hi Rene,

but it would surely be needed if someone wanted to build winff from 
source on armel?


Even though that case is perhaps unlikely.
I can't see how the alternative is doing any harm.

Regards,
Peter

Bug#1069554: [Pkg-pascal-devel] Bug#1069554: this is no bug in the package, bug in the script doing the rebuild?

[Peter B]

On 24/04/2024 20:02, Rene Engelhard wrote:



This bugreport now caused the following "fix" in winff:

Build-Depends-Indep:
 faketime,
 libreoffice-draw-nogui   | libreoffice-draw,
 libreoffice-writer-nogui | libreoffice-writer,

which I consider bad...



Hi Rene,

Why is it bad?  The nogui's are lighter dependencies than the gui packages.
One or the other is needed. Surely better to use the nogui if its available?


Regards,
Peter

P.S.  Relates to
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1065447

Bug#1069520: sbcl: FTBFS on armhf: make[1]: *** [debian/rules:53: override_dh_auto_build] Error 1

[Peter Van Eynde]

Hi,

Tested this and it’s due to the 64t transition. The grovelled data changed:

(sid_armhf-dchroot)pvaneynd@abel:~/sbcl-2.3.7$ diff -u 
./crossbuild-runner/backends/arm/stuff-groveled-from-headers.lisp 
output/stuff-groveled-from-headers.lisp
--- ./crossbuild-runner/backends/arm/stuff-groveled-from-headers.lisp   
2023-07-29 07:59:39.0 +
+++ output/stuff-groveled-from-headers.lisp 2023-07-29 07:59:39.0 
+
@@ -30,7 +30,7 @@
 (define-alien-type off-t (signed 64))
 (define-alien-type size-t (unsigned 32))
 (define-alien-type ssize-t (signed 32))
-(define-alien-type time-t (signed 32))
+(define-alien-type time-t (signed 64))
 (define-alien-type suseconds-t (signed 32))
 (define-alien-type uid-t (unsigned 32))
 ;; Types in src/runtime/wrap.h. See that file for explantion.
@@ -141,6 +141,7 @@
 (defconstant clock-process-cputime-id 2) ; #x2
 (defconstant clock-realtime-alarm 8) ; #x8
 (defconstant clock-realtime-coarse 5) ; #x5
+(defconstant clock-tai 11) ; #xb
 (defconstant clock-monotonic-coarse 6) ; #x6
 (defconstant clock-monotonic-raw 4) ; #x4
 (defconstant clock-boottime 7) ; #x7
@@ -149,11 +150,11 @@
 ;;; structures
 (define-alien-type nil
   (struct timeval
-  (tv-sec (signed 32))
-  (tv-usec (signed 32
+  (tv-sec (signed 64))
+  (tv-usec (signed 64
 (define-alien-type nil
   (struct timespec
-  (tv-sec (signed 32))
+  (tv-sec (signed 64))
   (tv-nsec (signed 32

I honestly don’t understand how to use 64-bit values on this arch, so I created 
https://bugs.launchpad.net/sbcl/+bug/2063340


Best regards, Peter

Bug#1069520: sbcl: FTBFS on armhf: make[1]: *** [debian/rules:53: override_dh_auto_build] Error 1

[Peter Van Eynde]

This looks a lot like a problem between the 
`OBSERVED-INTERNAL-REAL-TIME-DELTA-SEC` which is a word and the new 64-bit 
counters.

❯ git grep observed-internal-real-time-delta-sec
src/code/thread-structs.lisp:  #-64-bit (observed-internal-real-time-delta-sec 
0 :type sb-vm:word)
src/code/unix.lisp:   
(sb-thread::thread-observed-internal-real-time-delta-sec thr))

While the current sources still have:

❯ grep -A 2 -B 2 '(tv-sec' 
crossbuild-runner/backends/arm/stuff-groveled-from-headers.lisp
(define-alien-type nil
  (struct timeval
  (tv-sec (signed 32))
  (tv-usec (signed 32
(define-alien-type nil
  (struct timespec
  (tv-sec (signed 32))
  (tv-nsec (signed 32

I’m guessing that this is no longer the case on armhf anymore. I’m trying to 
test this on the porter box abel.debian.org.

Best regards, Peter

Bug#1069554: [Pkg-pascal-devel] Bug#1069554: winff: FTBFS on armel: build-dependency not installable: libreoffice-draw-nogui

[Peter B]

On 20/04/2024 21:28, Paul Gevers wrote:

Hi,

On 20-04-2024 3:22 p.m., Lucas Nussbaum wrote:

The following packages have unmet dependencies:
  sbuild-build-depends-main-dummy : Depends: libreoffice-draw-nogui 
but it is not installable

E: Unable to correct problems, you have held broken packages.
apt-get failed.


I recall rene mentioning that parts of lo are expected to not work on 
armel due to java being broken. Probably the best way forward is to 
request binary removal on armel.


Paul


Hi Paul,

Thanks for commenting.  Despite spitting out
   "Warning: failed to launch javaldx - java may not function correctly"

I gather soffice does not actually use Java, for pdf creation.
I hope to fix this by changing the build dependencies.

Cheers,
Peter

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#1066629: ucspi-tcp: FTBFS: tcpserver.c:143:29: error: implicit declaration of function ‘getpid’ [-Werror=implicit-function-declaration]

[Peter Pentchev]

On Fri, Apr 12, 2024 at 02:56:02PM -0600, Zixing Liu wrote:
> Package: ucspi-tcp
> Followup-For: Bug #1066629
> User: ubuntu-de...@lists.ubuntu.com
> Usertags: origin-ubuntu noble ubuntu-patch
> Control: tags -1 patch
> 
> Dear Maintainer,
> 
> In Ubuntu, the attached patch was applied to achieve the following:
> 
>   * debian/patches/0006-implicit-declarations.patch: Add missing
> includes and prototypes.  Closes LP: #2061188.
>   * debian/ipv6-support.patch: Refresh deferred patch.

OK, this is a little creepy :) I am staring at my work-in-progress update of
the ucspi-tcp package and I see a patch named 0006-implicit-declarations.patch 
and
an update to the ipv6-support one :) But mine was not completely done yet,
while yours seems to be.

(and yes, of course, the patch naming is logical)

> Thanks for considering the patch.

Thanks! I will probably upload a new ucspi-tcp version in a couple of days.

G'luck,
Peter

-- 
Peter Pentchev  r...@ringlet.net r...@debian.org p...@storpool.com
PGP key:http://people.FreeBSD.org/~roam/roam.key.asc
Key fingerprint 2EE7 A7A5 17FC 124C F115  C354 651E EFB0 2527 DF13


signature.asc
Description: PGP signature

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#1068608: tfortune dependencies unsatisfiable on 32-bit non-i386 architectures.

[Peter Michael Green]

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

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

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

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

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

[Peter Michael Green]

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

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

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

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

[Peter Michael Green]

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

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

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


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

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

[Peter Michael Green]

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

After being rebuilt for the time64 transition,
spice-client-gtk still depends on libusbredirhost1 and libusbredirparser1,
rather than the t64 versions of those libraries. As a result it is 
uninstallable on

architectures that are undergoing the time64 transition
(armel, armhf and some debian-ports architectures).

Ubuntu has applied a fix for this extracting the package names from 
dpkg-query.


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

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

libusbredirparser1t64.

Bug#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/be

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#1068226: libtrantor1, hardcoded dependency on libssl3

[Peter Michael Green]

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

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

Ubuntu removed the dependency with the following changelog
entry.

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

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

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

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

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

[Peter Michael Green]

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

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

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

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

[Peter Michael Green]

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

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


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

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

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

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

[Peter Michael Green]

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

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

Ubuntu already seem to have prepared a fix for this.

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

[Peter Michael Green]

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

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

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

[Peter Michael Green]

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

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

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

[Peter Michael Green]

tags 1066248 +patch
thanks

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

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

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

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


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

A debdiff is attatched.

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

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

[Peter Michael Green]

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

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

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

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

[Peter Michael Green]

tags 1066392 +patch
thanks

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

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

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

[Peter Michael Green]

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

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

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

[Peter Michael Green]

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

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

Bug#1068047: marked as pending in libarchive

[Peter Pentchev]

Control: tag -1 pending

Hello,

Bug #1068047 in libarchive reported by you has been fixed in the
Git repository and is awaiting an upload. You can see the commit
message below and you can check the diff of the fix at:

https://salsa.debian.org/debian/libarchive/-/commit/31fcf28c3be82824c34dd115c7465748adb2b787


Add the robust-error-reporting upstream patch

Closes: #1068047


(this message was generated automatically)
-- 
Greetings

https://bugs.debian.org/1068047

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#1067709: FTBFS in armel/armhf: some symbols disappeared

[Peter Pentchev]

Control: tag -1 + confirmed

On Tue, Mar 26, 2024 at 01:29:08AM +0500, Andrey Rakhmatullin wrote:
> Source: dante
> Version: 1.4.3+dfsg-1
> Severity: serious
> Tags: ftbfs
> 
> https://buildd.debian.org/status/fetch.php?pkg=dante=armhf=1.4.3%2Bdfsg-1=1710761774=0

Thanks for reporting this. I noticed it as soon as I uploaded this
version of dante, and I started looking into it; it is, at least partly,
fallout from the new "implicit function declarations are errors" GCC
option setting. FTR, I believe this is a good idea, no complaints here.
However, it turns out to be a bit more complicated than sprinkling
a couple of #include directives here and there; I will hopefully be
able to upload a fixed version within the next couple of days.

G'luck,
Peter

-- 
Peter Pentchev  r...@ringlet.net r...@debian.org p...@storpool.com
PGP key:http://people.FreeBSD.org/~roam/roam.key.asc
Key fingerprint 2EE7 A7A5 17FC 124C F115  C354 651E EFB0 2527 DF13


signature.asc
Description: PGP signature

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#1067027: python-cryptography build-dependencies unsatisfiable.

[Peter Michael Green]

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


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

but unstable has version 42.0.5-1

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

I will see what I can do.

This is blocking the time64 transition for python-cryptography.

Bug#1067010: libsquashfuse-dev: Incompatible pointer types on 32-bit architectures

[Peter Wienemann]

Package: libsquashfuse-dev
Version: 0.5.0-2
Severity: serious
Tags: ftbfs fixed-upstream
Affects: src:charliecloud

Dear Maintainer,

squashfuse suffers from an incompatible pointer type issue on 32-bit
architectures. Checking the latest build logs for armel, armhf and
i386 ([0], [1], [2]) one finds the following warning:

ll_main.c: In function ‘main’:
ll_main.c:164:41: warning: assignment to ‘void (*)(struct fuse_req *, 
fuse_ino_t,  uint64_t)’ {aka ‘void (*)(struct fuse_req *, long long unsigned 
int,  long long unsigned int)’} from incompatible pointer type ‘void (*)(struct 
fuse_req *, fuse_ino_t,  long unsigned int)’ {aka ‘void (*)(struct fuse_req *, 
long long unsigned int,  long unsigned int)’} [-Wincompatible-pointer-types]
  164 | sqfs_ll_ops.forget  = sqfs_ll_op_forget;
  | ^

This incompatibility leads to an FTBFS issue for the charliecloud
package on 32-bit architectures (see e. g. [3]) since it is built
using the -Werror option.

It seems that this issue was fixed in upstream release 0.5.1 [4].

More background information on this issue can be obtained from the
corresponding Charliecloud upstream issue and PR ([5], [6]).

Best regards,

Peter

[0] 
https://buildd.debian.org/status/fetch.php?pkg=squashfuse=armel=0.5.0-2%2Bb1=1707534165=0
[1] 
https://buildd.debian.org/status/fetch.php?pkg=squashfuse=armhf=0.5.0-2%2Bb1=1707538322=0
[2] 
https://buildd.debian.org/status/fetch.php?pkg=squashfuse=i386=0.5.0-2%2Bb1=1707537260=0
[3] 
https://buildd.debian.org/status/fetch.php?pkg=charliecloud=armel=0.37-2=1710594551=log
[4] 
https://github.com/vasi/squashfuse/commit/cb148fc1477ed676049b7891ebb6efc90b2c00ec
[5] https://github.com/hpc/charliecloud/issues/1858
[6] https://github.com/hpc/charliecloud/pull/1859

Bug#1065793: charliecloud: FTBFS on arm{el,hf}: ch_fuse.c:68:19: error: initialization of ‘void (*)(struct fuse_req *, fuse_ino_t, uint64_t)’ {aka ‘void (*)(struct fuse_req *, long long unsigned int,

[Peter Wienemann]

Control: reopen -1

It seems that the patch uploaded with 0.37-2 does not fix this issue.

See

https://buildd.debian.org/status/fetch.php?pkg=charliecloud=armel=0.37-2=1710594551=log

and

https://buildd.debian.org/status/fetch.php?pkg=charliecloud=armhf=0.37-2=1710594414=log

Therefore I reopen this bug.

Best regards,

Peter

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#1065793: marked as pending in charliecloud

[Peter Wienemann]

Control: tag -1 pending

Hello,

Bug #1065793 in charliecloud reported by you has been fixed in the
Git repository and is awaiting an upload. You can see the commit
message below and you can check the diff of the fix at:

https://salsa.debian.org/hpc-team/charliecloud/-/commit/5b9e616161bc9b2651081434b5fa5b017fdbc885


Add patch from upstream PR 1859 to fix FTBFS issue on arm{el,hf}

Closes: #1065793


(this message was generated automatically)
-- 
Greetings

https://bugs.debian.org/1065793

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#1063879: linux-image-6.1.0-18-amd64: nvidia-drivers 525.147.05 do not compile against linux-image 6.1.0-18

[Peter Hyman]

are-ipw2x00 20230210-5
ii firmware-ivtv 20230210-5
ii firmware-iwlwifi 20230210-5
ii firmware-libertas 20230210-5
ii firmware-linux-nonfree 20230210-5
ii firmware-misc-nonfree 20230210-5
ii firmware-myricom 20230210-5
ii firmware-netxen 20230210-5
ii firmware-qlogic 20230210-5
ii firmware-realtek 20230210-5
ii firmware-samsung 20230210-5
ii firmware-siano 20230210-5
ii firmware-ti-connectivity 20230210-5
pn xen-hypervisor 

-- no debconf information

--
Peter Hyman

Bug#1061034: Re Bug#1061034

[Peter B]

While Lazarus release (3.0+dfsg1-6) fixed the immediate problem
of ideconfig.lpk missing, lazbuilds still all fail, now with

"Note: (lazarus) Invalid Package Link: file 
"/usr/lib/lazarus/3.0/ide/packages/idedebugger/idedebugger.lpk" does not 
exist."


Builds fail on the firts missing (lazarus) package. Providing 
idedebugger.lpk alone may not be sufficient to fix builds


lazarus packages fail to build unless lazarus_src is included in build 
depends.

Affects c-evo-dh, ddrescueview, view3dscene, winff, doublecmd

Bug#1024830: ERROR: Unable to connect to servers to test latency.

[Peter Wienemann]

Hi,

speedtest-cli 2.1.3-2 works for me on Bookworm.

Best regards,

Peter

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 

Bug#1058286: marked as pending in ncrack

[Peter Wienemann]

Control: tag -1 pending

Hello,

Bug #1058286 in ncrack reported by you has been fixed in the
Git repository and is awaiting an upload. You can see the commit
message below and you can check the diff of the fix at:

https://salsa.debian.org/pkg-security-team/ncrack/-/commit/f4d07967032a4c9142532857b2d7b09f2ef7dc49


Allow zlib versions with two-part version number (Closes: #1058286)


(this message was generated automatically)
-- 
Greetings

https://bugs.debian.org/1058286

Bug#1059812: elan - dependency updates.

[Peter Michael Green]

Package: elan
Version: 3.0.0-1
Severity: serious

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

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

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

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

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

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

[Peter Michael Green]

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

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

Unfortunately they still fail on s390x.



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

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


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

Bug#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 +

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.