Bug#875890: Please consider shipping /etc/apparmor.d/usr.sbin.mysqld from upstream

[John Winters]

Hi there,

If you look at message #30 attached to bug #875890 you'll see I have 
already documented exactly what the problem is, plus suggested a couple 
of solutions.


Cheers,
John Winters

On 09/05/2021 01:02, Otto Kekäläinen wrote:

Hello!

Apparmor for MariaDB has not seen much progress lately. I would be
happy to get contributions on this topic.

If you want to help improve MariaDB in Debian in the open source way,
you could for example:

- submit your suggestion for a fix as a Merge Request at
https://salsa.debian.org/mariadb-team/mariadb-10.5
- help with documentation/testing to improve our understanding on what
exactly the bug is about
- triage the other bugs filed against MariaDB in Debian so there is
time freed up to work on this bug

Thanks!



--
Xronos Scheduler - https://xronos.uk/
All your school's schedule information in one place.
Timetable, activities, homework, public events - the lot
Live demo at https://schedulerdemo.xronos.uk/

Bug#792778: nouveau: screen sometimes remains blank after "xset dpms force off"

[Vincent Lefevre]

On 2021-05-08 21:30:11 +0200, Salvatore Bonaccorso wrote:
> So this was more recent. I guess still present as well on a recent
> kernel?

I don't know, as nouveau became completely unusable for me and
I'm currently using the NVIDIA driver:

  https://gitlab.freedesktop.org/xorg/driver/xf86-video-nouveau/-/issues/534

> Did you got a chance to report it upstream and got some feedback?

No, but in general, there is no useful feedback from upstream
(no attempt to fix bugs).

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

Bug#988267: micropython ftbfs on at least arm64 where it built before

[Matthias Klose]

Package: src:micropython
Version: 1.14+ds-1
Severity: serious
Tags: sid bookworm

micropython ftbfs on at least arm64 where it built before:

[...]
gcc -g -O2 -ffile-prefix-map=/<>=. -fstack-protector-strong
-Wformat -Werror=format-security -I. -I../.. -Ibuild-standard
-I../../lib/mp-readline -Wall -Werror -Wextra -Wno-unused-parameter
-Wpointer-arith -Wdouble-promotion -Wfloat-conversion -std=gnu99 -DUNIX
-DFFCONF_H=\"lib/oofatfs/ffconf.h\" -DMICROPY_PY_USSL=1 -DMICROPY_SSL_MBEDTLS=1
-DMICROPY_USE_READLINE=1 -DMICROPY_PY_TERMIOS=1 -DMICROPY_PY_SOCKET=1
-DMICROPY_PY_THREAD=1 -DMICROPY_PY_THREAD_GIL=0  -DMICROPY_PY_FFI=1
-I/usr/lib/jvm/default-java/include -I/usr/lib/jvm/default-java/include/linux
-DMICROPY_PY_JNI=1 -Os -DNDEBUG -fdata-sections -ffunction-sections
-Ivariants/standard -Wdate-time -D_FORTIFY_SOURCE=2 -g -O2
-ffile-prefix-map=/<>=. -fstack-protector-strong -Wformat
-Werror=format-security -g -U _FORTIFY_SOURCE
-DMICROPY_QSTR_EXTRA_POOL=mp_qstr_frozen_const_pool -DMICROPY_MODULE_FROZEN_MPY
-DMPZ_DIG_SIZE=16  -DMICROPY_MODULE_FROZEN_STR -c -MD -o
build-standard/modmachine.o modmachine.c
main.c: In function ‘main_’:
main.c:595:22: error: variable ‘subpkg_tried’ might be clobbered by ‘longjmp’ or
‘vfork’ [-Werror=clobbered]
  595 | bool subpkg_tried = false;
  |  ^~~~
CC modos.c
gcc -g -O2 -ffile-prefix-map=/<>=. -fstack-protector-strong
-Wformat -Werror=format-security -I. -I../.. -Ibuild-standard
-I../../lib/mp-readline -Wall -Werror -Wextra -Wno-unused-parameter
-Wpointer-arith -Wdouble-promotion -Wfloat-conversion -std=gnu99 -DUNIX
-DFFCONF_H=\"lib/oofatfs/ffconf.h\" -DMICROPY_PY_USSL=1 -DMICROPY_SSL_MBEDTLS=1
-DMICROPY_USE_READLINE=1 -DMICROPY_PY_TERMIOS=1 -DMICROPY_PY_SOCKET=1
-DMICROPY_PY_THREAD=1 -DMICROPY_PY_THREAD_GIL=0  -DMICROPY_PY_FFI=1
-I/usr/lib/jvm/default-java/include -I/usr/lib/jvm/default-java/include/linux
-DMICROPY_PY_JNI=1 -Os -DNDEBUG -fdata-sections -ffunction-sections
-Ivariants/standard -Wdate-time -D_FORTIFY_SOURCE=2 -g -O2
-ffile-prefix-map=/<>=. -fstack-protector-strong -Wformat
-Werror=format-security -g -U _FORTIFY_SOURCE
-DMICROPY_QSTR_EXTRA_POOL=mp_qstr_frozen_const_pool -DMICROPY_MODULE_FROZEN_MPY
-DMPZ_DIG_SIZE=16  -DMICROPY_MODULE_FROZEN_STR -c -MD -o build-standard/modos.o
modos.c
CC moduos_vfs.c
gcc -g -O2 -ffile-prefix-map=/<>=. -fstack-protector-strong
-Wformat -Werror=format-security -I. -I../.. -Ibuild-standard
-I../../lib/mp-readline -Wall -Werror -Wextra -Wno-unused-parameter
-Wpointer-arith -Wdouble-promotion -Wfloat-conversion -std=gnu99 -DUNIX
-DFFCONF_H=\"lib/oofatfs/ffconf.h\" -DMICROPY_PY_USSL=1 -DMICROPY_SSL_MBEDTLS=1
-DMICROPY_USE_READLINE=1 -DMICROPY_PY_TERMIOS=1 -DMICROPY_PY_SOCKET=1
-DMICROPY_PY_THREAD=1 -DMICROPY_PY_THREAD_GIL=0  -DMICROPY_PY_FFI=1
-I/usr/lib/jvm/default-java/include -I/usr/lib/jvm/default-java/include/linux
-DMICROPY_PY_JNI=1 -Os -DNDEBUG -fdata-sections -ffunction-sections
-Ivariants/standard -Wdate-time -D_FORTIFY_SOURCE=2 -g -O2
-ffile-prefix-map=/<>=. -fstack-protector-strong -Wformat
-Werror=format-security -g -U _FORTIFY_SOURCE
-DMICROPY_QSTR_EXTRA_POOL=mp_qstr_frozen_const_pool -DMICROPY_MODULE_FROZEN_MPY
-DMPZ_DIG_SIZE=16  -DMICROPY_MODULE_FROZEN_STR -c -MD -o
build-standard/moduos_vfs.o moduos_vfs.c
cc1: all warnings being treated as errors

Bug#988266: wrapsrv FTCBFS: builds for the build architecture

[Helmut Grohne]

Source: wrapsrv
Version: 1.0.0-1
Tags: patch
User: debian-cr...@lists.debian.org
Usertags: ftcbfs

wrapsrv fails to cross build from source, because it does not pass cross
tools to make. The easiest way of doing so - using dh_auto_build - makes
wrapsrv cross buildable. Please consider applying the attached patch.

Helmut
diff --minimal -Nru wrapsrv-1.0.0/debian/changelog 
wrapsrv-1.0.0/debian/changelog
--- wrapsrv-1.0.0/debian/changelog  2014-07-30 23:27:59.0 +0200
+++ wrapsrv-1.0.0/debian/changelog  2021-05-09 06:45:40.0 +0200
@@ -1,3 +1,10 @@
+wrapsrv (1.0.0-1.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix FTCBFS: Let dh_auto_build pass cross tools to make. (Closes: #-1)
+
+ -- Helmut Grohne   Sun, 09 May 2021 06:45:40 +0200
+
 wrapsrv (1.0.0-1) unstable; urgency=medium
 
   * New upstream release:
diff --minimal -Nru wrapsrv-1.0.0/debian/rules wrapsrv-1.0.0/debian/rules
--- wrapsrv-1.0.0/debian/rules  2014-07-30 23:27:59.0 +0200
+++ wrapsrv-1.0.0/debian/rules  2021-05-09 06:45:39.0 +0200
@@ -3,7 +3,7 @@
 
 build:
dh_testdir
-   $(MAKE)
+   dh_auto_build
 
 clean: 
dh_testdir

Bug#988265: bls-standalone FTCBFS: builds for the build architecture

[Helmut Grohne]

Source: bls-standalone
Version: 0.20151231
Tags: patch
User: debian-cr...@lists.debian.org
Usertags: ftcbfs

bls-standalone fails to cross build from source, because it builds for
the build architecture. The standard solution - using dh_auto_build -
does not just work here, because bls-standalone invokes the built
"compile" utility, which is also installed into the package. Given the
small package size and few Build-Depends, a good solution is building
the package twice in this case: Once for running compile for the build
architetcure and then a second time for installing the files. The
compile utility seems to have architecture-independent output. Please
consider applying the attached patch.

Helmut
diff --minimal -Nru bls-standalone-0.20151231/debian/changelog 
bls-standalone-0.20151231+nmu1/debian/changelog
--- bls-standalone-0.20151231/debian/changelog  2015-12-31 20:11:55.0 
+0100
+++ bls-standalone-0.20151231+nmu1/debian/changelog 2021-05-09 
06:38:03.0 +0200
@@ -1,3 +1,10 @@
+bls-standalone (0.20151231+nmu1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix FTCBFS: Build twice. (Closes: #-1)
+
+ -- Helmut Grohne   Sun, 09 May 2021 06:38:03 +0200
+
 bls-standalone (0.20151231) unstable; urgency=low
 
   * Initial release.
diff --minimal -Nru bls-standalone-0.20151231/debian/rules 
bls-standalone-0.20151231+nmu1/debian/rules
--- bls-standalone-0.20151231/debian/rules  2015-12-31 20:11:25.0 
+0100
+++ bls-standalone-0.20151231+nmu1/debian/rules 2021-05-09 06:38:01.0 
+0200
@@ -4,6 +4,7 @@
 #export DH_VERBOSE=1
 export DEB_BUILD_MAINT_OPTIONS=hardening=+all
 
+include /usr/share/dpkg/architecture.mk
 include /usr/share/dpkg/buildflags.mk
 
 CFLAGS += -Wall
@@ -16,6 +17,10 @@
$(MAKE) -C scan CFLAGS='$(CFLAGS)' CPPFLAGS='$(CPPFLAGS)' 
LDFLAGS='$(LDFLAGS)'
scan/compile -o rules/rules.compiled rules/*.description rules/*.switch
sed -e "s!^\(lib\|share\)dirdefault *= *'[^']*' *#.*!\1dirdefault = 
'/usr/\1/bls-standalone'!" bls-standalone.py > bls-standalone
+ifneq ($(DEB_BUILD_ARCH),$(DEB_HOST_ARCH))
+   dh_auto_clean --sourcedirectory=scan
+   dh_auto_build --sourcedirectory=scan -- CFLAGS='$(CFLAGS)' 
CPPFLAGS='$(CPPFLAGS)' LDFLAGS='$(LDFLAGS)'
+endif
touch $@
 
 build-arch build: build-arch-stamp

Bug#987777: Linux enabled user namespaces by default

[Justin B Rye]

Paul Gevers wrote:
> Attached commit ready to push.

Looks good to me.
-- 
JBR with qualifications in linguistics, experience as a Debian
sysadmin, and probably no clue about this particular package

Bug#987659: release-notes: redmine not available, please wait backports

[Justin B Rye]

Paul Gevers wrote:
> Attached commit ready to push.

This one needs a bit of work:

> +
> +  
> +  redmine missing in bullseye
> +  
> + redmine is
> + unfortunately late migrating over to newer  + role="package">rails version despite end of
> + upstream support soon (currently only severe security
> + fixes). In Debian we had to update  + role="package">rails for other applications thus
> + redmine is not
> + provided in bullseye. The Ruby Extras

This needs a couple of English fixes, but I think more importantly it
ought to start by stating the user-visible problem:

The package redmine is
not provided in bullseye, as it was too late migrating over from
the old version of rails
which is at the end of upstream support (receiving fixes for
severe security bugs only) to the version which is in bullseye.

> + Maintainers are following upstream closely and will be
> + releasing a version via  + url="https://backports.debian.org/backports;>backports
> + as soon as it is released and they have working packages. Until
> + then you may wait before upgrading, or use a VM or container
> + running buster to isolate this specific application.
> +  
> +
> +

The "You may wait before" bit doesn't work; how about:

If you can't wait for this to happen before upgrading, you can
use a VM or container running buster to isolate this specific
application.
-- 
JBR with qualifications in linguistics, experience as a Debian
sysadmin, and probably no clue about this particular package

Bug#982468: [Pkg-fonts-devel] Bug#982468: fonts-noto-color-emoji: U+1F52B PISTOL shows a water-spraying toy instead

[Jeremy Bicha]

On Sat, May 8, 2021 at 11:15 AM Adam Borowski  wrote:
> I'm thinking, what if we had a separate package with a fontconfig override
> that corrects this glyph?

I am not interested in that. This package is offered to Debian users
for interoperable human communication among people running a variety
of systems. I don't see a benefit in offering this (rare) variation to
Debian (and derivatives) only since most emoji users do not run
Debian-based systems.

If this isn't satisfactory, you'll need to try to get changes made
upstream. You could ask Unicode to add a new glyph for when a water
pistol just isn't adequate. (But you might not want to tell the
maintainers their opinions are "nasty" or assume that the status quo
is just a US viewpoint.)

Thanks,
Jeremy Bicha

Bug#977427: mariadb-10.5: bullseye: /updates -> -security

[Otto Kekäläinen]

Control: tags -1 pending upstream confirmed

Upstream closed the issue
https://github.com/mroonga/mroonga/issues/353 by removing the file.

Will close the issue once MariaDB imports latest Mroonga and the this
file is no longer part of MariaDB sources either:
  storage/mroonga/tools/travis/install.sh

Bug#988263: Add application/manifest+json mime type for .webmanifest ext

[Lioric]

Package: mime-support
Version: 3.66
Severity: wishlist
X-Debbugs-Cc: mugen...@gmail.com

Please consider including "application/manifest+json" for ".webmanifest" file 
extension, 
as this mime type is the recommended type for serving manifest files for the 
new PWA web application spec[1]
that replaces the deprecated[2] "application cache" (that used the 
"text/cache-manifest" mime type that is currently included in mime.types file)

[1]https://developer.mozilla.org/en-US/docs/Tools/Application/Manifests#deploying_a_manifest
[2]https://developer.mozilla.org/en-US/docs/Web/HTML/Using_the_application_cache

Best regards,

Lioric


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

Kernel: Linux 5.8.0-3-amd64 (SMP w/8 CPU threads)
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) (ignored: LC_ALL 
set to en_US.UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages mime-support depends on:
ii  mailcap  3.69
ii  media-types  4.0.0

mime-support recommends no packages.

mime-support suggests no packages.

Bug#988220: aptitude: documentation improvements

[Christoph Anton Mitterer]

Another thing which is IMO not clear:

When formatting the output of a search via -F, what do %O and %t relate
to? The Origin/Archive of the installed version or of the canditate
version? (Seems to be the later I guess, though %t gives "now" if
obsolet?)

Bug#988262: auto-apt-proxy: the busybox gateway code is never executed even with busybox installed

[Joe Krisch]

Package: auto-apt-proxy

Version: 13.1

Severity: normal



The test "busybox ip >/dev/null 2>&1;" doesn't appear to ever be true and
the busybox gateway code is skipped whether or not busybox is installed and
it would work.

"busybox ip route list >/dev/null 2>&1;" does work as well as "busybox true
>/dev/null 2>&1;"

I tried this both within a docker container and outside.

Updating that line to either busybox ip route or busybox true got things
working.


-- System Information:

Debian Release: bullseye/sid

  APT prefers testing

  APT policy: (500, 'testing')

Architecture: amd64 (x86_64)


Kernel: Linux 5.4.0-72-generic (SMP w/4 CPU threads)

Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE

Locale: LANG=C, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set

Shell: /bin/sh linked to /bin/dash

Init: unable to detect


Versions of packages auto-apt-proxy depends on:

ii  apt  2.2.2


Versions of packages auto-apt-proxy recommends:

ii  busybox  1:1.30.1-6+b1


auto-apt-proxy suggests no packages.


-- no debconf information

Bug#988261: librsvg2-2: Please drop libcroco3 dependency on alpha, hppa, m68k, sh4, x32

[Vasyl Gello]

Package: librsvg2-2
Version: 2.40.20-3
Severity: important
Tags: ftbfs
Justification: fails to build from source (but built successfully in the past)
X-Debbugs-Cc: jrt...@jrtc27.com, mat...@debian.org

Dear colleagues,

I encountered the gone dependency of lubrsvg2-2 on libcroco3 doing the test 
build
of Kodi 19.1 on x32. Please rebuild librsvg without libcroco3 on the ports.

Vasyl

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

Kernel: Linux 5.4.0-72-generic (SMP w/6 CPU threads)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=C, LC_CTYPE=C (charmap=UTF-8) (ignored: LC_ALL set to 
en_US.UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: unable to detect

Versions of packages librsvg2-2 depends on:
ii  libc62.31-12
pn  libcairo-gobject2
pn  libcairo2
ii  libgcc-s110.2.1-6
pn  libgdk-pixbuf-2.0-0  
ii  libglib2.0-0 2.66.8-1
pn  libpango-1.0-0   
pn  libpangocairo-1.0-0  
ii  libxml2  2.9.10+dfsg-6.6

Versions of packages librsvg2-2 recommends:
pn  librsvg2-common  

Versions of packages librsvg2-2 suggests:
pn  librsvg2-bin  

Bug#988260: guix: GNOME sessions crash with mismatched glib-2.0 schemas

[Vagrant Cascadian]

Package: guix
Version: 1.2.0-4
Severity: important
Control: submitter -1 Diane Trout 
X-Debbugs-Cc: Diane Trout 

The original history for this bug is in https://bugs.debian.org/985916
and this bug is caused by fixing that one... though it really stands as
it's own issue.

On 2021-04-08, Diane Trout wrote:
> As an update with the /etc/profiles.d/guix.sh update at some point my GNOME
> Desktop crashed and wouldn't restart.
>
> gnome-shell was dying with this error message
> "Settings schema 'org.gnome.desktop.peripherals.touchpad' does not contain a
> key named 'tap-button-map'"
>
> extracted from the stack trace.
>
> #0  g_log_structured_array (log_level=, fields=0x7fffc50d5f90,
> n_fields=4) at ../../../glib/gmessages.c:554
> #1  0x7f3fbdc560b5 in g_log_default_handler
> (log_domain=log_domain@entry=0x7f3fbded28f8 "GLib-GIO",
> log_level=log_level@entry=6,
> message=message@entry=0x7f3fac020d80 "Settings schema
> 'org.gnome.desktop.peripherals.touchpad' does not contain a key named 'tap-
> button-map'", unused_data=unused_data@entry=0x0) at
> ../../../glib/gmessages.c:3123
> #2  0x7f3fbdc56309 in g_logv (log_domain=0x7f3fbded28f8 "GLib-GIO",
> log_level=G_LOG_LEVEL_ERROR, format=,
> args=) at ../../../glib/gmessages.c:1350
> ...
>
> What I eventually figured out was there were glib-2.0 settings installed into
> my .guix-profile probably from installing the guix's graphical version of 
> emacs
> and that version is older than what's being used by Debian and gnome is very
> cranky about this.

This of course, only happens if you install packages into your profile
that conflict with what is installed via dpkg, so setting this bug as
important severity.


> I disabled automatically activating my user level .guix-profile, while still
> adding the pulled guix command by adding a return in /etc/profile.d/guix.sh.

> Is there a way to limit the guix-profile changes to just interactive shells?

I suspect that is tricker...

> And does the desktop startup only use the non-interactive shell configuration?

I *think* so.


live well,
  vagrant


signature.asc
Description: PGP signature

Bug#988252: calibre: Calibre will not mount from CIFS share since buster.

[Norbert Preining]

tags 988252 + moreinfo
severity 988252 normal
thanks

On Sat, 08 May 2021, Jonathan Hutchins wrote:
> Version: 3.39.1+dfsg-3

   

Current calibre version is about 5.17, so we cannot really work on bugs
on this version.

Please check/verify whether this still applies in testing/unstable and
let us know.

Thanks

Norbert

--
PREINING Norbert  https://www.preining.info
Fujitsu Research  +  IFMGA Guide  +  TU Wien  +  TeX Live  + Debian Dev
GPG: 0x860CDC13   fp: F7D8 A928 26E3 16A1 9FA0 ACF0 6CAC A448 860C DC13

Bug#977178: [debian-mysql] Bug#977178: mariadb-plugin-rocksdb: Server crashes in rocksdb on startup on pmull on some ARM CPUs

[Otto Kekäläinen]

Hello!

If you want to help improve MariaDB in Debian in the open source way,
you could for example:

- submit your suggestion for a fix as a Merge Request at
https://salsa.debian.org/mariadb-team/mariadb-10.5
- help with documentation/testing to improve our understanding on what
exactly the bug is about
- triage the other bugs filed against MariaDB in Debian so there is
time freed up to work on this bug

Since you already have the steps to reproduce this, it would be quite
easy for you to extend our current MariaDB autopkgtests in Debian to
run this, and then if RocksDB fails to work, it would be detected
automatically.

The changes would come into the file
https://salsa.debian.org/mariadb-team/mariadb-10.5/-/blob/master/debian/tests/smoke

Thanks!

On Sat, 12 Dec 2020 at 02:15, Michal Povinsky  wrote:
>
> > Can you please help out and try to produce a repeatable test case to
> > trigger this bug?
>
> I managed to reproduce the issue in a KVM virtual machine running on a
> Raspberry Pi 4.
> The detail I was missing was having to restart the server twice after
> creating a rocksdb table.
> I believe it should be possible to reproduce the issue on an emulated
> VM, but I couldn't find a way to configure CPU features in QEMU as
> required.
>
> -- Check that crc32 is supported, but pmull isn't.
> root@armtest:~# grep Features /proc/cpuinfo
> Features: fp asimd evtstrm crc32 cpuid
>
> root@armtest:~# apt-get install mariadb-plugin-rocksdb
> root@armtest:~# mysql <<< "CREATE DATABASE a; USE a; CREATE TABLE a
> (id INT PRIMARY KEY) ENGINE=ROCKSDB; INSERT INTO a VALUES (1);"
> root@armtest:~# mysql <<< "SELECT * FROM a.a;"
> -- This returns correct results
>
> root@armtest:~# systemctl restart mysql
> root@armtest:~# mysql <<< "SELECT * FROM a.a;"
> -- Restart mysql once, everything still works
>
> root@armtest:~# systemctl restart mysql
> Job for mariadb.service failed because a fatal signal was delivered to
> the control process.
> See "systemctl status mariadb.service" and "journalctl -xe" for details.
> -- But the second restart fails!



-- 
- Otto

Bug#977114: [debian-mysql] Bug#977114: mariadb-server doesn't start in the ppc64el autopkgtest environment

[Otto Kekäläinen]

Control: tags -1 moreinfo

Hello!

I don't have bandwidth or ideas to investigate this.

If you want to help improve MariaDB in Debian in the open source way,
you could for example:

- submit your suggestion for a fix as a Merge Request at
https://salsa.debian.org/mariadb-team/mariadb-10.5
- help with documentation/testing to improve our understanding on what
exactly the bug is about
- triage the other bugs filed against MariaDB in Debian so there is
time freed up to work on this bug

Thanks!

On Fri, 11 Dec 2020 at 10:21, Paul Gevers  wrote:
>
> Hi,
>
> On Fri, 11 Dec 2020 00:55:21 +0100 Gennaro Oliva
>  wrote:
> > Package: mariadb-server-10.5
> > Version: 1:10.5.8-3
> >
> > When I install mariadb-server and mariadb-client in the autopkgtest
> > environment on the ppc64el architecture, the mariadb service fails to
> > start.
> >
> > Please see this failed test log:
> >
> > https://ci.debian.net/data/autopkgtest/testing/ppc64el/s/slurm-wlm/8577097/log.gz
>
> To be fair, that doesn't happen most of the cases, but it seems a bit
> flaky. See e.g.
> https://ci.debian.net/packages/c/cacti/testing/ppc64el/
>
> Paul
>
> ___
> pkg-mysql-maint mailing list
> pkg-mysql-ma...@alioth-lists.debian.net
> https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-mysql-maint



-- 
- Otto

Bug#975911: [debian-mysql] Bug#975911: Bug#975911: mariadb-client: appears to ignore ~/.editrc keybind settings

[Otto Kekäläinen]

This issue has not seen any progress.

If you want to help improve MariaDB in Debian in the open source way,
you could for example:

- submit your suggestion for a fix as a Merge Request at
https://salsa.debian.org/mariadb-team/mariadb-10.5
- help with documentation/testing to improve our understanding on what
exactly the bug is about
- triage the other bugs filed against MariaDB in Debian so there is
time freed up to work on this bug

Thanks!

On Thu, 26 Nov 2020 at 12:03, Otto Kekäläinen  wrote:
>
> Thanks for reporting and debugging this. There are no libedit related 
> customizations in the Debian packaging, so I suggest you report this upstream 
> at jira.mariadb.org, where upstream devs might have some input into this.
>
> Otto
> ___
> pkg-mysql-maint mailing list
> pkg-mysql-ma...@alioth-lists.debian.net
> https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-mysql-maint



-- 
- Otto

Bug#984997: [debian-mysql] Bug#984997: Bug#984997: Bug#984997: mariadb-server-10.5: database password passed in cleartext both on commandline and in environment

[Otto Kekäläinen]

Hello!

If this was fixed in some Galera release, please let me know.

I did not see any Forwarded: line in
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=984997

On Tue, 16 Mar 2021 at 00:18, Olaf van der Spek  wrote:
>
> On Mon, Mar 15, 2021 at 2:33 PM  wrote:
> > Speaking of environment, AFAIK on modern systems it can be read only by
> > sufficiently privileged user, so I don't see how it is less secure than
> > a file (which will have to have the same permissions as
> > /proc//environ). Could you elaborate how is it less secure than
> > using --defaults-extra-file?
>
> Environment data 'leaks' easier than file contents.
> For example, when developing / debugging, one could easily copy/paste
> all environment data, including the password (by accident), and post
> it online when asking for help.
>
> ___
> pkg-mysql-maint mailing list
> pkg-mysql-ma...@alioth-lists.debian.net
> https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-mysql-maint



-- 
- Otto

Bug#937234: pam-python: Python2 removal in sid/bullseye

[Mike Gabriel]

Hi Russel,

On  Do 06 Mai 2021 12:21:28 CEST, Russell Stuart wrote:


On 6/5/21 12:55 am, Dominik George wrote:
@Mike, @Petter: Did you realise that pam-python is AGPL? It means  
that we cannot provide terminal servers or netbooting in Debian Edu  
without placing a prominent link to pam-python's sources on the  
desktop…


Err, no.  The requirement is [0]:

  Notwithstanding any other provision of this License, if you modify the
  Program, your modified version must prominently offer all users
  interacting with it remotely through a computer network (if your
  version supports such interaction) an opportunity to receive the
  Corresponding Source of your version by providing access to the
  Corresponding Source from a network server at no charge, through some
  standard or customary means of facilitating copying of software.

I packaged it.  I can assure you it wasn't modified.


That is not the point. E.g., if we spot a security issue with a  
package, maybe you as the maintainer / upstream developer (afaik, you  
are upstream and downstream for pam-python, Russel, right?) but also  
maybe someone in the security team (or any other third person) might  
apply a fix to the package and do an e.g. stable-security upload.


Then Debian ships a modified version of the original upstream release  
and with your way of reasoning, the package won't be compiant to the  
AGPL license anymore.


So, this "it-is-not-modified-I-can-assure-you" argument is not well  
applicable to Debian packages shipping AGPL'ed code in general. It  
works in case of libpam-python, but well, see above...



That aside, I don't think mentioning somewhere it is based on Debian,
mentioning Debian's values and perhaps with a link to www.debian.org for
more information is a bad idea.  That covers all source, nor just
pam-python.


No, see my previous mail for more details. Debian offers a very  
standardized way of obtaining the exact source code that the  
libpam-python bin:pkg has been built from. Period. Done. License  
compliance accomplished.



@Russell: Can you please relicence pam-python under a less insane licence?


I honestly can't see why an having "About" page somewhere is a problem.
 Hell, even Android does it, and it lists every licence Android uses
(but with nowhere near the thoroughness Debian policy insists on in its
"copyright" file).  And Android doesn't use the AGPL.  Surely, if
proprietary distributions can do that, we (Debian) can ensure there is a
link somewhere to www.debian.org, and a mention of open source and what
that means.  The rest, like being able to download the source, follows.

As for python3 support - it probably works now.  But I don't have tests
for it.  I'm a bit anal about tests - but that's likely the only  
holdup.  However, it won't be done for bullseye.  It will be done  
for Bookworm.


I'd say, let's leave the license as it is for bullseye, because it  
works for software shipped via Debian.


For projects using libpam-python via e.g. PyPi, things might be  
differrent. For e.g. software being obtained e.g. as snap packages,  
libpam-python would cause problems (because snaps can't always be  
easily traced back to the original source code they were built from).


Furthermore, I agree with Nik, that AGPL for a non-web project (as  
that's where AGPL really makes sense) is disputable and you don't  
loose anything if you switch over to GPL-3+ instead of AGPL-3+.


Feedback? Comments?

Mike
--

DAS-NETZWERKTEAM
c\o Technik- und Ökologiezentrum Eckernförde
Mike Gabriel, Marienthaler Str. 17, 24340 Eckernförde
mobile: +49 (1520) 1976 148
landline: +49 (4351) 850 8940

GnuPG Fingerprint: 9BFB AEE8 6C0A A5FF BF22  0782 9AF4 6B30 2577 1B31
mail: mike.gabr...@das-netzwerkteam.de, http://das-netzwerkteam.de



pgpM7OwbjzDYm.pgp
Description: Digitale PGP-Signatur

Bug#976147: [debian-mysql] Bug#976147: Bug#976147: Upgrade from mariadb-server-10.3 to mariadb-server-10.5 fails

[Otto Kekäläinen]

Hello!

If you want to help improve MariaDB in Debian in the open source way,
you could for example:

- submit your suggestion for a fix as a Merge Request at
https://salsa.debian.org/mariadb-team/mariadb-10.5
- help with documentation/testing to improve our understanding on what
exactly the bug is about
- triage the other bugs filed against MariaDB in Debian so there is
time freed up to work on this bug

Thanks!

Bug#875890: Please consider shipping /etc/apparmor.d/usr.sbin.mysqld from upstream

[Otto Kekäläinen]

Hello!

Apparmor for MariaDB has not seen much progress lately. I would be
happy to get contributions on this topic.

If you want to help improve MariaDB in Debian in the open source way,
you could for example:

- submit your suggestion for a fix as a Merge Request at
https://salsa.debian.org/mariadb-team/mariadb-10.5
- help with documentation/testing to improve our understanding on what
exactly the bug is about
- triage the other bugs filed against MariaDB in Debian so there is
time freed up to work on this bug

Thanks!

Bug#861553: [debian-mysql] Bug#861553: Bug#861553: Bug#861553: Bug#861553: Please enable numa support

[Otto Kekäläinen]

Hello!

If you want to help with getting numa support on MariaDB, please file
a MR at https://salsa.debian.org/mariadb-team/mariadb-10.5 or provide
more information/documentation or help with testing, thanks!

Bug#977137: [debian-mysql] Bug#977137: mariadb-server: Mariadb-server kept back on apt upgrade

[Otto Kekäläinen]

Control: tags -1 moreinfo

Hello!

If you want to help improve MariaDB in Debian in the open source way,
you could for example:

- submit your suggestion for a fix as a Merge Request at
https://salsa.debian.org/mariadb-team/mariadb-10.5
- help with documentation/testing to improve our understanding on what
exactly the bug is about
- triage the other bugs filed against MariaDB in Debian so there is
time freed up to work on this bug

Thanks!


On Fri, 11 Dec 2020 at 08:31, Otto Kekäläinen  wrote:
>
> We test the Debian 10 -> Debian 11 upgrade in
> https://salsa.debian.org/mariadb-team/mariadb-10.5/-/jobs/1222976
>
> Source: 
> https://salsa.debian.org/mariadb-team/mariadb-10.5/-/blob/master/debian/salsa-ci.yml#L201-226
>
> Would you like to contribute by extending the salsa-ci.yml to test for
> the upgrade scenario you have which is not yet covered by the existing
> tests?



--
- Otto

Bug#937234: pam-python: Python2 removal in sid/bullseye

[Mike Gabriel]

Hi Nik, hi all,

On  Mi 05 Mai 2021 16:55:06 CEST, Dominik George wrote:


@Mike, @Petter: Did you realise that pam-python is AGPL? It means that
we cannot provide terminal servers or netbooting in Debian Edu without
placing a prominent link to pam-python's sources on the desktop…


I think that tricky bit from AGPL is this:

```
13. Remote Network Interaction; Use with the GNU General Public License.

Notwithstanding any other provision of this License, if you modify the  
Program, your modified version must prominently offer all users  
interacting with it remotely through a computer network (if your  
version supports such interaction) an opportunity to receive the  
Corresponding Source of your version by providing access to the  
Corresponding Source from a network server at no charge, through some  
standard or customary means of facilitating copying of software. [...]


[...]
```

IMHO, any binary package in Debian that has been built from AGPL  
licensed source code portions, complies with the demands postulated by  
the AGPL Remote Network Interaction clause. Debian has a very  
'standard [...] means of facilitating copying of software': the Debian  
package archive and esp. the provisioning of matching source packages  
and their binary counterparts.


So, from my point of view, no real need to worry. Feedback? Comments?

Greets,
Mike


--

DAS-NETZWERKTEAM
c\o Technik- und Ökologiezentrum Eckernförde
Mike Gabriel, Marienthaler Str. 17, 24340 Eckernförde
mobile: +49 (1520) 1976 148
landline: +49 (4351) 850 8940

GnuPG Fingerprint: 9BFB AEE8 6C0A A5FF BF22  0782 9AF4 6B30 2577 1B31
mail: mike.gabr...@das-netzwerkteam.de, http://das-netzwerkteam.de



pgpA1lNDREYxz.pgp
Description: Digitale PGP-Signatur

Bug#988259: unblock: usrmerge/25

[Marco d'Itri]

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

Please unblock package usrmerge

[ Reason ]
Adds a new translation and removes years-dead code.

[ Impact ]
Spanish users will miss the translation for a package which is going to 
be used to upgrade all Debian systems.

[ Tests ]
I do not believe that this package can be automatically tested.

[ Risks ]
Not really.

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

[ Other info ]
(Anything else the release team should know.)

unblock usrmerge/25

-- 
ciao,
Marco
diff -Nru usrmerge-24/debian/changelog usrmerge-25/debian/changelog
--- usrmerge-24/debian/changelog	2021-01-16 06:02:21.0 +0100
+++ usrmerge-25/debian/changelog	2021-04-27 01:21:48.0 +0200
@@ -1,3 +1,12 @@
+usrmerge (25) unstable; urgency=medium
+
+  * Remove prerm, which has not been needed or even possibly used since
+usrmerge version 19 started removing /etc/dpkg/dpkg.cfg.d/usrmerge on
+upgrades. (Closes: #982867)
+  * New debconf translation(s): es. (Closes: #987519)
+
+ -- Marco d'Itri   Tue, 27 Apr 2021 01:21:48 +0200
+
 usrmerge (24) unstable; urgency=medium
 
   * Moved the scripts to /usr/lib/usrmerge/ on request of Ubuntu for better
diff -Nru usrmerge-24/debian/po/es.po usrmerge-25/debian/po/es.po
--- usrmerge-24/debian/po/es.po	1970-01-01 01:00:00.0 +0100
+++ usrmerge-25/debian/po/es.po	2021-04-27 01:17:21.0 +0200
@@ -0,0 +1,54 @@
+# usrmerge po-debconf translation to Spanish.
+# Copyright (C) 2021
+# This file is distributed under the same license as the usrmerge package.
+# Camaleón , 2021.
+#
+msgid ""
+msgstr ""
+"Project-Id-Version: usrmerge\n"
+"Report-Msgid-Bugs-To: usrme...@packages.debian.org\n"
+"POT-Creation-Date: 2016-02-12 03:06+0100\n"
+"PO-Revision-Date: 2021-04-14 08:41+0200\n"
+"Last-Translator: Camaleón \n"
+"Language-Team: Debian Spanish \n"
+"Language: es\n"
+"MIME-Version: 1.0\n"
+"Content-Type: text/plain; charset=UTF-8\n"
+"Content-Transfer-Encoding: 8bit\n"
+
+#. Type: title
+#. Description
+#: ../usrmerge.templates:1001
+msgid "Automatic conversion to merged /usr"
+msgstr "Conversión automática a /usr combinado"
+
+#. Type: boolean
+#. Description
+#: ../usrmerge.templates:2001
+msgid ""
+"Do you want to convert this system to the merged /usr directories scheme?"
+msgstr ""
+"¿Desea configurar este sistema para usar el esquema de directorios "
+"combinados /usr?"
+
+#. Type: boolean
+#. Description
+#: ../usrmerge.templates:2001
+msgid ""
+"The usrmerge package will automatically convert the system to the merged /"
+"usr directory scheme, in which the /{bin,sbin,lib}/ directories are "
+"symlinked to their counterparts in /usr/."
+msgstr ""
+"El paquete usrmerge ajustará automáticamente el sistema para utilizar "
+"un esquema de directorios combinados /usr, en el que los directorios "
+"/{bin,sbin,lib}/ están enlazados simbólicamente con sus homólogos en /usr/."
+
+#. Type: boolean
+#. Description
+#: ../usrmerge.templates:2001
+msgid ""
+"There is no automatic method to restore the precedent configuration, so "
+"there is no going back once the conversion has been started."
+msgstr ""
+"No existe un método automático para restablecer la configuración anterior, "
+"por lo que una vez iniciado el proceso de conversión, no podrá revertirlo."
diff -Nru usrmerge-24/debian/usrmerge.prerm usrmerge-25/debian/usrmerge.prerm
--- usrmerge-24/debian/usrmerge.prerm	2016-02-28 01:53:38.0 +0100
+++ usrmerge-25/debian/usrmerge.prerm	1970-01-01 01:00:00.0 +0100
@@ -1,35 +0,0 @@
-#!/bin/sh -e
-
-can_remove() {
-  dpkgconf='/etc/dpkg/dpkg.cfg.d/usrmerge'
-
-  [ -e "$dpkgconf" ] || return 0
-
-  local pkgs="$(awk '/^# [^ ]+$/ { print $2 }' $dpkgconf)"
-  [ "$pkgs" ] || return 0
-
-  local installed="$(dpkg-query --showformat='${Package}\n' --show $pkgs 2> /dev/null)"
-
-  if [ "$installed" ]; then
-cat <

signature.asc
Description: PGP signature

Bug#988258: /usr/bin/scp: Use power of two units in scp progress speed

[Alejandro Sánchez]

Package: openssh-client
Version: 1:7.9p1-10+deb10u2
Severity: important
File: /usr/bin/scp
Tags: upstream
X-Debbugs-Cc: w...@cuadernoinformatica.com

Dear Maintainer,

As it seemed to me to see in the source code the speed is calculated in power 
of two units but it is shown with the symbols of of power of 10 units. This is 
confusing. The correct thing to do would be to use the appropriate symbols: 
KiB, MiB, GiB, etc.

-- System Information:
Debian Release: 10.9
  APT prefers stable
  APT policy: (900, 'stable'), (800, 'unstable'), (500, 'stable-updates')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.19.0-16-amd64 (SMP w/4 CPU threads)
Locale: LANG=es_ES.UTF-8, LC_CTYPE=es_ES.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 openssh-client depends on:
ii  adduser   3.118
ii  dpkg  1.19.7
ii  libc6 2.31-12
ii  libedit2  3.1-20191231-2+b1
ii  libgssapi-krb5-2  1.18.3-5
ii  libselinux1   3.1-3
ii  libssl1.1 1.1.1k-1
ii  passwd1:4.5-1.1
ii  zlib1g1:1.2.11.dfsg-2

Versions of packages openssh-client recommends:
ii  xauth  1:1.0.10-1

Versions of packages openssh-client suggests:
pn  keychain  
pn  libpam-ssh
pn  monkeysphere  
pn  ssh-askpass   

-- Configuration Files:
/etc/ssh/ssh_config changed:
Host *
ForwardX11 yes
SendEnv LANG LC_*
HashKnownHosts yes
GSSAPIAuthentication yes


-- no debconf information

Bug#985981: u-boot-sunxi: please embed crust-firmware on supported platforms

[Vagrant Cascadian]

On 2021-03-27, Nicolas Boulenguez wrote:
> Once crust-firmware is available, the attached suggestion should be
> sufficient to enable it in u-boot.

> --- a/debian/control
> +++ b/debian/control
> @@ -7,6 +7,7 @@ Build-Depends:
>   arm-trusted-firmware (>= 2.4+dfsg) [arm64],
>   bc,
>   bison,
> + crust-firmware:all [arm64],
>   debhelper-compat (= 13),
>   device-tree-compiler,
>   flex,

"crust-firmware:all" is not a valid value for Build-Depends.

With the crust-firmware packaging as it stands "crust-firmware:native"
would be needed.

I think a better option would be to set "Multi-Arch: foreign" in
the crust-firmware package, and then u-boot can:

 Build-Depends: ... crust-firmware [arm64], ...

I filed a bug against crust-firmware and marked it as blocking this bug,
though it is arguably a soft block (since :native would technically
work).


Thanks for the work on getting crust-firmware into Debian! Looking
forward to integrating it into the u-boot packages!


live well,
  vagrant


signature.asc
Description: PGP signature

Bug#988257: crust-firmware: Set appropriate Multi-Arch headers

[Vagrant Cascadian]

Package: crust-firmware
Severity: normal
Tags: patch
Control: block 985981 by -1
X-Debbugs-Cc: vagr...@debian.org

crust-firmware does not set a Multi-Arch header, which complicates using
it as a build-dependency for cross builds.

I believe it should be safe to set it as "Multi-Arch: foreign":

  https://wiki.debian.org/MultiArch/Hints#set_Multi-Arch:_foreign

The attached patch adds this.

live well,
  vagrant

From e6f8b161126b039b3da8eea8b85532663a0356ce Mon Sep 17 00:00:00 2001
From: Vagrant Cascadian 
Date: Sat, 8 May 2021 15:55:31 -0700
Subject: [PATCH] debian/control: Set Multi-Arch: foreign.

This allows installation of crust-firmware when building u-boot.
---
 debian/control | 1 +
 1 file changed, 1 insertion(+)

diff --git a/debian/control b/debian/control
index 61966a9..2da5ad6 100644
--- a/debian/control
+++ b/debian/control
@@ -18,6 +18,7 @@ Vcs-Git: https://salsa.debian.org/debian/crust-firmware.git
 
 Package: crust-firmware
 Architecture: all
+Multi-Arch: foreign
 Depends: ${misc:Depends}
 Description: SCP firmware for Allwinner sunxi boards
  Some System on a Chip (SoC) computers, also known as single-board,
-- 
2.30.2



signature.asc
Description: PGP signature

Bug#981376: [debian-mysql] Bug#981376: mariadb-server-10.3: Conflicting MariaDB instance config

[Otto Kekäläinen]

Hello!

I am about to upload MariaDB 10.3.29 to Debian in the near future.

If you have a suggestion on how to fix this issue, I'd appreciate if
you submit your suggestion as a Merge Request at
https://salsa.debian.org/mariadb-team/mariadb-10.3 (or for 10.5 at
https://salsa.debian.org/mariadb-team/mariadb-10.5).

Since we inherit the systemd file from upstream, you could also in
addition (or instead) file an issue upstream or even submit a PR to
fix it at https://github.com/mariadb/server


On Sun, 31 Jan 2021 at 05:24, Jörg Delker  wrote:
>
> Am 30.01.2021 um 23:57 schrieb Otto Kekäläinen:
> > Hello!
> >
> > We are using the same mariadb@.service as upstream ships. It has not
> > been customized for Debian, so maybe you want to file this upstream?
>
> Hmm... Debian's bug guidelines deprecate that explicitly, saying that an
> issue shall not be posted here and upstream.
>  From the README.Debian I understood, that the packages provided by
> mariadb.org and Debian differ quite significantly and shall not be
> mixed. Maybe the instance-service works just fine in their environment...?
>
> > The directory /etc/mysql/conf.d/*.cnf has and always will be included
> > when parsing configuration for every server. If there is a server
> > instance that needs its own config, it should reside at some other
> > location, where other instances will not read it.
>
> I would generally agree to that. I'm not saying, that an instance must not 
> include /etc/mysql/conf.d/*.cnf,
> but if the instance service definition has it's "own config" hard-coded to 
> that directory, it becomes part of any other service instance by default.
>  From my understanding this renders the provided mariadb@.service competely 
> unusable.
>
> In fact, there are several more glitches in that service, which do not work 
> properly with a dedicated instance.
> That begins with a colliding /run dir and goes on with the invocation of the 
> debian-start script, which operates on the main server, rather than the 
> instance.
>


-- 
- Otto

Bug#988256: RM: mariadb-10.3/experimental -- RoM; obsoleted by mariadb-10.5

[Otto Kekäläinen]

Package: ftp.debian.org
Severity: normal
Affects: 975548

Hi,

Please remove src:mariadb-10.3 from experimental.

MariaDB 10.3 has been replaced by MariaDB 10.5 long ago. There still
seems to be some cruft of 10.3 in experimental.

Based on the report at
https://security-tracker.debian.org/tracker/CVE-2021-27928 there seems
to be some curft of mariadb-10.1 and mariadb-10.3 in unstable as well
as they are still tracked there. I'd appreciate it if ftp-masters can
help purge old MariaDB packages from experimental and unstable.

I don't know what is the definitive source of truth on this topic and
what is the proper way to address it.

Anyway, currently we should have only MariaDB 10.5 in unstable. Older
10.4, 10.3, 10.1, 10.0 and 5.5 are obsolete since long ago.

Bug#988255: buster-pu: package mariadb-10.3 10.3.29-0+deb10u1

[Otto Kekäläinen]

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

I propose that the latest version of MariaDB 10.3 (includes security
fixes) would be included in the upcoming stable release update of
Debian. Package is almost ready at
https://salsa.debian.org/mariadb-team/mariadb-10.3

Before I submit the final changelog etc I'd like to inquire what is
the schedule of the Debian 10.10 stable update?

There is currently no entry at https://release.debian.org/ but
timewise enough time has passed since the 10.9 release so 10.10 is
maybe soon up?

Bug#988219: meson: Move package into unstable

[Jussi Pakkanen]

On Fri, 7 May 2021 at 23:15, Andrea Pappacoda  wrote:

> Since Meson 0.57.1 Meson has been only packaged for experimental, even if it 
> seems that there isn't a good reason for it. Could it please be moved to 
> unstable? This also makes updated version unavailable for Ubuntu.

Unstable is under release freeze so it can't be updated until after
the release. It will be updated immediately after the release is done.
If you want a newer version for Ubuntu, it might be possible to
request that via Ubuntu's bug tracker but I don't know what is the
policy on that.

Bug#988083: unblock: micro-evtd/3.4-6

[Cyril Brulebois]

Hi,

Emilio Pozuelo Monfort  (2021-05-07):
> On 05/05/2021 07:26, Ryan Tandy wrote:
> > [ Tests ]
> > 
> > There are no automated tests. I have been running the updated daemon for
> > a few days, and I tested an installation with the updated udeb (using a
> > d-i daily image).

I'm very happy to see this was not only build- but also run-tested.

> > [ Risks ]
> > 
> > I built the package on buster with and without the patch, to see
> > what would change. The disassembly (objdump -d) was the same before
> > and after, so I think I can be confident the header was not actually
> > used and the patch should not change its behaviour.
> > 
> > However, the package had not been rebuilt since before buster was
> > released, so there could be unknown risks arising from rebuilding
> > with the newer toolchain.
> > 
> > [ Checklist ]
> > 
> >   [✔] all changes are documented in the d/changelog
> >   [✔] I reviewed all changes and I approve them
> >   [✔] attach debdiff against the package in testing
> > 
> > [ Other info ]
> > 
> > Very low popcon. The package provides hardware support for a specific
> > subset of armel/orion5x NAS devices with few remaining users.
> > 
> > The package builds a udeb. I tested an installation using a daily d-i
> > image that includes the update.
> 
> Cyril, can you (n)ack for d-i?

Since it seems to be a package that targets specific hardware, and since
tests have been carried out on at least one such device, this looks very
fine to me.


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


signature.asc
Description: PGP signature

Bug#987701: installation-reports: installation failed on Linkstation Pro: Out of memory during partitioning

[Samuel Thibault]

Control: tags -1 + pending

Ryan Tandy, le mar. 04 mai 2021 22:00:06 -0700, a ecrit:
> lowmem=2 worked nicely. I completed an installation successfully with that
> setting. Thanks!

Ok.

> Is there anything I can do to help improve the default experience on this
> target, besides documenting for others the process to set the extra bootarg
> in the u-boot environment?

I have already commited a patch to the manual to point people at the
lowmem parameter.

Thanks for your report,
Samuel

Bug#988254: FTBFS: Missing build dependency on txt2man

[Eriberto Mota]

Control: severity 988254 normal
Control: tags 988254 moreinfo unreproducible

Em sáb., 8 de mai. de 2021 às 18:21, Wyatt Ward  escreveu:
>
> Package: axel
> Version: 2.17.10-2
> Severity: serious
> Tags: ftbfs
> Justification: fails to build from source (but built successfully in the past)
>
> Dear Maintainer,
>
> When building axel from sources (with dpkg-buildpackage), the build fails
> partway through unless txt2man is installed. txt2man is not currently listed
> under the 'Build-Depends' field in debian/control.
>
> After manually installing txt2man, the build completes normally.
>
> I was building it on my powerbook (powerpc), but have also noticed this on one
> of my amd64 machines (which I am sending this message from, hence the 'built
> successfully in the past' message).
>
> This is likely my first Debian bug report, so I apologise in advance if I did
> this wrong. I am letting 'reportbug' determine the severity but I don't
> personally see it as a huge deal. If it's actually a policy violation, then I
> guess that's why.
>
> Errors:
>
> /bin/bash: line 2: txt2man: command not found
> make[3]: *** [Makefile:1146: doc/axel.1] Error 1
> make[3]: Leaving directory '/home/wyatt/development/axel/axel-git-debian'
> make[2]: *** [Makefile:676: all-recursive] Error 1
> make[2]: Leaving directory '/home/wyatt/development/axel/axel-git-debian'
> make[1]: *** [Makefile:452: all] Error 2
> make[1]: Leaving directory '/home/wyatt/development/axel/axel-git-debian'
> dh_auto_build: error: make -j1 returned exit code 2
> make: *** [debian/rules:7: binary] Error 2
> dpkg-buildpackage: error: debian/rules binary subprocess returned exit 
> status 2


Hi Wyatt ,

Thanks for your message.

axel 2.17.10-2 arrived in unstable on 2021-04-01 and it was
successfully built by all supported architectures in Debian[1]. I did
a new check now in my jail and all right in the axel. Considering it,
I am sure the problem is on your side. Please, describe step to step
all your procedures to build, starting with the source acquisition,
and I will be able to point the cause of the failure.

[1] https://buildd.debian.org/status/package.php?p=axel

Best regards,

Eriberto

Bug#988254: FTBFS: Missing build dependency on txt2man

[Wyatt Ward]

Package: axel
Version: 2.17.10-2
Severity: serious
Tags: ftbfs
Justification: fails to build from source (but built successfully in the past)

Dear Maintainer,

When building axel from sources (with dpkg-buildpackage), the build fails
partway through unless txt2man is installed. txt2man is not currently listed
under the 'Build-Depends' field in debian/control.

After manually installing txt2man, the build completes normally.

I was building it on my powerbook (powerpc), but have also noticed this on one
of my amd64 machines (which I am sending this message from, hence the 'built
successfully in the past' message).

This is likely my first Debian bug report, so I apologise in advance if I did
this wrong. I am letting 'reportbug' determine the severity but I don't
personally see it as a huge deal. If it's actually a policy violation, then I
guess that's why.

Errors:

/bin/bash: line 2: txt2man: command not found
make[3]: *** [Makefile:1146: doc/axel.1] Error 1
make[3]: Leaving directory '/home/wyatt/development/axel/axel-git-debian'
make[2]: *** [Makefile:676: all-recursive] Error 1
make[2]: Leaving directory '/home/wyatt/development/axel/axel-git-debian'
make[1]: *** [Makefile:452: all] Error 2
make[1]: Leaving directory '/home/wyatt/development/axel/axel-git-debian'
dh_auto_build: error: make -j1 returned exit code 2
make: *** [debian/rules:7: binary] Error 2
dpkg-buildpackage: error: debian/rules binary subprocess returned exit 
status 2

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

Kernel: Linux 5.9.1-wyatt-westmere (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 /usr/bin/dash
Init: sysvinit (via /sbin/init)
LSM: AppArmor: enabled

Versions of packages axel depends on:
ii  libc6  2.30-4
ii  libssl1.1  1.1.1g-1

axel recommends no packages.

axel suggests no packages.

-- no debconf information

Bug#988224: unblock: mapserver/7.6.2-2 (pre-approval)

[Sebastiaan Couwenberg]

Control: tags -1 - moreinfo

On 5/8/21 9:18 PM, Sebastian Ramacher wrote:
> On 2021-05-08 07:29:01 +0200, Bas Couwenberg wrote:
>> Package: release.debian.org
>> Severity: normal
>> User: release.debian@packages.debian.org
>> Usertags: unblock
>>
>> Please unblock package mapserver to fix CVE-2021-32062 as reported in 
>> #988208.
>>
>> [ Reason ]
>> Fix security issue.
>>
>> [ Impact ]
>> Unfixed security issue.
>>
>> [ Tests ]
>> Upstream CI.
>>
>> [ Risks ]
>> Low, leaf package.
>>
>> [ Checklist ]
>>   [x] all changes are documented in the d/changelog
>>   [x] I reviewed all changes and I approve them
>>   [x] attach debdiff against the package in testing
>>
>> [ Other info ]
>> 0001-Use-CPLSetConfigOption-CPLGetConfigOption-for-some-C.patch is required 
>> as a dependency of 
>> 0001-Address-flaw-in-CGI-mapfile-loading-that-makes-it-po.patch.
>>
>> unblock mapserver/7.6.2-2
> 
>> diff -Nru mapserver-7.6.2/debian/changelog mapserver-7.6.2/debian/changelog
>> --- mapserver-7.6.2/debian/changelog 2020-12-09 06:01:02.0 +0100
>> +++ mapserver-7.6.2/debian/changelog 2021-05-08 07:12:18.0 +0200
>> @@ -1,3 +1,12 @@
>> +mapserver (7.6.2-2) unstable; urgency=high
>> +
>> +  * Drop unused lintian overrides.
>> +  * Add upstream patches to fix CVE-2021-32062.
>> +(closes: #988208)
>> +  * Update symbols file.
>> +
>> + -- Bas Couwenberg   Sat, 08 May 2021 07:12:18 +0200
>> +
>>  mapserver (7.6.2-1) unstable; urgency=medium
>>  
>>* Update symbols for other architectures.
>> diff -Nru mapserver-7.6.2/debian/libmapserver2.lintian-overrides 
>> mapserver-7.6.2/debian/libmapserver2.lintian-overrides
>> --- mapserver-7.6.2/debian/libmapserver2.lintian-overrides   2020-08-06 
>> 05:34:57.0 +0200
>> +++ mapserver-7.6.2/debian/libmapserver2.lintian-overrides   1970-01-01 
>> 01:00:00.0 +0100
>> @@ -1,3 +0,0 @@
>> -# Cannot easily be fixed
>> -file-references-package-build-path *
>> -
>> diff -Nru mapserver-7.6.2/debian/libmapserver2.symbols 
>> mapserver-7.6.2/debian/libmapserver2.symbols
>> --- mapserver-7.6.2/debian/libmapserver2.symbols 2020-12-09 
>> 06:00:39.0 +0100
>> +++ mapserver-7.6.2/debian/libmapserver2.symbols 2021-05-08 
>> 07:11:08.0 +0200
>> @@ -945,6 +945,7 @@
>>   msCSVJoinPrepare@Base 6.2.1
>>   msCairoCleanup@Base 6.2.1
>>   msCalculateScale@Base 6.2.1
>> + msCaseEvalRegex@Base 7.6.2
>>   msCaseReplaceSubstring@Base 6.2.1
>>   msCheckLabelMinDistance@Base 7.0.0
>>   msCheckParentPointer@Base 6.2.1
>> @@ -1418,6 +1419,7 @@
>>   msIsGlyphASpace@Base 7.2.0
>>   msIsLayerQueryable@Base 6.2.1
>>   msIsOuterRing@Base 6.2.1
>> + msIsValidRegex@Base 7.6.2
> 
> This version is not high enough. The symbols need to be marked as
> requiring 7.6.2-2~

There are no rdeps of mapserver in Debian, so no users of the symbols file.

> Please remove the moreinfo tag once that fixed version is available in
> unstable.

mapserver (7.6.2-2) has been uploaded to unstable without further
changes to the symbols file.

Kind Regards,

Bas

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

Bug#963964: release-notes: document aufs removal for bullseye

[Paul Gevers]

Hi,

Friendly ping again.

On 17-04-2021 21:05, Paul Gevers wrote:
>>> Since the kernel supports overlayfs since some time now, what blocks
>>> it's removal?
>> There are Debian installations on filesystems that are incompatible 
> with 
>> overlayfs, for example xfs without d_type.
>> I ran into this while trying to get rid of aufs.
> So we need to document this problem in the release notes.  That's an
> easy task.

>> I have no clue. Would all users of XFS know what d_type is? What are
>> their options? The question of zigo (adding d_type to to an existing xfs
>> of ftype=0 and/or conversion tool from ftype=0 to ftype=1) in 963191
>> went unanswered.

Paul



OpenPGP_signature
Description: OpenPGP digital signature

Bug#987069: document which file systems support cgroupv2 I/O controller

[Paul Gevers]

Hi Nicholas,

On 17-04-2021 20:57, Paul Gevers wrote:
> On 17-04-2021 00:35, Nicholas D Steeves wrote:
>> Last I checked, only btrfs supports the cgroupv2 I/O controller; this
>> should probably be documented.  Alternatively, if more than btrfs (ie:
>> XFS and ext4) supports it, but not other file systems (ie: f2fs,
>> reiser4, jfs, etc) than this should be documented.
>>
>> As far as I can tell, the significance of this is as follows: Buster
>> switched to mq-deadline, which does not support the idle I/O priority,
>> and to get functional ionice the user/sysadmin had to switch to the
>> non-mq CFQ, or bfq.  The situation in a default Bullseye install is
>> better, but only for file systems that support the cgroupv2 I/O
>> controller.
> 
> As I don't have much knowledge on this front, can you maybe do an actual
> proposal for text to be added? And, if you're unsure, how do we find out
> if you're right?

For this one too: friendly ping.

Paul



OpenPGP_signature
Description: OpenPGP digital signature

Bug#978043: linux-image-5.10.0-trunk-amd64: irq 7: nobody cared (ryzen 3500u)

[NG]

Hello,

Since my bugzilla kernel report was a duplicate, I added myself to the 
following CC list: 201817 

No progress at all.  I'm currently running linux 5.10.0-6-amd64 
(5.10.28-1), in a sid installation.  And also tried linux 5.12.2 with 
fedora.  And is still the same.



El 8/05/21 a las 8:00 a. m., Salvatore Bonaccorso escribió:

Hi,

On Thu, Dec 24, 2020 at 07:17:29PM -0500, Neil wrote:

Package: src:linux
Version: 5.10.2-1~exp1
Severity: minor

Dear Maintainer,

Hello there,
I just wanted to report this dmesg message here,  I already reported it to
kernel.org and redhat's bugzilla (fedora),  but who knows, maybe reporting it
here before debian 11 gets released is worth it,  I hope it doesn't bother :)

can you reference the upstream report from you? Was there any
progress, is this fixed with a recent kernel or still reproducible?

Regards,
Salvatore

Bug#987068: assert "preliminary cgroupv2 support" or fix outstanding bugs (eg: debootstrap+Docker)

[Paul Gevers]

Hi Nicholas,

On 17-04-2021 20:55, Paul Gevers wrote:
> On 17-04-2021 00:27, Nicholas D Steeves wrote:
>> It looks like Debian's Docker package has broken cgroup2 support
>> (#985481), so either that bug should be fixed, or issues.dbk (around
>> L66) should document that cgroup2 support may be broken in Docker
>> containers on Bullseye.
> 
> I fail to see what you had in mind. Can you make your proposal a bit
> more concrete? I haven't made backtracking to line 66 easier by
> reorganizing that particular file, but the only place where we discuss
> cgroups v2 is in OpenStack and that's much later.

Vriendly ping.

Paul



OpenPGP_signature
Description: OpenPGP digital signature

Bug#988253: mmdebstrap: Ways to keep apt Packages files

[Vagrant Cascadian]

Package: mmdebstrap
Version: 0.7.5-2
Severity: wishlist
X-Debbugs-Cc: vagr...@debian.org

I cannot seem to find a straightforward option to keep apt Packages
files in /var/lib/apt/lists/ ...

If I use --skip=cleanup/apt it does keep the Packages files in
/var/lib/apt/lists, but also leaves the .deb files in /var/cache/apt/,
which is largely undesireable for several use-cases.

Using --customize-hook to run apt-get update occurs after the cleanup
steps are run...

I guess this wouldn't be too bad (untested):

  mmdebstrap ...
  --skip=cleanup/apt \
  --customize-hook='chroot "$1" apt-get clean'

But then maybe cleanup/apt might someday implement some other feature I
might miss out on by doing this...


If it doesn't make sense to implement this as a specific option in
mmdebstrap, at least documenting options to achieve this seems
appropriate.  I can see several use-cases where you might want the
Packages files to stay around while cleaning the .deb files from the
cache (e.g. sbuild, creating an OS image or live image).


Thanks so much for mmdebstrap; a very nice tool!


live well,
  vagrant


signature.asc
Description: PGP signature

Bug#987777: Linux enabled user namespaces by default

[Paul Gevers]

Control: tags -1 patch confirmed

Hi

Attached commit ready to push.

Paul
From 2c36e76427bdf94d8e46138cb76c7b64414b5ddd Mon Sep 17 00:00:00 2001
From: Paul Gevers 
Date: Sat, 8 May 2021 21:52:43 +0200
Subject: [PATCH] issues.dbk: Linux enables user namespaces by default

---
 en/issues.dbk | 32 
 1 file changed, 32 insertions(+)

diff --git a/en/issues.dbk b/en/issues.dbk
index fb6682bd..b8506867 100644
--- a/en/issues.dbk
+++ b/en/issues.dbk
@@ -272,6 +272,38 @@ password [success=1 default=ignore] pam_unix.so obscure yescrypt
   
 
 
+
+  Linux enables user namespaces by default
+  
+From Linux 5.10, all users are allowed to
+create user namespaces by default. This will allow programs
+such as web browsers and container managers to create more
+restricted sandboxes for untrusted or less-trusted code,
+without the need to run as root or to use a setuid-root
+helper.
+  
+  
+The previous Debian default was to restrict this feature to
+processes running as root, because it exposed more security
+issues in the kernel. However, as the implementation of this
+feature has matured, we are now confident that the risk of
+enabling it is outweighed by the security benefits it
+provides.
+  
+  
+If you prefer to keep this feature restricted, set the sysctl:
+  
+  
+kernel.unprivileged_userns_clone = 0
+  
+  
+	Note that various desktop and container features will not work
+	with this restriction in place, including web browsers,
+	WebKitGTK, Flatpak and
+	GNOME thumbnailing.
+  
+
+
 
   Things to do post upgrade before rebooting
   
-- 
2.30.2



OpenPGP_signature
Description: OpenPGP digital signature

Bug#988221: xterm: uses unescaped backslashes in manpage example

[Thorsten Glaser]

Thomas Dickey dixit:

>The example is correct, however.  xterm's manpage isn't a tutorial
>on shell programming.

Yes and yes, but it’s still over-microoptimised, in a way that is
not helpful to users.

bye,
//mirabilos
-- 
FWIW, I'm quite impressed with mksh interactively. I thought it was much
*much* more bare bones. But it turns out it beats the living hell out of
ksh93 in that respect. I'd even consider it for my daily use if I hadn't
wasted half my life on my zsh setup. :-) -- Frank Terbeck in #!/bin/mksh

Bug#790660: Closing this bug (BTS maintenance for src:linux bugs)

[chrysn]

> If you can reproduce it with
> 
> - the current version in unstable/testing
> - the latest kernel from backports
>
> please reopen the bug, see https://www.debian.org/Bugs/server-control
> for details.

Micha, can you? I don't have that hardware around any more.

BR
chrysn


signature.asc
Description: PGP signature

Bug#987659: release-notes: redmine not available, please wait backports

[Paul Gevers]

Control: tags -1 patch confirmed

Hi,

Attached commit ready to push.

Paul
From df46043fcb61e35455c9d300cdbc9cdad223a73e Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Marc=20Dequ=C3=A8nes=20=28duck=29?= 
Date: Sat, 8 May 2021 21:29:32 +0200
Subject: [PATCH] issues.dbk: redmine not part of bullseye

---
 en/issues.dbk | 21 +
 1 file changed, 21 insertions(+)

diff --git a/en/issues.dbk b/en/issues.dbk
index fb6682bd..f939b54e 100644
--- a/en/issues.dbk
+++ b/en/issues.dbk
@@ -272,6 +272,27 @@ password [success=1 default=ignore] pam_unix.so obscure yescrypt
   
 
 
+
+  
+  redmine missing in bullseye
+  
+	redmine is
+	unfortunately late migrating over to newer rails version despite end of
+	upstream support soon (currently only severe security
+	fixes). In Debian we had to update rails for other applications thus
+	redmine is not
+	provided in bullseye. The Ruby Extras
+	Maintainers are following upstream closely and will be
+	releasing a version via https://backports.debian.org/backports;>backports
+	as soon as it is released and they have working packages. Until
+	then you may wait before upgrading, or use a VM or container
+	running buster to isolate this specific application.
+  
+
+
 
   Things to do post upgrade before rebooting
   
-- 
2.30.2



OpenPGP_signature
Description: OpenPGP digital signature

Bug#792778: nouveau: screen sometimes remains blank after "xset dpms force off"

[Salvatore Bonaccorso]

Control: tags -1 + moreinfo

Hi Vincent,

Sorry for continiously pestering you on older bugreports ;-)

On Wed, Sep 04, 2019 at 10:26:07PM +0200, Vincent Lefevre wrote:
> Control: reopen -1
> Control: found -1 5.2.9-2
> 
> On 2019-09-01 10:41:15 +0200, Vincent Lefevre wrote:
> > On 2015-07-18 14:52:03 +0200, Vincent Lefevre wrote:
> > > After I blank the screen of my laptop with "xset dpms force off", it
> > > is usually unblanked as expected when I type a key or move the mouse,
> > > but not always. When this occurs, the screen is no longer off, in the
> > > sense I can see some light on it, but nothing is displayed.
> > 
> > This is old, and with a few tests on the same machine after using
> > again nouveau since last night, I could not reproduce the problem
> > with a 5.2.0-2-amd64 kernel. Closing.
> 
> I could reproduce it again. Exactly the same issue.

So this was more recent. I guess still present as well on a recent
kernel? Did you got a chance to report it upstream and got some
feedback?

Regards,
Salvatore

Bug#987440: release-notes: Mention GnuPG no longer reads ~/.gnupg/options

[Justin B Rye]

Paul Gevers wrote:
> No change commit ready to push.
>  
> +
> +  
> +  gnupg2 options file
> +  
> + Starting with version 2.2.27-1, per-user configuration of the
> + GnuPG suite has completely moved to
> + ~/.gnupg/gpg.conf, and
> + ~/.gnupg/options is no longer in use.
> + Please rename the file if necessary, or move its contents to
> + the new location.
> +  
> +

We don't mean the gnupg2 (transitional) package, so maybe it should
stick to calling it GnuPG (or GnuPG 2?) in the title as well?
-- 
JBR with qualifications in linguistics, experience as a Debian
sysadmin, and probably no clue about this particular package

Bug#988252: calibre: Calibre will not mount from CIFS share since buster.

[Jonathan Hutchins]

Package: calibre
Version: 3.39.1+dfsg-3
Severity: grave
Justification: renders package unusable

Dear Maintainer,

Calibre will not mount an existing library over CIFS.  It claims that the 
library is corrupted.  This works on stretch with the backport version of 
calibre, which is the same upstream number, so I suspect that the problem may 
actually be with python.

   * What led up to the situation?
Upgrade to buster

   * What exactly did you do (or not do) that was effective (or
 ineffective)?
Attempted to track down error.  Unable to find resolution on-line


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

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

Versions of packages calibre depends on:
ii  calibre-bin  3.39.1+dfsg-3
ii  fonts-liberation 1:1.07.4-9
ii  imagemagick  8:6.9.10.23+dfsg-2.1+deb10u1
ii  imagemagick-6.q16 [imagemagick]  8:6.9.10.23+dfsg-2.1+deb10u1
ii  libjpeg-turbo-progs  1:1.5.2-2+deb10u1
ii  libjs-coffeescript   1.12.8~dfsg-4
ii  libjs-mathjax2.7.4+dfsg-1
ii  optipng  0.7.7-1
ii  poppler-utils0.71.0-5
ii  python-apsw  3.24.0-r1-1
ii  python-chardet   3.0.4-3
ii  python-cherrypy3 8.9.1-2
ii  python-css-parser1.0.4-1
ii  python-cssselect 1.0.3-1
ii  python-cssutils  1.0.2-2
ii  python-dateutil  2.7.3-3
ii  python-dbus  1.2.8-3
ii  python-feedparser5.2.1-1
ii  python-html5-parser  0.4.5-1
ii  python-html5lib  1.0.1-1
ii  python-lxml  4.3.2-1+deb10u3
ii  python-markdown  3.0.1-3
ii  python-mechanize 1:0.2.5-3
ii  python-msgpack   0.5.6-1+b1
ii  python-netifaces 0.10.4-1+b1
ii  python-pil   5.4.1-2+deb10u2
ii  python-pkg-resources 40.8.0-1
ii  python-pyparsing 2.2.0+dfsg1-2
ii  python-pyqt5 5.11.3+dfsg-1+b3
ii  python-pyqt5.qtsvg   5.11.3+dfsg-1+b3
ii  python-pyqt5.qtwebkit5.11.3+dfsg-1+b3
ii  python-regex 0.1.20190207-1
ii  python-routes2.4.1-1
ii  python2.72.7.16-2+deb10u1
ii  xdg-utils1.1.3-1+deb10u1

Versions of packages calibre recommends:
ii  python-dnspython  1.16.0-1

Versions of packages calibre suggests:
pn  python-unrardll  

-- no debconf information

Bug#988224: unblock: mapserver/7.6.2-2 (pre-approval)

[Sebastian Ramacher]

Control: tags -1 moreinfo confirmed

On 2021-05-08 07:29:01 +0200, Bas Couwenberg wrote:
> Package: release.debian.org
> Severity: normal
> User: release.debian@packages.debian.org
> Usertags: unblock
> 
> Please unblock package mapserver to fix CVE-2021-32062 as reported in #988208.
> 
> [ Reason ]
> Fix security issue.
> 
> [ Impact ]
> Unfixed security issue.
> 
> [ Tests ]
> Upstream CI.
> 
> [ Risks ]
> Low, leaf package.
> 
> [ Checklist ]
>   [x] all changes are documented in the d/changelog
>   [x] I reviewed all changes and I approve them
>   [x] attach debdiff against the package in testing
> 
> [ Other info ]
> 0001-Use-CPLSetConfigOption-CPLGetConfigOption-for-some-C.patch is required 
> as a dependency of 
> 0001-Address-flaw-in-CGI-mapfile-loading-that-makes-it-po.patch.
> 
> unblock mapserver/7.6.2-2

> diff -Nru mapserver-7.6.2/debian/changelog mapserver-7.6.2/debian/changelog
> --- mapserver-7.6.2/debian/changelog  2020-12-09 06:01:02.0 +0100
> +++ mapserver-7.6.2/debian/changelog  2021-05-08 07:12:18.0 +0200
> @@ -1,3 +1,12 @@
> +mapserver (7.6.2-2) unstable; urgency=high
> +
> +  * Drop unused lintian overrides.
> +  * Add upstream patches to fix CVE-2021-32062.
> +(closes: #988208)
> +  * Update symbols file.
> +
> + -- Bas Couwenberg   Sat, 08 May 2021 07:12:18 +0200
> +
>  mapserver (7.6.2-1) unstable; urgency=medium
>  
>* Update symbols for other architectures.
> diff -Nru mapserver-7.6.2/debian/libmapserver2.lintian-overrides 
> mapserver-7.6.2/debian/libmapserver2.lintian-overrides
> --- mapserver-7.6.2/debian/libmapserver2.lintian-overrides2020-08-06 
> 05:34:57.0 +0200
> +++ mapserver-7.6.2/debian/libmapserver2.lintian-overrides1970-01-01 
> 01:00:00.0 +0100
> @@ -1,3 +0,0 @@
> -# Cannot easily be fixed
> -file-references-package-build-path *
> -
> diff -Nru mapserver-7.6.2/debian/libmapserver2.symbols 
> mapserver-7.6.2/debian/libmapserver2.symbols
> --- mapserver-7.6.2/debian/libmapserver2.symbols  2020-12-09 
> 06:00:39.0 +0100
> +++ mapserver-7.6.2/debian/libmapserver2.symbols  2021-05-08 
> 07:11:08.0 +0200
> @@ -945,6 +945,7 @@
>   msCSVJoinPrepare@Base 6.2.1
>   msCairoCleanup@Base 6.2.1
>   msCalculateScale@Base 6.2.1
> + msCaseEvalRegex@Base 7.6.2
>   msCaseReplaceSubstring@Base 6.2.1
>   msCheckLabelMinDistance@Base 7.0.0
>   msCheckParentPointer@Base 6.2.1
> @@ -1418,6 +1419,7 @@
>   msIsGlyphASpace@Base 7.2.0
>   msIsLayerQueryable@Base 6.2.1
>   msIsOuterRing@Base 6.2.1
> + msIsValidRegex@Base 7.6.2

This version is not high enough. The symbols need to be marked as
requiring 7.6.2-2~

Please remove the moreinfo tag once that fixed version is available in
unstable.

Cheers

>   msIsXMLTagValid@Base 6.2.1
>   msItemInGroups@Base 6.2.1
>   msJoinClose@Base 6.2.1
> diff -Nru mapserver-7.6.2/debian/mapserver-bin.lintian-overrides 
> mapserver-7.6.2/debian/mapserver-bin.lintian-overrides
> --- mapserver-7.6.2/debian/mapserver-bin.lintian-overrides2020-08-06 
> 05:34:57.0 +0200
> +++ mapserver-7.6.2/debian/mapserver-bin.lintian-overrides1970-01-01 
> 01:00:00.0 +0100
> @@ -1,3 +0,0 @@
> -# Cannot easily be fixed
> -file-references-package-build-path *
> -
> diff -Nru 
> mapserver-7.6.2/debian/patches/0001-Address-flaw-in-CGI-mapfile-loading-that-makes-it-po.patch
>  
> mapserver-7.6.2/debian/patches/0001-Address-flaw-in-CGI-mapfile-loading-that-makes-it-po.patch
> --- 
> mapserver-7.6.2/debian/patches/0001-Address-flaw-in-CGI-mapfile-loading-that-makes-it-po.patch
> 1970-01-01 01:00:00.0 +0100
> +++ 
> mapserver-7.6.2/debian/patches/0001-Address-flaw-in-CGI-mapfile-loading-that-makes-it-po.patch
> 2021-05-08 07:10:49.0 +0200
> @@ -0,0 +1,161 @@
> +Description: Address flaw in CGI mapfile loading that makes it possible to 
> bypass security controls.
> +Author: Even Rouault 
> +Origin: 
> https://github.com/MapServer/MapServer/commit/927ac97cb9ece305306b5ab2b5600d3afe8c1732
> +Bug: https://github.com/MapServer/MapServer/issues/6313
> +Bug-Debian: https://bugs.debian.org/988208
> +
> +--- a/mapfile.c
>  b/mapfile.c
> +@@ -97,6 +97,16 @@ int msValidateParameter(const char *valu
> +   return(MS_FAILURE);
> + }
> + 
> ++int msIsValidRegex(const char* e) {
> ++  ms_regex_t re;
> ++  if(ms_regcomp(, e, MS_REG_EXTENDED|MS_REG_NOSUB) != 0) {
> ++msSetError(MS_REGEXERR, "Failed to compile expression (%s).", 
> "msEvalRegex()", e);
> ++return(MS_FALSE);
> ++  }
> ++  ms_regfree();
> ++  return MS_TRUE;
> ++}
> ++
> + int msEvalRegex(const char *e, const char *s)
> + {
> +   ms_regex_t re;
> +@@ -107,6 +117,26 @@ int msEvalRegex(const char *e, const cha
> + msSetError(MS_REGEXERR, "Failed to compile expression (%s).", 
> "msEvalRegex()", e);
> + return(MS_FALSE);
> +   }
> ++
> ++  if(ms_regexec(, s, 0, NULL, 0) != 0) { /* no match */
> ++ms_regfree();
> ++return(MS_FALSE);
> ++  }
> ++  ms_regfree();
> ++
> ++  return(MS_TRUE);
> ++}

Bug#789610: symlink(2) refuses to let me create an empty symlink

[Salvatore Bonaccorso]

Hi,

On Tue, Jun 23, 2015 at 01:49:23AM +0100, Ben Hutchings wrote:
> Control: reassign -1 src:linux 3.2.68-1+deb7u1
> Control: tag -1 upstream
> 
> On Mon, 2015-06-22 at 17:10 +0100, Ian Jackson wrote:
> > Package: linux-image-3.2.0-4-amd64
> > Version: 3.2.68-1+deb7u1
> > 
> > I may be tilting at windmills here, but I think
> >ln -s '' foo
> > should work, rather than failing with ENOENT.
> > 
> > The fact that it didn't work inconvenienced me while I was trying to
> > write a test case for some other software.  I would have been happy
> > for the link to be created and then be un-dereferenceable.
> > 
> > I would, in fact, have been happy with either the traditional BSD
> > behaviour (create the link, treat it as a link to "."), or the
> > traditional SysV behaviour (create the link, dereferencing gives
> > ENOENT).
> > 
> > See also:
> > 
> >   https://lwn.net/Articles/551224/
> >   https://lwn.net/Articles/551228/
> > 
> > Do you think you could try to use any good connections you have to get
> > this fixed ?
> 
> Don't hold your breath.

Given this, is if at all to be handled upstream, I think we should
close this report by now. I do not see likely that it will ongoing.

Regards,
Salvatore

Bug#987440: release-notes: Mention GnuPG no longer reads ~/.gnupg/options

[Paul Gevers]

Control: tags -1 confirmed patch

Hi,

On 23-04-2021 22:24, Christoph Biedl wrote:
>   Starting with version 2.2.27-1, per-user configuration of the GnuPG
>   suite has completely moved to ~/.gnupg/gpg.conf, and ~/.gnupg/options
>   is no longer in use.  Please rename the file if necessary, or move
>   its contents to the new location.

No change commit ready to push.

Paul
From 5fe6e3f75242e0ca32371ce103ca886ca20b0663 Mon Sep 17 00:00:00 2001
From: Christoph Biedl 
Date: Sat, 8 May 2021 21:05:35 +0200
Subject: [PATCH] issues.dbk: gnupg2 deprecated ~/.gnupg/options file

---
 en/issues.dbk | 13 +
 1 file changed, 13 insertions(+)

diff --git a/en/issues.dbk b/en/issues.dbk
index fb6682bd..4d8f141c 100644
--- a/en/issues.dbk
+++ b/en/issues.dbk
@@ -272,6 +272,19 @@ password [success=1 default=ignore] pam_unix.so obscure yescrypt
   
 
 
+
+  
+  gnupg2 options file
+  
+	Starting with version 2.2.27-1, per-user configuration of the
+	GnuPG suite has completely moved to
+	~/.gnupg/gpg.conf, and
+	~/.gnupg/options is no longer in use.
+	Please rename the file if necessary, or move its contents to
+	the new location.
+  
+
+
 
   Things to do post upgrade before rebooting
   
-- 
2.30.2



OpenPGP_signature
Description: OpenPGP digital signature

Bug#785419: Bug#855203: hwclock-set: Synchronize from hwclock despite systemd presence

[Salvatore Bonaccorso]

Control: tags -1 + moreinfo

Hi,

Ist this still an issue or has been fixed in meanwhile? I'm going
through some older src:linux associated buts and noticed that it was
considered here to reassign it to util-linux.

Is the problem still present?

Further:

On Fri, Mar 17, 2017 at 07:55:31PM +0100, Lukas Wunner wrote:
[...]
> @Rick Thomas: Could you verify if the attached patch solves this issue
> for you?

Were you able to test the proposed patch?

Regards,
Salvatore

Bug#988251: nmu: gtkglextmm_1.2.0-8

[Adrian Bunk]

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

# spurious dependency on an obsolete library
# the as-needed change in bullseye fixes it
nmu gtkglextmm_1.2.0-8 . ANY . unstable . -m "rebuild without spurious 
libpangox-1.0-0 dependency"

Bug#959170: linux: at boot: Process '/usr/sbin/alsactl ... restore 0' failed with exit code 99

[Salvatore Bonaccorso]

Hi Vincent,

On Sat, May 08, 2021 at 06:13:09PM +0200, Vincent Lefevre wrote:
> On 2021-05-08 14:54:58 +0200, Salvatore Bonaccorso wrote:
> > Is this still something you are able to reproduce and have more
> > insights since then? If you are not able to reproduce it anymore,
> > should we otherwise close the issue?
> 
> zira:~> journalctl | grep 'failed with exit code 99'
> May 18 14:40:58 zira systemd-udevd[461]: controlC1: Process 
> '/usr/sbin/alsactl -E HOME=/run/alsa -E XDG_RUNTIME_DIR=/run/alsa/runtime 
> restore 1' failed with exit code 99.
> May 18 14:43:03 zira systemd-udevd[488]: controlC1: Process 
> '/usr/sbin/alsactl -E HOME=/run/alsa -E XDG_RUNTIME_DIR=/run/alsa/runtime 
> restore 1' failed with exit code 99.
> Sep 17 14:44:13 zira systemd-udevd[452]: controlC1: Process 
> '/usr/sbin/alsactl -E HOME=/run/alsa -E XDG_RUNTIME_DIR=/run/alsa/runtime 
> restore 1' failed with exit code 99.
> Sep 18 11:22:05 zira systemd-udevd[464]: controlC0: Process 
> '/usr/sbin/alsactl -E HOME=/run/alsa -E XDG_RUNTIME_DIR=/run/alsa/runtime 
> restore 0' failed with exit code 99.
> Sep 24 10:54:58 zira systemd-udevd[452]: controlC1: Process 
> '/usr/sbin/alsactl -E HOME=/run/alsa -E XDG_RUNTIME_DIR=/run/alsa/runtime 
> restore 1' failed with exit code 99.
> Sep 24 11:01:26 zira systemd-udevd[432]: controlC1: Process 
> '/usr/sbin/alsactl -E HOME=/run/alsa -E XDG_RUNTIME_DIR=/run/alsa/runtime 
> restore 1' failed with exit code 99.
> Sep 24 11:07:31 zira systemd-udevd[456]: controlC1: Process 
> '/usr/sbin/alsactl -E HOME=/run/alsa -E XDG_RUNTIME_DIR=/run/alsa/runtime 
> restore 1' failed with exit code 99.
> Sep 24 11:09:43 zira systemd-udevd[444]: controlC1: Process 
> '/usr/sbin/alsactl -E HOME=/run/alsa -E XDG_RUNTIME_DIR=/run/alsa/runtime 
> restore 1' failed with exit code 99.
> Sep 24 11:29:22 zira systemd-udevd[449]: controlC1: Process 
> '/usr/sbin/alsactl -E HOME=/run/alsa -E XDG_RUNTIME_DIR=/run/alsa/runtime 
> restore 1' failed with exit code 99.
> Sep 24 11:30:50 zira systemd-udevd[450]: controlC1: Process 
> '/usr/sbin/alsactl -E HOME=/run/alsa -E XDG_RUNTIME_DIR=/run/alsa/runtime 
> restore 1' failed with exit code 99.
> Oct 18 23:19:30 zira systemd-udevd[462]: controlC0: Process 
> '/usr/sbin/alsactl -E HOME=/run/alsa -E XDG_RUNTIME_DIR=/run/alsa/runtime 
> restore 0' failed with exit code 99.
> Oct 18 23:20:28 zira systemd-udevd[450]: controlC0: Process 
> '/usr/sbin/alsactl -E HOME=/run/alsa -E XDG_RUNTIME_DIR=/run/alsa/runtime 
> restore 0' failed with exit code 99.
> Oct 29 02:51:50 zira systemd-udevd[452]: controlC0: Process 
> '/usr/sbin/alsactl -E HOME=/run/alsa -E XDG_RUNTIME_DIR=/run/alsa/runtime 
> restore 0' failed with exit code 99.
> Nov 30 02:44:43 zira systemd-udevd[451]: controlC1: Process 
> '/usr/sbin/alsactl -E HOME=/run/alsa -E XDG_RUNTIME_DIR=/run/alsa/runtime 
> restore 1' failed with exit code 99.
> Jan 04 21:21:29 zira systemd-udevd[458]: controlC0: Process 
> '/usr/sbin/alsactl -E HOME=/run/alsa -E XDG_RUNTIME_DIR=/run/alsa/runtime 
> restore 0' failed with exit code 99.
> Jan 22 19:54:32 zira systemd-udevd[468]: controlC0: Process 
> '/usr/sbin/alsactl -E HOME=/run/alsa -E XDG_RUNTIME_DIR=/run/alsa/runtime 
> restore 0' failed with exit code 99.
> 
> So this failure hasn't occurred for a few months, but this was already
> the case between 2020-05-18 and 2020-09-17. Thus there may still be
> some possibility that it occurs again in a few weeks.

Okay and thanks for quickly report back, much appreciated.

Regards,
Salvatore

Bug#988046: bind9: does not honor CPPFLAGS

[Ondřej Surý]

Emilio,

could you please post this to the upstream gitLab.isc.org? Ping me when you 
create the account, I will have to bump the project limit, so you can fork.

I would be happy to merge this upstream.

Fortunately, I’ve already changed the build system to use automake in the 
development branch, but it was quite an effort, so I didn’t make it in time for 
9.16, but the next stable (9.18) will be pretty standard.

Ondřej 
--
Ondřej Surý  (He/Him)

> On 4. 5. 2021, at 11:21, Emilio Pozuelo Monfort  wrote:
> 
> Package: bind9
> Severity: normal
> 
> Hi,
> 
> While doing a bind9 update for stretch LTS, Anton Gladky added a salsa
> pipeline which had a blhc (build log hardening check) test that was
> failing.
> 
> I have investigated it and found that bind9 is not using automake and while
> it tries to honor most *FLAGS variables, it ignores CPPFLAGS. The attached
> patch makes it honor CPPFLAGS, so that Debian's default flags (e.g.
> -D_FORTIFY_SOURCE=2) get passed. A small diff from the build logs:
> 
> -libtool: compile:  gcc -include /build/bind9-9.16.13/config.h 
> -I/build/bind9-9.16.13 -I../../.. -I./include -I./../unix/include 
> -I./../pthreads/include -I../include -I./../include -I./.. 
> -I/usr/include/json-c -I/usr/include/libxml2 -g -O2 
> -ffile-prefix-map=/build/bind9-9.16.13=. -fstack-protector-strong -Wformat 
> -Werror=format-security -fno-strict-aliasing -fno-delete-null-pointer-checks 
> -DNO_VERSION_DATE -DDIG_SIGCHASE -pthread -fPIC -W -Wall -Wmissing-prototypes 
> -Wcast-qual -Wwrite-strings -Wformat -Wpointer-arith 
> -Wno-missing-field-initializers -fno-strict-aliasing -c tlsdns.c -o tlsdns.o 
> >/dev/null 2>&1
> +libtool: compile:  gcc -Wdate-time -D_FORTIFY_SOURCE=2 -include 
> /build/bind9-9.16.13/config.h -I/build/bind9-9.16.13 -I../../.. -I./include 
> -I./../unix/include -I./../pthreads/include -I../include -I./../include 
> -I./.. -I/usr/include/json-c -I/usr/include/libxml2 -g -O2 
> -ffile-prefix-map=/build/bind9-9.16.13=. -fstack-protector-strong -Wformat 
> -Werror=format-security -fno-strict-aliasing -fno-delete-null-pointer-checks 
> -DNO_VERSION_DATE -DDIG_SIGCHASE -pthread -fPIC -W -Wall -Wmissing-prototypes 
> -Wcast-qual -Wwrite-strings -Wformat -Wpointer-arith 
> -Wno-missing-field-initializers -fno-strict-aliasing -c tlsdns.c -o tlsdns.o 
> >/dev/null 2>&1
> 
> I have not tested the resulting package, but it should probably be alright
> to add this after the current freeze.
> 
> Thanks,
> Emilio
> 
> -- System Information:
> Debian Release: bullseye/sid
>  APT prefers testing-security
>  APT policy: (500, 'testing-security'), (200, 'testing')
> Architecture: amd64 (x86_64)
> Foreign Architectures: i386
> 
> Kernel: Linux 5.10.0-5-amd64 (SMP w/12 CPU threads)
> Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
> TAINT_UNSIGNED_MODULE
> Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), 
> LANGUAGE=en_GB:en
> Shell: /bin/sh linked to /usr/bin/dash
> Init: systemd (via /run/systemd/system)
> LSM: AppArmor: enabled
> 
> Versions of packages bind9 depends on:
> ii  adduser3.118
> ii  bind9-libs 1:9.16.13-1
> pn  bind9-utils
> ii  debconf [debconf-2.0]  1.5.75
> ii  dns-root-data  2021011101
> ii  init-system-helpers1.60
> ii  iproute2   5.10.0-4
> ii  libc6  2.31-11
> ii  libcap21:2.44-1
> ii  libfstrm0  0.6.0-1+b1
> ii  libjson-c5 0.15-2
> ii  liblmdb0   0.9.24-1
> ii  libmaxminddb0  1.5.2-1
> ii  libprotobuf-c1 1.3.3-1+b2
> ii  libssl1.1  1.1.1k-1
> ii  libuv1 1.40.0-1
> ii  libxml22.9.10+dfsg-6.3+b1
> ii  lsb-base   11.1.0
> ii  netbase6.2
> ii  zlib1g 1:1.2.11.dfsg-2
> 
> bind9 recommends no packages.
> 
> Versions of packages bind9 suggests:
> pn  bind-doc   
> ii  bind9-dnsutils [dnsutils]  1:9.16.13-1
> ii  dnsutils   1:9.16.13-1
> pn  resolvconf 
> pn  ufw
> 

Bug#988250: golang-go.opencensus: flaky autopkgtest: timebased test causes mismatched expectation

[Paul Gevers]

Source: golang-go.opencensus
Version: 0.22.4-1
Severity: serious
Tags: sid bullseye
X-Debbugs-CC: debian...@lists.debian.org
User: debian...@lists.debian.org
Usertags: flaky

Dear maintainer(s),

Your package has an autopkgtest, great. However, because of the failure
"caused" by golang-testify, I looked into the history of your
autopkgtest [1] and I noticed it fails regularly. In all the logs I
looked at the error is the same, it happens on multiple architectures,
but I haven't seen it on amd64.

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 causing people unrelated to your package to spend time on these
tests.

Paul

[1] https://ci.debian.net/packages/g/golang-go.opencensus/testing/arm64/

https://ci.debian.net/data/autopkgtest/testing/arm64/g/golang-go.opencensus/11227933/log.gz


=== RUN   Test_Worker_MultiExport
worker_test.go:216: Mismatched value (want &{2}, got 1) for &{[{a
true}] [{2021-03-23 03:41:31.469410257 + UTC m=+1.006722755 1}]
2021-03-23 03:41:31.469373227 + UTC m=+1.006685725} in "/VF1"
worker_test.go:221: Mismatched value (want &{7.50}, got
2.00) for &{[] [{2021-03-23 03:41:31.469410257 + UTC
m=+1.006722755 2}] 2021-03-23 03:41:31.469374877 + UTC
m=+1.006687375} in "/VF2"
--- FAIL: Test_Worker_MultiExport (0.00s)



OpenPGP_signature
Description: OpenPGP digital signature

Bug#986456: chromium: Could not unzip extension on armhf

[Michael Gilbert]

control: severity -1 minor
control: forwarded -1 http://crbug.com/1060925

Daniel Thompson wrote:
> 1. Install chromium
> 2. Navigate to https://chrome.google.com/webstore
> 3. Try to install an extension (I tested primarily with bitwarden
>but I also checked a couple of "random" ones from the suggestions
>list (Zoom, Dark Mode, Visor and saw the same results).
> 4. Chromium reports "An error has occured: Could not unzip extension".

Could you try a version of chromium before 67?  This may be a known
upstream bug [0].

Best wishes,
Mike

[0] http://crbug.com/1060925

Bug#988249: golang-github-getkin-kin-openapi: flaky autopkgtest: output order changed

[Paul Gevers]

Source: golang-github-getkin-kin-openapi
Version: 0.32.0-1
Severity: serious
Tags: sid bullseye
X-Debbugs-CC: debian...@lists.debian.org
User: debian...@lists.debian.org
Usertags: flaky

Dear maintainer(s),

Your package has an autopkgtest, great. However, because of the failure
"caused" by golang-testify, I looked into the history of your
autopkgtest [1] and I noticed it fails regularly. In all the logs I
looked at the error is the same, it happens on multiple architectures.

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 causing people unrelated to your package to spend time on these
tests.

Paul

[1]

https://ci.debian.net/data/autopkgtest/testing/amd64/g/golang-github-getkin-kin-openapi/11903910/log.gz

=== RUN   TestConvOpenAPIV3ToV2
openapi2_conv_test.go:30:
Error Trace:openapi2_conv_test.go:30
Error:  Not equal:
expected: map[string]interface
{}{"basePath":"/v2", "consumes":[]interface {}{"application/json",
"application/xml"}, "definitions":map[string]interface
{}{"Error":map[string]interface {}{"description":"Error response.",
"properties":map[string]interface {}{"message":map[string]interface
{}{"type":"string"}}, "required":[]interface {}{"message"},
"type":"object"}, "Item":map[string]interface
{}{"additionalProperties":true, "properties":map[string]interface
{}{"foo":map[string]interface {}{"type":"string"},
"quux":map[string]interface {}{"$ref":"#/definitions/ItemExtension"}},
"type":"object"}, "ItemExtension":map[string]interface
{}{"description":"It could be anything.", "type":"boolean"}},
"externalDocs":map[string]interface {}{"description":"Example
Documentation", "url":"https://example/doc/"},
"host":"test.example.com", "info":map[string]interface
{}{"title":"MyAPI", "version":"0.1", "x-info":"info extension"},
"parameters":map[string]interface {}{"banana":map[string]interface
{}{"in":"path", "name":"banana", "required":true, "type":"string"},
"post_form_ref":map[string]interface {}{"description":"param
description", "in":"formData", "name":"fileUpload2", "required":true,
"type":"file", "x-formData-name":"fileUpload2",
"x-mimetype":"text/plain"}, "put_body":map[string]interface
{}{"in":"body", "name":"banana", "required":true,
"schema":map[string]interface {}{"type":"string"},
"x-originalParamName":"banana"}}, "paths":map[string]interface
{}{"/another/{banana}/{id}":map[string]interface
{}{"parameters":[]interface {}{map[string]interface
{}{"$ref":"#/parameters/banana"}, map[string]interface {}{"in":"path",
"name":"id", "required":true, "type":"integer"}}},
"/example":map[string]interface {}{"delete":map[string]interface
{}{"description":"example delete", "operationId":"example-delete",
"parameters":[]interface {}{map[string]interface {}{"in":"query",
"name":"x", "type":"string", "x-parameter":"parameter extension 1"},
map[string]interface {}{"default":250, "description":"The y parameter",
"in":"query", "maximum":1, "minimum":1, "name":"y",
"type":"integer"}, map[string]interface {}{"description":"Only return
results that intersect the provided bounding box.", "in":"query",
"items":map[string]interface {}{"type":"number"}, "maxItems":4,
"minItems":4, "name":"bbox", "type":"array"}},
"responses":map[string]interface {}{"200":map[string]interface
{}{"description":"ok", "schema":map[string]interface
{}{"items":map[string]interface {}{"$ref":"#/definitions/Item"},
"type":"array"}}, "404":map[string]interface {}{"description":"404
response"}, "default":map[string]interface {}{"description":"default
response", "x-response":"response extension 1"}}, "security":[]interface
{}{map[string]interface {}{"get_security_0":[]interface {}{"scope0",
"scope1"}, "get_security_1":[]interface {}{}}}, "summary":"example get",
"tags":[]interface {}{"Example"}}, "get":map[string]interface
{}{"description":"example get", "responses":map[string]interface
{}{"403":map[string]interface {}{"$ref":"#/responses/ForbiddenError"},
"404":map[string]interface {}{"description":"404 response"},
"default":map[string]interface {}{"description":"default response"}},
"x-operation":"operation extension 1"}, "head":map[string]interface
{}{"description":"example head", "responses":map[string]interface
{}{"default":map[string]interface {}{"description":"default
response"}}}, "options":map[string]interface {}{"description":"example
options", "responses":map[string]interface
{}{"default":map[string]interface {}{"description":"default
response"}}}, "patch":map[string]interface {}{"consumes":[]interface
{}{"application/json", "application/xml"}, "description":"example
patch", "parameters":[]interface {}{map[string]interface {}{"in":"body",
"name":"patch_body", "schema":map[string]interface
{}{"allOf":[]interface {}{map[string]interface
{}{"$ref":"#/definitions/Item"}}}, 

Bug#988167: closed by Debian FTP Masters (reply to Jelmer Vernooij ) (Bug#988167: fixed in silver-platter 0.4.2-1)

[Paul Gevers]

Hi Jelmer,

On 06-05-2021 22:51, Debian Bug Tracking System wrote:
>  silver-platter (0.4.2-1) unstable; urgency=low
>  .
>* New upstream release.
> + Fixes compatibility with Breezy 3.2. Closes: #988167

Sure, but the regression test of silver-platter fails with the old
breezy (or better said, it fails when silver-platter from unstable is
tested in testing). Is there a *versioned* (test) dependency missing?

Also, please don't upload binaries, as they are not allowed to migrate
and we can't successfully binNMU arch:all yet.

Paul



OpenPGP_signature
Description: OpenPGP digital signature

Bug#783160: update

[Salvatore Bonaccorso]

Control: tags -1 + moreinfo

Hi Ian,

On Sun, Aug 04, 2019 at 03:26:38PM +0100, Iain Learmonth wrote:
> reassign 783160 src:linux
> kthxbye
> 
> Hi,
> 
> There is definitely an issue here that I've just reproduced with the
> kernel from unstable + the latest libax25 from experimental.
> 
> I don't think it is actually ever sending these duplicate packets on the
> KISS interface, I don't see them being sent via the radio, but I do see
> duplicates (sometimes 2, sometimes 3) when using tcpdump on the ax
> interface.
> 
> The interface is set up as follows (just do this as root):
> 
> sudo apt install direwolf net-tools
> sudo apt install -t experimental libax25 ax25-tools ax25-apps
> cat > /etc/ax25/axports < radio AA1ABC 1200 255 2 test
> EOF
> cat > direwolf.conf < ADEVICE pulse
> EOF
> direwolf -p
> kissattach /dev/pts/ radio 10.0.0.2
> arp -H ax25 -i ax -s 10.0.0.3 AA2ABC
> ping -c 1 10.0.0.2
> 
> You don't need a radio plugged in but expect modem noises to come out
> your speakers, maybe turn them down first!
> 
> You'll see in direwolf that it logs a single packet going out to AA2ABC.
> If you're running tcpdump on the ax interface though, you'll see the
> packet appears 2 or 3 times.
> 
> I've reproduced this on both amd64 and i386. I'm happy to try out any
> patches or assist the upstream if that is useful.

Is this still something you can reproduce with a recent kernel or
ideally mainline upstream? If so can you please report it upstream
(and keeping the downstream bugreport in the loop?)

Regards,
Salvatore

Bug#982629: L10n upload for prometheus-smokeping-prober?

[Helge Kreutzmann]

Hello Benjamin,
shortly before the freeze you uploaded prometheus-smokeping-prober
with changed Debconf messages.

Meanwhile 5 translations have arrived, all in the BTS marked patched
and I CC'ed the bug reports.

It would be very kind if you could perfom another upload for
prometheus-smokeping-prober *only* with the updated translations. I
firmly believe release-managers will still accept this. And your
international users will surely be happy, espcially if they talk
German, Portuguese, Dutch, French or Brazilian Portuguese.

If you need help talking to release managers, do not hesitate to
contact me.

Thanks for considering!

Greetings

 Helge
-- 
  Dr. Helge Kreutzmann deb...@helgefjell.de
   Dipl.-Phys.   http://www.helgefjell.de/debian.php
64bit GNU powered gpg signed mail preferred
   Help keep free software "libre": http://www.ffii.de/


signature.asc
Description: PGP signature

Bug#988248: chiaki: No audio because of missing `libqt5multimedia5-plugins` package dependency

[Michael Schaller]

Package: chiaki
Version: 2.1.0-1
Severity: grave
Justification: renders package unusable

Dear Maintainer,

Chiaki doesn't have working audio without `libqtmedia_pulse.so`.
Please add a dependency on the `libqt5multimedia5-plugins` package, which 
provides `libqtmedia_pulse.so`.

Best,

Michael Schaller

-- System Information:
Debian Release: bullseye/sid
  APT prefers hirsute-updates
  APT policy: (500, 'hirsute-updates'), (500, 'hirsute-security'), (500, 
'hirsute')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

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

Versions of packages chiaki depends on:
ii  libavcodec58   7:4.3.2-0+deb11u1ubuntu1
ii  libavutil567:4.3.2-0+deb11u1ubuntu1
ii  libc6  2.33-0ubuntu5
ii  libevdev2  1.11.0+dfsg-1build1
ii  libgcc-s1  11.1.0-1ubuntu1~21.04
ii  libjerasure2   2.0.0+2017.04.10.git.de1739cc84-2
ii  libopus0   1.3.1-0.1
ii  libqt5core5a   5.15.2+dfsg-5
ii  libqt5gui5 5.15.2+dfsg-5
ii  libqt5multimedia5  5.15.2-3
ii  libqt5svg5 5.15.2-3
ii  libqt5widgets5 5.15.2+dfsg-5
ii  libsdl2-2.0-0  2.0.14+dfsg2-3
ii  libssl1.1  1.1.1j-1ubuntu3
ii  libstdc++6 11.1.0-1ubuntu1~21.04
ii  libudev1   247.3-3ubuntu3

chiaki recommends no packages.

chiaki suggests no packages.

-- no debconf information

Bug#988247: libopenhmd0: Different architectures not co-installable

[Gregor Riepl]

Package: libopenhmd0
Version: 0.3.0-1
Severity: normal
X-Debbugs-Cc: onit...@gmail.com

Dear Maintainer,

It's not possible to coinstall libopenhmd0 for two different architectures.

I would like to install the package for both amd64 and i386, but this
doesn't work. apt produces a conflict if I try this.

Please mark the package as Multi-Arch: same and ensure that it is 
co-installable.

Thank you.


-- System Information:
Debian Release: bullseye/sid
  APT prefers testing
  APT policy: (900, 'testing'), (500, 'testing-security'), (300, 'unstable'), 
(100, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

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

Versions of packages libopenhmd0 depends on:
ii  libc6  2.31-11
ii  libhidapi-libusb0  0.10.1+dfsg-1

libopenhmd0 recommends no packages.

libopenhmd0 suggests no packages.

-- no debconf information

Bug#980020: chromium: "undefined command" when printing to postscript printer

[Michael Gilbert]

control: tag -1 moreinfo
control: severity -1 minor

Karl O. Pinc wrote:
> Package: chromium
> Version: 87.0.4280.88-0.4~deb10u1
> Severity: normal
>
> I find that trying to print to a postscript printer with chromium
> prints instead:
>
> ERROR NAME;
>undefined
> COMMAND;
>Invalid
> OPERAND STACK;
>
> This did not always happen, but seems to be due to a security  update.

Are the latest chromium stable updates affected by this?  The
87.0.4280.88-0.4~deb10u1 security upload was built incorrectly.

Best wishes,
Mike

Bug#931003: Fixing rust package FTBFS in buster (was: Bug#931003: Removed package(s) from unstable )

[Adrian Bunk]

On Wed, May 05, 2021 at 08:01:13AM +0100, peter green wrote:
> On 04/05/2021 12:28, Santiago Vila wrote:
> > On Tue, May 04, 2021 at 11:48:09AM +0100, peter green wrote:
> > > > This was automatically closed by ftpmaster because the package was
> > > > removed from unstable, but this still does not fix the FTBFS problem
> > > > in stable.
> > > 
> > > Unfortunately I don't think a proper fix will be forthcoming, upstream
> > > has abandoned the crate in question.
> > 
> > It does not need to be a perfect fix. It is enough that dpkg-buildpackage
> > exits with status 0. If the tests are no longer valid, disabling them
> > should be much better than nothing, because packages in stable must
> > build in stable.
> 
> I'm prepared prepare such uploads if the stable release managers
> are prepared to accept them.

Usually they are receptive for reasonable FTBFS fixes,
and my rust-rustyline bug was part of me doing a find+fix round.

>...
> rust-simd: abandoned upstream, not in testing/unstable probably not properly 
> fixible, could disable test build during package build to fix FTBFS.
> rust-coresimd: abandoned upstream, not in testing/unstable probably not 
> properly fixible, could disable test build during package build to fix FTBFS.
> rust-nodrop-union: abandoned upstream, not in testing, broken in unstable 
> probably not properly fixible, could disable test build during package build 
> to fix FTBFS.

Is it only the test that is broken?
Or is the test due to some minor functionality breakage?
In that case, ignoring test problems would be the correct action.

But if the packages are just completely broken with current rustc,
then RM bugs against release.debian.org asking for removal in the
next buster point release would be the correct action for such
leaf packages.

> rust-rustyline: fixed upstream and in testing/unstable, I was able to bisect 
> and backport the fix (see bug 988025 )

This should be fixed in buster.

cu
Adrian

Bug#959170: linux: at boot: Process '/usr/sbin/alsactl ... restore 0' failed with exit code 99

[Vincent Lefevre]

FYI, other users got the same error:

  https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=848395
  https://bugs.launchpad.net/ubuntu/+source/alsa-driver/+bug/1568772
  https://bugs.launchpad.net/ubuntu/+source/alsa-utils/+bug/1624435
  https://bugs.gentoo.org/578138

In Debian bug 848395: as said by the alsactl(1) man page:

init tries to initialize all devices to a default state.
If device is not known, error code 99 is returned.

I can see 2 possibilities:

1. For some reason, the device is not always initialized by the
   kernel.

2. There is a race condition: alsactl is run too soon, while the
   device has not been initialized yet by the kernel.

(2) would explain why this isn't always reproducible.

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

Bug#974678: chromium: WebRTC lack H264 because of un-bundled OpenH264, is this intended ?

[Bastian Germann]

On Sat, 5 Dec 2020 15:46:14 +0100 Hauke Mehrtens  wrote:
Create a libopenh264 in Debian main or non-free repositories which 
downloads the binary which was build by Cisco when the package is 
installed. I think Debian would then not ship the patented binary.

Create a libopenh264-dev with the matching header files.
We would do it in a similar way like this:
https://packages.debian.org/de/sid/firmware-b43-installer


This is fine. The package must not reside in main. If you plan to 
release the package (the downloader) under a DFSG-compatible license, 
please submit it to contrib rather than non-free.


I haven't started this, I only looked at the code and it looks like it 
is possible. I would like to know if this solution would be acceptable 
by Debian. My motivation is that I want to use GeForce Now and make it 
easier to use Google Stadia with Chromium on Debian...
I am not a lawyer and also not a Debian developer, but I would implement 
this if this proposal looks ok.

Please go ahead. I would like to have openh264 in contrib.

Bug#959170: linux: at boot: Process '/usr/sbin/alsactl ... restore 0' failed with exit code 99

[Vincent Lefevre]

On 2021-05-08 14:54:58 +0200, Salvatore Bonaccorso wrote:
> Is this still something you are able to reproduce and have more
> insights since then? If you are not able to reproduce it anymore,
> should we otherwise close the issue?

zira:~> journalctl | grep 'failed with exit code 99'
May 18 14:40:58 zira systemd-udevd[461]: controlC1: Process '/usr/sbin/alsactl 
-E HOME=/run/alsa -E XDG_RUNTIME_DIR=/run/alsa/runtime restore 1' failed with 
exit code 99.
May 18 14:43:03 zira systemd-udevd[488]: controlC1: Process '/usr/sbin/alsactl 
-E HOME=/run/alsa -E XDG_RUNTIME_DIR=/run/alsa/runtime restore 1' failed with 
exit code 99.
Sep 17 14:44:13 zira systemd-udevd[452]: controlC1: Process '/usr/sbin/alsactl 
-E HOME=/run/alsa -E XDG_RUNTIME_DIR=/run/alsa/runtime restore 1' failed with 
exit code 99.
Sep 18 11:22:05 zira systemd-udevd[464]: controlC0: Process '/usr/sbin/alsactl 
-E HOME=/run/alsa -E XDG_RUNTIME_DIR=/run/alsa/runtime restore 0' failed with 
exit code 99.
Sep 24 10:54:58 zira systemd-udevd[452]: controlC1: Process '/usr/sbin/alsactl 
-E HOME=/run/alsa -E XDG_RUNTIME_DIR=/run/alsa/runtime restore 1' failed with 
exit code 99.
Sep 24 11:01:26 zira systemd-udevd[432]: controlC1: Process '/usr/sbin/alsactl 
-E HOME=/run/alsa -E XDG_RUNTIME_DIR=/run/alsa/runtime restore 1' failed with 
exit code 99.
Sep 24 11:07:31 zira systemd-udevd[456]: controlC1: Process '/usr/sbin/alsactl 
-E HOME=/run/alsa -E XDG_RUNTIME_DIR=/run/alsa/runtime restore 1' failed with 
exit code 99.
Sep 24 11:09:43 zira systemd-udevd[444]: controlC1: Process '/usr/sbin/alsactl 
-E HOME=/run/alsa -E XDG_RUNTIME_DIR=/run/alsa/runtime restore 1' failed with 
exit code 99.
Sep 24 11:29:22 zira systemd-udevd[449]: controlC1: Process '/usr/sbin/alsactl 
-E HOME=/run/alsa -E XDG_RUNTIME_DIR=/run/alsa/runtime restore 1' failed with 
exit code 99.
Sep 24 11:30:50 zira systemd-udevd[450]: controlC1: Process '/usr/sbin/alsactl 
-E HOME=/run/alsa -E XDG_RUNTIME_DIR=/run/alsa/runtime restore 1' failed with 
exit code 99.
Oct 18 23:19:30 zira systemd-udevd[462]: controlC0: Process '/usr/sbin/alsactl 
-E HOME=/run/alsa -E XDG_RUNTIME_DIR=/run/alsa/runtime restore 0' failed with 
exit code 99.
Oct 18 23:20:28 zira systemd-udevd[450]: controlC0: Process '/usr/sbin/alsactl 
-E HOME=/run/alsa -E XDG_RUNTIME_DIR=/run/alsa/runtime restore 0' failed with 
exit code 99.
Oct 29 02:51:50 zira systemd-udevd[452]: controlC0: Process '/usr/sbin/alsactl 
-E HOME=/run/alsa -E XDG_RUNTIME_DIR=/run/alsa/runtime restore 0' failed with 
exit code 99.
Nov 30 02:44:43 zira systemd-udevd[451]: controlC1: Process '/usr/sbin/alsactl 
-E HOME=/run/alsa -E XDG_RUNTIME_DIR=/run/alsa/runtime restore 1' failed with 
exit code 99.
Jan 04 21:21:29 zira systemd-udevd[458]: controlC0: Process '/usr/sbin/alsactl 
-E HOME=/run/alsa -E XDG_RUNTIME_DIR=/run/alsa/runtime restore 0' failed with 
exit code 99.
Jan 22 19:54:32 zira systemd-udevd[468]: controlC0: Process '/usr/sbin/alsactl 
-E HOME=/run/alsa -E XDG_RUNTIME_DIR=/run/alsa/runtime restore 0' failed with 
exit code 99.

So this failure hasn't occurred for a few months, but this was already
the case between 2020-05-18 and 2020-09-17. Thus there may still be
some possibility that it occurs again in a few weeks.

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

Bug#988236: roundcube-core: Install breaks lighttpd if fastcgi-php-fpm module is active

[Kurt Fitzner]

Package: roundcube
Version: 1.4.11+dfsg.1-3
Severity: important

Dear Maintainer,

If roundcube is installed on a system with lighttpd, then the installer
attempts to activate lighttpd's php module fastcgi-php.  However, If the
module fastcgi-php-fpm is already active, then having them both active breaks
lighttpd and the subsequent force-reload that the installer attemmpts on
lighttpd causes it to fail.

On systems with lighttpd, the installer should detect if fastcgi-php-fpm is
already active and if so, should not subsequently activate fastcgi-php.

I'm not sure this shouldn't have a higher severity, but I'll let you judge.

Thanks,

 Kurt Fitzner



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

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

Versions of packages roundcube-core depends on:
ii  dbconfig-common 2.0.19
ii  debconf [debconf-2.0]   1.5.75
ii  dpkg1.20.9
ii  libjs-bootstrap44.5.2+dfsg1-6
ii  libjs-codemirror5.59.2+~cs0.23.109-1
ii  libjs-jquery3.5.1+dfsg+~3.5.5-7
ii  libjs-jquery-minicolors 2.2.6+dfsg-4
ii  libjs-jquery-ui 1.12.1+dfsg-8
ii  libjs-jstimezonedetect  1.0.6-5
ii  libmagic1   1:5.39-3
ii  php 2:7.4+76
ii  php-auth-sasl   1.1.0-1
ii  php-cli 2:7.4+76
ii  php-common  2:76
ii  php-intl2:7.4+76
ii  php-mail-mime   1.10.10-1
ii  php-masterminds-html5   2.7.4+dfsg-2
ii  php-mbstring2:7.4+76
ii  php-net-sieve   1.4.4-2
ii  php-net-smtp1.9.0-1
ii  php-net-socket  1.2.2-2
ii  php-pear1:1.10.12+submodules+notgz+20210212-1
ii  php7.4 [php]7.4.15-5+deb11u1
ii  php7.4-cli [php-cli]7.4.15-5+deb11u1
ii  php7.4-intl [php-intl]  7.4.15-5+deb11u1
ii  php7.4-json [php-json]  7.4.15-5+deb11u1
ii  php7.4-mbstring [php-mbstring]  7.4.15-5+deb11u1
ii  roundcube-mysql 1.4.11+dfsg.1-3
ii  ucf 3.0043

Versions of packages roundcube-core recommends:
ii  lighttpd [httpd-cgi]1.4.59-1
ii  php-fpm 2:7.4+76
ii  php-gd  2:7.4+76
ii  php-pspell  2:7.4+76
ii  php7.4-fpm [php-fpm]7.4.15-5+deb11u1
ii  php7.4-gd [php-gd]  7.4.15-5+deb11u1
ii  php7.4-pspell [php-pspell]  7.4.15-5+deb11u1
ii  spawn-fcgi  1.6.4-2

Versions of packages roundcube-core suggests:
pn  php-crypt-gpg 
pn  php-mkopinsky-zxcvbn-php  
pn  php-net-ldap3 
ii  roundcube-plugins 1.4.11+dfsg.1-3

Versions of packages roundcube depends on:
ii  dpkg  1.20.9

-- debconf information:
  roundcube/upgrade-error: abort
  roundcube/install-error: abort
  roundcube/dbconfig-remove: true
  roundcube/remote/newhost:
  roundcube/remove-error: abort
  roundcube/mysql/method: Unix socket
  roundcube/purge: false
  roundcube/remote/host: localhost
  roundcube/passwords-do-not-match:
  roundcube/language: en_CA
  roundcube/internal/skip-preseed: false
* roundcube/database-type: mysql
  roundcube/dbconfig-reinstall: false
  roundcube/restart-webserver: true
  roundcube/remote/port:
  roundcube/hosts:
* roundcube/mysql/admin-user: root
  roundcube/reconfigure-webserver: apache2, lighttpd
  roundcube/db/app-user: roundcube@localhost
  roundcube/upgrade-backup: true
  roundcube/internal/reconfiguring: false
  roundcube/mysql/authplugin: default
  roundcube/db/dbname: roundcube
  roundcube/missing-db-package-error: abort
* roundcube/dbconfig-install: true
  roundcube/dbconfig-upgrade: true

Bug#988129: hfst-ospell: FTBFS on sparc64 due to test failures

[Tino Didriksen]

forwarded 988129 https://github.com/hfst/hfst-ospell/issues/43
thanks

-- Tino Didriksen

Bug#988187: RFS: dmidecode/3.3-2 -- SMBIOS/DMI table decoder

[Adrian Bunk]

Control: tags -1 moreinfo

On Fri, May 07, 2021 at 10:45:35AM +0200, Jörg Frings-Fürst wrote:
>...
>  dmidecode (3.3-2) experimental; urgency=medium
>  .
>* Add upstream recommended patches (Closes: #987033):
>  - New debian/patches/0145-Fix_condition_error_in_ascii_filter.patch.
>  - New debian/patches/0150-Fix_crash.patch.
>* Declare compliance with Debian Policy 4.5.1 (No changes needed).
>* debian/copyright:
>  - Add year 2021 to myself.
>...

In my opinion the #987033 fixes should go into bullseye,
and I hope the release team would agree.

Please use
  reportbug release.debian.org
for an unblock request with debdiff of these changes for bullseye,
and if approved please change from "experimental" to "unstable".

> CU
> Jörg

cu
Adrian

Bug#946437: systemd-udevd: event4: Failed to call EVIOCSKEYCODE with scan code 0x70068, and key code 110: Invalid argument

[Vincent Lefevre]

Control: found -1 5.10.24-1

On 2021-05-08 14:53:13 +0200, Salvatore Bonaccorso wrote:
> Vincent, is this still something you are able to reproduce with a
> recent kernel? If not, should we close the bug? If yes, any more
> insights since the last report?

I still get the error in the logs due to the F13 key.
Last tested with:

Linux version 5.10.0-5-amd64 (debian-ker...@lists.debian.org) (gcc-10 (Debian 
10.2.1-6) 10.2.1 20210110, GNU ld (GNU Binutils for Debian) 2.35.2) #1 SMP 
Debian 5.10.24-1 (2021-03-19)

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

Bug#987030: linux-image-5.10.0-6-amd64 - Fans speed maximum - CPU load < 1%

[Hans van Kranenburg]

Oh,

On 4/16/21 11:44 AM, Hans van Kranenburg wrote:
> [...]
> 
> I have the same issue here, it started at the moment I moved from the
> 4.19 kernel to 5.9, and now 5.10. For totally non-obvious reasons fans
> start blowing like crazy regularly for a few seconds. When observing
> system load, it's just hovering around 0.2 - 0.4, no peaks observed.
> 
> [...]

So, while the fan misbehavior started around the time of the kernel
upgrade, the reason turned out to be a lot more simple.

For me, it was a dust problem. After thorough cleaning, the problem is
gone. :D

Hans

Bug#988246: wine-development: not intended for a stable release

[Michael Gilbert]

package: src:wine-development
severity: serious

This package is not intended to be released in a debian stable
release.  This bug serves to prevent migration of the package to
testing.

Best wishes,
Mike

Bug#988245: ocsinventory-agent: cron script uses /bin/sh and RANDOM

[Malte Schirmacher]

Package: ocsinventory-agent
Version: 2:2.8-2
Severity: important
X-Debbugs-Cc: malte.schirmac...@etecture.de

Dear Maintainer,

the automatically installed cron.daily script uses /bin/sh.
Trying to access $RANDOM later might fail on many systems as this variable is
not present causing the cronjob not to be executed at all.
Explicitly using /bin/bash fixes this.


-- System Information:
Debian Release: 11.0
  APT prefers unstable
  APT policy: (500, 'unstable'), (500, 'testing'), (500, 'oldstable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

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

Versions of packages ocsinventory-agent depends on:
ii  debconf [debconf-2.0]  1.5.76
ii  fdisk  2.36.1-7
ii  libc6  2.31-12
ii  libcrypt-ssleay-perl   0.73.06-1+b3
ii  libnet-ip-perl 1.26-2
ii  libproc-daemon-perl0.23-1
ii  libwww-perl6.53-1
ii  libxml-simple-perl 2.25-1
ii  perl   5.32.1-4
ii  ucf3.0043
ii  util-linux 2.36.1-7

Versions of packages ocsinventory-agent recommends:
ii  dmidecode   3.3-1
ii  e2fsprogs   1.46.2-1
ii  hdparm  9.60+ds-1
ii  libio-socket-ssl-perl   2.069-1
ii  liblwp-protocol-https-perl  6.10-1
ii  libnet-cups-perl0.64-1+b3
ii  libnet-netmask-perl 1.9104-2
ii  libnet-snmp-perl6.0.1-6
ii  libparse-edid-perl  1.0.7-1.1
ii  pciutils1:3.7.0-5

Versions of packages ocsinventory-agent suggests:
pn  libnmap-parser-perl  
ii  nmap 7.91+dfsg1+really7.80+dfsg1-2
pn  read-edid
ii  smartmontools7.2-1

-- Configuration Files:
/etc/cron.daily/ocsinventory-agent changed [not included]

-- debconf information:
* ocsinventory-agent/server: 172.29.0.222
* ocsinventory-agent/method: http

Bug#973240: chromium: APNGs flicker

[Michael Gilbert]

control: severity -1 minor
control: forwarded -1 http://crbug.com/1142228
control: retitle -1 chromium: APNGs flicker when built with system libpng

This is only a problem when chromium is built using the libpng shared
system library.

Best wishes,
Mike

Bug#982468: old glyph

[Adam Borowski]

> Anyways, what did you hope to accomplish by filing this bug against a
> Debian package? Is Debian going to start designing its own hotfix
> glyphs?

The old glyph from before Google decided to change it is good.

-- 
⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁
⢿⡄⠘⠷⠚⠋⠀ * ***
⠈⠳⣄

Bug#959881: libssh2-1: Please upgrade to 1.9: ECDSA and memory leaks

[Benjamin Riefenstahl]

I did some more digging and than made a bug report with Curl upstream
here: .  This produced a
commit there that makes my test work much better.

The glibc function mallinfo still says that a couple of bytes go missing
now and than, but valgrind says it can't find anything.  I also repeated
the test 2 times and watched the memory in htop and it didn't grow,
so I will assume this is an error with mallinfo.

Thank you for your attention and your patience.

Regards, benny

Bug#988158: xscreensaver regularly crashes, leaving screen unlocked

[Jamie Zawinski]

An XIO error means that the server dropped our connection, as opposed to the 
client making an invalid request, which is weird. Usually IO errors only happen 
when the X server crashes.

Maybe it's a driver bug? Maybe you're running out of memory? (Though typically 
the server sends a more sensible X error than this when out of memory.)

However, the XScreenSaver daemon does not use XSHM, so that error message is 
probably coming from the display mode, not the daemon. A crash in the display 
mode won't cause the daemon to exit and the screen to unlock.

As always, the only way to figure this out is if you include all of the output 
of -log.

Also, you're running 5.45 instead of 6.00 and if you can't reproduce it in 6.00 
there's no point in investigating any further. So try that.

--
Jamie Zawinski  https://www.jwz.org/  https://www.dnalounge.com/

Bug#982468: [Pkg-fonts-devel] Bug#982468: fonts-noto-color-emoji: U+1F52B PISTOL shows a water-spraying toy instead

[Adam Borowski]

On Sat, May 08, 2021 at 09:03:10AM -0400, Jeremy Bicha wrote:
> I am closing this bug. See James' previous message here for more details.
> 
> In this case, what is actually implemented and used by the major
> platforms (messaging apps, browsers, and operating systems) is more
> relevant than the written standard.

Perpetuating a violation is not right.  Especially, when this is done for
nasty political reasons (a particular sect of US politics).

> If the conflict between the written standard and the implementation
> bothers you, you could try working with Unicode to update the
> standard.

The current standard looks good as-is.  On the other hand, it would be good
to introduce a "water pistol" character to solve the issue at hand.

> Because interoperability with non-Debian-based platforms is such an
> essential feature of the Debian fonts-noto-color-emoji package, we
> will not attempt to diverge this particular emoji from the upstream
> maintainers.

What solution would you propose then?

I'm thinking, what if we had a separate package with a fontconfig override
that corrects this glyph?


Meow!
-- 
⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁
⢿⡄⠘⠷⠚⠋⠀ A true bird-watcher waves his tail while doing so.
⠈⠳⣄

Bug#988244: ITP: jcabi-ssh - Simple SSH client

[Mechtilde Stehmann]

Package: wnpp
Severity: wishlist

* Package name : libjcabi-ssh-java
  Version : 1.6.1
  Upstream Author : t...@jcabi.com
* URL : http://ssh.jcabi.com/
* License : BSD
  Programming Lang: Java
  Description :  Simple SSH Client

It is a convenient wrapper of JSch, a well-known pure
Java implementation of SSH2.



* Why is this package useful/relevant?
It is a dependency to build J-Lawyer (RFP: 962415)
* Is it a dependency for another package?
Yes
* Do you use it yourself?
Yes
* If there are other packages providing similar functionality,
  how does it compare?
No
* How do you plan to maintain it? Do you plan to maintain it
  inside a packaging team?
  (check list at https://wiki.debian.org/Teams)
inside Java-Team
* Are you looking for co-maintainers? Do you need a sponsor?
No

...--
Mechtilde Stehmann
## Debian Developer
## PGP encryption welcome
## F0E3 7F3D C87A 4998 2899  39E7 F287 7BBA 141A AD7F



OpenPGP_signature
Description: OpenPGP digital signature

Bug#988243: golang-github-ulikunitz-xz: CVE-2021-29482

[Salvatore Bonaccorso]

Source: golang-github-ulikunitz-xz
Version: 0.5.6-1
Severity: grave
Tags: security upstream
Justification: user security hole
X-Debbugs-Cc: car...@debian.org, Debian Security Team 

Hi,

The following vulnerability was published for golang-github-ulikunitz-xz.

CVE-2021-29482[0]:
| xz is a compression and decompression library focusing on the xz
| format completely written in Go. The function readUvarint used to read
| the xz container format may not terminate a loop provide malicous
| input. The problem has been fixed in release v0.5.8. As a workaround
| users can limit the size of the compressed file input to a reasonable
| size for their use case. The standard library had recently the same
| issue and got the CVE-2020-16845 allocated.


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-29482
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-29482
[1] https://github.com/ulikunitz/xz/security/advisories/GHSA-25xm-hr59-7c27
[2] 
https://github.com/ulikunitz/xz/commit/69c6093c7b2397b923acf82cb378f55ab2652b9b

Regards,
Salvatore

Bug#978166: Updated package

[eloy]

There's updated package released in salsa.debian.org
https://salsa.debian.org/debian/whipper/-/tree/debian/0.9.0-7 but I
have problems with uploading it into ftp debian.org. Until I resolve
problems with uploading someone can take build from there and upload it.

eloy

Bug#988242: exiv2: CVE-2021-29464

[Salvatore Bonaccorso]

Source: exiv2
Version: 0.27.3-3
Severity: important
Tags: security upstream
X-Debbugs-Cc: car...@debian.org, Debian Security Team 

Hi,

The following vulnerability was published for exiv2.

CVE-2021-29464[0]:
| Exiv2 is a command-line utility and C++ library for reading, writing,
| deleting, and modifying the metadata of image files. A heap buffer
| overflow was found in Exiv2 versions v0.27.3 and earlier. The heap
| overflow is triggered when Exiv2 is used to write metadata into a
| crafted image file. An attacker could potentially exploit the
| vulnerability to gain code execution, if they can trick the victim
| into running Exiv2 on a crafted image file. Note that this bug is only
| triggered when writing the metadata, which is a less frequently used
| Exiv2 operation than reading the metadata. For example, to trigger the
| bug in the Exiv2 command-line application, you need to add an extra
| command-line argument such as `insert`. The bug is fixed in version
| v0.27.4.


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-29464
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-29464
[1] https://github.com/Exiv2/exiv2/security/advisories/GHSA-jgm9-5fw5-pw9p
[2] 
https://github.com/Exiv2/exiv2/commit/f9308839198aca5e68a65194f151a1de92398f54

Regards,
Salvatore

Bug#988241: exiv2: CVE-2021-29463

[Salvatore Bonaccorso]

Source: exiv2
Version: 0.27.3-3
Severity: important
Tags: security upstream
X-Debbugs-Cc: car...@debian.org, Debian Security Team 

Hi,

The following vulnerability was published for exiv2.

CVE-2021-29463[0]:
| Exiv2 is a command-line utility and C++ library for reading, writing,
| deleting, and modifying the metadata of image files. An out-of-bounds
| read was found in Exiv2 versions v0.27.3 and earlier. The out-of-
| bounds read is triggered when Exiv2 is used to write metadata into a
| crafted image file. An attacker could potentially exploit the
| vulnerability to cause a denial of service by crashing Exiv2, if they
| can trick the victim into running Exiv2 on a crafted image file. Note
| that this bug is only triggered when writing the metadata, which is a
| less frequently used Exiv2 operation than reading the metadata. For
| example, to trigger the bug in the Exiv2 command-line application, you
| need to add an extra command-line argument such as `insert`. The bug
| is fixed in version v0.27.4.


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-29463
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-29463
[1] https://github.com/Exiv2/exiv2/security/advisories/GHSA-5p8g-9xf3-gfrr
[2] 
https://github.com/Exiv2/exiv2/commit/783b3a6ff15ed6f82a8f8e6c8a6f3b84a9b04d4b

Regards,
Salvatore

Bug#988240: openexr: CVE-2021-23169

[Salvatore Bonaccorso]

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

Hi,

The following vulnerability was published for openexr.

CVE-2021-23169[0]:
| Heap-buffer-overflow in Imf_2_5::copyIntoFrameBuffer

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-23169
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-23169
[1] https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=28051
[2] 
https://github.com/AcademySoftwareFoundation/openexr/commit/ae6d203892cc9311917a7f4f05354ef792b3e58e

Regards,
Salvatore

Bug#988232: wine64-development: new wine 5.9 always fails with chdir to /tmp/.wine-... : No such file or directory

[Antoine Le Gonidec]

This is most probably the same bug than already reported here:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=988195



OpenPGP_signature
Description: OpenPGP digital signature

Bug#988239: libgetdata: CVE-2021-20204

[Salvatore Bonaccorso]

Source: libgetdata
Version: 0.10.0-9
Severity: important
Tags: security upstream
Forwarded: https://bugs.launchpad.net/ubuntu/+source/libgetdata/+bug/1912050
X-Debbugs-Cc: car...@debian.org, Debian Security Team 
Control: found -1 0.10.0-5

Hi,

The following vulnerability was published for libgetdata.

CVE-2021-20204[0]:
| A heap memory corruption problem (use after free) can be triggered in
| libgetdata v0.10.0 when processing maliciously crafted dirfile
| databases. This degrades the confidentiality, integrity and
| availability of third-party software that uses libgetdata as a
| library. This vulnerability may lead to arbitrary code execution or
| privilege escalation depending on input/skills of attacker.


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-20204
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-20204
[1] https://bugs.launchpad.net/ubuntu/+source/libgetdata/+bug/1912050
[2] https://bugzilla.redhat.com/show_bug.cgi?id=1956348

Regards,
Salvatore

Bug#988227: nis: /var/lib/dpkg/info/nis.postinst: 76: [: -eq: unexpected operator

[Paul Menzel]

Dear Francesco,


Am 08.05.21 um 14:19 schrieb Francesco P. Lovergine:

Thanks for the report, but I can't see why a line like:

if [ ! -z "$PREV_VER" -a $(dpkg --compare-versions "$PREV_VER" lt '4~'; 
echo $?) -eq 0 ]


should fail under dash (which is even the default shell on Debian). You 
are trying to upgrade 4.2 to 4.2 in this case.


That was only to reproduce the issue. Originally I upgrade from 3.17.1-5.

2021-05-06 08:52:34 upgrade nis:ppc64el 3.17.1-5 4.2


Then it should run like:

if [ ! -z "4.2" -a $(dpkg --compare-versions "4.2" lt '4~'; echo $?) -eq 0 ]

and it works perfectly fine under dash. :-?


With `set -xe` in `/var/lib/dpkg/info/nis.postinst`:

$ sudo /var/lib/dpkg/info/nis.postinst configure 4.2
+ umask 022
+ PREV_VER=4.2
+ dpkg --compare-versions 4.2 lt 4~
+ [ ! -z 4.2 -a -eq 0 ]
/var/lib/dpkg/info/nis.postinst: 78: [: -eq: unexpected operator
+ rm -f /etc/init.d/nis

Could you please verify that /bin/sh links /bin/dash and what is the 
dash version via dpkg -l ?


```
$ ls -l /bin/sh
lrwxrwxrwx 1 root root 4 Jan  5 17:47 /bin/sh -> dash
$ dpkg -l dash
Desired=Unknown/Install/Remove/Purge/Hold
| 
Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend

|/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad)
||/ Name   Version 
Architecture Description

+++-==---=
ii  dash 
0.5.11+git20200708+dd9ef66+really0.5.11+git20200708+dd9ef66-5ubuntu1 
ppc64el  POSIX-compliant shell

```


Kind regards,

Paul

Bug#988134: digimend-dkms: partial install

[Kentaro Hayashi]

Thank you for reporting.

It was caused by missing Depends: to linux-headers package.

Bug#978084: CPU: 2 PID: 5507 at drivers/gpu/drm/amd/amdgpu/../display/dc/core/dc_link.c:2548

[Salvatore Bonaccorso]

Control: tags -1 + moreinfo

On Fri, Dec 25, 2020 at 02:28:36PM -0500, Neil wrote:
> Package: src:linux
> Version: 5.10.2-1~exp1
> Severity: minor
> 
> Hello there,
> 
> The following message was found after suspension in dmesg:
> 
> [ 1305.813835] WARNING: CPU: 2 PID: 5507 at
> drivers/gpu/drm/amd/amdgpu/../display/dc/core/dc_link.c:2548
> dc_link_set_backlight_level+0x8a/0xf0 [amdgpu]
> [ 1305.813837] Modules linked in: ctr ccm rfcomm nf_tables nfnetlink cmac
> algif_hash algif_skcipher af_alg bnep tpm_crb btusb snd_hda_codec_conexant
> btrtl snd_hda_codec_hdmi btbcm btintel btrfs snd_hda_codec_generic bluetooth
> snd_hda_intel snd_intel_dspcfg jitterentropy_rng soundwire_intel edac_mce_amd
> soundwire_generic_allocation snd_soc_core drbg kvm_amd rtw88_8822be 
> rtw88_8822b
> blake2b_generic snd_compress rtw88_pci kvm soundwire_cadence xor rtw88_core
> snd_hda_codec uvcvideo nls_ascii snd_hda_core snd_hwdep videobuf2_vmalloc
> nls_cp437 videobuf2_memops videobuf2_v4l2 irqbypass videobuf2_common videodev
> vfat soundwire_bus mac80211 mc fat ghash_clmulni_intel aes_generic aesni_intel
> snd_pcm ansi_cprng snd_rn_pci_acp3x ecdh_generic snd_pci_acp3x ecc
> thinkpad_acpi crypto_simd crc16 libaes cryptd snd_timer glue_helper cfg80211
> nvram ledtrig_audio snd raid6_pq libarc4 soundcore rapl sg rfkill ac joydev
> k10temp ccp sp5100_tco watchdog tpm_tis tpm_tis_core tpm ucsi_acpi 
> acpi_cpufreq
> wmi_bmof
> [ 1305.813920]  rng_core evdev typec_ucsi typec efi_pstore serio_raw pcspkr
> fuse configfs efivarfs ip_tables x_tables autofs4 xfs libcrc32c crc32c_generic
> sd_mod amdgpu rtsx_pci_sdmmc mmc_core gpu_sched i2c_algo_bit ttm xhci_pci
> drm_kms_helper i2c_piix4 ahci nvme libahci xhci_hcd crc32_pclmul cec
> crc32c_intel libata psmouse nvme_core drm usbcore scsi_mod t10_pi r8169
> crc_t10dif realtek mdio_devres usb_common libphy rtsx_pci crct10dif_generic
> crct10dif_pclmul crct10dif_common wmi battery video i2c_scmi button
> [ 1305.813979] CPU: 2 PID: 5507 Comm: xfpm-power-back Tainted: GW
> 5.10.0-trunk-amd64 #1 Debian 5.10.2-1~exp1
> [ 1305.813981] Hardware name: LENOVO 20NECTO1WW/20NECTO1WW, BIOS R11ET40P 
> (1.20
> ) 11/17/2020
> [ 1305.814140] RIP: 0010:dc_link_set_backlight_level+0x8a/0xf0 [amdgpu]
> [ 1305.814144] Code: 60 03 00 00 31 c0 48 8d 96 c0 01 00 00 48 8b 0a 48 85 c9
> 74 06 48 3b 59 08 74 20 83 c0 01 48 81 c2 d8 04 00 00 83 f8 06 75 e3 <0f> 0b 
> 45
> 31 e4 5b 44 89 e0 5d 41 5c 41 5d 41 5e c3 48 98 48 69 c0
> [ 1305.814147] RSP: 0018:b37602b43df0 EFLAGS: 00010246
> [ 1305.814150] RAX: 0006 RBX: 9e108a973800 RCX:
> 
> [ 1305.814152] RDX: 9e1089681ed0 RSI: 9e108968 RDI:
> 
> [ 1305.814153] RBP: 9e108a91 R08: 0033 R09:
> 000a
> [ 1305.814155] R10: 000a R11: f000 R12:
> 3501
> [ 1305.814156] R13:  R14: 359c R15:
> 9e10fc023820
> [ 1305.814159] FS:  7ff8adfc3b80() GS:9e1234a8()
> knlGS:
> [ 1305.814161] CS:  0010 DS:  ES:  CR0: 80050033
> [ 1305.814163] CR2: 7ff8ae0aade0 CR3: 00010947e000 CR4:
> 003506e0
> [ 1305.814165] Call Trace:
> [ 1305.814340]  amdgpu_dm_backlight_update_status+0xb4/0xc0 [amdgpu]
> [ 1305.814349]  backlight_device_set_brightness+0x7e/0x130
> [ 1305.814355]  ? kernfs_fop_write+0x131/0x1b0
> [ 1305.814360]  brightness_store+0x5b/0x70
> [ 1305.814364]  kernfs_fop_write+0xce/0x1b0
> [ 1305.814370]  vfs_write+0xc0/0x260
> [ 1305.814374]  ksys_write+0x5f/0xe0
> [ 1305.814380]  do_syscall_64+0x33/0x80
> [ 1305.814385]  entry_SYSCALL_64_after_hwframe+0x44/0xa9
> [ 1305.814389] RIP: 0033:0x7ff8ae148ed3
> [ 1305.814392] Code: 8b 15 c1 ef 0c 00 f7 d8 64 89 02 48 c7 c0 ff ff ff ff eb
> b7 0f 1f 00 64 8b 04 25 18 00 00 00 85 c0 75 14 b8 01 00 00 00 0f 05 <48> 3d 
> 00
> f0 ff ff 77 55 c3 0f 1f 40 00 48 83 ec 28 48 89 54 24 18
> [ 1305.814394] RSP: 002b:7ffc381e0b88 EFLAGS: 0246 ORIG_RAX:
> 0001
> [ 1305.814396] RAX: ffda RBX: 563a13783000 RCX:
> 7ff8ae148ed3
> [ 1305.814398] RDX: 0002 RSI: 563a13781eb0 RDI:
> 0003
> [ 1305.814399] RBP: 563a13781eb0 R08:  R09:
> 0002
> [ 1305.814400] R10: 7ffc381e08e6 R11: 0246 R12:
> 0003
> [ 1305.814402] R13: 7ffc381e0c08 R14: 0002 R15:
> 0001

is this still something you can reproduce with a recent 5.10.y kernel?

Regards,
Salvatore

Bug#978043: linux-image-5.10.0-trunk-amd64: irq 7: nobody cared (ryzen 3500u)

[Salvatore Bonaccorso]

Hi,

On Thu, Dec 24, 2020 at 07:17:29PM -0500, Neil wrote:
> Package: src:linux
> Version: 5.10.2-1~exp1
> Severity: minor
> 
> Dear Maintainer,
> 
> Hello there,
> I just wanted to report this dmesg message here,  I already reported it to
> kernel.org and redhat's bugzilla (fedora),  but who knows, maybe reporting it
> here before debian 11 gets released is worth it,  I hope it doesn't bother :)

can you reference the upstream report from you? Was there any
progress, is this fixed with a recent kernel or still reproducible?

Regards,
Salvatore

Bug#625357: upstream status for this issue?

[Matthias Klose]

Control: tags -1 + moreinfo

Jonathan, what's the upstream status for this issue?

Bug#988227: nis: /var/lib/dpkg/info/nis.postinst: 76: [: -eq: unexpected operator

[Francesco P. Lovergine]

Thanks for the report, but I can't see why a line like:

if [ ! -z "$PREV_VER" -a $(dpkg --compare-versions "$PREV_VER" lt '4~'; echo 
$?) -eq 0 ]

should fail under dash (which is even the default shell on Debian). You are 
trying to upgrade 4.2 to 4.2 in this case. Then it should run like:


if [ ! -z "4.2" -a $(dpkg --compare-versions "4.2" lt '4~'; echo $?) -eq 0 ]

and it works perfectly fine under dash. :-?
Could you please verify that /bin/sh links /bin/dash and what is the dash 
version via dpkg -l ?


On Sat, May 08, 2021 at 09:30:30AM +0200, Paul Menzel wrote:

Package: nis
Version: 4.2
Severity: normal

Dear Debian folks,


I encountered this in Ubuntu [1], but they use the Debian package.

With `/bin/sh` being dash and not Bash, the postinst script fails.

```
$ sudo apt reinstall nis
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
0 upgraded, 0 newly installed, 1 reinstalled, 0 to remove and 0 not 
upgraded.

Need to get 14.2 kB of archives.
After this operation, 0 B of additional disk space will be used.
Get:1 http://de.ports.ubuntu.com/ubuntu-ports hirsute/universe ppc64el 
nis all 4.2 [14.2 kB]

Fetched 14.2 kB in 0s (110 kB/s)
(Reading database ... 420369 files and directories currently installed.)
Preparing to unpack .../apt/archives/nis_4.2_all.deb ...
update-rc.d: error: unable to read /etc/init.d/nis
Unpacking nis (4.2) over (4.2) ...
Setting up nis (4.2) ...
/var/lib/dpkg/info/nis.postinst: 76: [: -eq: unexpected operator
```

Using `/bin/bash` in the shebang of the postinst script, and doing 
`dpkg -a --configure` worked around this issue.



Kind regards,

Paul


[1]: https://bugs.launchpad.net/ubuntu/+source/nis/+bug/1927540
[2]: 
https://salsa.debian.org/debian-nis-team/nis/-/blob/master/debian/postinst#L76



--
Francesco P. Lovergine

Bug#959170: linux: at boot: Process '/usr/sbin/alsactl ... restore 0' failed with exit code 99

[Salvatore Bonaccorso]

Control: tags -1 + moreinfo

On Thu, Apr 30, 2020 at 12:38:26PM +0200, Vincent Lefevre wrote:
> Source: linux
> Version: 5.6.7-1
> Severity: minor
> 
> With the 5.6.0-1-amd64 Linux kernel at least, I get the following
> error at boot (shown by journalctl):
> 
> Apr 30 11:57:16 zira systemd-udevd[489]: controlC0: Process 
> '/usr/sbin/alsactl -E HOME=/run/alsa -E XDG_RUNTIME_DIR=/run/alsa/runtime 
> restore 0' failed with exit code 99.
> 
> This apparently comes from /lib/systemd/system/alsa-restore.service,
> which has:
> 
> ExecStart=-/usr/sbin/alsactl -E HOME=/run/alsa -E 
> XDG_RUNTIME_DIR=/run/alsa/runtime restore
> 
> It seems that the first time I got a similar error was in October:
> 
> Oct 22 10:07:58 zira systemd-udevd[500]: Process '/usr/sbin/alsactl -E 
> HOME=/run/alsa restore 1' failed with exit code 99.
> 
> Then in November:
> 
> Nov 10 02:40:42 zira systemd-udevd[513]: Process '/usr/sbin/alsactl -E 
> HOME=/run/alsa -E XDG_RUNTIME_DIR=/run/alsa/runtime restore 1' failed with 
> exit code 99.
> 
> /etc/alsa/conf.d contains:
> 
> lrwxrwxrwx 1 root root  44 2020-02-29 17:15:54 10-rate-lav.conf -> 
> /usr/share/alsa/alsa.conf.d/10-rate-lav.conf
> lrwxrwxrwx 1 root root  46 2020-02-29 17:15:54 10-samplerate.conf -> 
> /usr/share/alsa/alsa.conf.d/10-samplerate.conf
> lrwxrwxrwx 1 root root  45 2020-02-29 17:15:54 10-speexrate.conf -> 
> /usr/share/alsa/alsa.conf.d/10-speexrate.conf
> lrwxrwxrwx 1 root root  48 2020-02-29 17:15:54 50-arcam-av-ctl.conf -> 
> /usr/share/alsa/alsa.conf.d/50-arcam-av-ctl.conf
> lrwxrwxrwx 1 root root  40 2020-02-29 17:15:54 50-jack.conf -> 
> /usr/share/alsa/alsa.conf.d/50-jack.conf
> lrwxrwxrwx 1 root root  39 2020-02-29 17:15:54 50-oss.conf -> 
> /usr/share/alsa/alsa.conf.d/50-oss.conf
> lrwxrwxrwx 1 root root  46 2020-02-29 17:15:54 50-pulseaudio.conf -> 
> /usr/share/alsa/alsa.conf.d/50-pulseaudio.conf
> lrwxrwxrwx 1 root root  47 2020-02-29 17:15:54 60-a52-encoder.conf -> 
> /usr/share/alsa/alsa.conf.d/60-a52-encoder.conf
> lrwxrwxrwx 1 root root  41 2020-02-29 17:15:54 60-upmix.conf -> 
> /usr/share/alsa/alsa.conf.d/60-upmix.conf
> lrwxrwxrwx 1 root root  44 2020-02-29 17:15:54 60-vdownmix.conf -> 
> /usr/share/alsa/alsa.conf.d/60-vdownmix.conf
> lrwxrwxrwx 1 root root  46 2020-02-29 17:15:54 98-usb-stream.conf -> 
> /usr/share/alsa/alsa.conf.d/98-usb-stream.conf
> lrwxrwxrwx 1 root root  38 2020-02-06 03:06:41 99-pulse.conf -> 
> /usr/share/alsa/alsa.conf.d/pulse.conf
> -rw-r--r-- 1 root root 201 2018-11-03 00:35:24 
> 99-pulseaudio-default.conf.example
> 
> (I haven't changed anything there.)

Is this still something you are able to reproduce and have more
insights since then? If you are not able to reproduce it anymore,
should we otherwise close the issue?

Regards,
Salvatore

Bug#946437: systemd-udevd: event4: Failed to call EVIOCSKEYCODE with scan code 0x70068, and key code 110: Invalid argument

[Salvatore Bonaccorso]

Control: tags -1 + moreinfo

Hi Vincent,

On Tue, Jan 28, 2020 at 03:40:03AM +0100, Vincent Lefevre wrote:
> On 2019-12-09 00:31:29 +0100, Vincent Lefevre wrote:
> > I've noticed the following error (in red) in the journalctl output:
> > 
> > Dec 09 00:10:18 zira systemd-udevd[506]: event4: Failed to call 
> > EVIOCSKEYCODE with scan code 0x70068, and key code 110: Invalid argument
> > 
> > This is not new.
> > 
> > I have a file /etc/udev/hwdb.d/98-apple-keyboard.hwdb with:
> > 
> > evdev:input:b0003v05ACp0221*
> >  KEYBOARD_KEY_70068=insert  # F13: Insert
> > 
> > and this corresponds to
> > 
> > Bus 002 Device 005: ID 05ac:0221 Apple, Inc. Aluminum Keyboard (ISO)
> > 
> > I use the F13 key for Insert, as there is no Insert key on this
> > keyboard (this is a Fn key at the usual place of the Insert key
> > and the driver honors this specificity).
> > 
> > I have not seen any side effect of this error, though.
> 
> According to the Xorg log[*], the keyboard uses 2 event devices
> (in particular, due to that, I get many duplicate lines in this
> log file: one for each event device). But the error I get in the
> journalctl output is only for the second event device.
> 
> [*] The lines from /var/log/Xorg.0.log corresponding to these two
> event devices:
> 
> [18.667] (II) config/udev: Adding input device Apple, Inc Apple Keyboard 
> (/dev/input/event3)
> [18.667] (**) Option "Device" "/dev/input/event3"
> [18.669] (II) event3  - Apple, Inc Apple Keyboard: is tagged by udev as: 
> Keyboard
> [18.669] (II) event3  - Apple, Inc Apple Keyboard: device is a keyboard
> [18.669] (II) event3  - Apple, Inc Apple Keyboard: device removed
> [18.698] (**) Option "config_info" 
> "udev:/sys/devices/pci:00/:00:14.0/usb2/2-6/2-6.2/2-6.2:1.0/0003:05AC:0221.0001/input/input9/event3"
> [18.700] (II) event3  - Apple, Inc Apple Keyboard: is tagged by udev as: 
> Keyboard
> [18.700] (II) event3  - Apple, Inc Apple Keyboard: device is a keyboard
> [18.701] (II) config/udev: Adding input device Apple, Inc Apple Keyboard 
> (/dev/input/event4)
> [18.701] (**) Option "Device" "/dev/input/event4"
> [18.704] (II) event4  - Apple, Inc Apple Keyboard: is tagged by udev as: 
> Keyboard
> [18.704] (II) event4  - Apple, Inc Apple Keyboard: device is a keyboard
> [18.704] (II) event4  - Apple, Inc Apple Keyboard: device removed
> [18.734] (**) Option "config_info" 
> "udev:/sys/devices/pci:00/:00:14.0/usb2/2-6/2-6.2/2-6.2:1.1/0003:05AC:0221.0002/input/input10/event4"
> [18.736] (II) event4  - Apple, Inc Apple Keyboard: is tagged by udev as: 
> Keyboard
> [18.736] (II) event4  - Apple, Inc Apple Keyboard: device is a keyboard
> [ 16244.494] (II) event3  - Apple, Inc Apple Keyboard: device removed
> [ 16244.510] (II) event4  - Apple, Inc Apple Keyboard: device removed
> [ 25897.048] (II) event3  - Apple, Inc Apple Keyboard: is tagged by udev as: 
> Keyboard
> [ 25897.048] (II) event3  - Apple, Inc Apple Keyboard: device is a keyboard
> [ 25897.049] (II) event4  - Apple, Inc Apple Keyboard: is tagged by udev as: 
> Keyboard
> [ 25897.049] (II) event4  - Apple, Inc Apple Keyboard: device is a keyboard
> [ 26635.074] (II) event3  - Apple, Inc Apple Keyboard: device removed
> [ 26635.094] (II) event4  - Apple, Inc Apple Keyboard: device removed
> [ 28690.158] (II) event3  - Apple, Inc Apple Keyboard: is tagged by udev as: 
> Keyboard
> [ 28690.158] (II) event3  - Apple, Inc Apple Keyboard: device is a keyboard
> [ 28690.159] (II) event4  - Apple, Inc Apple Keyboard: is tagged by udev as: 
> Keyboard
> [ 28690.159] (II) event4  - Apple, Inc Apple Keyboard: device is a keyboard

Vincent, is this still something you are able to reproduce with a
recent kernel? If not, should we close the bug? If yes, any more
insights since the last report?

Regards,
Salvatore

Bug#988231: gnu-efi: package for riscv64

[Julian Andres Klode]

On Sat, May 08, 2021 at 10:51:13AM +0200, Heinrich Schuchardt wrote:
> Package: gnu-efi
> Version: 3.0.9-2
> Severity: wishlist
> 
> gnu-efi is a build dependency for a bunch of other packages. Currently
> it is missing on RISC-V.
> 
> My patches to support riscv64 were merged with commit 3676bc353c83
> ("Merge /u/xypron/gnu-efi/ branch riscv64 into master").
> 
> Please, consider packaging for riscv64. I guess due to the freeze this
> would have to go to experimental first.

Once there is a new upstream release, and we're past the freeze, happy
to update it. Not really interested in cherry picking changes, neither
uploading to experimental before the freeze as it will have next to no
use.

-- 
debian developer - deb.li/jak | jak-linux.org - free software dev
ubuntu core developer  i speak de, en

Bug#988238: libnet-sip-perl: several crashing bugs (solved since upstream release 0.829)

[Jonas Smedegaard]

Package: libnet-sip-perl
Version: 0.828-1
Severity: important
Tags: upstream

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Upstream release 0.829 of NET::SIP issued on 2021-05-04 fixes several
crashing bugs:

* fix crash introduced in 0.827 when trying to be smarter about timers
  (actually, this just made an error already introduced in 2007
  way more likely)
* Propagate timeout errors on TCP connect via callback
  
* If a URL explicitly specified a port number
  this will take precedence to any port number set in the SRV record
  when resolving the URL.
  
* resolver: make sure to consider a response for TCP
  even if one for UDP was already returned, but the leg is TCP only.
  Do not send DNS SRV queries for protocols not supported by the legs
  


 - Jonas

-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEn+Ppw2aRpp/1PMaELHwxRsGgASEFAmCWhSEACgkQLHwxRsGg
ASF/rw/+OlH/O9UWxukgOWVVZU7Z6kqBtkH+HuCGQI31dzEOeTBJyZTgLSuG9B55
6Dbv19uvUVNVHl+qSERNwOaJtoy6pxCBLhF3JjAs1ZxiYbAiDqrzrD4ADA1XD2h1
jacTQhigNM6+hjlZ2Ey+R4PGX78Qxdl6pv2XfQV2ufVGV5sCPZJ7i46oY7mZq39i
y8fjGpTohhBJAF/yCkU4PR92eGQq39N1p6hJiMbtIvxAJ4c3wk1l4mz1tVFuvyrJ
itO/ujoddBZ0pkWjEvJMukxhU8IXBg1YJ838SfanVQnzKBbA3fLhcYZG4y2WDACM
jp+LeFQlwt39hXEIVyX9w0ucXlAhEJ6enMD2S3i/tFY3VI/6sW66plhLRTR8xY82
t3kg5i9305e+wVhV6ntRxS5CCkZI2sSfk3u0xi+g4p5MRJXwoH+OFF1XtSacJf/G
IlXLWGDB5jJpHfRYgSZUHz0plOvc2Yzb1Cu9MeU99IBH5KHuCg9eH1D+yt3nLJEm
T2JqIreAbA3oKHVl9fmOpVPGhf7GMMk3e0oauYiJyOnGxiYdz/qGq9XpSIeZNE0S
HrHQVyahNr0TOZyeoyBTQ9RiWnLh2rtgKzDGmPL1ZGs6hzFCq/Nx2fV08Hp4oNC3
x84kKUZl6yFCvUcyLgmQppk3TYELOPOu9Uk+RNF/JejhhJ5a/R0=
=nZm6
-END PGP SIGNATURE-