Bug#973002: ITP: tensorboard -- TensorFlow's Visualization Toolkit

[Mo Zhou]

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

* Package name: tensorboard
  Version : 2.3.0
  Upstream Author : TensorFlow authors
* URL : https://github.com/tensorflow/tensorboard
* License : Apache-2.0
  Programming Lang: TypeScript, Python
  Description : TensorFlow's Visualization Toolkit

TensorFlow's visualization tool can be used standalone (i.e. without
tensorflow). It's very useful for training networks using PyTorch as
well. This package will be maintained by Debian Deep Learning Team
for sake of unblocking the pytorch-lightning package.

Bug#973001: seqan3: autopackage tests need updating for new googletest

[Steve M. Robbins]

Source: seqan3
Severity: normal

Dear Maintainer,

The autopkg tests need to be updated for the new googletest.  There are 
failures such as

/tmp/autopkgtest-lxc.u2mymoo7/downtmp/autopkgtest_tmp/unit/alphabet/cigar/../alphabet_test_template.hpp:86:
 Failure
Type parameterized test suite alphabet is defined via 
REGISTER_TYPED_TEST_SUITE_P, but never instantiated via 
INSTANTIATE_TYPED_TEST_SUITE_P. None of the test cases will run.

Ideally, TYPED_TEST_P definitions should only ever be included as part of 
binaries that intend to use them. (As opposed to, for example, being placed in 
a library that may be linked in to get other utilities.)



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

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

Bug#972999: avoid "which"

[Harald Dunkel]

Package: sensible-utils
Version: 0.0.12

To avoid problems with user-supplied "which" or bad $PATH variables
sensible-editor should use built-ins (e.g. "type") or absolute path names.

Bug#973000: RFS: surgescript/0.5.4.4-1 -- Scripting language for games

[Carlos Donizete Froes]

Package: sponsorship-requests
Severity: normal

Dear mentors,

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

 * Package name: surgescript
   Version : 0.5.4.4-1
   Upstream Author : Alexandre Martins 
 * URL : https://docs.opensurge2d.org
 * License : Apache-2.0, BSD-2-Clause
 * Vcs : https://salsa.debian.org/games-team/surgescript
   Section : games

It builds those binary packages:

  surgescript - Scripting language for games

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

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

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

  dget -x 
https://mentors.debian.net/debian/pool/main/s/surgescript/surgescript_0.5.4.4-1.dsc

Changes since the last upload:

 surgescript (0.5.4.4-1) unstable; urgency=medium
 .
   * New upstream release.
   * Changed debian/clean.
   * debian/docs:
 + CHANGES.md file included.
   * debian/control:
 + Switch to debhelper-compat = 13.
   * The manual page has been changed to section 6.
   * debian/rules:
 - Changed override_dh_auto_install.
 + Added DEB_CFLAGS_MAINT_APPEND and DEB_LDFLAGS_MAINT_APPEND.
 + Added override_dh_auto_configure.

Regards,
--
  Carlos Donizete Froes [a.k.a coringao]

Bug#972998: RM: lumpy-sv [s390x] -- RoQA; build dependencies cannot be fulfilled on s390x

[Adrian Bunk]

Package: ftp.debian.org
Severity: normal

See #972935 for background.

Bug#972906: [Python-modules-team] Bug#972906: monty: new upstream release available

[Drew Parsons]

On 2020-10-27 03:11, Emmanuel Arias wrote:

Hi Drew,

 I push to salsa the new upstream release (4.0.2)

Cheers,

Arias Emmanuel



Looks good. Uploading.

Bug#972906: [Python-modules-team] Bug#972906: monty: new upstream release available

[Drew Parsons]

On 2020-10-27 03:11, Emmanuel Arias wrote:

Hi Drew,

 I push to salsa the new upstream release (4.0.2)




Thanks Emmanuel.  I'll check and upload.

Drew

Bug#972985: [Pkg-net-snmp-devel] Bug#972985: snmp: Blumenthal AES encryption should be enabled by default

[Craig Small]

Hi Owen,

OK, I think I know what happened, I was checking a different branch. No
idea why the build system says it is building with them when it's not.
Your patch is fine, I'll add that in shortly.

 - Craig


On Tue, 27 Oct 2020 at 10:18, Craig Small  wrote:

> On Tue, 27 Oct 2020 at 07:42, Owen Evans  wrote:
>
>> Package: snmp
>> Version: 5.9+dfsg-3-silo
>>
> This isn't a valid Debian version.
>
> Blumenthal AES, in spite of being a 'draft' part of the SNMP Standard,
>> is becoming widely implemented by many vendors. It is the main way to
>> have strong encryption in connection with SNMPv3. Debian should include
>> the --enable-blumenthal-aes option added around line 53 of debian/rules
>> so that it is used when invoking the ./configure script from the
>> upstream source package.
>>
> Are you sure the Debian packages don't already have this enabled?
>
> Also, that flag doesn't exist in 5.9 of net-snmp
>  ./configure --enable-blumenthal-aes
> configure: WARNING: unrecognized options: --enable-blumenthal-aes
>
> The draft standard seems to be all about enabling AES, or as the draft
> states:
>1)Provide a set of new privacy protocols for USM based on the
>  Advanced Encryption Standard.
>
> Output of the build system shows AES is actually there:
>
>   Crypto support from:crypto
>   Authentication support: MD5 SHA1 SHA224 SHA256 SHA384 SHA512
>   Encryption support: DES AES AES128 AES192 AES192C AES256 AES256C
>
> So I'm a bit confused about what is not enabled and why your configure
> option works.
> The --with-openssl and having openssl 0.9.7 or later will do it.
>
>  - Craig
>
>

Bug#972985: [Pkg-net-snmp-devel] Bug#972985: snmp: Blumenthal AES encryption should be enabled by default

[Evans, Owen]

Hi, Craig. Thanks for the reply.

When I issue the command ‘snmpwalk --help’ on a recent build of bullseye,
with out of the box net-snmp, the below line is found in the help:

-x PROTOCOL   set privacy protocol (DES|AES)

Indicates that the AES-192 and AES-256 options are not available, at least
in the command line utilities.

Attached please find the patch that I apply prior to building net-snmp in
order to enable this functionality. The version in the report is not a
valid Debian version because I have "made up" my own version to include
this change and differentiate it in my local apt repository from the out-
of-the-box version which does not include this change.

After applying the patch and building/
installing the package, the below line appears in the output:

-x PROTOCOL   set privacy protocol (DES|AES|AES-192|AES-256)

I am not sure I have made the patch the right way. I may also be missing
something. Please let me know if there is anything else I can do to help.

Thanks
Owen Evans

From: Craig Small  
Sent: Monday, October 26, 2020 7:19 PM
To: Evans, Owen ; 972...@bugs.debian.org
Subject: Re: [Pkg-net-snmp-devel] Bug#972985: snmp: Blumenthal AES encryption 
should be enabled by default

[EXTERNAL EMAIL]
On Tue, 27 Oct 2020 at 07:42, Owen Evans  wrote:
Package: snmp
Version: 5.9+dfsg-3-silo
This isn't a valid Debian version.

Blumenthal AES, in spite of being a 'draft' part of the SNMP Standard,
is becoming widely implemented by many vendors. It is the main way to
have strong encryption in connection with SNMPv3. Debian should include
the --enable-blumenthal-aes option added around line 53 of debian/rules
so that it is used when invoking the ./configure script from the
upstream source package.
Are you sure the Debian packages don't already have this enabled?

Also, that flag doesn't exist in 5.9 of net-snmp
 ./configure --enable-blumenthal-aes
configure: WARNING: unrecognized options: --enable-blumenthal-aes
 
The draft standard seems to be all about enabling AES, or as the draft states:
   1)Provide a set of new privacy protocols for USM based on the
     Advanced Encryption Standard.
Output of the build system shows AES is actually there:

  Crypto support from:        crypto
  Authentication support:     MD5 SHA1 SHA224 SHA256 SHA384 SHA512
  Encryption support:         DES AES AES128 AES192 AES192C AES256 AES256C

So I'm a bit confused about what is not enabled and why your configure option 
works.
The --with-openssl and having openssl 0.9.7 or later will do it.

 - Craig



silo.patch
Description: silo.patch

Bug#972996: ITP: nccm -- Terminal based ssh connection manager

[Andrew]

Package: wnpp
Severity: wishlist
Owner: Andrew 

* Package name: nccm
  Version : 1.2.0
  Upstream Author : Kenneth Aaron 
* URL : https://github.com/flyingrhinonz/nccm
* License : GPL3
  Programming Lang: Python
  Description : Terminal based ssh connection manager

This is a terminal based (ncurses) ssh connection manager.

Configuration is done via a yaml file and each connection can be
configured with user@host, a comment, an identity file and general
ssh options.

The list can be searched directly from the command line and, if more
than one match exists, an ncurses interface is presented to select the
required host.

The search is done on any configured field and the interface permits
ordering based on any of the displayed fields.


 - why is this package useful/relevant?

This package lets you easily keep track of hosts when you have a lot to
connect to. Once you configure it you can just type in

nccm mail

and access the host that, say, has mail in the comment field. If more
than one matches then it puts up an ncurses interface to let you select
one from a filtered list of mail hosts.


 - how do you plan to maintain it?

It's a simple package so I plan on doing it myself in my own git repo
(https://github.com/rubiksdot/nccm). I am in contact with the author
and have already submitted patches to the utility. Communication with
him is good and have found him very responsive to suggestions I've
given him as well bug reports.

Bug#972637: finch: crashes on startup with "illegal instruction"

[Bernhard Übelacker]

Hello Karsten,
thanks for the information - that explains why my emulated pentium
failed already at 0x...6bb because not supporting sse at all.

>From wikipedia [1] the pminud instruction at 0x...6fb got
introduced with sse4.1 which seem not supported from your
flags line (while on the other side intel says [2] it is a Penryn).
(Might there be a bios switch?)

Kind regards,
Bernhard

[1] https://en.wikipedia.org/wiki/SSE4
[2] 
https://ark.intel.com/content/www/de/de/ark/products/37253/intel-pentium-processor-t4300-1m-cache-2-10-ghz-800-mhz-fsb.html

Bug#972992: j4-dmenu-desktop: dmenu and i3-sensible-terminal missing

[Thierry B.]

Package: j4-dmenu-desktop
Version: 2.16-1+b1
Severity: grave
Justification: renders package unusable

Dear Maintainer,

   * running "j4-dmenu-desktop", "dmenu" is missing. So "suckless-tools"
should
be a dependency

   * After installing "suckless-tools" package, after selecting a program in
"j4-dmenu-desktop" search bar, there is a message:

 "/bin/bash: line 1: i3-sensible-terminal: command not found".

If the program is only for i3 window manager, then add a dependency to
"i3-wm"
package, or please fix the error.




-- System Information:
Distributor ID: Debian
Release:testing/unstable
Architecture: x86_64

Kernel: Linux 5.8.0-3-amd64 (SMP w/1 CPU thread)
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8),
LANGUAGE=fr:en
Shell: /bin/sh linked to /bin/dash
Init: runit (via /run/runit.stopit)

Versions of packages j4-dmenu-desktop depends on:
ii  libc62.31-4
ii  libgcc-s1 [libgcc1]  10.2.0-15
ii  libstdc++6   10.2.0-15

j4-dmenu-desktop recommends no packages.

j4-dmenu-desktop suggests no packages.

-- no debconf information

Bug#972995: dh-elpa: fails to read project.el's Package-Requires

[Sean Whitton]

Package: dh-elpa
Version: 2.0.4
Control: affects -1 elpa-project

For some reason dh-elpa is failing to generate a dependency on elpa-xref.

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#972885: emacs: Bundled Gnus unable to enter any group

[Rob Browning]

Florent Rougon  writes:

> The problem can be solved either by me not using the above configuration
> bit anymore (which is of course a regression), or by making the
> `article' variable use dynamic binding before the failing `funcall' in
> `gnus-summary-highlight-line' (see the attached patch; the change could
> probably be done earlier in the function, along with the other similar
> defvar's, but I've only tested the attached patch).
>
> Regards

Nice catch.  Have you, or are you already planning to post this
upstream?

-- 
Rob Browning
rlb @defaultvalue.org and @debian.org
GPG as of 2011-07-10 E6A9 DA3C C9FD 1FF8 C676 D2C4 C0F0 39E9 ED1B 597A
GPG as of 2002-11-03 14DD 432F AE39 534D B592 F9A0 25C8 D377 8C7E 73A4

Bug#972572: emacs-gtk: scrolling upward with the mouse wheel actually scrolls downward when the cursor needs repositioning

[Vincent Lefevre]

That's strange. I'm on another machine, and I can't reproduce the
bug, and I can't reproduce it either when I connect by SSH to the
machine where it was occurring.

Perhaps that's related to the X server or to the mouse.

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

Bug#972777: vim ftbfs with python3.9 (test failure)

[James McCoy]

On Fri, Oct 23, 2020 at 12:14:17PM +0200, Matthias Klose wrote:
> Package: src:vim
> Version: 8.2.0716-3
> Severity: important
> Tags: sid bullseye ftbfs
> User: debian-pyt...@lists.debian.org
> Usertags: python3.9
> 
> vim ftbfs with python3.9 (test failure), python3-defaults from experimental
> Not sure if that's really related to 3.9:
> 
> https://people.debian.org/~ginggs/python3.9-default/vim_8.2.0716-3build1_amd64-2020-10-23T04:16:10Z.build
> 
> [...]
> Failures:
>   test87 FAILED

The test87 failure is Python 3.9 related:

675c675
< vim.command("", 2):(, TypeError('vim.command() takes 
exactly one argument (2 given)',))
---
> vim.command("", 2):(, TypeError('command() takes 
exactly one argument (2 given)',))
701c701
< vim.foreach_rtp(int, 2):(, 
TypeError('vim.foreach_rtp() takes exactly one argument (2 given)',))
---
> vim.foreach_rtp(int, 2):(, TypeError('foreach_rtp() 
takes exactly one argument (2 given)',))
965c965
< d.popitem(1, 2):(, TypeError('dictionary.popitem() 
takes no arguments (2 given)',))
---
> d.popitem(1, 2):(, TypeError('popitem() takes no 
arguments (2 given)',))
967c967
< d.has_key():(, TypeError('dictionary.has_key() takes 
exactly one argument (0 given)',))
---
> d.has_key():(, TypeError('has_key() takes exactly one 
argument (0 given)',))

>   From test_alot.vim:
>   Found errors in Test_compiler():
>   function RunTheTest[39]..Test_compiler line 23: command did not fail: 
> clist
>   function RunTheTest[39]..Test_compiler line 29: Pattern '\\n \\d\\+ 
> Xfoo.pl:3:
> Global symbol "$foo" requires explicit package name' does not match '\n18
> Xfoo.pl:3: Global symbol "$foo" requires explicit package name (did you forget
> to declare "my $foo"?)'

This I haven't seen before nor reproduced locally.  The fix is straight
forward, but I don't see why it would have failed this way.

Cheers,
-- 
James
GPG Key: 4096R/91BF BF4D 6956 BD5D F7B7  2D23 DFE6 91AE 331B A3DB

Bug#972994: iw should no longer recommend crda

[Diederik de Haas]

Package: iw
Version: 5.9-1
Severity: normal

https://git.kernel.org/pub/scm/linux/kernel/git/mcgrof/crda.git/commit/?id=f4ef2531698fb9ba006e8b31a223b3269be8bc7c
states:
"README: add legacy notice
As if kernel v4.15 CRDA is no longer needed. Annotate this. The
code will still be maintained to help older kernels."

Thus, afaict, crda isn't even needed by the current stable (kernel) 
release, let alone for the next (Bullseye) or later.


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

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

Versions of packages iw depends on:
ii  libc6 2.31-4
ii  libnl-3-200   3.4.0-1+b1
ii  libnl-genl-3-200  3.4.0-1+b1

Versions of packages iw recommends:
ii  crda  4.14+git20191112.9856751-1

iw suggests no packages.

-- no debconf information

Bug#832628: Closing, only affecting jessie and earlier

[Mike Gabriel]

Control: close -1

Closing this bug as it was an issue spotted in jessie and earlier.  
Resolved since 5.1.0-1.


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



pgpaoprpN0NSg.pgp
Description: Digitale PGP-Signatur

Bug#972969: openafs-modules-dkms: Does not build on bullseye with kernel 5.9.1

[Benjamin Kaduk]

Hi Robert,

On Mon, Oct 26, 2020 at 07:08:41PM +0100, Robert Senger wrote:
> Package: openafs-modules-dkms
> Version: 1.8.6-3
> Severity: serious
> Tags: ftbfs
> Justification: fails to build from source (but built successfully in the past)
> 
> DKMS fails to build module on bullseye with kernel 5.9.1

It turns out that I prepared a 1.8.6-4 a couple days ago to fix this but
failed to actually upload it.  Thanks for the reminder to push it up; it
should be appearing in sid shortly.

-Ben

Bug#972197: subversion b-d's on python3-all-dev, but only builds for the default python3 version

[James McCoy]

On Wed, Oct 21, 2020 at 12:42:36PM +0200, Matthias Klose wrote:
> On 10/21/20 1:13 AM, James McCoy wrote:
> > On Wed, Oct 14, 2020 at 10:22:50AM +0200, Matthias Klose wrote:
> >> subversion b-d's on python3-all-dev, but only builds for the default 
> >> python3
> >> version.
> > 
> > It actually builds for all available versions, but the install is
> > broken.  This used to work with Python 2.x.
> > 
> > It looks like the difference is that
> > 
> >   python$$v -c 'from distutils import sysconfig; 
> > print(sysconfig.get_python_lib())'
> > 
> > no longer returns a version-specific path.  When installing the Python
> > bindings, that means we install all versions to the same path and they
> > overwrite each other.
> > 
> > Was this an intentional change?  If so, I guess I'll need to emulate
> > aspects of pybuild to handle this.
> 
> yes, 2.7 installed into a version specific path, while 3.x installs into a
> common path. Maybe it's worth patch the upstream to create the soname with the
> version already encoded in the soname.

We're already doing some patching (thanks to you!) to support building
version-specific Python bindings.  I'll see about updating that to use
the distutils.sysconfig.get_config_var('EXT_SUFFIX').

Cheers,
-- 
James
GPG Key: 4096R/91BF BF4D 6956 BD5D F7B7  2D23 DFE6 91AE 331B A3DB

Bug#972982: RM: libgstreamer1-perl -- ROM; dead upstream

[Mike Gabriel]

Package: ftp.debian.org
Severity: normal

Please remove libgstreamer1-perl from testing/unstable.

The upstream author is not planning on any updates in the next future and
most of the GStreamer functionality can be accessed via
Glib::Object::Introspection.

Time to let it go from Debian...

Thanks+Greets,
Mike

Bug#970176: aka new upstream release

[Diederik de Haas]

Package: f2fs-tools
Version: 1.11.0-1.1
Followup-For: Bug #970176

On salsa.d.o it looks like version 1.13 was ready to go, but it appears
that it just never got uploaded to the archives/sid.
It would be really welcome to have a more recent version of f2fs-tools
in Bullseye and as 1.14 has been released/tagged upstream, it would be
great to have that one. (But 1.13 would be an improvement as well)

The freeze is only a couple of months away...

Cheers,
  Diederik

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

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

Versions of packages f2fs-tools depends on:
ii  libblkid12.36-3+b1
ii  libc62.31-4
ii  libf2fs-format4  1.11.0-1.1
ii  libf2fs5 1.11.0-1.1
ii  libselinux1  3.1-2+b1
ii  libuuid1 2.36-3+b1

f2fs-tools recommends no packages.

f2fs-tools suggests no packages.

-- no debconf information

Bug#972871: git-el: .el files not installed / byte-compiled

[Jonathan Nieder]

tags 972871 + patch pending
quit

Jonathan Nieder wrote:

> Thanks for reporting.
>
> Strangely, debian-emacs-policy doesn't appear to be in the
> emacsen-common package any more.  Fortunately, it's in
> https://www.debian.org/doc/packaging-manuals/debian-emacs-policy.
>
> It looks like we can remove the '"$FLAVOR" != emacs' check because
> Debian no longer provides multiple co-installable versions of emacs
> (good!).  I think if we remove the check this will simply do the
> right thing.
>
> Emacsen team: would a Breaks against emacsen-common (<< 3.0.0~)
> be sufficient for ensuring we have a new enough version of emacs
> for this to be safe?

More concretely: how about this patch?

-- 8< --
Subject: debian/git-el: do not exclude "emacs" from the flavors to
 install for

As Zack Weinberg noticed, the git-el package has not installed any
elisp for emacs for the last two years, producing a warning at
startup instead:

  git removed but not purged, skipping setup

That is because "emacs" switched from being a virtual package to
being the only flavor of standard emacs installed.  Update the
installation scripts to reflect this.

Even after this patch, the elisp installed does not do anything other
than point the user to magit and emacs's built in vc-git support.  A
followup change may remove the package.

Fixes: https://bugs.debian.org/972871
Signed-off-by: Jonathan Nieder 
---
 debian/changelog  | 5 -
 debian/control| 1 +
 debian/git-el.emacsen-install | 6 --
 debian/git-el.emacsen-remove  | 1 -
 4 files changed, 5 insertions(+), 8 deletions(-)

diff --git a/debian/changelog b/debian/changelog
index 96d06fcaff4..657218ad785 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -5,8 +5,11 @@ git (1:2.29.1-0.1) unstable; urgency=low
   * debian/control: Build-Depends: debhelper-compat (= 10)
 * debian/rules: run "dh --without autoreconf" to speed up build,
   since we don't use the autotools-generated configure script.
+  * git-el: install elisp for the "emacs" flavor, too (thx Zack Weinberg;
+closes: #972871).  Breaks: emacsen-common (<< 3.0.0~) to avoid
+triggering on older systems where "emacs" was a virtual package.
 
- -- Jonathan Nieder   Mon, 26 Oct 2020 15:44:15 -0700
+ -- Jonathan Nieder   Mon, 26 Oct 2020 16:22:41 -0700
 
 git (1:2.28.0-1) unstable; urgency=low
 
diff --git a/debian/control b/debian/control
index e3edda4cf85..25c5b83f45d 100644
--- a/debian/control
+++ b/debian/control
@@ -278,6 +278,7 @@ Architecture: all
 Multi-Arch: foreign
 Depends: ${misc:Depends}, git (>= 1:1.7.4.1-2~), emacs | emacsen
 Recommends: elpa-magit
+Breaks: emacsen-common (<< 3.0.0~)
 Replaces: git (<< 1:1.7.4.1-2~)
 Breaks: git (<< 1:1.7.4.1-2~)
 Description: fast, scalable, distributed revision control system (emacs 
support)
diff --git a/debian/git-el.emacsen-install b/debian/git-el.emacsen-install
index da35fdb0c59..4b02513a5ae 100755
--- a/debian/git-el.emacsen-install
+++ b/debian/git-el.emacsen-install
@@ -12,12 +12,6 @@ el_files="git.el git-blame.el"
 el_dir=/usr/share/git-core/emacs
 elc_dir=/usr/share/$FLAVOR/site-lisp/git
 
-# The emacs startup file looks for these files in
-# /usr/share/${debian-emacs-flavor}/site-lisp/git.
-# Installing to the generic /usr/share/emacs/site-list/git would be
-# pointless.
-[ "$FLAVOR" != emacs ] || exit 0
-
 printf 'install/git: Handling install of emacsen flavor %s\n' "$FLAVOR"
 [ -d "$elc_dir" ] || mkdir "$elc_dir"
 (
diff --git a/debian/git-el.emacsen-remove b/debian/git-el.emacsen-remove
index 5d345e1ff84..81408b0b32e 100755
--- a/debian/git-el.emacsen-remove
+++ b/debian/git-el.emacsen-remove
@@ -8,7 +8,6 @@ el_files="git.el git-blame.el"
 elc_files="git.elc git-blame.elc"
 elc_dir=/usr/share/$FLAVOR/site-lisp/git
 
-[ "$FLAVOR" != emacs ] || exit 0
 printf 'remove/git: Handling removal of emacsen flavor %s\n' "$FLAVOR"
 [ -d "$elc_dir" ] || exit 0
 (cd "$elc_dir"; rm -f $elc_files $el_files)
-- 
2.29.0.rc2.309.g374f81d7ae

Bug#972871: git-el: .el files not installed / byte-compiled

[Jonathan Nieder]

Hi,

Zack Weinberg wrote:

> While updating my emacs configuration for 27.1 (now in unstable)
> I noticed that /etc/emacs/site-start.d/50git-core.el prints
>
> git removed but not purged, skipping setup
>
> and does not autoload either git.el or git-blame.el.  This appears to
> be because /usr/lib/emacsen-common/packages/install/git does nothing
> when $FLAVOR is “emacs”:
>
> | # The emacs startup file looks for these files in
> | # /usr/share/${debian-emacs-flavor}/site-lisp/git.
> | # Installing to the generic /usr/share/emacs/site-list/git would be
> | # pointless.
> | [ "$FLAVOR" != emacs ] || exit 0
>
> This has been incorrect for quite some time - I’m not sure how long
> ago it was that (symbol-name debian-emacs-flavor) was changed to
> evaluate to “emacs” for the ordinary packages of GNU Emacs, but
> probably more than one release by now.
>
> I think a sufficient fix is to remove the above quoted lines from
> /usr/lib/emacsen-common/packages/install/git.

Thanks for reporting.

Strangely, debian-emacs-policy doesn't appear to be in the
emacsen-common package any more.  Fortunately, it's in
https://www.debian.org/doc/packaging-manuals/debian-emacs-policy.

It looks like we can remove the '"$FLAVOR" != emacs' check because
Debian no longer provides multiple co-installable versions of emacs
(good!).  I think if we remove the check this will simply do the
right thing.

Emacsen team: would a Breaks against emacsen-common (<< 3.0.0~)
be sufficient for ensuring we have a new enough version of emacs
for this to be safe?

Thanks,
Jonathan

Bug#972985: [Pkg-net-snmp-devel] Bug#972985: snmp: Blumenthal AES encryption should be enabled by default

[Craig Small]

On Tue, 27 Oct 2020 at 07:42, Owen Evans  wrote:

> Package: snmp
> Version: 5.9+dfsg-3-silo
>
This isn't a valid Debian version.

Blumenthal AES, in spite of being a 'draft' part of the SNMP Standard,
> is becoming widely implemented by many vendors. It is the main way to
> have strong encryption in connection with SNMPv3. Debian should include
> the --enable-blumenthal-aes option added around line 53 of debian/rules
> so that it is used when invoking the ./configure script from the
> upstream source package.
>
Are you sure the Debian packages don't already have this enabled?

Also, that flag doesn't exist in 5.9 of net-snmp
 ./configure --enable-blumenthal-aes
configure: WARNING: unrecognized options: --enable-blumenthal-aes

The draft standard seems to be all about enabling AES, or as the draft
states:
   1)Provide a set of new privacy protocols for USM based on the
 Advanced Encryption Standard.

Output of the build system shows AES is actually there:

  Crypto support from:crypto
  Authentication support: MD5 SHA1 SHA224 SHA256 SHA384 SHA512
  Encryption support: DES AES AES128 AES192 AES192C AES256 AES256C

So I'm a bit confused about what is not enabled and why your configure
option works.
The --with-openssl and having openssl 0.9.7 or later will do it.

 - Craig

Bug#972993: eclipse-wtp: FTBFS cannot find symbol

[Markus Koschany]

Source: eclipse-wtp
Version: 3.18-4
Severity: serious
Tags: ftbfs
X-Debbugs-Cc: eclipse-wtp: FTBFS cannot find symbol

Hi,

while I was rebuilding reverse-dependencies of jflex, I discovered
that eclipse-wtp fails to build from source. The error is unrelated to
the new version of jflex.

org.eclipse.wst.sse.ui:
 [echo] Building bundle 'Structured Source Editor' 
(org.eclipse.wst.sse.ui:1.7.0)
[mkdir] Created dir: 
/build/eclipse-wtp-3.18/org.eclipse.wst.sse.ui/target/classes
[touch] Creating 
/build/eclipse-wtp-3.18/org.eclipse.wst.sse.ui/target/dependencies
[mkdir] Created dir: 
/build/eclipse-wtp-3.18/org.eclipse.wst.sse.ui/target/sources
 [copy] Copying 295 files to 
/build/eclipse-wtp-3.18/org.eclipse.wst.sse.ui/target/sources
[javac] Compiling 295 source files to 
/build/eclipse-wtp-3.18/org.eclipse.wst.sse.ui/target/classes
[javac] 
/build/eclipse-wtp-3.18/org.eclipse.wst.sse.ui/target/sources/org/eclipse/wst/sse/ui/internal/selection/SelectionHistory.java:23:
 error: cannot find symbol
[javac] import org.eclipse.jface.util.Assert;
[javac]  ^
[javac]   symbol:   class Assert
[javac]   location: package org.eclipse.jface.util
[javac] 
/build/eclipse-wtp-3.18/org.eclipse.wst.sse.ui/target/sources/org/eclipse/wst/sse/ui/internal/preferences/ui/StatusInfo.java:18:
 error: cannot find symbol
[javac] import org.eclipse.jface.util.Assert;
[javac]  ^
[javac]   symbol:   class Assert
[javac]   location: package org.eclipse.jface.util
[javac] 
/build/eclipse-wtp-3.18/org.eclipse.wst.sse.ui/target/sources/org/eclipse/wst/sse/ui/internal/selection/StructureSelectAction.java:20:
 error: cannot find symbol
[javac] import org.eclipse.jface.util.Assert;
[javac]  ^
[javac]   symbol:   class Assert
[javac]   location: package org.eclipse.jface.util
[javac] 
/build/eclipse-wtp-3.18/org.eclipse.wst.sse.ui/target/sources/org/eclipse/wst/sse/ui/internal/TransferBuilder.java:297:
 warning: non-varargs call of varargs method with inexact argument type for 
last parameter;
[javac] >--->--->--->---obj = mtd.invoke(null, null);
[javac] >--->--->--->---   ^
[javac]   cast to Object for a varargs call
[javac]   cast to Object[] for a non-varargs call and to suppress this 
warning
[javac] 
/build/eclipse-wtp-3.18/org.eclipse.wst.sse.ui/target/sources/org/eclipse/wst/sse/ui/internal/selection/SelectionHistory.java:36:
 error: cannot find symbol
[javac] >--->---Assert.isNotNull(editor);
[javac] >--->---^

Bug#972468: nvidia-graphics-drivers-legacy-390xx: module build fails for kernel 5.9.0-1-amd64

[Thierry B.]

Also facing the same bug with same exact versions (nvidia, kernel,
debian version) as Markus Steinko.

Bug#938639: telepathy-haze: Python2 removal in sid/bullseye

[Arek]

I submitted a pull request upstream:
https://gitlab.freedesktop.org/telepathy/telepathy-haze/-/merge_requests/1

Please note that the tests only work if twisted library is patched with
the following tiny changeset:
https://github.com/twisted/twisted/pull/1145/files

This should be enough to bring back support for telepathy-haze.

Bug#972973: Please re-enable SECO HDMI CEC driver (CONFIG_VIDEO_SECO_CEC)

[Sébastien Noel]

Package: src:linux
Severity: wishlist

Dear Maintainer,

Could you please re-enable the option CONFIG_VIDEO_SECO_CEC ?
I already did requested this via bug #951543,
it worked for a time, but since linux-5.8 it seems you disabled it again 
:'(


# grep -i seco /boot/config-5.7.0-0.bpo.2-amd64
CONFIG_VIDEO_SECO_CEC=m

$ grep -i seco /boot/config-5.8.0-0.bpo.2-amd64
# CONFIG_CEC_SECO is not set

Could you explain why you did remove this module ?

Best regards,
Sébastien

Bug#970127: kmail: Kmail depends on libsasl2-modules to send out mails via SMTP

[Sandro Knauß]

reassign 970127 kdepim-runtime 4:20.08.2-3
thanks

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

Bug#972981: src:uncrustify: fails to migrate to testing for too long: FTBFS on armhf

[David Bremner]

Paul Gevers  writes:

> Source: uncrustify
> Version: 0.69.0+dfsg1-1
> Severity: serious
> Control: close -1 0.71.0+dfsg1-1
> Tags: sid bullseye
> User: release.debian@packages.debian.org
> Usertags: out-of-sync

The give-back I triggered built on armhf, so it should migrate in due
course.

I wonder how often a give-back helps, and if it is worth considering
triggering a give-back before filing the bug.

d


signature.asc
Description: PGP signature

Bug#972637: finch: crashes on startup with "illegal instruction"

[Karsten Hilbert]

On Mon, Oct 26, 2020 at 11:04:42PM +0100, Bernhard Übelacker wrote:

> From wikipedia [1] the pminud instruction at 0x...6fb got
> introduced with sse4.1 which seem not supported from your
> flags line (while on the other side intel says [2] it is a Penryn).

OTOH, apparently wikipedia knows better than Intel itself :-)

https://en.wikipedia.org/wiki/SSE4#Name_confusion

> (Might there be a bios switch?)

Unfortunately not.

Karsten

> [2] 
> https://ark.intel.com/content/www/de/de/ark/products/37253/intel-pentium-processor-t4300-1m-cache-2-10-ghz-800-mhz-fsb.html
--
GPG  40BE 5B0E C98E 1713 AFA6  5BC0 3BEA AC80 7D4F C89B

Bug#685506: debian-policy: Please add field Files-Excluded to machine readable copyright files definition

[Sean Whitton]

Hello,

On Sun 25 Oct 2020 at 09:40PM -04, Joe Nahmias wrote:

> Is this truly the case that all that's needed is a new patch? Can we get
> an official ACK from one of the policy editors? I'd be happy to re-write
> the original patch to apply against HEAD if that's all that is required.

Well, it would need seconding, but otherwise, ACK.

Thank you for your interest.

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#968204: Removal of packges which depend on GTK2

[Sean Whitton]

Hello,

On Mon 26 Oct 2020 at 08:59PM +01, Pál Tamás Ács wrote:

>>
>> Can you please take your conspiracy theories, mis-information and
>> top-posting elsewhere, like /dev/null? Thanks.
>
>
> I'm not sure where exactly my statements were conspiracy theories or
> mis-information. Or you just don't like my opinion because it's kind of
> different from the mainstream that you're used to?
>
> Please point out one or more of my statements that you think is false.

I don't think this removal bug report is really an appropriate place for
a wide-ranging discussion like this.  In the interests of efficiency,
I'd be grateful if both of you could take it elsewhere.  Thank you!

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#968204: Removal of packges which depend on GTK2

[Sean Whitton]

Hello,

On Sun 25 Oct 2020 at 11:43AM GMT, Simon McVittie wrote:

> On Sat, 10 Oct 2020 at 09:11:23 -0700, Sean Whitton wrote:
>> Hello GNOME team,
>
> Note that pkg-gnome-maintainers receives bugmail etc. for the entire
> GNOME suite, and most (all?) GNOME maintainers aren't subscribed to that
> particular fire hose (we get bug mail for packages of interest, or for
> all GNOME packages, via tracker.debian.org instead). Our discussion list
> is debian-gtk-gnome; I only saw this because I happened to follow the
> link on a removal notification for one of the GTK2 mass-bug-filing mails.

Ah sorry about that.

Thank you for a useful reply.

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#972969: openafs-modules-dkms: Does not build on bullseye with kernel 5.9.1

[Robert Senger]

Package: openafs-modules-dkms
Version: 1.8.6-3
Severity: serious
Tags: ftbfs
Justification: fails to build from source (but built successfully in the past)

DKMS fails to build module on bullseye with kernel 5.9.1



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

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

Versions of packages openafs-modules-dkms depends on:
ii  dkms   2.8.3-4
ii  libc6-dev  2.31-4
ii  perl   5.30.3-4

Versions of packages openafs-modules-dkms recommends:
ii  openafs-client  1.8.6-3

openafs-modules-dkms suggests no packages.

-- no debconf information
DKMS make.log for openafs-1.8.6 for kernel 5.9.1-sandybridge (x86_64)
Mo 26. Okt 04:36:10 CET 2020
checking for gcc... gcc
checking whether the C compiler works... yes
checking for C compiler default output file name... a.out
checking for suffix of executables... 
checking whether we are cross compiling... no
checking for suffix of object files... o
checking whether we are using the GNU C compiler... yes
checking whether gcc accepts -g... yes
checking for gcc option to accept ISO C89... none needed
checking build system type... x86_64-pc-linux-gnu
checking host system type... x86_64-pc-linux-gnu
checking how to run the C preprocessor... gcc -E
checking for grep that handles long lines and -e... /bin/grep
checking for egrep... /bin/grep -E
checking for ANSI C header files... yes
checking for sys/types.h... yes
checking for sys/stat.h... yes
checking for stdlib.h... yes
checking for string.h... yes
checking for memory.h... yes
checking for strings.h... yes
checking for inttypes.h... yes
checking for stdint.h... yes
checking for unistd.h... yes
checking for a BSD-compatible install... /usr/bin/install -c
checking for flex... flex
checking lex output file root... lex.yy
checking lex library... none needed
checking whether yytext is a pointer... no
checking for pkg-config... /usr/bin/pkg-config
checking pkg-config is at least version 0.9.0... yes
checking for libxslt... no
checking for saxon... no
checking for xalan-j... no
checking for xsltproc... xsltproc
checking for fop... no
checking for dblatex... no
checking for docbook2pdf... no
checking for kindlegen... no
checking for doxygen... no
checking for dot... no
checking for library containing strerror... none required
checking for pid_t... yes
checking for size_t... yes
checking whether ln -s works... yes
checking for ranlib... ranlib
checking for bison... no
checking for byacc... no
checking if lex is flex... yes
checking whether byte order is known at compile time... yes
checking whether byte ordering is bigendian... no
checking whether printf understands the %z length modifier... yes
checking your OS... linux
checking your AFS sysname... amd64_linux26
checking for ranlib... (cached) ranlib
checking for as... as
checking for mv... mv
checking for rm... rm
checking for ld... ld
checking for cp... cp
checking for gencat... gencat
checking if gcc accepts -march=pentium... no
checking if gcc needs -fno-strength-reduce... yes
checking if gcc needs -fno-strict-aliasing... yes
checking if gcc supports -fno-common... yes
checking if gcc supports -pipe... yes
checking if linux kbuild requires EXTRA_CFLAGS... no
checking if linux kernel module build works... yes
checking operation follow_link in inode_operations... no
checking operation put_link in inode_operations... no
checking operation rename in inode_operations... yes
checking for linux/cred.h... yes
checking for linux/config.h... no
checking for linux/exportfs.h... yes
checking for linux/freezer.h... yes
checking for linux/key-type.h... yes
checking for linux/semaphore.h... yes
checking for linux/seq_file.h... yes
checking for linux/sched/signal.h... yes
checking for linux/uaccess.h... yes
checking for struct vfs_path... no
checking for kuid_t... yes
checking for struct proc_ops... yes
checking for time_t... no
checking for backing_dev_info in struct address_space... no
checking for write_begin in struct address_space_operations... yes
checking for name in struct backing_dev_info... no
checking for session_keyring in struct cred... yes
checking for ctl_name in struct ctl_table... no
checking for d_u.d_alias in struct dentry... yes
checking for d_automount in struct dentry_operations... yes
checking for gid in struct group_info... yes
checking for i_alloc_sem in struct inode... no
checking for i_blkbits in struct inode... yes
checking for i_blksize in struct inode... no
checking for i_mutex in struct inode... no
checking for i_security in struct inode... yes
checking for f_path in struct file... yes
checking for flock in struct file_operations... yes
checking for iterate in struct file_operations... 

Bug#966373: general: Higher version for uploads to stable and oldstable distributions

[Javier Serrano Polo]

On Mon, 19 Oct 2020 12:33:09 +0200 Julien Cristau 
wrote:
> tags 966373 + wontfix
> close 966373

Another closure, this time without excuse. It is obviously a mistake,
because Debian derivatives are welcome, right? I will correct this.

Adam D. Barratt did not answer my previous questions, thus she needs
more time.

smime.p7s
Description: S/MIME cryptographic signature

Bug#957270: getdp: diff for NMU version 3.2.0+dfsg1-1.1

[Adrian Bunk]

Control: tags 957270 + patch
Control: tags 957270 + pending

Dear maintainer,

I've prepared an NMU for getdp (versioned as 3.2.0+dfsg1-1.1) and 
uploaded it to DELAYED/2. Please feel free to tell me if I should cancel it.

cu
Adrian
diff -Nru getdp-3.2.0+dfsg1/debian/changelog getdp-3.2.0+dfsg1/debian/changelog
--- getdp-3.2.0+dfsg1/debian/changelog	2019-12-21 05:56:13.0 +0200
+++ getdp-3.2.0+dfsg1/debian/changelog	2020-10-26 21:06:45.0 +0200
@@ -1,3 +1,10 @@
+getdp (3.2.0+dfsg1-1.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Backport upstream fix for FTBFS with gcc 10. (Closes: #957270)
+
+ -- Adrian Bunk   Mon, 26 Oct 2020 21:06:45 +0200
+
 getdp (3.2.0+dfsg1-1) unstable; urgency=medium
 
   * Team upload.
diff -Nru getdp-3.2.0+dfsg1/debian/patches/0001-fix-compilation-with-gcc-10-fixes-61.patch getdp-3.2.0+dfsg1/debian/patches/0001-fix-compilation-with-gcc-10-fixes-61.patch
--- getdp-3.2.0+dfsg1/debian/patches/0001-fix-compilation-with-gcc-10-fixes-61.patch	1970-01-01 02:00:00.0 +0200
+++ getdp-3.2.0+dfsg1/debian/patches/0001-fix-compilation-with-gcc-10-fixes-61.patch	2020-10-26 21:05:50.0 +0200
@@ -0,0 +1,25 @@
+From 634d0ea771f781c9b59af075658587c3924309a8 Mon Sep 17 00:00:00 2001
+From: Christophe Geuzaine 
+Date: Sun, 3 May 2020 18:54:04 +0200
+Subject: fix compilation with gcc 10 (fixes #61)
+
+---
+ contrib/Sparskit/inout.f | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/contrib/Sparskit/inout.f b/contrib/Sparskit/inout.f
+index cde38577..4c87151f 100644
+--- a/contrib/Sparskit/inout.f
 b/contrib/Sparskit/inout.f
+@@ -1,7 +1,7 @@
+ c $Id: inout.f,v 1.1 2008-04-11 06:01:06 geuzaine Exp $
+ c--c
+   subroutine psplot (ncol,ja,ia,iunt,mode)
+-  integer ja(*),ia(*),iunt,ncol,id,mode
++  integer ja(*),ia(*),iunt,ncol,id(0),mode
+   call pspltm (ncol, ncol, mode, ja, ia, ' ',
+  & 0, 5.0, "in", 0, id, iunt)
+   return
+-- 
+2.20.1
+
diff -Nru getdp-3.2.0+dfsg1/debian/patches/series getdp-3.2.0+dfsg1/debian/patches/series
--- getdp-3.2.0+dfsg1/debian/patches/series	2019-12-21 05:56:13.0 +0200
+++ getdp-3.2.0+dfsg1/debian/patches/series	2020-10-26 21:06:42.0 +0200
@@ -2,4 +2,5 @@
 localise_toplevel_htmldoc.patch
 link_fortran.patch
 petsc-dev-5f171b22.patch
+0001-fix-compilation-with-gcc-10-fixes-61.patch
 

Bug#972991: RFA: ttf-ancient-fonts -- Unicode Fonts for Ancient Scripts

[Gürkan Myczko]

Package: wnpp
Severity: normal

I request an adopter for the ttf-ancient-fonts package.

Be aware about these bugs though:
https://bugs.debian.org/cgi-bin/pkgreport.cgi?src=ttf-ancient-fonts

As this is team-maintained by the Fonts team, it
mostly needs a new uploader who feels responsible for it.

Kind regards,
Gürkan Myczko

Bug#972512:

[Sudip Mukherjee]

Control: unblock -1 by 972790
--

Unblocking as the patch to remove python-rfc6555 dependency has been
ported from offlineimap. The dependency can be added later.

--
Regards
Sudip

Bug#854973: lists.debian.org: Create debian-banned

[Javier Serrano Polo]

Control: reopen -1

El dg 18 de 10 de 2020 a les 22:40 +0200, Javier Serrano Polo va
escriure:
> Otherwise, I will reopen this report.

Reopening.

smime.p7s
Description: S/MIME cryptographic signature

Bug#972990: O: geotranz -- GEOgraphic coordinates TRANslator

[Gürkan Myczko]

Package: wnpp
Severity: normal

I intend to orphan the geotranz package.

Upstream has a 3.8 version, the reason I took over it because it was 
outdated at 3.3, and some user wanted a newer version so there was it. 
It's not on salsa.debian.net yet.


The reason is I've got plenty other packages to take care of, and I'm 
not using

geotranz.

Bug#972989: O: dablin -- CLI and GTK+ GUI DAB & DAB+ receiver client

[Gürkan Myczko]

Package: wnpp
Severity: normal

I intend to orphan the dablin package.

Upstream is active, however I started packaging dablin before I found 
welle.io, and in favour of that I'm not using dablin. It's not on 
salsa.debian.net yet.


The reason is I've got plenty other packages to take care of, and I'm 
not using

dablin.

Bug#837723: Removing/Disabling the general psuedo package; refering to debian-u...@lists.debian.org

[Javier Serrano Polo]

On Sat, 24 Oct 2020 11:53:44 +0800 Paul Wise  wrote:
> # It is not up to people who are not submitters or BTS admins to
determine the outcome for this bug

What do you mean? Are you the submitter? No, you refused to be. Are you
a BTS admin? No, you are not listed as a member. You determine the
outcome, thus you do not follow your own guideline.

I am trying to solve a bug, you are sabotaging this effort. So, either
give a solution to this bug or let the submitter or BTS admins reply.
Otherwise, I will tag this report as wontfix again and, if you undo
this action, I may submit a complaint.

smime.p7s
Description: S/MIME cryptographic signature

Bug#972988: lookatme: CVE-2020-15271

[Salvatore Bonaccorso]

Source: lookatme
Version: 1.2.0-1
Severity: grave
Tags: security upstream
Justification: user security hole
X-Debbugs-Cc: car...@debian.org, Debian Security Team 

Hi,

The following vulnerability was published for lookatme.

CVE-2020-15271[0]:
| In lookatme (python/pypi package) versions prior to 2.3.0, the package
| automatically loaded the built-in "terminal" and "file_loader"
| extensions. Users that use lookatme to render untrusted markdown may
| have malicious shell commands automatically run on their system. This
| is fixed in version 2.3.0. As a workaround, the
| `lookatme/contrib/terminal.py` and `lookatme/contrib/file_loader.py`
| files may be manually deleted. Additionally, it is always recommended
| to be aware of what is being rendered with lookatme.


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

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2020-15271
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-15271
[1] 
https://github.com/d0c-s4vage/lookatme/security/advisories/GHSA-c84h-w6cr-5v8q
[2] 
https://github.com/d0c-s4vage/lookatme/commit/72fe36b784b234548d49dae60b840c37f0eb8d84
[3] https://github.com/d0c-s4vage/lookatme/pull/110

Regards,
Salvatore

Bug#972987: O: toxic -- curses Tox based instant messenging client

[Gürkan Myczko]

Package: wnpp
Severity: normal

I intend to orphan the toxic package.

I had prepared a last new upstream package at 
https://mentors.debian.net/package/toxic/

It's not on salsa.debian.net yet.

The reason is I've got plenty other packages to take care of, and I'm 
not using

toxic.

Bug#972637: finch: crashes on startup with "illegal instruction"

[Karsten Hilbert]

Hello Bernhard,

thanks for your work.

I have (also) filed a bug against intel-media-va-driver which
was invovked from VLC. They have forwarded the issue upstream:

https://github.com/intel/libva/issues/466

My CPU is Penryn, so it supports "less" SSE than what's
attempted to be used by the VA driver at which point the
SIGILL occurrs.

> Therefore it would be interesting to know with which CPU you
> are getting this SIGILL (e.g. 'lscpu' or 'cat /proc/cpuinfo').

processor   : 0
vendor_id   : GenuineIntel
cpu family  : 6
model   : 23
model name  : Pentium(R) Dual-Core CPU   T4300  @ 2.10GHz
stepping: 10
microcode   : 0xa0b
cpu MHz : 1545.084
cache size  : 1024 KB
physical id : 0
siblings: 2
core id : 0
cpu cores   : 2
apicid  : 0
initial apicid  : 0
fdiv_bug: no
f00f_bug: no
coma_bug: no
fpu : yes
fpu_exception   : yes
cpuid level : 13
wp  : yes
flags   : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov 
pat pse36 clflush dts acpi mmx fxsr sse sse2 ht tm pbe nx lm constant_tsc 
arch_perfmon pebs bts cpuid aperfmperf pni dtes64 monitor ds_cpl est tm2 ssse3 
cx16 xtpr pdcm xsave lahf_lm dtherm
bugs: cpu_meltdown spectre_v1 spectre_v2 spec_store_bypass l1tf mds 
swapgs itlb_multihit
bogomips: 4189.35
clflush size: 64
cache_alignment : 64
address sizes   : 36 bits physical, 48 bits virtual
power management:

> Otherwise finch seems not to depend directly from intel-media-va-driver,

Yeah, I certainly wondered about that, too, it being a console app.

> and from the package description if your CPU is older than "Broadwell",
> then you might even not benefit from this package. Therefore a
> workaround might be to uninstall intel-media-va-driver if no
> other dependencies require it?

Other deps do (see vlc above).

The stranger thing is that running vlc from either an xterm
or the desktop environment fails, while clvc only fails when
running under X and does not fail on the console.

Karsten
--
GPG  40BE 5B0E C98E 1713 AFA6  5BC0 3BEA AC80 7D4F C89B

Bug#972974: [Pkg-clamav-devel] Bug#972974: clamav-freshclam start faild.

[Sebastian Andrzej Siewior]

On 2020-10-26 19:02:58 [+0100], Michael Borgelt wrote:
> clamav-freshclam start faild with:
> Okt 26 18:44:41 host freshclam[31527]: ERROR: initialize: libfreshclam init
> failed.
> Okt 26 18:44:41 host freshclam[31527]: ERROR: Initialization error!
> Okt 26 18:44:41 bert freshclam[31527]: ERROR: Can't open
> /var/log/clamav/freshclam.log in append mode (check permissions!).
> Okt 26 18:44:41 host systemd[1]: clamav-freshclam.service: Main process 
> exited,
> code=exited, status=2/INVALIDARGUMENT
> Okt 26 18:44:41 host systemd[1]: clamav-freshclam.service: Failed with result
> 'exit-code'.
> 
> clamav-freshcalm was installed for the first time on this host.

Could you please tell the permissions for
/var/log/clamav/
/var/log/clamav/freshclam.log
?

Sebastian

Bug#972986: motion: CVE-2020-26566

[Salvatore Bonaccorso]

Source: motion
Version: 4.2.2-1
Severity: important
Tags: security upstream
X-Debbugs-Cc: car...@debian.org, Debian Security Team 

Hi,

The following vulnerability was published for motion.

CVE-2020-26566[0]:
| A Denial of Service condition in Motion-Project Motion 3.2 through
| 4.3.1 allows remote unauthenticated users to cause a webu.c
| segmentation fault and kill the main process via a crafted HTTP
| request.


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

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2020-26566
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-26566
[1] https://github.com/Motion-Project/motion/issues/1227#issuecomment-715927776
[2] https://github.com/Motion-Project/motion/pull/1232

Regards,
Salvatore

Bug#972985: snmp: Blumenthal AES encryption should be enabled by default

[Owen Evans]

Package: snmp
Version: 5.9+dfsg-3-silo
Severity: wishlist
X-Debbugs-Cc: oev...@sciencelogic.com

Dear Maintainer,

This is my first Debian issue report.

Blumenthal AES, in spite of being a 'draft' part of the SNMP Standard,
is becoming widely implemented by many vendors. It is the main way to
have strong encryption in connection with SNMPv3. Debian should include
the --enable-blumenthal-aes option added around line 53 of debian/rules
so that it is used when invoking the ./configure script from the
upstream source package.

My organization is patching the rules and building our own binaries in
order to enable this configuration, but I think this change would be
useful to the community at large too.

I would submit a patch myself but I can't easily figure out where/how to
do this.

Regards,
Owen Evans
ScienceLogic, Inc


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

Kernel: Linux 4.15.0-91-generic (SMP w/4 CPU threads)
Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: unable to detect

Versions of packages snmp depends on:
ii  libc6 2.31-4
ii  libsnmp-base  5.9+dfsg-3-silo
ii  libsnmp40 5.9+dfsg-3-silo
ii  libssl1.1 1.1.1d-0+deb10u3

Versions of packages snmp recommends:
ii  perl  5.30.3-4

snmp suggests no packages.

-- no debconf information

Bug#951508: lmod: broken on all architectures except x86_64 (wrong search path)

[Aaron Zauner]

Hey,

Thanks for working this out guys! I think arch:all is a good solution
having the Lua paths fixed upstream.

Aaron

On Mon, Oct 26, 2020 at 1:45 PM Lucas Nussbaum  wrote:

> Hi,
>
> On 26/10/20 at 11:19 +0100, Baptiste Jonglez wrote:
> > Hi,
> >
> > On Tue, 15 Sep 2020 12:32:34 +0200 "Aaron Zauner (azet)" 
> wrote:
> > > If anyone wants to take over I'm more than fine with that. The amount
> of work I have at the moment barely permits me from maintaining projects.
> It's most sensible that someone actively using this project on Debian
> maintains it, as is, I'm not using it much anymore and am not working in
> HPC at the moment. The bug should definitely reported upstream. Upgrading
> the package should be fairly simple though - the dependencies are already
> in place, as are simple tests/git integration etc.:
> https://github.com/azet/lmod-deb
> >
> > I had a look, and it seems to be an upstream "feature" that was
> introduced
> > between lmod 6.2 and lmod 6.3.
> >
> > The root cause is that the configure script uses the build-time paths
> from
> > lua, and then uses these paths at runtime.  The upstream changelog for
> 6.3
> > states:
> >
> > > Lmod now uses the values of LUA_PATH and LUA_CPATH at configuration
> > > time.  This way Lmod is safe from user changes to these important Lua
> > > values.
> >
> > The corresponding upstream change and discussion:
> https://github.com/TACC/Lmod/issues/112
> >
> > This was already reported for ARM and closed:
> https://github.com/TACC/Lmod/issues/338
> >
> > Overall, I think the simplest solution is to change the architecture to
> "any".
>
> Thanks Baptiste for the investigation.
> I've just uploaded an NMU to unstable, and will also upload a fix to
> stable.
>
> I also opened an RFA bug for this package to reflect the current
> situation (#972938).
>
> - Lucas
>

Bug#972984: ITP: nemo-media-columns -- Nemo Extension to display music/EXIF and PDF metadata

[Joshua Peisach]

Package: wnpp
Severity: wishlist
Owner: Joshua Peisach 
X-Debbugs-Cc: debian-de...@lists.debian.org, itzswirlz2...@outlook.com

* Package name: nemo-media-columns
  Version : 4.6.0
  Upstream Author : Clement Lefebvre 
* URL : https://github.com/linuxmint/nemo-
extensions/tree/master/nemo-media-columns
* License : GPL-3+
  Programming Lang: Python
  Description : Nemo Extension to display music/EXIF and PDF metadata

A Nemo extension to display music/EXIF and PDF metadata info
in the Nemo List View.

This package enhances the Nemo file manager.
I will maintain this by myself before I hopefully get it into cinnamon-team.

Bug#972954: notmuch-slurp-this-debbug should detect subscription emails

[Sean Whitton]

Hello,

On Mon 26 Oct 2020 at 11:06AM -04, Antoine Beaupre wrote:

> I still use "bts subscribe #12345" to subscribe to BTS bugs, which
> works great in my workflow. Sometimes -- but not always! -- I also
> like to have a copy of those emails in my inbox. So then I naturally
> head for the confirmation email, which looks something like:
>
> From: 942853-subh...@bugs.debian.org
> Subject: Please confirm subscription to 942...@bugs.debian.org (ITP: 
> [...])
>
> and type:
>
> M-x notmuch-slurp-this-debbug
>
> ... but nothing happens. I would have expected that function to detect
> the bug number in the confirmation email and download the bug report,
> as if I would have ran `(notmuch-slurp-debbug #942853)`.
>
> This is the reverse of #928435.

Yes, I think this would be a good idea.  Patches welcome.

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#972974: strace

[Michael Borgelt]

Additional strace output:

lchown("/var/log/clamav/freshclam.log", 133, 147) = -1 EPERM  
(Operation not permitted)
write(2, "ERROR: lchown to user 'clamav' f"..., 41ERROR: lchown to  
user 'clamav' failed on

) = 41
write(2, "log file '/var/log/clamav/freshc"..., 42log file  
'/var/log/clamav/freshclam.log'.

) = 42
write(2, "Error was 'Operation not permitt"..., 36Error was 'Operation  
not permitted'

) = 36
stat("/var/log/clamav/freshclam.log", {st_mode=S_IFREG|0666,  
st_size=922, ...}) = 0

write(3, "Mon Oct 26 19:13:10 2020 -> WARN"..., 150) = 150
fstat(1, {st_mode=S_IFCHR|0600, st_rdev=makedev(0x88, 0x6), ...}) = 0
write(1, "Mon Oct 26 19:13:10 2020 -> ^lch"..., 142Mon Oct 26 19:13:10  
2020 -> ^lchown to user 'clamav' failed
on log file '/var/log/clamav/freshclam.log'.  Error was 'Operation not  
permitted'

) = 142
stat("/var/log/clamav/freshclam.log", {st_mode=S_IFREG|0666,  
st_size=1072, ...}) = 0

write(3, "Mon Oct 26 19:13:10 2020 -> ERRO"..., 68) = 68
write(1, "Mon Oct 26 19:13:10 2020 -> !Fai"..., 62Mon Oct 26 19:13:10  
2020 -> !Failed to switch to clamav user

.
) = 62
close(3)    = 0
chmod("/var/lib/clamav/tmp.816a2126be", 0700) = -1 ENOENT (No such  
file or directory)
openat(AT_FDCWD, "/var/lib/clamav/tmp.816a2126be",  
O_RDONLY|O_NONBLOCK|O_CLOEXEC|O_DIRECTORY) = -1 ENOENT (No

such file or directory)
exit_group(9)   = ?
+++ exited with 9 +++
 MICHAEL BORGELTe-mail: mich...@borgelt.org

Bug#972983: python-ete3: autopkgtest regression: No module named 'numpy'

[Paul Gevers]

Source: python-ete3
Version: 3.1.2+dfsg-1
X-Debbugs-CC: debian...@lists.debian.org
Severity: serious
User: debian...@lists.debian.org
Usertags: regression

Dear maintainer(s),

With a recent upload of python-ete3 the autopkgtest of python-ete3 fails
in testing when that autopkgtest is run with the binary packages of
python-ete3 from unstable. It passes when run with only packages from
testing. In tabular form:

   passfail
python-ete3from testing3.1.2+dfsg-1
all others from testingfrom testing

I copied some of the output at the bottom of this report.

Currently this regression is blocking the migration to testing [1]. Can
you please investigate the situation and fix it?

More information about this bug and the reason for filing it can be found on
https://wiki.debian.org/ContinuousIntegration/RegressionEmailInformation

Paul

[1] https://qa.debian.org/excuses.php?package=python-ete3

https://ci.debian.net/data/autopkgtest/testing/amd64/p/python-ete3/7751730/log.gz

autopkgtest [09:29:16]: test autodep8-python3: set -e ; for py in
$(py3versions -r 2>/dev/null) ; do cd "$AUTOPKGTEST_TMP" ; echo "Testing
with $py:" ; $py -c "import ete3; print(ete3)" ; done
autopkgtest [09:29:16]: test autodep8-python3: [---
Testing with python3.8:
Traceback (most recent call last):
  File "", line 1, in 
  File "/usr/lib/python3/dist-packages/ete3/__init__.py", line 55, in

from .evol.evoltree import *
  File "/usr/lib/python3/dist-packages/ete3/evol/__init__.py", line 54,
in 
from .evoltreeimport *
  File "/usr/lib/python3/dist-packages/ete3/evol/evoltree.py", line 83,
in 
from .utils import translate
  File "/usr/lib/python3/dist-packages/ete3/evol/utils.py", line 45, in

from numpy import floor, pi as PI, sin
ModuleNotFoundError: No module named 'numpy'



signature.asc
Description: OpenPGP digital signature

Bug#860300: lircmd does not work

[Alec Leamas]

On Wed, 28 Jun 2017 10:53:12 +0200 Alec Leamas 
wrote:
> On Wed, 21 Jun 2017 09:44:28 +0200 Alec Leamas  
> wrote:
>  > This is tracked in upstream bug 
> https://sourceforge.net/p/lirc/tickets/295/
>  >
>  > --alec
> 
> 
> Fixed upstream and in experimental. Thanks for reporting and debugging!
> 

And in 0.10.0, closing

Bug#972637: finch: crashes on startup with "illegal instruction"

[Bernhard Übelacker]

Hello Karsten,
I tried to collect some more information for the maintainer and
could reproduce this (or nearly) the same SIGILL with a qemu VM limited
to a pentium class CPU.

The instruction in question might these below:

   0xb78816bb <+75>:movd   0x4(%esi),%xmm2 (here I received the SIGILL)
   0xb78816fb <+139>:   pminud %xmm2,%xmm3 (thats from your backtrace 
the similar address offset 0x...6fb)

Both access a register xmm2/xmm3 which seems to be "just"
available on CPUs having the SSE extension.

Therefore it would be interesting to know with which CPU you
are getting this SIGILL (e.g. 'lscpu' or 'cat /proc/cpuinfo').

Otherwise finch seems not to depend directly from intel-media-va-driver,
and from the package description if your CPU is older than "Broadwell",
then you might even not benefit from this package. Therefore a
workaround might be to uninstall intel-media-va-driver if no
other dependencies require it?

Kind regards,
Bernhard


# Bullseye/testing i386 qemu VM 2020-10-26 (with -cpu pentium)


apt update
apt dist-upgrade


apt install systemd-coredump mc htop psmisc net-tools strace gdb 
intel-media-va-driver intel-media-va-driver-dbgsym coreutils-dbgsym


gdb -q
set width 0
set pagination off
file /bin/ls
b main
run

#b call_init
call __dlopen("/usr/lib/i386-linux-gnu/dri/iHD_drv_video.so", 4354)
bt
disassemble

0xb78816b9













benutzer@debian:~$ gdb -q
(gdb) set width 0
(gdb) set pagination off
(gdb) file /bin/ls
Reading symbols from /bin/ls...
Reading symbols from 
/usr/lib/debug/.build-id/00/695414aa5413c8667e62c2362d119cb233a504.debug...
(gdb) b main
Breakpoint 1 at 0x2770: file src/ls.c, line 1622.
(gdb) run
Starting program: /bin/ls 
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/i386-linux-gnu/libthread_db.so.1".

Breakpoint 1, main (argc=1, argv=0xb744) at src/ls.c:1622
1622src/ls.c: Datei oder Verzeichnis nicht gefunden.
(gdb) call __dlopen("/usr/lib/i386-linux-gnu/dri/iHD_drv_video.so", 4354)

Program received signal SIGILL, Illegal instruction.
std::__cxx11::basic_string, std::allocator 
>::basic_string (__str=..., this=0x42fc50) at 
/usr/include/c++/10/bits/basic_string.h:569
569 /usr/include/c++/10/bits/basic_string.h: Datei oder Verzeichnis nicht 
gefunden.
The program being debugged was signaled while in a function called from GDB.
GDB remains in the frame where the signal was received.
To change this behavior use "set unwindonsignal on".
Evaluation of the expression containing the function
(__dlopen) will be abandoned.
When the function is done executing, GDB will silently stop.
(gdb) bt
#0  std::__cxx11::basic_string, 
std::allocator >::basic_string (__str=..., this=0x42fc50) at 
/usr/include/c++/10/bits/basic_string.h:569
#1  std::pair, 
std::allocator > const, DdiMediaDecode* 
(*)(DDI_DECODE_CONFIG_ATTR*)>::pair, std::allocator >, DdiMediaDecode* 
(*)(DDI_DECODE_CONFIG_ATTR*), true> (__p=..., this=0x42fc50) at 
/usr/include/c++/10/bits/stl_pair.h:373
#2  
__gnu_cxx::new_allocator, std::allocator > const, DdiMediaDecode* 
(*)(DDI_DECODE_CONFIG_ATTR*)> > 
>::construct, 
std::allocator > const, DdiMediaDecode* (*)(DDI_DECODE_CONFIG_ATTR*)>, 
std::pair, 
std::allocator >, DdiMediaDecode* (*)(DDI_DECODE_CONFIG_ATTR*)> > 
(this=0xb7ceb8b0 ::GetCreators[abi:cxx11]()::creators>, __p=0x42fc50) at 
/usr/include/c++/10/ext/new_allocator.h:150
#3  
__gnu_cxx::new_allocator, std::allocator > const, DdiMediaDecode* 
(*)(DDI_DECODE_CONFIG_ATTR*)> > 
>::construct, 
std::allocator > const, DdiMediaDecode* (*)(DDI_DECODE_CONFIG_ATTR*)>, 
std::pair, 
std::allocator >, DdiMediaDecode* (*)(DDI_DECODE_CONFIG_ATTR*)> > 
(__p=0x42fc50, this=0xb7ceb8b0 ::GetCreators[abi:cxx11]()::creators>) at 
/usr/include/c++/10/ext/new_allocator.h:148
#4  
std::allocator_traits, std::allocator > const, DdiMediaDecode* 
(*)(DDI_DECODE_CONFIG_ATTR*)> > > 
>::construct, 
std::allocator > const, DdiMediaDecode* (*)(DDI_DECODE_CONFIG_ATTR*)>, 
std::pair, 
std::allocator >, DdiMediaDecode* (*)(DDI_DECODE_CONFIG_ATTR*)> > 
(__p=0x42fc50, __a=...) at /usr/include/c++/10/bits/alloc_traits.h:512
#5  std::_Rb_tree, 
std::allocator >, std::pair, std::allocator > const, DdiMediaDecode* 
(*)(DDI_DECODE_CONFIG_ATTR*)>, 
std::_Select1st, std::allocator > const, DdiMediaDecode* 
(*)(DDI_DECODE_CONFIG_ATTR*)> >, std::less, std::allocator > >, 
std::allocator, std::allocator > const, DdiMediaDecode* 
(*)(DDI_DECODE_CONFIG_ATTR*)> > 
>::_M_construct_node, std::allocator >, DdiMediaDecode* 
(*)(DDI_DECODE_CONFIG_ATTR*)> > (__node=0x42fc40, this=0xb7ceb8b0 
::GetCreators[abi:cxx11]()::creators>) at 
/usr/include/c++/10/bits/stl_tree.h:618
#6  std::_Rb_tree, 
std::allocator >, std::pair, std::allocator > const, DdiMediaDecode* 
(*)(DDI_DECODE_CONFIG_ATTR*)>, 
std::_Select1st, std::allocator > const, DdiMediaDecode* 
(*)(DDI_DECODE_CONFIG_ATTR*)> >, std::less, std::allocator > >, 
std::allocator, std::allocator > const, DdiMediaDecode* 

Bug#968204: Removal of packges which depend on GTK2

[Pál Tamás Ács]

>
> Can you please take your conspiracy theories, mis-information and
> top-posting elsewhere, like /dev/null? Thanks.


I'm not sure where exactly my statements were conspiracy theories or
mis-information. Or you just don't like my opinion because it's kind of
different from the mainstream that you're used to?

Please point out one or more of my statements that you think is false.

On Sun, Oct 25, 2020 at 10:42 PM Michael Gratton  wrote:

>
> On 26 October 2020 01:06:59 Pál Tamás Ács  wrote:
>
>> Technically, Gtk2 and Gtk3 are two different toolkits with a similar
>> name. It's a completely different thing that Red Hat is trying to make us
>> believe that GTK3 is an improved successor of GTK2. It isn't. It never has
>> been.
>>
>> GTK3 has been very much unstable, full of API breaks and annoyances from
>> the get-go. It's slower due to CPU bloat under certain circumstances, eats
>> up more RAM and is suffering from a serious UX dumbing down to the level of
>> consumer devices like smartphones thus being made less suitable for
>> desktop. Anti-features like mandatory recursive search
>>  in File Dialog have
>> also been introduced.
>>
>> GTK3 was marked stable in many distros despite it wasn't stable at all.
>> Software creators and package maintainers didn't want to migrate to a
>> poorly designed, underdeveloped, buggy graphical toolkit. They either moved
>> forward to Qt or stayed with Gtk2. A famous precedent case is the cancelled
>> GTK3 migration of Audacious. They went back to Gtk2 then moved forward
>> toward Qt.
>>
>> There must be a cooperation among Linux maintainters outside of Red Hat
>> to save Gtk2 and provide security updates and some critical bug fixes on
>> the maintainer level
>>
>
> Can you please take your conspiracy theories, mis-information and
> top-posting elsewhere, like /dev/null? Thanks.
>
> — Mike
>
>

Bug#972952: [Pkg-javascript-devel] Bug#972952: Bug#972952: node-mkdirp 1.0 is incompatible with 0.5, breaks yarnpkg

[Paolo Greppi]

Hi Xavier,

Il 26/10/20 20:24, Xavier ha scritto:

Le 26/10/2020 à 15:28, ano...@users.sourceforge.net a écrit :

   ...


Hi JS Team,

yarnpkg is not in testing due to babel problems. Do you agree to
dicrease severity of this bug to allow mkdirp transition (or reassign
this bug to node-yarnpkg) ?

Cheers,
Xavier



I think this should be reassigned to node-yarnpkg and then escalated to upstream
I volunteer to do the second part.

Paolo

Bug#890374: Aw: Re: bug in lirc - 'post' and 'pre' not sent

[Alec Leamas]

On Wed, 14 Feb 2018 14:02:55 +0100 Alec Leamas 
wrote:

> > Best regards
> >
> > Andreas
> >
> Thanks for filing. That said, I'm moving this bug upstream to
> https://sf.net/p/lirc/tickets/319/. In that bug I have also repeated my
> reply, which basically requests some feedback from you. Let's keep
> discussion in the upstream bug, it really belongs there.


I honestly don't know what to do here. But in any case, this is not a
packaging problem, it's an upstream one.  Leaving bug open for now.

Bug#972897: libavformat58: provide libavformat-extra package now?

[Fabian Greffrath]

control: tags -1 +patch
control: forwarded -1 
https://salsa.debian.org/multimedia-team/ffmpeg/-/merge_requests/6

Please review my merge request for a patch.

 - Fabian


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

Bug#972981: src:uncrustify: fails to migrate to testing for too long: FTBFS on armhf

[Paul Gevers]

Source: uncrustify
Version: 0.69.0+dfsg1-1
Severity: serious
Control: close -1 0.71.0+dfsg1-1
Tags: sid bullseye
User: release.debian@packages.debian.org
Usertags: out-of-sync

Dear maintainer(s),

As recently announced [1], the Release Team now considers packages that
are out-of-sync between testing and unstable for more than 60 days as
having a Release Critical bug in testing. Your package src:uncrustify in
its current version in unstable has been trying to migrate for 60 days
[2]. Hence, I am filing this bug.

If a package is out of sync between unstable and testing for a longer
period, this usually means that bugs in the package in testing cannot be
fixed via unstable. Additionally, blocked packages can have impact on
other packages, which makes preparing for the release more difficult.
Finally, it often exposes issues with the package and/or
its (reverse-)dependencies. We expect maintainers to fix issues that
hamper the migration of their package in a timely manner.

This bug will trigger auto-removal when appropriate. As with all new
bugs, there will be at least 30 days before the package is auto-removed.

I have immediately closed this bug with the version in unstable, so if
that version or a later version migrates, this bug will no longer affect
testing. I have also tagged this bug to only affect sid and bullseye, so
it doesn't affect (old-)stable.

If you believe your package is unable to migrate to testing due to
issues beyond your control, don't hesitate to contact the Release Team.

Paul

[1] https://lists.debian.org/debian-devel-announce/2020/02/msg5.html
[2] https://qa.debian.org/excuses.php?package=uncrustify




signature.asc
Description: OpenPGP digital signature

Bug#972980: mlocate not indexing cifs mounted by fstab

[GnuTurd]

Package: mlocate
Version: 0.26-3+b1

Severity: Normal

mlocate is not indexing files located on my local samba file server anymore in 
buster/testing.  cifs is excluded from PRUNEFS= in /etc/updatedb.conf. I 
switched to locate, which seems to be working properly.

Bug#860551: fixed in lirc 0.10.0~rc3-1

[Alec Leamas]

This bug is reopened without any further information. I'm closing it
again, assuming it was some kind of mistake. If not, please re-open and
add some info.

Bug#972952: [Pkg-javascript-devel] Bug#972952: node-mkdirp 1.0 is incompatible with 0.5, breaks yarnpkg

[Xavier]

Le 26/10/2020 à 15:28, ano...@users.sourceforge.net a écrit :
> Package: node-mkdirp
> Version: 1.0.4-2
> Severity: critical
> 
> I don't know whether to report this against node-mkdirp for breaking
> compatibility, or yarnpkg for depending on "node-mkdirp (>= 0.5.1)"
> rather than "node-mkdirp (>= 0.5.1), node-mkdirp (<<1.0.0)". Either way,
> things are currently broken in unstable and shouldn't migrate to
> testing.
> 
> I upgraded various packages this morning, and found that yarn would no
> longer work.
> 
>   $ yarn
>   yarn install v1.22.4
>   warning Skipping preferred cache folder "/home/redacted/.cache/yarn" 
> because it is not writable.
>   warning Skipping preferred cache folder "/tmp/.yarn-cache-1000" because it 
> is not writable.
>   warning Skipping preferred cache folder "/tmp/.yarn-cache" because it is 
> not writable.
>   error Yarn hasn't been able to find a cache folder it can use. Please use 
> the explicit --cache-folder option to tell it what location to use, or make 
> one of the preferred locations writable.
>   info Visit https://yarnpkg.com/en/docs/cli/install for documentation about 
> this command.
> 
> This turns out to be due to this error being thrown:
> 
>   TypeError: invalid options argument
> at optsArg (/usr/share/nodejs/mkdirp/lib/opts-arg.js:13:11)
> at mkdirp (/usr/share/nodejs/mkdirp/index.js:11:10)
> at /usr/share/nodejs/yarn/lib/util/promise.js:37:10
> at new Promise ()
> at /usr/share/nodejs/yarn/lib/util/promise.js:17:12
> at Object. (/usr/share/nodejs/yarn/lib/util/fs.js:1024:15)
> at Generator.throw ()
> at step 
> (/usr/share/nodejs/babel-runtime/helpers/asyncToGenerator.js:17:30)
> at /usr/share/nodejs/babel-runtime/helpers/asyncToGenerator.js:30:13
> 
> It turns out yarn is expecting node-mkdirp to accept a callback, which
> was apparently dropped in node-mkdirp 1.0 in favor of it returning a
> promise.
> 
> Downgrading node-mkdirp to 0.5.1-2 fixed it:
> 
>   $ yarn
>   yarn install v1.22.4
>   info No lockfile found.
>   [1/4] Resolving packages...
>   [2/4] Fetching packages...
>   [3/4] Linking dependencies...
>   [4/4] Building fresh packages...
>   success Saved lockfile.
>   Done in 0.07s.

Hi JS Team,

yarnpkg is not in testing due to babel problems. Do you agree to
dicrease severity of this bug to allow mkdirp transition (or reassign
this bug to node-yarnpkg) ?

Cheers,
Xavier

Bug#872985: [Pkg-lirc-maint] Bug#872985: [lirc] postinst of lirc fails if systemd is not installed

[Alec Leamas]

On Wed, 30 Aug 2017 14:34:47 +0200 Alec Leamas 
wrote:

> The package description for systemd-shim says: "This package emulates
> the systemd function that are required to run the systemd helpers
> without using the init service"
> 
> So, this looks more like a systemd-shim bug to me.
> 
> Thoughts?

The state of sysV init scripts is basically "patches welcome". And since
there is no patch, or even reply here I'm closing this bug.

--alec

Bug#972979: wims-lti: [INTL:nl] Dutch translation of debconf messages

[Frans Spiesschaert]

 
 
Package: wims-lti 
Severity: wishlist 
Tags: l10n patch 
 
 
 
Dear Maintainer, 
 
 
Please find attached the Dutch translation of wims-lti debconf
messages. 
It has been submitted for review to the debian-l10n-dutch mailing list. 
Please add it to your next package revision. 
It should be put as debian/po/nl.po in your package build tree. 
 

-- 
Kind regards,
Frans Spiesschaert



nl.po.gz
Description: application/gzip

Bug#957769: rotter: diff for NMU version 0.9-3.1

[Sudip Mukherjee]

Control: tags 957769 + patch
Control: tags 957769 + pending
--

Dear maintainer,

I've prepared an NMU for rotter (versioned as 0.9-3.1) and
uploaded it to DELAYED/2. Please feel free to tell me if I
should cancel it.

--
Regards
Sudip

diff -Nru rotter-0.9/debian/changelog rotter-0.9/debian/changelog
--- rotter-0.9/debian/changelog 2011-07-30 10:34:07.0 +0100
+++ rotter-0.9/debian/changelog 2020-10-26 19:17:58.0 +
@@ -1,3 +1,10 @@
+rotter (0.9-3.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix ftbfs with GCC-10. (Closes: #957769)
+
+ -- Sudip Mukherjee   Mon, 26 Oct 2020 19:17:58 
+
+
 rotter (0.9-3) unstable; urgency=low
 
   * Build against libmp3lame-dev.
diff -Nru rotter-0.9/debian/patches/fix_gcc-10.patch 
rotter-0.9/debian/patches/fix_gcc-10.patch
--- rotter-0.9/debian/patches/fix_gcc-10.patch  1970-01-01 01:00:00.0 
+0100
+++ rotter-0.9/debian/patches/fix_gcc-10.patch  2020-10-26 19:17:54.0 
+
@@ -0,0 +1,19 @@
+Description: Fix ftbfs with GCC-10
+
+Author: Sudip Mukherjee 
+Bug-Debian: https://bugs.debian.org/957769
+Forwarded: no
+
+---
+
+--- rotter-0.9.orig/src/rotter.h
 rotter-0.9/src/rotter.h
+@@ -132,7 +132,7 @@ encoder_funcs_t* init_lame( const char*
+ encoder_funcs_t* init_sndfile( const char* format, int channels, int bitrate 
);
+ 
+ // In mpegaudiofile.c
+-FILE* mpegaudio_file;
++extern FILE* mpegaudio_file;
+ int close_mpegaudio_file();
+ int open_mpegaudio_file( const char* filepath );
+ 
diff -Nru rotter-0.9/debian/patches/series rotter-0.9/debian/patches/series
--- rotter-0.9/debian/patches/series2011-02-08 21:42:06.0 +
+++ rotter-0.9/debian/patches/series2020-10-26 19:10:04.0 +
@@ -1 +1,2 @@
 use_ogg.diff
+fix_gcc-10.patch

Bug#972977: megahit should be Architecture: amd64

[Adrian Bunk]

Source: megahit
Version: 1.2.9-1
Severity: important
Tags: ftbfs

https://buildd.debian.org/status/package.php?p=megahit=sid

I started looking at what it would take to make megahit build on
other architectures, but it would end up being more work than
it's worth.

This package is simply
  Architecture: amd64

Bug#923397: known issue with upstream bug report

[Alec Leamas]

On Mon, 11 Mar 2019 09:28:03 +0100 =?UTF-8?Q?Tycho_L=c3=bcrsen?=
 wrote:
> Hi, as the subject says, this is a known issue ( see 
> https://bugzilla.redhat.com/show_bug.cgi?id=1652992 )
> 
> and it has a upstream bugreport ( see 
> https://sourceforge.net/p/lirc/tickets/341/ )
> 
> Hope that helps.
> 
> Regards, Tycho



On current sid, using lirc 0.10.1-6.2 I cannot reproduce this,
lirc-setup starts without problems. Closing


--alec

Bug#872375: lirc: irrecord segfaults when recording a button

[Alec Leamas]

On Tue, 13 Feb 2018 21:54:19 +0100 Alec Leamas 
wrote:

> 
> This message really says it all: using irrecord  with the devinput
> driver is a useless and dangerous idea. See my other replies in the bug
> for more.
> 
> 

This is bug is outdated and partly off-topic. Closing. That is not to
say that irrecord works for all input devices -- it doesn't. It also
occasionally segfaults, I have not been able to find the reason.

Bug#972906: [Python-modules-team] Bug#972906: monty: new upstream release available

[Emmanuel Arias]

Hi Drew,

 I push to salsa the new upstream release (4.0.2)


Cheers,
Arias Emmanuel
@eamanu
yaerobi.com


On Mon, Oct 26, 2020 at 8:57 AM Drew Parsons  wrote:

> Great, I'll look forward to it. That will bring all the new molecular
> dynamics control packages online, then will have to start comparing and
> using them.
>
> Drew
>
> On 2020-10-26 19:23, Emmanuel Arias wrote:
> > Oh Ok! go ahead please :)
> >
> > I 'll prepare new version and contact  you for sponsorship (again)
> >
> > thanks!
> >
> > Cheers,
> >
> > Arias Emmanuel
> > @eamanu
> >
> > http://eamanu.com
> >
> > El lun., 26 de oct. de 2020 a la(s) 08:22, Drew Parsons
> > (dpars...@debian.org) escribió:
> >
> >> Great! I'll be happy to sponsor.
> >>
> >> Drew
> >>
> >> On 2020-10-26 19:19, Emmanuel Arias wrote:
> >>> Hi,
> >>>
> >>> Ok, I will ask sponsorship for the source upload.
> >>>
> >>> Meanwhile I will prepare a new upstream release.
> >>>
> >>> Thank you
> >>>
> >>> Cheers,
> >>>
> >>> Arias Emmanuel
> >>> @eamanu
> >>>
> >>> http://eamanu.com
> >>>
> >>> El lun., 26 de oct. de 2020 a la(s) 05:21, Drew Parsons
> >>> (dpars...@debian.org) escribió:
> >>>
>  Source: monty
>  Severity: normal
> 
>  Thanks for packaging monty! It will need another source-only
> >> upload
>  in
>  order to migrate to testing.
> 
>  While preparing that upload, could the version be updated to the
>  latest upstream release at the same time?
> 
>  The latest pymatgen 2020.10.20 requires monty >= 4.0.2
>  (and we need latest pymatgen in order to build against the
> >> recently
>  released Python 3.9)
> 
>  ___
>  Python-modules-team mailing list
>  python-modules-t...@alioth-lists.debian.net
> 
> >>>
> >>
> >
> https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/python-modules-team
>
>

Bug#972976: RM: pynast -- RoQA; Depends on Python 2, dead upstream

[Moritz Muehlenhoff]

Package: ftp.debian.org
Severity: normal

Please remove pynast. It depends on Python and is dead upstream,
acked by the maintainer in #937488.

Cheers,
Moritz

Bug#972975: Remove alternative build dep on Python

[Moritz Muehlenhoff]

Package: iotjs
Severity: minor

The build deps currently state "python3 | python", but you can safely
remove python entirely. Python 2 will be removed at some point and
even very old Debian releases (if you care about backports to older
suites) already provide some version of Python 3.
   

Bug#937488: pynast: Python2 removal in sid/bullseye

[Moritz Mühlenhoff]

On Fri, Oct 23, 2020 at 08:08:58AM +0200, Andreas Tille wrote:
> On Wed, Oct 21, 2020 at 11:09:57PM +0200, Moritz Mühlenhoff wrote:
> > 
> > Given that there's been no upstream reaction for almost a year, let's
> > remove?
> 
> Agreed, Andreas. 

Ack, I've just filed a removal bug.

Cheers,
Moritz

Bug#972785: zeromq3: Include cmake files for cppzmq

[Gordon Ball]

On Mon, Oct 26, 2020 at 01:07:09PM +, Luca Boccassi wrote:
> On Mon, 2020-10-26 at 12:28 +, Gordon Ball wrote:
> > On Mon, Oct 26, 2020 at 11:52:17AM +, Luca Boccassi wrote:
> > > On Mon, 2020-10-26 at 11:40 +, Gordon Ball wrote:
> > > > On Mon, Oct 26, 2020 at 09:48:52AM +, Luca Boccassi wrote:
> > > > > On Sun, 2020-10-25 at 17:13 +0100, László Böszörményi (GCS) wrote:
> > > > > > On Fri, Oct 23, 2020 at 4:57 PM Gordon Ball  
> > > > > > wrote:
> > > > > > > src:zeromq3 and libzmq3-dev currently embed headers from the 
> > > > > > > separate
> > > > > > > cppzmq repository. However, the associated cmake files are not 
> > > > > > > included,
> > > > > > > which means when trying to build downstream projects which use 
> > > > > > > cppzmq
> > > > > > > and cmake, it's necessary to hack the buildsystem or embed the 
> > > > > > > cmake
> > > > > > > files from cppzmq.
> > > > > >  These are different projects and should be packaged differently. As
> > > > > > czmq is packaged by Luca, I think cppzmq should be packaged by him 
> > > > > > as
> > > > > > well. But let's hear what he says.
> > > > > > 
> > > > > > Regards,
> > > > > > Laszlo/GCS
> > > > > 
> > > > > Hi,
> > > > > 
> > > > > Given it's just a header, I don't think it's necessary to do anything
> > > > > complicated - there's nothing to build and there's no dependencies to
> > > > > track. No point in having separate packages or cmake files or whatnot 
> > > > > -
> > > > > #include is all a user needs.
> > > > > 
> > > > 
> > > > The CMake files aren't _needed_, but they're provided upstream and
> > > > downstream projects that use cppzmq and CMake expect them to be there,
> > > > and it feels like an unnecessary friction to need to patch/override the
> > > > buildsystem of downstream projects to get round us shipping the headers
> > > > but not the other parts of the cppzmq distribution.
> > > 
> > > Sorry I still don't follow, why does the downstream build system need
> > > to be patched/overriden? Again, it's just a header. There's nothing to
> > > build - just install the package, #include and it's good to go.
> > > 
> > 
> > This is probably a case where build tools provide you with extra ways to
> > shoot yourself in the foot. See, for example:
> > 
> > https://github.com/jupyter-xeus/xeus/blob/master/CMakeLists.txt
> > 
> > While the source files do just do `#include `, as you say, the
> > CMakeLists.txt wants to find the CMake config files for cppzmq to check
> > for the version, linker flags required, etc:
> > 
> > set(cppzmq_REQUIRED_VERSION 4.4.1)
> > find_package(cppzmq ${cppzmq_REQUIRED_VERSION} REQUIRED)
> > target_link_libraries(... PUBLIC ${CPPZMQ_TARGET_NAME} ...)
> > 
> > The CMake files for cppzmq don't (as you'd expect) do much - define a
> > target which requires linking to libzmq and declare the version.
> > 
> > So, to build the above project against the current debian libzmq3-dev is
> > possible, but some patching of the downstream package's CMakeLists is
> > required.
> 
> Then why not just fix that project upstream to avoid all that? Sorry,
> but I am not going to take on additional work just because of the
> arbitrary choice of a downstream build system. Please fix that instead.
> Thank you.
> 

I think it is unlikely that they'll be receptive to making such changes
for my benefit, given they have something that works and is supported
by cppzmq upstream.

However, the workarounds for not having CMake integration in this case
aren't too complicated, so I'll work on that instead.
> -- 
> Kind regards,
> Luca Boccassi

Bug#972974: clamav-freshclam start faild.

[Michael Borgelt]

Package: clamav-freshclam
Version: 0.103.0+dfsg-1
Severity: grave
Justification: renders package unusable

clamav-freshclam start faild with:
Okt 26 18:44:41 host freshclam[31527]: ERROR: initialize: libfreshclam init
failed.
Okt 26 18:44:41 host freshclam[31527]: ERROR: Initialization error!
Okt 26 18:44:41 bert freshclam[31527]: ERROR: Can't open
/var/log/clamav/freshclam.log in append mode (check permissions!).
Okt 26 18:44:41 host systemd[1]: clamav-freshclam.service: Main process exited,
code=exited, status=2/INVALIDARGUMENT
Okt 26 18:44:41 host systemd[1]: clamav-freshclam.service: Failed with result
'exit-code'.

clamav-freshcalm was installed for the first time on this host.



-- Package-specific info:
--- configuration ---
Checking configuration files in /etc/clamav

Config file: clamd.conf
---
AlertExceedsMax disabled
PreludeEnable disabled
PreludeAnalyzerName = "ClamAV"
LogFile = "/var/log/clamav/clamav.log"
LogFileUnlock disabled
LogFileMaxSize = "4294967295"
LogTime = "yes"
LogClean disabled
LogSyslog disabled
LogFacility = "LOG_LOCAL6"
LogVerbose disabled
LogRotate = "yes"
ExtendedDetectionInfo = "yes"
PidFile disabled
TemporaryDirectory disabled
DatabaseDirectory = "/var/lib/clamav"
OfficialDatabaseOnly disabled
LocalSocket = "/var/run/clamav/clamd.ctl"
LocalSocketGroup = "clamav"
LocalSocketMode = "666"
FixStaleSocket = "yes"
TCPSocket disabled
TCPAddr disabled
MaxConnectionQueueLength = "15"
StreamMaxLength = "26214400"
StreamMinPort = "1024"
StreamMaxPort = "2048"
MaxThreads = "12"
ReadTimeout = "180"
CommandReadTimeout = "30"
SendBufTimeout = "200"
MaxQueue = "100"
IdleTimeout = "30"
ExcludePath disabled
MaxDirectoryRecursion = "15"
FollowDirectorySymlinks disabled
FollowFileSymlinks disabled
CrossFilesystems = "yes"
SelfCheck = "3600"
ConcurrentDatabaseReload = "yes"
DisableCache disabled
VirusEvent disabled
ExitOnOOM disabled
AllowAllMatchScan = "yes"
Foreground disabled
Debug disabled
LeaveTemporaryFiles disabled
User = "clamav"
Bytecode = "yes"
BytecodeSecurity = "TrustSigned"
BytecodeTimeout = "6"
BytecodeUnsigned disabled
BytecodeMode = "Auto"
DetectPUA disabled
ExcludePUA disabled
IncludePUA disabled
ScanPE = "yes"
ScanELF = "yes"
ScanMail = "yes"
ScanPartialMessages disabled
PhishingSignatures = "yes"
PhishingScanURLs = "yes"
HeuristicAlerts = "yes"
HeuristicScanPrecedence disabled
StructuredDataDetection disabled
StructuredMinCreditCardCount = "3"
StructuredMinSSNCount = "3"
StructuredSSNFormatNormal = "yes"
StructuredSSNFormatStripped disabled
ScanHTML = "yes"
ScanOLE2 = "yes"
AlertBrokenExecutables disabled
AlertEncrypted disabled
StructuredCCOnly disabled
AlertEncryptedArchive disabled
AlertEncryptedDoc disabled
AlertOLE2Macros disabled
AlertPhishingSSLMismatch disabled
AlertPhishingCloak disabled
AlertPartitionIntersection disabled
ScanPDF = "yes"
ScanSWF = "yes"
ScanXMLDOCS = "yes"
ScanHWP3 = "yes"
ScanArchive = "yes"
ForceToDisk disabled
MaxScanTime = "12"
MaxScanSize = "104857600"
MaxFileSize = "26214400"
MaxRecursion = "16"
MaxFiles = "1"
MaxEmbeddedPE = "10485760"
MaxHTMLNormalize = "10485760"
MaxHTMLNoTags = "2097152"
MaxScriptNormalize = "5242880"
MaxZipTypeRcg = "1048576"
MaxPartitions = "50"
MaxIconsPE = "100"
MaxRecHWP3 = "16"
PCREMatchLimit = "1"
PCRERecMatchLimit = "5000"
PCREMaxFileSize = "26214400"
OnAccessMountPath disabled
OnAccessIncludePath disabled
OnAccessExcludePath disabled
OnAccessExcludeRootUID disabled
OnAccessExcludeUID disabled
OnAccessExcludeUname disabled
OnAccessMaxFileSize = "5242880"
OnAccessDisableDDD disabled
OnAccessPrevention disabled
OnAccessExtraScanning disabled
OnAccessCurlTimeout = "5000"
OnAccessMaxThreads = "5"
OnAccessRetryAttempts disabled
OnAccessDenyOnError disabled
DevACOnly disabled
DevACDepth disabled
DevPerformance disabled
DevLiblog disabled
DisableCertCheck disabled
AlgorithmicDetection = "yes"
BlockMax disabled
PhishingAlwaysBlockSSLMismatch disabled
PhishingAlwaysBlockCloak disabled
PartitionIntersection disabled
OLE2BlockMacros disabled
ArchiveBlockEncrypted disabled

Config file: freshclam.conf
---
LogFileMaxSize = "4294967295"
LogTime = "yes"
LogSyslog disabled
LogFacility = "LOG_LOCAL6"
LogVerbose disabled
LogRotate = "yes"
PidFile disabled
DatabaseDirectory = "/var/lib/clamav"
Foreground disabled
Debug disabled
UpdateLogFile = "/var/log/clamav/freshclam.log"
DatabaseOwner = "clamav"
Checks = "24"
DNSDatabaseInfo = "current.cvd.clamav.net"
DatabaseMirror = "db.local.clamav.net", "database.clamav.net"
PrivateMirror disabled
MaxAttempts = "5"
ScriptedUpdates = "yes"
TestDatabases = "yes"
CompressLocalDatabase disabled
ExtraDatabase disabled
ExcludeDatabase disabled
DatabaseCustomURL disabled
HTTPProxyServer disabled
HTTPProxyPort disabled
HTTPProxyUsername disabled
HTTPProxyPassword disabled
HTTPUserAgent disabled
NotifyClamd = "/etc/clamav/clamd.conf"
OnUpdateExecute disabled
OnErrorExecute disabled
OnOutdatedExecute disabled
LocalIPAddress disabled

Bug#942853: ITP: python-mitogen - Python library for writing distributed self-replicating programs

[Emmanuel Arias]

El lun., 26 de oct. de 2020 a la(s) 14:17, Antoine Beaupré (
anar...@debian.org) escribió:

> On 2020-10-26 13:23:46, Emmanuel Arias wrote:
> >>
> >>
> >> Do you still plan on packaging mitogen? It would be great to see it in
> >> Debian.
> >>
> >> In any case I'd be happy to help and might start packaging it myself on
> >> the side if there's no further activity here...
> >>
> >
> > Hi Yes of course, whole help is thanks.  In this next couple of
> > weeks I plan clean my backlog, (mitogen included) but I was problems
> > with lfs + salsa (maybe because I don't have experience with that).
> >
> > But, I will take a look again, thanks for remember it.
> >
> > I created this salsa repo
> > https://salsa.debian.org/python-team/packages/python-mitogen
>
> Are you okay if I start pushing changes there directly? I'll ping you
>
yes of course start pushing :D

I'm in IRC as eamanu

> here if/when i start working on it, just to make sure we don't duplicate
> work...
>
> a.
>
> --
> Si Dieu existe, j'espère qu'Il a une excuse valable
> - Daniel Pennac
>

Bug#971277: dpdk 18.11.10-1~deb10u1 flagged for acceptance

[Luca Boccassi]

On Mon, 2020-10-26 at 17:56 +, Adam D. Barratt wrote:
> On Mon, 2020-10-26 at 15:18 +, Luca Boccassi wrote:
> > On Sun, 2020-10-25 at 12:11 +, Luca Boccassi wrote:
> > > On Sat, 24 Oct 2020 at 18:38, Adam D. Barratt <
> > > a...@adam-barratt.org.uk> wrote:
> [...]
> > > > Unfortunately, this FTBFS on armhf (in three attempts across two
> > > > different buildds):
> [...]
> > I found the issue, and I have a patch ready (a mainline commit was
> > mistakenly not tagged for backport). Also found that the armv7 CI was
> > disabled due to infra issues - I'll fix that too.
> 
> Cool, thanks for the quick turnaround.
> 
> > In terms of process, how do I proceed? A deb10u2 upload to stable?
> 
> Yes, as the archive already contains ~deb10u1.
> 
> > Do I need to create a new bug?
> 
> As this is a build fix for the upload tracked by this bug, then
> continuing to use this bug is fine in this instance. If it were a new
> set of changes then it should be tracked in a separate bug.
> 
> Please do attach an updated debdiff to this bug though.
> 
> Regards,
> 
> Adam

Uploaded and debdiff attached. Tested the build on the harris armhf
porterbox.

-- 
Kind regards,
Luca Boccassi
diff -Nru dpdk-18.11.10/debian/changelog dpdk-18.11.10/debian/changelog
--- dpdk-18.11.10/debian/changelog	2020-09-28 15:35:37.0 +0100
+++ dpdk-18.11.10/debian/changelog	2020-10-26 10:44:57.0 +
@@ -1,3 +1,9 @@
+dpdk (18.11.10-1~deb10u2) buster; urgency=medium
+
+  * Backport patch to fix armhf build with NEON
+
+ -- Luca Boccassi   Mon, 26 Oct 2020 10:44:57 +
+
 dpdk (18.11.10-1~deb10u1) buster; urgency=medium
 
   * New upstream version 18.11.10
diff -Nru dpdk-18.11.10/debian/patches/0008-net-i40e-support-aarch32.patch dpdk-18.11.10/debian/patches/0008-net-i40e-support-aarch32.patch
--- dpdk-18.11.10/debian/patches/0008-net-i40e-support-aarch32.patch	1970-01-01 01:00:00.0 +0100
+++ dpdk-18.11.10/debian/patches/0008-net-i40e-support-aarch32.patch	2020-10-26 10:44:57.0 +
@@ -0,0 +1,42 @@
+Author: Ruifeng Wang 
+Origin: https://git.dpdk.org/dpdk/commit/?id=78bfe1666b2063e3fc3fa51e757159f53e1fc779
+Description: fix armhf build with NEON
+--- a/config/defconfig_arm-armv7a-linuxapp-gcc
 b/config/defconfig_arm-armv7a-linuxapp-gcc
+@@ -45,7 +45,6 @@ CONFIG_RTE_LIBRTE_CXGBE_PMD=n
+ CONFIG_RTE_LIBRTE_E1000_PMD=n
+ CONFIG_RTE_LIBRTE_ENIC_PMD=n
+ CONFIG_RTE_LIBRTE_FM10K_PMD=n
+-CONFIG_RTE_LIBRTE_I40E_PMD=n
+ CONFIG_RTE_LIBRTE_IXGBE_PMD=n
+ CONFIG_RTE_LIBRTE_MLX4_PMD=n
+ CONFIG_RTE_LIBRTE_VMXNET3_PMD=n
+--- a/drivers/net/i40e/Makefile
 b/drivers/net/i40e/Makefile
+@@ -74,7 +74,7 @@ SRCS-$(CONFIG_RTE_LIBRTE_I40E_PMD) += i40e_dcb.c
+ 
+ SRCS-$(CONFIG_RTE_LIBRTE_I40E_PMD) += i40e_ethdev.c
+ SRCS-$(CONFIG_RTE_LIBRTE_I40E_PMD) += i40e_rxtx.c
+-ifeq ($(CONFIG_RTE_ARCH_ARM64),y)
++ifneq ($(filter y,$(CONFIG_RTE_ARCH_ARM) $(CONFIG_RTE_ARCH_ARM64)),)
+ SRCS-$(CONFIG_RTE_LIBRTE_I40E_INC_VECTOR) += i40e_rxtx_vec_neon.c
+ else ifeq ($(CONFIG_RTE_ARCH_PPC_64),y)
+ SRCS-$(CONFIG_RTE_LIBRTE_I40E_INC_VECTOR) += i40e_rxtx_vec_altivec.c
+--- a/drivers/net/i40e/i40e_rxtx_vec_neon.c
 b/drivers/net/i40e/i40e_rxtx_vec_neon.c
+@@ -6,6 +6,7 @@
+ #include 
+ #include 
+ #include 
++#include 
+ 
+ #include "base/i40e_prototype.h"
+ #include "base/i40e_type.h"
+@@ -13,7 +14,6 @@
+ #include "i40e_rxtx.h"
+ #include "i40e_rxtx_vec_common.h"
+ 
+-#include 
+ 
+ #pragma GCC diagnostic ignored "-Wcast-qual"
+ 
diff -Nru dpdk-18.11.10/debian/patches/series dpdk-18.11.10/debian/patches/series
--- dpdk-18.11.10/debian/patches/series	2020-09-28 15:17:35.0 +0100
+++ dpdk-18.11.10/debian/patches/series	2020-10-26 10:44:37.0 +
@@ -2,3 +2,4 @@
 0005-build-use-dependency-instead-of-find_library.patch
 0006-build-reorder-libraries-and-build-eal-before-cmdline.patch
 0007-build-use-dependency-for-libbsd-instead-of-manual-ap.patch
+0008-net-i40e-support-aarch32.patch


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

Bug#970830: Firefox 78 ESR: Can't hear other participants in Google Meet

[David Reviejo]

Package: firefox-esr
Version: 78.4.0esr-1~deb10u2

Hi,

I got the same problem with Soundcloud (https://soundcloud.com), both
embeded and in the web site.

Same conditions as the OP: ALSA-only system, audio working without any
problem in any site (YouTube, Vimeo... or opening audio or video files
in the browser), except in Soundcloud; also, the workaround using apulse
works.

-- 
David

Bug#968675: confirmed and tested

[Andreas B. Mundt]

Control: tags -1 + patch


Hi Mike,

I can confirm the issue for debian-lan.  
The patch from Michael Peek works for me.

Best regards and thanks for your work,

  Andi

Bug#972972: libcgi-application-server-perl FTBFS on IPV6-only buildds

[Adrian Bunk]

Source: libcgi-application-server-perl
Version: 0.063-3
Severity: serious
Tags: ftbfs

https://buildd.debian.org/status/fetch.php?pkg=libcgi-application-server-perl=all=0.063-3=1603732518=0

...
   debian/rules override_dh_auto_test
make[1]: Entering directory '/<>'
http_proxy= dh_auto_test
make -j4 test TEST_VERBOSE=1
make[2]: Entering directory '/<>'
PERL_DL_NONLAZY=1 "/usr/bin/perl" "-MExtUtils::Command::MM" "-MTest::Harness" 
"-e" "undef *Test::Harness::Switches; test_harness(1, 'blib/lib', 'blib/arch')" 
t/*.t
t/00-compile.t . 
1..1
ok 1 - CGI::Application::Server loaded ok
ok
# 
# 
# Generated by Dist::Zilla::Plugin::ReportVersions::Tiny v1.08
# perl: 5.030003 (wanted any version) on linux from /usr/bin/perl
# 
# CGI   => 4.51   (want any version)
# CGI::Application  => 4.61   (want 4.21)   
# CGI::Application::Dispatch=> 3.12   (want any version)
# CGI::Application::Plugin::Redirect=> 1.00   (want any version)
# Carp  => 1.50   (want 0.01)   
# ExtUtils::MakeMaker   => 7.34   (want 6.30)   
# File::Find=> 1.36   (want any version)
# File::Temp=> 0.2309 (want any version)
# HTTP::Response=> 6.26   (want any version)
# HTTP::Server::Simple  => 0.52   (want 0.18)   
# HTTP::Server::Simple::CGI => (want any version)
# HTTP::Server::Simple::Static  => 0.14   (want 0.02)   
# HTTP::Status  => 6.26   (want any version)
# Scalar::Util  => 1.5(want 1.18)   
# Test::Exception   => 0.43   (want any version)
# Test::HTTP::Server::Simple=> 0.11   (want any version)
# Test::More=> 1.302162   (want 0.96)   
# Test::Pod => 1.52   (want 1.41)   
# Test::WWW::Mechanize  => 1.52   (want any version)
# base  => 2.27   (want any version)
# lib   => 0.65   (want any version)
# strict=> 1.11   (want any version)
# version   => 0.9924 (want 0.9901) 
# warnings  => 1.44   (want any version)
# 
# Thanks for using my code.  I hope it works for you.
# If not, please try and include this output in the bug report.
# That will help me reproduce the issue and solve your problem.
# 
t/000-report-versions-tiny.t ... 
ok 1 - we really didn't test anything, just reporting data
1..1
ok
t/000_load.t ... 
1..1
ok 1 - use CGI::Application::Server;
ok

#   Failed test '... got the index.html page okay'
#   at t/001_basic.t line 65.
# 500
# Can't connect to localhost:47857 (Connection refused)

#   Failed test '... got the right page title for index.html'
#   at t/001_basic.t line 66.
#  got: undef
# expected: "Test Static Index Page"

#   Failed test '... got the index.cgi page start-point okay'
#   at t/001_basic.t line 70.
# 500
# Can't connect to localhost:47857 (Connection refused)

#   Failed test '... got the right page title for index.cgi'
#   at t/001_basic.t line 71.
#  got: undef
# expected: "Hello"

#   Failed test '... got the index.cgi page okay'
#   at t/001_basic.t line 75.
# 500
# Can't connect to localhost:47857 (Connection refused)

#   Failed test '... got the right page title for index.cgi (hello)'
#   at t/001_basic.t line 76.
#  got: undef
# expected: "Hello"

#   Failed test '... got the index.cgi page okay'
#   at t/001_basic.t line 78.
# 500
# Can't connect to localhost:47857 (Connection refused)

#   Failed test '... got the right page title for index.cgi (goodbye)'
#   at t/001_basic.t line 79.
#  got: undef
# expected: "Goodbye"

#   Failed test '... got the index.cgi page okay'
#   at t/001_basic.t line 81.
# 500
# Can't connect to localhost:47857 (Connection refused)

#   Failed test '... got the right page title for index.cgi (redirect end)'
#   at t/001_basic.t line 82.
#  got: undef
# expected: "Redirect End"

#   Failed test '... got the index.cgi page okay'
#   at t/001_basic.t line 84.
# 500
# Can't connect to localhost:47857 (Connection refused)

#   Failed test '... got the right page title for index.cgi (redirect end)'
#   at t/001_basic.t line 85.
#  got: undef
# expected: "Redirect End"

#   Failed test '... got the index.cgi page okay (even with extra path info)'
#   at t/001_basic.t line 89.
# 500
# Can't connect to localhost:47857 (Connection refused)

#   Failed 

Bug#972941: [DRE-maint] Bug#972941: jekyll: complains about missing kramdown-parser-gfm

[ydirson]

> > The real problem is probably https://bugs.debian.org/972702. For
> > the
> > time being
> > please add
> > 
> > gem "kramdown-parser-gfm"
> > 
> > to your Gemfile and eventually remove Gemfile.lock. That should fix
> > it.
> 
> Yes that does help, thanks!

It is still probably worth mentionning that the ruby-bundler I have is 2.1.4-2,
not the 2.2.0~rc.1 mentionned in #972702.

Bug#971177: intake: FTBFS: TypeError: 'NoneType' object is not iterable

[Dmitry Shachnev]

Hi all!

On Mon, Oct 26, 2020 at 03:45:54PM +0200, Adrian Bunk wrote:
> The error is "FTBFS with Sphinx 3.2".
> Sphinx 3.2 entered unstable on August 9th.
>
> Dmitry (Cc'ed) might know more regarding what is the problem.

Let me explain what happens here:

- Sphinx' inspect module is capable of fetching the docstrings for parent
  classes when the child class does not have its own.

- To do that, it checks the __mro__ property that is defined for classes
  (and contains the tuple of parent classes).

- The top-level intake module (intake/__init__.py) defines a very generic
  __getattr__ function, which is defined this way:

def __getattr__(attr):
if attr == 'Catalog':
...

  If attr != 'Catalog', this function does not raise AttributeError exception
  (and returns None).

  So basically, that module has *every* possible attribute, including one
  named "__mro__" (and that attribute is None).

- Sphinx tries to iterate through __mro__ (because it expects it to be a
  tuple) but fails (because it's None, not a tuple).

To fix this, __getattr__('__mro__') should raise an AttributeError, not return
None.

So you can either:

- Remove that function completely (it is provided for compatibility reasons).

- Update to a newer upstream snapshot where that function is refactored and
  does raise AttributeError (see https://github.com/intake/intake/pull/526).

- Add these two lines as a temporary measure:

elif attr == '__mro__':
raise AttributeError

--
Dmitry Shachnev


signature.asc
Description: PGP signature

Bug#972968: Output of systemctl status bluetooth

[Christian Britz]

 ● bluetooth.service - Bluetooth service
 Loaded: loaded (/lib/systemd/system/bluetooth.service; enabled; vendor 
preset: enabled)
 Active: active (running) since Mon 2020-10-26 18:28:47 CET; 3min 55s ago
   Docs: man:bluetoothd(8)
   Main PID: 558 (bluetoothd)
 Status: "Running"
  Tasks: 1 (limit: 9231)
 Memory: 3.1M
 CGroup: /system.slice/bluetooth.service
 └─558 /usr/libexec/bluetooth/bluetoothd

Okt 26 18:28:47 amiga5000 bluetoothd[558]: src/main.c:parse_controller_config() 
Key file does not have key “LEScanIntervalConnect” in group “Controller”
Okt 26 18:28:47 amiga5000 bluetoothd[558]: src/main.c:parse_controller_config() 
Key file does not have key “LEScanWindowConnect” in group “Controller”
Okt 26 18:28:47 amiga5000 bluetoothd[558]: src/main.c:parse_controller_config() 
Key file does not have key “LEMinConnectionInterval” in group “Controller”
Okt 26 18:28:47 amiga5000 bluetoothd[558]: src/main.c:parse_controller_config() 
Key file does not have key “LEMaxConnectionInterval” in group “Controller”
Okt 26 18:28:47 amiga5000 bluetoothd[558]: src/main.c:parse_controller_config() 
Key file does not have key “LEConnectionLatency” in group “Controller”
Okt 26 18:28:47 amiga5000 bluetoothd[558]: src/main.c:parse_controller_config() 
Key file does not have key “LEConnectionSupervisionTimeout” in group 
“Controller”
Okt 26 18:28:47 amiga5000 bluetoothd[558]: src/main.c:parse_controller_config() 
Key file does not have key “LEAutoconnecttimeout” in group “Controller”
Okt 26 18:28:47 amiga5000 systemd[1]: Started Bluetooth service.
Okt 26 18:28:47 amiga5000 bluetoothd[558]: Starting SDP server
Okt 26 18:28:47 amiga5000 bluetoothd[558]: Bluetooth management interface 1.18 
initialized

Bug#972971: atlas-ecmwf FTBFS on 32bit

[Adrian Bunk]

Source: atlas-ecmwf
Version: 0.22.0-4
Severity: serious
Tags: ftbfs

https://buildd.debian.org/status/package.php?p=atlas-ecmwf=sid

...
[ 58%] Building Fortran object 
src/atlas_f/CMakeFiles/atlas_ecmwf_f.dir/util/atlas_allocate_module.F90.o
cd /<>/obj-i686-linux-gnu/src/atlas_f && /usr/bin/gfortran 
-D_FILE_OFFSET_BITS=64 -Datlas_ecmwf_f_EXPORTS -I/<>/src 
-I/<>/obj-i686-linux-gnu/src 
-I/<>/obj-i686-linux-gnu/src/atlas_f 
-I/<>/obj-i686-linux-gnu/module -I/<>/src/atlas_f 
-I/usr/include/i386-linux-gnu -I/usr/include/i386-linux-gnu/eckit 
-I/usr/include/i386-linux-gnu/eckit/geometry 
-I/usr/include/i386-linux-gnu/eckit/linalg 
-I/usr/lib/i386-linux-gnu/openmpi/include/openmpi 
-I/usr/lib/i386-linux-gnu/openmpi/include 
-I/usr/include/i386-linux-gnu/eckit/mpi 
-I/usr/include/i386-linux-gnu/eckit/option -I/usr/include/eigen3 
-I/usr/lib/i386-linux-gnu/fortran/gfortran-10/fckit 
-I/usr/include/i386-linux-gnu/fckit -g -O2 
-fdebug-prefix-map=/<>=. -fstack-protector-strong 
-I/usr/lib/i386-linux-gnu/fortran/i686-linux-gnu-gfortran-10 -O3 -DNDEBUG 
-funroll-all-loops -finline-functions -J../../module -fPIC -fopenmp -c 
/<>/src/atlas_f/util/atlas_allocate_module.F90 -o 
CMakeFiles/atlas_ecmwf_f.dir/util/atlas_allocate_module.F90.o
/<>/src/atlas_f/util/atlas_allocate_module.F90:118:45:

  118 | subroutine atlas_allocate_managedmem_int32_r2( A, dims )
  | 1
..
  132 | subroutine atlas_allocate_managedmem_int64_r2_int32( A, dims )
  |   2
Error: Ambiguous interfaces in generic interface 'atlas_allocate_managedmem' 
for ‘atlas_allocate_managedmem_int32_r2’ at (1) and 
‘atlas_allocate_managedmem_int64_r2_int32’ at (2)
/<>/src/atlas_f/util/atlas_allocate_module.F90:278:47:

  278 | subroutine atlas_deallocate_managedmem_int32_r2( A )
  |   1
..
  286 | subroutine atlas_deallocate_managedmem_int64_r2( A )
  |   2
Error: Ambiguous interfaces in generic interface 'atlas_deallocate_managedmem' 
for ‘atlas_deallocate_managedmem_int32_r2’ at (1) and 
‘atlas_deallocate_managedmem_int64_r2’ at (2)
/<>/src/atlas_f/util/atlas_allocate_module.F90:290:37:

  290 |   call atlas__deallocate_managedmem( c_loc_int64(A(1,1)) )
  | 1
Error: Type mismatch in argument ‘x’ at (1); passed INTEGER(4) to INTEGER(8)
/<>/src/atlas_f/util/atlas_allocate_module.F90:258:37:

  258 |   call atlas__deallocate_managedmem( c_loc_int64(A(1)) )
  | 1
Error: Type mismatch in argument ‘x’ at (1); passed INTEGER(4) to INTEGER(8)
make[3]: *** [src/atlas_f/CMakeFiles/atlas_ecmwf_f.dir/build.make:1061: 
src/atlas_f/CMakeFiles/atlas_ecmwf_f.dir/util/atlas_allocate_module.F90.o] 
Error 1

Bug#972941: [DRE-maint] Bug#972941: jekyll: complains about missing kramdown-parser-gfm

[ydirson]

- Mail original -
> De: "Daniel Leidert" 
> À: 972...@bugs.debian.org
> Cc: 972941-submit...@bugs.debian.org
> Envoyé: Lundi 26 Octobre 2020 17:50:13
> Objet: Bug#972941: [DRE-maint] Bug#972941: jekyll: complains about missing 
> kramdown-parser-gfm
> 
> Am Montag, den 26.10.2020, 13:49 +0100 schrieb ydir...@free.fr:
> > Package: jekyll
> > Version: 3.9.0+dfsg-1
> > 
> > Starting to use a new machine and incrementally installing missing
> > packages,
> > I finally
> > get stuck with this:
> > 
> > $ jekyll serve
> > Configuration file: /home/yann/perso/blog/floss-cook/_config.yml
> > Source: /home/yann/perso/blog/floss-cook
> >Destination: /home/yann/perso/blog/floss-cook/_site
> >  Incremental build: disabled. Enable with --incremental
> >   Generating...
> >Jekyll Feed: Generating feed for posts
> >   Dependency Error: Yikes! It looks like you don't have
> >   kramdown-parser-gfm
> > or one of its dependencies installed. In order to use Jekyll as
> > currently
> > configured, you'll need to install this gem. The full error message
> > from Ruby
> > is: 'cannot load such file -- kramdown-parser-gfm' If you run into
> > trouble,
> > you can find helpful resources at https://jekyllrb.com/help/!
> >   Liquid Exception: kramdown-parser-gfm in /_layouts/default.html
> >  ERROR: YOUR SITE COULD NOT BE BUILT:
> > 
> > kramdown-parser-gfm
> > 
> > 
> > kramdown-parser-gfm has been pulled as a dependency of the jekyll
> > package,
> > and it seems to load properly enough:
> > 
> > floss-cook (master>)$ irb
> > irb(main):001:0> require 'kramdown-parser-gfm'
> > => true
> > irb(main):002:0>
> > 
> > 
> > That message seems wrong, right ?  How can we know what the real
> > problem is ?
> 
> The real problem is probably https://bugs.debian.org/972702. For the
> time being
> please add
> 
> gem "kramdown-parser-gfm"
> 
> to your Gemfile and eventually remove Gemfile.lock. That should fix
> it.

Yes that does help, thanks!

Bug#972970: waffle: binary-all FTBFS

[Adrian Bunk]

Source: waffle
Version: 1.6.1-2
Severity: serious
Tags: ftbfs

https://buildd.debian.org/status/fetch.php?pkg=waffle=all=1.6.1-2=1603710782=0

...
   dh_missing -i -O--buildsystem=cmake
dh_missing: warning: usr/usr/share/bash-completion/completions/wflinfo exists 
in debian/tmp but is not installed to anywhere 
dh_missing: error: missing files, aborting
The following debhelper tools have reported what they installed (with 
files per package)
 * dh_install: libwaffle-1-0 (2), libwaffle-dev (10), libwaffle-doc 
(2), waffle-utils (2)
 * dh_installdocs: libwaffle-1-0 (0), libwaffle-dev (0), libwaffle-doc 
(0), waffle-utils (0)
 * dh_installman: libwaffle-1-0 (0), libwaffle-dev (0), libwaffle-doc 
(0), waffle-utils (0)
If the missing files are installed by another tool, please file a bug 
against it.
When filing the report, if the tool is not part of debhelper itself, 
please reference the
"Logging helpers and dh_missing" section from the "PROGRAMMING" guide 
for debhelper (10.6.3+).
  (in the debhelper package: /usr/share/doc/debhelper/PROGRAMMING.gz)
Be sure to test with dpkg-buildpackage -A/-B as the results may vary 
when only a subset is built
If the omission is intentional or no other helper can take care of this 
consider adding the
paths to debian/not-installed.
make: *** [debian/rules:9: binary-indep] Error 25

Bug#972968: linux-image-5.9.0-1-amd64: Bluetooth stopped working

[Christian Britz]

Package: src:linux
Version: 5.9.1-1
Severity: important
Tags: upstream
X-Debbugs-Cc: cbr...@t-online.de

Dear Maintainer,

after upgrading my Debian testing installation to kernel 5.9.1, my bluetooth 
mouse does not work anymore. According to IRC #debian-next this seems to be a 
known upstream problem, also affecting other distributions.
I will send the output of systemctl status bluetooth.



-- Package-specific info:
** Version:
Linux version 5.9.0-1-amd64 (debian-ker...@lists.debian.org) (gcc-10 (Debian 
10.2.0-15) 10.2.0, GNU ld (GNU Binutils for Debian) 2.35.1) #1 SMP Debian 
5.9.1-1 (2020-10-17)

** Command line:
BOOT_IMAGE=/boot/vmlinuz-5.9.0-1-amd64 
root=UUID=8182619a-9f43-4ac4-b4b1-5d199fd18be1 ro quiet

** Not tainted

** Kernel log:
[   16.604024] iTCO_wdt: initialized. heartbeat=30 sec (nowayout=0)
[   16.605385] Adding 998396k swap on /dev/nvme0n1p5.  Priority:-2 extents:1 
across:998396k SSFS
[   16.607486] systemd[1]: Activated swap 
/dev/disk/by-uuid/c37e771f-dfac-4520-8b63-b3aa174b5713.
[   16.607573] systemd[1]: Reached target Swap.
[   16.638238] RAPL PMU: API unit is 2^-32 Joules, 3 fixed counters, 655360 ms 
ovfl timer
[   16.638239] RAPL PMU: hw unit of domain pp0-core 2^-14 Joules
[   16.638240] RAPL PMU: hw unit of domain package 2^-14 Joules
[   16.638240] RAPL PMU: hw unit of domain pp1-gpu 2^-14 Joules
[   16.652887] videodev: Linux video capture interface: v2.00
[   16.656935] snd_hda_intel :00:1f.3: DSP detected with PCI 
class/subclass/prog-if info 0x040380
[   16.656957] cfg80211: Loading compiled-in X.509 certificates for regulatory 
database
[   16.657114] cfg80211: Loaded X.509 cert 'b...@debian.org: 
577e021cb980e0e820821ba7b54b4961b8b4fadf'
[   16.657268] cfg80211: Loaded X.509 cert 'romain.per...@gmail.com: 
3abbc6ec146e09d1b6016ab9d6cf71dd233f0328'
[   16.657447] cfg80211: Loaded X.509 cert 'sforshee: 00b28ddf47aef9cea7'
[   16.659800] platform regulatory.0: firmware: direct-loading firmware 
regulatory.db
[   16.660116] platform regulatory.0: firmware: direct-loading firmware 
regulatory.db.p7s
[   16.661731] systemd[1]: Started Journal Service.
[   16.726023] alg: No test for fips(ansi_cprng) (fips_ansi_cprng)
[   16.822721] uvcvideo: Found UVC 1.00 device Integrated Camera (13d3:5a08)
[   16.827293] uvcvideo 1-5:1.0: Entity type for entity Extension 4 was not 
initialized!
[   16.827295] uvcvideo 1-5:1.0: Entity type for entity Processing 2 was not 
initialized!
[   16.827296] uvcvideo 1-5:1.0: Entity type for entity Camera 1 was not 
initialized!
[   16.827343] input: Integrated Camera: Integrated C as 
/devices/pci:00/:00:14.0/usb1/1-5/1-5:1.0/input/input7
[   16.827389] usbcore: registered new interface driver uvcvideo
[   16.827390] USB Video Class driver (1.1.1)
[   16.827421] rtw_8822ce :01:00.0: firmware: direct-loading firmware 
rtw88/rtw8822c_wow_fw.bin
[   16.827424] rtw_8822ce :01:00.0: Firmware version 9.9.0, H2C version 15
[   16.827910] rtw_8822ce :01:00.0: firmware: direct-loading firmware 
rtw88/rtw8822c_fw.bin
[   16.827914] rtw_8822ce :01:00.0: Firmware version 9.9.0, H2C version 15
[   16.911781] intel_rapl_common: Found RAPL domain package
[   16.911783] intel_rapl_common: Found RAPL domain core
[   16.911785] intel_rapl_common: Found RAPL domain uncore
[   16.917233] rtw_8822ce :01:00.0 wlp1s0: renamed from wlan0
[   16.933753] Bluetooth: Core ver 2.22
[   16.933765] NET: Registered protocol family 31
[   16.933765] Bluetooth: HCI device and connection manager initialized
[   16.933768] Bluetooth: HCI socket layer initialized
[   16.933769] Bluetooth: L2CAP socket layer initialized
[   16.933772] Bluetooth: SCO socket layer initialized
[   16.940160] usbcore: registered new interface driver btusb
[   16.941305] Bluetooth: hci0: RTL: examining hci_ver=0a hci_rev=000c 
lmp_ver=0a lmp_subver=8822
[   16.942291] Bluetooth: hci0: RTL: rom_version status=0 version=3
[   16.942291] Bluetooth: hci0: RTL: loading rtl_bt/rtl8822cu_fw.bin
[   16.942634] bluetooth hci0: firmware: direct-loading firmware 
rtl_bt/rtl8822cu_fw.bin
[   16.942645] Bluetooth: hci0: RTL: loading rtl_bt/rtl8822cu_config.bin
[   16.942652] bluetooth hci0: firmware: failed to load 
rtl_bt/rtl8822cu_config.bin (-2)
[   16.942652] firmware_class: See https://wiki.debian.org/Firmware for 
information about missing firmware
[   16.942652] bluetooth hci0: Direct firmware load for 
rtl_bt/rtl8822cu_config.bin failed with error -2
[   16.942656] Bluetooth: hci0: RTL: cfg_sz -2, total sz 31416
[   17.053414] intel_pmc_core intel_pmc_core.0:  initialized
[   17.094255] Bluetooth: hci0: RTL: fw version 0x09993aa1
[   17.151398] snd_hda_intel :00:1f.3: bound :00:02.0 (ops 
i915_audio_component_bind_ops [i915])
[   17.180552] snd_hda_codec_generic hdaudioC0D0: autoconfig for Generic: 
line_outs=1 (0x14/0x0/0x0/0x0/0x0) type:speaker
[   17.180553] snd_hda_codec_generic hdaudioC0D0:speaker_outs=0 
(0x0/0x0/0x0/0x0/0x0)
[   17.180554] 

Bug#971277: dpdk 18.11.10-1~deb10u1 flagged for acceptance

[Adam D. Barratt]

On Mon, 2020-10-26 at 15:18 +, Luca Boccassi wrote:
> On Sun, 2020-10-25 at 12:11 +, Luca Boccassi wrote:
> > On Sat, 24 Oct 2020 at 18:38, Adam D. Barratt <
> > a...@adam-barratt.org.uk> wrote:
[...]
> > > Unfortunately, this FTBFS on armhf (in three attempts across two
> > > different buildds):
[...]
> I found the issue, and I have a patch ready (a mainline commit was
> mistakenly not tagged for backport). Also found that the armv7 CI was
> disabled due to infra issues - I'll fix that too.

Cool, thanks for the quick turnaround.

> In terms of process, how do I proceed? A deb10u2 upload to stable?

Yes, as the archive already contains ~deb10u1.

> Do I need to create a new bug?

As this is a build fix for the upload tracked by this bug, then
continuing to use this bug is fine in this instance. If it were a new
set of changes then it should be tracked in a separate bug.

Please do attach an updated debdiff to this bug though.

Regards,

Adam

Bug#972967: vmemcache FTBFS on armel/mipsel/powerpc: undefined reference to `__atomic_fetch_add_8'

[Adrian Bunk]

Source: vmemcache
Version: 0.8.1-1
Severity: serious
Tags: ftbfs patch

https://buildd.debian.org/status/package.php?p=vmemcache=sid

...
/usr/bin/ld: ../src/libvmemcache.so.0: undefined reference to 
`__atomic_fetch_add_8'
...


Fix/Workaround:

--- debian/rules.old2020-10-26 17:50:08.062846897 +
+++ debian/rules2020-10-26 17:50:29.654659998 +
@@ -3,7 +3,10 @@
 export DEB_BUILD_MAINT_OPTIONS = hardening=+all
 
 export DEB_CFLAGS_MAINT_APPEND  = -Wall -pedantic
-export DEB_LDFLAGS_MAINT_APPEND = -latomic
+
+ifneq (,$(filter $(DEB_HOST_ARCH), armel mipsel powerpc))
+  export DEB_LDFLAGS_MAINT_APPEND += -Wl,--no-as-needed -latomic 
-Wl,--as-needed
+endif
 
 
 %:

Bug#972552: closed by Debian FTP Masters (reply to Julian Andres Klode ) (Bug#972552: fixed in apt 2.1.11)

[Adam D. Barratt]

On Mon, 2020-10-26 at 12:42 +0200, Otto Kekäläinen wrote:
> For some strange reason the Debian mirrors still serve 2.1.10:
>   Get:18 http://deb.debian.org/debian sid/main amd64 apt amd64 2.1.10
> [1459 kB]
> 
> However 2.1.11 should be in the repos already:
>   https://packages.debian.org/source/unstable/apt => 2.1.11

The "strange reason" is 
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=972618

fwiw, looking at https://buildd.debian.org/status/package.php?p=apt
would show the successful builds as being only 8 hours old, and that each was 
tried twice.

Regards,

Adam

Bug#972156: kylin-video: FTBFS with Qt 5.15

[Dmitry Shachnev]

Control: reopen -1
Control: found -1 kylin-video/2.1.1-1
Control: forwarded -1 https://github.com/UbuntuKylin/kylin-video/pull/24

Hi!

On Mon, Oct 26, 2020 at 07:56:51PM +0800, handsome_feng wrote:
> Hi, Dmitry,
>
> Sorry for the delay and thanks a lot for your NMU. <&
>
> I will upload the new upstream release to the archive ASAP.

Sorry, but I have to reopen this bug :(

The new upstream release added QPainterPath use in src/systembutton.cpp
(see commit 17ac4742a24b758d) and there is no QPainterPath include, so
it fails to build with Qt 5.15 again:

  systembutton.cpp: In member function ‘virtual void 
SystemButton::paintEvent(QPaintEvent*)’:
  systembutton.cpp:105:22: error: aggregate ‘QPainterPath path’ has incomplete 
type and cannot be defined
105 | QPainterPath path;
|  ^~~~

Please apply https://github.com/UbuntuKylin/kylin-video/pull/24 to fix it,
with that change it builds fine.

--
Dmitry Shachnev


signature.asc
Description: PGP signature

Bug#972966: tensorpipe FTBFS on armel/mipsel/m68k/powerpc/riscv64/sh4: undefined reference to symbol '__atomic_load_8@@LIBATOMIC_1.0'

[Adrian Bunk]

Source: tensorpipe
Version: 0.0~git20200805.42033c5-3
Severity: important
Tags: ftbfs patch

https://buildd.debian.org/status/package.php?p=tensorpipe=sid

...
/usr/bin/c++ -g -O2 -fdebug-prefix-map=/<>=. 
-fstack-protector-strong -Wformat -Werror=format-security -Wdate-time 
-D_FORTIFY_SOURCE=2 -Wl,-z,relro -Wl,-z,now 
CMakeFiles/tensorpipe_test.dir/test.cc.o 
CMakeFiles/tensorpipe_test.dir/transport/context_test.cc.o 
CMakeFiles/tensorpipe_test.dir/transport/connection_test.cc.o 
CMakeFiles/tensorpipe_test.dir/transport/uv/uv_test.cc.o 
CMakeFiles/tensorpipe_test.dir/transport/uv/context_test.cc.o 
CMakeFiles/tensorpipe_test.dir/transport/uv/loop_test.cc.o 
CMakeFiles/tensorpipe_test.dir/transport/uv/connection_test.cc.o 
CMakeFiles/tensorpipe_test.dir/transport/uv/sockaddr_test.cc.o 
CMakeFiles/tensorpipe_test.dir/transport/listener_test.cc.o 
CMakeFiles/tensorpipe_test.dir/core/context_test.cc.o 
CMakeFiles/tensorpipe_test.dir/proto/core_test.cc.o 
CMakeFiles/tensorpipe_test.dir/channel/basic/basic_test.cc.o 
CMakeFiles/tensorpipe_test.dir/channel/xth/xth_test.cc.o 
CMakeFiles/tensorpipe_test.dir/channel/mpt/mpt_test.cc.o 
CMakeFiles/tensorpipe_test.dir/channel/channel_test.cc.o 
CMakeFiles/tensorpipe_test.dir/common/system_test.cc.o 
CMakeFiles/tensorpipe_test.dir/common/defs_test.cc.o 
CMakeFiles/tensorpipe_test.dir/transport/shm/reactor_test.cc.o 
CMakeFiles/tensorpipe_test.dir/transport/shm/loop_test.cc.o 
CMakeFiles/tensorpipe_test.dir/transport/shm/connection_test.cc.o 
CMakeFiles/tensorpipe_test.dir/transport/shm/sockaddr_test.cc.o 
CMakeFiles/tensorpipe_test.dir/transport/shm/shm_test.cc.o 
CMakeFiles/tensorpipe_test.dir/util/ringbuffer/shm_ringbuffer_test.cc.o 
CMakeFiles/tensorpipe_test.dir/util/ringbuffer/protobuf_streams_test.cc.o 
CMakeFiles/tensorpipe_test.dir/util/ringbuffer/ringbuffer_test.cc.o 
CMakeFiles/tensorpipe_test.dir/util/shm/segment_test.cc.o 
CMakeFiles/tensorpipe_test.dir/channel/cma/cma_test.cc.o -o tensorpipe_test  
-Wl,-rpath,"/<>/obj-arm-linux-gnueabi/tensorpipe:/<>/obj-arm-linux-gnueabi/lib"
 ../libtensorpipe.so.0 /usr/lib/arm-linux-gnueabi/libprotobuf.so 
../../lib/libgtest_main.so.1.10.0 /usr/lib/arm-linux-gnueabi/libuv.so 
/usr/lib/arm-linux-gnueabi/libpthread.so /usr/lib/arm-linux-gnueabi/libdl.so 
/usr/lib/arm-linux-gnueabi/librt.so ../../lib/libgtest.so.1.10.0 -lpthread 
/usr/bin/ld: 
CMakeFiles/tensorpipe_test.dir/util/ringbuffer/shm_ringbuffer_test.cc.o: 
undefined reference to symbol '__atomic_load_8@@LIBATOMIC_1.0'
/usr/bin/ld: /usr/lib/arm-linux-gnueabi/libatomic.so.1: error adding symbols: 
DSO missing from command line
collect2: error: ld returned 1 exit status
make[3]: *** [tensorpipe/test/CMakeFiles/tensorpipe_test.dir/build.make:504: 
tensorpipe/test/tensorpipe_test] Error 1


Fix/Workaround:

--- debian/rules.old2020-10-26 16:39:12.175986248 +
+++ debian/rules2020-10-26 16:39:47.807678187 +
@@ -1,6 +1,10 @@
 #!/usr/bin/make -f
 export DEB_BUILD_MAINT_OPTIONS = hardening=+all
 
+ifneq (,$(filter $(DEB_HOST_ARCH), armel m68k mipsel powerpc riscv64 sh4))
+  export DEB_LDFLAGS_MAINT_APPEND += -Wl,--no-as-needed -latomic 
-Wl,--as-needed
+endif
+
 %:
dh $@ -Scmake
 

Bug#972158: closed by Debian FTP Masters (reply to Dmitry Shachnev ) (Bug#972158: fixed in falkon 3.1.0+dfsg1-9)

[Dmitry Shachnev]

Hi Georges!

On Mon, Oct 26, 2020 at 10:06:03AM +, Debian Bug Tracking System wrote:
>[ Georges Khaznadar ]
>* adopted Dmitry Shachnev's fix, thank you Dmitry!

Thank you for uploading it! I have cancelled my NMU now.

--
Dmitry Shachnev


signature.asc
Description: PGP signature

Bug#972965: conflicting declaration of wchar_t

[Sébastien Villemot]

Package: libintelrdfpmath-dev
Version: 2.0u2-3
Severity: important
Tags: patch

Dear Maintainer,

If one compiles the attached C program on i386 or armhf, one gets:

In file included from wchar_t-bug.c:9:
/usr/lib/gcc/i686-linux-gnu/10/include/stddef.h:321:24: error: conflicting 
types for ‘wchar_t’
  321 | typedef __WCHAR_TYPE__ wchar_t;
  |^~~
In file included from wchar_t-bug.c:7:
/usr/include/bid_functions.h:46:15: note: previous declaration of ‘wchar_t’ was 
here
   46 | typedef int   wchar_t;
  |   ^~~

The problem is that bid_functions.h comes with its own definition of wchar_t,
which conflicts with that of GCC.

Note that the problem does not occur on amd64 (I guess because the inclusion
chains are different, and wchar_t gets defined by GCC before bid_functions.h
tries to redefine it).

I attach a patch that solves the problem by simply unconditionnally including
wchar.h, instead of defining wchar_t.

Best,

--
⢀⣴⠾⠻⢶⣦⠀  Sébastien Villemot
⣾⠁⢠⠒⠀⣿⡁  Debian Developer
⢿⡄⠘⠷⠚⠋⠀  http://sebastien.villemot.name
⠈⠳⣄  http://www.debian.org
#define DECIMAL_CALL_BY_REFERENCE 1
#define DECIMAL_GLOBAL_ROUNDING 1
#define DECIMAL_GLOBAL_ROUNDING_ACCESS_FUNCTIONS 1
#define DECIMAL_GLOBAL_EXCEPTION_FLAGS 1
#define DECIMAL_GLOBAL_EXCEPTION_FLAGS_ACCESS_FUNCTIONS 1
#include 
#include 

#include 

int
main()
{
}
--- bid_functions.h.orig2018-06-08 03:10:52.0 +0200
+++ bid_functions.h 2020-10-26 18:26:16.833114259 +0100
@@ -36,16 +36,9 @@
 #ifndef _BID_FUNCTIONS_H
 #define _BID_FUNCTIONS_H
 
-#if !defined (__GNUC__) || defined(__QNX__)
 #include 
-#endif
 #include 
 
-// Fix system header issue on Sun solaris and define required type by ourselves
-#if !defined(_WCHAR_T) && !defined(_WCHAR_T_DEFINED) && !defined(__QNX__)
-typedef int   wchar_t;
-#endif
-
 
 #ifdef IN_LIBGCC2
 // When we are built as the part of the gcc runtime library, libgcc,

Bug#972278: transition: qtbase-opensource-src

[Dmitry Shachnev]

Hi Sebastian and all!

On Fri, Oct 16, 2020 at 03:12:21PM +0200, Sebastian Ramacher wrote:
> Control: forwarded -1 
> https://release.debian.org/transitions/html/qtbase-abi-5-15-1.html
>
> I've added the tracker.

Thanks for setting up the tracker!

Fixes for the remaining 6 blocker bugs are waiting in the deferred queue, the
last ones are going to be accepted on Friday, October 30th.

So we can start the transition on that day or even one or two days earlier
(without waiting for them), if my time allows. Of course we can start later
too. Please let me know what you prefer.

--
Dmitry Shachnev


signature.asc
Description: PGP signature

Bug#957640: openntpd: diff for NMU version 1:6.2p3-4.1

[Sudip Mukherjee]

Control: tags 957640 + patch
Control: tags 957640 + pending
--

Dear maintainer,

I've prepared an NMU for openntpd (versioned as 1:6.2p3-4.1) and
uploaded it to DELAYED/2. Please feel free to tell me if I
should cancel it.

--
Regards
Sudip

diff -Nru openntpd-6.2p3/debian/changelog openntpd-6.2p3/debian/changelog
--- openntpd-6.2p3/debian/changelog 2018-08-17 22:43:06.0 +0100
+++ openntpd-6.2p3/debian/changelog 2020-10-26 17:10:47.0 +
@@ -1,3 +1,10 @@
+openntpd (1:6.2p3-4.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix ftbfs with GCC-10. (Closes: #957640)
+
+ -- Sudip Mukherjee   Mon, 26 Oct 2020 17:10:47 
+
+
 openntpd (1:6.2p3-4) unstable; urgency=medium
 
   * Fix FTBFS on autoconf-1.15. Thanks sanvila@! (Closes: #906497).
diff -Nru openntpd-6.2p3/debian/patches/fix_gcc-10.patch 
openntpd-6.2p3/debian/patches/fix_gcc-10.patch
--- openntpd-6.2p3/debian/patches/fix_gcc-10.patch  1970-01-01 
01:00:00.0 +0100
+++ openntpd-6.2p3/debian/patches/fix_gcc-10.patch  2020-10-26 
16:23:34.0 +
@@ -0,0 +1,55 @@
+Description: Fix ftbfs with GCC-10
+
+Ported from 
https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=e1b05d95f42a73c2b5a4f6bd78fa2dc25d81b1bc
+Original Author: Paul B. Henson 
+
+Author: Sudip Mukherjee 
+Bug-Debian: https://bugs.debian.org/957640
+Forwarded: no
+
+---
+
+--- openntpd-6.2p3.orig/include/sys/types.h
 openntpd-6.2p3/include/sys/types.h
+@@ -22,6 +22,10 @@
+ # define __bounded__(x, y, z)
+ #endif
+ 
++#if !defined(HAVE_ATTRIBUTE__PACKED) && !defined(__packed)
++# define __packed __attribute__((__packed__))
++#endif
++
+ /*
+  * Define BSD-style unsigned bits types for systems that do not have them.
+  */
+--- openntpd-6.2p3.orig/src/ntp_dns.c
 openntpd-6.2p3/src/ntp_dns.c
+@@ -33,7 +33,7 @@
+ #include "ntpd.h"
+ 
+ volatile sig_atomic_t  quit_dns = 0;
+-struct imsgbuf*ibuf_dns;
++static struct imsgbuf  *ibuf_dns;
+ 
+ void  sighdlr_dns(int);
+ int   dns_dispatch_imsg(void);
+--- openntpd-6.2p3.orig/src/parse.c
 openntpd-6.2p3/src/parse.c
+@@ -101,7 +101,6 @@ int lgetc(int);
+ intlungetc(int);
+ intfindeol(void);
+ 
+-struct ntpd_conf  *conf;
+ struct sockaddr_in query_addr4;
+ struct sockaddr_in6query_addr6;
+ 
+--- openntpd-6.2p3.orig/src/parse.y
 openntpd-6.2p3/src/parse.y
+@@ -57,7 +57,6 @@ int   lgetc(int);
+ intlungetc(int);
+ intfindeol(void);
+ 
+-struct ntpd_conf  *conf;
+ struct sockaddr_in query_addr4;
+ struct sockaddr_in6query_addr6;
+ 
diff -Nru openntpd-6.2p3/debian/patches/series 
openntpd-6.2p3/debian/patches/series
--- openntpd-6.2p3/debian/patches/series2017-06-12 15:46:01.0 
+0100
+++ openntpd-6.2p3/debian/patches/series2020-10-26 16:16:59.0 
+
@@ -2,3 +2,4 @@
 02-syslog.patch
 03-kfreebsd.patch
 04-ntpd-manpage.patch
+fix_gcc-10.patch

Bug#942853: ITP: python-mitogen - Python library for writing distributed self-replicating programs

[Antoine Beaupré]

On 2020-10-26 13:23:46, Emmanuel Arias wrote:
>>
>>
>> Do you still plan on packaging mitogen? It would be great to see it in
>> Debian.
>>
>> In any case I'd be happy to help and might start packaging it myself on
>> the side if there's no further activity here...
>>
>
> Hi Yes of course, whole help is thanks.  In this next couple of
> weeks I plan clean my backlog, (mitogen included) but I was problems
> with lfs + salsa (maybe because I don't have experience with that).
>
> But, I will take a look again, thanks for remember it.
>
> I created this salsa repo
> https://salsa.debian.org/python-team/packages/python-mitogen

Are you okay if I start pushing changes there directly? I'll ping you
here if/when i start working on it, just to make sure we don't duplicate
work...

a.

-- 
Si Dieu existe, j'espère qu'Il a une excuse valable
- Daniel Pennac

Bug#972688: bumping severity, unusable with wireguard

[Raphael Hertzog]

Control: notfound -1 1.27.90-3
Control: found -1 1.27.91-1
Control: severity -1 serious

I'm bumping the severity of this bug because it will break a working setup
on upgrade.

In my case, I'm not activating any VPN via NetworkManager but I do have
a wireguard VPN managed with wg-quick and NetworkManager will just happily
always write an empty /etc/resolv.conf due to this behaviour change. The
wireguard VPN NM connection doesn't have any DNS server associated to it
(and will never have any AFAIK, it's not in its scope).

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