Bug#986224: buster-pu: package plinth/19.1+deb10u1

2021-03-31 Thread James Valleroy
Package: release.debian.org
Severity: normal
Tags: buster
User: release.debian@packages.debian.org
Usertags: pu
X-Debbugs-Cc: jvalle...@mailbox.org

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

[ Reason ]

A security issue was found and reported to the security team:
https://security-tracker.debian.org/tracker/TEMP-000-3E4AC3

Since the impact is limited to specific use cases, they did not issue
a DSA. A CVE has been requested but it still pending.

Description: After entering the first run wizard secret, other
web-sessions can continue the first run wizard without being asked for
the first run wizard secret.


[ Impact ]

Users performing initial setup of FreedomBox on untrusted networks are
impacted.

The vulnerability can be exploited by an adversary without any
tool or code. In a typical home server setup, an adversary in the home
network, during the initial setup of FreedomBox (at the right time), can
create an administrator account for themselves and gain full access. In
case of FreedomBox cloud instances (unusual), an adversary can remotely
exploit the vulnerability from public internet.


[ Tests ]

I manually tested by creating a fresh VM with buster from Debian
installer. I installed freedombox_19.1+deb10u2_all.deb and accessed
the web interface. I was prompted to type in a secret from
/var/lib/plinth/firstboot-wizard-secret, which I did. This brought me
to the initial user creation form.

I then opened a private browsing window and accessed the web
interface. I confirmed that I was prompted for the secret again, and
could not create a user account without entering the secret.

The issue was also fixed in freedombox 21.4.2, currently in unstable.

Additional tests performed for this fix in unstable:
https://salsa.debian.org/freedombox-team/freedombox/-/issues/2074#note_233860


[ Risks ]

The code is fairly simple, makes use of Django session data, and one
step added to a middleware, which checks several conditions.


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


[ Changes ]

When the secret is entered, the key 'firstboot_secret_provided' is set
in the Django session (server-side). Then in the firstboot middleware,
if the requested page is later in the firstboot process, it checks if
the session variable is set, or if the user is an administrator
(meaning the initial user has already been created). If neither is the
case, the request is redirected back to the welcome page, which
requires the secret to be entered before proceeding.

-BEGIN PGP SIGNATURE-

iQJKBAEBCgA0FiEEfWrbdQ+RCFWJSEvmd8DHXntlCAgFAmBlJr8WHGp2YWxsZXJv
eUBtYWlsYm94Lm9yZwAKCRB3wMdee2UICE9XEACyjRu2Lx2Ee6ixxWUxYhibX8Dr
CIIyIlR15JPGF9y9wLnj8SSuGXY2yDTGL5xe0YTMa4U9M+UED62lyoEzB3+Qj0uo
jmdYBCwZtgsPskD7APalV1sQxNCjRjdq9EsZNsWxEUyxH6I/1IUTgBIC3hwCWHgg
IEipqV/XwSTViMDhjccopvBjv2OMhjpVptzNGTara4uQwoB971/YmpalXAi/+dHr
1dx6gVuAx7bKxRwC4qDhJmGJx9DQRpUBjKR3Z1DBqvhfTn02lID5+rynysOo/7F5
8p+M25PfKzRzSWp6UZuYjXnWdYeB6Szvw8S6WGNqX53NMGPt3h34iiyjRv3PQjmR
P/fAeMBZVREpEd+c47j7DLoGdcet/xfj8LSdtB06xbp7+bfP0KeqMG1wemaiyACc
9cFuIdsWjIp/L1igzPxSdYMEaYyk2eC8Fc0etMhe7WtWNIZQ2upILpHf0arKvG/M
eOBIeNwdcLdN9MWTfHfK1csl6eTG2bVWL25GjXcHGR2Mt9yyXYIAAnkJJdMMrX7f
P7X0MFMISR5MjDIqgH1TLqmsk00W9oSzjjqlTPirhkze4Mq4ymkSfpT5jsz186Dx
3nuX/Z96Yuft3HTjc4KqO8LXk94gJfc9kb1kU4woxfkYEIDys7vPCh6sQfcN4iav
z9qnrpIt/LKEFlOitw==
=iEkv
-END PGP SIGNATURE-
diff -Nru plinth-19.1+deb10u1/debian/changelog 
plinth-19.1+deb10u2/debian/changelog
--- plinth-19.1+deb10u1/debian/changelog2020-09-21 21:40:22.0 
-0400
+++ plinth-19.1+deb10u2/debian/changelog2021-03-30 21:43:08.0 
-0400
@@ -1,3 +1,10 @@
+plinth (19.1+deb10u2) buster; urgency=medium
+
+  [ Kirill Schmidt ]
+  * first_boot: Use session to verify first boot welcome step
+
+ -- James Valleroy   Tue, 30 Mar 2021 21:43:08 -0400
+
 plinth (19.1+deb10u1) buster; urgency=medium
 
   * apache: Disable mod_status (CVE-2020-25073)
diff -Nru plinth-19.1+deb10u1/plinth/modules/first_boot/middleware.py 
plinth-19.1+deb10u2/plinth/modules/first_boot/middleware.py
--- plinth-19.1+deb10u1/plinth/modules/first_boot/middleware.py 2020-09-21 
21:40:22.0 -0400
+++ plinth-19.1+deb10u2/plinth/modules/first_boot/middleware.py 2021-03-30 
21:43:08.0 -0400
@@ -28,6 +28,7 @@
 from django.utils.deprecation import MiddlewareMixin
 
 from plinth.modules import first_boot
+from plinth.utils import is_user_admin
 
 LOGGER = logging.getLogger(__name__)
 
@@ -52,6 +53,15 @@
 firstboot_completed = first_boot.is_completed()
 user_requests_firstboot = first_boot.is_firstboot_url(request.path)
 
+# If user requests a step other than the welcome step, verify that they
+# indeed completed the secret verification by looking at the session.
+if (user_requests_firstboot and
+

Bug#950447: Document that persistent journal is now enabled in systemd

2021-03-31 Thread Justin B Rye
Andrei POPESCU wrote
> On Mi, 31 mar 21, 17:33:47, Justin B Rye wrote:
>> +
>> +  Persistent systemd journal
>> +  
>> +Systemd in bullseye activates its persistent journal functionality
>> +by default, storing its files in
>> +/var/log/journal/. See > +
>> url="/bullseye/systemd/journald.conf.5.html">journald.conf(5)
>> +for details.
> 
> To me systemd-journald.service(8) seems like a better introduction.

And it does have a fairly conspicuous pointer towards journald.conf(5)
and Storage= in particular.  Fair enough.

> It's probably also worth mentioning that on Debian the journal is 
> readable by members of 'adm', in addition to the default 
> 'systemd-journal' group.

So something like the attached:
-- 
JBR with qualifications in linguistics, experience as a Debian
sysadmin, and probably no clue about this particular package
diff --git a/en/whats-new.dbk b/en/whats-new.dbk
index 1e361e61..c271945c 100644
--- a/en/whats-new.dbk
+++ b/en/whats-new.dbk
@@ -182,6 +182,25 @@ linkend="obsolete"/>.
   
 
 
+
+  Persistent systemd journal
+  
+Systemd in bullseye activates its persistent journal functionality
+by default, storing its files in
+/var/log/journal/. See systemd-journald.service(8)
+for details; note that on Debian the journal is readable for
+members of adm, in addition to the default
+systemd-journal group.
+  
+  
+This should not interfere with any existing traditional logging
+daemon such as rsyslog, but
+users who are not relying on special features of such a daemon may
+wish to uninstall it and switch over to using only the journal.
+  
+
+
 
   Desktops and well known packages
 


Bug#986229: RFS: fonts-inter/3.17+ds-1 -- Inter font family

2021-03-31 Thread Gürkan Myczko

Package: sponsorship-requests
Severity: normal

Dear mentors,

I am looking for a sponsor for my package "fonts-inter":

 * Package name: fonts-inter
   Version : 3.17+ds-1
   Upstream Author : The Inter Project Authors 
 * URL : https://rsms.me/inter/
 * License : OFL-1.1 and Apache-2.0
 * Vcs : https://salsa.debian.org/fonts-team/fonts-inter
   Section : fonts

It builds those binary packages:

  fonts-inter-variable - Inter font family (VF)
  fonts-inter - Inter font family

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


  https://mentors.debian.net/package/fonts-inter/

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


  dget -x 
https://mentors.debian.net/debian/pool/main/f/fonts-inter/fonts-inter_3.17+ds-1.dsc


Changes since the last upload:

 fonts-inter (3.17+ds-1) experimental; urgency=medium
 .
   * New upstream version.

Regards,
--
  Gürkan Myczko



Bug#986124: linux-image-4.19.0-16-amd64: Version 4.19.0-16 breaks lirc and vdr

2021-03-31 Thread Salvatore Bonaccorso
Control: tags -1 + moreinfo

Hi David,

On Tue, Mar 30, 2021 at 12:42:50AM +0200, David Ruetti wrote:
> Package: src:linux
> Version: 4.19.181-1
> Severity: important
> 
> Upgraded to latest packages and with Kernel 4.19.0-16 lirc stopped working. 
> It cannot find /sys/class/rc and fills every second syslog:
> 
> Mar 30 00:09:45 supply lircd[296]: lircd-0.10.1[296]: Error: No 
> /sys/class/rc/ devices found
> Mar 30 00:09:45 supply lircd-0.10.1[296]: Error: No /sys/class/rc/ devices 
> found
> 
> Booting into 4.19.0-14, lirc work as expected. Breaking of lirc
> presumably affects vdr (vdr_2.4.1-4~etobi2_amd64.deb /
> packages.e-tobi.net vdr-experimental buster) as well. Vdr is working
> as expected on 4.19.0-14 kernel.

Would it be possible for you to check as well directly vanilla
upstream 4.19.181 and ideally 4.19.183 and if reproducible try to
bisect the offending commit introducing the issue?

https://wiki.debian.org/DebianKernel/GitBisect might help here.

It might be related to
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1901089 and
896111dc4bcf ("media: rc: ensure that uevent can be read directly
after rc device register") from 5.11-rc6 but which was backported to
4.19.173 and 5.10.13.

Do you have the same problem running the backports kernel?

Regards,
Salvatore



Bug#986228: nntp.c: close the file "resolv" to avoid leaking

2021-03-31 Thread Bjarni Ingi Gislason
Source: nn
Version: 6.7.3-14
Severity: normal
Tags: patch

Dear Maintainer,

>From 15ca216311a1cc157e627cd0207a8a4422e322f4 Mon Sep 17 00:00:00 2001
>From: Bjarni Ingi Gislason 
>Date: Thu, 1 Apr 2021 02:53:22 +
>Subject: [PATCH] nntp.c: close the file "resolv" to avoid leaking

  The compiler option "-fanalyzer" shows:

nntp.c: In function 'set_domain':
nntp.c:957:1: warning: leak of FILE 'resolv' [CWE-775] [-Wanalyzer-file-leak]
  957 | }
  | ^
...

Signed-off-by: Bjarni Ingi Gislason 
---
 nntp.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/nntp.c b/nntp.c
index a320df4..66064b6 100644
--- a/nntp.c
+++ b/nntp.c
@@ -942,6 +942,7 @@ set_domain(void)
break;
}
}
+   fclose(resolv);
}
if (domain[0] == '\0')
nn_exitmsg(1, "hostname=%s, You need a fully qualified domain 
name", host_name);
-- 
2.30.2



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

Kernel: Linux 5.10.24-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#986227: RFP: paperless-ng -- scan, index and archive all your physical documents

2021-03-31 Thread Phil Morrell
Package: wnpp
Severity: wishlist

* Package name: paperless-ng
  Version : 1.3.2
  Upstream Author : Jonas Winkler
* URL : https://paperless-ng.readthedocs.io/en/latest/
* License : GPL-3.0-or-later
  Programming Lang: Python backend, Javascript frontend
  Description : scan, index and archive all your physical documents

Paperless does not control your scanner, it only helps you deal with
what your scanner produces. Paperless doesn't care how the documents get
into its local consumption directory. You can setup a document scanner
to "scan to FTP", install an Android Share application, configure email
attachment processing via IMAP or just submit a web form.

Wait for paperless to process your files. OCR is expensive, and
depending on the power of your machine, this might take a bit of time.
Use the web frontend to sift through the database and find what you
want. Download the PDF you need/want via the web interface and do
whatever you like with it.

Filtering by tags, correspondents, types, and more. Full text search
helps you find what you need. Paperless learns from your documents and
will be able to automatically assign tags, correspondents and types to
documents once you've stored a few documents in paperless.

---

paperwork is a desktop application just recently added to the archive
that could be used, but a paperless-ng server feels like a better way to
handle the multiple devices usecase and could be a FreedomBox module.


signature.asc
Description: PGP signature


Bug#986226: db.c: add code to account for the case "line == NULL"

2021-03-31 Thread Bjarni Ingi Gislason
Source: nn
Version: 6.7.3-14
Severity: normal
Tags: patch

Dear Maintainer,

>From 7e8a88fd854a4c07f9df9c1c14929870d073fdcf Mon Sep 17 00:00:00 2001
>From: Bjarni Ingi Gislason 
>Date: Thu, 1 Apr 2021 02:23:54 +
>Subject: [PATCH] db.c: add code to account for the case "line == NULL"

  Indicated by the compiler option "-fanalyzer":

In function 'readtimfile':
db.c:1427:22: warning: use of NULL 'line' where non-null expected [CWE-690] 
[-Wanalyzer-null-argument]
 1427 |  char   *p = strchr(line, ' ');
  |  ^
...
In file included from db.c:10:
/usr/include/string.h:226:14: note: argument 1 of 'strchr' must be non-null
  226 | extern char *strchr (const char *__s, int __c)
  |  ^~

Signed-off-by: Bjarni Ingi Gislason 
---
 db.c | 10 +++---
 1 file changed, 7 insertions(+), 3 deletions(-)

diff --git a/db.c b/db.c
index 251be35..257ee5c 100644
--- a/db.c
+++ b/db.c
@@ -1423,9 +1423,13 @@ readtimfile(void)
 #endif /* NNTP */
 
 {
-   char   *line = strkeep(timline, 0, POOL_TIM);
-   char   *p = strchr(line, ' ');
-
+   char   *line = strkeep(timline, 0, POOL_TIM);
+   if (line == NULL) {
+   char   *p = NULL;
+   }
+   else {
+   char   *p = strchr(line, ' ');
+   }
if (p == NULL)
continue;
*p++ = NUL;
-- 
2.30.2



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

Kernel: Linux 5.10.24-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#986225: proto.c: Don't call "unlink()" with a "NULL" as an argument

2021-03-31 Thread Bjarni Ingi Gislason
Source: nn
Version: 6.7.3-14
Severity: normal
Tags: patch

Dear Maintainer,

>From dd06fa4749ec094ae075d192f966f38bc929e6a6 Mon Sep 17 00:00:00 2001
>From: Bjarni Ingi Gislason 
>Date: Thu, 1 Apr 2021 01:46:00 +
>Subject: [PATCH] proto.c: Don't call "unlink()" with a "NULL" as an argument

  Shown by the "-fanalyzer" option:

proto.c:190:5: warning: use of NULL 'lock' where non-null expected [CWE-690] 
[-Wanalyzer-null-argument]
  190 | unlink(lock);
...
In file included from proto.c:14:
/usr/include/unistd.h:825:12: note: argument 1 of 'unlink' must be non-null
  825 | extern int unlink (const char *__name) __THROW __nonnull ((1));
  |^~

Signed-off-by: Bjarni Ingi Gislason 
---
 proto.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/proto.c b/proto.c
index 3a9e256..5e862c2 100644
--- a/proto.c
+++ b/proto.c
@@ -187,7 +187,7 @@ again:
 /* wrong owner, ie. neither master or expire, so remove it */
 
 rm_lock:
-unlink(lock);
+if (lock != NULL) unlink(lock);
 
 no_lock:
 if (command != PL_SET && command != PL_SET_QUICK && command != PL_SET_WAIT)
-- 
2.30.2



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

Kernel: Linux 5.10.24-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#985197: kwin-wayland: Drag and drop a file in Dolphin makes KDE Plasma Wayland crash

2021-03-31 Thread Bernhard Übelacker

Hello Silvério,



Am 31.03.21 um 20:42 schrieb Silvério Santos:

Hallo Bernhard,

Here is it:

Mär 31 20:11:25 systemname kernel: kwin_wayland[1834]: segfault at e8 ip 
7fe70ba08268 sp 7ffc9bbf64d0 error 4 in 
libKWaylandServer.so.5.20.5[7fe70b9b+b6000]
Mär 31 20:11:25 systemname kernel: Code: 00 00 48 8b 47 10 48 8b 40 48 c3 90 66 0f 1f 
44 00 00 41 57 41 56 41 55 41 54 41 89 f4 55 48 89 fd 53 48 83 ec 18 4c 8b 7f 10 
<49> 8b 87 c8 00 00 00 8b 48 0c 8b 58 08 89 4c 24 0c 89 5c 24 08 39
Mär 31 20:11:25 systemname systemd[1]: Created slice 
system-systemd\x2dcoredump.slice.
Mär 31 20:11:25 systemname systemd[1]: Started Process Core Dump (PID 3494/UID 
0).



Mär 31 20:12:04 systemname systemd-coredump[3495]: Process 1834 (kwin_wayland) 
of user 1000 dumped core.
   
   Stack trace of thread 1834:

   #0  0x7fe70ba08268 n/a 
(n/a + 0x0)
Mär 31 20:12:05 systemname systemd[1]:systemd-coredump@0-3494-0.service: 
Succeeded.




thanks for the quick response, but unfortunately this
is less informative as I expected it to be.

If you have the package gdb installed could you please
try following commands and forward the output:

coredumpctl gdb 1834
set pagination off
bt

(With 1834 or the last pid shown after kwin_wayland
from the latest crash.)

Kind regards,
Bernhard



Bug#939585: installation-reports: confirmed with current installer

2021-03-31 Thread Norbert Preining
Package: installation-reports
Followup-For: Bug #939585

Same has happened on my system today, with a very recent installer.



Bug#986223: Much newer version available

2021-03-31 Thread Henning Sprang
Package: python3-pg8000
Version: 1.10.6-2

The upstream version of this package in the archive  is from 2016.

The current upstream version of this package is 1.19.0 from March 28, 2021.

Also, the homepage given in the Debian package tracker is not correct anymore.
The current one is https://github.com/tlocke/pg8000 (as announced on
the one currently mentioned as the homepage in the debian package
tracker).

If you need help doing this update, please let me know.

Thanks in advance



Bug#985459: dh-elpa: install error when root user has packages under /root/.emacs.d/elpa

2021-03-31 Thread Sean Whitton
Hello,

On Fri 19 Mar 2021 at 03:04AM GMT, Nick Gasson wrote:

> Hi Sean,
>
> On 03/18/21 18:31 PM, Sean Whitton wrote:
>>
>> Thank you for the report.  Can you test this patch, please?
>>
>> diff --git a/helper/install b/helper/install
>> index 1a2eb8a..af93ee4 100755
>> --- a/helper/install
>> +++ b/helper/install
>> @@ -51,6 +51,8 @@ echo install/${ELPA_DIR}: byte-compiling for ${FLAVOR}
>>  (cd ${elc_dir}
>>   set +e
>>   ${FLAVOR} --quick --batch -l package \
>> +   --eval "(setq package-directory-list \
>> + (delete package-user-dir package-directory-list))" 
>> \
>> --eval "(add-to-list 'package-directory-list \"$src_dir\")" \
>> -f package-initialize -f batch-byte-compile *.el > Install.log 
>> 2>&1
>>   if test $? -ne 0
>
> I've just tried this but unfortunately I get the same error. I think
> it's because package-load-all-descriptors in package.el always cons-es
> package-user-dir on the front of package-directory-list when it searches
> for a package
>
>   (defun package-load-all-descriptors ()
> ...
> (dolist (dir (cons package-user-dir package-directory-list))
>   (when (file-directory-p dir)
> ...)))
>
> Perhaps an alternative is to set package-user-dir to a temporary
> directory that's guaranteed not to contain any existing packages.

Yes, that sounds like a good idea.

-- 
Sean Whitton


signature.asc
Description: PGP signature


Bug#793675: hplip-gui: No system tray detected

2021-03-31 Thread Fabrice Bauzac-Stehly
This affects a number of operating system packages of hplip.

See this upstream bug:
https://bugs.launchpad.net/hplip/+bug/1714659

Concerning the idea of forcing a dependency on sni-qt, it looks like
this package does not exist (anymore?).

Concerning the need to add a "sleep" before starting hp-systray, this is
not useful anymore as the program now does this sleep (for up to 60
seconds), waiting for a system tray to be available.

About the idea of installing gnome-shell-extension-top-icons-plus, I can
confirm that it does not solve the issue for my GNOME environment.

To summarize, hplip provides several tools, among which there is
hp-systray which handles a system tray functionality.  However, system
trays are now replaced with "Notifications" in GNOME, and the system
tray functionality is simply absent nowadays in GNOME.  The message from
GNOME is that applications should stop relying on this (old) way of
doing things.  I'm not sure what functionality the hp-systray provides,
but if it makes sense the hplip team would have to create a new tool
based on "Notifications" that would provide the same functionality.

I doubt we can remove hp-systray; it may be useful for users of desktop
environments other than GNOME that still have a system tray.

To fix this issue which, as far as I know, only hit GNOME users, I
suggest to add this line to /etc/xdg/autostart/hplip-systray.desktop:

NotShowIn=GNOME;

So that the issue stops annoying GNOME users.

-- 
Fabrice Bauzac-Stehly
PGP 01EEACF8244E9C14B551C5256ADA5F189BD322B6
old PGP 015AE9B25DCB0511D200A75DE5674DEA514C891D



Bug#986209: debian-cd: Please provide symlinks for stable, unstable, etc...

2021-03-31 Thread Paul's Snet Email
UNSUBSCRIBE 

Sent from my iPhone

> On Mar 31, 2021, at 12:18 PM, bauen1  wrote:
> 
> Package: debian-cd
> Version: 3.1.33
> Severity: wishlist
> X-Debbugs-Cc: j24...@gmail.com
> 
> Dear Maintainer,
> 
> While building my own CDs I've discovered that while most tools, e.g. 
> debootstrap, allow using `unstable` / `sid` with the same results, debian-cd 
> does not.
> This could be handled by adding symlinks, like for sid, to data, tasks, 
> tools/boot , thus allowing the user to specify CODENAME=unstable to build a 
> sid installer cd.
> 
> -- System Information:
> Debian Release: bullseye/sid
>  APT prefers unstable
>  APT policy: (500, 'unstable'), (500, 'testing'), (1, 'experimental')
> Architecture: amd64 (x86_64)
> Foreign Architectures: i386
> 
> Kernel: Linux 5.10.0-5-amd64 (SMP w/4 CPU threads)
> Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
> TAINT_UNSIGNED_MODULE
> Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) (ignored: 
> LC_ALL set to en_US.UTF-8), LANGUAGE=en_US:en
> Shell: /bin/sh linked to /usr/bin/dash
> Init: systemd (via /run/systemd/system)
> LSM: SELinux: enabled - Mode: Enforcing - Policy name: bauen1-policy
> 
> Versions of packages debian-cd depends on:
> ii  apt2.2.2
> ii  bc 1.07.1-2+b2
> ii  bzip2  1.0.8-4
> ii  cpp4:10.2.1-1
> ii  curl   7.74.0-1.1
> ii  dctrl-tools [grep-dctrl]   2.24-3+b1
> ii  dpkg-dev   1.20.7.1
> ii  genisoimage9:1.1.11-3.2
> pn  libcompress-zlib-perl  
> pn  libdigest-md5-perl 
> ii  libdpkg-perl   1.20.7.1
> ii  lynx   2.9.0dev.6-2
> ii  make   4.3-4
> ii  perl [libdigest-sha-perl]  5.32.1-3
> ii  tofrodos   1.7.13+ds-5
> ii  wget   1.21-1+b1
> ii  xorriso1.5.2-1
> 
> Versions of packages debian-cd recommends:
> ii  dosfstools   4.2-1
> ii  hfsutils 3.2.6-15
> ii  isolinux 3:6.04~git20190206.bf6db5b4+dfsg1-3
> ii  mtools   4.0.26-1
> ii  netpbm   2:10.0-15.4
> ii  syslinux-common  3:6.04~git20190206.bf6db5b4+dfsg1-3
> ii  syslinux-utils   3:6.04~git20190206.bf6db5b4+dfsg1-3
> 
> debian-cd suggests no packages.
> 
> -- no debconf information
> 



Bug#986222: glibc: Fix O_NONBLOCK value on hppa architecture

2021-03-31 Thread Aurelien Jarno
control: forcemerge 981650 986222

Hi Helge,

On 2021-03-31 23:33, Helge Deller wrote:
> Package: glibc
> Version: 2.31-11
> Tags: hppa, patch
> 
> Please apply the attached patch which removes obsolete defines
> on the hppa architecture for old HPUX support from fcntl.h.
> The most important part is changing O_NONBLOCK to just be one bit.
> The patch is already committed upstream in glibc-2.33, but we would
> need it in the current debian/sid glibc-2.31 too.

This looks like a duplicate of #981650, which can't be fixed right now
due to the freeze. Merging the bugs.

Cheers,
Aurelien

-- 
Aurelien Jarno  GPG: 4096R/1DDD8C9B
aurel...@aurel32.net http://www.aurel32.net



Bug#985066: mono-gac: messes with the unpacking of another package

2021-03-31 Thread Andreas Beckmann
Followup-For: Bug #985066
Control: tag -1 patch

The attached patch fixes the piuparts issue for me.

Andreas
diff -Nru mono-6.8.0.105+dfsg/debian/changelog 
mono-6.8.0.105+dfsg/debian/changelog
--- mono-6.8.0.105+dfsg/debian/changelog2020-04-08 15:11:12.0 
+0200
+++ mono-6.8.0.105+dfsg/debian/changelog2021-03-31 13:38:34.0 
+0200
@@ -1,3 +1,10 @@
+mono (6.8.0.105+dfsg-4) UNRELEASED; urgency=medium
+
+  * mono-gac: Depend on mono-runtime-common (>= 5.20) and stop messing with
+/etc/mono/config manually.  (Closes: #985066)
+
+ -- Andreas Beckmann   Wed, 31 Mar 2021 13:38:34 +0200
+
 mono (6.8.0.105+dfsg-3) unstable; urgency=high
 
   * [2501df4] Workaround for gacutil System.Native mapping dependency 
diff -Nru mono-6.8.0.105+dfsg/debian/control mono-6.8.0.105+dfsg/debian/control
--- mono-6.8.0.105+dfsg/debian/control  2020-02-25 22:34:26.0 +0100
+++ mono-6.8.0.105+dfsg/debian/control  2021-03-31 13:38:32.0 +0200
@@ -2971,6 +2971,7 @@
 Package: mono-gac
 Architecture: all
 Depends: ${misc:Depends},
+ mono-runtime-common (>= 5.20),
  mono-4.0-gac (= ${source:Version})
 Provides: global-assembly-cache-tool
 Description: Mono GAC tool
diff -Nru mono-6.8.0.105+dfsg/debian/mono-gac.postinst 
mono-6.8.0.105+dfsg/debian/mono-gac.postinst
--- mono-6.8.0.105+dfsg/debian/mono-gac.postinst2020-02-25 
20:06:42.0 +0100
+++ mono-6.8.0.105+dfsg/debian/mono-gac.postinst2021-03-31 
13:38:31.0 +0200
@@ -1,10 +1,5 @@
 #!/bin/sh -e
 
-# Work around for gacutil needing /etc/mono/config >= 5.20
-if [ -e /etc/mono/config.dpkg-new ]; then
-   mv /etc/mono/config.dpkg-new /etc/mono/config
-fi
-
 # On upgrades we need to repopulate the GAC and framework paths
 # to accomodate any changes in layout
 #


Bug#986222: Acknowledgement (glibc: Fix O_NONBLOCK value on hppa architecture)

2021-03-31 Thread Helge Deller

The attached second patch is needed too.
It corrects hppa EFD_NONBLOCK, IN_NONBLOCK, SFD_NONBLOCK and TFD_NONBLOCK 
defines.

From: John David Anglin 
Date: Fri, 19 Feb 2021 17:08:47 + (+)
Subject: Correct hppa EFD_NONBLOCK, IN_NONBLOCK, SFD_NONBLOCK and TFD_NONBLOCK defines.
X-Git-Url: https://sourceware.org/git/?p=glibc.git;a=commitdiff_plain;h=96b8038f12dd5fc5620a1213b79eb3a8342e846a;hp=044e603b698093cf48f6e6229e0b66acf05227e4

Correct hppa EFD_NONBLOCK, IN_NONBLOCK, SFD_NONBLOCK and TFD_NONBLOCK defines.
---

diff --git a/sysdeps/unix/sysv/linux/hppa/bits/eventfd.h b/sysdeps/unix/sysv/linux/hppa/bits/eventfd.h
index e692b44c56..c1a46a16b0 100644
--- a/sysdeps/unix/sysv/linux/hppa/bits/eventfd.h
+++ b/sysdeps/unix/sysv/linux/hppa/bits/eventfd.h
@@ -26,6 +26,6 @@ enum
 #define EFD_SEMAPHORE EFD_SEMAPHORE
 EFD_CLOEXEC = 01000,
 #define EFD_CLOEXEC EFD_CLOEXEC
-EFD_NONBLOCK = 0024 /* HPUX has separate NDELAY & NONBLOCK */
+EFD_NONBLOCK = 0020
 #define EFD_NONBLOCK EFD_NONBLOCK
   };
diff --git a/sysdeps/unix/sysv/linux/hppa/bits/inotify.h b/sysdeps/unix/sysv/linux/hppa/bits/inotify.h
index f6cf97e8a7..a69a4a88d9 100644
--- a/sysdeps/unix/sysv/linux/hppa/bits/inotify.h
+++ b/sysdeps/unix/sysv/linux/hppa/bits/inotify.h
@@ -24,6 +24,6 @@ enum
   {
 IN_CLOEXEC = 01000,
 #define IN_CLOEXEC IN_CLOEXEC
-IN_NONBLOCK = 00024 /* HPUX has separate NDELAY & NONBLOCK */
+IN_NONBLOCK = 00020
 #define IN_NONBLOCK IN_NONBLOCK
   };
diff --git a/sysdeps/unix/sysv/linux/hppa/bits/signalfd.h b/sysdeps/unix/sysv/linux/hppa/bits/signalfd.h
index dd4ba77cc8..18568a9f1d 100644
--- a/sysdeps/unix/sysv/linux/hppa/bits/signalfd.h
+++ b/sysdeps/unix/sysv/linux/hppa/bits/signalfd.h
@@ -24,6 +24,6 @@ enum
   {
 SFD_CLOEXEC = 01000,
 #define SFD_CLOEXEC SFD_CLOEXEC
-SFD_NONBLOCK = 0024 /* HPUX has separate NDELAY & NONBLOCK */
+SFD_NONBLOCK = 0020
 #define SFD_NONBLOCK SFD_NONBLOCK
   };
diff --git a/sysdeps/unix/sysv/linux/hppa/bits/timerfd.h b/sysdeps/unix/sysv/linux/hppa/bits/timerfd.h
index f64502477a..9d7f228995 100644
--- a/sysdeps/unix/sysv/linux/hppa/bits/timerfd.h
+++ b/sysdeps/unix/sysv/linux/hppa/bits/timerfd.h
@@ -24,6 +24,6 @@ enum
   {
 TFD_CLOEXEC = 01000,
 #define TFD_CLOEXEC TFD_CLOEXEC
-TFD_NONBLOCK = 00024 /* HPUX has separate NDELAY & NONBLOCK */
+TFD_NONBLOCK = 00020
 #define TFD_NONBLOCK TFD_NONBLOCK
   };


Bug#986222: glibc: Fix O_NONBLOCK value on hppa architecture

2021-03-31 Thread Helge Deller

Package: glibc
Version: 2.31-11
Tags: hppa, patch

Please apply the attached patch which removes obsolete defines
on the hppa architecture for old HPUX support from fcntl.h.
The most important part is changing O_NONBLOCK to just be one bit.
The patch is already committed upstream in glibc-2.33, but we would
need it in the current debian/sid glibc-2.31 too.

All other projects have been fixed already too (Linux kernel, dietlibc,
qemu, ...).

Thanks,
Helge
From: John David Anglin 
Date: Fri, 13 Nov 2020 16:42:11 + (+)
Subject: Remove obsolete defines for HPUX support from fcntl.h and update O_NONBLOCK.
X-Git-Tag: glibc-2.33~298
X-Git-Url: https://sourceware.org/git/?p=glibc.git;a=commitdiff_plain;h=a24f414ba11a7acdf3c5ccec3fb327fc72166556;hp=01bd62517cc242ae503aaa7002e9e94551803e4d

Remove obsolete defines for HPUX support from fcntl.h and update O_NONBLOCK.
---

diff --git a/sysdeps/unix/sysv/linux/hppa/bits/fcntl.h b/sysdeps/unix/sysv/linux/hppa/bits/fcntl.h
index 294d3b5191..47686099a7 100644
--- a/sysdeps/unix/sysv/linux/hppa/bits/fcntl.h
+++ b/sysdeps/unix/sysv/linux/hppa/bits/fcntl.h
@@ -24,14 +24,11 @@
 #define O_EXCL		2000 /* not fcntl */
 #define O_NOCTTY	0040 /* not fcntl */
 #define O_APPEND	0010
-#define O_NONBLOCK	0024 /* HPUX has separate NDELAY & NONBLOCK */
+#define O_NONBLOCK	0020
 #define __O_DSYNC	0100
-#define __O_RSYNC	0200 /* HPUX only */
 #define __O_SYNC	0010
 #define O_SYNC		(__O_SYNC|__O_DSYNC)

-#define O_BLKSEEK	0100 /* HPUX only */
-
 #define __O_DIRECTORY	1 /* Must be a directory.  */
 #define __O_NOFOLLOW	00200 /* Do not follow links.  */
 #define __O_CLOEXEC	01000 /* Set close_on_exec.  */


Bug#980502: evolution: printing emails doesn't work

2021-03-31 Thread Alberto Garcia
On Wed, Mar 31, 2021 at 09:14:05PM +0200, Markus Frosch wrote:

> I can confirm this, root cause seems to be using the sandbox of webkit.
> 
> Issue: https://bugs.webkit.org/show_bug.cgi?id=202363
> 
> Workaround would be starting evolution like this:
> WEBKIT_FORCE_SANDBOX=0 evolution
> 
> Until fixed, Webkit devs seems to recommend disabling the sandbox code.

Is disabling the sandbox in Evolution an option? (i.e. setting
WEBKIT_FORCE_SANDBOX=0 in the Evolution code).

Berto



Bug#986221: ITP: postgresql-semver -- Semantic version type for PostgreSQL

2021-03-31 Thread Felix Lechner
Package: wnpp
Severity: wishlist
Owner: Felix Lechner 
X-Debbugs-CC: Debian PostgreSQL Maintainers 


* Package name: postgresql-semver
  Version : 0.31.0
  Upstream Author : David E. Wheeler 
* URL : https://github.com/theory/pg-semver
* License : PostgreSQL / Apache-2.0
  Programming Lang: SQL, C
  Description : Semantic version type for PostgreSQL

This library contains a single PostgreSQL extension for a data type
called 'semver'. It implements the version number format described in
the Semantic Versioning 2.0.0 Specification. [1]

The Debian packaging is based on the Apache-2.0 license because I
adapted packaging from an existing repository. [2]

I hope to convince the PostgreSQL Maintainers to adopt this package,
otherwise I will maintain it.

Kind regards
Felix Lechner

[1] https://semver.org/spec/v2.0.0.html
[2] https://github.com/mgit-at/pg-semver-debian



Bug#944485: mmdebstrap: please implement the creation of QEMU/KVM images for autopkgtest-virt-qemu

2021-03-31 Thread Francesco Poli
On Tue, 30 Mar 2021 02:04:03 +0200 Johannes Schauer Marin Rodrigues wrote:

[...]
> That depends on what you want to do inside that qemu environment. And it's
> totally possible to create a 10 GB disk image in your $HOME while only using
> 200 MB in your /tmp for the chroot.

Well... I tried dropping the TMPDIR setting and exporting in the script.
But:

  $ cd ~/Downloads/
  $ mmdebstrap-autopkgtest-qemu 8GiB
  I: automatically chosen mode: unshare
  I: chroot architecture amd64 is equal to the host's architecture
  I: automatically chosen format: tar
  I: using /tmp/mmdebstrap.h6DOq1LzM2 as tempdir
  [...]
  Setting up linux-image-5.10.0-5-amd64 (5.10.26-1) ...
  [...]
  cp: error writing 
'/var/tmp/mkinitramfs_chjGze//usr/lib/modules/5.10.0-5-amd64/kernel/drivers/input/mouse/psmouse.ko':
 No space left on device
  E: Sub-process /usr/bin/dpkg returned an error code (1)
  E: run_chroot failed: E: env --unset=APT_CONFIG --unset=TMPDIR 
/usr/sbin/chroot /tmp/mmdebstrap.h6DOq1LzM2 apt-get --yes install 
-oAPT::Status-Fd=<$fd> -oDpkg::Use-Pty=false dmidecode linux-image-amd64 
logrotate sensible-utils fdisk rsyslog systemd libpam-modules-bin iproute2 
vim-common passwd iputils-ping init e2fsprogs kmod adduser tzdata ifupdown udev 
vim-tiny libreadline8 gcc-10-base mawk apt apt-utils gpgv gcc-9-base mount 
libpam-runtime whiptail debian-archive-keyring procps debconf-i18n tasksel-data 
readline-common nano netbase isc-dhcp-client systemd-sysv nftables cpio debconf 
less isc-dhcp-common libpam-modules cron failed
  W: listening on child socket failed: 
  I: removing tempdir /tmp/mmdebstrap.h6DOq1LzM2...


The same happens with:

  $ mmdebstrap-autopkgtest-qemu 1GiB


I cannot understand why you needed less than 200 MB ...


-- 
 http://www.inventati.org/frx/
 There's not a second to spare! To the laboratory!
. Francesco Poli .
 GnuPG key fpr == CA01 1147 9CD2 EFDF FB82  3925 3E1C 27E1 1F69 BFFE


pgpm3w8jtm6fC.pgp
Description: PGP signature


Bug#986220: fonts-font-awesome: unhandled directory to symlink conversion: /usr/share/fonts-font-awesome/scss -> ../sass/font-awesome

2021-03-31 Thread Andreas Beckmann
Package: fonts-font-awesome
Version: 5.0.10+really4.7.0~dfsg-4
Severity: serious
User: debian...@lists.debian.org
Usertags: piuparts
Control: block 983853 with -1
Control: affects -1 + openstack-dashboard

Hi,

a test with piuparts revealed that your package misses some content
after an upgrade, files that should be reachable via the symlink
/usr/share/fonts-font-awesome/scss -> ../sass/font-awesome

After the upgrade /usr/share/fonts-font-awesome/scss is just an
empty directory.

This was observed on the following upgrade paths:

  openstack-dashboard from buster to bullseye

For logs see #983853


Additional info may be available here:
https://wiki.debian.org/MissingCopyrightFile

Note that dpkg intentionally does not replace directories with symlinks
and vice versa, you need the maintainer scripts to do this.
See in particular the end of point 4 in
https://www.debian.org/doc/debian-policy/ch-maintainerscripts.html#details-of-unpack-phase-of-installation-or-upgrade

It is recommended to use the dpkg-maintscript-helper command
'dir_to_symlink' (available since dpkg 1.17.14)
to perform the conversion, ideally using d/$PACKAGE.maintscript.
See dpkg-maintscript-helper(1) and dh_installdeb(1) for details.


cheers,

Andreas



Bug#983853: marked as pending in horizon

2021-03-31 Thread Andreas Beckmann

Control: reopen -1

On 31/03/2021 15.50, Andreas Beckmann wrote:

On 10/03/2021 10.39, Thomas Goirand wrote:
https://salsa.debian.org/openstack-team/services/horizon/-/commit/c841eedc22bfd099cb1bafbe814f847dd050ff60 


* Fix upgrade from Buster to Bullseye by manually copying the 
font-awesome

 scss files in Horizon static folder (Closes: #983853).



fonts-font-awesome has changed its layout:


This happened in 5.0.10+really4.7.0~dfsg-2
(buster has 5.0.10+really4.7.0~dfsg-1)


Is that manual copying in the postinst the correct solution
or does some path need to be updated (and the dependency (where
is it btw?) bumped the version)


python3-django-horizon
  Depends: python3-xstatic-font-awesome
Depends: fonts-font-awesome (>= 4.7.0~)

If I install openstack-dashboard in a buster and a sid chroot, I find 
the same set of files in 
/var/lib/openstack-dashboard/static/horizon/lib/font_awesome/scss, so 
the changed layout does not really matter.

But what is different during the buster2bullseye upgrade?

Found it: /usr/share/fonts-font-awesome/scss/ is an empty directory 
after the buster->bullseye upgrade, but it should be a symlink to 
../sass/font-awesome (i.e. missing dir_to_symlink)


Please revert the workaround you added to openstack-dashboard, let's fix 
this in fonts-font-awesome.



Andreas



Bug#986219: ITP: gnome-shell-extension-shelltile -- tiling window extension for GNOME Shell

2021-03-31 Thread Fabio Augusto De Muzio Tobich
Package: wnpp
Severity: wishlist
Owner: Fabio Augusto De Muzio Tobich 
X-Debbugs-Cc: debian-de...@lists.debian.org, ftob...@gmail.com

* Package name: gnome-shell-extension-shelltile
  Version : 61+git20210205.1d56815-1
  Upstream Author : Emanuele Sabellico 
* URL : https://github.com/emasab/shelltile
* License : GPL-2+
  Programming Lang: JavaScript
  Description : tiling window extension for GNOME Shell

Just move a window to the edges of the screen to create a tiling, otherwise
move a window over another one, holding down the Control key.

Grouped windows minimize, resize, raise and change workspace together. Move
or maximize a window to remove it from the group.



Bug#985383: auditd: Stopping of auditd service cause segmentation fault

2021-03-31 Thread Bernhard Übelacker

Control: fixed -1 1:3.0-2
Control: tags -1 + upstream fixed-upstream


Dear Maintainer,
I tried to reproduce this issue and got this backtrace:

(gdb) bt
#0  0x7f52d57cf7e4 in _IO_new_fclose (fp=0x0) at iofclose.c:48
#1  0x55884d86fec0 in shutdown_events () at 
../../../src/auditd-event.c:122
#2  0x55884d86d421 in close_down () at ../../../src/auditd.c:1012
#3  0x55884d86c9a7 in main (argc=, argv=) 
at ../../../src/auditd.c:995

https://sources.debian.org/src/audit/1:2.8.4-3/src/auditd-event.c/#L122

It looks like upstream has already fixed this issue in this commit,
which is already included in current version in testing:


https://github.com/linux-audit/audit-userspace/commit/e42602b7b246ae62e7a12e9cd91f0ac37b1b1968
https://sources.debian.org/src/audit/1:3.0-2/src/auditd-event.c/#L142

Kind regards,
Bernhard

# single-use Buster/stable amd64 qemu VM 2021-03-31

apt update

apt dist-upgrade
apt install systemd-coredump mc gdb auditd auditd-dbgsym


service auditd stop
cp -a /etc/audit/auditd.conf /etc/audit/auditd.conf.orig
sed -i 's@write_logs = yes@write_logs = no@g' /etc/audit/auditd.conf
sed -i 's@log_file = /var/log/audit/audit.log@#log_file =@g' 
/etc/audit/auditd.conf

service auditd start
service auditd stop


journalctl -f
Mär 31 17:00:07 debian systemd[1]: Stopping Security Auditing Service...
Mär 31 17:00:07 debian audit[1261]: ANOM_ABEND auid=4294967295 uid=0 gid=0 
ses=4294967295 subj==unconfined pid=1261 comm="auditd" exe="/usr/sbin/auditd" 
sig=11 res=1
Mär 31 17:00:07 debian kernel: auditd[1261]: segfault at 0 ip 7f52d57cf7e4 
sp 7ffe709d0790 error 4 in libc-2.28.so[7f52d5782000+148000]
Mär 31 17:00:07 debian kernel: Code: 00 64 44 89 23 85 c0 75 d4 e9 3b ff ff ff 
0f 1f 84 00 00 00 00 00 e8 fb a4 00 00 e9 09 ff ff ff e8 d1 af 09 00 90 41 54 
55 53 <8b> 07 48 89 fb f6 c4 20 0f 85 9e 00 00 00 89 c2 81 e2 00 80 00 00
Mär 31 17:00:07 debian systemd[1]: Created slice 
system-systemd\x2dcoredump.slice.
Mär 31 17:00:07 debian systemd[1]: Started Process Core Dump (PID 1304/UID 0).
Mär 31 17:00:07 debian audit[1]: SERVICE_START pid=1 uid=0 auid=4294967295 
ses=4294967295 subj==unconfined msg='unit=systemd-coredump@0-1304-0 
comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? 
res=success'
Mär 31 17:00:07 debian systemd[1]: auditd.service: Main process exited, 
code=dumped, status=11/SEGV
Mär 31 17:00:07 debian systemd[1]: auditd.service: Failed with result 
'core-dump'.
Mär 31 17:00:07 debian systemd[1]: Stopped Security Auditing Service.
Mär 31 17:00:07 debian audit[1]: SERVICE_STOP pid=1 uid=0 auid=4294967295 
ses=4294967295 subj==unconfined msg='unit=auditd comm="systemd" 
exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=failed'
Mär 31 17:00:07 debian kernel: audit: type=1131 audit(1617202807.556:30): pid=1 
uid=0 auid=4294967295 ses=4294967295 subj==unconfined msg='unit=auditd 
comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? 
res=failed'
Mär 31 17:00:07 debian systemd-coredump[1305]: Process 1261 (auditd) of user 0 
dumped core.

Stack trace of thread 1261:
#0  0x7f52d57cf7e4 fclose 
(libc.so.6)
#1  0x55884d86fec0 n/a 
(auditd)
#2  0x55884d86d421 n/a 
(auditd)
#3  0x55884d86c9a7 n/a 
(auditd)
#4  0x7f52d578409b 
__libc_start_main (libc.so.6)
#5  0x55884d86cf4a n/a 
(auditd)
Mär 31 17:00:07 debian systemd[1]: systemd-coredump@0-1304-0.service: Succeeded.
Mär 31 17:00:07 debian audit[1]: SERVICE_STOP pid=1 uid=0 auid=4294967295 
ses=4294967295 subj==unconfined msg='unit=systemd-coredump@0-1304-0 
comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? 
res=success'
Mär 31 17:00:07 debian kernel: audit: type=1131 audit(1617202807.592:31): pid=1 
uid=0 auid=4294967295 ses=4294967295 subj==unconfined 
msg='unit=systemd-coredump@0-1304-0 comm="systemd" 
exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success'


root@debian:~# coredumpctl list
TIMEPID   UID   GID SIG COREFILE  EXE
Wed 2021-03-31 17:00:07 CEST   1261 0 0  11 present   /usr/sbin/auditd


root@debian:~# coredumpctl gdb 1261
   PID: 1261 (auditd)
   UID: 0 (root)
   GID: 0 (root)
Signal: 11 (SEGV)
 Timestamp: Wed 2021-03-31 17:00:07 CEST (1min 30s ago)
  Command Line: /sbin/auditd
Executable: /usr/sbin/auditd
 Control Group: /system.slice/auditd.service
  Unit: auditd.service
 Slice: system.slice
   Boot ID: 13704ca5860b4e1ca1d50c521516559a
Machine ID: 

Bug#980502: evolution: printing emails doesn't work

2021-03-31 Thread Markus Frosch
clone 980502 -1
forwarded 980502 https://gitlab.gnome.org/GNOME/evolution/-/issues/1141
forwarded -1 https://bugs.webkit.org/show_bug.cgi?id=202363
reassign -1 webkit2gtk 2.30.6-1
retitle -1 Printing not working with bubblewrap sandbox enabled
affects -1 evolution
bye

Hi,

On Tue, 19 Jan 2021 22:52:07 +0100 Ben Ruhnow  wrote:
> when I recently had to print an email I found out that this function is
useless for now! 
> The workaround described there makes this feature useable.
> 
> Hoping this will be fixed in the next releases.

I can confirm this, root cause seems to be using the sandbox of webkit.

Issue: https://bugs.webkit.org/show_bug.cgi?id=202363

Workaround would be starting evolution like this:
WEBKIT_FORCE_SANDBOX=0 evolution

Until fixed, Webkit devs seems to recommend disabling the sandbox code.

Also see:
https://gitlab.gnome.org/GNOME/evolution/-/issues/1141#note_1058502

Best Regards
Markus Frosch



Bug#986217: netty: CVE-2021-21409

2021-03-31 Thread Salvatore Bonaccorso
Source: netty
Version: 1:4.1.48-3
Severity: grave
Tags: security upstream
X-Debbugs-Cc: car...@debian.org, Debian Security Team 

Hi,

The following vulnerability was published for netty.

Strictly speaking this might be disputable as RC severity, but I think
it should be reach bullseye and so make it on the RC severity bugs
radar. It is a followup to the CVE-2021-21295 issue where one case was
missed.

CVE-2021-21409[0]:
| Netty is an open-source, asynchronous event-driven network application
| framework for rapid development of maintainable high performance
| protocol servers  clients. In Netty (io.netty:netty-codec-http2)
| before version 4.1.61.Final there is a vulnerability that enables
| request smuggling. The content-length header is not correctly
| validated if the request only uses a single Http2HeaderFrame with the
| endStream set to to true. This could lead to request smuggling if the
| request is proxied to a remote peer and translated to HTTP/1.1. This
| is a followup of GHSA-wm47-8v5p-wjpj/CVE-2021-21295 which did miss to
| fix this one case. This was fixed as part of 4.1.61.Final.


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-21409
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-21409
[1] https://github.com/netty/netty/security/advisories/GHSA-f256-j965-7f32
[2] 
https://github.com/netty/netty/commit/b0fa4d5aab4215f3c22ce6123dd8dd5f38dc0432

Please adjust the affected versions in the BTS as needed.

Regards,
Salvatore



Bug#986216: buster-pu: package dwarf-fortress/0.44.12+dfsg1-0+deb10u1

2021-03-31 Thread Sven Bartscher
Package: release.debian.org
Severity: normal
Tags: buster
User: release.debian@packages.debian.org
Usertags: pu

[ Reason ]
It has been noted in #986119 that the upstream release tarballs for
dwarf-fortress include shared libraries but no corresponding source
code is available. The shared libraries in question are licensed under
GPL and thus not distributable without source code.

The affected files are not shipped in any binary packages. This
update fixes the issue by repacking the source tarballs to exclude
those files.

[ Impact ]
The package currently in buster is not distributable in its
current form, so it has to be either updated or entirely removed from
buster to cease violating the licenses of the affected files.

[ Tests ]
The now excluded files were not shipped in any binary package or used
in the build process. Their removal should not have any affect on the
binary packages. I confirmed (using diffoscope) that the built debian
packages do not differ in content except in expected ways due to
changed package metadata.

I also manually confirmed that the game can be successfully started
and basic interactions inside the game still work.

[ Risks ]
Since the removed files are not part of any binary packages, it can be
easily confirmed that their removal has no negative effect. I see
virtually no risk introduced by this update.

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

[ Changes ]
The source tarball has been repacked to exclude these files:

* libs/libgcc_s.so.1
* libs/libstdc++.so.6
* libs/libgcc_s.so.1
* libs/libstdc++.so.6

Additionally a note about the repacked tarball has been added to
debian/copyright and the version mangling in debian/watch has been
updated to deal with the new +dsfg1 version suffix.
Binärdateien /tmp/OJJcX56xZH/dwarf-fortress-0.44.12/amd64/libs/libgcc_s.so.1 
und /tmp/JM3ObfSHmq/dwarf-fortress-0.44.12+dfsg1/amd64/libs/libgcc_s.so.1 sind 
verschieden.
Binärdateien /tmp/OJJcX56xZH/dwarf-fortress-0.44.12/amd64/libs/libstdc++.so.6 
und /tmp/JM3ObfSHmq/dwarf-fortress-0.44.12+dfsg1/amd64/libs/libstdc++.so.6 sind 
verschieden.
diff -Nru dwarf-fortress-0.44.12/debian/changelog 
dwarf-fortress-0.44.12+dfsg1/debian/changelog
--- dwarf-fortress-0.44.12/debian/changelog 2018-07-08 15:03:52.0 
+0200
+++ dwarf-fortress-0.44.12+dfsg1/debian/changelog   2021-03-31 
19:01:19.0 +0200
@@ -1,3 +1,10 @@
+dwarf-fortress (0.44.12+dfsg1-0+deb10u1) buster; urgency=high
+
+  * Remove unnecessary code copies with license violations from source
+tarball. (Closes: #986119)
+
+ -- Sven Bartscher   Wed, 31 Mar 2021 19:01:19 +0200
+
 dwarf-fortress (0.44.12-1) unstable; urgency=medium
 
   * New upstream version
diff -Nru dwarf-fortress-0.44.12/debian/copyright 
dwarf-fortress-0.44.12+dfsg1/debian/copyright
--- dwarf-fortress-0.44.12/debian/copyright 2018-07-08 14:13:41.0 
+0200
+++ dwarf-fortress-0.44.12+dfsg1/debian/copyright   2021-03-31 
19:01:19.0 +0200
@@ -11,6 +11,15 @@
  do not grant all freedoms required by the DFSG. No modifications of
  the included binaries are permitted, and the binaries are not
  distributed with source code.
+Comment:
+ Some files have been removed from the original source tarballs, because
+ they are licensed under the GPL, but no source is available for them.
+Files-Excluded-amd64:
+ libs/libgcc_s.so.1
+ libs/libstdc++.so.6
+Files-Excluded-i386:
+ libs/libgcc_s.so.1
+ libs/libstdc++.so.6
 
 Files: *
 Copyright: 2002-2018 Tarn Adams. All rights reserved.
diff -Nru dwarf-fortress-0.44.12/debian/watch 
dwarf-fortress-0.44.12+dfsg1/debian/watch
--- dwarf-fortress-0.44.12/debian/watch 2018-06-24 13:22:23.0 +0200
+++ dwarf-fortress-0.44.12+dfsg1/debian/watch   2021-03-31 19:01:19.0 
+0200
@@ -1,7 +1,7 @@
 version=4
-opts="uversionmangle=s/^/0./,component=amd64" \
+opts="uversionmangle=s/^/0./,dversionmangle=s/\+dfsg\d+//,component=amd64" \
   http://bay12games.com/dwarves/older_versions.html \
   df_(\d+)_(\d+)_linux@ARCHIVE_EXT@ debian
-opts="uversionmangle=s/^/0./,component=i386" \
+opts="uversionmangle=s/^/0./,dversionmangle=s/\+dfsg\d+//,component=i386" \
   http://bay12games.com/dwarves/older_versions.html \
   df_(\d+)_(\d+)_linux32@ARCHIVE_EXT@ same
Binärdateien /tmp/OJJcX56xZH/dwarf-fortress-0.44.12/i386/libs/libgcc_s.so.1 und 
/tmp/JM3ObfSHmq/dwarf-fortress-0.44.12+dfsg1/i386/libs/libgcc_s.so.1 sind 
verschieden.
Binärdateien /tmp/OJJcX56xZH/dwarf-fortress-0.44.12/i386/libs/libstdc++.so.6 
und /tmp/JM3ObfSHmq/dwarf-fortress-0.44.12+dfsg1/i386/libs/libstdc++.so.6 sind 
verschieden.


Bug#986214: ircii: CVE-2021-29376

2021-03-31 Thread Salvatore Bonaccorso
Source: ircii
Version: 20190117-1
Severity: grave
Tags: security upstream
X-Debbugs-Cc: car...@debian.org, Debian Security Team 
Control: clone -1 -2
Control: reassign -2 src:scrollz 2.2.3-1
Control: retitle -2 scrollz: CVE-2021-29376

The following vulnerability was published for ircii.

CVE-2021-29376[0]:
| ircII before 20210314 allows remote attackers to cause a denial of
| service (segmentation fault and client crash, disconnecting the victim
| from an IRC server) via a crafted CTCP UTC message.


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-29376
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-29376
[1] https://www.openwall.com/lists/oss-security/2021/03/24/2

Regards,
Salvatore



Bug#986213: RM: ansible/2.9.16+dfsg-1.1

2021-03-31 Thread Sebastiaan Couwenberg
On 3/31/21 7:30 PM, Lee Garrett wrote:
> Unfortunately 2.10 didn't make it into bullseye in time (#984557). I tried
> getting the unit tests from 2.9.16 to work with python 3.9, but I had to give
> up. I don't feel comfortable with maintaining such a large package over the
> lifecycle of bullseye without unit tests, official py3.9 support, and security
> support running out in a few months, so please remove ansible from bullseye.

Shipping bullseye without ansible is going to make many users unhappy.

Will you actively maintain the package in bullseye-backports instead?

Kind Regards,

Bas

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



Bug#811361: libmount: provide extra package for pylibmount (Python bindings for libmount)

2021-03-31 Thread Andreas Henriksson
Hello Ludens (or anyone else interested in picking this up),

Thanks for the patch you submitted for adding a package with python3
bindings for libmount.

Beware: I'm by no means a python (packaging) expert, so anything I say
below might be completely wrong.

Some things you added in the `Package: python3-libmount` part
of debian/control looks possibly wrong to me:

> Package: python3-libmount
> Architecture: linux-any

Why linux-any? libmount1 is any. (Also I'm not sure when
python stuff can be all or any, but I guess any is correct
for something wrapping a c library).

> Section: libdevel

Shouldn't this be 'Section: python` ?

> Priority: optional
> Depends: libmount-dev (= ${binary:Version}),
>  libblkid-dev,
>  ${misc:Depends}

Depending on the -dev packages looks wrong to me. You likely want
to depend on the runtime packages like libmount1. Possibly
via some automatic variable like ${shlibs:Depends}, rather than
hard-coding the actual binary library packages.

Also shouldn't there be some python-related magic variable in
here as well?


> Multi-Arch: same

Are you sure?



FWIW Please open a merge-request against the util-linux packaging
git repo on salsa.debian.org/debian/util-linux for easier review!

Might also be useful to ask the debian-python lists to review
the changes, which should give extra confidence that your
packaging work follows debian python packaging best practices.

Regards,
Andreas Henriksson



Bug#950447: Document that persistent journal is now enabled in systemd

2021-03-31 Thread Andrei POPESCU
On Mi, 31 mar 21, 17:33:47, Justin B Rye wrote:
> Paul Gevers wrote:
> >> On 18-03-2021 11:41, Michael Biebl wrote:
> >>> Yes, the persistent journal is enabled on upgrades and new installations.
> >> 
> >> Thanks.
> >> 
> >>> I'm a bit uncertain, whether I should go into that much detail in the
> >>> release notes, especially wrt to rsyslog. But on the other hand, this
> >>> way our users are notified in advance that this change is coming.
> >> 
> >> I would say, keep it short. I.e. tell we change the default (it only the
> >> default, right?) on upgrades and how it can be disabled again.
> >
> > Did you already have inspiration? We can also try to write up something,
> > but I really appreciate it when maintainers do the initial proposal.
> 
> If nobody knowledgeable has had the time to come up with anything,
> maybe the version attached will inspire either improvements or just an
> urge to replace it with something completely different.
> 
> (The man page pointer should be enough that we don't also need to
> spell out a "disabling the journal HOWTO".)

> diff --git a/en/whats-new.dbk b/en/whats-new.dbk
> index 1e361e61..399e1977 100644
> --- a/en/whats-new.dbk
> +++ b/en/whats-new.dbk
> @@ -182,6 +182,23 @@ linkend="obsolete"/>.
>
>  
>  
> +
> +  Persistent systemd journal
> +  
> +Systemd in bullseye activates its persistent journal functionality
> +by default, storing its files in
> +/var/log/journal/. See  +
> url="/bullseye/systemd/journald.conf.5.html">journald.conf(5)
> +for details.

To me systemd-journald.service(8) seems like a better introduction.

It's probably also worth mentioning that on Debian the journal is 
readable by members of 'adm', in addition to the default 
'systemd-journal' group.

> +  
> +  
> +This should not interfere with any existing traditional logging
> +daemon such as rsyslog, but
> +users who are not relying on special features of such a daemon may
> +wish to uninstall it and switch over to using only the journal.
> +  
> +
> +
>  
>Desktops and well known packages
>  


Kind regards,
Andrei
-- 
http://wiki.debian.org/FAQsFromDebianUser


signature.asc
Description: PGP signature


Bug#983557: created merge-request for noudeb build-profile in util-linux

2021-03-31 Thread Andreas Henriksson
Control: forwarded -1 
https://salsa.debian.org/debian/util-linux/-/merge_requests/19

Hello,

I've created a merge-request on the util-linux git packaging repo
which should hopefully make it more convenient for the maintainer
to review this (once the freeze is over).

Regards,
Andreas Henriksson



Bug#986213: RM: ansible/2.9.16+dfsg-1.1

2021-03-31 Thread Lee Garrett
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: rm
X-Debbugs-Cc: deb...@rocketjump.eu

Hi,

Unfortunately 2.10 didn't make it into bullseye in time (#984557). I tried
getting the unit tests from 2.9.16 to work with python 3.9, but I had to give
up. I don't feel comfortable with maintaining such a large package over the
lifecycle of bullseye without unit tests, official py3.9 support, and security
support running out in a few months, so please remove ansible from bullseye.

Thanks in advance,
Lee



Bug#986212: pypy: Intermittent SIGILL and segv on armhf with Armada XP buildds

2021-03-31 Thread Stefano Rivera
Package: pypy
Version: 7.2.0~rc0+dfsg-1
Severity: normal
User: debian-...@lists.debian.org
Usertags: armhf
Control: affects -1 pypy3

Observable since 7.2.0~rc0+dfsg-1 we've seen occasional SIGILLs and SEGV
with pypy's armhf build running on Armada XP boards (arnold, hoiby,
hartmann, henze).

https://buildd.debian.org/status/logs.php?pkg=pypy=armhf
e.g. 
https://buildd.debian.org/status/fetch.php?pkg=pypy=armhf=7.2.0%7Erc0%2Bdfsg-1=1570119992=0

Reproduces at least 50% of the time on abel, the Armada XP porterbox.
This was an attempt to build pypy3 7.3.4~rc1+dfsg-1 with pypy 7.3.3+dfsg-1.

Core was generated by `pypy --jit loop_longevity=300 -u 
/home/stefanor/pypy3-7.3.4~rc1+dfsg/rpython/bi'.
Program terminated with signal SIGILL, Illegal instruction.
#0  0xb03fe3e0 in ?? ()
(gdb) bt
#0  0xb03fe3e0 in ?? ()
#1  0xb65f914c in ?? () from /usr/lib/pypy/bin/libpypy-c.so
Backtrace stopped: previous frame identical to this frame (corrupt stack?)
(gdb) info threads
  Id   Target Id Frame
* 1Thread 0xb6f8e010 (LWP 16596) 0xb03fe3e0 in ?? ()
(gdb) disas
No function contains program counter for selected frame.
(gdb) info registers
r0 0xb486f5bc  3028743612
r1 0x9 9
r2 0xb473a710  3027478288
r3 0xb66052ec  3059765996
r4 0x1e5ea00   31844864
r5 0xb486f6d4  3028743892
r6 0x0 0
r7 0xb486f714  3028743956
r8 0xb4750060  3027566688
r9 0xb486f6e4  3028743908
r100x1f31650   32708176
r110xb486f714  3028743956
r120x108   264
sp 0xbe91c748  0xbe91c748
lr 0xb65f914c  -1235250868
pc 0xb03fe3e0  0xb03fe3e0
cpsr   0xa0070010  -1610153968
fpscr  0x801d  -2147483619
(gdb) disas 0xb03fe3d0,+32
Dump of assembler code from 0xb03fe3d0 to 0xb03fe3f0:
   0xb03fe3d0:  bne 0xb03fe668
   0xb03fe3d4:  ldr r2, [pc, #-248] ; 0xb03fe2e4
   0xb03fe3d8:  ldr r2, [r2, #8]
   0xb03fe3dc:  cmp r2, #0
=> 0xb03fe3e0:  beq 0xb03fe688
   0xb03fe3e4:  ldr r2, [pc, #-256] ; 0xb03fe2ec
   0xb03fe3e8:  ldr r2, [r2, #8]
   0xb03fe3ec:  cmp r2, #0
End of assembler dump.
(gdb) x/32 0xb03fe3d0
0xb03fe3d0: 0x1aa4  0xe51f20f8  0xe5922008  0xe352
0xb03fe3e0: 0x0aa8  0xe51f2100  0xe5922008  0xe352
0xb03fe3f0: 0x0aac  0xe51f2108  0xe1520003  0x1ab1
0xb03fe400: 0xe300c114  0xe79b200c  0xe592400c  0xe594c004
0xb03fe410: 0xe30be4d8  0xe34be661  0xe15c000e  0x1ab1
0xb03fe420: 0xe5924008  0xe5949004  0xe2897001  0xe5946008
0xb03fe430: 0xe5966004  0xe1560007  0xe300c10c  0xe78b400c
0xb03fe440: 0xe30d42dd  0xe34b4535  0xe300c10c  0xe79b000c
(gdb) disas 0xb03fe688,+32
Dump of assembler code from 0xb03fe688 to 0xb03fe6a8:
   0xb03fe688:  ldr r12, [pc, #-936]; 0xb03fe2e8
   0xb03fe68c:  push{r12}   ; (str r12, [sp, #-4]!)
   0xb03fe690:  movwr12, #57916 ; 0xe23c
   0xb03fe694:  movtr12, #45119 ; 0xb03f
   0xb03fe698:  push{r12}   ; (str r12, [sp, #-4]!)
   0xb03fe69c:  movwr12, #0
   0xb03fe6a0:  movtr12, #45057 ; 0xb001
   0xb03fe6a4:  blx r12
End of assembler dump.

Seems like this is probably an issue with flushing the I-cache after generating
jit-code, but as far as I can see, pypy is doing the right thing, calling
__clear_cache after writing jit-code:
https://foss.heptapod.net/pypy/pypy/-/blob/release-pypy2.7-v7.3.4rc1/rpython/jit/backend/arm/codebuilder.py#L458

SR



Bug#982557: Merge request opened for bsdextrautils shlibs:Depends -> Depends

2021-03-31 Thread Andreas Henriksson
Control: forwarded -1 
https://salsa.debian.org/debian/util-linux/-/merge_requests/18

Hello,

I've opened a merge-request with the suggested changes which
should hopefully make it more convenient for maintainer
to review this (once the freeze is over).

Regards,
Andreas Henriksson



Bug#986211: pulseaudio: how default card profile is determined not documented

2021-03-31 Thread Arthur Marsh
Package: pulseaudio
Version: 14.2-2
Severity: normal
Tags: upstream

Dear Maintainer,

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

   * What led up to the situation?

Some unknown upgrade lead to me having to manually select audio profile on 
initial KDE plasma session after booting.


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

Tried the documented:

#set-default-sink output
#set-default-source input

   * What was the outcome of this action?

the set-default-sink output and set-default-source input did not work until I 
had manually set the audio profile in KDE plasma

   * What outcome did you expect instead?

What *DID* work was setting the desired profile in default.pa:

set-card-profile alsa_card.pci-_03_06.0 
output:analog-stereo+input:analog-mono

It was *NOT* clear from the documentation that the trailing colon ":" had to be 
removed from the profile name.

It would help immensely if the process of which profile was selected was 
documented, with instructions on how to change the start-up profile.

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


-- Package-specific info:
File '/etc/default/pulseaudio' does not exist


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

Kernel: Linux 5.12.0-rc5+ (SMP w/4 CPU threads)
Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.UTF-8 (charmap=UTF-8), LANGUAGE=en_GB
Shell: /bin/sh linked to /bin/bash
Init: sysvinit (via /sbin/init)

Versions of packages pulseaudio depends on:
ii  adduser  3.118
ii  init-system-helpers  1.60+devuan1
ii  libasound2   1.2.4-1.1
ii  libasound2-plugins   1.2.2-2
ii  libc62.31-10
ii  libcap2  1:2.44-1
ii  libdbus-1-3  1.12.20-2+devuan1
ii  libelogind0 [libsystemd0]246.10-2
ii  libeudev1 [libudev1] 3.2.9-9
ii  libgcc-s111-20210327-1
ii  libice6  2:1.0.10-1
ii  libltdl7 2.4.6-15
ii  liborc-0.4-0 1:0.4.32-1
ii  libpulse014.2-2
ii  libsm6   2:1.2.3-1
ii  libsndfile1  1.0.31-1
ii  libsoxr0 0.1.3-4
ii  libspeexdsp1 1.2~rc1.2-1.1
ii  libstdc++6   10.2.1-6
ii  libtdb1  1.4.3-1+b1
ii  libwebrtc-audio-processing1  0.3-1+b1
ii  libx11-6 2:1.7.0-2
ii  libx11-xcb1  2:1.7.0-2
ii  libxcb1  1.14-3
ii  libxtst6 2:1.2.3-1
ii  lsb-base 11.1.0
ii  pulseaudio-utils 14.2-2

Versions of packages pulseaudio recommends:
pn  dbus-user-session
ii  libpam-elogind [logind]  246.10-2
ii  rtkit0.13-4

Versions of packages pulseaudio suggests:
ii  eudev [udev]  3.2.9-9
pn  paprefs   
ii  pavucontrol   4.0-2
pn  pavumeter 

-- Configuration Files:
/etc/pulse/default.pa changed:
.fail
load-module module-device-restore
load-module module-stream-restore
load-module module-card-restore
load-module module-augment-properties
load-module module-switch-on-port-available
.ifexists module-udev-detect.so
load-module module-udev-detect
.else
load-module module-detect
.endif
.ifexists module-jackdbus-detect.so
.nofail
load-module module-jackdbus-detect channels=2
.fail
.endif
.ifexists module-bluetooth-policy.so
load-module module-bluetooth-policy
.endif
.ifexists module-bluetooth-discover.so
load-module module-bluetooth-discover
.endif
.ifexists module-esound-protocol-unix.so
load-module module-esound-protocol-unix
.endif
load-module module-native-protocol-unix
.ifexists module-gsettings.so
.nofail
load-module module-gsettings
.fail
.endif
load-module module-default-device-restore
load-module module-always-sink
load-module module-intended-roles
load-module module-suspend-on-idle
.ifexists module-console-kit.so
load-module module-console-kit
.endif
.ifexists module-systemd-login.so
load-module module-systemd-login
.endif
load-module module-position-event-sounds
load-module module-role-cork
load-module module-filter-heuristics
load-module module-filter-apply
set-card-profile alsa_card.pci-_03_06.0 
output:analog-stereo+input:analog-mono


-- no debconf information
# This file is part of PulseAudio.
#
# PulseAudio is free software; you can redistribute it and/or modify
# it under the terms of the GNU Lesser General Public License as published by
# the Free Software Foundation; either version 2 of the License, or
# (at your option) any later version.
#
# PulseAudio is distributed in the hope that it will be useful, but
# WITHOUT ANY WARRANTY; without even the implied warranty of
# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
# General Public License for more details.
#
# You should have received a copy of the GNU Lesser 

Bug#986206: qmake drops options passed from QMAKE_CXXFLAGS_RELEASE and QMAKE_CXXFLAGS_DEBUG

2021-03-31 Thread Dmitry Shachnev
Control: reassign -1 src:guymager 0.8.12-1
Control: severity -1 important

Hi Matthias!

On Wed, Mar 31, 2021 at 05:30:17PM +0200, Matthias Klose wrote:
> seen when building guymager, adding to the rules file:
>
> export DEB_CXXFLAGS_MAINT_APPEND = --param ggc-min-expand=0 --param
> ggc-min-heapsize=0
>
> The generated Makefile isn't correctly generated. The "# Command" line shows 
> the
> passed args, which are correct, however the "^CXXFLAGS" line shows that the
> flags are expanded twice, and the first time, the second --param option is
> omitted, but not the parameter following that option.

This happens because guymager.pro line 150 has this:

  QMAKE_CXXFLAGS *= $$system(dpkg-buildflags --get CXXFLAGS)

The *= operator is for adding unique values (as opposed to +=). The --param
flag appears twice, so it keeps only the first instance:

https://doc.qt.io/qt-5/qmake-language.html#adding-unique-values

You can use --param=ggc-min-expand=0 --param=ggc-min-heapsize=0, then there
will be no such problem.

Also there is no need at all to call dpkg-buildflags from the .pro file.
debhelper passes all needed flags via command line arguments.

> Feel free to reassign to guymager and lowering the severity, if that is not
> a generic qmake issue.

Doing so.

Dear guymager maintainer(s): please consider removing lines 150 and 151 from
guymager.pro, or at least replacing *= with +=.

--
Dmitry Shachnev



Bug#986210: unicode-cldr-core: Split the package?

2021-03-31 Thread Samuel Thibault
Package: unicode-cldr-core
Version: 32.0.1-1.1
Severity: normal

Hello,

I was requested to make brltty depend on unicode-cldr-core so as to get
the emoji pronunciations, but unicode-cldr-core is very large just for
that purpose. I guess it would make sense to split unicode-cldr-core
into unicode-cldr-{annotations,annotations-derived,bcp47,casing,
collation,dtd,main,properties,rbnf,segments,subdivisions,supplemental,
transforms,uca,validity}, so that brltty can just depend on
unicode-cldr-annotations (19MB)? Otherwise I'm afraid that actually most
other maintainers will also refrain from depending on unicode-cldr-core
simply due to its size, and the package lose its purpose of providing a
common cldr data source.

Samuel

-- System Information:
Debian Release: bullseye/sid
  APT prefers testing
  APT policy: (990, 'testing'), (500, 'unstable-debug'), (500, 
'testing-debug'), (500, 'stable-debug'), (500, 'proposed-updates-debug'), (500, 
'proposed-updates'), (500, 'oldoldstable'), (500, 'buildd-unstable'), (500, 
'unstable'), (500, 'stable'), (500, 'oldstable'), (1, 'experimental-debug'), 
(1, 'buildd-experimental'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.11.0 (SMP w/8 CPU threads)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.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

-- no debconf information



Bug#950447: Document that persistent journal is now enabled in systemd

2021-03-31 Thread Justin B Rye
Paul Gevers wrote:
>> On 18-03-2021 11:41, Michael Biebl wrote:
>>> Yes, the persistent journal is enabled on upgrades and new installations.
>> 
>> Thanks.
>> 
>>> I'm a bit uncertain, whether I should go into that much detail in the
>>> release notes, especially wrt to rsyslog. But on the other hand, this
>>> way our users are notified in advance that this change is coming.
>> 
>> I would say, keep it short. I.e. tell we change the default (it only the
>> default, right?) on upgrades and how it can be disabled again.
>
> Did you already have inspiration? We can also try to write up something,
> but I really appreciate it when maintainers do the initial proposal.

If nobody knowledgeable has had the time to come up with anything,
maybe the version attached will inspire either improvements or just an
urge to replace it with something completely different.

(The man page pointer should be enough that we don't also need to
spell out a "disabling the journal HOWTO".)
-- 
JBR with qualifications in linguistics, experience as a Debian
sysadmin, and probably no clue about this particular package
diff --git a/en/whats-new.dbk b/en/whats-new.dbk
index 1e361e61..399e1977 100644
--- a/en/whats-new.dbk
+++ b/en/whats-new.dbk
@@ -182,6 +182,23 @@ linkend="obsolete"/>.
   
 
 
+
+  Persistent systemd journal
+  
+Systemd in bullseye activates its persistent journal functionality
+by default, storing its files in
+/var/log/journal/. See journald.conf(5)
+for details.
+  
+  
+This should not interfere with any existing traditional logging
+daemon such as rsyslog, but
+users who are not relying on special features of such a daemon may
+wish to uninstall it and switch over to using only the journal.
+  
+
+
 
   Desktops and well known packages
 


Bug#986172: unblock: dwarf-fortress/0.47.04+dfsg1-1

2021-03-31 Thread Sven Bartscher
Control: tags -1 - moreinfo

Hi,

Am 31.03.21 um 09:55 schrieb Sebastian Ramacher:
> ACK, please remove the moreinfo tag once the new version is available in
> unstable.

0.47.04+dfsg1-1 has just been accepted into unstable.

Regards
Sven



Bug#986209: debian-cd: Please provide symlinks for stable, unstable, etc...

2021-03-31 Thread bauen1
Package: debian-cd
Version: 3.1.33
Severity: wishlist
X-Debbugs-Cc: j24...@gmail.com

Dear Maintainer,

While building my own CDs I've discovered that while most tools, e.g. 
debootstrap, allow using `unstable` / `sid` with the same results, debian-cd 
does not.
This could be handled by adding symlinks, like for sid, to data, tasks, 
tools/boot , thus allowing the user to specify CODENAME=unstable to build a sid 
installer cd.

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

Kernel: Linux 5.10.0-5-amd64 (SMP w/4 CPU threads)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) (ignored: LC_ALL 
set to en_US.UTF-8), LANGUAGE=en_US:en
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: SELinux: enabled - Mode: Enforcing - Policy name: bauen1-policy

Versions of packages debian-cd depends on:
ii  apt2.2.2
ii  bc 1.07.1-2+b2
ii  bzip2  1.0.8-4
ii  cpp4:10.2.1-1
ii  curl   7.74.0-1.1
ii  dctrl-tools [grep-dctrl]   2.24-3+b1
ii  dpkg-dev   1.20.7.1
ii  genisoimage9:1.1.11-3.2
pn  libcompress-zlib-perl  
pn  libdigest-md5-perl 
ii  libdpkg-perl   1.20.7.1
ii  lynx   2.9.0dev.6-2
ii  make   4.3-4
ii  perl [libdigest-sha-perl]  5.32.1-3
ii  tofrodos   1.7.13+ds-5
ii  wget   1.21-1+b1
ii  xorriso1.5.2-1

Versions of packages debian-cd recommends:
ii  dosfstools   4.2-1
ii  hfsutils 3.2.6-15
ii  isolinux 3:6.04~git20190206.bf6db5b4+dfsg1-3
ii  mtools   4.0.26-1
ii  netpbm   2:10.0-15.4
ii  syslinux-common  3:6.04~git20190206.bf6db5b4+dfsg1-3
ii  syslinux-utils   3:6.04~git20190206.bf6db5b4+dfsg1-3

debian-cd suggests no packages.

-- no debconf information



Bug#986208: wireless-regdb: Please update wireless-regdb to 2020-11-20

2021-03-31 Thread Amr Ibrahim
Package: wireless-regdb
Version: 2020.04.29-2
Severity: normal
X-Debbugs-Cc: amribrahim1...@hotmail.com

Dear Maintainer,

Please update wireless-regdb to 2020-11-20.

It has regulatory rules updates to countries that I care about: US, UK and 
Egypt.

It would be great to have it in Bullseye for the long-living Debian 11.


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

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

wireless-regdb depends on no packages.

wireless-regdb recommends no packages.

Versions of packages wireless-regdb suggests:
pn  crda  

-- no debconf information



Bug#986207: snapshot.debian.org: "debian-archive/.../debian-security/" is missing "wheezy"

2021-03-31 Thread Tianon Gravi
Package: snapshot.debian.org
Severity: normal

It would appear that archive.debian.org hasn't been snapshotted since
2019-03-28 10:54:44, but it has changed since then.  The notable change
that caused me to notice was that [0] seems to be missing wheezy, even
though [1] does include it (folder timestamp is 2019-03-31 19:18).

[0]: 
https://snapshot.debian.org/archive/debian-archive/20190328T105444Z/debian-security/dists/
[1]: http://archive.debian.org/debian-security/dists/

Any chance we could turn the wheels a little and get a newer snapshot of
archive.debian.org? O:)

Thank you for maintaining such an excellent service! :)

♥,
- Tianon
  4096R / B42F 6819 007F 00F8 8E36  4FD4 036A 9C25 BF35 7DD4


Bug#981422: xdg-utils: autopkgtest failure: make: dh: No such file or directory

2021-03-31 Thread Nicolas Boulenguez
Source: xdg-utils
Followup-For: Bug #981422

Hello
The attached commit suggests a third option.
If you call the scripts with an explicit interpreter,
they need no execution rights in the first place.
>From 5a48d85ad66d60e9be0085e98fdc6ab830cf2e9f Mon Sep 17 00:00:00 2001
From: Nicolas Boulenguez 
Date: Wed, 31 Mar 2021 17:05:29 +0200
Subject: autotests: in test-lib.sh, call tty{on,off} with an explicit
 interpreter

Explicit interpreters are usually discouraged so the calling code is
not broken by changes in the implementation, but in this case,
autotests/tty{on,off} are private helpers for autotests/test-lib.sh.

With an explicit interpreter, the scripts do not need execution rights.
Closes: #981422.

diff --git a/autotests/test-lib.sh b/autotests/test-lib.sh
index 87cab44..a16eb93 100644
--- a/autotests/test-lib.sh
+++ b/autotests/test-lib.sh
@@ -200,9 +200,9 @@ run() {
 
 local trace=
 if [ "$DETACH" = 0 ]; then
-trace="./ttyon"
+trace="/usr/bin/perl ttyon"
 elif [ "$DETACH" = 1 ]; then
-trace="./ttyoff"
+trace="/usr/bin/perl ttyoff"
 fi
 trace="$trace ${SHELL:-/bin/sh}"
 if [ "$TRACE" = 1 ]; then
diff --git a/autotests/ttyoff b/autotests/ttyoff
old mode 100755
new mode 100644
diff --git a/autotests/ttyon b/autotests/ttyon
old mode 100755
new mode 100644
diff --git a/debian/rules b/debian/rules
index 50c1d53..59b7c05 100755
--- a/debian/rules
+++ b/debian/rules
@@ -26,8 +26,6 @@ override_dh_auto_clean:
 
 override_dh_auto_test:
 ifeq (,$(filter nocheck,$(DEB_BUILD_OPTIONS)))
-# Fix perms of new files from the patch.
-   chmod +x autotests/ttyon autotests/ttyoff
 # Use automated tests that do not require a user action.
make autotest
 endif
diff --git a/debian/tests/entry b/debian/tests/entry
index 4c1e834..7ba19b7 100755
--- a/debian/tests/entry
+++ b/debian/tests/entry
@@ -13,6 +13,5 @@ fi
 BASH_XTRACEFD=1
 set -x
 
-debian/rules patch
 ./configure
 make autotest SHELL="${1:-/bin/sh}"


Bug#986171: underscore: CVE-2021-23358

2021-03-31 Thread Moritz Muehlenhoff
On Tue, Mar 30, 2021 at 11:00:00PM +0200, Yadd wrote:
> Le 30/03/2021 à 21:40, Salvatore Bonaccorso a écrit :
> > Source: underscore
> > Version: 1.9.1~dfsg-1
> > Severity: grave
> > Tags: security upstream
> > Justification: user security hole
> > X-Debbugs-Cc: car...@debian.org, Debian Security Team 
> > ,y...@debian.org
> > 
> > Hi,
> > 
> > The following vulnerability was published for underscore.
> > 
> > CVE-2021-23358[0]:
> > | The package underscore from 1.13.0-0 and before 1.13.0-2, from 1.3.2
> > | and before 1.12.1 are vulnerable to Arbitrary Code Execution via the
> > | template function, particularly when a variable property is passed as
> > | an argument as it is not sanitized.
> > 
> > [1] provides a POC to verify the issue.
> > 
> > 
> > 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-23358
> > https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-23358
> > [1] https://snyk.io/vuln/SNYK-JS-UNDERSCORE-1080984
> > 
> > Regards,
> > Salvatore
> 
> Hi,
> 
> here is a debdiff for buster including:
>  * backport of upstream patch
>  * autopkgtest file (tested)

Hi,
looks good! Please upload to security-master

Cheers,
Moritz



Bug#986206: qmake drops options passed from QMAKE_CXXFLAGS_RELEASE and QMAKE_CXXFLAGS_DEBUG

2021-03-31 Thread Matthias Klose
Package: qt5-qmake
Version: 5.15.2+dfsg-5
Severity: serious
Tags: sid bullseye

seen when building guymager, adding to the rules file:

export DEB_CXXFLAGS_MAINT_APPEND = --param ggc-min-expand=0 --param
ggc-min-heapsize=0


The generated Makefile isn't correctly generated. The "# Command" line shows the
passed args, which are correct, however the "^CXXFLAGS" line shows that the
flags are expanded twice, and the first time, the second --param option is
omitted, but not the parameter following that option.

Feel free to reassign to guymager and lowering the severity, if that is not a
generic qmake issue.


$ fgrep -- --param Makefile
# Command: /usr/lib/qt5/bin/qmake -o Makefile guymager.pro
'QMAKE_CFLAGS_RELEASE=-g -O2 -ffile-prefix-map=/packages/tmp/guymager-0.8.12=.
-fstack-protector-strong -Wformat -Werror=format-security -Wdate-time
-D_FORTIFY_SOURCE=2' 'QMAKE_CFLAGS_DEBUG=-g -O2
-ffile-prefix-map=/packages/tmp/guymager-0.8.12=. -fstack-protector-strong
-Wformat -Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2'
'QMAKE_CXXFLAGS_RELEASE=-g -O2 -ffile-prefix-map=/packages/tmp/guymager-0.8.12=.
-fstack-protector-strong -Wformat -Werror=format-security --param
ggc-min-expand=0 --param ggc-min-heapsize=0 -Wdate-time -D_FORTIFY_SOURCE=2'
'QMAKE_CXXFLAGS_DEBUG=-g -O2 -ffile-prefix-map=/packages/tmp/guymager-0.8.12=.
-fstack-protector-strong -Wformat -Werror=format-security --param
ggc-min-expand=0 --param ggc-min-heapsize=0 -Wdate-time -D_FORTIFY_SOURCE=2'
QMAKE_LFLAGS_RELEASE=-Wl,-z,relro QMAKE_LFLAGS_DEBUG=-Wl,-z,relro QMAKE_STRIP=:
PREFIX=/usr 'DEFINES+=SPLASH_DIR=\'\''\"/usr/share/guymager\"\'\''
LANGUAGE_DIR=\'\''\"/usr/share/guymager\"\'\''
LANGUAGE_DIR_QT=\'\''\"/usr/share/qt5/translations\"\'\'''
CXXFLAGS  = -pipe -g -O2 -ffile-prefix-map=/packages/tmp/guymager-0.8.12=.
-fstack-protector-strong -Wformat -Werror=format-security --param
ggc-min-expand=0 ggc-min-heapsize=0 -fmessage-length=0 -fno-strict-aliasing
-flto -g -ffile-prefix-map=/packages/tmp/guymager-0.8.12=.
-fstack-protector-strong -Wformat -Werror=format-security --param
ggc-min-expand=0 --param ggc-min-heapsize=0 -Wdate-time -D_FORTIFY_SOURCE=2 -O3
-ggdb -std=gnu++1y -Wall -Wextra -D_REENTRANT -fPIC $(DEFINES)
$(QMAKE) -o Makefile guymager.pro 'QMAKE_CFLAGS_RELEASE=-g -O2
-ffile-prefix-map=/packages/tmp/guymager-0.8.12=. -fstack-protector-strong
-Wformat -Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2'
'QMAKE_CFLAGS_DEBUG=-g -O2 -ffile-prefix-map=/packages/tmp/guymager-0.8.12=.
-fstack-protector-strong -Wformat -Werror=format-security -Wdate-time
-D_FORTIFY_SOURCE=2' 'QMAKE_CXXFLAGS_RELEASE=-g -O2
-ffile-prefix-map=/packages/tmp/guymager-0.8.12=. -fstack-protector-strong
-Wformat -Werror=format-security --param ggc-min-expand=0 --param
ggc-min-heapsize=0 -Wdate-time -D_FORTIFY_SOURCE=2' 'QMAKE_CXXFLAGS_DEBUG=-g -O2
-ffile-prefix-map=/packages/tmp/guymager-0.8.12=. -fstack-protector-strong
-Wformat -Werror=format-security --param ggc-min-expand=0 --param
ggc-min-heapsize=0 -Wdate-time -D_FORTIFY_SOURCE=2'
QMAKE_LFLAGS_RELEASE=-Wl,-z,relro QMAKE_LFLAGS_DEBUG=-Wl,-z,relro QMAKE_STRIP=:
PREFIX=/usr 'DEFINES+=SPLASH_DIR=\'\''\"/usr/share/guymager\"\'\''
LANGUAGE_DIR=\'\''\"/usr/share/guymager\"\'\''
LANGUAGE_DIR_QT=\'\''\"/usr/share/qt5/translations\"\'\'''
@$(QMAKE) -o Makefile guymager.pro 'QMAKE_CFLAGS_RELEASE=-g -O2
-ffile-prefix-map=/packages/tmp/guymager-0.8.12=. -fstack-protector-strong
-Wformat -Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2'
'QMAKE_CFLAGS_DEBUG=-g -O2 -ffile-prefix-map=/packages/tmp/guymager-0.8.12=.
-fstack-protector-strong -Wformat -Werror=format-security -Wdate-time
-D_FORTIFY_SOURCE=2' 'QMAKE_CXXFLAGS_RELEASE=-g -O2
-ffile-prefix-map=/packages/tmp/guymager-0.8.12=. -fstack-protector-strong
-Wformat -Werror=format-security --param ggc-min-expand=0 --param
ggc-min-heapsize=0 -Wdate-time -D_FORTIFY_SOURCE=2' 'QMAKE_CXXFLAGS_DEBUG=-g -O2
-ffile-prefix-map=/packages/tmp/guymager-0.8.12=. -fstack-protector-strong
-Wformat -Werror=format-security --param ggc-min-expand=0 --param
ggc-min-heapsize=0 -Wdate-time -D_FORTIFY_SOURCE=2'
QMAKE_LFLAGS_RELEASE=-Wl,-z,relro QMAKE_LFLAGS_DEBUG=-Wl,-z,relro QMAKE_STRIP=:
PREFIX=/usr 'DEFINES+=SPLASH_DIR=\'\''\"/usr/share/guymager\"\'\''
LANGUAGE_DIR=\'\''\"/usr/share/guymager\"\'\''
LANGUAGE_DIR_QT=\'\''\"/usr/share/qt5/translations\"\'\'''
g++ -pipe -g -O2 -ffile-prefix-map=/packages/tmp/guymager-0.8.12=.
-fstack-protector-strong -Wformat -Werror=format-security --param
ggc-min-expand=0 ggc-min-heapsize=0 -fmessage-length=0 -fno-strict-aliasing
-flto -g -ffile-prefix-map=/packages/tmp/guymager-0.8.12=.
-fstack-protector-strong -Wformat -Werror=format-security --param
ggc-min-expand=0 --param ggc-min-heapsize=0 -Wdate-time -D_FORTIFY_SOURCE=2 -O3
-ggdb -std=gnu++1y -Wall -Wextra -dM -E -o moc/moc_predefs.h
/usr/lib/x86_64-linux-gnu/qt5/mkspecs/features/data/dummy.cpp



Bug#983478: FAM and other arch/kernels

2021-03-31 Thread PICCORO McKAY Lenz
El mié, 31 de mar. de 2021 a la(s) 09:08,
 escribió:
>
> On Wed, Mar 31, 2021 at 08:30:24AM -0400, PICCORO McKAY Lenz wrote:
> > linux is so popular (wh ugh) today.. but only for enterprices.. i do
> > not see any help for normal users that wants more freedom .. sad and
> > oscure!
>
> Please go away troll.
Lest make omise case of some non usefull "please do" guys.. .. but i'm
aware of the alternatives on lighttpd cos its my default wegbserver in
ALL my services

FAM was removed from almost all of the today's software including
COURIER or lighttpd

my point is not about that .. is about real collaboration.. we cannot
change things that can interfere with the work of others.. of course i
taking FAM as a vage example .. but we need more interchange of
information when we made changes.. THANKS to all for effors and Markus
to improve the courier package , you was so flexible about the last
days: listening ! AS MUST BE!



Bug#986205: RFS: python-cleo/0.8.1-1 [ITP] -- create beautiful and testable command-line interfaces

2021-03-31 Thread Emmanuel Arias
Package: sponsorship-requests
Severity: wishlist
X-Debbugs-Cc: debian-pyt...@lists.debian.org

Dear mentors,

I am looking for a sponsor for my package "python-cleo":

 * Package name: python-cleo
   Version : 0.8.1-1
   Upstream Author : Sébastien Eustace 
 * URL : https://github.com/sdispater/cleo
 * License : expat
 * Vcs :
https://salsa.debian.org/python-team/packages/python-cleo
   Section : python

It builds those binary packages:

  python-cleo-doc - create beautiful and testable command-line interfaces
(documentation)
  python3-cleo - create beautiful and testable command-line interfaces

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

  https://mentors.debian.net/package/python-cleo/

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

  dget -x
https://mentors.debian.net/debian/pool/main/p/python-cleo/python-cleo_0.8.1-1.dsc

Changes for the initial release:

 python-cleo (0.8.1-1) unstable; urgency=medium
 .
   * Initial release (Closes: #958366)

Regards,
-- 
  Emmanuel Arias


Bug#986204: ITP: molecule -- aiding the development and testing of Ansible roles

2021-03-31 Thread Sakirnth Nagarasa
Package: wnpp
Severity: wishlist
Owner: Sakirnth Nagarasa 

* Package name: molecule
  Upstream Author : Cisco Systems, Inc. and Red Hat, Inc.
* URL : https://github.com/ansible-community/molecule
* License : MIT
  Description : aiding the development and testing of Ansible roles

 Molecule provides support for testing with multiple instances,
operating systems and distributions, virtualization providers, test
frameworks and testing scenarios.

Greetings,
Sakirnth (Saki)



Bug#986143: openstack-dashboard: fails to upgrade from 'buster': KeyError: 'django' in "/usr/lib/python3/dist-packages/django/template/utils.py", line 65

2021-03-31 Thread Andreas Beckmann

Control: reassign -1 python3-novaclient 2:17.2.1-2
Control: affects -1 + openstack-dashboard

On 31/03/2021 13.48, Thomas Goirand wrote:

Does this mean that I should add a Breaks: python3-django-horizon in
python3-novaclient?


A
  Breaks: python3-django-horizon (<< 3:18.6.2)
(is that the correct package and version?)
added to python3-novaclient seems to work against that failure 
(python3-novaclient is no longer part of the packages being upgraded by 
'apt-get upgrade').


But then we are back to the font-awesome issue... looks like we need a 
Breaks there as well. (I'll continue this discussion in #983853)


Andreas



Bug#983478: FAM and other arch/kernels

2021-03-31 Thread gs-debian . org
On Wed, Mar 31, 2021 at 08:30:24AM -0400, PICCORO McKAY Lenz wrote:
> linux is so popular (wh ugh) today.. but only for enterprices.. i do
> not see any help for normal users that wants more freedom .. sad and
> oscure!

Please go away troll.

Your language is inappropriate and you are clearly uninformed on this
topic.  gamin supports kqueue on FreeBSD and inotify on Linux.

For cross-platform servers such as lighttpd, multiple file system
monitoring alternatives are implemented for portability.  The default
stat cache in lighttpd does not use FAM or gamin or inotify or kqueue,
and in the most common use-case of infrequently-modified files, the
default in lighttpd is often faster than with the added overhead of
file system monitoring.

Please go away troll.  I will not respond to you further here.
This is not an invitation to defend your gross hyperbole.  Just go away.



Bug#986175: unblock: underscore/1.9.1~dfsg-2

2021-03-31 Thread Yadd
Control: tags -1 - moreinfo

Le 31/03/2021 à 09:52, Sebastian Ramacher a écrit :
> Control: tags -1 moreinfo
> 
> On 2021-03-30 22:49:43, Yadd wrote:
>> Package: release.debian.org
>> Severity: normal
>> User: release.debian@packages.debian.org
>> Usertags: unblock
>> X-Debbugs-Cc: pkg-javascript-de...@lists.alioth.debian.org
>>
>> Please unblock package underscore
>>
>> [ Reason ]
>> underscore is vulnerable to arbitrary code execution (#986171,
>> CVE-2021-23358)
>>
>> [ Impact ]
>> CVE provided a PoC to prove arbitrary code execution
>>
>> [ Tests ]
>> I added a test to prove that bug is fixed (based on PoC). Test fails
>> with 1.9.1~dfsg-1 and passes with 1.9.1~dfsg-2
>>
>> [ Risks ]
>> Patch is trivial. Note: I imported also Janitor changes: this breaks
>> nothing
> 
> The patch looks fine, but please upload a version without the janitor
> changes. It's too late for those changes and they can wait for bookworm.
> 
> Cheers

Hi,

thanks, done in version 1.9.1~dfsg-3

Cheers,
Yadd
diff --git a/debian/changelog b/debian/changelog
index 02cd807..3936261 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,33 @@
+underscore (1.9.1~dfsg-3) unstable; urgency=medium
+
+  * Team upload
+  * Revert Janitor changes as required by release team (#986175)
+
+ -- Yadd   Wed, 31 Mar 2021 14:21:21 +0200
+
+underscore (1.9.1~dfsg-2) unstable; urgency=medium
+
+  * Team upload
+
+  [ Debian Janitor ]
+  * Bump debhelper dependency to >= 9, since that's what is used in
+debian/compat.
+  * Bump debhelper from old 9 to 12.
+  * Set debhelper-compat version in Build-Depends.
+  * Set upstream metadata fields: Bug-Database, Repository, Repository-
+Browse.
+  * Update standards version to 4.4.1, no changes needed.
+  * Set upstream metadata fields: Bug-Submit.
+  * Update standards version to 4.5.0, no changes needed.
+  * Apply multi-arch hints.
++ node-underscore: Add Multi-Arch: foreign.
+
+  [ Yadd ]
+  * Mark autopkgtest as superficial
+  * Fix arbitrary code execution and add a test (Closes: #986171)
+
+ -- Yadd   Tue, 30 Mar 2021 22:40:59 +0200
+
 underscore (1.9.1~dfsg-1) unstable; urgency=medium
 
   [ upstream ]
diff --git a/debian/patches/CVE-2021-23358.patch 
b/debian/patches/CVE-2021-23358.patch
new file mode 100644
index 000..2ba4118
--- /dev/null
+++ b/debian/patches/CVE-2021-23358.patch
@@ -0,0 +1,62 @@
+Description: fix arbitrary code execution
+Author: Julian Gonggrijp 
+Origin: upstream, https://github.com/jashkenas/underscore/commit/4c73526d
+Bug: https://snyk.io/vuln/SNYK-JS-UNDERSCORE-1080984
+Bug-Debian: https://bugs.debian.org/986171
+Forwarded: not-needed
+Reviewed-By: Xavier Guimard 
+Last-Update: 2021-03-30
+
+--- a/underscore.js
 b/underscore.js
+@@ -1550,6 +1550,13 @@
+ return '\\' + escapes[match];
+   };
+ 
++  // In order to prevent third-party code injection through
++  // `_.templateSettings.variable`, we test it against the following regular
++  // expression. It is intentionally a bit more liberal than just matching 
valid
++  // identifiers, but still prevents possible loopholes through defaults or
++  // destructuring assignment.
++  var bareIdentifier = /^\s*(\w|\$)+\s*$/;
++
+   // JavaScript micro-templating, similar to John Resig's implementation.
+   // Underscore templating handles arbitrary delimiters, preserves whitespace,
+   // and correctly escapes quotes within interpolated code.
+@@ -1585,8 +1592,17 @@
+ });
+ source += "';\n";
+ 
+-// If a variable is not specified, place data values in local scope.
+-if (!settings.variable) source = 'with(obj||{}){\n' + source + '}\n';
++var argument = settings.variable;
++if (argument) {
++  // Insure against third-party code injection.
++  if (!bareIdentifier.test(argument)) throw new Error(
++'variable is not a bare identifier: ' + argument
++  );
++} else {
++  // If a variable is not specified, place data values in local scope.
++  source = 'with(obj||{}){\n' + source + '}\n';
++  argument = 'obj';
++}
+ 
+ source = "var __t,__p='',__j=Array.prototype.join," +
+   "print=function(){__p+=__j.call(arguments,'');};\n" +
+@@ -1594,7 +1610,7 @@
+ 
+ var render;
+ try {
+-  render = new Function(settings.variable || 'obj', '_', source);
++  render = new Function(argument, '_', source);
+ } catch (e) {
+   e.source = source;
+   throw e;
+@@ -1605,7 +1621,6 @@
+ };
+ 
+ // Provide the compiled source as a convenience for precompilation.
+-var argument = settings.variable || 'obj';
+ template.source = 'function(' + argument + '){\n' + source + '}';
+ 
+ return template;
diff --git a/debian/patches/series b/debian/patches/series
index da362d2..7ddac86 100644
--- a/debian/patches/series
+++ b/debian/patches/series
@@ -1 +1,2 @@
 2001_docs_privacy.patch
+CVE-2021-23358.patch
diff --git a/debian/tests/CVE-2021-23358 b/debian/tests/CVE-2021-23358
new file mode 100755
index 000..a2ae590

Bug#983478: FAM and other arch/kernels

2021-03-31 Thread PICCORO McKAY Lenz
I have reading the wiki page
https://wiki.debian.org/SupportedArchitectures and noted that debian
drop some time ago the "universal" in their tittle.. just by this kind
of SH*T (like systemd and removal of fam by gammon -> so linux only
here)

my point is that collaboration is D R O P P E D for others.. by
preferences on gamin/shitsemd those arches are more close to the abyss
.. well all the non-linux arches are "unnofficial" just after becomes
official release in wheezy..

>Given courier-imap had several issues in the past with FAM (see #357769,
>#578937, #599682), I think it's actually safer to just depend on (and
>build against) gamin, instead.  I certainly run courier-imap on gamin
>exclusively on my systems.

lighttpd and courier of course works with gamin but of course this
change does not help others mantainers.. i runs kfreebsd in one laptop
difficulty due all of those changes..

linux is so popular (wh ugh) today.. but only for enterprices.. i do
not see any help for normal users that wants more freedom .. sad and
oscure!

Lenz McKAY Gerardo (PICCORO)
http://qgqlochekone.blogspot.com



Bug#810890: Packaging caddyserver-certmagic

2021-03-31 Thread sumeet
On Wed, 17 Mar 2021 13:45:20 +0100 Zlatan Todoric 
wrote:
> Hi,
> 
> On 3/17/21 07:04, SECOB271_Ganesh Pawar wrote:
> > Hey there!
> >
> > I would like to package and maintain caddyserver's certmagic
package 
> > if you allow me to. I would like to ultimately package the caddy
server.
> 
> Yes, see the other comments on this bug (thread) and coordinate the
work 
> with them.
> 
> Z
> 
> 
> 

Hello, I want to know whether if this idea is open for GSoC 2021?

GSoC idea page:
https://wiki.debian.org/SummerOfCode2021/ApprovedProjects/PackagingCaddy



Bug#986173: new upstream (14.2.19)

2021-03-31 Thread Bernd Zeimetz
Hi,

that was discussed with the security and release team and point releases should 
be accepted. Please remind me to forward the mails.


Bernd

31.03.2021 13:57:14 Thomas Goirand :

> On 3/30/21 10:32 PM, Daniel Baumann wrote:
>> Package: ceph
>> Severity: important
>> 
>> Hi,
>> 
>> 14.2.19 just got released, announcement says:
>> 
>> ---snip---
>> This is a hotfix release to prevent daemons from binding to loopback
>> network interfaces. All nautilus users are advised to upgrade to this
>> release.
>> 
>> [...]
>> 
>> This release fixes a regression introduced in v14.2.18 whereby in
>> certain environments, OSDs will bind to 127.0.0.1.  See
>> https://tracker.ceph.com/issues/49938.
>> ---snap---
>> 
>> it would be nice if this makes it to the archive soon.
>> 
>> Regards,
>> Daniel
> 
> Hi Daniel,
> 
> Well, this patch:
> 
> https://github.com/ceph/ceph/commit/89321762ad4cfdd1a68cae467181bdd1a501f14d
> 
> was made by me, because otherwise, it's impossible to run Ceph on a
> bgp-to-the-host setup. So, if we're reverting this patch, I see this as
> a regression, rather than an improvement.
> 
> Also, I've posted an unblock request to the release team, and the
> debdiff was 13 MB big. You know what's happening next, don't you? The
> release team claims they can't review such big change, and refuses. What
> do you suggest I do then?
> 
> Do you see a way forward?
> 
> Cheers,
> 
> Thomas Goirand (zigo)



Bug#986192: gimp: refuses to run with LittleCMS 2.9, thinks 2.9 < 2.2

2021-03-31 Thread Lionel Élie Mamane
On Wed, Mar 31, 2021 at 12:26:44PM +0200, Lionel Elie Mamane wrote:

> Gimp refuses to start with LittleCMS 2.9 installed, saying it needs
> "LittleCMS version at least 2.2". It seems to mistakenly believe 2.9
> is not "at least 2.2".

This is while its dependency is actually on LittleCMS 2.9...

Upgrading to 2.12~rc1-2 solves the issue, but this shows that the
error message, as well as the dependency, are wrong.

The dependency being wrong could be a duplicate of bug#900819;
however, the error message is still probably wrong referring to 2.2,
and that's a different bug.



Bug#986173: new upstream (14.2.19)

2021-03-31 Thread Thomas Goirand
On 3/30/21 10:32 PM, Daniel Baumann wrote:
> Package: ceph
> Severity: important
> 
> Hi,
> 
> 14.2.19 just got released, announcement says:
> 
> ---snip---
> This is a hotfix release to prevent daemons from binding to loopback
> network interfaces. All nautilus users are advised to upgrade to this
> release.
> 
> [...]
> 
> This release fixes a regression introduced in v14.2.18 whereby in
> certain environments, OSDs will bind to 127.0.0.1.  See
> https://tracker.ceph.com/issues/49938.
> ---snap---
> 
> it would be nice if this makes it to the archive soon.
> 
> Regards,
> Daniel

Hi Daniel,

Well, this patch:

https://github.com/ceph/ceph/commit/89321762ad4cfdd1a68cae467181bdd1a501f14d

was made by me, because otherwise, it's impossible to run Ceph on a
bgp-to-the-host setup. So, if we're reverting this patch, I see this as
a regression, rather than an improvement.

Also, I've posted an unblock request to the release team, and the
debdiff was 13 MB big. You know what's happening next, don't you? The
release team claims they can't review such big change, and refuses. What
do you suggest I do then?

Do you see a way forward?

Cheers,

Thomas Goirand (zigo)



Bug#986203: bustools: Please provide autopkgtest

2021-03-31 Thread Nilesh Patra
Package: bustools
Version: 0.40.0-4
Severity: wishlist
X-Debbugs-Cc: nil...@debian.org

Dear Maintainer,

Please provide autopkgtest for this package.

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

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

Versions of packages bustools depends on:
ii  libc6   2.31-3
ii  libgcc-s1   10.1.0-6
ii  libstdc++6  10.1.0-6
ii  zlib1g  1:1.2.11.dfsg-2

bustools recommends no packages.

bustools suggests no packages.



Bug#986143: openstack-dashboard: fails to upgrade from 'buster': KeyError: 'django' in "/usr/lib/python3/dist-packages/django/template/utils.py", line 65

2021-03-31 Thread Thomas Goirand
On 3/30/21 11:48 PM, Andreas Beckmann wrote:
> On 30/03/2021 17.33, Thomas Goirand wrote:
>> Ah, sh**... What do you suggest then? (even: what do you suggest I test
>> in a VM...)
> 
> I just tried all packages involved in the failed upgrade one by one and
> activated the openstack-dashboard trigger after each one.
> 
> python3-novaclient is our culprit.
> 
> Use a buster chroot with openstack-dashboard and install
> python3-novaclient/bullseye to reproduce.
> 
> Andreas

Hi Andreas,

Thanks for taking the time to investigate.

Does this mean that I should add a Breaks: python3-django-horizon in
python3-novaclient?

Cheers,

Thomas Goirand (zigo)



Bug#986202: ITP: nextcloud-notify-push -- Nextcloud push notification server

2021-03-31 Thread Jonas Meurer
Package: wnpp
Severity: wishlist
Owner: Jonas Meurer 
X-Debbugs-Cc: debian-de...@lists.debian.org

* Package name: nextcloud-notify-push
  Version : 0.1.6
  Upstream Author : Robin Appelman 
* URL : https://github.com/nextcloud/notify_push
* License : AGPL
  Programming Lang: Rust
  Description : Nextcloud push notification server

Nextcloud notify-push attempts to solve the issue where Nextcloud clients
have to periodically check the server if any files have been changed.
In order to keep sync snappy, clients wants to check for updates often,
which increases the load on the server.
.
By providing a way for the server to send update notifications to the
clients, the need for the clients to make these checks can be greatly
reduced.
.
This package contains the notify-push server.



Bug#986200: sift: Please provide autopkgtest

2021-03-31 Thread Nilesh Patra
Package: sift
Version: 4.0.3b-6
Severity: wishlist
X-Debbugs-Cc: nil...@debian.org

Dear Maintainer,

Please provide autopkgtest for this package.

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

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

Versions of packages sift depends on:
pn  blimps-utils  
pn  csh   
pn  libblimps3
ii  libc6 2.31-3

sift recommends no packages.

sift suggests no packages.



Bug#986201: fsm-lite: Please provide autopkgtest

2021-03-31 Thread Nilesh Patra
Package: fsm-lite
Version: Please provide autopkgtest
Severity: wishlist
X-Debbugs-Cc: nil...@debian.org

Dear Maintainer,


Please provide autopkgtest for this package.

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

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

Versions of packages fsm-lite depends on:
ii  libc6   2.31-3
pn  libdivsufsort3  
ii  libgcc-s1   10.1.0-6
pn  libsdsl3
ii  libstdc++6  10.1.0-6

fsm-lite recommends no packages.

fsm-lite suggests no packages.



Bug#986199: unblock: python-oslo.cache/2.6.2-1

2021-03-31 Thread Thomas Goirand
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock

Please unblock package python-oslo.cache

This new release adds support for pymemcache, which was by
the way already available in the relevant backend driver,
here, dogpile.cache.

The relevant part of upstream code is just this:

+if dogpile.__version__ >= '1.1.2':
+_backend_choices.append('dogpile.cache.pymemcache')

the rest of the debdiff is just distraction.

Please unblock python-oslo.cache/2.6.2-1.

Cheers,

Thomas Goirand (zigo)
diff -Nru python-oslo.cache-2.6.1/debian/changelog 
python-oslo.cache-2.6.2/debian/changelog
--- python-oslo.cache-2.6.1/debian/changelog2020-10-15 23:00:34.0 
+0200
+++ python-oslo.cache-2.6.2/debian/changelog2021-03-31 13:34:14.0 
+0200
@@ -1,3 +1,9 @@
+python-oslo.cache (2.6.2-1) unstable; urgency=medium
+
+  * New upstream release.
+
+ -- Thomas Goirand   Wed, 31 Mar 2021 13:34:14 +0200
+
 python-oslo.cache (2.6.1-2) unstable; urgency=medium
 
   * Uploading to unstable.
diff -Nru python-oslo.cache-2.6.1/.gitreview python-oslo.cache-2.6.2/.gitreview
--- python-oslo.cache-2.6.1/.gitreview  2020-08-25 14:01:17.0 +0200
+++ python-oslo.cache-2.6.2/.gitreview  2021-02-09 14:18:20.0 +0100
@@ -2,3 +2,4 @@
 host=review.opendev.org
 port=29418
 project=openstack/oslo.cache.git
+defaultbranch=stable/victoria
diff -Nru python-oslo.cache-2.6.1/lower-constraints.txt 
python-oslo.cache-2.6.2/lower-constraints.txt
--- python-oslo.cache-2.6.1/lower-constraints.txt   2020-08-25 
14:01:17.0 +0200
+++ python-oslo.cache-2.6.2/lower-constraints.txt   1970-01-01 
01:00:00.0 +0100
@@ -1,65 +0,0 @@
-appdirs==1.4.3
-certifi==2018.1.18
-cffi==1.13.1
-chardet==3.0.4
-cliff==3.1.0
-cmd2==0.8.9
-debtcollector==2.1.0
-decorator==4.4.2
-dogpile.cache==1.0.2
-entrypoints==0.3
-etcd3gw==0.2.0
-extras==1.0.0
-fixtures==3.0.0
-future==0.18.2
-futurist==2.2.0
-gitdb2==2.0.3
-GitPython==2.1.8
-idna==2.6
-iso8601==0.1.12
-keystoneauth1==3.4.0
-linecache2==1.0.0
-mock==4.0.2
-mox3==0.25.0
-msgpack==1.0.0
-netaddr==0.7.19
-netifaces==0.10.9
-os-client-config==1.29.0
-oslo.config==8.1.0
-oslo.context==3.1.0
-oslo.i18n==5.0.0
-oslo.log==4.2.1
-oslo.serialization==3.2.0
-oslo.utils==4.2.0
-oslotest==3.2.0
-pbr==3.1.1
-pifpaf==0.10.0
-prettytable==0.7.2
-pycparser==2.18
-pyinotify==0.9.6
-pymongo==3.0.2
-pyparsing==2.2.0
-pyperclip==1.8.0
-python-binary-memcached==0.29.0
-python-dateutil==2.8.1
-python-memcached==1.56
-python-mimeparse==1.6.0
-python-subunit==1.2.0
-pytz==2020.1
-PyYAML==3.12
-requests==2.18.4
-requestsexceptions==1.4.0
-rfc3986==1.4.0
-six==1.11.0
-smmap2==2.0.3
-stestr==2.0.0
-stevedore==1.28.0
-testrepository==0.0.20
-testtools==2.3.0
-traceback2==1.4.0
-unittest2==1.1.0
-urllib3==1.22
-voluptuous==0.11.7
-wcwidth==0.2.4
-wrapt==1.12.1
-xattr==0.9.3
diff -Nru python-oslo.cache-2.6.1/oslo_cache/_opts.py 
python-oslo.cache-2.6.2/oslo_cache/_opts.py
--- python-oslo.cache-2.6.1/oslo_cache/_opts.py 2020-08-25 14:01:17.0 
+0200
+++ python-oslo.cache-2.6.2/oslo_cache/_opts.py 2021-02-09 14:18:20.0 
+0100
@@ -12,11 +12,34 @@
 # License for the specific language governing permissions and limitations
 # under the License.
 
+import dogpile
+
 from oslo_config import cfg
 
 
 _DEFAULT_BACKEND = 'dogpile.cache.null'
 
+_backend_choices = [
+'oslo_cache.memcache_pool',
+'oslo_cache.dict',
+'oslo_cache.mongo',
+'oslo_cache.etcd3gw',
+'dogpile.cache.memcached',
+'dogpile.cache.pylibmc',
+'dogpile.cache.bmemcached',
+'dogpile.cache.dbm',
+'dogpile.cache.redis',
+'dogpile.cache.memory',
+'dogpile.cache.memory_pickle',
+'dogpile.cache.null'
+]
+
+# NOTE(moguimar): dogpile.cache.pymemcache is currently the best
+# driver for using Memcached with TLS. This backport is intent for
+# security purposes.
+if dogpile.__version__ >= '1.1.2':
+_backend_choices.append('dogpile.cache.pymemcache')
+
 FILE_OPTIONS = {
 'cache': [
 cfg.StrOpt('config_prefix', default='cache.oslo',
@@ -34,18 +57,7 @@
 # prevent issues with the memory cache ending up in "production"
 # unintentionally, we register a no-op as the default caching backend.
 cfg.StrOpt('backend', default=_DEFAULT_BACKEND,
-   choices=['oslo_cache.memcache_pool',
-'oslo_cache.dict',
-'oslo_cache.mongo',
-'oslo_cache.etcd3gw',
-'dogpile.cache.memcached',
-'dogpile.cache.pylibmc',
-'dogpile.cache.bmemcached',
-'dogpile.cache.dbm',
-'dogpile.cache.redis',
-'dogpile.cache.memory',
-'dogpile.cache.memory_pickle',
-'dogpile.cache.null'],
+   

Bug#986198: unblock: python-oslo.messaging/12.5.2-1

2021-03-31 Thread Thomas Goirand
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock

Dear release team,

This is a bug-fix point release from upstream adding some
exception handling in the oslo.messaging code, which I
believe would be valuable to have in Debian.

Only the .py upstream source code change is relevant to
read in the attached debdiff (the rest of is upstream CI
configuration).

Please unblock python-oslo.messaging/12.5.2-1.

Cheers,

Thomas Goirand (zigo)
diff -Nru python-oslo.messaging-12.5.1/debian/changelog 
python-oslo.messaging-12.5.2/debian/changelog
--- python-oslo.messaging-12.5.1/debian/changelog   2020-12-20 
10:30:34.0 +0100
+++ python-oslo.messaging-12.5.2/debian/changelog   2021-03-31 
13:18:24.0 +0200
@@ -1,3 +1,9 @@
+python-oslo.messaging (12.5.2-1) unstable; urgency=medium
+
+  * New upstream release.
+
+ -- Thomas Goirand   Wed, 31 Mar 2021 13:18:24 +0200
+
 python-oslo.messaging (12.5.1-1) unstable; urgency=medium
 
   * New upstream version
diff -Nru python-oslo.messaging-12.5.1/doc/source/admin/rabbit.rst 
python-oslo.messaging-12.5.2/doc/source/admin/rabbit.rst
--- python-oslo.messaging-12.5.1/doc/source/admin/rabbit.rst2020-10-15 
14:25:27.0 +0200
+++ python-oslo.messaging-12.5.2/doc/source/admin/rabbit.rst2021-02-18 
11:46:49.0 +0100
@@ -66,7 +66,8 @@
 through the *Connection* class.
 
 With mandatory flag RabbitMQ raises a callback if the message is not routed to
-any queue.
+any queue. This callback will be used to loop for a timeout and let's a chance
+to sender to recover.
 
 .. _Exchange is a AMQP mechanism: 
https://www.rabbitmq.com/tutorials/amqp-concepts.html#exchanges
 .. _queues: https://www.rabbitmq.com/queues.html
diff -Nru python-oslo.messaging-12.5.1/lower-constraints.txt 
python-oslo.messaging-12.5.2/lower-constraints.txt
--- python-oslo.messaging-12.5.1/lower-constraints.txt  2020-10-15 
14:25:27.0 +0200
+++ python-oslo.messaging-12.5.2/lower-constraints.txt  1970-01-01 
01:00:00.0 +0100
@@ -1,83 +0,0 @@
-alabaster==0.7.10
-amqp==2.5.2
-appdirs==1.3.0
-Babel==2.3.4
-bandit==1.1.0
-cachetools==2.0.0
-cffi==1.14.0
-cliff==2.8.0
-cmd2==0.8.0
-confluent-kafka==1.3.0
-contextlib2==0.4.0
-coverage==4.0
-debtcollector==1.2.0
-docutils==0.11
-dulwich==0.15.0
-eventlet==0.23.0
-extras==1.0.0
-fasteners==0.7.0
-fixtures==3.0.0
-futurist==1.2.0
-gitdb==0.6.4
-GitPython==1.0.1
-greenlet==0.4.15
-imagesize==0.7.1
-iso8601==0.1.11
-Jinja2==2.10
-keystoneauth1==3.4.0
-kombu==4.6.6
-linecache2==1.0.0
-MarkupSafe==1.1.1
-mock==2.0.0
-mox3==0.20.0
-msgpack-python==0.4.0
-netaddr==0.8.0
-netifaces==0.10.4
-os-client-config==1.28.0
-oslo.concurrency==3.25.0
-oslo.config==5.2.0
-oslo.context==2.19.2
-oslo.i18n==3.15.3
-oslo.log==3.36.0
-oslo.middleware==3.31.0
-oslo.serialization==2.18.0
-oslo.service==1.24.0
-oslo.utils==3.37.0
-oslotest==3.2.0
-Paste==2.0.2
-PasteDeploy==1.5.0
-pbr==2.0.0
-pifpaf==2.2.0
-prettytable==0.7.2
-pycparser==2.18
-Pygments==2.2.0
-pyinotify==0.9.6
-pyngus==2.2.0
-pyparsing==2.1.0
-pyperclip==1.5.27
-python-dateutil==2.5.3
-python-mimeparse==1.6.0
-python-qpid-proton==0.20.0
-python-subunit==1.0.0
-pytz==2013.6
-PyYAML==3.13
-repoze.lru==0.7
-requests==2.14.2
-requestsexceptions==1.2.0
-rfc3986==0.3.1
-Routes==2.3.1
-six==1.10.0
-smmap==0.9.0
-snowballstemmer==1.2.1
-statsd==3.2.1
-stestr==2.0.0
-stevedore==1.20.0
-tenacity==4.4.0
-testscenarios==0.4
-testtools==2.2.0
-traceback2==1.4.0
-unittest2==1.1.0
-vine==1.1.4
-WebOb==1.7.1
-wrapt==1.7.0
-xattr==0.9.2
diff -Nru python-oslo.messaging-12.5.1/oslo_messaging/_drivers/amqpdriver.py 
python-oslo.messaging-12.5.2/oslo_messaging/_drivers/amqpdriver.py
--- python-oslo.messaging-12.5.1/oslo_messaging/_drivers/amqpdriver.py  
2020-10-15 14:25:27.0 +0200
+++ python-oslo.messaging-12.5.2/oslo_messaging/_drivers/amqpdriver.py  
2021-02-18 11:46:49.0 +0100
@@ -145,39 +145,67 @@
 while True:
 try:
 with self.listener.driver._get_connection(
-rpc_common.PURPOSE_SEND) as conn:
+rpc_common.PURPOSE_SEND,
+) as conn:
 self._send_reply(conn, reply, failure)
+
 return
-except rpc_amqp.AMQPDestinationNotFound:
-if timer.check_return() > 0:
-LOG.debug(("The reply %(msg_id)s cannot be sent  "
-   "%(reply_q)s reply queue doesn't exist, "
-   "retrying..."), {
-   'msg_id': self.msg_id,
-   'reply_q': self.reply_q})
-time.sleep(0.25)
-else:
+except oslo_messaging.MessageUndeliverable:
+# queue not found
+if timer.check_return() <= 0:
 self._obsolete_reply_queues.add(self.reply_q, self.msg_id)
-infos = {

Bug#986197: ecopcr: Please provide autopkgtest

2021-03-31 Thread Nilesh Patra
Package: ecopcr
Version: 1.0.1+dfsg-2
Severity: wishlist
X-Debbugs-Cc: nil...@debian.org

Dear Maintainer,

Please provide autopkgtest for this package.

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

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



Bug#986196: claws-mail-vcalendar-plugin: CANCEL for a single instance of a recurring event cancels all recurrences

2021-03-31 Thread Vilius Panevėžys
Package: claws-mail-vcalendar-plugin
Version: 3.17.3-2
Severity: normal
Tags: upstream

Dear Maintainer,
after receiving a vCalendar message with "method=CANCEL" that intends to cancel 
a single instance of a recurring event all instances of the recurring event are 
removed from calendar. The message cancelling a single instance includes "UID" 
field that matches the invitation for the recurring event and a "RECURRENCE-ID" 
field in the "VEVENT" section, see an example below.

RECURRENCE-ID;TZID=FLE Standard Time:20210324T10

A grep through the plugin source for claws-mail-3.17.3 (the version in current 
stable, retrieved using `apt source`) and the upstream git repo returns no 
matches for "RECUR", which suggests there is no support for handling the 
"RECURRENCE-ID", hence the "upstream" tag. I presume any other changes of a 
single instance of a recurring event, e.g. changing the start time for a single 
instance, would malfuction in the same way - the change would affect all 
recurrences instead of the specific instance.


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

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

Versions of packages claws-mail-vcalendar-plugin depends on:
ii  claws-mail   3.17.3-2
ii  libatk1.0-0  2.30.0-2
ii  libc62.28-10
ii  libcairo21.16.0-4+deb10u1
ii  libcurl3-gnutls  7.64.0-4+deb10u1
ii  libdb5.3 5.3.28+dfsg1-0.5
ii  libetpan20   1.9.3-2
ii  libexpat12.2.6-2+deb10u1
ii  libfontconfig1   2.13.1-2
ii  libfreetype6 2.9.1-3+deb10u2
ii  libgdk-pixbuf2.0-0   2.38.1+dfsg-1
ii  libglib2.0-0 2.58.3-2+deb10u2
ii  libgnutls30  3.6.7-4+deb10u6
ii  libgtk2.0-0  2.24.32-3
ii  libical3 3.0.4-3
ii  liblockfile1 1.14-1.1
ii  libpango-1.0-0   1.42.4-8~deb10u1
ii  libpangocairo-1.0-0  1.42.4-8~deb10u1
ii  libpangoft2-1.0-01.42.4-8~deb10u1
ii  libsasl2-2   2.1.27+dfsg-1+deb10u1

claws-mail-vcalendar-plugin recommends no packages.

claws-mail-vcalendar-plugin suggests no packages.

-- no debconf information



Bug#825408: Reproducible using 7.5.3~deb10u1

2021-03-31 Thread Vilius Panevėžys
I've come across the issue using reportbug 7.5.3~deb10u1.
Misconfiguring (in my case the server config has changed since the last
time I used reportbug) SMTP settings is a user error, but the output is
confusing, which makes the problem hard to notice, i.e. a reportbug
usability issue. See the partial output of my reportbug session below.

Connecting to  via SMTP...
Unable to send report to sub...@bugs.debian.org: 554 b'5.7.1 
: Relay access denied'
Wrote bug report to 
/tmp/reportbug-claws-mail-vcalendar-plugin-20210331-6084-iewah24q

Bug report submitted to: Debian Bug Tracking System 

Copies sent to:
  [...]

Exit status "0" suggests everything completed successfully. So it would
seem reasonable to assume that "Unable to send" was a temporary error
and a retry succeeded because a further line says "report submitted".
Even though I did notice the error and assumed submission had actually
failed, I still waited for more than an hour to make sure I would not
submit a duplicate report.



Bug#986194: pique: no autopkgtest available yet

2021-03-31 Thread Nilesh Patra
Package: pique
Version: 1.0-2
Severity: wishlist
Tags: newcomer
X-Debbugs-Cc: nil...@debian.org

Dear Maintainer,

It would be a nice addition for the package to have some test
suite "autopkgtest" available.

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

Kernel: Linux 5.7.0-2-amd64 (SMP w/8 CPU threads)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: unable to detect

Versions of packages pique depends on:
ii  eigensoft 7.2.1+dfsg-2
ii  emmax 0~beta.20100307-1+b1
ii  libfile-slurp-perl.32-1
ii  libparallel-forkmanager-perl  2.02-1
ii  libreadonly-perl  2.050-2
ii  perl  5.32.0-6
ii  plink 1.07+dfsg-3
ii  r-base-core   4.0.4-1
ii  r-cran-forecast   8.13-1
ii  r-cran-getopt 1.20.3-3
ii  r-cran-optparse   1.6.6-2
ii  r-cran-uroot  2.1-2-1

pique recommends no packages.

pique suggests no packages.

-- no debconf information

-- debsums errors found:
debsums: changed file /usr/bin/pique-input (from pique package)



Bug#986193: hinge: no autopkgtest available yet

2021-03-31 Thread Nilesh Patra
Package: hinge
Version: 5.0-6+b2
Severity: wishlist
X-Debbugs-Cc: nil...@debian.org

Dear Maintainer,

It would be a nice addition for the package to have some test
suite "autopkgtest" available.

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

Kernel: Linux 5.7.0-2-amd64 (SMP w/8 CPU threads)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: unable to detect

Versions of packages hinge depends on:
pn  daligner
pn  dascrubber  
ii  dazzdb  1.0+git20200727.d22ae58-1
ii  libc6   2.31-3
pn  libfmt7 
ii  libgcc-s1   11-20210220-1
ii  libgomp111-20210220-1
ii  libstdc++6  11-20210220-1
ii  python3 3.9.1-1
pn  python3-colormap
ii  python3-matplotlib  3.3.2-2
ii  python3-networkx2.5+ds-2
ii  python3-numpy   1:1.19.4-1
pn  python3-pbcore  
pn  python3-ujson   
ii  zlib1g  1:1.2.11.dfsg-2

hinge recommends no packages.

hinge suggests no packages.



Bug#986192: gimp: refuses to run with LittleCMS 2.9, thinks 2.9 < 2.2

2021-03-31 Thread Lionel Elie Mamane
Package: gimp
Version: 2.10.22-3
Severity: important

Gimp refuses to start with LittleCMS 2.9 installed, saying it needs
"LittleCMS version at least 2.2". It seems to mistakenly believe 2.9
is not "at least 2.2".

-- System Information:
Debian Release: 10.9
  APT prefers stable
  APT policy: (600, 'stable'), (500, 'stable-updates'), (400, 'testing'), (300, 
'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

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

Versions of packages gimp depends on:
ii  gimp-data2.10.22-3
ii  graphviz 2.40.1-6
ii  libaa1   1.4p5-46
ii  libbabl-0.1-01:0.1.82-1
ii  libbz2-1.0   1.0.6-9.2~deb10u1
ii  libc62.31-10
ii  libcairo21.16.0-4+deb10u1
ii  libfontconfig1   2.13.1-2
ii  libfreetype6 2.10.4+dfsg-1
ii  libgcc-s110.2.1-6
ii  libgdk-pixbuf-2.0-0  2.42.2+dfsg-1
ii  libgegl-0.4-01:0.4.26-2
ii  libgexiv2-2  0.10.9-1
ii  libgimp2.0   2.10.22-3
ii  libglib2.0-0 2.66.7-2
ii  libgs9   9.27~dfsg-2+deb10u4
ii  libgtk2.0-0  2.24.32-3
ii  libgudev-1.0-0   232-2
ii  libharfbuzz0b2.3.1-1
ii  libheif1 1.11.0-1
ii  libilmbase25 2.5.4-1
ii  libjpeg62-turbo  1:1.5.2-2+deb10u1
ii  libjson-glib-1.0-0   1.6.2-1
ii  liblcms2-2   2.9-3
ii  liblzma5 5.2.4-1
ii  libmng1  1.0.10+dfsg-3.1+b5
ii  libmypaint-1.5-1 1.6.0-2
ii  libopenexr25 2.5.4-1
ii  libopenjp2-7 2.4.0-3
ii  libpango-1.0-0   1.42.4-8~deb10u1
ii  libpangocairo-1.0-0  1.42.4-8~deb10u1
ii  libpangoft2-1.0-01.42.4-8~deb10u1
ii  libpng16-16  1.6.36-6
ii  libpoppler-glib8 0.71.0-5
ii  librsvg2-2   2.44.10-2.1
ii  libstdc++6   10.2.1-6
ii  libtiff5 4.1.0+git191117-2~deb10u2
ii  libwebp6 0.6.1-2
ii  libwebpdemux20.6.1-2
ii  libwebpmux3  0.6.1-2+b1
ii  libwmf0.2-7  0.2.8.4-14
ii  libx11-6 2:1.7.0-2
ii  libxcursor1  1:1.1.15-2
ii  libxext6 2:1.3.3-1+b2
ii  libxfixes3   1:5.0.3-1
ii  libxmu6  2:1.1.2-2+b3
ii  libxpm4  1:3.5.12-1
ii  xdg-utils1.1.3-1+deb10u1
ii  zlib1g   1:1.2.11.dfsg-1

Versions of packages gimp recommends:
ii  ghostscript  9.27~dfsg-2+deb10u4

Versions of packages gimp suggests:
pn  gimp-data-extras  
pn  gimp-help-en | gimp-help  
ii  gvfs-backends 1.38.1-5
ii  libasound21.1.8-1

-- no debconf information

-- 
Lionel Mamane
Tél: +352 46 67 74
Fax: +352 46 67 76

This message and any attachments may be intended to be confidential,
intended solely for the addressee and/or contain legally privileged
information. Any unauthorised use or dissemination is prohibited.
Unless cryptographically protected, emails are susceptible to
interception, alteration and spoofing, so in case of doubt, please
check by independent means.

We do not make any commitment by email, ever; if this emails appears
to contain a commitment, we will not recognise the latter as valid,
nor as engaging our liability. We make commitments only by a written
paper document signed by at least one person entitled to engage our
liability.


Bug#986190: please enable pie again

2021-03-31 Thread Matthias Klose
Package: src:python-pylibacl
Version: 0.6.0-1
Tags: patch

According to the changelog, pie was disabled in 2016. The package also builds
with pie. Please enable it again.

patch at
http://launchpadlibrarian.net/531026915/python-pylibacl_0.6.0-1build1_0.6.0-1ubuntu1.diff.gz



Bug#986191: please enable pie again

2021-03-31 Thread Matthias Klose
Package: src:python-pyxattr
Version: 0.7.2-1
Tags: patch

According to the changelog, pie was disabled in 2016. The package also builds
with pie. Please enable it again.

patch at
http://launchpadlibrarian.net/531026119/python-pyxattr_0.7.2-1build1_0.7.2-1ubuntu1.diff.gz



Bug#985946: patch proposal

2021-03-31 Thread David Bannon
Issue : tomboy-ng not building on ppc64el

Frédéric, I don't think I will be able to do anything about this until I
get home, some time after Easter.

My laptop has U18.04 on it, that has offered me QEMU 2.11.1 and it seems
quite unhappy with ppc64le. There are known issues that limit me to
using tcg, not kvm. I have to set machine to pseries-2.12 because it can
apparently workaround the bug that stops tcg working. Buts its still not
good.

I can get a commandline but not a working GUI (have tried XFCE4) - I
suspect my limited knowledge about QEMU is preventing me from
establishing a suitable graphics config.

Could you share your QEMU command line to start your test rig please ?

Without a test env, I cannot determine the reason behind that crash on
Search you are seeing, can you remember what you tried to do ?  It could
have been an "in note" find, ctrl-F or right click 'Find' or,
alternatively, a Search of the whole  note collection, Menu 'Search' ??

The target cpu issue ?  Its not really an issue IMHO.  FPC uses a switch
called 'powerpc64' to generate ppc64 code of either endianess.  It picks
up whatever endianess the host has and uses that. Lazarus, which is a
different product, uses $HOSTTYPE to name the object file directories
and on Debian at least thats  'powerpc64le'.

I guess we could campaign to add 'powerpc64le' to FPC options, having it
select both PPC instruction set and little endian but FPC is slow to
change ...

For now, an if statement will work fine. My build needs a few
(surprisingly few) changes to support PPC64le, easy. Fixing that access
violation, not so easy until I can run it under the debugger. Sorry.


Davo





On 30/3/21 1:25 am, Frédéric Bonnard wrote:
> Hi,
>
>> "ppc64el" ?  "endian little" ?  Is that the same as ppc64le  ?
> indeed
>
>>  As inIBM Power8 ?
> yes
>
>> I do have a history with IBM Power systems, once managed a
>> couple of largeish BlueGene machines. But a long time ago. I now have no
>> hope of getting direct access to P8 hardware. FPC 320 does apparently
>> support ppc64le and maybe I can cross compile ?
> For development use, yes cross-compilation may be an option, but for
> Debian package generation, I guess it follows a bit different path
> compared to native package build.
>
>> But sooner or later I'd have to use MiniCloud and bring X back over ssh.
>> Brazil to Australia ?  Wow, thats going to be fun. 
> There's also OSUOSl :
> https://osuosl.org/services/powerdev/request_hosting/
>
> In both case, testing on X may be "fun" :)
> Now, I wonder if just having a local ppc64el qemu machine running in
> a x86 host isn't better for both compilation (tomboy-ng is not a big
> build) and runtime testing.
>
>> Now, Lazarus, and in this case, I mean LCL, does not offer any PPC64le
>> support at all. But you seem to have installed some LCL at least so I
>> suspect I should be able to solve the KControls issue that you hit just
>> with an understanding of what the OS offers.  I expect there will be #
>> defines there that think they are looking at an old Mac PPC and thats
>> sure not going to work.
>>
>> So, its possible, the question is, is it practical ?
> Well my understand is that LCL is provided on ppc64el :
> https://tracker.debian.org/pkg/lazarus
> https://packages.debian.org/unstable/lcl-2.0
> ...
>
>> Personally, I'd consider it pretty cool but I have to ask, is anyone
>> using IBM Power8 desktop systems ?
> Probably few, but there are desktop oriented Power based systems :
> https://www.raptorcs.com/content/base/products.html
> https://www.talospace.com/
>
> I do not not use the desktop side on Power, but if software compile without
> much effort I try to enable them, and also for the sake of portability
> and the fact that Debian does support ppc64el officially.
>
>> OK, you are way ahead of me Frédéric, please disregard my previous response.
>>
>> Great that your patch works, really cool.  And thanks ! However, do you
>> mind if I query something ?  I don't quite see why you call the -
>>
>> +if [ "$CPU" = "powerpc64le" ]; then
>> +    CPU="powerpc64"
>> +fi
>>
>> AFTER the line -
>>
>> TARGET="$CPU-$OS"
>>
>> If we set TARGET after the "if" statement. the patch is heaps simpler.
>> And I like simple patches ...
>>
>> Now, I cannot test it here but if you can while you have a terminal to a
>> P8 machine, and don't have a reason for the way you have done it, could
>> you test please ?
>>
>> Otherwise, if you think it needs to be as per your patch, I am quite
>> happy to apply that.
> I always try my patches :) (this one let tomboy-ng build well, and I
> didn't see regression on other arches) and I'm always open to discussing it 
> for sure,
> you have the last word.
>
>> Do you want me to run up a new release or would you prefer to use the
>> patch on a Debian downstream release model ?
> oh great, I didn't realize you were the upstream too.
>
> On Sun, 28 Mar 2021 21:58:29 +1100, David Bannon  
> wrote:
>> OK Frédéric, I confess to being on very shaky 

Bug#981190: sudo-ldap: Users files sudoers nopasswd stop working after update to 1.8.27-1+deb10u3

2021-03-31 Thread BRUN Eric
Hi Dennis,

Le 30/03/2021 22:53, « Dennis Filder »  a écrit :

On Tue, Mar 30, 2021 at 10:17:11AM +, BRUN Eric wrote:

> In my file nsswitch.conf, I have :
>
> sudoers: files ldap
>
> Before update, that worked , first try to find account in "files"
> and then, if not found, try with ldap accounts.
>
> After update, it like "files" are ignored and ldap is directly used.
> I read logs files for this analyse.

This is not how sudo works by default.  To quote the sudoers.ldap
manpage:

  Sudo looks for a line beginning with sudoers: and uses this to
  determine the search order.  Note that sudo does not stop searching
  after the first match and later matches take precedence over earlier
  ones.

I suspect that before the upgrade the LDAP backend returned nothing,
and after the upgrade it started to return one or more entries, but
since those most likely do not have the "sudoOption: !authenticate"
attribute sudo prompts for a password (this was the only way I could
reproduce your observed behaviour).

These lines in your sudo-ldap-debug.log seem to confirm this:

  ...
  sudo: adding search result
  sudo: result now has 1 entries
  ...

Can you try if putting this

   sudoers: files [SUCCESS=return] ldap

into /etc/nsswitch.conf fixes the issue?  This way sudo stops
processing if a successful match in /etc/sudoers is found first (this
is not mentioned in the manpages, I learned of this by looking at the
code).

Yes, it solve my problem, thank you.

What do the LDAP entries for user nagios actually look like?

There is no "nagios" entry on the LDAP server.

I do must say though that using /etc/sudoers to specify exceptions to
rules in an LDAP backend is an unorthodox way of using sudo with LDAP
as it makes troubleshooting very complicated.  If you want a command
to be runnable only on a subset of hosts then using separate per-host
entries in LDAP is the intended way.  Otherwise someone looking just
at the LDAP output has no way of knowing what other rules might be in
effect or if the LDAP backend is overshadowed by a
[SUCCESS=return]/[NOTFOUND=return].

You are right, I will try to do better but for now your fix is the best and 
faster approach in my context.
Thank you for yours wise advices.

Another issue: your sudo-ldap.conf specifies ldap: URIs whereas ldaps:
is probably more applicable to ensure TLS.  Otherwise an attacker who
can manipulate packets in transit could use that to escalate his
privileges.
   
Thank you again and for spending time on this issue.

Regards,
Dennis.

Respectfully,

Eric



Bug#323420: Hej, jeg er advokat Samuel Mathey, jeg giver dig et forslag, men fonden til min afdøde klient, som du deler det samme efternavn med, og han kommer fra dit land. Jeg vil have dig til at kræ

2021-03-31 Thread mathey



Bug#986186: postgresql-common: pg_dump in bullseye does not talk to version 13

2021-03-31 Thread Johannes Ranke
Package: postgresql-common
Version: 225
Followup-For: Bug #986186

After successfully dumping my database as described above, I upgraded
the cluster to version 13 which worked nicely.

However, when I run pg_dump with the upgraded cluster running on port
5433, I get

LANG=C pg_dump -p 5433 my_database
pg_dump: server version: 13.2 (Debian 13.2-1); pg_dump version: 11.6 (Debian 
11.6-0+deb10u1)
pg_dump: aborting because of server version mismatch

I thought this may be due to the buster packages still being installed,
so I removed postgresql-11. After that, I get

Error: PostgreSQL version 11 is not installed

Is it possible that pg_dump in bullseye does not work at all with the
default postgresql package in bullseye?

Cheers,

Johannes

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

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

Versions of packages postgresql-common depends on:
ii  adduser   3.118
ii  debconf [debconf-2.0] 1.5.75
ii  lsb-base  11.1.0
ii  perl  5.32.1-3
ii  postgresql-client-common  225
ii  ssl-cert  1.1.0
ii  ucf   3.0043

Versions of packages postgresql-common recommends:
ii  e2fsprogs  1.46.2-1
ii  logrotate  3.18.0-2

Versions of packages postgresql-common suggests:
ii  libjson-perl  4.03000-1

-- Configuration Files:
/etc/apt/apt.conf.d/01autoremove-postgresql changed [not included]

-- debconf information:
  postgresql-common/ssl: true
* postgresql-common/obsolete-major:
  postgresql-common/catversion-bump:



Bug#986189: please advertise alsa Debian when creating a vm

2021-03-31 Thread Picca Frédéric-Emmanuel
Package: gnome-boxes
Version: 3.38.2-1
Severity: wishlist
X-Debbugs-Cc: pi...@debian.org

Hello,

I am debuging an upgrade buster -> bullseye problem for the tango-db package.
I installed tango-boxes in order to reproduce the issue on a fresh buster image.
the first advertize system are only RedHat related, it would be nice to add in
this list also the Debian system.

thanks for considering.

Frederic

-- System Information:
Debian Release: bullseye/sid
  APT prefers stable-debug
  APT policy: (500, 'stable-debug'), (500, 'proposed-updates-debug'), (500, 
'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 5.10.0-4-amd64 (SMP w/4 CPU threads)
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.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 gnome-boxes depends on:
ii  dconf-gsettings-backend [gsettings-backend]  0.38.0-2
ii  genisoimage  9:1.1.11-3.2
ii  libarchive13 3.4.3-2+b1
ii  libc62.31-10
ii  libcairo21.16.0-5
ii  libfreerdp2-22.3.0+dfsg1-1
ii  libgdk-pixbuf-2.0-0  2.42.2+dfsg-1
ii  libgdk-pixbuf2.0-0   2.40.2-2
ii  libglib2.0-0 2.66.8-1
ii  libgtk-3-0   3.24.24-3
ii  libgtk-vnc-2.0-0 1.0.0-1
ii  libgtksourceview-4-0 4.8.0-1
ii  libgudev-1.0-0   234-1
ii  libhandy-0.0-0   0.0.13-3
ii  libosinfo-1.0-0  1.8.0-1
ii  libosinfo-bin1.8.0-1
ii  libpango-1.0-0   1.46.2-3
ii  libsecret-1-00.20.4-2
ii  libsoup2.4-1 2.72.0-2
ii  libspice-client-glib-2.0-8   0.39-1
ii  libspice-client-gtk-3.0-50.39-1
ii  libtracker-sparql-2.0-0  2.3.6-2
ii  libusb-1.0-0 2:1.0.24-3
ii  libvirt-daemon   7.0.0-3
ii  libvirt-glib-1.0-0   3.0.0-1
ii  libvte-2.91-00.62.3-1
ii  libwebkit2gtk-4.0-37 2.30.6-1
ii  libwinpr2-2  2.3.0+dfsg1-1
ii  libxml2  2.9.10+dfsg-6.3+b1
ii  tracker  2.3.6-2

Versions of packages gnome-boxes recommends:
ii  qemu-system-x86  1:5.2+dfsg-9

gnome-boxes suggests no packages.

-- no debconf information



Bug#986186: postgresql-common: pg_dump works after dropping the upgraded cluster

2021-03-31 Thread Johannes Ranke
Package: postgresql-common
Version: 225
Followup-For: Bug #986186

OK, after I dropped the upgraded version 11 cluster, pg_dump works as
expected. It still seems to me that that pg_dump/pg_wrapper needs a way
to select the cluster it should talk to.

Thanks,

Johannes



Bug#965059: Syntax warnings with Python 3.8

2021-03-31 Thread Ludovic Rousseau
On Wed, 15 Jul 2020 11:34:38 +0100 Sam Morris  wrote:
> Package: python3-yubico
> Version: 1.3.3-0.3
> Severity: normal
> 
> $ ipa user-find sam
> /usr/lib/python3/dist-packages/netaddr/strategy/__init__.py:189: 
> SyntaxWarning: "is not" with a literal. Did you mean "!="?
>   if word_sep is not '':
> /usr/lib/python3/dist-packages/yubico/yubikey_usb_hid.py:288: SyntaxWarning: 
> "is" with a literal. Did you mean "=="?
>   if mode is 'nand':
> /usr/lib/python3/dist-packages/yubico/yubikey_usb_hid.py:294: SyntaxWarning: 
> "is" with a literal. Did you mean "=="?
>   elif mode is 'and':
> /usr/lib/python3/dist-packages/yubico/yubikey_usb_hid.py:306: SyntaxWarning: 
> "is" with a literal. Did you mean "=="?
>   if mode is 'nand':
> /usr/lib/python3/dist-packages/yubico/yubikey_config.py:478: SyntaxWarning: 
> "is" with a literal. Did you mean "=="?
>   if slot is 1:
> /usr/lib/python3/dist-packages/yubico/yubikey_config.py:483: SyntaxWarning: 
> "is" with a literal. Did you mean "=="?
>   elif slot is 2:
> [...]

The problem is already fixed upstream in 
https://github.com/Yubico/python-yubico/commit/b4a53389c3e6ad41c836aa82998149f427fe1ad8
 since September 2019.

But the change is not yet available in a released version of
python-yubico.

Maybe the Debian package could use the upstream patch?



Bug#986180: libc6: cannot upgrade to libc6_2.31-10: pre-installation script subprocess returned error exit status 10

2021-03-31 Thread Jack Donohue
Package: libc6
Version: 2.31-9
Severity: grave
Justification: renders package unusable
X-Debbugs-Cc: jdonohue654-debianh...@yahoo.com

Hi. Upgrading libc6_2.31-8 -> libc6_2.31-10 fails. The output from
apt-get dist-upgrade is included below.

I noticed a fix for Bug#984533 is included in this release. I don't
know if that is related. I had neither dialog nor whiptail
installed. I tried upgrading again after installing dialog, but still
got the exit status 10.

Here is the output from apt-get dist-upgrade:



Hit:1 http://dl.google.com/linux/chrome/deb stable InRelease
Get:2 https://packages.cloud.google.com/apt cloud-sdk InRelease [6,739 B]   
  
Hit:3 http://ftp.us.debian.org/debian testing InRelease 
   
Hit:4 http://security.debian.org testing-security/updates InRelease 
 
Hit:5 http://ftp.us.debian.org/debian testing-updates InRelease 
 
Hit:6 http://www.deb-multimedia.org testing InRelease  
Fetched 6,739 B in 1s (7,088 B/s)
Reading package lists... Done
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
Calculating upgrade... Done
The following NEW packages will be installed:
  libaom3
The following packages will be upgraded:
  bind9-dnsutils bind9-host bind9-libs ffmpeg geoclue-2.0 gir1.2-geoclue-2.0 
gir1.2-javascriptcoregtk-4.0 gir1.2-webkit2-4.0 google-chrome-stable 
google-cloud-sdk
  gstreamer1.0-plugins-bad libavcodec58 libavdevice58 libavfilter7 
libavformat58 libavresample4 libavutil56 libc-bin libc-l10n libc6 libcaca0 
libgeoclue-2-0 libglib2.0-0
  libglib2.0-bin libglib2.0-data libgnutls30 libgstreamer-plugins-bad1.0-0 
libjavascriptcoregtk-4.0-18 liblirc-client0 libmyth-31 libmythavcodec58 
libmythavfilter7 libmythavformat58
  libmythavutil56 libmythpostproc55 libmythswresample3 libmythswscale5 
libpostproc55 libqt5qml5 libqt5qmlmodels5 libqt5quick5 librubberband2 libssl1.1 
libsvthevcenc1 libswresample3
  libswscale5 libvpx6 libwebkit2gtk-4.0-37 locales mplayer mythtv-common 
mythtv-frontend openssl python3-lxml python3-mythtv
55 upgraded, 1 newly installed, 0 to remove and 0 not upgraded.
1 not fully installed or removed.
Need to get 0 B/249 MB of archives.
After this operation, 7,852 kB of additional disk space will be used.
Do you want to continue? [Y/n] 
debconf: delaying package configuration, since apt-utils is not installed
(Reading database ... 108166 files and directories currently installed.)
Preparing to unpack .../libc6_2.31-10_amd64.deb ...
debconf: unable to initialize frontend: Dialog
debconf: (No usable dialog-like program is installed, so the dialog based 
frontend cannot be used. at /usr/share/perl5/Debconf/FrontEnd/Dialog.pm line 
76.)
debconf: falling back to frontend: Readline
dpkg: error processing archive /var/cache/apt/archives/libc6_2.31-10_amd64.deb 
(--unpack):
 new libc6:amd64 package pre-installation script subprocess returned error exit 
status 10
Errors were encountered while processing:
 /var/cache/apt/archives/libc6_2.31-10_amd64.deb
E: Sub-process /usr/bin/dpkg returned an error code (1)






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

Kernel: Linux 5.10.0-5-amd64 (SMP w/8 CPU threads)
Kernel taint flags: TAINT_USER, TAINT_FIRMWARE_WORKAROUND
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages libc6 depends on:
ii  libcrypt1  1:4.4.17-1
ii  libgcc-s1  10.2.1-6

Versions of packages libc6 recommends:
ii  libidn2-0   2.3.0-5
pn  libnss-nis  
pn  libnss-nisplus  

Versions of packages libc6 suggests:
ii  debconf [debconf-2.0]  1.5.75
pn  glibc-doc  
ii  libc-l10n  2.31-9
ii  locales2.31-9

-- debconf information:
  glibc/kernel-not-supported:
  glibc/disable-screensaver:
  libraries/restart-without-asking: false
  glibc/upgrade: true
  glibc/restart-failed:
  glibc/kernel-too-old:
  glibc/restart-services:



Bug#986187: sharness: new upstream release 1.1.0

2021-03-31 Thread Paul Wise
Package: sharness
Version: 1.0.0-1.1
Severity: wishlist

There is new upstream release 1.1.0 of sharness:

https://github.com/chriscool/sharness/releases/tag/v1.1.0

Some packages in Debian require the new test_expect_unstable function.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


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


Bug#986186: postgresql-common: pg_dump does not talk to the last major version (11): Error: PostgreSQL version 9.6 is not installed

2021-03-31 Thread Johannes Ranke
Package: postgresql-common
Version: 225
Severity: normal

Dear Maintainer,

I have upgraded this buster system to bullseye. I did not do anything
postgresql related during the upgrade and phppgadmin kept working, so I
kept entering data with that. I think both clusters (11 and 13) were
running at the same time, and phppgadmin connected to 11. 

Now I would like to make a database dump before I upgrade the cluster.

The postgresql 9.6 directory is still present, and postgresql-11 is
still installed and running:

$ pg_lsclusters 
Ver Cluster Port StatusOwnerData directory   
Log file
9.6 main5432 down,binaries_missing postgres /var/lib/postgresql/9.6/main 
/var/log/postgresql/postgresql-9.6-main.log
11  main5433 onlinepostgres /var/lib/postgresql/11/main  
/var/log/postgresql/postgresql-11-main.log
13  main5434 onlinepostgres /var/lib/postgresql/13/main  
/var/log/postgresql/postgresql-13-main.log

I can connect to the version 11 cluster with psql -p 5433 my_database, but when 
I
run pg_dump -p 5433 my_database, I get

Error: PostgreSQL version 9.6 is not installed

After dropping 9.6 with pg_dropcluster this works as expected, but I
think it would be preferable if this would not be necessary.

BTW, is there work underway to provide a postgresql specific paragraph
in the bullseye release notes? I am not very experienced with
postgresql, but would be willing to help writing/proof reading/testing.

Johannes

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

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

Versions of packages postgresql-common depends on:
ii  adduser   3.118
ii  debconf [debconf-2.0] 1.5.75
ii  lsb-base  11.1.0
ii  perl  5.32.1-3
ii  postgresql-client-common  225
ii  ssl-cert  1.1.0
ii  ucf   3.0043

Versions of packages postgresql-common recommends:
ii  e2fsprogs  1.46.2-1
ii  logrotate  3.18.0-2

Versions of packages postgresql-common suggests:
ii  libjson-perl  4.03000-1

-- Configuration Files:
/etc/apt/apt.conf.d/01autoremove-postgresql changed [not included]

-- debconf information:
* postgresql-common/obsolete-major:
  postgresql-common/catversion-bump:
  postgresql-common/ssl: true



Bug#981113: ITP: cern-root -- data analysis framework

2021-03-31 Thread Stephan Lachnit

Control: retitle -1 ITP: root-framework -- data analysis framework


I've decided to go with root-framwork. The reason for this is that

this is also the name for the package in the snap store, which

afaik was created from some authors of ROOT, so I think it's best

not to come up with something new again.


Progress on the other hand is a bit slow at the moment, the main

reason is that I wait for the 6.24.xx series to release, which includes

an important build system fix that I don't want to backport (it's

hard-freeze time anyway so need to rush).


Regards,

Stephan



Bug#986184: ITP: dialect -- translation application

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

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

* Package name: dialect
  Version : 1.2.0
  Upstream Author : gi-lom
* URL : https://github.com/gi-lom/dialect/
* License : GPL-3+
  Programming Lang: Python
  Description : translation app for GTK environments

 Dialect is a simple translation app for GTK environments
 -
 Features:
  * Translation based on the googletrans Python API,
an unofficial API for Google Translate
  * Translation based on the LibreTranslate API,
allowing you use any instance available online
  * Translation history
  * Automatic language detection
  * Text to speech
  * Clipboard buttons

-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEn+Ppw2aRpp/1PMaELHwxRsGgASEFAmBkNLYACgkQLHwxRsGg
ASFqiBAAri83OZNlCGdO7LN8n1N1tY5V6ejvSOLfGJI6kMH/VYqobfiydlCtT3/J
1EdhkkAZaqND+XaaH01DKFWVQxYO1NWOGsw06I7iLoWUFN1/vhjlCZMncJksMbbN
Q2/QncbPgjzM74Wh5ksDQ+XRHAuqNsnkx26aqid0LDSuw8INuRiHV95eu2SDfzDA
xvTPLaeJTU+8TubTUmYw0uL2omk3+koZ46sJ8AyoMv3BePrp2RPItfoCk6CVw/cW
IkzkKkHYT/HwlgKaJL69l5sS1Yr7Dy3+R9sXcmaI1ILToFTZkISA5Z6mVVdmrVkL
115TULPxmhDoP4D+AHonbdjOJVWFnJ54LU+jqQjYVvvRUmQ7WaK71vtQBaTX1XZK
ZnTZPpuNTA40oZQdjdmzpduo5FzBrPAm9L+FLiqLthcMwYU7+Imn0IhWJJwW87Xa
sZtxCOYWIEOx6TTY4mJPplGkfBIOCJLvMiMNgOf/IP663tVxFidWijpHrOaeFwa8
tjkTf9zdj2lGl39WhbesfsfZhNCLCTzHR1QnkgUpGNQcDH2nziwVTKovTsKDePYd
QGj2irT/W6mApsx/PyNTXrmrejQ3klR/iIpo5jghdn6lrrLOhVZ3MSm+Lr4GVc0V
M7SEnAzAKmwAMA7Iuyy9BCjKJlVfFAnuoM32tcm1SuMoKyG/lo8=
=U/zy
-END PGP SIGNATURE-



Bug#986175: unblock: underscore/1.9.1~dfsg-2

2021-03-31 Thread Sebastian Ramacher
Control: tags -1 moreinfo

On 2021-03-30 22:49:43, Yadd wrote:
> Package: release.debian.org
> Severity: normal
> User: release.debian@packages.debian.org
> Usertags: unblock
> X-Debbugs-Cc: pkg-javascript-de...@lists.alioth.debian.org
> 
> Please unblock package underscore
> 
> [ Reason ]
> underscore is vulnerable to arbitrary code execution (#986171,
> CVE-2021-23358)
> 
> [ Impact ]
> CVE provided a PoC to prove arbitrary code execution
> 
> [ Tests ]
> I added a test to prove that bug is fixed (based on PoC). Test fails
> with 1.9.1~dfsg-1 and passes with 1.9.1~dfsg-2
> 
> [ Risks ]
> Patch is trivial. Note: I imported also Janitor changes: this breaks
> nothing

The patch looks fine, but please upload a version without the janitor
changes. It's too late for those changes and they can wait for bookworm.

Cheers

> 
> [ Checklist ]
>   [X] all changes are documented in the d/changelog
>   [X] I reviewed all changes and I approve them
>   [X] attach debdiff against the package in testing
> 
> [ Other ]
> I downgrade autopkgtest to "superficial" since nothing was really tested
> (just a node "require"). That's why I'm filing this ;-)
> 
> Regards,
> Yadd
> 
> unblock underscore/1.9.1~dfsg-2

> diff --git a/debian/changelog b/debian/changelog
> index 02cd807..fed9aa8 100644
> --- a/debian/changelog
> +++ b/debian/changelog
> @@ -1,3 +1,26 @@
> +underscore (1.9.1~dfsg-2) unstable; urgency=medium
> +
> +  * Team upload
> +
> +  [ Debian Janitor ]
> +  * Bump debhelper dependency to >= 9, since that's what is used in
> +debian/compat.
> +  * Bump debhelper from old 9 to 12.
> +  * Set debhelper-compat version in Build-Depends.
> +  * Set upstream metadata fields: Bug-Database, Repository, Repository-
> +Browse.
> +  * Update standards version to 4.4.1, no changes needed.
> +  * Set upstream metadata fields: Bug-Submit.
> +  * Update standards version to 4.5.0, no changes needed.
> +  * Apply multi-arch hints.
> ++ node-underscore: Add Multi-Arch: foreign.
> +
> +  [ Yadd ]
> +  * Mark autopkgtest as superficial
> +  * Fix arbitrary code execution and add a test (Closes: #986171)
> +
> + -- Yadd   Tue, 30 Mar 2021 22:40:59 +0200
> +
>  underscore (1.9.1~dfsg-1) unstable; urgency=medium
>  
>[ upstream ]
> diff --git a/debian/compat b/debian/compat
> deleted file mode 100644
> index ec63514..000
> --- a/debian/compat
> +++ /dev/null
> @@ -1 +0,0 @@
> -9
> diff --git a/debian/control b/debian/control
> index cb1e7e9..fc1d26b 100644
> --- a/debian/control
> +++ b/debian/control
> @@ -7,11 +7,11 @@ Uploaders:
>   David Paleino ,
>  Build-Depends:
>   brotli,
> - debhelper,
> + debhelper-compat (= 12),
>   node-source-map,
>   pigz,
>   uglifyjs (>= 3),
> -Standards-Version: 4.3.0
> +Standards-Version: 4.5.0
>  Homepage: https://underscorejs.org/
>  Vcs-Browser: https://salsa.debian.org/js-team/underscore
>  Vcs-Git: https://salsa.debian.org/js-team/underscore.git
> @@ -44,6 +44,7 @@ Depends:
>   libjs-underscore,
>   nodejs,
>   ${misc:Depends},
> +Multi-Arch: foreign
>  Description: JavaScript's functional programming helper library - NodeJS
>   Underscore is a utility-belt library for JavaScript that provides a lot
>   of the functional programming support that you would expect in
> diff --git a/debian/patches/CVE-2021-23358.patch 
> b/debian/patches/CVE-2021-23358.patch
> new file mode 100644
> index 000..2ba4118
> --- /dev/null
> +++ b/debian/patches/CVE-2021-23358.patch
> @@ -0,0 +1,62 @@
> +Description: fix arbitrary code execution
> +Author: Julian Gonggrijp 
> +Origin: upstream, https://github.com/jashkenas/underscore/commit/4c73526d
> +Bug: https://snyk.io/vuln/SNYK-JS-UNDERSCORE-1080984
> +Bug-Debian: https://bugs.debian.org/986171
> +Forwarded: not-needed
> +Reviewed-By: Xavier Guimard 
> +Last-Update: 2021-03-30
> +
> +--- a/underscore.js
>  b/underscore.js
> +@@ -1550,6 +1550,13 @@
> + return '\\' + escapes[match];
> +   };
> + 
> ++  // In order to prevent third-party code injection through
> ++  // `_.templateSettings.variable`, we test it against the following regular
> ++  // expression. It is intentionally a bit more liberal than just matching 
> valid
> ++  // identifiers, but still prevents possible loopholes through defaults or
> ++  // destructuring assignment.
> ++  var bareIdentifier = /^\s*(\w|\$)+\s*$/;
> ++
> +   // JavaScript micro-templating, similar to John Resig's implementation.
> +   // Underscore templating handles arbitrary delimiters, preserves 
> whitespace,
> +   // and correctly escapes quotes within interpolated code.
> +@@ -1585,8 +1592,17 @@
> + });
> + source += "';\n";
> + 
> +-// If a variable is not specified, place data values in local scope.
> +-if (!settings.variable) source = 'with(obj||{}){\n' + source + '}\n';
> ++var argument = settings.variable;
> ++if (argument) {
> ++  // Insure against third-party code injection.
> ++  if (!bareIdentifier.test(argument)) throw new Error(
> ++

Bug#986172: unblock: dwarf-fortress/0.47_04+dfsg1-1

2021-03-31 Thread Sebastian Ramacher
Control: tags -1 confirmed moreinfo

On 2021-03-30 22:32:08, Sven Bartscher wrote:
> Package: release.debian.org
> Severity: normal
> User: release.debian@packages.debian.org
> Usertags: unblock
> 
> Please unblock package dwarf-fortress
> 
> [ Reason ]
> It has been noted in #986119 that the upstream release tarballs for
> dwarf-fortress include shared libraries but no corresponding source
> code is available. The shared libraries in question are licensed under
> GPL and thus not distributable without source code.
> 
> The affected files are not shipped in any binary packages. This
> update fixes the issue by repacking the source tarballs to exclude
> those files.
> 
> [ Impact ]
> The package is not distributable in its current form, so it has to be
> either updated or entirely removed from testing to cease violating the
> licenses of the affected files.
> 
> [ Tests ]
> The now excluded files were not shipped in any binary package or used
> in the build process. Their removal should not have any affect on the
> binary packages. I confirmed (using diffoscope) that the built debian
> packages do not differ in content except in expected ways due to
> changed package metadata and changes in the generaed manpage due to a
> newer pandoc version being used in the build.
> 
> I also manually confirmed that the game can be successfully started
> and basic interactions inside the game still work.
> 
> [ Risks ]
> Since the removed files are not part of any binary packages, it can be
> easily confirmed that their removal has no negative effect. I see
> virtually no risk introduced by this update.
> 
> [ Checklist ]
>   [x] all changes are documented in the d/changelog
>   [x] I reviewed all changes and I approve them
>   [x] attach debdiff against the package in testing
> 
> unblock dwarf-fortress/0.47_04+dfsg1-1

ACK, please remove the moreinfo tag once the new version is available in
unstable.

Cheers


> Binärdateien /tmp/x4E2O1qvMn/dwarf-fortress-0.47.04/amd64/libs/libgcc_s.so.1 
> und /tmp/ag24SxYJ0c/dwarf-fortress-0.47.04+dfsg1/amd64/libs/libgcc_s.so.1 
> sind verschieden.
> Binärdateien /tmp/x4E2O1qvMn/dwarf-fortress-0.47.04/amd64/libs/libstdc++.so.6 
> und /tmp/ag24SxYJ0c/dwarf-fortress-0.47.04+dfsg1/amd64/libs/libstdc++.so.6 
> sind verschieden.
> diff -Nru dwarf-fortress-0.47.04/debian/changelog 
> dwarf-fortress-0.47.04+dfsg1/debian/changelog
> --- dwarf-fortress-0.47.04/debian/changelog   2020-03-28 18:48:06.0 
> +0100
> +++ dwarf-fortress-0.47.04+dfsg1/debian/changelog 2021-03-30 
> 19:04:37.0 +0200
> @@ -1,3 +1,10 @@
> +dwarf-fortress (0.47.04+dfsg1-1) unstable; urgency=high
> +
> +  * Remove unnecessary code copies with license violations from source
> +tarball. (Closes: #986119)
> +
> + -- Sven Bartscher   Tue, 30 Mar 2021 19:04:37 
> +0200
> +
>  dwarf-fortress (0.47.04-1) unstable; urgency=low
>  
>* New upstream version
> diff -Nru dwarf-fortress-0.47.04/debian/copyright 
> dwarf-fortress-0.47.04+dfsg1/debian/copyright
> --- dwarf-fortress-0.47.04/debian/copyright   2020-03-28 18:48:06.0 
> +0100
> +++ dwarf-fortress-0.47.04+dfsg1/debian/copyright 2021-03-30 
> 19:04:37.0 +0200
> @@ -11,6 +11,15 @@
>   do not grant all freedoms required by the DFSG. No modifications of
>   the included binaries are permitted, and the binaries are not
>   distributed with source code.
> +Comment:
> + Some files have been removed from the original source tarballs, because
> + they are licensed under the GPL, but no source is available for them.
> +Files-Excluded-amd64:
> + libs/libgcc_s.so.1
> + libs/libstdc++.so.6
> +Files-Excluded-i386:
> + libs/libgcc_s.so.1
> + libs/libstdc++.so.6
>  
>  Files: *
>  Copyright: 2002-2020 Tarn Adams. All rights reserved.
> diff -Nru dwarf-fortress-0.47.04/debian/watch 
> dwarf-fortress-0.47.04+dfsg1/debian/watch
> --- dwarf-fortress-0.47.04/debian/watch   2020-03-28 18:48:06.0 
> +0100
> +++ dwarf-fortress-0.47.04+dfsg1/debian/watch 2021-03-30 19:04:37.0 
> +0200
> @@ -1,7 +1,7 @@
>  version=4
> -opts="uversionmangle=s/^/0./,component=amd64" \
> +opts="uversionmangle=s/^/0./,dversionmangle=s/\+dfsg\d+//,component=amd64" \
>https://bay12games.com/dwarves/older_versions.html \
>df_(\d+)_(\d+)_linux@ARCHIVE_EXT@ debian
> -opts="uversionmangle=s/^/0./,component=i386" \
> +opts="uversionmangle=s/^/0./,dversionmangle=s/\+dfsg\d+//,component=i386" \
>https://bay12games.com/dwarves/older_versions.html \
>df_(\d+)_(\d+)_linux32@ARCHIVE_EXT@ same
> Binärdateien /tmp/x4E2O1qvMn/dwarf-fortress-0.47.04/i386/libs/libgcc_s.so.1 
> und /tmp/ag24SxYJ0c/dwarf-fortress-0.47.04+dfsg1/i386/libs/libgcc_s.so.1 sind 
> verschieden.
> Binärdateien /tmp/x4E2O1qvMn/dwarf-fortress-0.47.04/i386/libs/libstdc++.so.6 
> und /tmp/ag24SxYJ0c/dwarf-fortress-0.47.04+dfsg1/i386/libs/libstdc++.so.6 
> sind verschieden.


-- 
Sebastian Ramacher



Bug#986183: procenv: broken symlink: /usr/share/doc/procenv/README -> README.rst

2021-03-31 Thread Andreas Beckmann
Package: procenv
Version: 0.51-0.2+exp2
Severity: normal
User: debian...@lists.debian.org
Usertags: piuparts

Hi,

during a test with piuparts I noticed your package ships (or creates)
a broken symlink.

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

0m24.7s ERROR: FAIL: Broken symlinks:
  /usr/share/doc/procenv/README -> README.rst (procenv)


cheers,

Andreas


procenv_0.51-0.2+exp2.log.gz
Description: application/gzip


Bug#986182: zaqar-common: fails to install: install: cannot stat '/usr/share/zaqar-common/policy.json': No such file or directory

2021-03-31 Thread Andreas Beckmann
Package: zaqar-common
Version: 12.0.0~rc1-1
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 zaqar-common (12.0.0~rc1-1) ...
  install: cannot stat '/usr/share/zaqar-common/policy.json': No such file or 
directory
  dpkg: error processing package zaqar-common (--configure):
   installed zaqar-common package post-installation script subprocess returned 
error exit status 1


cheers,

Andreas


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


Bug#663255: Bonjour

2021-03-31 Thread Sahra Serhane
Nous supprimons tous les comptes de messagerie inutilisés de l'année 2020 et 
augmentons la taille de la boîte aux lettres vers la version 2021 mise à 
niveau. Pour continuer à utiliser votre compte de messagerie, vous devez 
vérifier votre compte.

Tous les comptes non vérifiés seront supprimés 24 heures après avoir reçu cette 
notification.

Cliquez ici pour valider votre compte

et cliquez sur Soumettre pour continuer à utiliser votre compte zimbra.

Bug#897980: chromium-bsu: on play mode, after the first left click, game loose focus of mouse

2021-03-31 Thread Paul Wise
On Sat, 2021-03-27 at 10:51 +0100, trebor wrote:

> I am definitively using X11.

I've just tried it using Cinnamon X11 and GNOME X11 and Wayland. As far
as I can tell it only happens with GNOME Wayland when not using the
wayland video driver for SDL and not with Cinnamon or GNOME X11.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


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