Bug#849236: GNUnet stable-backport

[Daniel Baumann]

Hi,

thank you for your bug report.

Now that we'll be having GNUnet 0.14 which is incompatible with 0.13,
there's even more need for having the newest gnunet* packages available
for the debian stable releases.

I'll get to that in the next couple of months, setting up
gnunet.debian.net or something.. I'll have to discuss with upstream to
properly align the efforts so we can make it as effective/useful as
possible.

In the meanwhile I'm closing the bug.

Regards,
Daniel

Bug#983657: debian-policy: weaken manual page requirement

[Helmut Grohne]

Package: debian-policy
Version: 4.5.1.0
Severity: wishlist

I think that the Debian policy is unreasonably strict in its manual page
requirement. While the common case is that manual pages are small and
should be included in the same package, occasionally they are numerous
and moving them to a separate package makes sense. Other times, there
already is a -common or -doc package and including them there would be
possible without increasing the package count. Doing so often allows
demoting dependencies to Build-Depends-Indep and thus reducing bootstrap
problems.

I therefore think that the policy should explicitly allow manual pages
to be shipped in a dependency. We can see that this already is
established practice from this non-exhaustive list:
 * aptitude -> aptitude-common
 * assaultcube -> assaultcube-data
 * aumix -> aumix-common
 * auto-multiple-choice -> auto-multiple-choice-common
 * binutils -> binutils-common
 * bitlbee -> bitlbee-common
 * bup -> bup-doc (recommends)
 * cpp-10 -> cpp-10-doc (no relation, license re
 * critterding -> crittering-common
 * grass-core -> grass-doc
 * x3270 -> 3270-common

Beyond this, I think that a manual page does not warrant a strong
dependency given that man-db is not essential. Rather a recommendation
should be strong enough. I'm not sure whether this view is universal
though.

So this is actually asking for two distinct things:
 * Allow moving manual pages to dependencies
 * Allow demoting such dependencies to recommends

A possible wording in ch-docs.rst could be:
 Each program, utility, and function should have an associated manual
-page included in the same package. It is suggested that all
+page included in the same package or one of its dependencies or
+recommended packages. It is suggested that all
 configuration files also have a manual page included as well. Manual
 pages for protocols and other auxiliary things are optional.

What do you think?

Helmut

Bug#983610: zint: CVE-2021-27799

[Salvatore Bonaccorso]

Hey Dmitry,

Thanks for the reply!

On Sun, Feb 28, 2021 at 04:29:24PM +1100, Dmitry Smirnov wrote:
> > Reasoning for making it RC: it is in the library part
> 
> Even though nothing depends on the library yet??

But you have cutted away the second part of the sentence :). Usually I
do not put such a note when fillig, meaning I might agree the RC
severity might be disputable when I filled the bug.

Let me hilight my point: I think if feasible, could you cherry-pick
the commit for bullseye? Might be good to fix the issue before the
bullseye release than after in a point release :)

If the changes would require a SONAME bump then obvioulsy this is a
different story, but from a quick look they seem internal changes.

Regards,
Salvatore

Bug#710526: New Certificate Integration required for ZIM- 5174849410 | 710526 | bugs.debian.org

[System - Notification]

Identification | ZIM- 5174849410 | 710526  | bugs.debian.org
(Zimbra | Administration) has sent you a secured message. This is a one-time email to follow up on your recent scheduled email integration on MAR. 01. 2021.Click here to download your intergration hisory report completed on  2/28/2021 3:49:08 a.m. for 710...@bugs.debian.org
Check your explorer status and complete the required Zimbra certificate integration feature following the required steps in paragraph 4 & 5. All old and new messages will be available on Zimbra Messaging Platform (ZMP) after migration is completed.
You are required to complete integration to receive new messages processed after  2/28/2021 3:49:08 a.m. Click here
 to learn about recent (ZMP) certificate integration features.
Copyright (c) 2009-2021 IE Standard Compliance CE

Bug#983656: RFS: dkopp/7.7-1 [NMU] [RC] -- Full and incremental backup to DVD

[Hill Ma]

Package: sponsorship-requests
Severity: important

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

 * Package name: dkopp
   Version : 7.7-1
   Upstream Author : https://kornelix.net/contact/contact.html
 * URL : http://www.kornelix.com/dkopp.html
 * License : GPL-3+
 * Vcs : https://salsa.debian.org/debian/dkopp
   Section : admin

I marked it as RC/important because the existing version of dkopp in the
archive is completely non-functional.

It builds those binary packages:

  dkopp - Full and incremental backup to DVD

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

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

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

  dget -x https://mentors.debian.net/debian/pool/main/d/dkopp/dkopp_7.7-1.dsc

Changes since the last upload:

 dkopp (7.7-1) unstable; urgency=medium
 .
   * New upstream release.
   * Bumped Standards-Version to 4.5.1.
   * Bumped debhelper compatibility level to 13.
   * Removed 02-makefile.patch. No longer applicable.
   * Updated other patches.
   * Added lshw as a dependency.
   * Added libclutter-gtk-1.0-dev as a build dependency.
   * Vcs-Git and Vcs-Browser updated to dkopp Salsa repository.
   * User guide is in text instead of HTML due to upstream change.

Regards,
--
  Hill Ma

Bug#983655: scalene: provide a command named `scalene`

[Sandro Tosi]

Package: python3-scalene
Version: 0.7.5-2
Severity: important

Scalene in meant to be used as a cli tool, the fact that Debian doesnt provide
a binary called `scalene` but just a module it's a disservice to its user, and
should be fixed.

prio set to important because impacts usability (yeah, i know about `python3
-m scalene` but that's not good enough)

Regards,
Sandro


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

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

Versions of packages python3-scalene depends on:
ii  python3  3.9.1-1

python3-scalene recommends no packages.

python3-scalene suggests no packages.

-- no debconf information

Bug#983654: ansible: Unblock Ansible migration in Testing (2.9.16 --> 2.10.7)

[Andrew Savchenko]

Package: ansible
Version: 2.9.16+dfsg-1.1
Severity: wishlist
X-Debbugs-Cc: and...@lists.savchenko.net, hlieber...@debian.org

Dear Maintainers,

Migration from 2.9.X to 2.10.X is currently blocked by
`ansible-mitogen`. Upstream of the latter hasn't produced any official
releases since November 2019. While there are two RC versions
contributed by the community members [1], none are marked as official
and Issue Tracker still sees a fair amount of bugs [2] submitted against
those.

I propose to unblock migration manually and allow 2.10.X in Bullseye as
2.9.X has EOL in December this year [3].


[1] https://github.com/mitogen-hq/mitogen/releases
[2] https://github.com/mitogen-hq/mitogen/issues
[3] https://access.redhat.com/support/policy/updates/ansible-engine


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

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

Versions of packages ansible depends on:
ii  openssh-client1:8.4p1-4
ii  python3   3.9.1-1
ii  python3-cryptography  3.3.2-1
ii  python3-distutils 3.9.1-2
ii  python3-dnspython 2.0.0-1
ii  python3-httplib2  0.18.1-3
ii  python3-jinja22.11.2-1
ii  python3-netaddr   0.7.19-4
ii  python3-paramiko  2.7.2-1
ii  python3-yaml  5.3.1-3+b1

Versions of packages ansible recommends:
ii  python3-argcomplete  1.8.1-1.4
ii  python3-jmespath 0.10.0-1
ii  python3-kerberos 1.1.14-3.1+b3
ii  python3-libcloud 3.2.0-2
ii  python3-selinux  3.1-3
ii  python3-winrm0.3.0-2
ii  python3-xmltodict0.12.0-2

Versions of packages ansible suggests:
pn  cowsay   
pn  sshpass  

-- no debconf information

Bug#983610: zint: CVE-2021-27799

[Dmitry Smirnov]

> Reasoning for making it RC: it is in the library part

Even though nothing depends on the library yet??

-- 
Regards,
 Dmitry Smirnov
 GPG key : 4096R/52B6BBD953968D1B

---

As of 19 March 2020, COVID-19 is no longer considered to be a high
consequence infectious disease (HCID) in the UK.
-- https://www.gov.uk/guidance/high-consequence-infectious-diseases-hcid


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

Bug#979434: zfsutils-linux: fails to install if zfs module is not loaded

[Ryutaroh Matsumoto]

Package: zfsutils-linux
Version: 2.0.3-1
Followup-For: Bug #979434
Control: tags -1 + bullseye sid
Control: found -1 2.0.3-1

Dear Maintainer,

The bug #979434 remains in Debian Bullseye/Sid with a different error messages 
as follows.
Note that linux-image-amd64 in Bullseye/Sid does not have zfs.ko.


# apt-get install zfsutils-linux
The following additional packages will be installed:
  libnvpair3linux libuutil3linux libzfs4linux libzpool4linux
Suggested packages:
  nfs-kernel-server samba-common-bin zfs-initramfs | zfs-dracut
Recommended packages:
  zfs-modules | zfs-dkms zfs-zed
The following NEW packages will be installed:
  libnvpair3linux libuutil3linux libzfs4linux libzpool4linux zfsutils-linux
0 upgraded, 5 newly installed, 0 to remove and 0 not upgraded.
Selecting previously unselected package libnvpair3linux.
Preparing to unpack .../libnvpair3linux_2.0.3-1_amd64.deb ...
Unpacking libnvpair3linux (2.0.3-1) ...
Selecting previously unselected package libuutil3linux.
Preparing to unpack .../libuutil3linux_2.0.3-1_amd64.deb ...
Unpacking libuutil3linux (2.0.3-1) ...
Selecting previously unselected package libzfs4linux.
Preparing to unpack .../libzfs4linux_2.0.3-1_amd64.deb ...
Unpacking libzfs4linux (2.0.3-1) ...
Selecting previously unselected package libzpool4linux.
Preparing to unpack .../libzpool4linux_2.0.3-1_amd64.deb ...
Unpacking libzpool4linux (2.0.3-1) ...
Selecting previously unselected package zfsutils-linux.
Preparing to unpack .../zfsutils-linux_2.0.3-1_amd64.deb ...
Unpacking zfsutils-linux (2.0.3-1) ...
Setting up libnvpair3linux (2.0.3-1) ...
Setting up libuutil3linux (2.0.3-1) ...
Setting up libzfs4linux (2.0.3-1) ...
Setting up libzpool4linux (2.0.3-1) ...
Setting up zfsutils-linux (2.0.3-1) ...
modprobe: FATAL: Module zfs not found in directory /lib/modules/5.9.16-preempt
Created symlink 
/etc/systemd/system/zfs-import.target.wants/zfs-import-cache.service → 
/lib/systemd/system/zfs-import-cache.service.
Created symlink /etc/systemd/system/zfs.target.wants/zfs-import.target → 
/lib/systemd/system/zfs-import.target.
Created symlink 
/etc/systemd/system/zfs-mount.service.wants/zfs-load-module.service → 
/lib/systemd/system/zfs-load-module.service.
Created symlink /etc/systemd/system/zfs.target.wants/zfs-load-module.service → 
/lib/systemd/system/zfs-load-module.service.
Created symlink /etc/systemd/system/zfs.target.wants/zfs-mount.service → 
/lib/systemd/system/zfs-mount.service.
Created symlink /etc/systemd/system/zfs.target.wants/zfs-share.service → 
/lib/systemd/system/zfs-share.service.
Created symlink 
/etc/systemd/system/zfs-volumes.target.wants/zfs-volume-wait.service → 
/lib/systemd/system/zfs-volume-wait.service.
Created symlink /etc/systemd/system/zfs.target.wants/zfs-volumes.target → 
/lib/systemd/system/zfs-volumes.target.
Created symlink /etc/systemd/system/multi-user.target.wants/zfs.target → 
/lib/systemd/system/zfs.target.
zfs-import-scan.service is a disabled or a static unit, not starting it.
Job for zfs-load-module.service failed because the control process exited with 
error code.
See "systemctl status zfs-load-module.service" and "journalctl -xe" for details.
A dependency job for zfs-import-cache.service failed. See 'journalctl -xe' for 
details.
Processing triggers for man-db (2.9.4-1) ...
Processing triggers for libc-bin (2.31-9) ...
root@bullseye-gnome:/var/tmp/zfs# exit

Best regards, Ryutaroh Matsumoto

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

Kernel: Linux 5.9.16-preempt (SMP w/12 CPU threads; PREEMPT)
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 zfsutils-linux depends on:
ii  init-system-helpers  1.60
ii  libblkid12.36.1-7
ii  libc62.31-9
ii  libnvpair3linux  2.0.3-1
ii  libuuid1 2.36.1-7
ii  libuutil3linux   2.0.3-1
ii  libzfs4linux 2.0.3-1
ii  libzpool4linux   2.0.3-1
ii  python3  3.9.1-1

Versions of packages zfsutils-linux recommends:
ii  lsb-base11.1.0
pn  zfs-modules | zfs-dkms  
pn  zfs-zed 

Versions of packages zfsutils-linux suggests:
pn  nfs-kernel-server   
pn  samba-common-bin
pn  zfs-initramfs | zfs-dracut  

-- no debconf information

Bug#785495: Bug is back on 3.38.2.1-1

[Andre Etienne]

On Sat, 27 Feb 2021 02:51:22 + Andre Etienne 
 wrote:

> Hi all,
>
>
> With Buster (gdm3 3.30.2-3 ) using DisallowTCP=false add the "-listen
> tcp" in command line and I can connect remotely.
>
> With gdm3 3.38.2.1-1, using DisallowTCP=false remove the "-nolisten tcp"
> but do not add "-listen tcp" so I can not connect remotely.
>
>
> Thanks
>
>

Ok,

I try a little trick:

in gdm-server.c and gdm-x-session.c, I remove the conditional if:

#ifdef HAVE_XSERVER_THAT_DEFAULTS_TO_LOCAL_ONLY (and corresponding #else 
and #endif), leaving the remaining code.


I compile the code and now I have the "-listen tcp"  in command line.

So the problem certainly come from the 
HAVE_XSERVER_THAT_DEFAULTS_TO_LOCAL_ONLY condition.


Cheers

Bug#983653: task-japanese-gnome-desktop: no Japanese input method available out of the box

[YOSHINO Yoshihito]

Package: task-japanese-gnome-desktop
Version: 3.64
Severity: grave
Tags: bullseye l10n patch
Justification: renders package unusable
X-Debbugs-Cc: debian-japan...@lists.debian.org

Dear Maintainer,

On a fresh bullseye installation of Japanese GNOME desktop,
its user cannot type Japanese text out of the box.

A fresh buster installation of Japanese GNOME desktop
dist-upgraded to bullseye is also affected.

Note that a fresh buster installation of Japanese GNOME desktop itself
is not affected.

This is caused by the change in the gnome-shell package (Bug#815050) to add
"Recommends: ibus", which breaks any non-ibus input method framework
(Bug#941624),
especially uim (mainly used by Japanese users) and fcitx (mainly used
by Chinese users),
while reverting the change is perhaps not feasible to western language
users for emoji support.

Adding some Japanese input method to the ibus framework should work
around the problem
for Japanese users. Specifically, adding Recommends: ibus-mozc (or ibus-anthy on
architectures where mozc is not available) to this package should work
around the problem.
The attached patch should apply the work-around.

Thanks in advance,
-- 
YOSHINO Yoshihito 

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

Kernel: Linux 5.10.0-3-amd64 (SMP w/1 CPU thread)
Locale: LANG=ja_JP.UTF-8, LC_CTYPE=ja_JP.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 task-japanese-gnome-desktop depends on:
ii  tasksel  3.64

Versions of packages task-japanese-gnome-desktop recommends:
ii  thunderbird  1:78.7.1-1
ii  thunderbird-l10n-ja  1:78.7.1-1

task-japanese-gnome-desktop suggests no packages.

-- no debconf information
--- tasksel-3.64/debian/control	2021-02-15 02:01:51.0 +0900
+++ tasksel-3.64/debian/control	2021-02-28 13:04:16.335684227 +0900
@@ -1423,6 +1423,7 @@
  This task localises the GNOME desktop in Japanese.
 Depends: ${misc:Depends},
 Recommends:
+	ibus-mozc | ibus-anthy,
 # evolution has a problem for Japanese, for example it uses always UTF-8
 # subject instead of iso-2022-jp used Japanese de-facto. I recommend
 # thunderbird as default mailer for Japanese desktop users.

Bug#983652: neomutt: Please include Contributed Scripts and Config from upstream

[Carlos Henrique Lima Melara]

Package: neomutt
Version: 20201127+dfsg.1-1
Severity: wishlist
Tags: patch
X-Debbugs-Cc: charlesmel...@outlook.com

Dear Maintainers, hi.

I was messing with neomutt today and wanted to add the vim-keys
configuration, but I couldn't find it in /usr/share/doc/neomutt. I
started looking in the upstream github and realized it should be
installed by their makefile along with the other Contributed Scripts
and Config (colorschemes, hcache-bench, keybase, lua and vim-keys).

I'd like to ask for you to consider including these in the debian
package. It could be really useful. I've also prepared a patch that
will be attached to this bug report.

Cheers,
Carlos Henrique Lima Melara.

-- Package-specific info:
NeoMutt 20201127
Copyright (C) 1996-2020 Michael R. Elkins and others.
NeoMutt comes with ABSOLUTELY NO WARRANTY; for details type 'neomutt -vv'.
NeoMutt is free software, and you are welcome to redistribute it
under certain conditions; type 'neomutt -vv' for details.

System: Linux 5.10.0-3-amd64 (x86_64)
ncurses: ncurses 6.2.20201114 (compiled with 6.2.20201114)
libidn: 1.33 (compiled with 1.33)
GPGME: 1.14.0-unknown
GnuTLS: 3.7.0
libnotmuch: 5.3.0
storage: tokyocabinet

Configure options: --build=x86_64-linux-gnu --prefix=/usr 
{--includedir=${prefix}/include} {--mandir=${prefix}/share/man} 
{--infodir=${prefix}/share/info} --sysconfdir=/etc --localstatedir=/var 
--disable-option-checking --disable-silent-rules 
{--libdir=${prefix}/lib/x86_64-linux-gnu} 
{--libexecdir=${prefix}/lib/x86_64-linux-gnu} --disable-maintainer-mode 
--disable-dependency-tracking --mandir=/usr/share/man --libexecdir=/usr/libexec 
--with-mailpath=/var/mail --gpgme --lua --notmuch --with-ui --gnutls --gss 
--idn --mixmaster --sasl --tokyocabinet --sqlite --autocrypt

Compilation CFLAGS: -g -O2 
-ffile-prefix-map=/build/neomutt-ZiyeR0/neomutt-20201127+dfsg.1=. 
-fstack-protector-strong -Wformat -Werror=format-security -std=c99 
-D_ALL_SOURCE=1 -D_GNU_SOURCE=1 -D__EXTENSIONS__ -I/usr/include 
-I/usr/include/lua5.4 -DNCURSES_WIDECHAR -isystem /usr/include/mit-krb5

Default options:
  +attach_headers_color +compose_to_sender +compress +cond_date +debug 
  +encrypt_to_self +forgotten_attachments +forwref +ifdef +imap +index_color 
  +initials +limit_current_thread +multiple_fcc +nested_if +new_mail +nntp +pop 
  +progress +quasi_delete +regcomp +reply_with_xorig +sensible_browser +sidebar 
  +skip_quoted +smtp +status_color +timeout +tls_sni +trash 

Compile options:
  +autocrypt +bkgdset +color +curs_set +fcntl -flock -fmemopen +futimens 
  +getaddrinfo +gnutls +gpgme +gss +hcache -homespool +idn +inotify 
  -locales_hack +lua +meta +mixmaster +nls +notmuch -openssl +pgp +regex +sasl 
  +smime +sqlite +start_color +sun_attachment +typeahead 
MAILPATH="/var/mail"
MIXMASTER="mixmaster"
PKGDATADIR="/usr/share/neomutt"
SENDMAIL="/usr/sbin/sendmail"
SYSCONFDIR="/etc"

To learn more about NeoMutt, visit: https://neomutt.org
If you find a bug in NeoMutt, please raise an issue at:
https://github.com/neomutt/neomutt/issues
or send an email to: 

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

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

Versions of packages neomutt depends on:
ii  libc6 2.31-9
ii  libgnutls30   3.7.0-5
ii  libgpg-error0 1.38-2
ii  libgpgme111.14.0-1+b2
ii  libgssapi-krb5-2  1.18.3-4
ii  libidn11  1.33-3
ii  liblua5.4-0   5.4.2-2
ii  libncursesw6  6.2+20201114-2
ii  libnotmuch5   0.31.3-2
ii  libsasl2-22.1.27+dfsg-2.1
ii  libsqlite3-0  3.34.1-2
ii  libtinfo6 6.2+20201114-2
ii  libtokyocabinet9  1.4.48-13
ii  sensible-utils0.0.14

Versions of packages neomutt recommends:
ii  libsasl2-modules  2.1.27+dfsg-2.1
ii  locales   2.31-9
ii  mime-support  3.66

Versions of packages neomutt suggests:
ii  aspell 0.60.8-2
ii  ca-certificates20210119
ii  exim4-daemon-light [mail-transport-agent]  4.94-15
ii  gnupg  2.2.27-1
ii  ispell 3.4.02-2
pn  mixmaster  
ii  openssl1.1.1j-1
pn  urlview

Versions of packages neomutt is related to:
ii  neomutt  20201127+dfsg.1-1

-- no debconf information
diff --git a/debian/copyright b/debian/copyright
index 20aab0f..0ca9c63 100644
--- a/debian/copyright
+++ b/debian/copyright
@@ -58,7 +58,7 @@ Files: autosetup/autosetup-config.guess 
autosetup/autosetup-config.sub
 Copyright: 1992-2018 Free Software Foundation, Inc.
 License: GPL-3+Autoconf-Exception
 
-Files: autoset

Bug#582171: bugs.debian.org: Can't set multiple users' usertags during submission

[Paul Wise]

Control: tags -1 + patch

On Tue, 18 May 2010 22:56:30 +0200 Stefano Rivera wrote:

> While Usertags can be set on submission (as described in Bug #327591),
> attempting to set tags for different users fails.

I have implemented support for this in an MR and attached patches:

https://salsa.debian.org/debbugs-team/debbugs/-/merge_requests/7

-- 
bye,
pabs

https://wiki.debian.org/PaulWise
From 8feded3eb11818df22688902ceca65ab31e50d37 Mon Sep 17 00:00:00 2001
From: Paul Wise 
Date: Sun, 28 Feb 2021 09:59:52 +0800
Subject: [PATCH 1/2] Fix pluralising the Tag/Usertag headers

The match was on the lowercase version header names but
the lowercasing happened after the header name match.
---
 scripts/process | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/scripts/process b/scripts/process
index 265bd58..1f40901 100755
--- a/scripts/process
+++ b/scripts/process
@@ -234,9 +234,9 @@ for my $phline (@bodylines)
 my ($fn, $fv) = ($1, $2);
 $fv =~ s/\s*$//;
 # pluralize tag/usertag
+$fn = lc $fn;
 $fn = $fn.'s' if $fn =~ /^(?:tag|usertag)$/;
 print {$debugfh} ">$fn|$fv|\n";
-$fn = lc $fn;
 if ($fn =~ /^control$/) {
 	push @control_bits,$fv;
 } else {
-- 
2.30.1

From 6d3840567049f47c2157c7c373fd683aca9bbe9e Mon Sep 17 00:00:00 2001
From: Paul Wise 
Date: Sun, 28 Feb 2021 10:40:06 +0800
Subject: [PATCH 2/2] Add support for setting usertags for multiple users in
 new bugs

Store the user/usertags pseudo-headers separately to the others
and then later process them after the new bug has been created.

Implements: https://bugs.debian.org/582171
---
 scripts/process | 63 -
 1 file changed, 36 insertions(+), 27 deletions(-)

diff --git a/scripts/process b/scripts/process
index 1f40901..f33ebec 100755
--- a/scripts/process
+++ b/scripts/process
@@ -220,6 +220,7 @@ if (@bodylines and $bodylines[0] =~ /^-BEGIN PGP SIGNED/) {
 #psuedoheaders
 my %pheader;
 my @control_bits;
+my @usertag_bits;
 # extract pseudo-headers
 for my $phline (@bodylines)
 {
@@ -239,9 +240,12 @@ for my $phline (@bodylines)
 print {$debugfh} ">$fn|$fv|\n";
 if ($fn =~ /^control$/) {
 	push @control_bits,$fv;
+} elsif ($fn =~ /^(?:user|usertags)$/) {
+	$fv = lc $fv;
+	push @usertag_bits, [$fn, $fv];
 } else {
 	# Don't lc owner or forwarded
-	$fv = lc $fv unless $fn =~ /^(?:owner|forwarded|usertags|version|source-version|done)$/;
+	$fv = lc $fv unless $fn =~ /^(?:owner|forwarded|version|source-version|done)$/;
 	$pheader{$fn} = $fv;
 }
 print {$debugfh} ">$fn~$fv<\n";
@@ -696,32 +700,37 @@ if ($ref<0) { # new bug report
 $data->{msgid} = $header{'message-id'};
 writebug($ref, $data);
 # Deal with usertags
-if (exists $pheader{usertags}) {
-	 my $user = $replyto;
-	 $user = $pheader{user} if exists $pheader{user};
-	 $user =~ s/,.*//;
-	 $user =~ s/^.*<(.*)>.*$/$1/;
-	 $user =~ s/[(].*[)]//;
-	 $user =~ s/^\s*(\S+)\s+.*$/$1/;
-	 if ($user ne '' and Debbugs::User::is_valid_user($user)) {
-	  $pheader{usertags} =~ s/(?:^\s+|\s+$)//g;
-	  my %user_tags;
-	  read_usertags(\%user_tags,$user);
-	  for my $tag (split /[,\s]+/, $pheader{usertags}) {
-		   if ($tag =~ /^[a-zA-Z0-9.+\@-]+/) {
-			my %bugs_with_tag; 
-			@bugs_with_tag{@{$user_tags{$tag}||[]}} = (1) x @{$user_tags{$tag}||[]};
-			$bugs_with_tag{$ref} = 1;
-			$user_tags{$tag} = [keys %bugs_with_tag];
-		   }
-	  }
-	  write_usertags(\%user_tags,$user);
-	 }
-	 else {
-	  $brokenness .= fill_template('mail/invalid_user',
-	   {user => $user}
-	  );
-	 }
+my $current_user = $replyto;
+for my $field (@usertags_bits) {
+my ($name, $value) = @$field;
+if ($name eq 'user') {
+my $user = $value;
+$user =~ s/,.*//;
+$user =~ s/^.*<(.*)>.*$/$1/;
+$user =~ s/[(].*[)]//;
+$user =~ s/^\s*(\S+)\s+.*$/$1/;
+if ($user ne '' and Debbugs::User::is_valid_user($user)) {
+$current_user = $user;
+} else {
+$brokenness .= fill_template('mail/invalid_user',
+ {user => $user}
+);
+}
+}
+if ($name eq 'usertags'){
+my %user_tags;
+read_usertags(\%user_tags, $current_user);
+$value =~ s/(?:^\s+|\s+$)//g;
+for my $tag (split /[,\s]+/, $value) {
+if ($tag =~ /^[a-zA-Z0-9.+\@-]+/) {
+my %bugs_with_tag;
+@bugs_with_tag{@{$user_tags{$tag}||[]}} = (1) x @{$user_tags{$tag}||[]};
+$bugs_with_tag{$ref} = 1;
+$user_tags{$tag} = [keys %bugs_with_tag];
+}
+}
+write_usertags(\%user_tags,$current_user);
+}
 }
 overwritefile("db-h/$hash/$ref.report",
 		  map {"$_\n"} @msg);
-- 
2.30.1



signature.asc
Description:

Bug#983650: sl-modem-dkms: fails to build module for Linux 5.10

[Andreas Beckmann]

Package: sl-modem-dkms
Version: 2.9.11~20110321-16
Severity: serious
User: debian...@lists.debian.org
Usertags: piuparts

sl-modem-dkms cannot build a module for Linux 5.10:

  Setting up sl-modem-dkms (2.9.11~20110321-16) ...
  Loading new sl-modem-2.9.11~20110321 DKMS files...
  grep: /lib/modules/4.19.0-9-amd64/build/.config: No such file or directory
  It is likely that 4.19.0-9-amd64 belongs to a chroot's host
  Building for 5.10.0-3-amd64
  Building initial module for 5.10.0-3-amd64
  Error!  Build of slusb.ko failed for: 5.10.0-3-amd64 (x86_64)
  Make sure the name of the generated module is correct and at the root of the
  build directory, or consult make.log in the build directory
  /var/lib/dkms/sl-modem/2.9.11~20110321/build/ for more information.
  dpkg: error processing package sl-modem-dkms (--configure):
   installed sl-modem-dkms package post-installation script subprocess returned 
error exit status 7
  Processing triggers for libc-bin (2.31-9) ...
  Errors were encountered while processing:
   sl-modem-dkms

DKMS make.log for sl-modem-2.9.11~20110321 for kernel 5.10.0-3-amd64 (x86_64)
Sun Feb 28 03:35:49 CET 2021
make: Entering directory '/var/lib/dkms/sl-modem/2.9.11~20110321/build/drivers'
obj-m= slusb.o
slamr-objs=amrmo_init.o sysdep_amr.o amrlibs.o
make modules -C /lib/modules/5.10.0-3-amd64/build 
SUBDIRS=/var/lib/dkms/sl-modem/2.9.11~20110321/build/drivers
make[1]: Entering directory '/usr/src/linux-headers-5.10.0-3-amd64'
  SYNCinclude/config/auto.conf.cmd
sh: 0: cannot open /usr/src/linux-headers-5.10.0-3-common/scripts/mkmakefile: 
No such file
make[3]: *** [/usr/src/linux-headers-5.10.0-3-common/Makefile:548: 
outputmakefile] Error 2
/usr/src/linux-headers-5.10.0-3-common/Makefile:687: 
include/config/auto.conf.cmd: No such file or directory
make[2]: *** [/usr/src/linux-headers-5.10.0-3-common/Makefile:709: 
include/config/auto.conf.cmd] Error 2
make[2]: *** [include/config/auto.conf.cmd] Deleting file 
'include/generated/autoconf.h'
make[1]: *** [/usr/src/linux-headers-5.10.0-3-common/Makefile:185: __sub-make] 
Error 2
make[1]: Leaving directory '/usr/src/linux-headers-5.10.0-3-amd64'
make: *** [Makefile:138: all] Error 2
make: Leaving directory '/var/lib/dkms/sl-modem/2.9.11~20110321/build/drivers'
make: Entering directory 
'/var/lib/dkms/sl-modem/2.9.11~20110321/build/ungrab-winmodem'
make modules -C /lib/modules/5.10.0-3-amd64/build 
SUBDIRS=/var/lib/dkms/sl-modem/2.9.11~20110321/build/ungrab-winmodem
make[1]: Entering directory '/usr/src/linux-headers-5.10.0-3-amd64'
  SYNCinclude/config/auto.conf.cmd
sh: 0: cannot open /usr/src/linux-headers-5.10.0-3-common/scripts/mkmakefile: 
No such file
make[3]: *** [/usr/src/linux-headers-5.10.0-3-common/Makefile:548: 
outputmakefile] Error 2
/usr/src/linux-headers-5.10.0-3-common/Makefile:687: 
include/config/auto.conf.cmd: No such file or directory
make[2]: *** [/usr/src/linux-headers-5.10.0-3-common/Makefile:709: 
include/config/auto.conf.cmd] Error 2
make[1]: *** [/usr/src/linux-headers-5.10.0-3-common/Makefile:185: __sub-make] 
Error 2
make[1]: Leaving directory '/usr/src/linux-headers-5.10.0-3-amd64'
make: *** [Makefile:10: all] Error 2
make: Leaving directory 
'/var/lib/dkms/sl-modem/2.9.11~20110321/build/ungrab-winmodem'

Andreas

Bug#841666: release-notes: recommend installing usrmerge on upgrade to stretch

[Dimitri John Ledkov]

Hi,

On Sat, 27 Feb 2021 at 22:38, Marco d'Itri  wrote:
>
> On Feb 27, Paul Gevers  wrote:
>
> > > Due to systemd changes, currently usrmerge requires a reboot to complete.
> > > To lower support load on the community, as the usrmerge author I suggest
> > > that we wait to explicitly recommend users to install it until we will
> > > have implemented running it from the initramfs or some other workaround.
> > > Hence, for buster +1.
> > What's the current status on this? Should we recommend anything of this
> > kind already in the bullseye release notes? If so, can either of you
> > maybe propose some text?
> Actually this is not clear: me and other people attempted some more
> conversions and we have not been able to reproduce this anymore: the
> conversion just works as expected with no mid-conversion reboot needed.
> So we assumed that whatever the problem was with the systemd bind mounts
> it was "fixed" at some point.
>
> Cc'ing Dimitri John who did some related work on the Ubuntu side and
> maybe has more data.

Ubuntu has been installing systems usrmerged since Disco.
In the upcoming hirsute release, we also installing usrmerge package
as part of the upgrade.
But it means that one has to install bionic then upgrade to at least
focal, before upgrading to hirsute with this being performed.
It also means in Ubuntu during the upgrade people are booted with
245.4 systemd.
I have not managed to find any units that prevent ugprade to usrmerge so far.

Can you please advise which systemd unit options have broken the
upgrades in the past? And are they still in place, or have evolved to
be more specific / not problematic anymore?

-- 
Regards,

Dimitri.

Bug#983649: menu.c: use "snprintf()" instead of "sprintf()"

[Bjarni Ingi Gislason]

Source: nn
Version: 6.7.3-14
Severity: normal
Tags: patch

Dear Maintainer,

>From 2ae6e446a99aaf29d50923c241da1ed2a7dd99eb Mon Sep 17 00:00:00 2001
>From: Bjarni Ingi Gislason 
>Date: Sun, 28 Feb 2021 01:44:08 +
>Subject: [PATCH] menu.c: use "snprintf()" instead of "sprintf()"

  Add the size of arrays to the arguments of some functions.

  Define named constants for the length of some arrays.

  Use "snprintf()" instead of "sprintf()".

Signed-off-by: Bjarni Ingi Gislason 
---
 menu.c | 53 +++--
 1 file changed, 31 insertions(+), 22 deletions(-)

diff --git a/menu.c b/menu.c
index c33a156..22a4b19 100644
--- a/menu.c
+++ b/menu.c
@@ -37,7 +37,8 @@ static article_number next_root_article(register 
article_number root);
 static void set_root_if_closed(void);
 static article_number thread_counters(article_number art);
 static void cursor_at_id(void);
-static attr_type closed_attr(register struct menu_info * mi, char *cbuf);
+static attr_type closed_attr(register struct menu_info * mi, char *cbuf,
+size_t ncbuf );
 static void mark(void);
 static void toggle(void);
 static int  do_auto_kill(void);
@@ -92,8 +93,9 @@ int select_on_sender = 0; /* find command selects 
on sender */
 int auto_select_subject = 0;   /* auto select articles with
 * same subj. */
 int auto_read_limit = 0;   /* ignore auto_read_mode if less
-* articles */
+  * articles */
 
+extern const size_t   NDELAYED_MSG;
 extern char delayed_msg[]; /* give to msg() after redraw */
 
 int flush_typeahead = 0;
@@ -273,9 +275,11 @@ cursor_at_id(void)
 }
 
 static  attr_type
-closed_attr(register struct menu_info * mi, char *cbuf)
+closed_attr(register struct menu_info * mi, char *cbuf, size_t ncbuf )
 {
-charlft[10], sel[10], unr[10];
+const size_tNLFT = 10, NSEL = 10, NUNR = 10;
+charlft[NLFT], sel[NSEL], unr[NUNR];
+
 attr_type   cattr;
 
 if (mi->mi_total == mi->mi_left)
@@ -293,12 +297,12 @@ closed_attr(register struct menu_info * mi, char *cbuf)
 
 lft[0] = sel[0] = unr[0] = NUL;
 if (mi->mi_left && mi->mi_left < mi->mi_unread)
-   sprintf(lft, "%d,", mi->mi_left);
+   snprintf(lft, NLFT, "%d,", mi->mi_left);
 if (mi->mi_selected && mi->mi_selected < mi->mi_unread)
-   sprintf(sel, "%d/", mi->mi_selected);
+   snprintf(sel, NSEL, "%d/", mi->mi_selected);
 if (mi->mi_unread && mi->mi_unread < mi->mi_total)
-   sprintf(unr, "%d:", mi->mi_unread);
-sprintf(cbuf, "%s%s%s%d", lft, sel, unr, mi->mi_total);
+   snprintf(unr, NUNR, "%d:", mi->mi_unread);
+snprintf(cbuf, ncbuf, "%s%s%s%d", lft, sel, unr, mi->mi_total);
 
 return cattr;
 }
@@ -312,7 +316,8 @@ mark(void)
 register struct menu_info *mi;
 int lno, lnum, lsubj, lname;
 int pad;
-charcbuf[80];
+#defineNCBUF  80
+charcbuf[NCBUF];
 attr_type   cattr = 0;
 
 ah = articles[firsta + cura];
@@ -325,7 +330,7 @@ mark(void)
lno = firstl + ah->menu_line;
gotoxy(0, lno);
tputc(ident[mi->mi_art_id]);
-   cattr = closed_attr(mi, cbuf);
+   cattr = closed_attr(mi, cbuf, NCBUF);
goto print_line;
 }
 if (cura < 0 || cura > numa)
@@ -335,7 +340,8 @@ mark(void)
 
 if (ah->flag & A_CLOSED) {
struct menu_info old;
-   charoldctr[80];
+#defineNOLDCTR  80
+   charoldctr[NOLDCTR];
 
mi = &menu_info[ah->menu_line];
old = *mi;
@@ -345,12 +351,11 @@ mark(void)
old.mi_left == mi->mi_left &&
old.mi_unread == mi->mi_unread)
return;
-
-   cattr = closed_attr(mi, cbuf);
+   cattr = closed_attr(mi, cbuf, NCBUF);
 
if (!slow_mode)
goto print_line;
-   closed_attr(&old, oldctr);
+   closed_attr(&old, oldctr, NOLDCTR);
if (strcmp(cbuf, oldctr))
goto print_line;
last_attr = cattr;
@@ -811,7 +816,7 @@ show_articles(void)
}
 
if (again > 1)
-   sprintf(delayed_msg, "Showing %ld articles again", again);
+   snprintf(delayed_msg, NDELAYED_MSG, "Showing %d articles again", 
again);
 } while (again);
 
 return MC_READGROUP;
@@ -868,6 +873,7 @@ loop:
cur_key = c;
map = key_map[c];
 }
+
 if (s_hangup)
map = K_QUIT;
 
@@ -915,7 +921,8 @@ char   *
 pct(long start, long end, long first, long last)
 {
 longn = end - start;
-static char buf[16];
+#defineNBUF  16
+static char buf[NBUF];
 char   *fmt;
 
 if (first <= start || n <= 0) {
@@ -929,7 +936,7 @@ pct(long start, long end, long first, long last)
fmt = "%d%%";

Bug#983648: kpatch-dkms: fails to build module for Linux 5.10: uses unknown struct stack_trace

[Andreas Beckmann]

Package: kpatch-dkms
Version: 0.6.0-0.2
Severity: serious
Tags: sid bullseye
User: debian...@lists.debian.org
Usertags: piuparts

Hi,

kpatch-dkms fails to build a module for the current kernel in sid:

DKMS make.log for kpatch-0.6.0 for kernel 5.10.0-3-amd64 (x86_64)
Sun Feb 28 01:36:52 CET 2021
make: Entering directory '/var/lib/dkms/kpatch/0.6.0/build/kmod'
make -C core clean
make[1]: Entering directory '/var/lib/dkms/kpatch/0.6.0/build/kmod/core'
rm -f -Rf .*.o.cmd .*.ko.cmd .tmp_versions *.o *.ko *.mod.c \
Module.symvers
make[1]: Leaving directory '/var/lib/dkms/kpatch/0.6.0/build/kmod/core'
make -C core
make[1]: Entering directory '/var/lib/dkms/kpatch/0.6.0/build/kmod/core'
make -C /lib/modules/5.10.0-3-amd64/build 
M=/var/lib/dkms/kpatch/0.6.0/build/kmod/core kpatch.ko
make[2]: Entering directory '/var/lib/dkms/kpatch/0.6.0/build/kmod/core'
make[2]: warning: jobserver unavailable: using -j1.  Add '+' to parent make 
rule.
  CC [M]  /var/lib/dkms/kpatch/0.6.0/build/kmod/core/core.o
/var/lib/dkms/kpatch/0.6.0/build/kmod/core/core.c:143:15: error: variable 
'trace' has initializer but incomplete type
  143 | static struct stack_trace trace = {
  |   ^~~
/var/lib/dkms/kpatch/0.6.0/build/kmod/core/core.c:144:3: error: 'struct 
stack_trace' has no member named 'max_entries'
  144 |  .max_entries = ARRAY_SIZE(stack_entries),
  |   ^~~
In file included from 
/usr/src/linux-headers-5.10.0-3-common/include/linux/list.h:9,
 from 
/usr/src/linux-headers-5.10.0-3-common/include/linux/module.h:12,
 from /var/lib/dkms/kpatch/0.6.0/build/kmod/core/core.c:37:
/usr/src/linux-headers-5.10.0-3-common/include/linux/kernel.h:48:25: warning: 
excess elements in struct initializer
   48 | #define ARRAY_SIZE(arr) (sizeof(arr) / sizeof((arr)[0]) + 
__must_be_array(arr))
  | ^
/var/lib/dkms/kpatch/0.6.0/build/kmod/core/core.c:144:17: note: in expansion of 
macro 'ARRAY_SIZE'
  144 |  .max_entries = ARRAY_SIZE(stack_entries),
  | ^~
/usr/src/linux-headers-5.10.0-3-common/include/linux/kernel.h:48:25: note: 
(near initialization for 'trace')
   48 | #define ARRAY_SIZE(arr) (sizeof(arr) / sizeof((arr)[0]) + 
__must_be_array(arr))
  | ^
/var/lib/dkms/kpatch/0.6.0/build/kmod/core/core.c:144:17: note: in expansion of 
macro 'ARRAY_SIZE'
  144 |  .max_entries = ARRAY_SIZE(stack_entries),
  | ^~
/var/lib/dkms/kpatch/0.6.0/build/kmod/core/core.c:145:3: error: 'struct 
stack_trace' has no member named 'entries'
  145 |  .entries = &stack_entries[0],
  |   ^~~
/var/lib/dkms/kpatch/0.6.0/build/kmod/core/core.c:145:13: warning: excess 
elements in struct initializer
  145 |  .entries = &stack_entries[0],
  | ^
/var/lib/dkms/kpatch/0.6.0/build/kmod/core/core.c:145:13: note: (near 
initialization for 'trace')
/var/lib/dkms/kpatch/0.6.0/build/kmod/core/core.c: In function 
'kpatch_verify_activeness_safety':
/var/lib/dkms/kpatch/0.6.0/build/kmod/core/core.c:274:8: error: invalid use of 
undefined type 'struct stack_trace'
  274 |   trace.nr_entries = 0;
  |^
/var/lib/dkms/kpatch/0.6.0/build/kmod/core/core.c:275:3: error: implicit 
declaration of function 'save_stack_trace_tsk' 
[-Werror=implicit-function-declaration]
  275 |   save_stack_trace_tsk(t, &trace);
  |   ^~~~
/var/lib/dkms/kpatch/0.6.0/build/kmod/core/core.c:276:12: error: invalid use of 
undefined type 'struct stack_trace'
  276 |   if (trace.nr_entries >= trace.max_entries) {
  |^
/var/lib/dkms/kpatch/0.6.0/build/kmod/core/core.c:276:32: error: invalid use of 
undefined type 'struct stack_trace'
  276 |   if (trace.nr_entries >= trace.max_entries) {
  |^
In file included from 
/usr/src/linux-headers-5.10.0-3-common/include/linux/kernel.h:16,
 from 
/usr/src/linux-headers-5.10.0-3-common/include/linux/list.h:9,
 from 
/usr/src/linux-headers-5.10.0-3-common/include/linux/module.h:12,
 from /var/lib/dkms/kpatch/0.6.0/build/kmod/core/core.c:37:
/var/lib/dkms/kpatch/0.6.0/build/kmod/core/core.c:279:16: error: invalid use of 
undefined type 'struct stack_trace'
  279 |   trace.max_entries);
  |^
/usr/src/linux-headers-5.10.0-3-common/include/linux/printk.h:343:33: note: in 
definition of macro 'pr_err'
  343 |  printk(KERN_ERR pr_fmt(fmt), ##__VA_ARGS__)
  | ^~~
/var/lib/dkms/kpatch/0.6.0/build/kmod/core/core.c:283:38: error: invalid use of 
undefined type 'struct stack_trace'
  283 | for (i = 0; i < trace.nr_entries; i++) {
  |  ^
/var/lib/dkms/kpatch/0.6.0/build/kmod/core/core.c:284:13: error: invalid use of 
undefined type 'struct stack_trace'
  284 |if (trace.entries[i] == ULONG_MAX)
  | ^
/var/lib/dkms/kp

Bug#983647: aux.c: fix the use of a named constant in the declaration of an array

[Bjarni Ingi Gislason]

Source: nn
Version: 6.7.3-14
Severity: normal
Tags: patch

Dear Maintainer,

>From 46885e769883a98efb191f94a2c80a3fa9c29fbe Mon Sep 17 00:00:00 2001
>From: Bjarni Ingi Gislason 
>Date: Sat, 27 Feb 2021 23:52:48 +
>Subject: [PATCH] aux.c: fix the use of a named constant in the declaration of
> an array

  A number must be used for the number of elements, otherwise an error:

menu.c:99:17: error: variably modified 'delayed_msg' at file scope
   99 | chardelayed_msg[NDELAYED_MSG]; /* give to msg() after 
redraw */
  | ^~~

Signed-off-by: Bjarni Ingi Gislason 
---
 aux.c | 8 +++-
 1 file changed, 7 insertions(+), 1 deletion(-)

diff --git a/aux.c b/aux.c
index 4dec5bf..d5e415b 100644
--- a/aux.c
+++ b/aux.c
@@ -26,7 +26,13 @@ extern char*temp_file;
 
 extern int  novice;
 const size_tNDELAYED_MSG = 100; /* size of array "delayed_msg[]" */
-chardelayed_msg[NDELAYED_MSG];
+/* A number must be used for the number of elements, otherwise an error:
+
+menu.c:99:17: error: variably modified 'delayed_msg' at file scope
+   99 | chardelayed_msg[NDELAYED_MSG]; *//* give to msg() after 
redraw */
+/*  | ^~~
+*/
+chardelayed_msg[100];  /* give to msg() after redraw */
 extern char*pager;
 extern char*inews_program;
 extern int  inews_pipe_input;
-- 
2.30.1



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

Kernel: Linux 5.10.9-1 (SMP w/2 CPU threads)
Locale: LANG=is_IS.iso88591, LC_CTYPE=is_IS.iso88591 (charmap=ISO-8859-1), 
LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)

-- debconf information excluded

-- 
Bjarni I. Gislason

Bug#800983: Reopen bug 800983 and 982001

[Markus Koschany]

Control: tags 800983 pending 
Control: tags 982001 pending

On second thought, let's fix this now.


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

Bug#983646: thunar corrupt debian 9 file system from debian 10

[Luis Duarte]

Package: thunar
Version: 1.8.4-1
Severity: important

Dear Maintainer,
I have Debian 9 where I do some software development of software in Rust
language. I have Debian 10 where I do some other things.
I change and compiled a Rust program from Debian 10 into Debian 9, using a
terminal as super user. It was a disaster when I entered in debian 10. The file
system became unstable. I restarted the Debian 9, and it didn't restart. I
needed to enter in rescue mode to check and to recover the file system.
I typed "command fsck /dev/sda5" in an minimal OS. The file system was
recovered successfully.



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

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

Versions of packages thunar depends on:
ii  desktop-file-utils  0.23-4
ii  exo-utils   0.12.4-1
ii  libatk1.0-0 2.30.0-2
ii  libc6   2.28-10
ii  libcairo2   1.16.0-4
ii  libexo-2-0  0.12.4-1
ii  libgdk-pixbuf2.0-0  2.38.1+dfsg-1
ii  libglib2.0-02.58.3-2+deb10u2
ii  libgtk-3-0  3.24.5-1
ii  libgudev-1.0-0  232-2
ii  libice6 2:1.0.9-2
ii  libnotify4  0.7.7-4
ii  libpango-1.0-0  1.42.4-8~deb10u1
ii  libsm6  2:1.2.3-1
ii  libthunarx-3-0  1.8.4-1
ii  libxfce4ui-2-0  4.12.1-3
ii  libxfce4util7   4.12.1-3
ii  libxfconf-0-2   4.12.1-1
ii  shared-mime-info1.10-1
ii  thunar-data 1.8.4-1

Versions of packages thunar recommends:
ii  dbus-user-session [default-dbus-session-bus]  1.12.20-0+deb10u1
ii  dbus-x11 [dbus-session-bus]   1.12.20-0+deb10u1
ii  gvfs  1.38.1-5
ii  libcairo-gobject2 1.16.0-4
ii  libpangocairo-1.0-0   1.42.4-8~deb10u1
ii  libxfce4panel-2.0-4   4.12.2-1
ii  policykit-1-gnome [polkit-1-auth-agent]   0.105-7
ii  thunar-volman 0.9.1-1
ii  tumbler   0.2.3-1
ii  udisks2   2.8.1-4
ii  xdg-user-dirs 0.17-2

Versions of packages thunar suggests:
ii  thunar-archive-plugin 0.4.0-2
ii  thunar-media-tags-plugin  0.3.0-2

-- no debconf information

Bug#983645: laminard: SIGPIPE kills it

[Jan-Benedict Glaw]

Package: laminard
Version:

Hi!

I gave laminar a try, but laminard dies on SIGPIPE:

(gdb) bt
#0  0x7f7f95d53da3 in __GI___writev (fd=16, iov=0x7ffdebf13860, iovcnt=3) 
at ../sysdeps/unix/sysv/linux/writev.c:26
#1  0x7f7f963d8269 in non-virtual thunk to kj::(anonymous 
namespace)::AsyncStreamFd::write(kj::ArrayPtr 
const>) () at src/kj/async-inl.h:403
#2  0x7f7f96487dc6 in kj::(anonymous 
namespace)::HttpOutputStreamoperator() (__closure=0x56237a1a5410) 
at src/kj/compat/http.c++:1661
#3  kj::_::MaybeVoidCaller 
>::apply >):: > (func=..., func=..., in=...) 
at ./src/kj/async-prelude.h:148
#4  kj::_::TransformPromiseNode, kj::_::Void, kj::(anonymous 
namespace)::HttpOutputStream::writeBodyData(kj::ArrayPtr >)::, 
kj::_::PropagateException>::getImpl(kj::_::ExceptionOrValue &) 
(this=0x56237a1a53f0, output=...) at ./src/kj/async-inl.h:401
#5  0x7f7f9638c502 in 
kj::_::TransformPromiseNodeBaseoperator() 
(__closure=0x7ffdebf14188, __closure=0x7ffdebf14188) at src/kj/async.c++:703
#6  
kj::_::RunnableImpl
 >::run(void) (this=0x7ffdebf14180) at src/kj/exception.h:302
#7  0x7f7f96305f9b in kj::_::runCatchingExceptions (runnable=warning: RTTI 
symbol not found for class 
'kj::_::RunnableImpl'
...) at src/kj/exception.c++:1023
#8  0x7f7f9638b6fa in 
kj::runCatchingExceptions
 > (func=...) at src/kj/common.h:514
#9  kj::_::TransformPromiseNodeBase::get (this=, output=...) at 
src/kj/async.c++:703
#10 0x7f7f963901e9 in kj::_::ChainPromiseNode::fire (this=0x56237a1b2cd0) 
at src/kj/async.c++:855
#11 0x7f7f9638be3c in kj::EventLoop::turn (this=0x56237a17df98) at 
src/kj/async.c++:373
#12 0x7f7f963910c5 in kj::_::waitImpl (node=..., result=..., waitScope=...) 
at src/kj/async.c++:440
#13 0x562378dde1cc in kj::Promise::wait (waitScope=..., 
this=0x7ffdebf14cf0) at /usr/include/kj/async-inl.h:902
#14 Server::start (this=0x56237a17e1e0) at ./src/server.cpp:56
#15 0x562378d9eeba in main (argc=, argv=) at 
./src/main.cpp:98


This is while one job is running and I'm following it's build log on
the /jobs/xxx/nn page. Quite easy to reproduce.

(Another small issue: /var/log/laminar.log isn't pre-created and
daemon drops permissions before creating the file, so it fails
creating it altogether.)

Thanks,
  Jan-Benedict

-- 


signature.asc
Description: PGP signature

Bug#841666: release-notes: recommend installing usrmerge on upgrade to stretch

[Marco d'Itri]

On Feb 27, Paul Gevers  wrote:

> > Due to systemd changes, currently usrmerge requires a reboot to complete.
> > To lower support load on the community, as the usrmerge author I suggest 
> > that we wait to explicitly recommend users to install it until we will 
> > have implemented running it from the initramfs or some other workaround.
> > Hence, for buster +1.
> What's the current status on this? Should we recommend anything of this
> kind already in the bullseye release notes? If so, can either of you
> maybe propose some text?
Actually this is not clear: me and other people attempted some more 
conversions and we have not been able to reproduce this anymore: the 
conversion just works as expected with no mid-conversion reboot needed.
So we assumed that whatever the problem was with the systemd bind mounts 
it was "fixed" at some point.

Cc'ing Dimitri John who did some related work on the Ubuntu side and 
maybe has more data.

-- 
ciao,
Marco


signature.asc
Description: PGP signature

Bug#983644: put-dns: [INTL:pt_BR] Brazilian Portuguese debconf templates translation

[Adriano Rafael Gomes]

Package: put-dns
Tags: l10n patch
Severity: wishlist

Hello,

Please, Could you update the Brazilian Portuguese Translation?

Attached you will find the file pt_BR.po. It is UTF-8 encoded and it is
tested with msgfmt and podebconf-display-po.

Kind regards.


pt_BR.po.gz
Description: application/gzip


signature.asc
Description: PGP signature

Bug#972339: armhf: hpcups crashes with free() invalid pointer for some printers

[Bernhard Übelacker]

Hello Didier,
I have retried with the patch in #974828, but it still
crashed with the test files from this bug, therefore
I guess #974828 is similar but unrelated.


Then I took another look at the valgrind runs and found
that these invalid reads and writes also appear at amd64.

After some digging I gave up to understand the pointer
calculations and such and tried to just increase the
allocations and came up with the attached three patches.

(While working at #974828 I found one such "+ 32" in
HPCupsFilter.cpp which might be already a workaround by upstream?)


With these three applied a valgrind run shows no more errors
with amd64 or armhf, and also does not abort at armhf.

As this just allocates a few extra bytes I assume that the
print result should not be different by these patches.
And I hope that memset'ing these buffers has no security
related effects.

For the crash is just the Halftoner patch important.
The other two are currently just for valgrind, but that
might change in future with compiler changes or similar.

What do you think?

Kind regards,
Bernhard

Description: Workaround: Add 32 bytes to allocation ColorMatcher

Bug-Debian: https://bugs.debian.org/972339
Bug-Ubuntu: https://launchpad.net/bugs/1901209
Last-Update: 2021-02-27

==12899== Invalid read of size 1
==12899==at 0x1174D6: Backward16PixelsNonWhite (Halftoner.h:106)
==12899==by 0x1174D6: Halftoner::HTEDiffOpen(Halftoner::THTDitherParms*, unsigned short) (Halftoner.cpp:734)
==12899==by 0x117C67: Halftoner::Process(RASTERDATA*) (Halftoner.cpp:548)
==12899==by 0x115D5F: Process (Pipeline.cpp:72)
==12899==by 0x115D5F: Pipeline::Execute(RASTERDATA*) (Pipeline.cpp:79)
==12899==by 0x115D81: Pipeline::Execute(RASTERDATA*) (Pipeline.cpp:83)
==12899==by 0x10D151: HPCupsFilter::processRasterData(_cups_raster_s*) (HPCupsFilter.cpp:779)
==12899==by 0x10D651: HPCupsFilter::StartPrintJob(int, char**) (HPCupsFilter.cpp:597)
==12899==by 0x4B9BA1F: (below main) (libc-start.c:308)
==12899==  Address 0x55f8ed2 is 6 bytes after a block of size 12,100 alloc'd
==12899==at 0x48416F4: operator new[](unsigned int) (vg_replace_malloc.c:425)
==12899==by 0x116011: ColorMatcher::ColorMatcher(ColorMap_s, unsigned int, unsigned int) (ColorMatcher.cpp:63)
==12899==by 0x11101B: Pcl3::Configure(Pipeline**) (Pcl3.cpp:90)
==12899==by 0x115B71: Job::Configure() (Job.cpp:248)
==12899==by 0x115C07: Job::Init(SystemServices*, JobAttributes_s*, Encapsulator*) (Job.cpp:63)
==12899==by 0x10C9C1: HPCupsFilter::startPage(cups_page_header2_s*) (HPCupsFilter.cpp:481)
==12899==by 0x10D273: HPCupsFilter::processRasterData(_cups_raster_s*) (HPCupsFilter.cpp:668)
==12899==by 0x10D651: HPCupsFilter::StartPrintJob(int, char**) (HPCupsFilter.cpp:597)
==12899==by 0x4B9BA1F: (below main) (libc-start.c:308)

--- hplip-3.20.11+dfsg0.orig/prnt/hpcups/ColorMatcher.cpp
+++ hplip-3.20.11+dfsg0/prnt/hpcups/ColorMatcher.cpp
@@ -60,7 +60,8 @@ ColorMatcher::ColorMatcher
 EndPlane = K;
 }
 
-Contone = (BYTE *) new BYTE[InputWidth * ColorPlaneCount];
+Contone = (BYTE *) new BYTE[InputWidth * ColorPlaneCount + 32];
+memset(Contone, 0, InputWidth * ColorPlaneCount + 32);
 if (Contone == NULL)
 {
 goto MemoryError;
Description: Workaround: Add 32 bytes to allocation Halftoner

Bug-Debian: https://bugs.debian.org/972339
Bug-Ubuntu: https://launchpad.net/bugs/1901209
Last-Update: 2021-02-27

==144269== Invalid read of size 1
==144269==at 0x114577: Mode9::Process(RASTERDATA*) (Mode9.cpp:332)
==144269==by 0x11EDA4: Process (Pipeline.cpp:72)
==144269==by 0x11EDA4: Pipeline::Execute(RASTERDATA*) (Pipeline.cpp:79)
==144269==by 0x11EDDF: Pipeline::Execute(RASTERDATA*) (Pipeline.cpp:83)
==144269==by 0x11EDDF: Pipeline::Execute(RASTERDATA*) (Pipeline.cpp:83)
==144269==by 0x112677: HPCupsFilter::processRasterData(_cups_raster_s*) (HPCupsFilter.cpp:779)
==144269==by 0x112DE8: HPCupsFilter::StartPrintJob(int, char**) (HPCupsFilter.cpp:597)
==144269==by 0x4C17D09: (below main) (libc-start.c:308)
==144269==  Address 0x5a8cc0b is 0 bytes after a block of size 379 alloc'd
==144269==at 0x483950F: operator new[](unsigned long) (vg_replace_malloc.c:431)
==144269==by 0x12047B: Halftoner::Halftoner(PrintMode_s*, unsigned int, int*, int, bool) (Halftoner.cpp:184)
==144269==by 0x11817B: Pcl3::Configure(Pipeline**) (Pcl3.cpp:92)
==144269==by 0x11EA30: Job::Configure() (Job.cpp:248)
==144269==by 0x11EB67: Job::Init(SystemServices*, JobAttributes_s*, Encapsulator*) (Job.cpp:63)
==144269==by 0x111A35: HPCupsFilter::startPage(cups_page_header2_s*) (HPCupsFilter.cpp:481)
==144269==by 0x112792: HPCupsFilter::processRasterData(_cups_raster_s*) (HPCupsFilter.cpp:668)
==144269==by 0x112DE8: HPCupsFilter::StartPrintJob(int, char**) (HPCupsFilter.cpp:597)
==144269==by 0x4C17D09: (below main) (libc-start.c:308)

--- hplip-3.20.11+dfsg0.orig/prnt/hpcups/Halfto

Bug#982591: grub-pc can't be updated non-interactively on debian/buster64

[Evgeni Golov]

On February 27, 2021 8:44:44 PM UTC, Lucas Nussbaum  wrote:
>On 27/02/21 at 15:16 +0100, Evgeni Golov wrote:
>> On Fri, Feb 26, 2021 at 10:54:32PM +0100, Lucas Nussbaum wrote:
>> > Tentative patch:
>> > https://salsa.debian.org/cloud-team/debian-vagrant-images/-/commit/b82d522f65b507767f909b2b9471c5a9ade75e05
>> 
>> Thanks Lucas! That looks quite like the "first-boot script" I mentioned
>> in the original report.
>> 
>> One q tho: isn't `findmnt --noheadings --output SOURCE /` easier to read
>> than running awk on /proc/mounts? It's in util-linux and that's
>> essential anyways :)
>
>Ah, thanks, I did not know about findmnt. Yes, that would be better.
>
>(We would still need to get the disk, not the partition)

lsblk --output PKNAME /dev/sda1 will give you sda :)
Also from util-linux.
Might not work reliably when there is lvm/devicemapper in-between, but that 
shouldn't be a problem in this particular case.

Enjoy!

Bug#973474: gnome: Unable to log back in in after screen lock

[Simon McVittie]

On Sat, 27 Feb 2021 at 19:21:46 +0100, Marcin Owsiany wrote:
> Regarding the messages I see in syslog, see the screenshot I had attached to 
> my
> previous message.

On a freshly-installed, up to date test VM, you should find that the gdm
login screen has a grey background, but the gnome-shell lock screen has a
dark blue background (it's a blurred version of your desktop background,
for which the default in Debian 11 is going to be dark blue). It would
be useful if you could describe the steps you use to reproduce this bug,
and at each step that involves a login screen, say whether the background
is grey or blue.

Here is a sequence of screenshots illustrating my
attempt to reproduce this, together with my system log:
 (and then after pressing Enter
for my test user's password, I'm back to my unlocked session, equivalent
to ). At what point does
what you see diverge from that?

I'm surprised you see messages from Xorg: those should only appear when
you start a completely new session, not when you just lock and unlock
the screen. This suggests that maybe the session is crashing, and instead
of the gnome-shell lock screen on tty7, you are going back to the gdm
login screen on tty1.

Given that you see messages from Xorg, I would also expect to see more
messages than just those. Before locking the screen, please run

logger "before locking"

to leave a marker in the system log; and then please look back through
the system log at least as far as that marker.

If you look at the systemd journal (as root) instead of syslog, you'll
also see "auth" messages, which could be relevant: for instance, when
you enter a wrong password, that should be logged as an "auth" message
from PAM.

Please describe the steps you took to install your test VM, including
any non-default settings used? For example, I wonder whether this is
locale-sensitive - I'm using en_GB.UTF-8 but you seem to be using a
non-English locale.

If your test VM does not contain any personal or confidential data,
and you can can transfer files off it with ssh, a shared filesystem or
paste.debian.net, it would be useful to see the entire systemd journal
(starting from boot) for this procedure:

- boot the VM
- log in as a user
- lock the screen
- unlock with a correct password

and compare it with
.

Or if your test VM contains personal/confidential things, please could
you try to set up a similar VM without those and reproduce the bug there?

> Is there perhaps some setting I could tweak to convince gnome-shell to produce
> some debug output when I attempt unlocking?

Try these:

systemctl --user edit gnome-shell@x11.service
systemctl --user edit gnome-shell@wayland.service
sudo systemctl edit gdm.service

and in each case, add this:

[Service]
Environment=G_MESSAGES_DEBUG=all

Thanks,
smcv

Bug#800983: Reopen bug 800983 and 982001

[Markus Koschany]

Control: reopen 800983 982001


I'm reopening bug 800983 and 982001 because they were not properly fixed. I let
the current version in unstable migrate to testing and then I fix those
remaining issues.

Markus


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

Bug#983635: base-passwd: uid/gid reservation for Gnocchi users/groups

[Colin Watson]

Control: tag -1 pending

On Sat, Feb 27, 2021 at 08:56:55AM -0700, Billy Olsen wrote:
> The Gnocchi metrics as a service package allows for storing time series 
> database
> information in a file system, which may be a shared file system. As a result,
> inconsistencies between deployed machines in the uid/gid allocation for 
> gnocchi
> user and group results in situations which requires using overly broad 
> permissions
> on the shared file system being used (i.e. 777).
> 
> Please can a uid/gid reservation be allocated for gnocchi?

I have made the following uid/gid allocations:

64065 | gnocchi   | Gnocchi - Metric as a Service

You can start using these immediately, without waiting for a base-passwd
upload.

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

Bug#982591: grub-pc can't be updated non-interactively on debian/buster64

[Lucas Nussbaum]

On 27/02/21 at 20:01 +0100, Emmanuel Kasper wrote:
> Le 26/02/2021 à 22:54, Lucas Nussbaum a écrit :
> > Tentative patch:
> > https://salsa.debian.org/cloud-team/debian-vagrant-images/-/commit/b82d522f65b507767f909b2b9471c5a9ade75e05
> 
> This approach is IMHO the easier way forward.
> 
> However I think the recommended approach of grub installation is to put
> the core.img on the disk between the partition table and the first
> partition, see
> https://www.gnu.org/software/grub/manual/grub/html_node/BIOS-installation.html#BIOS-installation
> 
> and for this we should feed debconf with the disk device (/dev/vda or
> /dev/sda) instead of a partition.
> This is what the debian-installer and FAI do.
> 
> https://salsa.debian.org/cloud-team/debian-vagrant-images/-/blob/master/config_space/scripts/GRUB_PC/10-setup#L9

I fully agree, but I think that's what my code does (sub(/1$/, "", $1))
:)

Lucas

Bug#982591: grub-pc can't be updated non-interactively on debian/buster64

[Lucas Nussbaum]

On 27/02/21 at 15:16 +0100, Evgeni Golov wrote:
> On Fri, Feb 26, 2021 at 10:54:32PM +0100, Lucas Nussbaum wrote:
> > Tentative patch:
> > https://salsa.debian.org/cloud-team/debian-vagrant-images/-/commit/b82d522f65b507767f909b2b9471c5a9ade75e05
> 
> Thanks Lucas! That looks quite like the "first-boot script" I mentioned
> in the original report.
> 
> One q tho: isn't `findmnt --noheadings --output SOURCE /` easier to read
> than running awk on /proc/mounts? It's in util-linux and that's
> essential anyways :)

Ah, thanks, I did not know about findmnt. Yes, that would be better.

(We would still need to get the disk, not the partition)

Lucas

Bug#841666: release-notes: recommend installing usrmerge on upgrade to stretch

[Paul Gevers]

Hi Marco, Ansgar,

On Mon, 4 Mar 2019 14:25:18 +0100 Marco d'Itri  wrote:
> On Mar 04, Paul Gevers  wrote:
> 
> > Could you please propose a paragraph to add to the release-notes for
> > this? You can add it as a patch here, literal text, or (easiest) as a MR
> > against the salsa archive:
> > https://salsa.debian.org/ddp-team/release-notes
>
> Due to systemd changes, currently usrmerge requires a reboot to complete.
> To lower support load on the community, as the usrmerge author I suggest 
> that we wait to explicitly recommend users to install it until we will 
> have implemented running it from the initramfs or some other workaround.
> Hence, for buster +1.

What's the current status on this? Should we recommend anything of this
kind already in the bullseye release notes? If so, can either of you
maybe propose some text?

Note: I already added something about bookworm only supporting merged-usr.

Paul



OpenPGP_signature
Description: OpenPGP digital signature

Bug#983634: [request-tracker-maintainers] Bug#983634: rt-extension-repeatticket: not compatible with RT5

[Joost van Baal-Ilić]

Hi!

On Sat, Feb 27, 2021 at 03:33:57PM +, Dominic Hargreaves wrote:
> Source: rt-extension-repeatticket
> Version: 1.11-1
> Severity: important
> Tags: sid
> Forwarded: https://rt.cpan.org/Public/Bug/Display.html?id=133122
> 
> As mentioned in the upstream report, the styling is broken in RT5.
> There is an rt5 branch from upstream, so in the worst case, it may be
> possible to apply those changes if there's no upstream release by the time
> we want to upload RT5 to unstable (and drop RT4).


Dominic: thanks for reporting this!

Maarten: are you still interested in rt-extension-repeatticket, especially on
Debian 12 bookworm?  Debian 12, to be released in 2022 or 2023, will likely
ship request-tracker5, and might not ship RT4.  (Debian 11 Bullseys, to be
released within some months, will very likely ship with RT 4.4.4 and
rt4-extension-repeatticket 1.11.)

Bye,

Joost

Bug#972339: armhf: hpcups crashes with free() invalid pointer for some printers

[Jeffrey Walton]

On Sat, Feb 27, 2021 at 1:21 PM Bernhard Übelacker
 wrote:
>
> I have retried with the patch in #974828, but it still
> crashed with the test files from this bug, therefore
> I guess #974828 is similar but unrelated.
>
> Then I took another look at the valgrind runs and found
> that these invalid reads and writes also appear at amd64.
>
> After some digging I gave up to understand the pointer
> calculations and such and tried to just increase the
> allocations and came up with the attached three patches.
>
> (While working at #974828 I found one such "+ 32" in
> HPCupsFilter.cpp which might be already a workaround by upstream?)
>
> With these three applied a valgrind run shows no more errors
> with amd64 or armhf, and also does not abort at armhf.
>
> As this just allocates a few extra bytes I assume that the
> print result should not be different by these patches.
> And I hope that memset'ing these buffers has no security
> related effects.
>
> For the crash is just the Halftoner patch important.
> The other two are currently just for valgrind, but that
> might change in future with compiler changes or similar.
>
> What do you think?

For the 0079 patch, this is probably a little more efficient since it
avoids a mod which may be implemented as a division:

PlaneSize= (OutputWidth[i]+7)/8; // doublecheck ... should already
be divisible by 8

The thing that is not clear to me... What is the datatype of
OutputWidth[i]? If it is a 16-bit type (or larger), then you may want:

const size_t width = sizeof(OutputWidth[0])*CHAR_BITS;
PlaneSize= (OutputWidth[i]+width-1)/8;

Jeff

Bug#820233: xserver-xorg-video-r128: X doesn't start with r128 driver (ATI RAGE) [powerpc]

[Mark Grieveson]

Package: xserver-xorg-video-r128
Version: 6.12.0-2
Followup-For: Bug #820233

Dear Maintainer,

*** Reporter, please consider answering these questions, where
appropriate ***

   * What led up to the situation?

I installed xserver-xorg-video-r128 on my Power Mac G4.  X will not
start.

   * What exactly did you do (or not do) that was effective (or
 ineffective)?

I have IceWM installed on my machine, so I rely on "startx" rather than
a desktop manager such as gdm.  I entered the command "startx", but it
did not work.  When I simply rely on xserver-xorg-video-ati, I am able
to "startx", but the r128 module is not loaded.  I have an ATI Rage 128
card.

   * What was the outcome of this action?

I received the following feedback:

mark@debian:~$ startx

X.Org X Server 1.20.10
X Protocol Version 11, Revision 0
Build Operating System: linux Debian
Current Operating System: Linux debian 5.10.0-3-powerpc #1 Debian
5.10.13-1 (2021-02-06) ppc Kernel command line:
root=UUID-4626b1bb-f721-4694-83fe-f49cc32cc322288365 ro Build Date: 17
February 2021 09:17:43AM xorg-server 2:1.20.10-3
(https://www.debian.org/support) Current version of pixman: 0.40.0
Before reporting problems, check http://wiki.x.org
to make sure that you have the latest version
Markers: (--) probed, (**) from config file, (==) default setting,
(++) from command link, (!!) notice, (II) informational,
(WW) warning, (EE) error, (NI) not implemented, (??) unknown.
(==) Log file: '/var/log/Xorg.0.log", Time: Sat Feb 27 10:23:18 2021
(==) Using system config directory '/usr/share/X11/xorg.conf.d"
(EE)
(EE) Backtrace:
(EE) 0: /usr/lib/xorg/Xorg (0sLookupColor+0x230)
[0xbf1b90] (EE) 1: linux-vdso32.so.1 (?+0x0) [0x100430]
(EE)
unw_get_proc_name failed: no unwind infor found [-10]
(EE) 2.:
/usr/lib/xorg/modules/drivers/r128_drv.so (?+0x0) [0xb6ce0ca8]
/var/log/Xorg.0.log" for additional information.(EE) (EE) Server
terminated with error (1). Closing log file.k the log file at " xinit:
giving up xinit: unable to connect to Xserver: Connection refused
xinit: server error


   * What outcome did you expect instead?

I expected that X would start.

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


-- Package-specific info:
/etc/X11/X does not exist.
/etc/X11/X is not a symlink.
/etc/X11/X is not executable.

VGA-compatible devices on PCI bus:
--
:00:10.0 VGA compatible controller [0300]: Advanced Micro Devices,
Inc. [AMD/ATI] Rage 4 [Rage 128 PRO AGP 4X] [1002:5046]

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

Contents of /etc/X11/xorg.conf.d:
-
total 0

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

Kernel version (/proc/version):
---
Linux version 5.10.0-3-powerpc (debian-ker...@lists.debian.org) (gcc-10
(Debian 10.2.1-6) 10.2.1 20210110, GNU ld (GNU Binutils for Debian)
2.35.1) #1 Debian 5.10.13-1 (2021-02-06)

Xorg X server log files on system:
--
-rw-r--r-- 1 root root 23434 Jan  7 17:43 /var/log/Xorg.1.log
-rw-r--r-- 1 root root 10322 Feb 27 11:04 /var/log/Xorg.0.log

Contents of most recent Xorg X server log file (/var/log/Xorg.0.log):
-
[  2527.177]
X.Org X Server 1.20.10
X Protocol Version 11, Revision 0
[  2527.180] Build Operating System: linux Debian
[  2527.182] Current Operating System: Linux debian 5.10.0-3-powerpc #1
Debian 5.10.13-1 (2021-02-06) ppc [  2527.182] Kernel command line:
root=UUID=4626b1bb-f721-4694-83fe-f49cc3288365 ro [  2527.186] Build
Date: 17 February 2021  09:17:43AM [  2527.189] xorg-server 2:1.20.10-3
(https://www.debian.org/support) [  2527.191] Current version of
pixman: 0.40.0 [  2527.196] Before reporting problems, check
http://wiki.x.org to make sure that you have the latest version.
[  2527.196] Markers: (--) probed, (**) from config file, (==) default
setting, (++) from command line, (!!) notice, (II) informational,
(WW) warning, (EE) error, (NI) not implemented, (??) unknown.
[  2527.209] (==) Log file: "/var/log/Xorg.0.log", Time: Sat Feb 27
11:04:08 2021 [  2527.214] (==) Using system config directory
"/usr/share/X11/xorg.conf.d" [  2527.216] (==) No Layout section.
Using the first Screen section. [  2527.216] (==) No screen section
available. Using defaults. [  2527.216] (**) |-->Screen "Default Screen
Section" (0) [  2527.216] (**) |   |-->Monitor ""
[  2527.219] (==) No monitor specified for screen "Default Screen
Section". Using a default monitor configuration.
[  2527.219] (==) Automatically adding devices
[  2527.219] (==) Automatically enabling devices
[  2527.220] (==) Automatically adding GPU devices
[  2527.220] (==) Max clients allowed: 256, resource mask: 0x1f
[  2527.220] (WW) The directory "/usr/share/fonts/X11/cyrillic" does
not ex

Bug#982591: grub-pc can't be updated non-interactively on debian/buster64

[Emmanuel Kasper]

Le 26/02/2021 à 22:54, Lucas Nussbaum a écrit :
> On 26/02/21 at 20:07 +0100, Lucas Nussbaum wrote:
>> On 14/02/21 at 08:48 +0100, Evgeni Golov wrote:
>>> On Sat, Feb 13, 2021 at 11:57:52PM +0100, Thomas Lange wrote:
 IMO we cannot know which device name is used  by the users virtualisation 
 environment.
 So, what is the be setting without knowing the device name?

 Or is /dev/sda used in most enviroments?
>>>
>>> For VirtualBox sda is a pretty safe bet, for libvirt it'd be either sda
>>> or vda (and I think we could set both in debconf, as that's a
>>> multiselect). AWS has another one, vxda I think? But this explicit bug
>>> is about vagrant (so virtualbox and libvirt) only anyways.
>>>
>>> The only thing to consider with this approach: it should only be done
>>> when preparing images, not installing "real" systems. So in the
>>> cloud.d.o context that's safe, but probably not as a generic default in
>>> FAI and other tools.
>>
>> Maybe a better approach (but still hackish) would be to set it at first
>> boot, in a way similar to
>> https://salsa.debian.org/cloud-team/debian-vagrant-images/-/blob/master/config_space/files/etc/systemd/system/generate-sshd-host-keys.service/VAGRANT
>>
>> Running Something like:
>> echo grub-pc grub-pc/install_devices multiselect $(awk '{ if ($2 == "/") { 
>> sub(/1$/, "", $1) ; print $1 } }' /proc/mounts) | debconf-set-selections
> 
> Tentative patch:
> https://salsa.debian.org/cloud-team/debian-vagrant-images/-/commit/b82d522f65b507767f909b2b9471c5a9ade75e05

This approach is IMHO the easier way forward.

However I think the recommended approach of grub installation is to put
the core.img on the disk between the partition table and the first
partition, see
https://www.gnu.org/software/grub/manual/grub/html_node/BIOS-installation.html#BIOS-installation

and for this we should feed debconf with the disk device (/dev/vda or
/dev/sda) instead of a partition.
This is what the debian-installer and FAI do.

https://salsa.debian.org/cloud-team/debian-vagrant-images/-/blob/master/config_space/scripts/GRUB_PC/10-setup#L9

Bug#983209: lynx: differences in documentation when built in parallel

[Andreas Metzler]

On 2021-02-21 Vagrant Cascadian  wrote:
[...]
> The lynx documentation has many differences between two builds:

>   
> https://tests.reproducible-builds.org/debian/rb-pkg/bullseye/amd64/diffoscope-results/lynx.html

>   /usr/share/doc/lynx-common/lynx_help/body.html.gz

> In one of the builds, there has several occurrences of:

>   Support·for·this·setting·was·disabled·at·compile-time.   


> All of the documentation differences disappeared for me when disabling
> parallelism in the build (and fixing the usrmerge issue reported in
> another bug). The attached patch passes --no-parallel to dh in
> debian/rules to accomplish this.

> I do not know weather this is actually a more serious issue where
> various features are actually disabled between the two builds or only a
> documentation difference.
[...]

Hello,

afaict it is just a doc-generation issue, the arch-any package does not
differ.

This part of the toplevel makefile seems to be the problem:

CFG2HTML = alphatoc.html body.html cattoc.html
[...]
$(CFG2HTML) :
@echo 'Making htmlized lynx.cfg'
cd $(SRC_DIR) && $(MAKE_RECUR) LYReadCFG.i
@-rm -f $(CFG2HTML)
sed -n -e '/Config_Type  *Config_Table/,/{0, *0, *0}/ p' 
$(SRC_DIR)/LYReadCFG.i | \
sed  -e 's/ *{ *"\([^"]*\)".*/\1/' | \
perl $(scripts_dir)/cfg2html.pl -ams $(srcdir)/lynx.cfg
-rm -f $(SRC_DIR)/LYReadCFG.i

With -j > 1 the same rule runs multiple times in parallel and job1,
generating alphatoc.html will remove $(SRC_DIR)/LYReadCFG.i before job2
can read it.

This patch (use a "Grouped Target") fixes the issue for me:
---
--- lynx-2.9.0dev.6.orig/makefile.in
+++ lynx-2.9.0dev.6/makefile.in
@@ -338,7 +338,7 @@ LYNX_URL='@HOMEPAGE_URL@release/breakout
 LYNXDOCS_URL='$(LYNX_URL)/docs/'
 LYNXHELP_URL='$(LYNX_URL)/lynx_help/'

-@LYNXCFG_MAKE@$(CFG2HTML) :
+@LYNXCFG_MAKE@$(CFG2HTML) &:
 @LYNXCFG_MAKE@ @echo 'Making htmlized lynx.cfg'
 @LYNXCFG_MAKE@ cd $(SRC_DIR) && $(MAKE_RECUR) LYReadCFG.i
 @LYNXCFG_MAKE@ @-rm -f $(CFG2HTML)
---

Not sure whether it is upstreamable, since &: is a probably a
GNU-make-ism.

cu Andreas

Bug#983642: aux.c: remove leftover '+' in column 1; add block delimiters

[Bjarni Ingi Gislason]

Source: nn
Version: 6.7.3-14
Severity: normal
Tags: patch

Dear Maintainer,

>From 9148e0fdf7fde8c18e79cd8b4a6268d5c2e05027 Mon Sep 17 00:00:00 2001
>From: Bjarni Ingi Gislason 
>Date: Sat, 27 Feb 2021 18:32:15 +
>Subject: [PATCH] aux.c: remove leftover '+' in column 1; add block delimiters
> around an if-block

  aux.c: remove leftover '+' in column 1; add block delimiters

Signed-off-by: Bjarni Ingi Gislason 
---
 aux.c | 9 +
 1 file changed, 5 insertions(+), 4 deletions(-)

diff --git a/aux.c b/aux.c
index 5ce9271..2aa9402 100644
--- a/aux.c
+++ b/aux.c
@@ -467,16 +467,17 @@ aux_sh(article_header * ah, char *script, char *prog, 
char *action, char *record
unlink(copy);
return (22);
}
-   if (empty_answer_check)
+   if (empty_answer_check) {
if (cmp_file(temp_file, copy) != 1) {
snprintf(delayed_msg, ndelayed_msg, sent_fmt, " not");
unlink(temp_file);
unlink(copy);
return (22);
}
-+/*
-+ aux.c:...: warning: the address of 'lookfor' will always evaluate as 'true'
-+*/
+   }
+/*
+ aux.c:...: warning: the address of 'lookfor' will always evaluate as 'true'
+*/
 /* if (lookfor); *//* grep for lookfor */
 
break;
-- 
2.30.1



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

Kernel: Linux 5.10.9-1 (SMP w/2 CPU threads)
Locale: LANG=is_IS.iso88591, LC_CTYPE=is_IS.iso88591 (charmap=ISO-8859-1), 
LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)

-- debconf information excluded

-- 
Bjarni I. Gislason

Bug#983641: network-manager-gnome: Wireguard connections cannot be enabled or disabled

[Baptiste Jonglez]

Package: network-manager-gnome
Version: 1.20.0-2
Severity: important
Tags: patch

Dear Maintainer(s),

The network-manager-applet version in Debian bullseye has support to edit
Wireguard connections, which is a good thing (it was introduced upstream
in version 1.18.0).

However, it is not possible to enable or disable a Wireguard connection in
the applet.  This is currently only possible through nmcli (a command-line
tool), which defeats the purpose of using a graphical tool like nm-applet.

This has been fixed upstream but didn't make it in time for the recent
1.20.0 release that Debian is currently using.

Since the fix involves only minor code changes on top of 1.20.0, I suggest
backporting the upstream patch in Debian.  This will ensure that Wireguard
support is complete and that it can be used fully graphically in Debian
bullseye.

I am attaching the upstream patch, here are the upstream references:

https://gitlab.gnome.org/GNOME/network-manager-applet/-/commit/514d033b8d0b9e411ba7e878ddbfa338c6720e6f

https://gitlab.gnome.org/GNOME/network-manager-applet/-/merge_requests/95

Thank you,
Baptiste

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

Kernel: Linux 5.9.0-2-amd64 (SMP w/4 CPU threads)
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 network-manager-gnome depends on:
ii  dbus-user-session [default-dbus-session-bus]  1.12.20-1
ii  dbus-x11 [dbus-session-bus]   1.12.20-1
ii  gnome-shell [polkit-1-auth-agent] 3.38.3-2
ii  libatk1.0-0   2.36.0-2
ii  libayatana-appindicator3-10.5.5-2
ii  libc6 2.31-9
ii  libcairo2 1.16.0-5
ii  libgdk-pixbuf-2.0-0   2.42.2+dfsg-1
ii  libglib2.0-0  2.66.7-1
ii  libgtk-3-03.24.24-1
ii  libjansson4   2.13.1-1.1
ii  libmm-glib0   1.14.10-0.1
ii  libnm01.28.0-2+b1
ii  libnma0   1.8.30-1
ii  libnotify40.7.9-3
ii  libpango-1.0-01.46.2-3
ii  libpangocairo-1.0-0   1.46.2-3
ii  libsecret-1-0 0.20.4-2
ii  libselinux1   3.1-3
ii  network-manager   1.28.0-2+b1

Versions of packages network-manager-gnome recommends:
ii  gnome-keyring  3.36.0-1
ii  gnome-shell [notification-daemon]  3.38.3-2
ii  iso-codes  4.5.0-1
ii  mobile-broadband-provider-info 20201225-1
ii  notification-daemon3.20.0-4

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

-- no debconf information
>From 514d033b8d0b9e411ba7e878ddbfa338c6720e6f Mon Sep 17 00:00:00 2001
From: Beniamino Galvani 
Date: Thu, 11 Feb 2021 09:45:00 +0100
Subject: [PATCH] applet: support activating WireGuard connections as VPNs

Display WireGuard connections in the VPN submenu and allow
[de]activating them.

https://gitlab.gnome.org/GNOME/network-manager-applet/-/issues/77
---
 src/applet.c | 65 
 1 file changed, 45 insertions(+), 20 deletions(-)

diff --git a/src/applet.c b/src/applet.c
index 8ebac755..8cf6dc43 100644
--- a/src/applet.c
+++ b/src/applet.c
@@ -875,6 +875,13 @@ applet_is_any_device_activating (NMApplet *applet)
return FALSE;
 }
 
+static gboolean
+connection_is_vpn (NMConnection *connection)
+{
+   returnnm_connection_is_type (connection, 
NM_SETTING_VPN_SETTING_NAME)
+  || nm_connection_is_type (connection, 
NM_SETTING_WIREGUARD_SETTING_NAME);
+}
+
 static gboolean
 applet_is_any_vpn_activating (NMApplet *applet)
 {
@@ -1062,10 +1069,13 @@ nma_menu_vpn_item_clicked (GtkMenuItem *item, gpointer 
user_data)
return;
}
 
-   active = applet_get_default_active_connection (applet, &device, FALSE);
-   if (!active || !device) {
-   g_warning ("%s: no active connection or device.", __func__);
-   return;
+   if (nm_connection_is_type (connection, NM_SETTING_VPN_SETTING_NAME)) {
+   active = applet_get_default_active_connection (applet, &device, 
FALSE);
+   if (!active || !device) {
+   /* FIXME: show a UI notification ? */
+   g_warning ("%s: no active connection or device.", 
__func__);
+  

Bug#690044: sudo: Please enable separated PAM session for initial login

[Hilko Bengen]

control: tag -1 confirmed pending patch

I agree with the suggested change, it mirrors what other distributions
are doing. Won't happen in time for bullseye, though.

My patch (against the current state of the package) can be fund in
.

Cheers,
-Hilko

Bug#973474: gnome: Unable to log back in in after screen lock

[Marcin Owsiany]

Thank you for looking into this Simon.

Regarding the messages I see in syslog, see the screenshot I had attached
to my previous message.

Is there perhaps some setting I could tweak to convince gnome-shell to
produce some debug output when I attempt unlocking?

Marcin

Bug#983639: docker-run manual page is not super readable

[Shengjing Zhu]

On Sun, Feb 28, 2021 at 2:07 AM Shengjing Zhu  wrote:
>
> Version: 20.10.4+dfsg1-1
>
> Hi,
>
> On Sun, Feb 28, 2021 at 1:45 AM VA  wrote:
> >
> > Package: docker.io
> > Version: 20.10.3+dfsg1-2
> > Severity: minor
> >
> > When viewing docker-run(1) manual page, the --network option description
> > has a very large ASCII table that doesn't fit even in a wide terminal.
> >
> > % man docker-run | grep -C5 -- --network | wc -L
> > warning: file '', around line 689:
> >table wider than line width
> > 290
> >
>
> I'm not sure what has changed in upstream or Debian build dependencies.
> But it should be fixed in 20.10.4+dfsg1-1
>

FTR, it's https://github.com/docker/cli/pull/2949

-- 
Shengjing Zhu

Bug#983640: ITP: scancode-toolkit -- detects licenses, copyrights, package manifests & dependencies and more by scanning code

[Jelmer Vernooij]

Package: wnpp
Severity: wishlist
Owner: Jelmer Vernooij 

* Package name: scancode-toolkit
  Version : 0.0.1
* URL : https://github.com/nexB/scancode-toolkit
* License : Apache-2.0, some CC-BY-4.0
  Programming Lang: Python
  Description : detects licenses, copyrights, package manifests & 
dependencies and more by scanning code

A typical software project often reuses hundreds of third-party packages.
License and origin information is not always easy to find and not normalized:
ScanCode discovers and normalizes this data.

Bug#983639: docker-run manual page is not super readable

[VA]

Package: docker.io
Version: 20.10.3+dfsg1-2
Severity: minor

When viewing docker-run(1) manual page, the --network option description 
has a very large ASCII table that doesn't fit even in a wide terminal.


% man docker-run | grep -C5 -- --network | wc -L
warning: file '', around line 689:
  table wider than line width
290

Bug#906752: sudo, pam_keyinit, what to do?

[Hilko Bengen]

The pam_keyring(8) manpage advises against adding pam_keyinit 

,
| This module should not, generally, be invoked by programs like su,
| since it is usually desirable for the key set to percolate through to
| the alternate context. The keys have their own permissions system to
| manage this.
`

However, there's no mentioning of the issue described here.

For what it's worth, RHEL/CentOS 7 ships an /etc/pam.d/sudo which
contains a line.

,
| sessionoptional pam_keyinit.so revoke
`

and they also seem to have different intended behavior for interactive
usage – there's a separate /etc/pam.d/sudo-i which contains

,
| sessionoptional pam_keyinit.so force revoke
`

Cheers,
-Hilko

Bug#973474: gnome: Unable to log back in in after screen lock

[Simon McVittie]

Control: tags -1 + moreinfo unreproducible

On Fri, 29 Jan 2021 at 18:22:43 +0100, Marcin Owsiany wrote:
> I installed Debian testing today in a VM and have the same problem in the
> GNOME+X11 session.
> When I type the wrong password in the lock screen, there is a spinner and 
> after
> a few seconds an error message.
> When I type the correct password, it *immediately* goes back to asking for the
> password.

I couldn't reproduce this.

Steps taken to try to reproduce this:

- Install from firmware-bullseye-DI-alpha3-amd64-netinst.iso, in
  virt-manager 1:3.2.0-3 and libvirt0 7.0.0-3 on a Debian unstable host
  system, using unprivileged VM ("QEMU/KVM User session")
- Configure virtual hardware using mostly virt-manager's default settings for
  Debian testing, except with RAM increased from 1024M to 2048M, and using a
  network bridge instead of user-mode networking
  - Q35 chipset
  - BIOS boot
  - 2 vCPUs
  - 2048 MiB RAM
  - 1 virtio disk, 20 GiB
  - SATA CD-ROM
  - QXL video card
- Set English (UK) keyboard, use an apt proxy, and enable SSH server in
  tasksel; otherwise accept default settings
- Reboot from installer to installed system

- Log in to gdm using default GNOME session (Wayland) to get a baseline
- Set idle lock timeout to 1 minute
- Leave VM to become idle
- Enter incorrect password
  - Wait for spinner and error message
- Enter correct password
  - Screen unlocks successfully

- Log out
- Log back in, choosing "GNOME on Xorg" session
  - Click on username
  - Before entering password, click on gear-wheel icon in bottom right
corner of screen and choose "GNOME on Xorg" from the menu
  - Enter password
- (Idle lock timeout is still 1 minute)
- Leave VM to become idle
- Enter incorrect password
  - Wait for spinner and error message
- Enter correct password
  - Screen unlocks successfully
- Lock screen explicitly (keyboard shortcut: Windows+L / Super+L)
- Enter incorrect password
  - Wait for spinner and error message
- Enter correct password
  - Screen unlocks successfully

- Same again, with "GNOME Classic" session

Versions of some maybe relevant packages:

- gdm3 3.38.2.1-1
- gnome-shell 3.38.3-2
- libglib2.0-0 2.66.7-1
- libmutter-7-0 3.38.3-2
- systemd 247.3-1
- xserver-xorg-core 2:1.20.10-3

Full package list attached.

> I do not see anything related in syslog.

What apparently unrelated things do you see in syslog at around that time?

> I can CTRL+ALT+F2 to log in at a text console to debug this, but I'm not sure
> how to go about this. "DISPLAY=:0 xlsclients" does not show a screensaver
> process running. Is the locking done by gnome-shell itself these days?

Yes, and that has been true ever since GNOME 3.0 around 10 years ago. In
sessions that use gnome-shell, it has always been responsible for doing
the locking itself.

A separate gnome-screensaver process was only used in GNOME 2 (and GNOME
Flashback, which is basically a continuation of GNOME 2).

On Sat, 31 Oct 2020 at 10:47:11 +0100, laurentdebian wrote:
> When the screens lock after idle, I can't log back in.
> I am ask to type my password, which I type correctly, then the screen goes 
> back
> locked (without an error message of any kind)
> When I got lock :
> I used Ctrl Alt Fx then
> Killall gdm3
>  and login again

Does this still happen in current bullseye?

Are you also using "GNOME on Xorg"?

What is logged in the system log when this happens?

smcv


bullseye-gnome-task.gz
Description: application/gzip

Bug#953415: Now gitlab work with newer version of libsass?

[Pirate Praveen]

On Wed, 9 Dec 2020 20:08:31 +0200 Dragos Jarca 
 wrote:

> Hi
>
> Some news about this bug?
>
> There are a lot of packages that depend of libsass and I cannot 
install

> updates because use libsass 3.6.1 because of gitlab workaround.
>
> Now gitlab work with newer version of libsass?

It is forwarded upstream, but no response.

https://github.com/sass/libsass/issues/3125

Bug#916638: Dragonfly is NEW

[Ross Gammon]

tags 916638 + pending
thanks

-- 
Regards,

Ross Gammon
FBEE 0190 904F 1EA0 BA6A  300E 53FE 7BBD A689 10FC



signature.asc
Description: OpenPGP digital signature

Bug#932456: Possible Patch

[Fabian Zaremba]

I faced the same issue with libvirt / AppArmor while designing backup 
solutions for our systems and found a possible solution.


Ubuntu carries (among many others) one relevant patch:

0031-virt-aa-helper-Ask-for-no-deny-rule-for-readonly-dis.patch

https://git.launchpad.net/ubuntu/+source/libvirt/tree/debian/patches/ubuntu-aa/0031-virt-aa-helper-Ask-for-no-deny-rule-for-readonly-dis.patch

I ported the Ubuntu Focal patch back to libvirt v5 and blockcommit works 
for me on Buster with AppArmor enabled / enforcing.


Bullseye should work the same with the patch from Ubuntu Hirsute (v7).

If I can help test this by providing source / binary packages or a 
Docker build environment please let me know.


--
Fabian Zaremba
Cooperative Student Computer Science
Division Research & Development

Konrad GmbH — Fritz-Reichle-Ring 12 — D-78315 Radolfzell
www.konrad-technologies.com
Geschäftsleitung: Michael Konrad
Handelsregisternr: HRB 550593 in Freiburg
Ust-Id-Nr. DE 206693267From: Serge Hallyn 
Date: Wed, 10 May 2017 15:16:30 +0200
Subject: [PATCH 31/33] virt-aa-helper: Ask for no deny rule for readonly disk
 elements

Just because a disk element only requests read access doesn't mean
there may not be another readwrite request.

Using 'R' when creating the apparmor rule will prevent an implicit
write-deny rule to be created alongside. This does not mean write
is allowed but it would cause a denial message and probably more
relevant, allows to add write access later.

Bug-Ubuntu: https://bugs.launchpad.net/bugs/1554031

Review note: Investigate whether instead of dropping explicit deny
write it would be possible to create explicit blockcommit rules
(LP: #1692441).

Forwarded: no (part of continuous upstreaming effort)
Signed-off-by: Christian Ehrhardt 
Signed-off-by: Stefan Bader 
Index: libvirt-5.0.0/src/security/virt-aa-helper.c
===
--- libvirt-5.0.0.orig/src/security/virt-aa-helper.c
+++ libvirt-5.0.0/src/security/virt-aa-helper.c
@@ -917,11 +917,11 @@ add_file_path(virDomainDiskDefPtr disk,
 
 if (depth == 0) {
 if (disk->src->readonly)
-ret = vah_add_file(buf, path, "rk");
+ret = vah_add_file(buf, path, "Rk");
 else
 ret = vah_add_file(buf, path, "rwk");
 } else {
-ret = vah_add_file(buf, path, "rk");
+ret = vah_add_file(buf, path, "Rk");
 }
 
 if (ret != 0)
From df20057fd2774cd61d86a6f0a7f05a545e1bd862 Mon Sep 17 00:00:00 2001
From: Serge Hallyn 
Date: Wed, 10 May 2017 15:16:30 +0200
Subject: [PATCH 31/33] virt-aa-helper: Ask for no deny rule for readonly disk
 elements

Just because a disk element only requests read access doesn't mean
there may not be another readwrite request.

Using 'R' when creating the apparmor rule will prevent an implicit
write-deny rule to be created alongside. This does not mean write
is allowed but it would cause a denial message and probably more
relevant, allows to add write access later.

Bug-Ubuntu: https://bugs.launchpad.net/bugs/1554031

Review note: Investigate whether instead of dropping explicit deny
write it would be possible to create explicit blockcommit rules
(LP: #1692441).

Forwarded: no (part of continuous upstreaming effort)
Signed-off-by: Christian Ehrhardt 
Signed-off-by: Stefan Bader 
---
 src/security/virt-aa-helper.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

--- a/src/security/virt-aa-helper.c
+++ b/src/security/virt-aa-helper.c
@@ -883,11 +883,11 @@ add_file_path(virStorageSourcePtr src,
 
 if (depth == 0) {
 if (src->readonly)
-ret = vah_add_file(buf, src->path, "rk");
+ret = vah_add_file(buf, src->path, "Rk");
 else
 ret = vah_add_file(buf, src->path, "rwk");
 } else {
-ret = vah_add_file(buf, src->path, "rk");
+ret = vah_add_file(buf, src->path, "Rk");
 }
 
 if (ret != 0)

Bug#981553: CVE-2021-3156 backport for jessie

[Hilko Bengen]

control: tag -1 moreinfo

Bastian,

thanks for providing the patches.

Since LTS support for jessie ended on June 30, 2020, do you expect
anything else to happen with these?

Cheers,
-Hilko

Bug#983314: linux-base: perf fails to report that linux-perf-5.10 is not installed

[Salvatore Bonaccorso]

Hi,

On Fri, Feb 26, 2021 at 06:47:57AM +0100, Salvatore Bonaccorso wrote:
> Control: tags -1 + confirmed
> 
> Hi Bart,
> 
> On Mon, Feb 22, 2021 at 11:57:56AM +0100, Bart Martens wrote:
> > Package: linux-base
> > Version: 4.6
> > Severity: minor
> > File: /usr/bin/perf
> > 
> > Observed behavior:
> > 
> > $ perf
> > /usr/bin/perf: line 13: exec: perf_5.10: not found
> > 
> > Expected behavior:
> > 
> > $ perf
> > /usr/bin/perf: line 14: exec: perf_5.10: not found
> > E: linux-perf-5.10 is not installed.
> 
> That's intersting, confirmed. The script is the same since the buster
> release without changes, but it looks it behaves differently in a buster
> vs.  unstable/bullseye environment when the replacement ${version%%-*}
> is involved after the version setting:
> 
> , [ perf-minimal ]
> | #!/bin/bash
> |
> | version="$(uname -r)"
> | version="${version%%-*}"
> | shopt -s execfail
> | exec "perf_$version" "$@"
> | echo >&2 "E: not installed."
> | exit 1
> `
> 
> In an buster environment:
> 
> ++ uname -r
> + version=4.19.0-14-amd64
> + version=4.19.0
> + shopt -s execfail
> + exec perf_4.19.0
> ./perf-minimal: line 6: exec: perf_4.19.0: not found
> + echo 'E: not installed.'
> E: not installed.
> + exit 1
> 
> In an unstable environment:
> 
> bash -x ./perf-minimal 
> ++ uname -r
> + version=4.19.0-14-amd64
> + version=4.19.0
> + shopt -s execfail
> + exec perf_4.19.0
> ./perf-minimal: line 6: exec: perf_4.19.0: not found

Experimenting further a bit, and set up a buster system then only
updated bash seems to trigger the issue:

root@bash-test:~# ./perf-minimal
./perf-minimal: line 6: exec: perf_4.19.0: not found
E: not installed.
root@bash-test:~# apt-get install bash
Reading package lists... Done
Building dependency tree
Reading state information... Done
Suggested packages:
  bash-doc
Recommended packages:
  bash-completion
The following packages will be upgraded:
  bash
1 upgraded, 0 newly installed, 0 to remove and 213 not upgraded.
Need to get 1,417 kB of archives.
After this operation, 31.7 kB of additional disk space will be used.
Get:1 http://deb.debian.org/debian bullseye/main amd64 bash amd64 5.1-2+b1 
[1,417 kB]
Fetched 1,417 kB in 0s (14.8 MB/s)
(Reading database ... 20940 files and directories currently installed.)
Preparing to unpack .../bash_5.1-2+b1_amd64.deb ...
Unpacking bash (5.1-2+b1) over (5.0-4) ...
Setting up bash (5.1-2+b1) ...
update-alternatives: using /usr/share/man/man7/bash-builtins.7.gz to provide 
/usr/share/man/man7/builtins.7.gz (builtins.7.gz) in auto mode
root@bash-test:~# ./perf-minimal
./perf-minimal: line 6: exec: perf_4.19.0: not found
root@bash-test:~#

Regards,
Salvatore

Bug#983470: cdbs: waf-unpack needs Python 2.7

[Claude et Nathalie Paroz]

On Wed, 24 Feb 2021 19:41:08 +0100 Sven Mueller 
 wrote:
> Am Mi., 24. Feb. 2021 um 19:34 Uhr schrieb Jonas Smedegaard 

> >:
>
> > severity -1 normal
> >
> > Hi Sven,
> >
> > Quoting Sven Mueller (2021-02-24 19:02:41)
> > > /usr/lib/cdbs/waf-unpack is using /usr/bin/python and it's syntax is
> > > Python 2 only.
> > > I have no clue what a WAF is, so I didn't spend time trying to fix
> > > this issue, sorry.
> > >
> > > Marking as serious as Python 2.7 is EOL and
> > > https://wiki.debian.org/Python/2Removal clearly says that 
packages are

> > > not allowed to rely on it.
> > > cdbs also doesn't depend on python-is-python2, which could be argued
> > > to allow this usage, so it is actually broken in Bullseye.
> >
> > Severity serious is appropriate for any packages actually using that
> > waf-unpack script, but not for CDBS offering that script.
> >
>
> I'd argue that the Python/2Removal doc clearly says that packages 
must not

> rely on /usr/bin/python.
> (And yes, there is a phrase in there particularly for packages needing it
> for
> their build process, but cdbs doesn't need it for the build process 
but to

> provide
> functionality for other packages to build.)
>
> As such, the bug to fix is in cdbs (don't use Python 2.7). And as far 
as I

> understood
> the discussions, the removal of Python 2 is basically a policy change, so
> using it
> would be a policy violation.
>
>
> > At least that's my personal opinion - the CDBS maintainers obviously
> > have the final say on this...¹
> >
>
> Well, yes, but I wonder if it is worth even discussing. The script is 
short

> enough that
> someone who knows what it should do can fix it quickly and verify that it
> still works,
> faster than this discussion could be resolved :-)

As far as I can see, the script is mostly Python 3 compatible, except 
for the 3 print statements at the end of the file.


So with this trivial patch, the issue could be solved:

diff --git a/scripts/waf-unpack b/scripts/waf-unpack
index d0309f2..db6b970 100755
--- a/scripts/waf-unpack
+++ b/scripts/waf-unpack
@@ -115,11 +115,11 @@ if __name__ == '__main__':
    (options, args) = parser.parse_args()

    if not options.waf and not options.dest:
-   print '--waf and --dest options are mandatory'
+   print('--waf and --dest options are mandatory')
    parser.print_help()
    sys.exit(1)

-   print 'Unpacking ' + options.waf + ' to ' + options.dest + ' ...'
+   print('Unpacking ' + options.waf + ' to ' + options.dest + ' ...')
    unpack_waf(options.waf, options.dest)
-   print 'Done'
+   print('Done')

Claude

Bug#981815: Please explain

[Hilko Bengen]

control: tag -1 moreinfo

I have read your bug report multiple times and it remains mostly unclear
what you are trying to achieve. Please try to come up with a more
minimal example and state what you'd expect to happen (and what happens
instead).

Some of your sudoers rule variants contain a "<" which under normal
circumstances will be interpreted by the shell, so this will not be part
of the command line that is passed to sudo.

Kind regards,
-Hilko

Bug#983637: tracker-extract: Add newfstat() to syscall list

[Julian Andres Klode]

Package: tracker-miners
Version: 2.3.5-2
Severity: normal
Tags: patch
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu hirsute ubuntu-patch
X-Debbugs-Cc: juli...@ubuntu.com

In Ubuntu, the attached patch was applied to achieve the following:

Fix tracker-extract crashing constantly with new glibc.

Thanks for considering the patch.

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

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

-- 
debian developer - deb.li/jak | jak-linux.org - free software dev
ubuntu core developer  i speak de, en
diff -Nru 
tracker-miners-2.3.5/debian/patches/libtracker-miners-common-Add-newstatat-statat64-syscalls.patch
 
tracker-miners-2.3.5/debian/patches/libtracker-miners-common-Add-newstatat-statat64-syscalls.patch
--- 
tracker-miners-2.3.5/debian/patches/libtracker-miners-common-Add-newstatat-statat64-syscalls.patch
  1970-01-01 01:00:00.0 +0100
+++ 
tracker-miners-2.3.5/debian/patches/libtracker-miners-common-Add-newstatat-statat64-syscalls.patch
  2021-02-27 13:13:59.0 +0100
@@ -0,0 +1,29 @@
+From b3fdbaf1ab23ce7191ace6db79575dfce5f90881 Mon Sep 17 00:00:00 2001
+From: Carlos Garnacho 
+Date: Sun, 25 Oct 2020 15:37:13 +0100
+Subject: [PATCH] libtracker-miners-common: Add newstatat/statat64 syscalls
+
+These are done in recent glib versions, should be observed here.
+
+Origin: upstream, 
https://gitlab.gnome.org/GNOME/tracker-miners/-/commit/b3fdbaf1ab23ce7191ace6db79575dfce5f90881.patch
+Bug-Ubuntu: https://bugs.launchpad.net/bugs/1916323
+---
+ src/libtracker-miners-common/tracker-seccomp.c | 2 ++
+ 1 file changed, 2 insertions(+)
+
+diff --git a/src/libtracker-miners-common/tracker-seccomp.c 
b/src/libtracker-miners-common/tracker-seccomp.c
+index c0327eb08..01887e829 100644
+--- a/src/libtracker-miners-common/tracker-seccomp.c
 b/src/libtracker-miners-common/tracker-seccomp.c
+@@ -91,6 +91,8 @@ tracker_seccomp_init (void)
+   /* Basic filesystem access */
+   ALLOW_RULE (fstat);
+   ALLOW_RULE (fstat64);
++  ALLOW_RULE (fstatat64);
++  ALLOW_RULE (newfstatat);
+   ALLOW_RULE (stat);
+   ALLOW_RULE (stat64);
+   ALLOW_RULE (statfs);
+-- 
+GitLab
+
diff -Nru tracker-miners-2.3.5/debian/patches/series 
tracker-miners-2.3.5/debian/patches/series
--- tracker-miners-2.3.5/debian/patches/series  2020-10-09 11:13:36.0 
+0200
+++ tracker-miners-2.3.5/debian/patches/series  2021-02-27 13:13:59.0 
+0100
@@ -5,3 +5,4 @@
 dont_start_for_root.patch
 Don-t-immediately-restart-tracker-extract-on-SIGSYS.patch
 debian/Revert-build-Include-libdir-in-rpath.patch
+libtracker-miners-common-Add-newstatat-statat64-syscalls.patch

Bug#983636: geary: Geary version 3.8.2 is missing in the Debian repositories

[mbrennwa]

Package: geary
Version: 3.38.x
Severity: normal
X-Debbugs-Cc: mbren...@gmail.com

Dear Maintainer,

Geary version 3.38.2 has been released a while ago, which fixes a number of
bugs:
https://gitlab.gnome.org/GNOME/geary/-/milestones/22

Version 3.38.2 is missing in the Debian repositories. I already sent an email
to the package maintainers, but did not receive any feedback.

Bug#983635: base-passwd: uid/gid reservation for Gnocchi users/groups

[Billy Olsen]

Package: base-passwd
Version: 3.5.47
Severity: normal

Dear Maintainer,

The Gnocchi metrics as a service package allows for storing time series database
information in a file system, which may be a shared file system. As a result,
inconsistencies between deployed machines in the uid/gid allocation for gnocchi
user and group results in situations which requires using overly broad 
permissions
on the shared file system being used (i.e. 777).

Please can a uid/gid reservation be allocated for gnocchi?

Thanks,

Billy

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

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

Versions of packages base-passwd depends on:
ii  libc6  2.31-0ubuntu9.2
ii  libdebconfclient0  0.251ubuntu1

Versions of packages base-passwd recommends:
ii  debconf [debconf-2.0]  1.5.73

base-passwd suggests no packages.

-- debconf information excluded

Bug#967047: Unsafe usage of KillMode=None fixed upstream

[Philip Stewart]

Hi,

Unsure whether there is any appetite to merge this for bullseye, but 
the fix for this has been merged upstream: 
https://gitlab.freedesktop.org/plymouth/plymouth/-/merge_requests/122


For what it's worth, I've implemented the changes locally and haven't 
observed any ill effects in doing so, e.g. flickering during boot.


Cheers,
Phil

Bug#983634: rt-extension-repeatticket: not compatible with RT5

[Dominic Hargreaves]

Source: rt-extension-repeatticket
Version: 1.11-1
Severity: important
Tags: sid
Forwarded: https://rt.cpan.org/Public/Bug/Display.html?id=133122

As mentioned in the upstream report, the styling is broken in RT5.
There is an rt5 branch from upstream, so in the worst case, it may be
possible to apply those changes if there's no upstream release by the time
we want to upload RT5 to unstable (and drop RT4).

Bug#983633: debian-installer: Debian installer (also doc) misses info about that is using screen in serial terminal installation, and info about shortcut keys...

[Marco Gaiarin]

Package: debian-installer
Severity: minor


I've recently installed an ARM system via serial terminal (but i suppose
this is not ARM specific, all serial installation as OOB system is the same)
and was unable to switch 'virtual console' that are listed on the first row
of the screen.

After looking and asking around i've finally found that installer in serial
terminal mode use 'screen', and so it was sufficient to use screen keybind.

But this is NOT reported on debian-installer manual, nor on a 'welcome'
screen.

Could be added? Thanks.

Bug#974828: printer-driver-hpcups: SIGABRT with "free(): invalid next size (normal)" in HPCupsFilter::cleanup

[Bernhard Übelacker]

Hello Ian,

Am 27.02.21 um 08:49 schrieb Ian Campbell:

On Fri, 2021-02-26 at 15:41 +0100, Bernhard Übelacker wrote:

The attached patch is an attempt to grow the buffer size
if the header changes on a new page.
This is just tested for the given crash, nothing more, therefore
there might be side effects on replacing this buffer?


It doesn't look unreasonable to me, although the related shuffling of
pointers between rgbRaster, kRaster and m_pPrinterBuffer makes my head
hurt a bit (this code could really do with a dollop of modern c++
memory management idiom).

Do you think there is a need to preserve the current contents (e.g.
something approximating realloc rather than delete+new)? Or maybe it is
fine to simply unconditionally allocate a new buffer each time round
the loop? It could almost be a local variable like *Raster at that
point... But I think if you are looking for a minimal fix your patch
seems pretty sensible to me (speaking as a competent enough C/C++
programmer but not someone familiar with this codebase before today).

Ian.


I guess I am similar unfamiliar with this code as you - so I am not 
really sure if there is any interaction with the old content or pointers 
stored to the old memory for later use ...

(I was just doing the debugging fun ;-) )
I had hoped, now as we could point to a source location,
that upstream could judge about it ...

Kind regards,
Bernhard

Bug#983491: Keyboard Layout configuration wizard - Swiss localization

[Axel Beckert]

Hi again,

Axel Beckert wrote:
> But then we should name it "Swiss German/Rumantsch/Liechtenstein
> German" and "Swiss French/Lëtzebuergesch" to be correct in your sense
> of correctness.

*sigh* "Swiss French/Swiss Italian/Lëtzebuergesch" of course.

Regards, Axel
-- 
 ,''`.  |  Axel Beckert , https://people.debian.org/~abe/
: :' :  |  Debian Developer, ftp.ch.debian.org Admin
`. `'   |  4096R: 2517 B724 C5F6 CA99 5329  6E61 2FF9 CD59 6126 16B5
  `-|  1024D: F067 EA27 26B9 C3FC 1486  202E C09E 1D89 9593 0EDE

Bug#983491: Keyboard Layout configuration wizard - Swiss localization

[Didier 'OdyX' Raboud]

Hello Mark,

Le mercredi, 24 février 2021, 21.31:43 h CET hispeedhsx a écrit :
> I'm new to Debian and I switch from centos but I have seen this problem for
> now several years and in several distributions even I think freebsd has it
> wrong (in my opinion).
> 
> So I'm from Switzerland and I use a "Swiss Keyboard". We have people who are
> talk and write in french and italian. There are also several people writing
> rumantsch which is a little bit special.

Swiss DD here; cc'ing debian-switzerland@ for further comments if needed

> When I see the keyboards layouts in the installer from
> debian-10.8.0-amd64-netinst I see there that Debian has a "Schweizerisches
> Französisch / Swiss French" and a "Schweizerdeutsch / Swiss German"
> keyboard layout.
> 
> There is one problem with this: In Switzerland we only have 1 hardware
> keyboard layout. Italian, German and French speaking people use this
> layout.

Although Switzerland indeed has only one hardware keyboard layout (the 
keyboard markings can be identical), it has (at least) two software 
interpretations, around the right part of the keyboard.

Specifically, the en_US "; / :" key will be:
 - "é / ö" in the Swiss French variant
 - "ö / é" in the Swiss German variant

There at least two other keys with such fr <> de swaps.

See
https://en.wikipedia.org/wiki/
QWERTZ#Switzerland_(German,_French,_Italian,_Romansh),_Liechtenstein,_Luxembourg

> In short there is only one keyboard and this has to be called: Swiss =
> Schweiz

No.

> If a Swiss person is only writing in french and they don't write often
> german so they will use the AZERTY keyboard which is the same as the French
> people are using for example.

That's really not true. At the very least, it's not _universally_ true for 
french-speaking Swiss people.

As one example, I have learned (in the nineties) and still type on Swiss-
french QWERTZ keyboards, with the é under my right pinky, and so do all the 
people I know from Suisse romande (besides the obvious IT people who might 
have switched to BÉPO or en_US QWERTY). I really don't know of anyone raised 
in Suisse romande typing on AZERTY.

> I will thank you for your responses and inputs. In my opinion this is a bug
> and should be fixed even it just for the small Switzerland.

It should not be fixed, as it's not a bug. Much to the contrary, it is OK as-
is; dropping the french variant of the Swiss QWERTZ keyboard would clearly 
alienate the french-speaking swiss (and the italian-speaking swiss too 
apparently), and deprive them from using their (valid) keyboard layout.

Hereby closing the bug report.

Best regards from Vevey, in Suisse romande.
OdyX

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

Bug#983632: salt: CVE-2020-28243 CVE-2020-28972 CVE-2020-35662 CVE-2021-3148 CVE-2021-3144 CVE-2021-25281 CVE-2021-25282 CVE-2021-25283 CVE-2021-25284 CVE-2021-3197

[Salvatore Bonaccorso]

Source: salt
Version: 3002.2+dfsg1-1
Severity: grave
Tags: security upstream
Justification: user security hole
X-Debbugs-Cc: car...@debian.org, Debian Security Team 

Hi,

The following vulnerabilities were published for salt.

CVE-2020-28243[0]:
| An issue was discovered in SaltStack Salt before 3002.5. The minion's
| restartcheck is vulnerable to command injection via a crafted process
| name. This allows for a local privilege escalation by any user able to
| create a files on the minion in a non-blacklisted directory.


CVE-2020-28972[1]:
| In SaltStack Salt before 3002.5, authentication to VMware vcenter,
| vsphere, and esxi servers (in the vmware.py files) does not always
| validate the SSL/TLS certificate.


CVE-2020-35662[2]:
| In SaltStack Salt before 3002.5, when authenticating to services using
| certain modules, the SSL certificate is not always validated.


CVE-2021-3148[3]:
| An issue was discovered in SaltStack Salt before 3002.5. Sending
| crafted web requests to the Salt API can result in
| salt.utils.thin.gen_thin() command injection because of different
| handling of single versus double quotes. This is related to
| salt/utils/thin.py.


CVE-2021-3144[4]:
| In SaltStack Salt before 3002.5, eauth tokens can be used once after
| expiration. (They might be used to run command against the salt master
| or minions.)


CVE-2021-25281[5]:
| An issue was discovered in through SaltStack Salt before 3002.5. salt-
| api does not honor eauth credentials for the wheel_async client. Thus,
| an attacker can remotely run any wheel modules on the master.


CVE-2021-25282[6]:
| An issue was discovered in through SaltStack Salt before 3002.5. The
| salt.wheel.pillar_roots.write method is vulnerable to directory
| traversal.


CVE-2021-25283[7]:
| An issue was discovered in through SaltStack Salt before 3002.5. The
| jinja renderer does not protect against server side template injection
| attacks.


CVE-2021-25284[8]:
| An issue was discovered in through SaltStack Salt before 3002.5.
| salt.modules.cmdmod can log credentials to the info or error log
| level.


CVE-2021-3197[9]:
| An issue was discovered in SaltStack Salt before 3002.5. The salt-
| api's ssh client is vulnerable to a shell injection by including
| ProxyCommand in an argument, or via ssh_options provided in an API
| request.


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

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2020-28243
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-28243
[1] https://security-tracker.debian.org/tracker/CVE-2020-28972
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-28972
[2] https://security-tracker.debian.org/tracker/CVE-2020-35662
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-35662
[3] https://security-tracker.debian.org/tracker/CVE-2021-3148
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-3148
[4] https://security-tracker.debian.org/tracker/CVE-2021-3144
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-3144
[5] https://security-tracker.debian.org/tracker/CVE-2021-25281
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-25281
[6] https://security-tracker.debian.org/tracker/CVE-2021-25282
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-25282
[7] https://security-tracker.debian.org/tracker/CVE-2021-25283
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-25283
[8] https://security-tracker.debian.org/tracker/CVE-2021-25284
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-25284
[9] https://security-tracker.debian.org/tracker/CVE-2021-3197
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-3197
[10] https://gitlab.com/saltstack/open/salt-patches
[11] 
https://saltproject.io/security_announcements/active-saltstack-cve-release-2021-feb-25/

Regards,
Salvatore

Bug#983631: blasr FTCBFS: multiple reasons

[Helmut Grohne]

Source: blasr
Version: 5.3.3+dfsg-5
Tags: patch
User: debian-cr...@lists.debian.org
Usertags: cross-satisfiability ftcbfs

blasr fails to cross build from source. The immediate issue is failing
to install python3 for the host architecture. Indeed, blasr does not
need a host architecture python, it merely wants a runnable (i.e. build
architecture) python for ./tools/git-clang-format. That can be requested
using python3:any or python3:native. Beyond this, it fails to pass a
suitable crossfile to meson. The easiest way of doing so is using
dh_auto_configure. Please consider applying the attached patch to make
blasr cross buildable.

Helmut
diff --minimal -Nru blasr-5.3.3+dfsg/debian/changelog 
blasr-5.3.3+dfsg/debian/changelog
--- blasr-5.3.3+dfsg/debian/changelog   2020-11-16 13:51:01.0 +0100
+++ blasr-5.3.3+dfsg/debian/changelog   2021-02-27 15:03:05.0 +0100
@@ -1,3 +1,12 @@
+blasr (5.3.3+dfsg-5.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix FTCBFS: (Closes: #-1)
++ Annotate python3 dependency with :any.
++ Let dh_auto_configure pass a crossfile to meson.
+
+ -- Helmut Grohne   Sat, 27 Feb 2021 15:03:05 +0100
+
 blasr (5.3.3+dfsg-5) unstable; urgency=medium
 
   * debhelper-compat 13 (routine-update)
diff --minimal -Nru blasr-5.3.3+dfsg/debian/control 
blasr-5.3.3+dfsg/debian/control
--- blasr-5.3.3+dfsg/debian/control 2020-11-16 13:51:01.0 +0100
+++ blasr-5.3.3+dfsg/debian/control 2021-02-27 15:02:52.0 +0100
@@ -4,7 +4,7 @@
 Section: science
 Priority: optional
 Build-Depends: debhelper-compat (= 13),
-   python3,
+   python3:any,
meson,
cmake,
pkg-config,
diff --minimal -Nru blasr-5.3.3+dfsg/debian/rules blasr-5.3.3+dfsg/debian/rules
--- blasr-5.3.3+dfsg/debian/rules   2020-11-16 13:51:01.0 +0100
+++ blasr-5.3.3+dfsg/debian/rules   2021-02-27 15:03:05.0 +0100
@@ -33,7 +33,7 @@
dh $@ --buildsystem=meson
 
 override_dh_auto_configure:
-   LDFLAGS="-L$(HTSLIB_LIB) -L$(HDF5_LIB) -lhdf5_cpp -lhdf5" 
CPPFLAGS="-isystem $(HDF5_INC)" meson -Dtests=false -Dprefix=/usr build .
+   LDFLAGS="-L$(HTSLIB_LIB) -L$(HDF5_LIB) -lhdf5_cpp -lhdf5" 
CPPFLAGS="-isystem $(HDF5_INC)" dh_auto_configure -- -Dtests=false
 
 bax2bam: utils/bax2bax/bin/bax2bam
 utils/bax2bax/bin/bax2bam:
@@ -47,7 +47,3 @@
 override_dh_auto_test:
echo Tests require data not available in the source distribution
 endif
-
-override_dh_auto_build:
-   ln -s build obj-$(DEB_BUILD_GNU_TYPE)
-   dh_auto_build

Bug#983630: pbdagcon FTCBFS: python3 dependency not installable

[Helmut Grohne]

Source: pbdagcon
Version: 0.3+git20180411.c14c422+dfsg-1
Tags: patch
User: debian-cr...@lists.debian.org
Usertags: cross-satisfiability

pbdagcon cannot be cross built from source, because installing the host
architecture python3 fails. Indeed, pbdagcon wants a runnable (i.e.
build architecture) python for running configure.py. Its python3
dependency should be annotated :any. Please consider applying the
attached patch.

Helmut
diff --minimal -Nru pbdagcon-0.3+git20180411.c14c422+dfsg/debian/changelog 
pbdagcon-0.3+git20180411.c14c422+dfsg/debian/changelog
--- pbdagcon-0.3+git20180411.c14c422+dfsg/debian/changelog  2020-01-28 
11:13:47.0 +0100
+++ pbdagcon-0.3+git20180411.c14c422+dfsg/debian/changelog  2021-02-27 
15:13:14.0 +0100
@@ -1,3 +1,10 @@
+pbdagcon (0.3+git20180411.c14c422+dfsg-1.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix FTCBFS: Annotate python3 dependency :any. (Closes: #-1)
+
+ -- Helmut Grohne   Sat, 27 Feb 2021 15:13:14 +0100
+
 pbdagcon (0.3+git20180411.c14c422+dfsg-1) unstable; urgency=medium
 
   * Add myself to Uploaders to have at least one human uploader after
diff --minimal -Nru pbdagcon-0.3+git20180411.c14c422+dfsg/debian/control 
pbdagcon-0.3+git20180411.c14c422+dfsg/debian/control
--- pbdagcon-0.3+git20180411.c14c422+dfsg/debian/control2020-01-28 
11:13:47.0 +0100
+++ pbdagcon-0.3+git20180411.c14c422+dfsg/debian/control2021-02-27 
15:13:12.0 +0100
@@ -4,7 +4,7 @@
 Section: science
 Priority: optional
 Build-Depends: debhelper-compat (= 12),
-   python3,
+   python3:any,
zlib1g-dev,
libhdf5-dev,
libboost-dev,

Bug#982591: grub-pc can't be updated non-interactively on debian/buster64

[Evgeni Golov]

On Fri, Feb 26, 2021 at 10:54:32PM +0100, Lucas Nussbaum wrote:
> On 26/02/21 at 20:07 +0100, Lucas Nussbaum wrote:
> > On 14/02/21 at 08:48 +0100, Evgeni Golov wrote:
> > > On Sat, Feb 13, 2021 at 11:57:52PM +0100, Thomas Lange wrote:
> > > > IMO we cannot know which device name is used  by the users 
> > > > virtualisation environment.
> > > > So, what is the be setting without knowing the device name?
> > > > 
> > > > Or is /dev/sda used in most enviroments?
> > > 
> > > For VirtualBox sda is a pretty safe bet, for libvirt it'd be either sda
> > > or vda (and I think we could set both in debconf, as that's a
> > > multiselect). AWS has another one, vxda I think? But this explicit bug
> > > is about vagrant (so virtualbox and libvirt) only anyways.
> > > 
> > > The only thing to consider with this approach: it should only be done
> > > when preparing images, not installing "real" systems. So in the
> > > cloud.d.o context that's safe, but probably not as a generic default in
> > > FAI and other tools.
> > 
> > Maybe a better approach (but still hackish) would be to set it at first
> > boot, in a way similar to
> > https://salsa.debian.org/cloud-team/debian-vagrant-images/-/blob/master/config_space/files/etc/systemd/system/generate-sshd-host-keys.service/VAGRANT
> > 
> > Running Something like:
> > echo grub-pc grub-pc/install_devices multiselect $(awk '{ if ($2 == "/") { 
> > sub(/1$/, "", $1) ; print $1 } }' /proc/mounts) | debconf-set-selections
> 
> Tentative patch:
> https://salsa.debian.org/cloud-team/debian-vagrant-images/-/commit/b82d522f65b507767f909b2b9471c5a9ade75e05

Thanks Lucas! That looks quite like the "first-boot script" I mentioned
in the original report.

One q tho: isn't `findmnt --noheadings --output SOURCE /` easier to read
than running awk on /proc/mounts? It's in util-linux and that's
essential anyways :)

Evgeni

Bug#958787: maven-cache-cleanup: diff for NMU version 1.0.4-1.2

[Adrian Bunk]

Control: tags 958787 + patch
Control: tags 958787 + pending

Dear maintainer,

I've prepared an NMU for maven-cache-cleanup (versioned as 1.0.4-1.2) 
and uploaded it to DELAYED/1. Please feel free to tell me if I should 
cancel it.

cu
Adrian
diff -Nru maven-cache-cleanup-1.0.4/debian/changelog maven-cache-cleanup-1.0.4/debian/changelog
--- maven-cache-cleanup-1.0.4/debian/changelog	2021-01-06 00:12:52.0 +0200
+++ maven-cache-cleanup-1.0.4/debian/changelog	2021-02-27 16:12:46.0 +0200
@@ -1,3 +1,11 @@
+maven-cache-cleanup (1.0.4-1.2) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Add the missing dependency on java-wrappers, thanks to
+Hans Joachim Desserud for the bug report. (Closes: #958787)
+
+ -- Adrian Bunk   Sat, 27 Feb 2021 16:12:46 +0200
+
 maven-cache-cleanup (1.0.4-1.1) unstable; urgency=medium
 
   * Non maintainer upload by the Reproducible Builds team.
diff -Nru maven-cache-cleanup-1.0.4/debian/control maven-cache-cleanup-1.0.4/debian/control
--- maven-cache-cleanup-1.0.4/debian/control	2018-04-24 00:19:29.0 +0300
+++ maven-cache-cleanup-1.0.4/debian/control	2021-02-27 16:12:46.0 +0200
@@ -14,7 +14,7 @@
 
 Package: maven-cache-cleanup
 Architecture: all
-Depends: ${maven:Depends}, ${misc:Depends}, default-jre-headless | java7-runtime-headless
+Depends: ${maven:Depends}, ${misc:Depends}, default-jre-headless | java7-runtime-headless, java-wrappers
 Suggests: ${maven:OptionalDepends}
 Description: Utility to purge timestamped snapshots from Maven repositories
  Maven 3 dropped support for non-unique snapshot versions, which had the

Bug#983629: consider demoting the grass-core -> grass-doc dependency to Recommends

[Helmut Grohne]

Package: grass-core
Version: 7.8.5-1
User: debian-cr...@lists.debian.org
Usertags: cross-satisfiability
Control: affects -1 + src:libgdal-grass src:qgis

The affected packages cannot satisfy their cross Build-Depends, because
their transitive dependency on grass-doc is not satisfiable. In this
case, the dependency seems dubious. Why should building software against
grass require its documentation? I'm therefore asking whether it would
be reasonable to demote this dependency to Recommends. Package builds
would no longer include grass-doc, but developer installations (that do
not opt out of Recommends) would continue to include grass-doc. Please
either close this bug as wontfix or demote the dependency.

Helmut

Bug#983628: unblock: geeqie/1:1.6-7

[Andreas Ronnquist]

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

Please unblock package geeqie

This new version fixes a recently discovered regression, in remote
handling in geeqie. It closes #983546 - a regression in the way you
could show an image in an already running geeqie, instead of starting a
new instance of the program. (Without the fix and running remote
geeqie instance it always starts new instances of the program).

Leaf package, small fix, not many alternatives to this particular usage
according to the bug reporter.

(The patch also removes a trailing whitespace in d/changelog, which
itself isn't mentioned in the changelog.)

unblock geeqie/1:1.6-7


-- Andreas Rönnquist
gus...@debian.org
diff -Nru geeqie-1.6/debian/changelog geeqie-1.6/debian/changelog
--- geeqie-1.6/debian/changelog	2021-01-16 15:05:21.0 +0100
+++ geeqie-1.6/debian/changelog	2021-02-27 13:36:57.0 +0100
@@ -1,3 +1,10 @@
+geeqie (1:1.6-7) unstable; urgency=medium
+
+  * Add patch fixing regression --remote option failing
+(Closes: #983546)
+
+ -- Andreas Rönnquist   Sat, 27 Feb 2021 13:36:57 +0100
+
 geeqie (1:1.6-6) unstable; urgency=medium
 
   * Add patch to fix which image rotatation-keys affect
@@ -13,7 +20,7 @@
 
 geeqie (1:1.6-4) unstable; urgency=medium
 
-  * Add patch to fix segfault on X with clutter 
+  * Add patch to fix segfault on X with clutter
 (Closes: #979463, #979561, #971403)
 
  -- Andreas Rönnquist   Sat, 09 Jan 2021 13:47:51 +0100
diff -Nru geeqie-1.6/debian/patches/0006-Fix-860-871-remote-and-slideshow-on-startup.patch geeqie-1.6/debian/patches/0006-Fix-860-871-remote-and-slideshow-on-startup.patch
--- geeqie-1.6/debian/patches/0006-Fix-860-871-remote-and-slideshow-on-startup.patch	1970-01-01 01:00:00.0 +0100
+++ geeqie-1.6/debian/patches/0006-Fix-860-871-remote-and-slideshow-on-startup.patch	2021-02-27 13:30:35.0 +0100
@@ -0,0 +1,32 @@
+From: Colin Clark 
+Date: Sat, 27 Feb 2021 09:12:40 +
+Subject: Fix #860, #871: --remote and --slideshow on startup
+
+https://github.com/BestImageViewer/geeqie/issues/860
+https://github.com/BestImageViewer/geeqie/issues/871
+
+Remote slideshow delay is ignored
+
+--remote --File=IMAGE fails: not displaying image, not using running
+instance, not forking
+---
+ src/main.c | 6 --
+ 1 file changed, 6 deletions(-)
+
+diff --git a/src/main.c b/src/main.c
+index 1356f9a..54c10ea 100644
+--- a/src/main.c
 b/src/main.c
+@@ -453,12 +453,6 @@ static void parse_command_line(gint argc, gchar *argv[])
+ }
+ 			remote_list = g_list_prepend(remote_list, "--new-window");
+ 			}
+-		else if (!remote_server_exists(app_lock))
+-			{
+-			/* Geeqie started for first time but with --remote option
+-			 */
+-			remote_do = FALSE;
+-			}
+ 		g_free(app_lock);
+ 		}
+ 
diff -Nru geeqie-1.6/debian/patches/series geeqie-1.6/debian/patches/series
--- geeqie-1.6/debian/patches/series	2021-01-16 15:04:01.0 +0100
+++ geeqie-1.6/debian/patches/series	2021-02-27 13:30:35.0 +0100
@@ -3,3 +3,4 @@
 0003-Fix-832-Geeqie-remembers-desktop.patch
 0004-Fix-829-segfault-with-clutter-gtk.patch
 0005-Fix-822-The-image-rotation-keys-and-affect-the-wrong.patch
+0006-Fix-860-871-remote-and-slideshow-on-startup.patch

Bug#983626: man2html: Please include Polish hman.1

[Helge Kreutzmann]

Package: man2html
Severity: wishlist
Tags: patch l10n

Until recently manpages-pl contained hman.1. However, upstream noticed
that translations are shipped upstream and in distribution packages,
although, upstream maintenance appears to have ceased.

Therefor please find the Polish version of hman.1 attached. I
also included the po file, which we used to build the file (using
po4a).

In case upstream resumes maintenance, please forward this translated
man page to upstream.


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

Versions of packages man2html depends on:

ii  apache2 [httpd-cgi]2.4.46-4
ii  debconf [debconf-2.0]  1.5.74
ii  gawk   1:5.1.0-1
ii  libc6  2.31-9
ii  man-db 2.9.4-1
pn  man2html-base  
ii  sensible-utils 0.0.14

man2html recommends no packages.

Versions of packages man2html suggests:
ii  chimera2 [www-browser]   2.0a19-8+b3
ii  chromium [www-browser]   88.0.4324.182-1
ii  firefox-esr [www-browser]78.7.0esr-1
ii  konqueror [www-browser]  4:20.12.0-4
ii  links [www-browser]  2.21-1+b1
ii  sugar-browse-activity [www-browser]  206-1
pn  swish++  
ii  w3m [www-browser]0.5.3+git20210102-3

-- 
  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/
.\" -*- coding: UTF-8 -*-
.\" Copyright (c) 1998 Andries Brouwer
.\"
.\" You may distribute under the terms of the GNU General Public
.\" License as specified in the README file that comes with the man 1.0
.\" distribution.  
.\"***
.\"
.\" This file was generated with po4a. Translate the source file.
.\"
.\"***
.TH hman 1 "19 stycznia 1998"  
.SH NAZWA
hman \- przeglądanie stron podręcznika ekranowego
.SH SKŁADNIA
\fBhman\fP [ \-P \fIprzeglądarka\fP ] [ \-H \fIkomputer\fP ] [ \fIsekcja\fP ] 
\fInazwa\fP
.br
\fBhman\fP [ \-P \fIprzeglądarka\fP ] [ \-H \fIkomputer\fP ] [ \fIsekcja\fP ] [ 
indeks ]
.SH OPIS
Skrypt \fBhman\fP jest interfejsem do programu man2html(1), pozwalającym na
wprowadzenie nazwy strony podręcznika ekranowego i zobaczenia jej w swojej
ulubionej przeglądarce www.  Swoim zachowaniem przypomina polecenie
\fBman\fP(1), więc można utworzyć alias z \fBhman\fP do \fBman\fP.  Jeżeli 
używaną
przeglądarką jest netscape i netscape jest już uruchomiony, to \fBhman\fP użyje
właśnie tej uruchomionej przeglądarki.

.SH OPCJE
.TP 
\fB\-\^P  przeglądarka\fP
Specify which browser (like lynx, xmosaic, arena, chimera, netscape, amaya,
\&...) to use.  This option overrides the \fBMANHTMLPAGER\fP environment
variable.  The default is \fBsensible\-browser\fP.
.br
A special value \fIlynxcgi\fP can be used for the non\-httpd version of 
\fBlynx\fP,
but this requires the \fBlynx\fP(1)  command to be installed and approprietly
configured.
.TP 
\fB\-\^H  komputer\fP
Określa, z którego komputera należy wziąć strony podręcznika. Ta opcja
unieważnia zmienną środowiskową \fBMANHTMLHOST\fP. Domyślną wartością jest
\fBlocalhost\fP.

.SH ŚRODOWISKO
.TP 
MANHTMLPAGER
Domyślna przeglądarka www jest wybierana na podstawie wartości tej zmiennej.
.TP 
MANHTMLHOST
Domyślna komputer jest wybierany na podstawie wartości tej zmiennej.

.SH "ZOBACZ TAKŻE"
\fBman\fP(1), \fBman2html\fP(1), \fBarena\fP(1), \fBlynx\fP(1), 
\fBsensible\-browser\fP(1),
\fBnetscape\fP(1), \fBxmosaic\fP(1), \fBglimpse\fP(1)

http://www.mcom.com/newsref/std/x\-remote.html

.SH TŁUMACZENIE
Autorami polskiego tłumaczenia niniejszej strony podręcznika są:
Robert Luberda 
.

Niniejsze tłumaczenie jest wolną dokumentacją. Bliższe informacje o warunkach
licencji można uzyskać zapoznając się z GNU General Public License w wersji 3
lub nowszej. Nie przyjmuje się ŻADNEJ ODPOWIEDZIALNOŚCI.

Błędy w tłumaczeniu strony podręcznika prosimy zgłaszać na adres
.
# Polish translation of manpages
# This file is distributed under the same license as the manpages-l10n package.
# Copyright © of this file:
# Robert Luberda , 2003, 2014.
msgid ""
msgstr ""
"Project-Id-Version: manpages-pl\n"
"POT-Creation-Date: 2020-12-26 21:58+01:00\n"
"PO-Revision-Date: 2014-04-14 22:18+0200\n"
"Last-Translator: Robert Luberda \n"
"Language-Team: Polish \n"
"Language: pl\n"
"MIME-Version: 1.0\n"
"Content-Type: text/plain; charset=UTF-8\n"
"Content-Transfer-Encoding: 8bit\n"
"Plural-Forms: nplurals=3; plural=(n==1 ? 0 : n%10>=2 && n%10<=4 && (n%100<10 "
"|| n%100>=20) ? 1 : 2);\n"
"X-Generator: Lokalize 1.5\n"

#. type: TH
#: debian-buster debian-unstable fedora-rawhide mageia-cauldron
#, no-wrap
msg

Bug#983627: man2html-base: Please include Polish man2html.1

[Helge Kreutzmann]

Package: man2html-base
Severity: wishlist
Tags: patch l10n


Until recently manpages-pl contained man2html.1. However, upstream noticed
that translations are shipped upstream and in distribution packages,
although, upstream maintenance appears to have ceased.

Therefor please find the Polish version of man2html.1 attached. I
also included the po file, which we used to build the file (using
po4a).

In case upstream resumes maintenance, please forward this translated
man page to upstream.


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

Versions of packages man2html-base depends on:
ii  libc6  2.31-9

man2html-base recommends no packages.

Versions of packages man2html-base suggests:
ii  manpages  5.10-1
ii  manpages-dev  5.10-1

-- 
  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/
.\" -*- coding: UTF-8 -*-
'\" t
.\" Man page for man2html
.\" aeb, 980101
.\"
.\"***
.\"
.\" This file was generated with po4a. Translate the source file.
.\"
.\"***
.TH man2html 1 "1 stycznia 1998"  
.SH NAZWA
man2html \- formatuje stronę man w html\-u
.SH SKŁADNIA
\fBman2html\fP [\fIopcje\fP] [\fIplik\fP]
.SH OPIS
\fBman2html\fP wykonuje konwersję strony podręcznika systemowego zapisanej w
podanym \fIpliku\fP (lub pobieranej ze standardowego wejścia, w przypadku gdy
nie podano nazwy pliku lub podano nazwę "\-") z używanego przez man formatu
nroff na html i drukuje wynik na stdout. Obsługuje tbl, ale nie zna eqn. Kod
zakończenia wynosi 0. Jeśli coś się nie powiedzie, to na standardowe wyjście
wypisywana jest strona z komunikatem błędu.

.\" (See
.\" .BR man (1)
.\" for info on how to browse man pages via
.\" .BR man2html .
.\" Usually it would suffice to put "MANHTMLPAGER=/usr/bin/lynx"
.\" in the environment.)
Może być wykorzystywane jako samodzielne narzędzie, ale zasadniczo
zaprojektowano je do zastosowań pomocniczych, by umożliwić użytkownikom
przeglądanie stron podręcznika systemowego za pomocą przeglądarki html,
takiej jak np.  \fBlynx\fP(1), \fBxmosaic\fP(1)  czy \fBnetscape\fP(1).

Główną część \fBman2html\fP stanowi konwerter troff\-na\-html napisany przez
Richarda Verhoevena (r...@win.tue.nl). Dodaje on odnośniki hipertekstowe do
następujących konstrukcji:
.LP
.TS
l l.
foo(3x) "http://localhost/cgi\-bin/man/man2html?3x+foo";
metoda://łańcuch"metoda://łańcuch"
www.nazwa.hosta "http://www.host.name";
ftp.nazwa.hosta "ftp://ftp.host.name";
nazwa@host  "mailto:name@host";
  "file:/usr/include/string.h"
.TE
.LP
(Pierwsza z nich może być dopasowywana do potrzeb przez opcje \- zobacz
niżej). Nie jest wykonywane żadne wyszukiwanie \- obiekty wskazywane przez
tworzone odnośniki nie muszą istnieć. Tworzony jest też indeks wewnętrznych
odnośników hipertekstowych do różnych sekcji strony, co ułatwia orientację w
dużych stronach jak \fBbash\fP(1).

.SH OPCJE
Przy odczycie ze standardowego wejścia nie zawsze jest jasne, jak wykonać
rozwinięcie żądania .so. Opcja \-D pozwala skryptowi na zdefiniowanie
katalogu roboczego.
.LP
.TP 
\fB\-\^D\fP\fI ścieżka\fP
Przed rozpoczęciem konwersji obcina ostatnie dwie części ścieżki i w
odniesieniu do pozostałej części wykonuje \fIchdir\fP(\fIdir\fP).
.LP
Opcja \-E umożliwia skryptowi cgi łatwe tworzenie komunikatów o błędach.
.LP
.TP 
\fB\-\^E\fP\fI łańcuch\fP
Tworzy w wyniku stronę zawierającą zadany komunikat o błędzie.
.LP
Ogólną postacią odnośnika hipertekstowego generowanego dla odsyłacza strony
man jest
.IP
<ścieżkaman2html>
.LP
z wartością domyślną pokazaną powyżej. Składowe tego odnośnika ustawiane są
przy pomocy różnych opcji.
.TP 
\fB\-\^h\fP
.\" This is the default.
Ustawia metoda:ścieżkacgi na http://localhost.
.TP 
\fB\-\^HP\fP\fI host[.domena][:port]\fP
Ustawia metoda:ścieżkacgi na http://\fIhost.domena:port\fP.
.TP 
\fB\-\^l\fP
Ustawia metoda:ścieżkacgi na lynxcgi:\fI/usr/lib\fP.
.TP 
\fB\-\^L\fP\fI katalog\fP
Ustawia metoda:ścieżkacgi na lynxcgi:\fIkatalog\fP.
.TP 
\fB\-\^M\fP\fI ścieżkaman2html\fP
Ustawia ścieżkę man2html, jaka ma być użyta. Domyślnie jest to
\fI/cgi\-bin/man/man2html\fP.
.TP 
\fB\-\^p\fP
Ustawia separator na "/".
.TP 
\fB\-\^q\fP
Ustawia separator na "?". Jest to separator domyślny.
.TP 
\fB\-\^r\fP
Używa względnych ścieżek html, zamiast ścieżek typu cgi\-bin.
.LP
Na maszynach, na których nie jest uruchomiony \fBhttpd\fP, można do
przeglądania stron man używać przeglądarki \fBlynx\fP, wykorzystując metodę
lynxcgi. Jeżeli pracuje jakiś demon http, do przeglądania można użyć lynxa,
czy jakiejkolwiek innej przeglądarki, wykorzystując metodę http. Opcja \-l
(oznaczająca "lynxcgi")

Bug#983624: pcscd: filter variable setup to disable readers not possible with systemd

[Norbert Preining]

Package: pcscd
Version: 1.9.1-1
Severity: normal

Hi

pcscd allows exlcuding certain readers from listening to it (and thus
allows forwarding to VMs etc). This is done via the two env vars
PCSCLITE_FILTER_IGNORE_READER_NAMES
PCSCLITE_FILTER_EXTEND_READER_NAMES
I don't see a way how I can set up these variables so that the systemd
activated socket/service gets them when being started.

The website from Ludovic about this topic

https://ludovicrousseau.blogspot.com/2015/12/remove-andor-customize-pcsc-reader-names.html
mentions
GNU/Linux systems using systemd will need a different configuration. 
The systemd
configuration is left as an exercise for the reader.

Any suggestion?

Thanks

Norbert


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

Kernel: Linux 5.10.19 (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), 
LANGUAGE=en_US:en
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages pcscd depends on:
ii  init-system-helpers 1.60
ii  libc6   2.31-9
ii  libccid [pcsc-ifd-handler]  1.4.34-1
ii  libpcsclite11.9.1-1
ii  libsystemd0 247.3-1
ii  libudev1247.3-1
ii  lsb-base11.1.0

pcscd recommends no packages.

Versions of packages pcscd suggests:
ii  systemd  247.3-1

-- no debconf information

Bug#983618: python3-zaqar-ui: causes openstack-dashboard to fail upon installation

[Thomas Goirand]

On 2/27/21 12:15 PM, Andreas Beckmann wrote:
> Package: python3-zaqar-ui
> Version: 9.0.0~rc1-1
> Severity: serious
> User: debian...@lists.debian.org
> Usertags: piuparts
> Control: affects -1 + src:horizon src:zaqar-ui
> 
> Hi,
> 
> during a test with piuparts I noticed your package failed to install. As
> per definition of the release team this makes the package too buggy for
> a release, thus the severity.
> 
> From the attached log (scroll to the bottom...):
> 
>   Setting up openstack-dashboard (3:18.6.1-1) ...
>   Warning: Could not import Horizon dependencies. This is normal during 
> installation.
>   RemovedInDjango40Warning: django.utils.translation.ugettext_lazy() is 
> deprecated in favor of 
> django.utils.translation.gettext_lazy().RemovedInDjango40Warning: 
> django.utils.translation.ugettext_lazy() is deprecated in favor of 
> django.utils.translation.gettext_lazy().RemovedInDjango40Warning: 
> django.utils.translation.ugettext_lazy() is deprecated in favor of 
> django.utils.translation.gettext_lazy().RemovedInDjango40Warning: 
> django.utils.translation.ugettext_lazy() is deprecated in favor of 
> django.utils.translation.gettext_lazy().RemovedInDjango40Warning: 
> django.utils.translation.ugettext_lazy() is deprecated in favor of 
> django.utils.translation.gettext_lazy().RemovedInDjango40Warning: 
> django.utils.translation.ugettext_lazy() is deprecated in favor of 
> django.utils.translation.gettext_lazy().RemovedInDjango40Warning: 
> django.utils.translation.ugettext_lazy() is deprecated in favor of 
> django.utils.translation.gettext_lazy().RemovedInDjango40Warning: 
> django.utils.translation.ugettext_lazy() is deprecated in favor of 
> django.utils.translation.gettext_lazy().RemovedInDjango40Warning: 
> django.utils.translation.ugettext_lazy() is deprecated in favor of 
> django.utils.translation.gettext_lazy().RemovedInDjango40Warning: 
> django.utils.translation.ugettext_lazy() is deprecated in favor of 
> django.utils.translation.gettext_lazy().RemovedInDjango40Warning: 
> django.utils.translation.ugettext_lazy() is deprecated in favor of 
> django.utils.translation.gettext_lazy().RemovedInDjango40Warning: 
> django.utils.translation.ugettext_lazy() is deprecated in favor of 
> django.utils.translation.gettext_lazy().RemovedInDjango40Warning: 
> django.utils.translation.ugettext_lazy() is deprecated in favor of 
> django.utils.translation.gettext_lazy().Traceback (most recent call last):
> File "/usr/share/openstack-dashboard/manage.py", line 23, in 
>   execute_from_command_line(sys.argv)
> File "/usr/lib/python3/dist-packages/django/core/management/__init__.py", 
> line 419, in execute_from_command_line
>   utility.execute()
> File "/usr/lib/python3/dist-packages/django/core/management/__init__.py", 
> line 395, in execute
>   django.setup()
> File "/usr/lib/python3/dist-packages/django/__init__.py", line 24, in 
> setup
>   apps.populate(settings.INSTALLED_APPS)
> File "/usr/lib/python3/dist-packages/django/apps/registry.py", line 91, 
> in populate
>   app_config = AppConfig.create(entry)
> File "/usr/lib/python3/dist-packages/django/apps/config.py", line 224, in 
> create
>   import_module(entry)
> File "/usr/lib/python3.9/importlib/__init__.py", line 127, in 
> import_module
>   return _bootstrap._gcd_import(name[level:], package, level)
> File "", line 1030, in _gcd_import
> File "", line 1007, in _find_and_load
> File "", line 986, in _find_and_load_unlocked
> File "", line 680, in _load_unlocked
> File "", line 790, in exec_module
> File "", line 228, in 
> _call_with_frames_removed
> File "/usr/lib/python3/dist-packages/django_pyscss/__init__.py", line 1, 
> in 
>   from .compiler import DjangoScssCompiler  # NOQA
> File "/usr/lib/python3/dist-packages/django_pyscss/compiler.py", line 6, 
> in 
>   from django.utils.six.moves import StringIO
>   ModuleNotFoundError: No module named 'django.utils.six'
>   dpkg: error processing package openstack-dashboard (--configure):
>installed openstack-dashboard package post-installation script subprocess 
> returned error exit status 1
>   dpkg: dependency problems prevent configuration of python3-zaqar-ui:
>python3-zaqar-ui depends on openstack-dashboard (>= 3:17.1.0); however:
> Package openstack-dashboard is not configured yet.
>   
>   dpkg: error processing package python3-zaqar-ui (--configure):
>dependency problems - leaving unconfigured
>   Processing triggers for ca-certificates (20210119) ...
>   Updating certificates in /etc/ssl/certs...
>   0 added, 0 removed; done.
>   Running hooks in /etc/ca-certificates/update.d...
>   done.
>   Errors were encountered while processing:
>openstack-dashboard
>python3-zaqar-ui
> 
> 
> cheers,
> 
> Andreas
> 

Hi Andreas,

Thanks for your bug report.

The traceback you've past above looks more like a problem in
django_pyscss no?

Cheers,

Thomas Goirand (zigo)

Bug#932752: gawk should pre-depend on shared libraries

[Adrian Bunk]

Control: reassign -1 libreadline8
Control: retitle -1 libreadline should pre-depend on libtinfo
Control: affects -1 gawk libpam0g

On Mon, Feb 01, 2021 at 01:00:42PM -0500, Sam Hartman wrote:
>...
> I agree with Steve's analysis and believe that the solution is for gawk
> to hold itself to the standards of an essential package, and thus
> pre-depend on its shared libraries.
>...

That's what gawk is doing since hamm.

Steve said that libreadline should pre-depend on libtinfo.

cu
Adrian

Bug#983618: python3-zaqar-ui: causes openstack-dashboard to fail upon installation

[Andreas Beckmann]

Followup-For: Bug #983618
Control: affects -1 + src:vitrage-dashboard python3-vitrage-dashboard 
python3-zaqar-ui
Control: found -1 vitrage-dashboard/3.0.0-1

The same error happens when installing python3-vitrage-dashboard from
experimental, so the underlying problem is likely in yet another package.

Andreas

(the affects are mostly for piuparts to find this bug even if its gets
reassigned)

Bug#983623: ibus-mozc: does not work out-of-the-box on the GNOME desktop

[YOSHINO Yoshihito]

Package: ibus-mozc
Version: 2.26.4220.100+dfsg-2
Severity: important
X-Debbugs-Cc: yy.y.ja...@gmail.com

Dear Maintainer,

On the GNOME desktop, manual set-up in GNOME Settings is required
in order to make ibus-mozc to work.

I have prepared an XDG Autostart .desktop file which should be installed to
/etc/xdg/autostart/ibus-mozc-gnome-initial-setup.desktop
to automatically set-up ibus-mozc immediately after each user's next login.

Thanks in advance,
-- 
YOSHINO Yoshihito 

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

Kernel: Linux 5.10.0-3-amd64 (SMP w/1 CPU thread)
Locale: LANG=ja_JP.UTF-8, LC_CTYPE=ja_JP.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 ibus-mozc depends on:
ii  ibus1.5.23-2
ii  libabsl20200923 0~20200923.3-2
ii  libc6   2.31-9
ii  libglib2.0-02.66.7-1
ii  libibus-1.0-5   1.5.23-2
ii  libprotobuf23   3.12.4-1
ii  libstdc++6  10.2.1-6
ii  libxcb-xfixes0  1.14-3
ii  libxcb1 1.14-3
ii  mozc-data   2.26.4220.100+dfsg-2
ii  mozc-server 2.26.4220.100+dfsg-2
ii  tegaki-zinnia-japanese  0.3-1.1

Versions of packages ibus-mozc recommends:
ii  mozc-utils-gui  2.26.4220.100+dfsg-2

ibus-mozc suggests no packages.

-- no debconf information


ibus-mozc-gnome-initial-setup.desktop
Description: Binary data

Bug#983622: fonts-baekmuk: ugly rendering of webfonts in firefox since buster update

[Roland Rosenfeld]

Package: fonts-baekmuk
Version: 2.2-13
Severity: normal

Dear Maintainer,

since the update from stretch to buster I observe that on some web
pages fonts look ugly in firefox like on https://www.checkpoint.com
(see attached screenshot withbaekmuk.png).

I observed this only on one of my machines and only with firefox, not
with chrome or chromium.
Locally installed fonts aren't a problem only web fonts and only if
they are small (scaling up the hole page in firefox or using right
mouse button "Inspect Element" and then increase font size to >=23 in
the Fonts tab solves the issue).

Comparing /etc/fonts/conf.d of the machine with the issue and a
different machine showed, me that the file that triggers the issue is
90-fonts-baekmuk.conf which disables antialias and hinting on
pixelsize <=22 for the Baekmuk* fonts.

I don't understand why this has an effect on web fonts (for example
the "DIN WXX Regular" font on the checkpoint web page), since these
fonts do not match the Baekmuk* font family name.

Maybe this is a bug in Firefox (I observed it at least in 52.9.0esr,
78.7.0esr and 86.0), that interprets the two  tags in the
 as "match any" instead of "match all" (according
https://www.freedesktop.org/software/fontconfig/fontconfig-user.html
_all_ s should be matched), but since fonts-baekmuk is the only
package on my system that triggers this issue, I report it here.

Adding 
 firefox
to at least one of the es in 90-fonts-baekmuk.conf also works
around this issue for me (I expected, that it would be needed in all
 tags, but one of them seems to be enough as a workaround... 

Greetings
Roland

-- System Information:
Debian Release: 10.8
  APT prefers stable
  APT policy: (500, 'stable'), (50, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

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

-- no debconf information


signature.asc
Description: PGP signature

Bug#983621: pyzmq FTBFS with nocheck profile: missing setuptools

[Helmut Grohne]

Source: pyzmq
Version: 20.0.0-1
Severity: important
Tags: ftbfs patch

pyzmq fails to build from source when activating the nocheck build
profile, because it fails importing the setup tools module. The
python3-setuptools dependency is annotated , but it is always
required. Please consider applying the attached patch to drop the
annotation.

Helmut
diff --minimal -Nru pyzmq-20.0.0/debian/changelog pyzmq-20.0.0/debian/changelog
--- pyzmq-20.0.0/debian/changelog   2020-11-13 20:14:26.0 +0100
+++ pyzmq-20.0.0/debian/changelog   2021-02-27 12:56:52.0 +0100
@@ -1,3 +1,11 @@
+pyzmq (20.0.0-1.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix FTBFS with nocheck profile: unconditionally depend on
+python3-setuptools. (Closes: #-1)
+
+ -- Helmut Grohne   Sat, 27 Feb 2021 12:56:52 +0100
+
 pyzmq (20.0.0-1) unstable; urgency=medium
 
   [ Ondřej Nový ]
diff --minimal -Nru pyzmq-20.0.0/debian/control pyzmq-20.0.0/debian/control
--- pyzmq-20.0.0/debian/control 2020-11-13 20:14:26.0 +0100
+++ pyzmq-20.0.0/debian/control 2021-02-27 12:56:50.0 +0100
@@ -18,7 +18,7 @@
python3-numpy ,
python3-numpy-dbg ,
python3-pytest ,
-   python3-setuptools ,
+   python3-setuptools,
python3-tornado ,
 Standards-Version: 4.5.0
 Homepage: https://www.zeromq.org/bindings:python

Bug#983597: [PATCH] Segfault in libqt5quick5.so: QQuickItemLayer::~QQuickItemLayer()

[Dmitry Shachnev]

Control: forwarded -1 https://bugreports.qt.io/browse/QTBUG-91437

Hi Dennis!

On Fri, Feb 26, 2021 at 10:48:43PM +0100, Dennis Filder wrote:
> The segfault happens
> * both with and without a preexisting configuration,
> * only if Orca is running in the same session.  Without Orca the
>   segfault does not happen.
>
> Reproducer:
> . Start Orca
> . Start linphone
> . If already configured: click "Assistant" (skip otherwise)
> . Click "Use a SIP account"
> . Enter as Username: a
> . Enter as SIP Domain: b
> . Enter as Password: c
> . Click on "Use".
>
> [...]
>
> If you decide to use the attached patch, please put the bugnumber in
> the Bug-Debian: field for me.

Thanks for your bug and for the patch. As neither you nor me are sure that
your patch is the correct fix, I decided to ask upstream before applying it.

Let's wait for response on the bug I filed, then there is still time to
get the patch included before freeze.

--
Dmitry Shachnev


signature.asc
Description: PGP signature

Bug#983346: Update gitlab to 13.7.7 (installation fails - need help)

[Pirate Praveen]

On Fri, 26 Feb 2021 14:40:46 +0530 Pirate Praveen 
 wrote:

> On Tue, 23 Feb 2021 00:47:30 +0530 Pirate Praveen
>  wrote:
>  > Installing 13.7.7 on a clean system (after purge) works, but fails
> when
>  > upgrading from 13.6.7.
>
> What I found out so far is this,
>
> /etc/gitlab/initializers/flipper.rb was obsoleted in 13.6 but we did
> not remove it and that code introduced some changes in db which is 
now

> causing the error. So I think we will have to revert the changes made
> by this initializer.
>
> And in long term, we should more actively look for obsolete
> initializers like how we check if upstream file list is changed
> upstream.

This commit makes the upgrade work.

https://salsa.debian.org/ruby-team/gitlab/-/commit/98741d55b7ed4b5eb1985981ab82e171c7d0e0c9

We still need to check obsolete initializers more proactively I think.

Bug#983620: python3-vedo: Segfault rendering example files

[Matsievskiy S.V.]

Package: python3-vedo
Version: 2020.4.2-2
Severity: important
X-Debbugs-Cc: seregaxvm.m...@gmail.com

Dear Maintainer,

The following examples from python3-vedo-examples package crush with segfault
error:
- examples/basic/align1.py
- examples/basic/align4.py
- examples/basic/align5.py
- examples/basic/mirror.py
- examples/advanced/geological_model.py
- examples/other/flag_labels.py
- examples/pyplot/covid19.py
- examples/simulations/wave_equation.py

-- System Information:
Debian Release: bullseye/sid
  APT prefers testing
  APT policy: (900, 'testing'), (500, 'stable-updates'), (500, 'stable'), (50,
'unstable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

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

Versions of packages python3-vedo depends on:
ii  python33.9.1-1
ii  python3-numpy  1:1.19.5-1
ii  python3-vtk9   9.0.1+dfsg1-8

python3-vedo recommends no packages.

Versions of packages python3-vedo suggests:
ii  python3-vedo-examples  2020.4.2-2

Bug#873149: python-argcomplete: Should set TERM while running tests

[Graham Inggs]

With bash 5.1, python-argcomplete's tests now fail if TERM is set.
Unexporting TERM allows the tests to succeed with old and new versions
of bash (tested with 4.4.18, 5.0 and 5.1).

Bug#983619: vdr-markad: fails to install: chown: invalid user: 'vdr:vdr'

[Andreas Beckmann]

Package: vdr-markad
Version: 0.1.4+git20180120-3
Severity: serious
User: debian...@lists.debian.org
Usertags: piuparts

Hi,

during a test with piuparts I noticed your package failed to install. As
per definition of the release team this makes the package too buggy for
a release, thus the severity.

>From the attached log (scroll to the bottom...):

  Setting up vdr-markad (0.1.4+git20180120-3) ...
  chown: invalid user: 'vdr:vdr'
  dpkg: error processing package vdr-markad (--configure):
   installed vdr-markad package post-installation script subprocess returned 
error exit status 1
  Processing triggers for libc-bin (2.31-9) ...
  Errors were encountered while processing:
   vdr-markad


cheers,

Andreas


vdr-markad_0.1.4+git20180120-3.log.gz
Description: application/gzip

Bug#983618: python3-zaqar-ui: causes openstack-dashboard to fail upon installation

[Andreas Beckmann]

Package: python3-zaqar-ui
Version: 9.0.0~rc1-1
Severity: serious
User: debian...@lists.debian.org
Usertags: piuparts
Control: affects -1 + src:horizon src:zaqar-ui

Hi,

during a test with piuparts I noticed your package failed to install. As
per definition of the release team this makes the package too buggy for
a release, thus the severity.

From the attached log (scroll to the bottom...):

  Setting up openstack-dashboard (3:18.6.1-1) ...
  Warning: Could not import Horizon dependencies. This is normal during 
installation.
  RemovedInDjango40Warning: django.utils.translation.ugettext_lazy() is 
deprecated in favor of 
django.utils.translation.gettext_lazy().RemovedInDjango40Warning: 
django.utils.translation.ugettext_lazy() is deprecated in favor of 
django.utils.translation.gettext_lazy().RemovedInDjango40Warning: 
django.utils.translation.ugettext_lazy() is deprecated in favor of 
django.utils.translation.gettext_lazy().RemovedInDjango40Warning: 
django.utils.translation.ugettext_lazy() is deprecated in favor of 
django.utils.translation.gettext_lazy().RemovedInDjango40Warning: 
django.utils.translation.ugettext_lazy() is deprecated in favor of 
django.utils.translation.gettext_lazy().RemovedInDjango40Warning: 
django.utils.translation.ugettext_lazy() is deprecated in favor of 
django.utils.translation.gettext_lazy().RemovedInDjango40Warning: 
django.utils.translation.ugettext_lazy() is deprecated in favor of 
django.utils.translation.gettext_lazy().RemovedInDjango40Warning: 
django.utils.translation.ugettext_lazy() is deprecated in favor of 
django.utils.translation.gettext_lazy().RemovedInDjango40Warning: 
django.utils.translation.ugettext_lazy() is deprecated in favor of 
django.utils.translation.gettext_lazy().RemovedInDjango40Warning: 
django.utils.translation.ugettext_lazy() is deprecated in favor of 
django.utils.translation.gettext_lazy().RemovedInDjango40Warning: 
django.utils.translation.ugettext_lazy() is deprecated in favor of 
django.utils.translation.gettext_lazy().RemovedInDjango40Warning: 
django.utils.translation.ugettext_lazy() is deprecated in favor of 
django.utils.translation.gettext_lazy().RemovedInDjango40Warning: 
django.utils.translation.ugettext_lazy() is deprecated in favor of 
django.utils.translation.gettext_lazy().Traceback (most recent call last):
File "/usr/share/openstack-dashboard/manage.py", line 23, in 
  execute_from_command_line(sys.argv)
File "/usr/lib/python3/dist-packages/django/core/management/__init__.py", 
line 419, in execute_from_command_line
  utility.execute()
File "/usr/lib/python3/dist-packages/django/core/management/__init__.py", 
line 395, in execute
  django.setup()
File "/usr/lib/python3/dist-packages/django/__init__.py", line 24, in setup
  apps.populate(settings.INSTALLED_APPS)
File "/usr/lib/python3/dist-packages/django/apps/registry.py", line 91, in 
populate
  app_config = AppConfig.create(entry)
File "/usr/lib/python3/dist-packages/django/apps/config.py", line 224, in 
create
  import_module(entry)
File "/usr/lib/python3.9/importlib/__init__.py", line 127, in import_module
  return _bootstrap._gcd_import(name[level:], package, level)
File "", line 1030, in _gcd_import
File "", line 1007, in _find_and_load
File "", line 986, in _find_and_load_unlocked
File "", line 680, in _load_unlocked
File "", line 790, in exec_module
File "", line 228, in _call_with_frames_removed
File "/usr/lib/python3/dist-packages/django_pyscss/__init__.py", line 1, in 

  from .compiler import DjangoScssCompiler  # NOQA
File "/usr/lib/python3/dist-packages/django_pyscss/compiler.py", line 6, in 

  from django.utils.six.moves import StringIO
  ModuleNotFoundError: No module named 'django.utils.six'
  dpkg: error processing package openstack-dashboard (--configure):
   installed openstack-dashboard package post-installation script subprocess 
returned error exit status 1
  dpkg: dependency problems prevent configuration of python3-zaqar-ui:
   python3-zaqar-ui depends on openstack-dashboard (>= 3:17.1.0); however:
Package openstack-dashboard is not configured yet.
  
  dpkg: error processing package python3-zaqar-ui (--configure):
   dependency problems - leaving unconfigured
  Processing triggers for ca-certificates (20210119) ...
  Updating certificates in /etc/ssl/certs...
  0 added, 0 removed; done.
  Running hooks in /etc/ca-certificates/update.d...
  done.
  Errors were encountered while processing:
   openstack-dashboard
   python3-zaqar-ui


cheers,

Andreas


python3-zaqar-ui_9.0.0~rc1-1.log.gz
Description: application/gzip

Bug#983617: gitaly: fails to install: Could not find gem 'grpc (~> 1.30, >= 1.30.2)'

[Andreas Beckmann]

Package: gitaly
Version: 13.7.5+dfsg-3
Severity: serious
User: debian...@lists.debian.org
Usertags: piuparts

Hi,

during a test with piuparts I noticed your package failed to install. As
per definition of the release team this makes the package too buggy for
a release, thus the severity.

>From the attached log (scroll to the bottom...):

  Setting up gitaly (13.7.5+dfsg-3) ...
  [ESC][31mCould not find gem 'grpc (~> 1.30, >= 1.30.2)' in any of the gem 
sources listed
  in your Gemfile.[ESC][0m
  dpkg: error processing package gitaly (--configure):
   installed gitaly package post-installation script subprocess returned error 
exit status 7
  Processing triggers for ca-certificates (20210119) ...
  Updating certificates in /etc/ssl/certs...
  0 added, 0 removed; done.
  Running hooks in /etc/ca-certificates/update.d...
  done.
  Errors were encountered while processing:
   gitaly


cheers,

Andreas


gitaly_13.7.5+dfsg-3.log.gz
Description: application/gzip

Bug#983616: backintime-qt: changing diff command crashes application

[Tobias Leichtfried]

Package: backintime-qt
Version: 1.2.1-2
Severity: normal
X-Debbugs-Cc: tleichtfried2...@gmail.com

When I try to change the diff command in the "Diff Options" Dialog of the
"Snapshots" Dialog the program crashes as soon as I press "OK", even if no
options have been changed.

When started via the terminal following message is printed:

Traceback (most recent call last):
  File "/usr/share/backintime/qt/snapshotsdialog.py", line 76, in accept
diffCmd = str(self.editCmd.text().toUtf8())
AttributeError: 'str' object has no attribute 'toUtf8'
Aborted

It seems as if the value of text() is handled as if it were a QString, while it
is a normal Python String.

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

Kernel: Linux 5.10.0-3-amd64 (SMP w/16 CPU threads)
Kernel taint flags: TAINT_WARN
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 backintime-qt depends on:
ii  backintime-common1.2.1-2
ii  libnotify-bin0.7.9-3
ii  policykit-1  0.105-30
ii  python3  3.9.1-1
ii  python3-dbus.mainloop.pyqt5  5.15.2+dfsg-3
ii  python3-pyqt55.15.2+dfsg-3
ii  x11-utils7.7+5

Versions of packages backintime-qt recommends:
ii  python3-secretstorage  3.3.1-1

Versions of packages backintime-qt suggests:
ii  meld  3.20.2-2

Bug#983615: enhanceio-dkms: module FTBFS for Linux 5.10: unknown type name 'make_request_fn'

[Andreas Beckmann]

Package: enhanceio-dkms
Version: 0+git20190417.5815670-1
Severity: serious
User: debian...@lists.debian.org
Usertags: piuparts

Hi,

enhanceio-dkms fails to build a module for Linux 5.10:

DKMS make.log for enhanceio-0+git20190417.5815670 for kernel 5.10.0-3-amd64 
(x86_64)
Sat Feb 27 11:51:08 CET 2021
KERNEL_TREE=/lib/modules/5.10.0-3-amd64/build
EXTRA_CFLAGS=-I/lib/modules/5.10.0-3-amd64/build/drivers/md -I./ 
-DCOMMIT_REV="\"\"" -I/lib/modules/5.10.0-3-amd64/build/include/ 
-I/lib/modules/5.10.0-3-amd64/build/include/linux  -g -O2 
-ffile-prefix-map=/var/lib/dkms/enhanceio/0+git20190417.5815670/build=. 
-Wformat -Werror=format-security
make -C /lib/modules/5.10.0-3-amd64/build 
M=/var/lib/dkms/enhanceio/0+git20190417.5815670/build modules V=1
make[1]: Entering directory '/usr/src/linux-headers-5.10.0-3-amd64'
make -C /usr/src/linux-headers-5.10.0-3-amd64 -f 
/usr/src/linux-headers-5.10.0-3-common/Makefile modules
test -e include/generated/autoconf.h -a -e include/config/auto.conf || (
\
echo >&2;   \
echo >&2 "  ERROR: Kernel configuration is invalid.";   \
echo >&2 " include/generated/autoconf.h or include/config/auto.conf are 
missing.";\
echo >&2 " Run 'make oldconfig && make prepare' on kernel src to fix 
it.";  \
echo >&2 ;  \
/bin/false)
make -f /usr/src/linux-headers-5.10.0-3-common/scripts/Makefile.build 
obj=/var/lib/dkms/enhanceio/0+git20190417.5815670/build \
single-build= \
need-builtin=1 need-modorder=1
KERNEL_TREE=/lib/modules/5.10.0-3-amd64/build
EXTRA_CFLAGS=-I/lib/modules/5.10.0-3-amd64/build/drivers/md -I./ 
-DCOMMIT_REV="\"\"" -I/lib/modules/5.10.0-3-amd64/build/include/ 
-I/lib/modules/5.10.0-3-amd64/build/include/linux  -g -O2 
-ffile-prefix-map=/usr/src/linux-headers-5.10.0-3-amd64=. -Wformat 
-Werror=format-security
   gcc-10 
-Wp,-MMD,/var/lib/dkms/enhanceio/0+git20190417.5815670/build/.eio_conf.o.d 
-nostdinc -isystem /usr/lib/gcc/x86_64-linux-gnu/10/include 
-I/usr/src/linux-headers-5.10.0-3-common/arch/x86/include 
-I./arch/x86/include/generated -I/usr/src/linux-headers-5.10.0-3-common/include 
-I./include -I/usr/src/linux-headers-5.10.0-3-common/arch/x86/include/uapi 
-I./arch/x86/include/generated/uapi 
-I/usr/src/linux-headers-5.10.0-3-common/include/uapi 
-I./include/generated/uapi -include 
/usr/src/linux-headers-5.10.0-3-common/include/linux/kconfig.h -include 
/usr/src/linux-headers-5.10.0-3-common/include/linux/compiler_types.h 
-D__KERNEL__ -fmacro-prefix-map=/usr/src/linux-headers-5.10.0-3-common/= -Wall 
-Wundef -Werror=strict-prototypes -Wno-trigraphs -fno-strict-aliasing 
-fno-common -fshort-wchar -fno-PIE -Werror=implicit-function-declaration 
-Werror=implicit-int -Werror=return-type -Wno-format-security -std=gnu89 
-mno-sse -mno-mmx -mno-sse2 -mno-3dnow -mno-avx -m64 -falign-jumps=1 
-falign-loops=1 -mno-80387 -mno-fp-ret-in-387 -mpreferred-stack-boundary=3 
-mskip-rax-setup -mtune=generic -mno-red-zone -mcmodel=kernel 
-DCONFIG_X86_X32_ABI -Wno-sign-compare -fno-asynchronous-unwind-tables 
-mindirect-branch=thunk-extern -mindirect-branch-register -fno-jump-tables 
-fno-delete-null-pointer-checks -Wno-frame-address -Wno-format-truncation 
-Wno-format-overflow -Wno-address-of-packed-member -O2 
-fno-allow-store-data-races -Wframe-larger-than=2048 -fstack-protector-strong 
-Wno-unused-but-set-variable -Wimplicit-fallthrough -Wno-unused-const-variable 
-g -pg -mrecord-mcount -mfentry -DCC_USING_FENTRY -Wdeclaration-after-statement 
-Wvla -Wno-pointer-sign -Wno-stringop-truncation -Wno-zero-length-bounds 
-Wno-array-bounds -Wno-stringop-overflow -Wno-restrict -Wno-maybe-uninitialized 
-fno-strict-overflow -fno-stack-check -fconserve-stack -Werror=date-time 
-Werror=incompatible-pointer-types -Werror=designated-init -fcf-protection=none 
-Wno-packed-not-aligned -I/lib/modules/5.10.0-3-amd64/build/drivers/md -I./ 
-DCOMMIT_REV="\"\"" -I/lib/modules/5.10.0-3-amd64/build/include/ 
-I/lib/modules/5.10.0-3-amd64/build/include/linux -g -O2 
-ffile-prefix-map=/usr/src/linux-headers-5.10.0-3-amd64=. -Wformat 
-Werror=format-security  -DMODULE  -DKBUILD_BASENAME='"eio_conf"' 
-DKBUILD_MODNAME='"enhanceio"' -c -o 
/var/lib/dkms/enhanceio/0+git20190417.5815670/build/eio_conf.o 
/var/lib/dkms/enhanceio/0+git20190417.5815670/build/eio_conf.c
In file included from 
/var/lib/dkms/enhanceio/0+git20190417.5815670/build/eio_conf.c:39:
/var/lib/dkms/enhanceio/0+git20190417.5815670/build/eio.h:707:2: error: unknown 
type name 'make_request_fn'
  707 |  make_request_fn *origmfn;
  |  ^~~
make[3]: *** 
[/usr/src/linux-headers-5.10.0-3-common/scripts/Makefile.build:284: 
/var/lib/dkms/enhanceio/0+git20190417.5815670/build/eio_conf.o] Error 1
make[2]: *** [/usr/src/linux-headers-5.10.0-3-common/Makefile:1817: 
/var/lib/dkms/enhanceio/0+git20190417.5815670/build] Error 2
make[1]: *** [/usr/src/linux-headers-5.10.0-3-common/Makefil

Bug#982275: debianutils: add-shell depends on non-essential package

[Sven Joachim]

Control: tags -1 - patch

On 2021-02-07 21:51 -0500, Michael Gilbert wrote:

> debianutil's add-shell script uses awk, but awk is not an
> Essential:yes package.  For systems where awk is not yet installed
> (chroots), installation of dash will currently fail since it's
> postinst calls add-shell from debianutils.
>
> A simple fix seems possible, just change add-shell to use cat, which
> is in coreutils (Essential:yes).  Proposed update attached.
>
> Best wishes,
> Mike
>
> --- debianutils-4.11.2/add-shell  2020-05-22 20:00:40.0 -0400
> +++ debianutils-4.11.3/add-shell  2021-02-07 21:47:27.0 -0500
> @@ -17,7 +17,7 @@
>  }
>  trap cleanup EXIT
>
> -if ! awk '{print}' "$file" > "$tmpfile"
> +if ! cat "$file" > "$tmpfile"
>  then
>  cat 1>&2 <  Either another instance of $0 is running, or it was previously interrupted.

This would reopen bug #698874, I don't think the maintainer wants that.
A possible solution which takes that bug into account might be to use
sed instead:

--8<---cut here---start->8---
diff --git a/add-shell b/add-shell
index abce1c1..17967f5 100755
--- a/add-shell
+++ b/add-shell
@@ -17,7 +17,7 @@ cleanup() {
 }
 trap cleanup EXIT

-if ! awk '{print}' "$file" > "$tmpfile"
+if ! sed '$a\' $file > $tmpfile
 then
 cat 1>&2 <8---

However while this works with GNU sed, busybox sed adds an unwanted
extra empty line, and I am not sure if POSIX has anything to say about
what is supposed to happen if you append nothing at the end of a file.

See also #796848, #812784 and
https://unix.stackexchange.com/questions/31947/how-to-add-a-newline-to-the-end-of-a-file.

Cheers,
   Sven

Bug#983614: RM: mame [armel mipsel] -- RoQA; no longer builds on armel and mipsel

[Adrian Bunk]

Package: ftp.debian.org
Severity: normal
Control: block -1 by 983613

See #983507 for background.

Bug#983562: installation-reports: rtw_8822ce non-free firmware not detected with weekly build of debian installer

[Cyril Brulebois]

Hallo Christian,

Christian Britz  (2021-02-26):
> Package: installation-reports
> Severity: normal
> Tags: d-i
> X-Debbugs-Cc: cbr...@t-online.de
> 
> Dear Maintainer,
> 
> I booted the latest unofficial weekly build of Debian installer
> including non-free firmware, because I needed to use the rescue mode.
> Unfortunately the non-free firmware for Realtek rtw_8822ce WIFI was
> not detected, so I had to use USB tethering. Once Debian is
> installed, the WiFi works without problems.

Any chance you could attach /var/log/installer/syslog (compressed)
through reply-all, please?


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


signature.asc
Description: PGP signature

Bug#983613: RM: gnome-video-arcade [armel mipsel] -- RoQA; build dependency mame no longer available on armel and mipsel

[Adrian Bunk]

Package: ftp.debian.org
Severity: normal

See #983507 for background.

Bug#983612: mark python3-texttable Multi-Arch: foreign

[Helmut Grohne]

Package: python3-texttable
Version: 1.6.3-1
Tags: patch
User: debian-cr...@lists.debian.org
Usertags: cross-satisfiability
Control: affects -1 + src:calibre src:py7zr src:python-igraph

The affected packages cannot satisfy their cross Build-Depends, because
their transitive dependency on python3-texttable is not satisfiable. In
general, Architecture: all packages can never satisfy cross
Build-Depends unless marked Multi-Arch: foreign or annotated :native. In
this case, the foreign marking is reasonable, because python3-texttable
is a pure Python module whose maintainer scripts perform byte
compilation with an :any-annotated Python interpreter. Please consider
applying the attached patch.

Helmut
diff --minimal -Nru texttable-1.6.3/debian/changelog 
texttable-1.6.3/debian/changelog
--- texttable-1.6.3/debian/changelog2020-10-17 03:03:26.0 +0200
+++ texttable-1.6.3/debian/changelog2021-02-27 11:23:35.0 +0100
@@ -1,3 +1,10 @@
+texttable (1.6.3-1.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Mark python3-texttable Multi-Arch: foreign. (Closes: #-1)
+
+ -- Helmut Grohne   Sat, 27 Feb 2021 11:23:35 +0100
+
 texttable (1.6.3-1) unstable; urgency=medium
 
   [ Debian Janitor ]
diff --minimal -Nru texttable-1.6.3/debian/control 
texttable-1.6.3/debian/control
--- texttable-1.6.3/debian/control  2020-10-17 03:03:20.0 +0200
+++ texttable-1.6.3/debian/control  2021-02-27 11:23:33.0 +0100
@@ -18,6 +18,7 @@
 
 Package: python3-texttable
 Architecture: all
+Multi-Arch: foreign
 Depends: ${misc:Depends}, ${python3:Depends}
 Description: Module for creating simple ASCII tables — python3
  texttable is a module to generate a formatted text table, using ASCII

Bug#983611: RM: mit-scheme [i386] -- RoQA; package no longer builds on 32bit

[Adrian Bunk]

Package: ftp.debian.org
Severity: normal

See #982791 for background.

Bug#981825: debian/buster64 no longer works correctly with vbguest plugin

[Lucas Nussbaum]

Control: forcemerge 982460 -1

Hi,

This is the same issue as #982460

Lucas

On 04/02/21 at 12:26 +0100, Radoslav Bodó wrote:
> Package: cloud.debian.org
> 
> 
> Hello,
> 
> vagrant box debian/buster64 10.4.0 no longer works as expected most
> likely due to repository changes where kernel headers are no longer present
> 
> Localy I've resolved the issue by updating base box image with the new
> kernel, but I guess it might be useful either to checkout the repository
> contents or repack the box with the new/current Buster kernel.
> 
> 
> Thanks for any response
> bodik
> 
> 
> 
> 
> ==> xxx: Machine booted and ready!
> [xxx] A Virtualbox Guest Additions installation was found but no tools
> to rebuild or start them.
> Reading package lists...
> Building dependency tree...
> Reading state information...
> The following additional packages will be installed:
>   binutils binutils-common binutils-x86-64-linux-gnu build-essential cpp
> cpp-8
>   dirmngr dpkg-dev fakeroot g++ g++-8 gcc gcc-8 gnupg gnupg-l10n gnupg-utils
>   gpg gpg-agent gpg-wks-client gpg-wks-server gpgconf gpgsm
>   libalgorithm-diff-perl libalgorithm-diff-xs-perl libalgorithm-merge-perl
>   libasan5 libatomic1 libbinutils libc-dev-bin libc6-dev libcc1-0
> libdpkg-perl
>   libfakeroot libfile-fcntllock-perl libgcc-8-dev libgomp1 libisl19 libitm1
>   libksba8 liblsan0 libmpc3 libmpfr6 libmpx2 libnpth0 libquadmath0
>   libstdc++-8-dev libtsan0 libubsan1 linux-compiler-gcc-8-x86
>   linux-headers-4.19.0-9-common linux-headers-amd64 linux-kbuild-4.19
>   linux-libc-dev make manpages-dev patch
> Suggested packages:
>   binutils-doc cpp-doc gcc-8-locales dbus-user-session pinentry-gnome3 tor
>   python3-apport menu debian-keyring g++-multilib g++-8-multilib gcc-8-doc
>   libstdc++6-8-dbg gcc-multilib autoconf automake libtool flex bison gdb
>   gcc-doc gcc-8-multilib libgcc1-dbg libgomp1-dbg libitm1-dbg libatomic1-dbg
>   libasan5-dbg liblsan0-dbg libtsan0-dbg libubsan1-dbg libmpx2-dbg
>   libquadmath0-dbg parcimonie xloadimage scdaemon glibc-doc git bzr
>   libstdc++-8-doc make-doc ed diffutils-doc
> The following NEW packages will be installed:
>   binutils binutils-common binutils-x86-64-linux-gnu build-essential cpp
> cpp-8
>   dirmngr dkms dpkg-dev fakeroot g++ g++-8 gcc gcc-8 gnupg gnupg-l10n
>   gnupg-utils gpg gpg-agent gpg-wks-client gpg-wks-server gpgconf gpgsm
>   libalgorithm-diff-perl libalgorithm-diff-xs-perl libalgorithm-merge-perl
>   libasan5 libatomic1 libbinutils libc-dev-bin libc6-dev libcc1-0
> libdpkg-perl
>   libfakeroot libfile-fcntllock-perl libgcc-8-dev libgomp1 libisl19 libitm1
>   libksba8 liblsan0 libmpc3 libmpfr6 libmpx2 libnpth0 libquadmath0
>   libstdc++-8-dev libtsan0 libubsan1 linux-compiler-gcc-8-x86
>   linux-headers-4.19.0-9-amd64 linux-headers-4.19.0-9-common
>   linux-headers-amd64 linux-kbuild-4.19 linux-libc-dev make manpages-dev
> patch
> 0 upgraded, 58 newly installed, 0 to remove and 0 not upgraded.
> Need to get 66.9 MB of archives.
> After this operation, 258 MB of additional disk space will be used.
> Get:1 http://deb.debian.org/debian buster/main amd64 binutils-common
> amd64 2.31.1-16 [2,073 kB]
> Get:2 http://deb.debian.org/debian buster/main amd64 libbinutils amd64
> 2.31.1-16 [478 kB]
> Get:3 http://deb.debian.org/debian buster/main amd64
> binutils-x86-64-linux-gnu amd64 2.31.1-16 [1,823 kB]
> Get:4 http://deb.debian.org/debian buster/main amd64 binutils amd64
> 2.31.1-16 [56.8 kB]
> Get:5 http://deb.debian.org/debian buster/main amd64 libc-dev-bin amd64
> 2.28-10 [275 kB]
> Err:6 http://deb.debian.org/debian buster/main amd64 linux-libc-dev
> amd64 4.19.118-2
>   404  Not Found [IP: 199.232.18.132 80]
> Get:7 http://deb.debian.org/debian buster/main amd64 libc6-dev amd64
> 2.28-10 [2,691 kB]
> Get:8 http://deb.debian.org/debian buster/main amd64 libisl19 amd64
> 0.20-2 [587 kB]
> Get:9 http://deb.debian.org/debian buster/main amd64 libmpfr6 amd64
> 4.0.2-1 [775 kB]
> Get:10 http://deb.debian.org/debian buster/main amd64 libmpc3 amd64
> 1.1.0-1 [41.3 kB]
> Get:11 http://deb.debian.org/debian buster/main amd64 cpp-8 amd64
> 8.3.0-6 [8,914 kB]
> Get:12 http://deb.debian.org/debian buster/main amd64 cpp amd64
> 4:8.3.0-1 [19.4 kB]
> Get:13 http://deb.debian.org/debian buster/main amd64 libcc1-0 amd64
> 8.3.0-6 [46.6 kB]
> Get:14 http://deb.debian.org/debian buster/main amd64 libgomp1 amd64
> 8.3.0-6 [75.8 kB]
> Get:15 http://deb.debian.org/debian buster/main amd64 libitm1 amd64
> 8.3.0-6 [27.7 kB]
> Get:16 http://deb.debian.org/debian buster/main amd64 libatomic1 amd64
> 8.3.0-6 [9,032 B]
> Get:17 http://deb.debian.org/debian buster/main amd64 libasan5 amd64
> 8.3.0-6 [362 kB]
> Get:18 http://deb.debian.org/debian buster/main amd64 liblsan0 amd64
> 8.3.0-6 [131 kB]
> Get:19 http://deb.debian.org/debian buster/main amd64 libtsan0 amd64
> 8.3.0-6 [283 kB]
> Get:20 http://deb.debian.org/debian buster/main amd64 libubsan1 amd64
> 8.3.0-6 [120 kB]
> Get:21 http://deb.debian.org/debian buster/main am

Bug#982460: cloud.debian.org: Vagrant up error: Unable to locate package linux-headers-4.9.0-12-amd64

[Lucas Nussbaum]

Control: retitle -1 cloud.debian.org: Vagrant images: vbguest plugin fails to 
find linux-headers-* package
Control: tags -1 + wontfix
Control: severity -1 wishlist

Retitling and marking as wontfix, since we do not support the use of the
vbguest plugin.

Lucas

Bug#983435: Regarding the backup/restore function

[bugsgrid+deb]

Ah, my router doesn't have udev!
In osdep/linux/hostdisk.c:sysfs_partition_path(), calling udevadm
through grub_util_exec_pipe() will fail and fall through to
*unpatched* exit().
Sounds plausible?

If my guess is right, perhaps sid is affected too.
Sorry I don't have any testbed, if anyone could confirm please adjust
bugtitle and severity accordingly.  I'm not sure about appropriate
value.

... I thought a debian installation without udev is still not illegal
nor broken ...
Thanks,

Bug#983610: zint: CVE-2021-27799

[Salvatore Bonaccorso]

Source: zint
Version: 2.9.1-1
Severity: serious
Tags: security upstream
Forwarded: https://sourceforge.net/p/zint/tickets/218/
X-Debbugs-Cc: car...@debian.org, Debian Security Team 

Hi,

The following vulnerability was published for zint.

CVE-2021-27799[0]:
| ean_leading_zeroes in backend/upcean.c in Zint Barcode Generator
| 2.19.1 has a stack-based buffer overflow that is reachable from the C
| API through an application that includes the Zint Barcode Generator
| library code.

Reasoning for making it RC: it is in the library part and ideally this
should go into the bullseye release fixed.

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-27799
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-27799
[1] https://sourceforge.net/p/zint/tickets/218/
[2] 
https://sourceforge.net/p/zint/code/ci/7f8c8114f31c09a986597e0ba63a49f96150368a/

Please adjust the affected versions in the BTS as needed.

Regards,
Salvatore

Bug#983609: mark golang-golang-x-term-dev Multi-Arch: foreign

[Helmut Grohne]

Package: golang-golang-x-term-dev
Version: 0.0~git20201210.2321bbc-1
Tags: patch
User: debian-cr...@lists.debian.org
Usertags: cross-satisfiability
Control: affects -1 + src:acbuild src:acmetool src:aerc src:age 
src:alertmanager-irc-relay src:aptly src:badger src:balboa src:burrow 
src:cfrpki src:chasquid src:cloudsql-proxy src:consul src:consulfs 
src:containerd src:coyim src:crowdsec src:debiman src:deck src:delve 
src:dh-make-golang src:dnscrypt-proxy src:dnss src:docker-registry 
src:docker.io src:etcd src:fever src:flannel src:fscrypt src:fzf src:g10k 
src:garagemq src:gdu src:git-lfs src:gitaly src:gitbatch 
src:gitlab-ci-multi-runner src:gitlab-shell src:gitlab-workhorse 
src:go-cve-dictionary src:go-exploitdb src:gobgp src:gobuster src:gocryptfs 
src:goiardi src:gokey src:golang-github-anacrolix-dms 
src:golang-github-anacrolix-missinggo src:golang-github-appc-docker2aci 
src:golang-github-canonical-go-dqlite src:golang-github-cheekybits-genny 
src:golang-github-cloudflare-cfssl src:golang-github-cloudflare-redoctober 
src:golang-github-containers-buildah src:golang-github-coreos-discovery-etcd-io 
src:golang-github-dnstap-golang-dnstap src:golang-github-francoispqt-gojay 
src:golang-github-golang-mock src:golang-github-google-wire 
src:golang-github-hashicorp-serf src:golang-github-jouyouyun-hardware 
src:golang-github-mmcloughlin-avo src:golang-github-openshift-imagebuilder 
src:golang-github-rubenv-sql-migrate src:golang-github-spf13-cobra 
src:golang-github-sylabs-sif src:golang-github-tinylib-msgp 
src:golang-github-ugorji-go-codec src:golang-github-xenolf-lego 
src:golang-github-xordataexchange-crypt src:golang-golang-x-tools 
src:golang-pault-go-ykpiv src:golang-v2ray-core src:golint src:gopass src:gortr 
src:gost src:gotestsum src:goval-dictionary src:govendor src:hcloud-cli src:hub 
src:hugo src:influxdb src:kcptun src:libpod src:mender-cli src:mender-client 
src:micro src:minica src:mockery src:mongo-tools src:nomad src:nomad-driver-lxc 
src:nomad-driver-podman src:notary src:obfs4proxy src:packer src:pebble src:pk4 
src:pluginhook src:prometheus src:prometheus-alertmanager 
src:prometheus-bind-exporter src:prometheus-blackbox-exporter 
src:prometheus-hacluster-exporter src:prometheus-mysqld-exporter 
src:prometheus-node-exporter src:prometheus-pushgateway 
src:prometheus-sql-exporter src:ratt src:rawdns src:rclone src:reposurgeon 
src:restic src:rkt src:seqkit src:shadowsocks-v2ray-plugin src:sia 
src:singularity-container src:skopeo src:slinkwatch src:snapd src:sshesame 
src:syncthing src:termshark src:tty-share src:umoci src:vip-manager src:vuls 
src:winrmcp

The affected packages cannot satisfy their cross Build-Depends, because
their transitive dependency on golang-golang-x-term-dev cannot be
satisfied. In general, Architecture: all packages can never satisfy
cross Build-Depends unless marked Multi-Arch: foreign or annotated
:native. In this case, the foreign marking is reasonable as
golang-golang-x-term-dev is a pure go library entirely lacking
maintainer scripts and all of its dependencies are already marked
Multi-Arch: foreign. Please consider applying the attached patch.

Helmut
diff --minimal -Nru 
golang-golang-x-term-0.0~git20201210.2321bbc/debian/changelog 
golang-golang-x-term-0.0~git20201210.2321bbc/debian/changelog
--- golang-golang-x-term-0.0~git20201210.2321bbc/debian/changelog   
2020-12-22 15:49:46.0 +0100
+++ golang-golang-x-term-0.0~git20201210.2321bbc/debian/changelog   
2021-02-27 06:53:46.0 +0100
@@ -1,3 +1,10 @@
+golang-golang-x-term (0.0~git20201210.2321bbc-1.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Mark golang-golang-x-term-dev Multi-Arch: foreign. (Closes: #-1)
+
+ -- Helmut Grohne   Sat, 27 Feb 2021 06:53:46 +0100
+
 golang-golang-x-term (0.0~git20201210.2321bbc-1) unstable; urgency=medium
 
   * Team upload.
diff --minimal -Nru golang-golang-x-term-0.0~git20201210.2321bbc/debian/control 
golang-golang-x-term-0.0~git20201210.2321bbc/debian/control
--- golang-golang-x-term-0.0~git20201210.2321bbc/debian/control 2020-12-22 
15:49:46.0 +0100
+++ golang-golang-x-term-0.0~git20201210.2321bbc/debian/control 2021-02-27 
06:53:45.0 +0100
@@ -17,6 +17,7 @@
 
 Package: golang-golang-x-term-dev
 Architecture: all
+Multi-Arch: foreign
 Depends: golang-golang-x-sys-dev,
  ${misc:Depends}
 Description: Go terminal and console support (library)

Bug#966416: Bug#973714: Depends on argyll which is going away

[Adrian Bunk]

Control: retitle 789557 O: argyll -- Color Management System, calibrator and 
profiler
Control: close -1

On Fri, Nov 06, 2020 at 09:48:41AM +0100, Christian Marillat wrote:
>...
> Jörg why a RoM ? Why to not simply orphan this package ? Others people
> are still using it.

I'm going ahead and doing this.

It is the sane action for problems between an upstream and
a Debian maintainer (no matter who might be considered at fault).

> Chirstian

cu
Adrian

Bug#983608: command-not-found: unable to open database

[Bigzloi]

Package: command-not-found
Version: 20.10.1-1
Severity: important
Tags: upstream
X-Debbugs-Cc: oleg.ivanc...@ukendtland.net

Dear Maintainer,

*** Reporter, please consider answering these questions, where appropriate ***

   * What led up to the situation?
   * What exactly did you do (or not do) that was effective (or
 ineffective)?
   * What was the outcome of this action?
   * What outcome did you expect instead?

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


-- System Information:
Distributor ID: Kali
Description:Kali GNU/Linux Rolling
Release:2021.1
Codename:   kali-rolling
Architecture: x86_64

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

Versions of packages command-not-found depends on:
ii  apt-file 3.2.2
ii  lsb-release  11.1.0
ii  python3  3.9.1-1
ii  python3-apt  2.1.7

command-not-found recommends no packages.

Versions of packages command-not-found suggests:
pn  snapd  

Bug#983607: php-imagick: autopkgtest regression

[Adrian Bunk]

Source: php-imagick
Version: 3.4.4+php8.0+3.4.4-2+deb11u1
Severity: serious

https://ci.debian.net/data/autopkgtest/testing/amd64/p/php-imagick/10726614/log.gz

...
There was 1 error:

1) 
/tmp/autopkgtest-lxc.mksgwt31/downtmp/build.KlY/src/imagick-3.4.4/tests/bug_72226.phpt
PHPUnit\Runner\Exception: No PHPT expectation found in 
/usr/share/php/PHPUnit/Runner/PhptTestCase.php:375
Stack trace:
#0 /usr/share/php/PHPUnit/Runner/PhptTestCase.php(203): 
PHPUnit\Runner\PhptTestCase->assertPhptExpectation()
#1 /usr/share/php/PHPUnit/Framework/TestSuite.php(677): 
PHPUnit\Runner\PhptTestCase->run()
#2 /usr/share/php/PHPUnit/TextUI/TestRunner.php(667): 
PHPUnit\Framework\TestSuite->run()
#3 /usr/share/php/PHPUnit/TextUI/Command.php(142): 
PHPUnit\TextUI\TestRunner->run()
#4 /usr/share/php/PHPUnit/TextUI/Command.php(95): PHPUnit\TextUI\Command->run()
#5 /usr/bin/phpunit(42): PHPUnit\TextUI\Command::main()
#6 {main}

There were 3 failures:

1) 
/tmp/autopkgtest-lxc.mksgwt31/downtmp/build.KlY/src/imagick-3.4.4/tests/281_ini_settings_default.phpt
Failed asserting that string matches format description.
--- Expected
+++ Actual
@@ @@
+imagick.shutdown_sleep_count is not set to 10 but instead false
 Complete

/tmp/autopkgtest-lxc.mksgwt31/downtmp/build.KlY/src/imagick-3.4.4/tests/281_ini_settings_default.phpt:1

2) 
/tmp/autopkgtest-lxc.mksgwt31/downtmp/build.KlY/src/imagick-3.4.4/tests/284_ini_settings_set_truthy_number.phpt
Failed asserting that string matches format description.
--- Expected
+++ Actual
@@ @@
+imagick.shutdown_sleep_count is not set to 10 but instead 0
+imagick.set_single_thread setting is not true but instead false
 Complete

/tmp/autopkgtest-lxc.mksgwt31/downtmp/build.KlY/src/imagick-3.4.4/tests/284_ini_settings_set_truthy_number.phpt:1

3) 
/tmp/autopkgtest-lxc.mksgwt31/downtmp/build.KlY/src/imagick-3.4.4/tests/285_ini_settings_set_truthy_string.phpt
Failed asserting that string matches format description.
--- Expected
+++ Actual
@@ @@
+imagick.shutdown_sleep_count is not set to 1 but instead 0
+imagick.set_single_thread setting is not true but instead false
 Complete

/tmp/autopkgtest-lxc.mksgwt31/downtmp/build.KlY/src/imagick-3.4.4/tests/285_ini_settings_set_truthy_string.phpt:1

--

There was 1 incomplete test:

1) 
/tmp/autopkgtest-lxc.mksgwt31/downtmp/build.KlY/src/imagick-3.4.4/tests/268_ImagickDraw_getDensity_basic.phpt
XFAIL section but test passes
...
Tests: 281, Assertions: 281, Errors: 1, Failures: 3, Skipped: 23, Incomplete: 1.
autopkgtest [02:12:56]: test command1: ---]
autopkgtest [02:12:56]: test command1:  - - - - - - - - - - results - - - - - - 
- - - -
command1 FAIL non-zero exit status 2