Bug#947929: Forwarded to upstream

[Silvério Santos]

Control: Forwarded -1 https://github.com/frescobaldi/frescobaldi/issues/1341

Bug#978041: join display problem

[David Mohammed]

I would retest with gnome-shell on your setup.

This is highly likely to be either a gnome mutter issue or a graphics
driver issue rather than a budgie desktop specific issue since budgie is
highly dependent on those components.


On Fri, 25 Dec 2020, 00:06 Mina Morcose Farage, <3409...@gmail.com> wrote:

> Package: budgie-desktop
> Version: 10.5.2-2
> Severity: minor
>
> hi
>
> i have an external monitor beside my laptop monitor when i try to change
> it to extended mode or as called in budgie " Join Display " my external
> monitor turn to be crumbled it's like the display has been splitted to
> small boxes and overlayed over each other
>
> to reproduce this problem you have to make the external  monitor on the
> left and to be primary and try to apply the mode and to bypass this issue
> you should to make it to the right
>
> Thank you
> Mina Morcose Farage
>
>
>

Bug#973610: Install from buster-backports

[Kimiaki Kuno]

Hi Michael,

Thank you for your reply.
Today I did these commands as follows: then cairosvg successfully installed.

apt update
apt -t buster-backports install cairosvg

I had forgotten the -t option to install cleary backports packages.
Thank you for your great support.

Regards,
Kimiaki

2020年12月10日(木) 6:48 Michael Fladischer :
>
> Hi Kimiaki,
>
> the "cairosvg" package is only available in buster-backports on your
> installation. So when running "apt install cairosvg" you are
> automatically selecting cairosvg-2.4.2-1~bpo10+1 from the
> buster-backports archive.
>
> python3-cairosvg is not found because you told apt to only use the main
> archive. Instead please run:
>
> apt -t buster-backports install cairosvg
>
> Regards,
> Michael

Bug#977649:

[Damir Islamov]

upstream: https://github.com/ksnip/kImageAnnotator/issues/185[1] 




Sincerely yours
Damir Islamov
email: da...@secretlaboratory.ru



[1] https://github.com/ksnip/kImageAnnotator/issues/185


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

Bug#978048: lintian: KillMode=none unsafe in systemd service files

[Paul Wise]

Package: lintian
Version: 2.104.0
Severity: wishlist

systemd complains about KillMode=none in systemd service files, I think
lintian should also warn about this so that packages in Debian are more
likely to get fixed before the eventual removal of this feature.

Dec 25 11:58:55 systemd[1]: /lib/systemd/system/plymouth-start.service:16: Unit 
configured to use KillMode=none.
  This is unsafe, as it disables systemd's process 
lifecycle management for the service.
  Please update your service to use a safer KillMode=, 
such as 'mixed' or 'control-group'.
  Support for KillMode=none is deprecated and will 
eventually be removed.

-- System Information:
Debian Release: bullseye/sid
  APT prefers testing-debug
  APT policy: (900, 'testing-debug'), (900, 'testing'), (800, 
'unstable-debug'), (800, 'unstable'), (790, 'buildd-unstable'), (700, 
'experimental-debug'), (700, 'experimental'), (690, 'buildd-experimental')
Architecture: amd64 (x86_64)

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

Versions of packages lintian depends on:
ii  binutils2.35.1-5
ii  bzip2   1.0.8-4
ii  diffstat1.63-1
ii  dpkg1.20.5
ii  dpkg-dev1.20.5
ii  file1:5.39-3
ii  gettext 0.19.8.1-10
ii  gpg 2.2.20-1
ii  intltool-debian 0.35.0+20060710.5
ii  libapt-pkg-perl 0.1.36+b4
ii  libarchive-zip-perl 1.68-1
ii  libcapture-tiny-perl0.48-1
ii  libclass-xsaccessor-perl1.19-3+b6
ii  libclone-perl   0.45-1+b1
ii  libconfig-tiny-perl 2.24-1
ii  libcpanel-json-xs-perl  4.25-1+b1
ii  libdata-dpath-perl  0.58-1
ii  libdata-validate-domain-perl0.10-1
ii  libdevel-size-perl  0.83-1+b2
ii  libdpkg-perl1.20.5
ii  libemail-address-xs-perl1.04-1+b3
ii  libfile-basedir-perl0.08-1
ii  libfile-find-rule-perl  0.34-1
ii  libfont-ttf-perl1.06-1
ii  libhtml-html5-entities-perl 0.004-1
ii  libipc-run3-perl0.048-2
ii  libjson-maybexs-perl1.004003-1
ii  liblist-compare-perl0.55-1
ii  liblist-moreutils-perl  0.430-2
ii  liblist-utilsby-perl0.11-1
ii  libmoo-perl 2.004004-1
ii  libmoox-aliases-perl0.001006-1
ii  libnamespace-clean-perl 0.27-1
ii  libpath-tiny-perl   0.114-1
ii  libperlio-gzip-perl 0.19-1+b7
ii  libproc-processtable-perl   0.59-2+b1
ii  libsereal-decoder-perl  4.018+ds-1+b1
ii  libsereal-encoder-perl  4.018+ds-1+b1
ii  libtext-glob-perl   0.11-1
ii  libtext-levenshteinxs-perl  0.03-4+b8
ii  libtext-markdown-discount-perl  0.12-1+b1
ii  libtext-xslate-perl 3.5.8-1+b1
ii  libtime-duration-perl   1.21-1
ii  libtime-moment-perl 0.44-1+b3
ii  libtimedate-perl2.3300-1
ii  libtry-tiny-perl0.30-1
ii  libtype-tiny-perl   1.012000-1
ii  libunicode-utf8-perl0.62-1+b2
ii  liburi-perl 5.05-1
ii  libxml-libxml-perl  2.0134+dfsg-2+b1
ii  libyaml-libyaml-perl0.82+repack-1+b1
ii  lzip1.21-8
ii  lzop1.04-2
ii  man-db  2.9.3-2
ii  patchutils  0.4.2-1
ii  perl [libdigest-sha-perl]   5.32.0-6
ii  t1utils 1.41-4
ii  unzip   6.0-25
ii  xz-utils5.2.4-1+b1

lintian recommends no packages.

Versions of packages lintian suggests:
ii  binutils-multiarch 2.35.1-5
ii  libtext-template-perl  1.59-1

Versions of other relevant packages:
ii  systemd  247.1-3+deb11u1

-- no debconf information

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


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

Bug#978047: debian-multimedia: A source-only upload is required for testing migration

[Boyuan Yang]

Source: debian-multimedia
Version: 0.9
Severity: important
X-Debbugs-CC: rossgam...@debian.org siret...@tauware.de

Dear Debian debian-multimedia package maintainer,

The latest upload of package debian-multimedia was not a source-only
upload. As a result, v0.9 did not migrate to Testing. If this issue is
not fixed, the new version will miss Debian 11 release due to
approaching soft and hard freeze.

Please make another source-only upload as described in
https://wiki.debian.org/SourceOnlyUpload . Thanks!

-- 
Regards,
Boyuan Yang


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

Bug#978046: bless: ignore/reload nonresponsive unless scrolled to top

[tom]

Package: bless
Version: 0.6.0-5.1
Severity: important

I opened a file in bless, from Nautilus file
manager.

I just wanted to view it to find out if I needed 
it for anything. A message said, file on disk 
has changed, with two buttons:
ignore
reload
and a warning, "reload is the only safe option".

The buttons were nonresponsive. The program would not close.
I expected the program would at least close,
making no changes. 

kill proved ineffective, but I only tried the 
default signal.

Scrolling to the top of the file made the ignore/reload
buttons active. Choosing one made the 
message and buttons disappear.

The program could then be closed. No other 
program works this way. It is not intuitive that
scrolling to the top of an open file does not
logically relate to closing an application.

I also don't know why the message 'file on disk has changed' 
appeared in the first place. None of this is 
particularly disturbing.

But the documentation is a bit lacking in how 
bless handles files. Without knowing that, it's
impossible to ever figure this stuff out.

I mean everything in the nicest possible 
way.

Merry Christmas and Happy New Year.  

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

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

Versions of packages bless depends on:
ii  libc6  2.28-10
ii  libglade2.0-cil2.12.40-2
ii  libglib2.0-cil 2.12.40-2
ii  libgtk2.0-cil  2.12.40-2
ii  libmono-corlib4.5-cil  5.18.0.240+dfsg-3
ii  libmono-posix4.0-cil   5.18.0.240+dfsg-3
ii  libmono-system-xml4.0-cil  5.18.0.240+dfsg-3
ii  libmono-system4.0-cil  5.18.0.240+dfsg-3
ii  mono-runtime   5.18.0.240+dfsg-3

bless recommends no packages.

bless suggests no packages.

-- no debconf information

Bug#978045: apache2-bin: Immediate exit with "AH00141: Could not initialize random number generator"

[David W]

Package: apache2-bin
Version: 2.4.46-2
Severity: important

On my machine, /usr/sbin/apache2 fails to start with the following message:

[Thu Dec 24 15:38:01.052051 2020] [:crit] [pid 15725] (38)Function not
implemented: AH00141: Could not initialize random number generator

This happens very early, before reading conffiles or parsing command-line
arguments.

The error comes from line 5674 here:
https://svn.apache.org/viewvc/httpd/httpd/trunk/server/core.c?revision=1884431&view=markup#l5674
and is due to a failure in apr_generate_random_bytes().

You can see that the associated call/failure is happening inside APR here,
on
line 216:
https://svn.apache.org/viewvc/apr/apr/trunk/misc/unix/rand.c?revision=1832691&view=markup#l216

The issue is that if the library is configured (at build time) to
USE_GETRANDOM, then it assumes that the getrandom() call will be available
and
if it fails it becomes a fatal error. On my system, I don't have getrandom()
because I'm running an ancient kernel, but others could (more legitimately)
have the option disabled on a recent custom-built kernel.

I think the correct fix is to not use that build-time option, and go back to
using DEV_RANDOM or whatever was being used previously. Alternatively, at
least document that a kernel with getrandom() support is required to use
apache2.

I'm not sure exactly when the packaging on this changed, but I know it was
broken in 2.4.46-1 and I *think* it worked in 2.4.43-1, although I can't
get a
copy of that to double-check anymore.


-- Package-specific info:

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

Kernel: Linux 3.14.15 (SMP w/4 CPU threads)
Locale: LANG=C, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages apache2-bin depends on:
ii  libapr1  1.7.0-4
ii  libaprutil1  1.6.1-5
ii  libaprutil1-dbd-sqlite3  1.6.1-5
ii  libaprutil1-ldap 1.6.1-5
ii  libbrotli1   1.0.9-2+b2
ii  libc62.31-5
ii  libcrypt11:4.4.17-1
ii  libcurl4 7.72.0-1
ii  libjansson4  2.13.1-1
ii  libldap-2.4-22.4.56+dfsg-1
ii  liblua5.2-0  5.2.4-1.1+b3
ii  libnghttp2-141.42.0-1
ii  libpcre3 2:8.39-13
ii  libssl1.11.1.1h-1
ii  libxml2  2.9.10+dfsg-6.3+b1
ii  perl 5.32.0-6
ii  zlib1g   1:1.2.11.dfsg-2

apache2-bin recommends no packages.

Versions of packages apache2-bin suggests:
ii  apache2-doc  2.4.46-2
pn  apache2-suexec-pristine | apache2-suexec-custom  
ii  links [www-browser]  2.21-1
ii  lynx [www-browser]   2.9.0dev.6-1
ii  w3m [www-browser]0.5.3-38+b1

Versions of packages apache2 depends on:
ii  apache2-data 2.4.46-2
ii  apache2-utils2.4.46-2
ii  dpkg 1.20.5
ii  init-system-helpers  1.60
ii  lsb-base 11.1.0
ii  mime-support 3.66
ii  perl 5.32.0-6
ii  procps   2:3.3.16-5

Versions of packages apache2 recommends:
ii  ssl-cert  1.0.40

Versions of packages apache2 suggests:
ii  apache2-doc  2.4.46-2
pn  apache2-suexec-pristine | apache2-suexec-custom  
ii  links [www-browser]  2.21-1
ii  lynx [www-browser]   2.9.0dev.6-1
ii  w3m [www-browser]0.5.3-38+b1

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

-- no debconf information

Bug#978044: wily: reproducible builds: Embeds user, group and umask in tarballs

[Vagrant Cascadian]

Source: wily
Severity: normal
Tags: patch
User: reproducible-bui...@lists.alioth.debian.org
Usertags: username umask
X-Debbugs-Cc: reproducible-b...@lists.alioth.debian.org

The tarballs /usr/share/doc/wily/wily.tar.gz and
/usr/share/doc/wily/tute.tar.gz contain the username, user id, group
name, group id and umask of the build environment in which they were
produced:

  
https://tests.reproducible-builds.org/debian/rb-pkg/bullseye/amd64/diffoscope-results/wily.html

  
drwxr-xr-x···0·pbuilder1··()·pbuilder1··()0·2019-08-21·10:11:18.00·tute/
  vs.
  
drwxrwxr-x···0·pbuilder2··()·pbuilder2··()0·2019-08-21·10:11:18.00·tute/


The attached patch fixes this by passing arguments to tar in
debian/rules to avoid embedding this metadata.


Thanks for maintaining wily!


live well,
  vagrant
From 8ee7445fb8376fec85b2f05b929a8881ce6b3d4b Mon Sep 17 00:00:00 2001
From: Vagrant Cascadian 
Date: Fri, 25 Dec 2020 00:01:32 +
Subject: [PATCH 1/8] debian/rules: Pass options to tar to generate
 reproducible tarballs.

Pass additional options to tar to ensure sort order, user id, group id
and pax headers are consistent between builds.

See "Full example":

   https://reproducible-builds.org/docs/archives/
---
 debian/rules | 14 ++
 1 file changed, 10 insertions(+), 4 deletions(-)

diff --git a/debian/rules b/debian/rules
index 7d38575..f21f401 100755
--- a/debian/rules
+++ b/debian/rules
@@ -53,10 +53,16 @@ install-stamp: build-stamp
 	install -m644 Doc/changes.txt debian/wily/usr/share/doc/wily/html
 	install -m644 Doc/*.html debian/wily/usr/share/doc/wily/html
 	install -m644 Doc/*.gif debian/wily/usr/share/doc/wily/html
-	cd Doc && GZIP="-9n" tar -czhf \
-		../debian/wily/usr/share/doc/wily/tute.tar.gz tute --mtime="@$(SOURCE_DATE_EPOCH)"
-	cd misc && GZIP="-9n" tar -czhf \
-		../debian/wily/usr/share/doc/wily/wily.tar.gz wily --mtime="@$(SOURCE_DATE_EPOCH)"
+	cd Doc && GZIP="-9n" tar --sort=name \
+		--mtime="@${SOURCE_DATE_EPOCH}" \
+		--owner=0 --group=0 --numeric-owner \
+		--pax-option=exthdr.name=%d/PaxHeaders/%f,delete=atime,delete=ctime \
+		-czhf ../debian/wily/usr/share/doc/wily/tute.tar.gz tute
+	cd misc && GZIP="-9n" tar --sort=name \
+		--mtime="@${SOURCE_DATE_EPOCH}" \
+		--owner=0 --group=0 --numeric-owner \
+		--pax-option=exthdr.name=%d/PaxHeaders/%f,delete=atime,delete=ctime \
+		-czhf ../debian/wily/usr/share/doc/wily/wily.tar.gz wily
 	touch install-stamp
 
 binary-indep: build install
-- 
2.20.1



signature.asc
Description: PGP signature

Bug#974860: Forwarded to upstream

[Sandro Knauß]

Hey Silvério,

thanks for forwanrding the bugs to upstream. I see you tried to update the 
Debian Bug Tracker(BTS)  two times. Pino already properly updated your bugs. 
Okay I was not exactly clear about the correct syntax. There are two way to 
interact with BTS. You can use sending mails to cont...@debian.org, than you 
have to send:

Forwarded 974860 https://bugs.kde.org/show_bug.cgi?id=430719

Or you send the mail to the bug itself ( 974...@bugs.debian.org) than you have 
to prefix the command with Control:

Control: Forwarded 974860 https://bugs.kde.org/show_bug.cgi?id=430719

Additionally you are able to replace the current bugnumber with -1 so you can 
shorten this to:

Control: Forwarded -1 https://bugs.kde.org/show_bug.cgi?id=430719

and please use only text-only mails. 

In the beginning it is hard to remember the differences and make a lot a 
failures. Sorry for not being that precise. You can find the documentation at 
https://bugs.debian.org. There is also a CLI from devscripts package  the 
command is called bts.

hefee

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

Bug#978008: libkwaylandserver5: undefined symbol: _ZN14KWaylandServer17XdgShellInterface14surfaceCreatedEPNS_24XdgShellSurfaceInterfaceE"

[Norbert Preining]

Hi Vincas,

> Package: libkwaylandserver5
> Version: 5.20.4-2

> /usr/bin/kwin: symbol lookup error: /lib/x86_64-linux-gnu/libkwin.so.5:
> undefined symbol:
> _ZN14KWaylandServer17XdgShellInterface14surfaceCreatedEPNS_24XdgShe
> llSurfaceInterfaceE

Which version of kwin do you have installed?

Seems like a missing breaks against old versions of kwin or so.

> It seems that I have go perform `full-upgrade` that removes `user-manager`. 
> After that KDE desktop works.

Yes, user-manager is going away. It is now a kcm and not a separate
program.

Best

Norbert

--
PREINING Norbert  https://www.preining.info
Accelia Inc. + IFMGA ProGuide + TU Wien + JAIST + TeX Live + Debian Dev
GPG: 0x860CDC13   fp: F7D8 A928 26E3 16A1 9FA0 ACF0 6CAC A448 860C DC13

Bug#973656: [Pkg-kde-extras] Bug#973656: digikam-private-libs wants libkf5akonadicontact5-20.08, but only libkf5akonadicontact5 is available

[Sandro Knauß]

Hey,

> digikam-private-libs can not be installed because of unmet dependencies.

There is no problem anymore installing digikam-private-libs 4:7.1.0-1. 
libkf5akonadicontact5  provides 
, as libkf5akonadicontact5-20.08 is a virtual package, that is provided by 
libkf5akonadicontact5 4:20.08.3-1 provides the virtual package  
libkf5akonadicontact5-20.08. You can see this looking at: 
apt  show libkf5akonadicontact5

At least on my sid system, I have digikam installed, so everything is fine.
But if you still have issues installing digikam, than please provide the 
output of the error.

hefee

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

Bug#978043: linux-image-5.10.0-trunk-amd64: irq 7: nobody cared (ryzen 3500u)

[Neil]

Package: src:linux
Version: 5.10.2-1~exp1
Severity: minor

Dear Maintainer,

Hello there,
I just wanted to report this dmesg message here,  I already reported it to
kernel.org and redhat's bugzilla (fedora),  but who knows, maybe reporting it
here before debian 11 gets released is worth it,  I hope it doesn't bother :)

[2.526137] irq 7: nobody cared (try booting with the "irqpoll" option)
[2.526166] CPU: 3 PID: 154 Comm: systemd-udevd Not tainted 5.10.0-trunk-
amd64 #1 Debian 5.10.2-1~exp1
[2.526167] Hardware name: LENOVO 20NECTO1WW/20NECTO1WW, BIOS R11ET40P (1.20
) 11/17/2020
[2.526168] Call Trace:
[2.526170]  
[2.526176]  dump_stack+0x6b/0x83
[2.526180]  __report_bad_irq+0x35/0xa7
[2.526181]  note_interrupt.cold+0xb/0x61
[2.526184]  handle_irq_event+0xa8/0xb0
[2.526186]  handle_fasteoi_irq+0x78/0x1c0
[2.526189]  asm_call_irq_on_stack+0x12/0x20
[2.526190]  
[2.526192]  common_interrupt+0xb0/0x130
[2.526194]  asm_common_interrupt+0x1e/0x40
[2.526198] RIP: 0010:copy_user_generic_string+0x2c/0x40
[2.526200] Code: cb 83 fa 08 72 27 89 f9 83 e1 07 74 15 83 e9 08 f7 d9 29
ca 8a 06 88 07 48 ff c6 48 ff c7 ff c9 75 f2 89 d1 c1 e9 03 83 e2 07  48 a5
89 d1 f3 a4 31 c0 0f 01 ca c3 0f 1f 80 00 00 00 00 0f 01
[2.526201] RSP: 0018:aa30c04bbd50 EFLAGS: 00040246
[2.526203] RAX: 7000 RBX: 93406249d000 RCX:
01b1
[2.526204] RDX:  RSI: 93406249d278 RDI:
55f78a2c8000
[2.526205] RBP: aa30c04bbe50 R08: 934044612fea R09:

[2.526206] R10: 9341f4aebc00 R11:  R12:
1000
[2.526206] R13: aa30c04bbe60 R14: 0002d000 R15:
1000
[2.526210]  copy_page_to_iter+0xdc/0x360
[2.526213]  generic_file_buffered_read+0x2f6/0xa90
[2.526217]  new_sync_read+0x115/0x1a0
[2.526219]  vfs_read+0xf4/0x180
[2.526221]  ksys_read+0x5f/0xe0
[2.526222]  do_syscall_64+0x33/0x80
[2.526224]  entry_SYSCALL_64_after_hwframe+0x44/0xa9
[2.526225] RIP: 0033:0x7fabab66d04e
[2.526227] Code: 0f 1f 40 00 48 8b 15 79 9f 00 00 f7 d8 64 89 02 48 c7 c0
ff ff ff ff eb ba 0f 1f 00 64 8b 04 25 18 00 00 00 85 c0 75 14 0f 05 <48> 3d 00
f0 ff ff 77 5a c3 66 0f 1f 84 00 00 00 00 00 48 83 ec 28
[2.526227] RSP: 002b:7ffc72939ad8 EFLAGS: 0246 ORIG_RAX:

[2.526228] RAX: ffda RBX: 55f78a29ad78 RCX:
7fabab66d04e
[2.526229] RDX: 0004 RSI: 55f78a29ad88 RDI:
000c
[2.526230] RBP: 55f78a255a30 R08: 55f78a29ad60 R09:
7fabab653be0
[2.526230] R10: 00040050 R11: 0246 R12:
0004
[2.526231] R13: 0004 R14: 55f78a29ad60 R15:
55f78a255a80
[2.526232] handlers:
[2.526242] [] amd_gpio_irq_handler
[2.526256] Disabling IRQ #7

As far as I'm concerned, it's harmless,  but I'm no expert.
Using that 'irqpoll' option does slow my system a lot, at least in my
experience. Therefore I boot with the defaults.



-- Package-specific info:
** Version:
Linux version 5.10.0-trunk-amd64 (debian-ker...@lists.debian.org) (gcc-10 
(Debian 10.2.1-1) 10.2.1 20201207, GNU ld (GNU Binutils for Debian) 2.35.1) #1 
SMP Debian 5.10.2-1~exp1 (2020-12-22)

** Command line:
BOOT_IMAGE=/boot/vmlinuz-5.10.0-trunk-amd64 
root=UUID=68d71330-4dc3-48e8-bc62-82fa0d066801 ro quiet

** Tainted: W (512)
 * kernel issued warning

** Kernel log:
[  137.289853] XFS (sda5): Unmounting Filesystem
[  195.003343] Lockdown: systemd-logind: hibernation is restricted; see man 
kernel_lockdown.7
[  195.011765] Lockdown: systemd-logind: hibernation is restricted; see man 
kernel_lockdown.7
[  195.013726] Lockdown: systemd-logind: hibernation is restricted; see man 
kernel_lockdown.7
[  197.017450] Lockdown: systemd-logind: hibernation is restricted; see man 
kernel_lockdown.7
[  197.026440] Lockdown: systemd-logind: hibernation is restricted; see man 
kernel_lockdown.7
[  197.028269] Lockdown: systemd-logind: hibernation is restricted; see man 
kernel_lockdown.7
[  198.135381] wlp4s0: deauthenticating from 4c:6e:6e:f9:5f:b7 by local choice 
(Reason: 3=DEAUTH_LEAVING)
[  198.191686] rtw_8822be :04:00.0: sta 4c:6e:6e:f9:5f:b7 with macid 0 left
[  198.293385] rtw_8822be :04:00.0: stop vif 3c:91:80:41:66:79 on port 0
[  198.521363] Lockdown: Xorg: raw io port access is restricted; see man 
kernel_lockdown.7
[  198.803786] rtw_8822be :04:00.0: start vif 3a:8e:f8:00:6f:e2 on port 0
[  199.543648] redshift-gtk[1661]: segfault at 18 ip 7f14bca367e0 sp 
7ffe1eef0ae8 error 4 in libgtk-3.so.0.2404.20[7f14bc7db000+374000]
[  199.543669] Code: da ff 48 8b 44 24 08 64 48 2b 04 25 28 00 00 00 75 0f 48 
83 c4 18 5b 5d 41 5c 41 5d 41 5e 41 5f c3 e8 04 95 da ff 0f 1f 40 00 <48> 8b 47 
18 48 8b 40 10 c3 0f 1f 80 00 00 00 00 53 48 8b 5f 18 48
[  199.854659] redshift-gtk[1704]: segfault at 18 ip 7f307c4067e0 sp 

Bug#978042: libwebkit2gtk-4.0-37: fails to run plugin

[Ben Chin]

Package: libwebkit2gtk-4.0-37
Version: 2.30.4-1~deb10u1
Severity: normal

Dear Maintainer,

When loading plugin, webkit complains it couldn't find WebKitPluginProcess with 
the following error message:

Unable to fork a new child process: Failed to execute child process 
“/usr/lib/x86_64-linux-gnu/webkit2gtk-4.0/WebKitPluginProcess” (No such file or 
directory) 

I have downloaded and built the source of this package. I found that
WebKitPluginProcess was actually built but wasn't copied to the installation
directory after "sudo make install". If I manually copy WebKitPluginProcess to 
/usr/lib/x86_64-linux-gnu/webkit2gtk-4.0/ then the plugin will work.

That's all. Thank you for your attention.


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

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

Versions of packages libwebkit2gtk-4.0-37 depends on:
ii  bubblewrap  0.3.1-4
ii  libatk1.0-0 2.30.0-2
ii  libc6   2.28-10
ii  libcairo-gobject2   1.16.0-4
ii  libcairo2   1.16.0-4
ii  libegl1 1.1.0-1
ii  libenchant1c2a  1.6.0-11.1+b1
ii  libfontconfig1  2.13.1-2
ii  libfreetype62.9.1-3+deb10u2
ii  libgcc1 1:8.3.0-6
ii  libgcrypt20 1.8.4-5
ii  libgdk-pixbuf2.0-0  2.38.1+dfsg-1
ii  libgl1  1.1.0-1
ii  libglib2.0-02.58.3-2+deb10u2
ii  libgstreamer-gl1.0-01.14.4-2
ii  libgstreamer-plugins-base1.0-0  1.14.4-2
ii  libgstreamer1.0-0   1.14.4-1
ii  libgtk-3-0  3.24.5-1
ii  libharfbuzz-icu02.3.1-1
ii  libharfbuzz0b   2.3.1-1
ii  libhyphen0  2.8.8-7
ii  libicu6363.1-6+deb10u1
ii  libjavascriptcoregtk-4.0-18 2.30.4-1~deb10u1
ii  libjpeg62-turbo 1:1.5.2-2+deb10u1
ii  libnotify4  0.7.7-4
ii  libopenjp2-72.3.0-2+deb10u1
ii  libpango-1.0-0  1.42.4-8~deb10u1
ii  libpangocairo-1.0-0 1.42.4-8~deb10u1
ii  libpng16-16 1.6.36-6
ii  libseccomp2 2.3.3-4
ii  libsecret-1-0   0.18.7-1
ii  libsoup2.4-12.64.2-2
ii  libsqlite3-03.27.2-3+deb10u1
ii  libstdc++6  8.3.0-6
ii  libsystemd0 241-7~deb10u5
ii  libtasn1-6  4.13-3
ii  libwayland-client0  1.16.0-1
ii  libwayland-egl1 1.16.0-1
ii  libwayland-server0  1.16.0-1
ii  libwebp60.6.1-2
ii  libwebpdemux2   0.6.1-2
ii  libwoff11.0.2-1
ii  libx11-62:1.6.7-1+deb10u1
ii  libxcomposite1  1:0.4.4-2
ii  libxdamage1 1:1.1.4-3+b3
ii  libxml2 2.9.4+dfsg1-7+deb10u1
ii  libxrender1 1:0.9.10-1
ii  libxslt1.1  1.1.32-2.2~deb10u1
ii  libxt6  1:1.1.5-1+b3
ii  xdg-dbus-proxy  0.1.1-1
ii  zlib1g  1:1.2.11.dfsg-1

Versions of packages libwebkit2gtk-4.0-37 recommends:
ii  gstreamer1.0-gl1.14.4-2
ii  gstreamer1.0-libav 1.15.0.1+git20180723+db823502-2
ii  gstreamer1.0-plugins-good  1.14.4-1
ii  gstreamer1.0-pulseaudio1.14.4-1
ii  libgl1-mesa-dri18.3.6-2+deb10u1

libwebkit2gtk-4.0-37 suggests no packages.

-- no debconf information

Bug#978041: join display problem

[Mina Morcose Farage]

Package: budgie-desktop
Version: 10.5.2-2
Severity: minor

hi

i have an external monitor beside my laptop monitor when i try to change it
to extended mode or as called in budgie " Join Display " my external
monitor turn to be crumbled it's like the display has been splitted to
small boxes and overlayed over each other

to reproduce this problem you have to make the external  monitor on the
left and to be primary and try to apply the mode and to bypass this issue
you should to make it to the right

Thank you
Mina Morcose Farage

Bug#966621: Many people have entire music collections on /var/tmp

[積丹尼 Dan Jacobson]

Anyways, in any NEWS.Debian.gz file, one would need to say
"Coming changes next month: We will start cleaning "
otherwise if you just say
"This version now cleans "
most users will not have enough time to move various projects
temp files off of there before they get wiped out.
E.g., some surveillance camera that cycles a month's worth of videos there.

Bug#902887: -dbgsym not working

[Matija Nalis]

Well, does FPC actually support building in a way that allow dbgsym
packages?

Specifically, with most basic dh(1) debian/rules, I'm getting
"dh_strip: warning: Could not find the BuildID in 
debian/ironseed/usr/libexec/ironseed/main"
warnings in sid with fpc 3.2.0+dfsg-8, and resulting -dbgsym file is unusable 
by gdb.

I've tried various compilation options, last one being: 
fpc -Mtp -g -gl -gv -fPIC -C3 -Ci -Co -CO  -O1 -gw -godwarfsets  -gt -vewnhiq   
-Sa -Sy -Sewnh -vm4049 -k-lSDL_mixer -k-lSDL -k-lm -k'-z relro' -k'-z now' 
-k-pie main.pas

that works for debugging with gdb when symbols are not extracted, but not in 
-dbgsym case.

(package is currently at 
https://incoming.debian.org/debian-buildd/pool/main/i/ironseed/ironseed_0.3.2-2.dsc)

Do we have some other packages using fpc, which have working -dbgsym?
Or does fpc itself need some changes for it to work?


-- 
Opinions above are GNU-copylefted.

Bug#973656: digikam-private-libs wants libkf5akonadicontact5-20.08, but only libkf5akonadicontact5 is available

[Thomas Florek]

Package: digikam-private-libs
Followup-For: Bug #973656

digikam-private-libs can not be installed because of unmet dependencies.

From control in extracted package:
...
Depends: ... libkf5akonadicontact5 (>= 4:20.08.3), 
libkf5akonadicontact5-20.08, ...

...

There is no libkf5akonadicontact5-20.08 in any Debian repo:

# LANG=C apt-cache search libkf5akonadicontact5-20.08
libkf5akonadicontact5 - Akonadi contacts access library



-- System Information:
Debian Release: bullseye/sid
  APT prefers buildd-unstable
  APT policy: (500, 'buildd-unstable'), (500, 'unstable'), (500, 
'testing'), (500, 'stable'), (1, 'experimental')

Architecture: amd64 (x86_64)

Kernel: Linux 5.9.15-towo.1-siduction-amd64
(SMP w/2 CPU threads; PREEMPT)
Kernel taint flags: TAINT_OOT_MODULE
Locale: LANG=de_DE.utf8, LC_CTYPE=de_DE.utf8 (charmap=UTF-8),
LANGUAGE=de
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled



digikam-private-libs recommends no packages.

digikam-private-libs suggests no packages.

-- no debconf information

Bug#971760: systemd: Error messages about XDG autostart after logging in as root

[Kurt Roeckx]

On Mon, Dec 21, 2020 at 05:58:55PM +0100, Michael Biebl wrote:
> 
> Doing so now.
> If you feel comfortable sharing the above information via private
> email, you can send it to me directly. I'll promise to not disclose any
> information without your prior consent.

I can't reproduce it anymore currently.

I now have systemd 247.1-3+deb11u1 installed.


Kurt

Bug#907449: liblzma: undefinited reference when link with lzma static library

[Sebastian Andrzej Siewior]

control: tags -1 patch

On 2018-08-28 21:14:34 [-0700], Jonathan Nieder wrote:
> Thanks for reporting.  I should be able to look into this this weekend.

The static build should enable threads. Patch attached.



> Sincerely,
> Jonathan

Sebastoam
From: Sebastian Andrzej Siewior 
Date: Fri, 25 Dec 2020 00:23:59 +0100
Subject: [PATCH] Enable threads for static builds.

Signed-off-by: Sebastian Andrzej Siewior 
---
 debian/changelog | 1 +
 debian/rules | 2 +-
 2 files changed, 2 insertions(+), 1 deletion(-)

diff --git a/debian/changelog b/debian/changelog
index 9af662ae1af28..f8003ef8b3680 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -3,6 +3,7 @@ xz-utils (5.2.4-1.1) UNRELEASED; urgency=medium
   * Non-maintainer upload.
   * Add % target to the rules file to work with newer debhelper
 (Closes: #945961).
+  * Enable threads for static builds (Closes: #907449).
 
  -- Sebastian Andrzej Siewior   Thu, 24 Dec 2020 14:34:19 +0100
 
diff --git a/debian/rules b/debian/rules
index 7e0676e31eb7a..d805ccefe564c 100755
--- a/debian/rules
+++ b/debian/rules
@@ -74,7 +74,7 @@ debian/normal-build/Makefile debian/normal-build/Doxyfile: $(configure_input)
 debian/static-build/Makefile: $(configure_input)
 	dh_auto_configure --builddirectory debian/static-build -- \
 		$(opt_reproduce) \
-		--disable-threads --disable-shared \
+		--enable-threads --disable-shared \
 		--enable-liblzma2-compat \
 		$(opt_optimize) $(opt_quiet) \
 		--disable-lzmainfo --disable-scripts \
-- 
2.29.2

Bug#978011: udev: uaccess is set before ID_SMARTCARD_READER

[Vincent Pelletier]

Hello Michael,

Thanks for your very prompt reaction.

On Thu, 24 Dec 2020 22:32:55 +0100, Michael Biebl  wrote:
> TBH, I can't answer that downstream, as I have no knowledge in that 
> specific area. What I did find is, that some packages, like gpg, do set 
> this variable prior to 70-uaccess.

Correct, and I have such rules installed. As udev/systemd itself
contains the rules I posted, I considered there is an intent to
autonomously set this access for devices which cleanly expose their
CCID compatibility, so I did not bring those into the report.

Also, my device using a very generic vendor & device number (which is
probably not very good practice, but I do not think as a hobbyist
developer I have what it takes to get my own vendor id from USB-IF...
but I think this I am getting off-topic), the approach used in gnupg
rules do not suit this device.

> I'm not sure if this specific rule you posted above is supposed to get 
> the uaccess tag or not.
> At a cursory glance, this might indeed be an oversight, but I'm not 
> sure. Could you raise this upstream please at
> https://github.com/systemd/systemd/issues

Thanks for the suggestion, I opened an issue upstream:
  https://github.com/systemd/systemd/issues/18079

Regards,
-- 
Vincent Pelletier


pgpeEZbqORxBQ.pgp
Description: Signature digitale OpenPGP

Bug#978040: Warning: (9034) "crtbeginS.o" not found (on non-intel architectures)

[Matija Nalis]

Package: fpc
Version: 3.2.0+dfsg-8
Severity: normal
X-Debbugs-Cc: mnalis-debian...@voyager.hr

Dear Maintainer,

   * What led up to the situation?

trying to compile my source throws warnings (which subsequently causes failure 
to build due to "-Sewnh". 
I can of course remove that option and continue build even in presence of 
warnings, but would like to fix 
the  problem at the source, as it is simple fix):

fpc -Mtp -g -gl -gv -fPIC -C3 -Ci -Co -CO  -O1 -gw -godwarfsets  -gt -vewnhiq   
-Sa -Sy  -vm4049 -Sewnh -k-lSDL_mixer -k-lSDL -k-lm -k'-z relro' -k'-z now' 
-k-pie is.pas
Hint: (11030) Start of reading config file /etc/fpc.cfg
Hint: (11031) End of reading config file /etc/fpc.cfg
Free Pascal Compiler version 3.2.0+dfsg-8 [2020/08/22] for arm
Copyright (c) 1993-2020 by Florian Klaempfl and others
(1002) Target OS: Linux for ARMHF
(3104) Compiling is.pas
(3104) Compiling _paths_.pas
(9015) Linking is
is.pas(86,1) Warning: (9034) "crtbeginS.o" not found, this will probably cause 
a linking failure
is.pas(86,1) Warning: (9034) "crtendS.o" not found, this will probably cause a 
linking failure
is.pas(86,1) Fatal: (10026) There were 2 errors compiling module, stopping
Fatal: (1018) Compilation aborted
Error: /usr/bin/ppcarm returned an error exitcode
make: *** [Makefile:83: is] Error 1

   * What exactly did you do (or not do) that was effective (or
 ineffective)?

it seems that required /usr/lib/gcc/X/ library path is not included on 
fpc.cfg on ARM architectures
(https://buildd.debian.org/status/package.php?p=ironseed shows that warnings at 
least for arm64, armel, armhf)

It is mentioned in FAQ at 
https://wiki.lazarus.freepascal.org/Lazarus_Faq#I_receive_a_warning_during_the_linking_that_states:_Warning:_.22crtbeginS.o.22_.28or_.22crtendS.o.22.29_not_found
and manually adding "-Fl/usr/lib/gcc/arm-linux-gnueabihf/10" to 
/etc/fpc-3.2.0.cfg fixes the problem.
Similar library path is already present for amd64/i386 inside ifdef marked with 
"# path to the gcclib".
It should be simple to add it to non-intel architectures too.

   * What was the outcome of this action?

The two warnings show above appear (and so build fails due to '-Sewnh')

   * What outcome did you expect instead?

No warnings, and sucessful build on ARM.


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

Kernel: Linux 5.2.0-0.bpo.2-amd64 (SMP w/2 CPU threads)
Locale: LANG=C, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: unable to detect

Versions of packages fpc depends on:
ii  fp-docs-3.2.0   3.2.0+dfsg-8
ii  fp-utils-3.2.0  3.2.0+dfsg-8
ii  fpc-3.2.0   3.2.0+dfsg-8

fpc recommends no packages.

fpc suggests no packages.

-- no debconf information

Bug#978039: opensmtpd: CVE-2020-35680

[Salvatore Bonaccorso]

Source: opensmtpd
Version: 6.8.0p1~rc1-1
Severity: important
Tags: security upstream
X-Debbugs-Cc: car...@debian.org, Debian Security Team 

Hi,

The following vulnerability was published for opensmtpd.

CVE-2020-35680[0]:
| smtpd/lka_filter.c in OpenSMTPD before 6.8.0p1, in certain
| configurations, allows remote attackers to cause a denial of service
| (NULL pointer dereference and daemon crash) via a crafted pattern of
| client activity, because the filter state machine does not properly
| maintain the I/O channel between the SMTP engine and the filters
| layer.


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

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2020-35680
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-35680
[1] 
https://github.com/openbsd/src/commit/6c3220444ed06b5796dedfd53a0f4becd903c0d1
[2] https://www.mail-archive.com/misc@opensmtpd.org/msg05188.html

Regards,
Salvatore

Bug#978038: opensmtpd: CVE-2020-35679

[Salvatore Bonaccorso]

Source: opensmtpd
Version: 6.8.0p1~rc1-1
Severity: important
Tags: security upstream
X-Debbugs-Cc: car...@debian.org, Debian Security Team 

Hi,

The following vulnerability was published for opensmtpd.

CVE-2020-35679[0]:
| smtpd/table.c in OpenSMTPD before 6.8.0p1 lacks a certain regfree,
| which might allow attackers to trigger a "very significant" memory
| leak via messages to an instance that performs many regex lookups.


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

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2020-35679
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-35679
[1] 
https://github.com/openbsd/src/commit/79a034b4aed29e965f45a13409268290c9910043
[2] https://www.mail-archive.com/misc@opensmtpd.org/msg05188.html

Please adjust the affected versions in the BTS as needed.

Regards,
Salvatore

Bug#976718: why replacing he previous version if the newer one is intentionaly non-working?

[Luc Maisonobe]

Fastboot *is* important.

It is the only way we can unlock some phones to install free alternative
like lineageos.

If the new version cannot be built, then why replacing the old working
version with an explicitly non-working script? What is the point
in replacing a working version when no alternative is available?

Now users are stuck trying to find their way to snapshot.debian.org and
make sense of hidden dependencies.

I would very much like to see the rationale here.

Bug#977329: krita segfaults when try to open with libQt5Gui.so.5.15.1

[Pino Toscano]

reassign 977329 lxqt-qtplugin
retitle 977329 lxqt-plugin: platform theme needs fixes for Qt 5.15
tag 977329 = fixed-upstream
severity 977329 serious
thanks

Hi,

In data giovedì 24 dicembre 2020 20:48:32 CET, proctor ha scritto:
> hi! thanks very much for your help.
> 
> the krita segfault still happens with all latest updates, including the
> most recent kernel 5.9.0-5-amd64
> 
> krita crashes at open. when i select the krita program from the menu
> nothing happens at all.
> when i run like this:
> $ krita
> Segmentation fault
> 
> that's what happens
> 
> i'm using lxqt

Thanks for the detail about this, and most probably you have
lxqt-qtplugin installed, right? I see that the there were various fixes
upstream related to the compatibility with Qt 5.15 and color palettes,
and I would not be surprised that any of these issues would cause a
crash:
https://github.com/lxqt/lxqt-qtplugin/issues/54
https://github.com/lxqt/lxqt-qtplugin/pull/55
https://github.com/lxqt/lxqt-qtplugin/commit/8cc32d94b4c9de74b5bcf27fae2d10e6b2b11caf
It looks like everything is included in the new upstream release 0.16.0,
which then needs to be packaged in Debian.

Another check you can do is try to run krita in a different desktop
environment / window manager than LxQt.

Hence, I'm reassigning this to lxqt-qtplugin with proper metadata.

Thanks for your report,
-- 
Pino Toscano

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

Bug#978037: ITP: golang-github-mohae-deepcopy -- create deep copies of things

[Cyril Brulebois]

Package: wnpp
Severity: wishlist
Owner: Cyril Brulebois 

* Package name: golang-github-mohae-deepcopy
  Version : 0.0~git20170929.c48cc78-1
  Upstream Author : Joel Scoble
* URL : https://github.com/mohae/deepcopy
* License : Expat
  Programming Lang: Go
  Description : create deep copies of things

 A standard copy would only copy the pointers, while deepcopy copies the
 values pointed to. Unexported field values are not copied.


Part of the crowdsec packaging effort:
  https://lists.debian.org/debian-go/2020/12/msg00019.html


Cheers,
Cyril.
-- 
Cyril Brulebois -- Debian Consultant @ DEBAMAX -- https://debamax.com/


signature.asc
Description: PGP signature

Bug#978011: udev: uaccess is set before ID_SMARTCARD_READER

[Michael Biebl]

Hello Vincent

Am 24.12.20 um 12:04 schrieb Vincent Pelletier:

I have a smartcard reader which exposes the CCID class (0x0b) on its function.
I see there are udev rules to grant uaccess based on this:

   $ rgrep SMARTCARD /lib/udev/rules.d
   70-uaccess.rules:ENV{ID_SMARTCARD_READER}=="?*", TAG+="uaccess"
   99-systemd.rules:SUBSYSTEM=="usb", ENV{DEVTYPE}=="usb_device", 
ENV{ID_USB_INTERFACES}=="*:0b:*", ENV{ID_SMARTCARD_READER}="1"
   99-systemd.rules:ENV{ID_SMARTCARD_READER}=="?*", TAG+="systemd", 
ENV{SYSTEMD_WANTS}+="smartcard.target", ENV{SYSTEMD_USER_WANTS}+="smartcard.target"

Which make me think that there is an intent to grant uaccess to these devices.

but while the ones in 99-systemd.rules have an effect (see below for
"udevadm info", note ID_SMARTCARD_READER=1 and
SYSTEMD_*WANTS=smartcard.target being present), the TAG+="uaccess" does not.

I suspect this is because of the file ordering: 70-uaccess vs. 99-systemd .

Wouldn't it make more sense to apply the uaccess rules after setting the
ID_SMARTCARD_READER flag ?

I have no special knowledge of these files, and I suspect it is not as easy as
reordering them. I guess a fix would rather be to set these flags much earlier,
then setting the uaccess rules in 60-uaccess.rules, and finally setting the
SYSTEMD_*WANTS in 99-sustemd.rules.


TBH, I can't answer that downstream, as I have no knowledge in that 
specific area. What I did find is, that some packages, like gpg, do set 
this variable prior to 70-uaccess.
I'm not sure if this specific rule you posted above is supposed to get 
the uaccess tag or not.
At a cursory glance, this might indeed be an oversight, but I'm not 
sure. Could you raise this upstream please at

https://github.com/systemd/systemd/issues

Regards,
Michael


[1] https://codesearch.debian.net/search?q=ID_SMARTCARD_READER&literal=1



OpenPGP_signature
Description: OpenPGP digital signature

Bug#978036: libmcpp0: Please apply patches from supertuxkart

[Witold Baryluk]

Package: libmcpp0
Version: 2.7.2-5
Severity: normal
X-Debbugs-Cc: witold.bary...@gmail.com

I don't know what is the upstream status of mcpp, but supertuxkart has
few important bug fixes:

https://github.com/supertuxkart/stk-code/commit/21cf075e419737879f6868643c16de6b612ae223#diff-57e7858f5e2f96d62d31eda3f49c2fe8be77f37b4406c29b7fd5ecbee1084c9b
https://github.com/supertuxkart/stk-code/commit/a79a2a7fabc181a4e0517d04d8cf9cd9300b4741#diff-57e7858f5e2f96d62d31eda3f49c2fe8be77f37b4406c29b7fd5ecbee1084c9b
https://github.com/supertuxkart/stk-code/commit/d729c543f97de29f130daa7bac79481eb09acd90#diff-57e7858f5e2f96d62d31eda3f49c2fe8be77f37b4406c29b7fd5ecbee1084c9b
https://github.com/supertuxkart/stk-code/commit/c8d036183710e2fd9ea2d819863e3400d04214fb#diff-57e7858f5e2f96d62d31eda3f49c2fe8be77f37b4406c29b7fd5ecbee1084c9b


You can see the list here:

https://github.com/supertuxkart/stk-code/commits/master/lib/mcpp

Personally I would love to see the valgrind and memory leak fixes in
Debian.

PS. I didn't try to contact upstream, as the last commits are from 2008.

There is also CVE-2019-14274, which is somehow addressed here:

https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-14274

As well these proposed fix:

https://sourceforge.net/p/mcpp/discussion/565342/thread/ef669864/?limit=25#7fb8



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

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

Versions of packages libmcpp0 depends on:
ii  libc6  2.31-5

libmcpp0 recommends no packages.

libmcpp0 suggests no packages.

-- no debconf information

Bug#978035: src:sublime-music: fails to migrate to testing for too long: Dependencies can't migrate

[Paul Gevers]

Source: sublime-music
Version: 0.9.1-2
Severity: serious
Control: close -1 0.11.10-1
Tags: sid bullseye
User: release.debian@packages.debian.org
Usertags: out-of-sync
Control: block -1 by 972803

Dear maintainer(s),

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

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

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

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

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

Paul

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




OpenPGP_signature
Description: OpenPGP digital signature

Bug#978034: src:tools-cli-clojure: fails to migrate to testing for too long: maintainer built arch:all binaries

[Paul Gevers]

Source: tools-cli-clojure
Version: 0.3.5-2
Severity: serious
Control: close -1 1.0.194-1
Tags: sid bullseye pending
User: release.debian@packages.debian.org
Usertags: out-of-sync

Dear maintainer(s),

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

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

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

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

Your package is only blocked because the arch:all binary package(s)
aren't built on a buildd. Unfortunately the Debian infrastructure
doesn't allow arch:all packages to be properly binNMU'ed. Hence, I will
shortly do a no-changes source-only upload to DELAYED/15, closing this
bug. Please let me know if I should delay or cancel that upload.

Paul

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




OpenPGP_signature
Description: OpenPGP digital signature

Bug#978033: node-autoprefixer: build ruby-autoprefixer-rails binary

[Pirate Praveen]

Package: node-autoprefixer
Version: 10.1.0+~cs11.3.2.0-1
Severity: wishlist

Now node-autoprefixer includes autoprefixer-rails as a component in 
source package (for its build directory). We can build 
ruby-autoprefixer-rails binary package from the same source and drop 
libjs-autoprefixer (there is no such independant browser library 
upstream and it was specifically created for use in 
autoprefixer-rails). This will reduce the maintenance burden.

Bug#947361: krita: Keyboard doesn't respond after some popups (f.e show color selector) are opened.

[Fenix]

Package: krita
Followup-For: Bug #947361
X-Debbugs-Cc: fenix...@gmail.com

Dear Maintainer,

I've just checked this issue in current Debian Testing Krita version and it was
fixed.

I'm closing this issue.


Thanks!



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

Kernel: Linux 5.9.0-5-amd64 (SMP w/12 CPU threads)
Locale: LANG=es_ES.UTF-8, LC_CTYPE=es_ES.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 krita depends on:
ii  krita-data1:4.4.1+dfsg-1
ii  libc6 2.31-5
ii  libexiv2-27   0.27.3-3
ii  libfftw3-double3  3.3.8-2
ii  libgcc-s1 10.2.1-1
ii  libgif7   5.1.9-1
ii  libgsl25  2.6+dfsg-2
ii  libheif1  1.9.1-1
ii  libilmbase25  2.5.3-2
ii  libjpeg62-turbo   1:2.0.5-1.1
ii  libkf5completion5 5.74.0-2
ii  libkf5configcore5 5.74.0-2
ii  libkf5configgui5  5.74.0-2
ii  libkf5coreaddons5 5.74.0-2
ii  libkf5crash5  5.74.0-2
ii  libkf5guiaddons5  5.74.0-3
ii  libkf5i18n5   5.74.0-3
ii  libkf5itemviews5  5.74.0-2
ii  libkf5widgetsaddons5  5.74.0-3
ii  libkf5windowsystem5   5.74.0-2
ii  liblcms2-22.9-4+b1
ii  libopencolorio1v5 1.1.1~dfsg0-7
ii  libopenexr25  2.5.3-2
ii  libopenjp2-7  2.3.1-1
ii  libpng16-16   1.6.37-3
ii  libpoppler-qt5-1  20.09.0-3
ii  libpython3.9  3.9.1-1
ii  libqt5concurrent5 5.15.2+dfsg-2
ii  libqt5core5a  5.15.2+dfsg-2
ii  libqt5dbus5   5.15.2+dfsg-2
ii  libqt5gui55.15.2+dfsg-2
ii  libqt5multimedia5 5.15.2-2
ii  libqt5network55.15.2+dfsg-2
ii  libqt5printsupport5   5.15.2+dfsg-2
ii  libqt5qml55.15.2+dfsg-2
ii  libqt5quick5  5.15.2+dfsg-2
ii  libqt5quickwidgets5   5.15.2+dfsg-2
ii  libqt5svg55.15.2-2
ii  libqt5widgets55.15.2+dfsg-2
ii  libqt5x11extras5  5.15.2-2
ii  libqt5xml55.15.2+dfsg-2
ii  libquazip5-1  0.9.1-1
ii  libraw20  0.20.2-1
ii  libstdc++610.2.1-1
ii  libtiff5  4.1.0+git201212-1
ii  libx11-6  2:1.6.12-1
ii  zlib1g1:1.2.11.dfsg-2

Versions of packages krita recommends:
ii  krita-gmic   2.4.5-1.1+b1
ii  python3-pyqt55.15.2+dfsg-1+b1
ii  python3-sip  4.19.24+dfsg-1+b2
ii  qml-module-qtmultimedia  5.15.2-2

Versions of packages krita suggests:
ii  colord  1.4.4-2
ii  ffmpeg  7:4.3.1-5
pn  krita-l10n  

-- no debconf information

Bug#978029: octave: unable to load appropriate font

[Sébastien Villemot]

Hi Stanislav,

Le jeudi 24 décembre 2020 à 19:11 +, Stanislav Maslovski a écrit :
> Package: octave
> Version: 6.1.0-2
> Severity: normal

> After testing octave --gui on a fresh Debian installation, I noticed that
> octave complains about being unable to load FreeSans OTF font when trying
> to create a simple 2D plot. As a result, nothing is plotted. Installing
> fonts-freefont-otf package resolved the problem.

> Possibly, a depends or recomends is missing?

octave depends on octave-common, which itself recommends fonts-
freefont-otf. So I don’t understand why fonts-freefont-otf was not
installed on your system.

In any case, I don’t see what should be changed at the octave level.

-- 
⢀⣴⠾⠻⢶⣦⠀  Sébastien Villemot
⣾⠁⢠⠒⠀⣿⡁  Debian Developer
⢿⡄⠘⠷⠚⠋⠀  https://sebastien.villemot.name
⠈⠳⣄  https://www.debian.org



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

Bug#978032: python-cobra: autopkgtest regression in testing

[Graham Inggs]

Source: python-cobra
Version: 0.19.0-1
Severity: serious
Tags: sid bullseye
X-Debbugs-CC: debian...@lists.debian.org
User: debian...@lists.debian.org
Usertags: regression

Hi Maintainer

The autopkgtests of python-cobra recently started to fail in testing [1].
I've copied what I hope is the relevant part of the log below.

Regards
Graham


[1] https://ci.debian.net/packages/p/python-cobra/testing/amd64/


 ERRORS 
__ ERROR at setup of TestManipulation.test_escape_ids __

filename = '/usr/lib/python3/dist-packages/cobra/test/data/textbook.xml.gz'
number = 
f_replace = {'F_GENE': ,
'F_GENE_REV': , 'F_GROUP':
, 'F_GROUP_REV': , ...}
kwargs = {}
doc =  >
cobra_error = CobraSBMLError('Something went wrong reading the SBML
model. Most likely the SBML model is not valid. Please check
tha...ame)`\nIf the model is valid and cannot be read please open an
issue at https://github.com/opencobra/cobrapy/issues .')

Bug#978031: swissknife: Please make another source-only upload for testing migration

[Boyuan Yang]

Source: swissknife
Version: 1.79-1
Severity: important
X-Debbugs-CC: ti...@debian.org moel...@debian.org

Dear Debian swissknife package maintainers,

The latest upload of package swissknife was not a source-only upload.
As a result, the new version cannot migrate to Debian Testing. If this
problem is not solved before release freeze, the new version will miss
Debian 11.

Please make a new source-only upload as described by
https://wiki.debian.org/SourceOnlyUpload . Thanks!

Regards,
Boyuan Yang


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

Bug#977329: krita segfaults when try to open with libQt5Gui.so.5.15.1

[proctor]

hi! thanks very much for your help.

the krita segfault still happens with all latest updates, including the
most recent kernel 5.9.0-5-amd64

krita crashes at open. when i select the krita program from the menu
nothing happens at all.
when i run like this:
$ krita
Segmentation fault

that's what happens

i'm using lxqt

i'm using xorg as far as i know. haven't installed wayland deliberately

===
here's output from dpkg regarding wayland and xorg:

# dpkg -l *wayland*

Desired=Unknown/Install/Remove/Purge/Hold


|
Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend


|/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad)


||/ NameVersion Architecture
Description

+++-===-===--
ii  kwayland-data   4:5.74.0-2  all  Qt library
wrapper for Wayland libraries - data files
ii  kwayland-integration:amd64  5.19.5-3amd64kwayland
runtime integration plugins
ii  libkf5waylandclient5:amd64  4:5.74.0-2  amd64Qt library
wrapper for Wayland libraries
ii  libqt5waylandclient5:amd64  5.15.2-2amd64QtWayland
client library
ii  libqt5waylandcompositor5:amd64  5.15.2-2amd64QtWayland
compositor library
ii  libva-wayland2:amd642.10.0-1amd64Video
Acceleration (VA) API for Linux -- Wayland runtime
ii  libwayland-client0:amd641.18.0-2~exp1.1 amd64wayland
compositor infrastructure - client library
ii  libwayland-cursor0:amd641.18.0-2~exp1.1 amd64wayland
compositor infrastructure - cursor library
ii  libwayland-egl1:amd64   1.18.0-2~exp1.1 amd64wayland
compositor infrastructure - EGL library
un  libwayland-egl1-mesa (no
description available)
ii  libwayland-server0:amd641.18.0-2~exp1.1 amd64wayland
compositor infrastructure - server library
un  libwayland0  (no
description available)
un  qtwayland-client-abi-5-15-2  (no
description available)
un  qtwayland-compositor-abi-5-15-2  (no
description available)
ii  qtwayland5:amd645.15.2-2amd64QtWayland
platform plugin


# dpkg -l *xorg*
Desired=Unknown/Install/Remove/Purge/Hold
|
Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend
|/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad)
||/ Name   Version Architecture
Description
+++-==-===--=
ii  xorg   1:7.7+21amd64
 X.Org X Window System
un  xorg-docs
(no description available)
ii  xorg-docs-core 1:1.7.1-1.1 all
 Core documentation for the X.org X Window System
un  xorg-driver-input
(no description available)
un  xorg-driver-video
(no description available)
un  xorg-input-abi-24
(no description available)
un  xorg-video-abi-24
(no description available)
ii  xserver-xorg   1:7.7+21amd64
 X.Org X server
ii  xserver-xorg-core  2:1.20.10-1 amd64
 Xorg X server - core server
un  xserver-xorg-driver-all  
(no description available)
ii  xserver-xorg-input-all 1:7.7+21amd64
 X.Org X server -- input driver metapackage
un  xserver-xorg-input-evtouch   
(no description available)
ii  xserver-xorg-input-libinput0.30.0-1amd64
 X.Org X server -- libinput input driver
un  xserver-xorg-input-vmmouse   
(no description available)
ii  xserver-xorg-input-wacom   0.34.99.1-1+b1  amd64
 X.Org X server -- Wacom input driver
ii  xserver-xorg-legacy2:1.20.10-1 amd64
 setuid root Xorg server wrapper
ii  xserver-xorg-video-all 1:7.7+21amd64
 X.Org X server -- output driver metapackage
ii  xserver-xorg-video-amdgpu  19.1.0-1amd64
 X.Org X server -- AMDGPU display driver
ii  xserver-xorg-video-ati 1:19.1.0-1  amd64
 X.Org X server -- AMD/ATI display driver wrapper
ii  xserver-xorg-video-fbdev   1:0.5.0-1   amd64
 X.Org X server -- fbdev display driver
ii  xserver-xorg-video-intel   2:2.99.917+git20200714-1+b1 amd64
 X.Org X server -- Intel i8xx, i9xx display driver
un  xserver-xorg-video-mach64
(no description available)
un  xserver-xorg-video-modesetting  

Bug#978030: ITP: xotes -- simple personal note management system

[Jameson Graef Rollins]

Package: wnpp
Severity: wishlist
Owner: Jameson Graef Rollins 
X-Debbugs-Cc: debian-de...@lists.debian.org

* Package name: xotes
  Version : 0.1.0
  Upstream Author : Jameson Graef Rollins 
* URL : https://gitlab.com/jrollins/xotes
* License : GPL
  Programming Lang: Python
  Description : simple personal note management system

Xotes is a personal note management system. It's goal is to be as
simple and efficient to use as possible.  Features include:
* notes are simple markdown
* git storage backend, for simple sharing between devices
* full text index and search of all notes with xapian
* GitJournal compatibility for sharing notes with Android devices
  library, command line, and ncurses interfaces

Bug#961283: libhttp-tiny-perl: Don't release with bullseye

[Paul Gevers]

Hi gregor,

On 24-12-2020 02:57, gregor herrmann wrote:
> So this looks like a potential for improvement for the tooling to
> detect "key packages", namely to take Provides into account.

Our tooling [1] already does that, but IIRC it prefers real packages
over Provides.

Paul

https://salsa.debian.org/qa/udd/-/blob/master/scripts/update-key-packages.pl



OpenPGP_signature
Description: OpenPGP digital signature

Bug#978029: octave: unable to load appropriate font

[Stanislav Maslovski]

Package: octave
Version: 6.1.0-2
Severity: normal
X-Debbugs-Cc: stanislav.maslov...@gmail.com

Dear Maintainer,

After testing octave --gui on a fresh Debian installation, I noticed that
octave complains about being unable to load FreeSans OTF font when trying
to create a simple 2D plot. As a result, nothing is plotted. Installing
fonts-freefont-otf package resolved the problem.

>> x=1:10;
>> y=sin(x);
>> plot(x,y);
warning: ft_manager: unable to load font: 
/usr/share/fonts/opentype/freefont/FreeSans.otf
warning: called from
axes at line 107 column 8
newplot at line 165 column 10
plot at line 228 column 9

warning: ft_text_renderer: unable to load appropriate font
warning: called from
axes at line 107 column 8
newplot at line 165 column 10
plot at line 228 column 9
.

Possibly, a depends or recomends is missing?

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

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

Versions of packages octave depends on:
ii  libbz2-1.0 1.0.8-4
ii  libc6  2.31-5
ii  libfftw3-double3   3.3.8-2
ii  libfftw3-single3   3.3.8-2
ii  libfltk-gl1.3  1.3.5-2
ii  libfltk1.3 1.3.5-2
ii  libgcc-s1  10.2.1-1
ii  libgl1 1.3.2-1
ii  libglpk40  5.0-1
ii  liboctave8 6.1.0-2
ii  libportaudio2  19.6.0-1.1
ii  libqhull8.02020.2-3
ii  libqscintilla2-qt5-15  2.11.6+dfsg-1
ii  libqt5core5a   5.15.2+dfsg-2
ii  libqt5gui5 5.15.2+dfsg-2
ii  libqt5help55.15.2-3
ii  libqt5network5 5.15.2+dfsg-2
ii  libqt5printsupport55.15.2+dfsg-2
ii  libqt5widgets5 5.15.2+dfsg-2
ii  libqt5xml5 5.15.2+dfsg-2
ii  libsndfile11.0.28-8
ii  libstdc++6 10.2.1-1
ii  libx11-6   2:1.6.12-1
ii  octave-common  6.1.0-2
ii  texinfo6.7.0.dfsg.2-5+b1
ii  zlib1g 1:1.2.11.dfsg-2

Versions of packages octave recommends:
ii  default-jre-headless  2:1.11-72
ii  epstool   3.09-3
ii  gnuplot-qt [gnuplot-x11]  5.4.1+dfsg1-1
ii  libopenblas0  0.3.13+ds-1
ii  octave-doc6.1.0-2
ii  pstoedit  3.75-1

Versions of packages octave suggests:
pn  liboctave-dev  

-- no debconf information

Bug#978028: opencv: FTBFS on architectures without java

[Pino Toscano]

Source: opencv
Version: 4.5.1+dfsg-1
Severity: important
Tags: patch

Hi,

opencv 4.5.1+dfsg-1 fails to build on architectures without Java
support, like hurd-i386 [1].

This is because the libopencv4.5-java binary was changed from arch:all
to arch:any in version 4.5.1+dfsg-1, so on architectures without Java
the files to install in libopencv4.5-java are not found.
The solution is to restrict the architecture of the libopencv4.5-java
binary to the same list of architectures of the other Java-related
binary, i.e. libopencv4.5-jni. Patch attached for this.

[1] 
https://buildd.debian.org/status/fetch.php?pkg=opencv&arch=hurd-i386&ver=4.5.1%2Bdfsg-1&stamp=1608798863&raw=0

Thanks,
-- 
Pino
--- a/debian/control
+++ b/debian/control
@@ -1106,7 +1106,7 @@ Description: computer vision contrlib li
  recognition, camera calibration and 3D reconstruction.
 
 Package: libopencv4.5-java
-Architecture: any
+Architecture: amd64 arm64 armel armhf i386 mips64el mipsel ppc64el s390x alpha 
ia64 m68k powerpc ppc64 riscv64 sh4 sparc64 x32
 Multi-Arch: no
 Section: java
 Depends: libopencv4.5-jni (>= ${binary:Version}),

Bug#940704: [Pkg-javascript-devel] Bug#940704: some tests do pass

[Pirate Praveen]

On Thu, Dec 24, 2020 at 19:50, Paolo Greppi  
wrote:

I have run jest in the yarnpkg source tree with:
jest --ci __tests__/



You can add this to debian/tests/pkg-js/test


having this jest.config.js to disable failing tests:


and include this as a patch.


module.exports = {
  testURL: "http://localhost/";,
  testPathIgnorePatterns: [
"/node_modules/",
"/__tests__/index.js",
"/__tests__/integration.js",
"/__tests__/lifecycle-scripts.js",
"/__tests__/pipe.js",
"/__tests__/commands/pack.js",
"/__tests__/commands/run.js",
"/__tests__/fixtures",
"/__tests__/reporters/_mock.js",
"/__tests__/commands/_helpers.js",
"/__tests__/_temp.js",
"/__tests__/__mocks__",
"/__tests__/commands/install/lockfiles.js"
  ]
}

result:
Test Suites: 1 skipped, 81 passed, 81 of 82 total
Tests:   15 skipped, 1116 passed, 1131 total
Snapshots:   111 passed, 111 total
Time:74.936s
Ran all test suites matching /__tests__\//i.

I think we can include it in the autopkgtest, later we can try to 
understand why some tests are failing ..


yes, running some tests soon while we figure out what is wrong with the 
rest is a good idea.


Note: 
https://alioth-lists.debian.net/pipermail/pkg-javascript-devel/2020-November/047062.html


Paolo

Bug#848180: konsole: Includes application name in window title when configured not to do so

[Pino Toscano]

reassign 848180 src:qtbase-opensource-src 
qtbase-opensource-src/5.7.1~20161021+dfsg-6
retitle 848180 setWindowTitle() includes application name in window title when 
configured not to do so
thanks

In data venerdì 23 dicembre 2016 16:36:15 CET, Maximiliano Curia ha scritto:
> ¡Hola Aaron!
> 
> El 2016-12-13 a las 19:49 -0500, Aaron Schrab escribió:
> > Package: konsole 
> > Version: 4:16.08.3-1 
> > Severity: minor
> 
> > After unchecking the "Show application name on the titlebar" option in the 
> > Configure Konsole dialog it still inludes " - Konsole" at the end of window 
> > titles. This occurs even after closing all Konsole windows and restarting 
> > the 
> > application.
> 
> > I first observed this with version 4:16.08.2-2 of both the konsole and 
> > konsole-kpart packages. I upgraded both of those to 4:16.08.3-1 from 
> > unstable 
> > to check if the issue was still present (and I again made sure to close all 
> > windows after the upgrade). Before I installed the version from testing 
> > yesterday I hadn't used this package in long time, so I can't say how long 
> > this 
> > bug has existed.
> 
> I can reproduce the issue, this seems to be a issue in kxmlgui rather than 
> konsole. konsole calls setCaption or setPlainCaption depending on the value 
> of 
> the user setting, the first on documents that it would add the application 
> name, and the second one that it wouldn't, but sadly this is no longer true ( 
> since this was ported to qt5), as setCaption is implemented as a single call 
> to setPlainCaption (and the responsible for adding the application name in 
> the 
> title is the qt qpa plugin).
> 
> The setCaption and setPlainCaption documentation can be seen here:
>  https://cgit.kde.org/kxmlgui.git/tree/src/kmainwindow.h
> 
> While the implementation can be seen here:
>  https://api.kde.org/frameworks/kxmlgui/html/kmainwindow_8cpp_source.html
> 
> The qt documentation for setWindowTitle can be found here:
>  http://doc.qt.io/qt-5/qwidget.html#windowTitle-prop
> 
> kxmlgui is missing a way to workaround the setWindowTitle use of the qpa 
> plugin, this may need to be scale to qtbase.

Indeed, this is a Qt limitation:
https://bugreports.qt.io/browse/QTBUG-75535

Hence, reassigning to Qt 5.

Thanks,
-- 
Pino Toscano

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

Bug#971271: rainloop: ftbfs with node-postcss 8.0 in experimental

[Pirate Praveen]

Control: retitle rainloop: ftbfs with node-postcss 8.0
Control: severity -1 serious

On Mon, 28 Sep 2020 21:21:26 +0530 Pirate Praveen 
 wrote:

>
> node-postcss 8.x will be uploaded to unstable when node-css-loader is
> ready (there is already an upstream pull request and hopefully next
> release will support it). Please make sure rainloop is ready for the
> transition.
>

node-postcss 8 is now in unstable and raising severity to serious.

Bug#942129: kio: no multiarch support.

[Pino Toscano]

severity 942129 wishlist
thanks

Hi,

In data giovedì 10 ottobre 2019 19:57:05 CET, peter green ha scritto:
> While trying to install a kde app for a foreign architecture. I noticed that 
> while libkf5declarative5 is multi-arch: same it can only be installed for one 
> architecture at a time, because it depends on kio and kio has no multi-arch 
> field.
> 
> Unfortunately it seems kio contains a bunch of stuff in architecture-specific 
> paths which look like they may be used from other packages, but also contains 
> native binaries in /usr/bin , so it seems adding multi-arch support would 
> require splitting the package.
> 
> Thoughts?

Multi-arch is in general not something upstream supports; we have some
changes mostly related to cross-building, but otherwise anything beyond
that is mostly "nice to have". Some of the KDE Frameworks (such as kio)
also have runtime components/daemons that can spawn D-Bus services
and/or load plugins. This makes the scenario you described above as hard
to do, and (personally speaking) not something to invest into unless
there is a strong demand for it.

Hence, I'm lowering the severity of this to wishlist.

-- 
Pino Toscano

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

Bug#940704: some tests do pass

[Paolo Greppi]

I have run jest in the yarnpkg source tree with:
jest --ci __tests__/

having this jest.config.js to disable failing tests:

module.exports = {
  testURL: "http://localhost/";,
  testPathIgnorePatterns: [
"/node_modules/",
"/__tests__/index.js",
"/__tests__/integration.js",
"/__tests__/lifecycle-scripts.js",
"/__tests__/pipe.js",
"/__tests__/commands/pack.js",
"/__tests__/commands/run.js",
"/__tests__/fixtures",
"/__tests__/reporters/_mock.js",
"/__tests__/commands/_helpers.js",
"/__tests__/_temp.js",
"/__tests__/__mocks__",
"/__tests__/commands/install/lockfiles.js"
  ]
}

result:
Test Suites: 1 skipped, 81 passed, 81 of 82 total
Tests:   15 skipped, 1116 passed, 1131 total
Snapshots:   111 passed, 111 total
Time:74.936s
Ran all test suites matching /__tests__\//i.

I think we can include it in the autopkgtest, later we can try to understand 
why some tests are failing ..

Note: 
https://alioth-lists.debian.net/pipermail/pkg-javascript-devel/2020-November/047062.html

Paolo

Bug#897275: llvm-6.0 should provide a pkg-config file

[Pino Toscano]

affects 897275 - src:qtcreator
thanks

In data martedì 1 maggio 2018 10:22:36 CET, hai scritto:
> Package: llvm-6.0

(currently src:llvm-11)

> Filename: /usr/lib/llvm-6.0/bin/llvm-config
> Forwarded: https://bugs.llvm.org/show_bug.cgi?id=9405
> Tags: upstream
> User: helm...@debian.org
> Usertags: rebootstrap
> Control: affects -1 + src:qtcreator

This does not affect qtcreator anymore: starting from 4.14.0-2,
qtcreator is now built using cmake, and thus the cmake config files
of llvm/clang are used to detect it.

-- 
Pino Toscano

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

Bug#947361: krita: Keyboard doesn't respond after some popups (f.e show color selector) are opened.

[Pino Toscano]

tag 947361 + moreinfo
thanks

Hi,

In data mercoledì 25 dicembre 2019 18:45:19 CET, Fenix ha scritto:
> Package: krita
> Version: 1:4.2.8.2+dfsg-1
> Severity: normal
> 
> Dear Maintainer,
> 
>  Krita seems to have problems with some popups docks, for example 
> color selector, minimal shade selector... After this controls are showed 
> if they are hidden just moving the pointer outside its domain, keyboard 
> doesn't respond anymore, unless you change to another program or window.
> 
>  Brush preset, for example, works fine. This type of popup are close
> clicking outside and not just moving pointer outside.
> 
> 
> * What led up to the situation?
> 
>  1.- Create new image.
>  2.- Open, for example, a color selector (Shift + I)
>  3.- Select a color and move the cursor outside the selector. It 
> will be vanished.
>  4.- Try to open again the color selector with Shift + I or made 
> something with keyboard: change to full screen, undo action (ctrl-z)...
>  5.- The keyboard will not repond.
>  6.- Change to another program and back to Krita (Krita must lost the
> focus).
>  7.- Try again show color selector (Shift + I). It will work again.
> 
> 
> * What exactly did you do (or not do) that was effective (or
>   ineffective)?
> 
>  If enter key is pressed just before choosing color in color 
> selector and with the pointer inside the control (for not hide it), the 
> keyboard works fine: accept other shourtuts. But if the popup is hide 
> only moving the pointer outside its domain, the keyboard will be stucked 
> into Krita. And only come back after loosing the focus into another 
> program or window.

Can you still reproduce the issue with a more recent version of krita,
like krita 4.4.1 currently available in testing?
If so, can you please report the bug to the upstream development team,
as they have more expertise than me? See the following page:
https://docs.krita.org/en/untranslatable_pages/reporting_bugs.html

Thanks,
-- 
Pino Toscano

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

Bug#978027: jami: Continues music playback when accepting incoming calls

[Bruno Kleinert]

Package: jami
Version: 20201217.1.80217fa~ds1-1
Severity: minor
X-Debbugs-Cc: fu...@debian.org

Hi,

in a GNOME 3 environment with Rhythmbox playing music, the music is paused by
Jami when a call is incoming so I can easily hear the sound Jami makes to
inform about the call. As soon as I accept the call, Jami makes Rhythmbox
unexpectedly continue to play back music.

I would expect Jami to keep music playback paused until I end the call.

Cheers,
Bruno



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

Kernel: Linux 5.9.0-5-amd64 (SMP w/8 CPU threads)
Locale: LANG=de_DE.utf8, LC_CTYPE=de_DE.utf8 (charmap=UTF-8) (ignored: LC_ALL 
set to de_DE.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 jami depends on:
ii  dconf-gsettings-backend [gsettings-backend]  0.38.0-1
ii  jami-daemon  20201217.1.80217fa~ds1-1
ii  libayatana-appindicator3-1   0.5.5-2
ii  libc62.31-6
ii  libcairo21.16.0-4
ii  libcanberra-gtk3-0   0.30-7
ii  libcanberra0 0.30-7
ii  libclutter-1.0-0 1.26.4+dfsg-2
ii  libclutter-gtk-1.0-0 1.8.4-4
ii  libgcc-s110.2.1-1
ii  libgdk-pixbuf-2.0-0  2.42.2+dfsg-1
ii  libglib2.0-0 2.66.4-1
ii  libgtk-3-0   3.24.24-1
ii  libnm0   1.28.0-1
ii  libnotify4   0.7.9-2
ii  libpango-1.0-0   1.46.2-3
ii  libqrencode4 4.1.1-1
ii  libqt5core5a 5.15.2+dfsg-2
ii  libqt5dbus5  5.15.2+dfsg-2
ii  libqt5gui5   5.15.2+dfsg-2
ii  libqt5sql5   5.15.2+dfsg-2
ii  libqt5sql5-sqlite5.15.2+dfsg-2
ii  libstdc++6   10.2.1-1
ii  libwebkit2gtk-4.0-37 2.30.4-1
ii  libx11-6 2:1.6.12-1

jami recommends no packages.

jami suggests no packages.

-- no debconf information

Bug#977329: krita segfaults when try to open with libQt5Gui.so.5.15.1

[Pino Toscano]

tag 977329 + moreinfo
thanks

Hi,

In data lunedì 14 dicembre 2020 02:12:14 CET, proctor ha scritto:
> Package: krita
> Version: 1:4.4.1+dfsg-1+b1
> Severity: important
> X-Debbugs-Cc: damonswir...@gmail.com
> 
> Dear Maintainer,
> 
> *** Reporter, please consider answering these questions, where appropriate ***
> 
>* What led up to the situation?
>* What exactly did you do (or not do) that was effective (or
>  ineffective)?
>* What was the outcome of this action?
>* What outcome did you expect instead?
> 
> *** End of the template - remove these template lines ***
> 
> 
> krita will not open. when i try i get this in dmesg and syslog
> 
> [327378.536890] krita[1273329]: segfault at 0 ip 7efdeea7c190 sp 
> 7fff99cbf6f8 error 4 in libQt5Gui.so.5.15.1[7efdee9fe000+4c3000]
> [327378.536895] Code: e0 10 48 09 f0 48 c1 e0 10 4c 09 e8 49 89 40 04 31 c0 
> 66 41 89 40 0c 48 83 c4 18 4c 89 c0 5b 5d 41 5c 41 5d 41 5e 41 5f c3 90 <48> 
> 8b 06 8b 56 08 48 89 07 89 57 08 f0 83 00 01 c3 90 66 66 2e 0f
> 
> krita does work on a similar system but with AMD video card (this machine
> has nvidia card) so maybe this is a video driver problem instead? is so let
> me know and i will try to file this bug there instead!

Unfortunately this dmesg line is not exactly useful, it merely says it
crashed "somewhere" within QtGui.

Do you still get a crash in an up-to-date testing installation?
What where you doing when krita crashed?
Which desktop environment or WM are you running?
Are you running a Wayland session or an Xorg session?

In case you still get a crash: please follow these two pages to install
the debug packages for krita, and get a stack trace of the crash:
https://wiki.debian.org/HowToGetABacktrace
https://community.kde.org/Guidelines_and_HOWTOs/Debugging/How_to_create_useful_crash_reports

Thanks,
-- 
Pino Toscano

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

Bug#978026: kvpm: crash after launch

[jpj]

Package: kvpm
Version: 0.9.10-1
Severity: grave
Justification: renders package unusable

Dear Maintainer,

I can't launch kvpm it crashes after launch !
kvpm: symbol lookup error: /usr/lib/x86_64-linux-gnu/libQt5Core.so.5: undefined
symbol: ucol_open_63

I get the same kind of problem with reportbug-ng crashing after launch :
File "/usr/bin/reportbug-ng", line 26, in 
from PyQt5 import QtCore, QtWidgets
ImportError: /usr/lib/x86_64-linux-gnu/libQt5Core.so.5: undefined symbol:
ucol_strcoll_63

The problem seems to be with Qt5 core ?

My system :
CPU : Intel(R) Core(TM) i5-5675C CPU @ 3.10GHz
RAM : 16Go
Some disks mostly using RAID 1
Mother board : Gigabyte H97N-WIFI

Regards

JP P



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

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

Versions of packages kvpm depends on:
ii  libblkid1   2.33.1-0.1
ii  libc6   2.28-10
ii  libdevmapper1.02.1  2:1.02.155-3
ii  libgcc1 1:8.3.0-6
ii  libkf5configcore5   5.54.0-1+deb10u1
ii  libkf5configgui55.54.0-1+deb10u1
ii  libkf5configwidgets55.54.0-1
ii  libkf5coreaddons5   5.54.0-1
ii  libkf5i18n5 5.54.0-1
ii  libkf5kdelibs4support5  5.54.0-1
ii  libkf5widgetsaddons55.54.0-1
ii  libkf5xmlgui5   5.54.0-1
ii  liblvm2app2.2   2.02.168-2
ii  libparted2  3.2-25
ii  libqt5core5a5.11.3+dfsg1-1+deb10u4
ii  libqt5gui5  5.11.3+dfsg1-1+deb10u4
ii  libqt5widgets5  5.11.3+dfsg1-1+deb10u4
ii  libstdc++6  8.3.0-6

Versions of packages kvpm recommends:
ii  dosfstools 4.1-2
ii  jfsutils   1.1.15-4
pn  ntfs-3g
ii  reiserfsprogs  1:3.6.27-3
ii  xfsprogs   4.20.0-1

Versions of packages kvpm suggests:
ii  btrfs-progs [btrfs-tools]  5.9-1~bpo10+1
pn  reiser4progs   

-- no debconf information

Bug#955730: krita does not start under wayland

[Pino Toscano]

severity 955730 wishlist
retitle 955730 krita does not support wayland
forwarded 955730 https://bugs.kde.org/show_bug.cgi?id=429079
thanks

Hi,

In data sabato 4 aprile 2020 11:22:08 CET, Nicolas Évrard ha scritto:
> I have started to use sway as my primary window manager unfortunately
> krita does not work with wayland it seems. Other Qt applications seems
> to work just find (provided I set the right environment variable ie
> QT_QPA_PLATFORM=wayland)

krita has never supported Wayland so far. It uses various X technologies
(e.g. tablet support, color management) that are not available under
Wayland, or nobody worked on them in krita.

There is an upstream bug mentioning this:
https://bugs.kde.org/show_bug.cgi?id=429079
starting from the upcoming version 4.4.2, you will even get an error
message with krita closing itself afterwards in case you are running
under Wayland. Please run krita within XWayland until proper Wayland
support is implemented in krita.

Thanks,
-- 
Pino Toscano

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

Bug#976437: found 976437 in 2.30.3-1~deb10u1, found 976437 in 2.30.3-1

[Alberto Garcia]

Control: notfound -1 2.30.3-1

On Tue, Dec 22, 2020 at 01:01:51PM +0100, Salvatore Bonaccorso wrote:

> > > found 976437 2.30.3-1
> > 
> > In practice the 2.30.3-1 binary packages in testing/sid are not
> > affected because they use a recent version of libsoup that does
> > not trigger this bug.
> > 
> > But it's ok to leave the bug tagged like that :)
> 
> Oh I see. We can fix up the metadata if wanted. I guess I got
> confused then because it got marked fixed in 2.30.4-1, so was
> assuming unstable's 2.30.3-1 was found and tried to fix up the graph
> in the BTS.

It's fine either way, but I guess that since the binaries are not
affected it's clearer if I just mark 2.30.3-1 as clean.

Berto

Bug#977857: libreoffice-common: On Wayland, it doesn't work without the xwayland pkg but installation does not pull xwayland as a dependency

[jman]

Rene Engelhard writes:


Is this common? I mean this would haven been reported far earlier/in
many more cases? Isn't the "GNOME" Session defaulting to wayland
nowadays?



Ah, both GNOME and KDE depend on xwayland. Which DE/WM do you use?


I use Sway on Wayland and during the installation of bullseye I didn't
install neither Gnome/KDE, therefore xwayland was not pulled as a
dependency by any package.

I'm experimenting how far can I go with a pure Wayland without the
"translation" layer provided by xwayland, so I guess I've stomped on a
corner-case nobody has tested yet.

I understand this might be a niche use-case for now (Gnome/KDE rely on
xwayland) so I guess it's fine if you WONTFIX this issue. But I also
think that Wayland-with-no-xwayland might be the way to the future
(with a bumpy road to get there ...) and at some point Xorg and its
dependencies will be dropped.


(Wrt your other mail, that package list is so obviously incomplete -
and
we TTBOMK don't patch any place which should affect this. What we do
differ in is using system-libraries where possible - so one of these
might affect this?


You're right and that's puzzling. I've installed on purpose only the
vanilla Libreoffice packages I needed and it works without xwayland. I
have no idea why, I don't have enough context to go deeper on this.

Anyway, thank you for clarifying a few points and for maintaining the
Debian package!

regards,

Bug#977328: false positive when passing variables to functions by address

[Russ Allbery]

Joachim Reichel  writes:

> The first and third issue are fixed in the upstream master branch. For
> the second issue, upstream asked for a separate bug report which is at
> https://trac.cppcheck.net/ticket/10062#ticket .

Awesome, thank you so much!

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

Bug#978025: linux-image-5.10.0-trunk-arm64: alsa audio output problems since 5.10 kernel

[Diederik de Haas]

Package: src:linux
Version: 5.10.2-1~exp1
Severity: normal

On my RPi3B+ (named rpi-mpd) I have the following sound cards:
$ cat /proc/asound/cards
 0 [ALSA   ]: bcm2835_alsa - bcm2835 ALSA
  bcm2835 ALSA
 1 [vc4hdmi]: vc4-hdmi - vc4-hdmi
  vc4-hdmi

My RPi is connected to my AV receiver via a (good quality) HDMI cable.
I have only alsa installed on this machine, no pulse audio.

When I play a (.flac) file with mpd with the "ALSA" card, the playback
quality is consistently worse than with the 5.9 kernel. 
Some 'only' have some noise (~static sound) along the music, others are
quite horrible. 
What is odd, is that it's the same tracks that are 'not good' and 'horrible'. 
I have one album both in .flac and in .mp3 format and they exibit the same 
behaviour on the same tracks.
This happens across albums and music styles (pop and classical).
These issue are a regression compared to 5.9.


There are also other audio issues, but those happen also with the 5.9
kernel.
When I have "vc4hdmi" selected as soundcard, I get the following in my
mpd.log file and then it doesn't play at all.
It could (very well) be that my mpd config is incorrect for that audio
card.

Dec 24 16:06 : exception: Failed to open "vc4hdmi" (alsa); Failed to
open ALSA device "default": Invalid argument
Dec 24 16:06 : exception: Failed to open "vc4hdmi" (alsa); Failed to
open ALSA device "default": Invalid argument
Dec 24 16:06 : player: problems opening audio device while playing
"CDs/BLØF/Omarm/01.De_Mooiste_Verliezers.flac"
ALSA lib pcm_direct.c:1206:(snd1_pcm_direct_initialize_slave) requested
or auto-format is not available
ALSA lib pcm_dmix.c:1087:(snd_pcm_dmix_open) unable to initialize slave


When I invoke 'aplay' directly on the command line, I get sth similar:

diederik@rpi-mpd:~$ aplay -c 2 -r 48000 /dev/urandom
ALSA lib pcm_direct.c:1206:(snd1_pcm_direct_initialize_slave) requested
or auto-format is not available
ALSA lib pcm_dmix.c:1087:(snd_pcm_dmix_open) unable to initialize slave
aplay: main:830: audio open error: Invalid argument


I don't believe that multichannel audio is supported, although looking
through RPi forums/bug trackers I get the feeling that the hardware
*could* support it. I just never got it to work properly.
At one time I thought to have it working with pulseaudio, but on closer
inspection it seems that the stereo sound is just replicated to more
outputs. 

Cheers,
  Diederik

-- Package-specific info:
** Version:
Linux version 5.10.0-trunk-arm64 (debian-ker...@lists.debian.org) (gcc-10 
(Debian 10.2.1-1) 10.2.1 20201207, GNU ld (GNU Binutils for Debian) 2.35.1) #1 
SMP Debian 5.10.2-1~exp1 (2020-12-22)

** Command line:
video=HDMI-A-1:1920x1080M@60,margin_left=48,margin_right=48,margin_top=48,margin_bottom=48
 dma.dmachans=0x7f35 bcm2709.boardrev=0xa020d3 bcm2709.serial=0x4db4eb14 
bcm2709.uart_clock=4800 bcm2709.disk_led_gpio=29 
bcm2709.disk_led_active_low=0 smsc95xx.macaddr=B8:27:EB:B4:EB:14 
vc_mem.mem_base=0x3ec0 vc_mem.mem_size=0x4000  console=tty0 
console=ttyS1,115200 root=/dev/mmcblk0p2 rw fsck.repair=yes net.ifnames=0 
cma=64M rootwait disable_fw_kms_setup=1

** Tainted: C (1024)
 * staging driver was loaded

** Kernel log:
[   13.233771] systemd[1]: Mounted POSIX Message Queue File System.
[   13.269941] systemd[1]: Mounted RPC Pipe File System.
[   13.301879] systemd[1]: Mounted Kernel Debug File System.
[   13.334267] systemd[1]: Mounted Kernel Trace File System.
[   13.369388] systemd[1]: Started Journal Service.
[   15.264660] bcm2835-wdt bcm2835-wdt: Broadcom BCM2835 watchdog timer
[   15.277293] vchiq: module is from the staging directory, the quality is 
unknown, you have been warned.
[   15.684981] alg: No test for fips(ansi_cprng) (fips_ansi_cprng)
[   15.895410] hid: raw HID events driver (C) Jiri Kosina
[   16.001054] cfg80211: Loading compiled-in X.509 certificates for regulatory 
database
[   16.020592] cfg80211: Loaded X.509 cert 'b...@debian.org: 
577e021cb980e0e820821ba7b54b4961b8b4fadf'
[   16.021187] libphy: Fixed MDIO Bus: probed
[   16.040951] cfg80211: Loaded X.509 cert 'romain.per...@gmail.com: 
3abbc6ec146e09d1b6016ab9d6cf71dd233f0328'
[   16.070420] usbcore: registered new interface driver usbhid
[   16.077020] cfg80211: Loaded X.509 cert 'sforshee: 00b28ddf47aef9cea7'
[   16.088116] usbhid: USB HID core driver
[   16.127572] platform regulatory.0: firmware: direct-loading firmware 
regulatory.db
[   16.146777] platform regulatory.0: firmware: direct-loading firmware 
regulatory.db.p7s
[   16.208404] cryptd: max_cpu_qlen set to 1000
[   16.372179] lan78xx 1-1.1.1:1.0 (unnamed net_device) (uninitialized): No 
External EEPROM. Setting MAC Speed
[   16.410860] brcmfmac: brcmf_fw_alloc_request: using brcm/brcmfmac43455-sdio 
for chip BCM4345/6
[   16.437335] usbcore: registered new interface driver brcmfmac
[   16.445395] libphy: lan78xx-mdiobus: probed
[   16.493071] brcmfmac mmc1:0001:1: firmware: direct-loadin

Bug#978018: libapr1: Please add 64-bit atomics workaround for m68k and sh4

[John Paul Adrian Glaubitz]

Control: tags -1 +patch

Attaching a patch. Please include sh3 in this change as well.

Adrian

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

diff -Nru apr.old/apr-1.7.0/debian/changelog apr/apr-1.7.0/debian/changelog
--- apr.old/apr-1.7.0/debian/changelog	2020-11-21 21:06:09.0 +0100
+++ apr/apr-1.7.0/debian/changelog	2020-12-24 18:01:25.611495190 +0100
@@ -1,3 +1,9 @@
+apr (1.7.0-4+ports) unstable; urgency=medium
+
+  * Fix atomics for m68k, sh3 and sh4.
+
+ -- John Paul Adrian Glaubitz   Thu, 24 Dec 2020 18:01:15 +0100
+
 apr (1.7.0-4) unstable; urgency=low
 
   [ Debian Janitor ]
diff -Nru apr.old/apr-1.7.0/debian/patches/generic-64bit-atomics.patch apr/apr-1.7.0/debian/patches/generic-64bit-atomics.patch
--- apr.old/apr-1.7.0/debian/patches/generic-64bit-atomics.patch	2020-08-30 21:07:53.0 +0200
+++ apr/apr-1.7.0/debian/patches/generic-64bit-atomics.patch	2020-12-24 17:44:40.797741482 +0100
@@ -1,20 +1,24 @@
 # quick and dirty fix for FTBFS on mipsel
 # There should be a proper configure check, see 
 # https://bz.apache.org/bugzilla/show_bug.cgi?id=63566
 apr.orig/include/arch/unix/apr_arch_atomic.h
-+++ apr/include/arch/unix/apr_arch_atomic.h
+Index: apr-1.7.0/include/arch/unix/apr_arch_atomic.h
+===
+--- apr-1.7.0.orig/include/arch/unix/apr_arch_atomic.h
 apr-1.7.0/include/arch/unix/apr_arch_atomic.h
 @@ -26,6 +26,9 @@
  /* noop */
  #elif HAVE_ATOMIC_BUILTINS
  #   define USE_ATOMICS_BUILTINS
-+#   if (__INTPTR_WIDTH__ == 32) && ( defined(__MIPSEL__) || defined(__powerpc__) )
++#   if (__INTPTR_WIDTH__ == 32) && ( defined(__MIPSEL__) || defined(__powerpc__) ) || defined(__m68k__) || defined(__sh__)
 +#   define NEED_ATOMICS_GENERIC64
 +#   endif
  #elif defined(SOLARIS2) && SOLARIS2 >= 10
  #   define USE_ATOMICS_SOLARIS
  #   define NEED_ATOMICS_GENERIC64
 apr.orig/atomic/unix/builtins64.c
-+++ apr/atomic/unix/builtins64.c
+Index: apr-1.7.0/atomic/unix/builtins64.c
+===
+--- apr-1.7.0.orig/atomic/unix/builtins64.c
 apr-1.7.0/atomic/unix/builtins64.c
 @@ -16,7 +16,7 @@
  
  #include "apr_arch_atomic.h"
@@ -24,8 +28,10 @@
  
  APR_DECLARE(apr_uint64_t) apr_atomic_read64(volatile apr_uint64_t *mem)
  {
 apr.orig/atomic/unix/builtins.c
-+++ apr/atomic/unix/builtins.c
+Index: apr-1.7.0/atomic/unix/builtins.c
+===
+--- apr-1.7.0.orig/atomic/unix/builtins.c
 apr-1.7.0/atomic/unix/builtins.c
 @@ -20,7 +20,11 @@
  
  APR_DECLARE(apr_status_t) apr_atomic_init(apr_pool_t *p)
diff -Nru apr.old/apr-1.7.0/debian/patches/generic-64bit-atomics.patch~ apr/apr-1.7.0/debian/patches/generic-64bit-atomics.patch~
--- apr.old/apr-1.7.0/debian/patches/generic-64bit-atomics.patch~	1970-01-01 01:00:00.0 +0100
+++ apr/apr-1.7.0/debian/patches/generic-64bit-atomics.patch~	2020-08-30 21:07:53.0 +0200
@@ -0,0 +1,40 @@
+# quick and dirty fix for FTBFS on mipsel
+# There should be a proper configure check, see 
+# https://bz.apache.org/bugzilla/show_bug.cgi?id=63566
+--- apr.orig/include/arch/unix/apr_arch_atomic.h
 apr/include/arch/unix/apr_arch_atomic.h
+@@ -26,6 +26,9 @@
+ /* noop */
+ #elif HAVE_ATOMIC_BUILTINS
+ #   define USE_ATOMICS_BUILTINS
++#   if (__INTPTR_WIDTH__ == 32) && ( defined(__MIPSEL__) || defined(__powerpc__) )
++#   define NEED_ATOMICS_GENERIC64
++#   endif
+ #elif defined(SOLARIS2) && SOLARIS2 >= 10
+ #   define USE_ATOMICS_SOLARIS
+ #   define NEED_ATOMICS_GENERIC64
+--- apr.orig/atomic/unix/builtins64.c
 apr/atomic/unix/builtins64.c
+@@ -16,7 +16,7 @@
+ 
+ #include "apr_arch_atomic.h"
+ 
+-#ifdef USE_ATOMICS_BUILTINS
++#if defined(USE_ATOMICS_BUILTINS) && ! defined(NEED_ATOMICS_GENERIC64)
+ 
+ APR_DECLARE(apr_uint64_t) apr_atomic_read64(volatile apr_uint64_t *mem)
+ {
+--- apr.orig/atomic/unix/builtins.c
 apr/atomic/unix/builtins.c
+@@ -20,7 +20,11 @@
+ 
+ APR_DECLARE(apr_status_t) apr_atomic_init(apr_pool_t *p)
+ {
++#if defined (NEED_ATOMICS_GENERIC64)
++return apr__atomic_generic64_init(p);
++#else
+ return APR_SUCCESS;
++#endif
+ }
+ 
+ APR_DECLARE(apr_uint32_t) apr_atomic_read32(volatile apr_uint32_t *mem)
diff -Nru apr.old/apr-1.7.0/debian/symbols.common apr/apr-1.7.0/debian/symbols.common
--- apr.old/apr-1.7.0/debian/symbols.common	2020-08-30 21:07:02.0 +0200
+++ apr/apr-1.7.0/debian/symbols.common	2020-12-24 17:54:31.659743330 +0100
@@ -588,4 +588,4 @@
  apr_vformatter@Base 1.2.7
  apr_vsnprintf@Base 1.2.7
  apr_wait_for_io_or_timeout@Base 1.2.7
- (arch=mipsel powerpc)apr__atomic_generic64_init@Base 1.7.0-3~
+ (arch=mipsel m68k powerpc sh3 sh4)apr__atomic_generic64_init@Base 1.7.0-3~

Bug#976943: golang-github-seccomp-libseccomp-golang: FTBFS on ppc64el (arch:all-only src pkg): dh_auto_test: error: cd obj-powerpc64le-linux-gnu && go test -vet=off -v -p 160 github.com/seccomp/libsec

[Shengjing Zhu]

Control: forwarded -1 https://github.com/seccomp/libseccomp-golang/issues/61
Control: severity -1 important

On Thu, Dec 24, 2020 at 9:12 PM Lucas Nussbaum  wrote:
>
> On 14/12/20 at 14:36 -0500, Reinhard Tartler wrote:
> >
> >
> > > === RUN   TestRuleAddAndLoad
> > > seccomp_test.go:588: Syscall should have returned error code!
> > > --- FAIL: TestRuleAddAndLoad (0.00s)
> >

This has been reported to upstream on Nov 29. There's no bug in the
library itself. Just the test doesn't take ppc64le into account. The
behavior of this library on ppc64le has no difference with the C
version libseccomp2.

So I'm downgrading this bug severity.

-- 
Shengjing Zhu

Bug#977894: gui is broken, python3-xdo

[Daniel Kahn Gillmor]

On Thu 2020-12-24 09:37:46 -0400, Joey Hess wrote:
> Daniel Kahn Gillmor wrote:
>> thanks for the diagnosis, Joey!  this looks like a change between the
>> ctypes module between python 3.8 and 3.9.  I'll fix it in python3-xdo,
>> and hopefully that will resolve your problem.
>
> Independent of getting this fixed, I think it's concerning that ctypes
> falls back to looking for library files in cwd when a shared library is
> unavailable. That has potential to be part of a security exploit chain,
> although I have not dug deeply enough to know if it's exploitable.

I agree with you that this sounds sketchy, but i think the functionality
you're concerned about is in the find_library function:

https://docs.python.org/3/library/ctypes.html#finding-shared-libraries

which says:

>>> On Linux, find_library() tries to run external programs
>>> (/sbin/ldconfig, gcc, objdump and ld) to find the library file. It
>>> returns the filename of the library file.

Not sure what to make of this, but if you end up reporting it upstream
i'd be interested to see a pointer.

I didn't see any report that is obviously related to security and
find_library.

https://bugs.python.org/issue?%40columns=id%2Cactivity%2Ctitle%2Ccreator%2Cassignee%2Cstatus%2Ctype&%40sort=-activity&%40filter=status&%40action=searchid&ignore=file%3Acontent&%40search_text=find_library+security&submit=search&status=-1%2C1%2C2%2C3

for the python xdo module bindings for libxdo, i suppose we could also
avoid calling find_library("xdo") on linux, since it won't work against
SONAMEs other than 3.  that is, we could maybe just hardcode
"libxdo.so.3" as the library name, assuming that these bindings are only
used on GNU/Linux systems.  I don't know whether i'd be as comfortable
hardcoding "libc.so.6" though.

   --dkg



signature.asc
Description: PGP signature

Bug#976637: Bug#977894: gui is broken, python3-xdo

[Daniel Kahn Gillmor]

Control: affects 976637 + impass python3-xdo

I just noticed #976637 after working on resolving #977894 in
impass/python3-xdo.

I'm working around the problem by using "c" instead of "libc" in libxdo,
but just wanted to note the relationship between the two issues in the
BTS.

--dkg


signature.asc
Description: PGP signature

Bug#977894: gui is broken, python3-xdo

[Daniel Kahn Gillmor]

Control: forwarded 977894 https://bugs.python.org/issue42580

On Thu 2020-12-24 08:24:19 -0500, Daniel Kahn Gillmor wrote:
> thanks for the diagnosis, Joey!  this looks like a change between the
> ctypes module between python 3.8 and 3.9.  I'll fix it in python3-xdo,
> and hopefully that will resolve your problem.

fwiw, this was reported as a regression in python 3.9 by doko at the URL
above.

--dkg


signature.asc
Description: PGP signature

Bug#934811: webrtc-audio-processing 1.0 available

[Laurent Bigonville]

On Tue, 15 Dec 2020 12:48:47 +0100 Laurent Bigonville  
wrote:

> On Thu, 15 Aug 2019 11:50:00 +0200 Sebastien Bacher 
> wrote:
> > Package: webrtc-audio-processing
> > Version: 0.3-1
> >
> > There is a new 0.3.1 version available since July 2018, it includes 
some

> > simple build and documentation fixes, would be nice to have it uploaded
> > to Debian
> >
> 
http://freedesktop.org/software/pulseaudio/webrtc-audio-processing/webrtc-audio-processing-0.3.1.tar.xz

>
> Verson 1.0 has actually been tagged end of November 2020
>
> Could that version be packaged?
>

I've started the work to package it, but the patch to add support for 
big-endian is not applying (and there are new places where extra code is 
needed)


See: https://salsa.debian.org/bigon/webrtc-audio-processing

Bug#978024: regression: 4.11.1 broke dose3 on bytecode arches

[Johannes 'josch' Schauer]

Source: ocaml
Version: 4.11.1-3
Severity: important

Hi,

my package botch FTBFS on armel, mips64el and mipsel:

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

The reason is, that when calling dose-deb-coinstall it fails with "unknown
option --verbose". Upon further investigation, it turns out, that the dose3
source package builds invalid binaries on armel, mips64el and mipsel.
You can reproduce the problem by building dose3 on a mipsel porter box
with:

$ apt-get source dose3 --build

You then end up with the following identical working binaries:

dose3-5.0.1/_build/applications/deb-coinstall.byte
dose3-5.0.1/debian/tmp/usr/bin/dose-deb-coinstall

But surprisingly, this one is different and also doesn't work as
expected:

$ dose3-5.0.1/debian/dose-extra/usr/bin/dose-deb-coinstall --help
unknown option --help

Funnily, the other non-working binaries, have the exact same md5sum:

$ find dose3-5.0.1/ -type f -print0 | xargs -0 md5sum | grep 
0261218e050b5c5c7ee1988fd1d4e5da
0261218e050b5c5c7ee1988fd1d4e5da  
dose3-5.0.1/debian/dose-extra/usr/bin/dose-deb-coinstall
0261218e050b5c5c7ee1988fd1d4e5da  
dose3-5.0.1/debian/dose-extra/usr/bin/dose-ceve
0261218e050b5c5c7ee1988fd1d4e5da  
dose3-5.0.1/debian/dose-distcheck/usr/bin/dose-distcheck

I don't understand how this problem or what makes these three different from
the other utilities built by the dose3 source package or how the error is only
introduced when moving the binaries from debian/tmp to debian/dose-*.

The reason I'm filing this bug against the ocaml source package is, that
I bisected Debian unstable and found out, that the problem was not
present when compiling dose3 at snapshot.d.o timestamp 20201012T150222Z
and was first seen in timestamp 20201014T150244Z. The few timestamps
between those two cannot be tested because the build dependencies were
not installable for a while due to an upgrade of ocaml and the involved
binNMU rebuilds.

At the end of this mail I attached a diff between the package list at
the still working snapshot timestamp 20201012T150222Z and the first
failing 20201014T150244Z. As far as ocaml packages go, ocaml itself
updated from 4.08.1 to 4.11.1 so I think this is likely the suspect.

Maybe you have an idea of how to proceed?

Thanks!

cheers, josch


$ diff debbisect.20201012T150222Z.pkglist 
debbisect.20201014T150244Z.pkglist 
19,20c19,20
19,20c19,20
< cpp-1010.2.0-13
< cppo  1.6.6-2
---
> cpp-1010.2.0-15
> cppo  1.6.6-2+b1
41c41
< g++-1010.2.0-13
---
> g++-1010.2.0-15
43,44c43,44
< gcc-1010.2.0-13
< gcc-10-base:armel 10.2.0-13
---
> gcc-1010.2.0-15
> gcc-10-base:armel 10.2.0-15
53c53
< hevea 2.34-2
---
> hevea 2.34-2+b1
62,63c62,63
< libasan6:armel10.2.0-13
< libatomic1:armel  10.2.0-13
---
> libasan6:armel10.2.0-15
> libatomic1:armel  10.2.0-15
72c72
< libbrotli1:armel  1.0.9-2
---
> libbrotli1:armel  1.0.9-2+b1
76,77c76,77
< libbz2-ocaml  0.6.0-10+b1
< libbz2-ocaml-dev  0.6.0-10+b1
---
> libbz2-ocaml  0.6.0-10+b2
> libbz2-ocaml-dev  0.6.0-10+b2
85c85
< libcc1-0:armel10.2.0-13
---
> libcc1-0:armel10.2.0-15
96c96
< libcudf-ocaml-dev 0.9-1
---
> libcudf-ocaml-dev 0.9-1+b1
109,110c109,110
< libextlib-ocaml   1.7.7-2
< libextlib-ocaml-dev   1.7.7-2
---
> libextlib-ocaml   1.7.7-2+b1
> libextlib-ocaml-dev   1.7.7-2+b1
113c113
< libfindlib-ocaml  1.8.1-1+b1
---
> libfindlib-ocaml  1.8.1-2
118,119c118,119
< libgcc-10-dev:armel   10.2.0-13
< libgcc-s1:armel   10.2.0-13
---
> libgcc-10-dev:armel   10.2.0-15
> libgcc-s1:armel   10.2.0-15
124c124
< libglib2.0-0:armel2.66.0-2
---
> libglib2.0-0:armel2.66.1-1
127c127
< libgomp1:armel10.2.0-13
---
> libgomp1:armel10.2.0-15
176c176
< libocamlgraph-ocaml-dev   1.8.8-1.1+b1
---
> libocamlgraph-ocaml-dev   1.8.8-1.1+b2
203c203
< libpython3-stdlib:armel   3.8.2-3
---
> libpython3-stdlib:armel   3.8.6-1
206c206
< libre-ocaml-dev   1.9.0-1
---
> libre-ocaml-dev   1.9.0-1+b1
214,216c214,216
< libseccomp2:armel 2.4.4-1
< libselinux1:armel 3.1-2
< libselinux1-dev:armel 3.1-2
---
> libseccomp2:armel 2.4.4-1+b1
> libselinux1:armel 3.1-2+b1
> libselinux1-dev:armel 3.1-2+b1
227,228c227,228
< libstdc++-10-dev:armel10.2.0-13
< libstdc++6:armel  10.2.0-13
---
> libstdc++-10-dev:armel10.2.0-15
> libstdc++6:armel  10.2.0-15
244c244
< libubsan1:armel   10.2.0-13
---
> libubsan1:armel   10.2.0-15
260,261c260,261
< libxml2:armel 2.9.10+dfsg-6
< libxml2-dev:armel 2.9.10+dfsg-6
---
> libxml2:armel 2.9.10+dfsg-6.1
> libxml2-dev:armel 

Bug#978023: nmu: cpu-features_0.6.0-1

[Shengjing Zhu]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: binnmu
X-Debbugs-Cc: z...@debian.org

nmu cpu-features_0.6.0-1 . amd64 . unstable . -m "rebuild on buildd"

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

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

Bug#978022: libopenmpi3 Runtime failure opal_pmix_base_select failed

[Michael Banck]

Package: libopenmpi3
Version: 3.1.3-11
Severity: serious

Even with the fixed libpmix2_4.0.0~rc1-2, I am getting runtime failures
trying to run MPI programs, e.g. the nwchem autopkgtests all fail like
this:

| Running tests/water/water_md 
| 
| cleaning scratch
| copying input and verified output files
| running nwchem (/usr/bin/nwchem)  with 1 processors 
| 
| NWChem execution failed
|[kohn:13218] [[5127,0],0] ORTE_ERROR_LOG: Not found in file 
../../../../../../orte/mca/ess/hnp/ess_hnp_module.c at line 320
|--
|It looks like orte_init failed for some reason; your parallel process is
|likely to abort.  There are many reasons that a parallel process can
|fail during orte_init; some of which are due to configuration or
|environment problems.  This failure appears to be an internal failure;
|here's some additional information (which may only be relevant to an
|Open MPI developer):
|
|  opal_pmix_base_select failed
|  --> Returned value Not found (-13) instead of ORTE_SUCCESS
|--

Not sure whether this is libopenmpi3, openmpi-bin, libpmix2 or something
else, so please reassign as needed. But at least the openmpi excuses is
full of ci.debian.net regressions:

https://qa.debian.org/excuses.php?package=openmpi

Or is there something needed on the application side, like a new
environment variable or library to be linked in?


Michael

Bug#977143: python3-libtorrent: Bug also occurs in deluge-console

[Cem Onyuksel]

Package: python3-libtorrent
Version: 1.2.9-0.2+b2
Followup-For: Bug #977143
X-Debbugs-Cc: cem.onyuk...@gmail.com

Dear Maintainer,

I see this bug in deluge-console as well. Here's the error trace:

Python argument types in
torrent_handle.move_storage(torrent_handle, str)
did not match C++ signature:
move_storage(libtorrent::torrent_handle {lvalue}, 
std::__cxx11::basic_string,
std::allocator > path, libtorrent::move_flags_t 
flags=libtorrent.move_flags_t.always_replace_files)
Traceback (most recent call last):
  File "/usr/lib/python3/dist-packages/deluge/core/torrent.py", line 1246, in 
move_storage
self.handle.move_storage(dest.encode('utf8'), flags=2)
Boost.Python.ArgumentError: Python argument types in
torrent_handle.move_storage(torrent_handle, bytes)
did not match C++ signature:
move_storage(libtorrent::torrent_handle {lvalue}, 
std::__cxx11::basic_string,
std::allocator > path, libtorrent::move_flags_t 
flags=libtorrent.move_flags_t.always_replace_files)

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/usr/lib/python3/dist-packages/deluge/core/rpcserver.py", line 326, in 
dispatch
ret = self.factory.methods[method](*args, **kwargs)
  File "/usr/lib/python3/dist-packages/deluge/core/core.py", line 691, in 
move_storage
if not self.torrentmanager[torrent_id].move_storage(dest):
  File "/usr/lib/python3/dist-packages/deluge/core/torrent.py", line 1248, in 
move_storage
self.handle.move_storage(dest, flags=2)
Boost.Python.ArgumentError: Python argument types in
torrent_handle.move_storage(torrent_handle, str)
did not match C++ signature:
move_storage(libtorrent::torrent_handle {lvalue}, 
std::__cxx11::basic_string,
std::allocator > path, libtorrent::move_flags_t 
flags=libtorrent.move_flags_t.always_replace_files)


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

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

Versions of packages python3-libtorrent depends on:
ii  libboost-python1.74.0 [libboost-python1.74.0-py39]  1.74.0-5
ii  libc6   2.31-6
ii  libgcc-s1   10.2.1-1
ii  libssl1.1   1.1.1i-1
ii  libstdc++6  10.2.1-1
ii  libtorrent-rasterbar10  1.2.9-0.2+b2
ii  python3 3.9.1-1

python3-libtorrent recommends no packages.

python3-libtorrent suggests no packages.

-- no debconf information

Bug#928526: testing bug existence

[Mina Morcose Farage]

hi
is this bug existed  in testing kernel 5.9.11 ?

Bug#977645: linux-image-5.10.0-trunk-arm64: Both 5.10.1 and .2 do work on RPi3B+ with ext4 rootfs on sdcard

[Diederik de Haas]

Package: src:linux
Version: 5.10.2-1~exp1
Followup-For: Bug #977645

Just wanted to mention that this version as well as 5.10.1 do boot 
on a RPi3B+. It's not in any way contradicting this bug, but may be 
useful to know nonetheless.


-- Package-specific info:
** Version:
Linux version 5.10.0-trunk-arm64 (debian-ker...@lists.debian.org) (gcc-10 
(Debian 10.2.1-1) 10.2.1 20201207, GNU ld (GNU Binutils for Debian) 2.35.1) #1 
SMP Debian 5.10.2-1~exp1 (2020-12-22)

** Command line:
video=HDMI-A-1:1920x1080M@60,margin_left=48,margin_right=48,margin_top=48,margin_bottom=48
 dma.dmachans=0x7f35 bcm2709.boardrev=0xa020d3 bcm2709.serial=0x4db4eb14 
bcm2709.uart_clock=4800 bcm2709.disk_led_gpio=29 
bcm2709.disk_led_active_low=0 smsc95xx.macaddr=B8:27:EB:B4:EB:14 
vc_mem.mem_base=0x3ec0 vc_mem.mem_size=0x4000  console=tty0 
console=ttyS1,115200 root=/dev/mmcblk0p2 rw fsck.repair=yes net.ifnames=0 
cma=64M rootwait disable_fw_kms_setup=1

** Tainted: C (1024)
 * staging driver was loaded

** Kernel log:
[   13.233771] systemd[1]: Mounted POSIX Message Queue File System.
[   13.269941] systemd[1]: Mounted RPC Pipe File System.
[   13.301879] systemd[1]: Mounted Kernel Debug File System.
[   13.334267] systemd[1]: Mounted Kernel Trace File System.
[   13.369388] systemd[1]: Started Journal Service.
[   15.264660] bcm2835-wdt bcm2835-wdt: Broadcom BCM2835 watchdog timer
[   15.277293] vchiq: module is from the staging directory, the quality is 
unknown, you have been warned.
[   15.684981] alg: No test for fips(ansi_cprng) (fips_ansi_cprng)
[   15.895410] hid: raw HID events driver (C) Jiri Kosina
[   16.001054] cfg80211: Loading compiled-in X.509 certificates for regulatory 
database
[   16.020592] cfg80211: Loaded X.509 cert 'b...@debian.org: 
577e021cb980e0e820821ba7b54b4961b8b4fadf'
[   16.021187] libphy: Fixed MDIO Bus: probed
[   16.040951] cfg80211: Loaded X.509 cert 'romain.per...@gmail.com: 
3abbc6ec146e09d1b6016ab9d6cf71dd233f0328'
[   16.070420] usbcore: registered new interface driver usbhid
[   16.077020] cfg80211: Loaded X.509 cert 'sforshee: 00b28ddf47aef9cea7'
[   16.088116] usbhid: USB HID core driver
[   16.127572] platform regulatory.0: firmware: direct-loading firmware 
regulatory.db
[   16.146777] platform regulatory.0: firmware: direct-loading firmware 
regulatory.db.p7s
[   16.208404] cryptd: max_cpu_qlen set to 1000
[   16.372179] lan78xx 1-1.1.1:1.0 (unnamed net_device) (uninitialized): No 
External EEPROM. Setting MAC Speed
[   16.410860] brcmfmac: brcmf_fw_alloc_request: using brcm/brcmfmac43455-sdio 
for chip BCM4345/6
[   16.437335] usbcore: registered new interface driver brcmfmac
[   16.445395] libphy: lan78xx-mdiobus: probed
[   16.493071] brcmfmac mmc1:0001:1: firmware: direct-loading firmware 
brcm/brcmfmac43455-sdio.bin
[   16.516817] brcmfmac mmc1:0001:1: firmware: direct-loading firmware 
brcm/brcmfmac43455-sdio.raspberrypi,3-model-b-plus.txt
[   16.655211] snd_bcm2835: module is from the staging directory, the quality 
is unknown, you have been warned.
[   16.707881] input:   mini keyboard as 
/devices/platform/soc/3f98.usb/usb1/1-1/1-1.1/1-1.1.2/1-1.1.2:1.0/0003:1997:2433.0001/input/input0
[   16.716699] mc: Linux media interface: v0.10
[   16.718052] brcmfmac: brcmf_fw_alloc_request: using brcm/brcmfmac43455-sdio 
for chip BCM4345/6
[   16.718219] brcmfmac mmc1:0001:1: firmware: failed to load 
brcm/brcmfmac43455-sdio.clm_blob (-2)
[   16.718222] firmware_class: See https://wiki.debian.org/Firmware for 
information about missing firmware
[   16.718230] brcmfmac: brcmf_c_process_clm_blob: no clm_blob available 
(err=-2), device may have limited channels available
[   16.718961] brcmfmac: brcmf_c_preinit_dcmds: Firmware: BCM4345/6 wl0: Mar  1 
2015 07:29:38 version 7.45.18 (r538002) FWID 01-6a2c8ad4
[   16.729295] debugfs: Directory '3f902000.hdmi' with parent 'vc4-hdmi' 
already present!
[   16.766644] hid-generic 0003:1997:2433.0001: input,hidraw0: USB HID v1.01 
Keyboard [  mini keyboard] on usb-3f98.usb-1.1.2/input0
[   16.767079] usbcore: registered new interface driver lan78xx
[   16.784405] videodev: Linux video capture interface: v2.00
[   16.800597] input:   mini keyboard Mouse as 
/devices/platform/soc/3f98.usb/usb1/1-1/1-1.1/1-1.1.2/1-1.1.2:1.1/0003:1997:2433.0002/input/input1
[   17.064785] input:   mini keyboard System Control as 
/devices/platform/soc/3f98.usb/usb1/1-1/1-1.1/1-1.1.2/1-1.1.2:1.1/0003:1997:2433.0002/input/input2
[   17.113125] vc4_hdmi 3f902000.hdmi: ASoC: no DMI vendor name!
[   17.120695] bcm2835_mmal_vchiq: module is from the staging directory, the 
quality is unknown, you have been warned.
[   17.136657] input:   mini keyboard Consumer Control as 
/devices/platform/soc/3f98.usb/usb1/1-1/1-1.1/1-1.1.2/1-1.1.2:1.1/0003:1997:2433.0002/input/input3
[   17.140203] vc4-drm soc:gpu: bound 3f902000.hdmi (ops vc4_hdmi_ops [vc4])
[   17.140452] vc4-drm soc:gpu: bound 3f806000.vec (ops vc4_vec_ops [vc4])
[   17.140575] vc4-drm s

Bug#963711: Found in 87 line

[Daniel Serpell]

Hi!

On Thu, 24 Dec 2020 14:37:09 +0100 Michel Le Bihan  wrote:
> Hello,
>
> This issue is about Chromium crashing just after startup with debug
> when it did not crash that quickly without debug. Is Chromium as stable
> with debug as without it?
>
> All Chromium packages in Debian unstable and the build on my website
> were affected by https://bugs.debian.org/977901 . If it's the issue you
> are writing about, then a new package that should fix this was uploaded
> today and should be built soon.
>

Sorry, I replied to the wrong bug. The version I have currently installed
is 87.0.4280.88-0.3, this is the one that is not crashing. the old version,
87.0.4280.88-0.2 crashed all the time.

Regards,
Daniel.

Bug#973433: reproducing bug

[Mina Morcose Farage]

is this bug happen in the current testing kernel  5.9.11 ?

Bug#975381: Subject: libinih: drop Debian's custom vendorisation

[Andreas Metzler]

On 2020-11-21 Stephan Lachnit  wrote:
[...]
> Because the library was designed for embedded use cases where every
> little bit of performance matters, the runtime patch was refused
> upstream. Dropping the runtime patch from Debian actually isn't
> problem, no reverse dependency of libinih uses compile time options
> anyway.

Hello,

goxel does.[1]

goxel-0.10.6/src/utils/ini.h:#define INI_HANDLER_LINENO 1

and gnutls would, too.

So imho inih upstream needs a interface that allows linking either
dynamically against system libinih or statically against the included
copy without changing the source with something equivalent to the
compile time options. The current Debian-patched version requires source
changes depending on what linkage is targeted, upstream's version of the
dynamic library just does not work when these compile time options are
needed. 

cu Andreas

[1] Which is probably why it actually uses the static copy although it
depends on libinih. (#978021)
-- 
`What a good friend you are to him, Dr. Maturin. His other friends are
so grateful to you.'
`I sew his ears on from time to time, sure'

Bug#905050: mpv: why does mpv tell it's built on unknown [PATCH]

[Richard Noble]

Control: tags -1 + patch

[resending as debbugs seems to have ignored my first attempt]

One way of fixing this bug is to set the BUILDDATE variable
based on the timestamp of the most recent debian changelog entry.

That way BUILDDATE contains a sane date instead of "UNKNOWN",
but the build is reproducible (all builds from the same source
package version will have the same date).

Patch attached below. In order for it to take effect, it is
necessary to remove --disable-build-date option in debian/rules,
i.e. revert the patch from https://bugs.debian.org/784267


--- a/version.sh
+++ b/version.sh
@@ -53,7 +53,7 @@

 NEW_REVISION="#define VERSION \"${VERSION}\""
 OLD_REVISION=$(head -n 1 "$version_h" 2> /dev/null)
-BUILDDATE="#define BUILDDATE \"$(date)\""
+BUILDDATE="#define BUILDDATE \"$(date -u --date=@$(dpkg-parsechangelog -S 
Timestamp))\""
 MPVCOPYRIGHT="#define MPVCOPYRIGHT \"Copyright © 2000-2018 
mpv/MPlayer/mplayer2 projects\""

 # Update version.h only on revision changes to avoid spurious rebuilds

Bug#978021: goxel: Unused dependency on libinih

[Andreas Metzler]

Package: goxel
Version: 0.10.6-1
Severity: important

Goxel build-depends on libinih-dev and has a hard-coded runtime
dependency on libinih1. However neither is used.

Afaict goxel cannot be linked dynamically against libinih without
requiring the Debian patched version because it uses inih compile
options
goxel-0.10.6/src/utils/ini.h:#define INI_HANDLER_LINENO 1

cu Andreas


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

Kernel: Linux 5.9.0-4-amd64 (SMP w/4 CPU threads)
Locale: LANG=de_AT.UTF-8, LC_CTYPE=de_AT.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
-- 
`What a good friend you are to him, Dr. Maturin. His other friends are
so grateful to you.'
`I sew his ears on from time to time, sure'

Bug#977900: node-autoprefixer: FTBFS: ENOENT: no such file or directory, open 'path'

[Pirate Praveen]

Control: tags -1 pending

On Tue, 22 Dec 2020 16:25:36 +0100 Andreas Beckmann  
wrote:

> debian/autoprefixer.js → dist/autoprefixer.js...
> [!] Error: Could not load path (imported by 
./../usr/share/nodejs/postcss/lib/map-generator.js): ENOENT: no such 
file or directory, open 'path'
> Error: Could not load path (imported by 
./../usr/share/nodejs/postcss/lib/map-generator.js): ENOENT: no such 
file or directory, open 'path'

>
> make[1]: *** [debian/rules:14: override_dh_auto_build] Error 1
> make[1]: Leaving directory '/build/node-autoprefixer-10.0.0'
> make: *** [debian/rules:11: binary] Error 2
>
> A previous build on Oct 28 has been successful, so this current 
failure is probably

> caused by some updated (transitive) build-depends.

It is fixed by changing the order of plugins used in rollup.config.js, 
rollup-plugin-polyfills should come before commonjs and node-resolve 
plugins.

Bug#978020: droopy: Authentication option not available

[KenichiroMATOHARA]

Package: droopy
Version: 0.20160830-2
Severity: normal

Dear Maintainer,

droopy has an authentication option.
> $ droopy -h | grep auth
>   -a AUTH, --auth AUTH  set the authentication credentials, in form USER:PASS

if you try to use this, an error will occur and droopy will not be available.

> $ droopy -d /tmp/upload -m "hello droopy." -p
/tmp/upload/20201224_18\:12\:13-3733667.jpg --chmod 400 -a USER:PASS
>  _
> | \..-.-.-.--.--.
> |  --  |   _|  _  |  _  |  _  |  |  |
> |_/|__| |_|_|   __|___  |
> |__|  |_|
>
> No configuration file found
> Files will be uploaded to /tmp/upload
>
> HTTP server starting... Check it out at http://localhost:8000
> 
> Exception occurred during processing of request from (127.0.0.1, 35446)
> Traceback (most recent call last):
>   File "/usr/lib/python3.9/socketserver.py", line 650, in
process_request_thread
> self.finish_request(request, client_address)
>   File "/usr/lib/python3.9/socketserver.py", line 360, in finish_request
> self.RequestHandlerClass(request, client_address, self)
>   File "/usr/lib/python3.9/socketserver.py", line 720, in __init__
> self.handle()
>   File "/usr/bin/droopy", line 397, in handle
> httpserver.BaseHTTPRequestHandler.handle(self)
>   File "/usr/lib/python3.9/http/server.py", line 427, in handle
> self.handle_one_request()
>   File "/usr/lib/python3.9/http/server.py", line 415, in handle_one_request
> method()
>   File "/usr/bin/droopy", line 122, in decorated
> expected = Basic  + base64.b64encode(self.auth)
>   File "/usr/lib/python3.9/base64.py", line 58, in b64encode
> encoded = binascii.b2a_base64(s, newline=False)
> TypeError: a bytes-like object is required, not str
> 

It seems that it has been fixed upstream.
"Make basic authentication work for python 2 & python 3 · hdf/Droopy@3ac476f"
https://github.com/hdf/Droopy/commit/3ac476fe4a703c1df99aa5208e1646468ee6aa65

I tried it and it worked.
> $ wget
https://raw.githubusercontent.com/hdf/Droopy/3ac476fe4a703c1df99aa5208e1646468ee6aa65/droopy
> $ python3 ./droopy -a user:pass



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

Kernel: Linux 5.9.11-mptcp (SMP w/4 CPU threads)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_CRAP, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=ja_JP.UTF-8, LC_CTYPE=ja_JP.UTF-8 (charmap=UTF-8) (ignored: LC_ALL 
set to ja_JP.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 droopy depends on:
ii  python3  3.9.1-1

droopy recommends no packages.

droopy suggests no packages.

-- no debconf information

Bug#977688: node-css-loader: please embed additional postcss extensions

[Pirate Praveen]

Control: block -1 by 977900
Control: tag 977900 help

On Sat, 19 Dec 2020 23:21:20 +0530 Pirate Praveen 
 wrote:

> I'd like to update css-loader to latest upstream release/postcss 8
> transition before I work on this.

node-postcss 8 transition is blocked by an ftbfs bug in 
node-autoprefixer


https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=977900 (need help)

Bug#977452: transition: fmtlib

[Shengjing Zhu]

Some status updates.

On Wed, Dec 16, 2020 at 1:19 AM Shengjing Zhu  wrote:
> spdlog is ftbfs because of symbols file, and is pending upload #977454
> Rebuild with fixed spdlog and fmtlib, following packages ftbfs, but
> not related to fmtlib/7.1.3
>

spdlog is fixed and migrated to testing

> + pytorch, impossible to build on a personal computer.. but only in sid..

pytorch originally failed to build with fmtlib/7.1.3, but has been
fixed and migrated to testing.

> + sopt #975843, ftbfs without fmtlib/7.1.3

Though it ftbfs for other reasons, it has been fixed and migrated to testing.

> + lizardfs ftbfs without fmtlib/7.1.3, only in sid
> + dpaste ftbfs without fmtlib/7.1.3, only in sid
>
> Other packages are just fine to build.

-- 
Shengjing Zhu

Bug#978019: ITP: golang-github-enescakir-emoji -- minimalistic emoji package for Go

[Cyril Brulebois]

Package: wnpp
Severity: wishlist
Owner: Cyril Brulebois 

* Package name: golang-github-enescakir-emoji
  Version : 1.0.0-1
  Upstream Author : Enes Çakır
* URL : https://github.com/enescakir/emoji
* License : Expat
  Programming Lang: Go
  Description : minimalistic emoji package for Go

 emoji is a minimalistic emoji library for Go. It makes it possible to
 use emoji characters in strings.
 .
 This package contains emoji constants based on the Full Emoji List
 v13.0, and also has additional emoji aliases from GitHub's gemoji
 library.


Part of the crowdsec packaging effort:
  https://lists.debian.org/debian-go/2020/12/msg00019.html


Cheers,
-- 
Cyril Brulebois -- Debian Consultant @ DEBAMAX -- https://debamax.com/


signature.asc
Description: PGP signature

Bug#974860: Forwarded to upstream

[Martin Steigerwald]

Silvério Santos - 24.12.20, 14:18:18 CET:
> forwarded -1 https://bugs.kde.org/show_bug.cgi?id=430787

Please retest once you upgraded to Plasma 5.20 and KF 5.77. They should 
appear in testing soon.

Have a Merry Christmas if you celebrate it, have a quiet and peaceful 
time,
-- 
Martin

Bug#978018: libapr1: Please add 64-bit atomics workaround for m68k and sh4

[John Paul Adrian Glaubitz]

Source: apr
Version: 1.7.0-4
Severity: normal
User: debian-...@lists.debian.org
Usertags: m68k
X-Debbugs-Cc: debian-...@lists.debian.org

Hello!

subversion currently FTBFS on m68k and sh4 because the configure process fails
to properly link against libserf [1]:

configure:5604: gcc -o conftest -g -O2 
-fdebug-prefix-map=/build/subversion-5EzMph/subversion-1.14.0=. 
-specs=/usr/share/dpkg/pie-compile.specs -fstack-protector-strong -Wformat 
-Werror=format-security   -pthread -Wdate-time -D_FORTIFY_SOURCE=2   -DLINUX 
-D_REENTRANT -D_GNU_SOURCE -D_LARGEFILE64_SOURCE  -I/usr/include/apr-1.0   
-I/usr/include/apr-1.0 -I/usr/include -I/usr/include/serf-1 
-specs=/usr/share/dpkg/pie-link.specs -Wl,-z,relro -Wl,-z,nowconftest.c 
-lserf-1 -L/usr/lib/m68k-linux-gnu -laprutil-1 -L/usr/lib/m68k-linux-gnu 
-lapr-1 -lz  >&5
/usr/bin/ld: /usr/lib/m68k-linux-gnu/libapr-1.so: undefined reference to 
`__sync_fetch_and_sub_8'
/usr/bin/ld: /usr/lib/m68k-linux-gnu/libapr-1.so: undefined reference to 
`__sync_sub_and_fetch_8'
/usr/bin/ld: /usr/lib/m68k-linux-gnu/libapr-1.so: undefined reference to 
`__sync_fetch_and_add_8'
/usr/bin/ld: /usr/lib/m68k-linux-gnu/libapr-1.so: undefined reference to 
`__sync_lock_test_and_set_8'
/usr/bin/ld: /usr/lib/m68k-linux-gnu/libapr-1.so: undefined reference to 
`__sync_val_compare_and_swap_8'
collect2: error: ld returned 1 exit status

This should be fixable using the same approach as for 32-bit MIPS and PowerPC 
[2].

Could you therefore apply the fix for m68k and sh4 as well so that subversions 
builds on these targets?

Thanks,
Adrian

> [1] 
> https://buildd.debian.org/status/fetch.php?pkg=subversion&arch=m68k&ver=1.14.0-3&stamp=1608803200&raw=0
> [2] 
> https://salsa.debian.org/apache-team/apr/-/commit/2df4f34a2fa3474806f89a15148afa7121c642bf

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

Bug#978006: extra-cmake-modules: please change the section of the package

[Laurent Bonnaud]

Package: extra-cmake-modules
Version: 5.77.0-2
Severity: normal


Dear Maintainer,

when I run "deborphan" on my system, the extra-cmake-modules package is always listed as an 
"orphaned" library.  This comes from the fact that this package is in the "libs" section 
and no other package depends on it:

$ dpkg -s extra-cmake-modules
[...]
Section: libs

How about changing the section from "libs" to "devel"? (the cmake package 
belongs to the devel section)


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

Kernel: Linux 5.10.0-trunk-rt-amd64 (SMP w/2 CPU threads; PREEMPT)
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

extra-cmake-modules depends on no packages.

extra-cmake-modules recommends no packages.

Versions of packages extra-cmake-modules suggests:
ii  qt5-qmake5.15.2+dfsg-2
ii  qtbase5-dev  5.15.2+dfsg-2

-- no debconf information

--
Laurent.

Bug#974781: reopen, needs further work

[Matthias Klose]

Control: reopen -1

failed to build. falling back to LLVM 9 for now.

Bug#978017: opencascade: please, make dependency on libvtk7 optional

[Daniel Serpell]

Source: opencascade
Version: 7.5.0+dfsg1-2
Severity: wishlist

Dear maintainer,

Most applications depending on libocct-* libraries do not need the Vtk 
visualization
(for example Kicad) and Vtk adds about 220MB of extra disk space.

It would be great if the dependency to Vtk could be made optional (or a 
recomends), so
that users that does not need the visuzalization can omit it.

Regards,

Daniel.

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

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

Bug#977894: gui is broken, python3-xdo

[Joey Hess]

Daniel Kahn Gillmor wrote:
> thanks for the diagnosis, Joey!  this looks like a change between the
> ctypes module between python 3.8 and 3.9.  I'll fix it in python3-xdo,
> and hopefully that will resolve your problem.

Independent of getting this fixed, I think it's concerning that ctypes
falls back to looking for library files in cwd when a shared library is
unavailable. That has potential to be part of a security exploit chain,
although I have not dug deeply enough to know if it's exploitable.

-- 
see shy jo


signature.asc
Description: PGP signature

Bug#963711: Found in 87 line

[Michel Le Bihan]

Hello,

This issue is about Chromium crashing just after startup with debug
when it did not crash that quickly without debug. Is Chromium as stable
with debug as without it?

All Chromium packages in Debian unstable and the build on my website
were affected by https://bugs.debian.org/977901 . If it's the issue you
are writing about, then a new package that should fix this was uploaded
today and should be built soon.

Michel Le Bihan

Le jeudi 24 décembre 2020 à 09:55 -0300, Daniel Serpell a écrit :
> Hi!
> 
> On Wed, 23 Dec 2020 10:15:16 +0100 Michel Le Bihan
>  wrote:
> > Hello,
> > 
> > Could you please confirm that this works for you in a new profile?
> > 
> 
> Installed the packages yesterday, been about 12 hours without a
> crash!
> 
> So, I would say it resolves the issue.
> 
> Thanks,
>     Daniel.
> 

Bug#977243: Still not fixed

[Anton Gladky]

tags 977243 -pending
thanks

CC-ing on of upstream contributors.

@Casey could you please take a look? This part of the code
fails with the newer boost_1.74? Thanks!

It looks like the last version in git still fails to build.

===
ceph/src/common/async/completion.h: In instantiation of 'void
ceph::async::detail::CompletionImpl::destroy_defer(std::tuple&&) [with Executor1 =
boost::asio::io_context::basic_executor_typ
e, 0>; Handler =
boost::asio::detail::coro_handler,
boost::asio::exec
ution::detail::blocking::never_t<0>,
boost::asio::execution::prefer_only
>, 
>boost::asio::execution::prefer_only
>, boos
t::asio::execution::prefer_only
>, 
>boost::asio::execution::prefer_only
>, boost::asio::execution::prefer_only > > >, void>;
T = void; Args = {boost::system::error_code}]':
/root/mod1/ceph/src/common/async/completion.h:188:8:   required from
here
/root/mod1/ceph/src/common/async/completion.h:194:29: error:
'boost::asio::executor_work_guard,
boost::asio::execution::detail::blo
cking::never_t<0>,
boost::asio::execution::prefer_only
>, 
>boost::asio::execution::prefer_only
>, boost::asio::execution
::prefer_only
>, 
>boost::asio::execution::prefer_only
>, boost::asio::execution::prefer_only > >, void>::executor_type' {aka
'class 
boost::asio::execution::any_executor,
boost::asio::execution::detail::blocking::never_t<0>
, 
boost::asio::execution::prefer_only
>, 
>boost::asio::execution::prefer_only
>, boost::asio::execution::prefer_only >,
boost::asio::execution::prefer_only
>, 
>boost::asio::execution::prefer_only > >'} has no member named 'defer'; did you mean 'prefer'?
  194 | w.second.get_executor().defer(std::move(f), alloc2);
  | ^
  | prefer
ceph/src/common/async/completion.h: In instantiation of 'void
ceph::async::detail::CompletionImpl::destroy_dispatch(std::tuple&&) [with Executor1 =
boost::asio::io_context::basic_executor_
type, 0>; Handler =
boost::asio::detail::coro_handler,
boost::asio::e
xecution::detail::blocking::never_t<0>,
boost::asio::execution::prefer_only
>, 
>boost::asio::execution::prefer_only
>, b
oost::asio::execution::prefer_only
>, 
>boost::asio::execution::prefer_only
>, boost::asio::execution::prefer_only > > >,
void>; T = void; Args = {boost::system::error_code}]':
/root/mod1/ceph/src/common/async/completion.h:196:8:   required from here
/root/mod1/ceph/src/common/async/completion.h:202:29: error:
'boost::asio::executor_work_guard,
boost::asio::execution::detail::blo
cking::never_t<0>,
boost::asio::execution::prefer_only
>, 
>boost::asio::execution::prefer_only
>, boost::asio::execution
::prefer_only
>, 
>boost::asio::execution::prefer_only
>, boost::asio::execution::prefer_only > >, void>::executor_type' {aka
'class 
boost::asio::execution::any_executor,
boost::asio::execution::detail::blocking::never_t<0>
, 
boost::asio::execution::prefer_only
>, 
>boost::asio::execution::prefer_only
>, boost::asio::execution::prefer_only >,
boost::asio::execution::prefer_only
>, 
>boost::asio::execution::prefer_only > >'} has no member named 'dispatch'
  202 | w.second.get_executor().dispatch(std::move(f), alloc2);
| ^~~~
ceph/src/common/async/completion.h: In instantiation of 'void
ceph::async::detail::CompletionImpl::destroy_post(std::tuple&&) [with Executor1 =
boost::asio::io_context::basic_executor_type
, 0>; Handler =
boost::asio::detail::coro_handler,
boost::asio::execu
tion::detail::blocking::never_t<0>,
boost::asio::execution::prefer_only
>, 
>boost::asio::execution::prefer_only
>, boost
::asio::execution::prefer_only
>, 
>boost::asio::execution::prefer_only
>, boost::asio::execution::prefer_only > > >, void>;
T = void; Args = {boost::system::error_code}]':
/root/mod1/ceph/src/common/async/completion.h:204:8:   required from here
/root/mod1/ceph/src/common/async/completion.h:210:29: error:
'boost::asio::executor_work_guard,
boost::asio::execution::detail::blo
cking::never_t<0>,
boost::asio::execution::prefer_only
>, 
>boost::asio::execution::prefer_only
>, boost::asio::execution
::prefer_only
>, 
>boost::asio::execution::prefer_only
>, boost::asio::execution::prefer_only > >, void>::executor_type' {aka
'class 
boost::asio::execution::any_executor,
boost::asio::execution::detail::blocking::never_t<0>
, 
boost::asio::execution::prefer_only
>, 
>boost::asio::execution::prefer_only
>, boost::asio::execution::prefer_only >,
boost::asio::execution::prefer_only
>, 
>boost::asio::execution::prefer_only > >'} has no member named 'post'
  210 | w.second.get_executor().post(std::move(f), alloc2);
  | ^~~~

===

Best regards

Anton

Bug#977894: gui is broken, python3-xdo

[Daniel Kahn Gillmor]

Control: reassign 977894 python3-xdo
Control: affects 977894 + impass
Control: severity critical
Control: retitle 977894 python3-xdo: fails with python3.9 due to bad libc 
linkage

thanks for the diagnosis, Joey!  this looks like a change between the
ctypes module between python 3.8 and 3.9.  I'll fix it in python3-xdo,
and hopefully that will resolve your problem.

--dkg

On Wed 2020-12-23 20:46:42 -0400, Joey Hess wrote:
> Yes, I get the same backtrace from both the 2 line script and the
> modified impass:
>
> joey@darkstar:~>impass gui
> Traceback (most recent call last):
>   File "/usr/bin/impass", line 11, in 
> load_entry_point('impass==0.12', 'console_scripts', 'impass')()
>   File "/usr/lib/python3/dist-packages/impass/__main__.py", line 620, in main
> func(args)
>   File "/usr/lib/python3/dist-packages/impass/__main__.py", line 350, in gui
> import xdo
>   File "/usr/lib/python3/dist-packages/xdo/__init__.py", line 8, in 
> from ._xdo import libxdo as _libxdo
>   File "/usr/lib/python3/dist-packages/xdo/_xdo.py", line 14, in 
> libc = ctypes.CDLL(ctypes.util.find_library('libc'))
>   File "/usr/lib/python3.9/ctypes/util.py", line 341, in find_library
> _get_soname(_findLib_gcc(name)) or _get_soname(_findLib_ld(name))
>   File "/usr/lib/python3.9/ctypes/util.py", line 147, in _findLib_gcc
> if not _is_elf(file):
>   File "/usr/lib/python3.9/ctypes/util.py", line 99, in _is_elf
> with open(filename, 'br') as thefile:
> FileNotFoundError: [Errno 2] No such file or directory: b'liblibc.a'
>
> And so I modified /usr/lib/python3/dist-packages/xdo/_xdo.py as follows,
> which fixed the problem:
>
> - libc = ctypes.CDLL(ctypes.util.find_library('libc'))
> + libc = ctypes.CDLL(ctypes.util.find_library('c'))


signature.asc
Description: PGP signature

Bug#974860: Forwarded to upstream

[Silvério Santos]

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

Bug#977639: bible-kjv: Possible GPL compliance problems

[Matthew Vernon]

On 19/12/2020 21:00, Bastian Germann wrote:

Am 19.12.20 um 20:28 schrieb Matthew Vernon:

On 19/12/2020 13:28, Bastian Germann wrote:
On Fri, 18 Dec 2020 00:01:10 +0100 Bastian Germann 
 wrote:> bible-kjv package claims to be 
GPLv2 licensed. One file has an "or
later" clause but some files seem to GPLv2-only. However, with the 
switch to readline6 (#553733), it uses a GPLv3 library. GPLv3 and 
GPLv2-only are known to be incompatible licenses, so please build 
with libedit instead. A patch is enclosed.


Instead of applying this patch, you can also build-depend on 
libeditreadline-dev, which allows to build with libedit while keeping 
the readline interface.


I could also, presumably, adjust the licence to be GPL2+? The only bit 
of the code that is GPL2 and isn't my copyright is randverse, which 
isn't linked against readline.


Sure. That is another solution.


I've been in touch with Oliver Elphick, the author of randverse, and he 
is happy for that to be GPL2+ as well, so I'm going to resolve this 
issue by relicencing. Possibly not before Christmas now, mind...


Regards,

Matthew

Bug#978016: ITP: golang-github-appleboy-gofight -- API Handler Testing for Golang Web framework

[Cyril Brulebois]

Package: wnpp
Severity: wishlist
Owner: Cyril Brulebois 

* Package name: golang-github-appleboy-gofight
  Version : 2.1.2-1
  Upstream Author : Bo-Yi Wu
* URL : https://github.com/appleboy/gofight
* License : Expat
  Programming Lang: Go
  Description : API Handler Testing for Golang Web framework

 This framework makes it possible to test various API handlers:
  - Http Handler
  - Gin
  - Echo
  - Mux
  - HttpRouter
  - Pat
  - beego


Part of the crowdsec packaging effort:
  https://lists.debian.org/debian-go/2020/12/msg00019.html


Cheers,
-- 
Cyril Brulebois -- Debian Consultant @ DEBAMAX -- https://debamax.com/


signature.asc
Description: PGP signature

Bug#976943: golang-github-seccomp-libseccomp-golang: FTBFS on ppc64el (arch:all-only src pkg): dh_auto_test: error: cd obj-powerpc64le-linux-gnu && go test -vet=off -v -p 160 github.com/seccomp/libsec

[Lucas Nussbaum]

On 14/12/20 at 14:36 -0500, Reinhard Tartler wrote:
> 
> 
> > === RUN   TestRuleAddAndLoad
> > seccomp_test.go:588: Syscall should have returned error code!
> > --- FAIL: TestRuleAddAndLoad (0.00s)
> 
> 
> Source code is here: 
> https://sources.debian.org/src/golang-github-seccomp-libseccomp-golang/0.9.1-2/seccomp_test.go/#L529-L589
> 
> This test is basically loading a seccomp rule and expects that the
> getpid() syscall fails with the rule loaded, but in that test it seems
> to pass. This might mean that seccomp isn't working on that box.
> 
> Lucas, can you elaborate a bit what kind of test system you were using?
> Do you have any explanation what might be going on with the test setup that
> would make seccomp not work or only under certain conditions?

Hi,

This is a system running plain debian stable with an unstable chroot
(using sbuild). I cannot think of something strange. I tried disabling
SMT (hyperthreading) because with it enabled, the system has 160 visible
cores, which breaks some builds. But it did not change anything.

# uname -a
Linux drac-6.grenoble.grid5000.fr 4.19.0-13-powerpc64le #1 SMP Debian 
4.19.160-2 (2020-11-28) ppc64le GNU/Linux

I also tried with a Debian testing image and could reproduce it. Kernel
was linux-image-5.9.0-1-powerpc64le  5.9.1-1

Lucas

Bug#976933: [rt.cpan.org #118730] libsys-cpuaffinity-perl: FTBFS: Failed test 'bind to all processors successful 18446744073709551615 == 18446744073709551616-1'

[Lucas Nussbaum]

On 19/12/20 at 17:29 +0100, gregor herrmann wrote:
> On Sat, 19 Dec 2020 01:06:49 -0500, Marty O'Brien via RT wrote:
> 
> > https://rt.cpan.org/Ticket/Display.html?id=118730 >
> 
> > On Fri Dec 18 12:04:27 2020, GREGOA wrote:
> > > And we have another test failure, found again by Lucas, on a 160 CPU
> > > machine:
> > > https://bugs.debian.org/976933
> > 
> > Working hypothesis: taskset(1) can only retrieve affinity data for
> > the first 64 cores; I don't know whether it can update affinity for
> > so many cores or not.
> > 
> > Uploaded Sys::CpuAffinity 1.13_01. I will give the
> > xs_sched_setaffinity/xs_sched_getaffinity  functions higher
> > priority than the  taskset  call and see if that solves more
> > problems than it creates.
> 
> Thank you!
> Uploaded to Debian.
> 
> Lucas, do you have a chance to test libsys-cpuaffinity-perl_1.13~01-1
> on this 160 CPU grid where you found #976933?

Hi Gregor,

It fails. I've attached the log.

Lucas
sbuild (Debian sbuild) 0.78.1 (09 February 2019) on drac-6.grenoble.grid5000.fr

+==+
| libsys-cpuaffinity-perl 1.13~01-1 (ppc64el)  Thu, 24 Dec 2020 11:00:31 + |
+==+

Package: libsys-cpuaffinity-perl
Version: 1.13~01-1
Source Version: 1.13~01-1
Distribution: unstable
Machine Architecture: ppc64el
Host Architecture: ppc64el
Build Architecture: ppc64el
Build Type: full

I: NOTICE: Log filtering will replace 
'var/run/schroot/mount/sid-ppc64el-sbuild-0a9c2070-ea16-4bf7-8fb4-bfb7e9ca' 
with '<>'
I: NOTICE: Log filtering will replace 
'build/libsys-cpuaffinity-perl-l9d8Gx/resolver-pasQDG' with '<>'

+--+
| Update chroot|
+--+

Hit:1 http://127.0.0.1:12990/debian sid InRelease
Reading package lists...
Reading package lists...
Building dependency tree...
Calculating upgrade...
0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.

+--+
| Fetch source files   |
+--+


Check APT
-

Checking available source versions...

Download source files with APT
--

Reading package lists...
NOTICE: 'libsys-cpuaffinity-perl' packaging is maintained in the 'Git' version 
control system at:
https://salsa.debian.org/perl-team/modules/packages/libsys-cpuaffinity-perl.git
Please use:
git clone 
https://salsa.debian.org/perl-team/modules/packages/libsys-cpuaffinity-perl.git
to retrieve the latest (possibly unreleased) updates to the package.
Need to get 53.1 kB of source archives.
Get:1 http://127.0.0.1:12990/debian sid/main libsys-cpuaffinity-perl 1.13~01-1 
(dsc) [2463 B]
Get:2 http://127.0.0.1:12990/debian sid/main libsys-cpuaffinity-perl 1.13~01-1 
(tar) [47.8 kB]
Get:3 http://127.0.0.1:12990/debian sid/main libsys-cpuaffinity-perl 1.13~01-1 
(diff) [2812 B]
Fetched 53.1 kB in 0s (791 kB/s)
Download complete and in download only mode
I: NOTICE: Log filtering will replace 
'build/libsys-cpuaffinity-perl-l9d8Gx/libsys-cpuaffinity-perl-1.13~01' with 
'<>'
I: NOTICE: Log filtering will replace 'build/libsys-cpuaffinity-perl-l9d8Gx' 
with '<>'

+--+
| Install package build dependencies   |
+--+


Setup apt archive
-

Merged Build-Depends: debhelper-compat (= 13), libmodule-build-perl, 
perl-xs-dev, perl, build-essential, fakeroot
Filtered Build-Depends: debhelper-compat (= 13), libmodule-build-perl, 
perl-xs-dev, perl, build-essential, fakeroot
dpkg-deb: building package 'sbuild-build-depends-main-dummy' in 
'/<>/apt_archive/sbuild-build-depends-main-dummy.deb'.
Ign:1 copy:/<>/apt_archive ./ InRelease
Get:2 copy:/<>/apt_archive ./ Release [957 B]
Ign:3 copy:/<>/apt_archive ./ Release.gpg
Get:4 copy:/<>/apt_archive ./ Sources [392 B]
Get:5 copy:/<>/apt_archive ./ Packages [472 B]
Fetched 1821 B in 0s (106 kB/s)
Reading package lists...
Reading package lists...

Install main build dependencies (apt-based resolver)


Installing build dependencies
Reading package lists...
Building dependency tree...
The following additional packages will be installed:
  autoconf automake autopoint autotools-dev bsdextrautils debhelper
  dh-autoreconf dh-strip-nondeterminism dwz file gettext gettext-base
  groff-base intltool-debian libarchive-zip-perl libdebhelper-perl libelf1
  libfile-stripnondeterminism-perl libicu67 libmagic-mgc libmagi

Bug#976918: memkind: FTBFS on ppc64el: GetArenaTest.test_TC_MEMKIND_ThreadHash failed

[Lucas Nussbaum]

Hi Adam,

On 18/12/20 at 08:46 +0100, Adam Borowski wrote:
> Control: tags -1 + moreinfo unreproducible
> 
> Hi Lucas!
> 
> > On Wed, Dec 09, 2020 at 09:39:08AM +0100, Lucas Nussbaum wrote:
> > > Source: memkind
> 
> > > During a rebuild of all packages in sid, your package failed to build
> > > on ppc64el. At the same time, it did not fail on amd64.
> > 
> > > I'm marking this bug as severity:serious since your package currently has
> > > ppc64el binary packages in unstable (so this is a regression).
> 
> > > > [ RUN  ] GetArenaTest.test_TC_MEMKIND_ThreadHash
> > > > test/get_arena_test.cpp:67: Failure
> > > > Expected: (max_collisions) <= (collisions_limit), actual: 10 vs 5
> > > > [  FAILED  ] GetArenaTest.test_TC_MEMKIND_ThreadHash (184 ms)
> 
> Ping:
> > Is that fail reproducible for you?  I have a possible fix, but have no way
> > of verifying it -- the package builds successfully on all machines I have
> > access to, and did build fine on buildds (no major changes to toolchain
> > since then).
> 
> The underlying code uses an assumption on the internal working for glibc,
> that might possibly be invalid in some cases.  Even if it happens to be
> wrong, correctness is not violated, there's just a performance loss.
> 
> The test that fails could thus be removed -- however, I'd like to know how
> it did fail in the first place.  No matter how I tried, I did not manage to
> reproduce the failure.
> 
> There are also multiple ways to improve this hash (an explicit mapping, a
> "random" hash, etc) but as this code is used in large performance-critical
> parts, I'd prefer to first understand.

Sorry for the late reply.

This machine has SMT with 10 threads per core (so a total of 160 "cpus"
in /proc/cpuinfo), and this proved to cause some issues.

I tried again building 1.10.1-1, and:
- the build succeeded with SMT off
- the build failed again with SMT on

Lucas

Bug#974821: forwarded bug upstream

[Silvério Santos]

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

Bug#963711: Found in 87 line

[Daniel Serpell]

Hi!

On Wed, 23 Dec 2020 10:15:16 +0100 Michel Le Bihan  wrote:
> Hello,
>
> Could you please confirm that this works for you in a new profile?
>

Installed the packages yesterday, been about 12 hours without a crash!

So, I would say it resolves the issue.

Thanks,
Daniel.

Bug#973154: apertium-kaz-tat: FTBFS: hfst-concatenate: .deps/any-symbol.hfst is not a valid transducer file

[Graham Inggs]

HI Nilesh

On Thu, 24 Dec 2020 at 10:48, Nilesh  wrote:
>
> I can't seem to reproduce this, can you initiate a rebuild for this?
>
> I suspect if new apertium upload fixed this somehow. Attaching the log in any 
> case.

Reproducible builds [1] shows apertium-kaz-tat is currently building
successfully, so this bug can be closed, but apertium-kaz-tat needs a
source-only upload anyway:

"Not built on buildd: arch all binaries uploaded by kartik, a new
source-only upload is needed to allow migration"

Regards
Graham


[1] 
https://tests.reproducible-builds.org/debian/history/amd64/apertium-kaz-tat.html

Bug#978008: libkwaylandserver5: undefined symbol: _ZN14KWaylandServer17XdgShellInterface14surfaceCreatedEPNS_24XdgShellSurfaceInterfaceE"

[Vincas Dargis]

I've reproduced same issue on VM.

It seems that I have go perform `full-upgrade` that removes `user-manager`. 
After that KDE desktop works.

If I try to install `user-manager` again, I get suggestion to remove whole 
kde-plasma-dekstop & friends...

Bug#978015: Add "image/webp webp" to /etc/mime.types ?

[Trent W. Buck]

Package: mime-support
Version: 3.62
Severity: normal
Tags: upstream

I attached foo.webp to an email and mutt used application/octet-stream.
I think to fix this mime.types needs to contain "image/webp webp".

https://en.wikipedia.org/wiki/WebP

Debian already supports this file format, and
file(1) uses the the correct media type (née MIME type):

$ gm convert rose: webp:- | file --mime -
/dev/stdin: image/webp; charset=binary

I think the RIGHT fix is to trick Google into filing IANA paperwork so it 
appears here:

https://www.iana.org/assignments/media-types/image.csv

I think if that is done, Debian will get it automatically.
Is that right?

Can mime-support add it right now (before IANA)?

I understand that in the meantime, I can patch it
per-user in ~/.mime.types or
per-host in /etc/mime.types (but not /etc/mime.types.d/foo.conf).


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

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

mime-support depends on no packages.

Versions of packages mime-support recommends:
ii  bzip2 1.0.6-9.2~deb10u1
ii  file  1:5.35-4+deb10u1
ii  xz-utils  5.2.4-1

mime-support suggests no packages.

-- debconf-show failed

Bug#977960: still not fixed in 3.5.1+dfsg+~3.5.5-2

[Matthias Klose]

Control: reopen -1
Control: found -1 3.5.1+dfsg+~3.5.5-2

$ ls -l /usr/share/nodejs/jquery/dist/
total 0
lrwxrwxrwx 1 root root 34 Dec 23 22:00 jquery.js ->
../../nodejs/jquery/dist/jquery.js
lrwxrwxrwx 1 root root 38 Dec 23 22:00 jquery.min.js ->
../../nodejs/jquery/dist/jquery.min.js
lrwxrwxrwx 1 root root 45 Dec 23 22:00 jquery.min.js.brotli ->
../../nodejs/jquery/dist/jquery.min.js.brotli
lrwxrwxrwx 1 root root 41 Dec 23 22:00 jquery.min.js.gz ->
../../nodejs/jquery/dist/jquery.min.js.gz
lrwxrwxrwx 1 root root 39 Dec 23 22:00 jquery.min.map ->
../../nodejs/jquery/dist/jquery.min.map
lrwxrwxrwx 1 root root 46 Dec 23 22:00 jquery.min.map.brotli ->
../../nodejs/jquery/dist/jquery.min.map.brotli
lrwxrwxrwx 1 root root 42 Dec 23 22:00 jquery.min.map.gz ->
../../nodejs/jquery/dist/jquery.min.map.gz


please could you check an upgrade path from the last versions?
snapshot.debian.org should have these packages.

You also could create such a directory with the symlinks and check that the
upgrade works.

Matthias

Bug#974827: forwarded bug upstream

[Silvério Santos]

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