Bug#1007905: transition: icu

[GCS]

On Sat, Mar 19, 2022 at 8:28 AM Adrian Bunk  wrote:
> On Fri, Mar 18, 2022 at 06:05:38PM +, Simon McVittie wrote:
> > Obviously all these copies of essentially the same codebase are quite
> > unfortunate, but mozjs and ICU seem to be sufficiently tightly-coupled
> > that perhaps using its vendored version of ICU, at least temporarily,
> > would be wiser than using the system copy?
>
> IMHO unblocking GNOME by temporarily making mozjs91 use its vendored
> version until the ICU transition would be a reasonable approach.
 OK.

> > On Fri, 18 Mar 2022 at 18:26:41 +0100, László Böszörményi (GCS) wrote:
> > > Speak of the devil. ICU 71.1 RC [1] just released. Final is expected
> > > in April (two-three weeks). Would you two mind if I package it and ask
> > > for testing of your packages (mozjs91 and nodejs) against it?
> >
> > Speaking only for myself, I'm flexible about timings for this; but Ubuntu
> > has already done the ICU 70.1 transition and is currently using it for
> > their next LTS release, and 2-3 weeks is probably too late for them to
> > do another transition before their freeze deadline.
 Can you elucidate why Ubuntu would be forced to do the ICU 71.1
transition for their current to be released LTS version?

> Does Ubuntu even care either way?
 I think no.

> AFAIK both now and in 2-3 weeks is inside their freeze.
 Exactly. As Matthias noted, we were in contact and helped them a bit
for doing the transition in Ubuntu. Blame me that I didn't start ICU
transition at the same time for Debian.
Now a status update in short. ICU 71.1 RC looks identical in API sense
to ICU 70.1 meaning all packages fail or build the same way with both
versions.
I've packaged ICU 71.1 RC at least and restarted the rebuilds on i386
_and_ amd64 parallel. This slowed me down, but I can report the
following. Package haskell-text-icu FTBFS, but the patch I've provided
[1] still fixes the issue. As noted, mozjs78 and 0ad FTBFS in my
pbuilder setups.
Other packages are built with ICU 70.1 and I'm at level3 with ICU 71.1
RC. Already built ceph, chromium and postgresql-14 with it on that
level. Any objection not to upload ICU 71.1 RC to experimental right
now?

Regards,
Laszlo/GCS
[1] https://bugs.debian.org/1004093

Bug#845166: Seeing similar with spaces

[Charles Curley]

I seem to see the same with ASCII spaces (0x20) in the SSID.

However I can create the connection using nmcli, and then selected it
from the GUI.

root@ideapc:~# pre network-m
network-manager 1.30.0-2amd64
network-manager-gnome   1.20.0-3amd64
root@ideapc:~# cat /etc/debian_version 
11.2
root@ideapc:~# lsb_release -a
No LSB modules are available.
Distributor ID: Debian
Description:Debian GNU/Linux 11 (bullseye)
Release:11
Codename:   bullseye
root@ideapc:~# 


-- 
Does anybody read signatures any more?

https://charlescurley.com
https://charlescurley.com/blog/

Bug#1007983: node-puppeteer: broken autopkgtest keeping chromium from migrating to testing

[Andres Salomon]

On Sat, 19 Mar 2022 17:44:02 -0400 Andres Salomon wrote:
> Source: node-puppeteer
> Control: found -1 node-puppeteer/13.1.0+dfsg-6
> Control: affects -1 chromium
> Severity: serious
> Tags: sid bookworm
>
> node-puppeteer is keeping chromium from migrating; as
> https://tracker.debian.org/pkg/chromium describes,


It looks like the tests also failed in testing with chromium v98 
(https://ci.debian.net/data/autopkgtest/testing/amd64/n/node-puppeteer/20151806/log.gz), 
which did actually allow chromium v99 to migrate to testing, so you can 
ignore that part of this bug report.

Bug#1003252: AttributeError: install_layout

[Stefano Rivera]

Control: reassign -1 python3.10
Control: fixed -1 python3.10/3.10.2-6
Control: found -1 python3.10/3.10.2-3
Control: close -1

This is resolved by the addition of _distutils_system_mod in Python
3.10.

python3.9 hasn't been fixed yet, but it'll be replaced by 3.10, soon.

SR

-- 
Stefano Rivera
  http://tumbleweed.org.za/
  +1 415 683 3272

Bug#1007724: xscreensaver: xscreensaver-auth says it should be installed setuid root

[Jamie Zawinski]

There is no debate about this. It is insecure and irresponsible for 
xscreensaver-auth to *not* be setuid root.

Install it setuid root, as it was designed to be, and as "make install" does by 
default.

Bug#959469: openssl 1.1.1n-0+deb10u1 flagged for acceptance

[Kurt Roeckx]

On Mon, Mar 21, 2022 at 12:12:11AM +0100, Sebastian Andrzej Siewior wrote:
> 
> The change in openssl is commit
>cc7c6eb8135b ("Check that the default signature type is allowed")

So that's:
commit cc7c6eb8135be665d0acc176a5963e1eaf52e4e2
Author: Kurt Roeckx 
Date:   Thu Jan 2 22:53:32 2020 +0100

Check that the default signature type is allowed

TLS < 1.2 has fixed signature algorithms: MD5+SHA1 for RSA and SHA1 for the
others. TLS 1.2 sends a list of supported ciphers, but allows not sending
it in which case SHA1 is used. TLS 1.3 makes sending the list mandatory.

When we didn't receive a list from the client, we always used the
defaults without checking that they are allowed by the configuration.

Reviewed-by: Paul Dale 
GH: #10784
(cherry picked from commit b0031e5dc2c8c99a6c04bc7625aa00d3d20a59a5)


Kurt

Bug#1008033: please make a new upload leveraging recent Poppler

[John Scott]

Source: okular
Version: 4:21.12.3-1
Severity: wishlist

Okular and the version of Poppler now in unstable both support digital
signing of PDFs, which is awesome. However, Okular checks at build time
whether Poppler provides the functions necessary for PDF signing.

It is sufficient to make a new no-change upload of Okular for it to
build against the version of Poppler currently in unstable, and hence
for it to support PDF signing automagically.

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

Kernel: Linux 5.16.0-1-amd64 (SMP w/2 CPU threads; PREEMPT)
Kernel taint flags: TAINT_USER, TAINT_WARN, TAINT_FIRMWARE_WORKAROUND
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



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

Bug#946187: ITP: starship -- any news?

[Matan Kushner]

No worries Daniele! I greatly appreciate your interest and willingness to 
contribute a Starship package.

Cheers,

Matan

Bug#959469: openssl 1.1.1n-0+deb10u1 flagged for acceptance

[Sebastian Andrzej Siewior]

On 2022-03-20 23:15:57 [+0100], Kurt Roeckx wrote:
> > https://ci.debian.net/data/autopkgtest/oldstable/amd64/g/gnutls28/20199677/log.gz
> > 
> > Checking TLS 1.0 with ECDHE-ECDSA (SECP384R1)...
> > %COMPAT: Checking TLS 1.0 with ECDHE-ECDSA (SECP384R1)...
> > *** Fatal error: A TLS fatal alert has been received.
> > Failure: Failed
> > *** Fatal error: A TLS fatal alert has been received.
> > %NO_ETM: Checking TLS 1.0 with ECDHE-ECDSA (SECP384R1)...
> > Failure: Failed
> > *** Fatal error: A TLS fatal alert has been received.
> > Failure: Failed
> > FAIL [11]../../tests/suite/testcompat-main-openssl
> > 
> > Which, according to me, is this check:
> > https://sources.debian.org/src/gnutls28/3.6.7-4%2Bdeb10u7/tests/suite/testcompat-main-openssl/#L307
> 
> That test still seems to exist, but is just moved to a different file:
> https://github.com/gnutls/gnutls/blob/master/tests/suite/testcompat-openssl-cli-common.sh#L255
> 
> My understanding is that gnutls now passes the correct list of signature
> algorithms to use to OpenSSL's s_client to be able to do that test, and
> that this is probably fixed by:
> https://github.com/gnutls/gnutls/commit/23958322865a8a77c2f924f569484e5fd150a24b
> (and 
> https://github.com/gnutls/gnutls/commit/8259a1dc8503ad760c0887eb95278f9957a00667)
> 
> I'm trying to remember what was changed and why, but I can't
> find/remember it.

The change in openssl is commit
   cc7c6eb8135b ("Check that the default signature type is allowed")

The server is
openssl s_server -quiet -www -accept 57687 -keyform pem -certform pem 
-tls1 \
 -key tests/certs/ecc384.pem -cert tests/certs/cert-ecc384.pem -Verify 
1 \
 -named_curve secp384r1 -CAfile tests/certs/ca-cert-ecc.pem

The client is
/usr/bin/gnutls-cli -p 57687 127.0.0.1 \
  --priority 
NONE:+CIPHER-ALL:+SIGN-ALL:+COMP-NULL:+MAC-ALL:+VERS-TLS1.0:+ECDHE-ECDSA:+CURVE-ALL
 \
  --insecure --x509certfile tests/certs/cert-ecc384.pem --x509keyfile 
tests/certs/ecc384.pem

Before the commit in question it connects as:
  - Description: (TLS1.0)-(ECDHE-SECP384R1)-(AES-256-CBC)-(SHA1)

after that, the server throws:
  140490373015360:error:14201044:SSL routines:tls_choose_sigalg:internal 
error:../ssl/t1_lib.c:2880:

and it appears that the security level in openssl forbids SHA1 here.
The argument on the s_server side
 -sigalgs RSA+SHA1:RSA+SHA256:DSA+SHA1:DSA+SHA256

doesn't help here but
 -cipher "ALL:@SECLEVEL=1"

does. 

> Kurt

Sebastian

Bug#1006199: xscreensaver: Does not power-off screen in normal operation, although it is working with "Blank screen now"

[Tormod Volden]

On Mon, Feb 21, 2022 at 9:03 AM Christian Britz wrote:
> Dear Maintainer,
>
> I have configured xscreensaver to use "Blank Screen Only", enabled power
> management and "Quick Power-off in Blank Only Mode".
> The display IS powered off when I issue "File -> Blank Screen Now" in
> xscreensaver-demo. However, it only goes black, when the scheduled blank time
> is reached.

Hi Christian,

It would be best if you can try version 6.02. If the issue persists,
please attach a verbose log as per the FAQ:

If the problem is reproducible, please type the following into a shell:

xscreensaver-command -exit
xscreensaver -v -log log.txt

That will re-start XScreenSaver and append diagnostics to the
"log.txt" file. When the problem happens again, attach the complete
file.

Best regards,
Tormod

Bug#1007792: nmu: fdroidcl_0.5.0-3+b3

[Jochen Sprickerhof]

Hi Sebastian,

* Sebastian Ramacher  [2022-03-19 18:08]:

Control: tags -1 moreinfo

On 2022-03-16 20:38:48 +0100, Jochen Sprickerhof wrote:

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

nmu fdroidcl_0.5.0-3+b3 . ANY . unstable . -m "rebuild with new golang version"


There is currently no golang transition ongoing. Why is this necessary?


fdroidcl was removed from testing due to being build with golang-1.15. 
I've tested it locally with the current golang version and it builds 
file, so a binnmu would be enough.


Actually I just saw that there are some minor changes in git so I could 
also upload a new version. Given that this is not the first testing 
removal, is there anything I should change in the package to fix this?


Cheers Jochen


signature.asc
Description: PGP signature

Bug#959469: openssl 1.1.1n-0+deb10u1 flagged for acceptance

[Kurt Roeckx]

On Sun, Mar 20, 2022 at 10:00:15PM +0100, Paul Gevers wrote:
> Dear Sebastian, Kurt,
> 
> On 19-03-2022 12:33, Adam D Barratt wrote:
> > Upload details
> > ==
> > 
> > Package: openssl
> > Version: 1.1.1n-0+deb10u1
> > 
> > Explanation: new upstream release
> 
> We're seeing a regression in buster in the autopkgtest of gnutls28 with the
> new version of openssl on all tested architectures. Can you please have a
> look and advise? (bullseye doesn't seem to have the test anymore, hence it
> doesn't fail).
> 
> https://ci.debian.net/data/autopkgtest/oldstable/amd64/g/gnutls28/20199677/log.gz
> 
> Checking TLS 1.0 with ECDHE-ECDSA (SECP384R1)...
> %COMPAT: Checking TLS 1.0 with ECDHE-ECDSA (SECP384R1)...
> *** Fatal error: A TLS fatal alert has been received.
> Failure: Failed
> *** Fatal error: A TLS fatal alert has been received.
> %NO_ETM: Checking TLS 1.0 with ECDHE-ECDSA (SECP384R1)...
> Failure: Failed
> *** Fatal error: A TLS fatal alert has been received.
> Failure: Failed
> FAIL [11]../../tests/suite/testcompat-main-openssl
> 
> Which, according to me, is this check:
> https://sources.debian.org/src/gnutls28/3.6.7-4%2Bdeb10u7/tests/suite/testcompat-main-openssl/#L307

That test still seems to exist, but is just moved to a different file:
https://github.com/gnutls/gnutls/blob/master/tests/suite/testcompat-openssl-cli-common.sh#L255

My understanding is that gnutls now passes the correct list of signature
algorithms to use to OpenSSL's s_client to be able to do that test, and
that this is probably fixed by:
https://github.com/gnutls/gnutls/commit/23958322865a8a77c2f924f569484e5fd150a24b
(and 
https://github.com/gnutls/gnutls/commit/8259a1dc8503ad760c0887eb95278f9957a00667)

I'm trying to remember what was changed and why, but I can't
find/remember it.


Kurt

Bug#1007724: xscreensaver: xscreensaver-auth says it should be installed setuid root

[Tormod Volden]

On Tue, Mar 15, 2022 at 6:57 PM Julian Gilbey wrote:
> euler:~ $ xscreensaver -no-splash
> xscreensaver-auth: 17:48:30: OOM: /proc/7427/oom_score_adj: Permission denied
> xscreensaver-auth: 17:48:30:   To prevent the kernel from randomly unlocking
> xscreensaver-auth: 17:48:30:   your screen via the out-of-memory killer,
> xscreensaver-auth: 17:48:30:   "xscreensaver-auth" must be setuid root.
>
> And:
>
> euler:~ $ ls -l /usr/libexec/xscreensaver/xscreensaver-auth
> -rwxr-xr-x 1 root root 308168 Jan 15 15:40 
> /usr/libexec/xscreensaver/xscreensaver-auth
>
> So perhaps this should be setuid root?

Thanks for the report. I guess this is something we'll leave to the
local administrator, to consider whether the risk of random unlocking
is worse than another setuid executable. xscreensaver is quite safe
with the recent split-out of xscreensaver-auth though.

Best regards,
Tormod

Bug#1008032: O: parprouted -- transparent IP (Layer 3) proxy ARP bridging tool

[Luciano Bello]

Package: wnpp
Severity: normal

I'm orphaning all of my packages in Debian because I have decided to
retire.

The description reads:
 transparent IP (Layer 3) proxy ARP bridging tool
 This is useful for creation of transparent firewalls and bridging
 networks with different MAC protocols. Also, unlike standard
 bridging, proxy ARP bridging allows one to bridge Ethernet networks
 behind wireless nodes without using WDS or layer 2 bridging.

Bug#1008031: bullseye-pu: package intel-microcode/3.20210608.2

[Henrique de Moraes Holschuh]

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

I'd like to update the intel-microcode package in bullseye.

The new Intel microcode release includes fixes for several critical
functional defects (errata) as well as security fixes and mitigations.
It fixes hangs and incorrect behavior on *many* processors, as well as
several CVEs.

The package changelog has a reasonable list of the issues addressed by
the update.

There are no known regressions introduced by this microcode update.

The same package is alrady in bullseye-backports, testing and unstable,
with no bug reports.

I have attached a git diff against the version currently in bullseye.

Here's the diffstat:
 b/.gitignore|1 
 b/changelog |   79 +++
 b/debian/.gitignore |5 +
 b/debian/changelog  |  103 
 b/debian/ucode-blacklist.txt|2 
 b/intel-ucode-with-caveats/06-4f-01 |binary
 b/intel-ucode/06-3f-02  |binary
 b/intel-ucode/06-3f-04  |binary
 b/intel-ucode/06-4e-03  |binary
 b/intel-ucode/06-55-03  |binary
 b/intel-ucode/06-55-04  |binary
 b/intel-ucode/06-55-06  |binary
 b/intel-ucode/06-55-07  |binary
 b/intel-ucode/06-55-0b  |binary
 b/intel-ucode/06-56-03  |binary
 b/intel-ucode/06-56-04  |binary
 b/intel-ucode/06-56-05  |binary
 b/intel-ucode/06-5c-09  |binary
 b/intel-ucode/06-5c-0a  |binary
 b/intel-ucode/06-5e-03  |binary
 b/intel-ucode/06-5f-01  |binary
 b/intel-ucode/06-6a-06  |binary
 b/intel-ucode/06-7a-01  |binary
 b/intel-ucode/06-7a-08  |binary
 b/intel-ucode/06-7e-05  |binary
 b/intel-ucode/06-8a-01  |binary
 b/intel-ucode/06-8c-01  |binary
 b/intel-ucode/06-8c-02  |binary
 b/intel-ucode/06-8d-01  |binary
 b/intel-ucode/06-8e-09  |binary
 b/intel-ucode/06-8e-0a  |binary
 b/intel-ucode/06-8e-0b  |binary
 b/intel-ucode/06-8e-0c  |binary
 b/intel-ucode/06-96-01  |binary
 b/intel-ucode/06-9c-00  |binary
 b/intel-ucode/06-9e-09  |binary
 b/intel-ucode/06-9e-0a  |binary
 b/intel-ucode/06-9e-0b  |binary
 b/intel-ucode/06-9e-0c  |binary
 b/intel-ucode/06-9e-0d  |binary
 b/intel-ucode/06-a5-02  |binary
 b/intel-ucode/06-a5-03  |binary
 b/intel-ucode/06-a5-05  |binary
 b/intel-ucode/06-a6-00  |binary
 b/intel-ucode/06-a6-01  |binary
 b/intel-ucode/06-a7-01  |binary
 b/releasenote.md|   80 +++
 48 files changed, 270 insertions(+)


PS: I apologise for sending this so close to the deadline for the next
point release.

-- 
  Henrique Holschuh
diff --git a/.gitignore b/.gitignore
index 5ead64a..0af49a5 100644
--- a/.gitignore
+++ b/.gitignore
@@ -1,3 +1,4 @@
 intel-microcode.bin
 intel-microcode-64.bin
 *.pbin
+*.dbin
diff --git a/changelog b/changelog
index 25b8ada..7dfb0b0 100644
--- a/changelog
+++ b/changelog
@@ -1,3 +1,81 @@
+2022-02-07:
+  * Relevant information:
+https://www.intel.com/content/www/us/en/developer/topic-technology/software-security-guidance/processors-affected-consolidated-product-cpu-model.html
+  * Mitigates (*only* when loaded from firmware through the FIT)
+CVE-2021-0146, INTEL-SA-00528: VT-d privilege escalation through
+debug port, on Pentium, Celeron and Atom processors with signatures
+0x506c9, 0x506ca, 0x506f1, 0x706a1, 0x706a8
+https://github.com/intel/Intel-Linux-Processor-Microcode-Data-Files/issues/57#issuecomment-1036363145
+  * Mitigates CVE-2021-0127, INTEL-SA-00532: an unexpected code breakpoint
+may cause a system hang, on many processors.
+  * Mitigates CVE-2021-0145, INTEL-SA-00561: information disclosure due
+to improper sanitization of shared resources (fast-store forward
+predictor), on many processors.
+  * Mitigates CVE-2021-33120, INTEL-SA-00589: out-of-bounds read on some
+Atom Processors may allow information disclosure or denial of service
+via network access.
+  * Fixes critical errata (functional issues) on many processors
+  * Adds a MSR switch to enable RAPL filtering (default off, once enabled
+it can only be disabled by poweroff or reboot).  Useful to protect
+SGX and other threads from side-channel info leak.  Improves the
+mitigation for CVE-2020-8694, CVE-2020-8695, INTEL-SA-00389 on many
+processors.
+  * Disables TSX in more processor models.
+  * Fixes issue with WBINDV on multi-socket (server) systems which could
+cause resets and unpredictable system behavior
+  * Adds a MSR switch 

Bug#1008030: buster-pu: package intel-microcode/3.20210608.2~deb10u1

[Henrique de Moraes Holschuh]

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

I'd like to update the intel-microcode package in buster.

The new Intel microcode release includes fixes for several critical
functional defects (errata) as well as security fixes and mitigations.
It fixes hangs and incorrect behavior on *many* processors, as well as
several CVEs.

The package changelog has a reasonable list of the issues addressed by
the update.

There are no known regressions introduced by this microcode update.

The same package is alrady in bullseye-backports, testing and unstable,
with no bug reports.

I have attached a git diff against the version currently in buster.
 b/.gitignore|1 
 b/changelog |   79 +++
 b/debian/.gitignore |5 +
 b/debian/changelog  |  103 
 b/debian/ucode-blacklist.txt|2 
 b/intel-ucode-with-caveats/06-4f-01 |binary
 b/intel-ucode/06-3f-02  |binary
 b/intel-ucode/06-3f-04  |binary
 b/intel-ucode/06-4e-03  |binary
 b/intel-ucode/06-55-03  |binary
 b/intel-ucode/06-55-04  |binary
 b/intel-ucode/06-55-06  |binary
 b/intel-ucode/06-55-07  |binary
 b/intel-ucode/06-55-0b  |binary
 b/intel-ucode/06-56-03  |binary
 b/intel-ucode/06-56-04  |binary
 b/intel-ucode/06-56-05  |binary
 b/intel-ucode/06-5c-09  |binary
 b/intel-ucode/06-5c-0a  |binary
 b/intel-ucode/06-5e-03  |binary
 b/intel-ucode/06-5f-01  |binary
 b/intel-ucode/06-6a-06  |binary
 b/intel-ucode/06-7a-01  |binary
 b/intel-ucode/06-7a-08  |binary
 b/intel-ucode/06-7e-05  |binary
 b/intel-ucode/06-8a-01  |binary
 b/intel-ucode/06-8c-01  |binary
 b/intel-ucode/06-8c-02  |binary
 b/intel-ucode/06-8d-01  |binary
 b/intel-ucode/06-8e-09  |binary
 b/intel-ucode/06-8e-0a  |binary
 b/intel-ucode/06-8e-0b  |binary
 b/intel-ucode/06-8e-0c  |binary
 b/intel-ucode/06-96-01  |binary
 b/intel-ucode/06-9c-00  |binary
 b/intel-ucode/06-9e-09  |binary
 b/intel-ucode/06-9e-0a  |binary
 b/intel-ucode/06-9e-0b  |binary
 b/intel-ucode/06-9e-0c  |binary
 b/intel-ucode/06-9e-0d  |binary
 b/intel-ucode/06-a5-02  |binary
 b/intel-ucode/06-a5-03  |binary
 b/intel-ucode/06-a5-05  |binary
 b/intel-ucode/06-a6-00  |binary
 b/intel-ucode/06-a6-01  |binary
 b/intel-ucode/06-a7-01  |binary
 b/releasenote.md|   80 +++
 48 files changed, 270 insertions(+)

PS: I apologise for sending this so close to the deadline for the next
point release.

-- 
  Henrique Holschuh
diff --git a/.gitignore b/.gitignore
index 5ead64a..0af49a5 100644
--- a/.gitignore
+++ b/.gitignore
@@ -1,3 +1,4 @@
 intel-microcode.bin
 intel-microcode-64.bin
 *.pbin
+*.dbin
diff --git a/changelog b/changelog
index 25b8ada..7dfb0b0 100644
--- a/changelog
+++ b/changelog
@@ -1,3 +1,81 @@
+2022-02-07:
+  * Relevant information:
+https://www.intel.com/content/www/us/en/developer/topic-technology/software-security-guidance/processors-affected-consolidated-product-cpu-model.html
+  * Mitigates (*only* when loaded from firmware through the FIT)
+CVE-2021-0146, INTEL-SA-00528: VT-d privilege escalation through
+debug port, on Pentium, Celeron and Atom processors with signatures
+0x506c9, 0x506ca, 0x506f1, 0x706a1, 0x706a8
+https://github.com/intel/Intel-Linux-Processor-Microcode-Data-Files/issues/57#issuecomment-1036363145
+  * Mitigates CVE-2021-0127, INTEL-SA-00532: an unexpected code breakpoint
+may cause a system hang, on many processors.
+  * Mitigates CVE-2021-0145, INTEL-SA-00561: information disclosure due
+to improper sanitization of shared resources (fast-store forward
+predictor), on many processors.
+  * Mitigates CVE-2021-33120, INTEL-SA-00589: out-of-bounds read on some
+Atom Processors may allow information disclosure or denial of service
+via network access.
+  * Fixes critical errata (functional issues) on many processors
+  * Adds a MSR switch to enable RAPL filtering (default off, once enabled
+it can only be disabled by poweroff or reboot).  Useful to protect
+SGX and other threads from side-channel info leak.  Improves the
+mitigation for CVE-2020-8694, CVE-2020-8695, INTEL-SA-00389 on many
+processors.
+  * Disables TSX in more processor models.
+  * Fixes issue with WBINDV on multi-socket (server) systems which could
+cause resets and unpredictable system behavior
+  * Adds a MSR switch to 10th and 11th-gen (Ice 

Bug#1006558:

[ryan]

Hello.  I am checking in on things.  I filed a bug report three weeks ago and 
have not heard back from anyone yet.  Thanks.

Bug#998627: linux: please enable the new NTFS3 driver in 5.15

[Ben Hutchings]

On Fri, 2022-03-18 at 20:58 +0100, lenni_na1 wrote:
> Hi,
> 
> are there any news on this?
> 
> We are now at kernel 5.16 in testing and as far as I can tell the ntfs3 
> driver still hasn't been enabled.

The recent traffic on the ntfs3 list seems to consist of bug reports
and small fixes, none of them being addressed by the supposed
maintainer of the filesystem (who last posted at the end of November).

I think that we would be doing our users a disservice by enabling ntfs3
in this state.

Ben.

-- 
Ben Hutchings
If the facts do not conform to your theory, they must be disposed of.


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

Bug#1008029: O: dirdiff -- Display and merge changes between two directory trees

[Luciano Bello]

Package: wnpp
Severity: normal

I'm orphaning all of my packages in Debian because I have decided to
retire. 

The description reads:

 Dirdiff can handle up to 5 trees.  It displays a main window with a
 list of the files which are different between the trees, with colored
 squares to indicate the relative ages of the versions.  A menu allows
 you to display the differences between any two of the versions in
 another window.  Another menu allows you to copy the file from one
 tree to another.

Bug#1008028: hydra: fails to propagate errors from sub-configure to make

[Helmut Grohne]

Source: hydra
Version: 9.3-1
Severity: serious
Justifictation: policy 4.6

When the sub-configure invocation for hydra-gtk fails, the error is
ignored and the build attempts to continue. Such behaviour is prohibited
by the Debian policy section 4.6:

| cd hydra-gtk && sh ./make_xhydra.sh
| Trying to compile xhydra now (hydra gtk gui) - don't worry if this fails, 
this is really optional ...
...
| Error: configure wasnt happy. Analyse this:
| make[1]: [Makefile:74: xhydra] Error 1 (ignored)
| 
| Now type make install
| make[1]: Leaving directory '/<>'

Note that xhydra is a non-optional component from a Debian packaging
point of view.

Helmut

Bug#959469: openssl 1.1.1n-0+deb10u1 flagged for acceptance

[Paul Gevers]

Dear Sebastian, Kurt,

On 19-03-2022 12:33, Adam D Barratt wrote:

Upload details
==

Package: openssl
Version: 1.1.1n-0+deb10u1

Explanation: new upstream release


We're seeing a regression in buster in the autopkgtest of gnutls28 with 
the new version of openssl on all tested architectures. Can you please 
have a look and advise? (bullseye doesn't seem to have the test anymore, 
hence it doesn't fail).


https://ci.debian.net/data/autopkgtest/oldstable/amd64/g/gnutls28/20199677/log.gz

Checking TLS 1.0 with ECDHE-ECDSA (SECP384R1)...
%COMPAT: Checking TLS 1.0 with ECDHE-ECDSA (SECP384R1)...
*** Fatal error: A TLS fatal alert has been received.
Failure: Failed
*** Fatal error: A TLS fatal alert has been received.
%NO_ETM: Checking TLS 1.0 with ECDHE-ECDSA (SECP384R1)...
Failure: Failed
*** Fatal error: A TLS fatal alert has been received.
Failure: Failed
FAIL [11]../../tests/suite/testcompat-main-openssl

Which, according to me, is this check:
https://sources.debian.org/src/gnutls28/3.6.7-4%2Bdeb10u7/tests/suite/testcompat-main-openssl/#L307

Paul


OpenPGP_signature
Description: OpenPGP digital signature

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

[Michael Biebl]

Am 19.03.22 um 18:04 schrieb Julien Cristau:

Control: tag -1 confirmed

On Tue, Jan 18, 2022 at 02:46:06PM +0100, Michael Biebl wrote:

   * Demote systemd-timesyncd from Depends to Recommends.
 This avoids a dependency cycle between systemd and systemd-timesyncd and
 thus makes dist upgrades more predictable and robust.
 It also allows minimal, systemd based containers where no NTP client is
 strictly necessary.
 To ensure that systemd-timesyncd is installed in a default installation
 created by d-i, bump its priority to standard.
 (Closes: #986651, #993947)

This one is probably the trickiest (and possibly also the simplest)
change. It simply breaks a dependency loop between systemd and
systemd-timesyncd resulting in a more predictable upgrade sequence which
in turn ensures that modifications of systemd-timesyncd's conffiles are
preserved on upgrades.


Difficult to predict the side effects this might have, but on the whole
it's probably better to do this than not.

Go ahead.


Uploaded. Thanks, Julien.


I've CCed the FTP team for #1003949.

Now that this change has been acked by the RT, please adjust the 
priority accordingly.


Regards,
Michael



OpenPGP_signature
Description: OpenPGP digital signature

Bug#1008027: O: mrtgutils -- Utilities to generate statistics for mrtg

[Luciano Bello]

Package: wnpp
Severity: normal

I'm orphaning all of my packages in Debian because I have decided to
retire.

MRTGutils is relative low-maintenance package, probably a good choice for a 
first-package.

The description reads:
 MRTGutils is a collection of simple utilities to generate output useful for
 mrtg. Many of the existing mrtg setups use shell or perl scripts to gather
 output. On busy systems, these scripts can generate a lot of extra load. These
 (small) C programs can return the given statistics more efficiently.
 .
 This package provides the following binaries that return:
  - mrtg-load: the current load average (5-minute average)
  - mrtg-ip-acct: the number of IP packets that have traversed an interface
  - mrtg-apache: the number of hits to a Apache web site

Bug#925879: reprotest: flaky autopkgtest: Unknown encoding 'RK1048' at /usr/bin/help2man line 56.

[Paul Gevers]

Hi,

On Tue, 06 Oct 2020 11:34:48 -0700 Vagrant Cascadian 
 wrote:

On 2019-03-27, Paul Gevers wrote:
> Since the introduction of 0.7.8 the autopkgtest of reprotest sometimes
> fails in unstable and testing, while a retry not much later succeeds.
> Because the unstable-to-testing migration software now blocks on
> regressions in testing, flaky tests, i.e. tests that flip between
> passing and failing without changes to the list of installed packages,
> are wasting peoples time. Please either fix the test to be more robust,
> or mark this particular test as "flaky".

In the short term, probably worth marking as flaky...


> I: pybuild base:217: python3.7 setup.py config
> I: pybuild base:217: /usr/bin/python3 setup.py build
> Unknown encoding 'RK1048' at /usr/bin/help2man line 56.
> I: pybuild base:217: /usr/bin/python3 setup.py install --root

This is probably triggered because reprotest randomly picks a locale to
run:

loc = random.choice(['fr_CH.UTF-8', 'es_ES', 'ru_RU.CP1251', 
'kk_KZ.RK1048', 'zh_CN'])


It might be better to adjust the test to only test specific locales,
which may require adjusting the code a bit.


Testing locales entirely randomly also results in reprotest producing
inconsisent tests when using it... so it's not surprising that it's also
inconsistent in the autopkgtests.


live well,
  vagrant


Bug #894126 (help2man bug about this) got closed (supposedly fixed) 
recently. Does that mean this issue should be fixed too?


Paul


OpenPGP_signature
Description: OpenPGP digital signature

Bug#993678: Patch fixes problem

[Daniel Leidert]

I can confirm that the patch fixes the reported issue.

Regards, Daniel

Bug#1008026: usbguard: CVE-2019-25058: unauthorized access via D-Bus

[Markus Koschany]

Package: usbguard
X-Debbugs-CC: t...@security.debian.org
Severity: grave
Tags: security

Hi,

The following vulnerability was published for usbguard.

CVE-2019-25058[0]:
| An issue was discovered in USBGuard before 1.1.0. On systems with the
| usbguard-dbus daemon running, an unprivileged user could make USBGuard
| allow all USB devices to be connected in the future.


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

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2019-25058
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-25058

Please adjust the affected versions in the BTS as needed.

Regards,

Markus


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

Bug#1005158: nvidia-graphics-drivers-tesla-450 450.172.01-2~deb11u1 flagged for acceptance

[Adam D Barratt]

package release.debian.org
tags 1005158 = bullseye pending
thanks

Hi,

The upload referenced by this bug report has been flagged for acceptance into 
the proposed-updates queue for Debian bullseye.

Thanks for your contribution!

Upload details
==

Package: nvidia-graphics-drivers-tesla-450
Version: 450.172.01-2~deb11u1

Explanation: new upstream release; fix denial of service issues [CVE-2022-21813 
CVE-2022-21814]; nvidia-kernel-support: Provide 
/etc/modprobe.d/nvidia-options.conf as a template

Bug#1008025: fwupd-efi FTCBFS: uses the build architecture compiler for efi components

[Helmut Grohne]

Source: fwupd-efi
Version: 1:1.2-3
Tags: patch
User: debian-cr...@lists.debian.org
Usertags: ftcbfs

fwupd-efi fails to cross build from source, because it uses the build
architecture compiler for building efi components. It actually has two
compiler variables and the efi-cc one is not default initialized to the
host compiler, so it happens to pick the build architecture one. Please
consider applying the attached patch to fix the cross build.

Helmut
diff --minimal -Nru fwupd-efi-1.2/debian/changelog 
fwupd-efi-1.2/debian/changelog
--- fwupd-efi-1.2/debian/changelog  2022-02-10 00:05:46.0 +0100
+++ fwupd-efi-1.2/debian/changelog  2022-03-20 10:46:47.0 +0100
@@ -1,3 +1,10 @@
+fwupd-efi (1:1.2-3.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix FTCBFS: Pass a suitable efi-cc to meson. (Closes: #-1)
+
+ -- Helmut Grohne   Sun, 20 Mar 2022 10:46:47 +0100
+
 fwupd-efi (1:1.2-3) unstable; urgency=medium
 
   [ Mario Limonciello ]
diff --minimal -Nru fwupd-efi-1.2/debian/rules fwupd-efi-1.2/debian/rules
--- fwupd-efi-1.2/debian/rules  2022-02-10 00:02:52.0 +0100
+++ fwupd-efi-1.2/debian/rules  2022-03-20 10:46:45.0 +0100
@@ -5,7 +5,9 @@
 export DEB_BUILD_MAINT_OPTIONS = hardening=+all
 export DEB_LDFLAGS_MAINT_STRIP=-Wl,-Bsymbolic-functions
 
-CONFARGS =
+-include /usr/share/dpkg/buildtools.mk
+
+CONFARGS = '-Defi-cc=$(CC)'
 
 ifneq ($(CI),)
CONFARGS += --werror --wrap-mode=default

Bug#1007267: [Pkg-javascript-devel] Bug#1007267: (no subject)

[Jonas Smedegaard]

Quoting Ayoyimika Ajibade (2022-03-20 18:51:35)
> The new update to webpack5 release 
> https://salsa.debian.org/Ayoyimika/node-webpack/-/commit/758a0d0bdb2001400d73db53c5a3ce3c73086b7a
>  
> which is basically updating how webpack5 requires node-eslint-scope 
> resolves this bugs.
> I guess i will close it then

Yes, makes good sense to simply close this bugreport.

Thanks,

 - Jonas

-- 
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/

 [x] quote me freely  [ ] ask before reusing  [ ] keep private

signature.asc
Description: signature

Bug#1008024: libpano13: CVE-2021-33293 out-of-bounds read

[Markus Koschany]

Package: libpano13
X-Debbugs-CC: t...@security.debian.org
Severity: important
Tags: security

Hi,

The following vulnerability was published for libpano13.

CVE-2021-33293[0]:
| Panorama Tools libpano13 v2.9.20 was discovered to contain an out-of-
| bounds read in the function panoParserFindOLine() in parser.c.


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

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2021-33293
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-33293

Please adjust the affected versions in the BTS as needed.

Regards,

Markus



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

Bug#1008023: ITP: node-cbor -- Node.js modules to encode and parse data in CBOR data format

[Yadd]

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

* Package name: node-cbor
  Version : 8.1.0
  Upstream Author : Joe Hildebrand 
* URL : https://github.com/hildjj/node-cbor
* License : Expat
  Programming Lang: JavaScript
  Description : Node.js modules to encode and parse data in CBOR data format

node-cbor provides binaries and libraries to encode and parse data in the
Concise Binary Object Representation (CBOR) data format (RFC8949).
It provides:
 * cbor: a node-centric CBOR processor
 * cbor-web: the "cbor" package compiled for use on the web
 * cbor-cli: a set of command-line tools for working with node-cbor
   package

This is a dependency of popular node-ava test suite which is required to
test many actual node-* packages. For now, JS Team uses some patches to
replace it by tape or jest but this doesn't permit to enable all checks.

node-cbor will be maintained under JS Team umbrella.

Bug#1005158: bullseye-pu: package nvidia-graphics-drivers-tesla-450/450.172.01-1~deb11u1

[Adam D. Barratt]

On Sun, 2022-03-20 at 17:32 +0100, Andreas Beckmann wrote:
> On 19/03/2022 17.48, Adam D. Barratt wrote:
> > Control: tags -1 + confirmed
> > 
> > On Tue, 2022-02-08 at 09:06 +0100, Andreas Beckmann wrote:
> > > I'd like to update src:nvidia-graphics-drivers-tesla-450/non-free 
> > > to
> > > a
> > > new upstream version to fix CVE‑2022‑21813, CVE‑2022‑21814.
> > > 
> > > This is a simple rebuild of the package from sid.
> > > 
> > 
> > Please go ahead.
> 
> I've uploaded a rebuild of the latest version from sid (-2 instead
> of 
> -1), which contains a few additional changes, please see the
> attached 
> incremental debdiff from 450.172.01-1 to 450.172.01-2~deb11u1
> 

Just to confirm, this and nvidia-modprobe - as the only packages from
the set so far uploaded AFAICS - are OK to be included in 11.3 without
needing the remainder of the updates?

Regards,

Adam

Bug#1007267: (no subject)

[Ayoyimika Ajibade]

The new update to webpack5 release 
https://salsa.debian.org/Ayoyimika/node-webpack/-/commit/758a0d0bdb2001400d73db53c5a3ce3c73086b7a 
which is basically updating how webpack5 requires node-eslint-scope 
resolves this bugs.

I guess i will close it then


OpenPGP_0x1FF1115A4CAC464D.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital signature

Bug#946187: ITP: starship -- any news?

[Daniele Tricoli]

Hello Matan,
thanks for the ping. I'm really sorry that well starship is not in
Debian yet.

On Sun, Jan 16, 2022 at 05:53:59PM +0300, Matan Kushner wrote:
> I'm the lead maintainer of Starship and would love to see a package be made.
> I don't know a whole lot about the process of creating Debian packages, but 
> if there's any way I could help move this along, please let me know!

I set my personal ETA to 30 days from now to have it uploaded. Feel free
to ping me again.

Cheers,

-- 
  Daniele Tricoli 'eriol'
  https://mornie.org

Bug#1002912: graphicsmagick 1.4+really1.3.35-1~deb10u2 flagged for acceptance

[Adam D Barratt]

package release.debian.org
tags 1002912 = buster pending
thanks

Hi,

The upload referenced by this bug report has been flagged for acceptance into 
the proposed-updates queue for Debian buster.

Thanks for your contribution!

Upload details
==

Package: graphicsmagick
Version: 1.4+really1.3.35-1~deb10u2

Explanation: fix buffer overflow issue [CVE-2020-12672]

Bug#1008022: keepass2: CVE-2022-0725 information disclosure

[Markus Koschany]

Package: keepass2
X-Debbugs-CC: t...@security.debian.org
Severity: important
Tags: security

Hi,

The following vulnerability was published for keepass2.

CVE-2022-0725[0]:
| A flaw was found in KeePass. The vulnerability occurs due to logging
| the plain text passwords in the system log and leads to an Information
| Exposure vulnerability. This flaw allows an attacker to interact and
| read sensitive passwords and logs.


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

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2022-0725
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-0725

Please adjust the affected versions in the BTS as needed.

Steps to reproduce the problem (according
to https://bugzilla.redhat.com/show_bug.cgi?id=2052696)


Step 1: Run "journalctl -f" in a terminal window.
Step 2: Double click a password in KeePass.
Step 3: Wait for the clear timeout to trigger.

Actual results:
See your plain text password logged in the terminal window

Expected results:
Never see your plain text password logged anywhere


Only users in the systemd-journal group can use journalctl. At the moment I
can't reproduce the problem on a custom XFCE system but I have not tried GNOME
or other desktop environments yet and I suspect this problem is not limited to
RedHat or Fedora.


Regards,

Markus



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

Bug#1008021: bind9: unused build-dependency on libldap2-dev

[Ryan Tandy]

Source: bind9
Version: 1:9.18.1-1
Severity: minor

Dear Maintainer,

I think bind9's build-dependency on libldap2-dev is unused.

As far as I can tell, it was added to support the dlz-ldap module:

https://salsa.debian.org/dns-team/bind9/-/commit/dcc91657062f34b22cceaceaac176e3d445770e9#58ef006ab62b83b4bec5d81fe5b32c3b4c2d1cc2

However, building the dlz modules seems to be disabled since 2011:

https://salsa.debian.org/dns-team/bind9/-/commit/6c6fcc660cb7be94857f42979bbae5558c7a4486

The current binary packages have no dependency on libldap, and I didn't 
find the word "ldap" in their contents, except for the apparmor profile 
and some documentation.

The package builds successfully with libldap2-dev dropped. The build is 
not reproducible (for other reasons) so I couldn't easily check whether 
the results were identical.

thanks,
Ryan

Bug#1006953: fonts-creep2: Font does not install correctly, so does not show up in GUI font lists

[Agathe Porte]

Control: tag -1 -moreinfo
Control: severity -1 grave

19/03/2022 23:31, David Calman :


I tried xfce4-terminal. It has the same font-selection dialogue as
Konsole, and it too cannot see creep. Both can see Atari and Misaki,
but not creep. I have PCF fonts disabled in `fontconfig-config`
because the bitmap Helvetica is pretty dire.


I can reproduce. Looks like my prototype package "fonts-creep" is 
working, but "fonts-creep2" is not although the TTF file is installed. 
This is also happening in "gnome-terminal".


I do not see any possible solution. Maybe I should upload "fonts-creep" 
and drop this package.


Bests,

Agathe.

Bug#1008020: precious: build-depends on obsolete package.

[Peter Michael Green]

Package: precious
Version: 0.1.3-2
Severity: serious

The upstream of  the rust which crate dropped the optional dependency on
the rust failure crate. As a result of this the rust-which source 
package no longer

builds a librust-which+failure-dev package.

The librust-which+failure-dev binary package is still present in 
unstable as a

cruft package, but is uninstallable. It is completely gone from testing.

After updating the build-dependency to librust-which+default-dev
(reflecting the fact that your Cargo.toml depends on the which crate
with default features enabled), I was able to build the package succesfully.
I have not tested it though.

Bug#1007717: Native source package format with non-native version

[Matthew Vernon]

On 17/03/2022 17:52, Russ Allbery wrote:

Helmut Grohne  writes:


Do you think it would be impossible to move forward on this matter in a
consensus-based way?


I don't know.  I have some reasons to be dubious, but it's possible that
I'm being excessively pessimistic.


I'm inclined to agree with Russ here; my impression is there are one or 
two long-standing areas of disagreement here, and that consensus hasn't 
been arrived at.



In the spirit of consensus: Do you agree that retrying this in a
consensus-based way is still possible?


If the relevant people required to implement a decision are willing to
tackle it that way, I am certainly willing to participate from the Policy
side.


For the avoidance of doubt, if that is the case, I am not going to 
suggest the TC gets in the way!


Regards,

Matthew

Bug#1005158: bullseye-pu: package nvidia-graphics-drivers-tesla-450/450.172.01-1~deb11u1

[Andreas Beckmann]

On 19/03/2022 17.48, Adam D. Barratt wrote:

Control: tags -1 + confirmed

On Tue, 2022-02-08 at 09:06 +0100, Andreas Beckmann wrote:

I'd like to update src:nvidia-graphics-drivers-tesla-450/non-free to
a
new upstream version to fix CVE‑2022‑21813, CVE‑2022‑21814.

This is a simple rebuild of the package from sid.



Please go ahead.


I've uploaded a rebuild of the latest version from sid (-2 instead of 
-1), which contains a few additional changes, please see the attached 
incremental debdiff from 450.172.01-1 to 450.172.01-2~deb11u1


The new autopkgtest (for testing buildability of the kernel module) 
currently is a (passing) no-op, it requires additional changes to dkms 
and autodep8 s.t. kernel headers get installed and the kernel module 
gets compiled.



Andreas
diff --git a/debian/README.source b/debian/README.source
index 03853038..d48a6fcf 100644
--- a/debian/README.source
+++ b/debian/README.source
@@ -13,6 +13,28 @@ Building "bleeding edge" from GIT for users
 uploaded in the archive.
 
 
+Upstream support timeframes
+
+https://nvidia.custhelp.com/app/answers/detail/a_id/3142
+https://docs.nvidia.com/datacenter/tesla/drivers/
+https://web.archive.org/web/20210522000916/https://docs.nvidia.com/datacenter/tesla/drivers/
+
+Driver Series   Supported until
+71  EoL
+96  EoL
+173 EoL
+304 12/2017 EoL
+340 12/2019 EoL
+390 12/2022
+Tesla 410   EoL
+Tesla 418 (LTSB)03/2022
+Tesla 440   11/2020 EoL
+Tesla 450 (LTSB)07/2023
+Tesla 460 (PB)  01/2022 EoL
+Tesla 470 (LTSB)07/2024
+Tesla 510 (PB)  01/2023
+
+
 The branch structure in the GIT repository
 
 The following branches exist in the git repository:
@@ -39,9 +61,16 @@ The branch structure in the GIT repository
 450   (bullseye)  460, 450-tesla
 450-tesla (bullseye)  460-tesla, tesla-450/master
 tesla-450/master  bullseye,sidtesla-460/master
-460   (bullseye)  master, 460-tesla
-460-tesla (bullseye)  tesla-460/master
-tesla-460/master  bullseye,sid
+460 EoL   (bullseye)  470, 460-tesla
+460-tesla   EoL   (bullseye)  470-tesla, tesla-460/master
+tesla-460/masterEoL   (bullseye),(sid)tesla-470/master, tesla-460/transition-470
+tesla-460/transition-470  bullseye,sid
+470   (bullseye)  510, 470-tesla
+470-tesla (bullseye)  510-tesla, tesla-470/master
+tesla-470/master  bullseye,sidtesla-510/master
+510   (bookworm)  master, 510-tesla
+510-tesla (bookworm)  tesla-510/master
+tesla-510/master  bookworm,sid
 mastersid YYY
 YYY   experimentalZZZ, (master)
 ZZZ   experimental(master)
diff --git a/debian/changelog b/debian/changelog
index 10c0a787..7a864cf1 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,21 @@
+nvidia-graphics-drivers-tesla-450 (450.172.01-2~deb11u1) bullseye; urgency=medium
+
+  * Rebuild for bullseye.
+
+ -- Andreas Beckmann   Sun, 20 Mar 2022 16:53:36 +0100
+
+nvidia-graphics-drivers-tesla-450 (450.172.01-2) unstable; urgency=medium
+
+  * Add xorg-video-abi-25 (Xorg Xserver 21) as alternative dependency.
+(Closes: #1005932)
+  * Backport pde_data changes from 470.103.01 to fix kernel module build for
+Linux 5.17.
+  * dkms.conf: Use a BUILD_EXCLUSIVE equivalent hack to skip building for -rt
+kernels, not supported upstream (510.54-1).
+  * Declare Testsuite: autopkgtest-pkg-dkms (510.54-1).
+
+ -- Andreas Beckmann   Mon, 28 Feb 2022 21:03:12 +0100
+
 nvidia-graphics-drivers-tesla-450 (450.172.01-1) unstable; urgency=medium
 
   * New upstream Tesla release 450.172.01 (2022-01-31).
@@ -919,6 +937,19 @@ nvidia-graphics-drivers (430.14-1) experimental; urgency=medium
 
  -- Andreas Beckmann   Sat, 25 May 2019 13:49:09 +0200
 
+nvidia-graphics-drivers-tesla-418 (418.226.00-2) unstable; urgency=medium
+
+  * Backport stdarg.h and stddef.h changes from 495.44 to fix kernel module
+build for Linux 5.16.
+  * Backport pde_data changes from 470.103.01 to fix kernel module build for
+Linux 5.17.  (Closes: #1005405)
+  * nvidia-tesla-418-kernel-support: Provide
+/etc/modprobe.d/nvidia-options.conf as a template taking into account the
+module renaming. This is a slave alternative of the nvidia alternative
+(470.86-1).  (Closes: #999670)
+
+ -- Andreas Beckmann   Fri, 25 Feb 2022 13:48:18 +0100
+
 nvidia-graphics-drivers-tesla-418 (418.226.00-1) unstable; urgency=medium
 
   * New upstream Tesla 

Bug#1003491: winetricks: Please allow co-installation with wine-staging

[Jens Reyer]

On 20.03.22 17:16, Jens Reyer wrote:
>   export WINE=/opt/wine-staging/bin/wineserver
>   export WINESERVER=/opt/wine-staging/bin/wineserver

That should have been:

  export WINE=/opt/wine-staging/bin/wine
  export WINESERVER=/opt/wine-staging/bin/wineserver

Bug#1007992: libigdgmm12: new version causes segfaults

[Sebastian Ramacher]

On 2022-03-20 07:07:46 +0100, Paul Menzel wrote:
> Control: forward -1 https://github.com/intel/gmmlib/issues/95
> 
> Dear Debian folks,
> 
> 
> Am 20.03.22 um 04:35 schrieb Christoph Anton Mitterer:
> 
> […]
> 
> > This version breaks e.g. video playback with mpv (also vlc):
> > $ mpv test.mp4
> >   (+) Video --vid=1 (h264 720x300 23.976fps)
> >   (+) Audio --aid=1 (aac 2ch 44100Hz)
> > Segmentation fault
> 
> I am only able to reproduce this with VA-API enabled, that means, when I
> pass `--hwdec=vaapi` to mpv. Firefox with VA-API enabled crashes too, but
> not when it’s disabled. Do you have VA-API enabled for mpv?

Considering that this code is only used for VA-API drivers for Intel
GPUs, that's not surprising.

vlc tries to auto-detect the best playback method (unless configuered to
use a specific one). It tries both VA-API and VDPAU and picks the best
match.

Cheers

> 
> […]
> 
> I installed *libigdgmm12-dbgsym*, and created the issue #95 *[regression]
> Terminates with segfault in InitializeGmm/InitContext* upstream [1].
> 
> Hopefully, they analyze and fix it quickly. No idea, if it’s possible to
> revert to an earlier version in Debian sid/unstable until that is fixed.
> 
> 
> Kind regards,
> 
> Paul
> 
> 
> [1]: https://github.com/intel/gmmlib/issues/95
> 

-- 
Sebastian Ramacher


signature.asc
Description: PGP signature

Bug#1007992: libigdgmm12: new version causes segfaults

[Christoph Anton Mitterer]

On Sun, 2022-03-20 at 07:07 +0100, Paul Menzel wrote:
> Firefox with VA-API enabled crashes too,
> but not when it’s disabled.


> Do you have VA-API enabled for mpv?
I do have:
hwdec=auto

in mpv.conf, which I think would use vaapi here.

However, I have nothing specifically set for VLC.


Thanks,
Chris.

Bug#1008019: RFS: lebiniou/3.66.0-1 -- user-friendly, powerful music visualization / VJing tool

[Olivier Girondel]

Package: sponsorship-requests
Severity: normal

Dear mentors,

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

  * Package name: lebiniou
Version : 3.66.0-1
Upstream Author : Olivier Girondel 
  * URL : https://biniou.net
  * License : GPL-2+
Section : graphics

It builds this binary package:

   lebiniou - user-friendly, powerful music visualization / VJing tool

The package appears to be lintian-clean.

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

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

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

   dget -x
https://mentors.debian.net/debian/pool/main/l/lebiniou/lebiniou_3.66.0-1.dsc

Changes since the last upload:

  * New upstream release 3.66.0.

Regards,

--
Olivier Girondel

Bug#1008018: RFS: lebiniou-data/3.66.0-1 -- datafiles for Le Biniou

[Olivier Girondel]

Package: sponsorship-requests
Severity: normal

Dear mentors,

I am looking for a sponsor for my package "lebiniou-data":

  * Package name: lebiniou-data
Version : 3.66.0-1
Upstream Author : Olivier Girondel 
  * URL : https://biniou.net
  * License : GPL-2+
Section : graphics

It builds this binary package:

 lebiniou-data - datafiles for Le Biniou

The package appears to be lintian-clean.

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

   https://mentors.debian.net/package/lebiniou-data

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

   dget -x
https://mentors.debian.net/debian/pool/main/l/lebiniou-data/lebiniou-data_3.66.0-1.dsc

Changes since the last upload:

  * New upstream release 3.66.0.
  * debian/copyright: Updated.

Regards,

--
Olivier Girondel

Bug#1008017: audiofile: CVE-2022-24599

[Salvatore Bonaccorso]

Source: audiofile
Version: 0.3.6-5
Severity: important
Tags: security upstream
Forwarded: https://github.com/mpruett/audiofile/issues/60
X-Debbugs-Cc: car...@debian.org, Debian Security Team 

Hi,

The following vulnerability was published for audiofile.

CVE-2022-24599[0]:
| In autofile Audio File Library 0.3.6, there exists one memory leak
| vulnerability in printfileinfo, in printinfo.c, which allows an
| attacker to leak sensitive information via a crafted file. The
| printfileinfo function calls the copyrightstring function to get data,
| however, it dosn't use zero bytes to truncate the data.


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

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2022-24599
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-24599
[1] https://github.com/mpruett/audiofile/issues/60

Regards,
Salvatore

Bug#1008016: ITP: safe-network -- network routing and service daemon for the Safe Network

[Jonas Smedegaard]

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

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

* Package name: safe-network
  Version : 0.46.5
  Upstream Author : MaidSafe.net limited
* URL : https://primer.safenetwork.org/
* License : GPL-3 with linking exception
  Programming Lang: Rust
  Description : network routing and service daemon for the Safe Network

 This package provides the Safe Network Core.
 API message definitions, routing and nodes, client core api.
 .
 The Safe Network is a fully autonomous
 data and communications network.

This package will be maintained in the collaborative Debian area of
Salsa: https://salsa.debian.org/debian/safe-network

-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEn+Ppw2aRpp/1PMaELHwxRsGgASEFAmI3RUUACgkQLHwxRsGg
ASGFjA//bn08OIqXF5QNbCwVacLdNLGd59+g8s+hkWp4TrjDWAOXeI6MupjiM6Bj
r10WrApsn3vmsXPTqMYiQypIqWhUNEstHwesZ+mLMhmLC8Jn10eszZDTkehnAAfA
lUta14bOzWGRdRCBzj9OlU3Wn6jJOKyAxkIoJ3ictc1WjpRrrr6qwejbrIqt7Lk8
JCd/jQWDcEvTSC0B702G7FMJZJRNV3cRWJDyS98ikYjDkjKukkldtmlCTsdIppC/
GgX90zdn5OgniU1VCUKx5aMu1gaD0hPk7ITdwXM/ethzl5JWlMFUzNKC36tWNI/S
21Q7mLOaxRa8R0jsEaZIcLknz7JDk0J/xdiYqx8kOh6K/MXX4JFCxV68qoy7PCqM
Zmhdp2VOpiWxuD4RakHWeaozc5p7xjjxb4Qkw25sWG61LFXo/ad8vXEnoycgt90v
cv8zlBSfc/0oQnsTBOg6sOTfECWYS3HehBN63MT/w1m37AA4j0pjt3SGFL0jbqOf
uXJ89ip5v2M42mraDL9iu+Pgsidmrt5Mv17ywJkOENmv6S3IapeGKDu+IOHR+zgF
bIsYjPDIQwhqqgiaWY8zFTHiMF9CR0lzF0CFNs0Cp6BtwE3i6uyuJqnwzpZ/pSEN
MDFUDVXmhcWq+blRlyUn2/ocx/C4WIf3+B7w3cARlVgJZa/vJnU=
=bJS4
-END PGP SIGNATURE-

Bug#1007977: [Android-tools-devel] Bug#1007977: android-platform-system-core: builds adb which is also built (at a higher version) by android-platform-tools

[Hans-Christoph Steiner]

Right, this is an ongoing, incomplete migration.  Anything that is built in 
android-platform-tools should be removed from android-platform-system-core or 
any other android-platform-* packages.  We welcome contributions there!

Bug#1008015: openvpn: CVE-2022-0547: authentication bypass in external authentication plug-ins

[Markus Koschany]

Package: openvpn
X-Debbugs-CC: t...@security.debian.org
Severity: grave
Tags: security

Hi,

The following vulnerability was published for openvpn.

CVE-2022-0547[0]:
| OpenVPN 2.1 until v2.4.12 and v2.5.6 may enable authentication bypass
| in external authentication plug-ins when more than one of them makes
| use of deferred authentication replies, which allows an external user
| to be granted access with only partially correct credentials.


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

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2022-0547
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-0547

Please adjust the affected versions in the BTS as needed.

Regards,

Markus



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

Bug#1008014: python3-blinker: DeprecationWarning with Python 3.10: invalid escape sequence '\*'

[Julian Gilbey]

Package: python3-blinker
Version: 1.4+dfsg1-0.4
Severity: normal
Tags: upstream

I am getting the following warning:

../../../../../../../../../../usr/lib/python3/dist-packages/blinker/base.py:93
  /usr/lib/python3/dist-packages/blinker/base.py:93: DeprecationWarning: 
invalid escape sequence '\*'
"""Connect *receiver* to signal events sent by *sender*.

and two other similar ones.

Upstream have fixed this (https://github.com/jek/blinker, commit
https://github.com/jek/blinker/commit/194e17a20008bd778714182ac191ad654074f81c
on 28 Oct 2020) but have not officially released a new version of the
package.

Perhaps you could either cherry-pick this fix, or upload the current
GitHub version of the package?

Best wishes,

   Julian

Bug#1008013: waitress: CVE-2022-24761

[Salvatore Bonaccorso]

Source: waitress
Version: 1.4.4-1.1
Severity: important
Tags: security upstream
X-Debbugs-Cc: car...@debian.org, Debian Security Team 

Hi,

The following vulnerability was published for waitress.

CVE-2022-24761[0]:
| Waitress is a Web Server Gateway Interface server for Python 2 and 3.
| When using Waitress versions 2.1.0 and prior behind a proxy that does
| not properly validate the incoming HTTP request matches the RFC7230
| standard, Waitress and the frontend proxy may disagree on where one
| request starts and where it ends. This would allow requests to be
| smuggled via the front-end proxy to waitress and later behavior. There
| are two classes of vulnerability that may lead to request smuggling
| that are addressed by this advisory: The use of Python's `int()` to
| parse strings into integers, leading to `+10` to be parsed as `10`, or
| `0x01` to be parsed as `1`, where as the standard specifies that the
| string should contain only digits or hex digits; and Waitress does not
| support chunk extensions, however it was discarding them without
| validating that they did not contain illegal characters. This
| vulnerability has been patched in Waitress 2.1.1. A workaround is
| available. When deploying a proxy in front of waitress, turning on any
| and all functionality to make sure that the request matches the
| RFC7230 standard. Certain proxy servers may not have this
| functionality though and users are encouraged to upgrade to the latest
| version of waitress instead.


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

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2022-24761
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-24761
[1] https://github.com/Pylons/waitress/security/advisories/GHSA-4f7p-27jc-3c36
[2] 
https://github.com/Pylons/waitress/commit/9e0b8c801e4d505c2ffc91b891af4ba48af715e0

Please adjust the affected versions in the BTS as needed.

Regards,
Salvatore

Bug#1008012: paramiko: CVE-2022-24302

[Salvatore Bonaccorso]

Source: paramiko
Version: 2.8.1-1
Severity: important
Tags: security upstream
X-Debbugs-Cc: car...@debian.org, Debian Security Team 

Hi,

The following vulnerability was published for paramiko.

CVE-2022-24302[0]:
| In Paramiko before 2.10.1, a race condition (between creation and
| chmod) in the write_private_key_file function could allow unauthorized
| information disclosure.


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

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2022-24302
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-24302
[1] 
https://github.com/paramiko/paramiko/commit/4c491e299c9b800358b16fa4886d8d94f45abe2e

Please adjust the affected versions in the BTS as needed.

Regards,
Salvatore

Bug#1008011: httpie: CVE-2022-24737

[Salvatore Bonaccorso]

Source: httpie
Version: 2.6.0-1.1
Severity: important
Tags: security upstream
X-Debbugs-Cc: car...@debian.org, Debian Security Team 

Hi,

The following vulnerability was published for httpie.

CVE-2022-24737[0]:
| HTTPie is a command-line HTTP client. HTTPie has the practical concept
| of sessions, which help users to persistently store some of the state
| that belongs to the outgoing requests and incoming responses on the
| disk for further usage. Before 3.1.0, HTTPie didn#8216;t
| distinguish between cookies and hosts they belonged. This behavior
| resulted in the exposure of some cookies when there are redirects
| originating from the actual host to a third party website. Users are
| advised to upgrade. There are no known workarounds.


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

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2022-24737
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-24737
[1] https://github.com/httpie/httpie/security/advisories/GHSA-9w4w-cpc8-h2fq
[2] 
https://github.com/httpie/httpie/commit/65ab7d5caaaf2f95e61f9dd65441801c2ddee38b

Please adjust the affected versions in the BTS as needed.

Regards,
Salvatore

Bug#1008010: frr: CVE-2022-26125 CVE-2022-26126 CVE-2022-26127 CVE-2022-26128 CVE-2022-26129

[Salvatore Bonaccorso]

Source: frr
Version: 8.1-1
Severity: important
Tags: security upstream
X-Debbugs-Cc: car...@debian.org, Debian Security Team 

Hi,

The following vulnerabilities were published for frr.

CVE-2022-26125[0]:
| Buffer overflow vulnerabilities exist in FRRouting through 8.1.0 due
| to wrong checks on the input packet length in isisd/isis_tlvs.c.


CVE-2022-26126[1]:
| Buffer overflow vulnerabilities exist in FRRouting through 8.1.0 due
| to the use of strdup with a non-zero-terminated binary string in
| isis_nb_notifications.c.


CVE-2022-26127[2]:
| A buffer overflow vulnerability exists in FRRouting through 8.1.0 due
| to missing a check on the input packet length in the
| babel_packet_examin function in babeld/message.c.


CVE-2022-26128[3]:
| A buffer overflow vulnerability exists in FRRouting through 8.1.0 due
| to a wrong check on the input packet length in the babel_packet_examin
| function in babeld/message.c.


CVE-2022-26129[4]:
| Buffer overflow vulnerabilities exist in FRRouting through 8.1.0 due
| to wrong checks on the subtlv length in the functions,
| parse_hello_subtlv, parse_ihu_subtlv, and parse_update_subtlv in
| babeld/message.c.


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-2022-26125
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-26125
[1] https://security-tracker.debian.org/tracker/CVE-2022-26126
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-26126
[2] https://security-tracker.debian.org/tracker/CVE-2022-26127
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-26127
[3] https://security-tracker.debian.org/tracker/CVE-2022-26128
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-26128
[4] https://security-tracker.debian.org/tracker/CVE-2022-26129
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-26129

Please adjust the affected versions in the BTS as needed.

Regards,
Salvatore

Bug#1008009: liblouis: CVE-2022-26981

[Salvatore Bonaccorso]

Source: liblouis
Version: 3.21.0-1
Severity: important
Tags: security upstream
Forwarded: https://github.com/liblouis/liblouis/issues/1171
X-Debbugs-Cc: car...@debian.org, Debian Security Team 

Hi,

The following vulnerability was published for liblouis.

CVE-2022-26981[0]:
| Liblouis through 3.21.0 has a buffer overflow in compilePassOpcode in
| compileTranslationTable.c (called, indirectly, by
| tools/lou_checktable.c).


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

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2022-26981
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-26981
[1] https://github.com/liblouis/liblouis/issues/1171

Please adjust the affected versions in the BTS as needed.

Regards,
Salvatore

Bug#1008008: CVE-2022-21698: denial of service in client_golang

[Markus Koschany]

Package: golang-github-prometheus-client-golang
X-Debbugs-CC: t...@security.debian.org
Severity: important
Tags: security

Hi,

The following vulnerability was published for golang-github-prometheus-client-
golang.

CVE-2022-21698[0]:
| client_golang is the instrumentation library for Go applications in
| Prometheus, and the promhttp package in client_golang provides tooling
| around HTTP servers and clients. In client_golang prior to version
| 1.11.1, HTTP server is susceptible to a Denial of Service through
| unbounded cardinality, and potential memory exhaustion, when handling
| requests with non-standard HTTP methods. In order to be affected, an
| instrumented software must use any of `promhttp.InstrumentHandler*`
| middleware except `RequestsInFlight`; not filter any specific methods
| (e.g GET) before middleware; pass metric with `method` label name to
| our middleware; and not have any firewall/LB/proxy that filters away
| requests with unknown `method`. client_golang version 1.11.1 contains
| a patch for this issue. Several workarounds are available, including
| removing the `method` label name from counter/gauge used in the
| InstrumentHandler; turning off affected promhttp handlers; adding
| custom middleware before promhttp handler that will sanitize the
| request method given by Go http.Request; and using a reverse proxy or
| web application firewall, configured to only allow a limited set of
| methods.


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

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2022-21698
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-21698

Please adjust the affected versions in the BTS as needed.

Regards,

Markus



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

Bug#983803: ITA: simple-revision-control -- single-file and single-user revision control system

[Daichi Fukui]

Hi

I intend to adopt simple-revision-control -- single-file and single-user
revision control system.

I am looking for an opportunity to contribute to Debian through packaging.
If you don't mind, let me adopt this package.

Regards,
Fukui

On Mon, 1 Mar 2021 23:37:47 +0200 Adrian Bunk  wrote:
> Package: wnpp
> Severity: normal
>
> The current maintainer of simple-revision-control has retired.
Therefore, I orphan this package now.
>
> Maintaining a package requires time and skills. Please only adopt this
> package if you will have enough time and attention to work on it.
>
> If you want to be the new maintainer, please see
> http://www.debian.org/devel/wnpp/index.html#howto-o
> for detailed instructions how to adopt a package properly.
>
> More information about this package:
>
> http://tracker.debian.org/pkg/simple-revision-control
>
>
> Package: simple-revision-control
> Binary: simple-revision-control
> Version: 1.26-2
> Maintainer: Dmitry Bogatov 
> Build-Depends: asciidoc, debhelper-compat (= 11), docbook-xml,
docbook-xsl, xsltproc
> Architecture: all
> Standards-Version: 4.3.0
> Format: 3.0 (quilt)
> Files:
>  de78a6112a426b73588f7fff51ee8193 2044 simple-revision-control_1.26-2.dsc
>  565b556139f8385aad342174badfef12 56482
simple-revision-control_1.26.orig.tar.gz
>  08bd3dbeec365ecbcecc595c8950eee3 2764
simple-revision-control_1.26-2.debian.tar.xz
> Vcs-Browser: https://salsa.debian.org/debian/simple-revision-control
> Vcs-Git: https://salsa.debian.org/debian/simple-revision-control.git
> Checksums-Sha256:
>  92ee43c54e6994a2eb06aac0d917a9d11c28068b2950c25ed74b617640ab86b6 2044
simple-revision-control_1.26-2.dsc
>  435c457f9f577d84ae1fd763e2bd3548d84f84c50cd2c88f664fba259cd5d71a 56482
simple-revision-control_1.26.orig.tar.gz
>  3358e36461ed89a3e5951261cc4c25e83751c0ed09d6291f9f509b3e2d156660 2764
simple-revision-control_1.26-2.debian.tar.xz
> Homepage: https://gitlab.com/esr/src
> Package-List:
>  simple-revision-control deb vcs optional arch=all
> Directory: pool/main/s/simple-revision-control
> Priority: extra
> Section: misc
>
> Package: simple-revision-control
> Version: 1.26-2
> Installed-Size: 146
> Maintainer: Dmitry Bogatov 
> Architecture: all
> Depends: python3, rcs
> Suggests: sccs
> Description-en: single-file and single-user revision control system
>  This package provides a powerful modern user interface for an RCS
>  (and to some extend, SCCS) backend. It will be familiar to users
>  with modern Subversion, Git, Hg experience, as well as a
>  reasonable introduction to this toolset to novices.
>  .
>  SRC is designed to provide its strength for single-file, single-user
>  version tracking. When it is overkill to make a whole directory and
>  multi-file repository store (under, for example, Git or Hg), src can
>  provide tracking for individual files instead.  Examples of such might
>  be your ~/bin scripts, /etc files, personal notes, résumés, and any such

Bug#1008007: O: ieee-data -- OUI and IAB listings

[Luciano Bello]

Package: wnpp
Severity: normal

I'm orphaning all of my packages in Debian because I have decided to
retire.

ieee-data is relative low-maintaince and has a high popcon count.

The description reads:

 Provide the Organizationally Unique Identifier (OUI) and Individual Address
 Block (IAB) listings of identifiers assigned by IEEE Standards Association.

Bug#1008006: dde-qt5integration: FTBFS: Unknown module(s) in QT: dtkgui5.5 dtkwidget5.5

[Dmitry Shachnev]

Source: dde-qt5integration
Version: 5.5.8-1
Severity: serious
Tags: ftbfs

Dear Maintainer,

dde-qt5integration fails to build from source in a clean sid chroot:

  Project ERROR: Unknown module(s) in QT: dtkgui5.5 dtkwidget5.5
  make[2]: *** [Makefile:47: sub-chameleon-make_first] Error 3
  make[2]: Leaving directory '/build/dde-qt5integration-5.5.8/styleplugins'

The full build log is attached.

--
Dmitry Shachnev
I: pbuilder: network access will be disabled during build
I: Current time: Sun Mar 20 17:03:02 MSK 2022
I: pbuilder-time-stamp: 1647784982
I: Building the build Environment
I: extracting base tarball [/home/dmitry/pbuilder/sid-base.tgz]
I: copying local configuration
W: --override-config is not set; not updating apt.conf Read the manpage 
for details.
I: mounting /proc filesystem
I: mounting /sys filesystem
I: creating /{dev,run}/shm
I: mounting /dev/pts filesystem
I: redirecting /dev/ptmx to /dev/pts/ptmx
I: policy-rc.d already exists
I: Obtaining the cached apt archive contents
I: Copying source file
I: copying [dde-qt5integration_5.5.8-1.dsc]
I: copying [./dde-qt5integration_5.5.8.orig.tar.gz]
I: copying [./dde-qt5integration_5.5.8-1.debian.tar.xz]
I: Extracting source
gpgv: unknown type of key resource 'trustedkeys.kbx'
gpgv: keyblock resource '/tmp/dpkg-verify-sig.dxFptRaa/trustedkeys.kbx': 
General error
gpgv: Signature made Wed Nov 10 01:28:36 2021 UTC
gpgv:using RSA key 7E7729476D87D6F11D91ACCBC293E7B461825ACE
gpgv: Can't check signature: No public key
dpkg-source: warning: cannot verify signature ./dde-qt5integration_5.5.8-1.dsc
dpkg-source: info: extracting dde-qt5integration in dde-qt5integration-5.5.8
dpkg-source: info: unpacking dde-qt5integration_5.5.8.orig.tar.gz
dpkg-source: info: unpacking dde-qt5integration_5.5.8-1.debian.tar.xz
dpkg-source: info: using patch list from debian/patches/series
dpkg-source: info: applying 0001-disable-googletest-for-now.patch
I: Not using root during the build.
I: Installing the build-deps
 -> Attempting to satisfy build-dependencies
 -> Creating pbuilder-satisfydepends-dummy package
Package: pbuilder-satisfydepends-dummy
Version: 0.invalid.0
Architecture: amd64
Maintainer: Debian Pbuilder Team 
Description: Dummy package to satisfy dependencies with aptitude - created by 
pbuilder
 This package was created automatically by pbuilder to satisfy the
 build-dependencies of the package being currently built.
Depends: debhelper-compat (= 13), libdtkgui-dev (>= 5.5.17~), libdtkwidget-dev 
(>= 5.5.17~), libegl1-mesa-dev, libfontconfig1-dev, libfreetype6-dev, 
libglib2.0-dev, libmtdev-dev, libqt5svg5-dev, libqt5x11extras5-dev, 
libqt5xdg-dev, libqt5xdgiconloader-dev (>= 3.2.0~), libxrender-dev, pkg-config, 
qt5-qmake, qtbase5-dev, qtbase5-private-dev
dpkg-deb: building package 'pbuilder-satisfydepends-dummy' in 
'/tmp/satisfydepends-aptitude/pbuilder-satisfydepends-dummy.deb'.
Selecting previously unselected package pbuilder-satisfydepends-dummy.
(Reading database ... 13644 files and directories currently installed.)
Preparing to unpack .../pbuilder-satisfydepends-dummy.deb ...
Unpacking pbuilder-satisfydepends-dummy (0.invalid.0) ...
dpkg: pbuilder-satisfydepends-dummy: dependency problems, but configuring 
anyway as you requested:
 pbuilder-satisfydepends-dummy depends on debhelper-compat (= 13); however:
  Package debhelper-compat is not installed.
 pbuilder-satisfydepends-dummy depends on libdtkgui-dev (>= 5.5.17~); however:
  Package libdtkgui-dev is not installed.
 pbuilder-satisfydepends-dummy depends on libdtkwidget-dev (>= 5.5.17~); 
however:
  Package libdtkwidget-dev is not installed.
 pbuilder-satisfydepends-dummy depends on libegl1-mesa-dev; however:
  Package libegl1-mesa-dev is not installed.
 pbuilder-satisfydepends-dummy depends on libfontconfig1-dev; however:
  Package libfontconfig1-dev is not installed.
 pbuilder-satisfydepends-dummy depends on libfreetype6-dev; however:
  Package libfreetype6-dev is not installed.
 pbuilder-satisfydepends-dummy depends on libglib2.0-dev; however:
  Package libglib2.0-dev is not installed.
 pbuilder-satisfydepends-dummy depends on libmtdev-dev; however:
  Package libmtdev-dev is not installed.
 pbuilder-satisfydepends-dummy depends on libqt5svg5-dev; however:
  Package libqt5svg5-dev is not installed.
 pbuilder-satisfydepends-dummy depends on libqt5x11extras5-dev; however:
  Package libqt5x11extras5-dev is not installed.
 pbuilder-satisfydepends-dummy depends on libqt5xdg-dev; however:
  Package libqt5xdg-dev is not installed.
 pbuilder-satisfydepends-dummy depends on libqt5xdgiconloader-dev (>= 3.2.0~); 
however:
  Package libqt5xdgiconloader-dev is not installed.
 pbuilder-satisfydepends-dummy depends on libxrender-dev; however:
  Package libxrender-dev is not installed.
 pbuilder-satisfydepends-dummy depends on 

Bug#1008005: php-imagick: Recommends removed package: ttf-dejavu-core

[Paul Gevers]

Package: php-imagick
Version: 3.4.4+php8.0+3.4.4-2+deb11u2
Severity: serious

Dear maintainer,

Due to a recent change in autopkgtest, I noticed that your packages
recommend a package that's not available in stable, testing and
unstable. ttf-dejavu-core was a transitional package in buster, please
update your recommends to fonts-dejavu-core.

Currently your autopkgtests are broken because "needs-recommends" now
fails if Recommends can't be installed (as it always should have done).

Paul

Bug#1006966: gajim: Gajim won't start due to gajim.c.storage.cache error

[Stefan Kropp]

Control: tags -1 + moreinfo

Upstream also says there ist something weird with the cache file.

Bug#1008004: build error with firefox

[Jeffrin Thalakkottoor]

Package: firefox
Version: 98.0-2

I came across build error while building firefox.
i will paste here a terminal clipping...
---
make[5]: Leaving directory
'/home/jeffrin/build/firefox-98.0/build-browser/dom/base'
make[4]: Leaving directory '/home/jeffrin/build/firefox-98.0/build-browser'
make[3]: *** [/home/jeffrin/build/firefox-98.0/config/recurse.mk:34:
compile] Error 2
make[3]: Leaving directory '/home/jeffrin/build/firefox-98.0/build-browser'
make[2]: *** [/home/jeffrin/build/firefox-98.0/config/rules.mk:352:
default] Error 2
make[2]: Leaving directory '/home/jeffrin/build/firefox-98.0/build-browser'
dh_auto_build: error: cd build-browser && make -j2
LD_LIBS=-Wl,--no-gc-sections _LEAKTEST_FILES=leaktest.py returned exit
code 2
make[1]: *** [debian/rules:245: stamps/build-browser] Error 255
make[1]: Leaving directory '/home/jeffrin/build/firefox-98.0'
make: *** [debian/rules:340: build] Error 2
dpkg-buildpackage: error: debian/rules build subprocess returned exit status 2

---


OS: Debian GNU/Linux  bookworm/sid
Kernel: 5.16.0-5-amd64

-- 
software engineer
rajagiri school of engineering and technology - autonomous

Bug#1008003: jansson: New upstream release (2.14, 2021 Sep 9), not detected by debian/watch

[Florian Ernst]

On Sun, Mar 20, 2022 at 01:56:10PM +0100, Florian Ernst wrote:
> The attached diff to debian/watch allows uscan to detect this version.

Yeah, right, a classic. So, now attached.

Cheers,
Flo
diff -Nru jansson-2.13.1/debian/watch jansson-2.13.1/debian/watch
--- jansson-2.13.1/debian/watch 2021-02-04 22:45:00.0 +0100
+++ jansson-2.13.1/debian/watch 2022-03-20 13:40:58.0 +0100
@@ -1,2 +1,4 @@
-version=3
-https://www.digip.org/jansson/releases/jansson-([\d+\.]*).tar.gz
+version=4
+opts="filenamemangle=s%(?:.*?)?v?(\d[\d.]*)\.tar\.gz%@PACKAGE@-$1.tar.gz%" \
+https://github.com/akheron/@PACKAGE@/tags \
+(?:.*?/)?v?(\d[\d.]*)\.tar\.gz


signature.asc
Description: PGP signature

Bug#1008003: jansson: New upstream release (2.14, 2021 Sep 9), not detected by debian/watch

[Florian Ernst]

Source: jansson
Version: 2.13.1-1.1
Severity: wishlist

Dear maintainer,

there is a new upstream release available, cf.
.

(For reference, the Homepage  now
redirects to .)

The attached diff to debian/watch allows uscan to detect this version.

The actual upstream differences contain some interesting items, cf.
, and of
these

looks like it would help with
 and/or .

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

Cheers,
Flo


signature.asc
Description: PGP signature

Bug#1007947: phpliteadmin 1.9.8.2-1+deb11u1 flagged for acceptance

[Adam D Barratt]

package release.debian.org
tags 1007947 = bullseye pending
thanks

Hi,

The upload referenced by this bug report has been flagged for acceptance into 
the proposed-updates queue for Debian bullseye.

Thanks for your contribution!

Upload details
==

Package: phpliteadmin
Version: 1.9.8.2-1+deb11u1

Explanation: fix cross-site scripting issue [CVE-2021-46709]

Bug#1005148: nvidia-modprobe 470.103.01-1~deb11u1 flagged for acceptance

[Adam D Barratt]

package release.debian.org
tags 1005148 = bullseye pending
thanks

Hi,

The upload referenced by this bug report has been flagged for acceptance into 
the proposed-updates queue for Debian bullseye.

Thanks for your contribution!

Upload details
==

Package: nvidia-modprobe
Version: 470.103.01-1~deb11u1

Explanation: new upstream release

Bug#1008002: installation-reports: wifi hardware not available, otherwise fine

[Uwe Kleine-König]

Package: installation-reports
Severity: normal
X-Debbugs-Cc: u...@kleine-koenig.org

Boot method: SD card
Image version: firmware-11.2.0-amd64-i386-netinst
Date: 2022-03-20

Machine: Apple MacBook Air

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

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

Comments/Problems:

Hello,

the builtin wifi hardware (broadcom) wasn't autodetected. I didn't look
into it yet, doesn't work out-of-the-box in the installed system either.

After the installation noticed there is no network device available, I
plugged in an usb wifi dongle. I couldn't make this work, but when I
restarted the installation with the wifi dongle plugged in from the
start it worked fine.

I didn't record the error messages, but if you want to investigate I can
reproduce and provide some logging contents.

Best regards
Uwe

-- Package-specific info:

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

==
Installer hardware-summary:
==
uname -a: Linux autonoe 5.10.0-10-amd64 #1 SMP Debian 5.10.84-1 (2021-12-08) 
x86_64 GNU/Linux
lspci -knn: 00:00.0 Host bridge [0600]: Intel Corporation Haswell-ULT DRAM 
Controller [8086:0a04] (rev 09)
lspci -knn: Subsystem: Apple Inc. Device [106b:011b]
lspci -knn: 00:02.0 VGA compatible controller [0300]: Intel Corporation 
Haswell-ULT Integrated Graphics Controller [8086:0a26] (rev 09)
lspci -knn: Subsystem: Apple Inc. Device [106b:011b]
lspci -knn: 00:03.0 Audio device [0403]: Intel Corporation Haswell-ULT HD Audio 
Controller [8086:0a0c] (rev 09)
lspci -knn: Subsystem: Apple Inc. Device [106b:011b]
lspci -knn: 00:14.0 USB controller [0c03]: Intel Corporation 8 Series USB xHCI 
HC [8086:9c31] (rev 04)
lspci -knn: Subsystem: Intel Corporation Apple MacBookAir6,2 / 
MacBookPro11,1 [8086:7270]
lspci -knn: Kernel driver in use: xhci_hcd
lspci -knn: Kernel modules: xhci_pci
lspci -knn: 00:15.0 DMA controller [0801]: Intel Corporation 8 Series Low Power 
Sub-System DMA [8086:9c60] (rev 04)
lspci -knn: 00:15.4 Serial bus controller [0c80]: Intel Corporation 8 Series 
SPI Controller #1 [8086:9c66] (rev 04)
lspci -knn: 00:16.0 Communication controller [0780]: Intel Corporation 8 Series 
HECI #0 [8086:9c3a] (rev 04)
lspci -knn: Subsystem: Intel Corporation Device [8086:7270]
lspci -knn: 00:1b.0 Audio device [0403]: Intel Corporation 8 Series HD Audio 
Controller [8086:9c20] (rev 04)
lspci -knn: Subsystem: Intel Corporation Device [8086:7270]
lspci -knn: 00:1c.0 PCI bridge [0604]: Intel Corporation 8 Series PCI Express 
Root Port 1 [8086:9c10] (rev e4)
lspci -knn: Kernel driver in use: pcieport
lspci -knn: 00:1c.2 PCI bridge [0604]: Intel Corporation 8 Series PCI Express 
Root Port 3 [8086:9c14] (rev e4)
lspci -knn: Kernel driver in use: pcieport
lspci -knn: 00:1c.4 PCI bridge [0604]: Intel Corporation 8 Series PCI Express 
Root Port 5 [8086:9c18] (rev e4)
lspci -knn: Kernel driver in use: pcieport
lspci -knn: 00:1c.5 PCI bridge [0604]: Intel Corporation 8 Series PCI Express 
Root Port 6 [8086:9c1a] (rev e4)
lspci -knn: Kernel driver in use: pcieport
lspci -knn: 00:1f.0 ISA bridge [0601]: Intel Corporation 8 Series LPC 
Controller [8086:9c43] (rev 04)
lspci -knn: Subsystem: Intel Corporation Device [8086:7270]
lspci -knn: 00:1f.3 SMBus [0c05]: Intel Corporation 8 Series SMBus Controller 
[8086:9c22] (rev 04)
lspci -knn: Subsystem: Intel Corporation Device [8086:7270]
lspci -knn: 02:00.0 Network controller [0280]: Broadcom Inc. and subsidiaries 
BCM4360 802.11ac Wireless Network Adapter [14e4:43a0] (rev 03)
lspci -knn: Subsystem: Apple Inc. Device [106b:0117]
lspci -knn: Kernel driver in use: bcma-pci-bridge
lspci -knn: Kernel modules: bcma
lspci -knn: 03:00.0 SATA controller [0106]: Marvell Technology Group Ltd. 
88SS9183 PCIe SSD Controller [1b4b:9183] (rev 14)
lspci -knn: Subsystem: Marvell Technology Group Ltd. 88SS9183 PCIe SSD 
Controller [1b4b:9183]
lspci -knn: Kernel driver in use: ahci
lspci -knn: Kernel modules: ahci
lspci -knn: 04:00.0 PCI bridge [0604]: Intel Corporation DSL3510 Thunderbolt 
Controller [Cactus Ridge 4C 2012] [8086:1547] (rev 03)
lspci -knn: Kernel driver in use: pcieport
lspci -knn: 05:00.0 PCI bridge [0604]: Intel Corporation DSL3510 Thunderbolt 
Controller [Cactus Ridge 4C 2012] 

Bug#1008001: O: davfs2 -- mount a WebDAV resource as a regular file system

[Luciano Bello]

Package: wnpp
Severity: normal

I'm orphaning all of my packages in Debian because I have decided to
retire.

Davfs2 is a relative popular package that has a very responsive upstream team.

The description reads:

 Web Distributed Authoring and Versioning (WebDAV), an extension to the
 HTTP-protocol, allows authoring of resources on a remote
 web server. davfs2 provides the ability to access such resources like
 a typical filesystem, allowing for use by standard applications with no
 built-in support for WebDAV.
 .
 davfs2 is designed to fully integrate into the filesystem semantics of
 Unix-like systems (mount, umount, et c.). davfs2 makes
 mounting by unprivileged users as easy and secure as possible.
 .
 davfs2 does extensive caching to make the file system responsive,
 to avoid unnecessary network traffic and to prevent data loss, and to cope
 for slow or unreliable connections.
 .
 davfs2 will work with most WebDAV servers needing little or no configuration.

Bug#1007948: phpliteadmin 1.9.7.1-2+deb10u1 flagged for acceptance

[Adam D Barratt]

package release.debian.org
tags 1007948 = buster pending
thanks

Hi,

The upload referenced by this bug report has been flagged for acceptance into 
the proposed-updates queue for Debian buster.

Thanks for your contribution!

Upload details
==

Package: phpliteadmin
Version: 1.9.7.1-2+deb10u1

Explanation: fix cross-site scripting issue [CVE-2021-46709]

Bug#1008000: rtl-433: CVE-2022-25050 CVE-2022-25051

[Salvatore Bonaccorso]

Source: rtl-433
Version: 21.12-1
Severity: important
Tags: security upstream
Forwarded: https://github.com/merbanan/rtl_433/issues/1960
X-Debbugs-Cc: car...@debian.org, Debian Security Team 

Hi,

The following vulnerabilities were published for rtl-433.

CVE-2022-25050[0]:
| rtl_433 21.12 was discovered to contain a stack overflow in the
| function somfy_iohc_decode(). This vulnerability allows attackers to
| cause a Denial of Service (DoS) via a crafted file.


CVE-2022-25051[1]:
| An Off-by-one Error occurs in cmr113_decode of rtl_433 21.12 when
| decoding a crafted file.


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-2022-25050
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-25050
[1] https://security-tracker.debian.org/tracker/CVE-2022-25051
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-25051
[2] https://github.com/merbanan/rtl_433/issues/1960
[3] 
https://github.com/merbanan/rtl_433/commit/2dad7b9fc67a1d0bfbe520fbd821678b8f8cc7a8

Please adjust the affected versions in the BTS as needed.

Regards,
Salvatore

Bug#1007999: debian-keyring: New release?

[Bastian Germann]

Package: debian-keyring
Version: 2021.12.24

There are tags in debian-keyring's git repo for 2022.01.25 and 2022.02.24 
releases.
They were never uploaded. Is there any problem? Please think about releasing a 
new version.

Bug#1007998: release-notes: netcat-openbsd incompatibilities

[Guilhem Moulin]

Package: release-notes
Severity: wishlist

Hi there,

netcat-openbsd 1.218-5 adds support for abstract sockets (on Linux),
which is a breaking change with possible security implications:
https://sources.debian.org/src/netcat-openbsd/1.218-5/debian/NEWS/ .
elbrus suggested to mention that in the Bookworm release notes; I
propose the following text, mostly straight from the NEWS entry — feel free to
adjust of course :-)

--8<->8--

netcat-openbsd and abstract socket support
==

Starting with netcat-openbsd 1.218-5, nc.openbsd(1)'s Linux builds support
[abstract namespace 
sockets](https://manpages.debian.org/unix.7.en.html#Abstract_sockets)
in the AF_UNIX family.  Socket paths starting with an at symbol '@' are
interpreted in the abstract namespace.

This has possible security implications: `nc -lU @foobar.sock` used to bind
pathname socket '@foobar.sock' in the current directory, subject to umask and
file system access restrictions, while (on Linux) it now binds 'foobar.sock'
in the abstract namespace where ownership and permissions have *no meaning*.

In order to specify a pathname socket make sure the argument doesn't start
with '@'; for instance by prefixing with './' or by using a fully-qualified
socket path.  (Note however that on Linux socket pathnames may not exceed 108
bytes in size.)

This change is a Linux-only behavior, and only affects UNIX domain sockets
(flag '-U').

--8<->8--

Cheers
-- 
Guilhem.


signature.asc
Description: PGP signature

Bug#1007970: ITP: cloudflare-ddns -- dynamically update a DNS record using Cloudflare

[Stephan Lachnit]

Hi Andrea,

This sounds really cool and useful to have in Debian!

Do you need a sponsor? If so, I would be willing to sponsor it.

Regards,
Stephan

On Sat, Mar 19, 2022 at 8:09 PM Andrea Pappacoda  wrote:
>
> Package: wnpp
> Severity: wishlist
> Owner: Andrea Pappacoda 
> X-Debbugs-Cc: debian-de...@lists.debian.org
>
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
>
> * Package name: cloudflare-ddns
>   Version : 1.0.0
>   Upstream Author : Andrea Pappacoda 
> * URL : https://github.com/Tachi107/cloudflare-ddns
> * License : AGPL-3.0-or-later OR LGPL-3.0-or-later
>   Programming Lang: C++
>   Description : dynamically update a DNS record using Cloudflare
>
> This is a little program that is really useful when you want to host something
> but your ISP only provides you a dynamic IP address. It uses Cloudflare's API
> to update a given DNS record when needed. It is a simple script, so to run it
> periodically you can configure a cron job or a systemd timer (provided
> upstream).
>
> It is written in C++, performs a low number of memory allocations, and is
> really lightweight, making it a valid choice for constrained environments.
>
> It also provides a C API, so that third party programs can embed its
> functionalities.
>
> The library portion of the project is licensed under the LGPL 3, while
> everything else is under the AGPL 3.
>
> I couldn't find any alternative in the Debian archive, and while there are 
> some
> other open source alternatives out there they are mostly written in more
> resource-intensive languages and/or are harder to deploy for simple use cases.
> And also because I'm the one who wrote this :D
>
>
> -BEGIN PGP SIGNATURE-
>
> iIoEARYIADIWIQSlw/BqXszDGx3GlQz/yQfijUdG7QUCYjYplRQcYW5kcmVhQHBh
> cHBhY29kYS5pdAAKCRD/yQfijUdG7T7cAQCTCY67bva7wnXpVjKrixLVsWeOy/cU
> orsLD1f6BauB8wD/Rbs4w72xiM46pcQLMBkd0YivhGs9hshRqKk64eTqUwg=
> =3xxd
> -END PGP SIGNATURE-
>

Bug#1007198: ITP: librist -- Reliable Internet Stream Transport for reliable transmission of video over lossy networks

[Florian Ernst]

tags 1007198 pending
thanks

On Sun, Mar 13, 2022 at 02:15:20PM +0100, Florian Ernst wrote:
> * Package name: librist
>   Version : v0.2.6
>   Upstream Author : VideoLAN and librist authors
> * URL : https://code.videolan.org/rist/librist
> * License : BSD 2-Clause "Simplified"
>   Programming Lang: C (+ asm)
>   Description : Reliable Internet Stream Transport for reliable 
> transmission of video over lossy networks
> [...]
> FFmpeg as present in Bookworm or newer already allows building against
> librist, hence a heads-up to the Debian Multimedia Maintainers. I will
> send a patch for evaluating librist linking once the package hits the
> archives.

FWIW, I was able to build FFmpeg against my local librist package using
the attached patch, the relevant part of the debdiff indicating success:

| Control files of package libavformat-extra58: lines which differ (wdiff 
format)
| 
---
| Depends: libavcodec58 (= [-7:4.4.1-3),-] {+7:4.4.1-3.1),+} libavutil56 (= 
[-7:4.4.1-3),-] {+7:4.4.1-3.1),+} libbluray2 (>= 1:0.2.2), libbz2-1.0, libc6 
(>= 2.33), libchromaprint1 (>= 1.3.2), libgme0 (>= 0.5.5), libgnutls30 (>= 
3.7.2), libopenmpt0 (>= 0.3.0), librabbitmq4 (>= 0.6.0), {+librist4 (>= 
0.2.6+dfsg),+} libsmbclient (>= 2:4.0.3+dfsg1), libsrt1.4-gnutls (>= 1.4.4), 
libssh-gcrypt-4 (>= 0.8.0), libxml2 (>= 2.7.4), libzmq5 (>= 4.0.1+dfsg), zlib1g 
(>= 1:1.2.0.2)
| Installed-Size: [-2741-] {+2749+}
| Provides: libavformat58 (= [-7:4.4.1-3)-] {+7:4.4.1-3.1)+}
| Version: [-7:4.4.1-3-] {+7:4.4.1-3.1+}
| [...]
| Control files of package libavformat58: lines which differ (wdiff format)
| -
| Depends: libavcodec58 (= [-7:4.4.1-3),-] {+7:4.4.1-3.1),+} libavutil56 (= 
[-7:4.4.1-3),-] {+7:4.4.1-3.1),+} libbluray2 (>= 1:0.2.2), libbz2-1.0, libc6 
(>= 2.33), libchromaprint1 (>= 1.3.2), libgme0 (>= 0.5.5), libgnutls30 (>= 
3.7.2), libopenmpt0 (>= 0.3.0), librabbitmq4 (>= 0.6.0), {+librist4 (>= 
0.2.6+dfsg),+} libsrt1.4-gnutls (>= 1.4.4), libssh-gcrypt-4 (>= 0.8.0), libxml2 
(>= 2.7.4), libzmq5 (>= 4.0.1+dfsg), zlib1g (>= 1:1.2.0.2)
| Version: [-7:4.4.1-3-] {+7:4.4.1-3.1+}

I will recheck that patch once librist hits the archive and then file a
corresponding wishlist but against FFmpeg for librist inclusion.

My packaging has just been uploaded to NEW, the current packaging can be
found at .

Cheers,
Flo
diff -Nru ffmpeg-4.4.1/debian/control ffmpeg-4.4.1/debian/control
--- ffmpeg-4.4.1/debian/control 2022-01-15 16:31:36.0 +0100
+++ ffmpeg-4.4.1/debian/control 2022-03-19 09:49:07.0 +0100
@@ -109,6 +109,8 @@
  libpulse-dev,
 # --enable-librabbitmq
  librabbitmq-dev,
+# --enable-librist
+ librist-dev,
 # --enable-librubberband
  librubberband-dev,
 # --enable-librsvg
diff -Nru ffmpeg-4.4.1/debian/rules ffmpeg-4.4.1/debian/rules
--- ffmpeg-4.4.1/debian/rules   2021-11-21 18:30:36.0 +0100
+++ ffmpeg-4.4.1/debian/rules   2022-03-19 09:49:07.0 +0100
@@ -52,6 +52,7 @@
--enable-libopus \
--enable-libpulse \
--enable-librabbitmq \
+   --enable-librist \
--enable-librubberband \
--enable-libshine \
--enable-libsnappy \


signature.asc
Description: PGP signature

Bug#1007997: librust-xml-rs-dev: wrong package section utils (should be rust)

[Jonas Smedegaard]

Package: librust-xml-rs-dev
Version: 0.8.3-1
Severity: minor

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Binary package librust-xml-rs-dev is in package section utils but
contain only Rust source code.

Please instead place it in package section rust.

 - Jonas

-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEn+Ppw2aRpp/1PMaELHwxRsGgASEFAmI2/YoACgkQLHwxRsGg
ASHtHw/8CZ/+IwOOrzhdHt1zKKh4UzVCi9Q1LDY6FhCOlS48n8E5w5XInoPinOw0
CFu6scGuax9E5rp0H9R6kHzZHpGsab8Owy4OCSJ+UfCtBiH3zCV6gfot+zOzOBj8
cPbjl1tQxnwqHZWuKXRcXEvS9+KQeBp3SjuXkVWJDEXS88yZV+SQGSVbGhxqthIy
qWaVwXrP2ClsPnXCPtJrT77RLWQNYXLzTGXqK6F5c/VL/5DdsrcHo1IrkprBWZMJ
In7RlstwPj5hJA7UQKEFsRr9zIcyNIUwTmBiGoN5NpiHhuQ0ZvYlIiNiFV6gEOU3
LsCauAF567oqFuAIo4DIHcwob4gR+J61L14ZWLi+34EcNdu3fC6XQa+n3t8Hv6M+
jBxBFdip/+dgPvJrORtI8WX0Zit3EcW6iSt76cl0d2UquFGQJA1pvbyl/ZxTeXA7
ry2AQ4M0erfmfGo4LqVIIlsrP8A3bN8Jni6BgSooTyD5XJ3QucZlCynoHZWu8YjS
VCjbU3HJhavPyXwVKh8i98aKHspMZuuMJjkm4zaIrsP9UijJT4q3MkR9diV63XSN
I7eDfCJsteuMbz7f/kCvqP7Ygnr0gt5UNhOdRkWjS8MvKUL5tdGaau5ebLn2Y1qO
grZTCEE4LztwjkpkYuvnR0NOIhVMT+HJFxVmAl9jjZ0OKmH0/Yc=
=YU8D
-END PGP SIGNATURE-

Bug#1007996: mkdocs-material: Please update to a recent upstream version

[Carsten Schoenert]

Package: mkdocs-material
Version: 8.1.3-1
Severity: wishlist

Dear Maintainer,

while working further on packaging of NetBox I noticed that NetBox has
bumped the depending version on mkdoc-material to 8.2.5 which is the
most recent upstream version while writing this bug repoprt.

Please consider to update the mkdocs-material packagage in Debian,
thanks!

Regards
Carsten

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

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

Versions of packages mkdocs-material depends on:
ii  mkdocs1.2.3-1
ii  python3   3.9.8-1
ii  python3-jinja23.0.3-1
ii  python3-markdown  3.3.6-1
ii  python3-pygments  2.11.2+dfsg-2
ii  python3-pymdownx  9.1-1

mkdocs-material recommends no packages.

mkdocs-material suggests no packages.

-- no debconf information

Bug#1007982: ITP: popsicle -- A Linux utility for flashing multiple USB devices in parallel

[Geert Stappers]

On Sat, Mar 19, 2022 at 09:42:53PM +, Matthias Geiger wrote:
> * Package name    : popsicle
> * URL : https://github.com/pop-os/popsicle
>    Programming Lang: Rust
>    Description : Popsicle is a Linux utility for flashing multiple USB
>  devices in parallel
> 
> A small program for creating bootable USB drives. I believe this would be a
> nice addition, especially for newcomers to linux.

I believe it will be also a nice addition
for those who have to deal with writing many USB devices.



Part of the Cargo.toml:
| [dependencies]
| anyhow = "1.0"
| as-result = "0.2"
| async-std = "1"
| derive-new = "0.5"
| futures = "0.3"
| futures_codec = "0.4"
| libc = "0.2"
| memchr = "2.2"
| mnt = "0.3"
| ron = "0.6"
| serde = "1.0"
| srmw = "0.1"
| thiserror = "1"
| usb-disk-probe = "0.1"


> I'd package it but I'd need a sponsor.

Work together with Debian Rust people.


Groeten
Geert Stappers
DD, subscribed to debian-r...@lists.debian.org
-- 
Silence is hard to parse

Bug#1007989: virt-manager: Error launching create dialog

[Erik de Castro Lopo]

Erik de Castro Lopo wrote:

> Package: virt-manager
> Version: 1:4.0.0-1
> Severity: important
> 
> Dear Maintainer,
> 
> When I run virt-manager and try to create a new VM I get a dialog box saying:
> 
> Error launching create dialog:
> programming error: Did not find widget name = disk-detect-zeros


After restart libvirt it was all fine. This can be closed. Thanks!

Erik
-- 
--
Erik de Castro Lopo
http://www.mega-nerd.com/

Bug#1007843: FTBFS with nodejs experimental/14.19.0

[Yadd]

Control: severity -1 serious

Upgrading severity to allow nodejs 14 migration.

Question: is this package useful ? No reverse dependencies in Debian, no 
new version for 2 years even if there are 116 open bugs, low and 
decreasing weekly downloads [https://www.npmjs.com/package/opencv],...

Bug#1007995: RM: node-zipfile -- ROM; Useless, abandonned upstream, incompatible with node 14

[Yadd]

Package: ftp.debian.org
Severity: normal
X-Debbugs-Cc: pkg-javascript-de...@alioth-lists.debian.net

Hi,

node-zipfile has no more reverse dependencies. It was already
incompatible with nodejs 12. I fixed that and pushed result [1]. Two
years later, nothing happened.

Now node-zipfile blocks another nodejs update (version 14). I think it
should be removed from Debian.

Cheers,
Yadd

[1]: https://github.com/mapbox/node-zipfile/pull/84

Bug#934025: chromium: can't access mic ( no audio input ), works fine in firefox

[Andres Salomon]

Hi,

Can you tell me if this issue is resolved with the latest chromium (v99) 
or not?


Thanks,

Andres


On Tue, 06 Aug 2019 01:08:00 -0700 Ximin Luo wrote:

> Package: chromium
> Version: 76.0.3809.87-2+b1
> Severity: important
>
> Dear Maintainer,
>
> Chromium can't access the microphone, the result is the same from 
multiple websites

> (meet.jit.si, appear.in, google meet, etc)
>
> When visiting 
https://webrtc.github.io/samples/src/content/getusermedia/volume/

> the console says:
>
> navigator.MediaDevices.getUserMedia error: Requested device not found 
NotFoundError

>
> Note that this bug is separate from #923028, I do not see any console 
messages about
> "not allowed to start", the audio device(s) themselves are invisible 
to chromium.

>
> I have looked in the following files:
>
> /etc/chromium/master_preferences
> /usr/share/chromium/master_preferences
> ~/.config/chromium/Default/Preferences
>
> and there is no key "audio_capture_enabled" anywhere. So the issue 
seems distinct

> from #885155 #884887 #889067 as well.
>
> X
>
>
> -- System Information:
> Debian Release: bullseye/sid
> APT prefers testing
> APT policy: (990, 'testing'), (500, 'stable'), (300, 'unstable'), 
(200, 'experimental')

> Architecture: amd64 (x86_64)
> Foreign Architectures: i386
>
> Kernel: Linux 4.19.0-5-amd64 (SMP w/8 CPU cores)
> Locale: LANG=en_GB.utf8, LC_CTYPE=en_GB.utf8 (charmap=UTF-8), 
LANGUAGE=en_GB:en (charmap=UTF-8)

> Shell: /bin/sh linked to /bin/dash
> Init: systemd (via /run/systemd/system)
> LSM: AppArmor: enabled
>
> Versions of packages chromium depends on:
> ii chromium-common 76.0.3809.87-2+b1
> ii libasound2 1.1.8-1
> ii libatk-bridge2.0-0 2.30.0-5
> ii libatk1.0-0 2.30.0-2
> ii libatomic1 9.1.0-10
> ii libatspi2.0-0 2.30.0-7
> ii libavcodec58 7:4.1.4-1
> ii libavformat58 7:4.1.4-1
> ii libavutil56 7:4.1.4-1
> ii libc6 2.28-10
> ii libcairo-gobject2 1.16.0-4
> ii libcairo2 1.16.0-4
> ii libcups2 2.2.10-6
> ii libdbus-1-3 1.12.16-1
> ii libdrm2 2.4.97-1
> ii libevent-2.1-6 2.1.8-stable-4
> ii libexpat1 2.2.7-1

Bug#1007199: ipxe: fails to boot on Geode LX

[Martin-Éric Racine]

On Sun, Mar 20, 2022 at 8:42 AM Martin-Éric Racine
 wrote:
>
> On Sat, Mar 19, 2022 at 1:59 AM Bernhard Übelacker
>  wrote:
> > I tried to reproduce the issue with the help of a qemu VM.
> >
> > That way I found /usr/lib/ipxe/ipxe.lkrn working with specifying
> > a pentium2 CPU, but hangs with a pentium.
> >
> > Similarly I found the version 1.0.0+git-20150424.a25a16d-1
> > does not show this issue, but all newer than this.
> >
> > And found in [1] a hint that building without
> > TIVOLI_VMM_WORKAROUND gives a Debian package that works too.
> > And indeed, attaching a debugger to the VM shows it hanging
> > always executing an fxsave and iret instruction, PF flag set,
> > while TIVOLI_VMM_WORKAROUND would also enable a fxsave instruction.
> >
> > Therefore at least either using the older package version
> > or rebuilding locally with above modification
> > might serve as a workaround.
> >
> > @Martin-Éric: Maybe you can confirm this,
> > otherwise my findings might be unrelated.
>
> @Bernhard: Thanks for the heads up.
>
> I first tried downgrading to earlier versions found at
> .
>
> 1.0.0+git-20190125.36a4c85-1: Fails to launch as above.
> 1.0.0+git-20161027.b991c67-1: Fails to launch as above.
> 1.0.0+git-20141004.86285d1-1: Immediately shows me the PXE menu.
>
> $ find . -name general.h
> ./debian/config/general.h
> ./src/config/vbox/general.h
> ./src/config/general.h
> ./src/config/qemu/general.h
> ./src/config/cloud/general.h
>
> $ rgrep TIVOLI_VMM_WORKAROUND
> src/config/general.h:#defineTIVOLI_VMM_WORKAROUND/* Work
> around the Tivoli VMM's garbling of SSE
> src/config/qemu/general.h:#undef TIVOLI_VMM_WORKAROUND
> src/arch/x86/transitions/librm.S:#ifdef TIVOLI_VMM_WORKAROUND
> src/arch/x86/transitions/librm.S:#ifdef TIVOLI_VMM_WORKAROUND
> src/arch/x86/transitions/librm.S:#ifdef TIVOLI_VMM_WORKAROUND
>
> I assume that you meant in ? Where and how did
> you disable that?

What I did:

*
diff -Nru ipxe-1.0.0+git-20190125.36a4c85/debian/changelog
ipxe-1.0.0+git-20190125.36a4c85/debian/changelog
--- ipxe-1.0.0+git-20190125.36a4c85/debian/changelog2021-02-07
19:25:50.0 +0200
+++ ipxe-1.0.0+git-20190125.36a4c85/debian/changelog2022-03-20
08:44:01.0 +0200
@@ -1,3 +1,10 @@
+ipxe (1.0.0+git-20190125.36a4c85-5.2) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * #undef TIVOLI_VMM_WORKAROUND
+
+ -- Martin-Éric Racine   Sun, 20 Mar 2022
08:44:01 +0200
+
 ipxe (1.0.0+git-20190125.36a4c85-5.1) unstable; urgency=medium

   * Non-maintainer upload.
diff -Nru ipxe-1.0.0+git-20190125.36a4c85/debian/config/general.h
ipxe-1.0.0+git-20190125.36a4c85/debian/config/general.h
--- ipxe-1.0.0+git-20190125.36a4c85/debian/config/general.h
2020-02-25 22:45:06.0 +0200
+++ ipxe-1.0.0+git-20190125.36a4c85/debian/config/general.h
2022-03-20 08:43:54.0 +0200
@@ -3,3 +3,5 @@

 #define NET_PROTO_IPV6
 #define DOWNLOAD_PROTO_NFS
+
+#undef TIVOLI_VMM_WORKAROUND
*

The resulting binary immediately shows me the PXE menu.

Meanwhile, iPXE itself is bugged. It clears the screen before
displaying the PXE menu, and it only displays the first 2 options, for
some reason all the way at the bottom of the screen. When I tap on
DOWN-ARROW to show more menu options, it starts repeating the last
menu option. The same issue can be seen on
<1.0.0+git-20141004.86285d1-1>, so that's probably an upstream issue.

When booting using the BIOS' build-in PXE support or via GRUB with a
self-built gPXE binary, the whole menu is displayed as expected.

Martin-Éric

Bug#1005410: chromium: debug trap warning on browser start up

[10dmar10]

Hi,

updating chromium to 99.0.4844.74-1 seems to have fixed this problem, thanks.



2022-02-19 0:08 GMT+01:00, 10dmar10 <10dma...@gmail.com>:
>> I just uploaded 98.0.4758.102-1, please let me know if it still happens
>> there.
>> Also, do you get symbols in the backtrace when you run "chromium -g"?
>
> Hi,
>
> the warning is still present in version 98.0.4758.102-1,
> but there is a slight change:
>
> the trap seems to be catched by chromium itself - gdb does not stop on trap
>
> anymore.
>
>
> # dmesg
>
> [  849.053964] traps: chromium[2709] trap int3 ip:55d7bc90c1d5
> sp:7ffd036c2270
> error:0 in chromium[55d7b9121000+8ce7000]
>
>
> # console
>
> [2656:2656:0218/234407.000497:ERROR:gpu_init.cc(454)] Passthrough is not
> supported, GL is desktop, ANGLE is
> [2656:2656:0218/234407.098893:ERROR:sandbox_linux.cc(377)]
> InitializeSandbox()
> called with multiple threads in process gpu-process.
> Crashing due to FD ownership violation:
> #0 0x55d7bc85e1a3 
> #1 0x55d7bc90c1cc 
> #2 0x55d7bc90c0a0 
> #3 0x55d7be74f24c 
> #4 0x55d7be737e62 
> #5 0x55d7b9122953 
> #6 0x55d7bc3ef6ac 
> #7 0x55d7bc3ed256 
> #8 0x55d7bc3edac4 
> #9 0x55d7b9121c1b 
> #10 0x7f3c967447ed 
> [2606:2694:0218/234411.984164:ERROR:chrome_browser_main_extra_parts_metrics.cc(227)]
>
> START: ReportBluetoothAvailability(). If you don't see the END: message,
> this is
> crbug.com/1216328.
> [2606:2694:0218/234411.984196:ERROR:chrome_browser_main_extra_parts_metrics.cc(230)]
>
> END: ReportBluetoothAvailability()
>
>
> # chromium -g
>
>
> # Env:
> # LD_LIBRARY_PATH=
> #
> PATH=/usr/local/bin:/usr/bin:/bin:/usr/local/games:/usr/games:/home/wwa/bin:/home/wwa/src/prog_lang/go/bin:/usr/lib/go-1.17/bin
> #GTK_PATH=
> #  CHROMIUM_FLAGS= --show-component-extension-options
> --enable-gpu-rasterization --no-default-browser-check --disable-pings
> --media-router=0 --disable-background-networking --disable-sync
> --force-dark-mode --enable-features=WebUIDarkMode
> --force-prefers-reduced-motion
> --autoplay-policy=user-required
> --disable-features=PreloadMediaEngagementData,AutoplayIgnoreWebAudio,MediaEngagementBypassAutoplayPolicies
>
> --use-gl=desktop --show-component-extension-options --ignore-gpu-blacklist
> --no-default-browser-check --disable-pings --disable-background-networking
> --media-router=0 --enable-remote-extensions
> --show-component-extension-options
> --ignore-gpu-blacklist --no-default-browser-check --disable-pings
> --media-router=0 --enable-remote-extensions --enable-remote-extensions
> --load-extension=
> /usr/bin/gdb /usr/lib/chromium/chromium -x /tmp/chromiumargs.WXbRm0
> GNU gdb (Debian 10.1-2) 10.1.90.20210103-git
> Copyright (C) 2021 Free Software Foundation, Inc.
>
>
> License GPLv3+: GNU GPL version 3 or later
> 
>
>
> This is free software: you are free to change and redistribute it.
>
>
> There is NO WARRANTY, to the extent permitted by law.
>
>
> Type "show copying" and "show warranty" for details.
>
>
> This GDB was configured as "x86_64-linux-gnu".
>
>
> Type "show configuration" for configuration details.
>
>
> For bug reporting instructions, please see:
>
>
> .
>
>
> Find the GDB manual and other documentation resources online at:
>
>
>  .
>
>
>
> For help, type "help".
>
>
> Type "apropos word" to search for commands related to "word"...
>
>
> Reading symbols from /usr/lib/chromium/chromium...
>
>
> Reading symbols from
> /usr/lib/debug/.build-id/91/60aa11533c38cb020127fc32477502e3b3ec53.debug...
>
>
> (gdb) run
>
>
> Starting program: /usr/lib/chromium/chromium
> --show-component-extension-options
> --enable-gpu-rasterization --no-default-browser-check --disable-p
> ings --media-router=0 --disable-background-networking --disable-sync
>
> --force-dark-mode --enable-features=WebUIDarkMode --force-prefers-reduced-mo
>
>tion --autoplay-policy=user-required
> --disable-features=PreloadMediaEngagementData,AutoplayIgnoreWebAudio,MediaEngagementBypassAutoplayPolicies
>
> -  -use-gl=desktop --show-component-extension-options
> --ignore-gpu-blacklist --no-default-browser-check --disable-pings
> --disable-background-network  ing --media-router=0
> --enable-remote-extensions --show-component-extension-options
> --ignore-gpu-blacklist --no-default-browser-check --disable-pi
>  ngs --media-router=0 --enable-remote-extensions
> --enable-remote-extensions
> --load-extension= --single-process
>
> [Thread debugging using libthread_db enabled]
>
>
> Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
>
>
> [Detaching after fork from child process 3225]
>
>
> [New Thread 0x729b9640 (LWP 3227)]
>
>
> [Detaching after fork from child process 3229]
>
>
> [Detaching after fork from child process 3232]
>
>
> [Detaching after fork from child process 3233]
> [New Thread 0x721b8640 (LWP 3236)]
>

Bug#1007199: ipxe: fails to boot on Geode LX

[Martin-Éric Racine]

On Sat, Mar 19, 2022 at 1:59 AM Bernhard Übelacker
 wrote:
> I tried to reproduce the issue with the help of a qemu VM.
>
> That way I found /usr/lib/ipxe/ipxe.lkrn working with specifying
> a pentium2 CPU, but hangs with a pentium.
>
> Similarly I found the version 1.0.0+git-20150424.a25a16d-1
> does not show this issue, but all newer than this.
>
> And found in [1] a hint that building without
> TIVOLI_VMM_WORKAROUND gives a Debian package that works too.
> And indeed, attaching a debugger to the VM shows it hanging
> always executing an fxsave and iret instruction, PF flag set,
> while TIVOLI_VMM_WORKAROUND would also enable a fxsave instruction.
>
> Therefore at least either using the older package version
> or rebuilding locally with above modification
> might serve as a workaround.
>
> @Martin-Éric: Maybe you can confirm this,
> otherwise my findings might be unrelated.

@Bernhard: Thanks for the heads up.

I first tried downgrading to earlier versions found at
.

1.0.0+git-20190125.36a4c85-1: Fails to launch as above.
1.0.0+git-20161027.b991c67-1: Fails to launch as above.
1.0.0+git-20141004.86285d1-1: Immediately shows me the PXE menu.

$ find . -name general.h
./debian/config/general.h
./src/config/vbox/general.h
./src/config/general.h
./src/config/qemu/general.h
./src/config/cloud/general.h

$ rgrep TIVOLI_VMM_WORKAROUND
src/config/general.h:#defineTIVOLI_VMM_WORKAROUND/* Work
around the Tivoli VMM's garbling of SSE
src/config/qemu/general.h:#undef TIVOLI_VMM_WORKAROUND
src/arch/x86/transitions/librm.S:#ifdef TIVOLI_VMM_WORKAROUND
src/arch/x86/transitions/librm.S:#ifdef TIVOLI_VMM_WORKAROUND
src/arch/x86/transitions/librm.S:#ifdef TIVOLI_VMM_WORKAROUND

I assume that you meant in ? Where and how did
you disable that?

Martin-Éric

Bug#1007992: libigdgmm12: new version causes segfaults

[Paul Menzel]

Control: forwarded -1 https://github.com/intel/gmmlib/issues/95


Dear Debian folks,


Am 20.03.22 um 07:07 schrieb Paul Menzel:

Control: forward -1 https://github.com/intel/gmmlib/issues/95


I thought it was `forwarded`, but changed after reading the example in 
*How to report a bug in Debian using reportbug* [2], which turned out to 
be wrong.


[…]


Kind regards,

Paul


[2]: https://www.debian.org/Bugs/Reporting.en.html#control

Bug#1007992: libigdgmm12: new version causes segfaults

[Paul Menzel]

Control: forward -1 https://github.com/intel/gmmlib/issues/95

Dear Debian folks,


Am 20.03.22 um 04:35 schrieb Christoph Anton Mitterer:

[…]


This version breaks e.g. video playback with mpv (also vlc):
$ mpv test.mp4
  (+) Video --vid=1 (h264 720x300 23.976fps)
  (+) Audio --aid=1 (aac 2ch 44100Hz)
Segmentation fault


I am only able to reproduce this with VA-API enabled, that means, when I 
pass `--hwdec=vaapi` to mpv. Firefox with VA-API enabled crashes too, 
but not when it’s disabled. Do you have VA-API enabled for mpv?


[…]

I installed *libigdgmm12-dbgsym*, and created the issue #95 
*[regression] Terminates with segfault in InitializeGmm/InitContext* 
upstream [1].


Hopefully, they analyze and fix it quickly. No idea, if it’s possible to 
revert to an earlier version in Debian sid/unstable until that is fixed.



Kind regards,

Paul


[1]: https://github.com/intel/gmmlib/issues/95

Bug#1007994: qtpaths is broken for cross compilation

[Helmut Grohne]

Package: qttools5-dev-tools
Version: 5.15.2-5+b1
Severity: important
Justification: multiarch violation
User: debian-cr...@lists.debian.org
Usertags: ftcbfs
Control: affects -1 + src:qt5ct

Dear qt maintainers,

we have a bigger problem about qtpaths. I haven't checked, but I think
it also affects qt6. When building qt5ct (and likely others), it locates
qtpaths. We presently have 3 different locations:
 * /usr/bin/qtpaths (wrapper for the next)
 * /usr/lib/qt5/bin/qtpaths (actual binary)
 * /usr/lib//qt5/bin/qtpaths (symlink to the second)

Note that since qtpaths resides in qttools5-dev-tools, which happens to
be Multi-Arch: foreign, the  path is only ever
available for the build architecture and no client package has the
ability to ever select a host architecture qtpaths even if it were
trying to do so.

qt5ct happens to select the second one. It then runs qtpaths
--plugin-dir and gets back /usr/lib//qt5/plugins.
Unsurprisingly, that multiarchtriplet happens to bet the build
architecture one.  This is very bad and produces misbuilds. I don't see
any way that qt5ct could improve on this aspect without also changing
qttools5-dev-tools.

So how do we fix that?

Quite obviously, qtpaths is architecture dependent. Thus we need an
instance of it that happens to be architecture aware. Most likely that'd
be both of /usr/bin/-qtpaths and
/usr/lib//qt5/bin/qtpaths.  While the latter may look
present, we really mean the host architecture one here.

Step 1: Construct a qtpaths wrapper script that makes it return output
for a given architecture instead of the native one. We've done this e.g.
for qmake already, but I couldn't figure out how to make it work for
qtpaths. I couldn't find an option for qtpaths similar to -qtconf for
qmake. Is there anything better we can do than replacing it entirely
with a shell script?

Step 2: Split packages. qttools5-dev-tools quite obviously cannot
continue being Multi-Arch: foreign. So much of it must be moved to a new
Multi-Arch: foreign package qttools5-dev-tools-bin. Then a new and
almost empty qttools5-dev-tools Multi-Arch: same package depends on
qttools5-dev-tools-bin. That way no client package is broken. Initially
qttools5-dev-tools keeps /usr/lib/ and everything else
moves to qttools5-dev-tools-bin.

Step 3: Add the wrapper script from step1 to qttools5-dev-tools. That
probably replaces the present symlink
/usr/lib//qt5/bin/qtpaths.

Note that steps 1 and 2 can be performed in parallel and independently.
Starting step 2 early is paramount as it will trip through new.

What happens to /usr/bin/-qtpaths is very unclear to me.
It's even unclear whether we need it at all given that packages seem to
prefer picking a qt installation root (e.g.
/usr/lib//qt5) and then locating everything from
there. If we need it, we likely need to involve qtchooser in order to
support qt6.

So does this make sense from the qt-maintainers pov?

Helmut