Bug#963678: hedgewars: FTBFS with ghc 8.8

2020-06-29 Thread Shengjing Zhu
On Thu, 25 Jun 2020 09:36:25 +0200 Sebastian Ramacher
 wrote:
> Source: hedgewars
> Version: 1.0.0-5
> Severity: serious
> Tags: ftbfs sid bullseye
> Justification: fails to build from source (but built successfully in the past)
>
> hedgewars fails to build with ghc 8.8:
> | [ 6 of 26] Compiling CoreTypes( 
> /<>/gameServer/CoreTypes.hs, 
> /<>/obj-x86_64-linux-gnu/gameServer/CoreTypes.o )
> | make[3]: Leaving directory '/<>/obj-x86_64-linux-gnu'
> | make -f QTfrontend/CMakeFiles/hedgewars.dir/build.make 
> QTfrontend/CMakeFiles/hedgewars.dir/build
>
> | /<>/gameServer/CoreTypes.hs:26:1: error:
> | Could not find module ‘Network’
> | Use -v (or `:set -v` in ghci) to see a list of the files searched for.
> ||
> | 26 | import Network
> || ^^
> | make[3]: *** [gameServer/CMakeFiles/hedgewars-server.dir/build.make:87: 
> bin/hedgewars-server] Error 1
>

Maybe try the patch from archlinux?
https://git.archlinux.org/svntogit/community.git/tree/trunk/PKGBUILD?h=packages/hedgewars#n22



Bug#963999: gcc-python-plugin: FTBFS: invalid literal for int() with base 10

2020-06-29 Thread Niko Tyni
Source: gcc-python-plugin
Version: 0.17-6
Severity: serious
Tags: ftbfs

This package fails to build from source on current sid.

  Exception occurred:
File "/usr/lib/python3/dist-packages/sphinx/writers/html5.py", line 548, in 
visit_image
  atts['width'] = int(atts['width']) * scale
  ValueError: invalid literal for int() with base 10: '550px'
  The full traceback has been saved in /tmp/sphinx-err-b_30quqh.log, if you 
want to report the issue to the developers.
  Please also report this if it was a user error, so that a better error 
message can be provided next time.
  A bug report can be filed in the tracker at 
. Thanks!
  make[1]: *** [Makefile:42: html] Error 2
  make[1]: Leaving directory '/<>/docs'
  make: *** [debian/rules:70: doc-stamp] Error 2
 
-- 
Niko Tyni   nt...@debian.org



Bug#963998: gcc-9-cross-mipsen: FTBFS: empty variable name

2020-06-29 Thread Niko Tyni
Source: gcc-9-cross-mipsen
Version: 4+c2
Severity: serious
Tags: ftbfs

This package fails to build on current sid.

dpkg-buildpackage: info: source package gcc-9-cross-mipsen
dpkg-buildpackage: info: source version 4+c2
dpkg-buildpackage: info: source distribution unstable
dpkg-buildpackage: info: source changed by YunQiang Su 
 dpkg-source --before-build .
dpkg-buildpackage: info: host architecture amd64
 fakeroot debian/rules clean
debian/rules:6: *** empty variable name.  Stop.
dpkg-buildpackage: error: fakeroot debian/rules clean subprocess returned exit 
status 2
 

This was presumably broken by the backward incompatible changes in
make_4.3-1.
-- 
Niko Tyni   nt...@debian.org



Bug#963997: terminology: Characters not displayed

2020-06-29 Thread Pierre Couderc
Package: terminology
Version: 1.7.0-1
Severity: important

Dear Maintainer,

In the last line of the window, the character '_' is not displayed.

I suppose (but I am not sure) that the last line of pixels is not
displayed.

To reproduce :
a- install a fresh bullseye debian system (maybe on a 1920x1080 display)
b- install enlightenment and terminolgy
c- execute terminology and fill the screen up to last line
d- on last line type  
_ is not displayed.

This problem exist since years on terminology, but the news is that it is easy 
to
reproduce on a debian system, as I suppose that the initialisation is
important (such as the font used : here no question : the problem
exist with default font).

Thnaks for terminology on debian !

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

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

Versions of packages terminology depends on:
ii  libc6 2.30-8
ii  libecore-con1 1.23.3-8
ii  libecore-evas11.23.3-8
ii  libecore-file11.23.3-8
ii  libecore-imf1 1.23.3-8
ii  libecore-input1   1.23.3-8
ii  libecore-ipc1 1.23.3-8
ii  libecore1 1.23.3-8
ii  libedje1  1.23.3-8
ii  libeet1   1.23.3-8
ii  libefreet-bin 1.23.3-8
ii  libefreet1a   1.23.3-8
ii  libeina1a 1.23.3-8
ii  libelementary11.23.3-8
ii  libemotion1   1.23.3-8
ii  libethumb-client-bin  1.23.3-8
ii  libethumb-client1 1.23.3-8
ii  libevas1  1.23.3-8
ii  libevas1-engines-x1.23.3-8
ii  terminology-data  1.7.0-1

terminology recommends no packages.

Versions of packages terminology suggests:
pn  libelementary-bin   
pn  libemotion-players  

-- no debconf information



Bug#963996: /usr/bin/unzip: Bomb detection fails with out of memory error when extracting bzip2-compressed files

2020-06-29 Thread Spencer Harris
Package: unzip
Version: 6.0-25
Severity: normal
File: /usr/bin/unzip

Dear Maintainer,

When using unzip to attempt to extract a zip file containing certain
bzip2-compressed files, unzip fails after extracting the first file with the
error, "not enough memory for bomb detection". Versions without the bomb
detection patches seem to have no problems handling bzip2 decompression. Not
all bzip2-compressed files produce this error.

To test this, I compressed the files "zip.h" and "zipinfo.c" from the
unpatched unzip sources with the command
"zip -Z bzip2 test.zip zip.h zipinfo.c", moved test.zip, and attempted to
extract with "unzip test.zip". This resulted in zip.h getting extracted,
followed by the aforementioned error message. zipinfo.c was not extracted.
Changing the order of the files to "zip -Z bzip2 test.zip zipinfo.c zip.h"
resulted in both files being extracted, with the error once again after zip.h.
Compressing each file by itself also resulted in an error when extracting
zip.h, albeit with the file being produced successfully, and no problems with
zipinfo.c.


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

Kernel: Linux 5.6.0-2-amd64 (SMP w/2 CPU cores)
Kernel taint flags: 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 unzip depends on:
ii  libbz2-1.0  1.0.8-3
ii  libc6   2.30-8

unzip recommends no packages.

Versions of packages unzip suggests:
ii  zip  3.0-11+b1

-- no debconf information



Bug#961839: closure-compiler: FTBFS: is not abstract and does not override abstract method test(Object) in Predicate

2020-06-29 Thread Sandro Tosi
Any update here? it's been a month now -- thanks!

On Sun, May 31, 2020 at 9:03 PM Sandro Tosi  wrote:
>
> > If that helps, building closure-compiler with source/target=8 should fix
> > this issue. I did that for Gradle this week to fix the same issue.
>
> if you guys fix this bug, can you also take care of #942965 at the
> same time? it should be just a matter of
> s/python-docutils/python3-docutils/
>
> thanks!
>
> --
> Sandro "morph" Tosi
> My website: http://sandrotosi.me/
> Me at Debian: http://wiki.debian.org/SandroTosi
> Twitter: https://twitter.com/sandrotosi
>
> --
> Sandro "morph" Tosi
> My website: http://sandrotosi.me/
> Me at Debian: http://wiki.debian.org/SandroTosi
> Twitter: https://twitter.com/sandrotosi



-- 
Sandro "morph" Tosi
My website: http://sandrotosi.me/
Me at Debian: http://wiki.debian.org/SandroTosi
Twitter: https://twitter.com/sandrotosi



Bug#943132: intel-gpu-tools: diff for NMU version 1.25-2.1

2020-06-29 Thread Sandro Tosi
Control: tags 943132 + pending


Dear maintainer,

I've prepared an NMU for intel-gpu-tools (versioned as 1.25-2.1) and
uploaded it to DELAYED/7. Please feel free to tell me if I
should delay it longer.

Regards.

diff -Nru intel-gpu-tools-1.25/debian/changelog intel-gpu-tools-1.25/debian/changelog
--- intel-gpu-tools-1.25/debian/changelog	2020-04-02 04:53:05.0 -0400
+++ intel-gpu-tools-1.25/debian/changelog	2020-06-29 23:37:21.0 -0400
@@ -1,3 +1,10 @@
+intel-gpu-tools (1.25-2.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Switch b-d from python-docutils to python3-docutils; Closes: #943132
+
+ -- Sandro Tosi   Mon, 29 Jun 2020 23:37:21 -0400
+
 intel-gpu-tools (1.25-2) unstable; urgency=medium
 
   [ Jordan Justen ]
diff -Nru intel-gpu-tools-1.25/debian/control intel-gpu-tools-1.25/debian/control
--- intel-gpu-tools-1.25/debian/control	2020-04-02 04:49:58.0 -0400
+++ intel-gpu-tools-1.25/debian/control	2020-06-29 23:37:18.0 -0400
@@ -24,7 +24,7 @@
meson (>= 0.47),
peg,
pkg-config,
-   python-docutils,
+   python3-docutils,
quilt,
x11proto-dri2-dev,
xutils-dev (>= 1:7.6+6)


Bug#916333: ITP: dav1d -- fast and small AV1 video stream decoder

2020-06-29 Thread Vasyl Gello
Hi Dylan!

There is a new upstream release 0.7.1 for a week or so.
Can you please package it?
-- 
Vasyl Gello
==
Certified SolidWorks Expert

Mob.:+380 (98) 465 66 77

E-Mail: vasek.ge...@gmail.com

Skype: vasek.gello
==
호랑이는 죽어서 가죽을 남기고 사람은 죽어서 이름을 남긴다

signature.asc
Description: PGP signature


Bug#963994: RFS: pygresql/1:5.2-1 [QA] -- PostgreSQL module for Python3

2020-06-29 Thread Håvard Flaget Aasen
Package: sponsorship-requests
Severity: normal

Dear mentors,

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

 * Package name: pygresql
   Version : 1:5.2-1
   Upstream Author : PyGreSQL team  
 * URL : https://www.pygresql.org/index.html
 * License : PostgreSQL
 * Vcs : https://salsa.debian.org/debian/pygresql
   Section : python

It builds those binary packages:

  python3-pygresql - PostgreSQL module for Python3
  python-pygresql-doc - Python Pygresql (common documentation)

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

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

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

  dget -x
https://mentors.debian.net/debian/pool/main/p/pygresql/pygresql_5.2-1.dsc

Changes since the last upload:

   * QA upload.
   * New upstream version 5.2
   * Add another superficial autopkgtest

Regards,
Håvard



Bug#963647: elpy: FTBFS with Sphinx 3.1: Could not import extension elispdomain (exception: cannot import name 'l_' from 'sphinx.locale' (/usr/lib/python3/dist-packages/sphinx/locale/__init__.py))

2020-06-29 Thread Nicholas D Steeves
Hi Dmitry!

Dmitry Shachnev  writes:

> So the correct link would be this one:
>
> https://www.sphinx-doc.org/en/2.0/extdev/deprecated.html
>
> which says that sphinx.locale.l_() was deprecated in 1.8, and the
> alternative is sphinx.locale._():
>
> https://www.sphinx-doc.org/en/3.x/extdev/i18n.html#sphinx.locale._
>
> Apart from the table of deprecated interfaces, there are no other migration
> docs.
>

Is it really as obvious as it seems?  I feel very naive trusting the
following without having confirmed it's correct via migrations docs.  It
appears to produce identical output to the version of Sphinx in sid
without the patch.  Does this look correct to you?  (I'm ready to
upload)

--- a/docs/elispdomain.py  
+++ b/docs/elispdomain.py  
@@ -8,7 +8,7 @@ Copyright 2014-2019 by Jorgen Schäfer
   
 from sphinx import addnodes   
 from sphinx.domains import Domain, ObjType
-from sphinx.locale import l_  
+from sphinx.locale import _   
 from sphinx.directives import ObjectDescription   
 from sphinx.roles import XRefRole 
 from sphinx.util.nodes import make_refnode
@@ -106,10 +106,10 @@ class ELispDomain(Domain):
 label = 'ELisp'   
   
 object_types = {  
-'function': ObjType(l_('function'), 'function'),  
-'variable': ObjType(l_('variable'), 'variable'),  
-'command': ObjType(l_('function'), 'command'),
-'option': ObjType(l_('variable'), 'option'),  
+'function': ObjType(_('function'), 'function'),   
+'variable': ObjType(_('variable'), 'variable'),   
+'command': ObjType(_('function'), 'command'), 
+'option': ObjType(_('variable'), 'option'),   
 } 
 directives = {
 'function': ELispFunction,


Thanks,
Nicholas


signature.asc
Description: PGP signature


Bug#960974: buster-pu: package postfix/3.4.14-0+deb10u1

2020-06-29 Thread Scott Kitterman
In the 6 weeks since this request was originally filed, there have been two 
more postfix bugfix releases.  I'd like to upload 3.4.14 instead.  I'm 
attaching 
two debdiffs:

stable.debdiff is the diff from what's currently in stable.
update.debdiff is the change from the original request in May.

Given the upcoming point release, I really would like to get this in now.

Scott Kdiff -Nru postfix-3.4.12/conf/postfix-tls-script postfix-3.4.14/conf/postfix-tls-script
--- postfix-3.4.12/conf/postfix-tls-script	2017-02-18 20:58:20.0 -0500
+++ postfix-3.4.14/conf/postfix-tls-script	2020-05-30 10:37:04.0 -0400
@@ -777,7 +777,7 @@
 deploy_server_cert() {
 certfile=$1; shift
 keyfile=$1; shift
-deploy=$1; shift
+case $# in 0) deploy=;; *) deploy=$1; shift;; esac
 
 # Sets key_algo, key_param and cert_param
 check_key "$keyfile" || return 1
diff -Nru postfix-3.4.12/debian/changelog postfix-3.4.14/debian/changelog
--- postfix-3.4.12/debian/changelog	2020-05-18 17:45:37.0 -0400
+++ postfix-3.4.14/debian/changelog	2020-06-29 21:33:31.0 -0400
@@ -1,8 +1,15 @@
-postfix (3.4.12-0+deb10u1) buster; urgency=medium
+postfix (3.4.14-0+deb10u1) buster; urgency=medium
+
+  [Cody Brownstein]
+
+  * README.Debian corrections:
+- Fix instructions wrt SMTP generic mapping
+- Fix authentication configuration example
 
   [Scott Kitterman]
 
   * Updated debian/watch to track postfix 3.4 series for stable updates
+  * Check GPG signature when downloading new versions via uscan
 
   [Wietse Venema]
 
@@ -40,7 +47,51 @@
   concurrent TLS session in the same tlsproxy process. File:
   tlsproxy/tlsproxy.c.
 
- -- Scott Kitterman   Mon, 18 May 2020 17:45:37 -0400
+  * 3.4.13
+- Bugfix (introduced: Postfix 3.1): "postfix tls deploy-server-cert"
+  did not handle a missing optional argument. File:
+  conf/postfix-tls-script.
+
+- Bugfix (introduced: Postfix 3.4): in the Postfix SMTP server,
+  the SNI callback reported an error when it was called a
+  second time. This happened after the server-side TLS engine
+  sent a TLSv1.3 HelloRetryRequest (HRR) to a remote SMTP
+  client. Reported by Ján Máté, fixed by Viktor Dukhovni.
+  File: tls/tls_misc.c.
+
+  * 3.4.14
+- Bugfix (introduced: Postfix 3.4): the connection_reuse
+  attribute in smtp_tls_policy_maps resulted in an "invalid
+  attribute name" error. Fix by Thorsten Habich. File:
+  smtp/smtp_tls_policy.c.
+
+- Bugfix (introduced: Postfix 3.4): SMTP over TLS connection
+  reuse was broken for configurations that use explicit trust
+  anchors. Reported by Thorsten Habich. Cause: the tlsproxy
+  client was sending a zero certificate length. File:
+  tls/tls_proxy_client_print.c.
+
+- Bugfix (introduced: Postfix 3.4): SMTP over TLS connection
+  reuse was broken for configurations that use explicit trust
+  anchors. Reported by Thorsten Habich. Fixed by calling DANE
+  initialization unconditionally (WTF). File: tlsproxy/tlsproxy.c.
+
+- Bugfix (introduced: Postfix 2.11): The Postfix smtp(8)
+  client did not send the right SNI name when the TLSA base
+  domain was a secure CNAME expansion of the MX hostname (or
+  non-MX nexthop domain). Domains with CNAME expanded MX hosts
+  are not conformant with RFC5321, and so are rare. Even more
+  rare are MX hosts with TLSA records for their CNAME expansion.
+  For this to matter, the remote SMTP server would also have
+  to select its certificate based on the SNI name in such a
+  way that the original MX host would yield a different
+  certificate. Among the ~2 million hosts in the DANE survey,
+  none meet the conditions for returning a different certificate
+  for the expanded CNAME. Therefore, sending the correct SNI
+  name should not break existing mail flows. Fixed by Viktor
+  Dukhovni. File: src/tls/tls_client.c.
+
+ -- Scott Kitterman   Mon, 29 Jun 2020 21:33:31 -0400
 
 postfix (3.4.10-0+deb10u1) buster; urgency=medium
 
diff -Nru postfix-3.4.12/debian/README.Debian postfix-3.4.14/debian/README.Debian
--- postfix-3.4.12/debian/README.Debian	2020-05-18 16:55:04.0 -0400
+++ postfix-3.4.14/debian/README.Debian	2020-06-29 21:33:10.0 -0400
@@ -156,7 +156,7 @@
 
 After creating the file, run the command:
 
-postmap /etc/postfix/example.com-passwd
+postmap /etc/postfix/example-passwd
 
 and add the following line to main.cf:
 
@@ -204,6 +204,14 @@
 
 with 'host.domain' taken from '/etc/mailname'.
 
+After creating the file, run the command:
+
+postmap /etc/postfix/generic_mapping
+
+and add the following line to main.cf:
+
+sender_generic_maps = hash:/etc/postfix/generic_mapping
+
 One advantage to using generic over canonical mapping is that the latter will
 be applied to local mail as well. If the system will be configured to send all
 mail, even mail addressed to local users, via the smarthost (e.g., via
diff 

Bug#963817: Breaks?

2020-06-29 Thread Rebecca N. Palmer

On 29/06/2020 20:59, Paul Gevers wrote:

Does this mean that numpy should add a Breaks relation on the old pandas
version to avoid upgrading numpy but not pandas on user systems?


Not really - the constant was replaced by its value, so the only 
1.19-related change outside of tests is the reworded error message


-raise ValueError("Must pass 2-d input")
+raise ValueError("Plain DataFrames must be 2-d - for higher 
dimensions use MultiIndex or the python3-xarray package.  If you are 
trying to create a nested DataFrame (which is not recommended) see 
https://github.com/pandas-dev/pandas/issues/32289;)


and upstream aren't planning that much of a notice:
https://github.com/pandas-dev/pandas/pull/34991/files



Bug#962474: CMAKE_SKIP_RPATH=ON improves reproducibility of CMake builds

2020-06-29 Thread Timo Röhling
On 30.06.2020 00:55, Chris Lamb wrote:
> In other words, unless you have no reason to suspect that lots and
> lots of things will break, I would highly and strongly recommend that
> you simply make the changes in CMake/debhelper and upload. :) 
I'd say the biggest risk lies in breaking test suites for shared
libraries, because they tend to be run from the build tree, which is why
CMake adds RPATHs to targets in the first place.

As precedent, I thought the way Debhelper introduced
-DCMAKE_SKIP_INSTALL_ALL_DEPENDENCY=ON in v13 was quite nice, and I
wouldn't mind if I had to opt-in for CMAKE_SKIP_RPATH by bumping my
compat level to (say) 14.

Cheers
Timo



Bug#954554: python-asynctest: FTBFS, maybe-RM

2020-06-29 Thread Rebecca N. Palmer

Is the above intended as a proposal to remove asynctest?

The rdeps in Debian are hypercorn, python-aioresponses, and (for 
autopkgtest only) python-fakeredis.


hypercorn upstream have stopped using it:
https://gitlab.com/pgjones/hypercorn/-/commit/80e2ad5db107c42d42471ea64764d2b42202349c

The other two still list it in upstream requirements*.  In the case of 
aioresponses, this has been reported as a bug, with no reply as yet:

https://github.com/pnuckowski/aioresponses/issues/162

Skipping the affected tests is probably an option, though obviously a 
non-ideal one.




Bug#963971: samba-libs: libndr.so.0 gone from latest version, breaks sssd-ad-common dependency

2020-06-29 Thread Michael Stone

On Tue, Jun 30, 2020 at 08:48:05AM +1200, Andrew Bartlett wrote:

On Mon, 2020-06-29 at 08:46 -0400, Michael Stone wrote:

Package: samba-libs
Version: 2:4.12.3+dfsg-2
Severity: critical
Justification: breaks the whole system

The new samba-libs package changes the soname of libndr from
libndr.so.0 to
libndr.so.1 without reflecting this change in the package name. sssd-
ad-common
has a dependency on samba-libs (>= 2:4.11.5+dfsg) and links to
libndr.so.0.
When the samba-libs package is updated and libndr.so.0 disappears
sssd fails to
start, which then makes a system's remote users unavailable. (Worse,
this
doesn't happen until the next time sssd restarts--which may not be
until the
next reboot.)

It's not clear why the samba-libs package doesn't include the so
number, but at
the very least it needs a set of dependencies to avoid breaking sssd-
ad-common.


We can't put a version number in samba-libs as there are multiple
public libraries in there.

(Upstream) Samba doesn't promise not to keep doing this - the
underlying change has happened before, but this time we were honest and
bumped the .so - so sssd may need to have a dependency on the Samba
version it built against.


That may well be the best solution going forward, but something else 
needs to be in place to prevent breakage for existing packages.




Bug#962474: CMAKE_SKIP_RPATH=ON improves reproducibility of CMake builds

2020-06-29 Thread Chris Lamb
Timo Röhling wrote:

> >> By default, CMake adds an RPATH entry to ELF binaries and deletes it
> >> again at install time. However, due to the limitations of some
> >> platforms, CMake will actually zero out the RPATH entry in the binary,
> >> leaking the original path length and thus making the build not
> >> reproducible (see the attached diffoscope output for an example).
> >>
> >> CMAKE_SKIP_RPATH disables the RPATH machinery and fixes the issue, and
> >> since most package won't ever ship with an RPATH entry anyway, I propose
> >> adding -DCMAKE_SKIP_RPATH=ON to the default build options.
> > Thanks for the suggestion.
> >
> > Has this proposal been tested on an archive-wide rebuild test to see how
> > much breaks with this option set?
>
> I don't know, but I don't think so. I'm not directly involved with the
> Reproducible Builds Team, I just pinged them on IRC after I filed this
> bug. Cc'ing them now.

As Vagrant implies we have not done an archive-wide rebuild test on
this specifically. (I was actually not aware of this specific issue
until now.) However, let me give you my general thoughts on using our
testing framework for staging changes.

Although we do have the ability to make changes to our toolchain to
test things we don't really like to do this unless absolutely
necessary. Every deviation from Debian itself is a "bug" of sorts and
only confuses users, developers and even the Reproducible Builds team
themselves when things are (for example) reproducible in one
environment or fail to build in a place that folks have zero control
or visibility over.

In addition, in the past when we have had temporary changes they have
persisted far longer than anyone planned. This leads to frustration
and highly-demotivating outcomes when maintainers no long feel a
pressing need to accommodate a change because "well, all the packages
are now reproducible". Well, yeah, I *guess* …

Lastly, making just a small change is actually non-trivial to do and
involves more technical and cognitive overhead than it sounds. "Just"
is a dangerous word, as I am sure you all know. This could probably be
fixed, but we have limited bandwidth and we aren't trying to be a
staging ground anyway. I suppose this would be mitigated if we only
needed to export that particular Debhelper environment variable from
our 'master' build environment vs. uploading a patched package, but
the above arguments still stand as a general rule.

In other words, unless you have no reason to suspect that lots and
lots of things will break, I would highly and strongly recommend that
you simply make the changes in CMake/debhelper and upload. :)

(Speaking only as myself, I don't represent the entire Reproducible
Builds project, etc. etc. etc. And I am partly writing this so I can
refer others to it later in other parallel contexts...)

Thanks for working on this. :)


Regards,

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



Bug#963995: uget: Crashes under XFCE when trying to sort on column "Added on"

2020-06-29 Thread waxhead
Package: uget
Version: 2.2.3-1
Severity: important

Dear Maintainer,

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

   * What led up to the situation?

   Tried to download some files..

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

   I clicked the "added on" column to sort my downloads. uGet just "exits" 
without warning.
   My added downloads are not saved, and not resumable so the URL's have to be 
added again.

   * What was the outcome of this action?

   I "lost data" e.g. I lost my added URL's.

   * What outcome did you expect instead?

   First of all that uGet should not crash, second that my URL's remains saved 
so it would be resumeable.

*** End of the template - remove these template lines ***


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

Kernel: Linux 5.6.0-2-amd64 (SMP w/2 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:en (charmap=UTF-8)
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages uget depends on:
ii  libc62.30-8
ii  libcairo21.16.0-4
ii  libcurl4 7.68.0-1
ii  libgdk-pixbuf2.0-0   2.40.0+dfsg-5
ii  libglib2.0-0 2.64.3-1
ii  libgstreamer1.0-01.16.2-2
ii  libgtk-3-0   3.24.20-1
ii  libnotify4   0.7.9-1
ii  libpango-1.0-0   1.44.7-4
ii  libpangocairo-1.0-0  1.44.7-4
ii  libssl1.11.1.1g-1

uget recommends no packages.

uget suggests no packages.

-- no debconf information



Bug#963983: closed by Gianfranco Costamagna (Re: python3-pyside2.qtsvg: segfault on import)

2020-06-29 Thread ydirson
reopen 963983
thanks

The other pyside2 packages (code, gui etc) were still at 5.15.0-1~exp1.

If I just update qtsvg to 5.15.0-2 the segfault still happens.

Update the rest of pyside2 triggers a huge cascading of upgrades to Qt 5.14
which had not been done when I had installed the exp packages, and when I
updated qtsvg initially.

Among them:

 Unpacking libqt5svg5:amd64 (5.14.2-2) over (5.12.5-2) ...

With all this upgraded, I confirm there is no segfault any more.

Thus, the problem is likely caused by an undeclared versioned dependency on an
underlying lib, and libqt5svg5 looks like a good candidate.  

Not dealing with it is likely to lead to other insufficient partial updates.



Bug#963788: systemd: please make user order and ids of systemd and systemd-timesyncd reproducible

2020-06-29 Thread Chris Lamb
[adding reproducible-bui...@lists.alioth.debian.org to CC]

Johannes 'josch' Schauer wrote:

> This is problem for reproducible installations because the exact same
> package set, consisting of systemd and systemd-timesyncd can result in a
> different system after installation.

I remember working on related issues in Tails which releases
bit-for-bit reproducible ISO images.

In the end, we went with a horrible post-build script that swapped
group IDs that were assigned non-deterministically due to the
arbitrary execution order of the postinst scripts.

I mention this here to encourage us exploring an archive-wide solution
rather than fixing every time it comes up.

This is a particularly good candidate for a general solution as, in my
hard-won experience:

 a) The non-determinism can happen infrequently and thus does not appear
even in extensive testing.

 b) There was no way to flush out the problem in CI (compare using
disorderfs to reverse your filesystem ordering to
deterministically flush out non-deterministic behaviour or similar
tricks.)

 c) Each test build run can take a significant amount of time.

 d) The packages could be entirely unrelated. As in, it could have
been between entirely different packages that could not have been
fixed by adding a relationship.

(Tails also has unrelated reasons for having persistent GIDs across
builds with different inputs. I would immediately concede that
these are out of scope for Debian itself to resolve.)

I'm not sure exactly where this change could be made (dpkg? apt?) as I
lack a confident understanding of the exact roles of those two tools,
but I am assuming that one of these is *eventually* deciding whether to
run the postinst for systemd or systemd-timesyncd first.


Regards,

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



Bug#952041: Fwd: Bug#952041: fixed in ruby-hoe 3.22.1+dfsg1-1

2020-06-29 Thread Lucas Kanashiro
This test failure is still not fixed in version 3.22.1+dfsg1-1. I faced
this issue in Ubuntu:

https://launchpadlibrarian.net/482047556/buildlog_ubuntu-groovy-amd64.ruby-hoe_3.22.1+dfsg1-1_BUILDING.txt.gz

The important part is:

1) Failure:
TestHoe#test_possibly_better
[/<>/ruby-hoe-3.22.1+dfsg1/test/test_hoe.rb:354]: Expected:
2020-05-30 00:00:00 UTC
Actual: 2020-04-02 00:00:00 UTC

39 runs, 104 assertions, 1 failures, 0 errors, 0 skips

This is the failing test:

https://github.com/seattlerb/hoe/blob/v3.22.1/test/test_hoe.rb#L354

After some investigation and chatting with Utkarsh, we noticed the
Actual date which is calling 'spec.date' is for some reason parsing the
date in the last entry of the debian/changelog, while
Gem::Specification::TODAY returns the date you are building the package.

The reason this package built fine in the last upload is because buildd
built it on the same day it was uploaded.

Since this is a downstream issue and this is not a bug in the gem code,
we are planning to patch this package to comment out this single test.

Cheers!

-- 
Lucas Kanashiro



Bug#963943: mupdf-tools: mutool decompression broken due to mismatched jbig2dec versions

2020-06-29 Thread Rogério Brito
Hi, Kan-Ru Chen.

On Jun 30 2020, Kan-Ru Chen wrote:
> On Sun, Jun 28, 2020 at 08:39:19PM -0300, Rogério Brito wrote:
> > The version of mupdf in testing/unstable is partially broken (thus, only
> > severity important, instead of a higher severity).
> > 
> > This happens because mutool produces unparseable/unreadable PDF files when
> > used like the following, if the files contain jbig2 images:
> 
> Thanks for the report. Could you attach the test file so I can test locally?

Sure. I just quickly created one based on a LaTeX file.

BTW, I locally recompiled mupdf with a newer jbig2dec and the problem is gone.


Cheers,

Rogério Brito.

-- 
Rogério Brito : rbrito@{ime.usp.br,gmail.com} : GPG key 4096R/BCFC
http://cynic.cc/blog/ : github.com/rbrito : profiles.google.com/rbrito
DebianQA: http://qa.debian.org/developer.php?login=rbrito%40ime.usp.br


mupdf-test.pdf
Description: Adobe PDF document


Bug#145257: #145257 Re: why did hypercorn migrate to testing?

2020-06-29 Thread Ivo De Decker

Control: retitle -1 [britney] migrations can break build-depends

Hi,

On 6/29/20 5:15 PM, peter green wrote:
> However hypercorn just migrated to testing again, despite the fact that
> python-asynctest is rc buggy and not in testing. This leaves hypercorn
> in violation of "packages must be buildable within the same release".
>
> Any idea why this happened?

Thanks for pointing this out.

On 6/29/20 8:59 PM, Rebecca N. Palmer wrote:

hypercorn is arch:all, and their build-dependencies aren't checked:

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=145257


Thanks for the reference. However, the info in this bug is outdated.

Arch: all build-dependencies have been checked for a while now (since 
cd08deb943 in Jan 2019), but see below.


I didn't close #145257 (and I'm not closing it now), because there are 
still situations where build-dependencies can be broken:


Build-dependencies are (currently) only checked in the excuses step. If 
src a has a build-dependency on binary b, and the excuse for b is a 
valid candidate, a will not be blocked. This means a will be able to 
migrate in the migration stage, even if b isn't able to migrate at that 
point.


Also, if src c has a build-dependency on binary d, and an update of d 
makes the build-dependency of c unsatisfiable, this will not be detected 
by britney.


Note that neither of these cases are arch: all specific. However, a 
common case for arch: any build-dependencies involves libraries, which 
usually also result in dependencies on the binaries. These dependencies 
are checked in the migration stage, so they usually prevent the cases 
described above.


The issue with hypercorn was that there is a bug in build-dependency 
checking when there are multiple build-dependencies that are not 
satisfiable in testing, but are satisfiable by from unstable. Only the 
last one was kept (uvloop in this case). I submitted a fix for this issue:


https://salsa.debian.org/release-team/britney2/-/merge_requests/47

Ivo



Bug#954554: python-asynctest: FTBFS, maybe-RM

2020-06-29 Thread Jonas Smedegaard
[ adding back bugreport as cc ]

Quoting Rebecca N. Palmer (2020-06-29 23:33:20)
> On 29/06/2020 22:27, Jonas Smedegaard wrote:
> > Sorry, what is "the above" you are referring to?
> 
> The previous message in the bug log,

Thanks for clarifying.

 - Jonas

-- 
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/

 [x] quote me freely  [ ] ask before reusing  [ ] keep private

signature.asc
Description: signature


Bug#888025: how to integrate ca-certificates with gpgsm (for email s/mime signature verification)

2020-06-29 Thread John Scott
> looking at the documentation for trustlist.txt in gpg-agent(1) (it seems
> odd to have it documented there, since i thought gpg-agent was for
> secret key material only, weird!), it looks like trustlist.txt has an
> `include-default` option, which maybe defaults to
> `/etc/gnupg/trustlist.txt` on debian (i haven't done much testing!)

Looking at the manual [1] it seems like a potentially more clean way to do 
this might be to synchronize or symlink the trusted ca-certificates with the 
directory /etc/gnupg/trusted-certs/; maybe that's what the option refers to:
> This directory should be filled with certificates of Root CAs you are
> trusting in checking the CRLs and signing OCSP Responses.
> 
> Usually these are the same certificates you use with the applications
> making use of dirmngr. It is expected that each of these certificate
> files contain exactly one DER encoded certificate in a file with the
> suffix .crt or .der. dirmngr reads those certificates on startup and
> when given a SIGHUP. Certificates which are not readable or do not make
> up a proper X.509 certificate are ignored; see the log file for
> details.
> 
> Applications using dirmngr (e.g. gpgsm) can request these certificates
> to complete a trust chain in the same way as with the extra-certs
> directory (see below).
> 
> Note that for OCSP responses the certificate specified using the option
> --ocsp-signer is always considered valid to sign OCSP requests.

Another drawback to the before proposed solution, which would work only on 
keyring creation, may be when a CA gets deleted from ca-certificates, but 
sticks around as trusted for a user. Irregardless either would be an 
improvement over blindly choosing "Correct."

> I'm one of the debian maintainers for gnupg, and i admit that i haven't
> put a lot of work into the gpgsm system integration.
Off-topic, but is the Bash completion support from upstream or downstream? 
gpgsm doesn't support it, which makes mixing up gpg/gpgsm arguments more 
cumbersome.

[1] https://www.gnupg.org/documentation/manuals/gnupg/Dirmngr-Configuration.html


smime.p7s
Description: S/MIME cryptographic signature


Bug#961745: [Pkg-pascal-devel] Bug#961745: [Pkg-utopia-maintainers] Bug#961745: udisks2 2.9.0-1 problems

2020-06-29 Thread Сергей Фёдоров
Based on your suggestion, I wrote to the doublecmd developer and they solved 
this problem. Thanks.



Bug#963887: UDD: 'duck' importer broken since 2020-05-25

2020-06-29 Thread Raphael Hertzog
On Mon, 29 Jun 2020, Baptiste BEAUPLAT wrote:
> > Indeed, creating a dedicated service for this does not seem a good idea.
> 
> I would love to have this feature integrated directly with
> distro-tracker. However, I'm wondering about the load that would case
> for the service.

Network request do not generate much "load", such processes spend the bulk
of their time waiting on the network.

> The duck worker has to process around 46 urls (only counting
> Homepage) in less than 24h.

How do you get to that figure? We don't have that many source package
and even if you consider multiple URL for each source package due to
changes over time (in multiple releases), that makes way too many URLs
per source package.

> I'm not sure that can done properly using
> the distro-tracker tasks (parallel workers are needed to work around
> timeout). Obviously that can be optimized (different check delay for
> different results) but that's still bulk network related tasks.

Nothing forbids parallel workers and in any case, I welcome any
improvement to the task mechanism to make that kind of parallelism easier
to handle.

There are other tasks that could benefit from this (and in general I want
to merge more of such features in distro-tracker to make them available to
derivatives too).

Cheers,
-- 
  ⢀⣴⠾⠻⢶⣦⠀   Raphaël Hertzog 
  ⣾⠁⢠⠒⠀⣿⡁
  ⢿⡄⠘⠷⠚⠋The Debian Handbook: https://debian-handbook.info/get/
  ⠈⠳⣄   Debian Long Term Support: https://deb.li/LTS


signature.asc
Description: PGP signature


Bug#954554: python-asynctest: FTBFS, maybe-RM

2020-06-29 Thread Jonas Smedegaard
Quoting Rebecca N. Palmer (2020-06-29 21:38:29)
> Is the above intended as a proposal to remove asynctest?

Sorry, what is "the above" you are referring to?

 - Jonas

-- 
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/

 [x] quote me freely  [ ] ask before reusing  [ ] keep private

signature.asc
Description: signature


Bug#963971: samba-libs: libndr.so.0 gone from latest version, breaks sssd-ad-common dependency

2020-06-29 Thread Andrew Bartlett
On Mon, 2020-06-29 at 08:46 -0400, Michael Stone wrote:
> Package: samba-libs
> Version: 2:4.12.3+dfsg-2
> Severity: critical
> Justification: breaks the whole system
> 
> The new samba-libs package changes the soname of libndr from
> libndr.so.0 to
> libndr.so.1 without reflecting this change in the package name. sssd-
> ad-common
> has a dependency on samba-libs (>= 2:4.11.5+dfsg) and links to
> libndr.so.0.
> When the samba-libs package is updated and libndr.so.0 disappears
> sssd fails to
> start, which then makes a system's remote users unavailable. (Worse,
> this
> doesn't happen until the next time sssd restarts--which may not be
> until the
> next reboot.)
> 
> It's not clear why the samba-libs package doesn't include the so
> number, but at
> the very least it needs a set of dependencies to avoid breaking sssd-
> ad-common.

We can't put a version number in samba-libs as there are multiple
public libraries in there.

(Upstream) Samba doesn't promise not to keep doing this - the
underlying change has happened before, but this time we were honest and
bumped the .so - so sssd may need to have a dependency on the Samba
version it built against. 

Andrew Bartlett

-- 
Andrew Bartlett   https://samba.org/~abartlet/
Authentication Developer, Samba Team  https://samba.org
Samba Developer, Catalyst IT  
https://catalyst.net.nz/services/samba



Bug#963991: libmkl-rt: libomp-dev dependency too strict

2020-06-29 Thread Marc Glisse
Package: libmkl-rt
Version: 2020.1.217-2
Severity: normal

Dear Maintainer,

I would like to install libomp-11-dev on this computer, but libmkl-rt
has a dependency on libomp-dev | libomp-7-dev | libomp-8-dev, and the
versions of libomp conflict with each other. As far as I know, llvm aims
to keep a compatible ABI on this library. Would it be possible to extend
the list of alternatives to more recent libomp-*-dev? You could even
preventively add libomp-12-dev so you don't have to add it later. I
don't know if it would be ok to depend on the virtual libomp-x.y-dev.

Or maybe the dependency could be downgraded to a recommendation, since
when it cannot find libiomp5.so it seems to fall back to sequential
mode?  With MKL_THREADING_LAYER=GNU and a suitable LD_LIBRARY_PATH
(gcc's libgomp.so is a bit hidden), it even seems possible to use a
threaded mkl without libomp, although that may be asking a bit much from
users. I only did some extremely basic testing, I may be completely
wrong about things actually "working".

(I could probably work around this by rebuilding libomp-dev to depend on
the libomp-*-dev I want, or creating fake packages)

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

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

Versions of packages libmkl-rt depends on:
ii  debconf [debconf-2.0]  1.5.74
ii  libatlas3-base [liblapack.so.3]3.10.3-10
ii  libblas3 [libblas.so.3]3.9.0-2
ii  libc6  2.30-8
ii  libgcc-5-dev   5.5.0-12
ii  libgcc-6-dev   6.5.0-2
ii  libgcc-8-dev   8.4.0-4
ii  liblapack3 [liblapack.so.3]3.9.0-2
ii  libmkl-locale  2020.1.217-2
ii  libmkl-meta-computational  2020.1.217-2
ii  libmkl-meta-interface  2020.1.217-2
ii  libmkl-meta-threading  2020.1.217-2
ii  libomp-dev 1:9.0-49.1
ii  libopenblas0-pthread [liblapack.so.3]  0.3.9+ds-3
ii  libtbb-dev 2020.2-2

libmkl-rt recommends no packages.

libmkl-rt suggests no packages.

-- debconf information:
* libmkl-rt/use-as-default-blas-lapack: true
  libmkl-rt/title:
* libmkl-rt/exact-so-3-selections: libblas.so.3, liblapack.so.3



Bug#963993: dolphin crashes with segfault

2020-06-29 Thread Hans-J. Ullrich
Package: dolphin
Version: 4:20.04.2-1
Severity: important

Dear Maintainer,

I do not know,if this is already been reported, but at the moment dolphin is 
crashing at start.

I am running debian/testing amd64 with plasma5.

This is the output, when dophin is crashing,hope it helps:


 snip --
Application: Dolphin (dolphin), signal: Aborted
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
[Current thread is 1 (Thread 0x7f2a237c4840 (LWP 48133))]

Thread 3 (Thread 0x7f2a21a5d700 (LWP 48136)):
#0  0x7ffe617e88d3 in clock_gettime ()
#1  0x7f2a2d7ca317 in __GI___clock_gettime (clock_id=1, tp=0x7f2a21a5caa0) 
at ../sysdeps/unix/sysv/linux/clock_gettime.c:33
#2  0x7f2a2b7280e1 in ?? () from /usr/lib/x86_64-linux-gnu/libQt5Core.so.5
#3  0x7f2a2b7269f9 in QTimerInfoList::updateCurrentTime() () from 
/usr/lib/x86_64-linux-gnu/libQt5Core.so.5
#4  0x7f2a2b726fc5 in QTimerInfoList::timerWait(timespec&) () from 
/usr/lib/x86_64-linux-gnu/libQt5Core.so.5
#5  0x7f2a2b72853e in ?? () from /usr/lib/x86_64-linux-gnu/libQt5Core.so.5
#6  0x7f2a29197d7f in g_main_context_prepare () from 
/usr/lib/x86_64-linux-gnu/libglib-2.0.so.0
#7  0x7f2a2919872b in ?? () from /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0
#8  0x7f2a2919891f in g_main_context_iteration () from 
/usr/lib/x86_64-linux-gnu/libglib-2.0.so.0
#9  0x7f2a2b7287db in 
QEventDispatcherGlib::processEvents(QFlags) () 
from /usr/lib/x86_64-linux-gnu/libQt5Core.so.5
#10 0x7f2a2b6d16db in 
QEventLoop::exec(QFlags) () from 
/usr/lib/x86_64-linux-gnu/libQt5Core.so.5
#11 0x7f2a2b5126f1 in QThread::exec() () from 
/usr/lib/x86_64-linux-gnu/libQt5Core.so.5
#12 0x7f2a2b9a64e6 in ?? () from /usr/lib/x86_64-linux-gnu/libQt5DBus.so.5
#13 0x7f2a2b513872 in ?? () from /usr/lib/x86_64-linux-gnu/libQt5Core.so.5
#14 0x7f2a29d6cf27 in start_thread (arg=) at 
pthread_create.c:479
#15 0x7f2a2d7bd31f in clone () at 
../sysdeps/unix/sysv/linux/x86_64/clone.S:95

Thread 2 (Thread 0x7f2a22700700 (LWP 48135)):
#0  0x7f2a2d7b2b7f in __GI___poll (fds=0x7f2a226ffc68, nfds=1, timeout=-1) 
at ../sysdeps/unix/sysv/linux/poll.c:29
#1  0x7f2a29fa0d02 in ?? () from /usr/lib/x86_64-linux-gnu/libxcb.so.1
#2  0x7f2a29fa298a in xcb_wait_for_event () from 
/usr/lib/x86_64-linux-gnu/libxcb.so.1
#3  0x7f2a232edca0 in ?? () from /usr/lib/x86_64-linux-gnu/libQt5XcbQpa.so.5
#4  0x7f2a2b513872 in ?? () from /usr/lib/x86_64-linux-gnu/libQt5Core.so.5
#5  0x7f2a29d6cf27 in start_thread (arg=) at 
pthread_create.c:479
#6  0x7f2a2d7bd31f in clone () at 
../sysdeps/unix/sysv/linux/x86_64/clone.S:95

Thread 1 (Thread 0x7f2a237c4840 (LWP 48133)):
[KCrash Handler]
#4  __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:50
#5  0x7f2a2d6e555b in __GI_abort () at abort.c:79
#6  0x7f2a2cccf9f2 in KXMLGUIClient::setXML(QString const&, bool) () from 
/usr/lib/x86_64-linux-gnu/libKF5XmlGui.so.5
#7  0x7f2a2ccd2452 in ?? () from /usr/lib/x86_64-linux-gnu/libKF5XmlGui.so.5
#8  0x7f2a2ccf658b in KXmlGuiWindow::createGUI(QString const&) () from 
/usr/lib/x86_64-linux-gnu/libKF5XmlGui.so.5
#9  0x7f2a2ccf736b in KXmlGuiWindow::setupGUI(QSize const&, 
QFlags, QString const&) () from 
/usr/lib/x86_64-linux-gnu/libKF5XmlGui.so.5
#10 0x7f2a2ccf743d in 
KXmlGuiWindow::setupGUI(QFlags, QString 
const&) () from /usr/lib/x86_64-linux-gnu/libKF5XmlGui.so.5
#11 0x7f2a2d8dc972 in ?? () from 
/usr/lib/x86_64-linux-gnu/libkdeinit5_dolphin.so
#12 0x7f2a2d8cba7f in kdemain () from 
/usr/lib/x86_64-linux-gnu/libkdeinit5_dolphin.so
#13 0x7f2a2d6e6e0b in __libc_start_main (main=0x5561ba073050, argc=1, 
argv=0x7ffe617a3098, init=, fini=, 
rtld_fini=, stack_end=0x7ffe617a3088) at ../csu/libc-start.c:308
#14 0x5561ba07308a in _start ()
[Inferior 1 (process 48133) detached]


-- snap -

Does this tell you all you need?


Thank for any help, hints or tipps.

Best regards

Hans


 

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

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

Versions of packages dolphin depends on:
ii  baloo-kf5  5.70.0-2
ii  kinit  5.70.0-1
ii  kio5.70.1-1
ii  libc6  2.30-8
ii  libdolphinvcs5 4:20.04.2-1
ii  libkf5activities5  5.70.0-1
ii  libkf5baloo5   5.70.0-2
ii  libkf5baloowidgets54:20.04.2-1
ii  libkf5bookmarks5   5.70.0-1
ii  libkf5codecs5  5.70.0-1
ii  libkf5completion5  5.70.0-1
ii  libkf5configcore5  5.70.0-1
ii  

Bug#963992: ITP: concurrentqueue -- industrial-strength lock-free queue for C++

2020-06-29 Thread Steffen Moeller
Package: wnpp
Severity: wishlist

Subject: ITP: concurrentqueue -- industrial-strength lock-free queue for C++
Package: wnpp
Owner: Steffen Moeller 
Severity: wishlist

* Package name: concurrentqueue
  Version : 1.0.1
  Upstream Author : , Cameron Desrochers
* URL : https://github.com/cameron314/concurrentqueue/tags
* License : BSD|Boost
  Programming Lang: C
  Description : industrial-strength lock-free queue for C++
 Features
  * Knock-your-socks-off blazing fast performance.
  * Single-header implementation. Just drop it in your project.
  * Fully thread-safe lock-free queue. Use concurrently from any number
of threads.
  * C++11 implementation -- elements are moved (instead of copied)
where possible.
  * Templated, obviating the need to deal exclusively with pointers --
memory is managed for you.
  * No artificial limitations on element types or maximum count.
Memory can be allocated once up-front, or dynamically as needed.
  * Fully portable (no assembly; all is done through standard C++11
primitives).
  * Supports super-fast bulk operations.
  * Includes a low-overhead blocking version (BlockingConcurrentQueue).
  * Exception safe.
 .
 Reasons to use
 .
 There are not that many full-fledged lock-free queues for C++. Boost has
 one, but it's limited to objects with trivial assignment operators and
 trivial destructors, for example. Intel's TBB queue isn't lock-free,
 and requires trivial constructors too. There're many academic papers
 that implement lock-free queues in C++, but usable source code is hard
 to find, and tests even more so.
 .
 This queue not only has less limitations than others (for the most part),
 but it's also faster. It's been fairly well-tested, and offers advanced
 features like bulk enqueueing/dequeueing (which, with my new design, is
 much faster than one element at a time, approaching and even surpassing
 the speed of a non-concurrent queue even under heavy contention).

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



Bug#913664: Does not integrate with firewalld, will be broken when nftables backend is used

2020-06-29 Thread Michael Biebl
On Tue, 13 Nov 2018 20:38:05 +0100 Michael Biebl  wrote:
> Source: docker.io
> Version: 18.06.1+dfsg1-2
> Severity: normal
> 
> Hi,
> 
> firewalld switched its default backend from iptables to nftables
> recently [1]. Unfortunately, this caused issues with libvirt and as
> reported in [2], also docker. I don't use docker myself, so I'm only
> relaying this information.
> The main problem seems to be, that currently there is no integration
> between docker and firewalld. Both manage firewall rules on their own.
> As soon as nftables(firewalld) and iptables(docker) are mixed, the
> result is a broken network setup.
> Please consider forwarding this issue upstream. Best is probably if
> docker upstream get's in touch with firewalld upstream to figure a
> solution.
>

Fwiw, I've uploaded firewalld 0.8.2-2 which now uses nftables as default
backend. I'll leave it up to you to adjust the severity accordingly.



signature.asc
Description: OpenPGP digital signature


Bug#962307: Acknowledgement (RFS: anymeal/1.0-1 ITA -- Cookbook database for storing recipes)

2020-06-29 Thread Jan Wedekind

Hi,
I have now released version 1.2. It is available here:

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

Also it can be downloaded as follows:

dget -x 
https://mentors.debian.net/debian/pool/main/a/anymeal/anymeal_1.2-1.dsc

Best regards
Jan



Bug#961337: ITP: A secure runtime for JavaScript and TypeScript.

2020-06-29 Thread Paolo Greppi
Il 29/06/20 21:27, Akshat Agarwal ha scritto:
> Package: wnpp
> Followup-For: Bug #961337
> Owner: Akshat Agarwal 
> 
> 
> * Package name: deno
>   Version : 1.1.2
>   Upstream Author : Deno authors
> * URL : https://github.com/denoland/deno
> * License : MIT
>   Programming Lang: Rust, TypeScript, JavaScript
>   Description : A secure runtime for JavaScript and TypeScript.
> 
> I intend to package Deno and maintain it. If anybody is willing to can 
> co-maintain with me.
> 
> Thanks,
> Akshat Agarwal (humancalico)

Hi Akshat,

many thanks for your interest in contributing to Debian. 
would you like to maintain deno within the js-team ?
We already maintain nodejs ...

Paolo



Bug#963990: libemf: FTBFS everywhere

2020-06-29 Thread Sebastian Ramacher
Source: libemf
Version: 1.0.13-1
Severity: serious
Tags: ftbfs
Justification: fails to build from source (but built successfully in the past)

libemf fails to build everywhere:
| dh_missing: warning: usr/lib/x86_64-linux-gnu/libEMF.la exists in debian/tmp 
but is not installed to anywhere 
| dh_missing: error: missing files, aborting
|   The following debhelper tools have reported what they installed (with files 
per package)
|* dh_install: libemf-dev (3), libemf-doc (0), libemf1 (2), printemf (1)
|* dh_installdocs: libemf-dev (0), libemf-doc (4), libemf1 (0), printemf (0)
|* dh_installman: libemf-dev (0), libemf-doc (73), libemf1 (0), printemf (0)
|   If the missing files are installed by another tool, please file a bug 
against it.
|   When filing the report, if the tool is not part of debhelper itself, please 
reference the
|   "Logging helpers and dh_missing" section from the "PROGRAMMING" guide for 
debhelper (10.6.3+).
| (in the debhelper package: /usr/share/doc/debhelper/PROGRAMMING.gz)
|   Be sure to test with dpkg-buildpackage -A/-B as the results may vary when 
only a subset is built
|   For a short-term work-around: Add the files to debian/not-installed
| make: *** [debian/rules:6: binary-arch] Error 25

For example, see
https://buildd.debian.org/status/fetch.php?pkg=libemf=amd64=1.0.13-1=1593211525=0

Cheers
-- 
Sebastian Ramacher


signature.asc
Description: PGP signature


Bug#963989: dracut: misses kernel modules for LUKS volumes using cbc-essiv cipher with Linux 5.4/5.6

2020-06-29 Thread Ansgar
Package: dracut
Version: 050+35-4
Severity: important

Hi,

with Linux 5.4 and later 5.6 dracut no longer included all modules
needed to setup the LUKS volume containing my root partition:

+---
| LUKS header information for /dev/sda2
|
| Version:  1
| Cipher name:  aes
| Cipher mode:  cbc-essiv:sha256
| Hash spec:sha1
+---[ # cryptsetup luksDump /dev/sda2 ]

I had to add

  add_drivers+=" essiv "

for Linux 5.4 and

  add_drivers+=" aes_generic cbc essiv "

later for Linux 5.6 to dracut.conf to get a working system again (not
totally sure if the AES module was needed or not).
https://bugs.debian.org/948593 seems to be the same/similar issue with
initramfs-tools and says some functionality was split out of
`dm_crypt` and moved into extra modules in the Linux kernel, sadly
breaking userspace by doing so.  I also got the "Error allocating
crypto tfm" message mentioned there.

Newer installations using a more modern setup like:

+---
| LUKS header information for /dev/md1
|
| Version:  1
| Cipher name:  aes
| Cipher mode:  xts-plain64
| Hash spec:sha1
+---[ # cryptsetup luksDump /dev/md1 ]

did not require this and continued to work.

It would be nice if the additional modules would be included
automatically when including support for LUKS in the initramfs as more
old installations might still be around.

Ansgar

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

Kernel: Linux 5.7.0-1-amd64 (SMP w/2 CPU cores)
Kernel taint flags: TAINT_FIRMWARE_WORKAROUND
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 /usr/bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages dracut depends on:
ii  dracut-core  050+35-4

dracut recommends no packages.

Versions of packages dracut suggests:
pn  dracut-network  

-- no debconf information



Bug#959420: O: free42-nologo -- Free42 is a re-implementation of the HP-42S calculator

2020-06-29 Thread Stephen Kitt
Control: retitle -1 ITA: free42-nologo -- Free42 is a re-implementation of the 
HP-42S calculator
Control: owner -1 !

On Sat, May 02, 2020 at 10:58:56AM +0200, Tobias Frost wrote:
> The current maintainer of free42-nologo, Christian Stalp ,
> is apparently not active anymore.  Therefore, I orphan this package now.

I’m working with Christian to get an updated version of the package
ready. I’ll change this to an ITA on my behalf for now, to signal that
I am taking care of the package (whether with Christian, or directly,
or co-maintaining).

Regards,

Stephen


signature.asc
Description: PGP signature


Bug#963699: PostgreSQL: WolfSSL support

2020-06-29 Thread Felix Lechner
Hi,

I think Christoph was right. For details, please see below.

On Sat, Jun 27, 2020 at 6:22 AM Florian Weimer  wrote:
>
> At this point, I have no idea what the actual intent is.

In response to your concern, I filed a support request to clarify the
wolfSSL license. Here is the relevant part of my correspondence with
Kaleb Hines, whom I have met on multiple occasions:

> 3. The file COPYING and the individual disclaimers in most files state
> that your library is provided under the GPLv2 or later, while the file
> LICENSING and your website omit the 'or later' language. This is a
> subtle but important difference (the details of which I probably do
> not fully appreciate). It may determine whether wolfSSL can link with
> projects released under the GPLv3, such as 'readline' (used in the
> command line utility 'psql'). Would you please clarify that your open
> source license is the GPLv2+ (emphasis on plus) and includes the ''or
> later' language?

That was Kaleb's reply:

> 3) This is actually clarified in the GPLv2 licensing itself:
> https://www.gnu.org/licenses/old-licenses/gpl-2.0.en.html
>
> 9. The Free Software Foundation may publish revised and/or new
> versions of the General Public License from time to time. Such new
> versions will be similar in spirit to the present version, but may differ
> in detail to address new problems or concerns.
>
> Each version is given a distinguishing version number. If the
> Program specifies a version number of this License which applies
> to it and "any later version", you have the option of following the
> terms and conditions either of that version or of any later version
> published by the Free Software Foundation. If the Program does
> not specify a version number of this License, you may choose
> any version ever published by the Free Software Foundation.
>
> Since wolfSSL specifies the distinguished version 2, this part of
> section 9 of the GPLv2 license applies:
>
> If the Program specifies a version number of this License which
> applies to it and "any later version", you have the option of
> following the terms and conditions either of that version or of any
> later version published by the Free Software Foundation.
>
> Hope that helps to clear up any questions, the verbage may
> differ between our sources and the LICENSE and website
> document however all give a distinguished version. You may
> either follow the terms and conditions of v2 or of any later version
> of the GPL license published by the Free Software Foundation
> as part of the GPLv2 licensing. If this needs any further clarity we
> would be more than happy to setup a call with our management
> for you to go over any outstanding concerns!
>
> Warmest Regards,
>
> Kaleb Himes
>
> If you enjoy working with wolfSSL please leave us a star on our
> github repository https://github.com/wolfSSL/wolfssl!
>
> Position: Software Engineer
> Website: www.wolfssl.com
> Hours: 09:00 - 17:00 MDT
> Email: ka...@wolfssl.com
> News: TLS 1.3 is now available in wolfSSL!

If you have a moment, please leave a star in their Github repo.

Kind regards
Felix Lechner



Bug#963988: transition: zimlib and libkiwix

2020-06-29 Thread Kunal Mehta
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: transition

zimlib and libkiwix are ready to be upgraded to their latest upstream major
versions. Since both are maintained by the same upstream and basically in sync
with each other, I thought it would make sense to do as one transition.

I prepared/tested all of the packages in experimental and it should be good to
go. The zimwriterfs build failures are because it built against and earlier,
buggy zimlib that was missing a dependency.

Ben files:

title = "zimlib";
is_affected = .depends ~ "libzim4" | .depends ~ "libzim6";
is_good = .depends ~ "libzim6";
is_bad = .depends ~ "libzim4";

title = "libkiwix";
is_affected = .depends ~ "libkiwix3" | .depends ~ "libkiwix9";
is_good = .depends ~ "libkiwix9";
is_bad = .depends ~ "libkiwix3";



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

Kernel: Linux 4.19.125-1.pvops.qubes.x86_64 (SMP w/2 CPU cores)
Kernel taint flags: TAINT_OOT_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)



Bug#961490: fwupd: version in stable too old, no updates possible

2020-06-29 Thread Darshaka Pathirana
Hi,

just wanted to let you know that I do *not* get the

  "Not compatible with org.freedesktop.fwupd version 1.2.5, requires >= 1.2.7"

output/error here:

  % sudo fwupdmgr refresh
  Fetching metadata https://cdn.fwupd.org/downloads/firmware.xml.gz
  Downloading… [***]
  Fetching signature https://cdn.fwupd.org/downloads/firmware.xml.gz.asc

  % sudo fwupdmgr get-updates 2>/dev/null | grep -e "has firmware updates" -e 
"^ID" -e "^Update Version"
  UEFI Device Firmware has firmware updates:
  ID:  com.lenovo.ThinkPadN20HT.firmware
  Update Version:  0.1.13
  ID:  com.lenovo.ThinkPadN20HT.firmware
  Update Version:  0.1.12
  ID:  com.lenovo.ThinkPadN20HT.firmware
  Update Version:  0.1.11
  ID:  com.lenovo.ThinkPadN20HT.firmware
  Update Version:  0.1.10

(Yes, I have a pending update).

FYI:

  Package: fwupd
  Version: 1.2.5-2

and:

  % sudo fwupdmgr --version
  client version: 1.2.5
  compile-time dependency versions
  gusb:   0.3.0
  efivar: 37
  daemon version: 1.2.5

20KF001GGE System Firmware (0.1.40) and UEFI Device Firmware
(184.70.3626) have been updated recently.


But my main reason for coming here is the fact that the (critical[1])
Firmware-Update for the Thunderbolt Controller[1][2] and the NVMe[2] is
not detected:

[1] https://pcsupport.lenovo.com/fi/en/solutions/ht508988
[2] https://fwupd.org/lvfs/devices/com.lenovo.ThinkPadN20TF.firmware
[3] https://fwupd.org/lvfs/devices/com.lenovo.PM981.512GB_1TB.firmware

  % sudo fwupdmgr get-devices | grep -v Serial
  ThinkPad X280 Thunderbolt Controller
DeviceId: a4ff56667c8863bbfec8c52b6aa02b51a98a8fb2
Guid: 4808eca4-fd4a-50e6-9e8d-bfd813f063da <- 
TBT-01091704-native
Summary:  Unmatched performance for high-speed I/O
Plugin:   thunderbolt
Flags:internal|updatable|registered
Vendor:   Lenovo
VendorId: TBT:0x0109
Version:  12.00
Icon: computer
Created:  2020-06-29

  20KF001GGE System Firmware
DeviceId: 5a566863d357fb728a620cdf235632fb9bc99f5f
Guid: 508f7539-1ad6-48b9-8680-38377535009d
Plugin:   uefi
Flags:
internal|updatable|require-ac|supported|registered|needs-reboot
Version:  0.1.40
VersionLowest:0.0.1
Icon: computer
Created:  2020-06-29

  UEFI Device Firmware
DeviceId: 093ef0be8328a2c4ed2fe55cd36aae3171b92ade
Guid: 6d28cd9f-7bcd-4fb9-9f10-0372e2962fc4
Plugin:   uefi
Flags:
internal|updatable|require-ac|supported|registered|needs-reboot
Version:  184.70.3626
VersionLowest:0.0.1
Icon: audio-card
Created:  2020-06-29

  UEFI Device Firmware
DeviceId: ca368aebcf7da847029e9f2520ec55fb7a036b31
Guid: 3f4a527b-6588-45b8-b2d3-dc61189b63cb
Plugin:   uefi
Flags:
internal|updatable|require-ac|supported|registered|needs-reboot
Version:  0.1.4
VersionLowest:0.1.4
Icon: audio-card
Created:  2020-06-29

  SAMSUNG MZVLB512HAJQ-000L7
DeviceId: e11623b2caa18fee292058a5c09ca4e6152f7ecf
Guid: 47335265-a509-51f7-841e-1c94911af66b <- 
NVME\VEN_144D_A808
Guid: 8fd4ca73-d0ae-52e8-8977-461435c6f4cf <- NVME\VEN_144D
Guid: 79d6cfae-a5a2-5936-9248-5aebd23480f7 <- SAMSUNG 
MZVLB512HAJQ-000L7
Summary:  NVM Express Solid State Drive
Plugin:   nvme
Flags:
internal|updatable|require-ac|supported|registered|needs-reboot
Vendor:   Samsung Electronics Co Ltd
VendorId: NVME:0x144D
Version:  3L2QEXA7
Icon: drive-harddisk
Created:  2020-06-29

  ST2000LM007-1R8174
DeviceId: 8b2e996216566cd71a3ec9c03bce8a9827a277e0
Guid: fe3873a5-8d96-5cd6-ae8e-aec49f11ed82 <- 
IDE\ST2000LM007-1R8174__EB01
Guid: a3cbe2af-31fd-5848-a7f9-44a95fa5f44d <- 
IDE\0ST2000LM007-1R8174__
Guid: 0f5e4f1e-1732-52a1-88d9-118952f0ffb3 <- 
ST2000LM007-1R8174
Summary:  ATA Drive
Plugin:   ata
Flags:updatable|require-ac|registered|needs-reboot
Version:  EB01
Icon: drive-harddisk
Created:  2020-06-29

  % sudo fwupdmgr get-updates 1>/dev/null
  No upgrades for 20KF001GGE System Firmware, current is 0.1.40: 0.1.30=older, 
0.1.29=older, 0.1.28=older, 

Bug#956700: kvirc: diff for NMU version 4:5.0.0+dfsg-2.1

2020-06-29 Thread Adrian Bunk
On Mon, Jun 29, 2020 at 11:09:58PM +0500, Andrey Rahmatullin wrote:
> On Fri, Jun 19, 2020 at 11:33:41AM +0300, Adrian Bunk wrote:
> > Control: tags 956700 + patch
> > Control: tags 956700 + pending
> > 
> > Dear maintainer,
> > 
> > I've prepared an NMU for kvirc (versioned as 4:5.0.0+dfsg-2.1) and 
> > uploaded it to DELAYED/14. Please feel free to tell me if I should 
> > cancel it.
> Thank you Adrian, I've just uploaded a -3 which includes a fix for this
> bug so you can cancel the NMU

Thanks, I've canceled the NMU.

> (if it won't be cancelled automatically).

It would be uploaded, and then rejected as being older than the version 
already in unstable.

cu
Adrian



Bug#963817: closed by Debian FTP Masters (reply to rebecca_pal...@zoho.com (Rebecca N. Palmer)) (Bug#963817: fixed in pandas 0.25.3+dfsg2-3)

2020-06-29 Thread Paul Gevers
Hi Rebecca, all,

On 29-06-2020 10:33, Debian Bug Tracking System wrote:
>  pandas (0.25.3+dfsg2-3) unstable; urgency=medium
>  .
>* Nested DataFrames may raise ValueError with numpy 1.19
>  (upstream bug 32289).  Clarify error message and xfail tests.
>* Stop using a no-longer-existing numpy constant.

Does this mean that numpy should add a Breaks relation on the old pandas
version to avoid upgrading numpy but not pandas on user systems?

Paul



signature.asc
Description: OpenPGP digital signature


Bug#961337: ITP: A secure runtime for JavaScript and TypeScript.

2020-06-29 Thread Geert Stappers
Control: retitle 961337 ITP: deno, secure runtime for JavaScript and TypeScript
Control: owner 961337 Akshat Agarwal 

On Tue, Jun 30, 2020 at 12:57:39AM +0530, Akshat Agarwal wrote:
> 
> * Package name: deno
>   Upstream Author : Deno authors
> * URL : https://github.com/denoland/deno
> * License : MIT
>   Programming Lang: Rust, TypeScript, JavaScript
>   Description : A secure runtime for JavaScript and TypeScript.
> 
> I intend to package Deno and maintain it.
> If anybody is willing to can co-maintain with me.
 
Yeah, let's seen what happens.

At least is the ITP seen by the uploading sponsor.


> Thanks,
> Akshat Agarwal (humancalico)


Regards
Geert Stappers
-- 
Silence is hard to parse



Bug#963792: transition: ros-*

2020-06-29 Thread Sebastian Ramacher
Control: tags -1 + confirmed

Hi Jochen

On 2020-06-29 19:05:00 +0200, Jochen Sprickerhof wrote:
> Hi Sebastian,
> 
> * Sebastian Ramacher  [2020-06-28 22:58]:
> > > I would like to transition these packages to unstable:
> > > 
> > > ros-roscpp-core
> > > ros-ros-comm
> > > ros-geometric-shapes
> > > ros-urdf
> > > ros-interactive-markers
> > > ros-actionlib
> > > ros-geometry2
> > > ros-vision-opencv
> > > 
> > > Would you be ok with doing all of them at the same time?
> > > (Otherwise I would start with ros-roscpp-core.)
> > 
> > Do all reverse dependencies build fine against the new versions?
> 
> Yes all build fine (sorry for not writing it in the first mail).

Great, so let's do all of them at once. Feel free to go ahead with the
uploads to unstable.

Cheers
-- 
Sebastian Ramacher


signature.asc
Description: PGP signature


Bug#963987: buster-pu: package libtool/2.4.6-9

2020-06-29 Thread Adam D. Barratt
Control: tags -1 + moreinfo

On Mon, 2020-06-29 at 19:23 +, Mohammed Naser wrote:
> The following bug was reported back in 2017:
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=864018
> 
> Because of that bug, it's not possible to build certain packages from
> source such as 'qemu' because it fails with the following:
> 
> powerpc64-linux-gnu-ar: `u' modifier ignored since `D' is the default
> (see `U')

I assume there's some missing detail here, because qemu has been built
in the Debian archive multiple times since 2017.

> The bug explains the details of why/how this issue is happening.

We can't approve an update simply based on a pointer to a bug.

Please attach a copy of the proposed debdiff against the current
package in stable, having built and tested it on a stable system.

Regards,

Adam



Bug#963877: [Android-tools-devel] Bug#963877: apksigner: cannot execute binary file: Exec format error

2020-06-29 Thread Claude Heiland-Allen

Hi Hans-Christoph!

I have binfmt-support installed, but the kernel module is a problem as I 
don't have root on the Android device underneath the UserLAnd Debian 
install. I'll use the java -jar method, perhaps with a shell alias.  Thanks,



Claude



Bug#961337: ITP: A secure runtime for JavaScript and TypeScript.

2020-06-29 Thread Akshat Agarwal
Package: wnpp
Followup-For: Bug #961337
Owner: Akshat Agarwal 


* Package name: deno
  Version : 1.1.2
  Upstream Author : Deno authors
* URL : https://github.com/denoland/deno
* License : MIT
  Programming Lang: Rust, TypeScript, JavaScript
  Description : A secure runtime for JavaScript and TypeScript.

I intend to package Deno and maintain it. If anybody is willing to can 
co-maintain with me.

Thanks,
Akshat Agarwal (humancalico)



Bug#962074: blender: crash in an assertion and doubt about CMAKE_BUILD_TYPE

2020-06-29 Thread Antonio Ospite
Package: blender
Version: 2.83.1+dfsg-1
Followup-For: Bug #962074

Dear Maintainer,

the crasher is still there in 2.83.1+dfsg-1, could you please consider
adjusting the Cmake building flags to avoid it?

A couple of alternative solutions are mentioned in the original report,
let me know if that report is confusing and if you prefer a summary of
the situation.

Thanks,
   Antonio

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

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

Versions of packages blender depends on:
ii  blender-data  2.83.1+dfsg-1
ii  fonts-dejavu  2.37-2
ii  libavcodec58  7:4.3-2
ii  libavdevice58 7:4.3-2
ii  libavformat58 7:4.3-2
ii  libavutil56   7:4.3-2
ii  libboost-locale1.71.0 1.71.0-6+b2
ii  libc6 2.30-8
ii  libfftw3-double3  3.3.8-2
ii  libfreetype6  2.10.1-2
ii  libgcc-s1 10.1.0-4
ii  libgl11.3.1-1
ii  libglew2.12.1.0-4+b1
ii  libgomp1  10.1.0-4
ii  libilmbase24  2.3.0-6
ii  libjack0 [libjack-0.125]  1:0.125.0-3+b1
ii  libjemalloc2  5.2.1-1
ii  libjpeg62-turbo   1:1.5.2-2+b1
ii  libopenal11:1.19.1-1+b1
ii  libopencolorio1v5 1.1.1~dfsg0-6+b1
ii  libopenexr24  2.3.0-6
ii  libopenimageio2.1 2.1.16.0~dfsg0-1
ii  libopenjp2-7  2.3.1-1
ii  libopenvdb7.0 7.0.0-3+b1
ii  libosdcpu3.4.33.4.3-3
ii  libosdgpu3.4.33.4.3-3
ii  libpcre3  2:8.39-13
ii  libpng16-16   1.6.37-2
ii  libpython3.8  3.8.3-1
ii  libsdl2-2.0-0 2.0.12+dfsg1-1
ii  libsndfile1   1.0.28-8
ii  libspnav0 0.2.3-1+b2
ii  libstdc++610.1.0-4
ii  libswscale5   7:4.3-2
ii  libtbb2   2020.2-2
ii  libtiff5  4.1.0+git191117-2
ii  libx11-6  2:1.6.9-2+b1
ii  libxfixes31:5.0.3-2
ii  libxi62:1.7.10-1
ii  libxml2   2.9.10+dfsg-5+b1
ii  libxrender1   1:0.9.10-1
ii  libxxf86vm1   1:1.1.4-1+b2
ii  zlib1g1:1.2.11.dfsg-2

blender recommends no packages.

blender suggests no packages.

-- no debconf information
-- 
Antonio Ospite
https://ao2.it
https://twitter.com/ao2it

A: Because it messes up the order in which people normally read text.
   See http://en.wikipedia.org/wiki/Posting_style
Q: Why is top-posting such a bad thing?



Bug#963987: buster-pu: package libtool/2.4.6-9

2020-06-29 Thread Mohammed Naser
Package: release.debian.org
Severity: normal
Tags: buster
User: release.debian@packages.debian.org
Usertags: pu

The following bug was reported back in 2017:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=864018

Because of that bug, it's not possible to build certain packages from
source such as 'qemu' because it fails with the following:

powerpc64-linux-gnu-ar: `u' modifier ignored since `D' is the default (see `U')

The bug explains the details of why/how this issue is happening.

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

Kernel: Linux 4.19.0-4-cloud-amd64 (SMP w/32 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



Bug#963986: buster-pu: package nvidia-graphics-drivers/418.152.00-1

2020-06-29 Thread Andreas Beckmann
Package: release.debian.org
Severity: normal
Tags: buster
User: release.debian@packages.debian.org
Usertags: pu

This is a new upstream release fixing CVE-2020-5963 and CVE-2020-5967.
Since NVIDIA does not seem to release updates for the "regular" 418 driver
any longer, I switched to the "Tesla" 418 driver.
The packaging changes are minimal this time ;-) (renamed lintian tags,
removed/refreshed patches and some patches for Linux 5.5/5.7).
The upload is comparable to the nvidia-graphics-drivers-tesla-418
418.152.00-1 upload to sid a few minutes ago.
I chose to keep the patches for Linux 5.5/5.7 even if they are not needed
for buster in order to keep the diff to nvidia-graphics-drivers-tesla-418
minimal and therefore have more test coverage on the 418 driver series.
(sid is already at 440.xx which is not a replacement candidate for buster
due to removed features.)

Andreas


ngd-418.152.00-1.diff.gz
Description: application/gzip


Bug#949055: autofs: FTBFS with libxml2 2.9.10 (uses xml2-config)

2020-06-29 Thread Mike Gabriel

On  Mo 29 Jun 2020 15:25:26 CEST, Hugh McMaster wrote:


Hallo Andreas,

Did you ever have time to follow up with upstream about your patch?

I saw they had some feedback that needs to be addressed before the
patch can be merged.

It looks very straightforward to fix. If will not have time, I am
happy to take care of this and resubmit the final patch under your
name.

Hugh


Wow. That'd be awesome helping out on this, Hugh.

Thanks.
Mike
--

DAS-NETZWERKTEAM
c\o Technik- und Ökologiezentrum Eckernförde
Mike Gabriel, Marienthaler Str. 17, 24340 Eckernförde
mobile: +49 (1520) 1976 148
landline: +49 (4351) 850 8940

GnuPG Fingerprint: 9BFB AEE8 6C0A A5FF BF22  0782 9AF4 6B30 2577 1B31
mail: mike.gabr...@das-netzwerkteam.de, http://das-netzwerkteam.de



pgp44kTBpUjaq.pgp
Description: Digitale PGP-Signatur


Bug#963985: smbclient: /usr/bin/mdfind is already shipped by mdfinder.app

2020-06-29 Thread Andreas Beckmann
Package: smbclient
Version: 2:4.12.3+dfsg-2
Severity: serious
User: trei...@debian.org
Usertags: edos-file-overwrite

Hi,

automatic installation tests of packages that share a file and at the
same time do not conflict by their package dependency relationships has
detected the following problem:

  Selecting previously unselected package smbclient.
  Preparing to unpack .../7-smbclient_2%3a4.12.3+dfsg-2_amd64.deb ...
  Unpacking smbclient (2:4.12.3+dfsg-2) ...
  dpkg: error processing archive 
/tmp/apt-dpkg-install-HFItAj/7-smbclient_2%3a4.12.3+dfsg-2_amd64.deb (--unpack):
   trying to overwrite '/usr/bin/mdfind', which is also in package mdfinder.app 
0.9.4-2+b1
  dpkg-deb: error: paste subprocess was killed by signal (Broken pipe)
  Errors were encountered while processing:
   /tmp/apt-dpkg-install-HFItAj/7-smbclient_2%3a4.12.3+dfsg-2_amd64.deb

This is a serious bug as it makes installation fail, and violates
sections 7.6.1 and 10.1 of the policy. An optimal solution would
consist in only one of the packages installing that file, and renaming
or removing the file in the other package. Depending on the
circumstances you might also consider Replace relations or file
diversions. If the conflicting situation cannot be resolved then, as a
last resort, the two packages have to declare a mutual
Conflict. Please take into account that Replaces, Conflicts and
diversions should only be used when packages provide different
implementations for the same functionality.

Here is a list of files that are known to be shared by both packages
(according to the Contents file for sid/amd64, which may be
slightly out of sync):

  usr/bin/mdfind
  usr/share/man/man1/mdfind.1.gz


Cheers,

Andreas

PS: for more information about the detection of file overwrite errors
of this kind see https://qa.debian.org/dose/file-overwrites.html


mdfinder.app=0.9.4-2+b1_smbclient=2:4.12.3+dfsg-2.log.gz
Description: application/gzip


Bug#870383: gpgme1.0: FTBFS on hurd-i386: hardinging flags mismatch w.r.t. Qt5

2020-06-29 Thread Gianfranco Costamagna
control: forwarded -1 https://dev.gnupg.org/T4982

thanks

G.



Bug#937959: python-ntlm: Python2 removal in sid/bullseye

2020-06-29 Thread Moritz Mühlenhoff
On Fri, Aug 30, 2019 at 07:43:00AM +, Matthias Klose wrote:
> Package: src:python-ntlm
> Version: 1.1.0-1
> Severity: normal
> Tags: sid bullseye
> User: debian-pyt...@lists.debian.org
> Usertags: py2removal
> 
> Python2 becomes end-of-live upstream, and Debian aims to remove
> Python2 from the distribution, as discussed in
> https://lists.debian.org/debian-python/2019/07/msg00080.html

While there's some upstream activity, the last release on pypi
is from 2014 and without Py3 support, given that there are no
reverse deps might be best to simply remove it?

Cheers,
Moritz



Bug#937490: pynifti: Python2 removal in sid/bullseye

2020-06-29 Thread Michael Hanke
Hi,

yes, that sounds like to best course of action to me.

Best,

Michael

On Mon, Jun 29, 2020, 20:38 Moritz Mühlenhoff  wrote:

> On Fri, Aug 30, 2019 at 07:34:39AM +, Matthias Klose wrote:
> > Package: src:pynifti
> > Version: 0.20100607.1-4.1
> > Severity: normal
> > Tags: sid bullseye
> > User: debian-pyt...@lists.debian.org
> > Usertags: py2removal
> >
> > Python2 becomes end-of-live upstream, and Debian aims to remove
> > Python2 from the distribution, as discussed in
> > https://lists.debian.org/debian-python/2019/07/msg00080.html
>
> The upstream homepage states
>
> | PyNIfTI is no longer actively developed. At has been
> | superseded by NiBabel -- a pure-Python package that
> | provides everything that PyNIfTI could do, and a lot more.
>
> Given that nibabel is packaged, let's simply remove pynifti?
>
> Cheers,
> Moritz
>


Bug#963964: release-notes: document aufs removal for bullseye

2020-06-29 Thread Andrei POPESCU
Control: tags -1 moreinfo

On Lu, 29 iun 20, 10:31:02, Holger Levsen wrote:
> package: release-notes
> x-debbugs-cc: Timo Weingärtner , Jan Luca 
> Naumann , 963...@bugs.debian.org, 
> debian-de...@lists.debian.org
> 
> in #963191 on Mon, Jun 29, 2020 at 10:06:33AM +0200, Bastian Blank wrote:
> > On Mon, Jun 29, 2020 at 09:32:09AM +0200, Timo Weingärtner wrote:
> > > 20.06.20 13:26 Bastian Blank:
> > > > Since the kernel supports overlayfs since some time now, what blocks
> > > > it's removal?
> > > There are Debian installations on filesystems that are incompatible with 
> > > overlayfs, for example xfs without d_type.
> > > I ran into this while trying to get rid of aufs.
> > So we need to document this problem in the release notes.  That's an
> > easy task.

Some more details (or even better, suggested wording) would be much 
appreciated, just in case none of the Release Notes editors are familiar 
with XFS and 'd_type'.

Kind regards,
Andrei
-- 
http://wiki.debian.org/FAQsFromDebianUser


signature.asc
Description: PGP signature


Bug#937490: pynifti: Python2 removal in sid/bullseye

2020-06-29 Thread Moritz Mühlenhoff
On Fri, Aug 30, 2019 at 07:34:39AM +, Matthias Klose wrote:
> Package: src:pynifti
> Version: 0.20100607.1-4.1
> Severity: normal
> Tags: sid bullseye
> User: debian-pyt...@lists.debian.org
> Usertags: py2removal
> 
> Python2 becomes end-of-live upstream, and Debian aims to remove
> Python2 from the distribution, as discussed in
> https://lists.debian.org/debian-python/2019/07/msg00080.html

The upstream homepage states

| PyNIfTI is no longer actively developed. At has been
| superseded by NiBabel -- a pure-Python package that
| provides everything that PyNIfTI could do, and a lot more.

Given that nibabel is packaged, let's simply remove pynifti?

Cheers,
Moritz



Bug#956700: kvirc: diff for NMU version 4:5.0.0+dfsg-2.1

2020-06-29 Thread Andrey Rahmatullin
On Fri, Jun 19, 2020 at 11:33:41AM +0300, Adrian Bunk wrote:
> Control: tags 956700 + patch
> Control: tags 956700 + pending
> 
> Dear maintainer,
> 
> I've prepared an NMU for kvirc (versioned as 4:5.0.0+dfsg-2.1) and 
> uploaded it to DELAYED/14. Please feel free to tell me if I should 
> cancel it.
Thank you Adrian, I've just uploaded a -3 which includes a fix for this
bug so you can cancel the NMU (if it won't be cancelled automatically).

-- 
WBR, wRAR


signature.asc
Description: PGP signature


Bug#963984: ITP: ruby-sys-proctable -- Ruby interface for gathering process informatio

2020-06-29 Thread Valentin Vidic
Package: wnpp
Severity: wishlist
Owner: Valentin Vidic 

* Package name: ruby-sys-proctable
  Version : 1.2.5
  Upstream Author : Daniel J. Berger 
* URL : https://github.com/djberg96/sys-proctable
* License : Apache-2.0
  Programming Lang: Ruby
  Description : Ruby interface for gathering process informatio

The sys-proctable library provides an interface for gathering information
about processes on your system, i.e. the process table. Most major
platforms are supported and, while different platforms may return
different information, the external interface is identical across
platforms.

This library is required as a dependency for the new version of the
sonic-pi package. The package will be maintained in the ruby-team
group on Salsa.



Bug#963957: openvswitch-switch-dpdk: Packaging is broken

2020-06-29 Thread Schmidt, Adriaan
Hi Thomas,

> I very much would appreciate some contributions here. Do you have enough
> time and skills to fix the package, and provide a patch? If so, I would 
> accept it
> in any form: a patch file on the BTS, or a merge request on Salsa. The only
> thing is, I'm not closely monitoring merge requests, so please write in the 
> BTS
> to signal it if that's what you choose.

I'm not exactly an expert here, but I have a patch that works for me.
I suspect the *-dbg package might be broken with respect to the DPDK variant, 
but I haven't tested that.

Best,
Adriaan


openvswitch-switch-dpdk-package.patch
Description: openvswitch-switch-dpdk-package.patch


Bug#963877: [Android-tools-devel] Bug#963877: apksigner: cannot execute binary file: Exec format error

2020-06-29 Thread Hans-Christoph Steiner


Hello Claude!

Looks like your binfmt support isn't working.  You need both the package
binfmt-support and the kernel module installed, then it works.  Or you
can always do the `java -jar` method.

.hc



Bug#951048: util-linux: please build with dm-verity support when uploading 2.35

2020-06-29 Thread Michael Biebl
Hi Luca

On Mon, 29 Jun 2020 12:16:39 +0100 Luca Boccassi  wrote:
> On Mon, 2020-06-29 at 12:58 +0200, Michael Biebl wrote:
> > Am 29.06.20 um 12:41 schrieb Luca Boccassi:
> > > In terms of image size, what % does that additional 5.6MB represent?
> > 
> > A minbase debootstrap of bullseye is currently 197M
> 
> Thanks - so about ~2.5%. I can look into changing to dlopen as you
> suggested in the next few days.

I see that Simon has been very active in tracking down and informing all
affected upstreams and trying to get them on board in fixing this in a
coordinated fashion.

As far as libmount is concerned, I think going the upstream route is
definitely the right approach. We shouldn't do this downstream. Let's
see what Karel has to say.
Btw, thanks for the offer to look into this.

Regards,
Michael



signature.asc
Description: OpenPGP digital signature


Bug#963887: UDD: 'duck' importer broken since 2020-05-25

2020-06-29 Thread Baptiste BEAUPLAT
Hi Bastian, Raphael,

On 6/29/20 3:55 PM, Raphael Hertzog wrote:
> On Sun, 28 Jun 2020, Bastian Blank wrote:
>>> Baptiste (CCed) volunteered to write it over again, but for now there is
>>> no clear timeline as for when the new project will be started.
>>
>> Maybe you could add that to vcswatch?

The main differences between vcswatch and duck.d.n are:

- history: duck used to keep 6 runs for each package, reporting only
after 3 failures. vcswatch only keeps the last run.
- d/control: duck processed the Homepage as well as the
Vcs-{Git,SVN,Hg,Darcs} fields. vcswatch has a wider support for all Vcs-*.
- d/upstream/metadata: duck processed any urls found here.
- worker: parallel worker for duck, single instance for vcswatch.

(sorry if I got anything wrong here. Please correct me!)

I'm not convinced that adding those features would result in an
improvement for vcswatch (Cc'ing Christoph to have his input on that).

Creating a new sub-project, like vcswatch, to qa.debian.org would be
more sensible IMHO. The new duck could only take care of the http urls
and leave Vcs stuff to vcswatch.

> or distro-tracker?
> 
> Indeed, creating a dedicated service for this does not seem a good idea.

I would love to have this feature integrated directly with
distro-tracker. However, I'm wondering about the load that would case
for the service.

The duck worker has to process around 46 urls (only counting
Homepage) in less than 24h. I'm not sure that can done properly using
the distro-tracker tasks (parallel workers are needed to work around
timeout). Obviously that can be optimized (different check delay for
different results) but that's still bulk network related tasks.

Another thing is that duck.d.n was delegating the actual checks to the
`duck` perl library. To work with distro-tracker I would need to drop
that an implement something silimar in python. Not a huge task per se,
but something to keep in mind.

I'm not sure what is best here and I'm looking forward to your
suggestions and remarks.
-- 
Baptiste BEAUPLAT - lyknode



signature.asc
Description: OpenPGP digital signature


Bug#962474: CMAKE_SKIP_RPATH=ON improves reproducibility of CMake builds

2020-06-29 Thread Niels Thykier
Vagrant Cascadian:
> On 2020-06-29, Vagrant Cascadian wrote:
>> On 2020-06-29, Vagrant Cascadian wrote:
>>> On 2020-06-29, Timo Röhling wrote:
>> By default, CMake adds an RPATH entry to ELF binaries and deletes it
>> again at install time. However, due to the limitations of some
>> platforms, CMake will actually zero out the RPATH entry in the binary,
>> leaking the original path length and thus making the build not
>> reproducible (see the attached diffoscope output for an example).
>>
>> CMAKE_SKIP_RPATH disables the RPATH machinery and fixes the issue, and
>> since most package won't ever ship with an RPATH entry anyway, I propose
>> adding -DCMAKE_SKIP_RPATH=ON to the default build options.
> Thanks for the suggestion.
>>>
>>> Thanks for identifying the issue!
>>>
>>>
> Has this proposal been tested on an archive-wide rebuild test to see how
> much breaks with this option set?
 I don't know, but I don't think so. I'm not directly involved with the
 Reproducible Builds Team, I just pinged them on IRC after I filed this
 bug. Cc'ing them now.
>>>
>>> There is currently only one package tagged with:
>>>
>>>   
>>> https://tests.reproducible-builds.org/debian/issues/unstable/cmake_rpath_contains_build_path_issue.html
>>
>> Also worth mentioning the upstream issue:
>>
>>   https://gitlab.kitware.com/cmake/cmake/-/issues/18413
> 
> And BUILD_RPATH_USE_ORIGIN:
> 
>   
> https://gitlab.kitware.com/cmake/cmake/-/blob/master/Help/prop_tgt/BUILD_RPATH_USE_ORIGIN.rst
> 
> 
> live well,
>   vagrant
> 

Ok, I will add a temporary undocumented variable for you to test this.
It accepts any space separated list of "key-value pairs", which can be
used to override -D flags passed to cmake.  An example being:

export DH_INTERNAL_RB_TEST_BUG962474="CMAKE_SKIP_RPATH=ON"

But you can substitute it with other flags if you also want or need to
experiment with other flags, such as:

export DH_INTERNAL_RB_TEST_BUG962474="CMAKE_SKIP_RPATH=OFF \
  BUILD_RPATH_USE_ORIGIN=ON"

For the ease of debugging, debhelper will be verbal about this feature
being used.

It will be available with the next upload and be removed once your tests
have concluded.

~Niels



Bug#963983: python3-pyside2.qtsvg: segfault on import

2020-06-29 Thread ydirson
Package: python3-pyside2.qtsvg
Version: 5.15.0-1
Severity: grave

$ gdb python3
...
Reading symbols from python3...
Reading symbols from 
/usr/lib/debug/.build-id/97/0f19629d98e5c631b44f6803fa34a5a07c3806.debug...

(gdb) r
Starting program: /usr/bin/python3 
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
Python 3.8.3 (default, May 14 2020, 11:03:12) 
[GCC 9.3.0] on linux
Type "help", "copyright", "credits" or "license" for more information.

>>> from PySide2 import QtSvg
Program received signal SIGSEGV, Segmentation fault.
0x772cf2eb in Shiboken::ObjectType::introduceWrapperType(_object*, char 
const*, char const*, PyType_Spec*, char const**, void (*)(void*), 
SbkObjectType*, _object*, unsigned int) ()
   from 
/usr/lib/x86_64-linux-gnu/libshiboken2.cpython-38-x86_64-linux-gnu.so.5.15

(gdb) bt
#0  0x772cf2eb in Shiboken::ObjectType::introduceWrapperType(_object*, 
char const*, char const*, PyType_Spec*, char const**, void (*)(void*), 
SbkObjectType*, _object*, unsigned int)
() from 
/usr/lib/x86_64-linux-gnu/libshiboken2.cpython-38-x86_64-linux-gnu.so.5.15
#1  0x7731ec41 in ?? () from 
/usr/lib/python3/dist-packages/PySide2/QtSvg.cpython-38-x86_64-linux-gnu.so
#2  0x7732a6a3 in PyInit_QtSvg () from 
/usr/lib/python3/dist-packages/PySide2/QtSvg.cpython-38-x86_64-linux-gnu.so
#3  0x0067d0aa in _PyImport_LoadDynamicModuleWithSpec (
spec=, 
origin='/usr/lib/python3/dist-packages/PySide2/QtSvg.cpython-38-x86_64-linux-gnu.so',
 loader_state=None, submodule_search_locations=None, _set_fileattr=True, 
_cached=None) at remote 0x7760d1f0>, fp=) at 
../Python/importdl.c:164
#4  0x0067dafd in _imp_create_dynamic_impl (module=, 
file=, 
spec=, 
origin='/usr/lib/python3/dist-packages/PySide2/QtSvg.cpython-38-x86_64-linux-gnu.so',
 loader_state=None, submodule_search_locations=None, _set_fileattr=True, 
_cached=None) at remote 0x7760d1f0>) at ../Python/import.c:2221
#5  _imp_create_dynamic (module=, args=, 
nargs=) at ../Python/clinic/import.c.h:330
#6  0x005c066c in cfunction_vectorcall_FASTCALL (func=, args=, nargsf=, 
kwnames=) at ../Objects/methodobject.c:422
#7  0x005f1da9 in PyVectorcall_Call (callable=, tuple=, kwargs={}) at ../Objects/call.c:199
#8  0x0056d160 in do_call_core (kwdict={}, 
callargs=(, 
origin='/usr/lib/python3/dist-packages/PySide2/QtSvg.cpython-38-x86_64-linux-gnu.so',
 loader_state=None, submodule_search_locations=None, _set_fileattr=True, 
_cached=None) at remote 0x7760d1f0>,), func=, tstate=) at 
../Python/ceval.c:4983
#9  _PyEval_EvalFrameDefault (f=, throwflag=) at 
../Python/ceval.c:3559
#10 0x00565602 in PyEval_EvalFrameEx (throwflag=0, 
f=Frame 0x77677610, for file , line 219, 
in _call_with_frames_removed (f=, args=(, 
origin='/usr/lib/python3/dist-packages/PySide2/QtSvg.cpython-38-x86_64-linux-gnu.so',
 loader_state=None, submodule_search_locations=None, _set_fileattr=True, 
_cached=None) at remote 0x7760d1f0>,), kwds={})) at ../Python/ceval.c:741
#11 _PyEval_EvalCodeWithName (_co=, globals=, 
locals=, args=, argcount=, 
kwnames=, 
kwargs=0x776de7e0, kwcount=, kwstep=1, defs=0x0, 
defcount=0, kwdefs=0x0, closure=0x0, name='_call_with_frames_removed', 
qualname='_call_with_frames_removed')
at ../Python/ceval.c:4298
#12 0x005f12a3 in _PyFunction_Vectorcall (func=, 
stack=0x776de7d0, nargsf=, kwnames=) at 
../Objects/call.c:435
#13 0x0056c1bf in _PyObject_Vectorcall (kwnames=0x0, nargsf=, args=0x776de7d0, callable=) at 
../Include/cpython/abstract.h:127
#14 call_function (kwnames=0x0, oparg=, pp_stack=, tstate=0x959e20) at ../Python/ceval.c:4963
#15 _PyEval_EvalFrameDefault (f=, throwflag=) at 
../Python/ceval.c:3469
#16 0x005f10c6 in PyEval_EvalFrameEx (throwflag=0, 
f=Frame 0x776de640, for file , 
line 1357, in create_module (self=, spec=, 
origin='/usr/lib/python3/dist-packages/PySide2/QtSvg.cpython-38-x86_64-linux-gnu.so',
 loader_state=None, submodule_search_locations=None, _set_fileattr=True, 
_cached=None) at remote 0x7760d1f0>)) at ../Python/ceval.c:741
#17 function_code_fastcall (globals=, nargs=, 
args=, co=) at ../Objects/call.c:283
#18 _PyFunction_Vectorcall (func=, stack=, 
nargsf=, kwnames=) at ../Objects/call.c:410
#19 0x005674c7 in _PyObject_Vectorcall (kwnames=0x0, nargsf=, args=0x777b2a30, callable=) at 
../Include/cpython/abstract.h:127
#20 call_function (kwnames=0x0, oparg=, pp_stack=, tstate=0x959e20) at ../Python/ceval.c:4963
#21 _PyEval_EvalFrameDefault (f=, throwflag=) at 
../Python/ceval.c:3486
#22 0x005f10c6 in PyEval_EvalFrameEx (throwflag=0, 
f=Frame 0x777b28b0, for file , line 556, 
in module_from_spec (spec=, 
origin='/usr/lib/python3/dist-packages/PySide2/QtSvg.cpython-38-x86_64-linux-gnu.so',
 loader_state=None, submodule_search_locations=None, _set_fileattr=True, 
_cached=None) 

Bug#881719: libcdio 2.1.0 and lubcdio++

2020-06-29 Thread Gabriel F. T. Gomes
Hi, Vasyl,

On Mon, 29 Jun 2020, Vasyl Gello wrote:

> The MR I amended after Gabriel's review is stuck since June 2nd.

Yes, my bad.

> Gabriel, can you please revise the MR and upload the fixed package to the 
> queue?

Will do (I'll try to do it today)! Thanks for the heads-up.

:)



Bug#963980: bumblebee-nvidia: Bumblebee daemon reported: error: [XORG] (EE) Unable to locate/open config directory

2020-06-29 Thread Vincas Dargis

In bumblebee changelog I see:

  * Simplify rules and use bumblebee.install etc. for installation.
  * Remove obsolete conffile /etc/bumblebee/xorg.conf.d/10-dummy.conf.

Could these introduce some sort of regression in my case?



Bug#963792: transition: ros-*

2020-06-29 Thread Jochen Sprickerhof

Hi Sebastian,

* Sebastian Ramacher  [2020-06-28 22:58]:

I would like to transition these packages to unstable:

ros-roscpp-core
ros-ros-comm
ros-geometric-shapes
ros-urdf
ros-interactive-markers
ros-actionlib
ros-geometry2
ros-vision-opencv

Would you be ok with doing all of them at the same time?
(Otherwise I would start with ros-roscpp-core.)


Do all reverse dependencies build fine against the new versions?


Yes all build fine (sorry for not writing it in the first mail).

Cheers Jochen


signature.asc
Description: PGP signature


Bug#963982: intel-mediasdk: Please upload 20.1.0 to unstable

2020-06-29 Thread Vasyl Gello
Source: intel-mediasdk
Version: 20.1.0
Severity: normal

Dear colleagues,

I see intel-mediasdk 20.1.0 has been shipped to ubuntu but not to debian 
unstable.

I would like to have it in ubstable and later in buster-backports.

I tested it by building a no-change backport to satisfy the dependency for 
ffmpeg 4.3
and in turn kodi 19.0. The only change I had to do is declare the 
"upstream/20.1.0" tag
to make "gbp buildpackage" happy.

Is it possible to make such upload?

Vasyl 

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

Kernel: Linux 4.15.0-108-generic (SMP w/6 CPU cores)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=C, LC_CTYPE=C (charmap=UTF-8) (ignored: LC_ALL set to 
en_US.UTF-8), LANGUAGE=C (charmap=UTF-8) (ignored: LC_ALL set to en_US.UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: unable to detect



Bug#963981: ITP: dextractor -- (d)extractor and compression command library

2020-06-29 Thread Shayan Doust
Package: wnpp
Severity: wishlist

Subject: ITP: dextractor -- (d)extractor and compression command library
Package: wnpp
Owner: Shayan Doust 
Severity: wishlist

* Package name: dextractor
  Version : 1.0
  Upstream Author : Dr. Eugene W. Myers (EWM)
* URL : https://github.com/thegenemyers/DEXTRACTOR
* License : BSD-3-Clause
  Programming Lang: C
  Description : (d)extractor and compression command library
 Dextractor commands allow one to pull exactly and only the
 information needed for assembly and reconstruction from the source HDF5
 files produced by the PacBio RS II sequencer, or from the source BAM
 files produced by the PacBio Sequel sequencer.
 .
 For each of the three extracted file types -- fasta, quiva, and 
 arrow -- the library contains commands to compress the given file
 type, and to decompress it, which is a reversible process delivering
 the original uncompressed file. The compressed .fasta files, with the
 extension .dexta, consume 1/4 byte per base. The compressed .quiva
 files, with the extension .dexqv, consume 1.5 bytes per base on
 average, and the compressed .arrow files, with the extension .dexar,
 consume 1/4 byte per base
 .
 For more information, please view the available documentation at
 https://github.com/thegenemyers/DEXTRACTOR

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



Bug#950856: fmtlib: Please upload source package to salsa.debian.org and set Vcs-*

2020-06-29 Thread Vasyl Gello
Hi Eugene,

I second Michael's request for uploading fmtlib to Salsa.
I am working on Kodi 19.0 "Matrix" and fmtlib is one of its build dependencies.
I would like to get fmtlib uploaded to buster-backports but first I would like 
to package the latest tagged release 6.2.1.

To do that, Git repository is much more convenient then sending patches here 
and there across tge mailing lists.

Cheers!

On Tue, 18 Feb 2020 14:25:33 +0100 "Eugene V. Lyubimkin"  
wrote:
> Hello!
> 
> Michael R. Crusoe kirjoitti 7.2.2020 klo 14.33:
> > Hello, please upload source package to salsa.debian.org and set Vcs-*; 
> > thanks
> 
> I currently don't have plans to upload packaging to some particular location.
> 
> Any particular reason the packaging location is important for you?
> 
> 
> Regards,
> -- 
> Eugene V. Lyubimkin aka JackYF
> C++ GNU/Linux userspace developer, Debian Developer
> 
> 

-- 
Vasyl Gello
==
Certified SolidWorks Expert

Mob.:+380 (98) 465 66 77

E-Mail: vasek.ge...@gmail.com

Skype: vasek.gello
==
호랑이는 죽어서 가죽을 남기고 사람은 죽어서 이름을 남긴다

signature.asc
Description: PGP signature


Bug#963953: cpanminus depends on 'make' to work - but installing cpanminus does not install 'make'.

2020-06-29 Thread Joao Miguel Ferreira
Hello, Gregor and Jeff,

On Mon, Jun 29, 2020 at 5:48 PM gregor herrmann  wrote:

>
> Good catch, thank you.
>
> I wonder
> - whether make is enough, as gcc etc. is needed as well for XS
>   modules, so maybe we should use build-essential?
> - whethere we want this in Depends or in Recommends
>
>
In my opinion the fact that the installation of cpanminus does not install
also make or gcc is a good thing. There are many situations where no
building or compiling is required. I have seen, as reported, cpanminus
indications that make is required and gcc too when needed. That is good.

I understand that in some cases the installation of make and gcc would
avoid some debugging and even reduce inefficiency.

So in my case it 's just a matter of having more fine grained control and
also avoid the extra disk space required by make and gcc.

It cpanm works well with only make and gcc, but build-essentials would be a
more comprehensive approach.

So, I vote for non-hard dependency

Cheers
Thank you
João



>
> 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: The Doors: I Looked At You
>


Bug#963979: libhibernate-validator{,4}-java: both ship /usr/share/java/hibernate-validator.jar

2020-06-29 Thread Andreas Beckmann
Package: libhibernate-validator-java,libhibernate-validator4-java
Severity: serious
User: debian...@lists.debian.org
Usertags: piuparts
Control: found -1 4.3.4-2
Control: found -1 5.3.6-1

Hi,

during a test with piuparts I noticed your package failed to install
because it tries to overwrite other packages files without declaring a
Breaks+Replaces relation.

>From the attached log (scroll to the bottom...):

  Selecting previously unselected package libhibernate-validator4-java.
  Preparing to unpack .../libhibernate-validator4-java_4.3.4-2_all.deb ...
  Unpacking libhibernate-validator4-java (4.3.4-2) ...
  dpkg: error processing archive 
/var/cache/apt/archives/libhibernate-validator4-java_4.3.4-2_all.deb (--unpack):
   trying to overwrite '/usr/share/java/hibernate-validator.jar', which is also 
in package libhibernate-validator-java 5.3.6-1
  dpkg-deb: error: paste subprocess was killed by signal (Broken pipe)
  Errors were encountered while processing:
   /var/cache/apt/archives/libhibernate-validator4-java_4.3.4-2_all.deb

Did you intend that the two packages are co-installable?


cheers,

Andreas


libhibernate-validator-java=5.3.6-1_libhibernate-validator4-java=4.3.4-2.log.gz
Description: application/gzip


Bug#963980: bumblebee-nvidia: Bumblebee daemon reported: error: [XORG] (EE) Unable to locate/open config directory

2020-06-29 Thread Vincas Dargis
Package: bumblebee-nvidia
Version: 3.2.1-23
Severity: important

Dear Maintainer,

After some updates I cannot use primusrun/optirun/pvkrun on my Sid:

```
$ primusrun glxgears
primus: fatal: Bumblebee daemon reported: error: [XORG] (EE) Unable to
locate/open config directory: "/etc/bumblebee/xorg.conf.d"
```

```
$ optirun glxgears
[  444.023511] [ERROR]Cannot access secondary GPU - error: [XORG] (EE)
Unable to locate/open config directory: "/etc/bumblebee/xorg.conf.d"

[  444.023570] [ERROR]Aborting because fallback start is disabled.
```

```
$ pvkrun vkcube
primus: fatal: Bumblebee daemon reported: error: [XORG] (EE) Unable to
locate/open config directory: "/etc/bumblebee/xorg.conf.d"

```

journalctl shows this:

```
$ sudo journalctl -f -u bumblebeed -n0
-- Logs begin at Mon 2020-06-29 19:49:28 EEST. --
birž. 29 19:57:47 vinco bumblebeed[12788]: [  504.277010] [ERROR][XORG] (EE) 
Unable to locate/open config directory: "/etc/bumblebee/xorg.conf.d"
birž. 29 19:57:47 vinco bumblebeed[12788]: [  504.277034] [WARN][XORG] (WW) 
Warning, couldn't open module mouse
birž. 29 19:57:47 vinco bumblebeed[12788]: [  504.277039] [ERROR][XORG] (EE) 
Failed to load module "mouse" (module does not exist, 0)
birž. 29 19:57:47 vinco bumblebeed[12788]: [  504.277045] [ERROR][XORG] (EE) 
NOUVEAU(0): [drm] failed to set drm interface version.
birž. 29 19:57:47 vinco bumblebeed[12788]: [  504.277048] [ERROR][XORG] (EE) 
NOUVEAU(0): [drm] error opening the drm
birž. 29 19:57:47 vinco bumblebeed[12788]: [  504.277051] [ERROR][XORG] (EE) 
NOUVEAU(0): 910:
birž. 29 19:57:47 vinco bumblebeed[12788]: [  504.277054] [ERROR][XORG] (EE) 
Screen(s) found, but none have a usable configuration.
birž. 29 19:57:47 vinco bumblebeed[12788]: [  504.277057] [ERROR][XORG] (EE)
birž. 29 19:57:47 vinco bumblebeed[12788]: [  504.277060] [ERROR][XORG] (EE) no 
screens found(EE)
birž. 29 19:57:47 vinco bumblebeed[12788]: [  504.277062] [ERROR][XORG] (EE)
birž. 29 19:57:47 vinco bumblebeed[12788]: [  504.277068] [ERROR][XORG] (EE) 
Please also check the log file at "/var/log/Xorg.8.log" for additional 
information.
birž. 29 19:57:47 vinco bumblebeed[12788]: [  504.277073] [ERROR][XORG] (EE)
birž. 29 19:57:47 vinco bumblebeed[12788]: [  504.277077] [ERROR][XORG] (EE) 
Server terminated with error (1). Closing log file.
birž. 29 19:57:47 vinco bumblebeed[12788]: [  504.277728] [ERROR]X did not 
start properly
```


-- Package-specific info:
OpenGL and NVIDIA library files installed:
lrwxrwxrwx 1 root root 25 Jun 29 19:44 /etc/alternatives/glx -> 
/usr/lib/nvidia/bumblebee
lrwxrwxrwx 1 root root 49 Jan 29 18:26 
/etc/alternatives/glx--libEGL.so-x86_64-linux-gnu -> 
/usr/lib/mesa-diverted/x86_64-linux-gnu/libEGL.so
lrwxrwxrwx 1 root root 51 Jun 29 19:44 
/etc/alternatives/glx--libEGL.so.1-x86_64-linux-gnu -> 
/usr/lib/mesa-diverted/x86_64-linux-gnu/libEGL.so.1
lrwxrwxrwx 1 root root 48 Jan 29 18:26 
/etc/alternatives/glx--libGL.so-x86_64-linux-gnu -> 
/usr/lib/mesa-diverted/x86_64-linux-gnu/libGL.so
lrwxrwxrwx 1 root root 48 Jun 29 19:44 
/etc/alternatives/glx--libGL.so.1-i386-linux-gnu -> 
/usr/lib/mesa-diverted/i386-linux-gnu/libGL.so.1
lrwxrwxrwx 1 root root 50 Jun 29 19:44 
/etc/alternatives/glx--libGL.so.1-x86_64-linux-gnu -> 
/usr/lib/mesa-diverted/x86_64-linux-gnu/libGL.so.1
lrwxrwxrwx 1 root root 55 Jan 29 18:26 
/etc/alternatives/glx--libGLESv1_CM.so-x86_64-linux-gnu -> 
/usr/lib/mesa-diverted/x86_64-linux-gnu/libGLESv1_CM.so
lrwxrwxrwx 1 root root 55 Jun 29 19:44 
/etc/alternatives/glx--libGLESv1_CM.so.1-i386-linux-gnu -> 
/usr/lib/mesa-diverted/i386-linux-gnu/libGLESv1_CM.so.1
lrwxrwxrwx 1 root root 57 Jun 29 19:44 
/etc/alternatives/glx--libGLESv1_CM.so.1-x86_64-linux-gnu -> 
/usr/lib/mesa-diverted/x86_64-linux-gnu/libGLESv1_CM.so.1
lrwxrwxrwx 1 root root 52 Jan 29 18:26 
/etc/alternatives/glx--libGLESv2.so-x86_64-linux-gnu -> 
/usr/lib/mesa-diverted/x86_64-linux-gnu/libGLESv2.so
lrwxrwxrwx 1 root root 52 Jun 29 19:44 
/etc/alternatives/glx--libGLESv2.so.2-i386-linux-gnu -> 
/usr/lib/mesa-diverted/i386-linux-gnu/libGLESv2.so.2
lrwxrwxrwx 1 root root 54 Jun 29 19:44 
/etc/alternatives/glx--libGLESv2.so.2-x86_64-linux-gnu -> 
/usr/lib/mesa-diverted/x86_64-linux-gnu/libGLESv2.so.2
lrwxrwxrwx 1 root root 40 Jun 29 19:44 
/etc/alternatives/glx--libGLX_indirect.so.0-i386-linux-gnu -> 
/usr/lib/i386-linux-gnu/libGLX_mesa.so.0
lrwxrwxrwx 1 root root 42 Jun 29 19:44 
/etc/alternatives/glx--libGLX_indirect.so.0-x86_64-linux-gnu -> 
/usr/lib/x86_64-linux-gnu/libGLX_mesa.so.0
lrwxrwxrwx 1 root root 25 Jun 29 19:44 /etc/alternatives/nvidia -> 
/usr/lib/nvidia/tesla-418
lrwxrwxrwx 1 root root 53 Jun 29 19:44 
/etc/alternatives/nvidia--libGL.so.1-x86_64-linux-gnu -> 
/usr/lib/x86_64-linux-gnu/nvidia/tesla-418/libGL.so.1

/etc/modprobe.d:
total 52
drwxr-xr-x   2 root root  4096 Jun 29 19:54 .
drwxr-xr-x 169 root root 12288 Jun 29 19:54 ..
-rw-r--r--   1 root root   113 Feb 23 12:19 alsa-base.conf
-rw-r--r--   1 root root   154 Dec 15  2018 

Bug#949055: autofs: FTBFS with libxml2 2.9.10 (uses xml2-config)

2020-06-29 Thread Andreas Hasenack
Sorry about that, I totally forgot. I would be very grateful if you could
address the follow-up concerns.

On Mon, Jun 29, 2020 at 10:27 AM Hugh McMaster 
wrote:

> Hallo Andreas,
>
> Did you ever have time to follow up with upstream about your patch?
>
> I saw they had some feedback that needs to be addressed before the
> patch can be merged.
>
> It looks very straightforward to fix. If will not have time, I am
> happy to take care of this and resubmit the final patch under your
> name.
>
> Hugh
>
>


Bug#962474: CMAKE_SKIP_RPATH=ON improves reproducibility of CMake builds

2020-06-29 Thread Vagrant Cascadian
On 2020-06-29, Vagrant Cascadian wrote:
> On 2020-06-29, Vagrant Cascadian wrote:
>> On 2020-06-29, Timo Röhling wrote:
> By default, CMake adds an RPATH entry to ELF binaries and deletes it
> again at install time. However, due to the limitations of some
> platforms, CMake will actually zero out the RPATH entry in the binary,
> leaking the original path length and thus making the build not
> reproducible (see the attached diffoscope output for an example).
>
> CMAKE_SKIP_RPATH disables the RPATH machinery and fixes the issue, and
> since most package won't ever ship with an RPATH entry anyway, I propose
> adding -DCMAKE_SKIP_RPATH=ON to the default build options.
 Thanks for the suggestion.
>>
>> Thanks for identifying the issue!
>>
>>
 Has this proposal been tested on an archive-wide rebuild test to see how
 much breaks with this option set?
>>> I don't know, but I don't think so. I'm not directly involved with the
>>> Reproducible Builds Team, I just pinged them on IRC after I filed this
>>> bug. Cc'ing them now.
>>
>> There is currently only one package tagged with:
>>
>>   
>> https://tests.reproducible-builds.org/debian/issues/unstable/cmake_rpath_contains_build_path_issue.html
>
> Also worth mentioning the upstream issue:
>
>   https://gitlab.kitware.com/cmake/cmake/-/issues/18413

And BUILD_RPATH_USE_ORIGIN:

  
https://gitlab.kitware.com/cmake/cmake/-/blob/master/Help/prop_tgt/BUILD_RPATH_USE_ORIGIN.rst


live well,
  vagrant


signature.asc
Description: PGP signature


Bug#963978: isc-dhcp-server: Wrong OUI URL in dhcp-lease-list

2020-06-29 Thread Tom Lloyd
Package: isc-dhcp-server
Version: 4.3.5-3+deb9u1

When you run dhcp-lease-list without an OUI file installed, it complains
and provides a web link to download one.  This web link is out of date and
results in a 404 error.  Correction follows:

/usr/sbin/dhcp-lease-list
Line 33
-my $OUI_URL = 'http://standards.ieee.org/regauth/oui/oui.txt';
+my $OUI_URL = 'http://standards-oui.ieee.org/oui/oui.txt';


Bug#881719: libcdio 2.1.0 and lubcdio++

2020-06-29 Thread Vasyl Gello
Dear colleagues,

The MR I amended after Gabriel's review is stuck since June 2nd.

Gabriel, can you please revise the MR and upload the fixed package to the queue?
-- 
Vasyl Gello
==
Certified SolidWorks Expert

Mob.:+380 (98) 465 66 77

E-Mail: vasek.ge...@gmail.com

Skype: vasek.gello
==
호랑이는 죽어서 가죽을 남기고 사람은 죽어서 이름을 남긴다

June 2, 2020 7:09:03 PM UTC, Vasyl Gello  написав(-ла):
>Hi Gabriel, Balint!
>
>Please check merge request to debian/cdio. Reprotest still fails at a first 
>glance, but lintian warnings have gone.
>I will try fixing it but I need to install reprotest hook inside my pbuilder.
>
>If you manage to fix reprotest, please let me know.
>-- 
>Vasyl Gello
>==
>Certified SolidWorks Expert
>
>Mob.:+380 (98) 465 66 77
>
>E-Mail: vasek.ge...@gmail.com
>
>Skype: vasek.gello
>==
>호랑이는 죽어서 가죽을 남기고 사람은 죽어서 이름을 남긴다

signature.asc
Description: PGP signature


Bug#963953: cpanminus depends on 'make' to work - but installing cpanminus does not install 'make'.

2020-06-29 Thread gregor herrmann
Control: tag -1 + confirmed

On Mon, 29 Jun 2020 17:28:40 +1000, Jeff wrote:

> Package: cpanminus
> Version: 1.7044-1
> Severity: normal
> 
> Dear Maintainer,
> 
>* apt-get install -y cpanminus; cpanminus --sudo File::chown
>* --> cpanminus fails to install module, and warns that I probably need to 
> install make
>* apt-get install -y make
>* cpanminus --sudo File::chown -> works as expected

Good catch, thank you.

I wonder
- whether make is enough, as gcc etc. is needed as well for XS
  modules, so maybe we should use build-essential?
- whethere we want this in Depends or in Recommends


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: The Doors: I Looked At You


signature.asc
Description: Digital Signature


Bug#962474: CMAKE_SKIP_RPATH=ON improves reproducibility of CMake builds

2020-06-29 Thread Vagrant Cascadian
On 2020-06-29, Vagrant Cascadian wrote:
> On 2020-06-29, Timo Röhling wrote:
 By default, CMake adds an RPATH entry to ELF binaries and deletes it
 again at install time. However, due to the limitations of some
 platforms, CMake will actually zero out the RPATH entry in the binary,
 leaking the original path length and thus making the build not
 reproducible (see the attached diffoscope output for an example).

 CMAKE_SKIP_RPATH disables the RPATH machinery and fixes the issue, and
 since most package won't ever ship with an RPATH entry anyway, I propose
 adding -DCMAKE_SKIP_RPATH=ON to the default build options.
>>> Thanks for the suggestion.
>
> Thanks for identifying the issue!
>
>
>>> Has this proposal been tested on an archive-wide rebuild test to see how
>>> much breaks with this option set?
>> I don't know, but I don't think so. I'm not directly involved with the
>> Reproducible Builds Team, I just pinged them on IRC after I filed this
>> bug. Cc'ing them now.
>
> There is currently only one package tagged with:
>
>   
> https://tests.reproducible-builds.org/debian/issues/unstable/cmake_rpath_contains_build_path_issue.html

Also worth mentioning the upstream issue:

  https://gitlab.kitware.com/cmake/cmake/-/issues/18413

live well,
  vagrant


signature.asc
Description: PGP signature


Bug#962474: CMAKE_SKIP_RPATH=ON improves reproducibility of CMake builds

2020-06-29 Thread Vagrant Cascadian
On 2020-06-29, Timo Röhling wrote:
>>> By default, CMake adds an RPATH entry to ELF binaries and deletes it
>>> again at install time. However, due to the limitations of some
>>> platforms, CMake will actually zero out the RPATH entry in the binary,
>>> leaking the original path length and thus making the build not
>>> reproducible (see the attached diffoscope output for an example).
>>>
>>> CMAKE_SKIP_RPATH disables the RPATH machinery and fixes the issue, and
>>> since most package won't ever ship with an RPATH entry anyway, I propose
>>> adding -DCMAKE_SKIP_RPATH=ON to the default build options.
>> Thanks for the suggestion.

Thanks for identifying the issue!


>> Has this proposal been tested on an archive-wide rebuild test to see how
>> much breaks with this option set?
> I don't know, but I don't think so. I'm not directly involved with the
> Reproducible Builds Team, I just pinged them on IRC after I filed this
> bug. Cc'ing them now.

There is currently only one package tagged with:

  
https://tests.reproducible-builds.org/debian/issues/unstable/cmake_rpath_contains_build_path_issue.html

The tagging is not automated, so most likely there are more issues that
people have not yet been identified... any good search terms for
sources.debian.org that might produce a list to compare?


The tests.reproducible-builds.org infrastructure has been building
without any custom toolchains for quite a while now, but we did at one
point have the ability to build with custom packages. It is best to be
avoided, however, as then we have to constantly keep pace with whatever
tools we're patching...


It would be nice if this could be added to debhelper but disabled by
default unless a flag was set in DEB_BUILD_OPTIONS (or something
similar) so that we could enable it from the build environment in
reproducible builds test infrastructure without affecting the official
archive.


live well,
  vagrant


signature.asc
Description: PGP signature


Bug#963977: linux-image-4.19.0-9-marvell: boot_id never changes on reboot

2020-06-29 Thread Pekka Paalanen
Package: src:linux
Version: 4.19.118-2
Severity: normal

Dear Maintainer,

I have a Qnap TS-112 with Debian installed on it. I very rarely need to
reboot it, but when I do, the systemd journal looks more messed up every
time. I think entries from different boots are being interleaved, and
'journalctl --list-boots' does not show all boots. I have observed that
_BOOT_ID recorded in the messages does not seem to change. From that, I
assume that the kernel boot_id does not change as it should either.

This machine does not have a battery-backed RTC.

I'm not quite sure if this problem has always existed or is it a
regression. I have seen journal message ordering problems before, but I
thought those were directly caused by the lack of RTC plus me using
ntpd which does not initialize early enough in boot. I've switched to
systemd's own NTP time keeping since then quite a while ago.

I purposefully rebooted the machine with 'shutdown -r now', and after it
restarted, there was no new boot entry in --list-boots. I do use
persistent storage for the journal, and I do see all the messages from
earlier boots as well as some messages from "right now".


-- Package-specific info:
** Version:
Linux version 4.19.0-9-marvell (debian-ker...@lists.debian.org) (gcc version 
8.3.0 (Debian 8.3.0-6)) #1 Debian 4.19.118-2 (2020-04-29)

** Command line:
console=ttyS0,115200 root=/dev/ram initrd=0xa0,0x90 ramdisk=34816

** Not tainted

** Kernel log:
[1.327639] Loaded X.509 cert 'Debian Secure Boot Signer: 00a7468def'
[1.334222] AppArmor: AppArmor sha1 policy hashing enabled
[1.341049] hctosys: unable to open rtc device (rtc0)
[1.348805] Freeing unused kernel memory: 316K
[1.353291] This architecture does not have kernel memory protection.
[1.359772] Run /init as init process
[1.800780] rtc-s35390a 0-0030: rtc core: registered rtc-s35390a as rtc0
[1.879332] SCSI subsystem initialized
[1.939565] libata version 3.00 loaded.
[1.941963] sata_mv f108.sata: version 1.28
[1.942218] sata_mv f108.sata: slots 32 ports 2
[1.956601] scsi host0: sata_mv
[1.962267] scsi host1: sata_mv
[1.966421] ata1: SATA max UDMA/133 irq 35
[1.970565] ata2: SATA max UDMA/133 irq 35
[2.447840] ata1: SATA link up 3.0 Gbps (SStatus 123 SControl F300)
[2.458677] ata1.00: ATA-8: WDC WD2500AAJS-00L7A0, 01.03E01, max UDMA/133
[2.465522] ata1.00: 488397168 sectors, multi 0: LBA48 NCQ (depth 31/32)
[2.476909] ata1.00: configured for UDMA/133
[2.481535] scsi 0:0:0:0: Direct-Access ATA  WDC WD2500AAJS-0 3E01 
PQ: 0 ANSI: 5
[2.806149] ata2: SATA link down (SStatus 0 SControl F300)
[2.837515] sd 0:0:0:0: [sda] 488397168 512-byte logical blocks: (250 GB/233 
GiB)
[2.849404] sd 0:0:0:0: [sda] Write Protect is off
[2.854258] sd 0:0:0:0: [sda] Mode Sense: 00 3a 00 00
[2.854349] sd 0:0:0:0: [sda] Write cache: enabled, read cache: enabled, 
doesn't support DPO or FUA
[2.902094]  sda: sda1 sda2 sda3 < sda5 sda6 >
[2.910970] sd 0:0:0:0: [sda] Attached SCSI disk
[3.769581] EXT4-fs (sda2): mounted filesystem with ordered data mode. Opts: 
(null)
[5.003150] systemd[1]: System time before build time, advancing clock.
[5.191939] systemd[1]: Inserted module 'autofs4'
[5.277439] NET: Registered protocol family 10
[5.449316] Segment Routing with IPv6
[5.453864] random: crng init done
[5.552715] systemd[1]: systemd 241 running in system mode. (+PAM +AUDIT 
+SELINUX +IMA +APPARMOR +SMACK +SYSVINIT +UTMP +LIBCRYPTSETUP +GCRYPT +GNUTLS 
+ACL +XZ +LZ4 +SECCOMP +BLKID +ELFUTILS +KMOD -IDN2 +IDN -PCRE2 
default-hierarchy=hybrid)
[5.574721] systemd[1]: Detected architecture arm.
[5.642395] systemd[1]: Set hostname to .
[7.195905] systemd[1]: File /lib/systemd/system/systemd-journald.service:12 
configures an IP firewall (IPAddressDeny=any), but the local system does not 
support BPF/cgroup based firewalling.
[7.213074] systemd[1]: Proceeding WITHOUT firewalling in effect! (This 
warning is only shown for the first loaded unit using IP firewalling.)
[7.979648] systemd[1]: /lib/systemd/system/dovecot.service:9: PIDFile= 
references path below legacy directory /var/run/, updating 
/var/run/dovecot/master.pid \xe2\x86\x92 /run/dovecot/master.pid; please update 
the unit file accordingly.
[8.081041] systemd[1]: Listening on fsck to fsckd communication Socket.
[8.104877] systemd[1]: Listening on Journal Socket.
[8.126584] systemd[1]: Created slice User and Session Slice.
[8.148034] systemd[1]: Reached target Slices.
[8.789595] input: gpio_keys as /devices/platform/gpio_keys/input/input0
[8.864058] EXT4-fs (sda2): re-mounted. Opts: errors=remount-ro
[9.660619] systemd-journald[141]: Received request to flush runtime journal 
from PID 1
[9.697129] systemd-journald[141]: File 
/var/log/journal/0c4d9c82740545bfaeedcc433021e0d3/system.journal corrupted or 
uncleanly shut down, renaming and 

Bug#963961: [Pkg-kde-extras] Bug#963961: Please backport exiv2

2020-06-29 Thread Pino Toscano
Ciao Enrico,

In data lunedì 29 giugno 2020 12:05:13 CEST, Enrico Zini ha scritto:
> Package: exiv2
> Version: 0.27.2-8
> Severity: wishlist
> 
> Hello,
> 
> thank you for maintaining exiv2.
> 
> exiv2 in testing adds support for the webp image format, not supported
> in stable.
> 
> I tried building exiv2 with the build-deps from stable, and it builds
> and works, with the attached .symbols patch.
> 
> Could you please backport exiv2?

There are two problems in this case, one smaller and two bigger.

The smaller problem is that we don't have the bandwidth needed to
maintain packages in -backports, so it would require somebody else to
step it and maintain the -backports branch.

The bigger problem #1 is that exiv2 breaks ABI (and SONAME) for each
stable series; you can easily see the package in unstable is
libexiv2-27 for version 0.27.x, and the same applies to older versions.
So even a plain backport won't be used automatically, as packages are
linked to the SONAME of the libexiv2 in stable.

The bigger problem #2 is that the API of libexiv2 is not that stable
and usually changes, requiring fixes and adaptations in packages.
Based on what I remember wrt the exiv2 update to 0.27, my wild guess
is at least 1/3, if not even 1/2 or more, of the packages in stable
that use exiv2 are not compatible with the newer exiv2.

So sorry to bring the bad news: IMHO this is not doable, and it would
require a lot of work.

-- 
Pino Toscano

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


Bug#963933: glib2.0: autopkgtext: ld: cannot find -lcryptsetup

2020-06-29 Thread Simon McVittie
Control: reassign -1 src:glib2.0,src:util-linux
Control: found -1 glib2.0/2.64.3-1
Control: found -1 util-linux/2.35.2-5
Control: tags -1 + moreinfo bullseye sid

On Mon, 29 Jun 2020 at 00:16:49 +0100, Simon McVittie wrote:
> On Sun, 28 Jun 2020 at 22:00:58 +0200, Chris Hofstaedtler wrote:
> > I imagine this might be caused by libcryptsetup-dev not shipping an
> > .a library.
> 
> This means that GLib could previously be successfully statically linked
> (and we had a test to prove it), and now it cannot.
> 
> Do you consider this to be a deliberate change? Is statically linking
> a library that depends on libmount no longer supported?

This is either a regression in libmount (could be statically linked, now
can't) or a wrong assumption in GLib (assumed that statically linking was
supported, but (now?) it isn't). Which one?

Thanks,
smcv



Bug#963721: libcryptsetup12 v2:2.3.3-1 seems to be breaking libssl somehow

2020-06-29 Thread Chris Hofstaedtler
* Simon McVittie  [200629 17:39]:
> On Mon, 29 Jun 2020 at 15:33:48 +0100, Simon McVittie wrote:
> > On Sun, 28 Jun 2020 at 15:45:41 +0200, Chris Hofstaedtler wrote:
> > > We seem to have multiple problems here:
> > > 
> > > 1) Software that is not shipped by Debian and uses a statically
> > > linked or private copy of libssl crashes, because libmount1 pulls 
> > > in libssl1.1, transitively.
> > ...
> > > 2) Some part of libmount1 or libcryptsetup1 introduces a memory
> > > corruption, which is "found" by libjansson users.
> > 
> > Also json-glib users, probably (all of json-c, jansson and json-glib
> > collide at json_object_iter_next()).
> 
> Given the number of moving parts involved in this, and the fact that the
> verity feature is specifically described as experimental in the upstream
> release notes, would you be willing to consider reverting the enablement
> of the cryptsetup feature until there is at least a concrete plan for
> a solution?

This is my plan indeed. I'm waiting for bsdmainutils to pass through
NEW, as it has a versioned dependency on util-linux 2.35.2-7.

> This would reopen #951048, but would at least temporarily
> resolve #963721, #963525 and #963933, and would mitigate #963932. Then we
> can do a coordinated transition with everything happening in the right
> order, when we know what that order is.

#951048 is already reopened.

> Some possible angles to attack this from:
> 
> - not enabling the feature

(Snipped your long list of other options which would need to be done
upstream.)

> Thanks,
> smcv

Best,
  Chris



Bug#963721: libcryptsetup12 v2:2.3.3-1 seems to be breaking libssl somehow

2020-06-29 Thread Simon McVittie
On Mon, 29 Jun 2020 at 15:33:48 +0100, Simon McVittie wrote:
> On Sun, 28 Jun 2020 at 15:45:41 +0200, Chris Hofstaedtler wrote:
> > We seem to have multiple problems here:
> > 
> > 1) Software that is not shipped by Debian and uses a statically
> > linked or private copy of libssl crashes, because libmount1 pulls 
> > in libssl1.1, transitively.
> ...
> > 2) Some part of libmount1 or libcryptsetup1 introduces a memory
> > corruption, which is "found" by libjansson users.
> 
> Also json-glib users, probably (all of json-c, jansson and json-glib
> collide at json_object_iter_next()).

Given the number of moving parts involved in this, and the fact that the
verity feature is specifically described as experimental in the upstream
release notes, would you be willing to consider reverting the enablement
of the cryptsetup feature until there is at least a concrete plan for
a solution? This would reopen #951048, but would at least temporarily
resolve #963721, #963525 and #963933, and would mitigate #963932. Then we
can do a coordinated transition with everything happening in the right
order, when we know what that order is.

Some possible angles to attack this from:

- not enabling the feature

- enabling the feature, but via dlopen rather than linking libcryptsetup
  normally (the developer who added verity support to util-linux seemed
  to be in favour of this, although I've lost the relevant tab and can't
  find a URL right now, sorry)

- enabling the feature, but via invoking a helper subprocess

- json-c, libjansson and json-glib *all* gaining versioned symbols
  (but the maintainer of json-glib has previously rejected requests to
  add versioned symbols, and this doesn't work unless all three libraries
  do it)

- at least two of json-c, libjansson and json-glib renaming their public
  symbols (the maintainer of json-glib already rejected this, and
  the maintainers of the others are likely to be equally reluctant to
  break ABI)

- GLib moving from normal linking of libmount to dlopen with RTLD_LOCAL
  in order to mitigate this by not pulling libmount into everything in
  the GLib/GNOME/MATE/Cinnamon/XFCE/LXDE ecosystem
  (but the GLib upstream maintainers don't like this idea and think
  low-level libraries like libmount should avoid gaining significant
  dependencies, instead)

- changing how Steam links OpenSSL (we cannot do this unilaterally, only
  its upstream maintainers can; I've raised this upstream with various
  suggestions, but it would involve significant restructuring, so don't
  expect immediate results)

- changing how other proprietary binary-only software like Minecraft
  links OpenSSL (we cannot do this unilaterally, only its upstream
  maintainers can)

Thanks,
smcv



Bug#963943: mupdf-tools: mutool decompression broken due to mismatched jbig2dec versions

2020-06-29 Thread Kan-Ru Chen
Hi,

On Sun, Jun 28, 2020 at 08:39:19PM -0300, Rogério Brito wrote:
> Package: mupdf-tools
> Version: 1.16.1+ds1-2
> Severity: important
> 
> The version of mupdf in testing/unstable is partially broken (thus, only
> severity important, instead of a higher severity).
> 
> This happens because mutool produces unparseable/unreadable PDF files when
> used like the following, if the files contain jbig2 images:

Thanks for the report. Could you attach the test file so I can test locally?

Cheers,
Kanru


signature.asc
Description: PGP signature


Bug#693782: auto.master.d documentation

2020-06-29 Thread Mike Gabriel

On  So 28 Jun 2020 19:18:48 CEST, Sam Morris wrote:


On Tue, Nov 20, 2012 at 11:17:09AM +0100, Stefan Skoglund wrote:

The documentation for how to use the 'auto.master.d' feature is really
non-existing. What exists is a sketch from the designer for what it is
(or how it should be.)


/etc/auto.master now has comments that describe how to use the feature:

# Include /etc/auto.master.d/*.autofs
# To add an extra map using this mechanism you will need to add
# two configuration items - one /etc/auto.master.d/extra.autofs file
# (using the same line format as the auto.master file)
# and a separate mount map (e.g. /etc/auto.extra or an auto.extra NIS 
map)
# that is referred to by the extra.autofs file.
#
+dir:/etc/auto.master.d

For instance, I have the following:

$ cat /etc/auto.master.d/work.autofs
/workfile:/etc/auto.workbrowse

$ cat /etc/auto.work
	server1-share1-fstype=cifs,sec=krb5i,cruid=$CRUID,multiuser  
://server1.example.com/share1
	server2-share1-fstype=cifs,sec=krb5i,cruid=$CRUID,multiuser  
://server2.example.com/share1


In addition, auto.master(5) describes the + inclusion feature:

Additionally, a map may be included from its source as if it were itself
present in the master map by including a line of the form:

+[maptype[,format]:map options]

and automount(8) will process the map according to the specification
described below for map entries.

... the format of a master map entry:

mount-point [map-type[,format]:]map [options]

... and describes the 'dir' map-type:

This map type can be used at + master map including notation. The
contents of files under given directory are included to the master
map. The name of file to be included must be ended with ".autofs". A
file will be ignored if its name is not ended with the suffix. In
addition a dot file, a file which name is started with "." is also
ignored.


Thanks!
Mike
--

DAS-NETZWERKTEAM
c\o Technik- und Ökologiezentrum Eckernförde
Mike Gabriel, Marienthaler Str. 17, 24340 Eckernförde
mobile: +49 (1520) 1976 148
landline: +49 (4351) 850 8940

GnuPG Fingerprint: 9BFB AEE8 6C0A A5FF BF22  0782 9AF4 6B30 2577 1B31
mail: mike.gabr...@das-netzwerkteam.de, http://das-netzwerkteam.de



pgpAituwRnY5K.pgp
Description: Digitale PGP-Signatur


Bug#963976: RFS: xscorch/0.2.1-1+nmu2.1 [NMU, RC] -- Clone of Scorched Earth

2020-06-29 Thread Luis Paulo Linares
Package: sponsorship-requests
Severity: important

Dear mentors,

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

 * Package name: xscorch
   Version : 0.2.1-1+nmu2.1
   Upstream Author : Justin David Smith 
 * URL : http://www.xscorch.org/
 * License : GPL-2
 * Vcs : None
   Section : games

It builds those binary packages:

  xscorch - Clone of Scorched Earth

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

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

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

  dget -x 
https://mentors.debian.net/debian/pool/main/x/xscorch/xscorch_0.2.1-1+nmu2.1.dsc

Changes since the last upload:

   * Non-maintainer upload.
   * debian/control: changed from 'libmikmod2-dev' to 'libmikmod-dev'
 in Build-Depends field to avoid a FTBFS. Thanks to Adrian Bunk
 . (Closes: #963836)

Regards,

--
  Luis Paulo Linares



Bug#963295: rust-structopt: FTBFS: build-dependency not installable: librust-structopt-derive-0.4.8+default-dev

2020-06-29 Thread Daniel Kahn Gillmor
On Sun 2020-06-21 21:50:37 +0200, Lucas Nussbaum wrote:
> Source: rust-structopt
> Version: 0.3.15-1
> Severity: serious
> Justification: FTBFS on amd64
> Tags: bullseye sid ftbfs
> Usertags: ftbfs-20200620 ftbfs-bullseye
[…]
>> The following packages have unmet dependencies:
>>  sbuild-build-depends-main-dummy : Depends: 
>> librust-structopt-derive-0.4.8+default-dev but it is not installable
>> E: Unable to correct problems, you have held broken packages.
>> apt-get failed.

This is blocked waiting on rust-proc-macro-error-attr, which is
currently stuck in NEW.

Hopefully someone on the FTP team can look at
rust-proc-macro-error-attr.

--dkg


signature.asc
Description: PGP signature


Bug#963974: faillog command does not display anything since a long time

2020-06-29 Thread Martin Steigerwald
Am Montag, den 29.06.2020, 16:32 +0200 schrieb Martin Steigerwald:
> Package: libpam-modules
> Version: 1.3.1-5
> Severity: normal
[…]
> I digged on the internet I found Red Hat apparently removed it during
> RHEL 5 development already. I digged in libpam-modules Debian
> changelog and NEWS file and found nothing about 'faillog' or
> pam_tally.
>
[…]
> Not sure what the best resolution for Debian would be. Maybe just a
> note in NEWS.Debian or… something else?

I tested various distributions: Both CentOS 8.2 and SLES 15 SP 1 have no
faillog command. The Debian 10, Debian Sid and the Debian based ones
Devuan 3 aka Beowolf and Ubuntu 20.04 LTS still have it.

Removing it would break setups with manually enabled pam_tally though.

Best,

Mit freundlichen Grüßen / With kind regards
Martin Steigerwald •
Proact Deutschland GmbH
Trainer
Telefon: +49 911 30999 0 •
Fax: +49 911 30999 99
Südwestpark 43 •
90449 Nürnberg •
Germany
martin.steigerw...@proact.de •
www.proact.de
Amtsgericht Nürnberg
 •
HRB 18320
Geschäftsführer:
René Schülein
 •
Jonas Hasselberg
 •
Jonas Persson
•
Oliver Kügow
– Delivering Business Agility –


Bug#963905: bsdmainutils: conffiles not removed: /etc/default/bsdmainutils /etc/cron.daily/bsdmainutils /etc/calendar/default

2020-06-29 Thread Michael Meskes
On Mon, Jun 29, 2020 at 12:50:51AM +0800, Paul Wise wrote:
> Package: bsdmainutils
> ...
> 
> The recent upgrade did not deal with obsolete conffiles properly.
> Please use the dpkg-maintscript-helper support provided by
> dh_installdeb to remove these obsolete conffiles on upgrade.

This should be fixed with the upload stuck in NEW. 

Michael
-- 
Michael Meskes
Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org)
Meskes at (Debian|Postgresql) dot Org
Jabber: michael at xmpp dot meskes dot org
VfL Borussia! Força Barça! Go SF 49ers! Use Debian GNU/Linux, PostgreSQL


signature.asc
Description: PGP signature


Bug#963975: blender: Blender crashes on launch (failed assert)

2020-06-29 Thread Ben Morris
Package: blender
Version: 2.83.1+dfsg-1
Severity: grave
Justification: renders package unusable

Blender 2.83.1+dfsg-1 is crashing on launch with the output shown below. I have
tested this with and without an existing ~/.config/blender/ directory.

$ blender
blf_load_font_default: 'fonts' data path not found for 'droidsans.ttf', will
not be able to display text
blf_load_font_default: 'fonts' data path not found for 'bmonofont-i18n.ttf',
will not be able to display text
blf_load_font_default: 'fonts' data path not found for 'bmonofont-i18n.ttf',
will not be able to display text
blender(BLI_system_backtrace+0x33) [0x55751863b4b3]
blender(BLF_default+0x1c) [0x55751851eddc]
blender(+0x18262bb) [0x5575168382bb]
blender(ED_time_scrub_draw+0x1af) [0x5575165eab8f]
blender(+0x184943d) [0x55751685b43d]
blender(ED_region_do_draw+0x841) [0x55751656e911]
blender(wm_draw_update+0x4ba) [0x55751620f4ba]
blender(WM_main+0x30) [0x55751620d3c0]
blender(main+0x2b8) [0x557515ee36c8]
/lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xeb) [0x7f0c01ea0e0b]
blender(_start+0x2a) [0x557515f303ba]
BLI_assert failed:
/build/blender-l5zyJy/blender-2.83.1+dfsg/source/blender/blenfont/intern/blf.c:185,
BLF_default(), at 'global_font_default != -1'
Aborted

I have checked that the two fonts mentioned are present on my system. They are
in /usr/share/locale/fonts/ as part of blender-data.



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

Kernel: Linux 5.7.0-1-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_GB:en_US (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

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

blender recommends no packages.

blender suggests no packages.

-- no debconf information



Bug#963894: Chromium: Error "Aw, Snap! Something went wrong while displaying this webpage. Error code 256."

2020-06-29 Thread Vladimir K
It's ffmpeg packages. Downgrade to 7:4.2.2-1+b1 fixes it.



Bug#963699: Fwd: PostgreSQL: WolfSSL support

2020-06-29 Thread Stephen Frost
Greetings,

* Felix Lechner (felix.lech...@lease-up.com) wrote:
> Attached please find a WIP patch for wolfSSL support in postgresql-12.

Would really be best to have this off of HEAD if we're going to be
looking at it rather than v12.  We certainly aren't going to add new
support for something new into the back-branches.

Further, I'd definitely suggest seeing how this plays with the patch to
add support for NSS which was posted recently to -hackers by Daniel.

Thanks,

Stephen


signature.asc
Description: PGP signature


Bug#963525: Bug#963721: [pkg-cryptsetup-devel] Bug#963721: libcryptsetup12 v2:2.3.3-1 seems to be breaking libssl somehow

2020-06-29 Thread Simon McVittie
On Sun, 28 Jun 2020 at 15:45:41 +0200, Chris Hofstaedtler wrote:
> We seem to have multiple problems here:
> 
> 1) Software that is not shipped by Debian and uses a statically
> linked or private copy of libssl crashes, because libmount1 pulls 
> in libssl1.1, transitively.
...
> 2) Some part of libmount1 or libcryptsetup1 introduces a memory
> corruption, which is "found" by libjansson users.

Also json-glib users, probably (all of json-c, jansson and json-glib
collide at json_object_iter_next()).

See also https://github.com/karelzak/util-linux/issues/1081
and https://gitlab.gnome.org/GNOME/glib/-/issues/2147.

smcv



Bug#963974: faillog command does not display anything since a long time

2020-06-29 Thread Martin Steigerwald
Package: libpam-modules
Version: 1.3.1-5
Severity: normal

Dear maintainers,

quite some time, quite some Debian releases ago, I found during a Linux
training I held that faillog would not display anything anymore, while
lastlog still does.

Finally I took time to research this a bit. I learned quickly that
pam_tally is required for it to work. However it is not enabled by
default in Debian, `grep tally /etc/pam.d/*' does not return any results.

I digged on the internet I found Red Hat apparently removed it during
RHEL 5 development already. I digged in libpam-modules Debian changelog
and NEWS file and found nothing about 'faillog' or pam_tally.

However in the manpage 'pam_tally(8)' I found:

   pam_tally has several limitations, which are solved with
   pam_tally2. For this reason pam_tally is deprecated and will be
   removed in a future release.

'pam_tally2' is included in Debian, yet also not enabled. And its file
format is not compatible with 'faillog', as manpage 'pam_tally2(8)' states:

   pam_tally2 is not compatible with the old pam_tally faillog
   file format. This is caused by requirement of compatibility of
   the tallylog file format between 32bit and 64bit architectures
   on multiarch systems.

So by default the Debian system contains a command that does not work out
of the box. And experienced user can dig up how to enable pam_tally, yet
this situation is still somehow inconsistent.

pam_tally2 has a command 'pam_tally2', but pam_tally2 by default is also
not enabled.

However there is 'lastb' command which displays the last failed login
attempt for each user. I am going to use that for the training for now
and mention that faillog is dysfunctional unless pam_tally is enabled,
which is deprecated.

Not sure what the best resolution for Debian would be. Maybe just a note
in NEWS.Debian or… something else?

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

Kernel: Linux 5.8.0-rc2-tp520 (SMP w/4 CPU cores; PREEMPT)
Kernel taint flags: TAINT_OOT_MODULE
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), LANGUAGE= 
(charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: runit (via /run/runit.stopit)
LSM: AppArmor: enabled

Versions of packages libpam-modules depends on:
ii  debconf [debconf-2.0]  1.5.74
ii  libaudit1  1:2.8.5-3+b1
ii  libc6  2.30-8
ii  libdb5.3   5.3.28+dfsg1-0.6
ii  libpam-modules-bin 1.3.1-5
ii  libpam0g   1.3.1-5
ii  libselinux13.0-1+b3

libpam-modules recommends no packages.

libpam-modules suggests no packages.

-- debconf-show failed


Bug#963948: [Pkg-utopia-maintainers] Bug#963948: failed to start with status=11/SEGV

2020-06-29 Thread Ernesto Domato
El lun., 29 de jun. de 2020 a la(s) 05:56, Michael Biebl
(bi...@debian.org) escribió:
> This is a known issue, caused by the latest libmount1 update, which
> pulls libjson-c into firewalld's address space. firewalld, via
> libnftables, also uses libjansson, another JSON library. And as it turns
> out, those two libraries have a symbol clash.
> See https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=963932

Perfect, I didn't know of that bug really :-)

> You have a couple of options to mitigate this issue for now:
> a/ downgrade firewalld (to a version where iptables was still the
> default backend)
> b/ downgrade libmount1 to 2.35.2-4 from testing and put that package on hold
> c/ edit /etc/firewalld/firewalld.conf and set FirewallBackend=iptables
>
> I do not really recommend c/, as you might forgot to undo that change,
> once the symbol clash has been fixed.

I opted for "C" since I also was hit by the bug in Steam client
mentioned in the bug report you mention and is fixed by downgrading
libmount1 :-)

Thanks for everything.



Bug#963962: Update: /etc/grub.d/20_linux_xen

2020-06-29 Thread Sergio Gelato
Some minor additions:

1. It turns out #924360 is no longer a concern. Not that I can see, anyway.
2. This is what I get when trying to boot from the .efi entry:

--
Loading Xen 4.11-amd64.efi ...Loading Xen 4.11-amd64.efi ...

error: invalid arch-dependent ELF magic.
error: invalid arch-dependent ELF magic.
Loading Linux 4.19.0-9-amd64 ...Loading Linux 4.19.0-9-amd64 ...

error: you need to load the kernel first.
error: you need to load the kernel first.
Loading initial ramdisk ...Loading initial ramdisk ...

error: you need to load the kernel first.
error: you need to load the kernel first.


Press any key to continue...Press any key to continue...
--

So at this time I don't see a point in generating those .efi menu entries.



Bug#963887: UDD: 'duck' importer broken since 2020-05-25

2020-06-29 Thread Raphael Hertzog
Hi,

On Sun, 28 Jun 2020, Bastian Blank wrote:
> > Baptiste (CCed) volunteered to write it over again, but for now there is
> > no clear timeline as for when the new project will be started.
> 
> Maybe you could add that to vcswatch?

or distro-tracker?

Indeed, creating a dedicated service for this does not seem a good idea.

https://qa.pages.debian.net/distro-tracker/contributing.html
https://qa.pages.debian.net/distro-tracker/devel/design.html#tasks-framework

Cheers,
-- 
  ⢀⣴⠾⠻⢶⣦⠀   Raphaël Hertzog 
  ⣾⠁⢠⠒⠀⣿⡁
  ⢿⡄⠘⠷⠚⠋The Debian Handbook: https://debian-handbook.info/get/
  ⠈⠳⣄   Debian Long Term Support: https://deb.li/LTS



  1   2   >