Bug#1070782: nmu: gtk4_4.12.5+dfsg-6

[plugwash]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: binnmu

As discussed in bug 1070706 gtk4 was built against a version of libpng1.6
suffering from bug 1066069, which resulted in libgtk-4-1-udeb depending on
libpng16-16t64-udeb which does not exist. This prevents gtk4 migrating to
testing, which leaves a bunch of packages uninstallable in testing on time64
architectures.

Please can you schedule a rebuild.

nmu gtk4_4.12.5+dfsg-6 . ANY . unstable . -m "rebuild with #1066069 fixed"

-- System Information:
Debian Release: 10.13
  APT prefers oldoldstable-updates
  APT policy: (500, 'oldoldstable-updates'), (500, 'oldoldstable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386, arm64

Kernel: Linux 4.19.0-18-amd64 (SMP w/4 CPU cores)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_GB:en (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Bug#1070708: unblock: rust-chrono/0.4.38-2

[plugwash]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock

rust-chrono's testing excuses say (and have listed for at least a day or so)

autopkgtest for rust-trash/3.3.1-1: amd64: Test in progress, arm64: Pass, i386: 
Pass, ppc64el: Pass, s390x: Pass

However, when I look over on debci I do not see any relavent pending tests.
There is a test that looks relavent to me a few days ago

rust-chrono/0.4.38-2 rust-fundu/1.0.0...
src:rust-chrono from unstable
src:rust-fundu from unstable
src:rust-pure-rust-locales from unstable 

which passed, but britney seems to be ignoring it. 

Can you figure out what is going wrong and either fix it or override the tests?

Bug#1068604: nmu: pnc_0.9.4-3

[plugwash]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: binnmu

The virtual package libphonenumber8-protobuf32 was renamed to
libphonenumber8t64-protobuf32 as part of the time_t transition.

Most reverse depedencies seem to have already been rebuilt, but four packages
still depend on the old virtual package. libebook-contacts-1.2-4,
kamailio-phonenum-modules, mmsd-tng and pnc

libebook-contacts-1.2-4 is a cruft package
kamailio already has a binnmu scheduled
mmsd-tng has a FTBFS bug.

That leaves pnc as being ready for a binnmu.

nmu pnc_0.9.4-3 . ANY . unstable . -m "rebuild against 
libphonenumber8t64-protobuf32 for time64 transition"

-- System Information:
Debian Release: 10.13
  APT prefers oldoldstable-updates
  APT policy: (500, 'oldoldstable-updates'), (500, 'oldoldstable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386, arm64

Kernel: Linux 4.19.0-18-amd64 (SMP w/4 CPU cores)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_GB:en (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Bug#1068600: swi-prolog, uninstallable on 32-bit non-i386 architectures.

[plugwash]

Package: swi-prolog
Version: 9.0.4+dfsg-3.1
Severity: grave
Tags: trixie, sid
User: debian-...@lists.debian.org
Usertag: time-t

It looks like the adjustments for the time64 transition in the 
9.0.4+dfsg-3.1

NMU were incomplete. Resulting in unsatisfiable dependencies on armel
and armhf at least (and probablly some debian-ports architectures too).

swi-prolog (9.0.4+dfsg-3.1) [PTS 
] [ctrl 
]

   ↓ swi-prolog-doc (>= 9.0.4+dfsg-3.1)
swi-prolog-doc 
 
(9.0.4+dfsg-3.1) [PTS ] [ctrl 
]

   ↓ swi-prolog-core (>= 9.0.4+dfsg-3.1)
swi-prolog-core 
 
(9.0.4+dfsg-3.1) [PTS ] [ctrl 
]

   ↓ libswipl9
MISSING

Ubuntu seem to have fixed this.

http://launchpadlibrarian.net/721003900/swi-prolog_9.0.4+dfsg-3.1ubuntu2_9.0.4+dfsg-3.1ubuntu3.diff.gz

Bug#1068429: nmu: pypy3_7.3.15+dfsg-1

[plugwash]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: binnmu

pypy3 needs rebuilding for the time64 transition (it currently depends on
libssl3).

nmu pypy3_7.3.15+dfsg-1 . ANY . unstable . -m "rebuild for time64"

-- System Information:
Debian Release: 10.13
  APT prefers oldoldstable-updates
  APT policy: (500, 'oldoldstable-updates'), (500, 'oldoldstable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386, arm64

Kernel: Linux 4.19.0-18-amd64 (SMP w/4 CPU cores)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_GB:en (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Bug#1068366: nmu: gyoto_2.0.2-1.1

[plugwash]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: binnmu

It seems that the new version of gyoto was built a bit too early and, on most
architectures, picked up a dependency on libcfitsio10 rather than
libcfitsio10t64.

nmu gyoto_2.0.2-1.1 . ANY . unstable . -m "Rebuild against libcfitsio10t64 for 
time64 transition."

-- System Information:
Debian Release: 10.13
  APT prefers oldoldstable-updates
  APT policy: (500, 'oldoldstable-updates'), (500, 'oldoldstable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386, arm64

Kernel: Linux 4.19.0-18-amd64 (SMP w/4 CPU cores)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_GB:en (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Bug#1068357: nmu: libgrss_0.7.0-2.1

[plugwash]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: binnmu

libsoup2.4.1 was renamed to libsoup-2.4.1 for the time64 transition.

It seems that the new version of libgrss was built a bit too early and, on most
architectures, picked up a dependency on the old package.

nmu libgrss_0.7.0-2.1 . ANY . unstable . -m "Rebuild with libsoup-2.4.1 for 
time64 transition."

-- System Information:
Debian Release: 10.13
  APT prefers oldoldstable-updates
  APT policy: (500, 'oldoldstable-updates'), (500, 'oldoldstable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386, arm64

Kernel: Linux 4.19.0-18-amd64 (SMP w/4 CPU cores)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_GB:en (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Bug#1064612: rust-ahash: Failing autopkgtests

[plugwash]

tags 1064612 +patch
thanks


rust-ahash is unable to migrate to Testing because its autopkgtests are failing:

A debdiff fixing this issue is attatched.

diff -Nru rust-ahash-0.8.9/debian/changelog rust-ahash-0.8.9/debian/changelog
--- rust-ahash-0.8.9/debian/changelog   2024-02-23 07:28:35.0 +
+++ rust-ahash-0.8.9/debian/changelog   2024-03-16 17:46:03.0 +
@@ -1,3 +1,10 @@
+rust-ahash (0.8.9-2.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix feature gaurds for test_key_ref (Closes: #1064612)
+
+ -- Peter Michael Green   Sat, 16 Mar 2024 17:46:03 +
+
 rust-ahash (0.8.9-2) unstable; urgency=medium
 
   * drop patch 2001, obsoleted by Debian package changes;
diff -Nru rust-ahash-0.8.9/debian/patches/1002_test_feature_requirements.patch 
rust-ahash-0.8.9/debian/patches/1002_test_feature_requirements.patch
--- rust-ahash-0.8.9/debian/patches/1002_test_feature_requirements.patch
2024-02-18 09:46:30.0 +
+++ rust-ahash-0.8.9/debian/patches/1002_test_feature_requirements.patch
2024-03-16 17:46:03.0 +
@@ -1,12 +1,15 @@
 Description: fix feature requirements for tests
 Author: Peter Michael Green 
 Bug-Debian: https://bugs.debian.org/1057451
-Last-Update: 2023-12-27
+Bug-Debian: https://bugs.debian.org/1064612
+Last-Update: 2024-03-16
 ---
 This patch header follows DEP-3: http://dep.debian.net/deps/dep3/
 a/src/lib.rs
-+++ b/src/lib.rs
-@@ -322,12 +322,14 @@
+Index: rust-ahash-0.8.9/src/lib.rs
+===
+--- rust-ahash-0.8.9.orig/src/lib.rs
 rust-ahash-0.8.9/src/lib.rs
+@@ -322,12 +322,14 @@ mod test {
  use std::hash::Hash;
  
  #[test]
@@ -21,7 +24,7 @@
  fn test_ahash_alias_set_construction() {
  let mut set = super::HashSet::with_capacity(1234);
  set.insert(1);
-@@ -342,6 +344,7 @@
+@@ -342,6 +344,7 @@ mod test {
  }
  
  #[test]
@@ -29,9 +32,11 @@
  fn test_builder() {
  let mut map = HashMapdefault();
  map.insert(1, 3);
 a/tests/bench.rs
-+++ b/tests/bench.rs
-@@ -116,6 +116,7 @@
+Index: rust-ahash-0.8.9/tests/bench.rs
+===
+--- rust-ahash-0.8.9.orig/tests/bench.rs
 rust-ahash-0.8.9/tests/bench.rs
+@@ -116,6 +116,7 @@ fn bench_map(c:  Criterion) {
  #[cfg(feature = "std")]
  {
  let mut group = c.benchmark_group("map");
@@ -39,7 +44,7 @@
  group.bench_function("aHash-alias", |b| {
  b.iter(|| {
  let hm: ahash::HashMap = (0..1_000_000).map(|i| (i, 
i)).collect();
-@@ -138,6 +139,7 @@
+@@ -138,6 +139,7 @@ fn bench_map(c:  Criterion) {
  }
  })
  });
@@ -47,7 +52,7 @@
  group.bench_function("aHash-hashBrown-explicit", |b| {
  b.iter(|| {
  let hm: hashbrown::HashMap = 
(0..1_000_000).map(|i| (i, i)).collect();
-@@ -160,6 +162,7 @@
+@@ -160,6 +162,7 @@ fn bench_map(c:  Criterion) {
  }
  })
  });
@@ -55,9 +60,11 @@
  group.bench_function("aHash-rand", |b| {
  b.iter(|| {
  let hm: std::collections::HashMap = 
(0..1_000_000).map(|i| (i, i)).collect();
 a/tests/map_tests.rs
-+++ b/tests/map_tests.rs
-@@ -179,7 +179,7 @@
+Index: rust-ahash-0.8.9/tests/map_tests.rs
+===
+--- rust-ahash-0.8.9.orig/tests/map_tests.rs
 rust-ahash-0.8.9/tests/map_tests.rs
+@@ -179,7 +179,7 @@ fn test_bucket_distribution() {
  check_for_collisions(_hasher, , 256);
  }
  
@@ -66,7 +73,7 @@
  #[test]
  fn test_ahash_alias_map_construction() {
  let mut map = ahash::HashMap::default();
-@@ -189,7 +189,7 @@
+@@ -189,7 +189,7 @@ fn test_ahash_alias_map_construction() {
  map.insert(1, "test");
  }
  
@@ -75,3 +82,12 @@
  #[test]
  fn test_ahash_alias_set_construction() {
  let mut set = ahash::HashSet::default();
+@@ -201,7 +201,7 @@ fn test_ahash_alias_set_construction() {
+ }
+ 
+ 
+-#[cfg(feature = "std")]
++#[cfg(all(feature = "std", any(feature = "runtime-rng", feature = 
"compile-time-rng", feature = "no-rng")))]
+ #[test]
+ fn test_key_ref() {
+ let mut map = ahash::HashMap::default();

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

[plugwash]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock

Please unblock package rust-rustls-webpki

The package is blocked by autopkgtest failures on ppc64el and s390x. The reason
for these failures is that the package (which is arch all) is not installable
on these architectures because it depends on the ring crate which is not
currently portable. Please can you override these failures and allow the
package to migrate to testing.

-- System Information:
Debian Release: 10.11
  APT prefers oldoldstable-updates
  APT policy: (500, 'oldoldstable-updates'), (500, 'oldoldstable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386, arm64

Kernel: Linux 4.19.0-18-amd64 (SMP w/4 CPU cores)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_GB:en (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Bug#1050073: unblock: rust-ahash-0.7/0.7.6-13

[plugwash]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock

Please unblock package rust-ahash-0.7

Testing migration of rust-ahash-0.7 is currently blocked by a ppc64el
autopkgtest of rust-cursive. This has been in-progress for 4+ days now,
I've looked at the queue stats and the queue seems basically empty.
So I don't think it's a simple case of infrastructure overload.

Can someone please either investiage what is blocking this test, or override
the test and let the package migrate to testing anyway. 

Bug#1037345: 389-ds-base: ftbfs with rust-base64 0.21

[plugwash]

Package: 389-ds-base
Version: 2.3.1+dfsg1-1
Tags: trixie, sid, ftbfs

389-ds-base FTBFS with the new version of rust-base64.

I attach a patch which makes the package build, and also fixes some 
packaging annoyances. I have not tested it beyond that. I may or may not 
NMU this later.
diff -Nru 389-ds-base-2.3.1+dfsg1/debian/changelog 
389-ds-base-2.3.1+dfsg1/debian/changelog
--- 389-ds-base-2.3.1+dfsg1/debian/changelog2023-01-24 11:21:19.0 
+
+++ 389-ds-base-2.3.1+dfsg1/debian/changelog2023-06-11 13:22:07.0 
+
@@ -1,3 +1,13 @@
+389-ds-base (2.3.1+dfsg1-1.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Add patch for base64 0.21
+  * Make Debian dependency on base64 match cargo dependency.
+  * Improve clean target.
+  * Use ln -fs instead of ln -s to allow resuming build after fixing errors.
+
+ -- Peter Michael Green   Sun, 11 Jun 2023 13:22:07 +
+
 389-ds-base (2.3.1+dfsg1-1) unstable; urgency=medium
 
   * Repackage the source, filter vendored crates and allow building with
diff -Nru 389-ds-base-2.3.1+dfsg1/debian/control 
389-ds-base-2.3.1+dfsg1/debian/control
--- 389-ds-base-2.3.1+dfsg1/debian/control  2023-01-24 11:21:16.0 
+
+++ 389-ds-base-2.3.1+dfsg1/debian/control  2023-06-11 13:22:07.0 
+
@@ -27,7 +27,7 @@
  libpci-dev,
  libpcre2-dev,
  libperl-dev,
- librust-base64-dev,
+ librust-base64-0.21-dev,
  librust-cbindgen-dev,
  librust-cc-dev,
  librust-crossbeam-dev,
diff -Nru 389-ds-base-2.3.1+dfsg1/debian/patches/base64-0.21.diff 
389-ds-base-2.3.1+dfsg1/debian/patches/base64-0.21.diff
--- 389-ds-base-2.3.1+dfsg1/debian/patches/base64-0.21.diff 1970-01-01 
00:00:00.0 +
+++ 389-ds-base-2.3.1+dfsg1/debian/patches/base64-0.21.diff 2023-06-11 
13:22:07.0 +
@@ -0,0 +1,65 @@
+Description: update for base64 0.21
+Author: Peter Michael Green 
+
+Index: 389-ds-base-2.3.1+dfsg1.new/src/plugins/pwdchan/src/lib.rs
+===
+--- 389-ds-base-2.3.1+dfsg1.new.orig/src/plugins/pwdchan/src/lib.rs
 389-ds-base-2.3.1+dfsg1.new/src/plugins/pwdchan/src/lib.rs
+@@ -42,6 +42,12 @@ macro_rules! ab64_to_b64 {
+ }};
+ }
+ 
++use base64::engine::GeneralPurpose;
++use base64::engine::GeneralPurposeConfig;
++use base64::Engine;
++use base64::alphabet;
++static BASE64CONFIG: GeneralPurposeConfig = 
GeneralPurposeConfig::new().with_decode_allow_trailing_bits(true);
++static BASE64ENGINE: GeneralPurpose = 
GeneralPurpose::new(::STANDARD,BASE64CONFIG);
+ impl PwdChanCrypto {
+ #[inline(always)]
+ fn pbkdf2_decompose(encrypted: ) -> Result<(usize, Vec, Vec), 
PluginError> {
+@@ -62,7 +68,7 @@ impl PwdChanCrypto {
+ .ok_or(PluginError::MissingValue)
+ .and_then(|ab64| {
+ let s = ab64_to_b64!(ab64);
+-base64::decode_config(, 
base64::STANDARD.decode_allow_trailing_bits(true))
++BASE64ENGINE.decode()
+ .map_err(|e| {
+ log_error!(ErrorLevel::Error, "Invalid Base 64 {} -> 
{:?}", s, e);
+ PluginError::InvalidBase64
+@@ -74,7 +80,7 @@ impl PwdChanCrypto {
+ .ok_or(PluginError::MissingValue)
+ .and_then(|ab64| {
+ let s = ab64_to_b64!(ab64);
+-base64::decode_config(, 
base64::STANDARD.decode_allow_trailing_bits(true))
++BASE64ENGINE.decode()
+ .map_err(|e| {
+ log_error!(ErrorLevel::Error, "Invalid Base 64 {} -> 
{:?}", s, e);
+ PluginError::InvalidBase64
+@@ -152,11 +158,11 @@ impl PwdChanCrypto {
+ PluginError::Format
+ })?;
+ // the base64 salt
+-base64::encode_config_buf(, base64::STANDARD,  output);
++BASE64ENGINE.encode_string(,  output);
+ // Push the delim
+ output.push_str("$");
+ // Finally the base64 hash
+-base64::encode_config_buf(_input, base64::STANDARD,  output);
++BASE64ENGINE.encode_string(_input,  output);
+ // Return it
+ Ok(output)
+ }
+Index: 389-ds-base-2.3.1+dfsg1.new/src/plugins/pwdchan/Cargo.toml
+===
+--- 389-ds-base-2.3.1+dfsg1.new.orig/src/plugins/pwdchan/Cargo.toml
 389-ds-base-2.3.1+dfsg1.new/src/plugins/pwdchan/Cargo.toml
+@@ -17,7 +17,7 @@ paste = "1.*"
+ slapi_r_plugin = { path="../../slapi_r_plugin" }
+ uuid = { version = "0.8", features = [ "v4" ] }
+ openssl = { version = "0.10" }
+-base64 = "0.13"
++base64 = "0.21"
+ 
+ [build-dependencies]
+ cc = { version = "1.0", features = ["parallel"] }
diff -Nru 389-ds-base-2.3.1+dfsg1/debian/patches/series 
389-ds-base-2.3.1+dfsg1/debian/patches/series
--- 389-ds-base-2.3.1+dfsg1/debian/patches/series   2023-01-24 
11:21:16.0 +
+++ 389-ds-base-2.3.1+dfsg1/debian/patches/series   2023-06-11 

Bug#1035393: unblock: rust-env-logger-0.7/0.7.1-4

[plugwash]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock

Please unblock package rust-env-logger-0.7

A bug was raised regarding missing breaks/replaces in rust-env-logger-0.7,
analysis revealed that debcargo was setting breaks+replaces against a virtual
package, the breaks against the virtual package are considered by dpkg but the
replaces are not leading to the potential for unpack failures during upgrade
from bullseye to bookworm.

This upload manually changes the breaks+replaces to point at the physical
package instead. How this should be handled automatically in debcargo is
under consideration, but a repack with the latest debcargo would probablly not
be appropriate at this point in the release cycle anyway.

unblock rust-env-logger-0.7/0.7.1-4

-- System Information:
Debian Release: 10.11
  APT prefers oldstable-updates
  APT policy: (500, 'oldstable-updates'), (500, 'oldstable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386, arm64

Kernel: Linux 4.19.0-18-amd64 (SMP w/4 CPU cores)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_GB:en (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
diff -Nru rust-env-logger-0.7-0.7.1/debian/changelog 
rust-env-logger-0.7-0.7.1/debian/changelog
--- rust-env-logger-0.7-0.7.1/debian/changelog  2021-10-23 19:30:54.0 
+
+++ rust-env-logger-0.7-0.7.1/debian/changelog  2023-05-02 07:01:45.0 
+
@@ -1,3 +1,11 @@
+rust-env-logger-0.7 (0.7.1-4) unstable; urgency=medium
+
+  * Team upload.
+  * Declare breaks+replaces against physical package, rather than virtual one
+(Closes: #1034949)
+
+ -- Peter Michael Green   Tue, 02 May 2023 07:01:45 +
+
 rust-env-logger-0.7 (0.7.1-3) unstable; urgency=medium
 
   * Team upload.
diff -Nru rust-env-logger-0.7-0.7.1/debian/control 
rust-env-logger-0.7-0.7.1/debian/control
--- rust-env-logger-0.7-0.7.1/debian/control2021-10-23 19:30:54.0 
+
+++ rust-env-logger-0.7-0.7.1/debian/control2023-05-02 07:01:07.0 
+
@@ -39,8 +39,8 @@
  librust-env-logger-dev (= ${binary:Version}),
  librust-env-logger-0-dev (= ${binary:Version}),
  librust-env-logger-0.7.1-dev (= ${binary:Version})
-Replaces: librust-env-logger-0.7.1-dev
-Breaks: librust-env-logger-0.7.1-dev
+Replaces: librust-env-logger-dev (<< 0.7.2)
+Breaks: librust-env-logger-dev (<< 0.7.2)
 Description: Logging implementation for `log` which is configured via an 
environment variable - Rust source code
  This package contains the source for the Rust env_logger crate, packaged by
  debcargo for use with cargo and dh-cargo.

Bug#1035383: unblock (pre-approval): brial/1.2.11-2.1

[plugwash]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock

It was discovered about a month ago by Bastian Germann that python3-brial needs
python3-sage, and he added a dependency.

Unfortunately this left the package uninstallable on about half of release
architectures. Normally this would block migration to testing, but elbrus
forced the package in.

I filed a bug 1034443 with grave severity for this based on the following
understanding.

* An uninstallable package is unusable
* The "is this package unusable" criteria is applied to each binary package
  individually and for packages that are built seperately for multiple
  architectures is applied on each arhictecture individually. Or to put it
  another way my understanding the criteria is applied to each "deb"
  individually.

I don't think these are explicitly stated anywhere, but they are consistent
with my experiance of how things are typically done in Debian. They are
consistent with the state of testing (other than python3-brial there are no
uninstallable arch-specific binary packages in testing) and they are consistent
with the rules britney normally enforces for testing migration.

Elbrus replied to my bug report, challangeing why I had filed it as rc, I
explained my position and he seemed somewhat but not totally convinced.

I would like to ask for a release team ruling on this bug. If the release agree
it is rc and should be fixed, I am happy to make an upload doing so. On the
other hand if the release team decide that it is not rc and should not be fixed
at this stage in the release process I'm happy to abide by that descision.

The debdiff for my proposed upload can be found at 
https://bugs.debian.org/cgi-bin/bugreport.cgi?att=2;bug=1034443;filename=brial.debdiff;msg=40

unblock brial/1.2.11-2.1

Bug#1034443: python3-brial: uninstallable on arcitectures where sagemath is unavailable

[plugwash]

Hell All, I have just made singular independent from brial

Thanks for dealing with that part of the issue.

Otherwise it must be keep in mind that Sage is mostly umbrella software.
That means that the dependency of brian on sage material is odd.

odd as it may be, it seems the dependency of python3-brial
on sagemath is real.

I've prepared a NMU, and intend to open a pre-approval
request with the release team. If you have any objections
to the NMU please tell me ASAP (I do not intend to upload
it until I receive a response from the release team, if you
would preffer to make the upload yourself that is fine too).
diff -Nru brial-1.2.11/debian/changelog brial-1.2.11/debian/changelog
--- brial-1.2.11/debian/changelog   2023-04-03 12:13:10.0 +
+++ brial-1.2.11/debian/changelog   2023-05-02 10:39:34.0 +
@@ -1,3 +1,11 @@
+brial (1.2.11-2.1) bookworm-staging; urgency=medium
+
+  * Non-Maintainer upload.
+  * Limit architectures for python3-brial package  to architectures where
+sagemath is available (Closes: #1034443).
+
+ -- Peter Michael Green   Tue, 02 May 2023 10:39:34 
+
+
 brial (1.2.11-2) unstable; urgency=medium
 
   * Team upload.
diff -Nru brial-1.2.11/debian/control brial-1.2.11/debian/control
--- brial-1.2.11/debian/control 2023-04-03 12:11:20.0 +
+++ brial-1.2.11/debian/control 2023-04-08 15:18:38.0 +
@@ -22,7 +22,7 @@
 Homepage: https://github.com/BRiAl
 
 Package: python3-brial
-Architecture: any
+Architecture: amd64 arm64 i386 riscv64
 Section: python
 Depends: python3-sage,
  ${misc:Depends},

Bug#1035041: unblock: rust-h2/0.3.13-2

[plugwash]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock

Please unblock package rust-h2

The new version fixes CVE-2023-26964/RUSTSEC-2023-0034 it consists of two
commits backported from upstream, one for the CVE fix itself and one to fix
a regression caused by the CVE fix. The fix has been uploaded to unstable
and autopkgtests passed on all architectures where britney runs them.

Please also schedule binnmus for rust-sequoia-sq, rust-tealdeer and sccache so
that they pick up the fix. I have done local rebuild tests on these packages
and they all built sucessfully.

unblock rust-h2/0.3.13-2

-- System Information:
Debian Release: 10.11
  APT prefers oldstable-updates
  APT policy: (500, 'oldstable-updates'), (500, 'oldstable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386, arm64

Kernel: Linux 4.19.0-18-amd64 (SMP w/4 CPU cores)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_GB:en (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
diff -Nru rust-h2-0.3.13/debian/changelog rust-h2-0.3.13/debian/changelog
--- rust-h2-0.3.13/debian/changelog 2022-06-21 15:47:48.0 +
+++ rust-h2-0.3.13/debian/changelog 2023-04-23 09:50:43.0 +
@@ -1,3 +1,15 @@
+rust-h2 (0.3.13-2) unstable; urgency=medium
+
+  * Team upload.
+  * Package h2 0.3.13 from crates.io using debcargo 2.5.0
+  * Add patch limit-pending-accept-reset-streams.patch cherry picked from
+upstream to fix denial of service vulnerability. CVE-2023-26964
+RUSTSEC-2023-0034 (Closes: #1034723)
+  * Add patch fix-regression.patch chrerry picked from upstream to fix a
+regression introduced by the above patch.
+
+ -- Peter Michael Green   Sun, 23 Apr 2023 09:50:43 +
+
 rust-h2 (0.3.13-1) unstable; urgency=medium
 
   * Team upload.
diff -Nru rust-h2-0.3.13/debian/copyright rust-h2-0.3.13/debian/copyright
--- rust-h2-0.3.13/debian/copyright 2022-06-21 15:47:48.0 +
+++ rust-h2-0.3.13/debian/copyright 2023-04-23 09:50:43.0 +
@@ -7,12 +7,12 @@
 Files: *
 Copyright:
  2017-2019 Carl Lerche 
- 2017-2022 Sean McArthur 
+ 2017-2023 Sean McArthur 
 License: MIT
 
 Files: debian/*
 Copyright:
- 2018-2022 Debian Rust Maintainers 

+ 2018-2023 Debian Rust Maintainers 

  2018-2019 Wolfgang Silbermayr 
 License: MIT
 
diff -Nru rust-h2-0.3.13/debian/copyright.debcargo.hint 
rust-h2-0.3.13/debian/copyright.debcargo.hint
--- rust-h2-0.3.13/debian/copyright.debcargo.hint   2022-06-21 
15:47:48.0 +
+++ rust-h2-0.3.13/debian/copyright.debcargo.hint   2023-04-23 
09:50:43.0 +
@@ -25,8 +25,8 @@
 
 Files: debian/*
 Copyright:
- 2018-2022 Debian Rust Maintainers 

- 2018-2022 Wolfgang Silbermayr 
+ 2018-2023 Debian Rust Maintainers 

+ 2018-2023 Wolfgang Silbermayr 
 License: MIT
 
 License: MIT
diff -Nru rust-h2-0.3.13/debian/patches/fix-regression.patch 
rust-h2-0.3.13/debian/patches/fix-regression.patch
--- rust-h2-0.3.13/debian/patches/fix-regression.patch  1970-01-01 
00:00:00.0 +
+++ rust-h2-0.3.13/debian/patches/fix-regression.patch  2023-04-23 
09:50:43.0 +
@@ -0,0 +1,19 @@
+commit 1c6fa285afe436ca2a1f8abd38a6389353f360b6
+Author: Sean McArthur 
+Date:   Mon Apr 17 14:08:02 2023 -0400
+
+fix: pending-accept remotely-reset streams pattern was checking is_local
+
+diff --git a/src/proto/streams/state.rs b/src/proto/streams/state.rs
+index b9612addc..76638fc87 100644
+--- a/src/proto/streams/state.rs
 b/src/proto/streams/state.rs
+@@ -362,7 +362,7 @@ impl State {
+ 
+ pub fn is_remote_reset() -> bool {
+ match self.inner {
+-Closed(Cause::Error(ref e)) => e.is_local(),
++Closed(Cause::Error(ref e)) => !e.is_local(),
+ _ => false,
+ }
+ }
diff -Nru 
rust-h2-0.3.13/debian/patches/limit-pending-accept-reset-streams.patch 
rust-h2-0.3.13/debian/patches/limit-pending-accept-reset-streams.patch
--- rust-h2-0.3.13/debian/patches/limit-pending-accept-reset-streams.patch  
1970-01-01 00:00:00.0 +
+++ rust-h2-0.3.13/debian/patches/limit-pending-accept-reset-streams.patch  
2023-04-23 09:50:43.0 +
@@ -0,0 +1,288 @@
+commit 5bc8e72e5fcbd8ae2d3d9bc78a1c0ef0040bcc39
+Author: Sean McArthur 
+Date:   Wed Apr 12 12:23:56 2023 -0400
+
+fix: limit the amount of pending-accept reset streams
+
+Streams that have been received by the peer, but not accepted by the
+user, can also receive a RST_STREAM. This is a legitimate pattern: one
+could send a request and then shortly after, realize it is not needed,
+sending a CANCEL.
+
+However, since those streams are now "closed", they don't count towards
+the max concurrent streams. So, they will sit in the accept queue, using
+memory.
+
+In most cases, the user is calling 

Bug#1034388: unblock: rust-spin/0.9.5-2

[plugwash]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock

Please unblock package rust-spin

RUSTSEC-2023-0031 was filed aginst the rust-spin package. While I do not believe
any applications in Debian are affected by this issue I would still rather we
avoided shipping packages with known soundness bugs where possible.

The upstream patch is a bit larger than I would ideally like, but I don't think
it would be appropriate to try and re-write the patch.

The package has functioning autopkgtests running the upstream testsuite with
various feature settings. The results of my local tests on the new version were
the same as the results on debci for the version currently in testing/unstable
(some feature settingss are known to fail to build). The patch also adds a new
regression test related to the changes.

unblock rust-spin/0.9.5-2
diff -Nru rust-spin-0.9.5/debian/changelog rust-spin-0.9.5/debian/changelog
--- rust-spin-0.9.5/debian/changelog2023-02-23 11:34:54.0 +
+++ rust-spin-0.9.5/debian/changelog2023-04-13 23:42:04.0 +
@@ -1,3 +1,10 @@
+rust-spin (0.9.5-2) unstable; urgency=medium
+
+  * Team upload.
+  * Add patch for RUSTSEC-2023-0031 (Closes: #1034374)
+
+ -- Peter Michael Green   Thu, 13 Apr 2023 23:42:04 +
+
 rust-spin (0.9.5-1) unstable; urgency=medium
 
   * Team upload.
diff -Nru rust-spin-0.9.5/debian/patches/RUSTSEC-2023-0031.patch 
rust-spin-0.9.5/debian/patches/RUSTSEC-2023-0031.patch
--- rust-spin-0.9.5/debian/patches/RUSTSEC-2023-0031.patch  1970-01-01 
00:00:00.0 +
+++ rust-spin-0.9.5/debian/patches/RUSTSEC-2023-0031.patch  2023-04-13 
23:39:43.0 +
@@ -0,0 +1,277 @@
+commit 2a018b69870853118d7cc8a55562ff905c67d271
+Author: UnknownEclipse <43258146+unknownecli...@users.noreply.github.com>
+Date:   Mon Apr 3 01:36:30 2023 -0700
+
+Fix #148 (UB in `try_call_once`) (#149)
+
+* Fix UB in `try_call_once` and add regression test.
+
+* Fix MSRV
+
+* Clean up `try_call_once` impl
+
+* Remove unused import
+
+diff --git a/src/once.rs b/src/once.rs
+index 0bfc7c1..31700dc 100644
+--- a/src/once.rs
 b/src/once.rs
+@@ -130,8 +130,6 @@ mod status {
+ }
+ use self::status::{AtomicStatus, Status};
+ 
+-use core::hint::unreachable_unchecked as unreachable;
+-
+ impl Once {
+ /// Performs an initialization routine once and only once. The given 
closure
+ /// will be executed if this is the first time `call_once` has been 
called,
+@@ -208,111 +206,92 @@ impl Once {
+ /// }
+ /// ```
+ pub fn try_call_once Result, E>(, f: F) -> 
Result<, E> {
+-// SAFETY: We perform an Acquire load because if this were to return 
COMPLETE, then we need
+-// the preceding stores done while initializing, to become visible 
after this load.
+-let mut status = self.status.load(Ordering::Acquire);
++if let Some(value) = self.get() {
++Ok(value)
++} else {
++self.try_call_once_slow(f)
++}
++}
+ 
+-if status == Status::Incomplete {
+-match self.status.compare_exchange(
++#[cold]
++fn try_call_once_slow Result, E>(, f: F) -> 
Result<, E> {
++loop {
++let xchg = self.status.compare_exchange(
+ Status::Incomplete,
+ Status::Running,
+-// SAFETY: Success ordering: We do not have to synchronize 
any data at all, as the
+-// value is at this point uninitialized, so Relaxed is 
technically sufficient. We
+-// will however have to do a Release store later. However, 
the success ordering
+-// must always be at least as strong as the failure ordering, 
so we choose Acquire
+-// here anyway.
+ Ordering::Acquire,
+-// SAFETY: Failure ordering: While we have already loaded the 
status initially, we
+-// know that if some other thread would have fully 
initialized this in between,
+-// then there will be new not-yet-synchronized accesses done 
during that
+-// initialization that would not have been synchronized by 
the earlier load. Thus
+-// we use Acquire to ensure when we later call force_get() in 
the last match
+-// statement, if the status was changed to COMPLETE, that 
those accesses will become
+-// visible to us.
+ Ordering::Acquire,
+-) {
+-Ok(_must_be_state_incomplete) => {
+-// The compare-exchange succeeded, so we shall initialize 
it.
+-
+-// We use a guard (Finish) to catch panics caused by 
builder
+-let finish = Finish {
+-status: ,
+-};
+-let val = match f() {
+-Ok(val) => val,
+-

Bug#1033541: RM: rust-lock-api-0.1 rust-parking-lot-0.7 rust-parking-lot-core-0.4 -- ROM; old versions no longer in use and affected by security bug

[plugwash]

Package: ftp.debian.org
Severity: normal

Please remove rust-lock-api-0.1, rust-parking-lot-0.7 and
rust-parking-lot-core-0.4

All are older versions, that are no longer in use after tokio was updated to
1.x. rust-lock-api-0.1 is also affected by RUSTSEC-2020-0070

Bug#1023787: transition: liblxqt

[plugwash]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: transition

It appears a liblxqt transition has started, possiblly inadvertantly.

Back in June, Simon Quigley prepared an update of the lxqt stack. He announced
that he intended to update the stack in unstable, but only actually did so in
experimental.

Part of this update was a transition from liblxqt0 to liblxqt1. The dev package
has also been renamed from liblxqt0 to liblxqt1-dev, so this transition requires
sourceful uploads of all reverse dependencies.

In late October, Andrew Lee uploaded the new versions liblxqt and lxqt-session
to unstable, but did not upload the rest of the stack.

liblxqt has migrated to testing thanks to "smooth updates", leaving the lxqt
stack in testing in violation of "packages must be buildable within the same
release".

An automatic transition tracker has been set up at
https://release.debian.org/transitions/html/auto-liblxqt.html


-- System Information:
Debian Release: 10.11
  APT prefers oldstable-updates
  APT policy: (500, 'oldstable-updates'), (500, 'oldstable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386, arm64

Kernel: Linux 4.19.0-18-amd64 (SMP w/4 CPU cores)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_GB:en (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Bug#1013869: rust-reqwest: feature rustls-tls has disappeared

[plugwash]

On 27/06/2022 01:15, Jonas Smedegaard wrote:

Thanks for clarifying.

I consider it a *horrific* bug that an interface is explicitly
advertised as available, linking against it succeeds, yet it is
non-functional.

In my opinion this renders the whole package unsuitable for release, and
I hereby flag this bugreport as such.

Please as a minimum ensure that broken or missing features are *not*
advertised by the package.


I'll remove the rustls support completely until/unless it can be 
re-enabled in a sane form.


but lets be clear not every "feature" that exists in a rust crate 
actually provides useful functionality. The "feature" 
"rustls-native-certs" was never advertised as providing any particular 
functionality. At this point I have only removed features, I have not 
changed the functionality of any existing features. Depending on the 
"feature" "rustls-native-certs" would be just as useless with the 
unmodified upstream source as it would be with my patched version.


Assuming tokio-rustls and hyper-rustls are packaged, I do intend to 
switch the "rustls-tls" feature from being an alias for 
"rustls-tls-webpki-roots" to being an alias for 
"rustls-tls-native-roots" in line with what I believe is appropriate for 
Debian. Indeed I already have a patch in the package doing that, but the 
feature is currently removed completely by a patch later in the series.

Bug#1010322: rust-core-arch: should this package be removed.

[plugwash]

reassign 1010322 ftp.debian.org
retitle 1010322 RM: rust-core-arch ROM abandoned upstream, FTBFS for 
over a year, superseeded by functionality in standard library.

thanks


If noone objects I will turn this bug into a removal request in a week
or two.

There were no responses, so reassigning to ftp.debian.org for removal.

Bug#1010731: rust-semver-parser-0.9: should this package be removed.

[plugwash]

reassign 1010731 ftp.debian.org
retitle 1010731 RM: rust-semver-parser-0.9 ROM old version no longer in use.
thanks


If noone objects I will turn this bug into a removal request in a week
or two.

There were no responses, so reassigning to ftp.debian.org for removal.

Bug#1007882: RM: rust-weedle/0.12.0-2 rust-wasm-bindgen-webidl/0.2.75-1

[plugwash]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: rm

James McCoy and I have been working on updating the rust-nom package from
version 5 to version 7, this is needed to enable ICMP support in sniffglue and
I belive it is also needed to facilitate packaging of alacritty.

In addition to the rust-nom package (which is currently version 5.x in testing
and version 7.x in unstable) there is a rust-nom-4 package providing version
4.x and a rust-nom-3 package providing version 3.x. It would be possible to
introduce a rust-nom-5 package as well but I don't think it's justifiable to
introduce yet another version at this time.

All but one of the reverse (build-)dependencies of nom 5.x have been ported to
nom 7.x, either by new upstream versions or by patching. That leaves
rust-weedle. rust-weedle has a single reverse (build-)dependency
rust-wasm-bindgen-webidl, neither of them are currently used by any applications
in Debian.

The version of rust-weedle currently in testing is the latest upstream version
and depends on nom 5.x. I tried patching it to use nom 7.x but failed to do
so, I also filed a bug report upstream but got no response. 

I then decided to try patching rust-weedle to use nom 4.x since that would at
least avoid introducing yet another version of nom to the archive. I did so
by reverting the upstream commit porting it from 4.x to 5.x. The tests passed
and I uploaded it as rust-weedle 0.12.0-2.

Unfortunately after uploading it I discovered that the autopkgtest for
rust-wasm-bindgen-webidl failed and it became clear that my upload of
rust-weedle had caused an API break. I attempted to try and adjust the
patch to avoid the API break but was not successful, I don't think the version
with the API break can be considered fit for release.

At that point I filed bug 1007026 to give the rest of the rust team a chance
to comment on the issue and said that if noone objected I planned to file
a removal request with the release team.

I now request that rust-weedle and rust-wasm-bindgen-webidl are removed from
testing so that rust-nom and it's reverse dependencies can migrate.

-- System Information:
Debian Release: 10.11
  APT prefers oldstable-updates
  APT policy: (500, 'oldstable-updates'), (500, 'oldoldstable'), (500, 
'oldstable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386, arm64

Kernel: Linux 4.19.0-10-amd64 (SMP w/4 CPU cores)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_GB:en (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Bug#1005020: RM: rust-rand-os -- ROM; obsolete and uninstallable/unbuildable

[plugwash]

Package: ftp.debian.org
Severity: normal

Upstream incorportated functionality in the rand_os crate into the
rand_core crate and deprecated the rand_os crate over two years ago.
There have been no further releases since the release announcing the
deprecation and the crate no longer appears in the master branch of the upstream
git repository.

The dependencies and build-dependencies of rust-rand-os are no longer
satisfiable with the new version of the rand_core crate that I have just
uploaded to Debian.

All the former reverse dependencies of the crate in Debian have now moved
away from it, so I think it's time for the crate to go. I filed a "should this
package be remove" bug a fortnight ago in case any other rust team members had
an opinion on the issue and received no responses.

Bug#1002148: qwertone: FTBFS: unsatisfiable build-dependencies

[plugwash]

The rust gtk stack is now installable again, but it looks like qwertone 
needs some work to build with

the new version of the stack.

It looks like upstream has updated the code for 0.14 but attempting to 
grab the upstream commit and
apply it as a patch resulted in a bunch of hunks failling, so it may be 
better to just update to a new

upstream version.

Bug#1000756: freedv: FTBFS: varicode.h: No such file or directory

[plugwash]

This appears to be fixed by version 1.6.1-1 in experimental? is there 
any blocker for uploading it to unstable?

Bug#1000458: bullseye-pu: package wget/1.21-1+deb11u1

[plugwash]

Package: release.debian.org
Severity: normal
Tags: bullseye
User: release.debian@packages.debian.org
Usertags: pu

When downloading a file greater than 2GB on a 32-bit system wget on bullseye
will truncate it to 2GB. No error is reported, the length of the file is simply
reported as less than it's true length. This was reported to me by raspberry pi
staff, but I can reproduce it in a Debian i386 environment, so it's not
raspberry pi, raspbian or arm specific.

I confirmed that the issue did not affect bookworm and after some searching
found the upstream commit and bug report that fix it. 
https://gitlab.com/gnuwget/wget/-/commit/90631a6fe54eabd9c80ede5c70bc916719e76cfe

I have rated this issue as important, being unable to download large files (for
example OS images) is a significant restriction on the usefulness of wget. There
is a possible argument that it deserves grave severity based on "non-serious
data loss" (for example if someone used wget to copy a file to another system
before deleting the original) but I think that argument is tenuous, so I decided
to stick with important.

I filed this as bug 999744 in Debian  on the 15th November and have not received
a maintainer response, hence I am starting the PU process myself. I have tested
the fix in raspbian bullseye and also in a debian bullsyeye i386 chroot. I have
also released the fix to raspbian bullseye.
diff -Nru wget-1.21/debian/changelog wget-1.21/debian/changelog
--- wget-1.21/debian/changelog  2021-01-02 10:58:25.0 +
+++ wget-1.21/debian/changelog  2021-11-23 14:34:25.0 +
@@ -1,3 +1,11 @@
+wget (1.21-1+deb11u1) bullseye-staging; urgency=medium
+
+  * Non-maintainer upload.
+  * Apply upstream patch to fix downloads over 2GB on 32-bit systems.
+closes: bug#999744
+
+ -- Peter Michael Green   Tue, 23 Nov 2021 14:34:25 +
+
 wget (1.21-1) unstable; urgency=medium
 
   * new upstream release from 2020-12-31
diff -Nru wget-1.21/debian/patches/fix-large-downloads-on-32-bit 
wget-1.21/debian/patches/fix-large-downloads-on-32-bit
--- wget-1.21/debian/patches/fix-large-downloads-on-32-bit  1970-01-01 
00:00:00.0 +
+++ wget-1.21/debian/patches/fix-large-downloads-on-32-bit  2021-11-23 
14:31:49.0 +
@@ -0,0 +1,26 @@
+Debian patch based on the upstream commit below, defuzzed
+in the context of the debian package.
+
+commit 90631a6fe54eabd9c80ede5c70bc916719e76cfe
+Author: Tim Rühsen 
+Date:   Sun Apr 11 12:53:16 2021 +0200
+
+* src/wget.h: Use strtoll() for str_to_wgint
+
+This fixes a regression reported at https://savannah.gnu.org/bugs/?60353.
+
+Reported-by: Michal Ruprich
+
+Index: wget-1.21/src/wget.h
+===
+--- wget-1.21.orig/src/wget.h
 wget-1.21/src/wget.h
+@@ -144,7 +144,7 @@ typedef int64_t wgint;
+ #define WGINT_MAX INT64_MAX
+ typedef wgint SUM_SIZE_INT;
+ 
+-#define str_to_wgint strtol
++#define str_to_wgint strtoll
+ 
+ #include "options.h"
+ 
diff -Nru wget-1.21/debian/patches/series wget-1.21/debian/patches/series
--- wget-1.21/debian/patches/series 2019-07-20 16:10:06.0 +
+++ wget-1.21/debian/patches/series 2021-11-23 14:31:49.0 +
@@ -1,3 +1,4 @@
 wget-doc-remove-usr-local-in-sample.wgetrc
 wget-doc-remove-usr-local-in-wget.texi
 wget-passive_ftp-default
+fix-large-downloads-on-32-bit

Bug#999735: RM: rust-tokio-process -- ROM; uninstallable/unbuildable, superseeded upstream, no reverse dependencies.

[plugwash]

Package: ftp.debian.org
Severity: normal

rust-tokio-process depends on an old version of rust-futures and as-such
it's dependencies and build-dependencies are unsatisfiable.

Upstream the features of the tokio-process crate have been integrated into
the tokio crate and here are no reverse dependencies in debian, so it's time
for this package to go.

Bug#996673: nmu: libfilezilla_0.34.0-1

[plugwash]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: binnmu

libfilezilla needs to be rebuilt on the buildds  so it can migrate to testing
and restore consistency of the filezilla/libfilezilla packages there.

The binary packages are multi-arch: same, so I am filing this request for all
architectures to maintain multi-arch sync.

nmu libfilezilla_0.34.0-1 . ANY . unstable . -m "Rebuild on buildd"

Bug#993216: dh-cargo timestamp fix doesn't cover changelogs installed to /usr/share/doc

[plugwash]

package: dh-cargo

Recently a substantial number of upstream cargo packages started using 
timestamps the ftpmasters
consider reject-worthy, I believe this was done in the name of 
reproducibility.


After it became clear that this was a larger-scale issue and we got sick 
of working around this in individual packages, sylvestre implemented a 
workaround in dh_cargo. Unfortunately this fix does not seem to be complete.


Specifically it seems that when an upstream changelog is installed by 
dh_installchangelogs  to /usr/share/doc it doesn't get the timestamp 
fixing treatment. Presumablly because dh_installchangelogs pulls it from 
the source tree while the dh_cargo timestamp fixing happens on the 
output tree.


I've worked around it for now in crossbeam-deque, but I don't know how 
many other packages are
potentially effected (e.g. have changelogs with dodgy timestamps in 
their upstream packaging) and whether this is something we need to deal 
with centrally.

Bug#993079: release.debian.org: autopkgtest scheduling does not seem to understand virtual packages correctly.

[plugwash]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: britney

Rust packaging makes heavy use of versioned virtual packages to allow
multiple versions of a crate to coexist if needed (though this functionality
is only occasionally actually used).

Britney now seems to understand versioned virtual packages (at least in simple
cases) for the main migration and for auto removals, but it still does not
seem to properly understand them for testing migration.

For example at the time of writing this bug report (though probablly not for
long afterwards as I intend to upload a workaround) this can be seen with
rust-datetime and rust-zoneinfo-compiled.

librust-zoneinfo-compiled-dev 0.4.8-1 in bookworm depends on
librust-datetime-0.4+default-dev (>= 0.4.7-~~) which is provided by
librust-datetime-dev 0.4.7-2

librust-zoneinfo-compiled-dev 0.5.1-2 in sid depends on
librust-datetime-0.5-dev (>= 0.5.2-~~) which is provided by
librust-datetime-dev 0.5.2-3

rust-datetime shows

> Migrates after: rust-exa, rust-iso8601, rust-zoneinfo-compiled
> Migration status for rust-datetime (0.4.7-2 to 0.5.2-3): BLOCKED: 
> Rejected/violates migration policy/introduces a regression
> Issues preventing migration:
> autopkgtest for rust-datetime/0.5.2-3: amd64: Pass, arm64: Pass, armhf: Pass, 
> i386: Pass, ppc64el: Pass
> autopkgtest for rust-zoneinfo-compiled/0.4.8-1: amd64: Regression ♻ 
> (reference ♻), arm64: Regression ♻ (reference ♻), armhf: Regression ♻ 
> (reference ♻), i386: Regression ♻ (reference ♻), ppc64el: Regression ♻ 
> (reference ♻)
> Too young, only 4 of 5 days old
> Build-Depends(-Arch): rust-datetime rust-iso8601
> Depends: rust-datetime rust-iso8601
> Implicit dependency: rust-datetime rust-exa
> Implicit dependency: rust-datetime rust-zoneinfo-compiled
> Additional info:
> Piuparts tested OK - 
> https://piuparts.debian.org/sid/source/r/rust-datetime.html
> Not considered

While rust-zoneinfo-compiled shows

> Migration status: Blocked. Can't migrate due to a non-migratable dependency. 
> Check status below.
> Blocked by: rust-datetime
> Migrates after: rust-exa
> Migration status for rust-zoneinfo-compiled (0.4.8-1 to 0.5.1-2): BLOCKED: 
> Cannot migrate due to another item, which is blocked (please check which 
> dependencies are stuck)
> Issues preventing migration:
> Build-Depends(-Arch): rust-zoneinfo-compiled rust-datetime (not considered)
> Depends: rust-zoneinfo-compiled rust-datetime (not considered)
> Invalidated by build-dependency
> Invalidated by dependency
> Implicit dependency: rust-zoneinfo-compiled rust-exa
> Additional info:
> Piuparts tested OK - 
> https://piuparts.debian.org/sid/source/r/rust-zoneinfo-compiled.html
> autopkgtest for rust-zoneinfo-compiled/0.5.1-2: amd64: Pass, arm64: Pass, 
> armhf: Pass, i386: Pass, ppc64el: Pass
> Required age reduced by 3 days because of autopkgtest
> 5 days old (needed 2 days)
> Not considered

We see that when it comes to excuses britney understands that these packages
need to go in togehter, rust-datetime is shown as having an implicit dependency
on rust-zoneinfo-compiled and rust-zoneinfo-compiled is shown as having
a dependency and build-dependency on rust-datetime.

However when it comes to the autopkgtest britney is refusing to migrate
rust-datetime based on an autopkgtest of the old rust-datetime. When
we look at the log we see the regular dependency installation fails

> autopkgtest: WARNING: package librust-zoneinfo-compiled-dev is not installed 
> though it should be
> autopkgtest: WARNING: Test dependencies are unsatisfiable with using apt 
> pinning. Retrying with using all packages from unstable

It then goes into the fallback dependency installation, this succeeds but it
installs the version of librust-zoneinfo-compiled-dev from sid. Autopkgtest
then tries to run the tests from testings rust-zoneinfo-compiled against
the librust-zoneinfo-compiled-dev from sid which fails with a crate directory
not found error.

I belive this has been worked around in newer versions of debcargo by marking
the tests as skip if uninstallable which prevents autopkgtest from heading
down the fallback dependency solving rabbit hole, but it still seems less than
ideal for britney to be behaving like this and we still have packages created
with older versions of debcargo in the archive.

-- System Information:
Debian Release: 10.5
  APT prefers oldstable-updates
  APT policy: (500, 'oldstable-updates'), (500, 'oldoldstable'), (500, 
'oldstable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386, arm64

Kernel: Linux 4.19.0-10-amd64 (SMP w/4 CPU cores)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_GB:en (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Bug#989894: ITP: (reintroduce) ghextris -- A Tetris-like game on a hexagonal grid

[plugwash]

Package: wnpp
Severity: wishlist
Owner: plugwash 

* Package name: ghextris
  Version : 0.9.0
  Upstream Author : Mikko Rauhala
* URL : http://mjr.iki.fi/software/ghextris
* License : GPLv2+
  Programming Lang: Python
  Description : A Tetris-like game on a hexagonal grid

The object of the game is basically the same as in Tetris; use the pieces 
that fall down from the top of the game area to construct fully filled lines, 
which will then disappear to make room for more pieces. The twist is that the 
pieces are composed of hexagonal blocks, so your visualization skills will get
an extra workout. 

ghextris was in Debian from Sarge through to Stretch, but was removed due
to dependencies on obsolete gnome2 related libraries. I have ported it to a
more modern python3/python3-gi/gtk3/glade technology stack and intend to
reintrouce it.

I intend to keep the package within the games team,

Bug#988453: buster-pu: package rust-rustyline/3.0.0-2

[plugwash]

Package: release.debian.org
Severity: normal
Tags: buster
User: release.debian@packages.debian.org
Usertags: pu

rust-rustyline fails to build in buster due to a change of behaviour in rustc,
this has been fixed in bullseye/sid for some time and I was able to locate
the upstream commit that fixes the failure by bisecting and then apply it to
the package from buster.

I have tested the patched package builds and I have also run the upstream
testsuite (which passed). rust-rustyline does not appear to have any reverse
dependencies.
diff -Nru rust-rustyline-3.0.0/debian/changelog 
rust-rustyline-3.0.0/debian/changelog
--- rust-rustyline-3.0.0/debian/changelog   2019-02-03 20:19:06.0 
+
+++ rust-rustyline-3.0.0/debian/changelog   2021-05-04 09:27:11.0 
+
@@ -1,3 +1,11 @@
+rust-rustyline (3.0.0-2+deb10u1) buster; urgency=medium
+
+  * Team upload.
+  * Apply upstream patch to fix build with newer rustc.
+(Closes: 988025)
+
+ -- Peter Michael Green   Tue, 04 May 2021 09:27:11 +
+
 rust-rustyline (3.0.0-2) unstable; urgency=medium
 
   * Package rustyline 3.0.0 from crates.io using debcargo 2.2.10
diff -Nru rust-rustyline-3.0.0/debian/patches/newer-rustc.patch 
rust-rustyline-3.0.0/debian/patches/newer-rustc.patch
--- rust-rustyline-3.0.0/debian/patches/newer-rustc.patch   1970-01-01 
00:00:00.0 +
+++ rust-rustyline-3.0.0/debian/patches/newer-rustc.patch   2021-05-04 
09:26:41.0 +
@@ -0,0 +1,49 @@
+commit e383956f3fc9f313d8cf979f1a9772bea9eb1eb8
+Author: gwenn 
+Date:   Fri May 17 19:20:14 2019 +0200
+
+Try to fix nightly build
+
+See #217
+
+diff --git a/examples/example.rs b/examples/example.rs
+index 8bb2e7e..204791f 100644
+--- a/examples/example.rs
 b/examples/example.rs
+@@ -80,8 +80,8 @@ fn main() {
+ loop {
+ let readline = rl.readline(PROMPT);
+ match readline {
+-Ok(line) => {
+-rl.add_history_entry(line.as_ref());
++Ok(ref line) => {
++rl.add_history_entry(line);
+ println!("Line: {}", line);
+ }
+ Err(ReadlineError::Interrupted) => {
+diff --git a/src/history.rs b/src/history.rs
+index b1cb596..b7cc317 100644
+--- a/src/history.rs
 b/src/history.rs
+@@ -148,7 +148,7 @@ impl History {
+ let file = File::open()?;
+ let rdr = BufReader::new(file);
+ for line in rdr.lines() {
+-self.add(line?.as_ref()); // TODO truncate to MAX_LINE
++self.add(line?); // TODO truncate to MAX_LINE
+ }
+ Ok(())
+ }
+diff --git a/src/lib.rs b/src/lib.rs
+index 4f6162b..54672fb 100644
+--- a/src/lib.rs
 b/src/lib.rs
+@@ -624,7 +624,7 @@ fn readline_raw(
+ let user_input = readline_edit(prompt, initial, editor, _mode);
+ if editor.config.auto_add_history() {
+ if let Ok(ref line) = user_input {
+-editor.add_history_entry(line.as_ref());
++editor.add_history_entry(line);
+ }
+ }
+ drop(guard); // disable_raw_mode(original_mode)?;
diff -Nru rust-rustyline-3.0.0/debian/patches/series 
rust-rustyline-3.0.0/debian/patches/series
--- rust-rustyline-3.0.0/debian/patches/series  2019-02-03 20:19:06.0 
+
+++ rust-rustyline-3.0.0/debian/patches/series  2021-05-04 09:27:05.0 
+
@@ -1 +1,2 @@
 relax-dep-version.patch
+newer-rustc.patch

Bug#987573: unblock: jumpnbump/1.61-3.1

[plugwash]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock

Please unblock package jumpnbump

jumpnbump 1.61-3 and below crash when the player jumps and sound is enabled
(the default) on systems where type char is unsigned (e.g. arm* powerpc*). 
This is due to passing -1 to a parameter of type char wich then wraps to
255 causing an out of bounds array reference.

Unless the player knows this is a sound issue and knows how to disable sound
this renders the game unplayable on those architectures.

The fix for the issue is trivial and has been accepted upstream. It simply
consists of changing the parameter type from char to signed char.

unblock jumpnbump/1.61-3.1

-- System Information:
Debian Release: 10.5
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'oldoldstable'), (500, 'stable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.19.0-10-amd64 (SMP w/4 CPU cores)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_GB:en (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
diff -Nru jumpnbump-1.61/debian/changelog jumpnbump-1.61/debian/changelog
--- jumpnbump-1.61/debian/changelog 2020-07-26 15:48:41.0 +0100
+++ jumpnbump-1.61/debian/changelog 2021-04-24 13:35:52.0 +0100
@@ -1,3 +1,11 @@
+jumpnbump (1.61-3.1) unstable; urgency=medium
+
+  * Non-maintainer upload with maintainers approval.
+  * Apply upstream fix to prevent crash on systems where char is unsigned.
+(Closes: 987333)
+
+ -- Peter Michael Green   Sat, 24 Apr 2021 13:35:52 +0100
+
 jumpnbump (1.61-3) unstable; urgency=medium
 
   * Backport post-release patch from upstream to add future gcc
diff -Nru jumpnbump-1.61/debian/patches/0018-Fix-char-signedness.patch 
jumpnbump-1.61/debian/patches/0018-Fix-char-signedness.patch
--- jumpnbump-1.61/debian/patches/0018-Fix-char-signedness.patch
1970-01-01 01:00:00.0 +0100
+++ jumpnbump-1.61/debian/patches/0018-Fix-char-signedness.patch
2021-04-24 13:29:18.0 +0100
@@ -0,0 +1,32 @@
+commit 8a6873baa395f16048c6865f7036650a3b2bbe76
+Author: Frank Birbacher 
+Date:   Sun Dec 27 12:59:33 2020 +
+
+Fix dj channel signedness
+
+diff --git a/dj.h b/dj.h
+index 07f4a32..985548b 100644
+--- a/dj.h
 b/dj.h
+@@ -115,7 +115,7 @@ extern void dj_mix(void);
+ extern char dj_set_num_sfx_channels(char num_channels);
+ extern void dj_set_sfx_volume(char volume);
+ extern char dj_get_sfx_volume(void);
+-extern void dj_play_sfx(unsigned char sfx_num, unsigned short freq, char 
volume, char panning, unsigned short delay, char channel);
++extern void dj_play_sfx(unsigned char sfx_num, unsigned short freq, char 
volume, char panning, unsigned short delay, signed char channel);
+ extern char dj_get_sfx_settings(unsigned char sfx_num, sfx_data *data);
+ extern char dj_set_sfx_settings(unsigned char sfx_num, sfx_data *data);
+ extern void dj_set_sfx_channel_volume(char channel_num, char volume);
+diff --git a/sdl/sound.c b/sdl/sound.c
+index ff1ee7e..4ea56af 100644
+--- a/sdl/sound.c
 b/sdl/sound.c
+@@ -357,7 +357,7 @@ void dj_set_sfx_volume(char volume)
+   SDL_UnlockAudio();
+ }
+ 
+-void dj_play_sfx(unsigned char sfx_num, unsigned short freq, char volume, 
char panning, unsigned short delay, char channel)
++void dj_play_sfx(unsigned char sfx_num, unsigned short freq, char volume, 
char panning, unsigned short delay, signed char channel)
+ {
+   int slot;
+ 
diff -Nru jumpnbump-1.61/debian/patches/series 
jumpnbump-1.61/debian/patches/series
--- jumpnbump-1.61/debian/patches/series2020-07-26 15:46:24.0 
+0100
+++ jumpnbump-1.61/debian/patches/series2021-04-24 13:30:09.0 
+0100
@@ -1,2 +1,3 @@
 0015-menu-use-Pillow-instead-of-ImageMagick-for-level-pre.patch
 0017-Add-future-gcc-default-fno-common-and-fix-code.patch
+0018-Fix-char-signedness.patch

Bug#987294: nmu: rust-sniffglue_0.11.1-6

[plugwash]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: binnmu

rust-stackvector recently had a memory safety bug that was reported by the
rustsec team as a security issue and the Debian security team as a rc bug.

I fixed this in rust-stackvector 1.6.0-3 , but due to the way rust packaging
works applications need to be rebuilt before they will pick up the fix. 
Based on grepping the package indexes, I belive that rust-sniffglue is the only
application that is built against rust-stackvector (though it's possible that
there are applications built with older tooling that I have missed).

nmu rust-sniffglue_0.11.1-6 . ANY . unstable . -m "Rebuild against 
rust-stackvector 1.0.6-3"

-- System Information:
Debian Release: 10.5
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'oldoldstable'), (500, 'stable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.19.0-10-amd64 (SMP w/4 CPU cores)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_GB:en (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Bug#986282: unblock: rust-compiler-builtins/0.1.26-3

[plugwash]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock

Please unblock package rust-compiler-builtins

rust-compiler-builtins 0.1.26-2 FTBFS on armhf (and presumablly also armel
but I did not test that).

Rust upstream have renamed the old assembler support from asm! to llvm_asm!
in preperation for the introduction of a new assembler syntax. This breaks
the build of rust-compiler-builtins on arm (tested on armhf but presumablly
also affects armel).

rust-compiler-builtins uses inline asm in the arm implementations. There is also
some inline asm in the x86 and x86-64 implementations, but said asm is not
used when building for linux.

Upstream fixed this some time ago,
https://github.com/rust-lang/compiler-builtins/commit/cde22bc180391e75de1c189fe29f442ada86ccde
but unfortunately the new version was never uploaded to Debian and given that
it's a key package, it's too late for new upstream versions now. The upstream
commit also included some unrelated changes.

I therefore took the upstream commit, removed changes unrelated to the asm
change and applied it to the Debian package. I left in the changes to the
non-linux asm blocks figuring it was sensible to treat the asm change
as one unit.

unblock rust-compiler-builtins/0.1.26-3

-- System Information:
Debian Release: 10.5
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'oldoldstable'), (500, 'stable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.19.0-10-amd64 (SMP w/4 CPU cores)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_GB:en (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
diff -Nru rust-compiler-builtins-0.1.26/debian/cargo-checksum.json 
rust-compiler-builtins-0.1.26/debian/cargo-checksum.json
--- rust-compiler-builtins-0.1.26/debian/cargo-checksum.json2020-04-12 
21:42:44.0 +
+++ rust-compiler-builtins-0.1.26/debian/cargo-checksum.json2021-04-01 
11:34:12.0 +
@@ -1 +1 @@
-{"package":"036b035e9ebcd705affece16319223d19f229e2358be6e3b7b094e57193312e6","files":{}}
+{"package":"Could not get crate checksum","files":{}}
diff -Nru rust-compiler-builtins-0.1.26/debian/changelog 
rust-compiler-builtins-0.1.26/debian/changelog
--- rust-compiler-builtins-0.1.26/debian/changelog  2020-04-12 
21:42:44.0 +
+++ rust-compiler-builtins-0.1.26/debian/changelog  2021-04-01 
11:34:12.0 +
@@ -1,3 +1,12 @@
+rust-compiler-builtins (0.1.26-3) unstable; urgency=medium
+
+  * Team upload.
+  * Package compiler_builtins 0.1.26 from crates.io using debcargo 2.4.2
+  * Apply upstream changes to replace asm with llvm_asm and hence
+fix FTBFS on arm (Closes: 985810).
+
+ -- Peter Michael Green   Thu, 01 Apr 2021 11:34:12 +
+
 rust-compiler-builtins (0.1.26-2) unstable; urgency=medium
 
   * Team upload.
diff -Nru rust-compiler-builtins-0.1.26/debian/copyright 
rust-compiler-builtins-0.1.26/debian/copyright
--- rust-compiler-builtins-0.1.26/debian/copyright  2020-04-12 
21:42:44.0 +
+++ rust-compiler-builtins-0.1.26/debian/copyright  2021-04-01 
11:34:12.0 +
@@ -57,7 +57,7 @@
 
 Files: debian/*
 Copyright:
- 2019 Debian Rust Maintainers 
+ 2019-2021 Debian Rust Maintainers 

  2019 kpcyrd 
 License: MIT or Apache-2.0
 
diff -Nru rust-compiler-builtins-0.1.26/debian/copyright.debcargo.hint 
rust-compiler-builtins-0.1.26/debian/copyright.debcargo.hint
--- rust-compiler-builtins-0.1.26/debian/copyright.debcargo.hint
2020-04-12 21:42:44.0 +
+++ rust-compiler-builtins-0.1.26/debian/copyright.debcargo.hint
2021-04-01 11:34:12.0 +
@@ -413,8 +413,8 @@
 
 Files: debian/*
 Copyright:
- 2020 Debian Rust Maintainers 
- 2020 kpcyrd 
+ 2020-2021 Debian Rust Maintainers 

+ 2020-2021 kpcyrd 
 License: MIT or Apache-2.0
 
 License: Apache-2.0
diff -Nru rust-compiler-builtins-0.1.26/debian/patches/series 
rust-compiler-builtins-0.1.26/debian/patches/series
--- rust-compiler-builtins-0.1.26/debian/patches/series 1970-01-01 
00:00:00.0 +
+++ rust-compiler-builtins-0.1.26/debian/patches/series 2021-04-01 
11:34:12.0 +
@@ -0,0 +1 @@
+use-llvm_asm.patch
\ No newline at end of file
diff -Nru rust-compiler-builtins-0.1.26/debian/patches/use-llvm_asm.patch 
rust-compiler-builtins-0.1.26/debian/patches/use-llvm_asm.patch
--- rust-compiler-builtins-0.1.26/debian/patches/use-llvm_asm.patch 
1970-01-01 00:00:00.0 +
+++ rust-compiler-builtins-0.1.26/debian/patches/use-llvm_asm.patch 
2021-04-01 11:34:12.0 +
@@ -0,0 +1,305 @@
+Patch to fix asm related FTBFS by switching from asm! to llvm_asm!
+
+This patch is Based on the upstream commit referenced below with
+non-asm related changes removed.
+
+commit cde22bc180391e75de1c189fe29f442ada86ccde
+Author: Alex 

Bug#985363: unblock: cross-toolchain-base/53

[plugwash]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock

Please unblock package cross-toolchain-base

cross-toolchain-base 52 has overzelous conflicts between multilib
libc packages which make the build-dependencies of gcc-10-cross and
gcc-9-cross unsatisfiable.

  package: gcc-10-cross
  version: 15
  architecture: all,arm64,i386,ppc64el,x32,amd64,ppc64
  type: src
  status: broken
  reasons:
   -
conflict:
 pkg1:
  package: libc6-x32-i386-cross
  version: 2.31-9cross3
  architecture: all
  unsat-conflict: libc6-x32-amd64-cross:amd64
 pkg2:
  package: libc6-x32-amd64-cross
  version: 2.31-9cross3
  architecture: all

This is fixed in cross-toolchain-base 53.

unblock cross-toolchain-base/53
diff -Nru cross-toolchain-base-52/debian/changelog 
cross-toolchain-base-53/debian/changelog
--- cross-toolchain-base-52/debian/changelog2021-02-21 08:30:19.0 
+
+++ cross-toolchain-base-53/debian/changelog2021-03-03 11:54:20.0 
+
@@ -1,3 +1,9 @@
+cross-toolchain-base (53) unstable; urgency=medium
+
+  * Don't let the libc*-cross multilib packages conflict with each other.
+
+ -- Matthias Klose   Wed, 03 Mar 2021 12:54:20 +0100
+
 cross-toolchain-base (52) unstable; urgency=medium
 
   * Build using linux 5.10.13.
diff -Nru cross-toolchain-base-52/debian/rules 
cross-toolchain-base-53/debian/rules
--- cross-toolchain-base-52/debian/rules2021-02-21 08:30:19.0 
+
+++ cross-toolchain-base-53/debian/rules2021-03-03 11:54:20.0 
+
@@ -923,6 +923,11 @@
grep -q '^Multi-Arch:' $$tmp/DEBIAN/control \
  || echo 'Multi-Arch: foreign' >> $$tmp/DEBIAN/control; \
esac; \
+   case "$$pkgname" in \
+ libc*-dev*-cross) ;; \
+ libc*-cross) \
+   sed -i -E '/^Conflicts:/s/ libc[^,]*(,|$$)//g;/^Conflicts: *$$/d' 
$$tmp/DEBIAN/control; \
+   esac; \
newdeb=`echo $$deb|sed -e 
"s/\(.*\)_\(.*\)_\(.*\)/\1_\2$(CROSS_EXT)_\3/g"`; \
NO_PKG_MANGLE=1 PKG_IGNORE_CURRENTLY_BUILDING=1 dpkg-deb -b $$tmp/ 
../$$newdeb; \
rm -rf $$tmp

Bug#985234: unblock: rust-smallvec/1.4.2-2

[plugwash]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock

Please unblock package rust-smallvec

The insert_many function in rust-smallvec 1.6.0 and earlier suffers from a
buffer overflow if the number of items returned by the iterator is greater
than the size hint provided by the iterator. This was picked up by the rust
security team as CVE-2021-27378 and in turn by the Debian security team
who filed it with serious severity as Debian bug 985087

I did a fair bit of searching and was unable to find any code that actually
called the problem function, but nevertheless I think this is something
that should be fixed for bullseye. The new upstream version however contained
a number of feature changes that did not seem appropriate at this stage in the
release process.

Therefore I applied the upstream fix as a patch and uploaded to unstable.
The package built successfully on all release architectures and the
autopkgtests passed on all debci architectures.

unblock rust-smallvec/1.4.2-2
diff -Nru rust-smallvec-1.4.2/debian/cargo-checksum.json 
rust-smallvec-1.4.2/debian/cargo-checksum.json
--- rust-smallvec-1.4.2/debian/cargo-checksum.json  2020-10-18 
00:11:43.0 +0100
+++ rust-smallvec-1.4.2/debian/cargo-checksum.json  2021-03-13 
16:28:35.0 +
@@ -1 +1 @@
-{"package":"fbee7696b84bbf3d89a1c2eccff0850e3047ed46bfcd2e92c29a2d074d57e252","files":{}}
+{"package":"Could not get crate checksum","files":{}}
diff -Nru rust-smallvec-1.4.2/debian/changelog 
rust-smallvec-1.4.2/debian/changelog
--- rust-smallvec-1.4.2/debian/changelog2020-10-18 00:11:43.0 
+0100
+++ rust-smallvec-1.4.2/debian/changelog2021-03-13 16:28:35.0 
+
@@ -1,3 +1,12 @@
+rust-smallvec (1.4.2-2) unstable; urgency=medium
+
+  * Team upload.
+  * Package smallvec 1.4.2 from crates.io using debcargo 2.4.3
+  * Apply upstream patch to fix overflow in insert_many
+( Closes: 984665 )
+
+ -- Peter Michael Green   Sat, 13 Mar 2021 16:28:35 +
+
 rust-smallvec (1.4.2-1) unstable; urgency=medium
 
   * Team upload.
diff -Nru rust-smallvec-1.4.2/debian/copyright 
rust-smallvec-1.4.2/debian/copyright
--- rust-smallvec-1.4.2/debian/copyright2020-10-18 00:11:43.0 
+0100
+++ rust-smallvec-1.4.2/debian/copyright2021-03-13 16:28:35.0 
+
@@ -11,7 +11,7 @@
 
 Files: debian/*
 Copyright:
- 2018-2019 Debian Rust Maintainers 

+ 2018-2021 Debian Rust Maintainers 

  2018 kpcyrd 
  2018-2019 Wolfgang Silbermayr 
 License: MIT or Apache-2.0
diff -Nru rust-smallvec-1.4.2/debian/copyright.debcargo.hint 
rust-smallvec-1.4.2/debian/copyright.debcargo.hint
--- rust-smallvec-1.4.2/debian/copyright.debcargo.hint  2020-10-18 
00:11:43.0 +0100
+++ rust-smallvec-1.4.2/debian/copyright.debcargo.hint  2021-03-13 
16:28:35.0 +
@@ -21,9 +21,9 @@
 
 Files: debian/*
 Copyright:
- 2018-2020 Debian Rust Maintainers 

- 2018-2020 kpcyrd 
- 2018-2020 Wolfgang Silbermayr 
+ 2018-2021 Debian Rust Maintainers 

+ 2018-2021 kpcyrd 
+ 2018-2021 Wolfgang Silbermayr 
 License: MIT or Apache-2.0
 
 License: Apache-2.0
diff -Nru 
rust-smallvec-1.4.2/debian/patches/fix-insert-many-buffer-overflow.patch 
rust-smallvec-1.4.2/debian/patches/fix-insert-many-buffer-overflow.patch
--- rust-smallvec-1.4.2/debian/patches/fix-insert-many-buffer-overflow.patch
1970-01-01 01:00:00.0 +0100
+++ rust-smallvec-1.4.2/debian/patches/fix-insert-many-buffer-overflow.patch
2021-03-13 16:28:35.0 +
@@ -0,0 +1,128 @@
+Debian patch for bug 984665
+
+The patches to lib.rs and tests.rs are identical to the upstream
+commit described below. The changes to Cargo.toml (which were
+just a change of the package version number) have been excluded.
+
+commit 9998ba0694a6b51aa6604748b00b6a98f0a0039e
+Author: Matt Brubeck 
+Date:   Thu Jan 7 21:28:46 2021 -0800
+
+Fix potential buffer overflow in `insert_many`
+
+Fixes #252.
+
+diff --git a/src/lib.rs b/src/lib.rs
+index 0241aefa..5e9de828 100644
+--- a/src/lib.rs
 b/src/lib.rs
+@@ -1009,7 +1009,7 @@ impl SmallVec {
+ /// Insert multiple elements at position `index`, shifting all following 
elements toward the
+ /// back.
+ pub fn insert_many>( self, index: 
usize, iterable: I) {
+-let iter = iterable.into_iter();
++let mut iter = iterable.into_iter();
+ if index == self.len() {
+ return self.extend(iter);
+ }
+@@ -1017,13 +1017,16 @@ impl SmallVec {
+ let (lower_size_bound, _) = iter.size_hint();
+ assert!(lower_size_bound <= core::isize::MAX as usize); // Ensure 
offset is indexable
+ assert!(index + lower_size_bound >= index); // Protect against 
overflow
+-self.reserve(lower_size_bound);
++
++let mut num_added = 0;
++let old_len = self.len();
++assert!(index <= old_len);
+ 
+ unsafe {
+-let old_len = self.len();
+-

Bug#984665: [Pkg-rust-maintainers] Bug#984665: CVE-2021-25900

[plugwash-urgent]

I started looking into this bug and trying to gauge it's impact.
In particular what if-any applications in Debian actually use the broken 
code.


First I tried to use codesearch to search for insert_many but I got way 
too many
false-positives. So I tried a different approach. I did however notice 
some embedded

code copies of smallvec during this search, more on that later.

I used zcat 
/srv/ftp.debian.org/mirror/dists/sid/main/binary-amd64/Packages.gz | 
grep-dctrl rust-smallvec -sPackage to identify what applications use 
(directly or indirectly) rust-smallvec, I came up with the following 
list.


bat
cargo-lock
cargo-outdated (build-depends uninstallable, not in testing)
debcargo
git-absorb
grcov
sq-keyring-linter
sqop
sq
sqv
spotify-tui (not in testing)

I installed the build-dependencies for all of these packages except 
cargo-outdated
and did "grep -r insert_many /usr/share/cargo/registry/" the only calls 
were in the

tests and benchmarks of smallvec itself.

I then downloaded and extracted the source packages for the apps 
themselves
into a directory and issued "grep -r insert_many *" in that directory, 
there

were no matches

I tried to repeat the process for buster, unfortunately it seems the 
version

of the tooling used to build many of the rust packages in buster did not
add built-using: or x-cargo-built-using:, It's possible there are also 
some
rust applications in bullseye that have not been touched for a long time 
and
hence suffer from the same isue. Anyway one application was found in 
buster that

had an X-Cargo-Built-Using for rust-smallvec.

ripgrep
I found the following packages that appeard to have embedded copies of
smallvec, it's very possible there were others as I did not do an 
exhaustive

search.
I repeated the build-dependency and source package contents tests 
described
above in buster, using the list of packages from both stable and 
unstable

(where the package existed in stable), again I found now results.

Going back to the original codesearch I noticed the following packages
in the list, that seemed (based mainly on my memory of what uses rust)
like they might be rust-related and investigated them further. I did not
investigate every package in the list for rust dependencies.

firefox
firefox-esr
rust-lexical-core
librsvg
thunderbird

firefox, firefox-esr, librsvg and thunderbird seem to have embedded
copies of rust-smallvec, but don't appear to call insert_many

rust-lexical-core seems to be completely unrelated to arrayvec
(it does not build-depend directly or indirectly on it and it
does not appear to have an embedded copy of it)

This search has not been perfect and I may try and assemble tooling to
do a better one, but my tentative conclusion is that the insert_many
operation in rust-arrayvec does not seem to actually be used.

Bug#979184: rust-lazycell: newly introduced binary packages uninstallable.

[plugwash]

Package: rust-lazycell
Version: 1.3.0-1
Severity: serious

The upload of rust-lazycell 1.3.0-1 introduced three new binary 
packages, two of which are currently
uninstallable. This is preventing the package from migrating to testing 
which is annoying the release

team (see: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=977583 )

I believe that the "nightly-testing" and "clippy" features should simply 
be dropped, both of them
appear to me to be related to linting the package with clippy rather 
than actual runtime features.


If noone objects I will make an upload dropping these features in a week 
or so.

Bug#978219: libfm-qt: FTBFS: gioptrs.h:75:26: error: ‘QString::QString(const char*)’ is private within this context

[plugwash]

tags 978219 +fixed-upstream
thanks

The immediate cause of this bug, is the addition of 
-DQT_NO_CAST_FROM_ASCII to the compiler flags.
Doing some grepping, this appears like it was caused by the update of 
lxqt-buildtools, and appears

to be intentional rather than a leak.

Doing some digging in the upstream source, it looks like this was fixed 
upstream in

https://github.com/lxqt/libfm-qt/commit/1baee3ed83b94aaf2f811e76a9fe789dc1695b3d
I have not checked if the fix can be applied to the version currently in 
Debian though.

Bug#979002: rust-libm: autopkgtest failure on i386: 1.10009765625 is not equal to 2.0

[plugwash]

tags 979002 +patch
thanks

I just whipped up a patch which made cargo test pass on debian i386, 
it's not particularly pretty though.


floor, ceil, round, roundf and rem_pio2f (but not floorf or ceilf) use 
an add/sub trick to round stuff to the nearest integer. Unfortunately 
while this trick works on architectures that use modern FPUs it seems to 
break on x87. Presumably due to excess precision.



For floor and ceil I made the functions use alternative implementations 
based on the proposal at

https://github.com/rust-lang/libm/issues/219

For the other functions I added a conversion to/from bits, this seems to 
force rounding and make the tests pass, though I don't know for sure how 
robust that solution is. The finer points of rust floating point on x87 
do not seem to be documented anywhere.


Finally I loosened the test slightly for j1f

I've pushed my changes at https://github.com/plugwash/libm 
<https://github.com/plugwash/libm> and also posted about them upstream

at https://github.com/rust-lang/libm/issues/243

I may or may not add these changes to the Debian package later.

Bug#978682: xfce4-verve-plugin: build-depends on obsolete package.

[plugwash]

Package: xfce4-verve-plugin
Version: 2.0.0-1
Severity: serious
Tags: bullseye, sid

xfce4-verve-plugin build-depends on libexo-1-dev which is no longer 
built by the exo source package,
it is still present in unstable as a cruft package, but is completely 
gone from testing.

Bug#978681: xfce4-mpc-plugin: build-depends on obsolete package.

[plugwash]

Package: xfce4-mpc-plugin
Version: 0.5.2-1
Severity: serious
Tags: bullseye, sid

xfce4-mpc-plugin build-depends on libexo-1-dev which is no longer built 
by the exo source package,
it is still present in unstable as a cruft package, but is completely 
gone from testing.

Bug#978680: xfce4-indicator-plugin: build-depends on obsolete package.

[plugwash]

Package: xfce4-indicator-plugin
Version: 2.3.4-2
Severity: serious
Tags: bullseye, sid

xfce4-indictor-plugin build-depends on libexo-1-dev which is no longer 
built by the exo source package,
it is still present in unstable as a cruft package, but is completely 
gone from testing.

Bug#978679: bedtools: autpkgtest failures

[plugwash]

Package: bedtools
Version: 2.29.2+dfsg-4
Severity: serious

The autopkgtests for bedtools are failing on all tested architectures 
(though they are "not a regression" on i386 and armhf). When I look at 
the amd64 failure logs, the failures all seem to be missing "../htsutil"



Testing bedtools bamtobed:
test-bamtobed.sh: line 22: ../htsutil: No such file or directory
Testing bedtools bamtofastq:
test-bamtofastq.sh: line 17: ../htsutil: No such file or directory



Testing bedtools bedtobam:
 bedtobam.t1...test-bedtobam.sh: line 23: ../htsutil: No such file or 
directory



Testing bedtools coverage:
test-coverage.sh: line 22: ../htsutil: No such file or directory
Testing bedtools genomecov:
test-genomecov.sh: line 22: ../htsutil: No such file or directory



Testing bedtools intersect:
 intersect.t01...ok
 intersect.t02...ok
 intersect.t03...ok
 intersect.t04...ok
 intersect.t05...ok
 intersect.t06...ok
 intersect.t07...ok
 intersect.t08...ok
 intersect.t09...ok
 intersect.t10...ok
 intersect.t11...ok
 intersect.t12...ok
 intersect.t13...ok
 intersect.t14...ok
 intersect.t15...ok
 intersect.t16...ok
test-intersect.sh: line 200: ../htsutil: No such file or directory
Testing bedtools multicov:
test-multicov.sh: line 17: ../htsutil: No such file or directory

Bug#971018: libgnatcoll-db: FTBFS on mips(64)el with assembler message: branch out of range

[plugwash]

tags 971018 +patch
thanks

I did some testing on the porterbox, which showed optimizing for size is 
enough to make things build on mipsel.


Debdiff attached, no intent to NMU.

diff -Nru libgnatcoll-db-21.0.0/debian/changelog 
libgnatcoll-db-21.0.0/debian/changelog
--- libgnatcoll-db-21.0.0/debian/changelog  2020-12-22 22:35:21.0 
+
+++ libgnatcoll-db-21.0.0/debian/changelog  2020-12-29 13:27:55.0 
+
@@ -1,3 +1,10 @@
+libgnatcoll-db (21.0.0-5.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Use -Os on mipsel, to work around jump length error (Closes: 971018).
+
+ -- Peter Michael Green   Tue, 29 Dec 2020 13:27:55 +
+
 libgnatcoll-db (21.0.0-5) unstable; urgency=medium
 
   [ Adrian Bunk  ]
diff -Nru libgnatcoll-db-21.0.0/debian/rules libgnatcoll-db-21.0.0/debian/rules
--- libgnatcoll-db-21.0.0/debian/rules  2020-11-17 18:33:55.0 +
+++ libgnatcoll-db-21.0.0/debian/rules  2020-12-29 13:27:55.0 +
@@ -34,6 +34,11 @@
   DEB_CFLAGS_MAINT_APPEND := -mxgot
 endif
 
+# Use -Os on mipsel to workaround further jump length issues
+ifneq (,$(filter mipsel,$(DEB_HOST_ARCH)))
+  DEB_CFLAGS_MAINT_APPEND += -Os
+endif
+
 include /usr/share/dpkg/buildflags.mk
 include $(wildcard /usr/share/ada/debian_packaging-$(GNAT_VERSION).mk)
 # wildcard means: not during -indep builds.

Bug#975448: nmu: antimony_0.9.3-2

[plugwash]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: binnmu

The antimony binnmus for the python 3.9 transition failed due to bug
975109 . The maintainer made an upload fixing the bug but unfortunately it was
not source-only and the included amd64 binary was not built against python 3.9
(the other architectures were built on buildds against python 3.9). There are
no Architecture: all or Multi-Arch: same binaries so a binnmu should be
sufficent to get this into a migratable state.

nmu antimony_0.9.3-2 . amd64 . unstable . -m "Python 3.9 as default"

Bug#947904: ledger2beancount autopkgtest failure with new ledger

[plugwash]

package: ledger2beancount
version: 1.8-1
severity: serious

ledger recently migrated to python 3 (forced by boost dropping python 2 
support), this has broken the ledger2beancount autopkgtest and this is 
blocking ledger from migrating to testing.



autopkgtest [19:31:06]: test testsuite:  - - - - - - - - - - stderr - - - - - - 
- - - -
While parsing file 
"/tmp/autopkgtest-lxc.52s9eaxl/downtmp/build.oQM/src/tests/directives.ledger", 
line 209:
Error: 'python' directive seen, but Python support is missing
While parsing file 
"/tmp/autopkgtest-lxc.52s9eaxl/downtmp/build.oQM/src/tests/directives.ledger", 
line 213:
While evaluating value expression:
   print_type(true)
   
Error: Unknown identifier 'print_type'
While parsing file 
"/tmp/autopkgtest-lxc.52s9eaxl/downtmp/build.oQM/src/tests/directives.ledger", 
line 215:
Error: 'python' directive seen, but Python support is missing
make: *** [Makefile:8: test-stamp] Error 1

Bug#939419: libparse-pidl-perl: version ordering issue.

[plugwash]

Package: libparse-pidl-perl
Version: 2:4.9.5+dfsg-5+deb10u1+really0.02
X-debbugs-cc: secur...@debian.org

It seems that the recent update to samba in buster-security generated a 
libparse-pidl-perl package with a lower version number than the version 
already in buster. As far as I can tell this has the following consequences.


1. Users will not get the update to this package, (I don't think this is 
a big problem in this particular case as I don't see anything perl 
related in the changelog).
2. I suspect it will stop the security update getting rolled in to the 
next point release.
3. It may mess up downstream infrastructure (that is how I ran into the 
issue).


I see two possible fixes.

1. Avoid using version numbers for the samba package that will trigger 
this issue.
2. Change the logic that generates the version numbers for the 
libparse-pidl-perl package.


I have knocked up some code to implement the second option and I am 
testing it now. If it works out ok i'll post a patch here.

Bug#936229: bootstrap-vz: Python2 removal in sid/bullseye

[plugwash]

severity 936229 serious
thanks

bootstrap-vz depends on the python-fysom binary package which has 
already been dropped by the python-fysom source package.

Bug#933822: virtualenvwrapper depends on cruft package python-stevedore

[plugwash]

Package: virtualenvwrapper
Severity: serious
Version: 4.3.1-2
Tags: bullseye, sid

virtualenvwapper depends on python-stevedore which is no longer built by 
the stevedore source package.

Bug#933348: mopidy-scrobbler: depends on removed package

[plugwash]

tags 933348 +bullseye,sid
found 933348 1.2.0-1
thanks

This bug also affects testing.

Bug#930467: unblock (pre-approval): mu-editor/1.0.2+dfsg-2.1

[plugwash]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock

Recently I became aware of two issues in mu-editor. A tool for beginning
python programmers.

I was informed that the "debug" button in mu-editors default python mode was
broken in the Debian packaged version of mu. While this does not render
the software totally unusable it is a pretty major deficiency.

The cause of the breakage is that the debug helper program 
/usr/share/mu-editor/mu-debug.py fails to find the python module mu.app
due to not having /usr/share/mu-editor in it's sys.path. The main mu executable
is in /usr/share/mu-editor, so it finds the modules through the default 
sys.path[0], but the debug helper script is in /usr/share/mu-editor/mu so it
does not find them. My fix was to make the debug helper script modify 
sys.path[0] before importing mu.app.

While working on the above issue I discovered that the clean target did not
clean up completely (in violation of policy 4.9) and this was making working on
the package irritating, so I added some extra rm commands to clean up the stray
files.

Is there any chance of getting at least the first and preferablly both of these
fixes into buster?

A debdiff is attatched. 

unblock mu-editor/1.0.2+dfsg-2.1
diff -Nru mu-editor-1.0.2+dfsg/debian/changelog 
mu-editor-1.0.2+dfsg/debian/changelog
--- mu-editor-1.0.2+dfsg/debian/changelog   2019-02-28 02:43:16.0 
+
+++ mu-editor-1.0.2+dfsg/debian/changelog   2019-06-13 02:03:44.0 
+
@@ -1,3 +1,12 @@
+mu-editor (1.0.2+dfsg-2.1) unstable; urgency=medium
+
+  * Non-Maintainer upload.
+  * Adjust sys.path[0] in mu/mu-debug.py so that debugger works
+(Closes: 930457)
+  * Fix clean target.
+
+ -- Peter Michael Green   Thu, 13 Jun 2019 02:03:44 +
+
 mu-editor (1.0.2+dfsg-2) unstable; urgency=medium
 
   * d/gbp.conf: use pristine-tar
diff -Nru mu-editor-1.0.2+dfsg/debian/patches/mu-debug-alter-sys.path.patch 
mu-editor-1.0.2+dfsg/debian/patches/mu-debug-alter-sys.path.patch
--- mu-editor-1.0.2+dfsg/debian/patches/mu-debug-alter-sys.path.patch   
1970-01-01 00:00:00.0 +
+++ mu-editor-1.0.2+dfsg/debian/patches/mu-debug-alter-sys.path.patch   
2019-06-13 02:03:44.0 +
@@ -0,0 +1,24 @@
+Description:  Adjust sys.path[0] in mu/mu-debug.py so that debugger works
+ Debian installs mu-editor's modules in a directory that is not on the
+ global python path. mu-editor finds the modules through sys.path[0]
+ pointing at /usr/share/mu-editor, unfortunately for mu-debug.py 
+ sys.path[0] is /usr/share/mu-editor/mu, so the modules are not found
+ adjust sys.path[0] in mu-editor.py to fix this issue
+Author: Peter Michael Green 
+Last-Update: 2019-06-13
+Bug-Debian: https://bugs.debian.org/930457
+
+--- mu-editor-1.0.2+dfsg.orig/mu/mu-debug.py
 mu-editor-1.0.2+dfsg/mu/mu-debug.py
+@@ -1,6 +1,11 @@
+ #!/usr/bin/env python3
+ import os
+ import sys
++
++#Remove last path element from sys.path[0] so that mu modules can be found 
relative to this executable.
++import os.path
++sys.path[0] = os.path.dirname(sys.path[0])
++
+ from mu.app import debug
+ 
+ 
diff -Nru mu-editor-1.0.2+dfsg/debian/patches/series 
mu-editor-1.0.2+dfsg/debian/patches/series
--- mu-editor-1.0.2+dfsg/debian/patches/series  2019-02-28 02:43:16.0 
+
+++ mu-editor-1.0.2+dfsg/debian/patches/series  2019-06-13 02:03:44.0 
+
@@ -8,3 +8,4 @@
 remove-non-dfsg-images-from-docs
 remove-non-dfsg-resources
 test_app_icon_as_string
+mu-debug-alter-sys.path.patch
diff -Nru mu-editor-1.0.2+dfsg/debian/rules mu-editor-1.0.2+dfsg/debian/rules
--- mu-editor-1.0.2+dfsg/debian/rules   2019-02-28 02:43:16.0 +
+++ mu-editor-1.0.2+dfsg/debian/rules   2019-06-13 02:03:44.0 +
@@ -27,6 +27,9 @@
 override_dh_auto_clean:
dh_auto_clean
rm -rf docs/html
+   rm -f debian/mu-editor.1
+   rm -f debian/mu-editor.1.md
+   rm -rf .pytest_cache
 
 override_dh_auto_build:
dh_auto_build

Bug#929450: caml-crush, build-dependencies unsatisfiable on armel

[plugwash]

package: caml-crush
tags: buster,sid
severity: serious
x-debbugs-cc: debian-ocaml-ma...@lists.debian.org

caml-crush build-depends on ocaml-native-compilers. In stretch this was 
a real package. In buster it is a virtual package provided by ocaml-base 
on most architectures, but does not seem to exist at all on armel. In 
the ocaml changelog I see "drop support for ocamlopt on armel as 
suggested by upstream" which I suspect reflects this change.


If this package can be reasonablly made to work without 
ocaml-native-compilers on armel then you should do so, if you belive it 
is not reasonable to support this package on armel please 
reassign/retitle this to ftpmaster so they can remove the armel binaries.

Bug#905035: libkf5kdcraw: FTBFS against libraw 0.19.0

[plugwash]

tags 905035 +patch
thanks

After some searching around and following links from the gentoo 
bugtracker I found a patch for this. I applied it to the package and was 
able to get a succesful build in raspbian buster.


A debdiff can be found at 
http://debdiffs.raspbian.org/main/libk/libkf5kdcraw/libkf5kdcraw_17.08.3-1+rpi1.debdiff


No intent to NMU in Debian.

Bug#892386: ITP: python3-pgzero -- pygame zero, environment for zero-boilerplate programming of 2D games.

[plugwash]

Package: wnpp
Severity: wishlist
Owner: plugwash <plugw...@p10link.net>

* Package name: python3-pgzero
  Version : 1.2.post1
  Upstream Author : Daniel Pope <ma...@mauveweb.co.uk>
* URL : https://bitbucket.org/lordmauve/pgzero
* License : LGPLv3
  Programming Lang: python3
  Description : pygame zero, environment for zero-boilerplate programming 
of 2D games.

Pygame zero provides an environment in which 2D games can be developed in
python without the need for boilerplate code or complex APIs.

It is intended for use in education, so that teachers can teach basic
programming without needing to explain the Pygame API or write an event loop.

Bug#863354: ITP: autoforwardportergit -- Tool for automatically merging local changes with new distro packages.

[plugwash]

Package: wnpp
Severity: wishlist
Owner: plugwash <plugw...@p10link.net>

* Package name: autoforwardportergit
  Version : 0.1
  Upstream Author : Peter Michael Green <plugw...@debian.org>
* URL : http://github.com/plugwash/autoforwardportergit/
* License : (MIT)
  Programming Lang: (Python3 and bash)
  Description : Tool for automatically merging local changes with new 
distro packages.

Often there is a need to maintain downstream changes to a package with a new 
version from the upstream
distro. Doing this manually is not difficult but it gets to be a PITA for more 
than a handful of
packages.

autoforwardportergit and the related tool dscdirtogit (which I intend to 
package as part of the same
source) are built to automate this process.

reprepro is used to create a local repo with both upstream and downstream 
versions of the packages.

dscdirtogit takes existing dscs (both upstream and downstream) and uses dgit to 
import them into a
git repo for each package. It uses the changelogs to determine the shape of the 
history. 

The actual autoforwardporter looks at package lists to determine when a merge 
is needed. The initial
merge is performed with git and then a series of "fixers" fixup the changelog 
and other common
conflicts. If the conflicts are fixed successfully dgit will be used to build a 
source package and
then sbuild will be used to build the package. 

If the conflicts are not fixed successfully the code complete with conflict 
markers will be committed
to a "working" branch so that a human can pick up where the automation left off.

The code currently works fine but before packaging I will need to move 
raspbian-specific assumptions
into a configuration file and move to a fhs-compliant file layout. I hope to 
work on this while at
Debconf.