Bug#861522: dman: fall back on newer or older suites when requested manual page not in current suite

[Paul Wise]

Package: debian-goodies
Version: 0.71
Severity: wishlist
File: /usr/bin/dman
X-Debbugs-CC: Antoine Beaupré , debian-...@lists.debian.org

dman currently reports an error when I try to use it to read its own
manual page, because it defaults to stretch with no fallback.

There are several situations where it would be nice to be able to
automatically fall back to the manual page from a different suite:

 * where the package is only in a newer suite:
* when using stable and it was first uploaded after the release
* when using unstable and it was uploaded during the freeze
 * where the package was removed from unstable recently, is still in
   use on a remote system running stable but dman is run on an unstable
   system

I expect this will probably need support on the server side?
If so, please clone this bug to the manpages.debian.org package.

pabs@chianamo ~ $ dman dman
/usr/bin/dman: A download error occurred. Neither
/usr/bin/dman: https://manpages.debian.org/stretch/dman.en.gz nor
/usr/bin/dman: https://manpages.debian.org/stretch/dman.gz could be
fetched.
pabs@chianamo ~ $ dman --release experimental dman
pabs@chianamo ~ $ 

-- System Information:
Debian Release: 9.0
  APT prefers testing-debug
  APT policy: (900, 'testing-debug'), (900, 'testing'), (860, 
'testing-proposed-updates'), (850, 'buildd-testing-proposed-updates'), (800, 
'unstable-debug'), (800, 'unstable'), (790, 'buildd-unstable'), (700, 
'experimental-debug'), (700, 'experimental'), (690, 'buildd-experimental')
Architecture: amd64 (x86_64)

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

Versions of packages debian-goodies depends on:
ii  curl  7.52.1-5
ii  dctrl-tools [grep-dctrl]  2.24-2+b1
ii  perl  5.24.1-2
ii  python3   3.5.3-1
ii  whiptail  0.52.19-1+b1

Versions of packages debian-goodies recommends:
ii  lsof  4.89+dfsg-0.1

Versions of packages debian-goodies suggests:
ii  lsb-release 9.20161125
ii  popularity-contest  1.64
ii  xdg-utils   1.1.1-1
ii  zenity  3.22.0-1+b1

-- no debconf information

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


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

Bug#789592: ITP: tuned -- tool that performs monitoring and adaptive

[gustavo panizzo]

Hello Evgeni

I've pushed a few lintian fixes, feel free to upload 

cheers!

-- 
1AE0 322E B8F7 4717 BDEA BF1D 44BB 1BA7 9F6C 6333

keybase: https://keybase.io/gfa

Bug#861523: bup: FTBFS: t/test-ls.sh:64 '1977-09-05-135600 latest' = '1977-09-05-125600 latest' FAILED

[Chris Lamb]

Source: bup
Version: 0.29-3
Severity: serious
Justification: fails to build from source
User: reproducible-bui...@lists.alioth.debian.org
Usertags: ftbfs
X-Debbugs-Cc: reproducible-b...@lists.alioth.debian.org

Dear Maintainer,

bup fails to build from source in unstable/amd64:

  […]

 dh_auto_test
make -j1 test VERBOSE=1
  make[1]: Entering directory '«BUILDDIR»'
  Detected release tree; skipping version configuration
  if test -e t/tmp/test-log; then rm -r t/tmp/test-log; fi
  mkdir -p t/tmp/test-log
  ./wvtest watch --no-counts \
make runtests-python runtests-cmdline 2>t/tmp/test-log/$$.log
  Testing "all" in make runtests-python runtests-cmdline:
  ! lib/bup/t/tbloom.py  test_bloom: . 0.064s ok
  ! lib/bup/t/tclient.py  test_server_split_with_indexes:  0.907s ok
  ! lib/bup/t/tclient.py  test_multiple_suggestions: ... 1.021s ok
  ! lib/bup/t/tclient.py  test_dumb_client_server: ... 0.549s ok
  ! lib/bup/t/tclient.py  test_midx_refreshing: . 1.002s ok
  ! lib/bup/t/tclient.py  test_remote_parsing: . 0.006s ok
  ! lib/bup/t/tgit.py  testmangle: ... 0.002s ok
  ! lib/bup/t/tgit.py  testencode: ... 0.004s ok
  ! lib/bup/t/tgit.py  testpacks: 

 0.480s ok
  ! lib/bup/t/tgit.py  test_pack_name_lookup: . 
2.863s ok
  ! lib/bup/t/tgit.py  test_long_index: ... 0.036s ok
  ! lib/bup/t/tgit.py  test_check_repo_or_die: ... 0.011s ok
  ! lib/bup/t/tgit.py  test_commit_parsing:  0.091s ok
  ! lib/bup/t/tgit.py  test_new_commit: . 0.272s ok
  ! lib/bup/t/tgit.py  test_list_refs:  0.569s ok
  ! lib/bup/t/thashsplit.py  test_nonresident_page_regions: 
 0.003s ok
  ! lib/bup/t/thashsplit.py  test_uncache_ours_upto:  0.001s ok
  ! lib/bup/t/thashsplit.py  test_rolling_sums: . 0.002s ok
  ! lib/bup/t/thashsplit.py  test_fanout_behaviour:  0.004s ok
  ! lib/bup/t/thelpers.py  test_next:  0.001s ok
  ! lib/bup/t/thelpers.py  test_fallback_next:  0.001s ok
  ! lib/bup/t/thelpers.py  test_parse_num: .. 0.001s ok
  ! lib/bup/t/thelpers.py  test_detect_fakeroot: . 0.000s ok
  ! lib/bup/t/thelpers.py  test_path_components: . 0.000s ok
  ! lib/bup/t/thelpers.py  test_stripped_path_components: ... 0.002s ok
  ! lib/bup/t/thelpers.py  test_grafted_path_components: ... 0.002s ok
  ! lib/bup/t/thelpers.py  test_readpipe: .. 0.006s ok
  ! lib/bup/t/thelpers.py  test_batchpipe: ... 0.010s ok
  ! lib/bup/t/thelpers.py  test_atomically_replaced_file:  0.006s ok
  ! lib/bup/t/thelpers.py  test_utc_offset_str:  0.001s ok
  ! lib/bup/t/thelpers.py  test_valid_save_name: 
. 0.010s ok
  ! lib/bup/t/tindex.py  index_basic: . 0.001s ok
  ! lib/bup/t/tindex.py  index_writer:  0.006s ok
  ! lib/bup/t/tindex.py  index_negative_timestamps: .. 0.003s ok
  ! lib/bup/t/tindex.py  index_dirty: ..

Bug#861524: libunwind: Please enable hppa in debian/control

[John Paul Adrian Glaubitz]

Source: libunwind
Version: 1.1-4.1
Severity: normal
User: debian-h...@lists.debian.org
Usertags: hppa

Hi!

Although libunwind has upstream support for PA-RISC (HPPA), hppa is
not enabled in the Architecture fields in debian/control.

I just did a quick build test and enabled hppa with a simple regexp:

  $ sed -i 's/mips64el/hppa/g' debian/control

After that, the package built just fine on hppa.

Can you please append "hppa" to all Architecture fields in
debian/control?

Thanks,
Adrian

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

Bug#848671: Bug#640162: fixed in xpdf 3.03-4

[kardan]

notfixed 640162 3.04-4
notfixed 640486 3.04-4
thanks

848671 is duplicate of above archived bugs.

Workaround: Comment "include /etc/xpdf/includes" in /etc/xpdf/xpdfrc.

$ strings /usr/bin/xpdf.real|grep 0:t|head
Unknown named action: '{0:t}'
Unknown link action type: '{0:t}'
Bad 'fontFile' config file command ({0:t}:{1:d})
Bad 'psFile' config file command ({0:t}:{1:d})
Bad 'psImageableArea' config file command ({0:t}:{1:d})
Bad 'psLevel' config file command ({0:t}:{1:d})
Bad 'initialZoom' config file command ({0:t}:{1:d})
Bad 'screenType' config file command ({0:t}:{1:d})
Bad 'bind' config file command ({0:t}:{1:d})
Bad 'unbind' config file command ({0:t}:{1:d})


References from #640162:

Derek B. Noonburg:
"Xpdf 3.03 changed the font configuration syntax around -- that may be
what you're running into.  Look at the "Upgrading from Xpdf 3.02"
section in the README file for more info."
"My guess is that the Debian build setup modified something in the Xpdf
source code (maybe xpdf/Error.cc?) which is breaking the error
reporting.  I'm not sure who's in charge of the Xpdf Debian package, but
hopefully this message will reach them."

Michael Gilbert:
"It looks like this is probably due to the fact that the default Debian
xpdfrc file was still using displayFontT1. I've just fixed that."

Bug#861525: unblock: lintian/2.5.50.2

[Niels Thykier]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock

Please unblock package lintian

The 2.5.50.2 unload works around a "perl stack" corruption (not to be
confused with perl's C stack) and makes a gnuplot file compability
with gnuplot 5 (so it works with the version we are shipping in
stretch).

I will expand on the stack corruption below in case it is relevant for
your understanding of the issue and the fix[1]. That said, the fix is
shorter than my explanation, so you may just want to skip ahead to the
debdiff.

unblock lintian/2.5.50.2

Thanks,
~Niels

[1]
Perl stack corruption
=

For most runs, "perl stack" corruption occurs but perl never notices
it until it has to unwind the stack to the point of the corruption.
On a successful run, the lintian tools will always exit from their
main sub and therefore avoid the issue.  To reproduce this bug, you
will have to cause the tool to throw an exception that generates a
stack trace (or unwinds past the main sub).

That is very trivial to do with the reporting framework (but could in
theory happen in lintian-info and lintian-lab-tool).  It cannot be
reproduced in lintian itself.  Lintian 2.5.50.2 is started via an
"exec" call after the stack corruption, so lintian cannot unwind to
the corrupted stack.

To reproduce, install lintian 2.5.50.1 and run:

"""
$ mkdir empty-dir
$ /usr/share/lintian/frontend/dplint reporting-sync-state \
  --state-dir empty-dir \
  --mirror-path /value-does-not-matter \
  --distributions value-does-not-matter \
  --architectures value-does-not-matter \
  --mirror-areas value-does-not-matter \
  --desired-version 2.5.50.1
Can't locate object method "errno" via package "Bizarre copy of ARRAY in list 
assignment at /usr/share/perl/5.24/Carp.pm line 229.
" (perhaps you forgot to load "Bizarre copy of ARRAY in list assignment at 
/usr/share/perl/5.24/Carp.pm line 229.
"?) at /usr/share/perl5/Lintian/Util.pm line 1614.
"""

The output here is a "double fault".  First, perl notices the
corruption and throws a string exception with the text:

  "Bizarre copy of ARRAY in list assignment at /usr/share/perl/5.24/Carp.pm 
line 229.\n"

Lintian catches this assuming it is an autodie exception and then
tries to call the "errno" method on it.  Obviously this fails again
leading to the weird error message.

The work around for this is to avoid passing the "@ARGV" variable on
the stack (i.e. passing as an argument to a perl sub).  That way, the
perl stack is not corrupted when Getopt::Long parses the options.


Thanks,
~Niels

Bug#861525: unblock: lintian/2.5.50.2

[Niels Thykier]

Niels Thykier:
> Package: release.debian.org
> Severity: normal
> User: release.debian@packages.debian.org
> Usertags: unblock
> 
> Please unblock package lintian
> 
> The 2.5.50.2 unload works around a "perl stack" corruption (not to be
> confused with perl's C stack) and makes a gnuplot file compability
> with gnuplot 5 (so it works with the version we are shipping in
> stretch).
> 
> I will expand on the stack corruption below in case it is relevant for
> your understanding of the issue and the fix[1]. That said, the fix is
> shorter than my explanation, so you may just want to skip ahead to the
> debdiff.
> 
> unblock lintian/2.5.50.2
> 
> Thanks,
> ~Niels
> 
> [...]


Fumble-fingered reportbug, here is the debdiff.  The upload is in the
queue and should be ACCEPTed soon. :)

Thanks,
~Niels

diff -Nru lintian-2.5.50.1/debian/changelog lintian-2.5.50.2/debian/changelog
--- lintian-2.5.50.1/debian/changelog   2017-02-04 16:05:07.0 +0100
+++ lintian-2.5.50.2/debian/changelog   2017-04-30 09:40:24.0 +0200
@@ -1,3 +1,16 @@
+lintian (2.5.50.2) unstable; urgency=medium
+
+  * frontend/dplint:
++ [NT] Work around a "Bizarre Copy" bug in perl that could trigger
+  on errors.  Notably, this bug causes the reporting framework in
+  lintian to break with a very non-informative error when the
+  "state-cache" is not present.
+
+  * reporting/graphs/tags.gpi:
++ [NT] Tweak tags.gpi so it works with gnuplot 5.
+
+ -- Niels Thykier   Sun, 30 Apr 2017 07:40:24 +
+
 lintian (2.5.50.1) unstable; urgency=medium
 
   * debian/copyright:
diff -Nru lintian-2.5.50.1/frontend/dplint lintian-2.5.50.2/frontend/dplint
--- lintian-2.5.50.1/frontend/dplint2017-01-29 21:00:48.0 +0100
+++ lintian-2.5.50.2/frontend/dplint2017-04-30 09:34:30.0 +0200
@@ -82,7 +82,7 @@
 }
 
 sub run_tool {
-my ($truename, $tool, @args) = @_;
+my ($truename, $tool) = @_;
 for my $include_dir (@INCLUDE_DIRS) {
 my $tool_path = "$include_dir/commands/${tool}";
 my $tool_pm_path = "${tool_path}.pm";
@@ -92,12 +92,12 @@
 }
 {
 # Scope here it to avoid a warning about exec not returning.
-exec {$tool_path} $truename, @args;
+exec {$tool_path} $truename, @ARGV;
 }
 local $" = ' ';
 error(
 "Running $tool failed!",
-"  Command: $tool_path @args",
+"  Command: $tool_path @ARGV",
 "  Error from exec: $!"
 );
 }
@@ -273,7 +273,7 @@
 error("Built-in $cmd returned unexpectedly");
 }
 $truename //= $cmd;
-run_tool($truename, $cmd, @ARGV);
+run_tool($truename, $cmd);
 error('run_tool returned unexpectedly');
 }
 
diff -Nru lintian-2.5.50.1/frontend/lintian lintian-2.5.50.2/frontend/lintian
--- lintian-2.5.50.1/frontend/lintian   2017-01-29 21:00:48.0 +0100
+++ lintian-2.5.50.2/frontend/lintian   2017-04-30 09:34:30.0 +0200
@@ -82,7 +82,7 @@
 }
 
 sub run_tool {
-my ($truename, $tool, @args) = @_;
+my ($truename, $tool) = @_;
 for my $include_dir (@INCLUDE_DIRS) {
 my $tool_path = "$include_dir/commands/${tool}";
 my $tool_pm_path = "${tool_path}.pm";
@@ -92,12 +92,12 @@
 }
 {
 # Scope here it to avoid a warning about exec not returning.
-exec {$tool_path} $truename, @args;
+exec {$tool_path} $truename, @ARGV;
 }
 local $" = ' ';
 error(
 "Running $tool failed!",
-"  Command: $tool_path @args",
+"  Command: $tool_path @ARGV",
 "  Error from exec: $!"
 );
 }
@@ -273,7 +273,7 @@
 error("Built-in $cmd returned unexpectedly");
 }
 $truename //= $cmd;
-run_tool($truename, $cmd, @ARGV);
+run_tool($truename, $cmd);
 error('run_tool returned unexpectedly');
 }
 
diff -Nru lintian-2.5.50.1/frontend/lintian-info 
lintian-2.5.50.2/frontend/lintian-info
--- lintian-2.5.50.1/frontend/lintian-info  2017-01-29 21:00:48.0 
+0100
+++ lintian-2.5.50.2/frontend/lintian-info  2017-04-30 09:34:30.0 
+0200
@@ -82,7 +82,7 @@
 }
 
 sub run_tool {
-my ($truename, $tool, @args) = @_;
+my ($truename, $tool) = @_;
 for my $include_dir (@INCLUDE_DIRS) {
 my $tool_path = "$include_dir/commands/${tool}";
 my $tool_pm_path = "${tool_path}.pm";
@@ -92,12 +92,12 @@
 }
 {
 # Scope here it to avoid a warning about exec not returning.
-exec {$tool_path} $truename, @args;
+exec {$tool_path} $truename, @ARGV;
 }
 local $" = ' ';
 error(
 "Running $tool failed!",
-"  Command: $tool_path @args",
+"  Command: $tool_path @ARGV",
  

Bug#800134: +1

[Giovanni Mascellani]

Hi,

Il 29/04/2017 16:17, Joey Hess ha scritto:
> IMHO, wotsap should support full length key fingerprints, I don't want
> to use any form of truncated ids when finding trust paths.

I fully agree. Unfortunately at the moment wotsap is not really
maintained by anyone. I tried to do something here:

  https://github.com/giomasce/wotsap

But then ran out of time again. There is also some discussion here:

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

I will try to put everything together as soon as I have some time.
Contributions are, of course, welcome.

Gio.
-- 
Giovanni Mascellani 
PhD Student - Scuola Normale Superiore, Pisa, Italy

http://poisson.phc.unipi.it/~mascellani



signature.asc
Description: OpenPGP digital signature

Bug#861526: unblock: freetype/2.6.3-3.2

[Salvatore Bonaccorso]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock

Hi

Please unblock package freetype. It actually has already but it needs
an ack as well for d-i.

The update fixes two CVEs,

 - CVE-2017-8105, #861220
 - CVE-2017-8287, #861308

and adressed in a DSA for stable. Would thus be great to have the
fixes as well in stretch to avoid a regression.

unblock freetype/2.6.3-3.2

Regards,
Salvatore
diff -u freetype-2.6.3/debian/changelog freetype-2.6.3/debian/changelog
--- freetype-2.6.3/debian/changelog
+++ freetype-2.6.3/debian/changelog
@@ -1,3 +1,12 @@
+freetype (2.6.3-3.2) unstable; urgency=high
+
+  * Non-maintainer upload.
+  * Better protect `flex' handling (CVE-2017-8105) (Closes: #861220)
+  * t1_builder_close_contour: Add safety guard (CVE-2017-8287)
+(Closes: #861308)
+
+ -- Salvatore Bonaccorso   Thu, 27 Apr 2017 20:57:40 +0200
+
 freetype (2.6.3-3.1) unstable; urgency=medium
 
   * Non-maintainer upload.
diff -u freetype-2.6.3/debian/patches-freetype/series 
freetype-2.6.3/debian/patches-freetype/series
--- freetype-2.6.3/debian/patches-freetype/series
+++ freetype-2.6.3/debian/patches-freetype/series
@@ -6,0 +7,2 @@
+CVE-2017-8105-psaux-Better-protect-flex-handling.patch
+CVE-2017-8287-src-psaux-psobjs.c-t1_builder_close_contour-Add-safe.patch
only in patch2:
unchanged:
--- 
freetype-2.6.3.orig/debian/patches-freetype/CVE-2017-8105-psaux-Better-protect-flex-handling.patch
+++ 
freetype-2.6.3/debian/patches-freetype/CVE-2017-8105-psaux-Better-protect-flex-handling.patch
@@ -0,0 +1,43 @@
+From f958c48ee431bef8d4d466b40c9cb2d4dbcb7791 Mon Sep 17 00:00:00 2001
+From: Werner Lemberg 
+Date: Fri, 24 Mar 2017 09:15:10 +0100
+Subject: [PATCH] [psaux] Better protect `flex' handling.
+
+Reported as
+
+  https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=935
+
+* src/psaux/t1decode.c (t1_decoder_parse_charstrings)
+: Since there is not a single flex operator but a
+series of subroutine calls, malformed fonts can call arbitrary other
+operators after the start of a flex, possibly adding points.  For
+this reason we have to check the available number of points before
+inserting a point.
+---
+diff --git a/src/psaux/t1decode.c b/src/psaux/t1decode.c
+index af7b465..7dd4513 100644
+--- a/src/psaux/t1decode.c
 b/src/psaux/t1decode.c
+@@ -780,10 +780,19 @@
+ /* point without adding any point to the outline*/
+ idx = decoder->num_flex_vectors++;
+ if ( idx > 0 && idx < 7 )
++{
++  /* in malformed fonts it is possible to have other */
++  /* opcodes in the middle of a flex (which don't*/
++  /* increase `num_flex_vectors'); we thus have to   */
++  /* check whether we can add a point*/
++  if ( FT_SET_ERROR( t1_builder_check_points( builder, 1 ) ) )
++goto Syntax_Error;
++
+   t1_builder_add_point( builder,
+ x,
+ y,
+ (FT_Byte)( idx == 3 || idx == 6 ) );
++}
+   }
+   break;
+ 
+-- 
+2.1.4
+
only in patch2:
unchanged:
--- 
freetype-2.6.3.orig/debian/patches-freetype/CVE-2017-8287-src-psaux-psobjs.c-t1_builder_close_contour-Add-safe.patch
+++ 
freetype-2.6.3/debian/patches-freetype/CVE-2017-8287-src-psaux-psobjs.c-t1_builder_close_contour-Add-safe.patch
@@ -0,0 +1,32 @@
+From 3774fc08b502c3e685afca098b6e8a195aded6a0 Mon Sep 17 00:00:00 2001
+From: Werner Lemberg 
+Date: Sun, 26 Mar 2017 08:32:09 +0200
+Subject: [PATCH] * src/psaux/psobjs.c (t1_builder_close_contour): Add safety
+ guard.
+
+Reported as
+
+  https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=941
+---
+diff --git a/src/psaux/psobjs.c b/src/psaux/psobjs.c
+index d18e821..0baf836 100644
+--- a/src/psaux/psobjs.c
 b/src/psaux/psobjs.c
+@@ -1718,6 +1718,14 @@
+ first = outline->n_contours <= 1
+ ? 0 : outline->contours[outline->n_contours - 2] + 1;
+ 
++/* in malformed fonts it can happen that a contour was started */
++/* but no points were added*/
++if ( outline->n_contours && first == outline->n_points )
++{
++  outline->n_contours--;
++  return;
++}
++
+ /* We must not include the last point in the path if it */
+ /* is located on the first point.   */
+ if ( outline->n_points > 1 )
+-- 
+2.1.4
+

Bug#789592: ITP: tuned -- tool that performs monitoring and adaptive

[Evgeni Golov]

On Sun, Apr 30, 2017 at 03:14:10PM +0800, gustavo panizzo wrote:
> I've pushed a few lintian fixes, feel free to upload 

thanks, uploaded

Bug#861112: xsane: always crashes on start

[Wolfgang Schweer]

On Mon, Apr 24, 2017 at 11:49:46PM +0300, Aaro Koskinen wrote:
> On Mon, Apr 24, 2017 at 10:21:47PM +0200, John Paul Adrian Glaubitz wrote:
> > Control: tags -1 moreinfo
> > > xsane with 1 network scanner defined in /etc/sane.d/net.conf
> > > crashes always on start:

While testing Debian Edu Stretch (virtualbox network 10.0.0.0/8 with 
gateway to a 192.168.178.0/24 LAN)) I tested to access a scanner 
connected to 192.168.178.2 (Jessie workstation, USB scanner). It worked 
like expected (scanimage, scanlite, xsane).

> > Would you mind sharing your net.conf file with this bug report so
> > that we can try to reproduce the problem?

> ## net backend options
> # Timeout for the initial connection to saned. This will prevent the backend
> # from blocking for several minutes trying to connect to an unresponsive
> # saned host (network outage, host down, ...). Value in seconds.
> # connect_timeout = 60
> 
> ## saned hosts
> # Each line names a host to attach to.
> # If you list "localhost" then your backends can be accessed either
> # directly or through the net backend.  Going through the net backend
> # may be necessary to access devices that need special privileges.
> # localhost
> 192.168.1.100

Same here, only the IP differs; see above.

This is the 'scanimage -L' output ('tjener' is the Debian Edu main 
server):

[jdoe@tjener ~]$ scanimage -L
device `net:192.168.178.2:gt68xx:libusb:001:014' is a Mustek ScanExpress 
1248 UB flatbed scanner

Output on the Jessie workstation for comparison:

[jdoe@tjener ~]$ ssh jdoe@192.168.178.2 scanimage -L
device `gt68xx:libusb:001:014' is a Mustek ScanExpress 1248 UB flatbed 
scanner

Same succes on a workstation inside the 10.0.0.0/8 network.

So I suspect there must be something else in addition causing the 
issue. 

Wolfgang


signature.asc
Description: PGP signature

Bug#861134: slim: Reloads automatically and queries login-prompt after running window manager for some (a short) time

[johnw]

Hello all, any update?  how to solve it?

Please help, thanks.



Hi all,

I need more informations about this bug, I can't confirm that on my
configuration.

Have you something specific on start splash or plymouth?

I will try to reproduce this bug for fix.


--
Key fingerprint: CDB3 6C62 254B C088 1E5D DD32 182C 97DB CF2C 80AC

Bug#851066: flashplugin-nonfree: Mismatch between detected and available versions (Download file not available at people.debian.org)

[Leo L. Schwab]

Package: flashplugin-nonfree
Version: 1:3.7
Followup-For: Bug #851066

Okay, attached is that patch I mentioned in my previous message.
This patch adds a new option to update-flashplugin-nonfree:


--using 
Specifies the name of a local tar file instead of attempting to
discover and download the latest version.  This file is presumed to be a tar
file downloaded by hand from Adobe.com, containing the flash plugin
appropriate for your machine arch.  No checks are performed to ensure the
tar file is authentic; you should download such plugins *only* from
Adobe.com.


Hmm.  Now that I think about it, I should update the docs, too.

Seems to work well for me.  Feedback welcome.

Schwab


-- Package-specific info:
Debian version: 9.0
Architecture: amd64
Package version: 1:3.7
Adobe Flash Player version: [@LNX 25,0,0,148
MD5 checksums:
d03f607cf2814884d0db497dff934b34  
/var/cache/flashplugin-nonfree/flash_player_npapi_linux.x86_64.tar.gz
29c85bc8504422120cf89702986ff8e1  
/var/cache/flashplugin-nonfree/get-upstream-version.pl
82cd4f82b2023fad1d43092de8e002a7  
/var/cache/flashplugin-nonfree/install_flash_player_11_linux.x86_64.tar.gz
f9210feb0ef3aa6c65fad905eb2e1aa2  
/usr/lib/flashplugin-nonfree/libflashplayer.so
Alternatives:
flash-mozilla.so - auto mode
  link best version is /usr/lib/flashplugin-nonfree/libflashplayer.so
  link currently points to 
/usr/lib/flashplugin-nonfree/libflashplayer.so
  link flash-mozilla.so is /usr/lib/mozilla/plugins/flash-mozilla.so
/usr/lib/flashplugin-nonfree/libflashplayer.so - priority 50
lrwxrwxrwx 1 root root 34 Aug  4  2016 
/usr/lib/mozilla/plugins/flash-mozilla.so -> /etc/alternatives/flash-mozilla.so
/usr/lib/mozilla/plugins/flash-mozilla.so: symbolic link to 
/etc/alternatives/flash-mozilla.so

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

Kernel: Linux 4.9.0-2-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 flashplugin-nonfree depends on:
ii  binutils   2.28-4
ii  ca-certificates20161130
ii  debconf [debconf-2.0]  1.5.60
ii  gnupg  2.1.18-6
ii  gnupg2 2.1.18-6
ii  libatk1.0-02.22.0-1
ii  libcairo2  1.14.8-1
ii  libcurl3-gnutls7.52.1-5
ii  libfontconfig1 2.11.0-6.7+b1
ii  libfreetype6   2.6.3-3.1
ii  libgcc11:6.3.0-14
ii  libglib2.0-0   2.50.3-2
ii  libgtk2.0-02.24.31-2
ii  libnspr4   2:4.12-6
ii  libnss32:3.26.2-1
ii  libpango1.0-0  1.40.5-1
ii  libstdc++6 6.3.0-14
ii  libx11-6   2:1.6.4-3
ii  libxext6   2:1.3.3-1+b2
ii  libxt6 1:1.1.5-1
ii  wget   1.19.1-3

flashplugin-nonfree recommends no packages.

Versions of packages flashplugin-nonfree suggests:
pn  firefox-esr
ii  fonts-dejavu   2.37-1
pn  hal-flash  
pn  iceweasel  
pn  konqueror-nsplugins
ii  ttf-mscorefonts-installer  3.6
pn  ttf-xfree86-nonfree

-- no debconf information
diff --git a/update-flashplugin-nonfree b/update-flashplugin-nonfree
index dac8e8f..d63fa36 100755
--- a/update-flashplugin-nonfree
+++ b/update-flashplugin-nonfree
@@ -39,16 +39,19 @@ show_usage() {
echo "Additional options:"
echo "  --verbose"
echo "  --quiet"
+   echo "  --using "
exit 1
 }
 
-getopt_temp=`getopt -o iusfvqn --long 
install,uninstall,status,fast,verbose,quiet -n 'update-flashplugin-nonfree' -- 
"$@"` || show_usage
+getopt_temp=`getopt -o iusfvqn --long 
install,uninstall,status,fast,verbose,quiet,using: -n 
'update-flashplugin-nonfree' -- "$@"` || show_usage
 eval set -- "$getopt_temp" || show_usage
 
 ACTION=none
 fast=no
 verbose=no
 quiet=no
+localtarfile=""
+localtarfile_fp=""
 
 GREP_OPTIONS=
 
@@ -87,6 +90,11 @@ do
quiet=yes
shift
;;
+   --using)
+   localtarfile="$2"
+   shift
+   shift
+   ;;
--)
shift
break
@@ -103,6 +111,11 @@ done
 
 [ "$verbose" != "yes" ] || echo "options : $getopt_temp"
 
+if [ "$localtarfile" != "" ]; then
+   [ -f "$localtarfile" ] || die_hard "$localtarfile: file not found"
+   localtarfile_fp=`realpath "$localtarfile"`
+fi
+
 UNPACKDIR=`mktemp -d /tmp/flashplugin-nonfree.XX` || die_hard "mktemp 
failed"
 echo "$UNPACKDIR" | grep -q "^/tmp/flashplugin-nonfree\." || die_hard 
"para

Bug#861014: unblock: python-pyelftools/0.24-2

[Tomasz Buchert]

On 29/04/17 12:26, Niels Thykier wrote:
> [...]
>
> Yes please.  Upload a -3 to unstable reverting just the debhelper compat
> bump from -2.
>
> Thanks,
> ~Niels

Yep, I've just uploaded -3.

Tomasz


signature.asc
Description: PGP signature

Bug#861527: xa65: undocumented special character caret/circumflex ("^")

[aym-naibed]

Package: xa65
Version: 2.3.5-1
Severity: normal

Dear xa65 maintainer,

it would appear that the caret/circumflex ("^") is special in
string literals. Unfortunately, the man page is silent on the matter.

Thanks for reading.

-- 
Discriminating spammers prefer lists.debian.org.

Bug#861528: xa65: no -E option (dump preprocessor output)

[aym-naibed]

Package: xa65
Version: 2.3.5-1
Severity: wishlist

Dear xa65 maintainer,

wish xa provided a way to write the output of the built-in
preprocessor to standard output, like cc's -E option.

Probably with the comments stripped to make the output less
ambiguous with respect to colons (":") which are logical line
delimiters in semicolon (";") comments but not in C (/* */)
comments.

Thanks for reading.

-- 
bugs.debian.org, a spammer's delight.

Bug#802805: Otto is no longer actively developed or maintained.

[Geert Stappers]

Control: close -1


At https://github.com/hashicorp/otto/ the URL in the opening ITP
is now this text:

  Otto is no longer actively developed or maintained. Please see the
  announcement for more details.

In that announce at https://www.hashicorp.com/blog/decommissioning-otto/

  Instead of leaving Otto to languish in the open,
  we are decommissioning it



So I close this ITP / RFP  bugreport.

 
Groeten
Geert Stappers
-- 
Leven en laten leven


signature.asc
Description: Digital signature

Bug#857631: mesa-opencl-icd: openCL is broken in LLVM < v5

[Antonio Ospite]

On Wed, 12 Apr 2017 23:52:51 +0200
Antonio Ospite  wrote:

> Source: llvm-toolchain-4.0
> Followup-For: Bug #857631
> 
> Dear Maintainer,
> 
> It looks like that since libllvm3.9_3.9.1-6~exp1 the issue is fixed
> experimental for libllvm3.9, hoever libllvm4.0 still has it.
> 
[...]
> Can we please have a fixed 4.0 version uploaded to experimental?
> The same fixes from #857623 should be enough.

Hi, I saw that 4.0-5 has been uploaded without this fix, is this fix
going to be in 4.0.1?

Thanks,
   Antonio

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

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

Bug#861474: slim: Session restarts in a loop renedering whole system useless.

[Lukas]

Hi

Got the same problem on stretch.

Changing the systemd service type to simple solves the problem for me:

echo "Type=simple" >> /lib/systemd/system/slim.service
systemctl daemon-reload

So, i guess the dbus name can't be acquired...

BR

Lukas 

Bug#861431: restic: Rebuild needed for CVE-2017-3204; #859655

[Félix Sipma]

Control: tag -1 unreproducible

I can't reproduce this on amd64.

And https://buildd.debian.org/status/package.php?p=restic says amd64, arm64,
armel, armhf, i386 were rebuilt without any problem.

ppc64el rebuilding seems to give the same error as yours, though.

Do you think we can close this bug, or associate it with ppc64el only?

It may be an issue with insufficient ressources but I'm not sure, and I'm a bit
out of idea on how to fix this...
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Format: 1.0
Source: restic
Binary: restic
Architecture: amd64 source
Version: 0.3.3-2
Checksums-Md5:
 566fd1b258ec1b3e7549934808771cea 2219 restic_0.3.3-2.dsc
 2f4223cfb51930ac2137a86041a8077d 2005748 restic_0.3.3-2_amd64.deb
Checksums-Sha1:
 e384e72da90c6148c8a202b6ff904c7f9d45de96 2219 restic_0.3.3-2.dsc
 c50197897298c92b7c0cb14e2e7f888effb53c89 2005748 restic_0.3.3-2_amd64.deb
Checksums-Sha256:
 f5ec3a55d8635f5d7c7708a340e7ac6f7b5754f1f1f66f0350fb447b3700f6c6 2219 
restic_0.3.3-2.dsc
 c57a34cd921d4ec48efe961a3069a7cb32b85d35acdfa65e1723cacab5a3ef75 2005748 
restic_0.3.3-2_amd64.deb
Build-Origin: Debian
Build-Architecture: amd64
Build-Date: Sun, 30 Apr 2017 10:25:53 +
Build-Path: /build/restic-A7Oe9X/restic-0.3.3
Installed-Build-Depends:
 autoconf (= 2.69-10),
 automake (= 1:1.15-6),
 autopoint (= 0.19.8.1-2),
 autotools-dev (= 20161112.1),
 base-files (= 9.9),
 base-passwd (= 3.5.43),
 bash (= 4.4-4+b2),
 binutils (= 2.28-4),
 bsdmainutils (= 9.0.12+nmu1),
 bsdutils (= 1:2.29.2-1),
 build-essential (= 12.3),
 bzip2 (= 1.0.6-8.1),
 coreutils (= 8.26-3),
 cpp (= 4:6.3.0-4),
 cpp-5 (= 5.4.1-8),
 cpp-6 (= 6.3.0-14),
 dash (= 0.5.8-2.4),
 debconf (= 1.5.60),
 debhelper (= 10.2.5),
 debianutils (= 4.8.1.1),
 dh-autoreconf (= 14),
 dh-strip-nondeterminism (= 0.032-1),
 diffutils (= 1:3.5-3),
 dpkg (= 1.18.23),
 dpkg-dev (= 1.18.23),
 e2fslibs (= 1.43.4-2),
 e2fsprogs (= 1.43.4-2),
 file (= 1:5.30-1),
 findutils (= 4.6.0+git+20161106-2),
 g++ (= 4:6.3.0-4),
 g++-6 (= 6.3.0-14),
 gcc (= 4:6.3.0-4),
 gcc-5 (= 5.4.1-8),
 gcc-5-base (= 5.4.1-8),
 gcc-6 (= 6.3.0-14),
 gcc-6-base (= 6.3.0-14),
 gettext (= 0.19.8.1-2),
 gettext-base (= 0.19.8.1-2),
 golang-1.7-go (= 1.7.4-2),
 golang-1.7-src (= 1.7.4-2),
 golang-any (= 2:1.7~5),
 golang-bazil-fuse-dev (= 0.0~git20160811.0.371fbbd-2),
 golang-etcd-dev (= 2.0.0-2),
 golang-github-armon-consul-api-dev (= 0.0~git20150107.0.dcfedd5-2),
 golang-github-cpuguy83-go-md2man-dev (= 1.0.6+ds-1),
 golang-github-davecgh-go-spew-dev (= 1.1.0-1),
 golang-github-elithrar-simple-scrypt-dev (= 1.1+git20161119.3.2325946-1),
 golang-github-fsnotify-fsnotify-dev (= 1.4.2-1),
 golang-github-hashicorp-hcl-dev (= 0.0~git20161215.0.80e628d-1),
 golang-github-inconshreveable-mousetrap-dev (= 0.0~git20141017.0.76626ae-1),
 golang-github-kr-fs-dev (= 0.0~git2013.0.2788f0d-2),
 golang-github-magiconair-properties-dev (= 1.7.0-2),
 golang-github-minio-minio-go-dev (= 2.0.2-1),
 golang-github-mitchellh-mapstructure-dev (= 0.0~git20161204.0.5a0325d-1),
 golang-github-pelletier-go-buffruneio-dev (= 0.0~git20160124.0.df1e16f-1),
 golang-github-pelletier-go-toml-dev (= 0.4.0+git20161213.2.017119f-1),
 golang-github-pkg-errors-dev (= 0.8.0-1),
 golang-github-pkg-sftp-dev (= 0.0~git20160930.0.4d0e916-1),
 golang-github-pmezard-go-difflib-dev (= 1.0.0-1),
 golang-github-restic-chunker-dev (= 0.1.0-1),
 golang-github-russross-blackfriday-dev (= 1.4+git20161003.40.5f33e7b-1),
 golang-github-shurcool-sanitized-anchor-name-dev (= 
0.0~git20160918.0.1dba4b3-1),
 golang-github-spf13-afero-dev (= 0.0~git20161226.0.90dd71e-1),
 golang-github-spf13-cast-dev (= 0.0~git20161225.0.56a7ecb-1),
 golang-github-spf13-cobra-dev (= 0.0~git20170314.0.7be4bed-1),
 golang-github-spf13-jwalterweatherman-dev (= 
0.0~git20170109.0.fa7ca7e.really.git20160311.0.33c24e7-1),
 golang-github-spf13-pflag-dev (= 0.0~git20161024.0.5ccb023-1),
 golang-github-spf13-viper-dev (= 0.0~git20161213.0.5ed0fc3-3),
 golang-github-stretchr-objx-dev (= 0.0~git20150928.0.1a9d0bb-1),
 golang-github-stretchr-testify-dev (= 1.1.4+ds-1),
 golang-github-xordataexchange-crypt-dev (= 0.0.2+git20150523.17.749e360-4),
 golang-go (= 2:1.7~5),
 golang-golang-x-crypto-dev (= 
1:0.0~git20170407.0.55a552f+REALLY.0.0~git20161012.0.5f31782-1),
 golang-golang-x-net-dev (= 1:0.0+git20161013.8b4af36+dfsg-3),
 golang-golang-x-sys-dev (= 0.0~git20161122.0.30237cf-1),
 golang-golang-x-text-dev (= 0.0~git20161013.0.c745997-2),
 golang-golang-x-tools-dev (= 1:0.0~git20161028.0.b814a3b+ds-4),
 golang-gopkg-check.v1-dev (= 0.0+git20161208.0.20d25e2-1),
 golang-gopkg-yaml.v2-dev (= 0.0+git20160928.0.a5b47d3-2),
 golang-src (= 2:1.7~5),
 golang-x-text-dev (= 0.0~git20161013.0.c745997-2),
 grep (= 2.27-2),
 groff-base (= 1.22.3-9),
 gzip (= 1.6-5+b1),
 hostname (= 3.18+b1),
 init-system-helpers (= 1.47),
 intltool-debian (= 0.35.0+20060710.4),
 libacl1 (= 2.2.52-3+b1),
 libarchive-zip-perl (= 1.59-1),
 libasan2 (= 5.4.1-8),
 libasan3 (= 6.3.0-14),
 libatomic1 (= 6.3.0-14),
 libattr1

Bug#861529: ITP: libpll -- Phylogenetic Likelihood Library

[Andreas Tille]

Package: wnpp
Severity: wishlist
Owner: Andreas Tille 

* Package name: libpll
  Version : 0.0+20160909
  Upstream Author : Tomas Flouri 
* URL : https://github.com/xflouris/libpll
* License : AFFERO-3
  Programming Lang: C
  Description : Phylogenetic Likelihood Library
 PLL is a highly optimized, parallelized software library to ease the
 development of new software tools dealing with phylogenetic inference.
 .
 Among the functions included in PLL are parsing multiple sequence
 alignments (MSA) from PHYLIP and FASTA files, reading Newick trees,
 performing topological moves such as SPR and NNI, model optimization,
 likelihood evaluation and partitioned analysis by assigning different
 substitution models to each partition of the MSA. PLL fully implements
 the GTR nucleotide substitution model for DNA data and a number of
 models for aminoacid data.


Remark: This package will be maintained by the Debian Med team at
https://anonscm.debian.org/git/debian-med/libpll.git

Bug#859846: jessie-pu: package vlc/2.2.5-1~deb8u1

[Sebastian Ramacher]

On 2017-04-28 17:51:21, Adam D. Barratt wrote:
> Control: tags -1 + confirmed
> 
> On Fri, 2017-04-07 at 19:45 +0200, Sebastian Ramacher wrote:
> > I'd like to update vlc to the latest upstream bug fix release in jessie. It
> > fixes various integer and buffer overflows, NULL pointer dereferences, 
> > division
> > by zero errors, heap corruptions that can be triggered during playback.
> 
> Please go ahead, bearing in mind that the window for 8.8 closes during
> the weekend.

Thanks, uploaded.

Cheers
-- 
Sebastian Ramacher


signature.asc
Description: PGP signature

Bug#808940: pkg-group

[Geert Stappers]

Hi,

Initial message in this report speaks about  "pkg-group".
However on Alioth I can't find pkg-group.

Where is pkg-group?



Something completely different:
The list of blocking RFP bugreports scares me.
I think not all are needed to get a working Terraform.


Groeten
Geert Stappers


P.S.
Otto is gone as blocking dependency
 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=802805#28

Bug#861495: plasma-discover: recommend apt-config-auto-update instead of software-properties-kde

[Francesco De Vita]

On 30/04/17 00:41:17 CEST, Matthias Klumpp wrote:
> PackageKit aleady updates the cache periodically

By default? I have different machines with Stretch and the default kde 
installation, there was no evidence ever that that happened automatically. I 
always had to to check for updates manually in plasma-discover. Of course, I 
was able to set the automatic update via s-p-kde but it wasn't set by default.

> there is no point in having another tool trying to do the same in the
> background. The only thing that this might end in is two things fighting over
> the APT database lock in the background, which is undesired.

My suggestion was in fact to recommend apt-config-auto-update *instead of*
s-p-kde. About this point, what should be the default mechanism in Debian to 
update the cache and/or enable automatic updates? Something related to APT or 
PackageKit only? The manuals still suggest to use and configure apt to do that 
(mentioning apticron,  apt-config-auto-update and unattend-upgrades for the 
convenience of the users). And by the way, s-p-kde does exactly that by 
(also?) writing the file /etc/apt/apt.conf.d/10periodic. This is why I don't 
understand why the two packages cannot be interchangeable.

> > What benefits if I may ask? The sources.list can be edited already in
> > plasma-discover without s-p-kde,
> 
> You can only remove sources, you can't add or edit them

You're right. But I just tried to edit my sources with s-p-kde. It crashes 
when adding new sources and it automatically enables them and adds a commented 
deb-src line. I had to manually check for errors my sources.list anyway.  
Also, the interface is misleading due to bug 443643 [1] (a bug of 10 years 
ago).  In this way it is still better to edit the sources.list with a text 
editor.

> or look at which GPG keys ou have installed for them on your system

I don't know if you're talking about the same functionality provided by 
apt-key, but s-p-kde simply displays nothing under "Trusted software 
providers", while apt-key shows correctly all the keys.

> You can also not enable/disable backports or updates via a simple click.

Maybe yes but still the interface is misleading due to bug 721662 [2].

> > and what remains is the possibility to choose if
> > automatically install security updates (but I suppose unattended-upgrades
> > does exactly that) or download all the updates in background or just
> > notify about it.
> 
> These are exactly the features that might be broken, as they rely on
> other tools and s-p-kde doesn't interface well with PackageKit.
> Everything else works.

Well, because of the issues above, I'm not convinced of the benefits of this 
package. Right now I still think that the updates can be managed better by 
editing the proper files in /etc/apt/ and that the usage of apt-config-auto-
update and unattended-upgrades provides a better setting for the average user.

Thank you for the useful clarifications and for your time.

Regards
Francesco

[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=443643
[2] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=721662

Bug#859475: jessie-pu: package ndisc6/1.0.1-1+deb8u1

[Adam D. Barratt]

Control: tags -1 + pending

On Sun, 2017-04-30 at 00:05 +0200, Bernhard Schmidt wrote:
> On Fri, Apr 28, 2017 at 05:45:17PM +0100, Adam D. Barratt wrote:
> 
> Hi Adam,
> 
> > On Tue, 2017-04-04 at 00:40 +0200, Bernhard Schmidt wrote:
> > > the package rdnssd (from src:ndisc6) provides a daemon that listens to 
> > > IPv6 RA
> > > messages containing RDNSS (recursive DNS servers) information, and adds 
> > > this
> > > information to /etc/resolv.conf. It is automatically installed by d-i if 
> > > this
> > > information is found during installation.
> > > 
> > > If resolvconf is installed managing and merging of /etc/resolv.conf is 
> > > handed
> > > over to it. However, if it is not installed the version in Jessie simply
> > > overwrites /etc/resolv.conf, which drops all search list information as 
> > > well as
> > > IPv4 nameservers. This often leads to severe breakage of the installed 
> > > system.
> > > This is tracked in Bug#767071
> > > 
> > > The proposed fix for Jessie will adjust the merge script to be the same 
> > > as in
> > > current upstream and Stretch.
> > 
> > Please go ahead, bearing in mind that the window for the 8.8 point
> > release closes during the weekend.
> 
> Thanks, uploaded and accepted.

Flagged for acceptance into p-u.

Regards,

Adam

Bug#858996: jessie-pu: package mariadb-10.0/10.0.30-0+deb8u2

[Adam D. Barratt]

Control: tags -1 + pending

On Sat, 2017-04-29 at 21:12 +0100, Adam D. Barratt wrote:
> Control: tags -1 + confirmed
> 
> On Sat, 2017-04-29 at 22:00 +0200, Ondřej Surý wrote:
> > Control: tags 858996 -moreinfo
> > 
> > JFTR mariadb-server-10.1 10.1.22-3 that contained the same change has
> > migrade to testing on 2017-04-06 and nobody has complained since, so I
> > am humbly asking for review of this change in jessie.
> 
> Please feel free to upload, but bear in mind that the window for 8.8 is
> closing during this weekend.

Uploaded and flagged for acceptance.

Regards,

Adam

Bug#861531: ricochet: FTBFS - Makefile:900: recipe for target 'ricochet-icon.svg' failed

[Hans Joachim Desserud]

Package: ricochet
Version: 0.6
Severity: serious
Justification: fails to build from source

Dear Maintainer,

The latest version of ricochet currently fails to build from source in 
Sid.

(I first saw this when the package was synced to Ubuntu, but I was also
able to reproduce it on my Sid vm)
See [1] or [2] for more details.

[1] 
https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/ricochet.html
[2] 
https://tests.reproducible-builds.org/debian/rbuild/unstable/amd64/ricochet_0.6.rbuild.log



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

Kernel: Linux 4.9.0-2-amd64 (SMP w/1 CPU core)
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)

--
mvh / best regards
Hans Joachim Desserud
http://desserud.org

Bug#861530: c-icap: Misleading error message if c-icap is running out of temp. diskspace

[Roland Schnabel]

Package: c-icap
Version: 1:0.3.4-2
Severity: minor
Tags: upstream

Dear Maintainer,

* What led up to the situation?
Configure c-icap with module libc-icap-mod-virus-scan

* What exactly did you do (or not do) that was effective (or ineffective)?
Configuration:
MaxServers  10
ThreadsPerChild 10
ServiceAlias  avscan virus_scan?allow204=on&sizelimit=off&mode=simple
virus_scan.MaxObjectSize5M
TmpDir  /tmp
Free diskspace in /tmp: 700 MB
Downloading a file via squid3 that is larger than 700 MB

* What was the outcome of this action?
Log entry in c-icap logfile:
"Bug in the service. Please report to the service author"

* What outcome did you expect instead?
Log entry in c-icap logfile:
"Running out of temporary diskspace" or "Skipping c-icap module because file is 
too large for temp. diskspace"
Max. required temp. diskspace of above c-icap configuration is 500 MB. Free 
diskspace is 700 MB. So temp.
diskspace would be enough. But because of the ServiceAlias option for 
virus_scan "sizelimit=off" the c-icap 
configuration for max. temp. diskspace is ignored. c-icap tries to download the 
file runs out of temp. 
diskspaceand logs this very misleading error message. This makes it very hard 
to detect this error if you 
have e.g. a large number of squid users that report infrequent error messages 
in their browser "internal 
server error" and they are concurrently only downloading small files over squid.

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

Kernel: Linux 3.16.0-4-amd64 (SMP w/2 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=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 c-icap depends on:
ii  adduser  3.113+nmu3
ii  libc62.19-18+deb8u7
ii  libdb5.3 5.3.28-9
ii  libicapapi3  1:0.3.4-2
ii  lsb-base 4.1+Debian13+nmu1

c-icap recommends no packages.

Versions of packages c-icap suggests:
ii  libc-icap-mod-virus-scan [libc-icap-module]  1:0.3.2-2+b1
ih  squid3   3.4.8-6+deb8u4

-- Configuration Files:
/etc/c-icap/c-icap.conf changed:
PidFile /var/run/c-icap/c-icap.pid
CommandsSocket /var/run/c-icap/c-icap.ctl
Timeout 300
MaxKeepAliveRequests 100
KeepAliveTimeout 600  
StartServers 3
MaxServers 10
MinSpareThreads 10
MaxSpareThreads 20
ThreadsPerChild 10
MaxRequestsPerChild  0
Port 1344 
User c-icap
Group c-icap
ServerAdmin postmas...@rolandschnabel.de
ServerName gray1b
TmpDir /tmp
MaxMemObject 512000
DebugLevel 2
ModulesDir /usr/lib/x86_64-linux-gnu/c_icap
ServicesDir /usr/lib/x86_64-linux-gnu/c_icap
TemplateDir /usr/share/c_icap/templates/
TemplateDefaultLanguage en
LoadMagicFile /etc/c-icap/c-icap.magic
RemoteProxyUsers off
RemoteProxyUserHeader X-Authenticated-User
RemoteProxyUserHeaderEncoded on
acl localhost src 127.0.0.1/255.255.255.255 192.168.0.215/32
acl all src 0.0.0.0/0.0.0.0
acl ALLREQUESTS type REQMOD RESPMOD OPTIONS
icap_access allow ALLREQUESTS localhost
icap_access deny all
LogFormat myFormat "%tl - Local-IP:%15la Remote-IP:%15a HTTP-Server:%

Bug#861532: mon-contrib: sms.alert uses /var/lib/mon for logs

[Russell Coker]

Package: mon-contrib
Version: 1.0+dfsg-3+nmu1
Severity: normal

Generally logs don't belong in /var/lib.  Also we want to separate alerts from
monitor scripts for security reasons.  While /usr/lib/mon/alert.d/sms.alert
has the line using /var/lib/mon commented out, it's there as a suggestion for
people to follow.  It should be expected that some users uncomment that line
and that others write new alert scripts derived from it with that line
uncommented.

We need to have some plan about where to log things to keep alerts, local
monitors, and remote monitors separate.

I don't have a good plan for this at the moment.  I'm documenting it here so I
don't forget and so that anyone who has ideas can contribute.

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

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

Versions of packages mon-contrib depends on:
ii  mon  1.2.0-9+nmu4

mon-contrib recommends no packages.

mon-contrib suggests no packages.

-- no debconf information

Bug#848671: Bug#640162: fixed in xpdf 3.03-4

[Vincent Lefevre]

On 2017-04-30 10:03:52 +0200, kardan wrote:
> 848671 is duplicate of above archived bugs.

No, this is a different bug (though similar). The error messages
are not the same ones and are obtained from different commands.
In particular, I have no problems with xpdf 3.04-1, even though
the unicodeMap command is present in the config files.

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

Bug#861533: ITP: alttab -- task switcher for minimalistic WMs or standalone X session

[Alexander Kulak]

Package: wnpp
Severity: wishlist
Owner: Alexander Kulak 

* Package name: alttab
  Version : 1.0.3
  Upstream Author : Alexander Kulak 
* URL : https://github.com/sagb/alttab
* License : GPLv3
  Programming Lang: C
  Description : task switcher for minimalistic WMs or standalone X session

alttab provides convenient visual interface and switching on
releasing, not pressing Alt key. Being lightweight and depending only
on basic X11 libs, it still features customizable look and behaviour.

Code is small and documented, I own copyright on all files except of
autotools stuff. I use alttab every day on several machines.
I've not found any suitable Debian release group.
Going to look for sponsorship.

Bug#861534: hardlink: fails on files in deep directory trees

[Sven Hartge]

Package: hardlink
Version: 0.3.0
Severity: wishlist

Hi!

I use hardlink on some very deep directory trees with files close or at
the maximum file name length.

Because hardlink adds a ".hardlink-temporary" suffix to files it is
going to link, it will fail for those files:

| WARNING: Cannot link /a/very/long/path/file-with-very-long-name.sample to 
/a/very/long/path/file-with-very-long-name.sample.hardlink-temporary: File name 
too long 

To alleviate that, I patched my local version to use a shorter suffix
".ht", but this of course increases the possibility of a collision with
an existing file:

test.file
same.file
same.file.ht

Hardlinking same.file to test.file will fail, because same.file.ht
already exists.

In my case I can guarantee that will not happen, because I know the
possible file names in the target directories, but this is of course not
the case for everybody.

One more general solution would be to use a completely random temporary
file name instead of adding a suffix to the original name.

I'd propose a patch for that, but my C-fu is to weak to come up with
working code. Sorry.

Note: using a 8 character temporary name will of course fail again if
the maximum possible file name length in an absurdly deep directory is
(for example) only 4 characters, but I think this is a much more
academic problem than the real one I experience daily.

Grüße,
Sven

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

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

Versions of packages hardlink depends on:
ii  libc6 2.24-10
ii  libpcre3  2:8.39-3

hardlink recommends no packages.

hardlink suggests no packages.

-- no debconf information

Bug#861535: unblock: file/1:5.30-1 (was: Seeking pre-approval to upload new file upstream version for stretch)

[Christoph Biedl]

Package: release.debian.org
User: release.debian@packages.debian.org
Usertags: unblock
Severity: normal

Hello,

please unblock file 1:5.30-1 I've uploaded to unstable.

Short version:

This upload

* fixes several issues in 1:5.29-3, including an assertion failure
  triggerable from certain files,
* includes more than twenty(!) commits from the upstream git since the
  5.30 release that, by their description, seem prudent to include
  security-wise, and
* otherwise tries hard to not change the detection of files.


A bit longer:

There are a few issues in the stretch version of file (1:5.29-3) that
in my opinion make it unfit for release. The most important one is an
easily triggerable crash (assertion failure) I found a while ago,
upstream was alerted in private. This issue was introduced in version
1:5.29-1 and is not public yet, at least not from my side.

The delta between 1:5.29-3 and upstream's 5.30 release is pretty small:
These are bug fixes like for the one mentioned above, several changes
that seem to address issues, some documentation and/or not affecting the
execution. There are two changes that introduce new features, I've
reverted them to reduce the impact (also, they looked somewhat fishy).
Initially, forwarding to 5.30 promised a smaller and better arranged
debian/patches/.

Since upstream's 5.30 release however, there have been a lot of commits
that address more issues, usually they contain a remark "oss-fuzz", so
appearently somebody has spent quite some time searching for flawed
code. One commit contains a remark "Although I can't reproduce it"
which implies at least some of the other commits fix an exploitable
issue. So I decided the cherry-pick *all* of them plus prerequisites in
the hope this will avoid some security uploads during the stretch life
cycle. They all can be found in debian/patches/, one patch per commit.


As with every upload of file, I ran a test on a huge collection of
files in order to detect unexpected changes. I have to admit there are
some minor ones: For some files not all the gory details are shown any
longer, basic detection still works. These were introduced by the
changes that should fix issues in the code.

Additional details, like discussion of every single change between
1:5.29-3 and 1:5.30-1 available upon request.

Regards,

Christoph


signature.asc
Description: Digital signature

Bug#861536: runit-init: Cannot reboot or shutdown after installing (or removing) the package.

[Matthew T Hoare]

Package: runit-init
Version: 2.1.2-9
Severity: grave
Justification: renders package unusable

Dear Maintainer,

   * What led up to the situation?
   I ran `apt install runit-init` and then attempted to reboot with
   `/sbin/reboot`, `/sbin/poweroff`, `init 0` & `init 6`, all to no
   effect; no error messages were returned and the exit status of all of
   the commands was zero.

   * What exactly did you do (or not do) that was effective (or
 ineffective)?
 Reintalled systemd-sysv then rebooted into my Arch Linux system,
 chrooted into BunsenLabs then installed the package from the chroot
 and rebooted into that init system.

   * What was the outcome of this action?
   It worked :)
   The same procedure was required to return to systemd as PID1.

-- System Information:
Distributor ID: BunsenLabs
Description:BunsenLabs GNU/Linux (Helium-dev)
Release:x
Codename:   bunsen-helium-dev

Architecture: x86_64

Kernel: Linux 4.10.0-11.1-liquorix-amd64 (SMP w/4 CPU cores; PREEMPT)
Locale: LANG=C, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)

Versions of packages runit-init depends on:
ii  getty-run  2.1.2-9
ii  libc6  2.24-10
ii  runit  2.1.2-9

runit-init recommends no packages.

runit-init suggests no packages.

-- no debconf information

Bug#861537: detox: causes malformed UTF-8 characters when no default character is set - fails to "fall through"

[Zenaan Harkness]

Package: detox
Version: 1.2.0-5
Severity: normal
Tags: upstream patch

Dear Maintainer,

detox does not "pass through" - that is, when configuring a .tbl table
file with not default, or "default" with nothing else on the line,
followed by those changes I want to achieve with my files, detox fails
to achieve desired outcome. Instead with certain UTF-8 characters, detox
creates malformed output characters (i.e. incomplete).

Here's an example of what I cannot achieve with detox (only changing a
few problematic chars, keeping all the greek, cyrillic etc chars),
running in uxterm (or xterm -u8):

$ cat /home/justa/etc/detox/ztest.tbl
start
0x0026  _and_   # AMPERSAND

# Chars to translate to _
0x0020  _   # space
0x0021  _   # !
0x0022  _   # "
0x0024  _   # $
0x0027  _   # '
0x002a  _   # *
0x002f  _   # /
0x003a  _   # :
0x003b  _   # ;
0x003c  _   # <
0x003e  _   # >
0x003f  _   # ?
0x0040  _   # @
0x005c  _   # \
0x0060  _   # `
0x007c  _   # |

# Chars to translate to -
0x0028  -   # (
0x0029  -   # )
0x005b  -   # [
0x005d  -   # ]
0x007b  -   # {
0x007d  -   # }
end

$ cat ~/.detoxrc
sequence gnu {
   utf_8 {filename "/home/justa/etc/detox/ztest.tbl";};
};

$ env|egrep "LOC|LANG|UTF|utf|LC"
LC_ALL=zen.UTF-8
MAILCHECK=0
LANG=zen.UTF-8
XTERM_LOCALE=zen.UTF-8
 unset -v CLASSPATH_LOCAL;

$ # (my custom locale is just UTF-8 with a custom default date format)

$ touch "mÉ Æ.txt"

$ ls *txt; ls -l *txt; ls -lb *txt
mÉ Æ.txt
-rw--- 1 justa justa 0 Apr 30 22:04 mÉ Æ.txt
-rw--- 1 justa justa 0 Apr 30 22:04 mÉ\ Æ.txt


What I want is for the file "mÉ Æ.txt" to end up with the following
name:
 mÉ_Æ.txt


but instead as we can see:

$ detox -vs gnu *txt

  
Scanning: mÉ Æ.txt
mÉ Æ.txt -> m .txt

$ ls *txt; ls -l *txt; ls -lb *txt
m? ?.txt
-rw--- 1 justa justa 0 Apr 30 22:04 m? ?.txt
-rw--- 1 justa justa 0 Apr 30 22:04 m\207\ \204.txt


and we see that some malformed chars have been created,
(whatever that is, I'm not sure).


The patch, thanks to Vasily Kolobkov, is quite simple - basically just a
missing "continue;" is added in a couple of places, fixing up the
clean_safe and clean_iso8859_1 methods. There's probably a similar
change needed in clean_utf_8 method - this is not yet done.

Patch 1 is just the fix.

Patch 2 adds example table files for fine grained "cascading" in user
defined detox config sequences.

Patch 3 tidies up the "sample" filenames, which don't need to end with
".sample" and are actually required in a normal installation anyway, and
so e.g. on Debian stable, result in duplicate files (should be symlinks
at least, but shouldn't be duplicated anyway - DRY/ remove redunancy).




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

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

Versions of packages detox depends on:
ii  libc6  2.19-18+deb8u7

detox recommends no packages.

detox suggests no packages.

-- no debconf information

Bug#861538: youtube-dl: Failure with some downloads due to changes at youtube, solved by new version

[Andreas Tille]

Package: youtube-dl
Version: 2017.03.26-1
Severity: important

Hello,

I failed to download

https://www.youtube.com/watch?v=H_a46WJ1viA

with youtube-dl from sid/stretch.  I can confirm that the latest
upstream version 2017.04.28 solves the problem.  I have no idea how
many videos might be affected but it would be bad to deliver a
partly broken youtube-dl with stretch.

Kind regards

Andreas.

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

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

Versions of packages youtube-dl depends on:
ii  python2.7.9-1
ii  python-pkg-resources  5.5.1-1

Versions of packages youtube-dl recommends:
pn  libav-tools | ffmpeg | ffprobe  
pn  mplayer2 | mplayer  
pn  rtmpdump

youtube-dl suggests no packages.

Bug#859255: binNMU needed for more R packages.

[Niels Thykier]

Charles Plessy:
> Le Sat, Apr 22, 2017 at 11:25:23PM +0900, Charles Plessy a écrit :
>>
>> Actually the rebuild was not enough and today I finally understood that
>> r-bioc-xvector also needs a rebuild (despite its own regression tests
>> did not fail).  Unfortunately R in Sid is now ahead of Testing, and the
>> Debian build system that we use will force a dependency on Sid's version
>> if it goes on the usuall buildds.
>>
>> Is it possible to binNMU in Testing, or shall I upload a source update to
>> testing-proposed-updates ?
> 
> Hello Niels and everybody,
> 
> I just uploaded r-bioc-xvector to testing-proposed-updates.  I checked
> in a clean chroot that the amd64 package that I built resolves the
> breakage of its downstream dependency r-bioc-rsamtools (whose autopkg
> tests fail with the current r-bioc-xvector).
> 
> Cheers,
> 
> Charles
> 

Hi Charles,

Thanks for following up on this issue.

We need unstable to have higher version than testing.  Therefore we
cannot use the tpu upload (as-is) because it would violate that rule.  I
will try to solve this with some binNMU magic.  Failing that, we will
need an upload of r-bioc-xvector to ensure that the versions align
correctly.

I will be in touch. :)

Thanks,
~Niels

Bug#861537: [PATCH] Fix Debian Bug#861537: malformed UTF-8 chars in output - failure to fall through

[Zenaan Harkness]

 - Debian bug is Bug#861537

 - when constructing a custom detox "translation table" with the fall through
   option (no default specified, or "default" without a value), detox creates
   malformed characters in the output - every "clean_*" code path is effected.

 - clean_iso8859_1() and clean_safe() methods have simple change to fix this
   bug.

 - clean_utf_8() still to be done

 - Thank you to Vasily Kolobkov  for the fix, I am
   a mere Java programmer still learning C.
---
 src/clean_string.c | 14 ++
 1 file changed, 6 insertions(+), 8 deletions(-)

diff --git a/src/clean_string.c b/src/clean_string.c
index 7aa054e..f1a75ba 100644
--- a/src/clean_string.c
+++ b/src/clean_string.c
@@ -131,16 +131,15 @@ unsigned char *clean_iso8859_1(unsigned char *s, void 
*opts)
 * Null translation == leave it alone
 */
*output_walk++ = *input_walk++;
+   continue;
}
else {
replace_walk = 
table->default_translation;
}
}
 
-   if (replace_walk != NULL) {
-   while (*replace_walk != '\0') {
-   *output_walk++ = *replace_walk++;
-   }
+   while (*replace_walk != '\0') {
+   *output_walk++ = *replace_walk++;
}
 
input_walk++;
@@ -296,16 +295,15 @@ unsigned char *clean_safe(unsigned char *s, void *opts)
 * Null translation == leave it alone
 */
*output_walk++ = *input_walk++;
+   continue;
}
else {
replace_walk = table->default_translation;
}
}
 
-   if (replace_walk != NULL) {
-   while (*replace_walk != '\0') {
-   *output_walk++ = *replace_walk++;
-   }
+   while (*replace_walk != '\0') {
+   *output_walk++ = *replace_walk++;
}
 
input_walk++;
-- 
2.9.0

Bug#861537: detox: causes malformed UTF-8 characters when no default character is set - fails to "fall through"

[Eriberto]

Hi Zenaan and Doug,

Thanks Zenaan for your message. I added Doug (the Detox upstream) to talk.

Zenaan, where are the patches? (I didn't see they but sorry if it is a
mistake of mine)

Doug, can you verify this issue?

Thanks!!!

Eriberto


2017-04-30 9:32 GMT-03:00 Zenaan Harkness :
> Package: detox
> Version: 1.2.0-5
> Severity: normal
> Tags: upstream patch
>
> Dear Maintainer,
>
> detox does not "pass through" - that is, when configuring a .tbl table
> file with not default, or "default" with nothing else on the line,
> followed by those changes I want to achieve with my files, detox fails
> to achieve desired outcome. Instead with certain UTF-8 characters, detox
> creates malformed output characters (i.e. incomplete).
>
> Here's an example of what I cannot achieve with detox (only changing a
> few problematic chars, keeping all the greek, cyrillic etc chars),
> running in uxterm (or xterm -u8):
>
> $ cat /home/justa/etc/detox/ztest.tbl
> start
> 0x0026  _and_   # AMPERSAND
>
> # Chars to translate to _
> 0x0020  _   # space
> 0x0021  _   # !
> 0x0022  _   # "
> 0x0024  _   # $
> 0x0027  _   # '
> 0x002a  _   # *
> 0x002f  _   # /
> 0x003a  _   # :
> 0x003b  _   # ;
> 0x003c  _   # <
> 0x003e  _   # >
> 0x003f  _   # ?
> 0x0040  _   # @
> 0x005c  _   # \
> 0x0060  _   # `
> 0x007c  _   # |
>
> # Chars to translate to -
> 0x0028  -   # (
> 0x0029  -   # )
> 0x005b  -   # [
> 0x005d  -   # ]
> 0x007b  -   # {
> 0x007d  -   # }
> end
>
> $ cat ~/.detoxrc
> sequence gnu {
>utf_8 {filename "/home/justa/etc/detox/ztest.tbl";};
> };
>
> $ env|egrep "LOC|LANG|UTF|utf|LC"
> LC_ALL=zen.UTF-8
> MAILCHECK=0
> LANG=zen.UTF-8
> XTERM_LOCALE=zen.UTF-8
>  unset -v CLASSPATH_LOCAL;
>
> $ # (my custom locale is just UTF-8 with a custom default date format)
>
> $ touch "mÉ Æ.txt"
>
> $ ls *txt; ls -l *txt; ls -lb *txt
> mÉ Æ.txt
> -rw--- 1 justa justa 0 Apr 30 22:04 mÉ Æ.txt
> -rw--- 1 justa justa 0 Apr 30 22:04 mÉ\ Æ.txt
>
>
> What I want is for the file "mÉ Æ.txt" to end up with the following
> name:
>  mÉ_Æ.txt
>
>
> but instead as we can see:
>
> $ detox -vs gnu *txt
> Scanning: mÉ Æ.txt
> mÉ Æ.txt -> m .txt
>
> $ ls *txt; ls -l *txt; ls -lb *txt
> m? ?.txt
> -rw--- 1 justa justa 0 Apr 30 22:04 m? ?.txt
> -rw--- 1 justa justa 0 Apr 30 22:04 m\207\ \204.txt
>
>
> and we see that some malformed chars have been created,
> (whatever that is, I'm not sure).
>
>
> The patch, thanks to Vasily Kolobkov, is quite simple - basically just a
> missing "continue;" is added in a couple of places, fixing up the
> clean_safe and clean_iso8859_1 methods. There's probably a similar
> change needed in clean_utf_8 method - this is not yet done.
>
> Patch 1 is just the fix.
>
> Patch 2 adds example table files for fine grained "cascading" in user
> defined detox config sequences.
>
> Patch 3 tidies up the "sample" filenames, which don't need to end with
> ".sample" and are actually required in a normal installation anyway, and
> so e.g. on Debian stable, result in duplicate files (should be symlinks
> at least, but shouldn't be duplicated anyway - DRY/ remove redunancy).
>
>
>
>
> -- System Information:
> Debian Release: 8.7
>   APT prefers stable-updates
>   APT policy: (500, 'stable-updates'), (500, 'proposed-updates'), (500, 
> 'stable')
> Architecture: amd64 (x86_64)
>
> Kernel: Linux 4.9.0-0.bpo.2-amd64 (SMP w/4 CPU cores)
> Locale: LANG=zen.UTF-8, LC_CTYPE=zen.UTF-8 (charmap=UTF-8) (ignored: LC_ALL 
> set to zen.UTF-8)
> Shell: /bin/sh linked to /bin/dash
> Init: systemd (via /run/systemd/system)
>
> Versions of packages detox depends on:
> ii  libc6  2.19-18+deb8u7
>
> detox recommends no packages.
>
> detox suggests no packages.
>
> -- no debconf information

Bug#861539: tcpreplay FTBFS on armel/armhf/mips*: L7 fuzzing test: Makefile:963: recipe for target 'rewrite_l7fuzzing' failed

[Adrian Bunk]

Source: tcpreplay
Version: 4.2.4-1
Severity: serious

https://buildd.debian.org/status/package.php?p=tcpreplay&suite=sid

...
[tcprewrite] Seeded Keep MAC test:  OK
[tcprewrite] L7 fuzzing test: Makefile:963: recipe for target 
'rewrite_l7fuzzing' failed
make[2]: *** [rewrite_l7fuzzing] Error 1
make[2]: Target 'test' not remade because of errors.
make[2]: Leaving directory '/«PKGBUILDDIR»/test'
Makefile:888: recipe for target 'test' failed
make[1]: *** [test] Error 2

Bug#861537: [PATCH] Fix Debian Bug#861537: malformed UTF-8 chars in output - failure to fall through

[Eriberto Mota]

Here is the patches now!!! Thanks.

2017-04-30 9:46 GMT-03:00 Zenaan Harkness :
>  - Debian bug is Bug#861537
>
>  - when constructing a custom detox "translation table" with the fall through
>option (no default specified, or "default" without a value), detox creates
>malformed characters in the output - every "clean_*" code path is effected.
>
>  - clean_iso8859_1() and clean_safe() methods have simple change to fix this
>bug.
>
>  - clean_utf_8() still to be done
>
>  - Thank you to Vasily Kolobkov  for the fix, I 
> am
>a mere Java programmer still learning C.
> ---
>  src/clean_string.c | 14 ++
>  1 file changed, 6 insertions(+), 8 deletions(-)
>
> diff --git a/src/clean_string.c b/src/clean_string.c
> index 7aa054e..f1a75ba 100644
> --- a/src/clean_string.c
> +++ b/src/clean_string.c
> @@ -131,16 +131,15 @@ unsigned char *clean_iso8859_1(unsigned char *s, void 
> *opts)
>  * Null translation == leave it alone
>  */
> *output_walk++ = *input_walk++;
> +   continue;
> }
> else {
> replace_walk = 
> table->default_translation;
> }
> }
>
> -   if (replace_walk != NULL) {
> -   while (*replace_walk != '\0') {
> -   *output_walk++ = *replace_walk++;
> -   }
> +   while (*replace_walk != '\0') {
> +   *output_walk++ = *replace_walk++;
> }
>
> input_walk++;
> @@ -296,16 +295,15 @@ unsigned char *clean_safe(unsigned char *s, void *opts)
>  * Null translation == leave it alone
>  */
> *output_walk++ = *input_walk++;
> +   continue;
> }
> else {
> replace_walk = table->default_translation;
> }
> }
>
> -   if (replace_walk != NULL) {
> -   while (*replace_walk != '\0') {
> -   *output_walk++ = *replace_walk++;
> -   }
> +   while (*replace_walk != '\0') {
> +   *output_walk++ = *replace_walk++;
> }
>
> input_walk++;
> --
> 2.9.0

Bug#861518: libc6-dev: The newest libc6-dev (2.24-10) badly depends on kernel, particularly linux-libc-dev (>= 4.9.18-1)

[Aurelien Jarno]

control: tag -1 + moreinfo
thanks

On 2017-04-29 18:49, Laci Tele wrote:
> Package: libc6-dev
> Version: 2.24-10
> Severity: important
> 
> Dear Maintainer,
> 
> 
>* What led up to the situation?
>
> I tried to install libc6-dev on my armhf embedded hardware.
> Its not possible, because dependencies are not met.
> Because the newest libc6-dev depends particularly on linux-kernel 
> (>= 4.9.18-1), and this is an error, at least I hope its not intentional.

Not it doesn't depends on the latest kernel. It depends on the latest
kernel *headers* which are provided by linux-libc-dev.

> Because many embedded armhf devices use older kernels, 4.1 , 4.4 ... so on
> , it depends on BSP what you can get from the HW vendor. Usually they have no 
> 4.9 or any near to mainline kernel.

Yes, that's something known. libc6 requires at least a 3.2 kernel on
most architectures, and 2.6.32 on i386 and amd64.

> So they have no linux-libc-dev (>= 4.9.18-1)

You can install linux-libc-dev (>= 4.9.18-1) even if you're embedded
device uses a 4.1 or 4.4 kernel. It's provided in the Debian archive.

> So they cant install libc6-dev (2.24-10)
> So actually they can't develop.

Please try to install libc6-dev and linux-libc-dev from stretch or sid.
If it fails to install, please provide the error message from apt,
aptitude or dpkg showing the issue.

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

Bug#861204: deb-systemd-invoke: fails to handle units with escaped characters

[Michael Biebl]

Hi Bernd

Am 30.04.2017 um 05:53 schrieb Bernd Zeimetz:
> Hi Michael,
> 
> any news on that? I could upload an NMU if you thats okay for you.
> Or is there anything else I can help with?

The package is in collab-maint. If you can commit your changes there and
make the upload, this would be great. Whether you name it team upload or
NMU doesn't really matter to me, both would be fine as far as I'm concerned.

Regards,
Michael


-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?



signature.asc
Description: OpenPGP digital signature

Bug#861537: [PATCH 2/2] Add "fall through" sequences and samples

[Zenaan Harkness]

 - These of course rely on the previous patch - fixing the detox bug causing
   malformed UTF-8 chars.

 - example table files provided, and can easily imagine some people will now
   come up with specific sets of files which would work for their language, e.g.
   Java creates (anonymous class) class files with '$' symbol in them, which
   could possibly be useful for detox to know about (then again, may be not)

 - added commend to detoxrc.sample about utf-8 cleaning method not yet done
---
 etc/detoxrc.sample | 63 +-
 table/brackets.tbl | 12 +++
 table/punct1.tbl   | 23 
 table/punct2.tbl   | 16 ++
 table/space.tbl|  5 +
 5 files changed, 114 insertions(+), 5 deletions(-)
 create mode 100644 table/brackets.tbl
 create mode 100644 table/punct1.tbl
 create mode 100644 table/punct2.tbl
 create mode 100644 table/space.tbl

diff --git a/etc/detoxrc.sample b/etc/detoxrc.sample
index 3247fc7..1e8bfe7 100644
--- a/etc/detoxrc.sample
+++ b/etc/detoxrc.sample
@@ -6,15 +6,15 @@
 # met:
 # 
 # 1. Redistributions of source code must retain the above copyright
-#notice, this list of conditions and the following disclaimer.
+#   notice, this list of conditions and the following disclaimer.
 # 
 # 2. Redistributions in binary form must reproduce the above copyright
-#notice, this list of conditions and the following disclaimer in the
-#documentation and/or other materials provided with the distribution.
+#   notice, this list of conditions and the following disclaimer in the
+#   documentation and/or other materials provided with the distribution.
 # 
 # 3. Neither the name of author nor the names of its contributors may be
-#used to endorse or promote products derived from this software
-#without specific prior written permission.
+#   used to endorse or promote products derived from this software
+#   without specific prior written permission.
 # 
 # THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
 # "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
@@ -32,6 +32,7 @@
 #
 # Basically just utf_8
 #
+
 sequence default {
utf_8;
safe;
@@ -67,6 +68,29 @@ sequence "lower" {
wipeup;
 };
 
+sequence "punctuation" {
+   safe {filename "/usr/share/detox/space.tbl";};
+   safe {filename "/usr/share/detox/brackets.tbl";};
+   safe {filename "/usr/share/detox/punct1.tbl";};
+   wipeup;
+};
+
+sequence "unix" {
+   uncgi;
+   # perhaps insert utf_8 fall through option here (when implemented) ?
+   # i.e. unicode control characters, special blocks, line terminators
+   # (there's at least 4) etc, should be filtered out here, or in the
+   # lines below, but we need first to be able to replace "safe" with
+   # "utf_8" detox (internal) processing codepath (that's the "when
+   # implemented" bit :)
+   safe {filename "/usr/share/detox/space.tbl";};
+   safe {filename "/usr/share/detox/brackets.tbl";};
+   safe {filename "/usr/share/detox/punct1.tbl";};
+   safe {filename "/usr/share/detox/punct2.tbl";};
+   wipeup {remove_trailing;};
+};
+
+
 #
 # Sequences meant primarily for inline-detox
 #
@@ -87,6 +111,35 @@ sequence "lower-only" {
lower;
 };
 
+sequence "space" {
+   safe {filename "/usr/share/detox/space.tbl";};
+};
+
+sequence "brackets" {
+   safe {filename "/usr/share/detox/brackets.tbl";};
+};
+
+sequence "punct1" {
+   safe {filename "/usr/share/detox/punct1.tbl";};
+};
+
+sequence "punct2" {
+   safe {filename "/usr/share/detox/punct2.tbl";};
+};
+
+sequence "shell-punct" {
+   safe {filename "/usr/share/detox/space.tbl";};
+   safe {filename "/usr/share/detox/punct1.tbl";};
+};
+
+sequence "punct" {
+   # for performance, these might need to be combined into one file
+   safe {filename "/usr/share/detox/space.tbl";};
+   safe {filename "/usr/share/detox/brackets.tbl";};
+   safe {filename "/usr/share/detox/punct1.tbl";};
+   safe {filename "/usr/share/detox/punct2.tbl";};
+};
+
 
 #
 # Files to ignore (detox only)
diff --git a/table/brackets.tbl b/table/brackets.tbl
new file mode 100644
index 000..ade8770
--- /dev/null
+++ b/table/brackets.tbl
@@ -0,0 +1,12 @@
+# See file "LICENSE" for distribution and modification terms.
+
+start
+
+0x28   -   # (
+0x29   -   # )
+0x5b   -   # [
+0x5d   -   # ]
+0x7b   -   # {
+0x7d   -   # }
+
+end
diff --git a/table/punct1.tbl b/table/punct1.tbl
new file mode 100644
index 000..e5eb817
--- /dev/null
+++ b/table/punct1.tbl
@@ -0,0 +1,23 @@
+# See file "LICENSE" for distribution and modification terms.
+
+start
+
+0x21   _   # !
+0x22   _   # "
+0x24   _   # $
+0x27   _   # '
+0x2a   _   # *
+0x2f   _   # /
+0x3a   _

Bug#861199: ceilometer-api systemd service fails to start

[Thomas Goirand]

On 04/28/2017 11:03 AM, Valentin Vidic wrote:
> On Fri, Apr 28, 2017 at 10:54:08AM +0200, Thomas Goirand wrote:
>> I'm not sure how come it worked before, and it doesn't now. I've fixed
>> the issue:
>>
>> https://review.openstack.org/460880
>>
>> Package upload and unblock are following. Thanks for your bug report.
> 
> Great, thanks.  Should I open a new bug for the port 8000 clash between
> ceilometer-api and heat-api-cfn?

You don't. It's fixed, uploaded and unblock!

Thanks for your bug reports.
Cheers,

Thomas Goirand (zigo)

Bug#861537: [PATCH 3] Tidy up table sample filenames - optional patch

[Zenaan Harkness]

 - just tidy up the sample table filenames

 - sample files need to be installed (and are on Debian), at least for new
   users, and shouldn't end with ".sample"

 - also this patch has little undo for space->tab conversion problem in last
   patch (sorry)
---
 etc/detoxrc.sample| 10 +-
 table/{iso8859_1.tbl.sample => iso8859_1.tbl} |  0
 table/{safe.tbl.sample => safe.tbl}   |  0
 table/{unicode.tbl.sample => unicode.tbl} |  0
 4 files changed, 5 insertions(+), 5 deletions(-)
 rename table/{iso8859_1.tbl.sample => iso8859_1.tbl} (100%)
 rename table/{safe.tbl.sample => safe.tbl} (100%)
 rename table/{unicode.tbl.sample => unicode.tbl} (100%)

diff --git a/etc/detoxrc.sample b/etc/detoxrc.sample
index 1e8bfe7..a1d6b9a 100644
--- a/etc/detoxrc.sample
+++ b/etc/detoxrc.sample
@@ -6,15 +6,15 @@
 # met:
 # 
 # 1. Redistributions of source code must retain the above copyright
-#   notice, this list of conditions and the following disclaimer.
+#notice, this list of conditions and the following disclaimer.
 # 
 # 2. Redistributions in binary form must reproduce the above copyright
-#   notice, this list of conditions and the following disclaimer in the
-#   documentation and/or other materials provided with the distribution.
+#notice, this list of conditions and the following disclaimer in the
+#documentation and/or other materials provided with the distribution.
 # 
 # 3. Neither the name of author nor the names of its contributors may be
-#   used to endorse or promote products derived from this software
-#   without specific prior written permission.
+#used to endorse or promote products derived from this software
+#without specific prior written permission.
 # 
 # THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
 # "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
diff --git a/table/iso8859_1.tbl.sample b/table/iso8859_1.tbl
similarity index 100%
rename from table/iso8859_1.tbl.sample
rename to table/iso8859_1.tbl
diff --git a/table/safe.tbl.sample b/table/safe.tbl
similarity index 100%
rename from table/safe.tbl.sample
rename to table/safe.tbl
diff --git a/table/unicode.tbl.sample b/table/unicode.tbl
similarity index 100%
rename from table/unicode.tbl.sample
rename to table/unicode.tbl
-- 
2.9.0

Bug#861517: python-requests: add virtual package python3?-requests-security with added dependencies

[Thomas Goirand]

On 04/30/2017 02:06 AM, Harlan Lieberman-Berg wrote:
> Package: python-requests
> Version: 2.12.4-1
> Severity: wishlist
> 
> Dear Maintainer,
> 
> Python requests ships with a "security" extra that requires an enlarged
> set of dependencies (with python-ndg-httpsclient being the current stone
> in my metaphorical shoe).
> 
> It would be awesome if there was a virtual package that I could depend
> on that would include not just python-requests, but also all the extra
> dependencies that the extra needs.
>   
>   
>   
> 
> 
> Thoughts?

I guess you probably wanted to write "metapackage", which is a package
with dependencies only without any other content. A virtual package is a
package that never really exists, and which a few package have in the
"Provides:" field. For example, the package nova-compute-hypervisor is a
virtual package provided by nova-compute-{ironic,qemu,lxc,kvm}. That's
IMO not what you wanted to ask for.

Cheers,

Thomas Goirand (zigo)

Bug#856843: [Pkg-samba-maint] Bug#856843: smbclient: connection flood to port 445 on mounting cifs volume under kernel 4.9.0

[Eric T]

Hi, I've got the same flood here on port 445, across my LAN. If I block that 
port, I get a flood instead via port 139.

There was 1MB/s upload/download between my Windows 10 machine and a Raspberry 
Pi 3 (Raspbian 4.9.24-v7+).

I blocked that and had the same flood between two Raspberry Pi 3s.

The same thing happened if I fired up my Lubuntu boxes. I can't remember if it 
was the 4.4.0-75-generic or the 4.8.0-29-generic, and I can't re-enable Samba 
right now on the network, as it's "live" and I don't want to disrupt the web 
service.

Not sure if I can attach a Wireshark screenshot of traffic between the two 
Raspberry Pi 3s (?)

Regards,
Eric Twose.

Bug#856521: libwala-java-doc: uninstallable in sid: unsatisfiable Depends: default-java-doc

[Jeremy Bicha]

I don't know what this package is trying to do, but maybe you meant
for it to depend on default-jdk-doc instead?

Thanks,
Jeremy Bicha

Bug#861474: Removing slim fixes the problem

[ael]

Removing the slim package solves the problem, so slim seems to be the
culprit.

Bug#861225: [Regression] Soft lockup in KVM/QEMU virtual machine

[Ben Hutchings]

On Fri, 2017-04-28 at 18:11 +0200, Olav Seyfarth wrote:
> Hi Ben,
> 
> first, thanks for your patience, very much appreciated. I know how hard
> debugging can be, I'm helping with Enigmail If I have time to do so.
> I tried to write clearly but now see that I did not succeed:
> 
> > Based on your original report, giving a kernel log from the guest
> > (which has also been upgraded), I thought you were reporting an issue
> > triggered by upgrading the guest kernel. Now I think what you're
> > actually reporting is that upgrading the host kernel casues guests
> > to crash. Is that correct?
> 
> No. Host and guests received the (unattended) upgrade but downgrading
> the _host_ (only) turned the system in a stable state. You might have
> spotted "Guests still are on 3.16.43-1" in my original report and
> deducted that the host seems to be the culprit. Well hidden, I agree.
> Sorry for that! So maybe you want to rephrase the bug title (again).
> 
> While investigating when my guests did not start, I tried to start them
> using virsh --console - and received (nothing) for some minutes. Just as
> I was about to kill the terminal, there was that kernel panic messages.
> So I saved them, not aware by that time that I was the host's console
> messages being shown. (At least I now think that it was.)
[...]

I think this is the same bug as #861313, which is now fixed in version
3.16.43-2.  That should be available on mirrors in a day or two.  Let
us know if it works for you.

Ben.

-- 
Ben Hutchings
This sentence contradicts itself - no actually it doesn't.


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

Bug#861537: [PATCH 4] Fix UTF-8 pathway, so fall through works properly.

[Zenaan Harkness]

 - This should solve the malformed output bugs on each of the three main
   pathways.

 - Also made one of the new table files sane.
---
 src/clean_string.c |  2 +-
 table/punct2.tbl   | 20 ++--
 2 files changed, 11 insertions(+), 11 deletions(-)

diff --git a/src/clean_string.c b/src/clean_string.c
index f1a75ba..fc84f72 100644
--- a/src/clean_string.c
+++ b/src/clean_string.c
@@ -681,7 +681,7 @@ unsigned char *clean_utf_8(unsigned char *s, void *opts)
/*
 * Null translation == leave it alone
 */
-   *input_walk -= characters_eaten;
+   input_walk -= characters_eaten - 1;
 
while (characters_eaten) {
*output_walk++ = *input_walk++;
diff --git a/table/punct2.tbl b/table/punct2.tbl
index 7a49307..2ea488f 100644
--- a/table/punct2.tbl
+++ b/table/punct2.tbl
@@ -2,15 +2,15 @@
 
 start
 
-0x23   '#'
-0x25   %
-0x2b   +
-0x2c   ,
-0x2d   -
-0x2e   .
-0x3d   =
-0x5e   ^
-0x5f   _
-0x7e   ~
+0x23   _ # '#'
+0x25   _ # %
+0x2b   _ # +
+0x2c   _ # ,
+0x2d   _ # -
+0x2e   _ # .
+0x3d   _ # =
+0x5e   _ # ^
+0x5f   _ # _
+0x7e   _ # ~
 
 end
-- 
2.9.0

Bug#861521: libxstream-java: CVE-2017-7957

[Emmanuel Bourg]

Thank you Salvatore. Here is the upstream commit that has to be backported:

https://github.com/x-stream/xstream/commit/b3570be

Emmanuel Bourg

Bug#861522: dman: fall back on newer or older suites when requested manual page not in current suite

[Antoine Beaupré]

Control: tags -1 +patch

On 2017-04-30 15:06:08, Paul Wise wrote:
> Package: debian-goodies
> Version: 0.71
> Severity: wishlist
> File: /usr/bin/dman
> X-Debbugs-CC: Antoine Beaupré , 
> debian-...@lists.debian.org
>
> dman currently reports an error when I try to use it to read its own
> manual page, because it defaults to stretch with no fallback.

Yes. Note that you can use the --release argument to select a
suite. This works, in other words:

$ ./dman --release experimental dman | head -1
DMAN(1) General Commands Manual   DMAN(1)

> There are several situations where it would be nice to be able to
> automatically fall back to the manual page from a different suite:
>
>  * where the package is only in a newer suite:
> * when using stable and it was first uploaded after the release
> * when using unstable and it was uploaded during the freeze
>  * where the package was removed from unstable recently, is still in
>use on a remote system running stable but dman is run on an unstable
>system
>
> I expect this will probably need support on the server side?
> If so, please clone this bug to the manpages.debian.org package.

This should be possible by making an extra request to the manpages site
without an explicit suite.

Here's a patch, for review:

https://anonscm.debian.org/git/collab-maint/debian-goodies.git/commit/?h=no-suite&id=d6dcb0fc15f340b581c2cf138a1cb02055410090

> pabs@chianamo ~ $ dman dman
> /usr/bin/dman: A download error occurred. Neither
> /usr/bin/dman: https://manpages.debian.org/stretch/dman.en.gz nor
> /usr/bin/dman: https://manpages.debian.org/stretch/dman.gz could be
> fetched.
> pabs@chianamo ~ $ dman --release experimental dman
> pabs@chianamo ~ $ 

I take it the last one succeeded? :)

A.

-- 
That's one of the remarkable things about life: it's never so bad that
it can't get worse.
- Calvin

Bug#861537: [PATCH] Fix Debian Bug#861537: malformed UTF-8 chars in output - failure to fall through

[Zenaan Harkness]

Found the clean_utf_8() bug too (PATCH 4 above).

Now the question comes to mind "why doesn't replacing space with '_'
work in utf_8 mode?"

Detox newbie here, so perhaps there's an obvious reason, but at
least now we can cascade through from safe(), to utf_8(), as needed.

Bug#857296: [hol88-library] hol88-library is an empty package on arm64, hppa, and m68k

[Helmut Grohne]

severity -1 serious
thanks

On Tue, Mar 21, 2017 at 01:32:55PM -0400, Camm Maguire wrote:
> Greetings and thanks for your report!  Am looking into this now

It seems your looking takes longer than expected and you didn't give any
reason for downgrading the severity. I don't think stretch should
release with such a broken hol88-library. This bug is release-critical
for two reasons:

 * The arm64 package is completely useless (actually qualifies for
   grave).
 * It violates policy by not checking for build failures.

So given little maintainer interest, I hereby ask the autoremover to do
its work.

Helmut

Bug#861468: php-monolog: FTBFS (failing tests)

[Ivo De Decker]

Control: retitle -1 php-monolog: FTBFS (failing tests at the end of the month)

Hi,

On Sat, Apr 29, 2017 at 12:23:30PM +, Santiago Vila wrote:
> There was 1 failure:
> 
> 1) Monolog\Handler\RotatingFileHandlerTest::testRotation with data set 
> "Rotation is not triggered when the file of the current month is already 
> present" (false, 'Y-m', Closure Object (...))
> Failed asserting that true matches expected false.

I guess this is a bug in the test:

http://sources.debian.net/src/php-monolog/1.22.0-1/tests/Monolog/Handler/RotatingFileHandlerTest.php/?hl=113#L113

$monthCallback = function($ago) {
return gmmktime(0, 0, 0, date('n') + $ago, date('d'), date('Y'));
};

This is used with values -1, -2, -3 and -4 for $ago. This will not give the
correct month if the date of the month doesn't exist.

Looking at
https://tests.reproducible-builds.org/debian/history/php-monolog.html
it started failing the 29th. With -2 this is February 29th, for which gmmktime
will return March:

$ date;php -r 'print date("c",gmmktime(0, 0, 0, date("n") - 2, date("d"), 
date("Y")))."\n";'
Sun Apr 30 16:14:25 CEST 2017
2017-03-02T01:00:00+01:00

The test failure on 2016-08-31 09:49 in the history above is probably the same
issue.

We'll see if it builds again tomorrow...

Cheers,

Ivo

Bug#861537: [PATCH 5] Fix table/unicode.tbl '#' quoting

[Zenaan Harkness]

 - the number/hash/sharp symbol is now quoted

 - looks like this has not been used much, hopefully this
   utf-8 pathway will see more use soon
---
 table/unicode.tbl | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/table/unicode.tbl b/table/unicode.tbl
index 5828787..4753a03 100644
--- a/table/unicode.tbl
+++ b/table/unicode.tbl
@@ -55,7 +55,7 @@ start
 # characters removed.
 #
 
-0x0023 #   # NUMBER SIGN
+0x0023 '#' # NUMBER SIGN
 0x0025 %   # PERCENT SIGN
 0x0026 _and_   # AMPERSAND
 0x002B +   # PLUS SIGN
-- 
2.9.0

Bug#861541: jessie-pu: package kedpm/1.0

[Antoine Beaupre]

Package: release.debian.org
Severity: normal
Tags: jessie
User: release.debian@packages.debian.org
Usertags: pu

A security issue came up in kedpm as shipped in stable (CVE-2017-8296,
#860817). It was marked "no-dsa" by the security team, to be fixed in
the next point release.

This is therefore my attempt at shipping that update. Unfortunately, I
will be offline very soon, for all of may, so it is unlikely that I
will be able to perform the upload myself, but hopefully someone can
take this and run if I don't respond in time to your permission. :)

Attached is the debdiff, I hope that covers it all...

A.

-- System Information:
Debian Release: 9.0
  APT prefers testing
  APT policy: (500, 'testing'), (1, 'unstable')
Architecture: amd64
 (x86_64)
Foreign Architectures: armhf

Kernel: Linux 4.9.0-2-amd64 (SMP w/4 CPU cores)
Locale: LANG=fr_CA.UTF-8, LC_CTYPE=fr_CA.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
diff -Nru kedpm-1.0/debian/changelog kedpm-1.0+deb8u1/debian/changelog
--- kedpm-1.0/debian/changelog  2012-11-30 15:45:14.0 -0500
+++ kedpm-1.0+deb8u1/debian/changelog   2017-04-26 20:44:11.0 -0400
@@ -1,3 +1,10 @@
+kedpm (1.0+deb8u1) jessie; urgency=high
+
+  * Non-maintainer upload by the Security Team.
+  * fix information leak via command history file (Closes: #860817)
+
+ -- Antoine Beaupré   Wed, 26 Apr 2017 20:44:11 -0400
+
 kedpm (1.0) unstable; urgency=low
 
   * New upstream release.
diff -Nru 
kedpm-1.0/debian/patches/0001-always-prompt-for-password-and-do-not-save-to-databa.patch
 
kedpm-1.0+deb8u1/debian/patches/0001-always-prompt-for-password-and-do-not-save-to-databa.patch
--- 
kedpm-1.0/debian/patches/0001-always-prompt-for-password-and-do-not-save-to-databa.patch
1969-12-31 19:00:00.0 -0500
+++ 
kedpm-1.0+deb8u1/debian/patches/0001-always-prompt-for-password-and-do-not-save-to-databa.patch
 2017-04-26 20:43:55.0 -0400
@@ -0,0 +1,61 @@
+From b8f7e8b3b2cb37425cb89b205c9836c6ac02a048 Mon Sep 17 00:00:00 2001
+From: =?UTF-8?q?Antoine=20Beaupr=C3=A9?= 
+Date: Wed, 26 Apr 2017 16:58:56 -0400
+Subject: [PATCH 1/2] always prompt for password and do not save to database
+
+---
+ kedpm/frontends/cli.py | 38 +++---
+ 1 file changed, 15 insertions(+), 23 deletions(-)
+
+diff --git a/kedpm/frontends/cli.py b/kedpm/frontends/cli.py
+index c343138..27cfb70 100644
+--- a/kedpm/frontends/cli.py
 b/kedpm/frontends/cli.py
+@@ -591,29 +591,21 @@ def complete_rename(self, text, line, begidx, endidx):
+ return self.complete_dirs(text, line, begidx, endidx)
+ 
+ def do_passwd(self, arg):
+-"""Change master password for opened database
+-
+-Syntax:
+-password [new password]
+-
+-If new password is not provided with command, you will be promted to enter new
+-one.
+-"""
+-
+-if not arg:
+-# Password is not provided with command. Ask user for it
+-pass1 = getpass(_("New password: "))
+-pass2 = getpass(_("Repeat password: "))
+-if pass1 == '':
+-print _("Empty passwords are really insecure. You should " \
+-"create one.")
+-return
+-if pass1!=pass2:
+-print _("Passwords don't match! Please repeat.")
+-return
+-new_pass = pass1
+-else:
+-new_pass = arg
++"""Change master password for opened database"""
++
++# remove possibly master password from history file
++readline.remove_history_item(readline.get_current_history_length()-1)
++# Password is not provided with command. Ask user for it
++pass1 = getpass(_("New password: "))
++pass2 = getpass(_("Repeat password: "))
++if pass1 == '':
++print _("Empty passwords are really insecure. You should " \
++"create one.")
++return
++if pass1!=pass2:
++print _("Passwords don't match! Please repeat.")
++return
++new_pass = pass1
+ 
+ self.pdb.changePassword(new_pass)
+ self.printMessage(_("Password changed."))
+-- 
+2.11.0
+
diff -Nru kedpm-1.0/debian/patches/series kedpm-1.0+deb8u1/debian/patches/series
--- kedpm-1.0/debian/patches/series 1969-12-31 19:00:00.0 -0500
+++ kedpm-1.0+deb8u1/debian/patches/series  2017-04-26 20:43:55.0 
-0400
@@ -0,0 +1 @@
+0001-always-prompt-for-password-and-do-not-save-to-databa.patch

Bug#861540: menulibre: Unresponsive after delete launcher attempt

[Frédéric Mesplède]

Package: menulibre
Version: 2.0.6-1
Severity: normal
Tags: upstream

Dear Maintainer,

Whenever I try to delete a launcher with menulibre, the software becomes
unresponsive. A window pops up to ask me if I am sure to delete the launcher
and whether I choose OK or Cancel it does not respond and remains stuck on this
pop up window.

Thank you for your time and work!



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

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

Versions of packages menulibre depends on:
ii  gir1.2-gdkpixbuf-2.0  2.31.1-2+deb8u5
ii  gir1.2-glib-2.0   1.42.0-2.2
ii  gir1.2-gmenu-3.0  3.13.3-6
ii  gir1.2-gtk-3.03.14.5-1+deb8u1
ii  gnome-menus   3.13.3-6
ii  python3   3.4.2-2
ii  python3-gi3.14.0-1
ii  python3-psutil2.1.1-1+b1
pn  python3:any   
ii  xdg-utils 1.1.0~rc1+git20111210-7.4

menulibre recommends no packages.

menulibre suggests no packages.

-- no debconf information

Bug#860648: gap-radiroot: FTBFS on i386: not enough memory during build on i386o

[Bill Allombert]

On Thu, Apr 27, 2017 at 05:18:38PM +0200, Lucas Nussbaum wrote:
> On 27/04/17 at 15:22 +0200, Bill Allombert wrote:
> > On Thu, Apr 27, 2017 at 02:53:07PM +0200, Lucas Nussbaum wrote:
> > > > Hello Lucas,
> > > > Sorry for the delay, for some reason my ISP blocked this email.
> > > > Do you know how much memory is there on this system ?
> > > > The test suite need 128M which does not seems unreasonable.
> > > > 
> > > > I did a test build using cowbuilder for stretch i386 and it worked fine.
> > > > It seems to me your system was experiencing a memory crunch during the
> > > > build.
> > > 
> > > 256 GB of RAM on the amd64 host, of which only 4GB is available per
> > > process since it's i386.
> > 
> > How many threads 
> > getconf _NPROCESSORS_CONF
> > report ?
> > 
> > I think the problem is that it needs 128M by threads.
> 
> 64, so yes, that's probably the issue

There is only 64MB of virtual memory by threads.
It is not a very realistic setup.
No real i386 box is going to have some much threads.

Honestly I do not really know how to fix this unless I hardcode
a limit for the number of threads in the test suite.

Cheers,
-- 
Bill. 

Imagine a large red swirl here. 

Bug#861540: Unresponsive after delete launcher attempt

[Frédéric Mesplède]

Apparently the launcher was deleted because when I restarted menulibre
the launcher I wanted to delete was gone but I had to hit Escape to
close the pop up window and then close menulibre and restart it.

Bug#861542: debian-faq: LSB support in Debian stretch

[Frank Lin PIAT]

Package: debian-faq
Version: 8.1
Severity: normal

Hello,

The state of LSB in Debian Strech is modified, as described in package lsb NEWS
file (quoted below) and in the release notes (see Bug#804264):
URL: 
https://www.debian.org/releases/stretch/amd64/release-notes/ch-information.en.html#reduced-lsb-support

I suppose the FAQ §4.3 should be updated :
  "How compatible is Debian with other distributions of Linux?"
  URL 
https://www.debian.org/doc/manuals/debian-faq/ch-compat.html#s-otherdistribs

Regards,

Franklin

Quoting lsb NEWS files
> lsb (9.20150826) unstable; urgency=low
>
>  This update drops all lsb-* compatibility packages, and is therefore
>  an abandon of the pursuit of LSB compatibility for Debian. Only
>  lsb-release and lsb-base are kept as they continue to be used 
>  throughout the archive.
>
> -- Didier Raboud   Wed, 26 Aug 2015 12:00:00 +0200


Compare the package list:
https://packages.debian.org/source/jessie/lsb
https://packages.debian.org/source/stretch/lsb

Bug#860515: Many translations missing in french KDE lang packages while we're close to release

[Julien Aubin]

Hi Maximiliano,

Thanks to Pino we've found the root of issue, which is that translations in
file  /usr/share/locale/fr/LC_MESSAGES/kwidgetaddons5_qt.qm are wrong,
which causes the OK/Cancel/Apply buttons to stay in English in all KDE Qt5
apps, and other buttons and confirm dialogs like the one which allows users
to customize keyboard shortcuts.

The fix consists in backporting this file from kwidgetsaddons 5.29.0 (only
for French translations), which fixes the issue.

Gentoo has this version of the lib, and I could test with Gentoo's
/usr/share/locale/fr/LC_MESSAGES/kwidgetaddons5_qt.qm file which makes the
issue disappear.

Could you please backport this file and re-release the package ?

If you need help to test the packages I can do this as long as it does not
break all libkf5*.

Many thanks,

Julien.

2017-04-28 21:59 GMT+02:00 Julien Aubin :

> Hi,
>
> I could test with Gentoo file for 
> /usr/share/locale/fr/LC_MESSAGES/kwidgetaddons5_qt.qm
> and it fixes the issue for all KDE Qt5 Apps. Gentoo uses version 5.29.0 of
> this package. Backporting the translation file to Debian will do the trick.
>
> Thanks again.
>
>
> 2017-04-28 7:10 GMT+02:00 Julien Aubin :
>
>> Le 28 avr. 2017 06:55, "Pino Toscano"  a écrit :
>>
>>> In data venerdì 28 aprile 2017 04:27:04 CEST, Julien Aubin ha scritto:
>>> > Le 27 avr. 2017 23:29, "Pino Toscano"  a écrit :
>>> >
>>> > In data giovedì 27 aprile 2017 22:30:43 CEST, Julien Aubin ha scritto:
>>> > > >
>>> > > >
>>> > > >
>>> > > > > This is why to me this bug is a showstopper for release, as
>>> > > > > there are many French Debian users around (incl. Africa and
>>> Quebec)
>>> > and
>>> > > > > such an issue makes UX issue look... amateurish.
>>> > > >
>>> > > > This is still not a reason to make this bug "grave" from the
>>> beginning,
>>> > > > with only generic and unhelpful instructions on *where* to find the
>>> > > > issue.
>>> > > >
>>> > > > For the rest of the details, see my other email.
>>> > > >
>>> > > > > For apps with full untranslated sections, adding the files I
>>> below
>>> > would
>>> > > > > solve the issue.
>>> > > >
>>> > > > Not really, no. This list has no utility, other than "some things
>>> where
>>> > > > not translated to French in software currently packaged in Debian".
>>> > > >
>>> > >
>>> > > Okay I understand. Now it would be really great to include them
>>> before
>>> > > release.
>>> >
>>> > Include what?
>>> >
>>> >
>>> > The untranslated messages for kmail antispam, korganizer, ...
>>>
>>> They are not part of kde-l10n/fr 16.04.x, which means they were not
>>> translated, and thus there's nowhere we can take them from.
>>> They are not even translated in 16.08.x (which is the version of the
>>> majority of non-PIM stuff from KDE Applications), so what you ask is
>>> simply not possible.
>>>
>>
>> Okay too bad :'( but well if these are the only chunks of translations
>> which are missing this is a smaller issue, even though they exist in
>> kde-l10n-pl.
>>
>> But backporting French translations from libkf5widgetsaddons-data 5.29
>> seems essential to me as without it every single KDE Qt5 app is crippled
>> with English text when using a French KDE, i.e. Konsole, Calligra suite,
>> Krita, Kdenlive, Dolphin, Kontact, ... Don't hesitate to ask me to test as
>> long as updating this package w/ libkf5widgetsaddons on my system does not
>> break other dependencies.
>>
>>>
>>> --
>>> Pino Toscano
>>
>>
>

Bug#861543: RFS: golang-github-jacobsa-bazilfuse/0.0~git20150622-2 [RC] -- fork of bazil.org/fuse for gcsfuse

[Roger Shimizu]

Package: sponsorship-requests
Severity: important
X-Debbugs-Cc: pkg-go-maintain...@lists.alioth.debian.org, rogershim...@gmail.com

Dear mentors,

I am looking for a sponsor for package "golang-github-jacobsa-bazilfuse"
This fixes an FTBFS RC bug #860623.

 * Package name: golang-github-jacobsa-bazilfuse
   Version : 0.0~git20150622-2
 * URL : https://github.com/jacobsa/bazilfuse
 * License : Go
   Section : devel

It builds those binary packages:

  golang-github-jacobsa-bazilfuse-dev - fork of bazil.org/fuse for gcsfuse

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

  https://mentors.debian.net/package/golang-github-jacobsa-bazilfuse

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

  dget -x 
https://mentors.debian.net/debian/pool/main/g/golang-github-jacobsa-bazilfuse/golang-github-jacobsa-bazilfuse_0.0~git20150622-2.dsc

Changes since the last upload:

golang-github-jacobsa-bazilfuse (0.0~git20150622-2) unstable; urgency=medium

  * Team upload.

  [ Paul Tagliamonte ]
  * Use a secure transport for the Vcs-Git and Vcs-Browser URL

  [ Roger Shimizu ]
  * debian/patches:
- Add a patch to fix FTBFS on i386 and other 32-bit systems.
  (Closes: #860623)
  * debian/control:
- Use cgit URL for Vcs-Browser.

Thank you and look forward to the upload!

Cheers,
-- 
Roger Shimizu, GMT +9 Tokyo
PGP/GPG: 4096R/6C6ACD6417B3ACB1


pgpIqOrKQXsZu.pgp
Description: PGP signature

Bug#860623: Pending fixes for bugs in the golang-github-jacobsa-bazilfuse package

[pkg-go-maintainers]

tag 860623 + pending
thanks

Some bugs in the golang-github-jacobsa-bazilfuse package are closed
in revision 88958ce7251d119d1ecf90e462a2b17348c8ff50 in branch ' 
mentors' by Roger Shimizu

The full diff can be seen at
https://anonscm.debian.org/cgit/pkg-go/packages/golang-github-jacobsa-bazilfuse.git/commit/?id=88958ce

Commit message:

debian/patches: Add a patch

Patch to fix FTBFS on i386 and other 32-bit systems

Closes: #860623

Bug#861543: RFS: golang-github-jacobsa-bazilfuse/0.0~git20150622-2 [RC] -- fork of bazil.org/fuse for gcsfuse

[Roger Shimizu]

On Mon, 1 May 2017 00:35:34 +0900
Roger Shimizu  wrote:

> I am looking for a sponsor for package "golang-github-jacobsa-bazilfuse"
> This fixes an FTBFS RC bug #860623.

Sorry that I forgot to mention the changes are pushed to:
  
https://anonscm.debian.org/cgit/pkg-go/packages/golang-github-jacobsa-bazilfuse.git
-b mentors

-- 
Roger Shimizu, GMT +9 Tokyo
PGP/GPG: 4096R/6C6ACD6417B3ACB1


pgpcfJopC2ldE.pgp
Description: PGP signature

Bug#859846: jessie-pu: package vlc/2.2.5-1~deb8u1

[Adam D. Barratt]

Control: tags -1 + pending

On Sun, 2017-04-30 at 13:06 +0200, Sebastian Ramacher wrote:
> On 2017-04-28 17:51:21, Adam D. Barratt wrote:
> > Control: tags -1 + confirmed
> > 
> > On Fri, 2017-04-07 at 19:45 +0200, Sebastian Ramacher wrote:
> > > I'd like to update vlc to the latest upstream bug fix release in jessie. 
> > > It
> > > fixes various integer and buffer overflows, NULL pointer dereferences, 
> > > division
> > > by zero errors, heap corruptions that can be triggered during playback.
> > 
> > Please go ahead, bearing in mind that the window for 8.8 closes during
> > the weekend.
> 
> Thanks, uploaded.

Flagged for acceptance.

Regards,

Adam

Bug#861544: pulseaudio: no sound after mute and unmute when volume is 0

[James N.]

Package: pulseaudio
Version: 5.0-13
Severity: normal

Dear Maintainer,

   * What led up to the situation?
Mute and unmute the sound with keyboard control when volume is 0 causes loss of
sound on the device being used. Even after increasing the volume in pulseaudio
and alsamixer, and reboot, still no sound on internal speakers of my laptop but
i have sound on headphones jack connector. Repeat the same operation when the
headphones is connected causes the same problem.
   * What exactly did you do (or not do) that was effective (or
 ineffective)?
alsactl init does not solve the problem.
Reinstall alsa and pulsedio does not solve the problem.
Set the volume to 0, mute and unmute with the keyboard control, and increasing
the volume allows to find the sound. The problem is less when you know the
solution, I took about three months to find this solution. How could the
problem be resolved definitively?

Sound card : 00:1b.0 Audio device: Intel Corporation 82801I (ICH9 Family) HD
Audio Controller (rev 03)
Distrib : Debian 8.6
Graphical environment : Gnome3
Laptop : COMPAQ-6830S



-- Package-specific info:
File '/etc/default/pulseaudio' does not exist



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

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

Versions of packages pulseaudio depends on:
ii  adduser   3.113+nmu3
ii  libasound21.0.28-1
ii  libasound2-plugins1.0.28-1+b1
ii  libc6 2.19-18+deb8u7
ii  libcap2   1:2.24-8
ii  libdbus-1-3   1.8.22-0+deb8u1
ii  libfftw3-single3  3.3.4-2
ii  libgcc1   1:4.9.2-10
ii  libice6   2:1.0.9-1+b1
ii  libltdl7  2.4.2-1.11+b1
ii  liborc-0.4-0  1:0.4.22-1
ii  libpulse0 5.0-13
ii  libsamplerate00.1.8-8
ii  libsm62:1.2.2-1+b1
ii  libsndfile1   1.0.25-9.1+deb8u1
ii  libspeexdsp1  1.2~rc1.2-1
ii  libstdc++64.9.2-10
ii  libsystemd0   215-17+deb8u6
ii  libtdb1   1.3.6-0+deb8u1
ii  libudev1  215-17+deb8u6
ii  libwebrtc-audio-processing-0  0.1-3
ii  libx11-6  2:1.6.2-3
ii  libx11-xcb1   2:1.6.2-3
ii  libxcb1   1.10-3+b1
ii  libxtst6  2:1.2.2-1+b1
ii  lsb-base  4.1+Debian13+nmu1
ii  pulseaudio-utils  5.0-13
ii  udev  215-17+deb8u6

Versions of packages pulseaudio recommends:
ii  pulseaudio-module-x11  5.0-13
ii  rtkit  0.11-2

Versions of packages pulseaudio suggests:
ii  paman0.9.4-1
ii  paprefs  0.9.10-1
ii  pavucontrol  2.0-3
ii  pavumeter0.9.3-4

-- no debconf information
# This file is part of PulseAudio.
#
# PulseAudio is free software; you can redistribute it and/or modify
# it under the terms of the GNU Lesser General Public License as published by
# the Free Software Foundation; either version 2 of the License, or
# (at your option) any later version.
#
# PulseAudio is distributed in the hope that it will be useful, but
# WITHOUT ANY WARRANTY; without even the implied warranty of
# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
# General Public License for more details.
#
# You should have received a copy of the GNU Lesser General Public License
# along with PulseAudio; if not, write to the Free Software
# Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307
# USA.

## Configuration file for PulseAudio clients. See pulse-client.conf(5) for
## more information. Default values are commented out.  Use either ; or # for
## commenting.

; default-sink =
; default-source =
; default-server =
; default-dbus-server =

; autospawn = yes
; daemon-binary = /usr/bin/pulseaudio
; extra-arguments = --log-target=syslog

; cookie-file =

; enable-shm = yes
; shm-size-bytes = 0 # setting this 0 will use the system-default, usually 64 
MiB

; auto-connect-localhost = no
; auto-connect-display = no
# This file is part of PulseAudio.
#
# PulseAudio is free software; you can redistribute it and/or modify
# it under the terms of the GNU Lesser General Public License as published by
# the Free Software Foundation; either version 2 of the License, or
# (at your option) any later version.
#
# PulseAudio is distributed in the hope that it will be useful, but
# WITHOUT ANY WARRANTY; without even the implied warranty of
# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
# General Public License for more details.
#
# You should have received a copy of the GNU Lesse

Bug#857995: respawn loop due to insufficient permissions

[Michael Biebl]

On Thu, 23 Mar 2017 07:10:05 -0400 Jeremy Bicha  wrote:
> By the way, the constant respawn is really annoying when I install
> stretch on VirtualBox.
> 
> I use the latest stretch testing netboot iso to install. Then I need
> to boot to a command line with Internet so I can install
> virtualbox-guest-x11 from sid (in order to be able to use a graphical
> desktop because Debian Security doesn't want VirtualBox in stretch).
> But first I have to wait 5 minutes for gdm to stop trying to load
> (effectively a Denial of Service) before I can use a virtual terminal.

Yeah, noticed this as well. Pretty sucky user experience.
Since virtualbox is no longer available in stretch, as an alternative,
you can use xserver-xorg-legacy.

Might be a good idea if d-i installed that automatically if it detects a
VBox environment.

Michael


-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?



signature.asc
Description: OpenPGP digital signature

Bug#861425: priority difference

[Julien Cristau]

Control: reassign -1 aptitude
Control: severity -1 minor
Control: retitle -1 aptitude: package priority mismatch

On Fri, Apr 28, 2017 at 22:40:01 +0200, SZÉPE Viktor wrote:

> Package: mirrors
> Severity: important
> 
> Hello!
> 
> The Packages files contains "optional".
> 
> $ wget -qO- 
> http://ftp.debian.org/debian/dists/stretch/main/binary-arm64/Packages.gz|zgrep
> -Fx -A18 "Package: aptitude"|tail -n 1
> Priority: optional
> 
> The package contains "important".
> 
> In
> http://ftp.debian.org/debian/pool/main/a/aptitude/aptitude_0.8.7-1_amd64.deb
> control files has:
> Priority: important
> 
> Please advise.

The Packages file contains the authoritative information, the priority
in the package itself can pretty much be ignored.

Cheers,
Julien

Bug#861218: libgssapi-krb5-2: soname-independent files in shared library package (policy 8.2)

[Sam Hartman]

> "Helmut" == Helmut Grohne  writes:

Helmut> Package: libgssapi-krb5-2 Version: 1.15-1 Severity: serious
Helmut> libgssapi-krb5-2 is a shared library package and contains
Helmut> /etc/gss/mech.d/README. The latter filename does not depend
Helmut> on the soname of the library and thus does not change when
Helmut> the soname changes.

Hi.

I'm going to start by  explaining why that file is there and asking for
your help in figuring out what to do.
I'm then going to argue that this is not an RC bug (probably not even a
bug at all).
But I'm more interested in finding a solution that works for us both
than simply closing bugs because I can.

The issue is that older versions of krb5 had two related problems with
regard to /etc/gss/mech.d:

1) They only supported a config file for reading mechanism config, not
an entire directory

2) Because of a bug in how I set prefix, they read /usr/etc/gss/mech not
/etc/gss/mech as that config file.

Nothing shipped /usr/etc/gss/mech on Debian--it's clearly not
FHS-compatible.

However, there are some gss mechanism packages, mostly not in Debian,
that need to configure themselves even on older krb5.
I needed a way to figure out whether the gss library was new enough to
read /etc/gss/mech.d.

So I dropped a README in that directory.  Code that detects that file
and uses it as a flag not to create and write /usr/etc/gss/mech has
escaped.  The main culprit is moonshot-gss-eap (especially versions not
in Debian), but I've recommended the approach to others and not tracked
where all it might be being used.

I think we can move away from that approach for stretch +1, but I really
kind of need that file to be there, and I'm quite uncomfortable trying
to get the replaces/conflicts/provides dance correct this late in the
stretch cycle.


So, that's why I care about the file for stretch, and why I want to be
careful about a fix.

I claim this is not a violation of policy 8.2.  In particular, It seems
very likely that if the soname of libgssapi_krb5 changes, you'll need
different mechanism configuration for the new version.  It seems very
unlikely that the same mechanism will work for GSS v2 and v3.  So, I'd
expect the directory to be /etc/gss3/mech.d or /etc/gss/mech3.d, and if
the readme were retained, I'd expect it to be in that new directory in
the new library.

That said, I'll note that libgssapi_krb5.so.2 has been stable since
before the release of Kerberos 1.0 back in 1995.  A change in gss's
soname is going to be a huge massive pain in all sorts of ways if it
ever happens, and I don't think having to deal with one README is going
to even make the headache list.

You said that you're running into dpkg issues.
I'm sympathetic to that, but I'd like to find a way that your needs and
mine can both be met.

--Sam

Bug#861518: libc6-dev: The newest libc6-dev (2.24-10) badly depends on kernel, particularly linux-libc-dev (>= 4.9.18-1)

[Laci Tele]

Hi Aurelien,

On Sun, Apr 30, 2017 at 2:55 PM, Aurelien Jarno 
wrote:

> control: tag -1 + moreinfo
> thanks
>
> On 2017-04-29 18:49, Laci Tele wrote:
> > Package: libc6-dev
> > Version: 2.24-10
> > Severity: important
> >
> > Dear Maintainer,
> >
> >
> >* What led up to the situation?
> >
> > I tried to install libc6-dev on my armhf embedded hardware.
> > Its not possible, because dependencies are not met.
> > Because the newest libc6-dev depends particularly on linux-kernel
> > (>= 4.9.18-1), and this is an error, at least I hope its not intentional.
>
> Not it doesn't depends on the latest kernel. It depends on the latest
> kernel *headers* which are provided by linux-libc-dev.
>
>

And the package linux-libc-dev provided by the linux kernel. So libc6-dev
depends on linux kernel (>= 4.9.18-1), via linux-libc-dev (>= 4.9.18-1)


> > Because many embedded armhf devices use older kernels, 4.1 , 4.4 ... so
> on
> > , it depends on BSP what you can get from the HW vendor. Usually they
> have no 4.9 or any near to mainline kernel.
>
> Yes, that's something known. libc6 requires at least a 3.2 kernel on
> most architectures, and 2.6.32 on i386 and amd64.
>
> > So they have no linux-libc-dev (>= 4.9.18-1)
>
> You can install linux-libc-dev (>= 4.9.18-1) even if you're embedded
> device uses a 4.1 or 4.4 kernel. It's provided in the Debian archive.
>

I don't want to install linux-libc-dev (>= 4.9.18-1) which one belongs to
the kernel  (>= 4.9.18-1) , but I have an installed a 4.1.15-2 kernel and
it's own linux-libc-dev (4.1.15-2) package.

And I have mentioned that, this dependency is a new thing,  in the whole
history of libc6-dev (until 2.24-10) it depended only a versionless
linux-libc-dev (linux header files in general without specific version).
This new, few days old dependency breaks the things badly.
Is it necessary indeed ?


>
> > So they cant install libc6-dev (2.24-10)
> > So actually they can't develop.
>
> Please try to install libc6-dev and linux-libc-dev from stretch or sid.
> If it fails to install, please provide the error message from apt,
> aptitude or dpkg showing the issue.
>

It doesn't fail, its possible to do that, but its a mistake, its an error.
Obviously using a header which belongs to a much newer kernel than the
current one is not so healthy. The things declared in the linux headers
 (>= 4.9.18-1) might or might not exist in the working kernel 4.1.15 .
Your method seemingly works, but you just sow the seeds of latent and hard
to detect errors in the future. I can't imagine that, if a binary was built
based on a mismatching header if that worked perfectly in a totally
different and older environment. Maybe if you use color codes, of some
version independent defines only from that header you used. But that is
very unlikely.
If your binary expects something at runtime, because it was declared so at
build-time, and it can't find it because it doesn't exist, that will be a
bad error. This is my opinion.
And developers must be 100% disciplined about this. The "its possible" and
"it seems good and working" that is not enough.


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

Regards,
Laci

Bug#859255: binNMU needed for more R packages.

[Julien Cristau]

On Sat, Apr  1, 2017 at 15:24:53 +0900, Charles Plessy wrote:

> Package: release.debian.org
> Severity: grave
> X-Debbugs-CC: debian-...@lists.debian.org, debian-scie...@lists.debian.org
> 
> Hello again,
> 
> as a follow-up to #858183, I looked at which other R Bioconductor
> packages were broken by R 3.3.3-1, and it seems that the previous round
> of binNMUs did not repair some of them.
> 
> Can you make the followig binNMUs ?
> 
> nmu r-bioc-rsamtools_1.26.1-2 . ANY . -m "Rebuild for R 3.3.3." 
> nmu r-bioc-shortread_1.32.0-1 . ANY . -m "Rebuild for R 3.3.3." 
> nmu r-bioc-variantannotation_1.20.2-1 . ANY . -m "Rebuild for R 3.3.3." 
> nmu r-bioc-genomicalignments_1.10.0-1 . ANY . -m "Rebuild for R 3.3.3." 
> 
> Note to debian-science: there are also R CRAN packages that fail with R
> 3.3.3, (r-cran-lubridate, r-cran-spam), but I am not yet sure if a
> binNMU is enough.
> 
binNMUs are not an acceptable way to deal with silent breakage.  If R
3.3.3-1 breaks reverse dependencies, it needs to not be co-installable
with them.

Cheers,
Julien

Bug#861305: python-cairo-dbg: unhandled symlink to directory conversion: /usr/share/doc/PACKAGE

[Ivo De Decker]

Control: tags -1 patch

Hi,

On Thu, Apr 27, 2017 at 10:40:40AM +0200, Andreas Beckmann wrote:
> an upgrade test with piuparts revealed that your package installs files
> over existing symlinks and possibly overwrites files owned by other
> packages. This usually means an old version of the package shipped a
> symlink but that was later replaced by a real (and non-empty)
> directory. This kind of overwriting another package's files cannot be
> detected by dpkg.
> 
> This was observed on the following upgrade paths on i386:
> 
>   lenny -> squeeze -> wheezy -> jessie -> stretch

This issue, introduced during the lenny -> squeeze upgrade, can be fixed by
using symlink_to_dir. The attached patch should fix it.

Cheers,

Ivo

commit 603827e1eb88611a20fe36925fc49b6db3f960e5
Author: Ivo De Decker 
Date:   Sun Apr 30 17:24:33 2017 +0200

Add python-cairo-dbg.maintscript

diff --git a/debian/changelog b/debian/changelog
index 80003e6..3f68c9a 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,11 @@
+pycairo (1.8.8-2.2) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Add python-cairo-dbg.maintscript to cleanup symlink left over from version
+1.4.12-1.2 (lenny). (Closes: #861305)
+
+ -- Ivo De Decker   Sun, 30 Apr 2017 17:22:42 +0200
+
 pycairo (1.8.8-2.1) unstable; urgency=medium
 
   * Non-maintainer upload.
diff --git a/debian/python-cairo-dbg.maintscript b/debian/python-cairo-dbg.maintscript
new file mode 100644
index 000..b01e49e
--- /dev/null
+++ b/debian/python-cairo-dbg.maintscript
@@ -0,0 +1 @@
+symlink_to_dir /usr/share/doc/python-cairo-dbg /usr/share/doc/python-cairo 1.8.8-2.2~

Bug#861425: priority difference

[Szépe Viktor]

Thank you. 

I've realized there are override files in a Debian repo.
https://github.com/szepeviktor/debian-server-tools/blob/master/debian-image-normalize.sh#L169

Stretch introduced quiet a change in those overridden priorities.

All the best! 
Viktor
-- 
+36204242498
Ezen a készüléken sok az elütés. 
Elnézést!

On April 30, 2017 6:01:48 PM CEST, Julien Cristau  wrote:
>Control: reassign -1 aptitude
>Control: severity -1 minor
>Control: retitle -1 aptitude: package priority mismatch
>
>On Fri, Apr 28, 2017 at 22:40:01 +0200, SZÉPE Viktor wrote:
>
>> Package: mirrors
>> Severity: important
>> 
>> Hello!
>> 
>> The Packages files contains "optional".
>> 
>> $ wget -qO-
>http://ftp.debian.org/debian/dists/stretch/main/binary-arm64/Packages.gz|zgrep
>> -Fx -A18 "Package: aptitude"|tail -n 1
>> Priority: optional
>> 
>> The package contains "important".
>> 
>> In
>>
>http://ftp.debian.org/debian/pool/main/a/aptitude/aptitude_0.8.7-1_amd64.deb
>> control files has:
>> Priority: important
>> 
>> Please advise.
>
>The Packages file contains the authoritative information, the priority
>in the package itself can pretty much be ignored.
>
>Cheers,
>Julien

Bug#859913: [Pkg-fonts-devel] Bug#859913: fonts-droid-fallback does not properly replace fonts-droid

[Juha Heinanen]

Vasudev Kamath writes:
> 
> From the changelog  of the packageits already done, Upstream stopped
> shipping fonts

OK thanks, I switch in Emacs to Noto Mono:

(add-to-list 'default-frame-alist '(font . "Noto Mono-10"))

-- Juha

Bug#861545: libwagon2-java: Version upgrade request to 2.12

[Elana Hashman]

Package: libwagon2-java
Version: 2.10-6
Severity: wishlist
Control: block 819811 by -1

To facilitate packaging leiningen2, this package needs an upgrade to 
version 2.12. Phil Hagelberg says this version is needed to fix a bug 
with self-signed certificates.

Bug#856603: RFS: arc-theme/20170302-1

[Julien Cristau]

On Fri, Mar 31, 2017 at 16:57:18 +, Gianfranco Costamagna wrote:

> Hello,
> 
> 
> >> 3.22.9-1 is a whole new upstream release, with changes that actively break
> >> unrelated packages.  As you just mentioned, it does at least require themes
> >> to be updated, and, as usual for GTK 3 new releases, probably a bunch of
> >> gtk-3 using programs as well.
> >
> >That's not usual for point releases, in this case a bad change slipped 
> >through.
> >That has been fixed in 3.22.9-3.
> >That bug was introduced in 3.22.9, it doesn't affect 3.22.8. So no, nothing
> >needs to go through tpu.
> >
> >BTW thanks for the notice about this regression.
> 
> 
> so, now that 3.22.11 is going to go in testing... can we upload this one?
> 
If something was not appropriate 2 months ago, it is even less so now...

Cheers,
Julien

Bug#856603: RFS: arc-theme/20170302-1

[Michael Biebl]

Am 30.04.2017 um 18:39 schrieb Julien Cristau:
> On Fri, Mar 31, 2017 at 16:57:18 +, Gianfranco Costamagna wrote:
> 
>> Hello,
>>
>>
 3.22.9-1 is a whole new upstream release, with changes that actively break
 unrelated packages.  As you just mentioned, it does at least require themes
 to be updated, and, as usual for GTK 3 new releases, probably a bunch of
 gtk-3 using programs as well.
>>>
>>> That's not usual for point releases, in this case a bad change slipped 
>>> through.
>>> That has been fixed in 3.22.9-3.
>>> That bug was introduced in 3.22.9, it doesn't affect 3.22.8. So no, nothing
>>> needs to go through tpu.
>>>
>>> BTW thanks for the notice about this regression.
>>
>>
>> so, now that 3.22.11 is going to go in testing... can we upload this one?
>>
> If something was not appropriate 2 months ago, it is even less so now...

I want to add, that the relevant changes in gtk have been reverted
upstream as well in 3.22.10. So no changes should be necessary for
arc-theme.


-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?



signature.asc
Description: OpenPGP digital signature

Bug#741233: qa.debian.org: send periodic emails for testing migration issues

[Julien Cristau]

On Fri, Mar 17, 2017 at 15:29:10 +0100, Mattia Rizzolo wrote:

> CC-ing d-release.
> 
> On Mon, Mar 10, 2014 at 02:35:13PM +0530, Ritesh Raj Sarraf wrote:
> > There are multiple reasons for packages not migrating to testing.
> > Currently, AFAIK, the maintainer has no automated way of knowing this.
> > 
> > It would be good if an automated email is send whenever a migration is
> > stalled for some reason.
> 
> Ubuntu recently implemented this in their britney instance, see the
> commits starting by
> https://git.launchpad.net/~ubuntu-release/britney/+git/britney2-ubuntu/commit/?id=2775a5435ca04a11f9692054ffdf5bd3bc1982fa
> 
> I also concour this is a great idea, but I wonder if this should rather
> go in britney2 (as Ubuntu did) or somewhere else, and whether it should
> be maintained by the release team or some other team; I already find
> weird that the testing watcher is not run by them.
> 
Patches welcome, I guess?  I would argue there's value in a central
thing sending that sort of mail rather than each service sending its own
separate reminders.  Once upon a time ddpo-by-mail sort of did this, I think?

Cheers,
Julien

Bug#861112: xsane: always crashes on start

[Jörg Frings-Fürst]

Hello Wolfgang,

thank you for spending your time helping to make Debian better with
this bug report.


I have a bugfix release for sane-backend ready and I send it to you.

Please can you test the packages?


CU
Jörg

-- 
New:
GPG Fingerprint: 63E0 075F C8D4 3ABB 35AB  30EE 09F8 9F3C 8CA1 D25D
GPG key (long) : 09F89F3C8CA1D25D
GPG Key: 8CA1D25D
CAcert Key S/N : 0E:D4:56

Old pgp Key: BE581B6E (revoked since 2014-12-31).

Jörg Frings-Fürst
D-54470 Lieser

Threema: SYR8SJXB
Wire: @joergfringsfuerst

IRC: j_...@freenode.net
 j_...@oftc.net

My wish list: 
 - Please send me a picture from the nature at your home.


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

Bug#861432: nmu: golang-go.crypto

[Ivo De Decker]

# cloning the bug, see below
clone 861432 -1
reassign -1 notary 0.1~ds1-1
retitle -1 notary: FTBFS with latest golang-go.crypto
severity -1 serious
clone 861432 -2
reassign -2 nomad 0.4.0+dfsg-1
retitle -2 nomad: FTBFS with latest golang-go.crypto
severity -2 serious
clone 861432 -3
reassign -3 packer 0.10.2+dfsg-4
retitle -3 packer: FTBFS with latest golang-go.crypto
severity -3 serious
clone 861432 -4
reassign -4 systemd-docker 0.2.1+dfsg-2
retitle -4 systemd-docker: FTBFS with latest golang-go.crypto
severity -4 serious
clone 861432 -5
reassign -5 docker-swarm 1.2.5+dfsg-2
retitle -5 docker-swarm: FTBFS with latest golang-go.crypto
severity -5 serious
clone 861432 -6
reassign -6 grafana 2.6.0+dfsg-3
retitle -6 grafana: FTBFS with latest golang-go.crypto
severity -6 serious
clone 861432 -7
reassign -7 docker.io 1.13.0~ds1-3
retitle -7 docker.io: FTBFS with latest golang-go.crypto
severity -7 serious
thanks

Hi,

On Fri, Apr 28, 2017 at 06:16:04PM -0500, Michael Lustfield wrote:
> Bug #859655 [3] has been fixed in unstable. This addresses a CVE bug, but also
> requires all reverse build dependencies be rebuilt. After this package has
> migrated to testing, there will be 62-64 packages that need rebuilding as 
> well.
> 
> I have run build tests in both unstable and testing for this update using an
> amd64 sbuild environment. For reference, the results:
> 
> testing:
>   success: 62,  failed: 2 (being addressed)
> unstable
>   success: 107, failed: 7 (unchecked)
> 
> 
> For the moment, I need the 107 packages in this list [1] to rebuilt in 
> unstable.
> ... wanna build? :)

[list of wb commands]

I scheduled the binNMUs. Please note that we currently cannot schedule binNMUs
for arch:all packages. So these are not rebuilt. The other ones should be ok
(with the exception of restic, but you already filed #861431 for that).

> [2] failed (not included above):

Thanks for testing all this.

> notary_0.1~ds1-1 (see buildlogs/notary_0.1~ds1-1)
> nomad_0.4.0+dfsg-1 (see buildlogs/nomad_0.4.0+dfsg-1)
> packer_0.10.2+dfsg-4 (see buildlogs/packer_0.10.2+dfsg-4)
> systemd-docker_0.2.1+dfsg-2 (see buildlogs/systemd-docker_0.2.1+dfsg-2)
> docker-swarm_1.2.5+dfsg-2 (see buildlogs/docker-swarm_1.2.5+dfsg-2)
> grafana_2.6.0+dfsg-3 (see buildlogs/grafana_2.6.0+dfsg-3)
> docker.io_1.13.0~ds1-3 (see buildlogs/docker.io_1.13.0~ds1-3)

I cloned this bug for each of them, to track the issue. It looks like only
packer is in testing. It doesn't seem to have any rdeps, so if it cannot be
fixed, we can just remove it. Obviously, a fix would be better :)

Cheers,

Ivo

Bug#858506: newer version of dns-root-data prevents dnsmasq from starting

[Thilo Six]

Hello

Kacper Berent schrieb/wrote:
> Package: dnsmasq
> Version: 2.76-5
> Followup-For: Bug #858506
> 
> Using awk seems to be more readable and it does not depend of whitespace
> 
> DNSMASQ_OPTS="$DNSMASQ_OPTS `awk -- '{ printf " 
> --trust-anchor=.,%d,%d,%d,%s", $5, $6, $7, $8 }' $ROOT_DS`"

Your patch does _not_ handle old style root.ds files.



kind regards,

 Thilo

Bug#750593: Stable update request: kernel changes to fix PIE with large stack

[Julien Cristau]

On Sat, Apr 22, 2017 at 21:42:30 +0100, Ben Hutchings wrote:

> On Sat, 2017-04-22 at 20:07 +, Niels Thykier wrote:
> [...]
> > Hi Ben,
> > 
> > Could you please file a pu bug for this?  I fear that otherwise, it
> > might be overlooked for the next time the SRMs review the outstanding
> > stable update requests.
> 
> I already stopped waiting and went ahead and made these changes.

Sorry for the lack of reply from SRM here.  And thanks for your work.

Cheers,
Julien

Bug#856263: git-buildpackage: Incorrect handling of --basepath in --git-pbuilder-options

[Russ Allbery]

Guido Günther  writes:

> Just for completeness: Russ, I've applied this patch to gbp. Would be
> nice if the version in gbp and the one shipped by you wouldn't diverge
> too much.

Applied, thank you!  Sorry about the long delay on this.

-- 
Russ Allbery (r...@debian.org)   

Bug#861432: closed by Ivo De Decker (Re: nmu: golang-go.crypto)

[Michael Lustfield]

On Sun, Apr 30, 2017 at 06:55:19PM +0200, Ivo De Decker wrote:
> I scheduled the binNMUs. Please note that we currently cannot schedule
binNMUs
> for arch:all packages. So these are not rebuilt. The other ones should be
ok

> (with the exception of restic, but you already filed #861431 for that).


Thanks! Thinking about it now, "all" was a mistake, for what are now
obvious reasons.

Bug#860393: Segfaults on startup

[Markus Koschany]

Control: tags -1 pending

On Mon, 17 Apr 2017 18:19:22 +0200 =?UTF-8?Q?Bernhard_=c3=9cbelacker?=
 wrote:
> Hello,
> just tried if I can reproduce the issue.
> 
> I think this is a again a case of a pointer truncation by default
> int for a pointer returning function.
> 
> 
> First patch is just to build with debug information to make the
> automatic dbgsym packages helpful.
> 
> The second patch adds some includes to get prototypes for alloc function.
> This is also warned about in the current amd64 build log:
> ../win/proxy/nhext.c:36:39: warning: implicit declaration of function 'alloc' 
> [-Wimplicit-function-declaration]
>  nhext_connection.in = (NhExtXdr *)alloc(sizeof(NhExtXdr));
>^
> 
> The third patch adds the prototype into a header file for 
> nh_option_get_boolopt.
> 
> With these applied at least the user interface can start without crashing.
> The build shows another 58 "warning: implicit declaration of function", that
> may crash later.
> 

Hi,

thank you again for your analysis and your patches. I think this issue
was already reported upstream seven years ago [1] but since upstream
development stopped a while ago we haven't seen an update yet. I'm sure
if you were able to address the remaining issue a lot of people would
appreciate it. Nevertheless thanks for the patches so far, the GTK
version appears to be usable again and I have just uploaded a new revision.

Regards,

Markus

[1] https://sourceforge.net/p/slashem/bugs/955/



signature.asc
Description: OpenPGP digital signature

Bug#861385: Acknowledgement (unblock (pre-approval): khal/1:0.8.4-4)

[Ivo De Decker]

Control: tags -1 confirmed moreinfo

Hi,

On Sat, Apr 29, 2017 at 03:24:57PM +0200, Filip Pytloun wrote:
> I see, didn't realized that epoch is not in file names. So new debdiff
> attached and retitling.

> diff -Nru khal-0.8.4/debian/changelog khal-0.8.4/debian/changelog
> --- khal-0.8.4/debian/changelog   2017-01-17 19:30:32.0 +0100
> +++ khal-0.8.4/debian/changelog   2017-04-28 10:28:13.0 +0200
> @@ -1,3 +1,28 @@
> +khal (1:0.8.4-4) unstable; urgency=medium
> +
> +  * Raise epoch to "revert" new upstream version in unstable and pass
> +stretch migration
> +
> + -- Filip Pytloun   Fri, 28 Apr 2017 10:28:13 +0200
> +
> +khal (0.9.5-2) unstable; urgency=medium
> +
> +  * d/copyright: mention presence of
> +0002-Reference-license-from-copyright-file.patch (Closes: #860984)
> +  * d/copyright: add upstream contact
> +  * d/copyright: update copyright year
> +
> + -- Filip Pytloun   Mon, 24 Apr 2017 09:45:57 +0200
> +
> +khal (0.9.5-1) unstable; urgency=medium
> +
> +  * New upstream release
> +  * d/patches: some TZ tests may fail due to Debian's python-tz of older
> +version but with newer TZ definitions, should be removed when 2017.2
> +reaches sid (Closes: #859472)
> +
> + -- Filip Pytloun   Thu, 20 Apr 2017 20:55:06 +0200
> +
>  khal (0.8.4-3) unstable; urgency=medium
>  

Please remove the changes of 0.9.5-1 and 0.9.5-2 from the changelog, as
1:0.8.4-4 doesn't contain these changes. With that change, feel free to upload
to unstable and remove the moreinfo tag from this bug once it's built on all
relevant architectures.

Cheers,

Ivo

Bug#861376: unblock: variety/0.6.3-4 (pre-upload approval)

[Ivo De Decker]

Control: tags -1 confirmed moreinfo

Hi,

On Thu, Apr 27, 2017 at 11:31:39PM -0700, James Lu wrote:
> Attached is a debdiff between 0.6.3-1 (currently in unstable) and 0.6.3-4,
> which I plan to release if this is okay.

Please go ahead with the upload and remove the moreinfo tag from this bug once
the package built on all the relevant architectures in unstable.

Cheers,

Ivo

Bug#860821: tudu: Crashes with segfault when adding deadline to item

[meskio]

Quoting Simon Heath (2017-04-20 17:54:57)
> Steps to reproduce:
> 
>  * Start "tudu"
>  * Hit "S" to edit the schedule for the default example item
>  * Hit "Enter" to save the default date
>  * Program crashes with a segfault.
> 
> Changing the date before saving it doesn't seem to change this behavior.
> This seems to crash no matter what item you are setting the date for.

I confirm I can reproduce it. I've opened an issue on tudu's bug tracker:
https://gitlab.com/tudu/tudu/issues/8

Sadly I being failing on having time for tudu for a long time, not sure if this 
will change soon. But I'll wellcome patches ;)

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


signature.asc
Description: signature

Bug#861553: Please enable numa support

[Laurent Bigonville]

Source: mariadb-10.1
Version: 10.1.22-4
Severity: wishlist

Hi,

Shouldn't mariadb be built with numa support?

I see that the mysql build in debian is doing so

Regards,

Laurent Bigonville

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

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

Bug#861554: Please enable numa support

[Laurent Bigonville]

Source: fio
Version: 2.16-1
Severity: wishlist

Hi,

Shouldn't fio be built with numa support?

libnuma is available on all linux architecture with the exception of
armhf and armel.

Regards,

Laurent Bigonville

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

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

Bug#861555: openbox: debian menu entry missing

[Jens Stimpfle]

Package: openbox
Version: 3.6.1-4

Dear Maintainer,

the openbox package in stretch does not include a menu file
(/usr/share/menu/openbox) anymore. There is a note in the package
changelog ("Drop menu file."), but no justification why the file was
dropped.

The version from jessie still works perfectly for me (switching between
various bare-bones window managers)

?package(openbox):needs="wm" section="Window Managers" \
  title="Openbox" command="/usr/bin/openbox" \
  icon="/usr/share/pixmaps/openbox.png"

All I did was change openbox.xpm to openbox.png to get a nice icon.

If there is still a reason why the menu file should no longer be
included then I at least hope this bug report will help other people
wondering why they can't live-switch to openbox.

Kind regards
Jens Stimpfle

Bug#861514: radicale: htpasswd authentication vulnerable to timing-based bruteforce attacks

[Salvatore Bonaccorso]

Hi

This issue has been assigned CVE-2017-8342 via the cveform at MITRE.

Regards,
Slavatore

Bug#819811: ITP: leiningen -- simple build system for Clojure

[Elana Hashman]

Owner: Elana Hashman 


Hi all,

Phil has done a bunch of great work significantly reducing the 
dependency profile of leiningen, so I have updated all the blocking 
issues and we are down to 8.


Of those, two are addressed by packages sitting in NEW and I will have 
more to follow. I wrote a (janky, alpha) tool to assist in Clojure 
packaging, for anyone that might be interested: 
https://github.com/ehashman/clj-helper


I just got added to the Debian Java and Debian Clojure packaging groups 
so I should be able to start working on some of the version upgrades as 
well.


ChangZhuo, I'm going to claim this bug since I haven't heard anything 
from you in the last few months :)


- e

Bug#861556: rhythmbox: Database not avaiable

[Symphonic]

Package: rhythmbox
Version: 3.1-1
Severity: important

Dear Maintainer,
I made a symlink from ~/.local/share/rhythmbox to a folder in another disk,
lather I changed the symlinks to another location and the problem start. When
rhythmbox starts it seem to can't see the database, it's all empty, and
furthermore it's not possible to play files in rhythmbox. The problem can be
resolved in a temp way by removing podcast-timestamp file in
~/.local/share/rhythmbox, then the program starts normally

Hope this will be fixed soon
Regards

(Please contact me at enigmaticalnig...@mail.com for news, the pgp key is
avaiable at pgp.mit.edu, keyserver.ubuntu.com and pool.sks.keyservers.net)

-- System Information:
Debian Release: 8.7
Architecture: amd64 (x86_64)

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

Versions of packages rhythmbox depends on:
ii  dbus1.8.22-0+deb8u1
ii  gnome-icon-theme3.12.0-1
ii  gstreamer1.0-plugins-base   1.4.4-2+deb8u1
ii  gstreamer1.0-plugins-good   1.4.4-2+deb8u3
ii  gstreamer1.0-x  1.4.4-2+deb8u1
ii  libatk1.0-0 2.14.0-1
ii  libc6   2.19-18+deb8u7
ii  libcairo-gobject2   1.14.0-2.1+deb8u2
ii  libcairo2   1.14.0-2.1+deb8u2
ii  libgdk-pixbuf2.0-0  2.31.1-2+deb8u5
ii  libgirepository-1.0-1   1.42.0-2.2
ii  libglib2.0-02.42.1-1+b1
ii  libgstreamer-plugins-base1.0-0  1.4.4-2+deb8u1
ii  libgstreamer1.0-0   1.4.4-2+deb8u1
ii  libgtk-3-0  3.14.5-1+deb8u1
ii  libgudev-1.0-0  215-17+deb8u6
ii  libjavascriptcoregtk-3.0-0  2.4.9-1~deb8u1
ii  libjson-glib-1.0-0  1.0.2-1
ii  libnotify4  0.7.6-2
ii  libpango-1.0-0  1.36.8-3
ii  libpangocairo-1.0-0 1.36.8-3
ii  libpeas-1.0-0   1.12.1-2
ii  librhythmbox-core8  3.1-1
ii  libsoup2.4-12.48.0-1
ii  libtdb1 1.3.6-0+deb8u1
ii  libtotem-plparser18 3.10.3-1
ii  libwebkitgtk-3.0-0  2.4.9-1~deb8u1
ii  libx11-62:1.6.2-3
ii  libxml2 2.9.1+dfsg1-5+deb8u4
ii  media-player-info   22-2
ii  rhythmbox-data  3.1-1
ii  zlib1g  1:1.2.8.dfsg-2+b1

Versions of packages rhythmbox recommends:
ii  avahi-daemon 0.6.31-5
ii  gstreamer1.0-plugins-ugly1.4.4-2+deb8u1
ii  gstreamer1.0-pulseaudio  1.4.4-2+deb8u3
ii  gvfs-backends1.22.2-1
ii  notification-daemon  0.7.6-2
ii  rhythmbox-plugins3.1-1
ii  xfce4-notifyd [notification-daemon]  0.2.4-3
ii  yelp 3.14.1-1

Versions of packages rhythmbox suggests:
pn  gnome-codec-install  
ii  gnome-control-center 1:3.14.2-3
ii  gstreamer1.0-plugins-bad 1.4.4-2.1+deb8u2
ii  rhythmbox-plugin-cdrecorder  3.1-1

Bug#859262: Re: freezes Orca screen reader

[Paul Gevers]

Hi Joanmarie,

On Sat, 29 Apr 2017 11:51:28 -0400 Joanmarie Diggs 
wrote:
> I've asked on the Orca list for testing, and we have enough users that
> use master and respond quite quickly to calls for testing, that we
> should know soon enough.

As you have seen, I already created a Debian package with your commits
included. Please find attached a debug log generated while running
Synaptic with this new Orca package (3.22.2 based) and verify that it
looks like intended now.

@all reading this bug, feedback is welcome.

Paul

P.S. I'll probably start working on getting Orca to produce sound on my
laptop soon, so that I can actually test what I am doing ;)


debug-2017-04-30-20:20:31.out.xz
Description: application/xz


signature.asc
Description: OpenPGP digital signature

Bug#856603: RFS: arc-theme/20170302-1

[Gianfranco Costamagna]

David,


> If something was not appropriate 2 months ago, it is even less so now...


please go for experimental and remove moreinfo when done.

G.

Bug#698012: debian-policy: Please update 10.6 "Device files" for udev and the like

[Russ Allbery]

Russ Allbery  writes:
> Andreas Henriksson  writes:

>> I don't think it's policys place to describe the actual implementation
>> details (which might change and we really don't care that much).
>> Instead only focus on if package maintainers needs to take special care
>> (like currently described in policy) or not (which is the actual truth).

>> Some parts of 10.6 might still be considered useful (but I wonder if
>> anyone would actually violate it even if it wasn't there these days,
>> after all policy can't describe every way to get things wrong so maybe
>> the entire chapter should still be considered for removal).

> I propose the following section to completely replace this section.  This
> preserves what I think are the still-useful requirements while making it
> clear that nearly all packages should keep their hands off of /dev
> entirely.  It also takes notice of device files outside of /dev, which are
> more like named pipes than regular device files and which packages may
> need to create for various jailing reasons (like creating a /dev/null
> inside your file system namespace).

> Comments, seconds?

This has now been applied for the next release.

-- 
Russ Allbery (r...@debian.org)