Processed: retitle 929732 to firejail: CVE-2019-12589: seccomp bypass when joining jails

2019-06-02 Thread Debian Bug Tracking System
Processing commands for cont...@bugs.debian.org:

> retitle 929732 firejail: CVE-2019-12589: seccomp bypass when joining jails
Bug #929732 {Done: Reiner Herrmann } [src:firejail] 
firejail: seccomp bypass when joining jails
Changed Bug title to 'firejail: CVE-2019-12589: seccomp bypass when joining 
jails' from 'firejail: seccomp bypass when joining jails'.
> thanks
Stopping processing here.

Please contact me if you need assistance.
-- 
929732: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=929732
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems



Processed: Re: Bug#928948: hostapd: syslog is spammed every two seconds

2019-06-02 Thread Debian Bug Tracking System
Processing control commands:

> tags -1 pending
Bug #928948 [hostapd] hostapd: syslog is spammed every two seconds
Added tag(s) pending.

-- 
928948: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=928948
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems



Bug#928948: hostapd: syslog is spammed every two seconds

2019-06-02 Thread Andrej Shadura
Control: tags -1 pending

Hi,

On Mon, 3 Jun 2019 at 03:36, Reinhard Tartler  wrote:
> I'm trying to help out with remaining RC bugs for buster.
>
> > The postinst is set up in a way so that if /etc/hostapd/hostapd.conf
> > is not readable or missing, the hostapd.service is masked during the
> > package installation unless it was already running.
>
> I wonder if that is really necessary and couldn't be avoided by using the 
> following drectitve in hostapd.service:
>
> ConditionPathExists=/etc/hostapd/hostapd.conf
>
> If my understading of systemd.unit(5) is correct, I believe this might 
> simplify significantly simplify the postinst script.

Your understanding is correct, but, unfortunately, we cannot do that
for buster since there’s no guarantee users are going to have their
configuration file there. For bullseye, this is going to be the plan.

I will upload a fix later today.

-- 
Cheers,
  Andrej



Bug#923661: marked as done (tt-rss: PHP Fatal error: Uncaught PDOException: SQLSTATE[22001]: String data, right truncated)

2019-06-02 Thread Debian Bug Tracking System
Your message dated Mon, 03 Jun 2019 04:34:06 +
with message-id 
and subject line Bug#923661: fixed in tt-rss 18.12+dfsg-1.1
has caused the Debian Bug report #923661,
regarding tt-rss: PHP Fatal error:  Uncaught PDOException: SQLSTATE[22001]: 
String data, right truncated
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact ow...@bugs.debian.org
immediately.)


-- 
923661: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=923661
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--- Begin Message ---
Package: tt-rss
Version: 18.12+dfsg-1
Severity: important

Hi,

after upgrading from 16.8+git20160826+dfsg-3 (which I had run under
Debian stretch), tt-rss fails to display anything after the login page.
There is this error:

[Sun Mar 03 13:15:12.954927 2019] [php7:error] [pid 2055] [client XXX] PHP 
Fatal error:  Uncaught PDOException: SQLSTATE[22001]: String data, right 
truncated: 1406 Data too long for column 'context' at row 1 in 
/usr/share/tt-rss/www/classes/logger/sql.php:18
Stack trace:
#0 /usr/share/tt-rss/www/classes/logger/sql.php(18): 
PDOStatement->execute(Array)
#1 /usr/share/tt-rss/www/classes/logger.php(28): Logger_SQL->log_error(8192, 
'strpos(): Non-s...', 'vendor/JShrink/...', 184, '1. vendor/JShri...')
#2 /usr/share/tt-rss/www/include/errorhandler.php(43): Logger->log_error(8192, 
'strpos(): Non-s...', 'vendor/JShrink/...', 184, '1. vendor/JShri...')
#3 [internal function]: ttrss_error_handler(8192, 'strpos(): Non-s...', 
'vendor/JShrink/...', 184, '1. vendor/JShri...')
#4 /usr/share/tt-rss/www/vendor/JShrink/Minifier.php(184): strpos('(-+{[@', 
false)
#5 /usr/share/tt-rss/www/vendor/JShrink/Minifier.php(144): 
JShrink\\Minifier->loop()
#6 /usr/share/tt-rss/www/vendor/JShrink/Minifier.php(110): 
JShrink\\Minifier->minifyDirectToOutput('/* global dijit...', Array)
#7 /usr/share/tt-rss/www/include/functions.php in 
/usr/share/tt-rss/www/classes/logger/sql.php on line 18, referer: https://XXX


I have then changed LOG_DESTINATION to syslog in config.php and it
worked again. In syslog, I see this message:

php: [tt-rss] E_DEPRECATED (8192) (vendor/JShrink/Minifier.php:184) strpos(): 
Non-string needles will be interpreted as strings in the future. Use an 
explicit chr() call to preserve the current behavior


If no other fix is possible in time for buster release, maybe the default for 
LOG_DESTINATION
could be changed?

Cheers,
Stefan


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

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

Versions of packages tt-rss depends on:
ii  dbconfig-common 2.0.11
ii  dbconfig-mysql  2.0.11
ii  debconf [debconf-2.0]   1.5.70
ii  init-system-helpers 1.56+nmu1
ii  libapache2-mod-php  2:7.3+69
ii  libapache2-mod-php7.3 [libapache2-mod-php]  7.3.2-3
ii  libjs-dojo-core 1.14.2+dfsg1-1
ii  libjs-dojo-dijit1.14.2+dfsg1-1
ii  libjs-scriptaculous 1.9.0-2
ii  lsb-base10.2018112800
ii  php 2:7.3+69
ii  php-cli 2:7.3+69
ii  php-mbstring2:7.3+69
ii  php-mysql   2:7.3+69
ii  php-php-gettext 1.0.12-0.1
ii  php-xml 2:7.3+69
ii  php7.0-cli [php-cli]7.0.33-0+deb9u2
ii  php7.0-json [php-json]  7.0.33-0+deb9u2
ii  php7.0-mbstring [php-mbstring]  7.0.33-0+deb9u2
ii  php7.0-xml [php-xml]7.0.33-0+deb9u2
ii  php7.3 [php]7.3.2-3
ii  php7.3-cli [php-cli]7.3.2-3
ii  php7.3-json [php-json]  7.3.2-3
ii  php7.3-mbstring [php-mbstring]  7.3.2-3
ii  php7.3-xml [php-xml]7.3.2-3
ii  phpqrcode   1.1.4-3

Versions of packages tt-rss recommends:
ii  apache2 [httpd] 2.4.38-2
ii  ca-certificates 20190110
ii  php-curl2:7.3+69
ii  php-gd  2:7.3+69
ii  php-mcrypt  1:7.0+49
ii  php7.0-gd [php-gd]  7.0.33-0+deb9u2
ii  

Processed: libreswan: CVE-2019-12312

2019-06-02 Thread Debian Bug Tracking System
Processing control commands:

> fixed -1 3.28-1
Bug #929916 [src:libreswan] libreswan: CVE-2019-12312
Marked as fixed in versions libreswan/3.28-1.

-- 
929916: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=929916
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems



Bug#929916: libreswan: CVE-2019-12312

2019-06-02 Thread Salvatore Bonaccorso
Source: libreswan
Version: 3.27-4
Severity: grave
Tags: patch security upstream fixed-upstream
Justification: user security hole
Forwarded: https://github.com/libreswan/libreswan/issues/246
Control: fixed -1 3.28-1

Hi,

The following vulnerability was published for libreswan.

CVE-2019-12312[0]:
| In Libreswan before 3.28, an assertion failure can lead to a pluto IKE
| daemon restart. An attacker can trigger a NULL pointer dereference by
| sending two IKEv2 packets (init_IKE and delete_IKE) in 3des_cbc mode
| to a Libreswan server. This affects send_v2N_spi_response_from_state
| in programs/pluto/ikev2_send.c when built with Network Security
| Services (NSS).


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-12312
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-12312
[1] https://github.com/libreswan/libreswan/issues/246
[2] 
https://github.com/libreswan/libreswan/commit/7142d2c37d58cf024595a7549f0fb0d3946682f8

Regards,
Salvatore



Bug#926676: marked as done (guile-2.2-dev: Missing binary symlink `guild-2.2` (and others))

2019-06-02 Thread Debian Bug Tracking System
Your message dated Mon, 03 Jun 2019 02:40:02 +
with message-id 
and subject line Bug#926182: fixed in guile-2.2 2.2.4+1-2
has caused the Debian Bug report #926182,
regarding guile-2.2-dev: Missing binary symlink `guild-2.2` (and others)
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact ow...@bugs.debian.org
immediately.)


-- 
926182: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=926182
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--- Begin Message ---
Package: guile-2.2-dev
Version: 2.2.4+1-1
Severity: normal

The `guile-2.2` package installs the `guile-2.2` binary. This in turn
will cause the `GUILE_PROGS` autoconf macro (as shipped in
`guile-2.2-dev`) to look for `guild-2.2`, not considering the
installed `guild` binary, thus causing `configure` scripts that use
`GUILE_PROGS` to fail like this:

configure: checking for guile 2.2
configure: found guile 2.2
checking for guile-2.2... /usr/bin/guile-2.2
checking for Guile version >= 2.2... 2.2.4
checking for guild-2.2... no
checking for guile-config-2.2... no
checking for guile-tools-2.2... no
configure: error: 'guild' binary not found; please check your guile-2.x 
installation.

The above output was from an attempt at compiling `guix` [0]. It seems
that if a versioned `guile` binary (such as `guile-2.2`) is present,
so should versioned variants of `guild`, `guile-config`, and
`guile-tools`. The documentation of the `GUILE_PROGS` macro supports
this:

 This macro looks for programs ‘guile’ and ‘guild’, setting
 variables GUILE and GUILD to their paths, respectively.  The macro
 will attempt to find ‘guile’ with the suffix of ‘-X.Y’, followed by
 looking for it with the suffix ‘X.Y’, and then fall back to looking
 for ‘guile’ with no suffix.  If ‘guile’ is still not found, signal
 an error.  The suffix, if any, that was required to find ‘guile’
 will be used for ‘guild’ as well.

Installing the versioned variants might even be a step on the way to
allow co-installability of `guile-2.2-dev` and future versions of the
Guile development binary package.

[0] https://www.gnu.org/software/guix/manual/en/guix.html#Introduction

Kind Regards, Rotty

-- System Information:
Debian Release: buster/sid
  APT prefers testing
  APT policy: (850, 'testing'), (800, 'unstable'), (500, 'testing-debug'), (1, 
'experimental')
Architecture: amd64 (x86_64)

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

Versions of packages guile-2.2-dev depends on:
ii  guile-2.2   2.2.4+1-1
ii  guile-2.2-libs  2.2.4+1-1
ii  libc6-dev   2.28-8
ii  libgc-dev   1:7.6.4-0.4
ii  libgmp-dev  2:6.1.2+dfsg-4
ii  libltdl-dev 2.4.6-9
ii  libncurses-dev [libncurses5-dev]6.1+20181013-2
ii  libncurses5-dev 6.1+20181013-2
ii  libreadline-dev [libreadline6-dev]  7.0-5
ii  pkg-config  0.29-6

guile-2.2-dev recommends no packages.

guile-2.2-dev suggests no packages.

-- no debconf information
--- End Message ---
--- Begin Message ---
Source: guile-2.2
Source-Version: 2.2.4+1-2

We believe that the bug you reported is fixed in the latest version of
guile-2.2, which is due to be installed in the Debian FTP archive.

A summary of the changes between this version and the previous one is
attached.

Thank you for reporting the bug, which will now be closed.  If you
have further comments please address them to 926...@bugs.debian.org,
and the maintainer will reopen the bug report if appropriate.

Debian distribution maintenance software
pp.
Rob Browning  (supplier of updated guile-2.2 package)

(This message was generated automatically at their request; if you
believe that there is a problem with it please contact the archive
administrators by mailing ftpmas...@ftp-master.debian.org)


-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Format: 1.8
Date: Sun, 02 Jun 2019 11:17:15 -0500
Source: guile-2.2
Binary: guile-2.2 guile-2.2-dev guile-2.2-doc guile-2.2-libs 
guile-2.2-libs-dbgsym
Architecture: source amd64 all
Version: 2.2.4+1-2
Distribution: unstable
Urgency: medium
Maintainer: Rob Browning 
Changed-By: Rob Browning 
Description:
 guile-2.2  - GNU extension language and Scheme interpreter
 guile-2.2-dev - Development files for Guile 2.2
 

Bug#926182: marked as done (guile-2.2-dev: autoreconf'ed scripts using guile.m4 cannot find guild & guile-config/tools)

2019-06-02 Thread Debian Bug Tracking System
Your message dated Mon, 03 Jun 2019 02:40:02 +
with message-id 
and subject line Bug#926182: fixed in guile-2.2 2.2.4+1-2
has caused the Debian Bug report #926182,
regarding guile-2.2-dev: autoreconf'ed scripts using guile.m4 cannot find guild 
& guile-config/tools
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact ow...@bugs.debian.org
immediately.)


-- 
926182: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=926182
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--- Begin Message ---
Package: guile-2.2
Version: 2.2.4+1-1
Severity: normal

Building gwave against guile-2.2 fails if gwave runs dh_autoreconf, that 
is bexause the autoreconf'ed configure script fails to find guild 
and guile-config/tools binaries, relevant configure log below:

configure: checking for guile 2.2
configure: found guile 2.2
checking for guile-2.2... /usr/bin/guile-2.2
checking for Guile version >= 2.2... 2.2.4
checking for guild-2.2... no
checking for guile-config-2.2... no
checking for guile-tools-2.2... no
checking build system type... x86_64-pc-linux-gnu
checking host system type... x86_64-pc-linux-gnu
checking for ld used by gcc... /usr/bin/ld
checking if the linker (/usr/bin/ld) is GNU ld... yes
checking for shared library run path origin... done
checking for GUILE... yes
configure: error: 'guild' binary not found; please check your guile-2.x 
installation.

The problem is because after autoreconf, the configure script searches 
for guild with the -2.2 suffix, yet the guile-2.2-dev package installs 
guild without that suffix, although guile binary has the -2.2 suffix in 
guile-2.2 package. Yet in /usr/share/aclocal/guile.m4 it says:

# @code{guile} is still not found, signal an error. The suffix, if any,
# that was required to find @code{guile} will be used for @code{guild}
# as well.

Hence,I beleive that that there is an issue with guile-2.2 package. 
Either the guild & guile-config/tools binaries shpuld be insyalled with 
-2.2 suffix (probably installing symlinks with no suffix to the 
respective -2.2 suffixed binaries), or the guile.m4 script needs to be 
fixed.

-- 
‎أحمد المحمودي (Ahmed El-Mahmoudy)
 Digital design engineer
GPG KeyIDs: 4096R/A7EF5671 2048R/EDDDA1B7
GPG Fingerprints:
 6E2E E4BB 72E2 F417 D066  6ABF 7B30 B496 A7EF 5761
 8206 A196 2084 7E6D 0DF8  B176 BC19 6A94 EDDD A1B7


signature.asc
Description: PGP signature
--- End Message ---
--- Begin Message ---
Source: guile-2.2
Source-Version: 2.2.4+1-2

We believe that the bug you reported is fixed in the latest version of
guile-2.2, which is due to be installed in the Debian FTP archive.

A summary of the changes between this version and the previous one is
attached.

Thank you for reporting the bug, which will now be closed.  If you
have further comments please address them to 926...@bugs.debian.org,
and the maintainer will reopen the bug report if appropriate.

Debian distribution maintenance software
pp.
Rob Browning  (supplier of updated guile-2.2 package)

(This message was generated automatically at their request; if you
believe that there is a problem with it please contact the archive
administrators by mailing ftpmas...@ftp-master.debian.org)


-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Format: 1.8
Date: Sun, 02 Jun 2019 11:17:15 -0500
Source: guile-2.2
Binary: guile-2.2 guile-2.2-dev guile-2.2-doc guile-2.2-libs 
guile-2.2-libs-dbgsym
Architecture: source amd64 all
Version: 2.2.4+1-2
Distribution: unstable
Urgency: medium
Maintainer: Rob Browning 
Changed-By: Rob Browning 
Description:
 guile-2.2  - GNU extension language and Scheme interpreter
 guile-2.2-dev - Development files for Guile 2.2
 guile-2.2-doc - Documentation for Guile 2.2
 guile-2.2-libs - Core Guile libraries
Closes: 900652 926182
Changes:
 guile-2.2 (2.2.4+1-2) unstable; urgency=medium
 .
   * Backport upstream fix for after-gc-hook test failures.  Replace
 0006-gc.test-after-gc-hook-mark-unresolved-on-failure-for.patch that
 marked the failure as unresolved on mips(el) (a failure which has been
 seen since on at least sparc64 and amd64) with
 0006-Fix-gc.test-after-gc-hook-gets-called-failures.patch which
 addresses the underlying problem. (Closes: 900652)
 .
   * Handle guile-config/guile-snarf/guild as alternatives.  Arrange for
 guile-config, guile-snarf, guild (and guile-tools) to be handled via
 update-alternatives with all of the other tools dependent on
 guile-config.  Configure with "--program-suffix -2.2" which gives the
 binaries the correct names from the start, so that we don't have to
 manually change them in debian/rules.  This also arranges for
 

Bug#922346: Fix for this issue still not available in testing

2019-06-02 Thread Hideki Yamane
On Sun, 26 May 2019 12:41:39 +0200 Michel Le Bihan  wrote:
> I saw that Mesa 18.3.6-2 was accepted into unstable on 2019-05-11. That
> version still hasn't migrated to testing because of the freeze. Could
> you please contact the release team to get this release in testing ASAP
> as I (and probably other users) am still experiencing this issue and it
> is very critical because opening a media file can cause my DE to crash
> causing the loss of any unsaved work.

 However, it contains thousands of diffs that is unsuitable during
 full freeze period. It'd be better to provide patch that only dealing
 with this issue for testing-proposed-update suite.


-- 
Hideki Yamane 



Bug#926182: Patch: Use alternatives system for guile-2.2-dev binaries

2019-06-02 Thread Rob Browning
Rob Browning  writes:

> Rob Browning  writes:
>
>> Yep -- I'm not sure yet, but I may lean toward providing:
>>
>>   bin/guile -> ./guile-2.2  # or whatever the selected alternative is
>>   bin/guild -> ./guild-2.2  # or whatever the selected alternative is
>
> OK, I think I'll have an upload this weekend using the built in
> ./configure --program-suffix support.  That produces a nearly identical
> install tree (though I'll need to double check the debs), excepting
> changes that should solve our problems, i.e. it installs:


Uploaded 2.2.4+1-2 to sid:

  https://salsa.debian.org/rlb/deb-guile/commits/deb/guile-2.2/v/2.2.4+1-2

Which includes:

  commit 4885ac01ce33474021b51695ef896661f237bd40
  Author: Rob Browning 
  Date:   Sat Jun 1 13:20:41 2019 -0500

  Handle guile-config/guile-snarf/guild as alternatives

  Arrange for guile-config, guile-snarf, guild (and guile-tools) to be
  handled via update-alternatives with all of the other tools dependent on
  guile-config.

  Configure with "--program-suffix -2.2" which gives the binaries the
  correct names from the start, so that we don't have to manually change
  them in debian/rules.  This also arranges for guile-config, etc. to
  refer to the versioned guile in their #! lines, which is what we should
  have been doing all along.

  Thanks to Ahmed El-Mahmoudy and Norbert Preining for reporting the
  problem, Kari Pahula and Vagrant Cascadian for help devising the fix,
  and Thibaut Paumard for help testing.

  Closes: 926182

I also included an upstream fix for the popen.test failures which I'd
begun hitting on amd64 too.  I'll see about badgering the release team
if it the buildds like it, but feel free to ping me if I wander off.

Thanks for all the help
-- 
Rob Browning
rlb @defaultvalue.org and @debian.org
GPG as of 2011-07-10 E6A9 DA3C C9FD 1FF8 C676 D2C4 C0F0 39E9 ED1B 597A
GPG as of 2002-11-03 14DD 432F AE39 534D B592 F9A0 25C8 D377 8C7E 73A4



Processed: Bug#928429 in package dpkg marked as pending

2019-06-02 Thread Debian Bug Tracking System
Processing control commands:

> tag 928429 pending
Bug #928429 [dpkg] dpkg: trigger cycle postgresql-common -> sgml-base while 
upgrading from stretch to buster
Added tag(s) pending.

-- 
928429: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=928429
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems



Bug#928429: in package dpkg marked as pending

2019-06-02 Thread Guillem Jover
Control: tag 928429 pending

Hi!

Bug #928429 in package dpkg reported by you has been fixed in
the dpkg/dpkg.git Git repository. You can see the changelog below, and
you can check the diff of the fix at:

https://git.dpkg.org/cgit/dpkg/dpkg.git/diff/?id=b5c50b3c6

---
commit b5c50b3c6f0739f45aaa03afa3e5c857e7895c8c
Author: Guillem Jover 
Date:   Mon May 13 03:36:03 2019 +0200

dpkg: Introduce a new dependency try level for trigger cycle checks

This new dependtry level will also check trigger cycles on trigger
process deferral due to unsatisfiable dependencies.

Closes: #928429

diff --git a/debian/changelog b/debian/changelog
index 3d97a0111..2a0615f36 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -6,6 +6,9 @@ dpkg (1.19.7) UNRELEASED; urgency=medium
   * dpkg: Set the force defaults before loading the config file, otherwise we
 incorrectly override them. Regression introduced in dpkg 1.19.5.
 Closes: #928671
+  * dpkg: Split the trigger dependtry into two, the second of which will be
+the one checking trigger cycles when deferring trigger processing due to
+unsatisfiable dependencies. Closes: #928429
 
   [ Updated programs translations ]
   * Catalan (Guillem Jover).



Bug#928948: hostapd: syslog is spammed every two seconds

2019-06-02 Thread Reinhard Tartler
Hi,

I'm trying to help out with remaining RC bugs for buster.

> The postinst is set up in a way so that if /etc/hostapd/hostapd.conf
> is not readable or missing, the hostapd.service is masked during the
> package installation unless it was already running.

I wonder if that is really necessary and couldn't be avoided by using the
following drectitve in hostapd.service:

ConditionPathExists=/etc/hostapd/hostapd.conf

If my understading of systemd.unit(5) is correct, I believe this might
simplify significantly simplify the postinst script.

-- 
regards,
Reinhard


Bug#929907: libgnutls30: Connections to older GnUTLS servers break

2019-06-02 Thread Dominik George
Package: libgnutls30
Version: 3.6.7-3
Severity: grave
Justification: renders package unusable

The update to 3.6.7-3 reproducibly breaks ldap-utils (or, maybe,the ldap
client library) when connecting to a server with the previous 3.6.6-2
version.  I am afraid it breaks more than that.  GnuTLS-secured connections
are just closed with no visible reason.

Seen on more than 12 systems, then went to a system that had not got the
update yet.  An ldapsearch works with 3.6.6-2, and fails after updating to
3.6.7-3 with the connection just being closed after reading some data from
the LDAP server setill on 3.6.6-2.  Upgrading GnuTLS to 3.6.7-3 on the
server made the problem go away.

I am setting this critical as I cannot imagine it is expected that GnuTLS
clients require the server to be the exact same version.

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

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

Versions of packages libgnutls30 depends on:
ii  libc6  2.28-10
ii  libgmp10   2:6.1.2+dfsg-4
ii  libhogweed43.4.1-1
ii  libidn2-0  2.0.5-1
ii  libnettle6 3.4.1-1
ii  libp11-kit00.23.15-2
ii  libtasn1-6 4.13-3
ii  libunistring2  0.9.10-1

libgnutls30 recommends no packages.

Versions of packages libgnutls30 suggests:
pn  gnutls-bin  

-- no debconf information



Bug#929903: [Pkg-openssl-devel] Bug#929903: openssl: m2crypto test case regression

2019-06-02 Thread Kurt Roeckx
On Sun, Jun 02, 2019 at 11:00:28PM +0200, Sebastian Andrzej Siewior wrote:
> Package: openssl
> Version: 1.1.1c-1
> Severity: serious
> 
> The m2crypto test suite fails with c, passes with b. The error log
>   
> https://ci.debian.net/data/autopkgtest/testing/amd64/m/m2crypto/2436983/log.gz
> 
> The testsuite complains about a missing error / the exception is not
> raised. The bisect says, this happens since
> 
> |commit f61c68043d3bd2ad9718d356e7988ee2fdfc3621
> | Author: Bernd Edlinger 
> | Date:   Thu Feb 28 10:08:18 2019 +0100
> | 
> | Fix memory overrun in rsa padding check functions
> | 
> | Fixes #8364 and #8357
> | 
> | Reviewed-by: Kurt Roeckx 
> | (Merged from https://github.com/openssl/openssl/pull/8365)
> | 
> | (cherry picked from commit d7f5e5ae6d53f1387a42d210806cf5e9ed0882d6)
> 
> Kurt, can you check if this is an error in the testsuite or something
> legal?

Looking at the log, this is about SSLv23 padding.

>From the review, Bernd wrote:
> While doing that I found an issue in RSA_padding_check_SSLv23
> It does the 03 check the wrong way round. But there is no test coverage,
> so it was not noticed.
[...]
> So, I added a small test for RSA_SSLV23_PADDING, as an extra commit,
> since it will likely not cherry-pick in stable branches.

It's about this change:
-good &= constant_time_lt(threes_in_row, 8);
+good &= constant_time_ge(threes_in_row, 8);

(That should probably have been a separate commit.)

Can you confirm that that is the reason for the change in
behaviour?

I don't understand the m2crypto code, so I have no idea what it's
testing.


Kurt



Bug#929903: openssl: m2crypto test case regression

2019-06-02 Thread Sebastian Andrzej Siewior
Package: openssl
Version: 1.1.1c-1
Severity: serious

The m2crypto test suite fails with c, passes with b. The error log
  https://ci.debian.net/data/autopkgtest/testing/amd64/m/m2crypto/2436983/log.gz

The testsuite complains about a missing error / the exception is not
raised. The bisect says, this happens since

|commit f61c68043d3bd2ad9718d356e7988ee2fdfc3621
| Author: Bernd Edlinger 
| Date:   Thu Feb 28 10:08:18 2019 +0100
| 
| Fix memory overrun in rsa padding check functions
| 
| Fixes #8364 and #8357
| 
| Reviewed-by: Kurt Roeckx 
| (Merged from https://github.com/openssl/openssl/pull/8365)
| 
| (cherry picked from commit d7f5e5ae6d53f1387a42d210806cf5e9ed0882d6)

Kurt, can you check if this is an error in the testsuite or something
legal?

Sebastian



Bug#927126: Fwd: Bug#929342: unblock: aqemu/0.9.2-2.2

2019-06-02 Thread Alexis Murzeau
Le 28/05/2019 à 00:16, Alexis Murzeau a écrit :
> Le 27/05/2019 à 21:58, Alexis Murzeau a écrit :
>> Le 27/05/2019 à 08:02, Abhijith PA a écrit :
>>> On 26 May 2019 4:01:33 PM IST, Alexis Murzeau  wrote:

 Ok, I have changed them to use what's is in the qemu-system manpage.
 Here is the commit on salsa: [0]


 Also, while aqemu will be able to run qemu again, I think it won't be
 able to create multiple virtual hub as the command line option "-net
 nic" only use the default hub ID 0.

 I don't know if this a serious issue that should be fixed too.
 In the meanwhile, I guess aqemu will still be able to create multiple
 nic but all of them will be connected to the same default hub.

 What do you think of this ?
>>>
>>> What is the upstream preferred way of doing this ? 
>>>
 [0]
 https://salsa.debian.org/amurzeau-guest/aqemu/commit/26087ea3c3700bc5a019ae8cc0f84eb14954ef3d
>>>
>>
>> I didn't ask upstream about it but given the last commit is in 2017 and
>> the change I've backported was partly made by someone else in a fork, I
>> don't expect any response from upstream.
>>
>> I think updating aqemu to be able to create multiple virtual hub again
>> is possible but would require more changes than a small patch. I think
>> it would require to remove the use of old -net option of qemu to the
>> newer -netdev.
>>
> 
> For reference, the original issue about the vlan argument was also
> reported upstream in 09/2018 as:
> https://github.com/tobimensch/aqemu/issues/58
> 
> I'm not an aqemu user myself, but if you think that's ok anyway as at
> least configurations with single nic are working now, I've uploaded the
> package on mentors, here is the dsc link:
> 
> https://mentors.debian.net/debian/pool/main/a/aqemu/aqemu_0.9.2-2.3.dsc
> 

Hi,

Did you have any chance to look at this ? Is this upload ok ?

-- 
Alexis Murzeau
PGP: B7E6 0EBB 9293 7B06 BDBC  2787 E7BD 1904 F480 937F



signature.asc
Description: OpenPGP digital signature


Processed: pyglet: diff for NMU version 1.3.0-2.1

2019-06-02 Thread Debian Bug Tracking System
Processing control commands:

> tags 929697 + patch
Bug #929697 [src:pyglet] pyglet: FTBFS randomly because of timing tests
Added tag(s) patch.
> tags 929697 + pending
Bug #929697 [src:pyglet] pyglet: FTBFS randomly because of timing tests
Added tag(s) pending.

-- 
929697: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=929697
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems



Bug#929697: pyglet: diff for NMU version 1.3.0-2.1

2019-06-02 Thread Reinhard Tartler
Control: tags 929697 + patch
Control: tags 929697 + pending

Dear maintainer,

I've prepared an NMU for pyglet (versioned as 1.3.0-2.1) and uploaded
it to DELAYED/2-days. Please feel free to tell me if I should delay it
longer.

Please note that this upload is *not* suitable for buster, as there
are many changes from 1.3.0-1 to 1.3.0-2 (including a conversion from
CDBS to dh) that don't meet the release team's criteria for updates to
buster this late in the game. This patch may need to be uploaded to
testing-proposed-updates separately.

Regards,
-rt

diff -Nru pyglet-1.3.0/debian/changelog pyglet-1.3.0/debian/changelog
--- pyglet-1.3.0/debian/changelog   2019-03-01 22:45:26.0 -0500
+++ pyglet-1.3.0/debian/changelog   2019-06-02 15:17:34.0 -0400
@@ -1,3 +1,14 @@
+pyglet (1.3.0-2.1) unstable; urgency=medium
+
+  [ Yaroslav Halchenko ]
+  * No strings exceptions is allowed in Python2.6
+
+  [ Reinhard Tartler ]
+  * Non-Maintainer upload.
+  * Disable ClockTimingTestCase (Closes: #929697)
+
+ -- Reinhard Tartler   Sun, 02 Jun 2019 15:17:34 -0400
+
 pyglet (1.3.0-2) unstable; urgency=medium
 
   [ Scott Kitterman ]
diff -Nru pyglet-1.3.0/debian/rules pyglet-1.3.0/debian/rules
--- pyglet-1.3.0/debian/rules   2019-03-01 21:13:15.0 -0500
+++ pyglet-1.3.0/debian/rules   2019-06-02 15:17:34.0 -0400
@@ -20,6 +20,8 @@
 EXCLUDED_TESTS += and not test_issue429
 EXCLUDED_TESTS += and not test_issue241
 EXCLUDED_TESTS += and not test_issue471
+# cf. #929697
+EXCLUDED_TESTS += and not ClockTimingTestCase
 
 export PYBUILD_NAME=pyglet
 export PYBUILD_TEST_PYTEST=1



Bug#929877: installation-reports: Buster installer hangs at hard disk step with arabic language

2019-06-02 Thread Holger Wansing

Hi,

Am Sonntag, 2. Juni 2019 schrieb Samuel Thibault:
> ButterflyOfFire, le dim. 02 juin 2019 15:43:41 +, a ecrit:
> > >> "لاحقاً"
> > 
> > This word means "later" and can be replaced by "لاحقا".
> 
> That avoids the issue here indeed. I however see it used in various

Hmm.
There has been no changing in the ar.po of partman-auto
for 3 years now (JFTR), thus the real problem seems to be
sitting somewhere else ...



Holger 

-- 
Sent from my Jolla phone
http://www.jolla.com/

Bug#929172: Same issue as already reported, and partially fixed

2019-06-02 Thread Ludovic Pouzenc
I can confirm that packages landed in unstable solve the situation for 
me (libdebian-installer4 0.119, cdebootstrap 0.7.7+b12, 
cdebootstrap-static 0.7.7+b12).


At time if writing, it's seem not landed in testing yet.

Thanks to all involved people.

--
Ludovic Pouzenc
www.pouzenc.fr

This is GNU/Linux land. In silent nights you can hear the Windows machines 
rebooting.



Bug#916610: Upstream patch, NMU available

2019-06-02 Thread Jakob Haufe
Control: tags -1 + patch upstream

There's an upstream commit[1] fixing this issue. I've prepared an NMU
and uploaded it to mentors [2].

I would like to try and get it sponsored and uploaded to the DELaYED
queue and ideally get it unblocked for buster.

Cheers,
sur5r

[1] 
https://github.com/FreeSpacenav/spacenavd/commit/34ddda1246ad07e8ff2e6606224e710852e3e3d8
[2] https://mentors.debian.net/package/spacenavd


-- 
ceterum censeo microsoftem esse delendam.


pgpeLl9tJmNZL.pgp
Description: OpenPGP digital signature


Processed: Upstream patch, NMU available

2019-06-02 Thread Debian Bug Tracking System
Processing control commands:

> tags -1 + patch upstream
Bug #916610 [spacenavd] spacenavd: conflict with /dev/input/js0
Added tag(s) patch and upstream.

-- 
916610: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=916610
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems



Processed: Re: Bug#929887: /usr/lib/qgis/crssync: error while loading shared libraries: libhdf5_serial_hl.so.100: cannot open shared object file: No such file or directory

2019-06-02 Thread Debian Bug Tracking System
Processing commands for cont...@bugs.debian.org:

> tags 929887 unreproducible
Bug #929887 [qgis-providers] /usr/lib/qgis/crssync: error while loading shared 
libraries: libhdf5_serial_hl.so.100: cannot open shared object file: No such 
file or directory
Added tag(s) unreproducible.
> severity 929887 normal
Bug #929887 [qgis-providers] /usr/lib/qgis/crssync: error while loading shared 
libraries: libhdf5_serial_hl.so.100: cannot open shared object file: No such 
file or directory
Severity set to 'normal' from 'critical'
> notfound 929887 qgis-providers/3.4.8+dfsg-1
Bug #929887 [qgis-providers] /usr/lib/qgis/crssync: error while loading shared 
libraries: libhdf5_serial_hl.so.100: cannot open shared object file: No such 
file or directory
The source qgis-providers and version 3.4.8+dfsg-1 do not appear to match any 
binary packages
Ignoring request to alter found versions of bug #929887 to the same values 
previously set
> thanks
Stopping processing here.

Please contact me if you need assistance.
-- 
929887: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=929887
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems



Bug#929887: Dependencies not tightened up

2019-06-02 Thread 積丹尼 Dan Jacobson
OK,
# aptitude -t sid install qgis
fixed it. That means there are dependency issues.

Reproduce with
# cat /etc/apt/sources.list
deb ... experimental ...
deb ... unstable ...



Bug#921688: Updates

2019-06-02 Thread Antoine Amarilli
Hi,

Are there any updates on packaging a new version of electrum in Debian?

Many thanks for your work on this!

Best,

-- 
Antoine Amarilli



Bug#929887: /usr/lib/qgis/crssync: error while loading shared libraries: libhdf5_serial_hl.so.100: cannot open shared object file: No such file or directory

2019-06-02 Thread 積丹尼 Dan Jacobson
Package: qgis-providers
Version: 3.4.8+dfsg-1
Severity: critical

Setting up qgis-providers (3.4.8+dfsg-1) ...
/usr/lib/qgis/crssync: error while loading shared libraries: 
libhdf5_serial_hl.so.100: cannot open shared object file: No such file or 
directory
dpkg: error processing package qgis-providers (--configure):
 installed qgis-providers package post-installation script subprocess returned 
error exit status 127
dpkg: dependency problems prevent configuration of qgis:
 qgis depends on qgis-providers (= 3.4.8+dfsg-1); however:
  Package qgis-providers is not configured yet.



Bug#929877: installation-reports: Buster installer hangs at hard disk step with arabic language

2019-06-02 Thread Samuel Thibault
ButterflyOfFire, le dim. 02 juin 2019 15:43:41 +, a ecrit:
> >> "لاحقاً"
> 
> This word means "later" and can be replaced by "لاحقا".

That avoids the issue here indeed. I however see it used in various
places, notably in the grub installer:

msgid ""
"Warning: If the installer failed to detect another operating system that is "
"present on your computer, modifying the master boot record will make that "
"operating system temporarily unbootable, though GRUB can be manually "
"configured later to boot it."
msgstr ""
"تحذير: إن كان برنامج التثبيت قد فشل باكتشاف نظام تشغيلٍ آخر موجودٍ على حاسوبك، 
"
"فإن تعديل سجلّ الإقلاع الرّئيسي سوف يجعل نظام التّشغيل ذاك غير قابلٍ للإقلاع "
"مؤقّتاً، إلّا أنّه من الممكن تهيئة GRUB يدويّاً لإقلاعه لاحقاً."

That one however shows up without any concern, that's odd...

Samuel



Bug#929877: installation-reports: Buster installer hangs at hard disk step with arabic language

2019-06-02 Thread ButterflyOfFire
Hi,

>> "لاحقاً"

This word means "later" and can be replaced by "لاحقا".



Bug#929877: installation-reports: Buster installer hangs at hard disk step with arabic language

2019-06-02 Thread Samuel Thibault
Samuel Thibault, le dim. 02 juin 2019 17:07:04 +0200, a ecrit:
> Samuel Thibault, le dim. 02 juin 2019 16:47:49 +0200, a ecrit:
> > But it's translated along the two other pieces "The installer can guide
> > you..." and "If you choose guided..." so the issue might be in those.
> 
> It's when I add this piece that gtk starts choking. Any idea?

More precisely, it's this bit:

> "لاحقاً"

Samuel



Bug#929877: installation-reports: Buster installer hangs at hard disk step with arabic language

2019-06-02 Thread Samuel Thibault
Samuel Thibault, le dim. 02 juin 2019 16:47:49 +0200, a ecrit:
> But it's translated along the two other pieces "The installer can guide
> you..." and "If you choose guided..." so the issue might be in those.

It's when I add this piece that gtk starts choking. Any idea?

"الفرصة لاحقاً لرؤية النتائج و تخصيصها."

Samuel



Bug#929877: installation-reports: Buster installer hangs at hard disk step with arabic language

2019-06-02 Thread Samuel Thibault
Samuel Thibault, le dim. 02 juin 2019 16:44:45 +0200, a ecrit:
> Samuel Thibault, le dim. 02 juin 2019 16:33:03 +0200, a ecrit:
> > Samuel Thibault, le dim. 02 juin 2019 16:06:50 +0200, a ecrit:
> > > Samuel Thibault, le dim. 02 juin 2019 15:56:31 +0200, a ecrit:
> > > > Samuel Thibault, le dim. 02 juin 2019 15:47:28 +0200, a ecrit:
> > > > > Holger Wansing, le dim. 02 juin 2019 15:00:09 +0200, a ecrit:
> > > > > > So, that would come down to this two commits
> > > > > > (if it's a matter of arabic translations):
> > > > > > https://salsa.debian.org/installer-team/d-i/commit/1e16f41d79578a47a370c7a47ec49abdcfc7fb52
> > > > > > https://salsa.debian.org/installer-team/d-i/commit/5654defa9a4b75196e83e905465cd3aa8704c093
> > > > > 
> > > > > I tried to revert these two, but that didn't fix the issue.
> > > > 
> > > > The bug could be coming from another string, not showing up in beta5,
> > > > but showing up in rc1.
> > > 
> > > Dropping the translations of partman-auto does fix the issue for me.
> > 
> > It's this translation which breaks things up:
> > 
> > msgid "Partitioning method:"
> > msgstr "طريقة التجزئة:"
> > 
> > Any idea? :)
> 
> Mmm, putting
> 
> msgid "Partitioning method:"
> msgstr "foobar:"
> 
> there does get the issue as well...

But it's translated along the two other pieces "The installer can guide
you..." and "If you choose guided..." so the issue might be in those.

Samuel



Bug#929877: installation-reports: Buster installer hangs at hard disk step with arabic language

2019-06-02 Thread Samuel Thibault
Samuel Thibault, le dim. 02 juin 2019 16:33:03 +0200, a ecrit:
> Samuel Thibault, le dim. 02 juin 2019 16:06:50 +0200, a ecrit:
> > Samuel Thibault, le dim. 02 juin 2019 15:56:31 +0200, a ecrit:
> > > Samuel Thibault, le dim. 02 juin 2019 15:47:28 +0200, a ecrit:
> > > > Holger Wansing, le dim. 02 juin 2019 15:00:09 +0200, a ecrit:
> > > > > So, that would come down to this two commits
> > > > > (if it's a matter of arabic translations):
> > > > > https://salsa.debian.org/installer-team/d-i/commit/1e16f41d79578a47a370c7a47ec49abdcfc7fb52
> > > > > https://salsa.debian.org/installer-team/d-i/commit/5654defa9a4b75196e83e905465cd3aa8704c093
> > > > 
> > > > I tried to revert these two, but that didn't fix the issue.
> > > 
> > > The bug could be coming from another string, not showing up in beta5,
> > > but showing up in rc1.
> > 
> > Dropping the translations of partman-auto does fix the issue for me.
> 
> It's this translation which breaks things up:
> 
> msgid "Partitioning method:"
> msgstr "طريقة التجزئة:"
> 
> Any idea? :)

Mmm, putting

msgid "Partitioning method:"
msgstr "foobar:"

there does get the issue as well...

Samuel



Bug#929877: installation-reports: Buster installer hangs at hard disk step with arabic language

2019-06-02 Thread Samuel Thibault
Samuel Thibault, le dim. 02 juin 2019 16:06:50 +0200, a ecrit:
> Samuel Thibault, le dim. 02 juin 2019 15:56:31 +0200, a ecrit:
> > Samuel Thibault, le dim. 02 juin 2019 15:47:28 +0200, a ecrit:
> > > Holger Wansing, le dim. 02 juin 2019 15:00:09 +0200, a ecrit:
> > > > So, that would come down to this two commits
> > > > (if it's a matter of arabic translations):
> > > > https://salsa.debian.org/installer-team/d-i/commit/1e16f41d79578a47a370c7a47ec49abdcfc7fb52
> > > > https://salsa.debian.org/installer-team/d-i/commit/5654defa9a4b75196e83e905465cd3aa8704c093
> > > 
> > > I tried to revert these two, but that didn't fix the issue.
> > 
> > The bug could be coming from another string, not showing up in beta5,
> > but showing up in rc1.
> 
> Dropping the translations of partman-auto does fix the issue for me.

It's this translation which breaks things up:

msgid "Partitioning method:"
msgstr "طريقة التجزئة:"

Any idea? :)

Samuel



Bug#929877: installation-reports: Buster installer hangs at hard disk step with arabic language

2019-06-02 Thread Samuel Thibault
Samuel Thibault, le dim. 02 juin 2019 15:56:31 +0200, a ecrit:
> Samuel Thibault, le dim. 02 juin 2019 15:47:28 +0200, a ecrit:
> > Holger Wansing, le dim. 02 juin 2019 15:00:09 +0200, a ecrit:
> > > So, that would come down to this two commits
> > > (if it's a matter of arabic translations):
> > > https://salsa.debian.org/installer-team/d-i/commit/1e16f41d79578a47a370c7a47ec49abdcfc7fb52
> > > https://salsa.debian.org/installer-team/d-i/commit/5654defa9a4b75196e83e905465cd3aa8704c093
> > 
> > I tried to revert these two, but that didn't fix the issue.
> 
> The bug could be coming from another string, not showing up in beta5,
> but showing up in rc1.

Dropping the translations of partman-auto does fix the issue for me.

Samuel



Bug#929877: installation-reports: Buster installer hangs at hard disk step with arabic language

2019-06-02 Thread Samuel Thibault
Samuel Thibault, le dim. 02 juin 2019 15:47:28 +0200, a ecrit:
> Holger Wansing, le dim. 02 juin 2019 15:00:09 +0200, a ecrit:
> > So, that would come down to this two commits
> > (if it's a matter of arabic translations):
> > https://salsa.debian.org/installer-team/d-i/commit/1e16f41d79578a47a370c7a47ec49abdcfc7fb52
> > https://salsa.debian.org/installer-team/d-i/commit/5654defa9a4b75196e83e905465cd3aa8704c093
> 
> I tried to revert these two, but that didn't fix the issue.

The bug could be coming from another string, not showing up in beta5,
but showing up in rc1.

Samuel



Bug#927714: CVE-2019-3885 CVE-2018-16877 CVE-2018-16878

2019-06-02 Thread wferi
On Wed, 24 Apr 2019 17:50:02 +0200 wf...@niif.hu wrote:

> On Mon, 22 Apr 2019 09:07:04 +0200 Salvatore Bonaccorso  
> wrote:
> 
>>> Please see https://www.openwall.com/lists/oss-security/2019/04/17/1
>> 
>> Please note that when fixing the issues, in the original patchsets
>> there were some behaviour regressions, I think they should be adressed
>> in the followups as noted in
>> https://www.openwall.com/lists/oss-security/2019/04/18/2
> 
> After several readings of the followup you linked to I think those
> "prior behavioral changes" are the fixes themselves, that is, the more
> thorough authorization checks.  Don't you agree?

According to
https://github.com/ClusterLabs/pacemaker/pull/1750#issuecomment-494765240,
those behavioral changes are already addressed in the pull request.

> I proceeded to apply the patches in the pull request to the pacemaker
> quilt queue.  Unfortunately they introduce new symbols in libcrmcommon:
> crm_ipc_is_authentic_process and pcmk__ipc_is_authentic_process_active.
> Am I expected to update the libtool version info in light of this?

I left those internal symbols unaccounted for now, just tell if it needs
adjustment.

As per the previous comment CVE-2019-3885 does not affect 1.1.16 (the
version in stretch), so that patch was left out (you may want to
indicate this in the security tracker).  On the other hand three
followup patches fixing two bugs in the security fixes are included
based on
https://lists.clusterlabs.org/pipermail/users/2019-May/025822.html.

Here is the full glorious debdiff:

diff -Nru pacemaker-1.1.16/debian/changelog pacemaker-1.1.16/debian/changelog
--- pacemaker-1.1.16/debian/changelog   2016-12-01 14:15:23.0 +0100
+++ pacemaker-1.1.16/debian/changelog   2019-06-02 08:08:12.0 +0200
@@ -1,3 +1,35 @@
+pacemaker (1.1.16-1+deb9u1) stretch-security; urgency=high
+
+  [ Christoph Berg ]
+  * [d3d1561] Remove myself from Uploaders.
+
+  [ Ferenc Wágner ]
+  * [53a63fc] Backport upstream security fixes from pull request #1749.
+1. CVE-2018-16877: Insufficient local IPC client-server authentication
+   on the client's side can lead to local privesc.  A local attacker
+   could use this flaw, and combine it with other IPC weaknesses, to
+   achieve local privilege escalation.
+2. CVE-2018-16878: Insufficient verification inflicted preference of
+   uncontrolled processes can lead to DoS.
+The backported patch bundles were taken from
+
https://src.fedoraproject.org/rpms/pacemaker/c/f48a85ec68e299dfc53655b121e661b7c488ed71?branch=f28:
+- High-pacemakerd-vs.-IPC-procfs-confused-deputy-authentic.patch
+  (fixes CVE-2018-16877 and CVE-2018-16878)
+- Med-controld-fix-possible-NULL-pointer-dereference.patch
+  (fixes an additional problem which is more likely triggerable now that
+  the problems related to CVE-2018-16878 are avoided)
+CVE-2019-3885 does not affect Pacemaker 1.1.16, so
+High-libservices-fix-use-after-free-wrt.-alert-handl.patch is not
+included in this backport.
+Thanks to Jan Pokorný  (Closes: #927714)
+  * [fcbaaae] Acknowledge the new symbols
+  * [babde58] Backport three more patches from upstream fixing memory safety
+bugs.
+Clearing up fallout from the preceding security fixes.
+Thanks to Ken Gaillot 
+
+ -- Ferenc Wágner   Sun, 02 Jun 2019 08:08:12 +0200
+
 pacemaker (1.1.16-1) unstable; urgency=medium
 
   * [d90daf5] Refresh our patches
diff -Nru pacemaker-1.1.16/debian/control pacemaker-1.1.16/debian/control
--- pacemaker-1.1.16/debian/control 2016-12-01 14:14:42.0 +0100
+++ pacemaker-1.1.16/debian/control 2019-05-18 16:41:29.0 +0200
@@ -5,7 +5,6 @@
 Uploaders:
  Richard B Winters ,
  Ferenc Wágner ,
- Christoph Berg ,
  Adrian Vondendriesch ,
 Build-Depends:
  cluster-glue-dev,
diff -Nru pacemaker-1.1.16/debian/gbp.conf pacemaker-1.1.16/debian/gbp.conf
--- pacemaker-1.1.16/debian/gbp.conf2016-12-01 14:07:08.0 +0100
+++ pacemaker-1.1.16/debian/gbp.conf2019-05-22 11:01:26.0 +0200
@@ -1,15 +1,12 @@
 [DEFAULT]
-debian-branch = debian/master
+debian-branch = debian/stretch
 upstream-branch = upstream/latest
-debian-tag-msg = Debian release %(version)s
-
-[import-orig]
 pristine-tar = True
 
-[gbp-pq]
+[pq]
 patch-numbers = False
 
-[gbp-dch]
+[dch]
 full = True
 multimaint-merge = True
 id-length = 7
diff -Nru pacemaker-1.1.16/debian/libcrmcommon3.symbols 
pacemaker-1.1.16/debian/libcrmcommon3.symbols
--- pacemaker-1.1.16/debian/libcrmcommon3.symbols   2016-12-01 
14:14:42.0 +0100
+++ pacemaker-1.1.16/debian/libcrmcommon3.symbols   2019-05-22 
11:56:47.0 +0200
@@ -94,6 +94,7 @@
  crm_ipc_default_buffer_size@Base 1.1.11
  crm_ipc_destroy@Base 1.1.9
  crm_ipc_get_fd@Base 1.1.9
+ crm_ipc_is_authentic_process@Base 1.1.16-1+deb9u1~
  crm_ipc_name@Base 1.1.9
  crm_ipc_new@Base 1.1.9
  crm_ipc_prepare@Base 1.1.9
@@ -292,6 +293,7 @@
  parse_date@Base 1.1.9
  parse_op_key@Base 1.1.9
  

Bug#929877: installation-reports: Buster installer hangs at hard disk step with arabic language

2019-06-02 Thread Samuel Thibault
Holger Wansing, le dim. 02 juin 2019 15:00:09 +0200, a ecrit:
> So, that would come down to this two commits
> (if it's a matter of arabic translations):
> https://salsa.debian.org/installer-team/d-i/commit/1e16f41d79578a47a370c7a47ec49abdcfc7fb52
> https://salsa.debian.org/installer-team/d-i/commit/5654defa9a4b75196e83e905465cd3aa8704c093

I tried to revert these two, but that didn't fix the issue.

Samuel



Processed: 929850

2019-06-02 Thread Debian Bug Tracking System
Processing commands for cont...@bugs.debian.org:

> clone 929850 -1
Bug #929850 [dhelp] buildd.debian.org: possible conflict between the "dhelp" 
package and the KDE packages on debian buster
Bug 929850 cloned as bug 929882
> reassign -1 khelpcenter
Bug #929882 [dhelp] buildd.debian.org: possible conflict between the "dhelp" 
package and the KDE packages on debian buster
Bug reassigned from package 'dhelp' to 'khelpcenter'.
Ignoring request to alter found versions of bug #929882 to the same values 
previously set
Ignoring request to alter fixed versions of bug #929882 to the same values 
previously set
>
End of message, stopping processing here.

Please contact me if you need assistance.
-- 
929850: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=929850
929882: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=929882
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems



Bug#929877: installation-reports: Buster installer hangs at hard disk step with arabic language

2019-06-02 Thread Samuel Thibault
ButterflyOfFire, le dim. 02 juin 2019 12:12:04 +, a ecrit:
> Tested right now on my laptop, I cannot reproduce the bug. It seems working.
> 
> Tested with :
> kvm -cdrom /var/tmp/d-i/debian-buster-DI-rc1-amd64-netinst.iso -drive 
> file=blip -m 1G

Hum :/

I tried to rebuild partman-base without the arabic translation, and I'm
still getting the issue, so it's not something in there but somewhere
else.

Just to be sure, I put 4G of memory, with the same result.

I also tried two dozens other languages and scripts, only Arabic gave me
the issue.

Samuel



Processed: severity of 929867 is important

2019-06-02 Thread Debian Bug Tracking System
Processing commands for cont...@bugs.debian.org:

> severity 929867 important
Bug #929867 [src:linux] linux-image-4.19.0-5-amd64: Kernel hangs at Boot, 
ACPI=off kinda workaround
Severity set to 'important' from 'critical'
> thanks
Stopping processing here.

Please contact me if you need assistance.
-- 
929867: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=929867
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems



Bug#929877: installation-reports: Buster installer hangs at hard disk step with arabic language

2019-06-02 Thread Holger Wansing
While ButterflyOfFire reported to be unable to reproduce this, I can indeed
reproduce this with qemu here.
Looking more closely, that bug is there for me with the rc1 installer, however 
not with the alpha5 one.

So, that would come down to this two commits
(if it's a matter of arabic translations):
https://salsa.debian.org/installer-team/d-i/commit/1e16f41d79578a47a370c7a47ec49abdcfc7fb52
https://salsa.debian.org/installer-team/d-i/commit/5654defa9a4b75196e83e905465cd3aa8704c093


@ButterflyOfFire:
is there something eye-catching problematic with one of these changings?


Holger


-- 
Holger Wansing 
PGP-Fingerprint: 496A C6E8 1442 4B34 8508  3529 59F1 87CA 156E B076



Bug#906144: mypaint: Unable to install MyPaint when Gimp 2.10 is installed

2019-06-02 Thread Jacob Nevins
I wrote:
> There's a patch (to mypaint rather than libmypaint) to resolve the
> conflict without a new version of mypaint, by renaming mypaint's locale
> to 'mypaint12', in the upstream tracker at
> .
> 
> This is the approach previously suggested by Chris Waters in
> .
> 
> I haven't tested it myself, but it looks plausible.

I have now tested this patch on my Buster system. It appears to work.

What needs to happen next, to fix this in Buster? I probably won't be
able to upload to the Debian archive myself.

Now that we have a simple and apparently workable solution, should the
buster-ignore tag be removed from #906144, to make this an RC bug once
again?

=-=-=-=-=-
What I did, in detail:

Starting with buster's mypaint_1.2.0-4.1, I added the above patch
verbatim to the debian/patches stack, updated debian/changelog, and
built new binary packages. I didn't have to make any changes.

Starting with buster's libmypaint_1.3.0-2.1, I simply edited
debian/control to remove the Conflicts:

--- debian/control  2019-02-09 11:22:40.0 +
+++ ../../libmypaint-1.3.0/debian/control   2019-06-02 12:50:07.776325535 
+0100
@@ -59,7 +59,7 @@
 Architecture: all
 Multi-Arch: foreign
 Depends: ${misc:Depends},
-Conflicts: mypaint-data
+Conflicts: mypaint-data (<< 1.2.0-4.1jtn1)
 Description: brush library for mypaint - common files
  MyPaint is a pressure- and tilt-sensitive painting program which works well
  with Wacom graphics tablets and other similar devices. It comes with a large

(that version being the name I gave to my local mypaint build)
and updated debian/changelog and built new local binary packages.

Before installing, I verified that my mypaint-data and libmypaint-common
binary packages no longer had any files in common (where the buster
packages have a lot of .mo files in common).

Testing:

I started with GIMP (and hence buster's libmypaint_1.3.0-2.1) installed.
Before changing anything, I had a quick play with GIMP's "MyPaint
brushes" feature, which I'm not familiar with. (It doesn't seem to have
any brushes by default, but I was able to scribble.)

I installed my new local libmypaint and libmypaint-common packages (the
ones GIMP uses), and verified there was no change in GIMP's behaviour as
far as I could tell.

I installed my new local mypaint and mypaint-data packages. They
installed fine. MyPaint runs and appears functional.
I have an en_GB locale, and MyPaint talks about "colour" rather than
"color", so I infer that the .mo files are installed correctly.



Bug#929877: installation-reports: Buster installer hangs at hard disk step with arabic language

2019-06-02 Thread Samuel Thibault
Samuel Thibault, le dim. 02 juin 2019 13:00:51 +0200, a ecrit:
> Cc-ing debian-l10n-arabic because they can perhaps look at the partman
> translation files and check that there is nothing odd in the file (e.g.
> odd ligatures or such odd thing that might disturb gtk).

I forgot to mention that I tried in Persian and didn't have the issue,
so that confirms that there is probably something in the Arabic
translation which triggers a bug in gtk.

> While doing some tests, I noticed that when running the installer in
> arabic language, the hard disk detection step hangs. To reproduce:
> 
> - dd < /dev/zero > blip bs=1M count=1 seek=1
> - kvm -cdrom /var/tmp/d-i/debian-buster-DI-rc1-amd64-netinst.iso -drive 
> file=blip -m 2G
> - Select the graphical installer
> - Select the arabic language
> - Select that you don't care that not everything is translated
> - Select everything by default except typing non-empty passwords and
>   user name
> 
> The partman packages get loaded but the installer remains stuck at the
> attached screenshot. /var/log/syslog does not provide more information
> than what we get when doing all the same in English. The ongoing
> processes showing up in ps are
> 
> udpkg --configure --force-configure partman-base
> /var/lib/dpkg/info/partman-base.postinst configure
> /bin/partman
> parted_server
> /lib/partman/display.d/10initial_auto
> 
> Switching to VT4 to see the log then going back to VT5 shows a fully
> gray screen, so I guess it's the gtk frontend which is somehow stuck due
> to something in the arabic translation?
> 
> I tried today's weekly build, with the same result (the only difference
> being that it doesn't warn that not everything is translated).
> 
> Samuel
> 
> -- Package-specific info:
> 
> Boot method: CD
> Image version: debian-buster-DI-rc1-amd64-netinst.iso
> 
> Machine: kvm
> 
> 
> Base System Installation Checklist:
> [O] = OK, [E] = Error (please elaborate below), [ ] = didn't try it
> 
> Initial boot:   [O]
> Detect network card:[O]
> Configure network:  [O]
> Detect CD:  [O]
> Load installer modules: [O]
> Clock/timezone setup:   [O]
> User/password setup:[O]
> Detect hard drives: [E]
> Partition hard drives:  [ ]
> Install base system:[ ]
> Install tasks:  [ ]
> Install boot loader:[ ]
> Overall install:[ ]
> 
> 
> -- 
> 
> Please make sure that the hardware-summary log file, and any other
> installation logs that you think would be useful are attached to this
> report. Please compress large files using gzip.
> 
> Once you have filled out this report, mail it to sub...@bugs.debian.org.



Bug#929877: installation-reports: Buster installer hangs at hard disk step with arabic language

2019-06-02 Thread ButterflyOfFire
Hi,
Tested right now on my laptop, I cannot reproduce the bug. It seems working.

Tested with :
kvm -cdrom /var/tmp/d-i/debian-buster-DI-rc1-amd64-netinst.iso -drive file=blip 
-m 1G

Salutations,



Bug#929877: installation-reports: Buster installer hangs at hard disk step with arabic language

2019-06-02 Thread Samuel Thibault
Package: installation-reports
Severity: serious
Justification: prevents from installing at all in arabic language

Hello,

Cc-ing debian-l10n-arabic because they can perhaps look at the partman
translation files and check that there is nothing odd in the file (e.g.
odd ligatures or such odd thing that might disturb gtk).


While doing some tests, I noticed that when running the installer in
arabic language, the hard disk detection step hangs. To reproduce:

- dd < /dev/zero > blip bs=1M count=1 seek=1
- kvm -cdrom /var/tmp/d-i/debian-buster-DI-rc1-amd64-netinst.iso -drive 
file=blip -m 2G
- Select the graphical installer
- Select the arabic language
- Select that you don't care that not everything is translated
- Select everything by default except typing non-empty passwords and
  user name

The partman packages get loaded but the installer remains stuck at the
attached screenshot. /var/log/syslog does not provide more information
than what we get when doing all the same in English. The ongoing
processes showing up in ps are

udpkg --configure --force-configure partman-base
/var/lib/dpkg/info/partman-base.postinst configure
/bin/partman
parted_server
/lib/partman/display.d/10initial_auto

Switching to VT4 to see the log then going back to VT5 shows a fully
gray screen, so I guess it's the gtk frontend which is somehow stuck due
to something in the arabic translation?

I tried today's weekly build, with the same result (the only difference
being that it doesn't warn that not everything is translated).

Samuel

-- Package-specific info:

Boot method: CD
Image version: debian-buster-DI-rc1-amd64-netinst.iso

Machine: kvm


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

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


-- 

Please make sure that the hardware-summary log file, and any other
installation logs that you think would be useful are attached to this
report. Please compress large files using gzip.

Once you have filled out this report, mail it to sub...@bugs.debian.org.


Bug#929846: firefox: Fails to load https sites after today's upgrade to 67.0-3

2019-06-02 Thread jim_p
Package: firefox
Version: 67.0-3
Followup-For: Bug #929846

I was expecting 67.0-4 to reach the repos soon, since the bug was closed
earlier today.
Instead, all I got was an upgrade to libnss3 which downgraded it from 3.44 to
3.42.1 as seen in apt's output

Unpacking libnss3:amd64 (2:3.44+really3.42.1-1) over (2:3.44-1) ...

And the issue on firefox has returned. So I have 2 options as it seems, while I
wait for 67.0-4 to finally reach the repos for amd64
a) use the forementioned config switch in firefox itself or
b) use libnss3 3.44, which is now on experimental

Why was libnss3 downgraded? All it did was to break a perfectrly working
package.

p.s. Please do not say "you use unstable, you should be familiar with
situations like these".


[/rant]



-- Package-specific info:

-- Extensions information
Name: Firefox Monitor
Location: /usr/lib/firefox/browser/features/fxmoni...@mozilla.org.xpi
Package: firefox
Status: enabled

Name: Firefox Screenshots
Location: /usr/lib/firefox/browser/features/screensh...@mozilla.org.xpi
Package: firefox
Status: user-disabled

Name: Form Autofill
Location: /usr/lib/firefox/browser/features/formautof...@mozilla.org.xpi
Package: firefox
Status: enabled

Name: uBlock Origin
Location: ${PROFILE_EXTENSIONS}/ublo...@raymondhill.net.xpi
Status: enabled

Name: Video DownloadHelper
Location: ${PROFILE_EXTENSIONS}/{b9db16a4-6edc-47ec-a1f4-b86292ed211d}.xpi
Status: enabled

Name: Web Compat
Location: /usr/lib/firefox/browser/features/webcom...@mozilla.org.xpi
Package: firefox
Status: enabled

Name: WebCompat Reporter
Location: /usr/lib/firefox/browser/features/webcompat-repor...@mozilla.org.xpi
Package: firefox
Status: user-disabled

-- Plugins information
Name: Shockwave Flash (32.0.0.192)
Location: /usr/lib/flashplayer-mozilla/libflashplayer.so
Package: flashplayer-mozilla
Status: disabled


-- Addons package information
ii  firefox 67.0-3amd64Mozilla Firefox web 
browser
ii  flashplayer-mozilla 3:32.0.0.192-dmo2 amd64Adobe Flash Player

-- System Information:
Debian Release: 10.0
  APT prefers testing
  APT policy: (990, 'testing'), (500, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 4.19.0-5-amd64 (SMP w/2 CPU cores)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US:en (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages firefox depends on:
ii  debianutils   4.8.6.1
ii  fontconfig2.13.1-2
ii  libasound21.1.8-1
ii  libatk1.0-0   2.30.0-2
ii  libc6 2.28-10
ii  libcairo-gobject2 1.16.0-4
ii  libcairo2 1.16.0-4
ii  libdbus-1-3   1.12.12-1
ii  libdbus-glib-1-2  0.110-4
ii  libevent-2.1-62.1.8-stable-4
ii  libffi6   3.2.1-9
ii  libfontconfig12.13.1-2
ii  libfreetype6  2.9.1-3
ii  libgcc1   1:8.3.0-6
ii  libgdk-pixbuf2.0-02.38.1+dfsg-1
ii  libglib2.0-0  2.58.3-1
ii  libgtk-3-03.24.5-1
ii  libjsoncpp1   1.7.4-3
ii  libnspr4  2:4.21-1
ii  libnss3   2:3.44+really3.42.1-1
ii  libpango-1.0-01.42.4-6
ii  libsqlite3-0  3.27.2-2
ii  libstartup-notification0  0.12-6
ii  libstdc++68.3.0-6
ii  libvpx5   1.7.0-3
ii  libx11-6  2:1.6.7-1
ii  libx11-xcb1   2:1.6.7-1
ii  libxcb-shm0   1.13.1-2
ii  libxcb1   1.13.1-2
ii  libxcomposite11:0.4.4-2
ii  libxdamage1   1:1.1.4-3+b3
ii  libxext6  2:1.3.3-1+b2
ii  libxfixes31:5.0.3-1
ii  libxrender1   1:0.9.10-1
ii  libxt61:1.1.5-1+b3
ii  procps2:3.3.15-2
ii  zlib1g1:1.2.11.dfsg-1

Versions of packages firefox recommends:
ii  libavcodec58  10:4.1.3-dmo1

Versions of packages firefox suggests:
pn  fonts-lmodern  
pn  fonts-stix | otf-stix  
ii  libcanberra0   0.30-7
ii  libgssapi-krb5-2   1.17-2
ii  libgtk2.0-02.24.32-3
pn  pulseaudio 

-- no debconf information



Processed: your mail

2019-06-02 Thread Debian Bug Tracking System
Processing commands for cont...@bugs.debian.org:

> severity 885818 important
Bug #885818 [src:alltray] alltray: Depends on gconf
Severity set to 'important' from 'serious'
>
End of message, stopping processing here.

Please contact me if you need assistance.
-- 
885818: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=885818
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems



Bug#929867: linux-image-4.19.0-5-amd64: Kernel hangs at Boot, ACPI=off kinda workaround

2019-06-02 Thread Kinky Nekoboi
Package: src:linux
Version: 4.19.37-3
Severity: critical
Justification: breaks the whole system

Please note i wrote this Bugreport from my Desktop machine so the included
system information is for the Wrong system.

My File server is driven by a ASUS KGPE-D16 + Opteron 6380 Motherboard with
coreboot.
After doing an dist-upgrade from stretch to the upcoming Buster release i
experienced an System hang at kernel load with the new kernel. Its a full
freeze right after GRUB loads the kernel.
acpi=off makes the kernel boot, but the system remains unusable as it several
sata controller are not working correctly with acpi disabled.
Booting with the old 4.9.0 Kernel as workaround works flawless and keeps my
system usable. But i guess this is nothing desired in the long term.



-- Package-specific info:
** Version:
Linux version 4.19.0-5-amd64 (debian-ker...@lists.debian.org) (gcc version 
8.3.0 (Debian 8.3.0-7)) #1 SMP Debian 4.19.37-3 (2019-05-15)

** Command line:
BOOT_IMAGE=/vmlinuz-4.19.0-5-amd64 root=/dev/mapper/thanatos--vg-root ro quiet 
iomem=relaxed

** Not tainted

** Kernel log:
Unable to read kernel log; any relevant messages should be attached

** Model information
sys_vendor: ASUS
product_name: F2A85-M
product_version: 1.0
chassis_vendor: ASUS
chassis_version: 
bios_vendor: coreboot
bios_version: 4.9-1334-gdb3f0e3ebd-dirty
board_vendor: ASUS
board_name: F2A85-M
board_version: 1.0

** Loaded modules:
nls_utf8
cifs
ccm
dns_resolver
fscache
fuse
nft_chain_route_ipv4
xt_CHECKSUM
nft_chain_nat_ipv4
ipt_MASQUERADE
nf_nat_ipv4
nf_nat
xt_conntrack
ipt_REJECT
nf_reject_ipv4
xt_tcpudp
nft_compat
tun
bridge
stp
llc
devlink
cpufreq_userspace
cpufreq_powersave
cpufreq_conservative
binfmt_misc
xfs
snd_hda_codec_hdmi
snd_hda_codec_realtek
snd_hda_codec_generic
nft_counter
edac_mce_amd
joydev
kvm_amd
ccp
snd_hda_intel
rng_core
snd_hda_codec
kvm
snd_hda_core
snd_hwdep
snd_pcm
irqbypass
snd_timer
k10temp
sp5100_tco
snd
soundcore
sg
evdev
nft_ct
pcc_cpufreq
nf_conntrack
acpi_cpufreq
nf_defrag_ipv6
nf_defrag_ipv4
nf_tables_set
nf_tables
parport_pc
ppdev
nfnetlink
lp
parport
ip_tables
x_tables
autofs4
ext4
crc16
mbcache
jbd2
fscrypto
ecb
btrfs
xor
zstd_decompress
zstd_compress
xxhash
raid6_pq
libcrc32c
crc32c_generic
algif_skcipher
af_alg
dm_crypt
dm_mod
hid_generic
usbhid
hid
sd_mod
nouveau
crct10dif_pclmul
crc32_pclmul
crc32c_intel
ghash_clmulni_intel
pcbc
ohci_pci
mxm_wmi
wmi
video
ahci
i2c_algo_bit
libahci
ttm
r8169
libata
drm_kms_helper
realtek
aesni_intel
libphy
aes_x86_64
crypto_simd
cryptd
glue_helper
drm
ohci_hcd
xhci_pci
scsi_mod
xhci_hcd
i2c_piix4
ehci_pci
ehci_hcd
usbcore
e1000e
usb_common
button

** PCI devices:
00:00.0 Host bridge [0600]: Advanced Micro Devices, Inc. [AMD] Family 15h 
(Models 10h-1fh) Processor Root Complex [1022:1410]
Subsystem: Advanced Micro Devices, Inc. [AMD] Family 15h (Models 
10h-1fh) Processor Root Complex [1022:1410]
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B- DisINTx-
Status: Cap- 66MHz+ UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- 
SERR- TAbort- SERR- 

00:02.0 PCI bridge [0604]: Advanced Micro Devices, Inc. [AMD] Family 15h 
(Models 10h-1fh) Processor Root Port [1022:1412] (prog-if 00 [Normal decode])
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B- DisINTx+
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- TAbort- Reset- FastB2B-
PriDiscTmr- SecDiscTmr- DiscTmrStat- DiscTmrSERREn-
Capabilities: 
Kernel driver in use: pcieport

00:04.0 PCI bridge [0604]: Advanced Micro Devices, Inc. [AMD] Family 15h 
(Models 10h-1fh) Processor Root Port [1022:1414] (prog-if 00 [Normal decode])
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B- DisINTx+
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- TAbort- Reset- FastB2B-
PriDiscTmr- SecDiscTmr- DiscTmrStat- DiscTmrSERREn-
Capabilities: 
Kernel driver in use: pcieport

00:10.0 USB controller [0c03]: Advanced Micro Devices, Inc. [AMD] FCH USB XHCI 
Controller [1022:7812] (rev 03) (prog-if 30 [XHCI])
Subsystem: Advanced Micro Devices, Inc. [AMD] FCH USB XHCI Controller 
[1022:7812]
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B- DisINTx+
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- 
Kernel driver in use: xhci_hcd
Kernel modules: xhci_pci

00:10.1 USB controller [0c03]: Advanced Micro Devices, Inc. [AMD] FCH USB XHCI 
Controller [1022:7812] (rev 03) (prog-if 30 [XHCI])
Subsystem: Advanced Micro Devices, Inc. [AMD] FCH USB XHCI Controller 
[1022:7812]
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B- DisINTx+
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR-