Bug#980846: kodi-addons-dev-common: missing Breaks+Replaces: kodi-addons-dev (<< 2:19.0~rc1+git20210119.8c761c4+dfsg1-2)

[Andreas Beckmann]

Package: kodi-addons-dev-common
Version: 2:19.0~rc1+git20210119.8c761c4+dfsg1-2
Severity: serious
User: debian...@lists.debian.org
Usertags: piuparts

Hi,

during a test with piuparts I noticed your package fails to upgrade from
'sid' to 'experimental'.
It installed fine in 'sid', then the upgrade to 'experimental' fails
because it tries to overwrite other packages files without declaring a
Breaks+Replaces relation.

See policy 7.6 at
https://www.debian.org/doc/debian-policy/ch-relationships.html#overwriting-files-and-replacing-packages-replaces

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

  Preparing to unpack 
.../kodi-addons-dev-common_2%3a19.0~rc1+git20210119.8c761c4+dfsg1-2_all.deb ...
  Unpacking kodi-addons-dev-common (2:19.0~rc1+git20210119.8c761c4+dfsg1-2) ...
  dpkg: error processing archive 
/var/cache/apt/archives/kodi-addons-dev-common_2%3a19.0~rc1+git20210119.8c761c4+dfsg1-2_all.deb
 (--unpack):
   trying to overwrite '/usr/bin/dh_kodiaddon_depends', which is also in 
package kodi-addons-dev 2:19.0~rc1+git20210119.8c761c4+dfsg1-1
  dpkg-deb: error: paste subprocess was killed by signal (Broken pipe)
  Errors were encountered while processing:
   
/var/cache/apt/archives/kodi-addons-dev-common_2%3a19.0~rc1+git20210119.8c761c4+dfsg1-2_all.deb

There are
  B+R: kodi-addons-dev (<< 2:19.0~beta2+dfsg1-6~)
but that is the wrong version.


cheers,

Andreas


kodi-addons-dev=2:19.0~rc1+git20210119.8c761c4+dfsg1-1_kodi-addons-dev-common=2:19.0~rc1+git20210119.8c761c4+dfsg1-2.log.gz
Description: application/gzip

Bug#980847: pre-approval: qutebrowser/2.0.0-1

[Axel Beckert]

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

Please pre-approve the package qutebrowser/2.0.0-1.

[ Reason ]
A major upstream release (2.0.0) of qutebrowser is going to be released
soon (currently aimed at early next week, i.e. around 26th of January
2021).

While it certainly counts as a "large change", it is a leaf package and
risk is believed to be small (see below).

[ Impact ]
Users on Debian Stable will continue to use the previous release series
(1.14.x) for the next couple of years. Since there are some changes
around the names of commands/settings, this introduces an undesirable
gap between users on Debian Stable and users on other distributions
(many of qutebrowser's users are on rolling-release distributions).

This gap would make it more difficult both for upstream and the affected
users to give/take support, share configuration files, etc.

[ Tests ]
qutebrowser has a big automated testsuite with over 9000 (sic) tests.
Note that many of those result from parametrization (running the same
test with different sets of inputs), but still this reduces the
potential for regressions. Upstream also uses other measures to reduce
defects where appropriate, such as type annotations.

A part of its users is using it directly from its git repository, so
that any remaining issues with changes usually get reported and fixed
quickly.

[ Risks ] qutebrowser is a leaf package, so no coordination with other
package(r)s is required. It is also a desktop application - while those
certainly shouldn't be held to lower standards, the impact (or need for
additional "preparation time" for users) might be smaller compared to
e.g. a server application.

There are many changes upstream:

  $ git diff --stat v1.14.1...master
  540 files changed, 12654 insertions(+), 10182 deletions(-)

Excluding tests/scripts/...:

  $ git diff --stat v1.14.1...master -- qutebrowser/
  199 files changed, 5189 insertions(+), 5794 deletions(-)

However, the bulk of those changes are a result of relatively boring
changes upstream, such as dropping support for old Python/Qt versions.

The upstream changelog is probably a better indication:
https://github.com/qutebrowser/qutebrowser/blob/master/doc/changelog.asciidoc#v200-unreleased

[ Checklist ]
(N/A because this is a pre-approval)

[ Other info ]
The upstream maintainer is on Cc for this bug and is willing to work
with the package maintainers for this, where needed. If (despite all
measures) regressions would be introduced, a potential patch release
would happen as soon as possible. Patch releases are done from a
dedicated v2.0.x maintenance branch, keeping care to keep changes as
small as possible and without any non-bugfix changes.

The release also introduces a new optional dependency on the Python
"adblock" module for better ad blocking. It is currently not packaged
for Debian and doing so is outside of the scope of this request. If the
dependency is unavailable, qutebrowser will fall back on the same
hosts-based adblocking it used before this release.

So please pre-approve qutebrowser/2.0.0-1.

For Debian's qutebrowser package, the qutebrowser package maintainers
and upstream.

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

Kernel: Linux 5.10.0-1-amd64 (SMP w/4 CPU threads)
Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)
LSM: AppArmor: enabled

Bug#980832: nmu: tor_0.4.4.6-1

[Adam Borowski]

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

Hi!
The tor package is paranoid about version of libzstd, and currently says:

[warn] Tor was compiled with zstd 1.4.5, but is running with zstd 1.4.8.
↪ For safety, we'll avoid using advanced zstd functionality.

Whether or not this warning is dubious (#963151), for the lifetime of
Bullseye we can assume the upstream version of libzstd won't change.
Thus, a simple rebuild against bullseye's libzstd is a good enough
workaround.

nmu tor_0.4.4.6-1 . ANY . unstable . -m "Rebuild against libzstd 1.4.8"


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

Kernel: Linux 5.11.0-rc4-00014-gc9b56d9c1053 (SMP w/64 CPU threads)
Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:en
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)

Bug#980834: fcitx: Broken flatpak support (ipcportal) in Debian 10

[Boyuan Yang]

Source: fcitx
Version: 1:4.2.9.6-5
Severity: important
Control: fixed -1 1:4.2.9.7-1

It is know that fcitx in Debian 10 has broken flatpak (ipcportal)
support. As a result, packages installed via flatpak cannot use fcitx
as input method.

This bug is fixed since fcitx 4.2.9.7. The exact commit for this fix
is 
https://github.com/fcitx/fcitx/commit/1f4c3a96cb2d1308581864676dd86ea6aa393ccb
. The bug does not affect Debian Testing (Debian 11) and Debian Sid.

Thanks,
Boyuan Yang


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

Bug#980837: icewm-common: Icewm crashes and/or doesn't start when Infadel2 theme is selected as default.

[Bartek]

Package: icewm-common
Version: 2.0.0-2
Severity: normal

Dear Maintainer,

IceWM does not start neither through any used display manager, ie.: LightDM,
SDDM nor using startx command.
A default theme was set to Infadel2 in $HOME/.icewm/theme. I tested it with
each of it available options: default, Ergonomic and Overloaded. After
changing the theme in the mentioned file to any other in menu IceWM runs.

Question: can the bug be related to:
icewm (2.0.0-2) unstable; urgency=low
* Disable direct loaders except for Imlib2 and librsvg
* Dropped libgdx-pixbuf-2.0 dependency (its xlib support is deprecated)

I rather use this theme as I find the best of available in the package. 


Best regards,

Bartek



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

Kernel: Linux 5.10.8-xanmod1 (SMP w/4 CPU threads; PREEMPT)
Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set to 
C.UTF-8), LANGUAGE=C.UTF-8
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages icewm-common depends on:
ii  libc6   2.31-9
ii  libgcc-s1   10.2.1-6
ii  libglib2.0-02.66.4-1
ii  libstdc++6  10.2.1-6
ii  sensible-utils  0.0.14

Versions of packages icewm-common recommends:
ii  menu  2.1.48
ii  xscreensaver  5.45+dfsg1-1
ii  xterm 363-1

icewm-common suggests no packages.

-- no debconf information

Bug#980836: pulseaudio: Internal speakers and microphone not automatically selected when headset is unplugged from jack

[Ben Goodwin]

Package: pulseaudio
Version: 14.1-1
Severity: normal

Since upgrading from version 14.0-2 to version 14.1-1, when I unplug my
headset from the headset jack on my laptop, pulse no longer
automatically selects the laptop's internal speakers and microphones.
In pavucontrol, I see that pulse is detecting when the headset is
unplugged. The output port selection becomes "Headphones (unplugged)" and
the input device port selection becomes "Microphone (unplugged)". I can
manually select the laptop's speakers and microphones via pavucontrol
to get them working, but I have to do this every time I unplug my
headset.


-- Package-specific info:
File '/etc/default/pulseaudio' does not exist


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

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

Versions of packages pulseaudio depends on:
ii  adduser  3.118
ii  init-system-helpers  1.60
ii  libasound2   1.2.4-1.1
ii  libasound2-plugins   1.2.2-2
ii  libc62.31-9
ii  libcap2  1:2.44-1
ii  libdbus-1-3  1.12.20-1
ii  libgcc-s110.2.1-6
ii  libice6  2:1.0.10-1
ii  libltdl7 2.4.6-15
ii  liborc-0.4-0 1:0.4.32-1
ii  libpulse014.1-1
ii  libsm6   2:1.2.3-1
ii  libsndfile1  1.0.30-1
ii  libsoxr0 0.1.3-4
ii  libspeexdsp1 1.2~rc1.2-1.1
ii  libstdc++6   10.2.1-6
ii  libsystemd0  247.2-5
ii  libtdb1  1.4.3-1+b1
ii  libudev1 247.2-5
ii  libwebrtc-audio-processing1  0.3-1+b1
ii  libx11-6 2:1.7.0-2
ii  libx11-xcb1  2:1.7.0-2
ii  libxcb1  1.14-2.1
ii  libxtst6 2:1.2.3-1
ii  lsb-base 11.1.0
ii  pulseaudio-utils 14.1-1

Versions of packages pulseaudio recommends:
ii  dbus-user-session1.12.20-1
ii  libpam-systemd [logind]  247.2-5
ii  rtkit0.13-4

Versions of packages pulseaudio suggests:
pn  paprefs  
ii  pavucontrol  4.0-2
pn  pavumeter
ii  udev 247.2-5

-- no debconf information
# This file is part of PulseAudio.
#
# PulseAudio is free software; you can redistribute it and/or modify
# it under the terms of the GNU Lesser General Public License as published by
# the Free Software Foundation; either version 2 of the License, or
# (at your option) any later version.
#
# PulseAudio is distributed in the hope that it will be useful, but
# WITHOUT ANY WARRANTY; without even the implied warranty of
# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
# General Public License for more details.
#
# You should have received a copy of the GNU Lesser General Public License
# along with PulseAudio; if not, see .

## Configuration file for PulseAudio clients. See pulse-client.conf(5) for
## more information. Default values are commented out.  Use either ; or # for
## commenting.

; default-sink =
; default-source =
; default-server =
; default-dbus-server =

; autospawn = yes
; daemon-binary = /usr/bin/pulseaudio
; extra-arguments = --log-target=syslog

; cookie-file =

; enable-shm = yes
; shm-size-bytes = 0 # setting this 0 will use the system-default, usually 64 
MiB

; auto-connect-localhost = no
; auto-connect-display = no
# This file is part of PulseAudio.
#
# PulseAudio is free software; you can redistribute it and/or modify
# it under the terms of the GNU Lesser General Public License as published by
# the Free Software Foundation; either version 2 of the License, or
# (at your option) any later version.
#
# PulseAudio is distributed in the hope that it will be useful, but
# WITHOUT ANY WARRANTY; without even the implied warranty of
# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
# General Public License for more details.
#
# You should have received a copy of the GNU Lesser General Public License
# along with PulseAudio; if not, see .

## Configuration file for the PulseAudio daemon. See pulse-daemon.conf(5) for
## more information. Default values are commented out.  Use either ; or # for
## commenting.

; daemonize = no
; fail = yes
; allow-module-loading = yes
; allow-exit = yes
; use-pid-file = yes
; system-instance = no
; local-server-type = user
; enable-shm = yes
; enable-memfd = yes
; shm-size-bytes = 0 # setting this 0 will use the system-default, usually 64 
MiB
; lock-memory = 

Bug#980839: RFP: rnnoise -- noise suppression library based on a recurrent neural network

[Petter Reinholdtsen]

Control: retitle -1 RFP: rnnoise -- noise suppression library based on a 
recurrent neural network

I discovered in
https://github.com/xiph/rnnoise/issues/137 > that both Mumble and
OBS Studio can use rnnoise.  So three Debian packages would use it.

-- 
Happy hacking
Petter Reinholdtsen

Bug#980818: RFS: targetd/0.9.1-1 [ITP] -- remote configuration of a LIO-based storage appliance

[Johan Fleury]

Package: sponsorship-requests
Severity: wishlist

Dear mentors,

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

 * Package name: targetd
   Version : 0.9.1-1
   Upstream Author : Tony Asleson 
 * URL : https://github.com/open-iscsi/targetd
 * License : GPL-3.0+
 * Vcs : https://salsa.debian.org/python-team/applications/targetd
   Section : net

It builds those binary packages:

  targetd - remote configuration of a LIO-based storage appliance

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

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

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

  dget -x 
https://mentors.debian.net/debian/pool/main/t/targetd/targetd_0.9.1-1.dsc

Changes for the initial release:

 targetd (0.9.1-1) UNRELEASED; urgency=medium
 .
   * Initial release (Closes: #968297).

Special notes to the person that’ll review my package:

* I’ve created the git repository at : https://salsa.debian.org/Arcaik/targetd
* targetd won’t start if no password is set in the configuration, so I used 
debconf to ask the user for a password in the post install phase (falling back 
to generating a random one), but I’m not sure if I’m doing this correctly (I’m 
just running sed on the file).

Regards.

-- 

  Johan Fleury

signature.asc
Description: OpenPGP digital signature

Bug#976796: Sporadically fails to create virtualenv with Python 3.9

[Stefano Rivera]

Hi Russ (2020.12.07_18:22:07_-0700)
> FileNotFoundError: [Errno 2] No such file or directory: 
> '/home/eagle/tmp/test/lib/python3.9/site-packages/pkg_resources/_vendor/appdirs.py'
> 
> Running the command repeatedly will sometimes cause it to succeed, which
> makes me think there's some sort of race condition or parallelism happening.
> This also affects tox, so I think it's the module and not just the command
> line tool.

Hrm, never seen that. Are you still able to reproduce this?

Maybe try a --reset-app-data?

SR

-- 
Stefano Rivera
  http://tumbleweed.org.za/
  +1 415 683 3272

Bug#949977: ITP: libgnt -- GLib Ncurses Toolkit

[Richard Laager]

This obviously took me a long time to get to, but I finally have.

1. As discussed with Ari, I have adopted the Pidgin package. I also
   made a few cleanups at the same time. More extensive updating (e.g.
   to modern debhelper compat) will probably have to wait until after
   bullseye, given the impending freeze.
2. I have uploaded libgnt, which should hit the NEW queue.
3. I have a Pidgin 2.14.1 package prepared, which uses the libgnt
   package. As soon as libgnt clears NEW, I can upload pidgin.

--
Richard

Bug#700337: RFP: kibana --- heads up: upstream license change to the non-free SSPL

[Axel Beckert]

Hi again,

a lot of things and discussions are currently happening around the
license change of ElasticSeach and Kibana. Some of those are probably
also interesting in this context of packaging work of Kibana:

Axel Beckert wrote:
> just a heads up for everyone interested in seeing Kibana (and maybe
> ElasticSearch) in Debian:
> 
> The license for Kibana and ElasticSearch is changing:
> https://www.elastic.co/de/blog/licensing-change

For those who still would like to see Kibana being packaged for
Debian, there's a fork of the old code underway under the previous
license (Apache License 2.0) by AWS and several other companies:

https://aws.amazon.com/de/blogs/opensource/stepping-up-for-a-truly-open-source-elasticsearch/
https://logz.io/blog/truly-doubling-down-on-open-source-2/

> And this SSPL is exactly what caused MongoDB to be removed from Debian
> as it is considered non-free. See these bug reports, especially the
> first one, for details:
> 
> https://bugs.debian.org/915537 (ftp.debian.org: MongoDB SSPL v1
> license and the DFSG)

Citing from that bug report:

  MongoDB has submitted the license to OSI for review[2]; the
  discussion there is still ongoing, but the initial response seems to
  be negative.

That application process got withdrawn by the license steward from
MongoDB due to mainly negative feedback:
http://lists.opensource.org/pipermail/license-review_lists.opensource.org/2019-March/003989.html

But Elastic's move to SSPL seems to have triggered an explicit
statement of the OSI on the SSPL: https://opensource.org/node/1099 —
And the headline is quite clear: "The SSPL is Not an Open Source
License"

That statement sparked quite some discussion on Twitter:
https://twitter.com/OpenSourceOrg/status/1351605387347324929

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

Bug#980841: fpc: Please add workaround patch to fix FTBFS on m68k

[John Paul Adrian Glaubitz]

Source: fpc
Severity: normal
Tags: patch
User: debian-...@lists.debian.org
Usertags: m68k
X-Debbugs-Cc: debian-...@lists.debian.org,char...@scenergy.dfmk.hu

Hello!

The attached patch contains a change suggested by Károly Balogh from
upstream to work around the current FPU issue on m68k [1].

With the patch applied, I was able to bootstrap fpc for m68k natively
and uploaded the resulting binaries.

Thus, please drop the current m68k patch [2] and replace it with the
attached one to fix the FTBFS until the upstream bug [1] has been
fixed.

Thanks,
Adrian

> [1] https://bugs.freepascal.org/view.php?id=37250
> [2] 
> https://salsa.debian.org/pascal-team/fpc/-/blob/master/debian/patches/fix-FTBFS-on-m68k.patch

--
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913
Description: Disable FPU inlining on m68k
 There is a bug in the FPU code on m68k which causes the
 bootstrap to fail (upstream bug #37250). Until the bug
 has been fixed, disable FPU inlining to work around the
 issue and fix the bootstrap on m68k.
 .
Author: John Paul Adrian Glaubitz 
Forwarded: https://bugs.freepascal.org/view.php?id=37250
Last-Update: 2021-01-22

--- fpc-3.2.0+dfsg.orig/fpcsrc/compiler/m68k/n68kadd.pas
+++ fpc-3.2.0+dfsg/fpcsrc/compiler/m68k/n68kadd.pas
@@ -148,10 +148,7 @@ implementation
 
 function t68kaddnode.inlineable_realconstnode(const n: tnode): boolean;
   begin
-result:=(n.nodetype = realconstn) and
-not ((trealconstnode(n).value_real=MathInf.Value) or
- (trealconstnode(n).value_real=MathNegInf.Value) or
- (trealconstnode(n).value_real=MathQNaN.value));
+result:=false;
   end;
 
 

Bug#980204: gdc: Resulting executables segfault on mipsel architecture (signal 11)

[Iain Buclaw]

Excerpts from Iain Buclaw's message of January 22, 2021 8:14 pm:
> Excerpts from Matija Nalis's message of January 22, 2021 5:51 pm:
>> On Fri, Jan 22, 2021 at 12:59:34PM +0100, Iain Buclaw wrote:
>>> Also, are you linking to the static or shared libphobos library?
>> 
>> shared (default):
>> 
>> (mipsel-chroot):/tmp/w$ dpkg -l gdc | grep gdc
>> ii  gdc4:10.2.1-1   mipsel   D compiler (language version 
>> 2), based on the GCC backend
>> 
>> (mipsel-chroot):/tmp/w$ printf 'import std.stdio;\nvoid main()  { 
>> writeln("Hello, World!"); }\n' > hello.d ; gdc hello.d && ./a.out
>> qemu: uncaught target signal 11 (Segmentation fault) - core dumped
>> Segmentation fault
>> 
>> (mipsel-chroot):/tmp/w$ file a.out
>> a.out: ELF 32-bit LSB pie executable, MIPS, MIPS32 rel2 version 1 (SYSV), 
>> dynamically linked, interpreter /lib/ld.so.1, 
>> BuildID[sha1]=36c5576b94519b416c1996018760159ae925bc34, for GNU/Linux 3.2.0, 
>> not stripped
>> 
>> (mipsel-chroot):/tmp/w$ ldd a.out
>> libgphobos.so.1 => /lib/mipsel-linux-gnu/libgphobos.so.1 (0x7f1a3000)
>> libgcc_s.so.1 => /lib/mipsel-linux-gnu/libgcc_s.so.1 (0x7f16b000)
>> libc.so.6 => /lib/mipsel-linux-gnu/libc.so.6 (0x7efd1000)
>> libm.so.6 => /lib/mipsel-linux-gnu/libm.so.6 (0x7ef52000)
>> libpthread.so.0 => /lib/mipsel-linux-gnu/libpthread.so.0 (0x7ef21000)
>> libdl.so.2 => /lib/mipsel-linux-gnu/libdl.so.2 (0x7ef0d000)
>> libz.so.1 => /lib/mipsel-linux-gnu/libz.so.1 (0x7eee2000)
>> /lib/ld.so.1 (0x7ffc9000)
>> 
>> 
>> But good point, when I try to link this "hello world" example statically, it
>> throws warnings, but works!
>> 
>> (mipsel-chroot):/tmp/w$ printf 'import std.stdio;\nvoid main()  { 
>> writeln("Hello, World!"); }\n' > hello.d ; gdc -static hello.d && ./a.out
>> /usr/bin/ld: /usr/lib/gcc/mipsel-linux-gnu/10/libgphobos.a(elf_shared.o): in 
>> function `_D3gcc8sections10elf_shared18pinLoadedLibrariesFNbNiZPv':
>> /build/gcc-10-XdUysA/gcc-10-10.2.1/build/mipsel-linux-gnu/libphobos/libdruntime/../../../../src/libphobos/libdruntime/gcc/sections/elf_shared.d:250:
>>  warning: Using 'dlopen' in statically linked applications requires at 
>> runtime the shared libraries from the glibc version used for linking
>> /usr/bin/ld: /usr/lib/gcc/mipsel-linux-gnu/10/libgphobos.a(stdio.o): in 
>> function `_D3std5stdio11openNetworkFAyatZS3std5stdio4File':
>> /build/gcc-10-XdUysA/gcc-10-10.2.1/build/mipsel-linux-gnu/libphobos/src/../../../../src/libphobos/src/std/stdio.d:5137:
>>  warning: Using 'gethostbyname' in statically linked applications requires 
>> at runtime the shared libraries from the glibc version used for linking
>> Hello, World!
>> 
> 
> I've just checked the testsuite result, and the only failed tests are
> those that use -shared-libphobos.
> 
> FAIL: gdc.test/runnable/implicit.d -shared-libphobos   execution test
> FAIL: gdc.test/runnable/test31.d -shared-libphobos   execution test
> FAIL: gdc.test/runnable/testarray.d -shared-libphobos   execution test
> FAIL: gdc.test/runnable/Same.d -shared-libphobos   execution test
> FAIL: gdc.test/runnable/s2ir.d -shared-libphobos   execution test
> FAIL: gdc.test/runnable/test9309.d -shared-libphobos   execution test
> FAIL: gdc.test/runnable/test15.d -shared-libphobos   execution test
> etc...
> 
> 

So the crux of the matter is that on MIPS, dynamic sections are read-only
(glibc sets DL_RO_DYN_SECTION 1), which requires special handling when pulling
data from dl_phdr_info.

Re-running with the attached patch applied.

Iain.

--- a/libphobos/libdruntime/gcc/sections/elf_shared.d
+++ b/libphobos/libdruntime/gcc/sections/elf_shared.d
@@ -22,6 +22,8 @@
 
 module gcc.sections.elf_shared;
 
+version (MIPS32)  version = MIPS_Any;
+version (MIPS64)  version = MIPS_Any;
 version (RISCV32) version = RISCV_Any;
 version (RISCV64) version = RISCV_Any;
 version (S390)version = IBMZ_Any;
@@ -763,6 +765,8 @@ version (Shared)
 // in glibc: #define DL_RO_DYN_SECTION 1
 version (RISCV_Any)
 strtab = cast(const(char)*)(info.dlpi_addr + 
dyn.d_un.d_ptr); // relocate
+else version (MIPS_Any)
+strtab = cast(const(char)*)(info.dlpi_addr + 
dyn.d_un.d_ptr); // relocate
 else
 strtab = cast(const(char)*)dyn.d_un.d_ptr;
 }

Bug#980202: FTBFS: gscan2pdf tests fail

[Bastien ROUCARIES]

Hi,

Just uploaded 6.9.11-58 as suggested by upstream.

No changes unfortunately

Bastien

Le ven. 22 janv. 2021 à 19:30, Cristy  a écrit :
>
> Subject "convert fails to create image with text" claims
>
> convert +matte -depth 1 -colorspace Gray -pointsize 12 -units PixelsPerInch 
> -density 300 label:"The quick brown fox" test.png
>
> returns unexpected results. We tried the command with ImageMagick 6.9.11-58 
> and get expected results under Fedora 33 and Debian 4.19.160-2 I686. Can you 
> try -58 on your system? Do you get expected results (test-old.png from bug 
> report)?
>
> Thanks,
>
> ImageMagick Development Team

Bug#979352: r-cran-pander_0.6.3+dfsg-1_amd64.changes REJECTED

[Thorsten Alteholz]

Hi Andreas,

there are several lintian warnings about privacy breach. Maybe you can take 
care of them.
For example the script mentioned in pander/inst/includes/html/header.html is no 
longer available, so the software might not even work ...

  Thorsten



===

Please feel free to respond to this email if you don't understand why
your files were rejected, or if you upload new files which address our
concerns.


___
R-pkg-team mailing list
r-pkg-t...@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/r-pkg-team

Bug#980849: apt fails to reject repositories with invalid InRelease file

[Wouter Verhelst]

Package: apt
Version: 2.1.18
Severity: important

Hi,

I maintain the extrepo package[1], a tool to manage external (i.e.,
third-party, non-Debian) repositories.

As part of that, the extrepo-data repository on salsa[2] manages
metadata for repositories. In a GitLab CI job, I validate that the
repositories do not contain anything that is not valid before accepting
them to the metadata repository.

One of the checks is to validate the InRelease file.

Currently, there are two merge requests open[3] for repositories on
which my script fails while trying to verify the InRelease file.

It turns out that these repositories return data for the InRelease file
-- i.e., a file that has checksums and is signed by some tool -- but the
signature is invalid. The repository also has a Release/Release.gpg
pair, where the signature *is* valid.

Apt should probably produce a warning (if not an error) on such
repositories; it currently does not seem to do that.

[1] https://packages.debian.org/extrepo
[2] https://salsa.debian.org/extrepo-team/extrepo-data
[3] https://salsa.debian.org/extrepo-team/extrepo-data/-/merge_requests/65
and .../66

Bug#980835: buster-pu: fcitx/1:4.2.9.6-5+deb10u1

[Paul Gevers]

Hi Boyuan,

On 22-01-2021 23:55, Boyuan Yang wrote:
> Current fcitx v4.2.9.6 in Debian 10 has a broken implementation to
> flatpak support. As a result, software installed via flatpak cannot
> enable fcitx as the active input method. The corresponding Debian bug
> report is at https://bugs.debian.org/980268 .

I think you mean https://bugs.debian.org/980834.

Paul



OpenPGP_signature
Description: OpenPGP digital signature

Bug#980809: [R-pkg-team] Bug#980809: rmatrix: breaks autopkgtest of r-cran-glmmtmb on s390x

[Graham Inggs]

Hi Dirk

On Fri, 22 Jan 2021 at 23:38, Dirk Eddelbuettel  wrote:
> Can you still please talk to the corresponding Debian maintainer for glmmTMB
> so that he/she can walk it upstream?

I have assigned this bug to both packages, until we can figure out
where the fix needs to happen.

> The package is clean where it matters:
> https://cloud.r-project.org/web/checks/check_results_glmmTMB.html

Are they doing any tests on big-endian architectures?  Remember s390x
is our only big-endian release architecture, and r-cran-glltmb's
autopkgtests have green lights on all our little-endian architectures,
so this hints to an endianness bug to me.

Regards
Graham

Bug#980845: sumo-tools: missing Breaks+Replaces: sumo (<< 1.8)

[Andreas Beckmann]

Package: sumo-tools
Version: 1.8.0+dfsg2-3
Severity: serious
User: debian...@lists.debian.org
Usertags: piuparts

Hi,

during a test with piuparts I noticed your package fails to upgrade from
'testing'.
It installed fine in 'testing', then the upgrade to 'sid' fails
because it tries to overwrite other packages files without declaring a
Breaks+Replaces relation.

See policy 7.6 at
https://www.debian.org/doc/debian-policy/ch-relationships.html#overwriting-files-and-replacing-packages-replaces

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

  Preparing to unpack .../sumo-tools_1.8.0+dfsg2-3_all.deb ...
  Unpacking sumo-tools (1.8.0+dfsg2-3) ...
  dpkg: error processing archive 
/var/cache/apt/archives/sumo-tools_1.8.0+dfsg2-3_all.deb (--unpack):
   trying to overwrite '/usr/share/sumo/data/3D/car-microcargo-citrus.mtl', 
which is also in package sumo 1.4.0+dfsg1-1+b2
  dpkg-deb: error: paste subprocess was killed by signal (Broken pipe)
  Errors were encountered while processing:
   /var/cache/apt/archives/sumo-tools_1.8.0+dfsg2-3_all.deb


There is also a typo in the sumo-tools description:
  The binary contatins different tools and scripts.
 ^

cheers,

Andreas


sumo=1.4.0+dfsg1-1+b2_sumo-tools=1.8.0+dfsg2-3.log.gz
Description: application/gzip

Bug#976796: Sporadically fails to create virtualenv with Python 3.9

[Russ Allbery]

Stefano Rivera  writes:
> Hi Russ (2020.12.07_18:22:07_-0700)
>> FileNotFoundError: [Errno 2] No such file or directory: 
>> '/home/eagle/tmp/test/lib/python3.9/site-packages/pkg_resources/_vendor/appdirs.py'
>> 
>> Running the command repeatedly will sometimes cause it to succeed, which
>> makes me think there's some sort of race condition or parallelism happening.
>> This also affects tox, so I think it's the module and not just the command
>> line tool.

> Hrm, never seen that. Are you still able to reproduce this?

No, I think it may have been fixed, or at least it's not still happening
for me.

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

Bug#973454: firmware-iwlwifi: firmware does not load with error -110 with Intel 8260

[maximilian attems]

On Fri, Jan 22, 2021 at 10:16:36PM +0100, Paweł Różański wrote:
> On 22.01.2021 21:44, maximilian attems wrote:
> > > Version: 20200918-1
> > 
> > > [   12.411452] iwlwifi :01:00.0: Failed to start INIT ucode: -110
> > > [   12.411500] iwlwifi :01:00.0: Collecting data: trigger 16 fired.
> > > [   13.566350] iwlwifi :01:00.0: Failed to run INIT ucode: -110
> > > uanme -rvm
> > > 5.9.0-1-amd64 #1 SMP Debian 5.9.1-1 (2020-10-17) x86_64
> > > (also tested on 5.7.0-2-amd64 #1 SMP Debian 5.7.10-1 (2020-07-26) x86_64 
> > > - the same)
> > > 
> > > Used to work fine before reboot with 5.7 kernel.
> > > Can provide additional information if needed.
> > 
> > Is this still happening with 5.10 linux and newer iwlwifi version >=
> > 202011?
> 
> 
>  Using 5.10.0-1-amd64 and 20200918-1 till now. Just upgraded to 20201218-2,
> but didn't reboot yet.
>  Issue never repeated since I sent this report.

thanks for patience and prompt report, this looks like to be fixed in
iwlwifi then.

I'll leave it open for a week and will then proceed to close unless
repeatable.

Bug#973742: Bad microSD Card

[Salvatore Bonaccorso]

Hi Gregor,

On Thu, Jan 21, 2021 at 04:23:02PM +0100, Gregor Horvath wrote:
> This was probably because of an dying microSD Card where the kernel was
> installed.
> Because 2 months later also the 4.9.0-13 kernel on hold had boot
> problems. [1]
> After reinstalling Debian Stretch with 4.9.0-14 on an SSD instead of
> microSD (except u-boot) everything runs fine.
> 
> [1] https://www.olimex.com/forum/index.php?topic=8028.0

thanks for reporting back. In this case I guess we can close this
bugreport.

Regards,
Salvatore

Bug#980833: geany-plugins: markdown-plugin is missing

[Simon Widmer]

Package: geany-plugin-markdown
Version: 1.33

When I install geany and all plugins available, markdown cannot be chosen in 
the geany plugin-manager
because the plugin is simply missing.

After compiling geany manually and also the plugins, markdown was available...
Must be a dependency problem at debian with a missing library somehow...?


Best regards,

Simon Widmer

Bug#980840: xfce4-genmon-plugin: The plugin is shoved into one row in sidebar mode in 4.16

[Горбешко Богдан]

Package: xfce4-genmon-plugin
Version: 4.1.0-1
Severity: important

Dear Maintainer,

after upgrading the panel from 4.14.4, and all the applets (this one 
from 4.0.2 exactly), the displaying of the genmon plugin got broken.


Before: https://pic4a.ru/11/mtO.png
After: https://pic4a.ru/11/3lC.png

This sidebar has 5 rows, and genmon occupies only one of it, instead of 
expanding to the full width.




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

Kernel: Linux 5.8.0-3-amd64 (SMP w/2 CPU threads)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_WARN, TAINT_CRAP, 
TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=ru_UA.UTF-8, LC_CTYPE=ru_UA.UTF-8 (charmap=UTF-8), 
LANGUAGE=ru_UA:ru

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

Versions of packages xfce4-genmon-plugin depends on:
ii  libc6    2.31-3
ii  libglib2.0-0 2.66.0-2
ii  libgtk-3-0   3.24.23-1
ii  libpango-1.0-0   1.46.2-1
ii  libxfce4panel-2.0-4  4.16.0-1
ii  libxfce4ui-2-0   4.16.0-1
ii  libxfce4util7    4.16.0-1

xfce4-genmon-plugin recommends no packages.

xfce4-genmon-plugin suggests no packages.

-- no debconf information

Bug#980061: caribou: diff for NMU version 0.4.21-7.1

[Fabio Fantoni]

Control: tags 980061 + pending

Dear maintainer,

As this is older than 7 days and no maintainer activity about this bug
and it cause security issue to cinnamon (that I think should be solved
ASAP);
I've prepared an NMU for caribou (versioned as 0.4.21-7.1) and will be
uploaded.

Regards.

diff -Nru caribou-0.4.21/debian/changelog caribou-0.4.21/debian/changelog
--- caribou-0.4.21/debian/changelog    2018-12-24 00:18:21.0 +0100
+++ caribou-0.4.21/debian/changelog    2021-01-15 15:49:43.0 +0100
@@ -1,3 +1,11 @@
+caribou (0.4.21-7.1) unstable; urgency=high
+
+  * Non-maintainer upload.
+  * Fix segfault (regression of xorg CVE-2020-25712 fix) that
+    cause security issue for cinnamon (Closes: #980061)
+
+ -- Fabio Fantoni   Fri, 15 Jan 2021 15:49:43
+0100
+
 caribou (0.4.21-7) unstable; urgency=medium
 
   * Restore -Wl,-O1 to our LDFLAGS
diff -Nru caribou-0.4.21/debian/patches/Fix-compilation-error.patch
caribou-0.4.21/debian/patches/Fix-compilation-error.patch
--- caribou-0.4.21/debian/patches/Fix-compilation-error.patch   
1970-01-01 01:00:00.0 +0100
+++ caribou-0.4.21/debian/patches/Fix-compilation-error.patch   
2021-01-15 15:49:43.0 +0100
@@ -0,0 +1,24 @@
+From bc6f3e7ca0921b50a3ff836d08ce264a4f114224 Mon Sep 17 00:00:00 2001
+From: Clement Lefebvre 
+Date: Tue, 12 Jan 2021 17:29:16 +
+Subject: [PATCH 1/4] Fix compilation error
+
+---
+ libcaribou/key-model.vala | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/libcaribou/key-model.vala b/libcaribou/key-model.vala
+index 89015bc..e88342e 100644
+--- a/libcaribou/key-model.vala
 b/libcaribou/key-model.vala
+@@ -101,7 +101,7 @@ namespace Caribou {
+ unichar uc;
+ while (text.get_next_char (ref index, out uc)) {
+ uint keyval = Gdk.unicode_to_keyval (uc);
+-    if (keyval != uc | 0x0100)
++    if (keyval != (uc | 0x0100))
+ _keyvals += keyval;
+ }
+ } else {
+--
+2.29.2
diff -Nru
caribou-0.4.21/debian/patches/Fix-subkey-popmenu-not-showing-after-being-dismissed.patch
caribou-0.4.21/debian/patches/Fix-subkey-popmenu-not-showing-after-being-dismissed.patch
---
caribou-0.4.21/debian/patches/Fix-subkey-popmenu-not-showing-after-being-dismissed.patch
   
1970-01-01 01:00:00.0 +0100
+++
caribou-0.4.21/debian/patches/Fix-subkey-popmenu-not-showing-after-being-dismissed.patch
   
2021-01-15 15:49:43.0 +0100
@@ -0,0 +1,31 @@
+From 85ac8f9e210243d95163cf8b1013470a6d9c7eaa Mon Sep 17 00:00:00 2001
+From: Clement Lefebvre 
+Date: Tue, 12 Jan 2021 17:30:25 +
+Subject: [PATCH 2/4] Fix subkey popmenu not showing after being dismissed
+
+To reproduce the issue:
+
+- long-press the "e" button
+- don't select any sub button.. just select "e" again to close the menu
+
+After this the menu no long appears when long-pressing "e".
+
+This commit fixes that.
+---
+ libcaribou/key-model.vala | 1 +
+ 1 file changed, 1 insertion(+)
+
+diff --git a/libcaribou/key-model.vala b/libcaribou/key-model.vala
+index e88342e..2f640f2 100644
+--- a/libcaribou/key-model.vala
 b/libcaribou/key-model.vala
+@@ -179,6 +179,7 @@ namespace Caribou {
+ hold_tid = GLib.Timeout.add (1000, on_key_held);
+
+ key_pressed(this);
++    show_subkeys = false;
+ }
+
+ public void release () {
+--
+2.29.2
diff -Nru caribou-0.4.21/debian/patches/series
caribou-0.4.21/debian/patches/series
--- caribou-0.4.21/debian/patches/series    2018-12-24
00:18:21.0 +0100
+++ caribou-0.4.21/debian/patches/series    2021-01-15
15:49:43.0 +0100
@@ -1,2 +1,5 @@
 autostart-set-nodisplay.patch
 fix-font-property-in-style.css.patch
+Fix-compilation-error.patch
+Fix-subkey-popmenu-not-showing-after-being-dismissed.patch
+xadapter.vala-Remove-XkbKeyTypesMask-and-f.patch
diff -Nru
caribou-0.4.21/debian/patches/xadapter.vala-Remove-XkbKeyTypesMask-and-f.patch
caribou-0.4.21/debian/patches/xadapter.vala-Remove-XkbKeyTypesMask-and-f.patch
---
caribou-0.4.21/debian/patches/xadapter.vala-Remove-XkbKeyTypesMask-and-f.patch  
 
1970-01-01 01:00:00.0 +0100
+++
caribou-0.4.21/debian/patches/xadapter.vala-Remove-XkbKeyTypesMask-and-f.patch  
 
2021-01-15 15:49:43.0 +0100
@@ -0,0 +1,46 @@
+From 00653c5dcc4be5e983b670d00d5724fc21da2e82 Mon Sep 17 00:00:00 2001
+From: Clement Lefebvre 
+Date: Tue, 12 Jan 2021 18:01:47 +
+Subject: [PATCH 3/4] [mtwebster] xadapter.vala: Remove XkbKeyTypesMask and
+ fields from XKbChangeMap call.
+MIME-Version: 1.0
+Content-Type: text/plain; charset=UTF-8
+Content-Transfer-Encoding: 8bit
+
+This was originally a workaround for xFree86 4.3 - see:
+https://bugzilla.gnome.org/show_bug.cgi?id=673547
+​
+As of https://gitlab.freedesktop.org/xorg/xserver/-/commit/87c64fc5b0 this
+causes a BadLength error when attempting to use shifted characters.
+​
+Ref:

Bug#971515: CTTE decision on "kubernetes: excessive vendoring (private libraries)"

[Dmitry Smirnov]

On Saturday, 23 January 2021 3:18:52 AM AEDT Shengjing Zhu wrote:
> The real complex things are, dealing license and copyright and *NEW* queue.
> If this TC decision is that we just trust what upstream say, then why not
> just unvendor them. Then many pieces of libraries can be reused by others.

Even without packaging new libraries, we could do so much better un-vendoring
some of already packaged ones, even if maintainer focuses only on those that
are _easy_ to un-vendor. Vendoring _everything_ is crazy, unnecessary,
irrational...

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

---

People are rarely grateful for a demonstration of their credulity.
-- Carl Sagan


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

Bug#974839: [Help] Test failures in q2-feature-classifier

[Andreas Tille]

Hi,

thanks to Nilesh and ftpmaster finally the needed dependencies for
q2-feature-classifier are available.  Unfortunately when I tried to
build the package there where some test failures in autopkgtest:

...
 test session starts ==
platform linux -- Python 3.9.1+, pytest-6.0.2, py-1.10.0, pluggy-0.13.0
rootdir: /build/q2-feature-classifier-2020.11.1
plugins: cov-2.10.1
collected 0 items / 5 errors

 ERRORS 
_ ERROR collecting 
.pybuild/cpython3_3.9/build/q2_feature_classifier/tests/test_classifier.py _
ImportError while importing test module 
'/build/q2-feature-classifier-2020.11.1/.pybuild/cpython3_3.9/build/q2_feature_classifier/tests/test_classifier.py'.
Hint: make sure your test modules/packages have valid Python names.
Traceback:
/usr/lib/python3.9/importlib/__init__.py:127: in import_module
return _bootstrap._gcd_import(name[level:], package, level)
q2_feature_classifier/tests/test_classifier.py:14: in 
from qiime2.plugins import feature_classifier
E   ImportError: cannot import name 'feature_classifier' from 'qiime2.plugins' 
(/usr/lib/python3/dist-packages/qiime2/plugins.py)
_ ERROR collecting 
.pybuild/cpython3_3.9/build/q2_feature_classifier/tests/test_consensus_assignment.py
 _
ImportError while importing test module 
'/build/q2-feature-classifier-2020.11.1/.pybuild/cpython3_3.9/build/q2_feature_classifier/tests/test_consensus_assignment.py'.
Hint: make sure your test modules/packages have valid Python names.
Traceback:
/usr/lib/python3.9/importlib/__init__.py:127: in import_module
return _bootstrap._gcd_import(name[level:], package, level)
q2_feature_classifier/tests/test_consensus_assignment.py:12: in 
from qiime2.plugins import feature_classifier
E   ImportError: cannot import name 'feature_classifier' from 'qiime2.plugins' 
(/usr/lib/python3/dist-packages/qiime2/plugins.py)
_ ERROR collecting 
.pybuild/cpython3_3.9/build/q2_feature_classifier/tests/test_custom.py _
ImportError while importing test module 
'/build/q2-feature-classifier-2020.11.1/.pybuild/cpython3_3.9/build/q2_feature_classifier/tests/test_custom.py'.
Hint: make sure your test modules/packages have valid Python names.
Traceback:
/usr/lib/python3.9/importlib/__init__.py:127: in import_module
return _bootstrap._gcd_import(name[level:], package, level)
q2_feature_classifier/tests/test_custom.py:12: in 
from qiime2.plugins import feature_classifier
E   ImportError: cannot import name 'feature_classifier' from 'qiime2.plugins' 
(/usr/lib/python3/dist-packages/qiime2/plugins.py)
_ ERROR collecting 
.pybuild/cpython3_3.9/build/q2_feature_classifier/tests/test_cutter.py _
...

My guess is that this is some simple (PYTHON)PATH issue but I'm busy
with real life this weekend and it would be great to have another
RC bug off the table.

Kind regards

  Andreas.

-- 
http://fam-tille.de

Bug#980764: libc6-dev: wrong return value for fputs when STDOUT_FILENO was closed()

[Florian Weimer]

* Bérenger:

> When running following code:
>
> ```C
> #include 
> #include 
> #include 
>
> int main()
> {
>   close( STDIN_FILENO );
>   close( STDOUT_FILENO );
>   int fd = dup( STDERR_FILENO );
>   close( STDERR_FILENO );
>   if( -1 == fprintf( stdout, "%d\n", fd ) )
>   {
>   return -1;
>   }
>
>   char s[] = "should fail\n";
>   if( -1 == write( STDOUT_FILENO, s, sizeof( s ) ) )
>   {
>   return -2;
>   }
>   return EXIT_SUCCESS;
> }
> ```
>
> built with glibc, the program returns 254. When built with muslc, it
> returns the expected value of 255.
>
> I believe glibc's behavior here is wrong. From what I could get by using
> strace, it seems that the 1st printf's write() call is ran _after_ the
> 2nd one, even when adding a call to fflush( stdout ) right after the
> printf.

The reason for the glibc behavior is that stdout ends up as a buffered
stream because it is not a terminal.  Why do you think this is a bug?

Bug#980751: petsc: breaks multiple autopkgtests: undefined reference to 'MPIU_SUM'

[Drew Parsons]

Source: dolfin
Followup-For: Bug #980751

Possibly related to the conditional declaration for petsc in
/usr/include/petsc/petscsys.h:

#if (defined(PETSC_HAVE_COMPLEX) && !defined(PETSC_HAVE_MPI_C_DOUBLE_COMPLEX)) 
|| defined(PETSC_USE_REAL___FLOAT128) || defined(PETSC_USE_REAL___FP16)
PETSC_EXTERN MPI_Op MPIU_SUM;
#else
#define MPIU_SUM MPI_SUM
#endif



Not obvious why these conditions would have changed between builds though.

Drew

Bug#980842: pytest-mpi: Tests test_mpi_with_mpi and test_mpi_only_mpi fail

[Drew Parsons]

Source: pytest-mpi
Version: 0.4-3
Severity: normal
Control: forwarded -1 https://github.com/aragilar/pytest-mpi/issues/14

After applying upstream PR#12 (https://github.com/aragilar/pytest-mpi/pull/12)
in debian/patches/fix_pytest6_PR12.patch, tests test_mpi_with_mpi and
test_mpi_only_mpi still fail with pytest 6.0.2-2.

An error "ValueError: mpi mark does not take positional args" is
easily fixed with
-@pytest.mark.mpi(2)
+@pytest.mark.mpi(min_size=2)
 def test_size_fail_pos():
in tests/test_markers.py

But then there are other errors:
$ python3 -m pytest -k "test_mpi_with_mpi or test_mpi_only_mpi" -p pytester -vv
...
_ test_mpi_with_mpi _

mpi_testdir = , has_mpi4py = 
True

def test_mpi_with_mpi(mpi_testdir, has_mpi4py):
mpi_testdir.makepyfile(MPI_TEST_CODE)

result = mpi_testdir.runpytest("--with-mpi")

if has_mpi4py:
>   result.assert_outcomes(passed=3, errors=1, skipped=1)
E   AssertionError: assert {'errors': 0,\n 'failed': 0,\n 'passed': 
4,\n 'skipped': 1,\n 'xfailed': 0,\n 'xpassed': 0} == {'errors': 1,\n 'failed': 
0,\n 'passed': 3,\n 'skipped': 1,\n 'xfailed': 0,\n 'xpassed': 0}
E Common items:
E {'failed': 0, 'skipped': 1, 'xfailed': 0, 'xpassed': 0}
E Differing items:
E {'passed': 4} != {'passed': 3}
E {'errors': 0} != {'errors': 1}
E Full diff:
E   {
E -  'errors': 1,
E ?^
E +  'errors': 0,
E ?^
E'failed': 0,
E -  'passed': 3,
E ?^
E +  'passed': 4,
E ?^
E'skipped': 1,
E'xfailed': 0,
E'xpassed': 0,
E   }

/projects/python/build/pytest-mpi/tests/test_markers.py:70: AssertionError



Likewise for test_mpi_only_mpi.

Reported upstream at https://github.com/aragilar/pytest-mpi/issues/14


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

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

Bug#957317: gtkboard: diff for NMU version 0.11pre0+cvs.2003.11.02-10.1

[Barak A. Pearlmutter]

Thank you! I'll merge your fix and do a non-NMU when I get a chance.

For future ref, no need to delay or even NMU. I don't mind my packages
getting a little TLC.

Bug#980829: imlib2: drop obsolete libltdl3-dev dependency

[Helmut Grohne]

Source: imlib2
Version: 1.7.1-1
Tags: patch
User: helm...@debian.org
Usertags: rebootstrap

imlib2 participates in a number of dependency cycles relevant to
architecture bootstrap. Instead of looking into this, I looked for
easily droppable dependencies and notices that libltdl3-dev is no longer
needed. It is mentioned in the ChangeLog as removed and can be dropped
with no replacement. Please consider applying the attached patch.

Helmut
diff --minimal -Nru imlib2-1.7.1/debian/changelog imlib2-1.7.1/debian/changelog
--- imlib2-1.7.1/debian/changelog   2020-12-13 18:41:51.0 +0100
+++ imlib2-1.7.1/debian/changelog   2021-01-22 22:41:46.0 +0100
@@ -1,3 +1,10 @@
+imlib2 (1.7.1-1.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Drop obsolete libltdl3-dev dependency. (Closes: #-1)
+
+ -- Helmut Grohne   Fri, 22 Jan 2021 22:41:46 +0100
+
 imlib2 (1.7.1-1) unstable; urgency=medium
 
   * New upstream version 1.7.1.
diff --minimal -Nru imlib2-1.7.1/debian/control imlib2-1.7.1/debian/control
--- imlib2-1.7.1/debian/control 2020-12-13 18:41:51.0 +0100
+++ imlib2-1.7.1/debian/control 2021-01-22 22:41:45.0 +0100
@@ -9,7 +9,6 @@
  libgif-dev,
  libid3tag0-dev,
  libjpeg-dev,
- libltdl3-dev,
  libpng-dev,
  libtiff-dev,
  libwebp-dev,

Bug#980830: gcr FTBFS with nocheck profile

[Helmut Grohne]

Source: gcr
Version: 3.38.1-1
Severity: important
Tags: patch ftbfs

gcr fails to build from source when disabling tests via the nocheck
profile and option. Once doing so, meson fails hard when it finds that
gpg is missing. Please consider applying the attached patch to
unannotate the gnupg dependency.

Helmut
diff --minimal -Nru gcr-3.38.1/debian/changelog gcr-3.38.1/debian/changelog
--- gcr-3.38.1/debian/changelog 2021-01-14 17:26:53.0 +0100
+++ gcr-3.38.1/debian/changelog 2021-01-22 22:47:04.0 +0100
@@ -1,3 +1,10 @@
+gcr (3.38.1-1.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix FTBFS with nocheck profile. (Closes: #-1)
+
+ -- Helmut Grohne   Fri, 22 Jan 2021 22:47:04 +0100
+
 gcr (3.38.1-1) unstable; urgency=medium
 
   * New upstream release
diff --minimal -Nru gcr-3.38.1/debian/control gcr-3.38.1/debian/control
--- gcr-3.38.1/debian/control   2021-01-14 17:26:53.0 +0100
+++ gcr-3.38.1/debian/control   2021-01-22 22:47:03.0 +0100
@@ -12,7 +12,7 @@
dh-sequence-gir,
dh-sequence-gnome,
docbook-xml,
-   gnupg ,
+   gnupg,
gtk-doc-tools (>= 1.9),
libdbus-1-dev (>= 1.0),
libgcrypt20-dev (>= 1.4.5),

Bug#980831: libimobiledevice: reduce Build-Depends

[Helmut Grohne]

Source: libimobiledevice
Version: 1.3.0-5
Tags: patch
User: helm...@debian.org
Usertags: rebootstrap

libimobiledevice participates in a number of dependency cycles relevant
to architecture bootstrap. Instead of looking into that, I looked into
easily droppable dependencies. I found that libreadline-dev is entirly
unused. I also observe that libimobiledevice is build with openssl and
thus libgcrypt20-dev and libtasn1-6-dev are also unused. Furthermore, it
only uses libplist-dev and not libplist++-dev. Please consider dropping
the mentioned dependencies. I'm attaching a patch for your convenience.

Helmut
diff --minimal -Nru libimobiledevice-1.3.0/debian/changelog 
libimobiledevice-1.3.0/debian/changelog
--- libimobiledevice-1.3.0/debian/changelog 2020-09-17 11:05:35.0 
+0200
+++ libimobiledevice-1.3.0/debian/changelog 2021-01-22 22:52:52.0 
+0100
@@ -1,3 +1,14 @@
+libimobiledevice (1.3.0-5.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Reduce Build-Depends: (Closes: #-1)
++ Drop unused libreadline-dev.
++ Drop unused libgcrypt20-dev and libtasn1-6-dev as libimobiledevice is
+  built with openssl.
++ Drop unused libplist++-dev as it only uses libplist-dev.
+
+ -- Helmut Grohne   Fri, 22 Jan 2021 22:52:52 +0100
+
 libimobiledevice (1.3.0-5) unstable; urgency=medium
 
   [ Debian Janitor ]
diff --minimal -Nru libimobiledevice-1.3.0/debian/control 
libimobiledevice-1.3.0/debian/control
--- libimobiledevice-1.3.0/debian/control   2020-09-17 11:05:35.0 
+0200
+++ libimobiledevice-1.3.0/debian/control   2021-01-22 22:52:52.0 
+0100
@@ -8,13 +8,9 @@
cython3,
debhelper-compat (= 12),
dh-python,
-   libgcrypt20-dev,
libglib2.0-dev (>= 2.14.1),
libssl-dev,
-   libplist++-dev (>= 2.2.0),
libplist-dev (>= 2.2.0),
-   libreadline-dev,
-   libtasn1-6-dev (>= 1.1),
libusb-1.0-0-dev (>= 1.0.3) [linux-any],
libusbmuxd-dev (>= 2.0.2),
python3-dev,

Bug#968297: ITP: targetd -- remote configuration of a LIO-based storage appliance

[Johan Fleury]

retitle 968297 ITP: targetd -- remote configuration of a LIO-based storage 
appliance

--
Johan Fleury

signature.asc
Description: OpenPGP digital signature

Bug#980751: petsc: breaks multiple autopkgtests: undefined reference to 'MPIU_SUM'

[Drew Parsons]

Source: dolfin
Followup-For: Bug #980751

Hard to say what went wrong here, to be honest.  As far as I can tell
dolfin is innocent in any case.  The problem was triggered in slepc
and fixed by rebuilding slepc.  On the face of it the problem is in
the dependency relationship between slepc and openmpi.

There were a lot of updates to the openmpi suite (including pmix and
ucx) in the past month. The openmpi library transition was already
declared to libopenmpi3 (>= 4.1.0). It must be some subtlety in the
handling of MPIU_SUM in openmpi 4.1.0, though it doesn't make sense
that pmix or ucx would affect that.

In short, buggered if I know.
https://youtu.be/BmRUJGRwkj0?t=111

Bug#980596: mkvtoolnix: FTBFS: src/merge/reader_detection_and_creation.cpp:164:54: internal compiler error: Segmentation fault

[Andreas Beckmann]

Control: reassign -1 src:gcc-10 10.2.1-6
Control: affects -1 + src:mkvtoolnix
Control: forwarded -1 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98790
Control: tag -1 fixed-upstream

On Thu, 21 Jan 2021 09:30:01 +0100 Christian Marillat  
wrote:
> On 20 janv. 2021 21:29, Lucas Nussbaum  wrote:
> >> src/merge/reader_detection_and_creation.cpp:164:54: internal compiler 
> >> error: Segmentation fault
> 
> Should be reassigned to gcc ?

That one looks very similar to the one I reported in nheko (#980429)
There is also the similar PR98659 but for gcc-11 only...

The backtrace:

0xa65400 crash_signal
../../src/gcc/toplev.c:328
0xeca104 maybe_instantiate_noexcept(tree_node*, int)
../../src/gcc/cp/pt.c:25331
0x768644 resolve_overloaded_unification
../../src/gcc/cp/pt.c:22255
0x768644 unify_one_argument
../../src/gcc/cp/pt.c:21801
0x111d442 type_unification_real
../../src/gcc/cp/pt.c:21945
0x111c93f fn_type_unification(tree_node*, tree_node*, tree_node*, tree_node* 
const*, unsigned int, tree_node*, unification_kind_t, int, conversion**, bool, 
bool)
../../src/gcc/cp/pt.c:21325
0x111c02a add_template_candidate_real(z_candidate**, tree_node*, tree_node*, 
tree_node*, tree_node*, vec const*, tree_node*, 
tree_node*, tree_node*, int, tree_node*, unification_kind_t, int) [clone 
.isra.0]
../../src/gcc/cp/call.c:3417
0xf538cd add_template_candidate
../../src/gcc/cp/call.c:3502
0xf538cd add_candidates
../../src/gcc/cp/call.c:5855
0x1045831 add_operator_candidates
../../src/gcc/cp/call.c:5974
0xf5de70 build_new_op_1
../../src/gcc/cp/call.c:6182
0xf5d597 build_new_op(op_location_t const&, tree_code, int, tree_node*, 
tree_node*, tree_node*, tree_node**, int)
../../src/gcc/cp/call.c:6573
0xfa18f8 cp_build_modify_expr(unsigned int, tree_node*, tree_code, tree_node*, 
int)
../../src/gcc/cp/typeck.c:8574
0xfa0b38 build_x_modify_expr(unsigned int, tree_node*, tree_code, tree_node*, 
int)
../../src/gcc/cp/typeck.c:8833
0xec8020 cp_parser_assignment_expression
../../src/gcc/cp/parser.c:9909
0xedbbf5 cp_parser_expression
../../src/gcc/cp/parser.c:10035
0xed9ca8 cp_parser_expression_statement
../../src/gcc/cp/parser.c:11696
0xed7284 cp_parser_statement
../../src/gcc/cp/parser.c:11492
0xed4fd9 cp_parser_statement_seq_opt
../../src/gcc/cp/parser.c:11843
0xed4fd9 cp_parser_compound_statement
../../src/gcc/cp/parser.c:11793

Andreas

Bug#980726: gpm.service does not automatically start

[Axel Beckert]

Control: tag -1 + confirmed
Control: retitle -1 gpm.service does not automatically start after reboot
Control: severity -1 important

Hi Daniel,

Daniel van Vugt wrote:
> The gpm service does not automatically start on boot.

Indeed. It starts after installation and after upgrade (which I
tested), but no more after reboot.

> $ systemctl status gpm
> ● gpm.service - Console Mouse manager
>  Loaded: loaded (/lib/systemd/system/gpm.service; disabled; vendor
> preset: enabled)
>  Active: inactive (dead)
>Docs: man:gpm(8)
>  man:gpm.conf(5)
>  man:gpm-types(7)

Seeing this, too, but only after reboot.

Daniel van Vugt wrote:
> Seems all it needs is:
> 
>   sudo systemctl enable gpm

Well, if so, at least without "sudo"…

> Does that need to be added to the packaging?

Nope. It indirectly should be already already there as update-rc.d is
AFAIK mandatory for all init systems:

$ fgrep -n update-rc.d /var/lib/dpkg/info/gpm.postinst
88:update-rc.d gpm defaults >/dev/null

But then again, what seems missing from gpm.postinst is the
#DEBHELPER# marker which includes debhelper generated snippets which
usually include some further systemd-specific magic.

Will test a new version of the package on a Raspberry Pi (runing
Debian Sid of course, not Raspbian) which I can quickly and easily
reboot without issues.

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

Bug#980825: debian-policy: Historical sign off dates in d/changelog and "single digit" day of the month

[Guillem Jover]

Hi!

On Fri, 2021-01-22 at 22:15:24 +0100, Niels Thykier wrote:
> Package: debian-policy
> Version: 4.5.0.0
> Severity: minor
> 
> This is a bit of a nit pick, but I think it is a special case worth
> mentioning in Policy.
> 
> I am basing this on
> https://www.debian.org/doc/debian-policy/ch-source.html#debian-changelog-debian-changelog
> where the date format of the changelog signoff line is described as:
> 
> 
> > The date has the following format 7 (compatible and with the same semantics 
> > of RFC 2822 and RFC 5322):
> > 
> > day-of-week, dd month  hh:mm:ss +
> > 
> > where:
> > 
> > day-of-week is one of: Mon, Tue, Wed, Thu, Fri, Sat, Sun
> > 
> > dd is a one- or two-digit day of the month (01-31)
> > [...]
> 
> I find that "single-digit day" is a bit underspecified here in.
> Basically there are two options, either the leading zero is replaced
> with a leading space or the leading zero is simply omitted.
> 
> Sadly, neither RFC 2822 nor RFC 5322 are helpful in clearing this up as
> they both assume "two-digit" days.
> 
> My understanding is that the reason for "single-digit" days is to
> support historical changelogs, where Debian omitted the leading zero.
> The samples I have found[1], the leading zero is replaced with a single
> space as in:
> 
> >  -- Joey Hess   Thu,  3 Dec 1998 23:31:56 -0800
> 
> 
> 
> This is relatively prevalent.  As an (un)scientific example, this
> alternative variant accounts for:
> 
>  * ~21% of all signoff dates in debhelper (202/927)
>  * ~10% of all signoff dates in apt (49/480)
> 
> 
> I applaud policy for highlighting the correct and preferred example, so
> I propose that we restrain this amendment to a footnote (or another note
> of equal low importance) that informs the reader that this alternative
> format may be found in older changelog entries and that this variant is
> still accepted but that the two-digit format with leading zero should be
> preferred in every new entry.

Isn't this report a duplicate of #971977?

(I clarified the other report in deb-changelog(5) with
.)

Thanks,
Guillem

Bug#980838: gpg-agent: generator 90gpg-agent without scdaemon generate annoying log

[Bastien Roucariès]

Package: gpg-agent
Version: 2.2.20-1
Severity: normal

Dear Maintainer,

Without scdaemon the 90gpg-agent will output something like 
LANG=C gpgconf --check-programs

gpgconf: error running '/usr/lib/gnupg/scdaemon': probably not installed
gpg:OpenPGP:/usr/bin/gpg:1:1:
gpg-agent:Private Keys:/usr/bin/gpg-agent:1:1:
scdaemon:Smartcards:/usr/lib/gnupg/scdaemon:0:0:
gpgsm:S/MIME:/usr/bin/gpgsm:1:1:::enabled debug flags%3a ipc:
dirmngr:Network:/usr/bin/dirmngr:1:1:
pinentry:Passphrase Entry:/usr/bin/pinentry:1:1:

The error line will go to log

Thanks

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

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

Versions of packages gpg-agent depends on:
ii  gpgconf 2.2.20-1
ii  init-system-helpers 1.60
ii  libassuan0  2.5.3-7.1
ii  libc6   2.31-9
ii  libgcrypt20 1.8.7-2
ii  libgpg-error0   1.38-2
ii  libnpth01.6-3
ii  pinentry-gnome3 [pinentry]  1.1.0-4
ii  pinentry-qt [pinentry]  1.1.0-4

Versions of packages gpg-agent recommends:
ii  gnupg  2.2.20-1

Versions of packages gpg-agent suggests:
ii  dbus-user-session  1.12.20-1
ii  libpam-systemd 247.2-4
ii  pinentry-gnome31.1.0-4
pn  scdaemon   

-- no debconf information

Bug#980839: RPF: rnnoise

[Petter Reinholdtsen]

Package: wnpp
Severity: wishlist

* Package name: rnnoise
  Version : n/a git repo
  Upstream Author : Jean-Marc Valin 
* URL : https://gitlab.xiph.org/xiph/rnnoise
* License : BSD
  Programming Lang: C
  Description : noise suppression library based on a recurrent neural 
network

This library is used by one of the VLC modules, see
http://git.videolan.org/?p=vlc.git;a=blob;f=modules/audio_filter/rnnoise.c;h=34229f0012487ffe00f932238b8d990e861e3b22;hb=HEAD#l77
 >.

-- 
Happy hacking
Petter Reinholdtsen

Bug#980817: ser2net: Does not process hex escapes in bannner

[Corey Minyard]

No need to file a defect in the ser2net repository, I've gotten this in.

Thanks,

-corey

Bug#980848: RFS: surgescript/0.5.5-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.5-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 : libs

It builds those binary packages:

  libsurgescript-dev - Scripting language for games (development files)
  libsurgescript0.5.5 - Scripting language for games (library files)
  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.5-1.dsc

Changes since the last upload:

 surgescript (0.5.5-1) unstable; urgency=medium
 .
   * New upstream release.
 + Added the ability to pause the SurgeScript VM.
 + Added utility macros for checking the SurgeScript version at compile 
time.
 + Introduced a dedicated module for keeping track of time.
 + Renamed Object.childCount to Object.__childCount.
 + Updated docs.
   * debian/copyright:
 + Copyright updated for current years (2021).
   * debian/control:
 + Changed versioned in "depends+breaks+replaces" to avoid version conflict.
   * Renamed for debian/libsurgescript0.5.5 file.
   * Updated debian/upstream/metadata years (2021).

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

Bug#979017: chromium 87 with hw accel, opening a second window freezes the UI

[Anthony Atkinson]

Hello,

   I was looking into this a little and noticed that
http://crbug.com/1141354 was reopened. #980482 mentions this may be
related, and is still open and release critical, but seeing that the
upstream bug has been reopened, I figured this may deserve to be as well
since it looks like a one-to-one match between the two (regardless of
whether the RC bug is related/unrelated).

Cheers,
Anthony Atkinson

Bug#980488: wine-development: FTBFS in sid

[Petter Reinholdtsen]

[Gianfranco Costamagna]
> Hello, your package FBTFS in sid...

This is the build error on arm64:

../../tools/winegcc/winegcc -o cabinet.dll.so --wine-objdir ../.. -fPIC 
-fasynchronous-unwind-tables -shared cabinet.spec -mno-cygwin cabinet_main.o 
fci.o fdi.o cabinet.res ../../dlls/ucrtbase/libucrtbase.a -Wl,-z,relro 
-Wl,-z,now -Wl,-rpath,/usr/lib/aarch64-linux-gnu/wine-development
warning: unknown warning option '-Wno-implicit-int-float-conversion'; did you 
mean '-Wno-implicit-float-conversion'? [-Wunknown-warning-option]
5 warnings generated.
../../tools/winegcc/winegcc -o combase.dll.fake --wine-objdir ../.. -fPIC 
-fasynchronous-unwind-tables -shared combase.spec -mno-cygwin roapi.o string.o 
-ladvapi32 -lole32 ../../dlls/uuid/libuuid.a ../../dlls/ucrtbase/libucrtbase.a 
-Wl,-z,relro -Wl,-z,now -Wl,-rpath,/usr/lib/aarch64-linux-gnu/wine-development
clang -c -o comboex.o comboex.c -I. -I../../include -I../../include/msvcrt 
-D__WINESRC__ -D_COMCTL32_ -D_UCRT -D_REENTRANT -fPIC -fno-builtin 
-fshort-wchar -Wall -pipe -fcf-protection=none -fno-stack-protector 
-fno-strict-aliasing -Wdeclaration-after-statement -Wempty-body 
-Wignored-qualifiers -Wno-packed-not-aligned -Wno-pragma-pack 
-Wshift-overflow=2 -Wstrict-prototypes -Wtype-limits -Wunused-but-set-parameter 
-Wvla -Wwrite-strings -gdwarf-2 -gstrict-dwarf -Wdate-time -g -O2 
-fdebug-prefix-map=/<>=. -Wno-shift-overflow -Wno-unused-function 
-Wno-format -Wno-absolute-value -Wno-enum-conversion 
-Wno-misleading-indentation -Wno-implicit-int-float-conversion
warning: unknown warning option '-Wno-packed-not-aligned'; did you mean 
'-Wno-over-aligned'? [-Wunknown-warning-option]
warning: unknown warning option '-Wshift-overflow=2'; did you mean 
'-Wshift-overflow'? [-Wunknown-warning-option]
warning: unknown warning option '-Wunused-but-set-parameter'; did you mean 
'-Wunused-parameter'? [-Wunknown-warning-option]
warning: unknown warning option '-Wno-misleading-indentation'; did you mean 
'-Wno-binding-in-condition'? [-Wunknown-warning-option]
warning: unknown warning option '-Wno-implicit-int-float-conversion'; did you 
mean '-Wno-implicit-float-conversion'? [-Wunknown-warning-option]
../../tools/winegcc/winegcc -o browseui.dll.fake --wine-objdir ../.. -fPIC 
-fasynchronous-unwind-tables -shared browseui.spec -mno-cygwin aclmulti.o 
aclsource.o browseui_main.o compcatcachedaemon.o progressdlg.o browseui.res 
browseui_classes_r.res ../../dlls/uuid/libuuid.a -lole32 -lcomctl32 -luser32 
-ladvapi32 ../../dlls/ucrtbase/libucrtbase.a -Wl,-z,relro -Wl,-z,now 
-Wl,-rpath,/usr/lib/aarch64-linux-gnu/wine-development
make[2]: Leaving directory '/<>/dlls/browseui'
make[2]: Entering directory '/<>/dlls/compstui'
clang -c -o compstui_main.o compstui_main.c -I. -I../../include 
-I../../include/msvcrt -D__WINESRC__ -D_UCRT -D_REENTRANT -fPIC -fno-builtin 
-fshort-wchar -Wall -pipe -fcf-protection=none -fno-stack-protector 
-fno-strict-aliasing -Wdeclaration-after-statement -Wempty-body 
-Wignored-qualifiers -Wno-packed-not-aligned -Wno-pragma-pack 
-Wshift-overflow=2 -Wstrict-prototypes -Wtype-limits -Wunused-but-set-parameter 
-Wvla -Wwrite-strings -gdwarf-2 -gstrict-dwarf -Wdate-time -g -O2 
-fdebug-prefix-map=/<>=. -Wno-shift-overflow -Wno-unused-function 
-Wno-format -Wno-absolute-value -Wno-enum-conversion 
-Wno-misleading-indentation -Wno-implicit-int-float-conversion
/usr/bin/ld: fci.o: in function `compress_MSZIP':
./dlls/cabinet/fci.c:929: undefined reference to `deflateInit2_'
/usr/bin/ld: ./dlls/cabinet/fci.c:941: undefined reference to `deflate'
/usr/bin/ld: ./dlls/cabinet/fci.c:942: undefined reference to `deflateEnd'
clang: error: linker command failed with exit code 1 (use -v to see invocation)
winegcc: /usr/bin/clang failed
make[2]: *** [Makefile:196: cabinet.dll.so] Error 2
make[2]: Leaving directory '/<>/dlls/cabinet'

Missing library or object file in linking stage?
-- 
Happy hacking
Petter Reinholdtsen

Bug#980835: buster-pu: fcitx/1:4.2.9.6-5+deb10u1

[Boyuan Yang]

Package: release.debian.org
Severity: normal
Tags: buster
User: release.debian@packages.debian.org
Usertags: pu
X-Debbugs-CC: debian-input-met...@lists.debian.org

Dear Release team,

Current fcitx v4.2.9.6 in Debian 10 has a broken implementation to
flatpak support. As a result, software installed via flatpak cannot
enable fcitx as the active input method. The corresponding Debian bug
report is at https://bugs.debian.org/980268 .

This bug is fixed by fcitx upstream in v4.2.9.7. I cherry-picked this
upstream commit and prepared this buster-pu upload here. The full
debdiff is provided in the attachment.

Thanks,
Boyuan Yang
diff -Nru fcitx-4.2.9.6/debian/changelog fcitx-4.2.9.6/debian/changelog
--- fcitx-4.2.9.6/debian/changelog	2018-08-30 14:54:54.0 -0400
+++ fcitx-4.2.9.6/debian/changelog	2021-01-22 17:45:45.0 -0500
@@ -1,3 +1,11 @@
+fcitx (1:4.2.9.6-5+deb10u1) buster; urgency=medium
+
+  * debian/patches/0009-ipcportal: Add patch to fix broken input
+method support with software installed via flatpak.
+(Closes: #980834)
+
+ -- Boyuan Yang   Fri, 22 Jan 2021 17:45:45 -0500
+
 fcitx (1:4.2.9.6-5) unstable; urgency=medium
 
   * Team upload.
diff -Nru fcitx-4.2.9.6/debian/patches/0009-ipcportal-use-org-freedesktop-portal-as-dbus-path-fo.patch fcitx-4.2.9.6/debian/patches/0009-ipcportal-use-org-freedesktop-portal-as-dbus-path-fo.patch
--- fcitx-4.2.9.6/debian/patches/0009-ipcportal-use-org-freedesktop-portal-as-dbus-path-fo.patch	1969-12-31 19:00:00.0 -0500
+++ fcitx-4.2.9.6/debian/patches/0009-ipcportal-use-org-freedesktop-portal-as-dbus-path-fo.patch	2021-01-22 17:45:45.0 -0500
@@ -0,0 +1,114 @@
+From 1f4c3a96cb2d1308581864676dd86ea6aa393ccb Mon Sep 17 00:00:00 2001
+From: Weng Xuetian 
+Date: Sat, 2 Nov 2019 22:02:54 -0700
+Subject: [PATCH] [ipcportal] use /org/freedesktop/portal as dbus path for
+ portal.
+
+Applied-Upstream: https://github.com/fcitx/fcitx/commit/1f4c3a96cb2d1308581864676dd86ea6aa393ccb
+Bug-Debian: https://bugs.debian.org/980834
+---
+ src/frontend/ipcportal/ipcportal.c | 8 
+ src/frontend/ipcportal/ipcportal.h | 9 +
+ src/frontend/qt/fcitxinputcontextproxy.cpp | 2 +-
+ src/lib/fcitx-gclient/fcitxclient.c| 2 +-
+ 4 files changed, 11 insertions(+), 10 deletions(-)
+
+diff --git a/src/frontend/ipcportal/ipcportal.c b/src/frontend/ipcportal/ipcportal.c
+index bed18299..14cd617c 100644
+--- a/src/frontend/ipcportal/ipcportal.c
 b/src/frontend/ipcportal/ipcportal.c
+@@ -49,7 +49,7 @@ typedef struct _FcitxLastSentIMInfo
+ typedef struct _FcitxPortalIC {
+ int id;
+ char* sender;
+-char path[32];
++char path[64];
+ uuid_t uuid;
+ int width;
+ int height;
+@@ -234,7 +234,7 @@ void* PortalCreate(FcitxInstance* instance, int frontendid)
+ }
+ 
+ DBusObjectPathVTable fcitxPortalVTable = {NULL, , NULL, NULL, NULL, NULL };
+-dbus_connection_register_object_path(ipc->_conn,  FCITX_IM_DBUS_PATH, , ipc);
++dbus_connection_register_object_path(ipc->_conn,  FCITX_IM_DBUS_PORTAL_PATH, , ipc);
+ dbus_connection_flush(ipc->_conn);
+ 
+ FcitxIMEventHook hook;
+@@ -266,7 +266,7 @@ void PortalCreateIC(void* arg, FcitxInputContext* context, void* priv)
+ ipcic->sender = strdup(dbus_message_get_sender(message));
+ ipc->maxid ++;
+ ipcic->lastPreeditIsEmpty = false;
+-sprintf(ipcic->path, "/inputcontext/%d", ipcic->id);
++sprintf(ipcic->path, FCITX_IC_DBUS_PORTAL_PATH, ipcic->id);
+ uuid_generate(ipcic->uuid);
+ 
+ int icpid = 0;
+@@ -420,7 +420,7 @@ static DBusHandlerResult PortalICDBusEventHandler(DBusConnection *connection, DB
+ {
+ FcitxPortalFrontend* ipc = (FcitxPortalFrontend*) user_data;
+ int id = -1;
+-sscanf(dbus_message_get_path(msg), "/inputcontext/%d", );
++sscanf(dbus_message_get_path(msg), FCITX_IC_DBUS_PORTAL_PATH, );
+ FcitxInputContext* ic = FcitxInstanceFindIC(ipc->owner, ipc->frontendid, );
+ DBusHandlerResult result = DBUS_HANDLER_RESULT_NOT_YET_HANDLED;
+ DBusMessage *reply = NULL;
+diff --git a/src/frontend/ipcportal/ipcportal.h b/src/frontend/ipcportal/ipcportal.h
+index 17e24138..07d1f6c4 100644
+--- a/src/frontend/ipcportal/ipcportal.h
 b/src/frontend/ipcportal/ipcportal.h
+@@ -17,14 +17,15 @@
+  *   51 Franklin St, Fifth Floor, Boston, MA 02110-1301, USA.  *
+  ***/
+ 
+-#ifndef FCITX_IPC_H
+-#define FCITX_IPC_H
++#ifndef FCITX_IPC_PORTAL_H
++#define FCITX_IPC_PORTAL_H
+ 
+ #ifdef __cplusplus
+ extern "C" {
+ #endif
+ 
+-#define FCITX_IM_DBUS_PATH "/inputmethod"
++#define FCITX_IM_DBUS_PORTAL_PATH "/org/freedesktop/portal/inputmethod"
++#define FCITX_IC_DBUS_PORTAL_PATH "/org/freedesktop/portal/inputcontext/%d"
+ 
+ #define FCITX_PORTAL_SERVICE "org.freedesktop.portal.Fcitx"
+ #define FCITX_IM_DBUS_INTERFACE "org.fcitx.Fcitx.InputMethod1"
+@@ -34,5 +35,5 @@ extern "C" {
+ }
+ #endif
+ 
+-#endif // 

Bug#980204: gdc: Resulting executables segfault on mipsel architecture (signal 11)

[Iain Buclaw]

Excerpts from Matija Nalis's message of January 22, 2021 5:51 pm:
> On Fri, Jan 22, 2021 at 12:59:34PM +0100, Iain Buclaw wrote:
>> Also, are you linking to the static or shared libphobos library?
> 
> shared (default):
> 
> (mipsel-chroot):/tmp/w$ dpkg -l gdc | grep gdc
> ii  gdc4:10.2.1-1   mipsel   D compiler (language version 2), 
> based on the GCC backend
> 
> (mipsel-chroot):/tmp/w$ printf 'import std.stdio;\nvoid main()  { 
> writeln("Hello, World!"); }\n' > hello.d ; gdc hello.d && ./a.out
> qemu: uncaught target signal 11 (Segmentation fault) - core dumped
> Segmentation fault
> 
> (mipsel-chroot):/tmp/w$ file a.out
> a.out: ELF 32-bit LSB pie executable, MIPS, MIPS32 rel2 version 1 (SYSV), 
> dynamically linked, interpreter /lib/ld.so.1, 
> BuildID[sha1]=36c5576b94519b416c1996018760159ae925bc34, for GNU/Linux 3.2.0, 
> not stripped
> 
> (mipsel-chroot):/tmp/w$ ldd a.out
> libgphobos.so.1 => /lib/mipsel-linux-gnu/libgphobos.so.1 (0x7f1a3000)
> libgcc_s.so.1 => /lib/mipsel-linux-gnu/libgcc_s.so.1 (0x7f16b000)
> libc.so.6 => /lib/mipsel-linux-gnu/libc.so.6 (0x7efd1000)
> libm.so.6 => /lib/mipsel-linux-gnu/libm.so.6 (0x7ef52000)
> libpthread.so.0 => /lib/mipsel-linux-gnu/libpthread.so.0 (0x7ef21000)
> libdl.so.2 => /lib/mipsel-linux-gnu/libdl.so.2 (0x7ef0d000)
> libz.so.1 => /lib/mipsel-linux-gnu/libz.so.1 (0x7eee2000)
> /lib/ld.so.1 (0x7ffc9000)
> 
> 
> But good point, when I try to link this "hello world" example statically, it
> throws warnings, but works!
> 
> (mipsel-chroot):/tmp/w$ printf 'import std.stdio;\nvoid main()  { 
> writeln("Hello, World!"); }\n' > hello.d ; gdc -static hello.d && ./a.out
> /usr/bin/ld: /usr/lib/gcc/mipsel-linux-gnu/10/libgphobos.a(elf_shared.o): in 
> function `_D3gcc8sections10elf_shared18pinLoadedLibrariesFNbNiZPv':
> /build/gcc-10-XdUysA/gcc-10-10.2.1/build/mipsel-linux-gnu/libphobos/libdruntime/../../../../src/libphobos/libdruntime/gcc/sections/elf_shared.d:250:
>  warning: Using 'dlopen' in statically linked applications requires at 
> runtime the shared libraries from the glibc version used for linking
> /usr/bin/ld: /usr/lib/gcc/mipsel-linux-gnu/10/libgphobos.a(stdio.o): in 
> function `_D3std5stdio11openNetworkFAyatZS3std5stdio4File':
> /build/gcc-10-XdUysA/gcc-10-10.2.1/build/mipsel-linux-gnu/libphobos/src/../../../../src/libphobos/src/std/stdio.d:5137:
>  warning: Using 'gethostbyname' in statically linked applications requires at 
> runtime the shared libraries from the glibc version used for linking
> Hello, World!
> 

I've just checked the testsuite result, and the only failed tests are
those that use -shared-libphobos.

FAIL: gdc.test/runnable/implicit.d -shared-libphobos   execution test
FAIL: gdc.test/runnable/test31.d -shared-libphobos   execution test
FAIL: gdc.test/runnable/testarray.d -shared-libphobos   execution test
FAIL: gdc.test/runnable/Same.d -shared-libphobos   execution test
FAIL: gdc.test/runnable/s2ir.d -shared-libphobos   execution test
FAIL: gdc.test/runnable/test9309.d -shared-libphobos   execution test
FAIL: gdc.test/runnable/test15.d -shared-libphobos   execution test
etc...


>> Running the testsuite now, to see if there's any reported failures, but
>> none so far...
> 
> 
> However, when I try to build and run the more complex program 
> Data_Generators/makedata/logmake.d
> from this version: 
> http://snapshot.debian.org/archive/debian/20210115T023714Z/pool/main/i/ironseed/ironseed_0.3.6-4.dsc
> 
> it still fails with segfault on my qemu mipsel chroot, even when '-static' is 
> added 
> (as it did on Debian buildd machine "eberlin.debian.org"):
> 
> (mipsel-chroot):/tmp/w/is/ironseed-0.3.6$ gdc -static -o 
> Data_Generators/makedata/logmake Data_Generators/makedata/logmake.d 
> Data_Generators/makedata/data.d && Data_Generators/makedata/logmake 
> Data_Generators/makedata/logs.txt data/titles.dta data/log.dta
> /usr/bin/ld: /usr/lib/gcc/mipsel-linux-gnu/10/libgphobos.a(elf_shared.o): in 
> function `_D3gcc8sections10elf_shared18pinLoadedLibrariesFNbNiZPv':
> /build/gcc-10-XdUysA/gcc-10-10.2.1/build/mipsel-linux-gnu/libphobos/libdruntime/../../../../src/libphobos/libdruntime/gcc/sections/elf_shared.d:250:
>  warning: Using 'dlopen' in statically linked applications requires at 
> runtime the shared libraries from the glibc version used for linking
> /usr/bin/ld: /usr/lib/gcc/mipsel-linux-gnu/10/libgphobos.a(stdio.o): in 
> function `_D3std5stdio11openNetworkFAyatZS3std5stdio4File':
> /build/gcc-10-XdUysA/gcc-10-10.2.1/build/mipsel-linux-gnu/libphobos/src/../../../../src/libphobos/src/std/stdio.d:5137:
>  warning: Using 'gethostbyname' in statically linked applications requires at 
> runtime the shared libraries from the glibc version used for linking
> qemu: uncaught target signal 11 (Segmentation fault) - core dumped
> Segmentation fault
> 
> (mipsel-chroot):/tmp/w/is/ironseed-0.3.6$ file 
> 

Bug#977701: gitlab: Missing assets, breaking some functionalities

[Antoine Le Gonidec]

On Thu, 21 Jan 2021 20:21:38 +0100 Maximilian Stein  wrote:
My broken pages are actually fixed with Gitlab 13.5.7-1. So for my side, 
this issue can be closed.


Great news!
As I am affected too I am going to give it a try, and report the result here.



OpenPGP_signature
Description: OpenPGP digital signature

Bug#980844: src:libbiblio-isis-perl: invalid maintainer address

[Ansgar]

Source: libbiblio-isis-perl
Version: 0.24-1
Severity: serious
Tags: bullseye sid
X-Debbugs-Cc: Holger Levsen 

The maintainer address is invalid, see below.

Ansgar

 Start of forwarded message 
From: Mail Delivery System 
Subject: Mail delivery failed: returning message to sender
Date: Wed, 13 Jan 2021 15:57:04 +

This message was created automatically by mail delivery software.

A message that you sent could not be delivered to one or more of its
recipients. This is a permanent error. The following address(es) failed:

  joseparre...@cantv.net
retry timeout exceeded
Reporting-MTA: dns; mailly.debian.org

Action: failed
Final-Recipient: rfc822;joseparrella@cantv.net
Status: 5.0.0

Bug#980843: wide-dhcpv6-client: support per-interface client DUIDs

[Brandon Stepler]

Package: wide-dhcpv6-client
Version: 20080615-23
Severity: wishlist
Tags: patch, ipv6

Attached is a patch to support per-interface client DUIDs. ISC dhclient 
supports this with "send dhcp6.client-id DUID;" in dhclient.conf. This patch 
implements support for "send client-id DUID;" inside interface statements in 
dhcp6c.conf. Originally authored for VyOS, this patch is useful for cloning 
DUIDs from ISP routers.

Thanks,
Brandon


0023-Support-per-interface-client-DUIDs.patch
Description: Binary data

Bug#980846: kodi-addons-dev-common: missing Breaks+Replaces: kodi-addons-dev (<< 2:19.0~rc1+git20210119.8c761c4+dfsg1-2)

[Vasyl Gello]

Hi Andreas!

Thanks for bringing that to my attention!

23 січня 2021 р. 01:20:27 UTC, Andreas Beckmann  написав(-ла):

>See policy 7.6 at
>https://www.debian.org/doc/debian-policy/ch-relationships.html#overwriting-files-and-replacing-packages-replaces

I think the Policy should be clarified stating that B+R must point to a version 
that has been accepted into Debian archive.
That was unclear for me to the dare because of

>There are
>  B+R: kodi-addons-dev (<< 2:19.0~beta2+dfsg1-6~)
>but that is the wrong version.

kodi-addons-dev (<< 2:19.0~beta2+dfsg1-6~) was uploaded to NEW queue but 
rejected by FTP Master.

Mattia suggests just changing that paragraph to:

kodi-addons-dev (<< 2:19.0~rc1+git20210119.8c761c4+dfsg1-2~)

which I am going to upload as:

2:19.0~rc1+git20210119.8c761c4+dfsg1-3

with s390x ftbfs fix.
-- 
Vasyl Gello
==
Certified SolidWorks Expert

Mob.:+380 (98) 465 66 77

E-Mail: vasek.ge...@gmail.com

Skype: vasek.gello
==
호랑이는 죽어서 가죽을 남기고 사람은 죽어서 이름을 남긴다

Bug#980850: src:rust-hostname: fails to migrate to testing for too long: unsatisfiable Build-Depends on armel, armhf, i386 and mipsel

[Paul Gevers]

Source: rust-hostname
Version: 0.1.5-2
Severity: serious
Control: close -1 0.3.1-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:rust-hostname
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=rust-hostname




OpenPGP_signature
Description: OpenPGP digital signature

Bug#980644: [Android-tools-devel] Bug#980644: android-sdk-platform-tools-common: no Multi-Arch annotation prevents adb upgrade

[Hans-Christoph Steiner]

Thorsten Glaser:

Hans-Christoph Steiner dixit:


Right now, we can only commit to supporting the arches that upstream supports
(amd64 and arm64), so I'm downgrading the severity.


It’d be the same if you’d install either of these, it’s *not*
an architecture-specific problem.


I could never wrap my head around the Multi-Arch: stuff.


Please consider doing so in the near future. Helmut Grohne can
help if you have concrete questions as well. This is becoming
more and more important.


I have tried in the past.  I have way too much going to spend more time on it. 
That's why we have team packages, so each person does not need to know all the 
details.  Thanks for your contribution!



I would accept a
merge request on salsa for this, if it passes in gitlab-ci.


It’s a one-liner that changes package metadata only, so it’s
got no chance not to pass. I tested it locally yesterday
already, so I’ll try to wrap my head around this Salsa thing
and give you one.


Thanks for taking the time to learn more about salsa!  I think the salsa/gitlab 
workflow will really improve Debian because it is a very common workflow in 
software development, and it is built around making it easy for anyone to 
contribute.  Having the build and CI integrated into the workflow is a really a 
bit win over having to upload to ftp-master to see the results.


.hc

Bug#980472: cubicsdr: CubicSDR crashes after lauch! (same effect on 2 clean bullseye OS)

[LH]

Hi Cristoph

Backtrace:
You can find my terminal output below ... not shure if this is what you 
want.


Best
Louis HB

---

root@pc-168:~# gdb CubicSDR
GNU gdb (Debian 10.1-1.7) 10.1.90.20210103-git
Copyright (C) 2021 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 


This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Type "show copying" and "show warranty" for details.
This GDB was configured as "x86_64-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
.
Find the GDB manual and other documentation resources online at:
    .

For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from CubicSDR...
(No debugging symbols found in CubicSDR)
(gdb) r
Starting program: /usr/bin/CubicSDR
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
Loaded 256 rig models via hamlib.
[New Thread 0x72cff700 (LWP 8306)]
[New Thread 0x724fe700 (LWP 8307)]
[New Thread 0x71cfd700 (LWP 8308)]
[New Thread 0x71406700 (LWP 8309)]
[New Thread 0x70c05700 (LWP 8310)]
[New Thread 0x7fffe2f1b700 (LWP 8311)]
[New Thread 0x7fffe271a700 (LWP 8312)]
[New Thread 0x7fffe1f19700 (LWP 8313)]
[New Thread 0x7fffe1718700 (LWP 8314)]
[New Thread 0x7fffbc18f700 (LWP 8315)]
[New Thread 0x7fffba4c2700 (LWP 8316)]

Audio Device #0 PulseAudio
[Thread 0x7fffba4c2700 (LWP 8316) exited]
    Default Output? Yes
    Default Input? Yes
    Input channels: 2
    Output channels: 2
    Duplex channels: 2
    Native formats:
        16-bit signed integer.
        32-bit signed integer.
        32-bit float normalized between plus/minus 1.0.
    Supported sample rates:
        8000hz
        16000hz
        22050hz
        32000hz
        44100hz
        48000hz
        96000hz

[New Thread 0x7fffba441700 (LWP 8317)]
[New Thread 0x7fffb97ff700 (LWP 8318)]
SDR enumerator starting.
SoapySDR init..
    API Version: v0.7.1
    ABI Version: v0.7
    Install root: /usr
    Loading modules...
    Available factories...airspy, audio, bladerf, hackrf, lime, null, 
osmosdr, redpitaya, remote, rtlsdr, uhd

[New Thread 0x7fffa8c2a700 (LWP 8319)]
[New Thread 0x7fffa8429700 (LWP 8320)]
[New Thread 0x7fffa7c28700 (LWP 8321)]
[New Thread 0x7fffa7427700 (LWP 8322)]
[New Thread 0x7fffba4c2700 (LWP 8323)]
[New Thread 0x7fffa6c26700 (LWP 8324)]
[New Thread 0x7fffa6425700 (LWP 8325)]
[New Thread 0x7fffa5c24700 (LWP 8326)]
[New Thread 0x7fffa5423700 (LWP 8327)]
[Thread 0x7fffa5423700 (LWP 8327) exited]
[New Thread 0x7fffa4c22700 (LWP 8328)]
[Thread 0x7fffa5c24700 (LWP 8326) exited]
[Thread 0x7fffba4c2700 (LWP 8323) exited]
Hash collision!!! Fatal error!!
[Thread 0x7fffa4c22700 (LWP 8328) exited]
[New Thread 0x7fff8700 (LWP 8329)]
[Thread 0x7fffe2f1b700 (LWP 8311) exited]
[Thread 0x7fffe1718700 (LWP 8314) exited]
[Thread 0x7fffe1f19700 (LWP 8313) exited]
[Thread 0x7fffe271a700 (LWP 8312) exited]
--Type  for more, q to quit, c to continue without paging--bt f

Thread 14 "CubicSDR" received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x7fffb97ff700 (LWP 8318)]
0x76712009 in std::_Rb_tree_insert_and_rebalance(bool, 
std::_Rb_tree_node_base*, std::_Rb_tree_node_base*, 
std::_Rb_tree_node_base&) ()

   from /lib/x86_64-linux-gnu/libstdc++.so.6
(gdb)

-- - End



Am 22.01.21 um 09:14 schrieb LH:

Hi there

Questions from hamlib:

1)
Does startup work if you first disconnect one of the receivers?
No, it does not start! It crashes as described. (No difference whether 
the SDR-Reciever is connected or not; CubicSDR crashes.)

2)
Do you have anything configured for hamlib radio control?
No, I have not configured anything. Just installed CubicSDR from Synaptic.
(CubicSDR was the first additional Software after installing Bullseye - incl. 
apt update/ apt upgrade of course.)

3)
Hmm. Can exit() lead to segfaults in threaded programs? I cannot 
answer that.

To Christoph:
Your 'backtrace' Links: I will give it one more try. I will let you know.

Best
Louis HB



Am 21.01.21 um 22:16 schrieb Christoph Berg:

Re: LH

Receivers:
- HackRF One
- DX Patrol Mk4

SDR enumerator starting.
SoapySDR init..
     API Version: v0.7.1
     ABI Version: v0.7
     Install root: /usr
     Loading modules...
     Available factories...airspy, audio, bladerf, hackrf, lime, null,
osmosdr, redpitaya, remote, rtlsdr, uhd
Hash collision!!! Fatal error!!

That's a message from hamlib:

https://sources.debian.org/src/hamlib/4.0-4/src/register.c/?hl=215#L215

Does startup work if you first disconnect one of the receivers?

Do you have anything configured for hamlib radio control?


[INFO] [UHD] linux; GNU C++ version 10.2.1 20201207; Boost_107400;
UHD_3.15.0.0-4+b1
Detached kernel driver

Bug#980788: Acknowledgement (netboot: support booting from USB WiFi devices)

[Michael Prokop]

Patch/MR is available at
https://salsa.debian.org/kernel-team/initramfs-tools/-/merge_requests/41

regards
-mika-


signature.asc
Description: Digital signature

Bug#980786: named: after upgrade to bind9=1:9.16.11-1 named is killed with status=11/SEGV

[Damir R. Islamov]

Package: bind9
Version: 1:9.16.11-1
Severity: important

Dear Maintainer,

After bind9 update to 1:9.16.11-1, named daemon cannot start dou to 11/SEGV 
signal.
Full log is like this:

Jan 22 14:40:47 trefle systemd[1]: Started BIND Domain Name Server.
Jan 22 14:40:47 trefle named[1317468]: starting BIND 9.16.11-Debian (Stable 
Release) 
Jan 22 14:40:47 trefle named[1317468]: running on Linux x86_64 5.10.0-1-amd64 
#1 SMP Debian 5.10.5-1 (2021-01-09)
Jan 22 14:40:47 trefle named[1317468]: built with '--build=x86_64-linux-gnu' 
'--prefix=/usr' '--includedir=/usr/include' '--mandir=/usr/share/man' 
'--infodir=/usr/share/info' '--sysconfdir=/etc' '--localstatedir=/var' 
'--disable-option-checking' '--disable-silent-rules' 
'--libdir=/usr/lib/x86_64-linux-gnu' '--runstatedir=/run' 
'--disable-maintainer-mode' '--disable-dependency-tracking' 
'--libdir=/usr/lib/x86_64-linux-gnu' '--sysconfdir=/etc/bind' 
'--with-python=python3' '--localstatedir=/' '--enable-threads' 
'--enable-largefile' '--with-libtool' '--enable-shared' '--enable-static' 
'--with-gost=no' '--with-openssl=/usr' '--with-gssapi=/usr' '--with-libidn2' 
'--with-json-c' '--with-lmdb=/usr' '--with-gnu-ld' '--with-maxminddb' 
'--with-atf=no' '--enable-ipv6' '--enable-rrl' '--enable-filter-' 
'--disable-native-pkcs11' '--enable-dnstap' 'build_alias=x86_64-linux-gnu' 
'CFLAGS=-g -O2 -ffile-prefix-map=/build/bind9-udv6N3/bind9-9.16.11=. 
-fstack-protector-strong -Wformat -Werror=format-security -fno-strict-aliasing 
-fno-delete-null-pointer-checks -DNO_VERSION_DATE -DDIG_SIGCHASE' 
'LDFLAGS=-Wl,-z,relro -Wl,-z,now' 'CPPFLAGS=-Wdate-time -D_FORTIFY_SOURCE=2'
Jan 22 14:40:47 trefle named[1317468]: running as: named -f -u bind
Jan 22 14:40:47 trefle named[1317468]: compiled by GCC 10.2.1 20210110
Jan 22 14:40:47 trefle named[1317468]: compiled with OpenSSL version: OpenSSL 
1.1.1i  8 Dec 2020
Jan 22 14:40:47 trefle named[1317468]: linked to OpenSSL version: OpenSSL 
1.1.1i  8 Dec 2020
Jan 22 14:40:47 trefle named[1317468]: compiled with libxml2 version: 2.9.10
Jan 22 14:40:47 trefle named[1317468]: linked to libxml2 version: 20910
Jan 22 14:40:47 trefle named[1317468]: compiled with json-c version: 0.15
Jan 22 14:40:47 trefle named[1317468]: linked to json-c version: 0.15
Jan 22 14:40:47 trefle named[1317468]: compiled with zlib version: 1.2.11
Jan 22 14:40:47 trefle named[1317468]: linked to zlib version: 1.2.11
Jan 22 14:40:47 trefle named[1317468]: 

Jan 22 14:40:47 trefle named[1317468]: BIND 9 is maintained by Internet Systems 
Consortium,
Jan 22 14:40:47 trefle named[1317468]: Inc. (ISC), a non-profit 501(c)(3) 
public-benefit
Jan 22 14:40:47 trefle named[1317468]: corporation.  Support and training for 
BIND 9 are
Jan 22 14:40:47 trefle named[1317468]: available at https://www.isc.org/support
Jan 22 14:40:47 trefle named[1317468]: 

Jan 22 14:40:47 trefle named[1317468]: adjusted limit on open files from 524288 
to 1048576
Jan 22 14:40:47 trefle named[1317468]: found 8 CPUs, using 8 worker threads
Jan 22 14:40:47 trefle named[1317468]: using 8 UDP listeners per interface
Jan 22 14:40:47 trefle named[1317468]: using up to 21000 sockets
Jan 22 14:40:47 trefle named[1317468]: loading configuration from 
'/etc/bind/named.conf'
Jan 22 14:40:47 trefle named[1317468]: reading built-in trust anchors from file 
'/etc/bind/bind.keys'
Jan 22 14:40:47 trefle named[1317468]: looking for GeoIP2 databases in 
'/usr/share/GeoIP'
Jan 22 14:40:47 trefle named[1317468]: using default UDP/IPv4 port range: 
[32768, 60999]
Jan 22 14:40:47 trefle named[1317468]: using default UDP/IPv6 port range: 
[32768, 60999]
Jan 22 14:40:47 trefle named[1317468]: listening on IPv4 interface lo, 
127.0.0.1#53
Jan 22 14:40:47 trefle named[1317468]: listening on IPv4 interface eth0, 
10.250.0.1#53
Jan 22 14:40:47 trefle named[1317468]: IPv6 socket API is incomplete; 
explicitly binding to each IPv6 address separately
Jan 22 14:40:47 trefle named[1317468]: listening on IPv6 interface lo, ::1#53
Jan 22 14:40:47 trefle named[1317468]: listening on IPv6 interface eth0, 
fd3a:49e:a53d:0:76d4:35ff:febc:1476#53
Jan 22 14:40:47 trefle named[1317468]: listening on IPv6 interface eth0, 
fe80::76d4:35ff:febc:1476%2#53
Jan 22 14:40:47 trefle named[1317468]: generating session key for dynamic DNS
Jan 22 14:40:47 trefle named[1317468]: sizing zone task pool based on 24 zones
Jan 22 14:40:47 trefle systemd[1]: named.service: Main process exited, 
code=killed, status=11/SEGV
Jan 22 14:40:47 trefle systemd[1]: named.service: Failed with result 'signal'.
Jan 22 14:40:47 trefle systemd[1]: named.service: Scheduled restart job, 
restart counter is at 3.
Jan 22 14:40:47 trefle systemd[1]: Stopped BIND Domain Name Server.
Jan 22 14:40:47 trefle systemd[1]: Started BIND Domain Name Server.
Jan 22 14:40:47 trefle named[1317495]: starting BIND 9.16.11-Debian (Stable 
Release) 
Jan 22 14:40:47 trefle 

Bug#980788: netboot: support booting from USB WiFi devices

[Michael Prokop]

Package: initramfs-tools
Version: 0.139
Severity: wishlist

Hi,

the net/usb kernel drivers are missing in the generated initramfs,
as they are excluded from auto_add_modules()'s net selection.
This means it's not possible to boot via PXE/network boot using
a USB WiFi driver (which isn't uncommon with recent generations of
notebooks, which no longer provide ethernet NICs).

I'll provide a patch/MR as soon I receive a bug number from the BTS.

regards
-mika-

Bug#980789: ITP: directx-headers -- Direct3D 12 headers

[Timo Aaltonen]

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

* Package name: directx-headers
  Version : 1.0.1
  Upstream Author : Microsoft Corporation
* URL : https://github.com/microsoft/DirectX-Headers
* License : MIT
  Programming Lang: C
  Description : Direct3D 12 headers

 This package provides the development headers for Direct3D 12.

This is needed for the new d3d12 gallium driver in Mesa 21.0 and up.

Bug#980685: seqan: FTBFS: dh_auto_test: error: cd obj-x86_64-linux-gnu && make -j4 test ARGS\+=-j4 returned exit code 2

[Michael R. Crusoe]

FYI: Seqan 1 is no longer supported upstream, and the only package in 
Debian that uses it is also no longer available/maintained.



--
Michael R. Crusoe

Bug#980787: libtss2-esys split causes regression

[Sven Mueller]

Severity: Grave
Package: tpm2-tss
Version: 3.0.3-1

Machines upgrading from previous versions lose access to the TPM because
libtss2-tcti-device0 (at least, not sure when others would be needed) are
not automatically installed during upgrade.
Neither does tpm2-tools depend on these dynamically loaded libraries nor
does libtss2-esys-3.0.2-0 or libtss2-tctildr0 depend on the component
libraries.

On newly installed systems, installing just tpm2-tools does not result in
usable access to the TPM

Filing against tpm2-tss because the split there is the root cause for the
regression, though the fix might be clear documentation on the tpm2-tss
side and fixed dependencies on tpm2-tools

Bug#980472: cubicsdr: CubicSDR crashes after lauch! (same effect on 2 clean bullseye OS)

[LH]

Hi there

Questions from hamlib:

1)
Does startup work if you first disconnect one of the receivers?
No, it does not start! It crashes as described. (No difference whether 
the SDR-Reciever is connected or not; CubicSDR crashes.)


2)
Do you have anything configured for hamlib radio control?
No, I have not configured anything. Just installed CubicSDR from Synaptic.
(CubicSDR was the first additional Software after installing Bullseye - incl. 
apt update/ apt upgrade of course.)

3)
Hmm. Can exit() lead to segfaults in threaded programs? I cannot answer 
that.


To Christoph:
Your 'backtrace' Links: I will give it one more try. I will let you know.

Best
Louis HB



Am 21.01.21 um 22:16 schrieb Christoph Berg:

Re: LH

Receivers:
- HackRF One
- DX Patrol Mk4

SDR enumerator starting.
SoapySDR init..
     API Version: v0.7.1
     ABI Version: v0.7
     Install root: /usr
     Loading modules...
     Available factories...airspy, audio, bladerf, hackrf, lime, null,
osmosdr, redpitaya, remote, rtlsdr, uhd
Hash collision!!! Fatal error!!

That's a message from hamlib:

https://sources.debian.org/src/hamlib/4.0-4/src/register.c/?hl=215#L215

Does startup work if you first disconnect one of the receivers?

Do you have anything configured for hamlib radio control?


[INFO] [UHD] linux; GNU C++ version 10.2.1 20201207; Boost_107400;
UHD_3.15.0.0-4+b1
Detached kernel driver
Available vertical sync SwapInterval functions:
     glxSwapIntervalEXT: Yes
     DRI2SwapInterval: No
     glxSwapIntervalMESA: Yes
     glxSwapIntervalSGI: Yes
Using glxSwapIntervalEXT.

Loaded font 'Bitstream Vera Sans Mono' from
'/usr/share/cubicsdr/fonts/vera_sans_mono12_0.png', parsed 255 characters.
Loaded font 'Bitstream Vera Sans Mono' from
'/usr/share/cubicsdr/fonts/vera_sans_mono16_0.png', parsed 255 characters.
Loaded font 'Bitstream Vera Sans Mono' from
'/usr/share/cubicsdr/fonts/vera_sans_mono18_0.png', parsed 255 characters.
Found Rafael Micro R820T tuner
Speicherzugriffsfehler

Hmm. Can exit() lead to segfaults in threaded programs?

Re: LH

Backtrace:
After Reading https://wiki.debian.org/HowToGetABacktrace ... sorry, this is
beyond my knowledge, I'm a user only.
And I was not able to find a 'cubicsdr-dbgsym' that works on my
bullseye-system (https://packages.debian.org/sid/cubicsdr-dbgsym) ?
Or is there an easier way to get the desired 'backtrace'?

The -dbgsym packages are in a separate archive, /debian-debug/:
https://wiki.debian.org/HowToGetABacktrace#Installing_the_debugging_symbols

Also install gdb. Then:

gdb CubicSDR
r
... and once it has crashed:
bt f

Christoph

Bug#980786: named: after upgrade to bind9=1:9.16.11-1 named is killed with status=11/SEGV

[Ondřej Surý]

Hi Damir,

this is most probably an upstream issue, could you please fill the issue at
https://gitlab.isc.org/isc-projects/bind9/ and I’ll take it from there?

We’ll need a coredump and backtrace, and ISC has facilities to receive
the coredump.

You can use https://pandora.isc.org/ to send large files, and use ond...@isc.org
as recipient if the coredump would not attach to the GitLab issue due to the 
size.

Ondrej
--
Ondřej Surý (He/Him)
ond...@sury.org

> On 22. 1. 2021, at 8:44, Damir R. Islamov  wrote:
> 
> Package: bind9
> Version: 1:9.16.11-1
> Severity: important
> 
> Dear Maintainer,
> 
> After bind9 update to 1:9.16.11-1, named daemon cannot start dou to 11/SEGV 
> signal.
> Full log is like this:
> 
> Jan 22 14:40:47 trefle systemd[1]: Started BIND Domain Name Server.
> Jan 22 14:40:47 trefle named[1317468]: starting BIND 9.16.11-Debian (Stable 
> Release) 
> Jan 22 14:40:47 trefle named[1317468]: running on Linux x86_64 5.10.0-1-amd64 
> #1 SMP Debian 5.10.5-1 (2021-01-09)
> Jan 22 14:40:47 trefle named[1317468]: built with '--build=x86_64-linux-gnu' 
> '--prefix=/usr' '--includedir=/usr/include' '--mandir=/usr/share/man' 
> '--infodir=/usr/share/info' '--sysconfdir=/etc' '--localstatedir=/var' 
> '--disable-option-checking' '--disable-silent-rules' 
> '--libdir=/usr/lib/x86_64-linux-gnu' '--runstatedir=/run' 
> '--disable-maintainer-mode' '--disable-dependency-tracking' 
> '--libdir=/usr/lib/x86_64-linux-gnu' '--sysconfdir=/etc/bind' 
> '--with-python=python3' '--localstatedir=/' '--enable-threads' 
> '--enable-largefile' '--with-libtool' '--enable-shared' '--enable-static' 
> '--with-gost=no' '--with-openssl=/usr' '--with-gssapi=/usr' '--with-libidn2' 
> '--with-json-c' '--with-lmdb=/usr' '--with-gnu-ld' '--with-maxminddb' 
> '--with-atf=no' '--enable-ipv6' '--enable-rrl' '--enable-filter-' 
> '--disable-native-pkcs11' '--enable-dnstap' 'build_alias=x86_64-linux-gnu' 
> 'CFLAGS=-g -O2 -ffile-prefix-map=/build/bind9-udv6N3/bind9-9.16.11=. 
> -fstack-protector-strong -Wformat -Werror=format-security 
> -fno-strict-aliasing -fno-delete-null-pointer-checks -DNO_VERSION_DATE 
> -DDIG_SIGCHASE' 'LDFLAGS=-Wl,-z,relro -Wl,-z,now' 'CPPFLAGS=-Wdate-time 
> -D_FORTIFY_SOURCE=2'
> Jan 22 14:40:47 trefle named[1317468]: running as: named -f -u bind
> Jan 22 14:40:47 trefle named[1317468]: compiled by GCC 10.2.1 20210110
> Jan 22 14:40:47 trefle named[1317468]: compiled with OpenSSL version: OpenSSL 
> 1.1.1i  8 Dec 2020
> Jan 22 14:40:47 trefle named[1317468]: linked to OpenSSL version: OpenSSL 
> 1.1.1i  8 Dec 2020
> Jan 22 14:40:47 trefle named[1317468]: compiled with libxml2 version: 2.9.10
> Jan 22 14:40:47 trefle named[1317468]: linked to libxml2 version: 20910
> Jan 22 14:40:47 trefle named[1317468]: compiled with json-c version: 0.15
> Jan 22 14:40:47 trefle named[1317468]: linked to json-c version: 0.15
> Jan 22 14:40:47 trefle named[1317468]: compiled with zlib version: 1.2.11
> Jan 22 14:40:47 trefle named[1317468]: linked to zlib version: 1.2.11
> Jan 22 14:40:47 trefle named[1317468]: 
> 
> Jan 22 14:40:47 trefle named[1317468]: BIND 9 is maintained by Internet 
> Systems Consortium,
> Jan 22 14:40:47 trefle named[1317468]: Inc. (ISC), a non-profit 501(c)(3) 
> public-benefit
> Jan 22 14:40:47 trefle named[1317468]: corporation.  Support and training for 
> BIND 9 are
> Jan 22 14:40:47 trefle named[1317468]: available at 
> https://www.isc.org/support
> Jan 22 14:40:47 trefle named[1317468]: 
> 
> Jan 22 14:40:47 trefle named[1317468]: adjusted limit on open files from 
> 524288 to 1048576
> Jan 22 14:40:47 trefle named[1317468]: found 8 CPUs, using 8 worker threads
> Jan 22 14:40:47 trefle named[1317468]: using 8 UDP listeners per interface
> Jan 22 14:40:47 trefle named[1317468]: using up to 21000 sockets
> Jan 22 14:40:47 trefle named[1317468]: loading configuration from 
> '/etc/bind/named.conf'
> Jan 22 14:40:47 trefle named[1317468]: reading built-in trust anchors from 
> file '/etc/bind/bind.keys'
> Jan 22 14:40:47 trefle named[1317468]: looking for GeoIP2 databases in 
> '/usr/share/GeoIP'
> Jan 22 14:40:47 trefle named[1317468]: using default UDP/IPv4 port range: 
> [32768, 60999]
> Jan 22 14:40:47 trefle named[1317468]: using default UDP/IPv6 port range: 
> [32768, 60999]
> Jan 22 14:40:47 trefle named[1317468]: listening on IPv4 interface lo, 
> 127.0.0.1#53
> Jan 22 14:40:47 trefle named[1317468]: listening on IPv4 interface eth0, 
> 10.250.0.1#53
> Jan 22 14:40:47 trefle named[1317468]: IPv6 socket API is incomplete; 
> explicitly binding to each IPv6 address separately
> Jan 22 14:40:47 trefle named[1317468]: listening on IPv6 interface lo, ::1#53
> Jan 22 14:40:47 trefle named[1317468]: listening on IPv6 interface eth0, 
> fd3a:49e:a53d:0:76d4:35ff:febc:1476#53
> Jan 22 14:40:47 trefle named[1317468]: listening on IPv6 interface eth0, 
> fe80::76d4:35ff:febc:1476%2#53
> 

Bug#979379: [pkg-gnupg-maint] Bug#979379: ITS: src:gnupg2

[Christoph Biedl]

[ Re-sending, signed ]

Daniel Kahn Gillmor wrote...

> Hi all--
> 
> GnuPG is team-maintained -- i've uploaded most of the recent uploads,
> but i'm definitely not intending to be the sole maintainer, and i would
> be happy to have more active contributors to the team: 
> 
>https://wiki.debian.org/Teams/GnuPG

So consider this a request to join the team. I'm also in the IRC channel
but it seems you are not (or you have changed the nick).

> Thanks Gniibe and Christoph for your work on this!  Thanks gniibe in
> particular for your updates to patches that seem relevant for debian
> work but might not be carried upstream in 2.2.
> 
> i can review and upload this work in the followin gweek if that'd be
> helpful,

That would be great.

Gniibe has updated his branch to the recently-released 2.27 (no major
changes), and I'd tighten some build dependencies as this happened
upstream, see attachment.

> but i also don't object to anyone picking this up and running
> with it in a responsible way.

Still I think that package should stay under team maintainence, so the
place should stay.

Christoph

From 456ac92975cd9d609e0a530ab3c7660804503c34 Mon Sep 17 00:00:00 2001
From: Christoph Biedl 
Date: Wed, 20 Jan 2021 12:43:25 +0100
Subject: [PATCH] Tighten libgcrypt and libksba dependency

Following upstream's requirement changes.

These are still satisfied in Debian so the changes do not affect
unstable.
---
 debian/control | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/debian/control b/debian/control
index 4f94e14b9..aba07668d 100644
--- a/debian/control
+++ b/debian/control
@@ -18,10 +18,10 @@ Build-Depends:
  libassuan-dev (>= 2.5.0),
  libbz2-dev,
  libcurl4-gnutls-dev,
- libgcrypt20-dev (>= 1.7.0),
+ libgcrypt20-dev (>= 1.8.0),
  libgnutls28-dev (>= 3.0),
  libgpg-error-dev (>= 1.35),
- libksba-dev (>= 1.3.4),
+ libksba-dev (>= 1.3.5),
  libldap2-dev,
  libnpth0-dev (>= 1.2),
  libreadline-dev,
@@ -36,9 +36,9 @@ Build-Depends:
 Build-Depends-Indep:
  binutils-multiarch [!amd64 !i386],
  libassuan-mingw-w64-dev (>= 2.5.0),
- libgcrypt-mingw-w64-dev (>= 1.7.0),
+ libgcrypt-mingw-w64-dev (>= 1.8.0),
  libgpg-error-mingw-w64-dev (>= 1.26-2~),
- libksba-mingw-w64-dev (>= 1.3.4),
+ libksba-mingw-w64-dev (>= 1.3.5),
  libnpth-mingw-w64-dev (>= 1.2),
  libz-mingw-w64-dev,
  mingw-w64,
-- 
2.29.2



signature.asc
Description: PGP signature

Bug#979379: [pkg-gnupg-maint] Bug#979379: ITS: src:gnupg2

[Christoph Biedl]

Daniel Kahn Gillmor wrote...

> Hi all--
> 
> GnuPG is team-maintained -- i've uploaded most of the recent uploads,
> but i'm definitely not intending to be the sole maintainer, and i would
> be happy to have more active contributors to the team: 
> 
>https://wiki.debian.org/Teams/GnuPG

So consider this a request to join the team. I'm also in the IRC channel
but it seems you are not (or you have changed the nick).

> Thanks Gniibe and Christoph for your work on this!  Thanks gniibe in
> particular for your updates to patches that seem relevant for debian
> work but might not be carried upstream in 2.2.
> 
> i can review and upload this work in the followin gweek if that'd be
> helpful,

That would be great.

Gniibe has updated his branch to the recently-released 2.27 (no major
changes), and I'd tighten some build dependencies as this happened
upstream, see attachment.

> but i also don't object to anyone picking this up and running
> with it in a responsible way.

Still I think that package should stay under team maintainence, so the
place should stay.

Christoph
>From 456ac92975cd9d609e0a530ab3c7660804503c34 Mon Sep 17 00:00:00 2001
From: Christoph Biedl 
Date: Wed, 20 Jan 2021 12:43:25 +0100
Subject: [PATCH] Tighten libgcrypt and libksba dependency

Following upstream's requirement changes.

These are still satisfied in Debian so the changes do not affect
unstable.
---
 debian/control | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/debian/control b/debian/control
index 4f94e14b9..aba07668d 100644
--- a/debian/control
+++ b/debian/control
@@ -18,10 +18,10 @@ Build-Depends:
  libassuan-dev (>= 2.5.0),
  libbz2-dev,
  libcurl4-gnutls-dev,
- libgcrypt20-dev (>= 1.7.0),
+ libgcrypt20-dev (>= 1.8.0),
  libgnutls28-dev (>= 3.0),
  libgpg-error-dev (>= 1.35),
- libksba-dev (>= 1.3.4),
+ libksba-dev (>= 1.3.5),
  libldap2-dev,
  libnpth0-dev (>= 1.2),
  libreadline-dev,
@@ -36,9 +36,9 @@ Build-Depends:
 Build-Depends-Indep:
  binutils-multiarch [!amd64 !i386],
  libassuan-mingw-w64-dev (>= 2.5.0),
- libgcrypt-mingw-w64-dev (>= 1.7.0),
+ libgcrypt-mingw-w64-dev (>= 1.8.0),
  libgpg-error-mingw-w64-dev (>= 1.26-2~),
- libksba-mingw-w64-dev (>= 1.3.4),
+ libksba-mingw-w64-dev (>= 1.3.5),
  libnpth-mingw-w64-dev (>= 1.2),
  libz-mingw-w64-dev,
  mingw-w64,
-- 
2.29.2

Bug#980790: gnome-software: emphasize portion of version actually changing

[Barak A. Pearlmutter]

Package: gnome-software
Version: 3.38.0-3
Severity: wishlist
X-Debbugs-Cc: none, Barak A. Pearlmutter 

Dear Maintainer,

In the window listing packages and their versions, there are lines like

   foo   1.2.3.4.5-3.4 -> 1.2.3.4.6-2

I'd suggest finding the common prefix of these two strings, and
emphasizing the part after that common prefix, by boldface & using a
bright color. Here is what I'm talking about, shown by underlining:

   foo   1.2.3.4.5-3.4 -> 1.2.3.4.6-2
 ====

Bug#980164: (no subject)

[alain]

I wish to thank the BTS and all those who participated, in particular, 
in the resolution of my concern.

a little word to nicholas and vincent for their kindness.

everything is almost perfect.
2 small residual bugs .
one on the linux-headers-amd64 meta-package
and a (curious) one for wayland operation .

but on the whole it's good.

happy new year to all and best wishes .

here are the latest reports :

sudo dpkg -l | grep -iE "linux-image-|linux-headers-"
ii linux-headers-5.10.0-1-amd64 5.10.5-1 amd64 Header files for Linux 
5.10.0-1-amd64
ii linux-headers-5.10.0-1-common 5.10.5-1 all Common header files for 
Linux 5.10.0-1
ii linux-headers-5.10.0-2-amd64 5.10.9-1 amd64 Header files for Linux 
5.10.0-2-amd64
ii linux-headers-5.10.0-2-common 5.10.9-1 all Common header files for 
Linux 5.10.0-2
ii linux-headers-amd64 5.10.5-1 amd64 Header files for Linux amd64 
configuration (meta-package)
ii linux-image-5.10.0-1-amd64 5.10.5-1 amd64 Linux 5.10 for 64-bit PCs 
(signed)
ii linux-image-5.10.0-2-amd64-unsigned 5.10.9-1 amd64 Linux 5.10 for 
64-bit PCs
ii linux-image-5.9.0-4-amd64 5.9.11-1 amd64 Linux 5.9 for 64-bit PCs 
(signed)

ii linux-image-amd64 5.10.5-1 amd64 Linux for 64-bit PCs (meta-package)

sudo apt-listbugs list linux-image-amd64 linux-headers-amd64
Retrieving bug reports... Done
Information analysis Found/Corrected... Done
serious serious bugs on linux-headers-amd64 (→ ) 
 b1 - #964335 - linux-headers-amd64: cannot upgrade to 5.7.6-1
Summary :
 linux-headers-amd64(1 bug)

xrandr
Screen 0: minimum 16 x 16, current 7680 x 2160, maximum 32767 x 32767
XWAYLAND0 connected primary 3840x2160+0+0 (normal left inverted right x 
axis y axis) 700mm x 390mm

   3840x2160 29.96*+
XWAYLAND1 connected 3840x2160+3840+0 (normal left inverted right x axis 
y axis) 700mm x 390mm

   3840x2160 29.96*+

Screen 0: minimum 320 x 200, current 7680 x 2160, maximum 16384 x 16384
DisplayPort-0 connected primary 3840x2160+0+0 (normal left inverted 
right x axis y axis) 697mm x 392mm

   3840x2160 60.00*+ 30.00 29.97
   2560x1440 59.95
   1920x1200 60.00
   1920x1080 60.00 59.94
   1600x1200 60.00
   1680x1050 59.95
   1600x900 60.00
   1280x1024 75.02 60.02
   1440x900 59.89
   1280x800 59.81
   1152x864 75.00
   1280x720 60.00 59.94
   1024x768 75.03 70.07 60.00
   832x624 74.55
   800x600 72.19 75.00 60.32 56.25
   640x480 75.00 72.81 66.67 60.00 59.94
   720x400 70.08
DisplayPort-1 connected 3840x2160+3840+0 (normal left inverted right x 
axis y axis) 697mm x 392mm

   3840x2160 60.00*+ 30.00 29.97
   2560x1440 59.95
   1920x1200 60.00
   1920x1080 60.00 59.94
   1600x1200 60.00
   1680x1050 59.95
   1600x900 60.00
   1280x1024 75.02 60.02
   1440x900 59.89
   1280x800 59.81
   1152x864 75.00
   1280x720 60.00 59.94
   1024x768 75.03 70.07 60.00
   832x624 74.55
   800x600 72.19 75.00 60.32 56.25
   640x480 75.00 72.81 66.67 60.00 59.94
   720x400 70.08
DisplayPort-2 disconnected (normal left inverted right x axis y axis)
HDMI-A-0 disconnected (normal left inverted right x axis y axis)

Bug#980793: bsdowl: piuparts failure

[Ivo De Decker]

package: bsdowl
version: 2.2.2-1
severity: serious

Hi,

The lastest upload of bsdowl triggers a piuparts failure:

https://piuparts.debian.org/sid/fail/bsdowl_2.2.2-1.1.log

It seems bsdowl installs files in /usr/share/mk, but that is now a symlink
(shipped by bmake), pointing to /usr/share/bmake/mk-netbsd. It looks like this
failure might be fixed by moving those files to that directory.

Note that the failure was detected in version 2.2.2-1.1, currently in
unstable, but version 2.2.2-1 contains the same files, so I'm filing it
against that version.

Cheers,

Ivo

Bug#980164: thanks a lot and bye ...

[alain]

I would like to thank you all for your help.

now, debian supports big navi graphics cards.

to start with, "navy21" cards are supported.
AMD RX 6800 /6800 XT /6900 XT
The 6700 and, perhaps, the 6500 are still to come.

With gcn3.0 support now enabled, it is likely that the RX 6x00 
generation will be fully supported.


remains a question : how did you know where the error came from ? and 
what to modify ?


respectfully .

alain.

p.s. you can close this thread.

Bug#980792: Cannot decrypt encrypted root at boot with cryptsetup-initramfs 2:2.3.4-2~bpo10+1 (buster-backports)

[Guilhem Moulin]

> apt upgrade installed cryptsetup-initramfs 2:2.3.4-2~bpo10+1 over
> 2:2.3.4-1~bpo10+1

Next time please use the backports mailing list to report bugs for
-backports: https://backports.debian.org/Instructions/#index6h2

-- 
Guilhem.


signature.asc
Description: PGP signature

Bug#980040: nmu: dune-grid-glue_2.7.0-3

[Ansgar]

Control: tags -1 - moreinfo

On Sun, 2021-01-17 at 11:43 +0100, Sebastian Ramacher wrote:
> > nmu dune-grid-glue_2.7.0-3 . ANY . unstable . -m "Rebuild against
> > DUNE 2.7.1"
> > dw dune-grid-glue_2.7.0-3 . ANY . -m "libdune-grid-dev (>= 2.7.1)"
> 
> dune-grid-glue is currently missing builds on arm64, armhf and
> ppc64el.

dune-grid-glue built on these architectures with the updated
dependencies after a give-back, but that means a binNMU is only needed
on the other architectures (or all if the version should be in sync,
but I doubt people will use multi-arch for such packages).

Ansgar

Bug#977694: 977694 & 979187 fixed-upstream but remain in Debian :-

[Ryutaroh Matsumoto]

Control: found -1 5.10.9-1

Hi Salvatore, thank you very much for your attention!

From: Salvatore Bonaccorso 
Subject: Re: Bug#979187: 979187 is fixed-upstream
Date: Thu, 21 Jan 2021 11:34:13 +0100
> 5.10.9-1 is awaiting currently in NEW for beeing processed. Once that
> enters unstable, can you please check with it, and if so then close
> this bug with the respective version?

I do not observe 977694 nor 979187 on my self-compiled kernel,
but 977694 & 979187 remain in 5.10.9-1... Strange...

The photo of booting failure is at
https://photos.app.goo.gl/QFD1ZAept3Ks7wP66

When the booting device is USB-MSD and the kernel tries to mount the
root partition, it has not yet recognized any USB device, and fails to
mount the root partition. As such, my USB keyboard does not work, neither.

On the other hand, my compiled kernel somehow recognize USB devices
even when the booting device is a USB MSD. Its  dmesg is attached
to this email.

Disk images of USB-MSD are made by slightly modified version of
https://github.com/emojifreak/debian-rpi-image-script
Only the kernel package is changed.

My kernel .config is
http://153.240.174.134:64193/kernel-deb-5.9/config-arm64-5.10.9.txt

Best regards, Ryutaroh Matsumoto
[0.00] Booting Linux on physical CPU 0x00 [0x410fd083]
[0.00] Linux version 5.10.9 (root@raspi4b8gb) (gcc (Debian 10.2.1-6) 
10.2.1 20210110, GNU ld (GNU Binutils for Debian) 2.35.1) #1 SMP Fri Jan 22 
10:00:50 JST 2021
[0.00] Machine model: Raspberry Pi 4 Model B Rev 1.4
[0.00] efi: UEFI not found.
[0.00] Reserved memory: created CMA memory pool at 0x3700, 
size 64 MiB
[0.00] OF: reserved mem: initialized node linux,cma, compatible id 
shared-dma-pool
[0.00] NUMA: No NUMA configuration found
[0.00] NUMA: Faking a node at [mem 
0x-0x0001]
[0.00] NUMA: NODE_DATA [mem 0x1ff016b00-0x1ff018fff]
[0.00] Zone ranges:
[0.00]   DMA  [mem 0x-0x3fff]
[0.00]   DMA32[mem 0x4000-0x]
[0.00]   Normal   [mem 0x0001-0x0001]
[0.00] Movable zone start for each node
[0.00] Early memory node ranges
[0.00]   node   0: [mem 0x-0x3b2f]
[0.00]   node   0: [mem 0x4000-0xfbff]
[0.00]   node   0: [mem 0x0001-0x0001]
[0.00] Zeroed struct page in unavailable ranges: 256 pages
[0.00] Initmem setup node 0 [mem 0x-0x0001]
[0.00] On node 0 totalpages: 2061056
[0.00]   DMA zone: 3788 pages used for memmap
[0.00]   DMA zone: 0 pages reserved
[0.00]   DMA zone: 242432 pages, LIFO batch:63
[0.00]   DMA32 zone: 12288 pages used for memmap
[0.00]   DMA32 zone: 770048 pages, LIFO batch:63
[0.00]   Normal zone: 16384 pages used for memmap
[0.00]   Normal zone: 1048576 pages, LIFO batch:63
[0.00] percpu: Embedded 33 pages/cpu s95192 r8192 d31784 u135168
[0.00] pcpu-alloc: s95192 r8192 d31784 u135168 alloc=33*4096
[0.00] pcpu-alloc: [0] 0 [0] 1 [0] 2 [0] 3 
[0.00] Detected PIPT I-cache on CPU0
[0.00] CPU features: detected: EL2 vector hardening
[0.00] CPU features: kernel page table isolation forced ON by KASLR
[0.00] CPU features: detected: Kernel page table isolation (KPTI)
[0.00] CPU features: detected: Spectre-v2
[0.00] CPU features: detected: Spectre-v4
[0.00] CPU features: detected: ARM errata 1165522, 1319367, or 1530923
[0.00] Built 1 zonelists, mobility grouping on.  Total pages: 2028596
[0.00] Policy zone: Normal
[0.00] Kernel command line:  dma.dmachans=0x37f5 
bcm2709.boardrev=0xd03114 bcm2709.serial=0x488d2af3 bcm2709.uart_clock=4800 
bcm2709.disk_led_gpio=42 bcm2709.disk_led_active_low=0 
smsc95xx.macaddr=DC:A6:32:BB:99:D9 vc_mem.mem_base=0x3eb0 
vc_mem.mem_size=0x3ff0  root=LABEL=RASPIROOT rw fsck.repair=yes 
net.ifnames=0 rootwait
[0.00] Dentry cache hash table entries: 1048576 (order: 11, 8388608 
bytes, linear)
[0.00] Inode-cache hash table entries: 524288 (order: 10, 4194304 
bytes, linear)
[0.00] mem auto-init: stack:off, heap alloc:on, heap free:off
[0.00] software IO TLB: mapped [mem 
0x3300-0x3700] (64MB)
[0.00] Memory: 4919276K/8244224K available (9664K kernel code, 2424K 
rwdata, 3528K rodata, 5312K init, 587K bss, 274288K reserved, 65536K 
cma-reserved)
[0.00] random: get_random_u64 called from 
__kmem_cache_create+0x48/0x404 with crng_init=0
[0.00] SLUB: HWalign=64, Order=0-3, MinObjects=0, CPUs=4, Nodes=1
[0.00] ftrace: allocating 39727 entries in 156 pages
[0.00] ftrace: allocated 156 pages with 4 groups
[0.00] rcu: Hierarchical RCU implementation.
[  

Bug#980750: thanks a lot an bye ...

[alain]

I would like to thank you all for your help.

now, debian supports big navi graphics cards.

to start with, "navy21" cards are supported.
AMD RX 6800 /6800 XT /6900 XT
The 6700 and, perhaps, the 6500 are still to come.

With gcn3.0 support now enabled, it is likely that the RX 6x00 
generation will be fully supported.


remains a question : how did you know where the error came from ? and 
what to modify ?


respectfully .

alain.

p.s. you can close this thread.

Bug#980794: octave-iso2mesh: Arbitrary limitation of build architectures

[John Paul Adrian Glaubitz]

Source: octave-iso2mesh
Severity: normal
User: debian-...@lists.debian.org
Usertags: m68k
X-Debbugs-Cc: debian-...@lists.debian.org

Hello!

The last upload octave-iso2mesh arbitrarily limited the list of build
architectures on the assumption that only certain architectures have
buildds with enough disk spaces which is certainly not true. The available
disk space depends on the buildd used, not the architecture.

Furthermore, it may happen that the buildd disk space fills up which can
happen if the machine crashes, gets automatically rebooted and the previous
builds are therefore not cleaned up. This is something observed on the buildd
blaauw which crashes regularly due to a bug in the kernel [1].

Could you therefore remove the architecture limitation list or - at least -
re-add the Debian Ports architectures (e.g. alpha, hppa, ia64, m68k, powerpc,
ppc64, riscv64, sh4, sparc64 and x32)?

Thanks,
Adrian

> [1] https://bugzilla.kernel.org/show_bug.cgi?id=206669

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

Bug#413954: incompatibilities between graphicsmagick-imagemagick-compat and imagemagick

[Mattia Rizzolo]

On Fri, Oct 02, 2009 at 11:31:05AM -0400, Daniel Kahn Gillmor wrote:
> A few more things that are missing (i just ran into this while trying to
> convert some private scripts from imagemagick to
> graphicsmagick-imagemagick-compat:

And today I stumbled upon this, as a system that was supposed to have
"impagemagick" installed couldn't find the `compare` program, which has
been part of imagemagick since… whatever long, but apparently is not
provided by this graphicsmagick-imagemagick-compat package.


After all these years, if graphicsmagick can't keep up the interface of
imagemagick, please consider dropping this Provides, as it's really
just annoying and it clearly isn't serving its porpuses well enough.

-- 
regards,
Mattia Rizzolo

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


signature.asc
Description: PGP signature

Bug#980792: Cannot decrypt encrypted root at boot with cryptsetup-initramfs 2:2.3.4-2~bpo10+1 (buster-backports)

[Martin Küchler]

Package: cryptsetup-initramfs
Version: 2:2.3.4-1~bpo10+1
Severity: grave
Justification: renders package unusable

apt upgrade installed cryptsetup-initramfs 2:2.3.4-2~bpo10+1 over
2:2.3.4-1~bpo10+1 despite the fact that initramfs-tools stayed at 0.133+deb10u1
(no newer version available in buster or buster-backports).

apt-cache cryptsetup-initramfs

(for version 2:2.3.4-2~bpo10+1) says it depends on "initramfs-tools (>= 0.137)
| linux-initramfs-tool", while the changelog says it "now requires initramfs-
tools 0.137 or later and no longer copies libgcc_s.so.1 to the initrd since
recent initramfs-tools take care of it".

After the upgrade, booting with a newly created initrd doesn't allow to unlock
the encrypted root any more ("wrong password or unknown parameter").
Fortunately, the cryptsetup-initramfs' install script re-creates only the
current kernel's initrd, so that booting from an older kernel allowed me to get
into the system and to revert cryptsetup and cryptsetup-initramfs to
2:2.3.4-1~bpo10+1 which solved the problem.




-- Package-specific info:

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

Kernel: Linux 5.10.8-surface (SMP w/4 CPU cores)
Kernel taint flags: TAINT_CPU_OUT_OF_SPEC, TAINT_USER, TAINT_CRAP, 
TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=de_BE.UTF-8, LC_CTYPE=de_BE.UTF-8 (charmap=UTF-8), 
LANGUAGE=de_BE:de (charmap=UTF-8)
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages cryptsetup-initramfs depends on:
ii  busybox 1:1.30.1-4
ii  cryptsetup  2:2.3.4-1~bpo10+1
ii  debconf [debconf-2.0]   1.5.71
ii  initramfs-tools [linux-initramfs-tool]  0.133+deb10u1

Versions of packages cryptsetup-initramfs recommends:
ii  console-setup  1.193~deb10u1
ii  kbd2.0.4-4

cryptsetup-initramfs suggests no packages.

-- debconf information:
  cryptsetup-initramfs/prerm_active_mappings: true

Bug#980750: thanks

[alain]

I wish to thank the BTS and all those who participated, in particular, 
in the resolution of my concern.

a little word to nicholas and vincent for their kindness.

everything is almost perfect.
2 small residual bugs .
one on the linux-headers-amd64 meta-package
and a (curious) one for wayland operation .

but on the whole it's good.

happy new year to all and best wishes .

here are the latest reports :

sudo dpkg -l | grep -iE "linux-image-|linux-headers-"
ii linux-headers-5.10.0-1-amd64 5.10.5-1 amd64 Header files for Linux 
5.10.0-1-amd64
ii linux-headers-5.10.0-1-common 5.10.5-1 all Common header files for 
Linux 5.10.0-1
ii linux-headers-5.10.0-2-amd64 5.10.9-1 amd64 Header files for Linux 
5.10.0-2-amd64
ii linux-headers-5.10.0-2-common 5.10.9-1 all Common header files for 
Linux 5.10.0-2
ii linux-headers-amd64 5.10.5-1 amd64 Header files for Linux amd64 
configuration (meta-package)
ii linux-image-5.10.0-1-amd64 5.10.5-1 amd64 Linux 5.10 for 64-bit PCs 
(signed)
ii linux-image-5.10.0-2-amd64-unsigned 5.10.9-1 amd64 Linux 5.10 for 
64-bit PCs
ii linux-image-5.9.0-4-amd64 5.9.11-1 amd64 Linux 5.9 for 64-bit PCs 
(signed)

ii linux-image-amd64 5.10.5-1 amd64 Linux for 64-bit PCs (meta-package)

sudo apt-listbugs list linux-image-amd64 linux-headers-amd64
Retrieving bug reports... Done
Information analysis Found/Corrected... Done
serious serious bugs on linux-headers-amd64 (→ ) 
 b1 - #964335 - linux-headers-amd64: cannot upgrade to 5.7.6-1
Summary :
 linux-headers-amd64(1 bug)

xrandr
Screen 0: minimum 16 x 16, current 7680 x 2160, maximum 32767 x 32767
XWAYLAND0 connected primary 3840x2160+0+0 (normal left inverted right x 
axis y axis) 700mm x 390mm

   3840x2160 29.96*+
XWAYLAND1 connected 3840x2160+3840+0 (normal left inverted right x axis 
y axis) 700mm x 390mm

   3840x2160 29.96*+

Screen 0: minimum 320 x 200, current 7680 x 2160, maximum 16384 x 16384
DisplayPort-0 connected primary 3840x2160+0+0 (normal left inverted 
right x axis y axis) 697mm x 392mm

   3840x2160 60.00*+ 30.00 29.97
   2560x1440 59.95
   1920x1200 60.00
   1920x1080 60.00 59.94
   1600x1200 60.00
   1680x1050 59.95
   1600x900 60.00
   1280x1024 75.02 60.02
   1440x900 59.89
   1280x800 59.81
   1152x864 75.00
   1280x720 60.00 59.94
   1024x768 75.03 70.07 60.00
   832x624 74.55
   800x600 72.19 75.00 60.32 56.25
   640x480 75.00 72.81 66.67 60.00 59.94
   720x400 70.08
DisplayPort-1 connected 3840x2160+3840+0 (normal left inverted right x 
axis y axis) 697mm x 392mm

   3840x2160 60.00*+ 30.00 29.97
   2560x1440 59.95
   1920x1200 60.00
   1920x1080 60.00 59.94
   1600x1200 60.00
   1680x1050 59.95
   1600x900 60.00
   1280x1024 75.02 60.02
   1440x900 59.89
   1280x800 59.81
   1152x864 75.00
   1280x720 60.00 59.94
   1024x768 75.03 70.07 60.00
   832x624 74.55
   800x600 72.19 75.00 60.32 56.25
   640x480 75.00 72.81 66.67 60.00 59.94
   720x400 70.08
DisplayPort-2 disconnected (normal left inverted right x axis y axis)
HDMI-A-0 disconnected (normal left inverted right x axis y axis)

Bug#943874: pure-ftpd: pure-ftp error on upgrade

[Stefan Hornburg (Racke)]

On 1/18/21 11:55 PM, Andreas Beckmann wrote:
> Followup-For: Bug #943874
> Control: tag -1 patch pending
> 
> Hi,
> 
> I'm attaching a patch that tries to clean up the docdir symlink mess.
> The package is already uploaded to DELAYED/5.
> 
> 
> Andreas
> 

Thanks a lot for your fixes!

Regards
   Racke

-- 
Ecommerce and Linux consulting + Perl and web application programming.
Debian and Sympa administration. Provisioning with Ansible.



OpenPGP_signature
Description: OpenPGP digital signature

Bug#980796: ITP: ruby-gitlab-pg-query -- PostgreSQL query parsing and normalization library

[Pirate Praveen]

Package: wnpp
Severity: wishlist
Owner: Pirate Praveen 

Packaging of https://rubygems.org/gems/gitlab-pg_query

Dependency of gitlab 13.6

Bug#980795: Security fixes from the January 2021 CPU

[Lars Tangvald]

Source: mysql-8.0
Version: 8.0.22
Severity: grave
Tags: security upstream fixed-upstream


The Oracle Critical Patch Update for October 2020 lists CVEs affecting MySQL 
8.0 that are fixed in 8.0.23

CVE list:
    - CVE-2021-1998 CVE-2021-2001 CVE-2021-2002 CVE-2021-2087
    - CVE-2021-2009 CVE-2021-2012 CVE-2021-2016 CVE-2021-2019
    - CVE-2021-2020 CVE-2021-2021 CVE-2021-2022 CVE-2021-2024
    - CVE-2021-2028 CVE-2021-2030 CVE-2021-2031 CVE-2021-2032
    - CVE-2021-2036 CVE-2021-2038 CVE-2021-2042 CVE-2021-2046
    - CVE-2021-2048 CVE-2021-2055 CVE-2021-2056 CVE-2021-2058
    - CVE-2021-2060 CVE-2021-2061 CVE-2021-2065 CVE-2021-2070
    - CVE-2021-2072 CVE-2021-2076 CVE-2021-2081 CVE-2021-2088
    - CVE-2021-2122

Ref: https://www.oracle.com/security-alerts/cpujan2021.html#AppendixMSQL

Regards,

Lars Tangvald

Bug#942529: phabricator: Please provide phabricator package again

[Christoph Biedl]

Control: tags 942529 pending

Christoph Biedl wrote...

> Sylvestre Ledru wrote...
> 
> > I won't have the time to do it. So, someone will have to step in to do it.
> 
> Cannot say I'd have the time to do so either - but on the other hand,
> having a Debian package would avoid having to do maintenance manually.

So, to keep everybody informed, I am currently working on this, the
initial work, surprise, was not sufficient. Still the goal is to bring
this into bullseye. Which means having to go through NEW so time is
really short.

Keep fingers crossed.

Christoph


signature.asc
Description: PGP signature

Bug#980768: [pkg-gnupg-maint] Bug#980768: gnupg2: reduce Build-Depends

[Werner Koch]

>  * libcurl4-gnutls-dev is unused. While curl is mentioned in source
>comments and checked for in configure, it is never actually used.

You mean GnuPG's configure?  I can't find it.  It was tested for in
GnuPG 1 and 2.0 but not anymore since 2.1.  I am just a curious
upstream.


Salam-Shalom,

   Werner

-- 
* Free Assange and protect free journalism!
* Germany: Sign the Treaty on the Prohibition of Nuclear Weapons!


signature.asc
Description: PGP signature

Bug#980204: gdc: Resulting executables segfault on mipsel architecture (signal 11)

[Iain Buclaw]

Excerpts from Matija Nalis's message of January 16, 2021 3:54 am:
> Package: gdc
> Version: 4:10.2.1-1
> Severity: normal
> X-Debbugs-Cc: mnalis-debian...@voyager.hr
> 
> Dear Maintainer,
> 
> compiling D programs with gdc produces excutable, but trying to run that 
> executable segfaults.
> I've tried various gdc flags, but never managed to produce even the simplest 
> working program.
> 
> on Debian Sid in chroot:
> 
> (mipsel-chroot)$ printf 'import std.stdio;\nvoid main()  { writeln("Hello, 
> World!"); }\n' > hello.d ; gdc  hello.d && ./a.out
> qemu: uncaught target signal 11 (Segmentation fault) - core dumped
> Segmentation fault
> 
> This is with host running Buster with qemu-user 1:5.2+dfsg-3~bpo10+1
> but the other not-too-complicated D programs fail on Debian buildd 
> infrastructure too:
> https://buildd.debian.org/status/fetch.php?pkg=ironseed=mipsel=0.3.6-4=1610676343=0
> 

Hi,

Building current gdc-master on a MIPS server (running Debian Jessie, I
don't seem to have access to the Buster node), I can't reproduce the
segfault.  What are the chances of it being QEMU that's the cause?

Also, are you linking to the static or shared libphobos library?

Running the testsuite now, to see if there's any reported failures, but
none so far...

Iain.

Bug#714499: segfault on connexion lost

[Florian Schlichting]

On Sat, Jun 29, 2013 at 08:43:37PM -0400, Antoine Beaupré wrote:
> From what I can tell, it looks like loudmouth is throwing an exception
> and the plugin is not handling it so crashes.
> 
> This is the code where this happens, I believe:
> 
> static void
> server_cleanup(XMPP_SERVER_REC *server)
> {
>   if (!IS_XMPP_SERVER(server))
>   return;
>   if (server->timeout_tag)
>   g_source_remove(server->timeout_tag);
>   if (lm_connection_get_state(server->lmconn) !=
>   LM_CONNECTION_STATE_CLOSED)
>   lm_connection_close(server->lmconn, NULL);
>   lm_connection_unref(server->lmconn);
>   g_free(server->jid);
>   g_free(server->user);
>   g_free(server->domain);
>   g_free(server->resource);
>   g_free(server->ping_id);
> }
> 
> Some try/catch around this may resolve the issue, but keep in mind
> that this function is called from a signal emitted elsewhere
> (server_disconnect()) so maybe that's where it should be handled
> instead.

Something like this landed upstream as part of
https://github.com/cdidier/irssi-xmpp/commit/5cc5fea5970fe19e1a3a2a1b6cb4b7436cc813fd
If that's where the problem was, it should be fixed as of
irssi-plugin-xmpp 0.54+git20191101+c13fa5-1

Florian

Bug#980799: buster-pu: package irssi-plugin-xmpp/0.54-3

[Florian Schlichting]

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

As explained in #931886 / upstream at
https://github.com/cdidier/irssi-xmpp/issues/43, due to recent changes
in irssi, irssi-plugin-xmpp in buster is unable to establish STARTTLS
connections because the connect timeout triggers prematurely.

This update contains a one-line patch that allows the intended
connection timeout to take effect.

I have verified that this bug is present in the version of
irssi-plugin-xmpp in buster and fixed by this proposed update. A
corresponding fix has just been uploaded to unstable as part of
irssi-plugin-xmpp 0.54+git20191101+c13fa5-1.

As I think the change is rather trivial and low-risk, I take the liberty
to upload to buster-pu right away. Debdiff below.

Florian


diff -Nru irssi-plugin-xmpp-0.54/debian/changelog 
irssi-plugin-xmpp-0.54/debian/changelog
--- irssi-plugin-xmpp-0.54/debian/changelog 2019-03-27 19:57:14.0 
+0800
+++ irssi-plugin-xmpp-0.54/debian/changelog 2021-01-22 21:53:27.0 
+0800
@@ -1,3 +1,11 @@
+irssi-plugin-xmpp (0.54-3+deb10u1) buster; urgency=medium
+
+  * Cherry-pick bug931886.patch from upstream to not trigger the irssi core
+connect timeout prematurely, thus fixing STARTTLS connections
+(closes: #931886)
+
+ -- Florian Schlichting   Fri, 22 Jan 2021 21:53:27 +0800
+
 irssi-plugin-xmpp (0.54-3) unstable; urgency=medium
 
   * drop -dbg→-dbgsym transition (no longer needed)
diff -Nru irssi-plugin-xmpp-0.54/debian/patches/bug931886.patch 
irssi-plugin-xmpp-0.54/debian/patches/bug931886.patch
--- irssi-plugin-xmpp-0.54/debian/patches/bug931886.patch   1970-01-01 
08:00:00.0 +0800
+++ irssi-plugin-xmpp-0.54/debian/patches/bug931886.patch   2021-01-22 
21:53:06.0 +0800
@@ -0,0 +1,16 @@
+commit 57c62278b97aeb999f3ca2e2b8a492f364405b61
+Author: Ailin Nemui 
+Date:   Tue Jan 29 21:37:05 2019 +0100
+
+do not trigger the irssi core connect timeout prematurely
+
+--- a/src/core/xmpp-servers.c
 b/src/core/xmpp-servers.c
+@@ -528,6 +528,7 @@
+   }
+   lm_connection_set_disconnect_function(server->lmconn,
+   lm_close_cb, server, NULL);
++  server->connect_time = time(NULL);
+   lookup_servers = g_slist_append(lookup_servers, server);
+   signal_emit("server looking", 1, server);
+   server->timeout_tag = g_timeout_add(
diff -Nru irssi-plugin-xmpp-0.54/debian/patches/series 
irssi-plugin-xmpp-0.54/debian/patches/series
--- irssi-plugin-xmpp-0.54/debian/patches/series2019-03-27 
19:57:14.0 +0800
+++ irssi-plugin-xmpp-0.54/debian/patches/series2021-01-22 
21:52:47.0 +0800
@@ -42,3 +42,4 @@
 ailin-nemui-0008-Add-support-for-messages-coming-directly-from-room.patch
 ailin-nemui-0009-Add-support-for-mode-change-in-MUC.patch
 comparison-between-pointer-and-zero-character-constant.patch
+bug931886.patch

Bug#861758: awscli: Missing manpages for aws/aws_completer

[Dominique Dumont]

On Wednesday, 20 January 2021 09:08:05 CET Mathieu Malaterre wrote:
> It looks like it is possible to generate on the fly a manpage using:
> 
> $ aws help > aws.1

This does not produce a nroff file, but a file containing escape sequence to 
provide formatting in a terminal.

On the other hand, this means that man information is available in aws 
sources. The questions are now: where and which format ?

HTH

Bug#980472: cubicsdr: CubicSDR crashes after lauch! (same effect on 2 clean bullseye OS)

[Christoph Berg]

Re: LH
> Hi Cristoph
> 
> Backtrace:
> You can find my terminal output below ... not shure if this is what you
> want.

Almost:

> [Switching to Thread 0x7fffb97ff700 (LWP 8318)]
> 0x76712009 in std::_Rb_tree_insert_and_rebalance(bool,
> std::_Rb_tree_node_base*, std::_Rb_tree_node_base*,
> std::_Rb_tree_node_base&) ()
>    from /lib/x86_64-linux-gnu/libstdc++.so.6
> (gdb)

At that point, type "bt f" (backtrace full).

Christoph

Bug#980798: RM: dindel & seqan -- ROM; Abandonded by upstream, FTBFS

[Michael R. Crusoe]

Package: ftp.debian.org
Severity: normal
X-Debbugs-Cc: cru...@debian.org

The dindel upstream repository [0] is "archived", the linked homepage
[1] 404s, and the only other reference on the original authors'
website[2] lists "Archive page. This resource is no longer available at the
Sanger Institute." and "This page is maintained as a historical record and is
no longer being updated."

Dindel requires seqan 1.4 which FTBFS[3] with gcc-10 and which is itself no
longer supported upstream. Upstream has declined to fix the FTBFS
bug[4] and they are focused on seqan 3 (seqan 2.x already being
superceded).

There are no other users of seqan 1.x in Debian.

Therefore I request that both source packages and their binary packages
be removed from the archive.

Many thanks!

[0] https://github.com/genome/dindel-tgi
[1] https://www.sanger.ac.uk/resources/software/dindel/
[2] https://www.sanger.ac.uk/tool/dindel/
[3] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=980685
[4] https://gitter.im/seqan/Lobby?at=600ad64f36db01248a951c84

-- 
Michael R. Crusoe

Bug#980752: Acknowledgement (ifupdown: discrepancy in IPv6 operation with USB WiFi dongles AP)

[Martin-Éric Racine]

If anyone asks me, the correct behavior for any interface that uses
the manual method should be to never create the IPv6 fe80 local link,
and instead assume that it will be manually created via other means,
the same way it already is for Ethernet devices. Whether the interface
is listed on the allow-hotplug line should not have any influence on
this behavior.

Bug#980791: clamav-unofficial-sigs: Patching is needed to get it running:

[Volker Bäurer]

Package: clamav-unofficial-sigs
Version: 3.7.2-2
Severity: important

Dear Maintainer,
most people use the manual installing procedure of the 
clamav-unofficial app (you can find everywhere in the www) because the debian 
package is faulty since a long time.
But installing the debian package could be working out-of-the-box when 
having my patches included. Then the installation has much less expenses than 
the manual installing procedure, which means a big advantage in my opinion.

Concrete: The installation fails because of no longer valid urls and 
databases and missing path-information inside the binary

So I patched the package and its configuration file:
sed -i 
"s/^si_url=\"clamav.securiteinfo.com\"/si_url=\"www.securiteinfo.com\"/" 
/usr/sbin/clamav-unofficial-sigs
sed -i 
"s/^mbl_url=\"www.malwarepatrol.net\"/mbl_url=\"lists.malwarepatrol.net\"/" 
/usr/sbin/clamav-unofficial-sigs

sed -i "s/if clamscan/if \/usr\/bin\/clamscan/" 
/usr/sbin/clamav-unofficial-sigs
sed -i "s/clamscan --infected/\/usr\/bin\/clamscan --infected/" 
/usr/sbin/clamav-unofficial-sigs
sed -i "s/clamscan --quiet/\/usr\/bin\/clamscan --quiet/" 
/usr/sbin/clamav-unofficial-sigs

Then I made a default configuration file:
/etc/clamav-unofficial-sigs.conf.d/local.conf
#As the version in Debian is quite outdated, it tries by default to 
download some
#files that don't exist anymore. This is fixed by creating file:
#/etc/clamav-unofficial-sigs.conf.d/local.conf

log_file_path="/var/log"
reload_dbs=yes

si_url="www.securiteinfo.com"
#  Empty db-list because they are no longer running on securiteinfo.com
# https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=783228
si_dbs=""

#The whole www.malwarepatrol.net seems to be dead right now
#mbl_url="www.malwarepatrol.net"
#But the lists.malwarepatrol.net site still seems to be up
mbl_url="lists.malwarepatrol.net"
# Empty db-list because you have to be registered first when using it
# https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=831607
mbl_dbs=""

ss_dbs="
junk.ndb
jurlbl.ndb
jurlbla.ndb
lott.ndb
phish.ndb
rogue.hdb
sanesecurity.ftm
sigwhitelist.ign2
scam.ndb
spam.ldb
spamimg.hdb
spamattach.hdb
spear.ndb
spearl.ndb
blurl.ndb
foxhole_generic.cdb
foxhole_filename.cdb
foxhole_js.ndb
malwarehash.hsb
hackingteam.hsb
badmacro.ndb
shelter.ldb
winnow_malware.hdb
winnow_malware_links.ndb
winnow_spam_complete.ndb
winnow_phish_complete_url.ndb
winnow.complex.patterns.ldb
winnow_extended_malware.hdb
winnow_extended_malware_links.ndb
winnow.attachments.hdb
winnow_bad_cw.hdb
MiscreantPunch099-Low.ldb
scamnailer.ndb
bofhland_cracked_URL.ndb
bofhland_malware_URL.ndb
bofhland_phishing_URL.ndb
bofhland_malware_attach.hdb
phishtank.ndb
"
With this, the installation will run smoothly

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

Kernel: Linux 5.4.78-2-pve (SMP w/4 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US:en (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages clamav-unofficial-sigs depends on:
ii  bind9-host [host]  1:9.11.5.P4+dfsg-5.1+deb10u2
ii  clamav 0.102.4+dfsg-0+deb10u1
ii  curl   7.64.0-4+deb10u1
ii  dnsutils   1:9.11.5.P4+dfsg-5.1+deb10u2
ii  gnupg  2.2.12-1+deb10u1
ii  rsync  3.1.3-6

clamav-unofficial-sigs recommends no packages.

Versions of packages clamav-unofficial-sigs suggests:
ii  clamav-daemon  0.102.4+dfsg-0+deb10u1

-- no debconf information

Mit freundlichen Grüßen / Best regards

Volker Bäurer
IT-Specialist

Mitutoyo CTL Germany GmbH
Von-Gunzert-Straße 17
D-78727 Oberndorf
GERMANY
T +49-7423-8776-0
volker.baeu...@mitutoyo-ctl.de
www.mitutoyo-ctl.de

Registered Company: Mitutoyo CTL Germany GmbH
Registered Office: Von Gunzert Straße 17, D-78727 Oberndorf am Neckar
Commercial register of the local court: Amtsgericht Stuttgart, HRB 734157
VAT number: DE272400711
Managing Director: Hans-Peter Klein

Bug#980472: cubicsdr: CubicSDR crashes after lauch! (same effect on 2 clean bullseye OS)

[LH]

Hi Christian

below the result (and thanks for your patient guideance).

Louis HB

---

root@pc-168:~# gdb CubicSDR
GNU gdb (Debian 10.1-1.7) 10.1.90.20210103-git
Copyright (C) 2021 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 


This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Type "show copying" and "show warranty" for details.
This GDB was configured as "x86_64-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
.
Find the GDB manual and other documentation resources online at:
    .

For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from CubicSDR...
(No debugging symbols found in CubicSDR)
(gdb) r
Starting program: /usr/bin/CubicSDR
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
Loaded 256 rig models via hamlib.
[New Thread 0x72cff700 (LWP 1300)]
[New Thread 0x724fe700 (LWP 1301)]
[New Thread 0x71cfd700 (LWP 1302)]
[New Thread 0x71406700 (LWP 1303)]
[New Thread 0x70c05700 (LWP 1304)]
[New Thread 0x7fffe2f1b700 (LWP 1305)]
[New Thread 0x7fffda71a700 (LWP 1306)]
[New Thread 0x7fffe271a700 (LWP 1307)]
[New Thread 0x7fffe1f19700 (LWP 1308)]
[New Thread 0x7fffbc1df700 (LWP 1309)]
[New Thread 0x7fffba4f6700 (LWP 1310)]
[Thread 0x7fffba4f6700 (LWP 1310) exited]

Audio Device #0 PulseAudio
    Default Output? Yes
    Default Input? Yes
    Input channels: 2
    Output channels: 2
    Duplex channels: 2
    Native formats:
        16-bit signed integer.
        32-bit signed integer.
        32-bit float normalized between plus/minus 1.0.
    Supported sample rates:
        8000hz
        16000hz
        22050hz
        32000hz
        44100hz
        48000hz
        96000hz

[New Thread 0x7fffba475700 (LWP 1311)]
[New Thread 0x7fffb9833700 (LWP 1312)]
[New Thread 0x7fffb9032700 (LWP 1313)]
SDR enumerator starting.
SoapySDR init..
    API Version: v0.7.1
    ABI Version: v0.7
    Install root: /usr
    Loading modules...
    Available factories...airspy, audio, bladerf, hackrf, lime, null, 
osmosdr, redpitaya, remote, rtlsdr, uhd

[New Thread 0x7fffa9268700 (LWP 1314)]
[New Thread 0x7fff9700 (LWP 1316)]
[New Thread 0x7fffa8a67700 (LWP 1315)]
[New Thread 0x7fff9f7fe700 (LWP 1317)]
[New Thread 0x7fffba4f6700 (LWP 1318)]
[New Thread 0x7fff9e5fd700 (LWP 1319)]
[New Thread 0x7fff9ddfc700 (LWP 1320)]
Hash collision!!! Fatal error!!
[New Thread 0x7fffe1f19700 (LWP 1322)]
[Thread 0x7fff9e5fd700 (LWP 1319) exited]
[Thread 0x7fffba4f6700 (LWP 1318) exited]
[Thread 0x7fff9f7fe700 (LWP 1317) exited]
[Thread 0x7fffa9268700 (LWP 1314) exited]
[New Thread 0x7fff9d5fb700 (LWP 1321)]
[Thread 0x7fffba475700 (LWP 1311) exited]
[Thread 0x7fffe1f19700 (LWP 1308) exited]
[Thread 0x7fffe271a700 (LWP 1307) exited]
[Thread 0x7fffda71a700 (LWP 1306) exited]
[Thread 0x7fffe2f1b700 (LWP 1305) exited]
[Thread 0x7fff9d5fb700 (LWP 1321) exited]
--Type  for more, q to quit, c to continue without paging--c

Thread 15 "CubicSDR" received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x7fffb9032700 (LWP 1313)]
0x76712009 in std::_Rb_tree_insert_and_rebalance(bool, 
std::_Rb_tree_node_base*, std::_Rb_tree_node_base*, 
std::_Rb_tree_node_base&) () from /lib/x86_64-linux-gnu/libstdc++.so.6

(gdb) bt f

  #0  0x76712009 in std::_Rb_tree_insert_and_rebalance(bool, 
std::_Rb_tree_node_base*, std::_Rb_tree_node_base*, 
std::_Rb_tree_node_base&) ()

   from /lib/x86_64-linux-gnu/libstdc++.so.6
No symbol table info available.
#1  0x76a81e96 in 
SoapySDR::Device::enumerate(std::mapstd::char_traits, std::allocator >, 
std::__cxx11::basic_string, 
std::allocator >, std::lessstd::char_traits, std::allocator > >, 
std::allocatorstd::char_traits, std::allocator > const, 
std::__cxx11::basic_string, 
std::allocator > > > > const&) ()

   from /lib/x86_64-linux-gnu/libSoapySDR.so.0.7
No symbol table info available.
#2  0x556671ae in 
SDREnumerator::enumerate_devices(std::__cxx11::basic_stringstd::char_traits, std::allocator >, bool) ()

No symbol table info available.
#3  0x5566a0b1 in SDREnumerator::run() ()
No symbol table info available.
#4  0x556444fa in IOThread::threadMain() ()
No symbol table info available.
#5  0x76724ed0 in ?? () from /lib/x86_64-linux-gnu/libstdc++.so.6
No symbol table info available.
--Type  for more, q to quit, c to continue without paging--RET
#6  0x764deea7 in start_thread (arg=) at 
pthread_create.c:477

    ret = 
    pd = 
    unwind_buf = {cancel_jmp_buf = {{jmp_buf = {140736297166592, 
-6303062190392514397, 140737488348702,
    140737488348703, 140736297162816, 8396800, 
6302919253074208931, 

Bug#980797: debian-installer: root fs very small when choosing a desktop environemnt

[Andreas Schlager]

Package: debian-installer
Version: 20201202
Severity: normal
X-Debbugs-Cc: andreas.schla...@sbg.at

I just had installed latest debian 11 testing (20210221) with default fs layout 
(see below).
Additional to the default SW I choosed GNOME desktop environment.
Now after the first start, I'm already getting a warning "low disk space on /"
In my opinion, the question about installed software should be asked before 
running the partitioner, so it can calculate the size of the filesystems 
properly.

Here the actual output of df -h:
Dateisystem Größe Benutzt Verf. Verw% Eingehängt auf
udev 468M   0  468M0% /dev
tmpfs 99M2,6M   96M3% /run
/dev/mapper/rootvg-root  4,0G3,6G  164M   96% /
tmpfs491M   0  491M0% /dev/shm
tmpfs5,0M4,0K  5,0M1% /run/lock
/dev/vda1472M 58M  391M   13% /boot
/dev/mapper/rootvg-var   1,6G323M  1,2G   22% /var
/dev/mapper/rootvg-home   13G 54M   12G1% /home
/dev/mapper/rootvg-tmp   345M2,1M  321M1% /tmp
tmpfs 99M 48K   99M1% /run/user/0
tmpfs 99M120K   99M1% /run/user/1000



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

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

Bug#980640: closed by Debian FTP Masters (reply to gregor herrmann ) (Bug#980640: fixed in libdbd-mariadb-perl 1.21-2)

[gregor herrmann]

Control: reopen -1
Control: found -1 1.21-2

On Fri, 22 Jan 2021 12:51:06 +, Debian Bug Tracking System wrote:

> #980640: libdbd-mariadb-perl: FTBFS: E: Build killed with signal TERM after 
> 150 minutes of inactivity
> It has been closed by Debian FTP Masters  
> (reply to gregor herrmann ).

Except that the tests fail on some architectures:

https://buildd.debian.org/status/logs.php?pkg=libdbd-mariadb-perl=1.21-2

They fail after the test, in the teardown step:

All tests successful.
Files=90, Tests=3590, 44 wallclock secs ( 0.67 usr  0.16 sys + 14.42 cusr  1.70 
csys = 16.95 CPU)
Result: PASS
make[2]: Leaving directory '/<>'

# tear down mariadb/mysql server
sh /<>/debian/tests/pkg-perl/smoke-cleanup
2021-01-22 13:01:57 139 [Warning] Access denied for user 'root'@'localhost'
/usr/bin/mysqladmin: connect to server at 'localhost' failed
error: 'Access denied for user 'root'@'localhost''
2021-01-22 13:01:57 0 [Note] /usr/sbin/mysqld (initiated by: unknown): Normal 
shutdown
2021-01-22 13:01:57 0 [Note] Event Scheduler: Purging the queue. 0 events
2021-01-22 13:01:57 0 [Note] InnoDB: FTS optimize thread exiting.
2021-01-22 13:01:57 0 [Note] InnoDB: Starting shutdown...
2021-01-22 13:01:57 0 [Note] InnoDB: Dumping buffer pool(s) to 
/<>/t/testdb/ib_buffer_pool
2021-01-22 13:01:57 0 [Note] InnoDB: Buffer pool(s) dump completed at 210122 
13:01:57
rm: cannot remove '/<>/t/testdb': Directory not empty

make[1]: *** [debian/rules:32: override_dh_auto_test] Error 1
make[1]: Leaving directory '/<>'
make: *** [debian/rules:22: binary-arch] Error 2
dpkg-buildpackage: error: debian/rules binary-arch subprocess returned exit 
status 2


The problem with root is the same as in smoke-setup.
Why the `rm -rf' works on some architectures and not on others
is a bit of a miracle.


Cheers,
gregor, trying some more things

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


signature.asc
Description: Digital Signature

Bug#929685: another fix

[Bastian Blank]

Hi

To fix this cycle, which makes any package dependency on
default-jre-headless unstable, I propose to change the dependency in
ca-certificates-java to just specify openjdk-11-jre-headless, without
any default-jre-headless alternative.

Yes, this will cause the default java version to be installed, but this
seems way better then all the alternatives.

Yes, this does not fix the cycle between java and ca-certificates-java,
but at least it breaks less.

Regards,
Bastian

-- 
"Beauty is transitory."
"Beauty survives."
-- Spock and Kirk, "That Which Survives", stardate unknown

Bug#980751: petsc: breaks multiple autopkgtests: undefined reference to 'MPIU_SUM'

[Graham Inggs]

Control: severity -1 important

Indeed, these autopkgtests were fixed by the binNMU of slepc.

Lowering severity so openmpi and petsc can migrate, but we need to
figure out what happened here so we can prevent it in future.

Does slepc need a tighter dependency on the version of slepc that it
was built against?

Bug#980800: djview: No longer accepts a local DjVu document URL

[Janusz S. Bień]

Package: djview
Version: 3.5.27.1-10
Severity: important

The feature is essential for using and creating indexes like this:

https://github.com/jsbien/Zaborowski-index4djview

Used to work not long ago.

A sample message for an indirect call from djview4poliqarp::

djview: cannot open 
'file:Zaborowski_MBC.djvu?djvuopts==388,950,128,52=1'.

And an example of an explicit invocation:

djview file:///Zaborowski_MBC.djvu?djvuopts==388,950,128,52=1
djview: cannot open 'file:///Zaborowski_MBC.djvu?djvuopts='.

Best regards

Janusz


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

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

Versions of packages djview depends on:
ii  djview4  4.11-1

djview recommends no packages.

djview suggests no packages.

-- no debconf information

-- 
 ,   
Janusz S. Bien
emeryt (emeritus)
https://sites.google.com/view/jsbien

Bug#980685: seqan: FTBFS: dh_auto_test: error: cd obj-x86_64-linux-gnu && make -j4 test ARGS\+=-j4 returned exit code 2

[Michael R. Crusoe]

Already done, after consulting with the Seqan developers:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=980798

Bug#980204: gdc: Resulting executables segfault on mipsel architecture (signal 11)

[Matija Nalis]

On Fri, Jan 22, 2021 at 12:59:34PM +0100, Iain Buclaw wrote:
> > (mipsel-chroot)$ printf 'import std.stdio;\nvoid main()  { writeln("Hello, 
> > World!"); }\n' > hello.d ; gdc  hello.d && ./a.out
> > qemu: uncaught target signal 11 (Segmentation fault) - core dumped
> > Segmentation fault
> > 
> > This is with host running Buster with qemu-user 1:5.2+dfsg-3~bpo10+1
> > but the other not-too-complicated D programs fail on Debian buildd 
> > infrastructure too:
> > https://buildd.debian.org/status/fetch.php?pkg=ironseed=mipsel=0.3.6-4=1610676343=0
> 
> Building current gdc-master on a MIPS server (running Debian Jessie, I
> don't seem to have access to the Buster node), I can't reproduce the
> segfault.  What are the chances of it being QEMU that's the cause?

I would be first to blame qemu in my virtual chroot on amd64, but I
was under impression the Debian buildd machine that failed was real
hardware? I could be wrong though, this is information for buildd machine
referenced in bug report where gdc failed:

https://db.debian.org/machines.cgi?host=eberlin

The program there segfaulted there was more complex than simple "hello world", 
though.
(but it does work without any problems on all other architectures with gdc)

> Also, are you linking to the static or shared libphobos library?

shared (default):

(mipsel-chroot):/tmp/w$ dpkg -l gdc | grep gdc
ii  gdc4:10.2.1-1   mipsel   D compiler (language version 2), 
based on the GCC backend

(mipsel-chroot):/tmp/w$ printf 'import std.stdio;\nvoid main()  { 
writeln("Hello, World!"); }\n' > hello.d ; gdc hello.d && ./a.out
qemu: uncaught target signal 11 (Segmentation fault) - core dumped
Segmentation fault

(mipsel-chroot):/tmp/w$ file a.out
a.out: ELF 32-bit LSB pie executable, MIPS, MIPS32 rel2 version 1 (SYSV), 
dynamically linked, interpreter /lib/ld.so.1, 
BuildID[sha1]=36c5576b94519b416c1996018760159ae925bc34, for GNU/Linux 3.2.0, 
not stripped

(mipsel-chroot):/tmp/w$ ldd a.out
libgphobos.so.1 => /lib/mipsel-linux-gnu/libgphobos.so.1 (0x7f1a3000)
libgcc_s.so.1 => /lib/mipsel-linux-gnu/libgcc_s.so.1 (0x7f16b000)
libc.so.6 => /lib/mipsel-linux-gnu/libc.so.6 (0x7efd1000)
libm.so.6 => /lib/mipsel-linux-gnu/libm.so.6 (0x7ef52000)
libpthread.so.0 => /lib/mipsel-linux-gnu/libpthread.so.0 (0x7ef21000)
libdl.so.2 => /lib/mipsel-linux-gnu/libdl.so.2 (0x7ef0d000)
libz.so.1 => /lib/mipsel-linux-gnu/libz.so.1 (0x7eee2000)
/lib/ld.so.1 (0x7ffc9000)


But good point, when I try to link this "hello world" example statically, it
throws warnings, but works!

(mipsel-chroot):/tmp/w$ printf 'import std.stdio;\nvoid main()  { 
writeln("Hello, World!"); }\n' > hello.d ; gdc -static hello.d && ./a.out
/usr/bin/ld: /usr/lib/gcc/mipsel-linux-gnu/10/libgphobos.a(elf_shared.o): in 
function `_D3gcc8sections10elf_shared18pinLoadedLibrariesFNbNiZPv':
/build/gcc-10-XdUysA/gcc-10-10.2.1/build/mipsel-linux-gnu/libphobos/libdruntime/../../../../src/libphobos/libdruntime/gcc/sections/elf_shared.d:250:
 warning: Using 'dlopen' in statically linked applications requires at runtime 
the shared libraries from the glibc version used for linking
/usr/bin/ld: /usr/lib/gcc/mipsel-linux-gnu/10/libgphobos.a(stdio.o): in 
function `_D3std5stdio11openNetworkFAyatZS3std5stdio4File':
/build/gcc-10-XdUysA/gcc-10-10.2.1/build/mipsel-linux-gnu/libphobos/src/../../../../src/libphobos/src/std/stdio.d:5137:
 warning: Using 'gethostbyname' in statically linked applications requires at 
runtime the shared libraries from the glibc version used for linking
Hello, World!

(mipsel-chroot):/tmp/w$ file a.out
a.out: ELF 32-bit LSB executable, MIPS, MIPS32 rel2 version 1 (GNU/Linux), 
statically linked, BuildID[sha1]=2da3a20d4fe083f1c33f79e4d259f91f8ed7696d, for 
GNU/Linux 3.2.0, with debug_info, not stripped

(mipsel-chroot):/tmp/w$ dpkg -l "libgphobos*" | grep '^ii'
ii  libgphobos-10-dev:mipsel 10.2.1-6 mipsel   Phobos D standard library
ii  libgphobos-dev:mipsel10.2.1-1 mipsel   Phobos D standard library
ii  libgphobos1:mipsel   10.2.1-6 mipsel   Phobos D standard 
library (runtime library)


> Running the testsuite now, to see if there's any reported failures, but
> none so far...


However, when I try to build and run the more complex program 
Data_Generators/makedata/logmake.d
from this version: 
http://snapshot.debian.org/archive/debian/20210115T023714Z/pool/main/i/ironseed/ironseed_0.3.6-4.dsc

it still fails with segfault on my qemu mipsel chroot, even when '-static' is 
added 
(as it did on Debian buildd machine "eberlin.debian.org"):

(mipsel-chroot):/tmp/w/is/ironseed-0.3.6$ gdc -static -o 
Data_Generators/makedata/logmake Data_Generators/makedata/logmake.d 
Data_Generators/makedata/data.d && Data_Generators/makedata/logmake 
Data_Generators/makedata/logs.txt data/titles.dta data/log.dta
/usr/bin/ld: /usr/lib/gcc/mipsel-linux-gnu/10/libgphobos.a(elf_shared.o): in 
function 

Bug#980802: buster-pu: package nvidia-graphics-drivers/418.181.07-1

[Andreas Beckmann]

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

Hi,

I'd like to update nvidia-graphics-drivers in buster again to a new upstream
release from the Tesla 418 series to fix CVE-2021-1056.

This driver release is also available as
  src:nvidia-graphics-drivers-tesla-418
in sid (and soon bullseye and buster-backports).

Again, it comes with some packaging changes (but not as many as in
previous pu requests):
- overhaul and simplify handling of patches for the kernel modules
  and building the kernel module source and dkms packages
- test at package build time whether the patches can be applied to
  the kernel module source
- introduce the libnvidia-cfg.so.1 versioned virtual package
- reorganize the changelog (splitting/adding UNRELEASED entries
  corresponding to uploads of the legacy and tesla branches) for
  easier diffing between branches
- documentation and metadata updates

These changes are well tested in sid, bullseye and buster-backports
and I'd like to include them in buster, too, in order to minimize the
diff between the different branches being maintained.

Andreas


ngd-418.181.07-1.diff.xz
Description: application/xz

Bug#980801: pgcharts: FTBFS with sbcl 2.1

[Andreas Beckmann]

Source: pgcharts
Version: 1.0+2017-09-16-1
Severity: serious
Tags: ftbfs
Justification: fails to build from source

Hi,

pgcharts recently started to FTBFS due to a change in its build
dependencies. I have a successful build log from Dec 01 and looking at the
difference in packages installed the most likely culprit seems to be the
upgrade of sbcl from 2:2.0.11-1 to 2:2.1.0-1


   debian/rules override_dh_auto_build
make[1]: Entering directory '/build/pgcharts-1.0+2017-09-16'
mkdir -p build/bin
mkdir -p /build/pgcharts-1.0+2017-09-16/debian/home
buildapp --logfile /tmp/pgcharts-build.log  \
 --require sb-posix \
 --load /usr/share/common-lisp/source/cl-asdf/build/asdf.lisp \
 --asdf-path .  \
 --asdf-tree /usr/share/common-lisp/systems \
 --load-system pgcharts \
 --load src/image.lisp  \
 --load debian/settings.lisp\
 --entry pgcharts:main  \
 --dynamic-space-size 4096   \
 --compress-core\
 --output build/bin/pgcharts
; compiling file "/usr/share/common-lisp/source/cl-asdf/build/asdf.lisp" 
(written 14 JAN 2021 01:45:37 PM):

; wrote 
/build/pgcharts-1.0+2017-09-16/debian/home/.cache/common-lisp/sbcl-2.1.0.debian-linux-x64/usr/share/common-lisp/source/cl-asdf/build/asdf-tmpGHU3ALSV.fasl
; compilation finished in 0:00:02.324
;; loading file #P"/usr/share/common-lisp/source/cl-asdf/build/asdf.lisp"
;; loading system "pgcharts"
Fatal SIMPLE-ERROR:
  Compilation failed: Derived type of #:.DEFAULTING-TEMP. is
(VALUES (INTEGER -1 -1) ),
  conflicting with its asserted type
UNSIGNED-BYTE.
See also:
  The SBCL Manual, Node "Handling of Types" in 
/usr/share/common-lisp/source/cl-postgres/cl-postgres/communicate.lisp
make[1]: *** [debian/rules:32: override_dh_auto_build] Error 1
make[1]: Leaving directory '/build/pgcharts-1.0+2017-09-16'


Andreas


pgcharts_1.0+2017-09-16-1.log.gz
Description: application/gzip

Bug#980513: libgnutls30: _gnutls_sort_clist Assertion with openconnect GlobalProtect VPN

[Andreas Metzler]

Control: forwarded -1 https://gitlab.com/gnutls/gnutls/-/merge_requests/1370

On 2021-01-21 Matthew Chandler  wrote:
> I've never used gnutls-cli before, and I'm not at all sure what openconnect
> is doing internally to match that behaviour, but it appears that I can
> reproduce w/ -cli

Hello,

Thank you, I can reproduce and have forwarded upstream.

The problem is triggered by the fact that the server is not configured
correctly. (GnuTLS should still work.) As you can see it sends 7
certificates:

Certificate[0] client certificate
Certificate[1] intermediate cert 1
Certificate[2] intermediate cert 2
Certificate[3] CA certificate (self-signed)
Certificate[4] Certificate[1] again
Certificate[5] Certificate[2] again
Certificate[6] Certificate[3] again

The duplicates (456) should not be sent.

cu Andreas

-- 
`What a good friend you are to him, Dr. Maturin. His other friends are
so grateful to you.'
`I sew his ears on from time to time, sure'