Bug#959412: node-puppeteer: progress

[merkys]

Hello,

I have made some progress in packaging node-puppeteer, thus I switched
to ITP. @types/node does not seem to be a blocker. Getting dependencies
right is much more work-intensive.

Andrius

Bug#960906: RFP: shiny-server -- put Shiny web apps online

[merkys]

Package: wnpp
Severity: wishlist
Control: block -1 by 896975 958159

* Package name    : shiny-server
  Version : 1.5.6.875
  Upstream Author : RStudio, Inc
* URL : https://www.rstudio.com/products/shiny/shiny-server/
* License : AFFERO-3
  Programming Lang: JavaScript
  Description : put Shiny web apps online
 Shiny Server lets you put shiny web applications and interactive
 documents online. Take your Shiny apps and share them with your
 organization or the world.
 .
 Shiny Server lets you go beyond static charts, and lets you manipulate
 the data. Users can sort, filter, or change assumptions in real-time.
 Shiny server empower your users to customize your analysis for their
 specific needs and extract more insight from the data.

Collaborative efforts to package shiny-server are ongoing in Debian Med
Team. I have noticed there is no ITP/RFP for it, hence I am opening one.
The packaging process right now is in the dependency packaging stage.

Remark: This package is to be maintained with Debian Med Packaging Team at
   https://salsa.debian.org/science-team/shiny-server.git

Bug#934135: [Aptitude-devel] Bug#934135: aptitude: depends on libparse-debianchangelog-perl that has no upstream maintainer

[intrigeri]

Axel Beckert (2020-05-18):
> Found out what missing: Guillem's patched Makefile.am and also
> debian/control, but missed debian/aptitude-common.install, so the
> upstream build-system installed the file, but the package build system
> did not.
>
> Works now for me. Can continue on preparing a new upstream release.

Thanks a lot, Axel, for working on this! :)

Bug#539575: netsurf-linuxfb: black screen

[Gürkan Myczko]

Hi Trent

It's been a while, could you try with 3.9-1 of netsurf-fb?

Best,

Bug#804345: netsurf-gtk: HiDPI support

[Gürkan Myczko]

Hi Mark

> When run on a system with a high DPI screen NetSurf produces a window
? which appears to be rendered with pixel measurements and is therefore
> very small with tiny text.  It would be very nice if it identified
> high DPI screens and adapted to them.

I don't think that should be fixed in an application that uses gtk,
unless that used gtk supports a universal solution to the problem.

This should happen inside gtk, without having to write special code
about it in the application.

I will tag this wontfix.

Best,

Bug#867694: netsurf-fb: Completely unusable due to missing dependencies, symlinks and documentation

[Gürkan Myczko]

Dear Salvo,

> * Depend on what's necessary (the link above suggests
>  xserver-xorg-video-fbdev, fbset and implicitly fonts-dejavu-core)

Axel:
It really needs fonts-dejavu, as it also uses at least one font from
fonts-dejavue-extra
And the symlinks are not needed anymore with 3.9-1

I am currently not able to confirm/test the fb part, but if any of you
are feel free to update the bug report here.

Jonas:
I think they are, just busy more with upstream than the packaging,
I'm helping out here.

Best,

Bug#960905: tomboy: Debian package for tomboy-ng

[Martin Monperrus]

Package: tomboy
Version: 1.14.1-4+b1
Severity: normal

Dear Tomboy Maintainers,

I discover that tomboy-ng is where activity happens now:
https://github.com/tomboy-notes/tomboy-ng/

Are there any plan to have tomboy-ng as Debian package?

That would be great!

Best,

--Martin





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

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

Versions of packages tomboy depends on:
ii  gconf2  3.2.6-6
ii  libatk1.0-0 2.36.0-2
ii  libc6   2.30-8
ii  libcairo2   1.16.0-4
ii  libdbus-glib2.0-cil 0.6.0-1
ii  libdbus2.0-cil  0.8.1-2
ii  libfontconfig1  2.13.1-4
ii  libfreetype62.10.1-2
ii  libgconf2.0-cil 2.24.2-4
ii  libgdk-pixbuf2.0-0  2.40.0+dfsg-4
ii  libglib2.0-02.64.2-1
ii  libglib2.0-cil  2.12.40-3
ii  libgmime2.6-cil 2.6.23+dfsg1-4
ii  libgtk2.0-0 2.24.32-4
ii  libgtk2.0-cil   2.12.40-3
ii  libgtkspell02.0.16-1.3
ii  libice6 2:1.0.9-2
ii  libmono-addins-gui0.2-cil   1.0+git20130406.adcd75b-4
ii  libmono-addins0.2-cil   1.0+git20130406.adcd75b-4
ii  libmono-cairo4.0-cil6.8.0.105+dfsg-3
ii  libmono-corlib4.5-cil   6.8.0.105+dfsg-3
ii  libmono-posix4.0-cil6.8.0.105+dfsg-3
ii  libmono-system-core4.0-cil  6.8.0.105+dfsg-3
ii  libmono-system-xml4.0-cil   6.8.0.105+dfsg-3
ii  libmono-system4.0-cil   6.8.0.105+dfsg-3
ii  libpango-1.0-0  1.44.7-4
ii  libpangocairo-1.0-0 1.44.7-4
ii  libpangoft2-1.0-0   1.44.7-4
ii  libproxy1v5 0.4.15-13
ii  libsm6  2:1.2.3-1
ii  libx11-62:1.6.9-2+b1
ii  mono-runtime6.8.0.105+dfsg-3

tomboy recommends no packages.

Versions of packages tomboy suggests:
ii  evolution  3.36.2-1
ii  tasque 0.1.12-4.1

-- no debconf information

Bug#960904: RFS: zh-autoconvert/0.3.16-6 -- Chinese HZ/GB/BIG5/UTF-16/UTF-7/UTF-8 encodings auto-converter

[铜豌豆 Linux]

Package: sponsorship-requests
Severity: normal

Dear mentors,

I am looking for a sponsor for my package "zh-autoconvert"

* Package name : zh-autoconvert
Version : 0.3.16-6
Upstream Author : Yu Guanghui 
* URL : [fill in URL of upstream's web site]
* License : GPL-2+
* Vcs : https://salsa.debian.org/chinese-team/zh-autoconvert
Section : text

It builds those binary packages:

libhz-dev - Headers and static libraries for zh-autoconvert
libhz0 - Chinese encoding autoconvert library
zh-autoconvert - Chinese HZ/GB/BIG5/UTF-16/UTF-7/UTF-8 encodings
auto-converter

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

https://mentors.debian.net/package/zh-autoconvert

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

dget -x
https://mentors.debian.net/debian/pool/main/z/zh-autoconvert/zh-autoconvert_0.3.16-6.dsc

Changes since the last upload:

[ 肖盛文 ]
* fix lintian: spelling-error-in-patch-description
* d/control:
- Bump debhelper-compat (= 13)
- Bump Standards-Version: 4.5.0
- add Rules-Requires-Root: no
- add New Uploaders: xiao sheng wen 
* d/rules:
- delete export DEB_LDFLAGS_MAINT_APPEND = -Wl,--as-needed
- delete dh_missing --fail-missing
* d/copyright: add Upstream-Contact:
* add source/lintian-overrides
* add libhz0.symbols

Regards,

-- 
肖盛文 Faris Xiao
邮箱：atzli...@yeah.net
微信：atzlinux
ＱＱ：909868357
铜豌豆 Linux 
基于 Debian 的 Linux 中文桌面操作系统：https://www.atzlinux.com




signature.asc
Description: OpenPGP digital signature

Bug#960903: dch: --rebuild increments the Debian portion of the version instead of appending "build1"

[Paul Wise]

Package: devscripts
Version: 2.20.3
Severity: normal
File: /usr/bin/dch
User: devscri...@packages.debian.org
Usertags: dch debchange

The behaviour of the dch --rebuild option does not match what the
documentation says. It should append build1 (or increment to build2
etc) to the version number but it instead increments the Debian portion
of the version number.

$ head -n1 debian/changelog 
iotop (0.6-24-g733f3f8-1) unstable; urgency=medium
$ dch --rebuild 'Rebuild for a test'
$ head -n1 debian/changelog 
iotop (0.6-24-g733f3f8-2) UNRELEASED; urgency=medium

$ dch --help | grep rebuild
  -R, --rebuild
 Increment the Debian release number for a no-change rebuild
$ man dch | grep -B1 'no-change rebuild'
   --rebuild, -R
  Increment the Debian release number for a no-change 
  rebuild by appending a "build1" or by incrementing a
  rebuild version number.

-- 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.6.0-1-amd64 (SMP w/4 CPU cores)
Kernel taint flags: TAINT_FIRMWARE_WORKAROUND
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

Versions of packages devscripts depends on:
ii  dpkg-dev  1.19.7
ii  fakeroot  1.24-1
ii  file  1:5.38-4
ii  gnupg 2.2.20-1
ii  gnupg22.2.20-1
ii  gpgv  2.2.20-1
ii  libc6 2.30-8
ii  libfile-homedir-perl  1.004-1
ii  libfile-which-perl1.23-1
ii  libipc-run-perl   20200505.0-1
ii  libmoo-perl   2.004000-1
ii  libwww-perl   6.44-1
ii  patchutils0.3.4-2+b1
ii  perl  5.30.0-10
ii  pseudo [fakeroot] 1.9.0+git20190802+060058b-1
ii  python3   3.8.2-3
ii  sensible-utils0.0.12+nmu1
ii  wdiff 1.2.2-2+b1

Versions of packages devscripts recommends:
ii  apt 2.1.2
ii  at  3.1.23-1+b1
ii  curl7.68.0-1
ii  dctrl-tools 2.24-3+b1
ii  debian-keyring  2020.03.24
ii  dput1.0.3
ii  dupload 2.9.5
ii  equivs  2.3.0
ii  libdistro-info-perl 0.23
ii  libdpkg-perl1.19.7
ii  libencode-locale-perl   1.05-1
pn  libgit-wrapper-perl 
ii  libgitlab-api-v4-perl   0.25-1
ii  liblist-compare-perl0.53-1
ii  liblwp-protocol-https-perl  6.07-2
ii  libsoap-lite-perl   1.27-1
ii  libstring-shellquote-perl   1.04-1
ii  libtry-tiny-perl0.30-1
ii  liburi-perl 1.76-2
ii  licensecheck3.0.46-1
ii  lintian 2.74.0
ii  man-db  2.9.1-1
ii  patch   2.7.6-6
ii  python3-apt 2.1.3
ii  python3-debian  0.1.37
ii  python3-magic   2:0.4.15-4
ii  python3-requests2.23.0+dfsg-2
pn  python3-unidiff 
ii  python3-xdg 0.26-3
ii  strace  5.5-3
ii  unzip   6.0-25
ii  wget1.20.3-1+b2
ii  xz-utils5.2.4-1+b1

Versions of packages devscripts suggests:
ii  adequate  0.15.2
ii  autopkgtest   5.13.1
ii  bls-standalone0.20151231+b1
ii  bsd-mailx [mailx] 8.1.2-0.20180807cvs-1+b1
ii  build-essential   12.8
ii  check-all-the-things  2017.05.20+nmu1
pn  cvs-buildpackage  
ii  debhelper 13
pn  devscripts-el 
ii  diffoscope144
ii  disorderfs0.5.9-2
ii  dose-extra5.0.1-14+b2
ii  duck  0.13
ii  faketime  0.9.7-3
pn  gnuplot   
ii  how-can-i-help16
ii  libauthen-sasl-perl   2.1600-1
pn  libdbd-pg-perl
ii  libfile-desktopentry-perl 0.22-1
pn  libnet-smtps-perl 
ii  libterm-size-perl 0.209-1+b2
ii  libtimedate-perl  2.3200-1
ii  libyaml-syck-perl 1.32-2
ii  mozilla-devscripts0.54
ii  mutt  1.13.2-1
ii  openssh-client [ssh-client]   1:8.2p1-4
ii  

Bug#960902: mark python3-cloudpickle Multi-Arch: foreign

[Helmut Grohne]

Package: python3-cloudpickle
Version: 1.3.0-1
Tags: patch
User: debian-cr...@lists.debian.org
Usertags: cross-satisfiability
Control: affects -1 + src:birdfont src: src:guiqwt src:libxmlbird src:skimage

The affected packages cannot satisfy their cross Build-Depends, because
they transitively Build-Depends on python3-cloudpickle. In general,
Architecture: all packages can never satisfy cross Build-Depends unless
marked Multi-Arch: foreign or annotated :native. In the case of
python3-cloudpickle, Multi-Arch: foreign is reasonable, because it is a
pure Python module without architecture-dependent dependencies. Please
consider applying the attached patch.

Helmut
diff --minimal -Nru cloudpickle-1.3.0/debian/changelog 
cloudpickle-1.3.0/debian/changelog
--- cloudpickle-1.3.0/debian/changelog  2020-02-24 23:14:11.0 +0100
+++ cloudpickle-1.3.0/debian/changelog  2020-05-18 06:13:33.0 +0200
@@ -1,3 +1,10 @@
+cloudpickle (1.3.0-1.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Mark python3-cloudpickle Multi-Arch: foreign. (Closes: #-1)
+
+ -- Helmut Grohne   Mon, 18 May 2020 06:13:33 +0200
+
 cloudpickle (1.3.0-1) unstable; urgency=medium
 
   [ Emmanuel Arias ]
diff --minimal -Nru cloudpickle-1.3.0/debian/control 
cloudpickle-1.3.0/debian/control
--- cloudpickle-1.3.0/debian/control2020-02-24 23:14:11.0 +0100
+++ cloudpickle-1.3.0/debian/control2020-05-18 06:13:32.0 +0200
@@ -19,6 +19,7 @@
 
 Package: python3-cloudpickle
 Architecture: all
+Multi-Arch: foreign
 Depends: ${misc:Depends}, ${python3:Depends}
 Description: Extended pickling support for Python 3 objects
  cloudpickle makes it possible to serialize Python constructs not supported

Bug#960897: Update android-platform-external-libunwind and build for ppc64el

[殷啟聰 | Kai-Chung Yan]

> According to the source trees at both 
> https://github.com/Unity-Technologies/android-libunwind and 
> https://android.googlesource.com/platform/external/libunwind/, ppc64[le] 
> systems are supported.  

I doubt it. Android never officially supported architectures other than x86, 
ARM or MIPS. And these days MIPS support is being removed. The source tree for 
PowerPC is probably from the original `libunwind` and never touched by Google.

Even if it builds successfully in PowerPC, I'm quite sure it was never tested.



signature.asc
Description: OpenPGP digital signature

Bug#867701: BUSINESS CONTRACT

[Alfresa Holdings Corporation]

--
Hello,
 Top of the day to you, Alfresa Holdings Corporation Located at 1-1-3 Otemachi, 
Chiyoda-ku, Tokyo 100-0004, Japan.  wish to contract your services for a period 
of 12 months as an executive representative in your Region. Working 1-3 hours 
per week. Please advise if you are open to new opportunities.
Regards,
Koichi Shimada,
Director Of Representative,
Alfresa Holdings Corporation.

Bug#960901: webpack: Resolver falsely detects phantom ‘buffer’ import in ‘clone’ library

[Ben Finney]

Package: webpack
Version: 4.43.0-1
Severity: normal

When I create a minimal project that imports the ‘clone’ library,
Webpack reports that it cannot resolve an import of ‘buffer’:

=
ERROR in /usr/share/nodejs/clone/clone.js
Module not found: Error: Can't resolve 
'./../../../../tmp/app-using-clone.AIFQnn/buffer' in '/usr/share/nodejs/clone'
 @ /usr/share/nodejs/clone/clone.js 1:0-58
 @ ./source/main.js
=

There is no attempt in that library to import ‘buffer’. The path in
the error message should never be used and is not present in the
‘clone’ library.

The ‘clone’ library is the ‘/usr/share/nodejs/clone/clone.js’
installed from Debian.

Webpack is not reporting correctly where it is finding this import. So
it is not clear, from that error message, what is causing Webpack to
detect a ‘buffer’ name that it then cannot resolve.


Here is a demonstration of how I invoked the above error:

=
$ dpkg-query --list node-clone | grep '^i'
ii  node-clone 2.1.2-2  all  deep cloning of objects and arrays

$ cd $(mktemp --tmpdir --directory 'app-using-clone.XX')

$ mkdir source/
$ cat > source/main.js
"use strict";
import clone from 'clone';

$ cat > webpack-config.js
"use strict";

const path = require('path');

const rootDir = path.resolve(__dirname);
const sourceDir = path.resolve(rootDir, 'source');
const buildDir = path.resolve(rootDir, 'build');

module.exports = {
mode: 'development',
entry: {
app: path.resolve(sourceDir, 'main.js'),
},
output: {
path: buildDir,
filename: 'app.js',
},
resolve: {
modules: [
sourceDir,
'/usr/share/javascript',
'/usr/share/nodejs',
],
},
};

$ webpack --config webpack-config.js
Hash: eceaa9ff3519c5b14efb
Version: webpack 4.43.0
Time: 111ms
Built at: 18/05/2020 1:09:24 pm
 Asset  Size  Chunks Chunk Names
app.js  12.1 KiB app  [emitted]  app
Entrypoint app = app.js
[../../usr/share/nodejs/clone/clone.js]
/usr/share/nodejs/clone/clone.js 7.12 KiB {app} [built]
[./source/main.js] 42 bytes {app} [built]

ERROR in /usr/share/nodejs/clone/clone.js
Module not found: Error: Can't resolve
'./../../../../tmp/app-using-clone.AIFQnn/buffer' in
'/usr/share/nodejs/clone'
 @ /usr/share/nodejs/clone/clone.js 1:0-58
 @ ./source/main.js

$
=


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

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

Versions of packages webpack depends on:
ii  node-ajv   6.10.2-1
ii  node-ajv-keywords  3.4.1-1
ii  node-anymatch  3.1.1+~2.1.1-1
ii  node-debbundle-acorn [node-acorn]  6.2.1+ds+~cs11.24.3-3
ii  node-enhanced-resolve  4.1.0-4
ii  node-esrecurse 4.2.1-1
ii  node-estraverse4.2.0-1
ii  node-findup-sync   4.0.0-3
ii  node-interpret 1.0.1-1
ii  node-json-parse-better-errors  1.0.2-2
ii  node-libs-browser  2.2.1-3
ii  node-loader-runner 2.3.0-2
ii  node-loader-utils  1.2.3-1
ii  node-memory-fs 0.4.1-2
ii  node-micromatch4.0.2+repack-3
ii  node-mkdirp0.5.1-2
ii  node-neo-async 2.6.1-3
ii  node-resolve-cwd   2.0.0-2
ii  node-schema-utils  1.0.0-2
ii  node-supports-color6.1.0-2
ii  node-tapable   1.0.0-4
ii  node-uglifyjs-webpack-plugin   1.3.0-6
ii  node-watchpack 1.6.0-2
ii  node-webassemblyjs 1.9.0+dfsg-4
ii  node-webpack-sources   1.1.0-2
ii  node-yargs 15.3.0-1
ii  nodejs 10.20.1~dfsg-1

webpack recommends no packages.

webpack suggests no packages.

-- no debconf information

-- 
 \“Politics is not the art of the possible. It consists in |
  `\   choosing between the disastrous and the unpalatable.” —John |
_o__)Kenneth Galbraith, 1962-03-02 |
Ben Finney 

signature.asc
Description: PGP signature

Bug#960739: libc-bin: getaddrinfo() fails with EAI_AGAIN when the DNS query returns a large number of A and AAAA records.

[Mike Przybylski]

Hi, Aurelien,

Well spotted.  This is a Debian 11, (formerly 10), guest in VirtualBox on a Mac 
host running Catalina.  Let me see if I can reproduce this on a native Debian 
box.  I will update with my results one way or another.

Kindest regards,
Mike Przybylski

> On May 16, 2020, at 3:45 PM, Aurelien Jarno  wrote:
> 
> I
> noticed that the IP of your host is 10.0.2.15. Could it be a QEMU or
> Virtualbox VM running with the user mode network stack?

Bug#960888: logwatch: version 7.5.0-1 is installing 7.4.3

[youtous]

Package: logwatch
Version: 7.5.0-1
Severity: normal

Dear Maintainer,

Logwatch 7.5.0-1 (current stable [buster]) is installing logwatch.pl
from 7.4.3.

7.4.3 is not supporting journalctl, consequently configurations reliying
on this feature are failing silently.

Same with 7.5.0-2 branch.

https://salsa.debian.org/debian/logwatch/-/blob/debian/7.5.0-2/scripts/logwatch.pl
https://salsa.debian.org/debian/logwatch/-/blob/debian/7.5.0-1/scripts/logwatch.pl

Thank you!
youtous

Bug#799323: local-apt-repository: Uninstallable without systemd despite that seems supported according to the package description

[Ángel]

The previous testing was misleading.

First of all, /run is a temporary folder:
> 9.1.4. /run and /run/lock
> The directory /run is cleared at boot, normally by being a mount point for a 
> temporary file system
 - https://www.debian.org/doc/debian-policy/ch-opersys.html#run-and-run-lock


we would only have  /run/systemd/system  if we booted with systemd.


However, if we were actively using systemd and tried to remove the
systemd package we would hit this code in prerm:

> $ cat /var/lib/dpkg/info/systemd.prerm
> #! /bin/sh
> 
> set -e
> 
> #
> # Prevent systemd from being removed if it's the active init.  That
> # will not work.
> #
> 
> if [ "$1" = "remove" ] && [ -d /run/systemd/system ]; then
> echo "systemd is the active init system, please switch to another before 
> removing systemd."
> exit 1
> fi
>(...)

Thus the check of /run/systemd/system used by dh_systemd_start is
sufficient to ensure the init system to be systemd, in which case there
will be a systemctl.

A system with /run/systemd/system but no systemctl should probably be
considered broken. Specially given that the check
for /run/systemd/system existence appears in multiple places and
packages.


Moving systemd dependency to Recommends should be perfectly safe.

Bug#397601: posh: "type" builtin missing

[Clint Adams]

On Sat, May 16, 2020 at 05:47:08PM +0200, Leah Neukirchen wrote:
> Sorry to necrobump this bug, but as of POSIX 2008, "command -v" is required.

Thanks for the tip.

Bug#954907: python3-dateparser: Warning with autopkgtest when python3.8 is default

[Emmanuel Arias]

Hi,

The warning is raised here [0]. The date_formats should be a list, and in
this
test is parametrized a string. If a list is set on the date_formats the
warning
does not emitted.

I created this issue on upstream [1]. What is your opinion? Make an patch
or we
wait for an upstream response?

[0]
https://salsa.debian.org/python-team/modules/dateparser/-/blob/master/tests/test_date.py#L302
[1] https://github.com/scrapinghub/dateparser/issues/688


Cheers,
Arias Emmanuel
@eamanu
yaerobi.com

Bug#958840: kmer: autopkgtest regression: No module named 'localAlignerInterface'

[Antoni Villalonga]

Hi,

For some reason I din't included all my previous work on my merge request.

I've recovered most of it from a binary package I've found on my machine. And
after lot of hours I've found the python module naming issue (see d/rules
changes).

All changes are now included on:
 https://salsa.debian.org/med-team/kmer/-/merge_requests/4

Sorry for the long delay and the childish mistake.

Best regrads,

PS: d/changelog is unmodified in my last MR. Probably should include a
reference to close this bug.

On Sat, May 16, 2020 at 07:37:54AM +0200, Andreas Tille wrote:
> Hi Antoni,
> 
> since you once dived into this which was interrupted when Salsa was
> offline:  Would you be able to finish this?
> 
> That would be really helpful.
> 
> Kind regards
> 
>   Andreas.
> 
> On Tue, Apr 28, 2020 at 08:43:55PM +0200, Andreas Tille wrote:
> > On Tue, Apr 28, 2020 at 04:43:30PM +, Antoni Villalonga wrote:
> > > 
> > > I think I've faced that problem and fixed.
> > > Fix should be included into '2to3.patch'
> > > 
> > > I think the relevant part is:
> > > 
> > > --- a/atac-driver/chainer/localalign/localAlignerInterfacemodule.C
> > > +++ b/atac-driver/chainer/localalign/localAlignerInterfacemodule.C
> > > @@ -227,8 +227,17 @@
> > >  };
> > >  
> > >  
> > > +static struct PyModuleDef cModMethods =
> > > +{
> > > +PyModuleDef_HEAD_INIT,
> > > +"localAlignerInterface",  /* name of module */
> > > +"",  /* module documentation, may be NULL */
> > > +-1,  /* size of per-interpreter state of the module, or -1 
> > > if the module keeps state in global variables. */
> > > +registration_table
> > > +};
> > > +
> > >  extern "C"
> > > -void initlocalAlignerInterface() {
> > > -  Py_InitModule("localAlignerInterface", registration_table);
> > > +void PyInit_localAlignerInterface() {
> > > +  PyModule_Create();
> > >  }
> > 
> > Thanks.  Looks promising.
> >  
> > > Sorry I can't access salsa due to a maintenance, also can't test 
> > > autopkgtest
> > > for testing for the same reason.
> > 
> > Salsa and other hosts seem to be back now.
> >  
> > > It worked fine for sid some days ago.
> > 
> > Kind regards and thanks a lot for your contribution
> > 
> >   Andreas. 
> > 
> > -- 
> > http://fam-tille.de
> > 
> > ___
> > Debian-med-packaging mailing list
> > debian-med-packag...@alioth-lists.debian.net
> > https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/debian-med-packaging
> 
> -- 
> http://fam-tille.de

-- 
Antoni Villalonga
https://friki.cat/

Bug#960900: black screen after s2ram while 3D graphics (amdgpu - workaround: no_console_suspend)

[kolafl...@kolahilft.de]

Package: linux-image-amd64
Version: 5.6.7-1

Hi,
I'm running KDE which uses 3d acceleration by default.
If I activate standby (s2ram) via the KDE menu, the screen stays black
after waking up from standby.

dmesg looks like this is a bug in amdgpu / drm.



Workaround:
Disable 3d (ALT + SHIFT + F12) or boot with
kernel parameter "no_console_suspend".

Switching "no_console_suspend" via
echo Y > /sys/module/printk/parameters/console_suspend
also works.

It's quite interesting that this helps, because "no_console_suspend"
doesn't look like a switch to workaround bugs.

https://www.kernel.org/doc/html/v5.6/admin-guide/kernel-parameters.html
no_console_suspend
  [HW] Never suspend the console
  Disable suspending of consoles during suspend and
  hibernate operations.  Once disabled, debugging
  messages can reach various consoles while the rest
  of the system is being put to sleep (ie, while
  debugging driver suspend/resume hooks).  This may
  not work reliably with all consoles, but is known
  to work with serial and VGA consoles.
  To facilitate more flexible debugging, we also add
  console_suspend, a printk module parameter to control
  it. Users could use console_suspend (usually
  /sys/module/printk/parameters/console_suspend) to
  turn on/off it dynamically.



Reproduction:
The bug may only happen on the first standby after boot.
So if the first standby was successful (e.g. because 3d was disabled)
successive standby's may work fine.

Reproduced with a live cd and an installed system (bullseye-20200511):
  debian-live-testing-amd64-kde+nonfree.iso

Computer: HP EliteBook 735 G6
CPU + GPU: Ryzen 7 3700U (Vega 10)
BIOS version: R74 Ver. 01.05.00 04/15/2020
Boot mode: EFI



It's a little of a Heisenbug.

After wakeup dmesg is immediately spammed with messages and I can't get
up to the first error anymore.
And if I run "dmesg -w > logfile" while s2ram, I won't be able to
connect via ssh after wakeup and "logfile" will stop at standby.
(even Alt+SysRq+B won't help)

But issuing "sleep 2; dmesg -w > logfile" got me a useful result, which
I attached to this email.



Where I found the workarounds:
https://bbs.archlinux.org/viewtopic.php?pid=1882244#p1882244
https://github.com/Pergravis?tab=projects
Note:
I didn't tried ArchLinux. But I couldn't reproduce with
  openSUSE-Tumbleweed-KDE-Live-x86_64-Snapshot20200511-Media.iso
So I'm not sure if it's maybe an upstream bug.

Maybe related:
https://bugs.freedesktop.org/show_bug.cgi?id=111244
https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-amdgpu/+bug/1842954




Regards,
kolAflash
[0.00] Linux version 5.6.0-1-amd64 (debian-ker...@lists.debian.org) (gcc version 9.3.0 (Debian 9.3.0-11)) #1 SMP Debian 5.6.7-1 (2020-04-29)
[0.00] Command line: BOOT_IMAGE=/vmlinuz-5.6.0-1-amd64 root=UUID=a1a4ba2d-3695-4569-9fba-784ab5a194e3 ro quiet
[0.00] x86/fpu: Supporting XSAVE feature 0x001: 'x87 floating point registers'
[0.00] x86/fpu: Supporting XSAVE feature 0x002: 'SSE registers'
[0.00] x86/fpu: Supporting XSAVE feature 0x004: 'AVX registers'
[0.00] x86/fpu: xstate_offset[2]:  576, xstate_sizes[2]:  256
[0.00] x86/fpu: Enabled xstate features 0x7, context size is 832 bytes, using 'compacted' format.
[0.00] BIOS-provided physical RAM map:
[0.00] BIOS-e820: [mem 0x-0x0008efff] usable
[0.00] BIOS-e820: [mem 0x0008f000-0x0008] reserved
[0.00] BIOS-e820: [mem 0x0009-0x0009] usable
[0.00] BIOS-e820: [mem 0x0010-0x09ef] usable
[0.00] BIOS-e820: [mem 0x09f0-0x09f0afff] ACPI NVS
[0.00] BIOS-e820: [mem 0x09f0b000-0x381cefff] usable
[0.00] BIOS-e820: [mem 0x381cf000-0x387cefff] type 20
[0.00] BIOS-e820: [mem 0x387cf000-0x38fcefff] reserved
[0.00] BIOS-e820: [mem 0x38fcf000-0x396cefff] ACPI NVS
[0.00] BIOS-e820: [mem 0x396cf000-0x3974efff] ACPI data
[0.00] BIOS-e820: [mem 0x3974f000-0x5dff] usable
[0.00] BIOS-e820: [mem 0xf800-0xfbff] reserved
[0.00] BIOS-e820: [mem 0xfd10-0xfd1f] reserved
[0.00] BIOS-e820: [mem 0xfec0-0xfec00fff] reserved
[0.00] BIOS-e820: [mem 0xfec1-0xfec10fff] reserved
[0.00] BIOS-e820: [mem 0xfed8-0xfed80fff] reserved
[0.00] BIOS-e820: [mem 0xfedf1000-0xfedf1fff] reserved
[0.00] BIOS-e820: [mem 0xfee0-0xfee00fff] reserved
[0.00] BIOS-e820: [mem 0xff00-0x] reserved
[0.00] BIOS-e820: [mem 0x0001-0x00041f33] usable
[0.00] NX (Execute Disable) protection: active
[0.00] efi: EFI v2.60 by HP
[0.00] efi:  

Bug#960899: paramiko: autopkgtests failures

[Gianfranco Costamagna]

Source: paramiko
Version: 2.7.1-1
Severity: serious

Hello, looks like the latest paramiko version is now failing its autopkgtests.

Not sure if
a) "invoke" should be moved from recommends to depends
b) the autopkgtest needs to install recommends too
c) something else

Processing triggers for libc-bin (2.30-8) ...
(Reading database ... 13936 files and directories currently installed.)
Removing autopkgtest-satdep (0) ...
autopkgtest [19:10:54]: test upstream: [---
= test session starts ==
platform linux -- Python 3.8.3, pytest-4.6.9, py-1.8.1, pluggy-0.13.0 -- 
/usr/bin/python3
cachedir: .pytest_cache
rootdir: /tmp/autopkgtest-lxc.5uagjxdu/downtmp/build.uH0/src, inifile: setup.cfg
collecting ... collected 257 items / 1 errors / 256 selected

 ERRORS 
 ERROR collecting tests/test_config.py _
ImportError while importing test module 
'/tmp/autopkgtest-lxc.5uagjxdu/downtmp/build.uH0/src/tests/test_config.py'.
Hint: make sure your test modules/packages have valid Python names.
Traceback:
tests/test_config.py:9: in 
from invoke import Result
E   ModuleNotFoundError: No module named 'invoke'
!!! Interrupted: 1 errors during collection 
=== 1 error in 0.59 seconds 
autopkgtest [19:10:55]: test upstream: ---]
autopkgtest [19:10:55]: test upstream:  - - - - - - - - - - results - - - - - - 
- - - -
upstream FAIL non-zero exit status 2
autopkgtest [19:10:55]:  summary

cheers,

Gianfranco

Bug#945172: still a problem

[kolafl...@kolahilft.de]

I'm still having the same problem in the current Debian testing.

Reproduced with a live cd and an installed system (bullseye-20200511):
  debian-live-testing-amd64-kde+nonfree.iso
Package:
  firmware-realtek-20190717-2


It wasn't fun to find out what's wrong. So please fix this :-)

Looks like kernel.org has that file in both places. Interestingly with
two different sizes...

https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git/log/rtw88/rtw8822b_fw.bin

https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git/log/rtlwifi/rtl8822befw.bin


dlf29's workaround works for me too (also with a symlink instead of a
hardlink).
But I just replaced it with the rtw88 file from kernel.org which works
fine too.



Thanks,
kolAflash



signature.asc
Description: OpenPGP digital signature

Bug#960898: libtool: suggestions for the Debian packaging

[Nicolas Boulenguez]

Source: libtool
Version: 2.4.6-14
Severity: minor
Tags: patch

Hello.

The attached archive contains more or less intrusive suggestions for
the Debian packaging of libtool. test_build.diff attempts to gather
all differences in the resulting .debs.  I hope that each difference
(or No such file or directory message) will be explained by a commit
header.

Two corner cases deserve a commentary.

Since commit 'Use dpkg-dev snippets for architecture, build flags and
package version', LDFLAGS is exported into the global environment and
probably affects more subprocesses than before.  That is why LTCFLAGS
in /usr/bin/libtool now contains -Wall. This seems correct, but if
not, it should be sufficient to remove 'DPKG_EXPORT_BUILDFLAGS:=1' and
add explicit assignments before './configure' or explicit exports
after ovreride_dh_auto_configure:.

In /usr/bin/libtool, the BINCC and BINCXX parts are swapped. This is
because commit 'Merge patching in an editor script, empty
dependency_libs in installed .la' requires some work.

Please review these changes.  These are local Git commits, so it would
be easy to translate them into a merge request if you are more
comfortable this way.

Thanks.


libtool-deb-suggestions.tar.gz
Description: application/gzip
diff -urN old/libltdl-dev/control new/libltdl-dev/control
--- old/libltdl-dev/control	2020-05-17 22:38:12.0 +
+++ new/libltdl-dev/control	2020-03-02 09:35:42.0 +
@@ -7,14 +7,11 @@
 Depends: libltdl7 (= 2.4.6-14), automake-1.16
 Recommends: libtool
 Suggests: libtool-doc
-Conflicts: libltdl3-dev, libltdl7-dev, libtool (<< 1.5.20), libtool1.4
-Replaces: libltdl3-dev, libltdl7-dev, libtool (<< 1.5.20)
-Provides: libltdl3-dev, libltdl7-dev
 Section: libdevel
 Priority: optional
 Multi-Arch: same
 Homepage: https://www.gnu.org/software/libtool/
-Description: System independent dlopen wrapper for GNU libtool
+Description: System independent dlopen wrapper for GNU libtool (headers)
  This package contains the header files and static libraries for the
  libltdl package.
  .
diff -urN old/libltdl-dev/md5sums new/libltdl-dev/md5sums
--- old/libltdl-dev/md5sums	2020-05-17 22:38:12.0 +
+++ new/libltdl-dev/md5sums	2020-03-02 09:35:42.0 +
@@ -3,7 +3,7 @@
 cc3d6ec52919a1534dd5b903f14157a3  usr/include/libltdl/lt_system.h
 ede699089a4182cdc3461044e1c2f2f5  usr/include/ltdl.h
 3ec479f4152e784279f4c4537d47fa3c  usr/lib/x86_64-linux-gnu/libltdl.a
-3357b543d9149c35f2d124cf54594a6d  usr/lib/x86_64-linux-gnu/libltdl.la
+c77b57615b6467ead6d0048f923fdac1  usr/lib/x86_64-linux-gnu/libltdl.la
 bf4928f1e020e2316c088721b556faa6  usr/share/aclocal/ltdl.m4
 4fbd65380cdd255951079008b364516c  usr/share/libtool/COPYING.LIB
 b82076e21327d56bec6f2976b6985fcc  usr/share/libtool/Makefile.am
@@ -40,4 +40,4 @@
 ede699089a4182cdc3461044e1c2f2f5  usr/share/libtool/ltdl.h
 9981730f31c360029db3a3a024034bdc  usr/share/libtool/ltdl.mk
 91b8a2dd795467ed9886b9d7a70260f0  usr/share/libtool/slist.c
-367e4cf100464e21a3f4203781c6ca52  usr/share/lintian/overrides/libltdl-dev
+eb31f4af706bc0b615f2a97dff0c73ea  usr/share/lintian/overrides/libltdl-dev
diff -urN old/libltdl-dev/usr/lib/x86_64-linux-gnu/libltdl.la new/libltdl-dev/usr/lib/x86_64-linux-gnu/libltdl.la
--- old/libltdl-dev/usr/lib/x86_64-linux-gnu/libltdl.la	2020-05-17 22:38:06.0 +
+++ new/libltdl-dev/usr/lib/x86_64-linux-gnu/libltdl.la	2020-03-02 09:35:42.0 +
@@ -17,7 +17,7 @@
 inherited_linker_flags=''
 
 # Libraries that this one depends upon.
-dependency_libs=' -ldl'
+dependency_libs=''
 
 # Names of additional weak libraries provided by this library
 weak_library_names=''
diff: old/libltdl-dev/usr/lib/x86_64-linux-gnu/libltdl.so: No such file or directory
diff: new/libltdl-dev/usr/lib/x86_64-linux-gnu/libltdl.so: No such file or directory
diff: old/libltdl-dev/usr/share/doc/libltdl-dev: No such file or directory
diff: new/libltdl-dev/usr/share/doc/libltdl-dev: No such file or directory
diff -urN old/libltdl-dev/usr/share/lintian/overrides/libltdl-dev new/libltdl-dev/usr/share/lintian/overrides/libltdl-dev
--- old/libltdl-dev/usr/share/lintian/overrides/libltdl-dev	2020-03-02 09:35:42.0 +
+++ new/libltdl-dev/usr/share/lintian/overrides/libltdl-dev	2020-03-02 09:35:42.0 +
@@ -1,2 +1,5 @@
 # the whole libltdl source is included, including the COPYING.LIB
 libltdl-dev binary: extra-license-file
+
+# the whole libltdl source is included, including README
+package-contains-documentation-outside-usr-share-doc usr/share/libtool/README
diff -urN old/libltdl7/control new/libltdl7/control
--- old/libltdl7/control	2020-05-17 22:38:12.0 +
+++ new/libltdl7/control	2020-03-02 09:35:42.0 +
@@ -3,7 +3,7 @@
 Version: 2.4.6-14
 Architecture: amd64
 Maintainer: Alastair McKinstry 
-Installed-Size: 418
+Installed-Size: 422
 Depends: libc6 (>= 2.14)
 Section: libs
 Priority: optional
diff -urN old/libltdl7/md5sums new/libltdl7/md5sums
--- old/libltdl7/md5sums	

Bug#960897: Update android-platform-external-libunwind and build for ppc64el

[Timothy Pearson]

Package: android-platform-external-libunwind

According to the source trees at both 
https://github.com/Unity-Technologies/android-libunwind and 
https://android.googlesource.com/platform/external/libunwind/, ppc64[le] 
systems are supported.  However, the version in Debian, even Sid, explicitly 
removes and disables support for ppc66el.

Please update to the current version and re-enable ppc64el builds.  There are 
several Android host-side tools, including adb, that are blocked partly by the 
lack of a build for this library on ppc64el.

Bug#934135: [Aptitude-devel] Bug#934135: aptitude: depends on libparse-debianchangelog-perl that has no upstream maintainer

[Axel Beckert]

Control: tag -1 + pending

Hi again,

Axel Beckert wrote:
> Problem: It doesn't work for me, no more highlighting of new changelog
> entries — which I is why I haven't pushed my changes yet.
[...]
> You need to test it on upgradable packages. (And check how
> it looks without the patch first: All entries between the currently
> installed version and the new version should be bold.

Found out what missing: Guillem's patched Makefile.am and also
debian/control, but missed debian/aptitude-common.install, so the
upstream build-system installed the file, but the package build system
did not.

Works now for me. Can continue on preparing a new upstream release.

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

Bug#960896: ITP: rt4-extension-assetautoname -- AssetAutoName extension (Request Tracker)

[Andrew Ruthven]

Package: wnpp
Severity: wishlist
Owner: Andrew Ruthven 

* Package name: rt4-extension-assetautoname
  Version : 0.02
  Upstream Author : Andrew Ruthven 
* URL : https://metacpan.org/release/RT-Extension-AssetAutoName
* License : GPL-2
  Programming Lang: Perl
  Description : AssetAutoName extension (Request Tracker)

 This extension adds automatic asset name generation from other fields
 to Request Tracker.

This package will be part of the request-tracker-maintainers team.
We use it as work, and it has proven useful to other folks as well.

I found I hadn't uploaded it to CPAN, I've just uploaded it, it
hasn't been processed yet.

Bug#960895: ITP: rt-extension-elapsedbusinesstime -- ElapsedBusinessTime extension (Request Tracker)

[Andrew Ruthven]

Package: wnpp
Severity: wishlist
Owner: Andrew Ruthven 

* Package name: rt-extension-elapsedbusinesstime
  Version : 0.03
  Upstream Author : Andrew Ruthven 
* URL : 
https://metacpan.org/release/RT-Extension-ElapsedBusinessTime
* License : GPL-2
  Programming Lang: Perl
  Description : ElapsedBusinessTime extension (Request Tracker)

 This extension adds a fields for elapsed business time (general, and forced
 into hours or minutes) in reports for tickets within Request Tracker.

This package will be maintained by the request-tracker-maintainers team.
We use this package at work, and there other Request Tracker installations
using it.

Bug#960894: blender: Segmentation fault opening images

[william]

Package: blender
Version: 2.82.a+dfsg-1+b2
Severity: normal

Dear Maintainer,

To reproduce the bug, open the UV Editing tab and select any picture through
the 'open' dialogue. Blender will try to open the image and then crash with
segmentation fault.

mrwm@wksp:~$ blender
[...]
Writing: /tmp/blender.crash.txt
Segmentation fault

Full output here: https://paste.debian.net/1147334/
blender.crash.txt: https://paste.debian.net/1147336/



-- 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.5.0-1-amd64 (SMP w/24 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages blender depends on:
ii  blender-data  2.82.a+dfsg-1
ii  fonts-dejavu  2.37-1
ii  libavcodec58  7:4.2.2-1+b1
ii  libavdevice58 7:4.2.2-1+b1
ii  libavformat58 7:4.2.2-1+b1
ii  libavutil56   7:4.2.2-1+b1
ii  libboost-locale1.67.0 1.67.0-18
ii  libc6 2.30-8
ii  libfftw3-double3  3.3.8-2
ii  libfreetype6  2.10.1-2
ii  libgcc-s1 10.1.0-1
ii  libgl11.3.1-1
ii  libglew2.12.1.0-4+b1
ii  libgomp1  10.1.0-1
ii  libilmbase24  2.3.0-6
ii  libjack-jackd2-0 [libjack-0.125]  1.9.12~dfsg-2+b1
ii  libjemalloc2  5.2.1-1
ii  libjpeg62-turbo   1:1.5.2-2+b1
ii  libopenal11:1.19.1-1+b1
ii  libopencolorio1v5 1.1.1~dfsg0-6+b1
ii  libopenexr24  2.3.0-6
ii  libopenimageio2.1 2.1.14.0~dfsg0-1
ii  libopenjp2-7  2.3.1-1
ii  libopenvdb7.0 7.0.0-3
ii  libosdcpu3.4.33.4.3-3
ii  libosdgpu3.4.33.4.3-3
ii  libpcre3  2:8.39-12+b1
ii  libpng16-16   1.6.37-2
ii  libpython3.8  3.8.3-1
ii  libsdl1.2debian   1.2.15+dfsg2-5
ii  libsndfile1   1.0.28-7
ii  libspnav0 0.2.3-1+b2
ii  libstdc++610.1.0-1
ii  libswscale5   7:4.2.2-1+b1
ii  libtbb2   2020.2-2
ii  libtiff5  4.1.0+git191117-2
ii  libx11-6  2:1.6.9-2+b1
ii  libxfixes31:5.0.3-2
ii  libxi62:1.7.9-1
ii  libxml2   2.9.10+dfsg-5
ii  libxrender1   1:0.9.10-1
ii  libxxf86vm1   1:1.1.4-1+b2
ii  zlib1g1:1.2.11.dfsg-2

blender recommends no packages.

blender suggests no packages.

-- no debconf information

Bug#960893: libc++-10-dev: Can't coinstall multiple libc++-dev versions

[Witold Baryluk]

Package: libc++-10-dev
Version: 1:10.0.0-4
Severity: normal


It is not the end of the world, but it does impose some limitations:

# apt install libc++-dev
The following additional packages will be installed:
  libc++-9-dev libc++1-9 libc++abi1-9
Suggested packages:
  clang
The following packages will be REMOVED:
  libc++-10-dev libc++1-10 libc++abi-10-dev libc++abi1-10
The following NEW packages will be installed:
  libc++-9-dev libc++-dev libc++1-9 libc++abi1-9
#

The headers are already in versioned locations, and clang from what I have seen 
with clang:

$ clang++-10 -v -march=native -O3 -fcoroutines-ts -std=c++2a -stdlib=libc++ 
-lc++abi nanotest.cpp -o nanotest
clang version 10.0.0-4 
ignoring nonexistent directory "/include"
#include "..." search starts here:
#include <...> search starts here:
 /usr/lib/llvm-10/bin/../include/c++/v1
 /usr/local/include
 /usr/lib/llvm-10/lib/clang/10.0.0/include
 /usr/include/x86_64-linux-gnu
 /usr/include
...
$


$ dpkg -L libc++-10-dev:amd64 | grep include | head
/usr/lib/llvm-10/include
/usr/lib/llvm-10/include/c++
/usr/lib/llvm-10/include/c++/v1
/usr/lib/llvm-10/include/c++/v1/__bit_reference
/usr/lib/llvm-10/include/c++/v1/__bsd_locale_defaults.h
/usr/lib/llvm-10/include/c++/v1/__bsd_locale_fallbacks.h
/usr/lib/llvm-10/include/c++/v1/__config
/usr/lib/llvm-10/include/c++/v1/__cxxabi_config.h
/usr/lib/llvm-10/include/c++/v1/__debug
/usr/lib/llvm-10/include/c++/v1/__errc
...
/usr/lib/llvm-10/lib
/usr/lib/llvm-10/lib/libc++.a
/usr/lib/llvm-10/lib/libc++.so
...
$

So I would assume it it should be easily possible, and clang already
default to correct includes. I do not know if it also defaults to the
correct linker paths tho. Because packages do have libc++.so symlinks,
that can throw it off, unless user manually select what they want:


$ dpkg -L libc++-10-dev:amd64 | grep usr/lib/x86.*/libc++.*
/usr/lib/x86_64-linux-gnu/libc++.a
/usr/lib/x86_64-linux-gnu/libc++.so
$

$ ls -lh /usr/lib/x86_64-linux-gnu/libc++.*
lrwxrwxrwx 1 root root 23 Apr 10 08:27 /usr/lib/x86_64-linux-gnu/libc++.a -> 
../llvm-10/lib/libc++.a
lrwxrwxrwx 1 root root 24 Apr 10 08:27 /usr/lib/x86_64-linux-gnu/libc++.so -> 
../llvm-10/lib/libc++.so
lrwxrwxrwx 1 root root 13 Apr 10 08:27 /usr/lib/x86_64-linux-gnu/libc++.so.1 -> 
libc++.so.1.0
lrwxrwxrwx 1 root root 28 Apr 10 08:27 /usr/lib/x86_64-linux-gnu/libc++.so.1.0 
-> ../llvm-10/lib/libc++.so.1.0
$

But that seems easily fixable.




-- 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)
Foreign Architectures: i386

Kernel: Linux 5.2.0-3-amd64 (SMP w/32 CPU cores)
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.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 libc++-10-dev depends on:
ii  libc++1-10  1:10.0.0-4

libc++-10-dev recommends no packages.

libc++-10-dev suggests no packages.

-- no debconf information

Bug#960851: game-data-packager: Add support for Myst 3

[Alexandre Detiste]

Hi,

Can you try to add automatic patching of game, if needed ?
And also list the checksum of the old unpatched data if you known.
(like M3DATA/OVER101.m3o?1.00 )

https://demos.residualvm.org/patches/

files:
  myst3v122patch.exe:
download: https://demos.residualvm.org/patches/myst3v122patch.exe
unpack:
  format: innoextract
provides:
- M3Data/OVER101.m3o
- M3Data/TEXT/ENGLISH.m3t

group_members: |
  6475108   b1c65318f66230db61275f90d349fad3 myst3v122patch.exe
  3062737601cb222c9f31e35e351ec33937c3a3 M3DATA/OVER101.m3o
  5660070   0cdf446840b133b62617041881e68094 M3DATA/TEXT/ENGLISH.m3t

sha1sums: |
  1c990b4c84a037dccebe24d39bf17947745f43662a9483b8a5b0339022c43796
myst3v122patch.exe
  ff1f8d8e70d0c8335de94a7d2302f9ee8745bde8 M3DATA/OVER101.m3o
  0069dcd5b6de82a081d453f823b72eec10415b07 M3DATA/TEXT/ENGLISH.m3t

Bug#960850: game-data-packager: Add support for Myst 2: Riven

[Alexandre Detiste]

Hi,

Thanks a lot.

Can you also document the no-to-good version of files to avoid warnings
about unexpected file ?

Thanks,

https://wiki.scummvm.org/index.php/Datafiles#Riven:_The_Sequel_to_Myst

The *[a,b,g,j,o,p,r,t]_Sounds.mhk* files may be present twice on game media.
Either version can be used, but the largest files (from the *assets1*
 directory)
are recommended as they are encoded with a higher audio quality.

Le dim. 17 mai 2020 à 16:39, Frodo Looijaard  a
écrit :

> Package: game-data-packager
> Version: 63
> Severity: wishlist
> Tags: patch
>
> Dear Maintainer,
>
> please consider support for the game Riven: the sequel to Myst.
> I have attached the yaml-file that worked for me, based on the 5 CD-ROM
> version for Windows.
>
> Kind regards,
>   Frodo Looijaard
>

Bug#960632: src:plm: Please add support to build against libjson-simple-java >= 3

[Gilles Filippini]

Gilles Filippini a écrit le 17/05/2020 à 23:29 :
> Gilles Filippini a écrit le 17/05/2020 à 22:51 :
>> Hi Martin,
>>
>> Martin Quinson a écrit le 17/05/2020 à 22:31 :
>>> Hello again,
>>>
>>> when I try to launch the program with your patch applied, I get the
>>> following backtrace:
>>>
>>> Exception in thread "main" java.lang.ClassCastException: class
>>> org.json.simple.JsonArray cannot be cast to class
>>> org.json.simple.JsonObject (org.json.simple.JsonArray and
>>> org.json.simple.JsonObject are in unnamed module of loader 'app')
>>> at plm.core.model.Users.loadUsersFromFile(Unknown Source)
>>> at plm.core.model.Users.(Unknown Source)
>>> at plm.core.model.Game.(Unknown Source)
>>> at plm.core.model.Game.getInstance(Unknown Source)
>>> at plm.core.ui.ProgrammersLearningMachine.main(Unknown Source)
>>> 
>>> I will try to fix it in the near future, but your help would of course
>>> be welcome. Don't modify your patch as it is applied and burried under
>>> other changes already. Instead, please propose another patch on top of
>>> the current state in the package in
>>> https://salsa.debian.org/java-team/plm/
>>
>> I'll have a look at this.
> 
> Could you give me an example of plm.users file causing this error?

Here is a patch to apply on top of your current git repo. It fixes
plm.users read / write and sessions- welcome.summary read.

Best,

_g.
diff --git a/debian/patches/json-simple-3.patch b/debian/patches/json-simple-3.patch
index ed5c9d9..141c4a7 100644
--- a/debian/patches/json-simple-3.patch
+++ b/debian/patches/json-simple-3.patch
@@ -164,9 +164,11 @@ Index: plm-2.6+repack/src/plm/core/model/session/SessionDB.java
 ===
 --- plm-2.6+repack.orig/src/plm/core/model/session/SessionDB.java
 +++ plm-2.6+repack/src/plm/core/model/session/SessionDB.java
-@@ -4,9 +4,9 @@ import java.util.HashMap;
+@@ -3,10 +3,11 @@ package plm.core.model.session;
+ import java.util.HashMap;
  import java.util.Map;
  import java.util.Set;
++import java.math.BigDecimal;
  
 -import org.json.simple.JSONObject;
 -import org.json.simple.parser.JSONParser;
@@ -177,7 +179,7 @@ Index: plm-2.6+repack/src/plm/core/model/session/SessionDB.java
  
  import plm.core.lang.ProgrammingLanguage;
  import plm.core.model.Game;
-@@ -154,7 +154,7 @@ public class SessionDB {
+@@ -154,7 +155,7 @@ public class SessionDB {
  	
  	
  	public String lessonSummary(String lesson) {
@@ -186,7 +188,7 @@ Index: plm-2.6+repack/src/plm/core/model/session/SessionDB.java
  
  		Map possibleL = possibleExercises.get(lesson);
  		for (ProgrammingLanguage pl: possibleL.keySet()) 
-@@ -166,15 +166,14 @@ public class SessionDB {
+@@ -166,15 +167,14 @@ public class SessionDB {
  			if (passedL.get(pl)!=0)
  result.put("passed"+pl.getLang(), passedL.get(pl));
  		
@@ -206,6 +208,23 @@ Index: plm-2.6+repack/src/plm/core/model/session/SessionDB.java
  			System.out.println("Ignoring invalid lesson summary (parse error: "+e.getLocalizedMessage()+").");
  			return;
  		}
+@@ -186,12 +186,12 @@ public class SessionDB {
+ 		
+ 		for (ProgrammingLanguage pl: Game.getProgrammingLanguages()) {
+ 			if (data.containsKey("possible"+pl.getLang())) {
+-Long v = (Long) data.get("possible"+pl.getLang());
+-possibleL.put(pl, v.intValue());
++Integer v = ((BigDecimal) data.get("possible"+pl.getLang())).intValue();
++possibleL.put(pl, v);
+ 			}
+ 			if (data.containsKey("passed"+pl.getLang())) {
+-Long v = (Long) data.get("passed"+pl.getLang()); // damn, damn java casting madness
+-passedL.put(pl, v.intValue());
++Integer v = ((BigDecimal) data.get("passed"+pl.getLang())).intValue(); // damn, damn java casting madness
++passedL.put(pl, v);
+ 			}
+ 		}
+ 	}
 Index: plm-2.6+repack/src/plm/core/model/session/ZipSessionKit.java
 ===
 --- plm-2.6+repack.orig/src/plm/core/model/session/ZipSessionKit.java
@@ -430,7 +449,12 @@ Index: plm-2.6+repack/src/plm/core/model/User.java
 ===
 --- plm-2.6+repack.orig/src/plm/core/model/User.java
 +++ plm-2.6+repack/src/plm/core/model/User.java
-@@ -6,10 +6,10 @@ import java.util.LinkedHashMap;
+@@ -2,14 +2,15 @@ package plm.core.model;
+ 
+ import java.io.IOException;
+ import java.io.Writer;
++import java.io.StringWriter;
+ import java.util.LinkedHashMap;
  import java.util.Objects;
  import java.util.UUID;
  
@@ -444,7 +468,7 @@ Index: plm-2.6+repack/src/plm/core/model/User.java
  	private String username;
  	private boolean lastUsed;
  	private UUID userUUID;
-@@ -27,12 +27,16 @@ public class User implements JSONStreamA
+@@ -27,12 +28,23 @@ public class User implements JSONStreamA
  	}
  
  	@SuppressWarnings({ "unchecked", "rawtypes" })
@@ -459,7 +483,14 @@ Index: plm-2.6+repack/src/plm/core/model/User.java
 +	}
 +
 +	public String toJson() {
-+		return toString();
++		StringWriter 

Bug#960892: po4a: --srcdir ignored by [po_directory]

[Axel Beckert]

Package: po4a
Version: 0.58.1-1
Severity: important
Control: affects -1 src:aptitude
Control: block 960865 by -1

Dear Martin,

previously when building aptitude's documentation, it sufficed to
declare

  [po_directory] po4a/po

in doc/po4a/po4a.cfg and then calling from the out-of-tree build
directory in e.g. "build/doc/de/"

  /usr/bin/po4a --translate-only=de/manpage.xml --srcdir=../../../doc 
--destdir=../../doc ../../../doc/po4a/po4a.cfg

but since recently, this fails with the IMHO not very helpful error
message:

  ../../../doc/po4a/po4a.cfg:1: no PO files found in po4a/po

See https://bugs.debian.org/960865.

The following change to doc/po4a/po4a.cfg fixes this:

  -[po_directory] po4a/po
  +[po_directory] ../../../doc/po4a/po

But this hardcoding of the relative path to the directory given with
--srcdir IMHO contradicts what is written in the man page:

   --srcdir SRCDIR
   Set the base directory for all input documents specified in
   the po4a configuration file.

   If both destdir and srcdir are specified, input files are
   searched in the following directories, in order: destdir,
   srcdir and the current directory. Output files are written to
   destdir if specified, or to the current directory.

Is there a chance that it has been forgotten to also check for the
po_directory under the directory given by --srcdir?

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

Kernel: Linux 5.5.0-1-amd64 (SMP w/4 CPU cores)
Kernel taint flags: TAINT_FIRMWARE_WORKAROUND, TAINT_UNSIGNED_MODULE
Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE=C.UTF-8 
(charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)
LSM: AppArmor: enabled

Versions of packages po4a depends on:
ii  gettext0.19.8.1-10
ii  libsgmls-perl  1.03ii-36
ii  libyaml-tiny-perl  1.73-1
ii  opensp 1.5.2-13+b1
ii  perl   5.30.0-10

Versions of packages po4a recommends:
ii  liblocale-gettext-perl 1.07-4
ii  libterm-readkey-perl   2.38-1+b1
ii  libtext-wrapi18n-perl  0.06-9
ii  libunicode-linebreak-perl  0.0.20190101-1+b2

po4a suggests no packages.

-- no debconf information

Bug#960891: devscripts: dd-list -nou results in "unknown option: […]"

[Chris Lamb]

Package: devscripts
Version: 2.20.3
Severity: normal

Hi,

dd-list's --help output mentions:

-nou, --nouploaders
Only list package Maintainers, do not list Uploaders.

However, passing -nou results in:

  Unknown option: n
  Unknown option: o

Can't seem to work out what it should be unfortunately, but
--nouploaders works as expected.


Regards,

--
  ,''`.
 : :'  : Chris Lamb
 `. `'`  la...@debian.org / chris-lamb.co.uk
   `- 

Bug#960871: linux-image-amd64: iwlwifi: iwl_mvm_enable_txq NULL pointer dereference, address: 0000000000000068

[Nye Liu]

Package: src:linux
Version: 5.6.7-1
Severity: grave
Tags: upstream
Justification: renders package unusable

This OOPS renders system unusable:

May 17 06:28:33  kernel: [541237.462244] BUG: kernel NULL pointer 
dereference, address: 0068
May 17 06:28:33  kernel: [541237.462252] #PF: supervisor write access in 
kernel mode
May 17 06:28:33  kernel: [541237.462256] #PF: error_code(0x0002) - 
not-present page
May 17 06:28:33  kernel: [541237.462259] PGD 0 P4D 0 
May 17 06:28:33  kernel: [541237.462265] Oops: 0002 [#1] SMP NOPTI
May 17 06:28:33  kernel: [541237.462272] CPU: 0 PID: 3881793 Comm: 
kworker/0:1 Tainted: GW 5.6.0-1-amd64 #1 Debian 5.6.7-1
May 17 06:28:33  kernel: [541237.462275] Hardware name: To Be Filled By 
O.E.M. To Be Filled By O.E.M./H270M-ITX/ac, BIOS P2.00 03/29/2017
May 17 06:28:33  kernel: [541237.462300] Workqueue: events 
iwl_mvm_add_new_dqa_stream_wk [iwlmvm]
May 17 06:28:33  kernel: [541237.462321] RIP: 
0010:iwl_trans_pcie_txq_enable+0x5f/0x430 [iwlwifi]
May 17 06:28:33  kernel: [541237.462326] Code: 63 c6 4c 8b ac c7 c8 14 00 
00 f0 48 0f ab 87 c8 24 00 00 73 0d 80 3d 52 0c 03 00 00 0f 84 82 03 00 00 44 
89 c7 e8 31 b4 3f e7 <49> 89 45 68 48 85 db 0f 84 b6 02 00 00 0f b6 85 aa 25 00 
00 44 39
May 17 06:28:33  kernel: [541237.462330] RSP: 0018:a9b60281fd20 
EFLAGS: 00010203
May 17 06:28:33  kernel: [541237.462334] RAX: 09c4 RBX: 
 RCX: 
May 17 06:28:33  kernel: [541237.462337] RDX:  RSI: 
001f RDI: 2710
May 17 06:28:33  kernel: [541237.462340] RBP: 9acfd78d8018 R08: 
2710 R09: 0001
May 17 06:28:33  kernel: [541237.462343] R10: 0040 R11: 
 R12: 001f
May 17 06:28:33  kernel: [541237.462346] R13:  R14: 
 R15: 2710
May 17 06:28:33  kernel: [541237.462350] FS:  () 
GS:9acfdf00() knlGS:
May 17 06:28:33  kernel: [541237.462353] CS:  0010 DS:  ES:  CR0: 
80050033
May 17 06:28:33  kernel: [541237.462356] CR2: 0068 CR3: 
0001b320a003 CR4: 003606f0
May 17 06:28:33  kernel: [541237.462359] DR0:  DR1: 
 DR2: 
May 17 06:28:33  kernel: [541237.462362] DR3:  DR6: 
fffe0ff0 DR7: 0400
May 17 06:28:33  kernel: [541237.462364] Call Trace:
May 17 06:28:33  kernel: [541237.462391]  iwl_mvm_enable_txq+0x173/0x260 
[iwlmvm]
May 17 06:28:33  kernel: [541237.462410]  
iwl_mvm_add_new_dqa_stream_wk+0x1c7/0x770 [iwlmvm]
May 17 06:28:33  kernel: [541237.462420]  process_one_work+0x1b4/0x380
May 17 06:28:33  kernel: [541237.462426]  worker_thread+0x50/0x3c0
May 17 06:28:33  kernel: [541237.462433]  kthread+0xf9/0x130
May 17 06:28:33  kernel: [541237.462438]  ? process_one_work+0x380/0x380
May 17 06:28:33  kernel: [541237.462443]  ? kthread_park+0x90/0x90
May 17 06:28:33  kernel: [541237.462452]  ret_from_fork+0x1f/0x40
May 17 06:28:33  kernel: [541237.462458] Modules linked in: tcp_diag 
inet_diag veth sctp ctr ccm ipt_REJECT nf_reject_ipv4 xt_MASQUERADE 
nf_conntrack_netlink xfrm_user xfrm_algo xt_addrtype br_netfilter iptable_nat 
overlay bridge stp llc sit tunnel4 ip_tunnel ip6t_REJECT nf_reject_ipv6 xt_dscp 
xt_mark nf_log_ipv4 nf_log_common nft_limit xt_state xt_conntrack xt_LOG 
xt_limit xt_multiport nft_counter btusb intel_rapl_msr intel_rapl_common btrtl 
btbcm btintel nft_chain_nat bluetooth xt_nat nf_nat nf_conntrack nf_defrag_ipv6 
nf_defrag_ipv4 xt_tcpudp nft_compat drbg nf_tables snd_hda_codec_hdmi 
ansi_cprng ecdh_generic ecc nfnetlink usblp crc16 x86_pkg_temp_thermal 
intel_powerclamp joydev snd_hda_codec_realtek binfmt_misc snd_hda_codec_generic 
kvm_intel ledtrig_audio snd_hda_intel kvm snd_intel_dspcfg irqbypass iwlmvm 
snd_hda_codec snd_hda_core ghash_clmulni_intel mac80211 snd_hwdep snd_pcm_oss 
libarc4 snd_mixer_oss iwlwifi aesni_intel libaes crypto_simd cryptd glue_helper 
snd_pcm intel_cstate snd_timer iTCO_wdt cfg80211
May 17 06:28:33  kernel: [541237.462518]  intel_uncore snd 
iTCO_vendor_support mei_me intel_rapl_perf pcspkr watchdog soundcore rfkill sg 
mei evdev acpi_pad nct6775 hwmon_vid coretemp parport_pc ppdev lp parport 
ip_tables x_tables autofs4 uas usb_storage btrfs blake2b_generic xor 
zstd_decompress zstd_compress hid_generic usbhid hid raid6_pq libcrc32c 
crc32c_generic sd_mod i915 nvme nvme_core t10_pi crc_t10dif crc32_pclmul 
crc32c_intel ahci crct10dif_generic libahci e1000e igb drm_kms_helper i2c_i801 
dca ptp pps_core xhci_pci crct10dif_pclmul crct10dif_common cec i2c_algo_bit 
xhci_hcd libata drm usbcore scsi_mod usb_common video button
May 17 06:28:33  kernel: [541237.462569] CR2: 0068
May 17 06:28:33  kernel: [541237.462574] ---[ end trace 7f0c3e199a7a8e2c 
]---
May 17 06:28:33  kernel: [541237.462591] RIP: 
0010:iwl_trans_pcie_txq_enable+0x5f/0x430 [iwlwifi]
May 

Bug#960890: python-django: New upstream 3.x release

[Chris Lamb]

Package: python-django
Version: 2:2.2.12-1
Severity: wishlist
User: python-modules-t...@lists.alioth.debian.org
Usertags: django-3.x

Hi,

This is a bug to track the progress of uploading Django 3.x to
unstable.

There are number of breaking changes (mostly removing deprecated
features) so this cannot simply be uploaded as it will break too many
packages.

The version in experimental is currently 3.0.6-1. I have built
the 153 reverse-dependencies in unstable against this version
114 of these build pass their testsuite successfully.

However the following packages fail. My next step is to investigate and
file bugs against them if relevant. I intend to usertag them so that
they will appear here:

  
https://bugs.debian.org/cgi-bin/pkgreport.cgi?tag=django-3.x;users=python-modules-t...@lists.alioth.debian.org

I cannot blindly file these bugs as some of them might FTBFS in any
case. Worst, some of them are due to other packages — eg. src:celery-
haystack and src:hyperkitty FTBFS due to haystack. I will try and catch
most of these, but I am only human so please do reassign and mark them
as "affects".

§

  Brian May 
 django-filter

  Debian Mailman Team 
 hyperkitty

  Debian OpenStack 
 horizon
 ironic-ui
 manila-ui
 mistral-dashboard
 murano-dashboard
 octavia-dashboard
 python-django-pyscss
 sahara-dashboard
 senlin-dashboard
 trove-dashboard
 zaqar-ui

  Debian Python Modules Team 
 celery-haystack
 django-auth-ldap
 django-cas-server
 django-cors-headers
 django-dirtyfields
 django-fsm
 django-model-utils
 django-modeltranslation
 django-oauth-toolkit
 django-pipeline
 django-simple-captcha
 djangorestframework
 libthumbor
 python-django-contact-form
 python-django-csp
 python-django-extensions
 python-django-imagekit
 python-django-jsonfield
 python-django-modelcluster
 python-django-mptt
 python-django-navtag
 python-django-storages
 python-django-tagging
 sorl-thumbnail

  FreedomBox packaging team 
 plinth

  Michal Čihař 
 django-taggit

  Stephan Sürken 
 mini-buildd

§


Regards,

--
  ,''`.
 : :'  : Chris Lamb
 `. `'`  la...@debian.org / chris-lamb.co.uk
   `- 

Bug#960889: xfonts-terminus: the "l" is very ugly

[Kacper Gutowski]

Package: xfonts-terminus
Version: 4.48-2
Severity: normal

Please don't apply the ll2 patch, it's not an improvement.


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

Kernel: Linux 5.4.0-4-amd64 (SMP w/4 CPU cores)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=pl_PL.UTF-8, LC_CTYPE=pl_PL.UTF-8 (charmap=UTF-8), 
LANGUAGE=pl_PL.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)

Versions of packages xfonts-terminus depends on:
ii  xfonts-utils  1:7.7+6

xfonts-terminus recommends no packages.

Versions of packages xfonts-terminus suggests:
pn  xfonts-terminus-oblique   
ii  xserver-xephyr [xserver]  2:1.20.8-2
ii  xserver-xorg [xserver]1:7.7+20
ii  xvfb [xserver]2:1.20.8-2

-- no debconf information

Bug#912569:

[Andrea Favero]

Hello, did someone figure out a workaround for this bug?
I have the same exact problem of yours... any help would be greatly
appreciated.

Regards,
Andrea Favero

Bug#960870: linux-image-armmp: please add patch to support fancontrol on Helios4

[Rob J. Epping]

Package: linux-image-armmp
Version: 5.5.17-1~bpo10+1
Severity: wishlist

Dear Maintainer,

Please add support for Helios4 fancontrol.

According to helios4 wiki [1] this needs a patch to the kernel because
> Currently Linux gpio-mvebu driver does not allow more than 1 PWM
> under the same gpio bank. 

In the same page the required patch was linked from Armbian.
The current link is either [2] or [3]. Neither does apply cleanly
to 5.5.17 though :(

THNX && GRTNX,
RobJE

[1] 
[2] 
[3] 

-- System Information:
Debian Release: 10.4
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable')
Architecture: armhf (armv7l)

Kernel: Linux 5.5.0-0.bpo.2-armmp (SMP w/2 CPU cores)
Kernel taint flags: TAINT_UNSIGNED_MODULE
Locale: LANG=C, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE=C (charmap=UTF-8)
Shell: /bin/sh linked to /usr/bin/dash
Init: sysvinit (via /sbin/init)

Versions of packages linux-image-armmp depends on:
ii  linux-image-5.5.0-0.bpo.2-armmp  5.5.17-1~bpo10+1

linux-image-armmp recommends no packages.

linux-image-armmp suggests no packages.

-- no debconf information

Bug#960630: ant: CVE-2020-1945

[Emmanuel Bourg]

Ant 1.10.8 adds a convenience property to change the temporary
directory. It was already possible to change it in prior versions with:

   ANT_OPTS=-Djava.io.tmpdir=~/temp ant jar

Now it's possible to use:

   ant jar -Dant.tmpdir=~/temp

Or by setting the ant.tmpdir property inside the Ant build.xml file.

Since it requires an action from the user and the issue is already
avoidable I'm tempted to think a backport to stable isn't important.

Emmanuel Bourg

Bug#960632: src:plm: Please add support to build against libjson-simple-java >= 3

[Gilles Filippini]

Gilles Filippini a écrit le 17/05/2020 à 22:51 :
> Hi Martin,
> 
> Martin Quinson a écrit le 17/05/2020 à 22:31 :
>> Hello again,
>>
>> when I try to launch the program with your patch applied, I get the
>> following backtrace:
>>
>> Exception in thread "main" java.lang.ClassCastException: class
>> org.json.simple.JsonArray cannot be cast to class
>> org.json.simple.JsonObject (org.json.simple.JsonArray and
>> org.json.simple.JsonObject are in unnamed module of loader 'app')
>> at plm.core.model.Users.loadUsersFromFile(Unknown Source)
>>  at plm.core.model.Users.(Unknown Source)
>>  at plm.core.model.Game.(Unknown Source)
>>  at plm.core.model.Game.getInstance(Unknown Source)
>> at plm.core.ui.ProgrammersLearningMachine.main(Unknown Source)
>>  
>> I will try to fix it in the near future, but your help would of course
>> be welcome. Don't modify your patch as it is applied and burried under
>> other changes already. Instead, please propose another patch on top of
>> the current state in the package in
>> https://salsa.debian.org/java-team/plm/
> 
> I'll have a look at this.

Could you give me an example of plm.users file causing this error?

Thanks,

_g.



signature.asc
Description: OpenPGP digital signature

Bug#960804: buster-pu: package pdfchain/pdfchain/1:0.4.4.2-1+deb10u1

[Adam D. Barratt]

Control: tags -1 + confirmed

On Sat, 2020-05-16 at 22:36 +0200, Johann Felix Soden wrote:
> To fix a severe bug that leads to application crashes,
> I would like to upload pdfchain (debdiff attached)
> 
> The used patch is tested in testing & sid with pdfchain/1:0.4.4.2-2
> and confirmed by users to fix the bug [1]. It is part of the
> OpenSuse's pdfchain package [2].
> 

Please go ahead.

Regards,

Adam

Bug#960887: dh-golang: Use of uninitialized value $caller

[Felix Lechner]

Package: dh-golang
Severity: normal

Hi,

I recently saw the warning below while building gocryptfs 1.8.0 on
stable-backports.

Kind regards
Felix Lechner

* * *

dh_makeshlibs -a -O--buildsystem=golang
dh_shlibdeps -a -O--buildsystem=golang
dh_installdeb -O--buildsystem=golang
dh_golang -O--buildsystem=golang
Use of uninitialized value $caller in string eq at
/usr/share/perl5/Debian/Debhelper/Buildsystem/golang.pm line 567.
   dh_gencontrol -O--buildsystem=golang
   dh_md5sums -O--buildsystem=golang
   dh_builddeb -O--buildsystem=golang
dpkg-deb: building package 'gocryptfs-dbgsym' in
'../gocryptfs-dbgsym_1.8.0-1_amd64.deb'.
dpkg-deb: building package 'gocryptfs' in '../gocryptfs_1.8.0-1_amd64.deb'.
 dpkg-genbuildinfo --build=binary
 dpkg-genchanges --build=binary >../gocryptfs_1.8.0-1_amd64.changes
dpkg-genchanges: info: binary-only upload (no source code included)

Bug#960806: buster-pu: package policyd-rate-limit/1.0.0-1

[Adam D. Barratt]

Control: tags -1 + moreinfo

On Sat, 2020-05-16 at 22:39 +0200, Pierre-Elliott Bécue wrote:
> Policyd rate limit in buster is RC-buggy due to a bug described
> here[0].
> Minor release 1.0.1 fixes the issue, and, consequently, I uploaded it
> in unstable minutes ago.
> 
> I prepared a debdiff for Buster. Note that the upstream release is
> 1.0.1.1 because upstream released signing with an inappropriate GPG
> key.

+policyd-rate-limit (1.0.1.1-1+deb10u1) buster; urgency=medium

The version needs to be lower than the package in unstable, so 1.0.1.1-
1~deb10u1

-Build-Depends: debhelper (>= 11~),
+Build-Depends: debhelper-compat (= 11),

As a general note, that's not particularly great for a stable update,
even though it's effectively a no-op (because it's not part of
resolving the issues). As part of a backport I wouldn't request not
including it though.

-raise ValueError("connection closed")
+raise PolicydConnectionClosed()
[...]
-except Exception as error:
+except PolicydConnectionClosed:
+if config.debug:
+sys.stderr.write("Connection closed\n")

Does anything rely on the specific strings being output here?

Regards,

Adam

Bug#960836: buster-pu: package gnutls28/3.6.7-4+deb10u4

[Adam D. Barratt]

Control: tags -1 + moreinfo

On Sun, 2020-05-17 at 14:23 +0200, Andreas Metzler wrote:
> I would like to update gnutls to fix #95664 aka
> https://gitlab.com/gnutls/gnutls/-/issues/841 fixing TLS1.2 client
> side resumption errors.

#956649. :-)

I'm assuming this is fixed in at least unstable already, but the BTS
metadata suggests otherwise (potentially not helped by the local
"found" version).

Please could you confirm, and fix either the metadata or unstable.

Thanks,

Adam

Bug#933734: CRTL+ARROWS switch but does not really now

[Vincent Lefevre]

On 2020-05-12 13:55:25 +0200, Andreas Ronnquist wrote:
> The default setting is Ctrl+Right/Ctrl+Left to switch tabs,

I've just installed sakura to try it, and this is what I've noticed.
Ctrl+Right/Ctrl+Left works, but not Alt+Right/Alt+Left.

The sakura(1) man page says about the default:

   Alt  + Left cursor   -> Previous tab
   Alt  + Right cursor  -> Next tab

So, either the default is buggy, or the man page is incorrect.

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

Bug#960886: dnetc does not need restarting after log rotate

[Stephen Gildea]

Package: distributed-net
Version: 2.9112.521-1
Tags: patch

Every week, cron logs an error from attempting to logrotate distributed-net.

/etc/logrotate.d/distributed-net says after rotating to run
invoke-rc.d distributed-net reload >/dev/null

/etc/init.d/distributed-net doesn't support a "reload" action,
only "restart", so the attempt gives an error.

But it turns out that dnetc re-opens the log file each time it writes,
so no reload or restart is necessary, and we can just get rid of the
postrotate action entirely.  Here's the patch:

--- debian/distributed-net.logrotate_2.9112.521-12009-03-14 
21:49:18.0 -0700
+++ debian/distributed-net.logrotate  2020-05-17 09:29:05.284103866 -0700
@@ -2,8 +2,5 @@
weekly
rotate 5
create 640 daemon adm
-   postrotate
-   invoke-rc.d distributed-net reload >/dev/null
-   endscript
compress
 }

Bug#960885: buster-pu: package fdroidserver_1.1.7-1~deb10u1

[Adam D. Barratt]

On Sun, 2020-05-17 at 22:49 +0200, Hans-Christoph Steiner wrote:
> We worked out this plan to keep fdroidserver update in buster in the
> previous release.debian.org bug:
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=935809

I'm not sure if there's been some misunderstanding then or now, but I
don't remember the previous discussion covering updates outside of the
one discussed there, and I can't see that it did on re-reading.

(I've not looked through this diff for suitability, but your wording
above sounds like you think there was a general pre-ACK for new
updates, which doesn't match my recollection.)

Regards,

Adam

Bug#960632: src:plm: Please add support to build against libjson-simple-java >= 3

[Gilles Filippini]

Hi Martin,

Martin Quinson a écrit le 17/05/2020 à 22:31 :
> Hello again,
> 
> when I try to launch the program with your patch applied, I get the
> following backtrace:
> 
> Exception in thread "main" java.lang.ClassCastException: class
> org.json.simple.JsonArray cannot be cast to class
> org.json.simple.JsonObject (org.json.simple.JsonArray and
> org.json.simple.JsonObject are in unnamed module of loader 'app')
> at plm.core.model.Users.loadUsersFromFile(Unknown Source)
>   at plm.core.model.Users.(Unknown Source)
>   at plm.core.model.Game.(Unknown Source)
>   at plm.core.model.Game.getInstance(Unknown Source)
> at plm.core.ui.ProgrammersLearningMachine.main(Unknown Source)
>   
> I will try to fix it in the near future, but your help would of course
> be welcome. Don't modify your patch as it is applied and burried under
> other changes already. Instead, please propose another patch on top of
> the current state in the package in
> https://salsa.debian.org/java-team/plm/

I'll have a look at this.

> Btw, I fixed a bug in the package that made it unusable on new
> installation since maybe 4 years. It was only working with openjdk7 :(
> Now, you should be able to start the program with the plm helper script.
> 
> Thanks for your help,
> Mt.
> 
> On Sun, May 17, 2020 at 08:23:36AM +0200, Martin Quinson wrote:
>> Hello Gilles,
>>
>> many thanks for your help, this package is in a rather sorry state,
>> and I promise myself to do something about it since a long time.
>> Hopefully this will be the nodge I needed :)
>>
>> I happen to be the upstream maintainer of this software, and I'd like
>> to make things simpler if possible. Is it possible to update the code
>> so that the patch does not depend on the used version?
>>
>> I will try to apply this patch, and then patch upstream to use json-simple-3 
>> only.

I need first to have json-simple reverse dependencies compatible with
both versions, to be able to manage the transition.
Once the transition is over there is no problem making plm supporting
json-simple 3 only.

Thanks,

_g.



signature.asc
Description: OpenPGP digital signature

Bug#960885: buster-pu: package fdroidserver_1.1.7-1~deb10u1

[Hans-Christoph Steiner]

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

Hi release team,

This is a stable upstream release targeted for Debian/buster.  It fixes
some key usability bugs.  I'm part of upstream, and we did
our Debian/buster bug fix work in our stable 1.1.x branch, so the
changes are mostly in the upstream source tarball.  There were also a
series of uploads to troubleshoot an issue with binfmt_misc on
ci.debian.net.  Most of the debdiff is the README being properly
included in the python egg-info.

We worked out this plan to keep fdroidserver update in buster in the
previous release.debian.org bug:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=935809

This package has an extensive autopkgtest suite.  The debian/changelog
mostly shows fixes to the test runs:

fdroidserver (1.1.7-1~deb10u1) buster; urgency=medium

  * New upstream release targeted for Debian/buster (Closes: #954070)
  * Remove "Recommends" test, ci.debian.net do not support binfmt_misc:
https://salsa.debian.org/ci-team/debian-ci-config/-/issues/1

 -- Hans-Christoph Steiner   Sat, 16 May 2020 22:15:14 +0200

fdroidserver (1.1.6-4) unstable; urgency=medium

  * fix running Recommends: test in containers

 -- Hans-Christoph Steiner   Wed, 13 May 2020 20:13:06 +0200

fdroidserver (1.1.6-3) unstable; urgency=medium

  * only run Recommends: test in VM, not base test

 -- Hans-Christoph Steiner   Tue, 12 May 2020 11:57:26 +0200

fdroidserver (1.1.6-2) unstable; urgency=medium

  * fix autopkgtest: run in VM so binfmt can be properly setup (Closes:
#954395)

 -- Hans-Christoph Steiner   Mon, 11 May 2020 21:55:14 +0200

fdroidserver (1.1.6-1) unstable; urgency=medium

  * New upstream release targeted for Debian/buster

 -- Hans-Christoph Steiner   Tue, 17 Dec 2019 14:54:02 +0100




diff --git a/PKG-INFO b/PKG-INFO
index 63697869..ac4ea350 100644
--- a/PKG-INFO
+++ b/PKG-INFO
@@ -1,12 +1,121 @@
 Metadata-Version: 2.1
 Name: fdroidserver
-Version: 1.1.4
+Version: 1.1.7
 Summary: F-Droid Server Tools
 Home-page: https://f-droid.org
 Author: The F-Droid Project
 Author-email: t...@f-droid.org
 License: AGPL-3.0
-Description: README.md
+Description: 
+
+| CI Builds|  fdroidserver | buildserver | fdroid 
build --all | publishing tools |
+
|--|:-:|:---:|:--:|::|
+| Debian   | [![fdroidserver status on 
Debian](https://gitlab.com/fdroid/fdroidserver/badges/master/build.svg)](https://gitlab.com/fdroid/fdroidserver/builds)
 | [![buildserver 
status](https://jenkins.debian.net/job/reproducible_setup_fdroid_build_environment/badge/icon)](https://jenkins.debian.net/job/reproducible_setup_fdroid_build_environment)
 | [![fdroid build all 
status](https://jenkins.debian.net/job/reproducible_fdroid_build_apps/badge/icon)](https://jenkins.debian.net/job/reproducible_fdroid_build_apps/)
 | [![fdroid test 
status](https://jenkins.debian.net/job/reproducible_fdroid_test/badge/icon)](https://jenkins.debian.net/job/reproducible_fdroid_test/)
 |
+| macOS & Ubuntu/trusty| [![fdroidserver status on macOS & 
Ubuntu/LTS](https://travis-ci.org/fdroidtravis/fdroidserver.svg?branch=master)](https://travis-ci.org/fdroidtravis/fdroidserver)
 | | | |
+
+
+# F-Droid Server
+
+Server for [F-Droid](https://f-droid.org), the Free Software 
repository system
+for Android.
+
+The F-Droid server tools provide various scripts and tools that are
+used to maintain the main
+[F-Droid application repository](https://f-droid.org/packages).  You
+can use these same tools to create your own additional or alternative
+repository for publishing, or to assist in creating, testing and
+submitting metadata to the main repository.
+
+For documentation, please see , or you can
+find the source for the documentation in
+[fdroid/fdroid-website](https://gitlab.com/fdroid/fdroid-website).
+
+
+### What is F-Droid?
+
+F-Droid is an installable catalogue of FOSS (Free and Open Source 
Software)
+applications for the Android platform. The client makes it easy to 
browse,
+install, and keep track of updates on your device.
+
+
+### Installing
+
+There are many ways to install _fdroidserver_, they are documented on
+the website:
+https://f-droid.org/docs/Installing_the_Server_and_Repo_Tools
+
+All sorts of other documentation lives there as well.
+
+
+### Tests
+
+There are many components to all of the tests for the components in
+this git repo.  The most commonly used parts of well tested, while
+some parts still lack tests.  This test suite has built 

Bug#960010: freefem++: diff for NMU version 3.61.1+dfsg1-5.1

[Stefano Rivera]

Control: tags 960010 + patch

Dear maintainer,

I've prepared an NMU for freefem++ (versioned as 3.61.1+dfsg1-5.1). The diff
is attached to this message.

Regards,

SR
diff -Nru freefem++-3.61.1+dfsg1/debian/changelog freefem++-3.61.1+dfsg1/debian/changelog
--- freefem++-3.61.1+dfsg1/debian/changelog	2019-10-05 00:21:24.0 -0700
+++ freefem++-3.61.1+dfsg1/debian/changelog	2020-05-17 13:41:04.0 -0700
@@ -1,3 +1,10 @@
+freefem++ (3.61.1+dfsg1-5.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix FTBFS with gsl 2.6 (Closes: #960010)
+
+ -- Stefano Rivera   Sun, 17 May 2020 13:41:04 -0700
+
 freefem++ (3.61.1+dfsg1-5) unstable; urgency=medium
 
   * Team upload.
diff -Nru freefem++-3.61.1+dfsg1/debian/patches/double-cblas-import.patch freefem++-3.61.1+dfsg1/debian/patches/double-cblas-import.patch
--- freefem++-3.61.1+dfsg1/debian/patches/double-cblas-import.patch	1969-12-31 16:00:00.0 -0800
+++ freefem++-3.61.1+dfsg1/debian/patches/double-cblas-import.patch	2020-05-17 13:21:25.0 -0700
@@ -0,0 +1,25 @@
+Description: Avoid FTBFS with gsl 2.6 by including 2 incompatible cblas headers
+Bug-Debian: https://bugs.debian.org/960010
+Author: Frederic Hecht 
+Origin: upstream, https://github.com/FreeFem/FreeFem-sources/commit/3bfe3eb669c580583e9290474614b45cee52a96c
+
+--- a/src/femlib/MatriceCreuse_tpl.hpp
 b/src/femlib/MatriceCreuse_tpl.hpp
+@@ -12,7 +12,7 @@
+ // test blas 
+ //  on MacOS9 under MWERKS
+ //  cblas_ddot macos-9 is not 
+-#ifdef HAVE_CBLAS_H
++#ifdef HAVE_CBLAS_H_BUG
+ extern "C" {
+ #define FF_VERSION VERSION
+ #undef VERSION
+@@ -21,7 +21,7 @@
+ #define VERSION VERSION
+ }
+ #define WITHBLAS 1
+-#elif HAVE_VECLIB_CBLAS_H
++#elif HAVE_VECLIB_CBLAS_BUG
+ #include  
+ #define WITHBLAS 1
+ #endif  
diff -Nru freefem++-3.61.1+dfsg1/debian/patches/series freefem++-3.61.1+dfsg1/debian/patches/series
--- freefem++-3.61.1+dfsg1/debian/patches/series	2019-10-05 00:21:24.0 -0700
+++ freefem++-3.61.1+dfsg1/debian/patches/series	2020-05-17 13:17:38.0 -0700
@@ -3,3 +3,4 @@
 examples++-load.patch
 src_fflib.patch
 fix_all.edp.patch
+double-cblas-import.patch

Bug#958737: linux-image-5.5.0-0.bpo.2-amd64 sound broken on Dell Latutude 14 2-in-1

[Matteo Semplice]

I am affected by this bug too on a Dell Latitude 14" 2-in-1.

~$ apt list --installed | grep linux-image

WARNING: apt does not have a stable CLI interface. Use with caution in 
scripts.


linux-image-5.4.0-rc8/now 5.4.0-rc8-2 amd64 [installato, locale]
linux-image-5.5.0-0.bpo.2-amd64/buster-backports,now 5.5.17-1~bpo10+1 
amd64 [installato, automatico]

linux-image-5.5.0-rc5-amd64/now 5.5~rc5-1~exp1 amd64 [installato, locale]
linux-image-amd64/buster-backports,now 5.5.17-1~bpo10+1 amd64 [installato]

Sound was working on a custom built 5.4.0-rc8 and on the 5.5.0-rc5 from 
experimental, but after the upgrade to 5.5.0-0.bpo.2 I have only a 
"Dummy output" in my mixer.


The results of journalctl -b | grep "00:1f\.3" are

== 5.5.0-rc5 == working sound ==

~# journalctl -b | grep "00:1f\.3"

mag 17 17:04:19 dentdherens kernel: pci :00:1f.3: [8086:02c8] type 
00 class 0x040100
mag 17 17:04:19 dentdherens kernel: pci :00:1f.3: reg 0x10: [mem 
0x6001118000-0x600111bfff 64bit]
mag 17 17:04:19 dentdherens kernel: pci :00:1f.3: reg 0x20: [mem 
0x600100-0x60010f 64bit]
mag 17 17:04:19 dentdherens kernel: pci :00:1f.3: PME# supported 
from D3hot D3cold
mag 17 17:04:19 dentdherens kernel: pci :00:1f.3: Adding to iommu 
group 12
mag 17 17:04:19 dentdherens kernel: snd_hda_intel :00:1f.3: DSP 
detected with PCI class/subclass/prog-if info 0x040100
mag 17 17:04:19 dentdherens kernel: snd_hda_intel :00:1f.3: enabling 
device ( -> 0002)
mag 17 17:04:19 dentdherens kernel: snd_hda_intel :00:1f.3: bound 
:00:02.0 (ops i915_audio_component_bind_ops [i915])
mag 17 17:58:20 dentdherens kernel: input: HDA Digital PCBeep as 
/devices/pci:00/:00:1f.3/sound/card0/input30
mag 17 17:58:20 dentdherens kernel: input: HDA Intel PCH Headphone Mic 
as /devices/pci:00/:00:1f.3/sound/card0/input31
mag 17 17:58:20 dentdherens kernel: input: HDA Intel PCH HDMI/DP,pcm=3 
as /devices/pci:00/:00:1f.3/sound/card0/input32
mag 17 17:58:20 dentdherens kernel: input: HDA Intel PCH HDMI/DP,pcm=7 
as /devices/pci:00/:00:1f.3/sound/card0/input33
mag 17 17:58:20 dentdherens kernel: input: HDA Intel PCH HDMI/DP,pcm=8 
as /devices/pci:00/:00:1f.3/sound/card0/input34
mag 17 17:58:20 dentdherens kernel: input: HDA Intel PCH HDMI/DP,pcm=9 
as /devices/pci:00/:00:1f.3/sound/card0/input35
mag 17 17:58:20 dentdherens kernel: input: HDA Intel PCH HDMI/DP,pcm=10 
as /devices/pci:00/:00:1f.3/sound/card0/input36


===

== 5.5.0-0.bpo.2 == sound not working ==

mag 17 17:14:29 dentdherens kernel: pci :00:1f.3: [8086:02c8] type 
00 class 0x040100
mag 17 17:14:29 dentdherens kernel: pci :00:1f.3: reg 0x10: [mem 
0x6001118000-0x600111bfff 64bit]
mag 17 17:14:29 dentdherens kernel: pci :00:1f.3: reg 0x20: [mem 
0x600100-0x60010f 64bit]
mag 17 17:14:29 dentdherens kernel: pci :00:1f.3: PME# supported 
from D3hot D3cold
mag 17 17:14:29 dentdherens kernel: pci :00:1f.3: Adding to iommu 
group 12
mag 17 17:14:29 dentdherens kernel: snd_hda_intel :00:1f.3: DSP 
detected with PCI class/subclass/prog-if info 0x040100
mag 17 17:14:29 dentdherens kernel: snd_hda_intel :00:1f.3: Digital 
mics found on Skylake+ platform, using SOF driver
mag 17 18:08:38 dentdherens kernel: sof-audio-pci :00:1f.3: DSP 
detected with PCI class/subclass/prog-if info 0x040100
mag 17 18:08:38 dentdherens kernel: sof-audio-pci :00:1f.3: Digital 
mics found on Skylake+ platform, using SOF driver
mag 17 18:08:38 dentdherens kernel: sof-audio-pci :00:1f.3: enabling 
device ( -> 0002)
mag 17 18:08:38 dentdherens kernel: sof-audio-pci :00:1f.3: warning: 
No matching ASoC machine driver found
mag 17 18:08:38 dentdherens kernel: sof-audio-pci :00:1f.3: DSP 
detected with PCI class/subclass/prog-if 0x040100
mag 17 18:08:38 dentdherens kernel: sof-audio-pci :00:1f.3: use msi 
interrupt mode
mag 17 18:08:38 dentdherens kernel: sof-audio-pci :00:1f.3: bound 
:00:02.0 (ops i915_audio_component_bind_ops [i915])
mag 17 18:08:38 dentdherens kernel: sof-audio-pci :00:1f.3: hda 
codecs found, mask 5
mag 17 18:08:38 dentdherens kernel: sof-audio-pci :00:1f.3: using 
HDA machine driver skl_hda_dsp_generic now
mag 17 18:08:38 dentdherens kernel: sof-audio-pci :00:1f.3: 
firmware: failed to load intel/sof/sof-cml.ri (-2)
mag 17 18:08:38 dentdherens kernel: sof-audio-pci :00:1f.3: Direct 
firmware load for intel/sof/sof-cml.ri failed with error -2
mag 17 18:08:38 dentdherens kernel: sof-audio-pci :00:1f.3: error: 
request firmware intel/sof/sof-cml.ri failed err: -2
mag 17 18:08:38 dentdherens kernel: sof-audio-pci :00:1f.3: error: 
failed to load DSP firmware -2
mag 17 18:08:38 dentdherens kernel: sof-audio-pci :00:1f.3: error: 
sof_probe_work failed err: -2


===

It seems that the version in backports recognizes the "Digital mics 
found on Skylake+ platform, using SOF driver" 

Bug#960638: [Pkg-shadow-devel] Bug#960638: login no longer needs to be essential

[Josh Triplett]

On Fri, May 15, 2020 at 01:33:42AM +0200, Chris Hofstaedtler wrote:
> * Josh Triplett  [200515 00:21]:
> > It should still have priority "required", and
> > perhaps "Important: yes" so that apt makes sure the user doesn't remove
> > it by accident, but it doesn't need "Essential: yes" anymore.
> 
> However, if you keep Important: yes, you'll discover that the Debian
> tooling doesn't deal with this properly, and your package won't
> migrate to testing. So ... I'd recommend avoiding Important: yes.

I was not aware of that.

Any reference to a bug report about that?

Bug#960632: src:plm: Please add support to build against libjson-simple-java >= 3

[Martin Quinson]

Hello again,

when I try to launch the program with your patch applied, I get the
following backtrace:

Exception in thread "main" java.lang.ClassCastException: class
org.json.simple.JsonArray cannot be cast to class
org.json.simple.JsonObject (org.json.simple.JsonArray and
org.json.simple.JsonObject are in unnamed module of loader 'app')
at plm.core.model.Users.loadUsersFromFile(Unknown Source)
at plm.core.model.Users.(Unknown Source)
at plm.core.model.Game.(Unknown Source)
at plm.core.model.Game.getInstance(Unknown Source)
at plm.core.ui.ProgrammersLearningMachine.main(Unknown Source)

I will try to fix it in the near future, but your help would of course
be welcome. Don't modify your patch as it is applied and burried under
other changes already. Instead, please propose another patch on top of
the current state in the package in
https://salsa.debian.org/java-team/plm/

Btw, I fixed a bug in the package that made it unusable on new
installation since maybe 4 years. It was only working with openjdk7 :(
Now, you should be able to start the program with the plm helper script.

Thanks for your help,
Mt.

On Sun, May 17, 2020 at 08:23:36AM +0200, Martin Quinson wrote:
> Hello Gilles,
> 
> many thanks for your help, this package is in a rather sorry state,
> and I promise myself to do something about it since a long time.
> Hopefully this will be the nodge I needed :)
> 
> I happen to be the upstream maintainer of this software, and I'd like
> to make things simpler if possible. Is it possible to update the code
> so that the patch does not depend on the used version?
> 
> I will try to apply this patch, and then patch upstream to use json-simple-3 
> only.
> 
> Thanks, Mt.
> 
> On Thu, May 14, 2020 at 11:28:01PM +0200, Gilles Filippini wrote:
> > Package: src:plm
> > Version: 2.6+repack-3
> > Severity: normal
> > Tags: patch
> > 
> > -BEGIN PGP SIGNED MESSAGE-
> > Hash: SHA512
> > 
> > Hi,
> > 
> > I'd like to transition json-simple 3.1.1 to unstable, but plm is a blocker 
> > since it builds against libjson-simple-java << 3 only.
> > 
> > The json-simple classes used by plm were deprecated in version 2.0.0 [1]. 
> > There were removed in versions 3.x [2].
> > 
> > [1] 
> > https://github.com/cliftonlabs/json-simple/blob/json-simple-2.0.0/README.txt
> > [2] 
> > https://github.com/cliftonlabs/json-simple/blob/json-simple-3.0.1/CHANGELOG
> > 
> > Please find attached a patch proposal to use the current json-simple 
> > classes. I've tested that the package builds correctly against 
> > libjson-simple-java version 2.3.0-1 from unstable and version 3.1.1-1~exp2 
> > currently in experimental. But I don't known how to test the package 
> > afterward.
> > 
> > Thanks in advance for considering.
> > 
> > _g.
> > 
> > -- System Information:
> > Debian Release: buster/sid
> > Architecture: amd64 (x86_64)
> > Foreign Architectures: i386
> > 
> > Kernel: Linux 5.6.0-1-amd64 (SMP w/4 CPU cores)
> > Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), 
> > LANGUAGE=fr_FR.UTF-8 (charmap=UTF-8)
> > Shell: /bin/sh linked to /bin/dash
> > Init: systemd (via /run/systemd/system)
> > LSM: AppArmor: enabled
> > 
> > 
> 
> > diff -Nru plm-2.6+repack/debian/changelog plm-2.6+repack/debian/changelog
> > --- plm-2.6+repack/debian/changelog 2016-09-18 16:39:19.0 +0200
> > +++ plm-2.6+repack/debian/changelog 2020-05-14 18:05:12.0 +0200
> > @@ -1,3 +1,10 @@
> > +plm (2.6+repack-3.1) UNRELEASED; urgency=medium
> > +
> > +  * Non-maintainer upload.
> > +  * Tentative patch to build against json-simple 3
> > +
> > + -- Gilles Filippini   Thu, 14 May 2020 18:05:12 +0200
> > +
> >  plm (2.6+repack-3) unstable; urgency=medium
> >  
> >* Add run-time dependencies on default-jdk, jython and jruby.
> > diff -Nru plm-2.6+repack/debian/patches/json-simple-3.patch 
> > plm-2.6+repack/debian/patches/json-simple-3.patch
> > --- plm-2.6+repack/debian/patches/json-simple-3.patch   1970-01-01 
> > 01:00:00.0 +0100
> > +++ plm-2.6+repack/debian/patches/json-simple-3.patch   2020-05-14 
> > 18:05:12.0 +0200
> > @@ -0,0 +1,595 @@
> > +Description: Migrate away from deprecated json-simple 1.x classes
> > + See json-simple 2.0.0 changelog:
> > + > * Deprecated JSONParse and JSONValue in favor of Jsoner.
> > + > * Deprecated JSONStreamAware and JSONAware in favor of Jsonable.
> > + > * Deprecated JSONObject in favor of JsonObject.
> > + > * Deprecated JSONArray in favor of JsonArray.
> > + .
> > + This patch uses the new json-simple Json* classes. It is compatible with
> > + both 2.x and 3.x json-simple releases, with a few ajustments regarding
> > + backward incompatible changes in json-simple 3.x:
> > + - The package name, changed to com.github.cliftonlabs.json_simple
> > + - The exception DeserializationExcetpion renamed as JsonException
> > + These two changes are handled using place-holders @JSON_SIMPLE_PACKAGE@
> > + and @JSON_EXCETPION@ 

Bug#960884: libwildmagic: Fix underlinkage issues with ld --as-needed

[Logan Rosen]

Package: libwildmagic
Version: 5.17+cleaned1-3
Severity: normal
Tags: patch
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu groovy ubuntu-patch

Hi,

I noticed that you applied a linking fix in 5.17+cleaned1-2, but it
doesn't address all of the errors output by dh-shlibdeps in the build
logs, and there's a cleaner way to fix it that we've been carrying as a
delta in Ubuntu.

Since GCC 10 uses ld --as-needed, it's important that the libraries come
after the objects that require them. The attached patch does this
accordingly and resolves all of the dh-shlibdeps warnings about
underlinkage (and fixes the same openms build issue you noticed).

In Ubuntu, the attached patch was applied to achieve the following:

  * d/p/ld-as-needed: Fix (under)linking issues with ld --as-needed.
  * d/control: Add conflicts/replaces for libwildmagic5 (can be dropped
after next LTS, 22.04).
  * Drop d/p/fixNoLinkToLibsSymbolsUnused.patch because ld-as-needed patch
fixes issue in a cleaner way (and Debian's patch still leads to
dh_shlibdeps warnings).

Thanks for considering the patch.

Logan

-- System Information:
Debian Release: bullseye/sid
  APT prefers focal-updates
  APT policy: (500, 'focal-updates'), (500, 'focal-security'), (500, 'focal'), 
(100, 'focal-backports')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.4.0-29-generic (SMP w/8 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
diff -Nru libwildmagic-5.17+cleaned1/debian/patches/ld-as-needed 
libwildmagic-5.17+cleaned1/debian/patches/ld-as-needed
--- libwildmagic-5.17+cleaned1/debian/patches/ld-as-needed  1969-12-31 
19:00:00.0 -0500
+++ libwildmagic-5.17+cleaned1/debian/patches/ld-as-needed  2020-05-17 
16:02:46.0 -0400
@@ -0,0 +1,144 @@
+Description: fix (under)linking issues with ld --as-needed
+Author: Logan Rosen 
+Bug-Ubuntu: https://launchpad.net/bugs/1578222
+Forwarded: no
+Last-Update: 2016-05-09
+---
+This patch header follows DEP-3: http://dep.debian.net/deps/dep3/
+--- a/LibApplications/makefile.wm5
 b/LibApplications/makefile.wm5
+@@ -16,7 +16,8 @@
+ RELVER = $(SOVER).17
+ CFLAGS += -fPIC
+ AR := $(CC)
+-ARFLAGS := $(LDFLAGS) -L$(LIBPATH) -shared -fPIC 
-Wl,-soname,libWm5Applications.so.$(SOVER) -lWm5Core -lWm5Mathematics 
-lWm5Imagics -lWm5Graphics -lWm5Physics -o
++ARFLAGS := $(LDFLAGS) -L$(LIBPATH) -shared -fPIC 
-Wl,-soname,libWm5Applications.so.$(SOVER) -o
++LIBS := -lWm5Core -lWm5Mathematics -lWm5Imagics -lWm5Graphics -lWm5Physics 
-lX11
+ LIB := $(LIBPATH)/libWm5Applications.so.$(RELVER)
+ else
+ AR := /usr/bin/ar
+@@ -44,7 +45,7 @@
+ OBJ := $(SRC:%.cpp=$(OBJDIR)/%.o)
+ 
+ build : $(OBJ) $(OBJDIR)/Wm5GlxApplication.o
+-  $(AR) $(ARFLAGS) $(LIB) $(OBJ) $(OBJDIR)/Wm5GlxApplication.o
++  $(AR) $(ARFLAGS) $(LIB) $(OBJ) $(OBJDIR)/Wm5GlxApplication.o $(LIBS)
+   cp -fp $(INC) $(INCDIR) 
+   ln -sf -T libWm5Applications.so.$(RELVER) 
../SDK/Library/$(OBJDIR)/libWm5Applications.so
+   ln -sf -T libWm5Applications.so.$(RELVER) 
../SDK/Library/$(OBJDIR)/libWm5Applications.so.$(SOVER)
+--- a/LibGraphics/makeprj.wm5
 b/LibGraphics/makeprj.wm5
+@@ -16,7 +16,8 @@
+ RELVER = $(SOVER).17
+ CFLAGS += -fPIC
+ AR := $(CC)
+-ARFLAGS := $(LDFLAGS) -L $(LIBPATH) -shared -fPIC 
-Wl,-soname,libWm5Graphics.so.$(SOVER) -lWm5Core -lWm5Mathematics -o
++ARFLAGS := $(LDFLAGS) -L $(LIBPATH) -shared -fPIC 
-Wl,-soname,libWm5Graphics.so.$(SOVER) -o
++LIBS := -lWm5Core -lWm5Mathematics -lGL
+ LIB := $(LIBPATH)/libWm5Graphics.so.$(RELVER)
+ else
+ AR := /usr/bin/ar
+@@ -50,7 +51,7 @@
+ OBJ := $(SRC:%.cpp=$(OBJDIR)/%.o)
+ 
+ build : $(OBJ)
+-  $(AR) $(ARFLAGS) $(LIB) $(OBJDIR)/*.o
++  $(AR) $(ARFLAGS) $(LIB) $(OBJDIR)/*.o $(LIBS)
+   cp -fp $(INC) $(INCDIR)
+ 
+ $(OBJDIR)/%.o : %.cpp
+--- a/LibImagics/makeprj.wm5
 b/LibImagics/makeprj.wm5
+@@ -16,7 +16,8 @@
+ RELVER = $(SOVER).17
+ CFLAGS += -fPIC
+ AR := $(CC)
+-ARFLAGS := $(LDFLAGS) -L $(LIBPATH) -shared -fPIC 
-Wl,-soname,libWm5Imagics.so.$(SOVER) -lWm5Core -lWm5Mathematics -o
++ARFLAGS := $(LDFLAGS) -L $(LIBPATH) -shared -fPIC 
-Wl,-soname,libWm5Imagics.so.$(SOVER) -o
++LIBS := -lWm5Core -lWm5Mathematics
+ LIB := $(LIBPATH)/libWm5Imagics.so.$(RELVER)
+ else
+ AR := /usr/bin/ar
+@@ -42,7 +43,7 @@
+ OBJ := $(SRC:%.cpp=$(OBJDIR)/%.o)
+ 
+ build : $(OBJ)
+-  $(AR) $(ARFLAGS) $(LIB) $(OBJDIR)/*.o
++  $(AR) $(ARFLAGS) $(LIB) $(OBJDIR)/*.o $(LIBS)
+   cp -fp $(INC) $(INCDIR)
+ 
+ $(OBJDIR)/%.o : %.cpp
+--- a/LibMathematics/makeprj.wm5
 b/LibMathematics/makeprj.wm5
+@@ -16,7 +16,8 @@
+ RELVER = $(SOVER).17
+ CFLAGS += -fPIC
+ AR := $(CC)
+-ARFLAGS := $(LDFLAGS) -L $(LIBPATH) -shared -fPIC 
-Wl,-soname,libWm5Mathematics.so.$(SOVER) -lWm5Core -o
++ARFLAGS := $(LDFLAGS) -L $(LIBPATH) -shared -fPIC 
-Wl,-soname,libWm5Mathematics.so.$(SOVER) 

Bug#960785: debci: allow self-service to launch tests for blacklisted packages

[Paul Gevers]

Control: tags -1 wontfix

Hi Drew,

On 16-05-2020 18:08, Drew Parsons wrote:
> Some packages are blacklisted from debci tests since they repeatedly
> fail their tests.
> 
> Nevertheless, it should be allowed to trigger tests manually with
> self-service. Currently that's not possible, the test simply doesn't
> run for a blacklisted package if triggered from self-service.

The whole idea of blacklisting is to avoid the test being run. The
migration software run by the release team uses the same facility as the
self-service (it is just a slightly special user). Hence, this request
would require a large restructuring of the code, for very little gain.

> If a new release has been uploaded, we need to be able to see if it
> has fixed the test failures.

You'll have to ping the maintainers of ci.d.n. If you believe such a bug
is fixed, close it, we'll lift the ban and if it still fails, we can
reopen the bug.

> scipy 1.4, for instance, has the new version fixed the problems with
> tests?

I have just scheduled a test run (in unstable), sorry for not responding
earlier to your requests in bug #946625, it slipped through. Please
close that bug if it passes.

Paul



signature.asc
Description: OpenPGP digital signature

Bug#960883: FBZX is out of date

[Steve Clark]

Package: fbzx
Version: 3.1.0-1

FBZX is a bit out of date. The current version in Buster is 3.1.0 which
has issues with full-screen where it changes a multi-monitor setup to
mirrored from what-ever you had previously. Also, it doesn't seem to
append to TZX/TAP files when SAVEing as it should.

The upstream version 4.0.0 has neither of these issues.

Bug#939058: subnetcalc: bogus autopkgtest definition file blocking migration to testing

[Paul Gevers]

Control: severity -1 serious

Hi,

On Sat, 31 Aug 2019 19:49:35 +0200 Paul Gevers  wrote:
> I noticed your package isn't migrating to testing because it's waiting
> for the results of the new autopkgtest (great) you introduced. However,
> the autopkgtest definition file debian/tests/control isn't using proper
> syntax. Due to the autopkgtest bug #918882, this is marked as tmpfail
> and is retried over and over again.

The release team has announced [1] that failing autopkgtest are now
considered RC in testing. I therefor raise the severity of this bug.

Paul

[1] https://lists.debian.org/debian-devel-announce/2019/07/msg2.html



signature.asc
Description: OpenPGP digital signature

Bug#960881: mark golang-sorcix-irc-dev Multi-Arch: foreign

[Helmut Grohne]

Package: golang-sorcix-irc-dev
Version: 1.1.0-2
Tags: patch
User: debian-cr...@lists.debian.org
Usertags: cross-satisfiability
Control: affects -1 + src:robustirc-bridge

Please mark golang-sorcix-irc-dev Multi-Arch: foreign to help making the
build-depends of robustirc-bridge cross-satisfiable. In general,
Architecture: all packages can never satisfy cross Build-Depends unless
marked Multi-Arch: foreign or annotated :native. The foreign marking is
reasonable here as golang-sorcix-irc-dev entirely lacks dependencies and
maintainer scripts. From a multiarch pov, it is a data package. Please
consider applying the attached patch.

Helmut
diff --minimal -Nru golang-sorcix-irc-dev-1.1.0/debian/changelog 
golang-sorcix-irc-dev-1.1.0/debian/changelog
--- golang-sorcix-irc-dev-1.1.0/debian/changelog2018-02-09 
17:09:26.0 +0100
+++ golang-sorcix-irc-dev-1.1.0/debian/changelog2020-05-17 
21:11:12.0 +0200
@@ -1,3 +1,10 @@
+golang-sorcix-irc-dev (1.1.0-2.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Mark golang-sorcix-irc-dev Multi-Arch: foreign. (Closes: #-1)
+
+ -- Helmut Grohne   Sun, 17 May 2020 21:11:12 +0200
+
 golang-sorcix-irc-dev (1.1.0-2) unstable; urgency=medium
 
   [ Paul Tagliamonte ]
diff --minimal -Nru golang-sorcix-irc-dev-1.1.0/debian/control 
golang-sorcix-irc-dev-1.1.0/debian/control
--- golang-sorcix-irc-dev-1.1.0/debian/control  2018-02-09 17:09:26.0 
+0100
+++ golang-sorcix-irc-dev-1.1.0/debian/control  2020-05-17 21:11:11.0 
+0200
@@ -12,6 +12,7 @@
 
 Package: golang-sorcix-irc-dev
 Architecture: all
+Multi-Arch: foreign
 Depends: ${shlibs:Depends}, ${misc:Depends}
 Description: generic support for the IRC protocol in Go
  Package irc allows your application to speak the IRC protocol.

Bug#960880: pev: autopkgtest failure: pehash did not report ASLR status

[Paul Gevers]

Source: pev
Version: 0.80-4
X-Debbugs-CC: debian...@lists.debian.org
Severity: serious
User: debian...@lists.debian.org
Usertags: fails-always

Dear maintainer(s),

Your package pev has an autopkgtest, great. However, it fails. Can you
please investigate the situation and fix it? I copied some of the output
at the bottom of this report.

The release team has announced [1] that failing autopkgtest are now
considered RC in testing.

Paul

[1] https://lists.debian.org/debian-devel-announce/2019/07/msg2.html

https://ci.debian.net/data/autopkgtest/testing/amd64/p/pev/5529710/log.gz

autopkgtest [13:21:31]: test test-runs: [---
valgrind is /usr/bin/valgrind
==831== Memcheck, a memory error detector
==831== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al.
==831== Using Valgrind-3.15.0 and LibVEX; rerun with -h for copyright info
==831== Command: pesec /usr/share/win32/gzip.exe
==831==
plugins: could not open directory 'src/build/plugins' -- No such file or
directory
==831==
==831== HEAP SUMMARY:
==831== in use at exit: 18 bytes in 1 blocks
==831==   total heap usage: 3 allocs, 2 frees, 4,602 bytes allocated
==831==
==831== LEAK SUMMARY:
==831==definitely lost: 0 bytes in 0 blocks
==831==indirectly lost: 0 bytes in 0 blocks
==831==  possibly lost: 0 bytes in 0 blocks
==831==still reachable: 18 bytes in 1 blocks
==831== suppressed: 0 bytes in 0 blocks
==831== Rerun with --leak-check=full to see details of leaked memory
==831==
==831== For lists of detected and suppressed errors, rerun with: -s
==831== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)
error: pesec did not report ASLR status
==833== Memcheck, a memory error detector
==833== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al.
==833== Using Valgrind-3.15.0 and LibVEX; rerun with -h for copyright info
==833== Command: pehash /usr/share/win32/gzip.exe
==833==
plugins: could not open directory 'src/build/plugins' -- No such file or
directory
==833==
==833== HEAP SUMMARY:
==833== in use at exit: 18 bytes in 1 blocks
==833==   total heap usage: 3 allocs, 2 frees, 4,602 bytes allocated
==833==
==833== LEAK SUMMARY:
==833==definitely lost: 0 bytes in 0 blocks
==833==indirectly lost: 0 bytes in 0 blocks
==833==  possibly lost: 0 bytes in 0 blocks
==833==still reachable: 18 bytes in 1 blocks
==833== suppressed: 0 bytes in 0 blocks
==833== Rerun with --leak-check=full to see details of leaked memory
==833==
==833== For lists of detected and suppressed errors, rerun with: -s
==833== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)
error: pehash did not report ASLR status
autopkgtest [13:21:33]: test test-runs: ---]



signature.asc
Description: OpenPGP digital signature

Bug#950455: override_dh_auto_test-does-not-check-DEB_BUILD_OPTIONS should not be emitted for compat level >= 13

[Chris Lamb]

reassign 960878 src:lintian
forcemerge 950455 960878
thanks

Thanks; merging.


Regards,

-- 
  ,''`.
 : :'  : Chris Lamb
 `. `'`  la...@debian.org / chris-lamb.co.uk
   `-

Bug#960752: FTBFS on arch-all, test-suite failure - conova buildd has broken "localhost"

[Martin Pitt]

Control: retitle -1 FTBFS on IPv6-only hosts
Control: found -1 188-1
Control: forwarded -1 https://github.com/cockpit-project/cockpit/pull/14098
Control: tag -1 patch upstream

Hello Aurelien,

Aurelien Jarno [2020-05-16 19:27 +0200]:
> This is an IPv6 host only,

Ah! This explains the issue indeed. I'm able to reproduce this now.

To unbreak unstable users ASAP, I uploaded a binary-all build for now.

Aurelien Jarno [2020-05-17 17:04 +0200]:
> As g_network_address_parse() supports escaping addresses with [] even
> for IPv4 addresses, I guess the following *untested* patch should fix
> the issue.
> 
> --- a/src/common/test-webserver.c
> +++ b/src/common/test-webserver.c
> @@ -93,7 +93,7 @@
>/* HACK: this should be "localhost", but this fails on COPR; 
> https://github.com/cockpit-project/cockpit/issues/12423 */
>tc->localport = g_strdup_printf ("127.0.0.1:%d", port);
>if (str)
> -tc->hostport = g_strdup_printf ("%s:%d", str, port);
> +tc->hostport = g_strdup_printf ("[%s]:%d", str, port);
>if (inet)
>  g_object_unref (inet);
>g_free (str);

Spot on, thank you!  I tested this and sent an upstream PR to fix this.

Martin

Bug#934135: [Aptitude-devel] Bug#934135: aptitude: depends on libparse-debianchangelog-perl that has no upstream maintainer

[Axel Beckert]

Hi again,

Axel Beckert wrote:
> > > After some thought, I think a local aptitude-specific wrapper might be
> > > even better and obviates the question of whether dpkg-parsechangelog
> > > should be moved or not. :)
> > 
> > FWIW, this makes sense to me.
> 
> Ack, and I'm actually on it. Tried to incorporate it last weekend.
> 
> Problem: It doesn't work for me, no more highlighting of new changelog
> entries — which I is why I haven't pushed my changes yet.
> 
> Maybe I should push them to a branch. Will do.

Did that now. The commit by Guillem with my fixes is in
https://salsa.debian.org/apt-team/aptitude/-/tree/debian-sid-test-upstream-patches

I also started to prepare a new aptitude upstream release (but still
without Guillem's patch — that's what the branch above is for) and
pushed my other changes to the debian-sid branch.

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

Bug#960808: node-babel7 7.9.6

[Xavier]

Control: blocked -1 by 952335

Hi all,

node-babel7 7.9.6 seems ready but it needs node-commander 4.
node-commander upgrade is blocked by #952335 (uglify-js needs
node-commander 2)

Cheers,
Xavier

Bug#960879: aspcud: homepage outdated

[Ivo De Decker]

package: aspcud

Hi,

It seems the url of the apcud homepage changed.

The new page is https://potassco.org/aspcud/

Cheers,

Ivo

Bug#960867: fs-uae-launcher: The application crash every time at the beginning

[John Paul Adrian Glaubitz]

(You should not remove the bug tracker from the CC)

On 5/17/20 9:11 PM, Davide Lombardo wrote:
> Nope  I had the quite same crash output with the backport version:
> 
> $fs-uae-launcher 
> [LOGGING] Logging to /home/davide/Documents/FS-UAE/Cache/Logs/fs-uae-
> launcher.log.txt
> FS-UAE Launcher 3.0.2
> ['/usr/bin/fs-uae-launcher']
> uname_result(system='Linux', node='PC0', release='4.19.0-9-amd64', 
> version='#1 
> SMP Debian 4.19.118-2 (2020-04-29)', machine='x86_64', processor='')
> Traceback (most recent call last):
>   File "/usr/share/fs-uae-launcher/fsgs/archive.py", line 15, in 
> from lhafile import LhaFile
> ModuleNotFoundError: No module named 'lhafile'
> [ARCHIVE] LhaFile module import problem
> [SETTINGS] No settings path specified
> [SETTINGS] Using default /home/davide/Documents/FS-UAE/Data/Settings.ini
> [SETTINGS] File /home/davide/Documents/FS-UAE/Data/Settings.ini does not exist
> [I18N] Initialize_locale language = 
> [I18N] Locale is en_GB
> [I18N] Checking /usr/bin/share/fs-uae-launcher/share-dir
> [I18N] Checking /usr/bin/../share/fs-uae-launcher/share-dir
> [I18N] bindtextdomain fs-uae-launcher: /usr/bin/../share/locale
> [I18N] find translations for en_GB in local directory /usr/bin/../share/locale
> [I18N] Path to mo file: None
> [I18N] Translations object:  0x7f88fb118e80>
> corrupted size vs. prev_size in fastbins
> KCrash: crashing... crashRecursionCounter = 2
> KCrash: Application Name = python3.7 path = /usr/bin pid = 5149
> KCrash: Arguments: 
> Alarm clock

Which is a good indicator that's not a bug in fs-uae-launcher but some
other package.
 
> #apt-get reinstall libc6 && apt-get reinstall libgettextpo0 apt-get reinstall 
> python3 didn't work

Just re-installing packages doesn't magically fix bugs, I'm afraid.

I need to install a fresh Debian stable VM next week and see if I can reproduce
the problem, but I'm very sure it's not a problem with fs-uae-launcher as even
buggy Python code shouldn't be able to provoke a crash in glibc.

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

Bug#960877: meson 0.54.2-1 breaks bali-phy build

[Adrian Bunk]

Package: meson
Version: 0.54.2-1
Severity: serious
Tags: ftbfs
Control: affects -1 src:bali-phy

https://tests.reproducible-builds.org/debian/rb-pkg/bullseye/amd64/bali-phy.html

...
FAILED: src/builtins/Prelude.so
c++  -o src/builtins/Prelude.so 
'src/builtins/2382537@@Prelude@sha/Prelude.cc.o' -Wl,--as-needed 
-Wl,--allow-shlib-undefined -Wl,-O1 -shared -fPIC -Wl,--start-group 
-Wl,-soname,Prelude.so -g -O2 
-ffile-prefix-map=/build/1st/bali-phy-3.5.0.1+dfsg=. -fstack-protector-strong 
-Wformat -Werror=format-security -O3 -Wl,-z,relro -Wl,-z,now 
/usr/lib/x86_64-linux-gnu/libboost_program_options.a 
/usr/lib/x86_64-linux-gnu/libboost_random.a 
/usr/lib/x86_64-linux-gnu/libboost_system.a 
/usr/lib/x86_64-linux-gnu/libboost_filesystem.a 
/usr/lib/x86_64-linux-gnu/libboost_chrono.a -Wl,--end-group
/usr/bin/ld: /usr/lib/x86_64-linux-gnu/libboost_system.a(error_code.o): 
relocation R_X86_64_PC32 against symbol 
`_ZTVN5boost6system6detail22generic_error_categoryE' can not be used when 
making a shared object; recompile with -fPIC
/usr/bin/ld: final link failed: bad value
collect2: error: ld returned 1 exit status


Why is it trying to link with the static library?

Bug#960878: lintian: do not emit override_dh_auto_test-does-not-check-DEB_BUILD_OPTIONS tag for debhelper-compat >= 13

[Baptiste BEAUPLAT]

Package: lintian
Severity: normal

Dear Maintainer,

As the tag description [1] says:

> This check is not required in Debhelper compat level 13 or greater
> (see #568897).

I think lintian should detect if `debhelper-compat >= 13` and skip this
tag if so.

[1]:
https://lintian.debian.org/tags/override_dh_auto_test-does-not-check-DEB_BUILD_OPTIONS.html

Best,
-- 
Baptiste BEAUPLAT - lyknode



signature.asc
Description: OpenPGP digital signature

Bug#960876: bcalm: autopkgtest regression: python: command not found

[Paul Gevers]

Source: bcalm
Version: 2.2.2-1
X-Debbugs-CC: debian...@lists.debian.org
Severity: serious
User: debian...@lists.debian.org
Usertags: regression

Dear maintainer(s),

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

   passfail
bcalm  from testing2.2.2-1
all others from testingfrom testing

I copied some of the output at the bottom of this report. Seems like you
missed that python now needs to be called with a version: python2.

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

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

Paul

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

https://ci.debian.net/data/autopkgtest/testing/amd64/b/bcalm/5517318/log.gz

Finding links between unitigs   19:07:17 memory
[current, maxRSS]: [  80,   80] MB
step 1 pass 0   19:07:17 memory
[current, maxRSS]: [  80,   80] MB
step 2 (0kmers/0extremities)19:07:17 memory
[current, maxRSS]: [  80,   80] MB
step 1 pass 1   19:07:17 memory
[current, maxRSS]: [  80,   80] MB
step 2 (0kmers/0extremities)19:07:17 memory
[current, maxRSS]: [  80,   80] MB
step 1 pass 2   19:07:17 memory
[current, maxRSS]: [  80,   80] MB
step 2 (0kmers/0extremities)19:07:17 memory
[current, maxRSS]: [  80,   80] MB
step 1 pass 3   19:07:17 memory
[current, maxRSS]: [  80,   80] MB
step 2 (0kmers/0extremities)19:07:17 memory
[current, maxRSS]: [  80,   80] MB
step 1 pass 4   19:07:17 memory
[current, maxRSS]: [  80,   80] MB
step 2 (2kmers/2extremities)19:07:17 memory
[current, maxRSS]: [  80,   80] MB
step 1 pass 5   19:07:17 memory
[current, maxRSS]: [  80,   80] MB
step 2 (0kmers/0extremities)19:07:17 memory
[current, maxRSS]: [  80,   80] MB
step 1 pass 6   19:07:17 memory
[current, maxRSS]: [  80,   80] MB
step 2 (0kmers/0extremities)19:07:17 memory
[current, maxRSS]: [  80,   80] MB
step 1 pass 7   19:07:17 memory
[current, maxRSS]: [  80,   80] MB
step 2 (0kmers/0extremities)19:07:17 memory
[current, maxRSS]: [  80,   80] MB
gathering links from disk   19:07:17 memory
[current, maxRSS]: [  80,   80] MB
Done finding links between unitigs  19:07:17 memory
[current, maxRSS]: [  80,   80] MB
simple_test.sh: line 9: python: command not found
test KO



signature.asc
Description: OpenPGP digital signature

Bug#960875: e-antic breaks normaliz autopkgtest: version `LIBEANTICXX_0_1_2' not found (required by /usr/bin/normaliz)

[Paul Gevers]

Source: e-antic, normaliz
Control: found -1 e-antic/0.1.5+ds-1
Control: found -1 normaliz/3.8.3+ds-2
Severity: serious
Tags: sid bullseye
X-Debbugs-CC: debian...@lists.debian.org
User: debian...@lists.debian.org
Usertags: breaks needs-update

Dear maintainer(s),

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

   passfail
e-anticfrom testing0.1.5+ds-1
normaliz   from testing3.8.3+ds-2
all others from testingfrom testing

I copied some of the output at the bottom of this report. I'm not
totally familiar with this error, but doesn't it hint at a forgotten
SONAME bump in e-antic? Or is normaliz doing unconventional loading of
libraries? In the latter case, is a stricter versioned dependency
warranted, or should we rely on autopkgtest to catch issues like this?

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

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

Paul

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

https://ci.debian.net/data/autopkgtest/testing/amd64/n/normaliz/5521842/log.gz
autopkgtest [19:07:43]: test command1: [---
make: Entering directory
'/tmp/autopkgtest-lxc.rk7cc6n6/downtmp/build.Xon/src/test'
/usr/bin/normaliz  -s test-s/mode456
/usr/bin/normaliz: /lib/x86_64-linux-gnu/libeanticxx.so.0: version
`LIBEANTICXX_0_1_2' not found (required by /usr/bin/normaliz)
/usr/bin/normaliz: /lib/x86_64-linux-gnu/libeantic.so.0: version
`LIBEANTIC_0_1_2' not found (required by /usr/bin/normaliz)
/usr/bin/normaliz: /lib/x86_64-linux-gnu/libeantic.so.0: version
`LIBEANTIC_0_1_2' not found (required by
/lib/x86_64-linux-gnu/libnormaliz.so.3)
/usr/bin/normaliz: /lib/x86_64-linux-gnu/libeanticxx.so.0: version
`LIBEANTICXX_0_1_2' not found (required by
/lib/x86_64-linux-gnu/libnormaliz.so.3)
make: *** [Makefile.classic:126: test-s/mode456.out] Error 1
make: Leaving directory
'/tmp/autopkgtest-lxc.rk7cc6n6/downtmp/build.Xon/src/test'
autopkgtest [19:07:43]: test command1: ---]




signature.asc
Description: OpenPGP digital signature

Bug#960874: RM: python-pyst -- RoQA; Depends on Python 2, dead upstream

[Moritz Muehlenhoff]

Package: ftp.debian.org
Severity: normal

Please remove pyst. It's dead upstream, depends on Python 2 and there
are no reverse deps. (Acked by Apollon on IRC)

Cheers,
Moritz

Bug#960873: mothur: autopkgtest regression: Segmentation fault

[Paul Gevers]

Source: mothur
Version: 1.44.0-1
X-Debbugs-CC: debian...@lists.debian.org
Severity: serious
User: debian...@lists.debian.org
Usertags: regression

Dear maintainer(s),

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

   passfail
mothur from testing1.44.0-1
all others from testingfrom testing

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

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

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

Paul

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

https://ci.debian.net/data/autopkgtest/testing/amd64/m/mothur/5517339/log.gz

autopkgtest [19:10:00]: test run-unit-test: [---
TERM environment variable not set.
unique.seqs(fasta=HA.fasta)
command
Linux version

Using ReadLine
mothur v.1.44.0
Last updated: 05/16/2020
by
Patrick D. Schloss

Department of Microbiology & Immunology

University of Michigan
http://www.mothur.org

When using, please cite:
Schloss, P.D., et al., Introducing mothur: Open-source,
platform-independent, community-supported software for describing and
comparing microbial communities. Appl Environ Microbiol, 2009.
75(23):7537-41.

Distributed under the GNU General Public License

Type 'help()' for information on the commands that are available

For questions and analysis support, please visit our forum at
https://forum.mothur.org

Type 'quit()' to exit program

[NOTE]: Setting random seed to 19760620.

Batch Mode


mothur > unique.seqs(fasta=HA.fasta)
599 259

Output File Names:
HA.names
HA.unique.fasta

dist.seqs(fasta=HA.unique.fasta, countends=F, cutoff=0.01)
command

mothur > dist.seqs(fasta=HA.unique.fasta, countends=F, cutoff=0.01)

Using 2 processors.

SequenceTimeNum_Dists_Below_Cutoff
0   0   0
200 0   3443
100 0   5025
258 0   15965
182 0   16617

It took 0 secs to find distances for 259 sequences. 32582 distances
below cutoff 0.01.


Output File Names:
HA.unique.dist

cluster(method=furthest, column=HA.unique.dist, name=HA.names,
cutoff=0.01, precision=1000)
command

mothur > cluster(method=furthest, column=HA.unique.dist, name=HA.names,
cutoff=0.01, precision=1000)

Using 2 processors.
unique  154 211 18  2   6   0   4   2   0   
2   0   0   0   1   0   0   0   0   2   
0   1   0   0   0   0   0   0   0   0   0
0   0   0   0   0   0   0   0   0   0   
0   0   0   1   0   0   0   0   0   0   
0   0   0   0   0   0   0   0   0   0   
0   0   0   0   0   0
0   0   0   0   0   0   0   0   0   0   
0   0   0   0   0   0   0   0   0   0   
0   0   0   0   0   0   0   0   0   0   
0   0   0   0   0   0
0   0   0   0   0   0   0   0   0   0   
0   0   0   0   0   0   0   0   0   0   
0   0   0   0   0   0   0   0   0   0   
0   0   0   0   0   0
0   0   0   0   0   0   0   0   0   0   
0   0   0   0   0   0   1
0.001   155 161 28  5   3   4   2   4   0   
0   1   0   1   0   1   0   0   0   0   
2   0   0   1   0   0   0   0   0   0   
0   0
0   0   0   0   0   0   0   0   0   0   
0   0   0   1   0   0   0   0   0   0   
0   0   0   0   0   0   0   0   0   0   
0   0   0   0   0   0
0   0   0   0   0   0   0   0   0   0   
0   0   0   0   0   0   0   0   0   0   
0   0   0   0   0   0   0   0   0   0   
0   0   0   0   0   0
0   0   0   0   0   0   0   0   0   0   
0   0   0   0   0   0   0   0   0   0   
0   0   0   0   0   0   0   0   0   0   
0   0   0   0   0   0
0   0   0   0   0   0   0   0

Bug#960872: gtkgl2: autopkgtest failure: cc: not found

[Paul Gevers]

Source: gtkgl2
Version: 2.1.0-0.1
X-Debbugs-CC: debian...@lists.debian.org, nico...@debian.org
Severity: serious
User: debian...@lists.debian.org
Usertags: fails-always

Dear maintainer(s), Nicolas,

With a recent upload of gtkgl2 an autopkgtest was added, great. However,
it fails. I copied some of the output at the bottom of this report.
There seems to be missing a test dependency.

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

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

Paul

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

https://ci.debian.net/data/autopkgtest/testing/amd64/g/gtkgl2/5240227/log.gz

autopkgtest [21:18:39]: test link-basic-example: [---
/tmp/autopkgtest-lxc.0adei5av/downtmp/build.N6w/src/debian/tests/link-basic-example:
9: cc: not found
autopkgtest [21:18:39]: test link-basic-example: ---]



signature.asc
Description: OpenPGP digital signature

Bug#956759: libayatana-indicator3 in workrave 1.10.44

[Francois Marier]

On 2020-05-15 at 20:45:38, Kentaro Hayashi wrote:
> Thus, it should be ayatana-indicator3-0.4 instead of indicator3-0.4.

Thanks Kentaro. I have applied your patch and uploaded the latest release.

It has now also been fixed upstream:

  
https://github.com/rcaelers/workrave/commit/3c538c240a2b1c83f6acf338ffdcb8d88f83c267

Francois

-- 
https://fmarier.org/

Bug#934334: munin-plugins-extra: please package asterisk multigraph plugin from munin-contrib

[devel]

Hello,


On Sat, 10 Aug 2019 14:35:34 +0200  wrote:
> At the moment we do not really have a process, how plugins are moved into (or
> out of) munin's core repository (which is used as the base of the Debian
> packging). We will discuss this during our next weekly IRC meeting. [1]

finally we discussed the issue and came to the conclusion, that we want to move
plugins into the core repository only if they are used (or can be maintained)
by one of the munin developers [1].
At the moment the asterisk_* plugins are not used by one of us. Thus we do
not want to move the (working) asterisk plugins from contrib to core.

We recently (munin v2.0.60) removed the really outdated asterisk_* plugins from
core, since they did not work for ~8 years.

Thus at the moment the best approach for using the asterisk plugin is probably
to install them via "munin-get".

This is probably not a satisfying solution, but it is the best we can offer.

Cheers,
Lars


[1] http://meetbot.debian.net/munin/2020/munin.2020-04-29-18.30.log.html

Bug#864603: gufw does not launch

[Dirk]

Package: gufw
Followup-For: Bug #864603

Dear Maintainer,

gufw fails to launch under wayland but launches without issue when using X.org.
I receive a very similar error:

-

No protocol specified
Unable to init server: Could not connect: Connection refused
No protocol specified
Unable to init server: Could not connect: Connection refused

(gufw.py:11170): Gdk-CRITICAL **: 14:14:38.708: gdk_keymap_get_for_display:
assertion 'GDK_IS_DISPLAY (display)' failed

(gufw.py:11170): Gdk-CRITICAL **: 14:14:38.708: gdk_keymap_get_modifier_mask:
assertion 'GDK_IS_KEYMAP (keymap)' failed

(gufw.py:11170): Gdk-CRITICAL **: 14:14:38.708: gdk_keymap_get_for_display:
assertion 'GDK_IS_DISPLAY (display)' failed

(gufw.py:11170): Gtk-CRITICAL **: 14:14:38.708: _gtk_replace_virtual_modifiers:
assertion 'GDK_IS_KEYMAP (keymap)' failed

(gufw.py:11170): Gdk-CRITICAL **: 14:14:38.708: gdk_keymap_get_for_display:
assertion 'GDK_IS_DISPLAY (display)' failed

(gufw.py:11170): Gdk-CRITICAL **: 14:14:38.708: gdk_keymap_get_modifier_mask:
assertion 'GDK_IS_KEYMAP (keymap)' failed

(gufw.py:11170): Gdk-CRITICAL **: 14:14:38.708: gdk_keymap_get_for_display:
assertion 'GDK_IS_DISPLAY (display)' failed

(gufw.py:11170): Gtk-CRITICAL **: 14:14:38.708: _gtk_replace_virtual_modifiers:
assertion 'GDK_IS_KEYMAP (keymap)' failed

(gufw.py:11170): Gdk-CRITICAL **: 14:14:38.708: gdk_keymap_get_for_display:
assertion 'GDK_IS_DISPLAY (display)' failed

(gufw.py:11170): Gdk-CRITICAL **: 14:14:38.708: gdk_keymap_get_modifier_mask:
assertion 'GDK_IS_KEYMAP (keymap)' failed

(gufw.py:11170): Gdk-CRITICAL **: 14:14:38.708: gdk_keymap_get_for_display:
assertion 'GDK_IS_DISPLAY (display)' failed

(gufw.py:11170): Gtk-CRITICAL **: 14:14:38.708: _gtk_replace_virtual_modifiers:
assertion 'GDK_IS_KEYMAP (keymap)' failed

(gufw.py:11170): Gdk-CRITICAL **: 14:14:38.708: gdk_keymap_get_for_display:
assertion 'GDK_IS_DISPLAY (display)' failed

(gufw.py:11170): Gdk-CRITICAL **: 14:14:38.708: gdk_keymap_get_modifier_mask:
assertion 'GDK_IS_KEYMAP (keymap)' failed

(gufw.py:11170): Gdk-CRITICAL **: 14:14:38.708: gdk_keymap_get_for_display:
assertion 'GDK_IS_DISPLAY (display)' failed

(gufw.py:11170): Gtk-CRITICAL **: 14:14:38.708: _gtk_replace_virtual_modifiers:
assertion 'GDK_IS_KEYMAP (keymap)' failed

(gufw.py:11170): Gdk-CRITICAL **: 14:14:38.708: gdk_keymap_get_for_display:
assertion 'GDK_IS_DISPLAY (display)' failed

(gufw.py:11170): Gdk-CRITICAL **: 14:14:38.708: gdk_keymap_get_modifier_mask:
assertion 'GDK_IS_KEYMAP (keymap)' failed

(gufw.py:11170): Gdk-CRITICAL **: 14:14:38.708: gdk_keymap_get_for_display:
assertion 'GDK_IS_DISPLAY (display)' failed

(gufw.py:11170): Gtk-CRITICAL **: 14:14:38.708: _gtk_replace_virtual_modifiers:
assertion 'GDK_IS_KEYMAP (keymap)' failed

(gufw.py:11170): Gdk-CRITICAL **: 14:14:38.708: gdk_keymap_get_for_display:
assertion 'GDK_IS_DISPLAY (display)' failed

(gufw.py:11170): Gdk-CRITICAL **: 14:14:38.709: gdk_keymap_get_modifier_mask:
assertion 'GDK_IS_KEYMAP (keymap)' failed

(gufw.py:11170): Gdk-CRITICAL **: 14:14:38.709: gdk_keymap_get_for_display:
assertion 'GDK_IS_DISPLAY (display)' failed

(gufw.py:11170): Gtk-CRITICAL **: 14:14:38.709: _gtk_replace_virtual_modifiers:
assertion 'GDK_IS_KEYMAP (keymap)' failed

(gufw.py:11170): Gdk-CRITICAL **: 14:14:38.709: gdk_keymap_get_for_display:
assertion 'GDK_IS_DISPLAY (display)' failed

(gufw.py:11170): Gdk-CRITICAL **: 14:14:38.709: gdk_keymap_get_modifier_mask:
assertion 'GDK_IS_KEYMAP (keymap)' failed

(gufw.py:11170): Gdk-CRITICAL **: 14:14:38.709: gdk_keymap_get_for_display:
assertion 'GDK_IS_DISPLAY (display)' failed

(gufw.py:11170): Gtk-CRITICAL **: 14:14:38.709: _gtk_replace_virtual_modifiers:
assertion 'GDK_IS_KEYMAP (keymap)' failed

(gufw.py:11170): Gdk-CRITICAL **: 14:14:38.709: gdk_keymap_get_for_display:
assertion 'GDK_IS_DISPLAY (display)' failed

(gufw.py:11170): Gdk-CRITICAL **: 14:14:38.709: gdk_keymap_get_modifier_mask:
assertion 'GDK_IS_KEYMAP (keymap)' failed

(gufw.py:11170): Gdk-CRITICAL **: 14:14:38.709: gdk_keymap_get_for_display:
assertion 'GDK_IS_DISPLAY (display)' failed

(gufw.py:11170): Gtk-CRITICAL **: 14:14:38.709: _gtk_replace_virtual_modifiers:
assertion 'GDK_IS_KEYMAP (keymap)' failed

(gufw.py:11170): Gdk-CRITICAL **: 14:14:38.709: gdk_keymap_get_for_display:
assertion 'GDK_IS_DISPLAY (display)' failed

(gufw.py:11170): Gdk-CRITICAL **: 14:14:38.709: gdk_keymap_get_modifier_mask:
assertion 'GDK_IS_KEYMAP (keymap)' failed

(gufw.py:11170): Gdk-CRITICAL **: 14:14:38.709: gdk_keymap_get_for_display:
assertion 'GDK_IS_DISPLAY (display)' failed

(gufw.py:11170): Gtk-CRITICAL **: 14:14:38.709: _gtk_replace_virtual_modifiers:
assertion 'GDK_IS_KEYMAP (keymap)' failed

(gufw.py:11170): Gdk-CRITICAL **: 14:14:38.709: gdk_keymap_get_for_display:
assertion 'GDK_IS_DISPLAY (display)' failed

(gufw.py:11170): Gdk-CRITICAL **: 14:14:38.709: gdk_keymap_get_modifier_mask:
assertion 'GDK_IS_KEYMAP (keymap)' failed

(gufw.py:11170): 

Bug#960802: apt: Feature Request: filter regexes from search using -'[regex]'

[Julian Andres Klode]

On Sat, May 16, 2020 at 02:40:12PM -0500, chris wrote:
> Package: apt
> Version: 2.0.2ubuntu0.1
> Severity: wishlist
> 
>* I ran 'apt search cura' to look for the package Cura. The command 
> returned several irrelevant packages whose name begins with 'python-'.
>* I ran 'apt search cura -"python"' to see if it would exclude packages 
> whose name contains "python".
>* The command returned an error. I also looked through the apt manpage to 
> see if an equivalent function exists, and I didn't see one.
>* It would be nice to have the ability to filter out certain strings such 
> as "python" or "lib" when searching for packages. This would cut out a lot of 
> scrolling.
> 

I'm against introducing more ad-hoc syntax. We're working on patterns which can 
query all sorts of things,
and has logic combinators, see apt-patterns(7). That said, description 
searching, and use in search are not
available yet.

There are also various issues with syntax like that:

* - starts a short option (which is why install uses foo- for removal)
* how do I differentiate the regex "-apt" from "not" the regex "apt"


Patterns solve this, but might be a bit more inconvenient

apt search "~ncura !~npython" for searching names
- short for '?and(?name(cura),?not(?name(python))'

Neither solution is intuitive, but at least people know the patterns from
aptitude already :)

-- 
debian developer - deb.li/jak | jak-linux.org - free software dev
ubuntu core developer  i speak de, en

Bug#960867: fs-uae-launcher: The application crash every time at the beginning

[John Paul Adrian Glaubitz]

Control: tags -1 moreinfo

Hello!

On 5/17/20 7:57 PM, Davide Lombardo wrote:
> [I18N] Initialize_locale language = 
> [I18N] Locale is en_GB
> [I18N] Checking /usr/bin/share/fs-uae-launcher/share-dir
> [I18N] Checking /usr/bin/../share/fs-uae-launcher/share-dir
> [I18N] bindtextdomain fs-uae-launcher: /usr/bin/../share/locale
> [I18N] find translations for en_GB in local directory /usr/bin/../share/locale
> [I18N] Path to mo file: None
> [I18N] Translations object:  0x7fd7ddc11eb8>
> corrupted size vs. prev_size in fastbins
> KCrash: crashing... crashRecursionCounter = 2
> KCrash: Application Name = python3.7 path = /usr/bin pid = 7000
> KCrash: Arguments: 
> Alarm clock   

The error message "corrupted size vs. prev_size in fastbins" indicates a crash 
in the
C library which can normally not happen when Python code is executed. So I'm not
sure this is actually a bug in fs-uae-launcher, it looks more like a problem
with gettext.

You can try to install fs-uae from stable-backports and see if that helps.

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

Bug#960869: python3: python package does not depend on ca-certificates

[Christian Heimes]

Package: python3
Version: 3.7.3-1
Severity: important

Dear Maintainer,

Python has no dependency on ca-certificates. Installing Python on a
minimal Debian or Ubuntu container image does not pull in ca-certificates.
This results in certificate validation issues as no trust anchors are
available. Python's ssl module and ssl.create_default_context() depend
on default root CA packages being available.

Reproducer:

# docker run -ti debian:buster /bin/bash
# apt-get update
# apt-get install python3
# ls -la /etc/ssl/certs/ca-certificates.crt
ls: cannot access '/etc/ssl/certs/ca-certificates.crt': No such file or 
directory
# dpkg -l ca-certificates
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
+++-===---=
un  ca-certificates   (no description available)

Proposed solution:
Either all Python interpreter packages or libssl should pull in
ca-certificates.

Christian

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

Kernel: Linux 5.6.11-300.fc32.x86_64 (SMP w/8 CPU cores)
Locale: LANG=C, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE=C (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: unable to detect

Versions of packages python3 depends on:
ii  libpython3-stdlib  3.7.3-1
ii  python3-minimal3.7.3-1
ii  python3.7  3.7.3-2+deb10u1

python3 recommends no packages.

Versions of packages python3 suggests:
pn  python3-doc   
pn  python3-tk
pn  python3-venv  

-- no debconf information

Bug#958721: perlbug and github

[Dominic Hargreaves]

On Fri, Apr 24, 2020 at 08:47:07PM +0300, Niko Tyni wrote:
> Package: perl
> Version: 5.28.1-6
> Severity: normal
> Tags: buster fixed-upstream
> Forwarded: https://github.com/Perl/perl5/issues/17197
> Control: found -1 5.30.0-10
> 
> The upstream tool to submit bug reports, /usr/bin/perlbug, does not
> currently work as advertised since upstream has moved from rt.perl.org
> to github.com/Perl/perl5 . It send the report to the old bug submission
> address perl...@perl.org, which (I believe) nowadays gives an autoresponse
> suggesting to file a GitHub issue instead.
> 
> Upstream has recently addressed this: 5.30.2 has
> 
>  https://github.com/Perl/perl5/commit/b9e2183386fadc0979b46e024365ceab56a369aa
> 
> removing references to perlbug,

I don't think this is addressing it at all. As jidanni points out in the
issue you reference below, the manpage for perlbug should point out that
it's doing the wrong thing at the very least. I would probably have used
perlbug myself the next time I needed to file a report with diagnostics,
even though I know that upstream has moved to github.

> and upcoming 5.31.11 will have
> 
>  https://github.com/Perl/perl5/commit/31fa749cfc50ff7f2bde2237bf6da5547efd53d4
> 
> which modifies the perlbug tool to save its output to a file and direct
> users to the GitHub issue tracker. 

I think we should backport this to all supported versions of perl in
Debian.

Then again, we should probably also teach that tool that in many cases
we prefer to receive reports at the BTS...

> The upstream issue at
> 
>  https://github.com/Perl/perl5/issues/17197
> 
> has the full discussion.
> 
> While I expect this will be fixed in Debian bullseye by upgrading to 5.32,
> we should probably do something about stable too.

Indeed. Had I remembered about this bug earlier I would have probably
tried to do something for the 5.30.2-1 upload.

Dominic

Bug#960868: Mention if --recon meant reconnaissance

[積丹尼 Dan Jacobson]

Package: apt
Version: 2.1.2
Severity: wishlist
File: /usr/share/man/man8/apt-get.8.gz

We read
   -s, --simulate, --just-print, --dry-run, --recon, --no-act

That is great, except for --recon.

The user wonders what it is short for.

So please in the sentence that follows it, mention what the meaning of
it originally was. "Do reconnaissance only"?

Bug#960867: fs-uae-launcher: The application crash every time at the beginning

[Davide Lombardo]

Package: fs-uae-launcher
Version: 2.8.4+dfsg-2
Severity: grave
Justification: renders package unusable

Dear Maintainer,

 The program crash at the beginning of the execution and print this 
outputin my console:
 
$ fs-uae-launcher
2.8.3
enabling except hook
enable tread exception handler
uname_result(system='Linux', node='PC0', release='4.19.0-9-amd64', version='#1 
SMP Debian 4.19.118-2 (2020-04-29)', machine='x86_64', processor='')
['/usr/bin/fs-uae-launcher']
FS-UAE Launcher 2.8.3
Traceback (most recent call last):
  File "/usr/share/fs-uae-launcher/fsgs/Archive.py", line 9, in 
from lhafile import LhaFile
ModuleNotFoundError: No module named 'lhafile'
LhaFile module import problem
[SETTINGS] Constructor 
[SETTINGS] No settings path specified
[SETTINGS] Using default /home/davide/Documents/FS-UAE/Data/Settings.ini
[SETTINGS] File /home/davide/Documents/FS-UAE/Data/Settings.ini does not exist
[I18N] Initialize_locale language = 
[I18N] Locale is en_GB
[I18N] Checking /usr/bin/share/fs-uae-launcher/share-dir
[I18N] Checking /usr/bin/../share/fs-uae-launcher/share-dir
[I18N] bindtextdomain fs-uae-launcher: /usr/bin/../share/locale
[I18N] find translations for en_GB in local directory /usr/bin/../share/locale
[I18N] Path to mo file: None
[I18N] Translations object: 
corrupted size vs. prev_size in fastbins
KCrash: crashing... crashRecursionCounter = 2
KCrash: Application Name = python3.7 path = /usr/bin pid = 7000
KCrash: Arguments: 
Alarm clock   
   

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

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

Versions of packages fs-uae-launcher depends on:
ii  fs-uae  2.8.4+dfsg-2
ii  python3 3.7.3-1
ii  python3-pyqt5   5.11.3+dfsg-1+b3
ii  python3-pyqt5.qtopengl  5.11.3+dfsg-1+b3
ii  python3-setuptools  40.8.0-1

fs-uae-launcher recommends no packages.

fs-uae-launcher suggests no packages.

-- no debconf information

Bug#960372: schroedinger-coordgenlibs transition is complete

[merkys]

Hello,

schroedinger-coordgenlibs transition seems to be complete. All related
packages had been rebuilt, and have already migrated to testing. I
suppose transition bug can now be closed.

Best,
Andrius

Bug#936557: freeorion: Python2 removal in sid/bullseye

[Fedja Beader]

Why does this bug still exist?

I was able to build headless Freeorion on Devuan with Python 3 just by changing 
the control file (see 
https://framagit.org/specing/debian-freeorion/-/commit/948beb224601838163bf7c9bea4d8bcf677dcb8d).
 It seems that Freeorion migrated from Python 2 a long time ago?

Bug#845772: libconfig-jfdi-perl: uses deprecated Any::Moose

[gregor herrmann]

On Sun, 17 May 2020 14:03:42 +0200, intrigeri wrote:

> I propose we remove both libconfig-jfdi-perl and libmojomojo-perl
> from the archive.

Given the popcon values of the packages, I see no problem with
removing them.


Cheers,
gregor

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


signature.asc
Description: Digital Signature

Bug#960702: [PATCH net] mlx4: Fix information leak on failure to read module EEPROM

[Ben Hutchings]

mlx4_en_get_module_eeprom() returns 0 even if it fails.  This results
in copying an uninitialised (or partly initialised) buffer back to
user-space.

Change it so that:

* In the special case that the DOM turns out not to be readable, the
  remaining part of the buffer is cleared.  This should avoid a
  regression when reading modules with this problem.

* In other error cases, the error code is propagated.

Reported-by: Yannis Aribaud 
References: https://bugs.debian.org/960702
Fixes: 7202da8b7f71 ("ethtool, net/mlx4_en: Cable info, get_module_info/...")
Signed-off-by: Ben Hutchings 
---
This is compile-tested only.  It should go to stable, if it is a
correct fix.

Ben.

 drivers/net/ethernet/mellanox/mlx4/en_ethtool.c | 7 +--
 1 file changed, 5 insertions(+), 2 deletions(-)

diff --git a/drivers/net/ethernet/mellanox/mlx4/en_ethtool.c 
b/drivers/net/ethernet/mellanox/mlx4/en_ethtool.c
index 8a5ea2543670..6edc3177af1c 100644
--- a/drivers/net/ethernet/mellanox/mlx4/en_ethtool.c
+++ b/drivers/net/ethernet/mellanox/mlx4/en_ethtool.c
@@ -2078,14 +2078,17 @@ static int mlx4_en_get_module_eeprom(struct net_device 
*dev,
ret = mlx4_get_module_info(mdev->dev, priv->port,
   offset, ee->len - i, data + i);
 
-   if (!ret) /* Done reading */
+   if (!ret) {
+   /* DOM was not readable after all */
+   memset(data + i, 0, ee->len - i);
return 0;
+   }
 
if (ret < 0) {
en_err(priv,
   "mlx4_get_module_info i(%d) offset(%d) 
bytes_to_read(%d) - FAILED (0x%x)\n",
   i, offset, ee->len - i, ret);
-   return 0;
+   return ret;
}
 
i += ret;


signature.asc
Description: PGP signature

Bug#960866: libnewlib-nano FTBFS with meson 0.54.2-1

[Adrian Bunk]

Source: libnewlib-nano
Version: 2.11.2-1
Severity: serious
Tags: ftbfs bullseye sid

https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/libnewlib-nano.html

...
Configuring newlib.h using configuration
Configuring _newlib_version.h using configuration
meson.build:187: WARNING: Consider using the built-in debug option instead of 
using "-g".
meson.build:187: WARNING: Consider using the built-in optimization level 
instead of using "-Os".
WARNING: Target "arm_v5te_softfp/libc" has a path separator in its name.
This is not supported, it can cause unexpected failures and will become
a hard error in the future.
WARNING: Target "arm_v5te_hard/libc" has a path separator in its name.
This is not supported, it can cause unexpected failures and will become
a hard error in the future.
WARNING: Target "thumb_nofp/libc" has a path separator in its name.
This is not supported, it can cause unexpected failures and will become
a hard error in the future.
WARNING: Target "thumb_v7_nofp/libc" has a path separator in its name.
This is not supported, it can cause unexpected failures and will become
a hard error in the future.
WARNING: Target "thumb_v7_fp_softfp/libc" has a path separator in its name.
This is not supported, it can cause unexpected failures and will become
a hard error in the future.
WARNING: Target "thumb_v7_fp_hard/libc" has a path separator in its name.
This is not supported, it can cause unexpected failures and will become
a hard error in the future.
WARNING: Target "thumb_v6_m_nofp/libc" has a path separator in its name.
This is not supported, it can cause unexpected failures and will become
a hard error in the future.
WARNING: Target "thumb_v7_m_nofp/libc" has a path separator in its name.
This is not supported, it can cause unexpected failures and will become
a hard error in the future.
WARNING: Target "thumb_v7e_m_nofp/libc" has a path separator in its name.
This is not supported, it can cause unexpected failures and will become
a hard error in the future.
WARNING: Target "thumb_v7e_m_fp_softfp/libc" has a path separator in its name.
This is not supported, it can cause unexpected failures and will become
a hard error in the future.
WARNING: Target "thumb_v7e_m_fp_hard/libc" has a path separator in its name.
This is not supported, it can cause unexpected failures and will become
a hard error in the future.
WARNING: Target "thumb_v7e_m_dp_softfp/libc" has a path separator in its name.
This is not supported, it can cause unexpected failures and will become
a hard error in the future.
WARNING: Target "thumb_v7e_m_dp_hard/libc" has a path separator in its name.
This is not supported, it can cause unexpected failures and will become
a hard error in the future.
WARNING: Target "thumb_v8_m_base_nofp/libc" has a path separator in its name.
This is not supported, it can cause unexpected failures and will become
a hard error in the future.
WARNING: Target "thumb_v8_m_main_nofp/libc" has a path separator in its name.
This is not supported, it can cause unexpected failures and will become
a hard error in the future.
WARNING: Target "thumb_v8_m_main_fp_softfp/libc" has a path separator in its 
name.
This is not supported, it can cause unexpected failures and will become
a hard error in the future.
WARNING: Target "thumb_v8_m_main_fp_hard/libc" has a path separator in its name.
This is not supported, it can cause unexpected failures and will become
a hard error in the future.
WARNING: Target "thumb_v8_m_main_dp_softfp/libc" has a path separator in its 
name.
This is not supported, it can cause unexpected failures and will become
a hard error in the future.
WARNING: Target "thumb_v8_m_main_dp_hard/libc" has a path separator in its name.
This is not supported, it can cause unexpected failures and will become
a hard error in the future.
WARNING: Target "arm_v5te_softfp/libm" has a path separator in its name.
This is not supported, it can cause unexpected failures and will become
a hard error in the future.
WARNING: Target "arm_v5te_hard/libm" has a path separator in its name.
This is not supported, it can cause unexpected failures and will become
a hard error in the future.
WARNING: Target "thumb_nofp/libm" has a path separator in its name.
This is not supported, it can cause unexpected failures and will become
a hard error in the future.
WARNING: Target "thumb_v7_nofp/libm" has a path separator in its name.
This is not supported, it can cause unexpected failures and will become
a hard error in the future.
WARNING: Target "thumb_v7_fp_softfp/libm" has a path separator in its name.
This is not supported, it can cause unexpected failures and will become
a hard error in the future.
WARNING: Target "thumb_v7_fp_hard/libm" has a path separator in its name.
This is not supported, it can cause unexpected failures and will become
a hard error in the future.
WARNING: Target "thumb_v6_m_nofp/libm" has a path separator in its name.
This is not supported, it can cause unexpected failures and will become
a hard error 

Bug#960864: libapp-perlrdf-command-query-perl: uses deprecated Any::Moose

[intrigeri]

Package: libapp-perlrdf-command-query-perl
Version: 0.004-2
Severity: normal
User: debian-p...@lists.debian.org
Usertags: any-moose
Forwarded: https://github.com/tobyink/p5-app-perlrdf-command-query/issues/1

Hi Jonas & all,

see the upstream issue I've just filed.

I understand this bug could be fixed by removing 1 occurrence of "Any::" in the
upstream source code, and then dropping the dependency on libany-moose-perl.

This being said, this package was removed from testing 2.5 years ago
along with perlrdf, so this could be an opportunity to question whether
we should keep it in the archive :)

Cheers!

Bug#960624: rename bug

[Dominic Hargreaves]

Control: tags -1 + wontfix

On Thu, May 14, 2020 at 08:55:37PM +0200, m...@ft-c.de wrote:
> The rename command doesn't work from another directory, when there is a "^"
> (beginn-line) in the regular-expression.
> 
> # script beginn - - - - -
> $ uname -a
> Linux ftd2 4.15.0-3-amd64 #1 SMP Debian 4.15.17-1 (2018-04-19) x86_64
> GNU/Linux
> $ rename -V
> /usr/bin/rename using File::Rename version 1.10
> 
> $ mkdir test
> $ cd test/
> /test$ touch Film-filmtitle1.txt
> /test$ cd ..
> $ mkdir test2
> $ cd test2
> 
> /test2$ rename -v -e 's/^Film-//eg' ~/skripte/test/*
> 
> /test2$ ls -l ~/skripte/test/*
> -rw-r--r-- 1 ft ft 0 Mai 12 00:48 /./test/Film-filmtitle1.txt
> 
> /test2$ cd ../test
> 
> /test$ rename -v -e 's/^Film-//eg' *
> Use of uninitialized value in substitution iterator at (eval 8) line 1.
> Film-filmtitle1.txt renamed as filmtitle1.txt
> 
> /test$ ls -l *
> -rw-r--r-- 1 ft ft 0 Mai 12 00:48 filmtitle1.txt
> 
> # script end - - - - -
> 
> In the script, the first rename command have no result/output,
> the second rename command there is a result.

This is as I would expect; the tool takes the filenames passed to it
as input, so ^ matches the start of the whole path. I can see that
a different behaviour would be convenient in many cases, but it would
also be a breaking change to the interface, so it's not a change that
we could make without it being protected by a flag.

Quoting from the manpage, this seems fairly clear:

"rename" renames the filenames supplied according to the rule specified
as the first argument

If you are interested in taking this forward as a feature proposal, this
is something that should be done upstream - by filing a bug here:
. However
it would change the nature of the program, and I'm not at all sure that
the author would want to pursue this. Instead, you could consider
writing a regular expression that actually matches what you want - to
match 'Film' appearing after the final '/' - or, for simplicity, after
any '/'?

Cheers
Dominic

Bug#960863: perl-tk: new upstream release fixes issues with Perl 5.31.x

[Niko Tyni]

Package: perl-tk
Version: 1:804.033-2
Severity: wishlist

Hi,

although Perl 5.32 is not released yet, we've just started early
testing against the archive during our online Debian Perl Sprint.
One of the issues we noticed is that the current perl-tk version in sid
is incompatible with newer versions of Perl, causing build failures with
perl-tk reverse dependencies.

The problem is fixed upstream in the 804.035 release according to
the changelog. Importing that into Debian would help our testing
efforts. Please consider doing that, and let us know if you'd like
any help.

Thanks for your work on Debian,
-- 
Niko Tyni   nt...@debian.org

Bug#960862: NotImplementedError:

[Picca Frédéric-Emmanuel]

Package: silver-platter
Version: 0.3.0+git20200516.9f9af15-1
Severity: normal

Hello when I try to log to salsa.debian.org, I get this error message

$ svp login https://salsa.debian.org
Traceback (most recent call last):
  File "/usr/bin/svp", line 11, in 
load_entry_point('silver-platter==0.3.0', 'console_scripts', 'svp')()
  File "/usr/lib/python3/dist-packages/silver_platter/__main__.py", line 121, 
in main
return callbacks[args.subcommand](args)
  File "/usr/lib/python3/dist-packages/silver_platter/__main__.py", line 65, in 
login_main
return cmd.run(args.url)
  File "/usr/lib/python3/dist-packages/breezy/commands.py", line 784, in run
return self._operation.run_simple(*args, **kwargs)
  File "/usr/lib/python3/dist-packages/breezy/cleanup.py", line 136, in 
run_simple
return _do_with_cleanups(
  File "/usr/lib/python3/dist-packages/breezy/cleanup.py", line 166, in 
_do_with_cleanups
result = func(*args, **kwargs)
  File "/usr/lib/python3/dist-packages/breezy/plugins/propose/cmds.py", line 
306, in run
private_token = ui.ui_factory.get_password(u'Private token')
  File "/usr/lib/python3/dist-packages/breezy/ui/__init__.py", line 239, in 
get_password
raise NotImplementedError(self.get_password)
NotImplementedError: 

Cheers


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

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

Versions of packages silver-platter depends on:
ii  brz-debian2.8.35
ii  devscripts2.20.3
ii  lintian-brush 0.64
ii  python3   3.8.2-3
ii  python3-breezy3.0.2-5+b1
ii  python3-distro-info   0.23
ii  python3-dulwich   0.19.15-1+b1
ii  python3-github1.43.7-1
ii  python3-gitlab1:2.2.0-1
ii  python3-launchpadlib  1.10.13-1
ii  python3-testtools 2.3.0-7
ii  python3-yaml  5.3.1-2

Versions of packages silver-platter recommends:
ii  brz  3.0.2-5

silver-platter suggests no packages.

-- no debconf information

Bug#959840: dbus-daemon: random crash (SIGABRT)

[Michael Biebl]

Control: found -1 245.5-2

On Wed, 06 May 2020 10:06:54 +0800 Paul Wise  wrote:
> Package: dbus
> Version: 1.12.16-2
> Severity: normal
> File: /usr/bin/dbus-daemon
> Usertags: crash
> 
> The last few days I have been getting dbus-daemon crashing randomly
> with SIGABRT. I don't know how to reproduce this, so if the below
> backtrace isn't useful, please close this bug.
> 

Paul, would you mind filing this upstream at

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



signature.asc
Description: OpenPGP digital signature

Bug#934135: Bug#934135: aptitude: depends on libparse-debianchangelog-perl that has no upstream maintainer

[Axel Beckert]

Control: clone -1 -2 aptitude FTBFS with new po4a
Control: reassign -2 src:aptitude 0.8.12-3
Control: severity -2 serious
Control: tag -2 = ftbfs

Hi,

one more thing:

intrigeri wrote:
> I have applied Guillem's patch and fixed the typo mentioned below, on
> top of current sid's 0.8.12-3

You also need to remove the hunk which modifies debian/control. Doing
that from debian/patches is bad.

> (after disabling the build of doc translations as this makes the
> package FTBFS for me with current po4a; same on the Reproducible
> Builds infra¹),

Worked for me last weekend. But indeed, it FTBFS now. Hence
documenting it. Will fix that, too.

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

___
Aptitude-devel mailing list
aptitude-de...@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/aptitude-devel

Bug#960861: barnowl: unnecessarily build-depends on the deprecated Any::Moose

[intrigeri]

Package: barnowl
Version: 1.10-1
Severity: normal
User: debian-p...@lists.debian.org
Usertags: any-moose

Hi Sam,

the Any::Moose Perl module has been deprecated since more than 5 years.
For more details, see http://shadow.cat/blog/matt-s-trout/moo-versus-any-moose/

I see that barnowl build-depends on libany-moose-perl. In the source tree I see
that the code under perl/modules/Facebook/lib/Facebook indeed uses Any::Moose.
But that code is not installed by the binary package.
And indeed, the good news is that src:barnowl appears to build just fine without
libany-moose-perl.

So I propose the following course of action:

1. Remove the unnecessary build dependency on libany-moose-perl

   That would be enough to close this bug and make my cleanup work,
   as a member of the Debian Perl group, easier :)

2. Let upstream know about the deprecated dependency.

   Switching from Any::Moose to Moose should be a simple string search &
   replace.

   Another option would be to migrate to Moo, but that's probably a bit more
   involved; the main benefit would be faster startup of the app, which
   I suppose does not matter much for an app that's primarily meant to run for
   a long while, e.g. in GNU Screen or similar.

Bug#960860: pcsx2: 1.7.0 released

[Beta Version]

Package: pcsx2
Version: 1.5.0~gfc1d9aef0+dfsg-2
Severity: wishlist

Dear Maintainer, please, update PCSX2 to 1.7.0.



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

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

Versions of packages pcsx2 depends on:
ii  libaio1   0.3.112-8
ii  libasound21.2.2-2.1
ii  libc6 2.30-8
ii  libfreetype6  2.10.1-2
ii  libgcc-s1 10.1.0-1
ii  libgdk-pixbuf2.0-02.40.0+dfsg-4
ii  libgl11.3.1-1
ii  libgl1-mesa-dri   20.0.6-1
ii  libglib2.0-0  2.64.2-1
ii  libgtk-3-03.24.20-1
ii  liblzma5  5.2.4-1+b1
ii  libpng16-16   1.6.37-2
ii  libportaudio2 19.6.0-1
ii  libsdl2-2.0-0 2.0.10+dfsg1-3
ii  libsoundtouch12.1.2+ds1-1
ii  libstdc++610.1.0-1
ii  libudev1  245.5-2
ii  libwxbase3.0-0v5  3.0.5.1+dfsg-1
ii  libwxgtk3.0-gtk3-0v5  3.0.5.1+dfsg-1
ii  libx11-6  2:1.6.9-2+b1
ii  zlib1g1:1.2.11.dfsg-2

Versions of packages pcsx2 recommends:
ii  libasound2-plugins  1.2.2-1
ii  libc6 [libc6-i686]  2.30-8

pcsx2 suggests no packages.

-- no debconf information

Bug#960859: node-clipboard: broken symlink to /usr/share/javascript/clipboard.js

[Doug Torrance]

Package: node-clipboard
Version: 2.0.6+ds-2
Severity: important
Tags: patch

Dear Maintainer,

There is a typo in debian/links which causes a broken symlink:

profzoom@gloria:~$ test -e /usr/share/javascript/clipboard.js; echo $?
1
profzoom@gloria:~$ ls -l /usr/share/javascript/clipboard.js
lrwxrwxrwx 1 root root 24 May 10 04:42 /usr/share/javascript/clipboard.js 
-> ../nodejs/clibboard/dist

In particular, "clipboard" is misspelled as "clibboard".

I have submitted a merge request at Salsa [1] and have attached a patch.

Thanks!
Doug

[1] https://salsa.debian.org/js-team/node-clipboard/-/merge_requests/1
>From 2bc8ed1bbba19dea16bd82b711125b20ac5eff7c Mon Sep 17 00:00:00 2001
From: Doug Torrance 
Date: Wed, 13 May 2020 22:41:22 -0400
Subject: [PATCH] Fix typo

---
 debian/links | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/debian/links b/debian/links
index 1303eb0..eaf4159 100644
--- a/debian/links
+++ b/debian/links
@@ -1 +1 @@
-/usr/share/nodejs/clibboard/dist /usr/share/javascript/clipboard.js
+/usr/share/nodejs/clipboard/dist /usr/share/javascript/clipboard.js
-- 
2.20.1

Bug#950455: Bug#960807: Bug#950455: Don't emit override_dh_auto_test-does-not-check-DEB_BUILD_OPTIONS with debhelper 13

[Felix Lechner]

Hi Chris,

On Sat, May 16, 2020 at 4:03 PM Chris Lamb  wrote:
>
> > > Making it "just" a library method is not that straightforward either
> > > as the code in debhelper.pm also finds and reports on conflicting/
> > > broken numbers, etc.

I have a branch that separates scanning from diagnostics. It solves
this dilemma. Please look out for a 'lab scan' facility in the near
future. The terminology corresponds to the interaction between a
doctor and a blood lab. Lintian checks function like a doctor that
issues a diagnosis based on lab results.

The low-level scan results will become much more abundant and provide
all kinds of data to consumers like Lintian Brush. They will replace
classification tags.

Kind regards

Felix Lechner

Bug#960858: libmousex-types-perl: uses deprecated Any::Moose

[intrigeri]

Package: libmousex-types-perl
Version: 0.06-2
Severity: normal
User: debian-p...@lists.debian.org
Usertags: any-moose
Forwarded: https://github.com/yappo/p5-mousex-types/issues/5

Also on CPAN RT: https://rt.cpan.org/Ticket/Display.html?id=104943

I've just poked upstream on their GitHub.

Bug#959883: gnome-shell: randomly crashes: segfaults and restarts

[debian-edid]

Hi,

Same problem here:

        gnome-shell[1153]: segfault at 0 ip 7f989dac846a sp 
7ffc28aef5a0 error 4 in libst-1.0.so[7f989daa9000+4a000]


Still no gnome-shell 3.36.2 update even in sid



Regards,
Edi D

Bug#957318: gtick: ftbfs with GCC-10

[Roland Reichwein]

Hi!

I'm attaching a patch that fixes this problem by adding a necessary 
"extern" and re-generating flex and bison generated files.


Thanks for reporting this!

Roland.
diff -ruN temp/gtick-0.5.4/debian/changelog gtick-0.5.4/debian/changelog
--- gtick-0.5.4/debian/changelog	2014-07-27 19:45:03.0 +0200
+++ gtick-0.5.4/debian/changelog	2020-05-17 12:39:58.174598751 +0200
@@ -1,3 +1,10 @@
+gtick (0.5.4-2) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix FTBFS with gcc-10 (Closes: #957318)
+
+ -- Roland Reichwein   Sun, 17 May 2020 12:38:49 +0200
+
 gtick (0.5.4-1) unstable; urgency=medium
 
   * New upstream release
diff -ruN temp/gtick-0.5.4/debian/clean gtick-0.5.4/debian/clean
--- gtick-0.5.4/debian/clean	1970-01-01 01:00:00.0 +0100
+++ gtick-0.5.4/debian/clean	2020-05-17 12:38:41.071956679 +0200
@@ -0,0 +1,3 @@
+src/optionlexer.c
+src/optionparser.h
+src/optionparser.c
diff -ruN temp/gtick-0.5.4/debian/control gtick-0.5.4/debian/control
--- gtick-0.5.4/debian/control	2014-06-22 16:45:48.0 +0200
+++ gtick-0.5.4/debian/control	2020-05-17 12:36:32.35602 +0200
@@ -2,7 +2,7 @@
 Section: sound
 Priority: extra
 Maintainer: Roland Stigge 
-Build-Depends: debhelper (>= 9), libgtk2.0-dev, libsndfile1-dev, libpulse-dev
+Build-Depends: debhelper (>= 9), libgtk2.0-dev, libsndfile1-dev, libpulse-dev, flex, bison
 Standards-Version: 3.9.5
 Homepage: http://www.antcom.de/gtick/
 
diff -ruN temp/gtick-0.5.4/debian/patches/fix-multiple-definition.patch gtick-0.5.4/debian/patches/fix-multiple-definition.patch
--- gtick-0.5.4/debian/patches/fix-multiple-definition.patch	1970-01-01 01:00:00.0 +0100
+++ gtick-0.5.4/debian/patches/fix-multiple-definition.patch	2020-05-17 12:44:30.389809211 +0200
@@ -0,0 +1,19 @@
+Description: Fix multiple definition of option_lloc
+ This patch fixes the multiple definition of iotion_lloc by adding
+ a missing "extern" and regenerating flex and bison generated files.
+ Under debian/, build dependencies to flex and bison have been added
+ and debian/clean now removes the old generated files.
+Author: Roland Reichwein 
+Bug-Debian: https://bugs.debian.org/957318
+
+--- gtick-0.5.4.orig/src/optionlexer.l
 gtick-0.5.4/src/optionlexer.l
+@@ -40,7 +40,7 @@
+ #include "optionlexer.h"
+ 
+ char* option_filename;
+-YYLTYPE option_lloc;
++extern YYLTYPE option_lloc;
+ 
+ void option_locate();
+ %}
diff -ruN temp/gtick-0.5.4/debian/patches/series gtick-0.5.4/debian/patches/series
--- gtick-0.5.4/debian/patches/series	1970-01-01 01:00:00.0 +0100
+++ gtick-0.5.4/debian/patches/series	2020-05-17 12:41:04.537430472 +0200
@@ -0,0 +1 @@
+fix-multiple-definition.patch