Bug#925826: shim: FTBFS w/ GCC 9 fix

[John Scott]

Control: tags -1 patch

Merge request with fix at https://github.com/rhboot/shim/pull/170

Bug#940463: fixed in falkon 3.1.0+dfsg1-4

[John Scott]

On Wed, 16 Oct 2019 10:00:15 + Georges Khaznadar  
wrote:
> Source: falkon
> Source-Version: 3.1.0+dfsg1-4
> 
> We believe that the bug you reported is fixed in the latest version of
> falkon, which is due to be installed in the Debian FTP archive.
> 
> A summary of the changes between this version and the previous one is
> attached.
> 
> Changes:
>  falkon (3.1.0+dfsg1-4) unstable; urgency=medium
>  .
>* Checked that falkon-3.1.0+dfsg1-3 does not crash.
>  Closes: #940463

Did a change to Falkon fix the issue, or is 3.1.0+dfsg-1-4 the same as 
3.1.0+dfsg-1-3? Was the submitter's issue resolved or were you unable to 
reproduce the crash?

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

Bug#933865: adb crashes on startup with SIGBUS

[John Scott]

Control: reassign -1 android-libboringssl/8.1.0+r23-1
Control: tags -1 upstream patch fixed-upstream
Control: retitle -1  adb crashes on startup with SIGBUS (armhf)
Control: forwarded -1 
https://boringssl.googlesource.com/boringssl/+/672f6fc2486745d0cabc3aaeb4e0a3cd13b37b12%5E%21/
Control: affects -1 adb
Control: severity -1 serious
(justification: it works on other architectures)

> A package android-libboringssl build with that patch applied could
> successfuly create the keys and did no crash on "adb devices" (just tested
> without a device connected).

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

Bug#946736: RM: defendguin -- RoM; questionable copyright status

[John Scott]

Package: ftp.debian.org
Severity: normal
X-Debbugs-CC: debian-rele...@lists.debian.org, n...@sonic.net
Control: block 934976 by -1

The maintainer and author acknowledges that the game uses Bill Gates's
likeness and likely non-free audio samples from the Defender arcade game
and requests that it be removed. See #934976

The package is in unstable, Buster, Stretch, and Jessie.

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

Bug#938511: solaar: Python 3 support

[John Scott]

Control: tags -1 fixed-upstream

I haven't been able to narrow it down to any particular release, but it 
appears that Solaar does support Python 3. See this issue adding support for 
Python 3.7 filed by the Fedora maintainer:
https://github.com/pwr-Solaar/Solaar/issues/447
And it looks to work with 3.8
https://apps.fedoraproject.org/packages/solaar/changelog/

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

Bug#943872: RM: fontypython -- ROM; No longer active upstream, Python 2 only

[John Scott]

Control: tags -1 - moreinfo

> There are rdepends that need to be addressed first:
> 
> Checking reverse dependencies...
> # Broken Depends:
> open-font-design-toolkit: open-font-design-toolkit

That doesn't look right; that's the same package. Is this a mistake?

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

Bug#940463: fixed in falkon 3.1.0+dfsg1-4

[John Scott]

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

If 3.1.0+dfsg1-4 doesn't have any changes from 3.1.0+dfsg1-3, why was it 
uploaded? That uses additional mirror space and rebuilds all of the packages. 
It also marks the bug as fixed in 3.1.0+dfsg1-4. Instead, if a bug isn't being 
fixed by a new upload, send the reason you're closing it to 940463-done@b.d.o  
with a Version: header reflecting if a version does have a fix.

> As my last e-mail tells, I "Checked that falkon-3.1.0+dfsg1-3 does not
> crash", which can be considered as being unable to reproduce the bug.
Bugs shouldn't be closed solely for being unreproducible. Instead, add the  
tags and contact the submitter. I see you might've been desperate to get 
Falkon back into testing since the upload was the same day it was removed. 
Bugs serious, grave, and critical cause removal, so I've downgraded the bug to 
normal.

> I got no reply from Xeno Idaltu , so I believe
> that either he is not using falkon again, or he installed falkon's new
> package and found the bug fixed.
Did you reply to him separately from the bug report? The log doesn't show 
anyone reaching out to him.

Additionally, I'm curious about this changelog entry
> falkon (3.1.0+dfsg1-5) unstable; urgency=medium
>   * removed the dependency on libgnome-keyring-dev, since this package
> is no longer part of Debian. Together with the upstream version
> change, this ... Closes: #943769
since #943769 doesn't appear to be related to GNOME Keyring.

I am also seeking to know why 3.1.0+dfsg1-3 has a +dfsg1-3 since the prior 
uploads were 3.0 and didn't have the +dfsg1. I haven't been able to find the 
reason for the change documented.

I haven't been able to reproduce the bug. However, I hope my suggestions are 
helpful for you and that I'll be able to help Falcon in this way.

Sincerely,
John Scott

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

Bug#946636: kmail: no progress bar when sending e-mails

[John Scott]

Control: tags -1 upstream

I'm not running KMail 19.08 at the moment so I can't check for sure, but this 
commit seems to suggest it's merely hidden by default now.
https://cgit.kde.org/kmail.git/commit/?id=d055c1bb

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

Bug#946618: DrKonqi handling large backtraces

[John Scott]

Control: forwarded -1 https://bugs.kde.org/show_bug.cgi?id=248807
Control: tags -1 patch fixed-upstream

Patch is at https://cgit.kde.org/drkonqi.git/commit/?id=c07434bf

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

Bug#941440: wxMaxima Pandoc problem

[John Scott]

wxMaxima FTBFS's for me with
$ pdf-engine /usr/bin/xelatex not known

I see that the 19.10.0 Debian package builds now by skipping the PDF manual 
when it can't be built. I think I've found the root of the problem with 
Pandoc.

It turns out this is a regression that's been there for ages and fixed in 
Pandoc 2.2.2 [1], just shy of the 2.2.1 version in Buster. wxMaxima doesn't 
build-dep on Pandoc and I'm building in a non-clean environment, but perhaps 
the following check done by CMake should be made aware of the Pandoc bug in 
the upstream part of wxMaxima by bumping the version:
-- pandoc version >= 2 found - using option --pdf-engine

https://github.com/jgm/pandoc/issues/4681#issuecomment-403617849



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

Bug#926618: RFP: webext-plasma-integration -- provides integration of web browsers with the Plasma desktop

[John Scott]

On Thu, 11 Apr 2019 11:30:43 -0400 Nicholas D Steeves  
wrote:
> I wonder if that package fulfills this RFP?  If not, and if this bug
> remains inactive for a month, please ping me and I'll take a look.
Ping :)

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

Bug#946365: kmail becomes unresponsive with active preview pane on wayland-plasma

[John Scott]

> Started kmail on wayland-plasma with active preview pane. The preview stays
> black at the beginning. When e.g.  hovering with the mouse over the preview,
Do you see a black rectangle like in the image I've attached? That is
https://bugs.kde.org/show_bug.cgi?id=397825 . If not, try to get a screenshot 
with Spectacle (it might not work unless you choose Full Screen or Current 
Screen).

> clicking on a different email or changing the folder the whole kmail
> software stops reacting and the title bar shows an unresponsive
> notification. No crash notification.
Have you tried using gdb to see what's going on? Do you get any output if you 
run KMail from a terminal emulator?

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

Bug#916076: [Retesting] kamoso: segmentation fault in GStreamer opening hamburger menu

[John Scott]

On Sat, 14 Dec 2019 22:55:17 +0100 Aurélien COUDERC  
wrote:
> Would you have the possibility to test again and comment here with more 
> information if the crash is still reproducible ?

Sure, I've attached a backtrace done with 'bt full' on the older version that 
looks more comprehensible. I've built Kamoso from source on Buster, so maybe 
the dependencies need to be tightened.

The new version fails to build from source for me, both on Buster and in an 
unstable pbuilder. Unfortunately it appears the buildd's are failing also:
https://buildd.debian.org/status/fetch.php?
pkg=kamoso=amd64=19.08.3-1=1576314481=0Starting program: /usr/bin/kamoso 
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
[New Thread 0x70963700 (LWP 17457)]
[New Thread 0x7fffeae3b700 (LWP 17458)]
[New Thread 0x7fffe995f700 (LWP 17460)]
[New Thread 0x7fffe33b2700 (LWP 17461)]
[New Thread 0x7fffe2bb1700 (LWP 17462)]
[New Thread 0x7fffe0e1f700 (LWP 17463)]
[New Thread 0x7fffcd9a9700 (LWP 17465)]
[New Thread 0x7fffcd1a8700 (LWP 17466)]
[New Thread 0x7fffc7fff700 (LWP 17467)]
[New Thread 0x7fffc77fe700 (LWP 17468)]
[New Thread 0x7fffc6ffd700 (LWP 17469)]
[New Thread 0x7fffc67fc700 (LWP 17470)]
[New Thread 0x7fffc5dc5700 (LWP 17472)]
[New Thread 0x7fffc55c4700 (LWP 17473)]
[New Thread 0x7fffc4dc3700 (LWP 17474)]
[New Thread 0x7fffa3fff700 (LWP 17475)]
[New Thread 0x7fffa37fe700 (LWP 17476)]
[New Thread 0x7fffa2ffd700 (LWP 17477)]
[New Thread 0x7fffa27fc700 (LWP 17478)]
[New Thread 0x7fffa1ffb700 (LWP 17479)]
[New Thread 0x7fffa17fa700 (LWP 17480)]
[New Thread 0x7fffa0ff9700 (LWP 17482)]
[New Thread 0x7fff83fff700 (LWP 17483)]
[New Thread 0x7fff837fe700 (LWP 17484)]
[New Thread 0x7fff82ffd700 (LWP 17485)]
[New Thread 0x7fff827fc700 (LWP 17486)]
[New Thread 0x7fff81ffb700 (LWP 17487)]
[New Thread 0x7fff817fa700 (LWP 17488)]
[New Thread 0x7fff80ff9700 (LWP 17489)]
[New Thread 0x7fff63fff700 (LWP 17490)]
[New Thread 0x7fff637fe700 (LWP 17491)]
[New Thread 0x7fff62ffd700 (LWP 17492)]
[New Thread 0x7fff627fc700 (LWP 17493)]
[New Thread 0x7fff61ffb700 (LWP 17494)]
[New Thread 0x7fff617fa700 (LWP 17495)]
[New Thread 0x7fff60ff9700 (LWP 17496)]
[New Thread 0x7fff5bfff700 (LWP 17497)]
[New Thread 0x7fff5b7fe700 (LWP 17498)]
[New Thread 0x7fff5affd700 (LWP 17499)]
[New Thread 0x7fff5a7fc700 (LWP 17500)]
[New Thread 0x7fff59ffb700 (LWP 17501)]
[New Thread 0x7fff597fa700 (LWP 17502)]
[New Thread 0x7fff58ff9700 (LWP 17503)]
[New Thread 0x7fff53fff700 (LWP 17504)]
[New Thread 0x7fff537fe700 (LWP 17505)]
[New Thread 0x7fff52ffd700 (LWP 17506)]
[New Thread 0x7fff527fc700 (LWP 17507)]
[New Thread 0x7fff51ffb700 (LWP 17508)]
[New Thread 0x7fff517fa700 (LWP 17509)]
[New Thread 0x7fff50ff9700 (LWP 17510)]
[New Thread 0x7fff507f8700 (LWP 17511)]
[New Thread 0x7fff4fff7700 (LWP 17512)]
[New Thread 0x7fff4f7f6700 (LWP 17513)]
[New Thread 0x7fff4eff5700 (LWP 17514)]
[New Thread 0x7fff4e7f4700 (LWP 17515)]
[New Thread 0x7fff4dff3700 (LWP 17516)]
[New Thread 0x7fff4d7f2700 (LWP 17517)]
[New Thread 0x7fff4cff1700 (LWP 17518)]
[New Thread 0x7fff4c7f0700 (LWP 17519)]
[New Thread 0x7fff4bfef700 (LWP 17520)]
[New Thread 0x7fff4b7ee700 (LWP 17521)]
[New Thread 0x7fff4afed700 (LWP 17522)]
[New Thread 0x7fff411eb700 (LWP 17523)]
[New Thread 0x7fff409ea700 (LWP 17524)]
[New Thread 0x7fff401e9700 (LWP 17525)]
[New Thread 0x7fff3f9e8700 (LWP 17526)]
[New Thread 0x7fff3f1e7700 (LWP 17527)]
[New Thread 0x7fff3e9e6700 (LWP 17528)]
[New Thread 0x7fff3e1e5700 (LWP 17529)]
[New Thread 0x7fff3c5e4700 (LWP 17533)]
[New Thread 0x7fff3bde3700 (LWP 17534)]
[New Thread 0x7fff3b5e2700 (LWP 17535)]
[New Thread 0x7fff317e0700 (LWP 17536)]
[New Thread 0x7fff30fdf700 (LWP 17537)]
[New Thread 0x7fff307de700 (LWP 17538)]

Thread 1 "kamoso" received signal SIGSEGV, Segmentation fault.
0x7fffe3cb58d8 in linear_to_ytiled (mem_copy_align16=, 
mem_copy=, swizzle_bit=0, src_pitch=20, 
src=0x7fffb4973440 "", dst=0x7ffe7681e000 "", y3=32, y0=21845, 
x3=, x2=16, x1=, x0=0)
at ../src/mesa/drivers/dri/i965/intel_tiled_memcpy.c:364
364 ../src/mesa/drivers/dri/i965/intel_tiled_memcpy.c: No such file or 
directory.
#0  0x7fffe3cb58d8 in linear_to_ytiled (mem_copy_align16=, 
mem_copy=, swizzle_bit=0, src_pitch=20, 
src=0x7fffb4973440 "", dst=0x7ffe7681e000 "", y3=32, y0=21845, 
x3=, x2=16, x1=, x0=0)
at ../src/mesa/drivers/dri/i965/intel_tiled_memcpy.c:364
xo = 
swizzle = 0
xo0 = 0
swizzle1 = 0
yo = 
bytes_per_column = 512
y1 = 
xo1 = 0
x = 0
column_width = 16
y2 = 32
swizzle0 = 0
column_width = 
bytes_per_column = 
y1 = 
y2 = 
xo0 = 
xo1 = 
swizzle0 = 
swizzle1 = 
x = 
yo = 
xo = 
swizzle = 
xo = 
swizzle = 
xo = 
swizzle = 
#1  linear_to_ytiled_faster (x0=0, x1=, x2=16, x3=, 

Bug#946722: opensc: broken documentation link in package description

[John Scott]

Source: opensc
Version: 0.19.0-1
Severity: normal

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

In the package descriptions OpenSC warns
 Before purchasing any cards, please read carefully documentation in
 /usr/share/doc/opensc/html/wiki/index.html

As best as I can tell, this file isn't provided by any package, not
even OpenSC. Even if the package did have the file, it seemed strange
to me that I was suggested to install the OpenSC package before
determining what smartcards would work with it.

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

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

- -- no debconf information

-BEGIN PGP SIGNATURE-

iHUEARMIAB0WIQQd3xxna2VescxVfdXYKFckL7guMwUCXfUW8wAKCRDYKFckL7gu
M+eOAQDBgTUVAhZGP3NJ2nHa+WzsANHLX0dV0egqj3J2MoHxiAEAj4p1JYmtDfHt
ND6vPkKVKW3AR8nXYUhPyjh9il5z9Uc=
=8Qy1
-END PGP SIGNATURE-

Bug#922574: digiKam FTBFS with OpenCV 4

[John Scott]

Control: forwarded -1 https://bugs.kde.org/show_bug.cgi?id=401306

This appears to have been fixed upstream. There are a couple patches there.

Bug#916076: kamoso: segmentation fault in GStreamer opening hamburger menu

[John Scott]

An easy way to reproduce it is by rapidly clicking the button while pressing 
escape to close the menu. I've attached a comprehensive backtrace. Help finding 
whatever package has the debugging symbols for /usr/lib/x86_64-linux-gnu/
libgstvideo-1.0.so.0.1404.0 would be appreciated.Application: Kamoso (kamoso), signal: Segmentation fault
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
[Current thread is 1 (Thread 0x7f45f6d1e800 (LWP 20083))]

Thread 73 (Thread 0x7f4537555700 (LWP 20193)):
#0  syscall () at ../sysdeps/unix/sysv/linux/x86_64/syscall.S:38
#1  0x7f45fca1df9f in g_cond_wait (cond=cond@entry=0x55860ef76ac0, 
mutex=mutex@entry=0x55860ef76ab8) at ../../../glib/gthread-posix.c:1402
#2  0x7f45ec1e468c in gst_base_sink_wait_preroll 
(sink=sink@entry=0x55860ef76990) at gstbasesink.c:2267
#3  0x7f45ec1e4c18 in gst_base_sink_do_preroll 
(sink=sink@entry=0x55860ef76990, obj=obj@entry=0x7f4568091d90) at 
gstbasesink.c:2361
#4  0x7f45ec1e531a in gst_base_sink_do_sync 
(basesink=basesink@entry=0x55860ef76990, obj=obj@entry=0x7f4568091d90, 
late=late@entry=0x7f45375548a0, step_end=step_end@entry=0x7f45375548a4) at 
gstbasesink.c:2564
#5  0x7f45ec1e6938 in gst_base_sink_chain_unlocked 
(basesink=basesink@entry=0x55860ef76990, obj=obj@entry=0x7f4568091d90, 
is_list=is_list@entry=0, pad=) at gstbasesink.c:3513
#6  0x7f45ec1e7c00 in gst_base_sink_chain_main (basesink=0x55860ef76990, 
pad=, obj=0x7f4568091d90, is_list=0) at gstbasesink.c:3672
#7  0x7f45fcb1bc3a in gst_pad_chain_data_unchecked (data=0x7f4568091d90, 
type=4112, pad=0x7f45e0432ce0) at gstpad.c:4322
#8  gst_pad_push_data (pad=pad@entry=0x5586100347f0, type=type@entry=4112, 
data=data@entry=0x7f4568091d90) at gstpad.c:4578
#9  0x7f45fcb23ed2 in gst_pad_push (pad=0x5586100347f0, 
buffer=0x7f4568091d90) at gstpad.c:4697
#10 0x7f45ec1f1dfd in gst_base_transform_chain (pad=, 
parent=0x55860fdc7f60, buffer=) at gstbasetransform.c:2321
#11 0x7f45fcb1bc3a in gst_pad_chain_data_unchecked (data=0x7f4568091950, 
type=4112, pad=0x558610034a40) at gstpad.c:4322
#12 gst_pad_push_data (pad=pad@entry=0x558610034100, type=type@entry=4112, 
data=data@entry=0x7f4568091950) at gstpad.c:4578
#13 0x7f45fcb23ed2 in gst_pad_push (pad=0x558610034100, 
buffer=0x7f4568091950) at gstpad.c:4697
#14 0x7f45ec1f1dfd in gst_base_transform_chain (pad=, 
parent=0x55860fdc7ab0, buffer=) at gstbasetransform.c:2321
#15 0x7f45fcb1bc3a in gst_pad_chain_data_unchecked (data=0x7f4568091ea0, 
type=4112, pad=0x7f45f0021910) at gstpad.c:4322
#16 gst_pad_push_data (pad=pad@entry=0x7f45f0021b60, type=type@entry=4112, 
data=data@entry=0x7f4568091ea0) at gstpad.c:4578
#17 0x7f45fcb23ed2 in gst_pad_push (pad=0x7f45f0021b60, 
buffer=buffer@entry=0x7f4568091ea0) at gstpad.c:4697
#18 0x7f45d1a72b69 in gst_image_freeze_src_loop (pad=0x7f45f0021b60) at 
gstimagefreeze.c:799
#19 0x7f45fcb50f41 in gst_task_func (task=0x7f45745f9950) at gsttask.c:332
#20 0x7f45fc9fcdb3 in g_thread_pool_thread_proxy (data=) at 
../../../glib/gthreadpool.c:307
#21 0x7f45fc9fc415 in g_thread_proxy (data=0x7f45dc004ad0) at 
../../../glib/gthread.c:784
#22 0x7f45fa426fa3 in start_thread (arg=) at 
pthread_create.c:486
#23 0x7f45fad364cf in clone () at 
../sysdeps/unix/sysv/linux/x86_64/clone.S:95

Thread 72 (Thread 0x7f4541357700 (LWP 20192)):
#0  __gst_fast_write_swap32 (v=4279271552, p=0x7f450826 "") at 
/usr/include/gstreamer-1.0/gst/gstutils.h:207
#1  gst_geometric_transform_transform_frame (vfilter=0x55860fdb5df0, 
in_frame=0x7f45413564b0, out_frame=0x7f4541356750) at 
gstgeometrictransform.c:249
#2  0x7f45ec25fe03 in ?? () from /lib/x86_64-linux-gnu/libgstvideo-1.0.so.0
#3  0x7f45ec1f2609 in default_generate_output (trans=0x55860fdb5df0, 
outbuf=0x7f4541356a60) at gstbasetransform.c:2132
#4  0x7f45ec1f1cd6 in gst_base_transform_chain (pad=, 
parent=0x55860fdb5df0, buffer=) at gstbasetransform.c:2285
#5  0x7f45fcb1bc3a in gst_pad_chain_data_unchecked (data=0x7f45783217a0, 
type=4112, pad=0x7f45d4048810) at gstpad.c:4322
#6  gst_pad_push_data (pad=pad@entry=0x558610029310, type=type@entry=4112, 
data=data@entry=0x7f45783217a0) at gstpad.c:4578
#7  0x7f45fcb23ed2 in gst_pad_push (pad=0x558610029310, 
buffer=0x7f45783217a0) at gstpad.c:4697
#8  0x7f45ec1f1dfd in gst_base_transform_chain (pad=, 
parent=0x55860ed8d8d0, buffer=) at gstbasetransform.c:2321
#9  0x7f45fcb1bc3a in gst_pad_chain_data_unchecked (data=0x7f451f4afea0, 
type=4112, pad=0x7f45e0433ac0) at gstpad.c:4322
#10 gst_pad_push_data (pad=pad@entry=0x7f45e0433d10, type=type@entry=4112, 
data=data@entry=0x7f451f4afea0) at gstpad.c:4578
#11 0x7f45fcb23ed2 in gst_pad_push (pad=0x7f45e0433d10, 
buffer=buffer@entry=0x7f451f4afea0) at gstpad.c:4697
#12 0x7f45d1a72b69 in gst_image_freeze_src_loop (pad=0x7f45e0433d10) at 
gstimagefreeze.c:799
#13 0x7f45fcb50f41 in gst_task_func (task=0x7f45745f93b0) at gsttask.c:332
#14 

Bug#928710: drkonqi segfaults

[John Scott]

Control: tags -1 patch

They have a two line patch that fixes this upstream
https://phabricator.kde.org/D21801

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

Bug#946618: drkonqi: please support large backtraces

[John Scott]

Package: drkonqi
Version: 5.14.5-1
Severity: minor
Tags: upstream

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

I have tried to report a bug in Kamoso just now, but unfortunately my
backtrace is so huge Dr. Konqi doesn't like it. At 'Sending the Crash Report'
it says

Error sending the crash report: /Received unexpected error code 114 from
bugzilla. Error message was: Comments cannot be longer than 65535 characters../

When this happens, it should instead send it as an attachment or find another
way.

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

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

Versions of packages drkonqi depends on:
ii  kio   5.54.1-1
ii  libc6 2.28-10
ii  libkf5completion5 5.54.0-1
ii  libkf5configcore5 5.54.0-1+deb10u1
ii  libkf5configgui5  5.54.0-1+deb10u1
ii  libkf5configwidgets5  5.54.0-1
ii  libkf5coreaddons5 5.54.0-1
ii  libkf5crash5  5.54.0-1
ii  libkf5i18n5   5.54.0-1
ii  libkf5idletime5   5.54.0-1
ii  libkf5jobwidgets5 5.54.0-1
ii  libkf5kiocore55.54.1-1
ii  libkf5notifications5  5.54.0-1
ii  libkf5service-bin 5.54.0-1
ii  libkf5service55.54.0-1
ii  libkf5wallet-bin  5.54.0-1
ii  libkf5wallet5 5.54.0-1
ii  libkf5widgetsaddons5  5.54.0-1
ii  libkf5xmlrpcclient5   5.54.0-1
ii  libqt5core5a  5.11.3+dfsg1-1+deb10u2
ii  libqt5dbus5   5.11.3+dfsg1-1+deb10u2
ii  libqt5gui55.11.3+dfsg1-1+deb10u2
ii  libqt5widgets55.11.3+dfsg1-1+deb10u2
ii  libqt5x11extras5  5.11.3-2
ii  libqt5xml55.11.3+dfsg1-1+deb10u2
ii  libstdc++68.3.0-6

drkonqi recommends no packages.

drkonqi suggests no packages.

- -- no debconf information

-BEGIN PGP SIGNATURE-

iHUEARMIAB0WIQQd3xxna2VescxVfdXYKFckL7guMwUCXfGdsQAKCRDYKFckL7gu
M8aDAP40UV9SytavbQn/AoNCX5Xbcd7XKNiLoHxH2muanyTz+AEAnvVfa385HDbg
C8fiCzpDBBTo+8q5ZxM/Sii2whlHOgE=
=Jb6c
-END PGP SIGNATURE-

Bug#936270: Please fix calibre, or get it out of Debian

[John Scott]

On Mon, 14 Oct 2019 16:05:04 +0200 Thomas Goirand  wrote:
>  it wont change the fact that Python2 is being removed from Bullseye 
because it's dead upstream on the 1st of January next year.

That's not a fact, Bullseye can still ship with Python 2 if needed
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=931659#17

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

Bug#877106: pinta: Pinta 1.6-2 crashes on image scaling and other image manipulation.

[John Scott]

This bug has been open for a while and blocks Pinta getting into Debian 
Bullseye. Can you confirm whether or not you can still reproduce this issue?

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

Bug#897777: kvmtool: ftbfs with GCC 8

[John Scott]

Control: tags -1 fixed-upstream

I think this is fixed upstream. I found these commits that seem to be related:
https://git.kernel.org/pub/scm/linux/kernel/git/will/kvmtool.git/commit/?id=05755b29
https://git.kernel.org/pub/scm/linux/kernel/git/will/kvmtool.git/commit/?id=96eda741
https://git.kernel.org/pub/scm/linux/kernel/git/will/kvmtool.git/commit/?id=eaeaf608

The last commit doesn't appear to be necessary to build with GCC 8, but it is
the only additional error that was in Reproducible Builds's build with GCC 9.
This might be sufficient to build with that too.

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

Bug#936740: ipe-tools supports Python 3

[John Scott]

Control: tags -1 fixed-upstream

It looks like the current releases use Python 3 for svgtoipe now
https://github.com/otfried/ipe-tools/commit/60ccc014

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

Bug#925758: librecad: ftbfs with GCC-9

[John Scott]

Control: forwarded -1 https://github.com/LibreCAD/LibreCAD/pull/
Control: tags -1 upstream fixed-upstream ftbfs

This has been fixed upstream. The change is at
https://github.com/shawncurry/LibreCAD/commit/3bc93383

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

Bug#937099: mypaint Python 3 support

[John Scott]

Control: tags -1 fixed-upstream

MyPaint has released their first 2.0 beta with Python 3 support. The 
announcement suggests it's stable and it could use testing to find any 
remaining bugs.
See https://github.com/mypaint/mypaint/releases/tag/v2.0.0-beta.0

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

Bug#940839: Same bug with 2.4.4

[John Scott]

Hello,

> Same situation here with openshot 2.4.4 from debian sid. I have an intel 
gpu.
OpenShot 2.4.4 isn't in Debian Sid yet. Where did you install it from?


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

Bug#940839: openshot-qt crashes immidiately

[John Scott]

Are you still able to reproduce this bug? In your logs I noticed the following
> Debian Release: bullseye/sid
>   APT prefers stable-updates
>   APT policy: (500, 'stable-updates'), (500, 'testing'), (500, 'stable'),
>   (110, 'unstable')> 
> Architecture: amd64 (x86_64)

It looks like you have a mixture of stable, bullseye, and unstable packages 
and that might provoke this. Do you know how this happened?

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

Bug#944616: emacs: FTBFS on mips64el, mipsel

[John Scott]

Has anyone been working on this?

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

Bug#944227: transition: prompt-toolkit

[John Scott]

It appears that bugs haven't been filed to get reverse dependencies depending 
on version 1 out of testing.

Britney [1] says
> trying: prompt-toolkit
> skipped: prompt-toolkit (39, 2, 91)
> 
> got: 26+0: a-1:a-0:a-0:a-0:i-17:m-0:m-7:p-0:s-1
> * mipsel: caffe-cpu, python3-caffe-cpu, python3-guiqwt,
> python3-line-profiler, python3-pyraf, python3-sfepy, python3-yt
and so since these binaries are still in Bullseye, prompt-toolkit isn't going 
to be migrating until they're removed.

I'm only an interested user and may be misunderstanding. Could you file these 
bugs or help me understand what I'm overlooking?
[1] https://release.debian.org/britney/update_output.txt

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

Bug#948940: Merge requests for FTBFS in Qt/KDE packages

[John Scott]

I have now prepared merge requests for fixing ktp-common-internals, 
ktp-accounts-kcm,
and kaccounts-providers respectively [1] [2] [3]. These issues are all fixed in
new upstream releases, but I am not comfortable with such an undertaking and
hope these fixes will suffice in the meantime.

[1] 
https://salsa.debian.org/qt-kde-team/kde/ktp-common-internals/-/merge_requests/1
[2] 
https://salsa.debian.org/qt-kde-team/kde/kaccounts-providers/-/merge_requests/2
[3] https://salsa.debian.org/qt-kde-team/kde/ktp-accounts-kcm/-/merge_requests/1

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

Bug#953187: kinfocenter: should recommend or suggest samba

[John Scott]

Source: kinfocenter
Severity: normal

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

The Samba status monitor dialog is blank and says
 Error run smbstatus: execve: No such file or directory

As the samba package description points out, Samba users need not have this
package installed, so at least a Suggests would help users know it's needed.

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

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

- -- debconf-show failed

-BEGIN PGP SIGNATURE-

iHUEARYIAB0WIQT287WtmxUhmhucNnhyvHFIwKstpwUCXmEovAAKCRByvHFIwKst
px8LAQCFR8tK/2r+srBOUe+TW07D9O4Fl5+Z9qA0eB5KkamKvwEAk9U+rImR2Abl
dDkX7rd5O71F7xYbwlrE0fAJEZzL2Aw=
=5vuv
-END PGP SIGNATURE-

Bug#952060: libsignon-glib FTBFS: a few non-trivial ways to fix

[John Scott]

This is caused by GLib => 2.58 which was uploaded in September 2018 long ago.

Likewise, libsignon-glib 1.12 lags behind upstream substantially.
It's 2.1 and the disparity causes the patch to not apply.

A cheap workaround might be to add a -Wno-error like is already done for
some other deprecated functions. (That has since been fixed upstream proper.)

But in version 1.13, the NEWS file says
* Build: don't emit a build error on deprecations
so perhaps to fix this "cleanly" without such a leap, this avenue may be
most suitable (perhaps 1.15).

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

Bug#946959: RFS: coreboot/4.10-1 [ITP] -- Coreboot firmware utilities

[John Scott]

> > If there really is a problem with those files I would appreciate your
> > letting me know what I missed. Otherwise I hope you can avoid the 
> > repacking trouble in the future.
> Probably not, but the repacking is not trouble.

Without a good reason, you really shouldn't repack [1]. I do not understand 
your motivation for removing those files since they don't end up in the binary 
packages.

Repacking means that you, collaborators, and volunteers working on quality 
assurance can't
* use tools like uupdate to upgrade to a new upstream version very easily
* can't verify the tarball against upstream's signature
* package those parts being removed from Coreboot later on without duplicating 
effort into another source package

Perhaps you're not aware that it is typical to disregard parts of the package 
that aren't built (yet). Otherwise I would like to know what advantage it has 
for my own potential applications, and you should explain in debian/copyright 
how the source differs [2].

> You can save you that pain. I already stole your watch file, now it
> says:
> E: coreboot source: debian-watch-file-pubkey-file-is-missing

I thought I had sent a merge request, but seeing no trace I must not have. I 
wanted it to have an explanation of how to modify the watch file to do the 
repacking for you.
It's necessary to put the Coreboot team's minimal OpenPGP
key in debian/upstream/signing-key.asc, and I didn't do it because of the 
sensitivity of the key material. The wiki [3] explains what you need to do, 
and to determine the key you need, GnuPG will say or complain which if you try 
verifying the tarball.

[1] https://perl-team.pages.debian.net/howto/repacking.html#0._INTRODUCTION
[2] https://wiki.debian.org/BenFinney/software/repack
[3] https://wiki.debian.org/debian/watch#Cryptographic_signature_verification

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

Bug#949986: kaddressbook: chokes querying unresponsive LDAP server for eternity

[John Scott]

Package: kaddressbook
Version: 4:19.08.3-1
Severity: normal

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Filing against KAddressBook for now since I don't know what broke.
Steps to reproduce:
 1) do `nc -l -p 1999` to start a dummy LDAP server
 2) in KAddressBook, go to Settings -> Configure KAddressBook... ->
LDAP Server Settings -> Add Host... and then
Host: localhost,  Port: 1999,  LDAP version: 3, and Security either TLS or SSL.

Thereafter the other options don't make a difference, so 3) Query Server
and KAddressBook will hang. The Cancel button won't work, and setting Time 
limit:
prior doesn't make a difference either.

If one stops the dummy server, KAddressBook resumes, otherwise it hangs forever.
gdb gets me the backtrace below.

#0  0x7f47447ccd0f in __GI___poll (fds=0x563ec90f7cb4, nfds=1, timeout=-1) 
at ../sysdeps/unix/sysv/linux/poll.c:29
#1  0x7f473edc47b9 in poll (__timeout=, __nfds=, __fds=) at /usr/include/x86_64-linux-gnu/bits/poll2.h:46
#2  ldap_int_select (ld=ld@entry=0x563ec8d06700, timeout=timeout@entry=0x0) at 
os-ip.c:1136
#3  0x7f473edaeced in wait4msg (ld=ld@entry=0x563ec8d06700, 
msgid=msgid@entry=1, all=all@entry=1, timeout=, 
timeout@entry=0x0, result=result@entry=0x7ffc7afecf50) at result.c:315
#4  0x7f473edaff54 in ldap_result (ld=ld@entry=0x563ec8d06700, msgid=1, 
all=all@entry=1, timeout=timeout@entry=0x0, result=result@entry=0x7ffc7afecf50) 
at result.c:120
#5  0x7f473edb31b8 in ldap_extended_operation_s 
(ld=ld@entry=0x563ec8d06700, reqoid=reqoid@entry=0x7f473ec4 
"1.3.6.1.4.1.1466.20037", reqdata=reqdata@entry=0x0, sctrls=sctrls@entry=0x0, 
cctrls=cctrls@entry=0x0, retoidp=retoidp@entry=0x7ffc7afecfb8, 
retdatap=0x7ffc7afecfc0) at extended.c:159
#6  0x7f473edd3d86 in ldap_start_tls_s (ld=0x563ec8d06700, 
serverctrls=serverctrls@entry=0x0, clientctrls=clientctrls@entry=0x0) at 
tls2.c:1050
#7  0x7f47417ccf1f in KLDAP::LdapConnection::connect (this=0x563ec8d3e450) 
at ./src/ldapconnection.cpp:335
#8  0x7f47417d7661 in LdapSearchPrivate::connect (this=0x563ec8a89580) at 
./src/ldapsearch.cpp:186
#9  0x7f47417d9aab in KLDAP::LdapSearch::search 
(this=this@entry=0x7ffc7afed170, url=..., count=count@entry=0) at 
./src/ldapsearch.cpp:312
#10 0x7f47417de8f9 in KLDAP::LdapConfigWidget::Private::sendQuery 
(this=this@entry=0x563ec8ba0370) at ./src/ldapconfigwidget.cpp:377
#11 0x7f47417df11c in KLDAP::LdapConfigWidget::Private::queryDNClicked 
(this=0x563ec8ba0370) at ./src/ldapconfigwidget.cpp:420
#12 0x7f4744d37528 in QtPrivate::QSlotObjectBase::call (a=0x7ffc7afed310, 
r=0x563ec8b653a0, 
this=0x563ec8abb680) at 
../../include/QtCore/../../src/corelib/kernel/qobjectdefs_impl.h:394
#13 QMetaObject::activate (sender=0x563ec8abb220, signalOffset=, 
local_signal_index=, argv=) at 
kernel/qobject.cpp:3783
#14 0x7f47457fb312 in QAbstractButton::clicked 
(this=this@entry=0x563ec8abb220, _t1=) at 
.moc/moc_qabstractbutton.cpp:312
#15 0x7f47457fb52a in QAbstractButtonPrivate::emitClicked 
(this=0x563ec8abb260) at widgets/qabstractbutton.cpp:414
#16 0x7f47457fc8cf in QAbstractButtonPrivate::click (this=0x563ec8abb260) 
at widgets/qabstractbutton.cpp:407
#17 0x7f47457fca95 in QAbstractButton::mouseReleaseEvent 
(this=0x563ec8abb220, e=0x7ffc7afed880) at widgets/qabstractbutton.cpp:1011
#18 0x7f474574a786 in QWidget::event (this=0x563ec8abb220, 
event=0x7ffc7afed880) at kernel/qwidget.cpp:8965
#19 0x7f4745708c32 in QApplicationPrivate::notify_helper 
(this=this@entry=0x563ec84e60c0, receiver=receiver@entry=0x563ec8abb220, 
e=e@entry=0x7ffc7afed880) at kernel/qapplication.cpp:3700
#20 0x7f47457123e3 in QApplication::notify (this=, 
receiver=0x563ec8abb220, e=0x7ffc7afed880) at kernel/qapplication.cpp:3160
#21 0x7f4744d0ca92 in QCoreApplication::notifyInternal2 
(receiver=0x563ec8abb220, event=0x7ffc7afed880) at 
../../include/QtCore/../../src/corelib/kernel/qobject.h:142
#22 0x7f47457114f3 in QApplicationPrivate::sendMouseEvent 
(receiver=receiver@entry=0x563ec8abb220, event=event@entry=0x7ffc7afed880, 
alienWidget=alienWidget@entry=0x563ec8abb220, nativeWidget=0x7ffc7afee140, 
buttonDown=buttonDown@entry=0x7f4745c2b8d0 , 
lastMouseReceiver=..., spontaneous=true, onlyDispatchEnterLeave=false) at 
kernel/qapplication.cpp:2646
#23 0x7f4745766049 in QWidgetWindow::handleMouseEvent (this=0x563ec8b92750, 
event=0x7ffc7afedd00) at /usr/include/c++/9/bits/atomic_base.h:413
#24 0x7f4745768ed4 in QWidgetWindow::event (event=0x7ffc7afedd00, 
this=0x563ec8b92750) at kernel/qwidgetwindow.cpp:281
#25 QWidgetWindow::event (this=0x563ec8b92750, event=0x7ffc7afedd00) at 
kernel/qwidgetwindow.cpp:224
#26 0x7f4745708c32 in QApplicationPrivate::notify_helper 
(this=this@entry=0x563ec84e60c0, receiver=receiver@entry=0x563ec8b92750, 
e=e@entry=0x7ffc7afedd00) at kernel/qapplication.cpp:3700
#27 0x7f4745712190 in QApplication::notify (this=0x7ffc7aff01d0, 
receiver=0x563ec8b92750, 

Bug#949237: ktp-accounts-kcm FTBFS fixed upstream

[John Scott]

Control: forwarded 949237 https://phabricator.kde.org/D25370
Control: tags 949237 patch fixed-upstream

This was caused by the new telepathy-qt and the patch suffices for it to build 
on my system. #949239 in ktp-contacts-runner looks to be the same issue, but 
its git log is much less decipherable and doesn't show any change aside from 
version bumps.
https://cgit.kde.org/ktp-contact-runner.git/

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

Bug#949236: ktp-common-internals FTBFS fixed upstream

[John Scott]

Control: forwarded -1 https://phabricator.kde.org/D25269
Control: tags -1 fixed-upstream patch
Control: reassign 949238 src:ktp-common-internals
Control: reassign 949239 src:ktp-common-internals
Control: forcemerge -1 949238 949239
Control: affects -1 + src:ktp-text-ui
Control: affects -1 + src:ktp-contact-runner

It seems that telepathy-qt 0.9.8 broke several packages and is the cause of 
#949236–949240. Fixing ktp-common-internals #949236 allows the latter two 
(ktp-text-ui and ktp-contact-runner) to build.

I plan to prepare a merge request in the coming days.

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

Bug#948940: kaccounts-providers FTBFS fixed upstream

[John Scott]

Control: forwarded -1 
https://cgit.kde.org/kaccounts-providers.git/commit/?id=fd6b3ebf
Control: tags -1 patch fixed-upstream

This was caused by the newer version of Qt and builds with the patch.

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

Bug#920147: Sage FTBFS on mipsel + mips64el

[John Scott]

On the off-chance they're relevant and Jmol is a red herring, I'm re-sending
my misplaced comments [1] about relevant parts of /usr/bin/sage here:

> By the way, looking at the header of that file I see
>  # workaround #892622; unfortunately we can't simply run setarch -R when 
> running Singular
>  # because src/sage/libs/singular/singular.pyx loads libsingular.so into the 
> current process
>  if [ "$(arch)" = "mips64" -a -z "$SAGE_DEB_MIPS64_WORKAROUND" ]; then
> SAGE_DEB_MIPS64_WORKAROUND=1 exec setarch mips64 -R "$0" "$@"
>  fi
> 
> I don't understand the test inside the brackets. Why do you use -a [in
> addition to the -z] when there is no mention of a file? And if you're
> checking equality, shouldn't that be a double equals sign (==)?
> 
> Furthermore, the code refers to mips64, but #892622 refers to mips64el. Is
> it possible these issues are the cause of Sage failing to build from source
> there (#920147)?
[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=948731#12

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

Bug#859066: linux-image-*: recommend free firmware-ath9k-htc

[John Scott]

The live images include firmware-ath9k-htc now, see #934522.

By the way, being unaware of this bug at the time I filed #900171, that 
firmware-free should recommend firmware-ath9k-htc. This reflects the logical 
relationship better, but it's a trivial difference and I wonder which would be 
preferred.

Bug#938632: Teeworlds Python 3

[John Scott]

It appears Teeworlds has been using Python 3 for at least the past year: 
https://github.com/teeworlds/teeworlds/commit/9bd2a2d98681add573e7e356eef361fde2ccd082

Bug#951398: pax.jar FTBFS: issue introduction

[John Scott]

Hello,

pax.jar seems to exist in version 2019.20191208-1 as well. If someone could 
affirm this is not an issue introduced with the new upload, could one set this 
bug as being found in 2019.20191208-1? This would enable the transition to 
testing.

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

Bug#950608: gmp 6.2.0 crashes postgresql-pgmp (& others)

[John Scott]

On February 23, 2020 3:11:46 PM EST, Marco Bodrato  
wrote:
>Ciao,
>
>Il Dom, 9 Febbraio 2020 9:34 pm, Steven Robbins ha scritto:
>> On Sunday, February 9, 2020 9:54:02 A.M. CST Marco Bodrato wrote:
>>> So, if the new release of the library is able to answer that the number
>>> 387047 is prime, and not only "probably" prime... This should not be
>>> marked as a regression...
>>
>> Indeed!  Thanks for investigating.  An improvement could be simply that
>
>> Is there a bug for libmath-gmp-perl for this test suite issue?
>
>It seems to me that all packages incorrectly using the internal
>representation and not the documented interface of GMP where patched.
>
>What else stops migration of GMP to testing? Maybe a release of GMP
>explicitly saying that it breaks:
> libmath-gmp-perl < 2.20
> libmath-prime-util-gmp-perl < 0.51-2
> postgresql-pgmp < 1.0.4
>is needed? So that nobody will update the library without updating also
>the other possibly failing packages?
>
>Ĝis,
>m
>

GMP is not migrating because this bug was marked as done by uploading 
postgresql-pgmp. However, this bug is filed against GMP, so the bug metadata 
still suggests that GMP 6.2.0 introduces this serious issue.

Bug#951674: kalzium: molecular editor is not available

[John Scott]

Source: kalzium
Severity: normal
Control: forwarded -1 https://bugs.kde.org/show_bug.cgi?id=416856

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

I haven't narrowed down in what version this changed, but in Kalzium the
Molecular Editor button appears to be greyed out on the toolbar. Invoking
Kalzium with --molecule and pointing to a file seems to have no effect
regardless of whether it exists.

Trying to build the current version yields
- -- Kalzium molecular editor disabled
and
- -- Checking for module 'openbabel-2.0>=2.2.0'
- --   No package 'openbabel-2.0' found
CMake Warning at CMakeLists.txt:30 (find_package):
  By not providing "FindAvogadroLibs.cmake" in CMAKE_MODULE_PATH this project
  has asked CMake to find a package configuration file provided by
  "AvogadroLibs", but CMake did not find one.

  Could not find a package configuration file provided by "AvogadroLibs" with
  any of the following names:

AvogadroLibsConfig.cmake
avogadrolibs-config.cmake

  Add the installation prefix of "AvogadroLibs" to CMAKE_PREFIX_PATH or set
  "AvogadroLibs_DIR" to a directory containing one of the above files.  If
  "AvogadroLibs" provides a separate development package or SDK, be sure it
  has been installed.

screenshots.debian.net seems to suggest that it was working in previous
versions, however.

Avogadro, Eigen 3, and OpenBabel 2 are the dependencies needed to build it.
Since unstable has OpenBabel 3, upstream will need to port to that first,
which is the forwarded bug.

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

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

- -- no debconf information

-BEGIN PGP SIGNATURE-

iHUEARYIAB0WIQT287WtmxUhmhucNnhyvHFIwKstpwUCXk3GJwAKCRByvHFIwKst
p3PcAQCFhfrrJZZ3GU8+sMkGdmR4NiANk+NjDCS6qEsycdRr5AEA9iwl7oC5zTRW
Mu/BFpJGXJXUciY2CHv4qIrDZFT16g0=
=ND90
-END PGP SIGNATURE-

Bug#951592: sagemath-common: SyntaxWarnings setting up sagemath-common

[John Scott]

Package: sagemath-common
Version: 9.0-1
Severity: normal

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On upgrading to the new version in Buster, I've gotten these warnings during
installation:

Setting up sagemath-common (9.0-1) ...
/usr/lib/python3/dist-packages/sage/combinat/root_system/branching_rules.py:1753:
 SyntaxWarning: "is not" with a literal. Did you mean "!="?
  if len(stypes) is not 2:
/usr/lib/python3/dist-packages/sage/graphs/graph_latex.py:1159: SyntaxWarning: 
'str' object is not callable; perhaps you missed a comma?
  raise TypeError('%s option must be a dictionary, not %s' (name, value))
/usr/lib/python3/dist-packages/sage/graphs/graph_latex.py:1168: SyntaxWarning: 
'str' object is not callable; perhaps you missed a comma?
  raise TypeError('%s option must be a dictionary, not %s' (name, value))
/usr/lib/python3/dist-packages/sage/graphs/graph_latex.py:1175: SyntaxWarning: 
'str' object is not callable; perhaps you missed a comma?
  raise TypeError('%s option must be a dictionary, not %s' (name, value))
/usr/lib/python3/dist-packages/sage/graphs/graph_latex.py:1182: SyntaxWarning: 
'str' object is not callable; perhaps you missed a comma?
  raise TypeError('%s option must be a dictionary, not %s' (name, value))
/usr/lib/python3/dist-packages/sage/graphs/graph_latex.py:1189: SyntaxWarning: 
'str' object is not callable; perhaps you missed a comma?
  raise TypeError('%s option must be a dictionary, not %s' (name, value))
/usr/lib/python3/dist-packages/sage/graphs/graph_latex.py:1196: SyntaxWarning: 
'str' object is not callable; perhaps you missed a comma?
  raise TypeError('%s option must be a dictionary, not %s' (name, value))
/usr/lib/python3/dist-packages/sage/graphs/graph_latex.py:1203: SyntaxWarning: 
'str' object is not callable; perhaps you missed a comma?
  raise TypeError('%s option must be a dictionary, not %s' (name, value))

Fortunately this appears to be a cosmetic issue, but creates a lot of
noise and I can't discern its meaning.

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

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

Versions of packages sagemath-common depends on:
ii  python3  3.7.5-3

sagemath-common recommends no packages.

sagemath-common suggests no packages.

- -- debconf-show failed

-BEGIN PGP SIGNATURE-

iHUEARYIAB0WIQT287WtmxUhmhucNnhyvHFIwKstpwUCXkwEIAAKCRByvHFIwKst
p2S0AP9UYGdJ4INOLiisNpKn8n3SNJb8Bx24Rx+Wr6EFcPR8+QEA0BBPqBud0jmw
Fj37PXhBlgyMP7F3tnzn+3GBc3MzVQg=
=E945
-END PGP SIGNATURE-

Bug#932597: konqueror: Some sites with SSL don't work (negotiation fails)

[John Scott]

This still affects 19.08.2, but strangely doesn't affect Falkon.

I see Falkon depends on libssl1.1 but Konqueror doesn't. Could that be what 
makes the difference?

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

Bug#944476: LKRG Debian packaging completed

[John Scott]

> I am not a Debian Developer (DD). This needs a DD to be uploaded to
> packages.debian.org.

If you are still looking for someone that can upload this for you, file a bug
against sponsorship-requests and block this bug by that one.

Bug#948731: Solution to the bug : one-liner change

[John Scott]

On Thu, 16 Jan 2020 17:36:21 +0100 Julien Puydt  
wrote:
> I fixed the brial package which was the culprit for the missing
> symbols, and can confirm that what is needed is only :
>
> modify env.py so SAGE_SCRIPTS_DIR points to /usr/share/sagemath/bin 

If SAGE_SCRIPTS_DIR were set to that directory in /usr/bin/sagemath, then I 
believe it would fix my bug #948731 about sage -v and sage --root not working.

Looking at the shell script, it seems sage-env is only sourced after checking 
for -v, --root, and --advanced, and that might be the cause of my issue. I 
would appreciate if you would take a look.

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

Bug#948731: [regression] sage -v doesn't work again

[John Scott]

Package: sagemath-common
Version: 8.9-3
Severity: normal
Control: affects -1 cantor-backend-sage

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

I previously reported this as #923166 and it was fixed in 8.6-6. It seems
it's come back: sage -v says
/usr/bin/sage: line 16: /src/bin/sage-version.sh: No such file or directory

I noticed this trying to use Cantor with Sage as I did then. Fortunately
the new version of Cantor doesn't crash anymore and says instead
 Failed to determine the version of Sage. Please check your installation and
 the output of 'sage -v'.

I thought this worked fine with 8.9-2, but maybe not.
The cause seems to be that Sage's root isn't set: sage --root gives no output.

Unfortunately I'm not familiar with it yet, otherwise I would like to help set
up an autopkgtest. However, 'sage -v' returns 0, so maybe the shebang
should be changed to
 #!/usr/bin/env bash -e
to catch errors.

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

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

Versions of packages sagemath-common depends on:
ii  python3  3.7.5-3

sagemath-common recommends no packages.

sagemath-common suggests no packages.

- -- no debconf information

-BEGIN PGP SIGNATURE-

iHUEARYIAB0WIQT287WtmxUhmhucNnhyvHFIwKstpwUCXhtOsgAKCRByvHFIwKst
p7L+AQD5kP+i5iESpAlUfBACKihBwCbzVwlWlt16FPE9LiciywEAiXf8NgBYLNdP
3W2PE0VREGdRcB4auwAMrJ09PnSmbAQ=
=gUwb
-END PGP SIGNATURE-

Bug#948731: /usr/bin/sage shell script

[John Scott]

By the way, looking at the header of that file I see
# workaround #892622; unfortunately we can't simply run setarch -R when 
running Singular
# because src/sage/libs/singular/singular.pyx loads libsingular.so into the 
current process
if [ "$(arch)" = "mips64" -a -z "$SAGE_DEB_MIPS64_WORKAROUND" ]; then
SAGE_DEB_MIPS64_WORKAROUND=1 exec setarch mips64 -R "$0" "$@"
fi

I don't understand the test inside the brackets. Why do you use -a when there 
is no mention of a file? And if you're checking equality, shouldn't that be a 
double equals sign (==)?

Furthermore, the code refers to mips64, but #892622 refers to mips64el. Is it 
possible these issues are the cause of Sage failing to build from source there 
(#920147)?

smime.p7s
Description: S/MIME cryptographic signature

Bug#947388: anki: Ctrl+Enter not working in Debian Buster KDE

[John Scott]

On Thu, 2 Jan 2020 15:46:53 + Julian Gilbey  wrote:
> > I'm using Anki w/ Plasma on Bullseye, and Ctrl+Enter works as expected on
> > both X11 and Wayland. So this does seem Buster-specific.
> Thanks John, that's really helpful to know.  Are you using KDE?
Plasma is the name of KDE's desktop environment. I believe that's what the 
submitter meant. It would take a very powerful computer to run the entire KDE 
software suite at once 
And by the way, I don't think it's been said explicitly that this only affects 
KDE Plasma yet. Rahul didn't specify if he tried another desktop environment 
and I'm not running Buster to try.

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

Bug#947388: anki: Ctrl+Enter not working in Debian Buster KDE

[John Scott]

On Thu, 02 Jan 2020 19:25:39 +0530 ra...@amaram.name wrote:
> It might be worth checking out in bullseye if the problem exists as well.
I'm using Anki w/ Plasma on Bullseye, and Ctrl+Enter works as expected on both 
X11 and Wayland. So this does seem Buster-specific.


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

Bug#946327: khotkeys FTBFS

[John Scott]

Control: forwarded -1 
https://salsa.debian.org/qt-kde-team/kde/khotkeys/merge_requests/2
Control: tags -1 patch

This is fixed in KHotKeys 5.15.1. Alternatively, I've submitted a merge request
to enable a potential new upload of 5.14.5 with the patch.


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

Bug#948098: RM: blogilo -- FTBFS, uninstallable, abandoned upstream

[John Scott]

Package: release.debian.org
User: release.debian@packages.debian.org
Usertags: rm
X-Debbugs-CC: debian-qt-...@lists.debian.org, he...@debian.org

Please remove Blogilo from unstable. It's been broken since Oct. 2018 when it 
couldn't be built for a KDE PIM transition and its dependencies are 
unsatisfiable. At the bug [1] Sandro Knauß wrote
> blogilo in is dead by upstream since 17.08. and pino made it compiling for
> 17.12. But now with 18.08 there are more issues get it compiling. I filed a
> bug against blogilo that it can't be compiled with new 18.08 [#908869].

> I recommend to delete blogilo from testing. Do I need to file a own RM
> request or is [#908869] enough for you to delete it from testing?
This question went unanswered and seemed to have been forgotten, so I'm filing 
this bug and CC'ing them for their awareness. 

[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=909288#51

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

Bug#948098: RM: blogilo -- FTBFS, uninstallable, abandoned upstream

[John Scott]

Control: reassign -1 ftp.debian.org

On Friday, January 3, 2020 4:20:00 PM EST you wrote:
> Unstable, or testing? The former is FTP team's balliwick, not Release.
Unstable. Thanks for the quick catch!

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

Bug#947955: general: Windows on second (external) screen are blurry after notebook sleep

[John Scott]

>> If you still need me to test with different desktop environments: which o ne
>> would you suggest? I'd prefer one that is easy to install AND remove after 
>> the test.
> I don't know other wayland-based desktops than gnome, so I leave this
> question to others :)
It's not easy to add or remove because it might pull in a lot of big packages, 
but KDE Plasma has fair support for Wayland provided by by plasma-workspace-
wayland.

You're probably looking for Weston which is much smaller.
You can try it by installing the weston package, going to a TTY 
(e.g. Ctrl+Alt+F3), log in, and type weston-launch. Then you should be able to 
open a terminal emulator and start other applications if you want to.
When you're done you can close Weston with Ctrl+Alt+Backspace and try 
Ctrl+Alt+F1 through F7 until you get back to GNOME/GDM again.


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

Bug#920589: CoqIDE supports GTK 3

[John Scott]

Control: unblock -1 885677
Control: forwarded -1 https://github.com/coq/coq/pull/9279
Control: tags -1 fixed-upstream

Unfortunately CoqIDE wasn't rebuilt for Buster. CoqIDE 8.10 supports lablgtk3 
though so it can be reintroduced

Bug#946327: khotkeys FTBFS: fixed upstream

[John Scott]

Control: tags -1 fixed-upstream

The package builds with the following two commits applied in order:
https://cgit.kde.org/khotkeys.git/diff/?id=67fd8f06
https://cgit.kde.org/khotkeys.git/diff/?id=ae574373

The former one makes many changes, but appears to be related only due to 
removing a blank line in a file, so that change could probably be consolidated.

A naive uscan and uupdate got me to 5.17.4. With no additional changes this 
builds fine in sbuild, so maybe a new release would be more convenient.

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

Bug#919903: Package wxWidgets 3.1

[John Scott]

Control: reassign 935141 libwxgtk3.0-0v5 3.0.4+dfsg-8
Control: affects 935141 wxmaxima

It appears that my trouble with wxMaxima is probably fixed in wxWidgets 3.1.2 
and I'd like to give it a try.

> It's not ABI stable, so it's just not suitable for packaging.  Every new
> 3.1.x release would mean a transition for everything built against it.
> Even if we only uploaded to experimental with the aim to support local
> builds, a new upload would break everyone's locally built applications.

Upstream appears adamant that it's ready to deploy:
> Please notice that while 3.1.3 is officially a “development” version because
> it is not fully compatible with the “stable” 3.0.x, the list of backwards
> incompatible changes is very short, so you shouldn’t have any problems
> updating to this version from 3.0.x in practice, and you’re encouraged to
> use this release, including in production.

I hope you'll reconsider uploading to experimental.

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

Bug#916076: kamoso: segmentation fault in GStreamer opening hamburger menu

[John Scott]

Control: tags -1 moreinfo

I've upgraded to Bullseye and I'm still able to reproduce it. I've attached 
new backtraces: one from gdb and a longer one from Dr. Konqi#0  0x7fffdf974af3 in linear_to_ytiled (mem_copy_align16=, 
mem_copy=, swizzle_bit=,
src_pitch=,
src=0x7fffe02dbb90 "89A\377@>I\377\071\067B\377,+/\377\035\034 
\377\035\033\032\377%#\"\377+$$\377'  \377'\036 
\377*!#\377+!%\377-#'\377\061(*\377\066-/\377\062,*\377-'%\377)!\037\377&\036\034\377%\035\033\377&\036\034\377*\"
 \377,$\"\377+#!\377*\" \377$\033\033\377)  \377*!!\377)  
\377*!!\377-$$\377/&'\377-$%\377\061*+\377*#$\377' 
!\377+$%\377-&'\377,%&\377\061(*\377\063*,\377\063*,\377\063)+\377\062(*\377\061&*\377/$(\377/!&\377.
 %\377(!\"\377*#$\377"..., dst=, y3=, 
y0=, x3=, x2=,
x1=, x0=) at 
../src/intel/isl/isl_tiled_memcpy.c:369
xo = 0
swizzle = 0
xo0 = 
swizzle1 = 
yo = 128
bytes_per_column = 
y1 = 
xo1 = 
x = 
column_width = 
y2 = 
swizzle0 = 
column_width = 
bytes_per_column = 
y1 = 
y2 = 
xo0 = 
xo1 = 
swizzle0 = 
swizzle1 = 
x = 
yo = 
xo = 
swizzle = 
xo = 
swizzle = 
xo = 
swizzle = 
#1  linear_to_ytiled_faster (x0=0, x1=0, x2=128, x3=128, y0=y0@entry=0, 
y1=y1@entry=32, dst=0x7ffe6180 
"Wfd\377Sb_\377Ra^\377_li\377\275\265\257\377\262\255\250\377\306\301\274\377\357\354\351\377KUT\377MWV\377Q[Z\377Q[Z\377HEM\377IGK\377DBF\377HGI\377;MG\377;MG\377:LF\377\071KE\377\026\026\026\377\023\023\023\377\023\023\023\377\023\023\023\377\274\262\252\377\301\272\265\377\327\320\313\377\352\353\347\377LY[\377IWW\377JXX\377GUU\377\070\071A\377@>I\377\071\067B\377,+/\377",
 src=0x7fffe02bbb90 
"Wfd\377Sb_\377Ra^\377_li\377`mj\377JRU\377\062:=\377\062\065C\377F\377\070\071A\377\070;E\377:=G\377:?I\377J\377\071>J\377\066;G\377\063\070D\377\062\065C\377\064\067E\377\070;I\377:=K\377:;I\377<>J\377;=I\377\070:F\377\063\065A\377./=\377*+9\377+)8\377,*9\377,*9\377-+:\377\060,;\377\061-<\377\061->\377\061->\377\062.?\377\063/@\377/+8\377/+8\377-)8\377+'6\377"...,
 src_pitch=16384, swizzle_bit=0, copy_type=ISL_MEMCPY) at 
../src/intel/isl/isl_tiled_memcpy.c:684
mem_copy = 
#2  0x7fffdf978698 in intel_linear_to_tiled (copy_type=ISL_MEMCPY, 
tiling=ISL_TILING_Y0, has_swizzling=false, src_pitch=16384, dst_pitch=16384, 
src=, dst=, yt2=128, yt1=0, xt2=16384, xt1=0) at 
../src/intel/isl/isl_tiled_memcpy.c:899
x0 = 
y1 = 
x2 = 
y0 = 
x3 = 128
x1 = 
yt0 = 0
yt3 = 128
tw = 128
th = 32
span = 
tile_copy = 0x7fffdf974a10 
xt = 
xt0 = 0
xt3 = 16384
yt = 
swizzle_bit = 0
tile_copy = 
xt0 = 
xt3 = 
yt0 = 
yt3 = 
xt = 
yt = 
tw = 
th = 
span = 
swizzle_bit = 
x0 = 
y0 = 
x3 = 
y1 = 
x1 = 
x2 = 
#3  _isl_memcpy_linear_to_tiled (xt1=0, xt2=16384, yt1=yt1@entry=0, 
yt2=yt2@entry=128, dst=dst@entry=0x7ffe6170 
"||z\377}}{\377}}{\377wwu\377fge\377fge\377dfb\377dfb\377`c_\377bba\377ddc\377iih\377[^Z\377\\_[\377]`\\\377]`\\\377nnm\377kki\377mmk\377oom\377\203\203|\377\200\200y\377\200\200y\377\202\202{\377`ba\377bdc\377fhg\377hih\377JLL\377LNN\377OQQ\377RTT\377`g\\\377[bW\377Z`Y\377bha\377vvu\377ppo\377ppo\377vvu\377\205\206\202\377\210\210\202\377\210\210\202\377\211\211\203\377gjf\377dfb\377egc\377fhd\377ffd\377gge\377"...,
 src=src@entry=0x7fffe01bbb90 
"||z\377}}{\377}}{\377wwu\377}}{\377}}{\377~~|\377\177\177}\377{{y\377z|x\377wyu\377vxq\377xzs\377|~v\377}\177w\377y|q\377{\177r\377|\200s\377~\177u\377~\177u\377~\177u\377}~t\377zzs\377|\200u\377z~s\377y{s\377wyq\377xxr\377||v\377\207\204\201\377~{x\377|yv\377|zt\377~|v\377~~w\377}}v\377|\177t\377vvo\377xxq\377zzs\377}}v\377\200\201w\377\203\205y\377\203\205y\377\177\201u\377}\177s\377|}s\377}~t\377\201\201z\377\200\200y\377"...,
 dst_pitch=16384, src_pitch=16384, has_swizzling=false, tiling=ISL_TILING_Y0, 
copy_type=ISL_MEMCPY) at ../src/intel/isl/isl_tiled_memcpy_normal.c:44
No locals.
#4  0x7fffdf9689a5 in isl_memcpy_linear_to_tiled (xt1=, 
xt2=, yt1=yt1@entry=0, yt2=yt2@entry=128, 
dst=dst@entry=0x7ffe6170 
"||z\377}}{\377}}{\377wwu\377fge\377fge\377dfb\377dfb\377`c_\377bba\377ddc\377iih\377[^Z\377\\_[\377]`\\\377]`\\\377nnm\377kki\377mmk\377oom\377\203\203|\377\200\200y\377\200\200y\377\202\202{\377`ba\377bdc\377fhg\377hih\377JLL\377LNN\377OQQ\377RTT\377`g\\\377[bW\377Z`Y\377bha\377vvu\377ppo\377ppo\377vvu\377\205\206\202\377\210\210\202\377\210\210\202\377\211\211\203\377gjf\377dfb\377egc\377fhd\377ffd\377gge\377"...,
 src=src@entry=0x7fffe01bbb90 

Bug#946959: RFS: coreboot/4.10-1 -- Coreboot firmware utilities

[John Scott]

The package is in great shape. The only challenge to getting the package in 
the archive seems to be the copyright file. Coreboot's README says
> Some files are licensed under the "GPL (version 2, or any later version)",
> and some files are licensed under the "GPL, version 2". For some parts,
> which were derived from other projects, other (GPL-compatible) licenses may 
apply. Please check the individual source files for details.

debian/copyright says most files are GPL 2+, but it my digging indicates the 
majority are GPL 2 only, and I think I saw additional licenses too.

I believe upstream has recently expressed desire to make listings files with 
respective licenses and/or using SPDX identifiers, rather than their lengthy 
headers in the source. If that's true, checking out the Git version might help 
you parse the licenses.

Speaking of which, you repacked Coreboot with the contents of 3rdparty/ 
removed. As a Libreboot user I thought I understood why, but as best as I can 
tell those files are free. On Coreboot's downloads page they appear to 
distribute the blobs separately which is news to me.

If there really is a problem with those files I would appreciate your letting 
me know what I missed. Otherwise I hope you can avoid the repacking trouble in 
the future.

Lastly, a small enhancement is to add a debian/watch file so that tools can 
check for and utilize new upstream versions automagically. I plan to send a 
Salsa merge request with details shortly.

I hope my feedback is useful for you to help your package.

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

Bug#851109: Emscripten violates font license

[John Scott]

Control: forwarded -1 https://github.com/emscripten-core/emscripten/issues/10146
Control: block 939477 by -1

I've reported this upstream since they're still using it.

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

Bug#809997: emscripten not installable on Debian/testing...

[John Scott]

Control: forwarded -1 https://github.com/emscripten-core/emscripten/issues/5488
Control
> The problem is that emscripten uses a fork of LLVM and I am reluctant to add
> yet-a-new-version of llvm in the archive...
> I have been waiting for the changes to be merged upstream and, with the
> recent progress on webassembly, we are getting there...

I haven't tried it, but it appears they enabled using Web Assembly with 
upstream LLVM in October.

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

Bug#936481: Emscripten supports Python 3

[John Scott]

Control: forwarded -1 https://github.com/emscripten-core/emscripten/issues/5950
Control: tags -1 fixed-upstream

It appears it still supports Python 2 also for the time being
https://github.com/emscripten-core/emscripten/issues/7198

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

Bug#945588: RFS: lutris/0.5.4-1 -- open source gaming platform for GNU/Linux

[John Scott]

I'm not a DD and can't sponsor packages, but I hope my feedback can be helpful 
for you.

I see Lutris bundles python-distro. This is available in Debian, so the 
package should use it rather than installing a bundled copy. Debian's 
Winetricks should be used also.
Since Winetricks is in contrib, depending or recommending it means that Lutris 
needs to go to contrib or non-free also.

Lutris's description mentions Linux. Does it use any Linux-specific 
functionality, or should it build and work on other kenels like the Hurd and 
kFreeBSD also? If so the Architecture: any is fine.

I see from the TODO and your GitHub issue that you're aware of the copyright 
problems, but as the package currently stands it's not suitable even for non-
free.
Files: share/lutris/icons/hicolor/symbolic/apps/nintendods-symbolic.svg
Copyright: Nintendo
License: none-wikipedia
Comment: from 

Files: share/lutris/icons/hicolor/symbolic/apps/sonyplaystation-symbolic.svg
Copyright: Sony Interactive Entertainment
License: none-wikipedia
Comment: from 

License: none-wikipedia
 This image consists only of simple geometric shapes or text. It does not meet
 the threshold of originality needed for copyright protection, and is 
therefore
 in the public domain.

Does upstream get the images from Wikimedia Commons? These logos are almost 
surely encumbered by copyright and/or trademark issues and can't go in main. 
Wikimedia Commons holds neither the copyright nor trademark and Lutris 
shouldn't go on the editors' words. See the disclaimer
> Other restrictions may apply. These may include trademarks,
> patents, personality rights, moral rights, privacy rights, or any of the
> many other legal causes which are independent of copyright and vary greatly
> by jurisdiction.
It's inconceivable that permission from Nintendo and Sony was obtained.
But actually the Flaticon icons are worst of all and keep this from going even 
in non-free:

License: Flaticon
 From :
 What you CANNOT DO:
  -Distribute Flaticon's Contents unless it has been expressly authorized 
by Flaticon.
  -Include Flaticon's Contents in an online or offline database or file.
  -Offering Flaticon's Contents designs (or modified Flaticon Contents versions)
   for download.

...but I just downloaded them. And as though it couldn't be any worse:
  "The complete content of licenses can be consulted in the Terms of Use, that
  will prevail over the content of this document."
so that isn't the license anyway.

That's problematic and I don't see any 'explicit authorization,' so I've 
reported this issue upstream at https://github.com/lutris/lutris/issues/2573
and hope it will be taken care of.

With respect to the Debian-specific parts, the packaging looks good and I hope 
my feedback helps you tackle your last few challenges.

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

Bug#877106: pinta: Pinta 1.6-2 crashes on image scaling and other image manipulation.

[John Scott]

> Yes, it still crashes after opening any of images and trying to edit it or
> just usin program GUI.

If you had sent mail to the bug report before, it seems you're using a 
different email address now and I don't know if you have sent any debugging 
information before. Regardless, the following should be helpful.

Can you run `reportbug -p --template pinta` and send back the system 
information that appears at the bottom of that? The output of `lscpu` might 
would also be helpful.

How do you invoke Pinta? Do you use a command in a terminal to start it or 
click it from a menu? What does `mono -V` say? Do you use GNOME 3?
Do you use any non-default graphics drivers, and does
`mono /usr/lib/pinta/Pinta.exe --render-threads=1` fare any better?

Are you usually working with a saved file when it crashes, and if you are, does 
opening a new window with an unsaved document make a difference?

Sorry to bombard you with questions, but I hope these details shed light on 
the issue so you can figure out this puzzle.

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

Bug#951891: open-ath9k-htc-firmware FTBFS with binutils 2.34

[John Scott]

> thank you!
> 
> I updated the package.

Hi,

I see you've fixed this upstream. firmware-ath9k-htc has been removed from
Bullseye, could you use some help with a new Debian package?

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

Bug#954228: apt should be able to install packages from files on disk

[John Scott]

>   dima@fatty:~$ sudo apt install /tmp/gnuplot-data_5.2.8+dfsg1-2dima1_all.deb
>   ...
>   Note, selecting 'gnuplot-data' instead of 
> '/tmp/gnuplot-data_5.2.8+dfsg1-2dima1_all.deb'
> 
> So apt recognized that I asked it to install a file on disk, but
> instead of using that file, it decided to install the same package
> from the repo.

I think the message is quite misleading. Despite what the note says, using
apt install ./*.deb to install packages has worked for me for a while,
including recently. Perhaps you should check again?


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

Bug#955762: okular: missing runtimeqtspeech5 dependencies inhibit text-to-speech

[John Scott]

Package: okular
Version: 4:19.12.3-2
Severity: normal
Tags: a11y

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

As remarked on this blog post [1] that tremendously helped me, Okular doesn't
complain if you try using the text-to-speech features without the necessary
libraries installed. It only shows on the CLI
  No text-to-speech plug-ins were found.

The necessary packages are qtspeech5-speechd-plugin and/or
qtspeech5-flite-plugin. The Okular docs say that the former is used by default,
so maybe do something like
Suggests/Recommends: qtspeech5-speechd-plugin | qtspeech5-flite-plugin

Neither of them have reverse dependencies yet it seems.
$ apt-cache rdepends qtspeech5-speechd-plugin
qtspeech5-speechd-plugin
Reverse Depends:
  qtspeech5-speechd-plugin-dbgsym

[1] 
https://www.ubuntubuzz.com/2018/12/text-to-speech-on-gnulinux-part-2-okular-to-speech.html

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

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

Versions of packages okular depends on:
ii  kinit 5.62.0-1+b1
ii  kio   5.62.1-2+b1
ii  libc6 2.30-4
ii  libfreetype6  2.10.1-2
ii  libjpeg62-turbo   1:1.5.2-2+b1
ii  libkf5activities5 5.62.0-1+b2
ii  libkf5archive55.62.0-1
ii  libkf5bookmarks5  5.62.0-1+b1
ii  libkf5codecs5 5.62.0-1
ii  libkf5completion5 5.62.0-1+b1
ii  libkf5configcore5 5.62.0-1+b1
ii  libkf5configgui5  5.62.0-1+b1
ii  libkf5configwidgets5  5.62.0-1+b1
ii  libkf5coreaddons5 5.62.0-1
ii  libkf5crash5  5.62.0-1+b1
ii  libkf5i18n5   5.62.0-1
ii  libkf5iconthemes5 5.62.0-1+b1
ii  libkf5itemviews5  5.62.0-1+b1
ii  libkf5jobwidgets5 5.62.0-1+b1
ii  libkf5kexiv2-15.0.0   19.08.1-1+b2
ii  libkf5kiocore55.62.1-2+b1
ii  libkf5kiowidgets5 5.62.1-2+b1
ii  libkf5parts5  5.62.0-1+b1
ii  libkf5pty55.62.0-1
ii  libkf5purpose-bin 5.62.0-2+b1
ii  libkf5purpose55.62.0-2+b1
ii  libkf5service-bin 5.62.0-1
ii  libkf5service55.62.0-1
ii  libkf5textwidgets55.62.0-1+b1
ii  libkf5wallet-bin  5.62.0-1+b1
ii  libkf5wallet5 5.62.0-1+b1
ii  libkf5widgetsaddons5  5.62.0-1+b1
ii  libkf5windowsystem5   5.62.0-3
ii  libkf5xmlgui5 5.62.0-1+b1
ii  libokular5core9   4:19.12.3-2
ii  libphonon4qt5-4   4:4.11.1-3
ii  libpoppler-qt5-1  0.71.0-6
ii  libqca-qt5-2  2.2.1-2
ii  libqmobipocket2   4:17.08.3-2+b1
ii  libqt5core5a  5.12.5+dfsg-9
ii  libqt5dbus5   5.12.5+dfsg-9
ii  libqt5gui55.12.5+dfsg-9
ii  libqt5printsupport5   5.12.5+dfsg-9
ii  libqt5svg55.12.5-2
ii  libqt5texttospeech5   5.12.5-1
ii  libqt5widgets55.12.5+dfsg-9
ii  libqt5xml55.12.5+dfsg-9
ii  libspectre1   0.2.8-2
ii  libstdc++610-20200324-1
ii  phonon4qt54:4.11.1-3
ii  zlib1g1:1.2.11.dfsg-2

Versions of packages okular recommends:
ii  cups-bsd  2.3.1-11

Versions of packages okular suggests:
ii  ghostscript9.52~dfsg-1
ii  okular-extra-backends  4:19.12.3-2
ii  poppler-data   0.4.9-2
ii  texlive-binaries   2019.20190605.51237-3
pn  unrar  

- -- no debconf information

-BEGIN PGP SIGNATURE-

iHUEARYIAB0WIQT287WtmxUhmhucNnhyvHFIwKstpwUCXojJOwAKCRByvHFIwKst
p7qpAQCwpxgyEJfgoOMWfpOVPg+Plc+8fyE3f6FRZ0Eru4QFjQEAgfqdrRE+wmne
6IjEzJ8qlJTJeiVmHdY9NUb2dybc0wU=
=zvtR
-END PGP SIGNATURE-

Bug#945404: Information

[John Scott]

Just a random thought: maybe it has to do with Buster using LVM2 by default. 
I'm reproducing this on a system installed as Buster also

Bug#951592: sagemath-common: SyntaxWarnings setting up sagemath-common

[John Scott]

Control: affects -1 python3-sagetex

Upgrading to 9.0-3 and installing SageTeX says
Setting up python3-sagetex (3.4+ds-1) ...
/usr/lib/python3/dist-packages/sagetexparse.py:135: SyntaxWarning: "is not" 
with a literal. Did you mean "!="?
  if t.format is not '':


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

Bug#944167: gcc-mingw-w64 builds with gcc 9

[John Scott]

Control: fixed -1 22~exp1

It builds with gcc 9 now, but deferring to leave this bug open since it's in
experimental and not on its way to Bullseye yet.

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

Bug#932597: some sites with SSL don't work; reassigning to Qt

[John Scott]

Control: reassign -1 src:qtwebengine-opensource-src
Control: affects -1 konqueror kaccounts-config

I've now noticed this appears to affect kaccounts-config also. I'm still
unable to identify the specific cause of the bug, but my attempts to get
at it with gdb indicate the culprit is probably Qt (not necessarily
QtWebEngine).

I wonder if anyone else can reproduce this or would have a hint?

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

Bug#955271: libreoffice-common: AppArmor profile blocks gpg's tofu.db, causes hang opening Options

[John Scott]

Package: libreoffice-common
Version: 1:6.4.1-1
Severity: minor
User: pkg-apparmor-t...@lists.alioth.debian.org
Usertags: buggy-profile
Control: affects -1 gpg

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

The AppArmor profile doesn't allow reading GnuPG's tofu.db:
apparmor="DENIED" operation="file_lock" profile="libreoffice-soffice//gpg" 
name="/home/john/.gnupg/tofu.db" pid=94210 comm="gpg" requested_mask="k" 
denied_mask="k" fsuid=1000 ouid=1000

This does have a material impact. Opening Tools -> Options makes LibreOffice
and GnuPG hang indefinitely. The latter excessively uses the CPU, but
LibreOffice resumes when it is killed.

This is observed in 1:6.4.2-2 also. It's probably dependent on me using the
tofu trust model, and I'm not sure whether it would affect someone not having
this setting. Specifically, I have in my ~/.gnupg/gpg.conf
  trust-model tofu+pgp
and hopefully this is sufficient to reproduce the issue.

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

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

Versions of packages libreoffice-common depends on:
ii  libnumbertext-data 1.0.5-3
ii  libreoffice-style-colibre  1:6.4.2-2
ii  libreoffice-style-tango1:6.4.2-2
ii  ure1:6.4.2-2

Versions of packages libreoffice-common recommends:
ii  apparmor2.13.3-7
ii  fonts-liberation2   2.1.0-1
ii  libexttextcat-data  3.4.5-1
ii  python3-uno 1:6.4.2-2
ii  xdg-utils   1.1.3-2

Versions of packages libreoffice-common suggests:
ii  libreoffice-style-breeze [libreoffice-style]   1:6.4.2-2
ii  libreoffice-style-colibre [libreoffice-style]  1:6.4.2-2
ii  libreoffice-style-tango [libreoffice-style]1:6.4.2-2

Versions of packages python3-uno depends on:
ii  libc62.30-2
ii  libgcc-s110-20200324-1
ii  libpython3.8 3.8.2-1
ii  libreoffice-core 1:6.4.2-2
ii  libstdc++6   10-20200324-1
ii  libuno-cppu3 1:6.4.2-2
ii  libuno-cppuhelpergcc3-3  1:6.4.2-2
ii  libuno-sal3  1:6.4.2-2
ii  libuno-salhelpergcc3-3   1:6.4.2-2
ii  python3  3.8.2-2
ii  python3.83.8.2-1
ii  uno-libs-private 1:6.4.2-2
ii  ure  1:6.4.2-2

- -- Configuration Files:
/etc/apparmor.d/usr.lib.libreoffice.program.soffice.bin changed [not included]
 * I had set it to complain mode

- -- no debconf information

-BEGIN PGP SIGNATURE-

iHUEARYIAB0WIQT287WtmxUhmhucNnhyvHFIwKstpwUCXoACrQAKCRByvHFIwKst
p3MSAP0cz2FiDMFiCC4wbSnsvYZCqLDf81/dSPc1vWkiHqOVbwEAysYhder368UF
z1E6TeePMY9k2bb/tL3RUy+ftbyrEwU=
=Lg5N
-END PGP SIGNATURE-

Bug#955272: libreoffice: unable to sign existing PDFs: foo.tmp doesn't exist

[John Scott]

Package: libreoffice
Version: 1:6.4.1-1
Severity: normal

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Unlike #955271 which I just filed about digital signing, this issue doesn't
seem to arise out of the AppArmor profile.

 1. Open LibreOffice and navigate to File -> Digital Signatures -> Sign 
Existing PDF
 2. Choose a PDF, and in the Writer window that opens choose 'Sign Document'
 3. A message appears saying something like
'/home/john/Documents/lu97947ceyaav.tmp does not exist.'
and if one clicks OK, the dialog appears once more.

This issue appears in 1:6.4.2-2 also, and please do let me know if I
should explore some avenues for clues.

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

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

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

Versions of packages libreoffice recommends:
ii  fonts-crosextra-caladea 20130214-2
ii  fonts-crosextra-carlito 20130920-1
ii  fonts-dejavu2.37-1
ii  fonts-liberation1:1.07.4-11
ii  fonts-liberation2   2.1.0-1
ii  fonts-linuxlibertine5.3.0-4
ii  fonts-noto-core 20200103-3
ii  fonts-noto-extra20200103-3
ii  fonts-noto-mono 20200103-3
ii  fonts-noto-ui-core  20200103-3
ii  fonts-sil-gentium-basic 1.102-1
ii  libreoffice-java-common 1:6.4.2-2
ii  libreoffice-nlpsolver   0.9+LibO6.4.2-2
ii  libreoffice-report-builder  1:6.4.2-2
ii  libreoffice-script-provider-bsh 1:6.4.2-2
ii  libreoffice-script-provider-js  1:6.4.2-2
ii  libreoffice-script-provider-python  1:6.4.2-2
ii  libreoffice-sdbc-mysql  1:6.4.2-2
ii  libreoffice-sdbc-postgresql 1:6.4.2-2
ii  libreoffice-wiki-publisher  1.2.0+LibO6.4.2-2

Versions of packages libreoffice suggests:
ii  cups-bsd2.3.1-11
ii  default-jre [java8-runtime] 2:1.11-72
ii  firefox 72.0-1
ii  firefox-esr 68.6.0esr-1
ii  ghostscript 9.52~dfsg-1
ii  gnupg   2.2.20-1
pn  gpa 
ii  gstreamer1.0-libav  1.16.2-2
ii  gstreamer1.0-plugins-bad1.16.2-2.1
ii  gstreamer1.0-plugins-base   1.16.2-2
ii  gstreamer1.0-plugins-good   1.16.2-2
ii  gstreamer1.0-plugins-ugly   1.16.2-2
ii  hunspell-en-us [hunspell-dictionary]1:2018.04.16-1
ii  hyphen-en-us [hyphen-hyphenation-patterns]  2.8.8-7
ii  imagemagick 8:6.9.10.23+dfsg-2.1+b2
ii  imagemagick-6.q16 [imagemagick] 8:6.9.10.23+dfsg-2.1+b2
ii  libgl1  1.3.1-1
pn  libofficebean-java  
pn  libreoffice-grammarcheck
ii  libreoffice-help-en-us [libreoffice-help]   1:6.4.2-2
pn  libreoffice-l10n
ii  libreoffice-librelogo   1:6.4.2-2
ii  libreoffice-plasma  1:6.4.2-2
ii  libsane 1.0.27-3.2+b1
ii  libxrender1 1:0.9.10-1
pn  myspell-dictionary  
ii  mythes-en-us [mythes-thesaurus] 1:6.4.0~rc2-1
pn  openclipart2-libreoffice | openclipart-libreoffice  
ii  openjdk-11-jre [java8-runtime]  11.0.6+10-2
ii  pstoedit3.75-1
pn  unixodbc

Versions of packages libreoffice-core depends on:
ii  fontconfig  2.13.1-2+b1
ii  fonts-opensymbol2:102.11+LibO6.4.2-2
ii  libboost-date-time1.71.01.71.0-6
ii  libboost-locale1.71.0   1.71.0-6
ii 

Bug#949042: KMail doesn't show GPG's trustmodel/tofu information

[John Scott]

Control: reassign -1 kleopatra
Control: affects -1 kmail
Control: forwarded -1 https://bugs.kde.org/show_bug.cgi?id=363309

Hello,

I too would like to see KMail describe the information. I couldn't find a
KMail-specific upstream bug, but found a Kleopatra bug about it which
would probably fix it in KMail when implemented. I'm reassigning your bug
accordingly.

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

Bug#935415: kmail: Kmail with EWS does not receive mail

[John Scott]

Hi,

Are you saying that the mail isn't fetched automatically, but manual syncing
works okay?

By chance, does it seem to ask for your password when KMail would normally
remember others, or does it prompt an excessive number of times?
https://bugs.kde.org/show_bug.cgi?id=393002

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

Bug#958843: please don't depend on vim-nox

[John Scott]

Package: vim-editorconfig
Version: 0.3.3+dfsg-2
Severity: normal

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Hi,

I see in #851572 the dependency was added on vim-nox, but it appears to me
that this was done out of an abundance of caution. Caution is good, but I
mean to point out that the reporter wasn't having any difficulties:
> https://github.com/editorconfig/editorconfig-vim#installation states
> that vim needs to have enabled python support. This support is included
> in the "vim-nox" package so it might make sense to add a dependency to
> that package instead of the "vim" package.

That's not true: Python isn't necessary, and if it were all versions of Vim
except for vim-tiny have support for it. The README says
> If your Vim is not compiled with +python feature (...), please first
> download the EditorConfig core

> This plugin would NOT work if neither +python nor EditorConfig core is
> available.

(It didn't get mentioned in the README until a couple years after [1], but
Python 2 or Python 3 are sufficient.) Since vim-editorconfig does depend on
editorconfig, Python support in Vim isn't needed.

In fact editorconfig.txt says there is a third option by which you can get
away with neither, by invoking the Python interpreter outside Vim:
> Specify the mode of EditorConfig core. Generally it is OK to leave this option
> empty. There are 3 modes currently: "external_command", "python_builtin",
> "python_external".
> 
> python_builtin: Use the vim built-in python to run the python version
> EditorConfig Core.
> python_external:Use an external python interpreter to run the python
> version EditorConfig Core.
> external_command:   Run external EditorConfig Core.

However all of the search paths for an external Python interpreter still look
for Python 2, so I don't think that works without patching.

debian/copyright has
> Files-Excluded: plugin/editorconfig-core-py
but vim-editorconfig doesn't depend/recommend/suggest python3-editorconfig
in its place. Because vim-editorconfig isn't patched to search outside of
its runtime path in /usr/lib/python3/dist-packages/editorconfig I don't think
it would find them or run any Python code for that matter.

I don't think the release candidate upstream uses Python at all anymore, so
please take that invitation to drop the need for Python when it comes.

[1] 
https://github.com/editorconfig/editorconfig-vim/pull/52#issuecomment-406514109

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

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

Versions of packages vim-editorconfig depends on:
ii  editorconfig  0.12.1-1.1
ii  vim-nox   2:8.2.0439-1

Versions of packages vim-editorconfig recommends:
ii  vim-addon-manager  0.5.10

vim-editorconfig suggests no packages.

- -- no debconf information

-BEGIN PGP SIGNATURE-

iHUEARYIAB0WIQT287WtmxUhmhucNnhyvHFIwKstpwUCXqSMbgAKCRByvHFIwKst
p3hDAP9cYT0e5fADRboC8l+x0VHUJXEWzCxQHsFMoDEt8YFW/wEA5HisEhHgRWzC
YVTGGP/gD8xA7SLIJfP3EYU6YJx3IQQ=
=P4Q6
-END PGP SIGNATURE-

Bug#925754: Fwd: Fixed in newer release of libopenshot / libopenshot-audio

[John Scott]

On Fri, 24 Apr 2020 23:33:59 -0400 FeRD  wrote:
> Sorry, I realized I might have sent this reply to the wrong bug.
Yes, I sent my mail to both of the bugs (am doing now again, I guess). I am 
also making noise :)

> What version of libopenshot is that result from? The Clang namespacing was
> fixed with the merge of 2a1fe80[1] on 2019-10-29, and would be included in
> both libopenshot-0.2.4 and libopenshot-0.2.5.
I used version 0.2.2+dfsg1-1 which is the current version in unstable. I'm not 
the maintainer; upgrading it is outside of my domain (esp. in light of the 
following).

> That's a merge commit and it touches a bunch of files, but basically all of
> our headers now qualify juce symbols with the juce:: namespace prefix,  and
> the test sources now #define DONT_SET_USING_JUCE_NAMESPACE
> which prevents JUCE from exporting its symbols into the global namespace.
> 
> AFAICT that's the only way to prevent UnitTest++ and JUCE from clashing
> over ambiguous 'UnitTest' symbols. But all this should have been solved
> months ago.
> 
>> I'm uneasy about this and hope that a new release of OpenShot made with
>> the practices described in /usr/share/doc/juce-modules-source/README.Debian
>> will make an elegant solution.
> 
> Is there a copy of that file online somewhere? It's not part of the JUCE
> distribution as far as I can tell, and it's definitely not located at that
> path on my Fedora machine.

Right, I know what'll pull it all together. It seems that the source for 
libopenshot includes embedded code copies of JUCE, and code copies are 
strongly discouraged in Debian, even if they don't make it into the binaries.

That file is a Debian-specific README mostly addressed to developers that says 
to replace bundled copies of JUCE and use the code in package juce-modules-
source instead. This approach seems to have not been taken.

Coincidentally the embedded code copy discussion just came up on debian-devel, 
and if no maintainer objects I'll add this to the 'big list' of embedded code 
copies sometime soonish.

I hope this makes clear the nature of the obstacles ahead.JUCE for Debian
===

upstream's preferred form of usage of JUCE is to include a verbatim copy of all
used JUCE modules in your application.
This is made explicit in the 'Projucer', JUCE's own software project
management workbench, that will copy (or symlink, or include otherwise) the
modules' source code into your project.

# Projucer for Debian

Installing the following packages will give you the 'Projucer' as Debian
packages while keeping your embedded-module-code workflow:
 - juce-tools (contains the Projucer)
 - juce-modules-source (contains the source-code for the JUCE modules)

The 'Projucer' as shipped with Debian has the following modification regarding
the once shipped by upstream:

# Debian packages that depend on JUCE

This is a quick guideline for packaging upstream software that uses JUCE for
Debian.
For further implementation details check out the 'iem-plugin-suite' package.

- Build-Depend on 'juce-modules-source'
- Add 'Built-Using: juce-modules-source (= <>)' to debian/control
  (replace '<>' with the actual version of 'juce-modules-source', as
  obtained with

   dpkg-query --show --showformat='${source:Version}' juce-modules-source


  E.g. dh based packages might use something like the following in debian/rules:

   JUCE_VERSION := $(shell dpkg-query --show --showformat='$${source:Version}' juce-modules-source)
   override_dh_gencontrol:
dh_gencontrol -- -Vjuce:BuiltUsing="juce ( = $(JUCE_VERSION) )"

  Accompanied by the following in the binary package's section in debian/control:

   Built-Using: ${juce:BuiltUsing}

- If needed, dynamically link against the following libraries (as
  "juce-modules-source" does not include their sources (as opposed to upstream):
  - libjpeg
  - libpng
  - libflac
  - libvorbis libvorbisenc libvorbisfile
  - libogg
  - zlib
  E.g. using something like:

   make LDFLAGS="$(pkg-config --libs libpng libjpeg flac vorbis vorbisfile vorbisenc ogg zlib)"

  *Alternatively*, resave the JUCE-project with the Debian-packaged 'Projucer'
  (>=5.4.4~repack0-3) which will take care of adding these libraries (if
  required) to the LinuxMakefile build.

- When compiling for some embedded architectures (notably 'armel', 'mipsel' and
  the like), you might need to link against '-latomic'.
  The following snippet for d/rules can help inject the library on the required
  architectures:

# link with libatomic on architectures without built-in atomic
noatomicarch = $(shell dpkg-architecture -qDEB_HOST_ARCH | egrep -x "(armel|powerpc|powerpcspe|m68k|mips|mipsel|sh4|riscv64)")
ifeq ($(if $(noatomicarch),atomic), atomic)
LDFLAGS += -latomic
endif

  *Alternatively*, resave the JUCE-project with the Debian-packaged 'Projucer'
  (>=5.4.4~repack0-3) which will take care of adding the relevant flags to the
  LinuxMakefile build.

Bug#895696: firmware-ath9k-htc: breaks with NetworkManager's MAC randomization: fixing in wpa_supplicant

[John Scott]

Control: block -1 by 954861

> If no one dissents I'll try to get a fix landed there soon, at least in the
> Debian package first.
Sorry for the noise, I take this back. This may be a bug in wpa_supplicant 
just fixed upstream: it has trouble with devices such that their names are the 
maximum of 15 characters.
If this is fixed MAC randomization will hopefully work and blacklisting will be 
unnecessary for ath9k_htc and dropped for the other devices. I'll hold my 
workaround proposal until that issue plays out.

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

Bug#895696: firmware-ath9k-htc: breaks with NetworkManager's MAC randomization: fixing in wpa_supplicant

[John Scott]

Control: owner -1 !

I've posted this with details on the GitHub issue [1], but it happens that
wpa_supplicant/nm upstream ships a file that specifically blacklists drivers
that don't work with NetworkManager's MAC randomization exactly as the
proposed 'workaround' here does.

The bug even mentioned ath9k_htc and AR9271 specifically but this didn't
become part of the fix. A Debian-specific version of the file is included in
wpa_supplicant.

If no one dissents I'll try to get a fix landed there soon, at least in the
Debian package first.

[1] 
https://github.com/qca/open-ath9k-htc-firmware/issues/132#issuecomment-618715461
[2] 
https://salsa.debian.org/debian/wpa/-/commits/debian/master/debian/NetworkManager/no-mac-addr-change.conf

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

Bug#925754: Fixed in newer release of libopenshot / libopenshot-audio

[John Scott]

Control: block 925754 by 925755
Control: notforwarded 925754
Control: forwarded 925755 
https://github.com/OpenShot/libopenshot-audio/issues/33

Hi,

> On Wed, 29 Jan 2020 10:08:55 +0100 Matthias Klose  wrote:
> > libopenshot-audio 0.1.8 still fails to build
> 
> Quite right, sorry. libopenshot-audio-0.1.8 fixed building with GCC *less
> than* 9,
> but GCC9 coming along broke it again.
> 
> On Fedora / RPM Fusion we were building with commit 7001b68[1],
> which was at the time an unreleased commit on the development branch.
> 
> However, since then both 0.1.9 and 0.2.0 have been released,
> including fixes to build with GCC 9 and 10 respectively, IIRC.
> (I know 0.2.0 builds with GCC 10 for sure, since I've done it myself.)
> 
> Current releases:
> 
> libopenshot-audio-0.2.0:
> https://github.com/OpenShot/libopenshot-audio/archive/v0.2.0.tar.gz
> 
> libopenshot-0.2.5:
> https://github.com/OpenShot/libopenshot/archive/v0.2.5.tar.gz
> 
> OpenShot 2.5.1 (openshot-qt):
> https://github.com/OpenShot/openshot-qt/archive/v2.5.1.tar.gz
> 
> 
> [1]:
> https://github.com/OpenShot/libopenshot-audio/commit/7001b68787c0881a44bcafba98cccae509a31644

libopenshot-audio builds with Clang without any modifications. Using this
OpenShot (again with Clang) gets a bit farther:
/usr/include/libopenshot-audio/JuceLibraryCode/modules/juce_audio_basics/../juce_core/unit_tests/juce_UnitTest.h:73:17:
 note: candidate found by name lookup is 'juce::UnitTest'
class JUCE_API  UnitTest
^
/<>/tests/Cache_Tests.cpp:50:2: error: reference to 'UnitTest' is 
ambiguous

I've seen this is fixed in a commit upstream, and I think cherrypicking it
helped, but the -audio Debian package uses the Juce embedded code copies
instead of the ones in juce-modules-source as best as I can tell.

I'm uneasy about this and hope that a new release of OpenShot made with the
practices described in /usr/share/doc/juce-modules-source/README.Debian will
make an elegant solution.

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

Bug#958501: please set paths and install systemd units

[John Scott]

Package: lynis
Version: 1.6.3-1
Severity: minor

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Hi,

Thanks for revamping the package. It provides a systemd service and timer at
/usr/share/lynis/extras/systemd/lynis.service/timer. The header of the former
reads

# Lynis service file for systemd
# - Adjust path to link to location where Lynis binary is installed
# - Place this file together with the timer file in systemd directory
# - Run: systemctl enable lynis.service

I think it's odd that this is directed at users since the paths aren't going
to change: this could be done at build-time, and then the service and timer
installed in /etc/systemd/system/ proper. The service has a dummy path to
`lynis` for the time being, so a copy-paste doesn't suffice.

Lynis now supports a command 'lynis generate systemd-units' that sets up the
paths for you [1]. It uses 'which' to get them though, so this might be a
problem on usr-merged systems.

Don't hesitate to let me know if I can be of any assistance.

[1] 
https://github.com/CISOfy/lynis/commit/9f7e0775a57781ae6e7a247e71a149f25ef7a02d

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

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

Versions of packages lynis depends on:
ii  e2fsprogs  1.45.6-1

Versions of packages lynis recommends:
ii  menu  2.1.47+b1

Versions of packages lynis suggests:
pn  aide  
ii  apt-listbugs  0.1.31
ii  debsecan  0.4.20.1
ii  debsums   2.2.5
ii  dnsutils  1:9.11.16+dfsg-2
pn  fail2ban  
pn  samhain   
pn  tripwire  

- -- debconf-show failed

-BEGIN PGP SIGNATURE-

iHUEARYIAB0WIQT287WtmxUhmhucNnhyvHFIwKstpwUCXqDiyAAKCRByvHFIwKst
pxNFAP9vWR6MSz973Z5mKigpZ9pxY1YmBMsS8gpBUIFcve7NmQD+Kjj52PBrSDKK
3Qyzz3SvPcYLKld2L8jYV5Gm9g9rQA0=
=UfTZ
-END PGP SIGNATURE-

Bug#958439: recommends python(3)-qwt-qt5 which has never existed

[John Scott]

Package: gnuradio
Version: 3.7.11-3
Severity: normal

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Hi,

GNU Radio currently recommends python3-qwt-qt5—and recommended python-qwt-qt5
before that—but these packages have never existed as best as I can tell.

It had the '3' appended at [1], but going to Qt 5 made the '5' commute [2]
- - python-qwt5-qt4,
+   python-qwt-qt5,

The former was removed last year [3] and though I don't know its purpose, maybe
 python3-pyqt5.qwt - Python version of the Qwt6 technical widget library 
(Python3)
is its successor?

[1] 
https://salsa.debian.org/bottoms/pkg-gnuradio/-/commit/f99bae4917f4?expanded=1#58ef006ab62b83b4bec5d81fe5b32c3b4c2d1cc2_85_91
[2] 
https://salsa.debian.org/bottoms/pkg-gnuradio/-/commit/6fe9dfaf7302#58ef006ab62b83b4bec5d81fe5b32c3b4c2d1cc2_81_80
[3] https://tracker.debian.org/news/1064774/

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

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

Versions of packages gnuradio depends on:
ii  libboost-program-options1.67.0  1.67.0-17
ii  libboost-system1.67.0   1.67.0-17
ii  libboost-thread1.67.0   1.67.0-17
ii  libc6   2.30-4
ii  libcanberra-gtk-module  0.30-7
ii  libcanberra-gtk3-module 0.30-7
ii  libcodec2-0.9   0.9.2-2
ii  libgcc-s1   10-20200411-1
ii  libgnuradio-analog3.8.1 3.8.1.0-1
ii  libgnuradio-audio3.8.1  3.8.1.0-1
ii  libgnuradio-blocks3.8.1 3.8.1.0-1
ii  libgnuradio-channels3.8.1   3.8.1.0-1
ii  libgnuradio-digital3.8.13.8.1.0-1
ii  libgnuradio-dtv3.8.13.8.1.0-1
ii  libgnuradio-fec3.8.13.8.1.0-1
ii  libgnuradio-fft3.8.13.8.1.0-1
ii  libgnuradio-filter3.8.1 3.8.1.0-1
ii  libgnuradio-pmt3.8.13.8.1.0-1
ii  libgnuradio-qtgui3.8.1  3.8.1.0-1
ii  libgnuradio-runtime3.8.13.8.1.0-1
ii  libgnuradio-trellis3.8.13.8.1.0-1
ii  libgnuradio-uhd3.8.13.8.1.0-1
ii  libgnuradio-video-sdl3.8.1  3.8.1.0-1
ii  libgnuradio-vocoder3.8.13.8.1.0-1
ii  libgnuradio-wavelet3.8.13.8.1.0-1
ii  libgnuradio-zeromq3.8.1 3.8.1.0-1
ii  liblog4cpp5v5   1.1.3-1
ii  libpython3.83.8.2-1+b1
ii  libqt5core5a5.12.5+dfsg-9
ii  libqt5widgets5  5.12.5+dfsg-9
ii  libstdc++6  10-20200411-1
ii  libuhd3.15.03.15.0.0-2+b1
ii  libvolk2-bin2.2.1-2
ii  python3 3.8.2-3
ii  python3-click   7.0-3
ii  python3-click-plugins   1.1.1-2
ii  python3-gi  3.36.0-1+b1
ii  python3-gi-cairo3.36.0-1+b1
ii  python3-lxml4.5.0-1+b1
ii  python3-mako1.1.2+ds1-1
ii  python3-numpy   1:1.17.4-5
ii  python3-opengl  3.1.5+dfsg-1
ii  python3-pyqt5   5.14.2+dfsg-1+b1
ii  python3-pyqtgraph   0.11.0~rc0-1
ii  python3-sip 4.19.22+dfsg-1+b1
ii  python3-yaml5.3.1-1+b1
ii  python3-zmq 18.1.1-3+b1

Versions of packages gnuradio recommends:
ii  gnuradio-dev3.8.1.0-1
ii  python3-matplotlib  3.1.2-2
pn  python3-networkx
pn  python3-qwt-qt5 
ii  python3-scipy   1.3.3-3+b1
ii  rtl-sdr 0.6.0-3
ii  uhd-host3.15.0.0-2+b1

Versions of packages gnuradio suggests:
ii  gr-fosphor  3.8~2.2d4fe78-1+b2
ii  gr-osmosdr  0.2.0-2+b1

- -- no debconf information

-BEGIN PGP SIGNATURE-

iHUEARYIAB0WIQT287WtmxUhmhucNnhyvHFIwKstpwUCXp+mjQAKCRByvHFIwKst
pxcrAQDkiYb8W8/sbtVA01Gp28sQHS2sVCVX/1UtPVKu0kceCgD+LP6BaV7v3aWd
FyxXsjoyd4qhPmlyO8n95P7MG1s2IwM=
=GrKs
-END PGP SIGNATURE-

Bug#958434: scribus suggests scribus-ng-doc; scribus*-doc do not correspond

[John Scott]

Source: scribus
Version: 1.5.1+dfsg-2
Severity: normal
Control: affects -1 src:scribus-doc

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Hi,

scribus suggests scribus-ng-doc. This doesn't seem right and the matching
1.5.* version is only in experimental. scribus-doc isn't 1.5.* however.

Seeing that the documentation is non-free I'm no longer pursuing it, but
I would appreciate knowing whether this is deliberate.

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

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

-BEGIN PGP SIGNATURE-

iHUEARYIAB0WIQT287WtmxUhmhucNnhyvHFIwKstpwUCXp+HhwAKCRByvHFIwKst
p+itAP4zXeWhKpcKRI9wvPcDKBR4NDNjehgLkGvFvAB+ZzpXNQEAlvDjmadnXJd9
kvqMxRLcIjQ3j4hHHfrIMqkgXraoDwg=
=N5A3
-END PGP SIGNATURE-

Bug#958558: 3.8 may not need libcanberra-gtk-module dependency

[John Scott]

Package: gnuradio
Version: 3.8.0.0-5
Severity: minor

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Hi,

I noticed libcanberra-gtk-module and libcanberra-gtk3-module were added to
gnuradio's dependencies for #921377, checking what packages installed depend
on GTK+ 2.

That user was using 3.7.10.1 on Stretch however, so I bet the former was needed
by PyGTK which isn't used in the recent packages. As best as I can tell 
neither gnuradio nor its dependencies use GTK+ 2 now. Please drop
libcanberra-gtk-module if you can.

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

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

Versions of packages gnuradio depends on:
ii  libboost-program-options1.67.0  1.67.0-17
ii  libboost-system1.67.0   1.67.0-17
ii  libboost-thread1.67.0   1.67.0-17
ii  libc6   2.30-4
ii  libcanberra-gtk-module  0.30-7
ii  libcanberra-gtk3-module 0.30-7
ii  libcodec2-0.9   0.9.2-2
ii  libgcc-s1   10-20200411-1
ii  libgnuradio-analog3.8.1 3.8.1.0-1
ii  libgnuradio-audio3.8.1  3.8.1.0-1
ii  libgnuradio-blocks3.8.1 3.8.1.0-1
ii  libgnuradio-channels3.8.1   3.8.1.0-1
ii  libgnuradio-digital3.8.13.8.1.0-1
ii  libgnuradio-dtv3.8.13.8.1.0-1
ii  libgnuradio-fec3.8.13.8.1.0-1
ii  libgnuradio-fft3.8.13.8.1.0-1
ii  libgnuradio-filter3.8.1 3.8.1.0-1
ii  libgnuradio-pmt3.8.13.8.1.0-1
ii  libgnuradio-qtgui3.8.1  3.8.1.0-1
ii  libgnuradio-runtime3.8.13.8.1.0-1
ii  libgnuradio-trellis3.8.13.8.1.0-1
ii  libgnuradio-uhd3.8.13.8.1.0-1
ii  libgnuradio-video-sdl3.8.1  3.8.1.0-1
ii  libgnuradio-vocoder3.8.13.8.1.0-1
ii  libgnuradio-wavelet3.8.13.8.1.0-1
ii  libgnuradio-zeromq3.8.1 3.8.1.0-1
ii  liblog4cpp5v5   1.1.3-1
ii  libpython3.83.8.2-1+b1
ii  libqt5core5a5.12.5+dfsg-9
ii  libqt5widgets5  5.12.5+dfsg-9
ii  libstdc++6  10-20200411-1
ii  libuhd3.15.03.15.0.0-2+b1
ii  libvolk2-bin2.2.1-2
ii  python3 3.8.2-3
ii  python3-click   7.0-3
ii  python3-click-plugins   1.1.1-2
ii  python3-gi  3.36.0-1+b1
ii  python3-gi-cairo3.36.0-1+b1
ii  python3-lxml4.5.0-1+b1
ii  python3-mako1.1.2+ds1-1
ii  python3-numpy   1:1.17.4-5
ii  python3-opengl  3.1.5+dfsg-1
ii  python3-pyqt5   5.14.2+dfsg-1+b1
ii  python3-pyqtgraph   0.11.0~rc0-1
ii  python3-sip 4.19.22+dfsg-1+b1
ii  python3-yaml5.3.1-1+b1
ii  python3-zmq 18.1.1-3+b1

Versions of packages gnuradio recommends:
ii  gnuradio-dev3.8.1.0-1
ii  python3-matplotlib  3.2.1-1+b1
pn  python3-networkx
pn  python3-qwt-qt5 
ii  python3-scipy   1.3.3-3+b1
ii  rtl-sdr 0.6.0-3
ii  uhd-host3.15.0.0-2+b1

Versions of packages gnuradio suggests:
ii  gr-fosphor  3.8~2.2d4fe78-1+b2
ii  gr-osmosdr  0.2.0-2+b1

- -- no debconf information

-BEGIN PGP SIGNATURE-

iHUEARYIAB0WIQT287WtmxUhmhucNnhyvHFIwKstpwUCXqHH4AAKCRByvHFIwKst
p2W4AQDKvkpiycG8tvNSz3HcXb6GD3v0n4aIZYtIACheMQEPrgEAw77Vwgk5j9yk
b+ZVdJUpkeQKpfDaWigpR9Cv20DU+QU=
=MHEG
-END PGP SIGNATURE-

Bug#959500: misleading 'You need to be root' when Linux is in Lockdown mode

[John Scott]

Package: flashrom
Version: 1.2-5
Severity: normal

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

It seems this is because I use my system with Secure Boot, so Lockdown
mode is enabled by default, but in principle I think it could be enabled by
anyone (maybe it's used by SELinux users as well)

# flashrom -p internal -r woo
flashrom v1.2 on Linux 5.5.0-2-amd64 (x86_64)
flashrom is free software, get the source code at https://flashrom.org

Using clock_gettime for delay loops (clk_id: 1, resolution: 1ns).
ERROR: Could not get I/O privileges (Operation not permitted).
You need to be root.
Error: Programmer initialization failed.

# dmesg | tail -3
[38836.060931] Lockdown: flashrom: raw io port access is restricted; see 
https://wiki.debian.org/SecureBoot
[38851.136762] Lockdown: flashrom: raw io port access is restricted; see 
https://wiki.debian.org/SecureBoot
[38865.113982] Lockdown: flashrom: raw io port access is restricted; see 
https://wiki.debian.org/SecureBoot

flashrom should say the actual semantic of the problem, that it couldn't
access a device, instead of its best guess.

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

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

Versions of packages flashrom depends on:
ii  libc6 2.30-4
ii  libftdi1-21.4-2+b2
ii  libpci3   1:3.6.4-1
ii  libusb-1.0-0  2:1.0.23-2

flashrom recommends no packages.

flashrom suggests no packages.

- -- debconf-show failed

-BEGIN PGP SIGNATURE-

iHUEARYIAB0WIQT287WtmxUhmhucNnhyvHFIwKstpwUCXq45lgAKCRByvHFIwKst
pxjXAQDidnYRdO0NEDDkPxcmxgT/+zsHnCovWtWTjGsbUS67XQEA9xFDpObphlMa
pb8aTi0E6hnwOqvk7p9qJDV9tf1IWg0=
=1538
-END PGP SIGNATURE-

Bug#958747: libqt5texttospeech5 might should depend or recommend a speech plugin

[John Scott]

Package: libqt5texttospeech5
Version: 5.12.5-1
Severity: normal
Tags: a11y
Control: block 955762 by -1
Control: tags 955762 - patch

Hi,

I filed #955762 on Okular because if one doesn't have at least one of
qtspeech5-flite-plugin or qtspeech5-speechd-plugin installed, the only error
it prints is to the CLI doing TTS. These plugins have no reverse dependencies.

It appears this isn't specific to Okular. KMouth also doesn't work unless
one types the path to a binary to a preferred engine. KAnagram's settings
are to speak the words by default but it hadn't been doing this without
a plugin. Knights (which doesn't have rdeps either) tries to use speech out
of the box though there is no mention in the program.

I'm not familiar with Qt and don't know whether this library has an actual
dependency on a plugin, or if the dep duty lies elsewhere. Or which engine
should be preferred, assuming all programs can use either.

Please point me in the right direction. It was this blog post [1] that had
shown me that the dependency is needed, and hopefully no one else will miss
out on such nifty features or feel frustration.

[1] 
https://www.ubuntubuzz.com/2018/12/text-to-speech-on-gnulinux-part-2-okular-to-speech.html

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

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

Versions of packages libqt5texttospeech5 depends on:
ii  libc6 2.30-4
ii  libqt5core5a [qtbase-abi-5-12-5]  5.12.5+dfsg-9
ii  libstdc++610-20200411-1

libqt5texttospeech5 recommends no packages.

libqt5texttospeech5 suggests no packages.

- -- no debconf information

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

Bug#959915: redundant freshclam profile since it's shipped in-package

[John Scott]

Package: apparmor-profiles-extra
Version: 1.27
Severity: minor

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Hi,

An experimental freshclam profile is provided at 
 /usr/share/apparmor/extra-profiles/usr.bin.freshclam, but clamav-freshclam
provides its own more recent one in enforce mode at /etc/aa.d/ and has been
for a while.

Please remove this one.

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

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

Versions of packages apparmor-profiles-extra depends on:
ii  apparmor  2.13.4-1+b1

apparmor-profiles-extra recommends no packages.

apparmor-profiles-extra suggests no packages.

- -- no debconf information

-BEGIN PGP SIGNATURE-

iHUEARYIAB0WIQT287WtmxUhmhucNnhyvHFIwKstpwUCXrNEiAAKCRByvHFIwKst
pz8jAP9hDm6l+bk4I4OKB2IyWlh0aL2ZPtH6E9fm+Pw269OCwAEAzzsqu3YuGsgw
wETgjZAg6N6AMdBsOcjxN4s5gmWHOws=
=SQtB
-END PGP SIGNATURE-

Bug#659348: #659348 - webext-librejs RFP → ITP

[John Scott]

Control: owner -1 !
Control: retitle -1 ITP: webext-librejs -- browser plugin to block non-free JS

I'm starting to work on this. When it starts taking shape, I hope it will be 
welcome with the Web/MozExt team.

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

Bug#925754: Fwd: Fixed in newer release of libopenshot / libopenshot-audio

[John Scott]

On Sat, 25 Apr 2020 21:40:14 -0400 FeRD  wrote:
> If Debian maintains JUCE as a distro package, and it would be a compatible
> alternative to our JUCE-based "libopenshot-audio", I don't see any reason we
> can't add an option to libopenshot's CMake configuration that tells it to
> just
> use those libs, completely replacing libopenshot-audio ? which would
> become entirely superfluous in that scenario.
> 
> This is the perfect time to do it, too, as I've been gutting and reworking
> large parts
> of libopenshot's build system recently ? sticking in a "USE_SYSTEM_JUCE"
> option would be no trouble at all.
> 
> Is there an importable CMake configuration for the distro JUCE package, by
> any chance, or should I put together a find module as well?

That would be terrific. The version of JUCE that you updated is almost the same 
version as the Debian package, so I expect that would work well.

There doesn't appear to be a CMake module. If you would create one or add an 
option to specify the path, that'd be the cleanest solution.

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

Bug#960143: sagetex: FTBFS in unstable

[John Scott]

On Mon, 11 May 2020 19:57:52 +0900 Norbert Preining  
wrote:
> Uploading in the a few minutes, after the binary build succeeded.

Just a ping in case you've moved on

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

Bug#953722: ITP: josm-installer -- Editor for OpenStreetMap (installer)

[John Scott]

> The package will be maintained with in the Debian GIS team where it will
> eventually replace the josm package.

Because this package will need to go in contrib or non-free, does this mean 
JOSM will be removed from main? I think that is a substantial trade-off to 
provide new backports. Could they both be maintained?


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

Bug#953918: samba-tool backup crashes, fixed and backported upstream

[John Scott]

Control: forwarded -1 https://bugzilla.samba.org/show_bug.cgi?id=13917
Control: tags -1 + upstream fixed-upstream
Control: fixed -1 2:4.11.0+dfsg-1
Control: affects -1 samba-common-bin

This was fixed upstream and they did apply the fix to Samba 4.9. I'm leaving 
this bug open to assess whether it ought to be fixed in Buster.

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

Bug#954735: kde-telepathy-text-ui: Could not find the program 'kcmshell4' setting up plugins

[John Scott]

Package: kde-telepathy-text-ui
Version: 17.08.3-2
Severity: normal

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Searching 'Plugins' from the application menu one finds
/usr/share/applications/kcm_ktp_chat_messages.desktop which has
 Exec=kcmshell4 kcm_ktp_message_filters

and kcmshell4 doesn't appear to exist anymore. Unfortunately kcmshell5 --list
doesn't immidiately show an equivalent.

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

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

Versions of packages kde-telepathy-text-ui depends on:
ii  kde-telepathy-data   17.08.3-2
ii  kio  5.62.1-2+b1
ii  libc62.30-2
ii  libgcc-s1 [libgcc1]  10-20200312-2
ii  libgcc1  1:10-20200312-2
ii  libjs-jquery 3.3.1~dfsg-3
ii  libkf5archive5   5.62.0-1
ii  libkf5configcore55.62.0-1+b1
ii  libkf5configgui5 5.62.0-1+b1
ii  libkf5configwidgets5 5.62.0-1+b1
ii  libkf5coreaddons55.62.0-1
ii  libkf5dbusaddons55.62.0-1
ii  libkf5emoticons-bin  5.62.0-1+b1
ii  libkf5emoticons5 5.62.0-1+b1
ii  libkf5i18n5  5.62.0-1
ii  libkf5iconthemes55.62.0-1+b1
ii  libkf5itemviews5 5.62.0-1+b1
ii  libkf5kcmutils5  5.62.0-1+b2
ii  libkf5kiocore5   5.62.1-2+b1
ii  libkf5kiowidgets55.62.1-2+b1
ii  libkf5notifications5 5.62.0-1+b1
ii  libkf5notifyconfig5  5.62.0-1+b1
ii  libkf5people55.62.0-1+b1
ii  libkf5peoplewidgets5 5.62.0-1+b1
ii  libkf5service-bin5.62.0-1
ii  libkf5service5   5.62.0-1
ii  libkf5sonnetcore55.62.0-1+b1
ii  libkf5sonnetui5  5.62.0-1+b1
ii  libkf5textwidgets5   5.62.0-1+b1
ii  libkf5widgetsaddons5 5.62.0-1+b1
ii  libkf5windowsystem5  5.62.0-2+b1
ii  libkf5xmlgui55.62.0-1+b1
ii  libktpcommoninternals9   17.08.3-2
ii  libktplogger917.08.3-2
ii  libktpmodels917.08.3-2
ii  libktpotr9   17.08.3-2
ii  libktpwidgets9   17.08.3-2
ii  libqt5core5a 5.12.5+dfsg-9
ii  libqt5dbus5  5.12.5+dfsg-9
ii  libqt5gui5   5.12.5+dfsg-9
ii  libqt5texttospeech5  5.12.5-1
ii  libqt5webenginewidgets5  5.12.5+dfsg-7
ii  libqt5widgets5   5.12.5+dfsg-9
ii  libqt5xml5   5.12.5+dfsg-9
ii  libstdc++6   10-20200312-2
ii  libtelepathy-qt5-0   0.9.8+ds-2

Versions of packages kde-telepathy-text-ui recommends:
ii  kde-telepathy  15.08.3

kde-telepathy-text-ui suggests no packages.

- -- no debconf information

-BEGIN PGP SIGNATURE-

iHUEARYIAB0WIQT287WtmxUhmhucNnhyvHFIwKstpwUCXnettwAKCRByvHFIwKst
p17EAP0RNt/eva9zHVYpevT1LVfFeXMXB85HafsO2rk3ZsyuywD6A3lEiBfc064E
3gXeZenZSdxZLx06cKqkw9dsbT5PfAo=
=TQXp
-END PGP SIGNATURE-

Bug#959500: misleading 'You need to be root' when Linux is in Lockdown mode

[John Scott]

Control: tags -1 + upstream

On Tuesday, May 5, 2020 7:07:39 AM EDT Gürkan Myczko wrote:
> The error message:
> ERROR: Could not get I/O privileges (Operation not permitted).
> to me and #flashrom is not misleading at all.

I had overlooked that part and fixated on the last line about root.
However 'You need to be root' sounds too strong IMHO especially since
that's not what's really necesarry. Maybe a message more like
  E: Unable to acquire the dpkg frontend lock, are you root?
would be fitting.

Thanks for giving me the gumption to try strace. With it I got the attached
output showing iopl() is throwing the error. Its man page says
ERRORS
  EPERM  The calling process has insufficient privilege to call iopl();
the CAP_SYS_RAWIO capability is required to raise the I/O privilege level
above its current value.
So maybe root isn't necessary in general.

With gdb the problem seems to be at
#0  rget_io_perms () at ../hwaccess.c:119
#1  0x5559fbab in internal_init () at ../internal.c:213
#2  0x555b706a in programmer_init (prog=PROGRAMMER_INTERNAL, param=0x0) 
at ../flashrom.c:555
#3  0x555ccffe in main (argc=5, argv=0x7fffe608) at 
../cli_classic.c:459

int rget_io_perms(void)
{
#if IS_X86 && !(defined(__DJGPP__) || defined(__LIBPAYLOAD__))
#if defined (__sun)
if (sysi86(SI86V86, V86SC_IOPL, PS_IOPL) != 0) {
#elif USE_DEV_IO
if ((io_fd = open("/dev/io", O_RDWR)) < 0) {
#elif USE_IOPERM
if (ioperm(0, 65536, 1) != 0) {
#elif USE_IOPL
if (iopl(3) != 0) {
#endif
msg_perr("ERROR: Could not get I/O privileges (%s).\n", 
strerror(errno));
msg_perr("You need to be root.\n");


I was pointed to it by the Linux commit [1], that on my system I can read
/sys/kernel/security/lockdown as root which says
none [integrity] confidentiality

I hope this can provide a check comparable to the OpenBSD and NetBSD ones
there.

If you have Linux 5.4+ you might be able to boot with lockdown=integrity
(EFI/Secure Boot not necessary) and reproduce this way.

Please let me know if you'd be helped by any more details. I hope this can be
solved cleanly.

[1] 
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=aefcf2f4execve("/usr/sbin/flashrom", ["flashrom", "--programmer", "internal", "-r", 
"woo"], 0x7ffebadd4dc0 /* 20 vars */) = 0
brk(NULL)   = 0x564f5f7a9000
access("/etc/ld.so.preload", R_OK)  = -1 ENOENT (No such file or directory)
openat(AT_FDCWD, "/etc/ld.so.cache", O_RDONLY|O_CLOEXEC) = 3
fstat(3, {st_mode=S_IFREG|0644, st_size=197499, ...}) = 0
mmap(NULL, 197499, PROT_READ, MAP_PRIVATE, 3, 0) = 0x7fc50c0ba000
close(3)= 0
openat(AT_FDCWD, "/lib/x86_64-linux-gnu/libusb-1.0.so.0", O_RDONLY|O_CLOEXEC) = 
3
read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\260G\0\0\0\0\0\0"..., 
832) = 832
fstat(3, {st_mode=S_IFREG|0644, st_size=109552, ...}) = 0
mmap(NULL, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 
0x7fc50c0b8000
mmap(NULL, 112016, PROT_READ, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x7fc50c09c000
mmap(0x7fc50c0a, 57344, PROT_READ|PROT_EXEC, 
MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x4000) = 0x7fc50c0a
mmap(0x7fc50c0ae000, 32768, PROT_READ, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 
0x12000) = 0x7fc50c0ae000
mmap(0x7fc50c0b6000, 8192, PROT_READ|PROT_WRITE, 
MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x19000) = 0x7fc50c0b6000
close(3)= 0
openat(AT_FDCWD, "/lib/x86_64-linux-gnu/libpci.so.3", O_RDONLY|O_CLOEXEC) = 3
read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0P5\0\0\0\0\0\0"..., 832) 
= 832
fstat(3, {st_mode=S_IFREG|0644, st_size=60024, ...}) = 0
mmap(NULL, 62096, PROT_READ, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x7fc50c08c000
mprotect(0x7fc50c08f000, 45056, PROT_NONE) = 0
mmap(0x7fc50c08f000, 28672, PROT_READ|PROT_EXEC, 
MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x3000) = 0x7fc50c08f000
mmap(0x7fc50c096000, 12288, PROT_READ, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 
0xa000) = 0x7fc50c096000
mmap(0x7fc50c09a000, 8192, PROT_READ|PROT_WRITE, 
MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0xd000) = 0x7fc50c09a000
close(3)= 0
openat(AT_FDCWD, "/lib/x86_64-linux-gnu/libftdi1.so.2", O_RDONLY|O_CLOEXEC) = 3
read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\2004\0\0\0\0\0\0"..., 
832) = 832
fstat(3, {st_mode=S_IFREG|0644, st_size=59872, ...}) = 0
mmap(NULL, 62024, PROT_READ, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x7fc50c07c000
mmap(0x7fc50c07f000, 32768, PROT_READ|PROT_EXEC, 
MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x3000) = 0x7fc50c07f000
mmap(0x7fc50c087000, 12288, PROT_READ, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 
0xb000) = 0x7fc50c087000
mmap(0x7fc50c08a000, 8192, PROT_READ|PROT_WRITE, 
MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0xd000) = 0x7fc50c08a000
close(3)= 0
openat(AT_FDCWD, "/lib/x86_64-linux-gnu/libc.so.6", O_RDONLY|O_CLOEXEC) 

Bug#960875: e-antic ABI break

[John Scott]

Control: reassign 960614 src:normaliz,src:e-antic
Control: forcemerge -1 960614

See bug #960614, not only the test fails but normaliz is unusable as 
installed.

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

Bug#969618: getopt: optarg is NULL outside of loop

[John Scott]

Package: libc6
Version: 2.31-3
Severity: normal
X-Debbugs-Cc: 

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

I suspect this is an upstream problem but I'm reporting it here
first per their policy [1] since I'm unsure.

Both POSIX (including the Issue 8 draft) and the GNU C Library
manual say that when an argument is provided for an option, a
pointer to it is provided as optarg.

It seems like after leaving the while() loop getopt is usually
used in, optarg points to NULL instead, even if no other options,
bearing arguments or not, are used. It's a little grey but POSIX
doesn't seem to permit this, and the (non-DFSG) glibc manual could
be construed as saying it should work fine this way:
> If the option has an argument, getopt returns the argument by storing
> it in the variable optarg. You don’t ordinarily need to copy the optarg
> string, since it is a pointer into the original argv array, not into a
> static area that might be overwritten. 

Everything works fine with Musl libc which can be tried with musl-gcc.
Consider this example program:

#define _POSIX_C_SOURCE 200809L
#include 
#include 
#include 
#include 
int main(int argc, char *argv[]) {
int opt;
while((opt = getopt(argc, argv, "a:")) != -1) {}
assert(optarg != NULL);
}

If this is invoked as './a.out -afoo', the inner assertion will
the last assertion will fail with glibc. In the absence of
a compelling reason (such as if I were using the GNU extension of
having an optional argument via '::'), standards aside, it would
be helpful for me if the variable could be left alone.

[1] https://sourceware.org/glibc/wiki/FilingBugs
[2] https://www.gnu.org/software/libc/manual/html_node/Using-Getopt.html
- -- System Information:
Debian Release: bullseye/sid
  APT prefers testing
  APT policy: (500, 'testing'), (2, 'unstable'), (1, 'testing-debug'), (1, 
'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

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

Versions of packages libc6 depends on:
ii  libcrypt1  1:4.4.17-1
ii  libgcc-s1  10.2.0-5

Versions of packages libc6 recommends:
ii  libidn2-0  2.3.0-1

Versions of packages libc6 suggests:
ii  debconf [debconf-2.0]  1.5.74
ii  glibc-doc  2.31-3
ii  libc-l10n  2.31-3
ii  locales2.31-3

- -- debconf information:
  glibc/restart-failed:
  glibc/upgrade: true
  glibc/kernel-too-old:
  glibc/kernel-not-supported:
* libraries/restart-without-asking: true
  glibc/disable-screensaver:
  glibc/restart-services:

-BEGIN PGP SIGNATURE-

iHUEARYIAB0WIQT287WtmxUhmhucNnhyvHFIwKstpwUCX1Q6TgAKCRByvHFIwKst
p+D0AQDqLFwxGh/oTV+13E5stB3WvG9zD0tpMiol/xHW0QuERgEAsPKsGbQBW2nG
VFzkfExA5cGyGj0GW7IyKg42+wLaZgI=
=WQf5
-END PGP SIGNATURE-

Bug#969360: Qt seccomp failure patch works

[John Scott]

Control: tags -1 - fixed-upstream

On Wednesday, September 2, 2020 8:02:42 AM EDT Dmitry Shachnev wrote:
> My guess is that we need this patch (not applied upstream yet)
Thanks for the pointer, that patch applies cleanly and fixes the issue.

> But that bug (QTBUG-81313) is already fixed in Qt 5.14.2. So we are
> probably seeing something else.
I saw that and figured it might've been a mistake on their part. It's even the 
same syscalls that are failing the issue's so similar, but perhaps their fix 
was incomplete.

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

Bug#969301: mutool: add OpenSSL support

[John Scott]

Package: mupdf-tools
Version: 1.17.0+ds1-1
Severity: normal
X-Debbugs-Cc: 

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

It appears mutool can't verify signed PDFs because it wasn't built
with OpenSSL support:
$ mutool sign -v signed.pdf
verifying signature 81
error: No OpenSSL support.
error processing signatures: No OpenSSL support.

I realize that since MuPDF uses the AGPL this is probably due to the
licenses clashing, but OpenSSL 3.0 with Apache v2 is in experimental
and might help the situation.

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

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

Versions of packages mupdf-tools depends on:
ii  libc62.31-3
ii  libfreetype6 2.10.2+dfsg-3
ii  libharfbuzz0b2.6.7-1
ii  libjbig2dec0 0.18+20200417-1
ii  libjpeg62-turbo  1:2.0.5-1.1
ii  libmujs1 1.0.7-2
ii  libopenjp2-7 2.3.1-1
ii  zlib1g   1:1.2.11.dfsg-2

mupdf-tools recommends no packages.

mupdf-tools suggests no packages.

- -- no debconf information

-BEGIN PGP SIGNATURE-

iHUEARYIAB0WIQT287WtmxUhmhucNnhyvHFIwKstpwUCX0w2+wAKCRByvHFIwKst
pzXyAQCCinw22u/+ybD5TY6Tuj7fw2tjJaSfLlNq1KAyUU9drwEAneq+lXb8VSSR
3bgznUa4jjNkctSKepUTnd2RVOyhSQY=
=XB4r
-END PGP SIGNATURE-

Bug#969360: Qt seccomp failure fixed upstream

[John Scott]

Control: forwarded -1 https://bugreports.qt.io/browse/QTBUG-81313
Control: tags -1 upstream fixed-upstream

It turns out it is a clash both with Chromium (powers Qt WebEngine) and glibc. 
Check out the Red Hat bugs
https://bugzilla.redhat.com/show_bug.cgi?id=1812482 (Qt)
https://bugzilla.redhat.com/show_bug.cgi?id=1773289 (Chromium)

The Chromium package also doesn't work on i386; that's bug #965960.

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

Bug#967011: Bug#969360: libqt5webengine5: [i386] seccomp-bpf failure in syscall 0403 (clock_gettime64)

[John Scott]

Control: severity -1 serious
Control: affects -1 konqueror

(Forgot to send this to the bug; only sent to the submitter first time around.)

On Tuesday, September 1, 2020 2:32:54 PM EDT you wrote:
> I am pretty sure, the issue appeared with the change from 5.12 to 5.14, 
around 5th of july. Checked the other logs, but there were no major changes.

That was a big version jump, so I bet you're probably right. I just noticed an 
interesting changelog entry however:

qtwebengine-opensource-src (5.14.2+dfsg1-3) unstable; urgency=medium

* Add a patch to build openh264 with -DX86_32_PICASM on i386, to fix errors
from new linker (closes: #965328).

I have been able to reproduce this in a fresh virtual machine, and in addition 
to KMail it also affects Konqueror and friends. Since it's unusable on i386, 
I'm making this bug serious.

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