Bug#975944: nmu: libcifpp_1.0.0-1

[Andrius Merkys]

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

Hello,

I want to request binNMU on amd64 for recently accepted new package.

  nmu libcifpp_1.0.0-1 . amd64 . unstable . -m "Rebuild on buildd"

Thanks,
Andrius

Bug#975939: tor: Tor fails to boot when SOCKSPORT set to anything but localhost

[Peter Palfrader]

On Thu, 26 Nov 2020, mike wrote:

> I have a server on the LAN that hosts a few minor Tor hidden services.
> I'd like it to also allow connections from the LAN to allow other
> computers on the LAN to use the SOCKSPORT rather than each one have to
> individually run their own tor proxy. In torrc if I set the following
> the tor daemon fails to bootstrap when I restart the machine.
> /var/log/tor/notices.log is empty upon boot and systemctl status tor
> shows as loaded, but the daemon doesn't allow connections from nyx or
> any other application.

> Changing to SOCKSPORT :9100 results in the same problem. On reboot tor
> fails to load without error, but when restarting tor via systemd tor
> works fine. 

Does it work if you set SocksPort to 0.0.0.0:9100?  What does syslog say
in either case?

-- 
|  .''`.   ** Debian **
  Peter Palfrader   | : :' :  The  universal
 https://www.palfrader.org/ | `. `'  Operating System
|   `-https://www.debian.org/

Bug#957881: tpm2-initramfs-tool: ftbfs with GCC-10

[Sebastien Bacher]

updated patch which renames the library Depends to the current naming

diff -Nru tpm2-initramfs-tool-0.2.1/debian/changelog tpm2-initramfs-tool-0.2.1/debian/changelog
--- tpm2-initramfs-tool-0.2.1/debian/changelog	2019-10-21 08:53:17.0 +0200
+++ tpm2-initramfs-tool-0.2.1/debian/changelog	2020-11-26 20:47:02.0 +0100
@@ -1,3 +1,13 @@
+tpm2-initramfs-tool (0.2.1-5) unstable; urgency=medium
+
+  * debian/control.in:
+- Depends on the new libtss2-esys-3.0.2-0 library naming
+  * debian/patches/git_gcc10_build.patch:
+- cherry pick an upstream patch to fix the build with gcc10
+  (Closes: #957881)
+
+ -- Sebastien Bacher   Thu, 26 Nov 2020 20:47:02 +0100
+
 tpm2-initramfs-tool (0.2.1-4) unstable; urgency=medium
 
   * Bump version for debian source package upload.
diff -Nru tpm2-initramfs-tool-0.2.1/debian/control tpm2-initramfs-tool-0.2.1/debian/control
--- tpm2-initramfs-tool-0.2.1/debian/control	2019-09-04 13:56:35.0 +0200
+++ tpm2-initramfs-tool-0.2.1/debian/control	2020-11-26 20:47:02.0 +0100
@@ -19,7 +19,7 @@
 Architecture: linux-any
 Depends: ${misc:Depends},
  ${shlibs:Depends},
- libtss2-esys0 (>= 2.1.0-4)
+ libtss2-esys-3.0.2-0 (>= 2.1.0-4)
 Description: Tool used in initramfs to seal/unseal FDE key to the TPM
  This package provides the TPM tool used by the initramfs. 
  Its purpose is to generate/seal/unseal the FDE encrypytion key into 
diff -Nru tpm2-initramfs-tool-0.2.1/debian/patches/git_gcc10_build.patch tpm2-initramfs-tool-0.2.1/debian/patches/git_gcc10_build.patch
--- tpm2-initramfs-tool-0.2.1/debian/patches/git_gcc10_build.patch	1970-01-01 01:00:00.0 +0100
+++ tpm2-initramfs-tool-0.2.1/debian/patches/git_gcc10_build.patch	2020-11-26 20:46:38.0 +0100
@@ -0,0 +1,58 @@
+From 263cd96f4597e91ed6d586e5b2dd24f2f44f3452 Mon Sep 17 00:00:00 2001
+From: Tim Chen 
+Date: Mon, 1 Jun 2020 10:54:56 +0800
+Subject: [PATCH] Fix gcc10 errors
+
+---
+ include/tpm2-initramfs-tool.h | 12 
+ src/libtpm2-initramfs-tool.c  |  3 +++
+ 2 files changed, 11 insertions(+), 4 deletions(-)
+
+diff --git a/include/tpm2-initramfs-tool.h b/include/tpm2-initramfs-tool.h
+index d8260f8..46ce4c4 100644
+--- a/include/tpm2-initramfs-tool.h
 b/include/tpm2-initramfs-tool.h
+@@ -131,7 +131,7 @@ extern const char *help;
+ extern const char *optstr;
+ extern const struct option long_options[];
+ 
+-struct {
++typedef struct {
+ enum { CMD_NONE, CMD_SEAL, CMD_UNSEAL } cmd;
+ char *data;
+ uint32_t persistent;
+@@ -139,12 +139,16 @@ struct {
+ int pcrs;
+ char *tcti;
+ int verbose;
+-} opt;
++} TPM2_INITRAMFS_TOOL_OPT;
+ 
+-struct {
++extern TPM2_INITRAMFS_TOOL_OPT opt;
++
++typedef struct {
+ void *dlhandle;
+ TSS2_TCTI_CONTEXT *context;
+-} tcti;
++} TPM2_INITRAMFS_TOOL_TCTI;
++
++extern TPM2_INITRAMFS_TOOL_TCTI tcti;
+ 
+ void tcti_finalize();
+ int tcti_init(char *str, TSS2_TCTI_CONTEXT **context);
+diff --git a/src/libtpm2-initramfs-tool.c b/src/libtpm2-initramfs-tool.c
+index 7d898c1..cbf8de4 100644
+--- a/src/libtpm2-initramfs-tool.c
 b/src/libtpm2-initramfs-tool.c
+@@ -59,6 +59,9 @@ const struct option long_options[] = {
+ { 0, 0, 0, 0 }
+ };
+ 
++TPM2_INITRAMFS_TOOL_OPT opt;
++TPM2_INITRAMFS_TOOL_TCTI tcti;
++
+ /** Function to generate base32 encoding string.
+  *
+  * This function generates the base32 encoding for input data.
+
diff -Nru tpm2-initramfs-tool-0.2.1/debian/patches/series tpm2-initramfs-tool-0.2.1/debian/patches/series
--- tpm2-initramfs-tool-0.2.1/debian/patches/series	1970-01-01 01:00:00.0 +0100
+++ tpm2-initramfs-tool-0.2.1/debian/patches/series	2020-11-26 20:46:51.0 +0100
@@ -0,0 +1 @@
+git_gcc10_build.patch

Bug#975658: This bug is affecting Firefox

[Gabriele Svelto]

We've detected instances of this bug crashing Firefox. The corresponding
bug in our tracker is this one:

https://bugzilla.mozilla.org/show_bug.cgi?id=1679430

Note that the crash doesn't seem to be present in upstream libdrm, it
seems to me that the `hurd-port.diff` patch applied to the Debian
package is introducing it.

 Gabriele Svelto

Bug#975628: Re: Re: Bug#975628: RFS: ukui-system-monitor/1.0.1-1 -- Monitor for UKUI desktop environment

[handsome_feng]

Hi, Adam,


It was my fault and I have uploaded the new versoin 1.0.3 which fix the 
segmentation fault to mentors:
https://mentors.debian.net/package/ukui-system-monitor


Thanks,
handsome_feng












在2020年11月26 18时03分，"Adam Borowski"写道：

On Thu, Nov 26, 2020 at 04:09:07PM +0800, handsome_feng wrote:
> Hi, Adam,
> 
> I have fix the error and upload it to mentors:
> https://mentors.debian.net/package/ukui-system-monitor/

Uh oh, looks like something in the dependencies was needed after all.
My bad for looking only at the diff but not running the actual code.

[~]$ ukui-system-monitor 
QStandardPaths: XDG_RUNTIME_DIR not set, defaulting to '/tmp/runtime-kilobyte'
Read file Failed.
QObject::connect(QGSettings, MonitorTitleWidget): invalid nullptr parameter
Segmentation fault


Meow!
-- 
⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁
⢿⡄⠘⠷⠚⠋⠀ * ***
⠈⠳⣄

Bug#824954: IRT: [bug #52939] [PATCH] 10_linux: support loading device trees

[Heinrich Schuchardt]

Am 27. November 2020 04:18:06 MEZ schrieb Elliott Mitchell 
:
>The patch to have GRUB load a device-tree is interesting.  This is
>certainly worthy of discussion.
>
>Three issues come up when looking though:
>
>First, your patch modifies /etc/grub.d/10_linux, but misses
>/etc/grub.d/10_linux_xen.  /etc/grub.d/10_linux_xen needs a fairly
>similar treatment.
>
>Second, rather than having this get buried inside Debian bug #824954,
>you
>should instead file a new bug against grub-common.
>
>Third, there may be a need for extra guarding to ensure these sections
>*only* get invoked on ARM devices (I'm fairly sure the *exact* *same*
>file is shipped for all architectures).

RISC-V uses device-trees too.
Some ARM devices use ACPI instead of device-trees.

The main issue is that fix-ups are not applied by U-Boot when GRUB loads the 
device-tree. A UEFI protocol for device tree fix ups would be needed. This 
issue has been discussed in this years Device Tree Evolution project 
(https://www.linaro.org/engineering/core/devicetree-evolution/).

Best regards

Heinrich

Bug#975943: raspi-firmware: arm_64bit is missing and linux-image-arm64 unbootable

[Ryutaroh Matsumoto]

Package: raspi-firmware
Version: 1.20201022-1
Severity: grave
Justification: renders package unusable

Dear Maintainer,

The version 1.20201022-1 does not include "arm_64bit=1" on
arm64 architecture, which makes my Raspi runnning linux-image-arm64
unbootable...
Of course, adding "arm_64bit=1" by another computer
fixes the problem.

I did not have this symptom with older version.
So I believe that this is a regression.

Best regards, Ryutaroh Matsumoto


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

Kernel: Linux 5.9.0-3-arm64 (SMP w/4 CPU threads)
Kernel taint flags: TAINT_CRAP
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)

Versions of packages raspi-firmware depends on:
ii  dosfstools  4.1-2
ii  dpkg1.20.5

raspi-firmware recommends no packages.

raspi-firmware suggests no packages.

-- no debconf information

Bug#975928: libreoffice: Please reimport the scale option in the view settings

[Rene Engelhard]

tag 975928 + upstream

forwarded 975928
https://bugs.documentfoundation.org/show_bug.cgi?id=101646


thanks


Hi,

Am 26.11.20 um 20:18 schrieb Hans-J. Ullrich:
> as there are now screens with high resolutions, the font of the menus are 
> very tiny now. Especially for older people Libreoffice is hardly to use, due 
> to the tiny font in the menu bar on top.
You can't use accessibility tools of yor desktop? Either increase the
font size globally or use "magnifier" or so?
> In former versions of Libreoffice there was a scale setting option in Extras 
> -> Options -> Libreoffice -> View, but today this usefull feature is gone.
>
> It would be nice and very, very helpfull, if you could set this back again.

Me? Not.

Upstream? Yes, maybe.


Doesn't look like it will happen soonish, though, see

https://bugs.documentfoundation.org/show_bug.cgi?id=101646



Regards,


Rene

Bug#954403: joblib: configuration error installing python3-joblib

[Graham Inggs]

As can be seen in the autopkgtests of circlator [1] and spades [2],
this started happening again with the upload of python3-defaults
3.9.0-3, which switched the default Python version from 3.8 to 3.9.

It can also be seen that the autopkgtests of both circlator and spades
previously started passing again on 2020-04-08, as soon as
python3-defaults 3.8.2-3 was uploaded, removing Python 3.7 as a
supported version.


[1] https://ci.debian.net/packages/c/circlator/testing/amd64/
[2] https://ci.debian.net/packages/s/spades/testing/amd64/

Bug#975941: add exception case to package-contains-documentation-outside-usr-share-doc if docs are linked to /usr/share/doc?

[Nicholas D Steeves]

Package: lintian
Version: 2.102.0~bpo10+1
Severity: normal

Hi,

The case is software that provides, for example, html docs, and that
opens these docs using the standard F1 (file bar help) interface.
Such docs should of course also be present in /usr/share/doc.  As I
see it, the question is whether the files should actually exist in
their upstream location--which in Debian translates to
/usr/share/foo/bar and have these docs linked to /usr/share/doc, or
whether they should be moved to /usr/share/doc and be linked back to
where the software expects them.  Option three is maintaining a patch
for a Debian-specific location, but I don't think that's the right solution.

So, should Lintian not warn about
package-contains-documentation-outside-usr-share-doc if the package links the 
assets to /usr/share/doc, or should the Lintian information output recommend 
the inverse case (moving the docs to /usr/share/doc and linking them back to 
where the software expects them)?

I leave it to you :-)
Cheers,
Nicholas

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

Kernel: Linux 5.4.74-mainline-soft-realtime (SMP w/4 CPU cores; PREEMPT)
Kernel taint flags: TAINT_UNSIGNED_MODULE
Locale: LANG=en_CA.UTF-8, LC_CTYPE=en_CA.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_CA:en (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages lintian depends on:
ii  binutils2.31.1-16
ii  bzip2   1.0.6-9.2~deb10u1
ii  diffstat1.62-1
ii  dpkg1.19.7
ii  dpkg-dev1.19.7
ii  file1:5.35-4+deb10u1
ii  gettext 0.19.8.1-9
ii  gpg 2.2.20-1~bpo10+1
ii  intltool-debian 0.35.0+20060710.5
ii  libapt-pkg-perl 0.1.34+b1
ii  libarchive-zip-perl 1.64-1
ii  libcapture-tiny-perl0.48-1
ii  libclass-xsaccessor-perl1.19-3+b2
ii  libclone-perl   0.41-1+b1
ii  libconfig-tiny-perl 2.23-1
ii  libcpanel-json-xs-perl  4.09-1
ii  libdata-dpath-perl  0.57-2
ii  libdata-validate-domain-perl0.10-1
ii  libdevel-size-perl  0.82-1+b1
ii  libdpkg-perl1.19.7
ii  libemail-address-xs-perl1.04-1+b1
ii  libfile-basedir-perl0.08-1
ii  libfile-find-rule-perl  0.34-1
ii  libfont-ttf-perl1.06-1
ii  libhtml-html5-entities-perl 0.004-1
ii  libipc-run3-perl0.048-1
ii  libjson-maybexs-perl1.004000-1
ii  liblist-compare-perl0.53-1
ii  liblist-moreutils-perl  0.416-1+b4
ii  liblist-utilsby-perl0.11-1
ii  libmoo-perl 2.003004-2
ii  libmoox-aliases-perl0.001006-1
ii  libnamespace-clean-perl 0.27-1
ii  libpath-tiny-perl   0.108-1
ii  libperlio-gzip-perl 0.19-1+b5
ii  libproc-processtable-perl   0.56-1
ii  libsereal-decoder-perl  4.005+ds-1+b1
ii  libsereal-encoder-perl  4.005+ds-1+b1
ii  libtext-glob-perl   0.10-1
ii  libtext-levenshteinxs-perl  0.03-4+b6
ii  libtext-markdown-discount-perl  0.11-3+b1
ii  libtext-xslate-perl 3.5.6-1+b1
ii  libtime-duration-perl   1.20-1
ii  libtime-moment-perl 0.44-1+b1
ii  libtimedate-perl2.3000-2+deb10u1
ii  libtry-tiny-perl0.30-1
ii  libtype-tiny-perl   1.004004-1
ii  libunicode-utf8-perl0.62-1
ii  liburi-perl 1.76-1
ii  libxml-libxml-perl  2.0134+dfsg-1
ii  libyaml-libyaml-perl0.76+repack-1
ii  lzip1.21-3
ii  lzop1.03-4+b1
ii  man-db  2.8.5-2
ii  patchutils  0.3.4-2
ii  perl [libdigest-sha-perl]   5.28.1-6+deb10u1
ii  t1utils 1.41-3
ii  unzip   6.0-23+deb10u1
ii  xz-utils5.2.4-1

lintian recommends no packages.

Versions of packages lintian suggests:
pn  binutils-multiarch 
ii  libtext-template-perl  1.55-1

-- no debconf information

Bug#975942: RM: node-cross-spawn -- ROM; unneeded for Debian, does risky path mangling

[Xavier Guimard]

Package: ftp.debian.org
Severity: normal

Hi,

following #958403, node-cross-spawn does risky path mangling and should
be rremoved from Debian.

Cheers,
Xavier

Bug#960901: Buffer is a built-in node function

[Ben Finney]

Howdy Pirate,

On 18-May-2020, Pirate Praveen wrote:

> For this particular case you can try embedding buffer module version
> 4.x as browsers need an equivalent module to features present only
> in node.

This looks like advice for me to work around the problem. What do I
need to do? How do I (as a user of the Debian package of Webpack)
“embed buffer module version 4.x”?

In other words, how does this advice help the user of Webpack to build
a code base that references the ‘buffer’ built-in function?

-- 
 \   “I disapprove of what you say, but I will defend to the death |
  `\ your right to say it.” —Evelyn Beatrice Hall, _The Friends of |
_o__)  Voltaire_, 1906 |
Ben Finney 


signature.asc
Description: PGP signature

Bug#975940: debian-reference-en: Outdated information on virtual consoles (Section 1.1.6)

[Vishal Subramanyam]

Package: debian-reference-en
Version: 2.76
Severity: normal
X-Debbugs-Cc: vishalsubraman...@outlook.com

Dear Maintainer,
The X-Window System runs on virtual consoles 1 and 2, not 7 anymore.
The second paragraph under this section seems to indicate that pressing
Ctrl-Alt-F1 will bring up a character console and that Ctrl-Alt-F7 will
bring up the X Window System. This is not true.

Vishal


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

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

Versions of packages debian-reference-en depends on:
pn  debian-reference-common  

debian-reference-en recommends no packages.

Versions of packages debian-reference-en suggests:
pn  doc-base  

Bug#824954: IRT: [bug #52939] [PATCH] 10_linux: support loading device trees

[Elliott Mitchell]

The patch to have GRUB load a device-tree is interesting.  This is
certainly worthy of discussion.

Three issues come up when looking though:

First, your patch modifies /etc/grub.d/10_linux, but misses
/etc/grub.d/10_linux_xen.  /etc/grub.d/10_linux_xen needs a fairly
similar treatment.

Second, rather than having this get buried inside Debian bug #824954, you
should instead file a new bug against grub-common.

Third, there may be a need for extra guarding to ensure these sections
*only* get invoked on ARM devices (I'm fairly sure the *exact* *same*
file is shipped for all architectures).


-- 
(\___(\___(\__  --=> 8-) EHM <=--  __/)___/)___/)
 \BS (| ehem+sig...@m5p.com  PGP 87145445 |)   /
  \_CS\   |  _  -O #include  O-   _  |   /  _/
8A19\___\_|_/58D2 7E3D DDF4 7BA6 <-PGP-> 41D1 B375 37D0 8714\_|_/___/5445

Bug#975894: Breaks build of many reverse dependencies

[Ralf Treinen]

Hi,

On Thu, Nov 26, 2020 at 12:03:41PM +0100, Stéphane Glondu wrote:
> Package: ocaml-dune
> Version: 2.7.1-1
> Severity: serious
> 
> Dear maintainer,
> 
> It seems the latest ocaml-dune breaks many reverse dependencies, see
> for example #975821 (ocp-indent).

The strange thing is that ocp-indent builds fine on my development
environment updated to the latest sid, but I can reproduce the bug
in a pbuilder chroot. When I rename in my development environment
/usr/bin/ocamlfind to something else, then I also get the build
error. So maybe the latest dune requires a dependency on the
ocaml-findlib package ? A quick grep in the dune source code shows
that dune does stuff differently depending on whether you have ocamlfind
installed or not.

-Ralf.

Bug#973287: systemd autopkgtest-virt-lxc failure on arm64

[Ryutaroh Matsumoto]

>> > We probably need to cherry-pick two changes
> I released 246.6-5 with those changes the other day.

I run autopkgtest 246.6-5 on amd64 and arm64 VM.
"upstream" sometimes succeeds and sometimes fails, so I assume it
is OK.

"storage" consistently fails on arm64 VM. The reason is simple as below:
modprobe: FATAL: Module scsi_debug not found in directory 
/lib/modules/5.9.0-3-arm64

linux-image-arm64 does not have scsi_debug kernel module.
I have no idea which package is responsible for autopkgtest error of "storage".

By the way, systemd autopkgtest-virt-qemu works fine if packages with
"Priority: important" are included in VM.
But packages "Priority: required" is only included, the systemd test script 
fails.
Is it considered as a bug??

Coverage of packages in VM can be adjusted by
https://github.com/emojifreak/qemu-arm-image-builder/blob/main/build-gpt-autopkgtest-qemu-debian.sh

Best regards, Ryutaroh

Bug#963962: /etc/grub.d/20_linux_xen generates non-functional menu entries

[Elliott Mitchell]

found 963962 2.02+dfsg1-20+deb10u2 2.04-10
quit

I was going to report I'd never observed this bug, but then I examined
the grub.cfg files and I discover they're present.  I would tend to rate
this as minor, but the original submitter didn't adjust severity.

With 2.04-10 the xen-4.*.config file entries are absent, but entries
for both the .efi file and the other are produced.  On an aarch64 system
the .efi file can be booted by GRUB 2.04.


-- 
(\___(\___(\__  --=> 8-) EHM <=--  __/)___/)___/)
 \BS (| ehem+sig...@m5p.com  PGP 87145445 |)   /
  \_CS\   |  _  -O #include  O-   _  |   /  _/
8A19\___\_|_/58D2 7E3D DDF4 7BA6 <-PGP-> 41D1 B375 37D0 8714\_|_/___/5445

Bug#975882: samba-common-bin: smb.conf testparm: Weak crypto is allowed

[Paul Wise]

Control: forwarded -1 https://bugzilla.samba.org/show_bug.cgi?id=14583

On Fri, 2020-11-27 at 14:34 +1300, Andrew Bartlett wrote:

> You need to raise it with your concerns.

Done in the above bug report.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


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

Bug#975939: tor: Tor fails to boot when SOCKSPORT set to anything but localhost

[mike]

Package: tor
Version: 0.3.5.10-1
Severity: important

Dear Maintainer,

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

   * What led up to the situation?

0


I have a server on the LAN that hosts a few minor Tor hidden services. I'd like 
it to also allow connections from the LAN to allow other computers on the LAN 
to use the SOCKSPORT rather than each one have to individually run their own 
tor proxy. In torrc if I set the following the tor daemon fails to bootstrap 
when I restart the machine. /var/log/tor/notices.log is empty upon boot and 
systemctl status tor shows as loaded, but the daemon doesn't allow connections 
from nyx or any other application.
Changing to SOCKSPORT :9100 results in the same problem. On reboot tor fails to 
load without error, but when restarting tor via systemd tor works fine. 
   * What exactly did you do (or not do) that was effective (or
 ineffective)? Commenting out the SOCKSPORT ip.of.my.server:9050 resolves 
the issue.
*** End of the template - remove these template lines ***


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

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

Versions of packages tor depends on:
ii  adduser 3.118
ii  libc6   2.28-10
ii  libcap2 1:2.25-2
ii  libevent-2.1-6  2.1.8-stable-4
ii  liblzma55.2.4-1
ii  libseccomp2 2.3.3-4
ii  libssl1.1   1.1.1g-1+0~20200421.17+debian10~1.gbpf6902f
ii  libsystemd0 241-7~deb10u4
ii  libzstd11.3.8+dfsg-3
ii  lsb-base10.2019051400
ii  zlib1g  1:1.2.11.dfsg-1

Versions of packages tor recommends:
ii  logrotate3.14.0-4
ii  tor-geoipdb  0.3.5.10-1
ii  torsocks 2.3.0-2

Versions of packages tor suggests:
pn  apparmor-utils   
pn  mixmaster
pn  obfs4proxy   
pn  socat
ii  tor-arm  2.1.0-2
pn  torbrowser-launcher  

-- Configuration Files:
/etc/tor/torrc changed [not included]

-- no debconf information

Bug#971616: sh: pager: command not found

[Guillem Jover]

Control: merge 856216 -1
Control: retitle 856216 dpkg: Should fallback to use more(1) or less(1) if 
pager(1) is not present
Control: user d...@packages.debian.org
Control: usertag 856216 - dpkg-query
Control: usertag 856216 + dpkg

Hi!

On Sat, 2020-10-03 at 09:02:43 +0200, Harald Dunkel wrote:
> Package: dpkg
> Version: 1.19.7

> I am pretty sure this is not supposed to happen:
> 
> # aptitude upgrade
> :
> Setting up smartmontools (7.1-1~bpo10+1) ...
> Installing new version of config file /etc/default/smartmontools ...
> Installing new version of config file /etc/init.d/smartmontools ...
> 
> Configuration file '/etc/smartd.conf'
>  ==> Modified (by you or by a script) since installation.
>  ==> Package distributor has shipped an updated version.
>What would you like to do about it ?  Your options are:
> Y or I  : install the package maintainer's version
> N or O  : keep your currently-installed version
>   D : show the differences between the versions
>   Z : start a shell to examine the situation
>  The default action is to keep your current version.
> *** smartd.conf (Y/I/N/O/D/Z) [default=N] ? d
> sh: pager: command not found
> dpkg: error processing package smartmontools (--configure):
>  conffile difference visualizer subprocess returned error exit status 127
> :

This seems like a variant of an already reported bug. Merging.

Thanks,
Guillem

Bug#975882: samba-common-bin: smb.conf testparm: Weak crypto is allowed

[Andrew Bartlett]

On Fri, 2020-11-27 at 07:59 +0800, Paul Wise wrote:
> On Fri, 2020-11-27 at 06:45 +1300, Andrew Bartlett wrote:
> 
> > What should come of this bug is that the testparm output and
> > associated
> > documentation needs to be much more verbose as to what this means,
> > and
> > what the alternative would mean for a interoperable installation. 
> > 
> > (And that needs to be an upstream bug and discussion really).
> 
> Do you intend to file/start that bug/discussion or should I?
> 
> (I don't feel qualified to participate, but could start/read it)

You need to raise it with your concerns.

Andrew Bartlett

-- 
Andrew Bartlett (he/him)   https://samba.org/~abartlet/
Samba Team Member (since 2001) https://samba.org
Samba Team Lead, Catalyst IT   https://catalyst.net.nz/services/samba

Bug#973395: clang-10: Unable to package LLVM/Clang on Buster (for backports) - libffi error

[Alexander Motzkau]

I hit the same bug when building for i386 (inside an i386 docker container)
on an amd64 system. Even though it's running inside an i386 environment,
the build system detects the host architecture and suddenly starts compiling
for that, where it doesn't find the corresponding libffi.

My solution was simple: Execute the build command with the linux32 wrapper.

Regards,
Alex

Bug#944247: [Pkg-xen-devel] Bug#944247: xen domU crashes under high i/o load if you use qcow2 images

[Diederik de Haas]

On woensdag 6 november 2019 16:46:05 CET mario wrote:
> does anyone else have problems with qcow2 images and xen under buster?

I don't know if it's the same/similar cause, but "... blocked for more than 
120 seconds." sounds familiar and caused me to get rid of my mdadm RAID1 
system and just use a single disk. I used LVM on top of that. I still use LVM, 
but no longer on top of software RAID.

I don't have any experience with qcow2 images though.
I'm not even sure whether my 'fix' fixed the problem (properly/entirely).

Only thing I am sure of is that your symptoms sound familiar.

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

Bug#975687: xterm: loses text lines, even descenders from some lines

[Thomas Dickey]

On Fri, Nov 27, 2020 at 12:04:07AM +, Thorsten Glaser wrote:
> Hi Thomas,
> 
> >If you're going to compile it, the debug-trace can be useful
> >(--enable-trace).  If not, the -report-fonts option is helpful.
> 
> I hadn’t recompiled, at least not with actual changes.
> The -report-fonts output is attached, fNorm is the one
> in question.
> 
> I did a little bisecting: Debian’s 360-1 did not have
> the bug, 361-1 did, and when recompiling 360-1 unchanged
> in a current unstable chroot, it also doesn’t have the
> bug, so it’s not something else that changed.

sounds promising - 
 
> Looking at debian/patches/ in 361-1 it also doesn’t change
> any of the code, so I guess it’s some upstream change.
> 
> >If I can reproduce it, I'll see what I can do.
> 
> If not but you still have patches I could test, send them
> and I’ll apply them and rebuild locally. If you need the
> trace, I’ll also do that, but not tonight…

fwiw

https://invisible-island.net/personal/git-exports.html
https://github.com/ThomasDickey/xterm-snapshots


> 
> bye,
> //mirabilos
> -- 
> 21:12⎜ sogar bei opensolaris haben die von der community so
> ziemlich jeden mist eingebaut │ man sollte unices nich so machen das
> desktopuser zuviel intresse kriegen │ das macht die code base kaputt
> 21:13⎜ linux war früher auch mal besser :D

> Script started on 2020-11-27 00:46:29+01:00 [TERM="screen" TTY="/dev/pts/15" 
> COLUMNS="113" LINES="34"]
> tglase@tglase-nb:~ $ /usr/bin/xterm +sb -fg black -geom 90x11+475+637 
> -report-fonts -bg cornflowerblue -e tail 
+sb -fg black -geom 90x11+475+637 -report-fonts -bg cornflowerblue -e tail  
   <-F 
/var/log/syslog
> Loaded VTFonts(default)
>   fNorm: -misc-fixed-medium-r-semicondensed--13-120-75-75-c-60-iso10646-1
>   all chars: no
>   default char:  0
>   direction: 0
>   ascent:11
>   descent:   2
>   first char:0
>   last char: 65535
>   maximum-chars: 65536
>   missing-chars: 61413
>   present-chars: 4123
>   min_byte1: 0
>   max_byte1: 255
>   properties:22
>   min_bounds:
>   lbearing: 0
>   rbearing: 0
>   width:6
>   ascent:   -1
>   descent:  -10
>   max_bounds:
>   lbearing: 5
>   rbearing: 6
>   width:6
>   ascent:   11
>   descent:  2
>   fBold: -misc-fixed-medium-r-semicondensed--13-120-75-75-c-60-iso10646-1
>   all chars: no
>   default char:  0
>   direction: 0
>   ascent:11
>   descent:   2
>   first char:0
>   last char: 65535
>   maximum-chars: 65536
>   missing-chars: 61413
>   present-chars: 4123
>   min_byte1: 0
>   max_byte1: 255
>   properties:22
>   min_bounds:
>   lbearing: 0
>   rbearing: 0
>   width:6
>   ascent:   -1
>   descent:  -10
>   max_bounds:
>   lbearing: 5
>   rbearing: 6
>   width:6
>   ascent:   11
>   descent:  2
>   fWide: -misc-fixed-medium-r-normal-ja-13-120-75-75-c-120-iso10646-1
>   all chars: no
>   default char:  0
>   direction: 0
>   ascent:11
>   descent:   2
>   first char:0
>   last char: 65535
>   maximum-chars: 65536
>   missing-chars: 46328
>   present-chars: 19208
>   min_byte1: 0
>   max_byte1: 255
>   properties:23
>   min_bounds:
>   lbearing: 0
>   rbearing: 0
>   width:12
>   ascent:   -1
>   descent:  -10
>   max_bounds:
>   lbearing: 11
>   rbearing: 12
>   width:12
>   ascent:   11
>   descent:  2
>   fWBold: -misc-fixed-medium-r-normal-ja-13-120-75-75-c-120-iso10646-1
>   all chars: no
>   default char:  0
>   direction: 0
>   ascent:11
>   descent:   2
>   first char:0
>   last char: 65535
>   maximum-chars: 65536
>   missing-chars: 46328
>   

Bug#975687: xterm: loses text lines, even descenders from some lines

[Thorsten Glaser]

Hi Thomas,

>If you're going to compile it, the debug-trace can be useful
>(--enable-trace).  If not, the -report-fonts option is helpful.

I hadn’t recompiled, at least not with actual changes.
The -report-fonts output is attached, fNorm is the one
in question.

I did a little bisecting: Debian’s 360-1 did not have
the bug, 361-1 did, and when recompiling 360-1 unchanged
in a current unstable chroot, it also doesn’t have the
bug, so it’s not something else that changed.

Looking at debian/patches/ in 361-1 it also doesn’t change
any of the code, so I guess it’s some upstream change.

>If I can reproduce it, I'll see what I can do.

If not but you still have patches I could test, send them
and I’ll apply them and rebuild locally. If you need the
trace, I’ll also do that, but not tonight…

bye,
//mirabilos
-- 
21:12⎜ sogar bei opensolaris haben die von der community so
ziemlich jeden mist eingebaut │ man sollte unices nich so machen das
desktopuser zuviel intresse kriegen │ das macht die code base kaputt
21:13⎜ linux war früher auch mal besser :DScript started on 2020-11-27 00:46:29+01:00 [TERM="screen" TTY="/dev/pts/15" 
COLUMNS="113" LINES="34"]
tglase@tglase-nb:~ $ /usr/bin/xterm +sb -fg black -geom 90x11+475+637 
-report-fonts -bg cornflowerblue -e tail 
+sb -fg black -geom 90x11+475+637 -report-fonts -bg cornflowerblue -e tail  
   <-F 
/var/log/syslog


Loaded VTFonts(default)

fNorm: -misc-fixed-medium-r-semicondensed--13-120-75-75-c-60-iso10646-1

all chars: no

default char:  0

direction: 0

ascent:11

descent:   2

first char:0

last char: 65535

maximum-chars: 65536

missing-chars: 61413

present-chars: 4123

min_byte1: 0

max_byte1: 255

properties:22

min_bounds:

lbearing: 0

rbearing: 0

width:6

ascent:   -1

descent:  -10

max_bounds:

lbearing: 5

rbearing: 6

width:6

ascent:   11

descent:  2

fBold: -misc-fixed-medium-r-semicondensed--13-120-75-75-c-60-iso10646-1

all chars: no

default char:  0

direction: 0

ascent:11

descent:   2

first char:0

last char: 65535

maximum-chars: 65536

missing-chars: 61413

present-chars: 4123

min_byte1: 0

max_byte1: 255

properties:22

min_bounds:

lbearing: 0

rbearing: 0

width:6

ascent:   -1

descent:  -10

max_bounds:

lbearing: 5

rbearing: 6

width:6

ascent:   11

descent:  2

fWide: -misc-fixed-medium-r-normal-ja-13-120-75-75-c-120-iso10646-1

all chars: no

default char:  0

direction: 0

ascent:11

descent:   2

first char:0

last char: 65535

maximum-chars: 65536

missing-chars: 46328

present-chars: 19208

min_byte1: 0

max_byte1: 255

properties:23

min_bounds:

lbearing: 0

rbearing: 0

width:12

ascent:   -1

descent:  -10

max_bounds:

lbearing: 11

rbearing: 12

width:12

ascent:   11

descent:  2

fWBold: -misc-fixed-medium-r-normal-ja-13-120-75-75-c-120-iso10646-1

all chars: no

default char:  0

direction: 0

ascent:11

descent:   2

first char:0

last char: 65535

maximum-chars: 65536

missing-chars: 46328

present-chars: 19208

min_byte1: 0

max_byte1: 255

properties:23

min_bounds:

Bug#974073: gcc-10: arm64 internal compiler error: canonical types differ for identical types

[Wookey]

I got some input from compiler gurus.

It seems that the corresponding upstream bug is:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52830
(And this may be the same issue:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91590 )

Alex Coplan has added a reduced testcase to 52380 derived from the
polymake codebase, which ICEs all the way back to GCC 6, so this has
been around for a while.

(Thanks for investigating, Alex)

Wookey
-- 
Principal hats:  Linaro, Debian, Wookware, ARM
http://wookware.org/


signature.asc
Description: PGP signature

Bug#975882: samba-common-bin: smb.conf testparm: Weak crypto is allowed

[Paul Wise]

On Fri, 2020-11-27 at 06:45 +1300, Andrew Bartlett wrote:

> What should come of this bug is that the testparm output and associated
> documentation needs to be much more verbose as to what this means, and
> what the alternative would mean for a interoperable installation. 
> 
> (And that needs to be an upstream bug and discussion really).

Do you intend to file/start that bug/discussion or should I?

(I don't feel qualified to participate, but could start/read it)

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


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

Bug#975687: xterm: loses text lines, even descenders from some lines

[Thomas Dickey]

On Thu, Nov 26, 2020 at 10:52:38PM +, Thorsten Glaser wrote:
> Thomas Dickey dixit:
> 
> >"Recently" could be something overlooked in #362's change
> 
> No, 362 is the current one, and I definitely had this in
> the previous version shipped in Debian as well, but I can’t
> narrow it down further than that. According to apt history
> log, that was 361.

I see - nothing comes to mind other than recalling some comment that
fontconfig wouldn't actually provide bitmap fonts.
 
> >On the other hand (if it's not specific to #362), a lot of the
> >font/display problems aren't xterm (and if the problem doesn't show up
> >on macOS, I wouldn't notice it right away).
> 
> Hmmh. It’s a regular X11 BDF/PCF font, so at least the
> ugly fontconfig/freetype/… combination doesn’t affect
> this, but as such you indeed won’t be able to see this
> on a Macintosh.
> 
> Since I can _somewhat_ reproduce this (three “sudo true”
> in quick succession did it right now), I could try to
> bisect releases until I find one, if that helps?

If you're going to compile it, the debug-trace can be useful
(--enable-trace).  If not, the -report-fonts option is helpful.

At the moment I'm closing out a set of changes for dialog,
intending to work on xterm for a week or so.  If I can
reproduce it, I'll see what I can do.

-- 
Thomas E. Dickey 
https://invisible-island.net
ftp://ftp.invisible-island.net


signature.asc
Description: PGP signature

Bug#975937: ITP: puppet-module-voxpupuli-zabbix -- Puppet module for zabbix

[Thomas Goirand]

Package: wnpp
Severity: wishlist
Owner: Thomas Goirand 

* Package name: puppet-module-voxpupuli-zabbix
  Version : 8.0.0
  Upstream Author : Vox Pupuli
* URL : https://github.com/voxpupuli/puppet-zabbix/
* License : Apache-2.0
  Programming Lang: Puppet
  Description : Puppet module for zabbix

 Puppet lets you centrally manage every important aspect of your system using a
 cross-platform specification language that manages all the separate elements
 normally aggregated in different files, like users, cron jobs, and hosts,
 along with obviously discrete elements like packages, services, and files.
 .
 puppet-zabbix installs and configure Zabbix.

Note: I'm going to use this to integrate the monitoring in OCI.

Bug#975938: ITP: jboss-vfs -- JBoss Virtual File System

[Bdale Garbee]

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

* Package name: jboss-vfs
  Version : 3.2.15.Final
  Upstream Author : JBoss, A division of Red Hat, Inc.
* url : http://www.jboss.org
* License : Apache-2.0
  Programming Lang: Java
  Description : JBoss Virtual File System

This package delivers the JBoss VFS libraries.  A much earlier version was
once included in Debian but dropped due to lack of use.  I'm re-packaging a
modern version with help from Sudip Mukherjee because it's a dependency for
annotation-detector, which is a dependency for openrocket, which I'm trying
to get back into main instead of being a jar-installer package in contrib.

Bug#951077: closed by Thomas Goirand (Fixed in 1.28.0 ?)

[Thomas Goirand]

On 11/26/20 8:11 PM, Guillem Jover wrote:
> Personally I'd rather have valid bugs kept open on the BTS, if not
> just for coordination with other affected people. I'm fine waiting,
> even years.

Good for you, but that's not at all my policy. Having a bug opened for
years about a manpage nit-picking, isn't helping me at all, and I don't
think it helps our users either.

For me, my QA page a a TODO list. A bug must either be addressed, or
closed, and I don't think there's room for a middle-ground. If I don't
do this, bugs accumulate.

When I look at your QA page, I see 22 packages. Mine got 655 (yes,
that's too many... help welcome!), and the BTS shows about the same
amount of open bugs. This means that if I want to be able to act on
things, I must keep the list of bugs manageable.

> If then you happen to have the time (or someone else does, like Mika
> did here), then the bug can be forwarded, marked as such, and dealt
> with either in Debian or upstream, etc. People affected or wanting
> or able to help can even provide patches, etc.

If someone gave me a patch, I would have apply it, which would mark the
bug as pending, meaning it wouldn't be on my way to see other important
things I must work on.

Cheers,

Thomas Goirand (zigo)

Bug#975723: apt-listbugs: [INTL:ru] Russian translation update

[Francesco Poli]

On Wed, 25 Nov 2020 17:35:56 +0300 Алексей Шилин wrote:

> Hi,
> 
> Updated Russian translation for apt-listbugs is attached.

Hello Алексей,
thanks a lot for your contribution!

I have a question.
Please note that, although I studied a little bit of Russian in the
past, my knowledge has never been too detailed and my memories are
definitely rusty now... Hence I may well be completely off-track.


#. TRANSLATORS: %{blist} is a comma-separated list of %{nbugs} bugs to be 
dodged.
#: ../lib/aptlistbugs/logic.rb:614
msgid ""
"The following %{nbugs} bug will be dodged:\n"
" %{blist}\n"
"Are you sure?"
msgid_plural ""
"The following %{nbugs} bugs will be dodged:\n"
" %{blist}\n"
"Are you sure?"
msgstr[0] ""
"Следующей %{nbugs} ошибки удастся избежать:\n"
" %{blist}\n"
"Вы уверены?"
msgstr[1] ""
"Следующих %{nbugs} ошибок удастся избежать:\n"
" %{blist}\n"
"Вы уверены?"
msgstr[2] ""
"Следующих %{nbugs} ошибок удастся избежать:\n"
" %{blist}\n"
"Вы уверены?"


Curious that the two plural forms are identical in this case. Is this
OK?



-- 
 http://www.inventati.org/frx/
 There's not a second to spare! To the laboratory!
. Francesco Poli .
 GnuPG key fpr == CA01 1147 9CD2 EFDF FB82  3925 3E1C 27E1 1F69 BFFE


pgplMBEz8jpWZ.pgp
Description: PGP signature

Bug#975687: xterm: loses text lines, even descenders from some lines

[Thorsten Glaser]

Thomas Dickey dixit:

>"Recently" could be something overlooked in #362's change

No, 362 is the current one, and I definitely had this in
the previous version shipped in Debian as well, but I can’t
narrow it down further than that. According to apt history
log, that was 361.

>On the other hand (if it's not specific to #362), a lot of the
>font/display problems aren't xterm (and if the problem doesn't show up
>on macOS, I wouldn't notice it right away).

Hmmh. It’s a regular X11 BDF/PCF font, so at least the
ugly fontconfig/freetype/… combination doesn’t affect
this, but as such you indeed won’t be able to see this
on a Macintosh.

Since I can _somewhat_ reproduce this (three “sudo true”
in quick succession did it right now), I could try to
bisect releases until I find one, if that helps?

bye,
//mirabilos
-- 
15:39⎜«mika:#grml» mira|AO: "mit XFree86® wär’ das nicht passiert" - muhaha
15:48⎜ also warum machen die xorg Jungs eigentlich alles
kaputt? :)15:49⎜ thkoehler: weil sie als Kinder nie den
gebauten Turm selber umschmeissen durften?  -- ~/.Xmodmap wonders…

Bug#824954: flash-kernel: GRUB? via U-Boot?

[Elliott Mitchell]

For a Raspberry PI, I've got the initial workings of a script to
accomplish this goal.

First, install u-boot-rpi, raspi-firmware, and grub-efi-arm64.

Next, create a filesystem on a device the Raspberry PI will boot from.
For anything pre-RP4, this will have to VFAT and show up in a MBR.  A
system I've done has a GPT with entry #3, which matches with entry #1 in
MBR.  The Raspberry PI will find this and boot from it, Linux will see it
as /dev/sda3.  Mount this filesystem on /boot/efi.


Do the following:

cp /usr/lib/raspi-firmware/* /boot/efi
# cp /usr/share/doc/raspi-firmware/copyright /boot/efi/LICENSE.broadcom

cp /usr/lib/u-boot/rpi_arm64/u-boot.bin /boot/efi/u-boot64.bin

cp /usr/lib/u-boot/rpi_3/u-boot.bin /boot/efi/u-boot3.bin
cp /usr/lib/u-boot/rpi_4/u-boot.bin /boot/efi/u-boot4.bin

cp /boot/dtbs/`uname -r`/broadcom/bcm2*-rpi*.dtb /boot/efi

grub-install --bootloader-id=BOOT
cp /boot/efi/EFI/BOOT/grubaa64.efi /boot/efi/EFI/BOOT/bootaa64.efi

echo bootaa64 > /boot/efi/startup.nsh


Now, I'm using SuSE as a starting point.  They copy a series of
device-tree overlays into /boot/efi/overlays.  These may come from the
Raspberry PI Foundation for optional hardware/configuration the RPF
provides.

Next would be to to create /boot/efi/config.txt.  I'm unsure of which
directives would be appropriate for Debian.  Debian would certainly need
to configure distinct "kernel=" lines depending upon which variant was
being booted.

This is rather badly damaged by bug #939633.  Until the device-trees are
fixed, this is completely broken.

Not ready for most people, but almost there...


-- 
(\___(\___(\__  --=> 8-) EHM <=--  __/)___/)___/)
 \BS (| ehem+sig...@m5p.com  PGP 87145445 |)   /
  \_CS\   |  _  -O #include  O-   _  |   /  _/
8A19\___\_|_/58D2 7E3D DDF4 7BA6 <-PGP-> 41D1 B375 37D0 8714\_|_/___/5445

Bug#957310: Proposal to add extern qualifier on problematic lines

[Pierre Gruet]

Hi,

May I suggest to apply the enclosed patch, adding the "extern" qualifier 
in front of the declarations of drmaa2_list_s and drmaa2_dict_s.


gcc-10 now uses, by default, the option -fno-common, which raises a 
"multiple definitions" error when there are two definitions of the same 
variable in two different units.



With this patch, all the build step then goes fine, but there are issues 
in the override of dh_auto_install that have nothing to do with the 
above C++ problem. I hope you can understand them better than me... It 
seems a jar source/clients/gui-installer/dist/installer.jar is expected 
but absent...



All the best,
Pierre Gruet
--- a/source/libs/japi/drmaa2_list_dict.h
+++ b/source/libs/japi/drmaa2_list_dict.h
@@ -10,7 +10,7 @@
struct _drmaa2_node *next;
 } _drmaa2_Node;
 
-/* static */ struct drmaa2_list_s
+/* static */ extern struct drmaa2_list_s
 {
_drmaa2_Node   *head;
_drmaa2_Node   *tail;
@@ -33,7 +33,7 @@
   struct _drmaa2_dictentry_t* next;
 } _drmaa2_dictentry_t;
 
-/* static */ struct drmaa2_dict_s
+/* static */ extern struct drmaa2_dict_s
 {
   _drmaa2_dictentry_t*head;
   _drmaa2_dictentry_t*tail;

Bug#972679: chrony 4.0 in backports

[Vincent Blut]

On 2020-11-26T22:55+0100, Kurt Roeckx wrote:

On Fri, Oct 23, 2020 at 10:25:55PM +0200, Vincent Blut wrote:

Hi Kurt,

On 2020-10-22T13:58+0200, Kurt Roeckx wrote:
> Package: chrony
> Severity: wishlist
>
> Hi,
>
> Would it be possible to get chrony 4.0 in buster backports?

I’ll do my best to make this happen. As I made quite a few changes on the
packaging side, I need to check that chrony 4.0 will behaves properly on a
Buster based system.

Also, I have to make sure that GnuTLS in Buster supports TLS 1.3 (IIRC this
is the case); this is a necessity to support the NTS authentication
mechanism.


Any update on this?


I plan to work on it this weekend.


Kurt


Cheers,
Vincent


signature.asc
Description: PGP signature

Bug#975936: nmu: gcc-mingw-w64_24

[Stephen Kitt]

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

Dear release team,

Please schedule a binNMU for gcc-mingw-w64, for
https://release.debian.org/transitions/html/auto-isl.html

nmu gcc-mingw-w64_24 . ANY . unstable . -m "Rebuild for libisl transition."

Regards,

Stephen


-- System Information:
Debian Release: 10.6
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable-debug'), (500, 'stable'), 
(100, 'unstable-debug'), (100, 'testing-debug'), (100, 'unstable'), (100, 
'testing'), (1, 'experimental-debug'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386, arm64

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

Bug#972679: chrony 4.0 in backports

[Kurt Roeckx]

On Fri, Oct 23, 2020 at 10:25:55PM +0200, Vincent Blut wrote:
> Hi Kurt,
> 
> On 2020-10-22T13:58+0200, Kurt Roeckx wrote:
> > Package: chrony
> > Severity: wishlist
> > 
> > Hi,
> > 
> > Would it be possible to get chrony 4.0 in buster backports?
> 
> I’ll do my best to make this happen. As I made quite a few changes on the
> packaging side, I need to check that chrony 4.0 will behaves properly on a
> Buster based system.
> 
> Also, I have to make sure that GnuTLS in Buster supports TLS 1.3 (IIRC this
> is the case); this is a necessity to support the NTS authentication
> mechanism.

Any update on this?


Kurt

Bug#975935: linux-image-5.9.0-1-amd64: HDA Digital PCBeep not registered anymore

[GSR]

Package: src:linux
Version: 5.9.1-1
Severity: normal

Dear Maintainer,

Beep device stopped appearing, and no beep via sound card. It seems to 
start happening with, at least, 5.2 and continues up to now. Last kernel 
I have avaliable and where it worked is 4.17.

---8<---
[0.00] Linux version 4.17.0-1-amd64 (debian-ker...@lists.debian.org) 
(gcc version 7.3.0 (Debian 7.3.0-26)) #1 SMP Debian 4.17.8-1 (2018-07-20)
...
[4.971895] snd_hda_intel :01:00.1: Handle vga_switcheroo audio client
[4.971897] snd_hda_intel :01:00.1: Force to non-snoop mode
[4.983750] r8169 :02:00.0: firmware: direct-loading firmware 
rtl_nic/rtl8168d-2.fw
[4.984001] input: HDA ATI HDMI HDMI/DP,pcm=3 as 
/devices/pci:00/:00:03.0/:01:00.1/sound/card1/input9
[4.984085] input: HDA ATI HDMI HDMI/DP,pcm=7 as 
/devices/pci:00/:00:03.0/:01:00.1/sound/card1/input10
[4.984144] input: HDA ATI HDMI HDMI/DP,pcm=8 as 
/devices/pci:00/:00:03.0/:01:00.1/sound/card1/input11
[4.984608] input: HDA ATI HDMI HDMI/DP,pcm=9 as 
/devices/pci:00/:00:03.0/:01:00.1/sound/card1/input12
[4.984680] input: HDA ATI HDMI HDMI/DP,pcm=10 as 
/devices/pci:00/:00:03.0/:01:00.1/sound/card1/input13
[4.984746] input: HDA ATI HDMI HDMI/DP,pcm=11 as 
/devices/pci:00/:00:03.0/:01:00.1/sound/card1/input14
[4.986104] kvm: VM_EXIT_LOAD_IA32_PERF_GLOBAL_CTRL does not work properly. 
Using workaround
[4.988309] snd_hda_codec_via hdaudioC0D0: autoconfig for VT1828S: 
line_outs=4 (0x24/0x25/0x26/0x27/0x0) type:line
[4.988312] snd_hda_codec_via hdaudioC0D0:speaker_outs=0 
(0x0/0x0/0x0/0x0/0x0)
[4.988314] snd_hda_codec_via hdaudioC0D0:hp_outs=1 
(0x28/0x0/0x0/0x0/0x0)
[4.988315] snd_hda_codec_via hdaudioC0D0:mono: mono_out=0x0
[4.988316] snd_hda_codec_via hdaudioC0D0:dig-out=0x2d/0x2e
[4.988318] snd_hda_codec_via hdaudioC0D0:inputs:
[4.988320] snd_hda_codec_via hdaudioC0D0:  Front Mic=0x29
[4.988321] snd_hda_codec_via hdaudioC0D0:  Rear Mic=0x2b
[4.988323] snd_hda_codec_via hdaudioC0D0:  Line=0x2a
[4.988324] snd_hda_codec_via hdaudioC0D0:  CD=0x2c
[4.998611] input: HDA Digital PCBeep as 
/devices/pci:00/:00:1b.0/sound/card0/input15
[4.998902] input: HDA Intel MID Front Mic as 
/devices/pci:00/:00:1b.0/sound/card0/input16
[4.999647] input: HDA Intel MID Rear Mic as 
/devices/pci:00/:00:1b.0/sound/card0/input17
[5.000369] input: HDA Intel MID Line as 
/devices/pci:00/:00:1b.0/sound/card0/input18
[5.000482] input: HDA Intel MID Line Out Front as 
/devices/pci:00/:00:1b.0/sound/card0/input19
[5.000548] input: HDA Intel MID Line Out Surround as 
/devices/pci:00/:00:1b.0/sound/card0/input20
[5.000616] input: HDA Intel MID Line Out CLFE as 
/devices/pci:00/:00:1b.0/sound/card0/input21
[5.000680] input: HDA Intel MID Line Out Side as 
/devices/pci:00/:00:1b.0/sound/card0/input22
[5.000740] input: HDA Intel MID Front Headphone as 
/devices/pci:00/:00:1b.0/sound/card0/input23
--->8---

---8<---
[0.00] Linux version 5.2.0-2-amd64 (debian-ker...@lists.debian.org) 
(gcc version 8.3.0 (Debian 8.3.0-21)) #1 SMP Debian 5.2.9-2 (2019-08-21)
...
[4.853182] snd_hda_intel :01:00.1: Handle vga_switcheroo audio client
[4.853184] snd_hda_intel :01:00.1: Force to non-snoop mode
[4.872028] snd_hda_codec_via hdaudioC0D0: autoconfig for VT1828S: 
line_outs=4 (0x24/0x25/0x26/0x27/0x0) type:line
[4.872030] snd_hda_codec_via hdaudioC0D0:speaker_outs=0 
(0x0/0x0/0x0/0x0/0x0)
[4.872031] snd_hda_codec_via hdaudioC0D0:hp_outs=1 
(0x28/0x0/0x0/0x0/0x0)
[4.872032] snd_hda_codec_via hdaudioC0D0:mono: mono_out=0x0
[4.872034] snd_hda_codec_via hdaudioC0D0:dig-out=0x2d/0x2e
[4.872035] snd_hda_codec_via hdaudioC0D0:inputs:
[4.872037] snd_hda_codec_via hdaudioC0D0:  Front Mic=0x29
[4.872038] snd_hda_codec_via hdaudioC0D0:  Rear Mic=0x2b
[4.872039] snd_hda_codec_via hdaudioC0D0:  Line=0x2a
[4.872041] snd_hda_codec_via hdaudioC0D0:  CD=0x2c
[4.875708] r8169 :02:00.0: firmware: direct-loading firmware 
rtl_nic/rtl8168d-2.fw
[4.876128] RTL8211B Gigabit Ethernet r8169-200:00: attached PHY driver 
[RTL8211B Gigabit Ethernet] (mii_bus:phy_addr=r8169-200:00, irq=IGNORE)
[4.906800] kvm: VM_EXIT_LOAD_IA32_PERF_GLOBAL_CTRL does not work properly. 
Using workaround
[4.925415] input: HDA Intel MID Front Mic as 
/devices/pci:00/:00:1b.0/sound/card0/input12
[4.925492] input: HDA Intel MID Rear Mic as 
/devices/pci:00/:00:1b.0/sound/card0/input13
[4.925568] input: HDA Intel MID Line as 
/devices/pci:00/:00:1b.0/sound/card0/input14
[4.925649] input: HDA Intel MID Line Out Front as 
/devices/pci:00/:00:1b.0/sound/card0/input15
[4.925731] input: HDA Intel MID Line Out 

Bug#940628: Working in 2.04-8 and 2.04-10

[Elliott Mitchell]

As of 2.04-8 it was possible to boot Xen on ARM.  The funky mechanism by
which GRUB loads its modules does a good job of obscuring which modules
to confirm presence of.

Seeing 'xen_loader="xen_hypervisor"' makes one expect to find
"/usr/lib/grub/arm64-efi/xen_hypervisor.mod", not for it to be taken care
of by "/usr/lib/grub/arm64-efi/xen_boot.mod".


-- 
(\___(\___(\__  --=> 8-) EHM <=--  __/)___/)___/)
 \BS (| ehem+sig...@m5p.com  PGP 87145445 |)   /
  \_CS\   |  _  -O #include  O-   _  |   /  _/
8A19\___\_|_/58D2 7E3D DDF4 7BA6 <-PGP-> 41D1 B375 37D0 8714\_|_/___/5445

Bug#954598: [Debian-lego-team] Bug#954598: nxt-firmware: FTBFS: readr.c:49: undefined reference to `_read'

[Petter Reinholdtsen]

[Lucas Nussbaum]
> During a rebuild of all packages in sid, your package failed to build
> on amd64.

Thank you for discovering this issue.  I hope someone find a fix in time
for the next Debian release.  I suspect I will not.

-- 
Happy hacking
Petter Reinholdtsen

Bug#975934: endlessh: missing endlessh@.socket despite the reference in README.Debian

[Philip Hands]

Package: endlessh
Version: 1.1-5
Severity: normal

Dear Maintainer,

I note that the fix for #970512 was to document the use of socket activation for
this service. However, you seem not to have included an endlessh@.socket file so
your suggestion in the README fails to work.

BTW I note that there is a pull request upstream relating to socket activation:

  https://github.com/skeeto/endlessh/pull/40

HTH

Cheers, Phil.

-- System Information:
Debian Release: 10.5
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable'), (99, 'unstable'), (99, 
'testing')
Architecture: amd64 (x86_64)

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

Versions of packages endlessh depends on:
ii  init-system-helpers  1.56+nmu1
ii  libc62.30-4

endlessh recommends no packages.

endlessh suggests no packages.

-- no debconf information

Bug#942611: [Pkg-xen-devel] Bug#942611: xen-doc: Various text files stored as .txt.gz, but index references .txt

[Hans van Kranenburg]

tags 942611 + pending
thanks

Hi Diederik,

On 10/19/19 2:19 AM, Diederik de Haas wrote:
> Package: xen-doc
> Version: 4.11.1+92-g6c33308a8d-2+b1
> Severity: normal
> 
> file:///usr/share/doc/xen/html/index.html contains a link to
> file:///usr/share/doc/xen/html/misc/vtd.txt (VT-d HOWTO), but that file
> doesn't exist. There is a .../misc/vtd.txt.gz file though.
> A similar pattern can be found with various other .txt files, but not all.
> Since this is HTML documentation and presumably meant to be read in a browser 
> (which is what I did), I think those .txt.gz files should be stored as .txt, 
> so
> they can be viewed in the browser and it would make the hyperlink actually 
> work.

Yes, you are right. I do agree.

We already have the html documentation collection in a separate package,
xen-doc.

So, when someone installs that package, they explicitly choose to do so.
If they want to browse around at file:///usr/share/doc/xen/html/ then
there should not be broken links all over the place.

The difference between compressing or not compressing is 5.1M vs 5.2M
measured by doing dpkg-deb -x on the xen-doc .deb before and after and
then doing du -sch on the directory in which it was unpacked.

https://salsa.debian.org/xen-team/debian-xen/-/commit/38cde19f59ee4121e048b23cfe7e9ea4ddcbdf60
(commit id will vanish because of heavily rebasing later, it's "d/rules:
do not compress /usr/share/doc/xen/html")

> (Sidenote: I doubt including a file mentioning how to compile your own 2.6.18 
> kernel 
> to include support for VT-d is useful, and it is 10+ y/o, but that's probably 
> an 
> upstream issue)

Heh, yes. Patches to remove obsolete documentation can be sent upstream
directly.

Have fun,
Hans

Bug#975933: mirror listing update for mirror.aminidc.com

[Amin IDC]

Package: mirrors
Severity: minor
User: mirr...@packages.debian.org
Usertags: mirror-list

Submission-Type: update
Site: mirror.aminidc.com
Type: leaf
Archive-architecture: ALL amd64 arm64 armel armhf hurd-i386 i386 kfreebsd-amd64 
kfreebsd-i386 mips mips64el mipsel powerpc ppc64el s390x
Archive-http: /debian/
Archive-rsync: debian/
Maintainer: Amin IDC 
Country: IR Iran, Islamic Republic of
Sponsor: Amin IDC https://aminidc.com




Trace Url: http://mirror.aminidc.com/debian/project/trace/
Trace Url: http://mirror.aminidc.com/debian/project/trace/ftp-master.debian.org
Trace Url: http://mirror.aminidc.com/debian/project/trace/mirror.aminidc.com

Bug#975932: buster-pu: package wireshark/2.6.20-0+deb10u1

[Adrian Bunk]

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

This update fixes the 14 non-dsa CVEs in buster by upgrading
to 2.6.20 (12 CVEs fixed) plus two fixes for additional CVEs.

Wireshark is a package where upstream is followed,
and will likely eventually be upgraded to a 3.x release
in a DSA at some point in the future. That's why this
pu request updates to the final 2.6 release (on top of
the last 2.6 release that was in unstable) instead of
backporting all CVE fixes.

The attached debdiff only includes changes to debian/
diff -Nru wireshark-2.6.8/debian/changelog wireshark-2.6.20/debian/changelog
--- wireshark-2.6.8/debian/changelog2019-05-27 17:08:44.0 +0300
+++ wireshark-2.6.20/debian/changelog   2020-11-26 21:21:18.0 +0200
@@ -1,3 +1,46 @@
+wireshark (2.6.20-0+deb10u1) buster; urgency=medium
+
+  * Non-maintainer upload.
+  * New upstream version including the following security fixes:
+- CVE-2019-16319: The Gryphon dissector could go into an infinite loop.
+- CVE-2019-19553: The CMS dissector could crash.
+- CVE-2020-7045: The BT ATT dissector could crash.
+- CVE-2020-9428: The EAP dissector could crash.
+- CVE-2020-9430: The WiMax DLMAP dissector could crash.
+- CVE-2020-9431: The LTE RRC dissector could leak memory.
+- CVE-2020-11647: The BACapp dissector could crash. (Closes: #958213)
+- CVE-2020-13164: The NFS dissector could crash.
+- CVE-2020-15466: The GVCP dissector could go into an infinite loop.
+- CVE-2020-25862: The TCP dissector could crash.
+- CVE-2020-25863: The MIME Multipart dissector could crash.
+  * Adjust 17_libdir_location.patch for context changes.
+  * Since Wireshark 2.6.14 tests are run automatically by debhelper,
+backport the build fix and making test failures non-fatal.
+  * CVE-2020-26575: The Facebook Zero Protocol (aka FBZERO) dissector
+could enter an infinite loop. (Closes: #974688)
+  * CVE-2020-28030: The GQUIC dissector could crash. (Closes: #974689)
+
+ -- Adrian Bunk   Thu, 26 Nov 2020 21:21:18 +0200
+
+wireshark (2.6.10-1) unstable; urgency=medium
+
+  * New upstream version 2.6.10
+ - security fixes:
+   - ASN.1 BER and related dissectors crash (CVE-2019-13619)
+ - fix QIcon crash on exit on Ubuntu 16.04 with Qt 5.5.1 (LP: #1803808)
+  * debian/gitlab-ci.yml: User minimal reference configuration
+
+ -- Balint Reczey   Wed, 17 Jul 2019 23:23:05 +0200
+
+wireshark (2.6.9-1) unstable; urgency=medium
+
+  * Acknowledge NMU
+  * New upstream version 2.6.9
+  * Drop obsolete CVE-2019-12295.patch
+  * Refresh patches
+
+ -- Balint Reczey   Thu, 30 May 2019 22:13:15 +0200
+
 wireshark (2.6.8-1.1) unstable; urgency=medium
 
   * Non-maintainer upload.
diff -Nru wireshark-2.6.8/debian/gitlab-ci.yml 
wireshark-2.6.20/debian/gitlab-ci.yml
--- wireshark-2.6.8/debian/gitlab-ci.yml2019-05-27 17:00:57.0 
+0300
+++ wireshark-2.6.20/debian/gitlab-ci.yml   2019-07-18 00:23:05.0 
+0300
@@ -1,13 +1,3 @@
-include: 
https://salsa.debian.org/salsa-ci-team/pipeline/raw/master/salsa-ci.yml
-
-build:
-extends: .build-unstable
-
-lintian:
-extends: .test-lintian
-
-autopkgtest:
-extends: .test-autopkgtest
-
-piuparts:
-extends: .test-piuparts
+include:
+  - https://salsa.debian.org/salsa-ci-team/pipeline/raw/master/salsa-ci.yml
+  - 
https://salsa.debian.org/salsa-ci-team/pipeline/raw/master/pipeline-jobs.yml
diff -Nru 
wireshark-2.6.8/debian/patches/0001-FBZERO-Make-sure-our-offset-advances.patch 
wireshark-2.6.20/debian/patches/0001-FBZERO-Make-sure-our-offset-advances.patch
--- 
wireshark-2.6.8/debian/patches/0001-FBZERO-Make-sure-our-offset-advances.patch  
1970-01-01 02:00:00.0 +0200
+++ 
wireshark-2.6.20/debian/patches/0001-FBZERO-Make-sure-our-offset-advances.patch 
2020-11-26 21:21:18.0 +0200
@@ -0,0 +1,63 @@
+From 3ff940652962c099b73ae3233322b8697b0d10ab Mon Sep 17 00:00:00 2001
+From: Gerald Combs 
+Date: Fri, 2 Oct 2020 12:42:03 -0700
+Subject: FBZERO: Make sure our offset advances.
+
+Make sure our offset advances so that we don't infinitely loop.
+Fixes #16887.
+---
+ epan/dissectors/packet-fbzero.c | 14 --
+ 1 file changed, 12 insertions(+), 2 deletions(-)
+
+diff --git a/epan/dissectors/packet-fbzero.c b/epan/dissectors/packet-fbzero.c
+index 16ffb63cf1..132079cfaa 100644
+--- a/epan/dissectors/packet-fbzero.c
 b/epan/dissectors/packet-fbzero.c
+@@ -66,6 +66,7 @@ static gint ett_fb_zero_tag_value = -1;
+ static expert_field ei_fb_zero_tag_undecoded = EI_INIT;
+ static expert_field ei_fb_zero_tag_length = EI_INIT;
+ static expert_field ei_fb_zero_tag_unknown = EI_INIT;
++static expert_field ei_fb_zero_length_invalid = EI_INIT;
+ 
+ #define FBZERO_MIN_LENGTH 3
+ 
+@@ -261,18 +262,26 @@ dissect_fb_zero_tag(tvbuff_t *tvb, packet_info *pinfo, 
proto_tree *fb_zero_tree,
+  "Dissector for FB Zero Tag"
+  

Bug#975931: pocl breaks libgpuarray autopkgtest on armhf: segmentation fault

[Paul Gevers]

Source: pocl, libgpuarray
Control: found -1 pocl/1.5-7
Control: found -1 libgpuarray/0.7.6-5
Severity: serious
Tags: sid bullseye
X-Debbugs-CC: debian...@lists.debian.org
User: debian...@lists.debian.org
Usertags: breaks needs-update

Dear maintainer(s),

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

   passfail
pocl   from testing1.5-7
libgpuarrayfrom testing0.7.6-5
all others from testingfrom testing

I copied some of the output at the bottom of this report. There's not a
hell of a lot to use for debugging.

Currently this regression is blocking the migration of pocl to testing
[1]. Due to the nature of this issue, I filed this bug report against
both packages. Can you please investigate the situation and reassign the
bug to the right package?

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

Paul

[1] https://qa.debian.org/excuses.php?package=pocl

https://ci.debian.net/data/autopkgtest/testing/amdhf/libg/libgpuarray/8423908/log.gz

autopkgtest [20:16:04]: test command1: set -e ; for py in $(py3versions
-r 2>/dev/null) ; do cd "$AUTOPKGTEST_TMP" ; echo "Testing with $py:" ;
DEVICE=opencl0:0 $py -m nose -v pygpu.tests ; echo "Testing with
$py-dbg:" ; DEVICE=opencl0:0 $py-dbg -m nose -v pygpu.tests ; done
autopkgtest [20:16:04]: test command1: [---
Testing with python3.9:
*** Testing for pthread-x-gene-1
mpi4py found: True
runTest (pygpu.tests.test_basic.test_errors) ... ok
pygpu.tests.test_basic.test_tril ... ok
pygpu.tests.test_basic.test_triu ... ok
pygpu.tests.test_blas.test_dot(1, 'float32', True, True, True, False)
... bash: line 1:  2439 Segmentation fault  DEVICE=opencl0:0 $py -m
nose -v pygpu.tests
autopkgtest [20:16:16]: test command1: ---]



signature.asc
Description: OpenPGP digital signature

Bug#975930: ITP: finbin -- Hi-speed search for a byte sequence in a big byte array

[Roger Shimizu]

Package: wnpp
Severity: wishlist
Owner: Roger Shimizu 

* Package name: finbin
  Version : 0.6.2
  Upstream Author : Tom Misawa 
* URL : https://github.com/riversun/finbin
* License : Apache-2.0 or Expat
  Programming Lang: Java
  Description : Hi-speed search for a byte sequence in a big byte array

Bug#975929: python-logfury: autopkgtest tries to use pip to download and install code from the internet

[Paul Gevers]

Source: python-logfury
Version: 0.1.2-4
Severity: serious
Justification: ftp-master autoreject ruling

Hi,

Your package has an autopkgtest, awesome. However, I noticed that it
tries to install Python code using pip. Running downloaded code from
internet is not allowed in the Debian archive; see the ftp-masters
autoreject list [1], so this must be prevented. Note that the download
is only tried with the latest upload of check-manifest, so this seems to
be a fallback mechanism which should be turned off.

Downloading data seems to be allowed, but please add a needs-internet
restriction in that case.

Your autopkgtest seems to need an update for check-manifest, that's how
I discovered this issue. If this is an issue with check-manifest, please
clone this issue and reassign one of the two.

Paul

[1] https://ftp-master.debian.org/REJECT-FAQ.html [Non-Main II]

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

autopkgtest [11:55:16]: test command1: [---
[*] testing on python3.8:
running nosetests
running egg_info
creating src/logfury.egg-info
writing src/logfury.egg-info/PKG-INFO
writing dependency_links to src/logfury.egg-info/dependency_links.txt
writing requirements to src/logfury.egg-info/requires.txt
writing top-level names to src/logfury.egg-info/top_level.txt
writing manifest file 'src/logfury.egg-info/SOURCES.txt'
reading manifest file 'src/logfury.egg-info/SOURCES.txt'
reading manifest template 'MANIFEST.in'
writing manifest file 'src/logfury.egg-info/SOURCES.txt'
WARNING: The pip package is not available, falling back to EasyInstall
for handling setup_requires/test_requires; this is deprecated and will
be removed in a future version.
Searching for build>=0.1
Reading https://pypi.org/simple/build/
Download error on https://pypi.org/simple/build/: [SSL:
CERTIFICATE_VERIFY_FAILED] certificate verify failed: unable to get
local issuer certificate (_ssl.c:1124) -- Some packages may not be found!
Couldn't find index page for 'build' (maybe misspelled?)
Scanning index of all packages (this may take a while)
Reading https://pypi.org/simple/
Download error on https://pypi.org/simple/: [SSL:
CERTIFICATE_VERIFY_FAILED] certificate verify failed: unable to get
local issuer certificate (_ssl.c:1124) -- Some packages may not be found!
No local packages or working download links found for build>=0.1
error: Could not find suitable distribution for
Requirement.parse('build>=0.1')
autopkgtest [11:55:17]: test command1: ---]



signature.asc
Description: OpenPGP digital signature

Bug#939608: bitcoin: CVE-2019-15947

[Salvatore Bonaccorso]

Hi Jonas,

On Thu, Nov 26, 2020 at 08:59:11PM +0100, Jonas Smedegaard wrote:
> Version: 0.20.1~dfsg-1
> 
> Quoting Salvatore Bonaccorso (2019-09-06 21:18:30)
> > The following vulnerability was published for bitcoin.
> > 
> > CVE-2019-15947[0]:
> > | In Bitcoin Core 0.18.0, bitcoin-qt stores wallet.dat data unencrypted
> > | in memory. Upon a crash, it may dump a core file. If a user were to
> > | mishandle a core file, an attacker can reconstruct the user's
> > | wallet.dat file, including their private keys, via a grep "6231 0500"
> > | command.
> > 
> > The severity is a bit exagerated here, but given the package is only
> > in testing and unstable, before the buster release this might be
> > considered RC and needed to fix. But it's a long road to there.
> > 
> > If you fix the vulnerability please also make sure to include the
> > CVE (Common Vulnerabilities & Exposures) id in your changelog entry.
> > 
> > For further information see:
> > 
> > [0] https://security-tracker.debian.org/tracker/CVE-2019-15947
> > https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-15947
> > 
> > Please adjust the affected versions in the BTS as needed.
> 
> This issue was fixed upstream since Debian release 0.20.1~dfsg-1.
> 
> I forgot to list the CVE in the changelog - that will be solved with 
> next release.

Okay thanks for the heads-up. I updated the security-tracker data
accordingly.

Regards,
Salvatore

Bug#975911: [debian-mysql] Bug#975911: mariadb-client: appears to ignore ~/.editrc keybind settings

[Otto Kekäläinen]

Thanks for reporting and debugging this. There are no libedit related
customizations in the Debian packaging, so I suggest you report this
upstream at jira.mariadb.org, where upstream devs might have some input
into this.

Otto

Bug#975913: Bluetooth mouse can not be connected with kernel linux-image-5.9.0-3-amd64

[Salvatore Bonaccorso]

Control: forcemerge 973368 975913

Hi

On Thu, Nov 26, 2020 at 11:35:56PM +0800, gulfstream wrote:
> Package: src:linux
> Version: 5.9.9-1
> Severity: important
> 
> 
> 
> After the kernel was upgraded to linux image 5.9 (from 
> linux-image-5.9.0-1-amd64, then linux-image-5.9.0-2-amd64, now it is 
> linux-image-5.9.0-3-amd64), the bluetooth mouse can not be connected which 
> can be use with linux-image-5.8.0-3-amd64. If back to 
> linux-image-5.8.0-3-amd64, the blue tooth mouse is also fine.
> 
> My laptop is Thinkpad P1.
> 
> Would you please resolve it for us? Thank you very much!

Please do stop opening new bugs, as this is the same as already filled
#973368 and #975323.

I had a followup question in https://bugs.debian.org/973368#14 Do the
changes discussed in
https://lore.kernel.org/linux-bluetooth/20201024002251.1389267-1-luiz.de...@gmail.com/
resolve the issue for you?

Regards,
Salvatore

Bug#963607: xen-hypervisor-4.11-amd64: Xen Hypervisor kernel fails to load arcmsr module with "arcmsr0: dma_alloc_coherent got error" message.

[Hans van Kranenburg]

tags 963607 + moreinfo
thanks

Hi Alex,

On 7/2/20 9:26 AM, debianb...@red-sand.com wrote:
> 
> [...]
> 
> I am about to purchase a new SAS HBA card to test as we have a number of
> these servers with Areca cards that I imagine will have the same problem
> on Xen 4.11.   I am leaning towards mpt3 driver cards but we have had
> problems with mpt3 previously so I am hesitating there too.  mpt2 has
> been rock solid. 
> 
> If you can think of anything else that I could try that would be
> excellent.  
> 
> [...]

No, I don't really have a suggestion.

Did you get new hardware? What do you want to do with this bug report?
There are no actionable items for us, we cannot solve a hardware problem
with packaging changes :) so I'd rather close it.

Thanks,
Hans

Bug#957881: tpm2-initramfs-tool: ftbfs with GCC-10

[Sebastien Bacher]

The attached patch fixes the issue, I've uploaded it to Ubuntu, you
commited it upstream, do you need a sponsor for a Debian upload?

diff -Nru tpm2-initramfs-tool-0.2.1/debian/changelog tpm2-initramfs-tool-0.2.1/debian/changelog
--- tpm2-initramfs-tool-0.2.1/debian/changelog	2019-10-21 08:53:17.0 +0200
+++ tpm2-initramfs-tool-0.2.1/debian/changelog	2020-11-26 20:47:02.0 +0100
@@ -1,3 +1,11 @@
+tpm2-initramfs-tool (0.2.1-5) unstable; urgency=medium
+
+  * debian/patches/git_gcc10_build.patch:
+- cherry pick an upstream patch to fix the build with gcc10
+  (Closes: #957881)
+
+ -- Sebastien Bacher   Thu, 26 Nov 2020 20:47:02 +0100
+
 tpm2-initramfs-tool (0.2.1-4) unstable; urgency=medium
 
   * Bump version for debian source package upload.
diff -Nru tpm2-initramfs-tool-0.2.1/debian/patches/git_gcc10_build.patch tpm2-initramfs-tool-0.2.1/debian/patches/git_gcc10_build.patch
--- tpm2-initramfs-tool-0.2.1/debian/patches/git_gcc10_build.patch	1970-01-01 01:00:00.0 +0100
+++ tpm2-initramfs-tool-0.2.1/debian/patches/git_gcc10_build.patch	2020-11-26 20:46:38.0 +0100
@@ -0,0 +1,58 @@
+From 263cd96f4597e91ed6d586e5b2dd24f2f44f3452 Mon Sep 17 00:00:00 2001
+From: Tim Chen 
+Date: Mon, 1 Jun 2020 10:54:56 +0800
+Subject: [PATCH] Fix gcc10 errors
+
+---
+ include/tpm2-initramfs-tool.h | 12 
+ src/libtpm2-initramfs-tool.c  |  3 +++
+ 2 files changed, 11 insertions(+), 4 deletions(-)
+
+diff --git a/include/tpm2-initramfs-tool.h b/include/tpm2-initramfs-tool.h
+index d8260f8..46ce4c4 100644
+--- a/include/tpm2-initramfs-tool.h
 b/include/tpm2-initramfs-tool.h
+@@ -131,7 +131,7 @@ extern const char *help;
+ extern const char *optstr;
+ extern const struct option long_options[];
+ 
+-struct {
++typedef struct {
+ enum { CMD_NONE, CMD_SEAL, CMD_UNSEAL } cmd;
+ char *data;
+ uint32_t persistent;
+@@ -139,12 +139,16 @@ struct {
+ int pcrs;
+ char *tcti;
+ int verbose;
+-} opt;
++} TPM2_INITRAMFS_TOOL_OPT;
+ 
+-struct {
++extern TPM2_INITRAMFS_TOOL_OPT opt;
++
++typedef struct {
+ void *dlhandle;
+ TSS2_TCTI_CONTEXT *context;
+-} tcti;
++} TPM2_INITRAMFS_TOOL_TCTI;
++
++extern TPM2_INITRAMFS_TOOL_TCTI tcti;
+ 
+ void tcti_finalize();
+ int tcti_init(char *str, TSS2_TCTI_CONTEXT **context);
+diff --git a/src/libtpm2-initramfs-tool.c b/src/libtpm2-initramfs-tool.c
+index 7d898c1..cbf8de4 100644
+--- a/src/libtpm2-initramfs-tool.c
 b/src/libtpm2-initramfs-tool.c
+@@ -59,6 +59,9 @@ const struct option long_options[] = {
+ { 0, 0, 0, 0 }
+ };
+ 
++TPM2_INITRAMFS_TOOL_OPT opt;
++TPM2_INITRAMFS_TOOL_TCTI tcti;
++
+ /** Function to generate base32 encoding string.
+  *
+  * This function generates the base32 encoding for input data.
+
diff -Nru tpm2-initramfs-tool-0.2.1/debian/patches/series tpm2-initramfs-tool-0.2.1/debian/patches/series
--- tpm2-initramfs-tool-0.2.1/debian/patches/series	1970-01-01 01:00:00.0 +0100
+++ tpm2-initramfs-tool-0.2.1/debian/patches/series	2020-11-26 20:46:51.0 +0100
@@ -0,0 +1 @@
+git_gcc10_build.patch

Bug#970066: atftp: CVE-2020-6097

[Moritz Mühlenhoff]

On Fri, Sep 11, 2020 at 07:12:49AM +0200, Salvatore Bonaccorso wrote:
> Source: atftp
> Version: 0.7.git20120829-3.1
> Severity: important
> Tags: security upstream
> X-Debbugs-Cc: car...@debian.org, Debian Security Team 
> 
> 
> Hi,
> 
> The following vulnerability was published for atftp.
> 
> CVE-2020-6097[0]:
> | An exploitable denial of service vulnerability exists in the atftpd
> | daemon functionality of atftp 0.7.git20120829-3.1+b1. A specially
> | crafted sequence of RRQ-Multicast requests trigger an assert() call
> | resulting in denial-of-service. An attacker can send a sequence of
> | malicious packets to trigger this vulnerability.

This is now fixed here:
https://sourceforge.net/u/peterkaestle/atftp/ci/96409ef3b9ca061f9527cfaafa778105cf15d994/

Cheers,
Moritz

Bug#975928: libreoffice: Please reimport the scale option in the view settings

[Hans-J. Ullrich]

Package: libreoffice
Version: 1:7.0.3-4
Severity: important

Dear Maintainer,

as there are now screens with high resolutions, the font of the menus are very 
tiny now. Especially for older people Libreoffice is hardly to use, due to the 
tiny font in the menu bar on top.

In former versions of Libreoffice there was a scale setting option in Extras -> 
Options -> Libreoffice -> View, but today this usefull feature is gone.

It would be nice and very, very helpfull, if you could set this back again.

Thank you very much for any help and also in the name of the elder people.

Best regards

Hans



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

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

Versions of packages libreoffice depends on:
ii  libreoffice-base1:7.0.3-4
ii  libreoffice-calc1:7.0.3-4
ii  libreoffice-core1:7.0.3-4
ii  libreoffice-draw1:7.0.3-4
ii  libreoffice-impress 1:7.0.3-4
ii  libreoffice-math1:7.0.3-4
ii  libreoffice-report-builder-bin  1:7.0.3-4
ii  libreoffice-writer  1:7.0.3-4
ii  python3-uno 1:7.0.3-4

Versions of packages libreoffice recommends:
ii  fonts-crosextra-caladea 20130214-2
ii  fonts-crosextra-carlito 20130920-1
ii  fonts-dejavu2.37-2
ii  fonts-liberation1:1.07.4-11
pn  fonts-liberation2   
ii  fonts-linuxlibertine5.3.0-4
pn  fonts-noto-core 
pn  fonts-noto-extra
pn  fonts-noto-mono 
ii  fonts-noto-ui-core  20201109-1
ii  fonts-sil-gentium-basic 1.102-1
ii  libreoffice-java-common 1:7.0.3-4
pn  libreoffice-nlpsolver   
pn  libreoffice-report-builder  
pn  libreoffice-script-provider-bsh 
pn  libreoffice-script-provider-js  
ii  libreoffice-script-provider-python  1:7.0.3-4
ii  libreoffice-sdbc-mysql  1:7.0.3-4
pn  libreoffice-sdbc-postgresql 
pn  libreoffice-wiki-publisher  

Versions of packages libreoffice suggests:
ii  cups-bsd 2.3.3-4
ii  default-jre [java8-runtime]  2:1.11-72
ii  firefox-esr  78.5.0esr-1
ii  ghostscript  9.52.1~dfsg-1
ii  gnupg2.2.20-1
pn  gpa  
ii  gstreamer1.0-libav   1.18.1-1
ii  gstreamer1.0-plugins-bad 1.18.0-2+b1
ii  gstreamer1.0-plugins-base1.18.1-1
ii  gstreamer1.0-plugins-good1.18.1-1
ii  gstreamer1.0-plugins-ugly1.18.1-1
ii  hunspell-de-at [hunspell-dictionary] 20161207-8
ii  hunspell-de-ch [hunspell-dictionary] 20161207-8
ii  hunspell-de-de [hunspell-dictionary] 20161207-8
ii  hyphen-de [hyphen-hyphenation-patterns]  1:7.0.1-1
ii  imagemagick  8:6.9.11.24+dfsg-1+b2
ii  imagemagick-6.q16 [imagemagick]  8:6.9.11.24+dfsg-1+b2
ii  libgl1   1.3.2-1
pn  libofficebean-java   
pn  libreoffice-grammarcheck 
ii  libreoffice-help-de [libreoffice-help]   1:7.0.3-4
ii  libreoffice-l10n-de [libreoffice-l10n]   1:7.0.3-4
ii  libreoffice-librelogo1:7.0.3-4
ii  libreoffice-plasma   1:7.0.3-4
ii  libsane1 1.0.31-3
ii  libxrender1  1:0.9.10-1
pn  myspell-dictionary   
ii  mythes-de [mythes-thesaurus] 20160424-3
ii  openclipart-libreoffice  1:0.18+dfsg-19
ii  openjdk-10-jre [java8-runtime]   10.0.2+13-2
ii  openjdk-11-jre [java8-runtime]   11.0.9.1+1-1
ii  openjdk-8-jre [java8-runtime]8u232-b09-1~deb9u1
ii  oracle-java8-jre [java8-runtime] 8u221
ii  pstoedit 3.75-1
ii  thunderbird  1:78.5.0-1
ii  unixodbc 2.3.6-0.1+b1

Versions of packages libreoffice-core depends on:
ii  fontconfig  2.13.1-4.2
ii  fonts-opensymbol2:102.11+LibO7.0.3-4
ii  libboost-locale1.71.0   1.71.0-7+b1
ii  libc6   2.31-4
ii  libcairo2   1.16.0-4
ii  libclucene-contribs1v5  2.3.3.4+dfsg-1+b1
ii  libclucene-core1v5  2.3.3.4+dfsg-1+b1
ii  libcmis-0.5-5v5 0.5.2-2+b1
ii  libcups2  

Bug#936268: caldav-tester: Python2 removal in sid/bullseye

[Moritz Mühlenhoff]

severity 936268 serious
thanks

On Tue, Nov 24, 2020 at 02:00:54PM +0100, Jonas Smedegaard wrote:
> I dare lower severity of this bug to important, however, since the 
> purpose of this package is only for testing other packages, not general 
> consumption (aligning with similar distinction in package 
> debian-security-support as of today).

These are only included for build deps on Py2 packages, not run time deps.

> Dropping this package causes less testing of package Radicale.

If no Py3 support can be written by time of the freeze, such tests can
still happen from a Buster or unstable chroot.

Cheers,
Moritz

Bug#975927: unison-gtk: No longer works from su session

[Helge Kreutzmann]

Package: unison-gtk
Version: 2.48.4-1+b1
Severity: important

Until a few days ago unsion-gtk worked from within su, if the
appropriate rights were set, e.g. by issuing xhost -. Now, however,
this no longer works:

root@samd:~# DISPLAY=:0 unison-gtk backupmirror 
No protocol specified
Uncaught exception Gtk.Error("GtkMain.init: initialization failed\nml_gtk_init: 
initialization failed")
Raised by primitive operation at file "gtkMain.ml", line 42, characters 1-14

Fatal error: exception File "/build/unison-jG3Alb/unison-2.48.4/uigtk2.ml", 
line 144, characters 14-20: Assertion failed
Raised at file "/build/unison-jG3Alb/unison-2.48.4/uigtk2.ml", line 144, 
characters 14-26
Called from file "/build/unison-jG3Alb/unison-2.48.4/uigtk2.ml", line 677, 
characters 27-46
Called from file "/build/unison-jG3Alb/unison-2.48.4/main.ml", line 241, 
characters 2-257
Called from file "/build/unison-jG3Alb/unison-2.48.4/linkgtk2.ml", line 19, 
characters 18-40


Plain unison, i.e. with -gtk, still works, however, is not 
very user-friendly if lots of changes occured.


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

Kernel taint flags: TAINT_UNSIGNED_MODULE
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8) (ignored: LC_ALL 
set to de_DE.UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages unison-gtk depends on:
ii  libatk1.0-0  2.36.0-2
ii  libc62.31-4
ii  libcairo21.16.0-4
ii  libfontconfig1   2.13.1-4.2
ii  libfreetype6 2.10.2+dfsg-4
ii  libgdk-pixbuf2.0-0   2.40.0+dfsg-7
ii  libglib2.0-0 2.66.3-1
ii  libgtk2.0-0  2.24.32-4
ii  libpango-1.0-0   1.46.2-3
ii  libpangocairo-1.0-0  1.46.2-3
ii  libpangoft2-1.0-01.46.2-3

Versions of packages unison-gtk recommends:
ii  ksshaskpass [ssh-askpass]4:5.19.5-3
ii  openssh-client [ssh-client]  1:8.4p1-2

Versions of packages unison-gtk suggests:
pn  unison-all-gtk  

-- no debconf information

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


signature.asc
Description: PGP signature

Bug#974644: postgresql-12-pg-wait-sampling: Package short description continues in long description

[Beatrice Torracca]

Hi!

Sorry for the late reply, I did not see the mail in the inbox.

On venerdì 13 novembre 2020, at 14:10 +0100, Adrien Nayrat wrote:
> On 11/13/20 9:59 AM, Beatrice Torracca wrote:
> > Package: postgresql-12-pg-wait-sampling
> > Severity: minor
> > 
> > Hi!
> > 
> > the package short description ("pg_wait-sampling provides functions
> > for detailed per backend") continues in the long description ("and per
> > query statistics about PostgreSQL wait events").
> > 
> > This is against the Debian Policy for package descriptions, and makes
> > both the short description and the long description not understandable
> > on their own.
> > 
> > Thanks,
> > 
> > beatrice
> > 
> 
> Hello Beatrice,
> 
> Indeed, sorry I wasn't aware of this rule.
> 
> What do you think of:
> Description: Extension providing statistics about PostgreSQL wait events
>  pg_wait-sampling is an extension which provides functions for detailed
>  per backend and per query wait events statistics.
>  .
>  It must be loaded in shared_preload_libraries to perform sample based
>  collection.

It is indeed a much better option for the short description. Please note that I 
am simply a member of the Italian translation team, so I surely can not say to 
have particular knowledge about the package itself.

Thanks for looking into this!!

beatrice

Bug#975902: octave-gui always shows "undecodable token: \001b(hex)[?2004h" in the prompt

[Rafael Laboissière]

Control: tags -1 + unreproducible moreinfo
Control: severity -1 normal

* Alberto Luaces  [2020-11-26 13:05]:

octave --gui is always showing "undecodable token: \001b(hex)[?2004h" 
at the prompt, hindering the edition commands since one cannot see 
where one is typing, and garbling the display.


Otherwise the rest of the program works ok as far as I know, and the 
CLI interface is not affected.


I have also tried in a new, fresh user account in order to see if it is 
related to my personal configuration, but I get the same results.


I cannot reproduce this bug.  Could you please provide a litte bit more 
information, please.  For instance, do you observe the same behavior with:


octave --gui --no-history --no-init-file  --no-site-file --norc

Best,

Rafael Laboissière

Bug#975902: octave-gui always shows "undecodable token: \001b(hex)[?2004h" in the prompt

[Alberto Luaces]

On 26/11/20 20:11, Rafael Laboissière wrote:
> 
> I cannot reproduce this bug.  Could you please provide a litte bit more
> information, please.  For instance, do you observe the same behavior with:
> 
>     octave --gui --no-history --no-init-file  --no-site-file --norc

Thank you for your prompt reply!

Unfortunately, the result is the same.  Is there any global
configuration or package that octave gui is relying in?  What can I try
next?

Regards.



OpenPGP_signature
Description: OpenPGP digital signature

Bug#975926: enigmail should not be shipped in bullseye

[Adrian Bunk]

Package: enigmail
Severity: serious
Tags: bullseye sid

It doesn't make sense to ship the enigmail migration wizard
in bullseye.

Bug#975925: ITP: proxy-vole -- Java library to auto detect the platform network proxy settings

[Roger Shimizu]

Package: wnpp
Severity: wishlist
Owner: Roger Shimizu 

* Package name: proxy-vole
  Version : 1.0.3
  Upstream Author : Markus Bernhardt 
* URL : https://github.com/MarkusBernhardt/proxy-vole
* License : Apache-2.0 and BSD-3-clause
  Programming Lang: Java
  Description : Proxy Vole

 Proxy Vole is a Java library to auto detect the platform network proxy
 settings.

Bug#951077: closed by Thomas Goirand (Fixed in 1.28.0 ?)

[Guillem Jover]

On Tue, 2020-11-24 at 22:24:13 +0100, Thomas Goirand wrote:
> On 11/24/20 3:57 PM, Guillem Jover wrote:
> > This is the second time something like this has happened to me with
> > git-review, so what I'm getting is that you don't want to deal with
> > valid bug reports
> 
> Very much, your bug report is valid.
> 
> Though I'm regularly reviewing bugs which I don't think I will ever
> action on, because I have other priorities. I sincerely regret not
> having enough time to deal with them. But then, what do you prefer? That
> I just leave them open forever, and do nothing, or that I'm honest and
> tell you that you should try to discuss with upstream if you want
> something to happen? This bug was opened since 10th of February, and
> since then, I was able to do nothing with it ... :/

Personally I'd rather have valid bugs kept open on the BTS, if not
just for coordination with other affected people. I'm fine waiting,
even years. What's important to me is that I can just check in a
single place (the Debian BTS) for known reported things in Debian.

If then you happen to have the time (or someone else does, like Mika
did here), then the bug can be forwarded, marked as such, and dealt
with either in Debian or upstream, etc. People affected or wanting
or able to help can even provide patches, etc.

The problem with closing valid bug reports is that then they become
invisible. :(

Thanks,
Guillem

Bug#975687: xterm: loses text lines, even descenders from some lines

[Thomas Dickey]

On Wed, Nov 25, 2020 at 06:26:14AM +0100, Thorsten Glaser wrote:
> Package: xterm
> Version: 362-1
> Severity: normal
> X-Debbugs-Cc: t...@mirbsd.de
> 
> I’ve got the following in my ~/.xinitrc…
> 
>   /usr/bin/xterm +sb -fg black -geom 78x10+1+637 \
>   -bg slateblue -e top &
>   /usr/bin/xterm +sb -fg black -geom 90x11+475+637 \
>   -bg cornflowerblue -e tail -F /var/log/syslog &
> 
> … to monitor the system on my laptop.
> 
> Recently, I’ve noticed that the right (syslog) window reliably

"Recently" could be something overlooked in #362's change

improve display when scaleHeight is greater than 1:
the text-cursor is vertically-centered on the current line, rather than
only extending below the current line

(though I'd expect problems only _if_ you're using scaleHeight resource)

On the other hand (if it's not specific to #362), a lot of the font/display
problems aren't xterm (and if the problem doesn't show up on macOS, I wouldn't
notice it right away).

-- 
Thomas E. Dickey 
https://invisible-island.net
ftp://ftp.invisible-island.net


signature.asc
Description: PGP signature

Bug#975896: don't pass unrecognized flags for D

[Matthias Klose]

On 11/26/20 8:01 PM, Guillem Jover wrote:
> Control: retitle -1 dpkg-buildflags: Please add support for D compiler flags
> Control: severity -1 wishlist
> Control: tags -1 moreinfo
> 
> On Thu, 2020-11-26 at 18:08:24 +0100, Sven Joachim wrote:
>> On 2020-11-26 12:19 +0100, Matthias Klose wrote:
>>> Package: dpkg-dev
>>> Version: 1.20.5
>>>
>>> as seen in
>>> https://buildd.debian.org/status/fetch.php?pkg=dub=amd64=1.22.0-1;
>>> stamp=1596920730=0
>>>
>>> Running gdc...
>>> + gdc -Wall -obin/dub -fversion=DubUseCurl -Isource
>>> -Wl,--push-state,--no-as-needed -lcurl -lz -Wl,--pop-state -g -O2
>>> -fdebug-prefix-map=/<>=. -fstack-protector-strong -Wformat
>>> -Werror=format-security -Wl,-z,relro @build-files.txt
>>> d21: warning: command-line option ‘-Wformat=1’ is valid for 
>>> C/C++/ObjC/ObjC++
>>> but not for D
>>> d21: warning: ‘-Werror=’ argument ‘-Werror=format-security’ is not valid 
>>> for D
>>> + set +x
>>>
>>> Please don't pass these flags in dpkg-buildflags.
>>
>> They are passed as part of CFLAGS.  If that is not suitable for D, I
>> think dub should not pass $CFLAGS to gdc, which it currently does.
> 
> Right, and it's not just dub, it's most of the packages in D where
> their build systems pass CPPFLAGS and CFLAGS to the compiler/linker
> invocation, in addition to DFLAGS.
> 
> I can add DFLAGS support at least to refactor the -fdebug/-frelease
> options, but even that will not fix the unknown options warnings as
> long as all those build systems are not modified.
> 
> meson for example simply filters unknown options, understanding that
> those might be coming from pkg-config and similar.

ahh, didn't look too closely.  Yes, DFLAGS would be useful. And maybe remove
GCJFLAGS?

Bug#975896: don't pass unrecognized flags for D

[Guillem Jover]

Control: retitle -1 dpkg-buildflags: Please add support for D compiler flags
Control: severity -1 wishlist
Control: tags -1 moreinfo

On Thu, 2020-11-26 at 18:08:24 +0100, Sven Joachim wrote:
> On 2020-11-26 12:19 +0100, Matthias Klose wrote:
> > Package: dpkg-dev
> > Version: 1.20.5
> >
> > as seen in
> > https://buildd.debian.org/status/fetch.php?pkg=dub=amd64=1.22.0-1;
> > stamp=1596920730=0
> >
> > Running gdc...
> > + gdc -Wall -obin/dub -fversion=DubUseCurl -Isource
> > -Wl,--push-state,--no-as-needed -lcurl -lz -Wl,--pop-state -g -O2
> > -fdebug-prefix-map=/<>=. -fstack-protector-strong -Wformat
> > -Werror=format-security -Wl,-z,relro @build-files.txt
> > d21: warning: command-line option ‘-Wformat=1’ is valid for 
> > C/C++/ObjC/ObjC++
> > but not for D
> > d21: warning: ‘-Werror=’ argument ‘-Werror=format-security’ is not valid 
> > for D
> > + set +x
> >
> > Please don't pass these flags in dpkg-buildflags.
> 
> They are passed as part of CFLAGS.  If that is not suitable for D, I
> think dub should not pass $CFLAGS to gdc, which it currently does.

Right, and it's not just dub, it's most of the packages in D where
their build systems pass CPPFLAGS and CFLAGS to the compiler/linker
invocation, in addition to DFLAGS.

I can add DFLAGS support at least to refactor the -fdebug/-frelease
options, but even that will not fix the unknown options warnings as
long as all those build systems are not modified.

meson for example simply filters unknown options, understanding that
those might be coming from pkg-config and similar.

Thanks,
Guillem

Bug#974695: buster-pu: package libxml2/2.9.4+dfsg1-7+deb10u1

[Moritz Mühlenhoff]

On Thu, Nov 19, 2020 at 08:39:55PM +, Adam D. Barratt wrote:
> Control: tags -1 + confirmed
> 
> On Fri, 2020-11-13 at 22:33 +0100, Moritz Muehlenhoff wrote:
> > This fixes a few low severity security fixes affecting libxml2,
> > I've tested the package on a buster system with a few rdeps.
> > 
> 
> Please go ahead.

Uploaded, thanks.

Cheers,
Moritz

Bug#975924: python3-rfc3986: rfc3986 sometimes needs idna, should be in Depends

[Andrej Shadura]

Package: python3-rfc3986
Version: 1.4.0-1
Severity: important

Hi,

I’m using rfc3986 by proxy of httpx.
I keep getting these exceptions:

req = client.build_request('GET', uri, params=params)
  File "/usr/lib/python3/dist-packages/httpx/_client.py", line 306, in 
build_request
url = self._merge_url(url)
  File "/usr/lib/python3/dist-packages/httpx/_client.py", line 327, in 
_merge_url
merge_url = URL(url)
  File "/usr/lib/python3/dist-packages/httpx/_models.py", line 121, in 
__init__
self._uri_reference = rfc3986.iri_reference(url).encode()
  File "/usr/lib/python3/dist-packages/rfc3986/iri.py", line 115, in encode
raise exceptions.MissingDependencyError(
rfc3986.exceptions.MissingDependencyError: Could not import the 'idna' 
module and the IRI hostname requires encoding

I think rfc3986 should depend on idna.

Thanks for considering this request.

-- 
Cheers,
  Andrej

Bug#973566: Fixed itself

[Edmund Biow]

I meant bullseye at #10, never try to post a bug without coffee.

Anyway, the issue seems to have resolved itself on Debian testing for 
me, this morning I was greeted by a request for an updated gmail 
certificate (I have pidgin set to auto-start), and everything looks 
ducky after several weeks. I guess that is why they call it testing...


BTW, is there any way to automatically accept the certificates? I never 
double check them and really don't use pidgin to do anything but chat 
with the spouse and a couple of cronies and sometimes get several new 
gmail certificates requests a day (and sometimes seem to go a long time 
between new ones). I know I shouldn't add anything to a bug report, but 
I guess I'm just an evil git that way.

Bug#975923: universal-ctags: Double quotes " are not parsed correctly

[Vincent Smeets]

Package: universal-ctags
Version: 0+git20200824-1
Severity: normal
Tags: upstream
X-Debbugs-Cc: vincent.vsme...@gmail.com

It looks like that double quotes are searched for in pairs. Everything
in between is skipped.

The attached assembly file has double quotes in the comments. The
command:
ctags -o - test.s
shows that some labels are not found, and some are incorrectly tagged.
The output looks like:

label1  test.s  /^label1:   ; No problems with label1.$/;"  l
label2  test.s  /^label4:   ; The tag of label2 will search for 
label4 because of the closing " character.$/;"  l
label5  test.s  /^label5:   ; Back to normal again.$/;" l

Label1 is Ok.
Label2 has the search pattern of the line with label4.
Label3 is missing.
Label4 is mixed up with label2.
Label5 is Ok again.

Regards,
Vincent


-- 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.9.0-3-amd64 (SMP w/4 CPU threads)
Locale: LANG=nl_NL.utf8, LC_CTYPE=nl_NL.utf8 (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 universal-ctags depends on:
ii  libc62.31-4
ii  libjansson4  2.13.1-1
ii  libseccomp2  2.5.0-3
ii  libxml2  2.9.10+dfsg-6.2
ii  libyaml-0-2  0.2.2-1

universal-ctags recommends no packages.

Versions of packages universal-ctags suggests:
ii  vim  2:8.2.1913-1+b2

-- no debconf information
; Problems with a single double-quote character.

label1: ; No problems with label1.
label2: ; label2 will not be found due to the " character.
label3: ; label3 is also skipped.
label4: ; The tag of label2 will search for label4 because of the 
closing " character.
label5: ; Back to normal again.

Bug#975922: rtklib: please update to a more recent upstream version

[Martin Schitter]

Package: rtklib
Version: 2.4.3+dfsg1-2.1
Severity: important

Dear Maintainer,

please update the rtklib package!

although the rtklib-packes in the debian repository are based on the
upstream development branch (2.4.3) of this application, it's in fact
still based on a utterly outdated patch level (b8 dating back to january
2016!!! -- instead of the much more common b33 from august 2019).
that's very irritating for practical use, because many obvious bugs
got already fixed in this more recent patch-level-releases (eg.
support for newer Gallileo satellites, etc.)

thanks!
martin

Bug#975911: mariadb-client: appears to ignore ~/.editrc keybind settings

[The Wanderer]

On 2020-11-26 at 09:43, The Wanderer wrote:

> Package: mariadb-client
> Version: 1:10.5.8-3
> Severity: normal
> 
> Dear Maintainer,
> 
> I have just upgraded mariadb-client (and -server) from version 10.3.x to
> version 10.5.8-3. As far as I can tell, no versions between those made
> it into testing. If I'm not mistaken, the last version I was running
> pre-upgrade was 10.3.24-2.
> 
> Prior to the upgrade, in an interactive session within the 'mysql'
> terminal-based client, Ctrl+W would kill everything to the left of the
> cursor up to the first word boundary (which in practice appeared to mean
> "whitespace"), but nothing to the left of that point.
> 
> This is apparently not the default, but I have it configured in
> ~/.editrc. The contents of that file are as follows:
> 
> ---8<---
> bind "^U" vi-kill-line-prev
> bind "^W" ed-delete-prev-word
> ---8<---
> 
> Following the upgrade and a restart of the client, in such an
> interactive session, Ctrl+W now kills everything to the left of the
> cursor, all the way to the beginning of the line. This appears to be the
> default behavior, used when no alternate configuration has been applied.
> 
> It thus appears as if the settings I have in place in ~/.editrc are
> simply being ignored. The environment variable EDITRC is not set.
> Launching with it explicitly set does not appear to change anything.

On further investigation, this might not be the full explanation after
all.

According to 'man editline', the ed-delete-prev-word function is bound
by default to Ctrl+Meta+H. When I execute that key combination, it kills
not up the preceding whitespace (as Ctrl+W used to do), but to the
preceding word boundary (using what seems to be the same criteria as
would be used by '\b' in a regular expression).

https://certif.com/cplot_print/libedit.html and
https://www.certif.com/spec_print/editline.html document the "kill
until previous whitespace" functionality as being provided by
em_kill_region. 'man editline' refers to em-kill-region, but states that
it kills everything between the cursor and "the mark"; since the mark
must be explicitly placed and omitting it means invoking this function
is an error, that doesn't seem to be equivalent to "kill until previous
whitespace".

The latter of those pages documents the readline equivalent of
ed-delete-prev-word as being backward-kill-word, and the one for "kill
until previous whitspace" as being unix-word-rubout. I haven't found a
way to readily test the behavior of these on my system yet, so I don't
know for sure which if any of them provide the behavior I expected.


I'm coming to suspect that there may be no way to regain access to the
previous behavior without either severely patching libedit (either
locally or upstream) or reverting to have mariadb-client use readline
again instead. Either of those things would be drastic, but for this
regression to be permanent would be quite unfortunate.

Either way, the fact that ~/.editrc does not seem to be being respected
is still an issue, which may or may not reside in mariadb-client. This
additional discovery may simply mean that it was being ignored
previously as well, I just hadn't noticed.


I filed this as a bug report on account of regression, but it's starting
to look like it might belong more in more general discussion channels
for the time being, until the actual root nature of the regression can
be figured out...

-- 
   The Wanderer

The reasonable man adapts himself to the world; the unreasonable one
persists in trying to adapt the world to himself. Therefore all
progress depends on the unreasonable man. -- George Bernard Shaw



signature.asc
Description: OpenPGP digital signature

Bug#975797: qtwebkit-opensource-src: FTBFS: NameError: name 'bytecodeSections' is not defined

[Dmitry Shachnev]

Control: fixed -1 qtwebkit-opensource-src/5.212.0~alpha4-9

On Wed, Nov 25, 2020 at 09:05:29PM +0100, Lucas Nussbaum wrote:
> During a rebuild of all packages in sid, your package failed to build
> on amd64.
>
> Relevant part (hopefully):
>
> > [114/4460] cd "/<>/obj-x86_64-linux-gnu/Source/JavaScriptCore" 
> > && /usr/bin/python3 
> > "/<>/Source/JavaScriptCore/generate-bytecode-files" 
> > --bytecodes_h 
> > "/<>/obj-x86_64-linux-gnu/DerivedSources/JavaScriptCore/Bytecodes.h"
> >  --init_bytecodes_asm 
> > "/<>/obj-x86_64-linux-gnu/DerivedSources/JavaScriptCore/InitBytecodes.asm"
> >  "/<>/Source/JavaScriptCore/bytecode/BytecodeList.json"
> > FAILED: DerivedSources/JavaScriptCore/Bytecodes.h 
> > DerivedSources/JavaScriptCore/InitBytecodes.asm 
> > cd "/<>/obj-x86_64-linux-gnu/Source/JavaScriptCore" && 
> > /usr/bin/python3 
> > "/<>/Source/JavaScriptCore/generate-bytecode-files" 
> > --bytecodes_h 
> > "/<>/obj-x86_64-linux-gnu/DerivedSources/JavaScriptCore/Bytecodes.h"
> >  --init_bytecodes_asm 
> > "/<>/obj-x86_64-linux-gnu/DerivedSources/JavaScriptCore/InitBytecodes.asm"
> >  "/<>/Source/JavaScriptCore/bytecode/BytecodeList.json"
> > Unexpected error parsing 
> > /<>/Source/JavaScriptCore/bytecode/BytecodeList.json: ( > 'TypeError'>, TypeError("__init__() got an unexpected keyword argument 
> > 'encoding'"), )
> > Traceback (most recent call last):
> >   File "/<>/Source/JavaScriptCore/generate-bytecode-files", 
> > line 181, in 
> > for section in bytecodeSections:
> > NameError: name 'bytecodeSections' is not defined

This is fixed in experimental.

The fix will reach unstable as part of Qt 5.15.2 transition which will
happen soon, I think it can wait until that.

--
Dmitry Shachnev


signature.asc
Description: PGP signature

Bug#975882: samba-common-bin: smb.conf testparm: Weak crypto is allowed

[Andrew Bartlett]

On Thu, 2020-11-26 at 20:55 +0800, Paul Wise wrote:
> On Thu, 2020-11-26 at 21:57 +1300, Andrew Bartlett wrote:
> 
> > No, this is just a reflection of what mode GnuTLS is set to on your
> > system.
> 
> Hmm, I haven't customised the GnuTLS config, so does that mean that
> Debian GnuTLS still allows some weak crypto? Should this be
> reassigned?

It all really depends on if you feel like breaking Samba or not.  Weak
crypto makes the world go round.

The alternative is FIPS mode.  If you enjoy that straight-jacket then
enabled FIPS mode in GnuTLS and some Samba things won't work.  A fair
bit actually.

What should come of this bug is that the testparm output and associated
documentation needs to be much more verbose as to what this means, and
what the alternative would mean for a interoperable installation. 

(And that needs to be an upstream bug and discussion really).

Andrew Bartlett

-- 
Andrew Bartlett (he/him)   https://samba.org/~abartlet/
Samba Team Member (since 2001) https://samba.org
Samba Team Lead, Catalyst IT   https://catalyst.net.nz/services/samba

Bug#974836: openconnect FTBFS on IPV6-only buildds

[Luca Boccassi]

Control: tags -1 moreinfo unreproducible
Control: severity -1 important

On Sun, 15 Nov 2020 13:25:11 +0200 Adrian Bunk  wrote:
> Source: openconnect
> Version: 8.10-1
> Severity: serious
> Tags: ftbfs
> 
> https://buildd.debian.org/status/fetch.php?pkg=openconnect=i386=8.10-1~bpo10%2B1=1589917131=0

> https://buildd.debian.org/status/fetch.php?pkg=openconnect=amd64=8.10-1~bpo10%2B1=1589912458=0

> https://buildd.debian.org/status/fetch.php?pkg=openconnect=amd64=8.10-2=1603997003=0

> 
> ...
> FAIL: auth-username-pass
> 
> 
> Testing certificate auth... 
> warning: skipping unknown option 'cookie-validity'
> Parsing plain auth method subconfig using legacy format
> note: vhost:default: setting 'plain' as primary authentication method
> note: setting 'file' as supplemental config option
> listening (TCP) on [::]:443...
> listening (UDP) on [::]:443...
> ocserv[19194]: main: Starting 1 instances of ocserv-sm
> ocserv[19194]: main: not using control unix socket
> ocserv[19194]: main: initialized ocserv 1.1.1
> ocserv[19214]: sec-mod: reading supplemental config from files
> ocserv[19214]: sec-mod: sec-mod initialized (socket: 
> ./ocserv-socket.af571984.0)
> Connecting to obtain cookie... Failure: Could not receive cookie from server
> ocserv[19194]: main: termination request received; waiting for children to die
> FAIL auth-username-pass (exit status: 1)
> 
> FAIL: auth-certificate
> ==
> 
> Testing certificate auth... 
> warning: skipping unknown option 'cookie-validity'
> Parsing plain auth method subconfig using legacy format
> note: vhost:default: setting 'certificate+plain' as primary authentication 
> method
> note: setting 'file' as supplemental config option
> listening (TCP) on [::]:443...
> listening (UDP) on [::]:443...
> ocserv[19199]: main: Starting 1 instances of ocserv-sm
> ocserv[19199]: main: not using control unix socket
> ocserv[19199]: main: initialized ocserv 1.1.1
> ocserv[19215]: sec-mod: reading supplemental config from files
> ocserv[19215]: sec-mod: sec-mod initialized (socket: 
> ./ocserv-socket.bee4d321.0)
> Connecting to obtain cookie (with key user-key-pkcs1.pem)... Failed to 
> connect to host 127.0.0.2
> Failed to open HTTPS connection to 127.0.0.2
> Failed to obtain WebVPN cookie
> Failure: Could not connect with key user-key-pkcs1.pem!
> ocserv[19199]: main: termination request received; waiting for children to die
> FAIL auth-certificate (exit status: 1)
> 
> FAIL: auth-nonascii
> ===
> 
> Testing certificate auth with non-ASCII passwords... 
> warning: skipping unknown option 'cookie-validity'
> Parsing plain auth method subconfig using legacy format
> note: vhost:default: setting 'certificate+plain' as primary authentication 
> method
> note: setting 'file' as supplemental config option
> listening (TCP) on [::]:443...

Can't reproduce this in a sid chroot + unshare -n + ip link set dev lo up + ip 
addr del 127.0.0.1/8 dev lo

make  check-TESTS
make[3]: Entering directory '/tmp/openconnect-8.10/tests'
make[4]: Entering directory '/tmp/openconnect-8.10/tests'
PASS: autocompletion
PASS: seqtest
PASS: lzstest
PASS: auth-username-pass
PASS: auth-nonascii
PASS: id-test
PASS: auth-pkcs11
PASS: auth-certificate
PASS: cert-fingerprint

#  ip a
1: lo:  mtu 65536 qdisc noqueue state UNKNOWN group 
default qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet6 ::1/128 scope host 
   valid_lft forever preferred_lft forever


Anything specific required to reproduce?

-- 
Kind regards,
Luca Boccassi


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

Bug#975921: mali-midgard: Contains auto-generated file without corresponding source

[Jessica Clarke]

Source: mali-midgard
Version: 16.0+pristine-4
Severity: serious

mali_base_hwconfig_issues.h currently has:

> /* AUTOMATICALLY GENERATED FILE. If you want to amend the issues/features,
>  * please update base/tools/hwconfig_generator/hwc_{issues,features}.py
>  * For more information see base/tools/hwconfig_generator/README
>  */

Unless patches to this file are accepted, this is not the preferred
form, and the mentioned scripts do not exist (I assume they are
Arm-internal scripts).

Jess

Bug#975896: don't pass unrecognized flags for D

[Sven Joachim]

On 2020-11-26 12:19 +0100, Matthias Klose wrote:

> Package: dpkg-dev
> Version: 1.20.5
>
> as seen in
> https://buildd.debian.org/status/fetch.php?pkg=dub=amd64=1.22.0-1;
> stamp=1596920730=0
>
> Running gdc...
> + gdc -Wall -obin/dub -fversion=DubUseCurl -Isource
> -Wl,--push-state,--no-as-needed -lcurl -lz -Wl,--pop-state -g -O2
> -fdebug-prefix-map=/<>=. -fstack-protector-strong -Wformat
> -Werror=format-security -Wl,-z,relro @build-files.txt
> d21: warning: command-line option ‘-Wformat=1’ is valid for C/C++/ObjC/ObjC++
> but not for D
> d21: warning: ‘-Werror=’ argument ‘-Werror=format-security’ is not valid for D
> + set +x
>
> Please don't pass these flags in dpkg-buildflags.

They are passed as part of CFLAGS.  If that is not suitable for D, I
think dub should not pass $CFLAGS to gdc, which it currently does.

Cheers,
   Sven

Bug#975920: ITP: pangolin -- Phylogenetic Assignment of Named Global Outbreak LINeages

[Andreas Tille]

Package: wnpp
Severity: wishlist

Subject: ITP: pangolin -- Phylogenetic Assignment of Named Global Outbreak 
LINeages
Package: wnpp
Owner: Andreas Tille 
Severity: wishlist

* Package name: pangolin
  Version : 2.0.8
  Upstream Author : Áine O'Toole, JT McCrone, Emily Scher
* URL : https://github.com/cov-lineages/pangolin
* License : GPL-3+
  Programming Lang: Python
  Description : Phylogenetic Assignment of Named Global Outbreak LINeages
 Pangolin runs a multinomial logistic regression model trained against
 lineage assignments based on GISAID data.
 .
 Legacy pangolin runs using a guide tree and alignment hosted at
 cov-lineages/lineages. Some of this data is sourced from GISAID, but
 anonymised and encrypted to fit with guidelines. Appropriate permissions
 have been given and acknowledgements for the teams that have worked to
 provide the original SARS-CoV-2 genome sequences to GISAID are also
 hosted here.

Remark: This package is maintained by Debian Med Packaging Team at
   https://salsa.debian.org/med-team/pangolin

Bug#944247: xen domU crashes under high i/o load if you use qcow2 images

[Hans van Kranenburg]

tags 944247 + moreinfo
severity 944247 normal
thanks

Hi Mario,

On 11/6/19 4:46 PM, mario wrote:
> Source: xen
> Severity: important
> 
> Dear Maintainer,
> 
> we have updated our server from debian oldstable (which unfortunately wasn't 
> running stable after the last update, bug reported) to debian buster.
> 
> unfortunately xen doesn't work reliably there either:
> 
> the virtual server crashes every 1-2 week with i/o problems and sometimes 
> also takes other domU instances with it.
> we use qcow2 images.
> 
> the harddisk of the domU is simply no longer accessible for the linux kernel, 
> no logfiles are available. in the xl console the following last lines can be 
> read, login not possible:
> 
> [ 1450.976415] INFO: task nginx:376 blocked for more than 120 seconds.
> [ 1450.976423] Not tainted 4.9.0-9-amd64 #1 Debian 4.9.168-1+deb9u5
> [ 1450.976428] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables 
> this message.
> [ 1450.976469] INFO: task nginx:377 blocked for more than 120 seconds.
> [ 1450.976474] Not tainted 4.9.0-9-amd64 #1 Debian 4.9.168-1+deb9u5
> [ 1450.976479] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables 
> this message.
> [ 1450.976624] INFO: task nginx:378 blocked for more than 120 seconds.
> 
> the process varies:
> [1523692.508073] INFO: task jbd2/xvda2-8:159 blocked for more than 120 seconds
> [1523692.508084] Not tainted [...]
> 
> all hard disk accesses fail as if the i/o system is completely dead.
> only "xl destroy " and recreate will help

This report is now a year old. Unfortunately it did not get any reply.
This might have several reasons, and one of them is probably that
there's not someone else around reading it that uses the same storage
configuration and as well runs into the same problem.

> you can easily reproduce this with the tool stress "stress -c 8 -i 8 -d 8".
> it takes a maximum of 10 minutes until the vm crashes.
> 
> in our experience, as a workaround you can convert all images to raw. after 
> our tests, the error will no longer occur. 
> but since we need the snapshot functions of qcow2 images, this is not a 
> permanent solution.
> 
> does anyone else have problems with qcow2 images and xen under buster?
> maybe this also concerns qemu?
> 
> [...]
To be honest, I do not know.

Have you been able to find out more about the problem yet, in the last
year? Have you taken steps to try narrow down the problem by
investigating other combinations of used software with/without xen? I
mean, for example, reboot into just Linux and mount the qcow2 image
somewhere and do the same load test to see if it's also happening when
eliminating Xen from the equation?

The bug report right now is not really actionable for anyone else than
yourself. As Debian Xen team we unfortunately do not have the bandwidth
to go set up a test server with the same configuration as you have and
try hammer on it and cause the same problem to happen.

Thanks,
Hans

Bug#975919: okular: Back and Forward navigation functions are broken

[Florent Rougon]

Package: okular
Version: 4:20.08.3-1
Severity: important
Tags: upstream patch

Dear maintainers,

Recent updates to okular have completely broken its Back and Forward
navigation functions (those found in the Go menu and bound to
Alt-Shift-Left and Alt-Shift-Right by default). This has been reported
upstream at [1] and fixed in commit 585340cef[2] (link found in this
comment[3] by Nate Graham on the bug report page[1]).

I have rebuilt okular 4:20.08.3-1 with the attached debdiff, which
merely applies the patch corresponding to [2]. This fixes the issue for
me. Hope this helps other users.

Thanks & regards

[1] https://bugs.kde.org/show_bug.cgi?id=414701
[2] 
https://invent.kde.org/graphics/okular/commit/585340cef5ca4dd1e26fe3baea1cf396f8de6469
[3] https://bugs.kde.org/show_bug.cgi?id=414701#c24

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

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

Versions of packages okular depends on:
ii  kinit 5.74.0-2
ii  kio   5.74.0-2
ii  libc6 2.31-4
ii  libfreetype6  2.10.2+dfsg-4
ii  libjpeg62-turbo   1:2.0.5-1.1
ii  libkf5activities5 5.74.0-2
ii  libkf5archive55.74.0-2
ii  libkf5bookmarks5  5.74.0-2
ii  libkf5codecs5 5.74.0-2
ii  libkf5completion5 5.74.0-2
ii  libkf5configcore5 5.74.0-2
ii  libkf5configgui5  5.74.0-2
ii  libkf5configwidgets5  5.74.0-2
ii  libkf5coreaddons5 5.74.0-2
ii  libkf5crash5  5.74.0-2
ii  libkf5i18n5   5.74.0-3
ii  libkf5iconthemes5 5.74.0-2
ii  libkf5itemviews5  5.74.0-2
ii  libkf5jobwidgets5 5.74.0-2
ii  libkf5kexiv2-15.0.0   20.04.3-1
ii  libkf5kiocore55.74.0-2
ii  libkf5kiowidgets5 5.74.0-2
ii  libkf5parts5  5.74.0-2
ii  libkf5pty55.74.0-2
ii  libkf5purpose-bin 5.74.0-2
ii  libkf5purpose55.74.0-2
ii  libkf5service-bin 5.74.0-2
ii  libkf5service55.74.0-2
ii  libkf5textwidgets55.74.0-2
ii  libkf5wallet-bin  5.74.0-2
ii  libkf5wallet5 5.74.0-2
ii  libkf5widgetsaddons5  5.74.0-3
ii  libkf5windowsystem5   5.74.0-2
ii  libkf5xmlgui5 5.74.0-2+b1
ii  libokular5core9   4:20.08.3-1
ii  libphonon4qt5-4   4:4.11.1-3
ii  libpoppler-qt5-1  20.09.0-3
ii  libqca-qt5-2  2.3.1-1
ii  libqmobipocket2   4:20.04.3-1
ii  libqt5core5a  5.15.1+dfsg-4
ii  libqt5dbus5   5.15.1+dfsg-4
ii  libqt5gui55.15.1+dfsg-4
ii  libqt5printsupport5   5.15.1+dfsg-4
ii  libqt5svg55.15.1-2
ii  libqt5texttospeech5   5.15.1-2
ii  libqt5widgets55.15.1+dfsg-4
ii  libqt5xml55.15.1+dfsg-4
ii  libspectre1   0.2.9-1
ii  libstdc++610.2.0-19
ii  phonon4qt54:4.11.1-3
ii  zlib1g1:1.2.11.dfsg-2

Versions of packages okular recommends:
ii  cups-bsd  2.3.3-4

Versions of packages okular suggests:
ii  ghostscript9.53.3~dfsg-5
ii  okular-extra-backends  4:20.08.3-1
ii  poppler-data   0.4.10-1
ii  texlive-binaries   2020.20200327.54578-5
ii  unrar  1:5.9.4-1

-- no debconf information
diff -Nru okular-20.08.3/debian/changelog okular-20.08.3/debian/changelog
--- okular-20.08.3/debian/changelog 2020-11-08 13:41:37.0 +0100
+++ okular-20.08.3/debian/changelog 2020-11-25 22:25:47.0 +0100
@@ -1,3 +1,9 @@
+okular (4:20.08.3-2~frougon.0) unstable; urgency=medium
+
+  * Add patch debian/patches/fix-back-and-forward-navigation.patch, which 
corresponds to 
.
+
+ -- Florent Rougon   Wed, 25 Nov 2020 22:25:47 +0100
+
 okular (4:20.08.3-1) unstable; urgency=medium
 
   * Team upload.
diff -Nru okular-20.08.3/debian/patches/fix-back-and-forward-navigation.patch 
okular-20.08.3/debian/patches/fix-back-and-forward-navigation.patch
--- okular-20.08.3/debian/patches/fix-back-and-forward-navigation.patch 
1970-01-01 01:00:00.0 +0100
+++ okular-20.08.3/debian/patches/fix-back-and-forward-navigation.patch 
2020-11-25 22:24:14.0 +0100
@@ -0,0 +1,11 @@
+--- a/ui/pageview.cpp
 b/ui/pageview.cpp
+@@ -4509,7 +4509,7 @@
+ newViewport.rePos.normalizedY = focusedY;
+ // set the viewport to other observers
+ // do not update history if the viewport is autoscrolling
+-d->document->setViewportWithHistory(newViewport, this, false, 
d->scroller->state() == QScroller::Scrolling);
++d->document->setViewportWithHistory(newViewport, this, false, 
d->scroller->state() != QScroller::Scrolling);
+ }
+ d->document->setVisiblePageRects(visibleRects, this);
+ }
diff -Nru 

Bug#975918: RM: libsis-jhdf5-java [s390x] -- ROM; Please remove old version from architecture s390x to enable migration and finalising auto-hdf5 transition

[Andreas Tille]

Package: ftp.debian.org
Severity: normal
X-Debbugs-Cc: Pierre Gruet , Nilesh Patra 
, Debian Med Packaging Team 


Hi,

it has turned out that the current version of libsis-jhdf5-java does not
build on s390x.  This us blocking not only the testing migration of a
set of important packages since a long time it also affects auto-hdf5
transition[1].  I consider it the best solution to remove the package
from architecture s390x for the moment.

Kind regards and thanks for your work as ftpmaster
Andreas.

Bug#975917: minidlna: files.db gets deleted and re-built on each startup

[Robert Latest]

Package: minidlna
Version: 1.2.1+dfsg-1+b1
Severity: important

Dear Maintainer,

Whenever minidlna starts up, it says:

"New media dir detected; rebuilding..."

Then it deletes the DB and starts rebuilding it, which takes about
one day because this is running on a low-power SBC and the DB is about
100MB in size when finished.

I don't understand this behavior as I didn't change anything about the
setup.

-- System Information:
Debian Release: 10.6
  APT prefers stable
  APT policy: (500, 'stable')
Architecture: arm64 (aarch64)
Foreign Architectures: armhf

Kernel: Linux 5.8.17-rockchip64 (SMP w/4 CPU cores; PREEMPT)
Kernel taint flags: TAINT_CRAP
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) (ignored: LC_ALL 
set to en_US.UTF-8), LANGUAGE=en_US.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set 
to en_US.UTF-8)
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages minidlna depends on:
ii  adduser  3.118
ii  libavformat587:4.1.6-1~deb10u1
ii  libavutil56  7:4.1.6-1~deb10u1
ii  libc62.28-10
ii  libexif120.6.21-5.1+deb10u4
ii  libflac8 1.3.2-3
ii  libid3tag0   0.15.1b-14
ii  libjpeg62-turbo  1:1.5.2-2+b1
ii  libogg0  1.3.2-1+b1
ii  libsqlite3-0 3.27.2-3
ii  libvorbis0a  1.3.6-2
ii  lsb-base 10.2019051400

minidlna recommends no packages.

minidlna suggests no packages.

-- Configuration Files:
/etc/logrotate.d/minidlna changed:
/var/log.hdd/minidlna.log
{
rotate 4
weekly
missingok
notifempty
delaycompress
compress
create 0644 minidlna minidlna
postrotate
service minidlna rotate > /dev/null
endscript
}

/etc/minidlna.conf changed:
user=minidlna
media_dir=V,/nas/disk2/video
media_dir=A,/nas/disk2/audio
media_dir=/nas/disk1/Bilder
db_dir=/nas/disk2/minidlna
log_dir=/nas/disk2/minidlna
log_level=general,artwork,database,inotify,scanner,metadata,http,ssdp,tivo=warn
root_container=B
port=8200
friendly_name=filmland
serial=681019810597110
model_name=MiniDLNA
inotify=yes
album_art_names=Cover.jpg/cover.jpg/AlbumArtSmall.jpg/albumartsmall.jpg
album_art_names=AlbumArt.jpg/albumart.jpg/Album.jpg/album.jpg
album_art_names=Folder.jpg/folder.jpg/Thumb.jpg/thumb.jpg
enable_tivo=no
notify_interval=895


-- no debconf information

Bug#975915: python3-debian: Deb822 objects cannot be serialized with pickle module

[Ansgar]

And of course I forgot something:

Alternatively one could ensure the hash gets updated when unpickling by
implementing `__setstate__` (or other means), but that seems more work
and I'm not sure it is so useful to store the precomputed hash anyway.

Ansgar

Bug#974724: no useful documentation of pdfjam commands

[Eduard Bloch]

Hallo,
* Norbert Preining [Thu, Nov 26 2020, 01:41:15PM]:
> On Sat, 14 Nov 2020, Eduard Bloch wrote:
> > First, in former times it was easy to find pdfjam because the package
>
> Yes, but now it is part of the TeX Live group and we cannot include the
> long description of every single included TeX package in the long
> description of the Debian package, it would fill a book.

And who decided to put dozens of separate tools into monster packages?
And adding a few more keywords to descriptions makes it suddenly "a
book" now?

> > Second, the documentation is useless. The manpage refers to ONLINE
> > documentation. IMHO this should be part of a package and NOT require a
> > user to establish internet connection. There is no offline version of
> > that README.md as far as I can see.
>
> Using
>   texdoc pdfjam

Interesting. Let's take a tour, demonstrating the ways of documentation
retrieval from users perspective.

Pre-Condition: As a regular user, I want to use a simple tool to merge
(join, concatenate, append...) a couple of existing PDF files. I don't
want to learn Latex language, my PDFs dont have much to do with Latex.

> gives you the README file of pdfjam with additional documentation, and

First, what is texdoc anyway?

$ man pdfjam | grep texdoc

-> nothing

A regular user has no idea about this command. Why should we even care?
We install a tool for basic documentation postprocessing, not creating
new stuff with Tex.

Even if the user knows learned this somehow by accident, your command
opens a browser, which wants me to open the MD file in a special editor
which is totally inappropriate. I guess you call sensible-browser there?
If so, why do you that for non-HTML contents? This does not make sense.
Why not use sensible-pager? Or "see"?

Let's assume that $USER figured out that RTFM of "pdfpages" is needed,
where to get it? Maintainer says:

>   texdoc pdfpages
> gives you the documentation of the additional key/value pairs accepted.

No, it doesn't.

$ texdoc pdfpages
Sorry, no documentation found for "pdfpages".
If you are unsure about the name, try full-text searching on CTAN.
Search form: 

$ apt search pdfpages
Sortierung... Fertig
Volltextsuche... Fertig
texlive-extra-utils/unstable,unstable,unstable,unstable,unstable,unstable,now 
2020.20200925-1 all  [installiert]
  TeX Live: TeX auxiliary programs

texlive-latex-recommended/unstable,unstable,unstable,unstable,unstable,unstable,now
 2020.20200925-1 all  [Installiert,automatisch]
  TeX Live: LaTeX recommended packages

And now, where is supposed to come from? (Remember, user perspective!)
Search it online? Like https://duckduckgo.com/?t=ffsb=man+pdfpages ?
Nice try, I remember "Passierschein A38" resp. "Catch 22".

Okay, with some luck (and knowledge how to use apt-file) one can find:
texlive-latex-recommended-doc: 
/usr/share/doc/texlive-doc/latex/pdfpages/pdfpages.pdf

So even after all that guessing one has to install FIFTY megabytes of
docs to learn about a couple of command line options of a simple tool
which does not even have obvious relationship to Latex in the first
place? SERIOUSLY?

And then even when going the hard way with pdfpages docs, it's not
perfectly clear how exactly to convert those documentation into pdfnup
command line options.

And by the way, if this is the way to go (which I doubt) then that way
should be documented in /usr/share/doc/texlive-extra-utils/README.Debian
somehow. Is it? Hardly, IMHO. And what do find there instead?

-- snip --
please see the document
TeX-on-Debian
in the tex-common package, which can be found in
/usr/share/doc/tex-common/
in the pdf, txt, and html format.
-- snap --

$ ls /usr/share/doc/tex-common/
NEWS.Debian.gz  changelog.gz  copyright

Great, another wrong instruction.

> Do you expect that pdfjam duplicates the complete documentation of
> pdfpages?

Why should I expect that? I didn't ever care about what it uses
underneath. I expect it, like any other tool, to document ITS OWN BASIC
operations properly. If that's is too complicated to be stored in a
manpage then please in a easily identifiable README somewhere aside AND
linked from the manpage.

> > Even the --help output is not helping. It tells a few things about
> > options but it does NOT mention what the actual operations are.
>
> It says that it is any of the many keys of pdfpages, so you need to read
> the documentation of pdfpages, which incidentally can be found with the
> above command.

Why? $USER installs a basic tool and wants to
- use it for basic operations (like, merging two PDFs) and
- have a simple doc about
  - those basic commands
  - which is avaible offline and
  - is easy to find.

Or do you expect a car buyer to read the complete maintenance manual
before starting the engine?

> So I really don't see what else can be provided ...

I do now, after learning that README.md is actually installed, just not
trivial to find. One could just put the reference to

Bug#975915: python3-debian: Deb822 objects cannot be serialized with pickle module

[Ansgar]

Package: python3-debian
Version: 0.1.38
Severity: normal
Tags: patch

Deb822 modules cannot properly be serialized by the pickle module.

It turns out the dict uses _CaseInsensitiveString which stores a
pre-computed hash value of a `str`. However Python randomizes hashes,
i.e., one will get a different hash for a _CaseInsensitiveString
restored by the pickle module and a newly created
_CaseInsensitiveString. As a workaround one can set the environment
variable `PYTHONHASHSEED=0`.

A short demo program is attached: call deb822pickler.py first, then
deb822unpickler.py.

I attached patches to just drop the precomputed hash. This makes
repeatedly calling `hash()` on the same string a bit slower, but on
the other hand calling `hash()` only once is a bit faster. I don't
think one usually needs to call `hash()` on the same string
repeatedly.

Also attached is a patch using `__slots__` to declare the member
variable. This makes creating a _CaseInsensitveString and calling hash
a bit faster.

I've attached a short benchmark script to compare the
implementations. On my system I get:

Using __slots__:

  Calling hash() repeatedly:
  Old implementation:  0.14679651000187732
  New implementation:  0.16284992700093426
  Creating string and calling hash once:
  Old implementation:  0.6289306499966187
  New implementation:  0.5861582299985457

Not using __slots__:

  Calling hash() repeatedly:
  Old implementation:  0.15407300100196153
  New implementation:  0.1629600290034432
  Creating string and calling hash once:
  Old implementation:  0.6767919499980053
  New implementation:  0.614397427008953

Ansgar
#! /usr/bin/python3

import pickle
from debian.deb822 import Deb822

d = Deb822("Field: value")

with open("db.pickle", "wb") as fh:
pickle.dump(d, fh)
#! /usr/bin/python3

import pickle
from debian.deb822 import Deb822

with open("db.pickle", "rb") as fh:
d = pickle.load(fh)

print(d)
#! /usr/bin/python3

import timeit

class _OldCaseInsensitiveString(str):
#str_lower = ''
#str_lower_hash = 0
__slots__ = 'str_lower', 'str_lower_hash'

def __new__(cls, str_): # type: ignore
s = str.__new__(cls, str_)# type: ignore
s.str_lower = str_.lower()
s.str_lower_hash = hash(s.str_lower)
return s

def __hash__(self):
# type: () -> int
return self.str_lower_hash


class _CaseInsensitiveString(str):
#str_lower = ''
__slots__ = 'str_lower'

def __new__(cls, str_): # type: ignore
s = str.__new__(cls, str_)# type: ignore
s.str_lower = str_.lower()
return s

def __hash__(self):
# type: () -> int
return hash(self.str_lower)

s_old = _OldCaseInsensitiveString("Field")
t_old = timeit.timeit('hash(s_old)', globals=globals())

s_new = _CaseInsensitiveString("Field")
t_new = timeit.timeit('hash(s_new)', globals=globals())

print("Calling hash() repeatedly:")
print("Old implementation: ", t_old)
print("New implementation: ", t_new)

t_old = timeit.timeit('hash(_OldCaseInsensitiveString("Field"))', 
globals=globals())
t_new = timeit.timeit('hash(_CaseInsensitiveString("Field"))', 
globals=globals())

print("Creating string and calling hash once:")
print("Old implementation: ", t_old)
print("New implementation: ", t_new)
>From 54165117266fcf419bc572e30bf66b4249074328 Mon Sep 17 00:00:00 2001
From: Ansgar 
Date: Thu, 26 Nov 2020 16:42:16 +0100
Subject: [PATCH 1/2] _CaseInsensitiveString: do not precompute hash

This allows the "pickle" module to work correctly: hashing a str will
give different results in different invocations of the Python
interpreter, so the old hash value should not be restored. Not storing
the hash value at all works for this.
---
 lib/debian/deb822.py | 4 +---
 1 file changed, 1 insertion(+), 3 deletions(-)

diff --git a/lib/debian/deb822.py b/lib/debian/deb822.py
index 9481a9c..d07abbb 100644
--- a/lib/debian/deb822.py
+++ b/lib/debian/deb822.py
@@ -2513,17 +2513,15 @@ class _CaseInsensitiveString(str):
 # Fake definitions because mypy doesn't find them in __new__ ## CRUFT
 # https://github.com/python/mypy/issues/1021
 str_lower = ''
-str_lower_hash = 0
 
 def __new__(cls, str_): # type: ignore
 s = str.__new__(cls, str_)# type: ignore
 s.str_lower = str_.lower()
-s.str_lower_hash = hash(s.str_lower)
 return s
 
 def __hash__(self):
 # type: () -> int
-return self.str_lower_hash
+return hash(self.str_lower)
 
 def __eq__(self, other):
 # type: (Any) -> Any
-- 
2.29.2

>From a547de6d8acee22eeb6f73ab570de76e80f21e6c Mon Sep 17 00:00:00 2001
From: Ansgar 
Date: Thu, 26 Nov 2020 16:46:49 +0100
Subject: [PATCH 2/2] _CaseInsensitiveString: declare data member using
 `__slots__`

---
 lib/debian/deb822.py | 4 +---
 1 file changed, 1 insertion(+), 3 deletions(-)

diff --git a/lib/debian/deb822.py b/lib/debian/deb822.py
index d07abbb..748383e 100644
--- a/lib/debian/deb822.py
+++ 

Bug#975891: error from deluge/_libtorrent.py

[Grand T]

Hello,
I managed it downgrading the 2 libs and using those from ubuntu


https://ubuntu.pkgs.org/20.10/ubuntu-universe-amd64/python3-libtorrent_1.2.5-1.2_amd64.deb.html

https://ubuntu.pkgs.org/20.10/ubuntu-universe-amd64/libtorrent-rasterbar10_1.2.5-1.2_amd64.deb.html


apt list --installed | grep libtorrent

libtorrent-rasterbar10/now 1.2.5-1.2 amd64 [installé, pouvant être mis à jour 
vers : 1.2.9-0.1]

libtorrent-rasterbar9/stable,now 1.1.11-2 amd64 [installé]

python3-libtorrent/now 1.2.5-1.2 amd64 [installé, pouvant être mis à jour vers 
: 1.2.9-0.1]



sudo apt-mark hold libtorrent-rasterbar10

libtorrent-rasterbar10 passé en figé (« hold »).

sudo apt-mark hold python3-libtorrent

python3-libtorrent passé en figé (« hold »).


it remains only one harmless error


deluge
Unable to initialize gettext/locale!
'ngettext'
Traceback (most recent call last):
  File "/usr/lib/python3/dist-packages/deluge/i18n/util.py", line 118, in 
setup_translation
builtins.__dict__['_n'] = builtins.__dict__['ngettext']
KeyError: 'ngettext'

And Deluge is ready with my locak preferences

Bug#975745: kexi: FTBFS: KReportGroupTracker.h:15: undefined reference to `vtable for KReportGroupTracker'

[Pino Toscano]

reassign 975745 libkreport3-4 kreport/3.2.0-2
tag 975745 = bullseye sid pending
affects 975745 src:kexi
thanks

In data mercoledì 25 novembre 2020 20:58:28 CET, Lucas Nussbaum ha scritto:
> Source: kexi
> Version: 1:3.2.0-2
> Severity: serious
> Justification: FTBFS on amd64
> Tags: bullseye sid ftbfs
> Usertags: ftbfs-20201125 ftbfs-bullseye
> 
> Hi,
> 
> During a rebuild of all packages in sid, your package failed to build
> on amd64.
> 
> Relevant part (hopefully):
> > /usr/bin/ld: CMakeFiles/kexi_reportplugin.dir/krscriptfunctions.cpp.o: in 
> > function `KReportGroupTracker::~KReportGroupTracker()':
> > /usr/include/KReport3/KReportGroupTracker.h:15: undefined reference to 
> > `vtable for KReportGroupTracker'
> > collect2: error: ld returned 1 exit status

Ops, I underestimated the symbols loss in kreport 3.2.0-2; fixing it
soon, luckly already fixed upstream.

-- 
Pino Toscano

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

Bug#975344: libapache-mod-auth-kerb: Uses Internal Krb5 APIs [test this patch please]

[Damyan Ivanov]

-=| Damyan Ivanov, 23.11.2020 22:16:43 +0200 |=-
> -=| Sam Hartman, 23.11.2020 10:02:34 -0500 |=-
> > Here's a patch that I believe will get libapache-mod-auth-kerb 
> > working with the latest krb5.  I'll go upload a krb5 that fixes the 
> > breaks relationship.
> > 
> > I'd appreciate it if someone who actually uses 
> > libapache-mod-auth-kerb will test this patch.
> > If it gets tested, I'll NMU.  If not, I'll ask the release team to
> > remove libapache-mod-auth-kerb from testing.
> 
> I'll try to find time to test the patch tomorrow (UTC+02).

A bit late, but I succeeded in testing the patch. Upgrading libkrb5-3 
and its dependencies to 1.18.3-4 doesn't break apache2 with 
mod-auth-kerb anymore. Moreover, the basic functionality (user 
authentication against a domain controller) works as before.

I am attaching a minimal patch, with the following changes compared to 
Sam's patch:

 - removed another instance of 'have_rcache_type' usage
 - removed all but the changes in debian/changelog, 
   debian/patches/serries and the real patch to mod_auth_kerb.c that 
   lives under debian/patches/.

I think this patch can be used for a clean NMU.

Cheers,
Damyan
diff --git a/debian/changelog b/debian/changelog
index b04ca6a..f621e17 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,10 @@
+libapache-mod-auth-kerb (5.4-2.5) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Always assume none replay cache type is present, Closes: #975344
+
+ -- Sam Hartman   Mon, 23 Nov 2020 09:34:53 -0500
+
 libapache-mod-auth-kerb (5.4-2.4) unstable; urgency=medium
 
   * Non-maintainer upload.
diff --git a/debian/patches/0011-Always-use-NONE-replay-cache-type.patch b/debian/patches/0011-Always-use-NONE-replay-cache-type.patch
new file mode 100644
index 000..71aaf40
--- /dev/null
+++ b/debian/patches/0011-Always-use-NONE-replay-cache-type.patch
@@ -0,0 +1,73 @@
+From: Sam Hartman 
+Date: Mon, 23 Nov 2020 09:30:22 -0500
+Subject: Always use NONE replay cache type
+
+It's 2020.  Any MIT Kerberos in the wild supports the none replay
+cache type.  The previous code used an internal function to detect
+that replay cache type; that function is no longer available.
+Instead, assume it is present.
+
+An alternative would be to enable the default replay cache.  It was
+originally disabled because of problems between Microsoft
+authenticators and 2004-era MIT Kerberos 1.3.  That's probably a good
+idea.  It probably closes off security attacks, although analyzing the
+impact of replays in cases where neither channel binding nor
+per-message services are used is difficult.  I believe that a replay
+cache is not strictly necessary in the common configuration where
+mod-auth-kerb is used over a TLS-protected connection where the client
+properly verifies the TLS certificate presented by the server prior to
+sending a GSS token.
+
+I have elected not to enable replay cache to affect a minimal change.
+---
+ src/mod_auth_kerb.c | 23 +--
+ 1 file changed, 1 insertion(+), 22 deletions(-)
+
+--- a/src/mod_auth_kerb.c
 b/src/mod_auth_kerb.c
+@@ -2057,27 +2057,6 @@ kerb_authenticate_user(request_rec *r)
+return ret;
+ }
+ 
+-static int
+-have_rcache_type(const char *type)
+-{
+-   krb5_error_code ret;
+-   krb5_context context;
+-   krb5_rcache id = NULL;
+-   int found;
+-
+-   ret = krb5_init_context();
+-   if (ret)
+-  return 0;
+-
+-   ret = krb5_rc_resolve_full(context, , "none:");
+-   found = (ret == 0);
+-
+-   if (ret == 0)
+-  krb5_rc_destroy(context, id);
+-   krb5_free_context(context);
+-
+-   return found;
+-}
+ 
+ /*** 
+  Module Setup/Configuration
+@@ -2139,7 +2118,7 @@ kerb_module_init(server_rec *dummy, pool
+ #ifndef HEIMDAL
+/* Suppress the MIT replay cache.  Requires MIT Kerberos 1.4.0 or later.
+   1.3.x are covered by the hack overiding the replay calls */
+-   if (getenv("KRB5RCACHETYPE") == NULL && have_rcache_type("none"))
++   if (getenv("KRB5RCACHETYPE") == NULL )
+   putenv(strdup("KRB5RCACHETYPE=none"));
+ #endif
+ }
+@@ -2181,7 +2160,7 @@ kerb_init_handler(apr_pool_t *p, apr_poo
+ #ifndef HEIMDAL
+/* Suppress the MIT replay cache.  Requires MIT Kerberos 1.4.0 or later.
+   1.3.x are covered by the hack overiding the replay calls */
+-   if (getenv("KRB5RCACHETYPE") == NULL && have_rcache_type("none"))
++   if (getenv("KRB5RCACHETYPE") == NULL)
+   putenv(strdup("KRB5RCACHETYPE=none"));
+ #endif
+ #ifdef STANDARD20_MODULE_STUFF
diff --git a/debian/patches/series b/debian/patches/series
index d2c7173..9848ef3 100644
--- a/debian/patches/series
+++ b/debian/patches/series
@@ -9,3 +9,4 @@ remove_bashism.patch
 gssapi_delegation.patch
 apache24.patch
 mod_auth_kerb-krb5_kt_close.patch
+0011-Always-use-NONE-replay-cache-type.patch

Bug#975914: libusb-1.0-0: libusb reports wrong device speed for libusb_wrap_sys_device() devices, breaks QEMU USB host device passthrough

[Jonathan Strobl]

Package: libusb-1.0-0
Version: 2:1.0.23-2.1
Severity: normal
Tags: patch
X-Debbugs-Cc: jonathan.str...@gmx.de

Dear Maintainer,

after upgrading libvirt to version 6.9.0, passthrough of USB devices into QEMU 
virtual machines broke.
The guest kernel was erroneously reporting the USB device as a "low-speed" 
device, even though it was
full-speed, and failed initialization of the device with the following error:
"invalid ep0 maxpacket: 64"

After some digging, I found out that this was a side-effect libvirt 6.9.0 
passing different (but valid)
options to QEMU for passing through host USB devices.
Old QEMU option: -device 
usb-host,hostbus=3,hostaddr=4,id=hostdev0,bus=usb.0,port=4
New QEMU option: -device 
usb-host,hostdevice=/dev/bus/usb/003/004,id=hostdev0,bus=usb.0,port=4

This, in turn, causes QEMU to use libusb_wrap_sys_device() to obtain a libusb 
device handle to the
host USB device, if my research is correct. After that, QEMU calls 
libusb_get_device_speed() to get
the speed of the USB device to pass through. This function returns an incorrect 
speed value for
wrapped devices in the current version of libusb, however, causing QEMU to 
report that incorrect speed
value to the guest operating system, which then results in the guest OS not 
being able to initialize
the USB device.

While a workaround patch for QEMU exists, I believe it is better to fix the 
underlying cause in libusb
and make libusb_get_device_speed() work for wrapped devices. There is a bug 
report on RedHat's
bugzilla (bug 1871818) that contains a patch for libusb, which has been 
upstreamed in libusb in commit
f6068e83c4f5e5fba16b23b6a87f1f6d7ab7200a. I have tested this patch on i386 and 
amd64 and can confirm
that it works.

I've attached a version of the patch that applies to Debian's libusb-1.0 
(2:1.0.23-2) using quilt.



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

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

Versions of packages libusb-1.0-0 depends on:
ii  libc6 2.31-4
ii  libudev1  246.6-4

libusb-1.0-0 recommends no packages.

libusb-1.0-0 suggests no packages.

-- no debconf information
Index: libusb-1.0-1.0.23/libusb/os/linux_usbfs.c
===
--- libusb-1.0-1.0.23.orig/libusb/os/linux_usbfs.c
+++ libusb-1.0-1.0.23/libusb/os/linux_usbfs.c
@@ -964,6 +964,26 @@ static int usbfs_get_active_config(struc
return LIBUSB_SUCCESS;
 }
 
+static enum libusb_speed usbfs_get_speed(struct libusb_context *ctx, int fd)
+{
+   int r;
+
+   r = ioctl(fd, IOCTL_USBFS_GET_SPEED, NULL);
+   switch (r) {
+   case USBFS_SPEED_UNKNOWN:   return LIBUSB_SPEED_UNKNOWN;
+   case USBFS_SPEED_LOW:   return LIBUSB_SPEED_LOW;
+   case USBFS_SPEED_FULL:  return LIBUSB_SPEED_FULL;
+   case USBFS_SPEED_HIGH:  return LIBUSB_SPEED_HIGH;
+   case USBFS_SPEED_WIRELESS:  return LIBUSB_SPEED_HIGH;
+   case USBFS_SPEED_SUPER: return LIBUSB_SPEED_SUPER;
+   case USBFS_SPEED_SUPER_PLUS:return LIBUSB_SPEED_SUPER_PLUS;
+   default:
+   usbi_warn(ctx, "Error getting device speed: %d", r);
+   }
+
+   return LIBUSB_SPEED_UNKNOWN;
+}
+
 static int initialize_device(struct libusb_device *dev, uint8_t busnum,
uint8_t devaddr, const char *sysfs_dir, int wrapped_fd)
 {
@@ -995,6 +1015,8 @@ static int initialize_device(struct libu
usbi_warn(DEVICE_CTX(dev), "Unknown device 
speed: %d Mbps", speed);
}
}
+   } else if (wrapped_fd >= 0) {
+   dev->speed = usbfs_get_speed(ctx, wrapped_fd);
}
 
/* cache descriptors in memory */
Index: libusb-1.0-1.0.23/libusb/os/linux_usbfs.h
===
--- libusb-1.0-1.0.23.orig/libusb/os/linux_usbfs.h
+++ libusb-1.0-1.0.23/libusb/os/linux_usbfs.h
@@ -143,6 +143,14 @@ struct usbfs_streams {
unsigned char eps[0];
 };
 
+#define USBFS_SPEED_UNKNOWN0
+#define USBFS_SPEED_LOW1
+#define USBFS_SPEED_FULL   2
+#define USBFS_SPEED_HIGH   3
+#define USBFS_SPEED_WIRELESS   4
+#define USBFS_SPEED_SUPER  5
+#define USBFS_SPEED_SUPER_PLUS 6
+
 #define IOCTL_USBFS_CONTROL_IOWR('U', 0, struct usbfs_ctrltransfer)
 #define IOCTL_USBFS_BULK   _IOWR('U', 2, struct usbfs_bulktransfer)
 #define IOCTL_USBFS_RESETEP_IOR('U', 3, unsigned int)
@@ -168,6 +176,8 @@ struct usbfs_streams {
 #define IOCTL_USBFS_DISCONNECT_CLAIM   _IOR('U', 27, struct 

Bug#975874: buster-pu: package openjdk-11/11.0.9.1+1-1~deb10u1

[Adam D. Barratt]

On Thu, 2020-11-26 at 07:32 -0800, tony mancill wrote:
> Does the confirmed tag indicate that I should proceed with a source
> upload?

Yes, please feel free to. Sorry if that wasn't clear.

Regards,

Adam

Bug#975913: Bluetooth mouse can not be connected with kernel linux-image-5.9.0-3-amd64

[gulfstream]

Package: src:linux
Version: 5.9.9-1
Severity: important



After the kernel was upgraded to linux image 5.9 (from 
linux-image-5.9.0-1-amd64, then linux-image-5.9.0-2-amd64, now it is 
linux-image-5.9.0-3-amd64), the bluetooth mouse can not be connected which can 
be use with linux-image-5.8.0-3-amd64. If back to linux-image-5.8.0-3-amd64, 
the blue tooth mouse is also fine.

My laptop is Thinkpad P1.

Would you please resolve it for us? Thank you very much!


Best regards,
Gulfstream



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

** Command line:
BOOT_IMAGE=/vmlinuz-5.9.0-3-amd64 
root=UUID=db2908ea-7526-4516-844c-944d78f49385 ro

** Tainted: OE (12288)
 * externally-built ("out-of-tree") module was loaded
 * unsigned module was loaded

** Kernel log:
Unable to read kernel log; any relevant messages should be attached

** Model information
sys_vendor: LENOVO
product_name: 20MES07K00
product_version: ThinkPad P1
chassis_vendor: LENOVO
chassis_version: None
bios_vendor: LENOVO
bios_version: N2EET50W (1.32 )
board_vendor: LENOVO
board_name: 20MES07K00
board_version: Not Defined

** Loaded modules:
rfcomm
snd_seq_dummy
snd_hrtimer
snd_seq
snd_seq_device
xfrm_user
xfrm_algo
l2tp_ppp
l2tp_netlink
l2tp_core
ip6_udp_tunnel
udp_tunnel
pppox
ppp_generic
slhc
xt_state
xt_conntrack
ctr
ccm
xt_CHECKSUM
ipt_REJECT
nf_reject_ipv4
xt_tcpudp
nft_compat
nft_counter
nft_chain_nat
nf_nat
nf_conntrack
nf_defrag_ipv6
nf_defrag_ipv4
nf_tables
nfnetlink
bridge
stp
llc
cmac
algif_hash
algif_skcipher
af_alg
bnep
bbswitch(OE)
x86_pkg_temp_thermal
intel_powerclamp
mei_wdt
intel_rapl_msr
coretemp
btusb
btrtl
btbcm
snd_sof_pci
btintel
snd_sof_intel_byt
snd_sof_intel_ipc
bluetooth
snd_sof_intel_hda_common
kvm_intel
snd_sof_xtensa_dsp
snd_sof
nls_ascii
jitterentropy_rng
nls_cp437
snd_sof_intel_hda
vfat
drbg
fat
iwlmvm
snd_soc_skl
kvm
snd_soc_hdac_hda
snd_hda_ext_core
snd_soc_sst_ipc
snd_soc_sst_dsp
snd_soc_acpi_intel_match
snd_soc_acpi
snd_soc_core
irqbypass
snd_hda_codec_realtek
aes_generic
mac80211
uvcvideo
snd_hda_codec_generic
ghash_clmulni_intel
snd_hda_codec_hdmi
videobuf2_vmalloc
snd_compress
libarc4
aesni_intel
videobuf2_memops
videobuf2_v4l2
crypto_simd
snd_hda_intel
videobuf2_common
cryptd
snd_intel_dspcfg
rapl
glue_helper
intel_cstate
efi_pstore
ansi_cprng
iwlwifi
snd_hda_codec
videodev
sd_mod
ecdh_generic
snd_hda_core
ecc
iTCO_wdt
sg
intel_pmc_bxt
intel_uncore
crc16
joydev
mc
tpm_crb
libaes
iTCO_vendor_support
snd_hwdep
pcspkr
tpm_tis
serio_raw
efivars
rmi_smbus
snd_pcm
thinkpad_acpi
wmi_bmof
mei_me
tpm_tis_core
cfg80211
processor_thermal_device
ucsi_acpi
tpm
typec_ucsi
snd_timer
intel_rapl_common
nvram
rmi_core
watchdog
mei
intel_soc_dts_iosf
intel_pch_thermal
ledtrig_audio
intel_wmi_thunderbolt
typec
rng_core
snd
soundcore
rfkill
int3403_thermal
ac
int340x_thermal_zone
intel_pmc_core
int3400_thermal
acpi_thermal_rel
evdev
acpi_pad
msr
parport_pc
ppdev
lp
parport
efivarfs
ip_tables
x_tables
autofs4
xfs
libcrc32c
crc32c_generic
wacom
hid_generic
usbhid
hid
uas
usb_storage
scsi_mod
i915
xhci_pci
xhci_hcd
i2c_algo_bit
nvme
drm_kms_helper
nvme_core
t10_pi
cec
crc_t10dif
e1000e
crc32_pclmul
intel_lpss_pci
crct10dif_generic
usbcore
psmouse
crc32c_intel
i2c_i801
ptp
intel_lpss
crct10dif_pclmul
drm
pps_core
i2c_smbus
crct10dif_common
idma64
usb_common
wmi
battery
video
button

** PCI devices:
00:00.0 Host bridge [0600]: Intel Corporation 8th Gen Core Processor Host 
Bridge/DRAM Registers [8086:3ec4] (rev 07)
Subsystem: Lenovo 8th Gen Core Processor Host Bridge/DRAM Registers 
[17aa:2267]
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B- DisINTx-
Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- SERR- 
Kernel driver in use: skl_uncore

00:01.0 PCI bridge [0604]: Intel Corporation 6th-9th Gen Core Processor PCIe 
Controller (x16) [8086:1901] (rev 07) (prog-if 00 [Normal decode])
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B- DisINTx+
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- TAbort- Reset- FastB2B-
PriDiscTmr- SecDiscTmr- DiscTmrStat- DiscTmrSERREn-
Capabilities: 
Kernel driver in use: pcieport

00:02.0 VGA compatible controller [0300]: Intel Corporation Device [8086:3e94] 
(prog-if 00 [VGA controller])
Subsystem: Lenovo Device [17aa:2267]
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B- DisINTx+
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- 
Kernel driver in use: i915
Kernel modules: i915

00:04.0 Signal processing controller [1180]: Intel Corporation Xeon E3-1200 
v5/E3-1500 v5/6th Gen Core Processor Thermal Subsystem [8086:1903] (rev 07)

Bug#975874: buster-pu: package openjdk-11/11.0.9.1+1-1~deb10u1

[tony mancill]

On Thu, Nov 26, 2020 at 08:07:47AM +, Adam D. Barratt wrote:
> Control: tags -1 + confirmed
> 
> On Wed, 2020-11-25 at 20:23 -0800, tony mancill wrote:
> > I propose that openjdk-11 be updated to upstream 11.0.9.1+1 in the
> > upcoming stable point release.  This update addresses a regression
> > [1] introduced in upstream release 11.0.9+11, which is present in
> > buster via a security upload [2].  This keeps Debian on par with
> > other vendors - e.g. RedHat [3], Ubuntu [4], and AdoptOpenJDK [5] -
> > and introduces the same upstream version currently available in
> > testing and unstable.
> > 
> > Without this update, users may encounter crashes during bytecode
> > compilation.  This this is not an optional component of the JVM,
> > there is no work-around and users would have to downgrade to 11.0.8
> > (which has open CVEs).
> > 
> > I have prepared an update and performed basic smoke-testing of the
> > resulting binaries.  The attached debdiff is based on the version
> > uploaded by Moritz Mühlenhoff for the DSA, 11.0.9+11-1~deb10u1.  I
> > checked with the OpenJDK Maintainers [6], where we agreed that this
> > update for the regression wouldn't follow the DSA process.
> 
> I'd have been more inclined to suggest fixing it via a DSA as a
> regression if it's going to affect lots of users (even though it's not
> a security update), given that's how the issue was introduced in the
> first place. I can see Moritz was involved in the discussion though, so
> I'm not going to push that too much right now. But this really
> shouldn't end up being SRM having to choose between security
> regressions or functional regressions for users when the latter were
> introduced via a DSA.
> 
> One difference between stable and unstable/testing that might be
> relevant here is that stable still has the mips architecture. I have to
> be honest that, from previous experiences with OpenJDK updates in
> (old)stable, that and the reintroduction of tests being run does
> concern me. But fingers crossed it all turns out fine.

Hi Adam,

Thank you for considering this.  An upstream regression introduced via a
DSA does seem like it could go both ways (and OpenJDK always seems to be
the exception to the rule).

Does the confirmed tag indicate that I should proceed with a source
upload?

Thank you,
tony


signature.asc
Description: PGP signature

Bug#975912: ufw: autopkgtests fail with Python 3.9

[Graham Inggs]

Source: ufw
Version: 0.36-7
Severity: serious
Tags: sid bullseye
User: debian-pyt...@lists.debian.org
Usertags: python3.9

Hi Maintainer

Ufw's autopkgtests fail with Python 3.9.  I've copied what I hope is
the relevant part of the log below.

It seems check-requirements [2] is choking on the version output:

$ python3.9 --version
Python 3.9.0+

Regards
Graham


[1] https://ci.debian.net/packages/u/ufw/testing/amd64/
[2] 
https://git.launchpad.net/ufw/tree/tests/check-requirements?h=debian/master#n50


==
FAIL: test_requirements (__main__.UfwTestAuto)
--
Traceback (most recent call last):
  File 
"/tmp/autopkgtest-lxc.6kixcwmt/downtmp/build.7ks/src/debian/tests/test-ufw.py",
line 243, in test_requirements
self.assertEqual(expected, rc, result + report)
AssertionError: 0 != 1 : Got exit code 1, expected 0
Has python: ERROR: could not find valid python
Has iptables: pass
Has ip6tables: pass


==
FAIL: test_requirements (__main__.UfwTestNft)
--
Traceback (most recent call last):
  File 
"/tmp/autopkgtest-lxc.6kixcwmt/downtmp/build.7ks/src/debian/tests/test-ufw.py",
line 243, in test_requirements
self.assertEqual(expected, rc, result + report)
AssertionError: 0 != 1 : Got exit code 1, expected 0
Has python: ERROR: could not find valid python
Has iptables: pass
Has ip6tables: pass


==
FAIL: test_requirements (__main__.UfwTestLegacy)
--
Traceback (most recent call last):
  File 
"/tmp/autopkgtest-lxc.6kixcwmt/downtmp/build.7ks/src/debian/tests/test-ufw.py",
line 243, in test_requirements
self.assertEqual(expected, rc, result + report)
AssertionError: 0 != 1 : Got exit code 1, expected 0
Has python: ERROR: could not find valid python
Has iptables: pass
Has ip6tables: pass


--
Ran 12 tests in 74.363s

FAILED (failures=3)
Adjusting tests for x86_64 container
autopkgtest [12:34:00]: test command1: ---]
autopkgtest [12:34:00]: test command1:  - - - - - - - - - - results -
- - - - - - - - -
command1 FAIL non-zero exit status 1

Bug#955994: [Pkg-xen-devel] Bug#955994: xen-utils-common: Could not start vif

[Hans van Kranenburg]

reassign 955994 src:xen
tags 955994 + pending
thanks

Hi Samuel,

On 4/5/20 9:14 PM, Samuel Thibault wrote:
> Package: xen-utils-common
> Version: 4.11.3+24-g14b62ab3e5-1
> Severity: normal
> Tags: patch
> 
> Hello,
> 
> I was having issues with starting domains with vif-nat: 
> 
> ♭ xl cr -c mydom
> Parsing config from mydom
> libxl: error: libxl_exec.c:117:libxl_report_child_exitstatus: 
> /etc/xen/scripts/vif-nat online [27191] exited with error status 1
> libxl: error: libxl_device.c:1286:device_hotplug_child_death_cb: script: 
> /etc/xen/scripts/vif-nat failed; error detected.
> libxl: error: libxl_create.c:1519:domcreate_attach_devices: Domain 25:unable 
> to add vif devices
> libxl: error: libxl_domain.c:1034:libxl__destroy_domid: Domain 
> 25:Non-existant domain
> libxl: error: libxl_domain.c:993:domain_destroy_callback: Domain 25:Unable to 
> destroy guest
> libxl: error: libxl_domain.c:920:domain_destroy_cb: Domain 25:Destruction of 
> domain failed
> 
> It happens that it seems that's merely because handle_iptable() does not
> pass a return value, and I guess the return value is thus that of the
> latest command, which may not be true, and that makes vif-nat fail. The
> attached patch fixes that.

Yes, you are completely right. Thanks for spotting this.

> [...]

I just added the explicit 0. I did not change the second return line,
since that code is unreachable anyway and it's patching upstream content.

https://salsa.debian.org/xen-team/debian-xen/-/commits/knorrie/sid

Thanks,
Hans

Bug#972821: ITS: python-crontab

[Michael Fladischer]

Hi,

I uploaded python-crontab-2.5.1-1 to DELAYED-7 yesterday. Once it hits 
the archive, I will upload a django-celery-beat package fixing the RC bug.


Am 09.11.2020 um 16:28 schrieb Mattia Rizzolo:

Might I ask you, in the meantime, go ahead and NMU the new release and
then fix django-celery-beat, while waiting for the salvage process time
to go through?

Bug#975911: mariadb-client: appears to ignore ~/.editrc keybind settings

[The Wanderer]

Package: mariadb-client
Version: 1:10.5.8-3
Severity: normal

Dear Maintainer,

I have just upgraded mariadb-client (and -server) from version 10.3.x to
version 10.5.8-3. As far as I can tell, no versions between those made
it into testing. If I'm not mistaken, the last version I was running
pre-upgrade was 10.3.24-2.

Prior to the upgrade, in an interactive session within the 'mysql'
terminal-based client, Ctrl+W would kill everything to the left of the
cursor up to the first word boundary (which in practice appeared to mean
"whitespace"), but nothing to the left of that point.

This is apparently not the default, but I have it configured in
~/.editrc. The contents of that file are as follows:

---8<---
bind "^U" vi-kill-line-prev
bind "^W" ed-delete-prev-word
---8<---

Following the upgrade and a restart of the client, in such an
interactive session, Ctrl+W now kills everything to the left of the
cursor, all the way to the beginning of the line. This appears to be the
default behavior, used when no alternate configuration has been applied.

It thus appears as if the settings I have in place in ~/.editrc are
simply being ignored. The environment variable EDITRC is not set.
Launching with it explicitly set does not appear to change anything.


I've found this behavior mentioned in a few places online. Nearly all of
them seem to advise resolving it by adding that Ctrl+W bind in
~/.editrc. The only one I've found thus far which indicates that doing
so does not change the behavior is

https://bugs.mysql.com/bug.php?id=95287

in which the solution found is to build with the internal libedit rather
than the system copy, which is obviously not suitable for Debian.

The only mentions of 'edit' in the relevant changelogs that I've found
are in those for mariadb-client-core-10.5. Version 1:10.4.12-1~exp2 has
an entry for "Link with libedit instead of readline5", and version
1:10.5.5-2 has one for "Add native dependencies on gnutls, libedit and
ncurses" (in relation to cross-compiling). I'd guess that the former is
the more relevant of the two, but I don't know for sure.

The installed version of libedit2 is 3.1-20191231-1. Based on the date,
I doubt that it was recently upgraded from an earlier version, but I
cannot testify to that for certain.


The only mention of ~/.editrc being ignored that I've managed to find
yet is a question on superuser.com from 2010, regarding ghci, which got
no answer.


I'm not sure whether the bug here is in mariadb-client or in libedit, or
even somewhere else, but this is clearly a behavior regression.

If the existing configuration through this file is supposed to continue
to be respected after the upgrade, please make appropriate adjustments
so that that happens.

If it is not, please explain and document what the correct method is for
applying such configuration.

If there is anything I can do to help track this down and get it
working, please let me know. I've tried strace, but failed to find
anything relevant thus far in the result; in particular, I find no
mention of the string 'editrc', although libedit.so.2 is apparently
read.


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

Kernel: Linux 5.9.0-2-amd64 (SMP w/12 CPU threads)
Kernel taint flags: TAINT_WARN
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: sysvinit (via /sbin/init)
LSM: AppArmor: enabled

Versions of packages mariadb-client depends on:
ii  mariadb-client-10.5  1:10.5.8-3

mariadb-client recommends no packages.

mariadb-client suggests no packages.

-- no debconf information

Bug#975910: Incompatible change on get_version() wanted?

[Sebastien Bacher]

Package: python-debian
Version:  0.1.38 

Hey there,

In the 0.1.38 update get_version() stopped working, since it's not a
documented change I was wondering if that's wanted. It's impacting some
code out there, see for example
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=973227
(I've been debugging a similar issue in Ubuntu with ubuntu-image).

The code change are easy to do but still it would be best to not break
existing code if possible

Cheers,

Bug#968362: Processed: closing 968362

[Niko Tyni]

Control: reopen -1
Control: found -1 0.33-3

On Thu, Nov 26, 2020 at 12:42:03PM +, Debian Bug Tracking System wrote:
 
> > # fixed in 0.33-3
> > close 968362
> Bug #968362 [src:libmaxmind-db-writer-perl] libmaxmind-db-writer-perl FTBFS 
> on big endian

Hi, this closure seems to be incorrect? 0.33-3 still failed
on the buildds on s390x, ppc64 and sparc64.

Reopening, but please let me know if I missed something.
-- 
Niko Tyni   nt...@debian.org

Bug#975909: linux-image-5.9.0-2-amd64: Kernel panic for unknown reason

[Dario Susman]

Package: src:linux
Version: 5.9.6-1
Severity: important

Dear Maintainer,

Caught this kernel panic from dmesg, I'm not sure what is this coming
from

[Tue Nov 24 11:01:01 2020] kernel BUG at fs/buffer.c:3351!
[Tue Nov 24 11:01:01 2020] invalid opcode:  [#1] SMP NOPTI
[Tue Nov 24 11:01:01 2020] CPU: 3 PID: 2035 Comm: freshclam Not tainted 
5.9.0-2-amd64 #1 Debian 5.9.6-1
[Tue Nov 24 11:01:01 2020] Hardware name: To be filled by O.E.M. To be filled 
by O.E.M./SABERTOOTH 990FX R2.0, BIOS 2901 05/04/2016
[Tue Nov 24 11:01:01 2020] RIP: 0010:free_buffer_head+0x42/0x50
[Tue Nov 24 11:01:01 2020] Code: 1c 22 06 01 e8 cf 08 f9 ff b8 01 00 00 00 65 
ff 0d 03 71 f4 61 65 0f c1 05 ff 70 f4 61 3d ff 0f 00 00 7e 05 e8 ff fe ff ff 
c3 <0f> 0b 66 66 2e 0f 1f 84 00 00 00 00 00 90 0f 1f 44 00 00 53 48 8b
[Tue Nov 24 11:01:01 2020] RSP: 0018:b779809a7b48 EFLAGS: 00010287
[Tue Nov 24 11:01:01 2020] RAX: 95975c8d8fb8 RBX: 95975c8d8f70 RCX: 
95975c8d8f70
[Tue Nov 24 11:01:01 2020] RDX: 85975c8d8fb8 RSI: 95975c8d8f70 RDI: 
95975c8d8f70
[Tue Nov 24 11:01:01 2020] RBP: dc8385719580 R08: 9f005c48 R09: 

[Tue Nov 24 11:01:01 2020] R10: 0001 R11:  R12: 
9597a8ddd884
[Tue Nov 24 11:01:01 2020] R13: 0001 R14: b779809a7c10 R15: 

[Tue Nov 24 11:01:01 2020] FS:  7ffb1c275980() 
GS:959836cc() knlGS:
[Tue Nov 24 11:01:01 2020] CS:  0010 DS:  ES:  CR0: 80050033
[Tue Nov 24 11:01:01 2020] CR2: 559f3ff08014 CR3: 000217a6e000 CR4: 
000406e0
[Tue Nov 24 11:01:01 2020] Call Trace:
[Tue Nov 24 11:01:01 2020]  try_to_free_buffers+0xa7/0x110
[Tue Nov 24 11:01:01 2020]  jbd2_journal_try_to_free_buffers+0x10c/0x160 [jbd2]
[Tue Nov 24 11:01:01 2020]  truncate_cleanup_page+0xa2/0xd0
[Tue Nov 24 11:01:01 2020]  truncate_inode_pages_range+0x1bb/0x7b0
[Tue Nov 24 11:01:01 2020]  ext4_evict_inode+0x14e/0x530 [ext4]
[Tue Nov 24 11:01:01 2020]  evict+0xd1/0x1a0
[Tue Nov 24 11:01:01 2020]  __dentry_kill+0xe4/0x180
[Tue Nov 24 11:01:01 2020]  dput+0x13c/0x360
[Tue Nov 24 11:01:01 2020]  do_renameat2+0x358/0x540
[Tue Nov 24 11:01:01 2020]  __x64_sys_rename+0x1f/0x30
[Tue Nov 24 11:01:01 2020]  do_syscall_64+0x33/0x80
[Tue Nov 24 11:01:01 2020]  entry_SYSCALL_64_after_hwframe+0x44/0xa9
[Tue Nov 24 11:01:01 2020] RIP: 0033:0x7ffb1c2e7e37
[Tue Nov 24 11:01:01 2020] Code: e8 fe 8c 09 00 85 c0 0f 95 c0 0f b6 c0 f7 d8 
5d c3 66 90 b8 ff ff ff ff 5d c3 66 0f 1f 84 00 00 00 00 00 b8 52 00 00 00 0f 
05 <48> 3d 00 f0 ff ff 77 01 c3 48 8b 15 29 60 16 00 f7 d8 64 89 02 b8
[Tue Nov 24 11:01:01 2020] RSP: 002b:7ffcab0e4338 EFLAGS: 0246 
ORIG_RAX: 0052
[Tue Nov 24 11:01:01 2020] RAX: ffda RBX: 559f416d6f00 RCX: 
7ffb1c2e7e37
[Tue Nov 24 11:01:01 2020] RDX:  RSI: 559f41734620 RDI: 
559f416de7c0
[Tue Nov 24 11:01:01 2020] RBP: 559f416de7c0 R08:  R09: 
7ffcab0e38b0
[Tue Nov 24 11:01:01 2020] R10: 7ffcab0e3764 R11: 0246 R12: 

[Tue Nov 24 11:01:01 2020] R13: 559f416de7c0 R14: 559f4174eec0 R15: 
559f41734620
[Tue Nov 24 11:01:01 2020] Modules linked in: xt_MASQUERADE nft_chain_nat 
nf_nat nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 tun bnep bluetooth 
jitterentropy_rng drbg ansi_cprng ecdh_generic ecc binfmt_misc uinput 
nft_counter ipt_REJECT nf_reject_ipv4 nft_compat nf_tables x_tables nfnetlink 
nfsd auth_rpcgss nfs_acl nfs lockd grace nfs_ssc fscache sunrpc xfs it87 
hwmon_vid loop parport_pc ppdev lp parport edac_mce_amd snd_hda_codec_realtek 
kvm_amd ccp snd_hda_codec_generic rng_core radeon ledtrig_audio 
snd_hda_codec_hdmi kvm snd_hda_intel snd_intel_dspcfg snd_hda_codec irqbypass 
ttm snd_hda_core eeepc_wmi snd_hwdep ghash_clmulni_intel drm_kms_helper 
asus_wmi snd_pcm battery evdev aesni_intel sparse_keymap cec libaes snd_timer 
crypto_simd rfkill cryptd snd sp5100_tco glue_helper video k10temp fam15h_power 
wmi_bmof mxm_wmi watchdog pcspkr soundcore drm sg i2c_algo_bit button ext4 
crc16 mbcache jbd2 btrfs blake2b_generic xor zstd_compress raid6_pq libcrc32c 
crc32c_generic hid_generic usbhid hid sr_mod cdrom
[Tue Nov 24 11:01:01 2020]  sd_mod t10_pi crc_t10dif crct10dif_generic ohci_pci 
xhci_pci crct10dif_pclmul crct10dif_common xhci_hcd ahci r8169 libahci 
crc32_pclmul ohci_hcd realtek ehci_pci mdio_devres ehci_hcd libata libphy 
crc32c_intel usbcore scsi_mod i2c_piix4 usb_common wmi
[Tue Nov 24 11:01:01 2020] ---[ end trace 4a30b8fe1b99df50 ]---
[Tue Nov 24 11:01:01 2020] RIP: 0010:free_buffer_head+0x42/0x50
[Tue Nov 24 11:01:01 2020] Code: 1c 22 06 01 e8 cf 08 f9 ff b8 01 00 00 00 65 
ff 0d 03 71 f4 61 65 0f c1 05 ff 70 f4 61 3d ff 0f 00 00 7e 05 e8 ff fe ff ff 
c3 <0f> 0b 66 66 2e 0f 1f 84 00 00 00 00 00 90 0f 1f 44 00 00 53 48 8b
[Tue Nov 24 11:01:01 2020] RSP: 0018:b779809a7b48 EFLAGS: 00010287
[Tue Nov 24 11:01:01 2020] RAX: 

Bug#974898: new release upstream fixed several problems

[Stefan Hornburg (Racke)]

On 11/26/20 1:47 PM, PICCORO McKAY Lenz wrote:
> seems do you not read the mails, several issues are solved upstream,
> but still are happened cos there's no new release. (not so difficult
> to make it)
> 
> same for courier, several bug reports are not taken in consideration
> (solved of course) and now today make a separate package for maildrop
> is nonsense cos is part of courier-mta suite.. it belongs to that
> suite, but upstream committed some of the requested features

The question is what the plan of the current maintainer is. He did
some work here: https://salsa.debian.org/debian/courier, but didn't do
an upload since the beginning of 2019.

Regards
   Racke

> 
> El jue, 26 de nov. de 2020 a la(s) 07:56, Josip Rodin
> (j...@debbugs.entuzijast.net) escribió:
>>
>>
>> Why are you posting these agitated bug reports? Can I suggest that you first
>> calm down and try to compose your thoughts, and then put that in writing
>> while bearing in mind that an assumption of good faith is the only proper
>> way to operate?
>>
>> On Mon, Nov 16, 2020 at 04:08:21AM -0400, PICCORO McKAY Lenz wrote:
>>> Package: maildrop
>>> Version: 2.9.3-2
>>> Severity: important
>>>
>>> The maildrop package in debian is severely out of sync and outdated:
>>>
>>> First of all stop of "Upstream is not willing to add another feature",
>>> seems people dont understan maildrop are made for courier, and if need
>>> can proposed a fork for that!
>>>
>>> Second: **several problems where aborted upstream**, the most
>>> important ones are:
>>> * libs/maildrop/deliver.C (delivery): Always return 75 upon
>>> delivery failure, for the standalone maildrop build. related to #481223
>>> * libs/maildir/maildirmake.c (main): maildirmake's -q option
>>> will create the maildir if it does not exist. related to #501557
>>> * libs/rfc2045/reformime.c (main2): Fix crash when the -s option is
>>> not valid. related to #71625
>>> * rfc2045/reformime.c (main2): fix crash if -x or -X is specified
>>> without the corresponding -s option. related to #71625
>>>
>>> A new maildrop pack is required and this must either come from the
>>> same courier sources (#867121) or update the one... this last seems
>>> quite stupid as courier is the official sources of maildrop and
>>> although it is offered separately by the author upstream, unifying it
>>> will improve maintenance from a team, and as you guys notice lack of
>>> interest/avaliable time in the courier suite (reading the last
>>> changelog, seems changes are more to complain with debian package
>>> policy that is innecesary respect real issues)
>>>
>>> ... and as far as I can see you are looking for the sources in sf
>>> instead of the right place which is the courier oficial download page,
>>> additional while the courier-mta sources are up to date in
>>> salsa-debian, the maildrop one in salsa-debian are too old respect the
>>> mta suite!
>>>
>>> while I made my own package on OBS vegnuli home for Devuan and Debian,
>>> is you guys need help i'm a often user of the complete suite and not
>>> just parts or toys of, maildrop can be build with two ways:
>>>  * set GID mail without restricted caller (maildrop)
>>>  * set UID root with restricted caller for courier-mta
>>>(maildrop-courier) -- missing and the way i set in my package cos
>>> is the need by the original suite the courier-mta
>>>
>>>
>>> NOTE: Courier maildrop in debian present a very not proper behaviour..
>>> original sources are from courier and any other implementation are
>>> non-related and users can fork the software, cases like #375589 are
>>> not valid cos seems maildrop (as author make it for courier filtering)
>>> is a courier implementation if applies! so any external specific usage
>>> are purely optional
>>>
>>> This are related to #910380 (separate makemime from sources) #204187,
>>> #596057 & #375589#26 (bad usage  cos is not made for), #481223
>>> (changed behaviour cos is not made for, what?), #592585 (dovecot
>>> specific crap) and go and go.. seems people thinks that maildrop are
>>> made for others rather than the courier suite... funny please close
>>> all of those package cos seems many of them are not supported by
>>> upstream and community must make a fork in those several cases!
>>>
>>> Lenz McKAY Gerardo (PICCORO)
>>> http://qgqlochekone.blogspot.com
>>
>> --
>> Josip Rodin
> 
> 


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



OpenPGP_signature
Description: OpenPGP digital signature