Bug#986746: systemd: Symbols are missing when building systemd by Clang

[Shawn Chang]

Package: systemd
Version: 241-7~deb10u7
Severity: serious
Tags: ftbfs
Justification: fails to build from source (but built successfully in the past)

Dear Maintainer,

Reproducible steps:

# cat /etc/dpkg/buildflags.conf 
APPEND CFLAGS -O -fPIE  
APPEND CXXFLAGS -O -fPIE 
APPEND LDFLAGS -pie -fuse-ld=lld

# Add below to debian/rules
export CC=clang
export CXX=clang++

3 test cases will failed, you can ignore them by:
  1) Edit debian/rules, comment a few lines:

ifeq (, $(filter nocheck, $(DEB_BUILD_OPTIONS)))
#   echo "01234567890123456789012345678901" > build-deb/machine-id
# some tests hang under fakeroot, so disable fakeroot
#   env -u LD_PRELOAD 
SYSTEMD_MACHINE_ID_PATH=$(CURDIR)/build-deb/machine-id meson test -C build-deb 
$(TEST_TIMEOUT_MULTIPLIER) || ( \
#
env -u LD_PRELOAD  meson test -C build-deb $(TEST_TIMEOUT_MULTIPLIER) 
|| ( \

  2) Drop two 
patches(0001-util-lib-static-array-argument-sizes-are-apparently-.patch and 
test-bus-track.patch) into debian/patches:

diff --git a/src/basic/string-util.c b/src/basic/string-util.c
index 7c487fb9a3..9586b3940e 100644
--- a/src/basic/string-util.c
+++ b/src/basic/string-util.c
@@ -725,10 +725,17 @@ char *strreplace(const char *text, const char 
*old_string, const char *new_strin
 return ret;
 }

-static void advance_offsets(ssize_t diff, size_t offsets[static 2], size_t 
shift[static 2], size_t size) {
+static void advance_offsets(
+ssize_t diff,
+size_t offsets[2], /* note: we can't use [static 2] here, 
since this may be NULL */
+size_t shift[static 2],
+size_t size) {
+
 if (!offsets)
 return;

+assert(shift);
+
 if ((size_t) diff < offsets[0])
 shift[0] += size;
 if ((size_t) diff < offsets[1])
@@ -844,8 +851,7 @@ char *strip_tab_ansi(char **ibuf, size_t *_isz, size_t 
highlight[2]) {

 fclose(f);

-free(*ibuf);
-*ibuf = obuf;
+free_and_replace(*ibuf, obuf);

 if (_isz)
 *_isz = osz;
@@ -855,7 +861,7 @@ char *strip_tab_ansi(char **ibuf, size_t *_isz, size_t 
highlight[2]) {
 highlight[1] += shift[1];
 }

-return obuf;
+return *ibuf;
 }

 char *strextend_with_separator(char **x, const char *separator, ...) {

diff --git a/src/libsystemd/sd-bus/test-bus-track.c 
b/src/libsystemd/sd-bus/test-bus-track.c
index 68a0010368..57af185d46 100644
--- a/src/libsystemd/sd-bus/test-bus-track.c
+++ b/src/libsystemd/sd-bus/test-bus-track.c
@@ -49,6 +49,7 @@ int main(int argc, char *argv[]) {
 const char *unique;
 int r;

+   return 0;
 test_setup_logging(LOG_INFO);

 r = sd_event_default(&event);

  3) Add those two patch files's name into debian/patches/series

Begin to build the package:
# dpkg-buildpackage -rfakeroot -us -uc



make[1]: Entering directory '/opt/debian10/build/tmp/systemd-241'
dh_missing --sourcedir debian/install/deb --fail-missing
make[1]: Leaving directory '/opt/debian10/build/tmp/systemd-241'
   dh_strip -O--buildsystem=meson
   debian/rules override_dh_makeshlibs
make[1]: Entering directory '/opt/debian10/build/tmp/systemd-241'
sed 's/SHARED_LIB_VERSION/241/' debian/shlibs.local.in > debian/shlibs.local
dh_makeshlibs -plibudev1 --add-udeb=libudev1-udeb -- -c4
dpkg-gensymbols: error: some symbols or patterns disappeared in the symbols 
file: see diff output below
dpkg-gensymbols: warning: debian/libudev1/DEBIAN/symbols doesn't match 
completely debian/libudev1.symbols
--- debian/libudev1.symbols (libudev1_241-7~deb10u7_amd64)
+++ dpkg-gensymbolshwl7L5   2021-04-11 14:15:58.815007345 +0800
@@ -1,10 +1,10 @@
 libudev.so.1 libudev1 #MINVER#
 * Build-Depends-Package: libudev-dev
- LIBUDEV_183@LIBUDEV_183 183
- LIBUDEV_189@LIBUDEV_189 189
- LIBUDEV_196@LIBUDEV_196 196
- LIBUDEV_199@LIBUDEV_199 199
- LIBUDEV_215@LIBUDEV_215 215
+#MISSING: 241-7~deb10u7# LIBUDEV_183@LIBUDEV_183 183
+#MISSING: 241-7~deb10u7# LIBUDEV_189@LIBUDEV_189 189
+#MISSING: 241-7~deb10u7# LIBUDEV_196@LIBUDEV_196 196
+#MISSING: 241-7~deb10u7# LIBUDEV_199@LIBUDEV_199 199
+#MISSING: 241-7~deb10u7# LIBUDEV_215@LIBUDEV_215 215
  udev_device_get_action@LIBUDEV_183 183
  udev_device_get_devlinks_list_entry@LIBUDEV_183 183
  udev_device_get_devnode@LIBUDEV_183 183
dh_makeshlibs: failing due to earlier errors
make[1]: *** [debian/rules:295: override_dh_makeshlibs] Error 1
make[1]: Leaving directory '/opt/debian10/build/tmp/systemd-241'
make: *** [debian/rules:311: binary] Error 2
dpkg-buildpackage: error: debian/rules binary subprocess returned exit status 2


-- Package-specific info:

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

Kernel: Linux 4.19.0-16-amd64 (SMP w/8 CPU cores)
Locale: LANG=en_H

Bug#986745: FTBFS on amd64

[Daniel Baumann]

Package: ruustc
Version: 1.50.0+dfsg1-1~exp2
Severity: serious
Tags: experimental

Hi,

while 1.50.0+dfsg1-1~exp1 build fine on amd64, the subsequent upload of
1.50.0+dfsg1-1~exp2 did not:

https://buildd.debian.org/status/fetch.php?pkg=rustc&arch=amd64&ver=1.50.0%2Bdfsg1-1%7Eexp2&stamp=1618053860&raw=0

Regards,
Daniel

Bug#568084: grub-common: Use of LABEL for 'root='

[Dario Susman]

Package: grub-common
Version: 2.04-17
Followup-For: Bug #568084

Dear Maintainer,

Might I ask this to be fixed, please?
It's much more easy to use labels than tinkering around with UUID, which
is both error-prone and, in some cases, when using mirrors of the same
disk, problematic. 

Thanks.

Best regards,

Dario Susman

-- Package-specific info:

*** BEGIN /proc/mounts
/dev/sda1 / ext4 rw,relatime,errors=remount-ro 0 0
/dev/sdb1 /mnt/WDBLUE1TB xfs 
rw,relatime,attr2,inode64,logbufs=8,logbsize=32k,noquota 0 0
*** END /proc/mounts

*** BEGIN /boot/grub/device.map
(hd0)   /dev/disk/by-id/ata-KINGSTON_SV300S37A120G_50026B7746012FCC
(hd1)   /dev/disk/by-id/ata-MAXTOR_STM3500320AS_9QM8W5FL
(hd2)   
/dev/disk/by-id/usb-Kingston_DataTraveler_2.0_001D0F0CAA76F951B59D0347-0:0
*** END /boot/grub/device.map

*** BEGIN /boot/grub/grub.cfg
#
# DO NOT EDIT THIS FILE
#
# It is automatically generated by grub-mkconfig using templates
# from /etc/grub.d and settings from /etc/default/grub
#

### BEGIN /etc/grub.d/00_header ###
if [ -s $prefix/grubenv ]; then
  set have_grubenv=true
  load_env
fi
if [ "${next_entry}" ] ; then
   set default="${next_entry}"
   set next_entry=
   save_env next_entry
   set boot_once=true
else
   set default="0"
fi

if [ x"${feature_menuentry_id}" = xy ]; then
  menuentry_id_option="--id"
else
  menuentry_id_option=""
fi

export menuentry_id_option

if [ "${prev_saved_entry}" ]; then
  set saved_entry="${prev_saved_entry}"
  save_env saved_entry
  set prev_saved_entry=
  save_env prev_saved_entry
  set boot_once=true
fi

function savedefault {
  if [ -z "${boot_once}" ]; then
saved_entry="${chosen}"
save_env saved_entry
  fi
}
function load_video {
  if [ x$feature_all_video_module = xy ]; then
insmod all_video
  else
insmod efi_gop
insmod efi_uga
insmod ieee1275_fb
insmod vbe
insmod vga
insmod video_bochs
insmod video_cirrus
  fi
}

terminal_input console
terminal_output console
if [ "${recordfail}" = 1 ] ; then
  set timeout=30
else
  if [ x$feature_timeout_style = xy ] ; then
set timeout_style=menu
set timeout=5
  # Fallback normal timeout code in case the timeout_style feature is
  # unavailable.
  else
set timeout=5
  fi
fi
### END /etc/grub.d/00_header ###

### BEGIN /etc/grub.d/05_debian_theme ###
set menu_color_normal=cyan/blue
set menu_color_highlight=white/blue
### END /etc/grub.d/05_debian_theme ###

### BEGIN /etc/grub.d/10_linux ###
function gfxmode {
set gfxpayload="${1}"
}
set linux_gfx_mode=
export linux_gfx_mode
menuentry 'Debian GNU/Linux' --class debian --class gnu-linux --class gnu 
--class os $menuentry_id_option 
'gnulinux-simple-16e84623-5d05-4f7b-b741-ad28bcc81a9f' {
load_video
insmod gzio
if [ x$grub_platform = xxen ]; then insmod xzio; insmod lzopio; fi
insmod part_msdos
insmod ext2
set root='hd0,msdos1'
if [ x$feature_platform_search_hint = xy ]; then
  search --no-floppy --fs-uuid --set=root --hint-bios=hd0,msdos1 
--hint-efi=hd0,msdos1 --hint-baremetal=ahci0,msdos1 --hint='hd0,msdos1'  
16e84623-5d05-4f7b-b741-ad28bcc81a9f
else
  search --no-floppy --fs-uuid --set=root 
16e84623-5d05-4f7b-b741-ad28bcc81a9f
fi
echo'Loading Linux 5.10.0-5-amd64 ...'
linux   /boot/vmlinuz-5.10.0-5-amd64 
root=UUID=16e84623-5d05-4f7b-b741-ad28bcc81a9f ro initrd=/install/initrd.gz 
text fbcon=scrollback:4096k net.ifnames=0 apparmor=0
echo'Loading initial ramdisk ...'
initrd  /boot/initrd.img-5.10.0-5-amd64
}
submenu 'Advanced options for Debian GNU/Linux' $menuentry_id_option 
'gnulinux-advanced-16e84623-5d05-4f7b-b741-ad28bcc81a9f' {
menuentry 'Debian GNU/Linux, with Linux 5.10.0-5-amd64' --class debian 
--class gnu-linux --class gnu --class os $menuentry_id_option 
'gnulinux-5.10.0-5-amd64-advanced-16e84623-5d05-4f7b-b741-ad28bcc81a9f' {
load_video
insmod gzio
if [ x$grub_platform = xxen ]; then insmod xzio; insmod lzopio; 
fi
insmod part_msdos
insmod ext2
set root='hd0,msdos1'
if [ x$feature_platform_search_hint = xy ]; then
  search --no-floppy --fs-uuid --set=root 
--hint-bios=hd0,msdos1 --hint-efi=hd0,msdos1 --hint-baremetal=ahci0,msdos1 
--hint='hd0,msdos1'  16e84623-5d05-4f7b-b741-ad28bcc81a9f
else
  search --no-floppy --fs-uuid --set=root 
16e84623-5d05-4f7b-b741-ad28bcc81a9f
fi
echo'Loading Linux 5.10.0-5-amd64 ...'
linux   /boot/vmlinuz-5.10.0-5-amd64 
root=UUID=16e84623-5d05-4f7b-b741-ad28bcc81a9f ro initrd=/install/initrd.gz 
text fbcon=scrollback:4096k net.ifnames=0 apparmor=0
echo'Loading initial ramdisk ...'
initrd  /boot/initrd.img-5.1

Bug#986744: email-reminder: Missing .desktop file

[Francois Marier]

Package: email-reminder
Version: 0.8.0-1
Severity: important

The .desktop file for email-reminder editor is missing and so it cannot be
easily be launched from a graphical desktop environment such as GNOME.

Francois

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

Kernel: Linux 5.10.0-5-amd64 (SMP w/4 CPU threads)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=fr_CA.utf8, LC_CTYPE=fr_CA.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 email-reminder depends on:
ii  adduser3.118
ii  cron   3.0pl1-137
ii  debconf [debconf-2.0]  1.5.76
ii  libdate-manip-perl 6.85-1
ii  libemail-valid-perl1.202-1
ii  libxml-dom-perl1.46-1
ii  perl   5.32.1-3
ii  python33.9.2-3
ii  python3-defusedxml 0.6.0-2
ii  python3-pyside2.qtcore 5.15.2-1
ii  python3-pyside2.qtgui  5.15.2-1
ii  python3-pyside2.qtwidgets  5.15.2-1

Versions of packages email-reminder recommends:
ii  anacron 2.3-30
ii  libauthen-sasl-perl 2.1600-1.1
ii  libemail-mime-encodings-perl1.315-2
ii  libnet-smtp-ssl-perl1.04-1
ii  postfix [mail-transport-agent]  3.5.6-1

email-reminder suggests no packages.

-- Configuration Files:
/etc/logcheck/ignore.d.server/email-reminder [Errno 13] Permission non 
accordée: '/etc/logcheck/ignore.d.server/email-reminder'

-- debconf information excluded

Bug#983726: runsv(8) incorrect regarding control/[dx]

[Lorenzo]

Control: tag -1 moreinfo
Control: tag -1 confirmed


On Sun, 28 Feb 2021 22:22:20 +0100
Andras Korn  wrote:

> Hi,
> 

Hello,

[Sorry, very late reply]
thanks for the report and the patch

> runsv(8) says:
> 
> CUSTOMIZE CONTROL
>For each control character c sent to the control pipe, runsv
> first checks if service/control/c exists and is executable. If so, it
>starts service/control/c and waits for it to terminate, before
>interpreting the command. If the program exits with return
> code 0, runsv refrains from sending the service the corresponding
> signal. The command o is always considered as command u. On command d
> first service/control/t is checked, and then service/control/d. On
> command x first service/control/t is checked, and then
> service/control/x. The control of the optional log service cannot be
> customized.
> 
> This is, however, not what the code actually does.
> 
> [ ... ]
> 
> i.e. the control/d or control/x script is only run after runsv sent
> its child a SIGTERM, not before as the manpage suggests.

Right. Also it looks that with control/[dx] an override on the CONT
signal is disregarded. It's reasonable but it should be documented too.

> 
> I would suggest that the code should be changed to reflect the
> documented behaviour, not vice versa.

Ideally Gerrit Pape should make a call on this, but it's not
happening, so:
Could you elaborate more on why you want to update the code instead of
fixing the manpage?

If you add an override for the TERM signal it would be run before [dx],
so what you want is a way to do a custom action that is not run when
the service receives a plain TERM signal but is run only when runsv is
told to set the service down or to exit.
Do you have an example/use case for this?

On the other hand, with the current code we have a custom action that
is run after runsv has sent both TERM and CONT, looks like a special
case of finish file (?), not sure what can be a reasonable use case here
too..


>  Perhaps the following code
> would work (but I have not tested it):
> 
> void stopservice(struct svdir *s) {
>   if (s->pid) {
> if (s->want == W_DOWN) {
>   kill(s->pid, SIGCONT);
>   if (custom(s, 'd')) return;
> }
> if (s->want == W_EXIT) {
>   kill(s->pid, SIGCONT);
>   if (custom(s, 'x')) return;
> }
> if (! custom(s, 't')) {
>   kill(s->pid, SIGTERM);
>   s->ctrl |=C_TERM;
>   update_status(s);
> }
>   }
> }
> 

I'm not an expert in runit code and I have just had a quick look at
runsv code, but unless I'm overlooking something it seems to me
that with your patch we will get CONT, then TERM while the man page
says TERM, then CONT. Also, it's changing the behavior even when there
is no signal override at all.

> Credits to https://serverfault.com/users/135556/keith for pointing
> the bug out.

I can only see some info about the reporter profile, do you have a link
where I can read what was the reporter complaining of?

> 
> Best regards,
> 
> András

Regards,
Lorenzo

Bug#986740: forked-daapd : please package new upstream release

[Sébastien Noel]

Package: src:forked-daapd
Severity: wishlist

Dear Maintainer,

forked-daapd has a new name & had a few releases
since the last time this package was updated.

https://github.com/ejurgensen/forked-daapd now redirect to
https://github.com/owntone/owntone-server and version 27.4 was
released less than a month ago

Thanks for taking care of this package.

Best regards,
Sébastien

Bug#986743: brltty: Please pass -static-libc to UDEB_LDFLAGS on ia64

[John Paul Adrian Glaubitz]

Source: brltty
Version: 6.3+dfsg-1
Severity: normal
Tags: patch
User: debian-i...@lists.debian.org
Usertags: ia64
X-Debbugs-Cc: debian-i...@lists.debian.org

Hello!

Adrian Bunk has had a go at the FTBFS of brltty on ia64 and he finally found a
solution which is passing -static-libgcc to UDEB_LDFLAGS on ia64:

--- a/brltty-6.3+dfsg/debian/rules  2021-01-28 16:18:34.0 +
+++ b/brltty-6.3+dfsg/debian/rules  2021-04-11 00:10:47.933611489 +
@@ -25,6 +25,9 @@
 DEB_CONFIGURE_OPTIONS = --with-curses=ncursesw --disable-stripping
 
 UDEB_CFLAGS=-Os -fomit-frame-pointer
+ifneq (,$(filter $(DEB_HOST_ARCH), ia64))
+UDEB_LDFLAGS=-static-libgcc
+endif
 UDEB_DISABLE=speech-support pcm-support midi-support fm-support \
contracted-braille api gpm iconv icu x polkit
 UDEB_CONFIGURE_OPTIONS=--with-braille-driver=-vr,all \
@@ -91,6 +94,7 @@
cd build-brltty-udeb && \
$(HARDENING) \
CFLAGS="$$(DEB_BUILD_MAINT_OPTIONS=hardening=+all 
dpkg-buildflags --get CFLAGS) $(UDEB_CFLAGS)" \
+   LDFLAGS="$$(DEB_BUILD_MAINT_OPTIONS=hardening=+all 
dpkg-buildflags --get LDFLAGS) $(UDEB_LDFLAGS)" \
../configure \
$(CONFIGURE_OPTIONS) \
$(UDEB_CONFIGURE_OPTIONS)

This fixes the FTBFS for me (verified on yttrium.debian.net) and should 
consequently
fix the FTBFS of debian-installer on ia64, too (once src:linux is fixed as well 
in
kernel version 5.12).

Thanks,
Adrian

--
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Bug#986739: is it possible to package new upstream "snapshot" ?

[Sébastien Noel]

Package: src:dolphin-emu
Severity: wishlist

Dear Maintainer,

The current dolphin-emu packages lacks almost 5 years of upstream 
improvements.

I know that technically there isn't any new upstream release,
but my feeling is that this is getting ridiculous.

The current package has lots of bugs regarding the usage of a real 
wiimote,

lots of games are unplayable, the GUI is antique
(upstream switched to QT5 3 years ago), etc...
Current documentation and user expectations are way out of line
with the state of the official debian package stuck at the 5.0 release.

If you agree with me that an update is welcome, I'm not coming empty 
handed,

I did my homework, I can share my current progress,
but I struggled on 2 points:
* some embedded libs (FreeSurround, minizip, ...) are more up2date
  in the tarball than the debian packaged version, so I used the bundled 
one

* updating the d/copyright file is a real pain
This is clearly not "release material" but it's a start:
https://twolife.be/debian/pool/main/d/dolphin-emu/

Thanks for reading up to this point.

Best Regards,
Sébastien

Bug#973059: logging-tree: FTBFS: dh_auto_test: error: pybuild --test -i python{version} -p "3.9 3.8" returned exit code 13

[Logan Rosen]

Control: tags -1 patch

Hi,

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

  * d/p/python-3.9.patch: Cherrypick upstream commit to fix FTBFS/test failure
with Python 3.9.

Thanks for considering the patch.

Logan
diff -Nru logging-tree-1.8.1/debian/patches/python-3.9.patch 
logging-tree-1.8.1/debian/patches/python-3.9.patch
--- logging-tree-1.8.1/debian/patches/python-3.9.patch  1969-12-31 
19:00:00.0 -0500
+++ logging-tree-1.8.1/debian/patches/python-3.9.patch  2021-04-10 
18:51:22.0 -0400
@@ -0,0 +1,57 @@
+From dfde23eca7288c1878d3b63a26f98e9764f5ba6c Mon Sep 17 00:00:00 2001
+From: Logan Rosen 
+Date: Sat, 10 Apr 2021 04:26:32 -0400
+Subject: [PATCH] Fix compatibility with Python 3.9 (#27)
+
+---
+ .travis.yml   | 1 +
+ logging_tree/tests/test_format.py | 4 ++--
+ setup.py  | 1 +
+ 3 files changed, 4 insertions(+), 2 deletions(-)
+
+diff --git a/.travis.yml b/.travis.yml
+index 1bc5bf5..bcff67e 100644
+--- a/.travis.yml
 b/.travis.yml
+@@ -11,6 +11,7 @@ python:
+   - "3.6"
+   - "3.7"
+   - "3.8"
++  - "3.9"
+ 
+ script:
+   - "python -m unittest logging_tree.tests.test_format 
logging_tree.tests.test_node"
+diff --git a/logging_tree/tests/test_format.py 
b/logging_tree/tests/test_format.py
+index c47..fec6c2d 100644
+--- a/logging_tree/tests/test_format.py
 b/logging_tree/tests/test_format.py
+@@ -13,7 +13,7 @@
+ 
+ 
+ class FakeFile(StringIO):
+-def __init__(self, filename, mode, encoding=None):
++def __init__(self, filename, *args, **kwargs):
+ self.filename = filename
+ StringIO.__init__(self)
+ 
+@@ -154,7 +154,7 @@ def test_2_dot_5_handlers(self):
+Level WARNING
+Handler TimedRotatingFile '/bar/two.txt' when='H' interval=3600 
backupCount=0
+ '''
+-if sys.version_info >= (3, 8):
++if sys.version_info == (3, 8):
+ # Apparently the design of the TimedRotatingFileHandler has
+ # become a bit more ambitious as of Python 3.8.
+ expected += '''\
+diff --git a/setup.py b/setup.py
+index 65da834..15cb6b1 100644
+--- a/setup.py
 b/setup.py
+@@ -24,6 +24,7 @@
+ 'Programming Language :: Python :: 3.6',
+ 'Programming Language :: Python :: 3.7',
+ 'Programming Language :: Python :: 3.8',
++'Programming Language :: Python :: 3.9',
+ 'Topic :: System :: Logging',
+ ],
+   packages=['logging_tree', 'logging_tree.tests'],
diff -Nru logging-tree-1.8.1/debian/patches/series 
logging-tree-1.8.1/debian/patches/series
--- logging-tree-1.8.1/debian/patches/series1969-12-31 19:00:00.0 
-0500
+++ logging-tree-1.8.1/debian/patches/series2021-04-10 18:51:22.0 
-0400
@@ -0,0 +1 @@
+python-3.9.patch

Bug#986741: Please enable CONFIG_IP_PNP_DHCP=y in cloud image

[Josh Triplett]

On Sat, Apr 10, 2021 at 11:23:53PM +0200, Bastian Blank wrote:
> On Sat, Apr 10, 2021 at 02:11:06PM -0700, Josh Triplett wrote:
> > For cloud instances and VMs, it's helpful to be able to use ip=dhcp as a
> > minimal network configuration. Enabling this option will do nothing
> > unless the kernel command line includes ip=dhcp.
> 
> We don't support initramfs-less boot.

Whether you have an initramfs or not is orthogonal to DHCP
configuration. The kernel's built-in DHCP configuration works even if
you're not using a network filesystem as the root filesystem.

Bug#986741: Please enable CONFIG_IP_PNP_DHCP=y in cloud image

[Bastian Blank]

Control: tag -1 wontfix

Hi

On Sat, Apr 10, 2021 at 02:11:06PM -0700, Josh Triplett wrote:
> For cloud instances and VMs, it's helpful to be able to use ip=dhcp as a
> minimal network configuration. Enabling this option will do nothing
> unless the kernel command line includes ip=dhcp.

We don't support initramfs-less boot.  So network configuration is done
by the initramfs.

Bastian

-- 
The best diplomat I know is a fully activated phaser bank.
-- Scotty

Bug#961337: Bug#986737: RFS: deno/1.8.3-1 [ITP] -- A secure JavaScript and TypeScript runtime

[Jérémy Lal]

(please don't top-post)
(cc-ing to relevant bugs and teams)


Le sam. 10 avr. 2021 à 22:26, Sergey Abroskin  a écrit :

> On Sat, Apr 10, 2021, 23:18 Jérémy Lal  wrote:
>
>>
>>
>> Le sam. 10 avr. 2021 à 21:42, Geert Stappers  a
>> écrit :
>>
>>> On Sat, Apr 10, 2021 at 09:17:12PM +0300, Sergey Abroskin wrote:
>>> > Dear mentors,
>>> >
>>> > I am looking for a sponsor for my package "deno":
>>> >
>>> >  * Package name: deno
>>> >Version : 1.8.3-1
>>> >Upstream Author : The Deno Authors
>>> >  * URL : https://deno.land
>>> >
>>> >
>>> >   https://mentors.debian.net/package/deno/
>>> >
>>> >   dget -x
>>> https://mentors.debian.net/debian/pool/main/d/deno/deno_1.8.3-1.dsc
>>> >
>>> >* Initial release (Closes: 961337)
>>> >
>>>
>>> 
>>> stappers@paddy:/usr/src/debian/deno
>>> $ grep ^name Cargo.lock  | head
>>> name = "Inflector"
>>> name = "adler"
>>> name = "ahash"
>>> name = "ahash"
>>> name = "aho-corasick"
>>> name = "alloc-no-stdlib"
>>> name = "alloc-stdlib"
>>> name = "ansi_term"
>>> name = "anyhow"
>>> name = "anymap"
>>> stappers@paddy:/usr/src/debian/deno
>>> $ grep --after=1 ^Build-Depends debian/control
>>> Build-Depends: debhelper (>= 11), rustc, cargo
>>> Standards-Version: 4.1.3
>>> stappers@paddy:/usr/src/debian/deno
>>> $
>>> 
>>>
>>> What cargo needs doesn't match the Build-Depends.
>>> If uploaded, it would fail to build due missing build dependencies.
>>>
>>>
>>> Yes, consider packaging deno for Debian (and it's derivatives)
>>>
 a very interresting challenge.
>>>
>> > Deno has ~400 dependencies. What should I do?

For all that concerns building:
https://wiki.debian.org/Teams/RustPackaging

For all that concerns userland:
https://wiki.debian.org/Javascript
In particular this is very interesting to read (because it explains what
could be bundled or not):
https://wiki.debian.org/Javascript/GroupSourcesTutorial

Debian toolchains have been upgraded (mainly by DD yadd) to cope with
bundled dependencies,
A.K.A. components. Uscan now supports this.

In my experience a huge project like Deno is going to drag sub-projects,
make them live,
and also make mistakes and depend on abandonware.
This isn't going to be a piece of cake. The more Deno and its deps are
stable, the more it's going to be easy to package.

Jérémy

Bug#986741: Please enable CONFIG_IP_PNP_DHCP=y in cloud image

[Josh Triplett]

Package: linux-image-cloud-amd64
Severity: wishlist
X-Debbugs-Cc: j...@joshtriplett.org

For cloud instances and VMs, it's helpful to be able to use ip=dhcp as a
minimal network configuration. Enabling this option will do nothing
unless the kernel command line includes ip=dhcp.


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

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

Versions of packages linux-image-cloud-amd64 depends on:
pn  linux-image-5.10.0-5-cloud-amd64  

linux-image-cloud-amd64 recommends no packages.

linux-image-cloud-amd64 suggests no packages.

Bug#984614: snort in Bullseye

[Javier Fernandez-Sanguino]

On Fri, 9 Apr 2021 at 20:10, Chris Hofstaedtler  wrote:

> Control: found -1 2.9.15.1-2
>
> Hi,
>
> it appears this conffile handling problem is caused by a not good
> enough attempt to move the old conffile /etc/cron.daily/5snort to
> /etc/cron.daily/snort-common.
>

You are correct.


> It would appear trivial to change this to use
> dpkg-maintscript-helper mv_conffile instead.
>

Thank you for suggesting this, I was not aware of this. I have fixed the
issue by using dpkg-maintscript-helper properly in the
preinst/postinst/postrm.


> Someone with enough interest in snort should probably just make this
> change and upload it.
>

After preparing a new version of the package and testing it in a chroot
with different upgrade scenarios, I have uploaded a new version to unstable
fixing this issue (and some  others I encountered along the way).

Best regards


Javier

Bug#961337: Bug#986737: RFS: deno/1.8.3-1 [ITP] -- A secure JavaScript and TypeScript runtime

[Jérémy Lal]

Le sam. 10 avr. 2021 à 21:42, Geert Stappers  a écrit :

> On Sat, Apr 10, 2021 at 09:17:12PM +0300, Sergey Abroskin wrote:
> > Dear mentors,
> >
> > I am looking for a sponsor for my package "deno":
> >
> >  * Package name: deno
> >Version : 1.8.3-1
> >Upstream Author : The Deno Authors
> >  * URL : https://deno.land
> >
> >
> >   https://mentors.debian.net/package/deno/
> >
> >   dget -x
> https://mentors.debian.net/debian/pool/main/d/deno/deno_1.8.3-1.dsc
> >
> >* Initial release (Closes: 961337)
> >
>
> 
> stappers@paddy:/usr/src/debian/deno
> $ grep ^name Cargo.lock  | head
> name = "Inflector"
> name = "adler"
> name = "ahash"
> name = "ahash"
> name = "aho-corasick"
> name = "alloc-no-stdlib"
> name = "alloc-stdlib"
> name = "ansi_term"
> name = "anyhow"
> name = "anymap"
> stappers@paddy:/usr/src/debian/deno
> $ grep --after=1 ^Build-Depends debian/control
> Build-Depends: debhelper (>= 11), rustc, cargo
> Standards-Version: 4.1.3
> stappers@paddy:/usr/src/debian/deno
> $
> 
>
> What cargo needs doesn't match the Build-Depends.
> If uploaded, it would fail to build due missing build dependencies.
>
>
> Yes, consider packaging deno for Debian (and it's derivatives)
> a very interresting challenge.
>

Hi !

Deno is Javascript/Typescript !
Please cc and involve pkg-javascript team.

Issues are 3-fold:
- packaging cargo (rust's package manager) dependencies
- how Deno userland modules (written in typescript/javascript) are going to
be distributed
  (probably in a way comparable to how node or javascript modules are
distributed)
- https://github.com/denoland/rusty_v8
  how to make Node and Deno share the same v8. (This is where i might be
able to help).

Jérémy

Bug#969907: Bug#969537: epdfinfo crashing with mismatched libpoppler102 and libpoppler-glib8

[Ivo De Decker]

Hi,

On Thu, Feb 18, 2021 at 03:33:23PM +, Simon McVittie wrote:
> > I'd rather think that the situation happened because
> > elpa-pdf-tools-server links both to libpoppler and libpoppler-glib:
> > the rebuild against poppler 20.09.0 (i.e. libpoppler102) make
> > elpa-pdf-tools-server link to libpoppler102 (forcing the newer
> > dependency to it), and setting an old dependency for libpoppler-glib
> > because there is no need for a newer version.
> 
> So elpa-pdf-tools-server is linked to libpoppler-glib, and because the
> (parts of the) libpoppler-glib API that it uses has not changed for a
> while, it is happy with an old version; but then during a partial
> upgrade, it can get this
> 
> elpa-pdf-tools-server
> \- old libpoppler-glib
> |   \- libpoppler95
> \- libpoppler102
> 
> and the two copies of libpoppler fight?
> 
> That seems entirely plausible, and I don't immediately see a way to
> fix it without adding Breaks (which would force a lockstep upgrade,
> somewhat defeating the purpose of SONAMEs).
> 
> GNOME had similar issues during the libffi transition, where gjs' direct
> use of libffi conflicted with its indirect use via GLib, and I think we
> ended up adding Breaks to force the broken combinations not to happen.

There are 2 other packages in bullseye that depend on both libpoppler and
libpoppler-glib: gambas3-gb-poppler and inkscape.

This issue is also present in inkscape (I didn't try to reproduce it with
gambas3-gb-poppler, but I guess the situation is similar):

Install inkscape on a buster system. The pdf David attached can be opened
without issue. Upgrade only inkscape to bullseye (letting apt pull in the
dependencies, which include libpoppler102 but not the newer libpoppler-glib8).
When opening the pdf inkscape closes with an error, and the kernel reports:
inkscape[9032]: segfault at 9 ip 7fad9e3e1d3e sp 7fff5127ae30 error 4 
in libpoppler-glib.so.8.10.0[7fad9e3c4000+27000]

Installing the new libpoppler-glib8 fixes the issue.

A way to fix this, is to add a dependency to the newer libpoppler-glib8 as
well (as was done for elpa-pdf-tools-server). Obviously, it would be nice to
have an elegant way to handle this automatically at build time to make sure
the dependencies are correct, without having to add them manually.

Cheers,

Ivo

Bug#986563: [Pkg-nagios-devel] Bug#986563: monitoring-plugins-contrib: check_ssl_cert Renegotiation test broken with STARTTLS

[Jan Wagner]

Package: nagios-plugins-contrib
Version: 34.20210407+1

Hi Slavko,

Am 07.04.21 um 14:52 schrieb Slavko:

The currently shipped check_ssl_cert has broken Renegotiation test, which
uses plain ports with STARTTLS certificate checks. It was fixed by upstream,
see https://github.com/matteocorti/check_ssl_cert/issues/272 in the 2.0.1
version.


thanks for bringing this to our attention. It was fixed with upload 
34.20210407+1.


Cheers, Jan.

Bug#961337: Bug#986737: RFS: deno/1.8.3-1 [ITP] -- A secure JavaScript and TypeScript runtime

[Geert Stappers]

On Sat, Apr 10, 2021 at 09:17:12PM +0300, Sergey Abroskin wrote:
> Dear mentors,
> 
> I am looking for a sponsor for my package "deno":
> 
>  * Package name: deno
>Version : 1.8.3-1
>Upstream Author : The Deno Authors
>  * URL : https://deno.land
> 
> 
>   https://mentors.debian.net/package/deno/
> 
>   dget -x https://mentors.debian.net/debian/pool/main/d/deno/deno_1.8.3-1.dsc
> 
>* Initial release (Closes: 961337)
> 


stappers@paddy:/usr/src/debian/deno
$ grep ^name Cargo.lock  | head
name = "Inflector"
name = "adler"
name = "ahash"
name = "ahash"
name = "aho-corasick"
name = "alloc-no-stdlib"
name = "alloc-stdlib"
name = "ansi_term"
name = "anyhow"
name = "anymap"
stappers@paddy:/usr/src/debian/deno
$ grep --after=1 ^Build-Depends debian/control 
Build-Depends: debhelper (>= 11), rustc, cargo
Standards-Version: 4.1.3
stappers@paddy:/usr/src/debian/deno
$ 


What cargo needs doesn't match the Build-Depends.
If uploaded, it would fail to build due missing build dependencies.


Yes, consider packaging deno for Debian (and it's derivatives)
a very interresting challenge.


Regards
Geert Stappers
-- 
If it was easy, everybody would do it.

Bug#986738: libstarlink-ast-doc: Fails to build reproducibly: Embeds date in the docs

[Vagrant Cascadian]

user reproducible-bui...@lists.alioth.debian.org
usertags 986738 + timestamps
usertags 986738 - usrmerge
tags 986738 + patch
thanks

On 2021-04-10, Nilesh Patra wrote:
> Tags: timestamps
...
> Usertags: usrmerge

Adjusted tags (+patch) and usertags (-usrmerge, +timestamps)...

> starlink-ast fails to build reproducibly because it embeds current date
> in the documentation and ast.h
>
> The patchs for the same is commited into salsa here[1][2]
>
> This should be ready for upload after bullseye release. I am reporting bug so 
> that
> this change is not lost somehow.
>
> [1]: 
> https://salsa.debian.org/debian-astro-team/starlink-ast/-/commit/3856f00f5b595163d4b04389288fffde42316e90
> [2]: 
> https://salsa.debian.org/debian-astro-team/starlink-ast/-/commit/8e50d3ea7244702baac12aa587f71cd653ae4fdf

live well,
  vagrant


signature.asc
Description: PGP signature

Bug#986738: libstarlink-ast-doc: Fails to build reproducibly: Embeds date in the docs

[Nilesh Patra]

Package: libstarlink-ast-doc
Version: 9.2.3+dfsg-1
Severity: normal
Tags: timestamps
User: reproducible-bui...@lists.alioth.debian.org
Usertags: usrmerge
X-Debbugs-Cc: nil...@debian.org, nil...@debian.org, 
reproducible-b...@lists.alioth.debian.org

Dear Maintainer,

starlink-ast fails to build reproducibly because it embeds current date
in the documentation and ast.h

The patchs for the same is commited into salsa here[1][2]

This should be ready for upload after bullseye release. I am reporting bug so 
that
this change is not lost somehow.

[1]: 
https://salsa.debian.org/debian-astro-team/starlink-ast/-/commit/3856f00f5b595163d4b04389288fffde42316e90
[2]: 
https://salsa.debian.org/debian-astro-team/starlink-ast/-/commit/8e50d3ea7244702baac12aa587f71cd653ae4fdf

Nilesh

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

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

-- no debconf information

Bug#986737: RFS: deno/1.8.3-1 [ITP] -- A secure JavaScript and TypeScript runtime

[Sergey Abroskin]

Package: sponsorship-requests
Severity: wishlist

Dear mentors,

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

 * Package name: deno
   Version : 1.8.3-1
   Upstream Author : The Deno Authors
 * URL : https://deno.land
 * License : MIT
   Section : devel

It builds those binary packages:

  deno - A secure JavaScript and TypeScript runtime

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

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

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

  dget -x
https://mentors.debian.net/debian/pool/main/d/deno/deno_1.8.3-1.dsc

Changes for the initial release:

 deno (1.8.3-1) unstable; urgency=medium
 .
   * Initial release (Closes: 961337)

Regards,
-- 
  Sergey Abroskin

Bug#986511: python-jenkinsapi: FTBFS: Unable to create file /sbuild-nonexistent/.pylint.d/jenkinsapi.views1.stats: [Errno 2] No such file or directory: '/sbuild-nonexistent/.pylint.d/jenkinsapi.views1

[Logan Rosen]

Control: tags -1 patch

Hi,

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

  * d/p/pylint-fixes.patch: Update to incorporate fix for new use-a-generator
failures.

Thanks for considering the patch.

Logan
diff -Nru python-jenkinsapi-0.3.11/debian/patches/pylint-fixes.patch 
python-jenkinsapi-0.3.11/debian/patches/pylint-fixes.patch
--- python-jenkinsapi-0.3.11/debian/patches/pylint-fixes.patch  2020-10-27 
23:19:59.0 -0400
+++ python-jenkinsapi-0.3.11/debian/patches/pylint-fixes.patch  2021-04-10 
13:53:15.0 -0400
@@ -1,6 +1,5 @@
-diff -Naur a/jenkinsapi/credential.py b/jenkinsapi/credential.py
 a/jenkinsapi/credential.py 2020-02-16 16:46:46.767307926 -0700
-+++ b/jenkinsapi/credential.py 2020-10-27 21:03:49.025512695 -0600
+--- a/jenkinsapi/credential.py
 b/jenkinsapi/credential.py
 @@ -83,7 +83,7 @@
  
  def __init__(self, cred_dict):
@@ -70,9 +69,8 @@
  }
 -return super(AmazonWebServicesCredentials, 
self)._get_attributes_xml(data)
 +return super()._get_attributes_xml(data)
-diff -Naur a/jenkinsapi/credentials.py b/jenkinsapi/credentials.py
 a/jenkinsapi/credentials.py2020-02-16 16:46:46.767307926 -0700
-+++ b/jenkinsapi/credentials.py2020-10-27 21:04:33.021889279 -0600
+--- a/jenkinsapi/credentials.py
 b/jenkinsapi/credentials.py
 @@ -100,8 +100,8 @@
  except JenkinsAPIException as jae:
  raise JenkinsAPIException('Latest version of Credentials '
@@ -104,9 +102,8 @@
  self.poll()
  self.credentials = self._data['credentials']
  if description in self:
-diff -Naur a/jenkinsapi/fingerprint.py b/jenkinsapi/fingerprint.py
 a/jenkinsapi/fingerprint.py2020-02-16 16:46:46.767307926 -0700
-+++ b/jenkinsapi/fingerprint.py2020-10-27 20:59:57.595597808 -0600
+--- a/jenkinsapi/fingerprint.py
 b/jenkinsapi/fingerprint.py
 @@ -96,14 +96,14 @@
  def validate(self):
  try:
@@ -126,9 +123,8 @@
  return True
  
  def get_info(self):
-diff -Naur a/jenkinsapi/jenkinsbase.py b/jenkinsapi/jenkinsbase.py
 a/jenkinsapi/jenkinsbase.py2020-02-16 16:46:46.767307926 -0700
-+++ b/jenkinsapi/jenkinsbase.py2020-10-27 20:58:54.431099252 -0600
+--- a/jenkinsapi/jenkinsbase.py
 b/jenkinsapi/jenkinsbase.py
 @@ -84,9 +84,9 @@
  response.raise_for_status()
  try:
@@ -141,9 +137,8 @@
  
  def pprint(self):
  """
-diff -Naur a/jenkinsapi/job.py b/jenkinsapi/job.py
 a/jenkinsapi/job.py2020-02-16 16:46:46.775307980 -0700
-+++ b/jenkinsapi/job.py2020-10-27 20:58:21.502844386 -0600
+--- a/jenkinsapi/job.py
 b/jenkinsapi/job.py
 @@ -89,7 +89,7 @@
  return branches
  
@@ -196,9 +191,8 @@
  
  def __delitem__(self, build_number):
  self.delete_build(build_number)
-diff -Naur a/jenkinsapi/node.py b/jenkinsapi/node.py
 a/jenkinsapi/node.py   2020-02-16 16:46:46.775307980 -0700
-+++ b/jenkinsapi/node.py   2020-10-27 20:54:01.232984206 -0600
+--- a/jenkinsapi/node.py
 b/jenkinsapi/node.py
 @@ -118,10 +118,10 @@
  credential = self.jenkins.credentials[
  na['credential_description']
@@ -212,9 +206,8 @@
  
  retries = na['max_num_retries'] if 'max_num_retries' in na else ''
  re_wait = na['retry_wait_time'] if 'retry_wait_time' in na else ''
-diff -Naur a/jenkinsapi/nodes.py b/jenkinsapi/nodes.py
 a/jenkinsapi/nodes.py  2020-02-16 16:46:46.775307980 -0700
-+++ b/jenkinsapi/nodes.py  2020-10-27 20:50:45.423835163 -0600
+--- a/jenkinsapi/nodes.py
 b/jenkinsapi/nodes.py
 @@ -75,8 +75,8 @@
  nodename = item['displayName']
  try:
@@ -237,9 +230,8 @@
  
  def values(self):
  """
-diff -Naur a/jenkinsapi/plugins.py b/jenkinsapi/plugins.py
 a/jenkinsapi/plugins.py2020-02-16 16:46:46.775307980 -0700
-+++ b/jenkinsapi/plugins.py2020-10-27 20:49:44.063536416 -0600
+--- a/jenkinsapi/plugins.py
 b/jenkinsapi/plugins.py
 @@ -82,8 +82,8 @@
  def __getitem__(self, plugin_name):
  try:
@@ -251,9 +243,30 @@
  
  def __setitem__(self, shortName, plugin):
  """
-diff -Naur a/jenkinsapi/queue.py b/jenkinsapi/queue.py
 a/jenkinsapi/queue.py  2020-02-16 16:46:46.775307980 -0700
-+++ b/jenkinsapi/queue.py  2020-10-27 20:48:12.011156888 -0600
+@@ -138,7 +138,7 @@
+ jobs = self.update_center_install_status['data']['jobs']
+ except JenkinsAPIException:
+ return True  # Jenkins 1.X has no update_center
+-return any([job for job in jobs if job['requiresRestart'] == 'true'])
++return any(job for job in jobs if job['requiresRestart'] == 'true')
+ 
+ def _install_specific_version(self, plugin):
+ """
+@@ -208,9 +208,9 @@
+ jobs = self.update_center_install_status['data']['jobs']
+ except JenkinsAPIException:
+ return Fal

Bug#986736: RFP: xmake -- A cross-platform build utility based on Lua

[Christof Meerwald]

Package: wnpp
Severity: wishlist

xmake is a lightweight cross-platform build utility based on Lua. It
uses xmake.lua to maintain project builds. Compared with
makefile/CMakeLists.txt, the configuration syntax is more concise and
intuitive. It is very friendly to novices and can quickly get started
in a short time. Let users focus more on actual project development.

It can compile the project directly like Make/Ninja, or generate
project files like CMake/Meson, and it also has a built-in package
management system to help users solve the integrated use of C/C++
dependent libraries.

URL: https://github.com/xmake-io/xmake/
License: Apache License 2.0

Bug#977358: release-notes: document how to make the rescue mode usable if no root password is set (buster)

[Justin B Rye]

Andrei POPESCU wrote:
>> (Should there be some hint here at the fact that this has happened
>> because we've switched to an implementation of sulogin without the
>> slightly dodgy Debian-specific patches?)
> 
> This is explained in the bug report for who cares to investigate, in my 
> opinion it's not needed in the Release Notes.

This was mostly a note to myself in the hope that I'd find a way of
leading into it that accentuated the positive - after all, this is
just a side-effect of improvements elsewhere.  But when we're this
late documenting it, it's a non-starter.

[...]
>> This probably needs an external link, but I'm not optimistic we'll
>> find one.  Maybe this is another case where we'll need a dedicated
>> page on wiki.debian.org.
> 
> As you probably know, it's as simple as:
> 
> systemctl edit rescue.service
> 
> and add
> 
> [Service]
> Environment=SYSTEMD_SULOGIN_FORCE=1
> 

Well, I know that now, because I've been looking it up, but I wasn't
sure as I wrote that, and it's not as easy to pull the details
together as it should be.  Still, at least it doesn't need the usual
reminders to run daemon-reload or reboot.  But instead of telling
people all about where to hunt for the information it might be quicker
in this case just to put the answer in the text!

   
 The rescue boot option is unusable without a root 
password
   
   
 Booting with the rescue option always requires
 the root password. If one has not been set, this makes the rescue
 mode effectively unusable. However it is still possible to boot
 using the kernel parameter init=/sbin/sulogin --force
   
   
 To configure systemd to do the equivalent of this whenever it boots
 into rescue mode (also known as single mode: see systemd(1)),
 run sudo systemctl edit rescue.service and create
 a file saying just:
   
   
 [Service]
 Environment=SYSTEMD_SULOGIN_FORCE=1
   
   
 It might also (or instead) be useful to do this for the
 emergency.service unit, which is started
 automatically in the case of certain
 errors (see systemd.special(7)),
 or if emergency is added to the kernel
 command line (e.g. if the system can't be recovered by using
 the rescue mode).
   

[...]
>> (Why *did* setting these systems up with passwords in the first place
>> go out of fashion?)
> 
> For me it was a natural consequence of using sudo exclusively ;)

Ah, well, it's the old slogan - "Debian: giving you the power to shoot
yourself in each toe individually."

>>> For background and a discussion on the security implications see 
>>> bts:802211.
>> 
>> I forget if we've got special markup for this or whether we just say
> 
> All entities are in a dedicated file (I don't have a checkout handy to 
> look it up).

I can't see the definition, but judging by old .po files we want


  For background and a discussion on the security implications see
  #802211.


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

Bug#986619: linux-image-5.10.0-5-amd64: bonding broken on 5.10.0-5 (5.10.26)

[Francesc Ferrer]

I can confirm this behaviour. I also have wired and wireless bonded, and 
it stopped working on 5.10.0-5. Everything looks fine: bond, gateway, 
DNS, ... all have correct if addresses obtained from dhcp; resolvectl 
looks fine; but I cannot even ping my gateway/router.


--
Francesc

Bug#986651: systemd: stop depending on systemd-timesyncd

[Michael Biebl]

Am 10.04.2021 um 17:11 schrieb Helmut Grohne:

On Sat, Apr 10, 2021 at 12:17:24PM +0200, Michael Biebl wrote:



If we bump the prio of systemd-timesyncd, those minimal containers will now
suddenly get systemd-timesyncd by default (which in turn pulls systemd). So
this would be a regression. You'd have to be careful to omit
systemd-timesyncd when building the container image.


I don't think minimal containers install Priority: important packages,
not even Priority: required ones.  At least that's not how I approach
it. I usually start with just Essential: yes and add what is needed.
Possibly though, this workflow is not the one other people use. How do
we find out? 


Good question.

For instance, e2fsprogs is not Essential: yes, but

Priority: required precisely for the container use case.

In any case, there is no regression as systemd presently is Priority:
important and systemd depends on systemd-timesyncd. If they'd install
systemd-timesyncd due to Priority: important, they'd do it today
already.


That's a valid remark, thanks.

My main objective is, that I want to have an NTP client installed in all 
but unusual/special installations.
Demoting the dependency to Recommends would not work afaiu as systemd is 
installed during the initial debootstrap phase where, I was told, 
Recommends are not considered. That's the motivation for the Depends.



If we can achieve the same with Recommends + Prio: important, then I'm 
ok with this change.




OpenPGP_signature
Description: OpenPGP digital signature

Bug#956192: Any progress or missing information?

[Helge Kreutzmann]

Dear webmasters,
one year ago I requested that manpages-l10n should be removed from
https://www.debian.org/international/l10n/po/de

as it does not make sense to track it. David Prevot reported that in
the past the (no longer existing) manpages-fr-extra had been removed
from being listed there as well.

Please remove it for the other languages as well (fr, es, mk, ..),
tracking it here really is useless and (speaking as part of upstream)
have good working relationship with the translators (as far as they
are still active).

If you require any further input from my side please let me know.

Thanks!

Greetings

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


signature.asc
Description: PGP signature

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

[Václav Doležal]

Hello Chris.

> Thanks for your followup. The original submitter sent this info in
> message #27:
> 
> 
># lsblk --version
>lsblk from util-linux 2.35.1
Yes, I noticed. But the bug is in libblkid, lsblk just displays info passed by 
udev.

Log in msg#37 (http://data.plan9.de/blkidbug.txt) starts with

5575: libblkid: INIT: library version: 2.33.1 [09-Jan-2019]

so I think only util-linux package was upgraded.

Otherwise, I think that the log matches the behaviour of libblkid prior to 
cdb9140967.

Regards,
Václav

Bug#985994: kwin-x11: crashes randomly on ALT-TAB for switching between windows

[Russell Coker]

Thanks for spending so much time on this.

On Saturday, 10 April 2021 9:56:42 PM AEST Bernhard Übelacker wrote:
> Could you please provide which theme you are using,
> or if there are maybe some third party extensions in use?
> 
> Maybe you are aware of some not widely used settings
> that you changed, which might be related?

Breeze Dark theme.  I changed many settings but can't think of anything that's 
related to kwin apart from the theme and colors.

It's a pity there isn't a way to dump out all the settings in some well known 
format (XML, JSON, whatever) so I could run a diff between my settings and 
default settings and then do a binary search for the problem.

-- 
My Main Blog http://etbe.coker.com.au/
My Documents Bloghttp://doc.coker.com.au/

Bug#986686: missing b-d netpbm?

[Hilmar Preuße]

Control: tags -1 + pending

Am 10.04.2021 um 11:59 teilte Matthias Klose mit:

On 4/9/21 11:14 PM, Hilmar Preuße wrote:


Hi,


The Makefile has a fallback to netpbm, but this does not work as
we  do not declare a B-D on netpbm. We could simply add it.

What do you think?


yes, that would be nice. Afaics, Ubuntu disabled that explicitly in
https://launchpad.net/ubuntu/+source/imagemagick/8:6.9.10.23+dfsg-2.1ubuntu3


Patch tested and committed to github, tag pending.

Hilmar
--
sigfault




OpenPGP_signature
Description: OpenPGP digital signature

Bug#986652: libdevmapper1.02.1 should not depend on dmsetup

[Bastian Blank]

Hi Helmut

On Sat, Apr 10, 2021 at 06:05:40PM +0200, Helmut Grohne wrote:
> On Sat, Apr 10, 2021 at 01:39:15PM +0200, Bastian Blank wrote:
> > Exactly, it requires working udev and udev rules for it's primary
> > function.  To change that, it either needs
> I fear that you still get "primary function" wrong. In many cases, the
> primary function of a shared library is being able to load it and then
> not calling any of its functions. It may be unfortunate, but that's how
> we integrate optional features from shared libraries.

The primary function is to introspect and modify the kernel device
mapper.  It does that by asking udev to do the magic, hence it needs
udev rules.

It is able to distinguish between udev missing and udev available, but
not between working udev and broken udev.  So the availability of both
the rules and dmsetup is not optional.  I don't pretend what
libdevmapper does in udev context is nice, but I assume upstream checked
other solutions as well.

> Or maybe it can quite simply fail to work if the udev rules are not
> invoked.

Please provide a patch and get it applied upstream.  Hint, the kernel
interface and udev is asynchron, so you have no obvious "fail to work".

>  Demoting the dependency is not a regression in this aspect as
> libdevmapper1.02.1 already does not depend on udev, so there already is
> no requirement on invoking the udev rules. I'm just asking for also
> skipping dmsetup.

As I said above: it can work with udev installed.  It can't work if udev
is installed but broken (not running, not providing the necessary
feedback).

I can off course merge dmsetup and the whole udev rule stuff into
libdevmapper, make it an integral part, and kill co-instabillity of
different libdevmapper versions alltogether.

> I'm attaching the obvious patch. I think that we don't actually need to
> touch other pieces of software, because it is quite difficult to get a
> system without dmsetup. This bug is not about making many systems lack
> dmsetup, but about making it possible at all.

No, this is wrong as it breaks various parts of libdevmapper.  The
library will just block in a lot of functions if the udev stuff is
missing and may even leave the user with a non-booting system.  Sorry,
I'm not going to risk breaking all of that for a marginal size
reduction.

Bastian

-- 
I'm a soldier, not a diplomat.  I can only tell the truth.
-- Kirk, "Errand of Mercy", stardate 3198.9

Bug#986735: add some superficial DEP-8 tests to libstrophe

[John Scott]

Source: libstrophe
Version: 0.10.1-1
Severity: minor
Tags: patch

Hello,

I've attached a patch that adds two autopkgtests to the package. One is
very simple and checks that the as-installed examples can be compiled,
but doesn't run them.

The other test installs Prosody, configures it to enable in-band
registration, and creates and deletes a user. Although the code may be
a little bit more ugly, I think it's worth it for a test that tests a
server as well.

I ran both tests under QEMU and they pass as-is for the unstable and
experimental packages.


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

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

From 25ba9e3e1e4e2ca55bae2a86b0d7cdc39546f01d Mon Sep 17 00:00:00 2001
From: John Scott 
Date: Sat, 10 Apr 2021 12:38:10 -0400
Subject: [PATCH] Add two superficial DEP-8 tests to test the installed
 package.

---
 debian/changelog  |  9 +
 debian/tests/build-examples   |  5 +
 debian/tests/control  |  7 +++
 debian/tests/in-band-registration | 28 
 4 files changed, 49 insertions(+)
 create mode 100755 debian/tests/build-examples
 create mode 100644 debian/tests/control
 create mode 100755 debian/tests/in-band-registration

diff --git a/debian/changelog b/debian/changelog
index b4318ae..2399a2b 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,12 @@
+libstrophe (0.11.0~git20210323.d7a28f9-2) UNRELEASED; urgency=medium
+
+  [ John Scott ]
+  * Add two superficial DEP-8 tests to test the installed package:
+- check that the installed examples can be compiled
+- try making a user using in-band registration on a local server
+
+ -- Debian XMPP Maintainers   Sat, 10 Apr 2021 12:36:29 -0400
+
 libstrophe (0.11.0~git20210323.d7a28f9-1) experimental; urgency=medium
 
   * Team upload
diff --git a/debian/tests/build-examples b/debian/tests/build-examples
new file mode 100755
index 000..115ed22
--- /dev/null
+++ b/debian/tests/build-examples
@@ -0,0 +1,5 @@
+#!/bin/sh
+set -e
+cd "$AUTOPKGTEST_TMP"
+find /usr/share/doc/libstrophe-dev/examples -name '*.c' -exec \
+	sh -c  'gcc {} $(pkg-config --cflags --libs libstrophe) -o $(basename {} .c)' \;
diff --git a/debian/tests/control b/debian/tests/control
new file mode 100644
index 000..3cd62c9
--- /dev/null
+++ b/debian/tests/control
@@ -0,0 +1,7 @@
+Tests: build-examples
+Depends: libstrophe-dev, gcc, pkg-config
+Restrictions: superficial
+
+Tests: in-band-registration
+Depends: libstrophe-dev, gcc, pkg-config, prosody
+Restrictions: isolation-container, needs-root, superficial
diff --git a/debian/tests/in-band-registration b/debian/tests/in-band-registration
new file mode 100755
index 000..aa3f62d
--- /dev/null
+++ b/debian/tests/in-band-registration
@@ -0,0 +1,28 @@
+#!/bin/sh
+set -e
+
+# Allow in-band registration
+sed -i 's/allow_registration.*$/allow_registration = true/' /etc/prosody/prosody.cfg.lua
+
+# We're probably using an auto-generated self-signed certificate; don't require that clients trust it.
+sed -i 's/c2s_require_encryption.*$/c2s_require_encryption = false/' /etc/prosody/prosody.cfg.lua
+prosodyctl check config
+systemctl restart prosody
+
+cd "$AUTOPKGTEST_TMP"
+cp /usr/share/doc/libstrophe-dev/examples/register.c .
+
+# Delete the block that tries TLS; it may not be trusted.
+sed -i '/child = xmpp_stanza_get_child_by_name(stanza, "starttls")/,/}/d' register.c
+
+gcc register.c -o register $(pkg-config --cflags --libs libstrophe)
+printf "foo\nbar\n" | (./register foo@localhost 2>&1)
+
+prosodyctl deluser foo@localhost
+
+# As an assertion check, let's validate that trying to delete a non-existent user returns failure.
+prosodyctl deluser nonexistent@localhost || EXITSTAT=$?
+if [ "$EXITSTAT" = "0" ]
+then
+	exit 1
+fi
-- 
2.30.2



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

Bug#986734: Debdiff

[Adam Cecile]

Please find attached debdiff I'm currently testing (all upstream 
information included in patch header)


diff -Nru rabbitmq-server-3.8.9/debian/changelog 
rabbitmq-server-3.8.9/debian/changelog
--- rabbitmq-server-3.8.9/debian/changelog  2021-03-26 14:24:32.0 
+0100
+++ rabbitmq-server-3.8.9/debian/changelog  2021-04-10 18:06:59.0 
+0200
@@ -1,3 +1,10 @@
+rabbitmq-server (3.8.9-2.1+PR2965) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Merge upstream PR #2965 fixing rabbitmqctl parsing bug.
+
+ -- Adam Cecile   Sat, 10 Apr 2021 18:06:59 +0200
+
 rabbitmq-server (3.8.9-2) unstable; urgency=medium
 
   * Do not use the /usr/sbin/rabbitmq-server wrapper in systemd service file
diff -Nru rabbitmq-server-3.8.9/debian/patches/series 
rabbitmq-server-3.8.9/debian/patches/series
--- rabbitmq-server-3.8.9/debian/patches/series 2021-03-26 14:24:32.0 
+0100
+++ rabbitmq-server-3.8.9/debian/patches/series 2021-04-10 18:06:59.0 
+0200
@@ -1,2 +1,3 @@
 lets-use-python3-not-python-binary.patch
 rabbitmq-dist.mk.patch
+Upstream_PR2965_fixing_rabbitmqctl_parsing
diff -Nru 
rabbitmq-server-3.8.9/debian/patches/Upstream_PR2965_fixing_rabbitmqctl_parsing 
rabbitmq-server-3.8.9/debian/patches/Upstream_PR2965_fixing_rabbitmqctl_parsing
--- 
rabbitmq-server-3.8.9/debian/patches/Upstream_PR2965_fixing_rabbitmqctl_parsing 
1970-01-01 01:00:00.0 +0100
+++ 
rabbitmq-server-3.8.9/debian/patches/Upstream_PR2965_fixing_rabbitmqctl_parsing 
2021-04-10 18:06:59.0 +0200
@@ -0,0 +1,46 @@
+Description: Fix incorrect parsing of vm_memory_high_watermark
+Author: Michael Klishin 
+
+---
+Origin: upstream, https://github.com/rabbitmq/rabbitmq-server/pull/2965
+Bug: https://github.com/rabbitmq/rabbitmq-server/issues/2964
+Bug-Debian: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=986734
+Forwarded: not-needed
+Reviewed-By: Adam Cecile 
+Last-Update: 2021-04-10
+
+--- rabbitmq-server-3.8.9.orig/deps/rabbit/src/rabbit_disk_monitor.erl
 rabbitmq-server-3.8.9/deps/rabbit/src/rabbit_disk_monitor.erl
+@@ -66,7 +66,7 @@
+ 
+ %%
+ 
+--type disk_free_limit() :: (integer() | string() | {'mem_relative', float() | 
integer()}).
++-type disk_free_limit() :: integer() | {'absolute', integer()} | string() | 
{'mem_relative', float() | integer()}.
+ 
+ %%
+ %% Public API
+@@ -272,6 +272,8 @@ parse_free_win32(CommandResult) ->
+ interpret_limit({mem_relative, Relative})
+ when is_number(Relative) ->
+ round(Relative * vm_memory_monitor:get_total_memory());
++interpret_limit({absolute, Absolute}) ->
++interpret_limit(Absolute);
+ interpret_limit(Absolute) ->
+ case rabbit_resource_monitor_misc:parse_information_unit(Absolute) of
+ {ok, ParsedAbsolute} -> ParsedAbsolute;
+--- 
rabbitmq-server-3.8.9.orig/deps/rabbitmq_cli/lib/rabbitmq/cli/core/memory.ex
 rabbitmq-server-3.8.9/deps/rabbitmq_cli/lib/rabbitmq/cli/core/memory.ex
+@@ -56,6 +56,12 @@ defmodule RabbitMQ.CLI.Core.Memory do
+   def formatted_watermark(val) when is_float(val) do
+ %{relative: val}
+   end
++  def formatted_watermark({:relative, val}) when is_float(val) do
++%{relative: val}
++  end
++  def formatted_watermark(:infinity) do
++%{relative: 1.0}
++  end
+   def formatted_watermark({:absolute, val}) do
+ %{absolute: parse_watermark(val)}
+   end

Bug#986734: rabbitmq-server: Incorrect parsing of vm_memory_high_watermark renders rabbitmqctl unusable

[Adam Cecile]

Package: rabbitmq-server
Version: 3.8.9-2
Severity: important
Tags: patch upstream

Hello,

I just hit this bug after upgrading some RabbitMQ server from Buster to
Bullseye and upstream already fixed it (backported to branch 3.8.x).

After upgrade cluster was barely usable because rabbitmqctl was unusable due to
a parsing issue.
When server config is in erlang format (the one used by everybody deploying
RabbitMQ using the official Puppet module) and has relative memory watermark
configured using an object, it just crash with:
(FunctionClauseError) no function clause matching in
RabbitMQ.CLI.Core.Memory.formatted_watermark/1

Upstream acknowledged the issue and fixed it, they also improved parsing to not
fail on another config issue I had in my file.

Would you please consider merging this patch for Debian 11 release ? I don't
think it's a serious issue but will definitely cause usuability/upgrade issues
to someone.

I'm currently rebuilding a patched version of RabbitMQ package to test upstream
patch and will report back.

Best regards, Adam.



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

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

Versions of packages rabbitmq-server depends on:
ii  adduser 3.118
pn  erlang-base | erlang-base-hipe  
pn  erlang-crypto   
pn  erlang-eldap
pn  erlang-inets
pn  erlang-mnesia   
pn  erlang-nox | esl-erlang 
pn  erlang-os-mon   
pn  erlang-parsetools   
pn  erlang-public-key   
pn  erlang-runtime-tools
pn  erlang-ssl  
pn  erlang-syntax-tools 
pn  erlang-tools
pn  erlang-xmerl
pn  locales-all 
ii  logrotate   3.14.0-4
ii  lsb-base10.2019051400
ii  python  2.7.16-1
ii  socat   1.7.3.2-2

rabbitmq-server recommends no packages.

rabbitmq-server suggests no packages.

Bug#986733: Support for pipewire

[Yuri D'Elia]

Package: pulseeffects
Severity: wishlist

Hi maintainers,

Since pipewire is now available in unstable, would it be possible to
support for using pulseeffects directly with a pipewire daemon?

Would the current package/build already work with pipewire, or would
pulseeffects require a different package entirely?

Thanks!


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

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

Bug#986652: libdevmapper1.02.1 should not depend on dmsetup

[Helmut Grohne]

Hi Bastian,

On Sat, Apr 10, 2021 at 01:39:15PM +0200, Bastian Blank wrote:
> Exactly, it requires working udev and udev rules for it's primary
> function.  To change that, it either needs

I fear that you still get "primary function" wrong. In many cases, the
primary function of a shared library is being able to load it and then
not calling any of its functions. It may be unfortunate, but that's how
we integrate optional features from shared libraries.

> - to be split into two libraries, one with the stuff that needs udev
>   rules, one for the stuff without or
> - runtime detection if udev can work.

Or maybe it can quite simply fail to work if the udev rules are not
invoked. Demoting the dependency is not a regression in this aspect as
libdevmapper1.02.1 already does not depend on udev, so there already is
no requirement on invoking the udev rules. I'm just asking for also
skipping dmsetup.

> Maybe.  Please provide a patch to fix this problem, without touching
> every piece of software that, directly or indirectly, links against
> libdevmapper.

I'm attaching the obvious patch. I think that we don't actually need to
touch other pieces of software, because it is quite difficult to get a
system without dmsetup. This bug is not about making many systems lack
dmsetup, but about making it possible at all.
 * dmsetup is still recommended by libdevmapper1.02.1, so you need to
   turn off Recommends.
 * dmsetup is pulled by lvm2 and cryptsetup.
 * Given that systemd is important and transitively depends on dmsetup
   at present, we can elevante dmsetup's priority without regressing
   anything. That way it remains part of a default debootstrap.
 * The actual bug that introduced the dmsetup dependency was about a
   mismatched version of dmsetup and libdevmapper1.02.1. Such a
   situation is prevented by suitable Breaks.

> Because the dependency on libdevmapper1.02.1 can only go after systemd
> (or maybe libcryptsetup) got it.

Neither actually need it unconditionally. We really want to be able to
install systemd without dmsetup. That's the highlevel goal of this bug
here.

Helmut
diff --minimal -Nru lvm2-2.03.11/debian/changelog lvm2-2.03.11/debian/changelog
--- lvm2-2.03.11/debian/changelog   2021-02-22 22:39:14.0 +0100
+++ lvm2-2.03.11/debian/changelog   2021-04-10 17:14:20.0 +0200
@@ -1,3 +1,12 @@
+lvm2 (2.03.11-2.2) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Demote libdevmapper1.02.1 -> dmsetup dependency to versioned Breaks +
+Recommends. Increase its priority to important to remain in a default
+debootstrap. (closes: #986652)
+
+ -- Helmut Grohne   Sat, 10 Apr 2021 17:14:20 +0200
+
 lvm2 (2.03.11-2.1) unstable; urgency=medium
 
   * Non-maintainer upload.
diff --minimal -Nru lvm2-2.03.11/debian/control lvm2-2.03.11/debian/control
--- lvm2-2.03.11/debian/control 2021-02-22 22:39:14.0 +0100
+++ lvm2-2.03.11/debian/control 2021-04-10 17:14:20.0 +0200
@@ -144,7 +144,10 @@
 Depends:
  ${shlibs:Depends},
  ${misc:Depends},
- dmsetup (>= ${devmapper:Version}~),
+Breaks:
+ dmsetup (<< ${devmapper:Version}~),
+Recommends:
+ dmsetup,
 Multi-Arch: same
 Description: Linux Kernel Device Mapper userspace library
  The Linux Kernel Device Mapper is the LVM (Linux Logical Volume Management)
@@ -183,6 +186,7 @@
  ${shlibs:Depends},
  ${misc:Depends},
 Multi-Arch: foreign
+Priority: important
 Description: Linux Kernel Device Mapper userspace library
  The Linux Kernel Device Mapper is the LVM (Linux Logical Volume Management)
  Team's implementation of a minimalistic kernel-space driver that handles

Bug#986651: systemd: stop depending on systemd-timesyncd

[Helmut Grohne]

Hi Michael,

On Sat, Apr 10, 2021 at 12:17:24PM +0200, Michael Biebl wrote:
> A few thoughts.
> The disk footprint of systemd-timesyncd is rather small.
> It would be good to know which kind of containers your have in mind.
> docker-style (minimal) without an init or with a full-blown init like lxc
> (fat)?

Indeed, I have systemd-nspawn containers in mind. Those require
systemd-container inside the container.

> The former doesn't have init/systemd installed (and thus no
> systemd-timesyncd), the latter does and systemd itself is much bigger disk
> footprint wise.

Indeed, systemd is much bigger, but at the same time, it is much harder
to get rid of. I'm trying to reduce the footprint on all ends.

> If we bump the prio of systemd-timesyncd, those minimal containers will now
> suddenly get systemd-timesyncd by default (which in turn pulls systemd). So
> this would be a regression. You'd have to be careful to omit
> systemd-timesyncd when building the container image.

I don't think minimal containers install Priority: important packages,
not even Priority: required ones.  At least that's not how I approach
it. I usually start with just Essential: yes and add what is needed.
Possibly though, this workflow is not the one other people use. How do
we find out? For instance, e2fsprogs is not Essential: yes, but
Priority: required precisely for the container use case.

In any case, there is no regression as systemd presently is Priority:
important and systemd depends on systemd-timesyncd. If they'd install
systemd-timesyncd due to Priority: important, they'd do it today
already.

> For fat containers, having systemd-timesyncd installed doesn't really gain
> you a lot (and is no regression compared to buster, where it was folded in).

There certainly is a trade-off here. You likely know that I'm also
trimming essential in various aspects. There is no single big thing to
make containers smaller, so what remains is more like 100 paper cuts
that makes them fat. I don't think we can compete with alpine, but we
can get a lot closer. Given how central systemd is today, I think fairly
many practical instances would benefit from being slightly smaller and
at that scale it adds up.

> Runtime-wise, having systemd-timesyncd installed, is not a problem either,
> as systemd-timesyncd.service has ConditionVirtualization=!container

Agreed.

There are magic boundaries at 64MB and 128MB size. For various use
cases, we're slightly above or below these. Debian tends to grow over
time, so it really is work to keep it small.

Helmut

Bug#985994: kwin-x11: crashes randomly on ALT-TAB for switching between windows

[Bernhard Übelacker]

Hello Russel,
thank you for the detailed backtraces.
Unfortunately they point into Qt's javascript module,
finally trying to copy memory to a null pointer.

I have not found a hint to similar crashes in
upstream bug tracker.

Could you please provide which theme you are using,
or if there are maybe some third party extensions in use?

Maybe you are aware of some not widely used settings
that you changed, which might be related?

Kind regards,
Bernhard

Bug#986662: ossp-padsp not working with recent Pulseaudio

[Ralf Jung]

Dear Sébastien,


The current osspd packages isn't working with current pulseaudio and it hasn't
for more than a year. I didn't file a bug back then, but I can confirm that
at the time it was a pulseaudio update that broke osspd.
Downgrading to an earlier version fixed the problem.

Here is what the osspd logs says:
ossp-padsp[] WARN: failed to subscribe to context events (Bad state)
ossp-padsp[] ERR: failed to connect context, state=5 (Bad state)

This bug has also been reported on launchpad for Ubuntu:
https://bugs.launchpad.net/ubuntu/+source/osspd/+bug/1857810

Almost 18 months later, I did found (by pure luck) that the ArchLinux package
has a fix for this problem.
Please find a debdiff in attachment so that you can upload the fix in Debian.


Thanks a lot for this! I have applied the patch in the git version of the 
package. I'll look into moving to a non-deprecated debhelper compat level, and 
then upload a new version.


Would you be interested in helping maintain osspd? As you can tell from it not 
working for more than a year, I am not actually using this package any more. I 
am also not maintaining any other Debian packages, so each time something comes 
up I have to re-learn how to use the involved tools.^^


Kind regards,
Ralf

Bug#986732: unblock: mutt/2.0.5-4

[Antonio Radici]

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

Please unblock package mutt

[ Reason ]
2.0.5-4 includes a patch to fix a slowness in opening messages due to coloring
which can amount to up to tens of seconds (see bugs.debian.org/985152).

[ Impact ]
Same as above.

[ Tests ]
No tests affected.

[ Risks ]
The change itself is trivial (see patch), and it has been already included in
the most recent version of mutt released.

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

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

unblock mutt/2.0.5-4
diff -Nru mutt-2.0.5/debian/changelog mutt-2.0.5/debian/changelog
--- mutt-2.0.5/debian/changelog 2021-02-16 21:34:09.0 +0100
+++ mutt-2.0.5/debian/changelog 2021-03-20 17:26:12.0 +0100
@@ -1,3 +1,11 @@
+mutt (2.0.5-4) unstable; urgency=medium
+
+  * debian/patches:
++ upstream/985152-body-color-slowness.patch: fixes slowness (up to tens of
+  seconds) if body coloring is present (Closes: 985152).
+
+ -- Antonio Radici   Sat, 20 Mar 2021 17:26:12 +0100
+
 mutt (2.0.5-3) unstable; urgency=medium
 
   * debian/patches:
diff -Nru mutt-2.0.5/debian/patches/series mutt-2.0.5/debian/patches/series
--- mutt-2.0.5/debian/patches/series2021-02-16 21:32:50.0 +0100
+++ mutt-2.0.5/debian/patches/series2021-03-20 17:24:06.0 +0100
@@ -12,3 +12,4 @@
 misc/smime.rc.patch
 upstream/528233-readonly-open.patch
 upstream/980924-updated-german-translation.patch
+upstream/985152-body-color-slowness.patch
diff -Nru mutt-2.0.5/debian/patches/upstream/985152-body-color-slowness.patch 
mutt-2.0.5/debian/patches/upstream/985152-body-color-slowness.patch
--- mutt-2.0.5/debian/patches/upstream/985152-body-color-slowness.patch 
1970-01-01 01:00:00.0 +0100
+++ mutt-2.0.5/debian/patches/upstream/985152-body-color-slowness.patch 
2021-03-20 17:25:35.0 +0100
@@ -0,0 +1,163 @@
+From 53ffdb93b8a96efb7456f9430cf46a66ca7b9860 Mon Sep 17 00:00:00 2001
+From: Kevin McCarthy 
+Date: Wed, 10 Mar 2021 15:09:49 -0800
+Subject: [PATCH] Improve body color matching speed by caching future matches.
+
+On a *very* long body (or header_partial) lines with multiple color
+lines that match, performance can be degraded.  For instance if there
+were moderately expensive regexp matches against "A" "B" and "C".  A
+line with:
+
+  A A A A A B A A C A A A B A A A C
+
+The B and C regexps were scanned again after every "A" match, despite
+that the result would be discarded again for the next A match.
+
+Change the color matching to cache the location of each color line
+match.  Discard the cache once the match offset passes that point.
+---
+ mutt_curses.h |  5 
+ pager.c   | 64 ---
+ 2 files changed, 55 insertions(+), 14 deletions(-)
+
+--- a/mutt_curses.h
 b/mutt_curses.h
+@@ -154,9 +154,14 @@
+   int pair;
+   struct color_line *next;
+ 
++  regoff_t cached_rm_so;
++  regoff_t cached_rm_eo;
++
+   unsigned int stop_matching : 1; /* used by the pager for body patterns,
+  to prevent the color from being retried
+  once it fails. */
++  unsigned int cached : 1; /* indicates cached_rm_so and cached_rm_eo
++* hold the last match location */
+ } COLOR_LINE;
+ 
+ #define MUTT_PROGRESS_SIZE  (1<<0)  /* traffic-based progress */
+--- a/pager.c
 b/pager.c
+@@ -773,7 +773,7 @@
+ {
+   COLOR_LINE *color_line, *color_list;
+   regmatch_t pmatch[1];
+-  int found, offset, null_rx, i;
++  int i;
+ 
+   if (n == 0 || ISHEADER (lineInfo[n-1].type) ||
+   (check_protected_header_marker (raw) == 0))
+@@ -879,6 +879,8 @@
+   (lineInfo[n].type == MT_COLOR_HDEFAULT && option 
(OPTHEADERCOLORPARTIAL)))
+   {
+ size_t nl;
++int has_nl = 0, found, offset, null_rx, has_reg_match;
++regoff_t rm_so, rm_eo;
+ 
+ /* don't consider line endings part of the buffer
+  * for regex matching */
+@@ -896,8 +898,10 @@
+ while (color_line)
+ {
+   color_line->stop_matching = 0;
++  color_line->cached = 0;
+   color_line = color_line->next;
+ }
++
+ do
+ {
+   if (!buf[offset])
+@@ -908,11 +912,31 @@
+   color_line = color_list;
+   while (color_line)
+   {
+-  if (!color_line->stop_matching &&
+-regexec (&color_line->rx, buf + offset, 1, pmatch,
+-   (offset ? REG_NOTBOL : 0)) == 0)
++has_reg_match = 0;
++  if (!color_line->stop_matching)
++{
++  if (color_line->cached)
++  {
++has_reg_match = 1;
++rm_so = color_line->cached_rm_so;
++rm_eo = color_line->cached_rm_eo;
++  }
++  else
++  {
++if (regexec (&color_line->rx, buf + offset, 

Bug#977358: release-notes: document how to make the rescue mode usable if no root password is set (buster)

[Andrei POPESCU]

On Sb, 10 apr 21, 10:53:52, Justin B Rye wrote:
> Andrei POPESCU wrote:
> > Ok, here is something, just to get the discussion started:
> 
> Thanks!  My suggestions below still need some work, but I'll call this
> my first pass:
> 
> > The `rescue` boot option is unusable without a root password.
> >
> > If a password for the `root` account is not set the system will 
> > still ask for the root password if booted with the `rescue` option, 
> > effectively making the rescue mode unusable. In order to avoid this
> > it is possible to boot using the kernel parameter 
> > `init=/sbin/sulogin --force`.
> 
> Simplifying:
> 
> 
>   The rescue boot option is unusable without a root 
> password
> 
> 
>   Booting with the rescue option always requires
>   the root password. If one has not been set, this makes the rescue
>   mode effectively unusable. However it is still possible to boot
>   using the kernel parameter init=/sbin/sulogin --force
> 
> 
> (I don't think "root" needs special markup; "rescue" only needs it
> when we're talking about an untranslatable literal string).
 
Ok

> (Should there be some hint here at the fact that this has happened
> because we've switched to an implementation of sulogin without the
> slightly dodgy Debian-specific patches?)

This is explained in the bug report for who cares to investigate, in my 
opinion it's not needed in the Release Notes.

> > To configure pkg:systemd to always to do the equivalent of this on 
>^^^ ^^^^
> When we're talking about machines booting with systemd-sysv, we should
> avoid mentioning systemd
> (which is a pain to type anyway).
> 
> The "to" might go in either position, but not both.  Here perhaps we
> might be better off saying

It's a consequence of some rewrite :)

>   To configure systemd to do the equivalent of this whenever the
>   rescue option is used,
> 
> > selecting the `rescue` option add `SYSTEMD_SULOGIN_FORCE=1` to the 
> > Environment of the rescue.service unit (see 
> > file:/usr/share/doc/systemd/ENVIRONMENT.md.gz). The `rescue.service` 
> 
> At least this information is already on my system before the
> dist-upgrade.
> 
> > unit is started by pkg:systemd in case it detects `single` in the 
>  ^^^
> > kernel command line (see man:systemd).
> 
> Bad use of "in case" - most English-speakers interpret "in case of" as
> "unconditionally, to avert the danger of".

I'll have to trust you on this (and make a mental note about it).

> systemd(1) defines "single" and "rescue" (and "1"!) as aliases of
> "systemd.unit=rescue.target", so maybe we can make that clearer
> earlier.
> 
> 
>   To configure systemd to do the equivalent of this whenever it
>   boots into rescue mode (also known as single mode - seeurl="&url-man;/bullseye/systemd/systemd.1.html">systemd(1)),
>   add SYSTEMD_SULOGIN_FORCE=1 to the
>   Environment of the rescue.service unit (see
>   /usr/share/doc/systemd/ENVIRONMENT.md.gz).
> 
> 
> Unfortunately we also need readers to know
>  * how to add things to a systemd unit (we don't want people editing
>/lib/systemd/system/rescue.service and losing it in an upgrade)
>  * how much of the rest of the file they should copy (as little as
>possible, I think, but how much is that?)
>  * how the syntax for multiple items in an Environment= line works
> 
> This probably needs an external link, but I'm not optimistic we'll
> find one.  Maybe this is another case where we'll need a dedicated
> page on wiki.debian.org.

As you probably know, it's as simple as:

systemctl edit rescue.service

and add

[Service]
Environment=SYSTEMD_SULOGIN_FORCE=1


It seemed a little bit much to add this as well, but I'm fine either 
way.

> (And why *is* the systemd man page in section 1, anyway?  Shouldn't it
> be in section 8, like systemv init used to be?)
> 
> > It might be useful to do the same for the `emergency.service` unit 
> > (or instead) which is started ''automatically'' in case of certain 
>^^ ^^
> > errors (see man:systemd.special), or if `emergency` is added to the 
> > kernel command line (e.g. in case the system can't be recovered by
> ^^^
> > using the `rescue` mode).
> 
> "The same or instead" needs to be reorganised as "as well or instead".
> 
> One of those "in case"s almost works.
> 
> I'm not sure what markup you mean for ''automatically''.

Some form of emphasis, to draw attention to the fact that users might 
find themselves stuck at the emergency console.

> 
>   It might be useful to do this for the 
> emergency.service
>   unit (as well or instead), which is started automatically in the case
>   of certain errors (see
> url="&url-man;/bullseye/systemd/systemd.special.7

Bug#985853: debian-installer: Whitespace before a commented line in preseed file causes line to be parsed

[Holger Wansing]

Control: reassign -1 src:installation-guide

Charles Curley  wrote (Thu, 25 Mar 2021 
12:06:32 -0600):
> On Thu, 25 Mar 2021 10:49:06 -0400
> lsore...@csclub.uwaterloo.ca (Lennart Sorensen) wrote:
> 
> > Well none of the examples ever have spaces before # for comments.
> > The documentation page you linked to doesn't even mention comments at
> > all. I would agree that perhaps it should.  I have certainly
> > encountered file types before where comments had to have # at the
> > start of the line.
> 
> May I suggest inserting the following as the last bullet point item at
> the top of "B.3. Creating a preconfiguration file" the following:
> 
> A comment consist of a line which *starts* with a sharp character ("#")
> and extends the length of that line.
> 
> https://www.debian.org/releases/stable/i386/apbs03.en.html
> 
> The emphasis on the word "starts" should probably be italics, or, in
> HTML, .

Re-assigning to installation-guide


Holger


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

Bug#986731: wireshark: packet bytes frame doesn't show all ASCII bytes

[Paul Slootman]

Package: wireshark
Version: 3.4.4-1
Severity: normal

When viewing packets from a capture file, I found that the ASCII
decoding of the bytes doesn't show most of the last 8 bytes on each row
of 16. This is an example of what is shown:

   00 e0 4c dc 45 db 00 f7 01 fc c5 31 08 00 45 00   ..L.E...
0010   00 40 a7 86 40 00 40 11 39 36 ac 12 01 ca ac 12   .@..@.@.
0020   00 02 4b e4 00 35 00 2c c5 f9 30 50 01 00 00 01   ..K..5.,
0030   00 00 00 00 00 00 05 67 72 61 70 68 08 66 61 63   ...g
0040   65 62 6f 6f 6b 03 63 6f 6d 00 00 01 00 01 ebook.co m.

Curiously, right click and "Copy Bytes as Hex + ASCII Dump" does result
in the following being copied:

   00 e0 4c dc 45 db 00 f7 01 fc c5 31 08 00 45 00   ..L.E..1..E.
0010   00 40 a7 86 40 00 40 11 39 36 ac 12 01 ca ac 12   .@..@.@.96..
0020   00 02 4b e4 00 35 00 2c c5 f9 30 50 01 00 00 01   ..K..5.,..0P
0030   00 00 00 00 00 00 05 67 72 61 70 68 08 66 61 63   ...graph.fac
0040   65 62 6f 6f 6b 03 63 6f 6d 00 00 01 00 01 ebook.com.

In the example above all but the last line had the problem, however on
some data a couple of ASCII characters are shown on the right part, but
still not all. I have not been able to find a pattern when a byte is
shown or not.

I noticed this on 3.4.2-1, tried updating to 3.4.4-1 but that didn't
make any difference.

Thanks,
Paul


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

Kernel: Linux 5.8.0-2-amd64 (SMP w/8 CPU cores)
Kernel taint flags: TAINT_FORCED_RMMOD, TAINT_WARN, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US:en (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash
Init: sysvinit (via /sbin/init)

Versions of packages wireshark depends on:
ii  wireshark-qt  3.4.4-1

wireshark recommends no packages.

wireshark suggests no packages.

-- no debconf information

Bug#986240: make-guile: broken symlink: /usr/bin/gmake -> /make

[Sébastien Villemot]

Control: tags -1 + patch pending

Dear Maintainer,

On Thu, 01 Apr 2021 12:59:16 +0200 Andreas Beckmann  wrote:
> Package: make-guile
> Version: 4.3-4
> Severity: serious
> User: debian...@lists.debian.org
> Usertags: piuparts

> during a test with piuparts I noticed your package ships (or creates)
> a broken symlink.
> 
> From the attached log (scroll to the bottom...):
> 
> 0m14.7s ERROR: FAIL: Broken symlinks:
>   /usr/share/man/man1/gmake.1.gz -> /make.1.gz (make-guile)
>   /usr/bin/gmake -> /make (make-guile)

I have uploaded to DELAYED/2 a fix for this bug. Don’t hesitate to tell
me if I should delay it longer. The debdiff is attached. 

Best,

-- 
⢀⣴⠾⠻⢶⣦⠀  Sébastien Villemot
⣾⠁⢠⠒⠀⣿⡁  Debian Developer
⢿⡄⠘⠷⠚⠋⠀  https://sebastien.villemot.name
⠈⠳⣄  https://www.debian.org

diff -u make-dfsg-4.3/debian/changelog make-dfsg-4.3/debian/changelog
--- make-dfsg-4.3/debian/changelog
+++ make-dfsg-4.3/debian/changelog
@@ -1,3 +1,11 @@
+make-dfsg (4.3-4.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * make-guile: fix broken symlinks /usr/bin/gmake and
+/usr/share/man/man1/gmake.1.gz. (Closes: #986240)
+
+ -- Sébastien Villemot   Sat, 10 Apr 2021 15:55:15 +0200
+
 make-dfsg (4.3-4) unstable; urgency=high
 
   * Cherry picked [SV 58232] Disable inheritance of jobserver FDs for
diff -u make-dfsg-4.3/debian/make-guile.links make-dfsg-4.3/debian/make-guile.links
--- make-dfsg-4.3/debian/make-guile.links
+++ make-dfsg-4.3/debian/make-guile.links
@@ -1,2 +1,2 @@
-make usr/bin/gmake
-make.1.gz usr/share/man/man1/gmake.1.gz
+usr/bin/make usr/bin/gmake
+usr/share/man/man1/make.1.gz usr/share/man/man1/gmake.1.gz


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

Bug#986618: unblock: zfs-linux/2.0.3-6

[Paul Gevers]

Control: tags -1 moreinfo

On 08-04-2021 09:17, M. Zhou wrote:
> 3. d/test/control: fix i386 autopkgtest failure due to
>missing kernel header dependency

If you also fix the armhf failure, we don't even need to discuss
anything in this unblock request. In my trial, installing
linux-hearders-armmp seemed to work.

If you fix your autopktest, then please also improve dkms-zfs-test to
use the (new) Architecture field to skip architectures where you're not
doing anything, or (less preferred as it duplicates the code in
autopkgtest) add the skippable restriction and exit 77 instead of 0
here:
https://sources.debian.org/src/zfs-linux/2.0.3-6/debian/tests/dkms-zfs-test/#L6

Paul



OpenPGP_signature
Description: OpenPGP digital signature

Bug#986730: RFP: publictransport-de -- real time information for public transportation (currently in Germany)

[Martin]

Package: wnpp
Severity: wishlist

* Package name: publictransport-de
  Version : git master
  Upstream Author : terence 
* URL : https://gitlab.com/terence97/publictransport
* License : GPL-3.0-or-later
  Programming Lang: Rust
  Description : real time information for public transportation (currently 
in Germany)

Bring Real time information for public transportation (currently in
Germany) to Linux phones/the Linux desktop (the basic features of the
likes of DB Navigator or Transportr).

The original name is publictransport, but maybe the name should
reflect the (current) local nature of the software.

Bug#986729: unblock: nodejs/12.21.0~dfsg-3

[Jérémy Lal]

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

Please unblock package nodejs

[ Reason ]
Two patches are added:

* Upstream patch fix test-worker-prof
  Closes: #985550, "test-worker-prof is flaky on s390x"
  which has lead to ftbfs sometimes.
* THP ELF assembly: Add .note.GNU-stack section
  Closes: #980272, "'/usr/bin/node' started with executable stack"
  which IMO is an important security issue but i cannot proof it.

[ Impact ]
Potential FTBFS, potential security issue.

[ Tests ]
The first patch is a fixed upstream version of a flaky test.
The second patch was just verified manually like this:
readelf --program-headers --wide /usr/bin/node | grep -w GNU_STACK
  GNU_STACK  0x00 0x 0x 0x00 
0x00 RW  0x10

[ Risks ]
Zero risks.
nodejs and many other modules have test suites and there was no regression.
One change only affects the test suite, the other only affects the executable 
bit.


[ 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 nodejs/12.21.0~dfsg-3
diff -Nru nodejs-12.21.0~dfsg/debian/changelog 
nodejs-12.21.0~dfsg/debian/changelog
--- nodejs-12.21.0~dfsg/debian/changelog2021-02-23 19:14:23.0 
+0100
+++ nodejs-12.21.0~dfsg/debian/changelog2021-03-19 18:43:52.0 
+0100
@@ -1,3 +1,16 @@
+nodejs (12.21.0~dfsg-3) unstable; urgency=medium
+
+  * Upstream patch fix test-worker-prof (Closes: #985550)
+
+ -- Jérémy Lal   Fri, 19 Mar 2021 18:43:52 +0100
+
+nodejs (12.21.0~dfsg-2) unstable; urgency=medium
+
+  [ James Addison ]
+  * THP ELF assembly: Add .note.GNU-stack section (Closes: #980272)
+
+ -- Jérémy Lal   Fri, 19 Mar 2021 11:15:57 +0100
+
 nodejs (12.21.0~dfsg-1) unstable; urgency=high
 
   * New upstream version 12.21.0~dfsg
diff -Nru 
nodejs-12.21.0~dfsg/debian/patches/large_pages_assembly_gnu_stack.patch 
nodejs-12.21.0~dfsg/debian/patches/large_pages_assembly_gnu_stack.patch
--- nodejs-12.21.0~dfsg/debian/patches/large_pages_assembly_gnu_stack.patch 
1970-01-01 01:00:00.0 +0100
+++ nodejs-12.21.0~dfsg/debian/patches/large_pages_assembly_gnu_stack.patch 
2021-03-19 11:13:53.0 +0100
@@ -0,0 +1,12 @@
+Description: Adds .GNU-stack section header to disable executable stack flag
+Author: James Addison 
+Origin: https://github.com/nodejs/node/pull/37688
+--- a/src/large_pages/node_text_start.S
 b/src/large_pages/node_text_start.S
+@@ -1,3 +1,6 @@
++#if defined(__ELF__)
++.section .note.GNU-stack,"",@progbits
++#endif
+ .text
+ .align 0x2000
+ .global __node_text_start
diff -Nru nodejs-12.21.0~dfsg/debian/patches/series 
nodejs-12.21.0~dfsg/debian/patches/series
--- nodejs-12.21.0~dfsg/debian/patches/series   2021-02-23 19:14:23.0 
+0100
+++ nodejs-12.21.0~dfsg/debian/patches/series   2021-03-19 18:28:07.0 
+0100
@@ -1,3 +1,4 @@
+large_pages_assembly_gnu_stack.patch
 dfhs_module_path_arch_triplet.patch
 # 2012_kfreebsd.patch
 use_system_node_gyp.patch
@@ -15,3 +16,4 @@
 ppc64.patch
 python3.patch
 cjs-module-lexer.patch
+upstream-fix-test-worker-prof.patch
diff -Nru 
nodejs-12.21.0~dfsg/debian/patches/upstream-fix-test-worker-prof.patch 
nodejs-12.21.0~dfsg/debian/patches/upstream-fix-test-worker-prof.patch
--- nodejs-12.21.0~dfsg/debian/patches/upstream-fix-test-worker-prof.patch  
1970-01-01 01:00:00.0 +0100
+++ nodejs-12.21.0~dfsg/debian/patches/upstream-fix-test-worker-prof.patch  
2021-03-19 18:27:32.0 +0100
@@ -0,0 +1,93 @@
+From 04fb597996455d0abbe7b12bbc2d2a5ce16fbb3d Mon Sep 17 00:00:00 2001
+From: Rich Trott 
+Date: Sun, 14 Feb 2021 15:52:54 -0800
+Subject: [PATCH] test: fix flaky test-worker-prof
+MIME-Version: 1.0
+Content-Type: text/plain; charset=UTF-8
+Content-Transfer-Encoding: 8bit
+
+Fixes: https://github.com/nodejs/node/issues/26401
+Co-authored-by: Gireesh Punathil 
+
+PR-URL: https://github.com/nodejs/node/pull/37372
+Reviewed-By: Antoine du Hamel 
+Reviewed-By: Michaël Zasso 
+Reviewed-By: James M Snell 
+Reviewed-By: Luigi Pinca 
+Reviewed-By: Gireesh Punathil 
+---
+ test/sequential/sequential.status   |  4 
+ test/sequential/test-worker-prof.js | 15 ---
+ 2 files changed, 8 insertions(+), 11 deletions(-)
+
+--- a/test/sequential/sequential.status
 b/test/sequential/sequential.status
+@@ -24,8 +24,6 @@
+ [$system==win32]
+ # https://github.com/nodejs/node/issues/22327
+ test-http2-large-file: PASS, FLAKY
+-# https://github.com/nodejs/node/issues/26401
+-test-worker-prof: PASS, FLAKY
+ 
+ [$system==linux]
+ 
+@@ -45,10 +43,6 @@
+ # https://github.com/nodejs/node/pull/30819
+ test-perf-hooks: SKIP
+ 
+-[$arch==arm]
+-# https://github.com/nodejs/node/issues/26401#issuecomment-613095719
+-test-worker-prof: PASS, FLAKY
+-
+ [$arch==mipsel]
+ test-inspector-async-hook-setup-at-inspect-brk: SKIP
+ test-inspector-async-hook-set

Bug#986637: Link to the fix

[kakohari]

https://github.com/sivel/speedtest-cli/commit/cadc68b5aef20f28648072cf07a8f155639b81dd#diff-561d5175f923c2ffd7764768f8e3cd6e1fdb41806bf1b0e4da699ab21bb31930

As it is a small change, this would be nice to have in the repo soon, as
it is used heavily for...speedtests ;-)

TIA!

Bug#986622: fixes

[Matus UHLAR - fantomas]

Hello,

I just wanted to note that clamav 0.103.2 fixes[1] all issues currently open
at security tracker[2]

CVE-2021-1252
CVE-2021-1404
CVE-2021-1405

It also makes freshclam more efficient for work with clamav mirrors, which
is desired for clamav infrastructure that has problems with older
versions[3] [4] [5].

[1]
https://blog.clamav.net/2021/04/clamav-01032-security-patch-release.html

[2]
https://security-tracker.debian.org/tracker/source-package/clamav 


[3]
https://lists.clamav.net/pipermail/clamav-users/2021-March/010544.html

[4]
https://lists.clamav.net/pipermail/clamav-users/2021-March/010578.html

[5]
https://lists.clamav.net/pipermail/clamav-users/2021-April/011043.html
--
Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/
Warning: I wish NOT to receive e-mail advertising to this address.
Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu.
Linux is like a teepee: no Windows, no Gates and an apache inside...

Bug#986266: Package Review

[SECOB271_Ganesh Pawar]

Thanks.
I have updated the package.
Please have a look again

On Thu, Apr 8, 2021 at 2:00 PM Kyle Robbertze 
wrote:

> Control: tags -1 moreinfo
>
> Thank you for preparing the package. I've noticed a couple things that
> need sorting:
>
> debian/changelog:
>
> * The distribution is 'UNRELEASED' - this should be 'unstable'
> * Urgency should be 'low'
>
> acme/jws.go, acme/jws_test.go:
>
> * the copyright of this file is not listed in debian/copyright - it is
> copyright The Go Authors under a BSD 3-clause licence.
>
> Otherwise it all looks good.
>
> Cheers
> Kyle
> --
> ⢀⣴⠾⠻⢶⣦⠀
> ⣾⠁⢠⠒⠀⣿⡁ Kyle Robbertze
> ⢿⡄⠘⠷⠚⠋⠀ Debian Developer
> ⠈⠳⣄ https://wiki.debian.org/KyleRobbertze
>
>

Bug#986728: upgrade-reports: boot fail until kernel 4.19.0.14

[Lamome Julien]

Package: upgrade-reports
Severity: critical
Justification: breaks the whole system

Dear Maintainer,


   * What led up to the situation?
try to boot on kernel 4.19.0-14 or 4.19.0-16
   * What exactly did you do (or not do) that was effective (or
 ineffective)?
update kernel via aptitude
   * What was the outcome of this action?
   * What outcome did you expect instead?
boot...

The boot fail (freeze, block) just after "initrd" print on screen.
I notice that initrd of kernel ..14 and ..16 are bigger than other.

Thank

-- 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 4.19.0-9-amd64 (SMP w/4 CPU cores)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), LANGUAGE= 
(charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Bug#986727: pexpect: flaky autopkgtest

[Graham Inggs]

Source: pexpect
Version: 4.8.0-1
Severity: serious
X-Debbugs-CC: debian...@lists.debian.org
User: debian...@lists.debian.org
Usertags: flaky

Hi Maintainer

The autopkgtests of pexpect fail regularly and are therefore
unsuitable for regression testing.  I've copied below what I hope is
the relevant part of the log.

There's a comment from upstream regarding this particular failing
test, and it is skipped when running on TRAVIS.  Perhaps this test
should be skipped unconditionally in Debian?

Regards
Graham


[1] https://ci.debian.net/packages/p/pexpect/testing/amd64/


=== FAILURES ===
_ InteractTestCase.test_interact_exit_unicode __

self = 

def test_interact_exit_unicode(self):
" Ensure subprocess receives utf8. "
p = pexpect.spawnu('{self.interact_py} --utf8'.format(self=self),
   timeout=5, env=self.env)
p.expect('READY')
p.send('ɑ')  # >>> map(ord, u'ɑ'.encode('utf8'))
p.expect('201')# [201, 145]
p.expect('145')
p.send('Β')  # >>> map(ord, u'Β'.encode('utf8'))
p.expect('206')# [206, 146]
p.expect('146')
p.send('\x00')
if not os.environ.get('TRAVIS', None):
# on Travis-CI, we sometimes miss trailing stdout from the
# chain of child processes, not entirely sure why. So this
# is skipped on such systems.
>   p.expect('0')

tests/test_interact.py:91:
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
pexpect/spawnbase.py:343: in expect
return self.expect_list(compiled_pattern_list,
pexpect/spawnbase.py:372: in expect_list
return exp.expect_loop(timeout)
pexpect/expect.py:179: in expect_loop
return self.eof(e)
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _

self = 
err = EOF('End Of File (EOF). Exception style platform.')

def eof(self, err=None):
spawn = self.spawn

spawn.before = spawn._before.getvalue()
spawn._buffer = spawn.buffer_type()
spawn._before = spawn.buffer_type()
spawn.after = EOF
index = self.searcher.eof_index
if index >= 0:
spawn.match = EOF
spawn.match_index = index
return index
else:
spawn.match = None
spawn.match_index = None
msg = str(spawn)
msg += '\nsearcher: %s' % self.searcher
if err is not None:
msg = str(err) + '\n' + msg

exc = EOF(msg)
exc.__cause__ = None # in Python 3.x we can use "raise exc
from None"
>   raise exc
E   pexpect.exceptions.EOF: End Of File (EOF). Exception style platform.
E   
E   command: /usr/bin/python3
E   args: [b'/usr/bin/python3', b'interact.py', b'--utf8']
E   buffer (last 100 chars): ''
E   before (last 100 chars): '\r\nEscaped interact\r\n'
E   after: 
E   match: None
E   match_index: None
E   exitstatus: None
E   flag_eof: True
E   pid: 1345
E   child_fd: 18
E   closed: False
E   timeout: 5
E   delimiter: 
E   logfile: None
E   logfile_read: None
E   logfile_send: None
E   maxread: 2000
E   ignorecase: False
E   searchwindowsize: None
E   delaybeforesend: 0.05
E   delayafterclose: 0.1
E   delayafterterminate: 0.1
E   searcher: searcher_re:
E   0: re.compile('0')

pexpect/expect.py:122: EOF
- Captured stdout call -

Bug#986652: libdevmapper1.02.1 should not depend on dmsetup

[Bastian Blank]

Hi Helmut

On Sat, Apr 10, 2021 at 11:41:49AM +0200, Helmut Grohne wrote:
> On Sat, Apr 10, 2021 at 10:34:50AM +0200, Bastian Blank wrote:
> > libdevmapper1.02.1 needs the udev rules, the udev rules need dmsetup,
> > dmsetup needs libdevmapper1.02.1.
> This is technically incorrect on two levels. First, libdevmapper1.02.1
> may need udev rules in order for the functions it provides to work.

Exactly, it requires working udev and udev rules for it's primary
function.  To change that, it either needs
- to be split into two libraries, one with the stuff that needs udev
  rules, one for the stuff without or
- runtime detection if udev can work.

> > There is no way around this.
> As presented, the matter is more nuanced than you think it is.

Maybe.  Please provide a patch to fix this problem, without touching
every piece of software that, directly or indirectly, links against
libdevmapper.

Because the dependency on libdevmapper1.02.1 can only go after systemd
(or maybe libcryptsetup) got it.

Bastian

-- 
"Get back to your stations!"
"We're beaming down to the planet, sir."
-- Kirk and Mr. Leslie, "This Side of Paradise",
   stardate 3417.3

Bug#986726: boxer-data: autopkgtest regressionin testing

[Graham Inggs]

Source: boxer-data
Version: 10.8.20
Severity: serious
X-Debbugs-CC: debian...@lists.debian.org
User: debian...@lists.debian.org
Usertags: regression

Hi Maintainer

The autopkgtest of boxer-data fails in testing where it succeeded in
the past [1].

The current failure seems to be due to the removal of citadel-mta from testing:
E: Unable to locate package citadel-mta

This regression also prevents boxer-data/10.8.21 from migrating to testing.

Regards
Graham


[1] https://ci.debian.net/packages/b/boxer-data/testing/amd64/

Bug#986651: systemd: stop depending on systemd-timesyncd

[Michael Biebl]

Am 08.04.21 um 22:24 schrieb Helmut Grohne:

Package: systemd
Version: 247.3-3
Tags: bookworm sid

systemd used to include systemd-timesyncd. Now it is split out to a
separate binary package. Thanks. However, systemd now depends on
systemd-timesyncd, so we cannot really remove it (unless installing
something like ntp). For containers, having a time-daemon is not useful
and we want to reduce the filesystem as much as possible. Therefore it
would be good to reduce the dependency to Recommends.


A few thoughts.
The disk footprint of systemd-timesyncd is rather small.
It would be good to know which kind of containers your have in mind.
docker-style (minimal) without an init or with a full-blown init like 
lxc (fat)?
The former doesn't have init/systemd installed (and thus no 
systemd-timesyncd), the latter does and systemd itself is much bigger 
disk footprint wise.


If we bump the prio of systemd-timesyncd, those minimal containers will 
now suddenly get systemd-timesyncd by default (which in turn pulls 
systemd). So this would be a regression. You'd have to be careful to 
omit systemd-timesyncd when building the container image.


For fat containers, having systemd-timesyncd installed doesn't really 
gain you a lot (and is no regression compared to buster, where it was 
folded in). Runtime-wise, having systemd-timesyncd installed, is not a 
problem either, as systemd-timesyncd.service has 
ConditionVirtualization=!container



Michael




OpenPGP_signature
Description: OpenPGP digital signature

Bug#986686: missing b-d netpbm?

[Matthias Klose]

On 4/9/21 11:14 PM, Hilmar Preuße wrote:
> Am 09.04.2021 um 15:57 teilte Matthias Klose mit:
> 
> Hi Matthias,
> 
>> On the Ubuntu buildd, the package ftbfs with a missing b-d. Adding netpbm
>> fixes this, although I don't yet see why it doesn't fail on the Debian
>> buildds. netpbm only shows as a Recommends in the Debian
>> build log.
>>
>> https://launchpad.net/ubuntu/+source/texworks-manual/20210308-1/+build/21339493
>>
> On Debian I can convert png to eps files using convert:
> 
> hille@debian-amd64-sid:~$ ls -l replaceDialog.*
> -rw-rw-r-- 1 hille hille 26755 May  7  2015 replaceDialog.png
> hille@debian-amd64-sid:~$ convert replaceDialog.png replaceDialog.eps
> hille@debian-amd64-sid:~$ ls -l replaceDialog.*
> -rw-r--r-- 1 hille hille 774464 Apr  9 23:04 replaceDialog.eps
> -rw-rw-r-- 1 hille hille  26755 May  7  2015 replaceDialog.png
> 
> Doing the same on Ubuntu 20.10 fails:
> 
> ubuntu@ubuntu2010:~$ convert replaceDialog.png replaceDialog.eps
> convert-im6.q16: attempt to perform an operation not allowed by the security
> policy `EPS' @ error/constitute.c/IsCoderAuthorized/408.
> 
> b/c the /etc/ImageMagick-6/policy.xml differs between Debian & Ubuntu.
> 
> The Makefile has a fallback to netpbm, but this does not work as we do not
> declare a B-D on netpbm. We could simply add it.
> 
> What do you think?

yes, that would be nice. Afaics, Ubuntu disabled that explicitly in
https://launchpad.net/ubuntu/+source/imagemagick/8:6.9.10.23+dfsg-2.1ubuntu3

diff at
http://launchpadlibrarian.net/429710949/imagemagick_8%3A6.9.10.23+dfsg-2.1ubuntu2_8%3A6.9.10.23+dfsg-2.1ubuntu3.diff.gz

Matthias

Bug#986625: unblock: grub2/2.04-17

[Cyril Brulebois]

Paul Gevers  (2021-04-08):
> On 08-04-2021 12:25, Colin Watson wrote:
> > Please unblock grub2 2.04-17.  The --sbat fix will be needed for d-i
> > builds once various bits of work on shim are finished, and the verifiers
> > module change helps core images fit in the constrained space that's
> > often all that's available on BIOS systems.

Happy to trust Colin and Steve on such things, please go ahead.


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


signature.asc
Description: PGP signature

Bug#977358: release-notes: document how to make the rescue mode usable if no root password is set (buster)

[Justin B Rye]

Andrei POPESCU wrote:
> Ok, here is something, just to get the discussion started:

Thanks!  My suggestions below still need some work, but I'll call this
my first pass:

> The `rescue` boot option is unusable without a root password.
>
> If a password for the `root` account is not set the system will 
> still ask for the root password if booted with the `rescue` option, 
> effectively making the rescue mode unusable. In order to avoid this
> it is possible to boot using the kernel parameter 
> `init=/sbin/sulogin --force`.

Simplifying:


  The rescue boot option is unusable without a root 
password


  Booting with the rescue option always requires
  the root password. If one has not been set, this makes the rescue
  mode effectively unusable. However it is still possible to boot
  using the kernel parameter init=/sbin/sulogin --force


(I don't think "root" needs special markup; "rescue" only needs it
when we're talking about an untranslatable literal string).

(Should there be some hint here at the fact that this has happened
because we've switched to an implementation of sulogin without the
slightly dodgy Debian-specific patches?)

> To configure pkg:systemd to always to do the equivalent of this on 
   ^^^ ^^^^
When we're talking about machines booting with systemd-sysv, we should
avoid mentioning systemd
(which is a pain to type anyway).

The "to" might go in either position, but not both.  Here perhaps we
might be better off saying

  To configure systemd to do the equivalent of this whenever the
  rescue option is used,

> selecting the `rescue` option add `SYSTEMD_SULOGIN_FORCE=1` to the 
> Environment of the rescue.service unit (see 
> file:/usr/share/doc/systemd/ENVIRONMENT.md.gz). The `rescue.service` 

At least this information is already on my system before the
dist-upgrade.

> unit is started by pkg:systemd in case it detects `single` in the 
 ^^^
> kernel command line (see man:systemd).

Bad use of "in case" - most English-speakers interpret "in case of" as
"unconditionally, to avert the danger of".

systemd(1) defines "single" and "rescue" (and "1"!) as aliases of
"systemd.unit=rescue.target", so maybe we can make that clearer
earlier.


  To configure systemd to do the equivalent of this whenever it
  boots into rescue mode (also known as single mode - see systemd(1)),
  add SYSTEMD_SULOGIN_FORCE=1 to the
  Environment of the rescue.service unit (see
  /usr/share/doc/systemd/ENVIRONMENT.md.gz).


Unfortunately we also need readers to know
 * how to add things to a systemd unit (we don't want people editing
   /lib/systemd/system/rescue.service and losing it in an upgrade)
 * how much of the rest of the file they should copy (as little as
   possible, I think, but how much is that?)
 * how the syntax for multiple items in an Environment= line works

This probably needs an external link, but I'm not optimistic we'll
find one.  Maybe this is another case where we'll need a dedicated
page on wiki.debian.org.

(And why *is* the systemd man page in section 1, anyway?  Shouldn't it
be in section 8, like systemv init used to be?)

> It might be useful to do the same for the `emergency.service` unit 
> (or instead) which is started ''automatically'' in case of certain 
   ^^ ^^
> errors (see man:systemd.special), or if `emergency` is added to the 
> kernel command line (e.g. in case the system can't be recovered by
^^^
> using the `rescue` mode).

"The same or instead" needs to be reorganised as "as well or instead".

One of those "in case"s almost works.

I'm not sure what markup you mean for ''automatically''.


  It might be useful to do this for the emergency.service
  unit (as well or instead), which is started automatically in the case
  of certain errors (see systemd.special(7)),
  or if emergency is added to the kernel command line
  (e.g. if the system can't be recovered by using the rescue mode).


(Why *did* setting these systems up with passwords in the first place
go out of fashion?)
 
> For background and a discussion on the security implications see 
> bts:802211.

I forget if we've got special markup for this or whether we just say


  For background and a discussion on the security implications see 
  https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=802211";>bug
  #802211.


Or even delegate it to the wiki link.  Oh well, buster needed two
last-minute wiki pages for complicated issues, so if bullseye only
needs one for this we'll still be improving...
-- 
JBR with qualifications in linguistics, experience as a Debian
sysadmin, and probably no clue about this particular package

Bug#986725: RFP: jamovi -- jamovi is a free and open statistics package, which is easy to use, and designed to be familiar to users of SPSS. It provides a spreadsheet editor, and a range of statistica

[Erez Shomron]

Package: wnpp
Severity: wishlist
X-Debbugs-Cc: eshoe...@gmail.com

* Package name: jamovi
  Version : 1.6.15
  Upstream Author : Jonathon Love, Damian Dropmann, Ravi Selker, Marcello
Gallucci, Sebastian Jentschke, Serdar Balci
* URL : https://github.com/jamovi/jamovi
* License : AGPL3,GPL2+
  Programming Lang: JavaScript,Python,CSS,C++,R
  Description : jamovi is a free and open statistics package, which is easy
to use, and designed to be familiar to users of SPSS. It provides a spreadsheet
editor, and a range of statistical analyses. jamovi can provide R syntax for
each analysis that is run, and additional analyses for jamovi can be developed
using the R language.

jamovi is very interesting piece of software, which is very useful for students
who want or need to get into statistical analysis. Due to its spreadsheet
editor capabilities it is friendly for users who are new to programming. At the
same time, more code-adept users can take advantage of the R engine jamovi is
based on. The software is intended to be an open source replacement for IBM's
SPSS.
Its goal of replacing SPSS is similar to the `pspp` package, but jamovi, being
based on R, makes it much more powerful.

Homepage: https://www.jamovi.org
Full authors' information: https://www.jamovi.org/about.html

Bug#986652: libdevmapper1.02.1 should not depend on dmsetup

[Helmut Grohne]

Hi Bastian,

On Sat, Apr 10, 2021 at 10:34:50AM +0200, Bastian Blank wrote:
> There is already a bug report about this, merging.

I think there is a subtle difference between these. The old bug is about
a dependency cycle, which presents issues to a package manager. The new
bug is about an excessive dependency which results in issues for
container and embedded images. I do agree that solving the new bug
implicitly solves the old one, but I could imagine solutions to the old
bug that do not solve the new bug. Hence I figured that filing these
separately would make sense. Your preference seems to handle them as
one, which effectively is a scope increase of the old one.

> libdevmapper1.02.1 needs the udev rules, the udev rules need dmsetup,
> dmsetup needs libdevmapper1.02.1.

This is technically incorrect on two levels. First, libdevmapper1.02.1
may need udev rules in order for the functions it provides to work.
Applications may link libdevmapper1.02.1 as to provide an optional
feature however. For them, the shared library is sufficient to run the
application unless they also want to use the optional feature. In the
latter case, they'd have to depend on dmsetup (and udev).

Then, while dmsetup provides the udev rules, it does not depend on udev.
As such, the rules are mere text files without anything to act upon. The
udev rules rightly provide optional integration with udev. Therefore, we
can rule that the present dependency on dmsetup does not provide the
guarantee it is supposed to provide. Even with dmsetup installed (but
udev missing) libdevmapper1.02.1 may not work as the udev rules are not
applied by anything.

> There is no way around this.

As presented, the matter is more nuanced than you think it is.

> Container images don't contain systemd, so no problem.  Embedded systems
> contain udev, so require the udev rules.

This also is technically incorrect. nspawn containers require installing
systemd-container in the container image. While embedded systems usually
contain udev, they do not necessarily need dmsetup.

Helmut

Bug#986724: libc6: pthread_cond_wait missed wakeup

[Костик Покотиленко]

Package: libc6
Version: 2.28-10
Severity: important

Dear Maintainer,

In short, this bug causes condition variable signal
(pthread_cond_signal) to be missed by condition
variable waiters (pthread_cond_wait) in some circumstances. Bug is
introduced in glibc 2.27. There
are few patches to fix this issue, none of them merged at this time.

This bug was reported in great details here:

https://sourceware.org/bugzilla/show_bug.cgi?id=25847

How to reproduce: use the repro from the sourceware report

I confirm that using the repro from sourceware report I was able to
reproduce issue on several Debian 10 machines. In my case It takes
from 20 minutes to few hours to make repro hang. On other hand I was
not able to reproduce issue on Debian 9 machine running repro for 20+
hours.

This bug is also mentioned here:

https://bugs.launchpad.net/ubuntu/+source/glibc/+bug/1899800
https://bugzilla.redhat.com/show_bug.cgi?id=1889892
https://discuss.ocaml.org/t/is-there-a-known-recent-linux-locking-bug-that-affects-the-ocaml-runtime/6542
https://jira.mongodb.org/browse/SERVER-47554
https://probablydance.com/2020/10/31/using-tla-in-the-real-world-to-understand-a-glibc-bug/

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

Kernel: Linux 4.19.0-14-amd64 (SMP w/16 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 /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages libc6 depends on:
ii  libgcc1  1:8.3.0-6

Versions of packages libc6 recommends:
ii  libidn2-0  2.0.5-1+deb10u1

Versions of packages libc6 suggests:
ii  debconf [debconf-2.0]  1.5.71
pn  glibc-doc  
ii  libc-l10n  2.28-10
ii  locales2.28-10

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

Bug#986723: ITP: ruby-omniauth-azure-activedirectory-v2 -- OAuth 2 authentication with the Azure ActiveDirectory V2 API

[Pirate Praveen]

Package: wnpp
Severity: wishlist
Owner: Pirate Praveen 

Packaging of https://rubygems.org/gems/omniauth-azure-activedirectory-v2

Dependency of gitlab 13.10

Bug#986722: RFP: elpa-annotate -- annotate files without changing them

[Martin]

Package: wnpp
Severity: wishlist
X-Debbugs-Cc: debian-emac...@lists.debian.org

* Package name: elpa-annotate
  Version : 1.1.5
  Upstream Author : Bastian Bechtold and contributors
* URL : https://github.com/bastibe/annotate.el
* License : MIT
  Programming Lang: Emacs-Lisp
  Description : annotate files without changing them

This package provides the minor mode annotate-mode, which can add
annotations to arbitrary files without changing the files
themselves. Annotations are saved in the annotate-file
(~/.annotations by default).
 
To add annotations to a file, select a region and hit C-c C-a. The
region will be underlined, and the annotation will be displayed in
the right margin. Annotations are saved whenever the file is saved.
 
Use C-c ] to jump to the next annotation and C-c [ to jump to
the previous annotation. Use M-x annotate-export-annotations to
save annotations as a no-difference diff file.
 
Important note: annotation can not overlaps and newline character
can not be annotated.

Bug#986720: systemd: lvm links missing - udev fails parsing dmsetup splitnames

[Michael Biebl]

Control: tags -1 moreinfo

Hi Sam

Am 09.04.2021 um 15:40 schrieb Sam Eiderman:
The problem is that systemd/udev fails collecting the output of "dmsetup 
splitnames".


This bug was also mentioned here:

https://github.com/systemd/systemd/issues/18190

After I build systemd v248 from source - the problem goes away.

Probably a backport is needed.


I guess for v247 in bullseye, we might consider that.
Can you test if applying 
https://github.com/systemd/systemd/pull/18976/commits/238d7efec627f9dc1d52538251c6e3d158d512ae
on top of the Debian package as available in testing fixes the issue as 
well?


Regards,
Michael

Bug#986652: libdevmapper1.02.1 should not depend on dmsetup

[Bastian Blank]

Control: reassign -1 dmsetup
Control: forcemerge 586424 -1

There is already a bug report about this, merging.

On Thu, Apr 08, 2021 at 10:54:05PM +0200, Helmut Grohne wrote:
> However, shared libraries should not depend on tools. The higher level
> users of libraries should have these dependencies. In this case,
> libdevmapper1.02.1 does not actually need a matching dmsetup to be
> useable. It should prevent installing a dmsetup of a different version
> though. The correct relationship for achieving that is Breaks.

libdevmapper1.02.1 needs the udev rules, the udev rules need dmsetup,
dmsetup needs libdevmapper1.02.1.

There is no way around this.

> This has practical relevance. systemd depends on libcryptsetup12, which
> depends on libdevmapper1.02.1, which depends on dmsetup. Therefore
> systemd always pulls dmsetup. This is undesirable for embedded systems
> and container images.

Container images don't contain systemd, so no problem.  Embedded systems
contain udev, so require the udev rules.

Bastian

-- 
Oblivion together does not frighten me, beloved.
-- Thalassa (in Anne Mulhall's body), "Return to Tomorrow",
   stardate 4770.3.

Bug#986721: live-boot: Failed to unmount /run/live/medium: Device or resource busy - which might corrupt live USB sticks

[Steven Shiau]

Package: live-boot
Version: 1:20210208
Severity: important

Dear Maintainer,

   * What led up to the situation?
 When rebooting or halting the Debian live system, it gives these
error messages:
 Failed to unmount /run/live/medium: Device or resource busy
 systemd-shutdown[1]: Could not detach loopback /dev/loop0: Device
or resource busy
 systemd-shutdown[1]: Failed to finalize file systems, loop devices,
ignoring.

 This error might corrupt the file system on the live USB flash drive.
 It been reported on different forums:
 https://github.com/systemd/systemd/issues/17988
 https://github.com/grml/grml/issues/109
 https://github.com/grml/grml/issues/150
 https://github.com/systemd/systemd/issues/2814

 System developers mentioned: "isn't the simpler and better fix to
change debian to not set things up that way? Specifically, why expose
the "components" of the overlayfs at all? why not just leave them
outside the tree when pivotting into the overlayfs?"

 This issue is not solved yet in live-boot 1:20210208. Is any
workaround we can try to avoid this?
 Thank you very much.

-- Package-specific info:

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

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

Versions of packages live-boot depends on:
ii  live-boot-initramfs-tools [live-boot-backend]  1:20210208.drbl2

Versions of packages live-boot recommends:
ii  live-boot-doc  1:20210208
ii  live-tools 1:20190831
ii  rsync  3.2.3-4
ii  uuid-runtime   2.36.1-7

Versions of packages live-boot suggests:
pn  cryptsetup  
pn  curlftpfs   
pn  httpfs2 
ii  wget    1.21-1+b1

-- no debconf information


-- 
Steven Shiau 
Public Key Server PGP Key ID: 4096R/163E3FB0
Fingerprint: EB1D D5BF 6F88 820B BCF5  356C 8E94 C9CD 163E 3FB0

Bug#986719: fdroidserver: should not depend on (python3-)vagrant

[Felix C. Stegerman]

Package: fdroidserver
Version: 2.0.1-1
Severity: normal
X-Debbugs-Cc: f...@obfusk.net

Hi!

Currently, fdroidserver Depends: on python3-vagrant which in turn
Depends: on vagrant itself.  Since fdroidserver has many use cases
that don't require vagrant, I think it would be better to downgrade
that to a Recommends: or Suggests:

Thanks.

- Felix

Bug#986716: installation-guide: Preseeding passwd/root-password-crypted with "!" doesn't work as described

[David Mandelberg]

Source: installation-guide
Severity: normal
Tags: d-i

Hi,

https://www.debian.org/releases/bullseye/amd64/apbs04.en.html section
B.4.5 talks about using "!" in passwd/root-password-crypted:

The passwd/root-password-crypted and passwd/user-password-crypted
variables can also be preseeded with "!" as their value. In that case,
the corresponding account is disabled. This may be convenient for the
root account, provided of course that an alternative method is set up
to allow administrative activities or root login (for instance by
using SSH key authentication or sudo).


When I tried that, it didn't seem to have any effect. From looking at
what I think is the relevant code[0], it looks like a value of "!" in
passwd/root-password-crypted is explicitly ignored. Is there a
recommended way to lock the root password without setting up another
user? (I want to set up ssh public key authentication for root, and no
other way to authenticate.)

 [0] 
https://salsa.debian.org/installer-team/user-setup/-/blob/597e5e6c52d11f0de8e084b274c00c944c632f84/user-setup-ask#L34-43



-- System Information:
Debian Release: bullseye/sid
  APT prefers testing
  APT policy: (990, 'testing'), (500, 'testing-security'), (100, 
'unstable')

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=nl_US.UTF-8@dseomn, LC_CTYPE=nl_US.UTF-8@dseomn 
(charmap=ANSI_X3.4-1968) (ignored: LC_ALL set to C), 
LANGUAGE=nl_US@dseomn:nl_NL:nl_BE:nl:en_US:en

Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled