Bug#991292: dist-upgrade interruption leaves hold on freedombox package

[James Valleroy]

Package: freedombox
Version: 21.4.3
Severity: important
X-Debbugs-Cc: jvalle...@mailbox.org

Using freedombox from buster-backports (21.4.2~bpo10+1) on Lime2
hardware, I started a test of the dist-upgrade feature, using the
"--test" flag to perform dist-upgrade to bullseye:

# /usr/share/plinth/actions/upgrades start-dist-upgrade --test

After several hours, I found the process had been interrupted. By
running the same command again, it was able to complete the upgrades.

The freedombox dist-upgrade feature normally sets an apt-mark hold on
the freedombox package, to prevent the system from becoming
unreachable. The hold is set and removed within a try/finally
block.

However, at the end of my test, the hold was left on the freedombox
package.  Most like this is because the upgrade process was killed, so
the finally block will not be run, leaving the hold in place.

The impact is that if FreedomBox users rely on the automatic
dist-upgrade feature, there is a chance that after it completes, they
will need to manually remove the hold on the freedombox package.

Bug#991294: libgc FTCBFS for nios2: symbol differences

[Helmut Grohne]

Source: libgc
Version: 1:8.0.4-3
Tags: patch
User: helm...@debian.org
Usertags: rebootstrap
User: debian-cr...@lists.debian.org
Usertags: ftcbfs

libgc fails to cross build from source for nios2 due to symbol
differences. A closer look reveals that nios2 is one of the few
architectures where the cross build does not enable the use of atomic
builtins, but a native build does. Once enabled, we get a very different
and larger pile of symbol differences that look much more reasonable.
Looks like the previous symbol update wasn't correct. Please consider
applying the attached patch to fix that.

Helmut
diff --minimal -Nru libgc-8.0.4/debian/changelog libgc-8.0.4/debian/changelog
--- libgc-8.0.4/debian/changelog2020-12-06 12:44:00.0 +0100
+++ libgc-8.0.4/debian/changelog2021-07-20 06:30:56.0 +0200
@@ -1,3 +1,10 @@
+libgc (1:8.0.4-3.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Also use atomic builtins on nios2 and adapt symbol file. (Closes: #-1)
+
+ -- Helmut Grohne   Tue, 20 Jul 2021 06:30:56 +0200
+
 libgc (1:8.0.4-3) unstable; urgency=medium
 
   * Fix cross/native difference: explicitly disable usage of
diff --minimal -Nru libgc-8.0.4/debian/libgc1.symbols 
libgc-8.0.4/debian/libgc1.symbols
--- libgc-8.0.4/debian/libgc1.symbols   2020-10-27 14:07:51.0 +0100
+++ libgc-8.0.4/debian/libgc1.symbols   2021-07-20 06:30:54.0 +0200
@@ -4,8 +4,8 @@
  (arch=kfreebsd-amd64 kfreebsd-i386)GC_FreeBSDGetDataStart@Base 1:7.2d
  (arch=sparc sparc64)GC_SysVGetDataStart@Base 1:7.2d
  GC_abort_on_oom@Base 1:8.0
- (arch=!nios2 !sh4)GC_acquire_mark_lock@Base 1:8.0
- (arch=!nios2 !sh4)GC_active_count@Base 1:8.0
+ (arch=!sh4)GC_acquire_mark_lock@Base 1:8.0
+ (arch=!sh4)GC_active_count@Base 1:8.0
  GC_add_ext_descriptor@Base 1:7.2d
  GC_add_map_entry@Base 1:7.2d
  GC_add_roots@Base 1:7.2d
@@ -53,7 +53,7 @@
  GC_build_fl@Base 1:7.2d
  GC_build_fl_clear2@Base 1:7.2d
  GC_build_fl_clear4@Base 1:7.2d
- (arch=!nios2 !sh4)GC_bytes_allocd_tmp@Base 1:8.0
+ (arch=!sh4)GC_bytes_allocd_tmp@Base 1:8.0
  GC_bytes_found@Base 1:7.2d
  GC_call_with_alloc_lock@Base 1:7.2d
  GC_call_with_gc_active@Base 1:7.2d
@@ -146,8 +146,8 @@
  GC_do_blocking@Base 1:7.2d
  GC_do_blocking_inner@Base 1:7.2d
  GC_do_enumerate_reachable_objects@Base 1:7.6.4
- (arch=!nios2 !sh4)GC_do_local_mark@Base 1:8.0
- (arch=!nios2 !sh4)GC_do_parallel_mark@Base 1:8.0
+ (arch=!sh4)GC_do_local_mark@Base 1:8.0
+ (arch=!sh4)GC_do_parallel_mark@Base 1:8.0
  GC_dont_expand@Base 1:7.2d
  GC_dont_gc@Base 1:7.2d
  GC_dont_precollect@Base 1:7.2d
@@ -194,8 +194,8 @@
  (arch=!arm64 !nios2 !mips !mips64el !mipsel !riscv64 !s390 
!s390x)GC_find_limit_with_bound@Base 1:7.2d
  GC_findleak_delay_free@Base 1:7.2d
  GC_finish_collection@Base 1:7.2d
- (arch=!nios2 !sh4)GC_first_nonempty@Base 1:8.0
- (arch=!nios2 !sh4)GC_fl_builder_count@Base 1:8.0
+ (arch=!sh4)GC_first_nonempty@Base 1:8.0
+ (arch=!sh4)GC_fl_builder_count@Base 1:8.0
  GC_fnlz_roots@Base 1:7.6.4
  GC_fo_entries@Base 1:7.2d
  GC_force_unmap_on_gcollect@Base 1:7.2d
@@ -295,9 +295,9 @@
  GC_hblkfreelist@Base 1:7.2d
  GC_header_cache_miss@Base 1:7.2d
  GC_heapsize_at_forced_unmap@Base 1:7.6.4
- (arch=!nios2 !sh4)GC_help_marker@Base 1:8.0
- (arch=!nios2 !sh4)GC_help_wanted@Base 1:8.0
- (arch=!nios2 !sh4)GC_helper_count@Base 1:8.0
+ (arch=!sh4)GC_help_marker@Base 1:8.0
+ (arch=!sh4)GC_help_wanted@Base 1:8.0
+ (arch=!sh4)GC_helper_count@Base 1:8.0
  GC_ignore_self_finalize_mark_proc@Base 1:7.2d
  GC_ignore_warn_proc@Base 1:7.2d
  GC_in_thread_creation@Base 1:7.2d
@@ -372,16 +372,16 @@
  GC_mark_and_push_stack@Base 1:7.2d
  GC_mark_from@Base 1:7.2d
  GC_mark_init@Base 1:7.2d
- (arch=!nios2 !sh4)GC_mark_local@Base 1:8.0
- (arch=!nios2 !sh4)GC_mark_no@Base 1:8.0
+ (arch=!sh4)GC_mark_local@Base 1:8.0
+ (arch=!sh4)GC_mark_no@Base 1:8.0
  GC_mark_some@Base 1:7.2d
  GC_mark_stack_size@Base 1:7.2d
  GC_mark_stack_too_small@Base 1:7.2d
  GC_mark_state@Base 1:7.2d
- (arch=!nios2 !sh4)GC_mark_thread@Base 1:8.0
+ (arch=!sh4)GC_mark_thread@Base 1:8.0
  GC_mark_thread_local_fls_for@Base 1:8.0
  GC_mark_thread_local_free_lists@Base 1:8.0
- (arch=!nios2 !sh4)GC_mark_threads@Base 1:8.0
+ (arch=!sh4)GC_mark_threads@Base 1:8.0
  GC_mark_togglerefs@Base 1:7.6.4
  GC_max_heapsize@Base 1:7.4.2
  GC_max_retries@Base 1:7.2d
@@ -420,8 +420,8 @@
  GC_noop6@Base 1:7.4.2
  GC_noop_sink@Base 1:7.2d
  GC_normal_finalize_mark_proc@Base 1:7.2d
- (arch=!nios2 !sh4)GC_notify_all_builder@Base 1:8.0
- (arch=!nios2 !sh4)GC_notify_all_marker@Base 1:8.0
+ (arch=!sh4)GC_notify_all_builder@Base 1:8.0
+ (arch=!sh4)GC_notify_all_marker@Base 1:8.0
  GC_notify_or_invoke_finalizers@Base 1:7.2d
  GC_nprocs@Base 1:7.2d
  GC_null_finalize_mark_proc@Base 1:7.2d
@@ -493,9 +493,9 @@
  GC_push_current_stack@Base 1:7.2d
  GC_push_finalizer_structures@Base 1:7.2d
  GC_push_gc_structures@Base 1:7.2d
- (arch=nios2 sh4)GC_push_marked1@Base 1:7.4.2
- (arch=!alpha !amd64 !arm64 !armel !armhf !hppa !hurd-i386 !i386 !ia64 
!kfreebsd-amd

Bug#991293: pillow: CVE-2021-34552 - buffer overflow in Convert.c

[Neil Williams]

On Tue, 20 Jul 2021 06:36:44 +0100 Neil Williams  wrote:
> This has been fixed upstream in version 8.3. The upstream fix can be
> backported to 8.1 in unstable.
> 
> This is a tracking bug to ease migration of pillow into bullseye. 
> 
> I have an upload ready for unstable.

Attaching the debdiff for this fix ahead of upload to unstable.


-- 
Neil Williams
=
https://linux.codehelp.co.uk/
diffstat for pillow-8.1.2+dfsg pillow-8.1.2+dfsg

 changelog|8 
 patches/CVE-2021-34552.patch |   40 
 patches/series   |1 +
 3 files changed, 49 insertions(+)

diff -Nru pillow-8.1.2+dfsg/debian/changelog pillow-8.1.2+dfsg/debian/changelog
--- pillow-8.1.2+dfsg/debian/changelog	2021-06-13 17:11:04.0 +0100
+++ pillow-8.1.2+dfsg/debian/changelog	2021-07-20 06:42:31.0 +0100
@@ -1,3 +1,11 @@
+pillow (8.1.2+dfsg-0.3) unstable; urgency=high
+
+  * Non-maintainer upload by the Security Team.
+  * Fix "CVE-2021-34552 - buffer overflow in Convert.c. Replace sprintf with
+snprintf. Backport upstream change from 8.3 to 8.1. (Closes: #991293)
+
+ -- Neil Williams   Tue, 20 Jul 2021 06:42:31 +0100
+
 pillow (8.1.2+dfsg-0.2) unstable; urgency=medium
 
   * Non-maintainer upload.
diff -Nru pillow-8.1.2+dfsg/debian/patches/CVE-2021-34552.patch pillow-8.1.2+dfsg/debian/patches/CVE-2021-34552.patch
--- pillow-8.1.2+dfsg/debian/patches/CVE-2021-34552.patch	1970-01-01 01:00:00.0 +0100
+++ pillow-8.1.2+dfsg/debian/patches/CVE-2021-34552.patch	2021-07-19 09:51:59.0 +0100
@@ -0,0 +1,40 @@
+From 5f4504bb03f4edeeef8c2633dc5ba03a4c2a8a97 Mon Sep 17 00:00:00 2001
+From: Andrew Murray 
+Date: Tue, 15 Jun 2021 15:14:26 +1000
+Subject: [PATCH 1/2] Limit sprintf modes to 10 characters
+
+From 518ee3722a99d7f7d890db82a20bd81c1c0327fb Mon Sep 17 00:00:00 2001
+From: Andrew Murray 
+Date: Wed, 30 Jun 2021 23:47:10 +1000
+Subject: [PATCH 2/2] Use snprintf instead of sprintf
+
+* https://github.com/python-pillow/Pillow/pull/5567/files
+* Replace sprintf with snprintf in src/libImaging/Convert.c
+
+---
+--- a/src/libImaging/Convert.c
 b/src/libImaging/Convert.c
+@@ -1664,9 +1664,8 @@
+ #ifdef notdef
+ return (Imaging) ImagingError_ValueError("conversion not supported");
+ #else
+-static char buf[256];
+-/* FIXME: may overflow if mode is too large */
+-sprintf(buf, "conversion from %s to %s not supported", imIn->mode, mode);
++static char buf[100];
++snprintf(buf, 100, "conversion from %.10s to %.10s not supported", imIn->mode, mode);
+ return (Imaging) ImagingError_ValueError(buf);
+ #endif
+ }
+@@ -1724,9 +1723,8 @@
+ }
+ #else
+ {
+-  static char buf[256];
+-  /* FIXME: may overflow if mode is too large */
+-  sprintf(buf, "conversion from %s to %s not supported in convert_transparent", imIn->mode, mode);
++  static char buf[100];
++  snprintf(buf, 100, "conversion from %.10s to %.10s not supported in convert_transparent", imIn->mode, mode);
+   return (Imaging) ImagingError_ValueError(buf);
+ }
+ #endif
diff -Nru pillow-8.1.2+dfsg/debian/patches/series pillow-8.1.2+dfsg/debian/patches/series
--- pillow-8.1.2+dfsg/debian/patches/series	2021-06-13 17:10:51.0 +0100
+++ pillow-8.1.2+dfsg/debian/patches/series	2021-07-19 09:45:27.0 +0100
@@ -7,3 +7,4 @@
 CVE-2021-28676.patch
 CVE-2021-28677.patch
 CVE-2021-28678.patch
+CVE-2021-34552.patch


pgpHIPp3pXh2x.pgp
Description: OpenPGP digital signature

Bug#991293: pillow: CVE-2021-34552 - buffer overflow in Convert.c

[Neil Williams]

Source: pillow
Version: 8.1.2+dfsg-0.2
Severity: grave
Tags: security
Justification: user security hole

https://security-tracker.debian.org/tracker/CVE-2021-34552

Pillow through 8.2.0 and PIL (aka Python Imaging Library) through 1.1.7 allow 
an attacker to
pass controlled parameters directly into a convert function to trigger a buffer 
overflow in Convert.c.

This has been fixed upstream in version 8.3. The upstream fix can be
backported to 8.1 in unstable.

This is a tracking bug to ease migration of pillow into bullseye. 

I have an upload ready for unstable.

--

Neil Williams

Bug#991291: developers-reference: replace atter

[Jeremy Bicha]

Source: developers-reference
Version: 11.0.20

"Any atter suffix". I am guessing you meant to use the word "other",
since "atter" is archaic or dialectal English according to my
dictionary.

https://salsa.debian.org/debian/developers-reference/-/commit/33fc4a914
https://www.debian.org/doc/manuals/developers-reference/best-pkging-practices.html#bpp-origtargz
https://en.wiktionary.org/wiki/atter

Thanks,
Jeremy Bicha

Bug#991290: RFS: apt-listchanges/3.25 [ITA] -- package change history notification tool

[Thompson, Brian]

Package: sponsorship-requests
Severity: normal

Dear mentors,

I am looking for a sponsor for my package "apt-listchanges":

 * Package name: apt-listchanges
   Version : 3.25
 * License : GPL-2+
 * Vcs : https://salsa.debian.org/debian/apt-listchanges/
   Section : utils

It builds those binary packages:

  apt-listchanges - package change history notification tool

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


  https://mentors.debian.net/package/apt-listchanges/

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


  dget -x 
https://mentors.debian.net/debian/pool/main/a/apt-listchanges/apt-listchanges_3.25.dsc


Changes since the last upload:

 apt-listchanges (3.25) experimental; urgency=medium
 .
   [ Debian Janitor ]
   * Remove constraints unnecessary since stretch.
 .
   [ Brian Thompson ]
   * Change maintainer to myself (closes: #981890).
   * Fix uninitialized variable.
   * Add debconf as build-dep.
   * Automated po update.

Regards,

BT

Bug#990956: uploading lintian-brush to testing-proposed-updates

[Jelmer Vernooij]

On Wed, Jul 14, 2021 at 10:25:29PM +0200, Paul Gevers wrote:
> Hi,
> 
> On 12-07-2021 01:20, Jelmer Vernooij wrote:
> > On Sun, Jul 11, 2021 at 09:58:30PM +0200, Paul Gevers wrote:
> >> On 11-07-2021 21:47, Jelmer Vernooij wrote:
> >>> It's going to be tricky to get this resolved in time before the removal of
> >>> lintian-brush from testing.
> >>
> >> Can you elaborate why it's tricky (not promising anything, but there
> >> could be reasons for t-p-u)? The current autoremoval is scheduled for
> >> August 8, which is *after* the tentative release date.
> > 
> > There have been updates to the other packages that relate to
> > lintian-brush - both dependencies (python-tr, debmutate,
> > upstream-ontologist, buildlog-consultant) and reverse dependencies
> > ((silver-platter); we'd have to either roll those back in unstable as
> > well or instead patch lintian-brush with a set of changes to lintian-brush 
> > that isn't really a
> > roll back.
> 
> Still not promising anything, but what would be the proposed change in
> t-p-u?
Please find attached the proposed change. Please note that it only
affects the testsuite.

Cheers,

Jelmer
commit d9d08efed57eca3f434954495dd5c84bbfa4cb12
Author: Jelmer Vernooij 
Date:   Mon Jul 19 23:26:25 2021 +0100

Fix test suite compatibility with the version of upstream-ontologist in bullseye.

diff --git a/debian/changelog b/debian/changelog
index 5431fedc..a4ef35b0 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,12 @@
+lintian-brush (0.99.1) bullseye; urgency=high
+
+  * Fix test suite compatibility with the version of upstream-ontologist in
+bullseye.
+   + Bump minimum upstream-ontologist to 0.1.22 since the test suite now
+ relies on the output from that version.
+
+ -- Jelmer Vernooij   Mon, 19 Jul 2021 23:25:07 +0100
+
 lintian-brush (0.99) unstable; urgency=medium
 
   * Also update 'set -e' in postrm files. Closes: #983347
diff --git a/debian/control b/debian/control
index 7644abac..0cc6006c 100644
--- a/debian/control
+++ b/debian/control
@@ -21,7 +21,8 @@ Build-Depends: bash-completion,
python3-setuptools,
python3-ruamel.yaml,
python3-toml,
-   python3-upstream-ontologist,
+   python3-tomlkit,
+   python3-upstream-ontologist (>= 0.1.22),
po-debconf,
gpg (>= 2.1),
lintian (>= 2.104.0),
@@ -42,7 +43,7 @@ Depends: devscripts,
  python3-distro-info,
  python3-iniparse,
  python3-ruamel.yaml,
- python3-upstream-ontologist,
+ python3-upstream-ontologist (>= 0.1.22),
  ognibuild,
  ${misc:Depends},
  ${python3:Depends}
diff --git a/debian/tests/control b/debian/tests/control
index 40a21b0e..9da5a58f 100644
--- a/debian/tests/control
+++ b/debian/tests/control
@@ -1,5 +1,5 @@
 Tests: tool-testsuite
-Depends: lintian-brush, python3-breezy.tests, gpg, dos2unix, libdebhelper-perl, lintian (>= 2.104.0), python3-iniparse, python3-toml, python3-levenshtein, decopy, po-debconf
+Depends: lintian-brush, python3-breezy.tests, gpg, dos2unix, libdebhelper-perl, lintian (>= 2.104.0), python3-iniparse, python3-toml, python3-levenshtein, decopy, po-debconf, python3-tomlkit
 Restrictions: allow-stderr
 
 Test-Command: deb-scrub-obsolete --version
diff --git a/tests/upstream-metadata-file/doap/message b/tests/upstream-metadata-file/doap/message
index 00d4f683..d0e9f9c9 100644
--- a/tests/upstream-metadata-file/doap/message
+++ b/tests/upstream-metadata-file/doap/message
@@ -1,3 +1,3 @@
-Set upstream metadata fields: Bug-Database, Name, Repository, Repository-Browse.
+Set upstream metadata fields: Bug-Database, Contact, Name, Repository, Repository-Browse.
 Certainty: certain
 Fixed-Lintian-Tags: upstream-metadata-file-is-missing, upstream-metadata-missing-repository
diff --git a/tests/upstream-metadata-file/doap/out/debian/upstream/metadata b/tests/upstream-metadata-file/doap/out/debian/upstream/metadata
index 7706a368..f6164da9 100644
--- a/tests/upstream-metadata-file/doap/out/debian/upstream/metadata
+++ b/tests/upstream-metadata-file/doap/out/debian/upstream/metadata
@@ -1,5 +1,6 @@
 ---
 Name: blah
+Contact: Joe Maintainer
 Bug-Database: http://example.com/blah/trac/newticket
 Repository: http://example.com/blah/svn/trunk/
 Repository-Browse: http://example.com/blah/trac/browser/
diff --git a/tests/upstream-metadata-file/fix-repository/message b/tests/upstream-metadata-file/fix-repository/message
index bda7d077..f266830a 100644
--- a/tests/upstream-metadata-file/fix-repository/message
+++ b/tests/upstream-metadata-file/fix-repository/message
@@ -1,2 +1,2 @@
-Set upstream metadata fields: Repository.
-Certainty: certain
+Set upstream metadata fields: Name, Repository.
+Certainty: possible
diff --git a/tests/upstream-metadata-file/fix-repository/out/debian/upstream/metadata b/tests/upstream-metadata-file/fix-repository/out/debian/upstream/metadata
index 8acd9d07..fcce007d 1

Bug#991110: python3.9: Please exclude test_concurrent_futures also on alpha

[Adrian Bunk]

Control: retitle 991110 python3.9: Please exclude test_concurrent_futures also 
on armhf and alpha
Control: severity 991110 serious
Control: retitle 99 python3.10: Please exclude test_concurrent_futures also 
on armhf and alpha
Control: severity 99 serious

The same failure happened now on the buildds for both python3.9 and 
python3.10 when building for armhf:

https://buildd.debian.org/status/fetch.php?pkg=python3.9&arch=armhf&ver=3.9.6-1&stamp=1626524274&raw=0
https://buildd.debian.org/status/logs.php?pkg=python3.10&arch=armhf

One suspect why this broke is:

12:55 < aurel32> bunk: arm-ubc-0{4,5,6} are now using QEMU from backports and 
the host is also 
 running the kernel from backports. This was need to fix the 
regular VM crashes 
 from 32-bit VMs
16:01 < aurel32> bunk: that was done on 2021-05-11 according to my IRC logs of 
the #debian-admin 
 channel

cu
Adrian

On Wed, Jul 14, 2021 at 06:49:24PM +0300, Adrian Bunk wrote:
> Source: python3.9
> Severity: important
> Tags: patch ftbfs
> Control: clone -1 -2
> Control: reassign -2 python3.10
> Control: retitle -2 python3.10: Please exclude test_concurrent_futures also 
> on alpha
> 
> test_concurrent_futures frequently hangs during the build on alpha:
> 
> https://buildd.debian.org/status/package.php?p=python3.9&suite=experimental
> https://buildd.debian.org/status/logs.php?pkg=python3.9&arch=alpha
> 
> ...
> 23:57:55 load avg: 0.00 running: test_concurrent_futures (23 hour 51 min)
> ...
> 
> 
> Workaround:
> 
> --- python3.9-3.9.6/debian/rules.old  2021-07-14 14:46:00.200490919 +
> +++ python3.9-3.9.6/debian/rules  2021-07-14 14:46:18.848548468 +
> @@ -542,7 +542,7 @@
>TEST_EXCLUDES += test_gdb
>  endif
>  
> -ifneq (,$(filter $(DEB_HOST_ARCH), riscv64))
> +ifneq (,$(filter $(DEB_HOST_ARCH), alpha riscv64))
>TEST_EXCLUDES += test_concurrent_futures
>  endif
>  

Bug#950174: gvfs-udisks2-volume-monitor.service crashes: No GSettings schemas are installed on the system

[Sebastian Ramacher]

Control: severity -1 normal

On 2021-01-28 09:46:53 +, Simon McVittie wrote:
> Control: retitle -1 gvfs-udisks2-volume-monitor.service crashes: No GSettings 
> schemas are installed on the system
> Control: tags -1 + moreinfo unreproducible
> 
> On Wed, 29 Jan 2020 at 23:22:01 +0100, Pipes wrote:
> > gianluca@debian64:~/bin$ systemctl --user start
> > gvfs-udisks2-volume-monitor.service
> > Job for gvfs-udisks2-volume-monitor.service failed because a fatal signal 
> > was
> > delivered to the control process.
> > See "systemctl --user status gvfs-udisks2-volume-monitor.service" and
> > "journalctl --user -xe" for details.
> > 
> > gianluca@debian64:~/bin$ systemctl --user status
> > gvfs-udisks2-volume-monitor.service
> > ● gvfs-udisks2-volume-monitor.service - Virtual filesystem service - disk
> > device monitor
> >      Loaded: loaded 
> > (/usr/lib/systemd/user/gvfs-udisks2-volume-monitor.service;
> > static; vendor preset: enabled)
> >      Active: failed (Result: signal) since Wed 2020-01-29 23:20:08 CET; 11s 
> > ago
> >     Process: 43074 ExecStart=/usr/lib/gvfs/gvfs-udisks2-volume-monitor 
> > (code=
> > killed, signal=TRAP)
> >    Main PID: 43074 (code=killed, signal=TRAP)
> > 
> > Jan 29 23:20:08 debian64 systemd[4850]: Starting Virtual filesystem service 
> > -
> > disk device monitor...
> > Jan 29 23:20:08 debian64 gvfs-udisks2-vo[43074]: No GSettings schemas are
> > installed on the system
> 
> Does this still occur?
> 
> On Wed, 29 Jan 2020 at 23:34:51 +0100, Michael Biebl wrote:
> > It appears gvfs-daemons (more specifically gvfsudisks2volumemonitor) is
> > requiring the schema files from gsettings-desktop-schemas
> 
> Yes, it does; but it has an indirect hard dependency on those schemas,
> so they should really be installed already.
> 
> gvfs-daemons
> -> Depends: gvfs-libs
>  -> Depends: gsettings-desktop-schemas
> 
> I tried installing gvfs-daemons with only its required dependencies
> (without Recommends) on a test system, and was unable to reproduce this
> bug. gvfs-udisks2-volume-monitor.service starts successfully.
> 
> Does /usr/share/glib-2.0/schemas/gschemas.compiled exist?
> 
> If it does, please copy it to
> /usr/share/glib-2.0/schemas/gschemas.compiled.old for later analysis,
> then try reinstalling the gsettings-desktop-schemas package with:
> 
> apt install --reinstall gsettings-desktop-schemas
> 
> and send the output to this bug address.

Given the above and that there has been no reply on the questions, let's
downgrade the severity.

Cheers

> 
> Thanks,
> smcv

-- 
Sebastian Ramacher


signature.asc
Description: PGP signature

Bug#990990: unblock: libcgroup/2.0

[Adrian Bunk]

On Mon, Jul 19, 2021 at 03:07:49PM +0200, Santiago Ruano Rincón wrote:
> On Thu, 15 Jul 2021 12:27:35 +0200 Paul Gevers  wrote:
> > Hi,
> > 
> > On 12-07-2021 18:45, Michael Biebl wrote:
> > > This was already discussed in
> > > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=959022
> > > 
> > > My takeaway from that discussion was, that rdeps of cgroup-tools, would
> > > itself have to be made cgroupv2 aware, especially OpenStack and its
> > > components.
> > 
> > That resembles my understanding of that discussion too.
> 
> Mine too.
> 
> zigo, are there any news from openstack about this?
> 
> > 
> > > Have those rdeps been tested successfully with libcgroup/cgroup-tools
> > > from experimental?
> > 
> > I'm not in favor of doing this transition now.
> > 
> 
> Please, keep in mind this comment, made before the release of 2.0:
> "we are planning something for next week. The version number will
> probably be 2.0 - with expectation that the v2 cycle will have
> continously breaking ABI. When we are happy where it is, we will push
> out v3 which will then maintain ABI through its lifetime."
> https://github.com/libcgroup/libcgroup/issues/12#issuecomment-825816328

What kind of ABI is this referring to?

Based on soname and package name, the libcgroup1 in experimental
claims to be ABI compatible with the library in buster.
Changes in bookworm would be a normal library transition.

OpenStack uses cgroup-tools, which is the only reason why libcgroup 
stayed in bullseye at all.
My suggestion was basically asking whether 2.0 would be better for
using with the version of OpenStack in bullseye, this is similar to
your question to Thomas above.

If cgroup-tools in *bookworm* would be incompatible with OpenStack in
bullseye, this could be resolved with Breaks on the bullseye versions
of cinder-common/nova-compute - this is irrelevant for discussing which
version of libcgroup to ship in bullseye.

> Cheers,
> 
>  -- Santiago

cu
Adrian

Bug#991289: /etc/ImageMagick-6/policy.xml: invalid XML due to broken comment

[Kevin Locke]

Package: imagemagick-6-common
Version: 8:6.9.11.60+dfsg-1.3
Severity: normal
File: /etc/ImageMagick-6/policy.xml

Dear Maintainer,

Line 77 of /etc/ImageMagick-6/policy.xml (for name="shared-secret")
has a comment start marker ()
causing the start marker on the next line to occur within a comment,
which is not valid XML[^1]:

> For compatibility, the string "--" (double-hyphen) MUST NOT occur within 
> comments.

As demonstrated by `xmllint /etc/ImageMagick-6/policy.xml`:

/etc/ImageMagick-6/policy.xml:77: parser error : Double hyphen within 
comment: 
^

It does not cause any issues with the ImageMagick tools that I am
aware of, but it complicates use/checking by other tools which parse
the XML more strictly (e.g. XMLStarlet).

The issue is caused by 0007-Improve-policy-in-order-to-be-safer.patch
(d9e5818685) which removed the end marker on line 77.

Thanks,
Kevin

[^1]: https://www.w3.org/TR/REC-xml/#sec-comments


-- Package-specific info:
ImageMagick program version
---
animate:  ImageMagick 6.9.11-60 Q16 x86_64 2021-01-25 https://imagemagick.org
compare:  ImageMagick 6.9.11-60 Q16 x86_64 2021-01-25 https://imagemagick.org
convert:  ImageMagick 6.9.11-60 Q16 x86_64 2021-01-25 https://imagemagick.org
composite:  ImageMagick 6.9.11-60 Q16 x86_64 2021-01-25 https://imagemagick.org
conjure:  ImageMagick 6.9.11-60 Q16 x86_64 2021-01-25 https://imagemagick.org
display:  ImageMagick 6.9.11-60 Q16 x86_64 2021-01-25 https://imagemagick.org
identify:  ImageMagick 6.9.11-60 Q16 x86_64 2021-01-25 https://imagemagick.org
import:  ImageMagick 6.9.11-60 Q16 x86_64 2021-01-25 https://imagemagick.org
mogrify:  ImageMagick 6.9.11-60 Q16 x86_64 2021-01-25 https://imagemagick.org
montage:  ImageMagick 6.9.11-60 Q16 x86_64 2021-01-25 https://imagemagick.org
stream:  ImageMagick 6.9.11-60 Q16 x86_64 2021-01-25 https://imagemagick.org

-- System Information:
Debian Release: 11.0
  APT prefers testing-debug
  APT policy: (990, 'testing-debug'), (990, 'testing'), (500, 
'unstable-debug'), (500, 'testing-security'), (500, 'stable-debug'), (500, 
'unstable'), (500, 'oldstable'), (101, 'experimental'), (1, 
'experimental-debug')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.14.0-rc1 (SMP w/4 CPU threads)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

-- no debconf information

Bug#991288: imagemagick: update Repository in debian/upstream/metadata

[Kevin Locke]

Source: imagemagick
Version: 8:6.9.11.60+dfsg-1.3
Severity: minor
Tags: patch

Dear Maintainer,

The [Repository in debian/upstream/metadata] responds with 404 Not
Found.  The [Install from Source] page on the ImageMagick website
states:

> The authoritative source code repository is https://github.com/ImageMagick.

It would be nice to update debian/upstream/metadata with the current
repository URL (https://github.com/ImageMagick/ImageMagick6 for IM6,
https://github.com/ImageMagick/ImageMagick for IM7).  I've attached a
patch which does so with the IM6 repository for the current package
version.

Thanks,
Kevin
>From 966afb82d32e892161ec605d3504164c617a9e27 Mon Sep 17 00:00:00 2001
Message-Id: 
<966afb82d32e892161ec605d3504164c617a9e27.1626728544.git.ke...@kevinlocke.name>
From: Kevin Locke 
Date: Mon, 19 Jul 2021 14:52:41 -0600
Subject: [PATCH] upstream/metadata: update Repository

The [Repository in debian/upstream/metadata] responds with 404 Not
Found.  The [Install from Source] page on the ImageMagick website
states:

> The authoritative source code repository is https://github.com/ImageMagick.

Update Repository in debian/upstream/metadata to point to the git
repository for [ImageMagick 6 on GitHub].

Add Repository-Browse with the browseable URL as well.

[ImageMagick 6 on GitHub]: https://github.com/ImageMagick/ImageMagick6
[Install from Source]: https://imagemagick.org/script/install-source.php
[Repository in debian/upstream/metadata]: 
https://subversion.imagemagick.org/subversion/ImageMagick/trunk

Signed-off-by: Kevin Locke 
---
 debian/upstream/metadata | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/debian/upstream/metadata b/debian/upstream/metadata
index 71f831bf3f..e40ebdf713 100644
--- a/debian/upstream/metadata
+++ b/debian/upstream/metadata
@@ -5,5 +5,6 @@ Bug-Submit: 
http://www.imagemagick.org/discourse-server/viewforum.php?f=3
 Contact: http://www.imagemagick.org/discourse-server/
 FAQ: http://www.imagemagick.org/Usage/
 Homepage: http://www.imagemagick.org/
-Repository: https://subversion.imagemagick.org/subversion/ImageMagick/trunk
+Repository: https://github.com/ImageMagick/ImageMagick6.git
+Repository-Browse: https://github.com/ImageMagick/ImageMagick6
 Security-Contact: Post private message to on the Bug-Submit forum. Add a 
public remainder on the bug forum asking to check private message.
\ No newline at end of file
-- 
2.30.2

Bug#991282: RFS: runit/2.1.2-41exp1 -- system-wide service supervision

[Lorenzo Puliti]

Package: sponsorship-requests
Severity: normal
X-Debbugs-Cc: plore...@disroot.org

Dear mentors,

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

 * Package name: runit
   Version : 2.1.2-41exp1
   Upstream Author : Gerrit Pape 
 * URL : http://smarden.org/runit/
 * License : GPL-3+, BSD-3-clause
 * Vcs : https://salsa.debian.org/debian/runit
   Section : admin

It builds those binary packages:

  runit-init - system-wide service supervision (as init system)
  getty-run - runscripts to supervise getty processes
  runit-systemd - transitional package for runit-systemd users
  runit-run - service supervision (systemd and sysv integration)
  runit - system-wide service supervision

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

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

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

  dget -x 
https://mentors.debian.net/debian/pool/main/r/runit/runit_2.1.2-41exp1.dsc

Git repo:

  https://salsa.debian.org/Lorenzo.ru.g-guest/runit/-/tree/2.1.2-41exp

Changes since the last upload:

 runit (2.1.2-41exp1) experimental; urgency=medium
 .
   * Set rules-requires-root to no
   * Runit-run: drop dependency on runit-systemd | sysvinit-core
   * Runit: get rid of ancient transition code in prerm
   * Add upstream metadata
   * Add support for policy-rc.d hack in invoke-run
   * Update invoke-run manpage for policy-rc.d
   * Update News files
   * Shutdown.c:
 - fix wrong command line parsing logic that always
   caused a No-Op when any option was given, breaking,
   among other things, the init switch from Sysvinit
   (Closes: #991227)
 - reboot the system with -r flag (Closes: #990774)
   * Update shutdown(8) manpage
   * Update license and copyright years

Regards,
-- 
  Lorenzo Puliti

Bug#911431: Bug#988329: ITA: usbredir/0.9.0-1 -- Simple USB host TCP server

[Lin Qigang]

retitle 911431 "ITA: usbredir/0.10.0 -- Simple USB host TCP server"
tags 988329 - moreinfo
thanks

Hi Tobi and everyone else,

> Please update the package, remove the moreinfo tag and ping me for an
> follow up, and I will take a look again.

Thanks again for your feedback. I think I fixed all the issues you previously 
told me about, and am ready for follow up. Here is the package 
https://mentors.debian.net/package/usbredir/. 


> Debian is currently frozen

I have targeted experimental instead

> Regarding the adoption, you should reply to the orphaning bug (#911431),
> indicating there that you want to adopt the package by retitling ^this^ bug to
> start with "ITA:" (stands for Intent to Adopt) and set yourself as maintainer.

> the #911431 with the changelog (the developers reference should have a 
> paragraph

I added #911431 and #988329 to the changelog. I hope retitling this bug solves 
the "package closes bug in a wrong way" lintian error. Otherwise could you 
please help me fix this?

> Otherwise, the mentors package page lists a few lintian messages, which should
> be fixed as well, like those:

> - upstream has released 0.10.0 in the meantime.
> - compat level is at the ancient level "9". Please consider updating it…
> - Standards Version is also quite old. Please consider updating that as well. 
> (see the upgrade checklist
  appendix of the Debian Policy)

I have fixed all of these lintian messages except for the one that I mentioned. 
I have updated from 0.8 to 0.10.0, fixed the compat level, updated the 
standards version, and fixed the remaining items.

Thanks again!

Lin Qigang 
GPG Fingerprint:  8CAD 1250 8EE0 3A41 7223  03EC 7096 F91E D75D 028F

signature.asc
Description: OpenPGP digital signature

Bug#991275: tar doesn't restore all directory timestamps from the extracted archive

[Vincent Lefevre]

On 2021-07-19 20:16:57 +0100, Janos LENART wrote:
> I am going to forward this report upstream, but I find it extremely
> unlikely they'd change this behavior as that would lead to
> surprising results for others depending on the current default.

Why would user want the current default?

This rule is very obscure and unintuitive, and I don't see any
advantage.

The linux-source archive surely does not expect this rule.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Bug#991122: unblock: varnish/6.5.2-1

[Graham Inggs]

Control: tags -1 + confirmed

Hi Stig

On Mon, 19 Jul 2021 at 13:00, Stig Sandbeck Mathisen  wrote:
> Attached is the diff. Changes are the upstream bugfix, as well as two commits
> in the packaging repository:

Thanks.  Please go ahead and upload to unstable, then remove the
moreinfo tag once it has built.

Regards
Graham

Bug#991287: unblock: containerd/1.4.5~ds1-2

[Shengjing Zhu]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
X-Debbugs-Cc: z...@debian.org

Please unblock package containerd

[ Reason ]
Backport patch for CVE-2021-32760:
https://github.com/containerd/containerd/security/advisories/GHSA-c72p-9xmj-rx3w

[ Impact ]
If it's blocked, the package has security issue.

[ Tests ]
Upstream has added a regression test to the patch.

[ Risks ]
Only one line change(in archive/tar_unix.go file), and a new test (in 
archive/tar_unix.go file).

[ Checklist ]
  [x] all changes are documented in the d/changelog
  [x] I reviewed all changes and I approve them
  [x] attach debdiff against the package in testing

[ Other info ]

unblock containerd/1.4.5~ds1-2


diff -Nru containerd-1.4.5~ds1/debian/changelog 
containerd-1.4.5~ds1/debian/changelog
--- containerd-1.4.5~ds1/debian/changelog   2021-05-12 13:17:38.0 
+0800
+++ containerd-1.4.5~ds1/debian/changelog   2021-07-20 02:36:10.0 
+0800
@@ -1,3 +1,9 @@
+containerd (1.4.5~ds1-2) unstable; urgency=medium
+
+  * Backport patches for CVE-2021-32760
+
+ -- Shengjing Zhu   Tue, 20 Jul 2021 02:36:10 +0800
+
 containerd (1.4.5~ds1-1) unstable; urgency=medium
 
   * New upstream patch version v1.4.5
diff -Nru containerd-1.4.5~ds1/debian/gbp.conf 
containerd-1.4.5~ds1/debian/gbp.conf
--- containerd-1.4.5~ds1/debian/gbp.conf2021-05-12 13:17:38.0 
+0800
+++ containerd-1.4.5~ds1/debian/gbp.conf2021-07-20 02:36:10.0 
+0800
@@ -1,4 +1,5 @@
 [DEFAULT]
 pristine-tar = True
 debian-branch = debian/sid
+upstream-branch = upstream/sid
 dist = DEP14
diff -Nru containerd-1.4.5~ds1/debian/patches/0008-CVE-2021-32760.patch 
containerd-1.4.5~ds1/debian/patches/0008-CVE-2021-32760.patch
--- containerd-1.4.5~ds1/debian/patches/0008-CVE-2021-32760.patch   
1970-01-01 08:00:00.0 +0800
+++ containerd-1.4.5~ds1/debian/patches/0008-CVE-2021-32760.patch   
2021-07-20 02:36:10.0 +0800
@@ -0,0 +1,91 @@
+From 03aa748c11663e87a72fab92b7ab7c88c28bf13e Mon Sep 17 00:00:00 2001
+From: Derek McGowan 
+Date: Tue, 6 Jul 2021 12:37:54 -0700
+Subject: [PATCH 1/2] Use chmod path for checking symlink
+
+Signed-off-by: Derek McGowan 
+(cherry picked from commit 27597ccfd30d8aa06b448062896bccfb33ad8f22)
+Signed-off-by: Derek McGowan 
+---
+ archive/tar_unix.go | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/archive/tar_unix.go b/archive/tar_unix.go
+index 6e89d2fdbc9..c22e79bf2be 100644
+--- a/archive/tar_unix.go
 b/archive/tar_unix.go
+@@ -113,7 +113,7 @@ func handleTarTypeBlockCharFifo(hdr *tar.Header, path 
string) error {
+ 
+ func handleLChmod(hdr *tar.Header, path string, hdrInfo os.FileInfo) error {
+   if hdr.Typeflag == tar.TypeLink {
+-  if fi, err := os.Lstat(hdr.Linkname); err == nil && 
(fi.Mode()&os.ModeSymlink == 0) {
++  if fi, err := os.Lstat(path); err == nil && 
(fi.Mode()&os.ModeSymlink == 0) {
+   if err := os.Chmod(path, hdrInfo.Mode()); err != nil && 
!os.IsNotExist(err) {
+   return err
+   }
+
+From 664f93ead6c613a9f0e9932dfa75c602dbe35f41 Mon Sep 17 00:00:00 2001
+From: Derek McGowan 
+Date: Tue, 6 Jul 2021 16:23:03 -0700
+Subject: [PATCH 2/2] Add test for archive breakout test for lchmod
+
+Signed-off-by: Derek McGowan 
+(cherry picked from commit ad81d76219a75559cb9d74a214efe0d779d7cbef)
+Signed-off-by: Derek McGowan 
+---
+ archive/tar_test.go | 35 +++
+ 1 file changed, 35 insertions(+)
+
+diff --git a/archive/tar_test.go b/archive/tar_test.go
+index 568f5a95f1c..8ffd3f221b8 100644
+--- a/archive/tar_test.go
 b/archive/tar_test.go
+@@ -243,6 +243,11 @@ func TestBreakouts(t *testing.T) {
+   return nil
+   }
+   errFileDiff := errors.New("files differ")
++  td, err := ioutil.TempDir("", "test-breakouts-")
++  if err != nil {
++  t.Fatal(err)
++  }
++  defer os.RemoveAll(td)
+ 
+   isSymlinkFile := func(f string) func(string) error {
+   return func(root string) error {
+@@ -744,6 +749,36 @@ func TestBreakouts(t *testing.T) {
+   // resolution ends up just removing etc
+   validator: fileNotExists("etc/passwd"),
+   },
++  {
++
++  name: "HardlinkSymlinkChmod",
++  w: func() tartest.WriterToTar {
++  p := filepath.Join(td, "perm400")
++  if err := ioutil.WriteFile(p, []byte("..."), 
0400); err != nil {
++  t.Fatal(err)
++  }
++  ep := filepath.Join(td, 
"also-exists-outside-root")
++  if err := ioutil.WriteFile(ep, []byte("..."), 
0640); err != nil {
++  t.Fatal(err)
++

Bug#991019: linux-image-5.10.0-7-armmp: a20 olinuxino-MICRO panic accessing sata disk after the boot.

[Ben Hutchings]

Control: tag -1 moreinfo

On Tue, 2021-07-13 at 04:28 +0200, Flavio Barbara wrote:
> Package: src:linux
> Version: 5.10.40-1
> Severity: normal
> X-Debbugs-Cc: none, f...@maidaccordo.net
> 
> Dear Maintainer,
> 
> after upgrading to bullseye my SBC olimex a20 olinuxino-MICRO, the
> system boots (so it seems it does not have any problem to boot from
> /dev/sda1) and soon after go in kernel panic.
> 
> My system has a SATA disc splitted  in 3 partitions:
> /dev/sda1 /ext4
> /dev/sda2 swap
> /dev/sda3 /homeext4
> 
> uboot is running in a empty microSD card. 
> 
> This is the last line of the sceen output:
> end Kernel panic - not syncing; stack-protector: Kernel stack is
> corrupted in generic_file_buffered_read+0xc2c/0xc30

We would need to see the full output to start investigating this.  If
you're using a monitor then please send a photo as an attachment.

Ben.


-- 
Ben Hutchings
Absolutum obsoletum. (If it works, it's out of date.) - Stafford Beer


signature.asc
Description: This is a digitally signed message part

Bug#991275: tar doesn't restore all directory timestamps from the extracted archive

[Janos LENART]

severity 991275 wishlist
tags 991275 + wontfix
thanks

Hi Vincent,

I am going to forward this report upstream, but I find it extremely
unlikely they'd change this behavior as that would lead to
surprising results for others depending on the current default.

Regards,

On Mon, 19 Jul 2021 at 16:12, Vincent Lefevre  wrote:

> I can see that the --delay-directory-restore option solves the issue.
> But IMHO, this option should be the default to avoid surprising
> results (the linux package doesn't ensure that the items are
> "correctly" ordered, if I understand its debian/rules.real file).
>
> --
> Vincent Lefèvre  - Web: 
> 100% accessible validated (X)HTML - Blog: 
> Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)
>


-- 
LÉNÁRT, János

Bug#991286: unblock: netdiscover/0.7-4

[Joao Eriberto Mota Filho]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
X-Debbugs-Cc: eribe...@debian.org

Dear Release Team,

Please unblock package netdiscover.

[ Reason ]

The revision 0.7-4 has a patch (030) to add an important fix from the
upstream[1]. This fix allows netdiscover to use correctly CIDR /24 if
netdiscover is being built with libpcap >= 1.10.

This fix closes #991258

[1] 
https://github.com/netdiscover-scanner/netdiscover/commit/2de0187c8b6aad3ca5393d96fbc5b00c453c3d23

Short explanation: Older versions of libpcap ignored to_ms on Linux. The
current version captures packets until a buffer a filled or the specified
timeout elapses. The value 0 disables that timeout, so libpcap will only start
delivering packets once the buffer is filled.

[ Impact ]

If the unblock isn't granted, the user will not able to scan a network using
the option '-r /24', so only /8 and /16 will work.

[ Tests ]

Several tests were made after the fix and it worked fine.

[ Risks ]

This is a trivial fix and it has no risks for the whole source code.

[ Checklist ]
  [x] all changes are documented in the d/changelog
  [x] I reviewed all changes and I approve them
  [x] attach debdiff against the package in testing

unblock netdiscover/0.7-4
diff -Nru netdiscover-0.7/debian/changelog netdiscover-0.7/debian/changelog
--- netdiscover-0.7/debian/changelog2021-02-06 00:05:00.0 -0300
+++ netdiscover-0.7/debian/changelog2021-07-18 17:23:16.0 -0300
@@ -1,3 +1,10 @@
+netdiscover (0.7-4) unstable; urgency=medium
+
+  * debian/patches/030_fix_cidr24.patch: created to fix no results with CIDR 
/24
+and libpcap >= 1.10. Thanks to Enrico Schmitz. (Closes: #991258)
+
+ -- Joao Eriberto Mota Filho   Sun, 18 Jul 2021 17:23:16 
-0300
+
 netdiscover (0.7-3) unstable; urgency=medium
 
   * debian/patches/20_update-oui.patch: updated.
diff -Nru netdiscover-0.7/debian/patches/030_fix_cidr24.patch 
netdiscover-0.7/debian/patches/030_fix_cidr24.patch
--- netdiscover-0.7/debian/patches/030_fix_cidr24.patch 1969-12-31 
21:00:00.0 -0300
+++ netdiscover-0.7/debian/patches/030_fix_cidr24.patch 2021-07-18 
17:23:16.0 -0300
@@ -0,0 +1,21 @@
+Description: Fix no results with CIDR /24 and libpcap >= 1.10
+Author: Enrico Schmitz
+Origin: 
https://github.com/netdiscover-scanner/netdiscover/commit/2de0187c8b6aad3ca5393d96fbc5b00c453c3d23
+Bug: https://github.com/netdiscover-scanner/netdiscover/issues/9
+Bug-Debian: https://bugs.debian.org/991258
+Forwarded: not-needed
+Reviewed-By: Joao Eriberto Mota Filho 
+Last-Update: 2021-07-18
+Index: netdiscover/src/ifaces.h
+===
+--- netdiscover.orig/src/ifaces.h
 netdiscover/src/ifaces.h
+@@ -45,7 +45,7 @@ extern "C"
+   typedef uint16_t u_int16_t;
+   typedef uint8_t  u_int8_t;
+#else
+-  #define PCAP_TOUT 0
++  #define PCAP_TOUT 512
+#endif
+ 
+ 
diff -Nru netdiscover-0.7/debian/patches/series 
netdiscover-0.7/debian/patches/series
--- netdiscover-0.7/debian/patches/series   2021-02-06 00:04:57.0 
-0300
+++ netdiscover-0.7/debian/patches/series   2021-07-18 17:23:16.0 
-0300
@@ -1,2 +1,3 @@
 10_fix-makefile.patch
 20_update-oui.patch
+030_fix_cidr24.patch

Bug#901973: ITP: node-destroy -- Node.js stream destruction utility, with quirk handling

[Shayan Doust]

Hello,

I will be packaging send-transform soon and this is a dependency.

Any progress with this? If not, I'll package node-destroy.

Kind regards,
Shayan Doust

On Wed, 20 Jun 2018 16:33:13 -0400 Zebulon McCorkle  wrote:
> Package: wnpp
> Severity: wishlist
> Owner: Zebulon McCorkle 
> 
> * Package name: node-destroy
>   Version : 1.0.4
>   Upstream Author : Jonathan Ong 
> * URL : https://github.com/stream-utils/destroy
> * License : MIT
>   Programming Lang: Node.js
>   Description : Node.js stream destruction utility, with quirk handling
> 
> Maintained in pkg-javascript-devel
> 
> 

-- 
Shayan Doust - 201427418
Fingerprint: 0401 A810 A6F2 4303 1EA3 9759 6D7D 4419 19D0 2395

Note: all emails sent by me are signed with my PGP key.


signature.asc
Description: PGP signature

Bug#991285: unblock: strip-nondeterminism/1.12-0.1

[Holger Levsen]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
x-debbugs-cc: reproducible-bui...@lists.alioth.debian.org

Hi,

I'm wondering whether it makes sense to unblock strip-nondeterminism 1.12.0-1,
which has been uploaded on 2021-05-07 and which since then (or rather shortly 
after)
has been used on the buildds when building packages. There haven't been any bugs
filed since the upload and the changes are pretty small:

strip-nondeterminism (1.12.0-1) unstable; urgency=medium

  [ Chris Lamb ]
  * Support normalising Python "pyzip" files -- ie. zip-compressed .py files
with a regular Python shebang. (Closes: 
reproducible-builds/strip-nondeterminism#18)
  * Drop single-debian-patch, etc.

  [ Bernhard M. Wiedemann ]
  * Move exception handling closer to call using perl's "//" operator.

The debdiffstat is:

 debdiff strip-nondeterminism_1.11.0-1.dsc 
strip-nondeterminism_1.12.0-1.dsc|diffstat
 debian/changelog   |   12 ++
 debian/source/options  |1 
 debian/source/patch-header |   17 
 lib/File/StripNondeterminism.pm|   11 ++
 lib/File/StripNondeterminism/handlers/pyzip.pm |  106 +
 5 files changed, 128 insertions(+), 19 deletions(-)

and the full debdiff is attached.

Rather obviously this more or less against the freeze guidelines but given the
fact that it's been used in many bullseye builds during the freeze I thought
I'd ask.
And I decided to ask via a bug report. Feel free to close or unblock :)

(And before you ask: I don't really know why I didn't file this unblock request
earlier. I guess it's because the change is not soo relevant but then I somehow
continued to be bothered by the fact that bullseye is build with packages from
out of bullseye and so I finally decided to ask anyway.)

unblock strip-nondeterminism/1.12-0.1

and thank you for releasing bullseye and dealing with requests like these! ;)


-- 
cheers,
Holger

 ⢀⣴⠾⠻⢶⣦⠀
 ⣾⠁⢠⠒⠀⣿⡁  holger@(debian|reproducible-builds|layer-acht).org
 ⢿⡄⠘⠷⠚⠋⠀  OpenPGP: B8BF54137B09D35CF026FE9D 091AB856069AAA1C
 ⠈⠳⣄

"A developed country is not a place where the poor have cars. It's where the
rich use public transportation." (quote attributed to several people)
diff -Nru strip-nondeterminism-1.11.0/debian/changelog strip-nondeterminism-1.12.0/debian/changelog
--- strip-nondeterminism-1.11.0/debian/changelog	2021-02-05 13:04:06.0 +0100
+++ strip-nondeterminism-1.12.0/debian/changelog	2021-05-07 13:36:57.0 +0200
@@ -1,3 +1,15 @@
+strip-nondeterminism (1.12.0-1) unstable; urgency=medium
+
+  [ Chris Lamb ]
+  * Support normalising Python "pyzip" files -- ie. zip-compressed .py files
+with a regular Python shebang. (Closes: reproducible-builds/strip-nondeterminism#18)
+  * Drop single-debian-patch, etc.
+
+  [ Bernhard M. Wiedemann ]
+  * Move exception handling closer to call using perl's "//" operator.
+
+ -- Chris Lamb   Fri, 07 May 2021 12:36:57 +0100
+
 strip-nondeterminism (1.11.0-1) unstable; urgency=medium
 
   [ Helmut Grohne ]
diff -Nru strip-nondeterminism-1.11.0/debian/source/options strip-nondeterminism-1.12.0/debian/source/options
--- strip-nondeterminism-1.11.0/debian/source/options	2021-02-05 13:04:06.0 +0100
+++ strip-nondeterminism-1.12.0/debian/source/options	1970-01-01 01:00:00.0 +0100
@@ -1 +0,0 @@
-single-debian-patch
diff -Nru strip-nondeterminism-1.11.0/debian/source/patch-header strip-nondeterminism-1.12.0/debian/source/patch-header
--- strip-nondeterminism-1.11.0/debian/source/patch-header	2021-02-05 13:04:06.0 +0100
+++ strip-nondeterminism-1.12.0/debian/source/patch-header	1970-01-01 01:00:00.0 +0100
@@ -1,17 +0,0 @@
-Subject: Collected Debian patches for strip-nondeterminism
-Author: Andrew Ayer 
-
-Since I am also upstream for this package, there will normally not be
-any patches to apply to the upstream source.  However, occasionally
-I'll pull up specific upstream commits prior to making an upstream
-release.  When this happens, this patch will collect all of those
-modifications.
-
-I use Git to maintain both the upstream source and the Debian
-packages, and generating individual patches rather than using git
-cherry-pick takes extra work for no gain.  Since I'm also upstream,
-there's no need to separate the patches for later upstream submission.
-Hence, I take this approach with a unified patch when it's necessary.
-
-For full commit history and separated commits, see the upstream Git
-repository.
diff -Nru strip-nondeterminism-1.11.0/lib/File/StripNondeterminism/handlers/pyzip.pm strip-nondeterminism-1.12.0/lib/File/StripNondeterminism/handlers/pyzip.pm
--- strip-nondeterminism-1.11.0/lib/File/StripNondeterminism/handlers/pyzip.pm	1970-01-01 01:00:00.0 +0100
+++ strip-nondeterminism-1.12.0/lib/File/StripNondeterminism/handlers/pyzip.pm	2021-05-07 13:35:16.0 +0200
@@ -0,0 +1,106 @@

Bug#991276: Boot existing Host Operating System or VM into Live Mode (grub-live)

[Patrick Schleizer]

Package: live-boot
Severity: wishlist
X-Debbugs-CC: whonix-de...@whonix.org

This is a feature request to adopt / re-implement grub-live.

It provides functionality to "Boot existing Host Operating System or VM
into Live Mode".

1. install Debian normally.
2. install grub-live
3. choose in grub boot menu the existing, already installed Debian into
either persistent or live mode

The grub-live package:

https://gitlab.com/whonix/grub-live

Essentially just only 1 grub configuration drop-in file:

https://gitlab.com/whonix/grub-live/-/blob/master/etc/grub.d/11_linux_live

Screenshots here:

https://www.whonix.org/wiki/Grub-live

Potential future enhancements:

- More generic package name that includes implementations for boot
loaders other than grub.

- dracut support

Bug#991284: RM: deltachat-core -- ROM; Replaced by a rust rewrite and no longer maintained

[Micah Anderson]

Package: ftp.debian.org
Severity: normal

Hi,

The upstream authors of deltachat-core have decided to re-implement the library
in Rust, and this package is no longer relevant. Upstream is not continuing to
maintain it, and it would just otherwise collect dust in the archive, so I'm
requesting removal.

I am the package maintainer.

Thanks!

micah

Bug#989630: mke2fs with size limit and default discard will discard data after size limit

[Josh Triplett]

On Sun, Jul 18, 2021 at 01:15:05PM -0400, Theodore Y. Ts'o wrote:
> tags 989630 +pending
> thanks
> 
> I finally had time to investigate this problem.  It turns out the only
> time this bug manifests is when creating an file system smaller than
> (blocksize)**2 bytes (e.g., 16 megabytes when the is block size is
> 4k).
> 
> The bug was introduced almost ten years ago (September 2011), and
> apparently no one noticed until you did!
> 
> Thanks for providing a repro, BTW; I had initially tried reproducing
> this with a file system size larger than 16MB, and I couldn't see the
> problem.  But when I used your precise reproduction instructions, I
> finally figured out what was going on.

Thanks for the fix! I'm glad the precise reproducer helped.

Bug#991283: unblock: mesa/20.3.5-1

[Simon McVittie]

Package: release.debian.org
Severity: normal
Tags: moreinfo
User: release.debian@packages.debian.org
Usertags: unblock
X-Debbugs-Cc: m...@packages.debian.org, Timo Aaltonen 

Should the mesa source package be unblocked for bullseye? It was uploaded
to unstable several months ago.

Please note that I am not a Mesa maintainer, and I don't know whether
the uploader (cc'd) intended this to be for bullseye or not. I've tagged
this bug as moreinfo until Mesa maintainers confirm whether they want
this in bullseye.

If we're too late for 11.0, another option would be to convert this into
a mesa/20.3.5-0+deb11u1 upload targeting point release 11.1.

[ Reason ]
New upstream stable release with various bug fixes. The one I'm
particularly interested in is https://bugs.debian.org/983390 which causes
crashes and hangs when using third-party Vulkan layers like MangoHUD, but
there are lots of bugfixes listed in the upstream release notes.

[ Impact ]
Users of bullseye who run games etc. will experience various crashes,
hangs and rendering artifacts that could have been avoided.

[ Tests ]
I don't know, I'm not the maintainer. Presumably a lot of users of
unstable have been using this version to run games and other
graphically-intensive programs in the 116 days since it was uploaded.

There don't seem to be any RC bugs open. The Mesa maintainers would know
better than I do whether there have been non-RC regression reports.

[ Risks ]
It's a key package, involved in providing hardware support.

If the changes that upstream made in their development branch and then
backported into their stable branch are not all correct, then this version
could introduce new crashes, hangs and artifacts of a scope similar to the
ones it's fixing.

[ Checklist ]
  [ ] all changes are documented in the d/changelog
  - debian/patches/llvm-12-build-fix.diff is not explicitly documented
  [ ] I reviewed all changes and I approve them
  [x] attach debdiff against the package in testing

The attached debdiff is lightly filtered to remove changes that appear to
be irrelevant (a copy of debian/patches/llvm-12-build-fix.diff in an
unintended location, and the JSON file that upstream use to track which
commits should/shouldn't be cherry-picked from their development branch).

Thanks,
smcv


mesa_20.3.5-1-filtered.diff.gz
Description: application/gzip

Bug#991274: Package libldap-2.4-2 was built without LDAP_CONNECTIONLESS

[Quanah Gibson-Mount]

--On Monday, July 19, 2021 9:59 AM -0700 Ryan Tandy  wrote:


Why does the new version of sssd require this? Can it not remain optional
on their side, if it was in the past?

See https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=539421 for the
previous request about LDAP_CONNECTIONLESS. As far as I know the upstream
status hasn't changed...


I've noted as much in the github issue.

--Quanah

--

Quanah Gibson-Mount
Product Architect
Symas Corporation
Packaged, certified, and supported LDAP solutions powered by OpenLDAP:

Bug#991281: virtualbox-ext-pack: missing Depends: ca-certificates

[Andreas Beckmann]

Package: virtualbox-ext-pack
Version: 6.1.22-1
Severity: serious
User: debian...@lists.debian.org
Usertags: piuparts

Hi,

during a test with piuparts I noticed your package failed to install. As
per definition of the release team this makes the package too buggy for
a release, thus the severity.

>From the attached log (scroll to the bottom...):

  Setting up virtualbox-ext-pack (6.1.22-1) ...
  virtualbox-ext-pack: downloading: 
https://download.virtualbox.org/virtualbox/6.1.22/Oracle_VM_VirtualBox_Extension_Pack-6.1.22.vbox-extpack
  The file will be downloaded into /usr/share/virtualbox-ext-pack
  Hash mismatch Oracle_VM_VirtualBox_Extension_Pack-6.1.22.vbox-extpack: 
expected 6d33d9cc1c5a8f8a2a70e5778a341322d2ba7eb34f7de420fb5f312b9e87, 
removing the file.
  dpkg: error processing package virtualbox-ext-pack (--configure):
   installed virtualbox-ext-pack package post-installation script subprocess 
returned error exit status 1
  Processing triggers for libc-bin (2.31-13) ...
  Errors were encountered while processing:
   virtualbox-ext-pack

The underlying but hidden error seems to come from wget:

(piuparts:/srv/piuparts/tmp/tmp0g9ymk)root@piuparts-testenv:/# wget 
https://download.virtualbox.org/virtualbox/6.1.22/Oracle_VM_VirtualBox_Extension_Pack-6.1.22.vbox-extpack
--2021-07-19 16:11:26--  
https://download.virtualbox.org/virtualbox/6.1.22/Oracle_VM_VirtualBox_Extension_Pack-6.1.22.vbox-extpack
Connecting to 10.99.17.1:3128... connected.
ERROR: The certificate of 'download.virtualbox.org' is not trusted.
ERROR: The certificate of 'download.virtualbox.org' doesn't have a known issuer.


cheers,

Andreas

Bug#991280: firmware-microbit-micropython-dl: fails to install: checksum of downloaded file does not match

[Andreas Beckmann]

Package: firmware-microbit-micropython-dl
Version: 1.2.4+dfsg-7
Severity: serious
User: debian...@lists.debian.org
Usertags: piuparts

Hi,

during a test with piuparts I noticed your package failed to install. As
per definition of the release team this makes the package too buggy for
a release, thus the severity.

>From the attached log (scroll to the bottom...):

  Setting up firmware-microbit-micropython-dl (1.2.4+dfsg-7) ...
  Either your micro:bit MicroPython runtime is missing, or it is out-of-date.
  Downloading micro:bit MicroPython runtime from 
https://raw.githubusercontent.com/ntoll/uflash/master/firmware.hex...
  --2021-07-15 14:11:04--  
https://raw.githubusercontent.com/ntoll/uflash/master/firmware.hex
  Connecting to 10.99.1.1:3128... connected.
  Proxy request sent, awaiting response... 200 OK
  Length: 1832972 (1.7M) [text/plain]
  Saving to: '/tmp/tmp.6rBUe36m2h'
  
  
/tmp/tmp.6rBUe36m2h   0%[]   0  --.-KB/s   
/tmp/tmp.6rBUe36m2h 100%[===>]   1.75M  --.-KB/sin 0.07s   
  
  2021-07-15 14:11:04 (26.6 MB/s) - '/tmp/tmp.6rBUe36m2h' saved 
[1832972/1832972]
  
  /tmp/tmp.6rBUe36m2h: FAILED
  md5sum: WARNING: 1 computed checksum did NOT match
  
  Warning: Failed to download micro:bit MicroPython runtime.
  Please run "dpkg-reconfigure firmware-microbit-micropython-dl"
  again when networking is up, or download the file manually:
  
  URL:  https://raw.githubusercontent.com/ntoll/uflash/master/firmware.hex
  File: /usr/share/firmware-microbit-micropython/firmware.hex
  
  dpkg: error processing package firmware-microbit-micropython-dl (--configure):
   installed firmware-microbit-micropython-dl package post-installation script 
subprocess returned error exit status 1
  Processing triggers for libc-bin (2.31-13) ...
  Processing triggers for ca-certificates (20210119) ...
  Updating certificates in /etc/ssl/certs...
  0 added, 0 removed; done.
  Running hooks in /etc/ca-certificates/update.d...
  done.
  Errors were encountered while processing:
   firmware-microbit-micropython-dl

(at the time of reporting this bug, the downloaded file has size 1832972
and md5sum d6f85e0f84b62e67fc18907c1a8920b9)


cheers,

Andreas


firmware-microbit-micropython-dl_1.2.4+dfsg-7.log.gz
Description: application/gzip

Bug#991274: Package libldap-2.4-2 was built without LDAP_CONNECTIONLESS

[Ryan Tandy]

Control: severity -1 wishlist

Hi,

I'm afraid this is too late for Debian 11 (bullseye). We could look at 
enabling it for Debian 12 (bookworm).


On Mon, Jul 19, 2021 at 03:35:38PM +0200, Gerald Vincent wrote:

Since 2.4.0, package sssd needs openldap library built with CONNECTIONLESS 
support to use cldap:// requests.
Without this feature enables, sssd is no longer working properly with Active 
Directory.


Why does the new version of sssd require this? Can it not remain 
optional on their side, if it was in the past?


See https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=539421 for the 
previous request about LDAP_CONNECTIONLESS. As far as I know the 
upstream status hasn't changed...


thanks
Ryan

Bug#941199: Upstream has valid debian packaging

[fossdd]

Hey guys,

is there anything news or a ETA?

3 months later and still not a package available.

Cheers,

fossdd

Bug#990566: dovecot: CVE-2021-33515 CVE-2021-29157 CVE-2020-28200

[Noah Meyerhans]

On Sat, Jul 17, 2021 at 09:05:32PM +0200, Salvatore Bonaccorso wrote:
> > CVE-2021-33515[0]:
> > | The submission service in Dovecot before 2.3.15 allows STARTTLS
> > | command injection in lib-smtp. Sensitive information can be redirected
> > | to an attacker-controlled address.
> > 
> > https://dovecot.org/pipermail/dovecot-news/2021-June/000462.html
> > https://www.openwall.com/lists/oss-security/2021/06/28/2
> > 
> > 
> > CVE-2021-29157[1]:
> > | Dovecot before 2.3.15 allows ../ Path Traversal. An attacker with
> > | access to the local filesystem can trick OAuth2 authentication into
> > | using an HS256 validation key from an attacker-controlled location.
> > | This occurs during use of local JWT validation with the posix fs
> > | driver.
> > 
> > https://dovecot.org/pipermail/dovecot-news/2021-June/000461.html
> > https://www.openwall.com/lists/oss-security/2021/06/28/1
> > 
> > 
> > CVE-2020-28200[2]:
> > | The Sieve engine in Dovecot before 2.3.15 allows Uncontrolled Resource
> > | Consumption, as demonstrated by a situation with a complex regular
> > | expression for the regex extension.
> > 
> > https://dovecot.org/pipermail/dovecot-news/2021-June/000460.html
> > https://www.openwall.com/lists/oss-security/2021/06/28/3
> > 
> > 
> > If you fix the vulnerabilities please also make sure to include the
> > CVE (Common Vulnerabilities & Exposures) ids in your changelog entry.
> > 
> > For further information see:
> > 
> > [0] https://security-tracker.debian.org/tracker/CVE-2021-33515
> > https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-33515
> > [1] https://security-tracker.debian.org/tracker/CVE-2021-29157
> > https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-29157
> > [2] https://security-tracker.debian.org/tracker/CVE-2020-28200
> > https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-28200
> > 
> > Please adjust the affected versions in the BTS as needed.
> 
> Do you have a chance to try to get this yet in time for bullseye? Do
> you have time for it (I do agree the time is now very tight).

It's not clear if I'll be able to get this fixed ahead of the release,
but I am working on it.  The individual upstream git commits aren't
easily correlated with the CVEs, and there's a lot of modified context,
making it difficult to cherry-pick individual changes even when they can
be identified.

Stay tuned...

noah

Bug#991275: tar doesn't restore all directory timestamps from the extracted archive

[Vincent Lefevre]

I can see that the --delay-directory-restore option solves the issue.
But IMHO, this option should be the default to avoid surprising
results (the linux package doesn't ensure that the items are
"correctly" ordered, if I understand its debian/rules.real file).

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Bug#990832: Updates

[Don Armstrong]

Thanks for all of the work and the patching.

The debug output that you're showing looks a lot like some of the
necessary macros aren't enabled in the postfix config; can you compare
what you have to what is listed in README.Debian?

I'll try to take another look at the code that you have which is working
and see what is going on there.


-- 
Don Armstrong  https://www.donarmstrong.com

I learned really early the difference between knowing the name of
something and knowing something
 -- Richard Feynman "What is Science" Phys. Teach. 7(6) 1969

Bug#991279: unblock: jetty9/9.4.39-3

[Markus Koschany]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
X-Debbugs-Cc: a...@debian.org

Please unblock package jetty9

[ Reason ]

jetty9 in Bullseye is vulnerable to CVE-2021-34429.
https://bugs.debian.org/991188

[ Tests ]

I have backported all the Junit tests for CVE-2021-34429 and there
were no test suite regressions.

[ Risks ]

The debdiff is rather large but that could not be avoided. The working
test suite makes me confident the issue has been fixed.

[ Checklist ]
  [x] all changes are documented in the d/changelog
  [x] I reviewed all changes and I approve them
  [x] attach debdiff against the package in testing


jetty9.debdiff.gz
Description: application/gzip

Bug#757356: Apple keyboard: Scan code event (EV_MSC) not generated when the EV_KEY event is generated by hid-apple.c

[Vincent Lefevre]

On 2021-06-02 17:24:38 +0200, Salvatore Bonaccorso wrote:
> Can you, time permitting, starting from there (and needed refreshes)
> try to confirm if the patch solves the issue on top of 5.10.40?

First, the patch did not apply correctly on top of 5.10.46 (currently
in unstable). So I've updated it and attached this new version. (I'm not
sure that the change concerning REL_HWHEEL is needed, but in any case,
it may be safer and it shouldn't hurt, thanks to the "type == EV_KEY"
test.)

Then I couldn't test it because the kernel build fails:

[...]
  CC  fs/locks.o
  CC  fs/binfmt_script.o
  CC  fs/binfmt_elf.o
  CC  fs/compat_binfmt_elf.o
  CC  fs/posix_acl.o
  CC  fs/coredump.o
  CC  fs/drop_caches.o
  CC  fs/fhandle.o
  CC  fs/dcookies.o
  CC [M]  fs/binfmt_misc.o
  CC [M]  fs/mbcache.o
  AR  fs/built-in.a
make[2]: *** [debian/rules:7: build-arch] Error 2
dpkg-buildpackage: error: debian/rules binary subprocess returned exit status 2
make[1]: *** [scripts/Makefile.package:77: deb-pkg] Error 2
make: *** [Makefile:1573: deb-pkg] Error 2

I don't know whether this matters, but the /usr/src/linux-source-5.10.tar.xz
archive is not extracted properly by tar, with directories having
incorrect timestamps. I've reported a bug for this:

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

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)
--- a/drivers/hid/hid-apple.c   2021-06-23 12:42:55.0 +
+++ b/drivers/hid/hid-apple.c   2021-07-19 13:15:39.478215724 +
@@ -187,6 +187,15 @@
return NULL;
 }
 
+static void input_event_with_scancode(struct input_dev *input,
+   __u8 type, __u16 code, unsigned int hid, __s32 value)
+{
+   if (type == EV_KEY &&
+   (!test_bit(code, input->key)) == value)
+   input_event(input, EV_MSC, MSC_SCAN, hid);
+   input_event(input, type, code, value);
+}
+
 static int hidinput_apple_event(struct hid_device *hid, struct input_dev 
*input,
struct hid_usage *usage, __s32 value)
 {
@@ -199,7 +208,8 @@
 
if (usage->code == fn_keycode) {
asc->fn_on = !!value;
-   input_event(input, usage->type, KEY_FN, value);
+   input_event_with_scancode(input, usage->type, KEY_FN,
+   usage->hid, value);
return 1;
}
 
@@ -240,7 +250,8 @@
code = do_translate ? trans->to : trans->from;
}
 
-   input_event(input, usage->type, code, value);
+   input_event_with_scancode(input, usage->type, code,
+   usage->hid, value);
return 1;
}
 
@@ -258,8 +269,8 @@
clear_bit(usage->code,
asc->pressed_numlock);
 
-   input_event(input, usage->type, trans->to,
-   value);
+   input_event_with_scancode(input, usage->type,
+   trans->to, usage->hid, value);
}
 
return 1;
@@ -270,7 +281,8 @@
if (hid->country == HID_COUNTRY_INTERNATIONAL_ISO) {
trans = apple_find_translation(apple_iso_keyboard, 
usage->code);
if (trans) {
-   input_event(input, usage->type, trans->to, 
value);
+   input_event_with_scancode(input, usage->type,
+   trans->to, usage->hid, value);
return 1;
}
}
@@ -279,7 +291,8 @@
if (swap_opt_cmd) {
trans = apple_find_translation(swapped_option_cmd_keys, 
usage->code);
if (trans) {
-   input_event(input, usage->type, trans->to, value);
+   input_event_with_scancode(input, usage->type,
+   trans->to, usage->hid, value);
return 1;
}
}
@@ -287,7 +300,8 @@
if (swap_fn_leftctrl) {
trans = apple_find_translation(swapped_fn_leftctrl_keys, 
usage->code);
if (trans) {
-   input_event(input, usage->type, trans->to, value);
+   input_event_with_scancode(input, usage->type,
+   trans->to, usage->hid, value);
return 1;
}
}
@@ -306,8 +320,8 @@
 
if ((asc->quirks & APPLE_INVERT_HWHEEL) &&
usage->code == REL_HWHEEL) {
-   inpu

Bug#991275: tar doesn't restore all directory timestamps from the extracted archive

[Vincent Lefevre]

Note: I did not do the bug report from the machine for which I posted
the results, but there are exactly the same results for this second
machine (they are both Debian/unstable machines).

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Bug#991277: ITP: cutesv -- comprehensive discovery of structural variations of genomic sequences

[Steffen Moeller]

Package: wnpp
Severity: wishlist

Subject: ITP: cutesv -- comprehensive discovery of structural variations of 
genomic sequences
Package: wnpp
Owner: Steffen Moeller 
Severity: wishlist

* Package name: cutesv
  Version : 1.0.11
  Upstream Author : JiangTao
* URL : https://github.com/tjiangHIT/cuteSV
* License : MIT
  Programming Lang: Python
  Description : comprehensive discovery of structural variations of genomic 
sequences
 Long-read sequencing enables the comprehensive discovery of structural
 variations (SVs). However, it is still non-trivial to achieve high
 sensitivity and performance simultaneously due to the complex SV
 characteristics implied by noisy long reads. 
 .
 cuteSV is a sensitive, fast and scalable long-read-based SV detection
 approach. cuteSV uses tailored methods to collect the signatures of
 various types of SVs and employs a clustering-and-refinement method to
 analyze the signatures to implement sensitive SV detection. Benchmarks
 on real Pacific Biosciences (PacBio) and Oxford Nanopore Technology
 (ONT) datasets demonstrate that cuteSV has better yields and scalability
 than state-of-the-art tools.

Remark: This package is maintained by Debian Med Packaging Team at
   https://salsa.debian.org/med-team/cutesv

Bug#991275: tar doesn't restore all directory timestamps from the extracted archive

[Vincent Lefevre]

Package: tar
Version: 1.34+dfsg-1
Severity: important

tar doesn't restore all directory timestamps from the extracted archive.

Example with

  tar -xaf /usr/src/linux-source-5.10.tar.xz

There are 4712 directories, but 118 of them have a recent timestamp.

zira% find linux-source-5.10 -type d | wc -l
4712
zira% find linux-source-5.10 -mtime -1 | wc -l
118
zira% find linux-source-5.10 -mtime -1 -type d | wc -l
118

e.g.

zira% ls -ld linux-source-5.10/drivers/dma/dw
drwxr-xr-x 2 vinc17 vinc17 4096 2021-07-19 15:45:29 
linux-source-5.10/drivers/dma/dw

(though this directory is present in the archive).

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

Kernel: Linux 5.10.0-8-amd64 (SMP w/12 CPU threads)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=POSIX, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages tar depends on:
ii  libacl1  2.2.53-10
ii  libc62.31-13
ii  libselinux1  3.1-3

tar recommends no packages.

Versions of packages tar suggests:
ii  bzip21.0.8-4
pn  ncompress
pn  tar-doc  
pn  tar-scripts  
ii  xz-utils 5.2.5-2

-- no debconf information

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Bug#991274: Package libldap-2.4-2 was built without LDAP_CONNECTIONLESS

[Gerald Vincent]

Package: libldap-2.4-2 
Version: 2.4.57+dfsg-3 

Hi, 

Since 2.4.0, package sssd needs openldap library built with CONNECTIONLESS 
support to use cldap:// requests. 
Without this feature enables, sssd is no longer working properly with Active 
Directory. 
We have this kind of error meessage: 
`` 
[sss_ldap_init_sys_connect_done] (0x0020): ldap_init_fd failed: Bad parameter 
to an ldap routine. [24][cldap://ad_server:ad_port] 
[sdap_sys_connect_done] (0x0020): sdap_async_connect_call request failed: [5]: 
Input/output error. 
[ad_cldap_ping_done] (0x0040): Unable to get site and forest information [2]: 
No such file or directory 
[sssd_async_socket_init_done] (0x0020): sdap_async_sys_connect request failed: 
[110]: Connection timed out. 
[sss_ldap_init_sys_connect_done] (0x0020): sssd_async_socket_init request 
failed: [110]: Connection timed out. 
[sdap_sys_connect_done] (0x0020): sdap_async_connect_call request failed: 
[110]: Connection timed out. 
[sssd_async_socket_init_done] (0x0020): sdap_async_sys_connect request failed: 
[110]: Connection timed out. 
[sss_ldap_init_sys_connect_done] (0x0020): sssd_async_socket_init request 
failed: [110]: Connection timed out. 
[sdap_sys_connect_done] (0x0020): sdap_async_connect_call request failed: 
[110]: Connection timed out. 
``` 

As Debian 11.0 provide sssd 2.4.0+ package, I guess libldap-2.4-2 should be 
built with LDAP_CONNECTIONLESS flag. 

More information on sssd's github: https://github.com/SSSD/sssd/issues/5391 

Bug#991273: acng: for testing dist fails to download by-hash translations

[Václav Ovsík]

Package: apt-cacher-ng
Version: 3.3.1-2~bpo10+1
Severity: normal

Dear Maintainer,
I tried to install bullseye machine and it fails to download some
translations and installation fails:

 Jul 19 10:29:53 in-target: E: Failed to fetch 
http://debian.i.cz:/debian/dists/bullseye/non-free/i18n/by-hash/SHA256/1719a3a7f5c969d9780aec600763314a8b55aaaed3016a76fa9a7a020c1e584c
  File has unexpected size (50436 != 91475). Mirror sync in progress? [IP: 
10.0.156.66 ]
 Jul 19 10:29:53 in-target:Hashes of expected file: 

 Jul 19 10:29:53 in-target: - Filesize:91475 [weak] 

 Jul 19 10:29:53 in-target: - 
SHA256:1719a3a7f5c969d9780aec600763314a8b55aaaed3016a76fa9a7a020c1e584c 
  
 Jul 19 10:29:53 in-target: - MD5Sum:c3ad4b048f3df02478a64b33ef776008 
[weak]
 Jul 19 10:29:53 in-target:Release file created at: Mon, 19 Jul 2021 
08:07:25 + 
 Jul 19 10:29:53 in-target: E: Failed to fetch 
http://debian.i.cz:/debian/dists/bullseye/contrib/i18n/by-hash/SHA256/57e6201d62bf60faf1a188ac528d0717cce16b6cfa1c9b91a0b89cc5b16e10f3
   
 Jul 19 10:29:53 in-target: E: Some index files failed to download. They have 
been ignored, or old ones used instead.   


Its obvious from the curl output:

 zito@ser1:~/admin$ curl --head 
http://debian.i.cz:/debian/dists/bullseye/non-free/i18n/by-hash/SHA256/1719a3a7f5c969d9780aec600763314a8b55aaaed3016a76fa9a7a020c1e584c
 HTTP/1.1 200 OK
 Content-Length: 50436
 Last-Modified: Tue, 15 Jun 2021 01:57:32 GMT
 Content-Type: application/octet-stream
 Date: Mon Jul 19 12:21:12 2021
 Server: Debian Apt-Cacher NG/3.3.1
 X-Original-Source: 
http://ftp.cz.debian.org/debian/dists/bullseye/non-free/i18n/by-hash/SHA256/1719a3a7f5c969d9780aec600763314a8b55aaaed3016a76fa9a7a020c1e584c
 Connection: Keep-Alive
 
 zito@ser1:~/admin$ curl --head 
http://ftp.cz.debian.org/debian/dists/bullseye/non-free/i18n/by-hash/SHA256/1719a3a7f5c969d9780aec600763314a8b55aaaed3016a76fa9a7a020c1e584c
 HTTP/1.1 200 OK
 Date: Mon, 19 Jul 2021 12:21:24 GMT
 Server: Apache/2.4.38 (Debian)
 Last-Modified: Tue, 08 Jun 2021 02:07:45 GMT
 ETag: "16553-5c4379fb85020"
 Accept-Ranges: bytes
 Content-Length: 91475


Maybe can be workarounded using some configuration pattern.
Regards
-- 
Zito

-- Package-specific info:

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

Kernel: Linux 4.19.0-17-amd64 (SMP w/2 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=cs_CZ.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US:en (charmap=UTF-8)
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages apt-cacher-ng depends on:
ii  adduser  3.118
ii  debconf [debconf-2.0]1.5.71
ii  dpkg 1.19.7
ii  libatomic1   8.3.0-6
ii  libbz2-1.0   1.0.6-9.2~deb10u1
ii  libc62.28-10
ii  libevent-2.1-6   2.1.8-stable-4
ii  libevent-pthreads-2.1-6  2.1.8-stable-4
ii  libgcc1  1:8.3.0-6
ii  liblzma5 5.2.4-1
ii  libssl1.11.1.1d-0+deb10u6
ii  libstdc++6   8.3.0-6
ii  libsystemd0  241-7~deb10u7
ii  libwrap0 7.6.q-28
ii  lsb-base 10.2019051400
ii  zlib1g   1:1.2.11.dfsg-1

Versions of packages apt-cacher-ng recommends:
ii  ca-certificates  20200601~deb10u2

Versions of packages apt-cacher-ng suggests:
pn  avahi-daemon  
pn  doc-base  
ii  libfuse2  2.9.9-1+deb10u1

-- Configuration Files:
/etc/apt-cacher-ng/security.conf [Errno 13] Permission denied: 
'/etc/apt-cacher-ng/security.conf'

-- debconf information:
  apt-cacher-ng/cachedir: keep
  apt-cacher-ng/proxy: keep
  apt-cacher-ng/bindaddress: keep
  apt-cacher-ng/gentargetmode: No automated setup
  apt-cacher-ng/port: keep
* apt-cacher-ng/tunnelenable: false

Bug#988963: libgc1c2: please drop obsolete Conflicts/Replaces on libgc1 in buster, it interferes with upgrades to bullseye

[Andreas Beckmann]

On Wed, 30 Jun 2021 21:36:54 +0200 Paul Gevers  wrote:

Hi libgc maintainers,



Can you please comment? We missed the 10.10 point release already and
10.11 may happen after we release bullseye, but at least we could
improve the upgrade for people upgrading after 10.11. Do you agree with
me doing an NMU to fix this issue?


I've been running my local piuparts buster->bullseye upgrade tests with 
the attached patch applied to src:libgc in buster. Except for some 
corner cases this has resolved the majority of the upgrade paths where 
the circular Conflicts previously prevented libgc1 and guile-X.Y-libs

to be upgraded.


Andreas
diff -Nru libgc-7.6.4/debian/changelog libgc-7.6.4/debian/changelog
--- libgc-7.6.4/debian/changelog	2018-09-09 15:25:27.0 +0200
+++ libgc-7.6.4/debian/changelog	2021-06-30 22:34:37.0 +0200
@@ -1,3 +1,12 @@
+libgc (1:7.6.4-0.4+deb10u1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * libgc1c2: Downgrade 'Conflicts+Replaces: libgc1' to
+'Breaks+Replaces: libgc1 (<< 1:8)' to avoid circular Conflicts on upgrades
+to bullseye.  (Closes: #988963)
+
+ -- Andreas Beckmann   Wed, 30 Jun 2021 22:34:37 +0200
+
 libgc (1:7.6.4-0.4) unstable; urgency=medium
 
   * Non-maintainer upload.
diff -Nru libgc-7.6.4/debian/control libgc-7.6.4/debian/control
--- libgc-7.6.4/debian/control	2018-09-08 17:50:13.0 +0200
+++ libgc-7.6.4/debian/control	2021-06-30 22:34:37.0 +0200
@@ -17,8 +17,8 @@
 Architecture: any
 Pre-Depends: ${misc:Pre-Depends}
 Depends: ${misc:Depends}, ${shlibs:Depends}
-Conflicts: libgc1
-Replaces: libgc1, libgc1c3
+Breaks: libgc1 (<< 1:8)
+Replaces: libgc1 (<< 1:8), libgc1c3
 Multi-Arch: same
 Description: conservative garbage collector for C and C++
  Boehm-Demers-Weiser's GC is a garbage collecting storage allocator that is

Bug#990990: unblock: libcgroup/2.0

[Santiago Ruano Rincón]

On Thu, 15 Jul 2021 12:27:35 +0200 Paul Gevers  wrote:
> Hi,
> 
> On 12-07-2021 18:45, Michael Biebl wrote:
> > This was already discussed in
> > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=959022
> > 
> > My takeaway from that discussion was, that rdeps of cgroup-tools, would
> > itself have to be made cgroupv2 aware, especially OpenStack and its
> > components.
> 
> That resembles my understanding of that discussion too.

Mine too.

zigo, are there any news from openstack about this?

> 
> > Have those rdeps been tested successfully with libcgroup/cgroup-tools
> > from experimental?
> 
> I'm not in favor of doing this transition now.
> 

Please, keep in mind this comment, made before the release of 2.0:
"we are planning something for next week. The version number will
probably be 2.0 - with expectation that the v2 cycle will have
continously breaking ABI. When we are happy where it is, we will push
out v3 which will then maintain ABI through its lifetime."
https://github.com/libcgroup/libcgroup/issues/12#issuecomment-825816328

Cheers,

 -- Santiago


signature.asc
Description: PGP signature

Bug#991272: unblock: bible-kjv/4.34

[Matthew Vernon]

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

Please unblock package bible-kjv

TL;DR: This fixes #991133 ("important"), a regression from
buster. There are two parts to the fix, both small.

unblock bible-kjv/4.34

Bug #991133 is that searching does not work ; this upload fixes that
by making the build non-parallel again, and addressing a longstanding
error that the concordance would be empty if built on a system without
"bible" already installed. This bug is a regression from buster.

The parallelism in the build system was introduced in 4.32 as a
side-effect of moving to dh_auto_build (to make cross-building work);
fixing that is straightforwardly a matter of specifying --no-parallel
to the dh_auto_build invocation.

The other fix is to use bible.rawtext as the source for the
concordance building, rather than trying to invoke "bible" to output
the entire text. This is a small adjustment to the makeconc.pl file
(diff below).

Neither of these bugs cause the package to fail to build, they rather
result in a package built with an empty concordance, which means that
all search attempts fail. Both fixes are necessary (e.g. if I build on
my bullseye system with bible installed, I still need the
--no-parallel fix).

>From a user POV, the buggy version cannot search anything:
bible(KJV) [Gen1:1]> ??hath
  Searching for 'hath'... not found.

whereas a fixed version does:
bible(KJV) [Gen1:1]> ??hath
  Searching for 'hath'... [1840 refs]

This is quite a significant impact on usability, and the fix a very
small diff, so I hope you can unblock this for bullseye, please :)

[
aside: you can tell the fix is working from the buildd logs; if you
look at a 4.32 buildd log and search for "Concordance data file", you see
Concordance data file:
  Version:  02
  Name: KJV Concordance
  Contents: 0 words
  Word list at file offset 100
  Index at file offset 101
  Data at file offset 103
NB the "0 words" -
https://buildd.debian.org/status/fetch.php?pkg=bible-kjv&arch=amd64&ver=4.32&stamp=1613928140&raw=0

whereas in a fixed version, you see:
Concordance data file:
  Version:  02
  Name: KJV Concordance
  Contents: 12544 words
  Word list at file offset 100
  Index at file offset 101823
  Data at file offset 126913
NB the >0 words :)
https://buildd.debian.org/status/fetch.php?pkg=bible-kjv&arch=amd64&ver=4.34&stamp=1626696782&raw=0
]

source debdiff:

diff -Nru bible-kjv-4.32/debian/changelog bible-kjv-4.34/debian/changelog
--- bible-kjv-4.32/debian/changelog 2021-02-21 16:05:00.0 +
+++ bible-kjv-4.34/debian/changelog 2021-07-19 12:36:43.0 +0100
@@ -1,3 +1,16 @@
+bible-kjv (4.34) unstable; urgency=medium
+
+  * Check for error return value
+
+ -- Matthew Vernon   Mon, 19 Jul 2021 12:36:43 +0100
+
+bible-kjv (4.33) unstable; urgency=medium
+
+  * Make the build not run in parallel 
+  * Use bible.rawtext to build concordance (Closes: #991133)
+
+ -- Matthew Vernon   Mon, 19 Jul 2021 12:10:28 +0100
+
 bible-kjv (4.32) unstable; urgency=medium
 
   * Patch from Helmut Grohne to fix FTCBFS: (Closes: #947616)
diff -Nru bible-kjv-4.32/debian/rules bible-kjv-4.34/debian/rules
--- bible-kjv-4.32/debian/rules 2021-02-21 16:05:00.0 +
+++ bible-kjv-4.34/debian/rules 2021-07-19 12:36:43.0 +0100
@@ -20,9 +20,9 @@
 
 build:
$(checkdir)
-   dpkg-architecture -a$(DEB_BUILD_ARCH) -f -c dh_auto_build -- 
bible-index.c bible.data bible.data.conc 'LD=$$(CC)'
+   dpkg-architecture -a$(DEB_BUILD_ARCH) -f -c dh_auto_build --no-parallel 
-- bible-index.c bible.data bible.data.conc 'LD=$$(CC)'
rm -f *.o
-   dh_auto_build -- bible 'LD=$$(CC)'
+   dh_auto_build --no-parallel -- bible 'LD=$$(CC)'
cd debian && $(CC) -g -O2 -o randverse randverse.c
touch build
 
diff -Nru bible-kjv-4.32/makeconc.pl bible-kjv-4.34/makeconc.pl
--- bible-kjv-4.32/makeconc.pl  2021-02-21 16:05:00.0 +
+++ bible-kjv-4.34/makeconc.pl  2021-07-19 12:36:43.0 +0100
@@ -18,6 +18,7 @@
 #  Received from Chris Eich, replaces "makeconcordance" script.
 #  Made use of stopwords conditional.
 ###
+use IO::Handle
 
 # Putting . on PATH ensures that the bible program will be found.
 $ENV{'PATH'} =~ s/^:*/.:/;
@@ -40,7 +41,8 @@
 # Generate plain text file, one "record" (e.g. bible verse) per line.
 # Fill %lines and $count tables, which are keyed by words.
 
-open(BIBLE, "$PROG -f gen1:1-rev99:99 |");
+open(BIBLE, "bible.rawtext");
+; #discard the header line
 while () {
 s/^\S+\s+//;   # Cut off the record reference that starts each line.
 tr/A-Z/a-z/;   # Downcase.
@@ -53,7 +55,7 @@
$lines{$word} .= " " . $.;
 }
 }
-close(BIBLE);
+die $! if BIBLE->error();
 
 # Create raw concordance, listing the lines where each word occurs.
 





-- System Information:
Debian Release: 9.13
  APT prefers oldstable
  APT

Bug#991266: postinst: Can't exec systemctl: No such file or directory

[Lorenzo Puliti]

Package: proftpd-core
Version: 1.3.7b+dfsg-1
Severity: normal
Tags: patch
X-Debbugs-Cc: plore...@disroot.org

Dear Maintainer,

during the last upgrade of proftpd i got

[...]
Setting up proftpd-core (1.3.7b+dfsg-1) ...
usermod: no changes
Can't exec "systemctl": No such file or directory at 
/usr/bin/deb-systemd-invoke line 110.
sh: 1: systemctl: not found
Can't exec "systemctl": No such file or directory at 
/usr/bin/deb-systemd-invoke line 94.
proftpd.service is a disabled or a static unit not running, not starting it.
insserv: warning: current start runlevel(s) (empty) of script `proftpd' 
overrides LSB defaults (2 3 4 5).
insserv: warning: current stop runlevel(s) (0 1 2 3 4 5 6) of script `proftpd' 
overrides LSB defaults (0 1 6).
insserv: Script `lvm2' has overlapping Default-Start and Default-Stop runlevels 
(S) and (S). This should be fixed.
Stopping ftp server: proftpd.
Starting ftp server: proftpd.
[...]

Not a tragic issue since it looks that postinst script proceeds anyway with the 
rest
of the configuration, but if you look at snippets from debhelper 
deb-systemd-invoke is always
called only if systemd is PID1. The patch at the bottom should fix the issue.

Regards,
Lorenzo

$ diff -u ./proftpd-core.postinst proftpd-core.postinst-new 
--- ./proftpd-core.postinst 2021-07-15 23:33:15.0 +0200
+++ proftpd-core.postinst-new   2021-07-19 10:02:48.080741451 +0200
@@ -207,8 +207,10 @@
# enable and start proftpd daemon via systemctl
if egrep -qi "^[[:space:]]*ServerType.*standalone" 
/etc/proftpd/proftpd.conf
then
-   deb-systemd-invoke enable proftpd.service
-   deb-systemd-invoke restart proftpd.service
+   if [ -d /run/systemd/system ]; then
+   deb-systemd-invoke enable proftpd.service
+   deb-systemd-invoke restart proftpd.service
+   fi
fi
 fi
 


-- System Information:
Debian Release: 11.0
  APT prefers unstable
  APT policy: (500, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 5.7.0-1-amd64 (SMP w/4 CPU threads)
Kernel taint flags: TAINT_FIRMWARE_WORKAROUND, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US:en
Shell: /bin/sh linked to /bin/dash
Init: runit (via /run/runit.stopit)

Versions of packages proftpd-core depends on:
ii  adduser  3.118
ii  debianutils  4.11.2
ii  init-system-helpers  1.60
ii  libacl1  2.2.53-10
ii  libc62.31-13
ii  libcap2  1:2.44-1
ii  libcrypt11:4.4.18-4
ii  libhiredis0.14   0.14.1-1
ii  libmemcached11   1.0.18-4.2
ii  libmemcachedutil21.0.18-4.2
ii  libncursesw6 6.2+20201114-2
ii  libpam-runtime   1.4.0-9
ii  libpam0g 1.4.0-9
ii  libpcre3 2:8.39-13
ii  libssl1.11.1.1k-1
ii  libtinfo66.2+20201114-2
ii  lsb-base 11.1.0
ii  netbase  6.3
ii  sed  4.7-1
ii  ucf  3.0043
ii  zlib1g   1:1.2.11.dfsg-2

Versions of packages proftpd-core recommends:
ii  proftpd-doc  1.3.7b+dfsg-1

Versions of packages proftpd-core suggests:
pn  openbsd-inetd | inet-superserver  
ii  openssl   1.1.1k-1
ii  proftpd-mod-crypto1.3.7b+dfsg-1
pn  proftpd-mod-geoip 
pn  proftpd-mod-ldap  
pn  proftpd-mod-mysql 
pn  proftpd-mod-odbc  
pn  proftpd-mod-pgsql 
pn  proftpd-mod-snmp  
pn  proftpd-mod-sqlite
ii  proftpd-mod-wrap  1.3.7b+dfsg-1

-- no debconf information

Bug#991271: fossil: Fix TLS hostname verification

[Martin]

Package: fossil
Version: 1:2.8-1
Severity: normal

Dear Maintainer,

It seems fossil 2.8 is also affected by [1] and I think it should be
updated as well.  The following patch might work as a starting point,
but I haven't tested anything beside it reporting an error when the host
name doesn't match.  It is an adaption of the patch at [1].

Best,

Martin

[1]: https://fossil-scm.org/home/info/aaab2a15d1dfc22f

--- fossil-2.8.orig/src/http_ssl.c
+++ fossil-2.8/src/http_ssl.c
@@ -236,6 +236,7 @@ static int establish_proxy_tunnel(UrlDat
 */
 int ssl_open(UrlData *pUrlData){
   X509 *cert;
+  const char *zRemoteHost;
   int hasSavedCertificate = 0;
   int trusted = 0;
   unsigned long e;
@@ -273,8 +274,10 @@ int ssl_open(UrlData *pUrlData){
 
 iBio = BIO_new_ssl(sslCtx, 1);
 BIO_push(iBio, sBio);
+zRemoteHost = pUrlData->hostname;
   }else{
 iBio = BIO_new_ssl_connect(sslCtx);
+zRemoteHost = pUrlData->name;
   }
   if( iBio==NULL ) {
 ssl_set_errmsg("SSL: cannot open SSL (%s)",
@@ -284,13 +287,20 @@ int ssl_open(UrlData *pUrlData){
   BIO_get_ssl(iBio, &ssl);
 
 #if (SSLEAY_VERSION_NUMBER >= 0x00908070) && !defined(OPENSSL_NO_TLSEXT)
-  if( !SSL_set_tlsext_host_name(ssl, 
(pUrlData->useProxy?pUrlData->hostname:pUrlData->name)) ){
+  if( !SSL_set_tlsext_host_name(ssl, zRemoteHost) ){
 fossil_warning("WARNING: failed to set server name indication (SNI), "
   "continuing without it.\n");
   }
 #endif
 
   SSL_set_mode(ssl, SSL_MODE_AUTO_RETRY);
+#if OPENSSL_VERSION_NUMBER >= 0x010002000
+  X509_VERIFY_PARAM *param = 0;
+  param = SSL_get0_param(ssl);
+  if( !X509_VERIFY_PARAM_set1_host(param, zRemoteHost, strlen(zRemoteHost)) ){
+fossil_fatal("failed to set hostname");
+  }
+#endif
 
   if( !pUrlData->useProxy ){
 char *connStr = mprintf("%s:%d", pUrlData->name, pUrlData->port);

Bug#945315: pan: error sending posts

[Thomas Noll]

Dear Maintainer,

is there a chance getting this fixed in Debian even if upstream doesn't 
seem to care much? 

Kind regards
Thomas

Bug#991264: python2.7: tarfile.py does not catch encoding errors

[Alex]

Package: python2.7
Version: 2.7.16-2+deb10u1
Severity: important

Dear Maintainer,
/usr/lib/python2.7/tarfile.py does not catch encoding errors in tarfile
filenames and throws an exception possibly crashing programs, like
duplicity.

The problem lies in def _proc_pax(self, tarfile):

1396 while True:
1397 match = regex.match(buf, pos)
1398 if not match:
1399 break
1400
1401 length, keyword = match.groups()
1402 length = int(length)
1403 value = buf[match.end(2) + 1:match.start(1) + length - 1]
1404
1405 keyword = keyword.decode("utf8")
1406 value = value.decode("utf8")
1407
1408 pax_headers[keyword] = value
1409 pos += length

Line 1406 seems to need errors="ignore" or errors="replace" to extract
archives with minor encoding errors in the filenames or should throw a
more specific exception than UnicodeDecodeError.


-- System Information:
Debian Release: 10.9
  APT prefers stable
  APT policy: (900, 'stable')
Architecture: amd64 (x86_64)

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

Versions of packages python2.7 depends on:
ii  libpython2.7-stdlib  2.7.16-2+deb10u1
ii  mime-support 3.62
ii  python2.7-minimal2.7.16-2+deb10u1

python2.7 recommends no packages.

Versions of packages python2.7 suggests:
ii  binutils   2.31.1-16
pn  python2.7-doc  

-- no debconf information

Bug#991270: unblock: suricata/6.0.1-3

[Sascha Steinbiss]

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

Please unblock package suricata

This minimal patch that I added fixes CVE-2021-35063 by backporting the
corresponding fix commit from upstream [1]. By doing so it addresses
#990835.

I have added a debdiff to this bugreport that illustrates the
situation. I could upload to unstable anytime. Please let me know if the
fix is appropriate and I will initiate an upload if confirmed.

Thanks
Sascha

[1] 
https://github.com/OISF/suricata/commit/556570f7dd7f21f11cffda5ebcb72738a29cbb90
 

unblock suricata/6.0.1-3
diff -Nru suricata-6.0.1/debian/changelog suricata-6.0.1/debian/changelog
--- suricata-6.0.1/debian/changelog 2020-12-11 09:35:57.0 +0100
+++ suricata-6.0.1/debian/changelog 2021-07-19 13:26:22.0 +0200
@@ -1,3 +1,10 @@
+suricata (1:6.0.1-3) unstable; urgency=medium
+
+  * Address CVE-2021-35063 by backporting upstream fix.
+Closes: #990835
+
+ -- Sascha Steinbiss   Mon, 19 Jul 2021 13:26:22 +0200
+
 suricata (1:6.0.1-2) unstable; urgency=medium
 
   * Also specify explicit separate '-latomic' reference on mipsel.
diff -Nru suricata-6.0.1/debian/patches/series 
suricata-6.0.1/debian/patches/series
--- suricata-6.0.1/debian/patches/series2020-12-09 23:02:55.0 
+0100
+++ suricata-6.0.1/debian/patches/series2021-07-19 13:26:22.0 
+0200
@@ -9,3 +9,4 @@
 remove-conflicting-python-file.patch
 avoid-to-include-if_tunnel-h.patch
 llc.patch
+stream-no-reject-bad-ack.patch
diff -Nru suricata-6.0.1/debian/patches/stream-no-reject-bad-ack.patch 
suricata-6.0.1/debian/patches/stream-no-reject-bad-ack.patch
--- suricata-6.0.1/debian/patches/stream-no-reject-bad-ack.patch
1970-01-01 01:00:00.0 +0100
+++ suricata-6.0.1/debian/patches/stream-no-reject-bad-ack.patch
2021-07-19 13:26:22.0 +0200
@@ -0,0 +1,30 @@
+From 556570f7dd7f21f11cffda5ebcb72738a29cbb90 Mon Sep 17 00:00:00 2001
+From: Eric Leblond 
+Date: Fri, 28 May 2021 12:19:38 +0200
+Subject: [PATCH] stream/tcp: don't reject on bad ack
+
+Not using a packet for the streaming analysis when a non zero
+ACK value and ACK bit was unset was leading to evasion as it was
+possible to start a session with a SYN packet with a non zero ACK
+value to see the full TCP stream to escape all stream and application
+layer detection.
+
+This addresses CVE-2021-35063.
+
+Fixes: fa692df37 ("stream: reject broken ACK packets")
+
+Ticket: #4504.
+---
+ src/stream-tcp.c | 1 -
+ 1 file changed, 1 deletion(-)
+
+--- a/src/stream-tcp.c
 b/src/stream-tcp.c
+@@ -4789,7 +4789,6 @@
+ /* broken TCP 
http://ask.wireshark.org/questions/3183/acknowledgment-number-broken-tcp-the-acknowledge-field-is-nonzero-while-the-ack-flag-is-not-set
 */
+ if (!(p->tcph->th_flags & TH_ACK) && TCP_GET_ACK(p) != 0) {
+ StreamTcpSetEvent(p, STREAM_PKT_BROKEN_ACK);
+-goto error;
+ }
+ 
+ /* If we are on IPS mode, and got a drop action triggered from

Bug#991133: One other necessary fix

[Matthew Vernon]

Hi,

The other bug was that makeconc.pl tries to run "bible -f 
gen1:1-rev99:99" to generate the text it builds the raw concordance 
from; obviously this doesn't work on chroots / buildds.


It's also unnecessary, since we have the rawtext file in the source 
tree, so use that instead.


This now works on my various test systems, including clean chroots.

I've uploaded 4.33; and will send an unblock request.

Regards,

Matthew

Bug#989785: devscripts: wrap-and-sort ignores --trailing-comma on non-sorted fields/Uploaders

[Mattia Rizzolo]

On Tue, Jun 15, 2021 at 01:47:11PM +0900, Norbert Preining wrote:
> Hi Mattia,
> 
> > Can you describe with an example or something more specific what you are
> > observing?
> 
> Ah, it only happens with *one* Uploader:
> $ head -6 debian/control
> Source: layer-shell-qt
> Section: kde
> Priority: optional
> Maintainer: Debian Qt/KDE Maintainers 
> Uploaders: Norbert Preining ,
> Build-Depends: cmake (>= 3.16~),
> 
> $ wrap-and-sort -t
> 
> $ head -6 debian/control
> Source: layer-shell-qt
> Section: kde
> Priority: optional
> Maintainer: Debian Qt/KDE Maintainers 
> Uploaders: Norbert Preining 
> Build-Depends: cmake (>= 3.16~),
> 
> The final comma after uploaders is gone.

Right.

That's because the trailing comma is added only in case of wrapping.  If
you are not wrapping you won't get it.
I.e., if you use -at you get it, else you won't.  It's not really
connected with "1 uploader", rather the lenght of the name of said
uploader.

> Not that important, but when automatizing tasks with a few hundred
> packages of KDE, I would like to see less changes in the actual git
> commits.

Honestly, I'm a big proponent of -ast - to the point that I entertain
making it the default: https://bugs.debian.org/895570  :)

-- 
regards,
Mattia Rizzolo

GPG Key: 66AE 2B4A FCCF 3F52 DA18  4D18 4B04 3FCD B944 4540  .''`.
More about me:  https://mapreri.org : :'  :
Launchpad user: https://launchpad.net/~mapreri  `. `'`
Debian QA page: https://qa.debian.org/developer.php?login=mattia  `-


signature.asc
Description: PGP signature

Bug#991268: [Aptitude-devel] Bug#991268: aptitude should provide an option to install packages from lower priority repos (backports, experimental) if the runtime dependency specify a version that can

[Pirate Praveen]

On Mon, 19 Jul 2021 12:14:40 +0200 Julian Andres Klode  
wrote:
> I'm a bit confused because this bug is about aptitude, and there, 
this

> should work already. It might take a couple times of rejecting solver
> choices, though. Did you want to report the bug against apt? I think
> we already have a report for that, though.

Can we force that by a command line option? Else if I have to add this 
in documentation for example for diaspora, I have to say, use aptitude 
and choose n two times etc.


But this did not work for diaspora anyway.

The following packages have unmet dependencies:
libcurl4 : Depends: libnghttp2-14 (>= 1.12.0) but it is not going to 
be installed
   Depends: librtmp1 (>= 2.4+20131018.git79459a2-3~) but it is 
not going to be installed
   Depends: libssh2-1 (>= 1.7.0) but it is not going to be 
installed
libjs-bootstrap : Depends: fonts-glyphicons-halflings but it is not 
going to be installed
libjs-jsxc : Depends: libjs-jquery-fullscreen but it is not going to 
be installed
 Depends: libjs-prettify but it is not going to be 
installed
diaspora : Depends: diaspora-common (>= 0.7.15.0+debian2) but it is 
not going to be installed
   Depends: unicorn (>= 6.0~) but it is not going to be 
installed
   Depends: ruby-unicorn-worker-killer (>= 0.4.5~) but it is 
not going to be installed
   Depends: ruby-devise-two-factor (>= 4.0~) but it is not 
going to be installed
   Depends: ruby-sidekiq (>= 6.2.1~) but 6.0.4+dfsg-2 is to be 
installed
   Depends: ruby-configurate (>= 0.5~) but it is not going to 
be installed
   Depends: ruby-toml-rb (>= 2.0.1~) but it is not going to be 
installed
   Depends: ruby-autoprefixer-rails (>= 10.2.4~) but 
10.1.0.0+dfsg1+~cs14.1.12-5 is to be installed
   Depends: ruby-nokogiri (>= 1.11.3~) but 1.11.1+dfsg-2 is to 
be installed
   Depends: ruby-open-graph-reader (>= 0.7.1~) but it is not 
going to be installed
   Depends: ruby-hamlit (>= 2.14.6~) but it is not going to be 
installed
imagemagick : Depends: imagemagick-6.q16 (>= 8:6.9.2.10+dfsg-2~) but 
it is not going to be installed

graphviz : Depends: libann0 but it is not going to be installed
   Depends: libcdt5 but it is not going to be installed
   Depends: libcgraph6 but it is not going to be installed
   Depends: libglib2.0-0 (>= 2.16.0) but it is not going to be 
installed
   Depends: libgts-0.7-5 (>= 0.7.6) but it is not going to be 
installed
   Depends: libgvc6 (>= 2.42.1) but it is not going to be 
installed

   Depends: libgvpr2 but it is not going to be installed
   Depends: liblab-gamut1 but it is not going to be installed
   Depends: libxaw7 but it is not going to be installed
libsass-dev : Depends: libsass1 (= 3.6.4+20201122-1) but it is not 
going to be installed
fonts-roboto-hinted : Depends: fonts-roboto-unhinted (>= 0~20170802~) 
but it is not going to be installed
nodejs : Depends: libnode72 (= 12.21.0~dfsg-5) but it is not going to 
be installed
libgmp-dev : Depends: libgmpxx4ldbl (= 2:6.2.1+dfsg-1) but it is not 
going to be installed
ruby-test-unit : Depends: ruby-power-assert but it is not going to be 
installed
open: 4948; closed: 50871; defer: 12; conflict: 35 oNo solution found 
within the allotted time. Try harder? [Y/n]


After adding 
https://salsa.debian.org/rojin/diaspora-apt-pin-preferences/-/blob/master/99diaspora 
in /etc/apt/preferences.d aptitude and apt can install diaspora.


I started with aptitude because it can already do this for build 
dependencies, but having this in apt would be nice as well.


If you'd like to reproduce this issue, you can use my personal repo at 
https://wiki.debian.org/Diaspora#Bullseye_Backports.2Fpersonal_repo 
which has a package priority of 100 like official backports.

Bug#991122: unblock: varnish/6.5.2-1

[Stig Sandbeck Mathisen]

On Sun, Jul 18, 2021 at 10:14:46AM +0200, Graham Inggs wrote:
> Control: tags -1 + moreinfo
> 
> Hi Stig
> 
> Please attach a filtered debdiff to this bug.  Something like:
> 
> filterdiff -x '*/build-aux/*' -x '*/doc/html/*'
> varnish-6.5.1-1--6.5.2-1.debdiff >filtered.debdiff
> 
> Please also show the command that you end up using, so we can see
> which parts were excluded.

Hello,

I used the command

filterdiff -x '*/build-aux/*' -x '*/doc/html/*' 
varnish-6.5.1-1--6.5.2-1.debdiff > varnish-6.5.1-1--6.5.2-1.filtered.debdiff

Attached is the diff. Changes are the upstream bugfix, as well as two commits
in the packaging repository:

https://salsa.debian.org/varnish-team/varnish/-/commit/b38fddf5fb3a7acf5c88d6a0f9906cb0967f16bb
 (lint: debian/*.install, paths should not begin with /)

https://salsa.debian.org/varnish-team/varnish/-/commit/46da54a751ae85afae8403fbf8ca360f322c349c
 (Declare compliance with Debian Policy 4.5.0)
diff -Nru varnish-6.5.1/Makefile.in varnish-6.5.2/Makefile.in
--- varnish-6.5.1/Makefile.in   2020-09-25 11:44:45.0 +0200
+++ varnish-6.5.2/Makefile.in   2021-07-02 13:57:15.0 +0200
@@ -207,7 +207,8 @@
$(top_srcdir)/build-aux/ltmain.sh \
$(top_srcdir)/build-aux/missing ChangeLog INSTALL \
build-aux/compile build-aux/config.guess build-aux/config.sub \
-   build-aux/install-sh build-aux/ltmain.sh build-aux/missing
+   build-aux/depcomp build-aux/install-sh build-aux/ltmain.sh \
+   build-aux/missing build-aux/ylwrap
 DISTFILES = $(DIST_COMMON) $(DIST_SOURCES) $(TEXINFOS) $(EXTRA_DIST)
 distdir = $(PACKAGE)-$(VERSION)
 top_distdir = $(distdir)
diff -Nru varnish-6.5.1/bin/varnishd/http2/cache_http2.h 
varnish-6.5.2/bin/varnishd/http2/cache_http2.h
--- varnish-6.5.1/bin/varnishd/http2/cache_http2.h  2020-09-25 
11:14:30.0 +0200
+++ varnish-6.5.2/bin/varnishd/http2/cache_http2.h  2021-07-02 
13:57:09.0 +0200
@@ -134,6 +134,8 @@
/* Where to wake this stream up */
struct worker   *wrk;
 
+   ssize_t reqbody_bytes;
+
VTAILQ_ENTRY(h2_req)tx_list;
h2_errorerror;
 };
diff -Nru varnish-6.5.1/bin/varnishd/http2/cache_http2_proto.c 
varnish-6.5.2/bin/varnishd/http2/cache_http2_proto.c
--- varnish-6.5.1/bin/varnishd/http2/cache_http2_proto.c2020-09-25 
11:14:30.0 +0200
+++ varnish-6.5.2/bin/varnishd/http2/cache_http2_proto.c2021-07-02 
13:57:09.0 +0200
@@ -554,6 +554,7 @@
 struct req *req, struct h2_req *r2)
 {
h2_error h2e;
+   ssize_t cl;
 
ASSERT_RXTHR(h2);
assert(r2->state == H2_S_OPEN);
@@ -574,16 +575,24 @@
// XXX: Have I mentioned H/2 Is hodge-podge ?
http_CollectHdrSep(req->http, H_Cookie, "; ");  // rfc7540,l,3114,3120
 
+   cl = http_GetContentLength(req->http);
+   assert(cl >= -2);
+   if (cl == -2) {
+   VSLb(h2->vsl, SLT_Debug, "Non-parseable Content-Length");
+   return (H2SE_PROTOCOL_ERROR);
+   }
+
if (req->req_body_status == NULL) {
-   if (!http_GetHdr(req->http, H_Content_Length, NULL))
+   if (cl == -1)
req->req_body_status = BS_EOF;
else
req->req_body_status = BS_LENGTH;
+   req->htc->content_length = cl;
} else {
/* A HEADER frame contained END_STREAM */
assert (req->req_body_status == BS_NONE);
r2->state = H2_S_CLOS_REM;
-   if (http_GetContentLength(req->http) > 0)
+   if (cl > 0)
return (H2CE_PROTOCOL_ERROR); //rfc7540,l,1838,1840
}
 
@@ -737,6 +746,7 @@
int w1 = 0, w2 = 0;
char buf[4];
unsigned wi;
+   ssize_t cl;
 
CHECK_OBJ_NOTNULL(wrk, WORKER_MAGIC);
ASSERT_RXTHR(h2);
@@ -755,6 +765,23 @@
Lck_Unlock(&h2->sess->mtx);
return (h2->error ? h2->error : r2->error);
}
+
+   r2->reqbody_bytes += h2->rxf_len;
+   if (h2->rxf_flags & H2FF_DATA_END_STREAM)
+   r2->state = H2_S_CLOS_REM;
+   cl = r2->req->htc->content_length;
+   if (cl >= 0 && (r2->reqbody_bytes > cl ||
+ (r2->state >= H2_S_CLOS_REM && r2->reqbody_bytes != cl))) {
+   VSLb(h2->vsl, SLT_Debug,
+   "H2: stream %u: Received data and Content-Length"
+   " mismatch", h2->rxf_stream);
+   r2->error = H2SE_PROTOCOL_ERROR; // rfc7540,l,3150,3163
+   if (r2->cond)
+   AZ(pthread_cond_signal(r2->cond));
+   Lck_Unlock(&h2->sess->mtx);
+   return (H2SE_PROTOCOL_ERROR);
+   }
+
AZ(h2->mailcall);
h2->mailcall = r2;
h2->req0->r_window -= h2->rxf_len;
@@ -773,6 +800,8 @@
r2->r_window += wi;
w2 = 1;
}
+
+

Bug#991268: [Aptitude-devel] Bug#991268: aptitude should provide an option to install packages from lower priority repos (backports, experimental) if the runtime dependency specify a version that can

[Julian Andres Klode]

On Mon, Jul 19, 2021 at 03:34:37PM +0530, Pirate Praveen wrote:
> Package: aptitude
> Severity: important
> Version: 0.8.13-3
> 
> aptitude already provide such an option for choosing build dependencies when
> building for backports or experimental, it would be great if there is an
> option for runtime dependencies as well.
> 
> Currently we have 3 options,
> 
> 1. aptitude -t buster-backports/experimental install foo - which will make
> priority of every package 500 and can create problems if conflicting newer
> versions are in buster-backports or experimental.
> 2. aptitude install foo bar/experimental - this works when we have small
> number of dependencies, but for packages with large number of dependencies
> this can be very inconvenient and hard.
> 
> For example, to install diaspora, I have to use
> 
> apt install diaspora ruby-marcel/bullseye-backports-staging
[...]

I'm a bit confused because this bug is about aptitude, and there, this
should work already. It might take a couple times of rejecting solver
choices, though. Did you want to report the bug against apt? I think
we already have a report for that, though.


-- 
debian developer - deb.li/jak | jak-linux.org - free software dev
ubuntu core developer  i speak de, en

Bug#991269: guymager: "AvoidEncaseProblems" is set to off in config file

[Zack Lau]

Package: guymager
Version: 0.8.12-1
Severity: important
Tags: patch
X-Debbugs-Cc: z...@zack.idv.hk

Dear Maintainer,

*** Reporter, please consider answering these questions, where appropriate ***

   * What led up to the situation?
I believe the root cause is the default config file "guymager.cfg" from the
offical repo does not have the option "AvoidEncaseProblems" enabled. The
majority of forensic images created using the latest Guymager with
"AvoidEncaseProblems" disabled causes error. Thus, cannot be be added to a case
in EnCase v8 or up.

   * What exactly did you do (or not do) that was effective (or
 ineffective)?
As I use Guymager from live CD, I have to change the "AvoidEncaseProblems"
option in line 426 of "/etc/guymager/guymager.cfg" from "off" to "on" everytime
I launch Guymager.

   * What was the outcome of this action?
After setting the "AvoidEncaseProblems" option to "on", forensic images created
by Guymager can be loaded in EnCase v8 or up with no issue.

   * What outcome did you expect instead?
I expect the "AvoidEncaseProblems" option can be set to "on" by default.
Suprisingly, this option is not known by a lot of people.

*** End of the template - remove these template lines ***


-- System Information:
Distributor ID: Kali
Description:Kali GNU/Linux Rolling
Release:2021.2
Codename:   kali-rolling
Architecture: x86_64

Kernel: Linux 5.10.0-kali7-amd64 (SMP w/2 CPU threads)
Kernel taint flags: TAINT_UNSIGNED_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not
set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages guymager depends on:
ii  hdparm  9.60+ds-1
ii  libc6   2.31-11
ii  libewf2 20140807-2+b2
ii  libgcc-s1   10.2.1-6
ii  libguytools22.1.0-1
ii  libparted2 [libparted]  3.4-1
ii  libqt5core5a5.15.2+dfsg-5
ii  libqt5dbus5 5.15.2+dfsg-5
ii  libqt5gui5  5.15.2+dfsg-5
ii  libqt5widgets5  5.15.2+dfsg-5
ii  libstdc++6  10.2.1-6
ii  smartmontools   7.2-1
ii  zlib1g  1:1.2.11.dfsg-2

Versions of packages guymager recommends:
ii  policykit-1  0.105-30+kali2

guymager suggests no packages.

Bug#991268: aptitude should provide an option to install packages from lower priority repos (backports, experimental) if the runtime dependency specify a version that can be satisfied only with these

[Pirate Praveen]

Package: aptitude
Severity: important
Version: 0.8.13-3

aptitude already provide such an option for choosing build dependencies 
when building for backports or experimental, it would be great if there 
is an option for runtime dependencies as well.


Currently we have 3 options,

1. aptitude -t buster-backports/experimental install foo - which will 
make priority of every package 500 and can create problems if 
conflicting newer versions are in buster-backports or experimental.
2. aptitude install foo bar/experimental - this works when we have 
small number of dependencies, but for packages with large number of 
dependencies this can be very inconvenient and hard.


For example, to install diaspora, I have to use

apt install diaspora ruby-marcel/bullseye-backports-staging 
ruby-autoprefixer-rails/bullseye-backports-staging \
ruby-responders/bullseye-backports-staging 
unicorn/bullseye-backports-staging \

ruby-unicorn-worker-killer/bullseye-backports-staging \
ruby-devise-two-factor/bullseye-backports-staging 
ruby-sidekiq/bullseye-backports-staging \
ruby-configurate/bullseye-backports-staging 
ruby-nokogiri/bullseye-backports-staging \
ruby-open-graph-reader/bullseye-backports-staging 
ruby-secure-headers/bullseye-backports-staging \
ruby-hamlit/bullseye-backports-staging 
ruby-rotp/bullseye-backports-staging \
ruby-zip/bullseye-backports-staging 
diaspora-common/bullseye-backports-staging \
ruby-toml-rb/bullseye-backports-staging 
ruby-rails/bullseye-backports-staging \
ruby-railties/bullseye-backports-staging 
ruby-actioncable/bullseye-backports-staging \
ruby-actioncable/bullseye-backports-staging 
ruby-actionmailer/bullseye-backports-staging \
ruby-actionpack/bullseye-backports-staging 
ruby-actiontext/bullseye-backports-staging \
ruby-actionview/bullseye-backports-staging 
ruby-activejob/bullseye-backports-staging \
ruby-activemodel/bullseye-backports-staging 
ruby-activerecord/bullseye-backports-staging \
ruby-activestorage/bullseye-backports-staging 
ruby-activesupport/bullseye-backports-staging \

ruby-actionmailbox/bullseye-backports-staging

buster-backports-staging is unofficially suite as bullseye-backports is 
not officially opened yet.


3. Use apt pinning, I currently use this for gitlab, 
https://salsa.debian.org/fasttrack-team/gitlab-apt-pin-preferences/-/blob/bullseye-fasttrack/99gitlab


but installing pin preferences is considered a lintian error.

So please provide an option that will choose packages with a lower 
priority if the runtime dependency has a requirement that can be 
satisfied with a lower priority packages.

Bug#991133: parallel building is the problem

[Matthew Vernon]

tags 991133 +pending -help
quit

Hi,

Right, the issue is that the Makefile isn't parallel-build safe (see 
e.g. the re-entrant calls of Make for building the concordance); 
Helmut's cross-building patch replaced $(MAKE) all (not parallel) with 
some dh_auto_build calls (parallel), and that's where this woe has come 
from.


I've tested a fix that adds --no-parallel to the two dh_auto_build calls 
to disable parallel building again, and that is building correctly.


I'll get an upload to unstable done shortly, and then file the unblock 
request.


Regards,

Matthew

Bug#991267: pg_config.h leaks internal macros

[Max Kellermann]

Package: libpq-dev
Version: 14~beta2-1

pg_config.h is a public header and needed if an application wants to
check the version number at compile time.  However, in version 14, it
leaks a lot of internal PostgreSQL macros, e.g. OPENSSL_API_COMPAT
which breaks applications using OpenSSL directly:

 /usr/include/postgresql/pg_config.h:791:9: error: 'OPENSSL_API_COMPAT' macro 
redefined [-Werror,-Wmacro-redefined]
 #define OPENSSL_API_COMPAT 0x10001000L
 ^
 :10:9: note: previous definition is here
 #define OPENSSL_API_COMPAT 0x1010L
 ^

Bug#991133: dh_strip seems to be to blame

[Matthew Vernon]

On 19/07/2021 09:56, Matthew Vernon wrote:

Hi,

More on this; a nostrip build works. If I take the unstripped executible 
and strip it as I did in 4.31 (install -s), then the resulting stripped 
executible also works.


So dh_strip (version in bullseye) is stripping too much out of the 
executible and that's breaking the search. dh_strip in stretch does not 
have this problem.


It's not this simple, alas - taking an unstripped bible executible and 
then applying all the strip options doesn't cause problems.


https://buildd.debian.org/status/fetch.php?pkg=bible-kjv&arch=amd64&ver=4.32&stamp=1613928140&raw=0

look at where the concordance is examined:
Concordance data file:
  Version:  02
  Name: KJV Concordance
  Contents: 0 words
  Word list at file offset 100
  Index at file offset 101
  Data at file offset 103

with a nostrip build:
Concordance data file:
  Version:  02
  Name: KJV Concordance
  Contents: 12544 words
  Word list at file offset 100
  Index at file offset 101823
  Data at file offset 126913

Also a parallel=1 build works, which might be the issue?

More work needed here.

Matthew

Bug#989010: linux-image-5.10.0-7-amd64: No display (post, grub, boot messages and desktop) after the upgrade to 5.10.38

[jim_p]

Source: linux
Followup-For: Bug #989010
X-Debbugs-Cc: pitsior...@gmail.com

One thing I noticed this weekend.
Time it took for 5.10.38/40 to reach testing from unstable: 7 days, despite
this awful bug here.
Time it took for 5.10.46 to reach testing from unstable: 20+ days and still
counting.

Please do not mention freeze as an excuse. Debian has been in hard freeze since
March, so I doubt that some "full freeze policy" has to do anything with it.
Imho, one more release critical bug like this one would delay the release of
bullseye even more, so you just marked it as important and let it be until it
is "magically" solved one day.
"Quality" testing...

In other news, I asked an experienced linux user to have a look at my logs and
he said there is nothing unusual. He also asked if there is a copy of
/var/log/kern.log from those problematic boots, but unfortunately there is none
right now. If I knew, I would have kept a copy.
Once again, a random user offered me more support that the debian kernel
team... on an issue that has to do with the kernel which is built from that
team.

Bug#991133: bible-kjv: Search no longer works after upgrading to Bullseye

[Matthew Vernon]

severity 991133 important
tags 991133 +help
quit


bible(KJV) [Gen1:1]> ??hath
   Searching for 'hath'... not found.


Huh. Thanks for reporting this.

If I build 4.32 on my (old-)stable system, this works.

Similarly, if I build 4.30 on my bullseye system, this works.

4.31 building on bullseye also works.

So 4.31 works everywhere, but 4.32 works on stretch, but not on 
bullseye. I can't test 4.32-build-on-stretch on bullseye because of the 
readline version change.


But the changes between 4.31 and 4.32 were only some debian/rules 
changes to support cross-building...


I will have to look at this further, since I am currently rather confused!

Regards,

Matthew

Bug#991133: dh_strip seems to be to blame

[Matthew Vernon]

Hi,

More on this; a nostrip build works. If I take the unstripped executible 
and strip it as I did in 4.31 (install -s), then the resulting stripped 
executible also works.


So dh_strip (version in bullseye) is stripping too much out of the 
executible and that's breaking the search. dh_strip in stretch does not 
have this problem.


Regards,

Matthew

Bug#991259: b4: fails with dns.exception.Timeout

[Uwe Kleine-König]

Hello,

On 7/18/21 10:38 PM, Uwe Kleine-König wrote:

I wiresharked the DNS traffic and found out that my provider's DNS
server doesn't reply "big" queries without edns:

$ dig +noedns fm3._domainkey.messagingengine.com TXT
;; Truncated, retrying in TCP mode.
;; communications error to 192.168.80.1#53: end of file


; <<>> DiG 9.16.15-Debian <<>> +noedns 
fm3._domainkey.messagingengine.com TXT
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 21882
;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0
;; WARNING: recursion requested but not available

;; QUESTION SECTION:
;fm3._domainkey.messagingengine.com. IN TXT

;; Query time: 7 msec
;; SERVER: fdb0:5279:7365:8000::1#53(fdb0:5279:7365:8000::1)
;; WHEN: Sun Jul 18 22:17:15 CEST 2021
;; MSG SIZE  rcvd: 52

If I query one of the public DNS servers (like 1.1.1.1 or 8.8.8.8), or
if I use an edns query (i.e. drop +noedns) or if I query one of the ipv6
servers of my provider I get a proper answer.

If I understood correctly using edns is the only way to properly get
replies bigger than 512 bytes, so it doesn't seem unreasonable to use
edns for TXT records?!


quick followup: I learned in the meantime that my provider's server 
doesn't answer TCP requests at all and that this is a violation of a 
MUST in the relevant RFC[1].


Still it would be a nice improvement for b4 to use edns as it saves the 
roundtrip through TCP.


I'll try to bug my provider now to repair its DNS server.

Best regards
Uwe

[1] https://www.rfc-editor.org/rfc/rfc7766.html#section-5



OpenPGP_signature
Description: OpenPGP digital signature