Bug#1004428: [PATCH] Add remaining options to exiqgrep.8

[Andreas Metzler]

Control: tags -1 pending

On 2022-01-27 Janne Hess  wrote:
> Package: exim4
> Version: 4.95-3
> Tags: patch

> Hi,

> the provided patch adds al yet undocumented options to exiqgrep.8.
> I hope the quality matches your expectations.

Thank you Janne, committed to GIT.

cu Andreas

Bug#1004389: transition: botan

[GCS]

On Sat, Jan 29, 2022 at 10:11 AM Sebastian Ramacher
 wrote:
> On 2022-01-26 16:21:37 +0100, László Böszörményi wrote:
> > Straightforward transition of botan. Affected packages are biboumi,
> > rnp and thunderbird.
> > All builds fine with the botan 2.19.1+dfsg-1 version from experimental.
>
> Go ahead
 Uploaded and already built on all primary architectures. You can
schedule binNMUs as your time permits.

Thanks,
Laszlo/GCS

Bug#1003837: 1003...@bugs.debian.org

[Harald Dunkel]

upstream bug report: https://github.com/BZFlag-Dev/bzflag/issues/301

Bug#1004111: unattended-upgrades: regression: packages with conffile prompts are no longer skipped, leading to upgrade failures

[Paul Wise]

Control: severity -1 normal
Control: tags -1 + moreinfo
Control: retitle -1 unattended-upgrades: upgrade of chromium-browser and others 
skipped on Raspberry Pi OS

On Thu, 20 Jan 2022 16:42:21 -0600 Judah Richardson wrote:

> This bug has showing up on this end in unattended-upgrades 2.8 on my
> Raspberry Pi Model 3B+ running Raspberry Pi OS 11.2 since January 6, 2022.

Since Raspberry Pi OS is a derivative of Debian, not Debian itself,
bugs in Raspberry Pi OS should only be filed in the Debian bug tracker
when they can be reproduced in Debian itself too.

> unattended-upgrades: regression: packages with conffile prompts are no longer 
> skipped, leading to upgrade failures
...
> Here's the error email I received from root on January 6, 2022:

The subject of the bug report was about packages with conffile prompts
attempting to be upgraded instead of skipped, but the filed bug report
showed no failed upgrades, just skipped upgrades, so I retitled it.

The information included in the bug report also isn't enough to
determine why there are packages on the system that have been skipped
when upgrading.

Please supply the output of the following commands:

apt policy
apt policy chromium-browser chromium-browser-l10n chromium-codecs-ffmpeg-extra 
libraspberrypi0 libraspberrypi-bin libraspberrypi-dev libraspberrypi-doc 
lxplug-updater lynis raspberrypi-bootloader raspberrypi-kernel vcdbg
apt upgrade --simulate
apt full-upgrade --simulate
aptitude upgrade --simulate
aptitude dist-upgrade --simulate
apt upgrade
apt full-upgrade

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


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

Bug#1002872: Can this be unblocked now?

[Shmerl]

Looks like it should be just a build time config switch fix.

Shmerl.

Bug#1002805: closed by Michael Biebl (Re: Bug#1002805: systemd: Upon mount, immediately umounts external drives not connected at boot)

[TomK]

I can no longer reproduce the problem. Sorry for the long delay. I have
a really busy time these days. Mount seems to work seemlessly on USB
drives. Thanks, whoever fixed it.



On Tue, 2022-01-18 at 19:36 +, Debian Bug Tracking System wrote:
> This is an automatic notification regarding your Bug report
> which was filed against the systemd package:
> 
> #1002805: systemd: Upon mount, immediately umounts external drives
> not connected at boot
> 
> It has been closed by Michael Biebl .
> 
> Their explanation is attached below along with your original report.
> If this explanation is unsatisfactory and you have not received a
> better one in a separate message then please contact Michael Biebl
>  by
> replying to this email.
> 
> 

Bug#1004535: ITP: ebusd -- daemon for handling communication with eBUS ('Energy Bus') devices

[Wookey]

Package: wnpp
Severity: wishlist
Owner: Wookey 

* Package name: ebusd
  Version : 21.3
  Upstream Author : John Baier 
* URL : https://ebusd.eu/
* License : GPL3 or later
  Programming Lang: C++
  Description : Daemon for handling communication with eBUS ('Energy Bus') 
devices

eBUS is a 2-wire serial bus used by some (mostly German-manufactured)
heating, ventilation and solar systems for communication.
The daemon can send, receive, cache and poll for messages, and scan the bus for 
devices.
It can log via syslogd, and save messages in human-readbale form.
There is a command-line interface, and a simple HTML interface to allow data 
retrieval as JSON
Messages can be published to (and from, if authorised) MQTT topics.
There is an ACL file for optional user authentication.

sysvinit and systemd are supported.

A suitable hardware interface is needed to use this software. Details
of an open interface which supports USB serial, rPi IO, and ethernet
and wifi with suitable modules are on the wiki:
https://adapter.ebusd.eu/index.en.html

Bug#1004534: Please promote version 1.38.0-1 to unstable

[Eric Dorland]

Source: golang-google-grpc
Version: 1.27.1-1
Severity: wishlist

Please upload 1.38.0-1 to unstable so that it can be used for packages there. 
It's a requirement to upload dnscrypt-proxy 2.1.1 for example.

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

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

Bug#998280: Please switch the dependency from ttf-bitstream-vera to fonts-dejavu-core

[Ross Vandegrift]

On Sun, Jan 30, 2022 at 12:01:51AM +, Amr Ibrahim wrote:
> Am Donnerstag, dem 27.01.2022 um 21:05 -0800 schrieb Ross Vandegrift:
> > Is ttf-bitstream-vera going away?
> 
> No, ttf-bitstream-vera is not going away because there are still many
> packages that depend on it.
> 
> The real issue of the Bitstream Vera font is that when it's installed,
> it takes precedence over the DejaVu font and becomes the default serif,
> sans-serif and monospace font on the system, and that's fontconfig's
> responsibility. That causes some issues displaying some characters,
> which are not supported by Bitstream Vera, in addition to being uglier
> than DejaVu.
> 
> Upstream fontconfig fixed that by completely removing Bitstream Vera
> from 60-latin.conf:
> https://gitlab.freedesktop.org/fontconfig/fontconfig/-/merge_requests/99
> 
> But that fix has not reached Debian yet because fontconfig has not seen
> real maintainer-ship for over a year now:
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=961386
> 
> So the alternative solution is, if feasible, to drop the dependency on
> ttf-bitstream-vera. If not feasible, then we'll just have to wait until
> fontconfig is fixed in Debian.

Thanks for the additional info.  The pain will be for users who end up having a
worse experience due to Bitstream Vera being installed.

Since it's just used in EFL examples (and so isn't installed in any search
paths for fonts), I will:
1) drop the dependency on ttf-bitstream-vera
2) go back to distributing upstream's copy for the examples
This ensures that efl-doc's examples are unchanged, and that users aren't
forced to fallback to a worse font option.

Thanks,
Ross

Bug#1004533: bullseye-pu: package golang-github-opencontainers-specs/1.0.2.41.g7413a7f-1

[Reinhard Tartler]

Package: release.debian.org
Severity: normal
Tags: bullseye
User: release.debian@packages.debian.org
Usertags: pu
X-Debbugs-Cc: siret...@tauware.de

[ Reason ]
podman (produced by src:libpod) allows users to run docker-compatible
container images. Because of recent changes in syscall wrappers, the version
of podman in bullseye will not be able to run container images that ship
glibc 2.34, which is currently in experimental and present in recent versions
of ubuntu and fedora.

[ Impact ]
Without these patches, containers will crash at least on arm (cf. #994451) and
amd64 at runtime.

[ Tests ]
The changes have been verified with manual testing.

[ Risks ]
I've attempted to keep the changes as minimal as possible.

[ Checklist ]
  [x] *all* changes are documented in the d/changelog
  [x] I reviewed all changes and I approve them
  [x] attach debdiff against the package in (old)stable
  [x] the issue is verified as fixed in unstable

[ Changes ]

There are three packages that need updating in order:

diff --git a/debian/changelog b/debian/changelog
index f644f7e..d06dbd5 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,10 @@
+golang-github-opencontainers-specs (1.0.2.41.g7413a7f-1+deb11u1) bullseye; 
urgency=medium
+
+  * Backport seccomp patches from upstream to allow execution of newer
+syscalls, Closes: #994451
+
+ -- Reinhard Tartler   Mon, 27 Sep 2021 12:12:47 -0400
+
 golang-github-opencontainers-specs (1.0.2.41.g7413a7f-1) unstable; 
urgency=medium

   * Team upload.
diff --git a/debian/patches/override-default-errno-code.patch 
b/debian/patches/override-default-errno-code.patch
new file mode 100644
index 000..de4f589
--- /dev/null
+++ b/debian/patches/override-default-errno-code.patch
@@ -0,0 +1,66 @@
+From f7ef278d1bbaa6f97b8ef511fad478a31e953290 Mon Sep 17 00:00:00 2001
+From: Giuseppe Scrivano 
+Date: Thu, 21 Jan 2021 13:20:57 +0100
+Subject: [PATCH] seccomp: allow to override default errno return code
+
+the specs already support overriding the errno code for the syscalls
+but the default value is hardcoded to EPERM.
+
+Add a new attribute to override the default value.
+
+Signed-off-by: Giuseppe Scrivano 
+---
+ config-linux.md  | 4 
+ schema/config-linux.json | 3 +++
+ specs-go/config.go   | 9 +
+ 3 files changed, 12 insertions(+), 4 deletions(-)
+
+diff --git a/config-linux.md b/config-linux.md
+index 3c9d77f5..9a515fbf 100644
+--- a/config-linux.md
 b/config-linux.md
+@@ -594,6 +594,10 @@ The actions, architectures, and operators are strings 
that match the definitions
+ The following parameters can be specified to set up seccomp:
+
+ * **`defaultAction`** *(string, REQUIRED)* - the default action for seccomp. 
Allowed values are the same as `syscalls[].action`.
++* **`defaultErrnoRet`** *(uint, OPTIONAL)* - the errno return code to use.
++Some actions like `SCMP_ACT_ERRNO` and `SCMP_ACT_TRACE` allow to specify 
the errno code to return.
++When the action doesn't support an errno, the runtime MUST print and 
error and fail.
++If not specified then its default value is `EPERM`.
+ * **`architectures`** *(array of strings, OPTIONAL)* - the architecture used 
for system calls.
+ A valid list of constants as of libseccomp v2.5.0 is shown below.
+
+diff --git a/schema/config-linux.json b/schema/config-linux.json
+index 83478cc9..61468b9c 100644
+--- a/schema/config-linux.json
 b/schema/config-linux.json
+@@ -203,6 +203,9 @@
+ "defaultAction": {
+ "$ref": "defs-linux.json#/definitions/SeccompAction"
+ },
++"defaultErrnoRet": {
++"$ref": "defs.json#/definitions/uint32"
++},
+ "flags": {
+ "type": "array",
+ "items": {
+diff --git a/specs-go/config.go b/specs-go/config.go
+index 40955144..16eac6dd 100644
+--- a/specs-go/config.go
 b/specs-go/config.go
+@@ -598,10 +598,11 @@ type VMImage struct {
+
+ // LinuxSeccomp represents syscall restrictions
+ type LinuxSeccomp struct {
+-  DefaultAction LinuxSeccompAction `json:"defaultAction"`
+-  Architectures []Arch `json:"architectures,omitempty"`
+-  Flags []LinuxSeccompFlag `json:"flags,omitempty"`
+-  Syscalls  []LinuxSyscall `json:"syscalls,omitempty"`
++  DefaultAction   LinuxSeccompAction `json:"defaultAction"`
++  DefaultErrnoRet *uint  `json:"defaultErrnoRet,omitempty"`
++  Architectures   []Arch `json:"architectures,omitempty"`
++  Flags   []LinuxSeccompFlag `json:"flags,omitempty"`
++  Syscalls[]LinuxSyscall `json:"syscalls,omitempty"`
+ }
+
+ // Arch used for additional architectures
diff --git a/debian/patches/series b/debian/patches/series
new file mode 100644
index 000..cd75fd3
--- /dev/null
+++ b/debian/patches/series
@@ -0,0 +1 @@

Bug#1004355: man-db modifies cache file contents but resets mtime timestamp

[Colin Watson]

Control: tag -1 fixed-upstream

On Tue, Jan 25, 2022 at 05:27:35PM +, Ian Jackson wrote:
> My backup system, like many, relies on file mtimes to know when to
> back files up.  *Un*like most other systems, it does a cross-check: it
> checks that the file *contents* (via checksum) are the same on the
> backed-up host and as is recorded in the backup.
> 
> This seems to me to be a correct and cautious approach.  On at least
> one occasion it has saved me from a serious problem by giving me early
> warning of a storage failure, by flagging up corruption in
> luckily-unimportant files.
> 
> But it means that if a file is modified, but the mtime is reset, the
> backups fail.
> 
> Empirically, this seems to happen with /var/cache/man/*/index.db.
> 
> Please could man-db not do this.  Specifically, if it modifies the
> file, I would like it to either not reset the time timestamp, or at
> least not set the timestamp to the same value it had before.

I've fixed this upstream; the fix will be in man-db 2.10.0, which I
expect to release in a week or so.

For purposes of cherry-picking to stable releases, I'm afraid the
changes involved were quite extensive, since they involved rearranging
all of man-db's database-handling code in order to make it
straightforward for mandb to open each database at most once in any
given run.  It might have been possible to fix the immediate bug with a
smaller patch, but I felt that attempting to do so would make the
relevant logic even more complex and thus more bug-prone, whereas this
approach ultimately leaves the logic simpler.  In particular, there's no
longer any manual adjustment of database mtimes, except when making
temporary copies of databases (roughly equivalent to "cp -a").  I doubt
it will be possible to construct a version of this short enough that it
could realistically be reviewed by the stable release managers, and I'd
much rather let it settle in bookworm anyway.

If need be, I expect that I can help with putting together cherry-picks
for local use.  However, I think I'd recommend simply building a
backport of man-db 2.10.0 instead (and I might consider pushing one to
bullseye-backports and perhaps even buster-backports-sloppy, once this
reaches testing).  There's much less chance of me missing something in
the cherry-picking process that way, and it would mean that you'd get
the significant mandb performance improvements too.

Here's the series I committed to fix this, for the record:

  
https://gitlab.com/cjwatson/man-db/-/commit/53dad5d746a376385ff50e4f2d3a948d1567f8e1
  
https://gitlab.com/cjwatson/man-db/-/commit/b1e9df213e8f1a009e6117673861806b03cec950
  
https://gitlab.com/cjwatson/man-db/-/commit/5cb38c5d360ba2fdbd2178843057c85c4efab576
  
https://gitlab.com/cjwatson/man-db/-/commit/73ab48605e6757240917f77e658f009549ee2f57
  
https://gitlab.com/cjwatson/man-db/-/commit/bf6d84c6d828db3d94d8218b2266b771ab6e5fa3
  
https://gitlab.com/cjwatson/man-db/-/commit/106287fe531ee04ae3f6d0a793084b01659afa16

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

Bug#980759: imageftbbox returns too small bounding box

[Thorsten Glaser]

reassign 980759 libgd3
# version in buster
notfound 980759 2.2.5-5.2
# version in bullseye, bookworm/testing, sid
found 980759 2.3.0-2
tags 980759 + bullseye bookworm sid
forwarded 980759 https://github.com/libgd/libgd/issues/814
affects 980759 php7.4-gd
affects 980759 php8.0-gd
affects 980759 php8.1-gd
thanks

Hi,

upstream had a good idea to try. And indeed:

Installing php7.3-{cli,gd} on bullseye (after removing the Breaks from
php-common the maintainer added just to make it harder to coinstall the
versions) yields the same broken values…

$ php7.3 x.php |fgrep scender
[ascender] => 11
[descender] => 0

… while LD_PRELOADing the exact library from buster
libgd3_2.2.5-5.2_amd64.deb, ceteris paribus, gives the correct values:

$ LD_PRELOAD=$PWD/libgd.so.3.0.5 php7.3 x.php |fgrep scender
[ascender] => 13
[descender] => 1
$ LD_PRELOAD=$PWD/libgd.so.3.0.5 php7.4 x.php |fgrep scender
[ascender] => 13
[descender] => 1

This makes it 100% clear that libgd3 is at fault, neither PHP nor any of
libgd3’s or PHP’s dependencies. Reassigning.

bye,
//mirabilos
-- 
> Hi, does anyone sell openbsd stickers by themselves and not packaged
> with other products?
No, the only way I've seen them sold is for $40 with a free OpenBSD CD.
-- Haroon Khalid and Steve Shockley in gmane.os.openbsd.misc

Bug#998280: Please switch the dependency from ttf-bitstream-vera to fonts-dejavu-core

[Amr Ibrahim]

Hi Ross,

Am Donnerstag, dem 27.01.2022 um 21:05 -0800 schrieb Ross Vandegrift:
> Is ttf-bitstream-vera going away?

No, ttf-bitstream-vera is not going away because there are still many
packages that depend on it.

The real issue of the Bitstream Vera font is that when it's installed,
it takes precedence over the DejaVu font and becomes the default serif,
sans-serif and monospace font on the system, and that's fontconfig's
responsibility. That causes some issues displaying some characters,
which are not supported by Bitstream Vera, in addition to being uglier
than DejaVu.

Upstream fontconfig fixed that by completely removing Bitstream Vera
from 60-latin.conf:
https://gitlab.freedesktop.org/fontconfig/fontconfig/-/merge_requests/99

But that fix has not reached Debian yet because fontconfig has not seen
real maintainer-ship for over a year now:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=961386

So the alternative solution is, if feasible, to drop the dependency on
ttf-bitstream-vera. If not feasible, then we'll just have to wait until
fontconfig is fixed in Debian.

Best,
Amr

Bug#1003017: dulwich: autopkgtest regression: src/debian/tests/testsuite3: 10: -m: not found

[Nilesh Patra]

Hi Jelmer,

On Sun, 2 Jan 2022 21:08:25 +0100 Paul Gevers  wrote:
> With a recent upload of dulwich the autopkgtest of dulwich fails in 
> testing when that autopkgtest is run with the binary packages of dulwich 
> from unstable. It passes when run with only packages from testing. In 
> tabular form:
> 
> passfail
> dulwichfrom testing0.20.26-1
> all others from testingfrom testing

Since this is an RC bug and it was preventing the migration of a chain 
(lintian-brush in particular)
I just NMU'd the fix.
debdiff is attached with this email, please consider applying

Regards,
Nilesh
diff -Nru dulwich-0.20.31/debian/changelog dulwich-0.20.31/debian/changelog
--- dulwich-0.20.31/debian/changelog2022-01-23 18:05:56.0 +
+++ dulwich-0.20.31/debian/changelog2022-01-29 23:36:01.0 +
@@ -1,3 +1,10 @@
+dulwich (0.20.31-1.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix variable name in testsuite (Closes: #1003017)
+
+ -- Nilesh Patra   Sat, 29 Jan 2022 23:36:01 +
+
 dulwich (0.20.31-1) unstable; urgency=low
 
   * New upstream release.
diff -Nru dulwich-0.20.31/debian/tests/testsuite3 
dulwich-0.20.31/debian/tests/testsuite3
--- dulwich-0.20.31/debian/tests/testsuite3 2022-01-23 18:05:56.0 
+
+++ dulwich-0.20.31/debian/tests/testsuite3 2022-01-29 23:36:01.0 
+
@@ -5,8 +5,8 @@
 unset https_proxy
 
 rv=0
-for py in $(py3versions -s); do
-  echo "= Running tests with $py =="
+for py3 in $(py3versions -s); do
+  echo "= Running tests with $py3 =="
   if ! $py3 -m unittest dulwich.tests.test_suite; then
 rv=1
   fi


signature.asc
Description: PGP signature

Bug#1004522: debian-policy: Proposing new virtual package: wayland-session

[Sean Whitton]

Hello,

On Sat 29 Jan 2022 at 08:12PM GMT, Simon McVittie wrote:

> Package: debian-policy
> Version: 4.6.0.1
> Severity: wishlist
> X-Debbugs-Cc: debian-de...@lists.debian.org
>
> GNOME's gdm3 and KDE's sddm both enumerate possible Wayland sessions in
> /usr/{,local/}share/wayland-sessions/*.desktop and make them available
> as desktop sessions that users can choose, in addition to listing the
> X11 sessions that they traditionally did.
>
> At the moment, installing gdm3 pulls in either gnome-session (a minimal
> GNOME desktop), or some sort of X11 thing (usually a session manager,
> but sometimes a window manager or an xterm), but it should ideally
> be possible to install gdm3 as a login prompt from which to launch a
> non-GNOME Wayland session like weston or sway.
>
> I propose this entry for virtual-package-names-list.yaml:
>
> - name: wayland-session
>   description: a Wayland desktop session 
> (/usr/share/wayland-sessions/*.desktop)
>
> According to `apt-file search`, it should initially be provided by these:
>
> gnome-session: /usr/share/wayland-sessions/gnome.desktop
> phosh: /usr/share/wayland-sessions/phosh.desktop
> plasma-workspace-wayland: /usr/share/wayland-sessions/plasmawayland.desktop
> sway: /usr/share/wayland-sessions/sway.desktop
> weston: /usr/share/wayland-sessions/weston.desktop
>
> and perhaps also (I don't know how practical this one is for actual use):
>
> mir-demos: /usr/share/wayland-sessions/mir-shell.desktop

Seems fine.  Just to confirm, the primary use case is so that if a
package providing wayland-session is installed, a display manager like
gdm3 won't try to install GNOME?

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#998063: debian-policy: New virtual package: {default-,}dbus-system-bus

[Sean Whitton]

control: tag -1 + pending

Hello,

On Sat 29 Jan 2022 at 08:24PM GMT, Simon McVittie wrote:

> On Thu, 23 Dec 2021 at 21:26:53 -0700, Sean Whitton wrote:
>> On Fri 29 Oct 2021 at 11:12AM +01, Simon McVittie wrote:
>> > it seems like a good time to introduce {default-,}dbus-system-bus
>> > virtual packages, mirroring {default-,}dbus-session-bus.
>>
>> virtual-package-names-list.yaml says that proposed new virtual package
>> names are meant to be sent to d-devel, not just filed as a bug against
>> debian-policy, so perhaps you could do that and we'll give it a week,
>> then I'll go ahead and add these?
>
> I sent this to -devel in December. There were no objections, and one
> positive reply.

I've committed it to the 'next' branch.

It looks like seconds were counted for recent virtual package additions,
but the documented procedure is lighter weight, so I've just gone ahead
and committed.  It seems appropriate not to require seconding for these.

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#1004529: imagemagick-6.q16: convert foo.png foo.eps security violation leaves empty foo.eps

[Barak A. Pearlmutter]

Package: imagemagick-6.q16
Version: 8:6.9.11.60+dfsg-1.3
Severity: normal

When "convert foo.png foo.eps" gets a security error, it leaves an empty
foo.eps.

/usr/bin/convert should not generate incorrect output files.  If the
output cannot be correctly generated, the output file should be removed.

The current behaviour is a problem when convert is used in a Makefile,
where the first run of "make" generates an error but also an empty
output file, then a second run of "make" treats that empty output file
as correct and continues later stages of the build.

Example:

$ ls -l stroke-signs-1.eps
ls: cannot access 'stroke-signs-1.eps': No such file or directory

$ convert stroke-signs-1.png stroke-signs-1.eps
convert-im6.q16: attempt to perform an operation not allowed by the security 
policy `EPS' @ error/constitute.c/IsCoderAuthorized/421.

$ ls -l stroke-signs-1.eps
-rw-rw-r-- 1 barak barak 0 Jan 14 22:36 stroke-signs-1.eps

Bug#1004528: RFP: dnspeep -- tool to spy on the DNS queries your computer is making

[Francois Marier]

Package: wnpp
Severity: wishlist

* Package name: dnspeep
  Version : 0.1.3
  Upstream Author : Julia Evans 
* URL : https://github.com/jvns/dnspeep/
* License : MIT
  Programming Lang: Rust
  Description : tool to spy on the DNS queries your computer is making

dnspeep lets you spy on the DNS queries your computer is making.
.
It uses libpcap to capture packets on port 53, and then matches up DNS
request and response packets so that it can show the request and response
together on the same line.
.
It also tracks DNS queries which didn't get a response within 1 second and
prints them out with the response .

Bug#1002023: This fixes the bug

[CJP]

Please ignore the patch in my previous mail. I created the new patch
attached here, and it fixes this bug for me.

The patch reverts commit 0cb79db12ac7c48477518dcff269ccc5d6b745e0,
which was reported in the upstream discussion[1] to introduce the bug.
Unfortunately, the reverted commit was intended to fix another bug[2],
so it might be that, by reverting the commit, the other bug[2] may be
re-introduced. Luckily, I am not affected by that other bug, so I am
much better off with this patch.

The other bug was open for more than 10 years, so apparently, it was
never a high priority for the developers. I'd say that the other bug,
which may be re-introduced by this patch, is a pretty minor one.

It may be of interest that the latest version of the Wine source code
(version 7.0+) does not seem to contain code from commit
0cb79db12ac7c48477518dcff269ccc5d6b745e0. 

[1] https://bugs.winehq.org/show_bug.cgi?id=49649
[2] https://bugs.winehq.org/show_bug.cgi?id=15232

From: Corné Plooy 
Subject: Revert commit 0cb79db12ac7c48477518dcff269ccc5d6b745e0

Bug: https://bugs.winehq.org/show_bug.cgi?id=49649
Bug-Debian: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1002023
--- a/dlls/winex11.drv/opengl.c
+++ b/dlls/winex11.drv/opengl.c
@@ -1305,7 +1305,7 @@
 /***
  *  create_gl_drawable
  */
-static struct gl_drawable *create_gl_drawable( HWND hwnd, const struct wgl_pixel_format *format, BOOL known_child )
+static struct gl_drawable *create_gl_drawable( HWND hwnd, const struct wgl_pixel_format *format )
 {
 struct gl_drawable *gl, *prev;
 XVisualInfo *visual = format->visual;
@@ -1326,7 +1326,7 @@
 gl->format = format;
 gl->ref = 1;
 
-if (!known_child && !GetWindow( hwnd, GW_CHILD ) && GetAncestor( hwnd, GA_PARENT ) == GetDesktopWindow())  /* childless top-level window */
+if (GetAncestor( hwnd, GA_PARENT ) == GetDesktopWindow())  /* top-level window */
 {
 gl->type = DC_GL_WINDOW;
 gl->window = create_client_window( hwnd, visual );
@@ -1389,7 +1389,7 @@
 
 if (!format->visual) return FALSE;
 
-if (!(gl = create_gl_drawable( hwnd, format, FALSE ))) return FALSE;
+if (!(gl = create_gl_drawable( hwnd, format ))) return FALSE;
 
 TRACE( "created GL drawable %lx for win %p %s\n",
gl->drawable, hwnd, debugstr_fbconfig( format->fbconfig ));
@@ -1448,7 +1448,7 @@
 /***
  *  sync_gl_drawable
  */
-void sync_gl_drawable( HWND hwnd, BOOL known_child )
+void sync_gl_drawable( HWND hwnd )
 {
 struct gl_drawable *old, *new;
 
@@ -1456,11 +1456,8 @@
 
 switch (old->type)
 {
-case DC_GL_WINDOW:
-if (!known_child) break; /* Still a childless top-level window */
-/* fall through */
 case DC_GL_PIXMAP_WIN:
-if (!(new = create_gl_drawable( hwnd, old->format, known_child ))) break;
+if (!(new = create_gl_drawable( hwnd, old->format ))) break;
 mark_drawable_dirty( old, new );
 XFlush( gdi_display );
 TRACE( "Recreated GL drawable %lx to replace %lx\n", new->drawable, old->drawable );
@@ -1497,7 +1494,7 @@
 return;
 }
 
-if ((new = create_gl_drawable( hwnd, old->format, FALSE )))
+if ((new = create_gl_drawable( hwnd, old->format )))
 {
 mark_drawable_dirty( old, new );
 release_gl_drawable( new );
@@ -3284,10 +3281,9 @@
 }
 pglXSwapBuffers(gdi_display, gl->drawable);
 break;
-case DC_GL_WINDOW:
 case DC_GL_CHILD_WIN:
 if (ctx) sync_context( ctx );
-if (gl->type == DC_GL_CHILD_WIN) escape.gl_drawable = gl->window;
+escape.gl_drawable = gl->window;
 /* fall through */
 default:
 if (escape.gl_drawable && pglXSwapBuffersMscOML)
@@ -3343,7 +3339,7 @@
 return NULL;
 }
 
-void sync_gl_drawable( HWND hwnd, BOOL known_child )
+void sync_gl_drawable( HWND hwnd )
 {
 }
 
--- a/dlls/winex11.drv/window.c
+++ b/dlls/winex11.drv/window.c
@@ -1906,11 +1906,6 @@
 
 if (GetWindowThreadProcessId( hwnd, NULL ) != GetCurrentThreadId()) return NULL;
 
-/* Recreate the parent gl_drawable now that we know there are child windows
- * that will need clipping support.
- */
-sync_gl_drawable( parent, TRUE );
-
 display = thread_init_display();
 init_clip_window();  /* make sure the clip window is initialized in this thread */
 
@@ -2243,12 +2238,6 @@
 done:
 release_win_data( data );
 set_gl_drawable_parent( hwnd, parent );
-
-/* Recreate the parent gl_drawable now that we know there are child windows
- * that will need clipping support.
- */
-sync_gl_drawable( parent, TRUE );
-
 fetch_icon_data( hwnd, 0, 0 );
 }
 
@@ -2412,7 +2401,7 @@
   data->client_rect.bottom - data->client_rect.top !=
   old_client_rect.bottom - 

Bug#1004527: vlc: convert does not honor profile settings for output type

[jrv]

Package: vlc
Version: 3.0.16-1+b6
Severity: normal
X-Debbugs-Cc: f...@bar.com

Dear Maintainer,

There are several issues which may or may not be related. I have included
everything as one because I think they all reflect the same underlying bug or
related ones.

I have been trying to get streaming working from vlc. The problem I was seeing
seemed to come from transcoding, so I tried conversion instead and had similar
problems.

Under Tools, Preferences, All, Stream output, Sout stream, Transcode, I looked
at my configured Audio encoder.  It was set to Theora video encoder. This is an
odd default and I am fairly sure I did not set it so. This may somehow be
related. I set the Audio encoder to "Automatic", save. This step is to make
sure your preferences don't let the process work.

Next I used menu Media, Convert/Save, selected a file (a .flac file, but I also
tried a .wav), click the Convert/Save button, select Profile "audio - Vorbis
(OGG)", pick a Destination file ("foo.ogg"), then click the "Start" button. The
file is created in a second or two but has zero size. The Messages at Debug
level

If I go to Preferences and change the Transcode Audio encoder to match what I
wanted for the output (in this case Vorbis Audio encoder), the conversion
process works as expected.

This was also true with streaming. If the Transcode Audio encoder setting under
preferences does not match what I wanted for output, there is no stream. If I
set the Transcode Audio encoder setting to match what I choose for profile
(e.g. mp3) streaming works.

Odd things happened with some settings. If I set in preferences the Vorbis
Audio encoder then tried to convert a .flac file using the .mp3 profile under
conversion, I got a non-zero-sized file but it would not play.


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

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

Versions of packages vlc depends on:
ii  vlc-bin  3.0.16-1+b6
ii  vlc-plugin-base  3.0.16-1+b6
ii  vlc-plugin-qt3.0.16-1+b6
ii  vlc-plugin-video-output  3.0.16-1+b6

Versions of packages vlc recommends:
ii  vlc-l10n   3.0.16-1
pn  vlc-plugin-access-extra
ii  vlc-plugin-notify  3.0.16-1+b6
ii  vlc-plugin-samba   3.0.16-1+b6
ii  vlc-plugin-skins2  3.0.16-1+b6
ii  vlc-plugin-video-splitter  3.0.16-1+b6
ii  vlc-plugin-visualization   3.0.16-1+b6

Versions of packages vlc suggests:
pn  vlc-plugin-fluidsynth  
pn  vlc-plugin-jack
pn  vlc-plugin-svg 

Versions of packages libvlc-bin depends on:
ii  libc62.33-3
ii  libvlc5  3.0.16-1+b6

Versions of packages libvlc5 depends on:
ii  libc62.33-3
ii  libvlccore9  3.0.16-1+b6

Versions of packages libvlc5 recommends:
ii  libvlc-bin  3.0.16-1+b6

Versions of packages vlc-bin depends on:
ii  libc6   2.33-3
ii  libvlc-bin  3.0.16-1+b6
ii  libvlc5 3.0.16-1+b6

Versions of packages vlc-plugin-base depends on:
ii  liba52-0.7.4 0.7.4-20
ii  libarchive13 3.5.2-1
ii  libaribb24-0 1.0.3-2
ii  libasound2   1.2.6.1-1
ii  libass9  1:0.15.2-1
ii  libavahi-client3 0.8-5
ii  libavahi-common3 0.8-5
ii  libavc1394-0 0.5.4-5
ii  libavcodec58 7:4.4.1-3
ii  libavformat587:4.4.1-3
ii  libavutil56  7:4.4.1-3
ii  libbluray2   1:1.3.0-3
ii  libc62.33-3
ii  libcairo21.16.0-5
ii  libcddb2 1.3.2-7
ii  libchromaprint1  1.5.1-1
ii  libdav1d50.9.2-1+b1
ii  libdbus-1-3  1.12.20-3
ii  libdc1394-25 2.2.6-4
ii  libdca0  0.0.7-2
ii  libdvbpsi10  1.3.3-1
ii  libdvdnav4   6.1.1-1
ii  libdvdread8  6.1.2-1
ii  libebml5 1.4.2-2
ii  libfaad2 2.10.0-2
ii  libflac8 1.3.3-2
ii  libfontconfig1   2.13.1-4.3
ii  libfreetype6 2.11.1+dfsg-1
ii  libfribidi0  1.0.8-2
ii  libgcc-s111.2.0-14
ii  libgcrypt20  1.9.4-5
ii  libglib2.0-0 2.70.3-1
ii  libgnutls30  3.7.2-5
ii  

Bug#1002956: New debdiff

[Thomas Goirand]

On 1/29/22 20:31, Salvatore Bonaccorso wrote:

Control: tags -1 + moreinfo

Hi Thomas,

On Sat, Jan 29, 2022 at 07:55:15PM +0100, Thomas Goirand wrote:

My appologies for opening a new bug. I didn't realize #1002956 was still
pending my input. I merged both bugs.

Please see, attached to this message, the new debdiff, adding the fix for
CVE-2021-22116 as well.


See my comment from
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1002956#10 . Isn't
the the debian/patches/series missing the listing of
CVE-2021-32718_Escape_username_before_displaying_it.patch to actually
apply the patch?

Regards,
Salvatore


Correct, fixed, thanks and sorry for the mistake.

I wont recreate a debdiff, but please believe me, it's fixed in the Git.

Cheers,

Thomas Goirand (zigo)

Bug#1004526: gr-osmosdr: Failure due to removal pf pyqwidget in gnuradio 3.9/3.10

[Dennis Boone]

Package: gr-osmosdr
Version: 0.2.3-5+b1
Severity: normal
X-Debbugs-Cc: d...@msu.edu

Changes to qtgui in gnuradio 3.9/3.10 break at least one of the
osmocom_* tools:

ozymandias 1835 # osmocom_fft -a hackrf -v
gr-osmosdr 0.2.0.0 (0.2.0) gnuradio 3.10.0.0
built-in source types: file fcd rtl rtl_tcp uhd hackrf bladerf rfspace airspy 
airspyhf soapy redpitaya freesrp 
Using HackRF One with firmware 2021.03.1
RF gain range: start 0 stop 14 step 14
IF gain range: start 0 stop 40 step 8
BB gain range: start 0 stop 62 step 2
Supported sample rates 800-2000 step 200.
Supported bandwidth rates 175-2800 step 50.
Supported frequencies 4.0M-7.246G
GAIN(RF): 0
GAIN(IF): 16
GAIN(BB): 20
Traceback (most recent call last):
  File "/usr/bin/osmocom_fft", line 714, in 
main()
  File "/usr/bin/osmocom_fft", line 690, in main
tb = app_top_block(qapp.arguments(), "osmocom Spectrum Browser")
  File "/usr/bin/osmocom_fft", line 297, in __init__
self.scope_win = sip.wrapinstance(self.scope.pyqwidget(), Qt.QWidget)
AttributeError: 'gnuradio.qtgui.qtgui_python.freq_sink_c' object has no 
attribute 'pyqwidget'
Segmentation fault (core dumped)

See a bug report against gnuradio at
https://github.com/gnuradio/gnuradio/issues/5175

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

Kernel: Linux 5.10.0-7-amd64 (SMP w/20 CPU threads)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=es_US.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 gr-osmosdr depends on:
ii  libc6   2.33-5
ii  libgcc-s1   11.2.0-14
ii  libgnuradio-osmosdr0.2.00.2.3-5+b1
ii  libgnuradio-runtime3.10.0   3.10.0.0-4
ii  libstdc++6  11.2.0-14
ii  python3 3.9.8-1
ii  python3-numpy [python3-numpy-abi9]  1:1.21.5-1

Versions of packages gr-osmosdr recommends:
ii  gnuradio3.10.0.0-4
ii  gr-fosphor  3.9~0.974ab2f-1+b2

gr-osmosdr suggests no packages.

-- no debconf information

Bug#1004525: autopkgtest doesn't look up build-needed in all cases

[Paul Gevers]

Package: autopkgtest
Version: 5.19
Severity: normal

Hi,

While working on a fix for bug #1002477, I noticed that the current
implementation and my to-be proposed fix don't look up if build-needed
is in the set of restrictions for the following cases:

* the --override-control option of autopkgtest
* additional restrictions passed to autodep8

As I think my to-be proposed fix is better than the status quo, I
think I'm going to pursue that solution for now, but I wanted to
record this behavior already.

Paul

Bug#1004524: wpasupplicant: After upgrading cannot connect to wifi

[Kamil Jonca]

Package: wpasupplicant
Version: 2:2.10-1
Severity: important
X-Debbugs-Cc: kjo...@poczta.onet.pl

I have upgraded some packages on my laptop with 

24:00.0 Network controller: Broadcom Inc. and subsidiaries BCM43228 
802.11a/b/g/n

controller. After I was not able to up wlan interface and in logs I have 
entries like:

=
2022-01-29T21:54:57.996370+01:00 bambus wpa_supplicant[22258]: wlan0: 
CTRL-EVENT-SCAN-FAILED ret=-22 retry=1
=
When I downgrade to 2:2.9.0-22+b1 (and only this package was downgraded)
everything started to work.


(I make this report on different machine that wpasupplicant is installed)
some info below.

~%uname -a
Linux bambus 5.15.0-3-amd64 #1 SMP Debian 5.15.15-1 (2022-01-18) x86_64 
GNU/Linux

%dpkg -l broadcom-sta-dkms 
Desired=Unknown/Install/Remove/Purge/Hold
| Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend
|/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad)
||/ Name  Version Architecture Description
+++-=-===--
ii  broadcom-sta-dkms 6.30.223.271-17 all  dkms source for the Broadcom 
STA Wireless driver

Bug#1004523: barcode: "SVG" missing from package description

[Jakub Wilk]

Package: barcode
Version: 0.99-4

The package description reads:


Output is generated as either Postscript, Encapsulated Postscript, or PCL.


But barcode supports also the SVG format.
Please add it to the package description.

--
Jakub Wilk

Bug#1004522: debian-policy: Proposing new virtual package: wayland-session

[Russ Allbery]

Simon McVittie  writes:

> GNOME's gdm3 and KDE's sddm both enumerate possible Wayland sessions in
> /usr/{,local/}share/wayland-sessions/*.desktop and make them available
> as desktop sessions that users can choose, in addition to listing the
> X11 sessions that they traditionally did.

> At the moment, installing gdm3 pulls in either gnome-session (a minimal
> GNOME desktop), or some sort of X11 thing (usually a session manager,
> but sometimes a window manager or an xterm), but it should ideally be
> possible to install gdm3 as a login prompt from which to launch a
> non-GNOME Wayland session like weston or sway.

> I propose this entry for virtual-package-names-list.yaml:

> - name: wayland-session
>   description: a Wayland desktop session 
> (/usr/share/wayland-sessions/*.desktop)

I trust Simon to understand the issues here and nothing about this jumps
out as a problem, so seconded.  This seems like an appropriate use of a
virtual package because this is a fairly broad-ranging interface that will
require coordination between separate packaging teams (such as the GNOME
and KDE teams).

-- 
Russ Allbery (r...@debian.org)  

Bug#998063: debian-policy: New virtual package: {default-,}dbus-system-bus

[Simon McVittie]

On Thu, 23 Dec 2021 at 21:26:53 -0700, Sean Whitton wrote:
> On Fri 29 Oct 2021 at 11:12AM +01, Simon McVittie wrote:
> > it seems like a good time to introduce {default-,}dbus-system-bus
> > virtual packages, mirroring {default-,}dbus-session-bus.
> 
> virtual-package-names-list.yaml says that proposed new virtual package
> names are meant to be sent to d-devel, not just filed as a bug against
> debian-policy, so perhaps you could do that and we'll give it a week,
> then I'll go ahead and add these?

I sent this to -devel in December. There were no objections, and one
positive reply.

Thanks,
smcv

Bug#1004521: lsof: New upstream release (4.94.0, 2020 Nov 10)

[Andres Salomon]

On 1/29/22 15:05, Florian Ernst wrote:

Package: lsof
Version: 4.93.2+dfsg-1.1
Severity: wishlist

Dear maintainer,

there is a new upstream release available, cf.
, including
numerous changes / bugfixes.

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



Thanks, I'm aware. I pushed a bunch of patches upstream and was waiting 
for 4.95 to get released, but it's taking longer than expected. :(



https://github.com/lsof-org/lsof/issues/135

Bug#1004522: debian-policy: Proposing new virtual package: wayland-session

[Simon McVittie]

Package: debian-policy
Version: 4.6.0.1
Severity: wishlist
X-Debbugs-Cc: debian-de...@lists.debian.org

GNOME's gdm3 and KDE's sddm both enumerate possible Wayland sessions in
/usr/{,local/}share/wayland-sessions/*.desktop and make them available
as desktop sessions that users can choose, in addition to listing the
X11 sessions that they traditionally did.

At the moment, installing gdm3 pulls in either gnome-session (a minimal
GNOME desktop), or some sort of X11 thing (usually a session manager,
but sometimes a window manager or an xterm), but it should ideally
be possible to install gdm3 as a login prompt from which to launch a
non-GNOME Wayland session like weston or sway.

I propose this entry for virtual-package-names-list.yaml:

- name: wayland-session
  description: a Wayland desktop session (/usr/share/wayland-sessions/*.desktop)

According to `apt-file search`, it should initially be provided by these:

gnome-session: /usr/share/wayland-sessions/gnome.desktop
phosh: /usr/share/wayland-sessions/phosh.desktop
plasma-workspace-wayland: /usr/share/wayland-sessions/plasmawayland.desktop
sway: /usr/share/wayland-sessions/sway.desktop
weston: /usr/share/wayland-sessions/weston.desktop

and perhaps also (I don't know how practical this one is for actual use):

mir-demos: /usr/share/wayland-sessions/mir-shell.desktop

Rationale for not using the names people are probably going to suggest:

- wayland-compositor would be wrong, because it's too low-level. Some
  Wayland compositors are a somewhat complete desktop environment in their
  own right, but for example plasma-workspace-wayland and gnome-session
  are larger components that merely *depend on* a Wayland compositor, plus
  the additional components needed to get a practical desktop environment;
  meanwhile, kwin-wayland and gnome-shell are Wayland compositors, but
  are not desktop environments on their own.

- wayland-session-manager seems like it would be misleading, because an X
  session manager has specific functional expectations (XSMP) separating
  it from an mere x-window-manager, but there's no such thing in Wayland.

smcv

Bug#1004521: lsof: New upstream release (4.94.0, 2020 Nov 10)

[Florian Ernst]

Package: lsof
Version: 4.93.2+dfsg-1.1
Severity: wishlist

Dear maintainer,

there is a new upstream release available, cf.
, including
numerous changes / bugfixes.

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

Cheers,
Flo


signature.asc
Description: PGP signature

Bug#912419: Please package the latest upstream version 0.1.11

[Florian Ernst]

On Wed, Oct 31, 2018 at 11:54:58AM +0100, Michael Biebl wrote:
> the latest upstream version of libestr is 0.1.11 [1]
> 
> While this version is not mandatory for rsyslog, rsyslog upstream
> recommends to use this version [2]
> [...]
> ===
> Hi. A quick addon note to the release:
> 
> The new version 0.1.11 of libestr is not mandatory to run rsyslog 8.39.0,
> but recommended. It contains several bugfixes and AIX support.

The changes are

| Version 0.1.11 2018-10-30
| 
| - portability: remove issues associated with AC_FUNC_MALLOC
|   This configure.ac macro is known to cause issues and not provide real
|   benefit. Thus many projects have removed it, as we have for most of
|   the rsyslog projects. libestr seemed to have overlooked.
|   This came up when troubleshooting issues on IBM AIX.
| - make build on AIX
|   Thanks to github user purnimam1 for the patch
| - bugfix: es_str2num mishandling empty strings
|   If es_str2num() receives an empty string, misadressing happens.
|   Under extreme conditions, this theoretically can lead to a segfault.
|   Thanks to Jan Gerhards for the patch.
|   closes https://github.com/rsyslog/libestr/issues/10
| - CI/Travis: now also test on osX

The bugfix alone seems to make it worthwhile. Pierre, do you maybe need
some support in packaging this?

Cheers,
Flo


signature.asc
Description: PGP signature

Bug#959007: liblognorm: Please provide new upstream release (2.0.6)

[Florian Ernst]

On Mon, Apr 27, 2020 at 09:37:49PM -0400, Boyuan Yang wrote:
> The liglognorm upstream has been providing new upstream release 2.0.6 since
> 2018. Is there any possibility to have this version packaged and provided in
> Debian?

JFTR, the Changelog at
 reads as
follows:

| Version 2.0.6, 2018-11-06
| 
| - implement Checkpoint LEA transfer format
|   … at least if we guess right that this is the format name. This
|   type of format seems to be seen in syslog message. Checkpoint does
|   not provide a spec, so everything is guesswork… 
|   closes https://github.com/rsyslog/liblognorm/issues/309
| - made build on AIX
|   Thanks to Philippe Duveau for the patch.
| - fixes and improvements in bash scripting
|   mostly based on shellcheck recommandations (via CodeFactor.com)
| - string parser: add “lazy” matching mode
|   This introduces paramter “matching.lazy”. See doc for details.
| - bugfix: suppress invalid param error for field name “-”
|   Suppress invalid param error for name for hexnumber, float, number,
|   date-rfc3164 and date-rfc5424. It will just check if name is “-” to
|   make sure that we only suppress the error message in case we do not
|   want to capture something.
|   Thanks to Sol Huebner for the patch.
|   closes https://github.com/rsyslog/liblognorm/issues/270
| - bugfix: cisco-interface-spec did not succeed when at end of line
|   Thanks to Sol Huebner for the patch.
|   closes https://github.com/rsyslog/liblognorm/issues/229

The bugfixes and the Checkpoint LEA transfer format seems to make this
worthwhile. Pierre, do you maybe need some support in packaging this?

Cheers,
Flo


signature.asc
Description: PGP signature

Bug#1004262: [debian-mysql] Bug#1004262: Acknowledgement (mariadb-server: Instead of being upgraded, mariadb-server gets removed after apt update)

[Paul Gevers]

Hi Otto,

On Thu, 27 Jan 2022 10:05:55 -0800 =?UTF-8?B?T3R0byBLZWvDpGzDpGluZW4=?= 
 wrote:

Note that apt-get and apt use different resolvers.


To be pedantic, I don't think this is correct. Yes, apt and apt-get 
behave slightly different, but the resolver they use by default is the same.


Paul


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1004520: diffutils: New upstream release (3.8, 2021 Aug 01)

[Florian Ernst]

Source: diffutils
Version: 1:3.7-5
Severity: wishlist

Dear maintainer,

there is a new upstream release available, cf.
.

The NEWS read as follows:

| * Noteworthy changes in release 3.8 (2021-08-01) [stable]
| 
| ** Incompatible changes
| 
|   diff no longer treats a closed stdin as representing an absent file
|   in usage like 'diff --new-file - foo <&-'.  This feature was rarely
|   if ever used and was not portable to POSIX platforms that reopen
|   stdin on exec, such as SELinux if the process underwent an AT_SECURE
|   transition, or HP-UX even if not setuid.
|   [bug#33965 introduced in 2.8]
| 
| ** Bug fixes
| 
|   diff and related programs no longer get confused if stdin, stdout,
|   or stderr are closed.  Previously, they sometimes opened files into
|   file descriptors 0, 1, or 2 and then mistakenly did I/O with them
|   that was intended for stdin, stdout, or stderr.
|   [bug#33965 present since "the beginning"]
| 
|   cmp, diff and sdiff no longer treat negative command-line
|   option-arguments as if they were large positive numbers.
|   [bug#35256 introduced in 2.8]

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

Cheers,
Flo


signature.asc
Description: PGP signature

Bug#1002956: New debdiff

[Salvatore Bonaccorso]

Control: tags -1 + moreinfo

Hi Thomas,

On Sat, Jan 29, 2022 at 07:55:15PM +0100, Thomas Goirand wrote:
> My appologies for opening a new bug. I didn't realize #1002956 was still
> pending my input. I merged both bugs.
> 
> Please see, attached to this message, the new debdiff, adding the fix for
> CVE-2021-22116 as well.

See my comment from
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1002956#10 . Isn't
the the debian/patches/series missing the listing of
CVE-2021-32718_Escape_username_before_displaying_it.patch to actually
apply the patch?

Regards,
Salvatore

Bug#1004519: libcap-ng: New upstream release (0.8.2, 2020 Dec 09)

[Florian Ernst]

Source: libcap-ng
Version: 0.7.9-2.2
Severity: wishlist

Dear maintainer,

there are some new upstream releases available at
, the ChangeLog reads as
follows:

| 0.8.2
| - In capng_apply, if we blew up in bounding set, allow setting capabilities
| - If PR_CAP_AMBIENT is not available, do not build libdrop_ambient
| - Improve last_cap check
| 
| 0.8.1
| - If procfs is not available, leave last_cap as CAP_LAST_CAP
| - If bounding and ambient not found in status, try prctl method
| - In capng_apply, move ambient caps to the end of the transaction
| - In capng_apply, return errors more aggressively.
| - In capng_apply, if the action includes the bounding set,resync with the 
kernel
| - Fix signed/unsigned warning in cap-ng.c
| - In capng_apply, return a unique error code to diagnose any failure
| - In capng_have_capability, return 0 for failure
| - Add the libdrop_ambient admin tool
| 
| 0.8
| - Add vararg support to python bindings for capng_updatev
| - Add support for ambient capabilities
| - Add support for V3 filesystem capabilities
| 
| 0.7.11
| - Really clear bounding set if asked in capng_change_id
| - Add CAP_PERFMON, CAP_BPF, & CAP_CHECKPOINT_RESTORE
| - Avoid malloc/free in capng_apply (Natanael Copa)
| - If procfs is not available, get bounding set via prctl
| - Cleanup some compiler warnings
| 
| 0.7.10
| - Update capng_change_id man page
| - Add capng_have_permitted_capabilities function
| - Update filecap to output which set the capabilities are in
| - Fix filecap to not output an error when a file has no capabilities
| - Add udplite support to netcap
| - Fix usage of pthread_atfork (Joe Orton)
| - Mark processes in child user namespaces with * (Danila Kiver)

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

Cheers,
Flo


signature.asc
Description: PGP signature

Bug#1004518: librecad: CVE-2021-45341 CVE-2021-45342 CVE-2021-45343

[Salvatore Bonaccorso]

Source: librecad
Version: 2.1.3-2
Severity: important
Tags: security upstream
X-Debbugs-Cc: car...@debian.org, Debian Security Team 
Control: found -1 2.1.3-1.3
Control: found -1 2.1.3-1.2

Hi,

The following vulnerabilities were published for librecad.

CVE-2021-45341[0]:
| A buffer overflow vulnerability in CDataMoji of the jwwlib component
| of LibreCAD 2.2.0-rc3 and older allows an attacker to achieve Remote
| Code Execution using a crafted JWW document.


CVE-2021-45342[1]:
| A buffer overflow vulnerability in CDataList of the jwwlib component
| of LibreCAD 2.2.0-rc3 and older allows an attacker to achieve Remote
| Code Execution using a crafted JWW document.


CVE-2021-45343[2]:
| In LibreCAD 2.2.0, a NULL pointer dereference in the HATCH handling of
| libdxfrw allows an attacker to crash the application using a crafted
| DXF document.


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

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2021-45341
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-45341
[1] https://security-tracker.debian.org/tracker/CVE-2021-45342
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-45342
[2] https://security-tracker.debian.org/tracker/CVE-2021-45343
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-45343

Regards,
Salvatore

Bug#1004517: [pyvo] CI failure with astropy 5.0.1; please update to version 1.2.1

[Ole Streicher]

Source: pyvo
Version: 1.1-1
Severity: serious
Control: affects -1 astropy

Dear maintainer,

I just uploaded astropy-5.0.1 to unstable. It appears that pyvo 1.1 is 
no longer compatible and now leads to a CI test error:


https://ci.debian.net/data/autopkgtest/testing/amd64/p/pyvo/18800419/log.gz

Relevant lines:

  File "/usr/lib/python3/dist-packages/pyvo/utils/decorators.py", line 
4, in 

from astropy.utils.decorators import wraps
ImportError: cannot import name 'wraps' from 'astropy.utils.decorators' 
(/usr/lib/python3/dist-packages/astropy/utils/decorators.py)

autopkgtest [15:19:32]:  summary
python3-pyvo FAIL non-zero exit status 1


This is fixed upstream in pyvo 1.2.1:

https://github.com/astropy/pyvo/pull/283

so the easiest would be to upload the new version.

Best regards

Ole

Bug#1002956: New debdiff

[Thomas Goirand]

My appologies for opening a new bug. I didn't realize #1002956 was still 
pending my input. I merged both bugs.


Please see, attached to this message, the new debdiff, adding the fix 
for CVE-2021-22116 as well.


Cheers,

Thomas Goirand (zigo)diff -Nru rabbitmq-server-3.8.9/debian/changelog 
rabbitmq-server-3.8.9/debian/changelog
--- rabbitmq-server-3.8.9/debian/changelog  2021-04-10 22:59:57.0 
+0200
+++ rabbitmq-server-3.8.9/debian/changelog  2022-01-01 18:46:04.0 
+0100
@@ -1,3 +1,39 @@
+rabbitmq-server (3.8.9-3+deb11u1) bullseye; urgency=medium
+
+  * CVE-2021-32719: In rabbitmq-server prior to version 3.8.18, when a
+federation link was displayed in the RabbitMQ management UI via the
+`rabbitmq_federation_management` plugin, its consumer tag was rendered
+without proper script tag sanitization. This potentially allows
+for JavaScript code execution in the context of the page. The user must
+be signed in and have elevated permissions (manage federation upstreams
+and policies) for this to occur. Applied upstream patch: Escape the
+consumer-tag value in federation mgmt.
+  * CVE-2021-32718: In rabbitmq-server prior to version 3.8.17, a new user
+being added via management UI could lead to the user's bane being
+rendered in a confirmation message without proper `script` tag
+sanitization, potentially allowing for JavaScript code execution in the
+context of the page. In order for this to occur, the user must be signed
+in and have elevated permissions (other user management).
+  * Closes: #990524
+  * Add a new README.Debian explaining how to secure RabbitMQ.
+  * Stop moving mv /etc/rabbitmq/rabbitmq.conf /etc/rabbitmq/rabbitmq-env.conf.
+  * Generate the Erlang cookie in /var/lib/rabbitmq/.erlang.cookie using
+OpenSSL, rather than letting RabbitMQ use Erlang to generate a poor entropy
+Erlang cookie, which was easily brute-forceable in 10 minutes. The OpenSSL
+generated version has order of magnitudes more possible values, which makes
+it a way harder to bruteforce. If an old Erlang cookie is detected, a new
+one is generated, and rabbitmq-server restarted if it was running.
+  * rabbitmq-server.service now correctly depends on epmd.socket and not the
+epmd@.socket, so it can correctly start after a reboot.
+  * CVE-2021-22116: RabbitMQ all versions prior to 3.8.16 are prone to a denial
+of service vulnerability due to improper input validation in AMQP 1.0
+client connection endpoint. A malicious user can exploit the vulnerability
+by sending malicious AMQP messages to the target RabbitMQ instance having
+the AMQP 1.0 plugin enabled. Added upstream patch: AMQP 1.0 binary parser:
+treat arrays with extra or missing input as fatal errors.
+
+ -- Thomas Goirand   Sat, 01 Jan 2022 18:46:04 +0100
+
 rabbitmq-server (3.8.9-3) unstable; urgency=medium
 
   [ Adam Cecile ]
diff -Nru rabbitmq-server-3.8.9/debian/control 
rabbitmq-server-3.8.9/debian/control
--- rabbitmq-server-3.8.9/debian/control2021-04-10 22:59:57.0 
+0200
+++ rabbitmq-server-3.8.9/debian/control2022-01-01 18:46:04.0 
+0100
@@ -61,6 +61,7 @@
  locales-all,
  logrotate,
  lsb-base,
+ openssl,
  socat,
  ${misc:Depends},
  ${python3:Depends},
diff -Nru 
rabbitmq-server-3.8.9/debian/patches/CVE-2021-22116_AMQP_1.0_parser_treat_arrays_with_extra_or_missing_input_as_fatal_errors.patch
 
rabbitmq-server-3.8.9/debian/patches/CVE-2021-22116_AMQP_1.0_parser_treat_arrays_with_extra_or_missing_input_as_fatal_errors.patch
--- 
rabbitmq-server-3.8.9/debian/patches/CVE-2021-22116_AMQP_1.0_parser_treat_arrays_with_extra_or_missing_input_as_fatal_errors.patch
  1970-01-01 01:00:00.0 +0100
+++ 
rabbitmq-server-3.8.9/debian/patches/CVE-2021-22116_AMQP_1.0_parser_treat_arrays_with_extra_or_missing_input_as_fatal_errors.patch
  2022-01-01 18:46:04.0 +0100
@@ -0,0 +1,135 @@
+From 626d5219115d087a2695c0eb243c7ddb7e154563 Mon Sep 17 00:00:00 2001
+From: Michael Klishin 
+Date: Wed, 7 Apr 2021 13:42:20 +0300
+Subject: [PATCH] Merge pull request #2953 from
+ rabbitmq/mk-amqp10-parser-infinite-loop
+
+AMQP 1.0 binary parser: treat arrays with extra or missing input as fatal 
errors
+
+(cherry picked from commit f37a31de55229e6c763215500e376fa16803390b)
+---
+ .../src/amqp10_binary_parser.erl  | 26 +---
+ .../test/binary_parser_SUITE.erl  | 59 +++
+ 2 files changed, 78 insertions(+), 7 deletions(-)
+ create mode 100644 deps/amqp10_common/test/binary_parser_SUITE.erl
+
+diff --git a/deps/amqp10_common/src/amqp10_binary_parser.erl 
b/deps/amqp10_common/src/amqp10_binary_parser.erl
+index b936f9f4ca8..376ac47aed5 100644
+--- a/deps/amqp10_common/src/amqp10_binary_parser.erl
 b/deps/amqp10_common/src/amqp10_binary_parser.erl
+@@ -31,15 +31,15 @@ parse_described(Bin) ->
+ {Value, Rest2} = parse(Rest1),
+ {{described, Descriptor, Value}, Rest2}.
+ 

Bug#1004203: closed by Scott Kitterman (Re: RM: src:php-bacon-bacon-qr-code -- ROM; duplicate (already in Debian))

[Guilhem Moulin]

Control: retitle -1 src:php-bacon-bacon-qr-code -- ROM; duplicate (already in 
Debian)

On Sat, 29 Jan 2022 at 18:25:42 +, Adam D. Barratt wrote:
> On Sat, 2022-01-29 at 18:41 +0100, Guilhem Moulin wrote:
>>> Appears it was already removed.
>> 
>> Was it?  5 days later it's still listed at 
>> https://tracker.debian.org/pkg/php-bacon-qr-code
>> and in the output of `apt showsrc php-bacon-qr-code`.
> 
> That's php-bacon-qr-code, whereas you asked for the removal of php-
> bacon-bacon-qr-code (with two "bacon"s). The latter is *not* listed on
> the page you mentioned, nor is it in the archive:
> 
> adsb@coccia:~$ dak ls php-bacon-bacon-qr-code
> adsb@coccia:~$ 
> 
> Did you mean to request the removal of php-bacon-qr-code instead?

Ah!  So I managed to typo the ITP *and* the RM :-(.  Yes, the source
package I incorrectly uploaded, and would like to request removal for,
is 'php-bacon-qr-code'
https://tracker.debian.org/news/1297071/accepted-php-bacon-qr-code-204-1-source-all-into-unstable-unstable/

Thanks for for the correction!
-- 
Guilhem.


signature.asc
Description: PGP signature

Bug#1004516: cwltool breaks toil autopkgtest: No such file or directory: '/home/debci/tmp/tmpgxz5j85g'

[Paul Gevers]

Source: cwltool, toil
Control: found -1 cwltool/3.1.20220119140128-2
Control: found -1 toil/5.6.0-2
Severity: serious
Tags: sid bookworm
X-Debbugs-CC: debian...@lists.debian.org
User: debian...@lists.debian.org
Usertags: breaks needs-update

Dear maintainer(s),

With a recent upload of cwltool the autopkgtest of toil fails in testing 
when that autopkgtest is run with the binary packages of cwltool from 
unstable. It passes when run with only packages from testing. In tabular 
form:


   passfail
cwltoolfrom testing3.1.20220119140128-2
toil   from testing5.6.0-2
versioned deps [0] from testingfrom unstable
all others from testingfrom testing

I copied some of the output at the bottom of this report.

Currently this regression is blocking the migration of cwltool to 
testing [1]. Due to the nature of this issue, I filed this bug report 
against both packages. Can you please investigate the situation and 
reassign the bug to the right package?


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

Paul

[0] You can see what packages were added from the second line of the log 
file quoted below. The migration software adds source package from 
unstable to the list if they are needed to install packages from 
cwltool/3.1.20220119140128-2. I.e. due to versioned dependencies or 
breaks/conflicts.

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

https://ci.debian.net/data/autopkgtest/testing/amd64/t/toil/18793124/log.gz

=== FAILURES 
===
___ FileJobStoreTest.testEmptyFileStoreIDIsReadable 


Traceback (most recent call last):
  File "/usr/lib/python3/dist-packages/toil/jobStores/fileJobStore.py", 
line 489, in read_file

os.link(jobStoreFilePath, local_path)
FileExistsError: [Errno 17] File exists: 
'/tmp/autopkgtest-lxc.85mlkjg3/downtmp/build.vip/src/jobstore-test-07ead108-dcba-43a6-9148-1858e1cd24c6/files/no-job/file-db26c7b57ee84f5597ddbf2a60af46e7/stream' 
-> '/home/debci/tmp/tmpgxz5j85g'


During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File 
"/usr/lib/python3/dist-packages/toil/test/jobStores/jobStoreTest.py", 
line 1039, in testEmptyFileStoreIDIsReadable

self.jobstore_initialized.read_file(id, path)
  File "/usr/lib/python3/dist-packages/toil/jobStores/fileJobStore.py", 
line 498, in read_file

os.link(jobStoreFilePath, local_path)
OSError: [Errno 18] Invalid cross-device link: 
'/tmp/autopkgtest-lxc.85mlkjg3/downtmp/build.vip/src/jobstore-test-07ead108-dcba-43a6-9148-1858e1cd24c6/files/no-job/file-db26c7b57ee84f5597ddbf2a60af46e7/stream' 
-> '/home/debci/tmp/tmpgxz5j85g'


During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File 
"/usr/lib/python3/dist-packages/toil/test/jobStores/jobStoreTest.py", 
line 1042, in testEmptyFileStoreIDIsReadable

os.unlink(path)
FileNotFoundError: [Errno 2] No such file or directory: 
'/home/debci/tmp/tmpgxz5j85g'
 Captured stdout setup 
-



[TEST] 
toil.test.jobStores.jobStoreTest.FileJobStoreTest:testEmptyFileStoreIDIsReadable 
(Jan 29 2022 03:14:35:362865 PST)



-- Captured log call 
---
INFO toil.test:__init__.py:109 Setting up 
toil.test.jobStores.jobStoreTest.FileJobStoreTest.testEmptyFileStoreIDIsReadable 
...
DEBUGtoil.jobStores.fileJobStore:fileJobStore.py:74 Path to job 
store directory is 
'/tmp/autopkgtest-lxc.85mlkjg3/downtmp/build.vip/src/jobstore-test-07ead108-dcba-43a6-9148-1858e1cd24c6'.
DEBUGtoil.jobStores.abstractJobStore:abstractJobStore.py:183 The 
workflow ID is: '38228cb7-9d17-4058-b812-cd5f00e89fc6'
DEBUGtoil.jobStores.fileJobStore:fileJobStore.py:74 Path to job 
store directory is 
'/tmp/autopkgtest-lxc.85mlkjg3/downtmp/build.vip/src/jobstore-test-07ead108-dcba-43a6-9148-1858e1cd24c6'.
INFO toil.test:__init__.py:114 Tore down 
toil.test.jobStores.jobStoreTest.FileJobStoreTest.testEmptyFileStoreIDIsReadable
- generated xml file: 
/tmp/autopkgtest-lxc.85mlkjg3/downtmp/run-unit-tests-artifacts/toil-tests-junit.xml 
-
=== short test summary info 

SKIPPED [6] 
../../../../../usr/lib/python3/dist-packages/_pytest/unittest.py:153: 
Install Toil with the 'kubernetes' extra to include this test.
SKIPPED [6] 
../../../../../usr/lib/python3/dist-packages/_pytest/unittest.py:153: 
Install py-tes to include this test
SKIPPED [122] 
../../../../../usr/lib/python3/dist-packages/_pytest/unittest.py:153: 
Skipped because TOIL_TEST_QUICK is "True"
SKIPPED [1] 
../../../../../usr/lib/python3/dist-packages/toil/test/batchSystems/batchSystemTest.py:998: 
Skipped because 

Bug#1004515: RFP: openwebstart -- Run JNLP files with the latest Java version

[Attila Csipak]

Package: wnpp
Severity: wishlist

* Package name: openwebstart
  Version : 1.5.1
  Upstream Author : Karakun 
* URL : https://openwebstart.com/
* License : GPL with Classpath Exception
  Programming Lang: Java
  Description : Run JNLP files with the latest Java version

OpenWebStart is an open source reimplementation of the Java Web Start
technology. It provides the most commonly used features of Java Web
Start and the JNLP standard, so that your customers can continue using
applications based on Java Web Start and JNLP without any change.
OpenWebStart is based on Iced-Tea-Web and the JNLP-specification
defined in JSR-56. OpenWebStart is released under the GPL with
Classpath Exception. For more information, read the full license here.

The main focus of OpenWebStart is the execution of JNLP-based
applications. Additionally, the tool contains four modules that
simplify your Web Start workflows and let you configure OpenWebStart
to suit your needs:
 - App Manager: manages the versions of any JNLP-based application
that is executed by OpenWebStart.
 - JVM Manager: manages Java versions and Java updates on the client.
 - Control Panel: provides a graphical user interface to configure OpenWebStart.
 - Updater: downloads and installs new versions of OpenWebStart.

The OpenWebStart website already provides deb package downloads.

The JavaPackaging team will probably be interested in this.

Bug#1004514: grub-common: background images don't work with luks encrypted lvm root partition

[khimaros]

Package: grub-common
Version: 2.04-20
Severity: important
Tags: upstream

the core issue is that grub-probe is not reporting cryptodisk abstraction when 
the block device below the lvm is luks encrypted.

/usr/share/grub/grub-mkconfig_lib relies on this output to decide whether to 
create the background cache on the /boot partition. because cryptodisk is not 
returned as an abstraction, the cache is never created and cannot be displayed 
at boot time.

this is the output of grub-probe:

# grub-probe -t abstraction /usr/share/images/desktop-base/desktop-grub.png
lvm

however, the file is definitely on an encrypted lvm volume:

# stat --printf="%m\n" /usr/share/images/desktop-base/desktop-grub.png
/

# lsblk
NAME MAJ:MIN RM   SIZE RO TYPE  MOUNTPOINTS
nvme0n1  259:00 476.9G  0 disk 
...
└─nvme0n1p3  259:30 476.7G  0 part  
  └─nvme0n1p3_crypt  253:00 476.7G  0 crypt 
└─fnord--vg-root 253:10 476.7G  0 lvm   /

# mount -vf /
mount: /dev/mapper/fnord--vg-root mounted on /.

# pvdisplay
PV Name /dev/mapper/nvme0n1p3_crypt
VG Name fnord-vg
...

# cryptsetup status nvme0n1p3_crypt
/dev/mapper/nvme0n1p3_crypt is active and in use.
  type: LUKS2
  device:   /dev/nvme0n1p3
...

Bug#1004513: bullseye-pu: package rabbitmq-server/3.8.9-3

[Thomas Goirand]

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

Hi,

I have prepared an update for rabbitmq-server/3.8.9-3
targetting Bullseye. This contains numerous adjustments. The
most important of them being the generation of the file
/var/lib/rabbitmq/.erlang.cookie which didn't have enough
entropy as per what RabbitMQ generates using Erlang. The
direct consequence, is a possible remote execution vulnerability
where the attacker simply bruteforce the value of the Erlang
cookie. As per what the default was, there's only 200 000 000
possible values (20 upper case chars, so 26 to the power of 20),
so it is estimated that in 10 minutes, someone can brutefoce
the cookie value. Using "openssl rand -base64 42", we get at
lease 2.6353924e+76 possible value which is considerably harder
to bruteforce.

Besides this, the systemd service dependency is corrected to
depend on epmd.socket instead of epmd@.socket, and there's also
an upstream patch for the rabbitmq monitoring interface (which
is less grave, IMO).

On top of this, I added a README.Debian to explain how to
correctly secure a rabbitmq-server installation. Hopefully,
this will help our users.

One thing to note: if someone was copying the older erlang
cookie to other servers part of the cluster, it *will* break
the cluster, as erlang cookies wont match. However, this is
IMO better than leaving an open RCE. Though I don't think this
will be the majority case. I expect our users running with the
wrong Erlang cookie to be running in a single node setup, and
not even knowing about the cookie entropy issue. For this case,
the upgrade will fix everything correctly and automatically.

[ Reason ]
Fixing RCE.
Fixing JS bug.
Adding doc how to secure rabbitmq.

[ Tests ]
I manually tested the new setup. The .erlang.cookie is
correctly generated, and older installation gets correctly
fixed.

[ Risks ]
Appart from the monitoring web interface of RabbitMQ, which
anyways isn't mandatory for running rabbitmq-server, all
changes are easy to audit.

[ Checklist ]
  [x] *all* changes are documented in the d/changelog
  [x] I reviewed all changes and I approve them
  [x] attach debdiff against the package in (old)stable
  [x] the issue is verified as fixed in unstable

Pleasee allow me to upload rabbitmq-server/3.8.9-3+deb11u1
for the next point release.

Cheers,

Thomas Goirand (zigo)
diff --git a/debian/README.Debian b/debian/README.Debian
new file mode 100644
index 000..9d564c4
--- /dev/null
+++ b/debian/README.Debian
@@ -0,0 +1,134 @@
+*** WARNING ***
+
+0/ Intro
+
+RabbitMQ, in its default configuration, is insecure.  A number of
+security measures are necessary to prevent remote execution of code
+from malicious actors.
+
+
+1/ Firewalling
+
+A default RabbitMQ installation opens the following ports, with the
+following authentication schemes:
+ - 4369: EPMD daemon, for port lookups; IP-based auth limited to
+   localhost
+ - 5672: AMQP protcol; username/password auth
+ - 25672: RabbitMQ "distribution" port for inter-node communication; a
+   "magic cookie" shared secret for auth
+
+Unauthorized access to all of these ports is a security risk; you
+should configure your firewall to disallow outside access to them.
+Speifically, unrestricted access to the port 25672, with the default
+weak secret before 3.9.8-3 (see below), EXPOSES YOUR SERVER TO A
+REMOTE CODE EXECUTION VULNERABILITY.  Unrestricted access to port 4369
+serves to advertise that vulnerability.
+
+Though not open by default, RabbitMQ may also be configured to open
+the following ports, which are also strongly advised to be firewalled:
+ - 5671: AMQP with SSL
+ - 15671: Management port with SSL
+ - 15672: Management port without SSL
+
+
+2/ Erlang cookie
+
+Prior to Debian version 3.9.8-3, rabbitmq-server generated an Erlang
+"magic cookie" shared secret if one did not exist.  This secret is
+stored in /var/lib/rabbitmq/.erlang.cookie
+
+However, due to predictable seeds and a non-cryptographic randomizer,
+the automatically-generated secret written by Erlang only supplies 20
+to 40 bits of entropy.  This allows a remote attacker with access to
+port 25672 to brute-force the "magic cookie," potentially within
+minutes, authenticate as a remote node, and EXECUTE ARBITRARY CODE.
+
+Since 3.9.8-3, the rabbitmq-server node will use openssl to generate a
+cryptographically-secure cookie during first installation, mitigating
+this vulnerability.
+
+Servers which installed a prior version, and are upgrading to 3.9.8-3
+or higher, ARE STILL VULNERABLE, as the package will not regenerate
+the secret if it exists already.  This is because the secret is
+designed to be shared between nodes in a cluster, and thus
+regenerating it would break existing clusters.
+
+Operators upgrading from earlier versions of rabbitmq-server are
+strongly encouraged to generate a new secret.  This can be done via:
+
+openssl rand -base64 42 

Bug#1004512: autodock-vina: autopkgtest regression on armhf: warning on stderr

[Paul Gevers]

Source: autodock-vina
Version: 1.2.3-1
X-Debbugs-CC: debian...@lists.debian.org
Severity: serious
User: debian...@lists.debian.org
Usertags: regression

Dear maintainer(s),

With a recent upload of autodock-vina the autopkgtest of autodock-vina 
fails in testing when that autopkgtest is run with the binary packages 
of autodock-vina from unstable. It passes when run with only packages 
from testing. In tabular form:


   passfail
autodock-vina  from testing1.2.3-1
all others from testingfrom testing

I copied some of the output at the bottom of this report. The host that 
run our armhf tests has a huge amount of resources. Maybe you want to 
suppress the warning or add a allow-stderr restriction to the test.


Currently this regression is blocking the migration to testing [1]. Can 
you please investigate the situation and fix it?


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=autodock-vina

https://ci.debian.net/data/autopkgtest/testing/armhf/a/autodock-vina/18799239/log.gz

WARNING: At low exhaustiveness, it may be impossible to utilize all CPUs.


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1004511: luajit breaks knot-resolver autopkgtest on ppc64el: Segmentation fault

[Paul Gevers]

Source: luajit, knot-resolver
Control: found -1 luajit/2.1.0~beta3+git20210112+dfsg-2
Control: found -1 knot-resolver/5.4.4-1
Severity: serious
Tags: sid bookworm
X-Debbugs-CC: debian...@lists.debian.org
User: debian...@lists.debian.org
Usertags: breaks needs-update

Dear maintainer(s),

With a recent upload of luajit the autopkgtest of knot-resolver fails in 
testing when that autopkgtest is run with the binary packages of luajit 
from unstable. It passes when run with only packages from testing. In 
tabular form:


   passfail
luajit from testing2.1.0~beta3+git20210112+dfsg-2
knot-resolver  from testing5.4.4-1
all others from testingfrom testing

I copied some of the output at the bottom of this report.

Currently this regression is blocking the migration of luajit to testing 
[1]. Due to the nature of this issue, I filed this bug report against 
both packages. Can you please investigate the situation and reassign the 
bug to the right package?


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=luajit

https://ci.debian.net/data/autopkgtest/testing/ppc64el/k/knot-resolver/18781119/log.gz

/usr/sbin/kresd + /usr/bin/kdig roundtrip tests

workdir: /tmp/autopkgtest-lxc.7e24ymsu/downtmp/roundtrip-artifacts
IP addr: 127.148.62.213
 kresd args: --addr=127.148.62.213@8053 --tls=127.148.62.213@8853 
--noninteractive 
--config=/tmp/autopkgtest-lxc.7e24ymsu/downtmp/roundtrip-artifacts/kresd.conf 
--verbose --verbose --verbose


make Certificate Authority key and certificate
--
Generating a 3072 bit RSA private key...
Generating a self signed certificate...
X.509 Certificate Information:
Version: 3
Serial Number (hex): 2b34f0d7e93fd713653dda432ddeffed7f9f834b
Validity:
Not Before: Fri Jan 28 19:35:43 UTC 2022
Not After: Wed Feb 09 19:35:43 UTC 2022
Subject: CN=testing certificate authority (NOT FOR PRODUCTION)
Subject Public Key Algorithm: RSA
Algorithm Security Level: High (3072 bits)
Modulus (bits 3072):
00:98:66:36:e9:ce:d2:58:89:bc:a9:ec:ac:21:5e:4b
d2:f3:70:af:5c:41:11:d2:0f:fa:e2:f1:54:65:bc:86
06:4c:55:9f:0e:c3:72:8a:81:75:c3:be:2a:37:20:6a
ce:45:4d:22:00:92:d8:f3:ff:0c:d1:c3:9e:1b:0e:f9
c4:48:38:22:84:f7:a0:6a:bd:e9:34:9d:91:35:00:7b
97:28:c7:6b:49:14:ed:50:81:07:7e:cc:cb:3c:79:cb
fb:52:3d:3c:e0:c5:d9:1d:b5:1f:49:f4:55:74:db:a9
e7:58:fd:83:b6:56:ef:82:07:8f:6f:af:ec:26:b5:40
b4:23:1f:5c:b5:13:47:28:13:8a:58:58:19:f4:8f:3d
7e:12:c2:75:0c:7e:bd:f3:7d:89:f6:b6:3f:8f:63:99
1b:9d:e6:0c:63:fa:a5:5c:5e:08:27:d7:fd:af:3f:7c
54:74:4d:44:3b:ed:66:1a:05:ca:60:94:87:6d:47:c2
5e:8c:3f:1b:d9:60:21:4f:a4:30:1c:0a:21:da:34:0d
a5:cc:df:70:f4:82:71:d4:05:eb:31:0a:2f:59:db:dd
5a:38:15:2a:39:c0:1c:14:2c:cc:3e:b1:dc:97:3d:d7
ff:95:3c:b7:9a:c9:e4:e4:d1:ee:8e:5f:f0:41:d1:f8
2d:4b:6a:36:8d:e8:33:ad:92:b1:7d:65:07:29:56:36
4a:ee:62:75:58:70:f0:99:31:b5:d9:08:8c:68:13:a2
f6:93:38:a9:d7:f9:84:a2:06:29:6f:c8:4c:53:ec:de
37:4b:0a:3c:a9:69:df:57:fd:f0:94:da:d1:a8:5a:8d
40:80:e4:80:5d:85:4c:4a:2f:94:81:9f:e5:a6:a2:49
10:bf:ff:10:11:9f:c6:9d:4d:04:d4:46:f3:25:7c:62
93:7a:43:c9:2d:6a:d5:5a:f2:4a:b7:35:5e:a1:08:f4
a7:30:7a:50:a2:67:c1:f7:2b:17:43:29:0e:3b:34:48
c5
Exponent (bits 24):
01:00:01
Extensions:
Basic Constraints (critical):
Certificate Authority (CA): TRUE
Path Length Constraint: 1
Name Constraints (critical):
Permitted:
DNSname: example
Key Usage (critical):
Certificate signing.
Subject Key Identifier (not critical):
9d5a5828bca2466ede2e930de28e9316dcab390d
Other Information:
Public Key ID:
sha1:9d5a5828bca2466ede2e930de28e9316dcab390d

sha256:f449822d822c9521c68c0b9b0135dd0fe61f7704c65d4f695daf70b73cb4b116
Public Key PIN:
pin-sha256:9EmCLYIslSHGjAubATXdD+YfdwTGXU9pXa9wtzy0sRY=



Signing certificate...

make Bogus Certificate 

Bug#1004203: closed by Scott Kitterman (Re: RM: src:php-bacon-bacon-qr-code -- ROM; duplicate (already in Debian))

[Adam D. Barratt]

On Sat, 2022-01-29 at 18:41 +0100, Guilhem Moulin wrote:
> Control: reopen -1
> 
> On Mon, 24 Jan 2022 at 14:39:11 +, Debian Bug Tracking System
> wrote:
> > > I mixed things up when filing https://bugs.debian.org/1003615 ,
> > > and
> > > unfortunately didn't notice before the upload entered NEW.  Per
> > > :
> > > 
> > > > Please ignore my upload: turns out the package is already in
> > > > Debian, my
> > > > bad…  Sorry for the trouble!
> > > 
> > > So please remove the just approved [0] src:php-bacon-bacon-qr-
> > > code and
> > > sorry again for the trouble, I certainly didn't mean to hijack
> > > the
> > > package!
> > 
> > Appears it was already removed.
> 
> Was it?  5 days later it's still listed at 
> https://tracker.debian.org/pkg/php-bacon-qr-code
> and in the output of `apt showsrc php-bacon-qr-code`.

That's php-bacon-qr-code, whereas you asked for the removal of php-
bacon-bacon-qr-code (with two "bacon"s). The latter is *not* listed on
the page you mentioned, nor is it in the archive:

adsb@coccia:~$ dak ls php-bacon-bacon-qr-code
adsb@coccia:~$ 

Did you mean to request the removal of php-bacon-qr-code instead?

Regards,

Adam

Bug#1004510: asterisk-opus: Depends on asterisk-1fb7f5c06d7a2052e38d021b3d8ca151 which is gone

[Paul Gevers]

Source: asterisk-opus
Version: 13.7+20171009-2
Severity: serious
X-Debbugs-CC: debian...@lists.debian.org, aster...@packages.debian.org
Tags: sid bookworm
User: debian...@lists.debian.org
Usertags: needs-update
Control: affects -1 src:asterisk

Dear maintainer(s),

With a recent upload of asterisk the autopkgtest of asterisk-opus fails 
in testing when that autopkgtest is run with the binary packages of 
asterisk from unstable. It passes when run with only packages from 
testing. In tabular form:


   passfail
asterisk   from testing1:16.23.0~dfsg+~cs6.10.20220309-2
asterisk-opus  from testing13.7+20171009-2
all others from testingfrom testing

I copied some of the output at the bottom of this report.

Currently this regression is blocking the migration of asterisk to 
testing [1]. Of course, asterisk shouldn't just break your autopkgtest 
(or even worse, your package), but it seems to me that the change in 
asterisk was intended and your package needs to update to the new situation.


If this is a real problem in your package (and not only in your 
autopkgtest), the right binary package(s) from asterisk should really 
add a versioned Breaks on the unfixed version of (one of your) 
package(s). Note: the Breaks is nice even if the issue is only in the 
autopkgtest as it helps the migration software to figure out the right 
versions to combine in the tests.


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=asterisk

https://ci.debian.net/data/autopkgtest/testing/amd64/a/asterisk-opus/18793117/log.gz

autopkgtest: WARNING: Test dependencies are unsatisfiable - calling apt 
install on test deps directly for further data about failing 
dependencies in test logs

Reading package lists...
Building dependency tree...
Reading state information...
Starting pkgProblemResolver with broken count: 1
Starting 2 pkgProblemResolver with broken count: 1
Investigating (0) asterisk-opus:amd64 < none -> 13.7+20171009-2 @un puN Ib >
Broken asterisk-opus:amd64 Depends on 
asterisk-1fb7f5c06d7a2052e38d021b3d8ca151:amd64 < none @un H >
  Considering asterisk:amd64 10001 as a solution to asterisk-opus:amd64 

Broken asterisk-opus:amd64 Depends on libopus0:amd64 < none | 1.3.1-0.1 
@un uH > (>= 1.1)

  Considering libopus0:amd64 0 as a solution to asterisk-opus:amd64 
  Re-Instated libopus0:amd64
Broken asterisk-opus:amd64 Depends on libopusfile0:amd64 < none | 
0.9+20170913-1.1 @un uH > (>= 0.5)
  Considering libopusfile0:amd64 0 as a solution to asterisk-opus:amd64 


  Re-Instated libopusfile0:amd64
Done
Some packages could not be installed. This may mean that you have
requested an impossible situation or if you are using the unstable
distribution that some required packages have not yet been created
or been moved out of Incoming.
The following information may help to resolve the situation:

The following packages have unmet dependencies:
 asterisk-opus : Depends: asterisk-1fb7f5c06d7a2052e38d021b3d8ca151
E: Unable to correct problems, you have held broken packages.
module-loadable  FAIL badpkg
blame: asterisk-opus



OpenPGP_signature
Description: OpenPGP digital signature

Bug#1004509: pyfai: autopkgtest regression on armhf: images have different dimensions

[Paul Gevers]

Source: pyfai
Version: 0.21.0+dfsg1-1
X-Debbugs-CC: debian...@lists.debian.org
Severity: serious
User: debian...@lists.debian.org
Usertags: regression

Dear maintainer(s),

With a recent upload of pyfai the autopkgtest of pyfai fails in testing 
when that autopkgtest is run with the binary packages of pyfai from 
unstable. It passes when run with only packages from testing. In tabular 
form:


   passfail
pyfai  from testing0.21.0+dfsg1-1
all others from testingfrom testing

I copied some of the output at the bottom of this report.

Currently this regression is blocking the migration to testing [1]. Can 
you please investigate the situation and fix it?


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=pyfai

https://ci.debian.net/data/autopkgtest/testing/armhf/p/pyfai/18797397/log.gz

==
FAIL: test_count_csr (pyFAI.test.test_histogram.TestHistogram2d)
Test that the pixel count and the total intensity is conserved
--
Traceback (most recent call last):
  File "/usr/lib/python3/dist-packages/pyFAI/test/test_histogram.py", 
line 337, in test_count_csr

self.assertTrue(delta == 0, msg="check all pixels were counted")
AssertionError: False is not true : check all pixels were counted

==
FAIL: test_numpy_vs_cython_vs_csr_2d 
(pyFAI.test.test_histogram.TestHistogram2d)

Compare numpy histogram with cython simple implementation
--
Traceback (most recent call last):
  File "/usr/lib/python3/dist-packages/pyFAI/test/test_histogram.py", 
line 370, in test_numpy_vs_cython_vs_csr_2d
self.assertTrue(delta_max <= self.err_max_cnt, "pixel count 
difference numpy/csr : max delta=%s" % delta_max)
AssertionError: False is not true : pixel count difference numpy/csr : 
max delta=8.0


==
FAIL: test_2d_nosplit (pyFAI.test.test_csr.TestCSR)
--
Traceback (most recent call last):
  File "/usr/lib/python3/dist-packages/pyFAI/test/test_csr.py", line 
193, in test_2d_nosplit

self.assertLess(error.mean(), 1e-3, "img are almost the same")
AssertionError: 244.15215998872887 not less than 0.001 : img are almost 
the same


--
Ran 375 tests in 138.562s

FAILED (failures=3, skipped=9)
60
44
23
autopkgtest [08:17:51]: test command1



OpenPGP_signature
Description: OpenPGP digital signature

Bug#1004508: ocrad: autopkgtest regression: undefined reference to `png_g*

[Paul Gevers]

Source: ocrad
Version: 0.28-1
X-Debbugs-CC: debian...@lists.debian.org
Severity: serious
User: debian...@lists.debian.org
Usertags: regression

Dear maintainer(s),

With a recent upload of ocrad the autopkgtest of ocrad fails in testing 
when that autopkgtest is run with the binary packages of ocrad from 
unstable. It passes when run with only packages from testing. In tabular 
form:


   passfail
ocrad  from testing0.28-1
all others from testingfrom testing

I copied some of the output at the bottom of this report. Looks like a 
missing test dependency to me.


Currently this regression is blocking the migration to testing [1]. Can 
you please investigate the situation and fix it?


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=ocrad

https://ci.debian.net/data/autopkgtest/testing/amd64/o/ocrad/18793280/log.gz

/usr/bin/ld: /tmp/ccFSvSEW.o: in function `main':
/tmp/autopkgtest-lxc.gm2jjp8j/downtmp/build.Wry/src/ocradcheck.cc:85: 
undefined reference to `Arg_parser::Arg_parser(int, char const* const*, 
Arg_parser::Option const*, bool)'
/usr/bin/ld: 
/usr/lib/gcc/x86_64-linux-gnu/11/../../../x86_64-linux-gnu/libocrad.a(png_io.o): 
in function `read_check_png_sig8(_IO_FILE*, int)':

(.text+0x7b): undefined reference to `png_sig_cmp'
/usr/bin/ld: 
/usr/lib/gcc/x86_64-linux-gnu/11/../../../x86_64-linux-gnu/libocrad.a(png_io.o): 
in function `Page_image::write_png(_IO_FILE*, unsigned int) const':

(.text+0x1f3): undefined reference to `png_create_write_struct'
/usr/bin/ld: (.text+0x209): undefined reference to `png_create_info_struct'
/usr/bin/ld: (.text+0x22d): undefined reference to `png_set_longjmp_fn'
/usr/bin/ld: (.text+0x24f): undefined reference to 
`png_destroy_write_struct'

/usr/bin/ld: (.text+0x30b): undefined reference to `png_init_io'
/usr/bin/ld: (.text+0x35b): undefined reference to `png_set_IHDR'
/usr/bin/ld: (.text+0x376): undefined reference to `png_set_rows'
/usr/bin/ld: (.text+0x38c): undefined reference to `png_write_png'
/usr/bin/ld: (.text+0x39b): undefined reference to 
`png_destroy_write_struct'
/usr/bin/ld: (.text+0x448): undefined reference to 
`png_destroy_write_struct'
/usr/bin/ld: 
/usr/lib/gcc/x86_64-linux-gnu/11/../../../x86_64-linux-gnu/libocrad.a(png_io.o): 
in function `show_png_info(_IO_FILE*, char const*, int)':

(.text+0x4b6): undefined reference to `png_create_read_struct'
/usr/bin/ld: (.text+0x4cc): undefined reference to `png_create_info_struct'
/usr/bin/ld: (.text+0x4f0): undefined reference to `png_set_longjmp_fn'
/usr/bin/ld: (.text+0x50e): undefined reference to `png_init_io'
/usr/bin/ld: (.text+0x51c): undefined reference to `png_set_sig_bytes'
/usr/bin/ld: (.text+0x52b): undefined reference to `png_read_info'
/usr/bin/ld: (.text+0x53a): undefined reference to `png_get_image_height'
/usr/bin/ld: (.text+0x54c): undefined reference to `png_get_image_width'
/usr/bin/ld: (.text+0x565): undefined reference to `png_get_bit_depth'
/usr/bin/ld: (.text+0x577): undefined reference to `png_get_color_type'
/usr/bin/ld: (.text+0x589): undefined reference to `png_get_channels'
/usr/bin/ld: (.text+0x59c): undefined reference to `png_get_interlace_type'
/usr/bin/ld: (.text+0x630): undefined reference to `png_destroy_read_struct'
/usr/bin/ld: (.text+0x6c6): undefined reference to `png_destroy_read_struct'
/usr/bin/ld: (.text+0x6f9): undefined reference to `png_destroy_read_struct'
/usr/bin/ld: 
/usr/lib/gcc/x86_64-linux-gnu/11/../../../x86_64-linux-gnu/libocrad.a(png_io.o): 
in function `Page_image::read_png(_IO_FILE*, int, bool)':

(.text+0x774): undefined reference to `png_create_read_struct'
/usr/bin/ld: (.text+0x78d): undefined reference to `png_create_info_struct'
/usr/bin/ld: (.text+0x7b7): undefined reference to `png_set_longjmp_fn'
/usr/bin/ld: (.text+0x7e3): undefined reference to `png_init_io'
/usr/bin/ld: (.text+0x7f4): undefined reference to `png_set_sig_bytes'
/usr/bin/ld: (.text+0x810): undefined reference to `png_read_png'
/usr/bin/ld: (.text+0x825): undefined reference to `png_get_image_height'
/usr/bin/ld: (.text+0x841): undefined reference to `png_get_image_width'
/usr/bin/ld: (.text+0x862): undefined reference to `png_get_bit_depth'
/usr/bin/ld: (.text+0x889): undefined reference to `png_get_color_type'
/usr/bin/ld: (.text+0x8a0): undefined reference to `png_get_channels'
/usr/bin/ld: (.text+0x8dd): undefined reference to `png_get_rows'
/usr/bin/ld: (.text+0xc39): undefined reference to `png_destroy_read_struct'
/usr/bin/ld: (.text+0xd7f): undefined reference to `png_destroy_read_struct'
/usr/bin/ld: (.text+0xdcf): undefined reference to `png_destroy_read_struct'
collect2: error: ld returned 1 exit status
autopkgtest [04:05:57]: test tests



OpenPGP_signature
Description: OpenPGP digital signature

Bug#1004507: RFP: tagainijisho -- Japanese dictionary and learning assistant

[Gregor Riepl]

Package: wnpp
Severity: wishlist
X-Debbugs-Cc: onit...@gmail.com

* Package name: tagainijisho
  Version : 1.1.90
  Upstream Author : Alexandre Courbot
* URL : https://github.com/Gnurou/tagainijisho
* License : GPL-3.0-or-later
  Programming Lang: C++
  Description : Japanese dictionary and learning assistant

Tagaini Jisho is a Japanese learning assistant built around a vocabulary and
kanji dictionary.
Its goal is to make it easy to:

* Lookup and find words or kanji (later referred to as "entries") that you want
to study,
* Mark and organize the entries you want to study or remember, and
* Consolidate your global knowledge by connecting related studied entries
together to facilitate memorization.

Using Tagaini, you can add entries to your study list, tag them, add notes,
practice them as flashcards, and easily navigate to related entries. A powerful
search engine lets you look words and kanji up from fragments of information,
like character components or number of strokes. Finally, export options allow
you to print booklets for study or export entries to CSV for e.g. using them
with Anki.

This package had previously been part of Debian, but was removed due to a lack
of Qt 5 support.
Version 1.1.90 introduces compatibility with Qt 5, making Tagaini Jisho
suitable for inclusion again.

Bug#1004506: muscle breaks theseus autopkgtest: Unknown option maxiters

[Paul Gevers]

Source: muscle, theseus
Control: found -1 muscle/1:5.1-1
Control: found -1 theseus/3.3.0-10
Severity: serious
Tags: sid bookworm
X-Debbugs-CC: debian...@lists.debian.org
User: debian...@lists.debian.org
Usertags: breaks needs-update

Dear maintainer(s),

With a recent upload of muscle the autopkgtest of theseus fails in 
testing when that autopkgtest is run with the binary packages of muscle 
from unstable. It passes when run with only packages from testing. In 
tabular form:


   passfail
muscle from testing1:5.1-1
theseusfrom testing3.3.0-10
all others from testingfrom testing

I copied some of the output at the bottom of this report.

Currently this regression is blocking the migration of muscle to testing 
[1]. Due to the nature of this issue, I filed this bug report against 
both packages. Can you please investigate the situation and reassign the 
bug to the right package?


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=muscle

https://ci.debian.net/data/autopkgtest/testing/amd64/t/theseus/18786643/log.gz



< BEGIN THESEUS 3.3.0 > 
I===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-=I
ITHESEUS: Maximum likelihood multiple 
superpositioningI

I=-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===I
Detected 48 CPUs ... Reading pdb file ... Successfully read 
10 models and/or structures Selecting coordinates for superposition 
... Calculating superposition transformations ... Calculating 
statistics ... Calculating likelihood statistics ... 10 models 
superimposed in 2.1 ms   * Classical LS pairwise  
   1.87300

  * Least-squares0.72541
  * Maximum Likelihood   0.39551
  ~ Marginal Log Likelihood-4487.32
  ~ AIC-5223.64
  ~ BIC-7333.12
  + Omnibus chi^2  0.95 (P:9.98e-01)
  + Hierarchical var (2.34e-01, 1.50e+00) chi^20.76 (P:7.91e-01)
  + Rotational, translational, covar chi^2 0.95 (P:9.98e-01)
  + Hierarchical minimum var (sigma)   1.34e-02 (1.16e-01)
  < skewness   0.03 (P:3.00e-01)
  < skewness Z-value   1.04
  < kurtosis   0.16 (P:1.28e-02)
  < kurtosis Z-value   2.49
  * Data pts = 5940,  Free params = 655,  D/P = 9.1* Median 
structure = #8

  * N(total) = 1980, N(atoms) = 198, N(structures) = 10
  Total rounds = 15
  Converged to a fractional precision of 5.2e-08
I===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-==I
Transforming coordinates ... Writing transformations file ... 
   Writing transformed coordinates PDB file ... Writing average 
coordinate file ... Done. 
I===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-==I

<  END THESEUS 3.3.0  >



< BEGIN THESEUS 3.3.0 > 
I===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-=I
ITHESEUS: Maximum likelihood multiple 
superpositioningI

I=-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===I
Detected 48 CPUs ... Reading 10 pdb files ... Successfully 
read 10 models and/or structures Reading multiple sequence alignment 
... Calculating superposition transformations ... Calculating 
statistics ... Calculating likelihood statistics ... 10 models 
superimposed in 2.2 ms   * Classical LS pairwise  
   0.80299

  * Least-squares0.32968
  * Maximum Likelihood   0.21859
  ~ Marginal Log Likelihood -271.63
  ~ AIC -712.02
  ~ BIC-1841.58
  + Omnibus chi^2  7.68 (P:0.00e+00)
  + Hierarchical var (7.16e-02, 1.50e+00) chi^21.42 (P:8.53e-02)
  + Rotational, translational, covar chi^2 7.73 (P:0.00e+00)
  + Hierarchical minimum var (sigma)   4.09e-03 (6.40e-02)
  < skewness  -0.10 (P:1.45e-02)
  < skewness Z-value   2.44
  < kurtosis   2.83 (P:2.15e-240)
  < kurtosis Z-value  33.11
  * Data pts = 3270,  Free params = 388,  D/P = 8.4* Median 
structure = #8

  * N(total) 

Bug#1004505: nanoc_4.12.5-2_all-buildd.changes REJECTED

[Aurelien Jarno]

Source: nanoc
Version: 4.12.5-2
Severity: serious

On 2022-01-29 16:19, Debian FTP Masters wrote:
> 
> 
> Version check failed:
> Your upload included the binary package ruby-nanoc-deploying, version 
> 1.0.1-2, for all,
> however testing already has version 1.0.1-2.
> Uploads to unstable must have a higher version than present in testing.
> 
> Mapping sid to unstable.
> 
> ===
> 
> Please feel free to respond to this email if you don't understand why
> your files were rejected, or if you upload new files which address our
> concerns.
> 
> 
> 

Bug#1003883: Tests aren't part of the package build

[vivi]

Hi,

According to the documentation, these tests are meant to be run from Octave.
I can try to run them as part of the package build, but is it really
worth adding a build dependency like Octave just for tests?

What about autopkgtest?
Am I supposed to include the interface built specifically for tests in
the lib package and also add Octave as a test dependency?

Best regards,
Vincent

Bug#1004203: closed by Scott Kitterman (Re: RM: src:php-bacon-bacon-qr-code -- ROM; duplicate (already in Debian))

[Guilhem Moulin]

Control: reopen -1

On Mon, 24 Jan 2022 at 14:39:11 +, Debian Bug Tracking System wrote:
>> I mixed things up when filing https://bugs.debian.org/1003615 , and
>> unfortunately didn't notice before the upload entered NEW.  Per
>> :
>> 
>> | Please ignore my upload: turns out the package is already in Debian, my
>> | bad…  Sorry for the trouble!
>> 
>> So please remove the just approved [0] src:php-bacon-bacon-qr-code and
>> sorry again for the trouble, I certainly didn't mean to hijack the
>> package!
> 
> Appears it was already removed.

Was it?  5 days later it's still listed at 
https://tracker.debian.org/pkg/php-bacon-qr-code
and in the output of `apt showsrc php-bacon-qr-code`.

cheers
-- 
Guilhem.


signature.asc
Description: PGP signature

Bug#1004503: node-tap: Please update to version 15

[Yadd]

Package: node-tap
Version: 12.0.1+ds-4
Severity: normal

node-tap is outdated, version 15 is needed for some package (npm at
least).

Dependencies state:

# tap@15.1.6 (node-tap)
DEPENDENCIES:
  node-tap ITSELF bind-obj-methods,
  fs-exists-cached,
  function-loop,
  own-or,
  own-or-env,
  trivial-deferred,
  yapool
  node-ansi-escapes (ansi-escapes)
  node-auto-bind (auto-bind)
  node-babel7 (@babel/core,
   @babel/plugin-proposal-object-rest-spread,
   @babel/plugin-transform-destructuring,
   @babel/plugin-transform-react-jsx)
  node-chalk (chalk)
  node-chokidar (chokidar)
  node-cli-boxes (cli-boxes)
  node-cli-cursor (cli-cursor)
  node-cli-truncate (cli-truncate)
  node-cliui (cliui)
  node-convert-source-map (convert-source-map)
  node-coveralls (coveralls)
  node-decamelize (decamelize)
  node-diff (diff)
  node-es6-error (es6-error)
  node-esprima (esprima)
  node-find-cache-dir (find-cache-dir)
  node-find-up (find-up)
  node-foreground-child (foreground-child)
  node-glob (glob)
  node-graceful-fs (graceful-fs)
  node-indent-string (indent-string)
  node-is-windows (is-windows)
  node-isexe (isexe)
  node-istanbul (@istanbuljs/load-nyc-config,
 @istanbuljs/schema,
 get-package-type,
 hasha,
 istanbul-lib-coverage,
 istanbul-lib-hook,
 istanbul-lib-instrument,
 istanbul-lib-processinfo,
 istanbul-lib-report,
 istanbul-lib-source-maps,
 istanbul-reports,
 node-preload,
 process-on-spawn,
 test-exclude)
  node-jest-debbundle (is-ci)
  node-lodash (lodash)
  node-lodash-packages (lodash.flattendeep)
  node-make-dir (make-dir)
  node-minipass (minipass)
  node-mkdirp (mkdirp)
  node-ms (ms)
  node-opener (opener)
  node-p-map (p-map)
  node-punycode (punycode)
  node-react (@types/react, react, react-reconciler, scheduler)
  node-read-pkg (type-fest)
  node-resolve-from (callsites, resolve-from)
  node-rimraf (rimraf)
  node-shell-quote (shell-quote)
  node-signal-exit (signal-exit)
  node-slice-ansi (slice-ansi)
  node-source-map-support (source-map-support)
  node-stack-utils (stack-utils)
  node-string-width (string-width)
  node-strip-ansi (strip-ansi)
  node-tap-mocha-reporter (tap-mocha-reporter)
  node-tap-parser (tap-parser)
  node-which (which)
  node-widest-line (widest-line)
  node-wrap-ansi (wrap-ansi)
  node-write-file-atomic (write-file-atomic)
  node-ws (ws)
  node-yaml (yaml)
  node-yargs (yargs)

MISSING:
tap
 └── @isaacs/import-jsx (4.0.1)
 └── caller-path (3.0.1)
 └── caller-callsite (4.1.0)
 └── findit (2.0.0)
 └── ink (3.2.0)
 └── code-excerpt (3.0.0)
 └── convert-to-spaces (1.0.2)
 └── patch-console (1.0.0)
 └── react-devtools-core (4.23.0)
 └── yoga-layout-prebuilt (1.10.0)
 └── @types/yoga-layout (1.9.2)
 └── jackspeak (1.4.1)
 └── libtap (1.1.4)
 └── async-hook-domain (2.0.4)
 └── tap-yaml (1.0.0)
 └── tcompare (5.0.7)
 └── nyc (15.1.0)
 └── caching-transform (4.0.0)
 └── package-hash (4.0.0)
 └── release-zalgo (1.0.0)
 └── spawn-wrap (2.0.0)
 └── (^) tap-yaml (1.0.0)
 └── (^) tcompare (5.0.7)
 └── treport (3.0.2)
 └── (^) @isaacs/import-jsx (4.0.1)
 └── cardinal (2.1.1)
 └── ansicolors (0.3.2)
 └── redeyed (2.1.1)
 └── (^) ink (3.2.0)
 └── unicode-length (2.0.2)

Bug#1004501: kernel: BUG: unable to handle page fault (RIP drm_stub_open)

[Nikolay Kyx]

Package: nvidia-legacy-340xx-kernel-dkms
Version: 340.108-12
Severity: important

Steps to reproduce on xfce desktop:
1. Boot, load and unload nvidia driver kernel module (in my case the
stack is optirun+bbswitch-dkms+nvidia driver);
2. Run xflock4.
So:
$ optirun mpv --version && sleep 1 ; xflock4 # suffices, reproduces
bug _quite frequently_

Visible effect:
Screen blanks, but then freezes, session become unrecoverable. Still
able to switch to another tty and login.

The following kernel errors appears in journal once or multiple times
(usually two Oopses) in row:
[   89.688357] kernel: BUG: unable to handle page fault for address:
c1c1ded0
[   89.688367] kernel: #PF: supervisor read access in kernel mode
[   89.688370] kernel: #PF: error_code(0x) - not-present page
[   89.688373] kernel: PGD 6d014067 P4D 6d014067 PUD 6d016067 PMD
13dc58067 PTE 0
[   89.688380] kernel: Oops:  [#1] SMP PTI
[   89.688385] kernel: CPU: 2 PID: 3934 Comm: Xorg Tainted: P
 OE 5.15.0-3-amd64 #1  Debian 5.15.15-1
[   89.688392] kernel: RIP: 0010:drm_stub_open+0x56/0x130 [drm]
[   89.688446] kernel: Code: e7 ff ff 0f 00 e8 5a fe ff ff 48 89 c5 41
89 c6 48 3d 00 f0 ff ff 0f 87 86 00 00 00 48 8b 58 10 41 be ed ff ff
ff 48 8b 43 30 <48> 8b 80 d0 00 00 00 48 85 c0 74 50 48 8b 38 e8 76 e5
e8 d7 48 8b
[   89.688450] kernel: RSP: 0018:b3c080ee3c48 EFLAGS: 00010283
[   89.688454] kernel: RAX: c1c1de00 RBX: 9adca0d0c800
RCX: 
[   89.688457] kernel: RDX: 0003bd40 RSI: 
RDI: c0114f00
[   89.688459] kernel: RBP: 9adcada0e0a8 R08: 
R09: c01213b0
[   89.688461] kernel: R10:  R11: 
R12: 9adca647b8e0
[   89.688464] kernel: R13: 9adcada12900 R14: ffed
R15: 
[   89.688467] kernel: FS:  7fda74004a40()
GS:9adcc3e8() knlGS:
[   89.688470] kernel: CS:  0010 DS:  ES:  CR0: 80050033
[   89.688473] kernel: CR2: c1c1ded0 CR3: 00013cef0001
CR4: 000206e0
[   89.688476] kernel: Call Trace:
[   89.688480] kernel:  
[   89.688484] kernel:  chrdev_open+0xf3/0x240
[   89.688492] kernel:  ? cdev_default_release+0x20/0x20
[   89.688497] kernel:  do_dentry_open+0x14e/0x370
[   89.688503] kernel:  path_openat+0xaeb/0x1070
[   89.688508] kernel:  ? generic_write_end+0xeb/0x160
[   89.688514] kernel:  ? balance_dirty_pages_ratelimited+0x199/0x3d0
[   89.688520] kernel:  do_filp_open+0xb2/0x150
[   89.688526] kernel:  ? __check_object_size+0x136/0x150
[   89.688530] kernel:  do_sys_openat2+0x96/0x160
[   89.688535] kernel:  __x64_sys_openat+0x53/0x90
[   89.688539] kernel:  do_syscall_64+0x3b/0xc0
[   89.688545] kernel:  entry_SYSCALL_64_after_hwframe+0x44/0xae
[   89.688552] kernel: RIP: 0033:0x7fda74569827
[   89.688556] kernel: Code: 25 00 00 41 00 3d 00 00 41 00 74 47 64 8b
04 25 18 00 00 00 85 c0 75 6b 44 89 e2 48 89 ee bf 9c ff ff ff b8 01
01 00 00 0f 05 <48> 3d 00 f0 ff ff 0f 87 95 00 00 00 48 8b 4c 24 28 64
48 2b 0c 25
[   89.688559] kernel: RSP: 002b:7ffc44848140 EFLAGS: 0246
ORIG_RAX: 0101
[   89.688563] kernel: RAX: ffda RBX: 
RCX: 7fda74569827
[   89.688566] kernel: RDX: 00080002 RSI: 556740d9abf0
RDI: ff9c
[   89.688568] kernel: RBP: 556740d9abf0 R08: 0031
R09: 
[   89.688571] kernel: R10:  R11: 0246
R12: 00080002
[   89.688573] kernel: R13: 556740d9abf0 R14: 556740d9abf0
R15: 556740d9a1c0
[   89.688577] kernel:  
[   89.688579] kernel: Modules linked in: xt_CHECKSUM xt_MASQUERADE
xt_conntrack ipt_REJECT nf_reject_ipv4 xt_tcpudp nft_compat
nft_chain_nat nf_nat nf_conntrack bbswitch(OE) nf_defrag_ipv6
nf_defrag_ipv4 nft_counter nf_tables libcrc32c nfnetlink bridge stp
llc intel_powerclamp r8169 ath9k coretemp ath9k_common ath3k
sparse_keymap at24 ath9k_hw kvm_intel ath kvm mac80211 bluetooth
jitterentropy_rng sha512_ssse3 sha512_generic libarc4 ctr drbg mxm_wmi
ansi_cprng irqbypass ecdh_generic cfg80211 iTCO_wdt intel_pmc_bxt
iTCO_vendor_support watchdog rfkill ecc intel_cstate realtek
snd_hda_codec_realtek mdio_devres snd_hda_codec_generic
snd_hda_codec_hdmi ledtrig_audio libphy intel_uncore snd_hda_intel
snd_intel_dspcfg snd_intel_sdw_acpi bfq snd_hda_codec snd_hda_core
sr_mod cdrom i2c_i801 snd_hwdep sg snd_pcm mei_me snd_timer mei wmi
i2c_smbus button battery ac snd acpi_cpufreq lpc_ich intel_ips
soundcore parport_pc ppdev lp parport fuse configfs ip_tables x_tables
autofs4 ext4 crc16 mbcache
[   89.688668] kernel:  jbd2 crc32c_generic zstd zstd_compress
zsmalloc dm_mod hid_generic usbhid hid sd_mod t10_pi crc_t10dif
crct10dif_generic crct10dif_common i915 i2c_algo_bit ttm ahci
drm_kms_helper libahci ehci_pci ehci_hcd libata cec usbcore rc_core
scsi_mod drm psmouse evdev crc32c_intel scsi_common serio_raw
usb_common video [last unloaded: nvidia]
[   

Bug#902887: [Pkg-pascal-devel] Bug#902887: [fpc] Add dbgsym packages for packages compiled with FPC

[Peter]

On 28/01/2022 22:10, Matija Nalis wrote:

On Fri, Jan 28, 2022 at 08:32:25PM +, Peter wrote:

-k--build-id
is an answer to getting dbgsym packages,
however I tried it out with c-evo and it is breaking reproducible build.
Looks like the build ID is a random string, so the two builds differ.

Does it build reproducibily *without* "-k--build-id"?


Yes. It passes reprotest locally. End of log is

===
Reproduction successful
===
No differences in ./../*.deb
a7440e75208155dd247ba540fa29f04107bc44e7ca7dc9cb95cdeb270decd9c8 
./../c-evo-data_1.3.0.418+dfsg-1_all.deb
dd0d4a122ace2ba25012bffbdb4019bdfe2d0e09afebf14ac134082f7400d35d 
./../c-evo-gtk2_1.3.0.418+dfsg-1_amd64.deb
a72a1cacb5bca6c4a797441f69cec15bd61a1c6b83b12f11e5cd52f2d32d6cd1 
./../c-evo-nh_1.3.0.418+dfsg-1_amd64.deb
968995d0363d7dbc5ad50a0b9a95dd6c9aad6a4bae24666bbe06ed497b19d311 
./../c-evo-qt5_1.3.0.418+dfsg-1_amd64.deb
e1327cb9cb69b2a66fa2c9aab89ba7c473bed50e4131122ff4f476f057b039da 
./../c-evo-stdai_1.3.0.418+dfsg-1_amd64.deb



Relatedly, is "c-evo" packaged in Debian?
I cannot seem to find it in the packages.debian.org, nor on mentors.debian.net
under that name?


Its mentioned here
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=968495

It was deleted from mentors after failing to attract a sponsor.



Cheers,
Peter

Bug#1004500: xserver-xorg-video-nouveau: Xorg killed, 0000:07:00.0: gr: TRAP ch 2 [007fb1c000 Xorg[1903]]

[curious_debian]

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

Dear Maintainer,

Been running my Debian 11 AMD64 server for many months without reboots.
Everything is fine.
GPU is NVIDIA GeForce GT 710. Hardware is stable, been running it without any
changes for several years. RAM is ECC.
Today, I could not VNC into the server. VNC client complained that no X server
is running. dmesg showed nouveau errors. I had to reboot entire machine to get
Xorg and VNC back.

This is dmesg errors:

[557232.209269] nouveau :07:00.0: firmware: failed to load
nouveau/nv106_fuc084 (-2)
[557232.209273] nouveau :07:00.0: Direct firmware load for
nouveau/nv106_fuc084 failed with error -2
[557232.209281] nouveau :07:00.0: firmware: failed to load
nouveau/nv106_fuc084d (-2)
[557232.209282] nouveau :07:00.0: Direct firmware load for
nouveau/nv106_fuc084d failed with error -2
[557232.209284] nouveau :07:00.0: msvld: unable to load firmware data
[557232.209285] nouveau :07:00.0: msvld: init failed, -19
[610293.940696] nouveau :07:00.0: gr: TRAP ch 2 [007fb1c000 Xorg[1903]]
[610293.940704] nouveau :07:00.0: gr: GPC0/TPC0/TEX: 8009
[610293.940790] nouveau :07:00.0: gr: TRAP ch 2 [007fb1c000 Xorg[1903]]
[610293.940796] nouveau :07:00.0: gr: GPC0/TPC0/TEX: 8009
[610293.940844] nouveau :07:00.0: gr: TRAP ch 2 [007fb1c000 Xorg[1903]]
[610293.940849] nouveau :07:00.0: gr: GPC0/TPC0/TEX: 8009
[610293.940931] nouveau :07:00.0: gr: TRAP ch 2 [007fb1c000 Xorg[1903]]
[610293.940936] nouveau :07:00.0: gr: GPC0/TPC0/TEX: 8009
[610293.940979] nouveau :07:00.0: gr: TRAP ch 2 [007fb1c000 Xorg[1903]]
[610293.940984] nouveau :07:00.0: gr: GPC0/TPC0/TEX: 8009
[610293.941071] nouveau :07:00.0: gr: TRAP ch 2 [007fb1c000 Xorg[1903]]
[610293.941076] nouveau :07:00.0: gr: GPC0/TPC0/TEX: 8009
[610293.941124] nouveau :07:00.0: gr: TRAP ch 2 [007fb1c000 Xorg[1903]]
[610293.941129] nouveau :07:00.0: gr: GPC0/TPC0/TEX: 8009
[610293.941213] nouveau :07:00.0: gr: TRAP ch 2 [007fb1c000 Xorg[1903]]
[610293.941219] nouveau :07:00.0: gr: GPC0/TPC0/TEX: 8009
[610293.943847] nouveau :07:00.0: gr: TRAP ch 2 [007fb1c000 Xorg[1903]]
[610293.943854] nouveau :07:00.0: gr: GPC0/TPC0/TEX: 8009
[610293.943933] nouveau :07:00.0: gr: TRAP ch 2 [007fb1c000 Xorg[1903]]
[610293.943938] nouveau :07:00.0: gr: GPC0/TPC0/TEX: 8009
[610293.943992] nouveau :07:00.0: gr: TRAP ch 2 [007fb1c000 Xorg[1903]]
[610293.943997] nouveau :07:00.0: gr: GPC0/TPC0/TEX: 8009
[610293.944205] nouveau :07:00.0: gr: TRAP ch 2 [007fb1c000 Xorg[1903]]
[610293.944211] nouveau :07:00.0: gr: GPC0/TPC0/TEX: 8009
[610293.955386] nouveau :07:00.0: gr: TRAP ch 2 [007fb1c000 Xorg[1903]]
[610293.955394] nouveau :07:00.0: gr: GPC0/TPC0/TEX: 8009
[610293.955478] nouveau :07:00.0: gr: TRAP ch 2 [007fb1c000 Xorg[1903]]
[610293.955484] nouveau :07:00.0: gr: GPC0/TPC0/TEX: 8009
[610293.955528] nouveau :07:00.0: gr: TRAP ch 2 [007fb1c000 Xorg[1903]]
[610293.955533] nouveau :07:00.0: gr: GPC0/TPC0/TEX: 8009
[610293.955625] nouveau :07:00.0: gr: TRAP ch 2 [007fb1c000 Xorg[1903]]
[610293.955631] nouveau :07:00.0: gr: GPC0/TPC0/TEX: 8009
[610293.955677] nouveau :07:00.0: gr: TRAP ch 2 [007fb1c000 Xorg[1903]]
[610293.955682] nouveau :07:00.0: gr: GPC0/TPC0/TEX: 8009
[610293.955927] nouveau :07:00.0: gr: TRAP ch 2 [007fb1c000 Xorg[1903]]
[610293.955933] nouveau :07:00.0: gr: GPC0/TPC0/TEX: 8009
[610293.955976] nouveau :07:00.0: gr: TRAP ch 2 [007fb1c000 Xorg[1903]]
[610293.955981] nouveau :07:00.0: gr: GPC0/TPC0/TEX: 8009
[610293.956064] nouveau :07:00.0: gr: TRAP ch 2 [007fb1c000 Xorg[1903]]
[610293.956069] nouveau :07:00.0: gr: GPC0/TPC0/TEX: 8009
[610293.956113] nouveau :07:00.0: gr: TRAP ch 2 [007fb1c000 Xorg[1903]]
[610293.956118] nouveau :07:00.0: gr: GPC0/TPC0/TEX: 8009
[610293.956202] nouveau :07:00.0: gr: TRAP ch 2 [007fb1c000 Xorg[1903]]
[610293.956207] nouveau :07:00.0: gr: GPC0/TPC0/TEX: 8009
[610293.956260] nouveau :07:00.0: gr: TRAP ch 2 [007fb1c000 Xorg[1903]]
[610293.956265] nouveau :07:00.0: gr: GPC0/TPC0/TEX: 8009
[610293.956464] nouveau :07:00.0: gr: TRAP ch 2 [007fb1c000 Xorg[1903]]
[610293.956469] nouveau :07:00.0: gr: GPC0/TPC0/TEX: 8009
[610296.946768] nouveau :07:00.0: gr: TRAP ch 2 [007fb1c000 Xorg[1903]]
[610296.946780] nouveau :07:00.0: gr: GPC0/TPC0/TEX: 8009
[610296.946865] nouveau :07:00.0: gr: TRAP ch 2 [007fb1c000 Xorg[1903]]
[610296.946871] nouveau :07:00.0: gr: GPC0/TPC0/TEX: 8009
[610296.946920] nouveau :07:00.0: gr: TRAP ch 2 [007fb1c000 Xorg[1903]]
[610296.946926] nouveau :07:00.0: gr: GPC0/TPC0/TEX: 8009
[610296.947010] nouveau :07:00.0: gr: TRAP ch 2 [007fb1c000 Xorg[1903]]
[610296.947017] nouveau :07:00.0: gr: GPC0/TPC0/TEX: 

Bug#1003972: marked as done (libphonenumber: New upstream release - please update)

[tony mancill]

On Sat, Jan 29, 2022 at 08:59:32AM -0700, Neil Mayhew wrote:
> On 2022-01-28 22:33, tony mancill wrote:
> > I noticed that 8.12.42 was released a couple days ago [4].
> > My thought was to let 8.12.41 transition to testing (5 days) before
> > uploading to unstable again, in case that impacts whether/when Ubuntu
> > picks up the update. Let me know if you know otherwise.
> 
> That sounds like the best approach. I don't know the details of how Ubuntu
> picks up the updates, but I have a bug report open with Ubuntu and I'll
> follow up there once 8.12.41 reaches testing. I'll mention that you're
> planning to package 8.12.42 as well.

For what it's worth, the 8.12.42 update doesn't do much for Debian and
Ubuntu, so I see that as something that can be deferred and or skipped
until a more substantial release is available.  Particularly if it helps
8.12.41 migrate all the way through...  The jar dependency bumps in [1]
don't change anything because Debian uses the packaged version of the
library and commons-io is already well-past 2.7 [2].
 
> I see that the mips64el build failed, and it was in the Java part of
> the build, with a JRE panic. I don't know much about Java,
> unfortunately, so I'm sorry I can't help with that.

I believe that was just bad luck, meaning an extant bug in OpenJDK
(maybe only on Zero), or at least not caused by libphonenumber.

> Can 8.12.41 still transition to testing even with mips64el failing?

No.  I have already given it back for a rebuild and will keep an eye on
it and mipsel.

Cheers,
tony

[1] 
https://github.com/google/libphonenumber/commit/9a7be5813db8c0713c111d1c5735c777ce3838f1
[2] https://tracker.debian.org/pkg/commons-io


signature.asc
Description: PGP signature

Bug#1003972: marked as done (libphonenumber: New upstream release - please update)

[Neil Mayhew]

On 2022-01-28 22:33, tony mancill wrote:

I noticed that 8.12.42 was released a couple days ago [4].
My thought was to let 8.12.41 transition to testing (5 days) before
uploading to unstable again, in case that impacts whether/when Ubuntu
picks up the update. Let me know if you know otherwise.


That sounds like the best approach. I don't know the details of how 
Ubuntu picks up the updates, but I have a bug report open with Ubuntu 
and I'll follow up there once 8.12.41 reaches testing. I'll mention that 
you're planning to package 8.12.42 as well.


I see that the mips64el build failed, and it was in the Java part of the 
build, with a JRE panic. I don't know much about Java, unfortunately, so 
I'm sorry I can't help with that.


Can 8.12.41 still transition to testing even with mips64el failing?

Bug#1003227: wmnet: diff for version 1.06-2

[Andreas Metzler]

Package: wmnet
Version: 1.06-1.2
Severity: normal
Tags: patch  pending


Dear maintainer,

I've prepared an salvaging upload for wmnet (versioned as 1.06-2) and
uploaded it to DELAYED/7. Please feel free to tell me if I
should delay it longer.

Regards.

-- 
`What a good friend you are to him, Dr. Maturin. His other friends are
so grateful to you.'
`I sew his ears on from time to time, sure'
diff -Nru wmnet-1.06/debian/changelog wmnet-1.06/debian/changelog
--- wmnet-1.06/debian/changelog	2022-01-06 14:13:30.0 +0100
+++ wmnet-1.06/debian/changelog	2022-01-29 15:18:41.0 +0100
@@ -1,3 +1,18 @@
+wmnet (1.06-2) unstable; urgency=medium
+
+  * Adopt/salvage package under Debian Window Maker Team umbrella.
+Closes: #1003227
+  * Run wrap-and-sort -ast.
+  * Bump to dh level 13.
+  * Use dh sequencer.
+  * Set Rules-Requires-Root: no.
+  * Update watchfile and homepage, point to www.dockapps.net.
+  * Add Vcs-* fields to control.
+  * Add DEP5 copyright.
+  * Fix hardening build. Closes: #668014
+
+ -- Andreas Metzler   Sat, 29 Jan 2022 15:18:41 +0100
+
 wmnet (1.06-1.2) unstable; urgency=medium
 
   * Non-maintainer upload.
diff -Nru wmnet-1.06/debian/control wmnet-1.06/debian/control
--- wmnet-1.06/debian/control	2022-01-06 14:07:33.0 +0100
+++ wmnet-1.06/debian/control	2022-01-08 14:31:56.0 +0100
@@ -1,16 +1,30 @@
 Source: wmnet
 Section: x11
 Priority: optional
-Maintainer: Martin Lazar 
-Standards-Version: 3.9.3
-Build-Depends: debhelper-compat (= 12), libx11-dev, libxext-dev, xutils-dev
-Homepage: http://www.katharineosborne.com/wmnet/
+Maintainer: Debian Window Maker Team 
+Uploaders:
+ Andreas Metzler ,
+Standards-Version: 4.6.0
+Build-Depends:
+ debhelper-compat (= 13),
+ libx11-dev,
+ libxext-dev,
+ xutils-dev,
+Rules-Requires-Root: no
+Homepage: https://www.dockapps.net/wmnet
+Vcs-Browser: https://salsa.debian.org/wmaker-team/wmnet
+Vcs-Git: https://salsa.debian.org/wmaker-team/wmnet.git
 
 Package: wmnet
 Architecture: any
-Depends: ${shlibs:Depends}, ${misc:Depends}, netbase
-Recommends: xfonts-base
-Suggests: wmaker
+Depends:
+ netbase,
+ ${misc:Depends},
+ ${shlibs:Depends},
+Recommends:
+ xfonts-base,
+Suggests:
+ wmaker,
 Description: network monitor for WindowMaker
  This little  program polls network  statistics and does a  few things
  with the  data it  gets. The speedometer  keeps track of  the current
diff -Nru wmnet-1.06/debian/copyright wmnet-1.06/debian/copyright
--- wmnet-1.06/debian/copyright	2012-03-11 13:12:50.0 +0100
+++ wmnet-1.06/debian/copyright	2022-01-08 14:52:52.0 +0100
@@ -1,27 +1,46 @@
-This package was debianized by Philipp Frauenfelder  on
-Wed, 29 Jul 1998 21:53:48 +0200.
-
-It is now maintained by Martin Lazar 
-
-It was downloaded from http://isufug.ee.iastate.edu/~joff/wmnet.html,
-then http://www.katharineosborne.com/wmnet/,
-now at http://dockapps.windowmaker.org/file.php/id/77
-
-wmnet was created by Jesse B. Off  and is upstream
-maintained by Katharine Osborne .
+Format: https://www.debian.org/doc/packaging-manuals/copyright-format/1.0/
+Upstream-Name: wmnet
+Upstream-Contact: Window Maker Developers Team 
+Source: https://www.dockapps.net/wmnet
 
+Files: *
 Copyright:
-
 1998 Jesse B. Off  
 2000 Katharine Osborne 
+License: GPL
 
-Licence:
-
-This software is released under the GNU General Public License agreement.
-No warranties, whatever you know the usuals this is free
-software.  if you use it, great... if you wanna make a change to it,
-great, but please send me the diff.  
-
-On a Debian system the complete text of the GNU General Public License
-can be found in the file `/usr/share/common-licenses/GPL'
+Files: getopt1.c getopt.c getopt.h
+Copyright: 1987,88,89,90,91,92,93,94,96,97 Free Software Foundation, Inc.
+License: GPL-2+
 
+Files: debian/*
+Copyright:
+ 1998-2006 Philipp Frauenfelder 
+ 2007-2008 Sandro Tosi 
+ 2012 Martin Lazar 
+ 2022 Andreas Metzler 
+License: GPL-2+
+
+License: GPL
+ This software is released under the GNU General Public License agreement.
+ No warranties, whatever you know the usuals this is free
+ software.  if you use it, great... if you wanna make a change to it,
+ great, but please send me the diff.
+ .
+ On a Debian system the complete text of the GNU General Public License
+ can be found in the file `/usr/share/common-licenses/GPL'
+
+
+License: GPL-2+
+ The GNU C Library is free software; you can redistribute it and/or
+ modify it under the terms of the GNU Library General Public License as
+ published by the Free Software Foundation; either version 2 of the
+ License, or (at your option) any later version.
+ .
+ The GNU C Library is distributed in the hope that it will be useful,
+ but WITHOUT ANY WARRANTY; without even the implied warranty of
+ MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
+ Library General Public License for more details.
+ .
+ On a Debian system the complete text of the GNU General Public 

Bug#1002023: Partial bugfix

[CJP]

I created the attached patch, based on an upstream patch. I re-compiled
the Wine packages with this patch, and tested it. It prevents Flight
Simulator 2004 and Age of Empires II from crashing.

In AoE, the game is playable, though in my case the window contents
wasn't correctly sized to the (Wine desktop) window size; this might be
specific to my current set-up though, and I could do more testing.

In FS, the menu is usable, but when flying, the screen contents is
garbage, and the 3D elements (environment and also cockpit elements)
are not drawn. The window menu *is* visible. The game is not crashed
though, and based on the sounds, it does respond as expected to
keyboard input.

Note: I used a VM with i386 Debian 11 installed to compile the i386
Wine packages. Getting the wine packages compiled took a lot more
effort than creating the patch for this Wine version.
From: Corné Plooy 
Subject: [PATCH] x11drv: Remove active client window from window data before
deleting it.

Fixes a crash with BadDrawable X error which happens when client window is used
in windows.c:sync_client_position() after the GL drawable has been deleted.
This does not happen under normal circumstances as the next GL drawable created
overrides client window in window structure. But in case new drawable gets
DC_GL_PIXMAP_WIN type it doesn't.

Origin: https://bugs.winehq.org/attachment.cgi?id=67883
Bug: https://bugs.winehq.org/show_bug.cgi?id=49649
Bug-Debian: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1002023

--- a/dlls/winex11.drv/opengl.c
+++ b/dlls/winex11.drv/opengl.c
@@ -241,6 +241,7 @@
 struct gl_drawable
 {
 LONG   ref;  /* reference count */
+HWND   hwnd;
 enum dc_gl_typetype; /* type of GL surface */
 GLXDrawabledrawable; /* drawable for rendering with GL */
 Window window;   /* window if drawable is a GLXWindow */
@@ -1162,10 +1163,23 @@
 {
 case DC_GL_WINDOW:
 case DC_GL_CHILD_WIN:
+{
+struct x11drv_win_data *data = get_win_data( gl->hwnd );
+
 TRACE( "destroying %lx drawable %lx\n", gl->window, gl->drawable );
+if (data)
+{
+if (data->client_window == gl->window)
+{
+XDeleteContext( data->display, data->client_window, winContext );
+data->client_window = 0;
+}
+release_win_data( data );
+}
 pglXDestroyWindow( gdi_display, gl->drawable );
 XDestroyWindow( gdi_display, gl->window );
 break;
+}
 case DC_GL_PIXMAP_WIN:
 TRACE( "destroying pixmap %lx drawable %lx\n", gl->pixmap, gl->drawable );
 pglXDestroyPixmap( gdi_display, gl->drawable );
@@ -1321,6 +1335,7 @@
 /* Default GLX and WGL swap interval is 1, but in case of glXSwapIntervalSGI
  * there is no way to query it, so we have to store it here.
  */
+gl->hwnd = hwnd;
 gl->swap_interval = 1;
 gl->refresh_swap_interval = TRUE;
 gl->format = format;

Bug#991880: gdm3: Please support systemd and elogind via the logind virtual packages

[Beardy Face]

On Wed, 4 Aug 2021 12:15:15 +0100 Mark Hindley  wrote:
> Package: gdm3
> Version: 3.38.2.1-1
> Severity: normal
> Tags: patch
>
> Dear colleagues,
>
> Please consider adjusting the gdm3 dependencies to support libpam-elogind as
> well as libpam-systemd via the logind and default-logind virtual packages.
>
> I think I remember it being said (although I cannot now find the reference,
> apologies if I have misremembered) that gdm3 might require systemd --user and
> therefore note work with elogind. However, as far as I can see, operation
> without systemd --user is supported and the gdm3 changelog only mentions a
> requirement for XDG_RUNTIME_DIR which elogind provides.
>
> To confirm this, I have tested gdm3 with libpam-elogind and can find no
> breakage.
>
> I would appreciate you considering the attached patch for the bookworm cycle.
>
> Many thanks.
>
> Mark



I also have tested this, by making an equivs package.. gdm3 certainly works if 
you either build such a package which says libpam-elogind provides 
libpam-systemd & create a symlink such that pam_systemd.so points to 
pam_elogind.so

Though I suspect that changing the code to accept either would be better, since 
the symlink masks similar problems, such as LightDM disabling the power options 
in it's greeter if no such link exists...

Bug#1002113: gr-gsm: FTBFS: ./obj-x86_64-linux-gnu/CMakeFiles/CMakeTmp/src.c:11: undefined reference to `pthread_create'

[Petter Reinholdtsen]

[Lucas Nussbaum]
> Relevant part (hopefully):
> > /usr/bin/ld: CMakeFiles/cmTC_af046.dir/src.c.o: in function `main':
> > ./obj-x86_64-linux-gnu/CMakeFiles/CMakeTmp/src.c:11: undefined reference to 
> > `pthread_create'
> > /usr/bin/ld: ./obj-x86_64-linux-gnu/CMakeFiles/CMakeTmp/src.c:12: undefined 
> > reference to `pthread_detach'
> > /usr/bin/ld: ./obj-x86_64-linux-gnu/CMakeFiles/CMakeTmp/src.c:13: undefined 
> > reference to `pthread_cancel'
> > /usr/bin/ld: ./obj-x86_64-linux-gnu/CMakeFiles/CMakeTmp/src.c:14: undefined 
> > reference to `pthread_join'
> > collect2: error: ld returned 1 exit status

Look like something, somewhere, is missing -lpthread to find the
required functions.  Anyone got a patch to fix it?

-- 
Happy hacking
Petter Reinholdtsen

Bug#1002192: kitinerary: FTBFS: 12: QWARN : ExtractorScriptEngineTest::testInfiniteLoop() org.kde.kitinerary: JS ERROR: [qrc://buggy.js]:0: Error: Interrupted

[Florian Ernst]

tags 1002192 patch
thanks

On Tue, Dec 21, 2021 at 05:02:35PM +0100, Lucas Nussbaum wrote:
> During a rebuild of all packages in sid, your package failed to build
> on amd64.
> [...]
> > test 29
> >   Start 29: calendarhandlertest
> > 
> > 29: Test command: 
> > /<>/obj-x86_64-linux-gnu/bin/calendarhandlertest
> > 29: Environment variables: 
> > 29:  QT_PLUGIN_PATH=/<>/obj-x86_64-linux-gnu/bin:
> > 29: Test timeout computed to be: 1000
> > 29: * Start testing of CalendarHandlerTest *
> > 29: Config: Using QtTest library 5.15.2, Qt 5.15.2 
> > (x86_64-little_endian-lp64 shared (dynamic) release build; by GCC 11.2.0), 
> > debian unknown
> > 29: PASS   : CalendarHandlerTest::initTestCase()
> > 29: PASS   : CalendarHandlerTest::testCreateEvent(canceled.json)
> > 29: QWARN  : CalendarHandlerTest::testCreateEvent(event.json) 
> > QFSFileEngine::open: No file name specified
> > 29: QWARN  : CalendarHandlerTest::testCreateEvent(event.json) 
> > kf.i18n.localeData: Unable to open iso_3166-1.json "" "No file name 
> > specified"
> > 29: QWARN  : CalendarHandlerTest::testCreateEvent(event.json) 
> > QFSFileEngine::open: No file name specified
> > 29: QWARN  : CalendarHandlerTest::testCreateEvent(event.json) 
> > kf.i18n.localeData: Unable to open iso_3166-1.json "" "No file name 
> > specified"
> > 29: QWARN  : CalendarHandlerTest::testCreateEvent(event.json) 
> > QFSFileEngine::open: No file name specified
> > 29: QWARN  : CalendarHandlerTest::testCreateEvent(event.json) 
> > kf.i18n.localeData: Unable to open iso_3166-1.json "" "No file name 
> > specified"
> > 29: QWARN  : CalendarHandlerTest::testCreateEvent(event.json) kf.contacts: 
> > address format database incomplete (no format for locale "" found). Using 
> > default address formatting.
> > 29: QDEBUG : CalendarHandlerTest::testCreateEvent(event.json) Actual:  
> > BEGIN:VCALENDAR

(similar messages reported for the other failures)

That file iso_3166-1.json is part of the iso-codes package which was
*not* installed during the build as can be seen from the full build log

> http://qa-logs.debian.net/2021/12/20/kitinerary_21.08.1-1_unstable.log

which lists

| Recommended packages:
|   curl | wget | lynx ca-certificates dbus libarchive-cpio-perl libglib2.0-data
|   xdg-user-dirs libkf5archive-doc libkf5codecs-doc libkf5config-doc iso-codes
  ^
and I can confirm that without that package the build indeed fails.

However, when adding that package to B-D the build reproducably succeeds
again. This is a bit weird as during previous builds that package
apparently wasn't required, as can be seen in the old build logs, but it
seems now it is. Still, I'm taking the liberty to tag this bug "patch".

Cheers,
Flo
diff -Nru kitinerary-21.08.1/debian/control kitinerary-21.08.1/debian/control
--- kitinerary-21.08.1/debian/control   2021-09-11 00:21:58.0 +0200
+++ kitinerary-21.08.1/debian/control   2022-01-29 13:46:39.0 +0100
@@ -8,6 +8,7 @@
debhelper-compat (= 13),
extra-cmake-modules (>= 5.83.0~),
gettext,
+   iso-codes,
libkf5archive-dev (>= 5.71.0~),
libkf5calendarcore-dev (>= 5:5.83.0~),
libkf5contacts-dev (>= 5:5.83.0~),


signature.asc
Description: PGP signature

Bug#1003708: Fw: Bug#1003708: units: Segmentation fault on certain conversions in verbose mode

[Stephen Kitt]

Control: tag -1 forwarded

Hi Adrian,

I had a quick look into this, it seems related to the fact that brwiregauge,
plategauge etc. are units with discrete values, and the user is asking for
the inverse; but I’m not sure what the best way to fix this is.
fun->inverse.param ends up with nonsensical values:

(gdb) run
Starting program: /home/steve/Debian/units/units -v
Currency exchange rates from FloatRates (USD base) on 2020-11-15 
3679 units, 109 prefixes, 114 nonlinear units

You have: cm
You want: brwiregauge

Program received signal SIGSEGV, Segmentation fault.
__strlen_avx2 () at ../sysdeps/x86_64/multiarch/strlen-avx2.S:65
65  ../sysdeps/x86_64/multiarch/strlen-avx2.S: No such file or directory.
(gdb) bt
#0  __strlen_avx2 () at ../sysdeps/x86_64/multiarch/strlen-avx2.S:65
#1  0x77c8cf76 in __vfprintf_internal (s=0x77de06a0 
<_IO_2_1_stdout_>, 
format=format@entry=0x55568f6d "\t%s = %s(", 
ap=ap@entry=0x7fffd540, mode_flags=mode_flags@entry=2)
at vfprintf-internal.c:1688
#2  0x77d2ce88 in ___vfprintf_chk (fp=, 
flag=flag@entry=1, format=format@entry=0x55568f6d "\t%s = %s(", 
ap=ap@entry=0x7fffd540) at vfprintf_chk.c:29
#3  0x84a5 in vprintf (__ap=0x7fffd540, __fmt=0x55568f6d 
"\t%s = %s(")
at /usr/include/x86_64-linux-gnu/bits/stdio2.h:120
#4  logprintf (format=format@entry=0x55568f6d "\t%s = %s(") at units.c:415
#5  0xe605 in showfunc (havestr=0x555dd900 "cm", 
have=have@entry=0x555703a0 , fun=0x556005c0)
at units.c:2976
#6  0x7e25 in main (argc=, argv=) at 
units.c:6267
(gdb) up
#1  0x77c8cf76 in __vfprintf_internal (s=0x77de06a0 
<_IO_2_1_stdout_>, 
format=format@entry=0x55568f6d "\t%s = %s(", 
ap=ap@entry=0x7fffd540, mode_flags=mode_flags@entry=2)
at vfprintf-internal.c:1688
1688vfprintf-internal.c: No such file or directory.
(gdb) up
#2  0x77d2ce88 in ___vfprintf_chk (fp=, 
flag=flag@entry=1, format=format@entry=0x55568f6d "\t%s = %s(", 
ap=ap@entry=0x7fffd540) at vfprintf_chk.c:29
29  vfprintf_chk.c: No such file or directory.
(gdb) up
#3  0x84a5 in vprintf (__ap=0x7fffd540, __fmt=0x55568f6d 
"\t%s = %s(")
at /usr/include/x86_64-linux-gnu/bits/stdio2.h:120
120   return __vfprintf_chk (stdout, __USE_FORTIFY_LEVEL - 1, __fmt, __ap);
(gdb) up
#4  logprintf (format=format@entry=0x55568f6d "\t%s = %s(") at units.c:415
415   vprintf(format, args);
(gdb) up
#5  0xe605 in showfunc (havestr=0x555dd900 "cm", 
have=have@entry=0x555703a0 , fun=0x556005c0)
at units.c:2976
2976 logprintf("\t%s = %s(", havestr, fun->inverse.param);
(gdb) print *fun
$1 = {name = 0x556005a0 "brwiregauge", forward = {param = 0x690077 
, 
def = 0x650072 , 
dimen = 0x610067 , 
domain_min = 0x670075, 
domain_max = 0x5b0065, domain_min_open = 105, domain_max_open = 110}, 
inverse = {
param = 0x20005d , 
def = 0x200020 , 
dimen = 0x200020 , 
domain_min = 0x200020, 
domain_max = 0x200020, domain_min_open = 45, domain_max_open = 54}, 
table = 0x555bc500, tablelen = 16, 
  tableunit = 0x55600660 "in", next = 0x555d44f0, skip_error_check = 0, 
linenumber = 5857, 
  file = 0x55589a40 "/usr/share/units/definitions.units"}


Regards,

Stephen


Begin forwarded message:

Date: Thu, 13 Jan 2022 19:20:31 -0600
From: "Owen T. Heisler" 
To: Debian Bug Tracking System 
Subject: Bug#1003708: units: Segmentation fault on certain conversions in
verbose mode


Package: units
Version: 2.21-1
Severity: normal
X-Debbugs-Cc: wri...@owenh.net

Hi, the following commands result in a segmentation fault:

$ echo -e "cm\nbrwiregauge" | units -v
$ echo -e "cm\nplategauge" | units -v

This was discovered while attempting to use the script example in the
"SCRIPTING WITH UNITS" section of the units(1) man page.

Thank you for maintaining this useful tool.

Owen T. Heisler

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

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

Versions of packages units depends on:
ii  libc6 2.31-13+deb11u2
ii  libreadline8  8.1-1

Versions of packages units recommends:
ii  python3   3.9.2-3
ii  python3-requests  2.25.1+dfsg-2

units suggests no packages.

-- debconf-show failed


pgpFbs11_850W.pgp
Description: OpenPGP digital signature

Bug#1004498: RFP: toml11 -- C++11 (or later) header-only toml parser/encoder

[Thomas Koch]

Package: wnpp
X-Debbugs-Cc: debian-...@lists.debian.org, Michael R. Crusoe 
Severity: wishlist

* Package name: toml11
  Version : 3.7.0
  Upstream Author : Copyright (c) 2017-2021 Toru Niina
* URL : https://github.com/ToruNiina/toml11
* License : MIT
  Programming Lang: C++
  Description : C++11 (or later) header-only toml parser/encoder

toml11 is a C++11 (or later) header-only toml parser/encoder depending only on
C++ standard library.

- It is compatible to the latest version of TOML v1.0.0.
- It is one of the most TOML standard compliant libraries, tested with the 
language agnostic test suite for TOML parsers by BurntSushi.
- It shows highly informative error messages. You can see the error messages 
about invalid files at CircleCI.
- It has configurable container. You can use any random-access containers and 
key-value maps as backend containers.
- It optionally preserves comments without any overhead.
- It has configurable serializer that supports comments, inline tables, literal 
strings and multiline strings.
- It supports user-defined type conversion from/into toml values.
- It correctly handles UTF-8 sequences, with or without BOM, both on posix and 
Windows.

This library is a dependency of nix[1] and uncalled[2].

[1] https://tracker.debian.org/pkg/nix
[2] https://tracker.debian.org/pkg/uncalled

I've never packaged a C or C++ library so I'd be grateful for somebody else to
package this. One could look at nlohmann-json3 which is also a C++ header
library.

[3] https://tracker.debian.org/pkg/nlohmann-json3

Bug#1004448: gnome-session: should manage session with systemd --user, if available

[Simon McVittie]

Control: found -1 40.1.1-2
Control: severity -1 normal

On Thu, 27 Jan 2022 at 20:23:36 +, Simon McVittie wrote:
> Recent-ish upstream versions of gnome-session have been able to manage the
> whole login session as a group of `systemd --user` services:
> https://wiki.gnome.org/Initiatives/SystemdUser

In fact gnome-session in stable already does this, and it appears
to have been disabled by mistake in testing/unstable. The patch
debian/patches/debian/Make-sure-to-pass-systemd-when-we-re-managing-the-user-se.patch
was removed about a year ago, but we're still configuring with
-Dsystemd_session=enable rather than -Dsystemd_session=default, which
means systemd --user session management is still opt-in but we're no longer
opting in.

With -Dsystemd_session=default, I believe we would now have the intended
semantics: users of dbus-user-session (the majority) get a systemd-based
session, and dbus-x11/sysvinit systems get the old code path.

smcv

Bug#914321: n2n: Upstream released version 3.0

[Hamish Coleman]

Upstream has recently released an even newer version with significant
changes and improvements.

I am part of the maintainer team for the upstream and would like to see
the new version available in Debian.  Please let me know if there is anything
that we could do to help this.

-- 
Use Linux!  ham...@zot.org
*** O- ***
  ``... why haven't you indolent fleshers transformed the whole galaxy
into chocolate?''
  ``Give us time.''

Bug#1002564: [pkg-lxc-devel] Bug#1002564: lxc: packaging adjustments for LXD

[Pierre-Elliott Bécue]

Hi Mathias,

Mathias Gibbens  wrote on 29/01/2022 at 03:41:40+0100:
> On Fri, 2022-01-28 at 01:33 +0100, Pierre-Elliott Bécue wrote:
>> I've made some changes I've decided to upload on salsa and on
>> experimental.
>> 
>> If you're able to test these changes on some clean environment, I'd
>> be
>> happy if you could do it as I like the time to redo a clean testing
>> environment for lxc right now.
>> 
>> If you can't, I'll try to do it this weekend or during the next week.
>
>   Thanks! I took a quick look this evening and noticed one thing -- the
> directory `usr/lib/*/lxc/rootfs` is still listed in the d/lxc.install
> file. Can that also get moved over into the liblxc-common package? LXD
> expects to be able to use that directory similarly to lxc when starting
> up containers.

Ah, sorry. It slipped out from my sight.

>   As it looks like liblxc-common is including the
> /usr/sbin/init.lxc{,.static} binaries it can't be an Architecture: all
> package, so having a directory with an architecture-dependent path
> hopefully won't be an issue. (Side note, in d/control, would it make
> sense to keep liblxc-common as Architecture: linux-any to match all the
> other binary packages that are built?)

Indeed! You're right. I've changed to linux-any.

>   I'll do a build and test of LXD in a fresh environment this weekend
> and report back on any other issues I find.

Thanks for your feedback and for spotting these issues. :)

-- 
PEB


signature.asc
Description: PGP signature

Bug#1004447: [Debian-on-mobile-maintainers] Bug#1004447: Acknowledgement (modemmanager: Sierra Wireless EM7455 stops working after upgrade to 1.18.4-1 (stays in FCC lock))

[Guido Günther]

Hi Bjørn,
On Fri, Jan 28, 2022 at 08:49:27PM +0100, Bjørn Bürger wrote:
> Argh! Nevermind, just figured it out.
> 
> It's actually documented in the original NEWS file, but it's
> not very obvious to the user, why suddenly the modem disappears.
> 
> This is the solution:
> 
> ln -sft /etc/ModemManager/fcc-unlock.d
> /usr/share/ModemManager/fcc-unlock.available.d/*
> 
> and it's also documented quite nicely on the modemmanager.org
> website. Maybe debian should add a prominent Warning, because
> this will break modemmanager heavily for a lot of non-technical
> people:

Thanks for investigating! Since you know exactly what you were looking
for do you want to draft something for NEWS.Debian / README.Debian and
submit this at
https://salsa.debian.org/DebianOnMobile-team/modemmanager ? That would be great.

Cheers,
 -- Guido

> 
> - cite from NEWS.gz ---
> 
> ModemManager 1.18.4
> ---
> 
>  * A new FCC unlock operation management via external scripts is introduced,
>which will avoid to automatically unlock FCC locked devices unless the
> user
>has configured the operation manually, or unless an official
> vendor-provided
>FCC unlock tool is found in the system.
> 
>Please refer to the following URL for full details:
>https://modemmanager.org/docs/modemmanager/fcc-unlock/
> 
>The following changes should be taken into account by distribution
> packagers:
>** A set of FCC unlock scripts named as the specific vendor 'vid' will be
>   installed in ${datadir}/ModemManager/fcc-unlock.available.d.
>** A set of symlinks is created named as the specific device 'vid:pid',
> and
>   pointing to the per-vendor 'vid' files, in the same location inside
>   ${datadir}.
>** A new ${sysconfdir}/ModemManager/fcc-unlock.d directory is created,
> where
>   users will manually install additional symlinks to the scripts shipped
> in
>   ${datadir}.
>** A new ${libdir}/ModemManager/fcc-unlock.d directory is created, where
>   vendors will install their own official FCC unlock tools.
>** Both fcc-unlock.d directories should be empty on a new install, and
> their
>   contents (if any) should not be removed on ModemManager upgrades.
> 
> ---
> 
> Have a nice weekend.
> Bjørn
> 
> ___
> Debian-on-mobile-maintainers mailing list
> debian-on-mobile-maintain...@alioth-lists.debian.net
> https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/debian-on-mobile-maintainers

Bug#1004496: debianutils: [INTL:de] updated German man page translation

[Helge Kreutzmann]

Package: debianutils
Version: 5.7-0.1
Severity: wishlist
Tags: patch l10n

Please find the updated German man page translation for debianutils
attached.

If you update your template, please use 
'msgfmt --statistics '
to check the po-files for fuzzy or untranslated strings.

If there are such strings, please contact me so I can update the 
German translation.

Greetings
Helge
# Translation of debianutils man page template to German
# Copyright (C) Helge Kreutzmann , 2011, 2012, 2017, 
2018, 2020, 2022.
# This file is distributed under the same license as the debianutils package.
#
msgid ""
msgstr ""
"Project-Id-Version: debianutils man page 5.7\n"
"POT-Creation-Date: 2021-09-23 12:52-0400\n"
"PO-Revision-Date: 2022-01-29 10:47+0100\n"
"Last-Translator: Helge Kreutzmann \n"
"Language-Team: German \n"
"Language: de\n"
"MIME-Version: 1.0\n"
"Content-Type: text/plain; charset=UTF-8\n"
"Content-Transfer-Encoding: utf-8\n"

#. type: TH
#: add-shell.8:1
#, no-wrap
msgid "ADD-SHELL"
msgstr "ADD-SHELL"

#. type: TH
#: add-shell.8:1 remove-shell.8:1
#, no-wrap
msgid "23 Sep 2021"
msgstr "23. Sep. 2021"

#. type: SH
#: add-shell.8:2 installkernel.8:2 ischroot.1:3 remove-shell.8:2 run-parts.8:9
#: savelog.8:3 update-shells.8:2 which.1:3
#, no-wrap
msgid "NAME"
msgstr "NAME"

#. type: Plain text
#: add-shell.8:4
msgid "add-shell - add shells to the list of valid login shells"
msgstr "add-shell - Shells zu der Liste der gültigen Anmelde-Shells hinzufügen"

#. type: SH
#: add-shell.8:4 installkernel.8:4 ischroot.1:5 remove-shell.8:4 run-parts.8:11
#: savelog.8:5 update-shells.8:4 which.1:5
#, no-wrap
msgid "SYNOPSIS"
msgstr "ÜBERSICHT"

#. type: Plain text
#: add-shell.8:8
msgid "B I [I...]"
msgstr "B I [I…]"

#. type: SH
#: add-shell.8:8 installkernel.8:6 ischroot.1:8 remove-shell.8:8 run-parts.8:20
#: savelog.8:11 update-shells.8:7 which.1:7
#, no-wrap
msgid "DESCRIPTION"
msgstr "BESCHREIBUNG"

#. type: Plain text
#: add-shell.8:18
msgid ""
"B copies I to I, adds the given "
"shells to this file if they are not already present, and copies this "
"temporary file back to I."
msgstr ""
"B kopiert I nach I, fügt die "
"angegebenen Shells zu dieser Datei hinzu falls sie dort noch nicht enthalten "
"sind und kopiert die temporäre Datei wieder zu I zurück."

#. type: Plain text
#: add-shell.8:20
msgid "The shells must be provided by their full pathnames."
msgstr "Die Shells müssen mit ihrem vollen Pfadnamen angegeben werden."

#. type: SH
#: add-shell.8:20 remove-shell.8:17
#, no-wrap
msgid "ENVIRONMENT"
msgstr "UMGEBUNG"

#. type: TP
#: add-shell.8:21 remove-shell.8:18
#, no-wrap
msgid "I"
msgstr "I"

#. type: Plain text
#: add-shell.8:26 remove-shell.8:23
msgid "specifies the base path under which I resides."
msgstr "Legt den Basispfad fest, unter dem sich I befindet."

#. type: SH
#: add-shell.8:26 remove-shell.8:23 savelog.8:166 update-shells.8:34
#, no-wrap
msgid "SEE ALSO"
msgstr "SIEHE AUCH"

#.  -*- nroff -*-
#. type: Plain text
#: installkernel.8:1 run-parts.8:8 which.1:2
msgid "B(5)"
msgstr "B(5)"

#. type: TH
#: installkernel.8:1
#, no-wrap
msgid "INSTALLKERNEL"
msgstr "INSTALLKERNEL"

#. type: TH
#: installkernel.8:1
#, no-wrap
msgid "7 Jan 2001"
msgstr "7. Jan. 2001"

#. type: TH
#: installkernel.8:1
#, no-wrap
msgid "Debian Linux"
msgstr "Debian Linux"

#. type: Plain text
#: installkernel.8:4
msgid "installkernel - install a new kernel image"
msgstr "installkernel - installiert ein neues Kernel-Image"

#. type: Plain text
#: installkernel.8:6
msgid "BI"
msgstr "BI"

#. type: Plain text
#: installkernel.8:13
msgid ""
"B installs a new kernel image onto the system from the Linux "
"source tree.  It is called by the Linux kernel makefiles when B is invoked there."
msgstr ""
"B installiert ein neues Kernel-Image auf das System aus dem "
"Linux-Quellbaum. Es wird von den Linux-Kernel-Makefiles aufgerufen, wenn "
"dort B ausgeführt wird."

#. type: Plain text
#: installkernel.8:24
msgid ""
"The new kernel is installed into I<{directory}/vmlinuz-{version}>.  If a "
"symbolic link I<{directory}/vmlinuz> already exists, it is refreshed by "
"making a link from I<{directory}/vmlinuz> to the new kernel, and the "
"previously installed kernel is available as I<{directory}/vmlinuz.old>."
msgstr ""
"Der neue Kernel wird in I<{Verzeichnis}/vmlinuz-{Version}> installiert. "
"Falls bereits ein symbolischer Link I<{Verzeichnis}/vmlinuz> existiert, wird "
"er erneuert, indem ein Link von I<{Verzeichnis}/vmlinuz> auf den neuen "
"Kernel gelegt wird. Der vorher installierte Kernel ist unter I<{Verzeichnis}/"
"vmlinuz.old> verfügbar."

#. type: SH
#: installkernel.8:24 ischroot.1:35 savelog.8:159
#, no-wrap
msgid "BUGS"
msgstr "FEHLER"

#.  -*- nroff -*-
#. type: Plain text
#: ischroot.1:2
msgid ""
"B resides in /sbin only because the Linux kernel makefiles "
"call it from there.  It should really be in /usr/sbin.  It isn't needed to "
"boot a system."
msgstr ""
"B liegt nur in /sbin, da die Makefiles des Linux-Kernels 

Bug#1004495: 5.16.3-1~exp1 FTBFS on i386

[Salvatore Bonaccorso]

Control: tags -1 + confirmed
Control: forwarded -1 
https://lore.kernel.org/lkml/20220114075756.838243-1-sly...@gmail.com/

Hi Daniel,

On Sat, Jan 29, 2022 at 10:23:21AM +0100, Daniel Baumann wrote:
> Package: linux
> Version: 5.16.3-1~exp1
> Severity: serious
> Tag: experimental
> 
> Hi,
> 
> unfortunately the last upload to experimental failed to build on i386.

Thank you Daniel from reporting, yes we are already aware of it, and for armel,
armhf (and will be for the other 32bit architectures). From yesterdays
conversation on IRC:

[23:49] < bwh> carnil: waldi: I suppose this is caused by 
https://salsa.debian.org/kernel-team/linux/commit/cf5238aa51bb6611bb7393ea6ec5f6f7c1a37711
[23:52] < bwh> and the preceding statement "idx = (rel->addend / sizeof(void 
*));" means the range of idx is twice as large on 32-bit, potentially requiring 
one more digit
[23:57] < bwh> also it seems like objtool can't actually handle cross-builds 
with differing word size...

The issue is there already since 5.16-rc1 but only got uncovered now with the
above change.

Regards,
Salvatore

Bug#1004495: 5.16.3-1~exp1 FTBFS on i386

[Daniel Baumann]

Package: linux
Version: 5.16.3-1~exp1
Severity: serious
Tag: experimental

Hi,

unfortunately the last upload to experimental failed to build on i386.

Regards,
Daniel

Bug#1004494: Wish: add alsacaps to alsa-utils

[Roland Schwarz]

Package: alsa-utils
Version: 1.2.3-1 amd64

Please consider adding the little helper utility:

alsacap

to the toolbox. I found the utility by following a link from
the [Documenation] [1] section on the alsa homepage. The link
leads to a page [A close look at ALSA] [2] written by Volker
Schatz.

The utility is very helpful for debugging alsa setups because
it helps exploring the *parameter space*. It can help answer
such questions as why certain parameters cannot be sucessfully
applied to a particular soundcard and how to remedy the situation.

The software can be compiled and installed by:

wget https://www.volkerschatz.com/noise/alsacap.tgz
tar - xzf alsacap.tgz
cd alsacap
make
sudo make install

The license is:


alsacap is copyright (c) 2007 Volker Schatz (alsacap at the domain 
volkerschatz.com)


Permission to use, copy, modify, and/or distribute this software for any
purpose with or without fee is hereby granted, provided that the above
copyright notice and this permission notice appear in all copies.

THE SOFTWARE IS PROVIDED "AS IS" AND THE AUTHOR DISCLAIMS ALL WARRANTIES
WITH REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF
MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR ANY
SPECIAL, DIRECT, INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES 
WHATSOEVER

RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN ACTION OF
CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN
CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE.



[1]: https://alsa-project.org/wiki/Documentation
[2]: https://www.volkerschatz.com/noise/alsa.html
--
__
  _  _  | Roland Schwarz
 |_)(_  |
 | \__) | mailto:roland.schw...@blackspace.at
| http://www.blackspace.at


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1004389: transition: botan

[Sebastian Ramacher]

Control: tags -1 confirmed
Control: forwarded -1 
https://release.debian.org/transitions/html/auto-botan.html

On 2022-01-26 16:21:37 +0100, László Böszörményi wrote:
> Package: release.debian.org
> Severity: normal
> User: release.debian@packages.debian.org
> Usertags: transition
> 
> Hi RMs,
> 
> Straightforward transition of botan. Affected packages are biboumi,
> rnp and thunderbird.
> All builds fine with the botan 2.19.1+dfsg-1 version from experimental.

Go ahead

Cheers

> 
> Regards,
> Laszlo/GCS
> 

-- 
Sebastian Ramacher


signature.asc
Description: PGP signature

Bug#864082: Improved patch

[Roland Clobus]

Hello Johannes,

On 28/01/2022 20:22, Johannes Schauer Marin Rodrigues wrote:

Would you be willing to submit an updated patch containing the name and email
of your choice and a commit message that explains your change? What you wrote
above is a good explanation I think.


Attached is the updated patch.

A commit message would be:

This patch changes the behaviour of the cache directory filename
calculation to be based on the "source" directory name, rather than
being entirely random if the SOURCE_DATE_EPOCH[1] environment variable
was determined to be present via getenv(3).

The two main scenarios are covered by this patch:
1) Invocation of 'fc-cache' as a postinst step
2) Invocation of 'update-initramfs' as a postinst step where the
   initial ramdisk contains a font (e.g. when the plymouth hook calls
   'fc-cache -s -y TEMPDIR')


or much shorter:


Generate deterministic cache directory filenames if SOURCE_DATE_EPOCH is 
set.



With kind regards,
Roland Clobus
From: Roland Clobus 
Date: Sat 29 Jan 07:58:22 UTC 2022
Subject: [PATCH] Make the cache filenames determinstic

Whilst working on the Reproducible Builds[0] effort, we noticed that
fontconfig generates cache files with unreproducible/non-deterministic
filenames.

This is a supplement to the changes added in f098adac54ab where we
ensured that the checksums themselves were determistic but the files
that were stored in the cache directory are currently being given
"random" names via uuid(3)'s uuid_generate_random function, thus
any images that generate such files have different contents on every
build.

This patch changes the behaviour of the cache directory filename
calculation to be based on the "source" directory name, rather than
being entirely random if the SOURCE_DATE_EPOCH[1] environment variable
was determined to be present via getenv(3).

The two main scenarios are covered by this patch:
1) Invocation of 'fc-cache' as a postinst step
2) Invocation of 'update-initramfs' as a postinst step where the
   initial ramdisk contains a font (e.g. when the plymouth hook calls
   'fc-cache -s -y TEMPDIR')

This work is based on the patch written by Chris Lamb
 who is sponsored by Tails[3].

 [0] https://reproducible-builds.org/
 [1] https://reproducible-builds.org/specs/source-date-epoch/
 [2] https://bugs.debian.org/864082
 [3] https://tails.boum.org/

Bug-Debian: http://bugs.debian.org/864082
---
 src/fccache.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

Index: fontconfig-2.13.1/src/fccache.c
===
--- fontconfig-2.13.1.orig/src/fccache.c
+++ fontconfig-2.13.1/src/fccache.c
@@ -101,7 +101,13 @@ FcDirCacheCreateUUID (FcChar8  *dir,
 	ret = FcFalse;
 	goto bail3;
 	}
-	uuid_generate_random (uuid);
+	if (getenv("SOURCE_DATE_EPOCH"))
+	{
+	const uuid_t nil = { 0 };
+	uuid_generate_sha1 (uuid, nil, (const char *)dir, strlen((const char *)dir));
+	}
+	else
+	uuid_generate_random (uuid);
 	if (force)
 	hash_add = FcHashTableReplace;
 	else


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1004493: not find rtc device in rt kernel

[肖盛文）]

Package: src:linux
Version: 5.16~rc8-1~exp1
Severity: normal
X-Debbugs-Cc: atzli...@sina.com

Hi,
When I boot use the rt kernel, I can't use hwclock in my
arm64 FT2000-4 CPU mini PC box.

It's normal when I boot use the no rt kernel.

From the dmesg, I can't find the rtc device in rt kernel.

The following is some normal info from no rt kernel 5.16.0-rc8-arm64,
it can find rtc device, hwclock run normal.

dmesg|grep rtc

[1.539761] rtc-efi rtc-efi.0: registered as rtc0
[1.551881] rtc-efi rtc-efi.0: setting system clock to 2022-01-29T01:49:51 
UTC (1643420991)
[  111.080870] rtc-efi rtc-efi.0: write status is 3
[  121.938858] rtc-efi rtc-efi.0: write status is 3
[  196.022653] rtc-efi rtc-efi.0: write status is 3
[  207.315759] rtc-efi rtc-efi.0: write status is 3

ls -l /dev/rtc*

lrwxrwxrwx 1 root root  4 Jan 29 09:49 /dev/rtc -> rtc0
crw--- 1 root root 250, 0 Jan 29 09:49 /dev/rtc0

hwclokc -v

hwclock from util-linux 2.36.1
System Time: 1643440677.231191
Trying to open: /dev/rtc0
Using the rtc interface to the clock.
Last drift adjustment done at 1642812487 seconds after 1969
Last calibration done at 1642812487 seconds after 1969
Hardware clock is on UTC time
Assuming hardware clock is kept in UTC time.
Waiting for clock tick...
ioctl(4, RTC_UIE_ON, 0): Invalid argument
Waiting in loop for time from /dev/rtc0 to change
...got clock tick
Time read from Hardware Clock: 2022/01/29 07:17:46
Hw clock time : 2022/01/29 07:17:46 = 1643440666 seconds since 1969
Time since last adjustment is 628179 seconds
Calculated Hardware Clock drift is 0.00 seconds
2022-01-29 15:17:45.709485+08:00

My mini PC box hardware info also can see:

https://linux-hardware.org/?probe=fb7e1fcf47

The install report bug:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1004474

-- Package-specific info:
** Version:
Linux version 5.16.0-rc8-rt-arm64 (debian-ker...@lists.debian.org) (gcc-11 
(Debian 11.2.0-13) 11.2.0, GNU ld (GNU Binutils for Debian) 2.37) #1 SMP 
PREEMPT_RT Debian 5.16~rc8-1~exp1 (2022-01-03)

** Command line:
BOOT_IMAGE=/boot/vmlinuz-5.16.0-rc8-rt-arm64 
root=UUID=172ab927-70a2-42d4-baf5-96d8e23ecd82 ro quiet

** Not tainted

** Kernel log:
Jan 29 15:30:01 atzlinux-arm64 kernel: [0.00] Booting Linux on physical 
CPU 0x00 [0x701f6633]
Jan 29 15:30:01 atzlinux-arm64 kernel: [0.00] Linux version 
5.16.0-rc8-rt-arm64 (debian-ker...@lists.debian.org) (gcc-11 (Debian 11.2.0-13) 
11.2.0, GNU ld (GNU Binutils for Debian) 2.37) #1 SMP PREEMPT_RT Debian 
5.16~rc8-1~exp1 (2022-01-03)
Jan 29 15:30:01 atzlinux-arm64 kernel: [0.00] efi: EFI v2.70 by Phytium 
Platform
Jan 29 15:30:01 atzlinux-arm64 kernel: [0.00] efi: ACPI 2.0=0xe695 
SMBIOS=0xebfa SMBIOS 3.0=0xe679 MEMATTR=0xe9f7d018 MOKvar=0xe9f6b000 
MEMRESERVE=0xe6f80298 
Jan 29 15:30:01 atzlinux-arm64 kernel: [0.00] secureboot: Secure boot 
disabled
Jan 29 15:30:01 atzlinux-arm64 kernel: [0.00] ACPI: Early table 
checksum verification disabled
Jan 29 15:30:01 atzlinux-arm64 kernel: [0.00] ACPI: RSDP 
0xE695 24 (v02 PHYLTD)
Jan 29 15:30:01 atzlinux-arm64 kernel: [0.00] ACPI: XSDT 
0xE694 74 (v01 PHYLTD PHYTIUM. 0001  0113)
Jan 29 15:30:01 atzlinux-arm64 kernel: [0.00] ACPI: FACP 
0xE685 000114 (v06 PHYLTD PHYTIUM. 0001 PHYT 0001)
Jan 29 15:30:01 atzlinux-arm64 kernel: [0.00] ACPI: DSDT 
0xE67C 0015F3 (v02 PHYLTD PHYTIUM. 0001 INTL 20180105)
Jan 29 15:30:01 atzlinux-arm64 kernel: [0.00] ACPI: GTDT 
0xE684 98 (v02 PHYLTD PHYTIUM. 0001 PHYT 0001)
Jan 29 15:30:01 atzlinux-arm64 kernel: [0.00] ACPI: IORT 
0xE683 80 (v00 PHYLTD PHYTIUM. 0001 PHYT 0001)
Jan 29 15:30:01 atzlinux-arm64 kernel: [0.00] ACPI: APIC 
0xE682 000198 (v04 PHYLTD PHYTIUM. 0001 PHYT 0001)
Jan 29 15:30:01 atzlinux-arm64 kernel: [0.00] ACPI: MCFG 
0xE681 3C (v01 PHYLTD PHYTIUM. 0001 PHYT 0001)
Jan 29 15:30:01 atzlinux-arm64 kernel: [0.00] ACPI: PCCT 
0xE680 AC (v02 PHYLTD PHYTIUM. 0001 PHYT 0001)
Jan 29 15:30:01 atzlinux-arm64 kernel: [0.00] ACPI: PPTT 
0xE67F 000206 (v01 PHYLTD PHYTIUM. 0001 PHYT 0001)
Jan 29 15:30:01 atzlinux-arm64 kernel: [0.00] ACPI: SPCR 
0xE67E 50 (v02 PHYLTD PHYTIUM. 0001 PHYT 0001)
Jan 29 15:30:01 atzlinux-arm64 kernel: [0.00] ACPI: SSDT 
0xE67D 000476 (v02 PHYLTD PHYTIUM. 0001 INTL 20180105)
Jan 29 15:30:01 atzlinux-arm64 kernel: [0.00] ACPI: VFCT 
0xE616 00EA84 (v01 PHYLTD PHYTIUM. 0001 AMD  31504F47)
Jan 29 15:30:01 atzlinux-arm64 kernel: [0.00] ACPI: SPCR: console: 
pl011,mmio32,0x28001000,115200
Jan 29 15:30:01 atzlinux-arm64 kernel: [0.00] NUMA: Failed to 
initialise from firmware