Bug#954825: gnome-boxes: Segmentation fault when "+" → "Create a Virtual Machine…" is selected

[Cody Brownstein]

0735570466560, 
5085453315389036726, 140737488332958, 140737488332959, 140735570462592, 
140735570466560, -5085633227581253450, -5085461228906440522}, mask_was_saved = 
0}}, priv = {pad = {0x0, 0x0, 0x0, 0x0}, data = {prev = 0x0, cleanup = 0x0, 
canceltype = 0}}}
not_first_call = 0
#6  0x738952af in clone () at 
../sysdeps/unix/sysv/linux/x86_64/clone.S:95
No locals.

Thread 8 (Thread 0x7fff8e2f6700 (LWP 13660)):
#0  futex_wait_cancelable (private=0, expected=0, futex_word=0x557e30c8) at 
../sysdeps/unix/sysv/linux/futex-internal.h:80
__ret = -512
oldtype = 0
err = 
oldtype = 
err = 
__ret = 
resultvar = 
__arg4 = 
__arg3 = 
__arg2 = 
__arg1 = 
_a4 = 
_a3 = 
_a2 = 
_a1 = 
#1  __pthread_cond_wait_common (abstime=0x0, clockid=0, mutex=0x557e3078, 
cond=0x557e30a0) at pthread_cond_wait.c:508
spin = 0
buffer = {__routine = 0x7396a370 <__condvar_cleanup_waiting>, __arg 
= 0x7fff8e2f5530, __canceltype = 0, __prev = 0x0}
cbuffer = {wseq = 0, cond = 0x557e30a0, mutex = 0x557e3078, 
private = 0}
err = 
g = 0
flags = 
g1_start = 
signals = 
result = 0
wseq = 0
seq = 0
private = 0
maxspin = 
err = 
result = 
wseq = 
g = 
seq = 
flags = 
private = 
signals = 
g1_start = 
spin = 
buffer = 
cbuffer = 
s = 
#2  __pthread_cond_wait (cond=0x557e30a0, mutex=0x557e3078) at 
pthread_cond_wait.c:638
No locals.
#3  0x7fff8eb536bb in ?? () from /usr/lib/x86_64-linux-gnu/dri/i965_dri.so
No symbol table info available.
#4  0x7fff8eb532d7 in ?? () from /usr/lib/x86_64-linux-gnu/dri/i965_dri.so
No symbol table info available.
#5  0x73963f27 in start_thread (arg=) at 
pthread_create.c:479
ret = 
pd = 
unwind_buf = {cancel_jmp_buf = {{jmp_buf = {140735578859264, 
5085453315389036726, 140737488332958, 140737488332959, 140735578855296, 
140735578859264, -5085632128606496586, -5085461228906440522}, mask_was_saved = 
0}}, priv = {pad = {0x0, 0x0, 0x0, 0x0}, data = {prev = 0x0, cleanup = 0x0, 
canceltype = 0}}}
not_first_call = 0
#6  0x738952af in clone () at 
../sysdeps/unix/sysv/linux/x86_64/clone.S:95
No locals.

Thread 7 (Thread 0x7fffc700 (LWP 13659)):
#0  futex_wait_cancelable (private=0, expected=0, futex_word=0x704697c8 
::Storage::s_memory+72>)
 at ../sysdeps/unix/sysv/linux/futex-internal.h:80
__ret = -512
oldtype = 0
err = 
oldtype = 
err = 
__ret = 
resultvar = 
__arg4 = 
__arg3 = 
__arg2 = 
__arg1 = 
_a4 = 
_a3 = 
_a2 = 
_a1 = 
#1  __pthread_cond_wait_common (abstime=0x0, clockid=0, mutex=0x55bd56e0, 
cond=0x704697a0 
::Storage::s_memory+32>)
 at pthread_cond_wait.c:508
spin = 0
buffer = {__routine = 0x7396a370 <__condvar_cleanup_waiting>, __arg 
= 0x7fffcfffe580, __canceltype = -208231568, __prev = 0x0}
cbuffer = {wseq = 12, cond = 0x704697a0 
::Storage::s_memory+32>,
 mutex = 0x55bd56e0, private = 0}
err = 
g = 0
flags = 
g1_start = 
signals = 
result = 0
wseq = 12
seq = 6
private = 0
maxspin = 
err = 
result = 
wseq = 
g = 
seq = 
flags = 
private = 
signals = 
g1_start = 
spin = 
buffer = 
cbuffer = 
s = 
#2  __pthread_cond_wait (cond=0x704697a0 
::Storage::s_memory+32>,
 mutex=0x55bd56e0) at pthread_cond_wait.c:638
No locals.
#3  0x705f67ac in __gthread_cond_wait (__mutex=, 
__cond=) at 
/build/gcc-10-f11ar0/gcc-10-10-20200324/build/x86_64-linux-gnu/libstdc++-v3/include/x86_64-linux-gnu/bits/gthr-default.h:865
No locals.
#4  std::condition_variable::wait (this=, __lock=...) at 
../../../../../src/libstdc++-v3/src/c++11/condition_variable.cc:53
__e = 
#5  0x70138b92 in 
std::_V2::condition_variable_any::wait > () at 
/usr/include/c++/9/condition_variable:273
No locals.
#6  wait, 
bmalloc::Scavenger::threadRunLoop():: > () at 
/usr/include/c++/9/condition_variable:282
No locals.
#7  bmalloc::Scavenger::threadRunLoop () at 
../Source/bmalloc/bmalloc/Scavenger.cpp:406
No locals.
#8  0x70138e69 in bmalloc::Scavenger::threadEntryPoint () at 
../Source/bmalloc/bmalloc/Scavenger.cpp:385
No locals.
#9  0x705fbbb0 in std::execute_native_thread_routine 
(__p=0x55b68710) at ../../../../../src/libstdc++-v3/src/c++11/thread.cc:80
__t = 
#10 0x73963f27 in start_thread (arg=) at 
pthread_create.c:479
ret = 
pd = 
unwind_buf = {cancel_jmp_buf = {{jmp_buf = {14073

Bug#954903: Can not show any vod stream in client

[gulfstream]

Package: crtmpserver
Version: 1.0~dfsg-5.5
Severity: grave


Hello, I have install the crtmpserver and open its rtmp and rtsp function. The 
port 1935 and 554 is listening. The media file cs.mp4 was copied to mediaFolder 
which set in the lua file of crtmpserver.

But I can not get any video or audio in the client, sunch as vlc, with URL 
"rtmp://127.0.0.1:1935/vod/cs.mp4" or "rtsp://127.0.0.1:554/vod/cs.mp4".




When I use rtmp to connect crtmpserver with URL 
"rtmp://127.0.0.1:1935/vod/cs.mp4", I got the log messages:

PID: 19415; TIMESTAMP: 1585113334
1585113334:3:/build/crtmpserver-HcyqVq/crtmpserver-1.0~dfsg/crtmpserver/src/crtmpserver.cpp:203:Initialize:Initialize
 I/O handlers manager: epoll
1585113334:3:/build/crtmpserver-HcyqVq/crtmpserver-1.0~dfsg/crtmpserver/src/crtmpserver.cpp:206:Initialize:Configure
 modules
1585113334:3:/build/crtmpserver-HcyqVq/crtmpserver-1.0~dfsg/thelib/src/configuration/module.cpp:84:LoadLibrary:Module
 
/usr/lib/crtmpserver/applications/applestreamingclient/libapplestreamingclient.so
 loaded
1585113334:3:/build/crtmpserver-HcyqVq/crtmpserver-1.0~dfsg/thelib/src/configuration/module.cpp:84:LoadLibrary:Module
 /usr/lib/crtmpserver/applications/appselector/libappselector.so loaded
1585113334:3:/build/crtmpserver-HcyqVq/crtmpserver-1.0~dfsg/thelib/src/configuration/module.cpp:84:LoadLibrary:Module
 /usr/lib/crtmpserver/applications/flvplayback/libflvplayback.so loaded
1585113334:3:/build/crtmpserver-HcyqVq/crtmpserver-1.0~dfsg/thelib/src/configuration/module.cpp:84:LoadLibrary:Module
 /usr/lib/crtmpserver/applications/proxypublish/libproxypublish.so loaded
1585113334:3:/build/crtmpserver-HcyqVq/crtmpserver-1.0~dfsg/thelib/src/configuration/module.cpp:84:LoadLibrary:Module
 /usr/lib/crtmpserver/applications/stresstest/libstresstest.so loaded
1585113334:3:/build/crtmpserver-HcyqVq/crtmpserver-1.0~dfsg/crtmpserver/src/crtmpserver.cpp:212:Initialize:Plug
 in the default protocol factory
1585113334:3:/build/crtmpserver-HcyqVq/crtmpserver-1.0~dfsg/crtmpserver/src/crtmpserver.cpp:219:Initialize:Configure
 factories
1585113334:3:/build/crtmpserver-HcyqVq/crtmpserver-1.0~dfsg/crtmpserver/src/crtmpserver.cpp:225:Initialize:Configure
 acceptors
1585113334:4:/build/crtmpserver-HcyqVq/crtmpserver-1.0~dfsg/thelib/src/netio/epoll/iohandlermanager.cpp:100:RegisterIOHandler:Handlers
 count changed: 0->1 IOHT_ACCEPTOR
1585113334:4:/build/crtmpserver-HcyqVq/crtmpserver-1.0~dfsg/thelib/src/netio/epoll/iohandlermanager.cpp:100:RegisterIOHandler:Handlers
 count changed: 1->2 IOHT_ACCEPTOR
1585113334:4:/build/crtmpserver-HcyqVq/crtmpserver-1.0~dfsg/thelib/src/netio/epoll/iohandlermanager.cpp:100:RegisterIOHandler:Handlers
 count changed: 2->3 IOHT_ACCEPTOR
1585113334:4:/build/crtmpserver-HcyqVq/crtmpserver-1.0~dfsg/thelib/src/netio/epoll/iohandlermanager.cpp:100:RegisterIOHandler:Handlers
 count changed: 3->4 IOHT_ACCEPTOR
1585113334:0:/build/crtmpserver-HcyqVq/crtmpserver-1.0~dfsg/thelib/src/protocols/protocolfactorymanager.cpp:114:ResolveProtocolChain:chain
 inboundRawHttpStream not registered by any protocol factory
1585113334:2:/build/crtmpserver-HcyqVq/crtmpserver-1.0~dfsg/thelib/src/configuration/module.cpp:119:BindAcceptor:Invalid
 protocol chain: inboundRawHttpStream
1585113334:4:/build/crtmpserver-HcyqVq/crtmpserver-1.0~dfsg/thelib/src/netio/epoll/iohandlermanager.cpp:100:RegisterIOHandler:Handlers
 count changed: 4->5 IOHT_ACCEPTOR
1585113334:4:/build/crtmpserver-HcyqVq/crtmpserver-1.0~dfsg/thelib/src/netio/epoll/iohandlermanager.cpp:100:RegisterIOHandler:Handlers
 count changed: 5->6 IOHT_ACCEPTOR
1585113334:3:/build/crtmpserver-HcyqVq/crtmpserver-1.0~dfsg/crtmpserver/src/crtmpserver.cpp:231:Initialize:Configure
 instances
1585113334:3:/build/crtmpserver-HcyqVq/crtmpserver-1.0~dfsg/crtmpserver/src/crtmpserver.cpp:237:Initialize:Start
 I/O handlers manager: epoll
1585113334:3:/build/crtmpserver-HcyqVq/crtmpserver-1.0~dfsg/crtmpserver/src/crtmpserver.cpp:240:Initialize:Configure
 applications
1585113334:3:/build/crtmpserver-HcyqVq/crtmpserver-1.0~dfsg/thelib/src/configuration/module.cpp:177:ConfigApplication:Application
 applestreamingclient instantiated
1585113334:3:/build/crtmpserver-HcyqVq/crtmpserver-1.0~dfsg/thelib/src/configuration/module.cpp:177:ConfigApplication:Application
 appselector instantiated
1585113334:3:/build/crtmpserver-HcyqVq/crtmpserver-1.0~dfsg/thelib/src/configuration/module.cpp:177:ConfigApplication:Application
 flvplayback instantiated
1585113334:3:/build/crtmpserver-HcyqVq/crtmpserver-1.0~dfsg/thelib/src/configuration/module.cpp:177:ConfigApplication:Application
 proxypublish instantiated
1585113334:4:/build/crtmpserver-HcyqVq/crtmpserver-1.0~dfsg/thelib/src/netio/epoll/iohandlermanager.cpp:100:RegisterIOHandler:Handlers
 count changed: 6->7 IOHT_TIMER
1585113334:3:/build/crtmpserver-HcyqVq/crtmpserver-1.0~dfsg/thelib/src/configuration/module.cpp:177:ConfigApplication:Application
 stresstest instantiated

Bug#954852: [Pkg-cmake-team] Bug#954852: cmake depends on libarchive13 3.3.3, but only 3.2.2 is available

[Andreas Tille]

Hi,

I have uploaded 


libarchive (3.4.0-2~bpo9+1) stretch-backports-sloppy; urgency=medium

  * Rebuild for stretch-backports-sloppy.

 -- Andreas Tille   Wed, 18 Mar 2020 16:24:20 +0100


(see git[1].  May be that upload got lost somehow?  I'm extremely busy
with COVID-19 issues now.  So I can repeat my upload but I have no
better idea what else I could do.

Kind regards

 Andreas.

[1] https://salsa.debian.org/debian/libarchive/-/tree/debian/stretch-backports

On Tue, Mar 24, 2020 at 11:14:26PM +0100, Felix Geyer wrote:
> Hi Andreas,
> 
> On 24.03.20 14:14, Martijn de Gouw wrote:
> > Package: cmake
> > Version: 3.13.2-1~bpo9+1
> > Severity: important
> > 
> > Dear Maintainer,
> > 
> > cmake in stretch-backports depends on libarchive13 (>= 3.3.3),
> > but libarchive13 (3.2.2-2+deb9u2) is the highest available version for
> > stretch (including backports). Therefore apt update fails when backports
> > are enabled
> 
> Could you look into this?
> 
> Seems like it also doesn't build because of this:
> https://buildd.debian.org/status/package.php?p=cmake=stretch-backports
> 
> Cheers,
> Felix
> 
> 

-- 
http://fam-tille.de

Bug#953860: how to reproduce

[Russell Coker]

I created a user on the 21st of March, logged in a couple of times, then 
didn't use that account again.  Now on the 25th of March I have a mapped 
deleted file.  The command "journalctl --rotate" fixes the problem.

root@sevm:~# last|grep test
test pts/1103.75.204.226   Sat Mar 21 13:36 - 13:37  (00:00)
test pts/1103.75.204.226   Sat Mar 21 13:36 - 13:36  (00:00)
root@sevm:~# id test
uid=1002(test) gid=1002(test) groups=1002(test)
root@sevm:~# ps aux|grep journald
root 293  0.0  0.0  67932 16016 ?Ss   Mar24   0:29 /lib/
systemd/systemd-journald
root@sevm:~# grep dele /proc/293/maps 
7fca8e8ef000-7fca8f0ef000 rw-s  00:15 2013277/var/
log/journal/68f1b89bf8c73b0ed9ed905f535fa641/
user-1002@6cf63a35b84c49e8b4fc99b777fb7629--.journal
 
(deleted)

-- 
My Main Blog http://etbe.coker.com.au/
My Documents Bloghttp://doc.coker.com.au/

Bug#952951: botan: Replace PKCS11 headers provided by OASIS

[Sean Whitton]

Hello,

On Tue 10 Mar 2020 at 06:32PM +01, László Böszörményi (GCS) wrote:

> Its CONTRIBUTING.md [3] adds: "Subject to applicable licensing rules,
> the repository content may be re-used freely, including the creation
> and publication of derivative works."
> In my reading this complies with DFSG. It's free to redistribute,
> source code is available and allows publication of derived works. It
> doesn't discriminate any persons, groups or fields of use. It doesn't
> restrict other software even.
> But of course, I would like to hear your opinion Sean and probably from Jack.

Based on what I've seen so far it is not clear to me that it's
DFSG-free.  The various files you reference contain links to various
policies, which might supercede the text you quote from CONTRIBUTING.md
(as "applicable licensing rules").

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#944920: Revise terminology used to specify requirements

[Sean Whitton]

Hello,

On Sat 29 Feb 2020 at 09:38PM -08, Russ Allbery wrote:

> Sean Whitton  writes:
>
>> One issue with using uppercased words is that people might think the
>> words have the same meaning as they do in RFCs, which they don't.
>
>> Your idea of marking keywords in bold wouldn't have this problem, and
>> maybe it would actually make it /easier/ to write patches because you
>> can see more clearly which of your words mean what.
>
> It does have the drawback of being either less obvious or a bit noisy in
> the text output format, though, which I suspect is reasonably heavily
> used.

Oh, excellent point (indeed, it's the main way I read Policy...).

> I'm not sure our definitions are that far off from the RFC terms.  We're
> not defining a protocol, so it's inherently a little different, but there
> are some clear equivalents.  And it would avoid reinventing a new
> typographic convention.
>
> A long time ago, Manoj proposed a deeper, more comprehensive fix: stop
> writing Policy as English prose and instead explicitly state normative
> requirements in some sort of numbered, clear fashion, and then add a prose
> informative explanation if warranted.  But I'm a bit dubious of that.  Not
> only would it be a ton of work, but the more formal phrasing will require
> repeating ourself a lot more.

Yes, it is not clear it would be worth it.

>> Thinking more, I believe that the issue you're raising here is separate
>> from what Russ is trying to achieve in this bug.  The problem you're
>> identifying here already exists in Policy, before Russ's change is
>> applied.  So maybe we should discuss it separately.
>
> Yes, I'm behind but that was the thing I wanted to say: I'd like to merge
> this change (I haven't looked at more recent reviews, since I've been
> distracted with work, so I don't know off-hand if it's ready for merging
> otherwise) and then tackle this issue separately.  But I do think it's
> time to tackle it.

I believe that there are enough seconds (from Sam and I) for your most
recent patch, minus the debian/missing-sources change.  If you're okay
with dropping that, at least for now, then let's get this committed.

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#953860: how to reproduce

[Michael Biebl]

Am 25.03.20 um 05:18 schrieb Russell Coker:
> I created a user on the 21st of March, logged in a couple of times, then 
> didn't use that account again.  Now on the 25th of March I have a mapped 
> deleted file.  The command "journalctl --rotate" fixes the problem.
> 
> root@sevm:~# last|grep test
> test pts/1103.75.204.226   Sat Mar 21 13:36 - 13:37  (00:00)
> test pts/1103.75.204.226   Sat Mar 21 13:36 - 13:36  (00:00)
> root@sevm:~# id test
> uid=1002(test) gid=1002(test) groups=1002(test)
> root@sevm:~# ps aux|grep journald
> root 293  0.0  0.0  67932 16016 ?Ss   Mar24   0:29 /lib/
> systemd/systemd-journald
> root@sevm:~# grep dele /proc/293/maps 
> 7fca8e8ef000-7fca8f0ef000 rw-s  00:15 2013277/var/
> log/journal/68f1b89bf8c73b0ed9ed905f535fa641/
> user-1002@6cf63a35b84c49e8b4fc99b777fb7629--.journal
>  
> (deleted)
> 

Can you find out, how the file was deleted?



signature.asc
Description: OpenPGP digital signature

Bug#948237: RFS: dnstwist

[林上智]

Hi Peter,

Peter Wienemann  於 2020年3月23日 週一 上午3:59寫道：
>
> Dear DDs,
>
> I prepared packaging for the domain name permutation engine "dnstwist"
> (ITP bug #948237). The git repository is currently available at
>
> https://salsa.debian.org/wiene-guest/dnstwist

Thanks for your contribution, I've created this repository and import your
commits in the pkg-security team.

[1] https://salsa.debian.org/pkg-security-team/dnstwist

>
> It would be great if someone could review the code, provide feedback and
> - once everything looks fine - transfer the repository to the security
> tools team area and upload the package.

I didn't see any issues, but one thing to be aware of that someone
also wrote a manpage of dnstwist and sent the PR to the upstream.

[2] https://github.com/elceef/dnstwist/pull/91/files

SZ

>
> Thanks, Peter
>

Bug#954474: python-h2: Autopkgtest failure due to use of py3versions -i

[eamanu]

Hi,

I attach a NMU patch. Please consider apply it.

Cheers,

-- 
Emmanuel Arias
@eamanu
yaerobi.com
From c22a8954dd14fe7c01734ae0564a3855dcf92e30 Mon Sep 17 00:00:00 2001
From: Emmanuel Arias 
Date: Tue, 24 Mar 2020 22:53:44 -0300
Subject: [PATCH] d/tests/control: Fix autopkgtest to test all supported
 python3 versions

---
 debian/changelog | 8 
 debian/tests/control | 2 +-
 debian/tests/python3-h2-upstream | 2 +-
 3 files changed, 10 insertions(+), 2 deletions(-)

diff --git a/debian/changelog b/debian/changelog
index f74bb04..85f332a 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,11 @@
+python-h2 (3.2.0-1.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * d/tests/control: Fix autopkgtest to test all
+supported python3 versions (Closes: #954474).
+
+ -- Emmanuel Arias   Tue, 24 Mar 2020 22:56:51 -0300
+
 python-h2 (3.2.0-1) unstable; urgency=medium
 
   * New upstream release (Closes: #947010).
diff --git a/debian/tests/control b/debian/tests/control
index a67baab..fe53b53 100644
--- a/debian/tests/control
+++ b/debian/tests/control
@@ -1,2 +1,2 @@
 Tests: python3-h2-upstream
-Depends: @, python3-pytest, python3-hypothesis
+Depends: @, python3-pytest, python3-hypothesis, python3-all
diff --git a/debian/tests/python3-h2-upstream b/debian/tests/python3-h2-upstream
index 161e771..44ee546 100644
--- a/debian/tests/python3-h2-upstream
+++ b/debian/tests/python3-h2-upstream
@@ -1,6 +1,6 @@
 #!/bin/sh
 set -e
-for py in $(py3versions -i); do
+for py in $(py3versions -s); do
 echo "[*] testing $py:"
 $py -m pytest
 done
-- 
2.25.1



0xFA9DEC5DE11C63F1.asc
Description: application/pgp-keys


signature.asc
Description: OpenPGP digital signature

Bug#446036: Hello

[Mr. Harold Charitable Foundation]

Mr Harold & Family charitable foundation have a donation for you. 

Reply for more details
Regards,

Bug#954900: openboard cannot be install because of unmet dependencies

[Joerg Schiermeier, Bielefeld/Germany]

Package: openboard
Version: 1.4.1-1~itzks2~0deb10+1
Severity: normal

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Hello!

Just I tried to install openboard via apt-get. This failed. It only gave me 
this error message:

- --- error ---
The following packages have unmet dependencies:
 openboard : Depends: libpoppler74 (>= 0.63.0) but it is not installable
 Depends: libquazip1 (>= 0.7.3) but it is not installable
 Depends: libx264-152 but it is not installable
 openboard-common : Depends: libjs-jquery-i18n-properties but it is not 
installable
- --- error ---

I check this packaged and I discover this:
openboard depends on some older versions of libpoppler, libquazip1 and libx264. 
This should be fixed.

- -- 
Yours sincerely
Joerg Schiermeier



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

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

Versions of packages openboard depends on:
ii  libasound21.2.2-2.1
ii  libass9   1:0.14.0-2
ii  libavcodec58  7:4.2.2-1+b1
ii  libavformat58 7:4.2.2-1+b1
ii  libavutil56   7:4.2.2-1+b1
ii  libbz2-1.01.0.8-2
ii  libc6 2.30-2
ii  libfreetype6  2.10.1-2
ii  libgcc-s1 [libgcc1]   10-20200312-2
ii  libgcc1   1:10-20200312-2
ii  libgl11.3.1-1
ii  libglib2.0-0  2.64.1-1
ii  libgomp1  10-20200312-2
ii  liblzma5  5.2.4-1+b1
ii  libmp3lame0   3.100-3
ii  libogg0   1.3.2-1+b1
ii  libopus0  1.3-1+b1
ii  libpulse-mainloop-glib0   13.0-5
ii  libpulse0 13.0-5
ii  libqt5core5a  5.12.5+dfsg-9
ii  libqt5gui55.12.5+dfsg-9
ii  libqt5multimedia5 5.12.5-1+b1
ii  libqt5multimediawidgets5  5.12.5-1+b1
ii  libqt5network55.12.5+dfsg-9
ii  libqt5printsupport5   5.12.5+dfsg-9
ii  libqt5script5 5.12.5+dfsg-2
ii  libqt5svg55.12.5-2
ii  libqt5webkit5 5.212.0~alpha4-1
ii  libqt5widgets55.12.5+dfsg-9
ii  libqt5xml55.12.5+dfsg-9
ii  libqt5xmlpatterns55.12.5-1
ii  libsdl1.2debian   1.2.15+dfsg2-5
ii  libssl1.1 1.1.1d-2
ii  libstdc++610-20200312-2
ii  libswresample37:4.2.2-1+b1
ii  libswscale5   7:4.2.2-1+b1
ii  libtheora01.1.1+dfsg.1-15
ii  libva-x11-2   2.7.0~pre1-1
ii  libva22.7.0~pre1-1
ii  libvorbis0a   1.3.6-2
ii  libvorbisenc2 1.3.6-2
ii  libvpx5   1.7.0-3
ii  libx11-6  2:1.6.9-2
ii  libxcb-render01.13.1-5
ii  libxcb-shape0 1.13.1-5
ii  libxcb-shm0   1.13.1-5
ii  libxcb-xfixes01.13.1-5
ii  libxcb1   1.13.1-5
ii  zlib1g1:1.2.11.dfsg-2

openboard recommends no packages.

openboard suggests no packages.

-BEGIN PGP SIGNATURE-
Comment: This was created by GnuPG for Linux.

iQIzBAEBCAAdFiEERMHJSMoKBiNrvtXJodFQ9YsO8GMFAl56t/EACgkQodFQ9YsO
8GO7ZQ//ff8GwKHHqo5CLzpMP5g0QOJEIbWb/eydjVWWEOn4PKzMwSyPCNOGddfS
joX+e8EBtfpoPcVZFzAQTxVen8nGxjAX/cnx4dnYFRIwXTPwb8Fw21fkqYGO3hfj
ytUf54Q3C5L8MjORM5eqaXYwn3SkcJM8bg1MornxbbdHBDzoEf8riAkDA3QURQz6
jvQdh7yk9mOXlaLCZ8JV/yJMmJH6NxeSH+JAtS9w/gGnkPh2m0Fl/P6s21PfvBLb
Pyy8CPRNFba0sqZe+4HbXrG8oYpYtxo5XYJvcQbf1UBMP0Up1617wWhrgLbq45vr
HrFzCczCrqZp72jMMgDnDNDnE+QkFRLXJWvty/emq/oVzL5QnasV+VYgfGXd9aoe
qFOI5UTHuJqmzSc5DJlEpiuo3rkhrmPPkaIvgliICNS+We/W9bufoW5K7O5a1des
7tdyeWmQmPbX80MGN9HTXLuMwKyCn19hEK+htcKn52GJDQEcgMTrjMEmEUh2cfi9
LiNYdNJrm4j0qqcljRs4m1uW6WUsgDYY8g3OjEymb6CCZDLZEYg7MjfOTljB906i
q4l1zXyXmT2w0qtCvBvpNlQcg/9FAbasTtDX0MzpNAXsrN+W8gobwd98uYbw13fi
IgA+wOVs6Xmnb9BnIkwJywXHq/E0VMFCa/fQHqvYkXvmYUsZKNY=
=4Ir+
-END PGP SIGNATURE-

Bug#883838: [Pkg-openldap-devel] Bug#883838: slapd: Overlay ppolicy: When pwdFailureCountInterval (!=0) is reached the password failures are not purged.

[Ryan Tandy]

Control: tag -1 moreinfo

Hello Mats,

I finally looked more closely at this bug, and I believe the code is 
working as intended.


On Fri, Dec 08, 2017 at 08:39:32AM +0100, Mats Luspa wrote:

in the overlay ppolicy you can use pwdFailureCountInterval attribute. The 
documentation says "pwdFailureCountInterval attribute holds the number of 
seconds after which the password failures are purged from the failure counter, even 
though no successful authentication occurred.
If pwdFailureCountInterval attribute is not present, or if its value is 0, the 
failure counter is only reset by a successful authentication."

But that doesn't work.


The documentation doesn't talk about how many values of pwdFailureTime 
are actually present in the database, only how many are _counted_ when 
deciding whether to lock the account.


Given the following policy:

pwdFailureCountInterval: 10
pwdMaxFailure: 2
pwdLockout: TRUE

If I try an incorrect password two times within ten seconds, my account 
will be locked (permanently, since I did not specify a lock duration).


However, if I try an incorrect password one time, wait at least ten 
seconds, and then try it again, my account will not be locked, because 
the earlier failure is considered to have expired and is not counted. I 
have verified this in the jessie version of slapd.


In either case, it's intentional that pwdFailureTime is not physically 
deleted until the next successful authentication. It's possible the 
documentation is not clear enough on this point.


Please let me know if you agree with my analysis above.

thanks,
Ryan

Bug#407722: Hello

[Mr. Harold Charitable Foundation]

Mr Harold & Family charitable foundation have a donation for you. 

Reply for more details
Regards,

Bug#595070: Hello

[Mr. Harold Charitable Foundation]

Mr Harold & Family charitable foundation have a donation for you. 

Reply for more details
Regards,

Bug#953971: Please add at-spi2-core to the build-dependencies so the tests on hurd-i386 can succeed

[Samuel Thibault]

Hello,

I got further down with this (I happen to be maintainer of the
at-spi2-core package :) ), the difference here is that the dbus-x11
package is not installed in the Linux case. If I install the dbus-x11
package, Linux starts getting the same issue: /usr/bin/dbus-launch gets
launched to autostart a session dbus bus and libatspi then tries to find
its at-spi2-core service, to no avail. Normally this only produces a
glib warning, but apparently the tests here enable making glib warnings
fatal, thus the trap.

So I was wondering whether it'd be a bug of the hurd port or of
libatspi, but apparently no, it's just an unfortunate combinaison of
behavior.

Installing at-spi2-core or setting NO_AT_BRIDGE=1 should be fine then.
I would say it would be safer to do so on non-hurd ports too, in case
at some point the dbus packages end up making dbus-launch available by
default on non-hurd too.

Samuel

Bug#954743: lintian: orig-tarball-missing-upstream-signature does not say how to add it to uploaded tarballs

[Chris Lamb]

Mattia Rizzolo wrote:

> > AIUI -sa by itself will not be rejected but I am unclear whether the
> > inclusion of the signature will cause a rejection. You could just try
> > it? :)
> 
> I can tell you both that such an upload won't be rejected by dak as long
> as the .orig.tar.gz is the very same as the one that was previously
> uploaded.

Just to be clear, we are attempting to clarify the situation regarding
the addition of the *.asc* corresponding to the .orig.tar.gz (ie. the
second half of my sentence) not whether DAK rejects "uselessly"
including the .orig.tar.gz again.

In other words, my "AIUI" should be replaced with something much
stronger; I've done many "useless" sourceful uploads successfully, but
I've never attempted to add an .sig…

> Honestly, I'm somewhat partial on putting such archive-dependant
> information in lintian is alright (dak is only one of the many debian
> archive software out there…).

(I don't believe that is being requested here.)


Regards,

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

Bug#954806: Wrong copyright years in attached tarball

[Asher Gordon]

Asher Gordon  writes:

> Since I was not able write a simpler program that triggers the bug, I
> have attached the source tarball (mu.tar.gz).

I copied the copyright notices in that tarball from another project and
forgot to change the copyright years. It should really be 2020. (It
probably makes no difference, but I just thought I'd clarify just in
case.)

Asher

-- 
The marvels of today's modern technology include the development of a
soda can, when discarded will last forever ... and a $7,000 car which
when properly cared for will rust out in two or three years.
   
I prefer to send and receive mail encrypted. Please send me your
public key, and if you do not have my public key, please let me
know. Thanks.

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


signature.asc
Description: PGP signature

Bug#954771: already fixed upstream: empathy-accounts fails to create any account

[Harald Geyer]

reassign 954771 telepathy-mission-control-5
forwarded 954771 
https://gitlab.freedesktop.org/telepathy/telepathy-mission-control/issues/84
tag 954771 + fixed-upstream
retitle 954771 telepathy-mission-control-5 broken by strict checks in recent 
glib
stop

Dear Maintainers,

turns out the bug has already been reported upstream some time ago.
Actually upstream git contains a trival fix (not tested by me):
https://gitlab.freedesktop.org/telepathy/telepathy-mission-control/-/commit/d8dab08fe8db137c6bbd8bbdc3d9b01d98c48910

HTH,
Harald

-- 
Es gibt viele Maßnahmen gegen die Klimakrise, die leicht und ohne Verlierer
umsetzbar sind. Das Problem ist immer noch das Desinteresse der etablierten
Parteien.
https://haraldgeyer.at/Klimaschutz.html

Bug#954898: libgccjit0: libgccjit segmentation fault

[Gong-Yi Liao]

Package: libgccjit0
Version: 10-20200324-1
Severity: important

Dear Maintainer,

I tried to complie GCC JIT's offiical hello world example shown on 

https://gcc.gnu.org/onlinedocs/jit/intro/tutorial01.html

Compilation worked well without any error message, however, when I ran the 
generated binary, it shows a segmentation fault, gdb output suggests it's 
caused by libgccjit:

gong-yi@sid0 ~> gdb ./test2
GNU gdb (Debian 9.1-2) 9.1
Copyright (C) 2020 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Type "show copying" and "show warranty" for details.
This GDB was configured as "x86_64-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
<http://www.gnu.org/software/gdb/documentation/>.

For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from ./test2...
(No debugging symbols found in ./test2)
(gdb) start
Temporary breakpoint 1 at 0x13c3
Starting program: /home/gong-yi/test2 

Temporary breakpoint 1, 0x53c3 in main ()
(gdb) continue
Continuing.

Program received signal SIGSEGV, Segmentation fault.
0x775829f3 in ?? () from /usr/lib/x86_64-linux-gnu/libgccjit.so.0
(gdb) continue
Continuing.

Program terminated with signal SIGSEGV, Segmentation fault.
The program no longer exists.

Thanks, 
Gong-Yi. 


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

   * What led up to the situation?
   * What exactly did you do (or not do) that was effective (or
 ineffective)?
   * What was the outcome of this action?
   * What outcome did you expect instead?

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


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

Kernel: Linux 5.4.0-0.bpo.4-amd64 (SMP w/8 CPU cores)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) (ignored: LC_ALL 
set to en_US.UTF-8), LANGUAGE=en_US.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set 
to en_US.UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages libgccjit0 depends on:
ii  binutils   2.34-5
ii  gcc-10-base10-20200324-1
ii  libc6  2.30-2
ii  libgcc-10-dev  10-20200324-1
ii  libgmp10   2:6.2.0+dfsg-4
ii  libisl22   0.22.1-1
ii  libmpc31.1.0-1
ii  libmpfr6   4.0.2-1
ii  libzstd1   1.4.4+dfsg-3
ii  zlib1g 1:1.2.11.dfsg-2

libgccjit0 recommends no packages.

libgccjit0 suggests no packages.

-- no debconf information

Bug#954899: ITP: cfgv -- Python module to validate configuration files

[Daniel Baumann]

Package: wnpp
Severity: wishlist

  * Package name : cfgv
  * Upstream Author : Anthony Sottile
  * License : MIT
  * Homepage : https://github.com/asottile/cfgv

Description: Python module to validate configuration files
 cfgv is a Python module to validate configuration files and produce
 human readable error messages.

This is a depends of pre-commit.

Regards,
Daniel

Bug#937063: moin: updating py2 removal status

[Sandro Tosi]

Hello Steve,

On Sat, Feb 1, 2020 at 8:08 PM Sandro Tosi  wrote:
>
> > We're using moin for the Debian wiki, so we can't sensibly just remove
> > it from Debian. Upstream are working on python3 migration, but only
> > for the new moin2 codebase. I'm watching the work going on there to
> > see when it makes sense for us to start playing with it...
>
> that seems a sensible decision, but by looking at their progress (and
> in particular at https://github.com/moinwiki/moin/issues/941) it
> appears upstream is working on the python3 porting rather slowly. Did
> you have a chance to look at the codebase yet? is there someone that
> could lend a hand to the moin team to speed up development?
>
> once we have a py3k codebase in Debian then there will be also need to
> develop a plan to migrate our current wiki instance to the new
> software (http://moinmo.in/MoinMoin2.0 mentions several chances).

did you have a chance to look at the points above?

we reached a point where moin is keeping in the archive a long list of
modules (both directly and transitively) that, if moin was ported to
python3, we could remove.

I think it's important to start looking at the current code soon and
start planning to migrate to is asap, as i know for a fact some
maintainers are getting eager to drop python2 support from their
package and may get over-exited and do that soon, without checking for
their rdeps.

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

Bug#954897: pydxcluster: should this package be removed?

[Sandro Tosi]

Package: pydxcluster
Severity: serious
Tags: sid, bullseye

Hello,
i believe this package should be removed:

* python2-only
* no upstream releases since 2016 (with no other sign of development)
* low popcon
* no rdeps

If i dont hear back within a week with a good reason to keep this package, i'll
file for it's removal.

Regards,
Sandro

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

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

Versions of packages pydxcluster depends on:
ii  python2.7.16-1
pn  python-pygame 
ii  python-requests   2.21.0-1
ii  python-tk 2.7.16-2
pn  python-xmltodict  

pydxcluster recommends no packages.

pydxcluster suggests no packages.

Bug#954845: poor performance for -g 256x50

[Thomas Dickey]

On Tue, Mar 24, 2020 at 01:15:40PM +0100, Harald Dunkel wrote:
> Package: xterm
> Version: 353-1
> 
> xterm -g 256x50 has a much worse "scroll performance" than xterm -g 255x50,
> esp if there are very long lines and its a slow network connection. Sample:
> 
> xterm -g 255x50:
> # time cat /var/log/rsnapshot.log
> :
> :
> 
> real0m0.041s
> user0m0.000s
> sys 0m0.006s
> 
> 
> xterm -g 256x50:
> # time cat /var/log/rsnapshot.log
> :
> :
> 
> real0m27.631s
> user0m0.000s
> sys 0m0.004s
> 
> 
> Maybe this could be improved?

maybe - but I have to see how to reproduce the problem.

Presumbly it's xterm, but then again, I can see cases where the
X server (and its uneven quality-of-implementation for certain Xlib calls)
could explain the problem.  If I can reproduce the problem, I'll have no
doubt :-)

I'm assuming that your example file's kind of large and wouldn't be suitable
for an attachment (even compressed).  Unless there's something special about
columns 255/256 -- or multiples of that (such as a multibyte character that has
to be split), then I'm not sure how to advise on reducing it to some repetitive
string that could be scripted.  But some sort of bisecting approach, making
successively smaller slices from the original file (and repeating them) might
work.

How large is the file ("wc" output would help)?

-- 
Thomas E. Dickey 
https://invisible-island.net
ftp://ftp.invisible-island.net


signature.asc
Description: PGP signature

Bug#954896: ITP: identify -- File identification library for Python

[Daniel Baumann]

Package: wnpp
Severity: wishlist

  * Package name : identify
  * Upstream Author : Chris Kuehl, Anthony Sottile
  * License : MIT
  * Homepage : https://github.com/chriskuehl/identify

Description: File identification library for Python
Identify is a Python module to get information about files, such as:
 .
   * File type (file, symlink, directory)
   * Mode (is it executable?)
   * File name (mostly based on extension)
   * If executable, the shebang is read and the interpreter interpreted

This is a depends of pre-commit.

Regards,
Daniel

Bug#954647: pandas - that's not the actual problem

[Rebecca N. Palmer]

Control: retitle -1 pandas FTBFS: deprecations/improvements fail tests

The message on the old title is just a warning, but there are 6 other 
tests that fail.


I think these are all bugs in the tests not the actual package, i.e. 
using our current pandas is fine.


Deprecation warnings in fail-on-warning tests:
arrays/categorical/test_warnings.py::TestCategoricalWarnings::test_tab_complete_warning
plotting/test_frame.py::TestDataFramePlots::test_subplots_warnings
plotting/test_hist_method.py::TestDataFrameGroupByPlots::test_grouped_hist_legacy

Tests that expect Matplotlib to reject a color format it now accepts ( 
https://matplotlib.org/users/whats_new.html#digit-and-4-digit-hex-colors ):

plotting/test_frame.py::TestDataFramePlots::test_line_colors
plotting/test_frame.py::TestDataFramePlots::test_line_colors_and_styles_subplots

Change in default axis tick positioning, already marked as 
version-dependent:

plotting/test_datetimelike.py::TestTSPlot::test_matplotlib_scatter_datetime64

Bug#954650: AttributeError: module 'certbot.plugins.common' has no attribute 'TLSSNI01'

[Harlan Lieberman-Berg]

On Sun, Mar 22, 2020 at 5:51 AM Damien Couroussé
 wrote:
> I could fix the issue by upgrading python3-certbot-apache to version
> 1.1.0-1.

Hi Damien,

Yes, these two versions are not fully compatible.  I didn't put in a
version restriction because mixing packages from testing into a stable
installation can result in breakage (such as you've ran into).  If you
really want to do so, make sure that you pull not only the package
from testing, but all the things that reverse-depend on it.  For
certbot, the easiest way to do that is to specify that you want to
install the leaf package from testing (python3-certbot-apache), rather
than the middle package (certbot, or python3-certbot).  That should
reliably upgrade certbot itself, if it's necessary to do so.

That said, I'll talk with upstream and see if I can add some level of
version protection to keep it from happening in the future.

Thanks for your report!

-- 
Harlan Lieberman-Berg
~hlieberman

Bug#954895: cryptominisat: Uninstallable because of outdated dependencies

[Celelibi]

Source: cryptominisat
Version: 5.6.4+dfsg.1-1+b3
Severity: grave
Justification: renders package unusable

Dear Maintainer,

Although the library and development files can be installed just fine,
the command line tool cannot.

The package cryptominisat depends on libboost-program-options1.62.0
which doesn't exist anymore.

Would it be possible to provide a package compiled against a newer
version?

Best regards,
Celelibi

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

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

Bug#908117: RFP: yq -- yq is a lightweight and portable command-line YAML processor The aim of the project is to be the jq or sed of yaml files.

[Dominik George]

Hi,

> Hi guys,

Please try to be inclusive of other genders ☺. (Proposal: Hi folks; Hi people;
Hi friends,…)

> 
> I see this thread in ITP status. However, I wonder if this is still in
> process of being packaged.
> 
> I've been maintaining the deb packages for such yq tool at my ppa
> (https://launchpad.net/~rmescandon/+archive/ubuntu/ppa/) but I wanted to
> step forward a little bit more by polishing and formatting everything
> that is needed for having yq into the debian upstream.
> 
> Could it be possible for me to take this ITP thread and give it a go?

I also jsut wanted to start work on a yq package for Debian. I think a month
later it is ok for you to setyourself as the owner of this ITP bug and take
over the packaging.

Please, if you start working, do so in a repository on salsa.debian.org. I
will happily mentor you and if that goes well sponsor your upload.

Cheers,
Nik

Bug#908117: RFP: yq -- yq is a lightweight and portable command-line YAML processor The aim of the project is to be the jq or sed of yaml files.

[Dominik George]

Hi,

> Hi guys,

Please try to be inclusive of other genders ☺. (Proposal: Hi folks; Hi people;
Hi friends,…)

> 
> I see this thread in ITP status. However, I wonder if this is still in
> process of being packaged.
> 
> I've been maintaining the deb packages for such yq tool at my ppa
> (https://launchpad.net/~rmescandon/+archive/ubuntu/ppa/) but I wanted to
> step forward a little bit more by polishing and formatting everything
> that is needed for having yq into the debian upstream.
> 
> Could it be possible for me to take this ITP thread and give it a go?

I also jsut wanted to start work on a yq package for Debian. I think a month
later it is ok for you to setyourself as the owner of this ITP bug and take
over the packaging.

Please, if you start working, do so in a repository on salsa.debian.org. I
will happily mentor you and if that goes well sponsor your upload.

Cheers,
Nik

Bug#954852: [Pkg-cmake-team] Bug#954852: cmake depends on libarchive13 3.3.3, but only 3.2.2 is available

[Felix Geyer]

Hi Andreas,

On 24.03.20 14:14, Martijn de Gouw wrote:

Package: cmake
Version: 3.13.2-1~bpo9+1
Severity: important

Dear Maintainer,

cmake in stretch-backports depends on libarchive13 (>= 3.3.3),
but libarchive13 (3.2.2-2+deb9u2) is the highest available version for
stretch (including backports). Therefore apt update fails when backports
are enabled


Could you look into this?

Seems like it also doesn't build because of this:
https://buildd.debian.org/status/package.php?p=cmake=stretch-backports

Cheers,
Felix

Bug#924362: Failure upgrading chkrootkit

[Marcos Fouces]

Hello Adam

I am trying to reproduce the bug with current version of chkrootkit but
i obtain a different result:

# sudo /usr/share/debconf/frontend
/var/lib/dpkg/info/chkrootkit.postinst configure 0.53-1; echo $?

# 0

I used a (still unreleased) 0.53-2 version and it seems to be correctly
upgraded.

Could you confirm this?

Greetings, 
Marcos.

Bug#954894: RM: python-lightblue -- RoQA; Depends on python 2, dead upstream

[Moritz Muehlenhoff]

Package: ftp.debian.org
Severity: normal

Please remove python-lightblue. It depends on Python 2, is dead upstream
and there are no reverse deps.

Cheers,
Moritz

Bug#954893: aptitude: messages from AppStream garble the ncurses interface

[Gabriele Stilli]

Package: aptitude
Version: 0.8.12-3

Hello,

I use aptitude with the ncurses interface. Every time I do an update
(press "u" in the program), the following message from AppStream pops up
at the end:

"The AppStream system cache was updated, but some components were
ignored. Refer to the verbose log for more information."

As a result, the interface gets garbled all around. I attach a
screenshot illustrating the end result.

Cheers,
Gabriele Stilli

Bug#954892: RM: obex-data-server -- RoQA; python2-only; orphaned; leaf package; alternatives exist

[Sandro Tosi]

Package: ftp.debian.org
Severity: normal

Bug#935626: RFA: numba

[Diane Trout]

On Wed, 18 Mar 2020 04:34:24 + Mo Zhou  wrote:
> Hi Diane,
> 
> Please go ahead. But actually the package is maintained under science
> team. I think it's unnecessary to move it from science team to python
> team.
> 

Did you want me to leave you in uploaders for numba?

Diane

Bug#954849: libreoffice: crash after update

[Rene Engelhard]

Hi,

On Tue, Mar 24, 2020 at 10:08:03PM +0100, Marcin Krawczyk wrote:
> : CommandLine Error: Option 'limited-coverage-experimental' registered more
> than once!
> LLVM ERROR: inconsistency in registered CommandLine options

Thq question still is what involves some CommandLine thingy of LLVM
here.

> Start-Date: 2020-03-23  21:38:19
> Commandline: apt install ./gdm3setup-utils-20140306-1.deb
> Requested-By: marcin (1000)
> Install: gdm3setup-utils:amd64 (20140306-1)
> End-Date: 2020-03-23  21:38:20

Are you installing random package from somewhere?

> > > LLVM ERROR: inconsistency in registered CommandLine options
> > LO does not use LLVM. So what are you using which is and throws this
> > error?
> There is just xterm, but console doesn't matter
> Only libreoffice crashes and I don't know why all rest apps works fine

I was more aiming at some tool using libreoffice, extension,  Or
some library from Debian replaced why whatever you installed from
somewhere

> > > Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
> > > TAINT_UNSIGNED_MODULE
> what that means
> > Oh my..

... or some proprietary X driver or some else proprietary stuff.

Regards,

Rene

Bug#954891: okular: CVE-2020-9359: Local binary execution via action links

[Salvatore Bonaccorso]

Source: okular
Version: 4:19.12.3-1
Severity: important
Tags: security upstream
Control: found -1 4:17.12.2-2.2
Control: found -1 4:16.08.2-1+deb9u1
Control: found -1 4:16.08.2-1

Hi,

The following vulnerability was published for okular.

CVE-2020-9359[0]:
| KDE Okular before 1.10.0 allows code execution via an action link in a
| PDF document.


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-9359
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-9359
[1] https://kde.org/info/security/advisory-20200312-1.txt
[2] 
https://invent.kde.org/kde/okular/-/commit/6a93a033b4f9248b3cd4d04689b8391df754e244

Regards,
Salvatore

Bug#954849: libreoffice: crash after update

[Marcin Krawczyk]

Hi

Thank You for reaction.

My answers bellow.

Little update, I purge libreoffice, change my source.apt to testing, 
uninstall gnome, python3 etc... then I install testing with libreoffice. 
Unfortunately error is still, after first run libreoffice show banner 
sometimes show it twice, new user doesn't help, remove local files 
doesn't help. If I can check something I can, please send where to look 
for it.
Only libreoffice --version is finished OK. Rest close and invoked in 
console send error


: CommandLine Error: Option 'limited-coverage-experimental' registered more
than once!
LLVM ERROR: inconsistency in registered CommandLine options


On 24.03.2020 16:59, Rene Engelhard wrote:

tag 954849 + moreinfo
tag 954849 + unreproducible
thanks

Hi,

On Tue, Mar 24, 2020 at 02:06:52PM +0100, Marcin Krawczyk wrote:

* What led up to the situation?
After night upgrade libreoffice crash when is opened

Which packages did get upgraded?

There is my /var/log/apt/history

Start-Date: 2020-03-23  00:45:49
Requested-By: marcin (1000)
Install: bind9-dnsutils:amd64 (1:9.16.1-2, automatic), 
libprotobuf-lite22:amd64 (3.11.4-2, automatic), libprotobuf22:amd64 
(3.11.4-2, automatic), libgeos-3.8.1:amd64 (3.8.1-1, automatic), 
bind9-libs:amd64 (1:9.16.1-2, automatic)
Upgrade: vlc-plugin-video-output:amd64 (3.0.8-4, 3.0.8-4+b1), 
python3-doc:amd64 (3.8.2-1, 3.8.2-2), libcom-err2:amd64 (1.45.5-2, 
1.45.6-1), libcom-err2:i386 (1.45.5-2, 1.45.6-1), 
libnet-ssleay-perl:amd64 (1.88-2, 1.88-3), gcc-9-base:amd64 (9.3.0-5, 
9.3.0-6), gcc-9-base:i386 (9.3.0-5, 9.3.0-6), lib32stdc++6:amd64 
(10-20200312-2, 10-20200321-1), libgeos-c1v5:amd64 (3.8.0-1, 3.8.1-1), 
gcc-10-base:amd64 (10-20200312-2, 10-20200321-1), gcc-10-base:i386 
(10-20200312-2, 10-20200321-1), r-cran-diffobj:amd64 (0.2.3-1, 0.2.4-1), 
libgeos-dev:amd64 (3.8.0-1, 3.8.1-1), libobjc4:amd64 (10-20200312-2, 
10-20200321-1), cpp-9:amd64 (9.3.0-5, 9.3.0-6), lib32gcc-s1:amd64 
(10-20200312-2, 10-20200321-1), bind9-host:amd64 (1:9.11.16+dfsg-2, 
1:9.16.1-2), e2fsprogs:amd64 (1.45.5-2, 1.45.6-1), libitm1:amd64 
(10-20200312-2, 10-20200321-1), dnsutils:amd64 (1:9.11.16+dfsg-2, 
1:9.16.1-2), libgfortran-9-dev:amd64 (9.3.0-5, 9.3.0-6), sudo:amd64 
(1.8.31-1, 1.8.31p1-1), gobjc-9:amd64 (9.3.0-5, 9.3.0-6), libvlc5:amd64 
(3.0.8-4, 3.0.8-4+b1), libasan5:amd64 (9.3.0-5, 9.3.0-6), 
libquadmath0:amd64 (10-20200312-2, 10-20200321-1), 
libisc-export1105:amd64 (1:9.11.16+dfsg-2, 1:9.11.17+dfsg-2), 
mozc-utils-gui:amd64 (2.23.2815.102+dfsg-8+b1, 2.23.2815.102+dfsg-8+b2), 
libvlccore9:amd64 (3.0.8-4, 3.0.8-4+b1), libvlc-bin:amd64 (3.0.8-4, 
3.0.8-4+b1), libstdc++-9-dev:amd64 (9.3.0-5, 9.3.0-6), libgcc1:amd64 
(1:10-20200312-2, 1:10-20200321-1), libss2:amd64 (1.45.5-2, 1.45.6-1), 
libext2fs2:amd64 (1.45.5-2, 1.45.6-1), lib32gcc1:amd64 (1:10-20200312-2, 
1:10-20200321-1), php-phpmyadmin-sql-parser:amd64 (4.4.0-1, 4.6.1-1), 
python3-ipykernel:amd64 (5.1.4-2, 5.2.0-1), libtsan0:amd64 
(10-20200312-2, 10-20200321-1), libubsan1:amd64 (10-20200312-2, 
10-20200321-1), pci.ids:amd64 (0.0~2020.02.22-1, 0.0~2020.03.20-1), 
g++-9:amd64 (9.3.0-5, 9.3.0-6), libgfortran5:amd64 (10-20200312-2, 
10-20200321-1), mozc-server:amd64 (2.23.2815.102+dfsg-8+b1, 
2.23.2815.102+dfsg-8+b2), gcc-9:amd64 (9.3.0-5, 9.3.0-6), 
libobjc-9-dev:amd64 (9.3.0-5, 9.3.0-6), libprotobuf-c1:amd64 (1.3.3-1, 
1.3.3-1+b1), gfortran-9:amd64 (9.3.0-5, 9.3.0-6), liblsan0:amd64 
(10-20200312-2, 10-20200321-1), libgomp1:amd64 (10-20200312-2, 
10-20200321-1), libgomp1:i386 (10-20200312-2, 10-20200321-1), zsh:amd64 
(5.8-3, 5.8-4), libtss2-esys0:amd64 (2.3.3-1, 2.4.0-1), libgcc-s1:amd64 
(10-20200312-2, 10-20200321-1), libgcc-s1:i386 (10-20200312-2, 
10-20200321-1), libphonenumber7:amd64 (7.1.0-5+b4, 7.1.0-5+b5), 
uim-mozc:amd64 (2.23.2815.102+dfsg-8+b1, 2.23.2815.102+dfsg-8+b2), 
python-concurrent.futures:amd64 (3.3.0-3, 3.3.0-4), libatomic1:amd64 
(10-20200312-2, 10-20200321-1), libatomic1:i386 (10-20200312-2, 
10-20200321-1), zsh-common:amd64 (5.8-3, 5.8-4), logsave:amd64 
(1.45.5-2, 1.45.6-1), libcc1-0:amd64 (10-20200312-2, 10-20200321-1), 
vlc-plugin-base:amd64 (3.0.8-4, 3.0.8-4+b1), libstdc++6:amd64 
(10-20200312-2, 10-20200321-1), libstdc++6:i386 (10-20200312-2, 
10-20200321-1), libgcc-9-dev:amd64 (9.3.0-5, 9.3.0-6), aspell-ga:amd64 
(0.50-4-4.2, 0.50-4-5)
Remove: libisccfg163:amd64 (1:9.11.16+dfsg-2), libirs161:amd64 
(1:9.11.16+dfsg-2), libisc1105:amd64 (1:9.11.16+dfsg-2), 
libprotobuf-lite17:amd64 (3.6.1.3-2+b3), libboost-chrono1.67.0:amd64 
(1.67.0-17), liblwres161:amd64 (1:9.11.16+dfsg-2), 
libboost-atomic1.67.0:amd64 (1.67.0-17), libisccc161:amd64 
(1:9.11.16+dfsg-2), libbind9-161:amd64 (1:9.11.16+dfsg-2), 
libgeos-3.8.0:amd64 (3.8.0-1), libdns1109:amd64 (1:9.11.16+dfsg-2)

End-Date: 2020-03-23  00:46:35

Start-Date: 2020-03-23  00:53:00
Requested-By: marcin (1000)
Install: csh:amd64 (20110502-5)
End-Date: 2020-03-23  00:53:01

Start-Date: 2020-03-23  01:05:34
Requested-By: marcin (1000)
Install: ksh:amd64 (2020.0.0-5)

Bug#953527: [apt] colour highlighted error/warn labels

[jnqnfe]

On Tue, 2020-03-24 at 21:16 +0100, Julian Andres Klode wrote:
> On Tue, Mar 24, 2020 at 08:09:24PM +, jnq...@gmail.com wrote:
> > Hi, Julian,
> > 
> > Thanks for adding the colour support in apt 2.0.1.
> > 
> > I'm curious though, most implementations use isatty() to determine
> > the
> > default colour control setting, which it seems that your
> > implementation
> > lacks, instead only outputting colour when explicitly enabled via
> > `-o
> > APT::Color=true`.
> > 
> > Was it a deliberate decision to not make use of isatty() to
> > determine a
> > default?
> 
> That's how it works, apt(8) sets APT::Color to true by default, and
> the
> code sets it to false if stdout is not a tty. Which it already did
> before,
> as you can see in apt list, for example.
> 
> As is customary, for compatibility reasons, apt-get(8) and apt-cache
> and 
> friends do not change behavior.

Oh, sorry. I saw no isatty() related change in a commit referenced from
the automatic 'pending' notification, and I did indeed try with apt-get 
rather than pure apt after updating which had no color by default, so
figured it must be missing. thanks.

Bug#890168: python-gasp: Please switch to python-gobject-2/python-gi

[Moritz Mühlenhoff]

On Sun, Oct 06, 2019 at 06:00:02PM -0400, Jeremy Bicha wrote:
> Control: severity -1 serious
> Tags: fixed-upstream
> 
> It looks to me like upstream has ported gasp to Python3 and GObject
> Introspection.
> 
> https://launchpad.net/gasp-core

Hi Luke,
are you still interested in maintaining python-gasp/updating it to
the current upstream? Otherwise I'll file a removal bug, it's among
the last handful of packages blocking the pygtk removal at this point.

Cheers,
Moritz

Bug#954822: openjdk-11-jre: Java application (Eclipse) regularly crashes with SIGSEGV

[Michael Meier]

I've downgraded libc6 to 2.29-10 again.
Still the same behaviour.
So i've downgraded all the openjdk packages to 11.0.4+11-1~deb10u1 .
Still the same result.

Could it be possible that it is an eclipse problem? I've recently 
updated to the new 2020-03 version.

I thought a programm shouldn't be able to sigsegv the virtual machine.


On 23.03.20 21:26, Michael Meier wrote:

Package: openjdk-11-jre
Version: 11.0.6+10-2
Severity: important

Recently Eclipse regularly crashes with a sigsevg.
I'm pretty sure that started happening since libc6 was updated on my system
about 1 week ago. Before I've never had that problem.
Unfortunately I can't downgrade it easily to test it out, since to many
packages depend on it.

Here is the message:

1 error
#
# A fatal error has been detected by the Java Runtime Environment:
#
#  SIGSEGV (0xb) at pc=0x7fa351edd245, pid=23923, tid=24047
#
# JRE version: OpenJDK Runtime Environment (11.0.6+10) (build 11.0.6+10-post-
Debian-2)
# Java VM: OpenJDK 64-Bit Server VM (11.0.6+10-post-Debian-2, mixed mode,
sharing, tiered, compressed oops, g1 gc, linux-amd64)
# Problematic frame:
# C  [libpthread.so.0+0x11245]  pthread_getcpuclockid+0x5
#
# No core dump will be written. Core dumps have been disabled. To enable core
dumping, try "ulimit -c unlimited" before starting Java again
#
# An error report file with more information is saved as:
# /home/rmm/hs_err_pid23923.log
Compiled method (nm)  372019 35610 n 0
sun.management.ThreadImpl::getThreadTotalCpuTime0 (native)
  total in heap  [0x7fa33d6cd310,0x7fa33d6cd6b0] = 928
  relocation [0x7fa33d6cd488,0x7fa33d6cd4b8] = 48
  main code  [0x7fa33d6cd4c0,0x7fa33d6cd6b0] = 496
#
# If you would like to submit a bug report, please visit:
#   https://bugs.debian.org/openjdk-11
#

let's see if report bug let me attach the mentioned file ;-)



-- System Information:
Debian Release: 10.3
   APT prefers stable
   APT policy: (990, 'stable'), (500, 'stable-updates'), (400, 'testing'), 
(300, 'unstable')
Architecture: amd64 (x86_64)

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

Versions of packages openjdk-11-jre depends on:
ii  libc62.30-2
ii  libgif7  5.1.4-3
ii  libgl1   1.1.0-1
ii  libjpeg62-turbo  1:1.5.2-2+b1
ii  libpng16-16  1.6.36-6
ii  libx11-6 2:1.6.7-1
ii  libxext6 2:1.3.3-1+b2
ii  openjdk-11-jre-headless  11.0.6+10-2

Versions of packages openjdk-11-jre recommends:
ii  fonts-dejavu-extra   2.37-1
ii  libatk-wrapper-java-jni  0.38.0-1~bpo10+1

openjdk-11-jre suggests no packages.

-- no debconf information

Bug#953863: python3-stem: "RuntimeError: dictionary keys changed during iteration" with python 3.8

[Scott Kitterman]

On Sat, 14 Mar 2020 09:23:49 +0100 intrig...@debian.org wrote:
> Package: python3-stem
> Version: 1.7.1-1.1
> Severity: serious
> 
> Hi,
> 
> onioncircuits fails to start on current sid:
> 
> Traceback (most recent call last):
>   File "/bin/onioncircuits", line 657, in 
> app = OnionCircuitsApplication()
>   File "/bin/onioncircuits", line 633, in __init__
> self.connect_controller()
>   File "/bin/onioncircuits", line 647, in connect_controller
> self.controller = stem.connection.connect(**connect_args)
>   File "/usr/lib/python3/dist-packages/stem/connection.py", line 291, in 
connect
> return _connect_auth(control_connection, password, password_prompt, 
chroot_path, controller)
>   File "/usr/lib/python3/dist-packages/stem/connection.py", line 375, in 
_connect_auth
> return controller(control_socket, is_authenticated = True)
>   File "/usr/lib/python3/dist-packages/stem/control.py", line 1057, in 
__init__
> super(Controller, self).__init__(control_socket, is_authenticated)
>   File "/usr/lib/python3/dist-packages/stem/control.py", line 585, in 
__init__
> self._post_authentication()
>   File "/usr/lib/python3/dist-packages/stem/control.py", line 3902, in 
_post_authentication
> owning_pid = self.get_conf('__OwningControllerProcess', None)
>   File "/usr/lib/python3/dist-packages/stem/control.py", line 2170, in 
get_conf
> entries = self.get_conf_map(param, default, multiple)
>   File "/usr/lib/python3/dist-packages/stem/control.py", line 2273, in 
get_conf_map
> for key in reply:
> RuntimeError: dictionary keys changed during iteration
> 
> 
> onionshare-gui fails to start with the same error since I upgraded to
> python 3.8.
> 
> I think that's https://trac.torproject.org/projects/tor/ticket/30882,
> which was fixed upstream with this commit:
> https://gitweb.torproject.org/stem.git/commit/stem/control.py?
id=b5aecb743d33db1a6378d59792d8e57305b6c6f2
> 
> I confirm that this commit fixes the problem I'm experiencing with
> onioncircuits and onionshare.
> 
> Until you, or someone else, finds time to package the 1.8.0 upstream
> release, could you please import that fix as a Debian patch?
> Alternatively, would you mind if someone else did that as an NMU?

I'm going to NMU this since it's one of the python3.8 transition blockers. NMU 
diff attached.

Scott Kdiff -Nru python-stem-1.7.1/debian/changelog python-stem-1.7.1/debian/changelog
--- python-stem-1.7.1/debian/changelog	2019-10-05 21:50:32.0 -0400
+++ python-stem-1.7.1/debian/changelog	2020-03-24 16:47:02.0 -0400
@@ -1,3 +1,10 @@
+python-stem (1.7.1-1.2) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Add fix from upstream to fix dictionary key error (Closes: #953863
+
+ -- Scott Kitterman   Tue, 24 Mar 2020 16:47:02 -0400
+
 python-stem (1.7.1-1.1) unstable; urgency=medium
 
   * Non-maintainer upload.
diff -Nru python-stem-1.7.1/debian/patches/key_order.patch python-stem-1.7.1/debian/patches/key_order.patch
--- python-stem-1.7.1/debian/patches/key_order.patch	1969-12-31 19:00:00.0 -0500
+++ python-stem-1.7.1/debian/patches/key_order.patch	2020-03-24 16:47:02.0 -0400
@@ -0,0 +1,18 @@
+Description: Fix from upstream to fix dictionary key error
+Author: Scott Kitterman 
+Bug-Debian: https://bugs.debian.org/953863
+Origin: https://gitweb.torproject.org/stem.git/commit/?id=b5aecb7
+Forwarded: not-needed
+Last-Update: 2020-03-24
+
+--- python-stem-1.7.1.orig/stem/control.py
 python-stem-1.7.1/stem/control.py
+@@ -2270,7 +2270,7 @@ class Controller(BaseController):
+   # entries since the user didn't request those by their key, so we can't
+   # be sure what they wanted.
+ 
+-  for key in reply:
++  for key in list(reply):
+ if not key.lower() in MAPPED_CONFIG_KEYS.values():
+   user_expected_key = _case_insensitive_lookup(params, key, key)
+ 
diff -Nru python-stem-1.7.1/debian/patches/series python-stem-1.7.1/debian/patches/series
--- python-stem-1.7.1/debian/patches/series	1969-12-31 19:00:00.0 -0500
+++ python-stem-1.7.1/debian/patches/series	2020-03-24 16:47:02.0 -0400
@@ -0,0 +1 @@
+key_order.patch


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

Bug#954890: RM: gourmet -- RoQA; Depends on Python 2 / pygtk2

[Moritz Muehlenhoff]

Package: ftp.debian.org
Severity: normal

Please remove gourmet. pygtk2 is now going away and it's among the
last handful of packages still using it. Upstream development has
stalled and https://github.com/thinkle/gourmet/issues/696 or
https://github.com/thinkle/gourmet/issues/696 haven't seen any
updates.

Cheers,
Moritz

Bug#954887: Returning UPnP response with 200 items out of 246 total matches

[Sebastian Ramacher]

Control: forwarded -1 https://trac.videolan.org/vlc/ticket/15876
Control: tags -1 upstream

On 2020-03-24 21:57:44, Mathieu Malaterre wrote:
> Source: vlc
> Version: 3.0.8-0+deb10u1
> 
> It seems that VLC cannot display all the Movies from my kodi
> installation (over UPnP).
> 
> For some reason I see in the debug log of kodi that only a portion of
> the files are being send, it looks as if this is chunked into section
> of 200 movies, the remaining should be requested.
> 
> Log from kodi:
> 
> LibreELEC # grep UPnP /storage/.kodi/temp/kodi.log | grep -v videodb
> 2020-03-24 21:35:20.840 T:1484030848   DEBUG: UPnP Translated id to
> 'virtualpath://upnproot/'
> 2020-03-24 21:35:20.841 T:1484030848INFO: UPnP: Received Browse
> DirectChildren request for object '0', with sort criteria
> 2020-03-24 21:35:20.843 T:1484030848   DEBUG: Building UPnP response
> with filter '*', starting @ 0 with 5000 requested
> 2020-03-24 21:35:20.843 T:1484030848   DEBUG: UPnP: Building didl for
> object 'musicdb://'
> 2020-03-24 21:35:20.844 T:1484030848   DEBUG: UPnP: Building didl for
> object 'library://video/'
> 2020-03-24 21:35:20.844 T:1484030848   DEBUG: Returning UPnP response
> with 2 items out of 2 total matches
> 2020-03-24 21:35:31.209 T:1484030848   DEBUG: UPnP Translated id to
> 'library://video/'
> 2020-03-24 21:35:31.210 T:1484030848INFO: UPnP: Received Browse
> DirectChildren request for object 'library://video/', with sort
> criteria
> 2020-03-24 21:35:31.231 T:1484030848   DEBUG: Building UPnP response
> with filter '*', starting @ 0 with 5000 requested
> 2020-03-24 21:35:31.281 T:1484030848   DEBUG: UPnP: Building didl for
> object 'library://video/movies/'
> 2020-03-24 21:35:31.301 T:1484030848   DEBUG: UPnP: Building didl for
> object 'library://video/musicvideos/'
> 2020-03-24 21:35:31.313 T:1484030848   DEBUG: UPnP: Building didl for
> object 'library://video/files.xml/'
> 2020-03-24 21:35:31.326 T:1484030848   DEBUG: UPnP: Building didl for
> object 'library://video/playlists.xml/'
> 2020-03-24 21:35:31.327 T:1484030848   DEBUG: Returning UPnP response
> with 4 items out of 4 total matches
> 2020-03-24 21:35:47.962 T:1484030848   DEBUG: UPnP Translated id to
> 'library://video/movies/'
> 2020-03-24 21:35:47.962 T:1484030848INFO: UPnP: Received Browse
> DirectChildren request for object 'library://video/movies/', with sort
> criteria
> 2020-03-24 21:35:47.990 T:1484030848   DEBUG: Building UPnP response
> with filter '*', starting @ 0 with 5000 requested
> 2020-03-24 21:35:48.037 T:1484030848   DEBUG: UPnP: Building didl for
> object 'library://video/movies/recentlyaddedmovies.xml/'
> 2020-03-24 21:35:48.054 T:1484030848   DEBUG: UPnP: Building didl for
> object 'library://video/movies/genres.xml/'
> 2020-03-24 21:35:48.066 T:1484030848   DEBUG: UPnP: Building didl for
> object 'library://video/movies/titles.xml/'
> 2020-03-24 21:35:48.079 T:1484030848   DEBUG: UPnP: Building didl for
> object 'library://video/movies/years.xml/'
> 2020-03-24 21:35:48.091 T:1484030848   DEBUG: UPnP: Building didl for
> object 'library://video/movies/actors.xml/'
> 2020-03-24 21:35:48.103 T:1484030848   DEBUG: UPnP: Building didl for
> object 'library://video/movies/directors.xml/'
> 2020-03-24 21:35:48.116 T:1484030848   DEBUG: UPnP: Building didl for
> object 'library://video/movies/studios.xml/'
> 2020-03-24 21:35:48.128 T:1484030848   DEBUG: UPnP: Building didl for
> object 'library://video/movies/sets.xml/'
> 2020-03-24 21:35:48.140 T:1484030848   DEBUG: UPnP: Building didl for
> object 'library://video/movies/country.xml/'
> 2020-03-24 21:35:48.152 T:1484030848   DEBUG: UPnP: Building didl for
> object 'library://video/movies/tags.xml/'
> 2020-03-24 21:35:48.153 T:1484030848   DEBUG: Returning UPnP response
> with 10 items out of 10 total matches
> 2020-03-24 21:35:54.498 T:1484030848   DEBUG: UPnP Translated id to
> 'library://video/movies/titles.xml/'
> 2020-03-24 21:35:54.498 T:1484030848INFO: UPnP: Received Browse
> DirectChildren request for object
> 'library://video/movies/titles.xml/', with sort criteria
> 2020-03-24 21:35:54.722 T:1484030848   DEBUG: Building UPnP response
> with filter '*', starting @ 0 with 5000 requested
> 2020-03-24 21:35:55.648 T:1484030848   DEBUG: Returning UPnP response
> with 200 items out of 246 total matches

That's https://trac.videolan.org/vlc/ticket/15876

Best
-- 
Sebastian Ramacher


signature.asc
Description: PGP signature

Bug#954889: RM: nxt-python -- RoQA; Depends on Python 2, pygtk

[Moritz Muehlenhoff]

Package: ftp.debian.org
Severity: normal

Please remove nxt-python. It's among the last handful of package blocking
the pygtk2 removal and a port to Python 3 is not immiment, the homepage
carries the note "

| DISCLAIMER: The NXT-Python v3 implementation is incomplete. Development is
| not active due to lack of interest. Find the latest stable version for
| Python2 on the releases page. Pull requests and improvements are very welcome!

Cheers,
Moritz

Bug#954887: Acknowledgement (Returning UPnP response with 200 items out of 246 total matches)

[Mathieu Malaterre]

Turns out this is a server side limitation in kodi+LibreELEC:

LibreELEC # cat /storage/.kodi/userdata/upnpserver.xml

e6ed9e0b-0580-e62c-4fc0-3a7e789f7575
1973
200

0


Simply changing 200 into 400 fixed the symptoms.

Bug#954831: RM: gcc-8, superseded by gcc-9

[Matthias Klose]

On 3/24/20 1:13 PM, Scott Kitterman wrote:
> On Tue, 24 Mar 2020 08:33:55 +0100 Matthias Klose  wrote:
>> Package: ftp.debian.org
>>
>> Please remove gcc-8, gcc-8-cross and gcc-8-cross-ports. superseded by gcc-9
>>
>>
> Removed gcc-8-cross and gcc-8-cross-ports, however gcc-8 itself still has 
> quite some rdepends that need to be resolved before it can be removed.  
> Please 
> remove the moreinfo tag once that's been taken care of.
> 
> Checking reverse dependencies...
> # Broken Depends:
> gcc-7: lib32gcc-7-dev [amd64]
>lib64gcc-7-dev [i386]
>libgcc-7-dev [amd64 i386]
>libx32gcc-7-dev [amd64 i386]

will be gone after the gcc-7 removal.

> gcc-8-cross-mipsen: gdc-8-mips64-linux-gnuabi64 [amd64 i386]
> gdc-8-mipsisa32r6-linux-gnu [amd64 i386]
> gdc-8-mipsisa32r6el-linux-gnu [amd64 i386]
> gdc-8-mipsisa64r6-linux-gnuabi64 [amd64 i386]
> gdc-8-mipsisa64r6el-linux-gnuabi64 [amd64 i386]

please remove as well.

> ghdl: ghdl-gcc [amd64 arm64 armel armhf i386 mips64el mipsel s390x]
>   ghdl-llvm [amd64 arm64 armel armhf i386 mips64el mipsel s390x]
>   ghdl-mcode [amd64 i386]

Marked for autoremoval on 06 April: #952110, #952324

> gprbuild: libgpr18 [mipsel]
>   libgpr2-dev [mipsel]
> libgnatcoll: libgnatcoll17 [mipsel]
>  libgnatcoll17-dev [mipsel]
> libgnatcoll-bindings: libgnatcoll-gmp17-dev [mipsel]
>   libgnatcoll-gmp18 [mipsel]
>   libgnatcoll-iconv17-dev [mipsel]
>   libgnatcoll-iconv18 [mipsel]
>   libgnatcoll-python17 [mipsel]
>   libgnatcoll-python17-dev [mipsel]
>   libgnatcoll-readline17-dev [mipsel]
>   libgnatcoll-readline18 [mipsel]
>   libgnatcoll-syslog1 [mipsel]
>   libgnatcoll-syslog1-dev [mipsel]
> libgnatcoll-db: libgnatcoll-sql1 [mipsel]
> libgnatcoll-sql1-dev [mipsel]
> libgnatcoll-sqlite-bin [mipsel]
> libgnatcoll-sqlite17-dev [mipsel]
> libgnatcoll-sqlite18 [mipsel]
> libgnatcoll-xref18 [mipsel]
> libgnatcoll-xref18-dev [mipsel]
> libxmlada: libxmlada-dom5 [mipsel]
>libxmlada-dom8-dev [mipsel]
>libxmlada-input5 [mipsel]
>libxmlada-input8-dev [mipsel]
>libxmlada-sax5 [mipsel]
>libxmlada-sax8-dev [mipsel]
>libxmlada-schema5 [mipsel]
>libxmlada-schema8-dev [mipsel]
>libxmlada-unicode5 [mipsel]
>libxmlada-unicode8-dev [mipsel]

CCing mips maintainers, and Ada maintainers.  Please can we drop mipsel as a
release architecture?

> llvm-toolchain-8: clang-8
>   libclang-8-dev
> llvm-toolchain-9: clang-9
>   libclang-9-dev

CCing LLVM maintainers.

> # Broken Build-Depends:
> gcc-7: gcc-8-base
> gcc-8-cross-mipsen: g++-8
> gcc-8-source (>= 8.3.0-7~)
> gccgo-8
> gdc-8
> gnat-8

see above, gcc-7 can be removed.

> gcc-mingw-w64: g++-8
>gcc-8-source (>= 8.3.0-10)
>gnat-8

Stephen, please can you upload the package from experimental to unstable? maybe
after building the binutils mingw64 package first.

> ghdl: gcc-8-source
>   gnat-8

see above.

> godot: libgcc-8-dev
>libstdc++-8-dev

has a RC issue, see #954608

> kfreebsd-10: gcc-8

CCed KFreebsd maintainers.

> mysql-workbench: g++-8

other RC issues

> open-ath9k-htc-firmware: gcc-8-source

Marked for autoremoval on 06 April: #951891

> openjdk-8: g++-8

I'll fix that one.

> openzwave: g++-8
>gcc-8

CCed Debian IoT

Bug#954887: Returning UPnP response with 200 items out of 246 total matches

[Mathieu Malaterre]

Source: vlc
Version: 3.0.8-0+deb10u1

It seems that VLC cannot display all the Movies from my kodi
installation (over UPnP).

For some reason I see in the debug log of kodi that only a portion of
the files are being send, it looks as if this is chunked into section
of 200 movies, the remaining should be requested.

Log from kodi:

LibreELEC # grep UPnP /storage/.kodi/temp/kodi.log | grep -v videodb
2020-03-24 21:35:20.840 T:1484030848   DEBUG: UPnP Translated id to
'virtualpath://upnproot/'
2020-03-24 21:35:20.841 T:1484030848INFO: UPnP: Received Browse
DirectChildren request for object '0', with sort criteria
2020-03-24 21:35:20.843 T:1484030848   DEBUG: Building UPnP response
with filter '*', starting @ 0 with 5000 requested
2020-03-24 21:35:20.843 T:1484030848   DEBUG: UPnP: Building didl for
object 'musicdb://'
2020-03-24 21:35:20.844 T:1484030848   DEBUG: UPnP: Building didl for
object 'library://video/'
2020-03-24 21:35:20.844 T:1484030848   DEBUG: Returning UPnP response
with 2 items out of 2 total matches
2020-03-24 21:35:31.209 T:1484030848   DEBUG: UPnP Translated id to
'library://video/'
2020-03-24 21:35:31.210 T:1484030848INFO: UPnP: Received Browse
DirectChildren request for object 'library://video/', with sort
criteria
2020-03-24 21:35:31.231 T:1484030848   DEBUG: Building UPnP response
with filter '*', starting @ 0 with 5000 requested
2020-03-24 21:35:31.281 T:1484030848   DEBUG: UPnP: Building didl for
object 'library://video/movies/'
2020-03-24 21:35:31.301 T:1484030848   DEBUG: UPnP: Building didl for
object 'library://video/musicvideos/'
2020-03-24 21:35:31.313 T:1484030848   DEBUG: UPnP: Building didl for
object 'library://video/files.xml/'
2020-03-24 21:35:31.326 T:1484030848   DEBUG: UPnP: Building didl for
object 'library://video/playlists.xml/'
2020-03-24 21:35:31.327 T:1484030848   DEBUG: Returning UPnP response
with 4 items out of 4 total matches
2020-03-24 21:35:47.962 T:1484030848   DEBUG: UPnP Translated id to
'library://video/movies/'
2020-03-24 21:35:47.962 T:1484030848INFO: UPnP: Received Browse
DirectChildren request for object 'library://video/movies/', with sort
criteria
2020-03-24 21:35:47.990 T:1484030848   DEBUG: Building UPnP response
with filter '*', starting @ 0 with 5000 requested
2020-03-24 21:35:48.037 T:1484030848   DEBUG: UPnP: Building didl for
object 'library://video/movies/recentlyaddedmovies.xml/'
2020-03-24 21:35:48.054 T:1484030848   DEBUG: UPnP: Building didl for
object 'library://video/movies/genres.xml/'
2020-03-24 21:35:48.066 T:1484030848   DEBUG: UPnP: Building didl for
object 'library://video/movies/titles.xml/'
2020-03-24 21:35:48.079 T:1484030848   DEBUG: UPnP: Building didl for
object 'library://video/movies/years.xml/'
2020-03-24 21:35:48.091 T:1484030848   DEBUG: UPnP: Building didl for
object 'library://video/movies/actors.xml/'
2020-03-24 21:35:48.103 T:1484030848   DEBUG: UPnP: Building didl for
object 'library://video/movies/directors.xml/'
2020-03-24 21:35:48.116 T:1484030848   DEBUG: UPnP: Building didl for
object 'library://video/movies/studios.xml/'
2020-03-24 21:35:48.128 T:1484030848   DEBUG: UPnP: Building didl for
object 'library://video/movies/sets.xml/'
2020-03-24 21:35:48.140 T:1484030848   DEBUG: UPnP: Building didl for
object 'library://video/movies/country.xml/'
2020-03-24 21:35:48.152 T:1484030848   DEBUG: UPnP: Building didl for
object 'library://video/movies/tags.xml/'
2020-03-24 21:35:48.153 T:1484030848   DEBUG: Returning UPnP response
with 10 items out of 10 total matches
2020-03-24 21:35:54.498 T:1484030848   DEBUG: UPnP Translated id to
'library://video/movies/titles.xml/'
2020-03-24 21:35:54.498 T:1484030848INFO: UPnP: Received Browse
DirectChildren request for object
'library://video/movies/titles.xml/', with sort criteria
2020-03-24 21:35:54.722 T:1484030848   DEBUG: Building UPnP response
with filter '*', starting @ 0 with 5000 requested
2020-03-24 21:35:55.648 T:1484030848   DEBUG: Returning UPnP response
with 200 items out of 246 total matches

Bug#945187: ImportError: No module named 'pip._vendor.retrying'

[Stefano Rivera]

Control: reassign -1 python3-pip
Control: affects -1 pypy3

Hi Brian (2019.11.20_15:04:44_-0800)
> # pypy3 -m pip

The recommended (and supported) mechanism is to use pip with a
virtualenv.

i.e.

pypy3 -m venv my-ve
ve/bin/python -m pip ...

That works.

However, this is a bug.

The vendor wheel hack in pip depends on sys.prefix, which is /usr for
python3 and /usr/lib/pypy3 from pypy3.

I don't know what the right solution here is. I can think of:
1. Create a symlink /usr/lib/pypy3/share/python-wheels in the pypy3
   package. Eww.
2. Special-case /usr/lib/pypy3 -> /usr in the pip patch.
3. Hard-code WHEEL_DIR in pip. Means it'll be used in venvs too.

Leaning towards 2.

SR

-- 
Stefano Rivera
  http://tumbleweed.org.za/
  +1 415 683 3272

Bug#885267: coccinelle: Depends on unmaintained pygtk

[Moritz Mühlenhoff]

On Tue, Feb 04, 2020 at 03:14:22PM -0300, eamanu wrote:
> Source: coccinelle
> Version: 1.0.4.deb-3
> 
> Hi everybody,
> 
> This issue was forward to upstream [1].
> 
> The dependency will be remove from coccinelle soon
> 
> [1] https://systeme.lip6.fr/pipermail/cocci/2020-February/006836.html

Dear Ocaml maintainers,
This was fixed in  
https://github.com/coccinelle/coccinelle/commit/2a8bcf6dbb1eb68004a3db56341c35d3d6daace4

It would be great if this were uploaded soon, coccinelle is among the last
handful of packages blocking the pygtk removal now.

Cheers,
Moritz

Bug#938327: Upstream references

[Moritz Mühlenhoff]

On Sun, Dec 15, 2019 at 02:01:30PM +, Jelmer Vernooij wrote:
> FWIW Upstream is working on Python 3 support here: 
> https://github.com/rabbitvcs/rabbitvcs/issues/279

Hi Ritesh,
this is fixed in 0.18, could you please update the package? rabbitcvs is among
the last handful of packages blocking the pygtk removal at this point.

Cheers,
Moritz

Bug#951819: closed by Debian FTP Masters (reply to Niels Thykier ) (Bug#951819: fixed in debhelper 12.10)

[Andy Caldwell]

Niels,

Thanks for fixing #951819.  I think you've actually also fixed (or at least
implemented a workaround for) #951820 but used the wrong bug ID in the
CHANGELOG so it's not been automatically closed etc.  I don't know if you
can change the CHANGELOG after the fact, but it would be good to at least
get the issue marked as fixed?

https://salsa.debian.org/debian/debhelper/-/commit/19ca1aea15ec5502cab4d9243a327f6f4ee2cc1d
is
the workaround I'm talking about.

Andy

On Tue, Mar 24, 2020 at 6:21 PM Debian Bug Tracking System <
ow...@bugs.debian.org> wrote:

> This is an automatic notification regarding your Bug report
> which was filed against the debhelper package:
>
> #951819: debhelper: dh_installsystemduser can't install parameterized
> services
>
> It has been closed by Debian FTP Masters 
> (reply to Niels Thykier ).
>
> Their explanation is attached below along with your original report.
> If this explanation is unsatisfactory and you have not received a
> better one in a separate message then please contact Debian FTP Masters <
> ftpmas...@ftp-master.debian.org> (reply to Niels Thykier <
> ni...@thykier.net>) by
> replying to this email.
>
>
> --
> 951819: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=951819
> Debian Bug Tracking System
> Contact ow...@bugs.debian.org with problems
>
>
>
> -- Forwarded message --
> From: Debian FTP Masters 
> To: 951819-cl...@bugs.debian.org
> Cc:
> Bcc:
> Date: Tue, 24 Mar 2020 18:19:09 +
> Subject: Bug#951819: fixed in debhelper 12.10
> Source: debhelper
> Source-Version: 12.10
> Done: Niels Thykier 
>
> We believe that the bug you reported is fixed in the latest version of
> debhelper, 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 951...@bugs.debian.org,
> and the maintainer will reopen the bug report if appropriate.
>
> Debian distribution maintenance software
> pp.
> Niels Thykier  (supplier of updated debhelper 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: SHA512
>
> Format: 1.8
> Date: Tue, 24 Mar 2020 15:55:09 +
> Source: debhelper
> Architecture: source
> Version: 12.10
> Distribution: unstable
> Urgency: medium
> Maintainer: Debhelper Maintainers 
> Changed-By: Niels Thykier 
> Closes: 939656 950723 951819 951917
> Changes:
>  debhelper (12.10) unstable; urgency=medium
>  .
>[ Niels Thykier ]
>* dh_installsystemd.1: Improve documentation about tmpfiles that
>  are now handled by dh_installtmpfiles in compat 13.
>* dh_installtmpfiles: Prefer debian/package.tmpfiles over
>  debian/package.tmpfile, but accept the old path with a warning.
>  Thanks to Michael Biebl for suggesting the change.
>* dh_strip: Automatically strip Link-Time Optimization (LTO)
>  symbols from static archives.  The format is not stable between
>  compiler versions.  Thanks to Matthias Klose for the
>  suggestion and for providing the exact options.
>  (Closes: #939656)
>* dh: Tweak the command-skipping optimization to skip commands
>  in a few more cases when the command is known not to react to
>  command line options.
>* dh,dh_installsytemd*: Work around broken NOOP promise caused by
>  dh_installsystemd* using nonstandard "package@" prefix for
>  pkgfiles.  Thanks to Badreddin Aboubakr and Andy Caldwell for
>  reporting it.  (Closes: #950723, #951819)
>  .
>[ Nicholas Guriev ]
>* cmake: Verbose autogen rules.
>* cmake: Skip install all dependency with compatibility level 13 and
>  above.
>  .
>[ Andy Caldwell ]
>* dh_installsystemduser: Fix bug that prevented dh_installsystemduser
>  from installing parameterized services.  (Closes: #951819)
>  .
>[ Translations ]
>* Update German translation (Chris Leick)  (Closes: #951917)
> Checksums-Sha1:
>  adef1db05ca8f20d5b93d1fec71524a7d5b0c885 1839 debhelper_12.10.dsc
>  8171da063f17d95a74b23c87bb2bd1a98c4652b3 525416 debhelper_12.10.tar.xz
>  75e0d34be7ca464dfdd9ba52182aa122a9763679 4606
> debhelper_12.10_source.buildinfo
> Checksums-Sha256:
>  934871f9a113f24616d10dcfb3d3a39d916cb7a80e478b93656164f5d27995ab 1839
> debhelper_12.10.dsc
>  74ef66f33d0a1ac8d854f9476b3ae8d08a65fadb6c7fa7e6155e62c52439676a 525416
> debhelper_12.10.tar.xz
>  451b679c0d242580e656aceb7834dcffa8d5ad7101f43b67bc8308e332db8e25 4606
> debhelper_12.10_source.buildinfo
> Files:
>  3acd0bd939678b2c65986c4adc9eba70 1839 devel optional debhelper_12.10.dsc
>  2e8b9ef9ed4a36b9b38cb3f453e900b7 525416 devel optional
> debhelper_12.10.tar.xz
>  3e1de02e9214f38444b2cde00cceb2d3 4606 devel optional
> 

Bug#951186: Please reconsider usage of perl-Array-IntSpan in licensecheck

[Sandro Mani]

So the current Array::IntSpan maintainer managed to track down the 
original author, which has agreed to relicense to Artistic-2.0, which 
resolves this issue.

Bug#953527: [apt] colour highlighted error/warn labels

[Julian Andres Klode]

On Tue, Mar 24, 2020 at 08:09:24PM +, jnq...@gmail.com wrote:
> Hi, Julian,
> 
> Thanks for adding the colour support in apt 2.0.1.
> 
> I'm curious though, most implementations use isatty() to determine the
> default colour control setting, which it seems that your implementation
> lacks, instead only outputting colour when explicitly enabled via `-o
> APT::Color=true`.
> 
> Was it a deliberate decision to not make use of isatty() to determine a
> default?

That's how it works, apt(8) sets APT::Color to true by default, and the
code sets it to false if stdout is not a tty. Which it already did before,
as you can see in apt list, for example.

As is customary, for compatibility reasons, apt-get(8) and apt-cache and 
friends do not change behavior.

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

Bug#954311: libgl1-mesa-dri: Makes KDE konsole unusable

[Stefan Fritsch]

Hi Timo,

Am 20.03.20 um 09:55 schrieb Timo Aaltonen:
> Please file it upstream, this is caused by the new 'iris' driver. In the
> meantime, you can force the previous driver with this in a ~/.drirc:
> 
> 
>   
> 
>   
> 
> 
> 
> Or run the app with the driver to verify it actually helps:
> 
> dri_driver=i965 ./app

That did not help. It seems Xorg itself also loads the iris driver and
that causes the drawing errors. But putting the config into /etc/drirc
did help.

Cheers,
Stefan

Bug#946836: Build failure on powerpc architectures

[Dirk Eddelbuettel]

Tomas, Martin,

The issue is still the long double.  The log pointed to by John reveals

gcc -std=gnu99 -I../../src/extra  -I. -I../../src/include -I../../src/include   
-I../../src/nmath -DHAVE_CONFIG_H   -fopenmp -fpic  -g -O2 
-fdebug-prefix-map=/<>=. -fstack-protector-strong -Wformat 
-Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2 -g -c arithmetic.c -o 
arithmetic.o
arithmetic.c:185:26: error: initializer element is not constant
  185 | static LDOUBLE q_1_eps = 1 / LDBL_EPSILON;
  |  ^
make[4]: *** [../../Makeconf:124: arithmetic.o] Error 1

And I thought we had that licked?  Any suggestions about what to try next?

In r-devel I see

#if HAVE_LONG_DOUBLE && (SIZEOF_LONG_DOUBLE > SIZEOF_DOUBLE)
# ifdef __PPC64__
 // PowerPC 64 (when gcc has -mlong-double-128) fails constant folding with 
LDOUBLE
#  define q_1_eps (1 / LDBL_EPSILON)
# else
static LDOUBLE q_1_eps = 1 / LDBL_EPSILON;
# endif
#else
static double  q_1_eps = 1 / DBL_EPSILON;
#endif

which is the same as what we have in R 3.6.3. So unless fixed, R 4.0.0 will
also fail :-/

My bad for noticing this earlier, and thanks to John for reopening the ticket.

Dirk

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

Bug#953527: [apt] colour highlighted error/warn labels

[jnqnfe]

Hi, Julian,

Thanks for adding the colour support in apt 2.0.1.

I'm curious though, most implementations use isatty() to determine the
default colour control setting, which it seems that your implementation
lacks, instead only outputting colour when explicitly enabled via `-o
APT::Color=true`.

Was it a deliberate decision to not make use of isatty() to determine a
default?

Regards,
Lyndon

Bug#954886: Please make autopkgtests cross-test-friendly

[Sebastien Bacher]

Package: libraw
Version: 0.19.5-1
Severity: minor
Tags: patch
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu focal ubuntu-patch

Dear maintainers,

In Ubuntu, we are in the process of moving the i386 architecture to a
compatibility-only layer on amd64, and therefore we are also moving our
autopkgtest infrastructure to test i386 binaries in a cross-environment.

This requires changes to some tests so that they are cross-aware and can
do the right thing.

The libxcb tests currently fail in this environment, because they are
build tests that do not invoke the toolchain in a cross-aware manner. 
I've verified that the attached patch lets the tests successfully build
(and run) i386 tests on an amd64 host.

Note that upstream autopkgtest doesn't currently set DEB_HOST_ARCH so
thisis a complete no-op in Debian for the moment.  Support for
cross-testing in autopkgtest is currently awaiting review at
https://salsa.debian.org/ci-team/autopkgtest/merge_requests/69 and once
landed, will still have no effect unless autopkgtest is invoked with a
'-a' option.  So this change should be safe to land in your package
despite this not being upstream in autopkgtest.

Thanks for considering,



diff -Nru libraw-0.19.5/debian/changelog libraw-0.19.5/debian/changelog
--- libraw-0.19.5/debian/changelog	2019-08-28 23:45:51.0 +0200
+++ libraw-0.19.5/debian/changelog	2020-03-24 16:36:35.0 +0100
@@ -1,3 +1,11 @@
+libraw (0.19.5-2) unstable; urgency=medium
+
+  * debian/tests/build:
+- Use the correct compiler for proposed autopkgtest cross-testing
+  support. 
+
+ -- Sebastien Bacher   Tue, 24 Mar 2020 16:36:35 +0100
+
 libraw (0.19.5-1) unstable; urgency=medium
 
   * New upstream release
diff -Nru libraw-0.19.5/debian/tests/smoketest libraw-0.19.5/debian/tests/smoketest
--- libraw-0.19.5/debian/tests/smoketest	2018-07-18 21:27:03.0 +0200
+++ libraw-0.19.5/debian/tests/smoketest	2020-03-24 16:36:20.0 +0100
@@ -1,6 +1,12 @@
 #!/bin/sh
 set -e
 
+if [ -n "${DEB_HOST_GNU_TYPE:-}" ]; then
+CROSS_COMPILE="$DEB_HOST_GNU_TYPE-"
+else
+CROSS_COMPILE=
+fi
+
 cd "$ADTTMP"
 cat > test.c << EOF
 #include 
@@ -15,6 +21,6 @@
 }
 
 EOF
-g++ -Wall -o test test.c -lraw
+${CROSS_COMPILE}g++ -Wall -o test test.c -lraw
 ./test
 objdump -p test | grep "libraw"

Bug#954885: /dev/bus/usb/*/* device file of printers assigned to "audio" group

[Till Kamppeter]

Package: libmtp-common
Version: 1.1.17-2
Severity: important

See my original bug report on Ubuntu:

https://bugs.launchpad.net/bugs/1863239

Hi,

When testing HPLIP I found out that CUPS backends can access my printer 
only when they are running as root, when they are running as the special 
user lp, as it is usually the case, they cannot access the printer.


So I tried to find out why and saw that the /dev/bus/usb/*/* device file 
for the printer has group ownership "audio" and not "lp":


till@till-x1yoga:~/ubuntu/hplip/focal/debian/hplip-3.19.12+dfsg0$ ll 
/dev/bus/usb/*/*

crw-rw-r-- 1 root root 189, 0 Feb 11 14:17 /dev/bus/usb/001/001
crw-rw-r-- 1 root root 189, 2 Feb 11 14:17 /dev/bus/usb/001/003
crw-rw-r-- 1 root root 189, 3 Feb 11 14:17 /dev/bus/usb/001/004
crw-rw-r-- 1 root plugdev 189, 4 Feb 14 12:23 /dev/bus/usb/001/005
crw-rw-r-- 1 root root 189, 5 Feb 11 14:17 /dev/bus/usb/001/006
crw-rw+ 1 root audio 189, 62 Feb 14 12:37 /dev/bus/usb/001/063
crw-rw-r-- 1 root root 189, 128 Feb 11 14:17 /dev/bus/usb/002/001
crw-rw-r-- 1 root root 189, 130 Feb 13 09:38 /dev/bus/usb/002/003
till@till-x1yoga:~/ubuntu/hplip/focal/debian/hplip-3.19.12+dfsg0$

The printer is the device /dev/bus/usb/001/063:

till@till-x1yoga:~/ubuntu/hplip/focal/debian/hplip-3.19.12+dfsg0$ lsusb
Bus 002 Device 003: ID 0b95:1790 ASIX Electronics Corp. AX88179 Gigabit 
Ethernet

Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 001 Device 005: ID 138a:0097 Validity Sensors, Inc.
Bus 001 Device 004: ID 04f2:b5ce Chicony Electronics Co., Ltd Integrated 
Camera

Bus 001 Device 003: ID 8087:0a2b Intel Corp.
Bus 001 Device 006: ID 056a:50b7 Wacom Co., Ltd Pen and multitouch sensor
Bus 001 Device 063: ID 03f0:7a12 HP, Inc HP OfficeJet Pro 8730
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
till@till-x1yoga:~/ubuntu/hplip/focal/debian/hplip-3.19.12+dfsg0$

This turned out to be a bug in the UDEV rules.

The file /lib/udev/rules.d/69-libmtp.rules of the libmtp-common assigns 
"audio" group ownership to devices which are supposed to be audio or 
video players and allow uploading files to them via USB using the MTP 
protocol.


First it includes some devices explicitly and then it lists thousands of 
supported devices. In the end there is some rule for passing a wide 
range of devices through an auto-probing:


-
# Autoprobe vendor-specific, communication and PTP devices
ENV{ID_MTP_DEVICE}!="1", ENV{MTP_NO_PROBE}!="1", 
ENV{COLOR_MEASUREMENT_DEVICE}!="1", ENV{ID_GPHOTO}!="1", 
ENV{libsane_matched}!="yes", ATTR{bDeviceClass}=="00|02|06|ef|ff", 
PROGRAM="mtp-probe /sys$env{DEVPATH} $attr{busnum} $attr{devnum}", 
RESULT=="1", SYMLINK+="libmtp-%k", MODE="660", GROUP="audio", 
ENV{ID_MTP_DEVICE}="1", ENV{ID_MEDIA_PLAYER}="1"

-

And this auto-probing tests positive on my printer:

till@till-x1yoga:~$ /lib/udev/mtp-probe 
/sys/devices/pci:00/:00:14.0/usb1/1-1 001 063

1
till@till-x1yoga:~$

Path taken from the output of "sudo udevadm monitor -e", blob with 
"ID_MEDIA_PLAYER" in it.


The device path of the printer I have taken from the blob in the udevadm 
output (attached to previous comment) which also contains 
"ID_MEDIA_PLAYER=1". So mtp-probe identifies my printer as a media 
player and assigns the device file to the "audio" group.


I assume that this happens to most or even all HP printers, so an 
exclusion of only my device via Vendor and Product ID would not be the 
correct solution.


There was already a measure against wrongly identifying HP printers as 
media players, but it is a rather dirty workaround which does not work 
any more (therefore this bug). The rule in the end of 69-libmtp.rules 
checks the absence of the env variable libsane_matched and this variable 
is set for all HP printers by HPLIP. First, this rule fails miserably if 
HPLIP is not installed, and I cannot imagine that the libmtp package 
depends on HPLIP only to identify unsupported devices. Also the libmtp 
rules are applied for both "add" and "bind" actions, whereas the rules 
of HPLIP (56-hpmud.rules) are only applied for "add" and so the bug 
happens on a "bind" action, here the HPLIP rules do not set said env 
variable and so the libmtp rules probe the HP printers.


One can theoretically work around this problem by mucking with the UDEV 
rules of HPLIP, but this is a REALLY DIRTY workaround, so please DO NOT 
add an hplip task to this bug report.


In addition, HPLIP will not be installed by default any more in the not 
too far future, as prnting and scanning will get snapped. Also we want 
printer driver Snaps (Printer Applications) not to run as root if 
possible, so we need to be sure that USB printer device files always 
belong to the group "lp" for all printer manufacturers and without HPLIP.


This patch would fix the bug:

--
--- /lib/udev/rules.d/69-libmtp.rules~  2020-02-11 13:06:23.0 +0100
+++ /lib/udev/rules.d/69-libmtp.rules   2020-03-19 21:01:48.696689026 +0100
@@ -26,6 

Bug#954884: Please make autopkgtests cross-test-friendly

[Sebastien Bacher]

Package: libcaca
Severity: minor
Tags: patch
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu focal ubuntu-patch

Dear maintainers,

In Ubuntu, we are in the process of moving the i386 architecture to a
compatibility-only layer on amd64, and therefore we are also moving our
autopkgtest infrastructure to test i386 binaries in a cross-environment.

This requires changes to some tests so that they are cross-aware and can
do the right thing.

The libxcb tests currently fail in this environment, because they are
build tests that do not invoke the toolchain in a cross-aware manner. 
I've verified that the attached patch lets the tests successfully build
(and run) i386 tests on an amd64 host.

Note that upstream autopkgtest doesn't currently set DEB_HOST_ARCH so
thisis a complete no-op in Debian for the moment.  Support for
cross-testing in autopkgtest is currently awaiting review at
https://salsa.debian.org/ci-team/autopkgtest/merge_requests/69 and once
landed, will still have no effect unless autopkgtest is invoked with a
'-a' option.  So this change should be safe to land in your package
despite this not being upstream in autopkgtest.

Thanks for considering,



diff -Nru libcaca-0.99.beta19/debian/changelog libcaca-0.99.beta19/debian/changelog
--- libcaca-0.99.beta19/debian/changelog	2019-04-06 22:18:41.0 +0200
+++ libcaca-0.99.beta19/debian/changelog	2020-03-24 16:38:08.0 +0100
@@ -1,3 +1,11 @@
+libcaca (0.99.beta19-2.2) unstable; urgency=medium
+
+  * debian/tests/build:
+- Use the correct compiler for proposed autopkgtest cross-testing
+  support.
+
+ -- Sebastien Bacher   Tue, 24 Mar 2020 16:38:08 +0100
+
 libcaca (0.99.beta19-2.1) unstable; urgency=medium
 
   * Non-maintainer upload.
diff -Nru libcaca-0.99.beta19/debian/tests/build libcaca-0.99.beta19/debian/tests/build
--- libcaca-0.99.beta19/debian/tests/build	2014-05-16 21:30:34.0 +0200
+++ libcaca-0.99.beta19/debian/tests/build	2020-03-24 16:38:08.0 +0100
@@ -5,6 +5,12 @@
 # Author: Vibhav Pant 
 
 set -e
+ 
+if [ -n "${DEB_HOST_GNU_TYPE:-}" ]; then
+CROSS_COMPILE="$DEB_HOST_GNU_TYPE-"
+else
+CROSS_COMPILE=
+fi
 
 WORKDIR=$(mktemp -d)
 trap "rm -rf $WORKDIR" 0 INT QUIT ABRT PIPE TERM
@@ -28,7 +34,7 @@
 }
 EOF
 
-gcc -o caca_test caca_test.c `pkg-config --cflags --libs caca` -Wall -Werror
+${CROSS_COMPILE}gcc -o caca_test caca_test.c `${CROSS_COMPILE}pkg-config --cflags --libs caca` -Wall -Werror
 echo "build: OK"
 [ -x caca_test ]
 export TERM=linux

Bug#954883: [Skins --> get more] doesn't

[Harald Dunkel]

Package: kodi
Version: 2:18.6+dfsg1-1

If I try to pick up my favorite skin using [get more], then it
just jumps back to the settings menu, instead of downloading
and showing an additional list of skins.

Installing kodi-repository-kodi did not help.


Regards
Harri

Bug#954010: improvements to mbox viewer

[Mattia Rizzolo]

On Tue, Mar 24, 2020 at 07:29:06PM +0100, Enrico Zini wrote:
> On Tue, Mar 24, 2020 at 06:46:22PM +0100, Mattia Rizzolo wrote:
> > It feels odd to scroll with the "mouse wheel" and have also the focused
> > mail change, but at least the mail list now also scroll, so this bug is
> > fixed for me.
> 
> Odd as in unusual, or odd as in uncomfortable?

both, I don't find it much usable in that context, I'd rather explicitly
click on something to change mail (or, press the arrow keys)

> Scrolling with the mouse wheel on the mail text doesn't scroll the list
> right?

Right.
Also, I can always manually move the browser scroll bar, so it's not
really causing me much trouble.

-- 
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#954879: Obsolete Suggests

[Hilmar Preuße]

Control: tags -1 + pending

Am 24.03.2020 um 19:53 teilte Moritz Muehlenhoff mit:

> rubber switched to Python 3, but still suggests
> python-prompt-toolkit and python-pygments
> 
Solved in, git tag pending.

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



signature.asc
Description: OpenPGP digital signature

Bug#954882: linux-image-5.4.0-4-amd64: [i915] Screen flickering when connecting external monitor to laptop

[Miguel Bernabeu]

Package: src:linux
Version: 5.4.19-1
Severity: normal

Dear Maintainer,

I have recently started to use an external monitor for this laptop and
the issue has surfaced. I have upgraded the system to the latest
release without fixing the issue. I'm unsure if previous versions of
these packages avoided the issue or not.

Some research pointed the error messages present in the dmesg output
have already been related to a kernel bug in the past:
https://bugs.freedesktop.org/show_bug.cgi?id=101868

[ 1812.607941] [drm:intel_cpu_fifo_underrun_irq_handler [i915]] *ERROR* CPU 
pipe A FIFO underrun

This laptop is a custom build.


   * What led up to the situation?

   Plugging in an external monitor via HDMI.
 
   * What exactly did you do (or not do) that was effective (or
 ineffective)?

 Rebooting with screen attached does not solve the problem.
 Booting without external screen solves the issue.
 
   * What was the outcome of this action?

 Intermittent flickering. When the screen is updated frequently
 (as when typing) the problem almost disappears. If the screen is
 almost idle, the flickering happens several times per second.

   * What outcome did you expect instead?

 No flickering on the screen

-- Package-specific info:
** Version:
Linux version 5.4.0-4-amd64 (debian-ker...@lists.debian.org) (gcc version 9.2.1 
20200203 (Debian 9.2.1-28)) #1 SMP Debian 5.4.19-1 (2020-02-13)

** Command line:
BOOT_IMAGE=/boot/vmlinuz-5.4.0-4-amd64 
root=UUID=e4908201-67d3-4615-9d56-d1cef5accb71 ro pcie_aspm=off quiet

** Tainted: OE (12288)
 * externally-built ("out-of-tree") module was loaded
 * unsigned module was loaded

** Kernel log:
[5.761317] EXT4-fs (nvme0n1p6): mounted filesystem with ordered data mode. 
Opts: (null)
[5.768320] RAPL PMU: API unit is 2^-32 Joules, 5 fixed counters, 655360 ms 
ovfl timer
[5.768322] RAPL PMU: hw unit of domain pp0-core 2^-14 Joules
[5.768322] RAPL PMU: hw unit of domain package 2^-14 Joules
[5.768323] RAPL PMU: hw unit of domain dram 2^-14 Joules
[5.768324] RAPL PMU: hw unit of domain pp1-gpu 2^-14 Joules
[5.768324] RAPL PMU: hw unit of domain psys 2^-14 Joules
[5.768703] uvcvideo: Found UVC 1.00 device Chicony USB2.0 Camera (04f2:b59e)
[5.780276] Bluetooth: Core ver 2.22
[5.780287] NET: Registered protocol family 31
[5.780288] Bluetooth: HCI device and connection manager initialized
[5.780290] Bluetooth: HCI socket layer initialized
[5.780292] Bluetooth: L2CAP socket layer initialized
[5.780294] Bluetooth: SCO socket layer initialized
[5.781059] uvcvideo 1-5:1.0: Entity type for entity Extension 4 was not 
initialized!
[5.781061] uvcvideo 1-5:1.0: Entity type for entity Processing 2 was not 
initialized!
[5.781062] uvcvideo 1-5:1.0: Entity type for entity Camera 1 was not 
initialized!
[5.782707] input: Chicony USB2.0 Camera: Chicony  as 
/devices/pci:00/:00:14.0/usb1/1-5/1-5:1.0/input/input21
[5.782813] usbcore: registered new interface driver uvcvideo
[5.782814] USB Video Class driver (1.1.1)
[5.828469] Intel(R) Wireless WiFi driver for Linux
[5.828470] Copyright(c) 2003- 2015 Intel Corporation
[5.830288] usbcore: registered new interface driver btusb
[5.846881] pcieport :00:1c.3: Intel SPT PCH root port ACS workaround 
enabled
[5.853995] audit: type=1400 audit(1585075392.750:2): apparmor="STATUS" 
operation="profile_load" profile="unconfined" name="lsb_release" pid=384 
comm="apparmor_parser"
[5.858053] Bluetooth: hci0: Firmware revision 0.1 build 216 week 27 2019
[5.859734] audit: type=1400 audit(1585075392.758:3): apparmor="STATUS" 
operation="profile_load" profile="unconfined" name="/usr/sbin/haveged" pid=385 
comm="apparmor_parser"
[5.861989] cryptd: max_cpu_qlen set to 1000
[5.866187] audit: type=1400 audit(1585075392.762:4): apparmor="STATUS" 
operation="profile_load" profile="unconfined" 
name="/usr/lib/ibus/ibus-engine-hangul" pid=399 comm="apparmor_parser"
[5.867087] audit: type=1400 audit(1585075392.766:5): apparmor="STATUS" 
operation="profile_load" profile="unconfined" 
name="/usr/lib/ibus/ibus-setup-hangul" pid=387 comm="apparmor_parser"
[5.867089] audit: type=1400 audit(1585075392.766:6): apparmor="STATUS" 
operation="profile_load" profile="unconfined" 
name="/usr/lib/ibus/ibus-setup-hangul//python_profile" pid=387 
comm="apparmor_parser"
[5.869150] iwlwifi :02:00.0: firmware: direct-loading firmware 
iwlwifi-9260-th-b0-jf-b0-46.ucode
[5.869167] iwlwifi :02:00.0: Found debug destination: EXTERNAL_DRAM
[5.869168] iwlwifi :02:00.0: Found debug configuration: 0
[5.869571] iwlwifi :02:00.0: loaded firmware version 46.a41adfe7.0 
op_mode iwlmvm
[5.870371] audit: type=1400 audit(1585075392.766:7): apparmor="STATUS" 
operation="profile_load" profile="unconfined" name="/usr/bin/man" pid=408 
comm="apparmor_parser"
[5.870373] audit: type=1400 

Bug#946836: Build failure on powerpc architectures

[John Paul Adrian Glaubitz]

On 3/24/20 8:32 PM, Dirk Eddelbuettel wrote:
> In r-devel I see
> 
> #if HAVE_LONG_DOUBLE && (SIZEOF_LONG_DOUBLE > SIZEOF_DOUBLE)
> # ifdef __PPC64__
>  // PowerPC 64 (when gcc has -mlong-double-128) fails constant folding with 
> LDOUBLE
> #  define q_1_eps (1 / LDBL_EPSILON)
> # else
> static LDOUBLE q_1_eps = 1 / LDBL_EPSILON;
> # endif
> #else
> static double  q_1_eps = 1 / DBL_EPSILON;
> #endif
> 
> which is the same as what we have in R 3.6.3. So unless fixed, R 4.0.0 will
> also fail :-/

See my other mail. Just use __powerpc__ instead of __PPC64__ and
adjust the comment.

Uploading a manually built package for powerpc in the meantime, so don't
be confused it shows as fixed.

Adrian

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

Bug#946836: Build failure on powerpc architectures

[John Paul Adrian Glaubitz]

Hi!

On 3/24/20 8:01 PM, John Paul Adrian Glaubitz wrote:
> It would be nice if this bug could be fixed as the missing r-base package
> is blocking a lot of other packages on powerpc.

This can be easily fixed by replacing __PPC64__ with __powerpc__ which is 
defined
on all PowerPC architectures (ppc64el, ppc64, powerpc).

Suggestion to change the patch into:

 #if HAVE_LONG_DOUBLE && (SIZEOF_LONG_DOUBLE > SIZEOF_DOUBLE)
+# ifdef __powerpc__
+ // PowerPC (when gcc has -mlong-double-128) breaks here ...
+#  define q_1_eps (1 / LDBL_EPSILON)
+# else
 static LDOUBLE q_1_eps = 1 / LDBL_EPSILON;
+# endif
 #else
 static double  q_1_eps = 1 / DBL_EPSILON;
 #endif

Proof that __powerpc__ is available on all three PowerPC targets.

On powerpc architecture:

(sid-powerpc-sbuild2)root@kapitsa:/# gcc -dM -E - < /dev/null|grep __powerpc__
#define __powerpc__ 1
(sid-powerpc-sbuild2)root@kapitsa:/#

On ppc64 architecture:

(sid-ppc64-sbuild2)root@kapitsa:/# gcc -dM -E - < /dev/null|grep __powerpc__
#define __powerpc__ 1
(sid-ppc64-sbuild2)root@kapitsa:/#

On ppc64el architecture:

(sid_ppc64el-dchroot)glaubitz@plummer:~$ gcc -dM -E - < /dev/null|grep 
__powerpc__
#define __powerpc__ 1
(sid_ppc64el-dchroot)glaubitz@plummer:~$

Thanks,
Adrian

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

Bug#954820: postfix's autopkgtest on arm64 is flaky; this is blocking e2fsprogs

[Paul Gevers]

Hi Theodore,

On Tue, 24 Mar 2020 10:53:28 -0400 "Theodore Y. Ts'o"  wrote:
> Thanks; it looks like the CI folks have managed to fix the postfix
> failure, so at least the short-term failure is fixed.

I don't think anybody did anything.

> The reason why
> I was concerned was it looks like autopkgtest doesn't retry after
> failures,

But I bet it's due to this being not true. The migration software
reschedules regressions after a day.

I have no clue yet about those pty's yet, but I only spotted it once.
That issue isn't the cause of the other failures I checked.

[1]
https://ci.debian.net/user/britney/jobs?package=postfix=%5B%5D=arm64

Paul




signature.asc
Description: OpenPGP digital signature

Bug#946836: Build failure on powerpc architectures

[John Paul Adrian Glaubitz]

(Re-sent as the bug report had to be unarchived first)

Control: reopen -1
User: debian-powe...@lists.debian.org
Usertags: powerpc
X-Debbugs-CC: debian-powe...@lists.debian.org

Hello!

This bug is still present [1], not sure why this bug report was closed.

A Debian powerpc/ppc64 porterbox is available, no restrictions apply [2],
it's available to all Debian Developers and anyone with a Debian guest
account.

The GCC compile farm also has PowerPC boxes available [3], any open source
developer can request access to a PowerPC for free [4].

It would be nice if this bug could be fixed as the missing r-base package
is blocking a lot of other packages on powerpc.

PS: Please always set the proper usertags and CC the architecture mailing list
when filing architecture-specific bugs.

Thanks,
Adrian

> [1] 
> https://buildd.debian.org/status/fetch.php?pkg=r-base=powerpc=3.6.3-1=1583981629=0
> [2] https://db.debian.org/machines.cgi?host=perotto
> [3] https://gcc.gnu.org/wiki/CompileFarm
> [4] https://cfarm.tetaneutral.net/users/new/

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

Bug#816654: youtube-dl: SSL error with vimeo URLs

[Daniel Baumann]

close 2020.01.24-0.1
thanks

Hi,

I've confirmed that the video you mentioned can be downloaded with the
current version of youtube-dl in sid (which uses python3), hence closing
the bug report.

Regards,
Daniel

Bug#954859: apt-listbugs: listbugs prompt will only accept a package name for pinning

[Francesco Poli]

On Tue, 24 Mar 2020 10:29:05 -0400 Calum McConnell wrote:

> When it comes time to upgrade or not, or pin packages, the 'p'
> menu requires the user to enter the full package name of whatever
> package they want to stop the upgrade of.

Hello Calum,
thanks for your interest in seeing a usability improvement in
apt-listbugs!

> This is undesireable for obvious reasons, since many packages
> have lengthy names.

While waiting for the new feature to be implemented, please note that
it is often possible to copy and paste package names, whenever they
are lengthy or, at any rate, in order to avoid typos.
I acknowledge that this is not *always* feasible and/or convenient, but
still...

> A more concise approach would be to also accept a bug number,
> like other menu items.  To prevent collision between actual
> packages and bugs, the syntax could be #, as # cannot
> appear in any valid package names.

This new feature has already been suggested, among other things, in bug
[#921583]. I will probably attempt an implementation in the future, but
I haven't yet got around to it, unfortunately.

[#921583]: 

Bye.


-- 
 http://www.inventati.org/frx/
 There's not a second to spare! To the laboratory!
. Francesco Poli .
 GnuPG key fpr == CA01 1147 9CD2 EFDF FB82  3925 3E1C 27E1 1F69 BFFE


pgpzLIEQ2dUHJ.pgp
Description: PGP signature

Bug#954881: RM: meshlab [armel armhf] -- RoQA; obsolete binaries

[Moritz Muehlenhoff]

Package: ftp.debian.org
Severity: normal

Please remove meshlab on armel/armhf. These are outdated binaries and
no longer build with the new version (due to only having OpenGL-ES)

Cheers,
Moritz

Bug#954879: Obsolete Suggests

[Moritz Muehlenhoff]

Package: rubber
Severity: normal

rubber switched to Python 3, but still suggests python-prompt-toolkit and 
python-pygments

Cheers,
Moritz

Bug#954880: RM: python-macaron -- RoQA; Depends on Python 2, unmaintained

[Moritz Muehlenhoff]

Package: ftp.debian.org
Severity: normal

Please remove python-macaron. It depends on Python 2, there are no
reverse deps and there hasn't been an upload since 2012.

Cheers,
Moritz

Bug#954878: Obsolete suggests on python-pygments

[Moritz Muehlenhoff]

Package: ranger
Severity: normal

ranger switched to Python 3, but still suggests

highlight | python-pygments

That should now be python3-pygments.

Cheers,
Moritz

Bug#954877: RM: ptex2tex -- RoQA; Depends on Python 2

[Moritz Muehlenhoff]

Package: ftp.debian.org
Severity: normal

Please remove ptex2tex. It depends on Python 2, is dead upstream and
unmaintained (last upload in 2011)

Cheers,
Moritz

Bug#954876: RM: xow -- ROM; licensing issue

[Samuel Henrique]

Package: ftp.debian.org
Severity: important

Hi,

We recently found out there is an issue with the license of one of
xow's files, upstream discussion is available here:
https://github.com/medusalix/xow/issues/15#issuecomment-602301493

The bulk of it is that upstream has a third party binary blob with
unknown license, which upstream previously thought had a DFSG
compliant one.

I'm asking for the removal of the package until the issue is resolved,
when that happens I will submit the package to NEW once again.

This is a non-free package which is not on testing and it's not
whitelisted on our build infrastructure.

Although upstream still has the file and lists the wrong license, I'm
being cautious here and asking for the removal because it's a
confirmed issue.

$ dak rm -Rn xow
Will remove the following packages from unstable:

   xow |  0.3-3 | source

Maintainer: Samuel Henrique 

--- Reason ---

--

Checking reverse dependencies...
No dependency problem found.


Thanks

-- 
Samuel Henrique 

Bug#954010: improvements to mbox viewer

[Enrico Zini]

On Tue, Mar 24, 2020 at 06:46:22PM +0100, Mattia Rizzolo wrote:

> It feels odd to scroll with the "mouse wheel" and have also the focused
> mail change, but at least the mail list now also scroll, so this bug is
> fixed for me.

Odd as in unusual, or odd as in uncomfortable?

Scrolling with the mouse wheel on the mail text doesn't scroll the list
right?


Enrico

-- 
GPG key: 4096R/634F4BD1E7AD5568 2009-05-08 Enrico Zini 


signature.asc
Description: PGP signature

Bug#925816: marked as done (qxw: ftbfs with GCC-9)

[Steve McIntyre]

Control: reopen 925816
Control: close 925826 15+1533136590.3beb971-8
thanks

Gah, typo in the changelog so I closed the wrong bug# :-(

On Tue, Mar 24, 2020 at 06:21:03PM +, Debian Bug Tracking System wrote:
>Your message dated Tue, 24 Mar 2020 18:19:58 +
>with message-id 
>and subject line Bug#925816: fixed in shim 15+1533136590.3beb971-8
>has caused the Debian Bug report #925816,
>regarding qxw: ftbfs with GCC-9
>to be marked as done.
>
>This means that you claim that the problem has been dealt with.
>If this is not the case it is now your responsibility to reopen the
>Bug report if necessary, and/or fix the problem forthwith.
>
>(NB: If you are a system administrator and have no idea what this
>message is talking about, this may indicate a serious mail system
>misconfiguration somewhere. Please contact ow...@bugs.debian.org
>immediately.)
>
>
>-- 
>925816: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=925816
>Debian Bug Tracking System
>Contact ow...@bugs.debian.org with problems

>From: Matthias Klose 
>To: mainto...@bugs.debian.org
>Date: Wed, 27 Mar 2019 19:47:50 +
>Subject: qxw: ftbfs with GCC-9
>
>Package: src:qxw
>Version: 20140331-1
>Severity: normal
>Tags: sid bullseye
>User: debian-...@lists.debian.org
>Usertags: ftbfs-gcc-9
>
>Please keep this issue open in the bug tracker for the package it
>was filed for.  If a fix in another package is required, please
>file a bug for the other package (or clone), and add a block in this
>package. Please keep the issue open until the package can be built in
>a follow-up test rebuild.
>
>The package fails to build in a test rebuild on at least amd64 with
>gcc-9/g++-9, but succeeds to build with gcc-8/g++-8. The
>severity of this report will be raised before the bullseye release,
>so nothing has to be done for the buster release.
>
>The full build log can be found at:
>http://people.debian.org/~doko/logs/gcc9-20190321/qxw_20140331-1_unstable_gcc9.log
>The last lines of the build log are at the end of this report.
>
>To build with GCC 9, either set CC=gcc-9 CXX=g++-9 explicitly,
>or install the gcc, g++, gfortran, ... packages from experimental.
>
>  apt-get -t=experimental install g++ 
>
>Common build failures are new warnings resulting in build failures with
>-Werror turned on, or new/dropped symbols in Debian symbols files.
>For other C/C++ related build failures see the porting guide at
>http://gcc.gnu.org/gcc-9/porting_to.html
>
>GCC 9 also passes the linker option --as-needed by default; typical
>build issues are passing libraries before object files to the linker,
>or underlinking of convenience libraries built from the same source.
>
>[...]
>  |   ^~~~
>gui.c:2072:94: note: ...this statement, but the latter is misleadingly 
>indented as if it were guarded by the 'else'
> 2072 |   else strcpy (s,"  Mean length: -");  
>   gtk_label_set_text(GTK_LABEL(st_r[1]),s);
>  |
>   ^~
>gui.c:2074:3: warning: this 'else' clause does not guard... 
>[-Wmisleading-indentation]
> 2074 |   else  strcpy (s,"  Checked light letters: -");   
>gtk_label_set_text(GTK_LABEL(st_r[2]),s);
>  |   ^~~~
>gui.c:2074:95: note: ...this statement, but the latter is misleadingly 
>indented as if it were guarded by the 'else'
> 2074 |   else  strcpy (s,"  Checked light letters: -");   
>gtk_label_set_text(GTK_LABEL(st_r[2]),s);
>  |
>^~
>gui.c:2076:3: warning: this 'else' clause does not guard... 
>[-Wmisleading-indentation]
> 2076 |   else  strcpy (s,"  Checked grid cells: -");  
>gtk_label_set_text(GTK_LABEL(st_r[3]),s);
>  |   ^~~~
>gui.c:2076:95: note: ...this statement, but the latter is misleadingly 
>indented as if it were guarded by the 'else'
> 2076 |   else  strcpy (s,"  Checked grid cells: -");  
>gtk_label_set_text(GTK_LABEL(st_r[3]),s);
>  |
>^~
>gui.c: In function 'updatefeas':
>gui.c:2241:45: warning: '%s' directive writing up to 999 bytes into a region 
>of size between 978 and 979 [-Wformat-overflow=]
> 2241 | else sprintf(p1," Feasible character%s: 
> %s",(strlen(p0)==1)?"":"s",p0);
>  | ^~ 
> ~~
>gui.c:2241:10: note: 'sprintf' output between 22 and 1022 bytes into a 
>destination of size 1000
> 2241 | else sprintf(p1," Feasible character%s: 
> %s",(strlen(p0)==1)?"":"s",p0);
>  |  
> ^
>gcc -Wall -fstack-protector 

Bug#954865: ruby: Ruby update to 2.7 broke all native extensions, including ones needed for gem pristine

[Chris Hofstaedtler]

Hi,

thanks for your report. However ...

* Calum McConnell  [200324 16:30]:
[..]
> /usr/lib/ruby/2.7.0/rubygems/core_ext/kernel_require.rb:92:in
> `require': libruby-2.5.so.2.5: cannot open shared object file: No
> such file or directory -
> /home/calum/gems/gems/psych-3.1.0/lib/psych.so (LoadError)
  

[..]
> Further, I shouldnt need to reinstall ruby: rebuilding native extensions 
> should
> be done by the upgrade script.

Rebuilding gems/extensions that are located in your home directory
or other random places is not something that is allowed to be be done
by the upgrade process. It also wouldn't work in multi-machine setups
and many other cases.

Please rebuild the gems in your home directory yourself, possibly by
deleting them first. I would also recommend using versioned
directories in your gem path to avoid breaking gem itself on such
occasions.

Chris

Bug#954374: marked as pending in glibc

[Johannes Schauer]

Okay, wow, this is a 100 times better solution than the one I proposed. :D

Thank you!!

Quoting Aurelien Jarno (2020-03-24 19:02:59)
> Bug #954374 in glibc reported by you has been fixed in the
> Git repository and is awaiting an upload. You can see the commit
> message below and you can check the diff of the fix at:
> 
> https://salsa.debian.org/glibc-team/glibc/-/commit/7d682fdc92f2a3bf2a16c534204c89a69ca08040
> 
> 
> debian/debhelper.in/libc.preinst, debian/rules.d/debhelper.mk: determine 
> ld.so ELF magic at build time instead of at run time to avoid using "readlink 
> -m".  Closes: #954374.
> 
> 
> (this message was generated automatically)

signature.asc
Description: signature

Bug#953883: Please backport version 20 for buster

[Chris Lamb]

Hey Enrico,

> > I'm inferring from the way you reference it that you have difficulty
> > getting these incantations right, but I must also admit that I rarely
> > ever get these right myself without some assistance. Indeed, I see a
> > "Breaks" that was likely one misguided attempt of mine to address this.
> > 
> > Perhaps we can get some outside assistance on this so we would feel
> > a bit more confident?
> 
> Indeed, this is out of my routine packaging work. I went digging and I
> *think* the trick is in policy 7.6.2; at least, I'd give this one a try:

[..]

Cool, I believe I have addressed that in:

 gunicorn (20.0.4-4) unstable; urgency=medium
 
   * Mark that the [Python 3.x] gunicorn binary package replaces the legacy
 gunicorn3 one removed in 19.9.0-2. Thanks, Enrico. (Re: #953883)
   * Add Bug-Database and Bug-Submit to debian/upstream/metadata.

I will backport this to buster once this migrates to bullseye.


Best wishes,

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

Bug#945405: ERROR: Signature extraction failed + WARNING: Unable to extract video title

[Daniel Baumann]

close 945405 2020.01.24-0.1
thanks

Hi,

downloading the videos you mentioned works with above version, hence
closing the bug report.

note: due to changes in youtube.com, youtube-dl needs to be updated
frequently in order to continue to work.

Regards,
Daniel

Bug#954875: new upstream (2020.03.24)

[Daniel Baumann]

Package: youtube-dl
Severity: wishlist

Hi Rogerio,

it woudl be nice if you could upgrade to the current upstream version
(2020.03.24).

I've sponsored theh last NMU-upload and am using youtube-dl frequently.
Just in case you'd like some help with the package..

Regards,
Daniel

Bug#954872: buildd.debian.org: Legends for the graphs on https://buildd.debian.org/stats/ half-gone

[Aurelien Jarno]

On 2020-03-24 18:47, nabijaczleweli wrote:
> Package: buildd.debian.org
> Severity: normal
> 
> Hello,
> 
> The legends for the graphs on https://buildd.debian.org/stats/ seem to
> be partway gone, mostly affecting the colour and start of the
> architecture name.
> 
> See the attached graph.png, taken from the site as I write this.
> 

This is a know issue, due to a change in the R packages in Debian
Buster. If someone has good knowledge of R, patches are welcome.

Aurelien

-- 
Aurelien Jarno  GPG: 4096R/1DDD8C9B
aurel...@aurel32.net http://www.aurel32.net


signature.asc
Description: PGP signature

Bug#954873: nm.debian.org: missing link from mailbox to process

[Mattia Rizzolo]

On Tue, Mar 24, 2020 at 06:55:22PM +0100, Mattia Rizzolo wrote:
> from the mailbox view I seem unable to find a link that gets me back to
> the process page.
> Could we have one?

Actually, that seems to be true for any requirement page as well, like
keycheck or am_ok.

-- 
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#954874: ruby-rspec-puppet: depends on obsolete transitional package.

[peter green]

Package: ruby-rspec-puppet
Version: 2.7.8-1
Severity: serious

ruby-rspec-puppet depends on "puppet-common", this has been a transitional 
package since stretch and has now been dropped by the puppet source package.

Please change your dependency to puppet.

Bug#954873: nm.debian.org: missing link from mailbox to process

[Mattia Rizzolo]

Package: nm.debian.org

from the mailbox view I seem unable to find a link that gets me back to
the process page.
Could we have one?

-- 
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#954010: improvements to mbox viewer

[Mattia Rizzolo]

Control: close -1

On Sat, Mar 21, 2020 at 03:28:38PM +0100, Enrico Zini wrote:
> > 1. I seem unable to scroll the list of mails in the mbox viewer unless I
> > also open a mail.
> > 
> > 2. when you open a mail, scroll it, then move to a different email
> > (either by clicking or arrow keys), the mail body doesn't scroll back to
> > the start of the new mail, keeping the position of the old mail.
> 
> Thanks for the report!
> 
> 2 should be done and deployed.

yup, thank you!

> I'm not sure I understood 1 enough to reproduce it. I have however
> cleaned up the mail display significantly, could you check if you can
> still reproduce it, then either give me instructions, or close the
> bug?

It feels odd to scroll with the "mouse wheel" and have also the focused
mail change, but at least the mail list now also scroll, so this bug is
fixed for me.

thanks!

-- 
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#954872: buildd.debian.org: Legends for the graphs on https://buildd.debian.org/stats/ half-gone

[nabijaczleweli]

Package: buildd.debian.org
Severity: normal

Hello,

The legends for the graphs on https://buildd.debian.org/stats/ seem to
be partway gone, mostly affecting the colour and start of the
architecture name.

See the attached graph.png, taken from the site as I write this.

Best regards,
nabijaczleweli


signature.asc
Description: PGP signature

Bug#954871: genext2fs: please package the new upstream release

[Johannes 'josch' Schauer]

Package: genext2fs
Version: 1.4.1-4
Severity: wishlist

Hi,

upstream released a new version 1.4.2 it would be nice if it could be
packaged.

Thanks!

cheers, josch

Bug#954833: libcss-minifier-perl: typo in POD

[gregor herrmann]

On Tue, 24 Mar 2020 09:38:00 +0100, Ricardo Mones wrote:

> Just fixing a typo found while reading the package documentation, patch
> attached.

Thanks, applied in git and forwarded upstream.
 
Cheers,
gregor

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


signature.asc
Description: Digital Signature

Bug#953098: xscreensaver: Crashes with XIO: fatal IO error

[Jamie Zawinski]

For best logging: xscreensaver -verbose -log log.txt

Bug#954870: ITP: r-cran-fingerprint -- GNU R functions to operate on binary fingerprint data

[Andreas Tille]

Package: wnpp
Severity: wishlist

Subject: ITP: r-cran-fingerprint -- GNU R functions to operate on binary 
fingerprint data
Package: wnpp
Owner: Andreas Tille 
Severity: wishlist

* Package name: r-cran-fingerprint
  Version : 3.5.7
  Upstream Author : Rajarshi Guha 
* URL : https://cran.r-project.org/package=fingerprint
* License : GPL-2
  Programming Lang: GNU R
  Description : GNU R functions to operate on binary fingerprint data
 Functions to manipulate binary fingerprints of arbitrary length. A
 fingerprint is represented by an object of S4 class 'fingerprint' which
 is internally represented a vector of integers, such that each element
 represents the position in the fingerprint that is set to 1. The bitwise
 logical functions in R are overridden so that they can be used directly
 with 'fingerprint' objects. A number of distance metrics are also
 available (many contributed by Michael Fadock). Fingerprints can be
 converted to Euclidean vectors (i.e., points on the unit hypersphere)
 and can also be folded using OR. Arbitrary fingerprint formats can be
 handled via line handlers. Currently handlers are provided for CDK, MOE
 and BCI fingerprint data.

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

Bug#919181: status of ITP: laminar

[meskio]

Quoting Dmitry Bogatov (2020-03-12 01:26:10)
> 
> [2020-02-27 11:40] meskio 
> > Dmitry, I see the issue on vue-router.js has being solved since some 
> > months. But 
> > no movement has being happening in this ITP. Are you still interested on 
> > packaging it? Do you need some help? Or someone to take it over?
> >
> > I have updated your package to the latest laminar release (0.8):
> > https://salsa.debian.org/meskio-guest/laminar/
> 
> If you (or somebody else) wish, go ahead, take over it. I no longer work
> on Debian.

Thank you for all the work you have already done. I'll try to move it forward, 
let's see if we get the libjs-vue-router fix uploaded.

-- 
meskio | http://meskio.net/
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
 My contact info: http://meskio.net/crypto.txt
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Nos vamos a Croatan.


signature.asc
Description: signature

Bug#927254: closed by Xavier Guimard (Bug#927254: fixed in vue-router.js 3.0.7+ds-1)

[meskio]

Hello Paolo,

Quoting Paolo Greppi (2019-10-31 18:39:16)
> Hi Dmitry, I have fixed the dangling symlink in libjs-vue-route.
> 
> It now builds locally and on Salsa CI (I enabled it for master branch as 
> well):
> https://salsa.debian.org/js-team/vue-router.js/-/jobs/393462
> 
> I then rebuilt laminar from the current version at 
> https://salsa.debian.org/debian/laminar against this unreleased 
> libjs-vue-route 3.0.7+ds-3 version.
> After issuing:
>   systemctl start laminar.service
> and checking that:
>   systemctl status laminar.service
> returns success,
> the laminar service dashboard can be reached from localhost:8080 and causes 
> no JavaScript error.

Is there anything still blocking this fix from being uploaded to unstable? Can 
I 
do something to help here?

Thank you for fixing the problem.


-- 
meskio | http://meskio.net/
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
 My contact info: http://meskio.net/crypto.txt
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Nos vamos a Croatan.


signature.asc
Description: signature

Bug#954860: lintian: absolute-symbolic-link-target-in-source duplicates source-contains-unsafe-symlink

[Felix Lechner]

Hi Raphaël,

On Tue, Mar 24, 2020 at 7:48 AM Raphaël Hertzog
 wrote:
>
> I don't see the point of "absolute-symbolic-link-target-in-source" since
> "source-contains-unsafe-symlink" is already triggered on such files.

Thanks for pointing out the overlap. Unfortunately, the tags are not equivalent.

You can see it in the test for
absolute-symbolic-link-target-in-source. Below are the full results,
including the check 'cruft'. (The 'tags' file is not a good indicator;
Lintian's test suite runs only the check being tested.) As you can
see, the tag source-contains-unsafe-symlink did not appear.

> Please remove that newly added tag.

The new tag was a reaction to a previously unidentified condition
after this important adjustment:


https://salsa.debian.org/lintian/lintian/-/commit/8e5a95d25669052386f1c7206f4eed4e3c1f35d3

Straight removal is not an option but will think of a way to remove the overlap.

Thank you for bringing this matter to our attention.

Kind regards
Felix Lechner

* * *

> W: absolute-target-in-source source: absolute-symbolic-link-target-in-source 
> debian/tests/asym -> /dev/null
> W: absolute-target-in-source source: absolute-symbolic-link-target-in-source 
> debian/tests/asym2 -> /dev/null
> W: absolute-target-in-source source: 
> debian-tests-control-autodep8-is-obsolete debian/tests/control.autodep8
> W: absolute-target-in-source source: 
> debian-tests-control-uses-national-encoding at line 2
> W: absolute-target-in-source source: exclusive-runtime-tests-field tests, 
> test-command paragraph starting at line 20
> W: absolute-target-in-source source: illegal-runtime-test-name under_score 
> paragraph starting at line 5
> W: absolute-target-in-source source: missing-runtime-test-file 
> debian/tests/asym paragraph starting at line 35
> W: absolute-target-in-source source: missing-runtime-test-file 
> debian/tests/asym1 paragraph starting at line 35
> W: absolute-target-in-source source: missing-runtime-test-file 
> debian/tests/broken paragraph starting at line 35
> W: absolute-target-in-source source: missing-runtime-test-file ... use 
> --no-tag-display-limit to see all (or pipe to a file/program)
> W: absolute-target-in-source source: obsolete-runtime-tests-restriction 
> needs-recommends paragraph starting at line 28
> W: absolute-target-in-source source: 
> testsuite-dependency-has-unparsable-elements "missing a comma" (in paragraph 
> starting at line 20)
> I: absolute-target-in-source source: 
> debian-tests-control-and-control-autodep8 debian/tests/control 
> debian/tests/control.autodep8
> I: absolute-target-in-source source: runtime-test-file-is-not-a-regular-file 
> debian/tests/fifo
> I: absolute-target-in-source source: runtime-test-file-is-not-a-regular-file 
> debian/tests/lfifo
> P: absolute-target-in-source source: unknown-runtime-tests-feature 
> unknownfeature paragraph starting at line 24
> P: absolute-target-in-source source: unknown-runtime-tests-field comment 
> paragraph starting at line 1
> P: absolute-target-in-source source: unknown-runtime-tests-restriction 
> unknownrestriction paragraph starting at line 24

Bug#954869: ITP: r-cran-rsvg -- GNU R render SVG images into PDF, PNG, PostScript, or bitmap arrays

[Andreas Tille]

Package: wnpp
Severity: wishlist

Subject: ITP: r-cran-rsvg -- GNU R render SVG images into PDF, PNG, PostScript, 
or bitmap arrays
Package: wnpp
Owner: Andreas Tille 
Severity: wishlist

* Package name: r-cran-rsvg
  Version : 1.3
  Upstream Author : Jeroen Ooms
* URL : https://cran.r-project.org/package=rsvg
* License : MIT
  Programming Lang: GNU R
  Description : GNU R render SVG images into PDF, PNG, PostScript, or 
bitmap arrays
 Renders vector-based svg images into high-quality custom-size bitmap
 arrays using 'librsvg2'. The resulting bitmap can be written to e.g. png, jpeg
 or webp format. In addition, the package can convert images directly to various
 formats such as pdf or postscript.

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

Bug#954743: lintian: orig-tarball-missing-upstream-signature does not say how to add it to uploaded tarballs

[Mattia Rizzolo]

On Sun, Mar 22, 2020 at 09:42:32PM +, Chris Lamb wrote:
> > Should use the '-sa' option to force both the *.orig.tar.gz and *.asc
> > into .*.changes? I think that such an upload will be rejected by DAK, as
> > the *.tar.gz is already in the archive. But to be honest this is based
> > on my past experiences, but maybe something has changed since then. Is
> > re-uploading upstream tarballs permitted now?
> 
> AIUI -sa by itself will not be rejected but I am unclear whether the
> inclusion of the signature will cause a rejection. You could just try
> it? :)

I can tell you both that such an upload won't be rejected by dak as long
as the .orig.tar.gz is the very same as the one that was previously
uploaded.
Honestly, I'm somewhat partial on putting such archive-dependant
information in lintian is alright (dak is only one of the many debian
archive software out there…).


Also, to put the .tar.gz.asc in the git repository you'll need to ask
pristine-tar to do a new "commit" (see man pristine-tar for "commit");
that said if I were you I'd just manually checkout to the pristine-tar
branch and git commit the .asc file…  (you'll see if that worked if
`pristine-tar list` list the file once you go back to the master
branch).

-- 
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#755385: CHARITY DONOR

[WANG JIANLIN]

I intend to send you some of my assets as part of a voluntary 
financial donation. 
Wang Jianlin 
Wanda Group 

Bug#954763: lintian: Lintian should warn about use of py3versions -i in autopkgtests

[Mattia Rizzolo]

Control: clone -1 -2
Control: retitle -2 lintian: warn about py3versions -s but no python3-all 
test-dependency

On Sun, Mar 22, 2020 at 11:57:08PM -0400, Scott Kitterman wrote:
> Preferably these packages should run their tests with all supported
> python3 versions.  This is ensured by including python3-all in the test
> dependencies and using py3versions -s (instead of -i).  Tests should run
> deterministically, not just based on whatever happens to be installed.

more than once I tripped on this, using `py3versions -s` but having only
python3 (or, not even that and rely on it being pulled by the testing
package), without python3-all.  That causes only the default version to
be installed, and then the test would fail when trying to run the other
non-default supported version.

Please check for this as well ♥

-- 
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