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

[Peter Michael Green]

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

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

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

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

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

[Peter Green]

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

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

[Peter Green]

Package: rust-rio
Version: 0.8.3-3

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

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

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

Bug#1071741: RFS: winff/1.6.4+dfsg-2 -- graphical video and audio batch converter using ffmpeg or avconv

[Peter B]

Package: sponsorship-requests
Severity: normal

Dear mentors,

I am looking for a sponsor for my package "winff":

 * Package name : winff
   Version  : 1.6.4+dfsg-2
   Upstream contact : Matthew Weatherford 
 * URL  : https://github.com/WinFF/winff
 * License  : GFDL-1.3+, GPL-2+, GPL-3+
 * Vcs  : https://salsa.debian.org/pascal-team/winff
   Section  : video

The source builds the following binary packages:

  winff - graphical video and audio batch converter using ffmpeg or avconv
  winff-qt - Qt variant of winff
  winff-data - winff data files
  winff-doc - winff documentation

To access further information about this package, please visit the 
following URL:


  https://mentors.debian.net/package/winff/

Alternatively, you can download the package with 'dget' using this command:

  dget -x 
https://mentors.debian.net/debian/pool/main/w/winff/winff_1.6.4+dfsg-2.dsc


Changes since the last upload:

 winff (1.6.4+dfsg-2) unstable; urgency=medium
 .
   * Fix reproducibility for locales & timezone

Regards,
--
  Peter Blackman

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#1071240: rust-ahash, autopkgtest failure.

[peter green]

Package: rust-ahash
Version: 0.8.11-2

rust-hashbrown was recently updated to 0.14.5, and as a result the autopkgtest
for rust-ahash is failing.

https://ci.debian.net/packages/r/rust-ahash/testing/ppc64el/46811732/


 97s error: failed to select a version for the requirement `hashbrown = ">=0.12.3, 
<=0.14.3"`
 97s candidate versions found which didn't match: 0.14.5


Please adjust the dev-dependency to allow all 0.14.x versions, a debdiff
doing that is attatched.diff -Nru rust-ahash-0.8.11/debian/changelog rust-ahash-0.8.11/debian/changelog
--- rust-ahash-0.8.11/debian/changelog  2024-03-18 05:44:43.0 +
+++ rust-ahash-0.8.11/debian/changelog  2024-05-17 03:52:01.0 +
@@ -1,3 +1,10 @@
+rust-ahash (0.8.11-2.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Allow all 0.14.x versions of rust-hashbrown.
+
+ -- Peter Michael Green   Fri, 17 May 2024 03:52:01 +
+
 rust-ahash (0.8.11-2) unstable; urgency=medium
 
   * fix or tighten patch 1002
diff -Nru rust-ahash-0.8.11/debian/patches/2001_hashbrown.patch 
rust-ahash-0.8.11/debian/patches/2001_hashbrown.patch
--- rust-ahash-0.8.11/debian/patches/2001_hashbrown.patch   2024-03-17 
17:00:00.0 +
+++ rust-ahash-0.8.11/debian/patches/2001_hashbrown.patch   2024-05-17 
03:52:01.0 +
@@ -11,7 +11,7 @@
  pcg-mwc = "0.2.1"
  serde_json = "1.0.59"
 -hashbrown = "0.14.3"
-+hashbrown = ">= 0.12.3, <= 0.14.3"
++hashbrown = ">= 0.12.3, < 0.15"
  smallvec = "1.13.1"
  
  [package.metadata.docs.rs]
diff -Nru rust-ahash-0.8.11/debian/patches/2001_pcg-mwc.patch 
rust-ahash-0.8.11/debian/patches/2001_pcg-mwc.patch
--- rust-ahash-0.8.11/debian/patches/2001_pcg-mwc.patch 2024-03-17 
17:05:31.0 +
+++ rust-ahash-0.8.11/debian/patches/2001_pcg-mwc.patch 2024-05-17 
03:52:01.0 +
@@ -12,7 +12,7 @@
  rand = "0.8.5"
 -pcg-mwc = "0.2.1"
  serde_json = "1.0.59"
- hashbrown = ">= 0.12.3, <= 0.14.3"
+ hashbrown = ">= 0.12.3, < 0.15"
  smallvec = "1.13.1"
 --- a/tests/map_tests.rs
 +++ b/tests/map_tests.rs
diff -Nru rust-ahash-0.8.11/debian/patches/2001_smallvec.patch 
rust-ahash-0.8.11/debian/patches/2001_smallvec.patch
--- rust-ahash-0.8.11/debian/patches/2001_smallvec.patch2024-03-17 
17:13:21.0 +
+++ rust-ahash-0.8.11/debian/patches/2001_smallvec.patch2024-05-17 
03:52:01.0 +
@@ -10,7 +10,7 @@
 @@ -99,7 +99,7 @@
  rand = "0.8.5"
  serde_json = "1.0.59"
- hashbrown = ">= 0.12.3, <= 0.14.3"
+ hashbrown = ">= 0.12.3, < 0.15"
 -smallvec = "1.13.1"
 +smallvec = "1.11.2"
  

Bug#1071212: rust-roadmap - upcoming rust-serde-yaml update.

[Peter Green]

Package: rust-roadmap
Version: 0.6.0-2

I hope to update rust-serde-yaml to 0.9 in unstable soon
(this was requested a long time ago, but squeekboard
stalled the process)

rust-serde-yaml 0.9 is available in experimental. I
have built a version of rust-roadmap with the dependency
bumped and was able to build it and run it's
autopkgtests succesfully.

The debdiff I used for testing is attached.diff -Nru rust-roadmap-0.6.0/debian/changelog 
rust-roadmap-0.6.0/debian/changelog
--- rust-roadmap-0.6.0/debian/changelog 2024-01-14 19:47:20.0 +
+++ rust-roadmap-0.6.0/debian/changelog 2024-05-16 08:34:24.0 +
@@ -1,3 +1,10 @@
+rust-roadmap (0.6.0-2.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Bump serde-yaml to 0.9
+
+ -- Peter Michael Green   Thu, 16 May 2024 08:34:24 +
+
 rust-roadmap (0.6.0-2) unstable; urgency=medium
 
   * update copyright info: update coverage
diff -Nru rust-roadmap-0.6.0/debian/control rust-roadmap-0.6.0/debian/control
--- rust-roadmap-0.6.0/debian/control   2024-01-13 18:57:13.0 +
+++ rust-roadmap-0.6.0/debian/control   2024-05-16 08:34:24.0 +
@@ -9,7 +9,7 @@
  librust-anyhow-1+default-dev ,
  librust-serde-1+default-dev ,
  librust-serde-1+derive-dev ,
- librust-serde-yaml-0.8+default-dev ,
+ librust-serde-yaml-0.9+default-dev ,
  librust-textwrap-0.16+default-dev ,
  librust-thiserror-1+default-dev ,
  libstring-shellquote-perl,
@@ -26,7 +26,7 @@
  librust-anyhow-1+default-dev,
  librust-serde-1+default-dev,
  librust-serde-1+derive-dev,
- librust-serde-yaml-0.8+default-dev,
+ librust-serde-yaml-0.9+default-dev,
  librust-textwrap-0.16+default-dev,
  librust-thiserror-1+default-dev,
  ${misc:Depends},
diff -Nru rust-roadmap-0.6.0/debian/patches/1002_serde-yaml.patch 
rust-roadmap-0.6.0/debian/patches/1002_serde-yaml.patch
--- rust-roadmap-0.6.0/debian/patches/1002_serde-yaml.patch 1970-01-01 
00:00:00.0 +
+++ rust-roadmap-0.6.0/debian/patches/1002_serde-yaml.patch 2024-05-16 
08:27:50.0 +
@@ -0,0 +1,12 @@
+Index: rust-roadmap-0.6.0/Cargo.toml
+===
+--- rust-roadmap-0.6.0.orig/Cargo.toml
 rust-roadmap-0.6.0/Cargo.toml
+@@ -12,6 +12,6 @@ repository = "https://gitlab.com/larswir
+ [dependencies]
+ anyhow = "1"
+ serde = { version = "1.0.134", features = ["derive"] }
+-serde_yaml = "0.8"
++serde_yaml = "0.9"
+ textwrap = ">= 0.15, <= 0.16"
+ thiserror = "1"
diff -Nru rust-roadmap-0.6.0/debian/patches/series 
rust-roadmap-0.6.0/debian/patches/series
--- rust-roadmap-0.6.0/debian/patches/series2023-12-29 19:06:14.0 
+
+++ rust-roadmap-0.6.0/debian/patches/series2024-05-16 08:14:27.0 
+
@@ -1 +1,2 @@
 1001_textwrap.patch
+1002_serde-yaml.patch

Bug#1071155: passwordsafe: crash on Manage>>Password policies, SIGSEGV, no message

[Peter Gervai]

Package: passwordsafe
Version: 1.17.0+dfsg-1+b3
Severity: normal
Tags: upstream

I have an oldish db, v3.14, works well, updates, etc.

However selecting the menu `Password policies` immediately crashes passwdsafe, 
with no message.
strace shows nothing of interest (or, in fact, anything apart from sigsegv).
gdb gives a possibly useful stack trace though:

Thread 1 "pwsafe" received signal SIGSEGV, Segmentation fault.

#0  0x557e26a8 in  ()
#1  0x77829fa2 in 
wxEvtHandler::ProcessEventIfMatchesId(wxEventTableEntryBase const&, 
wxEvtHandler*, wxEvent&) ()
at /lib/x86_64-linux-gnu/libwx_baseu-3.2.so.0
#2  0x7782a16b in wxEventHashTable::HandleEvent(wxEvent&, 
wxEvtHandler*) () at /lib/x86_64-linux-gnu/libwx_baseu-3.2.so.0
#3  0x7782a7dd in wxEvtHandler::TryHereOnly(wxEvent&) () at 
/lib/x86_64-linux-gnu/libwx_baseu-3.2.so.0
#4  0x7782a85e in wxEvtHandler::ProcessEventLocally(wxEvent&) () at 
/lib/x86_64-linux-gnu/libwx_baseu-3.2.so.0
#5  0x7782a961 in wxEvtHandler::ProcessEvent(wxEvent&) () at 
/lib/x86_64-linux-gnu/libwx_baseu-3.2.so.0
#6  0x7719232f in wxWindowBase::TryAfter(wxEvent&) () at 
/lib/x86_64-linux-gnu/libwx_gtk3u_core-3.2.so.0
#7  0x771ff396 in wxScrollHelperEvtHandler::ProcessEvent(wxEvent&) () 
at /lib/x86_64-linux-gnu/libwx_gtk3u_core-3.2.so.0
#8  0x7723e0cd in wxGrid::DoSendEvent(wxGridEvent&) () at 
/lib/x86_64-linux-gnu/libwx_gtk3u_core-3.2.so.0
#9  0x7723e59b in wxGrid::SendEvent(int, int, int, wxString const&) () 
at /lib/x86_64-linux-gnu/libwx_gtk3u_core-3.2.so.0
#10 0x7724ca59 in wxGrid::SetCurrentCell(wxGridCellCoords const&) () at 
/lib/x86_64-linux-gnu/libwx_gtk3u_core-3.2.so.0
#11 0x7724cc25 in wxGrid::UpdateCurrentCellOnRedim() () at 
/lib/x86_64-linux-gnu/libwx_gtk3u_core-3.2.so.0
#12 0x7724ce5c in wxGrid::SetTable(wxGridTableBase*, bool, 
wxGrid::wxGridSelectionModes) ()
at /lib/x86_64-linux-gnu/libwx_gtk3u_core-3.2.so.0
#13 0x557d9be2 in  ()
#14 0x5577d7f5 in  ()
#15 0x7782a810 in wxEvtHandler::TryHereOnly(wxEvent&) () at 
/lib/x86_64-linux-gnu/libwx_baseu-3.2.so.0
#16 0x7782a85e in wxEvtHandler::ProcessEventLocally(wxEvent&) () at 
/lib/x86_64-linux-gnu/libwx_baseu-3.2.so.0
#17 0x7782a961 in wxEvtHandler::ProcessEvent(wxEvent&) () at 
/lib/x86_64-linux-gnu/libwx_baseu-3.2.so.0
#18 0x7782ba85 in wxEvtHandler::ProcessPendingEvents() () at 
/lib/x86_64-linux-gnu/libwx_baseu-3.2.so.0
#19 0x776aac8a in wxAppConsoleBase::ProcessPendingEvents() () at 
/lib/x86_64-linux-gnu/libwx_baseu-3.2.so.0
#20 0x76f65675 in wxApp::DoIdle() () at 
/lib/x86_64-linux-gnu/libwx_gtk3u_core-3.2.so.0
#21 0x76f65757 in  () at /lib/x86_64-linux-gnu/libwx_gtk3u_core-3.2.so.0
#22 0x755b6e1f in  () at /lib/x86_64-linux-gnu/libglib-2.0.so.0
#23 0x755b8ea7 in  () at /lib/x86_64-linux-gnu/libglib-2.0.so.0
#24 0x755b97af in g_main_loop_run () at 
/lib/x86_64-linux-gnu/libglib-2.0.so.0
#25 0x75dfd65d in gtk_main () at /lib/x86_64-linux-gnu/libgtk-3.so.0
#26 0x76f82995 in wxGUIEventLoop::DoRun() () at 
/lib/x86_64-linux-gnu/libwx_gtk3u_core-3.2.so.0
#27 0x776e5d11 in wxEventLoopBase::Run() () at 
/lib/x86_64-linux-gnu/libwx_baseu-3.2.so.0
#28 0x776ac0ff in wxAppConsoleBase::MainLoop() () at 
/lib/x86_64-linux-gnu/libwx_baseu-3.2.so.0
#29 0x7773230b in wxEntry(int&, wchar_t**) () at 
/lib/x86_64-linux-gnu/libwx_baseu-3.2.so.0
#30 0x556d2ccc in  ()
#31 0x76642c8a in __libc_start_call_main 
(main=main@entry=0x556d2ca0, argc=argc@entry=1, 
argv=argv@entry=0x7fffdce8)
at ../sysdeps/nptl/libc_start_call_main.h:58
#32 0x76642d45 in __libc_start_main_impl
(main=0x556d2ca0, argc=1, argv=0x7fffdce8, init=, 
fini=, rtld_fini=, stack_end=0x7fffdcd8) at 
../csu/libc-start.c:360
#33 0x556ddbf1 in  ()



-- System Information:
Debian Release: trixie/sid
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 
'unstable'), (500, 'testing'), (500, 'stable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 6.1.0-18-amd64 (SMP w/8 CPU threads; PREEMPT)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_WARN, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=en_US.UTF8, LC_CTYPE=en_US.UTF8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash (but the user have tricked the system to 
use bash anyway)
Init: sysvinit (via /sbin/init) (yes, no systemd crap here)
LSM: AppArmor: enabled

Versions of packages passwordsafe depends on:
ii  libc62.38-11
ii  libgcc-s113.2.0-4
ii  libmagic1t64 1:5.45-3
ii  libqrencode4 4.1.1-1
ii  libstdc++6   13.2.0-4
ii  libuuid1 2.40-8
ii  libwxbase3.2-1t643.2.4+dfsg-5
ii  libwxgtk3.2-1t64 3.2.4+dfsg-5
ii  libx11-6  

Bug#1071054: RM: librust-bindgen+clap-dev librust-bindgen+default-dev librust-bindgen+env-logger-dev librust-bindgen+log-dev librust-bindgen+logging-dev librust-bindgen+runtime-dev librust-bindgen+sta

[Peter Green]

Package: ftp.debian.org

Please remove the cruft binary packages librust-bindgen+clap-dev 
librust-bindgen+default-dev librust-bindgen+env-logger-dev 
librust-bindgen+log-dev librust-bindgen+logging-dev librust-bindgen+runtime-dev 
librust-bindgen+static-dev librust-bindgen+which-dev

These packages were formerly physical packages, but are now virtual packages.
Unfortunately dak's dependency checks do not take proper account of virtual
packages, which leads dak to incorrectly believe that removing these packages
will cause broken dependencies.

While I am not 100% sure, I belive the presense of these cruft packages is
the cause of superious puipart's regression reports from britney which are
preventing the new version of rust-bindgen from migrating to testing.

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

[peter green]

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


The relavent change is.


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


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

Bug#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#966621: Make /tmp/ a tmpfs and cleanup /var/tmp/ on a timer by default [was: Re: systemd: tmpfiles.d not cleaning /var/tmp by default]

[Peter Pentchev]

On Tue, May 07, 2024 at 10:38:14AM +0200, Carsten Leonhardt wrote:
> Luca Boccassi  writes:
> 
> > Defaults are defaults, they are trivially and fully overridable where
> > needed if needed. Especially container and VM managers these days can
> > super trivially override them via SMBIOS Type11 strings or
> > Credentials, ephemerally and without changing the guest image at all.
> 
> That argument goes both ways and I prefer safe defaults. What
> you/upstream propose are unsafe defaults, as was shown by several
> comments in this thread. Whoever wants the unsafe defaults of deleting
> old files and risking OOM situations can than "trivially and fully
> override" the safe defaults.

So I've been wondering for a couple of days now, following this thread...
...would it be a good idea to make this a debconf prompt, high priority,
default "yes", so that it is activated on new automatically installed
systems, but people who upgrade their current Debian installations can
choose to keep the old behavior?

I do realize that more debconf prompts are not always desirable, and
such decisions must be taken on a case-by-case basis, so... yeah.

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#1070657: RFS: c-evo-dh/1.12-1 -- Empire Building Game, C-evo Distant Horizon

[Peter Blackman]

Package: sponsorship-requests
Severity: normal

Dear mentors,

I am looking for a sponsor for my package "c-evo-dh":

 * Package name : c-evo-dh
   Version  : 1.12-1
   Upstream contact : Peter 
 * URL  : https://sourceforge.net/projects/c-evo-eh/
 * License  : CC-BY-3.0, CC-BY-SA-3.0-US, GPL-2+, CC0-1.0
 * Vcs  : https://salsa.debian.org/PeterB/c-evo-dh
   Section  : games

The source builds the following binary packages:

  c-evo-dh-gtk2  - Empire Building Game (GTK2), C-evo: Distant Horizon
  c-evo-dh-stdai - Empire Building Game (AI module), C-evo: Distant Horizon
  c-evo-dh-data  - Empire Building Game (data files), C-evo: Distant 
Horizon


To access further information about this package, please visit the 
following URL:

  https://mentors.debian.net/package/c-evo-dh/

Alternatively, you can download the package with 'dget' using this command:
  dget -x 
https://mentors.debian.net/debian/pool/main/c/c-evo-dh/c-evo-dh_1.12-1.dsc


Changes since the last upload:

 c-evo-dh (1.12-1) unstable; urgency=medium
 .
   * New Upstream Release
   * Update d/copyright
   * Use mpg123 for sound (Closes: #1067844)
   * Standards now 4.7.0 (No changes)
   * Override 32bit shared library warnings
   * Use git tags instead of tarball in d/watch

Regards,
 Peter Blackman

Bug#1065459: rust-smol - upcoming rust-nix update.

[Peter Green]

On 04/03/2024 23:24, Peter Green wrote:

Package: rust-smol

I am currently preparing to update the rust-nix pacakge to version 0.27.

The smol crate has a dev-dependency on the nix crate, which the Debian
packaging translates to build and autopkgtest dependencies. After
relaxing the dependencies to allow the new version.

The new rust-nix package is available in experimental. A debdiff
is attached.

I have now uploaded the new version of nix to unstable and uploaded
this as a NMU, final debdiff is attached.

diff -Nru rust-smol-1.3.0/debian/changelog rust-smol-1.3.0/debian/changelog
--- rust-smol-1.3.0/debian/changelog2024-02-01 19:28:09.0 +
+++ rust-smol-1.3.0/debian/changelog2024-05-02 17:16:46.0 +
@@ -1,3 +1,10 @@
+rust-smol (1.3.0-5.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Allow building with nix 0.27 (Closes: #1065459).
+
+ -- Peter Michael Green   Thu, 02 May 2024 17:16:46 +
+
 rust-smol (1.3.0-5) unstable; urgency=medium
 
   * add patches 2001_async_* to accept older crates;
diff -Nru rust-smol-1.3.0/debian/control rust-smol-1.3.0/debian/control
--- rust-smol-1.3.0/debian/control  2024-02-01 19:14:29.0 +
+++ rust-smol-1.3.0/debian/control  2024-05-02 17:16:01.0 +
@@ -24,7 +24,7 @@
  librust-hyper-0.14+stream-dev ,
  librust-inotify-0-dev (<< 0.11) ,
  librust-native-tls-0.2+default-dev ,
- librust-nix-0+default-dev (<< 0.27) ,
+ librust-nix-0+default-dev (<< 0.28) ,
  librust-nix-0+default-dev (>= 0.23) ,
  librust-signal-hook-0.3+default-dev ,
  librust-tempfile-3+default-dev ,
diff -Nru rust-smol-1.3.0/debian/patches/1001_nix.patch 
rust-smol-1.3.0/debian/patches/1001_nix.patch
--- rust-smol-1.3.0/debian/patches/1001_nix.patch   2023-08-20 
08:25:51.0 +
+++ rust-smol-1.3.0/debian/patches/1001_nix.patch   2024-05-02 
17:16:01.0 +
@@ -10,7 +10,7 @@
  [target.'cfg(target_os = "linux")'.dev-dependencies]
  inotify = { version = "0.10", default-features = false }
 -nix = "0.24"
-+nix = ">= 0.24, < 0.27"
++nix = ">= 0.24, < 0.28"
  timerfd = "1"
  
  [target.'cfg(windows)'.dev-dependencies]
diff -Nru rust-smol-1.3.0/debian/patches/2001_inotify.patch 
rust-smol-1.3.0/debian/patches/2001_inotify.patch
--- rust-smol-1.3.0/debian/patches/2001_inotify.patch   2023-08-20 
08:25:51.0 +
+++ rust-smol-1.3.0/debian/patches/2001_inotify.patch   2024-05-02 
17:16:01.0 +
@@ -13,5 +13,5 @@
  [target.'cfg(target_os = "linux")'.dev-dependencies]
 -inotify = { version = "0.10", default-features = false }
 +inotify = { version = ">= 0.9, < 0.11", default-features = false }
- nix = ">= 0.24, < 0.27"
+ nix = ">= 0.24, < 0.28"
  timerfd = "1"
diff -Nru rust-smol-1.3.0/debian/patches/2001_windows.patch 
rust-smol-1.3.0/debian/patches/2001_windows.patch
--- rust-smol-1.3.0/debian/patches/2001_windows.patch   2023-08-20 
08:25:51.0 +
+++ rust-smol-1.3.0/debian/patches/2001_windows.patch   2024-05-02 
17:16:01.0 +
@@ -8,7 +8,7 @@
 +++ b/Cargo.toml
 @@ -50,6 +50,3 @@
  inotify = { version = "0.10", default-features = false }
- nix = ">= 0.24, < 0.27"
+ nix = ">= 0.24, < 0.28"
  timerfd = "1"
 -
 -[target.'cfg(windows)'.dev-dependencies]

Bug#1064580: netavark - diff for NMU 1.4.0-4.1

[Peter Green]

A debdiff is attatched, if I get no response I will likely NMU this when the
new rust-nix is uploaded to unstable.


As promised I have uploaded this.



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


This fit the zero-day NMU guidelines, and my NMU would have FTBFS if I
didn't fix it. So I added a fix for is to the NMU.

Final debdiff is attatched.diff -Nru netavark-1.4.0/debian/changelog netavark-1.4.0/debian/changelog
--- netavark-1.4.0/debian/changelog 2023-09-06 22:46:22.0 +
+++ netavark-1.4.0/debian/changelog 2024-05-02 17:08:20.0 +
@@ -1,3 +1,11 @@
+netavark (1.4.0-4.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Apply upstream patch for new version of rust-nix (Closes: #1064580)
+  * Relax cargo dependency on sysctl crate (Closes: #1069350)
+
+ -- Peter Michael Green   Thu, 02 May 2024 17:08:20 +
+
 netavark (1.4.0-4) unstable; urgency=medium
 
   [ Peter Michael Green ]
diff -Nru netavark-1.4.0/debian/control netavark-1.4.0/debian/control
--- netavark-1.4.0/debian/control   2023-09-06 22:46:22.0 +
+++ netavark-1.4.0/debian/control   2024-05-02 16:54:53.0 +
@@ -18,7 +18,7 @@
  librust-libc-dev,
  librust-log-dev,
  librust-netlink-packet-route-0.17-dev,
- librust-nix-dev,
+ librust-nix-0.27-dev,
  librust-rand-dev,
  librust-rtnetlink-dev,
  librust-serde+derive-dev,
diff -Nru netavark-1.4.0/debian/patches/nix-0.27.patch 
netavark-1.4.0/debian/patches/nix-0.27.patch
--- netavark-1.4.0/debian/patches/nix-0.27.patch1970-01-01 
00:00:00.0 +
+++ netavark-1.4.0/debian/patches/nix-0.27.patch2024-05-02 
17:02:52.0 +
@@ -0,0 +1,42 @@
+This patch is based on the upstream commit described below, adapted for use
+in the Debian package by Peter Michael Green.
+
+commit 61b8e62f4205b1b2609054bb0d07771b56a5ef9c
+Author: Paul Holzinger 
+Date:   Mon Sep 11 18:13:13 2023 +0200
+
+bump nix to 0.27.1
+
+The nix crate removes all features by default so we need to explicitly
+list what we use.
+Second, the io API's changed and all use the AsFd trait now. This is
+great for IO safety but will require larger changes to migrate from
+RawFd. Thus I went the easy way and use unsafe (not really unsafe here)
+and construct and a new BorrowedFd object (which impl AsFd) for the
+setns call.
+
+Signed-off-by: Paul Holzinger 
+
+Index: netavark-1.4.0/Cargo.toml
+===
+--- netavark-1.4.0.orig/Cargo.toml
 netavark-1.4.0/Cargo.toml
+@@ -34,1 +34,1 @@ serde_json = "1"
+-nix = "0.26.1"
++nix = { version = "0.27.1", features = ["sched", "signal", "user", "fs"] }
+Index: netavark-1.4.0/src/network/core_utils.rs
+===
+--- netavark-1.4.0.orig/src/network/core_utils.rs
 netavark-1.4.0/src/network/core_utils.rs
+@@ -260,7 +260,10 @@ impl CoreUtils {
+ }
+ 
+ pub fn join_netns(fd: RawFd) -> NetavarkResult<()> {
+-match sched::setns(fd, sched::CloneFlags::CLONE_NEWNET) {
++match sched::setns(
++unsafe { BorrowedFd::borrow_raw(fd) },
++sched::CloneFlags::CLONE_NEWNET,
++) {
+ Ok(_) => Ok(()),
+ Err(e) => Err(NetavarkError::wrap(
+ "setns",
diff -Nru netavark-1.4.0/debian/patches/relax-deps.patch 
netavark-1.4.0/debian/patches/relax-deps.patch
--- netavark-1.4.0/debian/patches/relax-deps.patch  2023-09-06 
22:46:22.0 +
+++ netavark-1.4.0/debian/patches/relax-deps.patch  2024-05-02 
16:59:29.0 +
@@ -19,7 +19,7 @@
 +serde = { version = "1", features = ["derive"], optional = true }
 +serde-value = "0.7"
 +serde_json = "1"
-+sysctl = "0.4"
++sysctl = ">= 0.4"
  url = "2.3.1"
  zbus = { version = "3.6.1" }
  nix = "0.26.1"
diff -Nru netavark-1.4.0/debian/patches/series 
netavark-1.4.0/debian/patches/series
--- netavark-1.4.0/debian/patches/series2023-09-06 22:46:22.0 
+
+++ netavark-1.4.0/debian/patches/series2024-05-02 16:54:53.0 
+
@@ -3,3 +3,4 @@
 debian-paths.patch
 netlink-0.5.patch
 netlink-0.7.patch
+nix-0.27.patch

Bug#1064480: aardvark-dns - upcoming rust-nix update.

[Peter Green]

On 29/02/2024 12:22, Marc Dequènes (duck) wrote:


I do not have a proper Internet connexion in my new Pond yet so I'd gladly let you upload it :-). 

Done

Final debdiff is attatched.diff -Nru greetd-0.9.0/debian/changelog greetd-0.9.0/debian/changelog
--- greetd-0.9.0/debian/changelog   2023-12-21 14:17:58.0 +
+++ greetd-0.9.0/debian/changelog   2024-05-02 16:30:23.0 +
@@ -1,3 +1,11 @@
+greetd (0.9.0-6.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Add upstream patch for nix 0.27 (Closes: #1064480)
+  * Tighten build-dependency on nix.
+
+ -- Peter Michael Green   Thu, 02 May 2024 16:30:23 +
+
 greetd (0.9.0-6) unstable; urgency=medium
 
   * Relax dependency on rpassword (Closes: #1057931).
diff -Nru greetd-0.9.0/debian/control greetd-0.9.0/debian/control
--- greetd-0.9.0/debian/control 2023-12-21 14:17:58.0 +
+++ greetd-0.9.0/debian/control 2024-05-02 16:26:04.0 +
@@ -6,7 +6,7 @@
  debhelper-compat (= 13),
  dh-cargo,
 # greetd & greetd_ipc
- librust-nix-dev (>= 0.25),
+ librust-nix-0.27-dev,
  librust-pam-sys-dev (>= 0.5.6),
  librust-users-dev (>= 0.11.0),
  librust-serde-derive-dev (>= 1.0),
diff -Nru greetd-0.9.0/debian/patches/nix-0.27.patch 
greetd-0.9.0/debian/patches/nix-0.27.patch
--- greetd-0.9.0/debian/patches/nix-0.27.patch  1970-01-01 00:00:00.0 
+
+++ greetd-0.9.0/debian/patches/nix-0.27.patch  2024-05-02 16:26:04.0 
+
@@ -0,0 +1,43 @@
+This patch is based on the upstream commit described below, adapted for use
+in the Debian package by Peter Michael Green.
+
+commit 161218164d366482ab7fab9dcc59cbd40623ac2c
+Author: Kenny Levinsen 
+Date:   Wed Feb 7 15:14:24 2024 +0100
+
+Update dependencies
+
+diff --git a/greetd/Cargo.toml b/greetd/Cargo.toml
+index c206ac1..3b1446f 100644
+--- a/greetd/Cargo.toml
 b/greetd/Cargo.toml
+@@ -14,1 +14,1 @@ repository = "https://git.sr.ht/~kennylevinsen/greetd/;
+-nix = "0.26"
++nix = { version = "0.27", features = ["ioctl", "signal", "user", "fs", 
"mman"] }
+diff --git a/greetd/src/main.rs b/greetd/src/main.rs
+index b88c6dc..92a53d4 100644
+--- a/greetd/src/main.rs
 b/greetd/src/main.rs
+@@ -22,7 +22,7 @@ use crate::{error::Error, session::worker};
+ 
+ async fn session_worker_main(config: config::Config) -> Result<(), Error> {
+ let raw_fd = config.internal.session_worker as RawFd;
+-let mut cur_flags = unsafe { FdFlag::from_bits_unchecked(fcntl(raw_fd, 
FcntlArg::F_GETFD)?) };
++let mut cur_flags = FdFlag::from_bits_retain(fcntl(raw_fd, 
FcntlArg::F_GETFD)?);
+ cur_flags.insert(FdFlag::FD_CLOEXEC);
+ fcntl(raw_fd, FcntlArg::F_SETFD(cur_flags))?;
+ let sock = unsafe { UnixDatagram::from_raw_fd(raw_fd) };
+diff --git a/greetd/src/session/interface.rs b/greetd/src/session/interface.rs
+index f1d3f04..b31f47f 100644
+--- a/greetd/src/session/interface.rs
 b/greetd/src/session/interface.rs
+@@ -99,8 +99,7 @@ impl Session {
+ UnixDatagram::pair().map_err(|e| format!("could not create pipe: 
{}", e))?;
+ 
+ let raw_child = childfd.as_raw_fd();
+-let mut cur_flags =
+-unsafe { FdFlag::from_bits_unchecked(fcntl(raw_child, 
FcntlArg::F_GETFD)?) };
++let mut cur_flags = FdFlag::from_bits_retain(fcntl(raw_child, 
FcntlArg::F_GETFD)?);
+ cur_flags.remove(FdFlag::FD_CLOEXEC);
+ fcntl(raw_child, FcntlArg::F_SETFD(cur_flags))?;
+ 
diff -Nru greetd-0.9.0/debian/patches/relax_deps.patch 
greetd-0.9.0/debian/patches/relax_deps.patch
--- greetd-0.9.0/debian/patches/relax_deps.patch2023-12-21 
14:17:58.0 +
+++ greetd-0.9.0/debian/patches/relax_deps.patch2024-05-02 
16:26:04.0 +
@@ -15,15 +15,4 @@
  getopts = "0.2"
  enquote = "1.1"
 -nix = "0.26"
-+nix = ">=0.26"
 a/greetd/Cargo.toml
-+++ b/greetd/Cargo.toml
-@@ -11,7 +11,7 @@
- debug = []
- 
- [dependencies]
--nix = "0.26"
-+nix = ">=0.26"
- pam-sys = "0.5.6"
- users = "0.11.0"
- serde = { version = "1.0", features = ["derive"] }
++nix = ">= 0.26"
diff -Nru greetd-0.9.0/debian/patches/series greetd-0.9.0/debian/patches/series
--- greetd-0.9.0/debian/patches/series  2023-12-21 14:17:58.0 +
+++ greetd-0.9.0/debian/patches/series  2024-05-02 16:26:04.0 +
@@ -2,3 +2,4 @@
 config_tweaks.patch
 relax_deps.patch
 rpassword_6.0_adaptation.patch
+nix-0.27.patch

Bug#1064479: aardvark-dns - upcoming rust-nix update.

[Peter Green]

if I get no response I will likely NMU this when the
new rust-nix is uploaded to unstable.


I have now uploaded rust-nix to unstable and uploaded
the nmu for this package.

Final debdiff is attatched (really this time)
diff -Nru aardvark-dns-1.4.0/debian/changelog 
aardvark-dns-1.4.0/debian/changelog
--- aardvark-dns-1.4.0/debian/changelog 2023-09-07 00:45:48.0 +
+++ aardvark-dns-1.4.0/debian/changelog 2024-05-02 16:14:54.0 +
@@ -1,3 +1,12 @@
+aardvark-dns (1.4.0-5.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Relax cargo dependency on nix to support 0.27 and explicitly enable
+required features, since nix no longer enables any features by default.
+(Closes: #1064479)
+
+ -- Peter Michael Green   Thu, 02 May 2024 16:14:54 +
+
 aardvark-dns (1.4.0-5) unstable; urgency=medium
 
   * Build against clap version 4, Closes: #1040876, #1040877
diff -Nru aardvark-dns-1.4.0/debian/patches/update-dependencies.patch 
aardvark-dns-1.4.0/debian/patches/update-dependencies.patch
--- aardvark-dns-1.4.0/debian/patches/update-dependencies.patch 2023-09-07 
00:45:48.0 +
+++ aardvark-dns-1.4.0/debian/patches/update-dependencies.patch 2024-05-02 
16:14:43.0 +
@@ -25,7 +25,7 @@
 +async-broadcast = ">= 0.4.1"
  resolv-conf = "0.7.0"
 -nix = "0.25.0"
-+nix = "0.26"
++nix = { version = ">= 0.25.0", features = ["fs", "signal"] }
  libc = "0.2"
  
  [build-dependencies]

Bug#1064479: aardvark-dns - upcoming rust-nix update.

[Peter Green]

if I get no response I will likely NMU this when the
new rust-nix is uploaded to unstable.


I have now uploaded rust-nix to unstable and uploaded
the nmu for this package.

Final debdiff is attatched.

Bug#1070136: openjdk-17-jre-headless: error creating symbolic link '/usr/share/man/man1/java.1.gz.dpkg-tmp': No such file or directory

[Peter van Dijk]

Package: openjdk-17-jre-headless
Version: 17.0.11+9-1~deb12u1
Severity: normal
X-Debbugs-Cc: pe...@7bits.nl

Dear Maintainer,

   * What led up to the situation?

Installing openjdk-17-jre-headless on a very minimal base system. The 12-slim 
Docker image is not minimal enough
 to reproduce this (it has an empty /usr/share/man/man1) but an mkosi-build 
Debian Bookworm image reproduces it
(by not having /usr/share/man/man1)

   * What exactly did you do (or not do) that was effective (or
 ineffective)?

As suggested in https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=863199 (which 
appears to be a previous instanc
e of the same problem), mkdir -p /usr/share/man/man1 followed by apt install -f 
sorted the situation. The fix ap
plied to close that bug would likely help here too.

Please note that the System Information below is from after:

* attempting to install openjdk-17-jre-headless
* the mkdir -p
* installing reportbug and its dependencies

although I have the impression installing reportbug did not change any of the 
information mentioned below.

-- System Information:
Debian Release: 12.1
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 'stable')
Architecture: amd64 (x86_64)

Kernel: Linux 6.1.0-18-amd64 (SMP w/4 CPU threads; PREEMPT)
Kernel taint flags: TAINT_DIE
Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages openjdk-17-jre-headless depends on:
ii  ca-certificates-java  20230710~deb12u1
ii  java-common   0.74
ii  libasound21.2.8-1+b1
ii  libc6 2.36-9+deb12u1
ii  libcups2  2.4.2-3+deb12u5
ii  libfontconfig12.14.1-4
ii  libfreetype6  2.12.1+dfsg-5
ii  libgcc-s1 12.2.0-14
ii  libharfbuzz0b 6.0.0+dfsg-3
ii  libjpeg62-turbo   1:2.1.5-2
ii  liblcms2-22.14-2
ii  libnss3   2:3.87.1-1
ii  libpcsclite1  1.9.9-2
ii  libstdc++612.2.0-14
ii  util-linux2.38.1-5+b1
ii  zlib1g1:1.2.13.dfsg-1

openjdk-17-jre-headless recommends no packages.

Versions of packages openjdk-17-jre-headless suggests:
pn  fonts-dejavu-extra 
pn  fonts-indic
pn  fonts-ipafont-gothic   
pn  fonts-ipafont-mincho   
pn  fonts-wqy-microhei | fonts-wqy-zenhei  
pn  libnss-mdns

-- no debconf information

Bug#1070042: libarchive: archive_entry_stat returns zero size on mips64el with _FILE_OFFSET_BITS=64

[Peter Pentchev]

On Tue, Apr 30, 2024 at 09:45:27AM +0300, Adrian Bunk wrote:
> On Mon, Apr 29, 2024 at 11:12:54AM +0200, Johannes Schauer Marin Rodrigues 
> wrote:
> >...
> > I attached a minimal reproducer. It includes an embedded gzipped tarball 
> > with a
> > single file called "myfilename" of size 10. It works fine if 
> > _FILE_OFFSET_BITS
> > is not set but with it, it reports a wrong archive member size of zero on
> > mips64el:
> >...
> >   st_uid = 1000, st_gid = 1000, st_rdev = 0, st_pad2 = {0, 0, 10}, st_size 
> > = 0, 
> >...
> > As one can see, the size "10" is not in st_size but in the padding before 
> > the
> > st_size member. This only happens when _FILE_OFFSET_BITS=64 and only on
> > mips64el.
> > 
> > Any idea what is going on with mips64el?
> 
> The assumption that _FILE_OFFSET_BITS=64 would be a NOP on 64-bit is
> not true on MIPS, where stat and stat64 differ in padding and 
> _FILE_OFFSET_BITS=64 switches stat to the stat64 padding:
> https://sources.debian.org/src/glibc/2.36-9%2Bdeb12u4/sysdeps/unix/sysv/linux/mips/bits/struct_stat.h/#L149-L156
> 
> AC_SYS_LARGEFILE was added to e2fsprogs configure.ac 2 years ago, 
> therefore manual
>   #define _FILE_OFFSET_BITS 64
>   #define _LARGEFILE64_SOURCE 1
> should no longer be necessary for architectures where it is needed.

Yeah, I think that's what Helmut Grohne said in #1068251, I knew I had
seen it before. So IMHO the problem here is indeed not in libarchive, but,
yes, in e2fsprogs setting FILE_OFFSET_BITS=64 unconditionally.

As such, if no one objects, I think this bug should be closed and
e2fsprogs should indeed rely on AC_SYS_LARGEFILE (as libarchive already does)
instead.

Thanks everyone for tracking this down!

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#1070010: Acknowledgement (dpkg: po: Fix typos)

[Peter Krefting]

Tags: patch

After sending the email I of course immediately found a few more 
typos. I also removed the date change for the header, to avoid merge 
issues.


Also available at 
https://github.com/nafmo/dpkg-l10n-sv/commit/b8167199488d92e65a88130a67c2698d55f3



From b8167199488d92e65a88130a67c2698d55f3 Mon Sep 17 00:00:00 2001

From: Peter Krefting 
Date: Sun, 28 Apr 2024 14:19:38 +0100
Subject: [PATCH] po: Fix typos

Signed-off-by: Peter Krefting 
---
 man/po/sv.po | 16 
 scripts/po/sv.po |  4 ++--
 2 files changed, 10 insertions(+), 10 deletions(-)

diff --git a/man/po/sv.po b/man/po/sv.po
index bd7cfc0f7..3f0e4d6ae 100644
--- a/man/po/sv.po
+++ b/man/po/sv.po
@@ -4350,7 +4350,7 @@ msgid ""
 "This file contains the list of artifacts that are to be distributed via the "
 "B<.changes> control file."
 msgstr ""
-"Den här filen innehåller listan över artifakter som skall distribueras genom "
+"Den här filen innehåller listan över artefakter som skall distribueras genom "
 "styrfilen B<.changes>."

 #. type: textblock
@@ -4366,7 +4366,7 @@ msgstr "I I I [ 
I ]"
 #. type: textblock
 #: deb-src-files.pod
 msgid "I is the name of the artifact to distribute."
-msgstr "I är namnet på artifakten som ska distribueras."
+msgstr "I är namnet på artefakten som ska distribueras."

 #. type: textblock
 #: deb-src-files.pod
@@ -9160,7 +9160,7 @@ msgid ""
 msgstr ""
 "Flera kommandoradsflaggor (beskrivna nedan) kan användas för att hjälpa till "
 "att optimera den skapade binären (sedan dpkg 1.21.0). B: om "
-"B aktiveras kan dessa flaggor leda till binärartifakter som inte kan "
+"B aktiveras kan dessa flaggor leda till binärartefakter som inte kan "
 "reproduceras."

 #. type: =item
@@ -10979,7 +10979,7 @@ msgid ""
 "referenced in the file (since dpkg 1.17.6).  The command should take the B<."
 "changes> pathname as an argument. This command will usually be B."
 msgstr ""
-"Kommando som kontrollerar själva B<.changes>-filen och byggda artifakter som "
+"Kommando som kontrollerar själva B<.changes>-filen och byggda artefakter som "
 "refereras i filen (sedan dpkg 1.17.6). Kommandot ska ta sökvägen till B<."
 "changes> som argument. Kommandot är normalt B."

@@ -11124,7 +11124,7 @@ msgstr "B<--buildinfo-file=>I"
 msgid ""
 "Set the I for the generated B<.buildinfo> file (since dpkg 1.21.0)."
 msgstr ""
-"Ange I att använda för den skapade B<.buildinfo>-filen (sedam dpkg "
+"Ange I att använda för den skapade B<.buildinfo>-filen (sedan dpkg "
 "1.21.0)."

 #. type: =item
@@ -11244,7 +11244,7 @@ msgid ""
 "Note: For security reasons the I is best kept locked with a "
 "password."
 msgstr ""
-"Observera: Av säkerhetsskäl är det bäst att håll I låst med ett "
+"Observera: Av säkerhetsskäl är det bäst att hålla I låst med ett "
 "lösenord."

 #. type: =item
@@ -11265,7 +11265,7 @@ msgstr "B<-ui>, B<--unsigned-buildinfo>"
 #. type: textblock
 #: dpkg-buildpackage.pod
 msgid "Do not sign the B<.buildinfo> file (since dpkg 1.18.19)."
-msgstr "Signera inte B<.buildinfo>-filen (sedam dpkg 1.18.19)."
+msgstr "Signera inte B<.buildinfo>-filen (sedan dpkg 1.18.19)."

 #. type: =item
 #: dpkg-buildpackage.pod
@@ -13341,7 +13341,7 @@ msgid ""
 msgstr ""
 "B läser information från ett uppackat och byggt "
 "Debiankällkodsträd och från de filer det har genererat, och genererar en "
-"styrfil som beskriver byggmiljön och byggartifakterna (B<.buildinfo>-filen)."
+"styrfil som beskriver byggmiljön och byggartefakterna (B<.buildinfo>-filen)."

 #. type: textblock
 #: dpkg-genbuildinfo.pod
diff --git a/scripts/po/sv.po b/scripts/po/sv.po
index 7fc16ce0a..c6d34f358 100644
--- a/scripts/po/sv.po
+++ b/scripts/po/sv.po
@@ -853,7 +853,7 @@ msgstr ""

 #: scripts/dpkg-genbuildinfo.pl
 msgid "binary build with no binary artifacts found; .buildinfo is meaningless"
-msgstr "binärbygge utan binära artifakter upptäckt; .buildinfo är meningslös"
+msgstr "binärbygge utan binära artefakter upptäckt; .buildinfo är meningslös"

 #: scripts/dpkg-genbuildinfo.pl
 #, perl-format
@@ -974,7 +974,7 @@ msgstr "endast binär insändning (inkluderar ej källkod)"

 #: scripts/dpkg-genchanges.pl
 msgid "binary build with no binary artifacts found; cannot distribute"
-msgstr "binärbygge utan binära artifakter upptäckt; kan inte distribuera"
+msgstr "binärbygge utan binära artefakter upptäckt; kan inte distribuera"

 #: scripts/dpkg-genchanges.pl
 #, perl-format
--
2.39.2

Bug#1070011: dpkg: po: Update Swedish translation (main branch)

[Peter Krefting]

Package: dpkg
Version: 1.22.6
Tags: l10n patch
Severity: wishlist

This updates the Swedish translation to match the main branch of 
https://git.dpkg.org/git/dpkg/dpkg.git as of today. It also contains 
the fixes posted in bug 1070010, so that merge errors can be ignored.


The files can also be downloaded from 
https://github.com/nafmo/dpkg-l10n-sv/commit/af826701112dd17c2fa0abd12c97e8e6da7a2726



From af826701112dd17c2fa0abd12c97e8e6da7a2726 Mon Sep 17 00:00:00 2001

From: Peter Krefting 
Date: Sun, 28 Apr 2024 15:36:33 +0100
Subject: [PATCH] po: Update Swedish translations

Signed-off-by: Peter Krefting 
---
 man/po/sv.po | 324 +--
 po/sv.po |  34 ++---
 scripts/po/sv.po |  45 +++
 3 files changed, 146 insertions(+), 257 deletions(-)

diff --git a/man/po/sv.po b/man/po/sv.po
index 97b3b98b5..8f8032435 100644
--- a/man/po/sv.po
+++ b/man/po/sv.po
@@ -1,15 +1,14 @@
 # Translation of dpkg-man to Swedish
-# Copyright 1999-2023 Software in the Public Interest
+# Copyright 1999-2024 Software in the Public Interest
 # This file is distributed under the same license as the dpkg package.
-#
-# Peter Krefting , 1999-2023.
+# Peter Krefting , 1999-2024.
 #
 msgid ""
 msgstr ""
 "Project-Id-Version: dpkg-man 1.22.0\n"
 "Report-Msgid-Bugs-To: debian-d...@lists.debian.org\n"
 "POT-Creation-Date: 2024-03-10 20:21+0100\n"
-"PO-Revision-Date: 2024-03-08 23:45+0100\n"
+"PO-Revision-Date: 2024-04-28 15:33+0100\n"
 "Last-Translator: Peter Krefting \n"
 "Language-Team: Svenska \n"
 "Language: sv\n"
@@ -4404,7 +4403,7 @@ msgid ""
 "This file contains the list of artifacts that are to be distributed via the "
 "B<.changes> control file."
 msgstr ""
-"Den här filen innehåller listan över artifakter som skall distribueras genom "
+"Den här filen innehåller listan över artefakter som skall distribueras genom "
 "styrfilen B<.changes>."

 #. type: textblock
@@ -4420,7 +4419,7 @@ msgstr "I I I [ 
I ]"
 #. type: textblock
 #: deb-src-files.pod
 msgid "I is the name of the artifact to distribute."
-msgstr "I är namnet på artifakten som ska distribueras."
+msgstr "I är namnet på artefakten som ska distribueras."

 #. type: textblock
 #: deb-src-files.pod
@@ -9121,15 +9120,6 @@ msgstr "B<--query-features> I"

 #. type: textblock
 #: dpkg-buildflags.pod
-#, fuzzy
-#| msgid ""
-#| "Print the features enabled for a given area (since dpkg 1.16.2).  If the "
-#| "feature is handled (even if only on some architectures) as a builtin "
-#| "default by the compiler, then a B field is printed (since dpkg "
-#| "1.21.14).  The only currently recognized areas on Debian and derivatives "
-#| "are B, B, B, B and B, see "
-#| "the B section for more details.  Exits with 0 if the area "
-#| "is known otherwise exits with 1."
 msgid ""
 "Print the features enabled for a given area (since dpkg 1.16.2).  If the "
 "feature is handled (even if only on some architectures) as a builtin default "
@@ -9139,11 +9129,9 @@ msgid ""
 msgstr ""
 "Skriv ut funktioner aktiverade för ett givet område (sedan dpkg 1.16.2). Om "
 "funktionen hanteras (även om bara av några arkitekturer) som ett inbyggt "
-"förval av kompilatorn visas fältet B (sedan dpkg 1.21.14). De enda "
-"för närvarande kända områdena på Debian och dess derivat är B, "
-"B, B, B och B, se avsnittet "
-"B för fler detaljer. Avslutar med 0 om området är känt, "
-"avslutar annars med 1."
+"förval av kompilatorn visas fältet B (sedan dpkg 1.21.14). Se "
+"avsnittet B för fler detaljer om de områden som är kända "
+"för  närvarande. Avslutar med 0 om området är känt, avslutar annars med 1."

 #. type: textblock
 #: dpkg-buildflags.pod
@@ -9466,6 +9454,8 @@ msgid ""
 "Feature areas are currently vendor specific, and the ones described below "
 "are only recognized on Debian and derivatives."
 msgstr ""
+"Funktionsområden är för närvarande återförsäljarspecifika, och de som "
+"beskrivs nedan är de enda som är kända på Debian och dess derivat."

 #. type: textblock
 #: dpkg-buildflags.pod
@@ -9481,6 +9471,16 @@ msgid ""
 "specifiers are split across multiple space-separated feature area settings "
 "for the same area."
 msgstr ""
+"Varje områdesfunktion kan aktiveras och inaktiveras i miljövariablerna "
+"B och B:s områdesvärde med "
+"ändringsvärdena ”B<+>” och ”B<->”. Genom att följa den allmänna syntaxen för "
+"dessa variabler (som besk

Bug#1070010: dpkg: po: Fix typos

[Peter Krefting]

Package: dpkg
Version: 1.21.22
Tags: l10n
Severity: wishlist

I spotted a couple of typos in my Swedish translation. The following 
patch applies on top of the "bookworm" branch from 
https://git.dpkg.org/git/dpkg/dpkg.git and can also be found here: 
https://github.com/nafmo/dpkg-l10n-sv/commit/bd899d3a9026ee44ea25e2cea829f00b4e9fc795



From bd899d3a9026ee44ea25e2cea829f00b4e9fc795 Mon Sep 17 00:00:00 2001

From: Peter Krefting 
Date: Sun, 28 Apr 2024 14:19:38 +0100
Subject: [PATCH] po: Fix typos

Signed-off-by: Peter Krefting 
---
 man/po/sv.po | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/man/po/sv.po b/man/po/sv.po
index bd7cfc0f7..13a6dc6b2 100644
--- a/man/po/sv.po
+++ b/man/po/sv.po
@@ -7,7 +7,7 @@ msgstr ""
 "Project-Id-Version: dpkg-man 1.21.19\n"
 "Report-Msgid-Bugs-To: debian-d...@lists.debian.org\n"
 "POT-Creation-Date: 2023-01-10 17:46+\n"
-"PO-Revision-Date: 2023-01-28 17:19+0100\n"
+"PO-Revision-Date: 2024-04-28 14:19+0100\n"
 "Last-Translator: Peter Krefting \n"
 "Language-Team: Swedish \n"
 "Language: sv\n"
@@ -11124,7 +11124,7 @@ msgstr "B<--buildinfo-file=>I"
 msgid ""
 "Set the I for the generated B<.buildinfo> file (since dpkg 1.21.0)."
 msgstr ""
-"Ange I att använda för den skapade B<.buildinfo>-filen (sedam dpkg "
+"Ange I att använda för den skapade B<.buildinfo>-filen (sedan dpkg "
 "1.21.0)."

 #. type: =item
@@ -11244,7 +11244,7 @@ msgid ""
 "Note: For security reasons the I is best kept locked with a "
 "password."
 msgstr ""
-"Observera: Av säkerhetsskäl är det bäst att håll I låst med ett "
+"Observera: Av säkerhetsskäl är det bäst att hålla I låst med ett "
 "lösenord."

 #. type: =item
@@ -11265,7 +11265,7 @@ msgstr "B<-ui>, B<--unsigned-buildinfo>"
 #. type: textblock
 #: dpkg-buildpackage.pod
 msgid "Do not sign the B<.buildinfo> file (since dpkg 1.18.19)."
-msgstr "Signera inte B<.buildinfo>-filen (sedam dpkg 1.18.19)."
+msgstr "Signera inte B<.buildinfo>-filen (sedan dpkg 1.18.19)."

 #. type: =item
 #: dpkg-buildpackage.pod
--
2.39.2

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#1069913: dovecot-imapd: dovecot starts before home directories are available

[Peter Chubb]

Package: dovecot-imapd
Version: 1:2.3.21+dfsg1-3+b1
Severity: normal

Dear Maintainer,

   On my system, home directories are automounted using autofs over NFS.
   It appears that dovecot starts before the autofs daemon is completely
   ready. Thus, it seems to be looking at the (empty) mount point 
   and seeing no mailboxes in people's home directories.

   The workaround is to wait until the system is fully up, log in,
   and restart dovecot.

   It's taken me a while to work out what's going on; it seems to have come 
   when I started using systemd instead of sysV init.  I suspect it's an
   ordering issue, but it's not that obvious how to make dovecot delay
   starting until autofs is ready to mount directories.


-- Package-specific info:

dovecot configuration
-
# 2.3.21 (47349e2482): /etc/dovecot/dovecot.conf
# Pigeonhole version 0.5.21 (f6cd4b8e)
# OS: Linux 6.7.12-amd64 x86_64 Debian trixie/sid 
# Hostname: wombat.chubb.wattle.id.au
first_valid_uid = 130
mail_access_groups = mail
mail_full_filesystem_access = yes
mail_location = mbox:~/Mail/:INBOX=/var/mail/%u:INDEX=/var/indices/%u
mail_nfs_storage = yes
mail_privileged_group = mail
namespace inbox {
  inbox = yes
  location = 
  mailbox Drafts {
special_use = \Drafts
  }
  mailbox Junk {
special_use = \Junk
  }
  mailbox Sent {
special_use = \Sent
  }
  mailbox "Sent Messages" {
special_use = \Sent
  }
  mailbox Spam {
special_use = \Junk
  }
  mailbox Trash {
special_use = \Trash
  }
  prefix = 
  separator = /
}
passdb {
  driver = pam
}
passdb {
  driver = pam
}
protocols = " imap"
ssl_cert = 

Versions of packages dovecot-imapd is related to:
ii  dovecot-core [dovecot-common]  1:2.3.21+dfsg1-3+b1
pn  dovecot-dev
pn  dovecot-gssapi 
ii  dovecot-imapd  1:2.3.21+dfsg1-3+b1
pn  dovecot-ldap   
pn  dovecot-lmtpd  
pn  dovecot-managesieved   
pn  dovecot-mysql  
pn  dovecot-pgsql  
pn  dovecot-pop3d  
pn  dovecot-sieve  
pn  dovecot-sqlite 

-- no debconf information

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#1069877: python3-ldap3: Ldif module unavailable/nonfunctional

[peter tuharsky]

Package: python3-ldap3
Version: 2.9.1-2
Severity: important

Dear Maintainer,

according to Python documentation, the python-ldap module should contain ldif 
module with functions such as LDIFParser, LDIFWrite etc.
As of Debian packages, the former python-ldap did support this functionality. 
However, its successor python3-ldap3 does not.
Attempt to call the module leads to error:

ModuleNotFoundError: No module named 'ldif'


-- System Information:
Debian Release: 12.5
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable')
Architecture: amd64 (x86_64)

Kernel: Linux 6.1.0-18-amd64 (SMP w/1 CPU thread; PREEMPT)
Locale: LANG=sk_SK.UTF-8, LC_CTYPE=sk_SK.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages python3-ldap3 depends on:
ii  python3 3.11.2-1+b1
ii  python3-pyasn1  0.4.8-3

python3-ldap3 recommends no packages.

python3-ldap3 suggests no packages.

-- no debconf information

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#1014037: mailman3-web: Possible memory leak: uwsgi OOMs after a few weeks

[Peter Chubb]

>>>>> "Pierre-Elliott" == Pierre-Elliott Bécue  writes:


Pierre-Elliott> Having the same kind of setup for the past 6 years, I
Pierre-Elliott> never had such an issue.


Since increasing the size of the VM and the last Mailman3 upgrade, I
haven't seen the issue.

-- 
Dr Peter Chubbhttps://trustworthy.systems/
Trustworthy Systems GroupCSE, UNSW
Core hours: Mon 8am-3pm; Wed: 8am-5pm; Fri 8am-12pm.

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#997948: FPC should provide a way to trigger automatic rebuild of

[Peter Blackman]

On 18/06/2023 09:45, Abou Al Montacir wrote:
However, fpc units are kind of statically linked libraries. And in 
this case, one ma want a rebuild of all reverse dependencies in order 
to ensure a bug fix is propagated on all binaries.


Example: Suppose we discover a vulnerability in a unit. We want that 
all units and all programs that use it be rebuilt, no?





Setting the 'Static-Built-Using' field in the control files of packages 
built with fpc should fix this.


Cheers,
Peter

Bug#1069256: debian-policy: clarify requirement for use of Static-Built-Using

[Peter B]

Regarding ;-

"(for example linking against static libraries, builds for
 source-centered languages such as Go or Rust, usage of header-only
 C/C++ libraries, injecting data blobs into code, etc.)"

Perhaps Pascal & Lazarus could be added to that list for clarity? [1]


Regards,
Peter

[1]  https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=997948

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#1025912: rust-serde-yaml: please upgrade to v0.9

[Peter Green]

On 23/04/2024 15:52, Arnaud Ferraris wrote:

Hi,

On Thu, 27 Jul 2023 20:19:19 +0100 Peter Green  wrote:

> squeekboard - not investigated yet.

Tests fail after bumping dependency.

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


I've just uploaded the new version of squeekboard to experimental, built using 
serde-yaml 0.9.

IIUC that was the last blocker, so feel free to upload to unstable whenever you 
see fit.


It looks like at least one new rdep has popped up, and it's a binary crate, so 
it this is
done now it will entangle itself with the time_t transition.

Will take a closer look when the time_t transition is over.

Bug#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#1069288: init: runit-init disappeared from PreDepends somewhere around 1.60

[Peter Gervai]

Package: init
Version: 1.60
Severity: normal

init 1.56+nmu1 had predepends on systemd-sysv | sysvinit-core | runit-init
init 1.60 and on has only systemd-sysv | sysvinit-core
runit-init seems to be gone?

I see nothing about that in changelog, nor it's obvious why this have happened, 
but it does not look right; it very much tries to break very hard any systems
using runit-init.

It's also a bit confusing what have (not) happened in #924132 since, erm, may 
2019?

Thanks!

Bug#1069287: RFS: winff/1.6.4+dfsg-1 -- graphical video and audio batch converter using ffmpeg or avconv

[Peter Blackman]

Package: sponsorship-requests
Severity: normal

Dear mentors,

I am looking for a sponsor for my package "winff":

 * Package name : winff
   Version  : 1.6.4+dfsg-1
   Upstream contact : Matthew Weatherford 
 * URL  : https://github.com/WinFF/winff
 * License  : GFDL-1.3+, GPL-2+, GPL-3+
 * Vcs  : https://salsa.debian.org/pascal-team/winff
   Section  : video

The source builds the following binary packages:

  winff - graphical video and audio batch converter using ffmpeg or avconv
  winff-qt - Qt variant of winff
  winff-data - winff data files
  winff-doc - winff documentation

To access further information about this package, please visit the 
following URL:


  https://mentors.debian.net/package/winff/

Alternatively, you can download the package with 'dget' using this command:

  dget -x 
https://mentors.debian.net/debian/pool/main/w/winff/winff_1.6.4+dfsg-1.dsc


Changes since the last upload:

 winff (1.6.4+dfsg-1) unstable; urgency=medium
 .
   * Use faketime for building the pdfs (reproducible build)
   * Add escapes for ';', '&' in file names (Closes: #1068471)
   * Add detox to suggests
   * Make the documentation a recommends instead of suggests
   * Update standards version to 4.7.0, no changes needed.

Regards,
--
  Peter Blackman

Bug#1067907: flam3-utils: flam3-genome randomly segfaults on ppc64el

[Peter Blackman]

On 13/04/2024 10:45, Bernhard Übelacker wrote:

Hi Bernard,

Many thanks for looking at this, but I'm afraid I still can't see any 
obvious solution.




(gdb) bt
#0  iter_thread_int (fth=0x157681210) at rect.c:500


The failing instruction is

  500 if (p[3]==1.0) {

I assume the issue is with p[3] rather than 1.0,
but the gbd dump shows p[3] holding a valid value!

  (gdb) print p[3]
  $8 = 1


If anyone with access to hardware was minded to have a further look,
it might be interesting to see if the program works without optimisation,
or maybe with just -O1   (set in Makefile.am)


Kind Regards,
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#1004863: Bootstrapping a Fedora produces a system with an empty package database

[Peter Pentchev]

On Sun, Apr 14, 2024 at 07:39:54PM +0100, Luca Boccassi wrote:
> > Le 2/13/22 à 09:00, Mihai Moldovan a écrit :
> > 
> > > I'm pretty sure that we can, at some point in the future, drop the
> > offending
> > > patch from the RPM package and all of this will be redundant. It
> > just requires a
> > > bit of work to make sure that older use cases (mostly alien) don't
> > break due to
> > > this, which might require a bit of development on RPM itself. It's
> > on my TODO
> > > list for very rainy and boring days, but unfortunately there's
> > almost always a
> > > truckload of other things to do, so I keep dragging it out.
> > > 
> > > 
> > > 
> > > Mihai
> > > 
> > 
> > I fully agree on removing the RPM patch that causes all of our issues
> > on packages depending on it. If needed, I'm willing to be part of
> > reviewing what would be the impact of returning to a standard RPM
> > package on Debian and to help into solving those issues. Don't
> > hesitate to ping me for that.
> 
> I think the time has come to drop the RPM Debian-specific patches and
> avoid these workarounds altogether.
> 
> Once upon a time it made sense to redirect the RPM DB, and to go out of
> our way to stop users installing RPMs locally, when RPMs were popular
> as a way to distribute upstream applications.
> 
> Nowadays, the most common way to distribute upstream apps is via
> Flatpak/Appimage/etc, or (thanks to Ubuntu's popularity) via deb
> repositories, so the chances someone tries to 'sudo rpm -i foo.rpm' are
> very low.
> 
> The main use of having rpm/dnf/zypper in Debian is not to convert RPMs
> with Alien or so, but it's to be able to do cross-distribution
> bootstraps and image building using native tools, like we do in mkosi
> (and in other tools as well).
> 
> So these patches to print warnings and divert the database and so on
> are a hindrance.
> 
> Hence, for Trixie I think we should just drop them all.
> 
> It should also make it easier to maintain the RPM stack, which has
> languished. We are trying to move everything under the RPM Team Salsa
> org, which should also help.
> 
> If there are any objections please speak up.

I've thought about making this change at least once a year, but
I have always been, hm, should I say "too careful" (when of course
I actually mean "too scared")... so if you feel the time has come,
yeah, go ahead!

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#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#1068894: dokuwiki: Get error accessing syntax help page.

[Peter Chubb]

Package: dokuwiki
Version: 0.0.20220731.a-2
Severity: normal

Dear Maintainer,

Visiting the 'syntax help' page produces the message,
"TypeError: implode(): Argument #2 ($array) must be of type ?array, 
string given"


This has been reported and fixed upstream at 
https://github.com/dokuwiki/dokuwiki/issues/4087

Packaging the new upstream version would fix this and bug  #1067025



-- System Information:
Debian Release: 12.5
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable')
Architecture: amd64 (x86_64)

Kernel: Linux 6.1.0-18-amd64 (SMP w/2 CPU threads; PREEMPT)
Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_AU:en
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages dokuwiki depends on:
ii  debconf [debconf-2.0]  1.5.82
ii  javascript-common  11+nmu1
ii  libjs-jquery   3.6.1+dfsg+~3.5.14-1
ii  libjs-jquery-cookie12-4
ii  libjs-jquery-ui1.13.2+dfsg-1
ii  libphp-simplepie   1.3.1+dfsg-5
ii  perl   5.36.0-7+deb12u1
ii  php2:8.2+93
ii  php-geshi  1.0.9.1-1
ii  php-phpseclib  2.0.42-1+deb12u1
ii  php-random-compat  2.0.21-1
ii  php-xml2:8.2+93
ii  php8.2 [php]   8.2.7-1~deb12u1
ii  php8.2-xml [php-xml]   8.2.7-1~deb12u1
ii  ucf3.0043+nmu1

Versions of packages dokuwiki recommends:
ii  imagemagick  8:6.9.11.60+dfsg-1.6
ii  imagemagick-6.q16 [imagemagick]  8:6.9.11.60+dfsg-1.6
ii  php-ldap 2:8.2+93
ii  php8.2-cli [php-cli] 8.2.7-1~deb12u1
ii  php8.2-ldap [php-ldap]   8.2.7-1~deb12u1
ii  wget 1.21.3-1+b2

Versions of packages dokuwiki suggests:
pn  libapache2-mod-xsendfile  

-- Configuration Files:
/etc/dokuwiki/mime.conf changed [not included]
/etc/dokuwiki/plugins.local.php changed [not included]

-- debconf information:
  dokuwiki/wiki/policy: public
  dokuwiki/wiki/failpass:
* dokuwiki/system/restart-webserver: false
  dokuwiki/wiki/email: webmaster@localhost
* dokuwiki/system/documentroot: /
* dokuwiki/system/accessible: global
* dokuwiki/system/writeconf: true
* dokuwiki/wiki/title: TS Wiki
  dokuwiki/wiki/fullname: DokuWiki Administrator
* dokuwiki/system/writeplugins: true
  dokuwiki/wiki/superuser: admin
* dokuwiki/system/purgepages: false
  dokuwiki/system/localnet: 10.0.0.0/24
* dokuwiki/wiki/acl: true
* dokuwiki/wiki/license: cc-by-sa
* dokuwiki/system/configure-webserver: apache2

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#1068181: asunder: Additional Information following maintainer response.

[Peter B]

On 03/04/2024 22:51, Joshua Aspinall wrote:

E: Unable to fetch some archives, maybe run apt-get update or try with 
--fix-missing?


Hi Josh,

I suggest trying that suggestion  "maybe run apt-get update or try with 
--fix-missing?"


Also try installing cdparanoia and wavpack separately.

You can download wavpack from here, and install with 'sudo dpkg -i'
https://packages.debian.org/trixie/amd64/wavpack/download



IMHO there is something wrong with your system, rather than with asunder.

Maybe ask for help on the user mailing list of the forum.
https://lists.debian.org/debian-user/
https://forums.debian.net/viewforum.php?f=40


Regards,
Peter

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#1067391: bitlbee-facebook: redundant dependency on libglib2.0-0

[Peter Michael Green]

severity 1067391 serious
thanks

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

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

[Peter Michael Green]

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

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

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

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

[Peter Michael Green]

tags 1066392 +patch
thanks

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

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

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

[Peter Michael Green]

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

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

Bug#966249: appstream-generator FTBFS with gdc

[Peter Michael Green]

severity 966249 serious
thanks


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

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

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

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

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

[Peter Michael Green]

severity 1064708 important

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

Bug#1068181: asunder: Asunder package calls wavpack version not present (5.6.0-1+b1). 5.7.0-1 in repo. Cannot install.

[Peter Blackman]

Hi Josh,

On 01/04/2024 17:33, Peter B wrote:


I have no idea where '5.6.0-1+b1' is coming from.


I do now! Its occurred to me that you need to run
  apt update

so that current packages can be installed.
wavpack was updated in testing a couple of weeks ago.


Please read
  https://wiki.debian.org/DebianTesting
carefully.


Regards,
Peter


P.S.   I'll be closing this 'bug' report.

Bug#1068181: asunder: Asunder package calls wavpack version not present (5.6.0-1+b1). 5.7.0-1 in repo. Cannot install.

[Peter B]

On 01/04/2024 13:07, Joshua Aspinall wrote:

Package: asunder
Version: 3.0.1+ds-1
Severity: normal
X-Debbugs-Cc: joshaspin...@member.fsf.org

Dear Maintainer,

Cannot install Asunder on testing under normal conditions due to wavpack 
version not present (reports file not found)

Looking through the packages browser can see a newer version (5.7.0-1) than 
that one it tries to grab.  Hopefully a simple fix!

Please contact me if I can help further.

Kind Regards,
Josh.


..snip


Versions of packages asunder depends on:
pn  cdparanoia   
ii  libatk1.0-0  2.50.0-1+b1
ii  libc62.37-15
ii  libcddb2 1.3.2-7
ii  libgdk-pixbuf-2.0-0  2.42.10+dfsg-3+b1
ii  libglib2.0-0 2.78.4-1
ii  libgtk2.0-0  2.24.33-3

Versions of packages asunder recommends:
pn  flac  
pn  lame  
pn  opus-tools
pn  vorbis-tools  
pn  wavpack   

Versions of packages asunder suggests:
pn  musepack-tools  

Hi Josh,

I can see that you do not have cdparanoia installed.
Its a dependency, and you will not be able to install asunder without it.
Also none of the recommends is installed.
You need at least one for Asunder to do anything useful.

wavpack is only a recommends, not a dependency, and the recommends is 
unversioned.

I have no idea where '5.6.0-1+b1' is coming from.
Have removed wavpack here and reinstalled asunder several times without 
any problems.



What exactly is the response to
  sudo dpkg -i asunder_3.0.1+ds-1_amd64.deb
?


Also, what happens if you try to install grimripper?
(grimripper is the gtk3 version of asunder)


Regards,
Peter