Bug#1003105: src:ca-certificates: fails to migrate to testing for too long: unresolved RC bug

[Paul Gevers]

Source: ca-certificates
Version: 20210119
Severity: serious
Control: close -1 20211016
Tags: sid bookworm
User: release.debian@packages.debian.org
Usertags: out-of-sync
Control: block -1 by 996048

Dear maintainer(s), Julien,

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


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


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


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


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


Paul

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


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1003104: src:pktanon: fails to migrate to testing for too long: autopkgtest regression on armhf

[Paul Gevers]

Source: pktanon
Version: 2~git20160407.0.2bde4f2+dfsg-7
Severity: serious
Control: close -1 2~git20160407.0.2bde4f2+dfsg-8
Tags: sid bookworm
User: release.debian@packages.debian.org
Usertags: out-of-sync
Control: block -1 by 999620

Dear maintainer(s), Sascha,

[What follows is a template, I'm aware we discussed the issue in the 
"block" bug].


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


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


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


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


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


Paul

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



OpenPGP_signature
Description: OpenPGP digital signature

Bug#984339: slim: diff for NMU version 1.3.6-5.3

[Christoph Biedl]

Control: tags 984339 + patch
Control: tags 984339 + pending

Dear maintainer,

To resolve the sitatuation, I've prepared an NMU for slim (versioned as
1.3.6-5.3), upload to DELAYED/2 will follow shortly. Please feel free to
tell me if I should delay it longer.

Regards.

diff -Nru slim-1.3.6/debian/changelog slim-1.3.6/debian/changelog
--- slim-1.3.6/debian/changelog 2020-09-25 13:22:22.0 +0200
+++ slim-1.3.6/debian/changelog 2022-01-04 01:43:19.0 +0100
@@ -1,3 +1,10 @@
+slim (1.3.6-5.3) unstable; urgency=high
+
+  * Non-maintainer upload
+  * Fix build error with gcc 11. Closes: #984339
+
+ -- Christoph Biedl   Tue, 04 Jan 2022 
07:02:51 +0100
+
 slim (1.3.6-5.2) unstable; urgency=medium
 
   * Non-maintainer upload.
diff -Nru slim-1.3.6/debian/patches/series slim-1.3.6/debian/patches/series
--- slim-1.3.6/debian/patches/series2017-05-02 15:42:52.0 +0200
+++ slim-1.3.6/debian/patches/series2022-01-04 00:58:36.0 +0100
@@ -6,3 +6,4 @@
 fix-systemd-service.patch
 manpage-formatting-fixes.patch
 fix-missing-plymouth-handling.patch
+slim-1.3.6-gcc11.patch
diff -Nru slim-1.3.6/debian/patches/slim-1.3.6-gcc11.patch 
slim-1.3.6/debian/patches/slim-1.3.6-gcc11.patch
--- slim-1.3.6/debian/patches/slim-1.3.6-gcc11.patch1970-01-01 
01:00:00.0 +0100
+++ slim-1.3.6/debian/patches/slim-1.3.6-gcc11.patch2022-01-04 
01:42:15.0 +0100
@@ -0,0 +1,33 @@
+Subject: Fix build with GCC 11
+Author: Martin Väth
+Date: 2021-05-03
+Bug-Debian: https://bugs.debian.org/984339
+Bug-Gentoo: https://bugs.gentoo.org/786498
+
+From the Gentoo bug ticket:
+
+Comment to the patch, since it might look wrong at a first glance:
+
+All documentation about the return value of XCreateGC I found states
+that it returns a proper pointer and in the error case sets some
+failure stat. In particular, I found no documentation that it
+returns a "negative" pointer.
+
+The cleanest patch would probably be to check the failure stat, but
+since I am not sure about it, the most reasonable analogous check to
+the original code is to check whether we get a null pointer
+returned. (Very likely, neither the original code nor the patch work
+properly in the error case, but at least the patch fixes the
+compilation issue and causes no regression in the non-error case.)
+
+--- a/panel.cpp
 b/panel.cpp
+@@ -48,7 +48,7 @@
+   gcm = GCGraphicsExposures;
+   gcv.graphics_exposures = False;
+   WinGC = XCreateGC(Dpy, Win, gcm, );
+-  if (WinGC < 0) {
++  if (WinGC == 0) {
+   cerr << APPNAME
+   << ": failed to create pixmap\n.";
+   exit(ERR_EXIT);



signature.asc
Description: PGP signature

Bug#1003102: ITP: webrtc -- WebRTC provides real time voice and video processing functionality to enable the implementation of PeerConnection/MediaStream.

[Paul Gevers]

Hi,

On 04-01-2022 08:12, 汤孟 wrote:

 > Is this similar to what webrtc-audio-processing does for audio alone? Is
 > this a super set or does this implement audio for webrtc differently?

webrtc-audio-processing is a subset of libwebrtc, the code of
webrtc-audio-processing is in the:
https://webrtc.googlesource.com/src/+/refs/heads/main/modules/audio_processing/

I wants to upload all modules of libwebrtc to facilitate subsequent 
development using

webrtc's API.


Do I understand correctly that webrtc-audio-processing will become 
redundant then? Have you aligned with the maintainers? Will you take 
over the libraries provided by that source package? If yes, will you 
make sure existing reverse dependencies don't need to change?


Paul


OpenPGP_signature
Description: OpenPGP digital signature

Bug#984339: slim: ftbfs with GCC-11

[Christoph Biedl]

Slavko wrote...

> i use slim, thus i wonder about its future. The patch proposed by
> Hugo Torres doesn't look as solution for me, but searching lead me
> to gentoo's bug tracker and and it's git, where i found:
> 
> + the bugreport with the same problem at https://bugs.gentoo.org/786498 
> + patch named slim-1.3.6-gcc11.patch at
>   
> https://gitweb.gentoo.org/repo/gentoo.git/tree/x11-misc/slim/files/slim-1.3.6-gcc11.patch

Thanks for finding this.

> I tried to apply it locally and slim build, while i didn't check how it
> works...

Well, I did, slim seems to work fine. A NMU to bring slim back into testing
will follow shortly.

Christoph


signature.asc
Description: PGP signature

Bug#1003102: ITP: webrtc -- WebRTC provides real time voice and video processing functionality to enable the implementation of PeerConnection/MediaStream.

[汤孟]

Hi

 I think this name is too generic, as it's also the name of the protocol 
 (IIUC) and we already have multiple webrtc implementing packages in the 
 archive. Maybe libwebrtc (as it provides functions to implement webrtc) 
 or webrtc-processing (complementary to webrtc-audio-processing, see 
below)? 

As you said, this is actually libwebrtc.



 Is this similar to what webrtc-audio-processing does for audio alone? Is 
 this a super set or does this implement audio for webrtc differently? 


webrtc-audio-processing is a subset of libwebrtc, the code of
webrtc-audio-processing is in the:
https://webrtc.googlesource.com/src/+/refs/heads/main/modules/audio_processing/


I wants to upload all modules of libwebrtcto facilitate subsequent 
development using
webrtc's API.


tangmeng

Bug#999069: console-cyrillic: diff for NMU version 0.9-17.2

[Adrian Bunk]

Control: tags 999069 + patch
Control: tags 999069 + pending

Dear maintainer,

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

cu
Adrian
diff -u console-cyrillic-0.9/debian/changelog console-cyrillic-0.9/debian/changelog
--- console-cyrillic-0.9/debian/changelog
+++ console-cyrillic-0.9/debian/changelog
@@ -1,3 +1,10 @@
+console-cyrillic (0.9-17.2) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * debian/rules: Add build-{arch,indep}. (Closes: #999069)
+
+ -- Adrian Bunk   Tue, 04 Jan 2022 09:17:15 +0200
+
 console-cyrillic (0.9-17.1) unstable; urgency=medium
 
   * Non maintainer upload by the Reproducible Builds team.
diff -u console-cyrillic-0.9/debian/rules console-cyrillic-0.9/debian/rules
--- console-cyrillic-0.9/debian/rules
+++ console-cyrillic-0.9/debian/rules
@@ -164,3 +164,5 @@
 
-.PHONY: binary binary-arch binary-indep clean checkroot
+build-arch: build
+build-indep: build
+.PHONY: build build-arch build-indep binary binary-arch binary-indep clean checkroot
 

Bug#1003102: ITP: webrtc -- WebRTC provides real time voice and video processing functionality to enable the implementation of PeerConnection/MediaStream.

[Paul Gevers]

Hi

On 04-01-2022 04:25, tangmeng wrote:

* Package name: webrtc


I think this name is too generic, as it's also the name of the protocol 
(IIUC) and we already have multiple webrtc implementing packages in the 
archive. Maybe libwebrtc (as it provides functions to implement webrtc) 
or webrtc-processing (complementary to webrtc-audio-processing, see below)?



   Version : 90
   Upstream Author : Tomas Gunnarsson 
* URL : http://www.webrtc.org
* License : BSD
   Programming Lang: C, C++, Clang, Python
   Description : WebRTC provides real time voice and video processing 
functionality to enable the implementation of PeerConnection/MediaStream.

  WebRTC is a free, open software project** that provides browsers and mobile
  applications with Real-Time Communications (RTC) capabilities via simple APIs.
  The WebRTC components have been optimized to best serve this purpose.

  WebRTC provides a library of real-time communication (RTC) functions for
  browsers and mobile applications through simple APIs.


Is this similar to what webrtc-audio-processing does for audio alone? Is 
this a super set or does this implement audio for webrtc differently?


Paul


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1002976: installation-reports: Installer Fault Accessibility No Screen Reader Heard

[D.J.J. Ring, Jr.]

On Tue, Jan 4, 2022, 01:09 Philip Hands  wrote:

> "D.J.J. Ring, Jr."  writes:
>
> > Yes, I said that, but I am under the impression that whatever went wrong
> > happened before partitions were mounted.
> >
> > I remembered using that advance menu configuration which I was unable to
> > find in Bullseye  - at least the same exact thing with the ability of
> > obtaining an IP address and downloading files.  I thought these files
> were
> > lost if the logs weren't sent to a web server or written during
> > installation to a mounted hard drive.
>
> I think you've been misinformed there, unless you are aborting the
> install early because you cannot drive it without the sound working.
>
> Assuming the install completes, the complete logs, including what happened
> early in the install, are copied from the installer's /var/log (which is
> in RAM) to the target system's /var/log/installer, where they can be
> found once one boots the resulting installed system.
>
> Of course if you are not able to complete the install, because the lack
> of working sound makes that impossible for you, then it will not get as far
> as writing the logs to the target system's disk for you.
>
> > No errors are ever seen or heard - except that there is no sound after
> the
> > installer probes for sound card (press enter if this is your sound card,
> > etc.).
> >
> > I'm going to install Bullseye once again because right now I have Buster
> -
> > but the sound is working in Buster and the screen readers orca and
> console
> > are both working. and sound from videos in the browser are all working.
> > Now if I can only get this in Bullseye.
>
> If you have working buster, you could also try upgrading that to
> bullseye to see if that ends up with a working setup.
>
> That ought to help narrow down whether the problem is really in the
> installer, or is related to other changes between the releases.
>
> BTW I find `etckeeper` very useful for seeing what changes on a system
> (it creates a git repository under /etc for you, and records changes
> that happen), so you could install that before upgrading. It also
> records the versions of packages that get changed in the git log as well
> as the changes to files under /etc when you upgrade packages.
>
> Cheers, Phil.
> --
> |)|  Philip Hands  [+44 (0)20 8530 9560]  HANDS.COM Ltd.
> |-|  http://www.hands.com/http://ftp.uk.debian.org/
> |(|  Hugo-Klemm-Strasse 34,   21075 Hamburg,GERMANY
>


Thanks, Phil.

I tried the daily Sid unstable and it also has no working sound screen
reader during but once finished it's there.

I'll believe you about the files because I cannot find an advanced menu
that installs the screen reader like Buster.had. Buster is much easier to
install.

I'm going to try another installer tomorrow.

David

Bug#679383: cconv: diff for NMU version 0.6.2-1.2

[Adrian Bunk]

Control: tags 679383 + pending
Control: tags 999169 + patch
Control: tags 999169 + pending

Dear maintainer,

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

cu
Adrian
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,12 @@
+cconv (0.6.2-1.2) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * debian/rules: Add build-{arch,indep}. (Closes: #999169)
+  * Package description improvements from Justin B Rye.
+(Closes: 679383)
+
+ -- Adrian Bunk   Tue, 04 Jan 2022 08:10:17 +0200
+
 cconv (0.6.2-1.1) unstable; urgency=medium
 
   [ Aurelien Jarno
diff -u cconv-0.6.2/debian/control cconv-0.6.2/debian/control
--- cconv-0.6.2/debian/control
+++ cconv-0.6.2/debian/control
@@ -13,33 +13,30 @@
-Description: simplified-traditional chinese conversion tool
+Description: Simplified/Traditional Chinese conversion tool
  The Chinese national GB standard defines a basic set of (around 6,000)
- characters for use with Simplified Chinese writing that does not include many
- of the characters in the Taiwanese industry standard for Traditional Chinese
- called Big5 (around 13,000 characters in the basic set). Unicode is however a
- superset of both with all duplication removed down to the level of detail
- described above.
+ characters for use in Simplified Chinese writing; this excludes many of
+ the characters in the Taiwanese industry standard for Traditional Chinese
+ called Big5 (around 13,000 characters in the basic set). However, Unicode
+ is a superset of both (with the duplication removed).
  .
- This tool is used for converting a UTF-8 string which combining both
- Simplified Chinese characters and Traditional Chinese charcters directly into
- one type Chinese chareacters.
+ This tool is used for converting a UTF-8 string which contains both
+ Simplified and Traditional Chinese characters directly into a single
+ Chinese character set.
 
 Package: libcconv0
 Section: libs
 Architecture: any
 Depends: ${shlibs:Depends}, ${misc:Depends}
-Description: library for CCONV
- CCONV is a simplified-traditional chinese conversion tool.
+Description: library for cconv
+ Cconv is a Simplified/Traditional Chinese conversion tool. For more
+ information, see the description of the package cconv.
  .
- This package provide runtime libraries for CCONV.
- .
- For more information about CCONV, please see the description of cconv package.
+ This package provides the runtime library for cconv.
 
 Package: libcconv-dev
 Section: libdevel
 Architecture: any
 Depends: libcconv0 (= ${binary:Version}), ${misc:Depends}
-Description: development library for CCONV
- CCONV is a simplified-traditional chinese conversion tool.
- .
- This package provide development libraries and documentations for CCONV.
+Description: development libraries for CCONV
+ Cconv is a Simplified/Traditional Chinese conversion tool. For more
+ information, see the description of the package cconv.
  .
- For more information about CCONV, please see the description of cconv package.
+ This package provides development libraries and documentation for cconv.
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
@@ -65,2 +65,4 @@
+build-arch: build
+build-indep: build
 binary: binary-indep binary-arch
-.PHONY: build clean binary-indep binary-arch binary install 
+.PHONY: build-arch build-indep build clean binary-indep binary-arch binary install 

Bug#1002990: ITS: byacc

[Brendan O'Dea]

[+m...@qa.debian.org]

On Sun, Jan 02, 2022 at 05:05:20AM -0500, Thomas Dickey wrote:
>Package: byacc
>Version: 20220101
>Severity: important
>
>Dear Maintainer,
>
>   * byacc package has not been updated in Debian since 2014.
>   * sent email to package maintainer (December 4, 2021)
>   * package maintainer did not respond to email.
>   * package maintainer should update to the current version of byacc
>
>I've been preparing an NMU, will proceed when I have sponsor's approval.
>
>-- System Information:
>Debian Release: 10.11
>  APT prefers oldstable-updates
>  APT policy: (500, 'oldstable-updates'), (500, 'oldstable')
>Architecture: amd64 (x86_64)
>
>Kernel: Linux 4.19.0-18-amd64 (SMP w/2 CPU cores)
>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 /bin/dash
>Init: systemd (via /run/systemd/system)
>LSM: AppArmor: enabled
>
>Versions of packages byacc depends on:
>ii  libc6  2.28-10
>
>byacc recommends no packages.
>
>byacc suggests no packages.
>
>-- no debconf information

Bug#1002863: node-react-audio-player: FTBFS with webpack5: Error: Invalid webpack options

[Ayoyimika Ajibade]

Hello Nicolas!

Am good for now.

Thanks for asking

On Fri, Dec 31, 2021 at 3:47 PM Nicolas Mora  wrote:
>
> Hello Ayoyimika,
>
> I've updated the webpack patch for webpack 5. Now the build goes
> further, but it fails anyway:
>
> make[1]: Entering directory '/<>'
> webpack -p
> internal/modules/cjs/loader.js:818
>throw err;
>^
>
> Error: Cannot find module 'import-local'
> Require stack:
> - /usr/share/nodejs/webpack-cli/bin/cli.js
> - /usr/share/nodejs/webpack/bin/webpack.js
>  at Function.Module._resolveFilename
> (internal/modules/cjs/loader.js:815:15)
>  at Function.Module._load (internal/modules/cjs/loader.js:667:27)
>  at Module.require (internal/modules/cjs/loader.js:887:19)
>  at require (internal/modules/cjs/helpers.js:74:18)
>  at Object. (/usr/share/nodejs/webpack-cli/bin/cli.js:5:21)
>  at Module._compile (internal/modules/cjs/loader.js:999:30)
>  at Object.Module._extensions..js
> (internal/modules/cjs/loader.js:1027:10)
>  at Module.load (internal/modules/cjs/loader.js:863:32)
>  at Function.Module._load (internal/modules/cjs/loader.js:708:14)
>  at Module.require (internal/modules/cjs/loader.js:887:19) {
>code: 'MODULE_NOT_FOUND',
>requireStack: [
>  '/usr/share/nodejs/webpack-cli/bin/cli.js',
>  '/usr/share/nodejs/webpack/bin/webpack.js'
>]
> }
> make[1]: *** [debian/rules:11: override_dh_auto_build] Error 1
> make[1]: Leaving directory '/<>'
> make: *** [debian/rules:8: binary] Error 2
> dpkg-buildpackage: error: debian/rules binary subprocess returned exit
> status 2
>
> I'll upload a new package to unstable with the new patch, let me know if
> you need further help.
>
> /Nicolas

Bug#1003103: Clients are missing from the package

[Arto Jantunen]

Package: elpa-lsp-mode
Version: 8.0.0-2
Severity: grave
Tags: patch
X-Debbugs-Cc: tho...@koch.ro

A large part of the program isn't included in the package, see a debdiff
between version 8.0.0-2 and a correctly built package:

Files in first .deb but not in second
-
-rw-r--r--  root/root   
/usr/share/emacs/site-lisp/elpa-src/lsp-mode-8.0.0/lsp-actionscript.el
-rw-r--r--  root/root   
/usr/share/emacs/site-lisp/elpa-src/lsp-mode-8.0.0/lsp-ada.el
-rw-r--r--  root/root   
/usr/share/emacs/site-lisp/elpa-src/lsp-mode-8.0.0/lsp-angular.el
-rw-r--r--  root/root   
/usr/share/emacs/site-lisp/elpa-src/lsp-mode-8.0.0/lsp-bash.el
-rw-r--r--  root/root   
/usr/share/emacs/site-lisp/elpa-src/lsp-mode-8.0.0/lsp-beancount.el
-rw-r--r--  root/root   
/usr/share/emacs/site-lisp/elpa-src/lsp-mode-8.0.0/lsp-clangd.el
-rw-r--r--  root/root   
/usr/share/emacs/site-lisp/elpa-src/lsp-mode-8.0.0/lsp-clojure.el
-rw-r--r--  root/root   
/usr/share/emacs/site-lisp/elpa-src/lsp-mode-8.0.0/lsp-cmake.el
-rw-r--r--  root/root   
/usr/share/emacs/site-lisp/elpa-src/lsp-mode-8.0.0/lsp-crystal.el
-rw-r--r--  root/root   
/usr/share/emacs/site-lisp/elpa-src/lsp-mode-8.0.0/lsp-csharp.el
-rw-r--r--  root/root   
/usr/share/emacs/site-lisp/elpa-src/lsp-mode-8.0.0/lsp-css.el
-rw-r--r--  root/root   
/usr/share/emacs/site-lisp/elpa-src/lsp-mode-8.0.0/lsp-d.el
-rw-r--r--  root/root   
/usr/share/emacs/site-lisp/elpa-src/lsp-mode-8.0.0/lsp-dhall.el
-rw-r--r--  root/root   
/usr/share/emacs/site-lisp/elpa-src/lsp-mode-8.0.0/lsp-dockerfile.el
-rw-r--r--  root/root   
/usr/share/emacs/site-lisp/elpa-src/lsp-mode-8.0.0/lsp-elixir.el
-rw-r--r--  root/root   
/usr/share/emacs/site-lisp/elpa-src/lsp-mode-8.0.0/lsp-elm.el
-rw-r--r--  root/root   
/usr/share/emacs/site-lisp/elpa-src/lsp-mode-8.0.0/lsp-erlang.el
-rw-r--r--  root/root   
/usr/share/emacs/site-lisp/elpa-src/lsp-mode-8.0.0/lsp-eslint.el
-rw-r--r--  root/root   
/usr/share/emacs/site-lisp/elpa-src/lsp-mode-8.0.0/lsp-fortran.el
-rw-r--r--  root/root   
/usr/share/emacs/site-lisp/elpa-src/lsp-mode-8.0.0/lsp-fsharp.el
-rw-r--r--  root/root   
/usr/share/emacs/site-lisp/elpa-src/lsp-mode-8.0.0/lsp-gdscript.el
-rw-r--r--  root/root   
/usr/share/emacs/site-lisp/elpa-src/lsp-mode-8.0.0/lsp-go.el
-rw-r--r--  root/root   
/usr/share/emacs/site-lisp/elpa-src/lsp-mode-8.0.0/lsp-groovy.el
-rw-r--r--  root/root   
/usr/share/emacs/site-lisp/elpa-src/lsp-mode-8.0.0/lsp-hack.el
-rw-r--r--  root/root   
/usr/share/emacs/site-lisp/elpa-src/lsp-mode-8.0.0/lsp-haxe.el
-rw-r--r--  root/root   
/usr/share/emacs/site-lisp/elpa-src/lsp-mode-8.0.0/lsp-html.el
-rw-r--r--  root/root   
/usr/share/emacs/site-lisp/elpa-src/lsp-mode-8.0.0/lsp-javascript.el
-rw-r--r--  root/root   
/usr/share/emacs/site-lisp/elpa-src/lsp-mode-8.0.0/lsp-json.el
-rw-r--r--  root/root   
/usr/share/emacs/site-lisp/elpa-src/lsp-mode-8.0.0/lsp-kotlin.el
-rw-r--r--  root/root   
/usr/share/emacs/site-lisp/elpa-src/lsp-mode-8.0.0/lsp-lua.el
-rw-r--r--  root/root   
/usr/share/emacs/site-lisp/elpa-src/lsp-mode-8.0.0/lsp-markdown.el
-rw-r--r--  root/root   
/usr/share/emacs/site-lisp/elpa-src/lsp-mode-8.0.0/lsp-nim.el
-rw-r--r--  root/root   
/usr/share/emacs/site-lisp/elpa-src/lsp-mode-8.0.0/lsp-nix.el
-rw-r--r--  root/root   
/usr/share/emacs/site-lisp/elpa-src/lsp-mode-8.0.0/lsp-ocaml.el
-rw-r--r--  root/root   
/usr/share/emacs/site-lisp/elpa-src/lsp-mode-8.0.0/lsp-perl.el
-rw-r--r--  root/root   
/usr/share/emacs/site-lisp/elpa-src/lsp-mode-8.0.0/lsp-php.el
-rw-r--r--  root/root   
/usr/share/emacs/site-lisp/elpa-src/lsp-mode-8.0.0/lsp-prolog.el
-rw-r--r--  root/root   
/usr/share/emacs/site-lisp/elpa-src/lsp-mode-8.0.0/lsp-purescript.el
-rw-r--r--  root/root   
/usr/share/emacs/site-lisp/elpa-src/lsp-mode-8.0.0/lsp-pwsh.el
-rw-r--r--  root/root   
/usr/share/emacs/site-lisp/elpa-src/lsp-mode-8.0.0/lsp-pyls.el
-rw-r--r--  root/root   
/usr/share/emacs/site-lisp/elpa-src/lsp-mode-8.0.0/lsp-pylsp.el
-rw-r--r--  root/root   
/usr/share/emacs/site-lisp/elpa-src/lsp-mode-8.0.0/lsp-r.el
-rw-r--r--  root/root   
/usr/share/emacs/site-lisp/elpa-src/lsp-mode-8.0.0/lsp-racket.el
-rw-r--r--  root/root   
/usr/share/emacs/site-lisp/elpa-src/lsp-mode-8.0.0/lsp-rf.el
-rw-r--r--  root/root   
/usr/share/emacs/site-lisp/elpa-src/lsp-mode-8.0.0/lsp-rust.el
-rw-r--r--  root/root   
/usr/share/emacs/site-lisp/elpa-src/lsp-mode-8.0.0/lsp-solargraph.el
-rw-r--r--  root/root   
/usr/share/emacs/site-lisp/elpa-src/lsp-mode-8.0.0/lsp-sorbet.el
-rw-r--r--  root/root   
/usr/share/emacs/site-lisp/elpa-src/lsp-mode-8.0.0/lsp-sqls.el
-rw-r--r--  root/root   
/usr/share/emacs/site-lisp/elpa-src/lsp-mode-8.0.0/lsp-steep.el
-rw-r--r--  root/root   
/usr/share/emacs/site-lisp/elpa-src/lsp-mode-8.0.0/lsp-svelte.el
-rw-r--r--  root/root   
/usr/share/emacs/site-lisp/elpa-src/lsp-mode-8.0.0/lsp-terraform.el
-rw-r--r--  root/root   
/usr/share/emacs/site-lisp/elpa-src/lsp-mode-8.0.0/lsp-tex.el
-rw-r--r--  root/root   

Bug#1003102: ITP: webrtc -- WebRTC provides real time voice and video processing functionality to enable the implementation of PeerConnection/MediaStream.

[tangmeng]

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

* Package name: webrtc
  Version : 90
  Upstream Author : Tomas Gunnarsson 
* URL : http://www.webrtc.org
* License : BSD
  Programming Lang: C, C++, Clang, Python
  Description : WebRTC provides real time voice and video processing 
functionality to enable the implementation of PeerConnection/MediaStream.

 WebRTC is a free, open software project** that provides browsers and mobile
 applications with Real-Time Communications (RTC) capabilities via simple APIs.
 The WebRTC components have been optimized to best serve this purpose.

 WebRTC provides a library of real-time communication (RTC) functions for
 browsers and mobile applications through simple APIs.

Bug#1003101: ITP: opengnb -- via P2P to setup de-centralized layer3 network VPN

[肖盛文]

Package: wnpp
Severity: wishlist
Owner: xiao sheng wen(肖盛文) 
X-Debbugs-Cc: debian-de...@lists.debian.org, atzli...@sina.com

* Package name: opengnb
  Version : 1.2.8.1
  Upstream Author : gnbdev 
* URL : https://github.com/gnbdev/opengnb/
* License : GPL-3
  Programming Lang: C
  Description : via P2P to setup de-centralized layer3 network VPN
 opengnb is open source de-centralized VPN to achieve layer3 network via p2p
 with the ultimate capability of NAT Traversal.
 .
 opengnb can add many nodes and LANs together into one big VPN.
 opengnb support use public index node to forward net packages.
 The public Internet IP is optional for setup one opengnb VPN.
 .
 opengnb support platform: Linux FreeBSD OpenBSD OpenWRT Raspberrypi macOS
 .
 opengnb use UDP by default, It can also use TCP, but need to install
 gnb_udp_over_tcp another. see https://github.com/gnbdev/gnb_udp_over_tcp

This package is very easy to setup one big VPN. The net speed is excellent.
It depend libminiupnpc17 package.

I'm using it now.I need a sponsor.

Bug#1002976: installation-reports: Installer Fault Accessibility No Screen Reader Heard

[D.J.J. Ring, Jr.]

Yes, I said that, but I am under the impression that whatever went wrong
happened before partitions were mounted.

I remembered using that advance menu configuration which I was unable to
find in Bullseye  - at least the same exact thing with the ability of
obtaining an IP address and downloading files.  I thought these files were
lost if the logs weren't sent to a web server or written during
installation to a mounted hard drive.

No errors are ever seen or heard - except that there is no sound after the
installer probes for sound card (press enter if this is your sound card,
etc.).

I'm going to install Bullseye once again because right now I have Buster -
but the sound is working in Buster and the screen readers orca and console
are both working. and sound from videos in the browser are all working.
Now if I can only get this in Bullseye.

Is there anything I can run while I have this installed?  I'm going to wait
for your response, it's past midnight on the Continent and 2000 hours here
on the east coast USA.  Also any suggestion of what to install thjat might
be more helpful?  Maybe the daily SID installer?

Best wishes,
David


On Mon, Jan 3, 2022 at 8:35 PM Samuel Thibault  wrote:

> D.J.J. Ring, Jr., le lun. 03 janv. 2022 20:26:54 -0500, a ecrit:
> > You mean take a video of the screen when I am trying to install Bullseye?
>
> Yes.
>
> > I don't get any error messages at all, it just doesn't speak to me.
>
> At some point you mentioned some errors:
>
> “the errors precede writing to disk.”
>
> Samuel
>

Bug#1003100: src:debugedit: please drop gcc-driver.diff patch

[David (Plasma) Paul]

Source: debugedit
Version: 1:5.0-4
Severity: minor

Dear Maintainer,

Please drop the 'gcc-driver.diff' debian patch from the debugedit
source package. The patch breaks testsuite tests 6, 7, 11, 14, 18, and
23, all of which involve partial linking[1], when compiling on an
oldstable Debian 10 Buster system with its gcc-8 compiler and ld version
2.31.1 linker. Additionally the patch just seems to be arbitrary and
incorrect.

[1] Test 19 is the only other test involving partial linking, but it is
skipped by default.

-- 
Plasma

Bug#1002982: elpa-org: post-installation script subprocess returned error exit status 1

[Sean Whitton]

control: reopen -1

Hello Gregory,

On Mon 03 Jan 2022 at 10:09pm +01, Gregory Mounie wrote:

> Thanks for the addition of org-version.el but I suspect another bug
> still exist in the auto-generation of the file:
>
> The org-version and org-git-version strings in
> /usr/share/emacs/site-lisp/elpa-src/org-9.5.2/org-version.el are both
> "N/A".
>
> It should probably be respectively something like "9.5.2" and
> "9.5.2-gfbff08" (values taken from a local user install of the package
> from elpa)

I don't know why piuparts on my system isn't finding these bugs.

Thanks for the report.  I think I know how to fix it.

-- 
Sean Whitton

Bug#1002976: installation-reports: Installer Fault Accessibility No Screen Reader Heard

[Samuel Thibault]

D.J.J. Ring, Jr., le lun. 03 janv. 2022 20:26:54 -0500, a ecrit:
> You mean take a video of the screen when I am trying to install Bullseye?

Yes.

> I don't get any error messages at all, it just doesn't speak to me.

At some point you mentioned some errors:

“the errors precede writing to disk.”

Samuel

Bug#1003021: x11-utils: luit - please upgrade

[Thomas Dickey]

On Sun, Jan 02, 2022 at 03:56:58PM -0500, Thomas Dickey wrote:
> Package: x11-utils
> Version: 7.7+5
> Severity: normal
...
>  a) modify x11-utils, making its copy of luit configurable via
> the alternatives feature (renaming it to "luit1", accessed as "luit")

I've implemented that here:

https://salsa.debian.org/dickey/x11-utils/-/commit/bcf8729a50c5034875526b05380b4abbab539836

> 
>  b) to provide an up-to-date package for luit as "luit2", also
> of course configurable via the alternatives feature.

as well as this, here:

https://salsa.debian.org/dickey/luit/-/commit/087e3504e384915244a06e39bfbcaf7524ad4faa

>  c) After some time, the copy in x11-utils can be replaced by a
> "recommends".
> 
>  Incidentally, doing this would fix #816289
> 
> The point of this bug report is to get feedback on "a" (modify x11-utils).

:-)

-- 
Thomas E. Dickey 
https://invisible-island.net
ftp://ftp.invisible-island.net


signature.asc
Description: PGP signature

Bug#1002976: installation-reports: Installer Fault Accessibility No Screen Reader Heard

[D.J.J. Ring, Jr.]

Samuel,

You mean take a video of the screen when I am trying to install Bullseye?

I don't get any error messages at all, it just doesn't speak to me.

Regards,

David

On Mon, Jan 3, 2022 at 7:03 PM Samuel Thibault  wrote:

> I'd like to emphasize this:
>
> john doe, le lun. 03 janv. 2022 09:39:41 +0100, a ecrit:
> > - As far as I understand it, everything is working fine on Buster but
> > not on Bullseye, tarring the logs from a Buster installation and from
> > Bullseye might give us some clues on where this is failing.
>
> Yes, please do this, that should be extremely informative.
>
> Any error message from the kernel will be visible in there.
>
> Possibly there are some error messages from alsa itself, which may not
> be there. Possibly you could use a smartphone to make a recording of the
> screen while you are booting the bullseye installer, so we can see which
> error messages you get there?
>
> Samuel
>

Bug#1003098: joe: fix crash at encoding prompt

[gregor herrmann]

Package: joe
Version: 4.6-1
Severity: normal
Tags: upstream patch
X-Debbugs-Cc: z...@debian.org

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Upstream has a fix in their repo for the annoying segfault in the
encoding prompt (Ctrl-t e   BOOM).

https://sourceforge.net/p/joe-editor/bugs/391/
https://sourceforge.net/p/joe-editor/mercurial/ci/72ca4cecf0aef6348287f5541c03c5a34c87226c/

Attached is a debdiff (trivial import of the commit as a quilt patch)
which fixes the issue for me.

Please consider adding this patch until a new upstream version is
released.

Cheers,
gregor


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

Kernel: Linux 5.10.0-8-amd64 (SMP w/4 CPU threads)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=C, LC_CTYPE=de_AT.utf8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)
LSM: AppArmor: enabled

Versions of packages joe depends on:
ii  libc6  2.33-1
ii  libtinfo6  6.3-1

joe recommends no packages.

joe suggests no packages.

- -- no debconf information

-BEGIN PGP SIGNATURE-

iQKTBAEBCgB9FiEE0eExbpOnYKgQTYX6uzpoAYZJqgYFAmHTmrlfFIAALgAo
aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldEQx
RTEzMTZFOTNBNzYwQTgxMDREODVGQUJCM0E2ODAxODY0OUFBMDYACgkQuzpoAYZJ
qgbbyRAAglpD9v5aSY70hpknZ3M4lMLxGPEfXyvhkPOK7RV80Sp3+m6482AHwZ8f
PQt9KzG3+6LD4RgSu2FuW6jNSxH4u5nJA1Wz5MuuPmMdcjc9ylwyPBvfkniJf2Mw
gCR69Lzt2Sct2kyt/SCl1xV2eXRckOLTyMNXMXmWsvNP6UiE8LwK7n/NFI+lSv+d
PAeBTK7Hyi2749WeIDSg5lnML/gK1DTGVrFaiOtNwvqgIi/3meetnwTD66Szze5u
g/PQwi831Ai+z1jsA5zhevz/f5gRuPZFz4UOFvo5oom7D6k9mZyJHW1e4skI6iA/
6A82bkbkVckfCpQySWzhUumT3bxoarHO648RvI3kBxKIG1CkWDdG+2ySs9I8Panb
NNfuDIRECqe76CWzF5vV05OnEIKNeTfZoviqoM8k1OLz4ioNAb+Qo0KbD9G8totL
jkrXSw6iJWMZBne7bCwchXl32YvdMCwDw1vJPSwtmEHhVtmJlkQL/Y5Dc8VFq6QE
lez3gs7JiuEBJ8H5DP7fJgwO3h60+QRPXb8szq6JkW2XmhlkzFyerFRWvFOffslq
G161BZco28H350wXWJK/NegMVXiW5R/3pY2VD9YaN3JSCUo+nok37aXAKxwZ0Y/o
Xnls/zVuBBG0KLIc/2hVdhjAgAYDol3+DU6mFZo8HoCK2Mjby6Q=
=nrjn
-END PGP SIGNATURE-
diff -Nru joe-4.6/debian/changelog joe-4.6/debian/changelog
--- joe-4.6/debian/changelog2018-02-17 21:10:49.0 +0100
+++ joe-4.6/debian/changelog2022-01-04 01:46:39.0 +0100
@@ -1,3 +1,10 @@
+joe (4.6-1.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Add patch from upstream repo to fix crash at encoding prompt.
+
+ -- gregor herrmann   Tue, 04 Jan 2022 01:46:39 +0100
+
 joe (4.6-1) unstable; urgency=low
 
   * New upstream version, closes: #887435.
diff -Nru joe-4.6/debian/patches/005_crash_encoding_completion.patch 
joe-4.6/debian/patches/005_crash_encoding_completion.patch
--- joe-4.6/debian/patches/005_crash_encoding_completion.patch  1970-01-01 
01:00:00.0 +0100
+++ joe-4.6/debian/patches/005_crash_encoding_completion.patch  2022-01-04 
01:46:34.0 +0100
@@ -0,0 +1,59 @@
+Description: Fix "Completion at encoding prompt crashes"
+Origin: 
https://sourceforge.net/p/joe-editor/mercurial/ci/72ca4cecf0aef6348287f5541c03c5a34c87226c/
+Bug: https://sourceforge.net/p/joe-editor/bugs/391/
+
+--- a/joe/options.c
 b/joe/options.c
+@@ -1011,7 +1011,7 @@
+   /* Load first from global (NOTE: Order here does not matter.) */
+   if (!chpwd(buf) && (t = rexpnd(wildcard))) {
+   for (x = 0; x < aLEN(t); ++x) {
+-  *zrchr(t[x], '.') = 0;
++  if (extension) *zrchr(t[x], '.') = 0;
+   for (y = 0; y < aLEN(ary); ++y)
+   if (!zcmp(t[x], ary[y]))
+   break;
+@@ -1020,6 +1020,7 @@
+   }
+ 
+   varm(t);
++  t = NULL;
+   }
+   }
+ 
+@@ -1031,7 +1032,7 @@
+ 
+   if (!chpwd(buf) && (t = rexpnd(wildcard))) {
+   for (x = 0; x < aLEN(t); ++x) {
+-  *zrchr(t[x],'.') = 0;
++  if (extension) *zrchr(t[x],'.') = 0;
+   for (y = 0; y < aLEN(ary); ++y)
+   if (!zcmp(t[x],ary[y]))
+   break;
+@@ -1040,6 +1041,7 @@
+   }
+ 
+   varm(t);
++  t = NULL;
+   }
+   }
+   }
+@@ -1050,7 +1052,7 @@
+   t = jgetbuiltins(wildcard);
+ 
+   for (x = 0; x < aLEN(t); ++x) {
+-  *zrchr(t[x], '.') = 0;
++  if (extension) 

Bug#1003097: parallel.1: document the shell/non-shell usage of command execution

[Paul Wise]

Package: moreutils
Version: 0.66-1
Severity: wishlist
File: /usr/share/man/man1/parallel.1.gz

For the moreutils implementation of parallel:

I noticed that the first form of command does not use the shell:

   parallel [options] [command] -- [argument ...]

I noticed that the second form of command *does* use the shell:

   parallel [options] -- [command ...]

Please document both of these in the manual page, so that folks know
that they should not quote commands passed in the first form but always
shell-quote commands passed in the second form.

-- System Information:
Debian Release: bookworm/sid
  APT prefers testing-debug
  APT policy: (900, 'testing-debug'), (900, 'testing'), (800, 
'unstable-debug'), (800, 'unstable'), (790, 'buildd-unstable'), (700, 
'experimental-debug'), (700, 'experimental'), (690, 'buildd-experimental')
Architecture: amd64 (x86_64)

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

Versions of packages moreutils depends on:
ii  libc6  2.33-1
ii  libipc-run-perl20200505.0-1
ii  libtime-duration-perl  1.21-1
ii  libtimedate-perl   2.3300-2
ii  perl   5.32.1-6

moreutils recommends no packages.

moreutils suggests no packages.

-- no debconf information

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


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

Bug#1002976: installation-reports: Installer Does Not Provide Screen Reader in Accessible Installation

[Samuel Thibault]

One thing possibly worth noting is this:

Jan  3 12:58:44 kernel: [1.769085] snd_hda_codec_realtek hdaudioC1D0: 
ALC888: SKU not ready 0x0100
Jan  3 12:58:44 kernel: [1.769627] snd_hda_codec_realtek hdaudioC1D0: 
autoconfig for ALC888: line_outs=4 (0x14/0x16/0x15/0x17/0x0) type:line
Jan  3 12:58:44 kernel: [1.769631] snd_hda_codec_realtek hdaudioC1D0:
speaker_outs=0 (0x0/0x0/0x0/0x0/0x0)
Jan  3 12:58:44 kernel: [1.769633] snd_hda_codec_realtek hdaudioC1D0:
hp_outs=1 (0x1b/0x0/0x0/0x0/0x0)
Jan  3 12:58:44 kernel: [1.769634] snd_hda_codec_realtek hdaudioC1D0:
mono: mono_out=0x0
Jan  3 12:58:44 kernel: [1.769636] snd_hda_codec_realtek hdaudioC1D0:
dig-out=0x1e/0x0
Jan  3 12:58:44 kernel: [1.769637] snd_hda_codec_realtek hdaudioC1D0:
inputs:
Jan  3 12:58:44 kernel: [1.769638] snd_hda_codec_realtek hdaudioC1D0:  
Rear Mic=0x18
Jan  3 12:58:44 kernel: [1.769640] snd_hda_codec_realtek hdaudioC1D0:  
Front Mic=0x19
Jan  3 12:58:44 kernel: [1.769641] snd_hda_codec_realtek hdaudioC1D0:  
Line=0x1a
Jan  3 12:58:44 kernel: [1.769642] snd_hda_codec_realtek hdaudioC1D0:  
CD=0x1c

I don't know what this really means, though.

Samuel

Bug#1002976: installation-reports: Installer Does Not Provide Screen Reader in Accessible Installation

[Samuel Thibault]

Hello,

David J. Ring, Jr., le lun. 03 janv. 2022 14:18:39 -0500, a ecrit:
[-- Attachement #2: installer.tar.gz --]
[-- Type: application/gzip, Encoding: base64, Size: 6,4M --]

Could you do the same with a Buster installer, so we can spot the
differences?

Samuel

Bug#1002976: installation-reports: Installer Fault Accessibility No Screen Reader Heard

[Samuel Thibault]

I'd like to emphasize this:

john doe, le lun. 03 janv. 2022 09:39:41 +0100, a ecrit:
> - As far as I understand it, everything is working fine on Buster but
> not on Bullseye, tarring the logs from a Buster installation and from
> Bullseye might give us some clues on where this is failing.

Yes, please do this, that should be extremely informative.

Any error message from the kernel will be visible in there.

Possibly there are some error messages from alsa itself, which may not
be there. Possibly you could use a smartphone to make a recording of the
screen while you are booting the bullseye installer, so we can see which
error messages you get there?

Samuel

Bug#974174: man.1: Add a reference to "man-pages(7)" to the manual

[Colin Watson]

Control: severity -1 wishlist
Control: tag -1 fixed-upstream

On Wed, Nov 11, 2020 at 01:13:15AM +, Bjarni Ingi Gislason wrote:
>   add a reference to "man-pages(7)"
>  (man-pages - conventions for writing Linux man pages)
>  to the man(1) manual.
> 
>   For example in the paragraph
> 
>   7   Miscellaneous (including macro packages and conventions), e.g.
>   man(7), groff(7)

OK, fixed for the next upstream release:

  
https://gitlab.com/cjwatson/man-db/-/commit/6df671bf23eefeee8fef5fc99516e99d5f37e015

-- 
Colin Watson (he/him)  [cjwat...@debian.org]

Bug#965679: ..

[Martina Ferrari]

Somehow I had missed this bug report. I will prepare a new upload ASAP.

--
Martina Ferrari (Tina)

Bug#941622: man-db: man(1) manpage does not mention MAN_DISABLE_SECCOMP=1 environment variable

[Colin Watson]

Control: tag -1 fixed-upstream

On Thu, Oct 03, 2019 at 03:16:08AM +0200, Matija Nalis wrote:
> man1/man.1.gz manpage should document all enviroment variables it uses.
> It includes:
> 
> - MAN_DISABLE_SECCOMP=1
> - PIPELINE_DEBUG=1
> 
> Those are usually only used for debugging, but so is MAN_KEEP_STDERR, which
> is correctly documented in man(1) manpage. Having them 
> undocumented/unmentioned 
> makes a life much more complicated for casual bug reporter, and sysadmins 
> trying 
> to troubleshoot apparmor/seccomp related bugs.

Thanks, fixed for the next upstream release:

  
https://gitlab.com/cjwatson/man-db/-/commit/877bb58741a7d370aca0524370dfe59a70c1a064

-- 
Colin Watson (he/him)  [cjwat...@debian.org]

Bug#1003096: grub-pc: upgrade-from-grub-legacy does not work on two systems in bullseye

[CJ Fearnley]

Package: grub-pc
Version: 2.04-20
Severity: normal

Dear Maintainer,

I am seeing the double chain loading of the old grub legacy which
successfully loads the modern grub.

Evidently, I forgot to run upgrade-from-grub-legacy on some systems
10 years ago. Or maybe it failed to work 10 years ago and I'm only now
noticing (since I've had to do a lot of reboots to fix other things that
broke in Bullseye).

On two systems I tried to run upgrade-from-grub-legacy in Bullseye. The
program appears to run, but the double chain loading of the old grub
continues. I infer that it did not work.

If the program cannot be run any more, then it should be removed from the
package.

If a solution can be offered to those of us who didn't pay close enough
attention to an upgrade 8 years ago, then, perhaps, the program can
be fixed.

Here are the run-time messages from upgrade-from-grub-legacy:

$ sudo upgrade-from-grub-legacy

core.img doesn't exist, trying to create it.

Installing for i386-pc platform.
Installation finished. No error reported.
dpkg: warning: version 'dummy-version' has bad syntax: version number does not 
start with digit
Configuring grub-pc
---

The grub-pc package is being upgraded. This menu allows you to select which 
devices you'd like
grub-install to be automatically run for, if any.

Running grub-install automatically is recommended in most situations, to 
prevent the installed
GRUB core image from getting out of sync with GRUB modules or grub.cfg.

If you're unsure which drive is designated as boot drive by your BIOS, it is 
often a good idea to
install GRUB to all of them.

Note: it is possible to install GRUB to partition boot records as well, and 
some appropriate
partitions are offered here. However, this forces GRUB to use the blocklist 
mechanism, which makes
it less reliable, and therefore is not recommended.

  1. /dev/md0 (1995264 MB; precession:0)3. /dev/sdb (2000398 MB; 
ST2000DM008-2FR102)
  2. /dev/sda (2000398 MB; WDC_WD2002FAEX-00MJRA0)  4. /dev/dm-0 (74998 MB; 
precession-root)

(Enter the items or ranges you want to select, separated by spaces.)

GRUB install devices: 2 3


Installing for i386-pc platform.
File descriptor 3 (pipe:[239103]) leaked on vgs invocation. Parent PID 66419: 
grub-install
File descriptor 3 (pipe:[239103]) leaked on vgs invocation. Parent PID 66419: 
grub-install
File descriptor 3 (pipe:[239103]) leaked on vgs invocation. Parent PID 66419: 
grub-install
Installation finished. No error reported.
Installing for i386-pc platform.
File descriptor 3 (pipe:[239103]) leaked on vgs invocation. Parent PID 66455: 
grub-install
File descriptor 3 (pipe:[239103]) leaked on vgs invocation. Parent PID 66455: 
grub-install
File descriptor 3 (pipe:[239103]) leaked on vgs invocation. Parent PID 66455: 
grub-install
Installation finished. No error reported.
Generating grub configuration file ...
Found linux image: /boot/vmlinuz-5.10.0-10-amd64
Found initrd image: /boot/initrd.img-5.10.0-10-amd64
Found linux image: /boot/vmlinuz-4.19.0-18-amd64
Found initrd image: /boot/initrd.img-4.19.0-18-amd64
done

GRUB Legacy has been removed, but its configuration files have been preserved,
since this script cannot determine if they contain valuable information.  If
you would like to remove the configuration files as well, use the following
command:

  rm -f /boot/grub/menu.lst*

But after I reboot I continue to see the old GRUB with fd0 errors before
the new modern grub successfully works.

The other system I tried this on had the same behavior: I still get
the old GRUB legacy splash screen before the new grub chain loads and
successfully boots the system.

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


-- Package-specific info:

*** BEGIN /proc/mounts
/dev/mapper/precession-root / ext4 rw,relatime,errors=remount-ro 0 0
/dev/mapper/precession-tmp /tmp ext2 rw,relatime 0 0
/dev/mapper/precession-var /var ext4 rw,relatime 0 0
/dev/mapper/precession-home /home ext4 rw,relatime 0 0
/dev/mapper/precession-storage2013 /storage ext4 rw,relatime,stripe=32751 0 0
*** END /proc/mounts

*** BEGIN /boot/grub/device.map
(hd0)   /dev/disk/by-id/ata-WDC_WD2002FAEX-00MJRA0_WD-WCC1P1012992
(hd1)   /dev/disk/by-id/ata-WDC_WD2002FAEX-00MJRA0_WD-WCC1P0987331
(hd2)   /dev/disk/by-id/usb-SanDisk_Cruzer_20035001811619024B88-0:0
*** END /boot/grub/device.map

*** BEGIN /boot/grub/grub.cfg
#
# DO NOT EDIT THIS FILE
#
# It is automatically generated by grub-mkconfig using templates
# from /etc/grub.d and settings from /etc/default/grub
#

### BEGIN /etc/grub.d/00_header ###
if [ -s $prefix/grubenv ]; then
  set have_grubenv=true
  load_env
fi
if [ "${next_entry}" ] ; then
   set default="${next_entry}"
   set next_entry=
   save_env next_entry
   set boot_once=true
else
   set default="0"
fi

if [ x"${feature_menuentry_id}" = xy ]; then
  menuentry_id_option="--id"
else
  

Bug#1003089: man-db has become prohibitively slow

[Colin Watson]

On Mon, Jan 03, 2022 at 08:34:46PM +0100, Steinar H. Gunderson wrote:
> I've noticed that during upgrades to bullseye, the man-db trigger now seems to
> take a very long time; in fact, it frequently seems to be a significant time 
> of
> the total time of the full-upgrade (depending, of course, on network speeds).
> 
> After digging a bit, I think I've figured out why I haven't seen this before;
> it's become a _lot_ slower recently, so it wasn't on the radar before. It 
> seems
> that due to a combination of the architecture chosen for these operations
> (a pipeline system, seemingly forking off subprocesses and running lots of
> syscalls in the process)

This part is already covered in https://bugs.debian.org/696503.  I admit
that this was last updated ten years ago; I really need to get back to
that and get it to work one way or another. :-/

> and a new sandbox model (based on seccomp, which needs a lot of setup
> for each new subprocess and adds considerable overhead to each
> syscall),

This is an interesting observation.  I do think that seccomp is valuable
defence in general given the amount of rather ad-hoc parsing that's
going on, but I hadn't noticed that it made such a big difference to
mandb performance.  (About 3ms per subprocess here purely for setup, I
think.)

The seccomp sandbox is mainly so that man-db can more safely operate on
manual pages shipped by packaging systems that expect to run code under
confinement and thus can ship relatively untrusted code (such as snapd).
If we limited the mandb invocation in the postinst to only
/usr/share/man, we could reasonably assume that all pages there were
installed by dpkg, and those don't need the same level of care since any
package installed by dpkg can run code directly as root anyway.  It
would then be reasonable to run it under MAN_DISABLE_SECCOMP=1.

This limitation would make apropos a bit less useful for third-party
packages installed by dpkg that ship manual pages under something like
/opt/*/man, but those are relatively rare, and the existing cron job /
systemd timer will catch up later so it wouldn't be fatal to make such
cases a little less ergonomic.

> As an example, a complete mandb run (mandb -c) on my laptop takes 3 minutes 
> and
> 39 seconds. (Of course, the man-db trigger is incremental, but on a 
> full-upgrade,
> many man pages are likely to be updated.) If I set MAN_DISABLE_SECCOMP=1,
> it drops to 1:41. If I recompile without HAVE_LIBSECCOMP, it's down to 51 
> seconds!

The difference between MAN_DISABLE_SECCOMP=1 and building without
libseccomp looks like a relatively simple fix, at least:

  
https://gitlab.com/cjwatson/man-db/-/commit/50200d151dfedb9d5064ec7008c09f6cf0f5ee24

Results on my system for "mandb -c /usr/share/man", roughly confirming
your findings:

  status quo:5m08s
  MAN_DISABLE_SECCOMP=1: 2m12s
  MAN_DISABLE_SECCOMP=1 plus 50200d151d: 1m17s

> I don't honestly know what this database is for, but my guess is that it is
> for the apropos command, which seems rare. (At least nothing obviously bad
> happens to my man usage if I “rm -r /var/cache/man/*”, but apropos stops 
> working.)
> Is it possible to either speed up man-db so that it takes less time to build
> its database, or otherwise perhaps split apropos out into a separate
> not-installed-by-default package, so that normal installations do not need to
> take this installation hit? Or maybe move man-db updating to cron?

I really don't want to make apropos less useful.  I'll have another go
at tackling the core problem here; but the fixes described above should
at least get us back to merely the situation we've had for years, rather
than the (as you say) much worse behaviour recently.

Given #696503, would you mind if I repurposed this bug to be just about
fixing the seccomp-related performance regression?  I think the plan
above will let me deal with just that part of it relatively quickly, and
the fixes would be small enough to be viable candidates for stable.

-- 
Colin Watson (he/him)  [cjwat...@debian.org]

Bug#1002575: iwd: Doesn't create global config file or its directory (/etc/iwd/)

[Diederik de Haas]

Hi Jonas,

On Monday, 27 December 2021 19:27:29 CET Diederik de Haas wrote:
> Control: forwarded -1
> https://lists.01.org/hyperkitty/list/i...@lists.01.org/thread/ZP5J2JEPF4YPOM
> H6XG6VUV2GYNAHCPXF/
> On Friday, 24 December 2021 16:48:57 CET Jonas Smedegaard wrote:
> > I agree that it would be helpful if the iwd package included a
> > system-wide default config file, even if containing only commented out
> > sample entries.
> > 
> > Do you want to suggest it to upstream?
> 
> Done at the forwarded address/URL.

Got a reply on that list [1] that the following commit was added:
https://git.kernel.org/pub/scm/network/wireless/iwd.git/commit/?id=04fccea63bd42b0b72587df9edee72d677b6ca7d

And then the following question which you should determine:
"Let us know if this is what the Debian package maintainer had in mind."

[1] 
https://lists.01.org/hyperkitty/list/i...@lists.01.org/message/C3UZVER6K4ORGTRXX4ICLIWY7PX23FKI/

Cheers,
  Diederik


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

Bug#1003094: slt: Missing systemd service

[Lars Kruse]

Package: slt
Version: 0.0.git20140301-6+b3
Severity: normal
Tags: patch

Dear Maintainer,

currently the stl package lacks a systemd service.
Attached you find one.

The service contains my specific execution restrictions.
Thus should help working around slt's lack of priviledge dropping.

The systemd service is written by Konrad Mohrfeldt (kmo...@systemausfall.org)
and released under the public domain.  Feel free to re-license it.

Cheers,
Lars
[Unit]
Description=TLS port multiplexer
ConditionPathExists=/etc/slt/%i.yaml
Wants=network.target

[Service]
Type=simple
ExecStart=/usr/bin/slt /etc/slt/%i.yaml
Restart=on-failure

# Use systemd's ability to disable security-sensitive features
# that slt does not explicitly need.
NoNewPrivileges=True
# slt only needs to bind to privileged ports, nothing else
# see: https://man7.org/linux/man-pages/man7/capabilities.7.html
CapabilityBoundingSet=CAP_NET_BIND_SERVICE
# slt only executes native code with no need for any other ABIs.
SystemCallArchitectures=native
# Only allow system calls required by slt.
# see: 
https://www.freedesktop.org/software/systemd/man/systemd.exec.html#SystemCallFilter=
# This should suffice, but doesn't work:
# SystemCallFilter=@basic-io @ipc @io-event @network-io @process @signal
SystemCallFilter=@system-service
SystemCallFilter=~@resources @aio @chown @cpu-emulation @debug @memlock 
@keyring @module @mount @obsolete @privileged @raw-io @reboot @setuid @swap 
@sync @timer
# ProtectSystem=strict disables write calls to the entire filesystem hierarchy, 
# leaving only /dev/, /proc/, and /sys/ writable.
# slt doesn't need access to those so might as well disable them.
ProtectSystem=strict
PrivateDevices=True
ProtectControlGroups=True
ProtectKernelTunables=True
# Make /home/, /root/, and /run/user/ inaccessible.
ProtectHome=True
# slt doesn't handle any specific device nodes
# so we only allow common paths like /dev/null or /dev/random.
DevicePolicy=closed
# slt doesn't make use of linux namespaces.
RestrictNamespaces=True
# slt doesn't need realtime scheduling.
RestrictRealtime=True
# Make sure files created by slt are only readable by itself and
# others in the slt system group.
UMask=0027
# Disable memory mappings that are both writable and executable.
MemoryDenyWriteExecute=True
# slt doesn't make use of linux personality switching.
LockPersonality=True
# slt only needs to support the IPv4 and IPv6 address families.
RestrictAddressFamilies=AF_INET AF_INET6
# slt doesn't need to load any linux kernel modules.
ProtectKernelModules=True

[Install]
WantedBy=multi-user.target

Bug#988596: akonadi-server: bug still exists

[Karsten Hilbert]

Package: akonadi-server
Version: 4:20.08.3-3
Followup-For: Bug #988596


Dear Maintainers,

after an apt full-upgrade from Buster to Bullseye akonadiserver now has an
apparmor profile. That profile seems to prevent it from starting up, as
witnessed by DENY messages in the system log.

Likely, this happens because I have relocated home dirs:

<-->/home/
<--><-->user1 -link-> /somewhere/else/home.user1/
<--><-->user2 -link-> /somewhere/else/home.user2/
<--><-->...

and apparmor seems to not consider the link location as allowed via the
"@xdg_data_home/akonadi/" rules.

For the time being I have set the profile to complain mode but what is
the suggested way forward ?

Thanks,
Karsten


-- System Information:
Debian Release: 11.2
  APT prefers stable
  APT policy: (990, 'stable'), (500, 'unstable-debug'), (500, 
'stable-updates'), (500, 'testing')
Architecture: i386 (i686)

Kernel: Linux 5.15.0-2-686-pae (SMP w/2 CPU threads)
Kernel taint flags: TAINT_UNSIGNED_MODULE
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.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 akonadi-server depends on:
ii  akonadi-backend-mysql4:20.08.3-3
ii  akonadi-backend-postgresql   4:20.08.3-3
ii  libaccounts-qt5-11.16-2
ii  libc62.33-1
ii  libgcc-s110.2.1-6
ii  libkf5akonadiprivate5abi2 [libkf5akonadiprivate5-20.08]  4:20.08.3-3
ii  libkf5akonadiwidgets5abi1 [libkf5akonadiwidgets5-20.08]  4:20.08.3-3
ii  libkf5configcore55.78.0-4
ii  libkf5coreaddons55.78.0-4
ii  libkf5crash5 5.78.0-3
ii  libkf5i18n5  5.78.0-2
ii  libqt5core5a 5.15.2+dfsg-9
ii  libqt5dbus5  5.15.2+dfsg-9
ii  libqt5gui5   5.15.2+dfsg-9
ii  libqt5network5   5.15.2+dfsg-9
ii  libqt5sql5   5.15.2+dfsg-9
ii  libqt5widgets5   5.15.2+dfsg-9
ii  libqt5xml5   5.15.2+dfsg-9
ii  libstdc++6   10.2.1-6

akonadi-server recommends no packages.

Versions of packages akonadi-server suggests:
ii  akonadi-backend-mysql   4:20.08.3-3
ii  akonadi-backend-postgresql  4:20.08.3-3
pn  akonadi-backend-sqlite  

-- no debconf information

Bug#1003093: mailgraph: leftover tag in mailgraph.cgi

[Vincent Lefevre]

Package: mailgraph
Version: 1.14-17
Severity: minor

In the past, the CSS styles were included in the mailgraph.cgi file
(located in /usr/share/mailgraph). They have been moved to a separate
mailgraph.css file, and they are now loaded with



In this change, the  tag and the styles were
removed, but not the closing  tag.

This closing  tag should be removed too.

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

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

Versions of packages mailgraph depends on:
ii  debconf [debconf-2.0]  1.5.77
ii  libfile-tail-perl  1.3-6
ii  librrds-perl   1.7.2-3+b7
ii  lsb-base   11.1.0
ii  perl   5.32.1-4+deb11u2
ii  ucf3.0043

Versions of packages mailgraph recommends:
ii  apache2 [httpd] 2.4.51-1~deb11u1
ii  postfix [mail-transport-agent]  3.5.6-1+b1

mailgraph suggests no packages.

-- debconf information excluded

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

Bug#1003092: RFP: vim-bracketed-paste -- plugin to handle bracketed-paste-mode in vim

[Joseph Nahmias]

Package: wnpp
Severity: wishlist
X-Debbugs-Cc: j...@nahmias.net, team+...@tracker.debian.org

* Package name: vim-bracketed-paste
* URL : https://github.com/ConradIrwin/vim-bracketed-paste
* License : MIT
  Programming Lang: VIM
  Description : plugin to handle bracketed-paste-mode in vim

vim-bracketed-paste enables transparent pasting into vim.
(i.e. no more :set paste!)
Requires a modern xterm-compatible terminal emulator that supports bracketed
paste mode. xterm, urxvt, iTerm2, gnome-terminal (and other terminals using
libvte) are known to work.

Bug#1001168: Info received (Bug#1001168: Info received (Bug#1001168: hkl: FTBFS on mipsel: FAIL: trajectory.py))

[PICCA Frederic-emmanuel]

Built with gcc-11 and -fno-lto it doesn not work.

(sid_mips64el-dchroot)picca@eller:~/matplotlib/build/lib.linux-mips64-3.9$ 
../../../test.py 
Segmentation fault
(sid_mips64el-dchroot)picca@eller:~/matplotlib/build/lib.linux-mips64-3.9$ 
PYTHONPATH=. ../../../test.py 
Segmentation fault

Bug#1003071: logs

[Heenec]

And again...


bugreport_nouveau_syslog.txt.xz
Description: application/xz

Bug#998534: intel-gpu-tools: FTBFS: ../lib/meson.build:155:4: ERROR: Function does not take positional arguments.

[Páder Rezső]

Hello,

FYI, this error is fixed in upstream git:

https://gitlab.freedesktop.org/drm/igt-gpu-tools/-/commit/963917a3565466832a3b2fc22e9285d34a0bf944

-- 
R.

Bug#1003071: logs

[heenec]

Oops, trying to send the file again.

Bug#1003091: xwayland: Xwayland uses glamor and shows black screens

[Gert van de Kraats]

Package: xwayland
Version: 2:21.1.4-1
Severity: important
Tags: upstream

Dear Maintainer,

I am using graphics:
00:00.0 Host bridge: Intel Corporation Mobile 945GM/PM/GMS, 943/940GML and
945GT Express Memory Controller Hub (rev 03)
Subsystem: Dell Mobile 945GM/PM/GMS, 943/940GML and 945GT Express
Memory Controller Hub
00:02.0 VGA compatible controller: Intel Corporation Mobile 945GM/GMS,
943/940GML Express Integrated Graphics Controller (rev 03)
Subsystem: Dell Mobile 945GM/GMS, 943/940GML Express Integrated
Graphics Controller
Kernel driver in use: i915
Kernel modules: i915
00:02.1 Display controller: Intel Corporation Mobile 945GM/GMS/GME, 
943/940GML

Express Integrated Graphics Controller (rev 03)
Subsystem: Dell Mobile 945GM/GMS/GME, 943/940GML Express Integrated
Graphics Controller

It is intel gen 3 and supports GL1.4 and ES2.0.

At Debian (testing) Bookworm this recently was working without problem,
using ES2.0 hardware driver at Wayland and automatically
galamor was disabled and the llvmpipe software driver at Xwayland
wa selected, because version GL1.4 is too low.
The latest Xwayland package now tries to use ES2.0 with glamor at
Xwayland. This causes blackscreen (Java8, Chromium), xeyes and not working
es2_info end glxinfo.
Errors at startup of user session at syslog:
Jan 2 01:27:47 debian org.gnome.Shell.desktop[9925]: Supported GL version is
not sufficient (required 21, found 14)
Jan 2 01:27:47 debian org.gnome.Shell.desktop[9925]: (EE) glamor0: GL error:
GL_INVALID_VALUE in glTexImage2D(internalFormat=GL_R8)
Jan 2 01:27:47 debian org.gnome.Shell.desktop[9925]: (EE)
Jan 2 01:27:47 debian org.gnome.Shell.desktop[9925]: (EE) Backtrace:
Jan 2 01:27:47 debian dbus-daemon[528]: [system] Activating via systemd:
service name='org.freedesktop.realmd' unit='realmd.service' requested by
':1.492' (uid=117 pid=9895 comm="/usr/bin/gnome-shell ")
Jan 2 01:27:47 debian systemd[1]: Starting Realm and Domain Configuration...
Jan 2 01:27:48 debian org.gnome.Shell.desktop[9925]: (EE) 0: 
/usr/bin/Xwayland

(0x4b9000+0x161813) [0x61a813]
Jan 2 01:27:48 debian org.gnome.Shell.desktop[9925]: (EE) 1: 
/usr/bin/Xwayland

(0x4b9000+0x31596) [0x4ea596]
Jan 2 01:27:48 debian org.gnome.Shell.desktop[9925]: (EE) 2:
/usr/lib/i386-linux-gnu/dri/i915_dri.so (0xb61c4000+0x1f6175) [0xb63ba175]
Jan 2 01:27:48 debian org.gnome.Shell.desktop[9925]: (EE) 3:
/usr/lib/i386-linux-gnu/dri/i915_dri.so (0xb61c4000+0x25d5f1) [0xb64215f1]
Jan 2 01:27:48 debian org.gnome.Shell.desktop[9925]: (EE) 4:
/usr/lib/i386-linux-gnu/dri/i915_dri.so (0xb61c4000+0x31f955) [0xb64e3955]
Jan 2 01:27:48 debian org.gnome.Shell.desktop[9925]: (EE) 5:
/usr/lib/i386-linux-gnu/dri/i915_dri.so (0xb61c4000+0x320076) [0xb64e4076]
Jan 2 01:27:48 debian org.gnome.Shell.desktop[9925]: (EE) 6:
/usr/lib/i386-linux-gnu/dri/i915_dri.so (0xb61c4000+0x3225fa) [0xb64e65fa]
Jan 2 01:27:48 debian org.gnome.Shell.desktop[9925]: (EE) 7: 
/usr/bin/Xwayland

(0x4b9000+0x31758) [0x4ea758]
Jan 2 01:27:48 debian org.gnome.Shell.desktop[9925]: (EE) 8: 
/usr/bin/Xwayland

(0x4b9000+0x32d27) [0x4ebd27]
Jan 2 01:27:48 debian org.gnome.Shell.desktop[9925]: (EE) 9: 
/usr/bin/Xwayland

(0x4b9000+0x2b3cc) [0x4e43cc]
Jan 2 01:27:48 debian org.gnome.Shell.desktop[9925]: (EE) 10:
/usr/bin/Xwayland (0x4b9000+0x25eac) [0x4deeac]
Jan 2 01:27:48 debian org.gnome.Shell.desktop[9925]: (EE) 11:
/usr/bin/Xwayland (0x4b9000+0x8f759) [0x548759]
Jan 2 01:27:48 debian org.gnome.Shell.desktop[9925]: (EE) 12:
/usr/bin/Xwayland (0x4b9000+0x1f584) [0x4d8584]
Jan 2 01:27:48 debian org.gnome.Shell.desktop[9925]: (EE) 13:
/usr/bin/Xwayland (0x4b9000+0x93715) [0x54c715]
Jan 2 01:27:48 debian org.gnome.Shell.desktop[9925]: (EE) 14:
/usr/bin/Xwayland (0x4b9000+0x1ed3b) [0x4d7d3b]
Jan 2 01:27:48 debian org.gnome.Shell.desktop[9925]: (EE) 15: 
/lib/i386-linux-

gnu/libc.so.6 (__libc_start_main+0xe5) [0xb7942905]
Jan 2 01:27:48 debian org.gnome.Shell.desktop[9925]: (EE) 16:
/usr/bin/Xwayland (0x4b9000+0x1ed81) [0x4d7d81]
Jan 2 01:27:48 debian org.gnome.Shell.desktop[9925]: (EE)
Jan 2 01:27:48 debian org.gnome.Shell.desktop[9925]: glamor: Test fbo for
depth 8 incomplete. Falling back to software.
Jan 2 01:27:48 debian org.gnome.Shell.desktop[9925]: glamor: Implementation
returned 0x1908/0x8366 read format/type for depth 15, expected 
0x1908/0x8034.

Falling back to software.
Jan 2 01:27:48 debian org.gnome.Shell.desktop[9925]: glamor: Implementation
returned 0x80e1/0x1401 read format/type for depth 24, expected 
0x1908/0x1401.

Falling back to software.
Jan 2 01:27:48 debian org.gnome.Shell.desktop[9925]: glamor: Implementation
returned 0x80e1/0x1401 read format/type for depth 32, expected 
0x1908/0x1401.

Falling back to software.
Jan 2 01:27:48 debian org.gnome.Shell.desktop[9925]: (EE) glamor0: GL error:
GL_INVALID_OPERATION in glTexImage2D(format = GL_RGBA, type =
GL_UNSIGNED_INT_2_10_10_10_REV, internalformat = GL_RGB10_A2)
Jan 2 01:27:48 debian org.gnome.Shell.desktop[9925]: (EE)
Jan 2 01:27:48 debian 

Bug#1001168: Info received (Bug#1001168: hkl: FTBFS on mipsel: FAIL: trajectory.py)

[PICCA Frederic-emmanuel]

I tested matplotlib built with numpy 0.17 0.19 0.21. each time I got the 
segfault.

another difference was the gcc compiler.

So I switched to gcc-10

(sid_mips64el-dchroot)picca@eller:~/matplotlib$ CC=gcc-10 python3 setup.py build

if failed with this error

lto1: fatal error: bytecode stream in file 
‘build/temp.linux-mips64-3.9/matplotlib.backends._backend_agg/extern/agg24-svn/src/agg_bezier_arc.o’
 generated with LTO version 9.4 instead of the expected 11.2

So I unactivated lto with this 

CFLAGS="-fno-lto" CC=gcc-10 python3 setup.py build

at the end it seems that  is does not segfault :)

(sid_mips64el-dchroot)picca@eller:~/matplotlib/build/lib.linux-mips64-3.9$ 
../../../test.py 
Segmentation fault
(sid_mips64el-dchroot)picca@eller:~/matplotlib/build/lib.linux-mips64-3.9$ 
PYTHONPATH=. ../../../test.py 
(sid_mips64el-dchroot)picca@eller:~/matplotlib/build/lib.linux-mips64-3.9$ ls
matplotlib  mpl_toolkits  pylab.py  toto.png

Cheers

Bug#1002670: grub2-common: Unable to force MBR/embedding installation

[Elliott Mitchell]

On Mon, Jan 03, 2022 at 05:17:19PM +, Steve McIntyre wrote:
> 
> On Mon, Jan 03, 2022 at 08:52:48AM -0800, Elliott Mitchell wrote:
> >On Mon, Jan 03, 2022 at 02:35:48PM +, Steve McIntyre wrote:
> >> 
> >> What you're asking for here won't work; arm64 devices don't/can't use
> >> the embedding MBR/gap style of GRUB installation - that's x86 only. 
> >> Instead,
> >> what you need is to do an EFI installation but with a couple of extra
> >> options chosen. Run "dpkg-reconfigure -plow grub-efi-arm64" and say:
> >> 
> >>  * "yes" to "Force extra installation to the EFI removable media path?"
> >>  * "no" to "Update NVRAM variables to automatically boot into Debian?"
> >> 
> >> and and you should be fine from now on.
> >
> >Justify the statement "arm64 devices don't/can't use the embedding
> >MBR/gap style of GRUB installation".  I concur that is not the normal way
> >of doing EFI installation on ARM64 devices, but in this case I've got a
> >device which is unable to store persistent variables (if you sacrifice a
> >SD Card it can store them, but otherwise it loses them on restart).
> 
> The MBR/gap style is *totally specific* to the old-school x86 BIOS way
> of doing things:
> 
>  * A tiny 16-bit x86 asm loader is added into the boot sector; it uses
>BIOS routines to load the GRUB core image from the raw space after
>the partition table and execute it.
> 
>  * The core image contains enough functionality (display, filesystems,
>storage drivers, etc.) to be able to find load further modules from
>the /boot filesystem. It loads those, runs the menu, etc.
> 
> arm64 machines categorically do *not* have any capability to run this
> way. It has never been a thing. Instead, systems running GRUB will
> load GRUB as a UEFI binary from an EFI System Partition (ESP) and go
> from there. Depending on the exact installation on your system, you
> may have an ESP on removable storage (SD?), on hard drive / SSD, or
> maybe on internal eMMC or similar. It's possible you could be loading
> from the network too, but I assume you'd know if that was happening.
> 
> You have not identified the exact platform you're using, so I've no
> idea exactly which of the above options is most likely.

The platform is Tianocore built for the particular hardware.

While the hardware does have a SD controller, since there is no card
present it couldn't be loaded from there (no eMMC).  As such it is
definitely coming from what Linux sees as /dev/sda (via USB3 since that
hardware is available).

Now, since everything on the VFAT filesystem used by both the initial
stage loader and Tianocore was moved to a subdirectory, the older
version isn't coming from there (unless Tianocore does the equivalent of
a `find` during load, which seems unlikely).

As such I'm pretty sure Tianocore is finding the older GRUB by looking in
the gap between the GPT entries and data start.


> >Yet somehow despite restarting from a mostly clean slate an older
> >installation of 2.02+dfsg1-20+deb10u4 keeps managing to manifest, while
> >2.04-20 is unable to be loaded.
> >
> >My conclusion is 2.02+dfsg1-20+deb10u4 was able to successfully install
> >in the embedding area despite not being supposed to work.  Meanwhile I'm
> >guessing Tianocore/ARM64 inherited the ability to boot from the embedding
> >area, despite using that being strongly discouraged.
> 
> Nope, sorry.
> 
> >Or at least that is a simple explanation for why traces of
> >2.02+dfsg1-20+deb10u4 continue to persist, while 2.04-20 appears
> >reluctant.
> 
> My first guess would be that either:
> 
>  * You have more than one ESP on your system somewhere, and the system
>is finding an old grub binary that way; or
> 
>  * The old grub is in the removable media path and you haven't managed
>to replace it yet (see my first mail for details on how to do
>that).

The former isn't possible.  I am though wondering if use of the
"--removable" option will resolve the situation.  When it comes down to
it, all storage media is removable just an issue of how difficult it is
to remove and replace.  Since this one is via USB3 it is pretty simple to
swap out, but I could see internal storage being attached via USB3...


-- 
(\___(\___(\__  --=> 8-) EHM <=--  __/)___/)___/)
 \BS (| ehem+sig...@m5p.com  PGP 87145445 |)   /
  \_CS\   |  _  -O #include  O-   _  |   /  _/
8A19\___\_|_/58D2 7E3D DDF4 7BA6 <-PGP-> 41D1 B375 37D0 8714\_|_/___/5445

Bug#997841: thunderbird: patch applied incorrect

[Михаил Миркин]

Carsten Schoenert писал 2022-01-03 23:02:

Hello Михаил,

Am 03.01.22 um 14:39 schrieb Михаил Миркин:

Package: thunderbird
Version: 1:91.4.1-1~deb10u1
Followup-For: Bug #997841

Dear Maintainer, please fix
'debian-hacks/Add-another-preferences-directory-for-applications-p.patch'.


this patch has nothing to do with the original issue of this bug 
report.

Or at least you need to explain what do you think is broken by the
patch you posted.


Hello, Carsten.

Let me expain.
Original patch inserts directive 'LoadDirIntoArray(mXULAppDir, 
kAppendSysPrefDir, directories);', that

appears inside the '#ifdef MOZ_BACKGROUNDTASKS' block.
Since no "--enable-backgroundtasks" flag in configuration, 
MOZ_BACKGROUNDTASKS is undefined.
Therefore directory '/usr/share/thunderbird/defaults/syspref' (link to 
'/etc/thunderbird/pref') is not included, in particular, file 
/etc/thunderbird/pref/thunderbird.js is not included.

It is in this file that the necessary directive is located:
pref("intl.locale.requested", "");
I think that's why no pulling the system locale into Thunderbird.

Bug#1002982: elpa-org: post-installation script subprocess returned error exit status 1

[Gregory Mounie]

Package: elpa-org
Version: 9.5.2+dfsh-2
Followup-For: Bug #1002982

Dear Maintainer,

Thanks for the addition of org-version.el but I suspect another bug
still exist in the auto-generation of the file:

The org-version and org-git-version strings in
/usr/share/emacs/site-lisp/elpa-src/org-9.5.2/org-version.el are both
"N/A".

It should probably be respectively something like "9.5.2" and
"9.5.2-gfbff08" (values taken from a local user install of the package
from elpa)

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

Kernel: Linux 5.15.0-2-amd64 (SMP w/4 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 /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages elpa-org depends on:
ii  dh-elpa-helper  2.0.10
ii  elpa-htmlize1.56-1
ii  emacsen-common  3.0.4

Versions of packages elpa-org recommends:
ii  emacs  1:27.1+1-3.1
ii  emacs-gtk [emacs]  1:27.1+1-3.1+b1

Versions of packages elpa-org suggests:
ii  ditaa  0.10+ds1-1.2
ii  org-mode-doc   9.4.0-2
ii  texinfo6.8-3
ii  texlive-fonts-recommended  2021.20211217-1
ii  texlive-latex-extra2021.20211217-1

-- debconf-show failed

Bug#1002821: lyx-common: String/Bytes Problem in layout2layout.py

[Pavel Sanda]

On Wed, 29 Dec 2021 04:15:48 -0800 "Leo L. Schwab"  wrote:
>   Discovered this while trying to use Editorium's LyXBook modules.
> layout2layout.py was konking out with "TypeError: cannot use a bytes
> pattern on a string-like object."  After a bunch of debugging, I found
> some strings in the script that hadn't been bytes-ified, which seemed to
> fix the problem.  Patch attached.

The patch can not be taken as is to the upstream.
Would you mind reporting the exact recipy how to reproduce your problem
(maybe attach layout and example lyx file?)

Thanks,
Pavel

Bug#1003067: (no subject)

[leonardo]

similar issue here #1002697: 
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1002697

Bug#1003090: RFS: ffcvt/1.7.5-1

[Tong Sun]

On Mon, Jan 3, 2022 at 3:20 PM Tong Sun
 wrote:
>
> Package: sponsorship-requests
> Severity: normal
>
> Dear mentors,
>
> I updated my ffcvt to a newer version, and am now looking for a sponsor.
>
> Here is from the d/changelog
>
> ffcvt (1.7.5-1) unstable; urgency=medium
>
>   * New upstream version 1.7.5
> - add --Speed for speeding up playback (v1.7.5)
> - add a copy target type that can speed up operations (v1.7.4)
> - add option -S,Seg -- split video into multiple segments (v1.7.3)
> - add option -sel, subtitle encoding language (v1.7.2)
> - add option -C which allows cutting multiple segments (v1.7.1)
> - add wx type for weixin (v1.7.0)
> - x264-mp3 type set ext to .mp4 (v1.6.2)
>   * fix "source: out-of-date-standards-version" problem
>   * fix "source: update-debian-copyright" problem
>   * fix "source: prefer-uscan-symlink filenamemangle" problem
>
> Note
>
> 1) My GPG key expired a few days ago, and I've already submit the
> update to keyring.debian.org, yet I understand it might take a while
> to really get updated, so please
>
> go directly to
> https://salsa.debian.org/go-team/packages/ffcvt/-/commits/master
>
> 2) Please disregard the .gitlab-ci.yml build failure as I'm not
> supposed to touch it.

Ops, please hold off reviewing it, as I've found out where the problem
is -- ffcvt depends on the latest easygen to build yet I haven't
upgraded easygen in Debian yet. and my expired GPG key is preventing
me from fixing it promptly.

Will update when the situation is fixed.

Sorry & thanks

> The build is fine, check out here --
> https://github.com/suntong/ffcvt/runs/4687405723?check_suite_focus=true
>
> Thanks
>
>
> On Sat, Jan 9, 2021 at 11:23 PM Dmitry Smirnov  wrote:
>
> > > Please help.
> >
> > I'm at the limit of my capacity so I don't have much time to spare...
> > I had a quick look and I'd like to ask you to make few trivial changes
> > if you could, before I upload.
> >
> > Please ...
> >
> > It might take few more _flawless_ uploads before I'll become confident
> > enough in your work to give you upload rights.

Bug#1003074: libwolfssl30: wc_HashInit(h, WC_HASH_TYPE_SHA512) overflows

[Felix Lechner]

Hi Tim,

On Mon, Jan 3, 2022 at 9:09 AM Tim Rühsen  wrote:
>
> Valgrind reports a buffer overflow.

The good folks at wolfSSL cannot reproduce the error. Do you '#include
' before the others?

Either way, will you please also attach your configuration to this
report? Thanks!

Kind regards,
Felix Lechner

Bug#996245: dh-make: make doc build arch-independent

[Drew Parsons]

Package: dh-make
Version: 2.202102
Followup-For: Bug #996245

Hi Craig, Commit 4ad43078 applied a patch for Bug#996245 to make the
sample debian/rules for python packages suggest using
override_dh_auto_build-indep instead of override_dh_auto_build to
build docs only for arch-independent builds.

It's been brought to my attention that override_dh_auto_build-indep is
not the best solution for this problem.

There are two problems with it. Firstly, the suggested solution runs
dh_auto_build (without a -i flag), which means that for a full build,
the python build launched by dh_auto_build will be run twice, once for
arch-dependent and again for arch-indepedent.  The docs don't need
that, it's just using up CPU time.

Secondly, building the python package twice like that can trigger other
problems, especially with multiple python versions (we currently have
both python3.9 and python3.10), with pybuild errors like
  build: plugin pep517 failed with: File already exists
This is how we noticed the problem, when we were reviewing the build
of pymatgen with the new dh-python plugin pybuild-plugin-pyproject
(for PEP517 builds with no setup.py).

Not sure if the patched override would work better by using
"dh_auto_build -i" instead of just "dh_auto_build".  But debhelper has
a better method.

dh has a "new" (v12.8) mechanism that complements the override targets,
injecting commands before or after a step.

For the python doc build for Bug#996245, we want to call it after
dh_auto_build (in arch-independent builds), so that's
execute_after_dh_auto_build-indep. The rule for debian/rules
(in dh_make.py) could be: 

# And uncomment the following lines
#execute_after_dh_auto_build-indep: export http_proxy=127.0.0.1:9
#execute_after_dh_auto_build-indep: export https_proxy=127.0.0.1:9
#execute_after_dh_auto_build-indep:
#\tPYTHONPATH=. python3 -m sphinx -N -bhtml \\
#\tdocs/ build/html # HTML generator
#\tPYTHONPATH=. python3 -m sphinx -N -bman \\
#\tdocs/ build/man # Manpage generator'''



I suspect there's a separate problem with the http_proxy.
Even though there are both http and https variants, the transport
method doesn't seem to get processed successfully. I think it might
need http_proxy=http://127.0.0.1:9 and https_proxy=https://127.0.0.1:9
I haven't investigated this thoroughly but I'm raising it for your
attention while looking at this part of the dh-make code (not sure if
it's a sphinx bug that has since been fixed in sphinx. Certainly given
the http_ and https_ prefixes, it shouldn't be necessary to write them
explicitly a second time)


Using PYTHONPATH=. for the docs build can make problems if the package
builds python extensions (providing a .so library alongside the python
code). In that case function documentation from the extension won't be
collected by sphinx.  An alternative could be
  PYTHONPATH=$(shell pybuild --pyver `py3versions --default -v` --print 
build_dir | awk '{print $$3}' )
But that assumes pybuild is being used to build the python module.
Perhaps it's better to keep dh-make simple and not make that
assumption.


Drew

Bug#1003086: foot: please include subdir themes as examples

[Birger Schacht]

Hi,

On 1/3/22 20:34, Jonas Smedegaard wrote:
> Package: foot
> Version: 1.6.4-1
> Severity: minor
>

Upstream source includes a subdir containing color themes.

I recommend to to include those as example files.


I *just* uploaded foot 1.10.3-1 to NEW which adds a `foot-themes` 
package containing the theme files in /usr/share/foot/themes (which is 
where upstream installs them) ;)


cheers,
Birger

Bug#1003090: RFS: ffcvt/1.7.5-1

[Tong Sun]

Package: sponsorship-requests
Severity: normal

Dear mentors,

I updated my ffcvt to a newer version, and am now looking for a sponsor.

Here is from the d/changelog

ffcvt (1.7.5-1) unstable; urgency=medium

  * New upstream version 1.7.5
- add --Speed for speeding up playback (v1.7.5)
- add a copy target type that can speed up operations (v1.7.4)
- add option -S,Seg -- split video into multiple segments (v1.7.3)
- add option -sel, subtitle encoding language (v1.7.2)
- add option -C which allows cutting multiple segments (v1.7.1)
- add wx type for weixin (v1.7.0)
- x264-mp3 type set ext to .mp4 (v1.6.2)
  * fix "source: out-of-date-standards-version" problem
  * fix "source: update-debian-copyright" problem
  * fix "source: prefer-uscan-symlink filenamemangle" problem

Note

1) My GPG key expired a few days ago, and I've already submit the
update to keyring.debian.org, yet I understand it might take a while
to really get updated, so please

go directly to
https://salsa.debian.org/go-team/packages/ffcvt/-/commits/master

2) Please disregard the .gitlab-ci.yml build failure as I'm not
supposed to touch it.

The build is fine, check out here --
https://github.com/suntong/ffcvt/runs/4687405723?check_suite_focus=true

Thanks


On Sat, Jan 9, 2021 at 11:23 PM Dmitry Smirnov  wrote:

> > Please help.
>
> I'm at the limit of my capacity so I don't have much time to spare...
> I had a quick look and I'd like to ask you to make few trivial changes
> if you could, before I upload.
>
> Please ...
>
> It might take few more _flawless_ uploads before I'll become confident
> enough in your work to give you upload rights.

Bug#997841: thunderbird: patch applied incorrect

[Carsten Schoenert]

Hello Михаил,

Am 03.01.22 um 14:39 schrieb Михаил Миркин:

Package: thunderbird
Version: 1:91.4.1-1~deb10u1
Followup-For: Bug #997841

Dear Maintainer, please fix
'debian-hacks/Add-another-preferences-directory-for-applications-p.patch'.


this patch has nothing to do with the original issue of this bug report.
Or at least you need to explain what do you think is broken by the patch 
you posted.


--
Regards
Carsten

Bug#1003089: man-db has become prohibitively slow

[Steinar H. Gunderson]

Package: man-db
Version: 2.9.4-2
Severity: normal
Tags: upstream

Hi Colin,

I've noticed that during upgrades to bullseye, the man-db trigger now seems to
take a very long time; in fact, it frequently seems to be a significant time of
the total time of the full-upgrade (depending, of course, on network speeds).

After digging a bit, I think I've figured out why I haven't seen this before;
it's become a _lot_ slower recently, so it wasn't on the radar before. It seems
that due to a combination of the architecture chosen for these operations
(a pipeline system, seemingly forking off subprocesses and running lots of
syscalls in the process) and a new sandbox model (based on seccomp, which needs
a lot of setup for each new subprocess and adds considerable overhead to each
syscall), most of the total time is now spent in pure setup overhead.

As an example, a complete mandb run (mandb -c) on my laptop takes 3 minutes and
39 seconds. (Of course, the man-db trigger is incremental, but on a 
full-upgrade,
many man pages are likely to be updated.) If I set MAN_DISABLE_SECCOMP=1,
it drops to 1:41. If I recompile without HAVE_LIBSECCOMP, it's down to 51 
seconds!
I still honestly think this is slower than it should be for decompressing and
indexing 144 MB of data, but it means that the sandboxing has 329% overhead
on a modern kernel (5.15.0-2-amd64).

I don't honestly know what this database is for, but my guess is that it is
for the apropos command, which seems rare. (At least nothing obviously bad
happens to my man usage if I “rm -r /var/cache/man/*”, but apropos stops 
working.)
Is it possible to either speed up man-db so that it takes less time to build
its database, or otherwise perhaps split apropos out into a separate
not-installed-by-default package, so that normal installations do not need to
take this installation hit? Or maybe move man-db updating to cron?


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

Kernel: Linux 5.14.0 (SMP w/40 CPU threads)
Locale: LANG=en_DK.UTF-8, LC_CTYPE=en_DK.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_NO:en_US:en_GB:en
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages man-db depends on:
ii  bsdextrautils  2.36.1-8
ii  bsdmainutils   12.1.7+nmu3
ii  debconf [debconf-2.0]  1.5.77
ii  dpkg   1.20.9
ii  groff-base 1.22.4-6
ii  libc6  2.31-13+deb11u2
ii  libgdbm6   1.19-2
ii  libpipeline1   1.5.3-1
ii  libseccomp22.5.1-1+deb11u1
ii  zlib1g 1:1.2.11.dfsg-2

man-db recommends no packages.

Versions of packages man-db suggests:
ii  apparmor   2.13.6-10
ii  chromium [www-browser] 90.0.4430.212-1
ii  firefox-esr [www-browser]  91.4.1esr-1~deb11u1
pn  groff  
ii  less   551-2
ii  lynx [www-browser] 2.9.0dev.6-3~deb11u1
ii  w3m [www-browser]  0.5.3+git20210102-6

-- debconf-show failed

Bug#1003088: libkcapi: FTBFS on hppa - undefined symbols

[John David Anglin]

Source: libkcapi
Version: 1.3.1-1
Severity: normal

Dear Maintainer,

The build fails here:
libtool: link: gcc -g -O2 -ffile-prefix-map=/<>=. -Wformat 
-Werror=format-security -fpie -fPIE -DPIE -Wl,-z -Wl,relro -Wl,-z -Wl,now -pie 
-o bin/.libs/kcapi-enc apps/bin_kcapi_enc-kcapi-enc.o 
apps/bin_kcapi_enc-app-internal.o  ./.libs/libkcapi.so
/usr/bin/ld: apps/bin_kcapi_dgst-kcapi-dgst.o: in function `cipher_op':
./apps/kcapi-dgst.c:179: undefined reference to `kcapi_md_final'
/usr/bin/ld: ./apps/kcapi-dgst.c:136: undefined reference to `kcapi_md_final'
/usr/bin/ld: apps/bin_kcapi_dgst-kcapi-dgst.o: in function `set_key':
./apps/kcapi-dgst.c:341: undefined reference to `kcapi_memset_secure'
/usr/bin/ld: ./apps/kcapi-dgst.c:342: undefined reference to 
`kcapi_memset_secure'
/usr/bin/ld: ./apps/kcapi-dgst.c:341: undefined reference to 
`kcapi_memset_secure'
/usr/bin/ld: ./apps/kcapi-dgst.c:342: undefined reference to 
`kcapi_memset_secure'
/usr/bin/ld: ./apps/kcapi-dgst.c:304: undefined reference to `kcapi_pbkdf'
/usr/bin/ld: ./apps/kcapi-dgst.c:288: undefined reference to 
`kcapi_rng_generate'
/usr/bin/ld: ./.libs/libkcapi.so: undefined reference to 
`kcapi_aead_stream_init_enc'
/usr/bin/ld: ./.libs/libkcapi.so: undefined reference to 
`kcapi_cipher_stream_init_enc'
/usr/bin/ld: ./.libs/libkcapi.so: undefined reference to 
`kcapi_cipher_stream_init_dec'
/usr/bin/ld: ./.libs/libkcapi.so: undefined reference to `kcapi_cipher_encrypt'
/usr/bin/ld: ./.libs/libkcapi.so: undefined reference to `/usr/bin/ld: 
kcapi_cipher_stream_op'
/usr/bin/ld: ./.libs/libkcapi.so: undefined reference to `kcapi_cipher_decrypt'
/usr/bin/ld: ./.libs/libkcapi.so: undefined reference to `kcapi_aead_stream_op'
/usr/bin/ld: ./.libs/libkcapi.so: undefined reference to 
`kcapi_aead_stream_update_last'
/usr/bin/ld: apps/bin_kcapi_rng-kcapi-rng.o: in function 
`./.libs/libkcapi.somain':
./apps/kcapi-rng.c:302: undefined reference to `kcapi_rng_generate: undefined 
reference to `kcapi_aead_stream_init_dec'
'
/usr/bin/ld: ./apps/kcapi-rng.c:/usr/bin/ld328: undefined reference to 
`kcapi_memset_secure'
/usr/bin/ld: ./apps/kcapi-rng.c:332: undefined reference to 
`kcapi_memset_secure'
: ./.libs/libkcapi.so: undefined reference to `kcapi_md_digest/usr/bin/ld: 
./apps/kcapi-rng.c:328: undefined reference to `kcapi_memset_secure'
/usr/bin/ld: ./apps/kcapi-rng.c:'
328: undefined reference to `kcapi_memset_secure'
/usr/bin/ld: /usr/bin/ld: ./.libs/libkcapi.so: undefined reference to 
`kcapi_aead_stream_init_enc'
/usr/bin/ld: ./.libs/libkcapi.so: undefined reference to 
`kcapi_cipher_stream_init_enc'
/usr/bin/ld: ./.libs/libkcapi.so: undefined reference to 
`kcapi_cipher_stream_init_dec'
/usr/bin/ld: ./.libs/libkcapi.so: undefined reference to `kcapi_cipher_encrypt'
/usr/bin/ld: ./.libs/libkcapi.so: undefined reference to `kcapi_md_final'
/usr/bin/ld: ./.libs/libkcapi.so: undefined reference to `kcapi_pbkdf'
/usr/bin/ld: ./.libs/libkcapi.so: undefined reference to 
`kcapi_cipher_stream_op'
/usr/bin/ld: ./.libs/libkcapi.so: undefined reference to `kcapi_cipher_decrypt'
/usr/bin/ld: ./.libs/libkcapi.so: undefined reference to `kcapi_aead_stream_op'
/usr/bin/ld: ./.libs/libkcapi.so: undefined reference to 
`kcapi_aead_stream_update_last'
/usr/bin/ld: ./.libs/libkcapi.so: undefined reference to 
`kcapi_aead_stream_init_dec'
/usr/bin/ld: ./.libs/libkcapi.so: undefined reference to `kcapi_md_digest'
apps/bin_kcapi_enc-kcapi-enc.o: in function `outbufsize':
./apps/kcapi-enc.c:267: undefined reference to `kcapi_aead_outbuflen_enc'
/usr/bin/ld: ./apps/kcapi-enc.c:254: undefined reference to 
`kcapi_aead_outbuflen_dec'
/usr/bin/ld: apps/bin_kcapi_enc-kcapi-enc.o: in function `sendtag':
./apps/kcapi-enc.c:322: undefined reference to `kcapi_aead_inbuflen_enc'
/usr/bin/ld: ./apps/kcapi-enc.c:319: undefined reference to 
`kcapi_aead_inbuflen_dec'
/usr/bin/ld: apps/bin_kcapi_enc-kcapi-enc.o: in function `cipher_op':
./apps/kcapi-enc.c:480: undefined reference to `kcapi_aead_setassoclen'
/usr/bin/ld: apps/bin_kcapi_enc-kcapi-enc.o: in function `.LC53':
kcapi-enc.c:(.data.rel.ro+0xc): undefined reference to 
`kcapi_aead_stream_init_enc'
/usr/bin/ld: apps/bin_kcapi_enc-kcapi-enc.o: in function `.LC54':
kcapi-enc.c:(.data.rel.ro+0x10collect2: error: ld returned 1 exit status
): undefined reference to `kcapi_aead_stream_init_dec'
/usr/bin/ld: apps/bin_kcapi_enc-kcapi-enc.o: in function `.LC55':
kcapi-enc.c:(.data.rel.ro+0x14): undefined reference to 
`kcapi_aead_stream_update'
/usr/bin/ld: apps/bin_kcapi_enc-kcapi-enc.o: in function `.LC56':
kcapi-enc.c:(.data.rel.ro+0x18): undefined reference to 
`kcapi_aead_stream_update_last'
/usr/bin/ld: apps/bin_kcapi_enc-kcapi-enc.o: in function `.LC57':
kcapi-enc.c:(.data.rel.ro+0x1c): undefined reference to `kcapi_aead_stream_op'
/usr/bin/ld: apps/bin_kcapi_enc-kcapi-enc.o: in function `.LC62':
kcapi-enc.c:(.data.rel.ro+0x30): undefined reference to 
`kcapi_cipher_stream_init_enc'
/usr/bin/ld: apps/bin_kcapi_enc-kcapi-enc.o: in 

Bug#1003087: ITP: vimix -- Live Video Mixer

[Gürkan Myczko]

Package: wnpp
Severity: wishlist
Owner: Gürkan Myczko 
X-Debbugs-Cc: debian-de...@lists.debian.org

* Package name: vimix
  Version : 0.6.2+git20220103
  Upstream Authors: Bruno Herbelin 
  URL : https://github.com/brunoherbelin/vimix
* License : GPL-3-or-later
  Description : Live Video Mixer
 This performs graphical mixing and blending of several movie clips and 
computer

 generated graphics, with image processing effects in real-time.
 .
 Its intuitive and hands-on user interface gives direct control on image 
opacity
 and shape for producing live graphics during concerts and VJ-ing 
sessions.

 .
 The ouput image is typically projected full-screen on an external 
monitor or a

 projector, but can be recorded live (no audio).

Bug#1003086: foot: please include subdir themes as examples

[Jonas Smedegaard]

Package: foot
Version: 1.6.4-1
Severity: minor

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Upstream source includes a subdir containing color themes.

I recommend to to include those as example files.

 - Jonas

-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEn+Ppw2aRpp/1PMaELHwxRsGgASEFAmHTT6kACgkQLHwxRsGg
ASHQjg/+OB1Ty4EOsT1Kf4EL75OCMpgawJOq9+uKIcAT4BhWpZ0/OQ6SibP7SqO3
fhUTAq9llO3dAMkoFKBP/CsrzY2WPzwVLYl5ZhVQWWF+VluLXlYdgdCNCHIrR9jF
/OyFqVbdB7WKKv0sPCcdrSAp2OQRVtXKIyAkw3r7A4HT6uiB+wkp8D8aIXsNHzK1
6EDG5LGHZu53Hj+i946xWwhyE/uz3Db7hFkJyOH3fSSUVjtt5RacjkZIpiWH557f
ScI1qd30cZ+YFppzxB7TDjc2k1z9iPhtJPLeIXJCJOmaLE0Sg/xAuG8lJS2ozN7/
vuWURee6KRsH6lt/W9JdLpbqtINxcsD69Fk+rZceIY5HPFuDmI3svjBRzUG6JYiZ
hSmy4WQWun0gnheiT5z1/tDZUf9kUrVH1Ld/u8jFhsSf6kXvlXmZjIWVbdPSBpS0
VN8HmBPibdVHqLsPvRFOXnplDaf7kt1AaQQpsS2UBRL5mmSB36AUqvaRRMkBV2we
gMwFiJ/Oj7//ZMBAuuGKjolfsIi7LsTGhBjqScm1q+24ZUxDGMUFNC2/XYLu+Dpf
iwuXk0z2GwyZP0gHDJL1l/IRredGGWbgMj/hfUKnfZ8aMVbYKpm83c8gkHzKq8O9
DKfNel5tlTHEH5GP831DOhoLb2N/8XnJhKpOJaylSPSwblF4K3A=
=TP3c
-END PGP SIGNATURE-

Bug#807278: Bug #807278: checkbashisms: check for wildcards in redirects

[Gioele Barabucci]

This mistake is reported by shellcheck with code SC3031:

https://github.com/koalaman/shellcheck/wiki/SC3031

--
Gioele Barabucci 

Bug#989901: re: postfix: ipv6 CIDR not correct in mynetwork documentation

[Scott Kitterman]

Proposed documentation changes will be included in postfix 3.7 when it is 
released.

Scott K

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

Bug#1003085: small transition: libportal 0.5

[Simon McVittie]

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

I'd like to upgrade libportal from 0.4 (currently in testing) to 0.5
(in experimental). It currently only has two rdeps:

* xdg-desktop-portal only uses it for tests, and can be binNMU'd
* gnome-builder needs a sourceful upload, which is on its way to experimental

Ben file: https://release.debian.org/transitions/html/auto-libportal.html
looks suitable.

smcv

Bug#1003083: thunderbird: Update to TB91 does reset application language to EN-US

[Michael Kesper]

Package: thunderbird
Version: 1:91.4.1-1
Severity: important
Tags: l10n

Dear Maintainer,

   Thunderbird was updated to 91.4.1 by apt.
   Although german installation package is installed, all menus etc. are
   displayed in english.
   Setting of application language needs to be re-configured manually in
   Preferences (search for "lang").
   NB: This also affects stable systems due to update to TB91.4 via
   security updates!

Thanks for clarification
Michael


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

Kernel: Linux 5.15.0-2-amd64 (SMP w/4 CPU threads)
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)
LSM: AppArmor: enabled

Versions of packages thunderbird depends on:
ii  debianutils  4.11.2
ii  fontconfig   2.13.1-4.2
ii  libatk1.0-0  2.36.0-3
ii  libbotan-2-182.18.2+dfsg-1
ii  libbz2-1.0   1.0.8-5
ii  libc62.33-1
ii  libcairo-gobject21.16.0-5
ii  libcairo21.16.0-5
ii  libdbus-1-3  1.12.20-3
ii  libdbus-glib-1-2 0.112-2
ii  libevent-2.1-7   2.1.12-stable-1
ii  libffi8  3.4.2-3
ii  libfontconfig1   2.13.1-4.2
ii  libfreetype6 2.11.0+dfsg-1
ii  libgcc-s111.2.0-13
ii  libgdk-pixbuf-2.0-0  2.42.6+dfsg-2
ii  libglib2.0-0 2.70.2-1
ii  libgtk-3-0   3.24.31-1
ii  libjson-c5   0.15-2
ii  libnspr4 2:4.32-3
ii  libnss3  2:3.73.1-1
ii  libpango-1.0-0   1.48.10+ds1-1
ii  libstdc++6   11.2.0-13
ii  libvpx7  1.11.0-2
ii  libx11-6 2:1.7.2-2+b1
ii  libx11-xcb1  2:1.7.2-2+b1
ii  libxcb-shm0  1.14-3
ii  libxcb1  1.14-3
ii  libxext6 2:1.3.4-1
ii  libxrender1  1:0.9.10-1
ii  psmisc   23.4-2
ii  x11-utils7.7+5
ii  zenity   3.41.0-2
ii  zlib1g   1:1.2.11.dfsg-2

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

Versions of packages thunderbird suggests:
ii  apparmor  3.0.3-6
ii  fonts-lyx 2.3.6-1
ii  libgssapi-krb5-2  1.18.3-7

-- no debconf information

Bug#1003082: linux-image-5.15.0-2-amd64: i40iw driver replaced by irdma

[Daniel Vacek]

Package: src:linux
Version: 5.15.5-2
Severity: normal
X-Debbugs-Cc: neel...@gmail.com

Please enable the relevant configuration option:

$ grep D_IR /boot/config-5.15.0-2-amd64
# CONFIG_INFINIBAND_IRDMA is not set

--nX

Bug#1001555: openconnect: can't connect to server that use SSO SAML with protocol "anyconnect"

[Antonio]

Dear maintainer,
I tried the updated version of OpenConnect.

---

From GNOME interface:

- When the VPN is active, the form for the insertion of username and 
password appears.
- Provide access credentials I receive notification from Microsoft 
Authenticator
- confirmed identity via authenticator, the "remain connected" form 
appears and I reply "yes"


The page is then shown:

"Cisco AnyConnect Secure Mobility Client"
"You have successfully authenticated. You may now close this browser tab"

Now the VPN should be active but if I try from terminal or browser I 
can't access the VPN network, despite successfully executed all the steps.


If I close the browser page, as indicated, the network menu indicates 
that the VPN is off.


Or rather, I think it's never started.

Journal reports: "Final Secrets Request Failed to Provide Sufficient 
Secrets"


---

From KDE interface:

- same configuration

- I can now select correct AUTHGROUP

However, when I click on the "Access" button, the form does not appear 
to insert the credentials.


Unlike the GNOME interface, the log log continues to report the message 
"No SSO Handler".


Thank you,
Antonio


Il 31/12/21 01:34, Luca Boccassi ha scritto:

Control: tag -1 pending

Hello,

Bug #1001555 in openconnect reported by you has been fixed in the
Git repository and is awaiting an upload. You can see the commit
message below and you can check the diff of the fix at:

https://salsa.debian.org/debian/openconnect/-/commit/145c237a574d06f348d0147390f33b5993e5b52d


Update SAML patch

Correctly detect termination on Anyconnect + Google SAML.
Also restore backward compatibility for legacy CLI based workflow.

Closes: #1001555

Gbp-Dch: full


(this message was generated automatically)

Bug#1003081: llvm-toolchain-12: FTBFS on hurd-i386: tries to use 64bit toolchain

[Samuel Thibault]

Source: llvm-toolchain-12
Version: 1:12.0.1-10
Severity: important

Hello,

Since version 1:12.0.1-10, llvm-toolchain-12 fails to build on
hurd-i386:

https://buildd.debian.org/status/fetch.php?pkg=llvm-toolchain-12=hurd-i386=1%3A12.0.1-17=1638316821=0

[122/302] /<>/build-llvm/./bin/clang --target=i686-unknown-gnu0.9 
-DVISIBILITY_HIDDEN  -fstack-protector-strong -Wformat -Werror=format-security 
-Wno-unused-command-line-argument -Wdate-time -D_FORTIFY_SOURCE=2 -O3 -DNDEBUG  
-m64 -std=c11 -fPIC -fno-builtin -fvisibility=hidden -fomit-frame-pointer -MD 
-MT CMakeFiles/clang_rt.builtins-x86_64.dir/udivmoddi4.c.o -MF 
CMakeFiles/clang_rt.builtins-x86_64.dir/udivmoddi4.c.o.d -o 
CMakeFiles/clang_rt.builtins-x86_64.dir/udivmoddi4.c.o -c 
/<>/compiler-rt/lib/builtins/udivmoddi4.c
FAILED: CMakeFiles/clang_rt.builtins-x86_64.dir/udivmoddi4.c.o
/<>/build-llvm/./bin/clang --target=i686-unknown-gnu0.9 
-DVISIBILITY_HIDDEN  -fstack-protector-strong -Wformat -Werror=format-security 
-Wno-unused-command-line-argument -Wdate-time -D_FORTIFY_SOURCE=2 -O3 -DNDEBUG  
-m64 -std=c11 -fPIC -fno-builtin -fvisibility=hidden -fomit-frame-pointer -MD 
-MT CMakeFiles/clang_rt.builtins-x86_64.dir/udivmoddi4.c.o -MF 
CMakeFiles/clang_rt.builtins-x86_64.dir/udivmoddi4.c.o.d -o 
CMakeFiles/clang_rt.builtins-x86_64.dir/udivmoddi4.c.o -c 
/<>/compiler-rt/lib/builtins/udivmoddi4.c
In file included from /<>/compiler-rt/lib/builtins/udivmoddi4.c:13:
/<>/compiler-rt/lib/builtins/int_lib.h:70:2: error: Unsupported 
target
#error Unsupported target
 ^
In file included from /<>/compiler-rt/lib/builtins/udivmoddi4.c:13:
In file included from /<>/compiler-rt/lib/builtins/int_lib.h:84:
In file included from 
/<>/build-llvm/lib/clang/12.0.1/include/limits.h:21:
/usr/include/limits.h:26:10: fatal error: 'bits/libc-header-start.h' file not 
found
#include 
 ^~
2 errors generated.
FAILED: runtimes/builtins-stamps/builtins-build 
/<>/build-llvm/runtimes/builtins-stamps/builtins-build
/bin/sh runtimes/CMakeFiles/builtins-build-9be9135.sh d0dc098f6fe9d694
ninja: build stopped: subcommand failed.
debian/rules:562: recipe for target 'debian-full-build' failed

Indeed, this is trying to use -m64, while we don't have a 64bit variant
in the hurd toolchain.  Version -10 is the switch to two-stage build so
I'm not very surprised that this broke it :) I however don't really know
how to persuade the build not to try to build a 64bit version of the
runtime?

Samuel

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

Kernel: Linux 5.15.0-2-amd64 (SMP w/8 CPU threads)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
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

-- 
Samuel
 >bah moi j'aime bien le flash et je cherche plus a comprendre
 >crosoft. Ca plante : je reinstalle
 Ca à le mérite de créer des emplois jeunes : "réinstalleur de crosoft"
 -+- BD in NPC : Bill Gates au secours de l'emploi -+-

Bug#1003080: RFS: lsb-release-minimal/0.2-2 [ITP] -- Linux Standard Base version reporting utility (minimal implementation)

[Gioele Barabucci]

Package: sponsorship-requests
Severity: wishlist

Dear mentors,

I am looking for a sponsor for my package "lsb-release-minimal":

 * Package name: lsb-release-minimal
   Version : 0.2-2
   Upstream Author : Gioele Barabucci
 * URL : https://gioele.io/lsb-release-minimal
 * License : ISC
 * Vcs : https://salsa.debian.org/gioele/lsb-release-minimal
   Section : misc

It builds those binary packages:

  lsb-release-minimal - Linux Standard Base version reporting utility 
(minimal implementation)


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


  https://mentors.debian.net/package/lsb-release-minimal/

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

  dget -x 
https://mentors.debian.net/debian/pool/main/l/lsb-release-minimal/lsb-release-minimal_0.2-2.dsc


Changes for the initial release (the previous versions have not been 
released):


lsb-release-minimal (0.2-2) UNRELEASED; urgency=medium

  * debian/control: Move Git repo to salsa.debian.org
  * debian/watch: Change watch URL to salsa.debian.org
  * debian/copyright: Align with dh_make template
  * debian/copyright: Update copyright year to 2022
  * debian/changelog: Fix previous releases

lsb-release-minimal (0.2-1) experimental; urgency=medium

  * New upstream release v0.2
  * debian/control: Add Homepage field
  * debian/control: Update Standards-Version (no changes)
  * debian/gbp: Use same branch settings for all commands
  * debian/watch: Fix filenamemangle

lsb-release-minimal (0.1-1) experimental; urgency=medium

  * Initial upstream release (Closes: #1002831)

Regards,

--
Gioele Barabucci

Bug#1003079: scotch v7 MPI dgord dgpart tests fail

[Drew Parsons]

Package: scotch
Version: 7.0.0-1exp1
Severity: normal

autopkgtest fails for the new scotch v7 package on the MPI tests of
dgord and dgpart (check_prog_dgord and check_prog_dgpart rules in
src/check/Makefile)

The failure is intermittent, usually fails with 

$ mpirun -n 3 --oversubscribe /usr/bin/dgord data/bump.grf /dev/null -Cu -vt
*** Process received signal ***
Signal: Segmentation fault (11)
Signal code: Address not mapped (1)
Failing at address: 0x55aa224dfee0
[ 0] /lib/x86_64-linux-gnu/libc.so.6(+0x3c910)[0x7f7bcf819910]
[ 1] 
/usr/lib/x86_64-linux-gnu/openmpi/lib/openmpi3/mca_btl_vader.so(mca_btl_vader_poll_handle_frag+0x154)[0x7f7bccb93be4]
[ 2] 
/usr/lib/x86_64-linux-gnu/openmpi/lib/openmpi3/mca_btl_vader.so(+0x4fc1)[0x7f7bccb93fc1]
[ 3] /lib/x86_64-linux-gnu/libopen-pal.so.40(opal_progress+0x2c)[0x7f7bcf4d596c]
[ 4] 
/lib/x86_64-linux-gnu/libmpi.so.40(ompi_request_default_wait+0x55)[0x7f7bcf9f8075]
[ 5] 
/lib/x86_64-linux-gnu/libmpi.so.40(ompi_coll_base_sendrecv_actual+0xcf)[0x7f7bcfa5174f]
[ 6] 
/lib/x86_64-linux-gnu/libmpi.so.40(ompi_coll_base_allgather_intra_bruck+0x140)[0x7f7bcfa4f9b0]
[ 7] 
/usr/lib/x86_64-linux-gnu/openmpi/lib/openmpi3/mca_coll_tuned.so(ompi_coll_tuned_allgather_intra_dec_fixed+0x4a)[0x7f7bcc554aca]
[ 8] /lib/x86_64-linux-gnu/libmpi.so.40(MPI_Allgather+0x121)[0x7f7bcfa0be61]
[ 9] 
/lib/x86_64-linux-gnu/libptscotch-7.0.so(_SCOTCHhdgraphInduceList+0x22f)[0x7f7bcfb307ff]
[10] /lib/x86_64-linux-gnu/libptscotch-7.0.so(+0x49e02)[0x7f7bcfb30e02]
[11] /lib/x86_64-linux-gnu/libptscotch-7.0.so(+0x4a6f8)[0x7f7bcfb316f8]
[12] /lib/x86_64-linux-gnu/libptscotch-7.0.so(+0x6597b)[0x7f7bcfb4c97b]
[13] /lib/x86_64-linux-gnu/libpthread.so.0(+0x8d80)[0x7f7bcf765d80]
[14] /lib/x86_64-linux-gnu/libc.so.6(clone+0x3f)[0x7f7bcf8d9b6f]
*** End of error message ***

but sometimes passes.

The unreliability of the failure suggests a race condition, likely
related to the new dynamic thread management in v7. Perhaps we need a
different set of scotch PTHREAD flags when compiling?

Review further once v7 has passed the NEW queue to experimental.



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

Kernel: Linux 5.15.0-2-amd64 (SMP w/8 CPU threads)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE
Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.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 scotch depends on:
ii  libc6  2.33-1
ii  libscotch-7.0  7.0.0-1exp1

scotch recommends no packages.

scotch suggests no packages.

-- no debconf information

Bug#960291: dhcpcd-dbus FTCBFS: uses the build architecture pkg-config

[Helmut Grohne]

On Mon, Jan 03, 2022 at 03:29:07PM -0300, Leandro Cunha wrote:
> Fail in arm64.
> Ok in amd64.
> See raw.txt and tested with Salsa CI.

Yes, that's due to a regression introduced in 0.6.1-1. You can spot the
difference in the compiler when you browse build logs across that
version boundary at http://crossqa.debian.net/dhcpcd-dbus. Maybe try
applying patches faster?

The configure logic is busted around here:
https://sources.debian.org/src/dhcpcd-dbus/0.6.1-1/configure/#L123
We're in the case where CC is unset and thus set to cc. Since HOSTCC is
still unset, it doesn't try HOST-prefixed compilers then things go down.

As long as the cross build log contains "Using compiler .. cc", it's
doomed to fail.

Helmut

Bug#995212: chromium: Update to version 94.0.4606.61 (security-fixes)

[Andres Salomon]

Thanks for testing! Are you doing this under sid?


On 1/3/22 7:39 AM, Mattia Rizzolo wrote:

On Sun, Jan 02, 2022 at 06:53:52PM +0100, Mattia Rizzolo wrote:

the v96 branch of https://salsa.debian.org/dilinger/chromium

FWIW, I'm trying to build it myself as well

Here it started chrashing as soon as I tried to open a new tab, and
after that it refuses to load my main profile (but it loads others).


Here is what it prints on the console:

mattia@warren /tmp % chromium
[3249439:3249439:0103/133254.120313:ERROR:power_monitor_device_source_stub.cc(11)]
 Not implemented reached in virtual bool 
base::PowerMonitorDeviceSource::IsOnBatteryPower()
[3249485:3249485:0103/133254.419923:ERROR:gpu_init.cc(457)] Passthrough is not 
supported, GL is desktop, ANGLE is
[3249485:3249485:0103/133254.445016:ERROR:sandbox_linux.cc(376)] 
InitializeSandbox() called with multiple threads in process gpu-process.
[3249439:3249468:0103/133258.019370:ERROR:chrome_browser_main_extra_parts_metrics.cc(226)]
 crbug.com/1216328: Checking Bluetooth availability started. Please report if 
there is no report that this ends.
[3249439:3249468:0103/133258.020176:ERROR:chrome_browser_main_extra_parts_metrics.cc(229)]
 crbug.com/1216328: Checking Bluetooth availability ended.
[3249439:3249468:0103/133258.020199:ERROR:chrome_browser_main_extra_parts_metrics.cc(232)]
 crbug.com/1216328: Checking default browser status started. Please report if 
there is no report that this ends.
[3249439:3249468:0103/133258.284415:ERROR:chrome_browser_main_extra_parts_metrics.cc(236)]
 crbug.com/1216328: Checking default browser status ended.
[3249439:3249439:0103/133259.591406:FATAL:accessibility_paint_checks.cc(60)] 
Check failed: node_data.GetNameFrom() == 
ax::mojom::NameFrom::kAttributeExplicitlyEmpty (kAttribute vs. 
kAttributeExplicitlyEmpty) 0x55c6fb7c92d0: BookmarkButton is focusable but has 
no accessible name or placeholder, and is not explicitly marked as empty.


Hm, that's a new one.

Looks like upstream turned those assert crashes into debug statements in 
newer releases. Please try to following patch:


https://chromium.googlesource.com/chromium/src/+/409b167aac2cd07f6606febcc2b6f3fa286ce749%5E%21/

If that doesn't help, also try the following:

https://chromium.googlesource.com/chromium/src/+/ed83cbdb051c676083dde799cfec982f721e5b68%5E%21/

That second one adds a SkipAccessibilityPaintChecks setting which will 
skip that whole code block.




BrowserRootView -> NonClientView -> OpaqueBrowserFrameView -> BrowserView -> 
TopContainerView -> BookmarkBarView -> BookmarkButton
#0 0x55c6ef3a2d79 (/usr/lib/chromium/chromium+0x824bd78)
[...]
#39 0x55c6eaa1052a _start
   r8:   r9: 7fffbda69a50 r10: 0008 r11: 
0246
  r12: 01d0 r13: 55c6f8cc8480 r14: 55c6f8cc8490 r15: 
7fffbda6a508
   di: 0002  si: 7fffbda69a50  bp: 7fffbda69ca0  bx: 
7f7cb6875540
   dx:   ax:   cx: 7f7cbdfe6891  sp: 
7fffbda69a50
   ip: 7f7cbdfe6891 efl: 0246 cgf: 002b0033 erf: 

  trp:  msk:  cr2: 
[end of stack trace]
[1]3249439 IOT instruction (core dumped)  chromium


(It looks like it's not immediatly obvious how to start it under gdb, so
I'm not providing a nicer stack trace)



In general, you install the -dbgsym packages and run chromium -g

Bug#1003078: network-manager-gnome: Can't disable Networking/Wi-Fi, can't remove/edit connections (No polkit authorization)

[Ivan Vilata i Balaguer]

Package: network-manager-gnome
Version: 1.24.0-1
Severity: normal

Dear Maintainer,

After updating `network-manager-gnome`, the toggles "Enable Networking" and
"Enable Wi-Fi" that show on right-click over the `nm-applet` appear active but
grayed out and not responsive.  Also, if I choose "Edit Connections...", and
choose a connection in the "Network Connections" list, the "-" and gears
buttons in the bottom remain grayed out and a tooltip shows up with
"No polkit authorization to perform the action".

Since I'm not running the whole GNOME, I installed `policykit-1-gnome`, ran
`/usr/lib/policykit-1-gnome/polkit-gnome-authentication-agent-1` and restarted
`nm-applet` with same results.  As my user belongs to `netdev`, I also tried
the `/etc/polkit-1/localauthority/50-local.d/WHATEVER.pkla` config mentioned
in #642136 to no avail (after restarting polkit and NetworkManager):

[Adding or changing system-wide NetworkManager connections]
Identity=unix-group:netdev
Action=org.freedesktop.NetworkManager.settings.modify.system
ResultAny=no
ResultInactive=no
ResultActive=yes

Other applets like `nm-tray` allow me to disable Networking/Wi-Fi without
issues, and `nmtui-*` tools allow me to edit connections just fine, so it
seems specific to this package and not `network-manager`.

Thanks a lot, and cheers!

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

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

Versions of packages network-manager-gnome depends on:
ii  dbus-user-session [default-dbus-session-bus]  1.12.20-3
ii  dbus-x11 [dbus-session-bus]   1.12.20-3
ii  libatk1.0-0   2.36.0-3
ii  libayatana-appindicator3-10.5.90-5
ii  libc6 2.33-1
ii  libcairo2 1.16.0-5
ii  libgdk-pixbuf-2.0-0   2.42.6+dfsg-2
ii  libglib2.0-0  2.70.2-1
ii  libgtk-3-03.24.31-1
ii  libjansson4   2.13.1-1.1
ii  libmm-glib0   1.18.4-1
ii  libnm01.32.12-1
ii  libnma0   1.8.32-1
ii  libnotify40.7.9-3
ii  libpango-1.0-01.48.10+ds1-1
ii  libpangocairo-1.0-0   1.48.10+ds1-1
ii  libsecret-1-0 0.20.4-2
ii  libselinux1   3.3-1+b1
ii  lxqt-policykit [polkit-1-auth-agent]  0.16.0-1
ii  network-manager   1.32.12-1
ii  policykit-1-gnome [polkit-1-auth-agent]   0.105-7+b1

Versions of packages network-manager-gnome recommends:
ii  dunst [notification-daemon]   1.5.0-1+b1
ii  gnome-keyring 40.0-3
ii  iso-codes 4.8.0-1
ii  lxqt-notificationd [notification-daemon]  0.16.0-1
ii  mobile-broadband-provider-info20210805-1

Versions of packages network-manager-gnome suggests:
pn  network-manager-openconnect-gnome  
pn  network-manager-openvpn-gnome  
pn  network-manager-pptp-gnome 
pn  network-manager-vpnc-gnome 

-- no debconf information

Bug#960291: dhcpcd-dbus FTCBFS: uses the build architecture pkg-config

[Leandro Cunha]

Hi,

Fail in arm64.
Ok in amd64.
See raw.txt and tested with Salsa CI.

-- 
Cheers,
Leandro Cunha
Running with gitlab-runner 13.11.0 (HEAD)
  on salsa-runner.debian.net f0fdd533
section_start:1637895536:prepare_executor
Preparing the "docker+machine" executor
Using Docker executor with image 
registry.salsa.debian.org/salsa-ci-team/pipeline/base:unstable ...
WARNING: Pulling GitLab Runner helper image from Docker Hub. Helper 
image is migrating to registry.gitlab.com, for more information see 
https://docs.gitlab.com/runner/configuration/advanced-configuration.html#migrate-helper-image-to-registrygitlabcom
Pulling docker image gitlab/gitlab-runner-helper:x86_64-latest ...
Using docker image 
sha256:09a800403ef0e30f8bcd5e201f6b4b1fc7e103cb6c918984dfa0c6fe07d6cc6e for 
gitlab/gitlab-runner-helper:x86_64-latest with digest 
gitlab/gitlab-runner-helper@sha256:dee8f5e62c1875e48d75ec0f8531cf310a366f99c0ba6427e5cadcaa869875cd
 ...
Authenticating with credentials from job payload (GitLab Registry)
Pulling docker image 
registry.salsa.debian.org/salsa-ci-team/pipeline/base:unstable ...
Using docker image 
sha256:bd5234e5d8de44ca3a00450397d5197e2c44b485238de3bf5ae18d3671d73e3c for 
registry.salsa.debian.org/salsa-ci-team/pipeline/base:unstable with digest 
registry.salsa.debian.org/salsa-ci-team/pipeline/base@sha256:9c8519959725eb7f6062a84d24b08cb4d2aaca95d0ca9c6cd41f5acfa0329098
 ...
section_end:1637895600:prepare_executor
section_start:1637895600:prepare_script
Preparing environment
Running on runner-f0fdd533-project-57920-concurrent-0 via 
runner-f0fdd533-1637895536-52a81fc0...
section_end:1637895602:prepare_script
section_start:1637895602:get_sources
Getting source from Git repository
Fetching changes with git depth set to 1...
Initialized empty Git repository in /builds/leandrocunha/dhcpcd-dbus/.git/
Created fresh repository.
Checking out 33fbd904 as debian/master...

Skipping Git submodules setup
section_end:1637895604:get_sources
section_start:1637895604:restore_cache
Restoring cache
Checking cache for build-amd64_arm64...
FATAL: file does not exist 
Failed to extract cache
section_end:1637895605:restore_cache
section_start:1637895605:download_artifacts
Downloading artifacts
Downloading artifacts for extract-source (2218827)...
Downloading artifacts from coordinator... ok    id=2218827 
responseStatus=200 OK token=Gt7bnm51
section_end:1637895606:download_artifacts
section_start:1637895606:step_script
Executing "step_script" stage of the job script
Using docker image 
sha256:bd5234e5d8de44ca3a00450397d5197e2c44b485238de3bf5ae18d3671d73e3c for 
registry.salsa.debian.org/salsa-ci-team/pipeline/base:unstable with digest 
registry.salsa.debian.org/salsa-ci-team/pipeline/base@sha256:9c8519959725eb7f6062a84d24b08cb4d2aaca95d0ca9c6cd41f5acfa0329098
 ...
$ # Reported in 
https://salsa.debian.org/salsa-ci-team/pipeline/issues/104, # collapsed 
multi-line command
+ [[ -n '' ]]
$ if test -n ${HOST_ARCH} && egrep -q 
"^Architecture:.*(any|[^\!]${HOST_ARCH})" debian/control; then # collapsed 
multi-line command
$ export CCACHE_DIR=${CCACHE_TMP_DIR} # collapsed multi-line command
Get:1 http://deb.debian.org/debian sid InRelease [165 kB]
Get:2 http://deb.debian.org/debian sid/main Sources [9424 kB]
Get:3 http://deb.debian.org/debian sid/main amd64 Packages [8879 kB]
Get:4 http://deb.debian.org/debian sid/main arm64 Packages [8743 kB]
Fetched 27.2 MB in 4s (6638 kB/s)
Reading package lists...
Reading package lists...
Building dependency tree...
The following additional packages will be installed:
  aptitude-common autoconf automake autopoint autotools-dev binutils
  binutils-common binutils-x86-64-linux-gnu bsdextrautils bzip2 cpp cpp-11
  debhelper dh-autoreconf dh-strip-nondeterminism dirmngr dpkg-dev dwz
  fakeroot file g++ g++-11 gcc gcc-11 gcc-11-base gettext gettext-base gnupg
  gnupg-l10n gnupg-utils gpg gpg-agent gpg-wks-client gpg-wks-server gpgconf
  gpgsm groff-base intltool-debian libarchive-zip-perl libasan6 libassuan0
  libatomic1 libb-hooks-op-check-perl libbinutils libboost-iostreams1.74.0
  libc-dev-bin libc6-dev libcc1-0 libclass-method-modifiers-perl libcrypt-dev
  libctf-nobfd0 libctf0 libcwidget4 libdebhelper-perl
  libdevel-callchecker-perl libdpkg-perl libdynaloader-functions-perl libelf1
  libencode-locale-perl libexpat1 libfakeroot libfile-dirlist-perl
  libfile-homedir-perl libfile-listing-perl libfile-stripnondeterminism-perl
  libfile-touch-perl libfile-which-perl libgcc-11-dev libgcc-s1
  libgdbm-compat4 libgdbm6 libgomp1 libhiredis0.14 libhtml-parser-perl
  

Bug#1002054: getmail: regression after uprading to buster

[Sudip Mukherjee]

On Mon, Jan 3, 2022 at 5:22 PM  wrote:
>
>
> Hi Sudip,
>
> Sudip Mukherjee  writes:
>
> > I think you meant to say "after upgrading to Bullseye".
>
> Yes.
>
> > Can you please install the package from "bullseye-backports"..
> > Previously it used to be a Debian specific wrapper for getmail, which
> > was removed when getmail was upgraded to getmail6. But getmail6
> > upstream has now added it in the source and so its available as part
> > of getmail6.
>
> Thanks. Swearing a few hours against my computer, I succeed to replace
> it by a naive version of mine.

That was not necessary. :)
Instructions from installing from backports are at:
https://backports.debian.org/Instructions/


-- 
Regards
Sudip

Bug#1003077: lesana: autopkgtest failure: No module named 'git'

[Paul Gevers]

Source: lesana
Version: 0.9.1-1
X-Debbugs-CC: debian...@lists.debian.org
Severity: serious
User: debian...@lists.debian.org
Usertags: fails-always

Dear maintainer(s),

You recently added an autopkgtest to your package lesana, great. 
However, it fails. Currently this failure is blocking the migration to 
testing [1]. Can you please investigate the situation and fix it?


I copied some of the output at the bottom of this report. Are you 
missing a test dependency?


More information about this bug and the reason for filing it can be found on
https://wiki.debian.org/ContinuousIntegration/RegressionEmailInformation

Paul

[1] https://qa.debian.org/excuses.php?package=lesana

https://ci.debian.net/data/autopkgtest/testing/amd64/l/lesana/17975376/log.gz

E..E..
==
ERROR: Failure: ModuleNotFoundError (No module named 'git')
--
Traceback (most recent call last):
  File "/usr/lib/python3/dist-packages/nose/failure.py", line 39, in 
runTest

raise self.exc_val.with_traceback(self.tb)
  File "/usr/lib/python3/dist-packages/nose/loader.py", line 416, in 
loadTestsFromName

module = self.importer.importFromPath(
  File "/usr/lib/python3/dist-packages/nose/importer.py", line 47, in 
importFromPath

return self.importFromDir(dir_path, fqname)
  File "/usr/lib/python3/dist-packages/nose/importer.py", line 94, in 
importFromDir

mod = load_module(part_fqname, fh, filename, desc)
  File "/usr/lib/python3.9/imp.py", line 234, in load_module
return load_source(name, filename, file)
  File "/usr/lib/python3.9/imp.py", line 171, in load_source
module = _load(spec)
  File "", line 711, in _load
  File "", line 680, in _load_unlocked
  File "", line 850, in exec_module
  File "", line 228, in 
_call_with_frames_removed
  File 
"/tmp/autopkgtest-lxc.uvne8ina/downtmp/build.wXs/src/tests/test_collection.py", 
line 9, in 

import git
ModuleNotFoundError: No module named 'git'

==
ERROR: test_init (tests.test_commands.testCommandsSimple)
--
Traceback (most recent call last):
  File 
"/tmp/autopkgtest-lxc.uvne8ina/downtmp/build.wXs/src/tests/test_commands.py", 
line 66, in test_init

streams = self._run_command(command.Init(), args)
  File 
"/tmp/autopkgtest-lxc.uvne8ina/downtmp/build.wXs/src/tests/test_commands.py", 
line 38, in _run_command

cmd.main()
  File 
"/tmp/autopkgtest-lxc.uvne8ina/downtmp/build.wXs/src/lesana/command.py", 
line 474, in main

self.collection_class.init(
  File 
"/tmp/autopkgtest-lxc.uvne8ina/downtmp/build.wXs/src/lesana/collection.py", 
line 632, in init

shutil.copy(hook_source, checkout_hook)
  File "/usr/lib/python3.9/shutil.py", line 427, in copy
copyfile(src, dst, follow_symlinks=follow_symlinks)
  File "/usr/lib/python3.9/shutil.py", line 266, in copyfile
with open(dst, 'wb') as fdst:
FileNotFoundError: [Errno 2] No such file or directory: 
'/tmp/tmp6g7s3i37/.git/hooks/post-checkout'

 >> begin captured logging << 
lesana.types: DEBUG: Not indexing empty value None
lesana.types: DEBUG: Not indexing empty value None
lesana.types: DEBUG: Not indexing empty value None
lesana.types: DEBUG: Not indexing empty value None
lesana.types: DEBUG: Not indexing empty value None
lesana.types: DEBUG: Not indexing empty value None
lesana.types: DEBUG: Not indexing empty value None
lesana.types: DEBUG: Not indexing empty value None
lesana.collection: WARNING: python3-git not available, could not 
initalise the git repository.

- >> end captured logging << -

--
Ran 50 tests in 2.623s

FAILED (errors=2)
autopkgtest [21:09:22]: test unittests



OpenPGP_signature
Description: OpenPGP digital signature

Bug#1003045: New information : problem seems to be xorg/wayland conflict.

[Rene Engelhard]

Hi

Am 03.01.22 um 18:46 schrieb Rene Engelhard:
> my clean testing VM which I just dist_upgraded. Lo starts fine with the
> default session there which is Xorg.

Nevermind, it was wayland actually but also "GNOME on Xorg" works.

Regards,

Rene

Bug#1001961: Bug#995393: fakeroot: diff for NMU version 1.26-1.2

[Christoph Biedl]

Control: tags 995393 + pending
Control: tags 1001961 + pending

Dear maintainer,

to finally address the segfault issue on ppc64el, I've prepared and NMU
for fakeroot (versioned as 1.26-1.2), and uploaded it to DELAYED/3.
Please feel free to tell me if I should delay it longer.


diff -Nru fakeroot-1.26/debian/changelog fakeroot-1.26/debian/changelog
--- fakeroot-1.26/debian/changelog  2021-12-23 08:19:30.0 +0100
+++ fakeroot-1.26/debian/changelog  2022-01-03 18:49:27.0 +0100
@@ -1,3 +1,10 @@
+fakeroot (1.26-1.2) unstable; urgency=high
+
+  * Non-maintainer upload
+  * Fix segfault on ppc64el, take 2. Closes: #995393
+
+ -- Christoph Biedl   Mon, 03 Jan 2022 
18:49:27 +0100
+
 fakeroot (1.26-1.1) unstable; urgency=high
 
   * Non-maintainer upload
diff -Nru fakeroot-1.26/debian/patches/fix-prototype-generation.patch 
fakeroot-1.26/debian/patches/fix-prototype-generation.patch
--- fakeroot-1.26/debian/patches/fix-prototype-generation.patch 1970-01-01 
01:00:00.0 +0100
+++ fakeroot-1.26/debian/patches/fix-prototype-generation.patch 2022-01-03 
12:55:03.0 +0100
@@ -0,0 +1,59 @@
+Subject: Fix prototype generation for openat
+Author: Christoph Biedl 
+Date: 2021-12-30
+Bug-Debian: https://bugs.debian.org/995393
+Forwarded: Yes (implicitely)
+
+As jrtc27 pointed out in IRC, ppc64el is more strict than other
+architectures when it comes to va_arg handling:
+
+it's that ppc64le uses the elfv2 abi, and for variadic calls you
+must reserve space for a parameter save area
+
+So enhance wrapawk to create a proper prototype and argument
+handling although it's specific to the openat call. Also add the
+missing documentation for the sixth column to wrapfunc.inp.
+
+--- a/wrapawk
 b/wrapawk
+@@ -37,7 +37,25 @@
+   argtype=$3;
+   argname=$4;
+   MACRO=$5;
+-  if(MACRO){
++  openat_extra=$6;
++  if(openat_extra){
++print "  {(void(*))_" name ", \"" name "\"},"  > structfile;
++print "extern " ret " (*next_" name ")" openat_extra ";" > headerfile;
++print ret " (*next_" name ")" openat_extra "=tmp_" name ";"> deffile;
++
++print ret " tmp_" name,  openat_extra "{"   > tmpffile;
++print "  mode_t mode = 0;"  > tmpffile;
++print "  if (flags & O_CREAT) {"> tmpffile;
++print "va_list args;"   > tmpffile;
++print "va_start(args, flags);"  > tmpffile;
++print "mode = va_arg(args, int);"   > tmpffile;
++print "va_end(args);"   > tmpffile;
++print "  }" > tmpffile;
++print "  load_library_symbols();"   > tmpffile;
++print "  return  next_" name,  argname ";"  > tmpffile;
++print "}"   > tmpffile;
++print ""> tmpffile;
++  } else if(MACRO){
+ print "  {(void(*))_" MACRO "_NOARG, " name "_QUOTE},"  > structfile;
+ print "extern " ret " (*NEXT_" MACRO "_NOARG)" argtype ";" > headerfile;
+ print ret " (*NEXT_" MACRO "_NOARG)" argtype "=TMP_" MACRO ";"> deffile;
+--- a/wrapfunc.inp
 b/wrapfunc.inp
+@@ -9,8 +9,10 @@
+ /**/*/
+ /* each line of this file lists 4 fields, seperated by a ";".   */
+ /* The first field is the name of the wrapped function, then it's return  */
+-/* value. After that come the function arguments with types, and the last */
++/* value. After that come the function arguments with types, and the fifth */
+ /* field contains the function arguments without types.   */
++/* A sixth field is a special needed when wrapping the openat syscall.*/
++/* Otherwise it's like the third (function arguments with types). */
+ /**/
+ 
+ /* __*xstat are used on glibc systems instead of just *xstat. */
diff -Nru fakeroot-1.26/debian/patches/ppc64el-workaround.patch 
fakeroot-1.26/debian/patches/ppc64el-workaround.patch
--- fakeroot-1.26/debian/patches/ppc64el-workaround.patch   2021-12-23 
08:19:30.0 +0100
+++ fakeroot-1.26/debian/patches/ppc64el-workaround.patch   1970-01-01 
01:00:00.0 +0100
@@ -1,31 +0,0 @@
-Subject: Work around segfault on ppc64el
-Author: Christoph Biedl 
-Date: 2021-12-20
-Bug-Debian: https://bugs.debian.org/995393
-Forwarded: Yes
-
-For whatever reason the generated code segfaults on ppc64el when
-built with the usual optimizations. The root cause is not clear,
-might be a compiler bug or the result of improperly generated
-function prototypes.
-
-As a workaround, disable optimizations for the affected function.
-
-This should be re-visted upon any major compiler release whether
-it's still needed.
-
 a/libfakeroot.c
-+++ b/libfakeroot.c
-@@ -2596,7 +2596,11 @@
- #endif
- 
- #ifdef HAVE_OPENAT
--int openat(int 

Bug#1003076: ITP: libgeo-hash-perl -- Perl module to encode/decode geohash.org locations.

[Christophe Maudoux]

Package: wnpp
Severity: wishlist
Owner: Christophe Maudoux 

* Package name: libgeo-hash-perl
  Version : 0.02
  Upstream Author : Andy Armstrong 
* URL : https://metacpan.org/release/Geo::Hash
* License : Artistic or GPL-1+
  Programming Lang: Perl
  Description : Perl module to encode/decode geohash.org locations.

Geohash is a latitude/longitude geocode system invented by Gustavo Niemeyer
when writing the web service at geohash.org, and put into the public domain.

This module encodes and decodes geohash locations.

This package is a dependency of libgeohash-perl. It will be maintainded under
Perl team umbrella.

Bug#1003075: gnutls28: HTML API reference documentation is not generated

[Dennis Filder]

Source: gnutls28
Version: 3.7.2-4
Tags: patch

Building the HTML api-reference docs seems to have been broken for
quite a while due to XML shenanigans.  The first of the attached
patches makes it work again, but fixing makeinfo to emit DocBook that
is actually valid XML would be better.

The second patch polishes d/rules a bit.

The patches apply cleanly to 3.7.2-4, but I only ran the build with
3.7.1-5.

Regards.
--- a/doc/reference/gnutls-docs.sgml
+++ b/doc/reference/gnutls-docs.sgml
@@ -2,7 +2,7 @@
 https://www.oasis-open.org/docbook/xml/4.3/docbookx.dtd;
 [
-  https://www.w3.org/2003/XInclude'">
+  http://www.w3.org/2003/XInclude'">
   
 ]>
 
--- a/lib/cert-cred.c
+++ b/lib/cert-cred.c
@@ -905,7 +905,7 @@
  * chain is incomplete due a missing intermediate certificate. The callback
  * may provide the missing certificate for use during verification.
  *
- * The callback's function prototype is defined in  as:
+ * The callback's function prototype is defined in gnutls/x509.h as:
  *
  *   int (*callback)(gnutls_x509_trust_list_t list,
  *   const gnutls_x509_crt_t cert,
--- a/debian/rules
+++ b/debian/rules
@@ -46,7 +46,7 @@
 		$(AMCONFBUILDINDEP)
 
 override_dh_autoreconf:
-	rm -v `grep -rl gettext-0.20 m4/`
+	-rm -v `grep -rl gettext-0.20 m4/`
 	if ! dh_listpackages | grep -q gnutls-doc ; \
 		then env GTKDOCIZE="echo DISABLED running gtkdocize" \
 			dh_autoreconf --verbose $(BDIR) ; \
@@ -78,7 +78,7 @@
 	# restore gnutls.pdf
 	if [ -e doc/gnutls.pdf.debbackup ] && [ ! -e doc/gnutls.pdf ] ; \
 		then mv -v doc/gnutls.pdf.debbackup doc/gnutls.pdf ; fi
-	rm -fv \
+	-rm -fv \
 		`grep -El 'has been AutoGen-ed |has been AutoGen-ed *$$' doc/manpages/*.?`
 
 override_dh_auto_build:
@@ -93,9 +93,9 @@
 override_dh_auto_install:
 	dh_auto_install $(BDIR) --verbose
 ifneq ($(filter --disable-doc,$(AMCONFBUILDINDEP)),)
-	$(MAKE) -C b4deb/doc/manpages DESTDIR=`pwd`/debian/tmp install
+	$(MAKE) -C b4deb/doc/manpages DESTDIR=$(CURDIR)/debian/tmp install
 else
-	$(MAKE) -C b4deb/doc/ DESTDIR=`pwd`/debian/tmp install-html
+	$(MAKE) -C b4deb/doc/ DESTDIR=$(CURDIR)/debian/tmp install-html
 	# we symlink these
 	rm -vf debian/tmp/usr/share/info/*.png
 endif
@@ -126,7 +126,7 @@
 
 # Fails with "dwz: Section overlap detected"
 override_dh_dwz:
-	dh_dwz -O--builddirectory=b4deb -Xextra.go -Xgnutls.go
+	dh_dwz $(BDIR) -Xextra.go -Xgnutls.go
 
 %:
-	dh $@ --builddirectory=b4deb
+	dh $@ $(BDIR)

Bug#1003045: libreoffice: Since testing update on Jan 2, 2021, libreoffice doesn't start.

[Rene Engelhard]

Hi,

Am 03.01.22 um 09:48 schrieb Emmanuel Charpentier:
> similarly, launching an application from a console's command line returns 
> after
> a few seconds.

Nothing on the command line?


Can't be a general problem since

https://ci.debian.net/packages/libr/libreoffice/testing/amd64/

passes (and the UI tests and junit tests start up LibreOffice)

(Admittedly that doesn't do actual display since it's told to use the
headless backend, but still.)


>
>* What exactly did you do (or not do) that was effective (or ineffective)?
>
> I tried to reinstall Libreoffice applications by :
>
> dpkg -l "*libre*office*" | grep -e "^ii" | sed -re "s/[ \t]+/ /g" | cut -d " "
> -f 2 | sudo xargs apt-get install --reinstall

Which usually doesn't help at all if the issue isn't a dependency
problem or you removed non-conffiles. If you removed important conffiles
e.g. this won't do anything since changes by the admin have to be preserved.


> Possibly related : sudo apt dist-upgrade leaves libc++1 unupgraded, whereas
> sudo apt install -s wants to uninstall libc++1-11 and libc++abi1-11 and 
> install
> libc++1-13 libc++abi1-13 libunwind-13. So far, I did **not** proceed.

None of which LibreOffice uses.


Regards,


Rene

Bug#1002670: grub2-common: Unable to force MBR/embedding installation

[Steve McIntyre]

Hi Elliott,

On Mon, Jan 03, 2022 at 08:52:48AM -0800, Elliott Mitchell wrote:
>On Mon, Jan 03, 2022 at 02:35:48PM +, Steve McIntyre wrote:
>> 
>> What you're asking for here won't work; arm64 devices don't/can't use
>> the embedding MBR/gap style of GRUB installation - that's x86 only. Instead,
>> what you need is to do an EFI installation but with a couple of extra
>> options chosen. Run "dpkg-reconfigure -plow grub-efi-arm64" and say:
>> 
>>  * "yes" to "Force extra installation to the EFI removable media path?"
>>  * "no" to "Update NVRAM variables to automatically boot into Debian?"
>> 
>> and and you should be fine from now on.
>
>Justify the statement "arm64 devices don't/can't use the embedding
>MBR/gap style of GRUB installation".  I concur that is not the normal way
>of doing EFI installation on ARM64 devices, but in this case I've got a
>device which is unable to store persistent variables (if you sacrifice a
>SD Card it can store them, but otherwise it loses them on restart).

The MBR/gap style is *totally specific* to the old-school x86 BIOS way
of doing things:

 * A tiny 16-bit x86 asm loader is added into the boot sector; it uses
   BIOS routines to load the GRUB core image from the raw space after
   the partition table and execute it.

 * The core image contains enough functionality (display, filesystems,
   storage drivers, etc.) to be able to find load further modules from
   the /boot filesystem. It loads those, runs the menu, etc.

arm64 machines categorically do *not* have any capability to run this
way. It has never been a thing. Instead, systems running GRUB will
load GRUB as a UEFI binary from an EFI System Partition (ESP) and go
from there. Depending on the exact installation on your system, you
may have an ESP on removable storage (SD?), on hard drive / SSD, or
maybe on internal eMMC or similar. It's possible you could be loading
from the network too, but I assume you'd know if that was happening.

You have not identified the exact platform you're using, so I've no
idea exactly which of the above options is most likely.

>Yet somehow despite restarting from a mostly clean slate an older
>installation of 2.02+dfsg1-20+deb10u4 keeps managing to manifest, while
>2.04-20 is unable to be loaded.
>
>My conclusion is 2.02+dfsg1-20+deb10u4 was able to successfully install
>in the embedding area despite not being supposed to work.  Meanwhile I'm
>guessing Tianocore/ARM64 inherited the ability to boot from the embedding
>area, despite using that being strongly discouraged.

Nope, sorry.

>Or at least that is a simple explanation for why traces of
>2.02+dfsg1-20+deb10u4 continue to persist, while 2.04-20 appears
>reluctant.

My first guess would be that either:

 * You have more than one ESP on your system somewhere, and the system
   is finding an old grub binary that way; or

 * The old grub is in the removable media path and you haven't managed
   to replace it yet (see my first mail for details on how to do
   that).

-- 
Steve McIntyre, Cambridge, UK.st...@einval.com
< liw> everything I know about UK hotels I learned from "Fawlty Towers"

Bug#1003074: libwolfssl30: wc_HashInit(h, WC_HASH_TYPE_SHA512) overflows

[Tim Rühsen]

Package: libwolfssl30
Version: 5.0.0-1+b1
Severity: important

Dear Maintainer,

the unit test for WolfSSL hashing in GNU Wget2 crashes.
Valgrind reports a buffer overflow.

This can be reproduced with this little C code:
#include 
#define WOLFSSL_SHA512
#define WC_NO_HARDEN
#include 
int main(void)
{
wc_HashAlg *h = malloc(sizeof(wc_HashAlg));
wc_HashInit(h, WC_HASH_TYPE_SHA512);
return 0;
}

Compile it with 'gcc -g -O0 sha512_overflow.c -o sha512_overflow -lwolfssl'
and run it with 'valgrind ./sha512_overflow'.

Valgrind output:
==1781168== Invalid write of size 4
==1781168==at 0x48DCEB1: wc_InitSha512_ex (in 
/usr/lib/x86_64-linux-gnu/libwolfssl.so.30.0.0)
==1781168==by 0x10916F: main (sha512_overflow.c:11)
==1781168==  Address 0x4e27120 is 0 bytes after a block of size 224 alloc'd
==1781168==at 0x483F7B5: malloc (in 
/usr/libexec/valgrind/vgpreload_memcheck-amd64-linux.so)
==1781168==by 0x10915A: main (sha512_overflow.c:9)
==1781168== 
==1781168== Invalid write of size 8
==1781168==at 0x48DCEB7: wc_InitSha512_ex (in 
/usr/lib/x86_64-linux-gnu/libwolfssl.so.30.0.0)
==1781168==by 0x10916F: main (sha512_overflow.c:11)
==1781168==  Address 0x4e27128 is 8 bytes after a block of size 224 alloc'd
==1781168==at 0x483F7B5: malloc (in 
/usr/libexec/valgrind/vgpreload_memcheck-amd64-linux.so)
==1781168==by 0x10915A: main (sha512_overflow.c:9)
==1781168== 
==1781168== Invalid write of size 4
==1781168==at 0x48DCEE2: wc_InitSha512_ex (in 
/usr/lib/x86_64-linux-gnu/libwolfssl.so.30.0.0)
==1781168==by 0x10916F: main (sha512_overflow.c:11)
==1781168==  Address 0x4e27130 is 16 bytes after a block of size 224 alloc'd
==1781168==at 0x483F7B5: malloc (in 
/usr/libexec/valgrind/vgpreload_memcheck-amd64-linux.so)
==1781168==by 0x10915A: main (sha512_overflow.c:9)

The code so far worked with WolfSSL versions < 5.0.0 (e.g. libwolfssl24).

Regards, Tim

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

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

Versions of packages libwolfssl30 depends on:
ii  libc6  2.33-1

libwolfssl30 recommends no packages.

libwolfssl30 suggests no packages.

-- no debconf information

Bug#1002670: grub2-common: Unable to force MBR/embedding installation

[Elliott Mitchell]

On Mon, Jan 03, 2022 at 02:35:48PM +, Steve McIntyre wrote:
> 
> On Sun, Dec 26, 2021 at 05:12:38PM -0800, Elliott Mitchell wrote:
> >
> >Hopefully the subject tells the tale.  Due to some odd hardware, I need
> >to force `grub-install` to install the EFI version of GRUB into the
> >MBR/boot area gap.  Unfortunately the documentation suggest none of
> >`grub-install`'s options can get this result.  As a result I've got a
> >problem.
> >
> >The background:  I'm trying to get GRUB installed on a very popular ARM64
> >device which has a full Tianocore/UEFI image available.  Unfortunately
> >while it is full Tianocore, the device lacks any private NVRAM and thus
> >is unable to store EFI variables.
> >
> >`grub-install` tries to do a "normal" UEFI installation, which fails due
> >to lack of EFI variables.  As a result I need GRUB to install in the
> >MBR/GPT gap, but none of `grub-install`'s options appear to cause this.
> 
> What you're asking for here won't work; arm64 devices don't/can't use
> the embedding MBR/gap style of GRUB installation - that's x86 only. Instead,
> what you need is to do an EFI installation but with a couple of extra
> options chosen. Run "dpkg-reconfigure -plow grub-efi-arm64" and say:
> 
>  * "yes" to "Force extra installation to the EFI removable media path?"
>  * "no" to "Update NVRAM variables to automatically boot into Debian?"
> 
> and and you should be fine from now on.

Justify the statement "arm64 devices don't/can't use the embedding
MBR/gap style of GRUB installation".  I concur that is not the normal way
of doing EFI installation on ARM64 devices, but in this case I've got a
device which is unable to store persistent variables (if you sacrifice a
SD Card it can store them, but otherwise it loses them on restart).

Yet somehow despite restarting from a mostly clean slate an older
installation of 2.02+dfsg1-20+deb10u4 keeps managing to manifest, while
2.04-20 is unable to be loaded.

My conclusion is 2.02+dfsg1-20+deb10u4 was able to successfully install
in the embedding area despite not being supposed to work.  Meanwhile I'm
guessing Tianocore/ARM64 inherited the ability to boot from the embedding
area, despite using that being strongly discouraged.

Or at least that is a simple explanation for why traces of
2.02+dfsg1-20+deb10u4 continue to persist, while 2.04-20 appears
reluctant.

(now back to pondering whether grub-uboot may still be a more
maintainable for this installation)


-- 
(\___(\___(\__  --=> 8-) EHM <=--  __/)___/)___/)
 \BS (| ehem+sig...@m5p.com  PGP 87145445 |)   /
  \_CS\   |  _  -O #include  O-   _  |   /  _/
8A19\___\_|_/58D2 7E3D DDF4 7BA6 <-PGP-> 41D1 B375 37D0 8714\_|_/___/5445

Bug#997845: Info received (Bug#997845: growlight: autopkgtest regression: log repeats until it times out)

[nick black]

wait, i just might have reproduced a failure. it doesn't look
like our failure in autopkgtests, but this is an assert()
blowing up, and i'm not certain we build with those. if not,
maybe we're hitting a case that locks up. let's hope so!

this would once again presumably be a notcurses fix.

the breakage doesn't happen all the time, but it can be provoked
without too much trouble:

No ZFS support in this build.
Couldn't read link at /sys/class/block/securityfs (No such file or directory)
Couldn't read link at /sys/class/block/cgroup2 (No such file or directory)
Couldn't read link at /sys/class/block/pstore (No such file or directory)
Couldn't read link at /sys/class/block/efivarfs (No such file or directory)
Couldn't read link at /sys/class/block/none (No such file or directory)
Couldn't read link at /sys/class/block/systemd-1 (No such file or directory)
Couldn't read link at /sys/class/block/hugetlbfs (No such file or directory)
Couldn't read link at /sys/class/block/mqueue (No such file or directory)
Couldn't read link at /sys/class/block/tracefs (No such file or directory)
Couldn't read link at /sys/class/block/configfs (No such file or directory)
Couldn't read link at /sys/class/block/none (No such file or directory)
Couldn't read link at /sys/class/block/zhomez (No such file or directory)
Couldn't read link at /sys/class/block/chungus (No such file or directory)
Couldn't read link at /sys/class/block/tracefs (No such file or directory)
growlight-readline: ./src/lib/in.c:1852: process_escape: Assertion 
`ictx->amata.used < buflen' failed.
;147;rgb:afaf/afaf/^[\^[]4;148;rgb:afaf/d7d7/^[\^[]4;149;rgb:afaf/d7d7/5f5f^[\^[]4;150;rgb:afaf/d7d7/8787^[\^[]4;151;rgb:afaf/d7d7/afaf^[\^[]4;152;rgb:afaf/d7d7/d7d7^[\^[]4;153;rgb:afaf/d7d7/^[\^[]4;154;rgb:afaf//^[\^[]4;155;rgb:afaf//5f5f^[\^[]4;156;rgb:afaf//8787^[\^[]4;157;rgb:afaf//afaf^[\^[]4;158;rgb:afaf//d7d7^[\^[]4;159;rgb:afaf//^[\^[]4;160;rgb:d7d7//^[\^[]4;161;rgb:d7d7//5f5f^[\^[]4;162;rgb:d7d7//8787^[\^[]4;163;rgb:d7d7//afaf^[\^[]4;164;rgb:d7d7//d7d7^[\^[]4;165;rgb:d7d7//^[\^[]4;166;rgb:d7d7/5f5f/^[\^[]4;167;rgb:d7d7/5f5f/5f5f^[\^[]4;168;rgb:d7d7/5f5f/8787^[\^[]4;169;rgb:d7d7/5f5f/afaf^[\^[]4;170;rgb:d7d7/5f5f/d7d7^[\^[]4;171;rgb:d7d7/5f5f/^[\^[]4;172;rgb:d7d7/8787/^[\^[]4;173;rgb:d7d7/8787/5f5f^[\^[]4;174;rgb:d7d7/8787/8787^[\^[]4;175;rgb:d7d7/8787/afaf^[\^[]4;176;rgb:d7d7/8787/d7d7^[\^[]4;177;rgb:d7d7/8787/^[\^[]4;178;rgb:d7d7/afaf/^[\^[]4;179;rgb:d7d7/afaf/5f5f^[\^[]4;180;rgb:d7d7/afaf/8787^[\^[]4;181;rgb:d7d7/afaf/afaf^[\^[]4;182;rgb:d7d7/afaf/d7d7^[\^[]4;183;rgb:d7d7/afaf/^[\^[]4;184;rgb:d7d7/d7d7/^[\^[]4;185;rgb:d7d7/d7d7/5f5f^[\^[]4;186;rgb:d7d7/d7d7/8787^[\^[]4;187;rgb:d7d7/d7d7/afaf^[\^[]4;188;rgb:d7d7/d7d7/d7d7^[\^[]4;189;rgb:d7d7/d7d7/^[\^[]4;190;rgb:d7d7//^[\^[]4;191;rgb:d7d7//5f5f^[\^[]4;192;rgb:d7d7//8787^[\^[]4;193;rgb:d7d7//afaf^[\^[]4;194;rgb:d7d7//d7d7^[\^[]4;195;rgb:d7d7//^[\^[]4;196;rgb://^[\^[]4;197;rgb://5f5f^[\^[]4;198;rgb://8787^[\^[]4;199;rgb://afaf^[\^[]4;200;rgb://d7d7^[\^[]4;201;rgb://^[\^[]4;202;rgb:/5f5f/^[\^[]4;203;rgb:/5f5f/5f5f^[\^[]4;204;rgb:/5f5f/8787^[\^[]4;205;rgb:/5f5f/afaf^[\^[]4;206;rgb:/5f5f/d7d7^[\^[]4;207;rgb:/5f5f/^[\^[]4;208;rgb:/8787/^[\^[]4;209;rgb:/8787/5f5f^[\^[]4;210;rgb:/8787/8787^[\^[]4;211;rgb:/8787/afaf^[\^[]4;212;rgb:/8787/d7d7^[\^[]4;213;rgb:/8787/^[\^[]4;214;rgb:/afaf/^[\^[]4;215;rgb:/afaf/5f5f^[\^[]4;216;rgb:/afaf/8787^[\^[]4;217;rgb:/afaf/afaf^[\^[]4;218;rgb:/afaf/d7d7^[\^[]4;219;rgb:/afaf/^[\^[]4;220;rgb:/d7d7/^[\^[]4;221;rgb:/d7d7/5f5f^[\^[]4;222;rgb:/d7d7/8787^[\^[]4;223;rgb:/d7d7/afaf^[\^[]4;224;rgb:/d7d7/d7d7^[\^[]4;225;rgb:/d7d7/^[\^[]4;226;rgb://^[\^[]4;227;rgb://5f5f^[\^[]4;228;rgb://8787^[\^[]4;229;rgb://afaf^[\^[]4;230;rgb://d7d7^[\^[]4;231;rgb://^[\^[]4;232;rgb:0808/0808/0808^[\^[]4;233;rgb:1212/1212/1212^[\^[]4;234;rgb:1c1c/1c1c/1c1c^[\^[]4;235;rgb:2626/2626/2626^[\^[]4;236;rgb:3030/3030/3030^[\^[]4;237;rgb:3a3a/3a3a/3a3a^[\^[]4;238;rgb://^[\^[]4;239;rgb:4e4e/4e4e/4e4e^[\^[]4;240;rgb:5858/5858/5858^[\^[]4;241;rgb:6262/6262/6262^[\^[]4;242;rgb:6c6c/6c6c/6c6c^[\^[]4;243;rgb:7676/7676/7676^[\^[]4;244;rgb:8080/8080/8080^[\^[]4;245;rgb:8a8a/8a8a/8a8a^[\^[]4;246;rgb:9494/9494/9494^[\^[]4;247;rgb:9e9e/9e9e/9e9e^[\^[]4;248;rgb:a8a8/a8a8/a8a8^[\^[]4;249;rgb:b2b2/b2b2/b2b2^[\^[]4;250;rgb:bcbc/bcbc/bcbc^[\^[]4;251;rgb:c6c6/c6c6/c6c6^[\^[]4;252;rgb:d0d0/d0d0/d0d0^[\^[]4;253;rgb:dada/dada/dada^[\^[]4;254;rgb:e4e4/e4e4/e4e4^[\^[]4;255;rgb://^[\^[]10;rgb://^[\^[]11;rgb:0808/0808/0808^[\^[[?11u^[[?2026;2$y^[_Gi=1;EINVAL:Zero
 width/height not allowed^[\^[[4;1035;1584t^[[8;45;132t^[[?62;cAborted

Bug#1003073: xxhash: Please package new upstream version 0.8.1

[Bálint Réczey]

Source: xxhash
Version: 0.8.0-2
Severity: wishlist

Hi Norbert,

The new version promises nice performance improvement:

https://github.com/Cyan4973/xxHash/releases/tag/v0.8.1 :
...
While the "big picture" is unchanged, there are a few notable improvements.
XXH3 / XXH128 feature a large speed improvement in streaming mode,
which is particularly sensible for gcc and MSVC (clang was already in
good shape), by as much as +40%, making streaming speed essentially on
par with single-shot mode when ingesting large quantities of data.
...

Cheers,
Balint

Bug#1003071: logs

[heenec]

Sorry, I forgot the attachment. Here it is.

Bug#997845: Info received (Bug#997845: growlight: autopkgtest regression: log repeats until it times out)

[nick black]

further investigation: i uploaded -4 with a change to simply
redirect input from /dev/null, rather than echoing 'blockdev -v'
into the process. the result was pretty much the exact same: we
don't see the input show up, and we get a time out. of course,
attempting to reproduce this locally leads to the test
immediately exiting on EOF as expected =\.

i notice the command to run the test is rather complicated:

su -s /bin/bash root -c set -e; export USER=`id -nu`; . /etc/profile >/dev/null 
2>&1 || true;  . ~/.profile >/dev/null 2>&1 || true; 
buildtree="/tmp/autopkgtest-lxc.glluyzfl/downtmp/build.A7s/src"; mkdir -p -m 
1777 -- "/tmp/autopkgtest-lxc.glluyzfl/downtmp/devnull-artifacts"; export 
AUTOPKGTEST_ARTIFACTS="/tmp/autopkgtest-lxc.glluyzfl/downtmp/devnull-artifacts";
 export ADT_ARTIFACTS="$AUTOPKGTEST_ARTIFACTS"; mkdir -p -m 755 
"/tmp/autopkgtest-lxc.glluyzfl/downtmp/autopkgtest_tmp"; export 
AUTOPKGTEST_TMP="/tmp/autopkgtest-lxc.glluyzfl/downtmp/autopkgtest_tmp"; export 
ADTTMP="$AUTOPKGTEST_TMP"; export DEBIAN_FRONTEND=noninteractive; export 
LANG=C.UTF-8; export DEB_BUILD_OPTIONS=parallel=160; unset LANGUAGE LC_CTYPE 
LC_NUMERIC LC_TIME LC_COLLATE   LC_MONETARY LC_MESSAGES LC_PAPER LC_NAME 
LC_ADDRESS   LC_TELEPHONE LC_MEASUREMENT LC_IDENTIFICATION LC_ALL;rm -f 
/tmp/autopkgtest_script_pid; set -C; echo $$ > /tmp/autopkgtest_script_pid; set 
+C; trap "rm -f /tmp/autopkgtest_script_pid" EXIT INT QUIT PIPE; cd 
"$buildtree"; export AUTOPKGTEST_NORMAL_USER=debci; export 
ADT_NORMAL_USER=debci; touch 
/tmp/autopkgtest-lxc.glluyzfl/downtmp/devnull-stdout 
/tmp/autopkgtest-lxc.glluyzfl/downtmp/devnull-stderr; bash -ec 
'TERM=xterm-256color growlight-readline -v < /dev/null' 2> >(tee -a 
/tmp/autopkgtest-lxc.glluyzfl/downtmp/devnull-stderr >&2) > >(tee -a 
/tmp/autopkgtest-lxc.glluyzfl/downtmp/devnull-stdout);"

maybe our answer lives in this setup? it seems we're redirecting
both stdout and stderr (makes sense)...what else here is
different from our setup? LANG is defined to C.UTF-8. we're
defining TERM ourselves. Notcurses is getting sensibly
initialized. we're just never receiving input, nor an indication
that input is exhausted...

Bug#1003071: xserver-xorg-video-nouveau: Bad memory deallocation inside nouveau kernel module, leading to freezes

[heenec]

Package: xserver-xorg-video-nouveau
Version: 1:1.0.17-1
Severity: important


Screen completely freezes after some amount of starting GUI
applications and interacting with their windows. A reliable way to
trigger this bug is to run applications with big amount of UI elements.
For example, start Thunderbird and LibreOffice (in this order) at the
same time. It will probaly freeze after an attempt to start
LibreOffice. If not, open a dozen of new documents in LibreOffice, try
to rearrange windows on screen, change virtual desktops several times,
open a web browser... Eventually after all this fuzzing the screen will
freeze.

How it looks like: there are frames of windows on screen with
unrendered internal part. The instead of internal part of these windows
there are often parts of image, which was on screen before freeze. No
reaction on any keyboard interaction, even on trying to change to
virtual terminal with Ctrl-Alt-F1. At the same time, mouse pointer in
most cases still can be moved on screen, but there is no reaction on
pressing mouse buttons.

After some time (5-15 minutes) the computer may unfreeze, but will
freeze again shortly after few attempts to interacts with it.

At the same time, computer remains accessible over SSH and can be
cleanly shut down with ACPI Power-Off button.

Examining syslog showed huge amount of warnings and stack traces from
kernel related to erroneous memory deallocations. See attachment.

Additional details:
 - Freezes occure regardless of whether Debian is run as Xen host, or
   without Xen.
 - Freezes started after upgrading from Buster to Bullseye.
 - Blacklisting nouveau in /etc/modprobe.d/ remove freezes. (But for
   this workaround I also need to turn on integrated GPU in BIOS and
   connect screen to DVI port on motherboard to make X working again.)


-- Package-specific info:
X server symlink status:

lrwxrwxrwx 1 root root 13 Oct 22  2016 /etc/X11/X -> /usr/bin/Xorg
-rwxr-xr-x 1 root root 274 Dec 16 19:08 /usr/bin/Xorg

VGA-compatible devices on PCI bus:
--
01:00.0 VGA compatible controller [0300]: NVIDIA Corporation G92 
[GeForce 9800 GT] [10de:0614] (rev a2)


/etc/X11/xorg.conf does not exist.

Contents of /etc/X11/xorg.conf.d:
-
total 4
-rw-r--r-- 1 root root 226 Jan 20  2019 90-xpra-virtual.conf

/etc/modprobe.d contains no KMS configuration files.

Kernel version (/proc/version):
---
Linux version 5.10.0-10-amd64 (debian-ker...@lists.debian.org) (gcc-10 
(Debian 10.2.1-6) 10.2.1 20210110, GNU ld (GNU Binutils for Debian) 
2.35.2) #1 SMP Debian 5.10.84-1 (2021-12-08)


Xorg X server log files on system:
--
-rw-r--r-- 1 rootroot15548 Mar 18  2018 /var/log/Xorg.2.log
-rw-r--r-- 1 useruser37608 May  3  2019 
/home/user/.local/share/xorg/Xorg.1.log

-rw-r--r-- 1 rootroot42217 Mar 13  2021 /var/log/Xorg.1.log
-rw-r--r-- 1 rootroot60330 Jan  3 15:05 /var/log/Xorg.0.log

Contents of most recent Xorg X server log file (/var/log/Xorg.0.log):
-
[39.172]
X.Org X Server 1.20.11
X Protocol Version 11, Revision 0
[39.172] Build Operating System: linux Debian
[39.172] Current Operating System: Linux mishascomp 5.10.0-10-amd64 
#1 SMP Debian 5.10.84-1 (2021-12-08) x86_64
[39.172] Kernel command line: BOOT_IMAGE=/vmlinuz-5.10.0-10-amd64 
root=/dev/mapper/main-rootfs ro quiet 
video=uvesafb:mode_option=1680x1050-24,mtrr=3,scroll=ywrap apparmor=1 
security=apparmor

[39.172] Build Date: 16 December 2021  05:08:23PM
[39.172] xorg-server 2:1.20.11-1+deb11u1 
(https://www.debian.org/support)

[39.172] Current version of pixman: 0.40.0
[39.172]Before reporting problems, check http://wiki.x.org
to make sure that you have the latest version.
[39.172] Markers: (--) probed, (**) from config file, (==) default 
setting,

(++) from command line, (!!) notice, (II) informational,
(WW) warning, (EE) error, (NI) not implemented, (??) unknown.
[39.172] (==) Log file: "/var/log/Xorg.0.log", Time: Mon Jan  3 
14:45:40 2022

[39.260] (==) Using config directory: "/etc/X11/xorg.conf.d"
[39.260] (==) Using system config directory 
"/usr/share/X11/xorg.conf.d"

[39.740] (==) No Layout section.  Using the first Screen section.
[39.740] (==) No screen section available. Using defaults.
[39.740] (**) |-->Screen "Default Screen Section" (0)
[39.740] (**) |   |-->Monitor ""
[39.742] (==) No monitor specified for screen "Default Screen 
Section".

Using a default monitor configuration.
[39.742] (==) Automatically adding devices
[39.742] (==) Automatically enabling devices
[39.742] (==) Automatically adding GPU devices
[39.742] (==) Max clients allowed: 256, resource mask: 0x1f
[39.824] (WW) The directory "/usr/share/fonts/X11/cyrillic" 

Bug#1003072: RFS: xca/2.4.0-1 -- x509 Certification Authority management tool based on Qt

[Thomas Ward]

Package: sponsorship-requests
Severity: normal

Dear mentors,

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

 * Package name: xca
   Version : 2.4.0-1
   Upstream Author : Christian Hohnstaedt 
 * URL : https://hohnstaedt.de/xca/
 * License : BSD-3-clause
 * Vcs : https://salsa.debian.org/debian/xca
   Section : x11

It builds those binary packages:

  xca - x509 Certification Authority management tool based on QT

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

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

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

  dget -x https://mentors.debian.net/debian/pool/main/x/xca/xca_2.4.0-1.dsc

Changes since the last upload:

 xca (2.4.0-1) unstable; urgency=medium
 .
   * New upstream release (2.4.0)
   * Additional changes:
 - Drop d/patches/0003-fix-autoheader.patch - this is already fixed
   in 2.4.0.
 - d/control: Add qttools5-dev package to build dependencies.
 - d/xca-dbgsym.lintian-overrides: Suppress a warning about ELF
   decoder in Lintian - seen in sbuild tests against Unstable.

Regards,
--
  Thomas Ward

Bug#1003069: openid exception "AttributeError: module 'base64' has no attribute 'decodestring'"

[Harald Welte]

Package: python3-django-allauth
Version: 0.44.0+ds-1
Severity: normal

I'm running a bullseye installation with mailman3-web and wanted to enable 
openid
authentication via the python3-django-allouth package.  However, when using it,
I get the following exception / backtrace:

ERROR:django.request:Internal Server Error: /accounts/openid/login/
Traceback (most recent call last):
  File "/usr/lib/python3/dist-packages/django/core/handlers/exception.py", line 
34, in inner
response = get_response(request)
  File "/usr/lib/python3/dist-packages/django/core/handlers/base.py", line 115, 
in _get_response
response = self.process_exception_by_middleware(e, request)
  File "/usr/lib/python3/dist-packages/django/core/handlers/base.py", line 113, 
in _get_response
response = wrapped_callback(request, *callback_args, **callback_kwargs)
  File "/usr/lib/python3/dist-packages/django/views/generic/base.py", line 71, 
in view
return self.dispatch(request, *args, **kwargs)
  File "/usr/lib/python3/dist-packages/django/views/generic/base.py", line 97, 
in dispatch
return handler(request, *args, **kwargs)
  File 
"/usr/lib/python3/dist-packages/allauth/socialaccount/providers/openid/views.py",
 line 45, in get
return self.perform_openid_auth(form)
  File 
"/usr/lib/python3/dist-packages/allauth/socialaccount/providers/openid/views.py",
 line 94, in perform_openid_auth
auth_request = client.begin(endpoint)
  File "/usr/lib/python3/dist-packages/openid/consumer/consumer.py", line 359, 
in begin
return self.beginWithoutDiscovery(service, anonymous)
  File "/usr/lib/python3/dist-packages/openid/consumer/consumer.py", line 382, 
in beginWithoutDiscovery
auth_req = self.consumer.begin(service)
  File "/usr/lib/python3/dist-packages/openid/consumer/consumer.py", line 610, 
in begin
assoc = self._getAssociation(service_endpoint)
  File "/usr/lib/python3/dist-packages/openid/consumer/consumer.py", line 1178, 
in _getAssociation
assoc = self.store.getAssociation(endpoint.server_url)
  File 
"/usr/lib/python3/dist-packages/allauth/socialaccount/providers/openid/utils.py",
 line 105, in getAssociation
base64.decodestring(stored_assoc.secret.encode("utf-8")),
AttributeError: module 'base64' has no attribute 'decodestring'


It seems like base64.decodestring() has been deprecated since python 3.8 but 
somehow this module
has not been updated.

Upstream has a fix in 
https://github.com/pennersr/django-allauth/commit/425dc774fb5d032204b92f0870c3802202259ad3


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

Kernel: Linux 5.14.0-4-amd64 (SMP w/4 CPU threads)
Kernel taint flags: TAINT_DIE, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/bash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages python3-django-allauth depends on:
ii  python33.9.8-1
ii  python3-cryptography   3.4.8-1
ii  python3-django 2:3.2.10-2
ii  python3-jwt2.1.0-1
pn  python3-openid 
ii  python3-requests   2.25.1+dfsg-2
pn  python3-requests-oauthlib  

python3-django-allauth recommends no packages.

Versions of packages python3-django-allauth suggests:
pn  python-django-allauth-doc  

Bug#1003068: RM: caffe -- ROM; obsolete; has been replaced by new libraries

[Mo Zhou]

Package: ftp.debian.org
Severity: normal

Dear ftp masters,

I'd like to request for the removal of src:caffe from unstable.
This is an old deep learning framework, and has in fact stopped
being developed. Nowadays people use the newer alternatives such
as pytorch and tensorflow. I don't think keeping src:caffe in
our archive will make any difference in the future. So let's
just throw away what should fade out.

Thank you for using reportbug

Bug#1003067: sssd: ssd offline SASL: No worthy mechs found

[leonardo]

Package: sssd
Version: 2.6.1-1
Severity: important
X-Debbugs-Cc: leone2...@leone2000.net

Dear Maintainer,

I had some authentication problems, in /var/log/sssd/sssd_.log:

   *  (2022-01-02  0:01:25): [be[MYDOMAIN]] [sasl_bind_send] (0x0100): 
Executing sasl bind mech: GSS-SPNEGO, user: PCLEONOVO$
   *  (2022-01-02  0:01:25): [be[MYDOMAIN]] [ad_sasl_log] (0x0040): SASL: No 
worthy mechs found
** BACKTRACE DUMP ENDS HERE 
*

(2022-01-02  0:01:25): [be[MYDOMAIN]] [sasl_bind_send] (0x0020): 
ldap_sasl_interactive_bind_s failed (-6)[Unknown authentication method]
(2022-01-02  0:01:25): [be[MYDOMAIN]] [sdap_cli_connect_recv] (0x0040): Unable 
to establish connection [1432158227]: Authentication Failed
** PREVIOUS MESSAGE WAS TRIGGERED BY THE FOLLOWING 
BACKTRACE:
   *  (2022-01-02  0:01:25): [be[MYDOMAIN]] [sasl_bind_send] (0x0020): 
ldap_sasl_interactive_bind_s failed (-6)[Unknown authentication method]
   *  (2022-01-02  0:01:25): [be[MYDOMAIN]] [sasl_bind_send] (0x0080): Extended 
failure message: [SASL(-4): no mechanism available: No worthy mechs found]
   *  (2022-01-02  0:01:25): [be[MYDOMAIN]] [sdap_cli_connect_recv] (0x0040): 
Unable to establish connection [1432158227]: Authentication Failed
** BACKTRACE DUMP ENDS HERE 
*

I tried to unjoin and now, when i try to join again, adcli returns:

 * Using GSS-SPNEGO for SASL bind
 ! Couldn't authenticate to active directory: SASL(-4): no mechanism available: 
No worthy mechs found
adcli: couldn't connect to MYDOMAIN domain: Couldn't authenticate to active 
directory: SASL(-4): no mechanism available: No worthy mechs found
 ! Insufficient permissions to join the domain
realm: Couldn't join realm: Insufficient permissions to join the domain

This happened after upgrade from from 2.5.2 to 2.6.1 (no problem with 2.5.2), 
the AD domain is Windows 2012r2 patched with november 2021 updates.


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

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

Versions of packages sssd depends on:
ii  python3-sss  2.6.1-1
ii  sssd-ad  2.6.1-1
ii  sssd-common  2.6.1-1
ii  sssd-ipa 2.6.1-1
ii  sssd-krb52.6.1-1
ii  sssd-ldap2.6.1-1
ii  sssd-proxy   2.6.1-1

sssd recommends no packages.

sssd suggests no packages.

-- no debconf information

Bug#1003066: nagios4-cgi: external references, ads and tracking

[Adolf Markus Berthold]

Package: nagios4-cgi
Version: 4.4.6-4
Severity: normal

Dear Maintainer,

some of the cgi-pages of Nagios4 include a feature named 'Page Tour'. Everytime
a user views one of those pages, his browser also fetches code from YouTube, 
which
in turn registers for ads and tracking. Since ads and user-tracking are 
supposedly
not Debian-style, the page-tour-feature should be disabled by default (and 
marked
with a warning-comment) in /etc/nagios4/cgi.cfg.


Greetings ... AMB




===

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

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

Versions of packages nagios4-cgi depends on:
ii  adduser 3.118
ii  apache2-utils   2.4.48-3.1+deb11u1
ii  coreutils   8.32-4+b1
ii  libapache2-mod-php7.4 [libapache2-mod-php]  7.4.21-1+deb11u1
ii  libc6   2.31-13+deb11u2
ii  libgd3  2.3.0-2
ii  libjs-jquery3.5.1+dfsg+~3.5.5-7
ii  nagios4-common  4.4.6-4
ii  php7.4 [php]7.4.21-1+deb11u1
ii  ucf 3.0043

Versions of packages nagios4-cgi recommends:
ii  apache2 [httpd]  2.4.48-3.1+deb11u1
ii  nagios-images0.9.4

nagios4-cgi suggests no packages.

-- Configuration Files:
/etc/nagios4/cgi.cfg changed [not included]

-- no debconf information

Bug#1002697: (no subject)

[leonardo]

Hi, same problem is on sssd, when I upgrade from 2.5.2 to 2.6.1, 
probably the bug is not adcli related.


I tried to unjoin because I had some authentication problems, in 
/var/log/sssd/sssd_.log


   *  (2022-01-02  0:01:25): [be[MYDOMAIN]] [sasl_bind_send] (0x0100): 
Executing sasl bind mech: GSS-SPNEGO, user: PCLEONOVO$
   *  (2022-01-02  0:01:25): [be[MYDOMAIN]] [ad_sasl_log] (0x0040): 
SASL: No worthy mechs found
** BACKTRACE DUMP ENDS HERE 
*


(2022-01-02  0:01:25): [be[MYDOMAIN]] [sasl_bind_send] (0x0020): 
ldap_sasl_interactive_bind_s failed (-6)[Unknown authentication method]
(2022-01-02  0:01:25): [be[MYDOMAIN]] [sdap_cli_connect_recv] (0x0040): 
Unable to establish connection [1432158227]: Authentication Failed
** PREVIOUS MESSAGE WAS TRIGGERED BY THE FOLLOWING 
BACKTRACE:
   *  (2022-01-02  0:01:25): [be[MYDOMAIN]] [sasl_bind_send] (0x0020): 
ldap_sasl_interactive_bind_s failed (-6)[Unknown authentication method]
   *  (2022-01-02  0:01:25): [be[MYDOMAIN]] [sasl_bind_send] (0x0080): 
Extended failure message: [SASL(-4): no mechanism available: No worthy 
mechs found]
   *  (2022-01-02  0:01:25): [be[MYDOMAIN]] [sdap_cli_connect_recv] 
(0x0040): Unable to establish connection [1432158227]: Authentication Failed
** BACKTRACE DUMP ENDS HERE 
*


now, when i try to join again:

 * Using GSS-SPNEGO for SASL bind
 ! Couldn't authenticate to active directory: SASL(-4): no mechanism 
available: No worthy mechs found
adcli: couldn't connect to MYDOMAIN domain: Couldn't authenticate to 
active directory: SASL(-4): no mechanism available: No worthy mechs found

 ! Insufficient permissions to join the domain
realm: Couldn't join realm: Insufficient permissions to join the domain

Bug#1003065: reportbug: crash (exception) on startup with locale de_DE@euro

[Adolf Markus Berthold]

Package: reportbug
Version: 7.10.3+deb11u1
Severity: normal
Tags: l10n

Dear Maintainer,

reportbug (console-version) raises an exception when called with the locale
de_DE@euro :

-8<
:~$ LANG=de_DE@euro reportbug
UnicodeDecodeError: 'utf-8' codec can't decode byte 0xe4 in position 3: invalid 
continuation byte

The above exception was the direct cause of the following exception:

SystemError:  returned a result with an error set

The above exception was the direct cause of the following exception:

SystemError:  returned a result with an error set

The above exception was the direct cause of the following exception:

SystemError:  returned a result with an error set

The above exception was the direct cause of the following exception:

SystemError:  returned a result with an error set

The above exception was the direct cause of the following exception:

Traceback (most recent call last):
  File "/usr/bin/reportbug", line 44, in 
from reportbug import utils
  File "/usr/lib/python3/dist-packages/reportbug/utils.py", line 109, in 

_apt_cache = apt.Cache()
  File "/usr/lib/python3/dist-packages/apt/cache.py", line 152, in __init__
self.open(progress)
  File "/usr/lib/python3/dist-packages/apt/cache.py", line 214, in open
self._cache = apt_pkg.Cache(progress)
SystemError:  returned a result with an error set
-8<

With the C-Locate, it works:

-8<
:~$ LANG= reportbug
Please enter the name of the package in which you have found a problem, or type 
'other' to report a more general
problem. If you don't know what package the bug is in, please contact 
debian-u...@lists.debian.org for assistance.
> 
reportbug: exiting due to user interrupt.
-8<

If the Program is intended not to work without an UTF-8-Locate, it should at 
least bail out with an error-message
and not raise an exception.



Greetings ... AMB



==



-- Package-specific info:
** Environment settings:
INTERFACE="text"

** /home//.reportbugrc:
reportbug_version "7.10.3+deb11u1"
mode standard
ui text
realname "Adolf Markus Berthold"
email "d...@berdisys.net"

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

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

Versions of packages reportbug depends on:
ii  apt2.2.4
ii  python33.9.2-3
ii  python3-reportbug  7.10.3+deb11u1
ii  sensible-utils 0.0.14

reportbug recommends no packages.

Versions of packages reportbug suggests:
pn  claws-mail  
pn  debconf-utils   
pn  debsums 
pn  dlocate 
ii  dma [mail-transport-agent]  0.13-1
pn  emacs-bin-common
ii  file1:5.39-3
ii  gnupg   2.2.27-2
pn  python3-urwid   
pn  reportbug-gtk   
ii  xdg-utils   1.1.3-4.1

Versions of packages python3-reportbug depends on:
ii  apt2.2.4
ii  file   1:5.39-3
ii  python33.9.2-3
ii  python3-apt2.2.1
ii  python3-debian 0.1.39
ii  python3-debianbts  3.1.0
ii  python3-requests   2.25.1+dfsg-2
ii  sensible-utils 0.0.14

python3-reportbug suggests no packages.

-- no debconf information

Bug#954247: postfix: postfix.service has status active after systemd instance unit failed to start

[Scott Kitterman]

On Thu, 19 Mar 2020 08:47:58 -0400 Scott Kitterman  
wrote:
> On Thursday, March 19, 2020 5:38:15 AM EDT Christian Göttsche wrote:
> > currently the instance unit postfix@.service is linked with PartOf= to
> > the main postfix.service.
> > This results in a active postfix.service in case the instance
> > postfix@.service has failed to start.
> > Is this by design or is a stronger bonding appropriate?
> 
> This is by design to enable multi-instance support.  I'm open to suggestions 
> on where to better document this so people are more likely to know it.  I 
can 
> understand it's not particularly intuitive for people running single 
> instances.

I've reviewed README.Debian and this is described in detail there, so I don't 
know what more can be done in terms of documentation.  I agree it's not super 
intuitive, but I don't think there is anything to 'fix', so I'm going to mark 
this wontfix rather than close it so it'll be easier to find by others.

Scott K

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

Bug#1003064: xshisen: cannot show the personal score

[Nobuhiro Ban]

Package: xshisen
Version: 1:1.51-7
Severity: normal
Tags: patch

Dear Maintainer,

xshisen (amd64) crashes when trying to show the personal score.


How to repeat
-

(1) If you have no ~/.xshisen.scores file, play the game once.
(2) Select Menu: Game -> Personal Score
or
hit Ctrl-t.


Analysis


It crashes in Score::PersonalStat(int) by segmentation fault.

>From the build log
>score.C: In member function ‘int Score::PersonalStat(int)’:
>score.C:622:1: warning: control reaches end of non-void function 
>[-Wreturn-type]
>  622 | }
>  | ^


According to the GCC manual, this causes undefined behavior.
So it may crash.

https://gcc.gnu.org/onlinedocs/gcc/Warning-Options.html
> -Wreturn-type
(snip)
> Unlike in C, in C++, flowing off the end of a non-void function other than
> main results in undefined behavior even when the value of the function is
> not used.


How to fix
--

Inserting "return 0;" at the end of this function fixes this problem.

- Begin
--- xshisen-1.51.orig/score.C
+++ xshisen-1.51/score.C
@@ -619,6 +619,7 @@ Score::PersonalStat(int kind_of_game)
 bufp += strlen(bufp);
 *bufp = '\0';
 Popup(buf);
+return 0;
 }

 int
- End


Regards,
Nobuhiro Ban



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

Kernel: Linux 5.15.0-2-amd64 (SMP w/4 CPU threads)
Kernel taint flags: TAINT_FIRMWARE_WORKAROUND
Locale: LANG=ja_JP.UTF-8, LC_CTYPE=ja_JP.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 xshisen depends on:
ii  libc6   2.33-1
ii  libgcc-s1   11.2.0-13
ii  libstdc++6  11.2.0-13
ii  libx11-62:1.7.2-2+b1
ii  libxm4  2.3.8-3
ii  libxpm4 1:3.5.12-1
ii  libxt6  1:1.2.0-1

xshisen recommends no packages.

xshisen suggests no packages.

-- debconf-show failed

Bug#1003063: RFS: su-exec/0.2-1 [ITP] -- switch user and group id, setgroups and exec

[Matteo Chesi]

Package: sponsorship-requests
Severity: wishlist

Dear mentors,

I am looking for a sponsor for my package "su-exec":

 * Package name: su-exec
   Version : 0.2-1
   Upstream Author : Natanael Copa 
 * URL : https://github.com/ncopa/su-exec
 * License : MIT
 * Vcs : [fill in URL of packaging vcs]
   Section : admin

It builds those binary packages:

  su-exec - switch user and group id, setgroups and exec

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


  https://mentors.debian.net/package/su-exec/

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


  dget -x 
https://mentors.debian.net/debian/pool/main/s/su-exec/su-exec_0.2-1.dsc


Changes for the initial release:

 su-exec (0.2-1) UNRELEASED; urgency=low
 .
   * Initial release (Closes: #1003059).

Regards,
--
  Matteo Chesi

Bug#1002703: bullseye-pu: package libarchive/3.4.3-2+deb11u1

[Peter Pentchev]

On Thu, Dec 30, 2021 at 09:10:34PM +0100, Salvatore Bonaccorso wrote:
> Hi Peter,
> 
> On Mon, Dec 27, 2021 at 10:10:58PM +0200, Peter Pentchev wrote:
> > Package: release.debian.org
> > Severity: normal
> > Tags: bullseye
> > User: release.debian@packages.debian.org
> > Usertags: pu
> > X-Debbugs-Cc: r...@ringlet.net
> > 
> > [ Reason ]
> > This is a future unblock request before I upload
> > libarchive-3.4.3-2+deb11u1 to fix a couple of bugs that were
> > fixed in later upstream versions and in unstable. They are all
> > related to setting permissions and ACLs when extracting
> > archive members that represent symbolic and hard links.
> > 
> > [ Impact ]
> > Extracting some (rarely seen) archives may result in files
> > having the wrong access permissions.
> > 
> > [ Tests ]
> > All the added patches are taken from upstream commits that
> > include both the bugfixes and the testsuite additions to
> > check for regressions.
> > 
> > [ Risks ]
> > The code is mostly easy to follow, the fixes are straightforward.
> > 
> > [ 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 stable
> >   [x] the issue is verified as fixed in unstable
> > 
> > [ Changes ]
> > - correctly extract a hardlink to a symlink using the linkat(2)
> >   system call
> > - do not change the ACLs on symlinks, since that would affect
> >   the symlink target instead
> > - do not accidentally change the access mode of a symlink target
> >   when a change to the symlink's mode was intended
> > 
> > [ Other info ]
> > Thanks in advance for looking at this, and keep up the great work!
> 
> > diff -Nru libarchive-3.4.3/debian/changelog 
> > libarchive-3.4.3/debian/changelog
> > --- libarchive-3.4.3/debian/changelog   2020-08-01 21:46:12.0 
> > +0300
> > +++ libarchive-3.4.3/debian/changelog   2021-12-27 18:45:51.0 
> > +0200
> > @@ -1,3 +1,12 @@
> > +libarchive (3.4.3-2+deb11u1) bullseye; urgency=medium
> > +
> > +  * Add four upstream fixes for various problems:
> > +- fix extracting hardlinks to symlinks
> > +- fix handling of symlink ACLs; Closes: 1001986
> > +- never follow symlinks when setting file flags; Closes: 1001990
> 
> While at it, can you as well add the CVE references to the
> debian/changelog?

Right... I'm not very smart these days, am I? Thanks a lot for
your patience with me these past few weeks!

Attached is an updated debdiff, the only difference being the CVE
references added to the changelog entry.

G'luck,
Peter

-- 
Peter Pentchev  r...@ringlet.net r...@debian.org p...@storpool.com
PGP key:http://people.FreeBSD.org/~roam/roam.key.asc
Key fingerprint 2EE7 A7A5 17FC 124C F115  C354 651E EFB0 2527 DF13
diff -Nru libarchive-3.4.3/debian/changelog libarchive-3.4.3/debian/changelog
--- libarchive-3.4.3/debian/changelog   2020-08-01 21:46:12.0 +0300
+++ libarchive-3.4.3/debian/changelog   2021-12-27 18:45:51.0 +0200
@@ -1,3 +1,13 @@
+libarchive (3.4.3-2+deb11u1) bullseye; urgency=medium
+
+  * Add four upstream fixes for various problems:
+- fix extracting hardlinks to symlinks
+- CVE-2021-23177: fix handling of symlink ACLs; Closes: 1001986
+- CVE-2021-31566: never follow symlinks when setting file flags;
+  Closes: 1001990
+
+ -- Peter Pentchev   Mon, 27 Dec 2021 18:45:51 +0200
+
 libarchive (3.4.3-2) unstable; urgency=medium
 
   * Add some more upstream patches:
diff -Nru libarchive-3.4.3/debian/patches/series 
libarchive-3.4.3/debian/patches/series
--- libarchive-3.4.3/debian/patches/series  2020-08-01 21:46:12.0 
+0300
+++ libarchive-3.4.3/debian/patches/series  2021-12-27 18:45:51.0 
+0200
@@ -8,3 +8,7 @@
 upstream-rar-read-format.patch
 upstream-memory-stdlib.patch
 upstream-max-comp-level.patch
+upstream-hardlinks-to-symlinks.patch
+upstream-symlink-acls.patch
+upstream-set-flags-nofollow.patch
+upstream-fixup-nofollow.patch
diff -Nru libarchive-3.4.3/debian/patches/upstream-fixup-nofollow.patch 
libarchive-3.4.3/debian/patches/upstream-fixup-nofollow.patch
--- libarchive-3.4.3/debian/patches/upstream-fixup-nofollow.patch   
1970-01-01 02:00:00.0 +0200
+++ libarchive-3.4.3/debian/patches/upstream-fixup-nofollow.patch   
2021-12-27 18:45:51.0 +0200
@@ -0,0 +1,168 @@
+Description: Do not follow symlinks when processing the fixup list
+ Published as CVE-2021-31566
+Origin: upstream, 
https://github.com/libarchive/libarchive/commit/b41daecb5ccb4c8e3b2c53fd6147109fc12c3043
+Bug-Debian: https://bugs.debian.org/1001990
+Author: Martin Matuska 
+Last-Update: 2021-12-20
+
+--- a/Makefile.am
 b/Makefile.am
+@@ -556,6 +556,7 @@
+   libarchive/test/test_write_disk.c \
+   libarchive/test/test_write_disk_appledouble.c \
+   libarchive/test/test_write_disk_failures.c \
++  libarchive/test/test_write_disk_fixup.c \
+   libarchive/test/test_write_disk_hardlink.c \
+ 

Bug#1003062: ITP: aiohttp-openmetrics -- openmetrics integration for aiohttp

[Jelmer Vernooij]

Package: wnpp
Severity: wishlist
Owner: Jelmer Vernooij 

* Package name: aiohttp-openmetrics
  Version : 0.0.3
  Upstream Author : Jelmer Vernooij 
* URL : https://github.com/jelmer/aiohttp-openmetrics
* License : Apachev2+
  Programming Lang: Python
  Description : openmetrics integration for aiohttp

Library that provides a standard /metrics target for aiohttp
applications, as well as a set of standard metrics.

Bug#1003061: dmrgpp: autopkgtest failure on armhf: segmentation fault

[Paul Gevers]

Source: dmrgpp
Version: 6.02-2
X-Debbugs-CC: debian...@lists.debian.org
Severity: serious
User: debian...@lists.debian.org
Usertags: fails-always timeout

Dear maintainer(s),

You recently added an autopkgtest to your package dmrgpp, great. 
However, it fails. Currently this failure is blocking the migration to 
testing [1]. Can you please investigate the situation and fix it?


I copied some of the output at the bottom of this report. Apperently the 
crash also doesn't stop the test, as it times out after 2:47h.


More information about this bug and the reason for filing it can be found on
https://wiki.debian.org/ContinuousIntegration/RegressionEmailInformation

Paul

[1] https://qa.debian.org/excuses.php?package=dmrgpp

https://ci.debian.net/data/autopkgtest/testing/armhf/d/dmrgpp/17804986/log.gz

Cloning into 'OraclesDmrg'...
From https://code.ornl.gov/gonzalo_3/OraclesDmrg
 * branchfeatures   -> FETCH_HEAD
Already up to date.
'../src/dmrg' -> 'tests/dmrg'
'../src/observe' -> 'tests/observe'
./ci.pl: WARNING: Ignored test 0 because it's an SU(2) test and you did 
not specify -su2
./ci.pl: WARNING: Ignored test 1 because it's an SU(2) test and you did 
not specify -su2

./ci.pl: Batch2.pbs written
./ci.pl: Batch3.pbs written
./ci.pl: Batch4.pbs written
./ci.pl: Batch5.pbs written
./ci.pl: WARNING: Ignored test 6 because it's an SU(2) test and you did 
not specify -su2

./ci.pl: Batch7.pbs written
./ci.pl: Batch8.pbs written
./ci.pl: Batch9.pbs written
./ci.pl: Batch10.pbs written
./ci.pl: Batch11.pbs written
./ci.pl: Batch12.pbs written
./ci.pl: Batch15.pbs written
./ci.pl: Batch18.pbs written
./ci.pl: Batch20.pbs written
./ci.pl: Batch20.pbs has been written in append mode.
./ci.pl: Batch22.pbs written
./ci.pl: Batch23.pbs written
./ci.pl: Batch23.pbs has been written in append mode.
./ci.pl: Batch25.pbs written
./ci.pl: Batch26.pbs written
./ci.pl: Batch28.pbs written
./ci.pl: Batch28.pbs has been written in append mode.
./ci.pl: Batch30.pbs written
./ci.pl: Batch32.pbs written
./ci.pl: WARNING: Ignored test 40 because it's an SU(2) test and you did 
not specify -su2
./ci.pl: WARNING: Ignored test 41 because it's an SU(2) test and you did 
not specify -su2

./ci.pl: Batch50.pbs written
./ci.pl: Batch52.pbs written
./ci.pl: Batch60.pbs written
./ci.pl: Batch61.pbs written
./ci.pl: Batch62.pbs written
./ci.pl: Batch62.pbs has been written in append mode.
./ci.pl: Batch65.pbs written
./ci.pl: WARNING: Ignored test 66 because it's an SU(2) test and you did 
not specify -su2
./ci.pl: WARNING: Ignored test 67 because it's an SU(2) test and you did 
not specify -su2

./ci.pl: Batch80.pbs written
./ci.pl: Batch82.pbs written
./ci.pl: Batch84.pbs written
./ci.pl: Batch85.pbs written
./ci.pl: Batch86.pbs written
./ci.pl: Batch100.pbs written
./ci.pl: Batch101.pbs written
./ci.pl: Batch103.pbs written
./ci.pl: Batch105.pbs written
./ci.pl: Batch105.pbs has been written in append mode.
./ci.pl: Batch112.pbs written
./ci.pl: Batch113.pbs written
./ci.pl: Batch120.pbs written
./ci.pl: Batch120.pbs has been written in append mode.
./ci.pl: Batch126.pbs written
./ci.pl: Batch126.pbs has been written in append mode.
./ci.pl: Batch150.pbs written
./ci.pl: Batch170.pbs written
./ci.pl: Batch172.pbs written
./ci.pl: Batch200.pbs written
./ci.pl: Batch200.pbs has been written in append mode.
./ci.pl: Batch250.pbs written
./ci.pl: Batch320.pbs written
./ci.pl: Batch340.pbs written
./ci.pl: Batch363.pbs written
./ci.pl: Batch410.pbs written
./ci.pl: Batch467.pbs written
./ci.pl: Batch550.pbs written
./ci.pl: Batch600.pbs written
./ci.pl: Batch1000.pbs written
./ci.pl: Batch1200.pbs written
./ci.pl: Batch1201.pbs written
./ci.pl: Batch1300.pbs written
./ci.pl: Batch1302.pbs written
./ci.pl: Batch1304.pbs written
./ci.pl: Batch1306.pbs written
./ci.pl: Batch1500.pbs written
./ci.pl: Batch1600.pbs written
./ci.pl: Batch1601.pbs written
./ci.pl: Batch1610.pbs written
./ci.pl: Batch1800.pbs written
./ci.pl: Batch1800.pbs has been written in append mode.
./ci.pl: Batch1810.pbs written
./ci.pl: Batch1810.pbs has been written in append mode.
./ci.pl: Batch1814.pbs written
./ci.pl: Batch1814.pbs has been written in append mode.
./ci.pl: Batch1814.pbs has been written in append mode.
./ci.pl: Batch1818.pbs written
./ci.pl: Batch1818.pbs has been written in append mode.
./ci.pl: Batch1850.pbs written
./ci.pl: Batch1850.pbs has been written in append mode.
./ci.pl: Batch1860.pbs written
./ci.pl: Batch1860.pbs has been written in append mode.
./ci.pl: Batch1950.pbs written
./ci.pl: Batch1950.pbs has been written in append mode.
./ci.pl: Batch1954.pbs written
./ci.pl: Batch1954.pbs has been written in append mode.
./ci.pl: Batch2021.pbs written
./ci.pl: Batch2024.pbs written
./ci.pl: Batch2028.pbs written
./ci.pl: Batch2029.pbs written
./ci.pl: Batch2040.pbs written
./ci.pl: Batch2045.pbs written
./ci.pl: Batch2048.pbs written
./ci.pl: Batch2061.pbs written
./ci.pl: Batch2071.pbs written
./ci.pl: Batch2080.pbs written

Bug#1002482: Close this bug

[clay stan]

dirsearch has been migrated to testing

Bug#1003060: systemsettings: Unable to Save the proxy settings

[Bob Wong]

Package: systemsettings
Version: 4:5.23.4-1
Severity: normal

Dear Maintainer,

 I just updated to the newest version of the package, but now I cannot set the
proxy settings correctly. The software doesn't save my configuration. When I
quit the software, it just recover to the default.


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

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

Versions of packages systemsettings depends on:
ii  kio 5.88.0-1
ii  kpackagetool5   5.88.0-1
ii  libc6   2.33-1
ii  libkf5activities5   5.88.0-1
ii  libkf5activitiesstats1  5.88.0-1
ii  libkf5auth5 5.88.0-1
ii  libkf5authcore5 5.88.0-1
ii  libkf5completion5   5.88.0-1
ii  libkf5configcore5   5.88.0-1
ii  libkf5configgui55.88.0-1
ii  libkf5configwidgets55.88.0-1
ii  libkf5coreaddons5   5.88.0-1
ii  libkf5crash55.88.0-1
ii  libkf5dbusaddons5   5.88.0-1
ii  libkf5i18n5 5.88.0-2
ii  libkf5iconthemes5   5.88.0-1
ii  libkf5itemmodels5   5.88.0-1
ii  libkf5itemviews55.88.0-1
ii  libkf5kcmutils5 5.88.0-1
ii  libkf5kiocore5  5.88.0-1
ii  libkf5kiogui5   5.88.0-1
ii  libkf5kiowidgets5   5.88.0-1
ii  libkf5notifications55.88.0-2
ii  libkf5package5  5.88.0-1
ii  libkf5quickaddons5  5.88.0-1
ii  libkf5runner5   5.88.0-1
ii  libkf5service-bin   5.88.0-1
ii  libkf5service5  5.88.0-1
ii  libkf5widgetsaddons55.88.0-2
ii  libkf5windowsystem5 5.88.0-1
ii  libkf5xmlgui5   5.88.0-1
ii  libkworkspace5-54:5.23.4-2
ii  libqt5core5a5.15.2+dfsg-14
ii  libqt5gui5  5.15.2+dfsg-14
ii  libqt5qml5  5.15.2+dfsg-9
ii  libqt5quick55.15.2+dfsg-9
ii  libqt5quickwidgets5 5.15.2+dfsg-9
ii  libqt5widgets5  5.15.2+dfsg-14
ii  libstdc++6  11.2.0-13
ii  qml-module-org-kde-kcm  5.88.0-1
ii  qml-module-org-kde-kirigami25.88.0-1
ii  qml-module-org-kde-kitemmodels  5.88.0-1
ii  qml-module-org-kde-newstuff 5.88.0-1
ii  qml-module-qtquick-controls 5.15.2-2
ii  qml-module-qtquick-layouts  5.15.2+dfsg-9
ii  qml-module-qtquick2 5.15.2+dfsg-9

systemsettings recommends no packages.

systemsettings suggests no packages.

-- no debconf information