Bug#991149: ITP: icinga-php-thirdparty -- Icinga PHP Thirdparty libraries for Icinga Web 2

[Sebastiaan Couwenberg]

On 7/16/21 10:26 PM, Bastian Blank wrote:
> On Thu, Jul 15, 2021 at 08:29:50PM +0200, Bas Couwenberg wrote:
>>  This package provides the Icinga PHP thirdparty libraries.
>> The package is required for icingaweb2 (>= 2.9.0) and will be maintained 
>> within the Nagios team.
> 
> How many source copies does this package contain?

25, see:

https://github.com/Icinga/icinga-php-thirdparty/blob/main/composer.json

Kind Regards,

Bas

-- 
 GPG Key ID: 4096R/6750F10AE88D4AF1
Fingerprint: 8182 DE41 7056 408D 6146  50D1 6750 F10A E88D 4AF1

Bug#990313: Updated package thorvg

[Timo Röhling]

Hello Michal,

On Fri, 9 Jul 2021 10:29:08 +0200 "Michal Maciola"  
wrote:

Just uploaded a fixed package.
Please kindly find it for your review.

I see you addressed the first two points, fixing the build itself.
Great!

- You have specified that your package is native, which would imply
  that it is written exclusively for Debian. However, this is not
  the case. You may maintain both upstream and the Debian package
  right now, but this could change in the future. A more appropriate
  package format is "3.0 (quilt)", which takes the sources
  from a particular upstream release and optionally applies
  Debian-specific patches. There are a number of tools to aid you.
  Have a look at git-buildpackage, for instance.

- Shared libraries are not supposed to be packaged in a single
  Debian package, but should be separated into the actual shared
  object and the files required for development only. This is why I
  asked you to read section 8 of the Debian Policy, where this is
  explained in more detail.

- Please run lintian on your package before uploading. You can ask
  if you do not understand a particular error, but you will have to
  fix them anyway.

Cheers
Timo

--
⢀⣴⠾⠻⢶⣦⠀   ╭╮
⣾⠁⢠⠒⠀⣿⡁   │ Timo Röhling   │
⢿⡄⠘⠷⠚⠋⠀   │ 9B03 EBB9 8300 DF97 C2B1  23BF CC8C 6BDD 1403 F4CA │
⠈⠳⣄   ╰╯


signature.asc
Description: PGP signature

Bug#991197: Fwd: [containers/podman] Release v3.2.3 - v3.2.3

[Reinhard Tartler]

Package: libpod
Severity: wishlist

-- Forwarded message -
From: Ashley 
Date: Fri, Jul 16, 2021, 16:03
Subject: [containers/podman] Release v3.2.3 - v3.2.3
To: containers/podman 
Cc: Subscribed 


v3.2.3 

Repository: containers/podman  · Tag:
v3.2.3  · Commit: 1e6fd46

· Released by: ashley-cui 
Security

   - This release addresses CVE-2021-3602, an issue with the podman build
   command with the --isolation chroot flag that results in environment
   variables from the host leaking into build containers.

Bugfixes

   - Fixed a bug where events related to images could occur before the
   relevant operation had completed (e.g. an image pull event could be written
   before the pull was finished) (#10812
   ).
   - Fixed a bug where podman save would refuse to save images with an
   architecture different from that of the host (#10835
   ).
   - Fixed a bug where the podman import command did not correctly handle
   images without tags (#10854
   ).
   - Fixed a bug where Podman's journald events backend would fail and
   prevent Podman from running when run on a host with systemd as PID1 but in
   an environment (e.g. a container) without systemd (#10863
   ).
   - Fixed a bug where containers using rootless CNI networking would fail
   to start when the dnsname CNI plugin was in use and the host system's
   /etc/resolv.conf was a symlink (#10855
    and #10929
   ).
   - Fixed a bug where containers using rootless CNI networking could fail
   to start due to a race in rootless CNI initialization (#10930
   ).

Misc

   - Updated Buildah to v1.21.3
   - Updated the containers/common library to v0.38.16

—

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#991196: RFP: vim-vint -- Fast and highly extensible Vim script language lint

[Gabriel Filion]

Package: wnpp
Severity: wishlist

* Package name: vim-vint
  Version : 0.4a4
  Upstream Author : Kuniwak 
* URL : https://github.com/Vimjas/vint
* License : MIT
  Programming Lang: Python
  Description : Fast and highly extensible Vim script language lint

Vint is a Vim script Language Lint that aims to be highly extensible, highly
customizable and high performance.

It can be used standalone or can be integrated with Vim plugins such as
syntastic or CoC.vim in order to continually check your scripts.

The linting rules are based upon a number of sources, among which are the
Google Vimscript Style Guide.


This package makes writing better vimscript way easier since it helps you avoid
many pitfalls while you're writing or reviewing your code.


I personally have no experience with creating packaging for python codebases. I
also don't have much spare energy so I don't think I can put the effort into
creating the package for Vint.

Bug#991157: lxqt-policykit authorization fails with more than one sudoer. Fixed in 0.17.0?

[Bryan Cebuliak]

Thanks. Apparently the  bug  is  fixed upstream in 0.17.0. However there
are no 0.17.0 packages to  test in  any  Debian or Ubuntu release.
https://github.com/lxqt/lxqt-policykit/issues/117

Bug#991195: appdirs: Friendly Fork: platformdirs

[Stefano Rivera]

Source: appdirs
Severity: normal
Forwarded: https://github.com/ActiveState/appdirs/issues/79

Upstream there has been a friendly fork of appdirs to "platformdirs".
Assuming this is the future of the library, we should migrate debian
packages from appdirs to platformdirs, once it's in the archive.

$ reverse-depends src:appdirs
Reverse-Recommends
* python3-profitbricks  (for python3-appdirs)

Reverse-Depends
* black (for python3-appdirs)
* crossgrader   (for python3-appdirs)
* git-phab  (for python3-appdirs)
* matrix-mirage [amd64 arm64 armel armhf i386 mips64el mipsel ppc64el s390x]
* mu-editor (for python3-appdirs)
* nuitka(for python3-appdirs)
* ofxstatement  (for python3-appdirs)
* ofxstatement-plugins  (for python3-appdirs)
* openmotor (for python3-appdirs)
* plover(for python3-appdirs)
* printrun-common   (for python3-appdirs)
* pronsole  (for python3-appdirs)
* ptpython  (for python3-appdirs)
* pydoctor  (for python3-appdirs)
* python3-cobra [amd64 arm64 armel armhf i386 ppc64el]
* python3-datalad   (for python3-appdirs)
* python3-easydev   (for python3-appdirs)
* python3-etesync   (for python3-appdirs)
* python3-fissix(for python3-appdirs)
* python3-fs(for python3-appdirs)
* python3-intake [amd64 arm64 armel armhf i386 mips64el mipsel ppc64el]
* python3-ironicclient  (for python3-appdirs)
* python3-mbed-ls   (for python3-appdirs)
* python3-miio  (for python3-appdirs)
* python3-openstacksdk  (for python3-appdirs)
* python3-os-faults (for python3-appdirs)
* python3-pantalaimon   (for python3-appdirs)
* python3-pycuda [amd64](for python3-appdirs)
* python3-pyopencl [amd64 arm64 armel armhf i386]
* python3-pyspectral(for python3-appdirs)
* python3-pytools   (for python3-appdirs)
* python3-rply  (for python3-appdirs)
* python3-smstrade  (for python3-appdirs)
* python3-subliminal(for python3-appdirs)
* python3-ulmo  (for python3-appdirs)
* python3-virtualenv(for python3-appdirs)
* python3-yowsup(for python3-appdirs)
* python3-zeep  (for python3-appdirs)
* snakemake (for python3-appdirs)
* urlwatch  (for python3-appdirs)
* vorta (for python3-appdirs)

SR

Bug#624251: Hola

[MARIA CHICOTE GONZALEZ]

 

Usted ha sido elegido como beneficiario para recibir US $ 950,000 de la 
Fundación Julio Ponce Lerou con fines humanitarios.envíenos su nombre  y número 
de teléfonocorreo: fundacionjuliopon...@gmail.com

Bug#868507: BAQ

[ADEINYS ESTHER DAVID PINEDA]

Hello i seek your indulgence in a life transforming project and you never 
revert.

Bug#991194: ITP: opentracing-c-wrapper -- C wrapper for the C++ impl of the OpenTracing API

[Stephen Gelman]

Package: wnpp
Severity: wishlist
Owner: Stephen Gelman 
X-Debbugs-Cc: debian-de...@lists.debian.org, ssg...@debian.org

* Package name: opentracing-c-wrapper
  Version : 1.1.0
  Upstream Author : HAProxy Technologies
* URL : https://github.com/haproxytech/opentracing-c-wrapper/
* License : Apache-2.0
  Programming Lang: C/C++
  Description : C wrapper for the C++ impl of the OpenTracing API

OpenTracing C Wrapper library was created due to the need to use distributed
tracing within C programs.

The OpenTracing project (https://opentracing.io/) has published a
C-language implementation on https://github.com/opentracing/opentracing-c
but that implementation is incomplete, with the last update on Jun
27th 2018

This library takes inspiration from the header files in that project but
implements the proposed functionality fully by wrapping the functional
C++ library.

This is a dependency of building haproxy with opentracing support.

Bug#991193: ITP: opentracing-cpp -- OpenTracing API for C++

[Stephen Gelman]

Package: wnpp
Severity: wishlist
Owner: Stephen Gelman 
X-Debbugs-Cc: debian-de...@lists.debian.org, ssg...@debian.org

* Package name: opentracing-cpp
  Version : 1.6.0
  Upstream Author : The OpenTracing Authors
* URL : https://github.com/opentracing/opentracing-cpp/
* License : Apache-2.0
  Programming Lang: C++
  Description : OpenTracing API for C++

C++ implementation of the OpenTracing API. See http://opentracing.io for 
additional information.

This is being packaged as part of an effort to add opentracing support
to haproxy.

Bug#991061: ns3 FTBFS with imagemagick with the #987504 change

[Martin Quinson]

Thanks for the additional info, and for the patch in the first place.
I'll upload it asap.

Thx, Mt.

signature.asc
Description: PGP signature

Bug#991158: media-types: use image/x-xcf rather than application/x-xcf to match gimp.desktop

[Joel Hockey]

The GIMP team have confirmed that image/x-xcf is the correct mime.

https://www.mail-archive.com/gimp-developer-list%40gnome.org/msg09755.html

On Fri, Jul 16, 2021 at 1:24 PM Joel Hockey  wrote:

> Package: media-types
> Version: ?
> Severity: normal
>
> Dear Maintainer,
>
> Would it be possible to change the xcf file association in
> /etc/mime.types from application/x-xcf to image/x-xcf?
>
> GIMP uses the xcf file extension by default, and registers to handle
> mime type image/x-xcf in its gimp.desktop file.
>
>
> https://github.com/GNOME/gimp/blob/512fc2469422bb651515fb56a250439a1cc5c4ad/configure.ac#L1451
>
> XDG shared-mime-info also uses image/x-xcf to associate *.xcf files.
>
>
> https://gitlab.freedesktop.org/xdg/shared-mime-info/-/blob/47ca1dc530d356336ffe1b7a45dc5dc8f0e528ca/data/freedesktop.org.xml.in#L5568
>
> I'm not sure the history of why these 2 are not in sync, so I'm not sure
> if this would cause any issues to change it in media-types. I have
> emailed gimp-developer-l...@gnome.org to ask their opinion about this
> requested change. I will follow up when I hear from them.
>
> -- System Information:
> Debian Release: 10.7
>   APT prefers stable
>   APT policy: (500, 'stable')
> Architecture: amd64 (x86_64)
>
> Kernel: Linux 5.4.128-15728-g686e2baf4c9b (SMP w/8 CPU cores; PREEMPT)
> 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)
>

Bug#991150: systemd: Invalid shell for systemd-coredump

[Michael Biebl]

control: unarchive 931850
control: forcemerge 931850 991150

Am 15.07.21 um 20:40 schrieb Benoît:

Package: systemd
Version: 247.3-3
Severity: minor

Dear Maintainer,

My /etc/passwd has a line for systemd-coredump with an invalid shell:

systemd-coredump:x:998:998:systemd Core Dumper:/:/sbin/nologin

The issue is that on Debian, the nologin binary's path is /usr/sbin/nologin
This makes pwck report this inconsistency.


This issue was fixed a long time ago, see

systemd (241-7) unstable; urgency=medium

...

  * Use /usr/sbin/nologin as nologin shell.
In Debian the nologin shell is installed in /usr/sbin, not /sbin.
(Closes: #931850)

If you have such a user account, it must be from 2019 or earlier and was 
never part of a stable release afaics.
Since this is a minor issue, I don't think it warrants adding migration 
code for this.


Michael



OpenPGP_signature
Description: OpenPGP digital signature

Bug#991188: jetty9: CVE-2021-34429

[Markus Koschany]

Control: owner -1 !

Hi,

Am Freitag, dem 16.07.2021 um 21:16 +0200 schrieb Salvatore Bonaccorso:
> Source: jetty9
> Version: 9.4.39-2
> Severity: grave
> Tags: security upstream
> X-Debbugs-Cc: car...@debian.org, Debian Security Team
> 
> 
> Hi,
> 
> The following vulnerability was published for jetty9.
> 
> CVE-2021-34429[0]:
> 

just FYI. I am almost done preparing a buster-security update for Jetty 9 and I
get back to you this weekend. I will take care of this issue for Debian 11 too.

Markus



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

Bug#991149: ITP: icinga-php-thirdparty -- Icinga PHP Thirdparty libraries for Icinga Web 2

[Bastian Blank]

On Thu, Jul 15, 2021 at 08:29:50PM +0200, Bas Couwenberg wrote:
>  This package provides the Icinga PHP thirdparty libraries.
> The package is required for icingaweb2 (>= 2.9.0) and will be maintained 
> within the Nagios team.

How many source copies does this package contain?

Bastian

-- 
If there are self-made purgatories, then we all have to live in them.
-- Spock, "This Side of Paradise", stardate 3417.7

Bug#991061: ns3 FTBFS with imagemagick with the #987504 change

[Dennis Filder]

On Fri, Jul 16, 2021 at 09:02:44PM +0200, Martin Quinson wrote:
> I'm sorry to ask, but I fear I need additional information, please.
> It seems to me that this patch merely circumvent the change in
> ImageMagik to allow the handling of eps file during the construction
> of the package. Am I right, or is it only disabling the dangerous
> parts of the converter while retrieving the parts we need?
>
> Sorry to ask, I'm very bad with ImageMagik.
>
> Even if it's re-enabling the conversion of eps files for the package
> building, I guess that this is a good emergency solution to not delay
> the release too much, provided that we trust the eps files that come
> with ns-3. Thanks for the proposal.

You have to trust the EPS files in your package like everything else
anyway.  AIUI the restriction in /etc/ImageMagick-6/policy.xml exists
as a stop-gap to keep people from accidentally running ImageMagick on
untrusted input (e.g. shoddily-written CGI scripts that don't sanitize
input correctly).  Seccomp filters would be a better approach, but
since ImageMagick has to also work under Windows that's unlikely to
ever happen.

If ImageMagick were too dangerous to use even on trusted input then
shipping it at all wouldn't make any sense.

> But I would prefer not to live with such a complex and even somewhat
> dangerous patch in my package, so I'm curious about other solutions
> that would allow to convert eps to png without ImageMagik. Maybe using
> gimp and Script-Fu?

pdftoppm from poppler-utils is another option.  Ubuntu's version of
sctk has a patch for that:
https://patches.ubuntu.com/s/sctk/sctk_2.4.10-20151007-1312Z+dfsg2-3ubuntu1.patch
(But I don't believe for a single second that that parser is any safer
than what comes in ImageMagick.)

Regards

Bug#991060: mlpost FTBFS with imagemagick with the #987504 change

[Dennis Filder]

Control: tag -1 patch

The attached patch should fix this.

Regards,
Dennis Filder
Description: Override ImageMagick policy
 Derive an appropriate policy from the too strict default one.
Author: Dennis Filder 
Last-Update: 2021-07-16
Bug-Debian: https://bugs.debian.org/991060
--- a/ocamlbuild.Makefile
+++ b/ocamlbuild.Makefile
@@ -44,6 +44,7 @@
 EXTDLL = .so
 DLL := backend/dllmlpost_ft$(EXTDLL) backend/libmlpost_ft.a
 
+POLFILE = "/etc/$(shell convert -version|sed -n '/^Version: /s@Version: ImageMagick \([[:digit:]]\+\)\..*@ImageMagick-\1@p')"/policy.xml
 
 ifeq "$(OCAMLBEST)" "opt"
 all:
@@ -195,7 +196,10 @@
 .PHONY: doc
 doc:
 	rm -f doc
+	test -d $(HOME)/.magick || mkdir -p $(HOME)/.magick
+	sed -e '//s@"none"@"read|write"@' $(POLFILE) > $(HOME)/.magick/policy.xml
 	$(OCAMLBUILD) doc/index.html
+	rm -Rf $(HOME)/.magick
 	ln -s _build/doc doc
 
 # clean

Bug#991192: dpkg-fsys-usrunmess: should be restartable

[Zack Weinberg]

Package: dpkg
Version: 1.20.9
Severity: wishlist
File: /usr/sbin/dpkg-fsys-usrunmess
X-Debbugs-Cc: za...@panix.com

I tried to run dpkg-fsys-usrunmess from systemd’s emergency mode,
thinking that this would be safer, since nothing else would be
running.  This tickled a bug in systemd (see #991185) and got
dpkg-fsys-usrunmess killed in the middle of its run—specifically,
during the ‘dpkg --pending --configure’ operation.  As you can
probably imagine, this is a really bad time for the process to be
interrupted.  I have a *lot* of experience cleaning up after breakage
in unstable and it still took me five hours this time.

In another bug, I suggested a stopgap measure for the specific thing
that went wrong with dpkg-fsys-usrunmess this time, but a more
thorough fix would be to make dpkg-fsys-usrunmess restartable.  Each
phase of the operation could be made idempotent on a file-by-file
basis simply by ignoring failures due to the rename or whatever
already having happened, and in between phases it could checkpoint
itself in a file in the shadow directory.

If I get time this weekend I’ll try to come up with a patch.


-- Package-specific info:

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

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

Versions of packages dpkg depends on:
ii  libbz2-1.0   1.0.8-4
ii  libc62.31-13
ii  liblzma5 5.2.5-2
ii  libselinux1  3.1-3
ii  tar  1.34+dfsg-1
ii  zlib1g   1:1.2.11.dfsg-2

dpkg recommends no packages.

Versions of packages dpkg suggests:
ii  apt2.2.4
pn  debsig-verify  

-- no debconf information

Bug#991191: ITP: catgirl -- TLS-only terminal IRC client

[Ryan Kavanagh]

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

* Package name: catgirl
  Version : 1.8
  Upstream Author : C. McEnroe 
* URL : https://git.causal.agency/catgirl/about/
* License : GPLv3+ plus OpenSSL exception
  Programming Lang: C
  Description : TLS-only terminal IRC client

A minimal terminal IRC client with tab completion, split scrolling, nick
colouring, topic diffing, and message filtering.

-- 
|)|/  Ryan Kavanagh  | 4E46 9519 ED67 7734 268F
|\|\  https://rak.ac | BD95 8F7B F8FC 4A11 C97A


signature.asc
Description: PGP signature

Bug#991190: dpkg-fsys-usrunmess: block service activation with policy-rc.d?

[Zack Weinberg]

Package: dpkg
Version: 1.20.9
Severity: normal
File: /usr/sbin/dpkg-fsys-usrunmess
X-Debbugs-Cc: za...@panix.com

I tried to run dpkg-fsys-usrunmess from systemd’s emergency mode,
thinking that this would be safer, since nothing else would be
running.  This tickled a bug in systemd (see #991185) and got
dpkg-fsys-usrunmess killed in the middle of its run—specifically,
during the ‘dpkg --pending --configure’ operation.  As you can
probably imagine, this is a really bad time for the process to be
interrupted.

As a stopgap safety measure, I suggest that dpkg-fsys-usrunmess should
use policy-rc.d to block all service activation while it’s running.

-- Package-specific info:

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

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

Versions of packages dpkg depends on:
ii  libbz2-1.0   1.0.8-4
ii  libc62.31-13
ii  liblzma5 5.2.5-2
ii  libselinux1  3.1-3
ii  tar  1.34+dfsg-1
ii  zlib1g   1:1.2.11.dfsg-2

dpkg recommends no packages.

Versions of packages dpkg suggests:
ii  apt2.2.4
pn  debsig-verify  

-- no debconf information

Bug#991189: unblock: fail2ban/0.11.2-2

[Salvatore Bonaccorso]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
X-Debbugs-Cc: car...@debian.org,t...@security.debian.org,sylves...@debian.org

Hi Release Team!

Please unblock package fail2ban

fail2ban is affected by CVE-2021-32749, see detailed advisory in
https://github.com/fail2ban/fail2ban/security/advisories/GHSA-m985-3f3v-cwmm,
which is a possible remote code execution vulnerability in the mailing
action mail-whois.

The idea is to have it fixed in the upper suite first, later for
buster a point release update could follow.

unblock fail2ban/0.11.2-2

Regards,
Salvatore
diff -Nru fail2ban-0.11.2/debian/changelog fail2ban-0.11.2/debian/changelog
--- fail2ban-0.11.2/debian/changelog2020-11-26 13:47:53.0 +0100
+++ fail2ban-0.11.2/debian/changelog2021-07-12 06:52:40.0 +0200
@@ -1,3 +1,9 @@
+fail2ban (0.11.2-2) unstable; urgency=high
+
+  * Fix a problem with mail
+
+ -- Sylvestre Ledru   Mon, 12 Jul 2021 06:52:40 +0200
+
 fail2ban (0.11.2-1) unstable; urgency=medium
 
   * New upstream release
diff -Nru fail2ban-0.11.2/debian/patches/fix-mail.patch 
fail2ban-0.11.2/debian/patches/fix-mail.patch
--- fail2ban-0.11.2/debian/patches/fix-mail.patch   1970-01-01 
01:00:00.0 +0100
+++ fail2ban-0.11.2/debian/patches/fix-mail.patch   2021-07-12 
06:50:21.0 +0200
@@ -0,0 +1,147 @@
+ config/action.d/complain.conf | 2 +-
+ config/action.d/dshield.conf  | 2 +-
+ config/action.d/mail-buffered.conf| 8 
+ config/action.d/mail-whois-lines.conf | 2 +-
+ config/action.d/mail-whois.conf   | 6 +++---
+ config/action.d/mail.conf | 6 +++---
+ 6 files changed, 13 insertions(+), 13 deletions(-)
+
+diff --git a/config/action.d/complain.conf b/config/action.d/complain.conf
+index 3a5f882c..4d73b058 100644
+--- a/config/action.d/complain.conf
 b/config/action.d/complain.conf
+@@ -102,7 +102,7 @@ logpath = /dev/null
+ # Notes.:  Your system mail command. Is passed 2 args: subject and recipient
+ # Values:  CMD
+ #
+-mailcmd = mail -s
++mailcmd = mail -E 'set escape' -s
+ 
+ # Option:  mailargs
+ # Notes.:  Additional arguments to mail command. e.g. for standard Unix mail:
+diff --git a/config/action.d/dshield.conf b/config/action.d/dshield.conf
+index c128bef3..3d5a7a53 100644
+--- a/config/action.d/dshield.conf
 b/config/action.d/dshield.conf
+@@ -179,7 +179,7 @@ tcpflags =
+ # Notes.:  Your system mail command. Is passed 2 args: subject and recipient
+ # Values:  CMD
+ #
+-mailcmd = mail -s
++mailcmd = mail -E 'set escape' -s
+ 
+ # Option:  mailargs
+ # Notes.:  Additional arguments to mail command. e.g. for standard Unix mail:
+diff --git a/config/action.d/mail-buffered.conf 
b/config/action.d/mail-buffered.conf
+index 325f185b..79b84104 100644
+--- a/config/action.d/mail-buffered.conf
 b/config/action.d/mail-buffered.conf
+@@ -17,7 +17,7 @@ actionstart = printf %%b "Hi,\n
+   The jail  has been started successfully.\n
+   Output will be buffered until  lines are available.\n
+   Regards,\n
+-  Fail2Ban"|mail -s "[Fail2Ban] : started on " 

++  Fail2Ban"|mail -E 'set escape' -s "[Fail2Ban] : started 
on " 
+ 
+ # Option:  actionstop
+ # Notes.:  command executed at the stop of jail (or at the end of Fail2Ban)
+@@ -28,13 +28,13 @@ actionstop = if [ -f  ]; then
+  These hosts have been banned by Fail2Ban.\n
+  `cat `
+  Regards,\n
+- Fail2Ban"|mail -s "[Fail2Ban] : Summary from 
" 
++ Fail2Ban"|mail -E 'set escape' -s "[Fail2Ban] : 
Summary from " 
+  rm 
+  fi
+  printf %%b "Hi,\n
+  The jail  has been stopped.\n
+  Regards,\n
+- Fail2Ban"|mail -s "[Fail2Ban] : stopped on " 

++ Fail2Ban"|mail -E 'set escape' -s "[Fail2Ban] : stopped on 
" 
+ 
+ # Option:  actioncheck
+ # Notes.:  command executed once before each actionban command
+@@ -55,7 +55,7 @@ actionban = printf %%b "`date`:  ( 
failures)\n" >> 
+ These hosts have been banned by Fail2Ban.\n
+ `cat `
+ \nRegards,\n
+-Fail2Ban"|mail -s "[Fail2Ban] : Summary" 
++Fail2Ban"|mail -E 'set escape' -s "[Fail2Ban] : 
Summary" 
+ rm 
+ fi
+ 
+diff --git a/config/action.d/mail-whois-lines.conf 
b/config/action.d/mail-whois-lines.conf
+index 3a3e56b2..d2818cb9 100644
+--- a/config/action.d/mail-whois-lines.conf
 b/config/action.d/mail-whois-lines.conf
+@@ -72,7 +72,7 @@ actionunban =
+ # Notes.:  Your system mail command. Is passed 2 args: subject and recipient
+ # Values:  CMD
+ #
+-mailcmd = mail -s
++mailcmd = mail -E 'set escape' -s
+ 
+ # Default name of the chain
+ #
+diff --git a/config/action.d/mail-whois.conf b/config/action.d/mail-whois.conf
+index 7fea34c4..ab33b616 100644
+--- 

Bug#991188: jetty9: CVE-2021-34429

[Salvatore Bonaccorso]

Source: jetty9
Version: 9.4.39-2
Severity: grave
Tags: security upstream
X-Debbugs-Cc: car...@debian.org, Debian Security Team 

Hi,

The following vulnerability was published for jetty9.

CVE-2021-34429[0]:
| For Eclipse Jetty versions 9.4.37-9.4.42, 10.0.1-10.0.5 
| 11.0.1-11.0.5, URIs can be crafted using some encoded characters to
| access the content of the WEB-INF directory and/or bypass some
| security constraints. This is a variation of the vulnerability
| reported in CVE-2021-28164/GHSA-v7ff-8wcx-gmc5.


If you fix the vulnerability please also make sure to include the
CVE (Common Vulnerabilities & Exposures) id in your changelog entry.

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2021-34429
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-34429
[1] 
https://github.com/eclipse/jetty.project/security/advisories/GHSA-vjv5-gp2w-65vm

Please adjust the affected versions in the BTS as needed. Just from
the upstream versions it is considered to be a problem starting with
9.4.37, but I have *not* checked if we might have an earlier patch
introducing the issue, so please double check, but I suspect the only
version so far affected is the one in bullseye/sid.

Regards,
Salvatore

Bug#991187: libfile-mimeinfo-perl: Use of uninitialized value $file in open at /usr/share/perl5/File/MimeInfo/Applications.pm line 140

[Felix Lechner]

Package: libfile-mimeinfo-perl
Version: 0.30-1
Severity: minor

Hi,

Under the Wayland compositor Sway (with Gnome 3 installed) I followed this
advice [1] to make evince the default application for PDFs once again. When I
invoked 'mimeopen -d XYZ.pdf' the program worked fine but also produced the
following warnings:

Use of uninitialized value $file in open at
/usr/share/perl5/File/MimeInfo/Applications.pm line 140.
Use of uninitialized value $file in open at
/usr/share/perl5/File/MimeInfo/Applications.pm line 140.
Use of uninitialized value $file in open at
/usr/share/perl5/File/MimeInfo/Applications.pm line 140.
Use of uninitialized value $file in open at
/usr/share/perl5/File/MimeInfo/Applications.pm line 140.

Based on my Perl experience, I assume that the messages are probably
unintended.

At the same time, the program's functionality was not affected. Also, mimeopen
is rarely invoked in a terminal and probably more often via a graphical
application with output redirected. Therefore, this bug is not urgent at all.

Thank you for maintaining this software in Debian!

Kind regards,
Felix Lechner

[1] https://unix.stackexchange.com/q/350103


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

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

Versions of packages libfile-mimeinfo-perl depends on:
ii  libencode-locale-perl  1.05-1.1
ii  libfile-basedir-perl   0.08-1
ii  libfile-desktopentry-perl  0.22-2
ii  perl   5.32.1-4
ii  shared-mime-info   2.0-1

Versions of packages libfile-mimeinfo-perl recommends:
ii  libio-stringy-perl  2.111-3

libfile-mimeinfo-perl suggests no packages.

Bug#991186: unblock: trafficserver/8.1.1+ds-1.1

[Salvatore Bonaccorso]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
X-Debbugs-Cc: car...@debian.org,j...@debian.org,deb...@jbfavre.org

Hi release team,

Please unblock package trafficserver

[ Reason ]
Trafficserver is affected by several CVEs, covered in #990303 and are
CVE-2021-27577, CVE-2021-32565, CVE-2021-32566, CVE-2021-32567 and
CVE-2021-35474..

[ Impact ]
Security issues remain open in bullseye (for now). But it is planned
to release a DSA for buster. So we want to make sure the fixes are
already present in the upper suite before it's release.

[ Tests ]
None further specifically.

[ Risks ]
Targetted upstream patch applied without problem.

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

[ Other info ]
None.

unblock trafficserver/8.1.1+ds-1.1

Regards,
Salvatore
diff -Nru trafficserver-8.1.1+ds/debian/changelog 
trafficserver-8.1.1+ds/debian/changelog
--- trafficserver-8.1.1+ds/debian/changelog 2020-12-06 16:26:39.0 
+0100
+++ trafficserver-8.1.1+ds/debian/changelog 2021-07-15 21:48:17.0 
+0200
@@ -1,3 +1,20 @@
+trafficserver (8.1.1+ds-1.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Address CVE-2021-27577, CVE-2021-32565, CVE-2021-32566, CVE-2021-32567 and
+CVE-2021-35474.
+- 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
+(Closes: #990303)
+
+ -- Salvatore Bonaccorso   Thu, 15 Jul 2021 21:48:17 +0200
+
 trafficserver (8.1.1+ds-1) unstable; urgency=medium
 
   * New upstream version 8.1.0+ds
diff -Nru trafficserver-8.1.1+ds/debian/patches/0018-Fixes-7971.patch 
trafficserver-8.1.1+ds/debian/patches/0018-Fixes-7971.patch
--- trafficserver-8.1.1+ds/debian/patches/0018-Fixes-7971.patch 1970-01-01 
01:00:00.0 +0100
+++ trafficserver-8.1.1+ds/debian/patches/0018-Fixes-7971.patch 2021-07-15 
21:45:16.0 +0200
@@ -0,0 +1,153 @@
+From: Evan Zelkowitz 
+Date: Tue, 22 Jun 2021 14:32:55 -0700
+Subject: Fixes (#7971)
+Origin: 
https://github.com/apache/trafficserver/commit/b82a3d192f995fb9d78e1c44d51d9acca4783277
+Bug-Debian-Security: https://security-tracker.debian.org/tracker/CVE-2021-27577
+Bug-Debian-Security: https://security-tracker.debian.org/tracker/CVE-2021-32565
+Bug-Debian-Security: https://security-tracker.debian.org/tracker/CVE-2021-32566
+Bug-Debian-Security: https://security-tracker.debian.org/tracker/CVE-2021-32567
+Bug-Debian-Security: https://security-tracker.debian.org/tracker/CVE-2021-35474
+Bug-Debian: https://bugs.debian.org/990303
+
+* String the url fragment for outgoing requests (#7966)
+
+Co-authored-by: Susan Hinrichs 
+(cherry picked from commit 2b13eb33794574e62249997b4ba654d943a10f2d)
+
+* Ensure that the content-length value is only digits (#7964)
+
+Co-authored-by: Susan Hinrichs 
+(cherry picked from commit 668d0f8668fec1cd350b0ceba3f7f8e4020ae3ca)
+
+* Schedule H2 reenable event only if it's necessary
+
+Co-authored-by: Katsutoshi Ikenoya 
+
+* Fix dynamic-stack-buffer-overflow of cachekey plugin (#7945)
+
+* Fix dynamic-stack-buffer-overflow of cachekey plugin
+
+* Check dst_size include null termination
+
+(cherry picked from commit 5a9339d7bc65e1c2d8d2a0fc80bb051daf3cdb0b)
+
+Co-authored-by: Bryan Call 
+Co-authored-by: Masakazu Kitajo 
+Co-authored-by: Katsutoshi Ikenoya 
+Co-authored-by: Masaori Koshiba 
+---
+ plugins/cachekey/cachekey.cc  |  2 +-
+ proxy/hdrs/HTTP.cc| 11 +++
+ proxy/http/HttpTransact.cc|  5 -
+ proxy/http2/Http2ClientSession.cc | 14 +++---
+ proxy/logging/LogUtils.cc |  2 +-
+ 5 files changed, 24 insertions(+), 10 deletions(-)
+
+diff --git a/plugins/cachekey/cachekey.cc b/plugins/cachekey/cachekey.cc
+index 5f128894bfa8..44925b3db280 100644
+--- a/plugins/cachekey/cachekey.cc
 b/plugins/cachekey/cachekey.cc
+@@ -41,7 +41,7 @@ appendEncoded(String , const char *s, size_t len)
+ return;
+   }
+ 
+-  char tmp[len * 2];
++  char tmp[len * 3 + 1];
+   size_t written;
+ 
+   /* The default table does not encode the comma, so we need to use our own 
table here. */
+diff --git a/proxy/hdrs/HTTP.cc b/proxy/hdrs/HTTP.cc
+index 6a2ecc41d3ad..48032dd9ddf4 100644
+--- a/proxy/hdrs/HTTP.cc
 b/proxy/hdrs/HTTP.cc
+@@ -1202,6 +1202,17 @@ validate_hdr_content_length(HdrHeap *heap, HTTPHdrImpl 
*hh)
+ int content_length_len = 0;
+ const char *content_length_val = 
content_length_field->value_get(_length_len);
+ 
++// RFC 7230 section 3.3.2
++// Content-Length = 1*DIGIT
++//
++// If the content-length 

Bug#991061: ns3 FTBFS with imagemagick with the #987504 change

[Martin Quinson]

Hello,

I'm sorry to ask, but I fear I need additional information, please.
It seems to me that this patch merely circumvent the change in
ImageMagik to allow the handling of eps file during the construction
of the package. Am I right, or is it only disabling the dangerous
parts of the converter while retrieving the parts we need?

Sorry to ask, I'm very bad with ImageMagik.

Even if it's re-enabling the conversion of eps files for the package
building, I guess that this is a good emergency solution to not delay
the release too much, provided that we trust the eps files that come
with ns-3. Thanks for the proposal.

But I would prefer not to live with such a complex and even somewhat
dangerous patch in my package, so I'm curious about other solutions
that would allow to convert eps to png without ImageMagik. Maybe using
gimp and Script-Fu?

Thanks for that patch anyway,
Mt

Le Fri, Jul 16, 2021 at 06:21:21PM +0200, Dennis Filder a écrit :
> Control: tag -1 patch
> 
> With this patch the build finished for me.
> 
> Regards,
> Dennis Filder

> Description: Override overly strict ImageMagick security policy (#987504)
>  This patch derives a more permissive ImageMagick security policy from
>  the system default.
> Author: Dennis Filder 
> Last-Update: 2021-07-16
> Bug-Debian: https://bugs.debian.org/991061
> --- a/ns-3.31/doc/models/Makefile
> +++ b/ns-3.31/doc/models/Makefile
> @@ -496,6 +496,8 @@
>  
>  RESCALE = ../../utils/rescale-pdf.sh
>  
> +POLFILE = "/etc/$(shell convert -version|sed -n '/^Version: /s@Version: 
> ImageMagick \([[:digit:]]\+\)\..*@ImageMagick-\1@p')/policy.xml"
> +
>  %.eps : %.dia
>   @echo dia $(notdir $<)
>   @$(DIA) -t eps $< -e $@ >/dev/null
> @@ -506,7 +508,9 @@
>  
>  %.png : %.eps
>   @echo convert $(notdir $<)
> - @$(CONVERT) $< $@ >/dev/null
> + test -d ../../../debian/tmp/ImageMagick || mkdir -p 
> ../../../debian/tmp/ImageMagick
> + test -f ../../../debian/tmp/ImageMagick/policy.xml || sed -e '/ domain="coder" rights="none" pattern="PS" .>/s@"none"@"read|write"@' 
> "$(POLFILE)" > ../../../debian/tmp/ImageMagick/policy.xml
> + XDG_CONFIG_HOME="$(shell pwd)/../../../debian/tmp" $(CONVERT) $< $@ 
> >/dev/null
>  
>  %.pdf : %.eps
>   @echo epstopdf $(notdir $<)
> @@ -556,6 +560,7 @@
>  clean:
>   -rm -rf $(BUILDDIR)/*
>   -rm -rf $(SOURCETEMP)
> + -rm -Rf ../../../debian/tmp/ImageMagick
>  
>  frag: pickle
>   @if test ! -d $(BUILDDIR)/frag; then mkdir $(BUILDDIR)/frag; fi


-- 
The web was not envisioned as a form of television when it was invented. 
But, like it or not, it is rapidly resembling TV: linear, passive,
programmed and inward-looking.   --  Hossein Derakhshan
https://medium.com/matter/the-web-we-have-to-save-2eb1fe15a426


signature.asc
Description: PGP signature

Bug#991057: gri FTBFS with imagemagick with the #987504 change

[Dennis Filder]

Control: tag -1 patch

The attached patch fixed this for me.

Regards.
--- debian/rules-orig
+++ debian/rules
@@ -21,6 +21,8 @@
 
 ARCH := $(shell dpkg --print-architecture | perl -pe chop)
 
+POLFILE = "/etc/$(shell convert -version|sed -n '/^Version: /s@Version: ImageMagick \([[:digit:]]\+\)\..*@ImageMagick-\1@p')/policy.xml"
+
 build: build-indep build-arch
 
 # Build architecture-dependent files here (no need to be root).
@@ -69,7 +71,10 @@
 
 # Build architecture-independent files here (no need to be root).
 build-indep: debian/gri_merge.1 Makefile
-	cd doc; make refcard.ps cmdrefcard.ps gri.pdf html
+	mkdir -p debian/tmp/ImageMagick
+	sed -e '//s@"none"@"read|write"@' "$(POLFILE)" > debian/tmp/ImageMagick/policy.xml
+	cd doc; make XDG_CONFIG_HOME="$(shell pwd)/debian/tmp" refcard.ps cmdrefcard.ps gri.pdf html
+	rm -Rf debian/tmp/ImageMagick
 
 # Install (as root) architecture-independent files here.
 binary-indep: build-indep

Bug#505253: Bonne journée

[lionel lawson]

-- 
Un courrier vous a été envoyé la semaine dernière dans l'espoir d'avoir un
retour de courrier de votre part mais à ma grande surprise vous n'avez
jamais pris la peine de répondre. Gentiment
réponse pour plus d'explications.

Respectueusement vôtre,
Lionel Lawson.

Bug#783990: efivarfs is a separate fs and needs moutning

[The Wanderer]

On 2021-07-16 at 13:36, Ian Jackson wrote:

> The Wanderer writes ("Re: Bug#783990: efivarfs is a separate fs and
> needs moutning"):
> 
>> Wouldn't testing the existence of
>> 
>> /lib/modules/`uname -r`/kernel/fs/efivarfs/efivarfs.ko
>> 
>> be enough, and probably more reliable?
> 
> I'm doubt very much it would be more reliable.  What if the kernel
> reorganises its modules ?

That possibility hadn't even occurred to me, but now that you point it
out, I drop this suggestion.

>> (I'm assuming that the test which skips because "fstype not
>> available" comes before the one which skips because "already
>> mounted", and that's why I saw the warning even though it seems to
>> be up and working on my machine.)
> 
> Yes, the tests are indeed in that order.  I think you have it
> mounted now because of the apparmor fixup you found.

I was initially not sure that was going to be relevant after all,
because I was expecting AppArmor to be a thing that has to be constantly
running in order to be effective, and there's no such process visible
that I can see - but apparmor shows up in dmesg, et cetera, so I must
have been expecting wrong.

> The change to mountkernfs was ineffective on your system for the same
> reason it was ineffective on mine, but the apparmor workaround means
> you don't see the effects since apparmor has got it mounted by the
> time you log in.

Makes perfect sense.

>> I need to do some other things for a while, so I won't be
>> rebooting again immediately, but I'll probably test this sometime
>> this afternoon.
>> 
>> 
>> My current biggest concern about this is:
>> 
>> --
> 
> No objections then ? :-)  (I think you may have missed a bit...)

Heh. That line was a leftover of when I was going to raise the question
of why the "fstype not available" test was even being reached, given the
"already mounted" test, before I realized that it must be simply a
matter of test order.

-- 
   The Wanderer

The reasonable man adapts himself to the world; the unreasonable one
persists in trying to adapt the world to himself. Therefore all
progress depends on the unreasonable man. -- George Bernard Shaw



signature.asc
Description: OpenPGP digital signature

Bug#991177: libdebian-installer: reproducible builds: Embeds build path in libdebian-installer-extra.so.*

[Cyril Brulebois]

Hello,

Vagrant Cascadian  (2021-07-16):
> The build path is embedded in various places in
> libdebian-installer-extra.so.*:
> 
>   
> https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/diffoscope-results/libdebian-installer.html
> 
>   ./usr/lib/x86_64-linux-gnu/libdebian-installer-extra.so.4.0.8 
> 
>   /build/1st/libdebian-installer-0.121/build/src/../../src/list.c:30
>   vs.
>   /build/2/libdebian-installer-0.121/2nd/build/src/../../src/list.c:30
> 
> The attached patch fixes this by passing -ffile-prefix-map to CFLAGS in
> debian/rules.
> 
> Alternately, with recent versions of dpkg, using dpkg-buildflags to set
> CFLAGS should pass this option by default.
> 
> 
> Thanks for maintaining libdebian-installer!

I know we haven't always been stellar when it comes to merging repro
build work, sorry about that. Any chance you could chase^Wremind us
about such issues once Bullseye (r0, and maybe r1) is out the door?

Thanks already!


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


signature.asc
Description: PGP signature

Bug#991053: ftgl FTBFS with imagemagick with the #987504 change

[Dennis Filder]

Control: tag -1 patch

The attached patch makes generating the EPS files work.

Regards
--- debian/rules-orig
+++ debian/rules
@@ -9,11 +9,16 @@
 ^(\./\.git/.*|\./debian/.*|\./\.pc/.*|\./test/font_pack/(El_Abogado_Loco\.ttf|timR12-ISO8859-1\.pcf\.gz)|\./docs/images/.*\.png|\./docs/FTGL_1_3\.gif)$
 
 
+POLFILE = "/etc/$(shell convert -version|sed -n '/^Version: /s@Version: ImageMagick \([[:digit:]]\+\)\..*@ImageMagick-\1@p')/policy.xml"
+
 %:
 	dh $@
 
 override_dh_auto_build:
-	dh_auto_build -- GLUT_LIBS="$(GLUT_LIBS)"
+	mkdir -p debian/tmp/ImageMagick
+	sed -e '//s@"none"@"read|write"@' "$(POLFILE)" > debian/tmp/ImageMagick/policy.xml
+	dh_auto_build -- GLUT_LIBS="$(GLUT_LIBS)" XDG_CONFIG_HOME="$(shell pwd)/debian/tmp"
+	rm -Rf debian/tmp/ImageMagick
 
 override_dh_makeshlibs:
 	dh_makeshlibs -p libftgl2 -V "libftgl2 (>= $(SHLIBVER))"

Bug#991068: xnee FTBFS with imagemagick with the #987504 change

[Dennis Filder]

Control: tag -1 patch

The attached patch allowed me to build xnee.

Regards.
Description: Override overly strict ImageMagick default security policy (#987504)
 This derives a more permissive policy from the system default policy.
 .
 XDG_CONFIG_HOME is only set for invocations of convert instead of
 globally to minimize inadvertent side-effects.
Author: Dennis Filder 
Last-Update: 2021-07-16
Bug-Debian: https://bugs.debian.org/991068
--- a/doc/Makefile.am
+++ b/doc/Makefile.am
@@ -15,6 +15,8 @@
 #	$(MANUALS)
 
 
+POLFILE = "/etc/$(shell convert -version|sed -n '/^Version: /s@Version: ImageMagick \([[:digit:]]\+\)\..*@ImageMagick-\1@p')/policy.xml"
+
 if BUILDDOC
 DOC_DEP=$(GEN_IMAGES_TO_INSTALL) $(MANUALS)
 doc_DATA = $(MANUALS) $(GEN_IMAGES_TO_INSTALL)
@@ -93,18 +95,24 @@
 
 %.png: %.eps
 	@echo "creating PNG"
-	$(CONVERT) -density 144x144 $< $@ 
+	mkdir -p debian/tmp/ImageMagick
+	sed -e '//s@"none"@"read|write"@' "$(POLFILE)" > debian/tmp/ImageMagick/policy.xml
+	XDG_CONFIG_HOME="$(shell pwd)/debian/tmp" $(CONVERT) -density 144x144 $< $@
 	( mv $@ `echo $@ | sed 's,\.png,_big\.png,g'` )
-	$(CONVERT) -density 32x32 $< $@ 
+	XDG_CONFIG_HOME="$(shell pwd)/debian/tmp" $(CONVERT) -density 32x32 $< $@
 	( mv $@ `echo $@ | sed 's,\.png,_small\.png,g'` )
-	$(CONVERT) -density 60x60 $< $@ 
+	XDG_CONFIG_HOME="$(shell pwd)/debian/tmp" $(CONVERT) -density 60x60 $< $@
+	rm -Rf debian/tmp/ImageMagick
 %.jpg: %.eps
 	echo "creating JPG"
-	$(CONVERT) -density 144x144 $< $@ 
+	mkdir -p debian/tmp/ImageMagick
+	sed -e '//s@"none"@"read|write"@' "$(POLFILE)" > debian/tmp/ImageMagick/policy.xml
+	XDG_CONFIG_HOME="$(shell pwd)/debian/tmp" $(CONVERT) -density 144x144 $< $@
 	( mv $@ `echo $@ | sed 's,\.jpg,_big\.jpg,g'` )
-	$(CONVERT) -density 32x32 $< $@ 
+	XDG_CONFIG_HOME="$(shell pwd)/debian/tmp" $(CONVERT) -density 32x32 $< $@
 	( mv $@ `echo $@ | sed 's,\.jpg,_small\.jpg,g'` )
-	$(CONVERT) -density 60x60 $< $@ 
+	XDG_CONFIG_HOME="$(shell pwd)/debian/tmp" $(CONVERT) -density 60x60 $< $@
+	rm -Rf debian/tmp/ImageMagick
 
 
 ${IMG_EPS}: ${IMG_DIA}

Bug#783990: efivarfs is a separate fs and needs moutning

[Ian Jackson]

The Wanderer writes ("Re: Bug#783990: efivarfs is a separate fs and needs 
moutning"):
> Wouldn't testing the existence of
> 
> /lib/modules/`uname -r`/kernel/fs/efivarfs/efivarfs.ko
> 
> be enough, and probably more reliable?

I'm doubt very much it would be more reliable.  What if the kernel
reorganises its modules ?

Also, it would then have to be OR-ed with the check in
/proc/filesystems, since you might have the module built-in.

> (I'm assuming that the test which skips because "fstype not available"
> comes before the one which skips because "already mounted", and that's
> why I saw the warning even though it seems to be up and working on my
> machine.)

Yes, the tests are indeed in that order.  I think you have it mounted
now because of the apparmor fixup you found.  The change to
mountkernfs was ineffective on your system for the same reason it was
ineffective on mine, but the apparmor workaround means you don't see
the effects since apparmor has got it mounted by the time you log in.

> I need to do some other things for a while, so I won't be rebooting
> again immediately, but I'll probably test this sometime this afternoon.
> 
> 
> My current biggest concern about this is:
> 
> -- 

No objections then ? :-)  (I think you may have missed a bit...)

Ian.

-- 
Ian JacksonThese opinions are my own.  

Pronouns: they/he.  If I emailed you from @fyvzl.net or @evade.org.uk,
that is a private address which bypasses my fierce spamfilter.

Bug#642282: Sahba Home & Garden Show 2021 Visitors Info List

[Olivia Collins]

Hello,
Hope you and your family is doing well and safe.

I am just following up to see if you are interested in acquiring the 
Attendees/Visitors  list of,

Sahba Home & Garden Show-2021
29 - 30 Oct 2021
Tucson Convention Center, Tucson, USA
Count = 4450

Each record of the list contains Contact Name, Email Address, Phone No, Title, 
Company Name, URL/Website, City, Country, Zip code.

Let me know your thoughts so that we can send you the cost and additional 
information.


Best Regards,
Olivia Collins
Business Executive

Bug#991066: vlfeat FTBFS with imagemagick with the #987504 change

[Dennis Filder]

Control: tag -1 patch

The attached patch should fix this by overriding the policy.

Regards,
Dennis Filder
--- rules-orig
+++ rules
@@ -10,12 +10,16 @@
 # grab the API version from the library SONAME
 API_VERSION = $(shell objdump -p bin/*/libvl.so | perl -ne 'if(/^\s+SONAME\s+libvl.so./p) {print $${^POSTMATCH}; exit;}')
 
+POLFILE = "/etc/$(shell convert -version|sed -n '/^Version: /s@Version: ImageMagick \([[:digit:]]\+\)\..*@ImageMagick-\1@p')/policy.xml"
+
 %:
 	dh $@
 
 override_dh_auto_build:
-	make PYTHON=python3 MKOCTFILE=`which mkoctfile` VERB=1 CFLAGS+=-g all doc
-
+	mkdir -p debian/tmp/ImageMagick
+	sed -e '//s@"none"@"read|write"@' "$(POLFILE)" > debian/tmp/ImageMagick/policy.xml
+	make XDG_CONFIG_HOME="$(shell pwd)/debian/tmp" PYTHON=python3 MKOCTFILE=`which mkoctfile` VERB=1 CFLAGS+=-g all doc
+	rm -Rf debian/tmp/ImageMagick
 
 override_dh_auto_install: $(addprefix install/,data $(wildcard toolbox/*))
 	cp bin/*/libvl.so libvl.so.$(VERSION)

Bug#783990: efivarfs is a separate fs and needs moutning

[The Wanderer]

On 2021-07-16 at 12:55, Ian Jackson wrote:

> I have now tested this.  I found that a safety catch in
> mount-functions caused it to not work, and this additional patch is
> needed.
> 
> mount-functions looks in /etc/filesystems and skips mounting things
> which the kernel doesn't seem to supoort.  In general with so many
> filesystems being kernel modules this seems to be of questionable use.
> In this case it definitely broke things: I found that mounting the
> filesystem with mount(8) auto-loads the module.
> 
> I'm using the existence of the mountpoint directory as a proxy for the
> filesystem/module being available.  IDK if that is exactly right, but
> if it isn't the worst case is an error message about failing to mount
> it.

Wouldn't testing the existence of

/lib/modules/`uname -r`/kernel/fs/efivarfs/efivarfs.ko

be enough, and probably more reliable?

(I'm assuming that the test which skips because "fstype not available"
comes before the one which skips because "already mounted", and that's
why I saw the warning even though it seems to be up and working on my
machine.)

> For your testing:
> 
> AFAICT it isn't a particularly good idea to just copy the new
> mount-functions.sh into /lib but monkey-applying the patch with
> 
>   patch /lib/init/mount-functions.sh < 
> 0001-initsripts-mount-functions-Do-not-check-efivarfs-in-.patch
> 
> worked for me.  With those patches (and the bodge in fstab commented
> it) it all works.

I need to do some other things for a while, so I won't be rebooting
again immediately, but I'll probably test this sometime this afternoon.


My current biggest concern about this is:

-- 
   The Wanderer

The reasonable man adapts himself to the world; the unreasonable one
persists in trying to adapt the world to himself. Therefore all
progress depends on the unreasonable man. -- George Bernard Shaw



signature.asc
Description: OpenPGP digital signature

Bug#783990: efivarfs is a separate fs and needs moutning

[Ian Jackson]

I have now tested this.  I found that a safety catch in
mount-functions caused it to not work, and this additional patch is
needed.

mount-functions looks in /etc/filesystems and skips mounting things
which the kernel doesn't seem to supoort.  In general with so many
filesystems being kernel modules this seems to be of questionable use.
In this case it definitely broke things: I found that mounting the
filesystem with mount(8) auto-loads the module.

I'm using the existence of the mountpoint directory as a proxy for the
filesystem/module being available.  IDK if that is exactly right, but
if it isn't the worst case is an error message about failing to mount
it.


For your testing:

AFAICT it isn't a particularly good idea to just copy the new
mount-functions.sh into /lib but monkey-applying the patch with

  patch /lib/init/mount-functions.sh < 
0001-initsripts-mount-functions-Do-not-check-efivarfs-in-.patch

worked for me.  With those patches (and the bodge in fstab commented
it) it all works.


Impact on systems which don't need this efivars FS:

I'm pretty sure it will do the right thing on non-EFI systems
(nothing, silently).  I'm also confident that even if it does fail,
the consequences are just a message.

I'm not sure if it will work on non-Linux systems, or indeed whether
it's needed.  I think it most likely that they don't have a /sys laid
out like Linux so this won't do anything.  Again I think the
reasonable worst-case scenario is a boot-time message and a bug still
unfixed.

Ian.

>From 5ac165a021fd361bad658ff50b59ae3e0c4c478d Mon Sep 17 00:00:00 2001
From: Ian Jackson 
Date: Fri, 16 Jul 2021 17:41:25 +0100
Subject: [PATCH] initsripts: mount-functions: Do not check efivarfs in
 /proc/filsystems

It is typically loaded on demand so this is not useful.

Signed-off-by: Ian Jackson 
---
 debian/src/initscripts/lib/init/mount-functions.sh | 5 +
 1 file changed, 5 insertions(+)

diff --git a/debian/src/initscripts/lib/init/mount-functions.sh 
b/debian/src/initscripts/lib/init/mount-functions.sh
index 73b45a79..709323af 100644
--- a/debian/src/initscripts/lib/init/mount-functions.sh
+++ b/debian/src/initscripts/lib/init/mount-functions.sh
@@ -206,6 +206,11 @@ domount () {
case "$KERNEL" in
*)  FSTYPE=$PRIFSTYPE ;;
esac
+   elif [ "$PRIFSTYPE" = efivarfs ]; then
+   # accept efivarfs if its mountpoint exists; kernel will 
auto-load the module
+   if test -d /sys/firmware/efi/efivars; then
+   FSTYPE=$PRIFSTYPE
+   fi
elif grep -E -qs "$PRIFSTYPE\$" /proc/filesystems; then
FSTYPE=$PRIFSTYPE
elif grep -E -qs "$ALTFSTYPE\$" /proc/filesystems; then
-- 
2.20.1



-- 
Ian JacksonThese opinions are my own.  

Pronouns: they/he.  If I emailed you from @fyvzl.net or @evade.org.uk,
that is a private address which bypasses my fierce spamfilter.

Bug#991064: therion FTBFS with imagemagick with the #987504 change

[Dennis Filder]

Control: tag -1 patch

The attached patch seems to allow the "Converting images" step to
succeed.  I ran this only once though.

Regards.
--- debian/rules-orig
+++ debian/rules
@@ -2,6 +2,9 @@
 
 export DEB_BUILD_MAINT_OPTIONS=hardening=+bindnow future=+lfs
 export DH_VERBOSE=1
+
+POLFILE = "/etc/$(shell convert -version|sed -n '/^Version: /s@Version: ImageMagick \([[:digit:]]\+\)\..*@ImageMagick-\1@p')/policy.xml"
+
 %:
 	dh $@
 
@@ -11,7 +14,10 @@
 	# We need therion itself to build the samples
 	$(MAKE) therion
 	# create HTML documentation for samples
-	faketime "$(dpkg-parsechangelog -S Date)" $(MAKE) samples
+	mkdir -p debian/tmp/ImageMagick
+	sed -e '//s@"none"@"read|write"@' "$(POLFILE)" > debian/tmp/ImageMagick/policy.xml
+	faketime "$(dpkg-parsechangelog -S Date)" $(MAKE) XDG_CONFIG_HOME="$(shell pwd)/debian/tmp" samples
+	rm -Rf debian/tmp/ImageMagick
 endif
 	$(MAKE) thbook
 

Bug#783990: efivarfs is a separate fs and needs moutning

[The Wanderer]

On 2021-07-16 at 12:06, Ian Jackson wrote:

> Control: tags -1 + patch

> Here you go, in diff format and also a file you can just run.  I 
> haven't rebooted with it (yet), but I did manually unmount the
> efivars subdir and verify that the new mountkernfs script remounts
> it.

I've just rebooted, with this in place as /etc/init.d/mountkernfs.sh. (I
kept the original around as a renamed file in the same directory.)

The boot-time messages - which, unexpectedly and a bit bizarrely, don't
seem to be logged anywhere that I'm managing to find - include with the
following four lines (transcribed from a photograph taken before
launching X), at what appears to be the beginning of the boot process:

>> INIT: version 2.96 booting
>> Using makefile-style concurrent boot in runlevel S.
>> Filesystem type 'efivarfs' is not supported. Skipping mount. ... (warning).
>> Starting hotplug events dispatcher: systemd-udevd.

Where the string "(warning)." is in orange, rather than the usual
whitish gray.

/sys/firmware/efi/efivars/ exists and is populated just as on the
previous boot, so this didn't break anything, but it also doesn't seem
as if it would have helped if that directory hadn't been mounted for
other reasons.


I notice that the line

>>> Registered efivars operations

appears in the output of 'dmesg', as well as being present (with similar
context) in /var/log/messages* and /var/log/syslog* from at least the
past several boots; if the context would be helpful in figuring out
when/where/how/by-what this is being mounted, I can share the
surrounding lines, or even potentially the entire output if that's
considered potentially safe.

I'm also willing to consider other steps to track down what's making
this work for me, if people care to suggest them. (Unpacking and
analyzing the initrd might well be useful, but is more than I'm
interested in undertaking just at the moment, although I can probably do
it at some point if necessary.)

-- 
   The Wanderer

The reasonable man adapts himself to the world; the unreasonable one
persists in trying to adapt the world to himself. Therefore all
progress depends on the unreasonable man. -- George Bernard Shaw



signature.asc
Description: OpenPGP digital signature

Bug#991184: check_running_kernel script fails with lz4 compressed kernels

[Andrew Shark]

Package: nagios-plugins-contrib
Version: 21.20170222
User: Andrew Shark
Tags: patch
With kernels that use lz4 compression, such as from 
linux-image-5.9.0-0.bpo.5-cloud-amd64 package, the check_running_kernel script 
(that is contained in nagios-plugins-contrib) fails with the following error:
 
root@server# /usr/lib/nagios/plugins/check_running_kernel

UNKNOWN: Failed to get a version string from image 
/boot/vmlinuz-5.9.0-0.bpo.2-cloud-amd64

There is a similar bug in ubuntu: 
https://bugs.launchpad.net/ubuntu/+source/nagios-plugins-contrib/+bug/1918618
And the patch is: 
https://launchpadlibrarian.net/527369842/check_running_kernel.patch

Debian should use the same patch to support such lz4 compressed kernels.

To identify the compression type, you can use the script  by Stephen Kitt from 
here:
https://gist.github.com/skitt/288c0c52b51b5863947a5d6c1180c9f3

Bug#990832: Updates

[William Haller]

Applied fixes from here to fedora 34 base for spamass-milter: 
https://bz.apache.org/SpamAssassin/attachment.cgi?id=5745=diff


With the exception of setting a default macro_r based on whether or not 
there was a cipher since r doesn't seem to be a postfix thing.


macro_cipher = smfi_getsymval(ctx, const_cast("{cipher}"));
if (!macro_cipher)
{
  macro_cipher = "";
  /* Protocol used to receive the message */
  macro_r = smfi_getsymval(ctx, const_cast("r"));
  if (!macro_r)
  {
    macro_r = "ESMTP";
    warnmacro("r", "ENVRCPT");
  }
}
else {
  /* Protocol used to receive the message */
  macro_r = smfi_getsymval(ctx, const_cast("r"));
  if (!macro_r)
  {
    macro_r = "ESMTPS";
    warnmacro("r", "ENVRCPT");
  }
}

and including the changes to append so the lines aren't dropped (setting 
the connected flag after a successful connect, moving the dump of the 
buffer to be after if (!connected) in ::output before the output of 
desired line).


Then corrected the fedora 34 base to include the -I option in the debian 
code.


Then made the final output for computed last hop to be

rec_header = (string) "Received: from " + macro_s + " (" + macro__ + 
")\r\n\t";

if (strlen(macro_tls_version)!=0)
{
  rec_header += (string) "(using ";
  if (strlen(macro_tls_version)!=0) {
    rec_header+=macro_tls_version;
  }
  if (strlen(macro_cipher)!=0) {
    rec_header+=(string) " cipher="+macro_cipher;
  }
  if (strlen(macro_auth_ssf))
  {
    rec_header += (string) " ("+macro_auth_ssf+"/"+macro_auth_ssf+" bits)";
  }
  rec_header += (string) ")\r\n\t";
}
if (strlen(macro_auth_authen)!=0) {
  rec_header += (string) "(Authenticated sender: 
"+macro_auth_authen+")\r\n\t";

}
rec_header += (string) "by " + macro_j + " (Postfix) with " +
  macro_r + " id " + macro_i + ";\r\n\t" +
  "for "+envrcpt[0]+"; "+macro_b + "\r\n";

Which gets rid of unparseable relays and dropped lines. I'm not sure 
what the best fix would or should be - adding a postfix flag so it would 
generate postfix worthy lines for spamassassin or making spamassassin 
recognize the lines put out by spamass-milter as "sendmail" lines. But 
getting the client ip address for the sender seems to be the big thing.


Bill

Bug#991061: ns3 FTBFS with imagemagick with the #987504 change

[Dennis Filder]

Control: tag -1 patch

With this patch the build finished for me.

Regards,
Dennis Filder
Description: Override overly strict ImageMagick security policy (#987504)
 This patch derives a more permissive ImageMagick security policy from
 the system default.
Author: Dennis Filder 
Last-Update: 2021-07-16
Bug-Debian: https://bugs.debian.org/991061
--- a/ns-3.31/doc/models/Makefile
+++ b/ns-3.31/doc/models/Makefile
@@ -496,6 +496,8 @@
 
 RESCALE = ../../utils/rescale-pdf.sh
 
+POLFILE = "/etc/$(shell convert -version|sed -n '/^Version: /s@Version: ImageMagick \([[:digit:]]\+\)\..*@ImageMagick-\1@p')/policy.xml"
+
 %.eps : %.dia
 	@echo dia $(notdir $<)
 	@$(DIA) -t eps $< -e $@ >/dev/null
@@ -506,7 +508,9 @@
 
 %.png : %.eps
 	@echo convert $(notdir $<)
-	@$(CONVERT) $< $@ >/dev/null
+	test -d ../../../debian/tmp/ImageMagick || mkdir -p ../../../debian/tmp/ImageMagick
+	test -f ../../../debian/tmp/ImageMagick/policy.xml || sed -e '//s@"none"@"read|write"@' "$(POLFILE)" > ../../../debian/tmp/ImageMagick/policy.xml
+	XDG_CONFIG_HOME="$(shell pwd)/../../../debian/tmp" $(CONVERT) $< $@ >/dev/null
 
 %.pdf : %.eps
 	@echo epstopdf $(notdir $<)
@@ -556,6 +560,7 @@
 clean:
 	-rm -rf $(BUILDDIR)/*
 	-rm -rf $(SOURCETEMP)
+	-rm -Rf ../../../debian/tmp/ImageMagick
 
 frag: pickle
 	@if test ! -d $(BUILDDIR)/frag; then mkdir $(BUILDDIR)/frag; fi

Bug#991183: libnginx-mod-rtmp memleak

[kalamla...@gmail.com]

Package: libnginx-mod-rtmp
Version: 1.14.2-2+deb10u4
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 ***


-- System Information:
Distributor ID: Raspbian
Description:Raspbian GNU/Linux 10 (buster)
Release:10
Codename:   buster
Architecture: armv7l

Kernel: Linux 5.10.17-v7l+ (SMP w/4 CPU cores)
Kernel taint flags: TAINT_CRAP
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) (ignored: LC_ALL 
set to en_US.UTF-8), LANGUAGE=en_US.UTF-8 (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)

Versions of packages libnginx-mod-rtmp depends on:
ii  libc6 2.28-10+rpi1
ii  nginx-common  1.14.2-2+deb10u4

libnginx-mod-rtmp recommends no packages.

libnginx-mod-rtmp suggests no packages.

-- no debconf information
nginx.conf:
rtmp_auto_push on;

rtmp {
server {
listen 1935;

application mytv {
live on;
}
}
}


ffmpeg command used to transmit to nginx:
fmpeg -f v4l2 -video_size 640x480 -pix_fmt yuv420p -framerate 8 -i /dev/video0 
-vcodec h264_omx -b:v 400k -f flv rtmp://localhost:1935/mytv/zonk

and motion deamon connected to the same endpoint.

after a few days of work nginx takes 77% of Raspberry PI 4B memory, but just 
after start of nginx it takes only a few MB.

Best regards,
Lukasz Kalamlacki

Bug#783990: efivarfs is a separate fs and needs moutning

[The Wanderer]

On 2021-07-16 at 11:54, Thorsten Glaser wrote:

> On Fri, 16 Jul 2021, The Wanderer wrote:
> 
>> On Fri, 16 Jul 2021, Ian Jackson wrote:
>> 
>>> On Fri, 16 Jul 2021, The Wanderer wrote:

 A possible additional complicating factor: on my system
 (tracking current testing, which I suspect is likely to turn
 into stable fairly
> 
> Roughly 15 more days, AFAIHH.

I didn't realize it had actually been scheduled; in my experience, any
time someone asks when the release will happen, the only answer is "When
it's ready.", and the gap between the ready date becoming known and the
release happening tends to be so small there's no room for the question
to be asked.

 soon), with sysvinit as the active init system, this directory
 already exists and is already mounted.
> 
> Then test for existence of a file inside that first. I don’t have
> access to an EFI system, can you share an “ls -l
> /sys/firmware/efi/efivars”, and probably an “ls -l /sys/firmware/efi”
> and “mount” as well?

I think in principle relying on any specific file inside there would be
potentially fragile, but in practice it might be possible to choose
something that would be unlikely to go away in later kernels etc..

The attached file contains the requested output. It's not clear
immediately whether the UUIDs are machine-specific or will be consistent
across machines; efivarfs.rst.txt points me to
/usr/share/doc/linux-doc-5.10/Documentation/ABI/stable/sysfs-firmware-efi-vars.gz
- which mentions namespacing via vendor GUID, but also seems to say that
the items whose names will contain those GUIDs are directories, so I'm
not sure whether it's relevant here.

>>> I suggest the following approach in mountkernfs:
> 
> 1.See if /sys/firmware/efi/efivars/somefile exists;
>   if it does, it’s already mounted, and there’s
>   nothing to do.
> 
>>>   - See if /sys/firmware/efi/efivars exists.
>>>
>>>   - If it does, and nothing is mounted on it yet, try to mount
>>> efivarfs with the runes earlier in this bug.
> 
> Is /sys/firmware/efi also a mountpoint, or is it a mere directory?

On my system, it is not mentioned separately in the output of 'mount'. I
think, but am not positive, that that's sufficient indication that it
isn't a mountpoint.

> Does it always contain an efivars subdirectory?

I can't testify one way or the other, but I suspect from the little I've
read about this that it does not.

-- 
   The Wanderer

The reasonable man adapts himself to the world; the unreasonable one
persists in trying to adapt the world to himself. Therefore all
progress depends on the unreasonable man. -- George Bernard Shaw
/sys/firmware/efi:
total 0
-r--r--r--  1 root root 4096 Jul 16 08:23 config_table
drwxr-xr-x  2 root root0 Jul 15 18:29 efivars
drwxr-xr-x  3 root root0 Jul 16 08:23 esrt
-r--r--r--  1 root root 4096 Jul 16 08:23 fw_platform_size
-r--r--r--  1 root root 4096 Jul 16 08:23 fw_vendor
drwxr-xr-x  2 root root0 Jul 16 08:23 mok-variables
-r--r--r--  1 root root 4096 Jul 16 08:23 runtime
drwxr-xr-x 19 root root0 Jul 16 08:23 runtime-map
-r  1 root root 4096 Jul 16 08:23 systab

/sys/firmware/efi/efivars:
total 0
-rw-r--r-- 1 root root   14 Jul 15 18:29 
AmdAcpiVar-79941ecd-ed36-49d0-8124-e4c31ac75cd4
-rw-r--r-- 1 root root  132 Jul 15 18:29 
AMD_PBS_SETUP-a339d746-f678-49b3-9fc7-54ce0f9df226
-rw-r--r-- 1 root root   12 Jul 15 18:29 
AMD_RAID-fe26a894-d199-47d4-8afa-070e3d54ba86
-rw-r--r-- 1 root root 1557 Jul 15 18:29 
AmdSetup-3a997502-647a-4c82-998e-52ef9486a247
-rw-r--r-- 1 root root8 Jul 15 18:29 
AmiHardwareSignatureSetupUpdateCountVar-81c76078-bfde-4368-9790-570914c01a65
-rw-r--r-- 1 root root   28 Jul 15 18:29 
AMITCGPPIVAR-a8a2093b-fefa-43c1-8e62-ce526847265e
-rw-r--r-- 1 root root 1024 Jul 15 18:29 
AOD_SETUP-5ed15dc0-edef-4161-9151-6014c4cc630c
-rw-r--r-- 1 root root8 Jul 15 18:29 
ApSyncFlagNv-ad3f6761-f0a3-46c8-a4cb-19b70ffdb305
-rw-r--r-- 1 root root5 Jul 15 18:29 
asusbkpsmmflag-3eb0ceb0-5890-4853-9a13-0942ec71
-rw-r--r-- 1 root root   20 Jul 15 18:29 
AsusRomLayout-2e0585e9-2b5e-4f1e-bbeb-e632c5ef44b8
-rw-r--r-- 1 root root   56 Jul 15 18:29 
AutoDetectData-ec87d643-eba4-4bb5-a1e5-3f3e36b20da9
-rw-r--r-- 1 root root  186 Jul 15 18:29 
BiosEventLog-4034591c-48ea-4cdc-864f-e7cb61cfd0f2
-rw-r--r-- 1 root root   92 Jul 15 18:29 
BiosSettingMappingTable-b57086d5-c2e5-4654-9e3a-0b55830fbb32
-rw-r--r-- 1 root root  122 Jul 15 18:29 
Boot-8be4df61-93ca-11d2-aa0d-00e098032b8c
-rw-r--r-- 1 root root  126 Jul 15 18:29 
Boot0001-8be4df61-93ca-11d2-aa0d-00e098032b8c
-rw-r--r-- 1 root root6 Jul 15 18:29 
BootCurrent-8be4df61-93ca-11d2-aa0d-00e098032b8c
-rw-r--r-- 1 root root5 Jul 15 18:29 
BootFromUSB-ec87d643-eba4-4bb5-a1e5-3f3e36b20da9
-rw-r--r-- 1 root root8 Jul 15 18:29 
BootOptionSupport-8be4df61-93ca-11d2-aa0d-00e098032b8c
-rw-r--r-- 1 root root8 Jul 15 18:29 
BootOrder-8be4df61-93ca-11d2-aa0d-00e098032b8c
-rw-r--r-- 1 root root6 Jul 15 18:29 

Bug#990763: [debian-mysql] Bug#990763: mariadb-server-core-10.3: MariaDB 10.3.29 is crashing and restarting continuously

[Faustin Lammler]

Hi!

Thanks for your detailed report.

I can't see anything related to Debian packaging and you seem to have
hit a bug in mariadb-server and I suggest you to ask for help with
upstream developers.

I have searched a bit in upstream issue but I can't find an issue
describing the exact same situation as yours. MDEV-25394 seems quite
similar though: https://jira.mariadb.org/browse/MDEV-25394

If you can't find a similar issue, then I encourage you to create one
and link this bug report to it (see "Setting Forwarded":
https://www.debian.org/Bugs/Reporting)

Thanks!

--
Faustin


signature.asc
Description: PGP signature

Bug#783990: efivarfs is a separate fs and needs moutning

[Ian Jackson]

Control: tags -1 + patch

Thorsten Glaser writes ("Re: Bug#783990: efivarfs is a separate fs and needs 
moutning"):
> /sys/firmware/efi does not exist for me.

Cool.

> >> I suggest the following approach in mountkernfs:
> 
> 1.See if /sys/firmware/efi/efivars/somefile exists;
>   if it does, it’s already mounted, and there’s
>   nothing to do.

It turns out that the domount function in mount-functions.sh already
uses a utility called `mountpoint` to check if something is already
mounted, so I think it's probably best just to go with that.

> Is /sys/firmware/efi also a mountpoint, or is it a mere directory?
> Does it always contain an efivars subdirectory? (Though, if it
> doesn’t, we can’t create it anyway, I guess.)

On my EFI system, /sys/firmware is just a directory in /sys.  Likewise
/sys/firmware/efi.  Ie, the mountpoints are just /sys and
/sys/firmware/efi/efivars (and of course various other things in /sys
like /sys/fs/pstore or whatever).

Indeed, I don't think we can create the efivars subdir.

> Sure¹, but let’s hold out a bit, we need some fixed file within
> /sys/firmware/efi/efivars/ to test for… or see if it’s empty,
> depending. I might have a look at the kernel source if needed.

As I say, I don't think we need that.  I tested my patched script and
on my system it is silently idempotent.

Also, I looked in mjy /sys/firmware/efivars and OMG.  It's full of
crazy stuff with names coming from EFI0land and I don't think there
would be anything sensible to test in it.

>  I just switched all my systems from sid to bullseye to avoid
>   the latest TC decision, but I can just live-patch the file
>   in question.

Here you go, in diff format and also a file you can just run.  I
haven't rebooted with it (yet), but I did manually unmount the efivars
subdir and verify that the new mountkernfs script remounts it.

I notice that my added section is very similar to the pstore section
immediately above - and this happened without me copying it :-), which
gives me confidence.

Ian.



0001-mountkernfs-Mount-sys-firmware-efi-efivars-if-necess.patch
Description: Binary data


mountkernfs.sh
Description: Binary data


-- 
Ian JacksonThese opinions are my own.  

Pronouns: they/he.  If I emailed you from @fyvzl.net or @evade.org.uk,
that is a private address which bypasses my fierce spamfilter.

Bug#991015: Acknowledgement (cannot execute due to incorrect shebang line)

[Ryan Kavanagh]

On Fri, Jul 16, 2021 at 06:37:52PM +0530, Pirate Praveen wrote:
> See https://lists.debian.org/debian-ruby/2021/07/msg2.html
> Since it affects only very old releases, reducing severity.

I think that Antonio's claim that

this should only be a problem on older systems, I would even say
only in already non-supported Debian releases.

is wrong, at least regarding the second clause. This bug affects me on
Debian unstable, and will likely affect anybody who has been upgrading
between stable releases and who has not installed a more recent version
of ruby.

It's too late to fix this for bullseye, so I think it would be
worthwhile to add a release note so that users are aware of the
potential issue when upgrading to the next stable release.

Ryan

-- 
|)|/  Ryan Kavanagh  | 4E46 9519 ED67 7734 268F
|\|\  https://rak.ac | BD95 8F7B F8FC 4A11 C97A


signature.asc
Description: PGP signature

Bug#783990: efivarfs is a separate fs and needs moutning

[Thorsten Glaser]

On Fri, 16 Jul 2021, The Wanderer wrote:
>On Fri, 16 Jul 2021, Ian Jackson wrote:
>>On Fri, 16 Jul 2021, The Wanderer wrote:
>>>On Fri, 16 Jul 2021, Ian Jackson wrote:
 Thorsten Glaser writes ("Re: Bug#783990: efivarfs is a separate fs and 
 needs moutning"):
 > This is not as easy as it sounds:
 >
 > tglase@tglase-nb:~ $ sudo mount -t efivarfs efivarfs 
 > /sys/firmware/efi/efivars
 > mount: /sys/firmware/efi/efivars: mount point does not exist.
 > 32|tglase@tglase-nb:~ $ sudo mkdir -p /sys/firmware/efi/efivars
 > mkdir: cannot create directory ‘/sys/firmware/efi’: Operation not 
 > permitted
 >
 > This is on amd64 without EFI (classical BIOS, no CSM).

 Oh.

 I guess this should be done if /sys/firmware/efi/efivars exists, then.

 Can you confirm that that directory doesn't exist for you ?

/sys/firmware/efi does not exist for me.

tglase@tglase-nb:~ $ mount
/dev/sda4/ ext4 
(rw,relatime,errors=remount-ro,stripe=256)
/dev/sda1/boot ext4 (rw,noatime,sync)
udev /dev  devtmpfs 
(rw,nosuid,relatime,size=4014412k,nr_inodes=1003603,mode=755)
devpts   /dev/pts  devpts   
(rw,nosuid,noexec,relatime,gid=5,mode=600,ptmxmode=000)
tmpfs/dev/shm  tmpfs
(rw,nosuid,nodev,noexec,relatime,size=1614660k)
proc /proc proc 
(rw,nosuid,nodev,noexec,relatime)
binfmt_misc  /proc/sys/fs/binfmt_misc  binfmt_misc  
(rw,nosuid,nodev,noexec,relatime)
tmpfs/run  tmpfs
(rw,nosuid,nodev,noexec,relatime,size=807336k,mode=755)
tmpfs/run/lock tmpfs
(rw,nosuid,nodev,noexec,relatime,size=5120k)
sysfs/sys  sysfs
(rw,nosuid,nodev,noexec,relatime)
pstore   /sys/fs/pstorepstore   (rw,relatime)
securityfs   /sys/kernel/security  securityfs   (rw,relatime)
tmpfs/tmp  tmpfs
(rw,nosuid,nodev,relatime,size=6458640k)
swap /var/cache/apttmpfs
(rw,nosuid,noexec,relatime,mode=755)
tglase@tglase-nb:~ $ ls -l /sys/firmware/
total 0
drwxr-xr-x  5 root root 0 16. Jul 17:43 acpi
drwxr-xr-x  4 root root 0 16. Jul 17:43 dmi
drwxr-xr-x 18 root root 0 16. Jul 17:43 memmap

(My “mount” does
mount | sed 's/ on \([^ ]*\) type / \1 /' | sort -bk2 | column -t
for better legible output.)

>>> A possible additional complicating factor: on my system (tracking
>>> current testing, which I suspect is likely to turn into stable fairly

Roughly 15 more days, AFAIHH.

>>> soon), with sysvinit as the active init system, this directory already
>>> exists and is already mounted.

Then test for existence of a file inside that first. I don’t have access
to an EFI system, can you share an “ls -l /sys/firmware/efi/efivars”,
and probably an “ls -l /sys/firmware/efi” and “mount” as well?

>> Perhaps the initramfs mounts it ?  I can't conveniently check.

Possibly. Me either.

> (It also finds that
> /usr/share/doc/linux-doc-5.10/html/_sources/filesystems/efivarfs.rst.txt
> suggests 'mount -t efivarfs none mountpoint' rather than 'mount -t
> efivarfs efivarfs mountpoint', but I suspect the end result will be the
> same regardless.)

That won’t make a difference other than the (decorative, for
pseudo filesystems) first column of mount output. I consider
it more useful to not just put “none” in there for most.

>> I suggest the following approach in mountkernfs:

1.  See if /sys/firmware/efi/efivars/somefile exists;
if it does, it’s already mounted, and there’s
nothing to do.

>>   - See if /sys/firmware/efi/efivars exists.
>>
>>   - If it does, and nothing is mounted on it yet, try to mount
>> efivarfs with the runes earlier in this bug.

Is /sys/firmware/efi also a mountpoint, or is it a mere directory?
Does it always contain an efivars subdirectory? (Though, if it
doesn’t, we can’t create it anyway, I guess.)

>>   - If that mount fails, print an error message, but otherwise
>> do not treat this as an error.

Agreed. Perhaps just display the error from the mount.

>> If you think this is a good plan I will send a patch.  Would each of
>> you be willing to do a test reboot with it ?

Sure¹, but let’s hold out a bit, we need some fixed file within
/sys/firmware/efi/efivars/ to test for… or see if it’s empty,
depending. I might have a look at the kernel source if needed.

① I just switched all my systems from sid to bullseye to avoid
  the latest TC decision, but I can just live-patch the file
  in question.

bye,
//mirabilos
-- 
15:41⎜ Somebody write a testsuite for helloworld :-)

Bug#991182: unblock: jailkit/2.21-4

[Joao Eriberto Mota Filho]

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

Dear Release Team,

Please unblock package jailkit.

[ Reason ]

The upstream migrated the source code from Python2 to Python3 in a
previous release (Debian revision 2.21-1). Recently, he released a new
version to fix some issues (upstream/2.22). This new version fixes two
bad lines, not compatibles with Python3 in file py/jk_update.in.

In this week, the bug #991075 pointed a crash in the current revision in
testing (2.21-3), caused by those two lines (without the fix), generating
a crash in the jail environment when updating it.

To fix, I made a patch over 2.21 version.

[ Impact ]

jailkit is a set of tools to generate chroot jails easily. If the unblock
isn't granted, the final user will be able to create a chroot environment
but it will not be updated. There is a security issue here, because the
user will always work inside an outdated environment.

[ Tests ]

This fix was tested by the upstream, by the bug submitter (Jesse Norel)
and by me.

[ Risks ]

This is a trivial fix and it has no risks. I made contact with the
upstream to ask if this alone change could impact negatively in whole
source code and the answer was "yes it is secure to change only those two
lines"[1].

 [1] https://lists.nongnu.org/archive/html/jailkit-dev/2021-07/msg1.html

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

[ Other info ]

Debian bug: https://bugs.debian.org/991075
Upstream changes: 
https://cvs.savannah.nongnu.org/viewvc/jailkit/jailkit/py/jk_update.in?r1=1.16=1.18=log
Upstream contact: 
https://lists.nongnu.org/archive/html/jailkit-dev/2021-07/msg0.html

unblock jailkit/2.21-4
diff -Nru jailkit-2.21/debian/changelog jailkit-2.21/debian/changelog
--- jailkit-2.21/debian/changelog   2020-08-24 10:23:23.0 -0300
+++ jailkit-2.21/debian/changelog   2021-07-16 11:31:18.0 -0300
@@ -1,3 +1,13 @@
+jailkit (2.21-4) unstable; urgency=medium
+
+  * debian/control: bumped Standards-Version to 4.5.1.
+  * debian/copyright: updated upstream and packaging copyright years.
+  * debian/patches/040_fix-crash-jk_update.patch: created to migrate two lines
+from Python2 to 3, fixing Python3 compatibility and avoiding a crash when
+updating the jail. (Closes: #991075)
+
+ -- Joao Eriberto Mota Filho   Fri, 16 Jul 2021 11:31:18 
-0300
+
 jailkit (2.21-3) unstable; urgency=medium
 
   * debian/control:
diff -Nru jailkit-2.21/debian/control jailkit-2.21/debian/control
--- jailkit-2.21/debian/control 2020-08-24 10:23:23.0 -0300
+++ jailkit-2.21/debian/control 2021-07-16 11:31:18.0 -0300
@@ -3,7 +3,7 @@
 Priority: optional
 Maintainer: Joao Eriberto Mota Filho 
 Build-Depends: debhelper-compat (= 13), dh-python, python3-all
-Standards-Version: 4.5.0
+Standards-Version: 4.5.1
 Rules-Requires-Root: no
 Homepage: https://olivier.sessink.nl/jailkit/
 Vcs-Browser: https://salsa.debian.org/debian/jailkit
diff -Nru jailkit-2.21/debian/copyright jailkit-2.21/debian/copyright
--- jailkit-2.21/debian/copyright   2020-08-24 10:23:23.0 -0300
+++ jailkit-2.21/debian/copyright   2021-07-16 11:31:18.0 -0300
@@ -4,7 +4,7 @@
 Source: https://olivier.sessink.nl/jailkit/
 
 Files: *
-Copyright: 2003-2019 Olivier Sessink 
+Copyright: 2003-2021 Olivier Sessink 
 License: BSD-3-Clause
 
 Files: man/*
@@ -23,7 +23,7 @@
 License: LGPL-2+
 
 Files: debian/*
-Copyright: 2019-2020 Joao Eriberto Mota Filho 
+Copyright: 2019-2021 Joao Eriberto Mota Filho 
 License: BSD-3-Clause
 
 License: BSD-3-Clause
diff -Nru jailkit-2.21/debian/patches/040_fix-crash-jk_update.patch 
jailkit-2.21/debian/patches/040_fix-crash-jk_update.patch
--- jailkit-2.21/debian/patches/040_fix-crash-jk_update.patch   1969-12-31 
21:00:00.0 -0300
+++ jailkit-2.21/debian/patches/040_fix-crash-jk_update.patch   2021-07-16 
11:31:18.0 -0300
@@ -0,0 +1,36 @@
+Description: Fix Python3 compatibility, avoiding a crash when updating jail
+Author: Olivier Sessink 
+Bug-Debian: https://bugs.debian.org/991075
+Origin: 
https://cvs.savannah.nongnu.org/viewvc/jailkit/jailkit/py/jk_update.in?r1=1.16=1.18
+Forwarded: not-needed
+Last-Update: 2021-07-16
+Index: jailkit/py/jk_update.in
+===
+--- jailkit.orig/py/jk_update.in
 jailkit/py/jk_update.in
+@@ -1,6 +1,6 @@
+ #!/usr/bin/python
+ #
+-#Copyright (c) 2006, 2007, Olivier Sessink
++#Copyright (c) 2006, 2007, 2020, 2021 Olivier Sessink
+ #All rights reserved.
+ #
+ #Redistribution and use in source and binary forms, with or without
+@@ -260,7 +260,7 @@ def main():
+   tmp = 
jk_lib.config_get_option_as_list(cfg,configsection,'skips')
+   for entry in tmp:
+   skips.append(entry)
+-  if 

Bug#991015: Acknowledgement (cannot execute due to incorrect shebang line)

[Pirate Praveen]

Control: severity -1 important

On Mon, 12 Jul 2021 21:10:15 -0400 Ryan Kavanagh  wrote:
> This bug seems to be, in part, due to a potentially (?) broken ruby
> upgrade behaviour. I've been running unstable on this laptop for ~6
> years, but still had
> 
> ii  ruby2.1 [ruby-interpreter]  2.1.5-4
> ii  ruby2.2 [ruby-interpreter]  2.2.4-1
> 
> installed as my only ruby interpreters. These are no longer available in
> unstable, and ruby2.1 was last available in:
> 
> ruby2.1| 2.1.5-2+deb8u3 | oldoldstable | source, amd64, armel, armhf, i386
> 
> Will users upgrading from buster to bullseye will encounter a similar
> issue if they've dist-upgraded from jessie to stretch to buster?

rubyX.Y no longer provides ruby-interpreter from ruby2.3

See https://lists.debian.org/debian-ruby/2021/07/msg2.html
Since it affects only very old releases, reducing severity.

-- 
Sent from my p≡p for Android.

Bug#991139: sgt-puzzles: status bar missing in Debian build

[Ben Hutchings]

On Thu, 2021-07-15 at 16:07 +0200, alex wrote:
> Package: sgt-puzzles
> Version: 20170606.272beef-1
> Severity: normal
> 
> Dear Ben Hutchings,
> 
> I enjoyed playing Simon Tatham's puzzles when I still was running
> Windows as my daily driver but since then I transitioned to
> Debian/LMDE.
> What I noticed right away but until now never really cared for is
> that the Windows build features a status bar at the bottom (and ports
> like the Android port have this bar, too, somewhat), but the Debian
> package does not.
> This status bar shows information like (where applicable) the elapsed
> time or counters of some sort.
[...]

The status bar is implemented, but with some themes (particularly dark
ones) it can use the same or very similar colours for text and
background.  There is a similar issue with menu colours (#944237).

Ben.

-- 
Ben Hutchings
Beware of programmers who carry screwdrivers. - Leonard Brandwein


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

Bug#991181: cmocka: reproducible builds: Embeds build path in documentation

[Vagrant Cascadian]

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

The build path is embedded in various documentation files:

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

  ./usr/share/doc/cmocka-doc/html/cmocka_8h_source.html

  cmocka:·/build/1st/cmocka-1.1.5/include/cmocka.h·Source·File
  vs.
  cmocka:·/build/2/cmocka-1.1.5/2nd/include/cmocka.h·Source·File

The attached patch fixes this by setting configuration options in
doc/CMakeLists.txt to pass FULL_PATH_NAMES = NO in the doxygen
configuration used to generate the documentation.


Thanks for maintaining cmocka!


live well,
  vagrant
From a2905110f40b93d17830953aecc22d2379bceea1 Mon Sep 17 00:00:00 2001
From: Vagrant Cascadian 
Date: Fri, 16 Jul 2021 15:13:48 +
Subject: [PATCH] doc/CMakeLists.txt: Disable embedding of full path names in
 documentation generated by doxygen.

https://reproducible-builds.org/docs/build-path/
https://tests.reproducible-builds.org/debian/issues/unstable/build_dir_in_documentation_generated_by_doxygen_issue.html
---
 doc/CMakeLists.txt | 1 +
 1 file changed, 1 insertion(+)

diff --git a/doc/CMakeLists.txt b/doc/CMakeLists.txt
index 6ac7494..9d4e7b5 100644
--- a/doc/CMakeLists.txt
+++ b/doc/CMakeLists.txt
@@ -31,6 +31,7 @@ if (DOXYGEN_FOUND)
  ${CMAKE_CURRENT_SOURCE_DIR}/that_style/img/folderclosed.svg
  ${CMAKE_CURRENT_SOURCE_DIR}/that_style/img/folderopen.svg
  ${CMAKE_CURRENT_SOURCE_DIR}/that_style/js/striped_bg.js)
+set(DOXYGEN_FULL_PATH_NAMES no)
 
 set(_doxyfile_template "${CMAKE_BINARY_DIR}/CMakeDoxyfile.in")
 set(_target_doxyfile "${CMAKE_CURRENT_BINARY_DIR}/Doxyfile.docs")
-- 
2.32.0



signature.asc
Description: PGP signature

Bug#783990: efivarfs is a separate fs and needs moutning

[The Wanderer]

(For some reason, I haven't gotten the copy of this reply that comes to
me via debian-init-diversity, even though it's clearly Cc'ed to the bug
which appears to send copies to that list. Is something in the chain -
probably BDO - detecting that I'm already in Cc and not sending the
second copy? That would be unfortunate, and a reason for me to return to
replying only to the bug number rather than to the full addressee
list...)

On 2021-07-16 at 11:00, Ian Jackson wrote:
> 
> The Wanderer writes ("Re: Bug#783990: efivarfs is a separate fs and
> needs moutning"):
>> 
>> I'm not sure what's making the difference (unless this is already
>> fixed for testing, and you're only discussing whether to backport
>> the fix to current stable, which I think doesn't sound like it is
>> the case),
> 
> Perhaps the initramfs mounts it ?  I can't conveniently check.

A quick grep through /usr and /etc/ for 'efivar' finds one thing that
looks potentially relevant: /etc/apparmor.d/abstractions/libvirt-lxc
includes a mount command for this directory.

(It also finds that
/usr/share/doc/linux-doc-5.10/html/_sources/filesystems/efivarfs.rst.txt
suggests 'mount -t efivarfs none mountpoint' rather than 'mount -t
efivarfs efivarfs mountpoint', but I suspect the end result will be the
same regardless.)

>> and I'm not sure where to look to try to find out - but whatever
>> fix is found for anyone experiencing this problem, it'll be
>> important to make sure it doesn't break people for whom this *is*
>> working.
> 
> Certainly.
> 
> I suggest the following approach in mountkernfs:
> 
>   - See if /sys/firmware/efi/efivars exists.
> 
>   - If it does, and nothing is mounted on it yet, try to mount
> efivarfs with the runes earlier in this bug.
> 
>   - If that mount fails, print an error message, but otherwise
> do not treat this as an error.
> 
> If you think this is a good plan I will send a patch.  Would each of
> you be willing to do a test reboot with it ?

That looks like a reasonable approach to me. I'm not sure exactly what
steps would be necessary to be sure that the reboot was properly testing
the patch, but as long as there's no meaningful risk of putting my
system into an unbootable state (an unlikely-seeming result), I have no
problem with testing this when time permits.

-- 
   The Wanderer

The reasonable man adapts himself to the world; the unreasonable one
persists in trying to adapt the world to himself. Therefore all
progress depends on the unreasonable man. -- George Bernard Shaw



signature.asc
Description: OpenPGP digital signature

Bug#783990: efivarfs is a separate fs and needs moutning

[Ian Jackson]

The Wanderer writes ("Re: Bug#783990: efivarfs is a separate fs and needs 
moutning"):
> I'm not sure what's making the difference (unless this is already fixed
> for testing, and you're only discussing whether to backport the fix to
> current stable, which I think doesn't sound like it is the case),

Perhaps the initramfs mounts it ?  I can't conveniently check.

> and I'm not sure where to look to try to find out - but whatever fix
> is found for anyone experiencing this problem, it'll be important to
> make sure it doesn't break people for whom this *is* working.

Certainly.

I suggest the following approach in mountkernfs:

  - See if /sys/firmware/efi/efivars exists.

  - If it does, and nothing is mounted on it yet, try to mount
efivarfs with the runes earlier in this bug.

  - If that mount fails, print an error message, but otherwise
do not treat this as an error.

If you think this is a good plan I will send a patch.  Would each of
you be willing to do a test reboot with it ?

Ian.

-- 
Ian JacksonThese opinions are my own.  

Pronouns: they/he.  If I emailed you from @fyvzl.net or @evade.org.uk,
that is a private address which bypasses my fierce spamfilter.

Bug#991180: xaw3d: reproducible builds: Embeds build path in libXaw3d.so

[Vagrant Cascadian]

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

The build path is embedded in various places in libXaw3d.so.*:

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

  ./usr/lib/x86_64-linux-gnu/libXaw3d.so.6.1

  /build/1st/xaw3d-1.5+F/xc/lib/Xaw3d/AsciiSrc.c:263
  vs.
  /build/2/xaw3d-1.5+F/2nd/xc/lib/Xaw3d/AsciiSrc.c:263

The attached patch fixes this by passing -ffile-prefix-map and -I. to
CFLAGS in debian/rules to avoid embedding the build path.


Thanks for maintaining xaw3d!


live well,
  vagrant
From 5f84216e4f3fce385a5e27317f521aa89637c63f Mon Sep 17 00:00:00 2001
From: Vagrant Cascadian 
Date: Fri, 16 Jul 2021 14:43:18 +
Subject: [PATCH] debian/rules: Pass CFLAGS with file-prefix-map in
 dh_auto_build.

Without file-prefix-map, the build path is embedded in the resulting
binaries. This converts it into a relative path. This also requires
passing "-I." to ensure the headers in the source are available under
a relative path.

https://reproducible-builds.org/docs/build-path/
---
 debian/rules | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/debian/rules b/debian/rules
index f8f65f3..d88124b 100755
--- a/debian/rules
+++ b/debian/rules
@@ -13,7 +13,8 @@ override_dh_auto_build:
 	rm -rf $(SOURCE)/X11 && install -m755 -d $(SOURCE)/X11
 	cd $(SOURCE) && ln -sf ../ X11/Xaw3d && xmkmf
 	$(MAKE) -C $(SOURCE) \
-  EXTRA_DEFINES="-D_REENTRANT -DARROW_SCROLLBAR" SHLIBDEF="-D_REENTRANT -DARROW_SCROLLBAR"
+  EXTRA_DEFINES="-D_REENTRANT -DARROW_SCROLLBAR" SHLIBDEF="-D_REENTRANT -DARROW_SCROLLBAR" \
+  CFLAGS="-ffile-prefix-map=$(CURDIR)=. -I."
 
 override_dh_auto_clean:
 	rm -rf $(SOURCE)/X11 $(COMPAT) lib/Xaw3d/laygram.h
-- 
2.32.0



signature.asc
Description: PGP signature

Bug#783990: efivarfs is a separate fs and needs moutning

[The Wanderer]

On 2021-07-16 at 10:23, Ian Jackson wrote:

> Control: tags -1 patch
> 
> Thorsten Glaser writes ("Re: Bug#783990: efivarfs is a separate fs and needs 
> moutning"):
>> This is not as easy as it sounds:
>> 
>> tglase@tglase-nb:~ $ sudo mount -t efivarfs efivarfs 
>> /sys/firmware/efi/efivars
>> mount: /sys/firmware/efi/efivars: mount point does not exist.
>> 32|tglase@tglase-nb:~ $ sudo mkdir -p /sys/firmware/efi/efivars
>> mkdir: cannot create directory ‘/sys/firmware/efi’: Operation not permitted
>> 
>> This is on amd64 without EFI (classical BIOS, no CSM).
> 
> Oh.
> 
> I guess this should be done if /sys/firmware/efi/efivars exists, then.
> 
> Can you confirm that that directory doesn't exist for you ?

A possible additional complicating factor: on my system (tracking
current testing, which I suspect is likely to turn into stable fairly
soon), with sysvinit as the active init system, this directory already
exists and is already mounted.

I'm not sure what's making the difference (unless this is already fixed
for testing, and you're only discussing whether to backport the fix to
current stable, which I think doesn't sound like it is the case), and
I'm not sure where to look to try to find out - but whatever fix is
found for anyone experiencing this problem, it'll be important to make
sure it doesn't break people for whom this *is* working.

-- 
   The Wanderer

The reasonable man adapts himself to the world; the unreasonable one
persists in trying to adapt the world to himself. Therefore all
progress depends on the unreasonable man. -- George Bernard Shaw



signature.asc
Description: OpenPGP digital signature

Bug#991179: unblock: hamlib/4.0-7

[tony mancill]

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

Dear Release Team,

Please consider an unblock for package hamlib.

[ Reason ]

This upload adds a patch for a bug that causes some programs that use
hamlib to crash upon startup.  See:

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

[ Impact ]

The severity of bug 980472 impacts all reverse dependencies of hamlib;
its removal would transitively remove several popular Ham Radio packages
from the Bullseye release.  Alternately, the bug could be downgraded and 
cubicsdr
and any other applications that call rig_load_all_backends() more than
once would remain broken.

[ Tests ]

The reported issue with cubicsdr is trivially reproducible with the
current version.  After verifying the crash, I installed the patched
libhamlib4 and libhamlib-utils packages and manually tested cubicsdr,
wsjtx, and xlog.


[ Risks ]

The patch clears memory in a hash table so repopulating the table
doesn't fail.  Since it is only called when the table is being
reconstructed, it seems quite safe.  (The code works on the first call
because it depends on the memory being initialized to zeros.)

The patch originates (and has been applied) upstream.

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

[ Other info ]

Thank you, and apologies for the very late unblock request!

Cheers,
tony

unblock hamlib/4.0-7
diff -Nru hamlib-4.0/debian/changelog hamlib-4.0/debian/changelog
--- hamlib-4.0/debian/changelog 2021-05-11 10:03:12.0 -0700
+++ hamlib-4.0/debian/changelog 2021-07-15 21:31:14.0 -0700
@@ -1,3 +1,11 @@
+hamlib (4.0-7) unstable; urgency=medium
+
+  * Team upload.
+  * Allow rig_load_all_backends to be called more than once.
+(Closes: #980472)
+
+ -- tony mancill   Thu, 15 Jul 2021 21:31:14 -0700
+
 hamlib (4.0-6) unstable; urgency=medium
 
   * Paper over a minor precision difference in dec2dms on i386.
diff -Nru hamlib-4.0/debian/patches/31dedcf4f79d8fc5fcf287360e5d017842c8e4c0 
hamlib-4.0/debian/patches/31dedcf4f79d8fc5fcf287360e5d017842c8e4c0
--- hamlib-4.0/debian/patches/31dedcf4f79d8fc5fcf287360e5d017842c8e4c0  
1969-12-31 16:00:00.0 -0800
+++ hamlib-4.0/debian/patches/31dedcf4f79d8fc5fcf287360e5d017842c8e4c0  
2021-07-15 21:31:14.0 -0700
@@ -0,0 +1,17 @@
+Comment: Allow rig_load_all_backends to be called more than once
+Bug-Debian: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=980472
+Forwarded: not-needed
+Source: 
https://sourceforge.net/p/hamlib/code/ci/31dedcf4f79d8fc5fcf287360e5d017842c8e4c0/
+Author: Michael Black W9MDB
+
+--- a/src/register.c
 b/src/register.c
+@@ -454,6 +454,8 @@
+ {
+ int i;
+ 
++memset(rig_hash_table, 0 , sizeof(rig_hash_table));
++
+ for (i = 0; i < RIG_BACKEND_MAX && rig_backend_list[i].be_name; i++)
+ {
+ rig_load_backend(rig_backend_list[i].be_name);
diff -Nru hamlib-4.0/debian/patches/series hamlib-4.0/debian/patches/series
--- hamlib-4.0/debian/patches/series2021-05-11 10:03:12.0 -0700
+++ hamlib-4.0/debian/patches/series2021-07-15 21:31:14.0 -0700
@@ -7,3 +7,4 @@
 cf858bfa3c8a36eda749c5078ef6f53a119fb285
 0089964af7fa1f43757083b7bc7db195ba382fe0
 1d74711a00dfa416a171cec87c841db315c5d9f7
+31dedcf4f79d8fc5fcf287360e5d017842c8e4c0
[The following lists of changes regard files as different if they have
different names, permissions or owners.]

Files in second .changes but not in first
-
-rw-r--r--  root/root   
/usr/lib/debug/.build-id/37/f26c116c35dc6ce75eab34eec4e51ae09c1e0d.debug

Files in first .changes but not in second
-
-rw-r--r--  root/root   
/usr/lib/debug/.build-id/93/b3059fa0ecb4686b120e91e64e0a2b8e37100c.debug

Control files of package libhamlib++-dev: lines which differ (wdiff format)
---
Depends: libc6-dev, libhamlib++4 (= [-4.0-6),-] {+4.0-7),+} libhamlib-dev (= 
[-4.0-6),-] {+4.0-7),+} libhamlib4 (= [-4.0-6)-] {+4.0-7)+}
Version: [-4.0-6-] {+4.0-7+}

Control files of package libhamlib++4: lines which differ (wdiff format)

Version: [-4.0-6-] {+4.0-7+}

Control files of package libhamlib++4-dbgsym: lines which differ (wdiff format)
---
Depends: libhamlib++4 (= [-4.0-6)-] {+4.0-7)+}
Version: [-4.0-6-] {+4.0-7+}

Control files of package libhamlib-dev: lines which differ (wdiff format)
-
Depends: libc6-dev, libhamlib4 (= [-4.0-6),-] {+4.0-7),+} libusb-1.0-0-dev
Version: [-4.0-6-] {+4.0-7+}

Control files of package libhamlib-doc: lines which differ (wdiff format)

Bug#991169: llvm-nm: --demangle does not work with versioned symbols

[Sylvestre Ledru]

Le 16/07/2021 à 16:22, Steffen Weinhart a écrit :
> Hi,
>
> Sylvestre Ledru wrote:
>> Do you know if this is an upstream limitation or a packaging issue?
>>
>
> after a short look through LLVM's bugzilla (and not knowing how or
> where to scan their commitlog) 
it is available here: https://github.com/llvm/llvm-project
> I would say that the problem exists upstream, too, but I'm not sure.
>
maybe report a bug upstream. I won't fix it if it is lacking upstream ;)

S

Bug#991178: installation-reports

[Peter Ehlert]

Package: installation-reports

Boot method: USB stick
Image version: 
https://cdimage.debian.org/images/unofficial/non-free/images-including-firmware/bullseye_di_rc2+nonfree/amd64/iso-cd/firmware-bullseye-DI-rc2-amd64-netinst.iso


Date: 15 Jul 2021 02:00 PM PDT

Machine:
Type: Laptop System: Hewlett-Packard product: HP EliteBook 820 G2
  v: A3009DD18303 serial: 
  Mobo: Hewlett-Packard model: 225A v: KBC Version 96.58
  serial:  BIOS: Hewlett-Packard v: M71 Ver. 01.12
  date: 11/05/2015

Processor:
CPU:
  Info: Dual Core model: Intel Core i7-5600U bits: 64 type: MT MCP
  L2 cache: 4 MiB
  Speed: 1843 MHz min/max: 500/3200 MHz Core speeds (MHz): 1: 1843 2: 1828
  3: 2018 4: 1812

Memory: 15.51 GiB

Network:
  Device-1: Intel Ethernet I218-LM driver: e1000e
  IF: enp0s25 state: down mac: b0:5a:da:b2:fe:82
  Device-2: Intel Wireless 7265 driver: iwlwifi
  IF: wlo1 state: up mac: 94:65:9c:b4:2a:35

Partitions: 

peter@g2i7d11:~$ df -Tl
df: /run/user/1000/doc: Operation not permitted
Filesystem Type 1K-blocks  Used Available Use% Mounted on
udev   devtmpfs   8109536 0   8109536   0% /dev
tmpfs  tmpfs  1626488  1556   1624932   1% /run
/dev/sda3  ext4  28660644   6472160  20707268  24% /
tmpfs  tmpfs  8132436 59488   8072948   1% /dev/shm
tmpfs  tmpfs 5120 4  5116   1% /run/lock
/dev/sda10 ext4 180377912 151667812  19477716  89% 
/media/Pictures.compile

/dev/sda4  ext4  81600856  61140388  16687828  79% /home
/dev/sda8  ext4 422805976 293374432 111474524  73% /media/backup
/dev/sdb9  ext4  20027260   9989732   8997144  53% 
/media/music.share

/dev/sda9  ext4 134014192  61981980  65589924  49% /media/backup.acc
/dev/sdb8  ext4 347473316 244465636  85793392  75% /media/syncspace
tmpfs  tmpfs  1626484   104   1626380   1% /run/user/1000
peter@g2i7d11:~$


Output of lspci -knn (or lspci -nn):

peter@g2i7d11:~$ lspci -knn
00:00.0 Host bridge [0600]: Intel Corporation Broadwell-U Host Bridge 
-OPI [8086:1604] (rev 09)
    Subsystem: Hewlett-Packard Company Broadwell-U Host Bridge -OPI 
[103c:225a]

    Kernel driver in use: bdw_uncore
00:02.0 VGA compatible controller [0300]: Intel Corporation HD Graphics 
5500 [8086:1616] (rev 09)

    DeviceName: 32
    Subsystem: Hewlett-Packard Company HD Graphics 5500 [103c:225a]
    Kernel driver in use: i915
    Kernel modules: i915
00:03.0 Audio device [0403]: Intel Corporation Broadwell-U Audio 
Controller [8086:160c] (rev 09)
    Subsystem: Hewlett-Packard Company Broadwell-U Audio Controller 
[103c:225a]

    Kernel driver in use: snd_hda_intel
    Kernel modules: snd_hda_intel
00:14.0 USB controller [0c03]: Intel Corporation Wildcat Point-LP USB 
xHCI Controller [8086:9cb1] (rev 03)
    Subsystem: Hewlett-Packard Company Wildcat Point-LP USB xHCI 
Controller [103c:225a]

    Kernel driver in use: xhci_hcd
    Kernel modules: xhci_pci
00:16.0 Communication controller [0780]: Intel Corporation Wildcat 
Point-LP MEI Controller #1 [8086:9cba] (rev 03)
    Subsystem: Hewlett-Packard Company Wildcat Point-LP MEI Controller 
[103c:225a]

    Kernel driver in use: mei_me
    Kernel modules: mei_me
00:19.0 Ethernet controller [0200]: Intel Corporation Ethernet 
Connection (3) I218-LM [8086:15a2] (rev 03)
    Subsystem: Hewlett-Packard Company Ethernet Connection (3) I218-LM 
[103c:225a]

    Kernel driver in use: e1000e
    Kernel modules: e1000e
00:1b.0 Audio device [0403]: Intel Corporation Wildcat Point-LP High 
Definition Audio Controller [8086:9ca0] (rev 03)
    Subsystem: Hewlett-Packard Company Wildcat Point-LP High Definition 
Audio Controller [103c:225a]

    Kernel driver in use: snd_hda_intel
    Kernel modules: snd_hda_intel
00:1c.0 PCI bridge [0604]: Intel Corporation Wildcat Point-LP PCI 
Express Root Port #1 [8086:9c90] (rev e3)

    Kernel driver in use: pcieport
00:1c.1 PCI bridge [0604]: Intel Corporation Wildcat Point-LP PCI 
Express Root Port #2 [8086:9c92] (rev e3)

    Kernel driver in use: pcieport
00:1c.3 PCI bridge [0604]: Intel Corporation Wildcat Point-LP PCI 
Express Root Port #4 [8086:9c96] (rev e3)

    Kernel driver in use: pcieport
00:1d.0 USB controller [0c03]: Intel Corporation Wildcat Point-LP USB 
EHCI Controller [8086:9ca6] (rev 03)
    Subsystem: Hewlett-Packard Company Wildcat Point-LP USB EHCI 
Controller [103c:225a]

    Kernel driver in use: ehci-pci
    Kernel modules: ehci_pci
00:1f.0 ISA bridge [0601]: Intel Corporation Wildcat Point-LP LPC 
Controller [8086:9cc3] (rev 03)
    Subsystem: Hewlett-Packard Company Wildcat Point-LP LPC Controller 
[103c:225a]

    Kernel driver in use: lpc_ich
    Kernel modules: lpc_ich
00:1f.2 SATA controller [0106]: Intel Corporation Wildcat Point-LP SATA 
Controller [AHCI Mode] [8086:9c83] (rev 03)
    Subsystem: Hewlett-Packard Company Wildcat Point-LP SATA Controller 
[AHCI Mode] [103c:225a]

    Kernel driver in use: ahci
    Kernel 

Bug#991169: llvm-nm: --demangle does not work with versioned symbols

[Steffen Weinhart]

Hi,

Sylvestre Ledru wrote:

Do you know if this is an upstream limitation or a packaging issue?



after a short look through LLVM's bugzilla (and not knowing how or where 
to scan their commitlog) I would say that the problem exists upstream, 
too, but I'm not sure.

Bug#783990: efivarfs is a separate fs and needs moutning

[Ian Jackson]

Control: tags -1 patch

Thorsten Glaser writes ("Re: Bug#783990: efivarfs is a separate fs and needs 
moutning"):
> This is not as easy as it sounds:
> 
> tglase@tglase-nb:~ $ sudo mount -t efivarfs efivarfs /sys/firmware/efi/efivars
> mount: /sys/firmware/efi/efivars: mount point does not exist.
> 32|tglase@tglase-nb:~ $ sudo mkdir -p /sys/firmware/efi/efivars
> mkdir: cannot create directory ‘/sys/firmware/efi’: Operation not permitted
> 
> This is on amd64 without EFI (classical BIOS, no CSM).

Oh.

I guess this should be done if /sys/firmware/efi/efivars exists, then.

Can you confirm that that directory doesn't exist for you ?

Ian.

-- 
Ian JacksonThese opinions are my own.  

Pronouns: they/he.  If I emailed you from @fyvzl.net or @evade.org.uk,
that is a private address which bypasses my fierce spamfilter.

Bug#990782: inkscape: /usr/share/inkscape/fonts does not exist

[Mattia Rizzolo]

Control: severity -1 minor
Control: tag -1 confirmed upstream

On Wed, Jul 07, 2021 at 11:45:09AM +0200, Hendrik Tews wrote:
> each time I start inkscape, it complains
> 
>** (org.inkscape.Inkscape:44746): WARNING **: 11:29:57.779: Fonts dir 
> '/usr/share/inkscape/fonts' does not exist and will be ignored.
> 
>** (org.inkscape.Inkscape:44746): WARNING **: 11:29:57.779: Fonts dir 
> '/home/tews/.config/inkscape/fonts' does not exist and will be ignored.
> 
> It is possible to get rid of these warnings by just creating
> these directories. But if inkscape expects these directories, the
> package or inkscape should create them, shouldn't they?

I wouldn't say that inkscape "expects" them.
It's just looking to see if they exist in case the user wants to use
some inkscape-specific fonts.

That said, I'll ask upstream what they think about toning down the lines
at DEBUG level, so they don't show up by default.  Or at least INFO,
those warnings are overrated imho.

-- 
regards,
Mattia Rizzolo

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


signature.asc
Description: PGP signature

Bug#991015: Acknowledgement (cannot execute due to incorrect shebang line)

[Antonio Terceiro]

On Tue, Jul 13, 2021 at 12:48:49PM +0300, Adrian Bunk wrote:
> On Mon, Jul 12, 2021 at 09:10:15PM -0400, Ryan Kavanagh wrote:
> > This bug seems to be, in part, due to a potentially (?) broken ruby
> > upgrade behaviour. I've been running unstable on this laptop for ~6
> > years, but still had
> > 
> > ii  ruby2.1 [ruby-interpreter]  2.1.5-4
> > ii  ruby2.2 [ruby-interpreter]  2.2.4-1
> > 
> > installed as my only ruby interpreters. These are no longer available in
> > unstable, and ruby2.1 was last available in:
> > 
> > ruby2.1| 2.1.5-2+deb8u3 | oldoldstable | source, amd64, armel, armhf, 
> > i386
> > 
> > Will users upgrading from buster to bullseye will encounter a similar
> > issue if they've dist-upgraded from jessie to stretch to buster?
>
> The problem is the following in the dependencies:
>   Depends: ruby | ruby-interpreter, ...
> 
> The /usr/bin/ruby symlink is in the ruby package,
> the alternative dependency ruby-interpreter is
> therefore wrong.

We noticed that a while ago, and ruby2.2 was the last of the rubyX.Y
packages to actually provide `ruby-interpreter`.

At this point, there are 900+ packages that still depend on `ruby |
ruby-interpreter`, so this isn't something we can easily fix. I will
submit a lintian check for this to get eventually fixed, but it will
take a while.

To workaround this, please install `ruby` and remove `ruby2.1`. and
`ruby2.2`.


signature.asc
Description: PGP signature

Bug#991177: libdebian-installer: reproducible builds: Embeds build path in libdebian-installer-extra.so.*

[Vagrant Cascadian]

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

The build path is embedded in various places in
libdebian-installer-extra.so.*:

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

  ./usr/lib/x86_64-linux-gnu/libdebian-installer-extra.so.4.0.8 

  /build/1st/libdebian-installer-0.121/build/src/../../src/list.c:30
  vs.
  /build/2/libdebian-installer-0.121/2nd/build/src/../../src/list.c:30

The attached patch fixes this by passing -ffile-prefix-map to CFLAGS in
debian/rules.

Alternately, with recent versions of dpkg, using dpkg-buildflags to set
CFLAGS should pass this option by default.


Thanks for maintaining libdebian-installer!


live well,
  vagrant
From 5222acd3ccb659da12cb877398375ceab2a44388 Mon Sep 17 00:00:00 2001
From: Vagrant Cascadian 
Date: Fri, 16 Jul 2021 13:59:17 +
Subject: [PATCH] debian/rules: Add -ffile-prefix-map to CFLAGS.

This avoids embedding the build path in the resulting binaries and
debug symbols.

https://reproducible-builds.org/docs/build-path/
---
 debian/rules | 4 
 1 file changed, 4 insertions(+)

diff --git a/debian/rules b/debian/rules
index 7307a7b..0f394c2 100755
--- a/debian/rules
+++ b/debian/rules
@@ -8,6 +8,10 @@ DEB_HOST_ARCH_OS:= $(shell dpkg-architecture -qDEB_HOST_ARCH_OS 2>/dev/null)
 #CFLAGS = -Wall -W -Werror -ggdb -Wstrict-prototypes -Wmissing-declarations -Wmissing-prototypes
 CFLAGS = -Wall -W -ggdb -Wmissing-declarations
 
+# Avoid embedding build paths in the binaries
+# https://reproducible-builds.org/docs/build-path/
+CFLAGS += -ffile-prefix-map=$(CURDIR)=.
+
 ifneq (,$(findstring noopt,$(DEB_BUILD_OPTIONS)))
 	CFLAGS += -O0
 else
-- 
2.32.0



signature.asc
Description: PGP signature

Bug#991169: llvm-nm: --demangle does not work with versioned symbols

[Sylvestre Ledru]

Hello,

Le 16/07/2021 à 13:34, Steffen Weinhart a écrit :
> Package: llvm-12
> X-Debbugs-Cc: stw...@blue-cable.de
> Version: 1:12.0.1-1
> Severity: normal
> File: /usr/bin/llvm-nm-12
>
> Dear Maintainer,
>
> the --demangle option of llvm-nm has no effect on symbols that are
> versioned.
> It seems like the program tries to demangle the already versioned
> symbol name (including the appended @).
> For an example, just compare the output of "llvm-nm -DC libstdc++.so"
> vs. "nm -DC libstdc++.so".
>
>
Do you know if this is an upstream limitation or a packaging issue?

Thanks
S

Bug#783990: efivarfs is a separate fs and needs moutning

[Thorsten Glaser]

On Fri, 16 Jul 2021, Ian Jackson wrote:

> but the suggestion by Greg Pearson is correct and IMO should be
> applied to mountkernfs.

This is not as easy as it sounds:

tglase@tglase-nb:~ $ sudo mount -t efivarfs efivarfs /sys/firmware/efi/efivars
mount: /sys/firmware/efi/efivars: mount point does not exist.
32|tglase@tglase-nb:~ $ sudo mkdir -p /sys/firmware/efi/efivars
mkdir: cannot create directory ‘/sys/firmware/efi’: Operation not permitted

This is on amd64 without EFI (classical BIOS, no CSM).

Nōn-{x86,ARM} systems will likely have the same. Don’t break them.

Meow,
//mirabilos
-- 
Infrastrukturexperte • tarent solutions GmbH
Am Dickobskreuz 10, D-53121 Bonn • http://www.tarent.de/
Telephon +49 228 54881-393 • Fax: +49 228 54881-235
HRB AG Bonn 5168 • USt-ID (VAT): DE122264941
Geschäftsführer: Dr. Stefan Barth, Kai Ebenrett, Boris Esser, Alexander Steeg

*

Mit dem tarent-Newsletter nichts mehr verpassen: www.tarent.de/newsletter

*

Bug#990631: thunderbird: Preferences tab is completely blank after the upgrade to 90b2

[jim_p]

Package: thunderbird
Version: 1:90.0~b2-1
Followup-For: Bug #990631
X-Debbugs-Cc: pitsior...@gmail.com

Any chance of fixing this? I found the reason for the egl errors (it's
webrender that is being forced by default). But there is no way to access
about:config and disable it, because it has to be opened through
about:preferences.

I tried disabling it by creating a user.js file and setting the preference in
there manually, but I had no luck. Then I learned about prefs.js, so I made a
file, added the preference there too and it messed up my tb! So now I am
setting it up from scratch.

Sadly, some settings, e.g. font size and time before rss entries are deleted
etc that interest me, can only be set by about:preferences.

Bug#990913: ausweisapp2: creates config in '~/.config/Unknown Organization'

[A. Klitzing]

Hi there,

thanks for the report.

The problem here is that strange Qt API for default pathes.
Previously we added "AusweisApp2_CE" as VENDOR / Organization [1]. So
Qt appends the organization and searches our configuation in
"/usr/share/VENDOR/AusweisApp2 [2].
As this isn't the default on unix/linux to have the organization
appended we removed VENDOR. But this now leads to this problem because
QSettings [3] uses QStandardPats [4] and tries to detect the
organization.
See old Debian patch: 0001-Disable-vendor-name.patch

Of course, we could customize our own code to work-around that. But I
still see that it is a bug in Qt. Qt uses wrong defaults for
unix/linux environment.

[1] https://doc.qt.io/qt-5/qcoreapplication.html#organizationName-prop
[2] 
https://code.qt.io/cgit/qt/qtbase.git/tree/src/corelib/io/qstandardpaths_unix.cpp#n223
[3] https://doc.qt.io/qt-5/qsettings.html#QSettings-1
[4] https://doc.qt.io/qt-5/qstandardpaths.html

Best regards
  André Klitzing

Bug#991175: kdump-tools: /var/lib/kdump is missing

[Benjamin Drung]

Package: kdump-tools
Version: 1:1.6.8.3
Severity: important
Tags: patch

Hi,

When building an image with debootstrap and using chroot to install
kdump-tools, no initrd will be generated on installation (and no
/var/lib/kdump directory will be created). The first boot will causes
error messages:

```
Creating symlink /var/lib/kdump/vmlinuz.
ln: failed to create symbolic link '/var/lib/kdump/vmlinuz': No such file or 
directory
```

The same happens if `kdump-config symlinks $kver` is called the first
time.

https://salsa.debian.org/debian/kdump-tools/-/merge_requests/8 will
address it.

-- 
Benjamin Drung

Senior DevOps Engineer and Debian & Ubuntu Developer
Compute Platform Operations

1&1 IONOS SE | Greifswalder Str. 207 | 10405 Berlin | Deutschland
E-Mail: benjamin.dr...@ionos.com | Web: www.ionos.de

Hauptsitz Montabaur, Amtsgericht Montabaur, HRB 24498

Vorstand: Hüseyin Dogan, Dr. Martin Endreß, Claudia Frese, Henning
Kettler, Arthur Mai, Matthias Steinberg, Achim Weiß
Aufsichtsratsvorsitzender: Markus Kadelke


Member of United Internet

Bug#991174: autopkgtest: pkispawn should specify `isolation-container` in d/tests/control

[Paride Legovini]

Source: dogtag-pki
Version: autopkgtest: pkispawn should specify `isolation-container` in 
d/tests/control
Severity: normal
X-Debbugs-Cc: par...@debian.org

Hi,

The `pkispawn` autopkgtest needs to open a TCP port. This fails in
simple chroot/schroot environments. The d/tests/control file should
specify `isolation-container` to the test is skipped when not running in
its own container/VM. For reference see:

https://people.debian.org/~mpitt/autopkgtest/README.package-tests.html

from which part of the above is copy/pasted :-)

Paride

Bug#991170: Transport

[Ondřej Holas]

Important thing to note - the problem applies to stream transports - TCP and
TLS. In the steps to reproduce, the first one should be:


- set up Linphone for Android to register with Asterisk USING TCP OR 
TLSOndrej

Bug#991173: autopkgtest: missing test dependency: iproute2

[Paride Legovini]

Source: dogtag-pki
Version: autopkgtest: missing test dependency: iproute2
Severity: normal
X-Debbugs-Cc: par...@debian.org

Hi,

While running the dogtag-pki autopkgtests using a very minimal testbed
images I encountered test failures due to `ip` being missing. See
d/tests/pkispawn:

  IP=`ip route get 1.1.1.1 | sed -n -e's/.*src //; s/ .*//; p; q'`

This is solved by adding a test dependency on `iproute2`.

Paride

Bug#990119: vip-manager: systemd service file uses incorrect parameter syntax

[Michael Banck]

Hi,

Am Montag, den 21.06.2021, 11:12 +0200 schrieb Chris Hofstaedtler:
> Package: vip-manager
> Version: 1.0.1-3+b2
> Severity: serious
> 
> Dear Maintainer,
> 
> thanks for maintaining the vip-manager package.
> 
> I've noticed that the service file
> /lib/systemd/system/vip-manager.service uses options with one dash
> (ex: `-ip=a.b.c.d`), but the vip-manager binary expects two dashes
> (`--ip=a.b.c.d`).
> 
> I believe old vip-manager versions used one dash, but apparently
> this has changed, and the Debian patch "service_file.patch" needs to
> be updated.

You're right. I only tested the Debian-integrated version of vip-manager 
where one uses the templated service unit that's corresponding to the
Patroni service/Debian PostgreSQL cluster (e.g. vip-manager@13-main) and
not the general one.

> Setting severity serious, because the default service file appears
> broken.

I've pushed a fix now according to your other mail. I first thought of
harmonizing the two service units some more (and just use environment
variables), but then decided to go for the minimal fix for bullseye.
I'll try to overhaul this for bookworm.

I also uploaded a new package candidate to
https://people.debian.org/~mbanck/.tmp/vip-manager_1.0.1-4_amd64.deb
if you want to test it. Or just build it yourself from the salsa repo.


Michael

-- 
Michael Banck
Projektleiter / Senior Berater
Tel.: +49 2166 9901-171
E-Mail: michael.ba...@credativ.de

credativ GmbH, HRB Mönchengladbach 12080
USt-ID-Nummer: DE204566209
Trompeterallee 108, 41189 Mönchengladbach
Geschäftsführung: Dr. Michael Meskes, Sascha Heuer, Geoff Richardson, Peter 
Lilley

Unser Umgang mit personenbezogenen Daten unterliegt
folgenden Bestimmungen: https://www.credativ.de/datenschutz

Bug#991172: installation-reports: MBR Partitioned USB drives cannot be found during UEFI installation

[Ruben Vorderman]

Package: installation-reports
Severity: important
Tags: d-i
X-Debbugs-Cc: rubenvorder...@xs4all.nl

Boot method: USB (FAT32 with image simply extracted)
Image version: https://cdimage.debian.org/cdimage/bullseye_di_rc2/amd64/iso-
cd/debian-bullseye-DI-rc2-amd64-netinst.iso
Date: July 5th

Machine: Lenovo Thinkpad T430
Partitions: 

Disk /dev/sda: 500GB
Sector size (logical/physical): 512B/4096B
Partition Table: gpt
Disk Flags:

Number  Start   End    Size    File system Name  Flags
 1  1049kB  269MB  268MB   fat32   EFI System Partition  
boot, esp

 2  269MB   108GB  107GB   ext4
 4  108GB   492GB  384GB   ext4
 3  492GB   500GB  8590MB linux-swap(v1)    swap


Base System Installation Checklist:
[O] = OK, [E] = Error (please elaborate below), [ ] = didn't try it

Initial boot:   [O]
Detect network card:    [O]
Configure network:  [O]
Detect media:   [E]
Load installer modules: [O]
Clock/timezone setup:   [O]
User/password setup:    [O]
Detect hard drives: [O]
Partition hard drives:  [O]
Install base system:    [O]
Install tasks:  [O]
Install boot loader:    [O]
Overall install:    [O]

Comments/Problems:

Simply extracting the ISO to a FAT32 partitioned USB stick and using UEFI
install by default always has been the easiest way to get a bootable USB 
stick

going. (I shun dd). The boot worked fine. But then it could not find the
install medium during the installation process. The usb device showed up as
/dev/sdb, but the partition /dev/sdb1 would not show up.

The solution was to use gparted to create a new GPT partition table on 
the USB

stick, add a FAT32 partition and extract the image to that. That solved the
problem. I was able to continue the installation after the detect-media 
stage.


Kind of strange that the Debian installer had issues recognizing the device
while the system BIOS had no problems recognising the MBR table + FAT 
partition

with UEFI image as bootable.

This was a very puzzling error. I happened to think of the solution by some
random chance within a day, but this easily could have had me puzzled for a
much longer time. That is why I filed it as "important".

The rest of the installation went smoothly. No complaints there. Thanks 
for all

the great work!


-- Package-specific info:

==
Installer lsb-release:
==
DISTRIB_ID=Debian
DISTRIB_DESCRIPTION="Debian GNU/Linux installer"
DISTRIB_RELEASE="11 (bullseye) - installer build 20210606"
X_INSTALLATION_MEDIUM=cdrom

==
Installer hardware-summary:
==
uname -a: Linux tuxpad 5.10.0-7-amd64 #1 SMP Debian 5.10.40-1 
(2021-05-28) x86_64 GNU/Linux
lspci -knn: 00:00.0 Host bridge [0600]: Intel Corporation 3rd Gen Core 
processor DRAM Controller [8086:0154] (rev 09)

lspci -knn:     Subsystem: Lenovo Device [17aa:21f3]
lspci -knn: 00:02.0 VGA compatible controller [0300]: Intel Corporation 
3rd Gen Core processor Graphics Controller [8086:0166] (rev 09)

lspci -knn:     Subsystem: Lenovo Device [17aa:21f3]
lspci -knn: 00:14.0 USB controller [0c03]: Intel Corporation 7 
Series/C210 Series Chipset Family USB xHCI Host Controller [8086:1e31] 
(rev 04)

lspci -knn:     Subsystem: Lenovo ThinkPad T430 [17aa:21f3]
lspci -knn:     Kernel driver in use: xhci_hcd
lspci -knn:     Kernel modules: xhci_pci
lspci -knn: 00:16.0 Communication controller [0780]: Intel Corporation 7 
Series/C216 Chipset Family MEI Controller #1 [8086:1e3a] (rev 04)

lspci -knn:     Subsystem: Lenovo Device [17aa:21f3]
lspci -knn: 00:19.0 Ethernet controller [0200]: Intel Corporation 
82579LM Gigabit Network Connection (Lewisville) [8086:1502] (rev 04)

lspci -knn:     Subsystem: Lenovo Device [17aa:21f3]
lspci -knn:     Kernel driver in use: e1000e
lspci -knn:     Kernel modules: e1000e
lspci -knn: 00:1a.0 USB controller [0c03]: Intel Corporation 7 
Series/C216 Chipset Family USB Enhanced Host Controller #2 [8086:1e2d] 
(rev 04)

lspci -knn:     Subsystem: Lenovo Device [17aa:21f3]
lspci -knn:     Kernel driver in use: ehci-pci
lspci -knn:     Kernel modules: ehci_pci
lspci -knn: 00:1b.0 Audio device [0403]: Intel Corporation 7 Series/C216 
Chipset Family High Definition Audio Controller [8086:1e20] (rev 04)

lspci -knn:     Subsystem: Lenovo Device [17aa:21f3]
lspci -knn:     Kernel driver in use: snd_hda_intel
lspci -knn:     Kernel modules: snd_hda_intel
lspci -knn: 00:1c.0 PCI bridge [0604]: Intel Corporation 7 Series/C216 
Chipset Family PCI Express Root Port 1 [8086:1e10] (rev c4)

lspci -knn:     Kernel driver in use: pcieport
lspci -knn: 00:1c.1 PCI bridge [0604]: Intel Corporation 7 Series/C210 
Series Chipset Family PCI Express Root Port 2 [8086:1e12] (rev c4)

lspci -knn:     Kernel driver in use: pcieport
lspci -knn: 00:1d.0 USB controller [0c03]: Intel Corporation 7 
Series/C216 Chipset 

Bug#991171: installation-reports: MBR Partitioned USB drives cannot be found during UEFI installation

[Ruben Vorderman]

Package: installation-reports
Severity: important
Tags: d-i
X-Debbugs-Cc: rubenvorder...@xs4all.nl

Boot method: USB (FAT32 with image simply extracted)
Image version: https://cdimage.debian.org/cdimage/bullseye_di_rc2/amd64/iso-
cd/debian-bullseye-DI-rc2-amd64-netinst.iso
Date: 

Machine: Lenovo Thinkpad T430
Partitions: 

Disk /dev/sda: 500GB
Sector size (logical/physical): 512B/4096B
Partition Table: gpt
Disk Flags:

Number  Start   EndSizeFile system Name  Flags
 1  1049kB  269MB  268MB   fat32   EFI System Partition  boot, esp
 2  269MB   108GB  107GB   ext4
 4  108GB   492GB  384GB   ext4
 3  492GB   500GB  8590MB  linux-swap(v1)swap


Base System Installation Checklist:
[O] = OK, [E] = Error (please elaborate below), [ ] = didn't try it

Initial boot:   [O]
Detect network card:[O]
Configure network:  [O]
Detect media:   [E]
Load installer modules: [O]
Clock/timezone setup:   [O]
User/password setup:[O]
Detect hard drives: [O]
Partition hard drives:  [O]
Install base system:[O]
Install tasks:  [O]
Install boot loader:[O]
Overall install:[O]

Comments/Problems:

Simply extracting the ISO to a FAT32 partitioned USB stick and using UEFI
install by default always has been the easiest way to get a bootable USB stick
going. (I shun dd). The boot worked fine. But then it could not find the
install medium during the installation process. The usb device showed up as
/dev/sdb, but the partition /dev/sdb1 would not show up.

The solution was to use gparted to create a new GPT partition table on the USB
stick, add a FAT32 partition and extract the image to that. That solved the
problem. I was able to continue the installation after the detect-media stage.

Kind of strange that the Debian installer had issues recognizing the device
while the system BIOS had no problems recognising the MBR table + FAT partition
with UEFI image as bootable.

This was a very puzzling error. I happened to think of the solution by some
random chance within a day, but this easily could have had me puzzled for a
much longer time. That is why I filed it as "important".

The rest of the installation went smoothly. No complaints there. Thanks for all
the great work!


-- Package-specific info:

==
Installer lsb-release:
==
DISTRIB_ID=Debian
DISTRIB_DESCRIPTION="Debian GNU/Linux installer"
DISTRIB_RELEASE="11 (bullseye) - installer build 20210606"
X_INSTALLATION_MEDIUM=cdrom

==
Installer hardware-summary:
==
uname -a: Linux tuxpad 5.10.0-7-amd64 #1 SMP Debian 5.10.40-1 (2021-05-28) 
x86_64 GNU/Linux
lspci -knn: 00:00.0 Host bridge [0600]: Intel Corporation 3rd Gen Core 
processor DRAM Controller [8086:0154] (rev 09)
lspci -knn: Subsystem: Lenovo Device [17aa:21f3]
lspci -knn: 00:02.0 VGA compatible controller [0300]: Intel Corporation 3rd Gen 
Core processor Graphics Controller [8086:0166] (rev 09)
lspci -knn: Subsystem: Lenovo Device [17aa:21f3]
lspci -knn: 00:14.0 USB controller [0c03]: Intel Corporation 7 Series/C210 
Series Chipset Family USB xHCI Host Controller [8086:1e31] (rev 04)
lspci -knn: Subsystem: Lenovo ThinkPad T430 [17aa:21f3]
lspci -knn: Kernel driver in use: xhci_hcd
lspci -knn: Kernel modules: xhci_pci
lspci -knn: 00:16.0 Communication controller [0780]: Intel Corporation 7 
Series/C216 Chipset Family MEI Controller #1 [8086:1e3a] (rev 04)
lspci -knn: Subsystem: Lenovo Device [17aa:21f3]
lspci -knn: 00:19.0 Ethernet controller [0200]: Intel Corporation 82579LM 
Gigabit Network Connection (Lewisville) [8086:1502] (rev 04)
lspci -knn: Subsystem: Lenovo Device [17aa:21f3]
lspci -knn: Kernel driver in use: e1000e
lspci -knn: Kernel modules: e1000e
lspci -knn: 00:1a.0 USB controller [0c03]: Intel Corporation 7 Series/C216 
Chipset Family USB Enhanced Host Controller #2 [8086:1e2d] (rev 04)
lspci -knn: Subsystem: Lenovo Device [17aa:21f3]
lspci -knn: Kernel driver in use: ehci-pci
lspci -knn: Kernel modules: ehci_pci
lspci -knn: 00:1b.0 Audio device [0403]: Intel Corporation 7 Series/C216 
Chipset Family High Definition Audio Controller [8086:1e20] (rev 04)
lspci -knn: Subsystem: Lenovo Device [17aa:21f3]
lspci -knn: Kernel driver in use: snd_hda_intel
lspci -knn: Kernel modules: snd_hda_intel
lspci -knn: 00:1c.0 PCI bridge [0604]: Intel Corporation 7 Series/C216 Chipset 
Family PCI Express Root Port 1 [8086:1e10] (rev c4)
lspci -knn: Kernel driver in use: pcieport
lspci -knn: 00:1c.1 PCI bridge [0604]: Intel Corporation 7 Series/C210 Series 
Chipset Family PCI Express Root Port 2 [8086:1e12] (rev c4)
lspci -knn: Kernel driver in use: pcieport
lspci -knn: 00:1d.0 USB controller [0c03]: Intel Corporation 7 Series/C216 
Chipset Family USB Enhanced Host 

Bug#991170: asterisk: chan_sip stream transport breaks after NUL characters in message body

[Ondřej Holas]

Package: asterisk
Version: 1:16.16.1~dfsg-1~bpo10+1
Severity: important
Tags: upstream

When chan_sip processes incoming SIP message and its body contains NUL
characters (for example due to deflate encoding), reading body from buffer
stops at the NUL character, thus ignoring the rest of the buffer and waiting
for additional incoming data to catch up all data of size indicated in
the Content-Length header. Effectively this behavior causes breakup of
SIP communication - ignoring subsequent messages and returning errors
"method not implemented".

Steps to reproduce:

- set up Linhone for Android to register with Asterisk
- in rasterisk, turn on debugging for the new peer: "sip set debug peer 
"
- in Linphone's settings, turn on Settings/Contacts/Friendlist subscribe
- in rasterisk, wait for the SUBSCRIBE message with deflated body
- in Linphone, try to place a call
- the INVITE message is not processed as chan_sip believes to be
continuation
  of body belonging to the preceding SUBSCRIBE message

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

Kernel: Linux 5.10.0-0.bpo.7-amd64 (SMP w/1 CPU core)
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)
LSM: AppArmor: enabled

Versions of packages asterisk depends on:
ii  adduser  3.118
ii  asterisk-config  1:16.16.1~dfsg-1~bpo10+1
ii  asterisk-core-sounds-en  1.6.1-1
ii  asterisk-modules 1:16.16.1~dfsg-1~bpo10+1
ii  libc6    2.28-10
ii  libcap2  1:2.25-2
ii  libedit2 3.1-20181209-1
ii  libjansson4  2.12-1
ii  libpopt0 1.16-12
ii  libsqlite3-0 3.27.2-3+deb10u1
ii  libssl1.1    1.1.1d-0+deb10u6
ii  libsystemd0  241-7~deb10u7
ii  liburiparser1    0.9.1-1
ii  libuuid1 2.33.1-0.1
ii  libxml2  2.9.4+dfsg1-7+deb10u2
ii  libxslt1.1   1.1.32-2.2~deb10u1
ii  lsb-base 10.2019051400

Versions of packages asterisk recommends:
ii  asterisk-moh-opsound-gsm 2.03-1
pn  asterisk-voicemail | asterisk-voicemail-storage  
pn  sox  

Versions of packages asterisk suggests:
pn  asterisk-dahdi   
pn  asterisk-dev 
pn  asterisk-doc 
pn  asterisk-ooh323  
pn  asterisk-opus    
pn  asterisk-vpb 

-- Configuration Files:
/etc/logrotate.d/asterisk changed [not included]

-- no debconf information

Bug#990869: Revision on Archive-architecture

[Peter Palfrader]

On Sat, 10 Jul 2021, Seksi Jaringan DSI Universitas Airlangga wrote:

> Site: mirror.unair.ac.id

Added, thanks.

Please note that we recommend mirrors not sync directly from service
aliases such as ftp..debian.org (only http is guaranteed to be
available at ftp..d.o sites).  Maybe change your config to sync from
the site currently backing the ftp..debian.org service you sync
from?
-- 
|  .''`.   ** Debian **
  Peter Palfrader   | : :' :  The  universal
 https://www.palfrader.org/ | `. `'  Operating System
|   `-https://www.debian.org/

Bug#783990: efivarfs is a separate fs and needs moutning

[Ian Jackson]

Control: tags -1 - moreinfo
Control: tags -1 + confirmed patch
Control: found -1 2.93-8
Control: found -1 2.96-7

I just encountered the lack of evivars when using fwupd to update my
laptop firmware from lvfs.

My workaround was to put this in /etc/fstab
 efivarfs/sys/firmware/efi/efivars   efivarfs   defaults

but the suggestion by Greg Pearson is correct and IMO should be
applied to mountkernfs.  (I felt that Greg's descriptiohn was
sufficientlty clear to be worth calling a "patch".)

Dmitry wrote:

> Hi. As I see on my system, /sys/firmware/efi is now part of /sys:
> 
>  $ ls /sys/firmware/efi/
>  config_table
...
>  $ mount | grep efi
>  /dev/sda1 on /boot/efi type vfat (

But, the relevant directory is /sys/firmware/efi/efivars. not
/sys/firmware/efi.  The fact that efivars exists in /sys/firmware/efi
doesn't tell us that the contents is available.

Empirically on this buster system, I needed to manually arrange for
the mounting of /sys/firmware/efi/efivars to get fwupd to work.

Steve McIntyre confirmed to me on irc that this is a separate
filesystem on bullseye too.  I looked at the source for sid's sysvinit
and its mountkernfs still lacks this.

I think it would be worth considering this fix for a stable update,
after bullseye is released.

Thanks,
Ian.

-- 
Ian JacksonThese opinions are my own.  

Pronouns: they/he.  If I emailed you from @fyvzl.net or @evade.org.uk,
that is a private address which bypasses my fierce spamfilter.

Bug#991169: llvm-nm: --demangle does not work with versioned symbols

[Steffen Weinhart]

Package: llvm-12
X-Debbugs-Cc: stw...@blue-cable.de
Version: 1:12.0.1-1
Severity: normal
File: /usr/bin/llvm-nm-12

Dear Maintainer,

the --demangle option of llvm-nm has no effect on symbols that are 
versioned.
It seems like the program tries to demangle the already versioned symbol 
name (including the appended @).
For an example, just compare the output of "llvm-nm -DC libstdc++.so" 
vs. "nm -DC libstdc++.so".



-- System Information:
Debian Release: 11.0
  APT prefers testing
  APT policy: (990, 'testing'), (500, 'testing-security'), (500, 
'stable-updates'), (500, 'proposed-updates'), (500, 'unstable'), (500, 
'stable'), (1,'experimental')

Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.13.1 (SMP w/8 CPU threads; PREEMPT)
Kernel taint flags: TAINT_CPU_OUT_OF_SPEC
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), LANGUAGE=de
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages llvm-12 depends on:
ii  libc6 2.31-12
ii  libgcc-s1 11.1.0-1
ii  libllvm12 1:12.0.1-1
ii  libpfm4   4.11.1+git32-gd0b85fb-1
ii  libstdc++6    11.1.0-1
ii  libtinfo6 6.2+20201114-2
ii  libz3-4   4.8.10-1
ii  llvm-12-linker-tools  1:12.0.1-1
ii  llvm-12-runtime   1:12.0.1-1
ii  zlib1g    1:1.2.11.dfsg-2

Versions of packages llvm-12 recommends:
ii  llvm-12-dev  1:12.0.1-1

Versions of packages llvm-12 suggests:
ii  llvm-12-doc  1:12.0.1-1

Bug#990368: Regarding SuperTuxKart in Debian main

[Markus Koschany]

Hello,

we have a dedicated bug report for this problem, please keep
990...@bugs.debian.org in CC.


Am Freitag, dem 16.07.2021 um 14:34 +1000 schrieb GumballForAPenny:
> Hi all,
> 
> (I am a user and contributor of SuperTuxKart, not any staff member of 
> the project.)
> 
> It has recently come to our attention that SuperTuxKart is not FOSS, due 
> to inclusion of non-free mascots such as the BSD Daemon and Hexley, alog 
> with other minor issues.
> 
> To my understanding, all the code (stk-code) is valid FOSS, only few 
> official data assets are not. An STK Moderator 'benau' correctly claims 
> the game is never advertised as 'free' by the project, so at this point 
> in time it appears to me as if there will be no intent of removing or 
> replacing the infringing characters from the main data assets repo.
> 


> What would be the best way for Debian package management to handle the 
> supertuxkart* packages? The game can run without non-free assets.

The correct way would be to ask the copyright holders of said mascots to give
their permission to use them in supertuxkart freely. Apparently the
supertuxkart mascots are a derivative work but the BSD logos are copyright
protected to prevent other companies from misusing them. Debian can't "fix"
that problem, the upstream developers must contact the original copyright
holders and find a solution with them.

In the short term we could just replace the mascots with either a placeholder
image in the same size or we use an already existing mascot to replace them. A
skilled graphic designer could repaint one of the existing mascots in red, make
small adjustment to their facial expression or even create a completely new
daemon model. It just should not look like the original BSD daemon.

https://tracker.debian.org/media/packages/s/supertuxkart/copyright-1.2ds-2

The next step is to identify the correct licenses for all paragraphs in
debian/copyright marked with ???. It appears to me those files were either
created automatically and should be under the same license as supertuxkart
itself or they are also licensed under the CC license which covers most of the
artwork. Here I would appreciate it if someone could ask upstream for a
clarification and then we could update debian/copyright accordingly. In the
worst case we would remove those images as well and try to replace them.

Just moving supertuxkart to non-free would be incorrect because if those ???
files are not covered by any license, then we are not allowed to redistribute
them at all.

In short: Right now we need someone who replaces the non-free mascots with free
ones and who identifies the correct license terms for all those ??? files.

We are short of time though because we are already in full freeze for Debian
11. If this problem can't be fixed quickly then supertuxkart must be removed
from testing and it will not be part of Debian 11.


Regards,

Markus






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

Bug#961142: snapshot.debian.org: python3 migration

[Baptiste BEAUPLAT]

Hi,

After a couple of month, the migration from python 2 and pylons to
python3 and flask is finally done. I've created a merge request
available at:

https://salsa.debian.org/snapshot-team/snapshot/-/merge_requests/1

The following describe what changed in snapshot:

Snapshot script
===

Ruby 'dbi' driver has been replaced by 'pg' ('dbi' was removed from
unstable in 2016). Main differences between both driver are:

- 'pg' require use of positional arguments
- renamed function/attributes (do/exec, ntuples and cmd_tuples)

I've tested the script both manually and using the frontend test suite.

Snapshot configuration
==

Since ruby 'pg' module understand connection string, I've removed
the duplicated yaml block information.

DB python upgrade scripts
=

In addition to being converted to python 3, I've updated the scripts so
they can be run either as a standalone script or imported from another
python application. This allow running upgrade scripts from the frontend
test suite, when provisionning the test database.

Other python scripts (frontend excluded)


I've updated all other python scripts that appeared releavent to me,
including scripts in the following directories

- fsck/
- master/
- mirror/
- fuse/

In fsck, I've also updated the C module to python 3.

Without doing extensive and exhaustive testing, I did run the script to
validate they primary use cases.

Dependencies


I've updated the dependency list in README.md to match bullseye package
versions (For fuse, ruby, scripts, frontend and fsck).

Frontend


Framework and layout


I've used the Flask framework to implement the frontend. That's a
minimalist framework, more simple and without any defined pattern, as
opposed to bigger framework such as Django.

It's a good fit in snapshot case because the backend is not in the
traditionnal form of a "Model", using a proper ORM, but instead is
already optimized, specific and implemented using PostgreSQL (psycopg2).

Flask provides all necessary tools to build around snapshot existing
model implementation, adding the frontend logic and the templates pages.

The following directories exposes the layout used for the frontend:

- `docs/`, deployment documentation and file header
- `public/`, root web folder
- `snapshot/__init__.py` `wgsi.py`, entry point
- `snapshot/views/`, frontend logic, contains all routes
- `snapshot/controllers/`, intermediary code, between views and models
- `snapshot/models/`, snapshot psycopg2 model
- `snapshot/settings/`, application configuration
- `snapshot/templates/`, jinja2 templates
- `snapshot/static/`, static content
- `snapshot/lib/`, generic code
- `tests/conftest.py`, test entry point
- `tests/controllers/`, test controllers
- `tests/data/`, test static data (package template, keyring, dataset)
- `tests/unit/`, unit and api tests
- `tests/functional/`, user/tools oriented tests (apt, debsnap)

Additionally, the frontend root folder contains licensing,
documentation, packaging and testing files.

Settings


Snapshot frontend settings are loaded from
`snapshot/settings/snapshot.py`. This file does not exist in the
repository and is intended to be a link to whatever environment
configuration file you choose (`develop.py` or `prod.py`).

All environment configuration files load `common.py` where all defaults
are defined, and overrides them when necessary.

Behavior changes


My goal for this migration is to provide a seamless transition for
snapshot users. Meaning I've re-implemented as close as I can the
behavior of the old frontend.

Generated html/json, minus the space indentation, should be identical to the
previous version.

Exception from a couple of minors bugs fixed, I'm not aware of any
behavior changes from the previous version.

Testing and QA
--

I've added a fairly big test suite to ensure that the rewrite does not
comes with any regression. The test suite is written using pytest and
provide almost a full coverage of the code (grep `pragma` to see
excluded code and why).

The test suite is working as described:

- Load testing settings from `snapshot/settings/test.py`
- Create a temporary PostgreSQL database (ASCII encoded)
- Import snapshot schema (using db/ files)
- Build testing packages and create pooled archived using data from
  `tests/data/dataset.py` and `tests/data/templates` (aptly is used to
  create the archives)
- Import and index the archives using the snapshot script

Once all those step are done, a snapshot of the database is made and
restored before each test.

Unit and functional tests are run. Unit tests covers all routes while
functional tests aims to cover user use cases (using snapshot with apt
or debsnap).

Additionally, a flake8 checker is run and a branch coverage report is
generated in web/app/htmlcov/.

The test suite is either run by:

- invoking the `tox` 

Bug#988618: unblock: kodi-pvr-iptvsimple/7.6.5+ds1-1

[Vasyl Gello]

Control: close -1

Closing this as there is no hope for positive outcome.
-- 
Vasyl Gello
==
Certified SolidWorks Expert

Mob.:+380 (98) 465 66 77

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

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

Bug#991166: ftpsync: Contents* and dep11/* metadata are incorrectly updated in stage1

[Raphael Hertzog]

Control: tags -1 + patch

I have prepared a MR for this:
https://salsa.debian.org/mirror-team/archvsync/-/merge_requests/2

Changes are trivial but they are currently untested.

Cheers,
-- 
Raphaël Hertzog ◈ Offensive Security ◈ Kali Linux Developer

Bug#991168: cconv FTCBFS: does not pass --host to configure

[Helmut Grohne]

Source: cconv
Version: 0.6.2-1.1
Tags: patch
User: debian-cr...@lists.debian.org
Usertags: ftcbfs

cconv fails to cross build from source, because it does not pass --host
to configure. The easiest way of doing so - using dh_auto_configure -
makes cconv cross buildable. Please consider applying the attached
patch.

Helmut
diff -u cconv-0.6.2/debian/changelog cconv-0.6.2/debian/changelog
--- cconv-0.6.2/debian/changelog
+++ cconv-0.6.2/debian/changelog
@@ -1,3 +1,10 @@
+cconv (0.6.2-1.2) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix FTCBFS: Let dh_auto_configure pass --host to configure. (Closes: #-1)
+
+ -- Helmut Grohne   Fri, 16 Jul 2021 09:19:05 +0200
+
 cconv (0.6.2-1.1) unstable; urgency=medium
 
   [ Aurelien Jarno
diff -u cconv-0.6.2/debian/rules cconv-0.6.2/debian/rules
--- cconv-0.6.2/debian/rules
+++ cconv-0.6.2/debian/rules
@@ -1,16 +1,9 @@
 #!/usr/bin/make -f
 
-# These are used for cross-compiling and for saving the configure script
-# from having to guess our platform (since we know it already)
-DEB_HOST_GNU_TYPE   ?= $(shell dpkg-architecture -qDEB_HOST_GNU_TYPE)
-DEB_BUILD_GNU_TYPE  ?= $(shell dpkg-architecture -qDEB_BUILD_GNU_TYPE)
-
 config.status: configure
dh_testdir
dh_autoreconf
-   ./configure --prefix=/usr \
-   --mandir=\$${prefix}/share/man \
-   --infodir=\$${prefix}/share/info \
+   dh_auto_configure -- \
CFLAGS="$(CFLAGS)" LDFLAGS="-Wl,-z,defs"
 
 build: build-stamp

Bug#971812: gegl: version in buster not compatible with libc6 from bullseye

[Adrian Bunk]

Control: reassign -1 libc6
Control: affects -1 libgegl-0.4-0
Control: close -1 2.31-9

On Wed, Oct 07, 2020 at 08:50:01PM +0100, Simon McVittie wrote:
>...
> This is because you are using the version of libc6 from testing (bullseye)
> on a mostly-buster system, and the version of libgegl in buster has
> assumptions that mean it works fine in buster, but breaks when libc6
> is upgraded. Mixing packages from stable and testing is not something
> that anyone can guarantee will work flawlessly.
> 
> This is not going to be something that can change in buster, unless the
> release team would accept a stable-update that changes how libgegl is
> linked in order to future-proof it against people upgrading core system
> libraries to versions 18 months newer. I'm not sure they're going to go
> for that, but I'll ask...
>...

Such problems can be solved with a Breaks in the opposite direction,
and this has already been done in bullseye for this bug:

glibc (2.31-9) unstable; urgency=medium
...
  * debian/control.in/libc: add a Breaks: against libgegl-0.4-0 (<< 0.4.18).
Closes: #968349.

 -- Aurelien Jarno   Tue, 05 Jan 2021 06:47:42 +0100

> smcv

cu
Adrian

Bug#991167: ftpsync: Please document how to contribute

[Raphaël Hertzog]

Package: ftpsync
Version: 20180513+nmu1
Severity: wishlist
User: de...@kali.org
Usertags: origin-kali
X-Debbugs-Cc: raph...@offensive-security.com

Looking at the README in https://salsa.debian.org/mirror-team/archvsync
I saw no instructions on how to contribute, nor any indication of where
bugs are welcome.

It would be nice to tell users that found an issue that they can file bugs
in the Debian BTS and that they can submit merge requests for patches (or
that they can send patch to the BTS if that's your preference).

IMO it would make sense to allow GitLab issues on the project too for
"upstream change", but YMMV.

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

Kernel: Linux 5.10.0-7-amd64 (SMP w/16 CPU threads)
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 ftpsync depends on:
ii  postfix [mail-transport-agent]  3.5.6-1+b1
ii  rsync   3.2.3-4

Versions of packages ftpsync recommends:
ii  curl  7.74.0-1.3+b1

ftpsync suggests no packages.

-- no debconf information

Bug#991166: ftpsync: Contents* and dep11/* metadata are incorrectly updated in stage1

[Raphaël Hertzog]

Package: ftpsync
Version: 20180513+nmu1
Severity: important
User: de...@kali.org
Usertags: origin-kali
X-Debbugs-Cc: raph...@offensive-security.com

In Kali we encountered many failed "apt update" with a mirror that was
slow to update and it always failed due to invalid checksums on
"Contents-amd64.gz".

Looking more closely, I discovered that "ftpsync" was not really kept
up-to-date with other files that are listed in the Release file and that
should be updated in stage 2 instead of stage 1.

I noticed in particular that dep11/* should also be handled like we
do for "i18n/*". And we might want to do it also for MD5SUMS/SHA256SUMS
files of debian-installer... although updates there are not very frequent.

Thank you in advance!

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

Kernel: Linux 5.10.0-7-amd64 (SMP w/16 CPU threads)
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 ftpsync depends on:
ii  postfix [mail-transport-agent]  3.5.6-1+b1
ii  rsync   3.2.3-4

Versions of packages ftpsync recommends:
ii  curl  7.74.0-1.3+b1

ftpsync suggests no packages.

-- no debconf information

Bug#991165: RM: compass-yui-plugin/0~20100724-4

[Jonas Smedegaard]

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

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Please drop compass-yui-plugin from Debian testing.

It is dead upstream and obsoleted by newer major YUI releases.

Last dependency, debian-design, dropped its dependency few days ago.

-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEn+Ppw2aRpp/1PMaELHwxRsGgASEFAmDxVowACgkQLHwxRsGg
ASEsNA//UI4BOdreODXSKgL/NA2H1Z8xDXnfzi3brxpmyfWV8lYn/9nQqG1l/3/d
kf7GjScsWbH0Bap7d4G4zFTb8DfEF1JmBRkE8MrVT0KABiCiR12+rlLPNsFrAleA
qo5NDgRsU+3QVxVj8feV2eg2MHTRziBjfg4qF/kGy46Avk7BvDc6GGQ+XwCCwI/i
YNN4bCX8T6zyotSHRrv+aK6TaQQ0B6c7KnqLWI85z9PLLfCguvR1lwkZ/ejcdK77
ROAgpGVJIBS74pF5lLKdvDOz58BZt/CrEevcNCAAalU0IgjUbIk9zbL8vlgjubCz
SpOvaSfa+yPdSCUFtmwGf+Te7hOuflGG1NEgRZKXB23XG3eWbKtikrsfo8peVFab
iVPIc80jp1FWbQY/9YzZsyN+HqQixdO9HDkDeK6e/u2sm0dhA7gmP3EbM9rHm81b
x7IWi8v+2ORFpGmyl8+sqprjVUL8jU1YThCeAfzbK4dPZ3ozZq61Dc5xs+Qw16Gt
apYJUXZAuS0eDd6VlLGOnF9G3CdSqbwIUIhj4U5vUvxBXWaUj8jyZg/+Ecuk7f6m
42aUVb0qIw7OkExP8KA6RhQPRuTwYeMX719eHUFgmcSiLwM8EQyLFqRA4j6qWwE9
N0gT5k/SLq0wNrgkrbtpVR0Ti/V71XkEmtr4Z3yy3U811JR6hOo=
=Cl/8
-END PGP SIGNATURE-

Bug#991164: RM: compass-slickmap-plugin/0.5.1.1-5

[Jonas Smedegaard]

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

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Please drop compass-slickmap-plugin from Debian testing.

It is dead upstream and has little if any use with modern Sass tools
(it has closer ties to ruby-sass which is also dead upstream but
unfortunately cannot be dropped yet due to reverse dependencies).

Last dependency, debian-design, dropped its dependency few days ago.

-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEn+Ppw2aRpp/1PMaELHwxRsGgASEFAmDxVlAACgkQLHwxRsGg
ASG+QA/+KttDnbsflcIvAsCzVfZnEGdlG3Ep6PiCLNf/kGGB94G0BK98aj9+AL62
PMIwuopMUiw4dBvJ4IgxEDqSBeYCFqUNB2OEtlLKFPwBf2TqOxpGcJ8kfyWSHmxb
jIy+yiYiAi5xyRpnPKa8vlmyIXuCG4CzupHctQ6NwM5Kx9orRjEZ4hQoeakd7hR2
PVPZsr3fvBToejdalQUeDzneO2RvRyaomw26rInVFLw9XEWEtM/lOkrNjRrMD84m
b+72btX5zaTmfKWRzCVPvlzmF0CP8NgHaV9khXSkovST9cZrGBMrp6lJibAX2psb
CUhbr6vjEMkOUxPrVhey612FzSx3cNZzpl69gA3ZEvrkO2fkgR2ALUcwbyJ0M61A
JiMAV5mETxzxb3k6cHWtdIwrVUj3XMKL1Hx+pwgjEpj6y0PIaI0W3SQ3iPPFet8e
Aqo2jcM3JKq9wN5ma7XpWhT7n83K/X5qlPAMp7s8sFERE20anSG0VxmTJn+PrrKF
xki8hYt+7mPwqdL3HB6naECyuyHfSAwzmatC9xK2X0RcrcNp7R5rHWW2eVYTuTRH
HIHX6C21I1pR/IAela6H0H/9ETnzOY6z79P0pR9sZ61/6GfuIGRWqGx25/b3DnJx
uzWxSFiDptfYrU2rekQquPBt527cPDlV68/f1whpHb+1VrakLjk=
=V71c
-END PGP SIGNATURE-

Bug#991163: RM: compass-susy-plugin/2.2.12-1.1

[Jonas Smedegaard]

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

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Please drop compass-susy-plugin from Debian testing.

It is dead upstream and obsoleted by newer CSS3 Grid techniques.

Last dependency, debian-design, dropped its dependency few days ago.

-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEn+Ppw2aRpp/1PMaELHwxRsGgASEFAmDxVd4ACgkQLHwxRsGg
ASGbRQ//YS9UYzgPHozwOmwZoMdmQC8NnwlfLXITfmvGBez5BvNSH2NhgEaHq1sN
DBSvK1T+EQgi9XesgKkzxFftax1bnZC9R5n/Wt70z2ImQMk9dFp7ckl3HQ67I2Ir
MQudkZFjXYyEJPSp95fzK1cUqkOtzidOWEnnbEXffv1t5CIOaLOd1rh1Par7y7En
GuDnYcNq6JR+2lEzjP1Rlupl7PHghBjwphUvXqXo8q7vyxfClTrh4BF2a2hqIqJb
9GKUr72wiKmX66HvTo75mWT8WLPoEEMD7yCPU0Otb2RLA6kM7tXIKu3PUpMsSpWR
ohIAWtcLaEKcUCTBgwSM8a+9alrfBByCXfWmli/seC1v5i868h3NmFb9EH5Ylf+h
CAm1BS4TbSViwv7TrIcxElchhZgjaZP9HDfZNr5/C6cle0ae2xFBOZFPJxxUB2x6
NMh7nSzkJeheuTJ2QizYS4OZ7clZ+OBp1ZFjeBRaKGAqnd/MPPlavrmYRgAytPoi
p5biCxA6A2uaKMhkWDTf2WYQTTqkcLLXsMjtomrK5cUDkqFdI3W7Sz9AUKgQVJ70
Zu6XJ1y84RXAy6bsVW2IfrT+buwfGwpKNDKH4beXi0czvVFb9su4B3f8EdTMA7Lu
16m1wVI1rulXpgzalUyhDy5GByWTFLQUZ/AwNbvIGN4o5v7yA+U=
=/t8U
-END PGP SIGNATURE-

Bug#991162: RM: compass-singularitygs-plugin/1.8.0-1

[Jonas Smedegaard]

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

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Please drop compass-singularitygs-plugin from Debian testing.

It is dead upstream and obsoleted by newer CSS3 Grid techniques.

Last dependency, debian-design, dropped its dependency few days ago.

 - Jonas

-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEn+Ppw2aRpp/1PMaELHwxRsGgASEFAmDxVYoACgkQLHwxRsGg
ASHBNg//VvBv8OcMWcBp5EAu+r+q2O3iLJKGMBKb5WL/inrRikEoC7pZ+pkqm/RZ
pcC6qUaHtnRkej60YTdX33o6Tm9a7SO3jB7UW0BEh/HQrLB3GZ3pxwAUaK1mQ8Gs
c7ZSy6c/rNlFe16ZJpQHpT9/2VSZihwzBMAyko9xluZ4Y5yvSaE6backKArIaHrh
Amgn07znwmLwy+tad7uvC3MF0kgNLqhwJ2i0L9wqSwhfwMprGhi4HWLzabB3V3QQ
BjOckVjv1Wl3qTeEzceT9pmLx24ozxZWASSShLJLBeLEug4jYCfFam5txPYIO+XI
q/zjvOdaAyXwg8A63FR7RlLeySW2yXdB/QJ49eoGhy5rPJByy+CKdBHd8V1Fpqbb
A18yfgOo+XjhV49pJdxDOYJR+owoTWMhgxqh8BPP2bm2ZhxAnToskIc5QshOvZGF
zbtH0YTq+vcWtpyeY5GTExi0sZqxTYR9oc7xGzm7KWPGf8ZT6CiI9GkrkbbLY5cv
uswrbB1xeq/QtjgED7RZvt6KvWtoQj5yxlxnifOONFWlnqQnKhuKOzWeSt5FSrb9
Goxvpk7ANI++veIjjeQWPAPjqmRxZaP7S5mbN0hK7SYuSpD3IlLqtx3/gCyq03S2
RolJ9OOVgr5cESsOyRx3Yr1TR8/c28mM5ijkIegxvdw4y0+BTAk=
=Q95r
-END PGP SIGNATURE-

Bug#991161: unblock: python-nosehtmloutput/0.0.5-3

[Thomas Goirand]

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

Please unblock package python-nosehtmloutput

This fixes #990816 (ie: unuseable package, it seems).
I applied upstream Python 3 support patch which fixes
the issue.

This is kind of a low risk leaf package, only used to
build docs, so IMO nothing to worry much about.

[ 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 python-nosehtmloutput/0.0.5-3
diff -Nru python-nosehtmloutput-0.0.5/debian/changelog 
python-nosehtmloutput-0.0.5/debian/changelog
--- python-nosehtmloutput-0.0.5/debian/changelog2019-09-02 
09:06:42.0 +0200
+++ python-nosehtmloutput-0.0.5/debian/changelog2021-07-16 
09:23:39.0 +0200
@@ -1,3 +1,9 @@
+python-nosehtmloutput (0.0.5-3) unstable; urgency=medium
+
+  * Added upstream "Python 3 support" patch (Closes: #990816).
+
+ -- Thomas Goirand   Fri, 16 Jul 2021 09:23:39 +0200
+
 python-nosehtmloutput (0.0.5-2) unstable; urgency=medium
 
   * Team upload.
diff -Nru python-nosehtmloutput-0.0.5/debian/patches/Python-3-support.patch 
python-nosehtmloutput-0.0.5/debian/patches/Python-3-support.patch
--- python-nosehtmloutput-0.0.5/debian/patches/Python-3-support.patch   
1970-01-01 01:00:00.0 +0100
+++ python-nosehtmloutput-0.0.5/debian/patches/Python-3-support.patch   
2021-07-16 09:23:39.0 +0200
@@ -0,0 +1,84 @@
+Description: Python 3 support
+ * Implicit relative import 'import version' to import htmloutput.version.
+   Use explicit relative import instead 'from . import version'.
+   Somehow 'from htmloutput import version' does not work for python2
+   when I tested this with horizon nosetest.
+ * Python3 dict does not has_key(). Use 'not in' instead.
+ * Open a file for writing with 'wb' (binary mode).
+   In Python 3, encode() converts unicode including regular string into
+   bytes. In Python 2, encode() converts unicode string into string and
+   string and bytes are handled equivalently. Thus, opening a file with
+   binary mode works both for python2 and python3.
+ * Decoding from string to unicode is only needed for Python 2,
+   so six.PY2 check is added to isinstance(x, str) if-clause.
+Author: Akihiro Motoki 
+Date: Thu, 22 Jun 2017 19:18:31 +0900
+Change-Id: Ied161e133ced1d672aba9d1a44b52034dfb676da
+Origin: upstream, 
https://github.com/openstack/nose-html-output/commit/71d12999b06908bbb019f69c89361bd44bec316c.patch
+
+Index: python-nosehtmloutput/htmloutput/htmloutput.py
+===
+--- python-nosehtmloutput.orig/htmloutput/htmloutput.py
 python-nosehtmloutput/htmloutput/htmloutput.py
+@@ -44,7 +44,9 @@ from nose.plugins import Plugin
+ import nose.plugins.skip
+ from xml.sax import saxutils
+ 
+-import version
++import six
++
++from . import version
+ __version__ = version.__version__
+ 
+ class TemplateData(object):
+@@ -513,7 +515,7 @@ class HtmlOutput(Plugin):
+ ending = ending,
+ )
+ if self.html_file:
+-html_file = open(self.html_file, 'w')
++html_file = open(self.html_file, 'wb')
+ html_file.write(output.encode('utf8'))
+ else:
+ stream.write(output.encode('utf8'))
+@@ -621,7 +623,7 @@ class HtmlOutput(Plugin):
+ cls = test.test.__class__
+ else:
+ cls = test.__class__
+-if not rmap.has_key(cls):
++if cls not in rmap:
+ rmap[cls] = []
+ classes.append(cls)
+ rmap[cls].append(data_tuple)
+@@ -639,13 +641,17 @@ class HtmlOutput(Plugin):
+ # Comments below from the original source project.
+ # TODO: clean this up within the context of a nose plugin.
+ # o and e should be byte string because they are collected from 
stdout and stderr?
+-if isinstance(o,str):
++# NOTE: In Python3 unicode is natively supported as string,
++# so there is no need to decode() here.
++if six.PY2 and isinstance(o, str):
+ # TODO: some problem with 'string_escape': it escape \n and mess 
up formating
+ # uo = unicode(o.encode('string_escape'))
+ uo = o.decode('latin-1')
+ else:
+ uo = o
+-if isinstance(e,str):
++# NOTE: In Python3 unicode is natively supported as string,
++# so there is no need to decode() here.
++if six.PY2 and isinstance(e, str):
+ # TODO: some problem with 'string_escape': it escape \n and mess 
up formating
+ # ue = unicode(e.encode('string_escape'))
+ ue = e.decode('latin-1')
+Index: python-nosehtmloutput/setup.py
+===
+--- python-nosehtmloutput.orig/setup.py
 python-nosehtmloutput/setup.py
+@@ -9,7 +9,7 @@ setuptools.setup(
+ 

Bug#990816: python3-nosehtmloutput: nosetests3 --with-html fails with RuntimeWarning

[Thomas Goirand]

On 7/15/21 10:36 PM, Jochen Sprickerhof wrote:
> Control: tags -1 patch
> 
> Hi,
> 
> this was fixed upstream in:
> 
> https://opendev.org/openstack/nose-html-output/commit/71d12999b06908bbb019f69c89361bd44bec316c
> 
> 
> Which is basically the only change in version 0.7. I would propose to
> upload that and ask for an unblock. @Thomas: can you take care or should
> I do a NMU?
> 
> Cheers Jochen

Hi,

Patch applied and uploaded. Thanks. Note that I also uploaded upstream
release 0.0.7 to experimental.

Cheers,

Thomas Goirand (zigo)

Bug#980472: cubicsdr: CubicSDR crashes after lauch! (same effect on 2 clean bullseye OS)

[Christoph Berg]

Am 16. Juli 2021 06:58:54 MESZ schrieb tony mancill :
>On Tue, Jun 01, 2021 at 02:06:33AM +0300, Adrian Bunk wrote:
>> Control: reassign -1 libhamlib4 4.0-6
>> Control: fixed -1 4.1-1
>> Control: affects -1 cubicsdr
>> Control: forwarded -1
>https://sourceforge.net/p/hamlib/code/ci/31dedcf4f79d8fc5fcf287360e5d017842c8e4c0/
>> 
>> The oneline fix for hamlib above matches your analysis exactly.
>
>And indeed it does!  Thank you for the pointer Adrian.
>
>I was able to reproduce the crash with cubicsdr locally using a basic
>RTL2832U dongle.  Then I built and tested with the reference patch and
>cubicsdr is working for me.  I also did a very quick check of wsjtx.
>
>Any concerns with an upload to unstable, hopefully in time a
>last-second
>unblock request for bullseye?  (debdiff attached)
>
>Cheers,
>tony

Seems fine to me, thanks for digging into this!

I'm currently on vacation, so please just go ahead with uploading.

Christoph

Bug#991160: rapl collector broken with Bullseye kernel, spams syslog

[Moritz Muehlenhoff]

Package: prometheus-node-exporter
Severity: important
Tags: patch

The rapl collector is broken with the 5.10 kernel in Bullseye and thus spams
syslog every minute with a message like this:

---
Jul 16 07:03:39 thanos-fe2001 prometheus-node-exporter[593]: level=error 
ts=2021-07-16T07:03:39.665Z caller=collector.go:161 msg="collector failed" 
name=rapl duration_seconds=0.004142071 err="open 
/sys/class/powercap/intel-rapl:0/energy_uj: permission denied"
Jul 16 07:03:39 thanos-fe2001 prometheus-node-exporter[593]: level=error 
ts=2021-07-16T07:03:39.669Z caller=collector.go:161 msg="collector failed" 
name=rapl duration_seconds=0.002975521 err="open 
/sys/class/powercap/intel-rapl:0/energy_uj: permission denied"
---

This has been reported upstream: 
https://github.com/prometheus/node_exporter/issues/1892

The upstream fix is to disable the collector, I we think should do the same for 
Bullseye?
https://github.com/wagdav/homelab/commit/26fc86c6a79a5f1a634c7b313f86c0b6109539c0

Cheers,
 Moritz