Bug#1004005: openmm: reproducible-builds: BuildId differences triggered by RPATH

[Vagrant Cascadian]

Source: openmm
Severity: normal
Tags: patch
User: reproducible-bui...@lists.alioth.debian.org
Usertags: buildpath
X-Debbugs-Cc: reproducible-b...@lists.alioth.debian.org

The RPATH contains the build path resulting in different buildid:

  https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/openmm.html

The attached patch to debian/rules passes
-DCMAKE_BUILD_RPATH_USE_ORIGIN=ON via a dh_auto_configure override,
which should use a relative path for RPATH.

Alternately, updating the packaging to debhelper compat level 14 should
fix this, although it is currently an experimental compat level.

With this patch applied, openmm *should* build reproducibly on
tests.reproducible-builds.org for the version currently in unstable,
although the version in experimental seems to embed the build path in
additional and/or non-deterministic ways.


Thanks for maintaining openmm!

live well,
  vagrant
From 62bcd0ccc41cdfe087c2aefcceaf55863172127d Mon Sep 17 00:00:00 2001
From: Vagrant Cascadian 
Date: Wed, 19 Jan 2022 05:05:47 +
Subject: [PATCH] debian/rules: Pass -DCMAKE_BUILD_RPATH_USE_ORIGIN=ON via
 dh_auto_configure override.

This avoids embedding the full path in RPATH, which triggers BuildId
differences.

https://tests.reproducible-builds.org/debian/issues/unstable/cmake_rpath_contains_build_path_issue.html
---
 debian/rules | 1 +
 1 file changed, 1 insertion(+)

diff --git a/debian/rules b/debian/rules
index 4c281f4..20f599f 100755
--- a/debian/rules
+++ b/debian/rules
@@ -13,6 +13,7 @@ CMAKE_FLAGS = \
 -DCMAKE_C_FLAGS_RELEASE="$(CFLAGS)" \
 -DCMAKE_CXX_FLAGS_RELEASE="$(CXXFLAGS)" \
 -DCMAKE_SHARED_LINKER_FLAGS_RELEASE="$(LDFLAGS)" \
+-DCMAKE_BUILD_RPATH_USE_ORIGIN=ON \
 -DCMAKE_BUILD_TYPE=Release  \
 $(CMAKE_ARCH_FLAGS) \
 -DOPENMM_BUILD_AMOEBA_PLUGIN=ON \
-- 
2.34.1



signature.asc
Description: PGP signature

Bug#1004006: ITP: xrt -- Xilinx Runtime library

[Nobuhiro Iwamatsu]

Package: wnpp
Severity: wishlist
Owner: Nobuhiro Iwamatsu 
X-Debbugs-Cc: debian-de...@lists.debian.org

* Package name: xrt
  Version : 2.8.832
  Upstream Author : Sonal Santan 
* URL : https://github.com/Xilinx/XRT.git
* License : GPL-2.0
  Programming Lang: C++
  Description : Xilinx Runtime library

  Xilinx Runtime library (XRT) is an open-source easy to
  use software stack that facilitates management and usage of
  field-programmable gate array (FPGA) / Adaptive Compute Acceleration
  Platform (ACAP) devices. Users use familiar programming languages
  like C/C++ or Python to write host code which uses XRT to interact
  with FPGA/ACAP device. XRT exports well defined set of software APIs
  that work across PCIe based datacenter platforms and ZYNQ UltraScale+
  MPSoC/Versal ACAP based embedded platforms. XRT is a combination of
  userspace and kernel driver components.

Bug#1004007: freecad: Segfaults on armhf when clicking "Ceate New..." or File -> New

[Serge Schneider]

Package: freecad
Version: 0.19.1+dfsg1-2
Severity: important
X-Debbugs-Cc: se...@raspberrypi.com

Dear Maintainer,

When running FreeCAD, creating a new file crashes with a segfault:

connect failed: No such file or directory
Program received signal SIGSEGV, Segmentation fault.
#0  /lib/arm-linux-gnueabihf/libc.so.6(+0x2acb0) [0xb4aaacb0]
FreeCAD 0.19, Libs: 0.19R
© Juergen Riegel, Werner Mayer, Yorik van Havre and others 2001-2021
FreeCAD is free and open-source software licensed under the terms of LGPL2+ 
license.
FreeCAD wouldn't be possible without FreeCAD community.
  #   ###     
  ##  # #   #   # 
  # ##     # #   #  #   # 
    # # #  # #  #  # #  #   # 
  # #      ## # #   # 
  # #   ## ## # #   #  ##  ##  ##
  # #       ### # #    ##  ##  ##


This is the same issue as #931458, which was closed because it was reported 
against Raspbian's packages.
However, the issue is reproducible in Debian too (using 
20210823_raspi_2_bullseye.img.xz).

The crash seems to have something to do with how Ccoin3D creates the context in 
Qt.

Rebuilding FreeCAD against Qt4 rather than Qt5 makes it work. It also works on 
arm64.

The main difference I can see is that Qt is built with OpenGL support on arm64, 
but only OpenGL ES support on armhf.

The issue has also been reported upstream at 
https://tracker.freecadweb.org/view.php?id=4083, but there hasn't been any 
progess in a few years.

-- System Information:
Debian Release: 11.0
  APT prefers stable-security
  APT policy: (500, 'stable-security'), (500, 'stable')
Architecture: armhf (armv7l)

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

Versions of packages freecad depends on:
ii  freecad-python3  0.19.1+dfsg1-2

Versions of packages freecad recommends:
ii  calculix-ccx  2.17-3
ii  graphviz  2.42.2-5

Versions of packages freecad suggests:
pn  povray  

-- no debconf information

Bug#1002188: re: resvg: FTBFS: unsatisfiable build-dependencies

[Andrej Shadura]

Hi,

On Wed, 29 Dec 2021 05:24:03 + peter green  wrote:

The parts of the rust gtk stack used by resvg are now installable again after 
having been broken for some time,
so I decided to take a look and see if I could get

The first thing I did was change the dependency on pico-args to 0.4 so that I 
could attempt a build.

I then discovered that the dependenices in Cargo.toml were often more 
restrictive than those in the
Debian package, I relaxed these.

Unfortunately I then discovered that the API of the cairo crate seems to have 
changed quite substantially,
I started trying to port it but quickly reached the point where I was not 
confident either that
my changes would work correctly or that patching was the right approach.

When I look at resvg upstream, the cairo code seems to have disappeared from 
the repository.

Work in progress debdiff attatched, do with it as you see fit.


Thanks Peter. I have some work in progress packaging of a newer upstream 
version, but it’s been stuck for some time for lack of time and build 
dependencies.


--
Cheers,
  Andrej

Bug#1002681: transition: ocaml

[Sebastian Ramacher]

Control: tags -1 confirmed

On 2022-01-11 11:17:25 +0100, Sebastian Ramacher wrote:
> Control: block -1 by 976811
> 
> On 2022-01-10 07:57:21 +0100, Stéphane Glondu wrote:
> > Control: tags -1 - moreinfo
> > 
> > Le 09/01/2022 à 17:49, Sebastian Ramacher a écrit :
> > > Please remove the moreinfo tag once ocaml-odoc-parser has been accepted.
> > 
> > It has been yesterday.
> > 
> > I think this transition is ready to be started.
> 
> This transition collides with the ongoing php8.1 transition (libguestfs,
> #1002986). So let's wait until that is complete.

The libguestfs build for the php8.1 transition migrated, so this
transition can proceed. Please go ahead.

Cheers
-- 
Sebastian Ramacher


signature.asc
Description: PGP signature

Bug#1004005: [Debichem-devel] Bug#1004005: openmm: reproducible-builds: BuildId differences triggered by RPATH

[Andrius Merkys]

Hi,

On 2022-01-19 10:02, Vagrant Cascadian wrote:
> The attached patch to debian/rules passes
> -DCMAKE_BUILD_RPATH_USE_ORIGIN=ON via a dh_auto_configure override,
> which should use a relative path for RPATH.

Thanks a lot for the patch!

> Alternately, updating the packaging to debhelper compat level 14 should
> fix this, although it is currently an experimental compat level.
> 
> With this patch applied, openmm *should* build reproducibly on
> tests.reproducible-builds.org for the version currently in unstable,
> although the version in experimental seems to embed the build path in
> additional and/or non-deterministic ways.

Maybe a possible long-term solution would be to use chrpath to set the
RPATH to point to the absolute location of private libraries, like
/usr/lib/${DEB_HOST_MULTIARCH}/openmm ?

Best,
Andrius

Bug#1004008: black: Out of sync manpage for black (py36 option)

[Mathieu Malaterre]

Package: black
Version: 20.8b1-4
Severity: minor

Dear Maintainer,

It would be nice of the man page of black was kept in sync with the
actual code.

Eg.:

% man black | grep py36
  --py36  Allow using Python 3.6-only syntax on 
all

while:

% black -h | grep py36
  -t, --target-version [py27|py33|py34|py35|py36|py37|py38]

Thanks

-- System Information:
Debian Release: 11.2
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 
'stable-debug'), (500, 'proposed-updates-debug'), (500, 'stable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.14.0-0.bpo.2-amd64 (SMP w/8 CPU threads)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, 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 /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages black depends on:
ii  python33.9.2-3
ii  python3-appdirs1.4.4-1
ii  python3-click  7.1.2-1
ii  python3-mypy-extensions0.4.3-2
ii  python3-pathspec   0.8.1-1
ii  python3-pkg-resources  52.0.0-4
ii  python3-regex  0.1.20201113-1
ii  python3-toml   0.10.1-1
ii  python3-typed-ast  1.4.2-1
ii  python3-typing-extensions  3.7.4.3-1

black recommends no packages.

Versions of packages black suggests:
pn  python-black-doc  

-- no debconf information

Bug#1003890: ceph-mgr won't start when backported to Bullseye

[Thomas Goirand]

On 1/19/22 02:49, Norbert Veber wrote:
Thanks for checking!  I was using the official Ceph packages from 
stable, and have a cluster with a Ceph filesystem (data and metadata 
pool), 3 mon and mgr nodes.  Manual install.. nothing too crazy.


I compiled the sources, and installed manually with 'dpkg -i'. 
Everything restarted fine except the ceph-mgr.


# ceph status
   cluster:
     id: c792f202-9f83-4f7c-ae08-243ef1afe1d8
     health: HEALTH_WARN
     no active mgr

   services:
     mon: 3 daemons, quorum pyre,llama,epsilon (age 34h)
     mgr: no daemons active (since 10h)
     mds: cephfs-ssd:1 {0=llama=up:active} 2 up:standby
     osd: 4 osds: 4 up (since 34h), 4 in (since 3d)

   data:
     pools:   2 pools, 64 pgs
     objects: 50.27k objects, 54 GiB
     usage:   118 GiB used, 8.1 TiB / 8.2 TiB avail
     pgs: 64 active+clean

Only changed a few config options:

pyre:~# ceph config dump
WHO    MASK LEVEL    OPTION    VALUE RO
global  advanced osd_pool_default_size 2
   mon   advanced auth_allow_insecure_global_id_reclaim false
   mgr   advanced mgr/dashboard/server_port 8083 *
   mgr   advanced mgr/dashboard/ssl false *
   osd   advanced bdev_async_discard true
   osd   advanced bdev_enable_discard true

Sounds like if all else fails I could blow away this cluster and make a 
new one with the new version from scratch.  Mostly wanted to upgrade so 
I could have multiple filesystems (SSD and HDD).


I kind of want to make sure there's an upgrade path, so this is 
important to address. I'll try myself soonish, maybe after Ceph Pacific 
got accepted in bullseye-backports.


Cheers,

Thomas Goirand (zigo)

Bug#1004009: haskell-cmark-gfm: diff for version 0.2.1+ds1-2

[Jonas Smedegaard]

Package: haskell-cmark-gfm
Version: 0.2.1+ds1-1
Severity: normal
Tags: patch  pending

Hi Haskell team,

I've released haskell-cmark-gfm 0.2.1+ds1-2.

Below is a diff of the changes made - I have not dared edit the git repo
so hope someone else will take care of that.

Regards,

 - Jonas

diff -Nru haskell-cmark-gfm-0.2.1+ds1/debian/changelog 
haskell-cmark-gfm-0.2.1+ds1/debian/changelog
--- haskell-cmark-gfm-0.2.1+ds1/debian/changelog2020-09-04 
09:45:40.0 +0200
+++ haskell-cmark-gfm-0.2.1+ds1/debian/changelog2022-01-19 
10:06:14.0 +0100
@@ -1,3 +1,13 @@
+haskell-cmark-gfm (0.2.1+ds1-2) unstable; urgency=medium
+
+  * team upload
+
+  * simple rebuild to link against current libcmark
+(see bug#1003964)
+
+
+ -- Jonas Smedegaard   Wed, 19 Jan 2022 10:06:14 +0100
+
 haskell-cmark-gfm (0.2.1+ds1-1) unstable; urgency=medium
 
   * Remove embedded copy of cmark-gfm library, use libcmark-gfm-dev instead

Bug#976811: [pkg-php-pear] Bug#976811: transition: php8.1

[Bryce Harrington]

On Sun, Jan 16, 2022 at 09:49:37PM -0800, Kunal Mehta wrote:
> 
> Hi,
> 
> On 1/16/22 11:52, Paul Gevers wrote:
> > On 12-01-2022 21:16, Paul Gevers wrote:
> > > Priority may lay with the mediawiki* regression on i386: "Internal
> > > Server Error" doesn't sound great, and other non-horde package.
> > 
> > Did anybody already take a look at this [1, 2, 3]? It's the last thing
> > before I'll add a hint to ignore the autopkgtest regressions.
> > Intermittent "Internal Server Error" sounds more like something in
> > php8.1 than in mediawiki* hence my reluctance to let php-defaults
> > migrate. What do you think?
> 
> Sorry, didn't get a chance to look at this until now. All 3 failures are
> most likely the same underlying cause. As for whether this is a MediaWiki or
> PHP 8.1 issue, I'm not sure. Upstream in MW we don't run any 32-bit CI, so
> it's entirely possible some 8.0 or 8.1 change broke something we were doing.
> 
> I don't have any i386 hardware, I tried pulling down a i386 Debian unstable
> Docker container on my amd64 laptop and installing the mediawiki+php8.1
> packages on that but it didn't trigger the test failure. Do you have any
> other suggestions/tips on how I could debug this?
> 
> As an alternative I just committed [4] which would hopefully dump the
> underlying error message upon failure. Please let me know if it's OK for me
> to upload that without it being disruptive.
> 
> > [1] https://ci.debian.net/packages/m/mediawiki-skin-greystuff/testing/i386/
> > [2]
> > https://ci.debian.net/packages/m/mediawiki-extension-youtube/testing/i386/
> > [3] https://ci.debian.net/packages/m/mediawiki/testing/i386/
> 
> [4] 
> https://salsa.debian.org/mediawiki-team/mediawiki/-/commit/20a94e6971be6b06d5f41338ec2811cc8572e05f

With [4] applied, I'm seeing the following dumped on armhf:

## https://autopkgtest.ubuntu.com/packages/m/mediawiki/jammy/armhf
cat: /var/log/mediawiki/error.log: No such file or directory
2022-01-19 09:16:57 autopkgtest-lxd-eeoxik autopkgtestwiki: 
[e33d1ec89af515673078437e] /mediawiki/index.php/Main_Page   PHP Fatal Error 
from line 110 of /usr/share/mediawiki/includes/json/FormatJson.php: Maximum 
execution time of 30 seconds exceeded
#0 [internal function]: MWExceptionHandler::handleFatalError()
#1 {main}
2022-01-19 09:17:27 autopkgtest-lxd-eeoxik autopkgtestwiki: 
[1284cbae5a84eb5387f33003] /mediawiki/index.php/Main_Page   PHP Fatal Error 
from line 152 of /usr/share/mediawiki/includes/HookContainer/HookContainer.php: 
Maximum execution time of 30 seconds exceeded
#0 [internal function]: MWExceptionHandler::handleFatalError()
#1 {main}
2022-01-19 09:17:57 autopkgtest-lxd-eeoxik autopkgtestwiki: 
[31731278ed6070e946af4fbe] /mediawiki/index.php/Main_Page   PHP Fatal Error 
from line 110 of /usr/share/mediawiki/includes/json/FormatJson.php: Maximum 
execution time of 30 seconds exceeded
#0 [internal function]: MWExceptionHandler::handleFatalError()
#1 {main}
cat: /var/log/mediawiki/fatal.log: No such file or directory

HTH,
Bryce

Bug#1003964: pandoc doesn't start: error while loading shared libraries: libcmark-gfm.so.0.29.0.gfm.0

[Sebastian Ramacher]

On 2022-01-18 19:30:39 +0100, Jonas Smedegaard wrote:
> Control: clone -1 -2
> Control: reassign -1 src:cmark-gfm 0.29.0.gfm.2-1
> Control: retitle -1 cmark-gfm: shlibs too relaxed for unstable ABI
> Control: affects -1 pandoc blogliterately gitit pandoc-citeproc patat
> Control: reassign -2 src:cmark 0.30.2-3
> Control: severity -2 important
> Control: retitle -2 cmark: shlibs too relaxed for unstable ABI
> 
> Quoting Jonas Smedegaard (2022-01-18 18:40:33)
> > Quoting gregor herrmann (2022-01-18 18:08:02)
> > > While looking at some test issues in libpod-pandoc-perl, I noticed
> > > that pandoc looks quite broken in current amd64/sid:
> > > 
> > > % pandoc --version
> > > pandoc: error while loading shared libraries: 
> > > libcmark-gfm.so.0.29.0.gfm.0: cannot open shared object file: No such 
> > > file or directory
> > [...]
> > > So it looks like pandoc wants libcmark-gfm.so.0.29.0.gfm.0 but 
> > > libcmark-gfm0 ships libcmark-gfm.so.0.29.0.gfm.2. Maybe this is an 
> > > issue in libcmark-gfm0 … Not sure where to fix this.
> > 
> > libcmark-gfm offers an unstable API, so I guess pandoc packaging is to 
> > blame for having too loose dependency on that inherently untameable 
> > library package.
> > 
> > Thanks for reporting, Gregor - might be enough to request a binNMU but 
> > I'd better tighten that dependency, so will do a regular upload.
> 
> Hmm - thinking on it, it seems to me that the change really should be in 
> the libcmark-gfm package - something like this (untested):
> 
> override_dh_makeshlibs:
>   dh_makeshlibs --version-info="libcmark-gfm0 (>= ${DEB_VERSION}), 
> libcmark-gfm0 (<< ${DEB_VERSION}+)"

No, please review Section 8 of the policy.

The SONAME is:

$ objdump -x libcmark-gfm.so.0.29.0.gfm.2 | grep SONAME
  SONAME   libcmark-gfm.so.0.29.0.gfm.2

So the package needs to be named libcmark-gfm0.29.0.gfm.2.

Cheers

> 
> Similar is required for the package cmark.
> 
> 
>  - Jonas
> 
> -- 
>  * Jonas Smedegaard - idealist & Internet-arkitekt
>  * Tlf.: +45 40843136  Website: http://dr.jones.dk/
> 
>  [x] quote me freely  [ ] ask before reusing  [ ] keep private



-- 
Sebastian Ramacher


signature.asc
Description: PGP signature

Bug#956183: transition: libwmf

[Yangfl]

Paul Gevers  于2022年1月19日周三 03:48写道：
>
> Control: tags -1 moreinfo
>
> Hi Yangfl,
>
> On Thu, 27 Aug 2020 01:35:40 +0100 Simon McVittie  wrote:
> > On Thu, 27 Aug 2020 at 01:01:39 +0100, Simon McVittie wrote:
> > > If the new library is genuinely
> > > compatible with the old library, then I think a better way to do this
> > > would be to introduce an empty, transitional package with the old name
> > > libwmf0.2-7.
> >
> > This, for example:
> > https://salsa.debian.org/yangfl-guest/libwmf/-/merge_requests/1
>
> This got merged long time ago, is this transition still needed? I see
> that there is still an autotracker, but I'm not sure if it's for the
> things related in this bug.
>
> Paul

After checking I found libwmf0.2-7-gtk left without transitional,
maybe I should add it back then someone can close this bug without
performing transition.

Bug#1004011: postfix: updated German message catalogue

[Markus Hiereth]

Package: postfix
Version: 3.6.3-6
Severity: normal

Dear Scott,

attached to this report, there is the updated German po-file.

Please pay attention the sugguestions made as FIXME within.

Best regards
Markus
# Translation of postfix debconf templates to German
# This file is distributed under the same license as the postfix package.
# Copyright (C) Helge Kreutzmann , 2006-2008, 2012, 2014, 
2016.
# Markus Hiereth , 2016, 2018, 2022.
msgid ""
msgstr ""
"Project-Id-Version: postfix 3.6.3-6\n"
"Report-Msgid-Bugs-To: post...@packages.debian.org\n"
"POT-Creation-Date: 2021-12-28 14:12-0500\n"
"PO-Revision-Date: 2022-01-20 14:40+0100\n"
"Last-Translator: Markus Hiereth \n"
"Language-Team: debian-l10n-german \n"
"Language: de\n"
"MIME-Version: 1.0\n"
"Content-Type: text/plain; charset=UTF-8\n"
"Content-Transfer-Encoding: 8bit\n"
"Plural-Forms: nplurals=2; plural=(n != 1);\n"
"X-Generator: Virtaal 0.7.1\n"

#FIXME Please consider replacement of "delimiter" (which appears four
#times) by "placeholder" if this meets better the effect of the
#character defined in this configuration step. mh, 2022-01-20

#. Type: boolean
#. Description
#: ../templates:1001
msgid "Update configuration to avoid compatibility warnings?"
msgstr ""
"Um Warnungen zu Inkompatibiltäten zu vermeiden, die Konfiguration "
"aktualisieren?"

#. Type: boolean
#. Description
#: ../templates:1001
msgid ""
"This upgrade of Postfix changes some default values in the configuration. As "
"part of this upgrade, the following will be changed: (1) chrooted components "
"will be changed from '-' to 'y' in master.cf, and (2) myhostname will be set "
"to a fully-qualified domain name if it is not already such. The install will "
"be aborted if you do not allow the change."
msgstr ""
"Diese Aktualisierung von Postfix ändert einige Standardwerte der "
"Konfiguration. Dazu gehört: (1) in master.cf wird bei chrooted-Komponenten "
"der Wert '-' durch 'y' ersetzt. (2) »myhostname« wird, falls die Variable "
"noch nicht die Anforderungen an einen voll-qualifizierten Domainnamen (FQDN) "
"erfüllt, in eine solche überführt. Sollten Sie diese Änderungen nicht "
"zulassen, wird die Installation abgebrochen."

#. Type: boolean
#. Description
#: ../templates:2001
msgid "Update main.cf for daemon_directory change?"
msgstr "main.cf für eine Änderung von »daemon_directory« aktualisieren?"

#. Type: boolean
#. Description
#: ../templates:2001
msgid ""
"This upgrade of Postfix changes where daemons are located, and your Postfix "
"configuration explicitly specifies the old location. The install will be "
"aborted if you do not allow the change."
msgstr ""
"Dieses Upgrade von Postfix ändert den Ort von Hintergrundprozessen, Ihre "
"Postfix-Konfiguration spezifiziert allerdings ausdrücklich den alten Ort. "
"Sollten Sie diese Änderungen nicht zulassen, wird die Installation "
"abgebrochen."

#. Type: boolean
#. Description
#: ../templates:3001
msgid "Update dynamicmaps.cf for 3.0?"
msgstr "dynamicmaps.cf für 3.0 aktualisieren?"

#. Type: boolean
#. Description
#: ../templates:3001
msgid ""
"Postfix version 3.0 changes how dynamic maps are delivered, and your "
"dynamicmaps.cf does not reflect that. Accept this option to convert "
"dynamicmaps.cf to the version required for 3.0."
msgstr ""
"Mit Postfix Version 3.0 ändert sich, wie dynamische Zuordnungen "
"bereitgestellt werden, Ihre dynamicmaps.cf widerspiegelt dies jedoch nicht. "
"Akzeptieren Sie diese Option, um dynamicmaps.cf in die für 3.0 benötigte "
"Version zu konvertieren."

#. Type: boolean
#. Description
#: ../templates:4001
msgid "Ignore incorrect hostname entry?"
msgstr "Fehlerhaften Hostnamen-Eintrag ignorieren?"

#. Type: boolean
#. Description
#: ../templates:4001
msgid ""
"The string '${enteredstring}' does not follow RFC 1035 and does not appear "
"to be a valid IP address."
msgstr ""
"Die Zeichenkette »${enteredstring}« entspricht nicht RFC 1035 und scheint "
"keine gültige IP-Adresse zu sein."

#. Type: boolean
#. Description
#: ../templates:4001
msgid ""
"RFC 1035 states that 'each component must start with an alphanum, end with "
"an alphanum and contain only alphanums and hyphens. Components must be "
"separated by full stops.'"
msgstr ""
"RFC 1035 fordert, dass »jede Komponente mit einem alphanumerischen Zeichen "
"beginnen und enden muss und ansonsten auch nur aus alphanumerischen Zeichen "
"und Bindestrichen bestehen darf. Alle Komponenten müssen jeweils durch einen "
"Punkt getrennt werden«."

#. Type: boolean
#. Description
#: ../templates:4001
msgid "Please check and confirm if you want to keep your entry."
msgstr ""
"Bitte kontrollieren und bestätigen Sie, falls Sie Ihren Eintrag beibehalten 
möchten."

#. Type: select
#. Choices
#. Translators beware! the following six strings form a single
#. Choices menu. - Every one of these strings has to fit in a standard
#. 80 characters console, as the fancy screen setup takes up some space
#. try to keep below ~71 characters.
#. DO NOT USE commas (,) in Cho

Bug#1003907: fails to successfully associate

[Michael Biebl]

Am 18.01.22 um 21:56 schrieb Andrej Shadura:

Hi Michael,

On Tue, 18 Jan 2022, at 21:52, Michael Biebl wrote:

Am 18.01.22 um 21:47 schrieb Masashi Honma:

The log indicates that the Wi-Fi access point rejected the association
request from the Wi-Fi station with status
code=WLAN_STATUS_INVALID_IE.

We can't read from this log why the Wi-Fi access point rejected the
assocication request.
If I have that Wi-Fi access point on hand, I can bisect this issue.
What is the Wi-Fi access point you are using?



It's a FRITZ!Box 7490 (a very common Wi-Fi Router in Germany) running
Firmware version 07.39.
WPA-Mode is set to WPA2+WPA3


Just a random thought: could you please try those two versions formerly from 
experimental:
  * 2:2.9.0+git20200517+dd2daf0-1
  * 2:2.9.0+git20210909+a75fdcd-1

I have re-enabled some options (WNM, MBO, FILS and mesh networking) in the 
latter, I wonder if that could have some effect.




I tried the various versions from snapshots.d.o

2:2.9.0-23 - works
2:2.9.0+git20200221+f65da0c-1 - works
2:2.9.0+git20200517+dd2daf0-1 - doesn't work
2:2.9.0+git20210909+a75fdcd-1 - doesn't work
2:2.9.0+git20211018+2e122945fa53-1 - doesn't work
2:2.9.0+git2026+0b853303ae31-1 - doesn't work
2:2.10-1 - doesn't work


I then went on and disabled WPA2+WPA3 mode on the Wi-Fi router and set 
it to WPA2 (CCMP).


After that, the connection was established successfully with 2.10.

If I remember correctly, my hardware doesn't support WPA3, but since I 
enabled support for both WPA2+WPA3, it should fall back to WPA2.


Obviously I'd like to keep WPA3 enabled for newer clients.

Regards,
Michael





OpenPGP_signature
Description: OpenPGP digital signature

Bug#1002418: [Pkg-privacy-maintainers] Bug#1002418: marked as done (mat2: FTBFS: AssertionError: 'TransparentColor' not found in {})

[Georg Faerber]

Hi Utkarsh,

Thanks for your upload.

Could you please push the changes you did to the git repo?

Thanks,
cheers,
Georg

Bug#1004012: tor: AppArmor policy needs update for recent obfs4proxy

[intrigeri]

Package: tor
Version: 0.4.7.3-alpha-1
Severity: minor
Tags: patch

Hi,

obfs4proxy more recent than the one in Debian, such as 0.0.11, needs
read access to /sys/kernel/mm/transparent_hugepage/hpage_pmd_size.
The attached patch grants such access.

Thanks in advance!

>From e5711ee98c5115cc24fe61b7346de92473b65199 Mon Sep 17 00:00:00 2001
From: intrigeri 
Date: Wed, 19 Jan 2022 10:28:03 +
Subject: [PATCH] AppArmor: allow access to
 /sys/kernel/mm/transparent_hugepage/hpage_pmd_size

obfs4proxy 0.0.11 needs this.
---
 debian/tor.apparmor-profile.abstraction | 1 +
 1 file changed, 1 insertion(+)

diff --git a/debian/tor.apparmor-profile.abstraction b/debian/tor.apparmor-profile.abstraction
index f2fe3c4e46..8271db63df 100644
--- a/debian/tor.apparmor-profile.abstraction
+++ b/debian/tor.apparmor-profile.abstraction
@@ -19,6 +19,7 @@
 
   # Needed by obfs4proxy
   /proc/sys/net/core/somaxconn r,
+  /sys/kernel/mm/transparent_hugepage/hpage_pmd_size r,
 
   /proc/sys/kernel/random/uuid r,
   /sys/devices/system/cpu/ r,
-- 
2.34.1

Bug#965900: xfsdump: diff for NMU version 3.1.9+0+nmu2

[Adrian Bunk]

Control: tags 965900 + patch
Control: tags 965900 + pending

Dear maintainer,

I've prepared an NMU for xfsdump (versioned as 3.1.9+0+nmu2) and
uploaded it to DELAYED/7. Please feel free to tell me if I
should cancel it.

cu
Adrian
diff -Nru xfsdump-3.1.9+0+nmu1/debian/changelog xfsdump-3.1.9+0+nmu2/debian/changelog
--- xfsdump-3.1.9+0+nmu1/debian/changelog	2021-12-16 10:44:12.0 +0200
+++ xfsdump-3.1.9+0+nmu2/debian/changelog	2022-01-19 12:22:32.0 +0200
@@ -1,3 +1,10 @@
+xfsdump (3.1.9+0+nmu2) unstable; urgency=low
+
+  * Non-maintainer upload.
+  * debian/compat: 5 -> 7. (Closes: #965900)
+
+ -- Adrian Bunk   Wed, 19 Jan 2022 12:22:32 +0200
+
 xfsdump (3.1.9+0+nmu1) unstable; urgency=medium
 
   * Non-maintainer upload.
diff -Nru xfsdump-3.1.9+0+nmu1/debian/compat xfsdump-3.1.9+0+nmu2/debian/compat
--- xfsdump-3.1.9+0+nmu1/debian/compat	2020-01-31 19:30:58.0 +0200
+++ xfsdump-3.1.9+0+nmu2/debian/compat	2022-01-19 12:22:27.0 +0200
@@ -1 +1 @@
-5
+7

Bug#965458: chntpw: diff for NMU version 1.0-1.2

[Adrian Bunk]

Control: tags 965458 + patch
Control: tags 965458 + pending

Dear maintainer,

I've prepared an NMU for chntpw (versioned as 1.0-1.2) and uploaded
it to DELAYED/7. Please feel free to tell me if I should cancel it.

cu
Adrian
diff -u chntpw-1.0/debian/changelog chntpw-1.0/debian/changelog
--- chntpw-1.0/debian/changelog
+++ chntpw-1.0/debian/changelog
@@ -1,3 +1,10 @@
+chntpw (1.0-1.2) unstable; urgency=low
+
+  * Non-maintainer upload.
+  * debian/compat: 5 -> 7. (Closes: #965458)
+
+ -- Adrian Bunk   Wed, 19 Jan 2022 12:46:45 +0200
+
 chntpw (1.0-1.1) unstable; urgency=low
 
   * Non-maintainer upload.
diff -u chntpw-1.0/debian/compat chntpw-1.0/debian/compat
--- chntpw-1.0/debian/compat
+++ chntpw-1.0/debian/compat
@@ -1 +1 @@
-5
+7

Bug#965917: yorick-z: diff for NMU version 1.2.0+cvs20080115-5.1

[Adrian Bunk]

Control: tags 965917 + patch
Control: tags 965917 + pending

Dear maintainer,

I've prepared an NMU for yorick-z (versioned as 1.2.0+cvs20080115-5.1) 
and uploaded it to DELAYED/7. Please feel free to tell me if I should 
cancel it.

cu
Adrian
diff -Nru yorick-z-1.2.0+cvs20080115/debian/changelog yorick-z-1.2.0+cvs20080115/debian/changelog
--- yorick-z-1.2.0+cvs20080115/debian/changelog	2012-06-28 14:30:43.0 +0300
+++ yorick-z-1.2.0+cvs20080115/debian/changelog	2022-01-19 12:59:55.0 +0200
@@ -1,3 +1,10 @@
+yorick-z (1.2.0+cvs20080115-5.1) unstable; urgency=low
+
+  * Non-maintainer upload.
+  * debian/compat: 5 -> 7. (Closes: #965917)
+
+ -- Adrian Bunk   Wed, 19 Jan 2022 12:59:55 +0200
+
 yorick-z (1.2.0+cvs20080115-5) unstable; urgency=low
 
   * Comply with Debian Science Policy
diff -Nru yorick-z-1.2.0+cvs20080115/debian/compat yorick-z-1.2.0+cvs20080115/debian/compat
--- yorick-z-1.2.0+cvs20080115/debian/compat	2012-06-28 12:51:22.0 +0300
+++ yorick-z-1.2.0+cvs20080115/debian/compat	2022-01-19 12:59:55.0 +0200
@@ -1 +1 @@
-5
+7

Bug#965916: yorick-cubeview: diff for NMU version 2.2-2.2

[Adrian Bunk]

Control: tags 965916 + patch
Control: tags 965916 + pending

Dear maintainer,

I've prepared an NMU for yorick-cubeview (versioned as 2.2-2.2) and 
uploaded it to DELAYED/7. Please feel free to tell me if I should
cancel it.

cu
Adrian
diff -Nru yorick-cubeview-2.2/debian/changelog yorick-cubeview-2.2/debian/changelog
--- yorick-cubeview-2.2/debian/changelog	2021-01-03 13:25:53.0 +0200
+++ yorick-cubeview-2.2/debian/changelog	2022-01-19 13:03:55.0 +0200
@@ -1,3 +1,10 @@
+yorick-cubeview (2.2-2.2) unstable; urgency=low
+
+  * Non-maintainer upload.
+  * debian/compat: 5 -> 7. (Closes: #965916)
+
+ -- Adrian Bunk   Wed, 19 Jan 2022 13:03:55 +0200
+
 yorick-cubeview (2.2-2.1) unstable; urgency=medium
 
   * Non maintainer upload by the Reproducible Builds team.
diff -Nru yorick-cubeview-2.2/debian/compat yorick-cubeview-2.2/debian/compat
--- yorick-cubeview-2.2/debian/compat	2013-07-28 15:48:29.0 +0300
+++ yorick-cubeview-2.2/debian/compat	2022-01-19 13:03:55.0 +0200
@@ -1 +1 @@
-5
+7

Bug#1003977: cwltool: privacy leak with option --print-doc

[Michael R. Crusoe]

Control: forwarded -1 
https://github.com/common-workflow-language/schema_salad/issues/510


On Tue, 18 Jan 2022 21:48:01 +0100 Jonas Smedegaard  wrote:

> Package: cwltool
> Version: 3.1.20211104071347-3
> Severity: important
>

Web pages produced with `cwltool --print-doc` contains links to only
resources, revealing when users render the document in a regular web
browser - or fails to produce intended layout if rendering while offline.



I think you mean `schema-salad-tool --print-doc`, yes? Agreed, this is 
not great.


I opened an issue about this upstream (where I am also the maintainer). 
A pull request to fix this would be very welcome!




For inspiration, the tool pandoc by default (as packaged in Debian,
upstream defaults differ) links against local system-shared resources,
with an option for each resource to instead link to an online instance
of the user's own choice.

Jonas


--
Michael R. Crusoe



OpenPGP_signature
Description: OpenPGP digital signature

Bug#55364: Schließen Sie sich den Illuminaten an.

[The Illuminati]

Grüße vom Welteliteimperium der Illuminaten. Bringen Sie die Armen, Bedürftigen 
und Talentierten ins Rampenlicht von Ruhm, Reichtum, Macht und Sicherheit, 
werden Sie in Ihrem Geschäft, Ihrer politischen Rasse anerkannt, steigen Sie an 
die Spitze in allem, was Sie tun, und seien Sie geistig und körperlich 
geschützt! All dies werden Sie im Handumdrehen erreichen, wenn Sie in das große 
Reich der Illuminaten eingeweiht werden. Sobald Sie in das Illuminati-Imperium 
eingeweiht sind, erhalten Sie zahlreiche Vorteile und Belohnungen.
Hinweis: Diese E-Mail-Nachricht wurde ausschließlich zum Zwecke unseres 
Rekrutierungsprogramms erstellt, das nächsten Monat endet, und dieses Angebot 
gilt nur für einzigartige Personen. Wenn Sie es nicht ernst meinen, dem 
Illuminati-Imperium beizutreten, raten wir Ihnen, uns nicht unter zu 
kontaktieren alle. Dies liegt daran, dass Untreue hier in unserer Organisation 
absolut nicht toleriert wird.
Bist du damit einverstanden, ein Mitglied der neuen Weltordnung der Illuminaten 
zu sein? Falls ja!. Dann antworten Sie uns bitte nur auf unsere direkte 
Rekrutierungs-E-Mail unter: joinillumina...@outlook.com 
Bitte beachten Sie: Stellen Sie bitte sicher, dass alle Ihre Antworten direkt 
an die oben angegebene E-Mail-Adresse gesendet werden, nur unter:> 
joinillumina...@outlook.com 
Weitere Anweisungen zu unserem Mitgliedschaftsprozess.
Hinweis: Einige E-Mail-Anbieter platzieren offizielle Illuminati-Nachrichten 
fälschlicherweise in ihrem Spam-/Junk-Ordner oder Werbeordner. Dies kann unsere 
Antworten auf Ihre E-Mails umleiten und ausschließen.
Die Illuminati.

Bug#37592: Schließen Sie sich den Illuminaten an.

[The Illuminati]

Grüße vom Welteliteimperium der Illuminaten. Bringen Sie die Armen, Bedürftigen 
und Talentierten ins Rampenlicht von Ruhm, Reichtum, Macht und Sicherheit, 
werden Sie in Ihrem Geschäft, Ihrer politischen Rasse anerkannt, steigen Sie an 
die Spitze in allem, was Sie tun, und seien Sie geistig und körperlich 
geschützt! All dies werden Sie im Handumdrehen erreichen, wenn Sie in das große 
Reich der Illuminaten eingeweiht werden. Sobald Sie in das Illuminati-Imperium 
eingeweiht sind, erhalten Sie zahlreiche Vorteile und Belohnungen.
Hinweis: Diese E-Mail-Nachricht wurde ausschließlich zum Zwecke unseres 
Rekrutierungsprogramms erstellt, das nächsten Monat endet, und dieses Angebot 
gilt nur für einzigartige Personen. Wenn Sie es nicht ernst meinen, dem 
Illuminati-Imperium beizutreten, raten wir Ihnen, uns nicht unter zu 
kontaktieren alle. Dies liegt daran, dass Untreue hier in unserer Organisation 
absolut nicht toleriert wird.
Bist du damit einverstanden, ein Mitglied der neuen Weltordnung der Illuminaten 
zu sein? Falls ja!. Dann antworten Sie uns bitte nur auf unsere direkte 
Rekrutierungs-E-Mail unter: joinillumina...@outlook.com 
Bitte beachten Sie: Stellen Sie bitte sicher, dass alle Ihre Antworten direkt 
an die oben angegebene E-Mail-Adresse gesendet werden, nur unter:> 
joinillumina...@outlook.com 
Weitere Anweisungen zu unserem Mitgliedschaftsprozess.
Hinweis: Einige E-Mail-Anbieter platzieren offizielle Illuminati-Nachrichten 
fälschlicherweise in ihrem Spam-/Junk-Ordner oder Werbeordner. Dies kann unsere 
Antworten auf Ihre E-Mails umleiten und ausschließen.
Die Illuminati.

Bug#1004013: python3-typedload-doc: missing Breaks+Replaces: python3-typedload (<< 2.15)

[Andreas Beckmann]

Package: python3-typedload-doc
Version: 2.15-2
Severity: serious
User: debian...@lists.debian.org
Usertags: piuparts

Hi,

during a test with piuparts I noticed your package fails to upgrade from
'testing'.
It installed fine in 'testing', then the upgrade to 'sid' fails
because it tries to overwrite other packages files without declaring a
Breaks+Replaces relation.

See policy 7.6 at
https://www.debian.org/doc/debian-policy/ch-relationships.html#overwriting-files-and-replacing-packages-replaces

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

  Preparing to unpack .../python3-typedload-doc_2.15-2_all.deb ...
  Unpacking python3-typedload-doc (2.15-2) ...
  dpkg: error processing archive 
/var/cache/apt/archives/python3-typedload-doc_2.15-2_all.deb (--unpack):
   trying to overwrite '/usr/share/doc/python3-typedload/docs/CHANGELOG.md.gz', 
which is also in package python3-typedload 2.14-2
  Errors were encountered while processing:
   /var/cache/apt/archives/python3-typedload-doc_2.15-2_all.deb

The exisiting
  Breaks+Replaces: python3-typedload (<< 2.5)
are insufficiently versioned.


cheers,

Andreas


python3-typedload=2.14-2_python3-typedload-doc=2.15-2.log.gz
Description: application/gzip

Bug#1004014: open-iscsi: Duplicate dh_installsystemd section in d/rules

[Dave Jones]

Source: open-iscsi
Version: 2.1.5-1
Severity: important

Dear Maintainer,

In commit 693da74e, it appears lintian-brush changed both the 
override_dh_systemd_enable and override_dh_systemd_start sections in 
d/rules to override_dh_installsystemd with the result that there are now 
two override_dh_installsystemd rules in the makefile. The first is 
presumably ignored with the result that the postinst/prerm sections for 
the iscsid.service unit are omitted.

Best regards,

Dave Jones.

Bug#1004015: kallisto FTBFS on i386/armel/armhf/mipsel

[Andrius Merkys]

Source: kallisto
Version: 0.48.0+dfsg-1
Severity: important
Tags: ftbfs
Control: forwarded -1 https://github.com/pachterlab/kallisto/issues/338

Hello,

kallisto throws segmentation faults in tests on 32bit architectures:

/bin/bash ./func_tests/runtests.sh
[INDEX]
./src/kallisto index -i ./func_tests/basic7.idx -k 7
./func_tests/simple.fasta
./func_tests/runtests.sh: line 13: 12638 Segmentation fault
./src/kallisto index -i ./func_tests/basic7.idx -k 7
./func_tests/simple.fasta 2> /dev/null > /dev/null
^[Failed]

Not sure if this used to happen before, as these particular tests did
not exist before. I have forwarded the issue upstream [1].

[1] https://github.com/pachterlab/kallisto/issues/338

Andrius

Bug#1002675: re hubic/pyrax problem

[Fabrice Lamareille]

Dear all,

I'll be more than happy to solve this bug by myself, provided that I 
knew how to get the relevant informations, i.e. the file and the line 
number where the error comes from.


Unfortunately, the duplicity -v9 command does not give me what I am 
expecting (see output below).


What am I doing wrong ?

Thanks in advance for your help.

Output of duplicity -v9:

GPG binary is gpg, version (2, 2, 27)
Import of duplicity.backends.adbackend Succeeded
Import of duplicity.backends.azurebackend Succeeded
Import of duplicity.backends.b2backend Succeeded
Import of duplicity.backends.boxbackend Succeeded
Import of duplicity.backends.cfbackend Succeeded
Import of duplicity.backends.dpbxbackend Succeeded
Import of duplicity.backends.gdocsbackend Succeeded
Import of duplicity.backends.gdrivebackend Succeeded
Import of duplicity.backends.giobackend Succeeded
Import of duplicity.backends.hsibackend Succeeded
Import of duplicity.backends.hubicbackend Succeeded
Import of duplicity.backends.idrivedbackend Succeeded
Import of duplicity.backends.imapbackend Succeeded
Import of duplicity.backends.jottacloudbackend Succeeded
Import of duplicity.backends.lftpbackend Succeeded
Import of duplicity.backends.localbackend Succeeded
Import of duplicity.backends.mediafirebackend Succeeded
Import of duplicity.backends.megabackend Succeeded
Import of duplicity.backends.megav2backend Succeeded
Import of duplicity.backends.megav3backend Succeeded
Import of duplicity.backends.multibackend Succeeded
Import of duplicity.backends.ncftpbackend Succeeded
Import of duplicity.backends.onedrivebackend Succeeded
Import of duplicity.backends.par2backend Succeeded
Import of duplicity.backends.pcabackend Succeeded
Import of duplicity.backends.pydrivebackend Succeeded
Import of duplicity.backends.rclonebackend Succeeded
Import of duplicity.backends.rsyncbackend Succeeded
Import of duplicity.backends.s3_boto3_backend Succeeded
Import of duplicity.backends.s3_boto_backend Succeeded
Import of duplicity.backends.ssh_paramiko_backend Succeeded
Import of duplicity.backends.ssh_pexpect_backend Succeeded
Import of duplicity.backends.swiftbackend Succeeded
Import of duplicity.backends.sxbackend Succeeded
Import of duplicity.backends.tahoebackend Succeeded
Import of duplicity.backends.webdavbackend Succeeded
Connection failed, please check your credentials: TypeError a bytes-like
object is required, not 'str'

Le 30/12/2021 à 06:10, Alexander Zangerl a écrit :

fabrice, upstream has reported that the problem you're encountering
is pretty much certainly not coming from duplicity but pyrax - which is
deprecated and no longer being maintained.

upstream requests the log of a duplicity run with full -v9 logging/debugging
on in order to track this down any further. if you can provide such a log
the chances of getting this sorted out will rise a bit.

regards
az

Bug#885140: [pkg-wicd-maint] Bug#885140: wicd: Depends on unmaintained pygtk

[Vincent Lefevre]

On 2022-01-19 05:43:15 +0100, Sebastian Rasmussen wrote:
> Sadly it appears no one has stepped up to do the porting in the four years
> since 2017. As a user of wicd-curses, can I humbly suggest that Debian
> disables wicd-gtk for the time being so that Debian/testing mapped to
> bookworm can continue using wicd?
> 
> I'm slightly worried by this comment though:
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=885140#77

There are also other issues.

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

is rather annoying for networks with several access points.

> If wicd-curses is kicked out of Debian entirely, what is the suggested
> alternative for scanning, connecting to and disconnecting from Wi-Fi
> in a terminal?

Due to the various wicd issues, I've switched to nmcli, e.g.

  nmcli device wifi rescan
  nmcli device wifi list
  nmcli device wifi connect ...
  nmcli device disconnect ...

There are completions for bash and zsh.

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

Bug#1003983: opendkim cannot initialize resolver in dkim_dns_init() (libunbound, libnettle, ...?)

[David Bürgin]

Robert Siemer:
> Opendkim does not run.
> 
> # opendkim -f
> [1642532480] libunbound[837:0] error: nettle random(yarrow) cannot 
> initialize, getentropy failed: Function not implemented
> opendkim: can't configure DKIM library: failed to initialize resolver
> 
> I even recompiled from source deb, both opendkim and libunbound. 
> An ltrace showed that dkim_dns_init() fails with -1, and that 
> one calls ub_ctx_create() which returns 0 but provokes the 
> first line to be printed. The second line is the reason printed 
> when dkim_dns_init() fails.

opendkim uses libunbound by default. The error is from libunbound,
perhaps try building opendkim without libunbound and see what happens?

https://salsa.debian.org/debian/opendkim/-/blob/debian/2.11.0_beta2-6/debian/rules#L10-14

Bug#1002863: (no subject)

[Ayoyimika Ajibade]

After updating node-react-audio-player to build with webpack5.65.0
repo here https://salsa.debian.org/Ayoyimika/node-react-audio-player,
the undefined module ./src/index.tsx is actually present in the package

this is the new error log

   debian/rules override_dh_auto_build
make[1]: Entering directory 
'/home/ayoyimika/debian-js-packaging/react-audio-player/node-react-audio-player'

webpack
assets by status 0 bytes [cached] 1 asset

ERROR in main
Module not found: Error: Recursion in resolving
Stack:
  undefined: 
(/home/ayoyimika/debian-js-packaging/react-audio-player/node-react-audio-player) 
./src/index.tsx


webpack 5.65.0 compiled with 1 error in 514 ms
make[1]: *** [debian/rules:11: override_dh_auto_build] Error 1
make[1]: Leaving directory 
'/home/ayoyimika/debian-js-packaging/react-audio-player/node-react-audio-player'

make: *** [debian/rules:8: binary] Error 2
dpkg-buildpackage: error: debian/rules binary subprocess returned exit 
status 2


OpenPGP_0x1FF1115A4CAC464D.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1004016: pipewire 0.3.43 upgrade automatically selects broken profile

[Alexander Clausen]

Package: pipewire
Version: 0.3.43-2
Severity: normal

Dear Maintainer,

After upgrading pipewire (and related pipewire-pulse packages etc.) from
0.3.42-1 to 0.3.43-2, my audio input from my webcam was suddenly not working
anymore (as in: WebRTC-based applications were complaining about not
being able to use microphone input). In `pavucontrol`, under "Input Devices",
it was impossible to set the device as the default input - it always switched 
back to
"monitor of built-in audio analog stereo" or something like that. After
some trial and error, I found out about the "Pro Audio" profile, and it
turns out, this profile was somehow selected (without user interaction).
Switching my webcam back to "Mono Input" made it possible to use again,
as in before versions.

Reading the pipewire FAQ, it seems the "Pro Audio" profile is not really
meant to be used for devices like webcams:

https://gitlab.freedesktop.org/pipewire/pipewire/-/wikis/FAQ#what-is-the-pro-audio-profile

Would it be possible to not switch to it automatically, or only switch
to it for devices that are actually compatible with this profile?

Thanks,
Alexander

-- System Information:
Debian Release: bookworm/sid
  APT prefers unstable-debug
  APT policy: (500, 'unstable-debug'), (500, 'unstable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.15.0-2-amd64 (SMP w/12 CPU threads)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, 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: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages pipewire depends on:
ii  init-system-helpers  1.61
ii  libpipewire-0.3-modules  0.3.43-2
ii  pipewire-bin 0.3.43-2

pipewire recommends no packages.

pipewire suggests no packages.

-- no debconf information

Bug#1003864: libreoffice-help-it: Libreoffice help depends from Firefox-esr package

[Antonio]

As already mentioned, I use a version of Firefox downloaded from 
www.mozilla.org and at the moment I can't replace it with the one 
available in the repositories because if I do it then it doesn't read 
the user profile and I have to reconfigure everything, which I don't 
want to do.


I would like to install LibreOffice Help to use it offline but if I do 
it then forced me to install Firefox-ESR, which for me would be a 
duplicate I don't need.


It would be interesting if the package manager could install Firefox-ESR 
only if it don't finds other browsers available in the system (in my 
case: /etc/alternatives/x-www-browser -> /opt/firefox/firefox).



Il 17/01/22 20:30, Rene Engelhard ha scritto:

severity 1003864 wishlist

retitle 1003864 please don' t depend on browsers

thanks


Am 17.01.22 um 08:57 schrieb Antonio:

Severity: normal


Why? It's doing that it is intended to do.



If I try to install the LibreOffice help, the Firefox-esr package is
automatically installed.



That is not new. That is there since ~ 3.5 years...

Just because it is the first alternative. As the reportbug info you 
posted said itself:


pn  firefox-esr | epiphany-browser | konqueror | chromium | fire 

firefox-esr OR epiphany-browser OR konqueror OR chromium OR firefox

(thought that list probably should be reordered?)


Why is this? Becuase the help DOES need a X  (well, 
JavaScript-capable, and the nongui browsers can't) browser. Without 
that there would be an error (or even worse: nothing happen) when 
opening the help.



One might argue it can be a Recommends: (then only people who don't 
install recommends per default don't get it, but)



Regards,


Rene

Bug#1004017: qemu-system-x86_64: assertion failure in parsing code of SLIC ACPI table

[Wouter Verhelst]

Package: qemu-system-x86
Version: 1:6.2+dfsg-1
Severity: important
Justification: qemu always crashes at startup in one (fairly common) use case
Forwarded: https://gitlab.com/qemu-project/qemu/-/issues/786

When called with the necessary parameters to loop through the Windows
license key that is embedded in my laptop (through libvirt), qemu fails
with an assertion:

internal error: qemu unexpectedly closed the monitor: qxl_send_events: 
spice-server bug: guest stopped, ignoring
**
ERROR:../../hw/acpi/aml-build.c:61:build_append_padded_str: assertion failed: 
(len <= maxlen)
Bail out! ERROR:../../hw/acpi/aml-build.c:61:build_append_padded_str: assertion 
failed: (len <= maxlen)

Traceback (most recent call last):
  File "/usr/share/virt-manager/virtManager/asyncjob.py", line 65, in cb_wrapper
callback(asyncjob, *args, **kwargs)
  File "/usr/share/virt-manager/virtManager/asyncjob.py", line 101, in tmpcb
callback(*args, **kwargs)
  File "/usr/share/virt-manager/virtManager/object/libvirtobject.py", line 57, 
in newfn
ret = fn(self, *args, **kwargs)
  File "/usr/share/virt-manager/virtManager/object/domain.py", line 1329, in 
startup
self._backend.create()
  File "/usr/lib/python3/dist-packages/libvirt.py", line 1353, in create
raise libvirtError('virDomainCreate() failed')
libvirt.libvirtError: internal error: qemu unexpectedly closed the monitor: 
qxl_send_events: spice-server bug: guest stopped, ignoring
**
ERROR:../../hw/acpi/aml-build.c:61:build_append_padded_str: assertion failed: 
(len <= maxlen)
Bail out! ERROR:../../hw/acpi/aml-build.c:61:build_append_padded_str: assertion 
failed: (len <= maxlen)

Resulting in a failure to start the Windows VM.

This is tracked upstream at
https://gitlab.com/qemu-project/qemu/-/issues/786, and a patch is
already available; please consider including it in the Debian package.

-- System Information:
Debian Release: bookworm/sid
  APT prefers testing
  APT policy: (990, 'testing'), (500, 'testing-debug'), (500, 
'stable-security'), (500, 'stable-debug'), (500, 'unstable'), (500, 'stable'), 
(500, 'oldstable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386, riscv64, armhf

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

Versions of packages qemu-system-x86 depends on:
ii  ipxe-qemu 1.0.0+git-20190125.36a4c85-5.1
ii  libaio1   0.3.112-13
ii  libc6 2.33-2
ii  libcapstone4  4.0.2-5
ii  libfdt1   1.6.1-1
ii  libfuse3-33.10.5-1
ii  libgcc-s1 11.2.0-13
ii  libglib2.0-0  2.70.2-1
ii  libgnutls30   3.7.2-5
ii  libibverbs1   38.0-1
ii  libjpeg62-turbo   1:2.1.2-1
ii  libnettle83.7.3-1
ii  libnuma1  2.0.14-3
ii  libpixman-1-0 0.40.0-1
ii  libpmem1  1.11.1-3
ii  libpng16-16   1.6.37-3
ii  librdmacm138.0-1
ii  libsasl2-22.1.27+dfsg2-3
ii  libseccomp2   2.5.3-2
ii  libslirp0 4.6.1-1
ii  libudev1  250.2-3
ii  liburing2 2.1-2
ii  libvdeplug2   4.0.1-3
ii  libxendevicemodel14.14.3+32-g9de3671772-1
ii  libxenevtchn1 4.14.3+32-g9de3671772-1
ii  libxenforeignmemory1  4.14.3+32-g9de3671772-1
ii  libxengnttab1 4.14.3+32-g9de3671772-1
ii  libxenmisc4.144.14.3+32-g9de3671772-1
ii  libxenstore3.04.14.3+32-g9de3671772-1
ii  libxentoolcore1   4.14.3+32-g9de3671772-1
ii  libzstd1  1.4.8+dfsg-3
ii  qemu-system-common1:6.2+dfsg-1
ii  qemu-system-data  1:6.2+dfsg-1
ii  seabios   1.15.0-1
ii  zlib1g1:1.2.11.dfsg-2

Versions of packages qemu-system-x86 recommends:
ii  ovmf  2021.11-1
ii  qemu-block-extra  1:6.2+dfsg-1
ii  qemu-system-gui   1:6.2+dfsg-1
ii  qemu-utils1:6.2+dfsg-1

Versions of packages qemu-system-x86 suggests:
pn  samba  
pn  vde2   

-- no debconf information

Bug#1004018: Is smb-nat still useful?

[Adrian Bunk]

Package: smb-nat
Version: 1:1.0-6
Severity: serious
Tags: bookworm sid

Does smb-nat provide any functionality that is not also provided
by Samba tools (that were originally written by the same author)?

Bug#1004019: Should forensics-extra drop the dependendency on smb-nat?

[Adrian Bunk]

Package: forensics-extra
Version: 2.34
Severity: serious
Control: block 1004018 by -1

Does the 25 year old smb-nat provide any functionality that is
not also provided by Samba tools (that were originally written
by the same author)?

Bug#1003968: [Pkg-electronics-devel] Bug#1003968: Bug#1003968: fpga-icestorm: icetime looking in wrong directory for chipdb files

[Daniel Gröber]

Hi Steffen,

Thanks for the quick upload.

It looks like something went wrong when you built the source package
though. The arch:all build is still failing for -2 and the source package
is missing the `[ ! -d debian/fpga-icestorm ]` guard statement I introduced
in debian/rules. Like it's in the repo on salsa but not your upload.

Thanks,
--Daniel


signature.asc
Description: PGP signature

Bug#1003969: sudo: FQDN option not overridable early on.

[Sven Mueller]

Tags 1003969 + fixed-upstream patch confirmed
Thanks

https://www.sudo.ws/repos/sudo/rev/8c6eaa503793 has the upstream patch.

Bug#1004003: Acknowledgement (chromium: After upgrade to latest version, chromium cannot open anymore.)

[johnw]

Duplicated with https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1003689 .

On 1/19/22 15:33, Debian Bug Tracking System wrote:

Thank you for filing a new Bug report with Debian.

You can follow progress on this Bug here: 1004003: 
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1004003.

This is an automatically generated reply to let you know your message
has been received.

Your message is being forwarded to the package maintainers and other
interested parties for their attention; they will reply in due course.

As you requested using X-Debbugs-CC, your message was also forwarded to
   johnw.m...@gmail.com
(after having been given a Bug report number, if it did not have one).

Your message has been sent to the package maintainer(s):
  Debian Chromium Team 

If you wish to submit further information on this problem, please
send it to 1004...@bugs.debian.org.

Please do not send mail to ow...@bugs.debian.org unless you wish
to report a problem with the Bug-tracking system.




--
Key fingerprint: CDB3 6C62 254B C088 1E5D DD32 182C 97DB CF2C 80AC

Bug#1004017: qemu-system-x86_64: assertion failure in parsing code of SLIC ACPI table

[Michael Tokarev]

19.01.2022 14:40, Wouter Verhelst wrote:

Package: qemu-system-x86
Version: 1:6.2+dfsg-1
Severity: important
Justification: qemu always crashes at startup in one (fairly common) use case
Forwarded: https://gitlab.com/qemu-project/qemu/-/issues/786

...

This is tracked upstream at
https://gitlab.com/qemu-project/qemu/-/issues/786, and a patch is
already available; please consider including it in the Debian package.


Yeah, I already pulled that one earlier today from qemu-stable@. Thanks!

/mjt

Bug#1003962: Fails with --buildsystem=cmake if builddirectory contains package version with ~ tilde

[Gregor Riepl]

> I suspect the error is in /usr/share/dh-python/dhpython/build/plugin_cmake.py:
> 
> return ('dh_auto_build --buildsystem=cmake'
> ' --builddirectory="{build_dir}"'
> 
> If I replace "{build_dir}" by {build_dir} in that file, the build
> succeeds.

Is that safe?
What if the build_dir contains spaces or shell characters?

Perhaps the command should be single quoted instead, or the resulting
strings should be escaped.

Bug#1002988: Too early to fix

[Julien Puydt]

Hi,

upstream didn't release a new version with support for camlp5 8.* ; but
they have a patch here:
https://github.com/LPCIC/elpi/pull/110/commits/f58341831b56ccfe5f2f49158c600e4e36bcb9b5

so I should be able to fix the problem as soon as it actually occurs.

Cheers,

J.Puydt

Bug#1004020: ITP: golang-golang.zx2c4-go118-netip -- netip from Go 1.18 for use in Go 1.17

[John Goerzen]

Package: wnpp
Severity: wishlist
Owner: John Goerzen 

* Package name: golang-golang.zx2c4-go118-netip
  Version : 0.0~git2021.a4a02ee-1
  Upstream Author : The Go Authors
* URL : TODO
* License : BSD 3-clause
  Programming Lang: Go
  Description : An extraction of netip from Go 1.18 for use in Go 1.17

Required by wireguard-go

Bug#1003948: bullseye-pu: package systemd/247.3-7

[Cyril Brulebois]

Hallo Michael,

Michael Biebl  (2022-01-18):
> What follows is an annotated list of changes. A full debdiff is also
> attached for your convenience.
> 
> As usual, I CCed debian-boot i.e. kibi for his ack regarding d-i.

Thanks as usual!

>   * udevadm-trigger: do not return immediately on EACCES.
> Fixes a regression when using systemd-networkd in an unprivileged LXD
> container. (Closes: #997006)
> 
> https://salsa.debian.org/biebl/systemd/-/commit/6c4f3c69d753edc8ca963c9f6f86f76bd30275c6
> 
> Straightforward cherry-pick from upstream. Confirmed by the bug submitter
> that it fixes the issue in #997006
> 
> Touches udev code but I don't expect any effect on d-i.

I don't think we do too many unprivileged things in d-i, yeah…

FWIW, a quick grep in our packages suggests we have mainly this user:
  
https://salsa.debian.org/installer-team/debian-installer-utils/-/blob/master/update-dev

which happily starts with set +e…

>   * Demote systemd-timesyncd from Depends to Recommends.
> This avoids a dependency cycle between systemd and systemd-timesyncd and
> thus makes dist upgrades more predictable and robust.
> It also allows minimal, systemd based containers where no NTP client is
> strictly necessary.
> To ensure that systemd-timesyncd is installed in a default installation
> created by d-i, bump its priority to standard.
> (Closes: #986651, #993947)
> 
> This one is probably the trickiest (and possibly also the simplest)
> change. It simply breaks a dependency loop between systemd and
> systemd-timesyncd resulting in a more predictable upgrade sequence
> which in turn ensures that modifications of systemd-timesyncd's
> conffiles are preserved on upgrades.
> 
> As systemd is installed during the initial bootstrap phase, where
> Recommends are not considered, we would end up with no
> systemd-timesycnd being installed on fresh installations.
> To avoid that, we'd like to bump the priority of systemd-timesyncd to
> standard in stable (so it is installed via the standard task).

Just as a data point:

I suppose it was a good idea for us (maintainers of the Raspberry Pi
images) to start pulling systemd-timesyncd for all suites then…
  
https://salsa.debian.org/raspi-team/image-specs/-/commit/96ac1dcec76e9af65150c4c2c2e5c88a3191504b

While your proposed approach should be sufficient for a lot of use
cases, people building their own images might get a different set of
packages before/after the point release (depending on the tool they
use). I'd probably have looped in the cloud team for such a change, but
ISTR having read recently they install chrony anyway.

I have no strong opinions either way (the fix is trivial, but the change
could be seen as surprising), that seems tricky to me too.


Anyway, no objections for d-i at first glance.


Cheers,
-- 
Cyril Brulebois (k...@debian.org)
D-I release manager -- Release team member -- Freelance Consultant


signature.asc
Description: PGP signature

Bug#1004021: ITP: wireguard-go -- Implementation of WireGuard in Go

[John Goerzen]

Package: wnpp
Severity: wishlist
Owner: John Goerzen 

* Package name: wireguard-go
  Version : 0.0.20220117-1
  Upstream Author : Jason A. Donenfeld 
* URL : https://git.zx2c4.com/wireguard-go/about/
* License : MIT
  Programming Lang: Go
  Description : Implementation of WireGuard in Go
 This is a userspace implementation of WireGuard in Go.
 .
 It also provides a library that is used by other programs
 for working with the kernel tun interface and related tasks.

This is a dependency of Yggdrasil, which uses it for its tun
support.  NNCP also requires Yggdrasil now.

Bug#1004022: clasp: Clasp FTBFS with glibc 2.34

[Lukas Märdian]

Package: clasp
Version: 3.3.5-4
Severity: normal
Tags: patch
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu jammy ubuntu-patch
X-Debbugs-Cc: sl...@ubuntu.com

Dear Maintainer,

Once glibc will be upgraded to 2.34+ clasp will FTBFS.

In Ubuntu, the attached patch was applied to fix this issue:

  * d/p/use-system-catch-for-glibc-2.34-compat.patch: Fix FTBFS with glibc-2.34
- Add catch v1 build-dependency
- Make use of system provided catch v1 (CTest) library


Thanks for considering the patch.

Cheers,
  Lukas


-- System Information:
Debian Release: 11.0
  APT prefers impish-updates
  APT policy: (500, 'impish-updates'), (500, 'impish-security'), (500, 
'impish'), (100, 'impish-backports')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.13.0-23-generic (SMP w/4 CPU threads)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_WARN, TAINT_OOT_MODULE
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), 
LANGUAGE=de_DE:en_GB:en
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
diff -Nru clasp-3.3.5/debian/control clasp-3.3.5/debian/control
--- clasp-3.3.5/debian/control  2020-12-26 22:25:24.0 +0100
+++ clasp-3.3.5/debian/control  2022-01-19 14:36:04.0 +0100
@@ -6,6 +6,7 @@
 Build-Depends: debhelper-compat (= 13),
  dpkg-dev (>= 1.16.1~),
  g++-10 (>= 10.2.1),
+ catch,
  cmake (>= 3.1.0)
 Rules-Requires-Root: no
 Standards-Version: 4.5.1
diff -Nru clasp-3.3.5/debian/patches/series clasp-3.3.5/debian/patches/series
--- clasp-3.3.5/debian/patches/series   2020-12-26 21:49:38.0 +0100
+++ clasp-3.3.5/debian/patches/series   2022-01-19 14:24:03.0 +0100
@@ -1,2 +1,3 @@
 clasp-manpage.patch
 link-libatomic-check-gcc.patch
+use-system-catch-for-glibc-2.34-compat.patch
diff -Nru 
clasp-3.3.5/debian/patches/use-system-catch-for-glibc-2.34-compat.patch 
clasp-3.3.5/debian/patches/use-system-catch-for-glibc-2.34-compat.patch
--- clasp-3.3.5/debian/patches/use-system-catch-for-glibc-2.34-compat.patch 
1970-01-01 01:00:00.0 +0100
+++ clasp-3.3.5/debian/patches/use-system-catch-for-glibc-2.34-compat.patch 
2022-01-19 14:35:31.0 +0100
@@ -0,0 +1,296 @@
+Description: Fix 'catch' (CTest) compatibility with glibc-2.34
+ The clasp package contains an embedded copy of the 'catch' v1 (CTest)
+ library. That copy is outdated and incompatible with glibc-2.34.
+ This patch updates the test sources to use the system provided versions of
+ 'catch' instead, to fix this issue.
+ C.f.: https://github.com/catchorg/Catch2/issues/2178
+Author: Lukas Märdian 
+Origin: vendor, Ubuntu
+Forwarded: no
+Bug: https://github.com/potassco/clasp/issues/73
+Last-Update: 2022-01-18
+---
+This patch header follows DEP-3: http://dep.debian.net/deps/dep3/
+--- clasp-3.3.5.orig/libpotassco/tests/main.cpp
 clasp-3.3.5/libpotassco/tests/main.cpp
+@@ -16,4 +16,4 @@ int enableDebugHeap() {
+ static int eh = enableDebugHeap();
+ #endif
+ #define CATCH_CONFIG_MAIN  // This tells Catch to provide a main() - only do 
this in one cpp file
+-#include "catch.hpp"
++#include 
+--- clasp-3.3.5.orig/libpotassco/tests/test_application.cpp
 clasp-3.3.5/libpotassco/tests/test_application.cpp
+@@ -18,7 +18,7 @@
+ // LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ // FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER 
DEALINGS
+ // IN THE SOFTWARE.
+-#include "catch.hpp"
++#include 
+ #include 
+ #include 
+ #include 
+--- clasp-3.3.5.orig/libpotassco/tests/test_aspif.cpp
 clasp-3.3.5/libpotassco/tests/test_aspif.cpp
+@@ -24,7 +24,7 @@
+ #ifdef _MSC_VER
+ #pragma warning (disable : 4996)
+ #endif
+-#include "catch.hpp"
++#include 
+ #include "test_common.h"
+ #include 
+ #include 
+--- clasp-3.3.5.orig/libpotassco/tests/test_options.cpp
 clasp-3.3.5/libpotassco/tests/test_options.cpp
+@@ -18,7 +18,7 @@
+ // LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ // FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER 
DEALINGS
+ // IN THE SOFTWARE.
+-#include "catch.hpp"
++#include 
+ #include 
+ #include 
+ #include 
+--- clasp-3.3.5.orig/libpotassco/tests/test_smodels.cpp
 clasp-3.3.5/libpotassco/tests/test_smodels.cpp
+@@ -22,7 +22,7 @@
+ // IN THE SOFTWARE.
+ //
+ 
+-#include "catch.hpp"
++#include 
+ #include "test_common.h"
+ #include 
+ #include 
+--- clasp-3.3.5.orig/libpotassco/tests/test_string_convert.cpp
 clasp-3.3.5/libpotassco/tests/test_string_convert.cpp
+@@ -18,7 +18,7 @@
+ // LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ // FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER 
DEALINGS
+ // IN THE SOFTWARE.
+-#include "catch.hpp"
++#include 
+ #include 
+ #include 
+ #include 
+--- clasp-3.3.5.orig/libpotassco/tests/test_text.cpp
 clasp-3.3.5/libpotassco/tests/test_text.cpp
+@@ -22,7 +22,7 @@
+ // IN THE SOFTWARE.
+ //
+ 
+-#include "catch.hpp"
++#inclu

Bug#1004023: golang-github-mendersoftware-mender-artifact: New upstream release (3.7.0)

[Andreas Henriksson]

Source: golang-github-mendersoftware-mender-artifact
Version: 3.6.0+ds1-2
Severity: wishlist

Dear all,

I've looked into updating the "mender-artifact" package to the current
latest upstream release, 3.7.0, and pushed my work to a branch
named "debian/experimental" in the packaging vcs.

This new version will likely be a requirement for being able to
update the "mender-client" package to latest upstream release (3.2.0).

Getting the mender-artifact 3.7.0 package uploaded to unstable is
currently blocked by needing newer versions that are currently only
available in experimental:

* mender-artifact 3.7.0 needs golang-google-genproto (exp)
* golang-google-genproto (exp) in turn needs golang-goprotobuf (exp)

See https://bugs.debian.org/991254

Exactly what's needed to be able to upload these two dependencies
currently sitting in experimental to unstable needs to be figured
out, but that discussion should likely happen on a bug report filed
against either of those. (Filing this for the record / public knowledge,
and to remind myself when I soon forget about this.)

Regards,
Andreas Henriksson

Bug#1003951: DROPBEAR_OPTIONS is silently ignored when missing quotes

[Lee Garrett]

On 18/01/2022 16:21, Guilhem Moulin wrote:
> Control: severity -1 minor
> 
> Hi,
> 
> On Tue, 18 Jan 2022 at 15:58:43 +0100, Lee Garrett wrote:
>> A low-effort fix would be to change the shipped config to
>> # DROPBEAR_OPTIONS=""
>> to indicate that they're required. Ideally the initramfs hook should either 
>> fail
>> when unquoted, or accept the full parameter list without quotes. Your call.
> 
> It's hopefully clear enough with your patch :-)
> 
> Blindly sourcing the config file is in line with how initramfs.conf(5)
> is processed AFAIK; a line containing “FOO=bar baz” won't set FOO="bar
> baz" in the hook, but instead run `baz` with FOO=bar in its environment.
> I'm not against some complex validation logic, but that should probably
> be implemented in initramfs-tools not in src:dropbear.
> 
> cheers

Ah, I wasn't aware that it was directly sourced by a shell. This makes
much more sense now. I guess the command then just failed then and
initramfs moved on. Thanks for clarifying.

Bug#1003948: bullseye-pu: package systemd/247.3-7

[Michael Biebl]

Am 18.01.22 um 14:46 schrieb Michael Biebl:

Touches udev code but I don't expect any effect on d-i.

   * Revert multipath symlink race fix.
 Revert upstream commits which caused a regression in udev resulting in
 long delays when processing partitions with the same label.
 (Closes: #993738)

https://salsa.debian.org/biebl/systemd/-/commit/e9ec5186a719afefbff7bfd9b7514482ad896ff3


I have to add here, that in [1] test/udev-test.pl was updated to check 
this new behaviour. By reverting the commit, some of the tests fail now 
(and as a result our udev autopkgtest as well).


TEST 158: errors: 25 good: 4975/5000
...
TEST 161: errors: 2 good: 418/420
...
27 errors occurred. 6657/6684 good results.


Don't really like that but I also didn't want to revert all those 
commits just to make test/udev-test.pl pass again.


Regards,
Michael



[1] https://github.com/systemd/systemd/pull/17431/commits


OpenPGP_signature
Description: OpenPGP digital signature

Bug#965917: yorick-z: diff for NMU version 1.2.0+cvs20080115-5.1

[Thibaut Paumard]

Dear Adrian,

Thanks a lot.

I completely forgot to process these yorick-* updates after the release 
and missed the mail in December. I did the two most urgent a couple of 
days ago (reverse dependencies of Gyoto) and plan on processing the rest 
within the next week.


NMUs are very welcome! Most or all should be trivial.

Best regards, Thibaut.

Le 19/01/2022 à 12:02, Adrian Bunk a écrit :

Control: tags 965917 + patch
Control: tags 965917 + pending

Dear maintainer,

I've prepared an NMU for yorick-z (versioned as 1.2.0+cvs20080115-5.1)
and uploaded it to DELAYED/7. Please feel free to tell me if I should
cancel it.

cu
Adrian



--
* Dr Thibaut Paumard   | LESIA/CNRS - Table équatoriale (bât. 5)   *
* Tel: +33 1 45 07 78 35   | Observatoire de Paris - Section de Meudon *
* Fax: +33 1 45 07 79 17   | 5, Place Jules Janssen*
* thibaut.paum...@obspm.fr | 92195 MEUDON CEDEX (France)   *


smime.p7s
Description: Signature cryptographique S/MIME

Bug#1004025: ITP: golang-github-arceliar-ironwood -- Routing library with public keys as addresses

[John Goerzen]

Package: wnpp
Severity: wishlist
Owner: John Goerzen 

* Package name: golang-github-arceliar-ironwood
  Version : 0.0~git20210619.6ad55ca-1
  Upstream Author : Arceliar
* URL : https://github.com/Arceliar/ironwood
* License : MPL-2.0
  Programming Lang: Go
  Description : 
 Ironwood is a routing library with a net.PacketConn-compatible interface
 using ed25519.PublicKeys as addresses. Basically, you use it when you
 want to communicate with some other nodes in a network, but you can't
 guarantee that you can directly connect to every node in that network.
 It was written to test improvements to / replace the routing logic in
 Yggdrasil (https://github.com/yggdrasil-network/yggdrasil-go), but it may
 be useful for other network applications.

Required by Yggdrasil, which is required by NNCP

Bug#1003983: opendkim cannot initialize resolver in dkim_dns_init() (libunbound, libnettle, ...?)

[Robert Siemer]

Without libunbound it works. – Problem solved? :-o

On Wed, Jan 19, 2022 at 12:41 PM David Bürgin  wrote:

> Robert Siemer:
> > Opendkim does not run.
> >
> > # opendkim -f
> > [1642532480] libunbound[837:0] error: nettle random(yarrow) cannot
> initialize, getentropy failed: Function not implemented
> > opendkim: can't configure DKIM library: failed to initialize resolver
> >
> > I even recompiled from source deb, both opendkim and libunbound.
> > An ltrace showed that dkim_dns_init() fails with -1, and that
> > one calls ub_ctx_create() which returns 0 but provokes the
> > first line to be printed. The second line is the reason printed
> > when dkim_dns_init() fails.
>
> opendkim uses libunbound by default. The error is from libunbound,
> perhaps try building opendkim without libunbound and see what happens?
>
>
> https://salsa.debian.org/debian/opendkim/-/blob/debian/2.11.0_beta2-6/debian/rules#L10-14
>

Bug#965538: gcc-h8300-hms: diff for NMU version 1:3.4.6+dfsg2-4.2

[Adrian Bunk]

Control: tags 965538 + patch
Control: tags 965538 + pending

Dear maintainer,

I've prepared an NMU for gcc-h8300-hms (versioned as 1:3.4.6+dfsg2-4.2) 
and uploaded it to DELAYED/7. Please feel free to tell me if I should 
cancel it.

cu
Adrian
diff -Nru gcc-h8300-hms-3.4.6+dfsg2/debian/changelog gcc-h8300-hms-3.4.6+dfsg2/debian/changelog
--- gcc-h8300-hms-3.4.6+dfsg2/debian/changelog	2019-12-17 01:36:24.0 +0200
+++ gcc-h8300-hms-3.4.6+dfsg2/debian/changelog	2022-01-19 16:12:47.0 +0200
@@ -1,3 +1,10 @@
+gcc-h8300-hms (1:3.4.6+dfsg2-4.2) unstable; urgency=low
+
+  * Non-maintainer upload.
+  * debian/compat: 5 -> 7. (Closes: #965538)
+
+ -- Adrian Bunk   Wed, 19 Jan 2022 16:12:47 +0200
+
 gcc-h8300-hms (1:3.4.6+dfsg2-4.1) unstable; urgency=medium
 
   [ Balint Reczey ]
diff -Nru gcc-h8300-hms-3.4.6+dfsg2/debian/compat gcc-h8300-hms-3.4.6+dfsg2/debian/compat
--- gcc-h8300-hms-3.4.6+dfsg2/debian/compat	2014-12-20 10:29:34.0 +0200
+++ gcc-h8300-hms-3.4.6+dfsg2/debian/compat	2022-01-19 16:12:37.0 +0200
@@ -1 +1 @@
-5
+7

Bug#965759: opus-tools: diff for NMU version 0.1.10-1.1

[Adrian Bunk]

Control: tags 965759 + patch
Control: tags 965759 + pending

Dear maintainer,

I've prepared an NMU for opus-tools (versioned as 0.1.10-1.1) and 
uploaded it to DELAYED/7. Please feel free to tell me if I should
cancel it.

cu
Adrian
diff -u opus-tools-0.1.10/debian/changelog opus-tools-0.1.10/debian/changelog
--- opus-tools-0.1.10/debian/changelog
+++ opus-tools-0.1.10/debian/changelog
@@ -1,3 +1,10 @@
+opus-tools (0.1.10-1.1) unstable; urgency=low
+
+  * Non-maintainer upload.
+  * debian/compat: 5 -> 7. (Closes: #965759)
+
+ -- Adrian Bunk   Wed, 19 Jan 2022 16:18:25 +0200
+
 opus-tools (0.1.10-1) unstable; urgency=medium
 
   * Improved handling of malformed input files to avoid crashes and other
diff -u opus-tools-0.1.10/debian/compat opus-tools-0.1.10/debian/compat
--- opus-tools-0.1.10/debian/compat
+++ opus-tools-0.1.10/debian/compat
@@ -1 +1 @@
-5
+7

Bug#965458: chntpw: Removal of obsolete debhelper compat 5 and 6 in bookworm

[Fabio Fantoni]

Hi, in recent days I had prepared a git for chntpw, contacted the 
maintainer, then prepared the patches to convert to dh and compat 13 and 
also solve other few issues.


the maintainer is still active and he told me he would revise my 
changes, anyway thanks to Adrian Bunk for your pending patch/build that 
delayed remove from testing (in case the maintainer does not have time 
to review and do the new build)




OpenPGP_signature
Description: OpenPGP digital signature

Bug#1003983: opendkim cannot initialize resolver in dkim_dns_init() (libunbound, libnettle, ...?)

[David Bürgin]

Robert Siemer:
> Without libunbound it works. – Problem solved? :-o

You decide. Well, I don’t think there’s much we can do in opendkim.

You could ask the unbound maintainers. It might be expected behaviour on
some unusual OS’es …? But I don’t know.

Bug#581630: dictconv: diff for NMU version 0.2-7.1

[Adrian Bunk]

Control: tags 581630 + patch
Control: tags 581630 + pending
Control: tags 965491 + patch
Control: tags 965491 + pending

Dear maintainer,

I've prepared an NMU for dictconv (versioned as 0.2-7.1) and uploaded
it to DELAYED/7. Please feel free to tell me if I should cancel it.

cu
Adrian
diff -u dictconv-0.2/debian/control dictconv-0.2/debian/control
--- dictconv-0.2/debian/control
+++ dictconv-0.2/debian/control
@@ -11,7 +11,7 @@
 Depends: ${shlibs:Depends}, ${misc:Depends}
 Recommends: dictzip
 Description: convert a dictionary file type in another dictionary file type
- Dictconv is a small program to convert a dictionay file type in another
+ Dictconv is a small program to convert a dictionary file type in another
  dictionary file type. Currently, it supports converting from Babylon
  glossaries, Freedict dictionaries, Sdictionary dictionaries and Stardict
  dictionaries to DICT dictionaries, plain text dictionaries and StarDict
diff -u dictconv-0.2/debian/changelog dictconv-0.2/debian/changelog
--- dictconv-0.2/debian/changelog
+++ dictconv-0.2/debian/changelog
@@ -1,3 +1,11 @@
+dictconv (0.2-7.1) unstable; urgency=low
+
+  * Non-maintainer upload.
+  * debian/compat: 5 -> 7. (Closes: #965491)
+  * Spelling fix in the package description. (Closes: #581630)
+
+ -- Adrian Bunk   Wed, 19 Jan 2022 16:23:08 +0200
+
 dictconv (0.2-7) unstable; urgency=low
 
   * debian/rules: added simple-patchsys include.
diff -u dictconv-0.2/debian/compat dictconv-0.2/debian/compat
--- dictconv-0.2/debian/compat
+++ dictconv-0.2/debian/compat
@@ -1 +1 @@
-5
+7

Bug#1004026: covered: gplcver support should be dropped or gplcver adopted by the Electronics Team

[Adrian Bunk]

Package: covered
Version: 0.7.10-3.1
Severity: serious
Control: block 965565 by -1

If gplcver provides any functionality not available in iverilog,
it would be useful if this orphaned package could be adopted by
the Electronics Team.

Otherwise, please drop gplcver support from covered.

Bug#1004027: aunpack should support unrar command

[VA]

Package: atool
Version: 0.39.0-11

When running aunpack on .rar files, I would expect it to run unrar 
command, but it doesn't…
So whether I installed `unrar-free` or `unrar` package, it's not used. 
It only supports rar files if the `rar` package is installed.


See log:

Can't exec "rar": No such file or directory at /usr/bin/aunpack line 1868.
rar: cannot execute - No such file or directory
aunpack: rar ...: non-zero return-code

Bug#1004028: ITP: golang-github-kardianos-minwinsvc -- Stub for portability to Windows

[John Goerzen]

Package: wnpp
Severity: wishlist
Owner: John Goerzen 

* Package name: golang-github-kardianos-minwinsvc
  Version : 1.0.0-1
  Upstream Author : Daniel Theophanes
* URL : https://github.com/kardianos/minwinsvc
* License : BSD-3
  Programming Lang: Go
  Description : Stub for portability to Windows

 Minimal windows service stub
 .
 Programs designed to run from most *nix style operating systems can
 import this package to enable running programs as services without
 modifying them.  On Debian platforms, it is simply a no-op, but is
 a dependency of certain cross-platform Go code.

Bug#1004029: music: Please update package homepage information

[Boyuan Yang]

Source: music
Version: 1.1.16-1.1
Tags: sid bookworm

Dear Debian music package maintainer,

It seems that the homepage now redirects to https://github.com/INCF/MUSIC .
Please update package metadata accordingly. Thanks!

Best,
Boyuan Yang


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

Bug#1004030: O: lqa -- LAVA QA tool

[Andrej Shadura]

Package: wnpp
Severity: normal
X-Debbugs-Cc: de...@lists.apertis.org
Control: affects -1 src:lqa

I intend to orphan the lqa package.

This package offers an alternative command-line client to LAVA, the
automated testing platform. I was developed by a former colleague of
mine, but we no longer use this tool, so it is effectively also
abandoned upstream.

Should somebody find this tool interesing or useful, please get in touch
and take it over upstream as well.

-- 
Cheers,
  Andrej

Bug#1004031: resolvconf: /etc/dhcp/dhclient-enter-hooks.d/resolvconf should not disable the generation of /etc/resolv.conf when not a symlink

[Vincent Lefevre]

Package: resolvconf
Version: 1.91
Severity: normal

/etc/dhcp/dhclient-enter-hooks.d/resolvconf systematically disables
the generation of /etc/resolv.conf when resolvconf is installed.

This is OK when resolvconf is used, i.e. when /etc/resolv.conf is a
symbolic link to ../run/resolvconf/resolv.conf, but this is incorrect
when /etc/resolv.conf is a plain file, i.e. when /etc/resolv.conf is
not handled by resolvconf.

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

Kernel: Linux 5.15.0-2-amd64 (SMP w/8 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 resolvconf depends on:
ii  debconf [debconf-2.0]  1.5.79
ii  lsb-base   11.1.0

resolvconf recommends no packages.

resolvconf suggests no packages.

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

Bug#1004032: unbound: /etc/resolvconf/update.d/unbound is buggy

[Vincent Lefevre]

Package: unbound
Version: 1.13.1-1
Severity: important

Note: The changes I've done on /etc/resolvconf/update.d/unbound
is just logging messages (to known what's going on).

When /run/resolvconf/interface/NetworkManager is obsolete (which
can occur as NetworkManager is not the only was to connect: I use
it only for wifi), DNS resolution no longer works.

I fear that even when this file is not obsolete, unbound does not
work as expected.

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

Kernel: Linux 5.15.0-2-amd64 (SMP w/8 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 unbound depends on:
ii  adduser 3.118
ii  dns-root-data   2021011101
ii  libc6   2.33-2
ii  libevent-2.1-7  2.1.12-stable-1
ii  libprotobuf-c1  1.3.3-1+b2
ii  libpython3.93.9.10-1
ii  libssl1.1   1.1.1m-1
ii  libsystemd0 250.2-3
ii  lsb-base11.1.0
ii  openssl 1.1.1m-1
ii  unbound-anchor  1.13.1-1

unbound recommends no packages.

Versions of packages unbound suggests:
ii  apparmor  3.0.3-6

-- Configuration Files:
/etc/resolvconf/update.d/unbound changed:
PATH=/usr/sbin:/usr/bin:/sbin:/bin
if [ ! -x /usr/sbin/unbound ]; then
exit 0
fi
if [ ! -f /etc/unbound/unbound_control.key ]; then
exit 0
fi
if [ ! -x /lib/resolvconf/list-records ]; then
exit 1
fi
RESOLVCONF_FILES="$(/lib/resolvconf/list-records)"
if [ -n "$RESOLVCONF_FILES" ]; then
NS_IPS="$(sed -rne 's/^[[:space:]]*nameserver[[:space:]]+//p' 
$RESOLVCONF_FILES \
| egrep -v '^(127\.|::1)' | sort -u)"
else
NS_IPS=""
fi
if [ -n "$NS_IPS" ]; then
FWD="$(echo $NS_IPS | tr '\n' ' ')"
else
FWD=off
fi
logger "/etc/resolvconf/update.d/unbound: forward $FWD"
unbound-control forward $FWD 1>/dev/null 2>&1 || true


-- no debconf information

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

Bug#1004005: [Debichem-devel] Bug#1004005: openmm: reproducible-builds: BuildId differences triggered by RPATH

[Vagrant Cascadian]

On 2022-01-19, Andrius Merkys wrote:
> On 2022-01-19 10:02, Vagrant Cascadian wrote:
>> The attached patch to debian/rules passes
>> -DCMAKE_BUILD_RPATH_USE_ORIGIN=ON via a dh_auto_configure override,
>> which should use a relative path for RPATH.
>
> Thanks a lot for the patch!
>
>> Alternately, updating the packaging to debhelper compat level 14 should
>> fix this, although it is currently an experimental compat level.
>> 
>> With this patch applied, openmm *should* build reproducibly on
>> tests.reproducible-builds.org for the version currently in unstable,
>> although the version in experimental seems to embed the build path in
>> additional and/or non-deterministic ways.
>
> Maybe a possible long-term solution would be to use chrpath to set the
> RPATH to point to the absolute location of private libraries, like
> /usr/lib/${DEB_HOST_MULTIARCH}/openmm ?

I haven't yet identified the cause of the other issues.

I think the RPATH issues are solved by the submitted patch; at the very
least it massively reduces the differences!


live well,
  vagrant


signature.asc
Description: PGP signature

Bug#1004033: bullseye-pu: package node-fetch/2.6.1-5+deb11u1

[Yadd]

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

[ Reason ]
node-fetch is vulnerable to privacy breach (CVE-2022-0235)

[ Impact ]
Medium vulnerability

[ Tests ]
Test passed

[ Risks ]
Low risk, patch just cleans headers

[ 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 (old)stable
  [X] the issue is verified as fixed in unstable

[ Changes ]
Clean headers before request

Cheers,
Yadd
diff --git a/debian/changelog b/debian/changelog
index 7f3da38..31eb312 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,10 @@
+node-fetch (2.6.1-5+deb11u1) bullseye; urgency=medium
+
+  * Team upload
+  * Don't forward secure headers to 3th party (Closes: CVE-2022-0235)
+
+ -- Yadd   Wed, 19 Jan 2022 16:46:28 +0100
+
 node-fetch (2.6.1-5) unstable; urgency=medium
 
   * Team upload
diff --git a/debian/patches/CVE-2022-0235.patch 
b/debian/patches/CVE-2022-0235.patch
new file mode 100644
index 000..d97cd7a
--- /dev/null
+++ b/debian/patches/CVE-2022-0235.patch
@@ -0,0 +1,22 @@
+Description: don't forward secure headers to 3th party
+Author: Jimmy Wärting 
+Origin: upstream, https://github.com/node-fetch/node-fetch/commit/f5d3cf5e
+Bug: https://huntr.dev/bounties/d26ab655-38d6-48b3-be15-f9ad6b6ae6f7/
+Forwarded: not-needed
+Reviewed-By: Yadd 
+Last-Update: 2022-01-19
+
+--- a/src/index.js
 b/src/index.js
+@@ -170,6 +170,11 @@
+   requestOpts.body = 
undefined;
+   
requestOpts.headers.delete('content-length');
+   }
++if (!isDomainOrSubdomain(request.url, locationURL)) {
++  for (const name of 
['authorization', 'www-authenticate', 'cookie', 'cookie2']) {
++  
requestOptions.headers.delete(name);
++  }
++  }
+ 
+   // HTTP-redirect fetch step 15
+   resolve(fetch(new 
Request(locationURL, requestOpts)));
diff --git a/debian/patches/series b/debian/patches/series
index 882f8ed..20c4319 100644
--- a/debian/patches/series
+++ b/debian/patches/series
@@ -1,3 +1,4 @@
 babelrc.patch
 fix-default-export.diff
 drop-legacy-rollup-babel-plugin.patch
+CVE-2022-0235.patch

Bug#1003969: sudo: FQDN option not overridable early on.

[Sven Mueller]

I can confirm that the linked upstream patch fixes the issue (sudo
works with non-resolvable hostname).

With the patch and `Defaults !fqdn`, no error or warning is shown/logged

With the patch and `Defaults fqdn` (or without a Defaults line
referring to fqdn, i.e. with a default sudoers file), a warning is
shown when sudo is used, but it remain usable.

Cheers,
Sven


Am Mi., 19. Jan. 2022 um 13:29 Uhr schrieb Sven Mueller
:
>
> Tags 1003969 + fixed-upstream patch confirmed
> Thanks
>
> https://www.sudo.ws/repos/sudo/rev/8c6eaa503793 has the upstream patch.

Bug#1004005: [Debichem-devel] Bug#1004005: openmm: reproducible-builds: BuildId differences triggered by RPATH

[Vagrant Cascadian]

On 2022-01-19, Vagrant Cascadian wrote:
> On 2022-01-19, Andrius Merkys wrote:
>> On 2022-01-19 10:02, Vagrant Cascadian wrote:
>>> The attached patch to debian/rules passes
>>> -DCMAKE_BUILD_RPATH_USE_ORIGIN=ON via a dh_auto_configure override,
>>> which should use a relative path for RPATH.
>>
>> Thanks a lot for the patch!
>>
>>> Alternately, updating the packaging to debhelper compat level 14 should
>>> fix this, although it is currently an experimental compat level.
>>> 
>>> With this patch applied, openmm *should* build reproducibly on
>>> tests.reproducible-builds.org for the version currently in unstable,
>>> although the version in experimental seems to embed the build path in
>>> additional and/or non-deterministic ways.
>>
>> Maybe a possible long-term solution would be to use chrpath to set the
>> RPATH to point to the absolute location of private libraries, like
>> /usr/lib/${DEB_HOST_MULTIARCH}/openmm ?
>
> I haven't yet identified the cause of the other issues.
>
> I think the RPATH issues are solved by the submitted patch; at the very
> least it massively reduces the differences!

It looks like the addition of python3-simtk-dbgsym in the version in
experimental is what is causing the additional changes.

diffoscope output attached.


live well,
  vagrant


experiment-1.diffoscope.out.gz
Description: application/gzip


signature.asc
Description: PGP signature

Bug#1004022: clasp: Clasp FTBFS with glibc 2.34

[Lukas Märdian]

Am 19.01.22 um 14:41 schrieb Lukas Märdian:

Package: clasp
Version: 3.3.5-4
Severity: normal
Tags: patch
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu jammy ubuntu-patch
X-Debbugs-Cc: sl...@ubuntu.com

Dear Maintainer,

Once glibc will be upgraded to 2.34+ clasp will FTBFS.

In Ubuntu, the attached patch was applied to fix this issue:

   * d/p/use-system-catch-for-glibc-2.34-compat.patch: Fix FTBFS with glibc-2.34
 - Add catch v1 build-dependency
 - Make use of system provided catch v1 (CTest) library


Please remember that 
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=993515 needs to be 
fixed first in order for this patch to take effect.


-- Lukas

Bug#1004034: bagel: reproducible-builds: build path embedded in /usr/bin/BAGEL and debug symbols

[Vagrant Cascadian]

Source: bagel
Severity: normal
Tags: patch
User: reproducible-bui...@lists.alioth.debian.org
Usertags: buildpath
X-Debbugs-Cc: reproducible-b...@lists.alioth.debian.org

Different build paths trigger reproducibility issues with binaries such
as /usr/bin/BAGEL and relevent debugging symbols.

The attached patch fixes this by passing -ffile-prefix-map to CXXFLAGS
to avoid embedding the build path into the binaries.

Another possibility would be to use dpkg-buildflags, which includes this
flag by default.


With this patch applied, bagel should build reproducibly on
tests.reproducible-builds.org!


Thanks for maintaining bagel!


live well,
  vagrant
From e7c8200cb457d886a634f383623d693a961b1a06 Mon Sep 17 00:00:00 2001
From: Vagrant Cascadian 
Date: Wed, 19 Jan 2022 16:04:53 +
Subject: [PATCH] debian/rules: Pass -ffile-prefix-map in CXXFLAGS.

The -ffile-prefix-map argument is used to avoid embedding the build
path in binaries, which allows for reproducible builds regardless of
the build path in the build environment.
---
 debian/rules | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/debian/rules b/debian/rules
index 62d1d08..b6e0afa 100755
--- a/debian/rules
+++ b/debian/rules
@@ -3,7 +3,7 @@
 
 export LIBS=-lblas -llapack -lpthread
 
-export CXXFLAGS=-g1 -O2 -DNDEBUG -DZDOT_RETURN
+export CXXFLAGS=-g1 -O2 -DNDEBUG -DZDOT_RETURN -ffile-prefix-map=$(CURDIR)=.
 
 DEB_HOST_MULTIARCH ?= $(shell dpkg-architecture -qDEB_HOST_MULTIARCH)
 B_LIBDIR=/usr/lib/$(DEB_HOST_MULTIARCH)
-- 
2.34.1



signature.asc
Description: PGP signature

Bug#1004007: freecad: Segfaults on armhf when clicking "Ceate New..." or File -> New

[Tobias Frost]

On Wed, Jan 19, 2022 at 08:17:11AM +, Serge Schneider wrote:
> Package: freecad
> Version: 0.19.1+dfsg1-2
> Severity: important
> X-Debbugs-Cc: se...@raspberrypi.com
> 
> Dear Maintainer,
> 
> When running FreeCAD, creating a new file crashes with a segfault:
(...)

> This is the same issue as #931458, which was closed because it was reported
> against Raspbian's packages.  However, the issue is reproducible in Debian
> too (using 20210823_raspi_2_bullseye.img.xz).
> 
> The crash seems to have something to do with how Ccoin3D creates the context
> in Qt.
> 
> Rebuilding FreeCAD against Qt4 rather than Qt5 makes it work. It also works
> on arm64.
> 
> The main difference I can see is that Qt is built with OpenGL support on
> arm64, but only OpenGL ES support on armhf.
> 
> Thegq issue has also been reported upstream at
> https://tracker.freecadweb.org/view.php?id=4083, but there hasn't been any
> progess in a few years.

The discussion on the FreCAD forum (pointer to the thread is in the above
FreeCAD ticket), namely the backtrace at 
https://forum.freecadweb.org/viewtopic.php?p=456568#p456568 hints that this
crash is happening somewhere in libcoin: (IF the backtrace is related to what 
you see as well)
It is calling out to libx11's XDefaultScreenOfDisplay() and it looks like that 
this
might be a NULL-Pointer passed to that function...
https://codesearch.debian.net/search?q=XScreenOfDisplay+package%3Alibx11&literal=0

That reminds me of https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=969230...

Unfortunatly I do not have any Pi4 I could use for this to debug at my hands.

However, you might want to see if cherry-picking the mentioned patch in
#969230 (https://github.com/coin3d/coin/pull/404/files) and recompile the
coin3 Debian package locally with that patch.. Maybe this does something for you
and helps pin-pointing the problem.


-- 
tobi

> -- System Information:
> Debian Release: 11.0
>   APT prefers stable-security
>   APT policy: (500, 'stable-security'), (500, 'stable')
> Architecture: armhf (armv7l)
> 
> Kernel: Linux 5.10.0-8-armmp (SMP w/4 CPU threads)
> Kernel taint flags: TAINT_CRAP, TAINT_UNSIGNED_MODULE
> Locale: LANG=C, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set
> Shell: /bin/sh linked to /usr/bin/dash
> Init: systemd (via /run/systemd/system)
> LSM: AppArmor: enabled
> 
> Versions of packages freecad depends on:
> ii  freecad-python3  0.19.1+dfsg1-2
> 
> Versions of packages freecad recommends:
> ii  calculix-ccx  2.17-3
> ii  graphviz  2.42.2-5
> 
> Versions of packages freecad suggests:
> pn  povray  
> 
> -- no debconf information

Bug#1002167: hmat-oss: diff for NMU version 1.2.0-2.2

[Adrian Bunk]

Control: tags 1002167 + patch
Control: tags 1002167 + pending

Dear maintainer,

I've prepared an NMU for hmat-oss (versioned as 1.2.0-2.2) and uploaded 
it to DELAYED/14. Please feel free to tell me if I should cancel it.

cu
Adrian
diff -Nru hmat-oss-1.2.0/debian/changelog hmat-oss-1.2.0/debian/changelog
--- hmat-oss-1.2.0/debian/changelog	2020-05-02 02:18:14.0 +0300
+++ hmat-oss-1.2.0/debian/changelog	2022-01-19 18:14:34.0 +0200
@@ -1,3 +1,10 @@
+hmat-oss (1.2.0-2.2) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Backport upstream fix for FTBFS with glibc 2.33. (Closes: #1002167)
+
+ -- Adrian Bunk   Wed, 19 Jan 2022 18:14:34 +0200
+
 hmat-oss (1.2.0-2.1) unstable; urgency=medium
 
   * Non-maintainer upload.
diff -Nru hmat-oss-1.2.0/debian/patches/0001-instrumentation-Use-mallinfo2-from-glibc-2.33.patch hmat-oss-1.2.0/debian/patches/0001-instrumentation-Use-mallinfo2-from-glibc-2.33.patch
--- hmat-oss-1.2.0/debian/patches/0001-instrumentation-Use-mallinfo2-from-glibc-2.33.patch	1970-01-01 02:00:00.0 +0200
+++ hmat-oss-1.2.0/debian/patches/0001-instrumentation-Use-mallinfo2-from-glibc-2.33.patch	2022-01-19 18:14:34.0 +0200
@@ -0,0 +1,41 @@
+From 40b12c8c90ab5d67847fec6bda6111c396fa3b0d Mon Sep 17 00:00:00 2001
+From: Julien Schueller 
+Date: Fri, 19 Feb 2021 10:22:35 +0100
+Subject: instrumentation: Use mallinfo2 from glibc 2.33
+
+mallinfo being deprecated
+---
+ src/common/memory_instrumentation.cpp | 8 
+ 1 file changed, 8 insertions(+)
+
+diff --git a/src/common/memory_instrumentation.cpp b/src/common/memory_instrumentation.cpp
+index 22acd3d..a98870e 100644
+--- a/src/common/memory_instrumentation.cpp
 b/src/common/memory_instrumentation.cpp
+@@ -31,7 +31,11 @@
+ #ifdef __GLIBC__
+ #include 
+ // Do not care about thread safety. This is an acceptable approximation.
++#if __GLIBC_PREREQ(2,33)
++static struct mallinfo2 global_mallinfo;
++#else
+ static struct mallinfo global_mallinfo;
++#endif
+ static int mallinfo_counter;
+ #endif
+ static int write_counter;
+@@ -142,7 +146,11 @@ void MemoryInstrumenter::allocImpl(mem_t size, char type) {
+ #ifdef __GLIBC__
+ mallinfo_counter ++;
+ if(mallinfo_counter >= mallinfo_sampling) {
++#if __GLIBC_PREREQ(2,33)
++global_mallinfo = mallinfo2();
++#else
+ global_mallinfo = mallinfo();
++#endif
+ mallinfo_counter = 0;
+ }
+ int k = 3;
+-- 
+2.20.1
+
diff -Nru hmat-oss-1.2.0/debian/patches/series hmat-oss-1.2.0/debian/patches/series
--- hmat-oss-1.2.0/debian/patches/series	2020-05-02 01:27:04.0 +0300
+++ hmat-oss-1.2.0/debian/patches/series	2022-01-19 18:14:05.0 +0200
@@ -1,3 +1,4 @@
 0001-make-build-reproducible.patch
 0002-Fix-compilation-on-Linux-32-bits-systems.patch
 fix_gcc.patch
+0001-instrumentation-Use-mallinfo2-from-glibc-2.33.patch

Bug#1002180: clamfs: diff for NMU version 1.2.0-2.1

[Adrian Bunk]

Control: tags 1002180 + patch
Control: tags 1002180 + pending

Dear maintainer,

I've prepared an NMU for clamfs (versioned as 1.2.0-2.1) and uploaded
it to DELAYED/14. Please feel free to tell me if I should cancel it.

cu
Adrian
diff -Nru clamfs-1.2.0/debian/changelog clamfs-1.2.0/debian/changelog
--- clamfs-1.2.0/debian/changelog	2020-01-10 02:46:18.0 +0200
+++ clamfs-1.2.0/debian/changelog	2022-01-19 18:35:36.0 +0200
@@ -1,3 +1,10 @@
+clamfs (1.2.0-2.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Don't build with -Werror. (Closes: #1002180)
+
+ -- Adrian Bunk   Wed, 19 Jan 2022 18:35:36 +0200
+
 clamfs (1.2.0-2) unstable; urgency=medium
 
   * Add patches/Remove-_start-symbol-check-for-CXX-libraries.patch to fix
diff -Nru clamfs-1.2.0/debian/patches/no-Werror.patch clamfs-1.2.0/debian/patches/no-Werror.patch
--- clamfs-1.2.0/debian/patches/no-Werror.patch	1970-01-01 02:00:00.0 +0200
+++ clamfs-1.2.0/debian/patches/no-Werror.patch	2022-01-19 18:35:36.0 +0200
@@ -0,0 +1,15 @@
+Description: Don't build with -Werror.
+Author: Adrian Bunk 
+Bug-Debian: https://bugs.debian.org/1002180
+
+--- clamfs-1.2.0.orig/configure.ac
 clamfs-1.2.0/configure.ac
+@@ -37,7 +37,7 @@ AC_CHECK_FUNCS([fchdir fdatasync fork ft
+ AC_C_FDPASSING
+ 
+ # Set initial CPPFLAGS
+-CPPFLAGS="$CPPFLAGS -Wall -Werror -Wextra"
++CPPFLAGS="$CPPFLAGS -Wall -Wextra"
+ 
+ # Checks for boost
+ AX_BOOST_BASE(1.33)
diff -Nru clamfs-1.2.0/debian/patches/series clamfs-1.2.0/debian/patches/series
--- clamfs-1.2.0/debian/patches/series	2020-01-10 01:59:11.0 +0200
+++ clamfs-1.2.0/debian/patches/series	2022-01-19 18:35:36.0 +0200
@@ -1 +1,2 @@
 Remove-_start-symbol-check-for-CXX-libraries.patch
+no-Werror.patch

Bug#1004035: rumur FTBFS on 32bit: Bad system call

[Adrian Bunk]

Source: rumur
Version: 2021.12.27-1
Severity: serious
Tags: ftbfs
Control: block 1002186 by -1

https://buildd.debian.org/status/package.php?p=rumur

...
--- SIGSYS {si_signo=SIGSYS, si_code=SYS_SECCOMP, si_call_addr=0x5c20ec, 
si_syscall=__NR_statx, si_arch=AUDIT_ARCH_PPC} ---
+++ killed by SIGSYS +++
/<>/tests/strace-sandbox.sh: line 69: 3494941 Bad system call  
   strace ./model.exe
+ RET=159
+ '[' 159 -eq 0 ']'
+ popd
+ rm -rf /tmp/tmp.MFJZxsf2dZ
+ exit 159


==
FAIL: test_basic_sandbox_m (__main__.rumurDebugMultithreaded)
--
Traceback (most recent call last):
  File "/<>/tests/run-tests.py", line 576, in 
setattr(c, name, lambda self, p=p: self._run(p))
  File "/<>/tests/run-tests.py", line 490, in _run
self._run_param(testcase, True, False, True, False)
  File "/<>/tests/run-tests.py", line 441, in _run_param
self.fail('Unexpected checker exit status {}:\n{}{}'
AssertionError: Unexpected checker exit status -31:
...
Ran 5344 tests in 1239.289s

FAILED (failures=13, skipped=2211)
make[4]: *** [CMakeFiles/check.dir/build.make:73: CMakeFiles/check] Error 1

Bug#1000991: Updates to the content required

[Gabriel CORRE]

Source: debian-reference
Followup-For: Bug #1000991

Hello,

in https://www.debian.org/doc/manuals/debian-reference/ch02.en.html
(in english but also other languages)

The samples of /etc/apt/source.list use possible wrong url

There are both mention of :

```
deb http://security.debian.org/debian-security ...
deb http://security.debian.org/ ...
```

The website it-self ( https://www.debian.org/security/ ) told to use `deb 
http://security.debian.org/debian-security`

Replace `http://security.debian.org/` by 
`http://security.debian.org/debian-security`

in chapiters:
- [x] 2.1.4 ok : 
https://www.debian.org/doc/manuals/debian-reference/ch02.en.html#_debian_archive_basics
- [ ] 2.7.4 need to be fixed : 
https://www.debian.org/doc/manuals/debian-reference/ch02.en.html#_updates_and_backports
- [ ] 2.7.6 need to be fixed : 
https://www.debian.org/doc/manuals/debian-reference/ch02.en.html#_tracking_literal_testing_literal_with_some_packages_from_literal_unstable_literal
- [ ] 2.7.7 need to be fixed : 
https://www.debian.org/doc/manuals/debian-reference/ch02.en.html#_tracking_literal_unstable_literal_with_some_packages_from_literal_experimental_literal

Regards,

Bug#1003864: libreoffice-help-it: Libreoffice help depends from Firefox-esr package

[Rene Engelhard]

Am 19.01.22 um 13:13 schrieb Antonio:
I would like to install LibreOffice Help to use it offline but if I do 
it then forced me to install Firefox-ESR, which for me would be a 
duplicate I don't need.


No, that is wrong as I said. It forces you to use a JS-supporting 
browser from the Debian archive, not just firefox-esr:


I said:

"firefox-esr OR epiphany-browser OR konqueror OR chromium OR firefox"


Maybe equivs helps here?


And yes, I can read english and understand what you want.

That's why my compromise suggestion was to do it as Recommends: (which 
would still be installed per default and can be ignored)


I said "One might argue it can be a Recommends: (then only people who 
don't install recommends per default don't get it, but)".



It would be interesting if the package manager could install 
Firefox-ESR only if it don't finds other browsers available in the 
system (in my case: /etc/alternatives/x-www-browser -> 
/opt/firefox/firefox).



Nah, that would be titally undeterministic.


(BTW, you maybe should stop fullquoting, top-posting and read mails, i 
already said in my last mail that I consider making it Recommends: 
instead of Depends:)


Regards,


Rene

Bug#1003929: ncurses: please make the build reproducible

[Sven Joachim]

On 2022-01-18 09:26 +, Chris Lamb wrote:

> Source: ncurses
> Version: 6.3-2
> Severity: wishlist
> Tags: patch
> User: reproducible-bui...@lists.alioth.debian.org
> Usertags: umask
> X-Debbugs-Cc: reproducible-b...@lists.alioth.debian.org
>
> Hi,
>
> Whilst working on the Reproducible Builds effort [0] we noticed that
> ncurses could not be built reproducibly.

Thanks.  I should have noticed that from the failing reprotest in the
Salsa CI, but did not look closely and thought that it would be due to a
different problem that has shown up on i386 since ncurses 6.3-1.

> This is because the README.gz file will retain its group-writeable bit
> due to the use of dh_fixperms -Xfoo, and will thus vary when the package
> is built with a different umask:
>
> --rw-r--r--   0 root (0) root (0) 7937 2021-03-07 
> 00:08:58.00 ./usr/libexec/ncurses-examples/README.gz
> +-rw-rw-r--   0 root (0) root (0) 7937 2021-03-07 
> 00:08:58.00 ./usr/libexec/ncurses-examples/README.gz
>
> Patch attached that removes this bit manually, but feel free to go with a
> different solution, of course.

> --- a/debian/rules2022-01-18 08:47:42.277389249 +
> --- b/debian/rules2022-01-18 09:03:30.547729907 +
> @@ -508,6 +508,7 @@
>   dh_compress -p$(package-examples) usr/libexec/ncurses-examples/README
>   dh_compress -a -N$(package-examples)
>   dh_fixperms -a -Xusr/libexec/ncurses-examples/README
> + chmod g-w debian/ncurses-examples/usr/libexec/ncurses-examples/README.gz

That works with umask 002, but in fact the file could have any
permissions from 000 to 666, depending on the umask used when the source
was unpacked.

I have installed a different fix, and now the reprotest succeeds
again[1].

Cheers,
   Sven


1. https://salsa.debian.org/debian/ncurses/-/pipelines/339074

Bug#985314: Fwd: Re: Bug#985314: asterisk spams console output to syslog due to systemd misconfiguration

[Sergio Durigan Junior]

The bug was archived, so the message I sent (below) bounced.  Forwarding
it.

-- 
Sergio
GPG key ID: 237A 54B1 0287 28BF 00EF  31F4 D0EB 7628 65FC 5E36
Please send encrypted e-mail if possible
https://sergiodj.net/

 Start of forwarded message 
From: Sergio Durigan Junior 
To: Utkarsh Gupta 
Cc: be...@debian.org,  985...@bugs.debian.org
Subject: Re: Bug#985314: asterisk spams console output to syslog due to
 systemd misconfiguration
Date: Wed, 19 Jan 2022 11:49:02 -0500

On Monday, March 15 2021, Utkarsh Gupta wrote:

> Hi Bernhard,
>
> Thanks for taking care of asterisk. This bug report is just a mere
> forward of what was originally reported in Ubuntu; cf:
> https://bugs.launchpad.net/ubuntu/+source/asterisk/+bug/1909816.
[...]

"Editing patches by hand considered evil" :-).

This upload introduced a problem: the asterisk.service file doesn't
contain the [Install] section anymore, which makes it be treated as a
static unit by systemd.  This means that the service cannot be
enabled/disabled, so when a reboot happens the service doesn't
automatically start.

This has been reported in
https://bugs.launchpad.net/ubuntu/+source/asterisk/+bug/1958259, btw.

The problem happened because the file d/p/systemd.patch was likely
edited by hand, but the diff header was not updated to reflect the new
lines that have been added.  Because of this, 'patch' silently drops the
last 6 lines of the diff when applying it.

The following patch should fix the problem.

Thanks,

-- 
Sergio
GPG key ID: 237A 54B1 0287 28BF 00EF  31F4 D0EB 7628 65FC 5E36
Please send encrypted e-mail if possible
https://sergiodj.net/

diff --git a/debian/patches/systemd.patch b/debian/patches/systemd.patch
index de803e43..34da8fed 100644
--- a/debian/patches/systemd.patch
+++ b/debian/patches/systemd.patch
@@ -81,7 +81,7 @@ Last-Update: 2016-04-02
 +fi
 --- /dev/null
 +++ b/contrib/asterisk.service
-@@ -0,0 +1,49 @@
+@@ -0,0 +1,55 @@
 +[Unit]
 +Description=Asterisk PBX
 +Documentation=man:asterisk(8)


signature.asc
Description: PGP signature
 End of forwarded message 

Bug#1004036: libvmime: FTBFS with ICU 70.1

[GCS]

Source: libvmime
Version: 0.9.2-7
Severity: normal
Tags: ftbfs patch
Usertags: ICU70.1

Hi,

Soon I would like to start the ICU 70.1 transition. Your package FTBFS
with this release. Main reason is that since ICU 68.1 it doesn't
define TRUE and FALSE constants.
You need to use the C99 / C++ ones which are lowercase ones. Patch is
attached to make it easy for you.

Regards,
Laszlo/GCS
Description: since ICU 68.1 TRUE and FALSE are no longer defined
 Use their C99 / C++ analogues, ie use them in lowercase.
Author: Laszlo Boszormenyi (GCS) 
Forwarded: no
Last-Update: 2022-01-19

---

--- libvmime-0.9.2.orig/src/vmime/charsetConverter_icu.cpp
+++ libvmime-0.9.2/src/vmime/charsetConverter_icu.cpp
@@ -359,7 +359,7 @@ void charsetFilteredOutputStream_icu::wr
 		toErr = U_ZERO_ERROR;
 
 		ucnv_toUnicode(m_from, &uniTarget, uniTargetLimit,
-		   &uniSource, uniSourceLimit, NULL, /* flush */ FALSE, &toErr);
+		   &uniSource, uniSourceLimit, NULL, /* flush */ false, &toErr);
 
 		if (U_FAILURE(toErr) && toErr != U_BUFFER_OVERFLOW_ERROR)
 		{
@@ -396,7 +396,7 @@ void charsetFilteredOutputStream_icu::wr
 			fromErr = U_ZERO_ERROR;
 
 			ucnv_fromUnicode(m_to, &cpTarget, cpTargetLimit,
-			 &cpSource, cpSourceLimit, NULL, /* flush */ FALSE, &fromErr);
+			 &cpSource, cpSourceLimit, NULL, /* flush */ false, &fromErr);
 
 			if (fromErr != U_BUFFER_OVERFLOW_ERROR && U_FAILURE(fromErr))
 			{
@@ -448,7 +448,7 @@ void charsetFilteredOutputStream_icu::fl
 		toErr = U_ZERO_ERROR;
 
 		ucnv_toUnicode(m_from, &uniTarget, uniTargetLimit,
-		   &uniSource, uniSourceLimit, NULL, /* flush */ TRUE, &toErr);
+		   &uniSource, uniSourceLimit, NULL, /* flush */ true, &toErr);
 
 		if (U_FAILURE(toErr) && toErr != U_BUFFER_OVERFLOW_ERROR)
 		{
@@ -476,7 +476,7 @@ void charsetFilteredOutputStream_icu::fl
 			fromErr = U_ZERO_ERROR;
 
 			ucnv_fromUnicode(m_to, &cpTarget, cpTargetLimit,
-			 &cpSource, cpSourceLimit, NULL, /* flush */ TRUE, &fromErr);
+			 &cpSource, cpSourceLimit, NULL, /* flush */ true, &fromErr);
 
 			if (fromErr != U_BUFFER_OVERFLOW_ERROR && U_FAILURE(fromErr))
 			{

Bug#997478: pyls-black: diff for NMU version 0.4.6-3.1

[Adrian Bunk]

Control: tags 997478 + patch
Control: tags 997478 + pending

Dear maintainer,

I've prepared an NMU for pyls-black (versioned as 0.4.6-3.1) and 
uploaded it to DELAYED/15. Please feel free to tell me if I should 
cancel it.

cu
Adrian
diff -Nru pyls-black-0.4.6/debian/changelog pyls-black-0.4.6/debian/changelog
--- pyls-black-0.4.6/debian/changelog	2021-02-05 11:19:34.0 +0200
+++ pyls-black-0.4.6/debian/changelog	2022-01-19 19:12:45.0 +0200
@@ -1,3 +1,11 @@
+pyls-black (0.4.6-3.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Add upstream fix for test failure with new Black.
+(Closes: #997478)
+
+ -- Adrian Bunk   Wed, 19 Jan 2022 19:12:45 +0200
+
 pyls-black (0.4.6-3) unstable; urgency=medium
 
   * Fix Build-Depends
diff -Nru pyls-black-0.4.6/debian/patches/0001-Fix-test-failure-with-black-21.4b0-39.patch pyls-black-0.4.6/debian/patches/0001-Fix-test-failure-with-black-21.4b0-39.patch
--- pyls-black-0.4.6/debian/patches/0001-Fix-test-failure-with-black-21.4b0-39.patch	1970-01-01 02:00:00.0 +0200
+++ pyls-black-0.4.6/debian/patches/0001-Fix-test-failure-with-black-21.4b0-39.patch	2022-01-19 19:11:25.0 +0200
@@ -0,0 +1,65 @@
+From 4a2780358c2827b2b1598e9e60365f0d5c9a27a4 Mon Sep 17 00:00:00 2001
+From: Mathis 
+Date: Sat, 5 Jun 2021 06:40:55 +0800
+Subject: Fix test failure with black 21.4b0+ (#39)
+
+Inline PY36_VERSIONS because black no longer exposes it.
+
+Closes #36.
+---
+ pyls_black/plugin.py | 4 +++-
+ tests/test_plugin.py | 9 +++--
+ 2 files changed, 10 insertions(+), 3 deletions(-)
+
+diff --git a/pyls_black/plugin.py b/pyls_black/plugin.py
+index 407802f..dc5d482 100644
+--- a/pyls_black/plugin.py
 b/pyls_black/plugin.py
+@@ -4,6 +4,8 @@ import black
+ import toml
+ from pyls import hookimpl
+ 
++_PY36_VERSIONS = {black.TargetVersion[v] for v in ["PY36", "PY37", "PY38", "PY39"]}
++
+ 
+ @hookimpl(tryfirst=True)
+ def pyls_format_document(document):
+@@ -97,7 +99,7 @@ def load_config(filename: str) -> Dict:
+ black.TargetVersion[x.upper()] for x in file_config["target_version"]
+ )
+ elif file_config.get("py36"):
+-target_version = black.PY36_VERSIONS
++target_version = _PY36_VERSIONS
+ else:
+ target_version = set()
+ 
+diff --git a/tests/test_plugin.py b/tests/test_plugin.py
+index f943b16..e722dba 100644
+--- a/tests/test_plugin.py
 b/tests/test_plugin.py
+@@ -8,7 +8,12 @@ import pytest
+ from pyls import uris
+ from pyls.workspace import Document, Workspace
+ 
+-from pyls_black.plugin import load_config, pyls_format_document, pyls_format_range
++from pyls_black.plugin import (
++_PY36_VERSIONS,
++load_config,
++pyls_format_document,
++pyls_format_range,
++)
+ 
+ here = Path(__file__).parent
+ fixtures_dir = here / "fixtures"
+@@ -191,7 +196,7 @@ def test_load_config_target_version():
+ def test_load_config_py36():
+ config = load_config(str(fixtures_dir / "py36" / "example.py"))
+ 
+-assert config["target_version"] == black.PY36_VERSIONS
++assert config["target_version"] == _PY36_VERSIONS
+ 
+ 
+ def test_load_config_defaults():
+-- 
+2.20.1
+
diff -Nru pyls-black-0.4.6/debian/patches/series pyls-black-0.4.6/debian/patches/series
--- pyls-black-0.4.6/debian/patches/series	2021-02-05 11:19:34.0 +0200
+++ pyls-black-0.4.6/debian/patches/series	2022-01-19 19:12:45.0 +0200
@@ -1 +1,2 @@
 suppress-post-install-tests.patch
+0001-Fix-test-failure-with-black-21.4b0-39.patch

Bug#979375: backuppc: Version 4 doesn't manage accents correctly.

[J. Fernando LAGRANGE]

Hello,

Do you use rsync as Xfer method ?


I tried to reproduce with a fresh backuppc 4.4.0-3 installation on a 
Debian Bullseye installation and rsync backup went smoothly with 
"Vid\x{e9}os" in the config file !



(I am sorry, I do not know how to get all "System Information" from my 
BackupPC server to tell bts.)


Regards,
Fernando


On 05/01/2021 22:25, Ghent wrote:

Package: backuppc
Version: 4.4.0-2
Severity: important
Tags: upstream

Dear Maintainer,

The web interface doesn't correctly manage accents in BackupFilesOnly or 
BackupFilesExclude.
If I put the word "Vidéos", it saves "Vid\x{e9}os" in the config file and 
doesn't detect the folder during backup.
If I write "Vidéos" directly in the config file, the web interface displays 
"Vidéos" but it detects correctly the folder during backup.

-- System Information:
Debian Release: bullseye/sid
   APT prefers stable-updates
   APT policy: (950, 'stable-updates'), (950, 'testing'), (950, 'stable'), 
(180, 'unstable'), (60, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

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

Versions of packages backuppc depends on:
ii  adduser3.118
ii  apache2 [httpd]2.4.46-2
ii  apache2-utils  2.4.46-2
ii  backuppc-rsync 3.1.3.0-1
ii  bzip2  1.0.8-4
ii  debconf [debconf-2.0]  1.5.74
ii  exim4  4.94-9
ii  exim4-daemon-light [mail-transport-agent]  4.94-9+b1
ii  init-system-helpers1.60
ii  iputils-ping   3:20200821-2
ii  libarchive-zip-perl1.68-1
ii  libbackuppc-xs-perl0.62-1+b1
ii  libc6  2.31-6
ii  libcgi-pm-perl 4.51-1
pn  libdigest-md5-perl 
ii  libfile-listing-perl   6.14-1
ii  libtime-parsedate-perl 2015.103-3
ii  lsb-base   11.1.0
ii  perl [libio-compress-perl] 5.32.0-6
ii  ucf3.0043

Versions of packages backuppc recommends:
ii  libio-dirent-perl0.05-1+b9
ii  openssh-client [ssh-client]  1:8.4p1-3
ii  rrdtool  1.7.2-3+b7
ii  samba-common-bin 2:4.13.2+dfsg-3
ii  smbclient2:4.13.2+dfsg-3

Versions of packages backuppc suggests:
pn  certbot | acme-tiny | acmetool | dehydrated | lacme | lecm |   
ii  elinks [www-browser]   0.13.2-1+b1
ii  epiphany-browser [www-browser] 3.38.2-1
ii  firefox [www-browser]  84.0-3
pn  libscgi-perl   
ii  links [www-browser]2.21-1
ii  links2 [www-browser]   2.21-1
ii  lynx [www-browser] 2.9.0dev.6-1
ii  midori [www-browser]   7.0-2.1
ii  par2   0.8.1-1
ii  rsync  3.2.3-3
ii  w3m [www-browser]  0.5.3-38+b1

-- Configuration Files:
/etc/backuppc/apache.conf changed [not included]
/etc/backuppc/config.pl [Errno 13] Permission non accordée: 
'/etc/backuppc/config.pl'
/etc/backuppc/hosts [Errno 13] Permission non accordée: '/etc/backuppc/hosts'
/etc/default/backuppc changed [not included]

-- debconf information excluded


--
J. Fernando Lagrange
PROBESYS - Spécialistes OpenSource
9 rue de chamrousse
38100 Grenoble
Tel : 09 74 76 47 86
site web : https://www.probesys.com

Bug#1003152: postfix: should provide (document if not cleanly doable) a way to restart postfix if /etc/resolv.conf changes

[Vincent Lefevre]

On 2022-01-18 18:43:55 -0500, Scott Kitterman wrote:
> I have committed a systemd path unit based solution to git (I assume non-
> systemd users can continue to use resolvconf).  I don't have a good way to 
> test it, since I don't currently have an unstable system and systemd doesn't 
> mix well with chroots.  I manually installed, enabled, and started the new 
> service files on a stable systems and they worked.
> 
> I would appreciate any testing before I upload this (or after, I guess).

I could check that after connecting to a different network,
the /etc/resolv.conf file in the chroot is updated and postfix
is reloaded.

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

Bug#990428: Add fixed package to stable?

[Jörn Heissler]

Hello,

could the fixed version 2.13 please be added to stable/bullseye?
So far it appears to work for me; 2.12 doesn't.

Cheers


signature.asc
Description: PGP signature

Bug#1004037: src:plink2: fails to migrate to testing for too long: autopkgtest regression

[Paul Gevers]

Source: plink2
Version: 2.00~a3-210816+dfsg-1
Severity: serious
Control: close -1 2.00~a3-211011+dfsg-1
Tags: sid bookworm
User: release.debian@packages.debian.org
Usertags: out-of-sync
Control: block -1 by 1000782

Dear maintainer(s),

The Release Team considers packages that are out-of-sync between testing 
and unstable for more than 60 days as having a Release Critical bug in 
testing [1]. Your package src:plink2 has been trying to migrate for 61 
days [2]. Hence, I am filing this bug.


If a package is out of sync between unstable and testing for a longer 
period, this usually means that bugs in the package in testing cannot be 
fixed via unstable. Additionally, blocked packages can have impact on 
other packages, which makes preparing for the release more difficult. 
Finally, it often exposes issues with the package and/or
its (reverse-)dependencies. We expect maintainers to fix issues that 
hamper the migration of their package in a timely manner.


This bug will trigger auto-removal when appropriate. As with all new 
bugs, there will be at least 30 days before the package is auto-removed.


I have immediately closed this bug with the version in unstable, so if 
that version or a later version migrates, this bug will no longer affect 
testing. I have also tagged this bug to only affect sid and bookworm, so 
it doesn't affect (old-)stable.


If you believe your package is unable to migrate to testing due to 
issues beyond your control, don't hesitate to contact the Release Team.


Paul

[1] https://lists.debian.org/debian-devel-announce/2020/02/msg5.html
[2] https://qa.debian.org/excuses.php?package=plink2



OpenPGP_signature
Description: OpenPGP digital signature

Bug#1004038: AppArmor: cannot save files in enforced mode (again)

[Vincas Dargis]

Package: libreoffice-common
Version: 1:7.3.0~rc2-2
Severity: normal
Tags: upstream

Dear Maintainer,

Looks like bug #905442 is back. We need rule with eight (and more) question
marks:

type=AVC msg=audit(1642615553.674:2636): apparmor="DENIED"
operation="mknod" profile="libreoffice-soffice"
name="/home/vincas/Darbastalis/lu7600dk8g.tmp" pid=7600
comm="soffice.bin" requested_mask="c" denied_mask="c" fsuid=1000
ouid=1000FSUID="vincas" OUID="vincas"

This one rule should the trick:

owner @{libo_user_dirs}/{,**/}lu{,?,??,???,}.tmp rwk,

It would be nice to find code that generates these temporaries and see
what range is currently used...

-- Package-specific info:

-- System Information:
Debian Release: bookworm/sid
  APT prefers unstable-debug
  APT policy: (500, 'unstable-debug'), (500, 'unstable'), (1, 
'experimental-debug'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

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

Versions of packages libreoffice-common depends on:
ii  libnumbertext-data 1.0.8-1
ii  libreoffice-style-colibre  1:7.3.0~rc2-2
ii  ucf3.0043
ii  ure1:7.3.0~rc2-2

Versions of packages libreoffice-common recommends:
ii  apparmor3.0.3-6
ii  fonts-liberation2   2.1.5-1
ii  libexttextcat-data  3.4.5-1
ii  poppler-data0.4.11-1
ii  python3-uno 1:7.3.0~rc2-2
ii  xdg-utils   1.1.3-4.1

Versions of packages libreoffice-common suggests:
ii  libreoffice-style-breeze [libreoffice-style]   1:7.3.0~rc2-2
ii  libreoffice-style-colibre [libreoffice-style]  1:7.3.0~rc2-2

Versions of packages python3-uno depends on:
ii  libc62.33-3
ii  libgcc-s111.2.0-14
ii  libpython3.9 3.9.10-1
ii  libreoffice-core 1:7.3.0~rc2-2
ii  libstdc++6   11.2.0-14
ii  libuno-cppu3 1:7.3.0~rc2-2
ii  libuno-cppuhelpergcc3-3  1:7.3.0~rc2-2
ii  libuno-sal3  1:7.3.0~rc2-2
ii  libuno-salhelpergcc3-3   1:7.3.0~rc2-2
ii  python3  3.9.8-1
ii  python3.93.9.10-1
ii  ucf  3.0043
ii  uno-libs-private 1:7.3.0~rc2-2

-- Configuration Files:
/etc/apparmor.d/usr.lib.libreoffice.program.oosplash changed:
profile libreoffice-oosplash /usr/lib/libreoffice/program/oosplash {
  #include 
  #include 
  /etc/libreoffice/ r,
  /etc/libreoffice/**   r,
  /etc/passwd   r,
  /etc/nsswitch.confr,
  /run/nscd/passwd  r,
  /sys/devices/{virtual,pci[0-9]*}/**/queue/rotational  r, # for isRotational() 
in desktop/unx/source/pagein.c
  /usr/lib{,32,64}/ure/bin/javaldx  rmpux,
  /usr/share/libreoffice/program/*  r,
  /usr/lib/libreoffice/program/**   r,
  /usr/lib/libreoffice/program/soffice.bin rmpx,
  /usr/lib/libreoffice/program/javaldx rmpux,
  owner @{HOME}/.Xauthority r,
  owner @{HOME}/.config/libreoffice{,dev}/?/user/uno_packages/cache/log.txt rw,
  unix peer=(addr=@/tmp/.ICE-unix/* label=unconfined),
  unix peer=(addr=@/tmp/.X11-unix/* label=unconfined),
}

/etc/apparmor.d/usr.lib.libreoffice.program.soffice.bin changed:
@{libreoffice_ext} = [tT][xX][tT]
@{libreoffice_ext} += {,f,F}[oO][dDtT][tTsSpPbBgGfF]
@{libreoffice_ext} += [xX][mMsS][lL]
@{libreoffice_ext} += [pP][dD][fF]
@{libreoffice_ext} += [uU][oO][fFtTsSpP]
@{libreoffice_ext} += {,x,X}[hH][tT][mM]{,l,L}
@{libreoffice_ext} += [eE][pP][uU][bB]
@{libreoffice_ext} += [pP][sS]
@{libreoffice_ext} += [jJ][pP][gG]
@{libreoffice_ext} += [jJ][pP][eE][gG]
@{libreoffice_ext} += [pP][nN][gG]
@{libreoffice_ext} += [sS][vV][gG]
@{libreoffice_ext} += [sS][vV][gG][zZ]99251
@{libreoffice_ext} += [tT][iI][fF]
@{libreoffice_ext} += [tT][iI][fF][fF]
@{libreoffice_ext} += [dD][oO][cCtT]{,x,X}
@{libreoffice_ext} += [rR][tT][fF]
@{libreoffice_ext} += [xX][lL][sStT]{,x,X,m,M}
@{libreoffice_ext} += [xX][lL][wW]
@{libreoffice_ext} += [dD][iIbB][fF]
@{libreoffice_ext} += [cCtT][sS][vV]
@{libreoffice_ext} += [sS][lL][kK]
@{libreoffice_ext} += [pP][pP][tTsS]{,x,X}
@{libreoffice_ext} += [pP][oO][tT]{,m,M}
@{libreoffice_ext} += [pP][sS][dD]
@{libreoffice_ext} += [mM][mM][lL]
@{libo_user_dirs} = @{HOME} /mnt /media
profile libreoffice-soffice /usr/lib/libreoffice/program/soffice.bin {
  #include 
  #include 
  #include 
  #include 
  #include 
  #include 
  #include 
  #include 
  #include 
  #include 
  #include 
  #include 
  #include 
  #include 
  #include 
  #include 
  #include 
  #include 
  #List directories for file browser
  / r,
  /**/  r,
  owner @{libo_user_dirs}/**

Bug#1004040: webcam Live! Cam Sync HD VF0770 unusable with linux 5.15.5 (working with at least 5.10)

[Mathieu Roy]

Package: src:linux
Version: 5.15.5-2
Severity: normal


Hello,

With any computer running 5.15.5, I cannot access the webcam Live! Cam 
Sync HD VF0770


The logs stops at
[  490.602056] usb 1-11: USB disconnect, device number 8
[  491.872365] usb 1-11: new high-speed USB device number 9 using xhci_hcd
[  492.114279] usb 1-11: New USB device found, idVendor=041e, 
idProduct=4095, bcdDevice=20.20
[  492.114285] usb 1-11: New USB device strings: Mfr=3, Product=1, 
SerialNumber=2

[  492.114289] usb 1-11: Product: Live! Cam Sync HD VF0770
[  492.114292] usb 1-11: Manufacturer:
and /dev/video* arent created, making the webcam unusable.



While,  with 5.10.9 kernel (and exact same hardware and installed software)

[  519.376025] usb 1-11: new high-speed USB device number 10 using xhci_hcd
[  519.617723] usb 1-11: New USB device found, idVendor=041e, 
idProduct=4095, bcdDevice=20.20
[  519.617730] usb 1-11: New USB device strings: Mfr=3, Product=1, 
SerialNumber=2

[  519.617734] usb 1-11: Product: Live! Cam Sync HD VF0770
[  519.617736] usb 1-11: Manufacturer: Creative Technology Ltd.
[  519.617739] usb 1-11: SerialNumber:
[  519.624350] uvcvideo: Found UVC 1.00 device Live! Cam Sync HD VF0770 
(041e:4095)
[  519.641876] input: Live! Cam Sync HD VF0770: Live! as 
/devices/pci:00/:00:14.0/usb1/1-11/1-11:1.0/input/input35


# ls /dev/video*
/dev/video0  /dev/video1

# v4l2-ctl --list-devices
Live! Cam Sync HD VF0770: Live! (usb-:00:14.0-11):
    /dev/video0
    /dev/video1
    /dev/media0

and webcam works as expected

This webcam supported since 2.6.26
https://linux-hardware.org/?id=usb:041e-4095

I found at least one post that is likely related (1 month old, 5.15 
kernel, working with Ubuntu 20.04 running earlier kernels)

https://www.reddit.com/r/archlinux/comments/r9l32r/live_cam_sync_hd_usb_webcam_not_working/


-- Package-specific info:
** Version:
Linux version 5.15.0-2-amd64 (debian-ker...@lists.debian.org) (gcc-11 
(Debian 11.2.0-13) 11.2.0, GNU ld (GNU Binutils for Debian) 2.37) #1 SMP 
Debian 5.15.5-2 (2021-12-18)


** Command line:

BOOT_IMAGE=/boot/vmlinuz-5.15.0-2-amd64 
root=UUID=b444fc5f-bc92-46b0-a1d5-fcec14615eb4 ro 
rd.luks.key=/:UUID=299ec5b3-9e0d-4391-ac0b-c7505e9809c3 
acpi_enforce_resources=lax quiet


** Tainted: POE (12289)
 * proprietary module was loaded
 * externally-built ("out-of-tree") module was loaded
 * unsigned module was loaded

** Kernel log:
Unable to read kernel log; any relevant messages should be attached

** Model information
sys_vendor: Gigabyte Technology Co., Ltd.
product_name: Z390 GAMING SLI
product_version: Default string
chassis_vendor: Default string
chassis_version: Default string
bios_vendor: American Megatrends Inc.
bios_version: F10k
board_vendor: Gigabyte Technology Co., Ltd.
board_name: Z390 GAMING SLI-CF
board_version: Default string

** Loaded modules:
mptcp_diag
tcp_diag
udp_diag
raw_diag
inet_diag
unix_diag
af_packet_diag
netlink_diag
nvidia_uvm(POE)
ufs
qnx4
hfsplus
hfs
cdrom
minix
vfat
msdos
fat
jfs
xfs
cfg80211
rfkill
nfnetlink
cpufreq_powersave
cpufreq_ondemand
cpufreq_conservative
cpufreq_userspace
binfmt_misc
uinput
drivetemp
it87
hwmon_vid
loop
cpuid
msr
ecryptfs
nvidia_drm(POE)
drm_kms_helper
cec
rc_core
nvidia_modeset(POE)
parport_pc
ppdev
lp
parport
fuse
nfsd
auth_rpcgss
nfs_acl
nfs
lockd
grace
sunrpc
sha512_ssse3
sha512_generic
cmac
nls_utf8
cifs
cifs_arc4
cifs_md4
dns_resolver
fscache
netfs
intel_rapl_msr
mei_hdcp
intel_rapl_common
x86_pkg_temp_thermal
intel_powerclamp
coretemp
snd_sof_pci_intel_cnl
kvm_intel
snd_sof_intel_hda_common
soundwire_intel
soundwire_generic_allocation
soundwire_cadence
snd_sof_intel_hda
snd_sof_pci
snd_sof_xtensa_dsp
kvm
snd_sof
soundwire_bus
irqbypass
snd_soc_skl
rapl
intel_cstate
snd_soc_hdac_hda
intel_uncore
snd_hda_ext_core
pcspkr
snd_soc_sst_ipc
snd_soc_sst_dsp
intel_wmi_thunderbolt
snd_soc_acpi_intel_match
wmi_bmof
snd_soc_acpi
mxm_wmi
snd_soc_core
iTCO_wdt
intel_pmc_bxt
iTCO_vendor_support
watchdog
ee1004
snd_compress
mei_me
mei
snd_hda_codec_realtek
snd_hda_codec_generic
ledtrig_audio
snd_hda_codec_hdmi
joydev
snd_usb_audio
xpad
ff_memless
evdev
nvidia(POE)
snd_hda_intel
snd_usbmidi_lib
snd_intel_dspcfg
snd_rawmidi
snd_intel_sdw_acpi
snd_seq_device
snd_hda_codec
mc
snd_hda_core
snd_hwdep
snd_pcm
snd_timer
snd
drm
soundcore
intel_pch_thermal
intel_pmc_core
acpi_pad
button
ext4
crc16
mbcache
jbd2
crc32c_generic
btrfs
zstd_compress
dm_crypt
dm_mod
hid_plantronics
raid10
raid456
async_raid6_recov
async_memcpy
async_pq
async_xor
async_tx
xor
raid6_pq
libcrc32c
raid1
raid0
multipath
linear
md_mod
hid_generic
usbhid
hid
sg
sd_mod
crc32_pclmul
crc32c_intel
ghash_clmulni_intel
ahci
libahci
nvme
xhci_pci
libata
aesni_intel
e1000e
xhci_hcd
crypto_simd
cryptd
ptp
nvme_core
r8169
pps_core
scsi_mod
usbcore
realtek
mdio_devres
t10_pi
i2c_i801
crc_t10dif
i2c_smbus
libphy
crct10dif_generic
crct10dif_pclmul
crct10dif_common
scsi_common
usb_common
fan
wmi
video

** PCI devices:
00:00.0 Host bridge [0600]: Inte

Bug#909436: libdrm: FTBFS on hurd-i386 (#909436, updated and new patches)

[Svante Signell]

On Tue, 2022-01-18 at 17:46 +0100, Svante Signell wrote:
> 
> The added file can be incorporated in libdrm-tests.install file with 
> using dh_exec and making libdrm-tests.install executable.
> +#! /usr/bin/dh-exec
> +[hurd-any] usr/bin/amdgpu_test

Add to this a build-dependency of dh-exec needed in debian/control.

> Alternately (and simpler) a separate file for Hurd can be created solving the
> same problem. Attached is a patch creating that file: libdrm-
> tests.install.hurd.diff  

Another simple solution is to use a wildcard:
--- a/debian/libdrm-tests.install   2021-12-15 16:55:18.0 +0100
+++ b/debian/libdrm-tests.install   2022-01-12 18:28:35.0 +0100
@@ -1,3 +1,3 @@
-usr/bin/amdgpu_stress
+usr/bin/amdgpu_*
 usr/bin/drmdevice
 usr/bin/modetest

Thanks again!

Bug#947334: lxc-checkpoint needs the criu package

[Salvatore Bonaccorso]

Hi Pierre,

On Sat, Sep 05, 2020 at 12:35:13AM +0200, Pierre-Elliott Bécue wrote:
> Cc-ing Salvatore,
> 
> Le mercredi 25 décembre 2019 à 08:11:11+0900, Ryutaroh Matsumoto a écrit :
> > Package: lxc
> > Version: 1:3.1.0+really3.0.4-2
> > Severity: normal
> > 
> > Dear Maintainer,
> > 
> > lxc-checkpoint command needs "criu", which is only available
> > in Debian experimental now.
> > But "criu" is neither suggested nor recommended.
> > Some kind of dependency by lxc seems necessary.
> 
> I can't depend on criu or I won't be able to have lxc installed in any
> version of Debian apart from unstable. Indeed, criu is currently
> voluntarily blocked from entering testing because the package is not
> stable enough yet.

FWIW, I lifted the blocking bug and criu is in testing. I'm not sure
we can give a guarantee that it will be in bookworm, but I wanted to
inform you about the fact that the blocking bug for now is gone.

Regards,
Salvatore

Bug#1004041: gwcs FTBFS

[Adrian Bunk]

Source: gwcs
Version: 0.18.0-1
Severity: serious
Tags: ftbfs
Control: block 1001238 by -1

https://buildd.debian.org/status/fetch.php?pkg=gwcs&arch=all&ver=0.18.0-1&stamp=1642613373&raw=0

...
 ERRORS 
_ ERROR collecting .pybuild/cpython3_3.9_gwcs/build/gwcs/extension.py __
gwcs/extension.py:8: in 
from .converters.selector import (
gwcs/converters/selector.py:11: in 
from asdf_astropy.converters.transform.core import TransformConverterBase
E   ModuleNotFoundError: No module named 'asdf_astropy'
_ ERROR collecting .pybuild/cpython3_3.9_gwcs/build/gwcs/converters/geometry.py 
_
gwcs/converters/geometry.py:5: in 
from asdf_astropy.converters.transform.core import TransformConverterBase
E   ModuleNotFoundError: No module named 'asdf_astropy'
_ ERROR collecting .pybuild/cpython3_3.9_gwcs/build/gwcs/converters/selector.py 
_
gwcs/converters/selector.py:11: in 
from asdf_astropy.converters.transform.core import TransformConverterBase
E   ModuleNotFoundError: No module named 'asdf_astropy'
_ ERROR collecting 
.pybuild/cpython3_3.9_gwcs/build/gwcs/converters/spectroscopy.py _
gwcs/converters/spectroscopy.py:6: in 
from asdf_astropy.converters.transform.core import (
E   ModuleNotFoundError: No module named 'asdf_astropy'
_ ERROR collecting 
.pybuild/cpython3_3.9_gwcs/build/gwcs/converters/tests/test_transforms.py _
gwcs/converters/tests/test_transforms.py:7: in 
from asdf_astropy.converters.transform.tests.test_transform import (
E   ModuleNotFoundError: No module named 'asdf_astropy'
_ ERROR collecting 
.pybuild/cpython3_3.9_gwcs/build/gwcs/converters/tests/test_transforms.py _
ImportError while importing test module 
'/<>/.pybuild/cpython3_3.9_gwcs/build/gwcs/converters/tests/test_transforms.py'.
Hint: make sure your test modules/packages have valid Python names.
Traceback:
/usr/lib/python3.9/importlib/__init__.py:127: in import_module
return _bootstrap._gcd_import(name[level:], package, level)
gwcs/converters/tests/test_transforms.py:7: in 
from asdf_astropy.converters.transform.tests.test_transform import (
E   ModuleNotFoundError: No module named 'asdf_astropy'
_ ERROR collecting 
.pybuild/cpython3_3.9_gwcs/build/gwcs/converters/tests/test_wcs.py _
gwcs/converters/tests/test_wcs.py:15: in 
from asdf_astropy.converters.transform.tests.test_transform import (  # 
noqa: E402
E   ModuleNotFoundError: No module named 'asdf_astropy'
_ ERROR collecting 
.pybuild/cpython3_3.9_gwcs/build/gwcs/converters/tests/test_wcs.py _
ImportError while importing test module 
'/<>/.pybuild/cpython3_3.9_gwcs/build/gwcs/converters/tests/test_wcs.py'.
Hint: make sure your test modules/packages have valid Python names.
Traceback:
/usr/lib/python3.9/importlib/__init__.py:127: in import_module
return _bootstrap._gcd_import(name[level:], package, level)
gwcs/converters/tests/test_wcs.py:15: in 
from asdf_astropy.converters.transform.tests.test_transform import (  # 
noqa: E402
E   ModuleNotFoundError: No module named 'asdf_astropy'
_ ERROR collecting .pybuild/cpython3_3.9_gwcs/build/gwcs/tests/test_geometry.py 
_
gwcs/tests/test_geometry.py:10: in 
from asdf_astropy.converters.transform.tests.test_transform import (
E   ModuleNotFoundError: No module named 'asdf_astropy'
_ ERROR collecting .pybuild/cpython3_3.9_gwcs/build/gwcs/tests/test_geometry.py 
_
ImportError while importing test module 
'/<>/.pybuild/cpython3_3.9_gwcs/build/gwcs/tests/test_geometry.py'.
Hint: make sure your test modules/packages have valid Python names.
Traceback:
/usr/lib/python3.9/importlib/__init__.py:127: in import_module
return _bootstrap._gcd_import(name[level:], package, level)
gwcs/tests/test_geometry.py:10: in 
from asdf_astropy.converters.transform.tests.test_transform import (
E   ModuleNotFoundError: No module named 'asdf_astropy'
=== warnings summary ===
../../../../../../usr/lib/python3/dist-packages/astropy/wcs/wcsapi/sliced_low_level_wcs.py:6
  /usr/lib/python3/dist-packages/astropy/wcs/wcsapi/sliced_low_level_wcs.py:6: 
AstropyDeprecationWarning: SlicedLowLevelWCS has been moved to 
astropy.wcs.wcsapi.wrappers.sliced_wcs.SlicedLowLevelWCS, or can be imported 
from astropy.wcs.wcsapi.
warnings.warn(

-- Docs: https://docs.pytest.org/en/stable/warnings.html
=== short test summary info 
ERROR gwcs/extension.py - ModuleNotFoundError: No module named 'asdf_astropy'
ERROR gwcs/converters/geometry.py - ModuleNotFoundError: No module named 'asd...
ERROR gwcs/converters/selector.py - ModuleNotFoundError: No module named 'asd...
ERROR gwcs/converters/spectroscopy.py - ModuleNotFoundError: No module named ...
ERROR gwcs/converters/tests/test_transforms.py - ModuleNotFoundError: No modu...
ERROR gwcs/converters/tests/test_transforms.py
ERROR gwcs/converters/tests/test_wcs.py - ModuleNotFoundError: No module name...
E

Bug#1004041: gwcs FTBFS

[Ole Streicher]

Control: block -1 by 1003331

This is because the new gwcs needs asdf-wcs-schemas, which is in the NEW 
queue, but not accepted yet.

Bug#947334: lxc-checkpoint needs the criu package

[Pierre-Elliott Bécue]

Le 19 janvier 2022 20:55:40 GMT+01:00, Salvatore Bonaccorso  
a écrit :
>Hi Pierre,
>
>On Sat, Sep 05, 2020 at 12:35:13AM +0200, Pierre-Elliott Bécue wrote:
>> Cc-ing Salvatore,
>> 
>> Le mercredi 25 décembre 2019 à 08:11:11+0900, Ryutaroh Matsumoto a écrit :
>> > Package: lxc
>> > Version: 1:3.1.0+really3.0.4-2
>> > Severity: normal
>> > 
>> > Dear Maintainer,
>> > 
>> > lxc-checkpoint command needs "criu", which is only available
>> > in Debian experimental now.
>> > But "criu" is neither suggested nor recommended.
>> > Some kind of dependency by lxc seems necessary.
>> 
>> I can't depend on criu or I won't be able to have lxc installed in any
>> version of Debian apart from unstable. Indeed, criu is currently
>> voluntarily blocked from entering testing because the package is not
>> stable enough yet.
>
>FWIW, I lifted the blocking bug and criu is in testing. I'm not sure
>we can give a guarantee that it will be in bookworm, but I wanted to
>inform you about the fact that the blocking bug for now is gone.
>
>Regards,
>Salvatore
>

Thanks !! 
--
Pierre-Elliott Bécue
From my phone

Bug#946152: iptables-dev vs libiptc-dev dependency in collectd

[Bernd Zeimetz]

Hi,

sorry for the late reply!

On Fri, 2020-03-06 at 18:11 -0700, Antonio Russo wrote:
> 
> Because that is not the case, the pkg-config calls to get the path to
> libip4tc{.h,.so} libip6tc{.h,.so} and libiptc.h fail. You can get around
> that with the trivial patch I've attached.


Unfortunately the attached patch is for xvfb - and not collectd.
If possible just send an MR on salsa.

Bernd

-- 
 Bernd ZeimetzDebian GNU/Linux Developer
 http://bzed.dehttp://www.debian.org
 GPG Fingerprint: ECA1 E3F2 8E11 2432 D485  DD95 EB36 171A 6FF9 435F

Bug#1004024: RFS: fig2sxd/0.23-2 -- convert XFig files to OpenOffice.org format

[Bastian Germann]

On Wed, 19 Jan 2022 14:55:34 +0100 acfbuer...@googlemail.com wrote:

Changes since the last upload:

fig2sxd (0.23-2) unstable; urgency=low

* New upstream version.
* Improved debian packaging, updated compat to 13 (see #965518).


A new upstream version never has revision -2.

Bug#1003865: GPG error: http://deb.debian.org/debian sid InRelease: The following signatures were invalid: BADSIG 648ACFD622F3D138 Debian Archive Automatic Signing Key (10/buster)

[Andreas Beckmann]

On Wed, 19 Jan 2022 02:47:56 +0530 Pirate Praveen 
 wrote:
I have seen at least one forum posting on the same error when searching for it so its likely more common 
 https://www.nixcraft.com/t/signatures-were-invalid-badsig-648acfd622f3d138-debian-archive-automatic-signing-key-10-buster/4025


May be related to apt-cacher-ng (though I tried with apt-cacher-ng disabled 
without fixing this issue).


When I encounter similar errors from time to time (once a year or so) I 
consider them as "caching artefacts" and fix them by having apt 
"reinitialize" the corresponding package source: first comment the line 
in sources.list (or rename the snippet in sources.list.d to *.list.off), 
run apt-get update (or whatever you like instead) to "forget" the 
source, enable it again, apt-get update again and the error is gone.


Actually I cannot remember having ever seen that as a piuparts failure 
(and that does a lot of apt-get update), only once in a while on my main 
machine which has everything from oldoldstable to experimental with 4 
foreign architectures available ...


Andreas

Bug#976811: [pkg-php-pear] Bug#976811: transition: php8.1

[Paul Gevers]

Hi Bryce,

On 19-01-2022 10:28, Bryce Harrington wrote:


With [4] applied, I'm seeing the following dumped on armhf:

## https://autopkgtest.ubuntu.com/packages/m/mediawiki/jammy/armhf
cat: /var/log/mediawiki/error.log: No such file or directory
2022-01-19 09:16:57 autopkgtest-lxd-eeoxik autopkgtestwiki: 
[e33d1ec89af515673078437e] /mediawiki/index.php/Main_Page   PHP Fatal Error 
from line 110 of /usr/share/mediawiki/includes/json/FormatJson.php: Maximum 
execution time of 30 seconds exceeded
#0 [internal function]: MWExceptionHandler::handleFatalError()
#1 {main}
2022-01-19 09:17:27 autopkgtest-lxd-eeoxik autopkgtestwiki: 
[1284cbae5a84eb5387f33003] /mediawiki/index.php/Main_Page   PHP Fatal Error 
from line 152 of /usr/share/mediawiki/includes/HookContainer/HookContainer.php: 
Maximum execution time of 30 seconds exceeded
#0 [internal function]: MWExceptionHandler::handleFatalError()
#1 {main}
2022-01-19 09:17:57 autopkgtest-lxd-eeoxik autopkgtestwiki: 
[31731278ed6070e946af4fbe] /mediawiki/index.php/Main_Page   PHP Fatal Error 
from line 110 of /usr/share/mediawiki/includes/json/FormatJson.php: Maximum 
execution time of 30 seconds exceeded
#0 [internal function]: MWExceptionHandler::handleFatalError()
#1 {main}
cat: /var/log/mediawiki/fatal.log: No such file or directory


As this issue seems intermittent (as mediawiki passed at one point) I 
guess you're trying to say that you think mediawiki got slower with 
php8.1? Or is this timeout new with php8.1? Obviously the code that 
fails to finish is mediawiki's code, so it doesn't seem to be a generic 
issue with php8.1 except if the timeout happens because of something 
inside php8.1. Can anybody shed a light on if it's reasonable to time 
out on what mediawiki is trying to do here. And why doesn't it happen on 
other architectures (in Debian, as far as I checked)?


Paul


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1004042: kubetail: New upstream release available (1.6.13, 2021 May 07)

[Florian Ernst]

Package: kubetail
Severity: wishlist

Dear Maintainer,

there is a new upstream release available, cf.
. It contains (among
many other things) updated autocompletion, new options
--show-color-index and --previous, and many cleanups.

Please update the package when you think it is due time.

Cheers,
Flo


signature.asc
Description: PGP signature

Bug#1004043: git-annex: test --pattern can segfault

[Benjamin Barenblat]

Package: git-annex
Version: 8.20210223-2
Severity: normal

Passing certain patterns to `git annex test -p` causes a segfault:

$ git annex test -p 'Tests.Unit Tests v8 locked.move'
error: git-annex died of signal 11

Other patterns work fine:

$ git annex test -p Tests.QuickCheck.prop_VectorClock_sane
Tests
  QuickCheck
prop_VectorClock_sane: OK
  +++ OK, passed 1 test.

All 1 tests passed (0.00s)

Running all the tests (i.e., `git annex test` without `-p`) also works
fine, and all the tests pass.

Bug#1004044: kubecolor: New upstream release available (v0.0.20, 2021 May 07)

[Florian Ernst]

Package: kubecolor
Severity: wishlist

Dear Maintainer,

there is a new upstream release available, cf.
. It contains, among
other things, keeping the exit code from kubectl, colorizing apply
result by the action, and dry run consideration, making this quite
desirable to have.

Please update the package when you think it is due time.

Cheers,
Flo


signature.asc
Description: PGP signature

Bug#1003847: binutils breaks glibc autopkgtest on ppc64el: unrecognized opcode: `vspltisb' (and others)

[John Paul Adrian Glaubitz]

Hi Aurelien!

Unfortunately, glibc no longer builds with this change on powerpc and ppc64
and kernel builds still fails on both targets:

> https://buildd.debian.org/status/fetch.php?pkg=glibc&arch=powerpc&ver=2.33-3&stamp=1642542048&raw=0
> https://buildd.debian.org/status/fetch.php?pkg=glibc&arch=ppc64&ver=2.33-3&stamp=1642542055&raw=0

> https://buildd.debian.org/status/fetch.php?pkg=linux&arch=powerpc&ver=5.15.15-1&stamp=1642579068&raw=0
> https://buildd.debian.org/status/fetch.php?pkg=linux&arch=ppc64&ver=5.15.15-1&stamp=1642578946&raw=0

Adrian

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Bug#976811: [pkg-php-pear] Bug#976811: transition: php8.1

[Paul Gevers]

Hi Ondřej,

On 18-01-2022 20:31, Paul Gevers wrote:

On 18-01-2022 19:37, Ondřej Surý wrote:
the fix is simple, it was actually cruft from before when 
uploadprogress didn’t support PHP 8.1:


https://sources.debian.org/src/php-uopz/7.1.1+6.1.2-5/debian/rules/#L3
https://sources.debian.org/src/php-gnupg/1.5.1-1/debian/rules/#L3


My NMU of php-igbinary fails to migrate to testing because you added a 
Breaks on << 3.2.6+2.0.8-6~ (where my NMU has version 3.2.6+2.0.8-5.1). 
Can you please fix this somehow?


Paul


OpenPGP_signature
Description: OpenPGP digital signature

Bug#824594: please support DPKG_ROOT in base-files' postinst

[Johannes Schauer Marin Rodrigues]

Hi Santiago,

Quoting Johannes Schauer Marin Rodrigues (2021-10-23 11:08:56)
> I just wanted to send a friendly ping about DPKG_ROOT support of base-files.
> I hope that I was able to address all your questions in my last mail to this
> bug.  If there is anything else I can do to help you?

since your last activity on this bug was more than 100 days ago, I uploaded a
NMU of base-files with the attached debdiff to DELAYED/10. As usual feel free
to cancel the NMU (or tell me to cancel it) if you disagree with my upload.

Thanks!

cheers, joschdiff -Nru base-files-12/debian/changelog base-files-12+nmu1/debian/changelog
--- base-files-12/debian/changelog	2021-08-22 19:00:00.0 +0200
+++ base-files-12+nmu1/debian/changelog	2022-01-19 21:49:23.0 +0100
@@ -1,3 +1,10 @@
+base-files (12+nmu1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Add support for DPKG_ROOT to postinst. Closes: #824594
+
+ -- Johannes Schauer Marin Rodrigues   Wed, 19 Jan 2022 21:49:23 +0100
+
 base-files (12) unstable; urgency=medium
 
   * Do not create /var/run/utmp in postinst, as /var/run is
diff -Nru base-files-12/debian/postinst.in base-files-12+nmu1/debian/postinst.in
--- base-files-12/debian/postinst.in	2021-08-22 19:00:00.0 +0200
+++ base-files-12+nmu1/debian/postinst.in	2022-01-19 21:49:23.0 +0100
@@ -1,52 +1,73 @@
 #!/bin/sh
 set -e
 
+change_owner() {
+  local owner group
+  owner=${1%:*}
+  group=${1#*:}
+  owner=$(sed -n "s/^$owner:[^:]*:\\([0-9]*\\):.*/\\1/p" "$DPKG_ROOT/etc/passwd")
+  group=$(sed -n "s/^$group:[^:]*:\\([0-9]*\\):.*/\\1/p" "$DPKG_ROOT/etc/group")
+  chown "$owner:$group" "$DPKG_ROOT$2"
+}
+
+change_mode() {
+  chmod "$1" "$DPKG_ROOT$2"
+}
+
+ensure_file_owner_mode() {
+  if [ ! -f "$DPKG_ROOT$1" ]; then
+: > "$DPKG_ROOT$1"
+  fi
+  change_owner "$2" "$1"
+  change_mode "$3" "$1"
+}
+
 install_local_dir() {
-  if [ ! -d $1 ]; then
-mkdir -p $1
+  if [ ! -d "$DPKG_ROOT$1" ]; then
+mkdir -p "$DPKG_ROOT$1"
   fi
-  if [ -f /etc/staff-group-for-usr-local ]; then
-chown root:staff $1 2> /dev/null || true
-chmod 2775 $1 2> /dev/null || true
+  if [ -f "$DPKG_ROOT/etc/staff-group-for-usr-local" ]; then
+change_owner root:staff "$1" 2>/dev/null || true
+change_mode 2775 "$1" 2> /dev/null || true
   fi
 }
 
 install_from_default() {
-  if [ ! -f $2 ]; then
-cp -p /usr/share/base-files/$1 $2
+  if [ ! -f "$DPKG_ROOT$2" ]; then
+cp -p "$DPKG_ROOT/usr/share/base-files/$1" "$DPKG_ROOT$2"
   fi
 }
 
 install_directory() {
-  if [ ! -d /$1 ]; then
-mkdir /$1
-chown root:$3 /$1
-chmod $2 /$1
+  if [ ! -d "$DPKG_ROOT/$1" ]; then
+mkdir "$DPKG_ROOT/$1"
+change_owner "root:$3" "/$1"
+change_mode "$2" "/$1"
   fi
 }
 
 migrate_directory() {
-  if [ ! -L $1 ]; then
-rmdir $1
-ln -s $2 $1
+  if [ ! -L "$DPKG_ROOT$1" ]; then
+rmdir "$DPKG_ROOT$1"
+ln -s "$2" "$DPKG_ROOT$1"
   fi
 }
 
 update_to_current_default() {
-  if [ -f $2 ]; then
-md5=`md5sum $2 | cut -f 1 -d " "`
-if grep -q "$md5" /usr/share/base-files/$1.md5sums; then
-  if ! cmp -s /usr/share/base-files/$1 $2; then
-cp -p /usr/share/base-files/$1 $2
+  if [ -f "$2" ]; then
+md5=`md5sum "$2" | cut -f 1 -d " "`
+if grep -q "$md5" "/usr/share/base-files/$1.md5sums"; then
+  if ! cmp -s "/usr/share/base-files/$1" "$2"; then
+cp -p "/usr/share/base-files/$1" "$2"
 echo Updating $2 to current default.
   fi
 fi
   fi
 }
 
-if [ ! -e /etc/dpkg/origins/default ]; then
-  if [ -e /etc/dpkg/origins/#VENDORFILE# ]; then
-ln -sf #VENDORFILE# /etc/dpkg/origins/default
+if [ ! -e "$DPKG_ROOT/etc/dpkg/origins/default" ]; then
+  if [ -e "$DPKG_ROOT/etc/dpkg/origins/#VENDORFILE#" ]; then
+ln -sf #VENDORFILE# "$DPKG_ROOT/etc/dpkg/origins/default"
   fi
 fi
 
@@ -62,8 +83,8 @@
   install_directory var/opt   755 root
   install_directory media 755 root
   install_directory var/mail 2775 mail
-  if [ ! -L /var/spool/mail ]; then
-ln -s ../mail /var/spool/mail
+  if [ ! -L "$DPKG_ROOT/var/spool/mail" ]; then
+ln -s ../mail "$DPKG_ROOT/var/spool/mail"
   fi
   install_directory run/lock 1777 root
   migrate_directory /var/run /run
@@ -79,25 +100,16 @@
   install_local_dir /usr/local/sbin
   install_local_dir /usr/local/src
   install_local_dir /usr/local/etc
-  ln -sf share/man /usr/local/man
+  ln -sf share/man "$DPKG_ROOT/usr/local/man"
 
-  if [ ! -f /var/log/wtmp ]; then
-echo -n>/var/log/wtmp
-  fi
-  if [ ! -f /var/log/btmp ]; then
-echo -n>/var/log/btmp
-  fi
-  if [ ! -f /var/log/lastlog ]; then
-echo -n>/var/log/lastlog
-  fi
-  chown root:utmp /var/log/wtmp /var/log/btmp /var/log/lastlog
-  chmod 664 /var/log/wtmp /var/log/lastlog
-  chmod 660 /var/log/btmp
+  ensure_file_owner_mode /var/log/wtmp root:utmp 664
+  ensure_file_owner_mode /var/log/btmp root:utmp 660
+  ensure_file_owner_mode /var/log/lastlog root:utmp 664
 fi
 
-if [ -d /usr/share/info ] && [ ! -f /usr/info/dir ] &&