Bug#890400: Any news about a new upstream version with new SONAME?

[Andreas Tille]

Hi Julien,

On Sat, Mar 31, 2018 at 08:36:01PM +0200, Julien Yann Dutheil wrote:
> bpp-phyl-omics pushed (once more had committed and forgotten to push, sorry
> about that).

It was building without any problem for me.  I've just added the symbols
file (please be more verbose in your changelogs about things like this
and bumping versioned Build-Depends etc.) and uploaded.  I'm really
hoping that the bunch of packages will pass new queue soon.  Due to the
change in the binary package name all packages need to pass this queue
and thus there is some delay.

Kind regards

Andreas. 

-- 
http://fam-tille.de

Bug#894537: ITP: iwd -- wireless daemon for Linux

[Andreas Henriksson]

Package: wnpp
Severity: wishlist
Owner: Andreas Henriksson 

* Package name: iwd
  Version : 0.1
  Upstream Author : See AUTHORS
* URL : https://git.kernel.org/pub/scm/network/wireless/iwd.git/
* License : LGPL-2.1+
  Programming Lang: C
  Description : wireless daemon for Linux

I've prepared initial debian packaging of iwd which is available at:
https://salsa.debian.org/debian/iwd

Please see the debian/control file for full/official description.
Help welcome with improving it!

The unofficial one is that iwd is a minimalistic replacement for
wpa_supplicant (suitable for embedded). It builds on top of modern linux
interfaces (nl80211, cfg80211) and provides a D-Bus API.
There are also iwctl and iwmon command line utilities included.

This should likely still be considered experimental stage software.
Latest upstream development release of NetworkManager provides
experimental and disabled-by-default support for iwd. You should
also be able to find (upstream) support for it in connman.

(co-)maintainers welcome.

Regards,
Andreas Henriksson

Bug#894536: vim: Name suggestions for edit command should not include directories

[David Christensen]

Package: vim
Version: 2:8.0.0197-4+deb9u1
Severity: wishlist

Dear Maintainer,

The 'e' (edit) command of Vim has command-line completion.  Items
offered include file names and directory names.  Directory names
should not be included by default.

TIA,

David



-- Package-specific info:

--- real paths of main Vim binaries ---
/usr/bin/vi is /usr/bin/vim.basic
/usr/bin/vim is /usr/bin/vim.basic

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

Kernel: Linux 4.9.0-6-amd64 (SMP w/8 CPU cores)
Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968), LANGUAGE=C 
(charmap=ANSI_X3.4-1968)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages vim depends on:
ii  libacl1  2.2.52-3+b1
ii  libc62.24-11+deb9u3
ii  libgpm2  1.20.4-6.2+b1
ii  libselinux1  2.6-3+b3
ii  libtinfo56.0+20161126-1+deb9u2
ii  vim-common   2:8.0.0197-4+deb9u1
ii  vim-runtime  2:8.0.0197-4+deb9u1

vim recommends no packages.

Versions of packages vim suggests:
pn  ctags
pn  vim-doc  
pn  vim-scripts  

-- no debconf information

Bug#840919: done (Display Changed-By or FTP Team member in RSS feed (Closes: #840919))

[Paul Wise]

On Tue, 27 Mar 2018 20:01:53 + Luca Falavigna wrote:

> This bug was fixed in Git by Luca Falavigna in commit
> 8f2b2a919ed7bf1254cfdc2d0e50bc10a694b75a:
> 
> Display Changed-By or FTP Team member in RSS feed (Closes: #840919)
> 
> Signed-off-by: Luca Falavigna 

Would it be possible to deploy this on ftp-master?
 
-- 
bye,
pabs

https://wiki.debian.org/PaulWise


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

Bug#868101: done (Do not show None in Uploaders file (Closes: #868101))

[Paul Wise]

On Tue, 27 Mar 2018 19:59:35 + Luca Falavigna wrote:

> This bug was fixed in Git by Luca Falavigna in commit
> bb99e6998126ebe751c6b59c194284a30ce459b2:
> 
> Do not show None in Uploaders file (Closes: #868101)
> 
> Signed-off-by: Luca Falavigna 

Would it be possible to deploy this on ftp-master?

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


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

Bug#828503: pinot: FTBFS with openssl 1.1.0

[Olly Betts]

Control: tag -1 + fixed-upstream patch

Looks like upstream has addressed this (commit message "Catch up with
current glib and OpenSSL"):

https://github.com/FabriceColin/pinot/commit/a932cd1093599e8e26f5e408292faff92daceb74

Cheers,
Olly

Bug#889848: marked as done (ruby2.5: Please include upstream patch to fix FTBFS on ia64)

[Antonio Terceiro]

> Date: Wed, 07 Feb 2018 22:09:23 +0100
> From: John Paul Adrian Glaubitz 
> To: Debian Bug Tracking System 
> Subject: ruby2.5: Please include upstream patch to fix FTBFS on ia64
> Message-ID: 
> <151803776351.18433.12367250620839726943.report...@z6.physik.fu-berlin.de>
> X-Mailer: reportbug 7.1.8
> 
> Source: ruby2.5
> Version: 2.5.0-4
> Severity: normal
> Tags: patch
> User: debian-i...@lists.debian.org
> Usertags: ia64
> 
> Hello!
> 
> ruby2.5 currently FTBFS on ia64 with:
> 
> gcc -g -O2 -fdebug-prefix-map=/<>=. -Wformat 
> -Werror=format-security -fPIC  -D_FORTIFY_SOURCE=2 -fno-strict-overflow 
> -fvisibility=hidden -fexcess-precision=standard -DRUBY_EXPORT -Wdate-time 
> -D_FORTIFY_SOURCE=2   -I. -I.ext/include/ia64-linux-gnu -I./include -I. 
> -I./enc/unicode/10.0.0 -o cont.o -c cont.c
> cont.c: In function 'cont_save_machine_stack':
> cont.c:478:7: error: 'rb_thread_t {aka struct rb_thread_struct}' has no 
> member named 'machine'
>  th->machine.register_stack_end = rb_ia64_bsp();
>^~
> cont.c:502:50: error: 'rb_thread_t {aka struct rb_thread_struct}' has no 
> member named 'machine'
>  size = cont->machine.register_stack_size = 
> th->machine.register_stack_end - th->machine.register_stack_start;
>   ^~
> cont.c:502:83: error: 'rb_thread_t {aka struct rb_thread_struct}' has no 
> member named 'machine'
>  size = cont->machine.register_stack_size = 
> th->machine.register_stack_end - th->machine.register_stack_start;
>   
>  ^~
> cont.c:503:42: error: 'rb_thread_t {aka struct rb_thread_struct}' has no 
> member named 'machine'
>  cont->machine.register_stack_src = th->machine.register_stack_start;
>   ^~
> Makefile:375: recipe for target 'cont.o' failed
> 
> This has already been fixed upstream [1]. I am attaching the backported patch
> for ruby2.5. It would be nice if it could be included in the next upload.

Well, it seems that the issue is deeper than getting it to build. it segfaults
beatifully while building documentation ... unfortunately I don't have the
cycles to go after this, but I will happily take a tested patch (which should
also be sent upstream, of course).

Generating RDoc documentation
./miniruby -I./lib -I. -I.ext/common  ./tool/runruby.rb --extout=.ext  -- 
--disable-gems "./bin/rdoc" --root "." --page-dir "./doc" --encoding=UTF-8 
--no-force-update --all --ri --op ".ext/rdoc"  "."
Parsing sources...
  0% [ 1/871]  /<>/doc/NEWS-1.8.7
  0% [ 2/871]  /<>/doc/NEWS-1.9.1
  0% [ 3/871]  /<>/doc/NEWS-1.9.2
  0% [ 4/871]  /<>/doc/NEWS-1.9.3
  0% [ 5/871]  /<>/doc/NEWS-2.0.0
  0% [ 6/871]  /<>/doc/NEWS-2.1.0
  0% [ 7/871]  /<>/doc/NEWS-2.2.0
  0% [ 8/871]  /<>/doc/NEWS-2.3.0
  1% [ 9/871]  /<>/doc/NEWS-2.4.0
  1% [10/871]  /<>/doc/contributing.rdoc
  1% [11/871]  /<>/doc/contributors.rdoc
  1% [12/871]  /<>/doc/dtrace_probes.rdoc
  1% [13/871]  /<>/doc/extension.ja.rdoc
  1% [14/871]  /<>/doc/extension.rdoc
  1% [15/871]  /<>/doc/globals.rdoc
  1% [16/871]  /<>/doc/keywords.rdoc
  1% [17/871]  /<>/doc/maintainers.rdoc
  2% [18/871]  /<>/doc/marshal.rdoc
  2% [19/871]  /<>/doc/regexp.rdoc
  2% [20/871]  /<>/doc/security.rdoc
  2% [21/871]  /<>/doc/standard_library.rdoc
  2% [22/871]  /<>/doc/syntax.rdoc
  2% [23/871]  /<>/doc/syntax/assignment.rdoc
  2% [24/871]  ...d/ruby2.5-TpDw3s/ruby2.5-2.5.1/doc/syntax/calling_methods.rdoc
  2% [25/871]  ...by2.5-TpDw3s/ruby2.5-2.5.1/doc/syntax/control_expressions.rdoc
  2% [26/871]  /<>/doc/syntax/exceptions.rdoc
  3% [27/871]  /<>/doc/syntax/literals.rdoc
  3% [28/871]  /<>/doc/syntax/methods.rdoc
  3% [29/871]  /<>/doc/syntax/miscellaneous.rdoc
  3% [30/871]  ...by2.5-TpDw3s/ruby2.5-2.5.1/doc/syntax/modules_and_classes.rdoc
  3% [31/871]  /<>/doc/syntax/precedence.rdoc
  3% [32/871]  /<>/doc/syntax/refinements.rdoc
  3% [33/871]  NEWS
  3% [34/871]  README.ja.md
  4% [35/871]  README.md
  4% [36/871]  addr2line.c
  4% [37/871]  array.c
  4% [38/871]  bignum.c
  4% [39/871]  class.c
  4% [40/871]  compar.c
  4% [41/871]  compile.c
  4% [42/871]  complex.c
  4% [43/871]  cont.c
  5% [44/871]  debug.c
  5% [45/871]  debug_counter.c
  5% [46/871]  dir.c
  5% [47/871]  dln.c
  5% [48/871]  dln_find.c
  5% [49/871]  dmydln.c
  5% [50/871]  dmyenc.c
  5% [51/871]  dmyext.c
  5% [52/871]  doc/NEWS-1.8.7
  6% [53/871]  doc/NEWS-1.9.1
  6% [54/871]  doc/NEWS-1.9.2
  6% [55/871]  doc/NEWS-1.9.3
  6% [56/871]  doc/NEWS-2.0.0
  6% [57/871]  doc/NEWS-2.1.0
  6% [58/871]  doc/NEWS-2.2.0
  6% [59/871]  doc/NEWS-2.3.0
  6% [60/871]  doc/NEWS-2.4.0
  7% [61/871]  doc/contributing.rdoc
  7% [62/871]  doc/contributors.rdoc
  7% [63/871]  doc/dtrace_probes.rdoc
  7% [64/871]  doc/extension.ja.rdoc
  7% [65/871]  doc/extension.rdoc
  7% [66/871]  doc/globals.rdoc
  7% [67/871]  doc/keywords.rdoc
  7% [68/871]  

Bug#693219: Bug#826709: Doesn't mention --foreign in help output

[Paul Wise]

CCing the maintainer of arch-test who will probably have some input.

On Sun, 2018-04-01 at 11:32 +0900, Hideki Yamane wrote:

> +   if [ "$HOST_ARCH" = "amd64" ] && [ "$ARCH" = "i386" ] ; then
> +   # i386 binary can be run on amd64 host

It is a bad idea to hard-code this and hard-code it for only two
arches, using arch-test and falling back to a more comprehensive list
would be much better, as I suggested in my initial bug report:

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=826709#5

> +   error 1 WHATARCH "Tried to run on different 
> architecture in chroot environment.\n   Use --foreign or --second-stage 
> option, instead"

I prefer the message I wrote in my initial bug report:

  This machine cannot run binaries for architecture armhf
  There are two options to work around this:

  Use qemu-debootstrap instead of debootstrap

  Use debootstrap --foreign here and
  use debootstrap --second-stage on armhf

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=826709#5

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


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

Bug#894535: sendmail: Typo in apt show sendmail

[annadane]

Package: sendmail
Version: 8.15.2-8
Severity: minor

Dear Maintainer,

Paragraph "Fortunately, simple thing can be done easily, and complex things
 are possible, even if not easily understood ;)  Sendmail is the *ONLY*
 MTA with a Turing complete language to control *ALL* aspects of delivery!"

"Thing" should read "things"

-- Package-specific info:
Output of /usr/share/bug/sendmail/script:

ls -alR /etc/mail:
/etc/mail:
total 236
drwxr-sr-x   7 smmta smmsp  4096 Mar 29 12:27 .
drwxr-xr-x 128 root  root  12288 Mar 31 23:22 ..
-rwxr-xr--   1 root  smmsp 10019 Mar 29 12:26 Makefile
-rw---   1 root  root   4265 Mar 29 12:26 access
-rw-r-   1 smmta smmsp 12288 Mar 29 12:26 access.db
-rw-r--r--   1 root  root281 Dec  8  2016 address.resolve
lrwxrwxrwx   1 root  smmsp10 Mar 29 12:26 aliases -> ../aliases
-rw-r-   1 smmta smmsp 12288 Mar 29 12:27 aliases.db
-rw-r--r--   1 root  root   3219 Mar 29 12:26 databases
-rw-r--r--   1 root  root   5659 Dec  8  2016 helpfile
-rw-r--r--   1 root  smmsp17 Mar 29 12:26 local-host-names
drwxr-sr-x   2 smmta smmsp  4096 Mar 29 12:26 m4
drwxr-xr-x   2 root  root   4096 Mar 29 12:26 peers
drwxr-xr-x   2 root  smmsp  4096 Dec  8  2016 sasl
-rw-r--r--   1 root  smmsp 64154 Mar 29 12:26 sendmail.cf
-rw-r--r--   1 root  root  12236 Mar 29 12:26 sendmail.conf
-rw-r--r--   1 root  smmsp  4058 Mar 29 12:26 sendmail.mc
-rw-r--r--   1 root  root149 Dec  8  2016 service.switch
-rw-r--r--   1 root  root180 Dec  8  2016 service.switch-nodns
drwxr-sr-x   2 smmta smmsp  4096 Mar 29 12:26 smrsh
-rw-r--r--   1 root  smmsp 44594 Mar 29 12:26 submit.cf
-rw-r--r--   1 root  smmsp  2374 Mar 29 12:26 submit.mc
drwxr-xr-x   2 smmta smmsp  4096 Mar 29 12:26 tls
-rw-r--r--   1 root  smmsp 0 Mar 29 12:26 trusted-users

/etc/mail/m4:
total 8
drwxr-sr-x 2 smmta smmsp 4096 Mar 29 12:26 .
drwxr-sr-x 7 smmta smmsp 4096 Mar 29 12:27 ..
-rw-r- 1 root  smmsp0 Mar 29 12:26 dialup.m4
-rw-r- 1 root  smmsp0 Mar 29 12:26 provider.m4

/etc/mail/peers:
total 12
drwxr-xr-x 2 root  root  4096 Mar 29 12:26 .
drwxr-sr-x 7 smmta smmsp 4096 Mar 29 12:27 ..
-rw-r--r-- 1 root  root   328 Dec  8  2016 provider

/etc/mail/sasl:
total 8
drwxr-xr-x 2 root  smmsp 4096 Dec  8  2016 .
drwxr-sr-x 7 smmta smmsp 4096 Mar 29 12:27 ..

/etc/mail/smrsh:
total 8
drwxr-sr-x 2 smmta smmsp 4096 Mar 29 12:26 .
drwxr-sr-x 7 smmta smmsp 4096 Mar 29 12:27 ..
lrwxrwxrwx 1 root  smmsp   26 Mar 29 12:26 mail.local -> 
/usr/lib/sm.bin/mail.local
lrwxrwxrwx 1 root  smmsp   17 Mar 29 12:26 procmail -> /usr/bin/procmail

/etc/mail/tls:
total 48
drwxr-xr-x 2 smmta smmsp 4096 Mar 29 12:26 .
drwxr-sr-x 7 smmta smmsp 4096 Mar 29 12:27 ..
-rw-r--r-- 1 root  root 7 Mar 29 12:26 no_prompt
-rw--- 1 root  root  1191 Mar 29 12:26 sendmail-client.cfg
-rw-r--r-- 1 root  smmsp 1176 Mar 29 12:26 sendmail-client.crt
-rw--- 1 root  root   989 Mar 29 12:26 sendmail-client.csr
-rw-r- 1 root  smmsp 1675 Mar 29 12:26 sendmail-common.key
-rw-r- 1 root  smmsp 1650 Mar 29 12:26 sendmail-common.prm
-rw--- 1 root  root  1191 Mar 29 12:26 sendmail-server.cfg
-rw-r--r-- 1 root  smmsp 1176 Mar 29 12:26 sendmail-server.crt
-rw--- 1 root  root   989 Mar 29 12:26 sendmail-server.csr
-rwxr--r-- 1 root  root  3248 Mar 29 12:26 starttls.m4

sendmail.conf:
DAEMON_NETMODE="Static";
DAEMON_NETIF="eth0";
DAEMON_MODE="Daemon";
DAEMON_PARMS="";
DAEMON_HOSTSTATS="No";
DAEMON_MAILSTATS="No";
QUEUE_MODE="${DAEMON_MODE}";
QUEUE_INTERVAL="10m";
QUEUE_PARMS="";
MSP_MODE="Cron";
MSP_INTERVAL="20m";
MSP_PARMS="";
MSP_MAILSTATS="${DAEMON_MAILSTATS}";
MISC_PARMS="";
CRON_MAILTO="root";
CRON_PARMS="";
LOG_CMDS="No";
HANDS_OFF="No";
AGE_DATA="";
DAEMON_RUNASUSER="No";
DAEMON_STATS="${DAEMON_MAILSTATS}";
MSP_STATS="${MSP_MAILSTATS}";


sendmail.mc:
divert(-1)dnl
divert(0)dnl
define(`_USE_ETC_MAIL_')dnl
include(`/usr/share/sendmail/cf/m4/cf.m4')dnl
VERSIONID(`$Id: sendmail.mc, v 8.15.2-8 2016-12-08 18:43:49 cowboy Exp $')
OSTYPE(`debian')dnl
DOMAIN(`debian-mta')dnl
undefine(`confHOST_STATUS_DIRECTORY')dnl#DAEMON_HOSTSTATS=
FEATURE(`no_default_msa')dnl
DAEMON_OPTIONS(`Family=inet,  Name=MTA-v4, Port=smtp, Addr=127.0.0.1')dnl
DAEMON_OPTIONS(`Family=inet,  Name=MSP-v4, Port=submission, M=Ea, 
Addr=127.0.0.1')dnl
define(`confPRIVACY_FLAGS',dnl
`needmailhelo,needexpnhelo,needvrfyhelo,restrictqrun,restrictexpand,nobodyreturn,authwarnings')dnl
define(`confCONNECTION_RATE_THROTTLE', `15')dnl
define(`confCONNECTION_RATE_WINDOW_SIZE',`10m')dnl
FEATURE(`use_cw_file')dnl
FEATURE(`access_db', , `skip')dnl
FEATURE(`greet_pause', `1000')dnl 1 seconds
FEATURE(`delay_checks', `friend', `n')dnl
define(`confBAD_RCPT_THROTTLE',`3')dnl
FEATURE(`conncontrol', `nodelay', `terminate')dnl
FEATURE(`ratecontrol', `nodelay', `terminate')dnl
include(`/etc/mail/m4/dialup.m4')dnl
include(`/etc/mail/m4/provider.m4')dnl
MAILER_DEFINITIONS
MAILER(`local')dnl
MAILER(`smtp')dnl

submit.mc...
divert(-1)dnl
divert(0)dnl
define(`_USE_ETC_MAIL_')dnl

Bug#894534: smartmontools: package still contains update-smart-drivedb(8)

[Christoph Anton Mitterer]

Package: smartmontools
Version: 6.5+svn4324-1
Severity: minor


Hi.

The package still contains the manpage to update-smart-drivedb.

Perhaps it makes sense to drop it as well.


Cheers,
Chris.

Bug#887709: shared-mime-info: misidentifies .html file as Perl script when it contains JavaScript "use strict"

[Dwayne Litzenberger]

tags 887709 + patch upstream
forwarded 887709 https://bugs.freedesktop.org/show_bug.cgi?id=105838
thanks

I just attached a patch to fix this, and also filed an upstream bug 
report about it.
>From 5c9dc4f8309905e557b898d1ec5c5adfdc5c322e Mon Sep 17 00:00:00 2001
From: Dwayne Litzenberger 
Date: Sat, 31 Mar 2018 19:24:58 -0700
Subject: [PATCH] Perl detection: Don't match ECMAScript "use strict" syntax

https://bugs.freedesktop.org/show_bug.cgi?id=105838
---
 freedesktop.org.xml.in   |  5 -
 tests/js-use-strict.html | 20 
 tests/js-use-strict.js   |  9 +
 tests/list   |  6 ++
 4 files changed, 39 insertions(+), 1 deletion(-)
 create mode 100644 tests/js-use-strict.html
 create mode 100644 tests/js-use-strict.js

diff --git a/freedesktop.org.xml.in b/freedesktop.org.xml.in
index 72c41d6..9c53352 100644
--- a/freedesktop.org.xml.in
+++ b/freedesktop.org.xml.in
@@ -3287,7 +3287,10 @@ command to generate the output files.
   
   
   
-  
+  
+  
+  
   
   
   
diff --git a/tests/js-use-strict.html b/tests/js-use-strict.html
new file mode 100644
index 000..648a508
--- /dev/null
+++ b/tests/js-use-strict.html
@@ -0,0 +1,20 @@
+
+
+  
+
+
+  function f() {
+"use strict";
+return true;
+  }
+  function g() {
+'use strict';
+return true;
+  }
+
+Test
+  
+  
+Test
+  
+
diff --git a/tests/js-use-strict.js b/tests/js-use-strict.js
new file mode 100644
index 000..1c14f94
--- /dev/null
+++ b/tests/js-use-strict.js
@@ -0,0 +1,9 @@
+
+function f() {
+  "use strict";
+  return true;
+}
+function g() {
+  'use strict';
+  return true;
+}
diff --git a/tests/list b/tests/list
index 269c50a..7497588 100644
--- a/tests/list
+++ b/tests/list
@@ -337,6 +337,12 @@ pyside.py text/x-python
 test.pl application/x-perl
 test.pm application/x-perl
 test.t application/x-perl
+# Not Perl
+# https://bugs.freedesktop.org/show_bug.cgi?id=63612
+js-use-strict.html application/x-perl xxx
+js-use-strict.html text/html
+js-use-strict.js application/x-perl xxx
+js-use-strict.js application/javascript ox
 # Copied from http://en.wikipedia.org/wiki/Turtle_%28syntax%29#Example
 test.ttl text/turtle ox
 # Twig template
-- 
2.16.3

Bug#894417: closed by Adam Borowski <kilob...@angband.pl> (Re: Bug#894417: RFS: dde-calendar/1.2.2-1)

[Yanhao Mo]

On Sun 04/01 00:00, Debian Bug Tracking System wrote:
> Those mysterious "Some Bug Fixes" are in the upstream release; these are
> usually skipped unless somehow related to the packages or reported to the
> BTS.  This line makes no sense.

Got it! I'll use it more properly next time.

-- 
Yanhao Mo


signature.asc
Description: PGP signature

Bug#894464: closed by Adam Borowski <kilob...@angband.pl> (Re: Bug#894464: RFS: deepin-picker/1.6.2-1)

[Yanhao Mo]

On Sat 03/31 23:03, Debian Bug Tracking System wrote:
> Hi!
> You didn't mention that you added yourself to Uploaders, and there's a typo
> ("Swithch" -> "Switch"), but none of these matter enough for another
> round-trip.  Uploaded.

Thanks for the uploading and sorry for my mistakes, I will do more
checks to avoid them next time :P.

-- 
Yanhao Mo


signature.asc
Description: PGP signature

Bug#894517: rapid-photo-downloader: Thumbnails are no longer created

[Damon Lynch]

The problem is not in Rapid Photo Downloader. The problem is the
incompatibility of python3-tornado 5.0 with python3-zmq 16.0.2.

Tornado 5.0 is very new.

-- 
http://www.damonlynch.net

Bug#892883: mirrors: Debian mirror opensource.nchc.org.tw: add as candidate of ftp.tw

[Steven Shiau]

On 2018/03/30 22:05, Bastian Blank wrote:
>
> I selected syncproxy2.wna.debian.org as upstream.  Please add to your
> ssh authorized keys:
>
> command="~/bin/ftpsync",no-port-forwarding,no-X11-forwarding,no-agent-forwarding,no-pty
>  ssh-rsa 
> B3NzaC1yc2EDAQABAAABAQD3fIOsSwQYFV7XunlnIwAIIBDUqctbpIkjtYUwCduOomWOc1HyZGDUzA7l3B4ckkTfX3JTxA9avOZT0SC3+a1IPklvEQwv5jgXARFW7eMwTL0nnTyyb9v1kIctdk/YFkiURKoI3tTR6WiT4neVdiAsbPVwpcDmhFX3xIbaPwCTxFEXS2lIXmL9wq4VWmKMRu7Hwjf86xlkfmKpfkwqnu4toyeahdAIu1zPHb4DYCRWcmh65qj6y19PDS/k6Ji1H5I7zZ7qGRaRrd8LH/NN1TSmJ6hIwzohCjUWrXmnGOMrwgdwTOIoJGe+hv5pObhLETSfSU+JrMdgboKkr37uX3hL
>  archvs...@syncproxy2.wna.debian.org (aka mirror-isc.debian.org; 2015-12-06)
>
> I can't connect to ssh on this host, please make sure it is reachable at
> least from the above mentioned host.  Please provide us with the
> username to use.
>
> I'll provide you with the rsync access infos later.
>
> Regards,
> Bastian
>
Thanks to Bastian. We finally made it. Now the push trigger is done, and
the upstream for opensource.nchc.org.tw is syncproxy2.wna.debian.org,
aka mirror-isc.debian.org:
https://mirror-master.debian.org/status/mirror-status.html#[results]=0-0[results]=opensource.nchc.org.tw
https://mirror-master.debian.org/status/mirror-info/opensource.nchc.org.tw.html

If everything is OK, when opensource.nchc.org.tw is added as
ftp.tw.debian.org. this bug can be closed.
Thank you very much.

Steven

-- 
Steven Shiau 
Public Key Server PGP Key ID: 4096R/163E3FB0
Fingerprint: EB1D D5BF 6F88 820B BCF5  356C 8E94 C9CD 163E 3FB0

Bug#881773: Info received (ruby2.5: FTBFS on hppa: recursive once test fails)

[John David Anglin]

This is also the reason that the ruby-rblineprof build fails.

--

John David Anglin  dave.ang...@bell.net

Bug#894282: openssl: Missing quotes in c_rehash

[Tim]

This also affects the build currently in experimental. Which is breaking 
my experimental sbuild chroots. Can the patch be uploaded there also.

Bug#894272: Gitlab: Bug#894272: Some problems fixed.

[Er_Maqui]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256


Hi,

After latest updates (Including gitlab-workhorse), login page are working
now.

I've recovered the old database and repositories now. Gitlab detected it
and it's working.

I have two problems now.

First:
Gitlab API is not working. Error 401:

Running /usr/share/gitlab-shell/bin/check
Check GitLab API access: FAILED. code: 401
gitlab-shell self-check failed
  Try fixing it:
  Make sure GitLab is running;
  Check the gitlab-shell configuration file:
  sudo -u gitlab -H editor /usr/share/gitlab-shell/config.yml
  Please fix the error above and rerun the checks.

gitlab-shell error log:
I, [2018-04-01T01:42:02.543546 #30418]  INFO -- : GET
http://localhost:8080/api/v4/internal/check 0.06425
E, [2018-04-01T01:42:02.573128 #30418] ERROR -- : API call http://localhost:8080/api/v4/internal/check> failed: 401 =>
<{"message":"401 Unauthorized"}>.

gitlab production.log:
Started GET "/api/v4/internal/check" for 127.0.0.1 at 2018-04-01 01:42:02
+0200


Second:
Gitlab interfaces got an error viewing repository: On Overview -> Details
page:
message: "Error loading viewer".

production.log:

Started GET "/repository" for x.x.x.x at 2018-04-01 01:31:03 +0200
Completed 200 OK in 225ms (Views: 184.2ms | ActiveRecord: 17.2ms)
Started GET "/repository/blob/master/README.md?format=json=rich" for
x.x.x.x at 2018-04-01 01:31:05 +0200
Started GET "/repository/refs/master/logs_tree/?format=js" for x.x.x.x at
2018-04-01 01:31:05 +0200
Processing by Projects::BlobController#show as JSON
Processing by Projects::RefsController#logs_tree as JS
Completed 500 Internal Server Error in 69ms (ActiveRecord: 2.0ms)

ActionView::Template::Error (undefined method `html_escape' for
#
Did you mean?  html_safe?):
1: - blob = viewer.blob
2: - rendered_markup = blob.rendered_markup if
blob.respond_to?(:rendered_markup)
3: .file-content.wiki
4:   = markup(blob.name, blob.data, rendered: rendered_markup)
  lib/banzai/renderer/redcarpet/html.rb:9:in `block_code'
  lib/banzai/filter/markdown_engines/redcarpet.rb:27:in `render'
  lib/banzai/filter/markdown_engines/redcarpet.rb:27:in `render'
  lib/banzai/filter/markdown_filter.rb:12:in `call'
  lib/banzai/pipeline/base_pipeline.rb:21:in `block (2 levels) in singleton
class'
  lib/banzai/renderer.rb:108:in `render_result'
  lib/banzai/renderer.rb:139:in `block in cacheless_render'
  lib/gitlab/metrics/influx_db.rb:98:in `measure'
  lib/banzai/renderer.rb:138:in `cacheless_render'
  lib/banzai/renderer.rb:28:in `render'
  lib/banzai.rb:3:in `render'
  app/helpers/markup_helper.rb:244:in `markdown_unsafe'
  app/helpers/markup_helper.rb:143:in `markup_unsafe'
  app/helpers/markup_helper.rb:110:in `markup'
  app/views/projects/blob/viewers/_markup.html.haml:4:in
`_app_views_projects_blob_viewers__markup_html_haml__60150874817435_3348073215480'
  app/views/projects/blob/_viewer.html.haml:20:in
`_app_views_projects_blob__viewer_html_haml__3018189872610422686_3348073432260'
  app/controllers/application_controller.rb:252:in `view_to_html_string'
  app/controllers/concerns/renders_blob.rb:18:in `blob_json'
  app/controllers/projects/blob_controller.rb:200:in `show_json'
  app/controllers/projects/blob_controller.rb:47:in `block (2 levels) in
show'
  app/controllers/projects/blob_controller.rb:39:in `show'
  lib/gitlab/i18n.rb:50:in `with_locale'
  lib/gitlab/i18n.rb:56:in `with_user_locale'
  app/controllers/application_controller.rb:330:in `set_locale'
  lib/gitlab/middleware/multipart.rb:95:in `call'
  lib/gitlab/request_profiler/middleware.rb:14:in `call'
  lib/gitlab/middleware/go.rb:17:in `call'
  lib/gitlab/etag_caching/middleware.rb:11:in `call'
  lib/gitlab/middleware/read_only/controller.rb:28:in `call'
  lib/gitlab/middleware/read_only.rb:16:in `call'
  lib/gitlab/request_context.rb:18:in `call'
  lib/gitlab/metrics/requests_rack_middleware.rb:27:in `call'
  lib/gitlab/middleware/release_env.rb:10:in `call'


On gitlab interface, I cannot view readme.md file.
Also, on commits list, I see this error:
message: An error ocurred while loading commits.

Production.log:
Completed 500 Internal Server Error in 760ms (ActiveRecord: 45.2ms)

ActiveRecord::StatementInvalid (PG::CharacterNotInRepertoire: ERROR:
invalid byte sequence for encoding "UTF8": 0xf3 0x70 0x65 0x7a
: INSERT INTO "gpg_signatures" ("gpg_key_primary_keyid", "commit_sha",
"project_id", "gpg_key_id", "gpg_key_user_name", "gpg_key_user_email",
"verification_status", "created_at", "updated_at") VALUES ($1, $2, $3, $4,
$5, $6, $7, $8, $9) RETURNING "id"):
  config/initializers/active_record_locking.rb:12:in `_create_record'
  lib/gitlab/gpg/commit.rb:78:in `block in create_cached_signature!'
  lib/gitlab/gpg/commit.rb:65:in `block in using_keychain'
  lib/gitlab/gpg.rb:89:in `optimistic_using_tmp_keychain'
  lib/gitlab/gpg.rb:71:in `block in using_tmp_keychain'
  lib/gitlab/gpg.rb:70:in `synchronize'
  lib/gitlab/gpg.rb:70:in `using_tmp_keychain'
  

Bug#894533: cookiecutter: Depends on pytest-catchlog (in removal process)

[Hugo Lefeuvre]

Package: cookiecutter
Version: 1.6.0-1

Dear cookiecutter maintainer,

cookiecutter currently build-depends on python{3,}-pytest-catchlog.
This is most likely a mistake, since pytest-catchlog has been merged
into the pytest core and is consequently going to be removed from
unstable in a near future.

I can NMU if needed.

See #892633[0] for more information.

Thanks.

Regards,
 Hugo

[0] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=892633

-- 
 Hugo Lefeuvre (hle)|www.owl.eu.com
4096/ 9C4F C8BF A4B0 8FC5 48EB 56B8 1962 765B B9A8 BACA


signature.asc
Description: PGP signature

Bug#892633: pytest-catchlog FTBFS with pytest 3.3.2-2

[Hugo Lefeuvre]

Upstream replied:

> Like the note in the output says:
>   pytest-catchlog plugin has been merged into the core, please remove it from 
> your requirements.
> So if you ship pytest 3.3.2, there's probably no reason to have a 
> pytest-catchlog package.

So, I guess the pytest-catchlog package has no reasons of existing in
unstable since we ship pytest 3.3.2, and we should let it get removed
from unstable. Also, removing pytest-catchlog from the dependencies of
your package should be fine.

Cheers,
 Hugo

-- 
 Hugo Lefeuvre (hle)|www.owl.eu.com
4096/ 9C4F C8BF A4B0 8FC5 48EB 56B8 1962 765B B9A8 BACA


signature.asc
Description: PGP signature

Bug#894532: node-d3-format: Duplicates exisitng node-d3-format binary package

[Jeremy Bicha]

Source: node-d3-format
Version: 1.2.0-3
Severity: serious
X-Debbugs-CC: d3-for...@packages.debian.org

The node-d3-format produces a binary package names node-d3-format, but
Debian already has a node-d3-format produced by source d3-format. In
fact, the d3-format version has an epoch so apt prefers it instead.

See 
https://anonscm.debian.org/cgit/pkg-javascript/d3-format.git/commit/?id=93ea4118

Please resolve this issue.

Thanks,
Jeremy Bicha

Bug#894530: run-parts.8: Some tidying of the manual

[Bjarni Ingi Gislason]

Package: debianutils
Version: 4.8.4
Severity: minor
Tags: patch

Dear Maintainer,


Test nr. 12:

Change -- in x--y to \(em (em-dash), or, if an
option, to \-\-

55:but don't actually run them. This option cannot be used with --test.
95:.B --arg

#

Test nr. 27:

Split lines longer than 80 characters into two or more lines.
Apropriate break points are the end of a sentence and a subordinate
clause.

run-parts.8: line 63length 157

#

Test nr. 28:

Wrong distance between sentences or protect the indicator.

1) Separate the sentences and subordinate clauses; each begins on a new
line.  See man-pages(7) and "info groff".

Or

2) Adjust space between sentences (two spaces),

3) or protect the indicator by adding "\&" after it.

The "indicator" is an "end-of-sentence character" (.!?).

55:but don't actually run them. This option cannot be used with --test.

#

Test nr. 30:

Surround a block of comments with the macros ".ig" and "..".
The .\" (\#) at the beginning of each line is then not needed.
Makes it easier to add and remove text and adjust lengtxh of lines.

NO PATCH

1:.\" Hey, Emacs!  This is an -*- nroff -*- source file.
2:.\" Build-from-directory and this manpage are Copyright 1994 by Ian Jackson.
3:.\" Changes to this manpage are Copyright 1996 by Jeff Noxon.
4:.\" More
5:.\"
6:.\" This is free software; see the GNU General Public Licence version 2
7:.\" or later for copying conditions.  There is NO warranty.

#

--- run-parts.8 2018-03-31 00:23:35.0 +
+++ run-parts.8.new 2018-03-31 00:33:26.0 +
@@ -52,7 +52,8 @@ them.
 .TP
 .B \-\-list
 print the names of the all matching files (not limited to executables),
-but don't actually run them. This option cannot be used with --test.
+but don't actually run them.
+This option cannot be used with \-\-test.
 .TP
 .B \-v, \-\-verbose
 print the name of each script to stderr before running.
@@ -60,7 +61,9 @@ print the name of each script to stderr
 .B \-\-report
 similar to
 .BR \-\-verbose ,
-but only prints the name of scripts which produce output.  The script's name 
is printed to whichever of stdout or stderr the script first produces output on.
+but only prints the name of scripts which produce output.
+The script's name is printed to whichever of stdout or stderr the
+script first produces output on.
 .TP
 .B \-\-reverse
 reverse the scripts' execution order.
@@ -92,7 +95,7 @@ should be specified in octal.  By defaul
 pass
 .I argument
 to the scripts.  Use
-.B --arg
+.B \-\-arg
 once for each argument you want passed.
 .TP
 .B "\-\-"


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

Kernel: Linux 4.9.80-2 (SMP w/2 CPU cores)
Locale: LANG=is_IS.iso88591, LC_CTYPE=is_IS.iso88591 (charmap=ISO-8859-1), 
LANGUAGE=is_IS.iso88591 (charmap=ISO-8859-1)
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)

Versions of packages debianutils depends on:
ii  libc6  2.27-2

debianutils recommends no packages.

debianutils suggests no packages.

-- no debconf information

-- 
Bjarni I. Gislason

Bug#892857: stretch-pu: package r-cran-mi/1.0-4+deb9u1

[Adam D. Barratt]

Control: tags -1 + pending

On Sun, 2018-04-01 at 01:37 +0300, Adrian Bunk wrote:
> Control: tags -1 - moreinfo
> 
> On Sat, Mar 31, 2018 at 10:41:42PM +0100, Adam D. Barratt wrote:
> > Control: tags -1 + moreinfo
> > 
> > On Tue, 2018-03-13 at 22:03 +0200, Adrian Bunk wrote:
> > >    * Add the missing dependency on r-cran-arm. (Closes: #877433)
> > 
> > -Depends: ${R:Depends}, ${misc:Depends}
> > +Depends: ${R:Depends}, ${misc:Depends}, r-cran-arm
> > 
> > Is it not possible for this to get picked up automagically, rather
> > than
> > hardcoding the binary dependency?
> 
> It is possible, and that is how it got solved in unstable.
> 
> It is a cdbs -> dh-r conversion, and hardcoding the dependency
> has a lower regression risk.
> 

I was hoping / assuming that's part of what ${R:Depends} was for.

Please go ahead.

Regards,

Adam

Bug#894313: etherape: Crashes on startup

[John Scott]

Package: etherape
Version: 0.9.16-1
Followup-For: Bug #894313

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

I am able to reproduce this issue, but installing libgnomeui-0
(which provides libgnome.so) fixes it for me. Like the upstream
report suggests, this looks like a missing dependency.

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

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

Versions of packages etherape depends on:
ii  etherape-data0.9.16-1
ii  libart-2.0-2 2.3.21-3
ii  libatk1.0-0  2.28.1-1
ii  libc-ares2   1.14.0-1
ii  libc62.27-2
ii  libcairo21.15.10-1
ii  libfontconfig1   2.12.6-0.1
ii  libfreetype6 2.8.1-2
ii  libgdk-pixbuf2.0-0   2.36.11-2
ii  libglade2-0  1:2.6.4-2+b1
ii  libglib2.0-0 2.56.0-4
ii  libgnomecanvas2-02.30.3-3
ii  libgtk2.0-0  2.24.32-1
ii  libpango-1.0-0   1.42.0-1
ii  libpangocairo-1.0-0  1.42.0-1
ii  libpangoft2-1.0-01.42.0-1
ii  libpcap0.8   1.8.1-6
ii  libpopt0 1.16-10+b2
ii  libxml2  2.9.4+dfsg1-6.1

etherape recommends no packages.

etherape suggests no packages.

- -- no debconf information

-BEGIN PGP SIGNATURE-

iQFGBAEBCgAwFiEEJwCMxdBfG24Y2trvfWFEpid5MHIFAlrAD0ASHGpzY290dEBw
b3N0ZW8ubmV0AAoJEH1hRKYneTBy0L0H/0M8r1h/xu7VYeNDoAgbRlZpVFHTIAbL
/oPwqt048gnKAn4Mngfd66gIfCJ437IK4g0RLHCLp3Ysn3kF9cA5uHPhPVVOnW4A
eHbDuvxUB4AVP0xRTbm1xspWiukxS6Wiukr+YeyiLq9OA3ZAcKaAUedv5K7SsuzL
DcYjSVZ4TmZxcToTpxxv5UktPot1qARSyeTP7/pwIEHO8lZxn8hQYuzmYGsZyyJW
CH1j1Q/+nBPMXwtmX7TDG49HtSXoyaNgxDY8baTIFsgEJmLm34nWqDbmExHjqzL+
tRDsQqShmLmwzArPSBQJ23yGvIWNdVfzVfG0OuRq04qxt2mt3bvBzZI=
=M1mF
-END PGP SIGNATURE-

Bug#892857: stretch-pu: package r-cran-mi/1.0-4+deb9u1

[Adrian Bunk]

Control: tags -1 - moreinfo

On Sat, Mar 31, 2018 at 10:41:42PM +0100, Adam D. Barratt wrote:
> Control: tags -1 + moreinfo
> 
> On Tue, 2018-03-13 at 22:03 +0200, Adrian Bunk wrote:
> >    * Add the missing dependency on r-cran-arm. (Closes: #877433)
> 
> -Depends: ${R:Depends}, ${misc:Depends}
> +Depends: ${R:Depends}, ${misc:Depends}, r-cran-arm
> 
> Is it not possible for this to get picked up automagically, rather than
> hardcoding the binary dependency?

It is possible, and that is how it got solved in unstable.

It is a cdbs -> dh-r conversion, and hardcoding the dependency
has a lower regression risk.

> Regards,
> 
> Adam

cu
Adrian

-- 

   "Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
   "Only a promise," Lao Er said.
   Pearl S. Buck - Dragon Seed

Bug#893377: RFS: taptempo/1.2.1-1 [ITP]

[François Mazen]

Hi,

I've chosen to create a separate repo for packaging:
https://git.tuxfamily.org/taptempo/taptempo_deb_packaging.git

and I will soon remove the debian folder in the upstream repository.

> 0. This program seems to be a terminal bpm meter. I'm not quite good
> at music stuff, so I'd like to make sure:
> 0.1  For what purpose can this program be used?
> 0.2  Who's the targeted people of this program?

This program is useful to quickly find the tempo of a song.
The idea is to type "taptempo" in a terminal, then hit enter key at
each beat while hearing a song, and display the tempo.

The targeted people are mainly musicians who need to transcribe music
or play the song at the exact original tempo. The typical situation to
use this software is when you are in a hurry and you don't have time to
launch a big workstation like Ardour or Lmms in order to find the
tempo.


> 8. When you have built the latest version of the modified package,
> you could run lintian against it:
> 
> lintian -EviI --pedantic .changes
> 
> There generally shouldn't be any Error or Warning.

I've fixed all the error and the lintian output should be clean.

Let me know if it still require more work.

Should I update this new package to the mentors website?

Thanks,
François






Le mardi 27 mars 2018 à 07:05 +, Lumin a écrit :
> Hi François,
> 
> On 26 March 2018 at 19:56, François Mazen  wrote:
> > I've manually changed the timestamp of the changelog file from the
> > original repo, and I haven't check that the date was wrong. I can
> > update the changelog file.
> 
> I've seen new commits in the repo. Let's assume it's the latest
> version
> we would talk about. The following discussion will be based on
> https://github.com/moleculext/taptempo
> 
> > The public key is published on the sks-keyservers network. Should I
> > sent it to debian keyring or other keyserver?
> 
> I can retrieve the key now.
> 
> > Should I submit a new revision of the package (1.2.1-2) or re-
> > upload
> > with the current revision number (1.2.1-1)?
> 
> Not necessary. Further changes are needed, I'll check the git repo
> directly since there is delay for mentor uploads.
> 
> Here are a list of problems I have found:
> 
> 0. This program seems to be a terminal bpm meter. I'm not quite good
> at music stuff, so I'd like to make sure:
> 0.1  For what purpose can this program be used?
> 0.2  Who's the targeted people of this program?
> 
> 1. Upstream source should not contain a "debian" directory. However,
> you seem to be the upstream author, so you have two choices:
> (a) remove debian directory from source, and create another
> packaging
>  repo where the debian directory is tracked.
> (b) change source/format to 3.0 (naitive). In this way you can
> keep
>  the debian directory in upstream source.
> 
> 2. The standards version is quite out of date. You could lookup the
> update
> checklist of Debian Policy[2], and update the standards version
> to the
> latest one (version 4.1.3).
> 
> 3. Debhelper compatibility version is old. Version 11 is preferred.
> 
> 4. control: the long discription is somewhat short. Could you please
> explain a bit more about the program's purpose and functionality?
> 
> 5. changelog: It should close the ITP bug you've submitted. e.g.
> Close: #XXX
> 
> 6. control: I'd recommend to add the Vcs-Git and Vcs-Browser field
> which
> point to the packaging repository. And add a homepage which
> points
> to the upstream homepage or simply the upstream repo.
> 
> 7. Hardening flags[3] should be added to rules. i.e.
> export DEB_BUILD_MAINT_OPTIONS   = hardening=+all
> 
> 8. When you have built the latest version of the modified package,
> you could run lintian against it:
> 
> lintian -EviI --pedantic .changes
> 
> There generally shouldn't be any Error or Warning.
> 
> 9. changelog: please keep the version number aligned with upstream
> version.
> or thing may get into a mess.
> 
> I'll check the git repo again once you have updated it. If you have
> any
> questions about the above points, just feel free to ask
> 
> [1] https://www.debian.org/doc/manuals/maint-guide/index.en.html
> [2] https://www.debian.org/doc/debian-policy/
> [3] https://wiki.debian.org/Hardening
> 

Bug#677224: wicd-gtk tray icon status always says "Not connected", able to reproduce?

[Riccardo Stagni]

I had to install python-appindicator to show the wicd-gtk tray icon in the
recently-updated enlightenment environment (#894529).
The tray icon stays not connected (exclamation mark in a black-bordered
triangle) even if I am connected.

Sooo, to reproduce:

root@hactar:~# LANG=C dpkg -l *wicd* *appindicator* *enlightenment*
Desired=Unknown/Install/Remove/Purge/Hold
| Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend
|/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad)
||/ Name   Version  Architecture 
Description
+++-==---=
ii  enlightenment  0.22.1-3 amd64
X11 window manager based on EFL
ii  enlightenment-data 0.22.1-3 all  
X11 window manager based on EFL - run time data files
ii  libappindicator1:amd64 0.4.92-5 amd64
allow applications to export a menu into the panel
ii  libayatana-appindicator3-1 0.5.3-3  amd64
Ayatana Application Indicators (GTK-3+ version)
ii  python-appindicator0.4.92-5 amd64
Python bindings for libappindicator
ii  python-wicd1.7.4+tb2-5  all  
wired and wireless network manager - Python module
un  python2.7-appindicator   
(no description available)
ii  wicd   1.7.4+tb2-5  all  
wired and wireless network manager - metapackage
un  wicd-cli 
(no description available)
un  wicd-client  
(no description available)
un  wicd-curses  
(no description available)
ii  wicd-daemon1.7.4+tb2-5  all  
wired and wireless network manager - daemon
ii  wicd-gtk   1.7.4+tb2-5  all  
wired and wireless network manager - GTK+ client

The tray icon used to work with the old enlightenment version (e17), without
appindicator (xembed support?)


Thanks for your work,
Riccardo

Bug#894529: wicd-gtk tray icon not showing anymore in enlightenment (missing appindicator dependency)

[Riccardo Stagni]

Package: wicd-gtk
Version: 1.7.4+tb2-5
Severity: normal

Hi,
I just updated my window manager (enlightenment) and the wicd-gtk tray icon was
not showing anymore.
It seems around e20 they stopped providing the xembed tray-system support in
favour of appindicator.

Could you please add python-appindicator as depends/raccomends for wicd-gtk?
(then I think I can reproduce #677224, but at least I have some icon to click 
on) :)

Thanks for maintaining wicd!
Riccardo

Bug#894525: linux: computer frozen on "reboot: power down" on power off

[Ben Hutchings]

Control: tag -1 - patch
Control: tag -1 moreinfo

On Sat, 2018-03-31 at 20:53 +0200, Alberto Fuentes wrote:
> Source: linux
> Severity: normal
> Tags: patch
> 
> 60% of the times, the computer refuses to power off
> 
> It stays in a blank screen that says
> 
> "[ 935.342345413 ] reboot: power down"
> I made it work adding reboot=b to /etc/default/grub as specified in
> 
> https://askubuntu.com/questions/7114/why-cant-i-restart-shutdown
[...]

We can't help you if you don't identify what "the computer" is.
Please send the output of:

grep . /sys/devices/virtual/dmi/id/{bios,board,product}*

Ben.

-- 
Ben Hutchings
Horngren's Observation:
  Among economists, the real world is often a special case.


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

Bug#894379: coreutils: timeout (hurd, possibly hppa): fails to detect that a program has exited

[Pádraig Brady]

On 29/03/18 08:31, Eugene V. Lyubimkin wrote:
> Package: coreutils
> Version: 8.28-1
> Severity: normal
> 
> Control: affects -1 cupt
> 
> 
> Hello,
> 
> Thank you for maintaining coreutils. I use timeout(1) to conveniently
> detect hanging problems in the testsuite of cupt. Unfortunately, on hurd
> and hppa it makes the test suite fail. 
> 
> This issue is best illustrated through a test case:
> 
> On hurd-i386 the commands which take less time to execute still make
> 'timeout' wait full time and exit with the error code:
> --8<-
> $ mkdir abc
> $ cd abc
> $ timeout 5s ls
> $ echo $?
> 124
> $ timeout 5s cat
> $ echo $?
> 124
> -->8-
> 
> On, say, amd64 the same scenario works as expected:
> --8<-
> $ mkdir abc
> $ cd abc
> $ timeout 5s ls
> $ echo $?
> 0
> $ timeout 5s cat
> $ echo $?
> 124
> -->8-
> 
> I couldn't check this scenario on hppa (as there are no porterboxes for
> it), but the bug report #882238 suggests a similar issue has been
> encountered on a hppa buildd box.
> 
> On hurd-i386 portexbox, I did verify that the program run under
> timeout(1) does exit, but timeout(1) itself continues to run even
> though it has no child processes anymore.
> 
> 

There was a bug fixed wrt SIGCHLD in coreutils-8.29

Bug#892857: stretch-pu: package r-cran-mi/1.0-4+deb9u1

[Adam D. Barratt]

Control: tags -1 + moreinfo

On Tue, 2018-03-13 at 22:03 +0200, Adrian Bunk wrote:
>    * Add the missing dependency on r-cran-arm. (Closes: #877433)

-Depends: ${R:Depends}, ${misc:Depends}
+Depends: ${R:Depends}, ${misc:Depends}, r-cran-arm

Is it not possible for this to get picked up automagically, rather than
hardcoding the binary dependency?

Regards,

Adam

Bug#892836: stretch-pu: package email2trac/2.10.0-2~deb9u1

[Adam D. Barratt]

Control: tags -1 + confirmed

On Tue, 2018-03-13 at 16:00 +0200, Adrian Bunk wrote:
>   * Add upstream fix for Trac 1.2. (Closes: #858819)

Please go ahead.

Regards,

Adam

Bug#892940: stretch-pu: package shared-mime-info/1.8-1+deb9u1

[Adam D. Barratt]

Control: tags -1 + confirmed

On Wed, 2018-03-14 at 20:13 +0200, Adrian Bunk wrote:
>   * Switch dpkg trigger to noawait. Closes: #864953.

It would have been helpful to indicate what issue this was solving. (I
realise that the changelog for the unstable upload is equally
unverbose, but there's no requirement to simply re-use them.)

Please go ahead.

Regards,

Adam

Bug#893006: stretch-pu: package boost1.62/1.62.0+dfsg-4+deb9u1

[Adam D. Barratt]

Control: tags -1 + moreinfo

On Thu, 2018-03-15 at 14:51 +0100, Philipp Huebner wrote:
> I would like to fix #883987 in boost1.62 for Stretch.
> The changes are basically the same as what is currently in testing
> and I got the
> maintainer's go-ahead in
> http://lists.alioth.debian.org/pipermail/pkg-boost-devel/2018-March/0
> 04184.html
> 

It's unclear to me that this actually affects stretch in any meaningful
 way.

While the version tracking information does include the stretch version
in the "found" list, the bug is tagged "buster sid". From reading the
bug log, it looks like this is because the issue only occurs when using
 GCC 7, which is not present in stretch.

Regards,

Adam

Bug#893278: stretch-pu: package showq/0.4.1+git20161215~dfsg0-2+deb9u1

[Adam D. Barratt]

Control: tags -1 + confirmed

On Sat, 2018-03-17 at 19:33 +0200, Adrian Bunk wrote:
> Fix the program startup.

I'm not sure how much we're actually helping by fixing a package that
was apparently not even trivially tested before upload and had been
entirely broken for nearly a year before anyone even noticed.

Feel free to upload, but it seems like time would be better spent
avoiding us getting to such situations to begin with, rather than
having to spend time on them after the fact.

Regards,

Adam

Bug#893043: stretch-pu: package nss-pam-ldapd/0.9.7-2+deb9u1

[Adam D. Barratt]

Control: tags -1 + confirmed

On Thu, 2018-03-15 at 21:49 +0100, Salvatore Bonaccorso wrote:
> src:nss-pam-ldapd is affected in stable (and alrady fixed
> correspondigly in unstable and testing) by #890508, which under
> certian circumstances (like the ones outlined in the bug, pam stack
> configured with pam_ldap, UseDNS=yes in sshd_config, and a remote
> hostname which is longer than 64 bytes), can lead to authentication
> failure. That is just one way to trigger the issue. It would be as
> well by any rhost value which matches the problem.
> 

Please go ahead.

Regards,

Adam

Bug#893644: stretch-pu: package leap-archive-keyring/2016.03.08

[Adam D. Barratt]

Control: tags -1 + moreinfo

On Wed, 2018-03-21 at 14:07 +0100, micah wrote:
> "Adam D. Barratt"  writes:
> 
> > Control: tags -1 + moreinfo
> > 
> > On Tue, 2018-03-20 at 16:32 -0400, micah wrote:
> > > The leap-archive-keyring is a simple archive keyring package that
> > > contains the
> > > signing key for trusting the archive of the LEAP encryption
> > > access
> > > project. Unfortunately, the expiration date chosen for the key
> > > that
> > > is included
> > > in the package in Stretch was too low, and it has expired.
> > > 
> > > The newer package that is available in testing, unstable, and
> > > backports provides
> > > a key with a sufficient length to cover the stable release cycle.
> > > 
> > > I would like to propose that this package be included in the next
> > > stable release point update.
> > 
> > We'd need to see a debdiff of the proposed upload, built on and
> > tested
> > against stretch, please.
> 
> Sorry, I thought I had attached the debdiff, here it is:

Ah, sorry, I meant of the source packages, not the binaries.

(Also, as per above - "of the proposed upload, built on and tested
against stretch". The provided debdiff is against the version that was
uploaded to unstable. An upload to stretch at least needs a new
changelog stanza with a different version number - most likely
2016.03.08+deb9u1, but possibly 2017.11.24~deb9u1 if you wish to argue
that all of the changes since the current version in stretch are
appropriate for a stable update.)

Regards,

Adam

Bug#893803: stretch-pu: package adminer/4.2.5-3+deb9u1

[Adam D. Barratt]

Control: tags -1 + confirmed

On Thu, 2018-03-22 at 15:05 +, Chris Lamb wrote:
>   adminer (4.2.5-3+deb9u1) stretch; urgency=high
>   
> * CVE-2018-7667: Adminer allowed unauthenticated connections to
> be initiated
>   to arbitrary systems and ports which coul bypass external
> firewalls to
>   identify internal hosts and/or perform port scanning of other
> servers.
>   (Closes: #893668)
> 

s/coul /could /

Please go ahead.

Regards,

Adam

Bug#881773: ruby2.5: FTBFS on hppa: recursive once test fails

[John David Anglin]

Source: ruby2.5
Version: 2.5.x
Followup-For: Bug #881773

Dear Maintainer,

In the 2.5.1 build, test #361 fails as follows:

#361 test_insns.rb:389:in `block in ' F 0.090
stderr output is not empty
   bootstraptest.tmp.rb:3:in `once': stack level too deep (SystemStackError)
   from bootstraptest.tmp.rb:7:in `block in once'
   from bootstraptest.tmp.rb:3:in `once'
   from bootstraptest.tmp.rb:7:in `block in once'
   from bootstraptest.tmp.rb:3:in `once'
   from bootstraptest.tmp.rb:7:in `block in once'
   from bootstraptest.tmp.rb:3:in `once'
   from bootstraptest.tmp.rb:7:in `block in once'
   from bootstraptest.tmp.rb:3:in `once'
... 97 levels...
   from bootstraptest.tmp.rb:3:in `once'
   from bootstraptest.tmp.rb:7:in `block in once'
   from bootstraptest.tmp.rb:3:in `once'
   from bootstraptest.tmp.rb:11:in `'

So, it appears the test causes a stack overflow on hppa.

It is not uncommon for hppa to require twice the stack space x86 needs.
Is there a way to increase the stack allocation for hppa (e.g., using ulimit)?
Otherwise, I would say the test needs to be skipped on hppa.

Regards,
Dave Anglin


-- System Information:
Debian Release: buster/sid
  APT prefers buildd-unstable
  APT policy: (500, 'buildd-unstable'), (500, 'unstable')
Architecture: hppa (parisc64)

Kernel: Linux 4.14.31+ (SMP w/4 CPU cores)
Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968), LANGUAGE=C 
(charmap=ANSI_X3.4-1968)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

-- no debconf information

Bug#894528: RFS: dbacl/1.14.1-1 [QA upload]

[Fabian Wolff]

Package: sponsorship-requests
Severity: normal

Dear mentors,

I am looking for a sponsor for a QA upload of the dbacl package.

My changes are summarized in the latest changelog entry:

 dbacl (1.14.1-1) unstable; urgency=medium

   * QA upload.
   * New upstream release.
   * Update debian/watch to version 4 format (no changes).
   * Update debian/copyright to the machine-readable format.
   * Upgrade to debhelper compat level 11.
   * Update patches:
  - Use quilt.
  - Update patch 01_manpage_doc_paths.diff and rename it to
00-fix-man-page-paths.patch.
  - Update patch 10_fix_bashisms.patch and rename it to
01-fix-bashisms.patch.
  - Delete 20_autotools_update.patch (useless with dh_autoreconf).
  - Add 02-fix-spelling.patch, 03-fix-find-param.patch and
04-fix-ldflags.patch.
   * Rewrite debian/rules to use debhelper (instead of CDBS).
   * Upgrade to Standards-Version 4.1.3 in debian/control (no changes).
   * Add build dependency on libncurses-dev (Closes: #646734).

  -- Fabian Wolff   Sat, 31 Mar 2018 21:59:24 +0200


The package is available on Mentors:

  https://mentors.debian.net/package/dbacl
  https://mentors.debian.net/debian/pool/main/d/dbacl/dbacl_1.14.1-1.dsc


Thank you!

Best regards,
Fabian

Bug#860797: Seconded

[Otto Kekäläinen]

This is already marked wontfix, but for the record I second this as well.

Epoch changes are unrevertable and should not happen for light
reasons. The are also very rare, so having them go through extra
hurdles should not hurt anybody too much.

Bug#893762: samba: installation fails when only loopback interface present.

[Mathieu Parent]

2018-03-31 13:19 GMT+02:00 unman :
[...]
>
> At least three:
> 1. Where external interface is created when device is attached.
> 2. User wants to test samba configuration on non-networked device.
> 3. In virtualised environment like Qubes, where Template has no network,
> but VMs that use the template do.

nmbd could'nt work in those situations.

You can mask it before the installation using "systemctl mask nmbd"
(or  read /usr/share/doc/*/README.policy-rc.d.gz if not using
systemd), but your install may not work properly.

> Probably more.
>
> I've tested a number of "network" services, and samba seems to be the
> only one that requires an external interface at time of installation.

nmbd is different because it needs to bind to a broadcast address (and
not localhost). smbd is not affected.

Maybe a solution would be to use "dh_installinit -psamba --name nmbd
--errorhandler nmbd_failure" in debian/rules and write an nmbd_failure
shell function to ignore the error if only the loopback interface is
up. Patch welcome!

Regards

-- 
Mathieu Parent

Bug#894527: RM: hyperestraier -- RoQA; FTBFS+wontfix

[Adam Borowski]

Package: ftp.debian.org
Severity: normal


Hi!
hyperestraier has a bug that bears an interesting combination:
FTBFS+serious+wontfix.  With the explanation being:

> Tagging as wontfix since the package is unmaintained, dead upstream, and
> therefore likely to be removed.

The previous maintainer said:

> For someone interested in adopting this software, please note:
>  - hyperestraier is completely dead software and users should consider
>moving to other modern search solutions (sphinx, groonga, and so on).

It has no rdeps (but has a rrecommends: mew).  It also blocks removal of
ruby2.3.

Thus, time to put it to a nice pasture, I guess.

Bug#892503: tmux: display garbling with nested sessions

[Romain Francoise]

Hi,

On Sat, Mar 31, 2018 at 6:39 AM, Vagrant Cascadian  wrote:
> Though, while using backports works around the issue, it would be ideal
> to get it fixed in stretch as well...

Yes, unfortunately that requires identifying the real root cause and
which of hundreds of changes between 2.3 and 2.6 fixes the bug, which
is not especially appealing.

So unless you feel strongly about it I'll probably close this bug and
mark it fixed in 2.6-1.

Thanks.

Bug#893169: rkhunter won't update definitions: Invalid WEB_CMD

[Francois Marier]

On 2018-03-30 at 12:52:23, Kudrettin Güleryüz wrote:
> This message apparently refers to the bug itself. Can you please point to
> the bug report that has the details for this issue?

Sorry, I meant to point to this bug instead:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=765895.

Also see https://security-tracker.debian.org/tracker/CVE-2017-7480 for the
details of the security bug.

Francois

-- 
https://fmarier.org/

Bug#884284: Correction

[Daniel Smolik]

NFSv3 local_lock=all

Bug#799626: RFP: beancount -- command line double-entry bookkeeping system

[Nicolas Dandrimont]

retitle 799626 ITP: beancount -- command line double-entry bookkeeping system
owner 799626 !
thanks

* Martin Michlmayr  [2018-03-30 17:14:49 +0200]:

> * Petter Reinholdtsen  [2015-09-21 00:17]:
> > * URL : http://furius.ca/beancount/
> > * License : GPL v2+
> > 
> > A double-entry bookkeeping computer language that lets you define
> > financial transaction records in a text file, read them in memory,
> > generate a variety of reports from them, and provides a web interface.
> 
> beancount 2.0 was released a few days ago so it's time to get this
> into Debian.
> 
> Anyone interested in packaging it?  It's Python code.

I've been meaning to look into this for a while, as I've been using beancount
in an org I'm treasurer of.

I'll put this in the python-team/applications group on salsa. Comaintainers 
welcome!

Cheers,
-- 
Nicolas Dandrimont


signature.asc
Description: PGP signature

Bug#891161: cwidget: FTBFS with libncursesw6

[Manuel A. Fernandez Montecelo]

2018-03-31 20:20 GMT+02:00 Sven Joachim :
> On 2018-03-31 19:56 +0200, Manuel A. Fernandez Montecelo wrote:
>
>> I think shlib bumping is a better plan than waiting for an unknown
>> time in the NEW queue, although for new binary package names it's
>> usually a short wait.
>
> If you have a libcwidget4 package ready, don't hesitate to upload it to
> experimental.  This gives me at least something to show in bug #894049,
> where I haven't received a reply yet.

I don't have it ready, but I imagine that it's not too much work
either way.  I wanted to include other changes in parallel, but didn't
have time to prepare it.

So I think that shlib bumping is a better route at this point.

About copying to #894049, I tought about replying to that bug report
instead, to show RMs that we're ready to go.  Feel free to point to
it, or tell me and I will reply to the other bug myself.


>> So I have to wait to upload cwidget until the new ncurses gets the
>> green light and enters unstable, right?
>
> For uploads to unstable, yes.  This holds for both plans (SONAME change or
> shlibs bump + Breaks against aptitude).

Right, so I can prepare this within a day, for both cwidget and aptitude.


Cheers.
-- 
Manuel A. Fernandez Montecelo 

Bug#883218: RFS: elpy/1.19.0-1 [ITP]

[Nicholas D Steeves]

Control: retitle -1 RFS: elpy/1.19.0-1 [ITP]

Updated to new upstream version.

https://mentors.debian.net/package/elpy
https://mentors.debian.net/debian/pool/main/e/elpy/elpy_1.19.0-1.dsc

Chris Lamb reviewed 1.17.0-1:
> Needs work lamby at 2018-03-08 01:53:27.146548
> Please drop homepage / URI link from long description of the binary
> package. Thats what the main Homepage field is for
> 
> - Please drop commented-out dependencies - they are just confusing 
> - X-Python3-Version: >= 3.2 is not really needed now we have 3.5 in stretch
> - #Testsuite: autopkgtest-pkg-elpa also commented out is weird
> - "true" in debian/rules is unnecessary
> - not sure why you are overriding clean anyway or indeed any of the other 
> targets
> 
> (Please prefer to justify any of these changes as comments in the
> package itself, otherwise the next person to look at the package will not 
> know...)

I have addressed all of these issues in 1.19.0-1, and have worked with
upstream to reduce the patch-set delta, both by fixing upstream bugs
and by adding build-deps needed for self-tests to pass.  In the future
I hope to help upstream make these tests pass when only python2
is not installed.

WRT the yasnippets installing to an elpy-specific location (Thanks to
Sean Whitton for raising this point), I have decided that for now they
should be installed and configured as upstream intends.  I am in the
process of merging them (upstream) into the official
yasnippet-snippets collection, and a future release of Elpy will
depend on yasnippet-snippets (>= version-with-elpy-snippets).

Please see https://salsa.debian.org/emacsen-team/elpy for git history.

Regards,
Nicholas


signature.asc
Description: PGP signature

Bug#894526: scikit-learn build depends on the removed python-imaging

[Adrian Bunk]

Source: scikit-learn
Version: 0.19.1-3
Severity: serious

The following packages have unmet dependencies:
 builddeps:scikit-learn : Depends: python-imaging but it is not installable

python-pil should be used instead of python-imaging.

Bug#894525: linux: computer frozen on "reboot: power down" on power off

[Alberto Fuentes]

Source: linux
Severity: normal
Tags: patch

60% of the times, the computer refuses to power off

It stays in a blank screen that says

"[ 935.342345413 ] reboot: power down"
I made it work adding reboot=b to /etc/default/grub as specified in

https://askubuntu.com/questions/7114/why-cant-i-restart-shutdown

Thanks

$ lspci -n
00:00.0 0600: 8086:0c00 (rev 06)
00:01.0 0604: 8086:0c01 (rev 06)
00:14.0 0c03: 8086:8c31 (rev 05)
00:16.0 0780: 8086:8c3a (rev 04)
00:1a.0 0c03: 8086:8c2d (rev 05)
00:1b.0 0403: 8086:8c20 (rev 05)
00:1c.0 0604: 8086:8c10 (rev d5)
00:1c.2 0604: 8086:8c14 (rev d5)
00:1c.5 0604: 8086:8c1a (rev d5)
00:1d.0 0c03: 8086:8c26 (rev 05)
00:1f.0 0601: 8086:8c5c (rev 05)
00:1f.2 0106: 8086:8c02 (rev 05)
00:1f.3 0c05: 8086:8c22 (rev 05)
01:00.0 0300: 10de:1402 (rev a1)
01:00.1 0403: 10de:0fba (rev a1)
03:00.0 0200: 10ec:8168 (rev 11)
04:00.0 0280: 10ec:8179 (rev 01)



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

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

Bug#884561: stretch-pu: package pam-krb5-migrate/0.0.11-4

[Dominik George]

Control: tag -1 - moreinfo

Hi,

sorry for losing track of this ☹…

> Care to provide the binary debdiff as well?

Sure:

debdiff libpam-krb5-migrate-mit_0.0.11-4+b1_amd64.deb 
libpam-krb5-migrate-mit_0.0.11-4+deb9u1_amd64.deb
[The following lists of changes regard files as different if they have
different names, permissions or owners.]

Files in second .deb but not in first
-
-rw-r--r--  root/root   /lib/security/pam_krb5_migrate_mit.so
-rw-r--r--  root/root   
/usr/share/pam-configs/libpam-krb5-migrate-mit.pam-config

Files in first .deb but not in second
-
-rw-r--r--  root/root   
/lib/security/pam_krb5_migrate_mit.so/pam_krb5_migrate_mit.so
-rw-r--r--  root/root   
/usr/share/doc/libpam-krb5-migrate-mit/changelog.Debian.amd64.gz
-rw-r--r--  root/root   
/usr/share/pam-configs/krb5-migrate-mit/libpam-krb5-migrate-mit.pam-config

Control files: lines which differ (wdiff format)

Installed-Size: [-45-] {+42+}
Maintainer: [-Jelmer Vernooij -] {+Dominik George 
+}
Source: pam-krb5-migrate [-(0.0.11-4)-]
Version: [-0.0.11-4+b1-] {+0.0.11-4+deb9u1+}

> Also, when did this break?

I do not know. I adopted the package after the stretch release.

-nik

-- 
PGP-Fingerprint: 3C9D 54A4 7575 C026 FB17  FD26 B79A 3C16 A0C4 F296

Dominik George · Hundeshagenstr. 26 · 53225 Bonn
Phone: +49 228 92934581 · https://www.dominik-george.de/

Teckids e.V. · FrOSCon e.V. · Debian Developer

LPIC-3 Linux Enterprise Professional (Security)


signature.asc
Description: PGP signature

Bug#894524: java-imaging-utilities build depends on java-gcj-compat-dev

[Adrian Bunk]

Source: java-imaging-utilities
Version: 0.14.3-2
Severity: serious
Tags: buster sid

The following packages have unmet dependencies:
 builddeps:java-imaging-utilities : Depends: java-gcj-compat-dev

gcj has been removed from Debian.

Bug#894488: release.debian.org: Please let mongodb transition to testing; i386 is not built anymore

[Apollon Oikonomopoulos]

Hi Emilio,

On 13:35 Sat 31 Mar , Emilio Pozuelo Monfort wrote:
> On 31/03/18 08:57, Apollon Oikonomopoulos wrote:
> > Package: release.debian.org
> > Severity: normal
> > 
> > Dear Release Team,
> > 
> > Following upstream's decision to drop 32-bit support, the mongodb source 
> 
> Was it so hard to maintain?

Unfortunately, yes. We maintained i386 support for 3.2, despite upstream 
dropping it. However the new storage engine, Wiredtiger, was written 
from scratch for 64-bit architectures only and never supported i386. We 
got away with setting MMapv1 as the default engine for i386 in 3.2, but 
that also broke in 3.4, making me think that it probably did not make 
much sense to continue supporting i386 ourselves.

> > as of 3.4 no longer builds an i386 package. AFAICT, this breaks 
> > britney's  rules for arch:all -> arch:any dependencies and does not let 
> > the package migrate to testing.
> > 
> > Could you please let mongodb through manually?
> 
> force-hint added, it should migrate in the next britney run.

Thanks!

Apollon

Bug#894522: libserializer build depends on java-gcj-compat-dev

[Adrian Bunk]

Source: libserializer
Version: 1.1.6-4
Severity: serious
Tags: buster sid

The following packages have unmet dependencies:
 builddeps:libserializer : Depends: java-gcj-compat-dev

gcj has been removed from Debian.

Bug#894523: liblayout build depends on gcj

[Adrian Bunk]

Source: liblayout
Version: 0.2.10-2
Severity: serious
Tags: buster sid

The following packages have unmet dependencies:
 builddeps:liblayout : Depends: java-gcj-compat-dev

gcj has been removed from Debian.

Bug#894495: [tethys] mandos-client: Mandos client fails while booting but works from chroot into unpacked initramfs

[Teddy Hogeborn]

root  writes:

> Package: mandos-client
> Version: 1.7.15-1
> Severity: important

If practical, try the latest version, 1.7.19.

> Mandos plugin mandos-client: Trying to decrypt OpenPGP data
> Mandos plugin mandos-client: bad gpgme_op_decrypt: GPGME: Decryption failed

That is the important message.  It means that it failed to decrypt the
data from the server using the GPGME library.  In the past, this error
has been due to all the necessary GnuPG binaries not having been copied
into the initramfs image.

> plugins.d/mandos-client.c:422:2: runtime error: null pointer passed as 
> argument 3, which is declared to never be null

That error is simply about not being able to print an error message
about any "unsupported algorithm", since that field is NULL.  I.e. a
spurious error message from the error handling routing itself.  Ignore
it for now.

> If I test the client per the manual instructions, it WORKS.
>
> If I unpack the initramfs, chroot into it and run the client, it WORKS.
>
> But when the system boots, it FAILS.
> 
> During system boot, I can SSH into the running initramfs using
> dropbear, then if I run the client manually, it fails with the exact
> same error that I can see displayed on screen when booting unattended.

First, when SSHing into the running system, make sure that /tmp is made
writeable by the unprivileged _mandos user.  This is fixed by the
automatic scripts when booting, but if you are running things manually
it might not be done.  Simply run "chmod a=rwxt /tmp" in the initramfs
file system.

Second, be aware that the instructions for running the client manually
does not contain the optional --dh-params option (Usually passed with an
argument of /etc/keys/mandos/dhparams.pem), but this option is used
automatically by the boot scripts.  Just to make sure, does it work when
run manually with or without a chroot with this option?  (Passing this
option also makes the client startup quite a bit faster, speeding up
debugging.)

> Any help in solving this will be greatly appreciated :-)

Since GPGME is giving the error, and it has been a problem in the past,
until it has beeen proved otherwise I suspect that the proper binaries
are not present in the system, or that they are not runnable somehow.

What does the "gpgconf" command output, in the normal system, in chroot,
and at boot?  Do the listed binaries all exist in all three systems,
i.e. what is the output of this command?

ls -laF $(gpgconf | awk -F: '{ print $3 }')

(Also don't forget to double check for a non-writeable /tmp.)

/Teddy Hogeborn

-- 
The Mandos Project
https://www.recompile.se/mandos


signature.asc
Description: PGP signature

Bug#890400: Any news about a new upstream version with new SONAME?

[Julien Yann Dutheil]

Dear Andreas,

bpp-phyl-omics pushed (once more had committed and forgotten to push, sorry
about that).

Best,

Julien.

On Sat, Mar 31, 2018 at 5:59 PM, Andreas Tille  wrote:

> Hi Julien,
>
> On Sat, Mar 31, 2018 at 08:32:26AM +0200, Julien Yann Dutheil wrote:
> > Continuing to upload new versions, but keep getting messages like this
> one
> > when running debuild:
> > devlibs error: There is no package matching [libbpp-core-dev]
> >
> > Updating my packages + setting dhlibs > 0.82 in rules solved the issue
> for
> > some packages,
>
> Yes, since I added some overrides to  dhlibs = 0.82  and uploaded. :-)
>
> > but I keep facing it in libbpp-phyl-omics, and I ave no clue
> > why :s
> >
> > Any hint welcome,
>
> Just push and I'll check.
>
> Kind regards
>
> Andreas.
>
>


-- 
Julien Y. Dutheil, Ph-D
0 (+49) 6421 178 986

§ Max Planck Institute for Evolutionary Biology
Molecular Systems Evolution
Department of Evolutionary Genetics
Plön -- GERMANY

§ Institute of Evolutionary Sciences - Montpellier
University of Montpellier 2 -- FRANCE

Bug#891161: cwidget: FTBFS with libncursesw6

[Sven Joachim]

On 2018-03-31 19:56 +0200, Manuel A. Fernandez Montecelo wrote:

> 2018-03-26 1:54 GMT+02:00 Manuel A. Fernandez Montecelo
> :
>
>>> I intend to file a transition bug for ncurses tomorrow.  If you can
>>> finish the changes for libcwidget4 until Easter, that's probably
>>> sufficiently early, but I have also come up with a backup plan: declare
>>> a versioned Breaks against aptitude and bump shlibs in libcwidget3v5.
>>> This requires uploads for both cwidget and aptitude, but does not need
>>> to through NEW.
>>>
>>> See these branches for cwidget and aptitude:
>>> https://salsa.debian.org/joachim-guest/cwidget/commits/ncurses6
>>> https://salsa.debian.org/joachim-guest/aptitude/commits/ncurses6
>>
>> That's good.  Sorry for not being more responsive, but I am massively
>> snowed under.
>>
>> I was leaving this precisely for Easter, because I have like 5 days of
>> holidays in total :)
>
> I think shlib bumping is a better plan than waiting for an unknown
> time in the NEW queue, although for new binary package names it's
> usually a short wait.

If you have a libcwidget4 package ready, don't hesitate to upload it to
experimental.  This gives me at least something to show in bug #894049,
where I haven't received a reply yet.

> So I have to wait to upload cwidget until the new ncurses gets the
> green light and enters unstable, right?

For uploads to unstable, yes.  This holds for both plans (SONAME change or
shlibs bump + Breaks against aptitude).

Cheers,
   Sven

Bug#885029: xrdp: thinclient_drives not umounted after session terminated

[Thorsten Glaser]

tags 885029 - moreinfo
thanks

Dominik George dixit:

>please test whether this is still reprodusible with a recent version
>from sid.

Yes, it still happens.

bye,
//mirabilos
-- 
[...] if maybe ext3fs wasn't a better pick, or jfs, or maybe reiserfs, oh but
what about xfs, and if only i had waited until reiser4 was ready... in the be-
ginning, there was ffs, and in the middle, there was ffs, and at the end, there
was still ffs, and the sys admins knew it was good. :)  -- Ted Unangst über *fs

Bug#894521: dolphin: Doplhin can't load kio file.so

[Matthias Wolle]

Package: dolphin
Version: 4:17.08.3-2
Severity: important

$ dolphin 
kf5.kio.core: Refilling KProtocolInfoFactory cache in the hope to find "stash"
qt.accessibility.core: Cannot create accessible child interface for object:  
PlacesView(0x5626a0827f30)  index:  14
kf5.kio.core: couldn't create slave: "Meldung von klauncher: Fehler beim Laden 
von /usr/lib/x86_64-linux-gnu/qt5/plugins/kf5/kio/file.so"
kf5.kio.core: couldn't create slave: "Meldung von klauncher: Fehler beim Laden 
von /usr/lib/x86_64-linux-gnu/qt5/plugins/kf5/kio/file.so"
kf5.kio.core: couldn't create slave: "Meldung von klauncher: Fehler beim Laden 
von /usr/lib/x86_64-linux-gnu/qt5/plugins/kf5/kio/file.so"
...

When I start dolhin, I see a red message that the creation of the input/output 
modul is not possible. klauncher said: Error loading 
/usr/lib/x86_64-linux-gnu/qt5/plugins/kf5/kio/file.so

The proposed solution in the thread fixes the issue for me.
https://bbs.archlinux.org/viewtopic.php?id=206352

$ dbus-launch dolphin


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

Kernel: Linux 4.14.0-3-amd64 (SMP w/8 CPU cores)
Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968), LANGUAGE= 
(charmap=ANSI_X3.4-1968)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages dolphin depends on:
ii  baloo-kf5  5.44.0-1
ii  kinit  5.44.0-1
ii  kio5.44.0-1
ii  libc6  2.27-2
ii  libdolphinvcs5 4:17.08.3-2
ii  libkf5baloo5   5.44.0-1
ii  libkf5baloowidgets54:17.08.3-1
ii  libkf5bookmarks5   5.44.0-1
ii  libkf5codecs5  5.44.0-1
ii  libkf5completion5  5.44.0-1
ii  libkf5configcore5  5.44.0-1
ii  libkf5configgui5   5.44.0-1
ii  libkf5configwidgets5   5.44.0-1
ii  libkf5coreaddons5  5.44.0-1
ii  libkf5crash5   5.44.0-1
ii  libkf5dbusaddons5  5.44.0-1
ii  libkf5filemetadata35.44.0-1
ii  libkf5i18n55.44.0-1
ii  libkf5iconthemes5  5.44.0-1
ii  libkf5itemviews5   5.44.0-1
ii  libkf5jobwidgets5  5.44.0-1
ii  libkf5kcmutils55.44.0-1
ii  libkf5kiocore5 5.44.0-1
ii  libkf5kiofilewidgets5  5.44.0-1
ii  libkf5kiowidgets5  5.44.0-1
ii  libkf5newstuff55.44.0-1
ii  libkf5notifications5   5.44.0-1
ii  libkf5parts5   5.44.0-1
ii  libkf5service-bin  5.44.0-1
ii  libkf5service5 5.44.0-1
ii  libkf5solid5   5.44.0-1
ii  libkf5textwidgets5 5.44.0-1
ii  libkf5widgetsaddons5   5.44.0-1
ii  libkf5xmlgui5  5.44.0-2
ii  libphonon4qt5-44:4.10.0-2
ii  libqt5core5a   5.9.2+dfsg-12
ii  libqt5dbus55.9.2+dfsg-12
ii  libqt5gui5 5.9.2+dfsg-12
ii  libqt5widgets5 5.9.2+dfsg-12
ii  libqt5xml5 5.9.2+dfsg-12
ii  libstdc++6 8-20180321-1
ii  phonon4qt5 4:4.10.0-2

Versions of packages dolphin recommends:
ii  kimageformat-plugins  5.44.0-1
ii  kio-extras4:17.08.3-2+b1
ii  ruby  1:2.5.1

Versions of packages dolphin suggests:
pn  dolphin-plugins  

-- no debconf information

Bug#894520: [sharutils] shar creates archives that will not extract files if the filename has spaces

[David Sanders]

Package: sharutils
Version: 1:4.15.2-2
Severity: important

--- Please enter the report below this line. ---
Dear maintainer,

shar does not handle filenames with spaces in them if using compression
(ie gzip or xz).  It creates
the archive without comment but then when trying to extract the archive
it fails with an error message.

This is the error message:
x - created lock directory _sh03236.
x - extracting Filename with spaces.txt gzipped
uudecode fatal error:
fserr 2 (No such file or directory) performing 'freopen' on Filename
with _sh03236/gzi
restore of Filename with spaces.txt failed
Filename with spaces.txt: MD5 check failed
x - removed lock directory _sh03236.

I have confirmed that the bug is present in the current upstream version.

The program works correctly with filenames containing spaces if you do
not specify compression.

Thank you

--- System information. ---
Architecture:
Kernel: Linux 4.9.0-6-amd64

Debian Release: 9.4
500 stable-updates ftp.us.debian.org
500 stable security.debian.org
500 stable ftp.us.debian.org
100 stretch-backports ftp.debian.org

--- Package information. ---
Depends (Version) | Installed
==-+-===
libc6 (>= 2.14) |


Package's Recommends field is empty.

Suggests (Version) | Installed
-+-===
sharutils-doc |
bsd-mailx | 8.1.2-0.20160123cvs-4
OR mailx |

Bug#894519: python-gtkglext1: Intent to remove from Debian

[Jeremy Bicha]

Source: python-gtkglext1
Version: 1.1.0-9.1
Severity: serious
Tags: buster sid

python-gtkglext1 has no reverse dependencies. (xpra recommends it). It
was removed from Testing a month ago because it depends on pygtk which
the Debian GNOME team is working to remove from Debian. [1]

python-gtkglext1's last upstream release was 12 years ago [2] and its
last Debian upload was 6 years ago.

Therefore, I intend for file a Debian removal bug for python-gtkglext1
soon. Please let me know if this is ok with you.

[1] https://bugs.debian.org/885373
[2] https://projects-old.gnome.org/gtkglext/download.html

Thanks,
Jeremy Bicha

Bug#891161: cwidget: FTBFS with libncursesw6

[Manuel A. Fernandez Montecelo]

Hi,

2018-03-26 1:54 GMT+02:00 Manuel A. Fernandez Montecelo
:

>> I intend to file a transition bug for ncurses tomorrow.  If you can
>> finish the changes for libcwidget4 until Easter, that's probably
>> sufficiently early, but I have also come up with a backup plan: declare
>> a versioned Breaks against aptitude and bump shlibs in libcwidget3v5.
>> This requires uploads for both cwidget and aptitude, but does not need
>> to through NEW.
>>
>> See these branches for cwidget and aptitude:
>> https://salsa.debian.org/joachim-guest/cwidget/commits/ncurses6
>> https://salsa.debian.org/joachim-guest/aptitude/commits/ncurses6
>
> That's good.  Sorry for not being more responsive, but I am massively
> snowed under.
>
> I was leaving this precisely for Easter, because I have like 5 days of
> holidays in total :)

I think shlib bumping is a better plan than waiting for an unknown
time in the NEW queue, although for new binary package names it's
usually a short wait.

So I have to wait to upload cwidget until the new ncurses gets the
green light and enters unstable, right?


Cheers.
-- 
Manuel A. Fernandez Montecelo 

Bug#894518: uscan: compression setting ignored without explicit repack / please use xz by default

[Andreas Metzler]

Package: devscripts
Version: 2.18.1
Severity: normal

Hello,

the compression=method setting in a watchfile is ignored when a tarball
is repacked because Files-Excluded matched (and not because --repack was
requested on the commandline). In this case the compression method of
the downloaded tarball is used for the repacked one.

Could you please change uscan/mk-origtargz to
a) always respect compression=method (includes an update for
mk-origtargz(1))
and
b) please default to xz (as dpkg does) when compression=method is unset
instead of using gzip or the compression method of to-be-repacked
tarball. 

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

Bug#894482: evolution-data-server: crashes caused by lax deps on libebook-contacts, libedata-book, libedata-cal

[Simon McVittie]

On Sat, 31 Mar 2018 at 09:18:46 +0800, Paul Wise wrote:
> I recently auto-upgraded evolution from testing to unstable because
> evolution-rss got auto-removed from testing due to the gconf transition
> so unattended-upgrades upgraded it to the latest unstable version.

Using unattended-upgrades with both testing and unstable available
seems brave. I'm surprised you don't get bugs worse than this on a
regular basis...

> This upgrade did not go well and resulted in the address book and
> calendar not working because the above factory programs segfaulted.
> 
> I narrowed this down to being caused by the versioned deps on the
> libebook-contacts, libedata-book and libedata-cal libraries being too
> lax and allowing the versions from testing to stay installed.

This probably means e-d-s (or a library that was upgraded alongside it)
only uses symbols that were already available in testing, but relies
on behaviour that wasn't. I don't think we can expect partial upgrades
within a source package to work - this is not something that its upstream
developer will ever have contemplated, and it's very common for upstreams
to rely on subtle behaviours or internal-only symbols in their own
libraries that would be a bug for anyone else to rely on.

I've added lockstep dependencies in pkg-gnome git.

smcv

Bug#894482: evolution-data-server: crashes caused by lax deps on libebook-contacts, etc

[Jeremy Bicha]

Control: found -1 3.26.5-2
Control: tags -1 +pending

Thank you for taking the time to report this bug.

This will be fixed in our next release.

https://salsa.debian.org/gnome-team/evolution-data-server/commit/35ab9551

I am marking this as found in the current Testing release to let this
package go ahead and migrate (which will end up fixing your particular
use case) since this isn't really a new issue.

Thanks,
Jeremy Bicha

Bug#885677: is rebuilding lablgtk2 without gnomecanvas an option?

[Jeremy Bicha]

Hi,

Please CC people on bug reports. The Debian bug tracker does not
automatically copy anyone except for the package Maintainer (according
to debian/control) and it's a hassle to subscribe to bug reports.

It's a good question about whether you can disable some optional features.

I expect libgnomeui to be removed from Testing next week (it was
already disabled in Debian's lablgtk2 last year).

The Debian GNOME wants to remove gtksourceview2 and libgnomecanvas
from Testing too.

Maybe it's too early for you to be interested, but for the release
after Buster (Bullseye), we'd like to remove gtkspell and libglade2
also. (The idea is to strongly push as much software as we can to stop
using gtk2 even though it might not be possible to get the number of
packaging using gtk2 all the way to zero in time for Bullseye.)

I haven't investigated, but from the dependencies mentioned in my
first 2 emails for this bug, it appears like there are several Debian
packages that do use the gnomecanvas support. I don't know how
practical it will be to build lablgtk2 without it.

Thanks,
Jeremy Bicha

Bug#894517: rapid-photo-downloader: Thumbnails are no longer created

[Pascal Volk]

Package: rapid-photo-downloader
Version: 0.9.9-1
Severity: important

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Dear maintainer,

since upgrading to version 0.9.9-1 rapid-photo-downloader is unable to
create new thumbnails. This could be caused by a programming error:

Traceback (most recent call last):
  File "/usr/lib/python3/dist-packages/raphodo/thumbloadbalancer.py", line 50, 
in 
loadbalancer = ThumbnailLoadBalancer()
  File "/usr/lib/python3/dist-packages/raphodo/thumbloadbalancer.py", line 47, 
in __init__
super().__init__('Thumbnail', ThumbnailLoadBalancerWorkerManager)
  File "/usr/lib/python3/dist-packages/raphodo/interprocess.py", line 601, in 
__init__
queue = LRUQueue(backend, frontend, controller, worker_type, 
process_manager)
  File "/usr/lib/python3/dist-packages/raphodo/interprocess.py", line 486, in 
__init__
self.backend = ZMQStream(backend_socket)
  File "/usr/lib/python3/dist-packages/zmq/eventloop/zmqstream.py", line 103, 
in __init__
self.io_loop = io_loop or IOLoop.instance()
  File "/usr/lib/python3/dist-packages/zmq/eventloop/ioloop.py", line 152, in 
instance
PollIOLoop.configure(cls)
  File "/usr/lib/python3/dist-packages/tornado/ioloop.py", line 199, in 
configure
"only AsyncIOLoop is allowed when asyncio is available")
RuntimeError: only AsyncIOLoop is allowed when asyncio is available


Best Regards,
Pascal

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

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

Versions of packages rapid-photo-downloader depends on:
ii  gir1.2-gexiv2-0.10 0.10.8-1
ii  gir1.2-gstreamer-1.0   1.14.0-1
ii  gir1.2-gudev-1.0   232-2
ii  gir1.2-notify-0.7  0.7.7-3
ii  gir1.2-udisks-2.0  2.7.6-2
ii  gstreamer1.0-libav 1:1.14.0-dmo1
ii  gstreamer1.0-plugins-good  1.12.4-1+b1
ii  libimage-exiftool-perl 10.80-1
ii  python33.6.4-1
ii  python3-arrow  0.10.0-1
ii  python3-colorlog   3.1.2-1
ii  python3-colour 0.1.5-1
ii  python3-dateutil   2.6.1-1
ii  python3-dbus   1.2.6-1
ii  python3-easygui0.96-3
ii  python3-exif   2.1.2-1
ii  python3-gi 3.28.1-1
ii  python3-gphoto21.8.2-1
ii  python3-gphoto2cffi [python3-gphoto2]  0.3~a1-1+b1
ii  python3-psutil 5.4.2-1
ii  python3-pymediainfo2.2.0-1
ii  python3-pyprind2.11.2-1
ii  python3-pyqt5  5.9.2+dfsg-1
ii  python3-rawkit 0.6.0-1
ii  python3-sortedcontainers   1.5.7-1
ii  python3-tornado5.0.0-1
ii  python3-xdg0.25-4
ii  python3-zmq16.0.2-2+b1
ii  qt5-image-formats-plugins  5.9.2-2

Versions of packages rapid-photo-downloader recommends:
ii  ffmpegthumbnailer 1:2.2.0-dmo4
pn  python3-hachoir-metadata  
pn  python3-kaa-metadata  

rapid-photo-downloader suggests no packages.

- -- no debconf information

-BEGIN PGP SIGNATURE-

iQGzBAEBCgAdFiEETlaQGxVbKzqL95JIiAsJTsUROf4FAlq/xGEACgkQiAsJTsUR
Of78tAv/VMFCzO4P2slc51pDWrr2gpg7T0sTCufEpcXzy56IgZCV/LjBu890V1D8
+mD9izykaV9H9sQqgDVRBp+xwSzKSFdwRwqR9PBZcGDZZNebLOQi/lTdukG2xAmJ
zJtWPAkem7fE2L/lnWqMrfeW3VgIUqDX2y1qCGnG+rN4Us27uay1JDTIsagviV5V
54BNNh/NYsWsbHwKJZa7Y1KddUPpuKs5mst+/HCFztLxhZZ8ZwSgJtPEQKWlbphc
zE6kSYKwkylnRiL6sZ1e2pQT8eYrlAVX0oLvqzdN68E95pMCYW3Y8CiLjWOSsOAW
JJqzTsKnwJS+XcZS6KbOCPnycOakIBfR9W+UroU/P41hJZF501xaKXSnwY5UagNC
NrivU4H5EqEu3QpjXCWxupJ626BmwoXIeps7f/c2jfinMu7v4Xd0AF2UPloDN/t5
iM5X1hOzjzylhIcXCzTFCWmYQq7fcXEDcjnr04BttO+DSDO80AR8PGrXURo69FiX
Lkk77YuM
=Yax/
-END PGP SIGNATURE-

Bug#894496: Removal of Xye package

[Andreas Ronnquist]

On Sat, 31 Mar 2018 18:45:32 +0200,
Stephen Kitt wrote:

>Hi Andreas,
>
>On Sat, 31 Mar 2018 16:14:36 +0200, Andreas Ronnquist
> wrote:
>> I intend to RM xye from unstable if nobody has any objection. It's
>> dead upstream (no release since 2013, no activity in blog since
>> 2015).  
>
>I rather like this game, I’d rather we keep it unless there’s a
>specific reason to remove it (basically, an RC bug).
>
>> Packaging is Gbp-based (not migrated to salsa yet) - unfortunately I
>> have done mistakes in the latest (old) upload, so that the latest
>> package differs from what's in the git repo (If I remember correctly
>> I think I made a mistake regarding pristine-tar / Non-pristine-tar).
>> I was hoping that a new upstream would be released so that I could
>> fix that easily, but that seems to never happen.  
>
>I just pushed a fix for that.
>
>> Doing an RM removes the package from unstable, but there's nothing
>> blocking a new upload to unstable of a new (somewhat unlikely)
>> upstream release.
>> 
>> It has a very small popcon of 117 too.
>> 
>> Does anybody have any objections?  
>
>Yes, me!
>
>I’ll gladly “adopt” it within the team if necessary.
>

Thanks!

Feel free to do so! I could "officially" orphan it if you would like,
whatever makes it easiest for you, but remember that upstream is _very_
inactive. 

Cheers
-- Andreas Rönnquist
mailingli...@gusnan.se
andr...@ronnquist.net
gus...@debian.org


pgpSn8YMY4Zew.pgp
Description: OpenPGP digital signatur

Bug#894516: python3-stdlib-extensions: BD-Uninstallable on all release arch (except all/amd64)

[Boyuan Yang]

Source: python3-stdlib-extensions
Version: 3.6.5-2
Severity: grave
Justification: renders package unusable

Dear Maintainer,

I'd like to raise your awareness about buildd status of src:python3-stdlib-
extensions.

>From https://buildd.debian.org/status/package.php?p=python3-stdlib-extensions
we could see that it was given-back on most release architectures. The reason
seems to be version mismatching.

For example:

Dependency installability problem for python3-stdlib-extensions on arm64:

python3-stdlib-extensions build-depends on:
- libpython3-all-dev:arm64
libpython3-all-dev depends on:
- libpython3.6-dev:arm64
libpython3.6-dev depends on:
- libpython3.6-stdlib:arm64 (= 3.6.5-2)
python3-stdlib-extensions build-depends on:
- python3-all-dev
python3-all-dev depends on:
- python3-dev:arm64 (= 3.6.5-1)
python3-dev depends on:
- python3-distutils:arm64 (>= 3.6.5~rc1-2)
libpython3.6-stdlib conflicts with:
- python3-distutils:arm64 (< 3.6.5-2)

Please investigate into its cause and fix it if possible.

--
Regards,
Boyuan Yang



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

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

Bug#894515: qcontrol: daemon does not start at boot

[alberto]

Package: qcontrol
Version: 0.5.5-2
Severity: important

Dear Maintainer,

I noticed that qcontrol daemon does not start at boot on a TS 212P running
stretch.

I see that in the list of supported models (/etc/qcontdol.conf) the 212P is
missing but if I start the daemon manually (service qcontrold start) everything
works.  I assume the problem is not the model but something weird in the
integration of qcontrol with systemd (I found that the same happened in jessie
but I never used at that time).

I put the severity to important because if you do not start it yourself (or do
not hack the start method) the package is "unusable". I understand it is maybe
a bit overstated. It is up to you to renormalize it.


-- System Information:
Debian Release: 9.4
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable')
Architecture: armel (armv5tel)

Kernel: Linux 4.9.0-6-marvell
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) (ignored: LC_ALL 
set to en_US.UTF-8), LANGUAGE=en_US.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set 
to en_US.UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages qcontrol depends on:
ii  libc62.24-11+deb9u3
ii  liblua5.1-0  5.1.5-8.1+b2
ii  udev 232-25+deb9u2

qcontrol recommends no packages.

qcontrol suggests no packages.

-- no debconf information

Bug#894388: affects corebird

[Simon McVittie]

Control: forwarded -1 https://gitlab.gnome.org/GNOME/gtk/merge_requests/89

On Fri, 30 Mar 2018 at 11:45:31 -0600, dann frazier wrote:
> #0  0x72018e79 in wl_proxy_marshal (proxy=proxy@entry=0x0, 
> opcode=opcode@entry=0) at ../src/wayland-client.c:692
> #1  0x7fffe2e461b9 in gtk_text_input_destroy (gtk_text_input=0x0)
> at ../../../../../modules/input/gtk-text-input-client-protocol.h:498
> #2  registry_handle_global_remove (data=0x55e652d0, 
> registry=, id=)
> at ../../../../../modules/input/imwayland.c:226

Thanks. Destroying a NULL struct gtk_text_input from
registry_handle_global_remove() looks like
https://gitlab.gnome.org/GNOME/gtk/issues/129#note_91002
which looks like it would be addressed by
https://gitlab.gnome.org/GNOME/gtk/merge_requests/89 which is awaiting
upstream review.

smcv

Bug#894512: gunicorn3: can't serve large files

[Chris Lamb]

forwarded 894512 https://github.com/benoitc/gunicorn/issues/1736
thanks

Dear Lars,

Thank you for the detailed bug report with testcase! I've forwarded
this upstream here for the time being:

  https://github.com/benoitc/gunicorn/issues/1736

(I'm generally «au fait» with WSGI stuff, but the streaming/chunked parts
of it are not.)


Regards,

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

Bug#893488: gnome-shell 3.28 crashes on Radeon R9: Failed to create texture 2d due to size/format constraints

[Simon McVittie]

On Sat, 31 Mar 2018 at 01:04:04 +0200, Matteo Settenvini wrote:
> I finally got round to re-install the packages that are crashing for me (by 
> the
> way, this seem to happen roughly the same on another computer of mine, which
> has a nVidia graphics card).

nVidia with the proprietary drivers from nvidia-graphics-drivers, or nVidia
with the open-source "Nouveau" driver from Mesa? (They have different bugs,
and Nouveau in particular has quite a lot in common with the amdgpu driver
that you're presumably using on the Radeon.)

> Thread 1 (Thread 0x7f2be1603ac0 (LWP 21374)):
> #0  0x7f2be0776509 in magazine_chain_pop_head (magazine_chunks= out>) at ../../../../glib/gslice.c:539
> #1  0x7f2be0776509 in thread_memory_magazine1_alloc (tmem=,
> ix=0) at ../../../../glib/gslice.c:842
> #2  0x7f2be0776509 in g_slice_alloc (mem_size=mem_size@entry=12) at ../..
> /../../glib/gslice.c:1016
> #3  0x7f2be0776b29 in g_slice_alloc0 (mem_size=mem_size@entry=12) at ../..
> /../../glib/gslice.c:1051
> #4  0x7f2be10360c7 in shell_generic_container_get_preferred_width (actor=
> 0x565161957920 [ShellGenericContainer], for_height=, 
> min_width_p
> =0x7ffebc4a4fa0, natural_width_p=0x7ffebc4a4fa4) at ../src/shell-generic-
> container.c:94
> #5  0x7f2bdf3e4f92 in clutter_actor_get_preferred_width (self=
> 0x565161957920 [ShellGenericContainer], for_height=27, min_width_p=
> 0x7ffebc4a5010, natural_width_p=0x7ffebc4a5014) at clutter-actor.c:9556

Unfortunately, this looks like heap corruption, so the damage was probably
done earlier (perhaps via a double-free, or by calling g_free() on memory
that came from g_slice_alloc()).

You might get a better backtrace from running gnome-shell with either
G_SLICE=always-malloc MALLOC_CHECK_=2, or G_SLICE=debug-blocks, for
instance by moving /usr/bin/gnome-shell to /usr/bin/gnome-shell.real
and replacing it with a script like:

#!/bin/sh
export G_SLICE=always-malloc
export MALLOC_CHECK_=2
exec /usr/bin/gnome-shell.real "$@"

or

#!/bin/sh
export G_SLICE=debug-blocks
exec /usr/bin/gnome-shell.real "$@"

Regards,
smcv

Bug#894496: Removal of Xye package

[Stephen Kitt]

Hi Andreas,

On Sat, 31 Mar 2018 16:14:36 +0200, Andreas Ronnquist
 wrote:
> I intend to RM xye from unstable if nobody has any objection. It's
> dead upstream (no release since 2013, no activity in blog since 2015).

I rather like this game, I’d rather we keep it unless there’s a specific
reason to remove it (basically, an RC bug).

> Packaging is Gbp-based (not migrated to salsa yet) - unfortunately I
> have done mistakes in the latest (old) upload, so that the latest
> package differs from what's in the git repo (If I remember correctly I
> think I made a mistake regarding pristine-tar / Non-pristine-tar). I was
> hoping that a new upstream would be released so that I could fix that
> easily, but that seems to never happen.

I just pushed a fix for that.

> Doing an RM removes the package from unstable, but there's nothing
> blocking a new upload to unstable of a new (somewhat unlikely) upstream
> release.
> 
> It has a very small popcon of 117 too.
> 
> Does anybody have any objections?

Yes, me!

I’ll gladly “adopt” it within the team if necessary.

Regards,

Stephen


pgpInxXxrvpFp.pgp
Description: OpenPGP digital signature

Bug#894514: Nautilus takes too long time to launch && Freezes

[Abel Lifaefi Mbula]

Package: nautilus
Version: 3.14.1-2
Severity: important

Dear Maintainer,

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

   * What led up to the situation? When I launch the package there is a long 
delay (more than 30 mn) before it launches
   * What exactly did you do (or not do) that was effective (or
 ineffective)? Open system monitor and kill the process, and then launch 
the package.
   * What was the outcome of this action? It works.
   * What outcome did you expect instead? See the program launched

*** End of the template - remove these template lines ***
-- System Information:
Debian Release: 8.10
  APT prefers oldstable-updates
  APT policy: (500, 'oldstable-updates'), (500, 'oldstable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 3.16.0-5-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages nautilus depends on:
ii  desktop-file-utils 0.22-1
ii  gsettings-desktop-schemas  3.14.1-1
ii  gvfs   1.22.2-1
ii  libatk1.0-02.14.0-1
ii  libc6  2.19-18+deb8u10
ii  libcairo-gobject2  1.14.0-2.1+deb8u2
ii  libcairo2  1.14.0-2.1+deb8u2
ii  libexempi3 2.2.1-2
ii  libexif12  0.6.21-2
ii  libgail-3-03.14.5-1+deb8u1
ii  libgdk-pixbuf2.0-0 2.31.1-2+deb8u7
ii  libglib2.0-0   2.42.1-1+b1
ii  libglib2.0-data2.42.1-1
ii  libgnome-desktop-3-10  3.14.1-1
ii  libgtk-3-0 3.14.5-1+deb8u1
ii  libnautilus-extension1a3.14.1-2
ii  libnotify4 0.7.6-2
ii  libpango-1.0-0 1.36.8-3
ii  libpangocairo-1.0-01.36.8-3
ii  libselinux12.3-2
ii  libtracker-sparql-1.0-01.2.4-2
ii  libx11-6   2:1.6.2-3+deb8u1
ii  libxml22.9.1+dfsg1-5+deb8u6
ii  nautilus-data  3.14.1-2
ii  shared-mime-info   1.3-1

Versions of packages nautilus recommends:
ii  eject  2.1.5+deb1+cvs20081104-13.1+deb8u1
ii  gnome-icon-theme-symbolic  3.12.0-1
ii  gnome-sushi3.12.0-2+b1
ii  gvfs-backends  1.22.2-1
ii  librsvg2-common2.40.5-1+deb8u2

Versions of packages nautilus suggests:
ii  atril [pdf-viewer] 1.8.1+dfsg1-4+deb8u1
ii  brasero3.11.4-1.1
ii  eog3.14.1-1
ii  evince [pdf-viewer]3.14.1-2+deb8u2
ii  okular [pdf-viewer]4:4.14.2-2
ii  totem  3.14.0-2
ii  tracker1.2.4-2
ii  vlc [mp3-decoder]  2.2.7-1~deb8u1
ii  vlc-nox [mp3-decoder]  2.2.7-1~deb8u1
ii  xdg-user-dirs  0.15-2

-- no debconf information

Bug#894512: gunicorn3: can't serve large files

[Lars Wirzenius]

Package: gunicorn3
Version: 19.6.0-10+deb9u1
Severity: normal

Dear Maintainer,

I'm writing a web application that needs to server fairly large files,
in the terabyte range. I am using python3-bottle for my code, and it
works just fine. However, when I run my application with gunicorn3 it
doesn't work.

I've distilled this into a small test case. The application code,
saved as file foo.py:

import bottle

def blob(*args, **kwargs):
return bottle.static_file('blob', '.')

app = bottle.Bottle()
app.route(path='/blob', callback=blob)

This is the script that starts it, saved as file start.sh:

#!/bin/sh

set -eu

truncate -s 1G blob
gunicorn3 --bind 0.0.0.0:12765 foo:app

To test, run "sh +x start.sh", and then from another host run:

curl http://195.201.99.89:12765/blob > blob

This always fails for me: curl complains:

 curl: (18) transfer closed with 611469105 bytes remaining to read

It seems to always work over localhost. It always works when the blob
is sufficiently small, such as 1024 bytes, even between hosts.

If I don't use gunicorn, and use the Bottle built-in HTTP server, it
always works. Like this:

import bottle

def blob(*args, **kwargs):
return bottle.static_file('blob', '.')

app = bottle.Bottle()
app.route(path='/blob', callback=blob)

if __name__ == '__main__':
app.run(host='0.0.0.0', port=12765)

I ran that on one machine, and ran curl on a different host and it
worked 10 times in a row.

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

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

Versions of packages gunicorn3 depends on:
ii  python3   3.5.3-1
ii  python3-gunicorn  19.6.0-10+deb9u1

gunicorn3 recommends no packages.

Versions of packages gunicorn3 suggests:
pn  gunicorn-examples 
pn  python3-pastedeploy   
pn  python3-setproctitle  
pn  python3-tornado   

-- no debconf information

Bug#894513: ITP: libdeclare-constraints-simple-perl -- module for declarative Validation of Data Structures

[Xavier Guimard]

Package: wnpp
Severity: wishlist
Owner: Xavier Guimard 

* Package name: libdeclare-constraints-simple-perl
  Version : 0.03
  Upstream Author : Robert 'phaylon' Sedlacek 
* URL : https://metacpan.org/release/Declare-Constraints-Simple
* License : Artistic or GPL-1+
  Programming Lang: Perl
  Description : module for declarative Validation of Data Structures

Declare::Constraints::Simple provide an easy way to build a profile to
validate a data structure. It does this by giving you a set of
declarative keywords in the importing namespace.

Bug#892423: man -Tutf8 /usr/share/man/ja/man5/apt_preferences.5.gz (and several others) enter infinite loop

[Colin Watson]

Control: reassign -1 groff 1.22.3-10

On Thu, Mar 08, 2018 at 07:35:49PM -0500, Anthony DeRobertis wrote:
> Running:
> 
> man -Tutf8 /usr/share/man/ja/man5/apt_preferences.5.gz
> 
> starts outputting the manpage, but then at some point switches over to
> outputting an (so far as I can tell) infinite loop of newlines:
> 
>sources.list(5) ファイルに列挙された場所から取得した Packages ファイル
>や Release ファイルはすべて、/var/lib/apt/lists ディレクトリ
>や、apt.conf ファイルの Dir::State::Lists 変数で指定した場所に取得され
>ます。例え

This is also reproducible without man being involved:

  (echo .mso ja.tmac && zcat 

Bug#893353: libinline-java-perl FTBFS with openjdk-9

[gregor herrmann]

On Sat, 31 Mar 2018 13:19:58 +0200, Emmanuel Bourg wrote:

> Le 31/03/2018 à 00:39, gregor herrmann a écrit :
> > BTW, do you have an idea why 0.63-1 and 0.64-1 don't build on armel?
> Sorry I can't see. Is there a way to have more details on the test
> failures ?

You mean besides the build logs?
https://buildd.debian.org/status/fetch.php?pkg=libinline-java-perl=armel=0.63-1=1521403599=0
https://buildd.debian.org/status/fetch.php?pkg=libinline-java-perl=armel=0.64-1=1522083758=0

No, I'm also confused by why all tests fail with wstat 11.
(That's a SIGSEGV, right?)

I thought that maybe there might be known problems with openjdk-9 on
armel.

Trying to reproduce the issue on abel.d.o in an armel sid chroot, I
get the same failures when I build the package.

Let's see:

$ PERL_INLINE_JAVA_JNI=1 prove --blib --verbose t/01_init.t
t/01_init.t .. 
1..1
# Running under perl version 5.026001 for linux
# Current time local: Sat Mar 31 14:51:34 2018
# Current time GMT:   Sat Mar 31 14:51:34 2018
# Using Test.pm version 1.30
Can't call method "get_java_config" on an undefined value at t/01_init.t line 
15.
Dubious, test returned 2 (wstat 512, 0x200)
Failed 1/1 subtests 

Test Summary Report
---
t/01_init.t (Wstat: 512 Tests: 0 Failed: 0)
  Non-zero exit status: 2
  Parse errors: Bad plan.  You planned 1 tests but ran 0.
Files=1, Tests=0,  3 wallclock secs ( 0.12 usr  0.01 sys +  3.15 cusr  0.06 
csys =  3.34 CPU)
Result: FAIL


Different wstat and exit status, and we see the problem: $ij is not
defined, which should be compiled Java code, if I'm reading
https://salsa.debian.org/perl-team/modules/packages/libinline-java-perl/blob/master/t/01_init.t
correctly.


Of course we can add armel to NO_JNI_ARCH in debian/rules to avoid
the whole issue with the JVM as a shared object (confirmed that the
tests pass) but finding the actual issue would still be nicer.
Or maybe we should just go that way instead of wasting time with an
almost dead architecture ...


Cheers,
gregor

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


signature.asc
Description: Digital Signature

Bug#890400: Any news about a new upstream version with new SONAME?

[Andreas Tille]

Hi Julien,

On Sat, Mar 31, 2018 at 08:32:26AM +0200, Julien Yann Dutheil wrote:
> Continuing to upload new versions, but keep getting messages like this one
> when running debuild:
> devlibs error: There is no package matching [libbpp-core-dev]
> 
> Updating my packages + setting dhlibs > 0.82 in rules solved the issue for
> some packages,

Yes, since I added some overrides to  dhlibs = 0.82  and uploaded. :-)

> but I keep facing it in libbpp-phyl-omics, and I ave no clue
> why :s
> 
> Any hint welcome,

Just push and I'll check.

Kind regards

Andreas.

Bug#894511: Please emphasize in the documentation a possible race condition in if-*.d hooks with systemd

[Raphaël Halimi]

Package: ifupdown
Version: 0.8.31
Severity: wishlist

tl;dr A major difference in handling the "auto" and "allow-hotplug"
interfaces between systemd and sysinit script leads to a possible race
condition when a hook in if-*.d isn't protected against multiple
concurrent runs (example: iptables scripts)

Long version:

With /etc/init.d/networking script, network interfaces configured with
class "auto" are raised first, and only when that's done, interfaces
configured with class "allow-hotplug" are then raised:

ifup -a $exclusions $verbose && ifup_hotplug $exclusions $verbose

With systemd, the unit file only calls:

/sbin/ifup -a --read-environment

...letting udev (I guess) take care of the interfaces configured with
class "allow-hotplug", the major difference being that both steps are
done concurrently.

(by the way, it may deserve its own bug report, but "--read-environment"
isn't documented anywhere)

This leads to situation where a given hook in /etc/network/if-*.d can
end up running multiple times simultaneously.

To be precise, I encountered the problem with a hook which sets iptables
rules (the idea of putting it in pre-up.d was that the interfaces were
firewalled before even being raised; I admit this may be a questionable
practice, but that's not the subject of this bug report), with iptables
producing errors when a chain was flushed by a second instance of the
script, while the first instance, which already flushed this same chain
before, now tried to add rules to it. This never posed a problem with
SysV, but this happens with systemd, because it calls "ifupdown -a"
(which runs all hooks with IFACE="--all", even when no interface is
configured with class "auto", as described in the manual page), and
simultaneously lets udev try to raise the single network interface
(which is configured with class "allow-hotplug" by debian-installer by
default). Note that in my case, replacing "allow-hotplug" with "auto" in
/etc/network/interfaces was sufficient to work around the problem, but
things may be different with custom hooks doing other stuff.

The NEWS.Debian file's entry for 0.8 states that:

"Ifupdown will now be more strict when errors occur, and will also
properly return a non-zero exit code when (de)configuring an interface
fails. Please ensure your /etc/network/interfaces is correct and that
your interfaces can be brought up and down without errors, especially
during system startup."

IMHO, this doesn't emphasize enough on the fact that a given hook in
if-*.d must be able to run several times simultaneously, as the SysV
init script did everything sequentially, whereas systemd raises "auto"
and "allow-hotplug" interfaces concurrently, so a hook which worked
perfectly fine with SysV can produce errors when run with systemd.

I suppose the aggressive parallelizing done by systemd is expected
behavior, and my goal is not to question that here - by no means am I
suggesting to fix the unit file so that it mimics the init script - but
IMHO, there should be at least some kind of warning documented somewhere
(hence the wishlist severity). It may seem late, but I guess I'm not the
only admin who decided to wait until Jessie+N to start letting systemd
handle the init process, and such a warning in the docs may help other
people in the future, saving them a lot of time if they wonder why
systemd randomly fails to raise their network interfaces, when SysV didn't.

Regards,

-- 
Raphaël Halimi



signature.asc
Description: OpenPGP digital signature

Bug#894510: debhelper: Because it is listing tmpfiles in systemd's only, conf overriding is not working

[Seyeong Kim]

Package: debhelper
Version: 9.20160115ubuntu3
Severity: normal
Tags: d-i

In autoscripts/postinst-init-tmpfiles, There is TMPFILE containing conf in 
systemd pkg only.
Then if there is 00rsyslog.conf from rsyslog pkg. and installing or upgrading 
systemd

/var/log's permission is 755(which is default) not 775(which is in 
00rsyslog.conf)
overriding doesn't work when upgrading.

Please refer to below LP
ubuntu lp bug : https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1748147

removing TMPFILE from autoscripts/postinst-init-tmpfiles solves this issue.
e.g. change like below
systemd-tmpfiles --create #TMPFILES# >/dev/null || true
to
systemd-tmpfiles --create >/dev/null || true

and removing related code from dh_installinit maybe needed
e.g. below kind of part
if (compat(10) && !$dh{NOSCRIPTS}) {
# Include postinst-init-tmpfiles if the package ships any files
# in /usr/lib/tmpfiles.d or /etc/tmpfiles.d
my @tmpfiles;
find({
wanted => sub {
my $name = $File::Find::name;
return unless -f $name;
$name =~ s/^\Q$tmp\E//g;
if ($name =~ m,^/usr/lib/tmpfiles\.d/, ||
$name =~ m,^/etc/tmpfiles\.d/,) {
push @tmpfiles, $name;
}
},
no_chdir => 1,
}, $tmp);
if (@tmpfiles > 0) {
autoscript($package,"postinst", 
"postinst-init-tmpfiles",
"s,#TMPFILES#," . join(" ", sort 
@tmpfiles).",g");
}
}

Is there any reason that TMPFILE list is there? 


-- System Information:
Debian Release: stretch/sid
  APT prefers xenial-updates
  APT policy: (500, 'xenial-updates'), (500, 'xenial-security'), (500, 
'xenial'), (100, 'xenial-backports')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.4.0-87-generic (SMP w/4 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=ko_KR.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages debhelper depends on:
ii  autotools-dev20150820.1
ii  binutils 2.26.1-1ubuntu1~16.04.6
ii  dh-strip-nondeterminism  0.015-1
ii  dpkg 1.18.4ubuntu1.2
ii  dpkg-dev 1.18.4ubuntu1.4
ii  file 1:5.25-2ubuntu1
ii  libdpkg-perl 1.18.4ubuntu1.4
ii  man-db   2.7.5-1
ii  perl 5.22.1-9ubuntu0.2
ii  po-debconf   1.0.19

debhelper recommends no packages.

Versions of packages debhelper suggests:
pn  dh-make  

-- no debconf information

Bug#894068: ocrmypdf: New dependency on PyMuPDF for v6.0.0

[Sean Whitton]

Hello,

On Sat, Mar 31 2018, James R Barlow wrote:

> Hello Sean,
>
> As promised ocrmypdf v6.1.2 makes pymupdf optional but recommended. My
> continuous integration tests check with and without pymupdf.
>
> The only major regression without pymupdf is that with all of:
> 1) an input file containing a mix of scanned and born digital files
> 2) --skip-text (not default)
> 3) --output-type pdf (not default)
> the output file can grow extremely large compared to the input. Past
> versions of ocrmypdf have had this issue for a long time, and now it will
> produce a warning.
>
> So it should be ready for Debian.

I will start working on the new packaging.  Thank you for the new
release.

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#894509: /usr/sbin/wicd: Setting static DNS with custom nameservers works only for a few minutes

[Neels Hofmeyr]

Package: wicd-daemon
Version: 1.7.4+tb2-5
Severity: normal
File: /usr/sbin/wicd

Dear Maintainer,

In wicd-gtk, I set the wired interface Properties as:

  [x] Use static DNS[ ] Use global DNS servers
  DNS domain[]
  Search domain []
  DNS server 1  [9.9.9.9 ]
  DNS server 2  [8.8.8.8 ]
  DNS server 3  []

I disconnect, then re-connect. Above DNS servers are used, and I see them in
/etc/resolv.conf fine.

After some time though, presumably after DHCP refresh, the nameserver in
/etc/resolv.conf is set back to the DHCP server's idea of what nameservers I
should be using (in my case 192.168.0.1).

In my current situation, the DHCP server's DNS is broken, and thus name
resolution stops working as soon as the static name servers are dropped, which
is why I noticed this behavior quite prominently.

In the olden days, I would edit /etc/resolv.conf manually, and it would stay
put. Currently though resolv.conf seems to get overwritten regularly
(presumably by DHCP), and I had hoped that wicd would help me keep it static.

Thanks for taking a look!

~N

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

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

Versions of packages wicd-daemon depends on:
ii  adduser  3.117
ii  dbus 1.12.6-2
ii  debconf  1.5.66
ii  iputils-ping 3:20161105-1
ii  isc-dhcp-client  4.3.5-3.1
ii  lsb-base 9.20170808
ii  psmisc   23.1-1
ii  python   2.7.14-4
ii  python-dbus  1.2.6-1
ii  python-gobject   3.26.1-2
ii  python-wicd  1.7.4+tb2-5
ii  wireless-tools   30~pre9-12+b1
ii  wpasupplicant2:2.6-15

Versions of packages wicd-daemon recommends:
ii  rfkill 2.31.1-0.5
ii  wicd-curses [wicd-client]  1.7.4+tb2-5
ii  wicd-gtk [wicd-client] 1.7.4+tb2-5

Versions of packages wicd-daemon suggests:
ii  pm-utils  1.4.1-17

Versions of packages wicd-gtk depends on:
ii  python 2.7.14-4
ii  python-glade2  2.24.0-5.1+b1
ii  python-gtk22.24.0-5.1+b1

Versions of packages wicd-gtk recommends:
ii  gksu   2.0.2-9+b1
pn  python-notify  

Versions of packages wicd-curses depends on:
ii  python2.7.14-4
ii  python-urwid  1.3.1-2+b2

Versions of packages wicd-curses recommends:
ii  sudo  1.8.21p2-3

Versions of packages python-wicd depends on:
ii  net-tools  1.60+git20161116.90da8a0-2
ii  python 2.7.14-4

Versions of packages python-wicd suggests:
pn  ethtool   
ii  iproute2  4.15.0-3

-- debconf information:
* wicd/users: neels

Bug#894508: dlib: SONAME version number should not be based on package version number

[Hugo Lefeuvre]

Package: dlib
Version: 18.18-2

Hi,

Currently the SONAME version number of dlib in Debian is the same as the
package's version number:

> $ cat debian/patches/fix-soname.patch 
> Set the libdlib soname to libdlib.so.18
> --- a/dlib/CMakeLists.txt
> +++ b/dlib/CMakeLists.txt
> @@ -413,7 +413,8 @@
> if(UNIX)
> set_target_properties(dlib-shared PROPERTIES
>  OUTPUT_NAME dlib 
> -VERSION ${VERSION})
> +VERSION ${VERSION}
> +SOVERSION 
> ${CPACK_PACKAGE_VERSION_MAJOR})
> install(TARGETS dlib dlib-shared
> EXPORT dlib 
> RUNTIME DESTINATION bin # Windows (including cygwin) 
> considers .dll to be runtime artifacts

While I am not an expert in packaging of shared libraries, this looks
like a bad practice. The Debian Library Packaging guide[0] states:

>  In most cases, if a package version matches the SONAME, it is a sign
>  that there is a problem with the versioning scheme. Scrap it, and
>  bash the upstream with the libtool manual. It is usually a good sign
>  that either he has not read the manual thoroughly, or he has not
>  understood it, or both. 

Going through the history of the git repository, it looks like you
introduced this patch in order to fix the following lintian warning:

> W: dlib: package-name-doesnt-match-sonames libdlib18.18.0
> N:
> N:The package name of a library package should usually reflect the soname
> N:of the included library. The package name can determined from the
> N:library file name with the following code snippet:
> N:
> N: $ objdump -p /path/to/libfoo-bar.so.1.2.3 | sed -n 
> -e's/^[[:space:]]*SONAME[[:space:]]*//p' | \
> N: sed -r -e's/([0-9])\.so\./\1-/; s/\.so(\.|$)//; y/_/-/;s/(.*)/\L&/'
> N:
> N:Severity: normal, Certainty: possible
> N:
> N:Check: binaries, Type: binary, udeb

IMO a correct fix would rather be to change binary package name to
libdlib18.18-0, instead of changing the SONAME.

I'm currently working on the next Debian release of dlib, see
#894118[1].

Regards,
 Hugo

[0] https://www.netfort.gr.jp/~dancer/column/libpkg-guide/libpkg-guide.html
[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=894118

-- 
 Hugo Lefeuvre (hle)|www.owl.eu.com
4096/ 9C4F C8BF A4B0 8FC5 48EB 56B8 1962 765B B9A8 BACA


signature.asc
Description: PGP signature

Bug#877871: RFP: pyside2 -- Python bindings for Qt5

[W. Martin Borgert]

Upstream seems to make good progress:
http://lists.qt-project.org/pipermail/pyside/2018-March/002557.html

Bug#894507: new version 2.0.0-dev must be packaged

[W. Martin Borgert]

Package: src:python-ghost
Version: 0.2.3-1

The current version depends on pyside, which will be removed from Debian.
The new version depends on pyside2, which is not yet in Debian (#877871).
-- 
"Furthermore, I consider that PySide2 must be packaged" -- Qt the Elder

Bug#894506: RFS: aj-snapshot/0.9.8-1 [QA upload]

[Fabian Wolff]

Package: sponsorship-requests
Severity: normal

Dear mentors,

I am looking for a sponsor for a QA upload of the aj-snapshot package.

My changes are summarized in the latest changelog entry:

 aj-snapshot (0.9.8-1) unstable; urgency=medium

   * QA upload.
   * New upstream release.
   * Update debian/copyright.
   * Upgrade to debhelper compat level 11:
  - Remove useless dh-autoreconf build dependency.
  - Remove unnecessary --parallel dh argument in debian/rules.
  - Remove unnecessary --with autoreconf dh argument in debian/rules.
   * Upgrade to Standards-Version 4.1.3 in debian/control (no changes).
   * Remove fixman.patch (fixed upstream).
   * Add 00-fix-long-options.patch (Closes: #715625).

  -- Fabian Wolff   Sat, 31 Mar 2018 15:09:03 +0200


The package is available on Mentors:

  https://mentors.debian.net/package/aj-snapshot
  
https://mentors.debian.net/debian/pool/main/a/aj-snapshot/aj-snapshot_0.9.8-1.dsc

Thank you!

Best regards,
Fabian

Bug#869151: kolourpaint4: Getting 'Cannot talk to klauncher' error in Save dialog

[Michael Groß]

Just installing the package "kinit" solved the problem for me.

Bug#894476: RCC: provide option to encode EPOCH timestamp

[Lisandro Damián Nicanor Pérez Meyer]

Thanks for the bug! And sorry for the to posting :-(

I'll try to take a look into this.

El sáb., 31 de mar. de 2018 07:09, Chris Lamb  escribió:

> Hi,
>
> > While investigating ultracopier's lack of build reproducibility, I found
> > out that rcc encodes the timestamp of the files the QRC file being
> > compiled references
>
> Indeed, we've been tracking this for a while in the Reproducible Builds
> project [0] but, without a patch, we did not wish to bother you with a
> bug. :)
>
> It is affecting at least 4 or 5 other packages. I had previously tracked
> it down to [1].
>
> Regarding the solution, I think I would actually prefer to see something
> consuming SOURCE_DATE_EPOCH[1] rather than adding an option to set a
> specific timestamp.
>
>   [0] https://reproducible-builds.org/
>   [1]
> https://sources.debian.org/src/qtbase-opensource-src/5.9.2+dfsg-12/src/tools/rcc/rcc.cpp/#L207-L212
>   [2] https://reproducible-builds.org/specs/source-date-epoch/
>
>
> Best wishes,
>
> --
>   ,''`.
>  : :'  : Chris Lamb
>  `. `'`  la...@debian.org / chris-lamb.co.uk
>`-
>
>

Bug#889669: nvidia-graphics-drivers: solve the upgrade problem

[Philipp Kern]

On 2018-03-30 20:02, Luca Boccassi wrote:

On Mon, 2018-03-26 at 18:45 +0200, Philipp Kern wrote:

I would like to understand better what the current set of packages
helps
with, though. It is true that I hadn't considered that you are
shipping
so many packages right now. However, you seem to also hardcode the
dependencies between them with a lot of substvars in the packaging,
which is understandable given the non-free nature of them. But at the
same time it makes it more muddy as to what problem that solves.

Well that's the Debian policy - one shared library per package, that's
what we follow.


While this is technically true, they are also far from the regular 
shared library packages, too. People generally don't link against these 
shared libraries. Files are installed not into the regular directories. 
Most of the time newer libraries are not actually co-installable. The 
installed file doesn't necessarily follow the SONAME. (I only spot 
checked as I have spotty connectivity right now.)


This is not about "you're doing it wrong or anything". Instead these are 
just awkward binary blobs that I think can be treated differently than 
usual shared libraries if needed. Especially in case you don't get the 
advantages of the split packaging with the binaries you are provided by 
NVidia.


I'll try to come up with a longer answer to the remaining bits. I 
suppose we should play this through as an example with the current 
packaging and then check what's acceptable and what's not acceptable.



Yes, the legacy drivers (340xx and 304xx at the moment, although the
latter is out of support so I guess we'll drop it in buster) are co-
installable. There are update-alternatives for those too. We have a
script to make it easier to manage those and the glx provider (mesa,
fglrx, nvidia), it's update-glx from the update-glx package.

You can find the scripts and configs in the git repo:
https://salsa.debian.org/nvidia-team/glx-alternatives


This means that users are expected to call update-glx on bootup if the 
driver in the installation doesn't match the installed hardware, right? 
My hope would be that if we get it to work consistently for minor 
revisions that we can support legacy drivers with the same mechanism: 
When a legacy module is loadable, we make sure that the GLX bits point 
to the correct library version for the card installed. I know that in 
regular desktop systems card architecture changes are rare and users 
expect to tend to the machine manually in this case. However in the case 
of bigger pool setups and imaging, modern Linux and X.org just works, 
except the NVidia bits.


Kind regards and thanks a lot for your responses!
Philipp Kern

Bug#894441: dpkg-buildpackage: SOURCE_DATE_EPOCH must ignore bin-nmu changelog entries. Breaks M-A:same

[Philipp Kern]

On 2018-03-30 20:15, Sven Joachim wrote:

On 2018-03-30 15:02 +0100, Chris Lamb wrote:


[adding 894441@ to CC]

Hi Jean-Michel,


Filled as #894441
https://bugs.debian.org/894441


Thanks for this. I was just briefly wondering whether this is related 
to:


  https://lists.debian.org/debian-security/2017/05/msg00011.html


It seems so.  What you are describing there had been noticed by Ian
Jackson before:

https://lists.debian.org/debian-devel/2016/11/msg00328.html

Ian then filed bug #843773 against sbuild, and as a result sbuild (as 
of

version 0.73.0-1) no longer reuses the timestamp of the last changelog
entry in binNMUs.

The same version of sbuild introduced a --binNMU-timestamp option, and 
I

think wanna-build should use it to achieve a consistent
SOURCE_DATE_EPOCH across architectures in binNMUs.  Something along
these lines had already been proposed in #843773.


I'd hold that the sourceful uploads Ubuntu does (XbuildY) are actually a 
cleaner solution to the problem. The cute hack is necessary because a) 
our policies discourage sourceful NMUs heavily and b) scheduling an 
automatic rebuild is more than a simple RPC call and involves a 
re-upload of the whole source package.


Right now wanna-build still has no notion of a consistent state across 
architectures. So just like version picking is already done in higher 
level orchestration (wb) that tool would need to provide the timestamps 
as well. Information is also lost whenever new state is merged, although 
practically that's probably not a problem here because a new sourceful 
build would be pushed to all architectures mostly at once anyway.


Kind regards
Philipp Kern

Bug#894504: backportpackage: sbuild creates .changes for release rather than release-backports

[Christopher Hoskin]

Package: ubuntu-dev-tools
Version: 0.162
Severity: normal

Dear Maintainer,

Using backportpackage with the -b and --builder=sbuild options produces a 
.changes file for release rather than release-backports.

e.g.

backportpackage -b -w build --builder=sbuild --destination=stretch 
--suffix=~bpo9+1 dh-golang

cat build/buildresult/dh-golang_1.34~debian9.0.1~bpo9+1_amd64.changes | grep 
Distribution
Distribution: stretch

This appears to be different to the behaviour with --builder=pbuilder. I think 
pbuilder uses the release specified in debian/changelog to produce the .changes 
file, whereas sbuild overrides this with the option passed to it in --dist.

If I try instead to run:

backportpackage -b -w build --builder=sbuild --destination=stretch-backports 
--suffix=~bpo9+1 dh-golang

Then I get the message:

dpkg-source: info: extracting dh-golang in dh-golang-stretch-backports
dpkg-source: info: unpacking dh-golang_1.34.tar.xz
backportpackage: Error: Unknown release codename stretch-backports

One possible solution would be to append -backports to the release passed to 
sbuild via --dist. The user would then need to have a chroot with a name like 
$release-backports-$arch-sbuild, $release-backports-sbuild, 
$release-backports-$arch or $release-backports. Alternatively the chroot name 
could be specified to sbuild separately with the --chroot option.

Or, backportpackage could be changed to accept release-backports as a 
destination.

Thanks.

Christopher Hoskin

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

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

Versions of packages ubuntu-dev-tools depends on:
ii  binutils   2.28-5
ii  dctrl-tools2.24-2+b1
ii  devscripts 2.17.6+deb9u1
ii  diffstat   1.61-1+b1
ii  distro-info0.14
ii  dpkg-dev   1.18.24
ii  lsb-release9.20161125
ii  perl   5.24.1-3+deb9u2
ii  python 2.7.13-2
ii  python-apt 1.4.0~beta3
ii  python-debian  0.1.30
ii  python-distro-info 0.14
ii  python-httplib20.9.2+dfsg-1
ii  python-launchpadlib1.10.4-1
ii  python-lazr.restfulclient  0.13.4-6
ii  python-ubuntutools 0.157
ii  sudo   1.8.19p1-2.1

Versions of packages ubuntu-dev-tools recommends:
ii  bzr 2.7.0+bzr6619-7+deb9u1
ii  bzr-builddeb2.8.10
ii  ca-certificates 20161130+nmu1
ii  cowbuilder  0.85
ii  debian-archive-keyring  2017.5
ii  debian-keyring  2017.05.28
ii  debootstrap 1.0.89
ii  dput0.12.1
ii  genisoimage 9:1.1.11-3+b2
ii  libwww-perl 6.15-1
ii  lintian 2.5.50.4
ii  patch   2.7.5-1+b2
ii  pbuilder0.228.7
ii  python-dns  2.3.6-3
ii  python-soappy   0.12.22-1
ii  quilt   0.63-8
ii  reportbug   7.1.7+deb9u1
ii  sbuild  0.73.0-4

Versions of packages ubuntu-dev-tools suggests:
ii  python 2.7.13-2
ii  python-simplejson  3.10.0-1
pn  qemu-user-static   

-- no debconf information

Bug#894505: [PATCH] meson: meson-related problem when crossbuilding systemd

[Karsten Merker]

Package: meson
Version: 0.45.1-1
Tags: patch
X-Debbugs-CC: debian-ri...@lists.debian.org
User: debian-ri...@lists.debian.org
Usertags: riscv64

Hello,

we are in the process of bootstrapping a Debian port for the
riscv64 architecture (https://wiki.debian.org/RISC-V).  The
systemd package - which uses meson as its build system - is part
of the build-dependency chain for the essential package set, so
we need to cross-build systemd to be able to complete the
bootstrap process.  Due to the meson issue at

  https://github.com/mesonbuild/meson/issues/3113

it currently isn't possible to crossbuild the systemd package in
Debian. A fix for this is already in upstream meson git at

  
https://github.com/mesonbuild/meson/commit/c4192a04fd3d46ac7a0ee81a158e7b1e3d4f06f8

but not part of the most-recent upstream meson release (0.45.1). 
It would be great if you could carry this one-line patch in the
Debian meson package until a new upstream release including this
fix is available.

Regards,
Karsten
-- 
Gem. Par. 28 Abs. 4 Bundesdatenschutzgesetz widerspreche ich der Nutzung
sowie der Weitergabe meiner personenbezogenen Daten für Zwecke der
Werbung sowie der Markt- oder Meinungsforschung.

Bug#894503: RFP: slick-greeter-settings -- A graphical tool for manipulating the settings of slick-greeter

[Zeid Habjoka]

Package: wnpp
Severity: wishlist

* Package name: slick-greeter-settings
  Version : 1.1.4
  Upstream Author : Clement Lefebvre 
* URL : https://github.com/linuxmint/lightdm-settings
* License : GPL-3+
  Programming Lang: Python
  Description : A graphical tool for manipulating the settings of slick-
greeter

A configuration tool for the LightDM display manager

This tool currently lets users configure slick-greeter.

https://github.com/linuxmint/lightdm-settings

Since this package is already configured for Debian, and may be found pre-
packaged in the linux mint repositiories, I hope it will be possible to add it
to the Debian repositories as well, especially since slick-greeter is already
included.

Bug#859130: Preferred source: a fundamental question

[Geert Stappers]

PARSE ERROR
}}} invite to check package
}} URL of package to check
} Sorry.
} This is about a Forth, where the Assembler source is extracted from a
} kind of database. This database is now part of the source distribution,
} as are the extraction tools (m4).


> 
> This is the url.
> 
> https://mentors.debian.net/package/lina
> 

Found three uploads of version 5.3.0-1 at that URL.

First impression of the 2018-03-28 16:12 version of 5.3.0-1 is that it
still has a gap between the git repo and the .orig.tar.gz.

A closer look will be done by me somewhere in april 2018.
But that should not block reviewing / uploading by others.


Groeten
Geert Stappers
-- 
Leven en laten leven

Bug#894496: RM: xye -- ROM, Dead upstream

[Andreas Rönnquist]

On Sat, 31 Mar 2018 13:39:30 +0200 Emilio Pozuelo Monfort
 wrote:
> On 31/03/18 12:44, Andreas Ronnquist wrote:
> > Package: ftp.debian.org
> > Severity: normal
> > 
> > Xye upstream has been talking about migrating away from sourceforge
> > since 2015, and nothing has happened with that or with any other
> > packaging since the same time.
> 
> Is the package still functional? Does the rest of the team agree with
> this decision?

ok, I'll admit that my communication with the games team has been
lacking regarding this. I'll ask there and see if anyone would have any
objections to this removal. (The package is very low-popcon - 117 last
I looked).
 
> Also it's not clear to me if you want the package removed from
> testing (and so from the next stable release) or also from unstable
> (in which case this bug should have been filed against
> ftp.debian.org).

hmm, I thought I filed it against ftp.d.o ... Anyway, my intention
is to remove it from unstable. Reading the dev-reference I thought that
I filed a bug for removal from unstable, and this would in its turn
later affect the testing package.

best
/Andreas
gus...@debian.org

Bug#894502: python3-matplotlib: Missing distutils dependency

[Ole Streicher]

Package: python3-matplotlib
Version: 2.1.1-2
Severity: serious
Control: affects: -1 python3-astroml python3-aplpy python3-imexam

Dear maintainer,

Matplotlib is currently unusable on sid:

Python 3.6.5 (default, Mar 30 2018, 02:08:52)
[GCC 7.3.0] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import matplotlib
Traceback (most recent call last):
  File "", line 1, in 
  File "/usr/lib/python3/dist-packages/matplotlib/__init__.py", line
110, in 
import distutils.sysconfig
ModuleNotFoundError: No module named 'distutils.sysconfig'

See also #893924.

This makes several packages (which require matplotlib) unusable.

Best regards

Ole