Bug#985471: msmtp: Unable to send email with starttls if post-handshake new tls session ticket arrives

[Emmanuel Bouthenot]

Hi Rajeev,

On Thu, Mar 18, 2021 at 06:06:40PM -0400, Rajeev wrote:
[...]

> Thank you. I was able to fix the issue based on your comments.
What do you think about closing this bug?

Regards,

-- 
Emmanuel Bouthenot
  mail: kolter@{openics,debian}.orggpg: 4096R/0x929D42C3
  xmpp: kol...@im.openics.org  irc: kolter@{freenode,oftc}

Bug#986316: poke: incorrect homepage URL

[Paul Wise]

On Sat, 2021-04-03 at 22:35 -0400, Sergio Durigan Junior wrote:

> I talked to the upstream author.  He didn't confirm whether he intends
> to expand the gnu.org page or not.  He did, however, told me that it's
> better to link to the gnu.org page because he can't guarantee that his
> personal page's URL won't change in the future, so it's good to have a
> stable address.  I agree.

I see, thanks for confirming.

> Having said all of the above, I think that the best decision for now is
> to keep pointing to gnu.org/s/poke.  For this reason, I'm closing this
> bug and tagging it as "wontfix".

Agreed.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


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

Bug#986352: RFS: hid-nintendo-dkms/3.1-6 -- Nintendo HID kernel module.

[Witherking25]

Package: sponsorship-requests
Severity: wishlist

Dear mentors,

I am looking for a sponsor for my package "hid-nintendo-dkms":

* Package name : hid-nintendo-dkms
Version : 3.1-6
Upstream Author : 
* URL : https://github.com/nicman23/dkms-hid-nintendo
* License : GPL-2+
* Vcs : https://github.com/nicman23/dkms-hid-nintendo
Section : kernel

It builds those binary packages:

hid-nintendo-dkms - Nintendo HID kernel module.

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


https://mentors.debian.net/package/hid-nintendo-dkms/

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

dget -x 
https://mentors.debian.net/debian/pool/main/h/hid-nintendo-dkms/hid-nintendo-dkms_3.1-6.dsc


Changes for the initial release:

hid-nintendo-dkms (3.1-6) unstable; urgency=medium
.
* Fixed whitespace

Regards,

Bug#986353: RFS: hid-nintendo-dkms/3.1-6 -- Nintendo HID kernel module.

[Witherking25]

Package: sponsorship-requests
Severity: wishlist

Dear mentors,

I am looking for a sponsor for my package "hid-nintendo-dkms":

* Package name : hid-nintendo-dkms
Version : 3.1-6
Upstream Author : 
* URL : https://github.com/nicman23/dkms-hid-nintendo
* License : GPL-2+
* Vcs : https://github.com/nicman23/dkms-hid-nintendo
Section : kernel

It builds those binary packages:

hid-nintendo-dkms - Nintendo HID kernel module.

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


https://mentors.debian.net/package/hid-nintendo-dkms/

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

dget -x 
https://mentors.debian.net/debian/pool/main/h/hid-nintendo-dkms/hid-nintendo-dkms_3.1-6.dsc


Changes for the initial release:

hid-nintendo-dkms (3.1-6) unstable; urgency=medium
.
* Fixed whitespace

Regards,

Witherking25

Bug#986351: hplip: Printing Places All Jobs On Hold

[Roger]

Package: hplip
Version: 3.18.12+dfsg0-2
Severity: grave
Tags: upstream
Justification: renders package unusable

Dear Maintainer,

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

   * What led up to the situation?
Unknown
   * What exactly did you do (or not do) that was effective (or
 ineffective)?
Reboot, reinstall printer, reinstall hplip, reinstall cups
   * What was the outcome of this action?
Nothing
   * What outcome did you expect instead?

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



-- Package-specific info:
Saving output in log file: /home/jolly/hp-check.log

HP Linux Imaging and Printing System (ver. 3.18.12)
Dependency/Version Check Utility ver. 15.1

Copyright (c) 2001-15 HP Development Company, LP
This software comes with ABSOLUTELY NO WARRANTY.
This is free software, and you are welcome to distribute it
under certain conditions. See COPYING file for more details.

Note: hp-check can be run in three modes:
1. Compile-time check mode (-c or --compile): Use this mode  
before compiling the HPLIP supplied tarball (.tar.gz or .run) to 
determine if the proper dependencies are installed to
successfully compile HPLIP.  
2. Run-time check mode (-r or --run): Use this mode to determine 
if a distro supplied package (.deb, .rpm, etc) or an already 
built HPLIP supplied tarball has the proper dependencies 
installed to successfully run.   
3. Both compile- and run-time check mode (-b or --both)  
(Default): This mode will check both of the above cases (both
compile- and run-time dependencies). 

Check types: 
a. EXTERNALDEP - External Dependencies   
b. GENERALDEP - General Dependencies (required both at compile   
and run time)
c. COMPILEDEP - Compile time Dependencies
d. [All are run-time checks] 
PYEXT SCANCONF QUEUES PERMISSION 

Status Types:
OK
MISSING   - Missing Dependency or Permission or Plug-in
INCOMPAT  - Incompatible dependency-version or Plugin-version

Gtk-Message: 21:15:47.063: Failed to load module "atk-bridge"
Traceback (most recent call last):
  File "/usr/share/hplip/base/utils.py", line 265, in walkFiles
names = os.listdir(root)
FileNotFoundError: [Errno 2] No such file or directory: '/etc/PolicyKit'

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/usr/share/hplip/base/utils.py", line 267, in walkFiles
raise StopIteration
StopIteration

The above exception was the direct cause of the following exception:

Traceback (most recent call last):
  File "/usr/bin/hp-check", line 861, in 
dep.core.init()
  File "/usr/share/hplip/installer/core_install.py", line 527, in init
self.check_dependencies(callback)
  File "/usr/share/hplip/installer/core_install.py", line 620, in 
check_dependencies
self.have_dependencies[d] = self.dependencies[d][3]()
  File "/usr/share/hplip/installer/core_install.py", line 1241, in 
check_policykit
if check_file('PolicyKit.conf', "/etc/PolicyKit") and 
check_file('org.gnome.PolicyKit.AuthorizationManager.service', 
"/usr/share/dbus-1/services"):
  File "/usr/share/hplip/installer/dcheck.py", line 107, in check_file
for w in utils.walkFiles(dir, recurse=True, abs_paths=True, 
return_folders=False, pattern=f):
RuntimeError: generator raised StopIteration

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

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

Versions of packages hplip depends on:
ii  adduser3.118
ii  cups   2.2.10-6+deb10u4
ii  hplip-data 3.18.12+dfsg0-2
ii  libc6  2.28-10
ii  libcups2   2.2.10-6+deb10u4
ii  libdbus-1-31.12.20-0+deb10u1
ii  libhpmud0  3.18.12+dfsg0-2
ii  libpython3.7   3.7.3-2+deb10u3
ii  libsane1.0.27-3.2
ii  libsane-hpaio  3.18.12+dfsg0-2
ii  libsnmp30  5.7.3+dfsg-5+deb10u2
ii  libusb-1.0-0   2:1.0.22-2
ii  lsb-base   10.2019051400
ii  printer-driver-hpcups  3.18.12+dfsg0-2
ii  python33.7.3-1
ii  python3-dbus   1.2.8-3
ii  python3-gi 3.30.4-1
ii  python3-pexpect4.6.0-1
ii  python3-pil5.4.1-2+deb10u2
ii  python3-reportlab  3.5.13-1+deb10u1
ii  wget   1.20.1-1.1
ii  xz-utils   

Bug#986350: ITP: hid-nintendo-dkms -- Nintendo HID kernel module

[Witherking25]

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

* Package name: hid-nintendo-dkms
  Version : 3.1
  Upstream Author : nicman23 
* URL : https://github.com/nicman23/dkms-hid-nintendo
* License : (GPL2)
  Programming Lang: (C)
  Description : Nintendo HID kernel module

hid-nintendo-dkms is a dkms module that adds a driver for 
 nintendo switch joycons. joycond requires this module to function.

Bug#871446: jemalloc: FTBFS on hurd-i386: aligned_alloc test hangs

[Samuel Thibault]

Hello,

Faidon Liambotis, le lun. 11 janv. 2021 01:33:34 +0200, a ecrit:
> I'm still unsure why either test fail the way they do¹. Like the last
> time I was debugging this bug... gdb'ing the aligned-alloc test doesn't
> work (can't interrupt execution). What's worse is that even running "ps"
> in a different console hangs while the test is running.

That's because the process is hung hard, see 
https://www.gnu.org/software/hurd/faq/ps_hangs.html
Using the -M option gets less information but doesn't hang.

> So something seems weird with the system, that's not jemalloc
> related...

It is :)

Attaching with gdb from outside, I get:

#0  0x0111e69c in mach_msg_trap () at 
./build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2
#1  0x0111ee46 in __GI___mach_msg (msg=0x103281c, option=3, send_size=64, 
rcv_size=32, rcv_name=51, timeout=0, notify=0) at msg.c:111
#2  0x01577612 in __gsync_wait (task=1, addr=17642300, val1=2, val2=0, msec=0, 
flags=0) at ./build-tree/hurd-i386-libc/mach/RPC_gsync_wait.c:175
#3  0x010f1923 in __pthread_mutex_lock (mtxp=0x10d333c ) at 
../sysdeps/mach/hurd/htl/pt-mutex-lock.c:36
#4  0x01086308 in malloc_mutex_lock_final (mutex=0x10d3300 ) at 
include/jemalloc/internal/mutex.h:155
#5  je_malloc_mutex_lock_slow (mutex=0x10d3300 ) at src/mutex.c:85
#6  0x0103f7bc in malloc_mutex_lock (mutex=0x10d3300 , tsdn=0x0) at 
include/jemalloc/internal/mutex.h:221
#7  malloc_init_hard () at src/jemalloc.c:1740
#8  0x01041d65 in malloc_init () at src/jemalloc.c:210
#9  imalloc_init_check (dopts=, sopts=) 
at src/jemalloc.c:2230
#10 imalloc (dopts=, sopts=) at 
src/jemalloc.c:2261
#11 je_malloc_default (size=100) at src/jemalloc.c:2290
#12 0x010423a2 in malloc (size=) at src/jemalloc.c:2389
#13 0x011af9a5 in __vasprintf_internal (result_ptr=0x1032b24, format=0x12d39a4 
"%s%s%s:%u: %s%sAssertion `%s' failed.\n%n",
args=0x1032ae8 "\357\352,\001\357\352,\001'f\017\001\034", mode_flags=0) at 
vasprintf.c:45
#14 0x0118c367 in ___asprintf (string_ptr=0x1032b24, format=0x12d39a4 
"%s%s%s:%u: %s%sAssertion `%s' failed.\n%n") at asprintf.c:31
#15 0x0116302a in __assert_fail_base (fmt=0x12d39a4 "%s%s%s:%u: %s%sAssertion 
`%s' failed.\n%n", assertion=0x10f6631 "self != NULL", file=0x10f6627 
"pt-self.c",
line=28, function=0x10f6640 <__PRETTY_FUNCTION__.1> "__pthread_self") at 
assert.c:57
#16 0x01163129 in __GI___assert_fail (assertion=0x10f6631 "self != NULL", 
file=0x10f6627 "pt-self.c", line=28,
function=0x10f6640 <__PRETTY_FUNCTION__.1> "__pthread_self") at assert.c:101
#17 0x010f12cf in __pthread_self () at pt-self.c:28
#18 __pthread_self () at pt-self.c:25
#19 0x0103f58d in malloc_init_hard_needed () at src/jemalloc.c:1455
#20 malloc_init_hard () at src/jemalloc.c:1746
#21 0x01041d65 in malloc_init () at src/jemalloc.c:210
#22 imalloc_init_check (dopts=, sopts=) 
at src/jemalloc.c:2230
#23 imalloc (dopts=, sopts=) at 
src/jemalloc.c:2261
#24 je_malloc_default (size=708) at src/jemalloc.c:2290
#25 0x010423a2 in malloc (size=) at src/jemalloc.c:2389
#26 0x010f054d in __pthread_alloc (pthread=0x1032cb0) at pt-alloc.c:125
#27 0x010f0884 in __pthread_create_internal (thread=0x1032cf8, attr=0x0, 
start_routine=0x0, arg=0x0) at pt-create.c:99
#28 0x010f4a3b in _init_routine (stack=0x0) at 
../sysdeps/mach/hurd/htl/pt-sysdep.c:73
#29 0x01154c14 in init (data=0x1032d60) at 
../sysdeps/mach/hurd/i386/init-first.c:209
#30 _dl_init_first (argc=) at 
../sysdeps/mach/hurd/i386/init-first.c:325
#31 0x220d in _dl_start_user () from /lib/ld.so

So basically libpthread is trying to initialize itself, calls malloc,
which initializes jemalloc, which calls pthread_self, which is not happy
that libpthread is not initialized yet, thus calls assert, which tries
to malloc as well, which tries (again!) to initialize jemalloc, and
gets stuck on mutex_lock. And since this is all happening at very early
initialization of libc, interaction with ps etc. is not possible yet.

I tried to make __pthread_alloc avoid using malloc, but then I got
instead

#24 je_malloc_default (size=4348) at src/jemalloc.c:2290
#25 0x010423a2 in malloc (size=) at src/jemalloc.c:2389
#26 0x00013b08 in _dl_allocate_tls_storage () at dl-tls.c:403
#27 0x00013e65 in _dl_allocate_tls (mem=0x0) at dl-tls.c:588
#28 0x010e1a0e in __pthread_create_internal (thread=0x1032cf8, attr=0x0, 
start_routine=0x0, arg=0x0) at pt-create.c:151
#29 0x010e5b1b in _init_routine (stack=0x0) at 
../sysdeps/mach/hurd/htl/pt-sysdep.c:73
#30 0x01154c14 in init (data=0x1032d60) at 
../sysdeps/mach/hurd/i386/init-first.c:209
#31 _dl_init_first (argc=) at 
../sysdeps/mach/hurd/i386/init-first.c:325
#32 0x220d in _dl_start_user () from /lib/ld.so

Thus the same issue, and changing _dl_allocate_tls is a way more
involved thing. I tried another approach by making pthread_self() return
the id of the initial thread withouth checks, but then I get a crash on

#0  __pthread_mutex_lock (mtxp=0x10ed1a0 <__pthread_key_lock>) at 
../sysdeps/mach/hurd/htl/pt-mutex-lock.c:41
#1  

Bug#986285: RE : geneweb: new version 7.0.0 available since Oct 2020

[Guillaume Brochu]

Hi,

Thanks for reporting.

I know that Geneweb 7.0.0 has been available since last October. However,
there are so many changes in 7.0.0 from 6.08 that it will require a
complete rewrite of the Debian package.

I felt the deadline was too short for Bullseye, but this job needs to be
completed for Bookworm of course.

With best regards,


Guillaume Brochu

Bug#986349: db.c: always close file pointer "actfp"

[Bjarni Ingi Gislason]

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

Dear Maintainer,

>From 70ac18c4ec83348259c613d1801e24b50731fcc6 Mon Sep 17 00:00:00 2001
>From: Bjarni Ingi Gislason 
>Date: Sat, 3 Apr 2021 23:43:04 +
>Subject: [PATCH] db.c: always close file pointer "actfp"

  File pointer "actfp" is opened independent of the use of NNTP or not
("use_nntp").

  Should silence a warning:

db.c:1252:12: warning: leak of FILE 'actfp' [CWE-775] [-Wanalyzer-file-leak]
 1252 | grplist[count] = NULL;
  |^
...
   | 1251 | actlist[count] = NULL;
   | 1252 | grplist[count] = NULL;
   |  |~
   |  ||
   |  |(26) 'actfp' leaks here; was opened at (10)

Signed-off-by: Bjarni Ingi Gislason 
---
 db.c | 6 ++
 1 file changed, 2 insertions(+), 4 deletions(-)

diff --git a/db.c b/db.c
index 15a9372..bd10cc4 100644
--- a/db.c
+++ b/db.c
@@ -1092,8 +1092,7 @@ readactfile(void)
 }
 stp->n.next = NULL;
 
-if (!use_nntp)
-   (void) fclose(actfp);
+(void) fclose(actfp);
 
 actlist = (char **) calloc(count + 1, sizeof(char *));
 grplist = (char **) calloc(count + 1, sizeof(char *));
@@ -1218,8 +1217,7 @@ readpartactfile(void)
 }
 stp->n.next = NULL;
 
-if (!use_nntp)
-   (void) fclose(actfp);
+(void) fclose(actfp);
 
 actlist = (char **) calloc(count + 1, sizeof(char *));
 grplist = (char **) calloc(count + 1, sizeof(char *));
-- 
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#986348: db.c: give the compiler information about the subroutine "nn_exitmsg()" that uses "exit()"

[Bjarni Ingi Gislason]

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

Dear Maintainer,

>From 6870dd7c11a62bf6713b0c0dc2790a2f8207bc11 Mon Sep 17 00:00:00 2001
>From: Bjarni Ingi Gislason 
>Date: Sat, 3 Apr 2021 22:59:32 +
>Subject: [PATCH] db.c: give the compiler information about the subroutine
> "nn_exitmsg()" that uses "exit()"

  "nn_exitmsg()" exits the program, so the compiler does not know that
when analyzing execution paths.

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

diff --git a/db.c b/db.c
index c55fa3f..15a9372 100644
--- a/db.c
+++ b/db.c
@@ -1039,6 +1039,8 @@ readactfile(void)
 
 if (actfp == NULL) {
nn_exitmsg(1, "could not fetch active file from %s\n", source);
+/* Give the compiler information about the exit of the previous line */
+   exit(1);
 }
 
 /*
@@ -1075,6 +1077,8 @@ readactfile(void)
 
if (stnew == NULL) {
nn_exitmsg(1, "Out of memory for active file (at line %d)\n", count 
+ 1);
+/* Give the compiler information about the exit of the previous line */
+   exit(1);
}
 
if (sthead != NULL) {
@@ -1097,6 +1101,8 @@ readactfile(void)
 if (grplist == NULL) {
nn_exitmsg(1, "can't create active or group list (%d entries)\n",
   count + 1);
+/* Give the compiler information about the exit of the previous line */
+   exit(1);
 }
 
 /*
@@ -1150,6 +1156,8 @@ readpartactfile(void)
 
 if (actfp == NULL) {
nn_exitmsg(1, "could not open .newsrc file %s\n", newsrc_file);
+/* Give the compiler information about the exit of the previous line */
+   exit(1);
 }
 
 /*
@@ -1196,6 +1204,8 @@ readpartactfile(void)
stlist_t *stnew = (stlist_t *) strkeep(actline, sizeof(stlisthdr_t), 
POOL_ACT);
if (stnew == NULL) {
nn_exitmsg(1, "Out of memory for active file (at line %d)\n", count 
+ 1);
+/* Give the compiler information about the exit of the previous line */
+   exit(1);
}
if (sthead != NULL) {
stp->n.next = stnew;
@@ -1399,6 +1409,8 @@ readtimfile(void)
 timtbl = hashcreate(hsize, (unsigned (*) ()) NULL);
 if (timtbl == NULL) {
nn_exitmsg(1, "can't create time hash (%d entries)\n", hsize);
+/* Give the compiler information about the exit of the previous line */
+   exit(1);
 }
 
 if (new_group_action == RCX_NEVER)
@@ -1439,6 +1451,8 @@ readtimfile(void)
*p++ = NUL;
if (!hashstore(timtbl, line, p)) {
nn_exitmsg(1, "nn: time hashstore failed\n");
+/* Give the compiler information about the exit of the previous line */
+   exit(1);
}
count++;
 }
@@ -1649,6 +1663,9 @@ db_init_group(register group_header * gh, int num)
gh->group_name = grplist[num];
if (gh->group_name == NULL) {
nn_exitmsg(1, "can't map group %d to name\n", num);
+/* Give the compiler information about the exit of the previous line */
+   exit(1);
+
}
gh->group_name_length = strlen(gh->group_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#986347: ITP: kernelshark -- Utilities for graphically analyzing function tracing in the kernel

[Sudip Mukherjee]

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

* Package name: kernelshark
  Version : v1.3
  Upstream Author : Steven Rostedt 
Yordan Karadzhov (VMware) 
* URL : 
https://git.kernel.org/pub/scm/utils/trace-cmd/kernel-shark.git/
* License : GPL-2 and LGPL-2.1
  Programming Lang: C++
  Description : Utilities for graphically analyzing function tracing in the 
kernel.

Data for analysis may be generated by the trace-cmd utility.

kernelshark is already available in Debian as part of trace-cmd but upstream
has now decided to move kernelshark to its own repo at:
https://git.kernel.org/pub/scm/utils/trace-cmd/kernel-shark.git and the 
announcement
is at 
https://git.kernel.org/pub/scm/utils/trace-cmd/trace-cmd.git/tag/?h=trace-cmd-v2.9.2


--
Regards
Sudip

Bug#986346: roundcube-plugins-extra: Please add twofactor_gauthenticator

[Daniel Lo Nigro]

Package: roundcube-plugins-extra
Version: 1.4.10+1-3
Severity: wishlist

Dear Maintainer,

Please consider adding the "twofactor_gauthenticator" plugin to this package.

Upstream URL: https://github.com/alexandregz/twofactor_gauthenticator

Thanks!


-- 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-3-amd64 (SMP w/3 CPU threads)
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 roundcube-plugins-extra depends on:
ii  roundcube-core  1.4.11+dfsg.1-3

roundcube-plugins-extra recommends no packages.

Versions of packages roundcube-plugins-extra suggests:
ii  fail2ban  0.11.2-1

-- no debconf information

Bug#986345: unblock: rxvt-unicode/9.22-10

[Ryan Kavanagh]

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

Please unblock package rxvt-unicode

[ Reason ]

Fixes a segfault on exit

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=981010

[ Tests ]

Patch cherry-picked from upstream. Fixed upstream ~9 months ago.

I cannot reproduce the segfault on exit.

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

[ Other info ]

Still too young for migration (currently 14/20 days old), so this is
just a proactive unblock request before I forget about it.

unblock rxvt-unicode/9.22-10

-- 
|)|/  Ryan Kavanagh  | GPG: 4E46 9519 ED67 7734 268F
|\|\  https://rak.ac |  BD95 8F7B F8FC 4A11 C97A
diff -Nru rxvt-unicode-9.22/debian/changelog rxvt-unicode-9.22/debian/changelog
--- rxvt-unicode-9.22/debian/changelog  2020-07-29 11:48:03.0 -0400
+++ rxvt-unicode-9.22/debian/changelog  2021-03-20 12:48:03.0 -0400
@@ -1,3 +1,16 @@
+rxvt-unicode (9.22-10) unstable; urgency=medium
+
+  * Correct a mistake in 19_sigsegv_perl_environ.diff
+
+ -- Ryan Kavanagh   Sat, 20 Mar 2021 12:48:03 -0400
+
+rxvt-unicode (9.22-9) unstable; urgency=medium
+
+  * Fix segfault at exit, 19_sigsegv_perl_environ.diff (Closes: #981010)
+  * Bump copyright years
+
+ -- Ryan Kavanagh   Sat, 20 Mar 2021 10:18:47 -0400
+
 rxvt-unicode (9.22-8) unstable; urgency=medium
 
   * Fix incorrect manpage output due to 12_hyphen_minus_sign.diff
diff -Nru rxvt-unicode-9.22/debian/copyright rxvt-unicode-9.22/debian/copyright
--- rxvt-unicode-9.22/debian/copyright  2018-01-04 13:46:13.0 -0500
+++ rxvt-unicode-9.22/debian/copyright  2021-03-20 10:18:33.0 -0400
@@ -40,7 +40,7 @@
 Copyright:
 Copyright (C) 2004-2006  Eduard Bloch 
 Copyright (C) 2006-2011  Decklin Foster 
-Copyright (C) 2011-2017  Ryan Kavanagh 
+Copyright (C) 2011-2021  Ryan Kavanagh 
 License: GPL-2.0+
 
 Files: debian/extensions/urxvt-font-size/*
diff -Nru rxvt-unicode-9.22/debian/patches/19_sigsegv_perl_environ.diff 
rxvt-unicode-9.22/debian/patches/19_sigsegv_perl_environ.diff
--- rxvt-unicode-9.22/debian/patches/19_sigsegv_perl_environ.diff   
1969-12-31 19:00:00.0 -0500
+++ rxvt-unicode-9.22/debian/patches/19_sigsegv_perl_environ.diff   
2021-03-20 12:48:03.0 -0400
@@ -0,0 +1,41 @@
+Description: Fix segfault on exit
+ Slightly tweaked version of upstream patch listed in Origin:
+Author: Ryan Kavanagh 
+Origin: http://cvs.schmorp.de/rxvt-unicode/src/rxvtperl.xs?r1=1.246=1.247
+http://cvs.schmorp.de/rxvt-unicode/src/rxvtperl.h?r1=1.28=1.29
+Bug-Debian: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=981010
+Last-Update: 2021-03-20
+---
+This patch header follows DEP-3: http://dep.debian.net/deps/dep3/
+--- rxvt-unicode/src/rxvtperl.xs   2020/01/20 09:35:12 1.246
 rxvt-unicode/src/rxvtperl.xs   2020/06/30 07:31:24 1.247
+@@ -372,6 +372,9 @@
+ 
+ static PerlInterpreter *perl;
+ 
++#if 0 /* we are not a library anymore, so doing this is just not worth it */
++/*THINK/TODO: this has the side effect of, of course, not calling 
destructors. */
++/* but therse are not guaranteed anyway... */
+ rxvt_perl_interp::~rxvt_perl_interp ()
+ {
+   if (perl)
+@@ -381,6 +384,7 @@
+   PERL_SYS_TERM ();
+ }
+ }
++#endif
+ 
+ void
+ rxvt_perl_interp::init ()
+--- rxvt-unicode/src/rxvtperl.h2012/06/12 10:45:53 1.28
 rxvt-unicode/src/rxvtperl.h2020/06/30 07:31:24 1.29
+@@ -51,7 +51,9 @@
+ {
+   char **perl_environ;
+ 
++  #if 0 // see rxvtperl.xs
+   ~rxvt_perl_interp ();
++  #endif
+ 
+   void init ();
+   void init (rxvt_term *term);
diff -Nru rxvt-unicode-9.22/debian/patches/series 
rxvt-unicode-9.22/debian/patches/series
--- rxvt-unicode-9.22/debian/patches/series 2020-07-27 16:12:41.0 
-0400
+++ rxvt-unicode-9.22/debian/patches/series 2021-03-20 12:48:03.0 
-0400
@@ -8,3 +8,4 @@
 16_no_terminfo.diff
 17_unsafe_man.diff
 18_expand_urxvt-tabbed.1.diff
+19_sigsegv_perl_environ.diff


signature.asc
Description: PGP signature

Bug#986344: unblock (pre-approval): gimp/2.10.22-4

[Simon McVittie]

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

I'd like permission to upload gimp with improved dependency handling.

[ Reason ]
Fix dependencies to make partial upgrades safer

[ Impact ]
Without these changes, users who do partial upgrades from buster might
encounter one of these failure modes:
* libbabl-0.1-0 is an insufficent version, causing gimp to refuse to start
  (#983568)
* liblcms2-2 is a version older than the one gimp was compiled against,
  which gimp wrongly thinks means it's insufficient, causing gimp to refuse
  to start if buster's version of liblcms (which satisifies its dependency
  and has all the required symbols) is still installed (#900819, #986192)

Additionally, the message printed for #900819, #986192 is really confusing,
because it implies that version 2.9 is less than the version "2.2" that
gimp_2.10.22-3 was compiled against. It was really compiled against 2.12;
gimp compares the encoded version numbers 2090 and 2120 correctly, but
then parses the encoded version number 2120 incorrectly when formatting
the error message.

[ Tests ]
For brevity "old gimp" refers to 2.10.22-3 in testing and "new gimp" is
the proposed version.

For #900819, #986192: on a Debian 11 / GNOME virtual machine:
* old gimp correctly launches normally with liblcms2-2 from Debian 11
  (v2.12)
* old gimp wrongly fails to launch, with a confusing error message, when
  liblcms2-2 from buster (v2.9) or stretch (v2.8) is LD_PRELOADed
* old gimp correctly fails to launch when a mock implementation of
  cmsGetEncodedCMMversion() that returns 1234 (indicating liblcms2-2
  v1.23.4) is LD_PRELOADed, but the error message wrongly describes the
  version number as 1.3
* new gimp correctly launches normally with liblcms2-2 from Debian 11
* new gimp correctly launches normally with liblcms2-2 from buster or
  stretch LD_PRELOADed
* new gimp correctly fails to launch when a mock implementation of
  cmsGetEncodedCMMversion() that returns 1234 is LD_PRELOADed, but this
  time the error message correctly describes it as version 1.23

For #983568: `apt-cache show gimp` indicates that old gimp wrongly
Depends: libbabl-0.1-0 (>= 0.1.10). `dpkg -s gimp` indicates that new
gimp correctly Depends: libbabl-0.1-0 (>= 0.1.78).

[ Risks ]
This is a high-visibility package, but the changes are trivial.

[ 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 gimp/2.10.22-4
diffstat for gimp-2.10.22 gimp-2.10.22

 changelog  |   23 
 patches/01_hurd_ftbfs.patch|3 
 patches/02_hurd_ftbfs.patch|   13 ++
 patches/app-Don-t-second-guess-the-dependency-system.patch |   56 ++
 patches/app-Print-2-digit-LittleCMS-minor-versions-correctly.patch |   41 +++
 patches/series |2 
 shlibs.local   |1 
 7 files changed, 137 insertions(+), 2 deletions(-)

diff -Nru gimp-2.10.22/debian/changelog gimp-2.10.22/debian/changelog
--- gimp-2.10.22/debian/changelog	2021-03-20 11:21:08.0 +
+++ gimp-2.10.22/debian/changelog	2021-04-03 23:21:59.0 +0100
@@ -1,3 +1,26 @@
+gimp (2.10.22-4) unstable; urgency=medium
+
+  * Team upload
+
+  [ Laurent Bigonville ]
+  * Drop debian/shlibs.local, not needed anymore.
+This file has the adverse effect of lowering the required version of
+libbabl-0.1-0. The library now ships a .symbols file with
+Build-Depends-Package, so let dh_shlibs adjust the dependency version
+automatically (Closes: #983568)
+
+  [ Simon McVittie ]
+  * d/p/app-Print-2-digit-LittleCMS-minor-versions-correctly.patch:
+Print 2-digit lcms minor versions correctly. Related to #900819, #986192.
+  * d/p/app-Don-t-second-guess-the-dependency-system.patch:
+Don't require lcms runtime version >= compile-time version.
+If no new symbols referenced by GIMP have been introduced (as is the
+case when upgrading from 2.9 to 2.12~rc1), we only need a dependency
+on version 2.9. (Closes: #900819, #986192)
+  * d/p/*_hurd_ftbfs.patch: Add patch metadata
+
+ -- Simon McVittie   Sat, 03 Apr 2021 23:21:59 +0100
+
 gimp (2.10.22-3) unstable; urgency=medium
 
   * debian/control.in: Add graphviz to the dependencies.
diff -Nru gimp-2.10.22/debian/patches/01_hurd_ftbfs.patch gimp-2.10.22/debian/patches/01_hurd_ftbfs.patch
--- gimp-2.10.22/debian/patches/01_hurd_ftbfs.patch	2021-03-20 11:21:08.0 +
+++ gimp-2.10.22/debian/patches/01_hurd_ftbfs.patch	2021-04-03 23:21:59.0 +0100
@@ -2,7 +2,8 @@
 Date: Sun, 1 Apr 2018 17:43:04 -0400
 Subject: Define PATH_MAX to fix build on the Hurd.
 
-Forwarded: no
+Forwarded: 

Bug#957547: mlucas: ftbfs with GCC-10

[Logan Rosen]

Control: tags -1 patch

Hi,

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

  * d/p/gcc-10.diff: Remove duplicate variable declaration to fix FTBFS with
GCC 10.

Thanks for considering the patch.

Logan
diff -Nru mlucas-17.1/debian/patches/gcc-10.diff 
mlucas-17.1/debian/patches/gcc-10.diff
--- mlucas-17.1/debian/patches/gcc-10.diff  1969-12-31 19:00:00.0 
-0500
+++ mlucas-17.1/debian/patches/gcc-10.diff  2021-04-03 17:44:31.0 
-0400
@@ -0,0 +1,10 @@
+--- a/src/gcd_lehmer.c
 b/src/gcd_lehmer.c
+@@ -49,7 +49,6 @@
+   WARNING: level-2 diagnostics not recommended for large 
vectors!
+ */
+   int fft_gcd_debug = 0;
+-  FILE *fp;
+   static char *file_access_mode[2] = {"a","w"};
+   char string0[STR_MAX_LEN];
+ #if GCD_DEBUG >= 1
diff -Nru mlucas-17.1/debian/patches/series mlucas-17.1/debian/patches/series
--- mlucas-17.1/debian/patches/series   2020-01-10 12:32:35.0 -0500
+++ mlucas-17.1/debian/patches/series   2021-04-03 17:44:31.0 -0400
@@ -3,3 +3,4 @@
 fix-c-identifier-typo.diff
 display-verbose-test-log.diff
 python2.diff
+gcc-10.diff

Bug#986342: python3-lxml: RelaxNG validator sometimes incorrectly reports errors in XML

[Wojciech Zabołotny]

 I attach the archive mentioned in the original report (that I forgot to
attach).

I have also resubmitted the bug with the archive included.




bug_demo.tar.gz
Description: application/gzip

Bug#986333: debian-security-support: Match ecosystems with limited support

[Holger Levsen]

Hi Sylvain,

On Sat, Apr 03, 2021 at 03:32:02PM +0200, Sylvain Beucler wrote:
> Sometimes, entire ecosystems are affected by Debian support decisions.
[...]
> Currently 'check-support-status' fails to detect individual packages
> affected by these decisions, it only notifies about explicitly
> referenced packages such as 'nodejs'.
> Maybe regex matching would help.

indeed & thanks for filing this bug report!

> (debian-security-support is an important tool in the Debian LTS/ELTS
> offering, so I believe we could offer help/time in this area.)
> 
> What do you think?

I think this is a useful feature indeed and I'd be very happy about patches,
MRs or plain commits. debian-security-support is maintained in the Debian
group on Salsa, so any DD can commit, though I'll equally happily take 
review requests :)


-- 
cheers,
Holger

 ⢀⣴⠾⠻⢶⣦⠀
 ⣾⠁⢠⠒⠀⣿⡁   holger@(debian|reproducible-builds|layer-acht).org
 ⢿⡄⠘⠷⠚⠋⠀ PGP fingerprint: B8BF 5413 7B09 D35C F026 FE9D 091A B856 069A AA1C
 ⠈⠳⣄

Because things are the way they are, things will not stay the way they are.
(Bertolt Brecht)


signature.asc
Description: PGP signature

Bug#986343: python3-lxml: RelaxNG validator sometimes incorrectly reports errors in XML

[Wojciech Zabołotny]

Package: python3-lxml
Version: 4.6.3-1
Severity: important

Dear Maintainer,

The Relax NG validator does not correctly detect the errors in the XML file.
The simple set of files reconstructing the problem is attached in archive
"bug_demo.tar.gz".
The agwb.rng defines the XML schema. The example1.xml contains the
conforming
xml file.
The example1a.xml file has an error - field "B2" in creg "X2" does not
contain
required "width" attribute.
The example1b.xml has another error - the attribute "name" in block SYS1
is written as "nafme".

Validating the erroneous files, however, gives incorrect results.
The tests are performed both with Python lxml module and with xmllint
utility.
The errors are similar, so probably the error is located in the lxml
library.

$ ./test0.sh example1a.xml
[...]
example1a.xml:11: element field: Relax-NG validity error : Element field
failed to validate attributes
example1a.xml:10: element field: Relax-NG validity error : Element creg
has extra content: field
Relax-NG validity error : Extra element creg in interleave
example1a.xml:9: element creg: Relax-NG validity error : Element block
failed to validate content
Relax-NG validity error : Extra element block in interleave
example1a.xml:3: element block: Relax-NG validity error : Element sysdef
failed to validate content
example1a.xml fails to validate

$ ./test0.py example1a.xml False
example1a.xml:11:0:ERROR:RELAXNGV:RELAXNG_ERR_ATTRVALID: Element field
failed to validate attributes
example1a.xml:10:0:ERROR:RELAXNGV:RELAXNG_ERR_EXTRACONTENT: Element creg
has extra content: field
:0:0:ERROR:RELAXNGV:RELAXNG_ERR_INTEREXTRA: Extra element creg
in interleave
example1a.xml:9:0:ERROR:RELAXNGV:RELAXNG_ERR_CONTENTVALID: Element block
failed to validate content
:0:0:ERROR:RELAXNGV:RELAXNG_ERR_INTEREXTRA: Extra element block
in interleave
example1a.xml:3:0:ERROR:RELAXNGV:RELAXNG_ERR_CONTENTVALID: Element
sysdef failed to validate content

The error message lacks specifity. There should be a detailed
information about the lacking field.
In case of example1b.xml the situation is even worse:

$ ./test0.sh example1b.xml example1b.xml:3: element block: Relax-NG
validity error : Expecting an element sreg, got nothing
Relax-NG validity error : Extra element block in interleave
example1b.xml:3: element block: Relax-NG validity error : Element sysdef
failed to validate content
example1b.xml fails to validate

./test0.py example1b.xml False
example1b.xml:3:0:ERROR:RELAXNGV:RELAXNG_ERR_NOELEM: Expecting an
element sreg, got nothing
:0:0:ERROR:RELAXNGV:RELAXNG_ERR_INTEREXTRA: Extra element block
in interleave
example1b.xml:3:0:ERROR:RELAXNGV:RELAXNG_ERR_CONTENTVALID: Element
sysdef failed to validate content

There is absolutely no reason to expect "sreg" element in a "sysdef". It
is against the defined schema.

However, if I convert the schema to the DTD:

$ trang -I rng -O dtd agwb.rng agwb.dtd
then the further validations wit DTD give the correct results for both
erroneous files:

$ ./test1.sh example1a.xml [...]
example1a.xml:11: element field: validity error : Element field does not
carry attribute width
Document example1a.xml does not validate against agwb.dtd

$ ./test1.py example1a.xml False
example1a.xml:11:0:ERROR:VALID:DTD_MISSING_ATTRIBUTE: Element field does
not carry attribute width

$ ./test1.sh example1b.xml [...]
example1b.xml:3: element block: validity error : Element block does not
carry attribute name
example1b.xml:3: element block: validity error : No declaration for
attribute nafme of element block
Document example1b.xml does not validate against agwb.dtd

$ ./test1.py example1b.xml False
example1b.xml:3:0:ERROR:VALID:DTD_MISSING_ATTRIBUTE: Element block does
not carry attribute name
example1b.xml:3:0:ERROR:VALID:DTD_UNKNOWN_ATTRIBUTE: No declaration for
attribute nafme of element block

The above reports precisely describe errors in the validated files.
Therefore the problem is rather not in the Relax NG scheme definition
but in the validator itself.

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

Kernel: Linux 5.10.0-5-amd64 (SMP w/12 CPU threads)
Locale: LANG=pl_PL.UTF-8, LC_CTYPE=pl_PL.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 python3-lxml depends on:
ii libc6 2.31-10
ii libxml2 2.9.10+dfsg-6.3+b1
ii libxslt1.1 1.1.34-4
ii python3 3.9.2-2

Versions of packages python3-lxml recommends:
ii python3-bs4 4.9.3-1
ii python3-html5lib 1.1-3

Versions of packages python3-lxml suggests:
pn python-lxml-doc 
pn python3-lxml-dbg 

-- no debconf information



bug_demo.tar.gz
Description: application/gzip

Bug#986341: unblock: neomutt/20201127+dfsg.1-1.1

[Ryan Kavanagh]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
X-Debbugs-Cc: r...@debian.org
Control: blocks -1 980427

Please unblock package neomutt

[ Reason ]

Fixes a screen rendering bug:

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=980427

[ Impact ]

Without this patch, neomutt users see garbage on their screen when their
terminal is resized. To clear the garbage, users currently need to
manually redraw their screen (^L).

[ Tests ]

I have used the patch for weeks. It has been fixed upstream since
December and it has appeared in a stable release.

[ Risks ]

Minimal: the patch adds two missing calls to clear the problematic
message line.

This is an NMU, and I still have not heard back from the maintainer. I
submitted the patch to the BTS in January and I declared my intention to
NMU on March 16.

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

[ Other info ]

Please advise if this is likely to be approved, so that I may upload to
DELAYED/10.

Best,
Ryan

unblock neomutt/20201127+dfsg.1-1.1

-- 
|)|/  Ryan Kavanagh  | GPG: 4E46 9519 ED67 7734 268F
|\|\  https://rak.ac |  BD95 8F7B F8FC 4A11 C97A
diff -Nru neomutt-20201127+dfsg.1/debian/changelog 
neomutt-20201127+dfsg.1/debian/changelog
--- neomutt-20201127+dfsg.1/debian/changelog2021-01-30 11:18:27.0 
-0500
+++ neomutt-20201127+dfsg.1/debian/changelog2021-03-16 15:37:31.0 
-0400
@@ -1,3 +1,11 @@
+neomutt (20201127+dfsg.1-1.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Clear the message window on SIGWINCH, redraw-on-sigwinch.patch
+(Closes: #980427)
+
+ -- Ryan Kavanagh   Tue, 16 Mar 2021 15:37:31 -0400
+
 neomutt (20201127+dfsg.1-1) unstable; urgency=medium
 
   * New upstream release.
diff -Nru neomutt-20201127+dfsg.1/debian/patches/series 
neomutt-20201127+dfsg.1/debian/patches/series
--- neomutt-20201127+dfsg.1/debian/patches/series   2021-01-30 
11:18:27.0 -0500
+++ neomutt-20201127+dfsg.1/debian/patches/series   2021-03-16 
15:37:31.0 -0400
@@ -3,3 +3,4 @@
 debian-specific/document_debian_defaults.patch
 misc/smime.rc.patch
 upstream/981306-mime-forwarding.patch
+upstream/redraw-on-sigwinch.patch
diff -Nru 
neomutt-20201127+dfsg.1/debian/patches/upstream/redraw-on-sigwinch.patch 
neomutt-20201127+dfsg.1/debian/patches/upstream/redraw-on-sigwinch.patch
--- neomutt-20201127+dfsg.1/debian/patches/upstream/redraw-on-sigwinch.patch
1969-12-31 19:00:00.0 -0500
+++ neomutt-20201127+dfsg.1/debian/patches/upstream/redraw-on-sigwinch.patch
2021-03-16 15:37:31.0 -0400
@@ -0,0 +1,43 @@
+From: Richard Russon 
+Date: Mon, 7 Dec 2020 14:21:45 +
+Subject: clear the message window on SIGWINCH (#2756)
+
+When the terminal is resized (or the font-size is changed),
+the screen must be redrawn.  This *used* to involve clearing the entire
+screen.  Soon, it will be delegated to individual windows to refresh
+themselves.
+
+In the mean time, forcibly clear the MessageWindow.
+
+Fixes: #2749
+
+Origin: 
https://github.com/neomutt/neomutt/commit/88f0b0572da9414550608054e960fd00b8d6b939
+---
+ index.c | 1 +
+ pager.c | 1 +
+ 2 files changed, 2 insertions(+)
+
+diff --git a/index.c b/index.c
+index c29ba8b..af3a18f 100644
+--- a/index.c
 b/index.c
+@@ -1368,6 +1368,7 @@ int mutt_index_menu(struct MuttWindow *dlg)
+ /* force a real complete redraw.  clrtobot() doesn't seem to be able
+  * to handle every case without this.  */
+ clearok(stdscr, true);
++mutt_window_clearline(MessageWindow, 0);
+ continue;
+   }
+ 
+diff --git a/pager.c b/pager.c
+index b08dda2..0e333c0 100644
+--- a/pager.c
 b/pager.c
+@@ -2473,6 +2473,7 @@ int mutt_pager(const char *banner, const char *fname, 
PagerFlags flags, struct P
+   SigWinch = 0;
+   mutt_resize_screen();
+   clearok(stdscr, true); /* force complete redraw */
++  mutt_window_clearline(MessageWindow, 0);
+ 
+   if (flags & MUTT_PAGER_RETWINCH)
+   {


signature.asc
Description: PGP signature

Bug#986342: python3-lxml: RelaxNG validator sometimes incorrectly reports errors in XML

[Wojciech Zabołotny]

Package: python3-lxml
Version: 4.6.3-1
Severity: important

Dear Maintainer,

The Relax NG validator does not correctly detect the errors in the XML file.
The simple set of files reconstructing the problem is attached in archive
"bug_demo.tar.gz".
The agwb.rng defines the XML schema. The example1.xml contains the
conforming
xml file.
The example1a.xml file has an error - field "B2" in creg "X2" does not
contain
required "width" attribute.
The example1b.xml has another error - the attribute "name" in block SYS1
is written as "nafme".

Validating the erroneous files, however, gives incorrect results.
The tests are performed both with Python lxml module and with xmllint
utility.
The errors are similar, so probably the error is located in the lxml
library.

$ ./test0.sh example1a.xml
[...]
example1a.xml:11: element field: Relax-NG validity error : Element field
failed to validate attributes
example1a.xml:10: element field: Relax-NG validity error : Element creg
has extra content: field
Relax-NG validity error : Extra element creg in interleave
example1a.xml:9: element creg: Relax-NG validity error : Element block
failed to validate content
Relax-NG validity error : Extra element block in interleave
example1a.xml:3: element block: Relax-NG validity error : Element sysdef
failed to validate content
example1a.xml fails to validate

$ ./test0.py example1a.xml False
example1a.xml:11:0:ERROR:RELAXNGV:RELAXNG_ERR_ATTRVALID: Element field
failed to validate attributes
example1a.xml:10:0:ERROR:RELAXNGV:RELAXNG_ERR_EXTRACONTENT: Element creg
has extra content: field
:0:0:ERROR:RELAXNGV:RELAXNG_ERR_INTEREXTRA: Extra element creg
in interleave
example1a.xml:9:0:ERROR:RELAXNGV:RELAXNG_ERR_CONTENTVALID: Element block
failed to validate content
:0:0:ERROR:RELAXNGV:RELAXNG_ERR_INTEREXTRA: Extra element block
in interleave
example1a.xml:3:0:ERROR:RELAXNGV:RELAXNG_ERR_CONTENTVALID: Element
sysdef failed to validate content

The error message lacks specifity. There should be a detailed
information about the lacking field.
In case of example1b.xml the situation is even worse:

$ ./test0.sh example1b.xml example1b.xml:3: element block: Relax-NG
validity error : Expecting an element sreg, got nothing
Relax-NG validity error : Extra element block in interleave
example1b.xml:3: element block: Relax-NG validity error : Element sysdef
failed to validate content
example1b.xml fails to validate

./test0.py example1b.xml False
example1b.xml:3:0:ERROR:RELAXNGV:RELAXNG_ERR_NOELEM: Expecting an
element sreg, got nothing
:0:0:ERROR:RELAXNGV:RELAXNG_ERR_INTEREXTRA: Extra element block
in interleave
example1b.xml:3:0:ERROR:RELAXNGV:RELAXNG_ERR_CONTENTVALID: Element
sysdef failed to validate content

There is absolutely no reason to expect "sreg" element in a "sysdef". It
is against the defined schema.

However, if I convert the schema to the DTD:

$ trang -I rng -O dtd agwb.rng agwb.dtd
then the further validations wit DTD give the correct results for both
erroneous files:

$ ./test1.sh example1a.xml [...]
example1a.xml:11: element field: validity error : Element field does not
carry attribute width
Document example1a.xml does not validate against agwb.dtd

$ ./test1.py example1a.xml False
example1a.xml:11:0:ERROR:VALID:DTD_MISSING_ATTRIBUTE: Element field does
not carry attribute width

$ ./test1.sh example1b.xml [...]
example1b.xml:3: element block: validity error : Element block does not
carry attribute name
example1b.xml:3: element block: validity error : No declaration for
attribute nafme of element block
Document example1b.xml does not validate against agwb.dtd

$ ./test1.py example1b.xml False
example1b.xml:3:0:ERROR:VALID:DTD_MISSING_ATTRIBUTE: Element block does
not carry attribute name
example1b.xml:3:0:ERROR:VALID:DTD_UNKNOWN_ATTRIBUTE: No declaration for
attribute nafme of element block

The above reports precisely describe errors in the validated files.
Therefore the problem is rather not in the Relax NG scheme definition
but in the validator itself.

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

Kernel: Linux 5.10.0-5-amd64 (SMP w/12 CPU threads)
Locale: LANG=pl_PL.UTF-8, LC_CTYPE=pl_PL.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 python3-lxml depends on:
ii libc6 2.31-10
ii libxml2 2.9.10+dfsg-6.3+b1
ii libxslt1.1 1.1.34-4
ii python3 3.9.2-2

Versions of packages python3-lxml recommends:
ii python3-bs4 4.9.3-1
ii python3-html5lib 1.1-3

Versions of packages python3-lxml suggests:
pn python-lxml-doc 
pn python3-lxml-dbg 

-- no debconf information

Bug#986340: ITP: stegseek -- Worlds fastest steghide cracker

[Francisco Vilmar Cardoso Ruviaro]

Package: wnpp
Severity: wishlist
Owner: Francisco Vilmar Cardoso Ruviaro 
X-Debbugs-Cc: debian-de...@lists.debian.org, francisco.ruvi...@riseup.net

* Package name: stegseek
  Version : 0.5
  Upstream Author : Rick de Jager 

* URL : https://github.com/RickdeJager/stegseek
* License : GPL-2+
  Programming Lang: C++
  Description : Worlds fastest steghide cracker

Stegseek is a lightning fast steghide cracker that can be used to extract
hidden data from files. It is built as a fork of the original steghide
project and, as a result, it is thousands of times faster than other
crackers and can run through millions of passwords per second.
.
Stegseek can also be used to extract steghide metadata without a password,
which can be used to test whether a file contains steghide data.

I intend to maintain this package under the umbrella of the Security Tools Team.

Bug#986339: universal-ctags: prerm fails on upgrades

[Antonio Terceiro]

Package: universal-ctags
Version: 0+git20200824-1.1.g15ce0a8
Severity: serious
Tags: patch
Justification: Policy 6.4

This is a clean buster container where I tested upgrading
universal-ctags:

root@1066c7b1da18:/# apt install -qy universal-ctags
Reading package lists...
Building dependency tree...
Reading state information...
The following packages will be upgraded:
  universal-ctags
1 upgraded, 0 newly installed, 0 to remove and 92 not upgraded.
Need to get 442 kB of archives.
After this operation, 311 kB of additional disk space will be used.
Get:1 http://deb.debian.org/debian bullseye/main amd64 universal-ctags amd64 
0+git20200824-1 [442 kB]
Fetched 442 kB in 5s (87.9 kB/s)
debconf: delaying package configuration, since apt-utils is not installed
(Reading database ... 8631 files and directories currently installed.)
Preparing to unpack .../universal-ctags_0+git20200824-1_amd64.deb ...
prerm called with unknown argument `upgrade'
dpkg: warning: old universal-ctags package pre-removal script subprocess 
returned error exit status 1
dpkg: trying script from the new package instead ...
dpkg: ... it looks like that went OK
Unpacking universal-ctags (0+git20200824-1) over (0+git20181215-2) ...
Setting up universal-ctags (0+git20200824-1) ...
update-alternatives: using /usr/bin/ctags-universal to provide /usr/bin/etags 
(etags) in auto mode

It seems that dpkg works around the issue somehow, but still prerm
should not exit non-zero. The script will also fail similarly when prerm
is called with "deconfigure".

The attached patch fixes both cases.

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

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

Versions of packages universal-ctags depends on:
ii  libc62.31-10
ii  libjansson4  2.13.1-1.1
ii  libseccomp2  2.5.1-1
ii  libxml2  2.9.10+dfsg-6.3+b1
ii  libyaml-0-2  0.2.2-1

universal-ctags recommends no packages.

Versions of packages universal-ctags suggests:
ii  vim 2:8.2.2434-3
ii  vim-gtk3 [vim]  2:8.2.2434-3

-- no debconf information
From 490f13d5b473059dd873deab5f1f1b64e12f4f40 Mon Sep 17 00:00:00 2001
From: Antonio Terceiro 
Date: Sat, 3 Apr 2021 17:05:57 -0300
Subject: [PATCH 2/2] debian/prerm: handle upgrade/removal scenarios correctly

---
 debian/prerm | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/debian/prerm b/debian/prerm
index 6ebf9a2..4b4d130 100644
--- a/debian/prerm
+++ b/debian/prerm
@@ -3,12 +3,12 @@
 set -e
 
 case "$1" in
-remove)
+remove|deconfigure)
 update-alternatives --remove ctags /usr/bin/ctags-universal
 update-alternatives --remove etags /usr/bin/ctags-universal
 ;;
 
-failed-upgrade)
+upgrade|failed-upgrade)
 ;;
 
 *)
-- 
2.31.0



signature.asc
Description: PGP signature

Bug#983203: your mail

[Lyndon Brown]

On Sat, 2021-04-03 at 02:10 +0200, Chris Hofstaedtler wrote:
> Control: severity -1 important
> 
> * Lyndon Brown  [210308 22:09]:
> > # set severity to grave since it appears that the package is
> > completely
> > # broken currently.
> > severity 983203 grave
> 
> "completely broken" appears to be a gross overstatement. The
> firewalld integration might be broken - and I agree it should be
> fixed - but sshguard supports other firewall tools as well.

You're absolutely right, I don't know why I thought differently at the
time.

Bug#985292: materia-gtk-theme: unhandled symlink to directory conversion: /usr/share/themes/Materia-compact/gtk-3.0/assets -> ../gtk-assets

[Andreas Beckmann]

On 03/04/2021 07.43, Leandro Cunha wrote:

Can you test the version I pushed for Salsa and confirm that the problem
has been fixed?

[1] https://salsa.debian.org/leandrocunha/materia-gtk-theme


There is no releated change in git, only a changelog entry (I would have 
expected a .maintscript file to be added).
But there is a revert of debian/rules to an older version (and from 
short debhelper 13 to something much older), which is probably unwanted 
and inappropriate at this point of the release cycle.



Andreas

Bug#986338: epiphany-browser: hangs after some navigation

[Jérémy Lal]

Package: epiphany-browser
Version: 3.38.2-1
Severity: important

Hi,

epiphany is my default browser on debian/sid, but since about a month,
it has become unusable: it hangs after some minutes of navigation on
normal websites.

nothing specific appears in journalctl when hangs happen.



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

Kernel: Linux 5.10.0-5-amd64 (SMP w/4 CPU threads)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=fr_FR.utf8, LC_CTYPE=fr_FR.utf8 (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 epiphany-browser depends on:
ii  dbus-user-session [default-dbus-session-bus]  1.12.20-2
ii  dbus-x11 [dbus-session-bus]   1.12.20-2
ii  epiphany-browser-data 3.38.2-1
ii  gsettings-desktop-schemas 3.38.0-2
ii  iso-codes 4.6.0-1
ii  libatk1.0-0   2.36.0-2
ii  libc6 2.31-11
ii  libcairo2 1.16.0-5
ii  libdazzle-1.0-0   3.38.0-1
ii  libgcr-base-3-1   3.38.1-2
ii  libgcr-ui-3-1 3.38.1-2
ii  libgdk-pixbuf-2.0-0   2.42.2+dfsg-1
ii  libglib2.0-0  2.66.8-1
ii  libgmp10  2:6.2.1+dfsg-1
ii  libgtk-3-03.24.24-3
ii  libhandy-1-0  1.0.3-2
ii  libhogweed6   3.7.2-1
ii  libjavascriptcoregtk-4.0-18   2.30.6-1
ii  libjson-glib-1.0-01.6.2-1
ii  libnettle83.7.2-1
ii  libpango-1.0-01.46.2-3
ii  libsecret-1-0 0.20.4-2
ii  libsoup2.4-1  2.72.0-2
ii  libsqlite3-0  3.34.1-3
ii  libwebkit2gtk-4.0-37  2.30.6-1
ii  libxml2   2.9.10+dfsg-6.3+b1

Versions of packages epiphany-browser recommends:
ii  ca-certificates  20210119
ii  evince   3.38.2-1
ii  yelp 3.38.3-1

epiphany-browser suggests no packages.

-- no debconf information

Bug#985518: node-d3-dsv: broken symlinks: /usr/bin/*2* -> ../lib/nodejs/d3-dsv/bin/*2*

[Paul Gevers]

Hi,

On Fri, 19 Mar 2021 12:35:42 +0100 Andreas Beckmann  wrote:
> during a test with piuparts I noticed your package ships (or creates)
> a broken symlink.
> 
> From the attached log (scroll to the bottom...):
> 
> 0m28.5s ERROR: FAIL: Broken symlinks:
>   /usr/bin/tsv2json -> ../lib/nodejs/d3-dsv/bin/dsv2json (node-d3-dsv)
>   /usr/bin/tsv2csv -> ../lib/nodejs/d3-dsv/bin/dsv2dsv (node-d3-dsv)
>   /usr/bin/json2tsv -> ../lib/nodejs/d3-dsv/bin/json2dsv (node-d3-dsv)
>   /usr/bin/json2dsv -> ../lib/nodejs/d3-dsv/bin/json2dsv (node-d3-dsv)
>   /usr/bin/json2csv -> ../lib/nodejs/d3-dsv/bin/json2dsv (node-d3-dsv)
>   /usr/bin/dsv2json -> ../lib/nodejs/d3-dsv/bin/dsv2json (node-d3-dsv)
>   /usr/bin/dsv2dsv -> ../lib/nodejs/d3-dsv/bin/dsv2dsv (node-d3-dsv)
>   /usr/bin/csv2tsv -> ../lib/nodejs/d3-dsv/bin/dsv2dsv (node-d3-dsv)
>   /usr/bin/csv2json -> ../lib/nodejs/d3-dsv/bin/dsv2json (node-d3-dsv)

Can we please get a fix for this bug in unstable without the other
changes that don't comply with the release policy?

In the current state I can't unblock the fix.

Paul



OpenPGP_signature
Description: OpenPGP digital signature

Bug#986311: unblock: debian-cloud-images/0.0.4

[Paul Gevers]

Hi Noah,

On 03-04-2021 17:44, Noah Meyerhans wrote:
> It is sufficient for the Depends packages to be available in the next
> release.

Unfortunately, our package handling goes per source package, not by
binary packages.

>> Should the current package in testing be released with bullseye if we
>> don't update it?
> 
> IMO, debian-cloud-images should never have been packaged in Debian in
> the first place, given that there was no plan to maintain it in the
> archive and that a "stable" packaged version of it bears only a passing
> relationship to the cloud images we actually ship, but it's too late for
> that.

What do you mean with "it's too late for that"? We *could* (not saying
we should) drop the package.

> In an ideal world, the debian-cloud-images package in the stable release
> would match what generates the images for that release.  However, it
> moves relatively quickly in order to keep up with changes implemented by
> the cloud services, so that would require us to update the stable
> package frequently.  The ability to update cloud related packages for
> this reason was discussed with the SRMs some time ago, and I understand
> that they were supportive of allowing such updates in stable point
> releases.  Practically speaking, we've only ever applied this agreement
> once, to update cloud-init in buster.
> 
> If we can't keep the debian-cloud-images package up-to-date in stable
> releases, then it should not be included.  It's the worst of both worlds
> and can only cause confusion for users.  I'd be in favor of removing it
> from buster, too, if that's the case, where it's most definitely out of
> sync with what's generating the cloud images today.

If the SRM's are fine with updating the package in stable, I'm happy to
unblock it. I'll point them to this bug to have them weight in.

Paul



OpenPGP_signature
Description: OpenPGP digital signature

Bug#986311: unblock: debian-cloud-images/0.0.4

[Paul Gevers]

Hi Bastian,

On 03-04-2021 21:08, Bastian Blank wrote:
> On Sat, Apr 03, 2021 at 08:00:20AM +0200, Paul Gevers wrote:
>> So, I'm very uncomfortable with the union of this key packages tracking
>> package
> 
> Then please drop the UUD entry that forces it to be a key package and
> drop the package from testing.  After that we'll stop updating packages
> in stable and just fake them into official Debian releases without any
> chance of security updates.  Would you consider that a better solution?

You sound a bit harsh, please assume good faith. Let me at least point
out that I was not aware of earlier discussions about uploading the
package to stable releases.

I'm just wondering what's the best course of action, and remarks in the
original request made me wonder if we should ship the
debian-cloud-images in stable releases. We *made*
src:debian-cloud-images a key package because of the
debian-cloud-images-packages binaries, not because of the
debian-cloud-images binary. So, if they seem (maybe just for someone
that looks for the first time at it) an ill fit together, maybe we can
find a better solution (now or in the future).

Paul



OpenPGP_signature
Description: OpenPGP digital signature

Bug#986311: unblock: debian-cloud-images/0.0.4

[Bastian Blank]

On Sat, Apr 03, 2021 at 08:00:20AM +0200, Paul Gevers wrote:
> So, I'm very uncomfortable with the union of this key packages tracking
> package

Then please drop the UUD entry that forces it to be a key package and
drop the package from testing.  After that we'll stop updating packages
in stable and just fake them into official Debian releases without any
chance of security updates.  Would you consider that a better solution?

Regards,
Bastian

-- 
Most legends have their basis in facts.
-- Kirk, "And The Children Shall Lead", stardate 5029.5

Bug#986323: ITP: wowlet -- a free Wownero desktop wallet

[Andrei POPESCU]

Control: reassign -1 wnpp

On Sb, 03 apr 21, 07:27:12, wowario wrote:
> Package: wowlet
> Severity: wishlist
> 
> * Package name : wowlet
>   Version : 1.0
>   Upstream Author : wowlet 
> * URL : https://git.wownero.com/wowlet/wowlet
> * License : BSD-3-clause
>   Programming Lang: Qt, C++
>   Description : WOWlet is a free, open-source Wownero desktop wallet for 
> Linux, Tails, macOS, and Windows.
> 
> - Wowario

Reassigning to correct (pseudo-)package.

Kind regards,
Andrei
-- 
Looking after bugs assigned to unknown or inexistent packages


signature.asc
Description: PGP signature

Bug#986314: RFS: gsimplecal/2.1-2 [QA] -- lightweight GUI calendar application

[Andreas Ronnquist]

On Fri, 02 Apr 2021 17:58:45 -0300,
Hugo Torres de Lima wrote:

>Package: sponsorship-requests
>Severity: normal
>
>Dear mentors,
>
>I am looking for a sponsor for my package "gsimplecal":
>
> * Package name: gsimplecal
>   Version : 2.1-2
>   Upstream Author : https://github.com/dmedvinsky/gsimplecal/issues
> * URL : https://dmedvinsky.github.io/gsimplecal
> * License : BSD-3-Clause
> * Vcs :
> http://anonscm.debian.org/cgit/collab-maint/gsimplecal.git Section
>  : misc
>
>It builds those binary packages:
>
>  gsimplecal - lightweight GUI calendar application
>
>To access further information about this package, please visit the
>following URL:
>
>  https://mentors.debian.net/package/gsimplecal/
>
-- 8< --

There seems to be changes in salsa, which has updated the Vcs-*-fields,
while yours are still pointing to alioth.

https://salsa.debian.org/jmsrdebian/gsimplecal/-/blob/debian/master/debian/changelog

Also, there seems to be an upstream 2.2 available from February, which
could be nice to package.

-- Andreas Rönnquist
mailingli...@gusnan.se
gus...@debian.org

Bug#963210: qa.debian.org: DDPO still using old name

[Martina Ferrari]

Hi Raúl,

I had spent some time understanding carnivore, and found the reason why 
this was happening, but in the end I never got around to implementing a 
fix.. So thank you for taking the time to look into this!


As you guessed, i would prefer not to have my deadname show at all, and 
to have all my packages merged under one identity.


Let me know if I can assist in any way.

Thanks a lot, Martina.

On 03/04/2021 00:45, Raúl Benencia wrote:

On Sat, Jun 20, 2020 at 05:07:43PM +0100, Martina Ferrari wrote:

In the past months, I have been gradually switching all my online identities to
my new name (Martina) and uid/nick (Tina). I have changed emails, GPG keys, and
finally my Debian LDAP uid.


Hola Martina! Long time. :-)

I did some research to get to the bottom of this issue. I'll be verbose
describing what I found in hopes of it being useful for similar issues in the
future.

The source of your deadname is in a database that DDPO uses under the hood
called carnivore[1]. I think your case might be very similar to #706260. In your
case, names are being merged[2] because there are still some packages that use
your deadname.

In quants, qa.debian.org, if you check the file
/srv/qa.debian.org/carnivore/uids you might see something like this:

| martina ferrari : email:t...@debian.org
| martina ferrari : email:t...@debian.org
| martín ferrari : email:t...@debian.org

I haven't confirmed this—I don't have access to quants—but I tried it locally
after running extract_data myself.

You can explicitly state[3] that you don't want your name to be merged with your
deadname, at the cost of unlinking the two uids. If you add[3] "Martina
Ferrari", then the result will be:

| martina ferrari : email:t...@debian.org
|
| martina ferrari : email:tin...@debian.org
| martín ferrari : email:tin...@debian.org

This approach has the disadvantage that you'll stop seeing all packages in a
single page; probably not what you want, so I kept digging.

The developer.wml[4] file shows that it chooses the first name of all the
indexed names. A possible solution is to somehow set your name at the beginning
of that list. Another solution can be to state that you prefer a single name on
the DB.

I wrote a patch that implements this last solution, allowing you to state a
preferred name. I'm still testing it, but I'll try to submit it for review on
the weekend.

nota bene: it's the first time I'm interacting with this codebase so I might be
entirely wrong. \o/

[1] https://salsa.debian.org/qa/qa/-/blob/c850ab59/carnivore/README#L12-13
[2] https://salsa.debian.org/qa/qa/-/blob/c850ab59/carnivore/extract_data#L85
[3] https://salsa.debian.org/qa/qa/-/blob/c850ab59/carnivore/extract_data#L82
[4] https://salsa.debian.org/qa/qa/-/blob/c850ab59/wml/developer.wml#L1654



--
Martina Ferrari (Tina)

Bug#815390: Processed: fixed 815390

[gregor herrmann]

Control: reopen -1
Control: notfixed -1 0.116
Control: tag -1 + patch

On Tue, 30 Mar 2021 22:59:53 +0200, gregor herrmann wrote:

> > > fixed 815390 dh-make-perl/0.116
> > Bug #815390 [dh-make-perl] dh-make-perl: Fail to build package if run with 
> > sudo ($orig_pwd not initialized)
> > Marked as fixed in versions dh-make-perl/0.116.
> If the bug is fixed, we might as well close the bug at this version.

Apparently the bug is not fixed, and there's a merge request at
https://salsa.debian.org/perl-team/modules/packages/dh-make-perl/-/merge_requests/3

Cheers,
gregor

-- 
 .''`.  https://info.comodo.priv.at -- Debian Developer https://www.debian.org
 : :' : OpenPGP fingerprint D1E1 316E 93A7 60A8 104D  85FA BB3A 6801 8649 AA06
 `. `'  Member VIBE!AT & SPI Inc. -- Supporter Free Software Foundation Europe
   `-   NP: Orquesta Aragon: El Charlatan


signature.asc
Description: Digital Signature

Bug#986337: zfs-linux: [INTL:fr] French templates translation

[Jean-Pierre Giraud]

Package: zfs-linux
Severity: wishlist
Tags: patch l10n

Hi!

Please find attached the french templates translation, proofread
by the debian-l10n-french mailing list contributors.

This file should be put as debian/po/fr.po in your package build tree.

Kind Regards

Jean-Pierre Giraud


fr.po.gz
Description: application/gzip


signature.asc
Description: OpenPGP digital signature

Bug#986320: Stronger advice on when to use native packages

[Russ Allbery]

David Bremner  writes:
> Russ Allbery  writes:

>> Currently, Debian Policy is silent on when it's appropriate to use a
>> native package, but there may be a project consensus aganist using
>> native packages when the software has an existence outside of Debian.

> Personally I don't think Debian policy should be concerned with what
> happens outside Debian. As long as a given process serves the users and
> contributors of/to Debian well, that seems sufficient to me.

To be clear, my understanding of the advocacy of using non-native packages
is primarily about their impact on *Debian* workflows (being able to base
multiple packages on the same tarball, not introducing confusion between
upstream version numbers and Debian version numbers and thus making it
easier for other people in Debian to track the package to an upstream
version, triggering various package checks that ignore native packages but
care about non-native packages such as uscan, etc.).

> I understand that others disagree, particularly on how much we should
> consider the needs of derivative distributions.

This is a good additional point for discussion, though, since I vaguely
recall that using native packages had some oddities for derivative
distributions, which is a significant Debian user use case.

>> Even if that consensus does not exist, there is probably consensus that
>> native packages are a poor match for large packages (because of the
>> inefficiency of making small updates to the packaging of native
>> packages), and there may be other cases where we can give stronger
>> guidance.

> That seems more like something that could be documented in devref as a
> best practice, rather than something needing normative language.

Yes, that's a good point; it's possible that some or all of this belongs
in devref rather than Policy.

-- 
Russ Allbery (r...@debian.org)  

Bug#985569: [DRE-maint] Bug#985569: ruby-kramdown: CVE-2021-28834

[Antonio Terceiro]

Hi,

On Sat, Mar 20, 2021 at 08:50:21AM +0100, Salvatore Bonaccorso wrote:
> Source: ruby-kramdown
> Version: 2.3.0-4
> Severity: grave
> Tags: security upstream
> Justification: user security hole
> Forwarded: https://github.com/gettalong/kramdown/pull/708
> X-Debbugs-Cc: car...@debian.org, Debian Security Team 
> 
> 
> Hi,
> 
> The following vulnerability was published for ruby-kramdown.
> 
> CVE-2021-28834[0]:
> | Kramdown before 2.3.1 does not restrict Rouge formatters to the
> | Rouge::Formatters namespace, and thus arbitrary classes can be
> | instantiated.
> 
> 
> If you fix the vulnerability please also make sure to include the
> CVE (Common Vulnerabilities & Exposures) id in your changelog entry.

I just uploaded a fix for bullseye, and prepared the attached update for
buster. It passes its own autopkgtest, and I don't see the possibility
of any regressions in non-malicious code.

Let me know if I can go ahead and upload.
diff --git a/debian/changelog b/debian/changelog
index 7830bf5..0541988 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,11 @@
+ruby-kramdown (1.17.0-1+deb10u2) buster-security; urgency=high
+
+  * Team upload.
+  * Add upstream patch to fix arbitrary code execution vulnerability
+[CVE-2021-28834] (Closes: #985569)
+
+ -- Antonio Terceiro   Sat, 03 Apr 2021 13:05:12 -0300
+
 ruby-kramdown (1.17.0-1+deb10u1) buster-security; urgency=high
 
   * Non-maintainer upload by the Security Team.
diff --git a/debian/patches/0004-Restrict-Rouge-formatters-to-Rouge-Formatters-namesp.patch b/debian/patches/0004-Restrict-Rouge-formatters-to-Rouge-Formatters-namesp.patch
new file mode 100644
index 000..5d9780e
--- /dev/null
+++ b/debian/patches/0004-Restrict-Rouge-formatters-to-Rouge-Formatters-namesp.patch
@@ -0,0 +1,56 @@
+From: Stan Hu 
+Date: Sat, 3 Apr 2021 13:00:47 -0300
+Subject: Restrict Rouge formatters to Rouge::Formatters namespace
+
+ff0218a added support for specifying custom Rouge formatters with the
+constraint that the formatter be in theRouge::Formatters namespace, but
+it did not actually enforce this constraint. For example, this is valid:
+
+```ruby
+Rouge::Formatters.const_get('CSV')
+=> CSV
+```
+
+Adding the `false` parameter to `const_get` prevents this:
+
+```ruby
+Rouge::Formatters.const_get('CSV', false)
+NameError: uninitialized constant Rouge::Formatters::CSV
+```
+
+This is a backport of the original patch at
+https://github.com/gettalong/kramdown/pull/708, backported by Antonio
+Terceiro to version 1.17.0.
+
+Signed-off-by: Antonio Terceiro 
+---
+ lib/kramdown/converter/syntax_highlighter/rouge.rb | 2 +-
+ test/test_files.rb | 2 +-
+ 2 files changed, 2 insertions(+), 2 deletions(-)
+
+diff --git a/lib/kramdown/converter/syntax_highlighter/rouge.rb b/lib/kramdown/converter/syntax_highlighter/rouge.rb
+index e1e5a0d..a6894d6 100644
+--- a/lib/kramdown/converter/syntax_highlighter/rouge.rb
 b/lib/kramdown/converter/syntax_highlighter/rouge.rb
+@@ -59,7 +59,7 @@ module Kramdown::Converter::SyntaxHighlighter
+   when Class
+ formatter
+   when /\A[[:upper:]][[:alnum:]_]*\z/
+-::Rouge::Formatters.const_get(formatter)
++::Rouge::Formatters.const_get(formatter, false)
+   else
+ # Available in Rouge 2.0 or later
+ ::Rouge::Formatters::HTMLLegacy
+diff --git a/test/test_files.rb b/test/test_files.rb
+index 30b9888..c985833 100644
+--- a/test/test_files.rb
 b/test/test_files.rb
+@@ -20,7 +20,7 @@ begin
+   end
+ 
+   # custom formatter for tests
+-  class RougeHTMLFormatters < Kramdown::Converter::SyntaxHighlighter::Rouge.formatter_class
++  class Rouge::Formatters::RougeHTMLFormatters < Kramdown::Converter::SyntaxHighlighter::Rouge.formatter_class
+ tag 'rouge_html_formatters'
+ 
+ def stream(tokens, )
diff --git a/debian/patches/series b/debian/patches/series
index 2de2e62..2a2bfc1 100644
--- a/debian/patches/series
+++ b/debian/patches/series
@@ -1,3 +1,4 @@
 skip_missing_math_engines.patch
 fix_manpage_warnings.patch
 Add-option-forbidden_inline_options.patch
+0004-Restrict-Rouge-formatters-to-Rouge-Formatters-namesp.patch


signature.asc
Description: PGP signature

Bug#980609: Big bug

[Pedro Ribeiro]

reopen 980609

severity 980609 grave

This is a huge bug, breaking compilation of many packages and newer
kernels. 

It definitely needs to go into the next stable version!

Bug#986311: unblock: debian-cloud-images/0.0.4

[Noah Meyerhans]

Control: tags -1 - moreinfo

On Sat, Apr 03, 2021 at 08:00:20AM +0200, Paul Gevers wrote:
> > This package contains a snapshot of the code and configuration used by the
> > cloud team to generate the images for azure, aws, and openstack.  The cloud
> > team does not build directly from the packages in the archive, but rather
> > from the salsa repository.  So there is no risk of impact to the cloud
> > images we generate if this package is updated.  Keeping the archive package
> > closer to what's actually used by the cloud team is beneficial to any users
> > who might be generating their own images based on our configuration.
> 
> So, I'm very uncomfortable with the union of this key packages tracking
> package and the actual snapshot package. debian-cloud-images:all is a
> new upstream release which doesn't follow our freeze policy at all, so I
> think this should be a NACK. I'm also wondering, technically, do you
> need the build dependencies of src:debian-cloud-images to be key too to
> release the cloud images, or should is suffice to guarantee the Depends
> of debian-cloud-images-packages to be in the next release? If I spot
> correctly, of the three newly added Depends only fdisk is currently not
> key yet, BD python3-yaml is also not a key package yet.

It's a Debian-native package, so "new upstream release" isn't really
accurate.  But yes, it changes a lot of the package contents.

It is sufficient for the Depends packages to be available in the next
release.

> Should the current package in testing be released with bullseye if we
> don't update it?

IMO, debian-cloud-images should never have been packaged in Debian in
the first place, given that there was no plan to maintain it in the
archive and that a "stable" packaged version of it bears only a passing
relationship to the cloud images we actually ship, but it's too late for
that.

In an ideal world, the debian-cloud-images package in the stable release
would match what generates the images for that release.  However, it
moves relatively quickly in order to keep up with changes implemented by
the cloud services, so that would require us to update the stable
package frequently.  The ability to update cloud related packages for
this reason was discussed with the SRMs some time ago, and I understand
that they were supportive of allowing such updates in stable point
releases.  Practically speaking, we've only ever applied this agreement
once, to update cloud-init in buster.

If we can't keep the debian-cloud-images package up-to-date in stable
releases, then it should not be included.  It's the worst of both worlds
and can only cause confusion for users.  I'd be in favor of removing it
from buster, too, if that's the case, where it's most definitely out of
sync with what's generating the cloud images today.

noah



signature.asc
Description: PGP signature

Bug#935725: util-linux: lsblk sometimes gives wrong pttype "dos" for gpt partitions

[Václav Doležal]

Hello,

can you verify that the bug is still present in current libblkid?

It should be fixed since commit cdb9140967 [1] (v2.35 or higher).

Regards,
Václav Doležal

[1] 
https://github.com/karelzak/util-linux/commit/cdb91409674cfb5d94a374b1e3b2bf1869ecfec7

Bug#986251: python-bleach: diff for NMU version 3.2.1-2.1

[Salvatore Bonaccorso]

Control: tags 986251 + patch
Control: tags 986251 + pending


Dear maintainer,

I've prepared an NMU for python-bleach (versioned as 3.2.1-2.1) and
uploaded it to DELAYED/5. Please feel free to tell me if I
should delay it longer.

Actually if you want to take care of it that would be the preferable
option, or if you think this is fine and inline in how you would like
to have we can have it reschduled as well, so that the unblock can be
asked earlier.

The fix should in any case ideally go to bullseye.

Regards,
Salvatore
diff -Nru python-bleach-3.2.1/debian/changelog python-bleach-3.2.1/debian/changelog
--- python-bleach-3.2.1/debian/changelog	2021-01-18 07:30:51.0 +0100
+++ python-bleach-3.2.1/debian/changelog	2021-04-03 17:17:55.0 +0200
@@ -1,3 +1,11 @@
+python-bleach (3.2.1-2.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * sanitizer: escape HTML comments (CVE-2021-23980) (Closes: #986251)
+  * tests: add tests for more eject tags for GHSA-vv2x-vrpj-qqpq
+
+ -- Salvatore Bonaccorso   Sat, 03 Apr 2021 17:17:55 +0200
+
 python-bleach (3.2.1-2) unstable; urgency=medium
 
   * Team upload.
diff -Nru python-bleach-3.2.1/debian/patches/0004-sanitizer-escape-HTML-comments.patch python-bleach-3.2.1/debian/patches/0004-sanitizer-escape-HTML-comments.patch
--- python-bleach-3.2.1/debian/patches/0004-sanitizer-escape-HTML-comments.patch	1970-01-01 01:00:00.0 +0100
+++ python-bleach-3.2.1/debian/patches/0004-sanitizer-escape-HTML-comments.patch	2021-04-03 17:17:22.0 +0200
@@ -0,0 +1,95 @@
+From: Greg Guthe 
+Date: Thu, 28 Jan 2021 14:56:24 -0500
+Subject: sanitizer: escape HTML comments
+Origin: https://github.com/mozilla/bleach/commit/1334134d34397966a7f7cfebd38639e9ba2c680e
+Bug-Debian: https://bugs.debian.org/986251
+Bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1689399
+Bug: https://github.com/mozilla/bleach/security/advisories/GHSA-vv2x-vrpj-qqpq
+Bug-Debian-Security: https://security-tracker.debian.org/tracker/CVE-2021-23980
+
+fixes: bug 1689399 / GHSA vv2x-vrpj-qqpq
+---
+ bleach/html5lib_shim.py |  1 +
+ bleach/sanitizer.py |  4 
+ tests/test_clean.py | 47 +
+ 3 files changed, 52 insertions(+)
+
+--- a/bleach/html5lib_shim.py
 b/bleach/html5lib_shim.py
+@@ -48,6 +48,7 @@ from html5lib._inputstream import (
+ HTMLInputStream,
+ )  # noqa: E402 module level import not at top of file
+ from html5lib.serializer import (
++escape,
+ HTMLSerializer,
+ )  # noqa: E402 module level import not at top of file
+ from html5lib._tokenizer import (
+--- a/bleach/sanitizer.py
 b/bleach/sanitizer.py
+@@ -376,6 +376,10 @@ class BleachSanitizerFilter(html5lib_shi
+ 
+ elif token_type == "Comment":
+ if not self.strip_html_comments:
++# call lxml.sax.saxutils to escape &, <, and > in addition to " and '
++token["data"] = html5lib_shim.escape(
++token["data"], entities={'"': "", "'": ""}
++)
+ return token
+ else:
+ return None
+--- a/tests/test_clean.py
 b/tests/test_clean.py
+@@ -766,6 +766,53 @@ def test_namespace_rc_data_element_strip
+ )
+ 
+ 
++@pytest.mark.parametrize(
++"namespace_tag, end_tag, data, expected",
++[
++(
++"math",
++"p",
++"",
++),
++(
++"math",
++"br",
++"",
++),
++(
++"svg",
++"p",
++"",
++),
++(
++"svg",
++"br",
++"",
++),
++],
++)
++def test_html_comments_escaped(namespace_tag, end_tag, data, expected):
++# refs: bug 1689399 / GHSA-vv2x-vrpj-qqpq
++#
++# p and br can be just an end tag (e.g.  == )
++#
++# In browsers:
++#
++# * img and other tags break out of the svg or math namespace (e.g.  == )
++# * style does not (e.g.  == 

Bug#985893: New location of the Debian Salsa repository

[Christopher Talbot]

Hello,

At the suggestion of Mr. Guido Günther, the new Debian Salsa home is
at:

https://salsa.debian.org/DebianOnMobile-team/mmsd

-- 
Respectfully,
Chris Talbot

Bug#986336: libopenlibm-dev: Wrong prefix used in openlibm.pc

[Mitsutoshi Aoe]

Package: libopenlibm-dev
Version: 0.7.0+dfsg-2
Severity: important

Dear Maintainer,

libopenlibm-dev includes a pkg-config file called openlibm.pc but it contains
wrong "prefix" and renderes pkg-config --libs or --cflags openlibm unusable.

I think the following shell session demonstrates the issue well enough:

% pkg-config --libs --cflags openlibm
-I/usr/local/include -L/usr/local/lib -lopenlibm
% grep ^prefix /usr/lib/x86_64-linux-gnu/pkgconfig/openlibm.pc
prefix=/usr/local
% dpkg -L libopenlibm-dev | grep /usr/local
% dpkg -L libopenlibm-dev | grep /usr/lib
/usr/lib
/usr/lib/x86_64-linux-gnu
/usr/lib/x86_64-linux-gnu/libopenlibm.a
/usr/lib/x86_64-linux-gnu/pkgconfig
/usr/lib/x86_64-linux-gnu/pkgconfig/openlibm.pc
/usr/lib/x86_64-linux-gnu/libopenlibm.so

In short, the prefix in the pkg-config file (/usr/local) doesn't match
the actual location this package installs the files (/usr). So any
programs that link to this library cannot use pkg-config.

-- 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-4-amd64 (SMP w/4 CPU threads)
Locale: LANG=en_US.UTF-8, LC_CTYPE=UTF-8 (charmap=UTF-8) (ignored: LC_ALL set 
to en_US.UTF-8), LANGUAGE=en_US.UTF-8
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages libopenlibm-dev depends on:
ii  libopenlibm3  0.7.0+dfsg-2

libopenlibm-dev recommends no packages.

libopenlibm-dev suggests no packages.

-- no debconf information

Bug#986335: chromium: Update to version 89.0.4389.114 (security-fixes)

[Sedat Dilek]

Package: chromium
Version: 89.0.4389.90-1
Severity: normal
X-Debbugs-Cc: sedat.di...@gmail.com

Dear Maintainer,

several issues were fixed in Google's chrome version 89.0.4389.114 recently.

Debian's security-tracker lists these CVEs:

Bug stretch buster  bullseyesid 
Description
CVE-2021-21199  vulnerable  vulnerable  vulnerable  vulnerable  
CVE-2021-21198  vulnerable  vulnerable  vulnerable  vulnerable  
CVE-2021-21197  vulnerable  vulnerable  vulnerable  vulnerable  
CVE-2021-21196  vulnerable  vulnerable  vulnerable  vulnerable  
CVE-2021-21195  vulnerable  vulnerable  vulnerable  vulnerable  
CVE-2021-21194  vulnerable  vulnerable  vulnerable  vulnerable

See also "Stable Channel Update for Desktop" in [2] (and [3] for German 
reading/speaking folks).

Please update Debian's chromium the version of Google's chrome.

Thanks.

Regards,
- Sedat -

[1] https://security-tracker.debian.org/tracker/source-package/chromium
[2] 
https://chromereleases.googleblog.com/2021/03/stable-channel-update-for-desktop_30.html
[3] 
https://www.heise.de/news/Chrome-Update-fuer-Desktop-Ausgabe-beseitigt-mehrere-Sicherheitsprobleme-6002712.html
 (German)


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

Kernel: Linux 5.12.0-rc5-11-amd64-clang12-lto (SMP w/4 CPU threads)
Kernel taint flags: TAINT_WARN, TAINT_UNSIGNED_MODULE
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 chromium depends on:
ii  chromium-common  89.0.4389.90-1
ii  libasound2   1.2.4-1.1
ii  libatk-bridge2.0-0   2.38.0-1
ii  libatk1.0-0  2.36.0-2
ii  libatomic1   10.2.1-6
ii  libatspi2.0-02.38.0-2
ii  libavcodec58 7:4.3.2-0+deb11u1
ii  libavformat587:4.3.2-0+deb11u1
ii  libavutil56  7:4.3.2-0+deb11u1
ii  libc62.31-11
ii  libcairo21.16.0-5
ii  libcups2 2.3.3op2-3
ii  libdbus-1-3  1.12.20-2
ii  libdrm2  2.4.104-1
ii  libevent-2.1-7   2.1.12-stable-1
ii  libexpat12.2.10-2
ii  libflac8 1.3.3-2
ii  libfontconfig1   2.13.1-4.2
ii  libfreetype6 2.10.4+dfsg-1
ii  libgbm1  20.3.5-1
ii  libgcc-s110.2.1-6
ii  libgdk-pixbuf-2.0-0  2.42.2+dfsg-1
ii  libglib2.0-0 2.66.8-1
ii  libgtk-3-0   3.24.24-3
ii  libharfbuzz0b2.7.4-1
ii  libicu67 67.1-6
ii  libjpeg62-turbo  1:2.0.6-4
ii  libjsoncpp24 1.9.4-4
ii  liblcms2-2   2.12~rc1-2
ii  libminizip1  1.1-8+b1
ii  libnspr4 2:4.29-1
ii  libnss3  2:3.63-1
ii  libopenjp2-7 2.4.0-3
ii  libopus0 1.3.1-0.1
ii  libpango-1.0-0   1.46.2-3
ii  libpng16-16  1.6.37-3
ii  libpulse014.2-2
ii  libre2-9 20210201+dfsg-1
ii  libsnappy1v5 1.1.8-1
ii  libstdc++6   10.2.1-6
ii  libvpx6  1.9.0-1
ii  libwebp6 0.6.1-2+b1
ii  libwebpdemux20.6.1-2+b1
ii  libwebpmux3  0.6.1-2+b1
ii  libx11-6 2:1.7.0-2
ii  libxcb1  1.14-3
ii  libxcomposite1   1:0.4.5-1
ii  libxdamage1  1:1.1.5-2
ii  libxext6 2:1.3.3-1.1
ii  libxfixes3   1:5.0.3-2
ii  libxml2  2.9.10+dfsg-6.3+b1
ii  libxrandr2   2:1.5.1-1
ii  libxshmfence11.3-1
ii  libxslt1.1   1.1.34-4
ii  zlib1g   1:1.2.11.dfsg-2

Versions of packages chromium recommends:
ii  chromium-sandbox  89.0.4389.90-1

Versions of packages chromium suggests:
pn  chromium-driver  
ii  chromium-l10n89.0.4389.90-1
pn  chromium-shell   

Versions of packages chromium-common depends on:
ii  libc6   2.31-11
ii  libstdc++6  10.2.1-6
ii  libx11-62:1.7.0-2
ii  libxext62:1.3.3-1.1
ii  x11-utils   7.7+5
ii  xdg-utils   1.1.3-4
ii  zlib1g  1:1.2.11.dfsg-2

Versions of packages chromium-common recommends:
ii  chromium-sandbox89.0.4389.90-1
ii  fonts-liberation1:1.07.4-11
ii  gnome-shell [notification-daemon]   3.38.4-1
ii  libgl1-mesa-dri 20.3.5-1
ii  libu2f-udev 1.1.10-3
ii  notification-daemon 3.20.0-4
ii  plasma-workspace [notification-daemon]  4:5.21.3-1
ii  system-config-printer   1.5.14-1
ii  upower  0.99.11-2

Versions of packages chromium-sandbox depends on:
ii  libc6  2.31-11

-- Configuration Files:
/etc/chromium.d/default-flags changed [not included]

-- no debconf 

Bug#986334: O: ladvd -- LLDP/CDP sender

[Marco d'Itri]

Package: wnpp
Severity: normal
Control: affects -1 src:ladvd

I intend to orphan the ladvd package.

I do not care for it anymore because, when systemd-networkd is not 
enough, then I think that lldpd is generally better.


The package description is:
 ladvd sends link layer advertisements on all available interfaces.
 This makes connected hosts visible on managed switches. By default it
 will run as a privilege-separated daemon.

-- 
ciao,
Marco


signature.asc
Description: PGP signature

Bug#985489: 0ad freezes with 0.0.24b1

[Bernhard Übelacker]

Dear Maintainer,
I tried to have a look at this savegame and when loaded
shows these freezes to me too.

An attached gdb shows that leaving VertexPathfinder::ComputeShortPath
takes some minutes, while the game is frozen.

Upstream might have already some optimizations
for this issue in [1].

At least the game shows an "obstacle" that might block some units,
because of an closed gate.

Kind regards,
Bernhard


(gdb) bt
#0  CheckVisibility (a=..., edges=..., a=..., edges=..., b=...) at /usr/include/c++/10/bits/stl_vector.h:918
#1  VertexPathfinder::ComputeShortPath (this=0x5587684b0f50, request=..., 
cmpObstructionManager=...) at 
../../../source/simulation2/helpers/VertexPathfinder.cpp:786
#2  0x5587572ccc1d in CCmpPathfinder::PathfinderWorker::Work 
(this=0x558767340600, pathfinder=...) at 
../../../source/simulation2/components/CCmpPathfinder.cpp:772
#3  0x5587572ccffb in CCmpPathfinder::StartProcessingMoves (this=0x55875e086000, 
useMax=) at 
../../../source/simulation2/components/CCmpPathfinder.cpp:841
#4  0x55875725417f in CSimulation2Impl::Update (this=0x55875e1350c0, 
turnLength=, commands=std::vector of length 0, capacity 0) at 
../../../source/simulation2/Simulation2.cpp:399
#5  0x55875729647c in CTurnManager::Update (this=0x55875db87c20, 
simFrameLength=, maxTurns=1) at 
../../../source/simulation2/system/TurnManager.cpp:169
#6  0x5587573e786e in CGame::Update (this=0x55875bb809d0, 
deltaRealTime=0.20622983574867249, doInterpolate=) at 
../../../source/ps/Game.cpp:400
#7  0x5587571f3b32 in Frame () at ../../../source/main.cpp:426
#8  RunGameOrAtlas (argc=, argv=) at 
../../../source/main.cpp:692
#9  0x5587571e021a in main (argc=1, argv=0x7fffcf84d8c8) at 
../../../source/main.cpp:743
(gdb) finish
Run till exit from #0  CheckVisibility (a=..., edges=..., a=..., edges=..., 
b=...) at /usr/include/c++/10/bits/stl_vector.h:918
VertexPathfinder::ComputeShortPath (this=0x5587684b0f50, request=..., 
cmpObstructionManager=...) at 
../../../source/simulation2/helpers/VertexPathfinder.cpp:786
786 ../../../source/simulation2/helpers/VertexPathfinder.cpp: Datei oder 
Verzeichnis nicht gefunden.
(gdb) finish
Run till exit from #0  VertexPathfinder::ComputeShortPath (this=0x5587684b0f50, 
request=..., cmpObstructionManager=...) at 
../../../source/simulation2/helpers/VertexPathfinder.cpp:786
CCmpPathfinder::PathfinderWorker::Work (this=0x558767340600, pathfinder=...) at 
../../../source/simulation2/components/CCmpPathfinder.cpp:773
...


[1] 
https://trac.wildfiregames.com/log/ps/trunk/source/simulation2/helpers/VertexPathfinder.cpp

Bug#986333: debian-security-support: Match ecosystems with limited support

[Sylvain Beucler]

Package: debian-security-support
Severity: normal

Hi,

Sometimes, entire ecosystems are affected by Debian support decisions.

These source package sets comes to mind:
- node-*
  
https://www.debian.org/releases/jessie/amd64/release-notes/ch-information.en.html#libv8
- golang-*
  
https://www.debian.org/releases/buster/amd64/release-notes/ch-information.en.html#golang-static-linking

Currently 'check-support-status' fails to detect individual packages
affected by these decisions, it only notifies about explicitly
referenced packages such as 'nodejs'.
Maybe regex matching would help.

(debian-security-support is an important tool in the Debian LTS/ELTS
offering, so I believe we could offer help/time in this area.)

What do you think?

Cheers!
Sylvain

Bug#986269: Proposed debdiff for CVE-2021-22876 and CVE-2021-22890

[Salvatore Bonaccorso]

Hi Alessandro,

Attached is proposed debdiff for curl in unstable fixing
CVE-2021-22876 and CVE-2021-22890 as already done in stable.

MR as well done on salsa at
https://salsa.debian.org/debian/curl/-/merge_requests/10

Regards,
Salvatore
diff -Nru curl-7.74.0/debian/changelog curl-7.74.0/debian/changelog
--- curl-7.74.0/debian/changelog2021-02-10 01:42:40.0 +0100
+++ curl-7.74.0/debian/changelog2021-04-03 14:43:39.0 +0200
@@ -1,3 +1,13 @@
+curl (7.74.0-1.2) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * transfer: strip credentials from the auto-referer header field
+(CVE-2021-22876) (Closes: #986269)
+  * vtls: add 'isproxy' argument to Curl_ssl_get/addsessionid()
+(CVE-2021-22890) (Closes: #986270)
+
+ -- Salvatore Bonaccorso   Sat, 03 Apr 2021 14:43:39 +0200
+
 curl (7.74.0-1.1) unstable; urgency=medium
 
   * Non-maintainer upload.
diff -Nru 
curl-7.74.0/debian/patches/14_transfer-strip-credentials-from-the-auto-referer-hea.patch
 
curl-7.74.0/debian/patches/14_transfer-strip-credentials-from-the-auto-referer-hea.patch
--- 
curl-7.74.0/debian/patches/14_transfer-strip-credentials-from-the-auto-referer-hea.patch
1970-01-01 01:00:00.0 +0100
+++ 
curl-7.74.0/debian/patches/14_transfer-strip-credentials-from-the-auto-referer-hea.patch
2021-04-03 14:43:39.0 +0200
@@ -0,0 +1,140 @@
+From: Viktor Szakats 
+Date: Tue, 23 Feb 2021 14:54:46 +0100
+Subject: transfer: strip credentials from the auto-referer header field
+Origin: 
https://github.com/curl/curl/commit/7214288898f5625a6cc196e22a74232eada7861c
+Bug-Debian-Security: https://security-tracker.debian.org/tracker/CVE-2021-22876
+
+Added test 2081 to verify.
+
+CVE-2021-22876
+
+Bug: https://curl.se/docs/CVE-2021-22876.html
+---
+ lib/transfer.c  | 25 ++--
+ tests/data/Makefile.inc |  2 +-
+ tests/data/test2081 | 66 +
+ 3 files changed, 90 insertions(+), 3 deletions(-)
+ create mode 100644 tests/data/test2081
+
+--- a/lib/transfer.c
 b/lib/transfer.c
+@@ -1588,6 +1588,9 @@ CURLcode Curl_follow(struct Curl_easy *d
+   data->set.followlocation++; /* count location-followers */
+ 
+   if(data->set.http_auto_referer) {
++CURLU *u;
++char *referer;
++
+ /* We are asked to automatically set the previous URL as the referer
+when we get the next URL. We pick the ->url field, which may or may
+not be 100% correct */
+@@ -1597,9 +1600,27 @@ CURLcode Curl_follow(struct Curl_easy *d
+   data->change.referer_alloc = FALSE;
+ }
+ 
+-data->change.referer = strdup(data->change.url);
+-if(!data->change.referer)
++/* Make a copy of the URL without crenditals and fragment */
++u = curl_url();
++if(!u)
++  return CURLE_OUT_OF_MEMORY;
++
++uc = curl_url_set(u, CURLUPART_URL, data->change.url, 0);
++if(!uc)
++  uc = curl_url_set(u, CURLUPART_FRAGMENT, NULL, 0);
++if(!uc)
++  uc = curl_url_set(u, CURLUPART_USER, NULL, 0);
++if(!uc)
++  uc = curl_url_set(u, CURLUPART_PASSWORD, NULL, 0);
++if(!uc)
++  uc = curl_url_get(u, CURLUPART_URL, , 0);
++
++curl_url_cleanup(u);
++
++if(uc || referer == NULL)
+   return CURLE_OUT_OF_MEMORY;
++
++data->change.referer = referer;
+ data->change.referer_alloc = TRUE; /* yes, free this later */
+   }
+ }
+--- a/tests/data/Makefile.inc
 b/tests/data/Makefile.inc
+@@ -218,7 +218,7 @@ test2064 test2065 test2066 test2067 test
+ test2064 test2065 test2066 test2067 test2068 test2069 test2070 \
+  test2071 test2072 test2073 test2074 test2075 test2076 test2077 \
+ test2078 \
+-test2080 \
++test2080 test2081 \
+ test2100 \
+ \
+ test3000 test3001 test3002 test3003 test3004 test3005 test3006 test3007 \
+--- /dev/null
 b/tests/data/test2081
+@@ -0,0 +1,66 @@
++
++
++
++HTTP
++HTTP GET
++referer
++followlocation
++--write-out
++
++
++
++# Server-side
++
++
++HTTP/1.1 301 This is a weirdo text message swsclose
++Location: data/%TESTNUMBER0002.txt?coolsite=yes
++Content-Length: 62
++Connection: close
++
++This server reply is for testing a simple Location: following
++
++
++
++# Client-side
++
++
++http
++
++ 
++Automatic referrer credential and anchor stripping check
++ 
++ 
++http://user:pass@%HOSTIP:%HTTPPORT/we/want/our/%TESTNUMBER#anchor --location 
--referer ';auto' --write-out '%{referer}\n'
++
++
++
++# Verify data after the test has been "shot"
++
++
++52
++
++
++GET /we/want/our/%TESTNUMBER HTTP/1.1
++Host: %HOSTIP:%HTTPPORT
++Authorization: Basic dXNlcjpwYXNz
++User-Agent: curl/%VERSION
++Accept: */*
++
++GET /we/want/our/data/%TESTNUMBER0002.txt?coolsite=yes HTTP/1.1
++Host: %HOSTIP:%HTTPPORT
++Authorization: Basic dXNlcjpwYXNz
++User-Agent: curl/%VERSION
++Accept: */*
++Referer: http://%HOSTIP:%HTTPPORT/we/want/our/%TESTNUMBER
++
++
++
++HTTP/1.1 301 

Bug#986332: lsattr on certiain files in /dev results in "stack smashing detected"

[Marc Haber]

Package: e2fsprogs
Version: 1.46.2-1
Severity: normal
File: /usr/bin/lsattr

Hi,

while debugging aide, I have stumbled upon a possible bug in lsattr or
one of the underlying libraries. Doing lsattr on /dev/dri/card0 results
in an abort with "stack smashing detected":

| root@testsid85:~# sudo lsattr /dev/dri/card0
| *** stack smashing detected ***: terminated
| Aborted

Similiar behavior is observed when aide is trying to read the ext2 attrs
of this file, so this is most probably a library issue.

I can provide a backtrace if it helps.

Greetings
Marc


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

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

Versions of packages e2fsprogs depends on:
ii  libblkid12.36.1-7
ii  libc62.31-11
ii  libcom-err2  1.46.2-1
ii  libext2fs2   1.46.2-1
ii  libss2   1.46.2-1
ii  libuuid1 2.36.1-7
ii  logsave  1.46.2-1

Versions of packages e2fsprogs recommends:
pn  e2fsprogs-l10n  

Versions of packages e2fsprogs suggests:
pn  e2fsck-static  
pn  fuse2fs
pn  gpart  
ii  parted 3.4-1

-- no debconf information

Bug#985948: libubootenv-tool: Debug lines from fw_printenv break RAUC

[Bastian Germann]

Control: tags -1 patch

A patch is enclosed.
From: Bastian Germann 
Date: Sat, 3 Apr 2021 14:36:37 +0200
Subject: Compile with NDEBUG set

This makes the tools' output more compatible with the original fw_*env tools.

Signed-off-by: Bastian Germann 
---
 debian/rules | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/debian/rules b/debian/rules
index 3b4cf35..e668526 100755
--- a/debian/rules
+++ b/debian/rules
@@ -4,7 +4,7 @@
 
 CMAKE_FLAGS = \
 	-DCMAKE_VERBOSE_MAKEFILE=ON \
-	-DCMAKE_C_FLAGS_RELEASE="$(CFLAGS)" \
+	-DCMAKE_C_FLAGS_RELEASE="$(CFLAGS) NDEBUG=" \
 	-DCMAKE_EXE_LINKER_FLAGS_RELEASE="$(LDFLAGS)" \
 	-DBUILD_DOCS=ON \
 	-DCMAKE_INSTALL_INCLUDEDIR="include/$(DEB_HOST_MULTIARCH)"

Bug#889822: Can the bug for the Bullseye release still be fixed?

[Giovanni Mascellani]

Hi,

Il 19/03/21 09:23, Matthias Klein ha scritto:

Is there any chance / possibility to fix the problem? Maybe even still for 
bullseye?


No, I think it is too late for bullseye, and I wouldn't have the time to 
work on it anyway, sorry.


Though I generally agree that it would be nicer to have Multi-Arch: same 
for boost -dev package.


Giovanni.
--
Giovanni Mascellani 

Bug#986331: ITP: prometheus-nextcloud-exporter -- Prometheus exporter for Nextcloud server metrics

[Jonas Meurer]

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

* Package name: prometheus-nextcloud-exporter
  Version : 0.3.0
  Upstream Author : Robert Jacob 
* URL : https://github.com/pijn-tech/nextcloud-exporter
* License : MIT
  Programming Lang: Go
  Description : Prometheus exporter for Nextcloud server metrics

Prometheus exporter for Nextcloud server metrics, written in Go.

I intend to maintain this package under the Debian Go Packaging Team umbrella.

Bug#985903: lib3MF.so.1: undefined symbol: zip_fclose

[Kristian Nielsen]

Not 100% clear what the issue(s) reported here are, but I looked through the
patches, and saw these:

1. Some libz/libzip changes. I'm guessing these are to avoid having to add
-lz/-lzip to the using project? There was a related change in the recent
NMU, 1.8.1+ds-3.1, which instead adds links to these libraries. This might
fix the problem reported here also.

2. There are some code-style changes (and a -Wall which may have triggered
these), these may be reasonable but perhaps not too relevant for the Debian
packaging.

3. There is what looks like a fix of a genuine mistake in the code
(always-true conditional). I files this upstream here:

  https://github.com/3MFConsortium/lib3mf/issues/262

Is there any user impact from this bug, or was it perhaps just something
noticed from -Wall? (At this stage an important impact is needed to include
a fix in the bullseye release).

 - Kristian.

Bug#985948: libubootenv-tool: Debug lines from fw_printenv break RAUC

[Bastian Germann]

On Fri, 26 Mar 2021 16:53:31 +0100 Paul Jena  wrote:

Package: libubootenv-tool
Version: 0.3-1
Severity: grave

Hello,

there are compatibility problems with RAUC and the libubootenv-tool package.

RAUC requires the fw_setenv and fw_printenv utilites to interact with the
u-boot-environment. After Installing the libubootenv-tool package to get fw_printenv 
and fw_setenv, RAUC didnt work properly. i.e.:


How is this a grave bug? RAUC explicitly says in its Kconfig: "To interact with U-Boot, fw_printenv 
and fw_setenv from u-boot-tools are used." So using it with libubootenv's tools is not expected.



After building a fw_printenv that doesnt print the Debug Mesaage the Rauc 
worked properly again.
(I looked into the source code of libubootenv and saw that passing the NDEBUG 
compiler flag
supresses the Debugging Messages:
https://salsa.debian.org/debian/libubootenv/-/blob/master/src/uboot_env.c#L946)
i.e:

$ fw_printenv BOOT_ORDER 
BOOT_ORDER=B A


$ rauc status
...
=== Bootloader ===
Activated: rootfs.1 (B)
...

Perhaps it is desirable that libubootenv-tool provides output similiar to the 
native
u-boot envtools to support compability, by building it in downstream with the 
NDEBUG
compiler flag. 


Setting NDEBUG is a good solution to the problem.

Bug#984967: About bug 984967

[andrew glaeser]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On Sun, 28 Mar 2021 11:55:31 +0200
Christian Marillat  wrote:

> Hi,
> 
> I read this bug (984967) and as I don't like bug in my package i sent
> this e-mail.
> 
> I don't use x2go and would like to know what is exactly wrong with
> handbrake.
> 
> Do you have error messages ?
> 
> handbrake log files are stored in ~/.config/ghb/EncodeLogs
> 
> Do you see errors in these files ?
> 
> Christian


The behaviour is the error-message: handbrake transcoding-queue discontinues,
when running headless with x2go-server.
I do think I have explained the issue in the most possible detailed way,
also mentioning the warning from Handbrake.fr upstream about debian-packages,
that were worsened or crippled for political reasons, including
deb-multimedia, in the name of defending copyright for example, so obviously
the real motivations behind such measures are financial, because somebody
paid for them.



-BEGIN PGP SIGNATURE-

iF0EARECAB0WIQTF9uNaslvnJpWt8kXn6sEfJS3nCwUCYGhW8QAKCRDn6sEfJS3n
CySuAKCGyG789p6HIEgJfLGiPFxtc7YS1QCgp32KRR0c9TttuBK6eefOvvZcKrE=
=RiAi
-END PGP SIGNATURE-

Bug#986330: Please upgrade to GVM 20.8.1 (20.8.0 is unusable)

[Julien AUBIN]

Package: gvm
Version: 20.8.0.2
Severity: important

Dear Maintainer,

The GVM platform version 20.8.0.2 does contain a bug which makes the platform
unusable :
https://github.com/Atomicorp/gvm/issues/48

Basically you cannot set up the cert data, rendering the whole package
unusable. The GVM daemon attempts to download split data, fails to parse it,
reattempts again until /tmp is full and then fails. The fix has been done in
GVM 20.8.1, could you please update GVM ?

https://github.com/greenbone/gvmd/releases/tag/v20.8.1

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


-- 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-5-amd64 (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 /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages gvm depends on:
ii  gvmd 20.8.0+git2020-2
ii  openvas-scanner  20.8.0-2
ii  ospd-openvas 20.8.0-1
ii  psmisc   23.4-2
ii  rsync3.2.3-4
ii  xsltproc 1.1.34-4

Versions of packages gvm recommends:
ii  greenbone-security-assistant  20.8.0-2
ii  gvm-tools 21.1.0-1

gvm suggests no packages.

Bug#953305: backported kernel 5.10 to become stable soon

[Andi Glaeser mobil]

[0.00] microcode: microcode updated early to revision 0x7, date = 
2018-04-23
[0.00] Linux version 5.10.0-0.bpo.4-amd64 
(debian-ker...@lists.debian.org) (gcc-8 (Debian 8.3.0-6) 8.3.0, GNU ld (GNU 
Binutils for Debian) 2.31.1) #1 SMP Debian 5.10.19-1~bpo10+1 (2021-03-13)
[0.00] Command line: BOOT_IMAGE=/vmlinuz-5.10.0-0.bpo.4-amd64 
root=UUID=8def690b-ee7d-4d54-b94a-87b9aa4e9b19 ro quiet
[0.00] x86/fpu: x87 FPU will use FXSAVE
[0.00] BIOS-provided physical RAM map:
[0.00] BIOS-e820: [mem 0x-0x0009fbff] usable
[0.00] BIOS-e820: [mem 0x0009fc00-0x0009] reserved
[0.00] BIOS-e820: [mem 0x000e-0x000f] reserved
[0.00] BIOS-e820: [mem 0x0010-0xbafc1fff] usable
[0.00] BIOS-e820: [mem 0xbafc2000-0xbb6c1fff] reserved
[0.00] BIOS-e820: [mem 0xbb6c2000-0xbb7c1fff] ACPI NVS
[0.00] BIOS-e820: [mem 0xbb7c2000-0xbb7fefff] ACPI data
[0.00] BIOS-e820: [mem 0xbb7ff000-0xbb7f] usable
[0.00] BIOS-e820: [mem 0xbb80-0xbbff] reserved
[0.00] BIOS-e820: [mem 0xe000-0xefff] reserved
[0.00] BIOS-e820: [mem 0xfec0-0xfec00fff] reserved
[0.00] BIOS-e820: [mem 0xfed1-0xfed13fff] reserved
[0.00] BIOS-e820: [mem 0xfed19000-0xfed19fff] reserved
[0.00] BIOS-e820: [mem 0xfed1b000-0xfed1] reserved
[0.00] BIOS-e820: [mem 0xfee0-0xfee00fff] reserved
[0.00] BIOS-e820: [mem 0xffd0-0x] reserved
[0.00] BIOS-e820: [mem 0x0001-0x000137ff] usable
[0.00] NX (Execute Disable) protection: active
[0.00] SMBIOS 2.6 present.
[0.00] DMI: Hewlett-Packard HP EliteBook 8440p/172A, BIOS 68CCU Ver. 
F.12 03/09/2011
[0.00] tsc: Fast TSC calibration using PIT
[0.00] tsc: Detected 2394.436 MHz processor
[0.001190] e820: update [mem 0x-0x0fff] usable ==> reserved
[0.001193] e820: remove [mem 0x000a-0x000f] usable
[0.001201] last_pfn = 0x138000 max_arch_pfn = 0x4
[0.001206] MTRR default type: uncachable
[0.001207] MTRR fixed ranges enabled:
[0.001208]   0-9 write-back
[0.001209]   A-B uncachable
[0.001210]   C-F write-protect
[0.001211] MTRR variable ranges enabled:
[0.001213]   0 base 0FFC0 mask FFFC0 write-protect
[0.001214]   1 base 0 mask F8000 write-back
[0.001215]   2 base 08000 mask FC000 write-back
[0.001216]   3 base 0BC00 mask FFC00 uncachable
[0.001217]   4 base 1 mask FC000 write-back
[0.001218]   5 base 13800 mask FF800 uncachable
[0.001219]   6 disabled
[0.001219]   7 disabled
[0.001852] x86/PAT: Configuration [0-7]: WB  WC  UC- UC  WB  WP  UC- WT  
[0.002149] last_pfn = 0xbb800 max_arch_pfn = 0x4

[0.011413] RAMDISK: [mem 0x30b73000-0x345b0fff]
[0.011423] ACPI: Early table checksum verification disabled
[0.011428] ACPI: RSDP 0x000FC600 24 (v02 HPQOEM)
[0.011433] ACPI: XSDT 0xBB7FE120 8C (v01 HPQOEM SLIC-MPC 
000F  0113)
[0.011440] ACPI: FACP 0xBB7FC000 F4 (v03 HPQOEM 172A 
000F HP   0001)
[0.011446] ACPI: DSDT 0xBB7D6000 020160 (v02 HPQOEM 172A 
0001 INTL 20060912)
[0.011450] ACPI: FACS 0xBB76 40
[0.011453] ACPI: FACS 0xBB76 40
[0.011457] ACPI: HPET 0xBB7FB000 38 (v01 HPQOEM 172A 
0001 HP   0001)
[0.011461] ACPI: APIC 0xBB7FA000 BC (v01 HPQOEM 172A 
0001 HP   0001)
[0.011464] ACPI: MCFG 0xBB7F9000 3C (v01 HPQOEM 172A 
0001 HP   0001)
[0.011468] ACPI: TCPA 0xBB7F7000 32 (v02 HPQOEM 172A 
 HP   0001)
[0.011472] ACPI: SSDT 0xBB7D3000 000135 (v01 HPQOEM SataAhci 
1000 INTL 20060912)
[0.011476] ACPI: SSDT 0xBB7D2000 000314 (v01 HPQOEM PtidDevc 
1000 INTL 20060912)
[0.011479] ACPI: SLIC 0xBB7D1000 000176 (v01 HPQOEM SLIC-MPC 
0001 HP   0001)
[0.011483] ACPI: DMAR 0xBB7D B8 (v01 INTEL  CP_DALE  
0001 INTL 0001)
[0.011487] ACPI: SSDT 0xBB7CF000 000A10 (v01 PmRef  CpuPm
3000 INTL 20060912)
[0.011491] ACPI: SSDT 0xBB7CE000 000288 (v01 PmRef  Cpu0Tst  
3000 INTL 20060912)
[0.011494] ACPI: SSDT 0xBB7CD000 000225 (v01 PmRef  ApTst
3000 INTL 20060912)
[0.011498] ACPI: ASF! 0xBB7F8000 A0 (v32 HPQOEM 172A 
0001 HP   0001)
[0.011509] ACPI: Local APIC address 0xfee0
[0.011636] No NUMA configuration found

Bug#986320: Stronger advice on when to use native packages

[David Bremner]

Russ Allbery  writes:

> Currently, Debian Policy is silent on when it's appropriate to use a
> native package, but there may be a project consensus aganist using
> native packages when the software has an existence outside of Debian.

Personally I don't think Debian policy should be concerned with what
happens outside Debian. As long as a given process serves the users and
contributors of/to Debian well, that seems sufficient to me. I
understand that others disagree, particularly on how much we should
consider the needs of derivative distributions.

> Even if that consensus does not exist, there is probably consensus
> that native packages are a poor match for large packages (because of
> the inefficiency of making small updates to the packaging of native
> packages), and there may be other cases where we can give stronger
> guidance.

That seems more like something that could be documented in devref as a
best practice, rather than something needing normative language.


signature.asc
Description: PGP signature

Bug#986329: debhelper: dh_installtmpfiles calls systemd-tmpfiles on not *.conf files

[Balint Reczey]

Package: debhelper
Severity: wishlist
Version: 13.3.4

Dear Maintainers,

Systemd upstream added README files in .d directories including in tmpfiles.d:
https://github.com/systemd/systemd/commit/d83e90c73cf25a839f5e60f355baa0d38364ff41

If /usr/lib/tmpfiles.d/README is shipped in the systemd package it
triggers errors to be shown upon installation because in postinst the
README is processed like it was a config file:
systemd.postinst:
...
if [ -d /run/systemd/system ] ; then
systemd-tmpfiles --create README debian.conf home.conf
journal-nocow.conf legacy.conf systemd-nologin.conf
systemd-pstore.conf systemd-tmp.conf systemd.conf tmp.conf var.conf
x11.conf >/dev/null || true
...

For now the plan is not shipping the README, but it would be nice to
not have this issue in debhelper.

Cheers,
Balint

-- 
Balint Reczey
Ubuntu & Debian Developer

Bug#900819: gimp: Dependency on liblcms2-2 needs tightening

[Simon McVittie]

On Sat, 03 Apr 2021 at 17:06:49 +0800, Michael Deegan wrote:
> Hello, I can confirm that the issue still exists (being part way through
> gradually upgrading my machine from buster to bullseye).

I would recommend trying to do the majority of the buster -> bullseye
upgrade in one go.

If you upgrade individual packages from buster to bullseye, that is
something that is *meant* to work, but realistically, there will be a bug
somewhere: there's an extremely large number of possible partial upgrades,
and Debian maintainers cannot test more than a tiny fraction of them. The
combination of packages on your system during a partial upgrade is likely
to be something unique to your system that nobody else has ever tested.

> Liblcms2 version mismatch!
> 
> GIMP was compiled against LittleCMS version 2.2, but the
> LittleCMS version found at runtime is only 2.9.
...
> My uneducated guess is that something plucked "2.2" from somewhere, where
> there should have been a *checks apt-cache policy* "2.12".

Looks like GIMP is parsing the LCMS_VERSION incorrectly when generating
this error message, based on an assumption that the minor version is a
single decimal digit: it says 2.2, but it really means 2.12. The version
number that it is actually comparing before generating the error message
is 209x < 2120 (meaning 2.9.x < 2.12.0), which makes more sense.

The gimp packaging should either generate tighter dependencies at
compile-time, or patch out these checks as redundant with the dependency
system.

smcv

Bug#986321: reportbug: command-not-found has crashed!

[ash]

Package: reportbug
Version: 7.10.3
Severity: normal
Tags: ftbfs
X-Debbugs-Cc: ash3...@protonmail.com


-- Package-specific info:
** Environment settings:
INTERFACE="gtk"

** /home/ash/.reportbugrc:
reportbug_version "7.10.3"
mode advanced
ui gtk
email "ash3...@protonmail.com"
no-cc
list-cc-me
smtphost reportbug.debian.org

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

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

Versions of packages reportbug depends on:
ii  apt2.2.2
ii  python33.9.2-2
ii  python3-reportbug  7.10.3
ii  sensible-utils 0.0.14

reportbug recommends no packages.

Versions of packages reportbug suggests:
pn  claws-mail 
pn  debconf-utils  
pn  debsums
pn  dlocate
pn  emacs-bin-common   
ii  exim4-daemon-light [mail-transport-agent]  4.94-17
ii  file   1:5.39-3
ii  gnupg  2.2.27-1
ii  python3-urwid  2.1.2-1
pn  reportbug-gtk  
ii  xdg-utils  1.1.3-4

Versions of packages python3-reportbug depends on:
ii  apt2.2.2
ii  file   1:5.39-3
ii  python33.9.2-2
ii  python3-apt2.1.7
ii  python3-debian 0.1.39
ii  python3-debianbts  3.1.0
ii  python3-requests   2.25.1+dfsg-2
ii  sensible-utils 0.0.14

python3-reportbug suggests no packages.

-- no debconf information

Bug#986328: unblock: lib3mf/1.8.1+ds-4

[Kristian Nielsen]

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

Please unblock package lib3mf

[ Reason ]

This is a targeted fix, a backport of upstream fix for CVE-2021-21772, which
is a use-after-free on user-controlled input:

  https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=985092
  https://github.com/3MFConsortium/lib3mf/issues/254

[ Impact ]

This is a published security bug in upstream lib3mf.

[ Tests ]

 - We obtained a (non-published) .3mf that triggers the bug. I verified
   (with Valgrind) that opening this 3MF file triggers a use-after-free in
   lib3mf_1.8.1+ds-3.1 and that it does not in lib3mf_1.8.1+ds-4.

 - Package `openscad', the main reverse dependency, has a comprehensive
   testsuite which passes with lib3mf_1.8.1+ds-4.

[ 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 lib3mf/1.8.1+ds-4

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

Kernel: Linux 5.4.0-0.bpo.4-amd64 (SMP w/8 CPU cores)
Kernel taint flags: TAINT_UNSIGNED_MODULE
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_GB.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
diff -Nru lib3mf-1.8.1+ds/debian/changelog lib3mf-1.8.1+ds/debian/changelog
--- lib3mf-1.8.1+ds/debian/changelog2020-12-06 02:27:21.0 +0100
+++ lib3mf-1.8.1+ds/debian/changelog2021-04-01 21:25:54.0 +0200
@@ -1,3 +1,10 @@
+lib3mf (1.8.1+ds-4) unstable; urgency=medium
+
+  * Fix use-after-free (CVE-2021-21772), backporting fix from v2.1.1
+(Closes: #985092)
+
+ -- Kristian Nielsen   Thu, 01 Apr 2021 21:25:54 
+0200
+
 lib3mf (1.8.1+ds-3.1) unstable; urgency=medium
 
   * Non-maintainer upload.
diff -Nru lib3mf-1.8.1+ds/debian/control lib3mf-1.8.1+ds/debian/control
--- lib3mf-1.8.1+ds/debian/control  2019-01-20 18:32:34.0 +0100
+++ lib3mf-1.8.1+ds/debian/control  2021-04-01 21:25:54.0 +0200
@@ -2,6 +2,7 @@
 Section: libs
 Priority: optional
 Maintainer: Torsten Paul 
+Uploaders: Kristian Nielsen 
 Build-Depends: debhelper (>=12~), pkg-kde-tools, cmake, libzip-dev, 
zlib1g-dev, uuid-dev
 Standards-Version: 4.3.0
 Homepage: https://github.com/3MFConsortium/lib3mf
diff -Nru lib3mf-1.8.1+ds/debian/patches/fix_use_after_free.patch 
lib3mf-1.8.1+ds/debian/patches/fix_use_after_free.patch
--- lib3mf-1.8.1+ds/debian/patches/fix_use_after_free.patch 1970-01-01 
01:00:00.0 +0100
+++ lib3mf-1.8.1+ds/debian/patches/fix_use_after_free.patch 2021-04-01 
21:25:54.0 +0200
@@ -0,0 +1,76 @@
+From: Kristian Nielsen 
+Date: Thu, 1 Apr 2021 21:28:00 +0100
+Subject: Remove unnecessary zip_source_close
+
+This patch fixes CVE-2021-21772, a use-after-free bug. It is a
+backport of the upstream fix in v2.1.1.
+
+Forwarded: not-needed
+---
+ Include/Common/OPC/NMR_OpcPackageReader.h  |  1 -
+ Source/Common/OPC/NMR_OpcPackageReader.cpp | 16 ++--
+ 2 files changed, 6 insertions(+), 11 deletions(-)
+
+--- a/Include/Common/OPC/NMR_OpcPackageReader.h
 b/Include/Common/OPC/NMR_OpcPackageReader.h
+@@ -54,7 +54,6 @@ namespace NMR {
+   std::vector m_Buffer;
+   zip_error_t m_ZIPError;
+   zip_t * m_ZIParchive;
+-  zip_source_t * m_ZIPsource;
+   std::map  m_ZIPEntries;
+   std::map  m_Parts;
+ 
+diff --git a/Source/Common/OPC/NMR_OpcPackageReader.cpp 
b/Source/Common/OPC/NMR_OpcPackageReader.cpp
+index 16dd2e8c..4f3a604d 100644
+--- a/Source/Common/OPC/NMR_OpcPackageReader.cpp
 b/Source/Common/OPC/NMR_OpcPackageReader.cpp
+@@ -111,7 +111,7 @@ namespace NMR {
+   m_ZIPError.sys_err = 0;
+   m_ZIPError.zip_err = 0;
+   m_ZIParchive = nullptr;
+-  m_ZIPsource = nullptr;
++  zip_source_t* pZIPsource = nullptr;
+ 
+   try {
+   // determine stream size
+@@ -131,20 +131,20 @@ namespace NMR {
+ #endif
+   if (bUseCallback) {
+   // read ZIP from callback: faster and requires 
less memory
+-  m_ZIPsource = 
zip_source_function_create(custom_zip_source_callback, pImportStream.get(), 
_ZIPError);
++  pZIPsource = 
zip_source_function_create(custom_zip_source_callback, pImportStream.get(), 
_ZIPError);
+   }
+   else {
+   // read ZIP into memory
+   m_Buffer.resize((size_t)nStreamSize);
+   pImportStream->readBuffer(_Buffer[0], 
nStreamSize, true);
+-  m_ZIPsource = 

Bug#986307: [Debian-med-packaging] Bug#986307: marked as done (scrappie: flaky armhf autopkgtest: Invalid control character at: line 1 column 91 (char 90))

[Graham Inggs]

Control: reopen -1

The autopkgtest now fails with:

dpkg-architecture: warning: cannot determine CC system type, falling
back to default (native compilation)
Skip Test 3 on armhf (see bug #986307)
autopkgtest [08:53:06]: test run-unit-test: ---]
autopkgtest [08:53:06]: test run-unit-test:  - - - - - - - - - -
results - - - - - - - - - -
run-unit-testFAIL stderr: dpkg-architecture: warning: cannot
determine CC system type, falling back to default (native compilation)
autopkgtest [08:53:06]: test run-unit-test:  - - - - - - - - - -
stderr - - - - - - - - - -
dpkg-architecture: warning: cannot determine CC system type, falling
back to default (native compilation)
autopkgtest [08:53:06]:  summary
run-unit-testFAIL stderr: dpkg-architecture: warning: cannot
determine CC system type, falling back to default (native compilation)

Bug#986327: cmake-data: UseJava.cmake: documentation for add_jar(... OUTPUT_NAME x) is lying

[Dennis Filder]

Package: cmake-data
Version: 3.18.4-2
Severity: normal
Tags: patch

The documentation for the OUTPUT_NAME parameter does not state that
add_jar() will add the .jar extension, but makes it seem like the
caller should do it.

The patch clarifies that.


usejava.diff.gz
Description: application/gzip

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

[Marc Haber]

Control: tags -1 + confirmed upstream
Control: forward -1 https://bugzilla.sudo.ws/show_bug.cgi?id=971

On Sat, Apr 03, 2021 at 10:31:54AM +0200, Dennis Filder wrote:
> The attached patch improves the underdocumentation of
> counter-intuitive default behaviour a little which may have been the
> cause here.

committed and forwared upstream (bugzilla #971). Thanks!

Greetings
MArc



-- 
-
Marc Haber | "I don't trust Computers. They | Mailadresse im Header
Leimen, Germany|  lose things."Winona Ryder | Fon: *49 6224 1600402
Nordisch by Nature |  How to make an American Quilt | Fax: *49 6224 1600421

Bug#900819: gimp: Dependency on liblcms2-2 needs tightening

[Michael Deegan]

Package: gimp
Version: 2.10.22-3
Followup-For: Bug #900819

Hello, I can confirm that the issue still exists (being part way through
gradually upgrading my machine from buster to bullseye).

However, it's more confusing now! The message from Gimp:

Liblcms2 version mismatch!

GIMP was compiled against LittleCMS version 2.2, but the
LittleCMS version found at runtime is only 2.9.

Somehow you or your software packager managed
to install a LittleCMS that is older than what GIMP was
built against.

Please make sure that the installed LittleCMS version
is at least 2.2 and that headers and library match.

By my understanding, 2.9 *is* a version number later than 2.2. :P

My uneducated guess is that something plucked "2.2" from somewhere, where
there should have been a *checks apt-cache policy* "2.12".

-- System Information:
Debian Release: 10.9
  APT prefers testing-debug
  APT policy: (500, 'testing-debug'), (500, 'stable-updates'), (500, 
'stable-debug'), (500, 'proposed-updates-debug'), (500, 'oldstable-updates'), 
(500, 'stable'), (500, 'oldstable'), (480, 'testing'), (470, 'unstable'), (1, 
'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.10.0-5-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_AU.utf8, LC_CTYPE=en_AU.utf8 (charmap=UTF-8), LANGUAGE=en_AU:en 
(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.8-1
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.3.0-2+deb10u2
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 20.09.0-3.1
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.1
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:
ii  gimp-data-extras  1:2.0.2-1
ii  gimp-help-en [gimp-help]  2.8.2-1
ii  gvfs-backends 1.38.1-5
ii  libasound21.1.8-1

-- no debconf information

Bug#971953: linux-image-5.8: Intel Bay Trail PMIC, laptop screen backlight cannot be adjusted

[Salvatore Bonaccorso]

Source: linux
Source-Version: 5.10.19-1

Hi,

On Fri, Apr 02, 2021 at 08:20:47PM +0200, /dev/fra wrote:
> Dear Maintainer,
> 
> This problem has been fixed in linux-image-5.10.0-4 (source-version 
> 5.10.19-1), see bug report #982808[1].
> 
> This bug report can be closed.

Thanks for reporting back that it's fixed now. Closing the bugreport.

Salvatore

Bug#984670: g++-10: ICE in std::bind

[Matthias Klose]

Control: tags -1 + moreinfo

I'm unable to reproduce this with

$ g++ -c -O3 -g -msse2 -mfpmath=sse -ftree-slp-vectorize -std=gnu++17 
NasalWidget.ii

please could you recheck with gcc-10 and gcc-11 from experimental?  Please also
attach the preprocessed source generated with GCC 11.

Bug#943989: command-not-found: "Sorry, command-not-found has crashed!"

[Raphael Hertzog]

So the latest version doesn't have the same error message (with "cnf"
variable being unbound) but it still doesn't fail gracefully when
the database is not available.

Instead of asking to file bug reports, it should tell them to run "apt
update". This bad behaviour is now generating quite some noise in the
Debian bug tracker because we have enabled command-not-found in Kali
and when they get it installed during upgrade (as opposed to during a
fresh installation), the database is not created during the same apt
run and they get this error message when they run a missing command:

> $ lsio
> 
> Sorry, command-not-found has crashed! Please file a bug report at:
> http://www.debian.org/Bugs/Reporting
> Please include the following information with the report:
> 
> command-not-found version: 0.3
> Python version: 3.9.2 final 0
> Distributor ID: Kali
> Description:Kali GNU/Linux Rolling
> Release:2021.1
> Codename:   kali-rolling
> Exception information:
> 
> unable to open database file
> Traceback (most recent call last):
>   File "/usr/share/command-not-found/CommandNotFound/util.py", line 23, in 
> crash_guard
> callback()
>   File "/usr/lib/command-not-found", line 90, in main
> cnf = CommandNotFound.CommandNotFound(options.data_dir)
>   File "/usr/share/command-not-found/CommandNotFound/CommandNotFound.py", 
> line 79, in __init__
> self.db = SqliteDatabase(dbpath)
>   File "/usr/share/command-not-found/CommandNotFound/db/db.py", line 12, in 
> __init__
> self.con = sqlite3.connect(filename)
> sqlite3.OperationalError: unable to open database file

This is clearly counter-productive. 

I would either suggest to ignore the failure entirely and behave as if
command-not-found was not installed, or to print a better error message
driving users towards "apt update".

And maybe if it's run as root, then directly propose to run "apt update".

Cheers,
- 
Raphaël Hertzog

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

[Dennis Filder]

Control: tags -1 + patch

The attached patch improves the underdocumentation of
counter-intuitive default behaviour a little which may have been the
cause here.


sudo-success_return.patch.gz
Description: application/gzip

Bug#986325: corosync: crash with compression enabled

[Ferenc Wágner]

Package: corosync
Version: 3.1.0-3
Severity: normal
Tags: patch upstream
Forwarded: https://github.com/corosync/corosync/issues/630

As reported by Lukey3332:

Sometimes corosync crashes at startup, but only if compression is enabled.

Distribution: Debian Bullseye

Corosync version:

Corosync Cluster Engine, version '3.1.0'
Copyright (c) 2006-2018 Red Hat, Inc.

Kronosnet version:

Package: libknet1
Source: kronosnet
Version: 1.20-4

Here is a backtrace:

#0  __GI___pthread_mutex_lock (mutex=mutex@entry=0x58619958) at 
../nptl/pthread_mutex_lock.c:67
#1  0x77e6c728 in pmtud_reschedule (knet_h=0x55577320 
<_logsys_log_printf>, knet_h@entry=0x58619958) at threads_common.c:42
#2  get_global_wrlock (knet_h=knet_h@entry=0x55577320 <_logsys_log_printf>) 
at threads_common.c:61
#3  0x77e64316 in knet_handle_compress (knet_h=0x55577320 
<_logsys_log_printf>, knet_handle_compress_cfg=0x7fffcea0) at compress.c:503
#4  0x5559ae8f in totemknet_configure_compression 
(knet_context=knet_context@entry=0x5574d900, 
totem_config=totem_config@entry=0x7fffd310) at totemknet.c:1565
#5  0x5559c104 in totemknet_initialize (poll_handle=0x556ddd30, 
knet_context=0x5574d900, totem_config=0x7fffd310, stats=, context=0x556eed20,
deliver_fn=0x5558c810 , iface_change_fn=0x5558d9c0 
, mtu_changed=0x5558c290 , 
target_set_completed=0x5558ddd0 )
at totemknet.c:1149
#6  0x55588550 in totemnet_initialize 
(loop_pt=loop_pt@entry=0x556ddd30, 
net_context=net_context@entry=0x557026f8, 
totem_config=totem_config@entry=0x7fffd310, stats=0x55702728,
context=context@entry=0x556eed20, 
deliver_fn=deliver_fn@entry=0x5558c810 , 
iface_change_fn=0x5558d9c0 , 
mtu_changed=0x5558c290 ,
target_set_completed=0x5558ddd0 ) at 
totemnet.c:343
#7  0x5559541a in totemsrp_initialize 
(poll_handle=poll_handle@entry=0x556ddd30, 
srp_context=srp_context@entry=0x556760f0 , 
totem_config=totem_config@entry=0x7fffd310,
stats=stats@entry=0x556760c0 , 
deliver_fn=deliver_fn@entry=0x555970b0 , 
confchg_fn=confchg_fn@entry=0x555965a0 ,
waiting_trans_ack_cb_fn=0x55596560 ) at 
totemsrp.c:981
#8  0x55597c28 in totempg_initialize (poll_handle=0x556ddd30, 
totem_config=totem_config@entry=0x7fffd310) at totempg.c:824
#9  0xe0de in main (argc=-11504, argv=, 
envp=) at main.c:1526

corosync.conf:

# Please read the corosync.conf.5 manual page
totem {
version: 2

cluster_name: tele-clu

key: 
crypto_cipher: aes256
crypto_hash: sha256

knet_compression_model: zlib
knet_compression_level: 6

link_mode: passive

interface {
linknumber: 0
knet_link_priority: 1
}

interface {
linknumber: 1
knet_link_priority: 0
}
token: 5000
}

logging {
# Log the source file and line where messages are being
# generated. When in doubt, leave off. Potentially useful for
# debugging.
fileline: off
# Log to standard error. When in doubt, set to yes. Useful when
# running in the foreground (when invoking "corosync -f")
to_stderr: yes
# Log to a log file. When set to "no", the "logfile" option
# must not be set.
to_logfile: yes
logfile: /var/log/corosync/corosync.log
# Log to the system log daemon. When in doubt, set to yes.
to_syslog: yes
# Log debug messages (very verbose). When in doubt, leave off.
debug: off
# Log messages with time stamps. When in doubt, set to hires (or on)
#timestamp: hires
logger_subsys {
subsys: QUORUM
debug: off
}
}

quorum {
# Enable and configure quorum subsystem (default: off)
# see also corosync.conf.5 and votequorum.5
provider: corosync_votequorum
}

nodelist {

node {
# Hostname of the node
name: tele-clu-01
# Cluster membership node identifier
nodeid: 1

ring0_addr: 192.168.233.1
ring1_addr: 192.168.178.241
}
node {
# Hostname of the node
name: tele-clu-02
# Cluster membership node identifier
nodeid: 2

ring0_addr: 192.168.233.2
ring1_addr: 192.168.178.242
}
node {
# Hostname of the node
name: tele-clu-03
# Cluster membership node identifier
nodeid: 3

ring0_addr: 192.168.233.6
ring1_addr: 192.168.178.243
}
}

--
As commented by fabbione:

It turns out the issue is in corosync configuration handling when doing 

Bug#985652: [ftpmas...@ftp-master.debian.org: Accepted nettle 3.7.2-1 (source) into unstable]

[Salvatore Bonaccorso]

Source: nettle
Source-Version: 3.7.2-1

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Format: 1.8
Date: Fri, 02 Apr 2021 23:35:53 +0200
Source: nettle
Architecture: source
Version: 3.7.2-1
Distribution: unstable
Urgency: medium
Maintainer: Magnus Holmgren 
Changed-By: Magnus Holmgren 
Changes:
 nettle (3.7.2-1) unstable; urgency=medium
 .
   [ Andreas Metzler ]
   * New upstream version, fixing a bug in ECDSA signature verification that
 could lead to a denial of service attack (via an assertion failure) or
 possibly incorrect results.
 + Drop cherry-picked patches added in previous upload.
 + Update copyright file.
 .
   [ Magnus Holmgren ]
   * Update symbol files.
Checksums-Sha1:
 d0caa159f82f609ea8ba9f85187c6021ebdcb028 2274 nettle_3.7.2-1.dsc
 d617fbcf8d301dfd887129c3883629d4d097c579 2382309 nettle_3.7.2.orig.tar.gz
 d7d856ddd0d37c923f394e159fad0ece49834787 573 nettle_3.7.2.orig.tar.gz.asc
 77cdf14f7fccb5e247c1eb4efa17c5e93c2d 21764 nettle_3.7.2-1.debian.tar.xz
 817cdfe966d0c78bfb7b857845476b686a0d271b 6049 nettle_3.7.2-1_source.buildinfo
Checksums-Sha256:
 69e3abcf23476c7063d66db232858967bd15a77994bddb61db30e29614494398 2274 
nettle_3.7.2-1.dsc
 8d2a604ef1cde4cd5fb77e422531ea25ad064679ff0adf956e78b3352e0ef162 2382309 
nettle_3.7.2.orig.tar.gz
 6183e94ac98dbd68ed25af0c54b7d76ebf2f0c80b415f8fffc7bb416aafa6ff2 573 
nettle_3.7.2.orig.tar.gz.asc
 b3968db4e13549fa02a4301477eb373ca3528ace5803951bd2faff5ed8c4a2c2 21764 
nettle_3.7.2-1.debian.tar.xz
 990054eb317cbed3a6dfaaf1299e5c3b11db7eccd80e0abf05775e9a7b388d53 6049 
nettle_3.7.2-1_source.buildinfo
Files:
 83b289ec7bbc528c6af1c4e3d9440583 2274 libs optional nettle_3.7.2-1.dsc
 22849db27ed563ebbc829273f0c97e35 2382309 libs optional nettle_3.7.2.orig.tar.gz
 3ae3a0eb0fdbbe2ca7be0079511b49da 573 libs optional nettle_3.7.2.orig.tar.gz.asc
 b2cda73696a6da39bcd1000eecd55814 21764 libs optional 
nettle_3.7.2-1.debian.tar.xz
 bbea1585afccbc845d54f653bfa9f0a3 6049 libs optional 
nettle_3.7.2-1_source.buildinfo

-BEGIN PGP SIGNATURE-

iQIzBAEBCAAdFiEEzSoHOzhhVBcKQILo1PIZv+yZhIkFAmBnkvgACgkQ1PIZv+yZ
hIlY9w//bQoBs5WKYPrxb8Un9I88+n6DPoqPop262amAqDsntXva3tlaR9wIye2I
VBm/FuELX8XIpoo2DQlTMGjcMHrI9633wwUXWkUnBNz8qrQSltAJNn6g14drtFK7
QL8ro6hxfLaB/klt/zv9536O9SO5kLHvg/sypRnW9ryioEpVo/DVvUAfCet9yX1R
jL0jvn/cpX9w307vXjpRZhFALfphfokLoZG1xZVw+plyR6enLrfOwCwS47E2A+cq
yyTsZ8FCiNvC8pe+szv7/Bgs0U2l5JiLzNU53yTc5WLEV3eMio9jT2Ymoh0Zljmn
QMm+0AKgkDhnz0PwdIL60vwjZJsBAAhPVcEXvtoYcD+D2d+ot+EfLsuSJmbJ5Kfj
CWfGhMNV3ZS1yAIkBLsjxDpLP6x8u5e7d//7BnGmGBjVgl6fhI4B/py21KSarGJE
fvk++cU0DaFN6pdI9NeyHPkJcclmQiPRZ2t0R3RSLKmje592NzZEZ+SVdOyGgItN
FDCvvBaFlhppEN/9SY7WL383UwyOl1txwUhNb/tNzxIo6mzy9spvrKjTe22wYsx2
2svLcksTNjLyHu7yTDH8IOdkJIfjAczIN+yvkDitgCpfGiFVIPWumfTkZFdY3JjT
VrQzHMRuHNvgoeXlSnrp2Bj7ub5PP+xB2dLrrCVkozevxeFPupU=
=yq7g
-END PGP SIGNATURE-

Bug#982996: buster-pu: package awstats/7.6+dfsg-2

[Salvatore Bonaccorso]

Hi Håvard,

On Thu, Mar 25, 2021 at 06:32:40AM +, Håvard Flaget Aasen wrote:
> Hi Salvatore,
> 
> On Tue, 23 Mar 2021 13:35:48 +0100 Salvatore Bonaccorso
>  wrote:
> 
> > 
> > On Sat, Mar 13, 2021 at 05:16:24PM +, Adam D. Barratt wrote:
> > > Control: tags -1 + confirmed
> > > 
> > > On Wed, 2021-02-17 at 23:33 +0100, Håvard Flaget Aasen wrote:
> > > > These  are the same changes which was implemented in stretch, two
> > > > upstream patches. Both of these patches resolves a path traversal
> > > > flaw, which was first discovered with CVE-2017-1000501.
> > > > 
> > > 
> > > Please go ahead.
> > 
> > Was this uploaded? Can you still do it, but will be late for 10.9 now.
> > 
> 
> 
> Since I'm not a DD, I uploaded it to the mentors site. I haven't found
> any sponsor yet..

Thanks for the status update. Could you maybe ask your sponsor (for
the unstable upload) directly on the case for the buster-pu upload?

Many thanks for your work and taking care of fixing those issues!

Regards,
Salvatore

Bug#986324: soci: libsoci-dev needs Depends: on libboost1.74-dev

[Dennis Filder]

Package: soci
Version: 4.0.1-4
Severity: minor

With C++11 support libsoci-dev also needs either libboost1.71-dev or
libboost1.74-dev:

In file included from /usr/include/soci/statement.h:11,
 from /usr/include/soci/values.h:11,
 from /usr/include/soci/column-info.h:13,
 from /usr/include/soci/soci.h:16,
 from /<>/src/lime_localStorage.hpp:23,
 from /<>/src/lime_impl.hpp:31,
 from /<>/src/lime_x3dh.cpp:22:
/usr/include/soci/bind-values.h:14:17: fatal error: 
boost/fusion/algorithm/iteration/for_each.hpp: No such file or directory
   14 | #   include 
  | ^~~

Regards,
Dennis.

Bug#985726: benchmark: autopkgtest regression: test depends on removed g++-8

[Kentaro Hayashi]

FYI: The following MR was sent.

Fix to use default g++ compiler 
https://salsa.debian.org/science-team/benchmark/-/merge_requests/3

Bug#986321: reportbug: command-not-found has crashed!

[Paul Wise]

On Sat, 3 Apr 2021 02:23:26 -0400 Sandro Tosi wrote:

> please seek for help in a user support forum as listed at
> https://www.debian.org/support

Since ash is a Kali user, it is best if they ask Kali support:

https://www.kali.org/community/

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


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

Bug#986318: inform6-compiler: Actually, upon retesting, the benefits come from using -O2

[Nathanael Nerode]

Package: inform6-compiler
Version: 6.33-2+b1
Followup-For: Bug #986318
X-Debbugs-Cc: ncn_flos...@fastmail.fm

Dear Maintainer,

I retested and realized that most of the benefits come not from -flto, but 
simply from -O2 (or the nearly-equivalent -Og if you want better debugging 
information).

No optimization flags seem to be used per default during the construction of 
the currently installed package, much to my surprise.

So please amend this report: please compile with -O2 or -Og to cut running time 
for the inform6 program in half.

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

Kernel: Linux 5.10.0-4-rt-amd64 (SMP w/16 CPU threads; PREEMPT)
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 inform6-compiler depends on:
ii  libc6  2.31-9

Versions of packages inform6-compiler recommends:
ii  frotz [zcode-interpreter]  2.53+dfsg-1
ii  gargoyle-free [zcode-interpreter]  2019.1.1-2
ii  inform6-library6.12.2+dfsg.1-1.1
ii  sdlfrotz [zcode-interpreter]   2.53+dfsg-1

Versions of packages inform6-compiler suggests:
pn  inform-mode  
pn  inform6-doc  

-- no debconf information

Bug#986311: unblock: debian-cloud-images/0.0.4

[Paul Gevers]

Control: tags -1 moreinfo

Hi Noah,

On 02-04-2021 22:00, Noah Meyerhans wrote:
> Please unblock package debian-cloud-images

 172 files changed, 3798 insertions(+), 1365 deletions(-)

> Primarily I'm requesting this because this source package provides the
> debian-cloud-images-packages package that is a key package (see
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=929214) and updating the
> package in bullseye will update the Depends list to match what is actually
> required to build cloud images today.

Ack.

> This package contains a snapshot of the code and configuration used by the
> cloud team to generate the images for azure, aws, and openstack.  The cloud
> team does not build directly from the packages in the archive, but rather
> from the salsa repository.  So there is no risk of impact to the cloud
> images we generate if this package is updated.  Keeping the archive package
> closer to what's actually used by the cloud team is beneficial to any users
> who might be generating their own images based on our configuration.

So, I'm very uncomfortable with the union of this key packages tracking
package and the actual snapshot package. debian-cloud-images:all is a
new upstream release which doesn't follow our freeze policy at all, so I
think this should be a NACK. I'm also wondering, technically, do you
need the build dependencies of src:debian-cloud-images to be key too to
release the cloud images, or should is suffice to guarantee the Depends
of debian-cloud-images-packages to be in the next release? If I spot
correctly, of the three newly added Depends only fdisk is currently not
key yet, BD python3-yaml is also not a key package yet.

Should the current package in testing be released with bullseye if we
don't update it?

Paul



OpenPGP_signature
Description: OpenPGP digital signature