Bug#990341: ITP: swagger-spec-validator -- Validation of Swagger specifications

[Carsten Schoenert]

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

* Package name: swagger-spec-validator
  Version : 2.7.3
  Upstream Author : core-servi...@yelp.com
Semir Patel 
Stephan Jaensch 
* URL : https://github.com/Yelp/swagger_spec_validator
* License : Apache-2.0
  Programming Lang: Python
  Description : Validation of Swagger specifications

 Swagger Spec Validator is a Python library that validates Swagger Specs
 against the Swagger 1.2
 (https://github.com/swagger-api/swagger-spec/blob/master/versions/1.2.md)
 or Swagger 2
 (https://github.com/swagger-api/swagger-spec/blob/master/versions/2.0.md)
 specification.
 The validator aims to check for full compliance with the Specification.

This package is a dependency for netbox I consider to package.

The package will get maintained within the Debian Python Team.

Bug#990340: glances: contains prebuilt javascript without source

[Johannes Schauer Marin Rodrigues]

Package: glances
Version: 3.1.5-1
Severity: serious
Justification: Policy 2.2.1

Hi,

the source package contains:

glances/outputs/static/public/glances.js
glances/outputs/static/public/glances.map.js

these files are copied into the binary package as:

/usr/lib/python3/dist-packages/glances/outputs/static/public/glances.js
/usr/lib/python3/dist-packages/glances/outputs/static/public/glances.map.js

they trigger the following lintian errors:

E source-is-missing glances/outputs/static/public/glances.js line 52292 is 
44264 characters long (>512)
E source-is-missing glances/outputs/static/public/glances.map.js line 2 is 
2631202 characters long (>512)

Don't distribute those files or build them from source.

Thanks!

cheers, josch

Bug#850258: glances: calling home?

[Johannes Schauer Marin Rodrigues]

Control: tag -1 + patch

On Thu, 22 Jun 2017 23:55:19 -0500 Daniel Echeverry  wrote:
> these connections are necessary for glances can show the Public IP Address.

but that functionality can be trivially disabled by disabling the ip module by
default using the following patch:

--- a/conf/glances.conf
+++ b/conf/glances.conf
@@ -603,3 +603,6 @@ regex=\/sbin\/init
 refresh=30
 one_line=true
 service_cmd=/usr/bin/service --status-all
+
+[ip]
+disable=True


Please consider changing the default configuration of glances to respect user's
privacy by default. The current package description reads:

> Curses-based monitoring tool
>  Glances is a curses-based monitoring tool for GNU/Linux or BSD OS.
>  Glances uses the PsUtil library to get information from your system.
>  .
>  It monitors CPU, load, memory, network bandwidth, disk I/O, disk use, 
> process.

I doubt anybody reading that expects glances to violate their privacy by making
requests to certain services on the internet that are not controlled by Debian.
Do you know who controls them? Why do you trust them? Why is this feature not
disabled by default to protect our users?

I suggest to disable the ip module by default and until then, am adding glances
to the list of privacy issues we have in Debian:

https://wiki.debian.org/PrivacyIssues

Thanks!

cheers, josch

signature.asc
Description: signature

Bug#990066: unblock: distcc/3.3.2-10+deb10u1

[Christian Marillat]

On 19 juin 2021 08:40, Christian Marillat  wrote:

> Package: release.debian.org
> Severity: normal
> User: release.debian@packages.debian.org
> Usertags: unblock
> X-Debbugs-Cc: maril...@debian.org
>
> Please unblock package distcc
>
> The Debian script update-distcc-symlinks who generate gcc/clang symlinks in
> /usr/lib/distcc doesn't work with gcc cross compiler and clang.
>
> This bug has been "fixed" in 3.3.2-6 by installing the upstream python
> script, but I reverted to the Debian perl script in 3.3.2-8 to not depends
> on python3 without reopening/fixing bug #919704

Would be nice to know if this package is accepter in buster before the
bullseye release.

Christian

Bug#990334: sbuild: Make usage of zfs snapshot/rollback and clone

[Johannes Schauer Marin Rodrigues]

Control: reassign -1 schroot

Quoting Juri Grabowski (2021-06-25 23:00:39)
> overlayfs doesn't work with ZFS right now.  I mean, that through zfs
> snapshot/rollback and clone features we can achieve better performance in
> spawning and destroying new schroots.

Possibly. But if so, then that's something that schroot has to offer. Not
sbuild.

signature.asc
Description: signature

Bug#990339: matplotlib: reproducible builds: embeds current year in documentation

[Vagrant Cascadian]

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

The build date is embedded in copyright statements in various .html
documentation:

  
https://tests.reproducible-builds.org/debian/rb-pkg/bullseye/amd64/diffoscope-results/matplotlib.html

  ./usr/share/doc/python-matplotlib-doc/html/users/whats_new_old.html

  
·Copyright·2021·-·2012·John·Hunter...·2012·-·2021·The·Matplotlib·development·team.
  vs.
  
·Copyright·2021·-·2012·John·Hunter...·2012·-·2022·The·Matplotlib·development·team.

The attached patch fixes this by patching doc/conf.py to respect
SOURCE_DATE_EPOCH, which is set by dpkg during package builds.


Arguably, dynamically generating the copyright dates during the build is
not correct behavior; no new copyrighted material was generated as a
result of the building at a later date.


This patch does not fix all reproducibility issues in matplotlib, but it
should reduce the overall diff.


Thanks for maintaining matplotlib!


live well,
  vagrant
From 94c1a1387f88279e31808ad3a9f08270f3e3d37b Mon Sep 17 00:00:00 2001
From: Vagrant Cascadian 
Date: Sat, 26 Jun 2021 03:12:37 +
Subject: [PATCH] doc/conf.py: if set, use SOURCE_DATE_EPOCH to set copyright
 year.

The build date of the software shouldn't really have any bearing on
the copyright dates, but by respecting SOURCE_DATE_EPOCH, it at least
limits this to the last time something in the source was changed.

https://reproducible-builds.org/specs/source-date-epoch/
---
 doc/conf.py | 7 ++-
 1 file changed, 6 insertions(+), 1 deletion(-)

diff --git a/doc/conf.py b/doc/conf.py
index 174c8935..06d5534c 100644
--- a/doc/conf.py
+++ b/doc/conf.py
@@ -18,6 +18,11 @@ import matplotlib
 import sphinx
 
 from datetime import datetime
+import time
+
+# Parse year using SOURCE_DATE_EPOCH, falling back to current time.
+# https://reproducible-builds.org/specs/source-date-epoch/
+sourceyear=datetime.utcfromtimestamp(int(os.environ.get('SOURCE_DATE_EPOCH', time.time(.year
 
 # If your extensions are in another directory, add it here. If the directory
 # is relative to the documentation root, use os.path.abspath to make it
@@ -189,7 +194,7 @@ html_context = {'sha': SHA}
 project = 'Matplotlib'
 copyright = ('2002 - 2012 John Hunter, Darren Dale, Eric Firing, '
  'Michael Droettboom and the Matplotlib development '
- f'team; 2012 - {datetime.now().year} The Matplotlib development team')
+ f'team; 2012 - {sourceyear} The Matplotlib development team')
 
 
 # The default replacements for |version| and |release|, also used in various
-- 
2.32.0



signature.asc
Description: PGP signature

Bug#990338: autogen: reproducible-builds: embeds /bin/sh or /bin/bash in autoopts-config

[Vagrant Cascadian]

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

Depending on what /bin/sh symlinks to, either /bin/sh or /bin/bash is
embedded in autoopts-config:

  
https://tests.reproducible-builds.org/debian/rb-pkg/experimental/amd64/diffoscope-results/autogen.html

  ./usr/bin/autoopts-config

  #!·/bin/bash
  vs.
  #!·/bin/sh

The attached patch fixes this by hard-coding CONFIG_SHELL=/bin/sh in
configure.ac.

I tried passing to configure or setting it in the environment, but both
approaches were ineffective.


Applying this patch *should* make autogen build reproducibly.


Thanks for maintaining autogen!


live well,
  vagrant
From 43575b74f0e64135edbcb7b6c6c5c789de87e84f Mon Sep 17 00:00:00 2001
From: Vagrant Cascadian 
Date: Sat, 26 Jun 2021 03:39:15 +
Subject: [PATCH] configure.ac: Hard-code CONFIG_SHELL as /bin/sh.

Without hard-coding this, the build may pick /bin/sh or /bin/bash,
depending on what /bin/sh links to.

Passing CONFIG_SHELL=/bin/sh to configure, or setting it in the
environment does not appear to effective.

https://tests.reproducible-builds.org/debian/issues/unstable/captures_shell_variable_in_autofoo_script_issue.html
---
 configure.ac | 5 +
 1 file changed, 1 insertion(+), 4 deletions(-)

diff --git a/configure.ac b/configure.ac
index 7171267..db0529e 100644
--- a/configure.ac
+++ b/configure.ac
@@ -223,10 +223,7 @@ AC_CONFIG_FILES([
 
 AC_CONFIG_COMMANDS([stamp-h],
 [test -z "$CONFIG_HEADERS" || echo timestamp > stamp-h])
-[CONFIG_SHELL=${CONFIG_SHELL-/bin/sh}
-f=`${CONFIG_SHELL} -c 'echo true | (
-exec 2>/dev/null ; read -u0 line ; echo $line ; )'`
-test X$f = Xtrue || CONFIG_SHELL=`command -v bash`]
+CONFIG_SHELL=/bin/sh
 AC_SUBST(CONFIG_SHELL)
 AC_DEFINE_UNQUOTED(CONFIG_SHELL,$CONFIG_SHELL,
[Define this to a working Bourne shell])
-- 
2.32.0



signature.asc
Description: PGP signature

Bug#932659: Re: [Pkg-javascript-devel] Bug#932659: node: modules are not getting

[Amon Udy]

Date: Sun, 21 Jul 2019 21:46:17 +0200
>From:

Bug#990337: python-openstackclient-doc: Missing AUTHORS file

[Jeremy Stanley]

Package: python-openstackclient-doc
Version: 5.4.0-4
Severity: normal

The manpage for the openstack CLI mentions the following:

AUTHORS
   Please refer to the AUTHORS file distributed with
   OpenStackClient.

COPYRIGHT
   Copyright  2011-2014 OpenStack Foundation and the authors
   listed in the AUTHORS file.

Yet the AUTHORS file (provided in the upstream release tarballs,
generated by PBR from metadata in the Git repository) is not included
with the binary or source package in Debian.

We can also discuss upstream eliminating this particular reference to
the AUTHORS file (which is why I'm reporting this at normal severity
instead of serious), but at least for the moment it's inconsistent in
Debian.

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

Kernel: Linux 5.10.0-7-amd64 (SMP w/4 CPU threads)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_FIRMWARE_WORKAROUND, 
TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=en_US.UTF-8, 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 python-openstackclient-doc depends on:
ii  libjs-sphinxdoc  3.4.3-2

python-openstackclient-doc recommends no packages.

python-openstackclient-doc suggests no packages.

-- no debconf information

Bug#969463: Not on all clients

[martin f krafft]

Just popping in here the fact that I have two Debian unstable 
clients backing up to the same BackupPC server (v3), and while one 
works fine, the other does exhibit a problem similar to this one. I 
am unsure about the hang and 100% CPU use, but my XferLog file is 
definitely growing indefinitely, and the backups are taking forever.


--
 .''`.   martin f. krafft  @martinkrafft
: :'  :  proud Debian developer
`. `'`   http://people.debian.org/~madduck
  `-  Debian - when you have better things to do than fixing systems

Bug#990336: mailman3: Improve logrotate configuration

[Kunal Mehta]

Package: mailman3
Version: 3.3.3-1
Severity: wishlist

Dear maintainer,

The Mailman3 package currently includes logrotate configuration for one file,
/var/log/mailman3/mailman.log. However, it is pretty common to enable other
logs, changing it to apply to /var/log/mailman3/*.log would be much nicer
IMO and what most sysadmins expect. I have tested this on Wikimedia's
Mailman3 install and it works properly.

I'm also somewhat curious why it only keeps 5 days worth of logs by default,
personally I think something like 7 days or 14 (what apache2 uses) would
be more reasonable.

Thanks,
-- Kunal

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

Kernel: Linux 5.4.120-1.fc25.qubes.x86_64 (SMP w/2 CPU cores)
Kernel taint flags: TAINT_OOT_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages mailman3 depends on:
pn  dbconfig-sqlite3 | dbconfig-pgsql | dbconfig-mysql | dbconfi  
ii  debconf [debconf-2.0] 1.5.71
ii  logrotate 3.14.0-4
ii  lsb-base  10.2019051400
ii  python3   3.7.3-1
pn  python3-aiosmtpd  
pn  python3-alembic   
ii  python3-click 7.0-1
pn  python3-dnspython 
pn  python3-falcon
pn  python3-flufl.bounce  
pn  python3-flufl.i18n
pn  python3-flufl.lock
pn  python3-lazr.config   
pn  python3-passlib   
pn  python3-psycopg2 | python3-pymysql
pn  python3-public
ii  python3-requests  2.21.0-1
pn  python3-sqlalchemy
pn  python3-zope.component
pn  python3-zope.configuration
pn  python3-zope.event
pn  python3-zope.interface
ii  ucf   3.0038+nmu1

Versions of packages mailman3 recommends:
ii  exim4-daemon-light [mail-transport-agent]  4.92-8+deb10u6

Versions of packages mailman3 suggests:
ii  chromium [www-browser]  90.0.4430.212-1~deb10u1
ii  firefox-esr [www-browser]   78.11.0esr-1~deb10u1
pn  mailman3-doc
pn  postgresql | default-mysql-server | virtual-mysql-  

Bug#990157: privoxy: legacy conffiles leftover

[Christoph Anton Mitterer]

Hey.

On Fri, 2021-06-25 at 12:39 +0200, Roland Rosenfeld wrote:
> But I'm not fully sure, whether using rm_conffile for
> /etc/privoxy/config is a good idea.  Sure, it is no longer a conffile
> nor is it contained in the privoxy package since 3.0.24-2, but it is
> handled using ucf since then (including removal on purge).
> 
> In my understanding of dpkg-maintscript-helper(1), a file that is
> handled by ucf should _not_ be handled bai dpkg-mainscript-helper
> rm_conffile.  Did I get this wrong?

Well the problem is, that it *was* handled as dpkg conffile (and still
is on any legacy) installation... so what would have needed to be done
in the first place was perhaps something like:
- cp -a it to temp location
- rm_conffile it
- move it back and from then on handle it via ucf


But I'm not an expert... perhaps it's rather best if you'd ask at
debian-devel or maybe the dpkg maintainers on how such a case should be
handled?

Cheers,
Chris.

Bug#990335: Test failure with OpenLDAP 2.5.5

[Sergio Durigan Junior]

On Friday, June 25 2021, I wrote:

> While working towards the OpenLDAP 2.5.5 transition, I noticed that
> volatildap's tests & autopkgtest are failing when run against this new
> OpenLDAP version.

For completeness: the test failure I'm seeing can be seen here:

https://autopkgtest.ubuntu.com/results/autopkgtest-impish/impish/amd64/v/volatildap/20210621_230959_275c4@/log.gz

It happens because volatildap tries to invoke OpenLDAP using HBD as the
backend, which has been deprecated and removed by OpenLDAP 2.5.x.
Changing the backed to MDB seems to fix the issue.

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/


signature.asc
Description: PGP signature

Bug#990335: Test failure with OpenLDAP 2.5.5

[Sergio Durigan Junior]

Source: volatildap
Version: 1.5.0-1
Severity: medium
Forwarded: https://github.com/rbarrois/volatildap/issues/7
Tags: patch

Dear maintainer,

While working towards the OpenLDAP 2.5.5 transition, I noticed that
volatildap's tests & autopkgtest are failing when run against this new
OpenLDAP version.

I have opened an upstream bug about this, and also filed a PR offering a
possible patch.  You can see the bug here:

  https://github.com/rbarrois/volatildap/issues/7

and the PR here:

  https://github.com/rbarrois/volatildap/pull/8

OpenLDAP 2.5.5 is currently in experimental, so there is no urgency in
fixing this problem.

Thank you,

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


signature.asc
Description: PGP signature

Bug#990162: power consumption regression

[John]

package: linux-image-5.10.0-8-amd64
version: 5.10.46-1

Tested on Debian 11 with sid (unstable) kernel.

Performs slightly better (3%) than 5.10.28-1/5.10.40-1.

Bug#990309: gdbserver: i386 (-m32) program on amd64 crashes while being debbugged

[Bernhard Übelacker]

Hello Simon,
I guess #982049 is about the same issue.
At least function name and address offset is equal.

Kind regards,
Bernhard

Bug#990334: sbuild: Make usage of zfs snapshot/rollback and clone

[Juri Grabowski]

Package: sbuild
Severity: wishlist

Dear Maintainer,

overlayfs doesn't work with ZFS right now.
I mean, that through zfs snapshot/rollback and clone features we can achieve
better performance in spawning and destroying new schroots.

Best Regards,
Juri Grabowski

Bug#989814: kodi: Kodi UI breaks with tr_TR.UTF-8 charset.

[Vasyl Gello]

Hi Hakan!

Can you please test this build with workaround I mentioned?

https://fex.net/s/vbdtzs6

Please test video library, search, PVR, whatever you use. It might break some 
things but let's see.
-- 
Vasyl Gello
==
Certified SolidWorks Expert

Mob.:+380 (98) 465 66 77

E-Mail: vasek.ge...@gmail.com

Skype: vasek.gello
==
호랑이는 죽어서 가죽을 남기고 사람은 죽어서 이름을 남긴다

25 червня 2021 р. 08:20:58 UTC, Vasyl Gello  
написав(-ла):
>Hi Hakan!
>
>> I’ll provide similar information to the official bugzilla today.
>
>This means glibc is correct and my proposed fix for Kodi upstream ( 
>https://github.com/xbmc/xbmc/pull/19905 ) is technically not…
>
>Does it make sense to catch this edge case in the linked PR rather than just 
>fall back into non-UTF-8 C locale if "Turkish I" problem is detected?
>-- 
>Vasyl Gello
>==
>Certified SolidWorks Expert
>
>Mob.:+380 (98) 465 66 77
>
>E-Mail: vasek.ge...@gmail.com
>
>Skype: vasek.gello
>==
>호랑이는 죽어서 가죽을 남기고 사람은 죽어서 이름을 남긴다

Bug#990333: Fwd: [containers/podman] Release v3.2.2 - v3.2.2

[Reinhard Tartler]

Package: libpod

Please update package in experimental


-- Forwarded message -
From: Matthew Heon 
Date: Fri, Jun 25, 2021, 17:04
Subject: [containers/podman] Release v3.2.2 - v3.2.2
To: containers/podman 
Cc: Subscribed 


v3.2.2 

Repository: containers/podman  · Tag:
v3.2.2  · Commit: d577c44

· Released by: mheon 
Changes

   - Podman's handling of the Architecture field of images has been
   relaxed. Since 3.2.0, Podman required that the architecture of the image
   match the architecture of the system to run containers based on an image,
   but images often incorrectly report architecture, causing Podman to reject
   valid images (#10648 
   and #10682 ).
   - Podman no longer uses inotify to monitor for changes to CNI
   configurations. This removes potential issues where Podman cannot be run
   because a user has exhausted their available inotify sessions (#10686
   ).

Bugfixes

   - Fixed a bug where the podman cp would, when given a directory as its
   source and a target that existed and was a file, copy the contents of the
   directory into the parent directory of the file; this now results in an
   error.
   - Fixed a bug where the podman logs command would, when following a
   running container's logs, not include the last line of output from the
   container when it exited when the k8s-file driver was in use (#10675
   ).
   - Fixed a bug where Podman would fail to run containers if
   systemd-resolved was incorrectly detected as the system's DNS server (
   #10733 ).
   - Fixed a bug where the podman exec -t command would only resize the
   exec session's TTY after the session started, leading to a race condition
   where the terminal would initially not have a size set (#10560
   ).
   - Fixed a bug where Podman containers using the slirp4netns network mode
   would add an incorrect entry to /etc/hosts pointing the container's
   hostname to the wrong IP address.
   - Fixed a bug where Podman would create volumes specified by images with
   incorrect permissions (#10188
    and #10606
   ).
   - Fixed a bug where Podman would not respect the uid and gid
options to podman
   volume create -o (#10620
   ).
   - Fixed a bug where the podman run command could panic when parsing the
   system's cgroup configuration (#10666
   ).
   - Fixed a bug where the remote Podman client's podman build -f - ...
   command did not read a Containerfile from STDIN (#10621
   ).
   - Fixed a bug where the podman container restore --import command would
   fail to restore checkpoints created from privileged containers (#10615
   ).
   - Fixed a bug where Podman was not respecting the TMPDIR environment
   variable when pulling images (#10698
   ).
   - Fixed a bug where a number of Podman commands did not properly support
   using Go templates as an argument to the --format option.

API

   - Fixed a bug where the Compat Inspect endpoint for Containers did not
   include information on container healthchecks (#10457
   ).
   - Fixed a bug where the Libpod and Compat Build endpoints for Images did
   not properly handle the devices query parameter (#10614
   ).

Misc

   - Fixed a bug where the Makefile's make podman-remote-static target to
   build a statically-linked podman-remote binary was instead producing
   dynamic binaries (#10656
   ).
   - Updated the containers/common library to v0.38.11

—

This release has 2 assets:

   - Source code (zip)
   - Source code (tar.gz)

Visit the release page
 to download them.

—
You are receiving this because you are watching this repository.
View it on GitHub 
or unsubscribe

from all notifications for this repository.

Bug#990332: libcddb: reproducible-builds: Example Makefile embeds build paths and binary paths

[Vagrant Cascadian]

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

The build path, several binary paths, and the value of the SHELL
variable are embedded in example Makefiles shipped in the package:

  
https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/diffoscope-results/libcddb.html

  ./usr/share/doc/libcddb2-dev/examples/Makefile.gz

  ACLOCAL·=·${SHELL}·'/build/1st/libcddb-1.3.2/missing'·aclocal-1.16
  vs.
  ACLOCAL·=·${SHELL}·'/build/2/libcddb-1.3.2/2nd/missing'·aclocal-1.16

  GREP·=·/bin/grep
  vs.
  GREP·=·/usr/bin/grep

  SHELL·=·/bin/bash
  vs.
  SHELL·=·/bin/sh

Since these values may differ with the installed system, in order to use
the example Makefiles, a person would have to regenerate them from
Makefile.am or Makefile.in, which are also provided.

The attached patch adjusts debian/libcddb2-dev.examples to only install
Makefile.in and Makefile.am.


If that is somehow not an option, an alternate option would be to
sanitize the Makefiles stripping the build path (or replacing with
/usr/src?), and possibly passing various variables to configure
(e.g. GREP=/bin/grep, SHELL=/bin/sh, ...).


Thanks for maintaining libcddb!


live well,
  vagrant
From e658bcb574a9cfc68f422c56671e1a13aad806fe Mon Sep 17 00:00:00 2001
From: Vagrant Cascadian 
Date: Fri, 25 Jun 2021 20:57:00 +
Subject: [PATCH] Do not install example Makefile.

The build path, several binary paths, and the value of the SHELL
variable are embedded in a Makefile shipped in the package.

Since these values may differ with the installed system, in order to use
the example Makefiles, a person would have to regenerate them from
Makefile.am or Makefile.in, which are included in the package.
---
 debian/libcddb2-dev.examples | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/debian/libcddb2-dev.examples b/debian/libcddb2-dev.examples
index bdd6e0e..3a5ea45 100644
--- a/debian/libcddb2-dev.examples
+++ b/debian/libcddb2-dev.examples
@@ -1,3 +1,3 @@
 examples/*.c
 examples/*.h
-examples/Makefil*
+examples/Makefile.*
-- 
2.32.0



signature.asc
Description: PGP signature

Bug#986593: syncthing: CVE-2021-21404

[Simon Frei]

The linked commit applies cleanly - patch is attached for convenience.

Also I have filed four important bugfixes with patches a while ago, that
I'd consider much higher priority that this security issue:

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=983667
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=983668
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=983669
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=983670

In the meantime another, even more important bugfix happened upstream,
bug and patch are here:

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

I'd appreciate if they could also be part of the stable release. And as
I mentioned before, I'd be happy to keep backporting important bugfixes.

Best,
Simon
diff --git a/lib/relay/protocol/protocol.go b/lib/relay/protocol/protocol.go
index 97dee8d41..0bc079ab6 100644
--- a/lib/relay/protocol/protocol.go
+++ b/lib/relay/protocol/protocol.go
@@ -4,6 +4,7 @@ package protocol
 
 import (
 	"errors"
+	"fmt"
 	"io"
 )
 
@@ -86,6 +87,9 @@ func ReadMessage(r io.Reader) (interface{}, error) {
 	if header.magic != magic {
 		return nil, errors.New("magic mismatch")
 	}
+	if header.messageLength < 0 || header.messageLength > 1024 {
+		return nil, fmt.Errorf("bad length (%d)", header.messageLength)
+	}
 
 	buf = make([]byte, int(header.messageLength))
 	if _, err := io.ReadFull(r, buf); err != nil {


OpenPGP_signature
Description: OpenPGP digital signature

Bug#990331: reportbug: cups-browsed printing fails due to apparmor config with message 'No destination host name supplied by cups-browsed for printer'

[Gabriel Kerneis]

Package: cups-browsed
Version: 1.28.7-1
Severity: important

Dear Maintainer,

I have a Brother printer configured per [1] using cups-browsed. It used
to work perfectly, but now fails to print with the same error message as
in #887495:
> No destination host name supplied by cups-browsed for printer "name", is 
> cups-browsed running?
Note that #887495 is a catch-all without a root cause ever identified,
which is why I'm opening a more specific bug for this issue.

[1] https://wiki.debian.org/CUPSDriverlessPrinting 

The cause of my issue lies is app armor config. I noticed the following
lines in the logs:

juin 22 16:42:55 wiyake audit[638]: AVC apparmor="STATUS" 
operation="profile_load" profile="unconfined" name="/usr/sbin/cups-browsed" 
pid=638 comm="apparmor_parser"
juin 22 16:42:55 wiyake audit[636]: AVC apparmor="STATUS" 
operation="profile_load" profile="unconfined" 
name="/usr/lib/cups/backend/cups-pdf" pid=636 comm="apparmor_parser"
juin 22 16:42:55 wiyake audit[636]: AVC apparmor="STATUS" 
operation="profile_load" profile="unconfined" name="/usr/sbin/cupsd" pid=636 
comm="apparmor_parser"
juin 22 16:42:55 wiyake audit[636]: AVC apparmor="STATUS" 
operation="profile_load" profile="unconfined" 
name="/usr/sbin/cupsd//third_party" pid=636 comm="apparmor_parser"
juin 22 16:42:55 wiyake audit[766]: AVC apparmor="DENIED" operation="capable" 
profile="/usr/sbin/cupsd" pid=766 comm="cupsd" capability=12  
capname="net_admin"
juin 22 16:42:55 wiyake audit[782]: AVC apparmor="DENIED" operation="capable" 
profile="/usr/sbin/cups-browsed" pid=782 comm="cups-browsed" capability=23  
capname="sys_nice"
juin 22 16:44:21 wiyake audit[2615]: AVC apparmor="DENIED" operation="capable" 
profile="/usr/sbin/cupsd" pid=2615 comm="cupsd" capability=12  
capname="net_admin"
juin 22 16:44:21 wiyake audit[2618]: AVC apparmor="DENIED" operation="capable" 
profile="/usr/sbin/cups-browsed" pid=2618 comm="cups-browsed" capability=23  
capname="sys_nice"

net_admin sounded suspicious, since the error message mentionned a host
name.

I then tried the following workaround, originally found for Ubuntu [2]:

# apt install apparmor-utils
# aa-complain cupsd-browsed
# systemctl restart cups-browsed

[2] https://askubuntu.com/questions/645636/apparmor-with-cupsd-denied-in-logs 

It resolved my issue, and my printer immediately started printing the
jobs in the queue. The logs now show:

juin 25 22:23:06 wiyake audit[221791]: AVC apparmor="STATUS" 
operation="profile_replace" profile="unconfined" name="/usr/sbin/cups-browsed" 
pid=221791 comm="apparmor_parser"
juin 25 22:24:40 wiyake audit[222966]: AVC apparmor="ALLOWED" 
operation="capable" profile="/usr/sbin/cups-browsed" pid=222966 
comm="cups-browsed" capability=23  capname="sys_nice"

I'm not sure what exactly needs to be updated in the apparmor config to
fix this issue. Note that #988764 is also about apparmor issues, but is
marked minor and doesn't seem to block printing. My issue yields to a
complete impossibility to print (at least in my use case).

I'd be happy to test any fix you could provide.

Thanks!

Gabriel

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

Kernel: Linux 5.10.0-7-amd64 (SMP w/4 CPU threads)
Kernel taint flags: TAINT_WARN
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.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 cups-browsed depends on:
ii  cups-daemon  2.3.3op2-3+deb11u1
ii  init-system-helpers  1.60
ii  libavahi-client3 0.8-5
ii  libavahi-common3 0.8-5
ii  libavahi-glib1   0.8-5
ii  libc62.31-12
ii  libcups2 2.3.3op2-3+deb11u1
ii  libcupsfilters1  1.28.7-1
ii  libglib2.0-0 2.66.8-1
ii  libldap-2.4-22.4.57+dfsg-3
ii  lsb-base 11.1.0

Versions of packages cups-browsed recommends:
ii  avahi-daemon  0.8-5

cups-browsed suggests no packages.

-- Configuration Files:
/etc/apparmor.d/usr.sbin.cups-browsed changed:
/usr/sbin/cups-browsed flags=(attach_disconnected, complain) {
  #include 
  #include 
  #include 
  #include 
  #include 
  /etc/cups/cups-browsed.conf r,
  /etc/cups/lpoptions r,
  /etc/cups/ppd/* r,
  /{var/,}run/cups/certs/* r,
  /var/cache/cups/* rw,
  /var/log/cups/* rw,
  /tmp/** rw,
  # Site-specific additions and overrides. See local/README for details.
  #include 
}


-- no debconf information

Bug#990330: syncthing: Inconsistent state after accepting new folder

[Simon Frei]

retitle 990330 "syncthing: Inconsistent state after accepting new folder"
thanks

I messed up the subject/title by copy-pasting - sorry about that, I hope
the correction works the way I expect.



OpenPGP_signature
Description: OpenPGP digital signature

Bug#990330: syncthing: Connection take a long time to close after an error

[Simon Frei]

Package: syncthing
Version: 1.12.1~ds1-2
Severity: important

Accepting a new folder can lead to missing files on initial sync. See
upstream bug [1] and PR for details. This can lead to an inconsistent
state, with files not being synced, thus I used severity important.

The patch fixing this is attached.

[1]: https://github.com/syncthing/syncthing/issues/7649




diff --git a/lib/model/indexsender.go b/lib/model/indexsender.go
index 7bca774..8b9e02a 100644
--- a/lib/model/indexsender.go
+++ b/lib/model/indexsender.go
@@ -329,15 +329,15 @@ func (r *indexSenderRegistry) addLocked(folder config.FolderConfiguration, fset
 // addPending stores the given info to start an index sender once resume is called
 // for this folder.
 // If an index sender is already running, it will be stopped.
-func (r *indexSenderRegistry) addPending(folder config.FolderConfiguration, startInfo *indexSenderStartInfo) {
+func (r *indexSenderRegistry) addPending(folderID string, startInfo *indexSenderStartInfo) {
 	r.mut.Lock()
 	defer r.mut.Unlock()
 
-	if is, ok := r.indexSenders[folder.ID]; ok {
+	if is, ok := r.indexSenders[folderID]; ok {
 		r.sup.RemoveAndWait(is.token, 0)
-		delete(r.indexSenders, folder.ID)
+		delete(r.indexSenders, folderID)
 	}
-	r.startInfos[folder.ID] = startInfo
+	r.startInfos[folderID] = startInfo
 }
 
 // remove stops a running index sender or removes one pending to be started.
diff --git a/lib/model/model.go b/lib/model/model.go
index 64e7bc6..1558321 100644
--- a/lib/model/model.go
+++ b/lib/model/model.go
@@ -1252,7 +1252,7 @@ func (m *model) ccHandleFolders(folders []protocol.Folder, deviceCfg config.Devi
 continue
 			}
 			m.cfg.AddOrUpdatePendingFolder(folder.ID, folder.Label, deviceID)
-			indexSenders.addPending(cfg, ccDeviceInfos[folder.ID])
+			indexSenders.addPending(folder.ID, ccDeviceInfos[folder.ID])
 			changed = true
 			m.evLogger.Log(events.FolderRejected, map[string]string{
 "folder":  folder.ID,
@@ -1270,7 +1270,7 @@ func (m *model) ccHandleFolders(folders []protocol.Folder, deviceCfg config.Devi
 		}
 
 		if cfg.Paused {
-			indexSenders.addPending(cfg, ccDeviceInfos[folder.ID])
+			indexSenders.addPending(cfg.ID, ccDeviceInfos[folder.ID])
 			continue
 		}
 
@@ -1312,7 +1312,7 @@ func (m *model) ccHandleFolders(folders []protocol.Folder, deviceCfg config.Devi
 			// Shouldn't happen because !cfg.Paused, but might happen
 			// if the folder is about to be unpaused, but not yet.
 			l.Debugln("ccH: no fset", folder.ID)
-			indexSenders.addPending(cfg, ccDeviceInfos[folder.ID])
+			indexSenders.addPending(cfg.ID, ccDeviceInfos[folder.ID])
 			continue
 		}
 


OpenPGP_signature
Description: OpenPGP digital signature

Bug#990329: rpm: embeds path to various binaries that differ with usrmerge

[Vagrant Cascadian]

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

The paths to various binaries are embedded which differs on a usrmerge
vs. non-usrmerge system.

  
https://tests.reproducible-builds.org/debian/rb-pkg/bullseye/amd64/diffoscope-results/rpm.html

  ./usr/lib/rpm/macros

  %__bzip2»   »   /bin/bzip2
  vs.
  %__bzip2»   »   /usr/bin/bzip2

Patch attached which passes variables to configure to use the
non-usrmerge locations, as usrmerge installations typically have
compatibility symlinks, but not vice-versa.


live well,
  vagrant
From edef98ba189c9eee0682813db839b33a5ffd4e85 Mon Sep 17 00:00:00 2001
From: Vagrant Cascadian 
Date: Fri, 25 Jun 2021 20:24:46 +
Subject: [PATCH] debian/rules: Pass paths to various binaries.

Use the non-usrmerge locations for binaries, which works on both
usrmerge and non-usrmerge systems.

https://tests.reproducible-builds.org/debian/issues/paths_vary_due_to_usrmerge_issue.html
---
 debian/rules | 17 -
 1 file changed, 16 insertions(+), 1 deletion(-)

diff --git a/debian/rules b/debian/rules
index 3e05ba54..0cc1be30 100755
--- a/debian/rules
+++ b/debian/rules
@@ -28,7 +28,22 @@ configure_flags += \
 	--enable-shared \
 	--enable-python \
 	LDFLAGS="$(LDFLAGS) -Wl,--as-needed" \
-	CPPFLAGS="$(CPPFLAGS)"
+	CPPFLAGS="$(CPPFLAGS)" \
+	__BZIP2=/bin/bzip2 \
+	__CAT=/bin/cat \
+	__CHGRP=/bin/chgrp \
+	__CHMOD=/bin/chmod \
+	__CHOWN=/bin/chown \
+	__CP=/bin/cp \
+	__GREP=/bin/grep \
+	__GZIP=/bin/gzip \
+	__LZIP=/bin/lzip \
+	__MKDIR=/bin/mkdir \
+	__MV=/bin/mv \
+	__RM=/bin/rm \
+	__SED=/bin/sed \
+	__TAR=/bin/tar \
+	MKDIR_P='/bin/mkdir -p' \
 
 override_dh_auto_configure:
 	dh_auto_configure -- $(configure_flags)
-- 
2.32.0



signature.asc
Description: PGP signature

Bug#990328: Please let "fallocate -d" preserve mtime, and add an option for ctime

[Kevin Price]

Package: util-linux
Version: 2.36.1-7
Severity: wishlist

Dear maintainer,

for sparsifying files with blocks of zeros, it's quite convenient to use
"fallocate -d". As of current bullseye util-linux/2.36.1-7 on ext4, this
updates their atime, mtime, and ctime, but preserves their "birth time"
(btime).

I'd like "fallocate -d" to always preserve mtime. To my understanding of
MAC times, mtime should only then be updated when the content of the
file gets modified, which "fallocate -d" definitely never does.

"fallocate -d" should:
 * update atime when reading > 0 bytes (which it does)
 * preserve mtime (which it _falsely_ updates)
 * preserve btime (which it does)
 * ctime: uncertain. (currently it updates it)

Whether "fallocate -d" should update or preserve ctime seems a good
question to me. From my understanding of MAC times, I'd prefer a
command-line switch to preserve or update ctime if desired, and to
update it by default.

So here's my wishlist item for util-linux: Please let "fallocate -d"
adhere to standards and always preserve mtime, and please add a
command-line option to handle ctime as desired by the user. Please bear
in mind that the current behavior regarding mtime counteracts common (or
at least my) understanding.

Please forward this to upstream. Shouldn't be a great deal.

Best
Kevin

Bug#909394: luarocks: New upstream release 3.7.0

[Kim Alvefur]

Dear maintainer,

The latest version of Luarocks is now 3.7.0 according to 
https://github.com/luarocks/luarocks/wiki/Download

--
Regards

Bug#990228: [Pkg-openssl-devel] Bug#990228: Bug#990228: Bug#990228: Bug#990228: openssl: breaks ssl-cert installation: 8022CB35777F0000:error:1200007A:random number generator:RAND_write_file:Not a reg

[Kurt Roeckx]

reassign 990228 ssl-cert
severity 990228 normal
thanks

So I think there is no bug in OpenSSL and the additional check
being done in 3.0 makes sense. So I'm reassigning this to
ssl-cert.


Kurt

Bug#989695: pre-approval: mono/6.8.0.105+dfsg-3.1

[Paul Gevers]

Hi,

On 10-06-2021 19:25, Andreas Beckmann wrote:
> If you ACK this, I intend to 0-day NMU this to experimental because it
> needs NEW processing. Please prod the ftp-masters to get this actually done.

We don't have control over ftp-masters *and* I still need some days
before I can actually look properly into this (I suspect strongly that
other colleagues won't beat me to it). Therefor, I propose you already
upload to experimental.

Paul



OpenPGP_signature
Description: OpenPGP digital signature

Bug#990327: cppunit: reproducible-builds: Example Makefiles embed build paths and binary paths

[Vagrant Cascadian]

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

The build path, several binary paths, and the value of the SHELL
variable are embedded in example Makefiles shipped in the package:

  
https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/diffoscope-results/cppunit.html

  /usr/share/doc/libcppunit-doc/examples/ClockerPlugIn/Makefile.gz

  ACLOCAL·=·${SHELL}·'/build/1st/cppunit-1.15.1/missing'·aclocal-1.16
  vs.
  ACLOCAL·=·${SHELL}·'/build/2/cppunit-1.15.1/2nd/missing'·aclocal-1.16

  GREP·=·/bin/grep
  vs.
  GREP·=·/usr/bin/grep

  SHELL·=·/bin/bash
  vs.
  SHELL·=·/bin/sh

Since these values may differ with the installed system, in order to use
the example Makefiles, a person would have to regenerate them from
Makefile.am or Makefile.in, which are also provided.

The attached patch adjusts debian/rules to remove the Makefiles before
running dh_compress.


If that is somehow not an option, an alternate option would be to
sanitize the Makefiles stripping the build path (or replacing with
/usr/src?), and possibly passing various variables to configure
(e.g. GREP=/bin/grep, SHELL=/bin/sh, ...).


Thanks for maintaining cppunit!


live well,
  vagrant
From e1714c24575d26671157ee54308a892fcf832a15 Mon Sep 17 00:00:00 2001
From: Vagrant Cascadian 
Date: Fri, 25 Jun 2021 19:14:10 +
Subject: [PATCH] debian/rules: Remove Makefiles to resolve reproducibility
 issues.

The build path, several binary paths, and the value of the SHELL
variable are embedded in a Makefile shipped in the package.

Since these values may differ with the installed system, in order to use
the example Makefiles, a person would have to regenerate them from
Makefile.am or Makefile.in, which are also provided.
---
 debian/rules | 5 +
 1 file changed, 5 insertions(+)

diff --git a/debian/rules b/debian/rules
index fc2f58a..9e54dce 100755
--- a/debian/rules
+++ b/debian/rules
@@ -40,3 +40,8 @@ override_dh_install-indep:
 	dh_installdocs -plibcppunit-doc doc/html
 	dh_installexamples -plibcppunit-doc examples/* debian/examples/*
 	rm -f debian/libcppunit-doc/usr/share/doc/libcppunit-doc/examples/simple/.gitignore
+
+override_dh_compress:
+	# Delete example Makefiles which contain variable build paths and binary paths
+	find debian/ -name Makefile -print -delete
+	dh_compress
-- 
2.32.0



signature.asc
Description: PGP signature

Bug#985303: questions

[debian]

Hello Thomas and sorry for the delay

I've tested it now with last fai-client in nfsroot from fai-project buster repo
(5.10.3~buster1)
This bug is still here.

Bug#990323: [Pkg-utopia-maintainers] Bug#990323: volume-key: reproducible-builds: Example Makefiles embed build paths and binary paths

[Michael Biebl]

Am 25.06.21 um 19:39 schrieb Vagrant Cascadian:

The attached patch adjusts debian/rules to remove the Makefile before
running dh_install.


Personally, I would probably just drop the following line from 
debian/volume-key.install


contrib usr/share/doc/volume_key

Any objections? Does anyone find those scripts particularly useful?




OpenPGP_signature
Description: OpenPGP digital signature

Bug#990277: unblock: feature-check/0.2.2-7

[Sebastian Ramacher]

Control: tags -1 moreinfo confirmed

On 2021-06-24 15:42:28 +0300, Peter Pentchev wrote:
> Package: release.debian.org
> Severity: normal
> User: release.debian@packages.debian.org
> Usertags: unblock
> 
> This is a pre-approval request before I upload feature-check/0.2.2-7
> to unstable to fix an RC bug.

Please go ahead and remove the moreinfo tag once the new version is
available in unstable.

> 
> [ Reason ]
> See #990276 (https://bugs.debian.org/990276): Version comparisons may
> return the wrong result.
> 
> [ Impact ]
> If the feature-check command-line tool is used by other programs to
> make sure that an installed program has a recent enough version of
> a supported feature, the checks may fail for some versions containing
> non-numeric characters (pre-release, patch, etc).
> 
> [ Tests ]
> The patches include additions to the feature-check unit-test suite that
> is run both at build time and as an autopkgtest.
> 
> [ Risks ]
> Leaf package, not widely used yet; targeted fix, so hopefully
> any risks are very low.
> 
> [ Checklist ]
>   [x] all changes are documented in the d/changelog
>   [x] I reviewed all changes and I approve them
>   [x] attach debdiff against the package in testing
> 
> unblock feature-check/0.2.2-7

> diff -Nru feature-check-0.2.2/debian/changelog 
> feature-check-0.2.2/debian/changelog
> --- feature-check-0.2.2/debian/changelog  2020-10-26 11:14:52.0 
> +0200
> +++ feature-check-0.2.2/debian/changelog  2021-06-24 15:33:07.0 
> +0300
> @@ -1,3 +1,10 @@
> +feature-check (0.2.2-7) unstable; urgency=medium
> +
> +  * Add the cmp-num and cmp-rest upstream patches to fix some version
> +string comparisons. Closes: #990276
> +
> + -- Peter Pentchev   Thu, 24 Jun 2021 15:33:07 +0300
> +
>  feature-check (0.2.2-6) unstable; urgency=medium
>  
>[ Michael Hudson-Doyle ]
> diff -Nru feature-check-0.2.2/debian/patches/cmp-num.patch 
> feature-check-0.2.2/debian/patches/cmp-num.patch
> --- feature-check-0.2.2/debian/patches/cmp-num.patch  1970-01-01 
> 02:00:00.0 +0200
> +++ feature-check-0.2.2/debian/patches/cmp-num.patch  2021-06-24 
> 15:30:21.0 +0300
> @@ -0,0 +1,46 @@
> +Description: Fix a 2 < 10 version int/string bug.
> +Origin: upstream; 
> https://gitlab.com/ppentchev/feature-check/-/commit/ed0da5159562fa37cf32386a1baf2a1114562822
> +Bug-Debian: https://bugs.debian.org/990276
> +Author: Peter Pentchev 
> +Last-Update: 2021-06-24
> +
> +--- a/perl5/feature-check.pl
>  b/perl5/feature-check.pl
> +@@ -269,7 +269,7 @@
> + if ($na ne '') {
> + if ($nb ne '') {
> + if ($nb != $na) {
> +-return $na cmp $nb;
> ++return $na <=> $nb;
> + }
> + } else {
> + return 1;
> +--- a/t/04-simple.t
>  b/t/04-simple.t
> +@@ -1,6 +1,6 @@
> + #!/usr/bin/perl
> + #
> +-# Copyright (c) 2018  Peter Pentchev
> ++# Copyright (c) 2018, 2021  Peter Pentchev
> + # All rights reserved.
> + #
> + # Redistribution and use in source and binary forms, with or without
> +@@ -89,6 +89,18 @@
> + ['base ge 3', 0],
> + ['base gt 3', 0],
> + ['base eq 3', 0],
> ++
> ++['base lt 10', 1],
> ++['base le 10', 1],
> ++['base ge 10', 0],
> ++['base gt 10', 0],
> ++['base eq 10', 0],
> ++
> ++['base lt 10.1', 1],
> ++['base le 10.1', 1],
> ++['base ge 10.1', 0],
> ++['base gt 10.1', 0],
> ++['base eq 10.1', 0],
> + );
> + 
> + my %c = env_init;
> diff -Nru feature-check-0.2.2/debian/patches/cmp-rest.patch 
> feature-check-0.2.2/debian/patches/cmp-rest.patch
> --- feature-check-0.2.2/debian/patches/cmp-rest.patch 1970-01-01 
> 02:00:00.0 +0200
> +++ feature-check-0.2.2/debian/patches/cmp-rest.patch 2021-06-24 
> 15:30:28.0 +0300
> @@ -0,0 +1,62 @@
> +Description: Fix a 3.0.beta2 < 3.0 version int/string bug.
> +Origin: upstream; 
> https://gitlab.com/ppentchev/feature-check/-/commit/59e618baff6836f281697561f5a9cfa22ccd28df
> +Bug-Debian: https://bugs.debian.org/990276
> +Author: Peter Pentchev 
> +Last-Update: 2021-06-24
> +
> +--- a/perl5/feature-check.pl
>  b/perl5/feature-check.pl
> +@@ -282,7 +282,7 @@
> + if ($ra ne '') {
> + if ($rb ne '') {
> + if ($ra ne $rb) {
> +-return $ra <=> $rb;
> ++return $ra cmp $rb;
> + }
> + } else {
> + return 1;
> +--- a/t/04-simple.t
>  b/t/04-simple.t
> +@@ -101,6 +101,42 @@
> + ['base ge 10.1', 0],
> + ['base gt 10.1', 0],
> + ['base eq 10.1', 0],
> ++
> ++['beta lt 1', 0],
> ++['beta le 1', 0],
> ++['beta eq 1', 0],
> ++['beta ge 1', 1],
> ++['beta gt 1', 1],
> ++
> ++['beta lt 3.0', 1],
> ++['beta le 3.0', 1],
> ++['beta eq 3.0', 0],
> ++['beta ge 3.0', 0],
> ++['beta gt 3.0', 0],
> ++
> ++['beta lt 3.0.beta1', 

Bug#990326: thunderbird: No images shown in thundebird

[Guido Krause]

Package: thunderbird
Version: 1:78.11.0-1
Severity: normal

Dear Maintainer,

Thunderbird does not show images embedded in e-mail if allowed. Either nothing 
is shown or a "broken image" icon

-- System Information:
Debian Release: 11.0
  APT prefers testing-security
  APT policy: (500, 'testing-security'), (500, 'testing')
Architecture: amd64 (x86_64)

Kernel: Linux 5.10.0-7-amd64 (SMP w/8 CPU threads)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.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 thunderbird depends on:
ii  debianutils  4.11.2
ii  fontconfig   2.13.1-4.2
ii  libatk1.0-0  2.36.0-2
ii  libbotan-2-172.17.3+dfsg-2
ii  libbz2-1.0   1.0.8-4
ii  libc62.31-12
ii  libcairo-gobject21.16.0-5
ii  libcairo21.16.0-5
ii  libdbus-1-3  1.12.20-2
ii  libdbus-glib-1-2 0.110-6
ii  libevent-2.1-7   2.1.12-stable-1
ii  libffi7  3.3-6
ii  libfontconfig1   2.13.1-4.2
ii  libfreetype6 2.10.4+dfsg-1
ii  libgcc-s110.2.1-6
ii  libgdk-pixbuf-2.0-0  2.42.2+dfsg-1
ii  libglib2.0-0 2.66.8-1
ii  libgtk-3-0   3.24.24-4
ii  libicu67 67.1-6
ii  libjson-c5   0.15-2
ii  libnspr4 2:4.29-1
ii  libnss3  2:3.61-1
ii  libpango-1.0-0   1.46.2-3
ii  libstdc++6   10.2.1-6
ii  libvpx6  1.9.0-1
ii  libx11-6 2:1.7.1-1
ii  libx11-xcb1  2:1.7.1-1
ii  libxcb-shm0  1.14-3
ii  libxcb1  1.14-3
ii  libxext6 2:1.3.3-1.1
ii  libxrender1  1:0.9.10-1
ii  psmisc   23.4-2
ii  x11-utils7.7+5
ii  zlib1g   1:1.2.11.dfsg-2

Versions of packages thunderbird recommends:
ii  hunspell-de-at [hunspell-dictionary]  20161207-9
ii  hunspell-de-ch [hunspell-dictionary]  20161207-9
ii  hunspell-de-de [hunspell-dictionary]  20161207-9
ii  hunspell-en-us [hunspell-dictionary]  1:2019.10.06-1

Versions of packages thunderbird suggests:
ii  apparmor  2.13.6-10
pn  fonts-lyx 
ii  libgssapi-krb5-2  1.18.3-5
ii  libgtk2.0-0   2.24.33-2

-- no debconf information

Bug#990325: evolution: printer not recognised

[Guido Krause]

Package: evolution
Version: 3.38.3-1
Severity: normal

Dear Maintainer,

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

   * What led up to the situation?
   * What exactly did you do (or not do) that was effective (or
 ineffective)?
   * What was the outcome of this action?
   * What outcome did you expect instead?

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

Evolution does not allow to print e-mails. There is an error message that the 
printer is not found.

-- System Information:
Debian Release: 11.0
  APT prefers testing-security
  APT policy: (500, 'testing-security'), (500, 'testing')
Architecture: amd64 (x86_64)

Kernel: Linux 5.10.0-7-amd64 (SMP w/8 CPU threads)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.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 evolution depends on:
ii  dbus   1.12.20-2
ii  evolution-common   3.38.3-1
ii  evolution-data-server  3.38.3-1
ii  libc6  2.31-12
ii  libcamel-1.2-623.38.3-1
ii  libclutter-gtk-1.0-0   1.8.4-4
ii  libecal-2.0-1  3.38.3-1
ii  libedataserver-1.2-25  3.38.3-1
ii  libevolution   3.38.3-1
ii  libglib2.0-0   2.66.8-1
ii  libgtk-3-0 3.24.24-4
ii  libical3   3.0.9-2
ii  libnotify4 0.7.9-3
ii  libsoup2.4-1   2.72.0-2
ii  libwebkit2gtk-4.0-37   2.32.1-2
ii  libxml22.9.10+dfsg-6.7
ii  psmisc 23.4-2

Versions of packages evolution recommends:
ii  evolution-plugin-bogofilter  3.38.3-1
ii  evolution-plugin-pstimport   3.38.3-1
ii  evolution-plugins3.38.3-1
ii  yelp 3.38.3-1

Versions of packages evolution suggests:
pn  evolution-ews   
pn  evolution-plugins-experimental  
ii  gnupg   2.2.27-2
ii  network-manager 1.30.0-2

-- no debconf information

Bug#990324: btrfs-progs on hppa arch should not install-depend on libgcc-s1 (but on libgcc-s4)

[Helge Deller]

Package: btrfs-progs
Version: 5.10.1-2
Tags: hppa, patch

btrfs-progs fails to install on the hppa arch, because there we do not have any
libgcc-s1 package, but instead a libgcc-s4 package:

root@phantom:~# apt install btrfs-progs/unstable
Selected version '5.10.1-2' (ftp.ports.debian.org:1.0/unstable [hppa]) for 
'btrfs-progs'
The following packages have unmet dependencies:
  btrfs-progs : Depends: libgcc-s1 (> 10-20200211) but it is not installable

buildd@phantom:/tmp/t1$ dpkg -l | grep libgcc-s
ii  libgcc-s4:hppa10.2.1-6   
hppa GCC support library

Please apply the attached patch.
It removes the install-dependency on libgcc-s1 on hppa (but keeps it for all 
other architectures).

Thanks,
Helge
diff -up ./debian/control.org ./debian/control
--- ./debian/control.org2021-06-25 17:47:02.311356810 +
+++ ./debian/control2021-06-25 14:19:29.464606707 +
@@ -28,7 +28,7 @@ Vcs-Git: https://salsa.debian.org/debian
 Package: btrfs-progs
 Architecture: linux-any
 Multi-Arch: foreign
-Depends: ${misc:Depends}, ${shlibs:Depends}, libgcc-s1 (>> 10-20200211)
+Depends: ${misc:Depends}, ${shlibs:Depends}, libgcc-s1 (>> 10-20200211) [!hppa]
 # backports will want the Breaks:libcc-s1 below
 Breaks: btrbk (<= 0.25.0), libgcc-s1 (<< 10-20200211), initramfs-tools (<< 
0.137~)
 Suggests: duperemove

Bug#969287: raspi-firmware: Dual HDMI support for RaspberryPI4

[ibu ☉ radempa]

On 25.06.21 18:52, Diederik de Haas wrote:

On Wed, 6 Jan 2021 14:11:02 -0600 Gunnar Wolf  wrote:

So, do you still have this behavior? Have you (or has anybody else)
been able to get dual-screen support on your RPi4? Or do you have any
promising pointers on this?


Making sure the submitter receives the the reply/request for info.


Indeed, I missed Gunnars message in January. Now I tried immediately and 
in fact, dual HDMI works (using bullseye's 5.10.0-6-arm64 kernel).

Disconnecting and reconnecting the second display also worked fine.

Bug solved!

Greetings from a very happy user :)
ibu

Bug#990323: volume-key: reproducible-builds: Example Makefiles embed build paths and binary paths

[Vagrant Cascadian]

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

The build path, several binary paths, and the value of the SHELL
variable are embedded in example Makefiles shipped in the package:

  
https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/diffoscope-results/volume-key.html

  ./usr/share/doc/volume_key/contrib/Makefile.gz

  ACLOCAL·=·${SHELL}·'/build/1st/volume-key-0.3.12/admin/missing'·aclocal-1.16
  vs.
  ACLOCAL·=·${SHELL}·'/build/2/volume-key-0.3.12/2nd/admin/missing'·aclocal-1.16

  GREP·=·/bin/grep
  vs.
  GREP·=·/usr/bin/grep

  SHELL·=·/bin/bash
  vs.
  SHELL·=·/bin/sh

Since these values may differ with the installed system, in order to use
the example Makefiles, a person would have to regenerate them from
Makefile.am or Makefile.in, which are also provided.

The attached patch adjusts debian/rules to remove the Makefile before
running dh_install.


If that is somehow not an option, an alternate option would be to
sanitize the Makefiles stripping the build path (or replacing with
/usr/src?), and possibly passing various variables to configure
(e.g. GREP=/bin/grep, SHELL=/bin/sh, ...).


Thanks for maintaining volume-key!


live well,
  vagrant
From a751749dabf2dd4b87796cb5924ba7e0d0cf7cf5 Mon Sep 17 00:00:00 2001
From: Vagrant Cascadian 
Date: Fri, 25 Jun 2021 17:25:14 +
Subject: [PATCH] debian/rules: Remove Makefile to resolve reproducibility
 issues.

The build path, several binary paths, and the value of the SHELL
variable are embedded in a Makefile shipped in the package.

Since these values may differ with the installed system, in order to use
the example Makefiles, a person would have to regenerate them from
Makefile.am or Makefile.in, which are also provided.
---
 debian/rules | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/debian/rules b/debian/rules
index 3e2b027..0ba6e6a 100755
--- a/debian/rules
+++ b/debian/rules
@@ -16,6 +16,8 @@ override_dh_auto_configure:
 
 override_dh_install:
 	find debian/tmp -name '*.la' -print -delete
+	# Remove example Makefile to fix reproducibility issues
+	find contrib -name Makefile -print -delete
 	dh_install
 
 override_dh_missing:
-- 
2.32.0



signature.asc
Description: PGP signature

Bug#990012: lightning: Calendar/DAV integration failed

[Guido Krause]

Package: lightning
Version: 1:78.11.0-1
Followup-For: Bug #990012

Dear Maintainer,

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

   * What led up to the situation?

I tried to add several online calenders in thunderbird-lighning with no success

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

- adding calender in thunderbird
- selecting network calendar
- adding the corrensponding entries for calendar address, user name, calendar 
name, e-mail address
- saving

   * What was the outcome of this action?

- calendar entries are not shown
- icon with "!" next to calendar name

   * What outcome did you expect instead?

- that calender entries are shown

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


-- System Information:
Debian Release: 11.0
  APT prefers testing-security
  APT policy: (500, 'testing-security'), (500, 'testing')
Architecture: amd64 (x86_64)

Kernel: Linux 5.10.0-7-amd64 (SMP w/8 CPU threads)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.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 lightning depends on:
ii  thunderbird  1:78.11.0-1

lightning recommends no packages.

lightning suggests no packages.

-- no debconf info

Bug#969287: raspi-firmware: Dual HDMI support for RaspberryPI4

[Diederik de Haas]

On Wed, 6 Jan 2021 14:11:02 -0600 Gunnar Wolf  wrote:
> The situation has evolved quite a bit since you filed the bug, and
> having both newer firmware and kernel versions, I wouldn't be
> surprised if this issue managed to fix itself. I understand (but don't
> know for sure) advances have been made regarding vc4 support in
> mainline Linux.
> 
> So, do you still have this behavior? Have you (or has anybody else)
> been able to get dual-screen support on your RPi4? Or do you have any
> promising pointers on this?

Making sure the submitter receives the the reply/request for info.

https://raspi.debian.net/daily/raspi_4_bullseye.img.xz will give you the 
latest in terms of firmware and kernel.
The 'tested' Bullseye image contains the latest firmware and a 5.10 kernel, 
which is important, but not the most recent kernel (5.10.24-1 vs 5.10.40-1).

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

Bug#656921: Suggestion

[王昊然]

I think it is better to use '/proc//comm' instead; it shows
correct script name instead of interpreter name, and didn't have the
issues of 'cmdline'.

Bug#990322: Backport patch to allow kopanocore to build against PHP 8

[Bryce Harrington]

Source: kopanocore
Version: 8.7.0-7.1
Severity: normal
Tags: upstream patch

kopanocore 8.7.0-7.1 will FTBFS when built with PHP 8 or later.

This isn't an issue in debian currently since PHP 7.4 is still the
default.  For Ubuntu we've dropped 7.4 and moved to 8.0, and discovered
this failure.  Fortunately there is a patch available from upstream to
move to 8.0, however it does not apply cleanly on top of 8.7.0-7.1 due
to some intermediary refactoring in upstream's tree.  The original
upstream patch is:


https://github.com/Kopano-dev/kopano-core/commit/9b3bbd27ea63af180ce73a30a218d34b6e6535a4

At least one of the refactoring changes needed to make that apply is:


https://github.com/Kopano-dev/kopano-core/commit/b8d29e9f58440f1d75bddf77df3d25fd6367af20

However, there are some other differences such as changes for APIs not
included in 8.7.0-7.1, etc.  So I ended up doing a reimplementation of
the patch:

https://launchpad.net/ubuntu/+source/kopanocore/8.7.0-7.1ubuntu4

Please note one important addition I made to configure.ac to enable the
build:

+   AS_CASE([$PHP_VERSION],
+   [5.*], [with_php=5],
+-  [7.*], [with_php=7]
++  [7.*], [with_php=7],
++  [8.*], [with_php=7]

IOW this tricks the Makefile into treating PHP 8 as the same as PHP 7,
which for purposes of the build logic is fine.  However, this could
likely be done better (e.g. by merging the php-ext and php7-ext
directories together, as was done in commit b8d29e9f).

Thanks,
Bryce

-- System Information:
Debian Release: bullseye/sid
  APT prefers focal-updates
  APT policy: (500, 'focal-updates'), (500, 'focal-security'), (500, 
'focal-proposed'), (500, 'focal'), (100, 'focal-backports')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.4.0-70-generic (SMP w/12 CPU cores)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE
Locale: LANG=C, LC_CTYPE=C (charmap=UTF-8) (ignored: LC_ALL set to 
en_US.UTF-8), LANGUAGE=en_US:en (charmap=UTF-8) (ignored: LC_ALL set to 
en_US.UTF-8)
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Bug#990321: golang-github-aws-aws-sdk-go: FTBFS with go 1.16

[William 'jawn-smith' Wilson]

Package: golang-github-aws-aws-sdk-go
Version: 1.36.33-1
Severity: normal
Tags: patch
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu impish ubuntu-patch

Dear Maintainer,

   * golang-github-aws-aws-sdk-go FTBFS with go 1.16
   * There is an upstream change to fix this

In Ubuntu, the attached patch was applied to achieve the following:

  Successfully building from source with go 1.16

  * Cherry pick minor upstream change to enable building with go 1.16
(LP: #1933678)


Thanks for considering the patch.


-- System Information:
Debian Release: bullseye/sid
  APT prefers hirsute-updates
  APT policy: (500, 'hirsute-updates'), (500, 'hirsute-security'), (500, 
'hirsute')
Architecture: arm64 (aarch64)

Kernel: Linux 5.11.0-1007-raspi (SMP w/4 CPU threads; PREEMPT)
Kernel taint flags: TAINT_CRAP, TAINT_UNSIGNED_MODULE
Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
diff -Nru 
golang-github-aws-aws-sdk-go-1.36.33/debian/patches/0003-fix-protocol-unit-test-for-go-1.16.patch
 
golang-github-aws-aws-sdk-go-1.36.33/debian/patches/0003-fix-protocol-unit-test-for-go-1.16.patch
--- 
golang-github-aws-aws-sdk-go-1.36.33/debian/patches/0003-fix-protocol-unit-test-for-go-1.16.patch
   1970-01-01 00:00:00.0 +
+++ 
golang-github-aws-aws-sdk-go-1.36.33/debian/patches/0003-fix-protocol-unit-test-for-go-1.16.patch
   2021-06-25 16:10:25.0 +
@@ -0,0 +1,26 @@
+Description: Enable building with go 1.16
+ Go 1.16 changes the behavior of SortXML in a way that causes some of this 
package's
+ unit tests to fail. The fix has already been applied upstream, so we pull in 
that minor change
+Origin: upstream, 
https://github.com/aws/aws-sdk-go/commit/8dfbe6f52e0cd75c2594178be73e8ab784feca32
+Bug: https://github.com/aws/aws-sdk-go/issues/3731
+Bug-Ubuntu: 
https://bugs.launchpad.net/ubuntu/+source/golang-github-aws-aws-sdk-go/+bug/1534346
+Last-Update: 2021-06-25
+---
+This patch header follows DEP-3: http://dep.debian.net/deps/dep3/
+Index: 
golang-github-aws-aws-sdk-go-1.36.33/private/protocol/restxml/build_test.go
+===
+--- 
golang-github-aws-aws-sdk-go-1.36.33.orig/private/protocol/restxml/build_test.go
 golang-github-aws-aws-sdk-go-1.36.33/private/protocol/restxml/build_test.go
+@@ -6830,8 +6830,10 @@ func TestInputService20ProtocolTestXMLAt
+   if r.Body == nil {
+   t.Errorf("expect body not to be nil")
+   }
+-  body := util.SortXML(r.Body)
+-  awstesting.AssertXML(t, `http://www.w3.org/2001/XMLSchema-instance; 
XMLSchema-instance:type="CanonicalUser" xmlns:_xmlns="xmlns" 
_xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance;>f...@example.com`,
 util.Trim(body))
++  body, _ := ioutil.ReadAll(r.Body)
++  awstesting.AssertXML(t, `http://www.w3.org/2001/XMLSchema-instance; 
xsi:type="CanonicalUser">f...@example.com`,
 util.Trim(string(body)))
++
++  // assert URL
+ 
+   // assert URL
+   awstesting.AssertURL(t, "https://test/;, r.URL.String())
diff -Nru golang-github-aws-aws-sdk-go-1.36.33/debian/patches/series 
golang-github-aws-aws-sdk-go-1.36.33/debian/patches/series
--- golang-github-aws-aws-sdk-go-1.36.33/debian/patches/series  2020-10-22 
21:35:03.0 +
+++ golang-github-aws-aws-sdk-go-1.36.33/debian/patches/series  2021-06-25 
15:37:26.0 +
@@ -1,2 +1,3 @@
 0001-dfsg-footer.erb.patch
 0002-dfsg-godoc.html.patch
+0003-fix-protocol-unit-test-for-go-1.16.patch

Bug#990103: gitlab: Conflicting dependencies on google-protobuf prevent package configuration during update

[Maximilian Stein]

Hi,
ruby-google-protobuf package no longer works and we need to install 
google-protobuf from rubygems.org now.


This is documented in https://wiki.debian.org/gitlab 




Thank you very much, this actually works!

Best,
Maximilian



OpenPGP_signature
Description: OpenPGP digital signature

Bug#990320: sssd - Fails after upgrade from Buster

[Bastian Blank]

Package: sssd
Version: 2.4.1-2
Severity: serious

After upgrade from Buster, several components of sssd simply fail:

| ● sssd-nss.socket  loaded failed failed
SSSD NSS Service responder socket
|   sssd-pac.socket  loaded active listening 
SSSD PAC Service responder socket
| ● sssd-pam-priv.socket loaded failed failed
SSSD PAM Service responder private socket
| ● sssd-ssh.socket  loaded failed failed
SSSD SSH Service responder socket
| ● sssd-sudo.socket loaded failed failed
SSSD Sudo Service responder socket

So all the sockets are broken and the system is in degraded mode due to
failed units.

Bastian

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

Kernel: Linux 5.10.0-7-amd64 (SMP w/2 CPU threads)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_GB:en
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages sssd depends on:
pn  python3-sss  
pn  sssd-ad  
pn  sssd-common  
pn  sssd-ipa 
pn  sssd-krb5
pn  sssd-ldap
pn  sssd-proxy   

sssd recommends no packages.

sssd suggests no packages.

Bug#951553: RFS: qepcad

[Torrance, Douglas]

Control: tags -1 pending

I've finished packaging QEPCAD (Quantifier Elimination by Partial Cylindrical 
Algebraic Decomposition) for Debian.  Would anyone be able to review/sponsor?  
It's NEW, so it would need a binary upload.
https://salsa.debian.org/science-team/qepcad

I'm also still looking for sponsors for several other packages:

* PHCpack (NEW)
 https://salsa.debian.org/science-team/phcpack

* Macaulay2 (new 1.18 release - upload to experimental due to freeze)
 https://salsa.debian.org/science-team/macaulay2

* Macaulay2-Jupyter-Kernel (NEW)
 https://salsa.debian.org/science-team/macaulay2-jupyter-kernel

Thanks!
Doug


signature.asc
Description: PGP signature

Bug#990243:

[Kevin Price]

fixed 990243 2.36.1-7
thanks

Dear Chris,

Am 25.06.21 um 16:34 schrieb Kevin Price:
>> Can the effect still be seen with Linux and util-linux from
>> bullseye?
> 
> IDK. I'd need to set up a bullseye machine iot test that.

Done. No, bullseye's utils-linux behaves correctly.

Filesystem: ext4, block size = 4096
Kernel: linux-image-5.10.0-7-amd64 version 5.10.40-1
Package: util-linux version 2.36.1-7

#BEGIN_TRANSCRIPT

$ dd if=/dev/zero bs=1 count=1 of=1-zero-byte
1+0 records in
1+0 records out
1 byte copied, 0.00124056 s, 0.8 kB/s

$ du 1-zero-byte
4   1-zero-byte

$ fallocate -vd 1-zero-byte
1-zero-byte: 1 B (1 bytes) converted to sparse holes.

$ du 1-zero-byte
0   1-zero-byte

#END_TRANSCRIPT

However the exact same procedure fails to unallocate the block in
buster's util-linux version 2.33.1-0.1 .

I've found the upstream fix:
https://git.kernel.org/pub/scm/utils/util-linux/util-linux.git/commit/?h=stable/v2.36=ed423e56ec43e6cdd5a8475e698f693b56512a63

Best
Kevin

Bug#990306: [debian-mysql] Bug#990306: bug on mariadb-server version 1:10.3.29-0+deb10u1

[Otto Kekäläinen]

Hello!

I've just imported 10.3.30 into our Debian packaging repositories and
so far I have not seen any regressions[1]. I expect us to be able to
ship this with the next stable Debian Buster release.

Faustin: Do you want to help out and update the debian/changelog,
adding appropriate "(Closes: #nn)" items so the changelog will
tell both users and Debian release managers why the update is
important?


[1] https://salsa.debian.org/mariadb-team/mariadb-10.3/-/pipelines/264414

On Fri, Jun 25, 2021 at 2:12 AM Jacopo D'oro  wrote:
>
> Package: mariadb-server
> Version: 1:10.3.29-0+deb10u1
>
> In the last upgrade of maridb-server package for debian buster (version
> 1:10.3.29-0+deb10u1), the following bug is now affecting any system that
> installed the update:
>
> https://jira.mariadb.org/browse/MDEV-25714
>
> This bug has been fixed in version 10.3.30 and has been marked as
> emercency because is compromising the results of some type of queries
> (subqueries with group by).
> An update or a rollback is necessary, a workaroud suggested by Mariadb
> is also available (optimizer_switch='split_materialized=off')
>
> ___
> pkg-mysql-maint mailing list
> pkg-mysql-ma...@alioth-lists.debian.net
> https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-mysql-maint

Bug#990319: unblock: intel-microcode/3.20210608.2

[Henrique de Moraes Holschuh]

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

Please unblock package intel-microcode

I would like to unblock the intel-microcode update currently in
unstable, so that it will be available in Debian 11.

Please note that the current plans are that a Debian 10 (buster)
security update, intel-microcode/3.20210608.2~deb10u1, will be delivered
to Debian stable in the next couple days through debian-security, in
which case the version currently in Debian 11 "bullseye" would be
*OLDER* than what would be available in buster-security and unstable.

Also, please be warned that this update has the potential to cause
regressions when compared to the previous version of the intel-microcode
package.  But do read the text below for the full rationale.


Potential regressions:

intel-microcode/3.20210608.2 restores a *LOT* of security updates to
Skylake D0/R0, but it might cause boot problems on systems that have too
old a microcode update *in BIOS*.  I have been asking around to check if
this still happens on the new microcode, but I haven't heard from anyone
affected yet.

Ubuntu and upstream reports about this:
https://github.com/intel/Intel-Linux-Processor-Microcode-Data-Files/issues/31
https://bugs.launchpad.net/ubuntu/+source/intel-microcode/+bug/1882890

intel-microcode/3.20210608.2 can also cause Intel WiFi connection issues
on systems with Intel Wireless *on-board* and a specific family of
processors (CoffeLake signature 0x906ea).  There is hope that a newer
release of iwlwifi-firmware (which is being arranged by the Debian
security team, since it is *also* a security update to mitigate some of
FragAttack) works around this issue.

Upstream report:
https://github.com/intel/Intel-Linux-Processor-Microcode-Data-Files/issues/56


Rationale for issuing it as a security-update to Debian buster, and the
Debian bollseye unblock request:

I have talked it over with the stable security team, and they're fully
aware of the above regression potential.  We considered several possible
scenarios (including *not* updating the affected processors), and the
security team prefers that we *do* issue the full microcode update, but
warn users of the potential issues.

The reason behind this decision is simple: we were forced to withold
relevant operational and security updates from a much larger set of
users, to avoid regressions on a much smaller set of users, and have
done so for quite a while already.  This situation cannot continue
indefinitely.

Anyway, once the buster-security update to
intel-microcode/3.20210608.2~deb10u1 is out, switching bullseye to
intel-microcode/3.20210608.2 is *NOT* going to add any regressions
compared to Debian stable + security updates.

I am filling this bug report before the security update is distributed
just in case.

IMPORTANT: I do recommend that we wait for at least 10 more days before
possibly unblocking the migration of intel-microcode/3.20210608.2 to
bullseye, anyway.  That will allow for feedback from the security
update to be acted upon.


Here's the git diffstat (git diff attached, as usual):
 README.md |   14 ++--
 changelog |   59 
 debian/changelog  |   71 
 intel-ucode-with-caveats/06-4f-01 |binary
 intel-ucode/06-3f-02  |binary
 intel-ucode/06-3f-04  |binary
 intel-ucode/06-4e-03  |binary
 intel-ucode/06-55-03  |binary
 intel-ucode/06-55-04  |binary
 intel-ucode/06-55-05  |binary
 intel-ucode/06-55-06  |binary
 intel-ucode/06-55-07  |binary
 intel-ucode/06-55-0b  |binary
 intel-ucode/06-56-03  |binary
 intel-ucode/06-56-04  |binary
 intel-ucode/06-56-05  |binary
 intel-ucode/06-5c-09  |binary
 intel-ucode/06-5c-0a  |binary
 intel-ucode/06-5e-03  |binary
 intel-ucode/06-5f-01  |binary
 intel-ucode/06-6a-05  |binary
 intel-ucode/06-6a-06  |binary
 intel-ucode/06-7a-01  |binary
 intel-ucode/06-7a-08  |binary
 intel-ucode/06-7e-05  |binary
 intel-ucode/06-86-04  |binary
 intel-ucode/06-86-05  |binary
 intel-ucode/06-8a-01  |binary
 intel-ucode/06-8c-01  |binary
 intel-ucode/06-8c-02  |binary
 intel-ucode/06-8d-01  |binary
 intel-ucode/06-8e-09  |binary
 intel-ucode/06-8e-0a  |binary
 intel-ucode/06-8e-0b  |binary
 intel-ucode/06-8e-0c  |binary
 intel-ucode/06-96-01  |binary
 intel-ucode/06-9c-00  |binary
 intel-ucode/06-9e-09  |binary
 intel-ucode/06-9e-0a  |binary
 intel-ucode/06-9e-0b  |binary
 intel-ucode/06-9e-0c  |binary
 intel-ucode/06-9e-0d  |binary
 

Bug#990313: Review for thorvg

[Timo Röhling]

Dear Michal,

your package requires a bit more work to be suitable for upload.
I'll start with a few things that stood out to me:

- Your package uses meson for building but declares no Build-Depends
  on meson. This is needed for the build servers to know which
  packages they have to install, and more generally to make it clear
  that changes to the meson package might affect your package, too.

- Even with meson installed, your package fails to build from source
  (FTBFS) in a clean sid chroot. I'll attach the build log; it looks
  like your code relies on some standard headers being indirectly
  included, which causes errors with GCC 11 (where this is no longer
  the case).

- You should be using the latest debhelper version (13) and policy
  revision (4.5.1) instead of whatever happened to be in the
  templates you used to debianize your source tree. You should also
  read the Debian policy (or at least the relevant sections of it)
  for Dos and Donts [1]. One section that you definitely *must* read
  and understand is section 8.

- Speaking of templates, you should also remove all the boilerplate
  that you do not need. I've seen quite a lot of example code left
  in your debian/rules that is commented out. On the other hand,
  there are also a few files missing, especially the
  debian/source/format file. Please read the relevant section from
  the dpkg-source(1) manual page for details on the source formats.

Generally, I strongly recommend that you use Lintian, our Debian
package linter, by running

lintian -i path/to/thorvg_0.2.2-1_*.changes

when you have built your package locally, and fix all issues.
Feel free to ask if any questions pop up, especially while reading
the Debian policy manual.

Cheers
Timo

[1] https://www.debian.org/doc/debian-policy/

--
⢀⣴⠾⠻⢶⣦⠀   ╭╮
⣾⠁⢠⠒⠀⣿⡁   │ Timo Röhling   │
⢿⡄⠘⠷⠚⠋⠀   │ 9B03 EBB9 8300 DF97 C2B1  23BF CC8C 6BDD 1403 F4CA │
⠈⠳⣄   ╰╯
dpkg-buildpackage: info: source package thorvg
dpkg-buildpackage: info: source version 0.2.2-1
dpkg-buildpackage: info: source distribution unstable
dpkg-buildpackage: info: source changed by Michal Maciola 

 dpkg-source --before-build .
dpkg-buildpackage: info: host architecture amd64
 fakeroot debian/rules clean
dh clean
   dh_clean
 dpkg-source -b .
dpkg-source: warning: no source format specified in debian/source/format, see 
dpkg-source(1)
dpkg-source: warning: native package version may not have a revision
dpkg-source: info: using source format '1.0'
dpkg-source: info: building thorvg in thorvg_0.2.2-1.tar.gz
dpkg-source: info: building thorvg in thorvg_0.2.2-1.dsc
 debian/rules build
dh build
   dh_update_autotools_config
   dh_autoreconf
   dh_auto_configure
cd obj-x86_64-linux-gnu && LC_ALL=C.UTF-8 meson .. 
--wrap-mode=nodownload --buildtype=plain --prefix=/usr --sysconfdir=/etc 
--localstatedir=/var --libdir=lib/x86_64-linux-gnu 
--libexecdir=lib/x86_64-linux-gnu
The Meson build system
Version: 0.56.2
Source dir: /build/thorvg-0.2.2
Build dir: /build/thorvg-0.2.2/obj-x86_64-linux-gnu
Build type: native build
Project name: thorvg
Project version: 0.2.2
Using 'CXXFLAGS' from environment with value: '-g -O2 
-ffile-prefix-map=/build/thorvg-0.2.2=. -fstack-protector-strong -Wformat 
-Werror=format-security'
Using 'LDFLAGS' from environment with value: '-Wl,-z,relro'
Using 'CPPFLAGS' from environment with value: '-Wdate-time -D_FORTIFY_SOURCE=2'
C++ compiler for the host machine: c++ (gcc 10.2.1 "c++ (Debian 10.2.1-6) 
10.2.1 20210110")
C++ linker for the host machine: c++ ld.bfd 2.35.2
Using 'CXXFLAGS' from environment with value: '-g -O2 
-ffile-prefix-map=/build/thorvg-0.2.2=. -fstack-protector-strong -Wformat 
-Werror=format-security'
Using 'LDFLAGS' from environment with value: '-Wl,-z,relro'
Using 'CPPFLAGS' from environment with value: '-Wdate-time -D_FORTIFY_SOURCE=2'
Host machine cpu family: x86_64
Host machine cpu: x86_64
Configuring config.h using configuration
Message: Enable SW Raster Engine
Message: Enable SVG Loader
Library pthread found: YES
Message: 

Summary:
ThorVG version  :   0.2.2
Build Type  :   custom
Prefix  :   /usr
Tests   :   false
Examples:   false

Build targets in project: 1

Option buildtype is: custom [default: debugoptimized]
Found ninja-1.10.1 at /usr/bin/ninja
   dh_auto_build
cd obj-x86_64-linux-gnu && LC_ALL=C.UTF-8 ninja -j20 -v
[1/31] c++ -Isrc/libthorvg.so.0.2.2.p -Isrc -I../src -Iinc -I../inc -I. -I.. 
-Isrc/lib -I../src/lib -Isrc/lib/sw_engine -I../src/lib/sw_engine -Isrc/loaders 
-I../src/loaders -Isrc/loaders/svg -I../src/loaders/svg -Isrc/loaders/raw 
-I../src/loaders/raw -Isrc/bindings -I../src/bindings -fvisibility=hidden 
-fdiagnostics-color=always -pipe -D_FILE_OFFSET_BITS=64 -Wall -Winvalid-pch 
-Wnon-virtual-dtor -Os 

Bug#990316: add glfw-im-module env for fcitx5 and ibus

Package: im-config Version: 0.46-1 Severity: wishlist Hi, Hello, I am in charge 
of this package at the deepin company, the first time to submit a patch. Best 
regards, Chen Shijie chenshijie 邮箱：chenshi...@uniontech.com 签名由 网易邮箱大师 定制From f873b6bcf104c99afc9d2637150da32eb59cdcea Mon Sep 17 00:00:00 2001
From: chenshijie 
Date: Fri, 25 Jun 2021 22:23:12 +0800
Subject: [PATCH] Add GLFW_IM_MODULE env for fcitx5 to "ibus" Add
 GLFW_IM_MODULE env for ibus to "ibus"

https://github.com/kovidgoyal/kitty/issues/469
---
 data/21_ibus.rc   | 1 +
 data/23_fcitx5.rc | 1 +
 2 files changed, 2 insertions(+)

diff --git a/data/21_ibus.rc b/data/21_ibus.rc
index 85cd3a2..67d9599 100644
--- a/data/21_ibus.rc
+++ b/data/21_ibus.rc
@@ -17,6 +17,7 @@ if [ "$IM_CONFIG_PHASE" = 1 ]; then
 XMODIFIERS=@im=ibus
 
 # Let's assume all required modules are installed
+GLFW_IM_MODULE=ibus
 GTK_IM_MODULE=ibus
 QT_IM_MODULE=ibus
 CLUTTER_IM_MODULE=ibus
diff --git a/data/23_fcitx5.rc b/data/23_fcitx5.rc
index c4a44cc..f4343ba 100644
--- a/data/23_fcitx5.rc
+++ b/data/23_fcitx5.rc
@@ -12,6 +12,7 @@ if [ "$IM_CONFIG_PHASE" = 1 ]; then
 XMODIFIERS=@im=fcitx
 
 # Let's assume all required modules are installed
+GLFW_IM_MODULE=ibus
 GTK_IM_MODULE=fcitx
 QT_IM_MODULE=fcitx
 CLUTTER_IM_MODULE=xim
-- 
2.20.1

Bug#990243:

[Kevin Price]

Dear Chris!

Am 25.06.21 um 15:20 schrieb Chris Hofstaedtler:
> * Kevin Price  [210625 11:00]:
>> fallocate -d seems to attempt to unallocate that last block if it
>> contains only zeros, and it even updates the file's mtime. The
>> unallocation is reported, but doesn't effectively happen.
> 
> Did you verify this is a bug in fallocate and not a bug or
> side-effect of the kernel-side implementation, possibly in the used
> filesystem?
I'm rather convinced the culprit is fallocate from util-linux, because
using the same kernel and filesystem:

1. With coreutils (dd, truncate) I'm able to create sparse files with
zero blocks and sizes other than multiples of ${block size}.

2. With coreutils (truncate) I'm able to truncate the last block of
zeros and re-add it, becoming an unallocated block. That's how I
successfully sparsified the last block (containing 2048 zeros) of the
debian iso, btw.

Is that convincing, or do you request any additional verification? Some
strace maybe?

> Can the effect still be seen with Linux and util-linux from
> bullseye?

IDK. I'd need to set up a bullseye machine iot test that.

> BTW, which filesystem are you trying this on?

I'm using ext4 with block size=4096, running on buster's stock
linux-image-4.19.0-17-amd64, version 4.19.194-2.

Best
Kevin

Bug#990316: Add GLFW_IM_MODULE=fcitx on ibus and fcitx5 to enable IME in kitty

[Osamu Aoki]

Hi,

I assume you are talking post-bullseye upload.

On Fri, 2021-06-25 at 21:23 +0800, Yao Wei wrote:
> Package: im-config
> Version: 0.46-1
> Severity: wishlist
> 
> Hi,
> 
> As discussed in https://github.com/kovidgoyal/kitty/issues/469, adding
> `GLFW_IM_MODULE=ibus` can enable IBus API connection in kitty terminal,
> and thus enabling CJK input in that terminal emulator.
> 
> Not only in IBus, fcitx5 populates IBus API so setting the envvar to
> `ibus` also works in fcitx5.
> 

I don't know about kitty but this sounds very good idea.
I assume this is like fbterm like program on Linux console with a lot of 
features ...
nono ...this is run under X.

> However, after some searching I found that the variable looks like
> exclusively used in kitty, especially this envvar acts as a toggle in
> kitty's source code:
> 
>   
> https://github.com/kovidgoyal/kitty/blob/6179cfc6703af1b0682fdd14829280b8a228c167/glfw/ibus_glfw.c#L286
> 
> I am wondering whether it is okay to add that variable into im-config.

I see this very low risk and good idea.
Send us pull request or patch.

Osamu

Bug#990318: python-pkg-resources: please add Breaks against the unversioned python packages

[Andreas Beckmann]

Package: python-pkg-resources
Version: 44.1.1-1
Severity: serious
Tags: patch

Hi,

in some upgrade scenarios the unversioned python packages don't get
removed despite of the Breaks existing in python2.7 and friends.
This is caused by the unversioned python packages getting higher scores
and apt-get therefore prefers to keep them installed. Often
python-pkg-resources is installed in these scenarios, too, and (as a
"surviving" python2 package) has the highest score of all python2
packages, making it the ideal candidate for a copy of the Breaks to make
them effective.


Andreas
diff -Nru python-setuptools-44.1.1/debian/changelog 
python-setuptools-44.1.1/debian/changelog
--- python-setuptools-44.1.1/debian/changelog   2020-08-02 14:20:55.0 
+0200
+++ python-setuptools-44.1.1/debian/changelog   2021-06-18 02:53:40.0 
+0200
@@ -1,3 +1,13 @@
+python-setuptools (44.1.1-2) UNRELEASED; urgency=medium
+
+  * python-pkg-resources: Copy Breaks: python (<< 2.7.18),
+python-minimal (<< 2.7.18), libpython-stdlib (<< 2.7.18) from python2.7
+for smoother upgrades from buster. In some upgrade scenarios these Breaks
+in python2.7 were ineffective because the unversioned python packages got
+higher scores. Closes: #-1.
+
+ -- Andreas Beckmann   Fri, 18 Jun 2021 02:53:40 +0200
+
 python-setuptools (44.1.1-1) unstable; urgency=medium
 
   * New upstream version.
diff -Nru python-setuptools-44.1.1/debian/control 
python-setuptools-44.1.1/debian/control
--- python-setuptools-44.1.1/debian/control 2020-08-02 14:20:55.0 
+0200
+++ python-setuptools-44.1.1/debian/control 2021-06-18 02:53:23.0 
+0200
@@ -19,6 +19,10 @@
 Architecture: all
 Multi-Arch: foreign
 Depends: ${misc:Depends}, ${python:Depends}
+Breaks:
+ python (<< 2.7.18),
+ python-minimal (<< 2.7.18),
+ libpython-stdlib (<< 2.7.18),
 Description: Package Discovery and Resource Access using pkg_resources
  The pkg_resources module provides an API for Python libraries to
  access their resource files, and for extensible applications and

Bug#990317: librust-object+compression-dev: please use a versioned dependency for librust-flate2-1+default-dev

[Andreas Beckmann]

Package: librust-object+compression-dev
Version: 0.12.0-3
Severity: serious
Tags: patch

librust-object+compression-dev depends on librust-flate2-1+default-dev
which is a (versioned) virtual package provided by
librust-flate2+zlib-dev in buster and by librust-flate2+rust-backend-dev
in bullseye. apt-get has problems exchanging these two packages during an
upgrade from buster to bullseye and prefers to keep the already installed
provider installed. This can be fixed by making the dependency versioned
s.t. the old provider from buster is no longer considered as a valid
solution.

Bad problem resolution by apt-get:

  Starting 2 pkgProblemResolver with broken count: 5
  Investigating (0) librust-goblin+pe32-dev:amd64 < 0.0.19-1 @ii mK Ib >
  Broken librust-goblin+pe32-dev:amd64 Depends on librust-goblin-dev:amd64 < 
0.0.19-1 -> 0.2.1-4 @ii umU > (= 0.0.19-1)
Considering librust-goblin-dev:amd64 5 as a solution to 
librust-goblin+pe32-dev:amd64 -2
Removing librust-goblin+pe32-dev:amd64 rather than change 
librust-goblin-dev:amd64
  Investigating (0) librust-goblin+pe64-dev:amd64 < 0.0.19-1 @ii mK Ib >
  Broken librust-goblin+pe64-dev:amd64 Depends on librust-goblin-dev:amd64 < 
0.0.19-1 -> 0.2.1-4 @ii umU > (= 0.0.19-1)
Considering librust-goblin-dev:amd64 5 as a solution to 
librust-goblin+pe64-dev:amd64 -2
Removing librust-goblin+pe64-dev:amd64 rather than change 
librust-goblin-dev:amd64
  Investigating (0) librust-goblin+mach64-dev:amd64 < 0.0.19-1 @ii mK Ib >
  Broken librust-goblin+mach64-dev:amd64 Depends on librust-goblin-dev:amd64 < 
0.0.19-1 -> 0.2.1-4 @ii umU > (= 0.0.19-1)
Considering librust-goblin-dev:amd64 5 as a solution to 
librust-goblin+mach64-dev:amd64 -2
Removing librust-goblin+mach64-dev:amd64 rather than change 
librust-goblin-dev:amd64
  Investigating (0) librust-parity-wasm+std-dev:amd64 < 0.35.5-1 @ii mK Ib >
  Broken librust-parity-wasm+std-dev:amd64 Depends on 
librust-parity-wasm-dev:amd64 < 0.35.5-1 -> 0.41.0-1 @ii umU > (= 0.35.5-1)
Considering librust-parity-wasm-dev:amd64 0 as a solution to 
librust-parity-wasm+std-dev:amd64 -2
Removing librust-parity-wasm+std-dev:amd64 rather than change 
librust-parity-wasm-dev:amd64
  Investigating (0) librust-flate2+zlib-dev:amd64 < 1.0.6-1 @ii mK Ib >
  Broken librust-flate2+zlib-dev:amd64 Depends on librust-flate2-dev:amd64 < 
1.0.6-1 -> 1.0.13-3 @ii umU > (= 1.0.6-1)
Considering librust-flate2-dev:amd64 0 as a solution to 
librust-flate2+zlib-dev:amd64 -2
Removing librust-flate2+zlib-dev:amd64 rather than change 
librust-flate2-dev:amd64
  Investigating (1) librust-object+compression-dev:amd64 < 0.11.0-1 -> 0.12.0-3 
@ii umU Ib >
  Broken librust-object+compression-dev:amd64 Depends on 
librust-flate2-1+default-dev:amd64 < none @un H >
Considering librust-flate2+zlib-dev:amd64 -2 as a solution to 
librust-object+compression-dev:amd64 2
Added librust-flate2+zlib-dev:amd64 to the remove list
Fixing librust-object+compression-dev:amd64 via keep of 
librust-flate2+zlib-dev:amd64
  Investigating (1) librust-flate2+zlib-dev:amd64 < 1.0.6-1 @ii mK Ib >
  Broken librust-flate2+zlib-dev:amd64 Depends on librust-flate2-dev:amd64 < 
1.0.6-1 -> 1.0.13-3 @ii umU > (= 1.0.6-1)
Considering librust-flate2-dev:amd64 0 as a solution to 
librust-flate2+zlib-dev:amd64 -2
Removing librust-flate2+zlib-dev:amd64 rather than change 
librust-flate2-dev:amd64
  Investigating (2) librust-object+compression-dev:amd64 < 0.11.0-1 -> 0.12.0-3 
@ii umU Ib >
  Broken librust-object+compression-dev:amd64 Depends on 
librust-flate2-1+default-dev:amd64 < none @un H >
Considering librust-flate2+zlib-dev:amd64 -2 as a solution to 
librust-object+compression-dev:amd64 2
Added librust-flate2+zlib-dev:amd64 to the remove list
Fixing librust-object+compression-dev:amd64 via keep of 
librust-flate2+zlib-dev:amd64
  Investigating (2) librust-flate2+zlib-dev:amd64 < 1.0.6-1 @ii mK Ib >
  Broken librust-flate2+zlib-dev:amd64 Depends on librust-flate2-dev:amd64 < 
1.0.6-1 -> 1.0.13-3 @ii umU > (= 1.0.6-1)
Considering librust-flate2-dev:amd64 0 as a solution to 
librust-flate2+zlib-dev:amd64 2
Added librust-flate2-dev:amd64 to the remove list
Fixing librust-flate2+zlib-dev:amd64 via keep of librust-flate2-dev:amd64
   Try to Re-Instate (3) librust-flate2-dev:amd64
  Done
  
  The following packages were automatically installed and are no longer 
required:
libperl5.28 librust-byteorder-dev librust-cfg-if-dev
librust-rustc-version-dev librust-semver-dev librust-semver-parser-0.7-dev
perl-modules-5.28
  Use 'sudo apt autoremove' to remove them.
  The following packages will be REMOVED:
librust-goblin+mach64-dev librust-goblin+pe32-dev librust-goblin+pe64-dev
librust-parity-wasm+std-dev
  The following NEW packages will be installed:
gcc-10-base libapt-pkg6.0 libcrypt-dev libcrypt1 libffi7 libgcc-s1
libgssapi-krb5-2 libhogweed6 libk5crypto3 libkeyutils1 libkrb5-3

Bug#990316: Add GLFW_IM_MODULE=fcitx on ibus and fcitx5 to enable IME in kitty

[魏銘廷]

Package: im-config
Version: 0.46-1
Severity: wishlist

Hi,

As discussed in https://github.com/kovidgoyal/kitty/issues/469, adding
`GLFW_IM_MODULE=ibus` can enable IBus API connection in kitty terminal,
and thus enabling CJK input in that terminal emulator.

Not only in IBus, fcitx5 populates IBus API so setting the envvar to
`ibus` also works in fcitx5.

However, after some searching I found that the variable looks like
exclusively used in kitty, especially this envvar acts as a toggle in
kitty's source code:

  
https://github.com/kovidgoyal/kitty/blob/6179cfc6703af1b0682fdd14829280b8a228c167/glfw/ibus_glfw.c#L286

I am wondering whether it is okay to add that variable into im-config.

Best regards,
Yao Wei


signature.asc
Description: PGP signature

Bug#990243: Info received ("fallocate -vd" reports incorrect result)

[Chris Hofstaedtler]

Hello Kevin,

* Kevin Price  [210625 11:00]:
> fallocate -d seems to attempt to unallocate that last block if it
> contains only zeros, and it even updates the file's mtime. The
> unallocation is reported, but doesn't effectively happen.

Did you verify this is a bug in fallocate and not a bug or
side-effect of the kernel-side implementation, possibly in the used
filesystem?

Can the effect still be seen with Linux and util-linux from
bullseye?

BTW, which filesystem are you trying this on?

Chris

Bug#990307: Acknowledgement (virtinst: Installation fails: cannot load AppArmor profile)

[Michal Herko]

Attaching the files.

Dňa Piatok, 25. jún 2021 o 09:15, Debian Bug Tracking System 
 napísal(a):

Thank you for filing a new Bug report with Debian.

You can follow progress on this Bug here: 990307: 
.


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

  michal.he...@disroot.org 
(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 Libvirt Maintainers 
>


If you wish to submit further information on this problem, please
send it to 990...@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.

--
990307: 
Debian Bug Tracking System
Contact ow...@bugs.debian.org  with 
problems


root@toymaker /h/heroin# systemctl --no-pager -l status libvirtd
● libvirtd.service - Virtualization daemon
 Loaded: loaded (/lib/systemd/system/libvirtd.service; enabled; vendor 
preset: enabled)
 Active: active (running) since Fri 2021-06-25 10:15:48 CEST; 53min ago
TriggeredBy: ● libvirtd-admin.socket
 ● libvirtd.socket
 ● libvirtd-ro.socket
   Docs: man:libvirtd(8)
 https://libvirt.org
   Main PID: 758 (libvirtd)
  Tasks: 19 (limit: 32768)
 Memory: 56.7M
CPU: 4.063s
 CGroup: /system.slice/libvirtd.service
 └─758 /usr/sbin/libvirtd

jún 25 10:20:43 toymaker libvirtd[758]: internal error: Child process 
(LIBVIRT_LOG_OUTPUTS=3:stderr /usr/lib/libvirt/virt-aa-helper -c -u 
libvirt-37a5a8fe-e739-4bf3-8435-610522d80af4) unexpected exit status 1: 
virt-aa-helper: error: apparmor_parser exited with error
jún 25 10:20:43 toymaker libvirtd[758]: internal error: cannot load AppArmor 
profile 'libvirt-37a5a8fe-e739-4bf3-8435-610522d80af4'
jún 25 10:43:28 toymaker libvirtd[758]: internal error: Child process 
(LIBVIRT_LOG_OUTPUTS=3:stderr /usr/lib/libvirt/virt-aa-helper -c -u 
libvirt-44fdd1be-0f7f-4c39-ba82-72ed52392b84) unexpected exit status 1: 
virt-aa-helper: error: apparmor_parser exited with error
jún 25 10:43:28 toymaker libvirtd[758]: internal error: cannot load AppArmor 
profile 'libvirt-44fdd1be-0f7f-4c39-ba82-72ed52392b84'
jún 25 10:43:46 toymaker libvirtd[758]: internal error: Child process 
(LIBVIRT_LOG_OUTPUTS=3:stderr /usr/lib/libvirt/virt-aa-helper -c -u 
libvirt-54ec7b66-1b8c-4b3c-a78c-ac3d2555f15e) unexpected exit status 1: 
virt-aa-helper: error: apparmor_parser exited with error
jún 25 10:43:46 toymaker libvirtd[758]: internal error: cannot load AppArmor 
profile 'libvirt-54ec7b66-1b8c-4b3c-a78c-ac3d2555f15e'
jún 25 10:45:06 toymaker libvirtd[758]: internal error: Child process 
(LIBVIRT_LOG_OUTPUTS=3:stderr /usr/lib/libvirt/virt-aa-helper -c -u 
libvirt-ed570f48-04be-40d8-addb-661cd79750ac) unexpected exit status 1: 
virt-aa-helper: error: apparmor_parser exited with error
jún 25 10:45:06 toymaker libvirtd[758]: internal error: cannot load AppArmor 
profile 'libvirt-ed570f48-04be-40d8-addb-661cd79750ac'
jún 25 10:51:34 toymaker libvirtd[758]: internal error: Child process 
(LIBVIRT_LOG_OUTPUTS=3:stderr /usr/lib/libvirt/virt-aa-helper -c -u 
libvirt-ac37c0f2-23da-4392-aa43-a7dcf913c779) unexpected exit status 1: 
virt-aa-helper: error: apparmor_parser exited with error
jún 25 10:51:34 toymaker libvirtd[758]: internal error: cannot load AppArmor 
profile 'libvirt-ac37c0f2-23da-4392-aa43-a7dcf913c779'

root@toymaker /h/heroin# LANG=en_US.UTF-8 virt-install --name lackey --memory 
4096 --cdrom Stiahnuté/Windows\ 10\ X64\ 20H2\ Pro\ OEM\ ESD\ MULTi-7\ MARCH\ 
2021\ \{Gen2\}/WIN10X64.MULTi-7.MAR2021.iso --os-variant win10 --disk size=99 
--debug
[Pi, 25 jún 2021 10:51:32 virt-install 7978] DEBUG (cli:204) Launched with 
command line: /usr/bin/virt-install --name lackey --memory 4096 --cdrom 
Stiahnuté/Windows 10 X64 20H2 Pro OEM ESD MULTi-7 MARCH 2021 
{Gen2}/WIN10X64.MULTi-7.MAR2021.iso --os-variant win10 --disk size=99 --debug
[Pi, 25 jún 2021 10:51:32 virt-install 7978] DEBUG (virtinstall:212) Distilled 
--network options: ['default']
[Pi, 25 jún 2021 10:51:32 virt-install 7978] DEBUG (virtinstall:144) Distilled 
--disk options: ['size=99']
[Pi, 25 jún 2021 10:51:32 virt-install 7978] DEBUG (cli:216) Requesting 
libvirt URI default
[Pi, 25 jún 2021 10:51:32 virt-install 7978] DEBUG (cli:219) Received libvirt 
URI qemu:///system
[Pi, 25 jún 2021 10:51:32 virt-install 7978] DEBUG (storage:139) Found default 

Bug#990307: virtinst: Installation fails: cannot load AppArmor profile

[Michal Herko]

Package: virtinst
Version: 1:3.2.0-3
Severity: normal
X-Debbugs-Cc: michal.he...@disroot.org

Dear Maintainer,

I'm trying to use *virt-install* command to create a new virtual machine
under qemu:///system uri.

The command

# virt-install --name lackey --memory 4096 --cdrom Stiahnuté/Windows\ 10\ 
X64\ 20H2\ Pro\ OEM\ ESD\ MULTi-7\ MARCH\ 2021\ 
\{Gen2\}/WIN10X64.MULTi-7.MAR2021.iso --os-variant win10 --disk size=99

fails with error message:

ERRORinternal error: cannot load AppArmor profile 
'libvirt-44fdd1be-0f7f-4c39-ba82-72ed52392b84'

The virtual machine is not created.
The expected outcome is to continue the process of installing the
virtual machine.

The same command executed under ordinary user work correctly.

I am attaching the debug output of virt-install command, and the logs of
libvirtd service.

-- System Information:
Debian Release: 11.0
  APT prefers testing
  APT policy: (500, 'testing')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

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

Versions of packages virtinst depends on:
ii  e2fsprogs 1.46.2-1
ii  genisoimage   9:1.1.11-3.2
ii  gir1.2-libosinfo-1.0  1.8.0-1
ii  python3   3.9.2-3
ii  python3-gi3.38.0-2
ii  python3-libvirt   7.0.0-2
ii  python3-libxml2   2.9.10+dfsg-6.7
ii  python3-requests  2.25.1+dfsg-2

Versions of packages virtinst recommends:
ii  libvirt-clients  7.0.0-3
ii  qemu-utils   1:5.2+dfsg-10+b2
ii  virt-viewer  7.0-2

Versions of packages virtinst suggests:
pn  python3-argcomplete  

Versions of packages virtinst is related to:
ii  libvirt-clients  7.0.0-3
ii  libvirt-daemon   7.0.0-3
ii  libvirt0 7.0.0-3
ii  osinfo-db0.20210215-1

-- no debconf information

Bug#990306: bug on mariadb-server version 1:10.3.29-0+deb10u1

[Jacopo D'oro]

Package: mariadb-server
Version: 1:10.3.29-0+deb10u1

In the last upgrade of maridb-server package for debian buster (version 
1:10.3.29-0+deb10u1), the following bug is now affecting any system that 
installed the update:


https://jira.mariadb.org/browse/MDEV-25714

This bug has been fixed in version 10.3.30 and has been marked as 
emercency because is compromising the results of some type of queries 
(subqueries with group by).
An update or a rollback is necessary, a workaroud suggested by Mariadb 
is also available (optimizer_switch='split_materialized=off')

Bug#989898: [debian-mysql] Bug#989898: Update from upstream

[Faustin Lammler]

Control: -1 forwarded https://jira.mariadb.org/browse/MDEV-25114

vasilis g ,
25/06/2021 – 14:27:50 (+0300):

> Hello,
> 
> I would like to add that upstream has marked this bug as blocker
> (highest severity) and is currently working on a fix. This affects
> galera clusters.
> 
> REF https://jira.mariadb.org/browse/MDEV-25114
> 
> VG
> 
> ___
> pkg-mysql-maint mailing list
> pkg-mysql-ma...@alioth-lists.debian.net
> https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-mysql-maint

-- 
Faustin


signature.asc
Description: PGP signature

Bug#990315: buster-pu: package gcc-mingw-w64/21.3~deb10u1

[Stephen Kitt]

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

Dear release team,

Would it be possible to upload the backported fix for gcc-mingw-w64’s
#989862 to Buster? The debdiff is attached; it’s a minimal, targeted
fix for gcov support.

Regards,

Stephen


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

Kernel: Linux 4.19.0-17-amd64 (SMP w/8 CPU cores)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_GB.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
commit f319345c3caf1dedbfc87654e1853762af3b6d77
Author: Stephen Kitt 
Date:   Tue Jun 15 22:18:31 2021 +0200

Fix gcov handling

When gcov is supported in a cross-compiler setup, GCC assumes that
either the headers are present and shared with the host, or present
and set up in a sysroot, or absent. We have headers which aren’t
shared and aren’t in a sysroot, so we need to tell GCC where they are
*without* specifying them as an argument to --with-headers (the latter
must only be enabled).

Closes: #989862
LP: #1883933, #1920988
(cherry picked from commit 2ee26ff4f275384aa6173ada884929db4d2f1bbf)

diff --git a/debian/changelog b/debian/changelog
index 66834dc..7d18a47 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,11 @@
+gcc-mingw-w64 (21.3~deb10u2) buster; urgency=medium
+
+  * Fix gcov handling: we need to tell GCC that we have headers, without
+telling it where, and then we need to correct its default assumption
+about where they are. Closes: #989862. LP: #1883933, #1920988.
+
+ -- Stephen Kitt   Sat, 12 Jun 2021 18:54:10 +0200
+
 gcc-mingw-w64 (21.3~deb10u1) buster; urgency=medium
 
   * Upload to Buster.
diff --git a/debian/patches/gcov.patch b/debian/patches/gcov.patch
index 4400d53..4e6a83e 100644
--- a/debian/patches/gcov.patch
+++ b/debian/patches/gcov.patch
@@ -1,10 +1,17 @@
-Description: Add __gcov_exit for gcov fallback
+Description: Fix gcov build issues
 Author: Stephen Kitt 
 
 When gcov is not supported on the target, gcc uses a fallback
 do-nothing implementation. That’s missing a __gcov_exit()
 implementation, causing linking errors.
 
+When gcov is supported in a cross-compiler setup, GCC assumes that
+either the headers are present and shared with the host, or present
+and set up in a sysroot, or absent. We have headers which aren’t
+shared and aren’t in a sysroot, so we need to tell GCC where they are
+*without* specifying them as an argument to --with-headers (the latter
+must only be enabled).
+
 --- a/src/libgcc/libgcov-driver.c
 +++ b/src/libgcc/libgcov-driver.c
 @@ -30,6 +30,7 @@
@@ -15,3 +22,14 @@ implementation, causing linking errors.
  #endif
  
  #else /* inhibit_libc */
+--- a/src/gcc/configure.ac
 b/src/gcc/configure.ac
+@@ -2268,7 +2268,7 @@
+   if test "x$with_build_sysroot" != "x"; then
+ target_header_dir="${with_build_sysroot}${native_system_header_dir}"
+   elif test "x$with_sysroot" = x; then
+-target_header_dir="${test_exec_prefix}/${target_noncanonical}/sys-include"
++target_header_dir="${test_exec_prefix}/${target_noncanonical}/include"
+   elif test "x$with_sysroot" = xyes; then
+ 
target_header_dir="${test_exec_prefix}/${target_noncanonical}/sys-root${native_system_header_dir}"
+   else
diff --git a/debian/patches/series1 b/debian/patches/series1
index 048c6bf..7a28c31 100644
--- a/debian/patches/series1
+++ b/debian/patches/series1
@@ -1,3 +1,4 @@
 disable-multilib.patch
 reproducible-sort.patch
 bug-55930.patch
+gcov.patch
diff --git a/debian/patches/series2 b/debian/patches/series2
index 53bd6d3..4cce23c 100644
--- a/debian/patches/series2
+++ b/debian/patches/series2
@@ -1,5 +1,4 @@
 reproducible-s-oscons.patch
-gcov.patch
 wc-file-streams.patch
 refactor-path-construction.patch
 win-std-filesystem.patch
diff --git a/debian/rules b/debian/rules
index e9e4416..4bbb4d1 100755
--- a/debian/rules
+++ b/debian/rules
@@ -187,9 +187,9 @@ CONFFLAGS = \
--libdir=/$(PF)/$(libdir) \
--enable-libstdcxx-time=yes \
--with-tune=generic
-# Tell GCC where the headers are (this enables gcov)
+# Tell GCC we have headers (this enables gcov)
 CONFFLAGS += \
-   --with-headers=/usr/$$target/include
+   --with-headers
 # MinGW-w64 flags
 # version-specific-runtime-libs puts target-specific libraries in
 # /usr/lib/gcc rather than /usr/$(target)

Bug#990305: Introduce ARC support in Perl cross-compiling for Debian

[Evgeniy Didin]

Package: perl
Version: 5.32.1-4

Currently ARC CPU is not supported in Perl cross-compiling for Debian due to 
missing files in debian/cross/ directory.
To enable cross-compiling for ARC the patch was prepared and located here:
https://salsa.debian.org/EvgeniyD/perl/-/commit/b7a9cd6499a91b59585394b1cad10cbdbd4512a4

I am not attaching the patch to this report because the size is more than 
thousand lines.

I am using Debian GNU/Linux 9.13 release, kernel - 3.10.0-693.11.6.el7.x86_64

This patch was tested in rebootstrap build.

Bug#990314: ferm: Pass timestamp option instead of timestamps to SYNPROXY target

[Aggelos Avgerinos]

Package: ferm
Version: 2.4-1
Severity: normal

Dear Maintainer,

In the upstream version v2.3.1 ferm renamed SYNPROXY's timestamp option
to timestamps, presumably following iptables' documentation[1].

However, the current iptables source[2] still calls the option timestamp
and fails when `--timestamps` is passed:

# iptables -j SYNPROXY --timestamps
iptables v1.8.2 (nf_tables): unknown option "--timestamps"

# iptables-legacy -j SYNPROXY --timestamps
iptables v1.8.2 (legacy): unknown option "--timestamps"

The option was renamed[3] back to `timestamp` in version 2.4.1, but
Buster still comes with 2.4 which has this bug.

[1]: https://git.netfilter.org/iptables/tree/extensions/libxt_SYNPROXY.man
[2]: https://git.netfilter.org/iptables/plain/extensions/libxt_SYNPROXY.c
[3]: https://github.com/MaxKellermann/ferm/pull/17

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

Kernel: Linux 4.19.0-9-amd64 (SMP w/8 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8),
LANGUAGE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages ferm depends on:
ii  debconf  1.5.71
ii  init-system-helpers  1.56+nmu1
ii  iptables 1.8.2-4
ii  lsb-base 10.2019051400
ii  perl 5.28.1-6

Versions of packages ferm recommends:
pn  libnet-dns-perl  

ferm suggests no packages.

-- Configuration Files:
/etc/ferm/ferm.conf changed [not included]

-- debconf information excluded

Bug#990313: RFS: thorvg/0.2.2-1 [ITP] -- library for vector-based drawing

[Michal Maciola]

Package: sponsorship-requests
Severity: wishlist

Dear mentors,

I am looking for a sponsor for our package "thorvg":

 * Package name: thorvg
   Version : 0.2.2
   Upstream Author : Michal Maciola 
 * URL : https://www.thorvg.org/
 * License : MIT
 * Vcs : https://github.com/Samsung/thorvg
   Section : libs

It builds those binary packages:

  thorvg - Thor Vector Graphics Library

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

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

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

  dget -x
https://mentors.debian.net/debian/pool/main/t/thorvg/thorvg_0.2.2-1.dsc

Changes since the last upload:

thorvg (0.2.2-1) unstable; urgency=medium

  * Fix Svg gradient to update take into account a stroke and a fill.
  * Fix SVG a crash when stroke-dasharray attribute is not none.
  * Fix SVG to parsing color correctly when format is "rgb(rrr, ggg, bbb)"
  * Fix Scene to return FailedAllocation if it really failed at memory
allocation.

Regards,
-- Michal Maciola



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

Kernel: Linux 4.19.0-17-amd64 (SMP w/2 CPU cores)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_WARN, TAINT_OOT_MODULE,
TAINT_UNSIGNED_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8),
LANGUAGE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /usr/bin/dash

Bug#989844: [Pkg-rust-maintainers] Bug#989844: Cross-compilation support (please package more libstd-rust-dev-*)

[Ximin Luo]

Hi,

Note it's already possible to cross-compile to other linux libc platforms, just 
dpkg --add-architecture $foreign then apt-get install libstd-rust-dev:$foreign.

Yes the *only* thing you have to do is package the libstd. I am unlikely to 
have time for the other platforms you mentioned but am happy to accept patches 
- just take a look at how the windows/wasm32 stuff how is done in the packaging 
and copy that. There is also the difficulty in testing the cross-compiled 
binaries, I personally don't have any Apple systems to test them on, whereas 
for windows/wasm32 there are emulators you can directly run on Debian.

Best,
Ximin

Matt Corallo:
> Package: src:rustc
> Version: 1.48.0+dfsg1-2
> 
> It would be nice to support cross-compilation in the Debian rustc builds, 
> both across-platforms targeting linux and for additional targets in the host 
> platform (eg apple-darwin, assuming its possible to build std without the 
> proprietary apple sysroot), or freebsd/android/etc. I assume the biggest 
> requirement there is just packaging the libstd.
> 
> ___
> Pkg-rust-maintainers mailing list
> pkg-rust-maintain...@alioth-lists.debian.net
> https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-rust-maintainers


-- 
GPG: ed25519/56034877E1F87C35
https://github.com/infinity0/pubkeys.git

Bug#954074: Fn key for Bluetooth Apple Magic Keyboard - simple patch

[Salvatore Bonaccorso]

Source: linux
Source-Version: 4.19.118-1

Hi,

On Mon, Mar 16, 2020 at 12:09:24PM +0100, DVE - Gabriele Brugnoni wrote:
> 
> 
> Package: linux-image-4.19.0-8-amd64
> Version: 4.19.98-1
> 
> 
> Hello.
> 
> I'm using Debian Buster with kernel 4.19.0-8.
> 
> I would like to signal a very small patch that sould be applyied in
> kernel 4.19 and future versions, to fix a problem with Apple magic
> keyboard when connected via Bluetooth.
> 
> This keyboard works well when connected via USB, but when connected via
> Bluethoot, the FN key is not recognised.
> 
> This bugs has been fixed in 2015, as reported here:
> 
> https://bugzilla.kernel.org/show_bug.cgi?id=99881#c41
> 
> but has you can see at the end of the page, the problem is still
> present in new kernels 4.xx.
> 
> There is a little patch that fix the problem, the link is reported at
> the end of the same page, this is the link:
> 
> https://lkml.org/lkml/2020/1/29/61

This patch landed for the 4.19.y series in 4.19.112. Closing
accordingly.

Regards,
Salvatore

Bug#990312: linux-image-5.10.0-8-amd64: GPU usage stuck at 99%

[definetti]

Package: src:linux
Version: 5.10.46-1
Severity: normal
X-Debbugs-Cc: l...@brianzaest.it

Dear Maintainer,

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

   * What led up to the situation?
   * What exactly did you do (or not do) that was effective (or
 ineffective)?
   * What was the outcome of this action?
   * What outcome did you expect instead?

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


-- Package-specific info:
** Version:
Linux version 5.10.0-8-amd64 (debian-ker...@lists.debian.org) (gcc-10 (Debian 
10.2.1-6) 10.2.1 20210110, GNU ld (GNU Binutils for Debian) 2.35.2) #1 SMP 
Debian 5.10.46-1 (2021-06-24)

** Command line:
BOOT_IMAGE=/boot/vmlinuz-5.10.0-8-amd64 
root=UUID=b7d300e2-31aa-4ce0-b7ab-8b78cfbc6765 ro quiet 
psmouse.synaptics_intertouch=1

** Tainted: OE (12288)
 * externally-built ("out-of-tree") module was loaded
 * unsigned module was loaded

** Kernel log:
[3.676155] EDAC amd64: Node 0: DRAM ECC disabled.
[3.692224] iwlwifi :03:00.0: base HW address: dc:41:a9:37:e4:20
[3.706440] thermal thermal_zone0: failed to read out thermal zone (-61)
[3.727515] iwlwifi :03:00.0 wlp3s0: renamed from wlan0
[3.808734] EDAC amd64: F17h_M60h detected (node 0).
[3.808777] EDAC amd64: Node 0: DRAM ECC disabled.
[3.991707] EDAC amd64: F17h_M60h detected (node 0).
[3.991765] EDAC amd64: Node 0: DRAM ECC disabled.
[4.081006] EDAC amd64: F17h_M60h detected (node 0).
[4.081056] EDAC amd64: Node 0: DRAM ECC disabled.
[4.192774] EDAC amd64: F17h_M60h detected (node 0).
[4.192825] EDAC amd64: Node 0: DRAM ECC disabled.
[4.271967] audit: type=1400 audit(1624623745.750:2): apparmor="STATUS" 
operation="profile_load" profile="unconfined" name="libreoffice-xpdfimport" 
pid=1143 comm="apparmor_parser"
[4.272223] audit: type=1400 audit(1624623745.750:3): apparmor="STATUS" 
operation="profile_load" profile="unconfined" name="libreoffice-oopslash" 
pid=1148 comm="apparmor_parser"
[4.272290] audit: type=1400 audit(1624623745.750:4): apparmor="STATUS" 
operation="profile_load" profile="unconfined" name="libreoffice-senddoc" 
pid=1147 comm="apparmor_parser"
[4.272515] audit: type=1400 audit(1624623745.750:5): apparmor="STATUS" 
operation="profile_load" profile="unconfined" name="lsb_release" pid=1141 
comm="apparmor_parser"
[4.272581] audit: type=1400 audit(1624623745.750:6): apparmor="STATUS" 
operation="profile_load" profile="unconfined" name="/usr/bin/man" pid=1144 
comm="apparmor_parser"
[4.272590] audit: type=1400 audit(1624623745.750:7): apparmor="STATUS" 
operation="profile_load" profile="unconfined" name="man_filter" pid=1144 
comm="apparmor_parser"
[4.272593] audit: type=1400 audit(1624623745.750:8): apparmor="STATUS" 
operation="profile_load" profile="unconfined" name="man_groff" pid=1144 
comm="apparmor_parser"
[4.272831] audit: type=1400 audit(1624623745.750:9): apparmor="STATUS" 
operation="profile_load" profile="unconfined" name="nvidia_modprobe" pid=1139 
comm="apparmor_parser"
[4.272834] audit: type=1400 audit(1624623745.750:10): apparmor="STATUS" 
operation="profile_load" profile="unconfined" name="nvidia_modprobe//kmod" 
pid=1139 comm="apparmor_parser"
[4.275932] EDAC amd64: F17h_M60h detected (node 0).
[4.275977] EDAC amd64: Node 0: DRAM ECC disabled.
[4.302950] mc: Linux media interface: v0.10
[4.307579] alg: No test for fips(ansi_cprng) (fips_ansi_cprng)
[4.311487] videodev: Linux video capture interface: v2.00
[4.342541] Bluetooth: Core ver 2.22
[4.342563] NET: Registered protocol family 31
[4.342563] Bluetooth: HCI device and connection manager initialized
[4.342566] Bluetooth: HCI socket layer initialized
[4.342567] Bluetooth: L2CAP socket layer initialized
[4.342569] Bluetooth: SCO socket layer initialized
[4.349013] usbcore: registered new interface driver btusb
[4.351237] Bluetooth: hci0: Firmware revision 0.0 build 121 week 7 2021
[4.443708] EDAC amd64: F17h_M60h detected (node 0).
[4.443763] EDAC amd64: Node 0: DRAM ECC disabled.
[4.444074] Bluetooth: BNEP (Ethernet Emulation) ver 1.3
[4.444076] Bluetooth: BNEP filters: protocol multicast
[4.444080] Bluetooth: BNEP socket layer initialized
[4.484720] uvcvideo: Found UVC 1.10 device Integrated Camera (04f2:b6d0)
[4.491160] input: Integrated Camera: Integrated C as 
/devices/pci:00/:00:02.7/:06:00.0/usb2/2-2/2-2:1.0/input/input18
[4.492410] uvcvideo: Found UVC 1.50 device Integrated Camera (04f2:b6d0)
[4.494065] input: Integrated Camera: Integrated I as 
/devices/pci:00/:00:02.7/:06:00.0/usb2/2-2/2-2:1.2/input/input19
[4.494208] usbcore: registered new interface driver uvcvideo
[4.494211] USB Video Class driver (1.1.1)
[4.555182] Generic FE-GE Realtek PHY r8169-200:00: attached PHY driver 
[Generic FE-GE Realtek PHY] (mii_bus:phy_addr=r8169-200:00, irq=IGNORE)
[4.572296] NET: 

Bug#989674: netselect-apt was unable to obtain a list of valids hosts

[Marcos Raúl Carot]

Please close, this is a duplicate of #920907

Cheers,
Marcos

Bug#901321: Bug#876197: Removed package(s) from unstable

[Helio Loureiro]

Hi Neil,

Thanks for the prompt reply.   I get impressed when a 5 years old bug gets
a fast response.  And stills not solved.

If you open the bug report #876197 and read it carefully and then read this
bug report more carefully yet, you will notice that the referred header
file isn't part of the final binary.

And it surprises me to hear that a simple binary, based on 2 header files,
11 C files and a single Makefile, can be so complex that maintenance as a
debian package becomes unbearable.

If you also read carefully the other mails in this bug, you will notice the
package was indeed removed by a misleading and wrong assumption from the
developer (or would better say packager since not even looking at the
source code was done?).   Which makes it really strange.  You as debian
developers (or maybe just packagers?) are expected to have a high quality
knowledge about packages, mainly to take a final decision to completely
remove them.   Now you come back to me saying you have the power to remove
the package based on a mistaken decision but you don't have the will to fix
it.  Don't you think it is, at the least, odd?

BTW now on do we need to keep track of all DDs thoughts and keep acting
upon their mindset about what they consider not useful anymore?

Before you ask me why not maintain the package myself, I already created my
own deb package and have it working fine here.  My intention was to stop
all the bad decisions that came after this wrongly removal, which affected
several packages that relied on mpage.  The idea was just to fix one
mistake made by a DD instead of forcing several other DDs to change their
packages and remove a supported software.

After 5 years I'm not so sure if my idea to help Debian succeed as
intended.

And that was just one quick check I made.  I'm afraid to find more of this
if I keep looking.

Best Regards,
Helio Loureiro
http://helio.loureiro.eng.br
http://br.linkedin.com/in/helioloureiro
http://twitter.com/helioloureiro
https://github.com/helioloureiro

Bug#990311: Secure boot does not work correctly with nvidia-driver after upgrade to Debian 10.10

[christian_k...@gmx.net]

Package:       shim* (shim-signed, shim-signed-common,
shim-helpers-amd64-signed, shim-unsigned)
Version:        1.36~1
Platform:      amd64

Dear Maintainer,

I'm using Secure Boot for an AMD64 system and I have installed the
non-free nvidia graphics driver (nvidia-driver). To use Secure Boot, I
have to sign the additional NVidia modules manually with the following
steps:

1) create a self-signed certificate using openssl  -> I have got the key
file .der

2) sign all module files with the script: /lib/modules//build/scripts/sign-file

3) import the key with the command: mokutil --import .der

4) Reboot the system and enroll the key after entering the passphrase

These steps works fine for me, but after upgrading to Debian 10.10 it
does no longer work, the kernel cannot start the NVidia driver, and the
error log says, that the kernel cannot find a trusted key. After running
the command "mokutil --list-enrolled" I have got the message "MokListRT
is empty."  Then I have installed an older Debian Version 10.2 with the
older package shim-signed, Version: 1.33+15153313, an now I can see the
imported key using the command mokutil --list-enrolled.

As Workaround I have installed the older Debian Version 10.2 and have
upgraded to 10.10 except the packages for shim, then I have installed
the nvidia driver and then signed the NVidia module files and now I can
boot into a graphical Desktop.

Best regards,
Christian

Bug#989898: Update from upstream

[vasilis g]

Hello,

I would like to add that upstream has marked this bug as blocker
(highest severity) and is currently working on a fix. This affects
galera clusters.

REF https://jira.mariadb.org/browse/MDEV-25114

VG

Bug#990310: RFP: translatelocally -- desktop application for text translation

[Petter Reinholdtsen]

Package: wnpp
Severity: wishlist

* Package name: translatelocally
  Version : n/a, git snapshot
  Upstream Author : Nikolay Bogoychev
* URL : https://www.translatelocally.com/, 
https://github.com/XapaJIaMnu/translateLocally
* License : MIT
  Description : desktop application for text translation

Unlike cloud providers, all processing is performed locally and your
text remains privately on your computer.

-- 
Happy hacking
Petter Reinholdtsen

Bug#990309: gdbserver: i386 (-m32) program on amd64 crashes while being debbugged

[Simon McVittie]

On Fri, 25 Jun 2021 at 11:27:10 +0100, Simon McVittie wrote:
> This seems to be a known bug, fixed in
> 

I confirm that the attached cherry-picks resolve this. Patch 0001
(whitespace change, originally part of a much larger commit) is just to
make patch 0002 apply cleanly; they could be turned into a single patch
if preferred.

smcv
From: Simon Marchi 
Date: Mon, 2 Nov 2020 10:26:14 -0500
Subject: gdbserver: fix a leading space vs tabs issue

[Originally part of a larger commit]

Origin: upstream, 11.1, part of commit:dda83cd783075941aabe9b0292b004b11f00c831
---
 gdbserver/linux-x86-low.cc | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/gdbserver/linux-x86-low.cc b/gdbserver/linux-x86-low.cc
index 79284473f14..bbf6c302e10 100644
--- a/gdbserver/linux-x86-low.cc
+++ b/gdbserver/linux-x86-low.cc
@@ -432,7 +432,7 @@ x86_fill_gregset (struct regcache *regcache, void *buf)
   if (register_size (regcache->tdesc, 0) == 4)
 {
   void *ptr = ((gdb_byte *) buf
-   + i386_regmap[find_regno (regcache->tdesc, "eax")]);
+		   + i386_regmap[find_regno (regcache->tdesc, "eax")]);
 
   *(int64_t *) ptr = *(int32_t *) ptr;
 }
From: Tom de Vries 
Date: Wed, 20 Jan 2021 16:29:30 +0100
Subject: [gdb/server] Don't overwrite fs/gs_base with -m32

Consider a minimal test-case test.c:
...
int main (void) { return 0; }
...
compiled with -m32:
...
$ gcc test.c -m32
...

When running the exec using gdbserver on openSUSE Factory (currently running a
linux kernel version 5.10.5):
...
$ gdbserver localhost:12345 a.out
...
to which we connect in a gdb session, we run into a segfault in the inferior:
...
$ gdb -batch -q -ex "target remote localhost:12345" -ex continue
Program received signal SIGSEGV, Segmentation fault.
0xf7dd8bd2 in init_cacheinfo () at ../sysdeps/x86/cacheinfo.c:761
...

The segfault is caused by gdbserver overwriting $gs_base with 0 using
PTRACE_SETREGS.  After it is overwritten, the next use of $gs in the inferior
will trigger the segfault.

Before linux kernel version 5.9, the value used by PTRACE_SETREGS for $gs_base
was ignored, but starting version 5.9, the linux kernel has support for
intel architecture extension FSGSBASE, which allows users to modify $gs_base,
and consequently PTRACE_SETREGS can no longer ignore the $gs_base value.

The overwrite of $gs_base with 0 is done by a memset in x86_fill_gregset,
which was added in commit 9e0aa64f551 "Fix gdbserver qGetTLSAddr for
x86_64 -m32".  The memset intends to zero-extend 32-bit registers that are
tracked in the regcache to 64-bit when writing them into the PTRACE_SETREGS
data argument.  But in addition, it overwrites other registers that are
not tracked in the regcache, such as $gs_base.

Fix the segfault by redoing the fix from commit 9e0aa64f551 in minimal form.

Tested on x86_64-linux:
- openSUSE Leap 15.2 (using kernel version 5.3.18):
  - native
  - gdbserver -m32
  - -m32
- openSUSE Factory (using kernel version 5.10.5):
  - native
  - m32

gdbserver/ChangeLog:

2021-01-20  Tom de Vries  

	* linux-x86-low.cc (collect_register_i386): New function.
	(x86_fill_gregset):  Remove memset.  Use collect_register_i386.

Origin: upstream, 11.1, commit:037e8112b9794a633248e5aa5943f3be273e0a20
---
 gdbserver/linux-x86-low.cc | 55 +++---
 1 file changed, 33 insertions(+), 22 deletions(-)

diff --git a/gdbserver/linux-x86-low.cc b/gdbserver/linux-x86-low.cc
index bbf6c302e10..ea95f3ea2ae 100644
--- a/gdbserver/linux-x86-low.cc
+++ b/gdbserver/linux-x86-low.cc
@@ -397,6 +397,35 @@ x86_target::low_cannot_fetch_register (int regno)
   return regno >= I386_NUM_REGS;
 }
 
+static void
+collect_register_i386 (struct regcache *regcache, int regno, void *buf)
+{
+  collect_register (regcache, regno, buf);
+
+#ifdef __x86_64__
+  /* In case of x86_64 -m32, collect_register only writes 4 bytes, but the
+ space reserved in buf for the register is 8 bytes.  Make sure the entire
+ reserved space is initialized.  */
+
+  gdb_assert (register_size (regcache->tdesc, regno) == 4);
+
+  if (regno == RAX)
+{
+  /* Sign extend EAX value to avoid potential syscall restart
+	 problems.
+
+	 See amd64_linux_collect_native_gregset() in
+	 gdb/amd64-linux-nat.c for a detailed explanation.  */
+  *(int64_t *) buf = *(int32_t *) buf;
+}
+  else
+{
+  /* Zero-extend.  */
+  *(uint64_t *) buf = *(uint32_t *) buf;
+}
+#endif
+}
+
 static void
 x86_fill_gregset (struct regcache *regcache, void *buf)
 {
@@ -411,32 +440,14 @@ x86_fill_gregset (struct regcache *regcache, void *buf)
 
   return;
 }
-
-  /* 32-bit inferior registers need to be zero-extended.
- Callers would read uninitialized memory otherwise.  */
-  memset (buf, 0x00, X86_64_USER_REGS * 8);
 #endif
 
   for (i = 0; i < I386_NUM_REGS; i++)
-collect_register (regcache, i, ((char *) buf) 

Bug#978065: lxc: After upgrade lxc to 4.0.5-1, cannot start with lxc.cap.drop sys_admin

[Andras Korn]

On Fri, Jun 11, 2021 at 09:59:51PM +0200, Pierre-Elliott Bécue wrote:

Hi,

> > FWIW, both host and guest use runit, so systemd is not involved; runit 
> > doesn't interfere with cgroups or capabilities on its own in any way.
> 
> It's not possible if the init in the container is systemd, as far as I
> know.

That's as may be, but my systems don't use systemd; like I said above, it's all 
runit. I'm still hitting the issue.

András

-- 
   Mary had a little lamb, she tied it to a pylon.
  A thousand volts went up its ass and turned it into Nylon.

Bug#990157: privoxy: legacy conffiles leftover

[Roland Rosenfeld]

Hi Christoph!

On Mo, 21 Jun 2021, Christoph Anton Mitterer wrote:

> Package: privoxy
> Version: 3.0.32-2
> Severity: normal

> Apparently the package used to contain the conffiles:
> /etc/privoxy/config
> /etc/privoxy/standard.action
> /etc/privoxy/global.action
> but no longer does so.

Thanks for the trigger, you are right, these files are no longer
conffiles and I should at least remove standard.action and
global.action, which were removed in 3.0.11-1.

But I'm not fully sure, whether using rm_conffile for
/etc/privoxy/config is a good idea.  Sure, it is no longer a conffile
nor is it contained in the privoxy package since 3.0.24-2, but it is
handled using ucf since then (including removal on purge).

In my understanding of dpkg-maintscript-helper(1), a file that is
handled by ucf should _not_ be handled bai dpkg-mainscript-helper
rm_conffile.  Did I get this wrong?

Greetings
Roland

Bug#990309: gdbserver: i386 (-m32) program on amd64 crashes while being debbugged

[Simon McVittie]

Package: gdbserver
Version: 10.1-2
Severity: important
Tags: patch fixed-upstream
Forwarded: 
https://sourceware.org/git/?p=binutils-gdb.git;a=commitdiff_plain;h=037e8112b9794a633248e5aa5943f3be273e0a20

When testing an i386 (-m32) program on an x86_64 host using gdbserver,
the program under test crashes with a segmentation fault.

Steps to reproduce:

$ cat > test.c
int main (void) { return 0; }
$ gcc -m32 -otest32 test.c
$ gdbserver localhost:12345 ./test32

and in another terminal

$ gdb -batch -q -ex "target remote localhost:12345" -ex continue

Expected result: test32 runs to completion

Actual result:

Program received signal SIGSEGV, Segmentation fault.
0xf7ddf3f7 in __ctype_init () from target:/lib/i386-linux-gnu/libc.so.6

This seems to be a known bug, fixed in
,
as applied in e.g. Arch Linux's version of gdb 10.2. I'm waiting for a
backport of that change to compile locally so I can try it.

Thanks,
smcv

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

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

Versions of packages gdbserver depends on:
ii  libc6   2.31-12
ii  libgcc-s1   10.2.1-6
ii  libstdc++6  10.2.1-6

gdbserver recommends no packages.

gdbserver suggests no packages.

-- no debconf information

Bug#989814: kodi: Kodi UI breaks with tr_TR.UTF-8 charset.

[Hakan Bayındır]

Hello Vasyl,

Sorry for my late reply. Your first reply to this bug didn’t generate a 
notification, so I missed your feedback on Sunday. Actually, there’s an edge 
case in Turkish language which doesn’t present in other languages, and our late 
arrival to localization scene allowed this edge case to be unhandled for a very 
long time.

In English and most other languages i.upper() = I and I.lower() = i. However, 
in Turkish, the case is as follows:

i.upper() = İ
İ.lower() = i
ı.upper() = I
I.lower() = ı

Hence, we have four letters:. ı, I, i, İ. When a code piece doesn’t expect İ or 
ı, or changes cases of these letters and end up with English counterparts,  
things can go wrong. Sometimes subtly, sometimes horribly wrong. This is what’s 
happening there most probably.

Similarly, when locale is set to Turkish and a piece of code gets İ instead of 
an I when it calls i.upper(), things break again.

We have other letters ü/Ü, ğ/Ğ, ş/Ş, ç/Ç, ö/Ö. However, some of these are 
present in other languages too, and their lower/upper conversion are not tricky.

Coding Horror has a nice write-up about this issue: 
https://blog.codinghorror.com/whats-wrong-with-turkey/ which sums up the issue 
probably better than me.

I’ll provide similar information to the official bugzilla today.

Please don't hesitate to contact for any questions,

Best regards,

Hakan


> On 24 Jun 2021, at 23:10, Vasyl Gello  wrote:
> 
> Package: kodi
> Followup-For: Bug #989814
> X-Debbugs-Cc: aure...@debian.org, mat...@debian.org, ha...@bayindir.org
> 
> Control: reassign -1 glibc
> Control: retitle -1 Broken CTYPE in Turkish and Azeri UTF-8 locales
> Control: severity -1 serious
> 
> Dear colleagues,
> 
> I was able to track down the issue reported in Kodi and unfortunately
> it is a glibc / locales issue.
> 
> Specifically, all functions relying on LC_CTYPE set to Turkish or Azeri
> UTF-8 locales (like 'tolower()' for example) produce incorrect results.
> 
> I linked the reproducer in Kodi upstream Github issue:
> https://github.com/xbmc/xbmc/issues/19883#issuecomment-867911187
> 
> I upgraded the severity of the bug because the flawed behavior of locale
> functions definitely needs further investigation.
> 
> Hakan, maybe you can shed somelight on what can be wrong with lower / upper
> conversions in Turkish?
> 
> 
> Sincerely,
> Vasyl
> 
> -- System Information:
> Debian Release: 11.0
>  APT prefers unstable-debug
>  APT policy: (500, 'unstable-debug'), (500, 'buildd-unstable'), (500, 
> 'unstable')
> Architecture: amd64 (x86_64)
> 
> Kernel: Linux 5.10.0-7-amd64 (SMP w/6 CPU threads)
> Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
> Locale: LANG=C, LC_CTYPE=C (charmap=UTF-8) (ignored: LC_ALL set to 
> en_US.UTF-8), LANGUAGE not set
> Shell: /bin/sh linked to /bin/dash
> Init: unable to detect
> 
> Versions of packages kodi depends on:
> pn  kodi-bin   
> pn  kodi-data  
> 
> Versions of packages kodi recommends:
> pn  kodi-repository-kodi | kodi-repository  
> pn  kodi-visualization-spectrum 
> 
> kodi suggests no packages.

Bug#990303: trafficserver: Apache Traffic Server is vulnerable to various HTTP/1.x and HTTP/2 attacks

[Moritz Muehlenhoff]

On Fri, Jun 25, 2021 at 08:59:25AM +0200, Lorenzo Maurizi wrote:
> Package: trafficserver
> Version: 8.0.2+ds-1+deb10u4
> Severity: grave
> Tags: security
> Justification: user security hole
> 
> CVE:
> CVE-2021-27577 Incorrect handling of url fragment leads to cache poisoning
> CVE-2021-32565 HTTP Request Smuggling, content length with invalid charters
> CVE-2021-32566 Specific sequence of HTTP/2 frames can cause ATS to crash
> CVE-2021-32567 Reading HTTP/2 frames too many times
> CVE-2021-35474 Dynamic stack buffer overflow in cachekey plugin

For 8.1.x these are fixed by 
https://github.com/apache/trafficserver/commit/b82a3d192f995fb9d78e1c44d51d9acca4783277

I've add full references to the Security Tracker:
https://security-tracker.debian.org/tracker/CVE-2021-35474
https://security-tracker.debian.org/tracker/CVE-2021-32567
https://security-tracker.debian.org/tracker/CVE-2021-32566
https://security-tracker.debian.org/tracker/CVE-2021-32565
https://security-tracker.debian.org/tracker/CVE-2021-27577

Jean Baptiste, can prepare updates for buster-security?

Cheers,
Moritz

Bug#976343: ruby-diaspora-federation: ftbfs with ruby-faraday 1.0

[Pirate Praveen]

Control: forwarded -1 
https://github.com/diaspora/diaspora_federation/pull/116


On Thu, 03 Dec 2020 23:25:20 +0530 Pirate Praveen 
 wrote:
> ruby-diaspora-federation ftbfs/fails autopkgtest with ruby-faraday 
1.0


Reported upstream
https://github.com/diaspora/diaspora_federation/pull/116

Bug#990308: FTBFS on non-vanilla system, pthread detection

[Eduard Bloch]

Package: qtcreator
Version: 4.14.1-1
Severity: important
Tags: ftbfs

Hi,

see below, smells like missing -lpthread in the minimum linker flags of
subsequent tests.

What was performed:
$ apt source qtcreator
$ cd ...
$ apt build-dep qtcreator
$ debuild
 dpkg-buildpackage -us -uc -ui
dpkg-buildpackage: Information: Quellpaket qtcreator
dpkg-buildpackage: Information: Quellversion 4.14.1-1
dpkg-buildpackage: Information: Quelldistribution unstable
dpkg-buildpackage: Information: Quelle geändert durch Pino Toscano 

dpkg-buildpackage: Warnung: von langen OpenPGP-Schlüsselkennungen wird klar 
abgeraten; bitte verwenden Sie stattdessen Fingerabdrücke in -k oder 
DEB_SIGN_KEYID
 dpkg-source --before-build .
dpkg-buildpackage: Information: Host-Architektur amd64
 debian/rules clean
dh clean --builddirectory=builddir
   dh_auto_clean -O--builddirectory=builddir
   dh_autoreconf_clean -O--builddirectory=builddir
   dh_clean -O--builddirectory=builddir
 dpkg-source -b .
dpkg-source: Information: Quellformat »3.0 (quilt)« wird verwendet
dpkg-source: Information: qtcreator wird unter Benutzung des existierenden 
./qtcreator_4.14.1.orig.tar.xz gebaut
dpkg-source: Information: Patchliste aus debian/patches/series wird verwendet
dpkg-source: Information: qtcreator wird in qtcreator_4.14.1-1.debian.tar.xz 
gebaut
dpkg-source: Information: qtcreator wird in qtcreator_4.14.1-1.dsc gebaut
 debian/rules binary
dh binary --builddirectory=builddir
   dh_update_autotools_config -O--builddirectory=builddir
   dh_autoreconf -O--builddirectory=builddir
   debian/rules override_dh_auto_configure
make[1]: Verzeichnis „/tmp/qtcreator-4.14.1“ wird betreten
dh_auto_configure --buildsystem=cmake -- \
-DBUILD_DEVELOPER_DOCS=ON \
-DBUILD_QBS=OFF \
-DWITH_DOCS=ON
cd builddir && cmake -DCMAKE_INSTALL_PREFIX=/usr 
-DCMAKE_BUILD_TYPE=None -DCMAKE_INSTALL_SYSCONFDIR=/etc 
-DCMAKE_INSTALL_LOCALSTATEDIR=/var -DCMAKE_EXPORT_NO_PACKAGE_REGISTRY=ON 
-DCMAKE_FIND_PACKAGE_NO_PACKAGE_REGISTRY=ON -DCMAKE_INSTALL_RUNSTATEDIR=/run 
-DCMAKE_SKIP_INSTALL_ALL_DEPENDENCY=ON "-GUnix Makefiles" 
-DCMAKE_VERBOSE_MAKEFILE=ON -DCMAKE_INSTALL_LIBDIR=lib/x86_64-linux-gnu 
-DBUILD_DEVELOPER_DOCS=ON -DBUILD_QBS=OFF -DWITH_DOCS=ON ..
-- The C compiler identification is GNU 10.2.1
-- The CXX compiler identification is GNU 10.2.1
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Check for working C compiler: /usr/lib/ccache/cc - skipped
-- Detecting C compile features
-- Detecting C compile features - done
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Check for working CXX compiler: /usr/lib/ccache/c++ - skipped
-- Detecting CXX compile features
-- Detecting CXX compile features - done
-- Looking for pthread.h
-- Looking for pthread.h - found
-- Performing Test CMAKE_HAVE_LIBC_PTHREAD
-- Performing Test CMAKE_HAVE_LIBC_PTHREAD - Failed
-- Looking for pthread_create in pthreads
-- Looking for pthread_create in pthreads - not found
-- Looking for pthread_create in pthread
-- Looking for pthread_create in pthread - found
-- Found Threads: TRUE  
-- Found ZLIB: /usr/lib/x86_64-linux-gnu/libz.so (found version "1.2.11") 
CMake Error at /usr/lib/llvm-12/lib/cmake/clang/ClangTargets.cmake:699 
(message):
  The imported target "clangBasic" references the file

 "/usr/lib/llvm-12/lib/libclangBasic.a"

  but this file does not exist.  Possible reasons include:

  * The file was deleted, renamed, or moved to another location.

  * An install or uninstall procedure did not complete successfully.

  * The installation package was faulty and contained

 "/usr/lib/llvm-12/lib/cmake/clang/ClangTargets.cmake"

  but not all the files it references.

Call Stack (most recent call first):
  /usr/lib/cmake/clang-12/ClangConfig.cmake:20 (include)
  cmake/FindClang.cmake:1 (find_package)
  CMakeLists.txt:55 (find_package)


-- Configuring incomplete, errors occurred!
See also "/tmp/qtcreator-4.14.1/builddir/CMakeFiles/CMakeOutput.log".
See also "/tmp/qtcreator-4.14.1/builddir/CMakeFiles/CMakeError.log".
cd builddir && tail -v -n \+0 CMakeCache.txt
==> CMakeCache.txt <==
# This is the CMakeCache file.
# For build in directory: /tmp/qtcreator-4.14.1/builddir
# It was generated by CMake: /usr/bin/cmake
# You can edit this file to change values found and used by cmake.
# If you do not want to change any of the values, simply exit the editor.
# If you do want to change a value, simply edit, save, and exit the editor.
# The syntax for the file is as follows:
# KEY:TYPE=VALUE
# KEY is the name of a variable in the cache.
# TYPE is a hint to GUIs for the type of VALUE, DO NOT EDIT TYPE!.
# VALUE is the current value for the KEY.


# EXTERNAL cache entries


//No help, variable specified on the command line.
BUILD_DEVELOPER_DOCS:UNINITIALIZED=ON

//Build executables by default. This can be used to build all executables
// by default, or none.

Bug#990243: Info received ("fallocate -vd" reports incorrect result)

[Kevin Price]

tags 990243 -lfs
retitle 990243 fallocate -d fails on last block if < block size
thanks

Dear maintainer,
I took a closer look at this bug. Please note that I'm using ext4 with
block size=4096.

No need to fetch debian-10.10.0-amd64-DLBD-2.iso iot reproduce this bug.
This file's last block happens to be 2048 zero-bytes, triggering this
bug. I'm seeing the same behavior with a file that consists of a single
zero, or of 4095 zeros. I conclude that it happens whenever the file's
last block contains only zeros, but is shorter than block size.

fallocate -d seems to attempt to unallocate that last block if it
contains only zeros, and it even updates the file's mtime. The
unallocation is reported, but doesn't effectively happen.

My suggestion is to fix fallocate, enabling it to unallocate the last
block even if it is shorter than block size.

Best
Kevin

Bug#982758: webext-browserpass: Failed to install on upgrade to bullseye

[Axel Beckert]

Hi Michael,

Michael Meskes wrote:
> Given that freeze is nearing and nobody's volunteering any additional
> information

Sorry, still didn't get to that one desktop upgrade (at work) which is
still left for me to do.

> and the bug has proven to be not reproducible, at least for me, I
> downgrade it again.

Thanks, I agree that this is currently the best solution.

> I'm more than willing to look into it again and fix it once we
> identify the reason.

I'm also still intending to dig deeper here, but due to constraints at
work can't promise that I'll manage that dist-upgrade before the
full-freeze, sorry.

Regards, Axel
-- 
 ,''`.  |  Axel Beckert , https://people.debian.org/~abe/
: :' :  |  Debian Developer, ftp.ch.debian.org Admin
`. `'   |  4096R: 2517 B724 C5F6 CA99 5329  6E61 2FF9 CD59 6126 16B5
  `-|  1024D: F067 EA27 26B9 C3FC 1486  202E C09E 1D89 9593 0EDE

Bug#989814: kodi: Kodi UI breaks with tr_TR.UTF-8 charset.

[Vasyl Gello]

Hi Hakan!

> I’ll provide similar information to the official bugzilla today.

This means glibc is correct and my proposed fix for Kodi upstream ( 
https://github.com/xbmc/xbmc/pull/19905 ) is technically not…

Does it make sense to catch this edge case in the linked PR rather than just 
fall back into non-UTF-8 C locale if "Turkish I" problem is detected?
-- 
Vasyl Gello
==
Certified SolidWorks Expert

Mob.:+380 (98) 465 66 77

E-Mail: vasek.ge...@gmail.com

Skype: vasek.gello
==
호랑이는 죽어서 가죽을 남기고 사람은 죽어서 이름을 남긴다

Bug#990304: barman: pg 13 expects wal_keep_size, not wal_keep_segments

[Jérémy Lal]

Package: barman
Version: 2.12
Severity: important

See
https://github.com/EnterpriseDB/barman/issues/302
and this is fixed in commit
https://github.com/EnterpriseDB/barman/commit/45ccd9d2f315ec208eee778eba1333c0aa4a4460

This is going to hit Bullseyes users.
Severity might need to be rised - after all it makes barman somewhat broken.

Jérémy


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

Kernel: Linux 5.10.0-7-amd64 (SMP w/4 CPU threads)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=fr_FR.utf8, LC_CTYPE=fr_FR.utf8 (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 barman depends on:
ii  adduser3.118
ii  python33.9.2-3
pn  python3-barman 
ii  python3-pkg-resources  52.0.0-3
ii  rsync  3.2.3-4

Versions of packages barman recommends:
ii  openssh-client1:8.4p1-5
ii  openssh-server1:8.4p1-5
ii  postgresql-client 13+225
ii  postgresql-client-13 [postgresql-client]  13.3-1

Versions of packages barman suggests:
pn  barman-cli  
pn  repmgr  

Bug#989929: Suddenly restarting fetchmail started to fail with error about its global pidfile

[Francesco P. Lovergine]

On Thu, Jun 24, 2021 at 07:11:02PM +0200, László Böszörményi (GCS) wrote:

Control: tags -1 +pending moreinfo

On Wed, Jun 16, 2021 at 10:00 AM Francesco P. Lovergine
 wrote:

This is currently run on testing since ages. I had to restart due to a changed
fingerprint and the global service started to fail with:

[...]

giu 16 08:07:28 klecker fetchmail[846499]: fetchmail: lock creation failed, pidfile 
"/run/fetchmail/fetchmail.pid": File o directory non esistente

Thanks for the report and the proposed fix! Can you please check if
the updated package[1] is fine for you now?

Cheers,
Laszlo/GCS
[1] dget -x https://people.debian.org/~gcs/fetchmail_6.4.16-2.dsc



Yes it is working. 


--
Francesco P. Lovergine

Bug#977346: unattended-upgrades: Does not find packages, that can be upgraded

[Paul Menzel]

Dear Balint,


I am sorry for the late reply.


Am 14.12.20 um 12:22 schrieb Balint Reczey:


On Mon, Dec 14, 2020 at 12:06 PM Paul Menzel  wrote:



Am 14.12.20 um 11:58 schrieb Balint Reczey:


On Mon, Dec 14, 2020 at 10:03 AM Paul Menzel  wrote:


[…]


On one user laptop with Debian sid/unstable, unattended-upgrades does
not find upgradable packages.

   From a dry run:

```
2020-12-14 09:51:17,335 INFO Checking if system is running on battery is 
skipped. Please install powermgmt-base package to check power status and skip 
installing updates when the system is running on battery.
2020-12-14 09:51:17,339 INFO Starting unattended upgrades script
2020-12-14 09:51:17,339 INFO Allowed origins are: 
origin=Debian,codename=buster,label=Debian, 
origin=Debian,codename=buster,label=Debian-Security, 
origin=Debian,codename=buster-security,label=Debian-Security
2020-12-14 09:51:17,339 INFO Initial blacklist:
2020-12-14 09:51:17,339 INFO Initial whitelist (not strict):
2020-12-14 09:51:22,899 INFO No packages found that can be upgraded unattended 
and no pending auto-removals
2020-12-14 09:51:22,900 INFO The list of kept packages can't be calculated in 
dry-run mode.
```

But upgradable packages are there:

```
$ apt list --upgradable
Listing... Done
autoconf/unstable,unstable 2.69-12 all [upgradable from: 2.69-11.1]
dde-qt5integration/unstable 5.0.0-2.1+b2 amd64 [upgradable from: 5.0.0-2.1+b1]
fonts-font-awesome/unstable,unstable 5.0.10+really4.7.0~dfsg-4 all [upgradable 
from: 5.0.10+really4.7.0~dfsg-2]
gcc-8-base/unstable 8.4.0-5 amd64 [upgradable from: 8.3.0-7]
gir1.2-gdkpixbuf-2.0/unstable 2.42.2+dfsg-1 amd64 [upgradable from: 
2.40.0+dfsg-10]

...

systemd/unstable 247.1-4 amd64 [upgradable from: 247.1-3]
udev/unstable 247.1-4 amd64 [upgradable from: 247.1-3]
$ sudo apt upgrade
Reading package lists... Done
Building dependency tree
Reading state information... Done
Calculating upgrade... Done
The following packages were automatically installed and are no longer
required:
 libboost-filesystem1.71.0 libboost-iostreams1.71.0
Use 'sudo apt autoremove' to remove them.
The following NEW packages will be installed:
 libboost-filesystem1.74.0 libboost-iostreams1.74.0
libboost-thread1.74.0 libdeflate0
The following packages have been kept back:
 gcc-8-base libboost-dev
The following packages will be upgraded:
 autoconf dde-qt5integration fonts-font-awesome gir1.2-gdkpixbuf-2.0

...

systemd-timesyncd udev
116 upgraded, 4 newly installed, 0 to remove and 2 not upgraded.
Need to get 101 MB of archives.
After this operation, 6,711 kB of additional disk space will be used.
Do you want to continue? [Y/n]
```

Is that expected, or am I missing something?


This (or something like that) is expected in unstable due to the fix in #960966.

Please change /etc/apt/apt.conf.d/50unattended-upgrades if you want
u-u to try very hard to upgrade things:

...
// When APT fails to mark a package to be upgraded or installed try adjusting
// candidates of related packages to help APT's resolver in finding a solution
// where the package can be upgraded or installed.
// This is a workaround until APT's resolver is fixed to always find a
// solution if it exists. (See Debian bug #711128.)
// The fallback is enabled by default, except on Debian's sid release because
// uninstallable packages are frequent there.
// Disabling the fallback speeds up unattended-upgrades when there are
// uninstallable packages at the expense of rarely keeping back packages which
// could be upgraded or installed.
// Unattended-Upgrade::Allow-APT-Mark-Fallback "true";


Thank you for the hint, but I still do not understand, why it works on
other systems. Are the kept back packages a problem? Could a log message
be added to `unattended-upgrades.log`?


APT found the upgrades on those, probably because different packages
are installed.

Yes, kept back packages are the ones making APT's work harder in
finding the upgradable ones.

When running without --dry-mode u-u already prints out more
information about held back packages.

More explanation _could_ be added, but this workaround is on by
default only in Sid and people using Sid are expected to figure out
things on their own thus I don't plan working on that part. Patches
are still welcome.


I also ran into the problem with no held back packages involved. Could 
the problem be that the allowed origins for some reason do not match *sid*?


2020-12-14 09:51:17,339 INFO Allowed origins are: 
origin=Debian,codename=buster,label=Debian, 
origin=Debian,codename=buster,label=Debian-Security, 
origin=Debian,codename=buster-security,label=Debian-Security


or

2021-06-18 11:22:11,763 INFO Erlaubte Ursprünge sind: 
origin=Debian,codename=bullseye,label=Debian, 
origin=Debian,codename=bullseye,label=Debian-Security, 
origin=Debian,codename=bullseye-security,label=Debian-Security


`apt-cache policy show` contains:

 500 http://mirror.netzwerge.de/debian sid/main amd64 Packages
 

Bug#982758: webext-browserpass: Failed to install on upgrade to bullseye

[Michael Meskes]

severity 982758 important
thanks

> I tried with a stable chroot, then installed all the webext* packages you have
> installed and then upgraded webext-browserpass. Works like a charm.

By now I've ran more test up to a full system dist-upgrade with all webext* 
packages installed, not a single failure.

> > Good question. My gut feeling at least says that the RC severity is
> > justified as quite some people ran into it and it actually causes apt
> > to abort in a quite nasty way.
> 
> I see your point, the problem is with this setting nobody is getting the
> software because of some of us having issues in the upgrade. I'd love to get
> this fixed before the freeze, but no matter what I tried I cannot reproduce.

Given that freeze is nearing and nobody's volunteering any additional
information and the bug has proven to be not reproducible, at least for me, I
downgrade it again. Yes, it can be very severe but removing the package for
everyone doesn't seem right either. Maybe by keeping it in we will get more
data to find out where the problem lies.

I'm more than willing to look into it again and fix it once we identify the 
reason.

Thanks,
Michael
-- 
Michael Meskes
Michael at Fam-Meskes dot De
Michael at Meskes dot (De|Com|Net|Org)
Meskes at (Debian|Postgresql) dot Org

Bug#990303: trafficserver: Apache Traffic Server is vulnerable to various HTTP/1.x and HTTP/2 attacks

[Lorenzo Maurizi]

Package: trafficserver
Version: 8.0.2+ds-1+deb10u4
Severity: grave
Tags: security
Justification: user security hole



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

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

Versions of packages trafficserver depends on:
ii  adduser  3.118
ii  libbrotli1   1.0.7-2+deb10u1
ii  libc62.28-10
ii  libcap2  1:2.25-2
ii  libcurl4 7.64.0-4+deb10u2
ii  libgcc1  1:8.3.0-6
ii  libgeoip11.6.12-1
ii  libhwloc51.11.12-3
ii  libluajit-5.1-2  2.1.0~beta3+dfsg-5.1
ii  liblzma5 5.2.4-1
ii  libncursesw6 6.1+20181013-2+deb10u2
ii  libpcre3 2:8.39-12
ii  libssl1.11.1.1d-0+deb10u6
ii  libstdc++6   8.3.0-6
ii  libtcl8.68.6.9+dfsg-2
ii  libtinfo66.1+20181013-2+deb10u2
ii  libunwind8   1.2.1-10~deb10u1
ii  libyaml-cpp0.6   0.6.2-4
ii  lsb-base 10.2019051400
ii  perl 5.28.1-6+deb10u1
ii  zlib1g   1:1.2.11.dfsg-1

trafficserver recommends no packages.

Versions of packages trafficserver suggests:
pn  trafficserver-experimental-plugins  

-- Configuration Files:
/etc/trafficserver/ip_allow.config changed [not included]
/etc/trafficserver/records.config changed [not included]

-- no debconf information

Description:
ATS is vulnerable to various HTTP/1.x and HTTP/2 attacks

CVE:
CVE-2021-27577 Incorrect handling of url fragment leads to cache poisoning
CVE-2021-32565 HTTP Request Smuggling, content length with invalid charters
CVE-2021-32566 Specific sequence of HTTP/2 frames can cause ATS to crash
CVE-2021-32567 Reading HTTP/2 frames too many times
CVE-2021-35474 Dynamic stack buffer overflow in cachekey plugin

Version Affected:
ATS 7.0.0 to 7.1.12
ATS 8.0.0 to 8.1.1
ATS 9.0.0 to 9.0.1

Mitigation:
7.x users should upgrade to 8.1.2 or 9.0.2, or later versions 8.x users should 
upgrade to 8.1.2 or later versions 9.x users should upgrade to 9.0.2 or later 
versions

Bug#990302: ITP: bulk-extractor -- A stream-based forensics tool for triage and cross-evidence analysis, which scans the media and extracts recognizable content

[Jan Gru]

Package: wnpp
X-Debbugs-Cc: debian-de...@lists.debian.org, 
debian-security-to...@lists.debian.org

Owner: Jan Gru 
Severity: wishlist

* Package name: bulk-extractor
  Version : 1.6.0
  Upstream Author : Simson L. Garfinkel 
* URL : https://github.com/simsong/bulk_extractor
* License : MIT and CC0
  Programming Lang: C++, Python (and Java for the BEViewier, probably not 
packaged)
  Description : A stream-based forensics tool for triage and cross-evidence 
analysis, which scans the media and extracts recognizable content


bulk_extractor is a program for bulk data extraction and analysis, it carves 
for relevant features such as email addresses, credit card numbers, URLs,
and other types of information from digital evidence files in a stream-based 
manner by parallelized processing blocks to omit disk seeking.

** Why is this package relevant?
It is a useful tool for forensic investigations, because it is way more than 
just another file carver. The program provides several unusual capabilities 
including:

- It finds email addresses, URLs and credit card numbers that other tools miss 
because it can process compressed data (like ZIP, PDF and GZIP files) and 
incomplete or partially corrupted data.
- It can carve JPEGs, office documents and other kinds of files out of 
fragments of compressed data. It will detect and carve encrypted RAR files.
- It builds word lists based on all of the words found within the data, even 
those in compressed files that are in unallocated space. Those word lists can 
be useful for password cracking.
- It is multi-threaded; running bulk_extractor on a computer with twice the 
number of cores typically makes it complete a run in half the time.
- It creates histograms showing the most common email addresses, URLs, domains, 
search terms and other kinds of information on the drive.

The program is authored by the renowned forensics researcher Simson L. 
Garfinkel, who is probably most recognized for his work on DFXML at the Naval 
Postgraduate School (NPS) and the National Institute of Standards and 
Technology (NIST). It provides rich documentation -- for the end-users as well 
as for potential contributors [0].

To sum it up, bulk_extractor has great potential for improving triage and 
automatation workflows within digital forensics and should be therefore 
included in Debian's package sources. 

** Resolved issues
bulk_extractor is already packaged in Kali [1], but had licensing issues until 
recently.
To be more precise, it linked code with OpenSSL while not explicitly permitting 
it and used a the modified MIT-license from the
JSON-project, which is considered non-free and not DFSG-compliant. To overcome 
this issues I resolved this issues in cooperation
with upstream by sending two recent patches [2], which were already accepted.

** Maintanance plan
I plan to maintain it within the pkg-security-team's repository on salsa, where 
a lot of forensics packages live [3].
I am looking for a sponsor of this package, who would be ideally a member of 
the a/m team.

Best regards
   Jan

[0] See http://digitalcorpora.org/downloads/bulk_extractor/BEUsersManual.pdf, 
https://digitalcorpora.s3.amazonaws.com/downloads/bulk_extractor/BEProgrammersManual.pdf
 and 
https://digitalcorpora.s3.amazonaws.com/downloads/bulk_extractor/BEWorkedExamplesStandalone.pdf
[1] See https://tools.kali.org/forensics/bulk-extractor
[2] See https://github.com/simsong/bulk_extractor/issues/168, 
https://github.com/simsong/bulk_extractor/pull/169 and 
https://github.com/simsong/bulk_extractor/pull/170
[3] See https://salsa.debian.org/pkg-security-team/

  

Bug#288778: Un service d'assistance

[Колесникова Светлана Алексеевна]

* Votre boîte aux lettres a dépassé sa limite de quota.


  Vous recevez cet avertissement maintenant que votre boîte aux lettres a 
atteint 180 000 Ko. Vous ne pourrez peut-être pas envoyer ou recevoir de 
nouveaux messages tant que vous n'aurez pas mis à jour la taille de votre boîte 
aux lettres.

  Pour libérer de l'espace, CLIQUEZ ICI et 
remplissez vos coordonnées pour mettre à jour et également supprimer les 
éléments que vous n'utilisez plus ou les déplacer vers votre fichier de 
dossiers personnels (.pst).

Remarque : votre boîte aux lettres se fermera si vous ne parvenez pas à mettre 
à jour ou si vous ne suivez pas les instructions fournies ci-dessus, mettez à 
jour la taille de votre boîte aux lettres.

administrateur du système

* Centre d'aide