Bug#945123: lasso builds for python3.8, but only installs the extension for 3.7

[Matthias Klose]

Package: src:lasso
Version: 2.6.0-4
Severity: important
Tags: sid bullseye
User: debian-pyt...@lists.debian.org
Usertags: python3.8

lasso builds for python3.8, but only installs the extension for 3.7. Apparently
the extensions for 3.7 and 3.8 are overridden, and only the extension for 3.7
ends up in the package.  Please fix this.

Bug#943608: tests segfault when run with Python 3.8

[Matthias Klose]

confirmed in unstable as well:
https://buildd.debian.org/status/fetch.php?pkg=beancount=amd64=2.2.3-1%2Bb1=1574207855=0

Bug#765899: [pkg-php-pear] Bug#765899: Bug#765899: Composer: Please, support OR-ed versions

[David Prévot]

Hi Thorsen,

Le 19/11/2019 à 20:30, Thorsten Glaser a écrit :

> Just fix the packaging tools, it can’t be *that* hard.

If you say so. I’m impatient to see your fix part of the next version.

> The issue has been open for five years, isn’t that embarassing?

Indeed, I filed that bug exactly five years (and a day) ago, never
bothered to actually work on it since (and you’re the first person to
actually care enough to reply), but I’m grateful if you feel interested
to get it fixed.

Regards

David



signature.asc
Description: OpenPGP digital signature

Bug#945122: buster-pu: package cyrus-imapd/3.0.8-6+deb10u2

[Xavier Guimard]

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

Hi,

cyrus-imapd is vulnerable to CVE-2019-18928: privilege escalation on HTTP
request. This is a minor vulnerability since authentication is already
vulnerable when using non-SSL connection. However, this little patch
fixes the problem.

Cheers,
Xavier
diff --git a/debian/changelog b/debian/changelog
index 8023011..b011c8f 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,9 @@
+cyrus-imapd (3.0.8-6+deb10u2) buster; urgency=high
+
+  * Fix privilege escalation on HTTP request (Closes: CVE-2019-18928)
+
+ -- Xavier Guimard   Tue, 19 Nov 2019 22:21:32 +0100
+
 cyrus-imapd (3.0.8-6+deb10u1) buster; urgency=medium
 
   * Add patch to fix data loss on upgrade from versions ≤ 3.0.0
diff --git a/debian/patches/CVE-2019-18928.patch 
b/debian/patches/CVE-2019-18928.patch
new file mode 100644
index 000..41bbad8
--- /dev/null
+++ b/debian/patches/CVE-2019-18928.patch
@@ -0,0 +1,38 @@
+Description: fix privilege escalation
+ Only allow reuse of auth creds on a persistent connection against a backend
+ server in a Murder
+Author: Ken Murchison 
+Origin: upstream, https://github.com/cyrusimap/cyrus-imapd/commit/e675bf7
+Bug: https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-18928
+Forwarded: not-needed
+Reviewed-By: Xavier Guimard 
+Last-Update: 2019-11-19
+
+--- a/imap/httpd.c
 b/imap/httpd.c
+@@ -1729,6 +1729,25 @@
+ txn->auth_chal.scheme = NULL;
+ }
+ 
++/* Drop auth credentials, if not a backend in a Murder */
++else if (!config_mupdate_server || 
!config_getstring(IMAPOPT_PROXYSERVERS)) {
++syslog(LOG_DEBUG, "drop auth creds");
++
++free(httpd_userid);
++httpd_userid = NULL;
++
++free(httpd_extrafolder);
++httpd_extrafolder = NULL;
++
++free(httpd_extradomain);
++httpd_extradomain = NULL;
++
++if (httpd_authstate) {
++auth_freestate(httpd_authstate);
++httpd_authstate = NULL;
++}
++}
++
+ /* Perform proxy authorization, if necessary */
+ else if (saslprops.authid &&
+  (hdr = spool_getheader(txn->req_hdrs, "Authorize-As")) &&
diff --git a/debian/patches/series b/debian/patches/series
index e9631e4..c66f980 100644
--- a/debian/patches/series
+++ b/debian/patches/series
@@ -23,3 +23,4 @@
 0023-fix-memory-leak-on-ldap-failure.patch
 CVE-2019-11356.patch
 0024-dont-skip-records-with-modseq-0.patch
+CVE-2019-18928.patch

Bug#765899: [pkg-php-pear] Bug#765899: Composer: Please, support OR-ed versions

[Thorsten Glaser]

David Prévot dixit:

>I believe the patch is wrong. Why patch at all?

You answer this yourself:

>[1] I don’t believe symfony will be upgraded to 5 in bullseye (according

But the package relationships should be correct to ease
the upgrade process, that is, ± 1 distribution release
at least. There’s also downstreams to consider, so having
the *correct* version used is certainly sensible.

>Since Stretch shipped with 2.8, the latter is probably overkill. Since I

Perhaps, but this is not the only case of OR dependencies
in the tangled mass of PHP libraries we’ve seen during
packaging of Movim. This means any reasoning based on any
specific example (and/or distribution release) necessarily
fails for incompleteness.

Just fix the packaging tools, it can’t be *that* hard.
The issue has been open for five years, isn’t that embarassing?

bye,
//mirabilos
-- 
“I'm not a real programmer. I throw together things until it works
 then I move on. The real programmers will say "yeah it works but
 you're leaking memory everywhere. Perhaps we should fix that."
 I'll just restart apache every 10 requests.” -- Rasmus Lerdorf

Bug#842420: electron packaging

[matteo]

Hi Paolo,

any news on this bug? I'm willing to help if needed.

Cheers and thanks

Matteo

Bug#944325: please fix this unclear and obtuse phrasing in §7.8 (suggestion provided)

[Sean Whitton]

Hello Nicholas,

I am not sure what is going on with your (1), (2) and (3).  Perhaps you
could propose your change in the form of a patch.

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#945096: metview: FTBFS in sid

[Gianfranco Costamagna]

This diff made it build successfully

diff -Nru metview-5.7.0/debian/control metview-5.7.0/debian/control
--- metview-5.7.0/debian/control2019-10-08 10:31:19.0 +0200
+++ metview-5.7.0/debian/control2019-11-19 22:56:58.0 +0100
@@ -14,6 +14,10 @@
   liblapack-dev,
   libpango1.0-dev,
   libfftw3-dev,
+  libxxhash-dev,
+  libsnappy-dev,
+  liblz4-dev,
+  libbz2-dev,
   libeigen3-dev,
   chrpath,
   mksh,
@@ -96,7 +100,7 @@
 Package: libmetview-dev
 Architecture: any
 Multi-Arch: same
-Depends: ${misc:Depends}, libmetview0d (=${binary:Version}), libodb-api-dev
+Depends: ${misc:Depends}, libmetview0d (=${binary:Version}), libodb-api-dev, 
libxxhash-dev, libsnappy-dev, liblz4-dev, libbz2-dev
 Section: libdevel
 Description: Development files for MetView
  Metview has been designed as a flexible, modular and extendible system

Bug#945030: lintian: legacy-foo++ test package fails with

[Chris Lamb]

Hi Felix,

> > I can't seem to build the test packages at the locally. The legacy-foo++
> > test appears to failing for me:
> 
> This may help with better error reporting. Feedback would be
> appreciated.

Looks good, although of course it is working now.

> Alternatively, please let me know which module you were missing.

Alas, I was missing a number of them so I don't know which was
the real culprit this time.


Regards,

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

Bug#945121: libopenmpi-dev: Sid The libopenmpi-dev 4.0.x package should probably depend on libevent-dev

[Ron Lovell]

Package: libopenmpi-dev
Version: 4.0.2-2
Severity: normal

While testing the newly upgraded Open MPI 4.0.2-2 packages in Sid I
found that builds with mpicc etc. will be expecting libevent.so and
libevent_pthreads.so, which are provided by libevent-dev.

Starting with 4.0.x, shouldn't libopenmpi-dev depend on or at least
recommend libevent-dev?

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

Kernel: Linux 5.3.0-2-amd64 (SMP w/2 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 libopenmpi-dev depends on:
ii  gfortran [gfortran-mod-15]4:9.2.1-3.1
ii  gfortran-9 [gfortran-mod-15]  9.2.1-19
ii  libhwloc-dev  1.11.13-1
ii  libibverbs-dev26.0-2
ii  libopenmpi3   4.0.2-2
ii  openmpi-bin   4.0.2-2
ii  openmpi-common4.0.2-2

Versions of packages libopenmpi-dev recommends:
ii  libcoarrays-openmpi-dev  2.8.0-1

Versions of packages libopenmpi-dev suggests:
pn  openmpi-doc  

-- no debconf information

Bug#945120: libopenmpi-dev: Sid upgrade to libopenmpi-dev 4.0.2-2 has issues in setup step

[Ron Lovell]

Package: libopenmpi-dev
Version: 4.0.2-2
Severity: important

Dear Maintainer,

The upgrade of Open MPI components from 3.1.3 to 4.0.2-2 did not
complete successfully. During upgrade I got these warnings:

Setting up libopenmpi-dev:amd64 (4.0.2-2) ...
update-alternatives: warning: forcing reinstallation of alternative 
/usr/lib/x86_64-linux-gnu/openmpi/include because link group 
mpi-x86_64-linux-gnu is broken
update-alternatives: warning: skip creation of 
/usr/lib/x86_64-linux-gnu/libmpi++.so because associated file 
/usr/lib/x86_64-linux-gnu/openmpi/lib/libmpi_cxx.so (of link group 
mpi-x86_64-linux-gnu) doesn't exist
update-alternatives: warning: skip creation of 
/usr/lib/x86_64-linux-gnu/libmpi.so because associated file 
/usr/lib/x86_64-linux-gnu/openmpi/lib/libmpi.so (of link group 
mpi-x86_64-linux-gnu) doesn't exist

As installed the libraries were not usable:

$ make
mpicc -O2 -march=native -fpie -std=c11  -D_Linux -D_XOPEN_SOURCE=700  -o 
mpi_mm.o -c mpi_mm.c
mpicc mpi_mm.o  -pie -Wl,-z,now -Wl,-z,relro  -o mpi_mm_c.linux-gnu.x86_64
/usr/bin/ld: cannot find -lmpi
/usr/bin/ld: cannot find -levent
/usr/bin/ld: cannot find -levent_pthreads
collect2: error: ld returned 1 exit status
make: *** [makefile:31: mpi_mm_c.linux-gnu.x86_64] Error 1

I found that the failure to locate -levent and -levent_pthreads was
because libevent-dev needs to be installed.

The -lmpi load failure is because the symlink

/usr/lib/x86_64-linux-gnu/openmpi/lib/libmpi.so -> libmpi.so.40.20.2

was missing when setup tried to create the symlinks

/etc/alternatives/libmpi.so-x86_64-linux-gnu ->
/usr/lib/x86_64-linux-gnu/openmpi/lib/libmpi.so

and

/usr/lib/x86_64-linux-gnu/libmpi.so -> 
/etc/alternatives/libmpi.so-x86_64-linux-gnu

Running dpkg-query -L libopenmpi-dev shows that

/usr/lib/x86_64-linux-gnu/openmpi/lib/libmpi.so

should have been created, but it wasn't.

On the off chance that a reinstallation might help, I reinstalled
all the 4.0.2-2 packages.  That time there were no issues reported,
the symlinks appear to be good, and Open MPI 4.0.2 works on my
test programs.

$ showlinks /usr/lib/x86_64-linux-gnu/libmpi.so
lrwxrwxrwx 1 root root 44 Nov 19 18:11 /usr/lib/x86_64-linux-gnu/libmpi.so -> 
/etc/alternatives/libmpi.so-x86_64-linux-gnu
lrwxrwxrwx 1 root root 47 Nov 19 18:11 
/etc/alternatives/libmpi.so-x86_64-linux-gnu -> 
/usr/lib/x86_64-linux-gnu/openmpi/lib/libmpi.so
lrwxrwxrwx 1 root root 17 Nov 19 05:55 
/usr/lib/x86_64-linux-gnu/openmpi/lib/libmpi.so -> libmpi.so.40.20.2
-rw-r--r-- 1 root root 1126552 Nov 19 05:55 
/usr/lib/x86_64-linux-gnu/openmpi/lib/libmpi.so.40.20.2

That's similar to the 3.1.3 scheme that I still have on my Buster host.

Is it possible that the installation script has a sequencing problem
such that it tries to target 

/usr/lib/x86_64-linux-gnu/openmpi/lib/libmpi.so

with a symlink from /etc/alternatives before it's been created?

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

Kernel: Linux 5.3.0-2-amd64 (SMP w/2 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 libopenmpi-dev depends on:
ii  gfortran [gfortran-mod-15]4:9.2.1-3.1
ii  gfortran-9 [gfortran-mod-15]  9.2.1-19
ii  libhwloc-dev  1.11.13-1
ii  libibverbs-dev26.0-2
ii  libopenmpi3   4.0.2-2
ii  openmpi-bin   4.0.2-2
ii  openmpi-common4.0.2-2

Versions of packages libopenmpi-dev recommends:
ii  libcoarrays-openmpi-dev  2.8.0-1

Versions of packages libopenmpi-dev suggests:
pn  openmpi-doc  

-- no debconf information

Bug#886679: Status of ITA

[Ondřej Surý]

Hi,

what’s the status of the adoption?

We use coccinelle for BIND 9 and I would be happy to start things moving again.

Ondrej
--
Ondřej Surý
ond...@sury.org

Bug#765899: [pkg-php-pear] Bug#765899: Composer: Please, support OR-ed versions

[David Prévot]

Hi Thorsen,

Le 19/11/2019 à 15:55, Thorsten Glaser a écrit :

> Please fix this issue some time soon. It causes problems with
> each new upgrade of things like Symfony because the other packages
> have debian/patches/ like this one…

I believe the patch is wrong. Why patch at all?

> $ cat debian/patches/pkg-php-tools-deficiency-workaround.diff
> # DP: or’d dependencies are not supported (#765899)
> # DP: choose the branch currently shipped in Debian
> 
> --- a/composer.json
> +++ b/composer.json
> @@ -22,7 +22,7 @@
>  ],
>  "require": {
>  "php": ">=5.3.9",
> -"symfony/translation": "~2.6 || ~3.0 || ~4.0"
> +"symfony/translation": "~3.0"

A proper way to actually express the current dependency wound be :

+"symfony/translation": "<5"

And, eventually, also

+"symfony/translation": "> 2.6"

Since Stretch shipped with 2.8, the latter is probably overkill. Since I
expect bullseye to ship with 4.4 [1], even the former is probably
overkill for your needs. So just leaving things as they are will do the
right thing here: no versioned dependency at all.

[1] I don’t believe symfony will be upgraded to 5 in bullseye (according
to the current [roadmap], I believe the next 5.4 LTS release will happen
by the end of 2022, and I expect the freeze to happen sooner.

roadmap: https://symfony.com/releases

Regards

David



signature.asc
Description: OpenPGP digital signature

Bug#945112: debcheck: handle debhelper-compat

[Thorsten Glaser]

On Tue, 19 Nov 2019, Thorsten Glaser wrote:

> Please hack debcheck that it works with these virtual packages. Thanks!

Perhaps same with 'default-logind | logind'.

Thanks in advance,
//mirabilos
-- 
tarent solutions GmbH
Rochusstraße 2-4, D-53123 Bonn • http://www.tarent.de/
Tel: +49 228 54881-393 • Fax: +49 228 54881-235
HRB 5168 (AG Bonn) • USt-ID (VAT): DE122264941
Geschäftsführer: Dr. Stefan Barth, Kai Ebenrett, Boris Esser, Alexander Steeg

Bug#765899: Composer: Please, support OR-ed versions

[Thorsten Glaser]

Package: pkg-php-tools
Version: 1.38
Followup-For: Bug #765899
Control: affects 765899 src:movim
Control: affects 765899 src:php-nesbot-carbon
Control: affects 765899 src:php-robmorgan-phinx
Control: affects 765899 src:ratchetphp

Please fix this issue some time soon. It causes problems with
each new upgrade of things like Symfony because the other packages
have debian/patches/ like this one…

$ cat debian/patches/pkg-php-tools-deficiency-workaround.diff
# DP: or’d dependencies are not supported (#765899)
# DP: choose the branch currently shipped in Debian

--- a/composer.json
+++ b/composer.json
@@ -22,7 +22,7 @@
 ],
 "require": {
 "php": ">=5.3.9",
-"symfony/translation": "~2.6 || ~3.0 || ~4.0"
+"symfony/translation": "~3.0"
 },
 "require-dev": {
 "friendsofphp/php-cs-fixer": "~2",


If pkg-php-tools would generate sensible dependencies, this would
not be necessary, and we’d not have the trouble of being specific
to a release of Symfony (and needing to change the patch in back‐
ports).

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

Kernel: Linux 5.3.0-1-amd64 (SMP w/2 CPU cores)
Kernel taint flags: TAINT_CRAP
Locale: LANG=C, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE=C (charmap=UTF-8)
Shell: /bin/sh linked to /bin/lksh
Init: sysvinit (via /sbin/init)

Versions of packages pkg-php-tools depends on:
ii  debhelper   12.7.1
ii  php-cli 2:7.3+69
ii  php-pear1:1.10.9+submodules+notgz-1
ii  php-xml 2:7.3+69
ii  php7.3-cli [php-cli]7.3.10-1+b1
ii  php7.3-json [php-json]  7.3.10-1+b1
ii  php7.3-xml [php-xml]7.3.10-1+b1

pkg-php-tools recommends no packages.

Versions of packages pkg-php-tools suggests:
pn  dh-make  

-- no debconf information

Bug#945119: mmdebstrap: Fail to mmdebstrap Jessie with systemd components (missing /dev/urandom)

[Vincent Caron]

Package: mmdebstrap
Version: 0.5.1
Severity: normal
Tags: upstream

Thanks a lot for mmdebstrap, I use it to generate images for my Xen
cluster, it's efficient and works like a charm.

I have a small bug when using it to generate Jessie images with systemd
components, when systemd's postinst invokes 'systemd-machine-id-setup'
and this one fails because it cannot find any /dev/urandom. Reproduce
with :

./mmdebstrap --mode=unshare --include systemd jessie jessie.tar.gz
...
Setting up systemd (215-17+deb8u7) ...
Failed to read /proc/cmdline. Ignoring: No such file or directory
Failed to open /dev/urandom: Function not implemented
dpkg: error processing package systemd (--install):
 subprocess installed post-installation script returned error exit
status 1

I've worked around this by adding a
--setup-hook='systemd-machine-id-setup --root $1' which is quite a hack
and works because my host has systemd.

And then I encounter a last (related?) bug :

./mmdebstrap --mode=unshare --setup-hook='systemd-machine-id-setup --
root $1' --include systemd jessie jessie.tar.gz
...
I: installing apt...
done
E: run_chroot failed: E: cannot make_path ./dev/pts/

It seems than around line 777 when creating type==5/directory it goes
thru the havemknod==false path and fails. But if I bypass this block, it
proceeds with bind-mouting /dev/pts which works, and I get my working
tarball.

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

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

Versions of packages mmdebstrap depends on:
ii  apt   1.8.2
ii  perl  5.28.1-6
ii  perl-doc  5.28.1-6

Versions of packages mmdebstrap recommends:
ii  arch-test   0.15-2
ii  fakechroot  2.19-3.2
ii  fakeroot1.23-1
ii  mount   2.33.1-0.1
ii  uidmap  1:4.5-1.1

Versions of packages mmdebstrap suggests:
pn  binfmt-support
ii  dpkg-dev  1.19.7
ii  proot 5.1.0-1.3
pn  qemu-user 
pn  qemu-user-static  

Bug#945064: unrardll needs a sourceful upload to support python3.8?

[Norbert Preining]

Hi Matthias,

On Tue, 19 Nov 2019, Matthias Klose wrote:
> unrardll shows up in
> https://release.debian.org/transitions/html/python3.8.html
> 
> but cannot be binNMUed because it's a contrib package b-d on a non-free 
> package.
>  Please do a sourceful upload to add support for Python 3.8.

No problem. Are there any changes besides a new upload that need to go
in?

debian/rules:
dh $@ --with python2,python3 --buildsystem=pybuild

debian/control:
Build-Depends: ... python3-all-dev ...

?

Best

Norbert

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

Bug#945118: asymptote: FTBFS because of grffile

[Norbert Preining]

On Wed, 20 Nov 2019, Francesco Poli (wintermute) wrote:
> The fix for bug [#944916] seems to be somehow incomplete and
> prevents the package from [building].

Indeed, already fixed for 2.61-1 to be uploaded in a minute ... ;-)
Didn't have WIFI in the airplane yesterday night.

> I don't fully understand why the invocations of ../asy do not
> use the just re-generated doc/asymptote.sty ...

The source code (asy) generated tex code also includes grffile.
I removed all of that, it is already in the git repo.

Best

Norbert

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

Bug#944932: www.debian.org: certain pages on www.debian.org are 403 Forbidden

[Christopher Cooper]

On Mon, Nov 18, 2019 at 5:25 PM Paul Wise  wrote:
> Which IP address are you accessing?

I don't have a log of which IP address was causing the problem. It
seems fine now and I cannot reproduce the issue anymore.

Thanks,
Christopher

Bug#945042: hydrogen: Typos in package description

[Nicholas D Steeves]

Control: tag -1 + pending

Hi,

Thomas Vincent  writes:

> Source: hydrogen
> Severity: minor
>
> Dear Maintainer,
>
> I noticed some typos while translating the package description of hydrogen.
> Indeed, I believe that in "it's main goal is to bring…", "it's" should be 
> "its".
> Moreover, "QT" should be spelled "Qt".
>
> Thanks for maintaining hydrogen!
>
> Cheers,
> Thomas
>
>

Fixed in git at commit:9ccc9e876e6e971c6b9836785f86b0515e80f4b5

Jonas and Jaromír, I've tagged this bug pending, but will am leaving the
upload to one of you.


Cheers,
Nicholas


signature.asc
Description: PGP signature

Bug#945118: asymptote: FTBFS because of grffile

[Francesco Poli (wintermute)]

Package: asymptote
Version: 2.60-2
Severity: serious
Tags: ftbfs
Justification: fails to build from source (but built successfully in the past)

Hello!

The fix for bug [#944916] seems to be somehow incomplete and
prevents the package from [building].

[#944916]: 
[building]: 


I thought that file doc/asymptote.sty was generated from
doc/asy-latex.dtx ...
However, for reasons I am not sure I understand, I see that
doc/asymptote.sty is also committed to the git repository.
And it still [includes] the line:

  \RequirePackage[space]{grffile}

[includes]: 


I don't fully understand why the invocations of ../asy do not
use the just re-generated doc/asymptote.sty ...

Oh well, I am sure you have already figured out what's wrong!
Please fix it.

Bye and thanks for your time and dedication!   :-)

Bug#944325: please fix this unclear and obtuse phrasing in §7.8 (suggestion provided)

[Nicholas D Steeves]

Sean Whitton  writes:

> Hello,
>
> On Sun 17 Nov 2019 at 10:29AM -08, Russ Allbery wrote:
>
>> How about:
>>
>> [1] This field should only be used when there are license or DFSG
>> requirements to retain the referenced source package.  [2] It should not
>> be added solely as a way to locate packages that need to be rebuilt
>> against newer versions of their build dependencies.
>
> Thanks, I think this is good -- would be good to hear from Nicholas too
> though.

I agree this is clear for people who already understand what it signifies,
but I don't think it's clear/accurate enough for a new contributor who
is struggling to understand Policy, because "retain the referenced
source package [singular]" seems to refer src:foo, if src:foo uses
Built-Using, and this isn't the case.

So:

  (3) The Built-Using field should exclusively be used to satisfy license or
  DFSG requirements, where those requirements stipulate that the
  specific versions of build-time dependencies must remain available in
  the Debian archive.

With further consideration I think (2) should be cut and replaced,
because it undercuts the clarity of this paragraph's premise.  Eg: Clear
(1||3) "should" premise, but if a tree falls in a forest and no one
notices it fall then you can do this other thing (2) without anyone
noticing.  If a maintainer uses the field for (1), then it's a non-issue
if they're also privately using it as a heuristic for (2).  Thus I don't
think we need to say anything about the (2), because it's confusing for
people who don't already understand the discussed concepts.

Rather than (2), I think it would be better to refer to the general case
of how to use foo.buildinfo (or tooling that leverages buildinfo, or
some other method) to identify packages that need to be rebuilt.


Sorry for the delay replying!
Regards,
Nicholas


signature.asc
Description: PGP signature

Bug#945117: ITP: matiec -- IEC 61131-3 to C translator

[Philip Rinn]

Package: wnpp
Severity: wishlist
Owner: Philip Rinn 

* Package name: matiec
  Version : 0.1+hgd9e47e0
  Upstream Author : Mario de Sousa 
* URL : https://bitbucket.org/mjsousa/matiec
* License : GPL-3
  Programming Lang: C++
  Description : IEC 61131-3 to C translator

Open source code translator for the programming languages defined in the IEC
61131-3 standard. These programming languages are mostly used in the industrial
automation domain, to program PLCs (Programmable Logic Controllers).
The translator accepts the three textual representations defined in the
standard, IL (Instruction List), ST (Structured Text) and SFC (Sequential
Function Chart).
.
To my knowledge this is the only open source compiler for the IEC 61131-3
Languages.

As I'm a DM, I'd need a sponsor for the upload.

Bug#945088: prewikka: depends on unexisting package

[Thomas Andrejak]

Hello

I'm waiting for this ITP :
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=941657

Regards

Thomas

Le mar. 19 nov. 2019 à 14:15, Gianfranco Costamagna <
locutusofb...@debian.org> a écrit :

> Source: prewikka
> Version: 5.1.1-1
> Severity: serious
>
> Hello,
> prewikka/amd64 unsatisfiable Depends: python3-lark-parser
> prewikka/i386 unsatisfiable Depends: python3-lark-parser
>
> Does this package depend on something that is not yet in the archive?
>
> Can you please have a look? Testing migration is stalled by this
>
>
> Gianfranco
>
>

Bug#944915: libldap-2.4-2: Segmentation fault in "ldap_unbind_ext"

[devel]

Hello Bernhard,


Am Tue, 19 Nov 2019 11:55:54 +0100
schrieb Bernhard Übelacker :

> just a wild guess - is claws-mail doing these ldap queries
> in parallel in different threads? This in combination with
> the unsteady connection to the server could make two threads
> operate on the same structures?

An interesting idea!
I could imagine, that claws-mail's maintainer will appreciate this hint.
(I guess, I will open a bug report against claws-mail upstream)


> In that case following gdb output would show all
> threads with their backtraces:
> (gdb) thread apply all bt

indeed this was the command, that I used to generate the gdb output.


> Or with showing also the variables:
> (gdb) thread apply all bt full

Next time I will also use this one.


> And how do you get the backtraces? Are you running
> with a gdb attached to it permanently?

Yes, I am doing this for claws-mail at the moment.


> Then you could create a core when the crash happened with
> (gdb) generate-core-file /home/someone/corefile

Good point - I will try this next time.


Thank you for your hints!

Cheers,
Lars

Bug#944914: libgpgme11: Buffer overflow while using claws-mail

[devel]

Hello Bernahrd,


Am Tue, 19 Nov 2019 14:50:13 +0100
schrieb Bernhard Übelacker :

> Another question, which version of claws-mail and plugins are you running?
> (And are they the binaries from debian or self-built?)

I use the Debian packages (current version in testing - 3.17.4-2+b1).


> Maybe a run with valgrind could shed some light on some wrong memory accesses.
> (But may also write many unrelated accesses,
> and slow the application down to an unusable speed.)

Thanks, I will try that.


> I found this upstream feature request, which could fit,
> but there is also a change mentioned that should avoid that crash,
> that is already included ...
> Are you maybe hitting this limit?
> 
> https://dev.gnupg.org/T2385

Right now the number of open file descriptors look fine:
(but this may change at some point in time)

$ ls -l /proc/$(pidof claws-mail)/fd | wc -l
39


Thank you!

Cheers,
Lars

Bug#944242: Test issues with BioPython 1.75

[Andreas Tille]

On Tue, Nov 19, 2019 at 10:03:25AM +, Peter Cock wrote:
> 
> Do you have a list of things still depending on Biopython & Python 2.7
> handy? We're discussing when exactly to drop Python 2.7 support -
> with a final compatible release in December 2019 or January 2020
> looking most likely.

Speaking about droping Python2 and just running tests with Python3
I was running into other errors:

==
FAIL: kmedoids (Bio.Cluster._cluster)
Doctest: Bio.Cluster._cluster.kmedoids
--
Traceback (most recent call last):
  File "/usr/lib/python3.8/doctest.py", line 2196, in runTest
raise self.failureException(self.format_failure(new.getvalue()))
AssertionError: Failed doctest test for Bio.Cluster._cluster.kmedoids
  File 
"/build/python-biopython-1.75+dfsg/.pybuild/cpython3_3.8/build/Bio/Cluster/_cluster.cpython-38-x86_64-linux-gnu.so",
 line unknown line number, in kmedoids

--
File 
"/build/python-biopython-1.75+dfsg/.pybuild/cpython3_3.8/build/Bio/Cluster/_cluster.cpython-38-x86_64-linux-gnu.so",
 line ?, in Bio.Cluster._cluster.kmedoids
Failed example:
distance = array([[0.0, 1.1, 2.3],
  [1.1, 0.0, 4.5],
  [2.3, 4.5, 0.0]])
Exception raised:
Traceback (most recent call last):
  File "/usr/lib/python3.8/doctest.py", line 1328, in __run
exec(compile(example.source, filename, "single",
  File "", line 1, in 
distance = array([[0.0, 1.1, 2.3],
NameError: name 'array' is not defined
--
File 
"/build/python-biopython-1.75+dfsg/.pybuild/cpython3_3.8/build/Bio/Cluster/_cluster.cpython-38-x86_64-linux-gnu.so",
 line ?, in Bio.Cluster._cluster.kmedoids
Failed example:
distance = array([1.1, 2.3, 4.5])
Exception raised:
Traceback (most recent call last):
  File "/usr/lib/python3.8/doctest.py", line 1328, in __run
exec(compile(example.source, filename, "single",
  File "", line 1, in 
distance = array([1.1, 2.3, 4.5])
NameError: name 'array' is not defined
--
File 
"/build/python-biopython-1.75+dfsg/.pybuild/cpython3_3.8/build/Bio/Cluster/_cluster.cpython-38-x86_64-linux-gnu.so",
 line ?, in Bio.Cluster._cluster.kmedoids
Failed example:
distance = [array([]),
array([1.1]),
array([2.3, 4.5])]
Exception raised:
Traceback (most recent call last):
  File "/usr/lib/python3.8/doctest.py", line 1328, in __run
exec(compile(example.source, filename, "single",
  File "", line 1, in 
distance = [array([]),
NameError: name 'array' is not defined


==
FAIL: pca (Bio.Cluster._cluster)
Doctest: Bio.Cluster._cluster.pca
--
Traceback (most recent call last):
  File "/usr/lib/python3.8/doctest.py", line 2196, in runTest
raise self.failureException(self.format_failure(new.getvalue()))
AssertionError: Failed doctest test for Bio.Cluster._cluster.pca
  File 
"/build/python-biopython-1.75+dfsg/.pybuild/cpython3_3.8/build/Bio/Cluster/_cluster.cpython-38-x86_64-linux-gnu.so",
 line unknown line number, in pca

--
File 
"/build/python-biopython-1.75+dfsg/.pybuild/cpython3_3.8/build/Bio/Cluster/_cluster.cpython-38-x86_64-linux-gnu.so",
 line ?, in Bio.Cluster._cluster.pca
Failed example:
columnmean + dot(coordinates, pc)
Exception raised:
Traceback (most recent call last):
  File "/usr/lib/python3.8/doctest.py", line 1328, in __run
exec(compile(example.source, filename, "single",
  File "", line 1, in 
columnmean + dot(coordinates, pc)
NameError: name 'columnmean' is not defined


==
FAIL: treecluster (Bio.Cluster._cluster)
Doctest: Bio.Cluster._cluster.treecluster
--
Traceback (most recent call last):
  File "/usr/lib/python3.8/doctest.py", line 2196, in runTest
raise self.failureException(self.format_failure(new.getvalue()))
AssertionError: Failed doctest test for Bio.Cluster._cluster.treecluster
  File 
"/build/python-biopython-1.75+dfsg/.pybuild/cpython3_3.8/build/Bio/Cluster/_cluster.cpython-38-x86_64-linux-gnu.so",
 line unknown line number, in treecluster

--
File 
"/build/python-biopython-1.75+dfsg/.pybuild/cpython3_3.8/build/Bio/Cluster/_cluster.cpython-38-x86_64-linux-gnu.so",
 line ?, in Bio.Cluster._cluster.treecluster
Failed example:
distance = array([[0.0, 1.1, 2.3],
 

Bug#942106: python3.8 / pandas py2removal

[Rebecca N. Palmer]

The binNMUs (to add python3.8 support) of pandas and statsmodels failed. 
 I think this will make them work (but haven't tried it):


- Apply the (existing) #943418 fix to python-xlrd.
- Build matplotlib, pandas and statsmodels in that order.  (ben can't 
work this out because the declared dependencies are circular, but I 
think the actual strict test dependencies only go that way.)

Bug#907733: Contributing to curlcpp

[Aloïs Micard]

Hello,

I'm interested to become a maintainer of the package. I have a good 
background in C++ but I'm fairly new to maintaining. This project seem a 
good start for me as I want to be involved in Debian.


I have already forked your repository and will fix the bugs, then I will 
try packaging the whole thing.


Have a good day

--
Aloïs Micard 

GPG: rsa4096/A5999EBDFC063F1F

Bug#932564: movim: should not use composer’s autoloader at runtime

[Thorsten Glaser]

retitle 932564 movim: should not use composer’s autoloader at runtime
severity 932564 wishlist
thanks

On Sat, 20 Jul 2019, David Prévot wrote:

> I just noticed that the movim package depends on composer. Looking
> further, it seems to use the ClassLoader feature of Composer.
> 
> I’m not sure this is a proper (nor optimal) way to load classes in a
> production system, I’m not even confident that’s a secure way to do it.

It’s good enough for now.

> I thus would like to advise the use of a tool like phpab in order to
> generate an autoload at build time, and let movim use this static
> autoload at run time.

This would require binNMUs every time a dependency changes.
I’d prefer to not do this.

If I get a really good reason to write an own autoloader implementation
similar to composer’s and use it instead, I might just do that, but I
looked at the implementation, and it’s suitable for now.

> Maybe some movim dependencies are affected by a similar issue, I didn’t

No, we’re installing them into /usr/share/php/ in a way that
the include path contains them correctly, which we use in the
composer autoloader invocation:

$movim_autoloader->setUseIncludePath(true); 
 

> I’d like to advise hosting those dependencies under the “Debian PHP
> PEAR (and Composer) Maintainers” umbrella by the way.

Are you kidding me? We’ve asked the PHP maintainers, ahead of
time, multiple times, and never got *any* kind of usable reply,
nor any kind of assistance regarding the way we should install
and use the libraries. It’s a bit surprising you complain *now*
about *both* the way we use them (autoloader) *and* where they
are hosted, when the PHP packagers have been extremely unhelpful
when we asked.

We would have liked to have them maintained by people who know
what they’re doing, but it turned out that it’s better to do it
ourselves, perhaps not in the same style but not too badly, than
to be under the umbrella of an unresponsive team.

bye,
//mirabilos
-- 
Yes, I hate users and I want them to suffer.
-- Marco d'Itri on gmane.linux.debian.devel.general

Bug#875065: [odin] Future Qt4 removal from Buster -> odin is ready for Qt5

[Moritz Mühlenhoff]

> On Fri, Oct 11, 2019 at 11:08:02PM +0200, Moritz Mühlenhoff wrote:
> > On Wed, Jan 23, 2019 at 09:46:28AM +0100, thies wrote:
> > > Dear all,
> > > 
> > > odin should compile on Buster without changes using the packages 
> > > qt5-default
> > > and libqwt-qt5-dev.
> > 
> > This bug hasn't seen any maintainer followup since two years, are the 
> > maintainers
> > planning to make this change?
> > 
> > We're now moving forward with the Qt4 removal, if there no immediate plans 
> > to
> > switch port odin to Qt5, we'll request to remove it from the archive.

On Sat, Oct 12, 2019 at 08:09:09AM +0200, Andreas Tille wrote:
> I can do so not before November 4th, Andreas.

What's the status?

Cheers,
Moritz

Bug#945116: RM: qjoypad -- RoQA; depends on Qt4

[Moritz Muehlenhoff]

Package: ftp.debian.org
Severity: normal

Please remove qjoypad. It depends on Qt4, which is going away.

Cheers,
Moritz

Bug#875137: [qjoypad] Future Qt4 removal from Buster

[Moritz Mühlenhoff]

On Thu, Oct 31, 2019 at 11:56:13PM +0100, Moritz Mühlenhoff wrote:
> On Sat, Sep 09, 2017 at 11:06:18PM +0200, Lisandro Damián Nicanor Pérez Meyer 
> wrote:
> > Source: qjoypad
> > Version: 4.1.0-2.1
> > Severity: wishlist
> > User: debian-qt-...@lists.debian.org
> > Usertags: qt4-removal
> > 
> > 
> > Hi! As you might know we the Qt/KDE team are preparing to remove Qt4
> > as [announced] in:
> > 
> > [announced] 
> > 
> > 
> > Currently Qt4 has been dead upstream and we are starting to have problems
> > maintaining it, like for example in the [OpenSSL 1.1 support] case.
> > 
> > [OpenSSL 1.1 support] 
> > 
> > 
> > In order to make this move, all packages directly or indirectly depending on
> > the Qt4 libraries have to either get ported to Qt5 or eventually get
> > removed from the Debian repositories.
> > 
> > Therefore, please take the time and:
> > - contact your upstream (if existing) and ask about the state of a Qt5
> > port of your application
> > - if there are no activities regarding porting, investigate whether there 
> > are
> > suitable alternatives for your users
> > - if there is a Qt5 port that is not yet packaged, consider packaging it
> > - if both the Qt4 and the Qt5 versions already coexist in the Debian
> > archives, consider removing the Qt4 version
> 
> qjoypad seems dead upstream, but there's a fork at 
> https://github.com/panzi/qjoypad
> which supports Qt5. Does anyone plan to switch the package to the port? 
> Otherwise
> let's remove it as we're moving forward with the Qt4 removal.

I've filed a removal bug now.

Cheers,
Moritz

Bug#933019: Adjust for GlusterFS API change

[Moritz Mühlenhoff]

On Fri, Nov 08, 2019 at 05:23:30PM +0100, Jakob Haufe wrote:
> Dear Bareos maintainers,
> 
> this FTBFS can be fixed rather easily.
> 
> Based on [1] I created [2].
> 
> An upcoming 18.2 upstream release will contain a fallback for GlusterFS
> 5 as well, but I don't see a point in backporting this logic to the
> autotools stuff in 17.2 as GlusterFS 6 is available even in buster via
> backports.
> 
> I could do an NMU as well if you want.

Given the lack of feedback, go ahead I'd say...

Cheers,
Moritz

Bug#944911: libfiu: FBTFS: Found too many matching python3 bindings

[Chris Lamb]

tags 944911 + upstream
thanks

Aurelien Jarno wrote:

> libfiu fails to build from source:
> | ./wrap-python 3 ./test-manyfps.py
> | Found too many matching python3 bindings

This happens because we build for all Python versions, eg:

cd bindings/python && \
set -e && for i in $(PYTHON_VERSIONS); do \
python$$i ./setup.py build; \
done

… which leaves us with:

  bindings
  └── python
  └── build
  ├── lib.linux-x86_64-3.7
  ├── lib.linux-x86_64-3.8
  ├── temp.linux-x86_64-3.7
  └── temp.linux-x86_64-3.8


… and then when we call "./wrap-python 3" this finds both the
lib.linux-x86_64-3.7 and lib.linux-x86_64-3.8 directories.

I'm not sure about the best solution here and have vaguely considered
manually deleting all but the default version of Python from
bindings/python/build but it would be preferable if we could run the
tests against all (or "all built") versions of Python. Alberto, would
this be possible?


Regards,

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

Bug#945115: armagetronad does not find itself (and fails to start)

[boffi]

Package: armagetronad
Version: 0.2.8.3.4-3
Severity: important

Dear Maintainer,

I tried to start the program, the following message was printed
-
Error: Error in tString GeneratePrefix() in 
../../src/tools/tDirectories.cpp:1359 : 
Relocation error. The binary was supposed to be installed into 
/usr/games and found itself in  and could not find out what this means for the 
prefix /usr.

-
and I was back at the shell prompt. This happened every time I tried
after the Nov 17 update.

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

Kernel: Linux 5.3.0-2-amd64 (SMP w/4 CPU cores)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
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: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages armagetronad depends on:
ii  armagetronad-common 0.2.8.3.4-3
ii  libc6   2.29-3
ii  libgcc1 1:9.2.1-19
ii  libgl1  1.1.0-1+b1
ii  libglu1-mesa [libglu1]  9.0.1-1
ii  libpng16-16 1.6.37-1
ii  libsdl-image1.2 1.2.12-12
ii  libsdl1.2debian 1.2.15+dfsg2-5
ii  libstdc++6  9.2.1-19
ii  libxml2 2.9.4+dfsg1-7+b4

armagetronad recommends no packages.

armagetronad suggests no packages.

-- no debconf information

Bug#945114: djvulibre: CVE-2019-18804

[Salvatore Bonaccorso]

Source: djvulibre
Version: 3.5.27.1-13
Severity: normal
Tags: security upstream
Forwarded: https://sourceforge.net/p/djvu/bugs/309/
Control: found -1 3.5.27.1-10
Control: found -1 3.5.27.1-7

Hi,

The following vulnerability was published for djvulibre.

CVE-2019-18804[0]:
| DjVuLibre 3.5.27 has a NULL pointer dereference in the function
| DJVU::filter_fv at IW44EncodeCodec.cpp.


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

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2019-18804
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-18804
[1] https://sourceforge.net/p/djvu/bugs/309/
[2] 
https://sourceforge.net/p/djvu/djvulibre-git/ci/c8bec6549c10ffaa2f2fbad8bbc629efdf0dd125/

Please adjust the affected versions in the BTS as needed.

Regards,
Salvatore

Bug#945113: transition: hwloc

[Samuel Thibault]

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

Hello,

Version 2 of hwloc introduces a soname bump. It also introduces
incompatible API changes, but with the latest upload of openmpi, I could
check that all packages that build with and actually use libhwloc-dev (a
dozen) now build fine with hwloc 2 (available in experimental). I'm thus
requesting a transition slot for hwloc 2.

Samuel

Ben file:

title = "hwloc";
is_affected = .depends ~ "libhwloc5" | .depends ~ "libhwloc15";
is_good = .depends ~ "libhwloc15";
is_bad = .depends ~ "libhwloc5";


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

Kernel: Linux 5.3.0 (SMP w/8 CPU cores)
Kernel taint flags: TAINT_OOT_MODULE
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)

Bug#945107: Fix some more crashes

[Asher Gordon]

Dear Maintainer,

I have written a patch to fix some more crashes. This has not been fixed
upstream (although it is the same issue; storing a pointer in an integer
type too small to store a pointer).

Here is the patch:
Index: berusky2-0.10/src/komat/Berusky3d_castice.h
===
--- berusky2-0.10.orig/src/komat/Berusky3d_castice.h
+++ berusky2-0.10/src/komat/Berusky3d_castice.h
@@ -195,8 +195,8 @@ typedef struct _PARMETAC
   GLMATRIX world;   // transfromacni matice
 
   void *p_param;
-  int param;
-  int param2;
+  size_ptr param;
+  size_ptr param2;
   END_FUNKCE p_endfce;  // kofolova end funkce
 
   struct _PARMETAC *p_next;


Thanks,
Asher


-- 
If at first you don't succeed, redefine success.

GPG fingerprint: 38F3 975C D173 4037 B397  8095 D4C9 C4FC 5460 8E68


signature.asc
Description: PGP signature

Bug#944323: RFS: piper/0.3-1 [ITP] -- graphical frontend for libratbag

[Stephan Lachnit]

> Right, that’s a good idea. I’ve uploaded the package now, it’s on its way to
> the NEW queue! I’ll address your previous questions later.

The package is up, and already in Ubuntu as well! Thanks for the upload!
I also got the python3-dev build dependency removed in upstream, and some 
simplifications for the copyright are also on their way, which makes the next 
release a little bit cleaner.

Regards,
Stephan

Bug#930492: pkg-config: Broken i686-w64-mingw32-pkg-config and x86_64-w64-mingw32-pkg-config

[Helmut Grohne]

Hi Stephen,

On Tue, Nov 19, 2019 at 08:51:05PM +0100, Stephen Kitt wrote:
> I noticed that the pkg-config hook is very careful to only
> touch /usr/bin/*-pkg-config links it owns. Would it be acceptable to continue
> shipping MinGW-w64 pkg-config instances there? Not using crosswrapper, of
> course, but a MinGW-w64-hosted implementation.

With my "author-of-pkg-config-dpkghook-hat", I agree with that. In my
view, you can even use your own crosswrapper.  Just make it different
from pkg-config's crosswrapper. However, I'm not a pkg-config
maintainer, so I don't have authority here.

Helmut

Bug#944227: breaks

[Graham Inggs]

Control: tags -1 - moreinfo + confirmed

On Tue, 19 Nov 2019 at 13:48, Gordon Ball  wrote:
> I've added Breaks to the package in git:
>
> aws-shell (<= 0.2.1) [1]
> mycli (<< 1.19)
> pgcli (<< 2)
> python3-ipython (<< 7)
> python3-jupyter-console (<< 6)
> python3-softlayer (<< 5.8)
>
> [1] No upstream version which fixes this, but I assume adding an
> unversioned Breaks: is a bad idea.
>
> I think that having heard from sagemath, pgcli and mycli, the only
> outstanding blockers are aws-shell (#944542) and possibly
> mlbstreamer (#944545).
>
> For my part (ipython, jupyter-console) I'm waiting for python-backcall
> and ipython-py2 to go through NEW before ipython can be upgraded.

Great!  Please go ahead.

Bug#944242: Test issues with BioPython 1.75

[Andreas Tille]

Hi Peter,

On Tue, Nov 19, 2019 at 10:03:25AM +, Peter Cock wrote:
> > I'd like to give you credit as the fastest upstream answering a
> > question. ;-)  Thanks a lot for it!
> 
> Lucky timing.

Anyway:  Thanks a lot.
 
> > On Tue, Nov 19, 2019 at 09:17:17AM +, Peter Cock wrote:
> > > Curious - do you have the Python 2.7 version and build details?
> >
> > I've attached the full build log.
> 
> Thanks - I'v had a quick look. There must be something different to
> how the build or installed directories are setup - our TravisCI tests
> do not pick up the C modules at all.

Hmmm, I'd love to re-implement this for the Debian package.
 
> > Hmmm, you say its harmless but its breaking the build of the Debian
> > package anyway.  So it would be good to have some means against it.
> 
> I mean I would not worry about this particular test failing - and would
> consider whitelisting this test acceptable.
> 
> Without yet being able to reproduce this and test it, does this work?:
> 
> https://github.com/peterjc/biopython/commit/5af680b5043c9f160a19e4bb0deab0ccc271280d

Unfortunately this does not work. :-(  I tried it in the packaging commit

   
https://salsa.debian.org/med-team/python-biopython/commit/bb94263daca0cd51968305805e444d0254c01c48

> If not, we could explicitly exclude the C modules from testing, maybe here:
> 
> https://github.com/biopython/biopython/blob/biopython-175/Tests/run_tests.py#L151

Neither works this

   
https://salsa.debian.org/med-team/python-biopython/commit/e22d86592d4c29c723297d3d5eb9cc63aa6f8fb8

> i.e. Add "Bio/KDTree/_CKDTree" etc to EXCLUDE_DOCTEST_MODULES
> (with the proviso that to date I've only used this with Python modules,
> you might need to include the .so extension?)

I'm not sure what you want to tell me with the last phrase in brackets.
 
> > Since you are asking about the 2.7 version:  We need to get rid of
> > Python2 as soon as all reverse depends of biopython are ported to
> > Python3 (or removed from Debian).  This might take some time but if
> > we could move this kind of doc string generation to be done by Python3
> > this would be some step in the right direction.
> 
> Do you have a list of things still depending on Biopython & Python 2.7
> handy?

As far as I interpret

apt-cache rdepends python-biopython

it is

   srst2
   seqsero
   prime-phylo
   nanopolish

nothing that I would mind to crash for some time span.  If it can not be
ported it will be removed anyway.  So if you decide to drop Python2
support that would set a clear signal.  If it is the safest means to
get rid of the above trouble I'm all for it.

> We're discussing when exactly to drop Python 2.7 support -
> with a final compatible release in December 2019 or January 2020
> looking most likely.

Sounds sensible.

Kind regards

Andreas. 

-- 
http://fam-tille.de

Bug#907231: Ping - ktp-contact-list FTBFS

[Lisandro Damián Nicanor Pérez Meyer]

Hi!

El vie., 15 nov. 2019 10:45, John Scott  escribió:

> ktp-contact-list has been kept out of testing for over a year, though this
> issue is fixed by the patch and new upstream version. If help is wanted
> with this, please let it be known.
>


I'll be happy to sponsor a fix, feel free to send a merge request to
salsa.debian.org's repo and then ping me.

>

Bug#945112: debcheck: handle debhelper-compat

[Thorsten Glaser]

Package: qa.debian.org
Severity: normal

 Package declares a build time dependency on debhelper-compat (= 12) which 
cannot be satisfied on amd64.

Please hack debcheck that it works with these virtual packages. Thanks!

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

Kernel: Linux 5.3.0-1-amd64 (SMP w/2 CPU cores)
Kernel taint flags: TAINT_CRAP
Locale: LANG=C, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE=C (charmap=UTF-8)
Shell: /bin/sh linked to /bin/lksh
Init: sysvinit (via /sbin/init)

Bug#930492: pkg-config: Broken i686-w64-mingw32-pkg-config and x86_64-w64-mingw32-pkg-config

[Stephen Kitt]

Hi,

On Mon, 01 Jul 2019 08:53:49 +0200, Tollef Fog Heen  wrote:
> > On Mon, 17 Jun 2019 22:20:11 +0200, Stefan Weil  wrote:  
> > > I am not sure whether reassigning the bug to mingw-w64-tools is the best
> > > way to get a quick (intermediate) solution. If it helps, I have no
> > > objection, although I thought that patching the pkg-config package would
> > > be easier to fix that special issue.  
> > 
> > Oh well, I suppose mingw-w64-tools *is* the right place to deal with
> > this, if pkg-config is only intended to handle Debian architectures. If
> > you do reassign the bug, please upgrade it to serious and I’ll try to get
> > a fix ready in time for Buster.  
> 
> The crosswrapper in pkg-config does require that the architecture is
> known to dpkg, yes.  The /usr/bin/*-pkg-config namespace is managed by
> the pkg-config dpkg hook, so other tools should coordinate with
> pkg-config if they want to work within that area.  (I'm not even sure
> what the pkg-config directory for i686-w64-mingw32 and
> x86_64-w64-mingw32 should be.)

The MinGW-w64 packages use traditional cross-compilation paths,
so the pkg-config directory /usr/{i686,x86-64}-w64-mingw32/lib/pkgconfig.
(Not FHS-compliant, I know, but they can’t “own” the multiarch paths until
their architectures are defined in dpkg.)

I noticed that the pkg-config hook is very careful to only
touch /usr/bin/*-pkg-config links it owns. Would it be acceptable to continue
shipping MinGW-w64 pkg-config instances there? Not using crosswrapper, of
course, but a MinGW-w64-hosted implementation.

Regards,

Stephen


pgpw5j_tJfgPV.pgp
Description: OpenPGP digital signature

Bug#945057: libnet-dbus-perl FTCBFS: uses the build architecture pkg-config

[Helmut Grohne]

Hi gregor,

On Tue, Nov 19, 2019 at 06:23:35PM +0100, gregor herrmann wrote:
> On Tue, 19 Nov 2019 06:09:15 +0100, Helmut Grohne wrote:
> 
> > libnet-dbus-perl fails to find the dbus library. It does so using the
> > build architecture pkg-config, but libdbus is only installed for the
> > host architecture. Now I'm unsure how to fix this. 
> 
> Thanks for the bug report, that's an interesting one indeed.

Thank you for looking into it.

> > The common wisdom is
> > to prefix tools with the host architecture triplet. The other wisdom is
> > to pass tools as environment variables. The perl ecosystem seems to
> > follow a different route: Record paths in Config.pm. Unfortunately,
> > Config.pm neither has the triplet nor does it have pkg-config. Bummer.
> 
> So we're looking for something like 'x86_64-linux-gnu' in Config.pm
> (or pass PKG_CONFIG=x86_64-linux-gnu-pkg-config in the environment),
> right?

Yes.

> For the former,
> % perl -MConfig=config_sh -e 'print config_sh();' | grep x86_64-linux-gnu
> has quite a few results but never x86_64-linux-gnu alone.

That's also what I found.

> Right, but the good news is that I only find 23 packages (of the
> pkg-perl maintained ones) which use pkg-config in
> {Makefile,Build}.PL.

Good.

> Random thought: I wonder if PkgConfig ("a pure perl version of
> pkg-config"), packaged as libpkgconfig-perl, providing
> /usr/bin/ppkg-config, could be a helpful workaround. This would still
> require a changed build dependency and a s/pkg-config/ppkg-config/ in
> {Makefile,Build}.PL [0] but would spare us any path or architecture
> hassles. Maybe :)

I do see why it works practically. If you read /usr/bin/ppkg-confing and
look for the construction of @DEFAULT_SEARCH_PATH, you'll notice that it
checks for the existence of dpkg-architecture and effectively inserts
/usr/lib/`dpkg-architecture -qDEB_HOST_MULTIARCH`/pkgconfig into the
path. While that is what we want here, it does rely on environment
variables again. To see this try:

| $ dpkg-architecture -am68k -c ppkg-config --debug doesnotexist
| dpkg-architecture: warning: specified GNU system type m68k-linux-gnu does not 
match CC system type x86_64-linux-gnu, try setting a correct CC environment 
variable
| Can't find doesntexist.pc in any of /usr/local/lib/m68k-linux-gnu/pkgconfig 
/usr/local/lib/pkgconfig /usr/local/share/pkgconfig 
/usr/lib/m68k-linux-gnu/pkgconfig /usr/lib/pkgconfig /usr/share/pkgconfig
| use the PKG_CONFIG_PATH environment variable, or
| specify extra search paths via 'search_paths'
| $

So we still don't have our single source of truth here.

The other aspect is that this is very much Debian-specific. Given the
effort it takes to make stuff cross buildable, we want to (and do) share
that work with yocto, ptxdist, buildroot and others as much as possible.
However this transformation doesn't help any other distribution.

Last but not least, this approach breaks an important corner case. It
happens every now and then that we need to build a build tool during a
package build. Such build tools need to be built for the build
architecture (to be runnable) rather than the host architecture, so it
is the task of the build system to explicitly tell which pkgconfig files
are requested for the build and which are requested for the host.

Let me give a positive example of how this could work: meson.  When you
want to use pkg-config in meson, you say "dependency('foo')". And when
you want the build architecture pkg-config, you say "dependency('foo',
native: true)". meson then figures how to call pkg-config. Why am I
telling you this? I think that Makefile.PL should also have some syntax
to tell these apart.

> So, I did my first cross build :) (with cowbuilder and the help of
> https://wiki.debian.org/CrossCompiling ) and it worked with:

Congrats. This sounds like our workflow now mostly "just works"(tm). Let
me know if you run into problems or annoyances.

> libnet-dbus-perl_1.1.0-7_i386.deb

Do note that cross building from amd64 to i386 isn't that enlightening,
because i386 is runnable on amd64. It's nice to be able do so, but it'll
hide a number of possible problems.

Unfortunately, choosing another architecture is a little difficult at
present:
 * All the mipsen are broken, because our gcc maintainer removed mipsen
   support from the toolchain packages and requested that they live in
   special -mipsen packages. Unfortunately crossbuild-essential-* is
   still missing for all mipsen.
 * Most architectures but armel are currently skewed against amd64 due
   to linux ftbfsing on most architectures.

So at the time of this writing, the only reasonable architecture to
cross build for is armel. I hope we get better weather soon.

> [0] or `use PkgConfig …;' programmatically

This would be better, but what we really need to do here is have
PkgConfig.pm derive its default search path from perl's Config.pm.

Helmut

Bug#944874: strange phenomenon with primus + nvidia-tesla

[Patrice Duroux]

Andreas,

Many thanks for your attention!
Each boot I am observing this:

[   11.601498] bbswitch: loading out-of-tree module taints kernel.
[   11.601540] bbswitch: module verification failed: signature and/or required 
key missing - tainting kernel
[   11.601693] bbswitch: version 0.8
[   11.601697] bbswitch: Found integrated VGA device :00:02.0: 
\_SB_.PCI0.GFX0
[   11.601702] bbswitch: Found discrete VGA device :01:00.0: 
\_SB_.PCI0.PEGP.DGFX
[   11.601714] ACPI Warning: \_SB.PCI0.PEGP.DGFX._DSM: Argument #4 type 
mismatch - Found [Buffer], ACPI requires [Package] (20190703/nsarguments-59)
[   11.602324] bbswitch: detected an Optimus _DSM function
[   11.602339] pci :01:00.0: enabling device ( -> 0003)
[   11.602402] bbswitch: Succesfully loaded. Discrete card :01:00.0 is on
[   11.602900] bbswitch: disabling discrete graphics

(bbswitch is well activated keeping NVIDIA driver silent)

but then sometimes still during the boot and I don't known the reason for,
the driver tries to be loaded but without success (because by-passing bbswitch):

[   11.696440] nvidia: module license 'NVIDIA' taints kernel.
[   11.696442] Disabling lock debugging due to kernel taint
[   11.718958] nvidia-nvlink: Nvlink Core is being initialized, major device
number 241
[   12.030091] nvidia :01:00.0: enabling device ( -> 0003)
[   12.030208] nvidia :01:00.0: vgaarb: changed VGA decodes:
olddecodes=io+mem,decodes=none:owns=none
[   12.030238] NVRM: The NVIDIA GPU :01:00.0
   NVRM: (PCI ID: 10de:12b9) installed in this system has
   NVRM: fallen off the bus and is not responding to commands.
[   12.030296] nvidia: probe of :01:00.0 failed with error -1
[   12.030329] NVRM: The NVIDIA probe routine failed for 1 device(s).
[   12.030329] NVRM: None of the NVIDIA graphics adapters were initialized!
[   12.066156] nvidia-nvlink: Unregistered the Nvlink Core, major device number
241

This happens many times in the same boot process.

Can this wake-up may be due to HDMI HDA audio driver?
Because I can this such messages:

[   14.030141] snd_hda_codec_hdmi hdaudioC1D0: Unable to sync register 0x4f0800.
-5
[   14.030148] snd_hda_codec_hdmi hdaudioC1D0: HDMI: invalid ELD buf size -1
[   14.030152] snd_hda_codec_hdmi hdaudioC1D0: HDMI: invalid ELD buf size -1
...

Then most of the time, optirun is not able to work at all.
Is the NVIDIA driver after such boot case in a state that bbswitch cannot
operate with correctly.
Sorry don't know how to help more!...

Patrice

Bug#945109: wrong section name [hp_color_laserjet_mfp_m278-m281] in file /usr/share/hplip/data/models/models.dat

[Brian Potkin]

tags 945109 upstream
thanks 



On Tue 19 Nov 2019 at 19:57:56 +0100, Lutz Kittler wrote:

> Package: libsane-hpaio
> Version: 3.19.11+dfsg0-1
> 
> When hp-probe is started for printer models HP ColorLaserJet MFP M278-M281
> hp-probe found hp_colorlaserjet_mfp_m278-m281:
> hp-probe[3937]: debug: Found device: {'num_devices': 1, 'num_ports': 1,
> 'product_id': 'T6B82A', 'status_code': 0, 'device2': '0', 'device3':
> '0', 'note': '', 'device1':
> 'MFG:HP;CMD:PJL,PML,PCLXL,PWG_RASTER,URP,PCL,PDF,POSTSCRIPT;MDL:HP
> ColorLaserJet MFP M278-M281;CLS:PRINTER;DES:HP Color LaserJet MFP
> M281fdw;MEM:MEM=213MB;PRN:T6B82A;COMMENT:RES=600x8;LEDMDIS:USB#ff#04#01;CID:HPLJPDLV1;IPP-E:FF-04-01,FF-04-01,FF-09-01,FF-09-01;eSCL:FF-04-01,FF-04-01,FF-09-01,FF-09-01;MCT:MF;MCL:DL;MCV:2.0;',
> 'mac': '7440BB7C3BE0', 'ip': '192.168.178.182', 'hn': 'NPIB59CB3'}
> hp-probe[3937]: debug: Cache miss: hp_colorlaserjet_mfp_m278-m281
> 
> but section name in models.dat is written as
> [hp_color_laserjet_mfp_m278-m281]
> so printers cannot be found

Thank you for your informative report, Lutz. This is not a Debian issue.
See

  https://bugs.launchpad.net/hplip/+bug/1851013

Regards,

Brian.

Bug#945111: pal: GLib-CRITICAL error

[Tomas Persson]

Package: pal
Version: 0.4.3-8.1+b5
Severity: important

Dear Maintainer,

When in interactive mode (pal -m), errors are printed to the screen 
when I try to go backwards in the calendar, and it is impossible to go 
backwards. The errors are of the form


"(process:16820): GLib-CRITICAL **: 20:00:07.279: g_date_add_days: assertion 'ndays <= 
G_MAXUINT32 - d->julian_days' failed"

best regards
Tomas Persson


-- System Information:
Debian Release: 10.2
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable'), (500, 
'oldstable')

Architecture: amd64 (x86_64)

Kernel: Linux 4.19.0-6-amd64 (SMP w/2 CPU cores)
Kernel taint flags: TAINT_WARN
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_GB:en (charmap=UTF-8)

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

Versions of packages pal depends on:
ii  libc6 2.28-10
ii  libglib2.0-0  2.58.3-2+deb10u2
ii  libncursesw6  6.1+20181013-2+deb10u2
ii  libreadline8  8.0-3
ii  libtinfo6 6.1+20181013-2+deb10u2

pal recommends no packages.

Versions of packages pal suggests:
ii  texlive  2018.20190227-2

-- no debconf information

Bug#945110: RM: check-mk/experimental -- RoQA; obsolete

[Moritz Muehlenhoff]

Package: ftp.debian.org
Severity: normal

check-mk was already removed from unstable in #942002, it should
also be removed from experimental (as indicated by Matt in
#933217)

Cheers,
Moritz

Bug#945097: please ignore /etc/logrotate.d/*.bak files by default

[Christian Göttsche]

> ".bak" is the traditional extension for local backup files used by various
> editors (e.g. mg). Do you think the *.bak files in /etc/logrotate.d could
> be ignored by default, similar to *~ and others?
>
> Of course I have found the tabooext option, but apparently it cannot be
> set in /etc/logrotate.d/0.conf, and changing the default in logrotate.conf
> is not an option, because /etc/logrotate.d was introduced to *avoid*
> changing logrotate.conf.

Normally that is exactly what the main /etc/logrotate.conf file is for:
either setting rules affecting all rotation targets (like dateext) or
basic options (like tabooext).

Of course .bak files could be set to be ignored by default (build-in).
Thinking about it...

Bug#945109: wrong section name [hp_color_laserjet_mfp_m278-m281] in file /usr/share/hplip/data/models/models.dat

[Lutz Kittler]

Package: libsane-hpaio
Version: 3.19.11+dfsg0-1

When hp-probe is started for printer models HP ColorLaserJet MFP M278-M281
hp-probe found hp_colorlaserjet_mfp_m278-m281:
hp-probe[3937]: debug: Found device: {'num_devices': 1, 'num_ports': 1,
'product_id': 'T6B82A', 'status_code': 0, 'device2': '0', 'device3':
'0', 'note': '', 'device1':
'MFG:HP;CMD:PJL,PML,PCLXL,PWG_RASTER,URP,PCL,PDF,POSTSCRIPT;MDL:HP
ColorLaserJet MFP M278-M281;CLS:PRINTER;DES:HP Color LaserJet MFP
M281fdw;MEM:MEM=213MB;PRN:T6B82A;COMMENT:RES=600x8;LEDMDIS:USB#ff#04#01;CID:HPLJPDLV1;IPP-E:FF-04-01,FF-04-01,FF-09-01,FF-09-01;eSCL:FF-04-01,FF-04-01,FF-09-01,FF-09-01;MCT:MF;MCL:DL;MCV:2.0;',
'mac': '7440BB7C3BE0', 'ip': '192.168.178.182', 'hn': 'NPIB59CB3'}
hp-probe[3937]: debug: Cache miss: hp_colorlaserjet_mfp_m278-m281

but section name in models.dat is written as
[hp_color_laserjet_mfp_m278-m281]
so printers cannot be found

Bug#945108: RFS: surgescript/0.5.4-1 [ITP] -- Scripting language for games

[Carlos Donizete Froes]

Package: sponsorship-requests
Severity: normal

Dear mentors,

I am looking for a sponsor for my package "surgescript"

 * Package name: surgescript
   Version : 0.5.4-1
   Upstream Author : Alexandre Martins 
 * URL : https://docs.opensurge2d.org
 * License : Apache-2.0
 * Vcs : https://salsa.debian.org/games-team/surgescript
   Section : graphics

It builds those binary packages:

  surgescript - Scripting language for games

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

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

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

  dget -x 
https://mentors.debian.net/debian/pool/main/s/surgescript/surgescript_0.5.4-1.dsc

Changes since the last upload:

   * Initial release (Closes: #945104)

Regards,

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

Bug#945049: gnutls: Please prefer PFS ciphers over plain RSA ones.

[Andreas Metzler]

On 2019-11-18 Sebastian Andrzej Siewior  wrote:
[request for changing cipher list]

Could you please take this upstream? This is not a point where Debian
will choose different defaults than upstream.

Thanks, cu Andreas

Bug#945107: berusky2: Segmentation fault in animation module

[Asher Gordon]

Package: berusky2
Version: 0.10-8
Severity: important
Tags: patch

Dear Maintainer,

Certain animations (such as pushing a block over a ledge) cause berusky2
to crash. This has been fixed upstream in commit 97ed81c (the bug is due
to trying to store a pointer in an integer type too small to store a
pointer).

For your convenience, here is a patch from that commit (created with
`git format-patch 97ed^..97ed'):
From 97ed81cc7fd48c4955d15efd5a341d6af4e96759 Mon Sep 17 00:00:00 2001
From: Martin Stransky 
Date: Sun, 3 Jan 2016 15:28:37 +0100
Subject: [PATCH] Fixed crashes in animation module

---
 src/komat/Berusky3d.h | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/src/komat/Berusky3d.h b/src/komat/Berusky3d.h
index 2b8bcc4..aef18c7 100644
--- a/src/komat/Berusky3d.h
+++ b/src/komat/Berusky3d.h
@@ -181,8 +181,8 @@ typedef struct _GLOBALNI_KONT_ANIMACE
 
   int *p_flag;  // kofoluv flag
   void *p_param;// kofolova end funkce
-  int param;
-  int param2;
+  size_ptr param;
+  size_ptr param2;
   END_FUNKCE p_endfce;
   int konec;
 
-- 
2.24.0


You can import the patch into quilt with

  quilt import Fixed-crashes-in-animation-module.patch

In addition, upstream commit df8d2a4 claims to fix crashes in the
particle engine (I haven't noticed these crashes yet).

Also, since upstream hasn't made a release in a while, maybe it would be
a good idea to update the Debian package against the latest upstream
commit.


Thanks,
Asher


-- 
: The following (relative to AutoSplit 1.03) attempts to please everyone
: and perhaps pleases no one:

I think that's way cool.
-- Larry Wall in <199709292015.naa09...@wall.org>


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

Kernel: Linux 5.2.0-3-amd64 (SMP w/2 CPU cores)
Kernel taint flags: TAINT_FIRMWARE_WORKAROUND
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=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 berusky2 depends on:
ii  berusky2-data   0.9-2
ii  libalut01.1.0-6
ii  libc6   2.29-3
ii  libgcc1 1:9.2.1-19
ii  libgl1  1.1.0-1+b1
ii  libglu1-mesa [libglu1]  9.0.0-2.1+b3
ii  libopenal1  1:1.19.1-1+b1
ii  libsdl-image1.2 1.2.12-12
ii  libsdl1.2debian 1.2.15+dfsg2-5
ii  libstdc++6  9.2.1-19
ii  libvorbisfile3  1.3.6-2
ii  libx11-62:1.6.8-1
ii  zlib1g  1:1.2.11.dfsg-1+b1

berusky2 recommends no packages.

berusky2 suggests no packages.

-- no debconf information


signature.asc
Description: PGP signature

Bug#944906: gitlab fails to install with missing rubyzip dependency

[Utkarsh Gupta]

On Sun, 17 Nov 2019 19:04:03 +0530 Pirate Praveen
 wrote:
> Package: gitlab
>
> Severity: grave
>
> version: 12.2.9-2
>
>
> Could not find gem 'rubyzip (>= 1.2.2, ~> 1.2)' in any of the gem
> sources listed in your Gemfile.
>
>
> All tests pass with rubyzip 2.0
>  so we can just
> add this patch to Gemfile and bump minimum version in control to >=
> 2.0~ to force new version in updates.
>
>
> Though we need only ~> 2.0 instead of ~> 2.0.0 in Gemfile.

Right, since the CI passes on my fork, I've written a patch that is
attached.
Hope that should fix this :)
Additionally shall fix this in the repo as well.


Best,
Utkarsh
Description: This patch bumps rubyzip to 2.0.
Author: Utkarsh Gupta 
Bug-Debian: https://bugs.debian.org/944906
Last-Update: 2019-11-19

--- a/Gemfile
+++ b/Gemfile
@@ -61,7 +61,7 @@
 
 # GitLab Pages
 gem 'validates_hostname', '~> 1.0', '>= 1.0.6'
-gem 'rubyzip', '~> 1.2', '>= 1.2.2', require: 'zip'
+gem 'rubyzip', '~> 2.0', '>= 2.0.0', require: 'zip'
 # GitLab Pages letsencrypt support
 gem 'acme-client', '~> 2.0', '>= 2.0.2'
 
--- a/Gemfile.lock
+++ b/Gemfile.lock
@@ -845,7 +845,7 @@
   sexp_processor (~> 4.9)
 rubyntlm (0.6.2)
 rubypants (0.2.0)
-rubyzip (1.2.2)
+rubyzip (2.0.0)
 rugged (0.28.3.1)
 safe_yaml (1.0.4)
 sanitize (4.6.6)
@@ -1220,7 +1220,7 @@
   ruby-prof (~> 0.17.0)
   ruby-progressbar
   ruby_parser (~> 3.8)
-  rubyzip (~> 1.2.2)
+  rubyzip (~> 2.0.0)
   rugged (~> 0.28)
   sanitize (~> 4.6)
   sassc-rails (~> 2.1.0)


signature.asc
Description: OpenPGP digital signature

Bug#945055: intel-microcode: CPU runs at considerably higher temperatures

[Henrique de Moraes Holschuh]

On Tue, Nov 19, 2019, at 01:56, Christoph Anton Mitterer wrote: 
> With the most recent upgrade, the CPU seems to run at considerably
> higher temperatures.

...

> microcode updated early to revision 0xca, date = 2019-09-26

...

> Now another strange thing:
> With the NEW microcode, once some load was put on the system, even when
> this is gone and the CPU back to basically no utilisation, the temperatures
> are at a *much* higher level and stay there, for whichever reason:
> 
> coretemp-isa-
> Adapter: ISA adapter
> Package id 0:  +76.0°C  (high = +100.0°C, crit = +100.0°C)
> Core 0:+70.0°C  (high = +100.0°C, crit = +100.0°C)
> Core 1:+69.0°C  (high = +100.0°C, crit = +100.0°C)

Looks quite bad, indeed.

I need the output of "cat /proc/cpuinfo" and also of "grep . 
/sys/devices/system/cpu/vulnerabilities/*" please. We need to know exactly what 
your processor is, and what got enabled.

Alternatively, you can report this directly upstream at:
https://github.com/intel/Intel-Linux-Processor-Microcode-Data-Files/issues

They will need the same information I requested.

> Is this a problem with the microcode or a kinda expected side-effect
> of the security workarounds?

There is nothing expected about it, as far as I know.

-- 
  Henrique de Moraes Holschuh 

Bug#945030: lintian: legacy-foo++ test package fails with

[Felix Lechner]

Hi Chris,

On Mon, Nov 18, 2019 at 9:03 AM Chris Lamb  wrote:
>
> I can't seem to build the test packages at the locally. The legacy-foo++
> test appears to failing for me:

This may help with better error reporting. Feedback would be
appreciated. Alternatively, please let me know which module you were
missing.

   
https://salsa.debian.org/lintian/lintian/commit/4dbfc3fe43a6ece114f6a38c0864ad0b41d2cd58

Kind regards,
Felix Lechner

Bug#945106: ITP: r-cran-ggraph -- GNU R implementation of grammar of graphics for graphs and networks

[Andreas Tille]

Package: wnpp
Severity: wishlist

Subject: ITP: r-cran-ggraph -- GNU R implementation of grammar of graphics for 
graphs and networks
Package: wnpp
Owner: Andreas Tille 
Severity: wishlist

* Package name: r-cran-ggraph
  Version : 2.0.0
  Upstream Author : Thomas Lin Pedersen
* URL : https://cran.r-project.org/package=ggraph
* License : MIT
  Programming Lang: GNU R
  Description : GNU R implementation of grammar of graphics for graphs and 
networks
 The grammar of graphics as implemented in ggplot2 is a poor fit for
 graph and network visualizations due to its reliance on tabular data input.
 ggraph is an extension of the ggplot2 API tailored to graph visualizations
 and provides the same flexible approach to building up plots layer by layer.

Remark: This package is maintained by Debian R Packages Maintainers at
   https://salsa.debian.org/r-pkg-team/r-cran-ggraph

Bug#945105: intel-gpu-tools: please make the build reproducible

[Chris Lamb]

Source: intel-gpu-tools
Version: 1.24-1
Severity: wishlist
Tags: patch
User: reproducible-bui...@lists.alioth.debian.org
Usertags: buildpath
X-Debbugs-Cc: reproducible-b...@lists.alioth.debian.org

Hi,

Whilst working on the Reproducible Builds effort [0] we noticed that
intel-gpu-tools could not be built reproducibly.

This is because it embedded the path to the test directory in the
binary. As we don't even build the tests (according to a comments,
they FTBFS...) my attached patch is almost-certainly harmless.

Patch attached.

 [0] https://reproducible-builds.org/


Best wishes,

-- 
  ,''`.
 : :'  : Chris Lamb
 `. `'`  la...@debian.org / chris-lamb.co.uk
   `-
--- a/debian/patches/0001_Reproducible-builds.patch 1969-12-31 
19:00:00.0 -0500
--- b/debian/patches/0001_Reproducible-builds.patch 2019-11-19 
12:58:31.782550136 -0500
@@ -0,0 +1,15 @@
+Description: Make the build reproducible
+Author: Chris Lamb 
+Last-Update: 2019-11-19
+
+--- intel-gpu-tools-1.24.orig/lib/meson.build
 intel-gpu-tools-1.24/lib/meson.build
+@@ -112,7 +112,7 @@ if chamelium.found()
+   lib_sources += 'igt_chamelium_stream.c'
+ endif
+ 
+-srcdir = join_paths(meson.source_root(), 'tests')
++srcdir = join_paths('.', 'tests')
+ 
+ lib_version = vcs_tag(input : 'version.h.in', output : 'version.h',
+ fallback : 'NO-GIT',
--- a/debian/patches/series 2019-11-19 10:28:42.584479614 -0500
--- b/debian/patches/series 2019-11-19 12:34:03.769612335 -0500
@@ -1 +1,2 @@
 #placeholder
+0001_Reproducible-builds.patch

Bug#808911: dh-make-perl: Switch from libdpkg-parse-perl to libdpkg-perl modules

[gregor herrmann]

On Sun, 27 Mar 2016 16:32:12 +0200, gregor herrmann wrote:

> > Seems to work (tests pass), but is noticeably slower:
> > 
> >  * without the patch
> >dh-make-perl-dev --cpan Catalyst  29,33s user 2,30s system 94% cpu 
> >33,473 total
> >(second try, after one dummy to fill CPAN/dh-make-perl caches)
> > 
> > 
> >  * with the patch
> >dh-make-perl-dev --cpan Catalyst  233,96s user 3,13s system 99% cpu 
> >3:59,17 total
> > 
> > (both timings were on the gregoa/apt-file-3 branch)
> 
> Ouch; 4 minutes seems a bit suboptimal :/
> 
> Ok, I guess this change won't make it into 0.90 in the current form
> :)

A few years later … I tried again. After massaging the patch a bit to
apply against git master, I get, with the same methodology:

* without the patch: 169.02s user 22.11s system 112% cpu 2:49.26 total
* with the patch:638.29s user 41.14s system 101% cpu 11:06.72 total

I guess that's still to slow :)


For posterity, I'm attaching the refreshed patch.


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: Rolling Stones
From 6c58729e7a13c5ae98b07e689a32cd25ed642cf5 Mon Sep 17 00:00:00 2001
From: Guillem Jover 
Date: Tue, 29 Sep 2015 15:06:34 +0200
Subject: [PATCH] Switch from libdpkg-parse-perl to libdpkg-perl modules

---
 Build.PL|  3 ++-
 debian/control  |  1 -
 lib/Debian/Control/FromCPAN.pm  | 17 +++--
 lib/DhMakePerl/Command/Packaging.pm | 16 +---
 4 files changed, 14 insertions(+), 23 deletions(-)

diff --git a/Build.PL b/Build.PL
index 22db76f..fb57f99 100644
--- a/Build.PL
+++ b/Build.PL
@@ -7,7 +7,6 @@ my $builder = My::Builder->new(
 module_name => 'DhMakePerl',
 license => 'gpl',
 recommends  => {
-'DPKG::Parse' => 0.02,
 'Git' => 0,
 'IO::Dir' => 0,
 },
@@ -24,6 +23,8 @@ my $builder = My::Builder->new(
 'CPAN::Meta'=> 0,
 'Cwd'   => 0,
 'Dpkg'  => 0,
+'Dpkg::Index'   => 0,
+'Dpkg::Control::Types'  => 0,
 'Dpkg::Source::Package' => '1.01',
 'Email::Address::XS'=> '1.01',
 'Email::Date::Format'   => 0,
diff --git a/debian/control b/debian/control
index d9bcdf5..b8405be 100644
--- a/debian/control
+++ b/debian/control
@@ -79,7 +79,6 @@ Depends: debhelper (>= 12),
 Recommends: apt-file (>= 3),
 apt (>= 1.1.8),
 git,
-libdpkg-parse-perl,
 libmodule-build-perl,
 libsys-cpu-perl,
 pristine-tar
diff --git a/lib/Debian/Control/FromCPAN.pm b/lib/Debian/Control/FromCPAN.pm
index f7fefc5..e8edaae 100644
--- a/lib/Debian/Control/FromCPAN.pm
+++ b/lib/Debian/Control/FromCPAN.pm
@@ -54,11 +54,11 @@ a required module belongs.
 
 =item dpkg_available
 
-An instance of L to be used when checking whether
+An instance of L to be used when checking whether
 the locally available package is the required version. For example:
 
-my $available = DPKG::Parse::Available->new;
-$available->parse;
+my $available = Dpkg::Index->new(type => CTRL_INFO_PKG);
+$available->load("$Dpkg::ADMINDIR/available");
 
 =item dir
 
@@ -299,7 +299,7 @@ L class) and a list of missing modules.
 
 Installed packages and perl core are searched first, then the APT contents.
 
-If a DPKG::Parse::Available object is passed, also check the available package version
+If a Dpkg::Index object is passed, also check the available package version.
 
 =cut
 
@@ -340,12 +340,12 @@ sub find_debs_for_modules {
 );
 
 # Check the actual version available, if we've been passed
-# a DPKG::Parse::Available object
+# a Dpkg::Index object
 if ( $dpkg_available ) {
 my @available;
 my @satisfied = grep {
-if ( my $pkg = $dpkg_available->get_package('name' => $_) ) {
-my $have_pkg = Debian::Dependency->new( $_, '=', $pkg->version );
+if ( my $pkg = $dpkg_available->get_by_key($_) ) {
+my $have_pkg = Debian::Dependency->new( $_, '=', $pkg->{Version} );
 push @available, $have_pkg;
 $have_pkg->satisfies($direct_dep);
 }
@@ -360,9 +360,6 @@ sub find_debs_for_modules {
 push @missing, $module;
 }
 }
-else {
-warn "DPKG::Parse not available. Not checking version of $module.";
-}
 }
 }
 
diff --git 

Bug#945072: qemu 4.1 block size regression

[Jamie Heilman]

Michael Tokarev wrote:
> 19.11.2019 13:44, Jamie Heilman wrote:
> > Package: qemu-system-x86
> > Version: 1:4.1-1+b4
> 
> > [...]  If I switch back to 3.1+dfsg-8+deb10u3
> > the corruption vanishes.
> 
> What do you switch back? qemu-system-x86 or qemu-utils?

Both qemu-system-x86 and qemu-utils but only on the build machine, the
qemu version on the system that winds up actually running the guests is
older (Debian 8 era).

> I'd love to understand where the problem lies - in the one
> of the conversion steps, producing broken image somehow,
> or within the qemu-system with some sort of good image?

Sure, I'll try mixing & matching and see if I can narrow it down and
let you know.

> There's a known (just discovered) corruption with
> qemu-img convert within 4.1, maybe it is the problematic
> spot. Please try it with the qemu-img from earlier version.
> Also, try qemu-img check on each step resulting in a qcow
> image (there's nothing to check on the lvm volume ofcours).
> 
> Thank you!
> 
> /mjt

-- 
Jamie Heilman http://audible.transient.net/~jamie/

Bug#945061: uninstallable due to Thunderbird security update to version 68

[Carsten Schoenert]

Hello Philipp,

Am 19.11.19 um 08:43 schrieb Philipp Huebner:
> Hi,
> 
> due to the security update introducing Thunderbird 68,
> xul-ext-sogo-connector has become uninstallable and thus unusable in all
> suites from oldstable to unstable.
> 
> Could you please package sogo-connector 68?
> 
> (old-)stable updates would also be greatly appreciated.
> I'd be happy to help test updated packages.

I'd like to do so but unfortunately my time for doing so is really
limited right now. The free time I have is mainly focused on working n
Thunderbird itself.
Also upstream has released a fixed version just a few weeks ago.

For now I just can suggest to use the upstream version of this AddOn.

-- 
Regards
Carsten Schoenert

Bug#944964: dh-make-perl: Module accesses internal dpkg database

[gregor herrmann]

On Tue, 19 Nov 2019 01:15:52 +0100, Guillem Jover wrote:

> Hi!

Hola!
And thanks for looking into this question.
 
> > I've now come up with a first patch (pushed to git) which seems to
> > work and which is not terribly slow.
> > t/DpkgLists.t still passes and takes ~9 seconds; with the original
> > _cat_lists() it was more like 2.5 seconds but well.
> Hmm ouch, I didn't expect it to be that slow. 

Please note that t/DpkgLists.t runs 7 tests, so _cat_lists() is
called 7 times; the speed loss per run is not so bad.

> I've poked a bit, and
> attached are some changes I've got locally that should shave a couple
> of seconds. Will keep looking for further improvements. 

Cool, thanks.

> But I guess
> in the end dpkg-query is just doing more work, as it first needs to
> parse the status db, build all the internal data structures, and then
> build the output according to the format specified.

Right, dpkg-query has to do more than the old implementation which
just read the *.list files.
 
> Maybe I need to look into making «dpkg-query --listfiles» require no
> packages to dump the entire thing like in this case. But I'm not sure
> how common this need is? But much of the involved work above would
> still be done all the same, we'd just skip part of the formatting.

I agree that it's probably not worth the effort, as this use case is
a bit niche, and the speedup would probably be not that enormous.
 

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: Rolling Stones


signature.asc
Description: Digital Signature

Bug#935098: nmap 7.80: random segfaults while scanning

[Bernhard Übelacker]

Dear Maintainer,
I tried to get some more information and was able
to record a crash with rr.

When continuing from below backtrace [2] it continues
into a recursion until the segfault is reached.
Therefore this might not be an nmap bug.

This led me to this bug report [1], which mentions
upstream lua-lpeg version 1.0.1 fixes this issue,
or alternatively has a patch for lua-lpeg 1.0.0.

Kind regards
Bernhard


[1] https://bugs.debian.org/942031


[2]
(rr) bt
#0  0x7f233d19d4cc in hascaptures (tree=0x556ae6cfca74, 
tree@entry=0x556ae6cfca94) at lpcode.c:144
#1  0x7f233d19d4cc in hascaptures (tree=tree@entry=0x556ae6cfca8c) at 
lpcode.c:144
#2  0x7f233d19d4cc in hascaptures (tree=0x556ae6cfca84, 
tree@entry=0x556ae6cfca94) at lpcode.c:144
#3  0x7f233d19d4cc in hascaptures (tree=tree@entry=0x556ae6cfca8c) at 
lpcode.c:144
#4  0x7f233d19d4cc in hascaptures (tree=0x556ae6cfca84, 
tree@entry=0x556ae6cfc9fc) at lpcode.c:144
#5  0x7f233d19d4cc in hascaptures (tree=tree@entry=0x556ae6cfc9f4) at 
lpcode.c:144
#6  0x7f233d19e1ec in codecapture (fl=0x7f233d19f280 , tt=-1, 
tree=0x556ae6cfc9ec, compst=0x73bd2930) at lpcode.c:720
#7  codegen (compst=compst@entry=0x73bd2930, 
tree=tree@entry=0x556ae6cfc9ec, opt=opt@entry=0, tt=tt@entry=-1, 
fl=fl@entry=0x7f233d19f280 ) at lpcode.c:905
#8  0x7f233d19e7f9 in codegrammar (compst=compst@entry=0x73bd2930, 
grammar=grammar@entry=0x556ae6cfc974) at lpcode.c:850
#9  0x7f233d19e17b in codegen (compst=compst@entry=0x73bd2930, 
tree=tree@entry=0x556ae6cfc974, opt=opt@entry=0, tt=tt@entry=-1, 
fl=fl@entry=0x7f233d19f280 ) at lpcode.c:907
#10 0x7f233d19e30c in codecapture (fl=0x7f233d19f280 , tt=-1, 
tree=0x556ae6cfc96c, compst=0x73bd2930) at lpcode.c:726
#11 codegen (compst=compst@entry=0x73bd2930, 
tree=tree@entry=0x556ae6cfc96c, opt=opt@entry=0, tt=tt@entry=-1, 
fl=fl@entry=0x7f233d19f280 ) at lpcode.c:905
#12 0x7f233d19e30c in codecapture (fl=0x7f233d19f280 , tt=-1, 
tree=0x556ae6cfc964, compst=0x73bd2930) at lpcode.c:726
#13 codegen (compst=compst@entry=0x73bd2930, tree=0x556ae6cfc964, 
tree@entry=0x556ae6cfc86c, opt=opt@entry=0, tt=tt@entry=-1, 
fl=fl@entry=0x7f233d19f280 ) at lpcode.c:905
#14 0x7f233d19e30c in codecapture (fl=0x7f233d19f280 , tt=-1, 
tree=0x556ae6cfc864, compst=0x73bd2930) at lpcode.c:726
#15 codegen (compst=compst@entry=0x73bd2930, 
tree=tree@entry=0x556ae6cfc864, opt=opt@entry=0, tt=tt@entry=-1, 
fl=fl@entry=0x7f233d19f280 ) at lpcode.c:905
#16 0x7f233d19e7f9 in codegrammar (compst=compst@entry=0x73bd2930, 
grammar=grammar@entry=0x556ae6cfc704) at lpcode.c:850
#17 0x7f233d19e17b in codegen (compst=compst@entry=0x73bd2930, 
tree=tree@entry=0x556ae6cfc704, opt=opt@entry=0, tt=tt@entry=-1, 
fl=fl@entry=0x7f233d19f280 ) at lpcode.c:907
#18 0x7f233d19e973 in compile (L=L@entry=0x556ae88bb058, p=0x556ae6cfc6f8) 
at lpcode.c:977
#19 0x7f233d19bbc4 in prepcompile (L=L@entry=0x556ae88bb058, p=, idx=1) at lptree.c:1099
#20 0x7f233d19d01b in lp_match (L=0x556ae88bb058) at lptree.c:1154
#21 0x7f233d16a585 in luaD_precall (L=L@entry=0x556ae88bb058, 
func=func@entry=0x556ae88bb190, nresults=nresults@entry=-1) at ldo.c:365
#22 0x7f233d16a735 in luaD_precall (L=L@entry=0x556ae88bb058, 
func=func@entry=0x556ae88bb190, nresults=nresults@entry=-1) at ldo.c:344
#23 0x7f233d1775d5 in luaV_execute (L=L@entry=0x556ae88bb058) at lvm.c:1149
#24 0x7f233d16a820 in unroll (L=0x556ae88bb058, ud=) at 
ldo.c:555
#25 0x7f233d169d82 in luaD_rawrunprotected (L=L@entry=0x556ae88bb058, 
f=f@entry=0x7f233d16a830 , ud=ud@entry=0x73bd2e1c) at ldo.c:142
#26 0x7f233d16aa35 in lua_resume (L=L@entry=0x556ae88bb058, 
from=from@entry=0x556ae673a328, nargs=, nargs@entry=2) at 
ldo.c:662
#27 0x7f233d17cc57 in auxresume (L=L@entry=0x556ae673a328, 
co=co@entry=0x556ae88bb058, narg=2) at lcorolib.c:39
#28 0x7f233d17cfa7 in luaB_coresume (L=0x556ae673a328) at lcorolib.c:60
#29 0x7f233d16a585 in luaD_precall (L=L@entry=0x556ae673a328, 
func=func@entry=0x556ae84e7620, nresults=nresults@entry=3) at ldo.c:365
#30 0x7f233d16a735 in luaD_precall (L=L@entry=0x556ae673a328, 
func=func@entry=0x556ae84e7620, nresults=nresults@entry=3) at ldo.c:344
#31 0x7f233d177355 in luaV_execute (L=L@entry=0x556ae673a328) at lvm.c:1134
#32 0x7f233d16a998 in luaD_call (L=L@entry=0x556ae673a328, func=, nResults=nResults@entry=0) at ldo.c:496
#33 0x7f233d16a9c1 in luaD_callnoyield (L=L@entry=0x556ae673a328, 
func=, nResults=nResults@entry=0) at ldo.c:506
#34 0x7f233d1664cc in lua_callk (L=L@entry=0x556ae673a328, 
nargs=nargs@entry=2, nresults=nresults@entry=0, ctx=ctx@entry=0, k=k@entry=0x0) 
at lapi.c:924
#35 0x556ae5dfd773 in run_main (L=0x556ae673a328) at nse_main.cc:668
#36 0x7f233d16a585 in luaD_precall (L=L@entry=0x556ae673a328, 
func=0x556ae84e73d0, nresults=0) at ldo.c:365
#37 0x7f233d16a963 in luaD_precall (nresults=, 
func=, 

Bug#941430: Kalarm sound, image alarms never worked, and then text alarms stopped working

[David Jarvie]

KAlarm image alarms have now been fixed for the forthcoming KDE Applications 
19.12 release, by commit 
https://cgit.kde.org/kalarm.git/commit/?h=release/19.12=2e2b77207eb1e4b631da94633484d0695e1dc0cd
 

-- 
David Jarvie.
KDE developer.
KAlarm author -- http://www.astrojar.org.uk/kalarm

Bug#945069: thunderbird: when I open thunderbird a giant screen appears with code that does not leave visibility to use it.

[Carsten Schoenert]

Hello Thunderbird bug,

Am 19.11.19 um 10:41 schrieb Thunderbird bug:
> Package: thunderbird
> Version: 1:68.2.2-1~deb10u1
> Severity: important
> 
> Dear Maintainer,
> 
> *** Reporter, please consider answering these questions, where appropriate ***
> 
>* What led up to the situation?
>* What exactly did you do (or not do) that was effective (or
>  ineffective)?
>* What was the outcome of this action?
>* What outcome did you expect instead?
> 
> *** End of the template - remove these template lines ***

have you noticed the questions above?

What should we in your impression now do? We have no idea what Desktop
Environmnet you are using nor what you have probably already done yet.

Some more points to consider before reporting are written to the wiki.

https://wiki.debian.org/Thunderbird#Bug_Reporting_.2F_Issues

-- 
Regards
Carsten Schoenert

Bug#945072: qemu 4.1 block size regression

[Michael Tokarev]

19.11.2019 13:44, Jamie Heilman wrote:
> Package: qemu-system-x86
> Version: 1:4.1-1+b4

> [...]  If I switch back to 3.1+dfsg-8+deb10u3
> the corruption vanishes.

What do you switch back? qemu-system-x86 or qemu-utils?

I'd love to understand where the problem lies - in the one
of the conversion steps, producing broken image somehow,
or within the qemu-system with some sort of good image?

There's a known (just discovered) corruption with
qemu-img convert within 4.1, maybe it is the problematic
spot. Please try it with the qemu-img from earlier version.
Also, try qemu-img check on each step resulting in a qcow
image (there's nothing to check on the lvm volume ofcours).

Thank you!

/mjt

Bug#945057: libnet-dbus-perl FTCBFS: uses the build architecture pkg-config

[gregor herrmann]

On Tue, 19 Nov 2019 06:09:15 +0100, Helmut Grohne wrote:

> libnet-dbus-perl fails to find the dbus library. It does so using the
> build architecture pkg-config, but libdbus is only installed for the
> host architecture. Now I'm unsure how to fix this. 

Thanks for the bug report, that's an interesting one indeed.

> The common wisdom is
> to prefix tools with the host architecture triplet. The other wisdom is
> to pass tools as environment variables. The perl ecosystem seems to
> follow a different route: Record paths in Config.pm. Unfortunately,
> Config.pm neither has the triplet nor does it have pkg-config. Bummer.

So we're looking for something like 'x86_64-linux-gnu' in Config.pm
(or pass PKG_CONFIG=x86_64-linux-gnu-pkg-config in the environment),
right?

For the former,
% perl -MConfig=config_sh -e 'print config_sh();' | grep x86_64-linux-gnu
has quite a few results but never x86_64-linux-gnu alone.

> So what is a good way to get the right pkg-config into the Makefile.PL?

(And Build.PL.)
I guess that's a question for Niko …
 
> I don't like the patch, because it creates two routes to communicate the
> host architecture: Config.pm and environment. If these communication
> methods are not in sync, bad things happen. I'd much prefer to have a
> single source of truth here.

Ack.
 
> Consider this bug an "example bug". Using pkg-config in Makefile.PL is
> likely something that happens elsewhere. It'll need fixing a few times.

Right, but the good news is that I only find 23 packages (of the
pkg-perl maintained ones) which use pkg-config in
{Makefile,Build}.PL.

> I'd like to get to a good solution here before filing more of them,
> because libnet-dbus-perl nicely isolates this issue.

Ack.


Random thought: I wonder if PkgConfig ("a pure perl version of
pkg-config"), packaged as libpkgconfig-perl, providing
/usr/bin/ppkg-config, could be a helpful workaround. This would still
require a changed build dependency and a s/pkg-config/ppkg-config/ in
{Makefile,Build}.PL [0] but would spare us any path or architecture
hassles. Maybe :)


*Some times later*


So, I did my first cross build :) (with cowbuilder and the help of
https://wiki.debian.org/CrossCompiling ) and it worked with:

+   libpkgconfig-perl:native,
+   perl-xs-dev,
+   perl:native

and a patch which does s/pkg-config/ppkg-config/ in Makefile.PL, and
I get:

libnet-dbus-perl_1.1.0-7_i386.deb
-
 new Debian package, version 2.0.
 size 183472 bytes: control archive=3128 bytes.
 917 bytes,19 lines  control
8013 bytes,88 lines  md5sums
 Package: libnet-dbus-perl
 Version: 1.1.0-7
 Architecture: i386


I've pushed these changes to a new "cross-945057" branch in
https://salsa.debian.org/perl-team/modules/packages/libnet-dbus-perl.git



Cheers,
gregor

[0] or `use PkgConfig …;' programmatically

-- 
 .''`.  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: Rolling Stones


signature.asc
Description: Digital Signature

Bug#944295: thunderbird: Spellcheck fixed to "English (United States)"

[Carsten Schoenert]

Control: tags -1 pending
thanks

Hello Raphaël,

Am 19.11.19 um 16:07 schrieb Raphaël Bleuse:
> It seems one may configure the DICPATH environment variable to point to 
> the location. This is documented in the following thread:
> https://bugs.launchpad.net/ubuntu/+source/thunderbird/+bug/1847247
> 
> Hope this helps

Absolutely!
Adding as a quick test a line

export DICPATH=/usr/share/hunspell

to the wrapper script /usr/bin/thunderbird brings back all the
dictionaries I've installed long ago.

It's really some kind of an shame that Mozilla isn't better
communicating what they have changed. :/

Will get included within the next upload.

-- 
Regards
Carsten Schoenert

Bug#894429:

[Aron Xu]

Would like to suggest that even the @tracker.d.o team address can
serve as a mini mailing list very well (except I don't see a list
archive service), and this is what Kylin Team has done so far -
team+kylin@tracker.d.o

Regards,
Aron

Bug#945104: ITP: surgescript -- scripting language for games

[Carlos Donizete Froes]

Package: wnpp
Severity: wishlist
Owner: Carlos Donizete Froes 

* Package name: surgescript
  Version : 0.5.4
  Upstream Author : Alexandre Martins 
* URL : https://docs.opensurge2d.org
* License : Apache-2.0
  Programming Lang: C
  Description : scripting language for games

 Unleash your creativity! With SurgeScript, you unleash your creativity
 and create your own amazing interactive content.
 .
 Unlike other programming languages, SurgeScript is designed with the specific
 needs of games in mind.
 .
 Easy for beginners, powerful for experts. Object-oriented, dynamically typed
 and based on state machines.
 .
 These features come from the experience of the developer dealing with
 game engines, applications related to computer graphics and so on.
 .
 Some of the best practices have been incorporated into the language itself,
 making things really easy for developers and modders.

Bug#945103: ITP: kt-update -- lightweight distribution management

[Jean-Jacques Brucker]

Package: wnpp
Severity: wishlist
Owner: Jean-Jacques Brucker 

* Package name: kt-update
  Version : 0.18.9
  Upstream Author : Jean-Jacques Brucker 
* URL : https://github.com/jbar/kt-update
* License : GPL-2
  Programming Lang: bash
  Description : lightweight distribution management

Manage an apt sources.list and permit to switch between different
distribution configurations. May also permit to switch beetween Debian
and a light Debian derivative.
.
Using filters, it may also replace cron-apt.
.
Relevant only if you trust distro conf availables in your kt server.
A kt server is trivial to deploy, cf. https://github.com/jbar/kt-update.

Bug#945102: thunderbird can not be upgraded because it breaks enigmail

[Michael Becker]

Package: thunderbird
Version: 1:60.9.0-1~deb10u1
Severity: serious
Tags: security
Justification: Policy 7.3

the upgrade to 68.2.2-1 includes security fixes but it can not be installed 
without deinstallation of enigmail
(The following packages have unmet dependencies: thunderbird : Breaks: enigmail 
(< 2:2.1.2~) but 2:2.0.12+ds1-1~deb10u1 is installed)

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

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

Versions of packages thunderbird depends on:
ii  debianutils   4.8.6.1
ii  fontconfig2.13.1-2
ii  libatk1.0-0   2.30.0-2
ii  libc6 2.28-10
ii  libcairo-gobject2 1.16.0-4
ii  libcairo2 1.16.0-4
ii  libdbus-1-3   1.12.16-1
ii  libdbus-glib-1-2  0.110-4
ii  libevent-2.1-62.1.8-stable-4
ii  libffi6   3.2.1-9
ii  libfontconfig12.13.1-2
ii  libfreetype6  2.9.1-3+deb10u1
ii  libgcc1   1:8.3.0-6
ii  libgdk-pixbuf2.0-02.38.1+dfsg-1
ii  libglib2.0-0  2.58.3-2+deb10u2
ii  libgtk-3-03.24.5-1
ii  libgtk2.0-0   2.24.32-3
ii  libhunspell-1.7-0 1.7.0-2
ii  libicu63  63.1-6
ii  libjsoncpp1   1.7.4-3
ii  libnspr4  2:4.20-1
ii  libnss3   2:3.42.1-1+deb10u1
ii  libpango-1.0-01.42.4-7~deb10u1
ii  libsqlite3-0  3.27.2-3
ii  libstartup-notification0  0.12-6
ii  libstdc++68.3.0-6
ii  libvpx5   1.7.0-3
ii  libx11-6  2:1.6.7-1
ii  libx11-xcb1   2:1.6.7-1
ii  libxcb-shm0   1.13.1-2
ii  libxcb1   1.13.1-2
ii  libxext6  2:1.3.3-1+b2
ii  libxrender1   1:0.9.10-1
ii  libxt61:1.1.5-1+b3
ii  psmisc23.2-1
ii  x11-utils 7.7+4
ii  zlib1g1:1.2.11.dfsg-1

Versions of packages thunderbird recommends:
ii  hunspell-de-at [hunspell-dictionary]  20161207-7
ii  hunspell-de-ch [hunspell-dictionary]  20161207-7
ii  hunspell-de-de [hunspell-dictionary]  20161207-7
ii  hunspell-en-us [hunspell-dictionary]  1:2018.04.16-1
ii  lightning 1:60.9.0-1~deb10u1

Versions of packages thunderbird suggests:
ii  apparmor  2.13.2-10
ii  fonts-lyx 2.3.2-1
ii  libgssapi-krb5-2  1.17-3

-- no debconf information

Bug#945101: nvidia-driver: NVIDIA driver fails to compile on bpo kernel 5.2

[Harm te Hennepe]

Package: nvidia-driver
Version: 418.74-1
Severity: normal
Tags: patch

Dear Maintainer,

Buster's nvidia kernel driver fails to install on bpo kernel 5.2, due to
put_user_pages already included in the kernel, see here:
https://garajau.com.br/2019/07/compiling-nvidia-418-on-kernel-52

This can fixed for all versions with the following patch:

*** source/nvidia-uvm/uvm8_tools.c  2019-11-19 17:11:49.478995704 +0100
--- source/nvidia-uvm/uvm8_tools.c  2019-11-19 17:04:05.458646201 +0100
***
*** 206,217 
--- 206,219 
  return event_tracker != NULL && !event_tracker->is_queue;
  }

+ #if LINUX_VERSION_CODE < KERNEL_VERSION(5, 2, 0)
  static void put_user_pages(struct page **pages, NvU64 page_count)
  {
  NvU64 i;
  for (i = 0; i < page_count; i++)
  put_page(pages[i]);
  }
+ #endif

  static void unmap_user_pages(struct page **pages, void *addr, NvU64 size)
  {

Kind regards,
Harm te Hennepe

-- Package-specific info:
uname -a:
Linux powerbox 5.2.0-0.bpo.3-amd64 #1 SMP Debian 5.2.17-1~bpo10+1 (2019-09-30) 
x86_64 GNU/Linux

/proc/version:
Linux version 5.2.0-0.bpo.3-amd64 (debian-ker...@lists.debian.org) (gcc version 
8.3.0 (Debian 8.3.0-6)) #1 SMP Debian 5.2.17-1~bpo10+1 (2019-09-30)

/proc/driver/nvidia/version:
NVRM version: NVIDIA UNIX x86_64 Kernel Module  418.74  Wed May  1 11:49:41 CDT 
2019
GCC version:  gcc version 8.3.0 (Debian 8.3.0-6) 

-- System Information:
Debian Release: 10.2
  APT prefers stable
  APT policy: (700, 'stable'), (500, 'stable-updates'), (50, 'testing'), (40, 
'unstable'), (30, 'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 5.2.0-0.bpo.3-amd64 (SMP w/12 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 nvidia-driver depends on:
ii  nvidia-alternative 418.74-1
ii  nvidia-driver-bin  418.74-1
ii  nvidia-driver-libs 418.74-1
ii  nvidia-installer-cleanup   20151021+9
ii  nvidia-kernel-dkms [nvidia-kernel-418.74]  418.74-1
ii  nvidia-legacy-check418.74-1
ii  nvidia-support 20151021+9
ii  nvidia-vdpau-driver418.74-1
ii  xserver-xorg-video-nvidia  418.74-1

Versions of packages nvidia-driver recommends:
ii  libnvidia-cfg1   418.74-1
pn  nvidia-persistenced  
ii  nvidia-settings  418.74-1

Versions of packages nvidia-driver suggests:
ii  nvidia-kernel-dkms  418.74-1

Versions of packages nvidia-driver-libs:amd64 depends on:
ii  libgl1-nvidia-glvnd-glx  418.74-1
ii  nvidia-egl-icd   418.74-1

Versions of packages nvidia-driver-libs:amd64 recommends:
ii  libgles-nvidia1  418.74-1
ii  libgles-nvidia2  418.74-1
ii  libglx-nvidia0   418.74-1
ii  libnvidia-cfg1   418.74-1
ii  libopengl0   1.1.0-1
pn  nvidia-driver-libs-i386  
ii  nvidia-vulkan-icd418.74-1

Versions of packages xserver-xorg-video-nvidia depends on:
ii  libc6  2.28-10
ii  libnvidia-glcore   418.74-1
ii  nvidia-alternative 418.74-1
ii  nvidia-installer-cleanup   20151021+9
ii  nvidia-legacy-check418.74-1
ii  nvidia-support 20151021+9
ii  xserver-xorg-core [xorg-video-abi-24]  2:1.20.4-1

Versions of packages xserver-xorg-video-nvidia recommends:
ii  nvidia-kernel-dkms [nvidia-kernel-418.74]  418.74-1
ii  nvidia-settings418.74-1
ii  nvidia-vdpau-driver418.74-1

Versions of packages xserver-xorg-video-nvidia suggests:
ii  nvidia-kernel-dkms  418.74-1

Versions of packages nvidia-alternative depends on:
ii  dpkg1.19.7
ii  glx-alternative-nvidia  1.0.0
ii  nvidia-legacy-check 418.74-1

Versions of packages nvidia-kernel-dkms depends on:
ii  dkms   2.6.1-4
ii  nvidia-installer-cleanup   20151021+9
ii  nvidia-kernel-support [nvidia-kernel-support--v1]  418.74-1

nvidia-kernel-dkms recommends no packages.

Versions of packages glx-alternative-nvidia depends on:
ii  dpkg  1.19.7
ii  glx-alternative-mesa  1.0.0
ii  glx-diversions1.0.0
ii  update-glx1.0.0

glx-alternative-nvidia suggests no packages.

Versions of packages xserver-xorg-video-intel depends on:
ii  libc6  2.28-10
ii  libdrm-intel1  2.4.97-1
ii  libdrm22.4.97-1
ii  libpciaccess0  0.14-1
ii  libpixman-1-0  0.36.0-1
ii  libudev1   241-7~deb10u2

Bug#945100: ITP: r-cran-tidygraph -- GNU R tidy API for graph manipulation

[Andreas Tille]

Package: wnpp
Severity: wishlist

Subject: ITP: r-cran-tidygraph -- GNU R tidy API for graph manipulation
Package: wnpp
Owner: Andreas Tille 
Severity: wishlist

* Package name: r-cran-tidygraph
  Version : 1.1.2
  Upstream Author : Thomas Lin Pedersen
* URL : https://cran.r-project.org/package=tidygraph
* License : MIT
  Programming Lang: GNU R
  Description : GNU R tidy API for graph manipulation
 A graph, while not "tidy" in itself, can be thought of as two tidy
 data frames describing node and edge data respectively. 'tidygraph'
 provides an approach to manipulate these two virtual data frames using the
 API defined in the 'dplyr' package, as well as provides tidy interfaces to
 a lot of common graph algorithms.

Remark: This package is maintained by Debian R Packages Maintainers at
   https://salsa.debian.org/r-pkg-team/r-cran-tidygraph

Bug#943992: transition: qscintilla2, soname 13 -> 15

[Graham Inggs]

Hi

On 2019/11/19 12:39, Dmitry Shachnev wrote:

qscintilla2 is now built and installed on all release architectures.


Thanks for the quick fix of the mips64el symbols!


You can schedule binNMUs.


Done a few hours ago.

Regards
Graham

Bug#944122: plantuml: New upstream version

[Tomas Janousek]

Hi Adrian (and Andrej),

On Mon, Nov 04, 2019 at 05:20:26PM +0100, Adrian Friedli wrote:
> Within the this year, plantuml got quite some improvements. The current
> release is 1.2019.12. Please consider upgrading the Debian package.

I needed this now so I tried to do the work. It's in my fork:
https://salsa.debian.org/liskin-guest/plantuml

I merged the upstream git history into the "upstream" branch because Andrej
merged a non-upstream patch into it and I needed git merge to do the right
thing (which it didn't, but at least the amount of manual work was minimized).

Feel free to use it.

-- 
Tomáš Janoušek, a.k.a. Pivník, a.k.a. Liskni_si, http://work.lisk.in/

Bug#832609: rpc-gssd.service: fails to start when keytab exists (ActiveDirectory member) but rpcsec_gss_krb5 module is not loaded

[Harald Dunkel]

I cannot confirm the fix. Even when rpcsec_gss_krb5 *is* loaded,
rpc-svcgssd.service still fails for Buster:

root@srvl064:/etc# systemctl daemon-reload
root@srvl064:/etc# systemctl restart rpc-svcgssd
Job for rpc-svcgssd.service failed because the control process exited with 
error code.
See "systemctl status rpc-svcgssd.service" and "journalctl -xe" for details.
root@srvl064:/etc# systemctl status rpc-svcgssd
* rpc-svcgssd.service - RPC security service for NFS server
   Loaded: loaded (/lib/systemd/system/rpc-svcgssd.service; static; vendor 
preset: enabled)
   Active: failed (Result: exit-code) since Tue 2019-11-19 16:45:35 CET; 5s ago
  Process: 1809 ExecStart=/usr/sbin/rpc.svcgssd $SVCGSSDARGS (code=exited, 
status=1/FAILURE)

Nov 19 16:45:35 srvl064.ac.aixigo.de systemd[1]: Starting RPC security service 
for NFS server...
Nov 19 16:45:35 srvl064.ac.aixigo.de rpc.svcgssd[1810]: ERROR: GSS-API: error 
in gss_acquire_cred(): GSS_S_FAILURE (Unspecified GSS failure.  Minor code may 
provide more information) - No key table entry found matching nfs/@
Nov 19 16:45:35 srvl064.ac.aixigo.de rpc.svcgssd[1810]: unable to obtain root 
(machine) credentials
Nov 19 16:45:35 srvl064.ac.aixigo.de systemd[1]: rpc-svcgssd.service: Control 
process exited, code=exited, status=1/FAILURE
Nov 19 16:45:35 srvl064.ac.aixigo.de rpc.svcgssd[1810]: do you have a keytab entry for 
nfs/@ in /etc/krb5.keytab?
Nov 19 16:45:35 srvl064.ac.aixigo.de systemd[1]: rpc-svcgssd.service: Failed 
with result 'exit-code'.
Nov 19 16:45:35 srvl064.ac.aixigo.de systemd[1]: Failed to start RPC security 
service for NFS server.
root@srvl064:/etc# lsmod | grep rpcsec_gss_krb5
rpcsec_gss_krb545056  1
auth_rpcgss73728  2 rpcsec_gss_krb5
sunrpc425984  13 nfsv4,auth_rpcgss,lockd,rpcsec_gss_krb5,nfs


journalctl -xe showed:

ERROR: GSS-API: error in gss_acquire_cred(): GSS_S_FAILURE (Unspecified GSS 
failure.  Minor code may provide more information) - No key table entry found 
matching nfs/@

Of course the nfs entry in the keytab has been omitted on purpose.


Regards
Harri

Bug#944934: cracklib2: diff for NMU version 2.9.6-3.1

[Boyuan Yang]

Control: tags 944934 + patch
Control: tags 944934 + pending

Dear maintainer,

I've prepared an NMU for cracklib2 (versioned as 2.9.6-3.1) and
uploaded it to DELAYED/3. Please feel free to tell me if I
should delay it longer.

Regards,
Boyuan Yang

diff -Nru cracklib2-2.9.6/debian/changelog cracklib2-2.9.6/debian/changelog
--- cracklib2-2.9.6/debian/changelog2019-10-23 07:02:23.0 -0400
+++ cracklib2-2.9.6/debian/changelog2019-11-19 10:14:51.0 -0500
@@ -1,3 +1,13 @@
+cracklib2 (2.9.6-3.1) unstable; urgency=high
+
+  * Non-maintainer upload.
+  * debian/control: Add Build-dependency on dh-python to fix
+FTBFS when building with python support. A 
+mark was also included.
+(Closes: #944934)
+
+ -- Boyuan Yang   Tue, 19 Nov 2019 10:14:51 -0500
+
 cracklib2 (2.9.6-3) unstable; urgency=medium
 
   * Fix "fails to build Python 3.8 extensions" by removing the
diff -Nru cracklib2-2.9.6/debian/control cracklib2-2.9.6/debian/control
--- cracklib2-2.9.6/debian/control  2019-10-23 07:02:23.0 -0400
+++ cracklib2-2.9.6/debian/control  2019-11-19 10:14:51.0 -0500
@@ -9,6 +9,7 @@
chrpath,
cracklib-runtime ,
debhelper (>= 10),
+   dh-python ,
docbook-utils,
docbook-xml,
dpkg-dev (>= 1.16.1~),

Bug#945099: lmms: Bump to version 1.2.1

[Dennis Braun]

Package: lmms
Version: 1.2.0 (in salsa)

please bump to version 1.2.1; because the build with my debian files
only work with 1.2.1 (as tested with pbuilder) and not with 1.2.0, so i
cannot send a merge request.

My debian files: https://salsa.debian.org/DNS-guest/lmms/tree/master/debian
My changes: https://salsa.debian.org/DNS-guest/lmms/commits/master/debian



signature.asc
Description: OpenPGP digital signature

Bug#944137: neomutt: Fail on launch with "munmap_chunk(): invalid pointer"

[Bernhard Übelacker]

Control: tags -1 + moreinfo


Hello Parleur,
is this still an problem with current version in unstable?

If yes, you could maybe supply some more informations.

One way would be to install the package systemd-coredump
and see if in 'journalctl --no-pager' appear some backtraces
of the issue, which could be forwarded to this bug.

Alternatively you might have a look in [1] to get
more information for the maintainer.

Kind regards,
Bernhard

[1] https://wiki.debian.org/HowToGetABacktrace

Bug#945098: kore: new upstream version 3.3.1 available (2019-06-03)

[Martin]

Source: kore
Version: 2.0.0-4
Severity: wishlist

Dear maintainer,

there were some releases since the last update of kore.

See e.g. https://blog.kore.io/posts/kore-3-released
and https://blog.kore.io/posts/the-next-kore-release-is-out
and https://github.com/jorisvink/kore/releases

Please consider packaging the latest release.

Thanks!

Bug#945097: please ignore /etc/logrotate.d/*.bak files by default

[Harald Dunkel]

Package: logrotate
Version: 3.14.0-4
Severity: wishlist

".bak" is the traditional extension for local backup files used by various
editors (e.g. mg). Do you think the *.bak files in /etc/logrotate.d could
be ignored by default, similar to *~ and others?

Of course I have found the tabooext option, but apparently it cannot be
set in /etc/logrotate.d/0.conf, and changing the default in logrotate.conf
is not an option, because /etc/logrotate.d was introduced to *avoid*
changing logrotate.conf.


Thanx in advance
Harri

Bug#903161: changing socket permissions seems to be the best solution for now

[Bjørn Mork]

I tried the different methods suggested in this bug report, but had
no success with any of them.

Using

  stats_writer_socket_path=

causes "doveadm index" to fail with

 bjorn@canardo:~$ doveadm index -q -u bjorn INBOX.Spam
 doveadm(bjorn): Error: net_connect_unix() failed: Connection refused

This can probably be worked around.  But I'd prefer too many hacks just
to make stuff work again...

For now I ended up using:

service stats {
  unix_listener stats-writer {
mode = 0666
  }
}


I don't want to add mail users to the dovecot group. It's unclear to me
what privileges this will result in now and in the future. And I don't
want to maintain yet another mail user group anyway.

This mess should really be sorted out.  Either there should be a way to
easily disable the stats service, or using it should be allowed for all
currently unprivileged operations.  By default.



Bjørn

Bug#945096: metview: FTBFS in sid

[Gianfranco Costamagna]

Source: metview
Version: 5.7.0-1
Severity: serious

Hello, looks like something added a libxxhash0 dependency on b-deps, and now it 
is FTBFS because of missing dev package

cd /<>/debian/build/metview/src/MacroEditor && /usr/bin/c++  
-DGRIB_HANDLING_PACKAGE=ecCodes -DH_INCLUDES_CC -DLITTLE_END -DMETVIEW 
-DMETVIEW_ODB -DMETVIEW_ODB_NEW -DMETVIEW_ODB_OLD -DMETVIEW_ODB_PLOT 
-DMETVIEW_QT5 -DODB_ECKIT -DQT_CORE_LIB -DQT_GUI_LIB -DQT_NETWORK_LIB 
-DQT_NO_DEBUG -DQT_NO_DEBUG_OUTPUT -DQT_PRINTSUPPORT_LIB -DQT_SVG_LIB 
-DQT_WIDGETS_LIB -DQT_XMLPATTERNS_LIB -DQT_XML_LIB -DR64 -DUSE_NEW_IO 
-I/<>/debian/build/metview/module 
-I/usr/include/x86_64-linux-gnu/qt5 
-I/usr/include/x86_64-linux-gnu/qt5/QtWidgets 
-I/usr/include/x86_64-linux-gnu/qt5/QtGui 
-I/usr/include/x86_64-linux-gnu/qt5/QtCore 
-I/usr/lib/x86_64-linux-gnu/qt5/mkspecs/linux-g++ 
-I/usr/include/x86_64-linux-gnu/qt5/QtXml 
-I/usr/include/x86_64-linux-gnu/qt5/QtXmlPatterns 
-I/usr/include/x86_64-linux-gnu/qt5/QtNetwork 
-I/usr/include/x86_64-linux-gnu/qt5/QtPrintSupport 
-I/usr/include/x86_64-linux-gnu/qt5/QtSvg 
-I/<>/debian/build/metview/src/MacroEditor 
-I/<>/metview/src/MacroEditor 
-I/<>/metview/src/libMetview 
-I/<>/metview/src/libMars 
-I/<>/debian/build/metview/src/libMars 
-I/<>/metview/src -I/<>/metview/src/libFTimeUtil 
-I/<>/metview/src/Odb -I/usr/lib/include 
-I/build/odb-api/metkit/src -I/build/odb-api/debian/build/python3.8/metkit/src 
-I/usr/include/python3.8/../eclib -I/usr/include/terralib/kernel 
-I/usr/include/hdf5/serial -I/<>/metview/src/libMvQtUtil 
-I/<>/metview/src/libMvQtGui 
-I/<>/debian/build/metview/src/libMvQtGui 
-I/<>/metview/src/libMvQtGui/../uPlot 
-I/<>/mars-client/src 
-I/<>/debian/build/mars-client/src -I/usr/include/python3.8 
-I/usr/include/python3.8/.. -I/usr/include/python3.8/../eclib/eclib 
-I/usr/include/python3.8/odblib  -g -O2 -fdebug-prefix-map=/<>=. 
-fstack-protector-strong -DACCEPT_USE_OF_DEPRECATED_PROJ_API_H -std=gnu++14 
-Wdate-time -D_FORTIFY_SOURCE=2 -pipe -fpermissive -Wno-write-strings 
-Wno-deprecated -Werror=return-type -O3 -DNDEBUG -fPIE   -fPIC -std=gnu++14 -o 
CMakeFiles/MacroEditor.dir/moc_mvplaintextedit.cpp.o -c 
/<>/debian/build/metview/src/MacroEditor/moc_mvplaintextedit.cpp
make[3]: *** No rule to make target '/usr/lib/x86_64-linux-gnu/libxxhash.so', 
needed by 'lib/libatlas_ecmwf.so.0.17'.  Stop.
make[3]: *** Waiting for unfinished jobs
[ 53%] Building CXX object 
atlas/src/atlas/CMakeFiles/atlas_ecmwf.dir/util/Allocate.cc.o
cd /<>/debian/build/atlas/src/atlas && /usr/bin/c++  
-Datlas_ecmwf_EXPORTS -I/<>/atlas/src/atlas 
-I/<>/atlas/src -I/<>/debian/build/atlas/src 
-I/usr/include/eigen3 -I/usr/include/x86_64-linux-gnu/eckit 
-I/usr/include/x86_64-linux-gnu/eckit/geometry 
-I/usr/include/x86_64-linux-gnu/eckit/linalg 
-I/usr/lib/x86_64-linux-gnu/openmpi/include/openmpi 
-I/usr/lib/x86_64-linux-gnu/openmpi/include 
-I/usr/include/x86_64-linux-gnu/eckit/mpi 
-I/usr/include/x86_64-linux-gnu/eckit/option  -g -O2 
-fdebug-prefix-map=/<>=. -fstack-protector-strong 
-DACCEPT_USE_OF_DEPRECATED_PROJ_API_H -std=gnu++14 -Wdate-time 
-D_FORTIFY_SOURCE=2 -pipe -O3 -DNDEBUG -fPIC   -fopenmp -std=gnu++14 -o 
CMakeFiles/atlas_ecmwf.dir/util/Allocate.cc.o -c 
/<>/atlas/src/atlas/util/Allocate.cc


http://debomatic-amd64.debian.net/distribution#unstable/metview/5.7.0-1/buildlog

probably adding libxxhash-dev to build-deps and runtime deps fixes the issue,

I'm uploading a test fix here
https://launchpad.net/ubuntu/+source/metview/5.7.0-1ubuntu1

G.

Bug#945095: /usr/lib/udev/rules.d/90-libgpod.rules:19 IMPORT key takes '==' or '!=' operator, assuming '==', but please fix it.

[Paul Menzel]

Package: libgpod-common
Version: 0.8.3-15
Severity: minor


Dear Debian folks,


The udev rules file needs an update to not be warned about. This is
systemd 243-7.

systemd-udevd[514]: /usr/lib/udev/rules.d/90-libgpod.rules:19 IMPORT key 
takes '==' or '!=' operator, assuming '==', but please fix it.
systemd-udevd[514]: /usr/lib/udev/rules.d/90-libgpod.rules:23 IMPORT key 
takes '==' or '!=' operator, assuming '==', but please fix it.


Kind regards,

Paul



smime.p7s
Description: S/MIME Cryptographic Signature

Bug#944295: thunderbird: Spellcheck fixed to "English (United States)"

[Raphaël Bleuse]

Hello Carsten,

On Fri, 8 Nov 2019 13:47:13 +0100 Carsten Schoenert 
 wrote:


I wasn't able to figure out how we can use the packaged dictionaries
with TB 68.x.


It seems one may configure the DICPATH environment variable to point to 
the location. This is documented in the following thread:

https://bugs.launchpad.net/ubuntu/+source/thunderbird/+bug/1847247

Hope this helps

Regards

--
Raphaël

Bug#944284: xchm crashes on search

[Bernhard Übelacker]

Control: tags -1 + moreinfo


Hello dinar,
I tried to reproduce the crash inside a minimal
i386 buster VM, but could not get xchm to crash
on my downloaded version of php_enhanced_en.chm [1].

Is this the file you are using, too?

Without further information the maintainer is maybe
not able to resolve this issue.

Maybe you could forward the last few lines of
'dmesg' output after the crash happened?

Or start xchm from a terminal and forward the output
of that?

Another way would be to install e.g. "systemd-coredump"
and forward the related lines "journalctl --no-pager",
after the crash happened.

Further information on providing more information could
be found in [1].

Kind regards,
Bernhard


[1] https://www.php.net/distributions/manual/php_enhanced_en.chm
[2] https://wiki.debian.org/HowToGetABacktrace

Bug#945094: fonts-open-sans: suggestions for the packaging

[Nicolas Boulenguez]

Package: fonts-open-sans
Severity: wishlist
Tags: patch

Hello.
The attached changes make update procedure a bit safer by preferring
HTTPS, refusing to extract directories, and showing any other
difference immediately.
They can probably be applied to similar packages.
diff --git a/debian/README.Source b/debian/README.Source
index 440f2c6..4df60a4 100644
--- a/debian/README.Source
+++ b/debian/README.Source
@@ -7,31 +7,17 @@ will ever be updated.
 
 The font is distributed in the form of a two zip files, open-sans.zip and
 open-sans-condensed.zip. These need to be repackaged to comply
-with debian source package standards.
+with Debian source package standards, which forbid this compressor.
 
 To find out if an update was released, you should download and
 unpack the fonts manually, then use otfdump to find out if they
 have a new version.
 
-
-Download the current font packages first:
-
-$ wget http://www.opensans.com/download/open-sans.zip http://www.opensans.com/download/open-sans-condensed.zip
-
-Unpack them into the source repository:
-
-$ unzip -o open-sans.zip
-$ unzip -o open-sans-condensed.zip
-
-
-Test if any of the files are tagged with a new version:
-
-$ for i in *.ttf; do echo $i; otfdump $i | grep '(nameID 5 "Version' ; done
+# debian/rules udate-upstream
 
 This should print something like:
 
-OpenSans-CondBold.ttf
-(nameID 5 "Version 1.11")
+OpenSans-Regular.ttf(nameID 5 "Version 1.10")
 
 for each of the fonts. Note that they may not all have the same version.
 
@@ -41,7 +27,6 @@ $ git status
 
 shows that a file has changed, it is recommended to prepare a new release.
 
-
 To accomplish this, debian/rules includes a script that does most of
 the work for you. Update the changelog first:
 
@@ -52,10 +37,10 @@ or increment  if only some fonts have changed and the highest
 font version is still the same.
 Add a suitable changelog line. For example: New upstream release
 
-Then save and run the tarball script (it uses wget and unzip):
-
-$ debian/rules get-orig-source
+# debian/rules repack-orig
 
 This should produce a new ../fonts-open-sans_.tar.xz file.
 
 Commit the updated TTFs and Debian changelog, then release the new package.
+
+ -- Nicolas Boulenguez , Tue, 19 Nov 2019 15:20:15 +0100
diff --git a/debian/changelog b/debian/changelog
index ecce744..23b7048 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,14 @@
+fonts-open-sans (1.11-2) unstable; urgency=medium
+
+  [ Nicolas Boulenguez  ]
+  * Improve script checking upstream versions.
+  * Update VCS-* fields to reference salsa.debian.org.
+  * Standards-Version: 4.4.1. Rules-Requires-Root: no.
+HTTPS URL for copyright format.
+  * Debhelper: 12.
+
+ -- Gregor Riepl   Tue, 19 Nov 2019 15:31:55 +0100
+
 fonts-open-sans (1.11-1) unstable; urgency=medium
 
   * Initial release. (Closes: #754785)
diff --git a/debian/compat b/debian/compat
deleted file mode 100644
index f599e28..000
--- a/debian/compat
+++ /dev/null
@@ -1 +0,0 @@
-10
diff --git a/debian/control b/debian/control
index b867e5e..209d9a0 100644
--- a/debian/control
+++ b/debian/control
@@ -2,14 +2,15 @@ Source: fonts-open-sans
 Section: fonts
 Priority: optional
 Build-Depends:
- debhelper (>= 10)
+ debhelper-compat (= 12)
 Maintainer: Debian Fonts Task Force 
 Uploaders:
  Gregor Riepl 
-Standards-Version: 3.9.8
+Standards-Version: 4.4.1
 Homepage: http://www.opensans.com/
-Vcs-Browser: https://anonscm.debian.org/cgit/pkg-fonts/fonts-open-sans.git/
-Vcs-Git: https://anonscm.debian.org/git/pkg-fonts/fonts-open-sans.git
+Rules-Requires-Root: no
+Vcs-Browser: https://salsa.debian.org/pkg-fonts/fonts-open-sans
+Vcs-Git: https://salsa.debian.org/pkg-fonts/fonts-open-sans.git
 
 Package: fonts-open-sans
 Architecture: all
diff --git a/debian/copyright b/debian/copyright
index 00a4d88..2d0ce8d 100644
--- a/debian/copyright
+++ b/debian/copyright
@@ -1,4 +1,4 @@
-Format: http://www.debian.org/doc/packaging-manuals/copyright-format/1.0/
+Format: https://www.debian.org/doc/packaging-manuals/copyright-format/1.0/
 Upstream-Name: Open Sans
 Source: http://www.opensans.com/
 
@@ -9,7 +9,8 @@ License: Apache-2.0
 
 Files: debian/*
 Copyright:
- Copyright (c) 2017, Gregor Riepl 
+ 2017-2019 Gregor Riepl 
+ 2019  Nicolas Boulenguez 
 License: Apache-2.0
 
 License: Apache-2.0
diff --git a/debian/rules b/debian/rules
index a20e681..441b1e1 100755
--- a/debian/rules
+++ b/debian/rules
@@ -4,11 +4,35 @@ include /usr/share/dpkg/pkg-info.mk
 %:
 	dh $@
 
-.PHONY: get-orig-source
-get-orig-source:
-	mkdir $(DEB_SOURCE)-$(DEB_VERSION_UPSTREAM)
-	wget http://www.opensans.com/download/open-sans.zip http://www.opensans.com/download/open-sans-condensed.zip
-	unzip -o open-sans.zip -d $(DEB_SOURCE)-$(DEB_VERSION_UPSTREAM)
-	unzip -o open-sans-condensed.zip -d $(DEB_SOURCE)-$(DEB_VERSION_UPSTREAM) -x "Apache License.txt"
-	tar -Jcf ../$(DEB_SOURCE)_$(DEB_VERSION_UPSTREAM).orig.tar.xz $(DEB_SOURCE)-$(DEB_VERSION_UPSTREAM)
-	rm -rf $(DEB_SOURCE)-$(DEB_VERSION_UPSTREAM) 

Bug#944914: [pkg-gnupg-maint] Bug#944914: libgpgme11: Buffer overflow while using claws-mail

[Werner Koch]

On Tue, 19 Nov 2019 14:50, Bernhard Übelacker said:

> Maybe it is of some help, following seem to be locations with the
> missing symbols:
> ...
> #8  0xb6441a7a in __fdelt_chk (d=194142480) at fdelt_chk.c:25
> #9 0xb27e5281 in () at libgpgme.so.11, in _gpgme_io_select at

This is the code at that place (at least in my master but we have not
chnaged it for quite some time)

  else if (fds[i].for_read)
{
> if (FD_ISSET (fds[i].fd, ))
{

Right, the tested FD might be out of range for FD_ISSET but we have an
earlier check for this:

  if (fds[i].for_read)
{
  if (fds[i].fd >= FD_SETSIZE)
{
  TRACE_END (dbg_help, " -BAD- ]");
  gpg_err_set_errno (EMFILE);
  return TRACE_SYSRES (-1);
}

So the code should not be the problem.  Hwoever if the fd table is
corrupt you might run into this but.  Nex step would be looking into
libc - I have no copy handy right now ...

> I found this upstream feature request, which could fit,
> but there is also a change mentioned that should avoid that crash,
> that is already included ...
> Are you maybe hitting this limit?

Nope, see the code above.


Shalom-Salam,

   Werner

-- 
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.


signature.asc
Description: PGP signature

Bug#945093: python3-scipy: SyntaxWarnings on upgrade

[Christian Göttsche]

Package: python3-scipy
Version: 1.2.2-8

During package upgrade some syntax warnings are printed:

Setting up python3-scipy (1.2.2-8) ...
/usr/lib/python3/dist-packages/scipy/io/netcdf.py:770: SyntaxWarning:
"is not" with a literal. Did you mean "!="?
  if typecode is not 'c':
/usr/lib/python3/dist-packages/scipy/optimize/_shgo.py:495:
SyntaxWarning: "is" with a literal. Did you mean "=="?
  if cons['type'] is 'ineq':
/usr/lib/python3/dist-packages/scipy/optimize/_shgo.py:743:
SyntaxWarning: "is not" with a literal. Did you mean "!="?
  if len(self.X_min) is not 0:


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

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

Versions of packages python3-scipy depends on:
ii  libblas3 [libblas.so.3] 3.8.0-8
ii  libc6   2.29-3
ii  libgcc1 1:9.2.1-19
ii  libgfortran59.2.1-19
ii  liblapack3 [liblapack.so.3] 3.8.0-8
ii  liblbfgsb0  3.0+dfsg.3-7
ii  libstdc++6  9.2.1-19
ii  python3 3.7.5-3
ii  python3-decorator   4.3.0-1.1
ii  python3-numpy [python3-numpy-abi9]  1:1.17.4-3

Versions of packages python3-scipy recommends:
ii  clang-9 [c++-compiler]  1:9.0.0-3+b1
ii  g++ [c++-compiler]  4:9.2.1-3.1
ii  g++-9 [c++-compiler]9.2.1-19
ii  python3-pil 6.2.1-2+b1

Versions of packages python3-scipy suggests:
pn  python-scipy-doc  

-- no debconf information

Bug#944341: libopencv-imgcodecs-dev depends on cruft package.

[Bas Couwenberg]

Source: opencv
Version: 4.1.2+dfsg-4+b1
Followup-For: Bug #944341
Control: tags -1 patch
Control: affects -1 src:otb

Dear Maintainer,

The attached patch fixes the issue.

Note that this issue also makes the otb build dependencies uninstallable.

Kind Regards,

Bas
>From ebfc61e5d3e658f472af0f10887ed2859e8cd1b2 Mon Sep 17 00:00:00 2001
From: Bas Couwenberg 
Date: Tue, 19 Nov 2019 12:30:42 +0100
Subject: Replace libgdbm2-dev with libgdbm-dev. (closes: #944341)


diff --git a/debian/changelog b/debian/changelog
index 61d213b81..5d33e82ef 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,12 @@
+opencv (4.1.2+dfsg-4.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Replace libgdbm2-dev with libgdbm-dev,
+and libvtkgdcm2-dev with libvtkgdcm-dev.
+(closes: #944341)
+
+ -- Bas Couwenberg   Tue, 19 Nov 2019 12:30:06 +0100
+
 opencv (4.1.2+dfsg-4) unstable; urgency=medium
 
   * Disable MSA (MIPS* arch) to avoid ISA violation. (Closes: #942561)
diff --git a/debian/control b/debian/control
index 83abbc308..02f3c1fd7 100644
--- a/debian/control
+++ b/debian/control
@@ -21,7 +21,7 @@ Build-Depends:
  libdc1394-22-dev [linux-any],
  libeigen3-dev,
  libgdal-dev,
- libgdcm2-dev [!hppa !m68k !powerpcspe !riscv64 !sh4 !sparc64 !x32],
+ libgdcm-dev [!hppa !m68k !powerpcspe !riscv64 !sh4 !sparc64 !x32],
  libgl1-mesa-dev,
  libglu1-mesa-dev,
  libgoogle-glog-dev,
@@ -40,7 +40,7 @@ Build-Depends:
  libtiff-dev,
  libv4l-dev [linux-any],
  libvtk6-dev,
- libvtkgdcm2-dev [!alpha !ppc64 !riscv64 !x32],
+ libvtkgdcm-dev [!alpha !ppc64 !riscv64 !x32],
  libgdcm-tools,
  maven-repo-helper,
  ocl-icd-opencl-dev,
@@ -297,7 +297,7 @@ Section: libdevel
 Architecture: any
 Multi-Arch: same
 Depends:
- libgdcm2-dev [!hppa !m68k !powerpcspe !riscv64 !sh4],
+ libgdcm-dev [!hppa !m68k !powerpcspe !riscv64 !sh4],
  libopencv-imgcodecs4.1 (= ${binary:Version}),
  libopencv-imgproc-dev (= ${binary:Version}),
  ${misc:Depends},
-- 
2.20.1

Bug#945092: Security: tcpxtract crash (heap-buffer-overflow) on Buster/Stretch/Jessie

[Antoine Cervoise]

Package: tcpxtract
Versions: 1.0.1-13

Dear Maintainer,

tcpxtract when analyzing the following file (crash.tcpdump). Crash exists on 
Debian Jessie, Stretch and Buster (Bullseye and Sid seems to use the same 
package as Buster).

Versions are 1.0.1-13 (buster), 1.0.1-11 (stretch), 1.0.1-8 (jessie)

Package info (jessie):
$ dpkg --list tcpxtract
Desired=Unknown/Install/Remove/Purge/Hold
| Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend
|/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad)
||/ Name   Version  Architecture Description
+++-==---=
ii  tcpxtract  1.0.1-8  amd64extracts files 
from network traffic based on file

Package info (stretch):
$ dpkg --list tcpxtract
Desired=Unknown/Install/Remove/Purge/Hold
| Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend
|/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad)
||/ Name   Version  Architecture Description
+++-==---=
ii  tcpxtract  1.0.1-11 amd64extract files from 
network traffic based on file

Package info (buster):
$ dpkg --list tcpxtract
Desired=Unknown/Install/Remove/Purge/Hold
| Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend
|/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad)
||/ Name   Version  Architecture Description
+++-==---===
ii  tcpxtract  1.0.1-13 amd64extract files from network traffic 
based on file signatures

File info:
$ md5sum crash.tcpdump
26514548ac04f47ec610e255d15d5e2f  crash.tcpdump
$ sha1sum crash.tcpdump
c5a0377d1c4f9f5f6d9c60839ed1b44388b90525  crash.tcpdump
$ sha256sum crash.tcpdump
eca339965dc64154029c7b8f3dd64e7710d04cde3850666df0b025a07c3fbad3  crash.tcpdump
$ file crash.tcpdump
crash.tcpdump: tcpdump capture file (little-endian) - version 2.4 (Ethernet, 
capture length 262144)


Crash (same result on Buster, Stretch and Jessie):
$ tcpxtract -f crash.tcpdump
Segmentation fault

Trace from crash (gdb with peda plugin) - Buster:
Program received signal SIGSEGV, Segmentation fault.

[--registers---]
RAX: 0x779e903a --> 0x1013f2f
RBX: 0x37bfc6
RCX: 0x0
RDX: 0x0
RSI: 0x0
RDI: 0x77d6ac40 --> 0x0
RBP: 0x555a3b40 --> 0x555a41a0 --> 0x555a3c20 --> 0x0
RSP: 0x7fffdf20 --> 0x7fffdf40 --> 0x555a3c60 --> 0x555a3c90 
--> 0x555a3cc0 --> 0x555a3cf0 (--> ...)
RIP: 0x8b9c (movzx  r12d,BYTE PTR [rax+rbx*1])
R8 : 0x555a41a0 --> 0x555a3c20 --> 0x0
R9 : 0x0
R10: 0x0
R11: 0x30 ('0')
R12: 0x55567ee0 --> 0x0
R13: 0x37bfc6
R14: 0x0
R15: 0x555a41a0 --> 0x555a3c20 --> 0x0
EFLAGS: 0x10282 (carry parity adjust zero SIGN trap INTERRUPT direction 
overflow)
[-code-]
   0x8b90:movrax,QWORD PTR [rsp+0x8]
   0x8b95:movr15,QWORD PTR [rbp+0x0]
   0x8b99:movr13d,ebx
=> 0x8b9c:movzx  r12d,BYTE PTR [rax+rbx*1]
   0x8ba1:test   r15,r15
   0x8ba4:jne0x8bc4
   0x8ba6:jmp0x8c10
   0x8ba8:nopDWORD PTR [rax+rax*1+0x0]
[stack-]
| 0x7fffdf20 --> 0x7fffdf40 --> 0x555a3c60 --> 0x555a3c90 
--> 0x555a3cc0 --> 0x555a3cf0 (--> ...)
0008| 0x7fffdf28 --> 0x779e903a --> 0x1013f2f
0016| 0x7fffdf30 --> 0xffdc
0024| 0x7fffdf38 --> 0x555635b0 --> 0x0
0032| 0x7fffdf40 --> 0x555a3c60 --> 0x555a3c90 --> 0x555a3cc0 
--> 0x555a3cf0 --> 0x555a3d20 (--> ...)
0040| 0x7fffdf48 --> 0x8292a0abdb3fa400
0048| 0x7fffdf50 --> 0xffdc
0056| 0x7fffdf58 --> 0x779e903a --> 0x1013f2f
[--]
Legend: code, data, rodata, value
Stopped reason: SIGSEGV
0x8b9c in ?? ()

Trace from crash (gdb with peda plugin) - Stretch:
[--registers---]
RAX: 0x77f9a03a --> 0x1013f2f
RBX: 0x55765c90 --> 0x0
RCX: 0x77b91b08 --> 0x0
RDX: 0x0
RSI: 0x0
RDI: 0x0
RBP: 0x44fc6
RSP: 0x7fffdef0 --> 0x7fffdf10 --> 0x0
RIP: 0x7c2f (movzx  ebx,BYTE PTR [rax+rbp*1])
R8 : 0x557a17e0 --> 0x557a1820 --> 0x0
R9 : 0x20 (' ')
R10: 0x557a1890 --> 0x40006
R11: 0x4
R12: 0x557a17c0 --> 0x557a17e0 --> 0x557a1820 --> 0x0
R13: 0x44fc6
R14: 0x0
R15: 0x557a17e0 --> 

Bug#944914: libgpgme11: Buffer overflow while using claws-mail

[Bernhard Übelacker]

Hello Lars,

> in fact they all happen with the same program (claws-mail).

> Besides the claws-mail crashes I did not notice any other unexpected behavior.

Yes, if crashes are just in one application then it seems less
likely to be an hardware issue.


Maybe it is of some help, following seem to be locations with the
missing symbols:
...
#8  0xb6441a7a in __fdelt_chk (d=194142480) at fdelt_chk.c:25
#9  0xb27e5281 in  () at libgpgme.so.11, in _gpgme_io_select at 
../../src/posix-io.c:788
#10 0xb27bf7fc in  () at libgpgme.so.11, in _gpgme_wait_on_condition at 
../../src/wait-private.c:87
#11 0xb27bf9ec in  () at libgpgme.so.11, in _gpgme_wait_one at 
../../src/wait-private.c:170
#12 0xb27c5201 in gpgme_op_verify () at libgpgme.so.11, ../../src/verify.c, 
line 1197.
...


Another question, which version of claws-mail and plugins are you running?
(And are they the binaries from debian or self-built?)


Maybe a run with valgrind could shed some light on some wrong memory accesses.
(But may also write many unrelated accesses,
and slow the application down to an unusable speed.)

I found this upstream feature request, which could fit,
but there is also a change mentioned that should avoid that crash,
that is already included ...
Are you maybe hitting this limit?

https://dev.gnupg.org/T2385

Kind regards,
Bernhard

Bug#936604: FYI: Python 3 migration of distributuion

[Osamu Aoki]

On Sun, Nov 17, 2019 at 02:28:44PM +0900, Osamu Aoki wrote:
> Hi,
>
> On Wed, Nov 13, 2019 at 11:11:43AM -0600, Charles Cazabon wrote:
> > Osamu Aoki  wrote:
> > >
> > > Currently, getmail is a candidate for removal from the upcoming Debian
> > > release if it is not updated to support python 3 by someone (not
> > > necessary by upstream).
> >
> > Thanks for the update, Osamu.  I have actually been playing with a prototype
> > refactoring of getmail to not just support but require a recent Python 3.x
> > version.  Such a project would give me the opportunity to remove a lot of
> > historical cruft and backwards-compatibility code that getmail has 
> > accumulated
> > over 20+ years.
>
> That's great.  (I thought you rejected idea to move to 3.0.)
>
> I tried to do it around getmail 5.5 days.  (I didn't finish it)


FYI: I found this repo
https://gitlab.com/dkg/getmail/commits/python3
I think this is better work than my local work.

Osamu

Bug#945090: Intel microcode problem

[Chris Lapera]

Package: intel-microcodeVersion: 3.20191112.1~deb10u1

When I installed this version I lost my WiFi and Bluetooth on my Dell XPS 9380 
Laptop. Once I apt removed the update and reverted back to the previous version 
I was fine. I'm running the latest version of debian 10.2. Kernel 
4.19.0-6-amd64. The previous microcode is 3.20190618.1(works).



Regards,
Chris laperac.lap...@verizon.net

Bug#932960: python-django doesn't fix a CVE and drops Python 2 support at the same time

[Antonio Terceiro]

Control: affects -1 - src:python-django-bootstrap-form
Control: affects -1 - src:python-semantic-version
Control: affects -1 - src:django-modeltranslation
Control: affects -1 - src:django-reversion
Control: affects -1 - src:python-aws-xray-sdk
Control: affects -1 - bcfg2-web

On Mon, 16 Sep 2019 22:18:36 +0200 Paul Gevers  wrote:
> Control: affects -1 src:python-django-bootstrap-form
> Control: affects -1 src:python-semantic-version
> Control: affects -1 src:django-modeltranslation
> Control: affects -1 src:django-reversion
> Control: affects -1 src:python-aws-xray-sdk
> Control: affects -1 bcfg2-web
> 
> Hi,
> 
> How is progress here? I failed to spot recent activity, but I may have
> missed it.
> 
> Paul
> 
> paul@testavoira ~ $ reverse-depends python-django -r testing -b
> Reverse-Build-Depends-Indep
> ===
> * python-django-bootstrap-form
> * python-semantic-version
> 
> Reverse-Build-Depends
> =
> * django-modeltranslation
> * django-picklefield
> * django-reversion
> * python-aws-xray-sdk
> 
> paul@testavoira ~ $ reverse-depends python-django -r testing
> Reverse-Depends
> ===
> * bcfg2-web
> * python-bootstrapform
> * python-django-modeltranslation
> * python-django-pagination
> * python-django-picklefield
> * python-django-reversion

I just double checked and all of the above (with the exception of
bcfg2-web which has been removed) now build fine in unstable. And:

~$ reverse-depends python-django -r testing
~$ reverse-depends python-django -r testing -b
No reverse dependencies found

I think we could let python-django migrate at this point.


signature.asc
Description: PGP signature

Bug#945091: Wrong homepage?

[Stephan Seitz]

Source: pgmodeler
Version: 0.9.1-2
Severity: minor

Dear Maintainer,

I’v noticed that the package pgmodeler has the homepage field set to 
https://www.pgmodeler.com.br/.


But this URL shows first a certificate error and then no content.
If you use http://www.pgmodeler.com.br/, it is working and you get 
redirected to https://pgmodeler.io/.


Maybe you should update the homepage field.

Shade and sweet water!

Stephan

--
|If your life was a horse, you'd have to shoot it.|