Bug#963110: urwid/numedit.py:245: SyntaxWarning: "is not" with a literal. Did you mean "!="?

2020-06-18 Thread Vincent Lefevre
Package: python3-urwid
Version: 2.1.0-2
Severity: normal

When upgrading:

Setting up python3-urwid (2.1.0-2) ...
/usr/lib/python3/dist-packages/urwid/numedit.py:245: SyntaxWarning: "is not" 
with a literal. Did you mean "!="?
  if default is not None and default is not "":

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

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

Versions of packages python3-urwid depends on:
ii  libc62.30-8
ii  python3  3.8.2-3

python3-urwid recommends no packages.

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

-- no debconf information

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



Bug#963108: perl: Please include minor patch to fix FTBFS on m68k

2020-06-18 Thread John Paul Adrian Glaubitz
Hi!

On 6/19/20 8:22 AM, John Paul Adrian Glaubitz wrote:
> The attached patch fixes the problem by adding an additional 16 bits padding
> before the opslot member which causes the alignment of opslot to be 32 bits.

Attaching a patch with a better commit message for explanation.

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
>From 8cd015a5cc230105bdcb8c33db80ef9f06b1c670 Mon Sep 17 00:00:00 2001
From: John Paul Adrian Glaubitz 
Date: Fri, 19 Jun 2020 08:33:33 +0200
Subject: [PATCH] op.h: Add additional padding to struct opslab to ensure
 proper alignment

Perl crashes with a segmentation fault on m68k due to an alignment issue.
On m68k, the natural alignment is 16 bits which causes the opslot
member of "struct opslab" to be aligned at a 16-bit offset.

On other 32-bit and 64-bit architectures, the natural alignment is at
least 32 bits, so the offset is always guaranteed to be 32-bit aligned.
Fix this by adding an additional 16 bits padding before the opslot member
which causes the offset of oplab_slots to be 32-bit aligned.

On architectures which have a natural alignment of at least 32 bits,
the padding does not affect the alignment, offsets or struct size.
---
 op.h | 1 +
 1 file changed, 1 insertion(+)

diff --git a/op.h b/op.h
index fc21f03cda..fb9f538e23 100644
--- a/op.h
+++ b/op.h
@@ -714,6 +714,7 @@ struct opslab {
 # ifdef PERL_DEBUG_READONLY_OPS
 bool	opslab_readonly;
 # endif
+U16 opslab_padding;		/* padding to ensure proper alignment */
 OPSLOT	opslab_slots;		/* slots begin here */
 };
 
-- 
2.27.0



Bug#963102: Debian is Buster 10.4 amd64

2020-06-18 Thread tonywyattparker
Debian is Buster 10.4 amd64

Bug#963109: libreoffice: Please drop clang from build-dependencies for alpha and ia64

2020-06-18 Thread John Paul Adrian Glaubitz
Source: libreoffice
Version: 1:7.0.0~beta2-1
Severity: normal
User: debian-al...@lists.debian.org
Usertags: alpha ia64

Hello!

I just noticed that src:libreoffice 7.x has added a build dependency on clang
for alpha and ia64. However, clang is unfortunately no longer available on
these targets which causes libreoffice to become BD-Uninstallable.

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#963104: The lxqt panel appears only after a delay of about ten seconds at cold boot

2020-06-18 Thread tonywyattparker
Package: lxqt-panel

Version: 0.14.1-1

After Debian Buster 10.3 amd64 was installed (a few weeks ago) with lxqt 
desktop environment from the small cd image, the lxqt panel appears only after 
a delay of about ten seconds at cold boot (i.e. ten seconds after the Desktop 
appears together with the icons on it). I noticed that there hasn't been such a 
software defect on other systems with installed linux with lxqt (Arch and 
Ubuntu) - may be there was something wrong with the small cd image (as i had 
problems with linux installations from small cd's before).

The system is:

os distribution: Debian Buster 10.4 amd64 with lxqt/sddm/openbox (with latest 
updates) - LXQt 0.14.1, sddm 0.18.0-1 and Qt 5.11.3

processor: amd athlon

chipset: nvidia nForce 430

ram: 4GB ddr2

Bug#963108: perl: Please include minor patch to fix FTBFS on m68k

2020-06-18 Thread John Paul Adrian Glaubitz
Source: perl
Version: 5.32.0~rc1-1
Severity: normal
Tags: patch
User: debian-...@lists.debian.org
Usertags: m68k

Hi!

perl currently fails to build from source on m68k in experimental due to
an alignment issue. On m68k, the natural alignment is 16 bits which causes
the opslot member of "struct opslab" to be aligned at a 16-bit offset.

On other 32-bit and 64-bit architectures, the alignment is at least 32 bits,
so the offset is always guaranteed to be 32-bit aligned.

The attached patch fixes the problem by adding an additional 16 bits padding
before the opslot member which causes the alignment of opslot to be 32 bits.

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
>From 3585dd865baaa3c631964fbba758491b26ef954a Mon Sep 17 00:00:00 2001
From: John Paul Adrian Glaubitz 
Date: Fri, 19 Jun 2020 07:42:08 +0200
Subject: [PATCH] op.h: Add additional padding to struct opslab to ensure
 proper alignment

On architectures where the native alignment is less than 4 bytes such as
Motorola 68000 (m68k), we need an additional padding of 2 bytes such that
the offset of the slots inside the slabs is correct.
---
 op.h | 1 +
 1 file changed, 1 insertion(+)

diff --git a/op.h b/op.h
index fc21f03cda..fb9f538e23 100644
--- a/op.h
+++ b/op.h
@@ -714,6 +714,7 @@ struct opslab {
 # ifdef PERL_DEBUG_READONLY_OPS
 bool   opslab_readonly;
 # endif
+U16 opslab_padding;/* padding to ensure proper 
alignment */
 OPSLOT opslab_slots;   /* slots begin here */
 };
 
-- 
2.27.0



Bug#963039: [Pkg-javascript-devel] Bug#963039: node-iconv: versions of nodejs dependencies not properly documented

2020-06-18 Thread Xavier
Le 18/06/2020 à 10:06, Paul Gevers a écrit :
> Source: node-iconv
> Version: 1.19.0-2
> Severity: serious
> Tags: sid bullseye
> User: debian...@lists.debian.org
> Usertags: needs-update
> Control: affects -1 src:nodejs src:node-body-parser
> Control: affects -1 src:node-client-sessions src:node-express
> 
> [X-Debbugs-CC: debian...@lists.debian.org,
> node-body-par...@packages.debian.org,
> node-client-sessi...@packages.debian.org, node-expr...@packages.debian.org]
> 
> Dear maintainer(s),
> 
> With a recent upload of nodejs the autopkgtest of node-body-parser fails
> in testing when that autopkgtest is run with the binary packages of
> nodejs from unstable. It passes when run with only packages from
> testing. In tabular form:
> 
>passfail
> nodejs from testing12.18.0~dfsg-3
> node-body-parser   from testing1.19.0-2
> all others from testingfrom testing

Hi Paul,

could we solve this by adding a:

  Breaks: nodejs (<< ${binary::Version}~)

in libnode72 package ? If it works, this will solve the problem for all
similar packages.

Cheers,
Xavier



Bug#888705: abseil-cpp packaging

2020-06-18 Thread GCS
On Sat, May 23, 2020 at 2:39 PM Benjamin Barenblat  wrote:
> This is now in the NEW queue.
 Not anymore and not in the archives. What happened? Can I help?

Cheers,
Laszlo/GCS



Bug#963102: Some user-created .desktop launchers can't be started from lxqt menu and lxqt panel

2020-06-18 Thread tonywyattparker
Package: lxqt-panel

Version: 0.14.1-1

Some user-created .desktop launchers can't be started from lxqt menu and lxqt 
panel - for example, a launcher with a bash command - though they can be 
launched from pcmanfm-qt file manager.

The system is:

os distribution: Debian Buster 10.4 with lxqt/sddm/openbox (with latest 
updates) - LXQt 0.14.1, sddm 0.18.0-1 and Qt 5.11.3

processor: amd athlon

chipset: nvidia nForce 430

ram: 4GB ddr2

Bug#963107: "Encrypted connection unavailable" when using pre-authenticated connection

2020-06-18 Thread Josh Triplett
Package: mutt
Version: 1.14.3-1
Severity: important

"important" because it makes a previously working configuration
unusable.

The fix for CVE-2020-14093 makes it so that when using a
preauthenticated connection (using `set tunnel` to SSH to the IMAP
server), mutt just prints "Encrypted connection unavailable" and refuses
the connection. An strace shows that mutt successfully runs SSH and gets
the preauthenticated IMAP connection.

I do not have any ssl-related options set. Best guess: the default
ssl_starttls=yes makes mutt think it should starttls over preauth, which
it now avoids due to the CVE.

- Josh Triplett

-- Package-specific info:
Mutt 1.14.3 (2020-06-14)
Copyright (C) 1996-2020 Michael R. Elkins and others.
Mutt comes with ABSOLUTELY NO WARRANTY; for details type `mutt -vv'.
Mutt is free software, and you are welcome to redistribute it
under certain conditions; type `mutt -vv' for details.

System: Linux 5.6.0-1-amd64 (x86_64)
ncurses: ncurses 6.2.20200212 (compiled with 6.2)
libidn: 1.33 (compiled with 1.33)
hcache backend: tokyocabinet 1.4.48

Compiler:
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/9/lto-wrapper
OFFLOAD_TARGET_NAMES=nvptx-none:hsa
OFFLOAD_TARGET_DEFAULT=1
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Debian 9.3.0-13' 
--with-bugurl=file:///usr/share/doc/gcc-9/README.Bugs 
--enable-languages=c,ada,c++,go,brig,d,fortran,objc,obj-c++,gm2 --prefix=/usr 
--with-gcc-major-version-only --program-suffix=-9 
--program-prefix=x86_64-linux-gnu- --enable-shared --enable-linker-build-id 
--libexecdir=/usr/lib --without-included-gettext --enable-threads=posix 
--libdir=/usr/lib --enable-nls --enable-bootstrap --enable-clocale=gnu 
--enable-libstdcxx-debug --enable-libstdcxx-time=yes 
--with-default-libstdcxx-abi=new --enable-gnu-unique-object 
--disable-vtable-verify --enable-plugin --enable-default-pie --with-system-zlib 
--with-target-system-zlib=auto --enable-objc-gc=auto --enable-multiarch 
--disable-werror --with-arch-32=i686 --with-abi=m64 
--with-multilib-list=m32,m64,mx32 --enable-multilib --with-tune=generic 
--enable-offload-targets=nvptx-none=/build/gcc-9-F9gimE/gcc-9-9.3.0/debian/tmp-nvptx/usr,hsa
 --without-cuda-driver --enable-checking=release --build=x86_64-linux-gnu 
--host=x86_64-linux-gnu --target=x86_64-linux-gnu 
--with-build-config=bootstrap-lto-lean --enable-link-mutex
Thread model: posix
gcc version 9.3.0 (Debian 9.3.0-13) 

Configure options: '--build=x86_64-linux-gnu' '--prefix=/usr' 
'--includedir=\${prefix}/include' '--mandir=\${prefix}/share/man' 
'--infodir=\${prefix}/share/info' '--sysconfdir=/etc' '--localstatedir=/var' 
'--disable-option-checking' '--disable-silent-rules' 
'--libdir=\${prefix}/lib/x86_64-linux-gnu' 
'--libexecdir=\${prefix}/lib/x86_64-linux-gnu' '--disable-maintainer-mode' 
'--disable-dependency-tracking' '--with-mailpath=/var/mail' 
'--enable-compressed' '--enable-debug' '--enable-fcntl' '--enable-hcache' 
'--enable-gpgme' '--enable-imap' '--enable-smtp' '--enable-pop' 
'--enable-sidebar' '--enable-nntp' '--enable-dotlock' '--disable-fmemopen' 
'--with-curses' '--with-gnutls' '--with-gss' '--with-idn' '--with-mixmaster' 
'--with-sasl' '--without-gdbm' '--without-bdb' '--without-qdbm' 
'--with-tokyocabinet' 'build_alias=x86_64-linux-gnu' 'CFLAGS=-g -O2 
-fdebug-prefix-map=/build/mutt-30SNLx/mutt-1.14.3=. -fstack-protector-strong 
-Wformat -Werror=format-security' 'LDFLAGS=-Wl,-z,relro -Wl,-z,now' 
'CPPFLAGS=-Wdate-time -D_FORTIFY_SOURCE=2'

Compilation CFLAGS: -Wall -pedantic -Wno-long-long -g -O2 
-fdebug-prefix-map=/build/mutt-30SNLx/mutt-1.14.3=. -fstack-protector-strong 
-Wformat -Werror=format-security

Compile options:
-DOMAIN
+DEBUG
-HOMESPOOL  +USE_SETGID  +USE_DOTLOCK  +DL_STANDALONE  +USE_FCNTL  -USE_FLOCK   
+USE_POP  +USE_IMAP  +USE_SMTP  
-USE_SSL_OPENSSL  +USE_SSL_GNUTLS  +USE_SASL  +USE_GSS  +HAVE_GETADDRINFO  
+HAVE_REGCOMP  -USE_GNU_REGEX  
+HAVE_COLOR  +HAVE_START_COLOR  +HAVE_TYPEAHEAD  +HAVE_BKGDSET  
+HAVE_CURS_SET  +HAVE_META  +HAVE_RESIZETERM  +HAVE_FUTIMENS  
+CRYPT_BACKEND_CLASSIC_PGP  +CRYPT_BACKEND_CLASSIC_SMIME  +CRYPT_BACKEND_GPGME  
-EXACT_ADDRESS  -SUN_ATTACHMENT  
+ENABLE_NLS  -LOCALES_HACK  +HAVE_WC_FUNCS  +HAVE_LANGINFO_CODESET  
+HAVE_LANGINFO_YESEXPR  
+HAVE_ICONV  -ICONV_NONTRANS  +HAVE_LIBIDN  -HAVE_LIBIDN2  +HAVE_GETSID  
+USE_HCACHE  
+USE_SIDEBAR  +USE_COMPRESSED  +USE_INOTIFY  
-ISPELL
SENDMAIL="/usr/sbin/sendmail"
MAILPATH="/var/mail"
PKGDATADIR="/usr/share/mutt"
SYSCONFDIR="/etc"
EXECSHELL="/bin/sh"
MIXMASTER="mixmaster"

To contact the developers, please mail to .
To report a bug, please contact the Mutt maintainers via gitlab:
https://gitlab.com/muttmua/mutt/issues


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

Kernel: Linux 5.6.0-1-amd64 (SMP w/4

Bug#961789: [Pkg-net-snmp-devel] Bug#961789: snmpd: 100% CPU utilisation of snmpd after subagents are disconnecting

2020-06-18 Thread Craig Small
Hi Danny,
  It will (actually has) ended up in Bullseye but net-snmp v5.8 won't end
up in Stretch or Buster.

 - Craig


On Tue, 16 Jun 2020 at 01:31, Danny Smit  wrote:

> Thanks for your reply. Is version 5.8 expected to end up in either
> Debian Stretch or Buster?
>
> On Thu, Jun 11, 2020 at 12:04 AM Craig Small  wrote:
> >
> > Package: snmpd
> > Version: 5.8+dfsg-1
> >
> > On Fri, 29 May 2020 at 19:57, Danny Smit  wrote:
> >>
> >>  The following upstream bugreport seems to describe the same
> behaviour:
> >>  https://sourceforge.net/p/net-snmp/bugs/2411/
> >
> > The patch was applied to upstream version 5.8 which means we have it for
> 5.8+dfsg-1
> >
> >  - Craig
> >
>


Bug#949440: Merged 949432 and 949440: does the same workaround solve?

2020-06-18 Thread Paul Szabo
I wonder why 949432 and 949440 were merged? I do not see confirmation
whether 949432 is solved by the same workaround of 949440.

Thanks, Paul
-- 
Paul Szabo   p...@maths.usyd.edu.au   www.maths.usyd.edu.au/u/psz
School of Mathematics and Statistics   University of SydneyAustralia

I support NTEU members taking a stand for workplace rights in the face of
poorly-run change management. Visit www.nteu.org.au/sydney to learn more.

Bug#963000: systemd-analyze unit-paths erroneously reports /usr/lib/systemd/system/

2020-06-18 Thread Thijs Kinkhorst
Hi Michael,

On Wed, June 17, 2020 22:48, Michael Biebl wrote:
> Systemd itself does indeed search /usr/lib/systemd/system . Our
> internal/Debian tooling though
> (dh_installsystemd/invoke-rc.d/service/...) currently only handles files
> from /lib/systemd (mostly for historical reasons where a /usr on a
> separate partition mounted during late boot was still supported).
>
> So, theoretically, you can install unit files in /usr/lib/systemd/system
> and systemd will process them. What you don't get is full Debian
> integration.

Well, I'm quite sure in the sense that I had a unit file in
/usr/lib/systemd/system but indeed commands like "service" did not work. I
find it unexpected behaviour that systemd reports that it searches the
directory but at the same time something like "service x start" does not
work.

Also I found
https://lintian.debian.org/tags/systemd-service-file-outside-lib.html
which explicitly says: "Systemd in Debian searches for unit files in
/lib/systemd/system/ and /etc/systemd/system. Notably, it does not look in
/usr/lib/systemd/system/ for service files."

So I think the most clear way forward is either that it does not report
this directory as being searched, or all the tools do in fact work with
this directory. A mid way where some things work and others do not, is
confusing to me at least.

Cheers,
Thijs



Bug#963100: screen fades to black with colorful artifacts at video playback

2020-06-18 Thread tonywyattparker
Package: xserver-xorg-video-nouveau

Version: 1:1.0.16-1

The system is with built-in Nvidia nForce 430 / GeForce 6150SE (chipset/video 
adapter).

We have debian buster latest updates (10.4) with lxqt/sddm/openbox and it works 
very well and fast though the system is old (2006 year - amd athlon, ddr2 4GB).

The problem is that the system crashes when playing full hd videos with smp or 
mpv player - crash takes place usually when the video window is resized during 
playback or during playback after more than one or two procedures of opening 
(and closing) full hd videos.

I guess that is due to the old nvidia video adapter and the driver nouveau.

Here is a syslog output at the moment of crash (copy/paste from nano):

Jun 16 01:25:05 user kernel: [12062.691373] nouveau :00:0d.0: bus: MMIO 
write of 017c0001 FAULT at 00b010

Jun 16 01:25:05 user kernel: [12062.737533] nouveau :00:0d.0: bus: MMIO 
write of 017c0001 FAULT at 00b010

Jun 16 01:25:05 user kernel: [12062.880903] nouveau :00:0d.0: bus: MMIO 
write of 02d40001 FAULT at 00b020

Jun 16 01:25:07 user kernel: [12064.697022] nouveau :00:0d.0: bus: MMIO 
write of  FAULT at 00b010

Jun 16 01:25:36 user kernel: [12093.475630] nouveau :00:0d.0: bus: MMIO 
write of  FAULT at 00b020

Jun 16 01:27:36 user kernel: [12213.081502] nouveau :00:0d.0: bus: MMIO 
write of 01850001 FAULT at 00b010

Jun 16 01:27:36 user kernel: [12213.126672] nouveau :00:0d.0: bus: MMIO 
write of 01850001 FAULT at 00b010

Jun 16 01:27:36 user kernel: [12213.258135] nouveau :00:0d.0: bus: MMIO 
write of 02910001 FAULT at 00b020

Jun 16 01:27:37 user kernel: [12214.950280] nouveau :00:0d.0: bus: MMIO 
write of  FAULT at 00b010

Jun 16 01:27:48 user kernel: [12225.936274] nouveau :00:0d.0: bus: MMIO 
write of  FAULT at 00b020

Jun 16 01:27:55 user kernel: [12232.290104] nouveau :00:0d.0: bus: MMIO 
write of 017b0001 FAULT at 00b010

Jun 16 01:27:55 user kernel: [12232.341367] nouveau :00:0d.0: bus: MMIO 
write of 017b0001 FAULT at 00b010

Jun 16 01:27:55 user kernel: [12232.454581] nouveau :00:0d.0: bus: MMIO 
write of 02d40001 FAULT at 00b020

Jun 16 01:27:56 user kernel: [12233.561988] nouveau :00:0d.0: bus: MMIO 
write of  FAULT at 00b010

Jun 16 01:28:10 user kernel: [12247.272435] nouveau :00:0d.0: bus: MMIO 
write of  FAULT at 00b020

Jun 16 01:33:26 user kernel: [12563.258826] nouveau :00:0d.0: bus: MMIO 
write of 01730001 FAULT at 00b010

Jun 16 01:33:26 user kernel: [12563.309403] nouveau :00:0d.0: bus: MMIO 
write of 01730001 FAULT at 00b010

Jun 16 01:33:26 user kernel: [12563.457561] nouveau :00:0d.0: bus: MMIO 
write of 02330001 FAULT at 00b020

Jun 16 01:33:27 user kernel: [12564.151786] nouveau :00:0d.0: bus: MMIO 
write of  FAULT at 00b010

^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^

Bug#890517: killer's CRON logs out users once per hour

2020-06-18 Thread Petter Reinholdtsen


Control: forwarded -1 https://bugs.x2go.org/cgi-bin/bugreport.cgi?bug=1171

[Wolfgang Schweer]
> Any news on this one? Debian Edu Bullseye intends to use x2goserver on 
> LTSP servers for Thin Client support...

The upstream issue is still open, at least.

(Just a quick reply to set the forwared url. :)

-- 
Happy hacking
Petter Reinholdtsen



Bug#963106: new upstream (4.12.3)

2020-06-18 Thread Daniel Baumann
Package: samba
Severity: normal

Hi,

thanks for maintaining samba in Debian.

The current samba release is at 4.12.3, it would be nice if you could
update the package to it.

Regards,
Daniel



Bug#962141: docker.io: CVE-2020-13401

2020-06-18 Thread Arnaud Rebillout



On 6/15/20 7:57 AM, Dmitry Smirnov wrote:

On Monday, 15 June 2020 7:23:41 AM AEST Felix Geyer wrote:

I've prepared an update for buster-security (debdiff attached).
With the update accept_ra is correctly set to 0 for bridges Docker creates.

Many thanks for your help, Felix.



@Maintainers:
Do you want me push the patch to the Git repo for unstable or are you
planning to update to 19.03.11 anyway?

Please go ahead and push. I'm not working on a new release but I'm not sure
about Arnaud.


  Thanks Felix!

Regarding my involvment in docker.io, just clarifying: I manage to keep 
the package afloat in Debian unstable, and I plan to keep doing that 
until the next release of Debian. I'm working on releasing a 19.03.11 
version to debian unstable, today or soon enough.


Regarding the package in Debian stable, I find myself unable to maintain 
it. Not following up on CVE, not following up on the Debian bugtracker, 
and overall no time to learn how I'm supposed to maintain packages in 
stable. So your help (or anyone) is more than welcome.


Thanks again,

  Arnaud



Bug#963105: (no subject)

2020-06-18 Thread Richard Hansen

Oops, the VCS link should have said: 
https://salsa.debian.org/rhansen/libscgi-perl



Bug#963105: RFS: libscgi-perl/0.6-1 [ITP] -- libscgi-perl - SCGI server library for perl

2020-06-18 Thread Richard Hansen

Package: sponsorship-requests
Severity: wishlist

Dear mentors,

I am looking for a sponsor for my package "libscgi-perl"

 * Package name: libscgi-perl
   Version : 0.6-1
   Upstream Author : Viper Code Limited
 * URL : https://metacpan.org/release/SCGI
 * License : Artistic or GPL-1+
 * Vcs : https://salsa.debian.org/debian/libscgi-perl
   Section : perl

It builds those binary packages:

  libscgi-perl - SCGI server library for perl

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

  https://mentors.debian.net/package/libscgi-perl

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

  dget -x 
https://mentors.debian.net/debian/pool/main/libs/libscgi-perl/libscgi-perl_0.6-1.dsc

Changes since the last upload:

   * Initial release.

Regards,

--
  Richard Hansen



Bug#962481: Printing to PDF makes files twenty million times bigger

2020-06-18 Thread Michael Gilbert
control: severity -1 minor
control: forwarded -1 http://crbug.com/1087707
control: retitle -1 print to pdf font subsetting issue

I am not able to reproduce this with 81.0.4044.92-1 following the
instructions in comment #13 from the upstream bug report.  I get a
500K pdf file with only DejaVuSans,DejaVuSansMono embedded, not
WenQuanYiZenHei,WenQuanYiZenHeiMono.

Is there anything else about your configuration that would be relevant?

Best wishes,
Mike



Bug#953537: xfsdump fails to install in /usr merged system.

2020-06-18 Thread peter green

This bug has now caused xfsdump to be kicked out of testing which is making 
amanda unbuildable in testing.



Yes, what's really needed here is for a change to be merged upstream
(as all other deb packaging artifacts are) otherwise this will keep
getting lost in time.

To make it easier to upstream this I whipped up a patch that should solve the 
issue while only modifying the debian packaging and not touching the upstream 
makefiles. It is attached to this message and if I get no response I will 
likely do some further testing and then NMU it in Debian.

One issue I noticed is it's not all all obvious who upstream is. The sgi 
website listed in README seems to be long dead and there are no obvious 
upstream results in a google search for xfsdump. Gentoos page on xfsdump links 
to https://xfs.wiki.kernel.org but that page makes no mention of xfsdump.

I eventually poked around on git.kernel.org and my best guess is that 
https://git.kernel.org/pub/scm/fs/xfs/xfsdump-dev.git/ is the upstream git 
repository and linux-...@vger.kernel.org is the appropriate mailing list, I 
would appreciate comments on whether or not this is correct and updates to the 
documentation to reflect whatever the correct location is.

diff -Nru xfsdump-3.1.9/debian/changelog xfsdump-3.1.9+nmu1/debian/changelog
--- xfsdump-3.1.9/debian/changelog  2020-01-31 17:30:58.0 +
+++ xfsdump-3.1.9+nmu1/debian/changelog 2020-06-19 01:01:18.0 +
@@ -1,3 +1,13 @@
+xfsdump (3.1.9+nmu1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Create and remove symlinks in postinst/preinst rather than including them
+in the package to support merged user systems. Based on a patch from
+Goffredo Baroncelli but adjusted to avoid the need for modifying upstream
+non-debian files. ( Closes: 953537 )
+
+ -- Peter Michael Green   Fri, 19 Jun 2020 01:01:18 +
+
 xfsdump (3.1.9) unstable; urgency=low
 
   * New upstream release
diff -Nru xfsdump-3.1.9/debian/rules xfsdump-3.1.9+nmu1/debian/rules
--- xfsdump-3.1.9/debian/rules  2020-01-31 17:30:58.0 +
+++ xfsdump-3.1.9+nmu1/debian/rules 2020-06-19 01:01:18.0 +
@@ -44,6 +44,9 @@
-rm -rf $(dirme)
$(pkgme) $(MAKE) -C . install
$(pkgme) $(MAKE) dist
+   #remove the symlinks in /usr/sbin, the postinst will create them
+   #if appropriate for the users system 
+   rm -f debian/xfsdump/usr/sbin/xfsdump debian/xfsdump/usr/sbin/xfsrestore
dh_installdocs
dh_installchangelogs
dh_strip
diff -Nru xfsdump-3.1.9/debian/xfsdump.postinst 
xfsdump-3.1.9+nmu1/debian/xfsdump.postinst
--- xfsdump-3.1.9/debian/xfsdump.postinst   1970-01-01 00:00:00.0 
+
+++ xfsdump-3.1.9+nmu1/debian/xfsdump.postinst  2020-06-19 00:59:32.0 
+
@@ -0,0 +1,12 @@
+#!/bin/sh
+set -e
+
+if [ "$1" = 'configure' ]; then
+  for file in xfsdump xfsrestore; do
+if [ ! -e /usr/sbin/$file ]; then
+  ln -s /sbin/$file /usr/sbin/$file
+fi
+  done
+fi
+
+#DEBHELPER#
diff -Nru xfsdump-3.1.9/debian/xfsdump.preinst 
xfsdump-3.1.9+nmu1/debian/xfsdump.preinst
--- xfsdump-3.1.9/debian/xfsdump.preinst1970-01-01 00:00:00.0 
+
+++ xfsdump-3.1.9+nmu1/debian/xfsdump.preinst   2020-06-19 01:01:18.0 
+
@@ -0,0 +1,12 @@
+#!/bin/sh
+set -e
+
+if [ "$1" = 'remove' ]; then
+  for file in xfsdump xfsrestore; do
+if [ -L /usr/sbin/$file ]; then
+  rm /usr/sbin/$file
+fi
+  done
+fi
+
+#DEBHELPER#


Bug#963080: chromium dies in libva

2020-06-18 Thread Michael Gilbert
control: severity -1 important

On Thu, Jun 18, 2020 at 12:48 PM Harald Dunkel wrote:
> libva-x11-2 is version 2.7.1-1. nvidia-graphics-drivers is version 440.82-2.
> I cannot reproduce this using google-chrome 83.0.4103.106-1.

This is caused by ffmpeg 4.3, see #963035.

Best wishes,
Mike



Bug#944989: ITP: python-fissix -- backport of lib2to3, supporting the latest Python3 grammars, with enhancements

2020-06-18 Thread Nicholas D Steeves
Update:

https://github.com/jreese/fissix/issues/8 has been resolved, but
upstream has transitioned to pyproject.toml.  We don't yet have Debian
tooling for this format, so my current plan is to package DepHell,
convert pyproject.toml to setup.py at build-time, and then use the
existing dh_python + pybuild support.


signature.asc
Description: PGP signature


Bug#884229: Bug #884229: 500 Internal Server Error (old files in

2020-06-18 Thread Nicholas D Steeves
Hi Laura,

Laura Arjona Reina  writes:

> Hello
>
> Today I got mail about error 500 Internal Server Error happening in
> packages.debian.org, not related to this one, but I took the opportunity
> to review the situation about this bug too.
>
> 1. I cannot reproduce now the 500 Internal Server Error nor in picconi
> nor in pkgmirror-csail with any of the links provided in this bug
> report. Everything seems to work fine.
>
> 2.- I have checked both machines and the files under
> /srv/packages.debian.org/files/db/xapian/ are similar, so I guess
> synchronization is happening well.
>
> 3.- I have seen that the folder
> /srv/packages.debian.org/files/db/xapian/old-files/ still existed, so I
> have removed the old files there and the old-files folder too.
>
> So, closing this bug; if any issue happens again feel free to reopen or
> open a new bug (I guess we'd need to look at the issues in syncing both
> servers).
>

Thanks, that's a fair assessment.  I confirm that my DDPO and Dashboard
looks good, with the exception of some git repo 404 errors that look
like gitlab/salsa bugs (off topic for this bug).

Best,
Nicholas

P.S. resending to bug@bugs.d.o, because I accidentally CCed bugs-done in
my last reply.


signature.asc
Description: PGP signature


Bug#963103: conserver: this package is Free Software, please move it to main

2020-06-18 Thread Paul Wise
Source: conserver
Severity: wishlist

Since filing #931365 I discovered that due to the lack of an explicit
modification permission in the license on code owned by Ohio State University, 
this package is in Debian non-free. I discussed this in various places and I 
have concluded that the license is free for several reasons and that it should 
be moved to Debian main.

 * There is an implicit modification permission in the anti-endorsement 
   clause in the license.
 * The BSD license authors updated the original BSD license to include
   an explicit modification permission, indicating the initial lack of
   explicit modification permission was an unintentional mistake and
   corrected this when it was pointed out to them.
 * The author of the affected conserver code intended to allow
   modifications and believes the existing license implicitly allows
   modifications.
 * There are several packages in Debian main (inc Linux, GCC etc) using
   the same license that caused this package to be in non-free.

https://github.com/bstansell/conserver/blob/master/LICENSES.md
https://www.conserver.com/pipermail/users/2019-July/msg0.html
https://www.conserver.com/pipermail/users/2019-July/msg1.html
https://www.conserver.com/pipermail/users/2019-July/msg2.html
https://www.conserver.com/pipermail/users/2020-May/msg1.html
https://lists.debian.org/msgid-search/a8259f8fb4348c790076ffcaf8721ecba7c714a3.ca...@debian.org
https://lists.debian.org/msgid-search/caktje6gyyvhyvo0rvo-4bslcoofr2zn3e-0sgmtegr7+j7w...@mail.gmail.com

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


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


Bug#963018: /root/.my.cnf overrides .backup-manager_my.cnf config

2020-06-18 Thread Andrei POPESCU
Control: reassign -1 backup-manager 0.7.14-1+deb10u1

On Mi, 17 iun 20, 20:41:19, sbalb...@free.fr wrote:
> Package: Backup Manager
> Version: 0.7.14
> 
> Context :
> Debian 10.4
> mysql Ver 15.1 Distrib 10.3.22-MariaDB
> Backup Manager 0.7.14
> 
> The backup fail with the following error:
> mysqldump: Got error: 1045: "Access denied for user 
> 'backupmanager'@'localhost' (using password: YES)" when trying to connect
> 
> When I use mysql/mysqldump with -u and -p options, no issues all is fine
> 
> The file /root/.backup-manager_my.cnf is present and with the correct 
> permissions / password inside.
> 
> I have another file /root/.my.cnf containing root user and password and I 
> think this is the source of the issue !
> 
> When referring to 
> https://mariadb.com/kb/en/configuring-mariadb-with-option-files/, it seems 
> that the filed passed in the command line with —default-extra-file is 
> overrides with the .my.cnf values
> 
> if I manually update the commande issued by backup manager using « 
> —default-file » instead of « —default-extra-file », it works
> 
> sudo /usr/bin/mysqldump --defaults-file=/root/.backup-manager_my.cnf --opt 
> -ubackupmanager -hlocalhost -P3306 mysql > mysql.sql
> 
> 
> Can you confirm the issue, please ?
> 
> Any chance to have this fixed soon or I should « patch » 
> https://salsa.debian.org/debian/backup-manager/-/blob/master/lib/backup-methods.sh#L1016
>  ?
> Maybe the most flexible way would be to be able to define the name of the 
> parameter to be used (—default-file or —default-extra-file) in the config 
> file.
> 
> Cheers
> -sylvain

-- 
Looking after bugs filled against unknown packages


signature.asc
Description: PGP signature


Bug#963101: cozy-audiobook-player: "Request For Package"

2020-06-18 Thread Andrei POPESCU
Control: reassign -1 wnpp
Control: retitle -1 RFP: cozy-audiobook-player -- slick GUI audiobook player

On Jo, 18 iun 20, 20:07:15, Randy Edwards wrote:
> Package: cozy-audiobook-player
> Version: "Request For Package
> Severity: wishlist
> 
> Dear Maintainer,
> 
> This is a request to package Cozy, a slick GPLed GUI audiobook player for
> Linux.
> 
> You can grab the source and more info at https://github.com/geigi/cozy or
> https://cozy.geigi.de/
> 
> 
> 
> -- System Information:
> Debian Release: 10.4
>   APT prefers stable-updates
>   APT policy: (500, 'stable-updates'), (500, 'stable')
> Architecture: amd64 (x86_64)
> Foreign Architectures: i386
> 
> Kernel: Linux 4.19.0-9-amd64 (SMP w/16 CPU cores)
> Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
> LANGUAGE=en_US.UTF-8 (charmap=UTF-8)
> Shell: /bin/sh linked to /usr/bin/dash
> Init: systemd (via /run/systemd/system)
> LSM: AppArmor: enabled

-- 
Looking after bugs filled against unknown packages


signature.asc
Description: PGP signature


Bug#961381: gsutil: autopkgtest failure: Can't locate LWP/UserAgent.pm in @INC

2020-06-18 Thread Regis Fernandes Gontijo
Control: tags 961381 patch

Hi Paul

thank you very much for your report.

The problem is that there are dependencies issues for gsutil since the changes 
from 3.1-1 (see: #620478)

I confirmed it by just running gsutil from the command line in a clean 
environment.

As we can see in the README from upstream

> Only perl and perl-libwww-perl were used, and they came
> with the operating system, so you probably won't have to
> download any perl modules.

But Depends field from debian/control says:

libhtml-form-perl | libwww-perl (<< 6)


The fix is just change to:


libhtml-form-perl, libwww-perl

The restrictions for the version of libwww-perl needs to be removed because 
libhtml-form-perl don't replaces libwww-perl. It could be used only if a 
package needs only libhtml-form-perl. As said in #620478 there was only 
libwww-perl in the past, which was splitted in libwww-perl and 
libhtml-form-perl at the time of #620478 .

I tested the changes in a clean jail and I reproduced it with both source and 
binary packages, from 3.1-1 to 3.1-4.

I'll upload the fix and also the 'Restrictions: superficial' for autopkgtest.

Cheers

Régis
diff -Nru gsutil-3.1/debian/control gsutil-3.1/debian/control
--- gsutil-3.1/debian/control	2020-05-11 03:16:27.0 +
+++ gsutil-3.1/debian/control	2020-06-18 06:33:01.0 +
@@ -7,7 +7,7 @@
 
 Package: gsutil
 Architecture: all
-Depends: ${shlibs:Depends}, ${misc:Depends}, ${perl:Depends}, libhtml-form-perl | libwww-perl (<< 6)
+Depends: ${shlibs:Depends}, ${misc:Depends}, ${perl:Depends}, libhtml-form-perl, libwww-perl
 Description: configure and manage Grandstream BudgeTone 100 VOIP and GX2000 phones
  GsUtil is a short program written to dump and restore the data
  from randstream BudgeTone 100 VOIP and GX2000 phone.


Bug#963058: android-platform-art ftbfs on arm64

2020-06-18 Thread Andrei POPESCU
Control: reassign -1 src:android-platform-art 8.1.0+r23-4

On Jo, 18 iun 20, 14:53:43, Matthias Klose wrote:
> Package: src:
> Version: 8.1.0+r23-4
> Severity: serious
> Tags: sid bullseye
> 
> android-platform-art ftbfs on arm64:
> 
> [...]
> python3 tools/generate-operator-out.py runtime runtime/arch/instruction_set.h
> runtime/base/allocator.h runtime/base/callee_save_type.h runtime/base/enums.h
> runtime/base/mutex.h runtime/debugger.h runtime/base/unix_file/fd_file.h
> runtime/dex_file.h runtime/dex_file_layout.h runtime/dex_instruction.h
> runtime/dex_instruction_utils.h runtime/gc_root.h runtime/gc/allocator_type.h
> runtime/gc/allocator/rosalloc.h runtime/gc/collector_type.h
> runtime/gc/collector/gc_type.h runtime/gc/heap.h 
> runtime/gc/space/region_space.h
> runtime/gc/space/space.h runtime/gc/weak_root_state.h runtime/image.h
> runtime/instrumentation.h runtime/indirect_reference_table.h
> runtime/invoke_type.h runtime/jdwp/jdwp.h runtime/jdwp/jdwp_constants.h
> runtime/lock_word.h runtime/mirror/class.h runtime/oat.h
> runtime/object_callbacks.h runtime/process_state.h runtime/stack.h
> runtime/suspend_reason.h runtime/thread.h runtime/thread_state.h
> runtime/ti/agent.h runtime/verifier/verifier_enums.h > operator_out.cc
> clang -o runtime/interpreter/mterp/out/mterp_arm64.o -g -O2
> -fdebug-prefix-map=/<>=. -fstack-protector-strong -Wformat
> -Werror=format-security -fPIC -c -Wdate-time -D_FORTIFY_SOURCE=2 -DNDEBUG
> -I/usr/include/android -UDEBUG -Umips -DART_BASE_ADDRESS_MAX_DELTA=0x100
> -DART_BASE_ADDRESS_MIN_DELTA=-0x100 -DART_BASE_ADDRESS=0x6000
> -DART_DEFAULT_COMPACT_DEX_LEVEL=fast -DART_DEFAULT_GC_TYPE_IS_CMS
> -DART_ENABLE_ADDRESS_SANITIZER=1 -DART_ENABLE_CODEGEN_arm
> -DART_ENABLE_CODEGEN_arm64 -DART_ENABLE_CODEGEN_mips 
> -DART_ENABLE_CODEGEN_mips64
> -DART_ENABLE_CODEGEN_x86 -DART_ENABLE_CODEGEN_x86_64 
> -DART_FRAME_SIZE_LIMIT=6400
> -DART_READ_BARRIER_TYPE_IS_BAKER=1 -DART_STACK_OVERFLOW_GAP_arm=8192
> -DART_STACK_OVERFLOW_GAP_arm64=8192 -DART_STACK_OVERFLOW_GAP_mips=16384
> -DART_STACK_OVERFLOW_GAP_mips64=16384 -DART_STACK_OVERFLOW_GAP_x86_64=20480
> -DART_STACK_OVERFLOW_GAP_x86=16384 -DART_USE_READ_BARRIER=1 
> -DBUILDING_LIBART=1
> -DIMT_SIZE=43 -DUSE_D8_DESUGAR=1 -I. -I/usr/include/android/nativehelper
> -I/usr/include/valgrind -Icmdline -Iruntime -Iruntime/generated -Isigchainlib
> runtime/interpreter/mterp/out/mterp_arm64.S
> runtime/interpreter/mterp/out/mterp_arm64.S:392:23: error: expected
> '[su]xt[bhw]' with optional integer in range [0, 4]
> add x25, x21, w0, lsl #2
>   ^
> runtime/interpreter/mterp/out/mterp_arm64.S:395:23: error: expected
> '[su]xt[bhw]' with optional integer in range [0, 4]
> add x20, x20, w0, lsl #1
>   ^
> :1:19: error: expected '[su]xt[bhw]' with optional integer in
> range [0, 4]
> add x17, x21, w3, lsl #2
>   ^
> runtime/interpreter/mterp/out/mterp_arm64.S:489:5: note: while in macro
> instantiation

-- 
Looking after bugs filled against unknown packages


signature.asc
Description: PGP signature


Bug#963018: /root/.my.cnf overrides .backup-manager_my.cnf config

2020-06-18 Thread Andrei POPESCU
Control: reassign backup-manager 0.7.14-1+deb10u1

On Mi, 17 iun 20, 20:41:19, sbalb...@free.fr wrote:
> Package: Backup Manager
> Version: 0.7.14
> 
> Context :
> Debian 10.4
> mysql Ver 15.1 Distrib 10.3.22-MariaDB
> Backup Manager 0.7.14
> 
> The backup fail with the following error:
> mysqldump: Got error: 1045: "Access denied for user 
> 'backupmanager'@'localhost' (using password: YES)" when trying to connect
> 
> When I use mysql/mysqldump with -u and -p options, no issues all is fine
> 
> The file /root/.backup-manager_my.cnf is present and with the correct 
> permissions / password inside.
> 
> I have another file /root/.my.cnf containing root user and password and I 
> think this is the source of the issue !
> 
> When referring to 
> https://mariadb.com/kb/en/configuring-mariadb-with-option-files/, it seems 
> that the filed passed in the command line with —default-extra-file is 
> overrides with the .my.cnf values
> 
> if I manually update the commande issued by backup manager using « 
> —default-file » instead of « —default-extra-file », it works
> 
> sudo /usr/bin/mysqldump --defaults-file=/root/.backup-manager_my.cnf --opt 
> -ubackupmanager -hlocalhost -P3306 mysql > mysql.sql
> 
> 
> Can you confirm the issue, please ?
> 
> Any chance to have this fixed soon or I should « patch » 
> https://salsa.debian.org/debian/backup-manager/-/blob/master/lib/backup-methods.sh#L1016
>  ?
> Maybe the most flexible way would be to be able to define the name of the 
> parameter to be used (—default-file or —default-extra-file) in the config 
> file.
> 
> Cheers
> -sylvain

-- 
Looking after bugs filled against unknown packages


signature.asc
Description: PGP signature


Bug#963101: cozy-audiobook-player: "Request For Package"

2020-06-18 Thread Randy Edwards
Package: cozy-audiobook-player
Version: "Request For Package
Severity: wishlist

Dear Maintainer,

This is a request to package Cozy, a slick GPLed GUI audiobook player for
Linux.

You can grab the source and more info at https://github.com/geigi/cozy or
https://cozy.geigi.de/



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

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



Bug#918887: ITA: quickml -- Very-easy-to-use mailing list system

2020-06-18 Thread Marcelo Mota
Hi,

I am willing to take care of the package.

Regards,

Marcelo S Mota



Bug#962973: haskell-readline: Removal notice: broken and unmaintained

2020-06-18 Thread Sean Whitton
Hello,

On Wed 17 Jun 2020 at 05:17PM -04, Joey Hess wrote:

> It could be converted to haskeline or raw IO, but gnu readline is the
> kind of library I think it makes sense to have language bindings to, and
> to use the bindings.
>
> This patch seems to fix the build problem:

Gratefully applying this patch and marking the upload as closing this
bug, but if Ilias thinks we should still consider dropping this library
for the reason that it's unmaintained, he should reopen the bug.

-- 
Sean Whitton



Bug#890517: killer's CRON logs out users once per hour

2020-06-18 Thread Wolfgang Schweer
Moin Mike,

On Wed, 06 Feb 2019 11:25:54 + Mike Gabriel 
 wrote:
> > control: severity -1 serious
> > # x2go-server is now in buster
> > thanks
> 
> neither x2goserver nor killer are unusable due to the missing  
> utmp/wtmp registration. Thus, reducing severity to imporant.
> 
> I will look into this issue for buster is out while we are still in  
> soft-freeze (in fact I have some local prototype already, but need to  
> revisit).
 
Any news on this one? Debian Edu Bullseye intends to use x2goserver on 
LTSP servers for Thin Client support...
 
Wolfgang


signature.asc
Description: PGP signature


Bug#838392: dpkg: should build-depend on hurd-dev

2020-06-18 Thread Samuel Thibault
Hello,

Guillem Jover, le lun. 15 juin 2020 05:11:21 +0200, a ecrit:
> On Wed, 2016-09-21 at 08:58:11 +0200, Samuel Thibault wrote:
> > Helmut Grohne, on Wed 21 Sep 2016 06:09:22 +0200, wrote:
> > > Thus I suggest to close this bug or turn it into wishlist bugs for the
> > > above.
> > 
> > Right. Also adding the bug dependency. I didn't remember that we still
> > hadn't fixed that part. So we're waiting for dpkg-genchanges' 818618 :)
> > Guillem had concerns which he raised on
> > 
> > https://lists.debian.org/debian-devel/2016/04/msg00326.html
> > 
> > I answered that what we actually need here is way less invasive than
> > what Guillem raised:
> > 
> > https://lists.debian.org/debian-devel/2016/04/msg00327.html
> 
> Bug 818618 was fixed in dpkg 1.19.3, is there still something else
> missing from the dpkg side? AFAIR there was a problem with DAK, but
> cannot recall if it was related to this problem.

IIRC it was, but now that the hurd-i386 binaries go to debian-ports, it
is not relevant any more, and thus it's not a problem for the hurd
source package any more.

Samuel



Bug#963098: dwarfdump: dump .eh_frame fails on x86-64 elf

2020-06-18 Thread Fabian Wolff
Hi Nick,

thanks for reporting this; indeed, I could reproduce the error, and 
llvm-dwarfdump
doesn't produce a similar error (unsurprisingly, if the file was generated with
LLVM in the first place).

I'm hereby forwarding your report to libdwarf's upstream developer - David, 
could
you have a look at this?

Thanks!

On 6/18/20 11:44 PM, Nick Lewycky wrote:
> Package: dwarfdump
> Version: 20200114-1
> Severity: normal
> 
> Dear Maintainer,
> 
> I have an ordinary x86-64 ELF .o file (attached) which was produced by LLVM,
> but dwarfdump issues an error when asked to dump the .eh_frame:
> 
> $ dwarfdump -F function_0.o
> 
> .eh_frame
> 
> dwarfdump ERROR:  dwarf_get_fde_list: 
> DW_DLE_RELOC_SECTION_RELOC_TARGET_SIZE_UNKNOWN (233) so doing a relocation is 
> unsafe
> 
> -- System Information:
> Debian Release: bullseye/sid
>   APT prefers stable-updates
>   APT policy: (500, 'stable-updates'), (500, 'testing'), (500, 'stable')
> Architecture: amd64 (x86_64)
> Foreign Architectures: i386
> 
> Kernel: Linux 5.6.0-1-amd64 (SMP w/8 CPU cores)
> Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
> LANGUAGE=en_US.UTF-8 (charmap=UTF-8)
> Shell: /bin/sh linked to /usr/bin/dash
> Init: systemd (via /run/systemd/system)
> LSM: AppArmor: enabled
> 
> Versions of packages dwarfdump depends on:
> ii  libc6  2.30-8
> ii  libdwarf1  20200114-1
> ii  libelf1    0.176-1.1
> 
> dwarfdump recommends no packages.
> 
> dwarfdump suggests no packages.
> 
> -- no debconf information
> 


function_0.o
Description: application/object


Bug#962968: libauthen-sasl-perl: Net::LDAP with GSSAPI SASL bind connecting with wrong sasl_ssf on Debian buster

2020-06-18 Thread A. Lewenberg
As a further test, here is a simple python script that does the same 
thing as the Perl script. It works fine and the LDAP logs show 
"sasl_ssf=256 ssf=256" when I run it:


###
import ldap
import ldap.sasl
import os

ldap_server = 'ldap.example.com'
os.environ["KRB5CCNAME"] = "/tmp/testing.tkt"

conn = ldap.ldapobject.ReconnectLDAPObject('ldap://' + ldap_server, 
retry_max = 5)

auth = ldap.sasl.gssapi("")
conn.sasl_interactive_bind_s("", auth)

basedn  = 'dc=example,dc=com'
searchScope = ldap.SCOPE_SUBTREE
searchFilter= '(uid=johndoe)'
searchAttribute = [
"uid",
"sn",
]
ldap_result_id = conn.search(basedn, searchScope, searchFilter, 
searchAttribute)

result_type, result_data = conn.result(ldap_result_id, 0)
print(result_data)
###

So, ldapsearch and the python script appear to connect with 
"sasl_ssf=256 ssf=256" but the Perl script connects with "sasl_ssf=1 
ssf=256". Why?




On Tue, 16 Jun 2020 08:25:51 -0700 Richard Landster 
 wrote:

Package: libauthen-sasl-perl
Version: 2.1600-1
Severity: important

Dear Maintainer,

I have a Perl script to read from an OpenLDAP instance using Net::LDAP
with a GSSAPI bind. The script works fine on Debian stretch but fails on
Debian buster.

Note that on both servers the line at the bottom of the Perl code that
runs ldapsearch produces the same correct results, so I am sure that the
Kerberos ticket cache is correct on both servers.

Looking at the OpenLDAP logs I see that the ldapsearch run shows up with
the strength factors sasl_ssf=256 ssf=256 while the Net::LDAP bind shows
up with the strength factors sasl_ssf=1 ssf=256. Since the Net::LDAP bind
is using Kerberos, the sasl_ssf should be 56, not 1.

###

use strict;
use warnings;
use Authen::SASL;
use Net::LDAP;
use Data::Dumper;

my $server_name = 'ldap.example.com';
$ENV{'KRB5CCNAME'} = '/tmp/krb.tkt';

my $ld = Net::LDAP->new($server_name, version => '3');
$ld->start_tls(verify => 'require');

if (!$ld or $ld == -1) {
die "Could not connect to directory server $server_name";
}

my $SASL = Authen::SASL->new('GSSAPI');
my $status = $ld->bind(sasl => $SASL);

if ($status->code) {
die  'Bind error: (' . $status->error_name . ') ' . $status->error_text;
}

my $base   = 'dc=example,dc=com';
my $filter = '(uid=johndoe)';
my @attrs  = ('uid', 'sn');
$status = $ld->search(
base=> 'dc=example,dc=com',
filter  => $filter,
attrs   => \@attrs,
) ;

my @entries = $status->all_entries;
# This results in nothing (but should result in the same data as the ldapsearch 
below):
warn Dumper @entries ;

my $attrs = join(' ', @attrs) ;
my $cmd = "ldapsearch -LLL -h $server_name -b $base '$filter' $attrs";
# This gives the correct result:




Bug#963099: lacks-unversioned-link-to-shared-library false positive

2020-06-18 Thread Bill Allombert
Package: lintian
Version: 2.15.0
Severity: normal

Dear Lintian maintainers,

lintian report a warning:
W: libpari-gmp-tls6: lacks-unversioned-link-to-shared-library
usr/lib/x86_64-linux-gnu/libpari-gmp-tls.so.2.11.4
usr/lib/x86_64-linux-gnu/libpari-gmp-tls.so

However while there is a requirement that the -dev package provides
a *.so symlink to libpari-gmp-tls.so.2.11.4, there is no requirement
that it has the same basename 'libpari-gmp-tls'.
In the above case the link is named libpari.so.

This seems an easy to avoid false positive.

Cheers,
-- 
Bill. 

Imagine a large red swirl here. 



Bug#963098: dwarfdump: dump .eh_frame fails on x86-64 elf

2020-06-18 Thread Nick Lewycky

Package: dwarfdump
Version: 20200114-1
Severity: normal

Dear Maintainer,

I have an ordinary x86-64 ELF .o file (attached) which was produced by LLVM,
but dwarfdump issues an error when asked to dump the .eh_frame:

$ dwarfdump -F function_0.o

.eh_frame

dwarfdump ERROR:  dwarf_get_fde_list: 
DW_DLE_RELOC_SECTION_RELOC_TARGET_SIZE_UNKNOWN (233) so doing a 
relocation is unsafe


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

Kernel: Linux 5.6.0-1-amd64 (SMP w/8 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US.UTF-8 (charmap=UTF-8)

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

Versions of packages dwarfdump depends on:
ii  libc6  2.30-8
ii  libdwarf1  20200114-1
ii  libelf1    0.176-1.1

dwarfdump recommends no packages.

dwarfdump suggests no packages.

-- no debconf information



function_0.o
Description: application/object


Bug#963085: ITP: selint -- Static code analysis of refpolicy style SELinux policies

2020-06-18 Thread Christian Göttsche
Package: wnpp
Severity: wishlist
X-Debbugs-CC: selinux-de...@lists.alioth.debian.org

* Package name: selint
  Version : 1.1.0
  Upstream Author : Daniel Burgener 
* URL : https://github.com/TresysTechnology/selint
* License : Apache-2.0
  Description : Static code analysis of refpolicy style SELinux policies
 SELint is a program to perform static code analysis on SELinux policy
 source files.
 .
 It is designed for refpolicy style policies and supports the standard
 SELinux policy language (not CIL).
 .
 It performs various checks from incorrect filecontext
 definitions over missing or superfluous required entries in interfaces
 to violations of the refpolicy style guide. All categories can be either
 enabled or disabled via the command line or a configuration file.

SELint is going to be maintained by the Debian SELinux maintainers,
see https://salsa.debian.org/selinux-team/selint .



Bug#943015: marked as pending in fonts-ebgaramond

2020-06-18 Thread Moritz Mühlenhoff
On Thu, Nov 14, 2019 at 02:09:28PM +, Hideki Yamane wrote:
> Control: tag -1 pending
> 
> Hello,
> 
> Bug #943015 in fonts-ebgaramond 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/fonts-team/fonts-ebgaramond/commit/54da98c3f51a94a0c5a7fae92a037fb49c18f797
> 
> 
> use python3 (Closes: #943015)
> 
>  * debian/control
>- use python3-fontforge
>  * debian/patches
>- add 0002-use-python3.patch
> 

What's the status, this is pendingg for over half a year? :-)

Cheers,
Moritz



Bug#963097: RM: opensips -- RoQA; Depends on Python 2, unmaintained

2020-06-18 Thread Moritz Muehlenhoff
Package: ftp.debian.org
Severity: normal

Please remove opensips. It depends on Python 2, is unmaintained
(no activity since 2016) and was already dropped from Buster.

Cheers,
 Moritz



Bug#963096: RM: snetz -- RoQA; Depends on Python 2, dead upstream, unmaintained

2020-06-18 Thread Moritz Muehlenhoff
Package: ftp.debian.org
Severity: normal

Please remove snetz. It's dead upstream (last release in 2012), depends on
Python 2 and the last and only upload was in 2014.

Cheers,
Moritz



Bug#963095: RM: woof -- RoQA; Depends on Python 2, dead upstream, unmaintained

2020-06-18 Thread Moritz Muehlenhoff
Package: ftp.debian.org
Severity: normal

Please remove woof. It depends on Python 2, is dead upstream and the last
maintainer upload was in 2011.

Cheers,
Moritz



Bug#936392: dh-virtualenv: Python2 removal in sid/bullseye

2020-06-18 Thread Uwe Kleine-König
Control: tag -1 fixed-upstream

Hello,

On Fri, Aug 30, 2019 at 07:14:58AM +, Matthias Klose wrote:
> Your package either build-depends, depends on Python2, or uses Python2
> in the autopkg tests.  Please stop using Python2, and fix this issue
> by one of the following actions.
> 
> - Convert your Package to Python3. This is the preferred option.  In
>   case you are providing a Python module foo, please consider dropping
>   the python-foo package, and only build a python3-foo package.  Please
>   don't drop Python2 modules, which still have reverse dependencies,
>   just document them.
>   
>   This is the preferred option.

This is already implemented in the upstream git repository since at
least commit c73d7dab6f1f ("Build debian package with python3")[1]

So all we're waiting for is (probably) a release 1.2 and then an updated
debian package. As the upstream author seems to match the Debian
package maintainer I wonder if there is still a problem I'm missing
given the package was already removed from testing[2] for the Python2
removal.

Best regards
Uwe

[1] 
https://github.com/spotify/dh-virtualenv/commit/c73d7dab6f1f2346cebc751ea8f90406c614833f.
[2] https://tracker.debian.org/news/1086738/dh-virtualenv-removed-from-testing/

-- 
Pengutronix e.K.   | Uwe Kleine-König|
Industrial Linux Solutions | https://www.pengutronix.de/ |


signature.asc
Description: PGP signature


Bug#963094: wine-development: FTBFS with libvulkan1 1.2.141.0-1

2020-06-18 Thread Ximin Luo
Package: wine-development
Version: 5.5-4
Followup-For: Bug #963094
Control: tags -1 + upstream patch

Looks like these patches fix the issue:

https://github.com/wine-mirror/wine/commit/4465ecfe0e3fa9fa14518abd1907193adb154957.patch
https://github.com/wine-mirror/wine/commit/727441cc24d54d9a6623d523788d4011c526ba94.patch

-- Package-specific info:
/usr/bin/wine points to /usr/bin/wine-development.

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

Kernel: Linux 5.5.0-1-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_GB.utf8, LC_CTYPE=en_GB.utf8 (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 wine-development depends on:
ii  wine32-development  5.5-4
ii  wine64-development  5.5-4

wine-development recommends no packages.

Versions of packages wine-development suggests:
ii  dosbox0.74-3-1
pn  exe-thumbnailer | kio-extras  
pn  playonlinux   
pn  q4wine
pn  winbind   
pn  wine-binfmt   
ii  winetricks0.0+20200412-1

Versions of packages libwine-development depends on:
ii  libasound2   1.2.2-2.2
ii  libc62.30-8
ii  libfaudio0   20.04-2
ii  libfontconfig1   2.13.1-4.2
ii  libfreetype6 2.10.1-2
ii  libgcc-s110.1.0-3
ii  libglib2.0-0 2.64.3-1
ii  libgphoto2-6 2.5.24-1
ii  libgphoto2-port122.5.24-1
ii  libgstreamer-plugins-base1.0-0   1.16.2-4
ii  libgstreamer1.0-01.16.2-2
ii  liblcms2-2   2.9-4+b1
ii  libldap-2.4-22.4.50+dfsg-1
ii  libmpg123-0  1.25.13-1
ii  libncurses6  6.2-1
ii  libopenal1   1:1.19.1-1+b1
ii  libpcap0.8   1.9.1-4
ii  libpulse013.0-5
ii  libtinfo66.2-1
ii  libudev1 245.6-1
ii  libunwind8   1.2.1-9
ii  libvkd3d11.1-4
ii  libx11-6 2:1.6.9-2+b1
ii  libxext6 2:1.3.3-1+b2
ii  libxml2  2.9.10+dfsg-5+b1
ii  ocl-icd-libopencl1 [libopencl1]  2.2.12-4
ii  zlib1g   1:1.2.11.dfsg-2

Versions of packages libwine-development recommends:
ii  fonts-liberation   1:1.07.4-11
ii  fonts-wine 5.0-4
ii  gstreamer1.0-plugins-good  1.16.2-3
ii  libasound2-plugins 1.2.2-1
ii  libgl1-mesa-dri20.1.1-1

Versions of packages libwine-development suggests:
pn  cups-bsd   
ii  gstreamer1.0-libav 1.16.2-2
pn  gstreamer1.0-plugins-bad   
ii  gstreamer1.0-plugins-ugly  1.16.2-2+b1
ii  ttf-mscorefonts-installer  3.8

Versions of packages wine32-development depends on:
ii  libc62.30-8
ii  libwine-development  5.5-4

wine32-development recommends no packages.

Versions of packages wine32-development suggests:
pn  wine32-development-preloader  

Versions of packages wine64-development depends on:
ii  libc62.30-8
ii  libwine-development  5.5-4

Versions of packages wine64-development recommends:
ii  wine32-development  5.5-4

Versions of packages wine64-development suggests:
pn  wine64-development-preloader  

Versions of packages wine-development is related to:
pn  dxvk 
pn  dxvk-wine32-development  
pn  dxvk-wine64-development  
ii  fonts-wine   5.0-4

-- no debconf information



Bug#963094: wine-development: FTBFS with libvulkan1 1.2.141.0-1

2020-06-18 Thread Ximin Luo
Package: wine-development
Version: 5.5-4
Severity: serious
Justification: FTBFS

Dear Maintainer,

Sadly, the latest update to "support vulkan 1.2" does not work with the latest
version, uploaded 1 day after the fix.

[..]
cd dlls/winevulkan && ./make_vulkan
Traceback (most recent call last):
  File "./make_vulkan", line 3081, in 
main()
  File "./make_vulkan", line 3059, in main
registry = VkRegistry(vk_xml)
  File "./make_vulkan", line 2581, in __init__
self._parse_types(root)
  File "./make_vulkan", line 2908, in _parse_types
_type = t.find("type").text
AttributeError: 'NoneType' object has no attribute 'text'
make[1]: *** [debian/rules:134: override_dh_auto_configure] Error 1
make[1]: Leaving directory '/<>'
make: *** [debian/rules:122: binary-arch] Error 2
dpkg-buildpackage: error: debian/rules binary-arch subprocess returned exit 
status 2

X

-- Package-specific info:
/usr/bin/wine points to /usr/bin/wine-development.

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

Kernel: Linux 5.5.0-1-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_GB.utf8, LC_CTYPE=en_GB.utf8 (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 wine-development depends on:
ii  wine32-development  5.5-4
ii  wine64-development  5.5-4

wine-development recommends no packages.

Versions of packages wine-development suggests:
ii  dosbox0.74-3-1
pn  exe-thumbnailer | kio-extras  
pn  playonlinux   
pn  q4wine
pn  winbind   
pn  wine-binfmt   
ii  winetricks0.0+20200412-1

Versions of packages libwine-development depends on:
ii  libasound2   1.2.2-2.2
ii  libc62.30-8
ii  libfaudio0   20.04-2
ii  libfontconfig1   2.13.1-4.2
ii  libfreetype6 2.10.1-2
ii  libgcc-s110.1.0-3
ii  libglib2.0-0 2.64.3-1
ii  libgphoto2-6 2.5.24-1
ii  libgphoto2-port122.5.24-1
ii  libgstreamer-plugins-base1.0-0   1.16.2-4
ii  libgstreamer1.0-01.16.2-2
ii  liblcms2-2   2.9-4+b1
ii  libldap-2.4-22.4.50+dfsg-1
ii  libmpg123-0  1.25.13-1
ii  libncurses6  6.2-1
ii  libopenal1   1:1.19.1-1+b1
ii  libpcap0.8   1.9.1-4
ii  libpulse013.0-5
ii  libtinfo66.2-1
ii  libudev1 245.6-1
ii  libunwind8   1.2.1-9
ii  libvkd3d11.1-4
ii  libx11-6 2:1.6.9-2+b1
ii  libxext6 2:1.3.3-1+b2
ii  libxml2  2.9.10+dfsg-5+b1
ii  ocl-icd-libopencl1 [libopencl1]  2.2.12-4
ii  zlib1g   1:1.2.11.dfsg-2

Versions of packages libwine-development recommends:
ii  fonts-liberation   1:1.07.4-11
ii  fonts-wine 5.0-4
ii  gstreamer1.0-plugins-good  1.16.2-3
ii  libasound2-plugins 1.2.2-1
ii  libgl1-mesa-dri20.1.1-1

Versions of packages libwine-development suggests:
pn  cups-bsd   
ii  gstreamer1.0-libav 1.16.2-2
pn  gstreamer1.0-plugins-bad   
ii  gstreamer1.0-plugins-ugly  1.16.2-2+b1
ii  ttf-mscorefonts-installer  3.8

Versions of packages wine32-development depends on:
ii  libc62.30-8
ii  libwine-development  5.5-4

wine32-development recommends no packages.

Versions of packages wine32-development suggests:
pn  wine32-development-preloader  

Versions of packages wine64-development depends on:
ii  libc62.30-8
ii  libwine-development  5.5-4

Versions of packages wine64-development recommends:
ii  wine32-development  5.5-4

Versions of packages wine64-development suggests:
pn  wine64-development-preloader  

Versions of packages wine-development is related to:
pn  dxvk 
pn  dxvk-wine32-development  
pn  dxvk-wine64-development  
ii  fonts-wine   5.0-4

-- no debconf information



Bug#963093: samtools: recommended dependencies are unnecessary

2020-06-18 Thread Alan Hoyle
Package: samtools
Version: 1.10-4
Severity: minor

Dear Maintainer,


Samtools includes recommended installation of python and cwltool.

python is completely unnecessary now.

cwltool should be a "suggests" at most for samtools, though I would make 
samtools a "recommends" for cwltool, as many workflows that use cwltool
do use samtools.  

I discovered this because I was creating Docker images for processing 
sequencing data and I noticed that python and cwltool were being
installed unless I included --no-install-recommends on the apt-get
command line.  

The disadvantage to leaving this is that some Debian images will be
larger even when they don't need cwltool or python.  

I have been emailing with Andreas Tille outside of this bug report and I
think he has addressed this issue in the following two git commits:

https://salsa.debian.org/med-team/samtools/-/commit/e8c62ffa10f390937a225fb4188fa9c31510379a

https://salsa.debian.org/med-team/samtools/-/commit/81ac71e9ddacb88279c35a913c81ba8f5118720a

Thanks,

Alan

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

Kernel: Linux 4.19.76-linuxkit (SMP w/8 CPU cores)
Kernel taint flags: TAINT_RANDSTRUCT
Locale: LANG=C, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE=C (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: unable to detect

Versions of packages samtools depends on:
ii  libc62.28-10
ii  libhts2  1.9-11
ii  libncurses6  6.1+20181013-2+deb10u2
ii  libtinfo66.1+20181013-2+deb10u2
ii  zlib1g   1:1.2.11.dfsg-1

Versions of packages samtools recommends:
pn  cwltool  
pn  python   

samtools suggests no packages.

-- no debconf information



Bug#963092: ITP: healpix-fortran -- HEALPix representation of spherical data - Fortran library

2020-06-18 Thread Leo Singer
Package: wnpp
Severity: wishlist
Owner: Leo Singer 

* Package name: healpix-fortran
  Version : 3.60
  Upstream Author : Martin Reinecke 
* URL : http://healpix.sourceforge.net
* License : GPL
  Programming Lang: Fortran
  Description : HEALPix representation of spherical data - Fortran library

HEALPix is an acronym for Hierarchical Equal Area isoLatitude Pixelization
of a sphere. As suggested in the name, this pixelization produces a
subdivision of a spherical surface in which each pixel covers the same
surface area as every other pixel. It is commonly used to store all-sky
astronomical images, most famously maps of the cosmic microwave background.
This package provides the Fortran language implementation of HEALPix.

This package has been requested by a fellow Debian member, Ole Streicher,
to support the 4MOST instrumment
(https://www.eso.org/sci/facilities/develop/instruments/4MOST.html).

The package will be maintained by the Debian Astro Team.



Bug#928516: Bug #928516/945932 logrotate: Upgrading from stretch breaks logrotate if logrotate.conf was modified

2020-06-18 Thread Christian Göttsche
Control: notforwarded 928516
Control: severity 928516 important
Control: merge 928516 945932

A section to the Debian release notes was added [1].

Leaving the bug open so users might be better able to find it.


[1]: 
https://www.debian.org/releases/stable/amd64/release-notes/ch-information.de.html#logrotate



Bug#961481: ceph: Protocol incompatibility between armhf and amd64

2020-06-18 Thread Bernd Zeimetz
Hi Ard,

On 6/18/20 1:28 PM, Ard van Breemen wrote:
>> The biggest issue in maintaining ceph is to make it build on 32 bit
>> architectures. This seems not to be supported at all by upstream anymore.
> 
> First of all, I don't know what your goal is to support 32 bit.

Debian supports it, so it should be supported if possible.

> I do have a goal: I have loads of armhf machines and only so many amd64
> machines that do not even have enough memory to properly support ceph
> and being able to do something (as the MON uses 1GB of memory alone).
> I have multiple sites with this situation, and for the foreseeable
> future, we will still be building infrastructure on armhf. Getting a
> decent AMD64 setup in any location is additional and probably
> unnecessary costs.

You'll either need to migrate to amd64 (or arm/whatever64) or pay
somebody to fix ceph at upstream.


> I think the stance of the ceph community in this is: as long as nobody
> sends in patches they are not going to care. And they can't support it
> themselves because they have a totally different target (clouds).

Its the same: they support what they get paid for or what is needed.
People rarely use 32bit these days. Even on cheap arm devices 64bit is
the way to go.



> I am willing to host the armhf releases and maybe the i386 releases on
> my server, that way there will be 32 bit releases but not official ones.

Doesn't matter, hosting is not the issue here.

> But I do want your involvement.

You can want that, but you won't get it.
Send patches or people who will do the work.
I'll happily accept patches, or even better, but reports with links to
patches at upstream.


> I've been trying to compile it for a time, using sources from ceph and
> from proxmox, until I realised ceph nautilus is in backports. And it
> worked.
> So at least I want your guidance on how you build these... For now I've
> used an armhf machine, and I needed to limit the number of threads to 1
> due to c++ compiler needing more than 1GB of RAM to compile a single
> source.

Upstream has a detailed readme, or you can use the basic way to build a
debian package using dpkg-buildpackage, or similar tools.

> Not only do I want to make support complete so I can use hardware, I
> also think it's just bad programming not to use explicit sizes. And I am
> also on the verge of investing in amd64 clusters, I don't want it to
> depend on code that's depending on a lot of features.
> Anyway: I don't know how you build and test on non amd64 systems, do you
> also use armhf, or do you use a cross compile environment?

You can just build it, if you are using the Debian source.
Otherwise you'll need a lot of patches to make it build, and even more
to fix those various 32bit related bugs.



Bernd

-- 
 Bernd ZeimetzDebian GNU/Linux Developer
 http://bzed.dehttp://www.debian.org
 GPG Fingerprint: ECA1 E3F2 8E11 2432 D485  DD95 EB36 171A 6FF9 435F



Bug#963091: ITP: idevicerestore -- command-line application to restore firmware files to iOS devices

2020-06-18 Thread Yves-Alexis Perez
Package: wnpp
Severity: wishlist
Owner: pkg-gtkpod-de...@alioth-lists.debian.net

* Package name: idevicerestore
  Version : 1.0.0
  Upstream Author : libimobiledevice project
* URL : http://www.libimobiledevice.org/
* License : LGPL
  Programming Lang: C
  Description : command-line application to restore firmware files to iOS 
devices

 The idevicerestore application is a full reimplementation of all granular
 steps which are performed during the restore of a firmware to a device.
 .
 In general, upgrades and downgrades are possible, however subject to
 availability of SHSH blobs from Apple for signing the firmare files.
 .
 Some key features are:
  - Restore: Update firmware on iOS devices
  - Firmware: Use official IPSW firmware archive file or a directory as source
  - Update: Allows updating the device by default or erasing all data
  - Download: On demand download of latest available firmware for a device
  - Cache: Downloaded firmware files are cached locally
  - Custom Firmware: Restore custom firmware files (requires bootrom exploit)
  - Baseband: Allows one to skip NOR/Baseband upgrade
  - SHSH: Fetch TSS records and save them as ".shsh" files
  - DFU: Put devices in pwned DFU mode (limera1n devices only)
  - AP Ticket: Use custom AP ticket from a file



Bug#963089: mig - Set priority to optional

2020-06-18 Thread Samuel Thibault
Bastian Blank, le jeu. 18 juin 2020 21:19:01 +0200, a ecrit:
> So installing [mig] by default, by virtue of being defined with
> priority "standard", is not appropriate.

Oh! I don't it was ever intended.  I'm actually surprised the
discrepancy on the mig package was never noticed.

> I've overriden the priority already to "optional".  Please fix the
> package itself.

Yep, sure! Done so in the repo for next upload.

Samuel



Bug#963082: libvorbis: Autopkgtests depend on pysycache-i18n which was removed from testing and unstable

2020-06-18 Thread Olivier Tilloy
Submitted a fix to the VCS:
https://salsa.debian.org/multimedia-team/libvorbis/-/merge_requests/1.


Bug#963090: mig - Undistributable (GPL + advertisement clause)

2020-06-18 Thread Bastian Blank
Package: mig
Version: 1.8-7
Severity: serious

mig mixes two incompatible licenses: GPL and a BSD derivative including
an advertisement clause (included in cpu.sym and message.h):

|and (3) all advertising
| materials mentioning features or use of this software display the following
| acknowledgement: ``This product includes software developed by the
| Computer Systems Laboratory at the University of Utah.''

See https://www.gnu.org/licenses/license-list.html#OriginalBSD

Bastian

-- 
One does not thank logic.
-- Sarek, "Journey to Babel", stardate 3842.4



Bug#963089: mig - Set priority to optional

2020-06-18 Thread Bastian Blank
Package: mig
Version: 1.8-7
Severity: important

mig is a development package.  So installing it by default, by virtue of
being defined with priority "standard", is not appropriate.  I've
overriden the priority already to "optional".  Please fix the package
itself.

Bastian

-- 
Not one hundred percent efficient, of course ... but nothing ever is.
-- Kirk, "Metamorphosis", stardate 3219.8



Bug#959773: logrotate: Standard logrotate from buster repository ignores compressing configuration options in configfile

2020-06-18 Thread Christian Göttsche
Control: forwarded -1 https://github.com/logrotate/logrotate/issues/321
Control: tags -1 wontfix
Control: retitle -1 logrotate: global options do not affect preceding
include directives

Marking as wontfix as the fact that global options do not affect
preceding include directives is intended.
The documentation got improved via
https://github.com/logrotate/logrotate/pull/325



Bug#953727: fixed in xdebug 2.9.6+2.8.1+2.5.5-1

2020-06-18 Thread Paul Gevers
Hi Ondřej,

On 18/06/2020 10.55, Ondřej Surý wrote:
> The best way is to Break the 'php-common‘ package because everything
> sort of depends on that.

You forgot that php-common has an epoch (as can be seen one line above
the line you changed for this breaks)

Paul



signature.asc
Description: OpenPGP digital signature


Bug#963088: bppsuite: autopkgtest failure on arm64: precision issue in reference data

2020-06-18 Thread Paul Gevers
Source: bppsuite
Version: 2.4.1-2
X-Debbugs-CC: debian...@lists.debian.org
Severity: serious
User: debian...@lists.debian.org
Usertags: fails-always

Dear maintainer(s),

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

I copied some of the output at the bottom of this report. It seems to
show a calculation precision issue in your reference data, but maybe the
answer is really good and it's showing an issue with your package on
arm64. (0.00762627 vs 0.00762628)

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

Paul

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

https://ci.debian.net/data/autopkgtest/testing/amd64/b/bppsuite/5887912/log.gz

<
(6.langur_Sen&Sve:0.00790177,7.langur_Tob&Tfr:1e-06,8.Douc_langur_Pne:0.0233448):0.00758139,9.probiscis_Nla:0.00784523):0.0258479,5.colobus_Cgu&Can:0.036229):0.077728,(((10.baboon_Pcy:0.0080218,11.mangabey_Cat:1e-06):1e-06,12.rhesus_Mmu:0.00761117):1e-06,13.Allen_Ani:0.015264,(14.talapoin_Mta:0.0156828,(15.patas_Epa:0.0160261,16.vervet_Cae:0.00794742):0.00762627):0.0076675):0.0173244):0.0393703,(((1.human:0.0161234,2.chimp_bonobo_gorilla:1e-06):0.00762358,3.orangutan_Ppy:1e-06):0.00723969,4.gibbon_Ggo:0.0319335):0.070116,(17.squirrel_m:0.0258088,(18.tamarin_Soe:0.0317538,19.Marmoset_Cja:0.0413489):1e-06):0.123173);
---
>
(6.langur_Sen&Sve:0.00790177,7.langur_Tob&Tfr:1e-06,8.Douc_langur_Pne:0.0233448):0.00758139,9.probiscis_Nla:0.00784523):0.0258479,5.colobus_Cgu&Can:0.036229):0.077728,(((10.baboon_Pcy:0.0080218,11.mangabey_Cat:1e-06):1e-06,12.rhesus_Mmu:0.00761117):1e-06,13.Allen_Ani:0.015264,(14.talapoin_Mta:0.0156828,(15.patas_Epa:0.0160261,16.vervet_Cae:0.00794742):0.00762628):0.0076675):0.0173244):0.0393703,(((1.human:0.0161234,2.chimp_bonobo_gorilla:1e-06):0.00762358,3.orangutan_Ppy:1e-06):0.00723969,4.gibbon_Ggo:0.0319335):0.070116,(17.squirrel_m:0.0258088,(18.tamarin_Soe:0.0317538,19.Marmoset_Cja:0.0413489):1e-06):0.123173);




signature.asc
Description: OpenPGP digital signature


Bug#963087: dpkg -V python3-minimal does not report correct status

2020-06-18 Thread Devarajulu, Mohanasundaram
Package: dpkg
Version: 1.19.7
Severity: normal

Dear Maintainer,

The following command shows
dpkg -L python3-minimal
/usr/bin/python3m
as one of the files that belong to the package.
sudo rm -f /usr/bin/python3m
removes the file and I expect dpkg -V python3-minimal to report it, but it does 
not
dpkg -V python3-minimal
returns with no output and echo $? shows successful completion.
If dpkg -L shows a file, dpkg -V needs to follow it, even if it is a symlink
For that matter even if the target is removed it does not complain. However
sudo rm -f /usr/share/doc/python3-minimal/README.Debian
evokes a response from dpkg -V python3-minimal
??5??   /usr/share/doc/python3-minimal/README.Debian

-- Package-specific info:

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

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

Versions of packages dpkg depends on:
ii  libbz2-1.0   1.0.6-9.2~deb10u1
ii  libc62.28-10
ii  liblzma5 5.2.4-1
ii  libselinux1  2.8-1+b1
ii  tar  1.30+dfsg-6
ii  zlib1g   1:1.2.11.dfsg-1

dpkg recommends no packages.

Versions of packages dpkg suggests:
ii  apt1.8.2.1
pn  debsig-verify  

-- no debconf information



Bug#963045: gnome-control-center: Unable to install due to wrong dependency(ies)

2020-06-18 Thread Philippe Chauvat
So yes, it was just as you wrote... Sorry for raising this and again,
thanks a lot for your help.

Best

Philippe

Le 18/06/2020 à 16:06, Simon McVittie a écrit :
> On Thu, 18 Jun 2020 at 12:17:19 +0200, Philippe Chauvat wrote:
>>gstreamer1.0-plugins-bad is trying to be installed but in conflict with 
>> other packages...
> ...
>> Préparation du dépaquetage de 
>> .../gstreamer1.0-plugins-bad_1%3a1.14.4-dmo7_amd64.deb ...
> This version is from deb-multimedia.org (notice the -dmo). That's
> a third-party package repository which is known to contain various
> packages that are incompatible with what's in Debian, particularly
> testing/unstable. Please don't use it, and replace packages that came
> from dmo with the equivalents from "real Debian".
>
> In particular, dmo puts epochs on the version numbers of its packages,
> which cause those packages to be compared incorrectly with packages in
> Debian - for example this is gstreamer1.0-plugins-bad version 1.14.4,
> but because of the 1: epoch, dpkg will think that it is newer than the
> version 1.16.x in Debian testing/unstable. This is not true and can
> break applications.
>
> smcv



Bug#963045: gnome-control-center: Unable to install due to wrong dependency(ies)

2020-06-18 Thread Philippe Chauvat
Hi Simon,

Thanks a lot for pointing this out... I'll check and let you know. I
really appreciate the quick reply.

Best

Philippe

Le 18/06/2020 à 16:06, Simon McVittie a écrit :
> On Thu, 18 Jun 2020 at 12:17:19 +0200, Philippe Chauvat wrote:
>>gstreamer1.0-plugins-bad is trying to be installed but in conflict with 
>> other packages...
> ...
>> Préparation du dépaquetage de 
>> .../gstreamer1.0-plugins-bad_1%3a1.14.4-dmo7_amd64.deb ...
> This version is from deb-multimedia.org (notice the -dmo). That's
> a third-party package repository which is known to contain various
> packages that are incompatible with what's in Debian, particularly
> testing/unstable. Please don't use it, and replace packages that came
> from dmo with the equivalents from "real Debian".
>
> In particular, dmo puts epochs on the version numbers of its packages,
> which cause those packages to be compared incorrectly with packages in
> Debian - for example this is gstreamer1.0-plugins-bad version 1.14.4,
> but because of the 1: epoch, dpkg will think that it is newer than the
> version 1.16.x in Debian testing/unstable. This is not true and can
> break applications.
>
> smcv



Bug#963073: reportbug: please update documentation on how to use reportbug.debian.org

2020-06-18 Thread David Bremner
Sandro Tosi  writes:

>
> in ~/.reportbugrc, you just need
>
> smtphost reportbug.debian.org
>
> and that's it (you can also re-run the reportbug configuration menu
> and dont enter any smtphost, and r.d.o will be selected automatically,
> just follow the instructions)
>
> can you provide an example of how you'd like to have
> the documentation updated?

Well, for example, if the use also specifies --email on the command
line, then it fails, because it tries to authenticate that user to the
smtp host. So maybe that's the real bug?

d



Bug#954189: Backport to buster?

2020-06-18 Thread Ralph Giles
Please backport the 0.2.1 package from bullseye to buster. The 0.0.62
package currently in buster no longer works for new installs, and will
stop working for renewals of current domain certificates in July 2020.

The 0.2.1 tag of acmetool is two years old and should build with the
golang 1.11 package in Buster.

The systemd unit file int he 0.0.62 package has also been broken by the
/var/run -> /run tempfiles changes.

Anyone who wants to continue using acmetool has to manually install the
package from unstable, so the distro might as well do it for us.

Thanks for packaging acmetool!

 -r



Bug#963055: Mark one more symbol as optional when building with -march=z13 on s390x

2020-06-18 Thread Olek Wojnar
Hi Matthias,

Thanks for the bug report!

On Thu, Jun 18, 2020, 08:21 Matthias Klose  wrote:

>
> Mark one more symbol as optional when building with -march=z13 on s390x
>

Per a discussion regarding CEGUI, I'm actually eliminating symbols files
from my C++ libraries, at least in the near term. I may re-add them later
once I have time to implement some of the recommended techniques to make
symbol maintenance less painful.

I'll upload an updated package shortly.

-Olek

>


Bug#963086: pcre3: CVE-2020-14155

2020-06-18 Thread Salvatore Bonaccorso
Source: pcre3
Version: 2:8.39-12
Severity: important
Tags: security upstream
Forwarded: https://bugs.exim.org/show_bug.cgi?id=2463
Control: found -1 2:8.39-3 

Hi,

The following vulnerability was published for pcre3.

CVE-2020-14155[0]:
| libpcre in PCRE before 8.44 allows an integer overflow via a large
| number after a (?C substring.


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-14155
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-14155
[1] https://bugs.exim.org/show_bug.cgi?id=2463

Regards,
Salvatore



Bug#963084: cython: New version available (0.29.20)

2020-06-18 Thread Stephen Quinney
Source: cython
Version: 0.29.14
Severity: wishlist

Hi there,

The current version of Cython in unstable is 0.29.14 which was released in
November 2019. There have been 6 releases since then with the latest - 0.29.20
- just over a week ago. Is there any chance of getting the Debian package
upgraded to the latest version please?

Regards,

Stephen Quinney





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

Kernel: Linux 4.19.0-8-amd64 (SMP w/4 CPU cores)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, 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 /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

-- 
The University of Edinburgh is a charitable body, registered in
Scotland, with registration number SC005336.



Bug#963083: equivs-build ignores package Version "0"

2020-06-18 Thread Denis Thulin
Package: equivs
Version: 2.2.0
Severity: normal
Tags: patch upstream


Dear Maintainer,

While using mk-build-deps, I've encountered a small inconsistency
between with equivs-build that results in an annoying bug:

When passing the `Version` field to equivs-build with value `0`,
equivs-build ignores that value and decides that the version should be
`1.0`.

mk-build-deps then fails because the generated package version is not
the one it expected.

The reason for that is the following line in equivs-build:
$version = $control->{'Version'} || "1.0";

https://salsa.debian.org/perl-team/modules/packages/equivs/-/blob/master/usr/bin/equivs-build#L341

This line is supposed to guard againts undefined version but has the
side effect of rejecting version 0.

Cheers,

- Denis


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

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

Versions of packages equivs depends on:
ii  debhelper  12.1.1
ii  dpkg-dev   1.19.7
ii  fakeroot   1.23-1
ii  make   4.2.1-1.2
ii  perl   5.28.1-6

equivs recommends no packages.

equivs suggests no packages.

-- no debconf information
--- a/usr/bin/equivs-build  2020-06-18 16:36:22.365024021 +
+++ b/usr/bin/equivs-build  2020-06-18 16:37:34.112880449 +
@@ -336,7 +336,10 @@
   my ($builddir, $control) = @_;
   my ($version, $suite, $date);
 
-  $version = $control->{'Version'} || "1.0";
+  my $version = '1.0';
+  if (defined $control->{'Version'}) {
+  $version = $control->{'Version'};
+  }
   $suite = $control->{'Suite'} || "unstable";
   chomp ($date = qx(date -R));
 


Bug#963081: src:camera.app: Please switch to using pkg-config for libgphoto2

2020-06-18 Thread Ferenc Wágner
Package: src:camera.app
Version: 0.8.0-12
Severity: normal

Dear Maintainer,

I plan to upload libgphoto2 2.5.25 without the config scripts,
which upstream considers obsolete and hurt the multi-arch effort.
It's easy to switch to using pkg-config instead, see the attached
debdiff.  Please consider applying something along these lines so
that the incoming libgphoto2 upload does not make camera.app FTBFS.
Or I can do this NMU or send a Salsa MR if you prefer, just holler.

Thanks,
Feri.

$ debdiff camera.app_0.8.0-12.dsc camera.app_0.8.0-12.1.dsc
gpgv: Signature made Thu 07 Nov 2019 04:57:15 PM CET
gpgv:using RSA key 9236557B170C87F8821C0AC3C1E0D92E986F7C7E
gpgv: Can't check signature: No public key
dpkg-source: warning: failed to verify signature on 
/home/wferi/phototools/libgphoto2/rdeps/camera.app_0.8.0-12.dsc
dpkg-source: warning: extracting unsigned source package 
(/home/wferi/phototools/libgphoto2/rdeps/camera.app_0.8.0-12.1.dsc)
diff -Nru camera.app-0.8.0/debian/changelog camera.app-0.8.0/debian/changelog
--- camera.app-0.8.0/debian/changelog   2019-11-01 13:36:00.0 +0100
+++ camera.app-0.8.0/debian/changelog   2020-06-18 18:16:16.0 +0200
@@ -1,3 +1,10 @@
+camera.app (0.8.0-12.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * libgphoto_2.5.25-1 dropped the config scripts, switch to pkg-config.
+
+ -- Ferenc Wágner   Thu, 18 Jun 2020 18:16:16 +0200
+
 camera.app (0.8.0-12) unstable; urgency=medium
 
   * Fix Vcs fields.
diff -Nru camera.app-0.8.0/debian/control camera.app-0.8.0/debian/control
--- camera.app-0.8.0/debian/control 2019-11-01 13:36:00.0 +0100
+++ camera.app-0.8.0/debian/control 2020-06-18 18:16:10.0 +0200
@@ -7,7 +7,8 @@
 Build-Depends: debhelper (>= 11),
   gnustep-make (>= 2.6.6),
   libgnustep-gui-dev (>= 0.24.0),
-  libgphoto2-dev (>= 2.5.10)
+  libgphoto2-dev (>= 2.5.10),
+  pkg-config,
 Standards-Version: 4.4.1
 Vcs-Git: https://salsa.debian.org/gnustep-team/camera.app.git
 Vcs-Browser: https://salsa.debian.org/gnustep-team/camera.app
diff -Nru camera.app-0.8.0/debian/patches/series 
camera.app-0.8.0/debian/patches/series
--- camera.app-0.8.0/debian/patches/series  1970-01-01 01:00:00.0 
+0100
+++ camera.app-0.8.0/debian/patches/series  2020-06-18 18:16:16.0 
+0200
@@ -0,0 +1 @@
+Use-pkg-config-for-libgphoto2.patch
diff -Nru camera.app-0.8.0/debian/patches/Use-pkg-config-for-libgphoto2.patch 
camera.app-0.8.0/debian/patches/Use-pkg-config-for-libgphoto2.patch
--- camera.app-0.8.0/debian/patches/Use-pkg-config-for-libgphoto2.patch 
1970-01-01 01:00:00.0 +0100
+++ camera.app-0.8.0/debian/patches/Use-pkg-config-for-libgphoto2.patch 
2020-06-18 18:16:16.0 +0200
@@ -0,0 +1,9 @@
+--- a/GNUmakefile.preamble
 b/GNUmakefile.preamble
+@@ -1,3 +1,3 @@
+-ADDITIONAL_INCLUDE_DIRS += `gphoto2-config --cflags`
++ADDITIONAL_INCLUDE_DIRS += `pkg-config libgphoto2 --cflags`
+ ADDITIONAL_OBJCFLAGS += -g -Wall
+-ADDITIONAL_GUI_LIBS += `gphoto2-config --libs`
+\ No newline at end of file
++ADDITIONAL_GUI_LIBS += `pkg-config libgphoto2 --libs`
diff -Nru camera.app-0.8.0/debian/rules camera.app-0.8.0/debian/rules
--- camera.app-0.8.0/debian/rules   2018-02-07 13:12:59.0 +0100
+++ camera.app-0.8.0/debian/rules   2020-06-18 18:16:16.0 +0200
@@ -15,11 +15,6 @@
 # import GNUstep settings for Debian
 include /usr/share/GNUstep/debian/config.mk
 
-# override GNUmakefile.preamble
-DEB_HOST_MULTIARCH ?= $(shell dpkg-architecture -qDEB_HOST_MULTIARCH)
-export ADDITIONAL_INCLUDE_DIRS += 
`/usr/lib/$(DEB_HOST_MULTIARCH)/libgphoto2-dev/bin/gphoto2-config --cflags`
-export ADDITIONAL_GUI_LIBS += 
`/usr/lib/$(DEB_HOST_MULTIARCH)/libgphoto2-dev/bin/gphoto2-config --libs`
-
 %:
dh $@
 


Bug#963082: libvorbis: Autopkgtests depend on pysycache-i18n which was removed from testing and unstable

2020-06-18 Thread Olivier Tilloy
Source: libvorbis
Version: 1.3.6-2
Severity: normal

Dear Maintainer,

libvorbis's autopkgtests depend on pysycache-i18n, which was recently removed 
from testing and unstable because it's python2 only.

The fix is trivial, as the dependency exists only to copy a random, small Ogg 
Vorbis file. This can be replaced by any such file from another package, for 
example sound-theme-freedesktop.



Bug#963080: chromium dies in libva

2020-06-18 Thread Harald Dunkel

Package: chromium
Version: 81.0.4044.92-1

Visiting youtube to watch a video chromium dies:

{harri@cecil:harri (master) 501} chromium
[65350:65350:0618/183220.289924:ERROR:browser_switcher_service.cc(238)] XXX 
Init()
[65386:65386:0618/183220.293842:ERROR:vaapi_wrapper.cc(482)] vaInitialize 
failed: unknown libva error
Received signal 11 SEGV_MAPERR 000c
#0 0x559b56c755a9 (/usr/lib/chromium/chromium+0x52485a8)
#1 0x559b56bdaac3 (/usr/lib/chromium/chromium+0x51adac2)
#2 0x559b56c75131 (/usr/lib/chromium/chromium+0x5248130)
#3 0x7f00c7bd3110 (/lib/x86_64-linux-gnu/libpthread-2.30.so+0x1410f)
#4 0x559b54af1e21 (/usr/lib/chromium/chromium+0x30c4e20)
#5 0x559b54ae39a8 (/usr/lib/chromium/chromium+0x30b69a7)
#6 0x559b54ae3730 (/usr/lib/chromium/chromium+0x30b672f)
#7 0x559b54ab7491 (/usr/lib/chromium/chromium+0x308a490)
#8 0x559b54aad8a9 (/usr/lib/chromium/chromium+0x30808a8)
#9 0x559b54aad501 (/usr/lib/chromium/chromium+0x3080500)
#10 0x559b54ab3daf (/usr/lib/chromium/chromium+0x3086dae)
#11 0x559b54ab3c37 (/usr/lib/chromium/chromium+0x3086c36)
#12 0x559b54af6abc (/usr/lib/chromium/chromium+0x30c9abb)
#13 0x559b54af8ff2 (/usr/lib/chromium/chromium+0x30cbff1)
#14 0x559b54a28feb (/usr/lib/chromium/chromium+0x2ffbfea)
#15 0x559b54a295fe (/usr/lib/chromium/chromium+0x2ffc5fd)
#16 0x559b54a0e477 (/usr/lib/chromium/chromium+0x2fe1476)
#17 0x559b56c25442 (/usr/lib/chromium/chromium+0x51f8441)
#18 0x559b56c35139 (/usr/lib/chromium/chromium+0x5208138)
#19 0x559b56c34ed5 (/usr/lib/chromium/chromium+0x5207ed4)
#20 0x559b56bf0daa (/usr/lib/chromium/chromium+0x51c3da9)
#21 0x559b56c359e9 (/usr/lib/chromium/chromium+0x52089e8)
#22 0x559b56c0dc84 (/usr/lib/chromium/chromium+0x51e0c83)
#23 0x559b56c49aa9 (/usr/lib/chromium/chromium+0x521caa8)
#24 0x559b56c8546e (/usr/lib/chromium/chromium+0x525846d)
#25 0x7f00c7bc7f27 start_thread
#26 0x7f00c2c4d31f clone
  r8:   r9: 00ca r10:  r11: 
0246
 r12: 7f0079bf84c8 r13: 7f0060007d80 r14:  r15: 
7f0060007a90
  di: 7f0060007a90  si:   bp: 7f0079bf82a0  bx: 

  dx: 7fff  ax:   cx:   sp: 
7f0079bf8280
  ip: 559b54af1e21 efl: 00010246 cgf: 002b0033 erf: 
0006
 trp: 000e msk:  cr2: 000c
[end of stack trace]
Calling _exit(1). Core file will not be generated.
[65386:65386:0618/183237.177627:ERROR:shared_image_manager.cc(212)] 
SharedImageManager::ProduceSkia: Trying to Produce a Skia representation from a 
non-existent mailbox.

libva-x11-2 is version 2.7.1-1. nvidia-graphics-drivers is version 440.82-2.
I cannot reproduce this using google-chrome 83.0.4103.106-1.


Regards
Harri



Bug#586413: ITA: tightvnc -- virtual network computing server software

2020-06-18 Thread Sven Geuer
Hi Mike,

>As I see it, the package has never been maintained in Git. It would
> be  
> cool to have its complete history (Debian package imports via gbp  
> import-dsc) added to that new Git repo.
>

Already done via 'gbp import-dscs --debsnap ...' to my personal project
[1]. It shall show up in the tightvnc teams repo soon.

Cheers,
Sven

[1] https://salsa.debian.org/sven-geuer-guest/tightvnc


 

Am Donnerstag, den 18.06.2020, 07:54 + schrieb Mike Gabriel:
> Hi Sven,
> 
> On  Mi 17 Jun 2020 20:34:39 CEST, Sven Geuer wrote:
> 
> > Owner: debma...@g-e-u-e-r.de
> > 
> > Hi Ola,
> > 
> > thank you for your consent. I take ownership of this bug now. It
> > will
> > be closed with the upcoming upload of tightvnc.
> > 
> > Thanks for having maintained tightvnc for all these years.
> > 
> > If there's anything in contrast to what you intended, please let me
> > know. We'll get it sorted out.
> > 
> > Sven
> 
> I have created a tightvnc repo for you.
> https://salsa.debian.org/debian-remote-team/tightvnc/
> 
> 
> As I see it, the package has never been maintained in Git. It would
> be  
> cool to have its complete history (Debian package imports via gbp  
> import-dsc) added to that new Git repo.
> 
> Sven, do you know you to do such an import (including all recent  
> Debian release branches)?
> 
> If not, I am happy to help you with that.
> 
> @Ola: or do you have some packaging Git around locally that you
> used  
> in the past?
> 
> Mike


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


Bug#963079: debootstrap: --unpack-tarball without matching url from --make-tarball cause errors

2020-06-18 Thread Marco
Package: debootstrap
Version: 1.0.123
Severity: normal

Creating a tarball via --make-tarball and then unpacking causes an error when
the same url isn't specified during unpack.


Problem:

  : debootstrap --arch amd64 --make-tarball=/tmp/debootstrap_pkgs.tar buster 
/tmp/junk http://ftp.us.debian.org/debian
  I: Retrieving InRelease
  I: Checking Release signature
  I: Valid Release signature (key id 6D33866EDD8FFA41C0143AEDDCC9EFBF77E11517)
  I: Retrieving Packages
  I: Validating Packages
  I: Resolving dependencies of required packages...
  I: Resolving dependencies of base packages...
  I: Checking component main on http://ftp.us.debian.org/debian...
  I: Retrieving libacl1 2.2.53-4
  I: Validating libacl1 2.2.53-4
  I: Retrieving adduser 3.118

  ...

  I: Retrieving zlib1g 1:1.2.11.dfsg-1
  I: Validating zlib1g 1:1.2.11.dfsg-1
  I: Deleting target directory

  # So far so good

  : sudo debootstrap --arch amd64 --unpack-tarball=/tmp/debootstrap_pkgs.tar 
buster /tmp/foo
  I: Target architecture can be executed
  I: Chosen extractor for .deb packages: dpkg-deb
  I: Extracting libacl1...
  I: Extracting adduser...

  ...

  I: Configuring sysvinit-utils...
  I: Configuring libc-bin...
  I: Unpacking the base system...

  # Failed

  : echo $?
  2

A little digging reveals:

  /tmp/usr/share/debootstrap//functions: line 1498: 
/tmp/mnt1/foo/var/lib/apt/lists/deb.debian.org_debian_dists_buster_main_binary-amd64_Packages:
 No such file or directory


Expectations:

  I would expect that the url would not be needed for unpacking.  Even if this
  behavior is somehow desired, it would be nice to have a more meaningful error
  message so the user would have an indication of what they did wrong.

Workaround:

  Specifying the url while unpacking makes this work.
  : sudo debootstrap --arch amd64 --unpack-tarball=/tmp/debootstrap_pkgs.tar 
buster /tmp/foo http://ftp.us.debian.org/debian

  Needing a url for an operation that should be offline seems strange.



Thank you!

Marco Fonseca



Bug#963078: ITP: paryfor: Parallel_for implementation based on atomic queues

2020-06-18 Thread Nilesh Patra
Package: wnpp
Severity: wishlist
Owner: Nilesh Patra 
X-Debbugs-CC: debian-de...@lists.debian.org


* Package name: paryfor
  Version : 0.1
  Upstream Author : Erik Garrison
* URL : https://github.com/ekg/paryfor

* License : Expat
  Programming Lang: C++
  Description : Parallel_for implementation based on atomic queues

 The parallel_for templates replace #pragma omp parallel for.
 This uses a callback that takes the iteration number.

NB: Dependency of mmmulti
I take the responsibility to maintain this package.


Bug#963077: btrfs-progs: btrfs-convert manpage present but binary missing

2020-06-18 Thread Christopher David Howie
Package: btrfs-progs
Version: 4.20.1-2

See #870286 for context.

It was reported that the btrfs-convert manpage is present in the stable
release of btrfs-progs, but the binary was removed because of serious
bugs.  The manpage should not be present in this package.

Apparently this bug report was closed when the btrfs-convert binary was
added back to the package in 5.1-1, but 4.20.1-2 (the current stable
version) still ships with a manpage for a command that isn't present.

Please remove the btrfs-convert manpage from the stable version of
btrfs-progs.  Its presence is confusing when its matching command is not
supplied.

-- 
Chris Howie
http://www.chrishowie.com
http://en.wikipedia.org/wiki/User:Crazycomputers

If you correspond with me on a regular basis, please read this document:
http://www.chrishowie.com/email-preferences/

PGP fingerprint: 2B7A B280 8B12 21CC 260A DF65 6FCE 505A CF83 38F5


IMPORTANT INFORMATION/DISCLAIMER

This document should be read only by those persons to whom it is
addressed.  If you have received this message it was obviously addressed
to you and therefore you can read it.

Additionally, by sending an email to ANY of my addresses or to ANY
mailing lists to which I am subscribed, whether intentionally or
accidentally, you are agreeing that I am "the intended recipient," and
that I may do whatever I wish with the contents of any message received
from you, unless a pre-existing agreement prohibits me from so doing.

This overrides any disclaimer or statement of confidentiality that may
be included on your message.



Bug#962230: sword: diff for NMU version 1.8.1+dfsg-8.2

2020-06-18 Thread Adrian Bunk
Control: tags 962230 + patch
Control: tags 962230 + pending

Dear maintainer,

I've prepared an NMU for sword (versioned as 1.8.1+dfsg-8.2) and 
uploaded it to DELAYED/2. Please feel free to tell me if I should
cancel it.

cu
Adrian
diff -Nru sword-1.8.1+dfsg/debian/changelog sword-1.8.1+dfsg/debian/changelog
--- sword-1.8.1+dfsg/debian/changelog	2020-06-09 03:39:54.0 +0300
+++ sword-1.8.1+dfsg/debian/changelog	2020-06-18 19:00:26.0 +0300
@@ -1,3 +1,10 @@
+sword (1.8.1+dfsg-8.2) unstable; urgency=high
+
+  * Non-maintainer upload.
+  * Add workaround for building on mips64el. (Closes: #962230)
+
+ -- Adrian Bunk   Thu, 18 Jun 2020 19:00:26 +0300
+
 sword (1.8.1+dfsg-8.1) unstable; urgency=medium
 
   * Non-maintainer upload.
diff -Nru sword-1.8.1+dfsg/debian/patches/0006-powerpc64.patch sword-1.8.1+dfsg/debian/patches/0006-powerpc64.patch
--- sword-1.8.1+dfsg/debian/patches/0006-powerpc64.patch	2018-11-12 18:05:48.0 +0200
+++ sword-1.8.1+dfsg/debian/patches/0006-powerpc64.patch	2020-06-18 19:00:19.0 +0300
@@ -1,6 +1,6 @@
 From: Daniel Glassey 
 Date: Sat, 3 Nov 2018 13:34:07 +0700
-Subject: powerpc64 can define __s64 differently
+Subject: powerpc64 and mips64el can define __s64 differently
 
 Index: sword/include/sysdata.h
 ===
@@ -10,7 +10,7 @@
  
  #ifdef OS_ANDROID
  #elif defined(__GNUC__)
-+  #if !defined(__SANE_USERSPACE_TYPES__) && defined(__powerpc64__)
++  #if !defined(__SANE_USERSPACE_TYPES__) && (defined(__powerpc64__) || (defined(__mips__) && (_MIPS_SIM==_ABI64)))
 +  typedef __signed__ long __s64;
 +  typedef unsigned long __u64;
 +  #else


Bug#963036: Wild guess to fix this bug

2020-06-18 Thread Georges Khaznadar
Dear maintainer(s) of octave-symbolic, here is a wild guess, inspired by
a simple remark:

8<
$ python3 -c "import six; print(six.integer_types)" (,)
$ python2 -c "import six; print(six.integer_types)" (, )
8<

Would it be enough to patch octave-symbolic source, to replace
'sympy.core.compatibility.integer_types' by 'six.integer_types' ?

Best regards,   Georges.

-- 
Georges KHAZNADAR et Jocelyne FOURNIER
22 rue des mouettes, 59240 Dunkerque France.
Téléphone +33 (0)3 28 29 17 70



signature.asc
Description: PGP signature


Bug#960237: clickhouse: diff for NMU version 18.16.1+ds-7.1

2020-06-18 Thread Adrian Bunk
Dear maintainer,

I've prepared an NMU for clickhouse (versioned as 18.16.1+ds-7.1) and 
uploaded it to DELAYED/14. Please feel free to tell me if I should 
cancel it.

cu
Adrian
diff -Nru clickhouse-18.16.1+ds/debian/changelog clickhouse-18.16.1+ds/debian/changelog
--- clickhouse-18.16.1+ds/debian/changelog	2020-03-30 05:55:51.0 +0300
+++ clickhouse-18.16.1+ds/debian/changelog	2020-06-18 18:24:20.0 +0300
@@ -1,3 +1,10 @@
+clickhouse (18.16.1+ds-7.1) unstable; urgency=low
+
+  * Non-maintainer upload.
+  * Build depend on tzdata. (Closes: #960237)
+
+ -- Adrian Bunk   Thu, 18 Jun 2020 18:24:20 +0300
+
 clickhouse (18.16.1+ds-7) unstable; urgency=medium
 
   * Port test suite to python3; Closes: #942920
diff -Nru clickhouse-18.16.1+ds/debian/control clickhouse-18.16.1+ds/debian/control
--- clickhouse-18.16.1+ds/debian/control	2020-03-30 05:55:51.0 +0300
+++ clickhouse-18.16.1+ds/debian/control	2020-06-18 18:24:20.0 +0300
@@ -43,6 +43,7 @@
 	   libdivide-dev,
 	   libpcg-cpp-dev,
 	   libmetrohash-dev,
+	   tzdata,
 #	   libclang-dev,
 #	   liblld-7-dev,
 #needs newer version


Bug#963076: ITP: lightgbm -- It is a gradient boosting framework that uses tree based learning algorithms. It is designed to be distributed and efficient

2020-06-18 Thread Juri Grabowski
Package: wnpp
Severity: wishlist
Owner: Juri Grabowski 

* Package name: lightgbm
  Version : 2.3.1
  Upstream Author : Guolin Ke 
Guolin Ke 
* URL : https://www.microsoft.com/en-us/research/project/lightgbm/
* License : MIT
  Programming Lang: C++, python
  Description : It is a gradient boosting framework that uses tree based 
learning algorithms. It is designed to be distributed and efficient

Description: It is a gradient boosting framework that uses tree based learning 
algorithms. It is designed to be distributed and efficient
 with the following advantages
 - Faster training speed and higher efficiency.
 - Lower memory usage.
 - Better accuracy.
 - Support of parallel and GPU learning.
 - Capable of handling large-scale data.

Plan is to maintain it in debian-science-team
Here is Licence:
https://github.com/microsoft/LightGBM/blob/master/LICENSE



Bug#963019: RFS: pem/0.7.9-3 -- command line personal expense manager

2020-06-18 Thread Marcio de Souza Oliveira
Boa tarde jovem,

Já encontrou sponsor? Se quiser posso revisar.

Att, 

Marcio

Em qua, 2020-06-17 às 14:10 -0500, David da Silva Polverari escreveu:
> Package: sponsorship-requests
> Severity: normal
> 
> Dear mentors,
> 
> I am looking for a sponsor for my package "pem"
> 
>  * Package name: pem
>Version : 0.7.9-3
>Upstream Author : Prasad J Pandit 
>  * URL : https://www.gnu.org/software/pem/
>  * License : GPL-3+
>  * Vcs : https://salsa.debian.org/debian/pem
>Section : misc
> 
> It builds those binary packages:
> 
>   pem - command line personal expense manager
> 
> To access further information about this package, please visit the
> following URL:
> 
>   https://mentors.debian.net/package/pem
> 
> Alternatively, one can download the package with dget using this
> command:
> 
>   dget -x 
> https://mentors.debian.net/debian/pool/main/p/pem/pem_0.7.9-3.dsc
> 
> Changes since the last upload:
> 
>* Using new DH level format. Consequently:
>- debian/compat: removed.
>- debian/control: changed from 'debhelper' to 'debhelper-
> compat' in
>  Build-Depends field and bumped level to 13.
>* debian/control:
>- Added '${perl:Depends}' to Depends field.
>- Added 'Rules-Requires-Root: no' to source stanza.
>- Added Vcs-* fields.
>- Bumped Standards-Version to 4.5.0.
>- Marked pem as 'Multi-Arch: foreign'.
>- Removed redundant dh-autoreconf build dependency.
>* debian/copyright: updated copyright years.
>* debian/patches/010_use-usr-bin-perl.patch: added to use
> '/usr/bin/perl'
>  instead of '/usr/bin/env perl' for interpreter invocation.
>* debian/rules: removed redundant '--with autoreconf' dh
> parameter.
>* debian/salsa-ci.yml: added to provide CI tests for Salsa.
>* debian/tests/control: added to perform a trivial CI test.
>* debian/upstream/metadata: created.
>* debian/watch: using a secure URI.
> 
> Regards,
> 
> --
>   David da Silva Polverari
> 



Bug#963075: fusiondirectory: Upstream files missing in package

2020-06-18 Thread Olof Johansson
Package: fusiondirectory
Version: 1.3-2
Severity: important

Hello,

Thanks for maintaining fusiondirectory!

After installing fusiondirectory in bullseye in a new environment, the
web interface (the setup wizard) only renders an error:

  cannot instantiate class 'Language' - try running 'fusiondirectory-setup 
--update-cache' to fix this

Running that command didn't fix it. It turns out some files are missing
from the installation, notably class_Language.inc. I *think* upstream
has added these recently, and they aren't listed in
debian/fusiondirectory.install.

The files I identified as missing in the debian package, as compared to
the git repository (tag fusiondirectory-1.3):

  core/html/include/tsorter.js
  core/include/class_Language.inc
  core/include/class_ldapSizeLimit.inc

(I may have missed something, and I didn't look at the plugin packages.)

I'm not sure how severe this would be when upgrading an existing
installation, but it at least leaves the web UI unusable to new
deployments as the setup wizard won't render.

Is there a reason for hardcoding this list of files in
debian/fusiondirectory.install, instead of just taking the whole
directory?


glad midsommar,
-- 
olof



Bug#963073: reportbug: please update documentation on how to use reportbug.debian.org

2020-06-18 Thread Sandro Tosi
On Thu, Jun 18, 2020 at 11:30 AM David Bremner  wrote:
>
> Package: reportbug
> Version: 7.6.0
> Severity: wishlist
>
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
>
> It's not very clear from README.Users what options precisely the user
> should use to submit via reportbug.debian.org. At least I just spent
> some minutes trying and failing to help a new user to do so.

in ~/.reportbugrc, you just need

smtphost reportbug.debian.org

and that's it (you can also re-run the reportbug configuration menu
and dont enter any smtphost, and r.d.o will be selected automatically,
just follow the instructions)

can you provide an example of how you'd like to have
the documentation updated?

Regards.

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



Bug#963074: ITP: thc-rfs-client -- Client for an encrypted cloud based remote file system

2020-06-18 Thread Ralf Skyper Kaiser
Package: wnpp
Severity: wishlist
Owner: sky...@thc.org

* Package name: thc-rfs-client
  Version : 1.2
  Upstream Author : skyper 
* URL : https://github.com/hackerschoice/thc-rfs-client
* License : (GPL)
  Programming Lang: (bash)
  Description : Client for an encrypted cloud based remote file system

An easy-to-use, easy-to-setup, hassle-free secure file system with the
encrypted data being stored on a remote cloud server without having to
trust the server.

All key material is created on the user's computer and never stored
or transferred to the server.

All data is locally encrypted (including the file name). The encrypted
data (and only that!) is stored in the cloud. The data remains secure
even if the cloud server is compromised. It does not need root or
superuser privileges. No need to run your own server. All you need is
the bash script (literally). It is one single command to add and use a
file system:

$ thc-rfs mount aDe5F2ik3x35x7pfAEAWdC5Y ~/secure

Why is it useful: It enables two users to share data securely without
needing access to a server or revealing their identity.

Maintain: I plan to maintain it with good faith and to the best
of my ability. Yes, I need a sponsor.


Bug#963036: Sympy 3.6 no longer defined any integer_types attribute

2020-06-18 Thread Georges Khaznadar
Dear maintainer(s),

The command `grep -r integer_types .`, when launched from the source
directory of sympy's package, returns nothing.

On the other hand, the command
`grep -r integer_types /usr/share/octave/packages/symbolic-2.7.1/`
returns the following lines:

---8<---
/usr/share/octave/packages/symbolic-2.7.1/private/check_and_convert.m:  
persistent integer_types
/usr/share/octave/packages/symbolic-2.7.1/private/check_and_convert.m:
integer_types = sp.compatibility.integer_types;
/usr/share/octave/packages/symbolic-2.7.1/private/check_and_convert.m:
elseif (py.isinstance(x, integer_types))
/usr/share/octave/packages/symbolic-2.7.1/private/python_header.py:elif 
isinstance(x, sp.compatibility.integer_types):
---8<---

So I suspect that some parts of Octave-symbolic should be updated to
take in account the newer Sympy version.

Unfortunately, the documentation of Sympy 1.6 does not refere to the
word integer_types (which is the consequence of this word missing in the
source of the package).

I cannot help, so far, because I ignore what the attribute integer_types
was intended to in the previous version. Please can you, maintainer(s)
of octave-symbolic, provide some additional information ? If it is not
possible to fix the bug properly, maybe some tests should be temporarily
disabled?
 
Best regards,   Georges.

-- 
Georges KHAZNADAR et Jocelyne FOURNIER
22 rue des mouettes, 59240 Dunkerque France.
Téléphone +33 (0)3 28 29 17 70



signature.asc
Description: PGP signature


Bug#963071: daily errors in webwml/check_trans.pl (called by cron/scripts/check_trans.sh)

2020-06-18 Thread Steve McIntyre
On Thu, Jun 18, 2020 at 03:59:21PM +0200, Laura Arjona Reina wrote:
>Package: www.debian.org
>User www.debian@packages.debian.org
>Usertag: scripts
>Severity: normal
>
>We are receiving daily errors about the check_trans.pl tool on top of
>the webwml folder, it seems Perl is not able to get the translator.db.pl
>files for each language. We have 2 types of error:
>
>1.- L1024: require $db_file; fails, but the file is there. For example
>arabic:
>
>Can't locate arabic/international/arabic/translator.db.pl in @INC (@INC
>contains: /srv/www.debian.org/webwml/Perl /etc/perl
>/usr/local/lib/x86_64-linux-gnu/perl/5.24.1 /usr/local/share/perl/5.24.1
>/usr/lib/x86_64-linux-gnu/perl5/5.24 /usr/share/perl5
>/usr/lib/x86_64-linux-gnu/perl/5.24 /usr/share/perl/5.24
>/usr/local/lib/site_perl /usr/lib/x86_64-linux-gnu/perl-base) at
>./check_trans.pl line 1024.
>
>We didn't change the check_trans.pl recently, I guess maybe something
>changed in the Perl environment that we need to provide the full path to
>the file (and not only relative path) or load the file in other way, no
>idea. Any Perl expert around?

ACK. Simple tweak is to modify the reauire slightly:

-   require $db_file;
+   require "./$db_file";

and that fixes this. I've no idea why this worked before but not now,
though. :-(

>2.- L1024: require $db_file; fails because the file is in other folder,
>for example Chinese:
>
>File `chinese/international/chinese/translator.db.pl' doesn't exist!
>I need my DBs to send mails.
>Please read the comments in the script and try again
>
>
>(The translator.db.pl is in the
>chinese/international/Chinese/translator.db.pl path). This issue
>(translator.db.pl in a diferent path) happens for 3 languages only:
>
>./catalan/international/Catalan/translator.db.pl
>./chinese/international/Chinese/translator.db.pl
>./german/international/German/translator.db.pl

Again, I have no idea WTH has *changed* here that might have caused
things to break suddenly! It looks like require is now suddenly acting
more strictly or something...

>I guess we need to:
>A.- move the translator.db.pl file to the corresponding folder with
>lower case letters
>or
>B.- add logic to the check_trans.pl to try the folder with capital
>letter if the usual path fails
>
>I tend to the A proposal because it's the one that I can do, but if
>there is anybody who can provide B, that's more elegant I guess :-)

Option A looks like the obvious thing to do, so I've just done it. I
don't see any good reason for the leading-cap names to exist here?

-- 
Steve McIntyre, Cambridge, UK.st...@einval.com
The two hard things in computing:
 * naming things
 * cache invalidation
 * off-by-one errors  -- Stig Sandbeck Mathisen



Bug#963073: reportbug: please update documentation on how to use reportbug.debian.org

2020-06-18 Thread David Bremner
Package: reportbug
Version: 7.6.0
Severity: wishlist

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

It's not very clear from README.Users what options precisely the user
should use to submit via reportbug.debian.org. At least I just spent
some minutes trying and failing to help a new user to do so.

- -- Package-specific info:
** Environment settings:
EDITOR="eedit"
DEBEMAIL="brem...@debian.org"
EMAIL="da...@tethera.net"

** /home/bremner/.reportbugrc:
sign gpg
keyid 922C87617C1A6344A263A7EA0345391B55AA1521!
mode advanced

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

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

Versions of packages reportbug depends on:
ii  apt2.1.6
ii  python33.8.2-3
ii  python3-reportbug  7.6.0
ii  sensible-utils 0.0.12+nmu1

reportbug recommends no packages.

Versions of packages reportbug suggests:
pn  claws-mail 
ii  debconf-utils  1.5.74
ii  debsums3.0.0
ii  dlocate1.07+nmu1
ii  emacs-bin-common   1:26.3+1-2
ii  file   1:5.38-5
ii  gnupg  2.2.20-1
ii  nullmailer [mail-transport-agent]  1:2.2-3
ii  python3-urwid  2.0.1-3+b1
pn  reportbug-gtk  
ii  xdg-utils  1.1.3-2

Versions of packages python3-reportbug depends on:
ii  apt2.1.6
ii  file   1:5.38-5
ii  python33.8.2-3
ii  python3-apt2.1.3
ii  python3-debian 0.1.37
ii  python3-debianbts  3.0.2
ii  python3-requests   2.23.0+dfsg-2
ii  sensible-utils 0.0.12+nmu1

python3-reportbug suggests no packages.

- -- no debconf information

-BEGIN PGP SIGNATURE-

iQIzBAEBCAAdFiEEkiyHYXwaY0SiY6fqA0U5G1WqFSEFAl7rh5cACgkQA0U5G1Wq
FSG8ow//avhybWyiIS5FcGVAofVLO3DHvgXqKU8m/VKvhJG+qJ/lVsrM7iQo3Cdx
IqahSOxvcuY8vmvfzlhFIlQfzp3l5gIG8MG0klRTs87q+5Vnp4NyxqzJjAkmMZFU
TSLnMnrc4ov501bUUN94Qipa8zQKwzlRJBM1wXyNBm+reK7M5jwokGDD/wjeYeAE
IQ0HfY6JKsB8S4ISaBsBwKnnQlxDRd83E2h3d7Ro4qv2S6bP18DybcrswmQFMuQC
RoNL7hVKHMZoBSwgTrMYQhPcU6ZNlJ6u4fi84sSZrr3AA1hW2uZMlohAkMYIwAEW
HYtmRRvmeUNxxMiz1MqCz764qtY6YXgpzTZn46aZZD7jOSoMFzzTH12zmGtiUF+A
Naqtmo9Q8P3yPRAx2lseZRcXS1DtKVCBxZXGyOMAdHB+3qbbRyXuN1FI6E62cMpk
2Rnx86P6uamrQ0qA4GzVItMCjvsSoedssE3bhOgS3ybA7cR3GJOfsQlaqUG2G74l
5sM718xckzVDCJXNejzfWJrIy5SiEDQ7uIES6hbFqkPKhW2CzGR8QZslkS6oONFF
MIRt4wiLMojXHmhSDiUKB7SvFCvyi/ng2JAzIE5iqYMxY08GUTqfrNtKIzuiWI4I
Hj78TTGe11U/gqOnKit1SoVYhNgMTME4aAWRBDCtkBW869HrEm8=
=34Sh
-END PGP SIGNATURE-



Bug#959157: fix for CVE-2020-1749 in linux-image-4.19.0-9 breaks wireguard

2020-06-18 Thread Timo Jyrinki

  
  
Hi,

I had this too using buster + backports:

---

DKMS make.log for wireguard-1.0.20200520 for kernel 4.19.0-6-marvell (armv5tel)
to 18.6.2020 15.12.16 +0300
make: Siirrytään hakemistoon ”/usr/src/linux-headers-4.19.0-6-marvell”
  CC [M]  /var/lib/dkms/wireguard/1.0.20200520/build/main.o
  CC [M]  /var/lib/dkms/wireguard/1.0.20200520/build/noise.o
  CC [M]  /var/lib/dkms/wireguard/1.0.20200520/build/device.o
  CC [M]  /var/lib/dkms/wireguard/1.0.20200520/build/peer.o
  CC [M]  /var/lib/dkms/wireguard/1.0.20200520/build/timers.o
  CC [M]  /var/lib/dkms/wireguard/1.0.20200520/build/queueing.o
  CC [M]  /var/lib/dkms/wireguard/1.0.20200520/build/send.o
  CC [M]  /var/lib/dkms/wireguard/1.0.20200520/build/receive.o
  CC [M]  /var/lib/dkms/wireguard/1.0.20200520/build/socket.o
/var/lib/dkms/wireguard/1.0.20200520/build/socket.c: In function ‘send6’:
/var/lib/dkms/wireguard/1.0.20200520/build/socket.c:139:20: error: ‘const struct ipv6_stub’ has no member named ‘ipv6_dst_lookup_flow’; did you mean ‘ipv6_dst_lookup’?
   dst = ipv6_stub->ipv6_dst_lookup_flow(sock_net(sock), sock, &fl,
^~~~
ipv6_dst_lookup
make[3]: *** [/usr/src/linux-headers-4.19.0-6-common/scripts/Makefile.build:309: /var/lib/dkms/wireguard/1.0.20200520/build/socket.o] Virhe 1
make[2]: *** [/usr/src/linux-headers-4.19.0-6-common/Makefile:1534: _module_/var/lib/dkms/wireguard/1.0.20200520/build] Virhe 2
make[1]: *** [Makefile:146: sub-make] Virhe 2
make: *** [Makefile:8: all] Virhe 2
make: Poistutaan hakemistosta ”/usr/src/linux-headers-4.19.0-6-marvell”
---

I managed to fix it thanks to message #34, changing /usr/src/wireguard-1.0.20200520/compat/compat.h slightly and running dpkg --configure -a. It built fine both against 4.19.0-6-marvell and 4.19.0-9-marvell.

-Timo


  




signature.asc
Description: OpenPGP digital signature


Bug#955114: mongo-c-driver: diff for NMU version 1.16.1-1.1

2020-06-18 Thread Adrian Bunk
Dear maintainer,

I've prepared an NMU for mongo-c-driver (versioned as 1.16.1-1.1) and 
uploaded it to DELAYED/2. Please feel free to tell me if I should cancel it.

cu
Adrian
diff -Nru mongo-c-driver-1.16.1/debian/changelog mongo-c-driver-1.16.1/debian/changelog
--- mongo-c-driver-1.16.1/debian/changelog	2020-02-06 21:30:48.0 +0200
+++ mongo-c-driver-1.16.1/debian/changelog	2020-06-18 18:02:18.0 +0300
@@ -1,3 +1,10 @@
+mongo-c-driver (1.16.1-1.1) unstable; urgency=high
+
+  * Non-maintainer upload.
+  * Backport fix for FTBFS with Sphinx 2.4. (Closes: #955114)
+
+ -- Adrian Bunk   Thu, 18 Jun 2020 18:02:18 +0300
+
 mongo-c-driver (1.16.1-1) unstable; urgency=medium
 
   * New upstream release
diff -Nru mongo-c-driver-1.16.1/debian/patches/0001-CDRIVER-3594-build-Sphinx-docs-without-parallelism.patch mongo-c-driver-1.16.1/debian/patches/0001-CDRIVER-3594-build-Sphinx-docs-without-parallelism.patch
--- mongo-c-driver-1.16.1/debian/patches/0001-CDRIVER-3594-build-Sphinx-docs-without-parallelism.patch	1970-01-01 02:00:00.0 +0200
+++ mongo-c-driver-1.16.1/debian/patches/0001-CDRIVER-3594-build-Sphinx-docs-without-parallelism.patch	2020-06-18 18:02:13.0 +0300
@@ -0,0 +1,34 @@
+From 214c433997ffbed6f36e2ba46218c5beb30a6107 Mon Sep 17 00:00:00 2001
+From: =?UTF-8?q?Roberto=20C=2E=20S=C3=A1nchez?= 
+Date: Mon, 30 Mar 2020 19:37:03 -0400
+Subject: CDRIVER-3594 build Sphinx docs without parallelism
+
+---
+ build/cmake/SphinxBuild.cmake | 4 ++--
+ 1 file changed, 2 insertions(+), 2 deletions(-)
+
+diff --git a/build/cmake/SphinxBuild.cmake b/build/cmake/SphinxBuild.cmake
+index a7f49d79b..f90308486 100644
+--- a/build/cmake/SphinxBuild.cmake
 b/build/cmake/SphinxBuild.cmake
+@@ -40,7 +40,7 @@ function (sphinx_build_html target_name doc_dir)
+   ${CMAKE_COMMAND} -E env
+   "PYTHONDONTWRITEBYTECODE=1"
+   ${SPHINX_EXECUTABLE}
+- -j ${NPROCS} -qEW -b html
++ -qEW -b html
+  -c "${CMAKE_CURRENT_SOURCE_DIR}"
+  "${CMAKE_CURRENT_SOURCE_DIR}"
+  "${SPHINX_HTML_DIR}"
+@@ -133,7 +133,7 @@ function (sphinx_build_man target_name)
+   ${CMAKE_COMMAND} -E env
+   "PYTHONDONTWRITEBYTECODE=1"
+   ${SPHINX_EXECUTABLE}
+- -j ${NPROCS} -qEW -b man
++ -qEW -b man
+  -c "${CMAKE_CURRENT_SOURCE_DIR}"
+  "${CMAKE_CURRENT_SOURCE_DIR}"
+  "${SPHINX_MAN_DIR}"
+-- 
+2.20.1
+
diff -Nru mongo-c-driver-1.16.1/debian/patches/series mongo-c-driver-1.16.1/debian/patches/series
--- mongo-c-driver-1.16.1/debian/patches/series	1970-01-01 02:00:00.0 +0200
+++ mongo-c-driver-1.16.1/debian/patches/series	2020-06-18 18:02:18.0 +0300
@@ -0,0 +1 @@
+0001-CDRIVER-3594-build-Sphinx-docs-without-parallelism.patch


Bug#963072: haskell-easytest: Does not build with hedgehog 1.x

2020-06-18 Thread Ilias Tsitsimpis
Source: haskell-easytest
Version: 0.2.1-2
Severity: grave
Justification: renders package unusable
Forwarded: https://github.com/joelburget/easytest/issues/26

easytest does not work with hedgehog 1.x (available on unstable).
Luckily, hledger (the only rev dep of easytest) replaced it with tasty:

  https://github.com/simonmichael/hledger/commit/13a3542464de479e8

If easytest continues to be unmaintained, we may want to consider
removing it from Debian.

-- 
Ilias



Bug#944757: endless-sky: please package Endless Sky 0.9.10

2020-06-18 Thread Enrico Zini
On Thu, Jun 18, 2020 at 04:28:38PM +0200, Enrico Zini wrote:

> Please do :)
> Upstream's latest stable release is now 0.9.12.

Additionally, I can confirm that 0.9.12 builds and works just by
plugging in the current debian/ contents.


Enrico

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



Bug#956888: gnome-control-center: FTBFS on mipsel

2020-06-18 Thread Simon McVittie
Control: severity -1 important
Control: tags -1 + unreproducible

On Thu, 16 Apr 2020 at 13:21:19 +0200, Sebastian Ramacher wrote:
> The rebuild for the libgnome-desktop transition failed on mipsel due to
> test failures.

This succeeded when given back.

smcv



Bug#962847: exim4: takes forever to send a mail after sleeping

2020-06-18 Thread Thorsten Bonow

Hi,

I can reproduce the bug on my system, but I think it's GNU Emacs 
related:


After I put my system to sleep for 5 minutes, sending a test mail 
with GNU Emacs took 5 minutes, while sending one with 
"/usr/bin/bsd-mailx" was possible without the lag.


The bug bit me for 2 days, I wasn't able to send mails in the 
morning---after my system was suspended during the night.  A reboot 
fixed the problem.  Everything else I tried failed.


I'm using GNU Emacs with the Mew Mailer (package "mew-beta") on an up 
to date Debian Sid system (exim 4.94-2, configured with my provider's 
mail server as smarthost).


During the last 5 minute test, the logs looked normal, the other 
mails stuck created something like this every 30 minutes:


"2020-06-16 13:22:18 1jl9X4-005JlN-Vw Spool file for 1jl9X4-005JlN-Vw 
is locked (another process is handling this message)"


On sending a mail which becomes stuck, Mew displays "Sending in 
background..." forever.   After restarting GNU Emacs and Mew, I can 
see the mail in the +queue folder; sending it is possible after a 
system reboot.


I'm not an expert but I will try to look into the problem.

Thanks,

Toto


--
Sent from my GNU Emacs running on GNU/Linux



Bug#963049: pki-base: syntax error in /usr/share/pki/scripts/config

2020-06-18 Thread Laurent Bonnaud


Package: pki-base
Version: 10.9.0~a2-2
Severity: serious


Dear Maintainer,

here is the problem:

# source /usr/share/pki/scripts/config
-bash: break: only meaningful in a `for', `while', or `until' loop


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

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

Versions of packages pki-base depends on:
ii  python3-pki-base  10.9.0~a2-2

pki-base recommends no packages.

pki-base suggests no packages.

-- no debconf information

-- 
Laurent.



Bug#944757: endless-sky: please package Endless Sky 0.9.10

2020-06-18 Thread Enrico Zini
On Thu, Nov 14, 2019 at 10:01:49PM +0100, Martin Steigerwald wrote:

> please package version 0.9.10 or whatever version is current when you decide
> to do an updated package.

Please do :)
Upstream's latest stable release is now 0.9.12.


Enrico

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



Bug#941235: remmina-plugin-vnc: VNC plugin not registered

2020-06-18 Thread Eric Cooper
On Wed, Jun 17, 2020 at 2:43 PM Matteo F. Vescovi  wrote:

> has the situation changed with newer versions?
>
> Please, let me know so I can triage this bug report better... or even
> close it, if the issue doesn't show up anymore.
>

I can't reproduce the problem with the version currently in bullseye, so
feel free to close this. Thanks.


Bug#963048: pki-base: postinst failure because of incorrect use of --silent option of pki-upgrade

2020-06-18 Thread Laurent Bonnaud


Package: pki-base
Version: 10.9.0~a2-2
Severity: serious


Dear Maintainer,

here is the problem:

Setting up pki-base (10.9.0~a2-2) ...
dpkg: error processing package pki-base (--configure):
 installed pki-base package post-installation script subprocess returned error 
exit status 1
Errors were encountered while processing:
 pki-base


The problem comes from the postinst script that tries to execute this command:

# pki-upgrade --silent
[...]
ERROR: option --silent not recognized
Usage: pki-upgrade [OPTIONS]

  --status   Show upgrade status only. Do not perform 
upgrade.
  --revert   Revert the last version.
  --validate Validate upgrade status.

  -X Show advanced options.
  -v, --verbose  Run in verbose mode.
  --debugRun in debug mode.
  -h, --help Show this help message.


Removing the --silent option fixes the problem.


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

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

Versions of packages pki-base depends on:
ii  python3-pki-base  10.9.0~a2-2

pki-base recommends no packages.

pki-base suggests no packages.

-- no debconf information

-- 
Laurent.



Bug#963045: gnome-control-center: Unable to install due to wrong dependency(ies)

2020-06-18 Thread Philippe Chauvat
Package: gnome-control-center
Version: 1:3.36.2-1
Severity: important

Dear Maintainer,

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

   * What led up to the situation?
   I upgraded my system from buster to bullseye. Therefore I was unable to 
install gnome-control-center. When trying to do it manually, I saw that other 
dependencies are either missing or wrong.
   libfluidsynth1 is required but only libfluidsynth2 is available
   gstreamer1.0-plugins-bad is trying to be installed but in conflict with 
other packages...
   * What exactly did you do (or not do) that was effective (or
 ineffective)?
 apt clean && apt update
 apt install gnome-control-center
 
   * What was the outcome of this action?
   Lecture des listes de paquets... Fait
Construction de l'arbre des dépendances   
Lecture des informations d'état... Fait
Les paquets suivants ont été installés automatiquement et ne sont plus 
nécessaires :
  espeak-ng-data gir1.2-gdata-0.0 gir1.2-rb-3.0 gir1.2-totem-1.0 
gir1.2-wnck-3.0 gir1.2-zpj-0.0 libdotconf0 libespeak-ng1 libgpod-common 
libgpod4 libmusicbrainz5-2 libmusicbrainz5cc2v5 libpcaudio0
  librhythmbox-core10 librygel-renderer-gst-2.6-2 libsgutils2-2 libsonic0 
libspeechd2 libtotem0 libwnck-3-0 libwnck-3-common libxres1 python3-brlapi 
python3-louis python3-mako python3-markupsafe
  python3-speechd python3-xdg rhythmbox-data sound-icons speech-dispatcher 
speech-dispatcher-audio-plugins speech-dispatcher-espeak-ng totem-common 
unoconv xbrlapi
Veuillez utiliser « apt autoremove » pour les supprimer.
Les paquets supplémentaires suivants seront installés : 
  gstreamer1.0-plugins-bad gstreamer1.0-plugins-good libcheese-gtk25 libcheese8
Paquets suggérés :
  libcanberra-gtk-module frei0r-plugins
Les NOUVEAUX paquets suivants seront installés :
  gnome-control-center gstreamer1.0-plugins-bad gstreamer1.0-plugins-good 
libcheese-gtk25 libcheese8
0 mis à jour, 5 nouvellement installés, 0 à enlever et 0 non mis à jour.
Il est nécessaire de prendre 0 o/8 203 ko dans les archives.
Après cette opération, 22,8 Mo d'espace disque supplémentaires seront utilisés.
Souhaitez-vous continuer ? [O/n] 

(Lecture de la base de données... 538983 fichiers et répertoires déjà 
installés.)
Préparation du dépaquetage de 
.../gstreamer1.0-plugins-bad_1%3a1.14.4-dmo7_amd64.deb ...
Dépaquetage de gstreamer1.0-plugins-bad:amd64 (1:1.14.4-dmo7) ...
dpkg: erreur de traitement de l'archive 
/var/cache/apt/archives/gstreamer1.0-plugins-bad_1%3a1.14.4-dmo7_amd64.deb 
(--unpack) :
 tentative de remplacement de « 
/usr/lib/x86_64-linux-gnu/gstreamer-1.0/libgstcompositor.so », qui appartient 
aussi au paquet gstreamer1.0-plugins-base:amd64 1.16.2-4
dpkg-deb: erreur: coller subprocess was killed by signal (Relais brisé (pipe))
Sélection du paquet gstreamer1.0-plugins-good:amd64 précédemment désélectionné.
Préparation du dépaquetage de .../gstreamer1.0-plugins-good_1.16.2-3_amd64.deb 
...
Dépaquetage de gstreamer1.0-plugins-good:amd64 (1.16.2-3) ...
Sélection du paquet libcheese8:amd64 précédemment désélectionné.
Préparation du dépaquetage de .../libcheese8_3.34.0-1+b2_amd64.deb ...
Dépaquetage de libcheese8:amd64 (3.34.0-1+b2) ...
Sélection du paquet libcheese-gtk25:amd64 précédemment désélectionné.
Préparation du dépaquetage de .../libcheese-gtk25_3.34.0-1+b2_amd64.deb ...
Dépaquetage de libcheese-gtk25:amd64 (3.34.0-1+b2) ...
Sélection du paquet gnome-control-center précédemment désélectionné.
Préparation du dépaquetage de .../gnome-control-center_1%3a3.36.2-1_amd64.deb 
...
Dépaquetage de gnome-control-center (1:3.36.2-1) ...
Des erreurs ont été rencontrées pendant l'exécution :
 /var/cache/apt/archives/gstreamer1.0-plugins-bad_1%3a1.14.4-dmo7_amd64.deb
needrestart is being skipped since dpkg has failed
E: Sub-process /usr/bin/dpkg returned an error code (1)

   * What outcome did you expect instead?
   Having the package installed?

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


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

Kernel: Linux 5.6.0-2-amd64 (SMP w/8 CPU cores)
Kernel taint flags: 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 /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages gnome-control-center depends on:
ii  accountsservice0.6.55-2
ii  apg2.2.3.dfsg.1-5+b1
ii  colord 1.4.4-2
ii  desktop-base   10.0.3
ii  desktop-file-utils 0.24-1
ii  gnome-control-center-data  1:3.36.2-1
ii  gnome-desktop3-data3.36.2-1
ii  gnome-settings-daemon  3.36.1-1
ii  gsettings-desktop-schemas  3.36.1-1
ii  libaccountsservice00.6.55-2
ii  libatk1.0-02.36.0-2
ii  libc6  2.30-8
ii  libcairo2  

Bug#962960: kdiff3: Choose X Everywhere / For All Unsolved menu items missing

2020-06-18 Thread Matthew Gabeler-Lee

forwarded 962960 https://bugs.kde.org/show_bug.cgi?id=407745
tags 962960 + upstream fixed-upstream
thanks

Looks like this was fixed upstream and has been released in 1.8.02, by 
commit https://invent.kde.org/sdk/kdiff3/-/commit/1c86432a9a72c9fbf193d97035255e3a1b6cac09


--
-- Matt
"Reality is that which, when you stop believing in it, doesn't go away".
-- Philip K. Dick
GPG fingerprint: 0061 15DF D282 D4A9 57CE  77C5 16AF 1460 4A3C C4E9



Bug#959755: Bug #959755: Package pages for source/buster-backports gets 500 error

2020-06-18 Thread Adam D. Barratt
On Thu, 2020-06-18 at 14:39 +0200, Laura Arjona Reina wrote:
> I still can reproduce this error, and also today webmaster@ received
> a report about some more URLs failing.
> 
> URL for existing packages in stable-backports report a HTTP 500 error
> at the time of writing (Thu, 18 Jun 2020 10:25:41 +0200).
> For instance:
> https://packages.debian.org/source/stable-backports/linux
> https://packages.debian.org/source/stable-backports/apt-cacher-ng
> do not work (HTTP 500)

The issue is that the suite doesn't have MD5 checksums enabled, which
the packages.d.o code relies on. After that was diagnosed a while ago,
I thought that ftp-master were re-enabling them, but apparently that
never happened.

When I looked at this previously, this seemed to work as a short-term
"fix":

adsb@picconi:~$ diff -u /srv/packages.debian.org/bin/parse-sources 
./parse-sources 
--- /srv/packages.debian.org/bin/parse-sources  2020-02-14 06:06:33.126000572 
+
+++ ./parse-sources 2020-02-27 09:49:07.123732777 +
@@ -103,6 +103,7 @@
$source_names_suite{$data{'package'}} = 1;
delete $data{'binary'};
 
+   $data{files} = $data{'checksums-sha256'} unless $data{files};
$data{files} =~ s/\s*\n\s*/\01/sog;
$data{files} =~ s/^\01//sg;
 
Longer term, that should probably iterate over the list of possible
checksums and use whichever it finds first.

Rhonda: would an MR for either version of the patch here be helpful?

Regards,

Adam



Bug#963071: daily errors in webwml/check_trans.pl (called by cron/scripts/check_trans.sh)

2020-06-18 Thread Laura Arjona Reina
Package: www.debian.org
User www.debian@packages.debian.org
Usertag: scripts
Severity: normal

We are receiving daily errors about the check_trans.pl tool on top of
the webwml folder, it seems Perl is not able to get the translator.db.pl
files for each language. We have 2 types of error:

1.- L1024: require $db_file; fails, but the file is there. For example
arabic:

Can't locate arabic/international/arabic/translator.db.pl in @INC (@INC
contains: /srv/www.debian.org/webwml/Perl /etc/perl
/usr/local/lib/x86_64-linux-gnu/perl/5.24.1 /usr/local/share/perl/5.24.1
/usr/lib/x86_64-linux-gnu/perl5/5.24 /usr/share/perl5
/usr/lib/x86_64-linux-gnu/perl/5.24 /usr/share/perl/5.24
/usr/local/lib/site_perl /usr/lib/x86_64-linux-gnu/perl-base) at
./check_trans.pl line 1024.

We didn't change the check_trans.pl recently, I guess maybe something
changed in the Perl environment that we need to provide the full path to
the file (and not only relative path) or load the file in other way, no
idea. Any Perl expert around?

2.- L1024: require $db_file; fails because the file is in other folder,
for example Chinese:

File `chinese/international/chinese/translator.db.pl' doesn't exist!
I need my DBs to send mails.
Please read the comments in the script and try again


(The translator.db.pl is in the
chinese/international/Chinese/translator.db.pl path). This issue
(translator.db.pl in a diferent path) happens for 3 languages only:

./catalan/international/Catalan/translator.db.pl
./chinese/international/Chinese/translator.db.pl
./german/international/German/translator.db.pl

I guess we need to:
A.- move the translator.db.pl file to the corresponding folder with
lower case letters
or
B.- add logic to the check_trans.pl to try the folder with capital
letter if the usual path fails

I tend to the A proposal because it's the one that I can do, but if
there is anybody who can provide B, that's more elegant I guess :-)

Kind regards,

Laura Arjona Reina
https://www.debian.org/LauraArjona



  1   2   >