Bug#987281: linux-image-amd64: Enable i915 HDCP 2.2 support

[Salvatore Bonaccorso]

Hi Bastian,

On Tue, Apr 20, 2021 at 08:57:02PM +0200, Bastian Germann wrote:
> Package: linux-image-amd64
> Severity: wishlist
> 
> Since Linux 5.6, CONFIG_INTEL_MEI_HDCP is available which allows to use HDCP
> 2.2 with i915 graphics. The HDCP support for AMD GPUs is already enabled
> (CONFIG_DRM_AMD_DC_HDCP=y).
> 
> Having this available in the kernel config would improve support for various
> video streaming services and enable full use of package intel-hdcp. Its
> README claims CONFIG_INTEL_MEI_TXE must be available as well, which might be
> an outdated information.
> 
> Please enable both CONFIG_INTEL_MEI_HDCP and CONFIG_INTEL_MEI_TXE as modules.

Were you able to verify that enabling those two as modules make it
work?

The time for changes for bullseye is thight, so would like to hear a
confirmation, the needed changed could be tested and confirmed to
work.

Many thanks in advance already,

Regards,
Salvatore

Bug#977299: Fixed in 5.11

[Salvatore Bonaccorso]

Hi,

On Tue, Apr 20, 2021 at 01:12:35PM -0600, Chris Dos wrote:
> Both of these drivers work in 5.11.  Is Debian planning on moving to 5.11 or
> sticking with 5.10?  If sticking with 5.10 can the bluetooth drivers be
> patched to include Intel Typhoon Peak?

Debian bullseye will be shipped with a 5.10.y based kernel, later
uploads will move to 5.12 and later though.

Do you have references to the specfic upstream commits which add the
support?

Regards,
Salvatore

Bug#987280: CVE-2021-31254 CVE-2021-31255 CVE-2021-31256 CVE-2021-31257 CVE-2021-31258 CVE-2021-31259 CVE-2021-31260 CVE-2021-31261 CVE-2021-31262

[Salvatore Bonaccorso]

Hi,

On Tue, Apr 20, 2021 at 08:55:13PM +0200, Moritz Muehlenhoff wrote:
> Package: gpac
> Version: 1.0.1+dfsg1-3
> Severity: grave
> Tags: security
> X-Debbugs-Cc: Debian Security Team 
> 
> CVE-2021-31262
> https://github.com/gpac/gpac/commit/b2eab95e07cb5819375a50358d4806a8813b6e50
> https://github.com/gpac/gpac/issues/1738
> 
> CVE-2021-31261
> https://github.com/gpac/gpac/commit/cd3738dea038dbd12e603ad48cd7373ae0440f65
> https://github.com/gpac/gpac/issues/1737
> 
> CVE-2021-31260
> https://github.com/gpac/gpac/commit/df8fffd839fe5ae9acd82d26fd48280a397411d9
> https://github.com/gpac/gpac/issues/1736
> 
> CVE-2021-31259
> https://github.com/gpac/gpac/commit/3b84ffcbacf144ce35650df958432f472b6483f8
> https://github.com/gpac/gpac/issues/1735
> 
> CVE-2021-31258
> https://github.com/gpac/gpac/commit/ebfa346eff05049718f7b80041093b4c5581c24e
> https://github.com/gpac/gpac/issues/1706
> 
> CVE-2021-31257
> https://github.com/gpac/gpac/commit/87afe070cd6866df7fe80f11b26ef75161de85e0
> https://github.com/gpac/gpac/issues/1734
> 
> CVE-2021-31256
> https://github.com/gpac/gpac/commit/2da2f68bffd51d89b1d272d22aa8cc023c1c066e
> https://github.com/gpac/gpac/issues/1705
> 
> CVE-2021-31255
> https://github.com/gpac/gpac/commit/758135e91e623d7dfe7f6aaad7aeb3f791b7a4e5
> https://github.com/gpac/gpac/issues/1733
> 
> CVE-2021-31254
> https://github.com/gpac/gpac/commit/8986422c21fbd9a7bf6561cae65aae42077447e8
> https://github.com/gpac/gpac/issues/1703

There appeared some more gpac CVEs yesterday, should we fill those as
a separate bug? See CVE-2021-29279, CVE-2021-30014, CVE-2021-30015,
CVE-2021-30019, CVE-2021-30020, CVE-2021-30022, CVE-2021-30199
additionally.

Regards,
Salvatore

Bug#987295: profile-bpf: 3 warnings generated

[Jacobo Najera]

Package: bpfcc-tools
Version: 0.18.0+ds-2
Severity: normal
File: profile-bpf

Dear Maintainer,

When I run profile-bpfcc 3 warnings generated:

In file included from :2:
In file included from /virtual/include/bcc/bpf.h:12:
In file included from include/linux/types.h:6:
In file included from include/uapi/linux/types.h:14:
In file included from include/uapi/linux/posix_types.h:5:
In file included from include/linux/stddef.h:5:
In file included from include/uapi/linux/stddef.h:2:
In file included from include/linux/compiler_types.h:69:
include/linux/compiler-clang.h:45:9: warning: '__HAVE_BUILTIN_BSWAP32__' macro 
redefined [-Wmacro-redefined]
#define __HAVE_BUILTIN_BSWAP32__
^
:4:9: note: previous definition is here
#define __HAVE_BUILTIN_BSWAP32__ 1
^
In file included from :2:
In file included from /virtual/include/bcc/bpf.h:12:
In file included from include/linux/types.h:6:
In file included from include/uapi/linux/types.h:14:
In file included from include/uapi/linux/posix_types.h:5:
In file included from include/linux/stddef.h:5:
In file included from include/uapi/linux/stddef.h:2:
In file included from include/linux/compiler_types.h:69:
include/linux/compiler-clang.h:46:9: warning: '__HAVE_BUILTIN_BSWAP64__' macro 
redefined [-Wmacro-redefined]
#define __HAVE_BUILTIN_BSWAP64__
^
:5:9: note: previous definition is here
#define __HAVE_BUILTIN_BSWAP64__ 1
^
In file included from :2:
In file included from /virtual/include/bcc/bpf.h:12:
In file included from include/linux/types.h:6:
In file included from include/uapi/linux/types.h:14:
In file included from include/uapi/linux/posix_types.h:5:
In file included from include/linux/stddef.h:5:
In file included from include/uapi/linux/stddef.h:2:
In file included from include/linux/compiler_types.h:69:
include/linux/compiler-clang.h:47:9: warning: '__HAVE_BUILTIN_BSWAP16__' macro 
redefined [-Wmacro-redefined]
#define __HAVE_BUILTIN_BSWAP16__
^
:3:9: note: previous definition is here
#define __HAVE_BUILTIN_BSWAP16__ 1


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

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

Versions of packages bpfcc-tools depends on:
ii  python3  3.9.2-2
ii  python3-bpfcc0.18.0+ds-2
ii  python3-netaddr  0.7.19-5

bpfcc-tools recommends no packages.

bpfcc-tools suggests no packages.

-- no debconf information

Bug#987207: podman not running out-of-the-box as root

[Reinhard Tartler]

Control: tag -1 moreinfo

Hi Laurent,

I've downloaded the Bullseye Alpha 3 debian installer and installed using
kvm to have a super clean new system. Unfortunately, I was unable to
reproduce the issue that you described below. (I did find some issues with
rootless podman outside of a gnome-session, but that's a different story).

The symptoms sound a lot like described in this upstream bug:
https://github.com/containers/podman/issues/5721

Can you please compare your notes with that upstream bug? Can you confirm
that the 'overlay' kernel module is loaded? (in my test, it was loaded
automatically). If you still think this is an issue in the Debian package,
please let me know. I may require your assistance with reproducing this
issue.

-rt

On Mon, Apr 19, 2021 at 11:54 AM Laurent Bigonville 
wrote:

> Package: podman
> Version: 3.0.1+dfsg1-1
> Severity: serious
>
> Hello,
>
> After installing podman, I cannot run it as root out of the box as it
> fails with:
>
> ERRO[] [graphdriver] prior storage driver overlay failed: kernel does
> not support overlay fs: 'overlay' is not supported over extfs at
> "/var/lib/containers/storage/overlay": backing file system is unsupported
> for this graph driver
> Error: kernel does not support overlay fs: 'overlay' is not supported over
> extfs at "/var/lib/containers/storage/overlay": backing file system is
> unsupported for this graph driver
>
> Looking at fedora it seems that they have a containers-common package
> that ships a default storage.conf file:
>
>
> https://src.fedoraproject.org/rpms/containers-common/blob/rawhide/f/storage.conf
>
> I see that the debian package is shipping a file in
> /usr/share/containers/storage.conf (in the containers-storage package),
> but that file is apparently not read (strace only shows that the file in
> /etc/containers is read) and anyway unlike in fedora:
>
> 1) the driver is not set to overlay
> 2) the file is installed only if the containers-storage package is
> installed, which is not done by default.
> 3) that file is not read anyway, strace only shows that
> /etc/containers/storage.conf is read and not
> /usr/share/containers/storage.conf, so the file is apparently useless
>
> Shouldn't debian do the same thing than fedora so everything works OOTB?
>
> As a side note, I can see they are shipping also other files as well,
> like the seccomp.json file, using strace, it seems that podman tries to
> read them:
>
> [pid 14835] newfstatat(AT_FDCWD, "/etc/containers/seccomp.json",
> 0xcee6b8, 0) = -1 ENOENT (Aucun fichier ou dossier de ce type)
> [pid 14835] newfstatat(AT_FDCWD, "/usr/share/containers/seccomp.json",
> 0xcee788, 0) = -1 ENOENT (Aucun fichier ou dossier de ce type)
>
> Shouldn't that file be shipped by default too?
>
> Kind regards,
> Laurent Bigonville
>
> -- System Information:
> Debian Release: 11.0
>   APT prefers unstable-debug
>   APT policy: (500, 'unstable-debug'), (500, 'unstable'), (1,
> 'experimental-debug'), (1, 'experimental')
> Architecture: amd64 (x86_64)
>
> Kernel: Linux 5.10.0-6-amd64 (SMP w/8 CPU threads)
> Locale: LANG=fr_BE.UTF-8, LC_CTYPE=fr_BE.UTF-8 (charmap=UTF-8),
> LANGUAGE=fr_BE:fr
> Shell: /bin/sh linked to /usr/bin/dash
> Init: systemd (via /run/systemd/system)
> LSM: SELinux: enabled - Mode: Permissive - Policy name: refpolicy
>
> Versions of packages podman depends on:
> ii  conmon   2.0.25+ds1-1
> ii  containernetworking-plugins  0.9.0-1+b3
> ii  golang-github-containers-common  0.35.4+ds1-1
> ii  init-system-helpers  1.60
> ii  libc62.31-11
> ii  libdevmapper1.02.1   2:1.02.175-2.1
> ii  libgpgme11   1.14.0-1+b2
> ii  libseccomp2  2.5.1-1
> ii  runc 1.0.0~rc93+ds1-3
>
> Versions of packages podman recommends:
> ii  buildah   1.20.0+ds1-1
> ii  fuse-overlayfs1.4.0-1
> ii  golang-github-containernetworking-plugin-dnsname  1.1.1+ds1-4+b4
> ii  slirp4netns   1.0.1-2
> ii  tini  0.19.0-1
> ii  uidmap1:4.8.1-1
>
> Versions of packages podman suggests:
> ii  containers-storage  1.24.8+dfsg1-1+b1
> ii  docker-compose  1.25.0-1
>
> -- no debconf information
>
>

-- 
regards,
Reinhard

Bug#934151: RFS: python-tuf -- plug-and-play library for securing a software updater

[Philippe Coval]

Hi,

Some updates about this packaging effort,
as member of Python team
I have hosted packaging changes at:

https://salsa.debian.org/python-team/packages/tuf

It's lintian clean and autopkgtest are enabled for CI/CD

Is anyone able to upload it to archive in unstable branch ?

For other feedback feel free to use this ticket or upstream tracker:

https://github.com/theupdateframework/tuf/issues/263#issuecomment-780735041  


Regards

Bug#987279: nim: amd64 binaries built by maintainer; needs source-ony upload

[Federico Ceratto]

> I guess something went wrong with the upload, because the changes file has
> both

Indeed the upload of 1.4.6-1 was only meant for Experimental and I'm
surprised it landed into Sid.
Any way to revert Unstable?

Thanks!
--
Federico

Bug#987226: youtube-dl: ERROR: Unable to extract yt initial data

[Mike Gabriel]

Hi Holger,

On  Di 20 Apr 2021 16:17:21 CEST, Holger Levsen wrote:


control: severity -1 important
thanks


Debatable...


hi Mike,

On Mon, Apr 19, 2021 at 09:39:55PM +, Mike Gabriel wrote:

Package: youtube-dl
Severity: grave


you didn't really describe why you thought the severity should be grave,
but anyway:

$ youtube-dl https://twitter.com/zemodancingto/status/1381937205787172867#m
[twitter] 1381937205787172867: Downloading guest token
[twitter] 1381937205787172867: Downloading JSON metadata
[twitter] 1381937205787172867: Downloading m3u8 information
[download] Destination: zemo dancing to - Rick Astley - Never Gonna  
Give You Up-1381937205787172867.mp4

[download] 100% of 3.00MiB in 00:01
$

so this clearly shows the package isn't broken for everyone.


Hmm, so rename src:pkg to twitter-dl? (Kidding...) Youtube downloads  
are broken these days, at least. For a tool being named after Youtube,  
this surely is a bad thing to have in upcoming Debian stable.


Mike


--

DAS-NETZWERKTEAM
c\o Technik- und Ökologiezentrum Eckernförde
Mike Gabriel, Marienthaler Str. 17, 24340 Eckernförde
mobile: +49 (1520) 1976 148
landline: +49 (4351) 850 8940

GnuPG Fingerprint: 9BFB AEE8 6C0A A5FF BF22  0782 9AF4 6B30 2577 1B31
mail: mike.gabr...@das-netzwerkteam.de, http://das-netzwerkteam.de



pgpX_9N1SGZyz.pgp
Description: Digitale PGP-Signatur

Bug#987294: nmu: rust-sniffglue_0.11.1-6

[plugwash]

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

rust-stackvector recently had a memory safety bug that was reported by the
rustsec team as a security issue and the Debian security team as a rc bug.

I fixed this in rust-stackvector 1.6.0-3 , but due to the way rust packaging
works applications need to be rebuilt before they will pick up the fix. 
Based on grepping the package indexes, I belive that rust-sniffglue is the only
application that is built against rust-stackvector (though it's possible that
there are applications built with older tooling that I have missed).

nmu rust-sniffglue_0.11.1-6 . ANY . unstable . -m "Rebuild against 
rust-stackvector 1.0.6-3"

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

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

Bug#528344: #528344 exim4-daemon-heavy: Please add SPF support

[Dmitry Smirnov]

According to upstream, SPF is supported [1] so it would be great
to enable the feature. Thanks.

[1]: https://github.com/Exim/exim/wiki/SPF

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

---

Your Facebook friends are wrong about the lockdown. A non-hysterics's guide
to COVID-19 by Tom Woods.
 -- https://wrongaboutlockdown.com/


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

Bug#987226: youtube-dl: ERROR: Unable to extract yt initial data

[Holger Levsen]

Dear Mike,

On Tue, Apr 20, 2021 at 07:23:48PM +, Mike Gabriel wrote:
> > control: severity -1 important
> Debatable...

quoting https://www.debian.org/Bugs/Developer#severities

grave
makes the package in question unusable or mostly so, or causes data loss, 
or introduces a security hole allowing access to the accounts of users who use 
the package.

important
a bug which has a major effect on the usability of a package, without 
rendering it completely unusable to everyone.

this bug *might* be *serious*, but certainly not *grave*.

 
> Hmm, so rename src:pkg to twitter-dl? (Kidding...) Youtube downloads are
> broken these days, at least. For a tool being named after Youtube, this
> surely is a bad thing to have in upcoming Debian stable.

$ apt-cache show youtube-dl|wc -l
1165

now please read the output of "apt-cache show youtube-dl|less".

yes, the software is badly named.


-- 
cheers,
Holger

 ⢀⣴⠾⠻⢶⣦⠀
 ⣾⠁⢠⠒⠀⣿⡁  holger@(debian|reproducible-builds|layer-acht).org
 ⢿⡄⠘⠷⠚⠋⠀  OpenPGP: B8BF54137B09D35CF026FE9D 091AB856069AAA1C
 ⠈⠳⣄

In Germany we don‘t say „Happy Valentine‘s Day, I love you“, we say „ich werde
diesen vom Markt kreierten, konsumorientierten Trend des Kapitalismus nicht
unterstützen,“ and I think that’s beautiful. (Hazel Brugger)


signature.asc
Description: PGP signature

Bug#987293: lxc: unprivileged containers don't have permission to access their configuration files

[Celejar]

Package: lxc
Version: 1:4.0.6-1
Severity: normal

The default location for the configuration files of unprivileged
containers created by non-root users seems to be $HOME/.local/share, but
such containers will fail to start, since they don't have permission to
access that directory, since it isn't world accessible.

On this Sid system, $HOME and $HOME/.local are 755, but
$HOME/.local/share is 700. On a Buster system of mine, $HOME is 755, but
the other two are only 700. On both these systems, starting unprivileged
containers fails with something like:

lxc-start: my-container: start.c: print_top_failing_dir: 125 Permission denied 
- Could not access /home/username/.local/share. Please grant it x access, or 
add an ACL for the container root
lxc-start: my-container: sync.c: __sync_wait: 62 An error occurred in another 
process (expected sequence number 3)
lxc-start: my-container: start.c: __lxc_start: 1951 Failed to spawn container 
"my-container"
lxc-start: my-container: tools/lxc_start.c: main: 330 The container failed to 
start
lxc-start: my-container: tools/lxc_start.c: main: 336 Additional information 
can be obtained by setting the --logfile and --logpriority options

The solution is obviously to grant the appropriate permissions, but I
think this should be handled automatically by the system, or at the very
least, documentation should be added explaining the issue, instead of
requiring users to figure this out on their own.

Here's a suggestion for a paragraph to be added to the "Unprivileged
containers" section of README.Debian:

*

Unprivileged containers started by non-root users store their
configuration in ~/.local/share, and so must have permission to
access that directory. This can be granted via a command like (assuming
the acl package is installed):

setfacl --modify user::x . .local .local/share

where  is the subuid mapped to 0 in
~/.config/lxc/default.conf

*

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

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

Versions of packages lxc depends on:
ii  bridge-utils 1.7-1
ii  debconf [debconf-2.0]1.5.76
ii  dnsmasq-base [dnsmasq-base]  2.85-1
ii  iproute2 5.10.0-4
ii  iptables 1.8.7-1
ii  libc62.31-11
ii  libcap2  1:2.44-1
ii  libgcc-s110.2.1-6
ii  liblxc1  1:4.0.6-1
ii  libseccomp2  2.5.1-1
ii  libselinux1  3.1-3
ii  lsb-base 11.1.0

Versions of packages lxc recommends:
ii  apparmor   2.13.6-10
ii  debootstrap1.0.123
ii  dirmngr2.2.27-1
ii  gnupg  2.2.27-1
pn  libpam-cgfs
ii  lxc-templates  3.0.4-5
pn  lxcfs  
ii  openssl1.1.1k-1
ii  rsync  3.2.3-4
ii  uidmap 1:4.8.1-1
ii  wget   1.21-1+b1

Versions of packages lxc suggests:
ii  btrfs-progs  5.10.1-1
ii  lvm2 2.03.11-2.1
pn  python3-lxc  

-- debconf information:
  lxc/auto_update_config:

Bug#987292: chromium: Use system libxnvctrl

[Bastian Germann]

Package: chromium
Severity: wishlist

debian/TODO says: "remove third_party/libXNVCtrl (package currently in contrib, bug 
#747837)"

The bug is done and libxnvctrl-dev is in main now. Please compile against the 
system library.

Bug#987105: inkscape: Incoherent style for window titlebar buttons

[Mattia Rizzolo]

Control: close -1

On Tue, Apr 20, 2021 at 03:37:00PM -0300, Joseph Ponte wrote:
> In fact, it is the same! I believe we can close this issue report and
> follow the thread on https://gitlab.com/inkscape/inkscape/-/issues/1925.

Thank you, doing so!

(usually we don't close debian bugs while they are being handled
upstream, but track them.  but honestly, inkscape has way too many open
bugs in debian, with nearly all of them being stuck in that state for
years, it's actually getting unwieldy... so I'm happy to close this
given your ACK)

-- 
regards,
Mattia Rizzolo

GPG Key: 66AE 2B4A FCCF 3F52 DA18  4D18 4B04 3FCD B944 4540  .''`.
More about me:  https://mapreri.org : :'  :
Launchpad user: https://launchpad.net/~mapreri  `. `'`
Debian QA page: https://qa.debian.org/developer.php?login=mattia  `-


signature.asc
Description: PGP signature

Bug#981533: poetry-core: autopkgtest failure

[Emmanuel Arias]

Hello!

Thanks for the report and sorry for the delay of my response.

I've just push to salsa [0] a fix for this error. Now at least on salsa
run autopkgtest successfully. I need sponsorship to upload it.

I cc pollo that help me to upload to Debian.

Thanks
Cheers,
Emmanuel

[0] https://salsa.debian.org/python-team/packages/poetry-core

Bug#987022: unblock: spamassassin/3.4.5~pre1-4

[Noah Meyerhans]

On Tue, Apr 20, 2021 at 08:53:48PM +0200, Ivo De Decker wrote:
> > The debdiff for 3.4.6-1 is at [5].  The debdiff for 3.4.5~pre1-4 is at
> > [6].
> 
> I suggest you upload 3.4.5~pre1-4 to unstable and 3.4.6-1 to experimental. I
> haven't looked at 3.4.5~pre1-4 in detail yet, but I suspect it will be fine.
> Once it migrates, we can look at 3.4.6-1 again, and by then, the upload to
> experimental will at least show us obvious issues in the builds or the ci.
> 
> Please remove the moreinfo tag from this bug when 3.4.5~pre1-4 (or something
> similar) is ready to migrate.

So, naturally, it's not that simple.  Experimental contains a 4.0.0
prerelease version, so getting 3.4.6-1 available there won't work.

In any case, I just uploaded 3.4.5~pre1-4 to unstable, and we can
consider 3.4.6-1 in unstable after it migrates.  I think that's the next
best plan, if we're to consider 3.4.6 at all.

Thanks
noah

Bug#982758: webext-browserpass: Failed to install on upgrade to bullseye

[Axel Beckert]

Hi,

Antoine Beaupré wrote:
> I have had the same, completely crashes the apt run too, neat. :)
>
> dpkg: error processing archive 
> /var/cache/apt/archives/webext-browserpass_3.7.2-1+b1_amd64.deb (--unpack):
>  unable to open 
> '/usr/share/mozilla/extensions/{ec8030f7-c20a-464f-9b0e-13a3a9e97384}/browserp...@maximbaz.com/icon.png.dpkg-new':
>  No such file or directory
> Reinstalling 
> /etc/chromium/native-messaging-hosts/com.dannyvankooten.browserpass.json that 
> was moved away

Ack. Ran into this, too, today.

> I bumped the severity because it completely fails to upgrade.

Thanks!

> Workaround: apt purge webext-browserpass && apt install webext-browserpass

Ah, nice!

I digged a bit deeper and found the culprit:

First that weird dpkg error message. It's well explained here:
https://raphaelhertzog.com/2011/07/18/deciphering-one-of-dpkg-weirdest-errors-unable-to-open-pathtofoo-dpkg-new/

This led me quickly looking into the preinst script and it indeed
fiddles with directories and symlinks. That's also why purging and
installing from scratch doesn't trigger the issue and helps as
workaround:

  #!/bin/sh
  set -e
  # Automatically added by dh_installdeb/13.3.4
  dpkg-maintscript-helper symlink_to_dir 
/usr/share/chromium/extensions/browserpass /usr/share/webext/browserpass 
3.0.0-1 -- "$@"
  dpkg-maintscript-helper symlink_to_dir 
/usr/share/mozilla/extensions/{ec8030f7-c20a-464f-9b0e-13a3a9e97384}/browserpass\@maximbaz.com
 /usr/share/webext/browserpass 3.0.0-1 -- "$@"
  dpkg-maintscript-helper rm_conffile 
/etc/chromium/native-messaging-hosts/com.dannyvankooten.browserpass.json 
3.4.1-3\~ -- "$@"
  # End automatically added section

Combine that with the fact that the package ships both,
/usr/share/chromium/extensions/browserpass/icon.png and
/usr/share/mozilla/extensions/{ec8030f7-c20a-464f-9b0e-13a3a9e97384}/browserp...@maximbaz.com/icon.png
and you get that problem.

So now the question is, what exactly happens and how to fix it?

In general, symlink_to_dir seems to be the right thing, since those
directories are indeed symlinks in buster:

  lrwxrwxrwx 1 root root 24 Feb  6  2019  
/usr/share/chromium/extensions/browserpass -> ../../webext/browserpass/
  lrwxrwxrwx 1 root root 27 Feb  6  2019 
'/usr/share/mozilla/extensions/{ec8030f7-c20a-464f-9b0e-13a3a9e97384}/browserp...@maximbaz.com'
 -> ../../../webext/browserpass/

And directory in sid/bullseye:

  drwxr-xr-x 2 root root 4096 Apr 10 03:00  
/usr/share/chromium/extensions/browserpass/
  drwxr-xr-x 7 root root 4096 Apr 10 03:00 
'/usr/share/mozilla/extensions/{ec8030f7-c20a-464f-9b0e-13a3a9e97384}/browserp...@maximbaz.com'/

The effect looks as if those symlinks weren't changed into
directories. But why? That 3.0.0-1 looks valid. And looking at my
upgrade logs (I always log dist-upgrades with "script"), the versions
seem the expected ones:

  Preparing to unpack .../370-webext-browserpass_3.7.2-1+b1_amd64.deb ...
  Unpacking webext-browserpass (3.7.2-1+b1) over (2.0.22-2) ...
  dpkg: error processing archive 
/tmp/apt-dpkg-install-VKYulC/370-webext-browserpass_3.7.2-1+b1_amd64.deb 
(--unpack):
   unable to open 
'/usr/share/mozilla/extensions/{ec8030f7-c20a-464f-9b0e-13a3a9e97384}/browserp...@maximbaz.com/icon.png.dpkg-new':
 No such file or directory
  Reinstalling 
/etc/chromium/native-messaging-hosts/com.dannyvankooten.browserpass.json that 
was moved away

So I must admit, I'm currently not understanding what exactly goes
wrong. Wanted though to share how far I came with debugging this in
case someone else was stuck earlier in the process, but now has an
idea what goes wrong.

Will write again if I figure out more.

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

Bug#984894: python-azure: flaky autopkgtest: You need to call 'result' or 'wait' on all LROPoller you have created

[Luca Boccassi]

On Mon, 12 Apr 2021 21:18:02 +0200 Paul Gevers  wrote:
> Control: severity -1 serious
> 
> Hi Luca,
> 
> [Please CC submitters if you ask for their input, the BTS doesn't
> forward messages automatically]
> 
> On Wed, 24 Mar 2021 16:53:52 + Luca Boccassi  wrote:
> > I have ran the sdk/resources/azure-mgmt-resource tests locally for ~30
> > times and unfortunately I am not able to reproduce the issue.
> 
> Did you by any chance run them in parallel? The failures on amd64 always
> happen on ci-worker13, which is running 8 parallel debci workers.
> Interestingly enough, armhf is *always* running on a host with 8
> parallel debci workers and there the issue isn't seen. All our arm64
> workers have two debci workers, as does ppc64el. The former is lightly
> flaky, the latter hasn't showed a failure yet since -2.
> 
> > Hence I'm
> > downgrading + adding tags for help - if anyone is able to reproduce or
> > spot the issue, a MR is more than welcome.
> > This particular module was also updated in -4 to solve an unrelated
> > issue, so it might very well be that this is solved too.
> 
> -4 is as flaky as before.
> 
> If there's something specific we can test for you on the ci.d.n infra
> let us know.
> 
> Paul
> (Release Team hat on for the severity call, CI Team hat on for the offer
> to help on the infra.)

Hi,

Thanks for the further information - I have now tried to run the same
test in parallel multiple times, but still no luck.

I'll just go ahead and blocklist it in the next upload.

-- 
Kind regards,
Luca Boccassi


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

Bug#987291: ITP: gnome-shell-extension-desktop-icons-ng -- desktop icon support for GNOME Shell

[Gunnar Hjalmarsson]

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

Package name: gnome-shell-extension-desktop-icons-ng
Version : 0.17.0-1
Upstream Author : Sergio Costas 
URL : https://gitlab.com/rastersoft/desktop-icons-ng
License : GPL-3+
Programming Lang: Javascript
Description : Desktop icon support for GNOME Shell

The package provides a GNOME Shell extension for showing the contents of 
~/Desktop on the desktop of the Shell. It's a fork/rewrite of an 
existing extension (package: gnome-shell-extension-desktop-icons) but 
with additional features often desired by users ("-ng" means New 
Generation).


Ubuntu 21.04 includes gnome-shell-extension-desktop-icons-ng by default.



OpenPGP_signature
Description: OpenPGP digital signature

Bug#987283: Filter list for "unreported" view

[Salvatore Bonaccorso]

Hi,

On Tue, Apr 20, 2021 at 09:01:10PM +0200, Moritz Muehlenhoff wrote:
> Package: security-tracker
> Severity: wishlist
> 
> https://security-tracker.debian.org/tracker/status/unreported should
> gain a filter list, since there are some packages for which filing
> bugs makes no sense (e.g. the linux kernel, which is tracked without
> filed bugs in the BTS or various legacy Nvidia packages, which are
> known vulnerable, but still kept around for hw compat).
> 
> Ideally we simply have a list of source packages kept under CVE/*
> which are filtered out.

Seems like a reasonable good idea. I think for consistency with other
lists I would place the filter-list like others just under
data/packages/ though (instead of data/CVE/).

But that can be looked at when implementing/expanding the 'unreported'
page view.

Regards,
Salvatore

Bug#987290: GIMP 2.10.8-2 crashes on segmentation error while opening in buster

[Chris Born]

Package: GIMP 2.10.8-2

Hello


GIMP crashes on DEBIAN 10 LXD
i hoped for an UPDATE but it does not come
neiter like the AUTOMOUNT from usb !!!

but this is about GIMP 2.10.8-2

the report:

```
GNU Image Manipulation Program version 2.10.8
git-describe: GIMP_2_10_6-294-ga967e8d2c2
C compiler:
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/8/lto-wrapper
OFFLOAD_TARGET_NAMES=nvptx-none
OFFLOAD_TARGET_DEFAULT=1
Target: x86_64-linux-gnu
	Configured with: ../src/configure -v --with-pkgversion='Debian 
8.2.0-13' --with-bugurl=file:///usr/share/doc/gcc-8/README.Bugs 
--enable-languages=c,ada,c++,go,brig,d,fortran,objc,obj-c++ 
--prefix=/usr --with-gcc-major-version-only --program-suffix=-8 
--program-prefix=x86_64-linux-gnu- --enable-shared 
--enable-linker-build-id --libexecdir=/usr/lib 
--without-included-gettext --enable-threads=posix --libdir=/usr/lib 
--enable-nls --enable-clocale=gnu --enable-libstdcxx-debug 
--enable-libstdcxx-time=yes --with-default-libstdcxx-abi=new 
--enable-gnu-unique-object --disable-vtable-verify --enable-libmpx 
--enable-plugin --enable-default-pie --with-system-zlib 
--with-target-system-zlib --enable-objc-gc=auto --enable-multiarch 
--disable-werror --with-arch-32=i686 --with-abi=m64 
--with-multilib-list=m32,m64,mx32 --enable-multilib --with-tune=generic 
--enable-offload-targets=nvptx-none --without-cuda-driver 
--enable-checking=release --build=x86_64-linux-gnu 
--host=x86_64-linux-gnu --target=x86_64-linux-gnu

Thread model: posix
gcc version 8.2.0 (Debian 8.2.0-13)

using GEGL version 0.4.12 (compiled against version 0.4.12)
using GLib version 2.63.5 (compiled against version 2.58.1)
using GdkPixbuf version 2.38.1 (compiled against version 2.38.0)
using GTK+ version 2.24.32 (compiled against version 2.24.32)
using Pango version 1.42.3 (compiled against version 1.42.3)
using Fontconfig version 2.13.1 (compiled against version 2.13.1)
using Cairo version 1.16.0 (compiled against version 1.16.0)

```

fatal error: Segmentation fault


Stack trace:
```

# Stack traces obtained from PID 3431 - Thread 3431 #

[New LWP 3432]
[New LWP 3433]
[New LWP 3434]
[New LWP 3435]
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
0x7ff6d2997544 in read () from /lib/x86_64-linux-gnu/libpthread.so.0
  Id   Target IdFrame
* 1Thread 0x7ff6d0f84d00 (LWP 3431) "gimp-2.10" 0x7ff6d2997544 
in read () from /lib/x86_64-linux-gnu/libpthread.so.0
  2Thread 0x7ff6cf768700 (LWP 3432) "gmain" 0x7ff6d28b1819 
in poll () from /lib/x86_64-linux-gnu/libc.so.6
  3Thread 0x7ff6cebd3700 (LWP 3433) "gdbus" 0x7ff6d28b1819 
in poll () from /lib/x86_64-linux-gnu/libc.so.6
  4Thread 0x7ff6bbfd1700 (LWP 3434) "async" 0x7ff6d28b6f59 
in syscall () from /lib/x86_64-linux-gnu/libc.so.6
  5Thread 0x7ff6bb7d0700 (LWP 3435) "worker"0x7ff6d28b6f59 
in syscall () from /lib/x86_64-linux-gnu/libc.so.6


Thread 5 (Thread 0x7ff6bb7d0700 (LWP 3435)):
#0  0x7ff6d28b6f59 in syscall () from /lib/x86_64-linux-gnu/libc.so.6
No symbol table info available.
#1  0x7ff6d2bc8b4f in g_cond_wait (cond=0x559e080d5bd0, 
mutex=0x559e080d5bc8) at ../glib/gthread-posix.c:1527

sampled = 0
#2  0x559e07d2e423 in ?? ()
No symbol table info available.
#3  0x7ff6d2ba652d in g_thread_proxy (data=0x559e084cd0c0) at 
../glib/gthread.c:807

thread = 0x559e084cd0c0
__func__ = "g_thread_proxy"
_g_boolean_var_ = 
#4  0x7ff6d298dfa3 in start_thread () from 
/lib/x86_64-linux-gnu/libpthread.so.0

No symbol table info available.
#5  0x7ff6d28bc4cf in clone () from /lib/x86_64-linux-gnu/libc.so.6
No symbol table info available.

Thread 4 (Thread 0x7ff6bbfd1700 (LWP 3434)):
#0  0x7ff6d28b6f59 in syscall () from /lib/x86_64-linux-gnu/libc.so.6
No symbol table info available.
#1  0x7ff6d2bc8b4f in g_cond_wait (cond=0x559e080d69b0, 
mutex=0x559e080d69c0) at ../glib/gthread-posix.c:1527

sampled = 0
#2  0x559e07d2e66c in ?? ()
No symbol table info available.
#3  0x7ff6d2ba652d in g_thread_proxy (data=0x559e084cd060) at 
../glib/gthread.c:807

thread = 0x559e084cd060
__func__ = "g_thread_proxy"
_g_boolean_var_ = 
#4  0x7ff6d298dfa3 in start_thread () from 
/lib/x86_64-linux-gnu/libpthread.so.0

No symbol table info available.
#5  0x7ff6d28bc4cf in clone () from /lib/x86_64-linux-gnu/libc.so.6
No symbol table info available.

Thread 3 (Thread 0x7ff6cebd3700 (LWP 3433)):
#0  0x7ff6d28b1819 in poll () from /lib/x86_64-linux-gnu/libc.so.6
No symbol table info available.
#1  0x7ff6d2b7e42e in g_main_context_poll (priority=, 
n_fds=2, fds=0x559e0832f190, timeout=, 
context=0x559e08323ca0) at ../glib/gmain.c:4309

ret = 
errsv = 
poll_func = 0x7ff6d2b8d820 

Bug#987202: Terminal output

[Bernhard Schmidt]

Control: tags -1 + moreinfo

Dear Patrick,

thanks for reporting this bug.

> 2021-04-19 16:34:29 SENT CONTROL [server]: 'PUSH_REQUEST' (status=1)> 
> 2021-04-19 16:34:29 PUSH: Received control message: 'PUSH_REPLY,ping
> 10,ping-restart 60,dhcp-option DNS 192.168.XXX.XXX,dhcp-option DNS
> 192.168.XXX.XXX,route-delay 5,echo,echo,echo,route-gateway
> 192.168.XXX.XXX,ping 10,ping-restart 120,ifconfig 192.168.XXX.XXX
> 255.255.255.0,peer-id 0,cipher AES-256-GCM'
> Segmentation fault

I haven't seen this before. It is likely an upstream bug with your
specific configuration.

We need at least a backtrace of the crashing OpenVPN process. Please
have a look at

https://wiki.debian.org/HowToGetABacktrace

sections 1 and 4.

Best Regards,
Bernhard

Bug#983140: closed by Debian FTP Masters (reply to Lee Garrett ) (Bug#983140: fixed in ansible 2.10.7+merged+base+2.10.8+dfsg-1)

[Baptiste Beauplat]

Hi Lee,

On 2021/04/19 11:06 PM, Debian Bug Tracking System wrote:
> #983140: ansible: Does not detect correct python interpreter on bullseye 
> target
> 
> It has been closed by Debian FTP Masters  
> (reply to Lee Garrett ).

Glad to hear this will be fixed by this new version.

I was also working on a patch for 2.9.16 but I guess it's a bit late of
that :)

I'll attach it anyway for reference because I managed to have all unit
tests working by avoiding the user home directory. You might be
interested to have a look at that.

Thanks again for maintaining ansible!

Best,

-- 
Baptiste Beauplat - lyknode
diff -Nru ansible-2.9.16+dfsg/debian/changelog 
ansible-2.9.16+dfsg/debian/changelog
--- ansible-2.9.16+dfsg/debian/changelog2021-01-06 11:56:22.0 
+0100
+++ ansible-2.9.16+dfsg/debian/changelog2021-04-17 15:27:02.0 
+0200
@@ -1,3 +1,11 @@
+ansible (2.9.16+dfsg-1.2) bullseye; urgency=medium
+
+  * Non-maintainer upload.
+  * Use python3.9 as default interpreter (Closes: #983140)
+  * Add autopkgtest to run a working subset of ansible test suite
+
+ -- Baptiste Beauplat   Sat, 17 Apr 2021 15:27:02 +0200
+
 ansible (2.9.16+dfsg-1.1) unstable; urgency=medium
 
   * Non-maintainer upload.
diff -Nru 
ansible-2.9.16+dfsg/debian/patches/0007-fix-interpreter-fallback.patch 
ansible-2.9.16+dfsg/debian/patches/0007-fix-interpreter-fallback.patch
--- ansible-2.9.16+dfsg/debian/patches/0007-fix-interpreter-fallback.patch  
1970-01-01 01:00:00.0 +0100
+++ ansible-2.9.16+dfsg/debian/patches/0007-fix-interpreter-fallback.patch  
2021-04-17 15:27:02.0 +0200
@@ -0,0 +1,33 @@
+Description: Fix python interpreter discovery (Closes: #983140)
+ On machines upgrade from buster to bullseye, the wrong interpreter will be
+ discovered and used, causing the playbook run to fail. Update the fallback 
list
+ so it correctly picks python3.9 on bullseye when both 3.9 and 3.7 are present,
+ which usually is the case on freshly upgrade machines.
+Origin: backport, 
https://github.com/ansible/ansible/commit/c986cbb9961bfaedf1a6ae7f0c2e34be26d9ab12
+Forwarded: not-needed
+Applied-Upstream: 
https://github.com/ansible/ansible/commit/c986cbb9961bfaedf1a6ae7f0c2e34be26d9ab12
+Reviewed-by: Lee Garrett 
+Last-Update: 2021-03-23
+---
+This patch header follows DEP-3: http://dep.debian.net/deps/dep3/
+--- a/lib/ansible/config/base.yml
 b/lib/ansible/config/base.yml
+@@ -1523,6 +1523,8 @@
+   name: Ordered list of Python interpreters to check for in discovery
+   default:
+   - /usr/bin/python
++  - python3.9
++  - python3.8
+   - python3.7
+   - python3.6
+   - python3.5
+--- a/test/lib/ansible_test/_internal/util.py
 b/test/lib/ansible_test/_internal/util.py
+@@ -110,6 +110,7 @@
+ '3.6',
+ '3.7',
+ '3.8',
++'3.9',
+ )
+
+
diff -Nru ansible-2.9.16+dfsg/debian/patches/0008-fix-tests.patch 
ansible-2.9.16+dfsg/debian/patches/0008-fix-tests.patch
--- ansible-2.9.16+dfsg/debian/patches/0008-fix-tests.patch 1970-01-01 
01:00:00.0 +0100
+++ ansible-2.9.16+dfsg/debian/patches/0008-fix-tests.patch 2021-04-17 
15:27:02.0 +0200
@@ -0,0 +1,44 @@
+From: Baptiste Beauplat 
+Date: Mon, 19 Apr 2021 20:41:09 +0200
+Subject: Fix test suite
+
+* Mark two tests depending on pycrypto with the correct skipif
+* Inject remote_tmp configuration to point to /tmp to handle testbed without
+  HOME
+* Truncate output check on test_build_requirement_from_path_no_version due to 
an
+  issue with text wrapping
+--- a/test/units/parsing/vault/test_vault.py
 b/test/units/parsing/vault/test_vault.py
+@@ -528,6 +528,7 @@
+ b_key_pycrypto = self.vault_cipher._create_key_pycrypto(b_password, 
b_salt, key_length=32, iv_length=16)
+ self.assertEqual(b_key_cryptography, b_key_pycrypto)
+ 
++@pytest.mark.skipif(not vault.HAS_PYCRYPTO, reason='Not testing 
cryptography known key as pycrypto is not installed')
+ def test_create_key_known_cryptography(self):
+ b_password = b'hunter42'
+ 
+@@ -555,6 +556,7 @@
+ self.assertEqual(b_key_3, b_key_4)
+ self.assertEqual(b_key_1, b_key_4)
+ 
++@pytest.mark.skipif(not vault.HAS_PYCRYPTO, reason='Not testing pycrypto 
known key as pycrypto is not installed')
+ def test_create_key_known_pycrypto(self):
+ b_password = b'hunter42'
+ 
+--- /dev/null
 b/test/lib/ansible_test/_data/ansible.cfg
+@@ -0,0 +1,2 @@
++[defaults]
++remote_tmp = /tmp/ansible
+--- a/test/units/galaxy/test_collection_install.py
 b/test/units/galaxy/test_collection_install.py
+@@ -242,8 +242,7 @@
+ assert mock_display.call_count == 1
+ 
+ actual_warn = ' '.join(mock_display.mock_calls[0][1][0].split('\n'))
+-expected_warn = "Collection at '%s' does not have a valid version set, 
falling back to '*'. Found version: ''" \
+-% to_text(collection_artifact[0])
++expected_warn = "does not have a valid version set, falling back to '*'. 
Found version: ''"
+ assert expected_warn in 

Bug#987038: buster-pu: package clamav/0.103.2+dfsg-0+deb10u1

[Adam D. Barratt]

Control: tags -1 + confirmed

On Tue, 2021-04-20 at 21:42 +0200, Sebastian Andrzej Siewior wrote:
> On 2021-04-19 21:15:06 [+0100], Adam D. Barratt wrote:
> > > > I guess the diff against the current buster package is quite
> > > > large
> > > > by
> > > > this point?
> > > 
> > > What do you mean by this point? We did full clamav uploads in the
> > > past.
> > > Please excuse if I miss something obvious.
> > 
> > Sorry, that may have been poor phrasing on my part. I simply meant
> > between the current and proposed packages, as we're changing the
> > upstream major version tree being followed.
> 
> Correct, we advance from 102 to 103. The 102 series seems not to be
> updated anymore. As I tried to argue why I don't think it that is
> enough to backport that one CVE that also applies to 102 (as done by
> the LTS team) it terms of security and support.

I'm certainly happy to defer to your judgement here, given our previous
experience with clamav updates in stable. I was simply trying to
ascertain the scale of the update involved, but fear I may have just
confused the discussion; perhaps it doesn't really matter that much, in
the end.

Please feel free to upload. I assume that, given there are security
fixes involved, you'd prefer an early release via stable-updates as
we've done with a number of updates in the past?

Regards,

Adam

Bug#960154: Feed UDD with just-in-time packaging hints from Lintian

[Raphael Hertzog]

Hi,

On Wed, 14 Apr 2021, Lucas Nussbaum wrote:
> I think that in Debian, we would aim for a better separation between:
> 
> A/ QA tools development, focused on getting the good tools to analyze
> packages (output: tools, as Debian packages)
> 
> B/ infrastructure that mass-process the archive using QA tools. (output:
> current status of each package in Debian, analyzed with the latest
> version of a given tool, as a parsable file)
> 
> C/ infrastructure that gathers the current status from all instances of
> (B) and exposes it per-package, per-maintainer, per-team, etc.
> 
> (C) could even be split into:
>   (C.1) infrastructure that gathers the status and stores it into a
>   common DB;
>   (C.2) infrastructure that uses (C.1) to provide useful
>   per-package/per-maintainer frontends (views).

Fully agreed on this. tracker.debian.org is clearly in the scope
of (C) but started to move into (B), but once I realized this I decided
that it would be better to have a separate project, that's how I ended
up designing "debusine".

See 
https://salsa.debian.org/freexian-team/debusine/-/blob/master/docs/devel/why.rst

As I announced a few days ago, I will invest Freexian's money
in this project so you're welcome to watch the project (in gitlab speak,
aka enable notifications) so that you can contribute to its design.

The first milestone will be oriented towards package building,
not lintian processing but I'm happy to include this in the roadmap
at some point.

Cheers,
-- 
  ⢀⣴⠾⠻⢶⣦⠀   Raphaël Hertzog 
  ⣾⠁⢠⠒⠀⣿⡁
  ⢿⡄⠘⠷⠚⠋The Debian Handbook: https://debian-handbook.info/get/
  ⠈⠳⣄   Debian Long Term Support: https://deb.li/LTS

Bug#987287: python-bz2file: no longer useful since Python 3.3

[Piotr Engelking]

Source: python-bz2file
Severity: important

As the library is no longer developed and all its features were
integrated upstream in Python 3.3, python-bz2file is no longer useful.

Please migrate its reverse dependencies to the standard library bz2
module and remove the package from Debian.

Bug#987038: buster-pu: package clamav/0.103.2+dfsg-0+deb10u1

[Sebastian Andrzej Siewior]

On 2021-04-19 21:15:06 [+0100], Adam D. Barratt wrote:
> > > I guess the diff against the current buster package is quite large
> > > by
> > > this point?
> > 
> > What do you mean by this point? We did full clamav uploads in the
> > past.
> > Please excuse if I miss something obvious.
> 
> Sorry, that may have been poor phrasing on my part. I simply meant
> between the current and proposed packages, as we're changing the
> upstream major version tree being followed.

Correct, we advance from 102 to 103. The 102 series seems not to be
updated anymore. As I tried to argue why I don't think it that is enough
to backport that one CVE that also applies to 102 (as done by the LTS
team) it terms of security and support.
This is not the first time that a major version is advanced within a
stable update. We did have 0.101.2+dfsg-1+deb10u1 before it was updated
to 102. Stretch went from 0.99.2+dfsg-6+deb9u1 to 0.102.3+dfsg-0~deb9u1
(not counting LTS).

> Regards,
> 
> Adam

Sebastian

Bug#986908: unblock: snort 2.9.15.1-5

[Graham Inggs]

Control: tags -1 + moreinfo

Hi Javier

On Mon, 19 Apr 2021 at 23:27, Chris Hofstaedtler  wrote:
>
> > $ debdiff snort_2.9.15.1-4_i386.deb snort_2.9.15.1-5_i386.deb
> [..]
>
> The debdiff does not seem to show any actual packaging changes. Are
> you sure you diffed the correct files?

This looks like a binary debdiff, not a source debdiff.

Regards
Graham

Bug#918984: fuse3 still not co-installable with fuse

[Sebastian Ramacher]

Control: tags -1 - bullseye + bookworm
Control: retitle -1 fuse3: provide upgrade path fuse -> fuse3 for bookworm

On 2021-04-06 21:30:37, Sebastian Ramacher wrote:
> Control: severity -1 serious
> Control: retitle -1 fuse3: provide upgrade path fuse -> fuse3 for bullseye
> 
> The fuse/fuse3 situation turns out to be an issue for buster -> bullseye
> upgrades. Take a minimal buster chroot with ntfs-3g and sshfs installed:
> 
> $ apt-get -y install ntfs-3g sshfs
> $ sed 's/buster/bullseye/' -i /etc/apt/sources.list
> $ apt-get update
> $ apt-get -y dist-upgrade
> 
> After the upgrade, sshfs is still at the version from buster:
> 
> $ apt-cache policy sshfs
> sshfs:
>   Installed: 2.10+repack-2
>   Candidate: 3.7.1+repack-1
>   Version table:
>  3.7.1+repack-1 500
> 500 http://localhost:3142/debian bullseye/main amd64 Packages
>  *** 2.10+repack-2 100
> 100 /var/lib/dpkg/status
> 
> 
> Explicitely upgrading sshfs with apt-get install will cause fuse3 to be
> installed and fuse to be removed. Thanks to Helmut Grohne for the
> reproducer.
> 
> With my release team hat on, I'm raising this issue to serious. We want
> to provide working upgrade paths. One possible solution to the problem
> would be for src:fuse3 to take over the fuse binary package as
> transitional package depending on bin:fuse3. As far as I understand the
> situation, all reverse dependencies of fuse should also work with fuse3.

This is now being documented in the release notes at
https://salsa.debian.org/ddp-team/release-notes/-/merge_requests/92 and
should not occur in normal upgrades. 
Since fixing this issue also involves udeps, let's postponse this for
bookworm.

Cheers
-- 
Sebastian Ramacher

Bug#984630: python3-waitress: leaves alternatives after upgrade: /etc/alternatives/waitress-serve -> /usr/bin/waitress-serve-python3

[Andreas Beckmann]

Followup-For: Bug #984630
Control: tag -1 pending

Hi,

I've just uploaded a NMU with the fix to DELAYED/5.


Andreas

Bug#977299: Fixed in 5.11

[Chris Dos]

Both of these drivers work in 5.11.  Is Debian planning on moving to 5.11 or
sticking with 5.10?  If sticking with 5.10 can the bluetooth drivers be
patched to include Intel Typhoon Peak?

    Chris

Bug#987279: nim: amd64 binaries built by maintainer; needs source-ony upload

[Salvatore Bonaccorso]

Hi,

On Tue, Apr 20, 2021 at 08:58:05PM +0200, Ivo De Decker wrote:
> Federico,
> 
> On Tue, Apr 20, 2021 at 08:49:54PM +0200, Salvatore Bonaccorso wrote:
> > The last nim upload seems to have included binary builds for amd64
> > which will prevent nim to potentially go to testing (even after
> > unblocked), as it needs a source-only upload with builds done on
> > buildds.
> > 
> > Cf. https://tracker.debian.org/pkg/nim
> > 
> >  * Not built on buildd: arch amd64 binaries uploaded by 
> > federico.cera...@gmail.com
> >  * Not built on buildd: arch all binaries uploaded by 
> > federico.cera...@gmail.com, a new source-only upload is needed to allow 
> > migration
> 
> I guess something went wrong with the upload, because the changes file has
> both
> 
> Distribution: sid
> 
> and
> 
> nim (1.4.6-1) experimental; urgency=medium
> 
> 
> Please check what went wrong to avoid this in the future.
> 
> In this case, I suspect the upload wasn't meant for bullseye, and it can just
> stay in unstable (unfortunately).

Unfortunately there is related the bug filled by Moritz, #987272,
JFYI. Probably needs still a revert in unstable to the old version +
patches?

Regards,
Salvatore

Bug#987285: pound FTCBFS: runs cmake for the build architecture

[Helmut Grohne]

Source: pound
Version: 3.0-2
Tags: patch
User: debian-cr...@lists.debian.org
Usertags: ftcbfs

pound fails to cross build from source since the 3.0-2 upload to
unstable, because it does not pass cross flags to cmake. The easiest way
of doing so - using dh_auto_configure - makes pound cross buildable.
Please consider applying the attached patch.

Helmut
diff --minimal -Nru pound-3.0/debian/changelog pound-3.0/debian/changelog
--- pound-3.0/debian/changelog  2020-12-10 11:23:42.0 +0100
+++ pound-3.0/debian/changelog  2021-04-19 11:43:30.0 +0200
@@ -1,3 +1,10 @@
+pound (3.0-2.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix FTCBFS: Let dh_auto_configure pass cross flags to cmake. (Closes: #-1)
+
+ -- Helmut Grohne   Mon, 19 Apr 2021 11:43:30 +0200
+
 pound (3.0-2) unstable; urgency=medium
 
   * Fix FTBS on KFreeBSD
diff --minimal -Nru pound-3.0/debian/rules pound-3.0/debian/rules
--- pound-3.0/debian/rules  2020-12-10 11:23:42.0 +0100
+++ pound-3.0/debian/rules  2021-04-19 11:43:12.0 +0200
@@ -17,7 +17,7 @@
dh "$@" --with sysuser
 
 override_dh_auto_configure:
-   cd build && cmake ..
+   dh_auto_configure --builddirectory=build
 
 override_dh_auto_build:
cd build && make

Bug#987286: trueprint FTCBFS: does not pass --host to ./configure

[Helmut Grohne]

Source: trueprint
Version: 5.4-3
Tags: patch
User: debian-cr...@lists.debian.org
Usertags: ftcbfs

trueprint fails to cross build from source, because it does not pass
--host to ./configure. The easiest way of doing so - using
dh_auto_configure - makes trueprint cross buildable. Please consider
applying the attached patch.

Helmut
diff --minimal -Nru trueprint-5.4/debian/changelog 
trueprint-5.4/debian/changelog
--- trueprint-5.4/debian/changelog  2019-12-23 15:46:03.0 +0100
+++ trueprint-5.4/debian/changelog  2021-04-19 11:47:38.0 +0200
@@ -1,3 +1,9 @@
+trueprint (5.4-5) UNRELEASED; urgency=medium
+
+  * Fix FTCBFS: Let dh_auto_configure pass --host to ./configure. (Closes: #-1)
+
+ -- Helmut Grohne   Mon, 19 Apr 2021 11:47:38 +0200
+
 trueprint (5.4-4) unstable; urgency=medium
 
   * QA upload.
diff --minimal -Nru trueprint-5.4/debian/rules trueprint-5.4/debian/rules
--- trueprint-5.4/debian/rules  2019-12-23 15:46:03.0 +0100
+++ trueprint-5.4/debian/rules  2021-04-19 11:47:36.0 +0200
@@ -8,7 +8,7 @@
dh $@
 
 override_dh_auto_configure:
-   ./configure --prefix=/usr --libdir=/etc/trueprint
+   dh_auto_configure -- --libdir=/etc/trueprint
 
 override_dh_auto_install:
dh_auto_install

Bug#987284: CVE-2021-29428 CVE-2021-29429

[Moritz Muehlenhoff]

Package: gradle
Severity: important
Tags: security
X-Debbugs-Cc: Debian Security Team 

CVE-2021-29429
https://github.com/gradle/gradle/security/advisories/GHSA-fp8h-qmr5-j4c8

CVE-2021-29428
https://github.com/gradle/gradle/security/advisories/GHSA-89qm-pxvm-p336

Cheers,
Moritz  

Bug#987283: Filter list for "unreported" view

[Moritz Muehlenhoff]

Package: security-tracker
Severity: wishlist

https://security-tracker.debian.org/tracker/status/unreported should
gain a filter list, since there are some packages for which filing
bugs makes no sense (e.g. the linux kernel, which is tracked without
filed bugs in the BTS or various legacy Nvidia packages, which are
known vulnerable, but still kept around for hw compat).

Ideally we simply have a list of source packages kept under CVE/*
which are filtered out.

Cheers,
Moritz

Bug#987279: nim: amd64 binaries built by maintainer; needs source-ony upload

[Ivo De Decker]

Federico,

On Tue, Apr 20, 2021 at 08:49:54PM +0200, Salvatore Bonaccorso wrote:
> The last nim upload seems to have included binary builds for amd64
> which will prevent nim to potentially go to testing (even after
> unblocked), as it needs a source-only upload with builds done on
> buildds.
> 
> Cf. https://tracker.debian.org/pkg/nim
> 
>  * Not built on buildd: arch amd64 binaries uploaded by 
> federico.cera...@gmail.com
>  * Not built on buildd: arch all binaries uploaded by 
> federico.cera...@gmail.com, a new source-only upload is needed to allow 
> migration

I guess something went wrong with the upload, because the changes file has
both

Distribution: sid

and

nim (1.4.6-1) experimental; urgency=medium


Please check what went wrong to avoid this in the future.

In this case, I suspect the upload wasn't meant for bullseye, and it can just
stay in unstable (unfortunately).

Cheers,

Ivo

Bug#987282: CVE-2021-30146

[Moritz Muehlenhoff]

Source: seafile-client
Severity: important
Tags: security
X-Debbugs-Cc: Debian Security Team 

This was assigned CVE-2021-30146:
https://github.com/Security-AVS/CVE-2021-30146

It's not really clear whether that was reported upstream, could
you check with them?

Cheers,
Moritz  

Bug#987281: linux-image-amd64: Enable i915 HDCP 2.2 support

[Bastian Germann]

Package: linux-image-amd64
Severity: wishlist

Since Linux 5.6, CONFIG_INTEL_MEI_HDCP is available which allows to use HDCP 2.2 with i915 graphics. 
The HDCP support for AMD GPUs is already enabled (CONFIG_DRM_AMD_DC_HDCP=y).


Having this available in the kernel config would improve support for various video streaming 
services and enable full use of package intel-hdcp. Its README claims CONFIG_INTEL_MEI_TXE must be 
available as well, which might be an outdated information.


Please enable both CONFIG_INTEL_MEI_HDCP and CONFIG_INTEL_MEI_TXE as modules.

Bug#987022: unblock: spamassassin/3.4.5~pre1-4

[Ivo De Decker]

Control: tags -1 confirmed moreinfo

Hi Noah,

On Thu, Apr 15, 2021 at 11:52:39AM -0700, Noah Meyerhans wrote:
> Package: release.debian.org
> Severity: normal
> User: release.debian@packages.debian.org
> Usertags: unblock
> 
> (I sent a similar message to debian-release recently, but am opening a
> bug under the expectation that the post will get lost in the noise.)
> 
> There are a few issues in spamassassin that need to be addressed prior to
> the bullseye release, and I'd like to discuss the best path forward.
> 
> Bullseye currently contains version 3.4.5~pre1-3, which is based on a
> pre-release of the 3.4.5 upstream release.  Upstream released 3.4.5 during
> the bullseye freeze, and followed up immediately with a 3.4.6 to fix two
> regressions [1] [2] that were not caught in testing.  The regressions are
> already present in 3.4.5~pre-3, so we'll need some form of an update.
> 
> I'd also like to include the fix for [3], which breaks installation in some
> (uncommon) scenarios.  The fix is small and should be low-risk.
> 
> These are all pretty clearly issues that need to get fixed.  What I'm
> specifically interested in discussing, though, is the various upstream
> commits between the 3.4.5-pre1 release and 3.4.5-final.  There are 37
> commits in this set, involved in fixing 10 upstream bugs.  As most of these
> bugs involve miscategorization of processed email, leaving them unfixed can
> potentially lead to data loss.
> 
> I've compiled a list of the upstream bugs fixed in their 3.4 branch at [4].
> 
> Most of the rest of the changes have to do with release administrivia
> and housekeeping (svn branch management, updating the Apache logo,
> updating version strings, spelling corrections, etc).
> 
> If it was completely up to me, I'd want 3.4.6-1 released with bullseye.
> It will be better supported by upstream and contains all the relevant
> bug fixes.  IMO it's less likely to introduce any new regressions than a
> 3.4.5-pre1-4 with relevant changes pulled back from upstream's svn.
> However, it's late in the freeze and I fully understand the policy wrt
> to new upstream releases.
> 
> The alternative is that we update to a 3.4.5~pre1-4 that cherry-picks
> only the specific commits targeting the bugs I'd like to fix.  This
> will definitely result in a smaller debdiff, but would still carry a
> comparable level of risk due to the cherry-picked changes being most
> of the actual code changes introduced upstream.
> 
> The debdiff for 3.4.6-1 is at [5].  The debdiff for 3.4.5~pre1-4 is at
> [6].

I suggest you upload 3.4.5~pre1-4 to unstable and 3.4.6-1 to experimental. I
haven't looked at 3.4.5~pre1-4 in detail yet, but I suspect it will be fine.
Once it migrates, we can look at 3.4.6-1 again, and by then, the upload to
experimental will at least show us obvious issues in the builds or the ci.

Please remove the moreinfo tag from this bug when 3.4.5~pre1-4 (or something
similar) is ready to migrate.

Thanks,

Ivo

Bug#987280: CVE-2021-31254 CVE-2021-31255 CVE-2021-31256 CVE-2021-31257 CVE-2021-31258 CVE-2021-31259 CVE-2021-31260 CVE-2021-31261 CVE-2021-31262

[Moritz Muehlenhoff]

Package: gpac
Version: 1.0.1+dfsg1-3
Severity: grave
Tags: security
X-Debbugs-Cc: Debian Security Team 

CVE-2021-31262
https://github.com/gpac/gpac/commit/b2eab95e07cb5819375a50358d4806a8813b6e50
https://github.com/gpac/gpac/issues/1738

CVE-2021-31261
https://github.com/gpac/gpac/commit/cd3738dea038dbd12e603ad48cd7373ae0440f65
https://github.com/gpac/gpac/issues/1737

CVE-2021-31260
https://github.com/gpac/gpac/commit/df8fffd839fe5ae9acd82d26fd48280a397411d9
https://github.com/gpac/gpac/issues/1736

CVE-2021-31259
https://github.com/gpac/gpac/commit/3b84ffcbacf144ce35650df958432f472b6483f8
https://github.com/gpac/gpac/issues/1735

CVE-2021-31258
https://github.com/gpac/gpac/commit/ebfa346eff05049718f7b80041093b4c5581c24e
https://github.com/gpac/gpac/issues/1706

CVE-2021-31257
https://github.com/gpac/gpac/commit/87afe070cd6866df7fe80f11b26ef75161de85e0
https://github.com/gpac/gpac/issues/1734

CVE-2021-31256
https://github.com/gpac/gpac/commit/2da2f68bffd51d89b1d272d22aa8cc023c1c066e
https://github.com/gpac/gpac/issues/1705

CVE-2021-31255
https://github.com/gpac/gpac/commit/758135e91e623d7dfe7f6aaad7aeb3f791b7a4e5
https://github.com/gpac/gpac/issues/1733

CVE-2021-31254
https://github.com/gpac/gpac/commit/8986422c21fbd9a7bf6561cae65aae42077447e8
https://github.com/gpac/gpac/issues/1703

Cheers,
Moritz  

Bug#987279: nim: amd64 binaries built by maintainer; needs source-ony upload

[Salvatore Bonaccorso]

Source: nim
Version: 1.4.6-1
Severity: serious
Justification: not build on all release architectures by buildds; no 
source-only upload
X-Debbugs-Cc: car...@debian.org

Hi

The last nim upload seems to have included binary builds for amd64
which will prevent nim to potentially go to testing (even after
unblocked), as it needs a source-only upload with builds done on
buildds.

Cf. https://tracker.debian.org/pkg/nim

 * Not built on buildd: arch amd64 binaries uploaded by 
federico.cera...@gmail.com
 * Not built on buildd: arch all binaries uploaded by 
federico.cera...@gmail.com, a new source-only upload is needed to allow 
migration

Regards,
Salvatore

Bug#986623: tuxmath: Segfaults on startup

[Bernhard Übelacker]

Attached patch just renames the global variable blits to tmblits.
A package tuxmath built with this patch does not show this crash.


Sorry, forgot to attach.
Bug-Debian: https://bugs.debian.org/986623
Forwarded: no
Last-Update: 2021-04-20

--- tuxmath-2.0.3.orig/src/titlescreen.c
+++ tuxmath-2.0.3/src/titlescreen.c
@@ -55,7 +55,7 @@ struct blit {
 SDL_Rect *srcrect;
 SDL_Rect *dstrect;
 unsigned char type;
-} blits[MAX_UPDATES];
+} tmblits[MAX_UPDATES];
 
 // Lessons available for play
 char **lesson_list_titles = NULL;
@@ -1019,8 +1019,8 @@ void init_blits(void) {
 int i;
 
 for (i = 0; i < MAX_UPDATES; ++i) {
-	blits[i].srcrect = [i];
-	blits[i].dstrect = [i];
+	tmblits[i].srcrect = [i];
+	tmblits[i].dstrect = [i];
 }
 }
 
@@ -1032,14 +1032,14 @@ void update_screen(int *frame) {
 
 /* -- First erase everything we need to -- */
 for (i = 0; i < numupdates; i++)
-	if (blits[i].type == 'E')
-	SDL_LowerBlit(blits[i].src, blits[i].srcrect, screen, blits[i].dstrect);
+	if (tmblits[i].type == 'E')
+	SDL_LowerBlit(tmblits[i].src, tmblits[i].srcrect, screen, tmblits[i].dstrect);
 //SNOW_erase();
 
 /* -- then draw -- */
 for (i = 0; i < numupdates; i++)
-	if (blits[i].type == 'D')
-	SDL_BlitSurface(blits[i].src, blits[i].srcrect, screen, blits[i].dstrect);
+	if (tmblits[i].type == 'D')
+	SDL_BlitSurface(tmblits[i].src, tmblits[i].srcrect, screen, tmblits[i].dstrect);
 //SNOW_draw();
 
 /* -- update the screen only where we need to! -- */
@@ -1067,7 +1067,7 @@ void add_rect(SDL_Rect* src, SDL_Rect* d
 	return;
 }
 
-update = [numupdates++];
+update = [numupdates++];
 
 update->srcrect->x = src->x;
 update->srcrect->y = src->y;

Bug#987278: CVE-2021-30498 CVE-2021-30499

[Moritz Muehlenhoff]

Source: libcaca
Severity: important
Tags: security
X-Debbugs-Cc: Debian Security Team 

CVE-2021-30499:
https://github.com/cacalabs/libcaca/issues/54

CVE-2021-30498:
https://github.com/cacalabs/libcaca/issues/53

Cheers,
Moritz  

Bug#987277: CVE-2021-29457 CVE-2021-29458

[Moritz Muehlenhoff]

Package: exiv2
Version: 0.27.3-3
Severity: important
Tags: security
X-Debbugs-Cc: Debian Security Team 

CVE-2021-29458:
https://github.com/Exiv2/exiv2/security/advisories/GHSA-57jj-75fm-9rq5
https://github.com/Exiv2/exiv2/issues/1530
https://github.com/Exiv2/exiv2/pull/1536

CVE-2021-29457:
https://github.com/Exiv2/exiv2/security/advisories/GHSA-v74w-h496-cgqm
https://github.com/Exiv2/exiv2/issues/1529
https://github.com/Exiv2/exiv2/pull/1534

Cheers,
Moritz  

Bug#987105: inkscape: Incoherent style for window titlebar buttons

[Joseph Ponte]

Hi Mattia!

In fact, it is the same! I believe we can close this issue report and
follow the thread on https://gitlab.com/inkscape/inkscape/-/issues/1925.

Thanks!

Joseph


On Sat, 17 Apr 2021 20:53:15 +0200 Mattia Rizzolo  wrote:
> Hi!
>
> On Sat, Apr 17, 2021 at 03:44:06PM -0300, Joseph Ponte wrote:
> > The windows title bar buttons of inkscape package have a different
style from standard GTK theme.
> >
> > It seems overwrite on front of the correct style. It is more evident
when use the GTK arc-theme for example.
> >
> > It happens with all of three buttons (minize, maximize and close)
> >
> > An anhoter behavior that I noticed, the application GTK theme doesn't
> > change automatically when I change the settings of gnome-shell  with
> > gsettings set org.gnome.desktop.interface gtk-theme.
>
> Could you please see if what you are describing is the same as this:
> https://gitlab.com/inkscape/inkscape/-/issues/1925
>
> Else, since I cannot find anything similar besides that one report, it
> would be best if you could file this issue directly upstream here:
> https://gitlab.com/inkscape/inbox/-/issues/new
>
> --
> regards,
> Mattia Rizzolo
>
> GPG Key: 66AE 2B4A FCCF 3F52 DA18  4D18 4B04 3FCD B944 4540  .''`.
> More about me:  https://mapreri.org : :'  :
> Launchpad user: https://launchpad.net/~mapreri  `. `'`
> Debian QA page: https://qa.debian.org/developer.php?login=mattia  `-

Bug#986623: tuxmath: Segfaults on startup

[Bernhard Übelacker]

Dear Maintainer,
I tried to have a look at this crash and
got this backtrace [1].

It looks like there is a disaggreement about the size of the blits structure,
one inside tuxmath and one inside libt4k-common0:
tuxmath-2.0.3/src/titlescreen.h:65:#define MAX_UPDATES 
180
tuxmath-2.0.3/src/titlescreen.c:58:} blits[MAX_UPDATES];
t4kcommon-0.1.1/src/t4k_sdl.c:954:#define MAX_UPDATES 512
t4kcommon-0.1.1/src/t4k_sdl.c:966:} blits[MAX_UPDATES];

Because of this libt4k-common0 accesses memory behind the 180
records of the blits structure from tuxmath.

Attached patch just renames the global variable blits to tmblits.
A package tuxmath built with this patch does not show this crash.

I found no exact match in upstream bug trackers,
but I guess [2] is about this bug.

Currently I see no direct connection to #933346.

Kind regards,
Bernhard


[1]
(gdb) bt
#0  0x7f063879a972 in T4K_AddRect (src=src@entry=0x7ffede50c468, 
dst=dst@entry=0x7ffede50c468) at t4k_sdl.c:1034
#1  0x7f063879acb3 in T4K_TransWipe (newbkg=0x55bd0b680520, 
type=, type@entry=RANDOM_WIPE, segments=segments@entry=5, 
duration=duration@entry=20) at t4k_sdl.c:824
#2  0x55bd0893b23f in TitleScreen () at titlescreen.c:245
#3  0x55bd08938bee in main (argc=, argv=) 
at tuxmath.c:41

https://sources.debian.org/src/t4kcommon/0.1.1-10/src/t4k_sdl.c/#L1034


[2]
https://github.com/tux4kids/tuxmath/issues/16

# single-use Bullseye/testing amd64 qemu VM 2021-04-20

echo "set enable-bracketed-paste off" >> /etc/inputrc; bash

apt update

# to speedup testing
mv /etc/manpath.config /etc/manpath.config.renamed
apt install libeatmydata1
export LD_PRELOAD=/usr/lib/x86_64-linux-gnu/libeatmydata.so

apt dist-upgrade
apt install systemd-coredump mc gdb rr lightdm xserver-xorg jwm fakeroot 
tuxmath \
tuxmath-dbgsym libt4k-common0-dbgsym

apt build-dep tuxmath libt4k-common0


mkdir /home/benutzer/source/tuxmath/orig -p
cd/home/benutzer/source/tuxmath/orig
apt source tuxmath
cd

mkdir /home/benutzer/source/libt4k-common0/orig -p
cd/home/benutzer/source/libt4k-common0/orig
apt source libt4k-common0
cd







benutzer@debian:~$ export DISPLAY=:0
benutzer@debian:~$ tuxmath
Initializing Tux4Kids-Common 0.1.1
ALSA lib pcm.c:8545:(snd_pcm_recover) underrun occurred
libpng warning: iCCP: known incorrect sRGB profile
libpng warning: iCCP: known incorrect sRGB profile
libpng warning: iCCP: known incorrect sRGB profile
libpng warning: iCCP: known incorrect sRGB profile
libpng warning: iCCP: known incorrect sRGB profile
libpng warning: iCCP: known incorrect sRGB profile
libpng warning: iCCP: known incorrect sRGB profile
libpng warning: iCCP: known incorrect sRGB profile
libpng warning: iCCP: known incorrect sRGB profile
libpng warning: iCCP: known incorrect sRGB profile
libpng warning: iCCP: known incorrect sRGB profile
libpng warning: iCCP: known incorrect sRGB profile
libpng warning: iCCP: known incorrect sRGB profile
libpng warning: iCCP: known incorrect sRGB profile
libpng warning: iCCP: known incorrect sRGB profile
libpng warning: iCCP: known incorrect sRGB profile
libpng warning: iCCP: known incorrect sRGB profile
libpng warning: iCCP: known incorrect sRGB profile
Speicherzugriffsfehler (Speicherabzug geschrieben)



root@debian:~# coredumpctl list
TIMEPID   UID   GID SIG COREFILE  EXE
Tue 2021-04-20 15:45:51 CEST644  1000  1000  11 present   
/usr/lib/tuxmath/tuxmath

root@debian:~# coredumpctl gdb 644
   PID: 644 (tuxmath)
   UID: 1000 (benutzer)
   GID: 1000 (benutzer)
Signal: 11 (SEGV)
 Timestamp: Tue 2021-04-20 15:45:50 CEST (38s ago)
  Command Line: tuxmath
Executable: /usr/lib/tuxmath/tuxmath
 Control Group: /user.slice/user-1000.slice/session-5.scope
  Unit: session-5.scope
 Slice: user-1000.slice
   Session: 5
 Owner UID: 1000 (benutzer)
   Boot ID: 27f9ae5d40034f8484e4d155de897ba4
Machine ID: 33f18f39d2a9438eb75b0ed52848afcd
  Hostname: debian
   Storage: 
/var/lib/systemd/coredump/core.tuxmath.1000.27f9ae5d40034f8484e4d155de897ba4.644.161892635000.zst
   Message: Process 644 (tuxmath) of user 1000 dumped core.

Stack trace of thread 644:
#0  0x7f063879a972 T4K_AddRect (libt4k_common.so.0 + 0xe972)
#1  0x7f063879acb3 T4K_TransWipe (libt4k_common.so.0 + 
0xecb3)
#2  0x55bd0893b23f n/a (tuxmath + 0x923f)
#3  0x55bd08938bee main (tuxmath + 0x6bee)
#4  0x7f06385c9d0a __libc_start_main (libc.so.6 + 0x26d0a)
#5  0x55bd08938c2a n/a (tuxmath + 0x6c2a)

...
Core was generated by `tuxmath'.
Program terminated with signal SIGSEGV, Segmentation fault.
#0  0x7f063879a972 in T4K_AddRect () from 
/lib/x86_64-linux-gnu/libt4k_common.so.0
[Current thread is 1 (Thread 0x7f0632edfe80 (LWP 644))]
(gdb) 

Bug#987276: CVE-2021-29338

[Moritz Muehlenhoff]

Source: openjpeg2
Severity: important
Tags: security
X-Debbugs-Cc: Debian Security Team 

This was assigned CVE-2021-29338:
https://github.com/uclouvain/openjpeg/issues/1338

Cheers,
Moritz

Bug#987275: CVE-2021-28305

[Moritz Muehlenhoff]

Source: rust-diesel
Severity: grave
Tags: security
X-Debbugs-Cc: Debian Security Team 

This was assigned CVE-2021-28305:
https://rustsec.org/advisories/RUSTSEC-2021-0037.html

Cheers,
Moritz  

Bug#987274: CVE-2021-22879

[Moritz Muehlenhoff]

Package: nextcloud-desktop
Severity: important
Tags: security
X-Debbugs-Cc: Debian Security Team 

https://nextcloud.com/security/advisory/?id=NC-SA-2021-008

Bumping to 3.1.3 is not in line with the current freeze, but
the patches from https://github.com/nextcloud/desktop/pull/2906
can be applied instead.

Cheers, 
Moritz

Bug#987273: CVE-2021-21783

[Moritz Muehlenhoff]

Package: libgsoap-2.8.104
Version: 2.8.104-2
Severity: important
File: gsoap
Tags: security
X-Debbugs-Cc: Debian Security Team 

This was assigned CVE-2021-21783:
https://talosintelligence.com/vulnerability_reports/TALOS-2021-1245

Cheers,
Moritz  

Bug#987272: CVE-2021-21372 CVE-2021-21373 CVE-2021-21374

[Moritz Muehlenhoff]

Package: nim
Severity: important
Tags: security
X-Debbugs-Cc: Debian Security Team 

https://consensys.net/diligence/vulnerabilities/nim-insecure-ssl-tls-defaults-remote-code-execution/

This is fixed in experimental, but for unstable please do a targeted upload
and ask for an unblock with the release team.

Cheers,
Moritz

Bug#986492: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=986492

[Jai Bheemsen Rao Dhanwada]

Can you please provide an update on this?

Bug#987101: RM: ruby-rexml -- ROM; duplicate package, included in libruby2.7

[Ivo De Decker]

Hi,

On Sat, Apr 17, 2021 at 10:30:18PM +0530, Pirate Praveen wrote:
> This package duplicates fucntionality embedded in ruby. This is affected by
> rc bug #986806 (already fixed in ruby2.7 2.7.3-1). As discussed in the rc
> bug above, please remove this package from the archive.

Just a note for the ftp-team:

As mentioned in the other bug report: dak rm show an rdep problem with
ruby-kramdown, but that's not actually the case, because libruby2.7 Provides
ruby-rexml:

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=986806#46

Thanks!

Ivo

Bug#987271: Consider offering octopus project as backend for gpg support in thunderbird

[Pirate Praveen]

Package: thunderbird
Severity: wishlist

There is a new OpenPGP backend for thunderbird.
https://lib.rs/crates/sequoia-octopus-librnp

and fedora is already offering packages to test it,

https://discussion.fedoraproject.org/t/sequoia-pgp-packages-and-alternative-thunderbird-openpgp-backend-ready-for-testing/28787

they list some of the advantages in the linked article,

The “Octopus” backend for Thunderbird has several advantages 
compared to the bundled RNP backend:


integration with the GnuPG keyring
integration with running gpg agents
no support for weak cryptographic standards
in-memory-encryption of GPG keys
restrictions for SHA-1 use and mitigations for SHA-1 collision attacks
better conformance and compatibility with OpenPGP than librnp
better performance (parallelized parsing, background tasks as threads)
memory- and thread-safe implementation in Rust
uses system nettle as cryptography library instead of botan (which is 
not available in RHEL)


Since it is not yet ready for production use, we could offer it as an 
option in experimental.

Bug#986363: ITA: guile-lib -- Library of useful Guile modules

[Vagrant Cascadian]

Control: retitle 986363 ITA: guile-lib -- Library of useful Guile modules
Control: owner 986363 vagr...@debian.org

On 2021-04-04, Göran Weinholt wrote:
> I intend to orphan the guile-lib package.
>
> The package description is:
>  A set of various-purpose library modules for Guile. Covered areas include:
>  .
>   * Unit testing framework ala JUnit
>   * Logging system
>   * String routines (wrapping, completion, soundex algorithm)
>   * OS process chains (think "shell pipes in scheme")
>   * ANSI escape sequence text coloring
>   * A thread-safe message queue
>   * Routines to perform topological sorts
>   * Neil Van Dyke's permissive ("pragmatic") HTML parser
>   * Nifty and concise regular expression routines
>   * Classic search functions

This is a build dependency of newer versions of guix (and the upcoming
guix version requires a newer version of guile-lib), so looks like I
should adopt it!

I did some quick testing of the updated guile-lib version, and the
packaging was nicely up-to-date and didn't require much more than
merging the new version, so hope to upload to experimental in the next
few days...


live well,
  vagrant


signature.asc
Description: PGP signature

Bug#987270: unblock: epix/1.2.19-2

[Julian Gilbey]

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

Please unblock package epix

(Please provide enough (but not too much) information to help
the release team to judge the request efficiently. E.g. by
filling in the sections below.)

[ Reason ]
(Explain what the reason for the unblock request is.)
To fix RC bug#987258: causes xemacs21 to fail to install and vice versa

[ Impact ]
(What is the impact for the user if the unblock isn't granted?)
The presence of this package will prevent installation of xemacs21 and
vice versa

[ Tests ]
(What automated or manual tests cover the affected code?)
I have manually installed xemacs21 and epix together on a machine
running Debian testing after applying this fix, but was unable to do
so before fixing it.

[ Risks ]
(Discussion of the risks involved. E.g. code is trivial or
complex, key package vs leaf package, alternatives available.)
Leaf package, change in packaging is small.

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

[ Other info ]
(Anything else the release team should know.)
The three changes listed in d/changelog:
* The first is needed to fix the RC bug; the required scripts are now
  generated automatically by dh_elpa or something similar during the
  build process
* The second change is a fix for a bug discovered by building this on
  a new machine with a merged /usr; autoconf checked for bash and
  found it as /usr/bin/bash, which is in contravention of policy.
* The third change is to remove an empty lisp directory; it was
  already empty in 1.2.19-1 but I hadn't noticed.

unblock epix/1.2.19-2
diff -Nru epix-1.2.19/debian/changelog epix-1.2.19/debian/changelog
--- epix-1.2.19/debian/changelog2020-04-02 22:57:19.0 +0100
+++ epix-1.2.19/debian/changelog2021-04-20 17:54:01.0 +0100
@@ -1,3 +1,15 @@
+epix (1.2.19-2) unstable; urgency=medium
+
+  * Remove old debian/epix.emacsen-* files which prevented dh-elpa from
+working correctly (Closes: #987258)
+  * Force configure to use /bin/bash for bash, otherwise building on
+systems with /bin being a symlink to /usr/bin leads to scripts with
+the incompatible /usr/bin/bash as their interpreter
+  * Remove now-empty directory usr/share/emacs/site-lisp/epix from
+debian/epix.dirs
+
+ -- Julian Gilbey   Tue, 20 Apr 2021 17:54:01 +0100
+
 epix (1.2.19-1) unstable; urgency=medium
 
   * New upstream release
diff -Nru epix-1.2.19/debian/epix.dirs epix-1.2.19/debian/epix.dirs
--- epix-1.2.19/debian/epix.dirs2020-04-02 22:57:19.0 +0100
+++ epix-1.2.19/debian/epix.dirs2021-04-20 17:54:01.0 +0100
@@ -1,5 +1,4 @@
 usr/bin
 usr/lib
 usr/include
-usr/share/emacs/site-lisp/epix
 usr/share/bash-completion/completions
diff -Nru epix-1.2.19/debian/epix.emacsen-compat 
epix-1.2.19/debian/epix.emacsen-compat
--- epix-1.2.19/debian/epix.emacsen-compat  2020-04-02 22:57:19.0 
+0100
+++ epix-1.2.19/debian/epix.emacsen-compat  1970-01-01 01:00:00.0 
+0100
@@ -1 +0,0 @@
-0
diff -Nru epix-1.2.19/debian/epix.emacsen-install 
epix-1.2.19/debian/epix.emacsen-install
--- epix-1.2.19/debian/epix.emacsen-install 2020-04-02 22:57:19.0 
+0100
+++ epix-1.2.19/debian/epix.emacsen-install 1970-01-01 01:00:00.0 
+0100
@@ -1,45 +0,0 @@
-#! /bin/sh -e
-# /usr/lib/emacsen-common/packages/install/epix
-
-# Written by Jim Van Zandt , borrowing heavily
-# from the install scripts for gettext by Santiago Vila
-#  and octave by Dirk Eddelbuettel .
-
-FLAVOR=$1
-PACKAGE=epix
-
-if [ ${FLAVOR} = emacs ]; then exit 0; fi
-
-echo install/${PACKAGE}: Handling install for emacsen flavor ${FLAVOR}
-
-#FLAVORTEST=`echo $FLAVOR | cut -c-6`
-#if [ ${FLAVORTEST} = xemacs ] ; then
-#SITEFLAG="-no-site-file"
-#else
-#SITEFLAG="--no-site-file"
-#fi
-FLAGS="${SITEFLAG} -q -batch -l path.el -f batch-byte-compile"
-
-ELDIR=/usr/share/emacs/site-lisp/${PACKAGE}
-ELCDIR=/usr/share/${FLAVOR}/site-lisp/${PACKAGE}
-
-# Install-info-altdir does not actually exist. 
-# Maybe somebody will write it.
-if test -x /usr/sbin/install-info-altdir; then
-echo install/${PACKAGE}: install Info links for ${FLAVOR}
-install-info-altdir --quiet --section "" "" --dirname=${FLAVOR} 
/usr/info/${PACKAGE}.info.gz
-fi
-
-install -m 755 -d ${ELCDIR}
-cd ${ELDIR}
-FILES=`echo *.el`
-cp ${FILES} ${ELCDIR}
-cd ${ELCDIR}
-
-cat << EOF > path.el
-(setq load-path (cons "." load-path) byte-compile-warnings nil)
-EOF
-${FLAVOR} ${FLAGS} ${FILES}
-rm -f *.el path.el
-
-exit 0
diff -Nru epix-1.2.19/debian/epix.emacsen-remove 
epix-1.2.19/debian/epix.emacsen-remove
--- epix-1.2.19/debian/epix.emacsen-remove  2020-04-02 22:57:19.0 
+0100
+++ epix-1.2.19/debian/epix.emacsen-remove  1970-01-01 01:00:00.0 
+0100
@@ -1,15 +0,0 @@
-#!/bin/sh -e
-# 

Bug#987255: puppet: needs an extra systemd config line to use the right SE Linux context

[Russell Coker]

Package: puppet
Version: 5.5.22-2
Severity: normal
Tags: patch upstream

# ps axZ|grep pupp
system_u:system_r:initrc_t:s0  1603 ?Ss 0:00 /usr/bin/ruby 
/usr/bin/puppet agent

Because the same program /usr/bin/puppet is used for starting the agent and the
master we can't get the correct SE Linux domain via an automatic domain
transition.  So puppet ends up in initrc_t which is not the desired domain.

[Service]
SELinuxContext=system_u:system_r:puppet_t:s0

If the above is put in /lib/systemd/system/puppet.service then systemd will
assign the correct context if SE Linux is active and it will ignore it if SE
Linux is not active.  There is no downside to this for people who don't use SE
Linux, but it is a benefit for those who do.

Currently SE Linux users need to run "systemctl edit puppet.service" to put an
override for this.

system_u:system_r:puppet_t:s0  1683 ?Ss 0:00 /usr/bin/ruby 
/usr/bin/puppet agent

The above is the desired result in the output of "ps axZ".

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

Kernel: Linux 5.10.0-6-amd64 (SMP w/2 CPU threads)
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: SELinux: enabled - Mode: Enforcing - Policy name: default

Versions of packages puppet depends on:
ii  adduser  3.118
ii  facter   3.14.12-1+b2
ii  hiera3.2.0-2.1
ii  init-system-helpers  1.60
ii  lsb-base 11.1.0
ii  ruby 1:2.7+2
ii  ruby-augeas  1:0.5.0-3+b8
ii  ruby-deep-merge  1.1.1-1
ii  ruby-shadow  2.5.0-1+b4

Versions of packages puppet recommends:
pn  debconf-utils  
ii  lsb-release11.1.0
pn  ruby-selinux   

Versions of packages puppet suggests:
pn  ruby-hocon  
pn  ruby-rrd

-- no debconf information

Bug#987269: dh-make-golang: Support building a binary package from a sub directory of source package

[Pirate Praveen]

Package: dh-make-golang
Version: 0.4.0-1
Severity: wishlist

Examples:
1. github.com/golang/gddo/httputil/ (the base repo has many modules and 
we only need to build a single directory).
2. gitlab-workhorse is now shipped as workhorse directory inside gitlab 
source package.


gem2deb already support such a feature, see this example

https://salsa.debian.org/ruby-team/rails/-/blob/master/debian/control#L129

Package: ruby-activerecord
X-DhRuby-Root: activerecord/

Bug#986564: Crash on pool-evolution

[Bernhard Übelacker]

Dear Maintainer,
with the help of the dbgsym package the "Code:" line
points to this line [1]:
0x7fffebed7f9c in camel_imapx_folder_set_mailbox at 
./src/camel/providers/imapx/camel-imapx-folder.c:1371

The function camel_imapx_folder_set_mailbox then points
to this upstream bug report [2].
That also mentions another Debian report #985353, which
shows the same line and instruction offset.

Kind regards,
Bernhard


[1]

https://sources.debian.org/src/evolution-data-server/3.38.3-1/src/camel/providers/imapx/camel-imapx-folder.c/#L1371

https://gitlab.gnome.org/GNOME/evolution-data-server/-/blob/master/src/camel/providers/imapx/camel-imapx-folder.c#L1364

[2]
https://gitlab.gnome.org/GNOME/evolution-data-server/-/issues/312

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



From submitter:
kernel: [27363.195104] pool-evolution[76405]: segfault at 28 ip 
7f6d1e663f9c sp 7f6d0b7fd7a0 error 4 in 
libcamelimapx.so[7f6d1e656000+3b000]
kernel: [27363.195115] Code: c6 e8 78 48 ff ff 48 89 c7 e8 b0 36 ff ff 4c 89 ee 
48 89 c7 e8 65 48 ff ff 4c 89 e7 49 89 c5 e8 ba 56 ff ff 85 c0 74 10 89 c6 <49> 
3b 75 28 74 08 48 89 ef e8 b6 36 ff ff 48 89 ef be 50 00 00 00


https://wiki.debian.org/InterpretingKernelOutputAtProcessCrash


"error 4" == 0b0100
bit 0 ==0: no page found
bit 1 ==0: read access
bit 2 ==1: user-mode access


echo -n "find /b ..., ..., 0x" && \
echo "c6 e8 78 48 ff ff 48 89 c7 e8 b0 36 ff ff 4c 89 ee 48 89 c7 e8 65 48 ff 
ff 4c 89 e7 49 89 c5 e8 ba 56 ff ff 85 c0 74 10 89 c6 <49> 3b 75 28 74 08 48 89 
ef e8 b6 36 ff ff 48 89 ef be 50 00 00 00" \
 | sed 's/[<>]//g' | sed 's/ /, 0x/g'

find /b ..., ..., 0xc6, 0xe8, 0x78, 0x48, 0xff, 0xff, 0x48, 0x89, 0xc7, 0xe8, 
0xb0, 0x36, 0xff, 0xff, 0x4c, 0x89, 0xee, 0x48, 0x89, 0xc7, 0xe8, 0x65, 0x48, 
0xff, 0xff, 0x4c, 0x89, 0xe7, 0x49, 0x89, 0xc5, 0xe8, 0xba, 0x56, 0xff, 0xff, 
0x85, 0xc0, 0x74, 0x10, 0x89, 0xc6, 0x49, 0x3b, 0x75, 0x28, 0x74, 0x08, 0x48, 
0x89, 0xef, 0xe8, 0xb6, 0x36, 0xff, 0xff, 0x48, 0x89, 0xef, 0xbe, 0x50, 0x00, 
0x00, 0x00





# single-use Bullseye/testing amd64 qemu VM 2021-04-20

echo "set enable-bracketed-paste off" >> /etc/inputrc; bash

apt update

# to speedup testing
mv /etc/manpath.config /etc/manpath.config.renamed
apt install libeatmydata1
export LD_PRELOAD=/usr/lib/x86_64-linux-gnu/libeatmydata.so

apt dist-upgrade
apt install systemd-coredump gdb evolution evolution-dbgsym 
evolution-data-server-dbgsym





gdb -q
set width 0
set pagination off
file /usr/bin/evolution
tb main
run
call 
dlopen("/usr/lib/evolution-data-server/camel-providers/libcamelimapx.so",0x102)
info share
find /b 0x7fffebecda50, 0x7fffebf044f1, 0xc6, 0xe8, 0x78, 0x48, 0xff, 
0xff, 0x48, 0x89, 0xc7, 0xe8, 0xb0, 0x36, 0xff, 0xff, 0x4c, 0x89, 0xee, 0x48, 
0x89, 0xc7, 0xe8, 0x65, 0x48, 0xff, 0xff, 0x4c, 0x89, 0xe7, 0x49, 0x89, 0xc5, 
0xe8, 0xba, 0x56, 0xff, 0xff, 0x85, 0xc0, 0x74, 0x10, 0x89, 0xc6, 0x49, 0x3b, 
0x75, 0x28, 0x74, 0x08, 0x48, 0x89, 0xef, 0xe8, 0xb6, 0x36, 0xff, 0xff, 0x48, 
0x89, 0xef, 0xbe, 0x50, 0x00, 0x00, 0x00
b * (0x7fffebed7f72 + 42)
info b
disassemble camel_imapx_folder_set_mailbox



(gdb) info share
FromTo  Syms Read   Shared Object Library
...
0x7fffebecda50  0x7fffebf044f1  Yes 
/usr/lib/evolution-data-server/camel-providers/libcamelimapx.so

(gdb) find /b 0x7fffebecda50, 0x7fffebf044f1, 0xc6, 0xe8, 0x78, 0x48, 
0xff, 0xff, 0x48, 0x89, 0xc7, 0xe8, 0xb0, 0x36, 0xff, 0xff, 0x4c, 0x89, 0xee, 
0x48, 0x89, 0xc7, 0xe8, 0x65, 0x48, 0xff, 0xff, 0x4c, 0x89, 0xe7, 0x49, 0x89, 
0xc5, 0xe8, 0xba, 0x56, 0xff, 0xff, 0x85, 0xc0, 0x74, 0x10, 0x89, 0xc6, 0x49, 
0x3b, 0x75, 0x28, 0x74, 0x08, 0x48, 0x89, 0xef, 0xe8, 0xb6, 0x36, 0xff, 0xff, 
0x48, 0x89, 0xef, 0xbe, 0x50, 0x00, 0x00, 0x00
0x7fffebed7f72 
1 pattern found.

(gdb) b * (0x7fffebed7f72 + 42)
Breakpoint 2 at 0x7fffebed7f9c: file 
./src/camel/providers/imapx/camel-imapx-folder.c, line 1371.

(gdb) info b
Num Type   Disp Enb AddressWhat
2   breakpoint keep y   0x7fffebed7f9c in 
camel_imapx_folder_set_mailbox at 
./src/camel/providers/imapx/camel-imapx-folder.c:1371

(gdb) disassemble camel_imapx_folder_set_mailbox
Dump of assembler code for function camel_imapx_folder_set_mailbox:
   0x7fffebed7ee0 <+0>: push   %r13
   0x7fffebed7ee2 <+2>: push   %r12
   0x7fffebed7ee4 <+4>: mov%rsi,%r12
   0x7fffebed7ee7 <+7>: push   %rbp
   0x7fffebed7ee8 <+8>: mov%rdi,%rbp
   0x7fffebed7eeb <+11>:call   0x7fffebecc7c0 

   0x7fffebed7ef0 <+16>:test   %rbp,%rbp
   0x7fffebed7ef3 <+19>:je 0x7fffebed7fd0 

   0x7fffebed7ef9 <+25>:mov%rax,%rsi
   0x7fffebed7efc <+28>:mov0x0(%rbp),%rax
   0x7fffebed7f00 <+32>:test   %rax,%rax
   0x7fffebed7f03 <+35>:je 0x7fffebed7f0a 

   0x7fffebed7f05 <+37>:cmp%rsi,(%rax)
   

Bug#987268: xfce4: Xfce Upgrade Error

[Roger]

Package: xfce4
Version: 4.12
Severity: normal
Tags: upstream

Dear Maintainer,

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

   * What led up to the situation?\
I ran the upgrade yesterday.
   * What exactly did you do (or not do) that was effective (or
 ineffective)?
Upon completion of the upgrade, the notice was given that there were many Xfce
files no longer needed.  It was suggested to use apt autoremove, which I did.
   * What was the outcome of this action?
Upon bootup this morning, there were no panels, and the icon set was different.
Also, the ability to empty the trash was lost with an error message which
stated "The name org.xfce.FileManager was not provided by any .service files".
   * What outcome did you expect instead?
Should never have damaged DE.

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



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

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

Versions of packages xfce4 depends on:
pn  gtk2-engines-xfce
pn  libxfce4ui-utils 
pn  thunar   
pn  xfce4-appfinder  
ii  xfce4-panel  4.12.2-1
pn  xfce4-pulseaudio-plugin  
ii  xfce4-session4.12.1-6
ii  xfce4-settings   4.12.4-1
ii  xfconf   4.12.1-1
ii  xfdesktop4   4.12.4-2
ii  xfwm44.12.5-1

Versions of packages xfce4 recommends:
ii  desktop-base  10.0.2
pn  tango-icon-theme  
pn  thunar-volman 
ii  xfce4-notifyd 0.4.3-1
ii  xorg  1:7.7+19

Versions of packages xfce4 suggests:
pn  gtk3-engines-xfce
pn  xfce4-goodies
pn  xfce4-power-manager  

Bug#987254: puppet-master: needs an extra systemd config line to use the right SE Linux context

[Russell Coker]

Package: puppet-master
Version: 5.5.22-2
Severity: normal
Tags: patch upstream

# ps axZ|grep pupp
system_u:system_r:initrc_t:s0  1351 ?Ssl0:00 /usr/bin/ruby 
/usr/bin/puppet master

Because the same program /usr/bin/puppet is used for starting the agent and the
master we can't get the correct SE Linux domain via an automatic domain
transition.  So puppet ends up in initrc_t which is not the desired domain.

[Service]
SELinuxContext=system_u:system_r:puppetmaster_t:s0

If the above is put in /lib/systemd/system/puppet-master.service then systemd
will assign the correct context if SE Linux is active and it will ignore it if
SE Linux is not active.  There is no downside to this for people who don't use
SE Linux, but it is a benefit for those who do.

Currently SE Linux users need to run "systemctl edit puppet-master.service" to
put an override for this.

system_u:system_r:puppetmaster_t:s0 2668 ?   Ssl0:00 /usr/bin/ruby 
/usr/bin/puppet master

The above is the desired result in the output of "ps axZ".

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

Kernel: Linux 5.10.0-6-amd64 (SMP w/2 CPU threads)
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: SELinux: enabled - Mode: Enforcing - Policy name: default

Versions of packages puppet-master depends on:
ii  init-system-helpers  1.60
ii  lsb-base 11.1.0
ii  puppet   5.5.22-2
ii  ruby 1:2.7+2

puppet-master recommends no packages.

puppet-master suggests no packages.

-- no debconf information

Bug#987266: preinst check for kernel release > 255 may no longer be needed

[Andras Korn]

Package: libc6
Version: 2.31-11
Severity: normal

Hi,

due to 
https://salsa.debian.org/glibc-team/glibc/-/commit/6ddfa57577af0d96df9ddd7be401f5ce9a9bcc0f
 (a commit from 2004) the preinst script for glibc checks whether the "z" in 
the "x.y.z" of the kernel version is less than 255. If yes, the package refuses 
to install.

I hit this problem on a box with a custom 4.9.266 kernel.

Based on this lkml thread: 
https://lore.kernel.org/lkml/7pR0YCctzN9phpuEChlL7_SS6auHOM80bZBcGBTZPuMkc6XjKw7HUXf9vZUPi-IaV2gTtsRVXgywQbja8xpzjGRDGWJsVYSGQN5sNuX1yaQ=@protonmail.com/T/,
 the check is no longer needed because the kernel caps the version code it 
reports to 255, even if uname prints a higher number.

Of course, you could conceivably still hit the problem with earlier kernels, so 
I suppose the logic of the check should be modified, not removed entirely, to 
be technically correct.

If forced at gunpoint to make a guess, I would guess, though, that removing the 
check would have very little actual impact; it also doesn't protect the user 
from installing a kernel with an unsupported version number after having 
installed glibc.

Best regards,

András

-- 
 A ham sandwich is better than nothing. Nothing is better than eternal
 happiness. So a ham sandwich is better than eternal happiness.

Bug#987170: python3-dolfinx: python module missing wrapper functions

[Matsievskiy S.V.]

Got clarification from FEniCS-X team in this thread:
https://fenicsproject.discourse.group/t/debian-dolfinx-package-missing-functionality/5629


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

Bug#987017: recommends 3 different ways to find obsolete packages, pick one

[Antoine Beaupré]

On 2021-04-16 09:19:35, Justin B Rye wrote:
> Antoine Beaupré wrote

[...]


 aptitude search '?narrow(?installed, ?not(?origin(Debian)))'
>>>
>>> This one (apparently an improvement on the '~i(!~ODebian)' search that
>>> was recommended for buster, though the logic is too subtle for me to
>>> remember) is looking for a slightly different thing at a different
>>> stage in the upgrade process: it's part of the section about getting
>>> rid of "non-Debian packages" *before* the upgrade.  The '~o' and
>>> '!~ODebian' searches find different kinds of "unwanted" package.
>> 
>> Maybe it would be worth clarifying that distinction then?
>
> I don't know how we make texts more separate than printing them
> in two different places with explanatory paragraphs that talk
> about different things!  But let me have a look.
>
> # 4.2.2. Remove non-Debian packages
> #
> # Below there are two methods for finding installed packages that did
> # not come from Debian, using either aptitude or apt-forktracer.
> # Please note that neither of them are 100% accurate (e.g. the
> # aptitude example will list packages that were once provided by
> # Debian but no longer are, such as old kernel packages).
>
> Now that you come to mention it I've always thought that was a bad
> example, since after all it isn't exactly a false-positive - old
> linux-images really are no-longer-Debian packages, and if you've got
> some lying around even before the upgrade, this would be an
> appropriate time to get rid of them, as we go on to say a little
> later.  Wait, why *is* 4.2.2 before 4.2.3?  shouldn't it be
>  * sort out the package database (pending actions or whatever)
>  * make sure you're at the latest point release
>  * remove any non-Debian packages
>  * similarly but separately, remove any obsolete packages
>  * tidy any relic configs
>  [...]
> Maybe this is turning into the sort of disruptive low-priority change
> that should wait for next time.

Indeed. It does seem like 4.2.3 should be before 4.2.2.

I am not sure we should tell people to "remove any non-Debian package"
before the upgrade. They might have legitimate reasons to have
third-party package repositories...?

>> It might help if the former `~o` is expanded to `?obsolete` in the text,
>> to make it clearer how it compares with the latter.
>
> Unfortunately people also use "obsolete" to mean "autoremovable"!
> And this also makes the search less simple and easier to confuse with
> the one in 4.2...

I just meant to avoid using the shortcut, obscuring it won't help with
this sort of confusiong.

> [...]
 In my personal documentation, I've settled on `apt-forktracer`,
>>>
>>> I'd be interested to know what you find it useful for.
>> 
>> I like that it shows the related versions in the archive, and that it
>> has very terse output.
>
> Yes, but how do you come to be running a system with non-Debian
> repositories in your sources and installing packages to inspect the
> gory details without already realising you've done that?

You have forgotten, it's been years since you messed around with your
sources.list.

> Now that we've got "https://deb.debian.org/debian/;, we're close to
> being able to say that standard procedure is "for the duration of the
> upgrade, comment out any lines that don't match that URL".

I am not sure we want the release notes to standardize on that as
well... But I have considered writing a parser that checks sources.list
Origin headers and fixes things up correctly. Because my checklist is
getting ridiculous:

: Check for pinned, on hold, packages, and possibly disable &&
rm -f /etc/apt/preferences /etc/apt/preferences.d/* &&
rm -f /etc/apt/sources.list.d/backports.debian.org.list &&
rm -f /etc/apt/sources.list.d/backports.list &&
rm -f /etc/apt/sources.list.d/bullseye.list &&
rm -f /etc/apt/sources.list.d/buster-backports.list &&
rm -f /etc/apt/sources.list.d/experimental.list &&
rm -f /etc/apt/sources.list.d/incoming.list &&
rm -f /etc/apt/sources.list.d/proposed-updates.list &&
rm -f /etc/apt/sources.list.d/sid.list &&
rm -f /etc/apt/sources.list.d/testing.list &&
apt update && apt -y upgrade &&

>>>  [---suture---]
 I actually forgot that bullseye itself introduces yet another one:

 apt list ~obsolete
>>>
>>> And indeed for section 4.8, which is dealing with tidying up *after*
>>> the upgrade, it might make sense to recommend the use of apt instead
>>> of aptitude here.
>> 
>> Yeah, and then we get rid of aptitude in the docs in bullseye +1 :)
>
> Aptitude may no longer be recommended for dist-upgrades, but there are
> still reasons to prefer it for day-to-day admin on stable systems.

I'm not arguing for deprecating aptitude altogether, but it would seem
to me that using less tools in the release notes would be better.

> For bullseye-to-bookworm we'll probably want to use apt recipes
> wherever possible, with at most a mention that aptitude can also do
> this from the 

Bug#987265: stunnel4: Bug in patch file 04-restore-pidfile-default.patch

[Shane Frasier]

Package: stunnel4
Version: 3:5.50-3
Severity: important

Dear Maintainer,

When running AWS efs-utils( https://github.com/aws/efs-utils), which relies on
stunnel4, I see a lot of syslog messages of the form:
  stunnel: INTERNAL ERROR: Bad magic at options.c, line 1035

This message appears to be due to lines 28-29 of
debian/patches/04-restore-pidfile-default.patch:
-new_global_options.pidfile=NULL; /* do not create a pid file */
+new_global_options.pidfile=PIDFILE;

I think these lines should instead be:
-new_global_options.pidfile=NULL; /* do not create a pid file */
+new_global_options.pidfile=str_dup(PIDFILE)

This is because, when a SIGHUP signal is received, stunnel will attempt
to reload the configuration file.  In the process of doing that it will
call str_free() on the pidfile path string, as shown in the CMD_FREE
case clause of the same switch statement to which the above patch lines
apply.  (This case clause corresponds to lines 1051-1055 of the
unpatched file src/options.c.)

This bug seems like it could cause memory corruption issues, so I
labeled it as important.  Feel free to change the severity if this was
incorrect.

I didn't find this bug already reported in BTS, but I did find it
reported in Ubuntu's bug tracker:
https://bugs.launchpad.net/ubuntu/+source/stunnel4/+bug/1901784

I also verified that this bug is still in the testing and unstable
version of the stunnel4 package (3:5.56+dfsg-9).

Thank you,
Shane Frasier


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

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

Versions of packages stunnel4 depends on:
ii  adduser  3.118
ii  libc62.28-10
ii  libssl1.11.1.1d-0+deb10u6
ii  libsystemd0  241-7~deb10u7
ii  libwrap0 7.6.q-28
ii  lsb-base 10.2019051400
ii  netbase  5.6
ii  openssl  1.1.1d-0+deb10u6
ii  perl 5.28.1-6+deb10u1

stunnel4 recommends no packages.

Versions of packages stunnel4 suggests:
pn  logcheck-database  

-- no debconf information

Bug#987264: git-el: fails to install with xemacs21

[Andreas Beckmann]

Package: git-el
Version: 1:2.30.2-1
Severity: serious
User: debian...@lists.debian.org
Usertags: piuparts

Hi,

during a test with piuparts I noticed your package failed to install if
xemacs21 is already installed.

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

  Setting up git-el (1:2.31.0+next.20210315-1) ...
  Install git for emacs
  install/git: Handling install of emacsen flavor emacs
  mkdir: cannot create directory '/usr/share/emacs/site-lisp/git': No such file 
or directory
  /usr/lib/emacsen-common/packages/install/git emacs xemacs21 failed at 
/usr/lib/emacsen-common/lib.pl line 19,  line 1.
  dpkg: error processing package git-el (--configure):
   installed git-el package post-installation script subprocess returned error 
exit status 2
  Processing triggers for libc-bin (2.31-11) ...
  Errors were encountered while processing:
   git-el


cheers,

Andreas


git-el=1:2.30.2-1_xemacs21.log.gz
Description: application/gzip

Bug#987263: ITP: node-jmespath -- javascript implementation of JMESPath

[Nilesh Patra]

Package: wnpp
Severity: wishlist
Owner: Nilesh Patra 
X-Debbugs-Cc: debian-de...@lists.debian.org, nil...@debian.org

* Package name: node-jmespath
  Version : 0.15.0+dfsg
  Upstream Author : James Saryerwinnie
* URL : https://github.com/jmespath/jmespath.js
* License : Apache-2.0
  Programming Lang: Javascript
  Description : javascript implementation of JMESPath

 Jmespath.js is a javascript implementation of JMESPath, which is a query
 language for JSON. It will take a JSON document and transform it into
 another JSON document through a JMESPath expression.

 I shall maintain this package

Bug#979531: lodash/fp does not have all the files shipped by npm dist.tarball

[Pirate Praveen]

On Fri, 08 Jan 2021 16:04:05 +0530 Pirate Praveen 
 wrote:

> Control: forwarded -1 https://github.com/lodash/lodash/issues/5051
>
> Even upstream build is broken.
>
> yarnpkg build:fp-modules is also generating only 104 files.

Thanks to 
https://salsa.debian.org/js-team/node-lodash/-/merge_requests/1 from 
Akshay, we can now build it correctly.

Bug#987261: libopenmpi3: Severe memory leak in MPI_Allreduce when using a repeatedly created and freed MPI_Datatype

[Matthias Maier]

Package: libopenmpi3
Version: 4.1.0-7
Severity: important
Tags: patch upstream
X-Debbugs-Cc: tamiko+deb...@kyomu.43-1.org

Dear Maintainer,

Please consider applying the following upstream patch [1] for a memory leak
issue in OpenMPI-4.1.0.  In short, the memory allocator for MPI_Datatype in
the UCX PML does not correctly free allocated resources. Under certain
workloads this lead to a severe memory leak that renders the OpenMPI
library unusable. Upstream bug report [2].

I am reporting this issue for 4.1.0-7 but the issue is also present in 4.1.0-8.

[1] https://github.com/open-mpi/ompi/pull/8828
( review currently in progress )
[2] https://github.com/open-mpi/ompi/issues/8827


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

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

Versions of packages libopenmpi3 depends on:
ii  libc62.31-11
ii  libevent-core-2.1-7  2.1.12-stable-1
ii  libevent-pthreads-2.1-7  2.1.12-stable-1
ii  libfabric1   1.11.0-2
ii  libgcc-s110.2.1-6
ii  libhwloc-plugins 2.4.1+dfsg-1
ii  libhwloc15   2.4.1+dfsg-1
ii  libibverbs1  33.1-1
ii  libnl-3-200  3.4.0-1+b1
ii  libpmix2 4.0.0-4
ii  libpsm-infinipath1   3.3+20.604758e7-6.1
ii  libpsm2-211.2.185-1
ii  libstdc++6   10.2.1-6
ii  libucx0  1.10.0~rc1-7
ii  zlib1g   1:1.2.11.dfsg-2

libopenmpi3 recommends no packages.

libopenmpi3 suggests no packages.

-- no debconf information

Bug#987226: youtube-dl: ERROR: Unable to extract yt initial data

[Holger Levsen]

control: severity -1 important
thanks

hi Mike,

On Mon, Apr 19, 2021 at 09:39:55PM +, Mike Gabriel wrote:
> Package: youtube-dl
> Severity: grave

you didn't really describe why you thought the severity should be grave,
but anyway:

$ youtube-dl https://twitter.com/zemodancingto/status/1381937205787172867#m
[twitter] 1381937205787172867: Downloading guest token
[twitter] 1381937205787172867: Downloading JSON metadata
[twitter] 1381937205787172867: Downloading m3u8 information
[download] Destination: zemo dancing to - Rick Astley - Never Gonna Give You 
Up-1381937205787172867.mp4
[download] 100% of 3.00MiB in 00:01
$

so this clearly shows the package isn't broken for everyone.


-- 
cheers,
Holger

 ⢀⣴⠾⠻⢶⣦⠀
 ⣾⠁⢠⠒⠀⣿⡁  holger@(debian|reproducible-builds|layer-acht).org
 ⢿⡄⠘⠷⠚⠋⠀  OpenPGP: B8BF54137B09D35CF026FE9D 091AB856069AAA1C
 ⠈⠳⣄

In Germany we don‘t say „Happy Valentine‘s Day, I love you“, we say „ich werde
diesen vom Markt kreierten, konsumorientierten Trend des Kapitalismus nicht
unterstützen,“ and I think that’s beautiful. (Hazel Brugger)


signature.asc
Description: PGP signature

Bug#987260: lyskom-elisp-client: fails to install with xemacs21

[Andreas Beckmann]

Package: lyskom-elisp-client
Version: 0.48+git.20200923.ec349ff4-1
Severity: serious
User: debian...@lists.debian.org
Usertags: piuparts

Hi,

during a test with piuparts I noticed your package failed to install if
xemacs21 is already installed.

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

  Preparing to unpack 
.../lyskom-elisp-client_0.48+git.20200923.ec349ff4-1_all.deb ...
  Unpacking lyskom-elisp-client (0.48+git.20200923.ec349ff4-1) ...
  Setting up lyskom-elisp-client (0.48+git.20200923.ec349ff4-1) ...
  Install lyskom-elisp-client for emacs
  install/lyskom-elisp-client: Handling install of emacsen flavor emacs
  Install lyskom-elisp-client for xemacs21
  install/lyskom-elisp-client: Handling install of emacsen flavor xemacs21
  install/lyskom-elisp-client: byte-compiling for xemacs21
  Please wait...
  Compiling /usr/share/xemacs21/site-lisp/lyskom-elisp-client.el...
  Ignoring `eval:' in file's local variables
  While compiling lyskom-help-format-keymap in file 
/usr/share/xemacs21/site-lisp/lyskom-elisp-client.el:
** variable this-command-keys bound but not referenced
  While compiling toplevel forms:
!! Invalid read syntax (("#"))
  >>Error occurred processing lyskom-elisp-client.el: 
  Invalid read syntax: "#"
  
  
  Done
  ERROR: install script from lyskom-elisp-client package failed
  dpkg: error processing package lyskom-elisp-client (--configure):
   installed lyskom-elisp-client package post-installation script subprocess 
returned error exit status 1
  Errors were encountered while processing:
   lyskom-elisp-client


cheers,

Andreas


lyskom-elisp-client=0.48+git.20200923.ec349ff4-1_xemacs21.log.gz
Description: application/gzip

Bug#969410: maxima-emacs: maxima-emacs 5.44 does not work with XEmacs

[Andreas Beckmann]

Followup-For: Bug #969410
Control: severity -1 serious

Hi,

during a test with piuparts I noticed your package failed to install if
xemacs21 is already installed.

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

  Setting up maxima-emacs (5.44.0-2) ...
  Install emacsen-common for xemacs21
  emacsen-common: Handling install of emacsen flavor xemacs21
  Loading /usr/share/emacsen-common/debian-startup...
  Loading 00debian...
  Compiling /usr/share/xemacs21/site-lisp/debian-startup.el...
  Wrote /usr/share/xemacs21/site-lisp/debian-startup.elc
  Done
  Install maxima-emacs for xemacs21
  install/maxima: Handling install for emacsen flavor xemacs21
  Compiling /usr/share/xemacs21/site-lisp/maxima/bookmode.el...
  Wrote /usr/share/xemacs21/site-lisp/maxima/bookmode.elc
  Compiling /usr/share/xemacs21/site-lisp/maxima/emaxima.el...
  Wrote /usr/share/xemacs21/site-lisp/maxima/emaxima.elc
  Compiling /usr/share/xemacs21/site-lisp/maxima/imath.el...
  While compiling toplevel forms in file 
/usr/share/xemacs21/site-lisp/maxima/imath.el:
!! File error (("Cannot open load file" "cl-lib"))
  >>Error occurred processing imath.el: Cannot open load file: cl-lib
  
  Compiling 
/usr/share/xemacs21/site-lisp/maxima/imaxima-autoconf-variables.el...
  Wrote /usr/share/xemacs21/site-lisp/maxima/imaxima-autoconf-variables.elc
  Compiling /usr/share/xemacs21/site-lisp/maxima/imaxima.el...
  While compiling toplevel forms in file 
/usr/share/xemacs21/site-lisp/maxima/imaxima.el:
!! File error (("Cannot open load file" "cl-lib"))
  >>Error occurred processing imaxima.el: Cannot open load file: cl-lib
  
  Compiling /usr/share/xemacs21/site-lisp/maxima/maxima-font-lock.el...
  Wrote /usr/share/xemacs21/site-lisp/maxima/maxima-font-lock.elc
  Compiling /usr/share/xemacs21/site-lisp/maxima/maxima.el...
  Wrote /usr/share/xemacs21/site-lisp/maxima/maxima.elc
  Compiling /usr/share/xemacs21/site-lisp/maxima/setup-imaxima-imath.el...
  Wrote /usr/share/xemacs21/site-lisp/maxima/setup-imaxima-imath.elc
  Compiling /usr/share/xemacs21/site-lisp/maxima/smart-complete.el...
  Wrote /usr/share/xemacs21/site-lisp/maxima/smart-complete.elc
  Compiling /usr/share/xemacs21/site-lisp/maxima/sshell.el...
  Wrote /usr/share/xemacs21/site-lisp/maxima/sshell.elc
  Done
  ERROR: install script from maxima-emacs package failed
  dpkg: error processing package maxima-emacs (--configure):
   installed maxima-emacs package post-installation script subprocess returned 
error exit status 1
  Processing triggers for libc-bin (2.31-11) ...
  Processing triggers for tex-common (6.16) ...
  Running updmap-sys. This may take some time... done.
  Running mktexlsr /var/lib/texmf ... done.
  Building format(s) --all.
This may take some time... done.
  Errors were encountered while processing:
   maxima-emacs


cheers,

Andreas


maxima-emacs=5.44.0-2_xemacs21.log.gz
Description: application/gzip

Bug#987259: utop: fails to install with xemacs21

[Andreas Beckmann]

Package: utop
Version: 2.7.0-1
Severity: serious
User: debian...@lists.debian.org
Usertags: piuparts

Hi,

during a test with piuparts I noticed your package failed to install if
xemacs21 is already installed.

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

  Setting up utop (2.7.0-1) ...
  Install emacsen-common for xemacs21
  emacsen-common: Handling install of emacsen flavor xemacs21
  Loading /usr/share/emacsen-common/debian-startup...
  Loading 00debian...
  Compiling /usr/share/xemacs21/site-lisp/debian-startup.el...
  Wrote /usr/share/xemacs21/site-lisp/debian-startup.elc
  Done
  Install utop for xemacs21
  install/utop: Handling install for emacsen flavor xemacs21
  Loading /usr/share/emacsen-common/debian-startup...
  Loading 00debian...
  Compiling /usr/share/emacs/site-lisp/utop.el...
  While compiling toplevel forms in file /usr/share/emacs/site-lisp/utop.el:
!! File error (("Cannot open load file" "pcase"))
  >>Error occurred processing /usr/share/emacs/site-lisp/utop.el: Cannot open 
load file: pcase
  
  Done
  ERROR: install script from utop package failed
  dpkg: error processing package utop (--configure):
   installed utop package post-installation script subprocess returned error 
exit status 1
  Processing triggers for libc-bin (2.31-11) ...
  Errors were encountered while processing:
   utop


cheers,

Andreas


utop=2.7.0-1_xemacs21.log.gz
Description: application/gzip

Bug#987258: epix: fails to install with xemacs21

[Andreas Beckmann]

Package: epix
Version: 1.2.19-1
Severity: serious
User: debian...@lists.debian.org
Usertags: piuparts

Hi,

during a test with piuparts I noticed your package failed to install if
xemacs21 is already installed.

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

  Setting up epix (1.2.19-1) ...
  Install emacsen-common for xemacs21
  emacsen-common: Handling install of emacsen flavor xemacs21
  Loading /usr/share/emacsen-common/debian-startup...
  Loading 00debian...
  Compiling /usr/share/xemacs21/site-lisp/debian-startup.el...
  Wrote /usr/share/xemacs21/site-lisp/debian-startup.elc
  Done
  Install epix for xemacs21
  install/epix: Handling install for emacsen flavor xemacs21
  cp: cannot stat '*.el': No such file or directory
  ERROR: install script from epix package failed
  dpkg: error processing package epix (--configure):
   installed epix package post-installation script subprocess returned error 
exit status 1
  Setting up imagemagick (8:6.9.11.60+dfsg-1) ...
  Processing triggers for libc-bin (2.31-11) ...
  Processing triggers for tex-common (6.16) ...
  Running updmap-sys. This may take some time... done.
  Running mktexlsr /var/lib/texmf ... done.
  Building format(s) --all.
This may take some time... done.
  Errors were encountered while processing:
   epix


cheers,

Andreas


epix=1.2.19-1_xemacs21.log.gz
Description: application/gzip

Bug#987225: debian-edu-config: openQA 'standalone' install test failing

[Philip Hands]

Wolfgang Schweer  writes:

> Hi Phil,
>
> [ Philip Hands, 2021-04-19 ]
>> I've re-run the job with DEBCONF_DEBUG=5 set, which gives one a more verbose
>> logging, and you can find the resulting syslog here:
>> 
>>   https://openqa.debian.net/tests/1220/file/grub-syslog
>  
> The broken install might be due to a space problem, see these lines from 
> grub-syslog::
>
> Apr 19 20:25:53 in-target: Processing triggers for initramfs-tools (0.140) 
> ...^M
> Apr 19 20:25:53 in-target: update-initramfs: Generating 
> /boot/initrd.img-5.10.0-6-amd64^M
> Apr 19 20:26:05 in-target: cpio: write error
> Apr 19 20:26:05 in-target: : No space left on device^M
> Apr 19 20:26:05 in-target: E: mkinitramfs failure cpio 2^M
> Apr 19 20:26:05 in-target: update-initramfs: failed for 
> /boot/initrd.img-5.10.0-6-amd64 with 1.^M
> Apr 19 20:26:05 in-target: dpkg: error processing package initramfs-tools 
> (--configure):^M
> Apr 19 20:26:05 in-target:  installed initramfs-tools package 
> post-installation script subprocess returned error exit status 1^M
>
> Wolfgang

Yes, sorry for not noticing that sooner.

It seems that 40GB is no longer enough. I'm just making sure that the
test looks in syslog for that message, and highlights it, so it'll be
much more obvious next time this comes up.

Cheers, Phil.
-- 
|)|  Philip Hands  [+44 (0)20 8530 9560]  HANDS.COM Ltd.
|-|  http://www.hands.com/http://ftp.uk.debian.org/
|(|  Hugo-Klemm-Strasse 34,   21075 Hamburg,GERMANY

Bug#950790: libqt5qml5: Do a double build with SSE2 enabled on i386

[Jiri Palecek]

Hello,

On Thu, 6 Feb 2020 17:43:53 +0300 Dmitry Shachnev wrote:

> On Thu, Feb 06, 2020 at 11:08:41AM -0300, Lisandro Damián Nicanor
Pérez Meyer wrote:
> > Lars pointed out [1] that QtQml (and so I guess this lib, will need
to double
> > check) would really benefit from a i386 build with SSE2 enabled.
> >
> > [1]
>
> Already discussed on IRC, but for the record:
>
> Actually Qt QML has a runtime requirement for SSE2, so I am not sure the
> non-SSE2 build makes sense:
>
>
https://sources.debian.org/src/qtdeclarative-opensource-src/5.12.5-5/src/qml/qml/v8/qv8engine.cpp/#L143
>
> I think we should just switch the default build to SSE2 by passing
> CONFIG+=sse2 to qmake when DEB_HOST_ARCH_CPU = i386.


I doubt it. First, the line you reference (and any other reference to
SSE2) is missing from the current sources, second, it is alleged qml
should work without sse2 just with interpreted bytecode.

However, I tried the dual build and it is actually hard to compile it
with sse2 enabled:

CONFIG+=sse2

QMAKE_CxxxFLAGS+=-msse2

etc. all don't work. Either it does nothing, or it fails to enable the
jit in build. It seems this feature is hard coded in the file

/usr/lib/i386-linux-gnu/qt5/mkspecs/qmodule.pri

By editing that file I found out I needed to change
QT.global_private.enabled_features to make it work. Which is super ugly.

You can see the result here:
https://salsa.debian.org/jpalecek-guest/qtdeclarative

I still need to test the resulting binaries.

Regards

    Jiri Palecek

Bug#987256: unblock: nvidia-graphics-drivers-legacy-390xx/390.143-1

[Luca Boccassi]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
X-Debbugs-Cc: pkg-nvidia-de...@lists.alioth.debian.org

Please unblock package nvidia-graphics-drivers-legacy-390xx

The new upstream LTS version 390.143 fixes a CVE and a crash in X.org,
both of which affect Bullseye.

X.org crash under certain conditions, and a security vulnerability
(CVE-2021-1076 and #987218) has been found in the kernel driver:
https://nvidia.custhelp.com/app/answers/detail/a_id/5172

The inlined debdiff excludes the binary blobs.

unblock nvidia-graphics-drivers-legacy-390xx/390.143-1

-- 
Kind regards,
Luca Boccassi

diff -Nru --exclude 'NVIDIA*.run' 
nvidia-graphics-drivers-legacy-390xx-390.141/debian/changelog 
nvidia-graphics-drivers-legacy-390xx-390.143/debian/changelog
--- nvidia-graphics-drivers-legacy-390xx-390.141/debian/changelog   
2021-03-13 21:39:29.0 +
+++ nvidia-graphics-drivers-legacy-390xx-390.143/debian/changelog   
2021-04-20 01:04:19.0 +0100
@@ -1,3 +1,16 @@
+nvidia-graphics-drivers-legacy-390xx (390.143-1) unstable; urgency=medium
+
+  * New upstream legacy branch release 390.143 (2021-04-19).
+* Fixed CVE-2021-1076.  (Closes: #987218)
+  https://nvidia.custhelp.com/app/answers/detail/a_id/5172
+- Fixed a bug where vkCreateSwapchain could cause the X Server to crash
+  when an invalid imageFormat was provided.
+- Fixed a driver installation failure on Linux kernel 5.11 release
+  candidates, where the NVIDIA kernel module failed to build with error
+  "fatal error: asm/kmap_types.h: No such file or directory".
+
+ -- Andreas Beckmann   Tue, 20 Apr 2021 02:04:19 +0200
+
 nvidia-graphics-drivers-legacy-390xx (390.141-3) unstable; urgency=medium
 
   * nvidia-legacy-390xx-alternative: Add libnvidia-ml.so slave alternative if
diff -Nru --exclude 'NVIDIA*.run' 
nvidia-graphics-drivers-legacy-390xx-390.141/debian/control.md5sum 
nvidia-graphics-drivers-legacy-390xx-390.143/debian/control.md5sum
--- nvidia-graphics-drivers-legacy-390xx-390.141/debian/control.md5sum  
2021-03-13 21:39:29.0 +
+++ nvidia-graphics-drivers-legacy-390xx-390.143/debian/control.md5sum  
2021-04-20 01:04:19.0 +0100
@@ -1,5 +1,5 @@
 a1db8e174e35b30f771fffdf4690ea8b  debian/control
 0a204645020c143be44b04bd5daf7b85  debian/control.in
 db12f898b07cdaf431ad34bd68a1662e  debian/gen-control.pl
-365281fc24d824d688be59ab97ae1ca5  debian/rules
+e0a6daa55d2509f44d21bbb591ccbad1  debian/rules
 181fae6bc60df1e667ef475560be4fdf  debian/rules.defs
diff -Nru --exclude 'NVIDIA*.run' 
nvidia-graphics-drivers-legacy-390xx-390.141/debian/rules 
nvidia-graphics-drivers-legacy-390xx-390.143/debian/rules
--- nvidia-graphics-drivers-legacy-390xx-390.141/debian/rules   2021-03-13 
21:39:29.0 +
+++ nvidia-graphics-drivers-legacy-390xx-390.143/debian/rules   2021-04-20 
01:04:19.0 +0100
@@ -138,9 +138,9 @@
cat $^ | sort -u > $@
 
 nv-readme.ids: unpack-stamp debian/nv-readme.ids
-   sed -e '0,/A. Supported\|APPENDIX A: SUPPORTED/d' \
-   -e '0,/Appendix A. Supported\|APPENDIX A: SUPPORTED/d' \
-   -e '0,/^Below\|APPENDIX B/{/ 0x/s/.*  
0x\([0-9a-fA-F]\{4\}\).*/10de\1/p; /^.\{41\} [0-9a-fA-F]\{4\} /s/^.\{41\} 
\([0-9a-fA-F]\{4\}\) .*/10de\1/p};d' \
+   sed -r  -e '0,/A. Supported|APPENDIX A: SUPPORTED/d' \
+   -e '0,/Appendix A. Supported|APPENDIX A: SUPPORTED/d' \
+   -e '0,/^Below|APPENDIX B/{/ 0x/s/.*  
0x([0-9a-fA-F]{4}).*/10de\1/p; /^(.{41}|.{49}) [0-9a-fA-F]{4} /s/^(.{41}|.{49}) 
([0-9a-fA-F]{4}) .*/10de\2/p};d' \
NVIDIA-Linux/README.txt \
| tr a-f A-F | sort -u > $@
@set -e -x ; \


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

Bug#987257: libcw{7,-dev}: removal of libcw{7,-dev} makes files disappear from libcw6{,-dev}

[Andreas Beckmann]

Package: libcw-dev,libcw7
Version: 3.6.0-1
Severity: serious
User: debian...@lists.debian.org
Usertags: piuparts replaces-without-breaks

Hi,

during a test with piuparts and DOSE tools I noticed your package causes
removal of files that also belong to another package.
This is caused by using Replaces without corresponding Breaks.

The installation sequence to reproduce this problem is

  apt-get install libcw6-dev
  # (1)
  apt-get install libcw-dev
  apt-get remove libcw-dev
  # (2)

The list of installed files at points (1) and (2) should be identical,
but the following files have disappeared:

  /usr/include/libcw.h
  /usr/include/libcw_debug.h
  /usr/lib/x86_64-linux-gnu/libcw.a
  /usr/lib/x86_64-linux-gnu/libcw.so
  /usr/lib/x86_64-linux-gnu/pkgconfig/libcw.pc
  /usr/share/man/man3/libcw.3.gz

  /usr/share/man/man7/cw.7.gz

This is a serious bug violating policy 7.6, see
https://www.debian.org/doc/debian-policy/ch-relationships.html#overwriting-files-and-replacing-packages-replaces
and also see the footnote that describes this incorrect behavior:
https://www.debian.org/doc/debian-policy/ch-relationships.html#id13

The libcw-dev package has the following relationships with libcw6-dev:

  Conflicts: n/a
  Replaces:  libcw3-dev, libcw4-dev, libcw5-dev, libcw6-dev, unixcw-dev
  Breaks:libcw3-dev, unixcw-dev

The libcw7 package has the following relationships with libcw6:

  Conflicts: n/a
  Replaces:  libcw3, libcw4, libcw5, libcw6, unixcw
  Breaks:libcw3, unixcw

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

0m25.1s ERROR: FAIL: After purging files have disappeared:
  /usr/include/libcw.h   owned by: libcw-dev
  /usr/include/libcw_debug.h owned by: libcw-dev
  /usr/lib/x86_64-linux-gnu/libcw.a  owned by: libcw-dev
  /usr/lib/x86_64-linux-gnu/libcw.so -> libcw.so.6.6.1   owned by: libcw-dev
  /usr/lib/x86_64-linux-gnu/pkgconfig/libcw.pc   owned by: libcw-dev
  /usr/share/man/man3/libcw.3.gz owned by: libcw-dev
  /usr/share/man/man7/cw.7.gzowned by: libcw7:amd64

0m25.1s ERROR: FAIL: After purging files have been modified:
  /var/lib/dpkg/info/libcw6-dev.list not owned
  /var/lib/dpkg/info/libcw6:amd64.list   not owned


cheers,

Andreas


libcw6-dev=3.5.1-4_libcw-dev=3.6.0-1.log.gz
Description: application/gzip

Bug#987166: Description truncated

[Ritesh Raj Sarraf]

Control: tag -1 +pending

On Mon, 2021-04-19 at 23:13 +0200, Chris Hofstaedtler wrote:
> * Ritesh Raj Sarraf  [210419 21:12]:
> > > The package description appears truncated after "between".
> > 
> > If you have suggestions on how to extend it further, please do so.
> > My
> > english showed limitations in finding words to describe it.
> 
> I guess appending "them." would at least finish the sentence?

Thanks Chris. That does improve the description.

-- 
Ritesh Raj Sarraf | http://people.debian.org/~rrs
Debian - The Universal Operating System


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

Bug#986742: unblock: ruby2.7/2.7.3-1

[Antonio Terceiro]

On Sun, Apr 18, 2021 at 09:43:41PM +0200, Sebastian Ramacher wrote:
> On 2021-04-17 22:10:19 +0530, Utkarsh Gupta wrote:
> > Hi Sebastian,
> > 
> > On Sat, Apr 17, 2021 at 3:08 PM Sebastian Ramacher  
> > wrote:
> > > Thanks, please go ahead and remove the moreinfo tag once the version is
> > > available in unstable.
> > 
> > Uploaded to unstable, thanks. And removed the tag as well.
> 
> The builds on armel and armhf failed:
> https://buildd.debian.org/status/fetch.php?pkg=ruby2.7=armel=2.7.3-1=1618744303=0

I just uploaded -2 with the following fix:

8<8<8<- 
From: Antonio Terceiro 
Date: Mon, 19 Apr 2021 17:50:12 +
Subject: Revert "Make host_* values consistent with target_*"

See https://bugs.ruby-lang.org/issues/17021 for the original request.

This breaks the build on the 32-bit Debian ARM architectures. Maybe this
is specific to the Debian packaging, so this has not been reported
upstream yet.
---
 configure.ac | 7 +--
 1 file changed, 1 insertion(+), 6 deletions(-)

diff --git a/configure.ac b/configure.ac
index da22ab6..73ce534 100644
--- a/configure.ac
+++ b/configure.ac
@@ -309,14 +309,9 @@ AC_SUBST(CC_VERSION_MESSAGE, $cc_version_message)
 : ${DLDFLAGS="$LDFLAGS"}
 
 RUBY_UNIVERSAL_ARCH
-AS_IF([test "$target_cpu" != "$host_cpu" -a "$GCC" = yes -a "$cross_compiling" 
= no -a "${universal_binary:-no}" = no], [
+AS_IF([test "$target_cpu" != "$host_cpu" -a "$GCC" = yes -a "$cross_compiling" 
= no -a "$universal_binary" = no], [
 RUBY_DEFAULT_ARCH("$target_cpu")
 ])
-host_os=$target_os
-host_vendor=$target_vendor
-host_cpu=$target_cpu
-host=$target
-host_alias=$target_alias
 
 AS_CASE(["$target_os"], [darwin*], [
 if libtool 2>&1 | grep no_warning_for_no_symbols > /dev/null; then
8<8<8<- 


signature.asc
Description: PGP signature

Bug#987244: RFS: nbsdgames/4.0-1 [ITP] -- text based mini games for your terminal

[Gürkan Myczko]

Hi Adam,


Fails to build:
cp jewels sudoku mines reversi checkers battleship rabbithole sos
pipes fifteen memoblocks fisher muncher miketron redsquare darrt
snakeduel /usr/games
cp: cannot create regular file '/usr/games/jewels': Permission denied
cp: cannot create regular file '/usr/games/sudoku': Permission denied
cp: cannot create regular file '/usr/games/mines': Permission denied
cp: cannot create regular file '/usr/games/reversi': Permission denied
cp: cannot create regular file '/usr/games/checkers': Permission denied
cp: cannot create regular file '/usr/games/battleship': Permission 
denied
cp: cannot create regular file '/usr/games/rabbithole': Permission 
denied

cp: cannot create regular file '/usr/games/sos': Permission denied
cp: cannot create regular file '/usr/games/pipes': Permission denied
cp: cannot create regular file '/usr/games/fifteen': Permission denied
cp: cannot create regular file '/usr/games/memoblocks': Permission 
denied

cp: cannot create regular file '/usr/games/fisher': Permission denied
cp: cannot create regular file '/usr/games/muncher': Permission denied
cp: cannot create regular file '/usr/games/miketron': Permission denied
cp: cannot create regular file '/usr/games/redsquare': Permission 
denied

cp: cannot create regular file '/usr/games/darrt': Permission denied
cp: cannot create regular file '/usr/games/snakeduel': Permission 
denied


Oversaw that, fixed.


Also, in-$PATH names "sudoku" and "sos" are already taken, by packages
sudoku and sosreport respectively.


Now Conflicts: sudoku, and sos is not in /usr/games, so it's up to the 
user

to pick the right one using the full path.

(upload is done to m.d.n, takes a while to appear though)
Thanks,

Bug#987252: kolourpaint: does not have a manpage

[Norbert Preining]

Hi

> Bullseye's version but also in stable and old-stable). I thought this was
> mandatory in Debian.

It is recommended, but not mandatory.

The man page would be trivial, something like the output of -h, so
probably not worth the pain.

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#987253: kolourpaint: Missing most of the icons in left panel

[Norbert Preining]

Hi

On Tue, 20 Apr 2021, Yvan Masson wrote:
> In the left panel of KolourPaint, tools like line, square, circle… are by
> default normally shown by their icon. However most of the icons seems to be
> missing because only the text of the button is shown (see screenshot
> attached).

I do see the icons, so that means you might have selected a special set
of icons in the settings application that does not provide all icons.

Try breeze icon, it should show up.

Also, there is an option in the settings application under Appearance,
Application Style, Configure Icons and Toolsbars
that let you hide icons and only show text. Worth checking out.

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#987244: RFS: nbsdgames/4.0-1 [ITP] -- text based mini games for your terminal

[Adam Borowski]

On Tue, Apr 20, 2021 at 01:19:13PM +0200, Gürkan Myczko wrote:
>  * Package name: nbsdgames

> https://mentors.debian.net/debian/pool/main/n/nbsdgames/nbsdgames_4.0-1.dsc
> 
>  nbsdgames (4.0-1) unstable; urgency=medium
>  .
>* Initial release. (Closes: #964876)

Fails to build:
cp jewels sudoku mines reversi checkers battleship rabbithole sos pipes fifteen 
memoblocks fisher muncher miketron redsquare darrt snakeduel /usr/games
cp: cannot create regular file '/usr/games/jewels': Permission denied
cp: cannot create regular file '/usr/games/sudoku': Permission denied
cp: cannot create regular file '/usr/games/mines': Permission denied
cp: cannot create regular file '/usr/games/reversi': Permission denied
cp: cannot create regular file '/usr/games/checkers': Permission denied
cp: cannot create regular file '/usr/games/battleship': Permission denied
cp: cannot create regular file '/usr/games/rabbithole': Permission denied
cp: cannot create regular file '/usr/games/sos': Permission denied
cp: cannot create regular file '/usr/games/pipes': Permission denied
cp: cannot create regular file '/usr/games/fifteen': Permission denied
cp: cannot create regular file '/usr/games/memoblocks': Permission denied
cp: cannot create regular file '/usr/games/fisher': Permission denied
cp: cannot create regular file '/usr/games/muncher': Permission denied
cp: cannot create regular file '/usr/games/miketron': Permission denied
cp: cannot create regular file '/usr/games/redsquare': Permission denied
cp: cannot create regular file '/usr/games/darrt': Permission denied
cp: cannot create regular file '/usr/games/snakeduel': Permission denied

Also, in-$PATH names "sudoku" and "sos" are already taken, by packages
sudoku and sosreport respectively.


Meow!
-- 
⢀⣴⠾⠻⢶⣦⠀ You should never, ever, degrade a human being by saying they're
⣾⠁⢠⠒⠀⣿⡁ a worthless waste of food and air.
⢿⡄⠘⠷⠚⠋⠀
⠈⠳⣄ You should also never anthropomorphize spammers and telemarketers.

Bug#987084: Acknowledgement (unblock: wordpress/5.7.1+dfsg1-1)

[Craig Small]

Hi,
  I have just got a bug report for WordPress about a messed up symlink in
one of the theme packages #986085. As a result, I'd like to change this
unblock from 5.7.1+dfsg1-1 to 5.7.1+dfsg1-2
The singular change between these two is fixing the symlink for
wordpress-theme-twentytwentyone

 - Craig


On Sat, 17 Apr 2021 at 21:15, Debian Bug Tracking System <
ow...@bugs.debian.org> wrote:

> Thank you for filing a new Bug report with Debian.
>
> You can follow progress on this Bug here: 987084:
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=987084.
>
> 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.
>
> Your message has been sent to the package maintainer(s):
>  Debian Release Team 
>
> If you wish to submit further information on this problem, please
> send it to 987...@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.
>
> --
> 987084: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=987084
> Debian Bug Tracking System
> Contact ow...@bugs.debian.org with problems
>

Bug#987253: kolourpaint: Missing most of the icons in left panel

[Yvan Masson]

Package: kolourpaint
Version: 4:20.12.0-1
Severity: normal

Dear Maintainer,

In the left panel of KolourPaint, tools like line, square, circle… 
are 
by default normally shown by their icon. However most of the icons seems 
to be missing because only the text of the button is shown (see 
screenshot attached).


Regards,
Yvan

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

Kernel: Linux 5.10.0-6-amd64 (SMP w/4 CPU threads)
Kernel taint flags: TAINT_WARN
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 kolourpaint depends on:
ii  kio5.78.0-4
ii  libc6  2.31-11
ii  libkf5configcore5  5.78.0-4
ii  libkf5configgui5   5.78.0-4
ii  libkf5configwidgets5   5.78.0-2
ii  libkf5coreaddons5  5.78.0-4
ii  libkf5guiaddons5   5.78.0-3
ii  libkf5i18n55.78.0-2
ii  libkf5jobwidgets5  5.78.0-2
ii  libkf5kiocore5 5.78.0-4
ii  libkf5kiofilewidgets5  5.78.0-4
ii  libkf5sane520.12.0-1
ii  libkf5service-bin  5.78.0-2
ii  libkf5service5 5.78.0-2
ii  libkf5textwidgets5 5.78.0-2
ii  libkf5widgetsaddons5   5.78.0-2
ii  libkf5xmlgui5  5.78.0-2
ii  libqt5core5a   5.15.2+dfsg-5
ii  libqt5gui5 5.15.2+dfsg-5
ii  libqt5printsupport55.15.2+dfsg-5
ii  libqt5widgets5 5.15.2+dfsg-5
ii  libstdc++6 10.2.1-6

kolourpaint recommends no packages.

kolourpaint suggests no packages.

-- no debconf information



OpenPGP_signature
Description: OpenPGP digital signature

Bug#987252: kolourpaint: does not have a manpage

[Yvan Masson]

Package: kolourpaint
Version: 4:20.12.0-1
Severity: normal

Dear maintainers,

If I am not wrong, KolourPaint does not have a manpage, not only in 
Bullseye's version but also in stable and old-stable). I thought this 
was mandatory in Debian.


Anyway, `kolourpaint -h` shows a help message as expected.

Regards,
Yvan



OpenPGP_signature
Description: OpenPGP digital signature

Bug#987251: unblock: rdma-core/33.1+git20210317-1

[Benjamin Drung]

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

Please unblock package rdma-core

we (1&1 IONOS SE) are hit by the race in rdma-ndd that is already fixed
in the latest rdma-core release. The rdma-core projects follows a
similar release process than the linux kernel developers. The point
releases only contain backported fixes. I had a look at those commits
and we probably want those fixes as well.

[ Reason ]
This release contains the rdma-ndd race fix.

[ Impact ]
For system with multiple InfiniBand HCAs, only the first HCA is
guaranteed to be detected by kernel and the node description for the
other ports are often not set due to the race.

[ Tests ]
The upstream project has test cases, but our package does not run the
tests, because they rely on having InfiniBand hardware.

[ Risks ]
The package is not a leaf package, but only needed for users with RDMA
hardware. Since we have a good upstream relationship, the code from
upstream is unchanged. In case of a regression, upstream will be
affected as well (with their latest 34.0 release and their upcoming 33.2
point release).

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

unblock rdma-core/33.1+git20210317-1

-- 
Benjamin Drung

Senior DevOps Engineer and Debian & Ubuntu Developer
Compute Platform Operations

1&1 IONOS SE | Greifswalder Str. 207 | 10405 Berlin | Deutschland
E-Mail: benjamin.dr...@ionos.com | Web: www.ionos.de

Hauptsitz Montabaur, Amtsgericht Montabaur, HRB 24498

Vorstand: Hüseyin Dogan, Dr. Martin Endreß, Claudia Frese, Henning
Kettler, Arthur Mai, Matthias Steinberg, Achim Weiß
Aufsichtsratsvorsitzender: Markus Kadelke


Member of United Internet
diff -Nru rdma-core-33.1/debian/changelog 
rdma-core-33.1+git20210317/debian/changelog
--- rdma-core-33.1/debian/changelog 2021-01-27 14:32:48.0 +0100
+++ rdma-core-33.1+git20210317/debian/changelog 2021-04-12 11:28:57.0 
+0200
@@ -1,3 +1,26 @@
+rdma-core (33.1+git20210317-1) unstable; urgency=medium
+
+  * New upstream bug-fix snapshot:
+- mlx5: Fix uuars to have the 'uar_mmap_offset' data
+- pyverbs: Fix Mlx5 QP constructor
+- efa: Fix DV extension clear check
+- verbs: Fix possible port loop overflow
+- ibacm: Fix possible port loop overflow
+- mlx5: DR, Check new cap for isolated VL TC QP
+- kernel-boot: Fix VF lookup
+- mlx5: DR, Force QP drain on table creation
+- libhns: Avoid double release of a pointer
+- libhns: Correct definition of DB_BYTE_4_TAG_M
+- libhns: Remove assert to check whether a pointer is NULL
+- libhns: Remove the unnecessary mask on QPN of CQE
+- libhns: Remove unnecessary mask of ownerbit
+- libhns: Remove unnecessary barrier when poll cq
+- rdma-ndd: fix udev racy issue for system with multiple InfiniBand HCAs
+- verbs: Fix create CQ comp_mask check
+  * Update my email address
+
+ -- Benjamin Drung   Mon, 12 Apr 2021 11:28:57 +0200
+
 rdma-core (33.1-1) unstable; urgency=medium
 
   * New upstream bugfix release.
diff -Nru rdma-core-33.1/debian/control 
rdma-core-33.1+git20210317/debian/control
--- rdma-core-33.1/debian/control   2021-01-27 14:32:46.0 +0100
+++ rdma-core-33.1+git20210317/debian/control   2021-04-12 11:25:05.0 
+0200
@@ -1,5 +1,5 @@
 Source: rdma-core
-Maintainer: Benjamin Drung 
+Maintainer: Benjamin Drung 
 Section: net
 Priority: optional
 Build-Depends: cmake (>= 2.8.11),
diff -Nru rdma-core-33.1/debian/copyright 
rdma-core-33.1+git20210317/debian/copyright
--- rdma-core-33.1/debian/copyright 2020-04-14 16:06:21.0 +0200
+++ rdma-core-33.1+git20210317/debian/copyright 2021-04-12 11:25:21.0 
+0200
@@ -12,7 +12,7 @@
 Copyright: 2008, Genome Research Ltd
2014, Ana Beatriz Guerrero Lopez 
2015-2016, Jason Gunthorpe 
-   2016-2018, Benjamin Drung 
+   2016-2021, Benjamin Drung 
2016-2017, Talat Batheesh 
 License: GPL-2+
  This program is free software; you can redistribute it and/or modify
diff -Nru rdma-core-33.1/ibacm/src/acme.c 
rdma-core-33.1+git20210317/ibacm/src/acme.c
--- rdma-core-33.1/ibacm/src/acme.c 2021-01-26 09:06:08.0 +0100
+++ rdma-core-33.1+git20210317/ibacm/src/acme.c 2021-04-06 10:12:51.0 
+0200
@@ -461,7 +461,7 @@
struct ibv_port_attr port_attr;
int i, index, ret, found_active;
char host_name[256];
-   uint8_t p;
+   uint32_t p;
 
ret = gethostname(host_name, sizeof host_name);
if (ret) {
@@ -481,17 +481,17 @@
if (!found_active) {
ret = ibv_query_port(verbs[i], p, _attr);
if (!ret && port_attr.state == IBV_PORT_ACTIVE) 
{
-   VPRINT("%s %s %d default\n",
+   

Bug#987250: baycomepp FTBFS with GCC-11

[Lukas Märdian]

Package: baycomepp
Version: 0.10-15
Severity: important
Tags: patch
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu hirsute ubuntu-patch

Dear Maintainer,

baycomepp fails to build from scratch with newer versions of GCC,
especially GCC-11, as discovered by an Ubuntu archive rebuild.

The attached patch fixes this problem by re-defining the 'only_inline'
macro as 'extern inline', as it can be found in the original sources.

Thanks for considering the patch.


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

Kernel: Linux 5.8.0-49-generic (SMP w/4 CPU threads)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_WARN, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
diff -u baycomepp-0.10/udriver/drvresident.c 
baycomepp-0.10/udriver/drvresident.c
--- baycomepp-0.10/udriver/drvresident.c
+++ baycomepp-0.10/udriver/drvresident.c
@@ -48,11 +48,7 @@
 
 /* -- */
 
-#if __GNUC__ < 5
 #define only_inline extern inline
-#else
-#define only_inline inline
-#endif
 
 /* -- */
 

Bug#987249: bookletimposer: Failing autopkgtests after imagemagick change to disable ghostscript handled formats

[Salvatore Bonaccorso]

Source: bookletimposer
Version: 0.3+ds-1
Severity: serious
Justification: failing autopkgtests
X-Debbugs-Cc: car...@debian.org

Hi

imagemagick / 8:6.9.11.60+dfsg-1.2 upload disabled ghostscript handled
formats (which already was done earlier in DSA 4712-1 / imagemagick
8:6.9.10.23+dfsg-2.1+deb10u1)

Unfortunately bookletimposer's autopkgtests (integration) uses 

convert xc:none -page A4 $i.pdf

to first create 4 PDFs. But this is only preparational for the own
tests for bookletimposer itself, so the failure is false in the sense
it does not indicate a problem with bookletimposer.

The autopkgtests should try to avoid first creating 4 PDFs with
convert, as imagemagick disables now by default the ghostscript
handled formats and so convert to PDF will be blocked.

Regards,
Salvatore

Bug#987247: imagemagick: failing autopkgtests after disabling of ghostscript handled formats

[Salvatore Bonaccorso]

Source: imagemagick
Version: 8:6.9.11.60+dfsg-1.2
Severity: serious
Justification: failing autopkgtests
X-Debbugs-Cc: car...@debian.org,debian-rele...@lists.debian.org

After disabling the ghostscript handled formats in policy.xml for
imagemagick (following what was done in stable already with DSA 4712-1
/ imagemagick 8:6.9.10.23+dfsg-2.1+deb10u1) the autopkgtests of
imagemagick itself fail because they use 'convert rose: pdf:/dev/null'
in part of the tests.

Those need to be adjusted as well, and was a fallout of the previous
done upload done as 8:6.9.11.60+dfsg-1.2.

Regards,
Salvatore

Bug#986830: ITP: sscg -- simple SSL certificate generator

[Martin Pitt]

Control: tag -1 pending

Martin Pitt [2021-04-12 16:23 +0200]:
> * Package name: sscg

I packaged this at https://salsa.debian.org/debian/sscg and uploaded to
experimental. It's in the NEW queue now:
https://ftp-master.debian.org/new/sscg_2.6.2-1.html

Martin

Bug#987246: buster-pu: package tnef/1.4.12-1.2

[Thorsten Alteholz]

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

The attached debdiff for tnef fixes CVE-2019-18849 in Buster.

It is marked as no-dsa by the security team.

The fix has been uploaded to Jessie long time ago and nobody complained up 
to now.


  Thorstendiff -Nru tnef-1.4.12/debian/changelog tnef-1.4.12/debian/changelog
--- tnef-1.4.12/debian/changelog2017-05-29 15:03:02.0 +0200
+++ tnef-1.4.12/debian/changelog2021-04-18 10:03:02.0 +0200
@@ -1,3 +1,12 @@
+tnef (1.4.12-1.2+deb10u1) buster-security; urgency=high
+
+  * Non-maintainer upload by the LTS Team.
+  * CVE-2019-18849 (Closes: #944851)
+Using emails with a crafted winmail.dat application/ms-tnef attachment
+might allow to change .ssh/authorized_keys.
+
+ -- Thorsten Alteholz   Sun, 18 Apr 2021 10:03:02 +0200
+
 tnef (1.4.12-1.2) unstable; urgency=medium
 
   * Non-maintainer upload by the Wheezy LTS Team. (Closes: #862442)
diff -Nru tnef-1.4.12/debian/patches/CVE-2019-18849.patch 
tnef-1.4.12/debian/patches/CVE-2019-18849.patch
--- tnef-1.4.12/debian/patches/CVE-2019-18849.patch 1970-01-01 
01:00:00.0 +0100
+++ tnef-1.4.12/debian/patches/CVE-2019-18849.patch 2021-04-18 
10:03:02.0 +0200
@@ -0,0 +1,147 @@
+Index: tnef-1.4.12/src/alloc.c
+===
+--- tnef-1.4.12.orig/src/alloc.c   2021-04-16 09:49:11.067016999 +0200
 tnef-1.4.12/src/alloc.c2021-04-16 09:49:11.063016905 +0200
+@@ -72,13 +72,14 @@
+ 
+ /* attempts to malloc memory, if fails print error and call abort */
+ void*
+-xmalloc (size_t num, size_t size)
++xmalloc (size_t num, size_t size, size_t extra)
+ {
+ size_t res;
+ if (check_mul_overflow(num, size, ))
+ abort();
+-
+-void *ptr = malloc (res);
++if (res + extra < res)
++abort();
++void *ptr = malloc (res + extra);
+ if (!ptr
+ && (size != 0)) /* some libc don't like size == 0 */
+ {
+@@ -90,41 +91,44 @@
+ 
+ /* Allocates memory but only up to a limit */
+ void*
+-checked_xmalloc (size_t num, size_t size)
++checked_xmalloc (size_t num, size_t size, size_t extra)
+ {
+ size_t res;
+ if (check_mul_overflow(num, size, ))
+ abort();
+-
++if (res + extra < res)
++abort();
+ alloc_limit_assert ("checked_xmalloc", res);
+-return xmalloc (num, size);
++return xmalloc (num, size, extra);
+ }
+ 
+ /* xmallocs memory and clears it out */
+ void*
+-xcalloc (size_t num, size_t size)
++xcalloc (size_t num, size_t size, size_t extra)
+ {
+ size_t res;
+ if (check_mul_overflow(num, size, ))
+ abort();
+ 
+ void *ptr;
+-ptr = malloc(res);
++if (res + extra < res)
++abort();
++ptr = malloc(res + extra);
+ if (ptr)
+ {
+-memset (ptr, '\0', (res));
++memset (ptr, '\0', (res + extra));
+ }
+ return ptr;
+ }
+ 
+ /* xcallocs memory but only up to a limit */
+ void*
+-checked_xcalloc (size_t num, size_t size)
++checked_xcalloc (size_t num, size_t size, size_t extra)
+ {
+ size_t res;
+ if (check_mul_overflow(num, size, ))
+ abort();
+ 
+ alloc_limit_assert ("checked_xcalloc", (res));
+-return xcalloc (num, size);
++return xcalloc (num, size, extra);
+ }
+Index: tnef-1.4.12/src/alloc.h
+===
+--- tnef-1.4.12.orig/src/alloc.h   2021-04-16 09:49:11.067016999 +0200
 tnef-1.4.12/src/alloc.h2021-04-16 09:49:11.063016905 +0200
+@@ -35,19 +35,23 @@
+ extern void set_alloc_limit (size_t size);
+ extern size_t get_alloc_limit();
+ extern void alloc_limit_assert (char *fn_name, size_t size);
+-extern void* checked_xmalloc (size_t num, size_t size);
+-extern void* xmalloc (size_t num, size_t size);
+-extern void* checked_xcalloc (size_t num, size_t size);
+-extern void* xcalloc (size_t num, size_t size);
++extern void* checked_xmalloc (size_t num, size_t size, size_t extra);
++extern void* xmalloc (size_t num, size_t size, size_t extra);
++extern void* checked_xcalloc (size_t num, size_t size, size_t extra);
++extern void* xcalloc (size_t num, size_t size, size_t extra);
+ 
+ #define XMALLOC(_type,_num)   \
+-((_type*)xmalloc((_num), sizeof(_type)))
++  ((_type*)xmalloc((_num), sizeof(_type), 0))
+ #define XCALLOC(_type,_num)   \
+-((_type*)xcalloc((_num), sizeof (_type)))
++  ((_type*)xcalloc((_num), sizeof (_type), 0))
+ #define CHECKED_XMALLOC(_type,_num)   \
+-((_type*)checked_xmalloc((_num),sizeof(_type)))
+-#define CHECKED_XCALLOC(_type,_num)   \
+-((_type*)checked_xcalloc((_num),sizeof(_type)))
++  ((_type*)checked_xmalloc((_num),sizeof(_type),0))
++#define CHECKED_XMALLOC_ADDNULL(_type,_num)   \
++  

Bug#987055: ksnip: Requires libkColorPicker.so.0.1.4

[Manu Hernandez]

Hi,

Another missing library: libkImageAnnotator.so.0.3.2

Could you please take a look at it?

Thank you!

Manu

Bug#987245: apache2: After=network.target should be After=network-online.target

[Ryutaroh Matsumoto]

Package: apache2
Version: 2.4.46-4
Severity: normal
Tags: sid bullseye

Dear Maintainer,

When /etc/apache2/ports.conf listens specific IP addresses like below
Listen 192.168.1.2:80
Listen 153.240.174.134:64193
Listen [2400:4050:2ba1:ac00:99:f0ae:8600:9595]:80
Listen [2400:4050:2ba1:ac00:99:f0ae:8600:beef]:80

apache httpd needs those IP addresses being already configured
when it starts, otherwise the httpd fails to start.
This ordering dependency is captured by
After=network-online.target
Wants=network-online.target

The current apache2.service systemd file seems slightly incorrect.

Best regards, Ryutaroh Matsumoto

-- Package-specific info:

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

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

Versions of packages apache2 depends on:
ii  apache2-bin  2.4.46-4
ii  apache2-data 2.4.46-4
ii  apache2-utils2.4.46-4
ii  dpkg 1.20.7.1
ii  init-system-helpers  1.60
ii  lsb-base 11.1.0
ii  mime-support 3.66
ii  perl 5.32.1-3
ii  procps   2:3.3.17-5

Versions of packages apache2 recommends:
ii  ssl-cert  1.1.0

Versions of packages apache2 suggests:
pn  apache2-doc  
pn  apache2-suexec-pristine | apache2-suexec-custom  
pn  www-browser  

Versions of packages apache2-bin depends on:
ii  libapr1  1.7.0-6
ii  libaprutil1  1.6.1-5
ii  libaprutil1-dbd-sqlite3  1.6.1-5
ii  libaprutil1-ldap 1.6.1-5
ii  libbrotli1   1.0.9-2+b2
ii  libc62.31-11
ii  libcrypt11:4.4.18-2
ii  libcurl4 7.74.0-1.2
ii  libjansson4  2.13.1-1.1
ii  libldap-2.4-22.4.57+dfsg-2
ii  liblua5.3-0  5.3.3-1.1+b1
ii  libnghttp2-141.43.0-1
ii  libpcre3 2:8.39-13
ii  libssl1.11.1.1k-1
ii  libxml2  2.9.10+dfsg-6.3+b1
ii  perl 5.32.1-3
ii  zlib1g   1:1.2.11.dfsg-2

Versions of packages apache2-bin suggests:
pn  apache2-doc  
pn  apache2-suexec-pristine | apache2-suexec-custom  
pn  www-browser  

Versions of packages apache2 is related to:
ii  apache2  2.4.46-4
ii  apache2-bin  2.4.46-4

-- Configuration Files:
/etc/apache2/conf-available/charset.conf changed:
AddDefaultCharset UTF-8

/etc/apache2/ports.conf changed:
Listen 192.168.1.2:80
Listen 153.240.174.134:64193
Listen [2400:4050:2ba1:ac00:99:f0ae:8600:9595]:80
Listen [2400:4050:2ba1:ac00:99:f0ae:8600:beef]:80

Listen 443


Listen 443



-- no debconf information

Bug#987244: RFS: nbsdgames/4.0-1 [ITP] -- text based mini games for your terminal

[Gürkan Myczko]

Package: sponsorship-requests
Severity: wishlist

Dear mentors,

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

 * Package name: nbsdgames
   Version : 4.0-1
   Upstream Author : Hossein Bakhtiarifar 
 * URL : https://github.com/abakh/nbsdgames
 * License : WTFPL-like-CC0
 * Vcs : https://salsa.debian.org/games-team/nbsdgames
   Section : games

It builds those binary packages:

  nbsdgames - text based mini games for your terminal

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


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

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


  dget -x 
https://mentors.debian.net/debian/pool/main/n/nbsdgames/nbsdgames_4.0-1.dsc


Changes for the initial release:

 nbsdgames (4.0-1) unstable; urgency=medium
 .
   * Initial release. (Closes: #964876)

Regards,
--
  Gürkan Myczko

Bug#982745: nginx-common: don't enable TLSv1 or TLSv1.1 in default configuration)

[Diederik de Haas]

Control: severity -1 grave
Control: notforwarded -1

I did not get any response to my bug report which I tagged with 'security', so 
I'm upping the severity and believe the Debian documentation justifies it.
https://www.debian.org/Bugs/Developer#severities says:
"Most security bugs should also be set at critical or grave severity."

Feel free to downgrade the severity if you don't agree this is a security or a 
'grave' issue (which should be fixed before Bullseye is released).
But then I'll at least know someone has seen and evaluated the issue.

I've also cleared the 'forwarded' as it is not an upstream issue.
https://salsa.debian.org/nginx-team/nginx/-/merge_requests/7 still contains my 
patch which fixes this issue by removing "TLSv1 TLSv1.1" from the 
"ssl_protocols" setting in debian/conf/nginx.conf

https://en.wikipedia.org/wiki/Transport_Layer_Security#TLS_1.0 says:
"The PCI Council suggested that organizations migrate from TLS 1.0 to TLS 1.1 
or higher before June 30, 2018. In October 2018, Apple, Google, Microsoft, and 
Mozilla jointly announced they would deprecate TLS 1.0 and 1.1 in March 2020."



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

Bug#986112: buster-pu: package freediameter/1.2.1-7

[Thorsten Alteholz]

On Mon, 19 Apr 2021, Adam D. Barratt wrote:

Please go ahead.


Great, thanks, and uploaded ...

  Thorsten

Bug#987242: logrotate: Whitespace and/or equal sign separate key and value is not true for at least "dateformat"

[Henning Hucke]

Package: logrotate
Version: 3.14.0-4
Severity: normal

Dear Maintainer,

totally reproducable is the issue that with something like

dateformat-%Y-%m-%d

(with "" meaning tab character "0x09") a logfile

logfile.log

is rotated into a file

logfile.log-2021-04-19

in contrast to the statement in the logrotate.conf man page that keys
and value are separated by whitespace and/or an optional equal ("=")
sign.

If I remember correctly I also get an error message if I use the config
keyword "rotate" like "rotate7" with daily rotation. A
"copytruncate" possibly also plays a role.

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

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

Versions of packages logrotate depends on:
ii  cron [cron-daemon]  3.0pl1-134+deb10u1
ii  libacl1 2.2.53-4
ii  libc6   2.28-10
ii  libpopt01.16-12
ii  libselinux1 2.8-1+b1
ii  systemd-sysv241-7~deb10u7

Versions of packages logrotate recommends:
ii  mailutils [mailx]  1:3.5-4

logrotate suggests no packages.

-- no debconf information

Best regards,
Henning Hucke