Bug#961902: biomaj3-core: autopkgtest failure: No module named 'biomaj3_core'

2020-05-30 Thread Paul Gevers
Source: biomaj3-core
Version: 3.0.19-1
X-Debbugs-CC: debian...@lists.debian.org
Severity: serious
User: debian...@lists.debian.org
Usertags: fails-always

Dear maintainer(s),

Your package has an autopkgtest, great. However, it fails. I copied some
of the output at the bottom of this report. Can you please investigate
the situation and fix it? You're using autodep8 to trigger the test, but
it seems your package naming and Python module name aren't aligned for
autodep8. autodep8 recently acquired a new feature that enables you to
tell autode8 what the real module name is that should be tested [1].

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

Paul

[1]
https://manpages.debian.org/unstable/autodep8/autodep8.1.en.html#PYTHON_PACKAGES
[2] https://lists.debian.org/debian-devel-announce/2019/07/msg2.html

https://ci.debian.net/data/autopkgtest/testing/amd64/b/biomaj3-core/5702067/log.gz

autopkgtest [00:25:15]: test autodep8-python3: set -e ; for py in
$(py3versions -r 2>/dev/null) ; do cd "$AUTOPKGTEST_TMP" ; echo "Testing
with $py:" ; $py -c "import biomaj3_core; print(biomaj3_core)" ; done
autopkgtest [00:25:15]: test autodep8-python3: [---
Testing with python3.8:
Traceback (most recent call last):
  File "", line 1, in 
ModuleNotFoundError: No module named 'biomaj3_core'



signature.asc
Description: OpenPGP digital signature


Bug#961382: hyphy: baseline violation on amd64/i386

2020-05-30 Thread Andreas Tille
Hi Michael,

On Sat, May 23, 2020 at 11:10:37PM +0300, Adrian Bunk wrote:
> Source: hyphy
> Version: 2.2.7+dfsg-1
> Severity: serious
> 
> https://buildd.debian.org/status/package.php?p=hyphy
> 
> That package in stretch and buster builds with -msse3
> for no apparent reason.
> 
> The package in unstable/testing is built with
> "-march=native -mtune=native -mavx  -mfma".

do you think this package could be a target for simde in the near future
or should we rather remove those options for the moment.

Kind regards

   Andreas.

-- 
http://fam-tille.de



Bug#961901: djangorestframework-gis: autopkgtest failure: No module named 'djangorestframework_gis'

2020-05-30 Thread Paul Gevers
Source: djangorestframework-gis
Version: 0.14-3
X-Debbugs-CC: debian...@lists.debian.org
Severity: serious
User: debian...@lists.debian.org
Usertags: fails-always

Dear maintainer(s),

Your package has an autopkgtest, great. However, it fails. I copied some
of the output at the bottom of this report. Can you please investigate
the situation and fix it? You're using autodep8 to trigger the test, but
it seems your package naming and Python module name aren't aligned for
autodep8. autodep8 recently acquired a new feature that enables you to
tell autode8 what the real module name is that should be tested [1].

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

Paul

[1]
https://manpages.debian.org/unstable/autodep8/autodep8.1.en.html#PYTHON_PACKAGES
[2] https://lists.debian.org/debian-devel-announce/2019/07/msg2.html

https://ci.debian.net/data/autopkgtest/testing/amd64/d/djangorestframework-gis/5701408/log.gz

autopkgtest [22:59:33]: test autodep8-python3: set -e ; for py in
$(py3versions -r 2>/dev/null) ; do cd "$AUTOPKGTEST_TMP" ; echo "Testing
with $py:" ; $py -c "import djangorestframework_gis;
print(djangorestframework_gis)" ; done
autopkgtest [22:59:33]: test autodep8-python3: [---
Testing with python3.8:
Traceback (most recent call last):
  File "", line 1, in 
ModuleNotFoundError: No module named 'djangorestframework_gis'
autopkgtest [22:59:33]: test autodep8-python3: ---]



signature.asc
Description: OpenPGP digital signature


Bug#961900: lua-mediator: autopkgtest failure: No rule to make target 'test-lua-dynamic-apkgt-fake'

2020-05-30 Thread Paul Gevers
Source: lua-mediator
Version: 1.1.2-0-2
X-Debbugs-CC: debian...@lists.debian.org
Severity: serious
User: debian...@lists.debian.org
Usertags: fails-always

Dear maintainer(s),

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

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

Paul

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

https://ci.debian.net/data/autopkgtest/testing/amd64/l/lua-mediator/5700931/log.gz

autopkgtest [22:26:42]: test dh-lua-tests: [---
dh autopkgtest --buildsystem=lua --with lua
dh: warning: Compatibility levels before 10 are deprecated (level 9 in use)
   dh_auto_test -O--buildsystem=lua
dh_auto_test: warning: Compatibility levels before 10 are deprecated
(level 9 in use)
make --no-print-directory -f
/usr/share/dh-lua/make/dh-lua.Makefile.multiple autopkgtest

Making target autopkgtest for debian/lua5.1.dh-lua.conf
make[2]: *** No rule to make target 'test-lua-dynamic-apkgt-fake',
needed by 'autopkgtest'.  Stop.
make[1]: *** [/usr/share/dh-lua/make/dh-lua.Makefile.multiple:12:
autopkgtest] Error 1
dh_auto_test: error: make --no-print-directory -f
/usr/share/dh-lua/make/dh-lua.Makefile.multiple autopkgtest returned
exit code 2
make: *** [debian/rules:4: autopkgtest] Error 25
autopkgtest [22:26:43]: test dh-lua-tests: ---]



signature.asc
Description: OpenPGP digital signature


Bug#961686: lintian: false positive: runtime-test-file-uses-supported-python-versions-without-python-all-build-depends

2020-05-30 Thread Scott Kitterman
On Wednesday, May 27, 2020 6:11:51 PM EDT you wrote:
> Package: lintian
> Severity: normal
> 
> From lintian.debian.org, so I don't know the lintian version:
> 
> https://lintian.debian.org/sources/dkimpy/1.0.4-1.html
> 
> among other things it says:
> 
>  W
> runtime-test-file-uses-supported-python-versions-without-python-all-build-d
> epends debian/tests/py3 py3versions -sv (line 5)
> 
> There is py3versions -sv is debian/tests/py3, so that part of the check
> is correct, but the build-depends detection is not.  Here's
> debian/tests/control for dkimpy 1.0.4-1:
> 
> Tests: py3
> Depends: python3-all,
>  python3-authres,
>  python3-dnspython,
>  python3-nacl,
>  python3-pkg-resources,
>  @
> Restrictions: allow-stderr
> 
> So the check is wrong.

Same issue affects xml2rfc checks when run locally on Unstable:

W: xml2rfc source: runtime-test-file-uses-supported-python-versions-without-
python-all-build-depends debian/tests/run-pytest py3versions -s (line 14)

Here's debian/tests/control:

Tests: run-pytest
Depends: @, python3-all, fonts-noto-cjk, fonts-noto-core, fonts-noto-unhinted, 
python3-cairo, python3-dict2xml, python3-pypdf2, weasyprint
Restrictions: allow-stderr

Scott K

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


Bug#959561: guile-ssh: FTBFS: dh_auto_test: error: make -j1 check VERBOSE=1 returned exit code 2

2020-05-30 Thread Vagrant Cascadian
Control: severity 959561 important

On 2020-05-22, Vagrant Cascadian wrote:
> On 2020-05-03, Lucas Nussbaum wrote:
>> During a rebuild of all packages in sid, your package failed to build
>> on amd64.
>>
>> Relevant part (hopefully):
>>> make[5]: Entering directory '/<>/tests'
> ...
>>> FAIL: dist.scm
>>> 
>>>Guile-SSH 0.11.3: tests/test-suite.log
>>> 
>>> 
>>> # TOTAL: 11
>>> # PASS:  10
>>> # SKIP:  0
>>> # XFAIL: 0
>>> # FAIL:  1
>>> # XPASS: 0
>>> # ERROR: 0
>>> 
>>> .. contents:: :depth: 2
>>> 
>>> FAIL: dist
>>> ==
>>> 
>>>  Starting test dist  (Writing full log to "dist.log")
>>> 
>>> Some deprecated features have been used.  Set the environment
>>> variable GUILE_WARN_DEPRECATED to "detailed" and rerun the
>>> program to get more information.  Set it to "no" to suppress
>>> this message.
>>>  Starting test dist  (Writing full log to "dist.log")
>>> tests/dist.scm:216: FAIL with-ssh
>>> # of expected passes  18
>>> # of unexpected failures  1
> ...
>>> Test begin:
>>>   test-name: "with-ssh"
>>>   source-file: "tests/dist.scm"
>>>   source-line: 216
>>>   source-form: (test-assert "with-ssh" (begin (set-log-userdata! 
>>> "with-ssh") (run-client-test (lambda (server) (server-listen server) 
>>> (server-set! server (quote log-verbosity) (quote functions)) (let ((session 
>>> (server-accept server))) (server-handle-key-exchange session) 
>>> (start-session-loop session (lambda (msg type) (format-log/scm (quote 
>>> nolog) "server" "msg: ~a; type: ~a" msg type) (case (car type) 
>>> ((request-channel-open) (let ((c (message-channel-request-open-reply-accept 
>>> msg))) (format-log/scm (quote nolog) "server" "channel 0: ~a" c) 
>>> (write-line "Enter `,help' for help." c) (format-log/scm (quote nolog) 
>>> "server" "channel 1: ~a" c) (usleep 100) (poll c (lambda args (let ((result 
>>> (read-line c))) (format-log/scm (quote nolog) "server" "sexp: ~a" result) 
>>> (or (string=? result "(begin (+ 21 21))") (error "Wrong result 1" result))) 
>>> (let ((result (read-line c))) (format-log/scm (quote nolog) "server" "sexp: 
>>> ~a" result) (or (string=? result "(newline)") (error "Wrong result 2" 
>>> result))) (write-line "scheme@(guile-user)> $1 = 42\n" c) (sleep 5) (close 
>>> c) (while #t (sleep 60)) (else (message-reply-success msg))) 
>>> (lambda () (call-with-connected-session (lambda (session) 
>>> (authenticate-server session) (format-log/scm (quote nolog) "client" 
>>> "session: ~a" session) (unless (equal? (userauth-none! session) (quote 
>>> success)) (error "Could not authenticate with a server" session)) (let ((n 
>>> (make-node session #:start-repl-server? #f))) (= (with-ssh n (+ 21 21)) 
>>> 42
>>> result) (or (string=? result "(newline)") (error "Wrong result 2" result))) 
>>> (write-line "scheme@(guile-user)> $1 = 42\n" c) (sleep 5) (close c) (while 
>>> #t (sleep 60)) (else (message-reply-success msg))) (lambda () 
>>> (call-with-connected-session (lambda (session) (authenticate-server 
>>> session) (format-log/scm (quote nolog) "client" "session: ~a" session) 
>>> (unless (equal? (userauth-none! session) (quote success)) (error "Could not 
>>> authenticate with a server" session)) (let ((n (make-node session 
>>> #:start-repl-server? #f))) (= (with-ssh n (+ 21 21)) 42
>>> Test end:
>>>   result-kind: fail
>>>   actual-value: #f
>>>   actual-error: (guile-ssh-error "read_from_channel_port" "Error reading 
>>> from the channel" # #f)
>>> Group end: dist
>>> # of expected passes  18
>>> # of unexpected failures  1
>>> FAIL dist.scm (exit status: 1)
> ...
>> The full build log is available from:
>>http://qa-logs.debian.net/2020/05/01/guile-ssh_0.11.3-2_unstable.log
>>
>> A list of current common problems and possible solutions is available at
>> http://wiki.debian.org/qa.debian.org/FTBFS . You're welcome to contribute!
>
> I can't reproduce this issue on amd64 or arm64, with versions 0.11.3-2
> (sid/bullseye) or 0.12.0-1 (experimental). Both versions also built fine
> on the buildd's, originally...
>
> Reading the above mentioned wiki page, I tried building without network
> to ensure it wasn't somehow trying to ssh over the network, but the
> tests passed. How is network disabled in your tests?
>
> According to https://tests.reproducible-builds.org/debian/guile-ssh,
> amd64 and arm64 have failures, but they appear to be different tests
> entirely.
>
>
>> About the archive rebuild: The rebuild was done on EC2 VM instances from
>> Amazon Web Services, using a clean, minimal and up-to-date chroot.
>
> All my tests were also on updated, clean, minimal chroots... is there
> anything unusual with your test setup not mentioned on the FAQ?
>
>
>> Every failed build was retried once to eliminate random failures.
>
> Did the retried build fail in the same way vs. just testing that it
> failed twice?

The newer guile-ssh 0.12.0-2 is now in unstable, 

Bug#961889: src:gnutls28: Fails building chains with expired intermediate regardless of trust store

2020-05-30 Thread Andreas Metzler
X-Debbugs-Cc: severity -1 serious
X-Debbugs-Cc: found -1 3.6.7-1

On 2020-05-31 Chris Hofstaedtler  wrote:
> Package: src:gnutls28
> Version: 3.6.7-4+deb10u3
> Severity: grave
> Justification: renders package unusable

> Hi,

> gnutls appears to fail building a certificate chain, if:
> - the server sends an alternate chain with an expired intermediate
> - a matching root is in the local trust store.

[...]
> I'm marking this grave, as GnuTLS doesn't seem to follow standards here,
> various other software just works, GnuTLS-using clients all break, and
> many many sites on the public Internet send the cross-signed
> certificate.

Hello,

thanks for the report.

I disagree on the severity here, since only a very small minority of
internet servers provide alternative trust paths at all and out of these
only a small percentage send an alternative trust path using an expired
certificate. (Personally I would consider the latter a server-side 
configuration error.)

cu Andreas

-- 
`What a good friend you are to him, Dr. Maturin. His other friends are
so grateful to you.'
`I sew his ears on from time to time, sure'



Bug#961432: RFP: picom -- lightweight compositor for X11

2020-05-30 Thread Lev Lamberov
Hi Nikos,

Сб 30 мая 2020 @ 13:34 Nikos Tsipinakis :

> On 26/05, Lev Lamberov wrote:
>> Then you could compare your packages and somehow merge them, taking best 
>> pieces.
>
> I took a look at that package and cherry-picked some improvements from there,
> also added Fritz to d/copyright. I think it's ready to be uploaded now, I've
> put it on mentors[1].
>
> Upstream symlinks compton to picom and also installs a compton.desktop file, 
> so
> rather than override that I opted to set a Conflict/Replaces for compton.
>
> [1] https://mentors.debian.net/debian/pool/main/p/picom/picom_8-1.dsc

Good. Could you update your Salsa repository too?

Your d/watch needs some tweaks, because currently it detects 7.5 as the
latest upstream version, where there is 8 (which you package).

I'd recommend using pristine-tar.

And I have a question. Why don't you import upstream versions as
archives and not use upstream branch to track upstream master? The
latter could make cherry-picking patches much more easy.

There are some lintian stuff to deal with:

lintian -L ">=pedantic" ../*.changes
W: picom: binary-without-manpage usr/bin/compton
W: picom: binary-without-manpage usr/bin/compton-trans
I: picom: desktop-entry-lacks-icon-entry usr/share/applications/picom.desktop
I: picom: spelling-error-in-binary usr/bin/picom everytime every time
I: picom: spelling-error-in-manpage usr/share/man/man1/picom.1.gz everytime 
every time
I: picom source: testsuite-autopkgtest-missing
P: picom source: file-contains-trailing-whitespace debian/control (line 50)
P: picom source: package-uses-old-debhelper-compat-version 12
P: picom source: rules-requires-root-missing

At the very least, please, add the following changes:

(1) migrate to debhelper-compat=13 (in d/control),
(2) add Rules-Requires-Root: no (in d/control),
(3) remove trailing whitespaces from d/*.

Also, do we really need to have symlinks (compton and compton-trans)
and corresponding desktop files? Since it is a new Debian package,
probably we can drop these. What do you think?

And I have not looked into d/copyright yet.

Cheers!
Lev



Bug#961886: Clicking the Dash Icon

2020-05-30 Thread asmegir
Clicking the epiphany-browser Dash To Dock Icon also produces 2
instances (2 open windows.)

Damon



Bug#961899: RFS: wifi-qr/0.1-1 -- WiFi Share and Connect with QR

2020-05-30 Thread Ko Ko Ye`
Package: sponsorship-requests
Severity: wishlist

Dear mentors,

I am looking for a sponsor for my package "wifi-qr"

 * Package name: wifi-qr
   Version : 0.1-1
   Upstream Author : kokoye2007 
 * URL : https://github.com/kokoye2007/wifi-qr
 * License : GPL-3.0+
 * Vcs : https://github.com/kokoye2007/wifi-qr
   Section : utils

It builds those binary packages:

  wifi-qr - WiFi Share and Connect with QR

 PC to Android Network SSID Password share with QR code.
 Idea from Xiaomi Android WiFi Password share with QR
 Its just bash script and qrencode only.
 now support also QR Scan with connect to WIFI.
 Make to easy and happy.

PC to Android Network SSID Password share with QR code.
Idea from Xiaomi Android WiFi Password share with QR
Its just bash script and qrencode only.
now support also QR Scan with connect to WIFI.
Make to easy and happy.

OPTIONS
   wifi-qr option

   gGUI Main Menu

   cWiFi QR Create GUI

   tWiFi QR Create Terminal

   sQR Scan and Auto Connect WiFi

   qQR Scan and Connect WiFi GUI



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

  https://mentors.debian.net/package/wifi-qr

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

  dget -x
https://mentors.debian.net/debian/pool/main/w/wifi-qr/wifi-qr_0.1-1.dsc

Changes since the last upload:

   * Initial packaging (Closes: #961897).

Regards,


Bug#961761: psmisc: killall fails to kill processes with names longer than 15 characters

2020-05-30 Thread Frank Heckenbach
> On Fri, 29 May 2020 at 09:21, Frank Heckenbach  
> wrote:
> > killall fails to kill processes with names longer than 15
> > characters.
> Actually it does. But the comm length has increased for some kernels.
> 
> If you're asking it to kill something with another name because the
> comm is "killall-bug-wit" not "killall-bug-with-long-names" it used to
> work even though the command is wrong because it just cut the extra
> characters off. This won't work when the comm length is increased.

Don't know what you mean by "the command is wrong" (I gave the full
name), and honestly I don't (and shouldn't have to) care about comm
length etc.

Fact is, it doesn't match the documented behaviour (in its own man
page!). It used to do so before. So it's clearly a regression.

Again, as I quoted, the man page says:

:   -e, --exact
:  Require an exact match for very long names.  If a command
:  name is longer than 15 characters, the full name may be
:  unavailable (i.e.  it is swapped  out). In  this case,
:  killall will kill everything that matches within the first
:  15 characters.  With -e, such entries are skipped.  [...]

So logically, there are two possibilities (without "-e"):

- The full name is available, in which case it should work since I
  gave the full name.

- The full name is not available, in which case it should also work
  since the first 15 characters match.

> $ ps -o comm 1739632
> COMMAND
> killall-bug-wit
> $ killall killall-bug-wit

I know that's a workaround. But as I wrote:

: I think that's at least "serious", because it makes killall by name
: basically unusable, at least in automated contexts, unless you want
: to replace:
:
:   killall "$x"
:
: everywhere with some beast such as (untested):
:
:   killall "$(echo "$x" | cut -c-15)"

The duplicate report you mention below also calls that problematic
"so I don't have to count letters when I'm typing into my shell, and
can write shellscripts that work regardless of what the kernel limit
is."

> However 23.3 has a work-around where if the comm length is exactly 15
> characters then it matches on this too.
> This is a duplicate of bug #912748 and fixed in psmisc 23.3-1

Then please provide a backport for buster (possibly even as a
security fix, as I explained).

Debian developers tend to forget that stable is the
release Debian itself recommends to use (see
https://www.debian.org/releases/index.en.html),
so if you leave such a serious bug unfixed, I guarantee
you'll get more duplicate reports!

Frank



Bug#949762: [Python-modules-team] Bug#949762: Bug#949762: Please update hypothesis package to >= 5.1

2020-05-30 Thread Sandro Tosi
> For that reason, I decided skip the test [1]. Please, I need a more experience
> review, or if it's all ok, I will need sponsorship to  upload.

you did not push upstream and pristine-tar branches, so now i cannot
look and fix and upload this package :(

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



Bug#951891: open-ath9k-htc-firmware: adoption status

2020-05-30 Thread John Scott
Control: tags -1 help
Control: owner -1 jsc...@posteo.net

Hi,

I've been quiet on this important package for a little while and ought to give 
an update, if nothing else to assure I've not bailed :).

Recently I've been taking time to get acquainted with the tools, like gbp and 
friends, for a Git-only workflow seeing as upstream hasn't been making any 
formal releases. That need not be a blocker but I took up this opportunity.

I'm now suitably comfortable to start fruitfully hacking and hope to have a 
candidate for a new upload in a week or two.

Oleksij, thank you for your maintainership up-and-downstream, and thereby 
accommodating a dire need in free software.

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


Bug#659348: LibreJS ITP updates

2020-05-30 Thread John Scott
Before I dig in to spending the coming weeks fixing firmware-ath9k-htc, which 
has more release-critical issues, an update on findings with LibreJS is due.

* I've contacted upstream about possibly removing the embedded code 
copies [1], which unfortunately some of which are included in Git also. They 
didn't get back to me, but since they're DFSG that should pose no problem.

* The build directions say browserify is needed (RFP #780357), but it looks 
like browserify-lite is good enough. I'm not sure it's strictly necessary to 
use browserify to pack the JS together at all, seeing that for Debian's sake 
it'd be better to avoid this as I believe most webext-* packages seem to 
install things unpacked. But if it's needed, it's doable.

And that's all I've concluded so far.

[1] https://lists.gnu.org/archive/html/bug-librejs/2020-05/msg6.html

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


Bug#961897: RFS: wifi-qr/0.1-1 [ITP] -- WiFi Share and Connect with QR

2020-05-30 Thread Ko Ko Ye`
Package: sponsorship-requests
Severity: wishlist

Dear mentors,

I am looking for a sponsor for my package "wifi-qr"

 * Package name: wifi-qr
   Version : 0.1-1
   Upstream Author : kokoye2007 
 * URL : https://github.com/kokoye2007/wifi-qr
 * License : GPL-2.0+
 * Vcs : https://github.com/kokoye2007/wifi-qr
   Section : utils

It builds those binary packages:


wifi-qr - WiFi Share and Connect with QR

 PC to Android Network SSID Password share with QR code.
 Idea from Xiaomi Android WiFi Password share with QR
 Its just bash script and qrencode only.
 now support also QR Scan with connect to WIFI.
 Make to easy and happy.

PC to Android Network SSID Password share with QR code.
Idea from Xiaomi Android WiFi Password share with QR
Its just bash script and qrencode only.
now support also QR Scan with connect to WIFI.
Make to easy and happy.

OPTIONS
   wifi-qr option

   gGUI Main Menu

   cWiFi QR Create GUI

   tWiFi QR Create Terminal

   sQR Scan and Auto Connect WiFi

   qQR Scan and Connect WiFi GUI

   vWiFi-QR Version is 0.1.1
~

  https://mentors.debian.net/package/wifi-qr

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

  dget -x https://mentors.debian.net/debian/pool/main/w/wifi-qr_0.1-1.dsc


Regards,


Bug#961896: nuitka: Please make another source-only upload to allow testing migration

2020-05-30 Thread Yaroslav Halchenko
Thanks for the buzz! I really need to change my helper for uploads process to 
make sure they are source only ones by default. I will wait for the upstream 
Kay  who is also the maintainer :-) - a new release might be not too far away.

On May 30, 2020 9:38:57 PM EDT, Boyuan Yang  wrote:
>Source: nuitka
>Severity: important
>Version: 0.6.8.3+ds-1
>Tags: sid  bullseye
>X-Debbugs-CC: kay.ha...@gmail.com  y...@debian.org
>
>
>Hi Yaroslav and Kay,
>
>It looks like all previous uploads for package nuitka in Debian are not
>source-only uploads. As a result, this package has been missing in
>Debian Testing for quite some time.
>
>I see that all uploads are sponsored by Yaroslav. Please make sure to
>make source-only uploads in the future to avoid issues like this one.
>For more information about source-only upload, see 
>https://wiki.debian.org/SourceOnlyUpload .

-- 
Yaroslav O. Halchenko (mobile version)
Center for Open Neuroscience   http://centerforopenneuroscience.org
Dartmouth College, NH, USA



Bug#961898: RFP: mypy-protobuf -- Generate mypy stub files from protobuf specs

2020-05-30 Thread Jelmer Vernooij
Package: wnpp
Severity: wishlist

* Package name: mypy-protobuf
  Version : 1.13
  Upstream Author : Dropbox
* URL : https://github.com/dropbox/mypy-protobuf
* License : Apache-2
  Programming Lang: Python
  Description : Generate mypy stub files from protobuf specs

mypy-protobuf can generate mypy stubs from protobuf specifications,
removing the need to manually specify the types.



Bug#961896: nuitka: Please make another source-only upload to allow testing migration

2020-05-30 Thread Boyuan Yang
Source: nuitka
Severity: important
Version: 0.6.8.3+ds-1
Tags: sid  bullseye
X-Debbugs-CC: kay.ha...@gmail.com  y...@debian.org


Hi Yaroslav and Kay,

It looks like all previous uploads for package nuitka in Debian are not
source-only uploads. As a result, this package has been missing in
Debian Testing for quite some time.

I see that all uploads are sponsored by Yaroslav. Please make sure to
make source-only uploads in the future to avoid issues like this one.
For more information about source-only upload, see 
https://wiki.debian.org/SourceOnlyUpload .

-- 
Regards,
Boyuan Yang


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


Bug#959558: this fix breaks things

2020-05-30 Thread Rebecca N. Palmer
This fix causes Sphinx to fail if documenting an object whose 
__getattr__ fails, e.g. flask.request.  This causes at least snakemake 
to FTBFS.


Details and fix:
https://github.com/sphinx-doc/sphinx/pull/7520

A workaround in failing packages is to add
autodoc_default_options = {'exclude-members': 'request'}
(or whatever object triggers the error) to conf.py, but if there are 
more than just snakemake, I suggest instead fixing sphinx itself.




Bug#961895: nuitka: Invalide Vcs-Git and Vcs-Browser values

2020-05-30 Thread Boyuan Yang
Source: nuitka
Severity: normal
Version: 0.6.8.3+ds-1
X-Debbugs-CC: kay.ha...@gmail.com

Dear Debian nuitka maintainer,

The Vcs-* fields in debian/control file has some invalid values:

* When accessing https://git.nuitka.net/Nuitka.git , I get a 404 not
found.

* When accessing https://nuitka.net/gitweb/?p=Nuitka.git;a=summary , I
get a raw gitweb perl script instead of the result of running such
script.

Please review your server settings so that those information can be
used to browse and retrieve the packaging files.

-- 
Regards,
Boyuan Yang


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


Bug#961894: mutt fails on non-linear certificate chains

2020-05-30 Thread Wifi Freak
Subject: mutt fails on non-linear certificate chains
Package: mutt
Version: 1.10.1-2.1
Severity: important
Tags: upstream

Dear Maintainer,

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

mutt fails on non-linear certificate chains when the CA that issued
the server shipped intermediate CA has expired but an intermediate
(non expired one) is present within the certificate store.

Expected behaviour:
- mutt accepts this connection without a certificate warning and asks
for username and password

Behaviour is fixed in mutt 1.14.2.

Way to reproduce:
mutt -f imaps://mail.manitu.de

the following message appears within mutt:
###
This certificate belongs to:
   COMODO RSA Certification Authority
   COMODO CA Limited

   Salford Greater Manchester GB

This certificate was issued by:
   AddTrust External CA Root
   AddTrust AB
   AddTrust External TTP Network
   SE

This certificate is valid
   from Tue, 30 May 2000 10:48:38 UTC
 to Sat, 30 May 2020 10:48:38 UTC
SHA1 Fingerprint: F5AD 0BCC 1AD5 6CD1 5072 5B1C 866C 30AD 92EF 21B0
SHA256 Fingerprint: 4F32 D5DC 00F7 1525 0ABC C486 511E 37F5
01A8 99DE B3BF 7EA8 ADBB D3AE F1C4 12DA

WARNING: Server certificate has expired
###
as the server is shipping an intermediate CA issued by an expired CA
(AddTrust External CA Root).

OpenSSL validates this connection just fine as "COMODO RSA
Certification Authority" is included within the system's certificate
store.

openssl s_client -connect mail.manitu.de:993
###
003)
depth=2 C = GB, ST = Greater Manchester, L = Salford, O = COMODO CA
Limited, CN = COMODO RSA Certification Authority
verify return:1
depth=1 C = GB, ST = Greater Manchester, L = Salford, O = COMODO CA
Limited, CN = COMODO RSA Domain Validation Secure Server CA
verify return:1
depth=0 OU = Domain Control Validated, CN = *.manitu.de
verify return:1
---
Certificate chain
 0 s:OU = Domain Control Validated, CN = *.manitu.de
   i:C = GB, ST = Greater Manchester, L = Salford, O = COMODO CA
Limited, CN = COMODO RSA Domain Validation Secure Server CA
-BEGIN CERTIFICATE-
MIIHqzCCBpOgAwIBAgIQQaVrtZY6LQITn0Zb2mXHVTANBgkqhkiG9w0BAQsFADCB
kDELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4G
A1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxNjA0BgNV
BAMTLUNPTU9ETyBSU0EgRG9tYWluIFZhbGlkYXRpb24gU2VjdXJlIFNlcnZlciBD
QTAeFw0xODA1MjkwMDAwMDBaFw0yMDA4MjYyMzU5NTlaMDkxITAfBgNVBAsTGERv
bWFpbiBDb250cm9sIFZhbGlkYXRlZDEUMBIGA1UEAwwLKi5tYW5pdHUuZGUwggIi
MA0GCSqGSIb3DQEBAQUAA4ICDwAwggIKAoICAQClwKfXTkWH1u2WA9SicE9gg5vY
WK9xJFh8dIjFZE3ksfPFVvHwpQMxEj/DoJD8SWBWdKM7BWdlzlSGLi6iFw+n6mzV
92wz37I54ngYd8VPcn/GkNd+fKnL+mHKDRDq45IERzo93BhBzVpIC29GC2eBZhd/
xefEbb/LQWjeK3ZDt6xBBWvMFV9N4pPcXncdWS3yl+t/MiM5GeU4dT+gdeSMXAOV
h0d+bRpxFeOkSaP/lsj8/khhsy6EfLjnGZDoJenwVFatvSvgv6sBuzcYwHQCxAVj
Omp9+dSD+YO8u1Ffi6lHUA/sDJw8/vniqtqZYfpKKas8kQ6yJqXYQWmDOD2emkrE
vg7Yp91eg1MDqNq39JbxLRyypWC5zDI8/cvmRBwB4TK7NZalD526dPmWzcPOAbeK
1LFZpYxxl0CynnIvakMtmfpatlher0CPutlQv4E4iI8y79D8ckkZKPJ3Sl1Pe7Rc
iX8aNGCY8hQzK/O4/P1zQB5Z7F2pym1/gSDYG68wdVrDeMQqOYPOEjy+D07ShK30
kk4X6tf2vME2PYZGQqUZQrFE0KuTtMSHXqZNKrTYyvRiUEQ8y2T0Wnej1LY3eKRM
8ABl8SGdJvnKrRo21u1e7sOhsFZXgTvSGZXOQbgD6b2IB/A0/60dkiDIj41yqW08
+sNLDAUpWvt/FsWywwIDAQABo4IDVTCCA1EwHwYDVR0jBBgwFoAUkK9qOpRaC9iQ
6hJWc99DtDoo2ucwHQYDVR0OBBYEFILJqXWhWFSldlHetk95ADaak1SCMA4GA1Ud
DwEB/wQEAwIFoDAMBgNVHRMBAf8EAjAAMB0GA1UdJQQWMBQGCCsGAQUFBwMBBggr
BgEFBQcDAjBPBgNVHSAESDBGMDoGCysGAQQBsjEBAgIHMCswKQYIKwYBBQUHAgEW
HWh0dHBzOi8vc2VjdXJlLmNvbW9kby5jb20vQ1BTMAgGBmeBDAECATBUBgNVHR8E
TTBLMEmgR6BFhkNodHRwOi8vY3JsLmNvbW9kb2NhLmNvbS9DT01PRE9SU0FEb21h
aW5WYWxpZGF0aW9uU2VjdXJlU2VydmVyQ0EuY3JsMIGFBggrBgEFBQcBAQR5MHcw
TwYIKwYBBQUHMAKGQ2h0dHA6Ly9jcnQuY29tb2RvY2EuY29tL0NPTU9ET1JTQURv
bWFpblZhbGlkYXRpb25TZWN1cmVTZXJ2ZXJDQS5jcnQwJAYIKwYBBQUHMAh0
dHA6Ly9vY3NwLmNvbW9kb2NhLmNvbTAhBgNVHREEGjAYggsqLm1hbml0dS5kZYIJ
bWFuaXR1LmRlMIIBfgYKKwYBBAHWeQIEAgSCAW4EggFqAWgAdgDuS723dc5guuFC
aR+r4Z5mow9+X7By2IMAxHuJeqj9ywAAAWOrI3SpAAAEAwBHMEUCIHBywDOdN6pj
eEdmvW8Hu8kWg0EztHl5zI7t+hm5UHL8AiEAiGL1+aUB78za23d7bxqpAHpbpD/P
3odsBi3yDr4jEMcAdwBep3P531bA57U2SH3QSeAyepGaDIShEhKEGHWWgXFFWAAA
AWOrI3TtAAAEAwBIMEYCIQD+vMLkX92U2SpiJ6K/eMH9qUlIQAtZwDIYtv3++NCj
3QIhAMwGvgjQ6eLQ3QDgKBni2nq4DySNxTrad4RH52+SyBYWAHUAVYHUwhaQNgFK
6gubVzxT8MDkOHhwJQgXL6OqHQcT0wwAAAFjqyN0zAAABAMARjBEAiAYSvgHMFWq
LsC1bnETQEdJik1W+ie+F0suJBZDqAbvVgIgIzf09fSyHGW1TXKMfDHkpRI5KeCw
Os37kJkFVZi8v3UwDQYJKoZIhvcNAQELBQADggEBAEUDlWrGH9yjr72M0pkbh1mK
kdYXR1ZE1BsAYg7tnpQ7Ndkrgo7QX7ENs20LaXI9duxWOEbgguUzRqehIUf8YrJ2
F9xrszLnVviA6jZikhLeRnZQGYIlTfyAMPWFjmTtAZTfkBVquo7vocnyHADPBDko
SutvmmSnIAHipUtA39Lrdgt6soIZ8RPyZ50WON/jKqHUfzRboYBICMNSN7xa9DhS
iQ4MBTMO3QRVQeDYLSn9gpPG074TdASKDogQlQ/tEydMKL4j/7FV3kKsEiZuSwSF
VGfEvi1voQF4iAlkmcUQTOgnxrghaTFH4Ypfz4mjvuRsTwM/8OmBY6P33Sk8HT0=
-END CERTIFICATE-
 1 s:C = GB, ST = Greater Manchester, L = Salford, O = COMODO CA
Limited, CN = COMODO RSA Domain Validation Secure Server CA
   i:C = GB, ST = Greater Manchester, L = Salford, O = COMODO CA

Bug#961893: npm2deb: Minor manpage improvements

2020-05-30 Thread Wookey
Package: npm2deb
Version: 0.3.0-4
Severity: minor
Tags: patch

The man page is minimal and was not clear to me so I improved it a bit.

Made clear that you don't put in 'DEBUG' text but a level number of 1 or 2.

Clarified behaviour of 'create' and fixed a typo. 
diff -u a/man/npm2deb.1 b/man/npm2deb.1
--- a/man/npm2deb.1 2020-05-31 01:21:47.609895454 +0100
+++ b/man/npm2deb.1 2020-05-31 01:28:56.872783273 +0100
@@ -4,7 +4,7 @@
 - debianize nodejs modules available via npm
 
 .SH SYNOPSIS
-.B npm2deb\fR [\fB-D\fR \fIdebug\fR] { create | view | depends | rdepends | 
search | itp } \fInode_module\fR
+.B npm2deb\fR [\fB-D\fR \fIdebuglevel\fR] { create | view | depends | rdepends 
| search | itp } \fInode_module\fR
 .br
 .B npm2deb\fR license {-l | license }
 
@@ -20,15 +20,15 @@
 \fB\-h\fR, \fB\-\-help\fR
 show this help message and exit
 .TP
-\fB\-D\fR DEBUG, \fB\-\-debug\fR DEBUG
-set debug level
+\fB\-D\fR DEBUG, \fB\-\-debug\fR DEBUGLEVEL
+set debug level (currently 1 or 2)
 .TP
 \fB\-v\fR, \fB\-\-version\fR
 show program's version number and exit
 .SS "commands:"
 .TP
 \fIcreate
-create the debian files
+download node module, create debian files, and generate a package
 .TP
 \fIview
 a summary view of a node module
@@ -40,10 +40,10 @@
 show the reverse dependencies for module
 .TP
 \fIsearch
-look for module in debian project
+look for module in debian project. Checks the archive, simialr named packages, 
and WNPP for other packaging attempts
 .TP
 \fIitp
-print a itp bug template
+print an itp bug template
 .TP
 \fIlicense
 print license template and exit


Bug#961892: ifupdown-extra: reject must be replace by blackhole

2020-05-30 Thread Guillaume Avez
Package: ifupdown-extra
Version: 0.27
Severity: normal

Dear Maintainer,

   * What led up to the situation?
Playing with blackhole and how to set it "a standard way".

   * What exactly did you do (or not do) that was effective (or
 ineffective)?
I added a 'reject' line in /etc/network/routes 

   * What was the outcome of this action?
Nothing happened

   * What outcome did you expect instead?
Get a null route.


All this because iproute2 take over old route.
The keyword and syntax has changed from 
route add  reject
to
ip route add blackhole 

I checked 0.28 version, it has the same problem.

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

Kernel: Linux 4.9.0-12-amd64 (SMP w/1 CPU core)
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), 
LANGUAGE=fr_FR.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages ifupdown-extra depends on:
ii  bind9-host [host]1:9.10.3.dfsg.P4-12.3+deb9u6
ii  curl 7.52.1-5+deb9u10
ii  dpkg 1.18.25
ii  host 1:9.10.3.dfsg.P4-12.3+deb9u6
ii  iproute2 4.9.0-1+deb9u1
ii  iputils-arping   3:20161105-1
ii  iputils-ping [ping]  3:20161105-1
ii  net-tools1.60+git20161116.90da8a0-1
ii  netcat-traditional [netcat]  1.10-41+b1

Versions of packages ifupdown-extra recommends:
ii  ethtool  1:4.8-1+b1
ii  ndisc6   1.0.3-3

ifupdown-extra suggests no packages.

-- Configuration Files:
/etc/init.d/networking-routes changed:
[ -x /sbin/ip ] || exit 0
ROUTEFILE="/etc/network/routes"
[ ! -r "$ROUTEFILE" ] && exit 0
. /lib/lsb/init-functions
VERBOSITY=${VERBOSITY:-0}
run_route() {
local COMMAND="ip route $*"
export LC_MESSAGES=C # We need the return messages to be in english
RETMESSAGE="$($COMMAND 2>&1)"
RETVALUE=$?
if test $RETVALUE -ne 0 ; then
[ "$VERBOSITY" -eq 1 ] && echo "DEBUG: calling: '$COMMAND' 
FAILED"
# Process the messages and omits those that are not
# relevant.
case "$RETMESSAGE" in
# Omit 'File exists' since the route is already there..
*File*exists) return ;;
# 'No such process' is only omitted if the route is being
# deleted.  If the route is being created, this error message
# might appear if the gateway is not reachable.
*No*such*process) [ "$1" = "del" ] && return ;;
*)
esac
log_failure_msg "Error while executing:" \
 "  Command '$COMMAND' returned:  
${RETMESSAGE%%Usage:*}"\
 "  Configuration line: $LINE"
else
[ "$VERBOSITY" -eq 1 ] && echo "DEBUG: calling: '$COMMAND' 
SUCCEEDED"
fi
} 
del_global_routes() {
ret=0
cat $ROUTEFILE | egrep "^[^#].*$" | 
while read network netmask gateway interface ; do
if [ -n "$interface" ] && [ -n "$network" ] && [ -n "$netmask" ] && 
[ -n "$gateway" ] ; then
if [ "$gateway" != "blackhole" ] ; then
[ "$VERBOSITY" -eq 1 ] && echo "DEBUG: Deleting global 
route for $network / $netmask through gateway $gateway"
if [ "$interface" != "any" ] ; then
run_route del $network/$netmask via $gateway dev 
$interface 
else
run_route del $network/$netmask via $gateway 
fi
[ $? -ne 0 ] && ret=$?
else
[ "$VERBOSITY" -eq 1 ] && echo "DEBUG: Deleting blackhole 
route for $network / $netmask"
run_route del blackhole $network/$netmask
[ $? -ne 0 ] && ret=$?
fi
else
echo "ERROR: Incorrect line for global network routes in 
$ROUTEFILE: '$network $netmask $gateway $interface'"
ret=1
fi
done
return $ret
}
add_global_routes() {
ret=0
cat $ROUTEFILE | egrep "^[^#].*$" | 
while read network netmask gateway interface ; do
if [ -n "$interface" ] && [ -n "$network" ] && [ -n "$netmask" ] && 
[ -n "$gateway" ] ; then
if [ "$gateway" != "blackhole" ] ; then
[ "$VERBOSITY" -eq 1 ] && echo "DEBUG: Adding global route 
for $network / $netmask through gateway $gateway"
if [ "$interface" != "any" ] ; then
run_route add $network/$netmask via $gateway dev 
$interface
else
run_route add $network/$netmask via $gateway 
fi
[ $? -ne 0 ] && ret=$?
 

Bug#961891: ITP: eclipse-swtchart -- Eclipse SWTChart allows to create different types of charts

2020-05-30 Thread Sudip Mukherjee
Package: wnpp
Severity: wishlist
Owner: Sudip Mukherjee 
Control: block 961796 by -1

* Package name: eclipse-swtchart
  Version : 0.12.0
  Upstream Author : Yoshitaka Yanagida 
Philip Wenig 
* URL : https://projects.eclipse.org/projects/science.swtchart
* License : EPL-2.0
  Programming Lang: Java
  Description : Eclipse SWTChart allows to create different types of charts

The API allows to create Line, Bar and Scatter charts easily. Size,
colors, axes, ranges and all aspects of the charts can be modified via
code. It is easy to create customized charts. The library already contains
data compression to show large data sets in a performant way. Charts can be
created even more easily with the SWTChart extensions. It uses the convention
over configuration pattern and offers many additional improvements to scale
axes of different type automatically or to select specific data ranges.

The old package "libswtchart-java" is already in debian but this new
version is now a eclipse project and the class names have all changed to
org.eclipse.swtchart instead of the old old.swtchart.

This is needed to package #961796 and I can maintain it under the umbrella
of java-team.

Note:
Once it has landed, it should be possible to update the other packages
depending on the old "libswtchart-java" and use this one instead.

--
Regards
Sudip



Bug#961890: clementine: Network Remote listening IPv6 only

2020-05-30 Thread Teemu Järvinen
Package: clementine
Version: 1.3.1+git609-g623a53681+dfsg-1
Severity: normal

Dear Maintainer,

I'm running Clementine with Network Remote Option. There is an Android
App called Clementine Remote. Tried to use this, and the App can't
connect to my Computer. From my Firewall Log I can see that the App
tried IPv4 Port tcp/5500. Netstat reports Clementine is only listening
IPv6 Port tcp/5500.

The Network being used is Wifi, provided by ZTE 4g USB Network
Adapter. There seems not to be any IPv6 Options in the ZTE's Config
Interface. Firewall Log also does not report Activity, when trying
IPv6 Address of the Computer. So, there's no IPv6 in my Wifi.

I was able to work around this with:
socat TCP4-LISTEN:5500 TCP6:localhost:5500
which redirects IPv4 from my Phone to IPv6 on my Computer.

I'm wondering is it possible to make Clementine listen to IPv4 out of
the Box?


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

Versions of packages clementine depends on:
ii  gstreamer1.0-plugins-base   1.14.4-2
ii  gstreamer1.0-plugins-good   1.14.4-1
ii  gstreamer1.0-plugins-ugly   1.14.4-1
ii  libc6   2.28-10
ii  libcdio18   2.0.0-2
ii  libchromaprint1 1.4.3-3
ii  libcrypto++65.6.4-8
ii  libfftw3-double33.3.8-2
ii  libgcc1 1:8.3.0-6
ii  libgdk-pixbuf2.0-0  2.38.1+dfsg-1
ii  libglib2.0-02.58.3-2+deb10u2
ii  libgpod40.8.3-13
ii  libgstreamer-plugins-base1.0-0  1.14.4-2
ii  libgstreamer1.0-0   1.14.4-1
ii  libimobiledevice6   1.2.1~git20181030.92c5462-2
ii  liblastfm5-11.0.9-1+b11
ii  libmtp9 1.1.16-2
ii  libmygpo-qt5-1  1.1.0-3
ii  libplist3   2.0.1~git20190104.3f96731-1
ii  libprojectm2v5  2.1.0+dfsg-4+b4
ii  libprotobuf17   3.6.1.3-2
ii  libpulse0   12.2-4+deb10u1
ii  libqt5concurrent5   5.11.3+dfsg1-1+deb10u3
ii  libqt5core5a5.11.3+dfsg1-1+deb10u3
ii  libqt5dbus5 5.11.3+dfsg1-1+deb10u3
ii  libqt5gui5  5.11.3+dfsg1-1+deb10u3
ii  libqt5network5  5.11.3+dfsg1-1+deb10u3
ii  libqt5opengl5   5.11.3+dfsg1-1+deb10u3
ii  libqt5sql5  5.11.3+dfsg1-1+deb10u3
ii  libqt5widgets5  5.11.3+dfsg1-1+deb10u3
ii  libqt5x11extras55.11.3-2
ii  libqt5xml5  5.11.3+dfsg1-1+deb10u3
ii  libsqlite3-03.27.2-3
ii  libstdc++6  8.3.0-6
ii  libtag1v5   1.11.1+dfsg.1-0.3+deb10u1
ii  libx11-62:1.6.7-1
ii  projectm-data   2.1.0+dfsg-4
ii  zlib1g  1:1.2.11.dfsg-1

Versions of packages clementine recommends:
ii  gstreamer1.0-pulseaudio  1.14.4-1

Versions of packages clementine suggests:
ii  gstreamer1.0-plugins-bad  1.14.4-1+b1

-- no debconf information



Bug#961889: src:gnutls28: Fails building chains with expired intermediate regardless of trust store

2020-05-30 Thread Chris Hofstaedtler
Package: src:gnutls28
Version: 3.6.7-4+deb10u3
Severity: grave
Justification: renders package unusable

Hi,

gnutls appears to fail building a certificate chain, if:
- the server sends an alternate chain with an expired intermediate
- a matching root is in the local trust store.

This was found because the "AddTrust External CA Root" [1] expired today,
and it was used - a long time ago - to cross-sign the "USERTrust RSA
Certification Authority" Root CA. When a server sends the cross-signed
certificate, gnutls thinks the entire chain is invalid, even though the
not-expired root is contained in its trust store.

Example:

$ gnutls-cli apt.puppet.com:443
Processed 129 CA certificate(s).
Resolving 'apt.puppet.com:443'...
Connecting to '2600:9000:2043:2200:1d:fc37:1cc0:93a1:443'...
- Certificate type: X.509
- Got a certificate list of 3 certificates.
- Certificate[0] info:
 - subject `CN=apt.puppet.com,OU=PositiveSSL Multi-Domain,OU=Domain Control 
Validated', issuer `CN=Gandi Standard SSL CA 2,O=Gandi,L=Paris,ST=Paris,C=FR', 
serial 0x00d50b93f3f071150e62d87aee147a1520, RSA key 2048 bits, signed using 
RSA-SHA256, activated `2019-07-18 00:00:00 UTC', expires `2020-07-18 23:59:59 
UTC', pin-sha256="oBlhqVlMzd0j01OweaExY7LRykSLER7Cyml3qM9Rp4M="
Public Key ID:
sha1:c94ab18efcc44ba3c51d39f831a734ad4e78e60b

sha256:a01961a9594ccddd23d353b079a13163b2d1ca448b111ec2ca6977a8cf51a783
Public Key PIN:
pin-sha256:oBlhqVlMzd0j01OweaExY7LRykSLER7Cyml3qM9Rp4M=

- Certificate[1] info:
 - subject `CN=Gandi Standard SSL CA 2,O=Gandi,L=Paris,ST=Paris,C=FR', 
issuer `CN=USERTrust RSA Certification Authority,O=The USERTRUST 
Network,L=Jersey City,ST=New Jersey,C=US', serial 
0x05e4dc3b9438ab3b8597cba6a19850e3, RSA key 2048 bits, signed using RSA-SHA384, 
activated `2014-09-12 00:00:00 UTC', expires `2024-09-11 23:59:59 UTC', 
pin-sha256="WGJkyYjx1QMdMe0UqlyOKXtydPDVrk7sl2fV+nNm1r4="
- Certificate[2] info:
 - subject `CN=USERTrust RSA Certification Authority,O=The USERTRUST 
Network,L=Jersey City,ST=New Jersey,C=US', issuer `CN=AddTrust External CA 
Root,OU=AddTrust External TTP Network,O=AddTrust AB,C=SE', serial 
0x13ea28705bf4eced0c36630980614336, RSA key 4096 bits, signed using RSA-SHA384, 
activated `2000-05-30 10:48:38 UTC', expires `2020-05-30 10:48:38 UTC', 
pin-sha256="x4QzPSC810K5/cMjb05Qm4k3Bw5zBn4lTdO/nEW/Td4="
- Status: The certificate is NOT trusted. The certificate chain uses 
expired certificate.
*** PKI verification of server certificate failed...
*** Fatal error: Error in the certificate.

Note that modern browsers, and OpenSSL 1.1.1 has no problem with this
server.

Obviously, this also breaks APT.

I'm marking this grave, as GnuTLS doesn't seem to follow standards here,
various other software just works, GnuTLS-using clients all break, and
many many sites on the public Internet send the cross-signed
certificate.

Thanks,
Chris

[1] https://crt.sh/?id=1


-- 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-9-amd64 (SMP w/12 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 /bin/dash
Init: systemd (via /run/systemd/system)



Bug#961876: ncdu: new upstream version 1.15

2020-05-30 Thread Christian Göttsche
Package: ncdu
Version: 1.14.1-1

Hi,

ncdu released a new version: 1.15
Please consider to package it, as it closes #953731 also probably also #957580 .
Please also enable hardening flags `export DEB_BUILD_MAINT_OPTIONS =
hardening=+all`.

Best regards,
 Christian Göttsche



Bug#961888: qemu: CVE-2020-13361

2020-05-30 Thread Salvatore Bonaccorso
Source: qemu
Version: 1:5.0-5
Severity: important
Tags: security upstream
Forwarded: https://lists.gnu.org/archive/html/qemu-devel/2020-05/msg07230.html

Hi,

The following vulnerability was published for qemu.

CVE-2020-13361[0]:
| In QEMU 4.2.0, es1370_transfer_audio in hw/audio/es1370.c does not
| properly validate the frame count, which allows guest OS users to
| trigger an out-of-bounds access during an es1370_write() operation.


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

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2020-13361
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-13361
[1] https://lists.gnu.org/archive/html/qemu-devel/2020-05/msg07230.html

Please adjust the affected versions in the BTS as needed.

Regards,
Salvatore



Bug#961887: qemu: CVE-2020-13362

2020-05-30 Thread Salvatore Bonaccorso
Source: qemu
Version: 1:5.0-5
Severity: important
Tags: security upstream
Forwarded: https://lists.gnu.org/archive/html/qemu-devel/2020-05/msg03463.html

Hi,

The following vulnerability was published for qemu.

CVE-2020-13362[0]:
| In QEMU 4.2.0, megasas_lookup_frame in hw/scsi/megasas.c has an out-
| of-bounds read via a crafted reply_queue_head field from a guest OS
| user.


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

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2020-13362
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-13362
[1] https://lists.gnu.org/archive/html/qemu-devel/2020-05/msg03463.html

Please adjust the affected versions in the BTS as needed.

Regards,
Salvatore



Bug#960559: burgerspace: Application crashes if you complete a level after loosing the game

2020-05-30 Thread Pierre Sarrazin
Hi Markus,

The report says the bug was found in burgerspace 1.9.2-3 and
libflatzebra-0.1-2v5 0.1.6-5.

The current version of BurgerSpace is 1.9.3 and for flatzebra, it
is 0.1.7.

I would recommend trying to reproduce the bug with those current
versions, in case the bug has been fixed since 1.9.2 came out.

--
Pierre Sarrazin 



Bug#961844: fixed in libguestfs 1:1.42.0-4

2020-05-30 Thread Gianfranco Costamagna
control: reopen -1
control: notfixed -1 1:1.42.0-4

Hello, to fix the issue I added the -Xguestfs-erlang.3 to dh_missing, not 
dh_install
target

cheers,

Gianfranco

On Sat, 30 May 2020 13:33:31 + Debian FTP Masters 
 wrote:
> Source: libguestfs
> Source-Version: 1:1.42.0-4
> Done: Hilko Bengen 
> 
> We believe that the bug you reported is fixed in the latest version of
> libguestfs, which is due to be installed in the Debian FTP archive.
> 
> A summary of the changes between this version and the previous one is
> attached.
> 
> Thank you for reporting the bug, which will now be closed.  If you
> have further comments please address them to 961...@bugs.debian.org,
> and the maintainer will reopen the bug report if appropriate.
> 
> Debian distribution maintenance software
> pp.
> Hilko Bengen  (supplier of updated libguestfs package)
> 
> (This message was generated automatically at their request; if you
> believe that there is a problem with it please contact the archive
> administrators by mailing ftpmas...@ftp-master.debian.org)
> 
> 
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
> 
> Format: 1.8
> Date: Sat, 30 May 2020 15:15:25 +0200
> Source: libguestfs
> Architecture: source
> Version: 1:1.42.0-4
> Distribution: unstable
> Urgency: medium
> Maintainer: Debian Libvirt Maintainers 
> 
> Changed-By: Hilko Bengen 
> Closes: 961844
> Changes:
>  libguestfs (1:1.42.0-4) unstable; urgency=medium
>  .
>* dh_install: Ignore guestfs-erlang manpage, for real (Closes: #961844)
> Checksums-Sha1:
>  0b0159ed5e3752f5171ee32f0f8dce2d03493f1a 5980 libguestfs_1.42.0-4.dsc
>  7eb184de970045dfb7222166f6b8ec89b6512fab 42240 
> libguestfs_1.42.0-4.debian.tar.xz
>  03bb953b2527846596b6a24045f65e47c570710f 18144 
> libguestfs_1.42.0-4_source.buildinfo
> Checksums-Sha256:
>  9f1f6a131a5c86fc480a157eb1b6515ee646eb14989973e901063c3dfac1d191 5980 
> libguestfs_1.42.0-4.dsc
>  eec71057dddb8776c62b3824af3c677a2e51008df179908a2fdb50958efb7a21 42240 
> libguestfs_1.42.0-4.debian.tar.xz
>  f02fbd69a08032d2741f0299e7a4157a4e3830bf728887ca947c2c27dbc5a335 18144 
> libguestfs_1.42.0-4_source.buildinfo
> Files:
>  bdad4f2afbd414b00f91e3006c72587f 5980 libs optional libguestfs_1.42.0-4.dsc
>  dbcc87c3597969e0bcf811d07d37ab10 42240 libs optional 
> libguestfs_1.42.0-4.debian.tar.xz
>  1c8fd9e06ec320979101cc08e3fcdfd2 18144 libs optional 
> libguestfs_1.42.0-4_source.buildinfo
> 
> -BEGIN PGP SIGNATURE-
> 
> iQJGBAEBCAAwFiEErnMQVUQqHZbPTUx4dbcQY1whOn4FAl7SXJUSHGJlbmdlbkBk
> ZWJpYW4ub3JnAAoJEHW3EGNcITp+xpQP+wUtB64ic5ngIh8ju4OnFEHxktTlkoMf
> 0vtalnNoU7sZCkbrQ5qK+9QEs/8mNQBaUVu6KG3dDWVCepvrhbOqUfCbyuUd+a+1
> FWL37M2b5BifUw6qaHX5J2hP59d36dep9lRh+GZmoXXZBYV5bXrY9IoyhNTSSBip
> Bh98yE2VMNcXPRwnaBgIFNKW2ZxSpsKeur1uEMY2x4UI5sCx0/8U8E3TdYOnhbS4



Bug#961886: gnome-shell-extension-dashtodock: Super-N Launches Double Instance

2020-05-30 Thread Damon Thomas
Package: gnome-shell-extension-dashtodock
Version: 68-1
Severity: normal

Dear Maintainer,

When using the Dash To Dock extension Super-N key combo to launch 
epiphany-browser 2 instances (with 2 visible windows) are opened. This could be 
an epiphany-browser issue as well since Super-N launches a single 
firefox-esr window. 

Thanks!
Damon

-- 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/4 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 gnome-shell-extension-dashtodock depends on:
ii  dconf-gsettings-backend [gsettings-backend]  0.36.0-1
ii  gir1.2-clutter-1.0   1.26.4+dfsg-1
ii  gnome-shell  3.36.2-1
ii  gnome-shell-extension-prefs  3.36.2-1

gnome-shell-extension-dashtodock recommends no packages.

gnome-shell-extension-dashtodock suggests no packages.

-- no debconf information



Bug#961738: RFS: dragengine/1.1 -- Drag[en]gine Game Engine

2020-05-30 Thread Roland Plüss

On 5/30/20 4:45 PM, Tobias Frost wrote:
> On Sat, May 30, 2020 at 03:08:21PM +0200, Roland Plüss wrote:
>> On 5/30/20 2:00 PM, Tobias Frost wrote:
>>> * Update to my hints list: There is a fox package, fox-1.6 [1]; you'll
>>> know for
>>> sure if it suitable…
>>>
>>> [1] https://tracker.debian.org/pkg/fox1.6
>>>
>> I've seen that. I need though fox1.7 since 1.6 is not compatible to 1.7
>> . There had been API breaking changes in 1.7 .
>>
>> If this is a vital problem please tell me. It's not possible to remove
>> fox1.7 requirement unless various parts of the package are not build
>> (namely the basic crash recovery module, the gui launcher and the entire
>> IGDE).
> Yes, this gonna be a problem due to the Debian Policy about embedded code
> copies [1].
>
> I see those options:
> - talk to the fox-1.6 maintainer about updating the package to 1.7.
>   (though I see that they generally stick to released versions and 1.7.* seems
>   to be only development snapshots; a question to ask: is the 1.7 ABI stable 
> already?)
> - make the features optional that requires 1.7
> - use only 1.6 features (listed for completeness, as you said you can't)
>
> [1] 
> https://www.debian.org/doc/debian-policy/ch-source.html#embedded-code-copies
>
To be honest I don't know how stable the author thinks 1.7 is. I had no
troubles with stability so far.

The features can be made optional but then only the console-launcher is
working. This would mean games can be played (from the console) but no
gui-launcher can be used and no development environment can be used. To
be honest I don't think such a stripped down version is useful except
for one scenario: game server hosting.

-- 
Mit freundlichen Grüssen
Plüss Roland

Game Development and Game Engine Technologies https://dragondreams.ch



signature.asc
Description: OpenPGP digital signature


Bug#954823: hydrogen: Qt5 version available

2020-05-30 Thread Nicholas D Steeves
Hi Jonas,

On Sat, May 30, 2020 at 03:57:44PM -0400, Nicholas D Steeves wrote:
> Hi Jaromír,
> 
> On Fri, Apr 03, 2020 at 07:19:06AM +0200, Jaromír Mikeš wrote:
> >Hi Alexandre,
> >I am former maintainer of this package but not active any more.
> >please contact Debian multimedia team to get help with this issue.
> >https://wiki.debian.org/DebianMultimedia
> >https://lists.debian.org/debian-multimedia/
> >Or even join it if you want to work on it.
> >https://wiki.debian.org/DebianMultimedia/Join
> >hope this helps
> >mira
> 
> Given that you haven't been active in Debian for a while, and given
> this message I understood that your intent was to drop yourself from
> Uploaders, so I went ahead and committed that change.
> 
> Please let me know if I was mistaken, and I'll revert that commit asap :-)
> 

I've arrived at the stage of work where my options are to 1) convert
to dh 2) learn about cdbs (specifically why it is overriding
debhelper-compat 13 with compat 5).  I'd prefer to spend my time on
#1.

Do you object to the move to dh?  Also, would you like to remain an
Uploader or would you like me to remove your name from the list at
this time?

Thank you,
Nicholas



signature.asc
Description: PGP signature


Bug#961885: apt-show-versions: patch for 'apt-show-versions bash: completion: function `_apt_show_versions' not found'

2020-05-30 Thread Richard Lewis
Package: apt-show-versions
Version: 0.22.11
Severity: normal
Tags: patch

Dear Maintainer,

On some systems, when i type

apt-show-versions TAB

I get

'apt-show-versions bash: completion: function _apt_show_versions' not found' 

despite having bash-completion installed. This seems to be because the 
completion snipped is using the deprecated 'have' instead of '_have'

the attached patch fixes this.

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

Versions of packages apt-show-versions depends on:
ii  apt  1.8.2.1
ii  libapt-pkg-perl  0.1.34+b1
ii  perl [libstorable-perl]  5.28.1-6

apt-show-versions recommends no packages.

apt-show-versions suggests no packages.

-- no debconf information
--- apt-show-versions.orig  2019-02-16 11:10:23.0 +
+++ apt-show-versions.new   2020-05-30 21:10:26.817007260 +0100
@@ -1,6 +1,6 @@
 #-*-shell-script-*-
 
-have apt-show-versions &&
+_have apt-show-versions &&
 _apt_show_versions()
 {
 local cur prev opts


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

2020-05-30 Thread zzz
Hi, upstream here, thanks for the patch.
this patch looks fine to me, although I have NOT tested it.
We just released 0.9.46 on May 25, but mhatta hasn't pulled it into Debian yet, 
so this would be a good time for him to do so and take this patch with it.
I'll try to migrate upstream to use the 2.x API for our 0.9.47 release, target 
August-September, so the patch would only be needed for 0.9.46.



signature.asc
Description: OpenPGP digital signature


Bug#961725: libopenblas-dev: On some cpus, openmp and pthread dead-lock

2020-05-30 Thread Dirk Eddelbuettel


On 30 May 2020 at 21:39, Sébastien Villemot wrote:
| Control: tags -1 + patch
| 
| Hi Graham,
| 
| Le samedi 30 mai 2020 à 15:09 +0200, Graham Inggs a écrit :
| 
| > I was able to reproduce this in Ubuntu 20.04 on i7-2600 with the
| > Rscript -e "example(solve)"
| > test case.  Rebuilding with
| > export DEB_LDFLAGS_MAINT_STRIP="-Wl,-Bsymbolic-functions"
| > in debian/rules solved it for me.
| > 
| > On Sat, 30 May 2020 at 09:15, Sébastien Villemot <
| > sebast...@debian.org
| > > wrote:
| > > Just one question: did you try to rebuild it from source without
| > > changing anything? Maybe it’s just the rebuild that fixed it, and not
| > > the flag change.
| > 
| > I confirm that a no-change rebuild had no effect.
| 
| Thanks to you (and to Mo) for doing those rebuilds.
| 
| > Could we get this fixed in Debian?  At worst, it should be a no-op in
| > Debian, and should someone try rebuilding locally with -Bsymbolic-
| > functions they won't fall into this trap.
| 
| Sure, we’ll fix it in Debian (a similar fix is present in src:lapack,
| by the way).
| 
| It could however take some time, because we are currently waiting for
| NEW clearance from the most recent upload of src:openblas.

Awesome too. Really good to see everybody remains on top of this.

Dirk
 
| Best,
| 
| -- 
| ⢀⣴⠾⠻⢶⣦⠀  Sébastien Villemot
| ⣾⠁⢠⠒⠀⣿⡁  Debian Developer
| ⢿⡄⠘⠷⠚⠋⠀  https://sebastien.villemot.name
| ⠈⠳⣄  https://www.debian.org
| 
| [DELETED ATTACHMENT signature.asc, application/pgp-signature]

-- 
http://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org



Bug#961725: libopenblas-dev: On some cpus, openmp and pthread dead-lock

2020-05-30 Thread Dirk Eddelbuettel


On 30 May 2020 at 15:09, Graham Inggs wrote:
| Hi
| 
| I was able to reproduce this in Ubuntu 20.04 on i7-2600 with the
| Rscript -e "example(solve)"
| test case.  Rebuilding with
| export DEB_LDFLAGS_MAINT_STRIP="-Wl,-Bsymbolic-functions"
| in debian/rules solved it for me.
| 
| On Sat, 30 May 2020 at 09:15, Sébastien Villemot  wrote:
| > Just one question: did you try to rebuild it from source without
| > changing anything? Maybe it’s just the rebuild that fixed it, and not
| > the flag change.
| 
| I confirm that a no-change rebuild had no effect.
| 
| I suspect this is the same problem that was discovered in LP: #1860601
| [1], but I was unable to reproduce it locally.
| I'll take care of fixing this in Ubuntu Groovy and SRU for Ubuntu Focal.

Lovely!  I was wondering how we could possibly reach out and get to someone!

Dirk

| Could we get this fixed in Debian?  At worst, it should be a no-op in
| Debian, and should someone try rebuilding locally with -Bsymbolic-
| functions they won't fall into this trap.
| 
| Regards
| Graham
| 
| 
| [1] https://pad.lv/1860601

-- 
http://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org



Bug#961849: [debian-mysql] Bug#961849: mariadb-10.3: CVE-2020-2814 CVE-2020-2812 CVE-2020-2760 CVE-2020-2752

2020-05-30 Thread Otto Kekäläinen
Hello!

Because of the vagueness of Oracle CVEs, I cannot judge if this
warrants a DSA or not.

I am happy to prepare a security update for you if you so request.

Currently https://release.debian.org/ states:
> stable (10.5) Not yet planned
> oldstable (9.13) Not yet planned

..so I will not rush to make stable update preparations.

I am currently preparing MariaDB 10.4/10.5 for unstable, so there will
not be a MariaDB 10.3 upload to unstable anymore. I am happy to do
stable updates on your request for 10.3 and 10.1.

Related: Currently the CVE
https://security-tracker.debian.org/tracker/CVE-2020-13249 is marked
to apply to MariaDB 10.1. That version however does not include
libmariadb3, so I think it does not apply there.



Bug#954823: hydrogen: Qt5 version available

2020-05-30 Thread Nicholas D Steeves
Hi Jaromír,

On Fri, Apr 03, 2020 at 07:19:06AM +0200, Jaromír Mikeš wrote:
>Hi Alexandre,
>I am former maintainer of this package but not active any more.
>please contact Debian multimedia team to get help with this issue.
>https://wiki.debian.org/DebianMultimedia
>https://lists.debian.org/debian-multimedia/
>Or even join it if you want to work on it.
>https://wiki.debian.org/DebianMultimedia/Join
>hope this helps
>mira

Given that you haven't been active in Debian for a while, and given
this message I understood that your intent was to drop yourself from
Uploaders, so I went ahead and committed that change.

Please let me know if I was mistaken, and I'll revert that commit asap :-)

Best,
Nicholas


signature.asc
Description: PGP signature


Bug#961884: add init script / systemd unit for clamonacc background scanner

2020-05-30 Thread Patrick Schleizer
Package: clamav-daemon
Severity: normal
X-Debbugs-CC: whonix-de...@whonix.org

Dear maintainer,

package clamav-daemon ships a file /usr/bin/clamonacc which is a
background virus scaning guard / real-time protection. It's currently
non-trivial to use.

sudo clamonacc

ERROR: Clamonacc: at least one of OnAccessExcludeUID,
OnAccessExcludeUname, or OnAccessExcludeRootUID must be specified ... it
is reccomended you exclude the clamd instance UID or uname to prevent
infinite event scanning loops

May I suggest adding an init script / systemd unit file which runs the
clamonacc background scanner?

Cheers,
Patrick



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

2020-05-30 Thread Graham Inggs
Control: tags -1 + fixed-upstream

Hi!

Thanks for forwarding this bug,

On Fri, 29 May 2020 at 02:00, Michael Biebl  wrote:
> Apparently doublecmd calls udisksctl mount -b
> I'm not really speaking Pascal: Maybe it is parsing the output of that
> command (which is brittle).
> I notice the difference between 2.8.x and 2.9.x
>
> 2.8.x:
> udisksctl mount -b /dev/sdb2
> Mounted /dev/sdb2 at /media/michael/Test.
>
> 2.9.x:
> udisksctl mount -b /dev/sdb2
> Mounted /dev/sdb2 at /media/michael/Test
>
> (note the missing '.')
>
> Maybe doublecmd get's confused by that.

It is fixed upstream [1].

Regards
Graham


[1] https://sourceforge.net/p/doublecmd/code/9425/



Bug#961725: libopenblas-dev: On some cpus, openmp and pthread dead-lock

2020-05-30 Thread Sébastien Villemot
Control: tags -1 + patch

Hi Graham,

Le samedi 30 mai 2020 à 15:09 +0200, Graham Inggs a écrit :

> I was able to reproduce this in Ubuntu 20.04 on i7-2600 with the
> Rscript -e "example(solve)"
> test case.  Rebuilding with
> export DEB_LDFLAGS_MAINT_STRIP="-Wl,-Bsymbolic-functions"
> in debian/rules solved it for me.
> 
> On Sat, 30 May 2020 at 09:15, Sébastien Villemot <
> sebast...@debian.org
> > wrote:
> > Just one question: did you try to rebuild it from source without
> > changing anything? Maybe it’s just the rebuild that fixed it, and not
> > the flag change.
> 
> I confirm that a no-change rebuild had no effect.

Thanks to you (and to Mo) for doing those rebuilds.

> Could we get this fixed in Debian?  At worst, it should be a no-op in
> Debian, and should someone try rebuilding locally with -Bsymbolic-
> functions they won't fall into this trap.

Sure, we’ll fix it in Debian (a similar fix is present in src:lapack,
by the way).

It could however take some time, because we are currently waiting for
NEW clearance from the most recent upload of src:openblas.

Best,

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



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


Bug#961725: libopenblas-dev: On some cpus, openmp and pthread dead-lock

2020-05-30 Thread Graham Inggs
Hmm, my last reply to this bug seems to have gone astray.



Bug#961725: libopenblas-dev: On some cpus, openmp and pthread dead-lock

2020-05-30 Thread Mo Zhou
> Just one question: did you try to rebuild it from source without
> changing anything? Maybe it’s just the rebuild that fixed it, and not
> the flag change.

Rebuilt without change: hang with libopenblas0-pthread

Rebuilt with USE_TLS=0: hang

Rebuilt with USE_SIMPLE_THREADED_LEVEL3=1: hang

Rebuilt with "-Wl,-Bsymbolic-functions" stripped: pass



Bug#956495: htpdate and FHS

2020-05-30 Thread Thiago Andrade
Hello guys,

I hadn't really noticed that htpdate is following the FHS[1] and I don't
see a problem with that.
The message could really be improved, maybe I can do this with a
preinst, I will test to see if it works.
So in my view this bug can be closed I don't know if you agree?

[1] https://www.debian.org/doc/packaging-manuals/fhs/fhs-3.0.txt

Best regards,

Thiago Andrade

-- 
...
⢀⣴⠾⠻⢶⣦⠀ Thiago Andrade Marques
⣾⠁⢰⠒⠀⣿⡁ GPG: 4096R/F8CDB08B
⢿⡄⠘⠷⠚⠋⠀ GPG Fingerprint: 1D38 EE3C 624F 955C E1FA  3C85 5A30 3591 F8CD B08B
⠈⠳⣄ 



Bug#953745: proftpd-dfsg 1.3.5b-4+deb9u5 flagged for acceptance

2020-05-30 Thread Adam D Barratt
package release.debian.org
tags 953745 = stretch pending
thanks

Hi,

The upload referenced by this bug report has been flagged for acceptance into 
the proposed-updates queue for Debian stretch.

Thanks for your contribution!

Upload details
==

Package: proftpd-dfsg
Version: 1.3.5b-4+deb9u5

Explanation: fix handling SSH_MSG_IGNORE packets



Bug#961725: libopenblas-dev: On some cpus, openmp and pthread dead-lock

2020-05-30 Thread Graham Inggs
Hi

I was able to reproduce this in Ubuntu 20.04 on i7-2600 with the
Rscript -e "example(solve)"
test case.  Rebuilding with
export DEB_LDFLAGS_MAINT_STRIP="-Wl,-Bsymbolic-functions"
in debian/rules solved it for me.

On Sat, 30 May 2020 at 09:15, Sébastien Villemot  wrote:
> Just one question: did you try to rebuild it from source without
> changing anything? Maybe it’s just the rebuild that fixed it, and not
> the flag change.

I confirm that a no-change rebuild had no effect.

I suspect this is the same problem that was discovered in LP: #1860601
[1], but I was unable to reproduce it locally.
I'll take care of fixing this in Ubuntu Groovy and SRU for Ubuntu Focal.

Could we get this fixed in Debian?  At worst, it should be a no-op in
Debian, and should someone try rebuilding locally with -Bsymbolic-
functions they won't fall into this trap.

Regards
Graham


[1] https://pad.lv/1860601



Bug#961725: libopenblas-dev: On some cpus, openmp and pthread dead-lock

2020-05-30 Thread Mo Zhou


> Just one question: did you try to rebuild it from source without
> changing anything? Maybe it’s just the rebuild that fixed it, and not
> the flag change.

Rebuilt without change: hang with libopenblas0-pthread

Rebuilt with USE_TLS=0: hang

Rebuilt with USE_SIMPLE_THREADED_LEVEL3=1: hang

Rebuilt with "-Wl,-Bsymbolic-functions" stripped: pass



Bug#961803: libexif 0.6.21-5.1+deb10u3 flagged for acceptance

2020-05-30 Thread Adam D Barratt
package release.debian.org
tags 961803 = buster pending
thanks

Hi,

The upload referenced by this bug report has been flagged for acceptance into 
the proposed-updates queue for Debian buster.

Thanks for your contribution!

Upload details
==

Package: libexif
Version: 0.6.21-5.1+deb10u3

Explanation: security fixes [CVE-2020-13112 CVE-2020-13113 CVE-2020-13114]



Bug#961212: dpdk 18.11.8-1~deb10u1 flagged for acceptance

2020-05-30 Thread Adam D Barratt
package release.debian.org
tags 961212 = buster pending
thanks

Hi,

The upload referenced by this bug report has been flagged for acceptance into 
the proposed-updates queue for Debian buster.

Thanks for your contribution!

Upload details
==

Package: dpdk
Version: 18.11.8-1~deb10u1

Explanation: new upstream release



Bug#961439: clamav 0.102.3+dfsg-0+deb10u1 flagged for acceptance

2020-05-30 Thread Adam D Barratt
package release.debian.org
tags 961439 = buster pending
thanks

Hi,

The upload referenced by this bug report has been flagged for acceptance into 
the proposed-updates queue for Debian buster.

Thanks for your contribution!

Upload details
==

Package: clamav
Version: 0.102.3+dfsg-0+deb10u1

Explanation: new upstream release; security fixes [CVE-2020-3327 CVE-2020-3341]



Bug#961804: libexif 0.6.21-2+deb9u3 flagged for acceptance

2020-05-30 Thread Adam D Barratt
package release.debian.org
tags 961804 = stretch pending
thanks

Hi,

The upload referenced by this bug report has been flagged for acceptance into 
the proposed-updates queue for Debian stretch.

Thanks for your contribution!

Upload details
==

Package: libexif
Version: 0.6.21-2+deb9u3

Explanation: security fixes [CVE-2020-13112 CVE-2020-13113 CVE-2020-13114]



Bug#961019: libexif 0.6.21-5.1+deb10u2 flagged for acceptance

2020-05-30 Thread Adam D Barratt
package release.debian.org
tags 961019 = buster pending
thanks

Hi,

The upload referenced by this bug report has been flagged for acceptance into 
the proposed-updates queue for Debian buster.

Thanks for your contribution!

Upload details
==

Package: libexif
Version: 0.6.21-5.1+deb10u2

Explanation: security fixes [CVE-2020-12767 CVE-2020-0093]



Bug#960806: policyd-rate-limit 1.0.1.1-0+deb10u1 flagged for acceptance

2020-05-30 Thread Adam D Barratt
package release.debian.org
tags 960806 = buster pending
thanks

Hi,

The upload referenced by this bug report has been flagged for acceptance into 
the proposed-updates queue for Debian buster.

Thanks for your contribution!

Upload details
==

Package: policyd-rate-limit
Version: 1.0.1.1-0+deb10u1

Explanation: fix issues in accounting due to socket reuse



Bug#961020: libexif 0.6.21-2+deb9u2 flagged for acceptance

2020-05-30 Thread Adam D Barratt
package release.debian.org
tags 961020 = stretch pending
thanks

Hi,

The upload referenced by this bug report has been flagged for acceptance into 
the proposed-updates queue for Debian stretch.

Thanks for your contribution!

Upload details
==

Package: libexif
Version: 0.6.21-2+deb9u2

Explanation: security fixes [CVE-2016-6328 CVE-2017-7544 CVE-2018-20030 
CVE-2020-12767 CVE-2020-0093]



Bug#961514: lirc 0.10.1-6.2~deb10u1 flagged for acceptance

2020-05-30 Thread Adam D Barratt
package release.debian.org
tags 961514 = buster pending
thanks

Hi,

The upload referenced by this bug report has been flagged for acceptance into 
the proposed-updates queue for Debian buster.

Thanks for your contribution!

Upload details
==

Package: lirc
Version: 0.10.1-6.2~deb10u1

Explanation: fix conffile management



Bug#953763: node-minimist 1.2.0-1+deb10u1 flagged for acceptance

2020-05-30 Thread Adam D Barratt
package release.debian.org
tags 953763 = buster pending
thanks

Hi,

The upload referenced by this bug report has been flagged for acceptance into 
the proposed-updates queue for Debian buster.

Thanks for your contribution!

Upload details
==

Package: node-minimist
Version: 1.2.0-1+deb10u1

Explanation: fix prototype pollution [CVE-2020-7598]



Bug#961440: clamav 0.102.3+dfsg-0~deb9u1 flagged for acceptance

2020-05-30 Thread Adam D Barratt
package release.debian.org
tags 961440 = stretch pending
thanks

Hi,

The upload referenced by this bug report has been flagged for acceptance into 
the proposed-updates queue for Debian stretch.

Thanks for your contribution!

Upload details
==

Package: clamav
Version: 0.102.3+dfsg-0~deb9u1

Explanation: new upstream release; security fixes [CVE-2020-3327 CVE-2020-3341]



Bug#961579: erlang 19.2.1+dfsg-2+deb9u3 flagged for acceptance

2020-05-30 Thread Adam D Barratt
package release.debian.org
tags 961579 = stretch pending
thanks

Hi,

The upload referenced by this bug report has been flagged for acceptance into 
the proposed-updates queue for Debian stretch.

Thanks for your contribution!

Upload details
==

Package: erlang
Version: 19.2.1+dfsg-2+deb9u3

Explanation: fix use of weak TLS ciphers [CVE-2020-12872]



Bug#961883: RFS: rumur/2020.05.27-1 -- model checker for the Murphi language

2020-05-30 Thread Matthew Fernandez
Package: sponsorship-requests
Severity: normal

Dear mentors,

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

* Package name: rumur
   Version : 2020.05.27-1
   Upstream Author : Matthew Fernandez 
* URL : https://github.com/Smattr/rumur
* License : Unlicense
* Vcs : https://github.com/Smattr/rumur.git
   Section : devel

It builds those binary packages:

  rumur - model checker for the Murphi language

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

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

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

  dget -x 
https://mentors.debian.net/debian/pool/main/r/rumur/rumur_2020.05.27-1.dsc

Changes since the last upload:

   * New upstream release.

Regards,
Matthew


Bug#961881: haskell-time-compat FTBFS: debian/hlibrary.setup: No such file or directory

2020-05-30 Thread Adrian Bunk
Source: haskell-time-compat
Version: 1.9.3-1
Severity: serious
Tags: ftbfs

https://buildd.debian.org/status/package.php?p=haskell-time-compat=sid

...
dh_installdirs -A 
mkdir -p "."
CDBS WARNING:DEB_DH_STRIP_ARGS is deprecated since 0.4.85
CDBS WARNING:DEB_COMPRESS_EXCLUDE is deprecated since 0.4.85
. /usr/share/haskell-devscripts/Dh_Haskell.sh && \
make_setup_recipe
. /usr/share/haskell-devscripts/Dh_Haskell.sh && \
configure_recipe
Running debian/hlibrary.setup configure --ghc -v2 
--package-db=/var/lib/ghc/package.conf.d --prefix=/usr 
--libdir=/usr/lib/haskell-packages/ghc/lib --libexecdir=/usr/lib 
--builddir=dist-ghc --ghc-option=-optl-Wl\,-z\,relro 
--haddockdir=/usr/lib/ghc-doc/haddock/time-compat-1.9.3/ 
--datasubdir=time-compat --htmldir=/usr/share/doc/libghc-time-compat-doc/html/ 
--enable-library-profiling
/usr/share/haskell-devscripts/Dh_Haskell.sh: line 6: debian/hlibrary.setup: No 
such file or directory
make: *** [/usr/share/cdbs/1/class/hlibrary.mk:142: configure-ghc-stamp] Error 
127



Bug#961882: haskell-tagged FTBFS: hlibrary.setup: Encountered missing or private dependencies: template-haskell >=2.8 && <2.15

2020-05-30 Thread Adrian Bunk
Source: haskell-tagged
Version: 0.8.6-2
Severity: serious
Tags: ftbfs

https://buildd.debian.org/status/package.php?p=haskell-tagged=sid

...
make_setup_recipe
Running ghc --make Setup.lhs -o debian/hlibrary.setup
[1 of 1] Compiling Main ( Setup.lhs, Setup.o )
Linking debian/hlibrary.setup ...
. /usr/share/haskell-devscripts/Dh_Haskell.sh && \
configure_recipe
Running debian/hlibrary.setup configure --ghc -v2 
--package-db=/var/lib/ghc/package.conf.d --prefix=/usr 
--libdir=/usr/lib/haskell-packages/ghc/lib --libexecdir=/usr/lib 
--builddir=dist-ghc --ghc-option=-optl-Wl\,-z\,relro 
--haddockdir=/usr/lib/ghc-doc/haddock/tagged-0.8.6/ --datasubdir=tagged 
--htmldir=/usr/share/doc/libghc-tagged-doc/html/ --enable-library-profiling
Using Parsec parser
Configuring tagged-0.8.6...
CallStack (from HasCallStack):
  die', called at 
libraries/Cabal/Cabal/Distribution/Simple/Configure.hs:1022:20 in 
Cabal-3.0.1.0:Distribution.Simple.Configure
  configureFinalizedPackage, called at 
libraries/Cabal/Cabal/Distribution/Simple/Configure.hs:475:12 in 
Cabal-3.0.1.0:Distribution.Simple.Configure
  configure, called at libraries/Cabal/Cabal/Distribution/Simple.hs:625:20 in 
Cabal-3.0.1.0:Distribution.Simple
  confHook, called at 
libraries/Cabal/Cabal/Distribution/Simple/UserHooks.hs:65:5 in 
Cabal-3.0.1.0:Distribution.Simple.UserHooks
  configureAction, called at 
libraries/Cabal/Cabal/Distribution/Simple.hs:180:19 in 
Cabal-3.0.1.0:Distribution.Simple
  defaultMainHelper, called at 
libraries/Cabal/Cabal/Distribution/Simple.hs:116:27 in 
Cabal-3.0.1.0:Distribution.Simple
  defaultMain, called at Setup.lhs:7:10 in main:Main
hlibrary.setup: Encountered missing or private dependencies:
template-haskell >=2.8 && <2.15

make: *** [/usr/share/cdbs/1/class/hlibrary.mk:142: configure-ghc-stamp] Error 1



Bug#961880: makedumpfile: kdump-tools currently does not respect KDUMP_SYSCTL and cannot handle sysctl overrides on kdump boot

2020-05-30 Thread Guilherme G. Piccoli
Package: makedumpfile
Version: 1.6.7-2
Severity: normal

Dear Maintainers,

Kdump-tools currently has 2 issues related to sysctls:
(1) It doesn't respect KDUMP_SYSCTL, after some commit removes it partially - by
partially, it means it wasn't _removed_, but the feature does not work anymore.
(2) There's no way to control sysctls on kdump environment - it "inherits"
sysctl configuration of the host, which could be problematic specially in case
of hugepages setting as sysctl in the regular boot.

I've submitted a merge request with fixes/improvements for this situations,
see: https://salsa.debian.org/debian/makedumpfile/-/merge_requests/2

The patch series addresses (1) [first patch] and (2) [patches two and three]. We
changed the KDUMP_SYSCTL name to prevent confusion...the idea is to rename it to
KDUMP_PANIC_TRIGGERS since the goal for this configuration is to set the panic
options. Regarding (2), we make use of an initrd approach to override sysctls on
*kdump environment only*.

Appreciate reviews, thanks in advance!
Cheers,


Guilherme


-- System Information:
Debian Release: stretch/sid
Architecture: amd64 (x86_64)



Bug#961879: petsc: binary-all FTBFS

2020-05-30 Thread Adrian Bunk
Source: petsc
Version: 3.13.1+dfsg1-2
Severity: serious
Tags: ftbfs

https://buildd.debian.org/status/fetch.php?pkg=petsc=all=3.13.1%2Bdfsg1-2=1590861266=0

...
   dh_missing -i
dh_missing: warning: 
petsc3.13-real-debug/usr/lib/petscdir/petsc3.13/x86_64-linux-gnu-real-debug/lib/libpetsc_real.so.3.13.1
 exists in debian/tmp but is not installed to anywhere 
dh_missing: warning: 
petsc3.13-real-debug/usr/lib/petscdir/petsc3.13/x86_64-linux-gnu-real-debug/lib/libpetsc_real.so.3.13
 exists in debian/tmp but is not installed to anywhere 
dh_missing: warning: 
petsc3.13-real-debug/usr/lib/petscdir/petsc3.13/x86_64-linux-gnu-real-debug/lib/libpetsc_real.so
 exists in debian/tmp but is not installed to anywhere 
dh_missing: warning: 
petsc3.13-real-debug/usr/lib/petscdir/petsc3.13/x86_64-linux-gnu-real-debug/lib/pkgconfig/PETSc.pc
 exists in debian/tmp but is not installed to anywhere 
dh_missing: warning: 
petsc3.13-real-debug/usr/lib/petscdir/petsc3.13/x86_64-linux-gnu-real-debug/lib/petsc/conf/uninstall.py
 exists in debian/tmp but is not installed to anywhere 
dh_missing: warning: 
petsc3.13-real-debug/usr/lib/petscdir/petsc3.13/x86_64-linux-gnu-real-debug/lib/petsc/conf/reconfigure-x86_64-linux-gnu-real-debug.py
 exists in debian/tmp but is not installed to anywhere 
dh_missing: warning: 
petsc3.13-real-debug/usr/lib/petscdir/petsc3.13/x86_64-linux-gnu-real-debug/lib/petsc/conf/petscrules
 exists in debian/tmp but is not installed to anywhere 
dh_missing: warning: 
petsc3.13-real-debug/usr/lib/petscdir/petsc3.13/x86_64-linux-gnu-real-debug/lib/petsc/conf/configure-hash
 exists in debian/tmp but is not installed to anywhere 
dh_missing: warning: 
petsc3.13-real-debug/usr/lib/petscdir/petsc3.13/x86_64-linux-gnu-real-debug/lib/petsc/conf/test
 exists in debian/tmp but is not installed to anywhere 
dh_missing: warning: 
petsc3.13-real-debug/usr/lib/petscdir/petsc3.13/x86_64-linux-gnu-real-debug/lib/petsc/conf/test.common
 exists in debian/tmp but is not installed to anywhere 
dh_missing: warning: 
petsc3.13-real-debug/usr/lib/petscdir/petsc3.13/x86_64-linux-gnu-real-debug/lib/petsc/conf/rules
 exists in debian/tmp but is not installed to anywhere 
dh_missing: warning: 
petsc3.13-real-debug/usr/lib/petscdir/petsc3.13/x86_64-linux-gnu-real-debug/lib/petsc/conf/variables
 exists in debian/tmp but is not installed to anywhere 
dh_missing: warning: 
petsc3.13-real-debug/usr/lib/petscdir/petsc3.13/x86_64-linux-gnu-real-debug/lib/petsc/conf/petscvariables
 exists in debian/tmp but is not installed to anywhere 
dh_missing: warning: 
petsc3.13-real-debug/usr/lib/petscdir/petsc3.13/x86_64-linux-gnu-real-debug/lib/petsc/conf/modules/petsc/3.13.1
 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: libpetsc-complex-dev (0), libpetsc-complex3.13 (0), 
libpetsc-complex3.13-dbg (0), libpetsc-complex3.13-dev (0), libpetsc-real-dev 
(0), libpetsc-real3.13 (0), libpetsc-real3.13-dbg (0), libpetsc-real3.13-dev 
(0), libpetsc3.13-dev-common (3), libpetsc3.13-dev-examples (2), petsc-dev (0), 
petsc3.13-doc (1)
 * dh_installdocs: libpetsc-complex-dev (0), libpetsc-complex3.13 (0), 
libpetsc-complex3.13-dbg (0), libpetsc-complex3.13-dev (1), libpetsc-real-dev 
(0), libpetsc-real3.13 (0), libpetsc-real3.13-dbg (0), libpetsc-real3.13-dev 
(1), libpetsc3.13-dev-common (0), libpetsc3.13-dev-examples (0), petsc-dev (0), 
petsc3.13-doc (3)
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:136: binary-indep] Error 25



This is due to the following change in dh compat 13:

   -   The dh_missing command will now default to
   --fail-missing.  This can be reverted to a non-
   fatal warning by explicitly passing --list-missing
   like it was in compat 12.



Bug#961878: libuv1: autopkgtest regression: ./gyp_uv.py: No such file or directory

2020-05-30 Thread Paul Gevers
Source: libuv1
Version: 1.38.0-1
X-Debbugs-CC: debian...@lists.debian.org
Severity: serious
User: debian...@lists.debian.org
Usertags: regression

Dear maintainer(s),

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

   passfail
libuv1 from testing1.38.0-1
versioned deps [0] from testingfrom unstable
all others from testingfrom testing

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

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

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

Paul

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

https://ci.debian.net/data/autopkgtest/testing/amd64/libu/libuv1/5693343/log.gz

autopkgtest [04:08:19]: test run-tests: [---
creating makefile for tests
/tmp/autopkgtest-lxc.kbt8395b/downtmp/build.cIp/src/debian/tests/run-tests:
line 6: ./gyp_uv.py: No such file or directory
autopkgtest [04:08:19]: test run-tests: ---]



signature.asc
Description: OpenPGP digital signature


Bug#961877: miniupnpd: configure should not be called with --leasefile

2020-05-30 Thread Ryutaroh Matsumoto
Package: miniupnpd
Version: 2.1-6.1
Severity: minor

The current debian/rules has
>override_dh_auto_build:
>dh_auto_build -- CONFIG_OPTIONS="--igd2 --ipv6 --leasefile --vendorcfg 
> \
>--pcp-peer --portinuse"

At
https://github.com/miniupnp/miniupnp/issues/463#issuecomment-636299732
the upstream developer said
> In that context, I advise to disable lease file completely.

So it seems better not to use  --leasefile in Debian packaging.

Best regards, Ryutaroh Matsumoto



Bug#961875: r-cran-dplyr: please package version 1.0.0

2020-05-30 Thread Zack Weinberg
Package: r-cran-dplyr
Version: 0.8.5-1+b1
Severity: normal

Per https://cran.r-project.org/web/packages/dplyr/index.html the current
version of dplyr is 1.0.0; the most recent packaged version is 0.8.5.
Version 1.0.0 adds some valuable new features such as the ability to
create multiple new columns at once in mutate() and summarise().
Please package this version.

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

Kernel: Linux 5.6.0-1-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

Versions of packages r-cran-dplyr depends on:
ii  libc62.30-8
ii  libgcc-s110.1.0-2
ii  libstdc++6   10.1.0-2
ii  r-base-core [r-api-4.0]  4.0.0-3
ii  r-cran-assertthat0.2.1-2
ii  r-cran-bh1.66.0-1
ii  r-cran-ellipsis  0.3.1-1
ii  r-cran-glue  1.4.1-1
ii  r-cran-magrittr  1.5-6
ii  r-cran-pkgconfig 2.0.3-2
ii  r-cran-plogr 0.2.0-3
ii  r-cran-r62.4.1-2
ii  r-cran-rcpp  1.0.4.6-1+b1
ii  r-cran-rlang 0.4.6-1+b1
ii  r-cran-tibble3.0.1-1+b1
ii  r-cran-tidyselect1.1.0+dfsg-1

Versions of packages r-cran-dplyr recommends:
ii  r-cran-bit64   0.9-7-3+b1
ii  r-cran-data.table  1.12.8+dfsg-1+b1
ii  r-cran-hms 0.5.3-2
ii  r-cran-mass7.3-51.6-1+b1
ii  r-cran-rsqlite 2.2.0-1+b1
ii  r-cran-testthat2.3.2-2+b1
ii  r-cran-withr   2.2.0-2

Versions of packages r-cran-dplyr suggests:
ii  r-cran-broom0.5.6+dfsg-2
ii  r-cran-callr3.4.3-2
ii  r-cran-covr 3.5.0+dfsg-1+b1
ii  r-cran-crayon   1.3.4-5
ii  r-cran-dbi  1.1.0-3
ii  r-cran-dbplyr   1.4.3-2
ii  r-cran-ggplot2  3.3.0+dfsg-2
ii  r-cran-knitr1.28+dfsg-2
ii  r-cran-lubridate1.7.8-1+b1
ii  r-cran-mgcv 1.8-31-1+b1
ii  r-cran-purrr0.3.4-1+b1
ii  r-cran-readr1.3.1-1+b2
ii  r-cran-rmarkdown2.1+dfsg-4
ii  r-cran-rmysql   0.10.20-1+b1
ii  r-cran-rpostgresql  0.6-2+dfsg-2+b1

-- no debconf information



Bug#961874: Demote the dependency on Xfce libraries to suggests or recommends

2020-05-30 Thread Amr Ibrahim

Package: pragha

Version: 1.3.4-1

In Debian pragha depends on libxfce4ui-2-0 and libxfce4util7, however, 
according to upstream*, pragha is independent of Xfce and libxfce4ui is 
optional and not strictly required to run the app. So I think the 
depends is too strong especially when the app is installed in a non-Xfce 
environment. So please demote the Xfce libraries to suggests or 
recommends, whichever you see more appropriate.


* https://github.com/pragha-music-player/pragha



Bug#961872: debianutils: autopkgtest failure: output on stderr

2020-05-30 Thread Paul Gevers
Hi

On 30-05-2020 18:56, Paul Gevers wrote:
> I copied some of the output at the bottom of this report. You may want
> to have the allow-stderr restriction (or have run-parts write its name
> and copyright to stdout instead of stderr).

Oh, and the name of the test suggests you really should mark the test as
superficial (restriction).

Paul



signature.asc
Description: OpenPGP digital signature


Bug#961873: npm2deb: Both node-$module and node-$module-$version get created, with two copies of debian dir

2020-05-30 Thread Wookey
Package: npm2deb
Version: 0.3.0-4
Severity: important

Running npm2deb create npm-run
produced:
node-npm-run and node-npm-run-5.0.1

node-npm-run-5.0.1 contained the module source and a debian directory.
node-npm-run contained just a debian directory.

The contents of the two debian directories was identical except for the 
changelog file.
node-npm-run/debian/changelog was as expected:
node-npm-run (5.0.1-1) UNRELEASED; urgency=low

  * Initial release (Closes: #)

 -- Wookey   Sat, 30 May 2020 16:09:11 +


node-npm-run-5.0.1/debian/changelog had an extra copy of the stanza for the 
same version:
node-npm-run (5.0.1-1) UNRELEASED; urgency=medium

  *

 -- Wookey   Sat, 30 May 2020 16:09:20 +

node-npm-run (5.0.1-1) UNRELEASED; urgency=low

  * Initial release (Closes: #)

 -- Wookey   Sat, 30 May 2020 16:09:11 +


I did this with another package (angular-animate) and get exactly the 
equivalent results.



Bug#961738: RFS: dragengine/1.1 -- Drag[en]gine Game Engine

2020-05-30 Thread Roland Plüss

On 5/30/20 2:00 PM, Tobias Frost wrote:
> * Update to my hints list: There is a fox package, fox-1.6 [1]; you'll
> know for
> sure if it suitable…
>
> [1] https://tracker.debian.org/pkg/fox1.6
>
I've seen that. I need though fox1.7 since 1.6 is not compatible to 1.7
. There had been API breaking changes in 1.7 .

If this is a vital problem please tell me. It's not possible to remove
fox1.7 requirement unless various parts of the package are not build
(namely the basic crash recovery module, the gui launcher and the entire
IGDE).

-- 
Mit freundlichen Grüssen
Plüss Roland

Game Development and Game Engine Technologies https://dragondreams.ch



signature.asc
Description: OpenPGP digital signature


Bug#961872: debianutils: autopkgtest failure: output on stderr

2020-05-30 Thread Paul Gevers
Source: debianutils
Version: 4.11
X-Debbugs-CC: debian...@lists.debian.org
Severity: serious
User: debian...@lists.debian.org
Usertags: fails-always

Dear maintainer(s),

You recently added an autopkgtest to your package debianutils, great.
However, it fails. Currently this failure is blocking the migration to
testing [1]. Can you please investigate the situation and fix it?

I copied some of the output at the bottom of this report. You may want
to have the allow-stderr restriction (or have run-parts write its name
and copyright to stdout instead of stderr).

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

Paul

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

https://ci.debian.net/data/autopkgtest/testing/amd64/d/debianutils/5639505/log.gz

autopkgtest [15:08:08]: test smoke: [---
Debian run-parts program, version 4.11
Copyright (C) 1994 Ian Jackson, Copyright (C) 1996 Jeff Noxon.
Copyright (C) 1996,1997,1998,1999 Guy Maor
Copyright (C) 2002-2012 Clint Adams
This is free software; see the GNU General Public License version 2
or later for copying conditions.  There is NO warranty.
WARNING: tempfile is deprecated; consider using mktemp instead.
/tmp/file0eMflp
/usr/bin/sh
Debian ischroot, version 4.11Copyright (C) 2011 Aurelien Jarno
This is free software; see the GNU General Public License version 2
or later for copying conditions.  There is NO warranty.
autopkgtest [15:08:08]: test smoke: ---]
autopkgtest [15:08:08]: test smoke:  - - - - - - - - - - results - - - -
- - - - - -
smokeFAIL stderr: Debian run-parts program, version 4.11
autopkgtest [15:08:08]: test smoke:  - - - - - - - - - - stderr - - - -
- - - - - -
Debian run-parts program, version 4.11
Copyright (C) 1994 Ian Jackson, Copyright (C) 1996 Jeff Noxon.
Copyright (C) 1996,1997,1998,1999 Guy Maor
Copyright (C) 2002-2012 Clint Adams
This is free software; see the GNU General Public License version 2
or later for copying conditions.  There is NO warranty.
Debian ischroot, version 4.11Copyright (C) 2011 Aurelien Jarno
This is free software; see the GNU General Public License version 2
or later for copying conditions.  There is NO warranty.



signature.asc
Description: OpenPGP digital signature


Bug#961868: release.debian.org: RM: broccoli, broccoli-python, broccoli-ruby

2020-05-30 Thread Mattia Rizzolo
Control: reassign -1 ftp.debian.org
Control: clone -1 -2 -3
Control: retitle -1 RM: broccoli -- ROM; deprecated
Control: retitle -2 RM: broccoli-python -- ROM; deprecated
Control: retitle -3 RM: broccoli-ruby -- ROM; deprecated
Control: block -1 by -2 -3

On Sat, May 30, 2020 at 06:00:34PM +0200, Hilko Bengen wrote:
> Package: release.debian.org
> 
> Please remove broccoli, broccoli-python, broccoli-ruby from unstable.
> These packages have been deprecated upstream.

removals from unstable are handled by the ftp masters, reassigning (and
retitling correctly, they like one bug per source package).

-- 
regards,
Mattia Rizzolo

GPG Key: 66AE 2B4A FCCF 3F52 DA18  4D18 4B04 3FCD B944 4540  .''`.
More about me:  https://mapreri.org : :'  :
Launchpad user: https://launchpad.net/~mapreri  `. `'`
Debian QA page: https://qa.debian.org/developer.php?login=mattia  `-


signature.asc
Description: PGP signature


Bug#961869: breezy breaks breezy-loom autopkgtest: copy_content_into() got an unexpected keyword argument 'tag_selector'

2020-05-30 Thread Paul Gevers
Source: breezy, breezy-loom
Control: found -1 breezy/3.1~alpha1-1
Control: found -1 breezy-loom/3.0.0-2
Severity: serious
Tags: sid bullseye
X-Debbugs-CC: debian...@lists.debian.org
User: debian...@lists.debian.org
Usertags: breaks needs-update

Dear maintainer(s),

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

   passfail
breezy from testing3.1~alpha1-1
breezy-loomfrom testing3.0.0-2
all others from testingfrom testing

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

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

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

Paul

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

https://ci.debian.net/data/autopkgtest/testing/amd64/b/breezy-loom/5693342/log.gz

==
ERROR: breezy.plugins.loom.tests.blackbox.TestPull.test_pull
--
Traceback (most recent call last):
testtools.testresult.real._StringException: log: {{{
4.059  creating repository in
file:///tmp/testbzr-shkp97u6.tmp/breezy.plugins.loom.tests.blackbox.TestPull.test_pull/work/source/.bzr/.
4.062  creating branch  in
file:///tmp/testbzr-shkp97u6.tmp/breezy.plugins.loom.tests.blackbox.TestPull.test_pull/work/source/
4.069  trying to create missing lock
'/tmp/testbzr-shkp97u6.tmp/breezy.plugins.loom.tests.blackbox.TestPull.test_pull/work/source/.bzr/checkout/dirstate'
4.069  opening working tree
'/tmp/testbzr-shkp97u6.tmp/breezy.plugins.loom.tests.blackbox.TestPull.test_pull/work/source'
4.080  preparing to commit
INFO  Committing to:
/tmp/testbzr-shkp97u6.tmp/breezy.plugins.loom.tests.blackbox.TestPull.test_pull/work/source/
4.082  Selecting files for commit with filter None
INFO  Committed revision 1.
4.092  Committed revid
b'jran...@example.com-20200530040825-nuhp6c1o3icnt5w1' as revno 1.
4.094  run brz: ['loomify', 'source']
4.094  breezy version: 3.1a1
4.094  brz arguments: ['loomify', 'source']
4.106  opening working tree
'/tmp/testbzr-shkp97u6.tmp/breezy.plugins.loom.tests.blackbox.TestPull.test_pull/work/source'
4.122  opening working tree
'/tmp/testbzr-shkp97u6.tmp/breezy.plugins.loom.tests.blackbox.TestPull.test_pull/work/source'
4.131  creating repository in
file:///tmp/testbzr-shkp97u6.tmp/breezy.plugins.loom.tests.blackbox.TestPull.test_pull/work/target/.bzr/.
4.135  Using fetch logic to copy between
CHKInventoryRepository('file:///tmp/testbzr-shkp97u6.tmp/breezy.plugins.loom.tests.blackbox.TestPull.test_pull/work/source/.bzr/repository/')(RepositoryFormat2a())
and
CHKInventoryRepository('file:///tmp/testbzr-shkp97u6.tmp/breezy.plugins.loom.tests.blackbox.TestPull.test_pull/work/target/.bzr/repository/')(RepositoryFormat2a())
4.135  fetching: 
4.149  creating branch  in
file:///tmp/testbzr-shkp97u6.tmp/breezy.plugins.loom.tests.blackbox.TestPull.test_pull/work/target/
}}}

Traceback (most recent call last):
  File
"/usr/lib/python3/dist-packages/breezy/plugins/loom/tests/blackbox.py",
line 622, in test_pull
tree.controldir.sprout('target')
  File "/usr/lib/python3/dist-packages/breezy/bzr/bzrdir.py", line 436,
in sprout
result_branch = source_branch.sprout(
  File "/usr/lib/python3/dist-packages/breezy/branch.py", line 1233, in
sprout
self.copy_content_into(
  File "/usr/lib/python3/dist-packages/breezy/branch.py", line 1275, in
copy_content_into
return InterBranch.get(self, destination).copy_content_into(
TypeError: copy_content_into() got an unexpected keyword argument
'tag_selector'



signature.asc
Description: OpenPGP digital signature


Bug#961867: python3?-talloc multiarch support is broken because of the dependency on python

2020-05-30 Thread Francois Gouget
Package: python-talloc
Version: 2.1.14-2
Severity: normal

Dear Maintainer,

python-talloc is 'multiarch: same' but the i386 package is not coinstallable
with the amd64 one because of their python dependency.

The issue is that python-talloc:i386 depends on python:i386, while
python-talloc:amd64 depends on python:amd64. But python is multiarch
allowed and this causes a conflict when trying to install both i386 and
amd64.

python3-talloc 2.3.0-5 has the same issue in Debian Testing but with
python3 instead of python.

Maybe what was intended is to have a python3:any dependency instead of a
regular python3 one? So this would make it:

Depends: libtalloc2 (= 2.3.0-5), python3:any (<< 3.9), python3:any (>= 3.8~), 
libc6 (>= 2.4), libpython3.8 (>= 3.8.2)

Unfortunately I don't know enough about python3-talloc to know if that would 
make sense. This multiarch howto section seems particularly relevant:
https://wiki.debian.org/Multiarch/HOWTO#When_to_use_:native_and_when_to_use_:any.3F

The impact is that this prevents Wine from using the libnetapi
library for 32-bit Windows applications because libnetapi is part of
samba-libs, which depends on python3-talloc.


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

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

Versions of packages python-talloc depends on:
ii  libc6 2.28-10
ii  libpython2.7  2.7.16-2+deb10u1
ii  libtalloc22.1.14-2
ii  python2.7.16-1

python-talloc recommends no packages.

python-talloc suggests no packages.

-- no debconf information



Bug#961868: release.debian.org: RM: broccoli, broccoli-python, broccoli-ruby

2020-05-30 Thread Hilko Bengen
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: rm

Please remove broccoli, broccoli-python, broccoli-ruby from unstable.
These packages have been deprecated upstream.

Cheers,
-Hilkoü



Bug#961838: s390x 5.6.0 kernel unusable on qemu-system-s390x TCG

2020-05-30 Thread Ryan Finnie
On 5/29/20 10:59 PM, Ryan Finnie wrote:
> Package: linux-image-5.6.0-2-s390x
> Source: linux
> Version: 5.6.14-1
> 
> 5.5 worked correctly:
> 
> # qemu-system-s390x -M s390-ccw-virtio -cpu max -m 512 -kernel 
> vmlinuz-5.5.0-0.bpo.2-s390x -display none -serial mon:stdio
> qemu-system-s390x: warning: 'msa5-base' requires 'kimd-sha-512'.
> qemu-system-s390x: warning: 'msa5-base' requires 'klmd-sha-512'.
> KASLR disabled: CPU has no PRNG
> [1.617782] Linux version 5.5.0-0.bpo.2-s390x 
> (debian-ker...@lists.debian.org) (gcc version 8.3.0 (Debian 8.3.0-6)) #1 SMP 
> Debian 5.5.17-1~bpo10+1 (2020-04-23)
> [1.618669] setup: Linux is running under KVM in 64-bit mode
> [1.619472] setup: The maximum memory size is 512MB
> [1.620515] cpu: 1 configured CPUs, 0 standby CPUs
> [...]
> 
> But 5.6 appears to stop immediately:
> 
> # qemu-system-s390x -M s390-ccw-virtio -cpu max -m 512 -kernel 
> vmlinuz-5.6.0-2-s390x -display none -serial mon:stdio
> qemu-system-s390x: warning: 'msa5-base' requires 'kimd-sha-512'.
> qemu-system-s390x: warning: 'msa5-base' requires 'klmd-sha-512'.
> KASLR disabled: CPU has no PRNG
> # echo $?
> 0

Sorry, forgot to mention that I had also tested Ubuntu's vanilla-ish
5.6.14 kernel build
(https://kernel.ubuntu.com/~kernel-ppa/mainline/v5.6.14/), and that
works correctly, so I'm not sure what to make of that.



signature.asc
Description: OpenPGP digital signature


Bug#958277: simple-cdd: Resulting Install CD asks for questions answered in the profiles/NAME.x files

2020-05-30 Thread Vagrant Cascadian
On 2020-04-30, Vagrant Cascadian wrote:
> On 2020-04-29, Buck wrote:
>> One difference is you wrote "simple-cdd --locale=en_CH --keyboard=us"
>> but I used "build-simple-cdd --locale=en_CH --keyboard=us" and I think
>> that was just a typo right?  Anyway I also did it your way and the
>> result was the same.
>
> It should make no difference, simple-cdd and build-simple-cdd are
> symlinks to the same file.
>
>
>> So it's looking like a bug.  I will do more testing if you want, including a 
>> new images/ directory.
>
> It sounds like I need to test it for myself at this point and see if I
> can reproduce the issue(s), so maybe best to wait until I get that
> chance. It may take me a week or so.

Sorry it took so long to follow up on this.

So, when I run "simple-cdd --locale=en_CH --keyboard=us" I get a working
installer image that asks which locale to use, presenting text
suggesting what the problem is:

  There is no locale defined for the combination of language and country
  you have selected. ...

When I build an image with "simple-cdd --locale=en_US --keyboard=us" it
skips the question prompting for language, as expected.


So, you need to provide values to debian-installer that are supported by
debian-installer:

  https://www.debian.org/releases/stable/amd64/apbs04.en.html#preseed-l10n

From the looks of it, locales present in /etc/locale.gen should be
supported in general.

I do need to explore using the auto-install/enable=true a.k.a. auto=true
parameter in simple-cdd, or moving simple-cdd to initrd preseeding,
both of which would allow preseeding country/language/keyboard settings
through a preseed file, and possibly allow arbitrary selection of
country and language.


live well,
  vagrant


signature.asc
Description: PGP signature


Bug#961866: ITP: gztool -- gzip-compressed file indexer

2020-05-30 Thread Stephen Kitt
Package: wnpp
Severity: wishlist
Owner: Stephen Kitt 

* Package name: gztool
  Version : 0.11.2
  Upstream Author : Roberto S. Galende
* URL : https://github.com/circulosmeos/gztool/
* License : zlib
  Programming Lang: C
  Description : gzip-compressed file indexer

 gztool indexes gzip-compressed files, allowing them to be accessed
 randomly (instead of from the beginning). It can index existing
 files, which takes as much time as decompressing the file entirely;
 it can also compress and decompress files itself, creating optimised
 indexes as it goes.
 .
 Other features include:
   - watch and index a gzip-compressed file as it is created;
   - partially extract a gzip-compressed file;
   - tail a gzip-compressed file (including follow mode).



Bug#961857: reproducible-check: incomprehensive and too good results

2020-05-30 Thread Jakub Wilk

* Holger Levsen , 2020-05-30, 16:23:

on a sid system I get this when running reproducible-check from devscripts:

$ reproducible-check

[...]

72/3141 (2.29%) of installed binary packages are unreproducible.
user@talk:~$ dpkg -l | wc -l
1472
user@talk:~$

IOW, I have 1472 packages installed, yet reproducible-check claims 
72/3141 of installed binary packages are unreproducible.


This doesn't match up.

Then, I'm also not sure if I see 72 packages in the output above :)


Does the attached patch help?

--
Jakub Wilk
diff --git a/scripts/reproducible-check b/scripts/reproducible-check
index b18adc75..b1d2633f 100755
--- a/scripts/reproducible-check
+++ b/scripts/reproducible-check
@@ -155,8 +155,8 @@ class ReproducibleCheck:
 
 @staticmethod
 def output_by_source(unreproducible, installed):
-num_installed = sum(len(x) for x in installed.keys())
-num_unreproducible = sum(len(x) for x in unreproducible.keys())
+num_installed = sum(len(x) for x in installed.values())
+num_unreproducible = sum(len(x) for x in unreproducible.values())
 default_architecture = apt.apt_pkg.config.find('APT::Architecture')
 
 for key, binaries in sorted(unreproducible.items()):


Bug#961106: Info received (Bug#961106: Acknowledgement (Bug for `telegram-desktop'))

2020-05-30 Thread morteza jamareh
Hi,
I had attached the screenshot...
We can't even open a mtproxy on my telegram application. We tested on more
that 5 separated cases,
Could you resolve that?


On Sat, May 23, 2020 at 12:39 PM Debian Bug Tracking System <
ow...@bugs.debian.org> wrote:

> Thank you for the additional information you have supplied regarding
> this Bug report.
>
> This is an automatically generated reply to let you know your message
> has been received.
>
> Your message is being forwarded to the package maintainers and other
> interested parties for their attention; they will reply in due course.
>
> Your message has been sent to the package maintainer(s):
>  Nicholas Guriev 
>
> If you wish to submit further information on this problem, please
> send it to 961...@bugs.debian.org.
>
> Please do not send mail to ow...@bugs.debian.org unless you wish
> to report a problem with the Bug-tracking system.
>
> --
> 961106: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=961106
> Debian Bug Tracking System
> Contact ow...@bugs.debian.org with problems
>


Bug#961848: photoflare: segfaults when trying to use Colour Picker

2020-05-30 Thread Bartosz Fenski
Package: photoflare
Version: 1.6.4-1
Severity: important

Dear Maintainer,

* What led up to the situation?

Simply trying to use Colour Picker.

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

It's so easily reproducible that you can test it even with newly created
blank picture.

* What was the outcome of this action?

[1]77137 segmentation fault  photoflare

* What outcome did you expect instead?

I was expecting change of used colour.


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

Kernel: Linux 5.6.0-2-amd64 (SMP w/4 CPU cores)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=pl_PL.UTF-8, LC_CTYPE=pl_PL.UTF-8 (charmap=UTF-8), 
LANGUAGE=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 photoflare depends on:
ii  libc6   2.30-8
ii  libgcc-s1   10.1.0-3
ii  libgomp110.1.0-3
ii  libgraphicsmagick++-q16-12  1.4+really1.3.35-1
ii  libqt5core5a5.12.5+dfsg-10
ii  libqt5gui5  5.12.5+dfsg-10
ii  libqt5network5  5.12.5+dfsg-10
ii  libqt5printsupport5 5.12.5+dfsg-10
ii  libqt5widgets5  5.12.5+dfsg-10
ii  libstdc++6  10.1.0-3
ii  qt5-image-formats-plugins   5.12.5-1

photoflare recommends no packages.

photoflare suggests no packages.

-- no debconf information



Bug#961865: picard-tools needs a source-only upload.

2020-05-30 Thread peter green

Package: picard-tools
Version: 2.18.25+dfsg-3
Severity: serious

The release team have decreed that non-buildd binaries can no longer migrate to 
testing, please make a source-only upload so your package can migrate.



Bug#961864: debrebuild: creates wrong commandline for binNMUs

2020-05-30 Thread Holger Levsen
Package: devscripts
Version: 2.20.3
Severity: normal

Dear Maintainer,

debrebuild creates wrong commandlines for binNMU, because the source field
in .buildinfo files looks different for binNMUs than normal uploads.

Normal uploads have these entries:

Source: libqcow
Version: 20181227-1.1

binNMUs these:

Source: libqcow (20181227-1.1)
Version: 20181227-1.1+b1

and then debrebuilds creates instructions like these:

"And then build your package:

dpkg-source -x ./libqcow (20181227-1.1)_20181227-1.1+b1.dsc
" and similarily the constructed sbuild commandline refers to 
./libqcow (20181227-1.1)_20181227-1.1+b1.dsc which is not a legit filename here.


-- 
cheers,
Holger

---
   holger@(debian|reproducible-builds|layer-acht).org
   PGP fingerprint: B8BF 5413 7B09 D35C F026 FE9D 091A B856 069A AA1C

Dance like no one's watching. Encrypt like everyone is.


signature.asc
Description: PGP signature


Bug#961863: zatacka: Depends/Build-Depends on cruft package ttf-dejavu-core

2020-05-30 Thread Daniel Schepler
Package: zatacka
Version: 0.1.8-5.2
Severity: serious

Currently, src:zatacka Build-Depends on ttf-dejavu and the binary
package Depends on ttf-dejavu-core.  However, src:fonts-dejavu dropped
these packages as of 2.37-2; so it's currently only possible to
install the package by using obsolete packages in sid, and once 2.37-2
migrates to testing, the packages will become uninstallable.
-- 
Daniel Schepler



Bug#961862: debrebuild: should assemble the source for binNMUs

2020-05-30 Thread Holger Levsen
package: devscripts
Version: 2.20.3
Severity: normal
x-debbugs-cc: reproducible-bui...@alioth-lists.debian.net

Dear Maintainer,

TTBOMK currently there is no tool to assemble the source for a binNMU. The 
source for a binNMU has do be assembled like this:

- take the normal source package and unpack it
- extract the d/changelog stanza from the .buildinfo file in question and
  concatenate that with d/changelog from the source package.
- use dpkg-source to build the source package.

It would be great if debrebuild would this if instructed to.

"#961861 «debrebuild: should (optionally) download the source too»" is a
blocker/requirement to fix this bug.


-- 
cheers,
Holger

---
   holger@(debian|reproducible-builds|layer-acht).org
   PGP fingerprint: B8BF 5413 7B09 D35C F026 FE9D 091A B856 069A AA1C

"... the premise [is] that privacy is about hiding a wrong. It's not.
 Privacy is an inherent human right, and a requirement for maintaining
 the human condition with dignity and respect." (Bruce Schneier)


signature.asc
Description: PGP signature


Bug#961860: make: Broken symlinks: /usr/bin/gmake, /usr/share/man/man1/gmake.1.gz

2020-05-30 Thread Peter Wienemann
Package: make
Version: 4.3-1
Severity: normal

Dear maintainer,

piuparts reports the following problem:

ERROR: WARN: Broken symlinks:
  /usr/bin/gmake -> /make (make)
  /usr/share/man/man1/gmake.1.gz -> /make.1.gz (make)

Peter

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



Bug#961861: debrebuild: should (optionally) download the source too

2020-05-30 Thread Holger Levsen
Package: devscripts
Version: 2.20.3
Severity: normal

Dear Maintainer,

even though current .buildinfo files in Debian don't contain the hashes of the
source package (as we mandated in our original design) it would be great if
debrebuild could, at least optionally also download the source packages.

The .buildinfo file contains the name of the source and the version, so this 
should be easy.


-- 
cheers,
Holger

---
   holger@(debian|reproducible-builds|layer-acht).org
   PGP fingerprint: B8BF 5413 7B09 D35C F026 FE9D 091A B856 069A AA1C

"... the premise [is] that privacy is about hiding a wrong. It's not.
 Privacy is an inherent human right, and a requirement for maintaining
 the human condition with dignity and respect." (Bruce Schneier)


signature.asc
Description: PGP signature


Bug#961738: RFS: dragengine/1.1 -- Drag[en]gine Game Engine

2020-05-30 Thread Tobias Frost
On Sat, May 30, 2020 at 03:08:21PM +0200, Roland Plüss wrote:
> 
> On 5/30/20 2:00 PM, Tobias Frost wrote:
> > * Update to my hints list: There is a fox package, fox-1.6 [1]; you'll
> > know for
> > sure if it suitable…
> >
> > [1] https://tracker.debian.org/pkg/fox1.6
> >
> I've seen that. I need though fox1.7 since 1.6 is not compatible to 1.7
> . There had been API breaking changes in 1.7 .
> 
> If this is a vital problem please tell me. It's not possible to remove
> fox1.7 requirement unless various parts of the package are not build
> (namely the basic crash recovery module, the gui launcher and the entire
> IGDE).

Yes, this gonna be a problem due to the Debian Policy about embedded code
copies [1].

I see those options:
- talk to the fox-1.6 maintainer about updating the package to 1.7.
  (though I see that they generally stick to released versions and 1.7.* seems
  to be only development snapshots; a question to ask: is the 1.7 ABI stable 
already?)
- make the features optional that requires 1.7
- use only 1.6 features (listed for completeness, as you said you can't)

[1] https://www.debian.org/doc/debian-policy/ch-source.html#embedded-code-copies

-- 
tobi


signature.asc
Description: PGP signature


Bug#961859: reproducible-check: should not show results on Ubuntu and other distros != Debian

2020-05-30 Thread Holger Levsen
Package: devscripts
Version: 2.20.3
Severity: normal
x-debbugs-cc: reproducible-bui...@alioth-lists.debian.net


hi, 

reproducible-check should not show any results on Ubuntu as Ubuntu is not
involved in Reproducible Builds and not doing any efforts. TTBOMK they also
don't publish their .buildinfo files so doing reproducible builds of 
Canonical released Ubuntu packages is also not possible at the moment.

Thus reproducible-check should not show results when running on Ubuntu
or actually any other distro != Debian.


-- 
cheers,
Holger

---
   holger@(debian|reproducible-builds|layer-acht).org
   PGP fingerprint: B8BF 5413 7B09 D35C F026 FE9D 091A B856 069A AA1C

There are no jobs on a dead planet.


signature.asc
Description: PGP signature


Bug#961858: reproducible-check: should be explicit about just showing CI results

2020-05-30 Thread Holger Levsen
Package: devscripts
Version: 2.20.3
Severity: normal

hi,

reproducible-check shows how many of the installed binary packages are
(un)reproducible in our current CI framework, that is these results only
show the theoretical reproducibility of these Debian pacakges, they 
*do not* however show any real values. So this should be made very clear.


-- 
cheers,
Holger

---
   holger@(debian|reproducible-builds|layer-acht).org
   PGP fingerprint: B8BF 5413 7B09 D35C F026 FE9D 091A B856 069A AA1C


signature.asc
Description: PGP signature


Bug#961856: kodi: baseline violation on i386

2020-05-30 Thread Adrian Bunk
Source: kodi
Version: 2:18.7+dfsg1-1
Severity: serious
Tags: patch

SSE is not part of the i386 baseline.
A fix is attached.
Description: The baseline of the i386 port does not include SSE
 SSE2 is always enabled on amd64.
Author: Adrian Bunk 

--- kodi-18.7+dfsg1.orig/cmake/scripts/linux/ArchSetup.cmake
+++ kodi-18.7+dfsg1/cmake/scripts/linux/ArchSetup.cmake
@@ -13,7 +13,7 @@ else()
   elseif(CPU MATCHES "i.86")
 set(ARCH i486-linux)
 set(NEON False)
-add_options(CXX ALL_BUILDS "-msse")
+#add_options(CXX ALL_BUILDS "-msse")
   elseif(CPU STREQUAL arm1176jzf-s)
 set(ARCH arm)
 set(NEON False)
--- kodi-18.7+dfsg1.orig/xbmc/cores/AudioEngine/CMakeLists.txt
+++ kodi-18.7+dfsg1/xbmc/cores/AudioEngine/CMakeLists.txt
@@ -137,11 +137,11 @@ endif()
 
 core_add_library(audioengine)
 target_include_directories(${CORE_LIBRARY} PRIVATE ${CMAKE_CURRENT_SOURCE_DIR})
-if(NOT CORE_SYSTEM_NAME STREQUAL windows AND NOT CORE_SYSTEM_NAME STREQUAL 
windowsstore)
-  if(HAVE_SSE)
-target_compile_options(${CORE_LIBRARY} PRIVATE -msse)
-  endif()
-  if(HAVE_SSE2)
-target_compile_options(${CORE_LIBRARY} PRIVATE -msse2)
-  endif()
-endif()
+#if(NOT CORE_SYSTEM_NAME STREQUAL windows AND NOT CORE_SYSTEM_NAME STREQUAL 
windowsstore)
+#  if(HAVE_SSE)
+#target_compile_options(${CORE_LIBRARY} PRIVATE -msse)
+#  endif()
+#  if(HAVE_SSE2)
+#target_compile_options(${CORE_LIBRARY} PRIVATE -msse2)
+#  endif()
+#endif()
--- kodi-18.7+dfsg1.orig/xbmc/rendering/CMakeLists.txt
+++ kodi-18.7+dfsg1/xbmc/rendering/CMakeLists.txt
@@ -4,12 +4,12 @@ set(HEADERS RenderSystem.h
 RenderSystemTypes.h)
 
 core_add_library(rendering)
-if(NOT CORE_SYSTEM_NAME STREQUAL windows AND NOT CORE_SYSTEM_NAME STREQUAL 
windowsstore)
-  if(HAVE_SSE)
-target_compile_options(${CORE_LIBRARY} PRIVATE -msse)
-  endif()
-  if(HAVE_SSE2)
-target_compile_options(${CORE_LIBRARY} PRIVATE -msse2)
-  endif()
-endif()
+#if(NOT CORE_SYSTEM_NAME STREQUAL windows AND NOT CORE_SYSTEM_NAME STREQUAL 
windowsstore)
+#  if(HAVE_SSE)
+#target_compile_options(${CORE_LIBRARY} PRIVATE -msse)
+#  endif()
+#  if(HAVE_SSE2)
+#target_compile_options(${CORE_LIBRARY} PRIVATE -msse2)
+#  endif()
+#endif()
 
--- kodi-18.7+dfsg1.orig/xbmc/utils/CMakeLists.txt
+++ kodi-18.7+dfsg1/xbmc/utils/CMakeLists.txt
@@ -207,8 +207,8 @@ endif()
 
 core_add_library(utils)
 
-if(NOT CORE_SYSTEM_NAME STREQUAL windows AND NOT CORE_SYSTEM_NAME STREQUAL 
windowsstore)
-  if(HAVE_SSE2)
-target_compile_options(${CORE_LIBRARY} PRIVATE -msse2)
-  endif()
-endif()
+#if(NOT CORE_SYSTEM_NAME STREQUAL windows AND NOT CORE_SYSTEM_NAME STREQUAL 
windowsstore)
+#  if(HAVE_SSE2)
+#target_compile_options(${CORE_LIBRARY} PRIVATE -msse2)
+#  endif()
+#endif()


Bug#961857: reproducible-check: incomprehensive and too good results

2020-05-30 Thread Holger Levsen
Package: devscripts
Version: 2.20.3
x-debbugs-cc: reproducible-bui...@alioth-lists.debian.net

Hi,

on a sid system I get this when running reproducible-check from devscripts:

$ reproducible-check
alsa-lib (1.2.2-2.1) is unreproducible (libasound2) 

apt (2.1.5) is unreproducible (apt, apt-utils, libapt-pkg6.0) 

autogen (1:5.18.16-4) is unreproducible (libopts25) 

bind9 (1:9.16.2-3) is unreproducible (bind9-host, bind9-libs) 

binutils (2.34-8) is unreproducible (binutils, binutils-common, 
binutils-x86-64-linux-gnu, libbinutils, libctf-nobfd0, libctf0) 

boost1.67 (1.67.0-18) is unreproducible (libboost-date-time1.67.0, 
libboost-filesystem1.67.0, libboost-iostreams1.67.0, libboost-locale1.67.0, 
libboost-system1.67.0, libboost-thread1.67.0) 

emacs (1:26.3+1-2) is unreproducible (emacs-bin-common) 

gcc-8 (8.4.0-4) is unreproducible (gcc-8-base, libmpx2) 

gcc-9 (9.3.0-13) is unreproducible (cpp-9, g++-9, gcc-9, gcc-9-base, libasan5, 
libgcc-9-dev, libstdc++-9-dev) 

gettext (0.19.8.1-10) is unreproducible (gettext, gettext-base) 

guile-2.2 (2.2.7+1-5) is unreproducible (guile-2.2-libs) 

libtheora (1.1.1+dfsg.1-15) is unreproducible (libtheora0) 

libtommath (1.2.0-3) is unreproducible (libtommath1) 

libtool (2.4.6-14) is unreproducible (libltdl-dev, libltdl7) 

m4 (1.4.18-4) is unreproducible 

mariadb-10.3 (1:10.3.22-1) is unreproducible (libmariadb3) 

perl (5.30.2-1) is unreproducible (libperl5.30, perl, perl-base) 

pkg-config (0.29.2-1) is unreproducible 

python2.7 (2.7.18-1) is unreproducible (libpython2.7, libpython2.7-minimal, 
libpython2.7-stdlib, python2.7, python2.7-minimal) 

python3.8 (3.8.3-1) is unreproducible (libpython3.8, libpython3.8-minimal, 
libpython3.8-stdlib, python3.8, python3.8-minimal) 

sudo (1.9.0-1) is unreproducible 

volume-key (0.3.12-3.1) is unreproducible (libvolume-key1) 

webkit2gtk (2.28.2-2) is unreproducible (libjavascriptcoregtk-4.0-18, 
libwebkit2gtk-4.0-37) 
xorg-server (2:1.20.8-2) is unreproducible (xserver-xorg-core, 
xserver-xorg-legacy) 
72/3141 (2.29%) of installed binary packages are unreproducible.
user@talk:~$ dpkg -l | wc -l
1472
user@talk:~$ 

IOW, I have 1472 packages installed, yet reproducible-check claims 72/3141 of 
installed binary packages are unreproducible.

This doesn't match up.

Then, I'm also not sure if I see 72 packages in the output above :)

And finally and foremost, 97.71% reproducible packages seems to be a bit high.


-- 
cheers,
Holger

---
   holger@(debian|reproducible-builds|layer-acht).org
   PGP fingerprint: B8BF 5413 7B09 D35C F026 FE9D 091A B856 069A AA1C

There are no jobs on a dead planet.


signature.asc
Description: PGP signature


Bug#961855: lintian: Doesn't read profile

2020-05-30 Thread Christian Marillat
Package: lintian
Version: 2.78.0
Severity: normal

Dear Maintainer,

The contents of  ~/.config/lintian/lintianrc is :

LINTIAN_PROFILE = dmo

But the dmo profile is'nt read :

$ strace -fo log lintian 
W: kodi-pvr-argustv: bugs-field-does-not-refer-to-debian-infrastructure 
mailto:maril...@deb-multimedia.org

$ grep profiles log  
163139 stat("/usr/share/lintian/profiles/debian/main.profile", 
{st_mode=S_IFREG|0644, st_size=3082, ...}) = 0
163139 lstat("invalid-profile-name-in-build-profiles-field.desc", 
{st_mode=S_IFREG|0644, st_size=507, ...}) = 0
163139 stat("invalid-profile-name-in-build-profiles-field.desc", 
{st_mode=S_IFREG|0644, st_size=507, ...}) = 0
163139 lstat("invalid-restriction-formula-in-build-profiles-field.desc", 
{st_mode=S_IFREG|0644, st_size=327, ...}) = 0
163139 stat("invalid-restriction-formula-in-build-profiles-field.desc", 
{st_mode=S_IFREG|0644, st_size=327, ...}) = 0
163139 
stat("/usr/share/lintian/tags/i/invalid-profile-name-in-build-profiles-field.desc",
 {st_mode=S_IFREG|0644, st_size=507, ...}) = 0
163139 openat(AT_FDCWD, 
"/usr/share/lintian/tags/i/invalid-profile-name-in-build-profiles-field.desc", 
O_RDONLY|O_CLOEXEC) = 5
163139 
stat("/usr/share/lintian/tags/i/invalid-restriction-formula-in-build-profiles-field.desc",
 {st_mode=S_IFREG|0644, st_size=327, ...}) = 0
163139 openat(AT_FDCWD, 
"/usr/share/lintian/tags/i/invalid-restriction-formula-in-build-profiles-field.desc",
 O_RDONLY|O_CLOEXEC) = 5
163139 openat(AT_FDCWD, "/usr/share/lintian/profiles/debian/main.profile", 
O_RDONLY|O_CLOEXEC) = 5

The contents of /usr/share/lintian/profiles/dmo/main.profile id 

Profile: dmo/main
Extends: debian/main
Disable-Tags: bugs-field-does-not-refer-to-debian-infrastructure

Chirstian

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

Kernel: Linux 5.6.15 (SMP w/8 CPU cores)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), 
LANGUAGE=fr_FR.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages lintian depends on:
ii  binutils 2.34-8
ii  bzip21.0.8-3
ii  diffstat 1.63-1
ii  dpkg 1.19.7
ii  dpkg-dev 1.19.7
ii  file 1:5.38-5
ii  gettext  0.19.8.1-10
ii  gpg  2.2.20-1
ii  intltool-debian  0.35.0+20060710.5
ii  libapt-pkg-perl  0.1.36+b3
ii  libarchive-zip-perl  1.68-1
ii  libcapture-tiny-perl 0.48-1
ii  libclass-xsaccessor-perl 1.19-3+b4
ii  libclone-perl0.45-1
ii  libconfig-tiny-perl  2.24-1
ii  libcpanel-json-xs-perl   4.19-1
ii  libdevel-size-perl   0.83-1+b1
ii  libdigest-sha-perl   6.02-1+b2
ii  libdpkg-perl 1.19.7
ii  libemail-address-xs-perl 1.04-1+b2
ii  libemail-valid-perl  1.202-1
ii  libfile-basedir-perl 0.08-1
ii  libfile-find-rule-perl   0.34-1
ii  libfont-ttf-perl 1.06-1
ii  libhtml-parser-perl  3.72-5
ii  libio-async-loop-epoll-perl  0.20-1
ii  libio-async-perl 0.75-1
ii  libjson-maybexs-perl 1.004002-1
ii  liblist-compare-perl 0.53-1
ii  liblist-moreutils-perl   0.416-1+b5
ii  liblist-utilsby-perl 0.11-1
ii  libmoo-perl  2.004000-1
ii  libmoox-aliases-perl 0.001006-1
ii  libnamespace-clean-perl  0.27-1
ii  libpath-tiny-perl0.112-1
ii  libsereal-decoder-perl   4.011+ds-1
ii  libsereal-encoder-perl   4.011+ds-1
ii  libtext-levenshtein-perl 0.13-1
ii  libtimedate-perl 2.3300-1
ii  libtry-tiny-perl 0.30-1
ii  libtype-tiny-perl1.010001-1
ii  libunicode-utf8-perl 0.62-1+b1
ii  liburi-perl  1.76-2
ii  libxml-libxml-perl   2.0134+dfsg-2
ii  libxml-writer-perl   0.625-1
ii  libyaml-libyaml-perl 0.82+repack-1
ii  man-db   2.9.1-1
ii  patchutils   0.3.4-2+b1
ii  perl [libdigest-sha-perl]5.30.2-1
ii  t1utils  1.41-4
ii  xz-utils 5.2.4-1+b1

Versions of packages lintian recommends:
pn  libperlio-gzip-perl  

Versions of packages lintian suggests:
pn  binutils-multiarch 
ii  libtext-template-perl  1.58-1

-- no debconf information



Bug#961854: RM: iptables-optimizer -- RoQA; Depends on Python 2, dead upstream, unmaintained

2020-05-30 Thread Moritz Muehlenhoff
Package: ftp.debian.org
Severity: normal

Please remove iptables-optimizer. It depends on Python 2, the last upload was in
2016 (and so were the last upstream commits, the maintainer is also upstream)

Cheers,
Moritz



Bug#953745: stretch-pu: package proftpd-dfsg/1.3.5b-4+deb9u5

2020-05-30 Thread Hilmar Preuße

Am 28.05.2020 um 23:54 teilte Adam D. Barratt mit:
> On Tue, 2020-05-19 at 09:07 +0200, Hilmar Preuße wrote:

Hi Adam,

>> Anyway: I've uploaded the requested
>> change to Debian unstable yesterday. Is this sufficient to get deb9u5
>> into oldstable?
>>
> 
> Sure, please go ahead.
> 

I've uploaded proftpd-dfsg_1.3.5b-4+deb9u5 into the archive. Please process.

Thanks!

Hilmar
-- 
sigfault
#206401 http://counter.li.org



signature.asc
Description: OpenPGP digital signature


Bug#961853: micro crashes at startup

2020-05-30 Thread Nils Dagsson Moskopp
Package: micro
Version: 2.0.3-1~bpo10+1
Severity: grave
Justification: renders package unusable

Dear Maintainer,

a friend just suggested that I try the “micro” text editor.
I installed the software using “sudo apt-get install micro”.

I executed the command “micro” from a terminal. Instead of starting an 
editor, the terminal contents look all weird and only executing “reset” 
brings it into a usable state again. I see no text editor anywhere.

I managed to capture the error messages by redirecting the standard 
error to a file, which I have appended to this bug report.

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

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

Versions of packages micro depends on:
ii  libc6  2.28-10

Versions of packages micro recommends:
ii  xclip  0.13-1

micro suggests no packages.

-- no debconf information
unexpected fault address 0x80cda9e9
fatal error: fault
[signal SIGSEGV: segmentation violation code=0x1 addr=0x80cda9e9 pc=0x9b2896]

goroutine 1 [running]:
runtime.throw(0x9fa5fc, 0x5)
/usr/lib/go-1.11/src/runtime/panic.go:608 +0x70 fp=0x23d2de0 
sp=0x23d2dcc pc=0x52cb00
runtime.sigpanic()
/usr/lib/go-1.11/src/runtime/signal_unix.go:397 +0x1e4 fp=0x23d2e04 
sp=0x23d2de0 pc=0x542224
github.com/zyedidia/micro/internal/display.(*BufWindow).Relocate(0x2231d00, 
0x9b2215)
github.com/zyedidia/micro/internal/display/bufwindow.go:153 +0x126 
fp=0x23d2e40 sp=0x23d2e04 pc=0x9b2896
github.com/zyedidia/micro/internal/display.(*BufWindow).Resize(0x2231d00, 0x50, 
0x17)
github.com/zyedidia/micro/internal/display/bufwindow.go:57 +0x32 
fp=0x23d2e4c sp=0x23d2e40 pc=0x9b2242
github.com/zyedidia/micro/internal/action.(*BufPane).Resize(0x2068d20, 0x50, 
0x17)
:1 +0x3e fp=0x23d2e5c sp=0x23d2e4c pc=0x9dc17e
github.com/zyedidia/micro/internal/action.(*Tab).Resize(0x2231ce0)
github.com/zyedidia/micro/internal/action/tab.go:296 +0xd1 fp=0x23d2e8c 
sp=0x23d2e5c pc=0x9d5dd1
github.com/zyedidia/micro/internal/action.(*TabList).Resize(0x21ae820)
github.com/zyedidia/micro/internal/action/tab.go:92 +0x210 fp=0x23d2ec4 
sp=0x23d2e8c pc=0x9d5070
github.com/zyedidia/micro/internal/action.(*TabList).HandleEvent(0x21ae820, 
0xc85970, 0x21a4040)
github.com/zyedidia/micro/internal/action/tab.go:102 +0x1b8 
fp=0x23d2edc sp=0x23d2ec4 pc=0x9d5298
main.main()
github.com/zyedidia/micro/cmd/micro/micro.go:316 +0x5b2 fp=0x23d2fd0 
sp=0x23d2edc pc=0x9f6b02
runtime.main()
/usr/lib/go-1.11/src/runtime/proc.go:201 +0x289 fp=0x23d2ff0 
sp=0x23d2fd0 pc=0x52e619
runtime.goexit()
/usr/lib/go-1.11/src/runtime/asm_386.s:1324 +0x1 fp=0x23d2ff4 
sp=0x23d2ff0 pc=0x558771

goroutine 5 [syscall]:
os/signal.signal_recv(0x0)
/usr/lib/go-1.11/src/runtime/sigqueue.go:139 +0x157
os/signal.loop()
/usr/lib/go-1.11/src/os/signal/signal_unix.go:23 +0x1b
created by os/signal.init.0
/usr/lib/go-1.11/src/os/signal/signal_unix.go:29 +0x3d

goroutine 17 [select]:
github.com/zyedidia/tcell.(*tScreen).mainLoop(0x20dc420)
github.com/zyedidia/tcell/tscreen.go:1411 +0x166
created by github.com/zyedidia/tcell.(*tScreen).Init
github.com/zyedidia/tcell/tscreen.go:198 +0x623

goroutine 18 [IO wait]:
internal/poll.runtime_pollWait(0xa7a95fc0, 0x72, 0x5ae26a)
/usr/lib/go-1.11/src/runtime/netpoll.go:173 +0x4c
internal/poll.(*pollDesc).wait(0x21501d4, 0x72, 0xff01, 0xc85150, 0x5c60e5)
/usr/lib/go-1.11/src/internal/poll/fd_poll_runtime.go:85 +0x99
internal/poll.(*pollDesc).waitRead(0x21501d4, 0x2234001, 0x1000, 0x1000)
/usr/lib/go-1.11/src/internal/poll/fd_poll_runtime.go:90 +0x33
internal/poll.(*FD).Read(0x21501c0, 0x2234000, 0x1000, 0x1000, 0x0, 0x0, 0x0)
/usr/lib/go-1.11/src/internal/poll/fd_unix.go:169 +0x152
os.(*File).read(0x211df90, 0x2234000, 0x1000, 0x1000, 0x0, 0x0, 0x0)
/usr/lib/go-1.11/src/os/file_unix.go:249 +0x3e
os.(*File).Read(0x211df90, 0x2234000, 0x1000, 0x1000, 0x1000, 0x1000, 0x0)
/usr/lib/go-1.11/src/os/file.go:108 +0x52
github.com/zyedidia/tcell.(*tScreen).inputLoop(0x20dc420)
github.com/zyedidia/tcell/tscreen.go:1464 +0x9b
created by github.com/zyedidia/tcell.(*tScreen).Init
github.com/zyedidia/tcell/tscreen.go:199 +0x646

goroutine 9 [select]:
github.com/zyedidia/tcell.(*tScreen).PollEvent(0x20dc420, 0x23dd7e4, 0x21a4040)
github.com/zyedidia/tcell/tscreen.go:819 +0x97
main.main.func3()
github.com/zyedidia/micro/cmd/micro/micro.go:299 +0x33
created by main.main
github.com/zyedidia/micro/cmd/micro/micro.go:296 +0x4a1


Bug#961852: python-matrix-nio: autopkgtest failure: No module named 'matrix_nio'

2020-05-30 Thread Paul Gevers
Source: python-matrix-nio
Version: 0.11.2-2
X-Debbugs-CC: debian...@lists.debian.org
Severity: serious
User: debian...@lists.debian.org
Usertags: fails-always

Dear maintainer(s),

You recently added an autopkgtest to your package python-matrix-nio,
great. However, it fails. Currently this failure is blocking the
migration to testing [1]. Can you please investigate the situation and
fix it?

I copied some of the output at the bottom of this report. You're using
autodep8 to trigger the test, but it seems your package naming and
Python module name aren't aligned for autodep8. autodep8 recently
acquired a new feature that enables you to tell autode8 what the real
module name is that should be tested [2].

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

Paul

[1] https://qa.debian.org/excuses.php?package=python-matrix-nio
[2]
https://manpages.debian.org/unstable/autodep8/autodep8.1.en.html#PYTHON_PACKAGES

https://ci.debian.net/data/autopkgtest/testing/amd64/p/python-matrix-nio/5580919/log.gz

autopkgtest [15:19:47]: test autodep8-python3: set -e ; for py in
$(py3versions -r 2>/dev/null) ; do cd "$AUTOPKGTEST_TMP" ; echo "Testing
with $py:" ; $py -c "import matrix_nio; print(matrix_nio)" ; done
autopkgtest [15:19:47]: test autodep8-python3: [---
Testing with python3.8:
Traceback (most recent call last):
  File "", line 1, in 
ModuleNotFoundError: No module named 'matrix_nio'
autopkgtest [15:19:48]: test autodep8-python3: ---]



signature.asc
Description: OpenPGP digital signature


Bug#961851: make-dfsg breaks cross-toolchain-base autopkgtest: debian/kernelarch.make:5: *** empty variable name

2020-05-30 Thread Paul Gevers
Source: make-dfsg, cross-toolchain-base
Control: found -1 make-dfsg/4.3-1
Control: found -1 cross-toolchain-base/45
Severity: serious
Tags: sid bullseye
X-Debbugs-CC: debian...@lists.debian.org
User: debian...@lists.debian.org
Usertags: breaks needs-update

Dear maintainer(s),

With a recent upload of make-dfsg the autopkgtest of
cross-toolchain-base fails in testing when that autopkgtest is run with
the binary packages of make-dfsg from unstable. It passes when run with
only packages from testing. In tabular form:

   passfail
make-dfsg  from testing4.3-1
cross-toolchain-base   from testing45
all others from testingfrom testing

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

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

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

Paul

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

https://ci.debian.net/data/autopkgtest/testing/amd64/c/cross-toolchain-base/5687474/log.gz

autopkgtest [18:08:29]: test build: [---
Testing cross builds on amd64 ...
+ CROSS_ARCHS=ppc64el DEB_BUILD_OPTIONS=parallel=2 nopgo nolto
dpkg-buildpackage -d -b --no-sign
dpkg-buildpackage: info: source package cross-toolchain-base
dpkg-buildpackage: info: source version 45
dpkg-buildpackage: info: source distribution unstable
dpkg-buildpackage: info: source changed by Matthias Klose 
 dpkg-source --before-build .
dpkg-buildpackage: info: host architecture amd64
 fakeroot debian/rules clean
debian/kernelarch.make:5: *** empty variable name.  Stop.
dpkg-buildpackage: error: fakeroot debian/rules clean subprocess
returned exit status 2
autopkgtest [18:08:29]: test build: ---]



signature.asc
Description: OpenPGP digital signature


  1   2   >