Bug#993949: dnscrypt-proxy fails to use address from DoH servers on start-up, resorts to system resolver

[Eric Dorland]

Control: forwarded -1 https://github.com/DNSCrypt/dnscrypt-proxy/issues/1861

Thanks for the report. I've marked it forwarded upstream, and the fix
appears to be in
https://github.com/DNSCrypt/dnscrypt-proxy/commit/0f00cd27f92cee434336c6d6cde9df26286d8dbe.
 Do
you think this is serious enough to warrant cherrypicking into the
package or should we just wait for the next upstream release?

* Danny van Heumen (da...@dannyvanheumen.nl) wrote:
> Package: dnscrypt-proxy
> Version: 2.0.45+ds1-1+b5
> Severity: normal
> X-Debbugs-Cc: da...@dannyvanheumen.nl
> 
> Dear Maintainer,
> 
> A bug was recently found where DNS stamp information is used
> incorrectly to fill the resolver cache on initialization.
> 
> In short, DNS stamps of the various DNSCrypt/DoH/etc. resolvers include
> hostname and port information for finding the server. Additionally, it
> (optionally) includes an IPv4/IPv6 address to find the server without
> nameserver resolution for bootstrapping/initialization purposes, in such
> cases where it is unreliable or unavailable.
> 
> dnscrypt-proxy intends to use this address in all cases - caching the
> address with unlimited lifetime, but accidentally stored it with incorrect
> key "hostname with optional port number". Subsequently loading from a key
> "hostname" will fail to load the address from the cache.
> 
> Consequently, in all cases of DoH servers that include a port number,
> the bootstrapping address could not be loaded and dnscrypt-proxy needs to
> rely on the system resolver to look up the address anyways.
> 
> The details can be found in
> https://github.com/DNSCrypt/dnscrypt-proxy/issues/1861
> and a side-effect was under discussion at
> https://github.com/DNSCrypt/dnscrypt-proxy/discussions/1828
> 
> It is beneficial to use the DNS stamp information both for speed and
> reliability of resolution.
> 
> Kind regards,
> Danny
> 
> 
> PS: I am not familiar with bug reporting or bug handling in Debian. Please
> let me know if I should do things differently. I may be able to help if
> you want to cherry-pick the bugfix from upstream. (Although I am not
> affiliated with the project in any way.)
> 
> 
> -- System Information:
> Debian Release: 11.0
>   APT prefers stable-security
>   APT policy: (500, 'stable-security'), (500, 'stable')
> Architecture: amd64 (x86_64)
> 
> Kernel: Linux 5.10.0-8-amd64 (SMP w/4 CPU threads)
> Kernel taint flags: TAINT_USER
> Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
> LANGUAGE=en_US:en
> Shell: /bin/sh linked to /usr/bin/dash
> Init: systemd (via /run/systemd/system)
> LSM: AppArmor: enabled
> 
> Versions of packages dnscrypt-proxy depends on:
> ii  adduser   3.118
> ii  libc6 2.31-13
> ii  lsb-base  11.1.0
> 
> dnscrypt-proxy recommends no packages.
> 
> Versions of packages dnscrypt-proxy suggests:
> pn  resolvconf  
> 
> -- Configuration Files:
> /etc/dnscrypt-proxy/dnscrypt-proxy.toml changed [not included]
> 
> -- no debconf information

-- 
Eric Dorland 
43CF 1228 F726 FD5B 474C  E962 C256 FBD5 0022 1E93


signature.asc
Description: PGP signature

Bug#991673: Update on promod3 packaging

[Andrius Merkys]

Hello,

The packaging of promod3 is almost ready. Two issues remain:

1. Executable name clash on /usr/bin/pm with powerman package;

2. Need to have components.cif.gz provided by some package [1] and
transformed by openstructure into format needed by promod3.

I will talk to the upstream about both these issues as it would be best
to solve them upstream.

[1] https://lists.debian.org/debian-med/2021/09/msg9.html

Andrius

Bug#992034: installation-guide: Include a note on how to change init system during install

[Holger Wansing]

Hi,

Justin B Rye  wrote (Thu, 9 Sep 2021 21:52:44 +0100):
> > So, I tend to go with a 6.5 section like
> > 
> >+ 
> >+ Customization
> >+ 
> >+ The installation process can be further customized to fit your needs:
> >+ 
> > 
> > What do you think?
> 
> It might work.  Then it goes on:
> 
>   Installing an alternative init system
>
>  uses systemd as its default init system. However, other
> init systems (such as sysvinit and OpenRC) are supported, and the
> easiest time to select an alternative init system is during the
> installation process. For detailed instructions on how to do so,
> please see the
>  url="https://wiki.debian.org/Init#Changing_the_init_system_-_at_installation_time;>Init
> page on the Debian wiki.
>
>   
>  
> 
> Hmm.  That may have been boiled down *too* far, since there's no
> hint that it works by going to a shell.  So maybe that should have
> been in the intro?  (Sorry, can't remember the ulink syntax)
> 
>   As well as troubleshooting, the [[6.3.9.2|link]] also allows
>   further customization of the installation process to fit your
>   needs:
> 
> People might also want some echo of the Troubleshooting section's
> cautionary note wedged in there; the minimal version would be to say
> something like "careful customization" and/or "in exceptional cases".

Trying to integrate your suggestions, would then have



+ 
+ Customization
+ 
+ Using the shell (see ), the installation process
+ can be carefully customized, to fit exceptional use cases:
+ 
+ 
+   Installing an alternative init system
+ 
+  uses systemd as its default init system. However, other init
+ systems (such as sysvinit and OpenRC) are supported, and the
+ easiest time to select an alternative init system is during the
+ installation process. For detailed instructions on how to do so,
+ please see the https://wiki.debian.org/Init#Changing_the_init_system_-_at_installation_time;>Init
+ page on the Debian wiki.
+ 
+ 
+   
+  



Comments?

Holger


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

Bug#978832: gupnp-av: diff for NMU version 0.12.11-2.1

[Boyuan Yang]

Control: tags 978832 + patch
Control: tags 978832 + pending

Dear maintainer,

I've prepared an NMU for gupnp-av (versioned as 0.12.11-2.1) and
uploaded it to DELAYED/3. Please feel free to tell me if I
should delay it longer.

Regards.

diff -Nru gupnp-av-0.12.11/debian/changelog gupnp-av-0.12.11/debian/changelog
--- gupnp-av-0.12.11/debian/changelog   2018-12-26 14:09:48.0 -0500
+++ gupnp-av-0.12.11/debian/changelog   2021-09-09 23:56:58.0 -0400
@@ -1,3 +1,11 @@
+gupnp-av (0.12.11-2.1) unstable; urgency=high
+
+  * Non-maintainer upload.
+  * debian/control{,in}: Add missing build-dependency gtk-doc-tools.
+(Closes: #978832)
+
+ -- Boyuan Yang   Thu, 09 Sep 2021 23:56:58 -0400
+
 gupnp-av (0.12.11-2) unstable; urgency=medium
 
   * Add -Wl,-O1 to our LDFLAGS
diff -Nru gupnp-av-0.12.11/debian/control gupnp-av-0.12.11/debian/control
--- gupnp-av-0.12.11/debian/control 2018-12-26 14:09:48.0 -0500
+++ gupnp-av-0.12.11/debian/control 2021-09-09 23:56:58.0 -0400
@@ -9,6 +9,7 @@
 Uploaders: Jeremy Bicha 
 Build-Depends: debhelper (>= 11),
gnome-pkg-tools,
+   gtk-doc-tools,
libglib2.0-dev (>= 2.38),
libsoup2.4-dev (>= 2.34.0-1~),
valac (>= 0.22),
diff -Nru gupnp-av-0.12.11/debian/control.in gupnp-av-
0.12.11/debian/control.in
--- gupnp-av-0.12.11/debian/control.in  2018-12-26 14:09:48.0 -0500
+++ gupnp-av-0.12.11/debian/control.in  2021-09-09 23:56:45.0 -0400
@@ -5,6 +5,7 @@
 Uploaders: @GNOME_TEAM@
 Build-Depends: debhelper (>= 11),
gnome-pkg-tools,
+   gtk-doc-tools,
libglib2.0-dev (>= 2.38),
libsoup2.4-dev (>= 2.34.0-1~),
valac (>= 0.22),


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

Bug#992796: dpkg-gensymbols should ignore version script tag symbols

[Guillem Jover]

Control: tag -1 moreinfo

Hi!

On Mon, 2021-08-23 at 17:59:48 +0300, Raul Tambre wrote:
> Package: dpkg-dev
> Version: 1.20.9
> Severity: normal

> GNU ld generates a nullptr absolute symbol for each version script tag.
> test.sym:
> 
> LIBTEST_1
> {
> };
> 
> clang -shared /dev/null -o example.so -Wl,--version-script=test.sym 
> -fuse-ld=ld
> llvm-nm -D example.so:
> 
>  A LIBTEST_1@@LIBTEST_1
>  w _ITM_deregisterTMCloneTable
>  w _ITM_registerTMCloneTable
>  w __cxa_finalize
>  w __gmon_start__
> 
> LLVM's LLD (i.e. -fuse-ld=lld) does not.
> Many existing packages' symbols files however expect such symbols (e.g. 
> systemd).
> This makes building them cleanly with LLD not possible.
> 
> Rather than considering this a bug in LLD I think it would be more reasonable 
> to
> fix this in dpkg because they're simply noise.

Why? I'm afraid I don't see an underlying rationale for this here. :)

> 1. They are nullpointers and thus don't have any actual underlying 
> implementation.
> 2. If they disappear, the whole section will have been deleted, so certainly 
> other
>symbols will have also gone missing.

Sometimes you might have empty version nodes.

> I tried reading the binutils code for half an hour to understand where in the 
> code
> and why they're being generated, but had no luck.

Well, from the binutils code, if I'm not reading the location
incorrectly, this really seems to be on purpose, and as such my worry
is that removing these from symbols files could cause ABI issues?

  


And reading something like:

  

gives the impression this is not implemented in lld, because the
reason for it in binutils is not understood?

Before even considering applying something like this, the above would
need to be clarified with GNU binutils maintainers. And either that
deemed redundant (which I doubt) and to stop emitting them, or for LLD
to start emitting them for compatibility with GNU ld and gold.

Thanks,
Guillem

Bug#994028: cryptsetup: manpage improvements

[Christoph Anton Mitterer]

Package: cryptsetup
Version: 2:2.4.0-1
Severity: wishlist


Hi.

I think the following might be improved in the crypttab(5) manpage:

1) discard
Apart from the fact that I think it's a pretty bad idea to enable
this per default (security wise, and especially since more recent
SSD allegedly no longer benefit so much from TRIM, if at all)...

It should be made more clear, that the installer simply adds the option
to crypttab (and there is no hidden changed default in Debian's
cryptsetup binary).
Perhaps if you just add a sentence, that it's enough to remove the
flag from crypttab if someone doesn't want it?



2) For options like check= or tmp= my understanding is
that if one just adds "tmp" or "check", then and only then it's enabled
with the mentioned default (e.g "ext4" and blkid).

It should be made more clear that the default is only about the *value*
if no = is given, and not about the flag itself.
I.e. "tmp" means actually "tmp=ext4" but no "tmp" at all, doesn't mean
that "tmp" is implicitly set to "ext4".



3) loud
"Be loud. Print warnings if a device does not exist. This option overwrites the 
option loud."
=> should probably read that it overwrites "quiet"?



4) keyscript=
   WARNING: With systemd as init system, this option might be ignored.
   At the time this is written (December 2016), the systemd cryptsetup
   helper doesn't support the keyscript option to /etc/crypttab. For
   the time being, the only option to use keyscripts along with
   systemd is to force processing of the corresponding crypto devices
   in the initramfs. See the 'initramfs' option for further
   information.

Not sure but that seems a bit misleading:
Even *with* systemd that option is not ignored, at least not by e.g. the 
cryptsetup
package and it's tools itself.
So I can just happily use my own keyscript *outside of the initramfs* with e.g.
cryptdisk_st* .

What does not work is systemd's own cryptsetup support stuff.

It may make sense to advise people that there is the 'luks.crypttab=no'
kernel command line option, as described in systemd-cryptsetup-generator(8),
which causes systemd to ignore any device configured in /etc/crypttab:
   luks.crypttab=, rd.luks.crypttab=
   Takes a boolean argument. Defaults to "yes". If "no", causes the
   generator to ignore any devices configured in /etc/crypttab
   (luks.uuid= will still work however).  rd.luks.crypttab= is honored
   only by initial RAM disk (initrd) while luks.crypttab= is honored
   by both the main system and the initrd.


Cheers,
Chris.

Bug#994026: xkb-data: breaks Multi_key, a.k.a. Compose key

[Vincent Lefevre]

Package: xkb-data
Version: 2.33-1
Severity: important

The upgrade from 2.29-2 to 2.33-1 silently breaks Multi_key.

A diff of the xkbcomp dump gives in particular:

 key  {
-type= "TWO_LEVEL",
-symbols[Group1]= [ ISO_Level3_Shift,   Multi_key ]
+type= "ONE_LEVEL",
+symbols[Group1]= [ ISO_Level3_Shift ]
 };

i.e. Multi_key is no longer there.

Note: I use the gb keyboard layout.

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

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

-- no debconf information

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

Bug#993948: kernel/amd64: system hang on HPE ProLiant BL460c Gen9

[YunQiang Su]

Yunqiang Su  于2021年9月9日周四 上午11:11写道：
>
>
> On Wed, 8 Sep 2021 20:53:27 +0800 YunQiang Su  wrote:
> > Package: src:linux
> > Version: 5.10
> >
> > After upgrade to bullseyes' kernel, the system always hang after about 10 
> > min
> > with an error from IML log
> >
> > An Unrecoverable System Error (NMI) has occurred (Service Information:
> > 0x0008, 0x8948)
> >
> > Kernel 5.14 from experimental also has this problem.
> > Kernel 4.19 works fine.
> > Fedora 34 seems to be working well.
>
> This is the output of dmesg and lspci from both Fedora 34 and Debian bullseye.
> Wish they are useful.
>

Finally, we find the problem:

https://github.com/torvalds/linux/commit/8343b1f8b97ac016150c8303f95b63b20b98edf8
https://github.com/torvalds/linux/commit/65161c35554f7135e6656b3df1ce2c500ca0bdcf

In the first patch:
   They thought `err' is not used at all, and removed it.
In the second patch:
   They add it back and a wrong value "-EINVAL" is given.

Better KPI got.

> >
> > --
> > YunQiang Su
> >
> >



-- 
YunQiang Su

Bug#983578: stterm: defaul variable for TERM didn't appear to work by default

[Richard]

Package: stterm
Version: 0.8.4-1
Followup-For: Bug #983578
X-Debbugs-Cc: arfisna...@mailnesia.com

Dear Maintainer,

Oops, forgot to mention that it happens locally, and not remotely via something
like ssh.

Thanks

Kernel: Linux 5.10.0-8-amd64 (SMP w/1 CPU thread)
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)

Versions of packages stterm depends on:
ii  libc6   2.31-13
ii  libfontconfig1  2.13.1-4.2
ii  libx11-62:1.7.2-1
ii  libxft2 2.3.2-2
ii  ncurses-term6.2+20201114-2

stterm recommends no packages.

stterm suggests no packages.

Bug#929641: xdesktopwaves: diff for NMU version 1.3-4.1

[Boyuan Yang]

Control: tags 929641 + pending

Dear maintainer,

I've prepared an NMU for xdesktopwaves (versioned as 1.3-4.1) and
uploaded it to DELAYED/15. Please feel free to tell me if I
should delay it longer.

Regards,
Boyuan Yang

diff -Nru xdesktopwaves-1.3/debian/changelog xdesktopwaves-
1.3/debian/changelog
--- xdesktopwaves-1.3/debian/changelog  2012-11-27 03:50:31.0 -0500
+++ xdesktopwaves-1.3/debian/changelog  2021-09-09 20:47:38.0 -0400
@@ -1,3 +1,24 @@
+xdesktopwaves (1.3-4.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * debian/source/options: Dropped, prefer default option.
+  * debian/control:
++ Bump debhelper compat to v13.
++ Bump Standards-Version to 4.6.0.
++ Add Vcs-* fields for git packaging repo under
+  Debian Salsa GitLab.
++ Enable "Rules-Requires-Root: no".
+  * debian/xdesktopwaves.menu: Dropped per tech-ctte's decision.
+  * debian/xdesktopwaves*.desktop: Drop obsolete Encoding field.
+  * debian/patches/makefile.patch: Dropped in favor of autotools
+as buildsystem.
+  * debian/patches/0002-use-autotools.patch: Use autotools as
+buildsystem to avoid all kinds of problems.
+  * debian/rules: Use dh sequencer.
++ Fixes FTCBFS. (Closes: #929641)
+
+ -- Boyuan Yang   Thu, 09 Sep 2021 20:47:38 -0400
+
 xdesktopwaves (1.3-4) unstable; urgency=low
 
   * Using source package format "3.0 (quilt)"
@@ -40,4 +61,3 @@
   * Initial Debian version.
 
  -- Miriam Ruiz   Wed,  8 Dec 2004 19:46:34 +0100
-
diff -Nru xdesktopwaves-1.3/debian/compat xdesktopwaves-1.3/debian/compat
--- xdesktopwaves-1.3/debian/compat 2012-11-23 09:41:42.0 -0500
+++ xdesktopwaves-1.3/debian/compat 1969-12-31 19:00:00.0 -0500
@@ -1 +0,0 @@
-9
diff -Nru xdesktopwaves-1.3/debian/control xdesktopwaves-1.3/debian/control
--- xdesktopwaves-1.3/debian/control2012-11-23 09:41:22.0 -0500
+++ xdesktopwaves-1.3/debian/control2021-09-09 20:46:43.0 -0400
@@ -2,10 +2,13 @@
 Section: games
 Priority: optional
 Maintainer: Miriam Ruiz 
-Build-Depends: debhelper (>= 9), quilt, libx11-dev,
+Build-Depends: debhelper-compat (= 13), libx11-dev,
  x11proto-core-dev, x11proto-xext-dev, libxext-dev
-Standards-Version: 3.9.3
+Standards-Version: 4.6.0
+Rules-Requires-Root: no
 Homepage: http://xdesktopwaves.sourceforge.net/
+Vcs-Git: https://salsa.debian.org/debian/xdesktopwaves.git
+Vcs-Browser: https://salsa.debian.org/debian/xdesktopwaves
 
 Package: xdesktopwaves
 Architecture: any
diff -Nru xdesktopwaves-1.3/debian/patches/0002-use-autotools.patch
xdesktopwaves-1.3/debian/patches/0002-use-autotools.patch
--- xdesktopwaves-1.3/debian/patches/0002-use-autotools.patch   1969-12-31
19:00:00.0 -0500
+++ xdesktopwaves-1.3/debian/patches/0002-use-autotools.patch   2021-09-09
20:41:01.0 -0400
@@ -0,0 +1,63 @@
+From: Boyuan Yang 
+Date: Thu, 9 Sep 2021 20:40:56 -0400
+Subject: use autotools
+
+---
+ Makefile.am  | 10 ++
+ configure.ac | 30 ++
+ 2 files changed, 40 insertions(+)
+ create mode 100644 Makefile.am
+ create mode 100644 configure.ac
+
+diff --git a/Makefile.am b/Makefile.am
+new file mode 100644
+index 000..4b04474
+--- /dev/null
 b/Makefile.am
+@@ -0,0 +1,10 @@
++gamesdir = $(prefix)/games
++games_PROGRAMS = xdesktopwaves
++
++xdesktopwaves_SOURCES = xdesktopwaves.c
++xdesktopwaves_CPPFLAGS = -DXDW_MAX_OPTIMIZATION=2
++
++dist_man_MANS = xdesktopwaves.1
++
++pixmapsdir = $(datadir)/pixmaps/
++pixmaps_DATA = xdesktopwaves.xpm
+diff --git a/configure.ac b/configure.ac
+new file mode 100644
+index 000..10010f1
+--- /dev/null
 b/configure.ac
+@@ -0,0 +1,30 @@
++#   -*- Autoconf -*-
++# Process this file with autoconf to produce a configure script.
++
++AC_PREREQ([2.69])
++AC_INIT([xdesktopwaves], [1.3], [xdesktopwaves.sourceforge.net])
++AC_CONFIG_SRCDIR([xdesktopwaves.c])
++AC_CONFIG_HEADERS([config.h])
++AM_INIT_AUTOMAKE([foreign])
++
++# Checks for programs.
++AC_PROG_CC
++AC_PROG_INSTALL
++
++# Checks for libraries.
++AC_CHECK_LIB([X11], [XOpenDisplay])
++AC_CHECK_LIB([Xext], [XextCreateExtension])
++AC_CHECK_LIB([m], [sin])
++
++# Checks for header files.
++AC_PATH_X
++AC_CHECK_HEADERS([unistd.h])
++
++# Checks for typedefs, structures, and compiler characteristics.
++
++# Checks for library functions.
++AC_FUNC_MALLOC
++AC_CHECK_FUNCS([memset sqrt strerror])
++
++AC_CONFIG_FILES([Makefile])
++AC_OUTPUT
diff -Nru xdesktopwaves-1.3/debian/patches/makefile.patch xdesktopwaves-
1.3/debian/patches/makefile.patch
--- xdesktopwaves-1.3/debian/patches/makefile.patch 2012-11-23
09:37:15.0 -0500
+++ xdesktopwaves-1.3/debian/patches/makefile.patch 1969-12-31
19:00:00.0 -0500
@@ -1,47 +0,0 @@
 xdesktopwaves-1.3.orig/Makefile
-+++ xdesktopwaves-1.3/Makefile
-@@ -22,11 +22,20 @@
- 
- # Installer configuration
==
- 
--BINDIR  = /usr/X11R6/bin
--MAN1DIR = 

Bug#994025: cyrus-common 3.4.2-1 fails to configure due to "unknown type of DB: SYNC_CACHE" on upgrade-db

[David Caldwell]

Package: cyrus-common
Version: 3.4.2-1
Severity: important

Dear Maintainer,

I'm getting this error after upgrading to 3.4.2-1

  $ sudo dpkg --configure --pending
  Setting up cyrus-common (3.4.2-1) ...
  Creating/updating cyrus user account...
  The user `cyrus' is already a member of `sasl'.
  /usr/lib/cyrus/bin/upgrade-db: Unknown type of DB: SYNC_CACHE
  dpkg: error processing package cyrus-common (--configure):
   installed cyrus-common package post-installation script subprocess returned 
error exit status 1

It looks like "SYNC_CACHE" is missing from the case statement in the
upgradealldb() function in /usr/lib/cyrus/bin/upgrade-db which is
causing the error I'm seeing. They are listed in 
/usr/lib/cyrus/cyrus-db-types.{txt,active}:

  $ grep SYNC_CACHE /usr/lib/cyrus/cyrus-db-types.txt 
/usr/lib/cyrus/cyrus-db-types.active
  /usr/lib/cyrus/cyrus-db-types.txt:SYNC_CACHE twoskip
  /usr/lib/cyrus/cyrus-db-types.active:SYNC_CACHE twoskip

Thanks,
  David



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

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

Versions of packages cyrus-common depends on:
ii  adduser  3.118
ii  db-upgrade-util  5.3.1+nmu1
ii  db-util  5.3.1+nmu1
ii  debconf [debconf-2.0]1.5.77
ii  e2fsprogs1.46.4-1
ii  gawk 1:5.1.0-1
ii  init-system-helpers  1.60
ii  libc62.31-17
ii  libclamav9   0.103.3+dfsg-1+b1
ii  libcom-err2  1.46.4-1
ii  libgcc-s111.2.0-4
ii  libical3 3.0.10-1
ii  libicu67 67.1-7
ii  libjansson4  2.13.1-1.1
ii  libkrb5-31.18.3-7
ii  libldap-2.4-22.4.59+dfsg-1
ii  libpcre3 2:8.39-13
ii  libpq5   13.4-3
ii  libsasl2-2   2.1.27+dfsg-2.1
ii  libsasl2-modules 2.1.27+dfsg-2.1
ii  libsqlite3-0 3.36.0-2
ii  libssl1.11.1.1l-1
ii  libstdc++6   11.2.0-4
ii  libwrap0 7.6.q-31
ii  libxapian30  1.4.18-3
ii  libxml2  2.9.10+dfsg-6.7
ii  libzephyr4   3.1.2-1+b3
ii  lsb-base 11.1.0
ii  netbase  6.3
ii  perl 5.32.1-5
ii  sendmail-bin [mail-transport-agent]  8.15.2-23
ii  zlib1g   1:1.2.11.dfsg-2

Versions of packages cyrus-common recommends:
iu  cyrus-admin  3.4.2-1
ii  cyrus-imapd  3.4.2-1

Versions of packages cyrus-common suggests:
ii  apt-listchanges3.24
iu  cyrus-admin3.4.2-1
pn  cyrus-caldav   
iu  cyrus-clients  3.4.2-1
ii  cyrus-doc  3.4.2-1
ii  cyrus-imapd3.4.2-1
pn  cyrus-murder   
pn  cyrus-nntpd
pn  cyrus-pop3d
pn  cyrus-replication  
ii  sasl2-bin  2.1.27+dfsg-2.1

-- Configuration Files:
/etc/cyrus.conf changed [not included]
/etc/imapd.conf changed [not included]

-- debconf information excluded

Bug#994023: buster-pu: package espeak-ng/1.49.2+dfsg-8+deb10u1

[Samuel Thibault]

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

Hello,

This is actually like #971944, but for espeak-ng (which is a newer
version of espeak that will eventually supersede it). Normally I
would have submitted them at the same time but it seems I missed doing
it.

[ Reason ]
Espeak-ng cannot drive the mbrola-fr4 speech synthesis voice if the
mbrola-fr1 package is not installed. This is because some of the mb-fr4
espeak rules refer to the fr1 voice while they should be referring to
the fr4 voice. This was fixed some time ago in the newer espeak-ng
package, but the fix was not backported yet to buster.

[ Impact ]
This was not a regression over previous distributions, but it's hard for
users to guess that espeak+mbrola-fr4 cannot work without the mbrola-fr1
package, I actually got hit by the issue in october 2020 and it took
me some time to realize the problem, even though I'm maintaining the
packages.

[ Tests ]
After installing speech-dispatcher, espeak-ng, and mbrola-fr4, but not
mbrola-fr1,

spd-say -O espeak-ng-mbrola-generic Bonjour

should be speaking "Bonjour"

I have just tested it in a buster chroot.

[ Risks ]
The change is trivial, as attached. It is already tested as working in
unstable and stable.

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

[ Changes ]
They simply fix the fr1 reference into fr4.

Yes, the remaining reference to fr1_phtrans is on purpose, it is part of
the confusion between mbrola-fr1 and mbrola-fr4: fr1_phtrans is provided
by espeak-ng-data for both mbrola-fr1 and mbrola-fr4, it was actually
renamed to fr_phtrans in latest espeak-ng-data.
diff -Nru espeak-ng-1.49.2+dfsg/debian/changelog 
espeak-ng-1.49.2+dfsg/debian/changelog
--- espeak-ng-1.49.2+dfsg/debian/changelog  2018-11-14 00:01:43.0 
+0100
+++ espeak-ng-1.49.2+dfsg/debian/changelog  2021-09-10 01:34:50.0 
+0200
@@ -1,3 +1,10 @@
+espeak-ng (1.49.2+dfsg-8+deb10u1) buster; urgency=medium
+
+  * patches/mbrola-fr4: Fix using espeak with mbrola-fr4 when mbrola-fr1 is
+not installed.
+
+ -- Samuel Thibault   Fri, 10 Sep 2021 01:34:50 +0200
+
 espeak-ng (1.49.2+dfsg-8) unstable; urgency=medium
 
   * patches/fix-cancel: Do not open audio when audio speak mode is not
diff -Nru espeak-ng-1.49.2+dfsg/debian/patches/mbrola-fr4 
espeak-ng-1.49.2+dfsg/debian/patches/mbrola-fr4
--- espeak-ng-1.49.2+dfsg/debian/patches/mbrola-fr4 1970-01-01 
01:00:00.0 +0100
+++ espeak-ng-1.49.2+dfsg/debian/patches/mbrola-fr4 2021-09-10 
01:34:34.0 +0200
@@ -0,0 +1,22 @@
+diff --git a/espeak-ng-data/voices/mb/mb-fr4 b/espeak-ng-data/voices/mb/mb-fr4
+index 8e3c392..6e459cc 100755
+--- a/espeak-ng-data/voices/mb/mb-fr4
 b/espeak-ng-data/voices/mb/mb-fr4
+@@ -5,5 +5,5 @@ gender female
+ dictrules 1
+ pitch 140 220
+ voicing 90
+-mbrola fr1 fr1_phtrans
++mbrola fr4 fr1_phtrans
+ 
+diff --git a/espeak-ng-data/voices/mb/mb-fr4-en 
b/espeak-ng-data/voices/mb/mb-fr4-en
+index 8126770..33817e5 100755
+--- a/espeak-ng-data/voices/mb/mb-fr4-en
 b/espeak-ng-data/voices/mb/mb-fr4-en
+@@ -5,5 +5,5 @@ gender female
+ dictrules 1
+ pitch 140 220
+ voicing 90
+-mbrola fr1 fr1_phtrans
++mbrola fr4 fr1_phtrans
+ 
diff -Nru espeak-ng-1.49.2+dfsg/debian/patches/series 
espeak-ng-1.49.2+dfsg/debian/patches/series
--- espeak-ng-1.49.2+dfsg/debian/patches/series 2018-11-13 01:17:49.0 
+0100
+++ espeak-ng-1.49.2+dfsg/debian/patches/series 2021-09-10 01:34:34.0 
+0200
@@ -6,3 +6,4 @@
 privacy
 lessgreat-punct
 nocancel
+mbrola-fr4

Bug#994022: bullseye-pu: package java-atk-wrapper/0.38.0-2+deb11u1

[Samuel Thibault]

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

(this is the same content as for the buster update request for the same
package)

[ Reason ]
As reported on
https://lists.debian.org/debian-accessibility/2021/06/msg3.html
when from an Xorg sesssion one runs

systemctl lightdm restart

which thus restarts the X server, or when for some reason the X session
crashes and the user is back at the lightdm login screen, after logging
back in the java applications are not accessible with the Orca screen
reader.

This is because the user's dbus session bus survives the restart/crash,
which is on purpose as discussed in 
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=992990
and thus the accessibility at-spi stack survives the restart/crash,
which is fine for orca etc. but since a new X server is used, the
address of the at-spi stack is not stored any more as the AT_SPI_BUS
X root property. Non-java applications are fine with that since
nowadays they use the dbus session bus to find the at-spi stack bus.
java-atk-wrapper however was still not using that, and was still using
the AT_SPI_BUS X root property which is considered deprecated.

The proposed changes make java-atk-wrapper use the dbus session bus,
like other accessible applications. It is then not a problem any more
that the restarted user session has a new X server without the
AT_SPI_BUS X root property.

[ Impact ]
Whenever an X session crashes or lightdm is restarted, java applications
in the new user sessions are not accessible to blind people through the
Orca screen reader.

[ Tests ]
I tested it with some VMs on my laptop, and tested by the original
user reporter.

[ Risks ]
The code is quite simple, is committed upstream, and just follows the
current practice of all other accessible applicatoins.

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

[ Changes ]
The code change the startup of java applications: if the AT_SPI_BUS X
root property is not found, they use dbus-send to achieve the standard
at-spi stack bus discovery.

[ Other info ]
This is the same request as for buster.
diff -Nru java-atk-wrapper-0.38.0/debian/changelog 
java-atk-wrapper-0.38.0/debian/changelog
--- java-atk-wrapper-0.38.0/debian/changelog2021-01-01 15:05:05.0 
+0100
+++ java-atk-wrapper-0.38.0/debian/changelog2021-08-26 02:50:17.0 
+0200
@@ -1,3 +1,9 @@
+java-atk-wrapper (0.38.0-2+deb11u1) bullseye; urgency=medium
+
+  * patches/dbus: Also detect at-spi through dbus.
+
+ -- Samuel Thibault   Thu, 26 Aug 2021 02:50:17 +0200
+
 java-atk-wrapper (0.38.0-2) unstable; urgency=medium
 
   [ Samuel Thibault ]
diff -Nru java-atk-wrapper-0.38.0/debian/patches/dbus 
java-atk-wrapper-0.38.0/debian/patches/dbus
--- java-atk-wrapper-0.38.0/debian/patches/dbus 1970-01-01 01:00:00.0 
+0100
+++ java-atk-wrapper-0.38.0/debian/patches/dbus 2021-08-26 02:50:17.0 
+0200
@@ -0,0 +1,50 @@
+commit 43576f265a16de8f1cd16c8a09d0e6a6006cbe3c
+Author: Samuel Thibault 
+Date:   Thu Aug 26 02:49:06 2021 +0200
+
+Also use dbus to detect accessibility being enabled
+
+This is required if for some reason the AT_SPI_BUS property is not set.
+That happens for instance if for some reason the dbus session bus (and thus
+the at-spi bus) is reused between X sessions.
+
+diff --git a/wrapper/org/GNOME/Accessibility/AtkWrapper.java.in 
b/wrapper/org/GNOME/Accessibility/AtkWrapper.java.in
+index cb267fd..d91b985 100644
+--- a/wrapper/org/GNOME/Accessibility/AtkWrapper.java.in
 b/wrapper/org/GNOME/Accessibility/AtkWrapper.java.in
+@@ -32,6 +32,11 @@ import java.lang.management.*;
+ 
+ public class AtkWrapper {
+   static boolean accessibilityEnabled = false;
++  static void initAtk() {
++System.loadLibrary("atk-wrapper");
++if (AtkWrapper.initNativeLibrary())
++  accessibilityEnabled = true;
++  }
+   static {
+ try {
+   Process p = Runtime.getRuntime().exec("@XPROP@ -root");
+@@ -39,13 +44,20 @@ public class AtkWrapper {
+   String result;
+   while ((result = b.readLine()) != null) {
+ if (result.indexOf("AT_SPI_IOR") >= 0 || result.indexOf("AT_SPI_BUS") 
>= 0) {
+-  System.loadLibrary("atk-wrapper");
+-  if (AtkWrapper.initNativeLibrary())
+-accessibilityEnabled = true;
++  initAtk();
+   break;
+ }
+   }
+ 
++  if (!accessibilityEnabled) {
++p = Runtime.getRuntime().exec("dbus-send --session 
--dest=org.a11y.Bus --print-reply /org/a11y/bus org.a11y.Bus.GetAddress");
++b = new BufferedReader(new InputStreamReader (p.getInputStream ()));
++while ((b.readLine()) != null);
++p.waitFor();
++if (p.exitValue() == 0)
++  initAtk();
++  }
++
+   java.util.List gcbeans = 

Bug#994021: buster-pu: package java-atk-wrapper/0.33.3-22+deb10u1

[Samuel Thibault]

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

[ Reason ]
As reported on
https://lists.debian.org/debian-accessibility/2021/06/msg3.html
when from an Xorg sesssion one runs

systemctl lightdm restart

which thus restarts the X server, or when for some reason the X session
crashes and the user is back at the lightdm login screen, after logging
back in the java applications are not accessible with the Orca screen
reader.

This is because the user's dbus session bus survives the restart/crash,
which is on purpose as discussed in 
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=992990
and thus the accessibility at-spi stack survives the restart/crash,
which is fine for orca etc. but since a new X server is used, the
address of the at-spi stack is not stored any more as the AT_SPI_BUS
X root property. Non-java applications are fine with that since
nowadays they use the dbus session bus to find the at-spi stack bus.
java-atk-wrapper however was still not using that, and was still using
the AT_SPI_BUS X root property which is considered deprecated.

The proposed changes make java-atk-wrapper use the dbus session bus,
like other accessible applications. It is then not a problem any more
that the restarted user session has a new X server without the
AT_SPI_BUS X root property.

[ Impact ]
Whenever an X session crashes or lightdm is restarted, java applications
in the new user sessions are not accessible to blind people through the
Orca screen reader.

[ Tests ]
I tested it with some VMs on my laptop, and tested by the original
user reporter.

[ Risks ]
The code is quite simple, is committed upstream, and just follows the
current practice of all other accessible applicatoins.

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

[ Changes ]
The code change the startup of java applications: if the AT_SPI_BUS X
root property is not found, they use dbus-send to achieve the standard
at-spi stack bus discovery.

[ Other info ]
I will also submit for a bullseye update.
diff -Nru java-atk-wrapper-0.33.3/debian/changelog 
java-atk-wrapper-0.33.3/debian/changelog
--- java-atk-wrapper-0.33.3/debian/changelog2019-04-04 22:51:05.0 
+0200
+++ java-atk-wrapper-0.33.3/debian/changelog2021-08-26 02:50:17.0 
+0200
@@ -1,3 +1,9 @@
+java-atk-wrapper (0.33.3-22+deb10u1) buster; urgency=medium
+
+  * patches/dbus: Also detect at-spi through dbus.
+
+ -- Samuel Thibault   Thu, 26 Aug 2021 02:50:17 +0200
+
 java-atk-wrapper (0.33.3-22) unstable; urgency=medium
 
   * patches/remove_component_listener: Fix memory leak (Closes: Bug#926420)
diff -Nru java-atk-wrapper-0.33.3/debian/patches/dbus 
java-atk-wrapper-0.33.3/debian/patches/dbus
--- java-atk-wrapper-0.33.3/debian/patches/dbus 1970-01-01 01:00:00.0 
+0100
+++ java-atk-wrapper-0.33.3/debian/patches/dbus 2021-08-26 02:50:17.0 
+0200
@@ -0,0 +1,50 @@
+commit 43576f265a16de8f1cd16c8a09d0e6a6006cbe3c
+Author: Samuel Thibault 
+Date:   Thu Aug 26 02:49:06 2021 +0200
+
+Also use dbus to detect accessibility being enabled
+
+This is required if for some reason the AT_SPI_BUS property is not set.
+That happens for instance if for some reason the dbus session bus (and thus
+the at-spi bus) is reused between X sessions.
+
+diff --git a/wrapper/org/GNOME/Accessibility/AtkWrapper.java.in 
b/wrapper/org/GNOME/Accessibility/AtkWrapper.java.in
+index cb267fd..d91b985 100644
+--- a/wrapper/org/GNOME/Accessibility/AtkWrapper.java.in
 b/wrapper/org/GNOME/Accessibility/AtkWrapper.java.in
+@@ -32,6 +32,11 @@ import java.lang.management.*;
+ 
+ public class AtkWrapper {
+   static boolean accessibilityEnabled = false;
++  static void initAtk() {
++System.loadLibrary("atk-wrapper");
++if (AtkWrapper.initNativeLibrary())
++  accessibilityEnabled = true;
++  }
+   static {
+ try {
+   Process p = Runtime.getRuntime().exec("@XPROP@ -root");
+@@ -39,13 +44,20 @@ public class AtkWrapper {
+   String result;
+   while ((result = b.readLine()) != null) {
+ if (result.indexOf("AT_SPI_IOR") >= 0 || result.indexOf("AT_SPI_BUS") 
>= 0) {
+-  System.loadLibrary("atk-wrapper");
+-  if (AtkWrapper.initNativeLibrary())
+-accessibilityEnabled = true;
++  initAtk();
+   break;
+ }
+   }
+ 
++  if (!accessibilityEnabled) {
++p = Runtime.getRuntime().exec("dbus-send --session 
--dest=org.a11y.Bus --print-reply /org/a11y/bus org.a11y.Bus.GetAddress");
++b = new BufferedReader(new InputStreamReader (p.getInputStream ()));
++while ((b.readLine()) != null);
++p.waitFor();
++if (p.exitValue() == 0)
++  initAtk();
++  }
++
+   java.util.List gcbeans = 

Bug#992692: general: Use https for {deb,security}.debian.org by default

[Paul Wise]

On Thu, Sep 9, 2021 at 6:03 PM Simon Richter wrote:

> Another important argument is that it creates a dependency on
> third-party commercial CDNs, and their *continued* sponsorship.

This dependency on external providers is unavoidable, Debian
definitely cannot afford to run our own CDN at the scale needed to
support our existing userbase. For example the security mirrors
struggled with Linux kernel security updates, so security.d.o switched
to a commercial CDN. Also, we are dependent on continued sponsorship
for all of our infrastructure, paying for all of our hosting is likely
not feasible.

https://wiki.debian.org/ExternalEntities

> Debian is very conservative when spending money and generally shies away
> from recurring expenses because we do not want to find us in a situation
> where we are dependent on an external entity making a timely donation in
> order to keep operations running, so I wonder why we are that accepting
> of it in one of our core services, and I certainly don't think we should
> be adding additional roadblocks should we ever need to find an alternative.

DSA setup the CDN provider solution to give the Debian userbase a
better experience than having to choose a mirror and a better
experience than httpredir.d.o's redirect method. We have multiple CDN
providers to mitigate the dependency, and other providers who we
aren't yet using that are offering service. So, as much as I dislike
CDNs as a concept, I recognise that we currently need them and think
that we are able to handle loss of a CDN provider or two.

> We have a (crude) load-balancing framework in infrastructure we control
> that can point requests towards a set of untrusted mirrors, and while
> it's nice that we don't *need* to use this fallback plan, it is
> reassuring it is there.

httpredir.d.o no longer exists, it points at deb.d.o, so it would have
to be rebuilt if we were to need to switch away from CDNs.

Personally I'd like to see a larger variety of Debian delivery
mechanisms; copy Debian/snapshot to archive.org, create a multi-distro
FLOSS CDN, bring back httpredir, DebTorrent and apt-p2p, add an i2p
mirror, use IPFS and content oriented networking etc. Michael Stone's
apt://debian idea seems like a good way to move in that direction
while adding protocol agility.

> If they ask why we're not using HTTPS, yes: it helps clear up the
> misconception that anything with an "s" in it is secure and can be trusted.

The volume of questions about missing https means that it is more
efficient to just use https than to have to reply to new questions
about it.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise

Bug#993947: Time lost, /etc/systemd/timesyncd.conf gets replaced with a default one

[Felipe Sateler]

On Thu, Sep 9, 2021 at 5:01 PM Michael Biebl  wrote:

> Am 09.09.21 um 16:15 schrieb Michael Biebl:
> > Am 09.09.21 um 15:15 schrieb Felipe Sateler:
> >> It should give us the guarantees[1]:
> >>
> >>  > The postinst script may be called in the following ways:
> >>  > postinst configure most-recently-configured-version
> >>  >   The files contained in the package will be unpacked.
> >>  >   All package dependencies will at least be “Unpacked”.
> >>  >   If there are no circular dependencies involved,
> >>  >   all package dependencies will be configured
> >>
> >> AFAICS we don't have circular dependencies, but maybe the versioned
> >> breaks/replaces + versioned depends makes dpkg think there is one?
> >
> > Hm, we do have systemd -> systemd-timesyncd | time-daemon and
> > systemd-timesyncd -> systemd
> >
> > This is a circular dep afaiu.
> >
>
> I guess the only way to break this dep cycle is to drop (or rather
> demote) the Depends: systemd-timesyncd | time-daemon to a Recommends.
>
> To ensure that systemd-timesyncd is installed during the initial
> bootstrap, we'd have to bump it's prio, similar to what we did for
> libpam-systemd. Either important or standard.
>
> Related here:
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=986651
>
> If we can get such a change into bullseye remains to be seen.
>
> Does anyone else have a different idea how to approach this?
>
>
No, I don't have any other idea. Perhaps the installer or apt teams have
any ideas?


-- 

Saludos,
Felipe Sateler

Bug#990800: ITA: btcheck/2.1-5 -- downloaded data checker and a torrent file content viewer

[Lin Qigang]

> On Saturday, August 7th, 2021 at 10:49 PM, Tobias Frost  
> wrote:
>
> Control: tags -1 moreinfo
> 

> Hi Lin Qigang,
> 

> On Wed, 07 Jul 2021 18:24:46 + Lin Qigang lqi...@protonmail.com wrote:
> 

> > Changes since the last upload:
> > 

> > btcheck (2.1-5) experimental; urgency=medium
> > 

> >   .
> > 

> > * debian/upstream/metadata: Added upstream metadata
> 

> The title says "ITA", so likely you've forgotten to close the ITA bug in
> 

> d/changelog…
> 

> Did you see
> 

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

> You do have undocumented changes (not mentioned in d/changelog).
> 

> Please document every single change.
> 


I closed the ITA bug, documented all of the changes, and fixed the pedantic and 
experimental lintian issues. I also retargeted it to unstable. If there is 
anything else please let me know.

Lin Qigang 
GPG Fingerprint:  8CAD 1250 8EE0 3A41 7223  03EC 7096 F91E D75D 028F



signature.asc
Description: OpenPGP digital signature

Bug#993971: kate: Kate puts a space when using some dead keys

[Norbert Preining]

Hi all,

> I did a test creating a file with the accented letters (my language is
> LANG=it_it), getting these results:
> 
> $ kate prova-accentate-àèéìòù-test
> 
> prova-accentate-ￜￜￜￜￜￜ-test

My guess is that there is a locale setup mismatch, and what happens is:
- filename is encoded in latin1
- kate expects utf8
- kate replaces the non-interpretable characters from latin1 with
�   (Unicode "REPLACEMENT CHARACTER")
  which has hex utf-8 bytes
EF BF BD
  which you see in the hd output:
> 0010  ef bf bd ef bf bd ef bf  bd ef bf bd ef bf bd ef


I have never tried running KDE in a *non UTF-8* locale, that might be 
problematic.

I tried to reproduce this with 
LANG=de_AT@euro kate
(this is a iso locale defined on my computer) but kate always uses utf8.

So I suggest that you make sure that your locales are properly set up,
and match with the settings of kde.

Best

Norbert

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

Bug#993605: lxml.etree.tostring() trailing junk

[Maxime Werlen]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Hi,

Any news about this bug ? Is this handled by upstream ?
Some urlwatch tests are failing due to this bug. I can't release a new version.

I hope someone has good news about this bug.

Thanks

Maxime
- --
Maxime Werlen
-BEGIN PGP SIGNATURE-

iQE+BAEBCgAoIRxNYXhpbWUgV2VybGVuIDxtYXhpbWVAd2VybGVuLmZyPgUCYTpU
rwAKCRBJ5XP6DXDdpufsB/4wtTPLgTK1hey/Zlwk1NApdZcKCbRnNpgHTp9FJUk/
GeLjPR1NRVikeD/FZ6AIhO4f+AJWNuR0MN8sh2eRPgLf3KLElwDDQCbSJ+HXEiM8
eS0v7znXUky9sfrXyt4RntaiF4SCUk5Dvezeo9z6Cl+8aomOPgzK1vdzZ3cgO4qp
Vo8U/Bjbng8Iz8aRD/DnEFX5UazRTdB9NazI3HbHbYepnNWfDtjoTGqwUtDVPErg
M0H+w8ncat96fKpIu5Q6QCsn/s9PqgkOnDDseugxz5oOImEfoIuq0tMSeRocfiRH
cIeJ1Aqmx6evj5Fv0Oo99RmXbh6msokawUh4H/VGZtQF
=tp1G
-END PGP SIGNATURE-

Bug#994020: dpkg-reconfigure debconf db modes (permitions) not as configured

[u34]

Package: debconf
Version: 1.5.77

dpkg-reconfigure debconf sets files in /var/cache/debconf whosemodes 
(permitions) are not as configured in /etc/debconf.conf. I guess it is 
also because of the umask setting.

How to reproduce?
1. Set the mode of config at /etc/debconf.conf to 0644.
2. Manually chmod /var/cache/debconf/config.dat to 0644, just to be sure.
3. Set root umsak for something restrictive, such as 0077. 
4. Run dpkg-reconfigure debconf.
5. Compare /var/cache/debconf/config*.dat actual value to the mode from
   /etc/debconf.conf.
6. Now repeat the procedure while setting root's umask at step 3 for
   something less restrictive, such as 0022. 

Bug#994019: libraw-doc: Package should include the samples

[Dima Kogan]

Package: libraw-doc
Version: 0.20.2-1
Severity: normal
Hi. The libraw sources include example code in samples/ and the html
documentation we ship in libraw-doc references those samples. But we
don't appear to actually ship those in any package. I think the whole
samples/ directory should be shipped in the libraw-doc package.

Thanks.

Bug#971590: rt-tests: bump to a new upstream release

[Punit Agrawal]

Hi Uwe,

Punit Agrawal  writes:

> Hi Uwe,
>
> I was looking to update the rt-tests package in Debian as it is lagging
> behind upstream.
>
> Before digging into the task, I wanted to check if you're planning to
> make any changes or had any patches that haven't been pushed. Pointers
> to any particular issues to watch out for would also be appreciated.
>
> Things I've noticed so far -
>
> * the upstream branch[0] is not fast-forwardable to latest upstream
>   changes and will need a rebase / force-push
>
> * there is a rt-tests repo on salsa[1] which has updates from Anders
>   (cc'd) but I don't see the results uploaded anywhere.

Following on from here, I took some time to address the above issues and
update the salsa package repository[2] to v2.2 of rt-tests. The task was
made a lot easier due to Anders' prior efforts.

Please take a look when you get a chance. If there are no objections, I
will look to doing an upload sometime next week.

Thanks,
Punit

[...]

>
> [0] https://git.pengutronix.de/cgit/ukl/rt-tests/log/?h=upstream
> [1] https://salsa.debian.org/debian/rt-tests

Bug#993819: release-notes: Please document the removal of wicd

[Noah Meyerhans]

On Thu, Sep 09, 2021 at 09:35:05PM +0200, Paul Gevers wrote:
> > Warning:  `wicd` will no longer be available after the upgrade, so if 
> > you use it to connect to the internet through wifi, you will be cut 
> > off.  To prevent this, you should change to a connection manager that 
> > *will* still be available, such as `connman`.  If you want a convnient 
> > graphical interface, without which making connections can be difficult, 
> > you should install `connman-gtk`.  You should do this *before* you 
> > start the upgrade, or you will have trouble reconnecting if things go 
> > wrong.
> 
> Isn't NetworkManager the default graphical manager nowadays? Or is there
> a link with systemd such that you wouldn't mention it for Devuan? No
> judgement intended, just wanting to have the facts straight.

Users who have wicd installed have already most likely expressed a
preference for something other than NetworkManager.  In most
installations, installing something like task-gnome-desktop or
task-xfce-desktop will pull in NetworkManager by virtue of their
Recommemds on network-manager-gnome.

I don't know much about connman or connman-gtk, but if it's the current
best alternative to NetworkManager, then maybe it makes sense to
recommend it as a replacement for wicd.  On the other hand, maybe a
gentle nudge back toward the "default" set of packages will lead to a
better experience in the longer term.  Recommending either
NetworkManager or connman as alternatives might be a good compromise.

noah

Bug#993668: CUPS is missing after a default GNOME Desktop Install

[Nader Nooryani]

Of course!

Updated the Reddit post.  Thank you so much for your swift help here Brian
and Holder :)

On Thu, Sep 9, 2021 at 8:14 PM Brian Potkin  wrote:

> On Sat 04 Sep 2021 at 16:16:50 +0200, Nader Nooryani wrote:
>
> > Package: task-gnome-desktop
> > Version: 3.68
> >
> > As of Debian 11, Print Server is no longer included as an option in the
> > Debian installer if you use the defaults: Debian desktop environment,
> GNOME
> > and standard system utilities.  Ref:
> > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=950553
> >
> > This leaves the user without CUPS after a default install.  This should
> > perhaps be included in task-gnome-desktop
> >
> > Suggestion: It may be wise to include CUPS in task-gnome-desktop or
> > somewhere else, since there are no instructions informing the user how
> they
> > can enable support for printing.
> >
> > I am using Linux debian 5.10.0-8-amd64 #1 SMP Debian 5.10.46-4
> (2021-08-03)
> > x86_64 GNU/Linux
>
> From a previous mail to -boot:
>
>  > I have written a bit more about this on Reddit as well.
>  > https://www.reddit.com/r/debian/comments/pgl6c9/debian_11_and_printing/
>
> It would be nice if the reddit thread could be updated to record the
> responsive and timely intervention from the d-i maintainers.
>
> Regards,
>
> Brian.
>
>
>

Bug#993819: release-notes: Please document the removal of wicd

[Hendrik Boom]

On Thu, Sep 09, 2021 at 09:35:05PM +0200, Paul Gevers wrote:
> Hi Hendrik,
> 
> On 09-09-2021 21:27, Hendrik Boom wrote:
> > Here is the text I have included in the current draft upgrade 
> > instructions for Devuan:
> > 
> > Warning:  `wicd` will no longer be available after the upgrade, so if 
> > you use it to connect to the internet through wifi, you will be cut 
> > off.  To prevent this, you should change to a connection manager that 
> > *will* still be available, such as `connman`.  If you want a convnient 
> > graphical interface, without which making connections can be difficult, 
> > you should install `connman-gtk`.  You should do this *before* you 
> > start the upgrade, or you will have trouble reconnecting if things go 
> > wrong.
> 
> Isn't NetworkManager the default graphical manager nowadays? Or is there
> a link with systemd such that you wouldn't mention it for Devuan? No
> judgement intended, just wanting to have the facts straight.

When I installed devuan a few releases ago it gave me connman.  So I
knew it worked.  And I tested it on chimaera.

network-manager is also available on Devuan, so I guess, there's no 
systemd issue.  But I am loathe to recommend something I hadn't tested 
on chimaera.

-- hendrik

> 
> Paul
> 
> 

Bug#991853: archive.debian.org: Invalid SSL/TLS certificate, https fails

[Ansgar]

Control: reassign -1 mirrors

Greg Wooledge wrote:
> Attempts to download a package from the archive.debian.org site using
> https with command line tools fail.
[...]
> The certificate's owner does not match hostname ‘archive.debian.org’

The FTP team only maintains the master copy of archive contents. Access
to the public copy via HTTP(S) should fall into the domain of the
mirror and/or system administration teams.

Ansgar

Bug#992034: installation-guide: Include a note on how to change init system during install

[Justin B Rye]

Justin B Rye wrote:
> Hmm.  That may have been boiled down *too* far, since there's no
> hint that it works by going to a shell.  So maybe that should have
> been in the intro?  (Sorry, can't remember the ulink syntax)
> 
>   As well as troubleshooting, the [[6.3.9.2|link]] also allows

Oops - what I intended to say here was [[6.3.9.2|shell]], i.e.
shell

>   further customization of the installation process to fit your
>   needs:
-- 
JBR with qualifications in linguistics, experience as a Debian
sysadmin, and probably no clue about this particular package

Bug#992034: installation-guide: Include a note on how to change init system during install

[Holger Wansing]

Hi,

Justin B Rye  wrote (Thu, 9 Sep 2021 07:21:24 +0100):
> Holger Wansing wrote:
> >> @Justin?
> > 
> > Hmm, debian-l10n-english has vanished from the loop somehow.
> > Therefore, I fear you lost track of this thread in the meantime ...
> 
> Thanks for spotting that.
>  
> > Maybe you could try to catch up starting from
> > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=992034#90
> > and the follow-ups in the bug and give some feedback? 
> > Thanks
> 
> In fact I'd also lost track of the fact that this particular thread is
> about changes to the *installer* guide rather than the release notes.
> 
>  + 
>  + Miscellaneous adaptions
>  +
>  +You may make custom adaptions of the installation process, to make it fit
>  +your needs:
>  +
> 
> Another vote against "adaption" (I've heard people use it, but usually
> because they're confusing "adapt" and "adopt").  You've also got an
> odd use of "may", and a slightly clunky repetition of "make" where all
> you really need to say is something like "The installation process can
> be adapted to fit your needs".  Except that this doesn't really feel
> to me like a good way to try to fit the section into its context.
> 
> Philip Hands suggested the section would fit with its neighbours
> better as
> 
>Variations requiring manual intervention
> 
> which may be true, but this brings to my attention the point that it
> seems to be promising to list plural variationS whereas in fact we've
> only got this one.  Another problem with "manual intervention" is that
> the installer guide tends to use the word "manual" to mean just "less
> automated" - as in "manual" versus "guided" partitioning.
> 
> The more I look at the way the sections are organised the more I think
> that the real problem is that "6.3.9 Troubleshooting" is already a
> misfit.  There needs to be some clearer mention in 6.1 of the fact
> that jumping to VT2 lets you issue commands behind d-i's back; the
> only place that's explained is the "Troubleshooting" section, which
> has been included in the list of d-i components where it doesn't
> really belong.  If that was fixed, maybe there would be a natural
> place to put a section on custom variations in the installation
> process.
> 
> It clearly is permitted to promote things out of that list of
> components into separate sections, since after all that's what has
> been done with section 6.4 "Loading Missing Firmware", which has been
> promoted out of 6.3.1 "Setting up Debian Installer and Hardware
> Configuration".  So maybe a 6.5 "Troubleshooting and Customization"?
> 
> Unfortunately this would necessarily be a long way from the sort of
> minimal patch that people were hoping for...

I'm not that unlucky with the Troubleshooting section, it in fact talks
about existing d-i modules for such job (save-logs, start a shell and
view debug info). And also the ordering of the sections looks more
logically to me that way.

So, I tend to go with a 6.5 section like

   + 
   + Customization
   + 
   + The installation process can be further customized to fit your needs:
   + 


What do you think?


Holger


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

Bug#993819: release-notes: Please document the removal of wicd

[Justin B Rye]

Hendrik Boom wrote:
> Here is the text I have included in the current draft upgrade 
> instructions for Devuan:
> 
> Warning:  `wicd` will no longer be available after the upgrade, so if 
> you use it to connect to the internet through wifi, you will be cut 
> off.  To prevent this, you should change to a connection manager that 
> *will* still be available, such as `connman`.  If you want a convnient 
> graphical interface, without which making connections can be difficult, 
> you should install `connman-gtk`.  You should do this *before* you 
> start the upgrade, or you will have trouble reconnecting if things go 
> wrong.

Thanks for giving us something to start from!  But becoming
unavailable for installation doesn't necessarily imply being
automatically purged on upgrade.  I gather wicd-gtk had Python2 GTK
dependencies; is there anything to stop users insisting on hanging on
to those on Bullseye?  It would certainly be wiser to switch ASAP, but
I don't think we can categorically declare that "you will be cut off".

Other nitpicks:
 * At least according to the package description I might in principle
   have been using wicd to manage a _wired_ connection.
 * And is there some particular reason for pointing in the direction
   of connman rather than network-manager?  (Don't desktops usually
   provide GUIs of their own for this sort of thing?)
 * Meanwhile, you're assuming the context of mobile devices that need
   to make frequent connections to new networks.  The reason I know so
   little about this sort of software is that "making connections can
   be difficult" has never been true for my PC - I just need to edit
   one configuration file each time I move house!

A revised version, still short on releasenotes-style markup:

  The network connection manager `wicd` will no longer be available
  after the upgrade, so to avoid the danger of losing connectivity
  users are recommended to switch before the upgrade to an alternative
  such as `network-manager` or `connman`.

(Plenty of room for other recommendations there if needed.)
-- 
JBR with qualifications in linguistics, experience as a Debian
sysadmin, and probably no clue about this particular package

Bug#983578: stterm: defaul variable for TERM didn't appear to work by default

[Richard]

Package: stterm
Version: 0.8.4-1
Followup-For: Bug #983578
X-Debbugs-Cc: arfisna...@mailnesia.com

Dear Maintainer,

Makes sense that it's not proper solution and thank you for your feedback.

Using st and dash I got the following.

$ dpkg -L ncurses-term|grep st-256color
/usr/share/terminfo/s/st-256color
$ TERM="st-256color"
$ htop
Error opening terminal: st-256color.
$ top
'st-256color': unknown terminal type.
$ man --version
man 2.9.4
$



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

Kernel: Linux 5.10.0-8-amd64 (SMP w/1 CPU thread)
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)

Versions of packages stterm depends on:
ii  libc6   2.31-13
ii  libfontconfig1  2.13.1-4.2
ii  libx11-62:1.7.2-1
ii  libxft2 2.3.2-2
ii  ncurses-term6.2+20201114-2

stterm recommends no packages.

stterm suggests no packages.

Bug#992034: installation-guide: Include a note on how to change init system during install

[Justin B Rye]

Holger Wansing wrote:
>> The more I look at the way the sections are organised the more I think
>> that the real problem is that "6.3.9 Troubleshooting" is already a
>> misfit.  There needs to be some clearer mention in 6.1 of the fact
>> that jumping to VT2 lets you issue commands behind d-i's back; the
>> only place that's explained is the "Troubleshooting" section, which
>> has been included in the list of d-i components where it doesn't
>> really belong.  If that was fixed, maybe there would be a natural
>> place to put a section on custom variations in the installation
>> process.
>> 
>> It clearly is permitted to promote things out of that list of
>> components into separate sections, since after all that's what has
>> been done with section 6.4 "Loading Missing Firmware", which has been
>> promoted out of 6.3.1 "Setting up Debian Installer and Hardware
>> Configuration".  So maybe a 6.5 "Troubleshooting and Customization"?
>> 
>> Unfortunately this would necessarily be a long way from the sort of
>> minimal patch that people were hoping for...
> 
> I'm not that unlucky with the Troubleshooting section, it in fact talks
> about existing d-i modules for such job (save-logs, start a shell and
> view debug info). And also the ordering of the sections looks more
> logically to me that way.

The only way I'm likely to make any progress towards fixing this bug
is by persuading myself I agree with you here!
 
> So, I tend to go with a 6.5 section like
> 
>+ 
>+ Customization
>+ 
>+ The installation process can be further customized to fit your needs:
>+ 
> 
> What do you think?

It might work.  Then it goes on:

  Installing an alternative init system
   
 uses systemd as its default init system. However, other
init systems (such as sysvinit and OpenRC) are supported, and the
easiest time to select an alternative init system is during the
installation process. For detailed instructions on how to do so,
please see the
https://wiki.debian.org/Init#Changing_the_init_system_-_at_installation_time;>Init
page on the Debian wiki.
   
  
 

Hmm.  That may have been boiled down *too* far, since there's no
hint that it works by going to a shell.  So maybe that should have
been in the intro?  (Sorry, can't remember the ulink syntax)

  As well as troubleshooting, the [[6.3.9.2|link]] also allows
  further customization of the installation process to fit your
  needs:

People might also want some echo of the Troubleshooting section's
cautionary note wedged in there; the minimal version would be to say
something like "careful customization" and/or "in exceptional cases".
-- 
JBR with qualifications in linguistics, experience as a Debian
sysadmin, and probably no clue about this particular package

Bug#969418: Library Package from PPA

[Petter Reinholdtsen]

[Barak A. Pearlmutter]
> I've ported the injection-library-package stuff from the upstream
> author's Ubuntu PPA, moving the support library in the process to what
> I'd consider the standard location for such things. Pushed to
> 
> https://salsa.debian.org/bap/simplescreenrecorder.git

I find a master and pristine-tar branch, but no upstream branch needed
for gpb buildpackage to recreate the orig.tar.gz file.

Do you have it around?
-- 
Happy hacking
Petter Reinholdtsen

Bug#993865: please enable CONFIG_MT7915E

[Vincent Blut]

Hi Piotr,

Le 2021-09-07 15:08, Piotr Ożarowski a écrit :
> Package: src:linux
> Version: 5.10.28-1
> Severity: wishlist
> 
> Dear Maintainer,
> 
> Please enable CONFIG_MT7915E (MediaTek MT7915E (PCIe) support) - looks
> like my new mini PCIe card needs this one.
> 5.14-1~exp2 from experimental doesn't have this one enabled as well
> 
> CONFIG_MT7915E was added in Linux 5.8

I sent a merge request¹ to fulfil your request. It also enables support for
other wireless MediaTek chips, notably the MT7921E which seems quite popular on
some laptops (e.g. ASUS G15, Acer Nitro 5).

> TIA

Cheers,
Vincent

¹ https://salsa.debian.org/kernel-team/linux/-/merge_requests/391


signature.asc
Description: PGP signature

Bug#994008: debian-policy: Clarify relationship between source and binary packages' archive areas

[Ansgar]

On Thu, 2021-09-09 at 12:48 -0700, Sean Whitton wrote:
> > But source packages in main must also produce at least one binary
> > package in main[1].
> 
> Let's include that point in Policy.
> 
> > [1]: Probably with the default build profile if we care about corner
> >    cases.
> 
> Are we sure about this?  Is this a bug in current dak or a general
> problem with the semantics we're discussing?

We expect all packages uploaded to Debian to use the default build
profile (as a policy). Not doing so will probably cause various issues
(such as a binNMU reverting to the default profile thus changing the
package). So for the archive a binary only built in non-default build
profiles should just be ignored (for binary-NEW, choice of archive
area, ...) as it shouldn't appear in Debian; packages are free to do
whatever they want with build profiles.

This behavior was asked for in https://bugs.debian.org/913965

If we allowed packages to use non-default build profiles then we would
probably have to revisit this.

(I would expect this corner case to not happen in practice.)

> > I personally would prefer if we would avoid using this feature too much
> > if possible. It is simpler to understand when archive areas are self-
> > contained (IMHO). Outside Debian archive areas are used differently,
> > e.g., for different "branches" or similar; sources building binary
> > packages across multiple archive areas also find strange corner cases
> > now and then that are not handled correctly.
> 
> It would be good if we included in Policy the idea that for technical
> reasons, it is best to use separate source packages (only) when that is
> not otherwise too inconvenient.
> 
> I am not sure we have a consensus on avoiding using this feature for the
> sake of simplicity of understanding, so let's exclude that idea for now.

Sure, that seems reasonable enough.

Ansgar

Bug#994018: gnome-tweaks must not suggest installing Extensions app from flathub

[Julian Andres Klode]

Package: gnome-tweaks
Version: 40.0-3
Severity: serious

gnome-tweaks suggests users install the Extensions app from flathub,
if not provided by the distribution. This is misleading the user to
install apps from outside of main, in violation of policy 2.2.1.

It should offer to install the gnome-shell-extension-prefs package
via gnome-software, tell people to install that package with apt,
or (in my case where it was already installed), tell me that it
is already installed.

The message under concern is:

self.format_secondary_markup(
"{0}\n\n{1}".format(
# Translators: Placeholder will be replaced with "GNOME 
Extensions" in active link form
_("Extensions management has been moved to {0}.").format(
'https://gitlab.gnome.org/GNOME/gnome-shell/-/blob/master/subprojects/extensions-app/README.md;>GNOME
 Extensions',
),
# Translators: Placeholder will be replaced with "Flathub" in 
active link form
_("We recommend downloading GNOME Extensions from {0} if your 
distribution does not include it.").format(
'https://flathub.org/apps/details/org.gnome.Extensions;>Flathub'
)
)
)

it should say something like:

"Extensions management has been moved to Extension, which is part of
the gnome-shell-extensions-prefs package."

Bug-Ubuntu: https://bugs.launchpad.net/ubuntu/+source/gnome-tweaks/+bug/1943183

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

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

Versions of packages gnome-tweaks depends on:
ii  dconf-gsettings-backend [gsettings-backend]  0.40.0-1
ii  gir1.2-glib-2.0  1.68.0-1
ii  gir1.2-gnomedesktop-3.0  40.2-1ubuntu1
ii  gir1.2-gtk-3.0   3.24.30-1ubuntu1
ii  gir1.2-handy-1   1.2.3-1
ii  gir1.2-notify-0.70.7.9-3ubuntu2
ii  gir1.2-pango-1.0 1.48.9+ds1-1
ii  gir1.2-soup-2.4  2.72.0-3ubuntu3
ii  gnome-settings-daemon40.0.1-1ubuntu2
ii  gnome-shell-common   40.2-1ubuntu6
ii  gnome-shell-extension-prefs  40.2-1ubuntu6
ii  gsettings-desktop-schemas40.0-1ubuntu1
ii  mutter-common40.2.1-1ubuntu1
ii  python3  3.9.4-1
ii  python3-gi   3.40.1-1

gnome-tweaks recommends no packages.

gnome-tweaks suggests no packages.

-- no debconf information

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

Bug#994017: python3-pynetbox: please provide a bullseye-backport

[Georg Faerber]

Package: python3-pynetbox
Severity: wishlist

Dear maintainer,

Would it be possible to provide a backport targeting bullseye?

Thanks a lot for maintaining python3-pynetbox in Debian!

Cheers,
Georg

Bug#993979: gpac: CVE-2020-19751 The gf_odf_del_ipmp_tool function in odf_code.c has a heap-based buffer over-read

[Salvatore Bonaccorso]

Hi,

On Thu, Sep 09, 2021 at 09:07:59AM +0100, Neil Williams wrote:
> Source: gpac
> Version: 1.0.1+dfsg1-5
> Severity: important
> Tags: security upstream
> X-Debbugs-Cc: codeh...@debian.org, Debian Security Team 
> 
> 
> A security vulnerability exists in gpac at version 1.0.1+dfsg1-5.
> (Vulnerable code was introduced after the version currently in buster
> but remains present in the version in unstable.)
> 
> CVE-2020-19750 [0]
> An issue was discovered in gpac 0.8.0. The strdup function in box_code_base.c 
> has a heap-based buffer over-read.
> 
> 
> If you fix the vulnerability please also make sure to include the
> CVE (Common Vulnerabilities & Exposures) id in your changelog entry.
> 
> For further information, see:
> 
> [0] https://security-tracker.debian.org/tracker/CVE-2020-19751
> 
> https://github.com/gpac/gpac/commit/3fcf66c6031da966cf33ee89bcbefa2f8bec4b02
> 
> https://sources.debian.org/src/gpac/1.0.1+dfsg1-5/src/odf/odf_code.c/#L3340

Something is confusing in the above. For CVE-2020-19751 for which this
bug report seems to, the upstream issue is
https://github.com/gpac/gpac/issues/1272 . This was adressed in
https://github.com/gpac/gpac/commit/c26b0aa605aaea1f0ebe8d21fe1398d94680adf7
which in the lines above is contained. Actually it should be since
around v0.9.0 upstream. Now I did not get to the poc's provided by the
reporter to do some additional verification. But the touched code
seems present back in at least 0.5.2-426-gc5ad4e4+dfsg5-5 (not checked
older).

Can you double check? Or what am i missing?

Regards,
Salvatore

Bug#993947: Time lost, /etc/systemd/timesyncd.conf gets replaced with a default one

[Michael Biebl]

Am 09.09.21 um 16:15 schrieb Michael Biebl:

Am 09.09.21 um 15:15 schrieb Felipe Sateler:

It should give us the guarantees[1]:

 > The postinst script may be called in the following ways:
 > postinst configure most-recently-configured-version
 >   The files contained in the package will be unpacked.
 >   All package dependencies will at least be “Unpacked”.
 >   If there are no circular dependencies involved,
 >   all package dependencies will be configured

AFAICS we don't have circular dependencies, but maybe the versioned 
breaks/replaces + versioned depends makes dpkg think there is one?


Hm, we do have systemd -> systemd-timesyncd | time-daemon and
    systemd-timesyncd -> systemd

This is a circular dep afaiu.



I guess the only way to break this dep cycle is to drop (or rather 
demote) the Depends: systemd-timesyncd | time-daemon to a Recommends.


To ensure that systemd-timesyncd is installed during the initial 
bootstrap, we'd have to bump it's prio, similar to what we did for 
libpam-systemd. Either important or standard.


Related here:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=986651

If we can get such a change into bullseye remains to be seen.

Does anyone else have a different idea how to approach this?

Michael



OpenPGP_signature
Description: OpenPGP digital signature

Bug#993823: buster-pu: package clamav/0.103.3+dfsg-0+deb10u1

[Adam D. Barratt]

Control: tags -1 + confirmed

On Mon, 2021-09-06 at 23:59 +0200, Sebastian Andrzej Siewior wrote:
> This is an update of clamav to version 0.103.3 which is considered as
> a
> LTS version. It contains only important fixes. The details were
> documented by upstream at
> 
> https://blog.clamav.net/2021/09/changes-to-clamav-end-of-life-policy.html
> 

Please go ahead.

Regards,

Adam

Bug#993822: bullseye-pu: package clamav/0.103.3+dfsg-0+deb11u1

[Adam D. Barratt]

Control: tags -1 + confirmed

On Tue, 2021-09-07 at 00:00 +0200, Sebastian Andrzej Siewior wrote:
> This is an update of clamav to version 0.103.3 which is considered as
> a
> LTS version. It contains only important fixes. The details were
> documented by upstream at
>   
> https://blog.clamav.net/2021/09/changes-to-clamav-end-of-life-policy.html
> 

Please go ahead.

Regards,

Adam

Bug#993971: kate: Kate puts a space when using some dead keys

[Antonio]

I did a test creating a file with the accented letters (my language is 
LANG=it_it), getting these results:


$ date > prova-accentate-àèéìòù-test

$ ls -ll
-rw-r--r--  1 root   root 31  9 set 21.34 prova-accentate-àèéìòù-test

$ ls prova-accentate-àèéìòù-test | hd
  70 72 6f 76 61 2d 61 63  63 65 6e 74 61 74 65 2d  
|prova-accentate-|

0010  e0 e8 e9 ec f2 f9 2d 74  65 73 74 0a |àèéìòù-test.|

This test is ok

---

$ kate prova-accentate-àèéìòù-test

$ ls -ll
-rw-r--r--  1 root   root 31  9 set 21.35 
prova-accentate-ￜￜￜￜￜￜ-test


$ ls prova-accentate-ￜￜￜￜￜￜ-test | hd
  70 72 6f 76 61 2d 61 63  63 65 6e 74 61 74 65 2d  
|prova-accentate-|
0010  ef bf bd ef bf bd ef bf  bd ef bf bd ef bf bd ef 
|ￜￜￜￜￜï|

0020  bf bd 2d 74 65 73 74 0a |¿œ-test.|

This test has an unexpected result, It seems that Kate does not manage 
these characters...

Bug#993889: [INTL:sv] Swedish strings for diaspora-installer debconf

[Martin Bagge / brother]

On 2021-09-08 17:53, Anders Jonsson wrote:
The attached po file fixes some small typos and overly split-up words 
for diaspora-installer. Changes can be seen in the diff that is also 
attached.


thnx

--
brother

Bug#994008: debian-policy: Clarify relationship between source and binary packages' archive areas

[Sean Whitton]

Hello,

On Thu 09 Sep 2021 at 09:15PM +02, Ansgar wrote:

> On Thu, 2021-09-09 at 17:39 +0100, Simon McVittie wrote:
>>
>> ftp team: is this correct?
>
> Yes.

Indeed.

> But source packages in main must also produce at least one binary
> package in main[1].

Let's include that point in Policy.

> [1]: Probably with the default build profile if we care about corner
>cases.

Are we sure about this?  Is this a bug in current dak or a general
problem with the semantics we're discussing?

> I personally would prefer if we would avoid using this feature too much
> if possible. It is simpler to understand when archive areas are self-
> contained (IMHO). Outside Debian archive areas are used differently,
> e.g., for different "branches" or similar; sources building binary
> packages across multiple archive areas also find strange corner cases
> now and then that are not handled correctly.

It would be good if we included in Policy the idea that for technical
reasons, it is best to use separate source packages (only) when that is
not otherwise too inconvenient.

I am not sure we have a consensus on avoiding using this feature for the
sake of simplicity of understanding, so let's exclude that idea for now.

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#994012: [Pkg-rust-maintainers] Bug#994012: librust-html5ever-dev - dependencies not available

[peter green]

> The depencencies aren't available at bullseye, bookworm, sid

Yes they are.

The Debian rust packaging makes heavy use of versioned virtual packages to make
it possible to have multiple versions of crates around at one time. 
Unfortunately
the packages.debian.org web interface doesn't understand these and claims
"package not available".

Bug#993819: release-notes: Please document the removal of wicd

[Paul Gevers]

Hi Hendrik,

On 09-09-2021 21:27, Hendrik Boom wrote:
> Here is the text I have included in the current draft upgrade 
> instructions for Devuan:
> 
> Warning:  `wicd` will no longer be available after the upgrade, so if 
> you use it to connect to the internet through wifi, you will be cut 
> off.  To prevent this, you should change to a connection manager that 
> *will* still be available, such as `connman`.  If you want a convnient 
> graphical interface, without which making connections can be difficult, 
> you should install `connman-gtk`.  You should do this *before* you 
> start the upgrade, or you will have trouble reconnecting if things go 
> wrong.

Isn't NetworkManager the default graphical manager nowadays? Or is there
a link with systemd such that you wouldn't mention it for Devuan? No
judgement intended, just wanting to have the facts straight.

Paul




OpenPGP_signature
Description: OpenPGP digital signature

Bug#993819: release-notes: Please document the removal of wicd

[Hendrik Boom]

On Tue, Sep 07, 2021 at 06:54:05AM +0200, Joost van Baal-Ilić wrote:
> Hi,
> 
> On Mon, Sep 06, 2021 at 05:23:45PM -0400, Hendrik Boom wrote:
> > On Mon, Sep 06, 2021 at 10:01:10PM +0100, Roger Lynn wrote:
> > > Package: release-notes
> > > Severity: important
> > > 
> > > Please document the removal of wicd in Bullseye. This seems particularly
> > > dangerous if the upgrade is being done over a network connection being 
> > > managed
> > > by wicd as it seems likely that the connection will be lost when wicd is
> > > removed (due to dependency problems). It would also be helpful if 
> > > alternatives
> > > could be suggested.
> > 
> > I already did that in the draft upgrade instructions for Devuan, as 
> > something to be done before anything else. 
> > 
> > SHould I send a copy of the paragraph to this list?
> 
> Yes, that would be helpful, and please do Cc 993...@bugs.debian.org .

Here is the text I have included in the current draft upgrade 
instructions for Devuan:

Warning:  `wicd` will no longer be available after the upgrade, so if 
you use it to connect to the internet through wifi, you will be cut 
off.  To prevent this, you should change to a connection manager that 
*will* still be available, such as `connman`.  If you want a convnient 
graphical interface, without which making connections can be difficult, 
you should install `connman-gtk`.  You should do this *before* you 
start the upgrade, or you will have trouble reconnecting if things go 
wrong.

-- hendrik





> 
> Thanks, Bye,
> 
> Joost
> 

Bug#994016: salt: CVE-2021-21996 CVE-2021-22004

[Salvatore Bonaccorso]

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

Hi,

The following vulnerabilities were published for salt.

CVE-2021-21996[0]:
| An issue was discovered in SaltStack Salt before 3003.3. A user who
| has control of the source, and source_hash URLs can gain full file
| system access as root on a salt minion.


CVE-2021-22004[1]:
| An issue was discovered in SaltStack Salt before 3003.3. The salt
| minion installer will accept and use a minion config file at
| C:\salt\conf if that file is in place before the installer is run.
| This allows for a malicious actor to subvert the proper behaviour of
| the given minion software.


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

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2021-21996
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-21996
[1] https://security-tracker.debian.org/tracker/CVE-2021-22004
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-22004

Please adjust the affected versions in the BTS as needed.

Regards,
Salvatore

Bug#993974: mpv: Can't play anything anymore

[Sebastian Ramacher]

Control: reassign -1 ffmpeg 7:4.4-1
Control: affects -1 mpv 0.33.1-1

On 2021-09-09 20:23:22, Sven Joachim wrote:
> Control: affects -1 - mpv
> Control: reassign -1 mpv 0.33.1-1
> Control: severity -1 serious
> 
> On 2021-09-09 09:16 +0200, Sebastian Ramacher wrote:
> 
> > Control: reassign -1 src:ffmpeg 7:4.4-1
> > Control: retitle -1 ffmpeg: bump symbol versions to generate dependencies 
> > with >= 7:4.4
> 
> I do not think this is the right solution.
> 
> > On 2021-09-08 19:45:03 -0300, Nelson A. de Oliveira wrote:
> >> Package: mpv
> >> Version: 0.33.1-1
> >> Severity: grave
> >> Justification: renders package unusable
> >>
> >> Hi!
> >>
> >> After upgrading mpv from 0.32.0-3 to 0.33.1-1 it seems that I can't play
> >> anything anymore.
> >> (downgrading to 0.32.0-3 I can play videos again)
> >>
> >> =
> >> $ mpv palestra.mp4
> >> libavutil: 56.70.100 -> 56.51.100
> >> zsh: abort  mpv palestra.mp4
> 
> It is mpv's own code which does the library version check and aborts
> here, see check_library_versions() in common/av_log.c.

ffmpeg in general does not support users who build with X but run
with Y < X. mpv checks for that and aborts if that is not the case.
Reassigning back to ffmpeg. Please do not reassign it again.

Cheers

> 
> There used to be a Debian patch to prevent that, but it was removed
> rather than rebased in 0.33.1-1[1].
> 
> Cheers,
>Sven
> 
> 
> 1. 
> https://salsa.debian.org/multimedia-team/mpv/-/commit/280e7916502baa177bbd23435f0ce16a56c8be21#4850c9e1d1b2b6d5c3448c16e5dcf6fbf07b338a

-- 
Sebastian Ramacher

Bug#993838: sane-utils: fails to detect scanner w/o root privileges; the user is in scanner group

[Jörg Frings-Fürst]

Hello,

thanks for your feedback.



Am Mittwoch, dem 08.09.2021 um 19:34 +0700 schrieb A L:
> В Tue, 07 Sep 2021 18:18:52 +0200
> Jörg Frings-Fürst  пишет:
> 
> > Hello,
> > 
> > at first please answer always into the bug,too.
> > 
[...]
> 
> OK
>  
>  
> > Then reboot und test it again.
> 
> Scanner detected!
> 
> 
[...]
> 
> It works!
> 
> 
[...]

> 
> Many thanks, Jörg !
> 
> WBR,
> Andrei

CU 
Jörg

-- 
New:
GPG Fingerprint: 63E0 075F C8D4 3ABB 35AB  30EE 09F8 9F3C 8CA1 D25D
GPG key (long) : 09F89F3C8CA1D25D
GPG Key: 8CA1D25D
CAcert Key S/N : 0E:D4:56

Old pgp Key: BE581B6E (revoked since 2014-12-31).

Jörg Frings-Fürst
D-54470 Lieser


git:  https://jff.email/cgit/

Threema: SYR8SJXB
Wire: @joergfringsfuerst
Skype: joergpenguin
Ring: jff
Telegram: @joergfringsfuerst


My wish list: 
 - Please send me a picture from the nature at your home.



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

Bug#994011: ghostscript: CVE-2021-3781

[Jonas Smedegaard]

Quoting Salvatore Bonaccorso (2021-09-09 20:43:30)
> Hi Jonas,
> 
> On Thu, Sep 09, 2021 at 08:09:42PM +0200, Jonas Smedegaard wrote:
> > Hi Salvatore,
> > 
> > Quoting Salvatore Bonaccorso (2021-09-09 19:20:08)
> > > The following vulnerability was published for ghostscript.
> > > 
> > > CVE-2021-3781[0].
> > 
> > I have prepared a package fixing this issue, available at 
> > https://salsa.debian.org/printing-team/ghostscript/-/tree/debian/bullseye
> > 
> > Please tell how I should proceed with it - or feel free to proceed 
> > yourself from here.
> 
> I did actually already uploaded earlier today to the embargoed queues,
> waiting for the builds of mips64el and s390x yet, but then hope to
> release the DSA soon.

Excellent!


 - Jonas

-- 
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/

 [x] quote me freely  [ ] ask before reusing  [ ] keep private

signature.asc
Description: signature

Bug#971319: aubio: uses deprecated libavresample

[peter green]

tags 971319 +patch
thanks



The ffmpeg package no longer builds libavresample-dev, it is still present in
unstable as a cruft package but is completely gone from testing. So this
package's build-dependencies can no longer be satisfied in testing.

Looking at the build logs and the binary dependencies it looks like aubio
has already switched from using libavresample to using libswresample but
the build-dependencies were never updated to match. This worked because
libswresample was pulled in indirectly (I did not investigate by which path
it was pulled in)

I did a test build and autopkgtest run with the change and it passed,
so I have uploaded the fix to delayed/5 as a NMU, please tell me if
you see any problems with this upload.
diff -Nru aubio-0.4.9/debian/changelog aubio-0.4.9/debian/changelog
--- aubio-0.4.9/debian/changelog2020-01-08 12:39:53.0 +
+++ aubio-0.4.9/debian/changelog2021-09-09 18:11:53.0 +
@@ -1,3 +1,12 @@
+aubio (0.4.9-4.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Change build-depends from libavresample-dev to libswresample-dev
+the build logs and binary dependencies indicate the package was
+already using libswresample ( Closes: 971319 ).
+
+ -- Peter Michael Green   Thu, 09 Sep 2021 18:11:53 +
+
 aubio (0.4.9-4) unstable; urgency=medium
 
   * debian/tests/control: remove py2 tests
diff -Nru aubio-0.4.9/debian/control aubio-0.4.9/debian/control
--- aubio-0.4.9/debian/control  2020-01-04 18:53:25.0 +
+++ aubio-0.4.9/debian/control  2021-09-09 18:11:53.0 +
@@ -7,7 +7,7 @@
libjack-dev | libjack-jackd2-dev,
libavcodec-dev,
libavformat-dev,
-   libavresample-dev,
+   libswresample-dev,
libavutil-dev,
libsndfile1-dev,
libsamplerate-dev,

Bug#994008: debian-policy: Clarify relationship between source and binary packages' archive areas

[Ansgar]

Hi,

On Thu, 2021-09-09 at 17:39 +0100, Simon McVittie wrote:
> In the form of a table, the allowed source/binary combinations are:
> 
>   |    binary   |
>   | main  contrib  non-free |
>  -|-|
>  main |  yes    yes  -  |
>  source  contrib  |   - yes  -  |
>  non-free |   -  -  yes |
> 
> ftp team: is this correct?

Yes. But source packages in main must also produce at least one binary
package in main[1].

  [1]: Probably with the default build profile if we care about corner
   cases.

I personally would prefer if we would avoid using this feature too much
if possible. It is simpler to understand when archive areas are self-
contained (IMHO). Outside Debian archive areas are used differently,
e.g., for different "branches" or similar; sources building binary
packages across multiple archive areas also find strange corner cases
now and then that are not handled correctly.

Ansgar

Bug#994015: RFS: evilwm/1.3.1-1 -- minimalist window manager for X11

[Mateusz Łukasik]

Package: sponsorship-requests
Severity: normal

Dear mentors,

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

 * Package name: evilwm
   Version : 1.3.1-1
   Upstream Author : Ciaran Anscomb
 * URL :https://www.6809.org.uk/evilwm/
 * License : AEWM
 * Vcs :https://github.com/mati75/evilwm.git
   Section : x11

It builds those binary packages:

  evilwm - minimalist window manager for X11

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

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

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

  dget -xhttps://mentors.debian.net/debian/pool/main/e/evilwm/evilwm_1.3.1-1.dsc

Changes since the last upload:

 evilwm (1.3.1-1) unstable; urgency=medium
 .
   [ Jelmer Vernooij ]
   * Use secure URI in Vcs control header.
 .
   [ Debian Janitor ]
   * Trim trailing whitespace.
   * Use secure copyright file specification URI.
   * Use secure URI in debian/watch.
   * Use secure URI in Homepage field.
   * Bump debhelper from old 9 to 12.
   * Update renamed lintian tag names in lintian overrides.
   * Drop unnecessary dh arguments: --parallel
 .
   [ Mateusz Łukasik ]
   * New upstream release. (Closes: #920946)
   * Bump standards version to 4.6.0
   * Drop d/patches/fix-lost-focus.patch -- included upstream.
   * Add Rules-Requires-Root.
   * Bump d/watch to 4.
   * Drop menu file.
   * Update d/evilwm.doc-base.
   * Add d/patches/drop_build_pdf.patch -- for disable build docs in pdf.
   * Add d/upstream/metadata.
   * Add Forwarded: not-needed to all patches.

Regards,
--
  Mateusz Łukasik

Bug#994000: undertime: missing dependency ModuleNotFoundError: No module named 'ephem'

[Ben Harris]

Package: undertime
Version: 2.4.0
Severity: important

Dear Maintainer,

import ephem fails when running moonphases.

installing python3-ephem resolves this issue; please add it as a dep.

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

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

Versions of packages undertime depends on:
ii  python3 3.9.2-3
ii  python3-dateparser  1.0.0-1
ii  python3-tabulate0.8.7-0.1
ii  python3-termcolor   1.1.0-3
ii  python3-tz  2021.1-1
ii  python3-yaml5.3.1-5

undertime recommends no packages.

undertime suggests no packages.

-- no debconf information

Bug#988935: gftp-{gtk,text}: broken symlinks

[Stefan]

I looked into upstream the upstream project.
It looks there were some changes.

 * Readme file has been renamed from README to README.md
 * THANkS does not exists anymore (there is a AUTHORS)
 * TODO: I think this files it not part of installation
 * parse-netrc.pl has been removed

I think two files which needs to be fixed:

 * debian/gftp-gtk.links
 * gftp-text.links

-- 

Bug#994014: dgit push-source unnecessarily fails if gpg updates its trustdb

[Colin Watson]

Package: dgit
Version: 9.14
Severity: normal

  $ dgit push-source
  Format `3.0 (quilt)', need to check/update patch stack
  canonical suite name for unstable is sid
  examining quilt state (multiple patches, linear mode)
  dgit: base trees orig=4279eec4f1a3bd0a717f o+d/p=5d5ad4032c09579ff44b
  dgit: quilt differences: src:  ## orig ## gitignores:  == orig ==
  dgit: quilt differences:  HEAD == o+d/p   HEAD == o+d/p
  starting quiltify (multiple patches, linear mode)
  quiltify linearisation planning successful, executing...
  nothing quilty to commit, ok.
  dpkg-source: info: using source format '3.0 (quilt)'
  dpkg-source: info: building groff using existing ./groff_1.22.4.orig.tar.gz
  dpkg-source: info: building groff using existing 
./groff_1.22.4.orig.tar.gz.asc
  gpgv: [don't know]: invalid packet (ctb=2d)
  gpgv: no signature found
  gpgv: the signature could not be verified.
  Please remember that the signature file (.sig or .asc)
  should be the first file given on the command line.
  dpkg-source: warning: failed to verify signature on 
./groff_1.22.4.orig.tar.gz.asc
  dpkg-source: info: using patch list from debian/patches/series
  dpkg-source: info: building groff in groff_1.22.4-7.debian.tar.xz
  dpkg-source: info: building groff in groff_1.22.4-7.dsc
  changelog will contain changes since 1.22.4-6
  dpkg-genchanges: info: not including original source code in upload
  last upload to archive: specified git info (debian)
  using existing groff_1.22.4.orig.tar.gz
  using existing groff_1.22.4.orig.tar.gz.asc
  nothing quilty to commit, ok.
  checking that groff_1.22.4-7.dsc corresponds to HEAD
  dpkg-source: warning: extracting unsigned source package 
(/home/cjwatson/src/debian/groff/trunk/groff/../groff_1.22.4-7.dsc)
  dpkg-source: info: extracting groff in groff-1.22.4
  dpkg-source: info: unpacking groff_1.22.4.orig.tar.gz
  dpkg-source: info: unpacking groff_1.22.4-7.debian.tar.xz
  dpkg-source: info: using patch list from debian/patches/series
  dpkg-source: info: applying bash-scripts.patch
  dpkg-source: info: applying nroff-ifs.patch
  dpkg-source: info: applying doc-gfdl.patch
  dpkg-source: info: applying doc-gzipped.patch
  dpkg-source: info: applying extratmacdirs.patch
  dpkg-source: info: applying papersize-config.patch
  dpkg-source: info: applying load-desc-failure.patch
  dpkg-source: info: applying mmse-note.patch
  dpkg-source: info: applying display-utc-times.patch
  dpkg-source: info: applying sort-perl-hash-keys.patch
  dpkg-source: info: applying avoid-perl-diamond.patch
  dpkg-source: info: applying mdoc-Lk-arguments.patch
  dpkg-source: info: applying bsd-updates.patch
  dpkg-source: info: applying document-sgr.patch
  dpkg-source: info: applying destructor-segv.patch
  ../groff_1.22.4-7_source.changes already has appropriate .orig(s) (if any)
  gpg: WARNING: server 'gpg-agent' is older than us (2.2.19 < 2.2.27)
  gpg: Note: Outdated servers may lack important security fixes.
  gpg: Note: Use the command "gpgconf --kill all" to restart them.
  gpg: WARNING: server 'gpg-agent' is older than us (2.2.19 < 2.2.27)
  gpg: Note: Outdated servers may lack important security fixes.
  gpg: Note: Use the command "gpgconf --kill all" to restart them.
  gpg: Signature made Thu 09 Sep 2021 18:21:14 BST
  gpg:using RSA key AC0A4FF12611B6FCCF01C111393587D97D86500B
  gpg: checking the trustdb
  gpg: public key BFE09513E94EC0C2 is 4372 seconds newer than the signature
  gpg: public key 2BAEE41F0644FAB7 is 676 seconds newer than the signature
  gpg: public key 2BAEE41F0644FAB7 is 660 seconds newer than the signature
  gpg: public key 8921B5DCCD15A883 is 11958 days newer than the signature
  gpg: public key 8921B5DCCD15A883 is 11958 days newer than the signature
  gpg: public key 8921B5DCCD15A883 is 11958 days newer than the signature
  gpg: public key 9710B89BCA57AD7C is 12758 days newer than the signature
  gpg: public key of ultimately trusted key 0E3DB4D402F53CC6 not found
  gpg: public key of ultimately trusted key 9586533FAD672468 not found
  gpg: public key of ultimately trusted key A74F479F4E500079 not found
  gpg: public key of ultimately trusted key 79293F36215383B8 not found
  gpg: public key of ultimately trusted key A337CC09F1F12F4C not found
  gpg: public key of ultimately trusted key 0B0F571CA04CEE7F not found
  gpg: public key of ultimately trusted key 9DE2F2078A48CE0B not found
  gpg: public key of ultimately trusted key B6FEEE02ED291A57 not found
  gpg: public key of ultimately trusted key 9095D28B3513A7B0 not found
  gpg: marginals needed: 3  completes needed: 1  trust model: classic
  gpg: depth: 0  valid:  12  signed: 100  trust: 0-, 0q, 0n, 0m, 0f, 12u
  gpg: depth: 1  valid: 100  signed: 343  trust: 60-, 19q, 2n, 12m, 7f, 0u
  gpg: depth: 2  valid: 164  signed: 283  trust: 123-, 34q, 0n, 6m, 1f, 0u
  gpg: depth: 3  valid:   2  signed:  42  trust: 2-, 0q, 0n, 0m, 0f, 0u
  gpg: next trustdb check due at 2035-01-22
  gpg: Good 

Bug#984884: libgcrypt20: Unknown error executing apt-key [Bullseye]

[Mateusz Rejek]

Hi,

Interestingly enough got the same problem on ARMHF after moving to bullseye.

I have version 1.8.7-6 installed over 1.8.4-5+deb10u1

# cat /var/log/dpkg.log.1 | grep libgcrypt
> 2021-09-07 13:07:54 upgrade libgcrypt20:armhf 1.8.4-5+deb10u1 1.8.7-6
> 2021-09-07 13:07:54 status half-configured libgcrypt20:armhf
> 1.8.4-5+deb10u1
> 2021-09-07 13:07:54 status unpacked libgcrypt20:armhf 1.8.4-5+deb10u1
> 2021-09-07 13:07:54 status half-installed libgcrypt20:armhf 1.8.4-5+deb10u1
> 2021-09-07 13:07:54 status unpacked libgcrypt20:armhf 1.8.7-6
> 2021-09-07 13:07:54 configure libgcrypt20:armhf 1.8.7-6 
> 2021-09-07 13:07:54 status unpacked libgcrypt20:armhf 1.8.7-6
> 2021-09-07 13:07:54 status half-configured libgcrypt20:armhf 1.8.7-6
> 2021-09-07 13:07:54 status installed libgcrypt20:armhf 1.8.7-6


and confirmed to be OK:

# dpkg -s libgcrypt20
> Package: libgcrypt20
> Status: install ok installed
> Priority: optional
> Section: libs
> Installed-Size: 1027
> Maintainer: Debian GnuTLS Maintainers <
> pkg-gnutls-ma...@lists.alioth.debian.org>
> Architecture: armhf
> Multi-Arch: same
> Version: 1.8.7-6
> Depends: libc6 (>= 2.28), libgpg-error0 (>= 1.25)
> Suggests: rng-tools
> Description: LGPL Crypto library - runtime library
>  libgcrypt contains cryptographic functions.  Many important free
>  ciphers, hash algorithms and public key signing algorithms have been
>  implemented:
>  .
>  Arcfour, Blowfish, CAST5, DES, AES, Twofish, Serpent, rfc2268 (rc2), SEED,
>  Poly1305, Camellia, ChaCha20, IDEA, Salsa, Blake-2, CRC, MD2, MD4, MD5,
>  RIPE-MD160, SHA-1, SHA-256, SHA-512, SHA3-224, SHA3-256, SHA3-384,
> SHA3-512,
>  SHAKE128, SHAKE256, Tiger, Whirlpool, DSA, DSA2, ElGamal, RSA, ECC
>  (Curve25519, sec256k1, GOST R 34.10-2001 and GOST R 34.10-2012, etc.)
> Homepage: https://directory.fsf.org/project/libgcrypt/


gpg is linking to libgcrypt.so.20

# ldd  /usr/bin/gpg
> linux-vdso.so.1 (0x7ed53000)
> /usr/lib/arm-linux-gnueabihf/libarmmem-${PLATFORM}.so =>
> /usr/lib/arm-linux-gnueabihf/libarmmem-v7l.so (0x76ec2000)
> libz.so.1 => /lib/arm-linux-gnueabihf/libz.so.1 (0x76e85000)
> libbz2.so.1.0 => /lib/arm-linux-gnueabihf/libbz2.so.1.0 (0x76e65000)
> libsqlite3.so.0 => /usr/lib/arm-linux-gnueabihf/libsqlite3.so.0
> (0x76d39000)
> libgcrypt.so.20 => /lib/arm-linux-gnueabihf/libgcrypt.so.20 (0x76c96000)
> libreadline.so.8 => /lib/arm-linux-gnueabihf/libreadline.so.8 (0x76c43000)
> libassuan.so.0 => /usr/lib/arm-linux-gnueabihf/libassuan.so.0 (0x76c23000)
> libgpg-error.so.0 => /lib/arm-linux-gnueabihf/libgpg-error.so.0
> (0x76bf6000)
> libc.so.6 => /lib/arm-linux-gnueabihf/libc.so.6 (0x76aa2000)
> /lib/ld-linux-armhf.so.3 (0x76ed7000)
> libm.so.6 => /lib/arm-linux-gnueabihf/libm.so.6 (0x76a33000)
> libpthread.so.0 => /lib/arm-linux-gnueabihf/libpthread.so.0 (0x76a07000)
> libdl.so.2 => /lib/arm-linux-gnueabihf/libdl.so.2 (0x769f3000)
> libtinfo.so.6 => /lib/arm-linux-gnueabihf/libtinfo.so.6 (0x769c1000)


That is pointing to libgcrypt.so.20.0.3

# ls -al /lib/arm-linux-gnueabihf/libgcrypt.so.20
> lrwxrwxrwx 1 root root 19 Sep  7 14:30
> /lib/arm-linux-gnueabihf/libgcrypt.so.20 -> libgcrypt.so.20.0.3


but in the system there also:

# ls -al /usr/lib/arm-linux-gnueabihf/libgcrypt.so.20
> lrwxrwxrwx 1 root root 19 May 27 18:07
> /usr/lib/arm-linux-gnueabihf/libgcrypt.so.20 -> libgcrypt.so.20.2.8


coming from:

root@rpi3:~# dpkg -L libgcrypt20
> /.
> /usr
> /usr/lib
> /usr/lib/arm-linux-gnueabihf
> /usr/lib/arm-linux-gnueabihf/libgcrypt.so.20.2.8
> /usr/share
> /usr/share/doc
> /usr/share/doc/libgcrypt20
> /usr/share/doc/libgcrypt20/AUTHORS.gz
> /usr/share/doc/libgcrypt20/NEWS.gz
> /usr/share/doc/libgcrypt20/README.gz
> /usr/share/doc/libgcrypt20/THANKS.gz
> /usr/share/doc/libgcrypt20/changelog.Debian.gz
> /usr/share/doc/libgcrypt20/changelog.gz
> /usr/share/doc/libgcrypt20/copyright
> /usr/lib/arm-linux-gnueabihf/libgcrypt.so.20


After removing old lib from /lib/arm-linux-gnueabihf/libgcrypt.so.20,
leaving /usr/lib/arm-linux-gnueabihf/libgcrypt.so.20 in place and
re-running ldconfig

I moved from

# gpg --version
> gpg: Fatal: libgcrypt is too old (need 1.8.0, have 1.6.3)


to

# gpg --version
> gpg (GnuPG) 2.2.27
> libgcrypt 1.8.8
> Copyright (C) 2021 Free Software Foundation, Inc.
> License GNU GPL-3.0-or-later 
> This is free software: you are free to change and redistribute it.
> There is NO WARRANTY, to the extent permitted by law.

Home: //.gnupg
> Supported algorithms:
> Pubkey: RSA, ELG, DSA, ECDH, ECDSA, EDDSA
> Cipher: IDEA, 3DES, CAST5, BLOWFISH, AES, AES192, AES256, TWOFISH,
> CAMELLIA128, CAMELLIA192, CAMELLIA256
> Hash: SHA1, RIPEMD160, SHA256, SHA384, SHA512, SHA224
> Compression: Uncompressed, ZIP, ZLIB, BZIP2


This was following an dist-upgrade from Debian 10 to Debian 11.

IMO problem is coming from libgcrypt moving in Debian 11 from
/lib/arm-linux-gnueabihf/ to /usr/lib/arm-linux-gnueabihf/ and leaving old
lib behind
--
Mat

Bug#994011: ghostscript: CVE-2021-3781

[Salvatore Bonaccorso]

Hi Jonas,

On Thu, Sep 09, 2021 at 08:09:42PM +0200, Jonas Smedegaard wrote:
> Hi Salvatore,
> 
> Quoting Salvatore Bonaccorso (2021-09-09 19:20:08)
> > The following vulnerability was published for ghostscript.
> > 
> > CVE-2021-3781[0].
> 
> I have prepared a package fixing this issue, available at 
> https://salsa.debian.org/printing-team/ghostscript/-/tree/debian/bullseye
> 
> Please tell how I should proceed with it - or feel free to proceed 
> yourself from here.

I did actually already uploaded earlier today to the embargoed queues,
waiting for the builds of mips64el and s390x yet, but then hope to
release the DSA soon.

Regards,
Salvatore

Bug#994013: libc6-dev: sys_errlist.h is missing

[Elimar Riesebieter]

Package: libc6-dev
Version: 2.32-2
Severity: important
X-Debbugs-Cc: e...@lxtec.de

Dear maintainers,

since 2.32 /usr/include/x86_64-linux-gnu/bits/sys_errlist.h is
missing. I identyfied this issue by rebuilding a kernel without
making clean in the source tree.

Thanks
Elimar

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

Kernel: Linux 5.10.63-toy-lxtec-amd64 (SMP w/8 CPU threads)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE
Locale: LANG=de_DE.utf8, LC_CTYPE=de_DE.utf8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: sysvinit (via /sbin/init)

Versions of packages libc6-dev depends on:
ii  libc-dev-bin2.32-2
ii  libc6   2.32-2
ii  libcrypt-dev1:4.4.25-2
ii  libnsl-dev  1.3.0-2
ii  linux-libc-dev  5.10.46-4
ii  rpcsvc-proto1.4.2-4

libc6-dev recommends no packages.

Versions of packages libc6-dev suggests:
pn  glibc-doc 
pn  manpages-dev  

-- no debconf information

Bug#994001: openssh-server: Almost locked out due #990456

[Aristeu Rozanski]

On Thu, Sep 09, 2021 at 05:23:29PM +0100, Colin Watson wrote:
> We can add some kind of check that would fail the installation in this
> situation, but please migrate to using some other site-specific group
> for this ASAP.  The ssh/_ssh group is an internal implementation detail
> used only to ensure that private key material cannot be extracted from
> running ssh-agent processes using ptrace(2); it's not intended to have
> users added to it.

Done, thanks.

-- 
Aristeu

Bug#993974: mpv: Can't play anything anymore

[Sven Joachim]

Control: affects -1 - mpv
Control: reassign -1 mpv 0.33.1-1
Control: severity -1 serious

On 2021-09-09 09:16 +0200, Sebastian Ramacher wrote:

> Control: reassign -1 src:ffmpeg 7:4.4-1
> Control: retitle -1 ffmpeg: bump symbol versions to generate dependencies 
> with >= 7:4.4

I do not think this is the right solution.

> On 2021-09-08 19:45:03 -0300, Nelson A. de Oliveira wrote:
>> Package: mpv
>> Version: 0.33.1-1
>> Severity: grave
>> Justification: renders package unusable
>>
>> Hi!
>>
>> After upgrading mpv from 0.32.0-3 to 0.33.1-1 it seems that I can't play
>> anything anymore.
>> (downgrading to 0.32.0-3 I can play videos again)
>>
>> =
>> $ mpv palestra.mp4
>> libavutil: 56.70.100 -> 56.51.100
>> zsh: abort  mpv palestra.mp4

It is mpv's own code which does the library version check and aborts
here, see check_library_versions() in common/av_log.c.

There used to be a Debian patch to prevent that, but it was removed
rather than rebased in 0.33.1-1[1].

Cheers,
   Sven


1. 
https://salsa.debian.org/multimedia-team/mpv/-/commit/280e7916502baa177bbd23435f0ce16a56c8be21#4850c9e1d1b2b6d5c3448c16e5dcf6fbf07b338a

Bug#994012: librust-html5ever-dev - dependencies not available

[Mechtilde Stehmann]

Package: librust-html5ever-dev


The depencencies aren't available at bullseye, bookworm, sid


I am surprised that the package came to Bullseye at all.


-- System Information:
Debian Release: bookworm/sid
  APT prefers testing
  APT policy: (400, 'testing'), (300, 'unstable'), (200, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.10.0-8-amd64 (SMP w/4 CPU cores)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8),
LANGUAGE=de_DE.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash


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

Bug#993668: CUPS is missing after a default GNOME Desktop Install

[Brian Potkin]

On Sat 04 Sep 2021 at 16:16:50 +0200, Nader Nooryani wrote:

> Package: task-gnome-desktop
> Version: 3.68
> 
> As of Debian 11, Print Server is no longer included as an option in the
> Debian installer if you use the defaults: Debian desktop environment, GNOME
> and standard system utilities.  Ref:
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=950553
> 
> This leaves the user without CUPS after a default install.  This should
> perhaps be included in task-gnome-desktop
> 
> Suggestion: It may be wise to include CUPS in task-gnome-desktop or
> somewhere else, since there are no instructions informing the user how they
> can enable support for printing.
> 
> I am using Linux debian 5.10.0-8-amd64 #1 SMP Debian 5.10.46-4 (2021-08-03)
> x86_64 GNU/Linux

>From a previous mail to -boot:

 > I have written a bit more about this on Reddit as well.
 > https://www.reddit.com/r/debian/comments/pgl6c9/debian_11_and_printing/

It would be nice if the reddit thread could be updated to record the
responsive and timely intervention from the d-i maintainers.

Regards,

Brian.

Bug#993968: buster-pu: package telegram-desktop/2.6.1+ds-1+deb11u1

[Nicholas Guriev]

Hello! Thank you for the quick feedback! I do take your point.

On Чт, 2021-09-09 at 08:52 +0100, Jonathan Wiltshire wrote:
> 
> On Wed, Sep 08, 2021 at 10:49:30PM +0300, Nicholas Guriev wrote:
> > A possible test-case is described in the aforementioned bug report.
> 
> It is, but you haven't said what testing you have done for this upload -
> that's what I'm really interested in here. In the bug report you say:
> 
> > The patch that should fix the issue is attached.
> 
> which doesn't help to clarify much.

I personally did a local build with pbuilder(8), followed the steps and
made sure the patched application was not closed abruptly.

Those steps describe interaction between two accounts, first one uses
most recent version (either desktop or mobile) and second one is logged
into the app of version 2.6.1+ds-1. I had no chance to verify that the
message would disappear after 30 days, though. A computer should be
uptime all these 30 days, or the timer will be reset.

Maybe is there something I can add to the original bug report to clarify
the issue or explain the patch? I thought it was understandable. But
perhaps my eyes are swimming.

> This changelog doesn't easily help a user to understand why they want this
> update. It doesn't need an essay but briefly describing what this is fixing
> would help more them I think.

Ok. I should have appended some kind of line like "- Fixes crash on a
long-lived message when auto-delete is set".



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

Bug#994011: ghostscript: CVE-2021-3781

[Jonas Smedegaard]

Hi Salvatore,

Quoting Salvatore Bonaccorso (2021-09-09 19:20:08)
> The following vulnerability was published for ghostscript.
> 
> CVE-2021-3781[0].

I have prepared a package fixing this issue, available at 
https://salsa.debian.org/printing-team/ghostscript/-/tree/debian/bullseye

Please tell how I should proceed with it - or feel free to proceed 
yourself from here.


 - Jonas

-- 
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/

 [x] quote me freely  [ ] ask before reusing  [ ] keep private

signature.asc
Description: signature

Bug#992692: general: Use https for {deb,security}.debian.org by default

[Simon Richter]

Hi,

On 04.09.21 22:12, Hideki Yamane wrote:


The TLS layer is not part of the security model, so we'd be teaching
users to look for the wrong thing, kind of like the "encrypted with SSL"
badges on web pages in the 90ies.



  Is there any strong reason to use HTTP than HTTPS now?


The strongest reason (IMO) in favor of unencrypted transmission is that 
it doesn't introduce a policy decision. The package "ca-certificates" 
must be installed and a checkmark set for the "mozilla/ISRG_Root_X1.crt" 
certificate, otherwise updates will break.


If we want to have HTTPS as default, we need additional logic to make 
sure certificates are installed and cannot be deinstalled (so Essential 
or a strong dependency chain from an Essential package) and that the 
certificate cannot be deactivated, or apt needs its own repository of 
trusted certificates.


With the current Docker images:

$ docker run --rm -it debian:bullseye
root@32529bf86cd3:/# sed -i -e s/http/https/ /etc/apt/sources.list
root@32529bf86cd3:/# apt update
Err:1 https://deb.debian.org/debian bullseye InRelease
  Certificate verification failed: The certificate is NOT trusted. The 
certificate issuer is unknown.  Could not handshake: Error in the 
certificate verification. [IP: 199.232.138.132 443]
Err:2 https://security.debian.org/debian-security bullseye-security 
InRelease
  Certificate verification failed: The certificate is NOT trusted. The 
certificate issuer is unknown.  Could not handshake: Error in the 
certificate verification. [IP: 151.101.66.132 443]

Err:3 https://deb.debian.org/debian bullseye-updates InRelease
  Certificate verification failed: The certificate is NOT trusted. The 
certificate issuer is unknown.  Could not handshake: Error in the 
certificate verification. [IP: 199.232.138.132 443]


So changing the default is not sufficient here, we'd need a lot of 
additional work and testing to ensure this works for everyone, not just 
the desktop users.


Another important argument is that it creates a dependency on 
third-party commercial CDNs, and their *continued* sponsorship.


Debian is very conservative when spending money and generally shies away 
from recurring expenses because we do not want to find us in a situation 
where we are dependent on an external entity making a timely donation in 
order to keep operations running, so I wonder why we are that accepting 
of it in one of our core services, and I certainly don't think we should 
be adding additional roadblocks should we ever need to find an alternative.


We have a (crude) load-balancing framework in infrastructure we control 
that can point requests towards a set of untrusted mirrors, and while 
it's nice that we don't *need* to use this fallback plan, it is 
reassuring it is there.



  Should we teach all our users (including non-tech) about "Secure APT"
  mechanism?


If they ask why we're not using HTTPS, yes: it helps clear up the 
misconception that anything with an "s" in it is secure and can be trusted.


Anyone who configures an additional source needs to know how the 
authentication mechanism works anyway, so we're not gaining anything 
there either.


   Simon



OpenPGP_signature
Description: OpenPGP digital signature

Bug#993946: fakechroot: adduser fails with glibc 2.32

[Johannes Schauer Marin Rodrigues]

Hi,

I NMU-ed fakechroot with the patch from my last mail. The debdiff is attached.
As per devref I uploaded to DELAYED/5 in case you have objections and want to
cancel it.

Thanks!

cheers, joschdiff -Nru fakechroot-2.19/debian/changelog fakechroot-2.19/debian/changelog
--- fakechroot-2.19/debian/changelog	2021-08-17 10:58:10.0 +0200
+++ fakechroot-2.19/debian/changelog	2021-09-09 19:50:34.0 +0200
@@ -1,3 +1,10 @@
+fakechroot (2.19-3.5) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Wrap __nss_files_fopen for getpwnam in glibc >= 2.32 (closes: #993946)
+
+ -- Johannes Schauer Marin Rodrigues   Thu, 09 Sep 2021 19:50:34 +0200
+
 fakechroot (2.19-3.4) unstable; urgency=medium
 
   * Non-maintainer upload.
diff -Nru fakechroot-2.19/debian/patches/0001-Wrap-__nss_files_fopen-for-getpwnam-in-glibc-2.32.patch fakechroot-2.19/debian/patches/0001-Wrap-__nss_files_fopen-for-getpwnam-in-glibc-2.32.patch
--- fakechroot-2.19/debian/patches/0001-Wrap-__nss_files_fopen-for-getpwnam-in-glibc-2.32.patch	1970-01-01 01:00:00.0 +0100
+++ fakechroot-2.19/debian/patches/0001-Wrap-__nss_files_fopen-for-getpwnam-in-glibc-2.32.patch	2021-09-09 19:48:29.0 +0200
@@ -0,0 +1,112 @@
+From 14ab1b7910bf080b715d8ae846f8fc24b72823ed Mon Sep 17 00:00:00 2001
+From: Johannes Schauer Marin Rodrigues 
+Date: Thu, 9 Sep 2021 18:21:07 +0200
+Subject: [PATCH] Wrap __nss_files_fopen for getpwnam in glibc >= 2.32
+
+Starting with glibc 2.32 the compat nss module for getpwnam calls
+__nss_files_fopen (which is a GLIBC_PRIVATE symbol provided by glibc)
+instead of fopen (see 299210c1fa67e2dfb564475986fce11cd33db9ad). This
+leads to getpwnam calls accessing /etc/passwd from *outside* the chroot
+and as a result programs like adduser do not work correctly anymore
+under fakechroot.
+
+Adhemerval Zanella (azanella) argued on IRC:
+
+ > But another problem is the ship has sailed, so there are nss modules that
+ > will bind to an external symbol. And there is not much we can do about
+ > it. And since nss modules are most compat, I am not sure community will
+ > be willing to move back. I think it will be better to add the interpose
+ > logic of private symbols on fakechroot instead, it is ugly but it is
+ > better than messing even more with the nss interface.
+
+Thus, instead of changing glibc, we instead wrap __nss_files_fopen.
+---
+ configure.ac|  1 +
+ src/Makefile.am |  1 +
+ src/__nss_files_fopen.c | 60 +
+ 3 files changed, 62 insertions(+)
+ create mode 100644 src/__nss_files_fopen.c
+
+--- a/configure.ac
 b/configure.ac
+@@ -134,6 +134,7 @@ AC_CHECK_FUNCS(m4_normalize([
+ __getwd_chk
+ __lxstat
+ __lxstat64
++__nss_files_fopen
+ __open
+ __open_2
+ __open64
+--- a/src/Makefile.am
 b/src/Makefile.am
+@@ -7,6 +7,7 @@ libfakechroot_la_SOURCES = \
+ __lxstat.c \
+ __lxstat64.c \
+ __lxstat64.h \
++__nss_files_fopen.c \
+ __open.c \
+ __open64.c \
+ __open64_2.c \
+--- /dev/null
 b/src/__nss_files_fopen.c
+@@ -0,0 +1,60 @@
++/*
++libfakechroot -- fake chroot environment
++Copyright (c) 2010, 2013 Piotr Roszatycki 
++
++This library is free software; you can redistribute it and/or
++modify it under the terms of the GNU Lesser General Public
++License as published by the Free Software Foundation; either
++version 2.1 of the License, or (at your option) any later version.
++
++This library is distributed in the hope that it will be useful,
++but WITHOUT ANY WARRANTY; without even the implied warranty of
++MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
++Lesser General Public License for more details.
++
++You should have received a copy of the GNU Lesser General Public
++License along with this library; if not, write to the Free Software
++Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307  USA
++*/
++
++
++#include 
++
++/*
++ * Starting with glibc 2.32 the compat nss module for getpwnam calls
++ * __nss_files_fopen (which is a GLIBC_PRIVATE symbol provided by glibc)
++ * instead of fopen (see 299210c1fa67e2dfb564475986fce11cd33db9ad). This
++ * leads to getpwnam calls accessing /etc/passwd from *outside* the chroot
++ * and as a result programs like adduser do not work correctly anymore
++ * under fakechroot.
++ *
++ * Adhemerval Zanella (azanella) argued on IRC:
++ *
++ *  > But another problem is the ship has sailed, so there are nss modules that
++ *  > will bind to an external symbol. And there is not much we can do about
++ *  > it. And since nss modules are most compat, I am not sure community will
++ *  > be willing to move back. I think it will be better to add the interpose
++ *  > logic of private symbols on fakechroot instead, it is ugly but it is
++ *  > better than messing even more with the nss interface.
++ *
++ * Thus, instead of changing glibc, we instead wrap 

Bug#994010: Acknowledgement (libvirt-daemon: cannot create lvm volume in logical pool if there is existing signature on that device)

[Jonas]

Control: forwarded -1 https://bugzilla.redhat.com/show_bug.cgi?id=1940413

Bug#993968: telegram-desktop 2.6.1+ds-1+deb11u1 flagged for acceptance

[Jonathan Wiltshire]

package release.debian.org
tags 993968 = bullseye pending
thanks

Hi,

The upload referenced by this bug report has been flagged for acceptance into 
the proposed-updates queue for Debian bullseye.

Thanks for your contribution!

Upload details
==

Package: telegram-desktop
Version: 2.6.1+ds-1+deb11u1

Explanation: avoid crash when auto-delete is enabled

Bug#992063: fetchmail 6.4.16-4+deb11u1 flagged for acceptance

[Jonathan Wiltshire]

package release.debian.org
tags 992063 = bullseye pending
thanks

Hi,

The upload referenced by this bug report has been flagged for acceptance into 
the proposed-updates queue for Debian bullseye.

Thanks for your contribution!

Upload details
==

Package: fetchmail
Version: 6.4.16-4+deb11u1

Explanation: fix segmentation fault and security regression

Bug#993978: linux-image-5.10.0-8-arm64: host hangs after some time of use

[Salvatore Bonaccorso]

On Thu, Sep 09, 2021 at 05:11:48PM +0200, Salvatore Bonaccorso wrote:
> Hi Paul,
> 
> On Thu, Sep 09, 2021 at 11:00:26AM +0200, Salvatore Bonaccorso wrote:
> > Hi Paul,
> > 
> > On Thu, Sep 09, 2021 at 09:37:02AM +0200, Paul Gevers wrote:
> > > Package: src:linux
> > > Version: 5.10.46-4
> > > X-Debbugs-CC: debian...@lists.debian.org, a...@debian.org
> > > Severity: serious
> > > Justification: data loss
> > > 
> > > Hi,
> > > 
> > > As discussed over IRC, here is the bug report for one of the hanging
> > > arm64 hosts we have for ci.debian.net.
> > > 
> > > Since the upgrade of our hosts to bullseye (days before the bullseye
> > > release) we have been experiencing random loss of access to our hosts.
> > > For the hosts that have some form of out-of-bound access, I tried to use
> > > that to see what's going on, but at AWS our account doesn't have the
> > > right permissions to use the serial port out-of-bound access and all
> > > other forms that I tried on all hosts that I have access to some for of
> > > out-of-bound access that didn't work.
> > > 
> > > Since the bullseye release I've rebooted (externally triggered) already
> > > dozens of times and for those host that don't allow rebooting (AWS
> > > again) I had to reprovision the hosts.
> > > 
> > > All the architectures (amd64, arm64, ppc64el and s390x) that we have
> > > experience these hangs. I'm absolutely not claiming that the root cause
> > > is the same, but on buster we didn't experience this (our s390x host
> > > never workerd on buster so I don't claim regression there), so there is
> > > a pattern. However, the symptoms don't look completely the same 
> > > everywhere.
> > > 
> > > On one of our arm64 hosts (we call ci-worker-armel-01) I found the
> > > attached logging as the final logs in the journal.
> > 
> > I suspect it's the same issue as fixed by
> > https://git.kernel.org/linus/ad9f151e560b016b6ad3280b48e42fa11e1a5440
> > upstream,
> > https://lore.kernel.org/lkml/ef07b205c3cb1...@google.com/
> > 
> > The fix landed in 5.13-rc7 (was backported to 5.12.13 as well, but not
> > 5.10.y). It seems it requires more work to address it as well in
> > 5.10.y.
> > 
> > Asked upstream in
> > https://lore.kernel.org/lkml/ytkj4xh2ol075...@eldamar.lan/
> 
> The needed patches are now there:
> https://lore.kernel.org/stable/20210909140337.29707-1...@strlen.de/
> and queued for the next 5.10.y upload (so I expect it to have thos
> latest in our first bullseye point release).
> 
> I will try to cherry-pick those, if you can check they fix the issue
> that would be great.

If you can/want to give it a try testing binaries (not signed, if you
trust nevertheless), and only for amd64:

https://people.debian.org/~carnil/tmp/linux/5.10.46-4a~test/

Regards,
Salvatore

Bug#994011: ghostscript: CVE-2021-3781

[Salvatore Bonaccorso]

Source: ghostscript
Version: 9.53.3~dfsg-7
Severity: grave
Tags: security upstream
Justification: user security hole
Forwarded: https://bugs.ghostscript.com/show_bug.cgi?id=704342
X-Debbugs-Cc: car...@debian.org, Debian Security Team 

Hi,

The following vulnerability was published for ghostscript.

CVE-2021-3781[0].

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

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2021-3781
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-3781
[1] https://bugs.ghostscript.com/show_bug.cgi?id=704342 (not public yet)
[2] https://git.ghostscript.com/?p=ghostpdl.git;a=commitdiff;h=a9bd3dec9fde

Regards,
Salvatore

Bug#994010: libvirt-daemon: cannot create lvm volume in logical pool if there is existing signature on that device

[Jonas L.]

Package: libvirt-daemon
Version: 7.0.0-3
Severity: important

Dear Maintainer,

I cannot create a LVM volume if there is an existing signature on that device.

This happen while trying to clone a VM or to create a new VM.

This bug has been comfirmed 
(https://bugzilla.redhat.com/show_bug.cgi?id=1940413) and
patched on upstream version 7.6
(https://gitlab.com/libvirt/libvirt/-/commit/d91a3e96c04ae093f4422b52e259750c86ba79fc).

I was unsure whether I should fill a bug report in order to backport a fix to 
stable.

A workaround is to run the lvcreate command manually. But it is a nightmare 
when cloning a VM, as you need
to create the new volume to wipe it, and remove it to clone the orignal disk.

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

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

Versions of packages libvirt-daemon depends on:
ii  libblkid1   2.36.1-8
ii  libc6   2.31-13
ii  libdevmapper1.02.1  2:1.02.175-2.1
ii  libgcc-s1   10.2.1-6
ii  libglib2.0-02.66.8-1
ii  libnetcf1   1:0.2.8-1.1
ii  libparted2  3.4-1
ii  libpcap0.8  1.10.0-2
ii  libpciaccess0   0.16-1
ii  libselinux1 3.1-3
ii  libudev1247.3-6
ii  libvirt-daemon-driver-qemu  7.0.0-3
ii  libvirt07.0.0-3
ii  libxml2 2.9.10+dfsg-6.7

Versions of packages libvirt-daemon recommends:
ii  libvirt-daemon-driver-lxc   7.0.0-3
ii  libvirt-daemon-driver-vbox  7.0.0-3
ii  libvirt-daemon-driver-xen   7.0.0-3
ii  libxml2-utils   2.9.10+dfsg-6.7
ii  netcat-openbsd  1.217-3
ii  qemu-system-x86 [qemu-kvm]  1:5.2+dfsg-11

Versions of packages libvirt-daemon suggests:
pn  libvirt-daemon-driver-storage-gluster   
pn  libvirt-daemon-driver-storage-iscsi-direct  
pn  libvirt-daemon-driver-storage-rbd   
pn  libvirt-daemon-driver-storage-zfs   
ii  libvirt-daemon-system   7.0.0-3
pn  numad   

-- no debconf information

Bug#994009: autopkgtest fails on 32bit

[Alois Micard]

Source: golang-github-vulcand-oxy
Version: 1.3.0-2
Severity: serious
X-Debbugs-Cc: creekor...@debian.org

See:

- 
https://ci.debian.net/data/autopkgtest/testing/armhf/g/golang-github-vulcand-oxy/14883551/log.gz
- 
https://ci.debian.net/data/autopkgtest/testing/i386/g/golang-github-vulcand-oxy/14883550/log.gz

Cheers,

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

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

Bug#994001: openssh-server: Almost locked out due #990456

[Colin Watson]

On Thu, Sep 09, 2021 at 11:08:05AM -0400, Aristeu Rozanski wrote:
> Jokes aside, I had 'ssh' group defined for a good while as to be used as
> group of people allowed to ssh in the machine (AllowGroup, root login is
> disabled) and a recent upgrade, probably due #990456, that group got renamed
> as '_ssh' and I wasn't able to login anymore. Thankfully I had a session open
> since before the change and was able to figure out what was going on.
> 
> Please change the upgrade script to check if the group ssh already contains
> users before doing the change.

We can add some kind of check that would fail the installation in this
situation, but please migrate to using some other site-specific group
for this ASAP.  The ssh/_ssh group is an internal implementation detail
used only to ensure that private key material cannot be extracted from
running ssh-agent processes using ptrace(2); it's not intended to have
users added to it.

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

Bug#994006: libc6: NSS modules changes require a restart of systemd-logind, which is not possible

[Aurelien Jarno]

On 2021-09-09 18:26, Aurelien Jarno wrote:
> Package: libc6
> Version: 2.32-1
> Severity: serious
> X-Debbugs-Cc: pkg-systemd-maintain...@lists.alioth.debian.org
> 
> The NSS modules provided by glibc 2.32 require new symbols, which are
> therefore not provided by libc6 2.31. This is why we require restarting
> daemons after the new libc6 is installed.
> 
> systemd-logind is also using NSS modules, so it needs to be restarted.
> Unfortunately that's not something possible without killing Xorg
> sessions (see bug#919509). Not restarting systemd-logind means that it
> is not able to load new NSS modules, howeveralready loaded modules are
> still usable.

One way to workaround the issue would be to force systemd-logind to do a
NSS lookup, just like it it s already the case when a user log onto the
system.

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

Bug#994008: debian-policy: Clarify relationship between source and binary packages' archive areas

[Simon McVittie]

Package: debian-policy
Version: 4.6.0.1
Severity: wishlist
Tags: patch
X-Debbugs-Cc: ftpmas...@debian.org

If you have an upstream project consisting of Free source code with a
mixture of Free and non-Free dependencies, it isn't currently clear how
that should be packaged.

For example, if gnome-software added a steam plugin that was itself Free
Software, but had Depends: steam, then it would be in this situation:
the program and the flatpak and snap plugins would still be suitable
for main, but the steam plugin would need to go in contrib.

Based on the precedent seen in the bumblebee package, I believe the
ftp team's intention is that packages like this are allowed to be a
single source package in main, which builds binary packages for main
and contrib, even though this means the contrib binary packages don't
match their source package's archive area.

I think I remember talking to a ftp team member about this in person
and coming to the conclusion that there are good reasons for none of
the other possible source/binary archive area mismatches to be allowed.

In the form of a table, the allowed source/binary combinations are:

  |binary   |
  | main  contrib  non-free |
 -|-|
 main |  yesyes  -  |
 source  contrib  |   - yes  -  |
 non-free |   -  -  yes |

ftp team: is this correct?

If it is, I attach proposed patches for Policy. Their commit messages
attempt to capture the rationale for why the other situations are not
allowed; corrections/clarifications welcome.

Thanks,
smcv
>From eda0f325301bd514e5ac94328dd4b5a01960634a Mon Sep 17 00:00:00 2001
From: Simon McVittie 
Date: Thu, 9 Sep 2021 15:43:20 +0100
Subject: [PATCH 1/2] archive: Point out that mixed main/contrib source
 packages can exist

Most source packages produce only binary packages in the same archive
area, but a few source packages in main (such as bumblebee) produce
a mixture of main and contrib binary packages.

If an upstream project is in this situation (for example a program with
optional plugins that have non-free dependencies) it isn't entirely
obvious how to package it; clarify that a single source package in main
is considered to be appropriate in this case, as long as no non-free
build-dependencies are required.

Signed-off-by: Simon McVittie 
---
 policy/ch-archive.rst | 13 +
 1 file changed, 13 insertions(+)

diff --git a/policy/ch-archive.rst b/policy/ch-archive.rst
index ab04261..7829601 100644
--- a/policy/ch-archive.rst
+++ b/policy/ch-archive.rst
@@ -130,6 +130,19 @@ In addition, the packages in *main*
 
 - must meet all policy requirements presented in this manual.
 
+If a source package is in the *main* archive area, then each of the
+binary packages that it produces must be in either the *main* or *contrib*
+archive area. Each binary package's archive area is indicated by its
+``Section`` field: see :ref:`s-subsections`.
+
+When a *main* source package has a mixture of *main* and *contrib*
+binary packages, the source package and the *main* binary packages must
+follow the requirements for *main* packages, but the *contrib* binary
+packages may follow the weaker requirements for *contrib* packages.
+In particular, build-dependencies outside *main* are not allowed in
+these source packages, but the *contrib* binary packages may have runtime
+dependencies outside *main*.
+
 .. _s-contrib:
 
 The contrib archive area
-- 
2.33.0

>From 0b855a4a0dbb348269388985fc45c7887376a245 Mon Sep 17 00:00:00 2001
From: Simon McVittie 
Date: Thu, 9 Sep 2021 15:53:20 +0100
Subject: [PATCH 2/2] archive: Clarify binaries produced by contrib and
 non-free source

A source package outside main cannot produce main binary packages, because
we want main to be self-contained: if you download all main source
packages, that should give you the source code of all main binary
packages.

A source package in contrib cannot produce non-free binary packages,
because by definition contrib only contains free software (with non-free
dependencies, but those are not part of the source code).

A source package in non-free cannot produce contrib binary packages,
because we want main + contrib to be self-contained: if you download
all main or contrib source packages, that should give you the source
code of all main and contrib binary packages.

Signed-off-by: Simon McVittie 
---
 policy/ch-archive.rst | 8 
 1 file changed, 8 insertions(+)

diff --git a/policy/ch-archive.rst b/policy/ch-archive.rst
index 7829601..35b44bb 100644
--- a/policy/ch-archive.rst
+++ b/policy/ch-archive.rst
@@ -169,6 +169,10 @@ Examples of packages which would be included in *contrib* are:
 -  wrapper packages or other sorts of free accessories for non-free
programs.
 
+If a source package is in the *contrib* archive area, then each of the
+binary packages that it produces must also be in the 

Bug#994007: python-language-server: Consider switch to the python-lsp-server fork

[Tomas Janousek]

Source: python-language-server
Severity: normal

The palantir upstream seems to have gone dead: 
https://github.com/palantir/python-language-server/issues/935 and 
there's now a maintained fork here: 
https://github.com/python-lsp/python-lsp-server

Vim integrations such as nvim-lspconfig and ale have already dropped 
their support for pyls in favor of pylsp.


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

Kernel: Linux 5.10.0-8-amd64 (SMP w/4 CPU threads)
Kernel taint flags: TAINT_CPU_OUT_OF_SPEC, TAINT_USER
Locale: LANG=cs_CZ.UTF-8, LC_CTYPE=cs_CZ.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

-- 
Tomáš "liskin" ("Pivník") Janoušek, https://work.lisk.in/

Bug#994006: libc6: NSS modules changes require a restart of systemd-logind, which is not possible

[Aurelien Jarno]

Package: libc6
Version: 2.32-1
Severity: serious
X-Debbugs-Cc: pkg-systemd-maintain...@lists.alioth.debian.org

The NSS modules provided by glibc 2.32 require new symbols, which are
therefore not provided by libc6 2.31. This is why we require restarting
daemons after the new libc6 is installed.

systemd-logind is also using NSS modules, so it needs to be restarted.
Unfortunately that's not something possible without killing Xorg
sessions (see bug#919509). Not restarting systemd-logind means that it
is not able to load new NSS modules, howeveralready loaded modules are
still usable.

One visible consequence is that on systems where no user sessions have
been registered with systemd-logind, new sessions will fail to register
after the libc6 upgrade with the following king of error:

  sshd[647]: pam_systemd(sshd:session): Failed to create session: No such 
process

Not registering the session causes among other things XDG_RUNTIME_DIR to
not be defined (or even created), causing autopkgtest failures:
https://ci.debian.net/data/autopkgtest/testing/amd64/c/calibre/15138528/log.gz

Here is a simpler way to reproduce the problem:
- Schedule the libc6 upgrade from 2.31 to 2.32 (currently bookworm to
  sid) to happen on a system which hasn't seen any user login since it
  has been booted. For instance trigger it from /etc/rc.local.
- Log onto the system (for instance through TTY or SSH), observe the
  error message in the logs and the absence of XDG_RUNTIME_DIR in the
  environment.

Bug#994005: ITS: fakechroot

[Johannes Schauer Marin Rodrigues]

Source: fakechroot
Severity: important
X-Debbugs-Cc: dex...@debian.org, m...@qa.debian.org, piotr.roszaty...@gmail.com

Hi,

I intend to salvage the package fakechroot as it meets the following criteria:

 - the last maintainer upload was in 2016
 - the last four uploads were an NMUs (by myself) and there was no maintainer
   upload since then
 - the latest upstream release is not packaged (see #943400)
 - there are QA issues:
* debian/watch cannot find the latest upstream version
* the Vcs-Git field points to a non-existing VCS
* there is 1 lintian error and 4 warnings
* the standards-version is at 3.9.8 (from 2016)
 - the last activity I can see from Piotr is tagging #914995 as
   "fixed-upstream" in March 2019

Thanks!

cheers, josch

Bug#994004: ITP: r-bioc-bcellviper -- Human B-cell transcriptional interactome and expression data

[Steffen Moeller]

Package: wnpp
Severity: wishlist

Subject: ITP: r-bioc-bcellviper -- Human B-cell transcriptional interactome and 
expression data
Package: wnpp
Owner: Steffen Moeller 
Severity: wishlist

* Package name: r-bioc-bcellviper
  Version : 1.28.0
  Upstream Author : Mariano Javier Alvarez
* URL : 
https://bioconductor.org/packages/data/experiment/bcellViper/
* License : GPL-2+
  Programming Lang: GNU R
  Description : Human B-cell transcriptional interactome and expression data
 This package provides a human B-cell context-specific
 transcriptional regulatory network and a human normal B-cells
 dataset for the examples in package viper.

Remark: This package is maintained by Debian R Packages Maintainers at
   https://salsa.debian.org/r-pkg-team/r-bioc-bcellviper

Bug#993946: fakechroot: adduser fails with glibc 2.32

[Johannes Schauer Marin Rodrigues]

Control: tag -1 + patch
Control: forwarded -1 https://github.com/dex4er/fakechroot/issues/97

With the help of the glibc developer Adhemerval Zanella I managed to find a
solution for this problem. The attached patch wraps __nss_files_fopen from
glibc.--- a/configure.ac
+++ b/configure.ac
@@ -165,6 +165,7 @@ AC_CHECK_FUNCS(m4_normalize([
 __getwd_chk
 __lxstat
 __lxstat64
+__nss_files_fopen
 __open
 __open_2
 __open64
--- /dev/null
+++ b/src/__nss_files_fopen.c
@@ -0,0 +1,60 @@
+/*
+libfakechroot -- fake chroot environment
+Copyright (c) 2010, 2013 Piotr Roszatycki 
+
+This library is free software; you can redistribute it and/or
+modify it under the terms of the GNU Lesser General Public
+License as published by the Free Software Foundation; either
+version 2.1 of the License, or (at your option) any later version.
+
+This library is distributed in the hope that it will be useful,
+but WITHOUT ANY WARRANTY; without even the implied warranty of
+MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
+Lesser General Public License for more details.
+
+You should have received a copy of the GNU Lesser General Public
+License along with this library; if not, write to the Free Software
+Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307  USA
+*/
+
+
+#include 
+
+/*
+ * Starting with glibc 2.32 the compat nss module for getpwnam calls
+ * __nss_files_fopen (which is a GLIBC_PRIVATE symbol provided by glibc)
+ * instead of fopen (see 299210c1fa67e2dfb564475986fce11cd33db9ad). This
+ * leads to getpwnam calls accessing /etc/passwd from *outside* the chroot
+ * and as a result programs like adduser do not work correctly anymore
+ * under fakechroot.
+ *
+ * Adhemerval Zanella (azanella) argued on IRC:
+ *
+ *  > But another problem is the ship has sailed, so there are nss modules that
+ *  > will bind to an external symbol. And there is not much we can do about
+ *  > it. And since nss modules are most compat, I am not sure community will
+ *  > be willing to move back. I think it will be better to add the interpose
+ *  > logic of private symbols on fakechroot instead, it is ugly but it is
+ *  > better than messing even more with the nss interface.
+ *
+ * Thus, instead of changing glibc, we instead wrap __nss_files_fopen.
+ *
+ */
+#ifdef HAVE___NSS_FILES_FOPEN
+
+#include 
+#include "libfakechroot.h"
+
+
+wrapper(__nss_files_fopen, FILE *, (const char * path))
+{
+char fakechroot_abspath[FAKECHROOT_PATH_MAX];
+char fakechroot_buf[FAKECHROOT_PATH_MAX];
+debug("__nss_files_fopen(\"%s\")", path);
+expand_chroot_path(path);
+return nextcall(__nss_files_fopen)(path);
+}
+
+#else
+typedef int empty_translation_unit;
+#endif
--- a/src/Makefile.am
+++ b/src/Makefile.am
@@ -7,6 +7,7 @@ libfakechroot_la_SOURCES = \
 __lxstat.c \
 __lxstat64.c \
 __lxstat64.h \
+__nss_files_fopen.c \
 __open.c \
 __open64.c \
 __open64_2.c \


signature.asc
Description: signature

Bug#993988: debian-edu-config: consider to drop diskless workstation support as default for Main-Server+LTSP-Server profile

[Dominik George]

Hi,

> Like reported in #993935, a local admin might install additional 
> packages on a combined server causing potential leakage of sensible data
> in the SquashFS image file for diskless workstations.
> 
> It would be quite easy to drop the diskless workstation support (done by 
> default at first boot of a combined server), only provide thin client 
> support on the combined server and leave the (site specific) setup for 
> diskless ws to the local admin. (The manual should then contain hints 
> how to do this.)

I take it that by "drop support", you mean "not install by default"?

Diskless workstations are one (probably the) Unique Selling Point of
Debian Edu, so I would like to make very clear that dropping support
for it in general would be problematic.

-nik

-- 
Dominik George (1. Vorstandsvorsitzender, pädagogischer Leiter)
Teckids e.V. — Digitale Freiheit mit Jugend und Bildung
https://www.teckids.org/


signature.asc
Description: PGP signature

Bug#993855: rustc: Bootstrapping rustc for x32

[John Paul Adrian Glaubitz]

Control: -1 tags +patch

On 9/7/21 11:01, John Paul Adrian Glaubitz wrote:
> Once we have version 1.55.0 in unstable, we will be able to build the rustc
> package for x32 without any problems. I haven't verified the testsuite results
> though.

OK, Rust 1.55.0 was just released without this particular patch. So in order to
get it to work on x32, we will have to include the patch from [1].

Adrian

> [1] https://github.com/rust-lang/rust/pull/88668

-- 
 .''`.  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
From cd75af25e036301d7971f6f302cf6a5593b0a6b5 Mon Sep 17 00:00:00 2001
From: Harald van Dijk 
Date: Sun, 5 Sep 2021 16:42:36 +0100
Subject: [PATCH] Change more x64 size checks to not apply to x32.

Commit 95e096d6 changed a bunch of size checks already, but more have
been added, so this fixes the new ones the same way: the various size
checks that are conditional on target_arch = "x86_64" were not intended
to apply to x86_64-unknown-linux-gnux32, so add
target_pointer_width = "64" to the conditions.
---
 compiler/rustc_middle/src/mir/mod.rs| 8 
 compiler/rustc_parse/src/parser/attr_wrapper.rs | 2 +-
 src/librustdoc/html/render/context.rs   | 2 +-
 3 files changed, 6 insertions(+), 6 deletions(-)

diff --git a/compiler/rustc_middle/src/mir/mod.rs b/compiler/rustc_middle/src/mir/mod.rs
index 83f6e79d5fcf6..36afbc6cbf171 100644
--- a/compiler/rustc_middle/src/mir/mod.rs
+++ b/compiler/rustc_middle/src/mir/mod.rs
@@ -1708,7 +1708,7 @@ pub struct Place<'tcx> {
 pub projection: &'tcx List>,
 }
 
-#[cfg(target_arch = "x86_64")]
+#[cfg(all(target_arch = "x86_64", target_pointer_width = "64"))]
 static_assert_size!(Place<'_>, 16);
 
 #[derive(Copy, Clone, Debug, PartialEq, Eq, PartialOrd, Ord, Hash)]
@@ -2034,7 +2034,7 @@ pub enum Operand<'tcx> {
 Constant(Box>),
 }
 
-#[cfg(target_arch = "x86_64")]
+#[cfg(all(target_arch = "x86_64", target_pointer_width = "64"))]
 static_assert_size!(Operand<'_>, 24);
 
 impl<'tcx> Debug for Operand<'tcx> {
@@ -2172,7 +2172,7 @@ pub enum Rvalue<'tcx> {
 Aggregate(Box>, Vec>),
 }
 
-#[cfg(target_arch = "x86_64")]
+#[cfg(all(target_arch = "x86_64", target_pointer_width = "64"))]
 static_assert_size!(Rvalue<'_>, 40);
 
 #[derive(Clone, Copy, Debug, PartialEq, Eq, TyEncodable, TyDecodable, Hash, HashStable)]
@@ -2198,7 +2198,7 @@ pub enum AggregateKind<'tcx> {
 Generator(DefId, SubstsRef<'tcx>, hir::Movability),
 }
 
-#[cfg(target_arch = "x86_64")]
+#[cfg(all(target_arch = "x86_64", target_pointer_width = "64"))]
 static_assert_size!(AggregateKind<'_>, 48);
 
 #[derive(Copy, Clone, Debug, PartialEq, PartialOrd, Eq, TyEncodable, TyDecodable, Hash, HashStable)]
diff --git a/compiler/rustc_parse/src/parser/attr_wrapper.rs b/compiler/rustc_parse/src/parser/attr_wrapper.rs
index 9f06bdcc135ba..568682cc3e4e0 100644
--- a/compiler/rustc_parse/src/parser/attr_wrapper.rs
+++ b/compiler/rustc_parse/src/parser/attr_wrapper.rs
@@ -34,7 +34,7 @@ pub struct AttrWrapper {
 
 // This struct is passed around very frequently,
 // so make sure it doesn't accidentally get larger
-#[cfg(target_arch = "x86_64")]
+#[cfg(all(target_arch = "x86_64", target_pointer_width = "64"))]
 rustc_data_structures::static_assert_size!(AttrWrapper, 16);
 
 impl AttrWrapper {
diff --git a/src/librustdoc/html/render/context.rs b/src/librustdoc/html/render/context.rs
index 733bedfdde9b4..34f9c0a8187a6 100644
--- a/src/librustdoc/html/render/context.rs
+++ b/src/librustdoc/html/render/context.rs
@@ -69,7 +69,7 @@ crate struct Context<'tcx> {
 }
 
 // `Context` is cloned a lot, so we don't want the size to grow unexpectedly.
-#[cfg(target_arch = "x86_64")]
+#[cfg(all(target_arch = "x86_64", target_pointer_width = "64"))]
 rustc_data_structures::static_assert_size!(Context<'_>, 104);
 
 /// Shared mutable state used in [`Context`] and elsewhere.

Bug#974781: ftbfs with LLVM 13

[Matthias Klose]

also ftbfs with LLVM 13
see https://gcc.gnu.org/PR102260

Bug#994002: MPlayer fails to compile against ffmpeg 4.4

[Nicola Ferralis]

Package: mplayer
Version:2:1.4+ds1-1

When MPlayer (v. 2:1.4+ds1-1) is compiled with FFMPEG 4.4-5 (now in 
bookworm/sid) compilation fails. Log:


In file included from libmpcodecs/ad_spdif.c:25:
/usr/include/x86_64-linux-gnu/libavformat/avformat.h:888:21: note: 
declared here

  888 | AVCodecContext *codec;
  | ^
libmpcodecs/ad_spdif.c:303:43: error: 'AVStream' {aka 'struct AVStream'} 
has no member named 'info'

  303 | av_freep(_ctx->streams[0]->info);
  | ^~
make[2]: *** [Makefile:726: libmpcodecs/ad_spdif.o] Error 1
make[2]: *** Waiting for unfinished jobs

The patch in attachment (proposed here: 
https://bbs.archlinux.org/viewtopic.php?id=265578 
) fix the issue.


I am using Ubuntu 20.04, kernel 5.11.0-34-generic and libc6 2.31-0ubuntu9.
diff -Nru MPlayer-1.4.orig/libmpcodecs/ad_spdif.c 
MPlayer-1.4/libmpcodecs/ad_spdif.c
--- MPlayer-1.4.orig/libmpcodecs/ad_spdif.c 2016-03-06 08:00:49.0 
-0500
+++ MPlayer-1.4/libmpcodecs/ad_spdif.c  2021-09-09 10:22:49.0 -0400
@@ -298,14 +298,8 @@
 if (spdif_ctx->header_written)
 av_write_trailer(lavf_ctx);
 av_freep(_ctx->pb);
-if (lavf_ctx->streams) {
-av_freep(_ctx->streams[0]->codec);
-av_freep(_ctx->streams[0]->info);
-av_freep(_ctx->streams[0]);
-}
-av_freep(_ctx->streams);
-av_freep(_ctx->priv_data);
+avformat_free_context(lavf_ctx);
+lavf_ctx = NULL;
 }
-av_freep(_ctx);
 av_freep(_ctx);
 }

Bug#993978: linux-image-5.10.0-8-arm64: host hangs after some time of use

[Salvatore Bonaccorso]

Hi Paul,

On Thu, Sep 09, 2021 at 11:00:26AM +0200, Salvatore Bonaccorso wrote:
> Hi Paul,
> 
> On Thu, Sep 09, 2021 at 09:37:02AM +0200, Paul Gevers wrote:
> > Package: src:linux
> > Version: 5.10.46-4
> > X-Debbugs-CC: debian...@lists.debian.org, a...@debian.org
> > Severity: serious
> > Justification: data loss
> > 
> > Hi,
> > 
> > As discussed over IRC, here is the bug report for one of the hanging
> > arm64 hosts we have for ci.debian.net.
> > 
> > Since the upgrade of our hosts to bullseye (days before the bullseye
> > release) we have been experiencing random loss of access to our hosts.
> > For the hosts that have some form of out-of-bound access, I tried to use
> > that to see what's going on, but at AWS our account doesn't have the
> > right permissions to use the serial port out-of-bound access and all
> > other forms that I tried on all hosts that I have access to some for of
> > out-of-bound access that didn't work.
> > 
> > Since the bullseye release I've rebooted (externally triggered) already
> > dozens of times and for those host that don't allow rebooting (AWS
> > again) I had to reprovision the hosts.
> > 
> > All the architectures (amd64, arm64, ppc64el and s390x) that we have
> > experience these hangs. I'm absolutely not claiming that the root cause
> > is the same, but on buster we didn't experience this (our s390x host
> > never workerd on buster so I don't claim regression there), so there is
> > a pattern. However, the symptoms don't look completely the same everywhere.
> > 
> > On one of our arm64 hosts (we call ci-worker-armel-01) I found the
> > attached logging as the final logs in the journal.
> 
> I suspect it's the same issue as fixed by
> https://git.kernel.org/linus/ad9f151e560b016b6ad3280b48e42fa11e1a5440
> upstream,
> https://lore.kernel.org/lkml/ef07b205c3cb1...@google.com/
> 
> The fix landed in 5.13-rc7 (was backported to 5.12.13 as well, but not
> 5.10.y). It seems it requires more work to address it as well in
> 5.10.y.
> 
> Asked upstream in
> https://lore.kernel.org/lkml/ytkj4xh2ol075...@eldamar.lan/

The needed patches are now there:
https://lore.kernel.org/stable/20210909140337.29707-1...@strlen.de/
and queued for the next 5.10.y upload (so I expect it to have thos
latest in our first bullseye point release).

I will try to cherry-pick those, if you can check they fix the issue
that would be great.

Regards,
Salvatore

Bug#994001: openssh-server: Almost locked out due #990456

[Aristeu Rozanski]

Package: openssh-server
Version: 1:8.4p1-6
Severity: important

Dear Maintainer,

I have a user named Rufus Obrien O'Rourke and he can't use the defined
username (according to our rules) 'root' but it already comes defined when
I install the system. Please rename them to something like '_root' please.

Jokes aside, I had 'ssh' group defined for a good while as to be used as
group of people allowed to ssh in the machine (AllowGroup, root login is
disabled) and a recent upgrade, probably due #990456, that group got renamed
as '_ssh' and I wasn't able to login anymore. Thankfully I had a session open
since before the change and was able to figure out what was going on.

Please change the upgrade script to check if the group ssh already contains
users before doing the change.

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

Kernel: Linux 4.19.0-2-amd64 (SMP w/4 CPU threads)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) (ignored: LC_ALL 
set to en_US.UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/bash
Init: systemd (via /run/systemd/system)

Versions of packages openssh-server depends on:
ii  adduser3.118
ii  debconf [debconf-2.0]  1.5.77
ii  dpkg   1.20.9
ii  libaudit1  1:3.0.5-1
ii  libc6  2.31-17
ii  libcom-err21.46.4-1
ii  libcrypt1  1:4.4.25-2
ii  libgssapi-krb5-2   1.18.3-7
ii  libkrb5-3  1.18.3-7
ii  libpam-modules 1.4.0-10
ii  libpam-runtime 1.4.0-10
ii  libpam0g   1.4.0-10
ii  libselinux13.1-3
ii  libssl1.1  1.1.1l-1
ii  libsystemd0247.9-1
ii  libwrap0   7.6.q-31
ii  lsb-base   11.1.0
ii  openssh-client 1:8.4p1-6
ii  openssh-sftp-server1:8.4p1-6
ii  procps 2:3.3.17-5
ii  runit-helper   2.10.3
ii  ucf3.0043
ii  zlib1g 1:1.2.11.dfsg-2

Versions of packages openssh-server recommends:
ii  libpam-systemd [logind]  247.9-1
ii  ncurses-term 6.2+20201114-4
ii  xauth1:1.1-1

Versions of packages openssh-server suggests:
pn  molly-guard   
pn  monkeysphere  
ii  ssh-askpass   1:1.2.4.1-13+b1
pn  ufw   

-- Configuration Files:
/etc/pam.d/sshd changed [not included]

-- debconf information excluded

Bug#990456: almost locked me out of my server

[Aristeu Rozanski]

This change almost locked me out of my server. I have ssh configured to only
allow login for users in the 'ssh' group and root login disabled. I found out
that it was renamed to _ssh and if I didn't had a session ongoing I'd be locked
out of it.

Please revert it before you lock people out of a server that isn't sitting few
meters from the users.

-- 
Aristeu

Bug#993947: Time lost, /etc/systemd/timesyncd.conf gets replaced with a default one

[Michael Biebl]

Am 09.09.21 um 16:15 schrieb Michael Biebl:
That said, keep in mind that we don't have a versioned systemd dep 
(yet), only an unversioned one [1].


Actually, what I said is not true. We do get a strict, versioned Depends 
via shlibs.local as systemd-timesyncd links against libsystemd-shared



$ cat debian/shlibs.local.in
udeb: libudev 1 libudev1-udeb
libsystemd 0 libsystemd0 (= ${binary:Version})
libsystemd-shared SHARED_LIB_VERSION systemd (= ${binary:Version})





OpenPGP_signature
Description: OpenPGP digital signature

Bug#993999: ableton-link-dev: CMake-snippets provide wrong include-path

[Debian/GNU]

Package: ableton-link-dev
Version: 3.0.3+dfsg-2
Severity: normal

Dear Maintainer,

ableton-link-dev provides an AbletonLinkConfig.cmake snippets, which is
great.

unfortunately, it is not really usable, as the include-paths defined
therein are "${CMAKE_CURRENT_LIST_DIR}/include" which expands to
"/usr/share/ableton-link/include" rather than "/usr/include/ableton"

Please fix this, so other Debian packages can use the ableton-link-dev
package.


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

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

Versions of packages ableton-link-dev depends on:
ii  libasio-dev  1:1.18.1-1

ableton-link-dev recommends no packages.

ableton-link-dev suggests no packages.

-- no debconf information

Bug#990718: RFS: duma/2.5.21-2 [ITA] -- Detect Unintended Memory Access - A Red-Zone memory allocator

[Peter]

duma (2.5.21-2) unstable; urgency=medium
 
   * Restore --no-parallel in rules file



( parallel make caused occasional build fails )

https://mentors.debian.net/debian/pool/main/d/duma/duma_2.5.21-2.dsc 

Bug#993998: Security fixes

[Leandro Cunha]

package: chromium
severity: important
tags: security, sid, buster, bookworm, bullseye
X-Debbugs-CC: mgilb...@debian.org mic...@lebihan.pl

Hi,

The chrome situation is worrying about several security issues that need to
be fixed [1] [2],
so I thought I would open this bug to boost this idea. Please, consider
updating Chromium to
the latest version periodically with security fixes. Thanks.

[1] https://security-tracker.debian.org/tracker/source-package/chromium
[2] https://chromereleases.googleblog.com/2021/09

-- 
Cheers,
Leandro Cunha

Bug#993991: dpkg-gensymbols complains about mising symver

[Guillem Jover]

Control: severity -1 minor
Control: retitle -1 dpkg-gensymbols: Add error for invalid symver entries

On Thu, 2021-09-09 at 14:34:21 +0200, Matthias Klose wrote:
> Package: src:dpkg
> Version: 1.20.9
> Severity: important

> seen with the gcc-11 builds on alpha:
> 
> https://buildd.debian.org/status/fetch.php?pkg=gcc-11=alpha=11.2.0-4=1630683098=0

> --- debian/libgcc-s1.symbols (libgcc-s1_11.2.0-4_alpha)
> +++ dpkg-gensymbolsQxYQ2t   2021-09-03 14:39:28.376544513 +
> @@ -18,6 +18,10 @@
>   (symver|arch=any-amd64 any-i386 x32)GCC_4.8.0 4.8
>   (symver)GCC_7.0.0 7
>   (symver|arch=sparc)GCC_LDBL_3.0@GCC_LDBL_3.0 3.0
> - (symver|arch=alpha sparc)GCC_LDBL_4.0.0@GCC_LDBL_4.0.0 4.0
> + GCC_LDBL_4.0.0@GCC_LDBL_4.0.0 11.2.0-4
> +#MISSING: 11.2.0-4# (symver|arch=alpha sparc)GCC_LDBL_4.0.0@GCC_LDBL_4.0.0 
> 4.0
>   (symver|arch=!any-amd64 !x32 !sparc64 !s390x !sh4)GLIBC_2.0 4.2
>   (symver|arch=s390x sh4 sparc64)GLIBC_2.2 4.2
> + __divtc3@GCC_LDBL_4.0.0 11.2.0-4
> + __multc3@GCC_LDBL_4.0.0 11.2.0-4
> + __powitf2@GCC_LDBL_4.0.0 11.2.0-4
> dh_makeshlibs: error: failing due to earlier errors
> 
> The symbols file looks correct, I don't know why dpkg-gensymbols doesn't
> recognize this symver. There are no trailing spaces in this symbols file.

The symver entries are not correct. They need to include only the
version part of the pattern not the symbol name, so:

 (symver|arch=sparc)GCC_LDBL_3.0 3.0
 (symver|arch=alpha sparc)GCC_LDBL_4.0.0 4.0

I've now added an explicit check for this kind of error, which will
print something like:

 dpkg-gensymbols: error: you cannot use symver tag with fully qualified symbol 
pattern:  (symver|arch=sparc)GCC_LDBL_3.0@GCC_LDBL_3.0 3.0

Thanks,
Guillem

Bug#993997: snmpd: missing dependency procps

[Sophie Brun]

Package: snmpd
Version: 5.9+dfsg-3
Severity: minor
User: de...@kali.org
Usertags: origin-kali
X-Debbugs-Cc: sop...@offensive-security.com

Hello,

/usr/bin/net-snmp-create-v3-user uses the command "/bin/ps".
I think procps should be a dependency of snmpd.

Thanks
Sophie

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

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

Versions of packages snmpd depends on:
ii  adduser3.118
ii  debconf [debconf-2.0]  1.5.77
ii  init-system-helpers1.60
ii  libc6  2.31-17
ii  libsnmp-base   5.9+dfsg-3
ii  libsnmp40  5.9+dfsg-3+b1
ii  lsb-base   11.1.0

snmpd recommends no packages.

Versions of packages snmpd suggests:
pn  snmptrapd  

Bug#993947: Time lost, /etc/systemd/timesyncd.conf gets replaced with a default one

[Michael Biebl]

Am 09.09.21 um 15:15 schrieb Felipe Sateler:

It should give us the guarantees[1]:

 > The postinst script may be called in the following ways:
 > postinst configure most-recently-configured-version
 >   The files contained in the package will be unpacked.
 >   All package dependencies will at least be “Unpacked”.
 >   If there are no circular dependencies involved,
 >   all package dependencies will be configured

AFAICS we don't have circular dependencies, but maybe the versioned 
breaks/replaces + versioned depends makes dpkg think there is one?


Hm, we do have systemd -> systemd-timesyncd | time-daemon and
   systemd-timesyncd -> systemd

This is a circular dep afaiu.

That said, keep in mind that we don't have a versioned systemd dep 
(yet), only an unversioned one [1].
So maybe turning this into a versioned dep is "good enough" and should 
work in most cases.
If possible, I think we should get this into the first stable release, 
as we can't really fix this for good, only for users who haven't 
upgraded yet.


Regards,
Michael

[1] 
https://salsa.debian.org/systemd-team/systemd/-/blob/debian/master/debian/control#L192




OpenPGP_signature
Description: OpenPGP digital signature

Bug#993995: Acknowledgement (upgrade-reports: lost abilty to do fast repeated key strokes after upgrade from buster to bullseye)

[J. Rodrigo Flores]

SOLVED.

Took me 2.5 hours to find after the upgrade,
Going to Settings, accesibility, typing assists, disabling "ignores
fast duplicate keypresses "

best
Rodrigo

On 09/09/2021, Debian Bug Tracking System  wrote:
> Thank you for filing a new Bug report with Debian.
>
> You can follow progress on this Bug here: 993995:
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=993995.
>
> This is an automatically generated reply to let you know your message
> has been received.
>
> Your message is being forwarded to the package maintainers and other
> interested parties for their attention; they will reply in due course.
>
> As you requested using X-Debbugs-CC, your message was also forwarded to
>   rodrigo.flores...@gmail.com
> (after having been given a Bug report number, if it did not have one).
>
> Your message has been sent to the package maintainer(s):
>  Debian Testing Group 
>
> If you wish to submit further information on this problem, please
> send it to 993...@bugs.debian.org.
>
> Please do not send mail to ow...@bugs.debian.org unless you wish
> to report a problem with the Bug-tracking system.
>
> --
> 993995: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=993995
> Debian Bug Tracking System
> Contact ow...@bugs.debian.org with problems
>


-- 

Rodrigo

Bug#992416: uploaded to DELAYED/3

[Matthias Klose]

I uploaded the fix to DELAYED/3, it's also blocking autoconf from migrating.

Bug#993992: ncl: FTBFS on i386, mipsel, mips64el

[Adrian Bunk]

On Thu, Sep 09, 2021 at 02:39:59PM +0200, Bas Couwenberg wrote:
> Source: ncl
> Version: 6.6.2-8
> Severity: serious
> Tags: ftbfs
> Justification: makes the package in question unusable or mostly so
> Control: block 992563 by -1
> 
> Dear Maintainer,
> 
> Your package FTBFS on i386, mipsel, and mips64el:
> 
>  dh_install: error: missing files, aborting
>   install -d debian/.debhelper/generated/ncl-ncarg
>   install -d debian/.debhelper/generated/libncarg0
>   install -d debian/.debhelper/generated/libncarg-dev
>   install -d debian/.debhelper/generated/libncarg-bin
>   install -d debian/.debhelper/generated/libncarg-data
> 
> Full buildlogs:
> 
>  
> https://buildd.debian.org/status/fetch.php?pkg=ncl=i386=6.6.2-8=1631137769=0
>...

The i386 failure is a gcc regression, I have not yet reported it upstream.

Not sure whether or not the mips{,64}el failures are related to that.

> Kind Regards,
> 
> Bas

cu
Adrian

Bug#990328: Please let "fallocate -d" preserve mtime, and add an option for ctime

[Chris Hofstaedtler]

* Kevin Price  [210909 13:59]:
> Whether "fallocate -d" should update or preserve ctime seems a good
> question to me. From my understanding of MAC times, I'd prefer a
> command-line switch to preserve or update ctime if desired, and to
> update it by default.

fallocate itself does none of this. It just calls the fallocate
syscall. The kernel decides what to do, and if it considers a
successful fallocate call a modification of the file or not.

If you want this changed, I would suggest you talk to the kernel
folks instead, as it makes no sense for util-linux to override
kernel policy.

  Chris