Bug#894095: Confirm upgrade breaks mouse preferences bug

[E Lux]

Package: xserver-xorg-input-libinput
Version: 0.27.0-1

Dear Maintainer,

I had this issue too. My mouse configuration is left-handed. After upgrade,
was automatically reconfigured right-handed. Y tried to come back to my
configuration via Mate Control Center and via dconf. Anything worked.

Downgrading to previous version solved the problem.

Kichdalto.

Bug#894595: function ​cr_sel_eng_get_matched_rulesets cause denial of service

[Jin Huang]

Package: libcroco3
Version: 0.6.12-2
Severity: normal

Dear Maintainer,

The
​​
cr_sel_eng_get_matched_rulesets() function in cr-sel-eng.c can cause a
denial of service (infinite loop) via a crafted CSS file.

In the while loop(line 1378) of funtion cr_sel_eng_get_matched_rulesets(),
cr_sel_eng_get_matched_rulesets_real() will always return
"CR_OUTPUT_TOO_SHORT_ERROR" when parsing a malformed file, leading the
while loop run infinitely.

cr_sel_eng_get_matched_rulesets_real() returns  array of the ruleset
statements that matches the
given xml node, it's prototype is as below:

static enum CRStatus
cr_sel_eng_get_matched_rulesets_real (CRSelEng * a_this,
  CRStyleSheet * a_stylesheet,
  xmlNode * a_node,
  CRStatement ** a_rulesets,
  gulong * a_len)

 *@param a_sel_eng the current selection engine
 *@param a_node the xml node for which the request
 *is being made.
 *@param a_sel_list the list of selectors to perform the search in.
 *@param a_rulesets in/out parameter. A pointer to the
 *returned array of rulesets statements that match the xml node
 *given in parameter. The caller allocates the array before calling this
 *function.
 *@param a_len in/out parameter the length (in sizeof (#CRStatement*))
 *of the returned array.
 *(the length of a_rulesets, more precisely).
 *The caller must set it to the length of a_ruleset prior to calling this
 *function. In return, the function sets it to the length
 *(in sizeof (#CRStatement)) of the actually returned CRStatement array.
 *@return CR_OUTPUT_TOO_SHORT_ERROR if found more rulesets than the size
 *of the a_rulesets array. In this case, the first *a_len rulesets found
 *are put in a_rulesets, and a further call will return the following
 *ruleset(s) following the same principle.
 *@return CR_OK if all the rulesets found have been returned. In this
 *case, *a_len is set to the actual number of ruleset found.
 *@return CR_BAD_PARAM_ERROR in case any of the given parameter are
 *bad (e.g null pointer).
 *@return CR_ERROR if any other error occurred.
 */

 CR_OUTPUT_TOO_SHORT_ERROR is returned if found more rulesets than the size
of the a_rulesets array. In this case, the first *a_len rulesets found are
put in a_rulesets, and a further call will return the following ruleset(s)
following the same principle.

 However, if more than *a_len rulesets found , in a further call, the
"a_this", "a_stylesheet" and "a_node" parameter will not change. Besides,
the *a_len will always be 8 (see below) in this fuction ,thus results in
another  CR_OUTPUT_TOO_SHORT_ERROR, make the while loop run infinitely.

*a_len not changed in every call:

1355gulong tab_size = 0,
1356tab_len = 0,
1357index = 0;
1358gushort stmts_chunck_size = 8;  //stmts_chunck_size is a fixed
value

...

1375tab_size = stmts_chunck_size;
1376tab_len = tab_size; //tab_size ,tab_len and
stmts_chunck_size are equal(value is 8)
1377
1378while ((status = cr_sel_eng_get_matched_rulesets_real
1379(a_this, a_sheet, a_node, stmts_tab + index, _len))
1380   == CR_OUTPUT_TOO_SHORT_ERROR) {
1381stmts_tab = g_try_realloc (stmts_tab,
1382   (tab_size +
stmts_chunck_size)
1383   * sizeof (CRStatement *));
1384if (!stmts_tab) {
1385cr_utils_trace_info ("Out of memory");
1386status = CR_ERROR;
1387goto error;
1388}
1389tab_size += stmts_chunck_size;// tab_size always
incresed by 8
1390index += tab_len;
// index's initial value is 0, the first time index
incresed by 8
1391tab_len = tab_size - index;
/* tab_len will be 8 the first time,and causing index
always incresed by 8,
so in every loop ,tab_len is always 8, which will
pass to cr_sel_eng_get_matched_rulesets_real() in the further call.
So, in fuction
cr_sel_eng_get_matched_rulesets_real, *a_len will not changed
and always be 8.
*/
1392}



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

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

Versions of packages libcroco3 depends on:
ii  libc6 2.24-11+deb9u3
ii  libglib2.0-0  2.50.3-2
ii  libxml2   2.9.4+dfsg1-2.2+deb9u2


--
 Jin Huang, ADLab of Venustech

Bug#894594: fix test errors, and please stop uploading binary packages without having the testsuite run

[Matthias Klose]

Package: src:meson
Version: 0.45.1-1
Severity: serious
Tags: sid buster patch

The java and cross tests fail. and I don't see how these could succeed in the
past.  This package is uploaded including the binary package, so the only
explanation I have is that the tests were disabled during these local builds.
Please don't do that, and do source only uploads instead so you can see what 
fails.

The attached patch fixes the test failures regarding the java and the cross 
tests.

  * Fix javac detection. This cannot have worked in any source only
upload.
  * Build-depend on g++-arm-linux-gnueabihf. The cross tests call
gcc/g++ explicitly.
  * Use default-jdk-headless instead of openjdk-8.

 
diff -Nru meson-0.45.1/debian/control meson-0.45.1/debian/control
--- meson-0.45.1/debian/control 2018-03-04 20:53:50.0 +0100
+++ meson-0.45.1/debian/control 2018-04-01 09:44:20.0 +0200
@@ -29,7 +29,7 @@
   protobuf-compiler ,
   libprotobuf-dev ,
 # OpenJDK does not work on Hurd, so skip the tests.
-  openjdk-8-jdk [!hurd-i386] ,
+  default-jdk-headless [!hurd-i386] ,
   valac ,
   gobject-introspection ,
   libgirepository1.0-dev ,
@@ -57,7 +57,7 @@
   itstool ,
   libgtk-3-dev ,
 # Not available on older releases and only needed for tests
-  c++-compiler-arm-linux-gnueabihf [!armhf]  | bash-doc ,
+  g++-arm-linux-gnueabihf [!armhf]  | bash-doc ,
   valgrind [amd64 i386] ,
   llvm-dev ,
   libsdl2-dev ,
diff -Nru meson-0.45.1/debian/patches/fix-javac-test.diff 
meson-0.45.1/debian/patches/fix-javac-test.diff
--- meson-0.45.1/debian/patches/fix-javac-test.diff 1970-01-01 
01:00:00.0 +0100
+++ meson-0.45.1/debian/patches/fix-javac-test.diff 2018-04-01 
09:43:52.0 +0200
@@ -0,0 +1,13 @@
+Index: b/mesonbuild/environment.py
+===
+--- a/mesonbuild/environment.py
 b/mesonbuild/environment.py
+@@ -661,7 +661,7 @@ class Environment:
+ except OSError:
+ raise EnvironmentException('Could not execute Java compiler "%s"' 
% ' '.join(exelist))
+ version = search_version(err)
+-if 'javac' in err:
++if 'javac' in out or 'javac' in err:
+ return JavaCompiler(exelist, version)
+ raise EnvironmentException('Unknown compiler "' + ' '.join(exelist) + 
'"')
+ 
diff -Nru meson-0.45.1/debian/patches/series meson-0.45.1/debian/patches/series
--- meson-0.45.1/debian/patches/series  2017-08-15 00:26:22.0 +0200
+++ meson-0.45.1/debian/patches/series  2018-04-01 09:44:20.0 +0200
@@ -1 +1,3 @@
 1-disable-openmpi.patch
+fix-javac-test.diff
+unversioned-armhf-cross.diff
diff -Nru meson-0.45.1/debian/patches/unversioned-armhf-cross.diff 
meson-0.45.1/debian/patches/unversioned-armhf-cross.diff
--- meson-0.45.1/debian/patches/unversioned-armhf-cross.diff1970-01-01 
01:00:00.0 +0100
+++ meson-0.45.1/debian/patches/unversioned-armhf-cross.diff2018-04-01 
09:44:20.0 +0200
@@ -0,0 +1,28 @@
+Index: b/cross/ubuntu-armhf.txt
+===
+--- a/cross/ubuntu-armhf.txt
 b/cross/ubuntu-armhf.txt
+@@ -1,8 +1,8 @@
+ [binaries]
+ # we could set exe_wrapper = qemu-arm-static but to test the case
+ # when cross compiled binaries can't be run we don't do that
+-c = '/usr/bin/arm-linux-gnueabihf-gcc-7'
+-cpp = '/usr/bin/arm-linux-gnueabihf-g++-7'
++c = '/usr/bin/arm-linux-gnueabihf-gcc'
++cpp = '/usr/bin/arm-linux-gnueabihf-g++'
+ rust = ['rustc', '--target', 'arm-unknown-linux-gnueabihf', '-C', 
'linker=/usr/bin/arm-linux-gnueabihf-gcc-7']
+ ar = '/usr/arm-linux-gnueabihf/bin/ar'
+ strip = '/usr/arm-linux-gnueabihf/bin/strip'
+Index: b/run_tests.py
+===
+--- a/run_tests.py
 b/run_tests.py
+@@ -131,7 +131,7 @@ def get_fake_options(prefix):
+ return opts
+ 
+ def should_run_linux_cross_tests():
+-return shutil.which('arm-linux-gnueabihf-gcc-7') and not 
platform.machine().lower().startswith('arm')
++return shutil.which('arm-linux-gnueabihf-gcc') and not 
platform.machine().lower().startswith('arm')
+ 
+ def run_configure_inprocess(meson_command, commandlist):
+ old_stdout = sys.stdout

Bug#876710: evince: File type DjVu image (image/vnd.djvu) is not supported

[Dingyuan Wang]

This bug still presents. It seems that nothing can identify multipage
.djvu files as "image/vnd.djvu+multipage" so evince can't open those
files now.

Bug#874498: [Pkg-protobuf-devel] Bug#874498: protobuf: Please package latest upstream version

[Andres Salomon]

On Sun, Apr 1, 2018 at 12:02 PM, László Böszörményi (GCS) 
 wrote:
On Sun, Apr 1, 2018 at 4:31 PM, Dmitry Smirnov  
wrote:
 On Saturday, 31 March 2018 7:12:03 PM AEST László Böszörményi 
(GCS) wrote:

  We are three here as I count. I do plan to update it, but I still
 have some time constraints.


 Sorry László, somehow I didn't think that you are still 
interested...

 Made a quick update[1], build and test it Andres if you may have
time. Beware, it may not work at all.


Thanks! I built and tested it with gplaycli; it worked perfectly. So +1 
from me.

That's just testing the python3 protobuf bindings, though.


[1] dget -x http://www.barcikacomp.hu/gcs/protobuf_3.5.2-1.dsc

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

[Matthias Klose]

On 31.03.2018 19:15, Boyuan Yang wrote:
> I saw missing packages provided w/o involving buildd network and the
> problem is solved. Closing this bug for now.

you are wrong. all builds have the build logs attached which means that these
were uploaded together with the binary packages.

Bug#894593: RFS: deepin-picker/1.6.2-1

[Yanhao Mo]

Package: sponsorship-requests
Severity: normal

Dear mentors,

I am looking for a sponsor for my package "deepin-picker"

* Package name: deepin-picker
  Version : 1.6.2-2
  Upstream Author : Deepin Technology Co., Ltd
* URL : https://github.com/linuxdeepin/deepin-picker
* License : GPL-3+
  Section : graphics

It builds those binary packages:

  deepin-picker - Color picker tool for deepin

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

https://mentors.debian.net/package/deepin-picker

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

  dget -x 
https://mentors.debian.net/debian/pool/main/d/deepin-picker/deepin-picker_1.6.2-2.dsc

More information about hello can be obtained from 
https://salsa.debian.org/pkg-deepin-team/deepin-picker

Changes since the last upload:

* d/control: add missing dependency dde-qt5integration since
deepin-picker cannot work correctly without it.

-- 
Yanhao Mo


signature.asc
Description: PGP signature

Bug#882006: redmine: "no_notification" option is not honored in mail_handler.rb

[duck]

Quack,

I had a look at your problem and the current code. I can see in 
`create_user_from_email` that the code is much different now (in 3.4.4):

  if handler_options[:no_notification]
user.mail_notification = 'none'
  end

So I think you problem is solved now.

Could you have a look at 3.4.4-1 (soon to be uploaded) and tell us if 
this is fine?


Regards.
\_o<

--
Marc Dequènes

Bug#894592: "Invalid SOS parameters for sequential JPEG" is recoverable

[martin f krafft]

Package: libjpeg-turbo-progs
Version: 1:1.5.2-2+b1
Severity: normal
File: /usr/bin/jpegtran

On certain files, jpegtran emits "Invalid SOS parameters for
sequential JPEG" and exits 1. This makes e.g. exifautotran fail,
while jpegtran still writes the transformed JPEG data to stdout.
ImageMagick treats this as a warning, and so should jpegtran, I'd
say.

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

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

Versions of packages libjpeg-turbo-progs depends on:
ii  libc62.27-2
ii  libjpeg62-turbo  1:1.5.2-2+b1
ii  libturbojpeg01:1.5.2-2+b1

libjpeg-turbo-progs recommends no packages.

libjpeg-turbo-progs suggests no packages.

-- debconf-show failed


-- 
 .''`.   martin f. krafft  @martinkrafft
: :'  :  proud Debian developer
`. `'`   http://people.debian.org/~madduck
  `-  Debian - when you have better things to do than fixing systems


digital_signature_gpg.asc
Description: Digital GPG signature (see http://martin-krafft.net/gpg/sig-policy/999bbcc4/current)

Bug#894591: ITP: golang-github-jedisct1-go-minisign -- Minisign library for Golang

[Eric Dorland]

Package: wnpp
Severity: wishlist
Owner: Eric Dorland 

* Package name: golang-github-jedisct1-go-minisign
  Version : 0.0~git20180113.f404c07-1
  Upstream Author : Frank Denis
* URL : https://github.com/jedisct1/go-minisign
* License : MIT
  Programming Lang: Go
  Description : Minisign library for Golang

 A Golang library to verify Minisign
 (https://jedisct1.github.io/minisign/) signatures.

Bug#894590: ITP: golang-github-jedisct1-go-clocksmith -- A sleep-aware-sleep() function

[Eric Dorland]

Package: wnpp
Severity: wishlist
Owner: Eric Dorland 

* Package name: golang-github-jedisct1-go-clocksmith
  Version : 0.0~git20180307.c35da9b-1
  Upstream Author : Frank Denis
* URL : https://github.com/jedisct1/go-clocksmith
* License : MIT
  Programming Lang: Go
  Description : sleep-aware-sleep() function for Go

 A sleep-aware sleep() function, that doesn't pause (for too
 long) if the system goes to hibernation.

Bug#894589: graphviz: Segmentation fault in feasible_tree() at at ns.c:516 in libgvc.so.6

[Boyuan Yang]

Control: notfound -1 2.38.0-17
Control: found -1 2.40.1-2

2018-04-02 8:46 GMT+08:00 Boyuan Yang <073p...@gmail.com>:
> Package: graphviz
> Version: 2.40.1-2
> Severity: important
>
> Dear Maintainer,
>
> I run "dot -Tsvg pkg-deepin-dep.today.dot" and got segfault.
>
> Reading symbols from /usr/bin/dot...Reading symbols from 
> /usr/lib/debug/.build-
> id/b2/d9312242d7e1e1734fd2e8a3555268ddbea8bf.debug...done.
> done.
> (gdb) set pagination off
> (gdb) r -Tsvg pkg-deepin-dep.today.dot
> Starting program: /usr/bin/dot -Tsvg pkg-deepin-dep.today.dot
> [Thread debugging using libthread_db enabled]
> Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
>
> Program received signal SIGSEGV, Segmentation fault.
> feasible_tree () at ns.c:516
> 516 ns.c: 没有那个文件或目录.
> (gdb) bt full
> #0  feasible_tree () at ns.c:516
> tree = 0x55964110
> i = 
> n = 
> subtree_count = 
> #1  rank2 (g=g@entry=0x5577ea40, balance=balance@entry=2,
> maxiter=2147483647, search_size=) at ns.c:821
> iter = 0
> ns = 0x77bb7b5e "network simplex: "
> f = 
> #2  0x77b88c64 in rank (g=g@entry=0x5577ea40,
> balance=balance@entry=2, maxiter=) at ns.c:870
> s = 
> search_size = 
> #3  0x71d15db5 in dot_position (g=g@entry=0x5577ea40,
> asp=asp@entry=0x0) at position.c:132
> __PRETTY_FUNCTION__ = "dot_position"
> #4  0x71d0e259 in dotLayout (g=g@entry=0x5577ea40) at 
> dotinit.c:326
> aspect = {targetAR = 3.9525251667299724e-323, combiAR =
> 9.8813129168249309e-324, prevIterations = -9280, curIterations = 32767,
> nextIter = 0, nPasses = -1335793544, badGraph = 0}
> asp = 0x0
> maxphase = -1
> #5  0x71d0eaa8 in doDot (g=0x5577ea40) at dotinit.c:463
> ccs = 
> sg = 
> i = 
> ncc = -1335793544
> pinfo = {aspect = 1.70365918e+13, sz = 0, margin = 8, doSplines = 0,
> mode = l_node, fixed = 0x0, vals = 0x0, flags = 0}
> Pack = -1
> mode = l_undef
> #6  dot_layout (g=0x5577ea40) at dotinit.c:509
> No locals.
> #7  0x77b5cdcb in gvLayoutJobs (gvc=, g=0x5577ea40)
> at gvlayout.c:85
> gvle = 0x71f27690 
> p = 
> rc = 
> #8  0x502f in main (argc=, argv=) at
> dot.c:134
> prev = 0x0
> r = 
> rc = 0
>
> The input file can be found at
> https://salsa.debian.org/pkg-deepin-team/progress-
> tracker/tree/02359e87d31274e3d314e91112c21b9260a883c8/depgraph
> (by running make -B) and I have attached an example file too.

Graphviz in Stretch is not affected, btw.

--
Regards,
Boyuan Yang

Bug#886041: Sugar GConf removal patches

[James Cameron]

G'day,

Upstream has landed patches for each of these bugs, and a patch for
src:python-sugar3 that doesn't have a bug yet.

for src:sugar #886040 cherry-pick from 38b173d ("jarabe, extensions -
remove GConf compatibility").

for src:sugar-browse-activity #886041 use v202 release, or cherry-pick
a7f2e19 ("Add Gio.Settings for home-page") and fadd3a3 ("Port from
GConf to Gio.Settings").

for src:sugar-read-activity #886042 cherry-pick 225983e ("Port from
GConf").

for src:sugar-write-activity #886042 cherry-pick 6bd08c5 ("Port from
GConf - font face and size) and 2663064 ("Port from GConf - speech
rate and pitch").

for src:python-sugar3 (NO BUG NUMBER) cherry-pick 30139a3
("sugar3.speech - remove GConf compatibility support").

My thanks to Rahul Bothra and Yash Agrawal (BCC'd) for review and
testing.

-- 
James Cameron
http://quozl.netrek.org/

Bug#861262: sphinxsearch needs systemd unit file

[Thomas Deutschmann]

Hi,

Debian still provides a generic fallback for sysvinit scripts for
packages not providing a systemd unit like sphinxsearch.
The problem is that this fallback isn't aware of anything else like
"stop" and "start", i.e. systemd will only call sphinxsearch's runscript
with either "start" or "stop" argument.

Due to that, the only lines/function using $DODTIME are never executed.

I would recommend the following fix:

> -  stop)
> -echo -n "Stopping $DESC: "
> -do_stop
> -echo "$NAME."
> -;;
> -  force-stop)
> +  stop|force-stop)
>echo -n "Forcefully stopping $DESC: "
>do_force_stop
>if ! running ; then

While this sounds dangerous (always "force-stop" instead of just "stop")
this shouldn't be a problem because "do_force_stop()" calls "kill -15"
at the beginning, i.e. the same thing "do_stop()" would do using
start-stop-daemon. The only difference is that "do_force_stop()" now
waits $DODTIME and _only_ if the service is still running it will be
forcefully killed (which should be safe at this stage or you should
increase $DODTIME if this doesn't fit your needs).


-- 
Regards,
Thomas

Bug#894589: graphviz: Segmentation fault in feasible_tree() at at ns.c:516 in libgvc.so.6

[Boyuan Yang]

Package: graphviz
Version: 2.40.1-2
Severity: important

Dear Maintainer,

I run "dot -Tsvg pkg-deepin-dep.today.dot" and got segfault.

Reading symbols from /usr/bin/dot...Reading symbols from /usr/lib/debug/.build-
id/b2/d9312242d7e1e1734fd2e8a3555268ddbea8bf.debug...done.
done.
(gdb) set pagination off
(gdb) r -Tsvg pkg-deepin-dep.today.dot
Starting program: /usr/bin/dot -Tsvg pkg-deepin-dep.today.dot
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".

Program received signal SIGSEGV, Segmentation fault.
feasible_tree () at ns.c:516
516 ns.c: 没有那个文件或目录.
(gdb) bt full
#0  feasible_tree () at ns.c:516
tree = 0x55964110
i = 
n = 
subtree_count = 
#1  rank2 (g=g@entry=0x5577ea40, balance=balance@entry=2,
maxiter=2147483647, search_size=) at ns.c:821
iter = 0
ns = 0x77bb7b5e "network simplex: "
f = 
#2  0x77b88c64 in rank (g=g@entry=0x5577ea40,
balance=balance@entry=2, maxiter=) at ns.c:870
s = 
search_size = 
#3  0x71d15db5 in dot_position (g=g@entry=0x5577ea40,
asp=asp@entry=0x0) at position.c:132
__PRETTY_FUNCTION__ = "dot_position"
#4  0x71d0e259 in dotLayout (g=g@entry=0x5577ea40) at dotinit.c:326
aspect = {targetAR = 3.9525251667299724e-323, combiAR =
9.8813129168249309e-324, prevIterations = -9280, curIterations = 32767,
nextIter = 0, nPasses = -1335793544, badGraph = 0}
asp = 0x0
maxphase = -1
#5  0x71d0eaa8 in doDot (g=0x5577ea40) at dotinit.c:463
ccs = 
sg = 
i = 
ncc = -1335793544
pinfo = {aspect = 1.70365918e+13, sz = 0, margin = 8, doSplines = 0,
mode = l_node, fixed = 0x0, vals = 0x0, flags = 0}
Pack = -1
mode = l_undef
#6  dot_layout (g=0x5577ea40) at dotinit.c:509
No locals.
#7  0x77b5cdcb in gvLayoutJobs (gvc=, g=0x5577ea40)
at gvlayout.c:85
gvle = 0x71f27690 
p = 
rc = 
#8  0x502f in main (argc=, argv=) at
dot.c:134
prev = 0x0
r = 
rc = 0

The input file can be found at
https://salsa.debian.org/pkg-deepin-team/progress-
tracker/tree/02359e87d31274e3d314e91112c21b9260a883c8/depgraph
(by running make -B) and I have attached an example file too.

--
Regards,
Boyuan Yang



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

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

Versions of packages graphviz depends on:
ii  libann0  1.1.2+doc-6
ii  libc62.27-3
ii  libcairo21.15.10-2
ii  libcdt5  2.40.1-2
ii  libcgraph6   2.40.1-2
ii  libexpat12.2.5-3
ii  libgcc1  1:8-20180331-1
ii  libgd3   2.2.5-4
ii  libglib2.0-0 2.56.0-4
ii  libgts-0.7-5 0.7.6+darcs121130-4
ii  libgvc6  2.40.1-2
ii  libgvpr2 2.40.1-2
ii  libice6  2:1.0.9-2
ii  liblab-gamut12.40.1-2
ii  libltdl7 2.4.6-2
ii  libpango-1.0-0   1.42.0-1
ii  libpangocairo-1.0-0  1.42.0-1
ii  libpathplan4 2.40.1-2
ii  libsm6   2:1.2.2-1+b3
ii  libstdc++6   8-20180331-1
ii  libx11-6 2:1.6.5-1
ii  libxaw7  2:1.0.13-1+b2
ii  libxdot4 2.40.1-2
ii  libxext6 2:1.3.3-1+b2
ii  libxmu6  2:1.1.2-2
ii  libxpm4  1:3.5.12-1
ii  libxt6   1:1.1.5-1
ii  zlib1g   1:1.2.8.dfsg-5

Versions of packages graphviz recommends:
ii  fonts-liberation  1:1.07.4-5

Versions of packages graphviz suggests:
pn  graphviz-doc  
ii  gsfonts   1:8.11+urwcyr1.0.7~pre44-4.4

-- no debconf information
digraph "deepin-dependency-list" {
/**
 *
 * PKG-DEEPIN TEAM
 *
 * pkg-deepin-de...@lists.alioth.debian.org
 * salsa.debian.org/pkg-deepin-team
 *
 * * * * * * * * * * * * * * * * * * * * * *
 *
 * ACCEPTED: green
 * NEW: magenta
 * RFS: deepskyblue
 * ITP: yellow
 *  non-ITP-blocked: grey
 * with-problem: red
 * deepin packages: square/octagon
 * non-deepin packages: diamond
 */

rankdir=LR;
node [style=filled];

subgraph "DeepinPackages" {
node [penwidth=4, shape=octagon];
"deepin-boot-maker" [color=yellow];
"deepin-calculator" [color=green];
"deepin-image-viewer" [color=green];
"deepin-terminal" [color=green];
"deepin-screenshot" [color=green];
"deepin-movie-reborn" [color=green];
"deepin-music" [color=grey];

Bug#883877: rsyslog: fails to configure, dpkg --configure exits with error

[Martin-Éric Racine]

This seems to have resolved itself over the past few days.

I have a strong suspicion that a dangling symbolic link in
/etc/alternatives to /etc/ld.so.conf.d/i386-linux-gnu_GL.conf was the
culprit. Doing 'sudo update-alternatives --all' removed it and that
solved a bunch of issues on that particular host.

That systemd would be sensitive to that dangling link however bothers
me. It doesn't bode too well for the distribution's stability, given
how systemd is meant to replace sysvinit and a growing list of other
essential components.

2018-04-02 1:24 GMT+03:00 Michael Biebl :
> On Wed, 17 Jan 2018 05:20:49 +0200 =?UTF-8?Q?Martin=2D=C3=89ric_Racine?=
>  wrote:
>> 2018-01-17 4:24 GMT+02:00 Michael Biebl :
>> > On Tue, 19 Dec 2017 06:55:34 +0100 Michael Biebl  wrote:
>> >> Am 19.12.2017 um 02:18 schrieb Martin-Éric Racine:
>> >> > 2017-12-19 2:02 GMT+02:00 Michael Biebl :
>> >> >> Am 18.12.2017 um 20:07 schrieb Martin-Éric Racine:
>> >> >>> 2017-12-18 2:08 GMT+02:00 Michael Biebl :
>> >>  Hi,
>> >> 
>> >>  I just uploaded v236 today. Before we try to debug this further, it
>> >>  would be great if you can give this version a try. Maybe your issue 
>> >>  is
>> >>  already fixed.
>> >>  If not, we'll have to involve upstream at some point by filing an
>> >>  upstream bug report. But let's first wait for your results with 236-1
>> >> >>>
>> >> >>> The issue is not fixed. Something fails at communicating with dbus,
>> >> >>> and it messes up everything else.
>> >> >>
>> >> >> Just to be sure, have you rebooted your system after upgrading to 
>> >> >> 236-1?
>> >> >
>> >> > Yes I have, but this required issuing "exec reboot -f" to bypass init
>> >> > entirely, otherwise it fails due to the lack of dbus connection.
>> >>
>> >> Sure, if PID 1 has crashed, it will freeze itself and no longer respond
>> >> to any (D-Bus) requests.
>> >>
>> >> When exactly does systemd crash? Is it immediately during boot or after
>> >> you've been using the system for a while?
>> >> I assume it works at least for a while, otherwise no other services
>> >> would be started and you would not be able to log in.
>> >> When systemd crashes, you should get an entry in the kernel log (dmesg)
>> >> respectively the journal.
>> >>
>> >> It would be great if you can follow the instructions at [1] to boot with
>> >> debug logging enabled and then provide a journal log which shows such a
>> >> crash.
>> >>
>> >
>> > Any updates on this?
>>
>> Not yet.  I just spent the last month or so giving interviews to the
>> media.  Will get back to this ASAP.
>>
>
> Ping
>
> --
> Why is it that all of the instruments seeking intelligent life in the
> universe are pointed away from Earth?
>

Bug#894588: apache2: "apache2ctl start" leads to severe errors in cgi scripts

[Bernd Gonsior]

Package: apache2
Version: 2.4.25-3+deb9u3
Severity: normal

Dear Maintainer,

"apache2ctl start" disables a perl cgi script to read the content of
/var/tmp, whereas "apache2ctl graceful" after "apache2ctl stop" (the
stop is necessary) does not.

There are other symptoms, probably related to bug 879571:

OK:
apache2 -h
Usage: apache2 [-D name] [-d directory] [-f file]
...

ERROR:
apache2 --help
[Sun Apr 01 23:58:25.445067 2018] [core:warn] [pid 2373] AH00111: Config 
variable ${APACHE_RUN_DIR} is not defined
apache2: Syntax error on line 80 of /etc/apache2/apache2.conf: 
DefaultRuntimeDir must be a valid directory, absolute or relative to ServerRoot

At my system following temporary workaround enabled proper working of
cgi scripts, the error of "apache2 --help" persisted:

Map the call of "apache2ctl start" to "apache2ctl graceful".

Modify /usr/sbin/apache2ctl like this:

1. add "start" to the "restart|graceful)" condition (originally in line 183):
start|restart|graceful)

2. delete the whole start condition (originally lines 151 - 178)

Then call:

1. apache2ctl stop
this "stop" is important - only an "apache2ctl graceful" is not sufficient

2. apache2ctl graceful


For testing that script was used:
--
#!/usr/bin/perl

use strict;
use warnings;

my $var = qx#/bin/ls -1 /var#;
my $var_tmp = qx#/bin/ls -1 /var/tmp#;

if (length($var_tmp) < 1) {
$var_tmp = "ERROR: failed to list /var/tmp\n";
}

my $body =
" var:\n" .
"$var\n" .
" var_tmp:\n" .
"$var_tmp";

my $len = length($body);

print
"Content-Length: $len\r\n" .
"Content-Type: text/plain\r\n" .
"\r\n" .
$body .
"\r\n";
--

output after
apache2ctl stop
apache2ctl start:
--
 var:
backups
cache
...
www

 var_tmp:
ERROR: failed to list /var/tmp
--

output after
apache2ctl stop
apache2ctl graceful:
--
 var:
backups
cache
...
www

 var_tmp:
systemd-private-1c3c5355c1234a4396389329c99a5a90-rtkit-daemon.service-xJby4F
systemd-private-1c3c5355c1234a4396389329c99a5a90-systemd-timesyncd.service-HCQsKU
--

Regards, Bernd


-- Package-specific info:

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

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

Versions of packages apache2 depends on:
ii  apache2-bin  2.4.25-3+deb9u3
ii  apache2-data 2.4.25-3+deb9u3
ii  apache2-utils2.4.25-3+deb9u3
ii  dpkg 1.18.24
ii  init-system-helpers  1.48
ii  lsb-base 9.20161125
ii  mime-support 3.60
ii  perl 5.24.1-3+deb9u2
ii  procps   2:3.3.12-3

Versions of packages apache2 recommends:
ii  ssl-cert  1.0.39

Versions of packages apache2 suggests:
pn  apache2-doc  
pn  apache2-suexec-pristine | apache2-suexec-custom  
ii  chromium [www-browser]   64.0.3282.119-1~deb9u1
ii  firefox-esr [www-browser]52.7.3esr-1~deb9u1
ii  w3m [www-browser]0.5.3-34+deb9u1

Versions of packages apache2-bin depends on:
ii  libapr1  1.5.2-5
ii  libaprutil1  1.5.4-3
ii  libaprutil1-dbd-sqlite3  1.5.4-3
ii  libaprutil1-ldap 1.5.4-3
ii  libc62.24-11+deb9u3
ii  libldap-2.4-22.4.44+dfsg-5+deb9u1
ii  liblua5.2-0  5.2.4-1.1+b2
ii  libnghttp2-141.18.1-1
ii  libpcre3 2:8.39-3
ii  libssl1.0.2  1.0.2l-2+deb9u3
ii  libxml2  2.9.4+dfsg1-2.2+deb9u2
ii  perl 5.24.1-3+deb9u2
ii  zlib1g   1:1.2.8.dfsg-5

Versions of packages apache2-bin suggests:
pn  apache2-doc  
pn  apache2-suexec-pristine | apache2-suexec-custom  
ii  chromium [www-browser]   64.0.3282.119-1~deb9u1
ii  firefox-esr [www-browser]52.7.3esr-1~deb9u1
ii  w3m [www-browser]0.5.3-34+deb9u1

Versions of packages apache2 is related to:
ii  apache2  2.4.25-3+deb9u3
ii  apache2-bin  2.4.25-3+deb9u3

-- no debconf information

Bug#891571: file not found for large /dtbs directory on ext4

[Vagrant Cascadian]

On 2018-02-26, Marc Haber wrote:
> the system in question is a Banana Pi, booting off an sd card. /boot is
> already on the SATA disk, and was an ext4 file system when the issue
> appeared.
>
> According to the availability of the ext4* commands, this u-boot should
> be able to handle an ext4fs, I therefore used it as /boot. This has
> worked until recently, when I installed the 4.15.6 kernel.

> The (now gone) ext4fs had the following attributes:
> Filesystem features:  has_journal ext_attr resize_inode dir_index 
> filetype needs_recovery extent 64bit flex_bg sparse_super large_file 
> huge_file dir_nlink extra_isize metadata_csum
>
> Is is possible that u-boot won't handle some of the advanced ext4
> features?

I believe most recent versions *should* support ext4, though there were
definitely bugs in older versions. It's possible some newer features now
enabled by default would trigger issues like this, of course.

I've been running numerous systems with ext4 for /boot for a while
now... are you sure you're running the current version of u-boot?  It
requires manual installation and upgrading; the package does not handle
this, see the instructions in /usr/share/doc/u-boot-sunxi/README.Debian*


live well,
  vagrant


signature.asc
Description: PGP signature

Bug#894587: kdepim-addons: File conflict with akonadi-contacts-data 4:17.08.3-2

[Boyuan Yang]

2018-04-02 8:16 GMT+08:00 Boyuan Yang <073p...@gmail.com>:
> Source: kdepim-addons
> Version: 17.12.3-1
> Severity: grave
> Justification: renders package unusable
>
> Preparing to unpack .../6-kdepim-addons_17.12.3-1_amd64.deb ...
> Unpacking kdepim-addons:amd64 (17.12.3-1) over (17.08.3-2) ...
> dpkg: error processing archive /tmp/apt-dpkg-install-zBVare/6-kdepim-
> addons_17.12.3-1_amd64.deb (--unpack):
>  trying to overwrite
> '/usr/share/contacteditor/grantleetheme/default/addresseslocation.css', which
> is also in package akonadi-contacts-data 4:17.08.3-2
> dpkg-deb: error: paste subprocess was killed by signal (Broken pipe)
> Errors were encountered while processing:
>  /tmp/apt-dpkg-install-zBVare/6-kdepim-addons_17.12.3-1_amd64.deb

After enabling "--force-overwrite", the output is as follows:

Preparing to unpack .../kdepim-addons_17.12.3-1_amd64.deb ...
Unpacking kdepim-addons:amd64 (17.12.3-1) over (17.08.3-2) ...
dpkg: warning: overriding problem because --force enabled:
dpkg: warning: trying to overwrite
'/usr/share/contacteditor/grantleetheme/default/addresseslocation.css',
which is also in package akonadi-contacts-data 4:17.08.3-2
dpkg: warning: overriding problem because --force enabled:
dpkg: warning: trying to overwrite
'/usr/share/contacteditor/grantleetheme/default/addresseslocation.html',
which is also in package akonadi-contacts-data 4:17.08.3-2

--
Regards,
Boyuan Yang

Bug#894587: kdepim-addons: File conflict with akonadi-contacts-data 4:17.08.3-2

[Boyuan Yang]

Source: kdepim-addons
Version: 17.12.3-1
Severity: grave
Justification: renders package unusable

Preparing to unpack .../6-kdepim-addons_17.12.3-1_amd64.deb ...
Unpacking kdepim-addons:amd64 (17.12.3-1) over (17.08.3-2) ...
dpkg: error processing archive /tmp/apt-dpkg-install-zBVare/6-kdepim-
addons_17.12.3-1_amd64.deb (--unpack):
 trying to overwrite
'/usr/share/contacteditor/grantleetheme/default/addresseslocation.css', which
is also in package akonadi-contacts-data 4:17.08.3-2
dpkg-deb: error: paste subprocess was killed by signal (Broken pipe)
Errors were encountered while processing:
 /tmp/apt-dpkg-install-zBVare/6-kdepim-addons_17.12.3-1_amd64.deb



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

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

-- no debconf information

Bug#894586: reprepro: VerifyRelease doesn't support full keyid

[Vagrant Cascadian]

Package: reprepro
Version: 5.1.1-1
Severity: normal

Many thanks for reprepro; I use it extensively!

In order to use VerifyRelease, reprepro at least requires using the long
keyid, which are more secure against collision attacks that the short
ids (e.g. https://evil32.com), but not nearly as secure as the full
fingerprint.

Using the full key fingerprint should at least be allowed for
VerifyRelease:

  Name: debian-ports
  VerifyRelease: 
58E64B9BB11BC112205DBCDB06AED62430CB581C|66571731B5A71F91C501F3FDDA1B2CEA81DCBC61
  Method: http://deb.debian.org/debian-ports

  Error: not a valid key id '58E64B9BB11BC112205DBCDB06AED62430CB581C'!
  Use hex-igits from the end of the key as identifier
  There have been errors!


Using the corresponding long keyids works fine, of course.


live well,
  vagrant


-- System Information:
Debian Release: 9.4
  APT prefers stable
  APT policy: (500, 'stable'), (210, 'proposed-updates'), (120, 'unstable'), 
(1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: armhf, arm64

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

Versions of packages reprepro depends on:
ii  libarchive13   3.2.2-2
ii  libbz2-1.0 1.0.6-8.1
ii  libc6  2.24-11+deb9u3
ii  libdb5.3   5.3.28-12+deb9u1
ii  libgpg-error0  1.26-2
ii  libgpgme11 1.8.0-3+b2
ii  liblzma5   5.2.2-1.2+b1
ii  zlib1g 1:1.2.8.dfsg-5

Versions of packages reprepro recommends:
ii  apt  1.4.8

Versions of packages reprepro suggests:
ii  gnupg-agent  2.1.18-8~deb9u1
pn  inoticoming  
pn  lzip 
ii  pinentry-curses  1.0.0-2

-- no debconf information


signature.asc
Description: PGP signature

Bug#894585: ITP: golang-github-jedisct1-dlog -- A super simple logger for Go. Supports stderr, logfiles, syslog and windows event log.

[Eric Dorland]

Package: wnpp
Severity: wishlist
Owner: Eric Dorland 

* Package name: golang-github-jedisct1-dlog
  Version : 0.3+git20180206.52c32ac-1
  Upstream Author : Frank Denis
* URL : https://github.com/jedisct1/dlog
* License : BSD-2-clause
  Programming Lang: Go
  Description : A super simple logger for Go

 Go's standard logger is fairly limited. As result, kazilion alternatives
 loggers have been written.
 .
 All of these are wonderful. They can make your logs look colorful and
 pretty, buffer things in complicated ways, format data for ElasticSearch,
 and more.
 .
 Cool, but all I wanted is something super dumb, that just exposes
 log.Info(), log.Error() and a couple other standard levels.
 .
 I don't need a super flexible kitchen sink. Just something super basic
 and trivial to use. I just want it to handle different log levels, and
 be able to write simple logs to stderr, to a local file, to syslog and
 to the Windows event log.
 .
 So, here's one more logging library for Go. The dumbest of them
 all. Enjoy.

Bug#887470: slixmpp: please package new version 1.3.0

[W. Martin Borgert]

Note, that the current poezio git master needs a newer slixmpp,
i.e. also the git master, not 1.3.0.

Bug#894584: RM: jta -- ROM; Obsolete, no longer used, FTBFS with Java 9

[Emmanuel Bourg]

Package: ftp.debian.org
Severity: normal

Hi,

Please remove the jta package, this is a SSH applet that is no longer
used, applet support has been removed from browsers lately, and the
package now fails to build with Java 9.

Thank you,

Emmanuel Bourg

Bug#894581: RM: scidavis/1:1.22-1

[Adam D. Barratt]

Control: reassign -1 ftp.debian.org

On Sun, 2018-04-01 at 23:29 +0200, Georges Khaznadar wrote:
> Scidavis hardly relies on Qt4 and its Qt3 compatibility facilities.
> It still uses an obsolete version of Qwt and QwtPlot.
> 
> I tried to fork the latest upstream source and begin to migrate
> code from Qt4 to Qt5, but the task appears as quite difficult,
> since many obsolete Qt3 structures are still in use, and that quite
> a lot of Qwt structures are now unsupported with the recent qwt
> release (the
> only compatible with Qt5).
> 
> As messages asking for an update at upstream level got no reply
> during the
> last three months, and that no git branch was opened recently to
> address
> this issue in the upstream repository, I suspect that Scidavis will
> never be ported to Qt5 by upstream developers.
> 
> So, I ask for the removal of the package Scidavis from both Testing
> and
> Unstable distributions, as I do not consider to make this migration.
> 

Then you need to be requesting removal from unstable, which is the FTP
Team's area; reassigning.

Regards,

Adam

Bug#830230: systemd disable wake-on-lan

[Michael Biebl]

On Tue, 19 Jul 2016 17:39:40 +0200 Norbert Schulz
 wrote:
> 
> 
> Christian Hofstaedtler schrieb:
> > * Norbert Schulz  [160718 09:24]:
> >> Here are the required and some more information.
> > 
> > Thanks for following up on this. Unfortunately, I have no idea
> > either on what is happening here.
> > 
> Is there any possibility to get some output if I send a wake-on-lan packet 
> (with
> etherwake) to the ethernet card when the system is running?
> 

Is this still reproducible with an up-to-date stretch or sid system?

-- 
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#894342: transition: kdepim

[Sandro Knauß]

Hey,

Thanks a lot!

> BTW I had to fix all your commands because of the bad versions... Next time
> try to get them right, or don't specify the version at all (it's optional).

sorry - I do not have written a lot of them. But I thought I need to specify a 
version, as in the docu[1] it is not mentioned as optional. Btw. is there a 
tool to help writing them and check those cmds?

hefee

[1] https://release.debian.org/wanna-build.txt



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

Bug#894342: transition: kdepim

[Emilio Pozuelo Monfort]

On 02/04/18 00:39, Emilio Pozuelo Monfort wrote:
> On 01/04/18 16:14, Sandro Knauß wrote:
>> Hey,
>>
>> after uploading kdepim, the buildds had built KDE Pim 17.12.3 successfully 
>> for amd64 and i386 (other archs are still building).
>>
>> Now we needs some binNMUs. I don't know, do I need to use a separate bug for 
>> those requests or is it the correct way to file the wb actions just here 
>> inside the transition bug?
>>
>> KGPG need to recompiled too as Akonadi has/had some issues with building on 
>> many archs (because of the dep to python). So KGPG got compiled against the 
>> old kdepim 17.08, just amd64 and armel were fast enough. Still archs do not 
>> built kdepim completely, so the BD are not available on the archs yet, so 
>> you may want to set dep-wait for those packages.
>>
>>   nmu kgpg_17.12.3-1 . ANY -amd64 -armel . -m 'rebuilt against kdepim 
>> 17.12.3'
>>   dw kgpg_17.12.3-1 . ANY -amd64 -armel . -m 'libkf5akonadicontact-dev (>= 
>> 4:17.12.3~)'
>>
>> and kjots and zanshin needs to get rebuilt. As those are not inside kdepim, 
>> they needs to get rebuilt on any architecture. 
>>
>>  nmu kjots_5.0.2-1 . ANY . -m 'rebuilt against kdepim 17.12.3'
>>  dw kjots_5.0.2-1 . ANY . -m 'libkf5akonadinotes-dev (>= 4:17.12.3~), 
>> libkf5kontactinterface-dev (>= 17.12.3~)'
>>  nmu zanshin_5.0-1 . ANY . -m 'rebuilt against kdepim 17.12.3'
>>  dw zanshin_5.0.-1 . ANY . -m 'libkf5akonadicalendar-dev (>= 4:17.12.3~)'
> 
> Scheduled.

BTW I had to fix all your commands because of the bad versions... Next time try
to get them right, or don't specify the version at all (it's optional).

Emilio

Bug#894342: transition: kdepim

[Emilio Pozuelo Monfort]

On 01/04/18 16:14, Sandro Knauß wrote:
> Hey,
> 
> after uploading kdepim, the buildds had built KDE Pim 17.12.3 successfully 
> for amd64 and i386 (other archs are still building).
> 
> Now we needs some binNMUs. I don't know, do I need to use a separate bug for 
> those requests or is it the correct way to file the wb actions just here 
> inside the transition bug?
> 
> KGPG need to recompiled too as Akonadi has/had some issues with building on 
> many archs (because of the dep to python). So KGPG got compiled against the 
> old kdepim 17.08, just amd64 and armel were fast enough. Still archs do not 
> built kdepim completely, so the BD are not available on the archs yet, so you 
> may want to set dep-wait for those packages.
> 
>   nmu kgpg_17.12.3-1 . ANY -amd64 -armel . -m 'rebuilt against kdepim 17.12.3'
>   dw kgpg_17.12.3-1 . ANY -amd64 -armel . -m 'libkf5akonadicontact-dev (>= 
> 4:17.12.3~)'
> 
> and kjots and zanshin needs to get rebuilt. As those are not inside kdepim, 
> they needs to get rebuilt on any architecture. 
> 
>  nmu kjots_5.0.2-1 . ANY . -m 'rebuilt against kdepim 17.12.3'
>  dw kjots_5.0.2-1 . ANY . -m 'libkf5akonadinotes-dev (>= 4:17.12.3~), 
> libkf5kontactinterface-dev (>= 17.12.3~)'
>  nmu zanshin_5.0-1 . ANY . -m 'rebuilt against kdepim 17.12.3'
>  dw zanshin_5.0.-1 . ANY . -m 'libkf5akonadicalendar-dev (>= 4:17.12.3~)'

Scheduled.

Emilio

Bug#894560: pygame: Don't drop python2 package

[Jeremy Bicha]

On Sun, Apr 1, 2018 at 6:12 PM, Dominik George  wrote:
> I do not target for testing - I target for buster and for sid.  Neither
> pygame nor its dependencies, using Python 2, will survive the buster release
> cycle, so there is no point in forcefully keeping it around in testing.  And
> as you said: Non of this will transition until the problem is solved (either
> by removal of the dependencies or their switch to Python 3).

Are you aware that python2 will still be included in Debian Buster?

Thanks,
Jeremy Bicha

Bug#883877: rsyslog: fails to configure, dpkg --configure exits with error

[Michael Biebl]

On Wed, 17 Jan 2018 05:20:49 +0200 =?UTF-8?Q?Martin=2D=C3=89ric_Racine?=
 wrote:
> 2018-01-17 4:24 GMT+02:00 Michael Biebl :
> > On Tue, 19 Dec 2017 06:55:34 +0100 Michael Biebl  wrote:
> >> Am 19.12.2017 um 02:18 schrieb Martin-Éric Racine:
> >> > 2017-12-19 2:02 GMT+02:00 Michael Biebl :
> >> >> Am 18.12.2017 um 20:07 schrieb Martin-Éric Racine:
> >> >>> 2017-12-18 2:08 GMT+02:00 Michael Biebl :
> >>  Hi,
> >> 
> >>  I just uploaded v236 today. Before we try to debug this further, it
> >>  would be great if you can give this version a try. Maybe your issue is
> >>  already fixed.
> >>  If not, we'll have to involve upstream at some point by filing an
> >>  upstream bug report. But let's first wait for your results with 236-1
> >> >>>
> >> >>> The issue is not fixed. Something fails at communicating with dbus,
> >> >>> and it messes up everything else.
> >> >>
> >> >> Just to be sure, have you rebooted your system after upgrading to 236-1?
> >> >
> >> > Yes I have, but this required issuing "exec reboot -f" to bypass init
> >> > entirely, otherwise it fails due to the lack of dbus connection.
> >>
> >> Sure, if PID 1 has crashed, it will freeze itself and no longer respond
> >> to any (D-Bus) requests.
> >>
> >> When exactly does systemd crash? Is it immediately during boot or after
> >> you've been using the system for a while?
> >> I assume it works at least for a while, otherwise no other services
> >> would be started and you would not be able to log in.
> >> When systemd crashes, you should get an entry in the kernel log (dmesg)
> >> respectively the journal.
> >>
> >> It would be great if you can follow the instructions at [1] to boot with
> >> debug logging enabled and then provide a journal log which shows such a
> >> crash.
> >>
> >
> > Any updates on this?
> 
> Not yet.  I just spent the last month or so giving interviews to the
> media.  Will get back to this ASAP.
> 

Ping

-- 
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#894495: mandos-client: Mandos client fails while booting but works from chroot into unpacked initramfs

[Teddy Hogeborn]

Michel Bouissou  writes:

> After a more thourough dive in GPGME logs, it is now crystal clear to
> me that the matter is that GPG is unable to import the key data that
> GPGME tries to feed into it at key import time.
>
> Here is the result of the GPG secret key import (working) inside the
> chroot :
>
> [GNUPG:] KEY_CONSIDERED .
> [GNUPG:] IMPORTED .
> [GNUPG:] IMPORT_OK 1 .
> [GNUPG:] IMPORT_RES 1 0 1 0 0 0 0 0 0 1 1 0 0 0 0
>
> - Count : 1
> - Imported : 1
> - Sec Read : 1
> - Sec Imported : 1
>
> And now the failing one from initramfs :
>
> [GNUPG:] IMPORT_RES 1 1 0 0 0 0 0 0 0 1 0 0 0 0 0.
>
> - Count : 1
> - No_User_ID : 1
> - Imported : 0
> - Sec Read : 1
> - Sec Imported : 0
>
> IMPORT_RES 
>  
>   
>
> However it further seems to properly receive the encrypted data, but
> is unable to decrypt it because it has no keys.
>
> I have no clue about why, and what the difference can be, but I need a
> break for now as I have spent my entire sunday wrestling with this :-\

I've added, to the latest revision of mandos-client.c in trunk, an
additional check for errors in the GPGME key importing code, and lots of
code for outputting whatever GPGME says went wrong.  Latest revision of
mandos-client.c, and a bare diff with just this change, are attached.

This should hopefully show what GPGME thinks is the problem.  Whatever
it is, it can't be a problem reading the key files, because we can
import them into GnuTLS just fine.  It must, I think, be some problem
with writing or locking the GPGME keyring files, which is why I'm still
leaing towards the unwriteable /tmp problem, or something very much like
it.

/Teddy Hogeborn

-- 
The Mandos Project
https://www.recompile.se/mandos
/*  -*- coding: utf-8 -*- */
/*
 * Mandos-client - get and decrypt data from a Mandos server
 *
 * This program is partly derived from an example program for an Avahi
 * service browser, downloaded from
 * .  This
 * includes the following functions: "resolve_callback",
 * "browse_callback", and parts of "main".
 * 
 * Everything else is
 * Copyright © 2008-2018 Teddy Hogeborn
 * Copyright © 2008-2018 Björn Påhlsson
 * 
 * This file is part of Mandos.
 * 
 * Mandos is free software: you can redistribute it and/or modify it
 * under the terms of the GNU General Public License as published by
 * the Free Software Foundation, either version 3 of the License, or
 * (at your option) any later version.
 * 
 * Mandos 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 General Public License
 * along with Mandos.  If not, see .
 * 
 * Contact the authors at .
 */

/* Needed by GPGME, specifically gpgme_data_seek() */
#ifndef _LARGEFILE_SOURCE
#define _LARGEFILE_SOURCE
#endif	/* not _LARGEFILE_SOURCE */
#ifndef _FILE_OFFSET_BITS
#define _FILE_OFFSET_BITS 64
#endif	/* not _FILE_OFFSET_BITS */

#define _GNU_SOURCE		/* TEMP_FAILURE_RETRY(), asprintf() */

#include 		/* fprintf(), stderr, fwrite(),
   stdout, ferror() */
#include  		/* uint16_t, uint32_t, intptr_t */
#include 		/* NULL, size_t, ssize_t */
#include  		/* free(), EXIT_SUCCESS, srand(),
   strtof(), abort() */
#include 		/* bool, false, true */
#include 		/* strcmp(), strlen(), strerror(),
   asprintf(), strncpy(), strsignal()
*/
#include 		/* ioctl */
#include 		/* socket(), inet_pton(), sockaddr,
   sockaddr_in6, PF_INET6,
   SOCK_STREAM, uid_t, gid_t, open(),
   opendir(), DIR */
#include 		/* open(), S_ISREG */
#include 		/* socket(), struct sockaddr_in6,
   inet_pton(), connect(),
   getnameinfo() */
#include 		/* open(), unlinkat(), AT_REMOVEDIR */
#include 		/* opendir(), struct dirent, readdir()
 */
#include 		/* PRIu16, PRIdMAX, intmax_t,
   strtoimax() */
#include 		/* perror(), errno, EINTR, EINVAL,
   EAI_SYSTEM, ENETUNREACH,
   EHOSTUNREACH, ECONNREFUSED, EPROTO,
   EIO, ENOENT, ENXIO, ENOMEM, EISDIR,
   ENOTEMPTY,
   program_invocation_short_name */
#include 		/* nanosleep(), time(), sleep() */
#include 		/* ioctl, ifreq, SIOCGIFFLAGS, IFF_UP,
   SIOCSIFFLAGS, if_indextoname(),
   if_nametoindex(), IF_NAMESIZE */
#include 		/* IN6_IS_ADDR_LINKLOCAL,
   INET_ADDRSTRLEN, INET6_ADDRSTRLEN
*/
#include 		/* close(), SEEK_SET, off_t, write(),
   getuid(), getgid(), seteuid(),
   setgid(), pause(), _exit(),
   unlinkat() */
#include 		/* inet_pton(), htons() */
#include 		/* not, or, and */
#include 		/* struct argp_option, error_t, struct
   argp_state, struct argp,
   argp_parse(), ARGP_KEY_ARG,
   ARGP_KEY_END, ARGP_ERR_UNKNOWN */
#include 		/* sigemptyset(), sigaddset(),
   sigaction(), SIGTERM, 

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

[Dominik George]

Hi,

On Sun, Apr 01, 2018 at 10:45:10PM +0200, Andreas Beckmann wrote:
> On Sat, 31 Mar 2018 20:53:05 +0200 Dominik George
>  wrote:
> > Files in second .deb but not in first
> > -
> > -rw-r--r--  root/root   /lib/security/pam_krb5_migrate_mit.so
> 
> > Files in first .deb but not in second
> > -
> > -rw-r--r--  root/root   
> > /lib/security/pam_krb5_migrate_mit.so/pam_krb5_migrate_mit.so
> 
> Does dpkg gracefully handle directory->file transitions?
> I know it intentionally doesn't do symlink<->directory transitions ...

Well, at least I successfully upgraded from the package in stretch to my new
version ☺.

-nik



signature.asc
Description: PGP signature

Bug#894560: pygame: Don't drop python2 package

[Dominik George]

Hi,

> Your latest upload drops the python-pygame pacakge but I count 35
> packages in Debian Testing that depend on it. Please restore the
> python-pygame package until all those packages no longer depend on it.
> 
> Even without a bug being filed, I believe the broken dependency issue
> would have prevented this package from migrating to Testing.

So, what's the use of that?

I do not target for testing - I target for buster and for sid.  Neither
pygame nor its dependencies, using Python 2, will survive the buster release
cycle, so there is no point in forcefully keeping it around in testing.  And
as you said: Non of this will transition until the problem is solved (either
by removal of the dependencies or their switch to Python 3).

All that will happen with and without the Python 2 version of Pygame.

-nik


signature.asc
Description: PGP signature

Bug#894582: gnome-shell: Dynamic workspace setting not honoured at startup

[Peter Denison]

Package: gnome-shell
Version: 3.28.0-1+b1
Severity: normal

Dear Maintainer,

When the settings are for dynamic workspaces, the shell starts up with 
only two workspaces and does not behave as per the dynamic workspace setting

If the setting is changed (using gnome-tweaks) to static workspaces and 
then back to dynamic workspaces, the dynamic workspaces behave as 
expected


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

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

Versions of packages gnome-shell depends on:
ii  dconf-gsettings-backend [gsettings-backend]  0.26.1-3
ii  evolution-data-server3.28.0-2
ii  gir1.2-accountsservice-1.0   0.6.45-1
ii  gir1.2-atspi-2.0 2.28.0-1
ii  gir1.2-freedesktop   1.56.0-2
ii  gir1.2-gcr-3 3.28.0-1
ii  gir1.2-gdesktopenums-3.0 3.28.0-1
ii  gir1.2-gdm-1.0   3.28.0-1
ii  gir1.2-geoclue-2.0   2.4.7-1
ii  gir1.2-glib-2.0  1.56.0-2
ii  gir1.2-gnomebluetooth-1.03.28.0-2
ii  gir1.2-gnomedesktop-3.0  3.28.0-1
ii  gir1.2-gtk-3.0   3.22.29-2
ii  gir1.2-gweather-3.0  3.28.1-1
ii  gir1.2-ibus-1.0  1.5.17-3
ii  gir1.2-mutter-2  3.28.0-2
ii  gir1.2-nm-1.01.10.6-2
ii  gir1.2-nma-1.0   1.8.10-2
ii  gir1.2-pango-1.0 1.42.0-1
ii  gir1.2-polkit-1.00.105-18
ii  gir1.2-rsvg-2.0  2.40.20-2
ii  gir1.2-soup-2.4  2.62.0-1
ii  gir1.2-upowerglib-1.00.99.7-2
ii  gjs  1.52.0-2
ii  gnome-backgrounds3.28.0-1
ii  gnome-settings-daemon3.28.0-1
ii  gnome-shell-common   3.28.0-1
ii  gsettings-desktop-schemas3.28.0-1
ii  libatk-bridge2.0-0   2.26.2-1
ii  libatk1.0-0  2.28.1-1
ii  libc62.27-2
ii  libcairo21.15.10-1
ii  libcanberra-gtk3-0   0.30-6
ii  libcanberra0 0.30-6
ii  libcroco30.6.12-2
ii  libecal-1.2-19   3.28.0-2
ii  libedataserver-1.2-233.28.0-2
ii  libgcr-base-3-1  3.28.0-1
ii  libgdk-pixbuf2.0-0   2.36.11-2
ii  libgirepository-1.0-11.56.0-2
ii  libgjs0g [libgjs0-libmozjs-52-0] 1.52.0-2
ii  libglib2.0-0 2.56.0-4
ii  libglib2.0-bin   2.56.0-4
ii  libgstreamer1.0-01.14.0-1
ii  libgtk-3-0   3.22.29-2
ii  libical3 3.0.1-5
ii  libjson-glib-1.0-0   1.4.2-3
ii  libmutter-2-03.28.0-2
ii  libnm0   1.10.6-2
ii  libpango-1.0-0   1.42.0-1
ii  libpangocairo-1.0-0  1.42.0-1
ii  libpolkit-agent-1-0  0.105-18
ii  libpolkit-gobject-1-00.105-18
ii  libpulse-mainloop-glib0  11.1-4
ii  libpulse011.1-4
ii  libsecret-1-00.18.5-6
ii  libstartup-notification0 0.12-5
ii  libsystemd0  238-3
ii  libx11-6 2:1.6.5-1
ii  libxfixes3   1:5.0.3-1
ii  mutter   3.28.0-2
ii  python3  3.6.4-1

Versions of packages gnome-shell recommends:
ii  chrome-gnome-shell9-1
ii  gdm3  3.28.0-1
ii  gkbd-capplet  3.26.0-3
ii  gnome-control-center  1:3.28.0-1
ii  gnome-user-docs   3.28.0-1
ii  iio-sensor-proxy  2.4-2
ii  switcheroo-control1.2-1
ii  unzip 6.0-21

Versions of packages gnome-shell suggests:
ii  gir1.2-telepathyglib-0.12   0.24.1-2
ii  gir1.2-telepathylogger-0.2  0.8.2-3

-- no debconf information

Bug#873329: Any news?

[Elena ``of Valhalla'']

I've seen that love has been autoremoved from testing because of this
bug, which seems to be fixed in the next upstream version.

Are there news on its packaging? is it still waiting for a review of the
copyright file or was there some blocking issues found?

I'm not interested in maintaining this package, but maybe I could give
some one-off help

-- 
Elena ``of Valhalla''

Bug#883987: boost1.62: FTBFS error: partial specialization ... after instantiation ... (with patch)

[Andreas Beckmann]

apparently this is reproducible in stretch:

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=893006#17

Bug#894581: RM: scidavis/1:1.22-1

[Georges Khaznadar]

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

Scidavis hardly relies on Qt4 and its Qt3 compatibility facilities.
It still uses an obsolete version of Qwt and QwtPlot.

I tried to fork the latest upstream source and begin to migrate
code from Qt4 to Qt5, but the task appears as quite difficult,
since many obsolete Qt3 structures are still in use, and that quite
a lot of Qwt structures are now unsupported with the recent qwt release (the
only compatible with Qt5).

As messages asking for an update at upstream level got no reply during the
last three months, and that no git branch was opened recently to address
this issue in the upstream repository, I suspect that Scidavis will
never be ported to Qt5 by upstream developers.

So, I ask for the removal of the package Scidavis from both Testing and
Unstable distributions, as I do not consider to make this migration.

Thank you in advance.

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

Kernel: Linux 4.9.0-6-amd64 (SMP w/4 CPU cores)
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8),
LANGUAGE=fr_FR.UTF-8 (charmap=UTF-8)

Bug#615874: bug in Debian package libpam-mount

[Jonathan Dowland]

Hi,

On Sun, Apr 01, 2018 at 12:01:47PM +0200, Jochen Sprickerhof wrote:
a long time ago you opened a bug in the Debian package libpam-mount. 
Recently I took over maintenance of this package and tried to 
reproduce your bug but didn't find it. If you still have this problem, 
could you please provide detailed instructions on how to reproduce it 
(best in a chroot or VM)? If you can't reproduce the bug or if there 
is no message in a month from now, I will assume this bug was fixed 
already and close this.


I'll close it now, I can't reproduce it using Carsten's instructions and
I long ago migrated away from that machine.

Good luck with the package!


--
Jonathan Dowland

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

[Andreas Beckmann]

Control: tag -1 stretch

On 2018-04-01 14:51, Adam D. Barratt wrote:
> Andreas - you tagged #883987 as "buster sid" despite the version
> tracking implying that stretch was affected. Do you remember the
> details as to why?

Most likely:

On Tue, 12 Dec 2017 14:13:18 +0100 (CET) Pierre Saramito
 wrote:> Hi Andreas,
>
> This problem do neither comes from Rheolef-6.7 nor from CGAL-4.11:
> it comes from Boost-1.62 combined with g++ 7.2 in Debian sid and testing.

So gcc-7 triggered the tags.

Adding stretch since the problem is apparently reproducible there ...
(and "stretch buster sid" (rather than "") carries for me the meaning
that this was set intentionally in this "unclear" case)


Andreas

Bug#894580: postinst does not create the knot-resolver user

[Marco d'Itri]

Package: knot-resolver
Version: 2.1.1-1
Severity: grave
Tags: patch

Due to a typo in postinst, the knot-resolver user is not actually 
created at install time, so nothing works.

-if [ "$1" = "$configure" ]; then
+if [ "$1" = "configure" ]; then

-- 
ciao,
Marco


signature.asc
Description: PGP signature

Bug#894577: CVE-2016-5397

[Moritz Muehlenhoff]

On Sun, Apr 01, 2018 at 10:52:59PM +0200, László Böszörményi (GCS) wrote:
> Hi Moritz,
> 
> On Sun, Apr 1, 2018 at 10:38 PM, Moritz Muehlenhoff  wrote:
> > Package: thrift-compiler
> > Severity: grave
> > Tags: security
> >
> > This was assigned CVE-2016-5397: 
> > https://issues.apache.org/jira/browse/THRIFT-3893
>  This affects the Go compiler component only if I see it right. That's
> packaged only with 0.9.3-2 and later versions. As such, it affects
> only thrift which is still in experimental only. I need to check every
> usage scenario of course - but I'm going to do that in daytime and not
> at the moment. :-/

Thanks, I wasn't aware of that. If you can confirm that, please update the
security tracker to mark it as not-affected.

Cheers,
Moritz

Bug#894579: ITP: libmypaint -- brush library for mypaint

[Jeremy Bicha]

Package: wnpp
Severity: wishlist
X-Debbugs-CC: debian-de...@lists.debian.org, debian-multime...@lists.debian.org
Owner: jbi...@debian.org

Package Name: libmypaint
Version: 1.3.0
Upstream Authors : Martin Renold, Jon Norby, and others
License : ISC
Programming Lang: C
Homepage: https://github.com/mypaint/libmypaint

Description: brush library for mypaint
 MyPaint is a pressure- and tilt-sensitive painting program which works well
 with Wacom graphics tablets and other similar devices. It comes with a large
 brush collection including charcoal and ink to emulate real media, but the
 highly configurable brush engine allows you to experiment with your own
 brushes and with not-quite-natural painting.
 .
 This package contains the shared library.

Other Info
--
This package and mypaint-brushes are required dependencies for gimp 2.10.

The next major release of mypaint will use this library also.

I intend to help maintain this package under the Debian Multimedia Team.

Packaging is at
https://salsa.debian.org/multimedia-team/libmypaint

Thanks,
Jeremy Bicha

Bug#894577: CVE-2016-5397

[GCS]

Hi Moritz,

On Sun, Apr 1, 2018 at 10:38 PM, Moritz Muehlenhoff  wrote:
> Package: thrift-compiler
> Severity: grave
> Tags: security
>
> This was assigned CVE-2016-5397: 
> https://issues.apache.org/jira/browse/THRIFT-3893
 This affects the Go compiler component only if I see it right. That's
packaged only with 0.9.3-2 and later versions. As such, it affects
only thrift which is still in experimental only. I need to check every
usage scenario of course - but I'm going to do that in daytime and not
at the moment. :-/

> Fix: 
> https://github.com/apache/thrift/commit/2007783e874d524a46b818598a45078448ecc53e
 I don't really consider this as a fix, it disables the
format_go_output function instead of input sanitizing. :-(

Thanks anyway,
Laszlo/GCS

Bug#894578: ITP: mypaint-brushes -- brushes for paint apps

[Jeremy Bicha]

Package: wnpp
Severity: wishlist
X-Debbugs-CC: debian-de...@lists.debian.org, debian-multime...@lists.debian.org
Owner: jbi...@debian.org

Package Name: mypaint-brushes
Version: 1.3.0
Upstream Authors : Martin Renold, the MyPaint Development Team, and others
License : brushes are CC0-1.0, the rest is GPL-2+
Programming Lang: N/A
Homepage: https://github.com/Jehan/mypaint-brushes

Description: brushes for paint apps
 MyPaint is a pressure- and tilt-sensitive painting program which works well
 with Wacom graphics tablets and other similar devices. It comes with a large
 brush collection including charcoal and ink to emulate real media, but the
 highly configurable brush engine allows you to experiment with your own
 brushes and with not-quite-natural painting.
 .
 This package contains the virtual paint brushes.

Other Info
--
This package and libmypaint are required dependencies for gimp 2.10.

There is an obvious duplication here with the brushes included in
Debian's mypaint package. I expect a future mypaint release will no
longer include the brushes and will depend on the mypaint-brushes
package. We could drop the bundled brushes from our mypaint package
now, but upstream advised to wait a bit longer for
https://github.com/mypaint/mypaint/pull/538 to be approved.

I intend to help maintain this package under the Debian Multimedia Team.

Packaging is at
https://salsa.debian.org/multimedia-team/mypaint-brushes

Thanks,
Jeremy Bicha

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

[Andreas Beckmann]

On Sat, 31 Mar 2018 20:53:05 +0200 Dominik George
 wrote:
> Files in second .deb but not in first
> -
> -rw-r--r--  root/root   /lib/security/pam_krb5_migrate_mit.so

> Files in first .deb but not in second
> -
> -rw-r--r--  root/root   
> /lib/security/pam_krb5_migrate_mit.so/pam_krb5_migrate_mit.so

Does dpkg gracefully handle directory->file transitions?
I know it intentionally doesn't do symlink<->directory transitions ...


Andreas

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

[Andreas Beckmann]

On Sat, 31 Mar 2018 22:38:18 +0100 "Adam D. Barratt"
 wrote:
> On Wed, 2018-03-14 at 20:13 +0200, Adrian Bunk wrote:
> >   * Switch dpkg trigger to noawait. Closes: #864953.
> 
> It would have been helpful to indicate what issue this was solving. (I
> realise that the changelog for the unstable upload is equally
> unverbose, but there's no requirement to simply re-use them.)

I can reproducibly run into dpkg trigger cycles in a few piuparts
jessie->stretch upgrade tests. They went away when I tested noawait
triggers in this package ... (during deep freeze iirc).


Andreas

Bug#894577: CVE-2016-5397

[Moritz Muehlenhoff]

Package: thrift-compiler
Severity: grave
Tags: security

This was assigned CVE-2016-5397: 
https://issues.apache.org/jira/browse/THRIFT-3893

Fix: 
https://github.com/apache/thrift/commit/2007783e874d524a46b818598a45078448ecc53e

Cheers,
Moritz

Bug#894576: RFS: ffe/0.3.8-1 [QA upload]

[Fabian Wolff]

Package: sponsorship-requests
Severity: normal

Dear mentors,

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

My changes are summarized in the latest changelog entry:

 ffe (0.3.8-1) unstable; urgency=medium

   * QA upload.
   * New upstream release.
   * Upgrade to debhelper compat level 11.
   * Upgrade to Standards-Version 4.1.3 in debian/control (no changes).
   * Update debian/watch to version 4 format (no changes).
   * Remove debian/dirs (not needed).
   * Remove trailing whitespace from old changelog entries to silence
 the file-contains-trailing-whitespace Lintian tag.

  -- Fabian Wolff   Sun, 01 Apr 2018 21:15:13 +0200


The package is available on Mentors:

  https://mentors.debian.net/package/ffe
  https://mentors.debian.net/debian/pool/main/f/ffe/ffe_0.3.8-1.dsc

Thank you!

Best regards,
Fabian

Bug#894493: lexicon: please make the build reproducible

[Chris Lamb]

tags 894493 fixed-upstream
thanks

Merged upstream:

  https://github.com/AnalogJ/lexicon/pull/212#issuecomment-377809194


Regards,

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

Bug#885999: dia: Crash on trying to simple scale object

[John Scott]

Package: dia
Version: 0.97.3+git20160930-8
Followup-For: Bug #885999

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

I am able to reproduce on Buster. I'm including a backtrace.

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

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

Versions of packages dia depends on:
ii  dia-common   0.97.3+git20160930-8
ii  libart-2.0-2 2.3.21-3
ii  libatk1.0-0  2.28.1-1
ii  libc62.27-2
ii  libcairo21.15.10-1
ii  libfontconfig1   2.12.6-0.1
ii  libfreetype6 2.8.1-2
ii  libgdk-pixbuf2.0-0   2.36.11-2
ii  libglib2.0-0 2.56.0-4
ii  libgtk2.0-0  2.24.32-1
ii  libpango-1.0-0   1.42.0-1
ii  libpangocairo-1.0-0  1.42.0-1
ii  libpangoft2-1.0-01.42.0-1
ii  libpng16-16  1.6.34-1
ii  libpython2.7 2.7.14-7
ii  libxml2  2.9.4+dfsg1-6.1
ii  libxslt1.1   1.1.29-5
ii  zlib1g   1:1.2.8.dfsg-5

Versions of packages dia recommends:
ii  dia-shapes   0.6.0-3
ii  gsfonts-x11  0.25

dia suggests no packages.

- -- no debconf information

*** /home/john/diabt.txt
#0  0x in  ()
#1  0x7fffe985eda8 in PyDiaObject_MoveHandle (self=0x7fffe76e17e0, 
args=) at pydia-object.c:236
#2  0x7fffe93821b0 in call_function (oparg=, 
pp_stack=0x7fffcbc0) at ../Python/ceval.c:4372
#3  0x7fffe93821b0 in PyEval_EvalFrameEx (f=f@entry=Frame 0x55d21ad0, 
for file /usr/share/dia/python/scascale.py, line 111, in SimpleScale 
(data=, factor=, objs=(,), scaleFailed={}, 
o=, pos=, hSE=None, hLR=, x=, y=, x2=, y2=), 
throwflag=throwflag@entry=0)
at ../Python/ceval.c:3009
#4  0x7fffe9382cfb in fast_function (nk=, na=2, n=2, 
pp_stack=0x7fffcce0, func=)
at ../Python/ceval.c:4457
#5  0x7fffe9382cfb in call_function (oparg=, 
pp_stack=0x7fffcce0) at ../Python/ceval.c:4392
#6  0x7fffe9382cfb in PyEval_EvalFrameEx (f=, 
throwflag=) at ../Python/ceval.c:3009
#7  0x7fffe94b2198 in PyEval_EvalCodeEx (co=, 
globals=, locals=, args=, 
argcount=, kws=0x0, kwcount=0, defs=0x0, defcount=0, 
closure=0x0) at ../Python/ceval.c:3604
#8  0x7fffe9443349 in function_call.lto_priv.345 (func=, arg=(, ), kw=0x0)
at ../Objects/funcobject.c:523
#9  0x7fffe9327313 in PyObject_Call (func=, arg=, kw=)
at ../Objects/abstract.c:2547
#10 0x7fffe947ec6c in instancemethod_call.lto_priv.261 (func=, arg=(, ), kw=0x0) at ../Objects/classobject.c:2600
#11 0x7fffe9327313 in PyObject_Call (func=, arg=, kw=) at 
../Objects/abstract.c:2547
#12 0x7fffe94b16c7 in PyEval_CallObjectWithKeywords (func=, arg=(,), 
kw=) at ../Python/ceval.c:4241
#13 0x7fffe87b9768 in pyg_closure_marshal (closure=0x55fe5c40, 
return_value=0x0, n_param_values=1, param_values=0x7fffd380, 
invocation_hint=, marshal_data=)
at /build/pygobject-2-JVNV4G/pygobject-2-2.28.6/gobject/pygtype.c:1216
#17 0x76673e0f in  (instance=, signal_id=, 
detail=) at ../../../../gobject/gsignal.c:3447
#14 0x76657f6d in g_closure_invoke (closure=0x55fe5c40, 
return_value=0x0, n_param_values=1, param_values=0x7fffd380, 
invocation_hint=0x7fffd300) at ../../../../gobject/gclosure.c:804
#15 0x7666ad3e in signal_emit_unlocked_R 
(node=node@entry=0x55920ac0, detail=detail@entry=0, 
instance=instance@entry=0x55f1e830, 
emission_return=emission_return@entry=0x0, 
instance_and_params=instance_and_params@entry=0x7fffd380) at 
../../../../gobject/gsignal.c:3635
#16 0x766733f5 in g_signal_emit_valist (instance=, 
signal_id=, detail=, 
var_args=var_args@entry=0x7fffd540) at ../../../../gobject/gsignal.c:3391
#18 0x77571775 in gtk_real_button_released (button=0x55f1e830 
[GtkButton]) at ./gtk/gtkbutton.c:1712
#22 0x76673e0f in  (instance=, signal_id=, 
detail=) at ../../../../gobject/gsignal.c:3447
#19 0x76657f6d in g_closure_invoke (closure=0x55926ca0, 
return_value=0x0, n_param_values=1, param_values=0x7fffd7f0, 
invocation_hint=0x7fffd770) at ../../../../gobject/gclosure.c:804
#20 0x7666ae0e in signal_emit_unlocked_R 
(node=node@entry=0x55d2e090, detail=detail@entry=0, 
instance=instance@entry=0x55f1e830, 
emission_return=emission_return@entry=0x0, 
instance_and_params=instance_and_params@entry=0x7fffd7f0) at 
../../../../gobject/gsignal.c:3565
#21 0x766733f5 in g_signal_emit_valist (instance=, 
signal_id=, detail=, 
var_args=var_args@entry=0x7fffd9b0) at 

Bug#893817:

[Maximilian Eschenbacher]

I am experiencing the same bug.

Bug#871806: uscan: (dpkg, git-buildpackage) accept/mangle/store signed git tags in cases where upstream does not publish detached sigs on tarballs

[Georg Faerber]

(Sorry for missing In-Reply-To: and References:)

Hi all,

I was just pointed to this bug, which seems quite similar as #827065.
Should these be merged?

Also, as I wrote in #827065: I'm highly interested in getting this into
uscan, and I would like to take care of this. But: I need a mentor, as
my Perl knowledge is quite shitty.

Cheers,
Georg


signature.asc
Description: Digital signature

Bug#894575: ITP: node-tldjs -- JavaScript module that delivers details about domain names

[Michael Meskes]

Package: wnpp
Severity: wishlist
Owner: Michael Meskes 

* Package name: node-tldjs
  Version : 2.3.1
  Upstream Author : Thomas Parisot 
* URL : https://github.com/oncletom/tld.js/
* License : MIT
  Programming Lang: JavaScript
  Description : JavaScript module that delivers details about domain names

 `tld.js` is a Node.js module written in JavaScript to work against complex 
 domain names, subdomains and well-known TLDs.
 .
 It answers with accuracy to questions like what is host's (sub)domain, or is
 its TLD a well-known one?

 Just another new dependency for browserpass.

Bug#894574: Please add support for riscv64 architecture

[Aurelien Jarno]

Package: python-numpy
Version: 1:1.13.3-2
Severity: wishlist
Tags: patch upstream
User: debian-ri...@lists.debian.org
Usertags: riscv64

Hi,

We are in the process of bootstrapping a Debian port for the
riscv64 architecture (https://wiki.debian.org/RISC-V). It happens that
python-numpy needs a patch to support this architecture, which has just
been merged upstream:

  https://github.com/numpy/numpy/commit/718d9e866b8f49a6898d267ed45306c08410e86c

The patch doesn't apply cleanly on the version 1.13.3 which is in
Debian, so I have backported the patch. You'll find it attached.

Would it be possible to include it in the next upload?

Thanks,
Aurelien

-- System Information:
Debian Release: buster/sid
  APT prefers unreleased
  APT policy: (500, 'unreleased'), (500, 'unstable')
Architecture: riscv64

Kernel: Linux 4.15.0_riscv-linux-4.15_2b0aa1de4+ (SMP w/1 CPU core)
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), 
LANGUAGE=fr_FR.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
--- a/numpy/core/include/numpy/npy_cpu.h
+++ b/numpy/core/include/numpy/npy_cpu.h
@@ -15,6 +15,7 @@
  *  NPY_CPU_ARMEB
  *  NPY_CPU_SH_LE
  *  NPY_CPU_SH_BE
+ *  NPY_CPU_RISCV64
  */
 #ifndef _NPY_CPUARCH_H_
 #define _NPY_CPUARCH_H_
@@ -76,6 +77,8 @@
 #define NPY_CPU_AARCH64
 #elif defined(__mc68000__)
 #define NPY_CPU_M68K
+#elif defined(__riscv) && defined(__riscv_xlen) && __riscv_xlen == 64
+#define NPY_CPU_RISCV64
 #else
 #error Unknown CPU, please report this to numpy maintainers with \
 information about your platform (OS, CPU and compiler)
--- a/numpy/core/include/numpy/npy_endian.h
+++ b/numpy/core/include/numpy/npy_endian.h
@@ -45,7 +45,8 @@
 || defined(NPY_CPU_AARCH64) \
 || defined(NPY_CPU_SH_LE)   \
 || defined(NPY_CPU_MIPSEL)  \
-|| defined(NPY_CPU_PPC64LE)
+|| defined(NPY_CPU_PPC64LE) \
+|| defined(NPY_CPU_RISCV64)
 #define NPY_BYTE_ORDER NPY_LITTLE_ENDIAN
 #elif defined(NPY_CPU_PPC)  \
 || defined(NPY_CPU_SPARC)   \

Bug#874498: [Pkg-protobuf-devel] Bug#874498: protobuf: Please package latest upstream version

[GCS]

On Sun, Apr 1, 2018 at 4:31 PM, Dmitry Smirnov  wrote:
> On Saturday, 31 March 2018 7:12:03 PM AEST László Böszörményi (GCS) wrote:
>>  We are three here as I count. I do plan to update it, but I still
>> have some time constraints.
>
> Sorry László, somehow I didn't think that you are still interested...
 Made a quick update[1], build and test it Andres if you may have
time. Beware, it may not work at all.

>> But to be honest Dmitry, you have the most
>> possibilities here as I know. As I understand, you also have time
>> issues and maybe don't want to work on this package even.
>
> Unfortunately I won't be able to work on protobuf for a very long time, if
> ever... Please don't count on me.
 Sorry to hear this. Hope we will meet again somewhen, maybe at
DebConf this year?

Regards,
Laszlo/GCS
[1] dget -x http://www.barcikacomp.hu/gcs/protobuf_3.5.2-1.dsc

Bug#894573: savi: "make clean" fails with debhelper >= 11.1.5

[Adrian Bunk]

Package: debhelper
Version: 11.1.5
Severity: serious
Control: affects -1 src:savi

https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/savi.html

...
dh clean --parallel
   dh_auto_clean -O--parallel
make -j16 -O clean
make[1]: Entering directory '/build/1st/savi-1.5.1'
/bin/rm -f *~ core 
making clean in manual...
make: Entering an unknown directory
make: *** unknown output-sync type 'clean'.  Stop.
make: Leaving an unknown directory
making clean in bin...
make: Entering an unknown directory
make: *** unknown output-sync type 'clean'.  Stop.
make: Leaving an unknown directory
making clean in maps...
make: Entering an unknown directory
make: *** unknown output-sync type 'clean'.  Stop.
make: Leaving an unknown directory
making clean in oogl...
make: Entering an unknown directory
make: *** unknown output-sync type 'clean'.  Stop.
make: Leaving an unknown directory
making clean in data...
make: Entering an unknown directory
make: *** unknown output-sync type 'clean'.  Stop.
make: Leaving an unknown directory
making clean in tcl...
make: Entering an unknown directory
make: *** unknown output-sync type 'clean'.  Stop.
make: Leaving an unknown directory
making clean in src...
make: Entering an unknown directory
make: *** unknown output-sync type 'clean'.  Stop.
make: Leaving an unknown directory
make[1]: *** [Makefile:22: clean] Error 2
make[1]: Leaving directory '/build/1st/savi-1.5.1'
dh_auto_clean: make -j16 -O clean returned exit code 2
make: *** [debian/rules:7: clean] Error 25

Bug#894572: statsmodels FTBFS with dh-python >= 3.20180313

[Adrian Bunk]

Source: statsmodels
Version: 0.8.0-6
Severity: serious

https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/statsmodels.html

...
 make -C docs html
make[2]: Entering directory '/build/1st/statsmodels-0.8.0/docs'
Make static directory for images
mkdir -p build/html/_static
# generate the examples rst files
Generating reST from examples folder
#../tools/examples_rst.py
Generating datasets from installed statsmodels.datasets
python3 ../tools/dataset_rst.py
Traceback (most recent call last):
  File "../tools/dataset_rst.py", line 8, in 
import statsmodels.api as sm
ModuleNotFoundError: No module named 'statsmodels'
make[2]: *** [Makefile:68: html] Error 1

Bug#894571: jupyter-notebook FTBFS: test failures

[Adrian Bunk]

Source: jupyter-notebook
Version: 5.4.0-1
Severity: serious

https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/jupyter-notebook.html

...
   debian/rules override_dh_auto_test
make[1]: Entering directory '/build/1st/jupyter-notebook-5.4.0'
mkdir -p /build/1st/jupyter-notebook-5.4.0/debian/tmp-home/runtime
# send2trash deletion tests fail if the temporary notebook files
# are on a different block device to the implicit trash directory in HOME
TMPDIR=/build/1st/jupyter-notebook-5.4.0/debian/tmp-home/runtime dh_auto_test
I: pybuild base:217: cd 
/build/1st/jupyter-notebook-5.4.0/.pybuild/cpython2_2.7/build; python2.7 -m 
nose 
No handlers could be found for logger "NotebookApp"
../usr/lib/python2.7/dist-packages/ipython_genutils/tempdir.py:58:
 Warning: Implicitly cleaning up 
  Warning)
./usr/lib/python2.7/dist-packages/ipython_genutils/tempdir.py:58: Warning: 
Implicitly cleaning up 
  Warning)
.../usr/lib/python2.7/dist-packages/nbformat/validator.py:251:
 UserWarning: No schema for validating v2 notebooks
  warnings.warn("No schema for validating v%s notebooks" % version, UserWarning)
..E..Traceback
 (most recent call last):
  File "/usr/lib/python2.7/runpy.py", line 174, in _run_module_as_main
"__main__", fname, loader, pkg_name)
  File "/usr/lib/python2.7/runpy.py", line 72, in _run_code
exec code in run_globals
  File "/usr/lib/python2.7/dist-packages/ipykernel_launcher.py", line 15, in 

from ipykernel import kernelapp as app
  File "/usr/lib/python2.7/dist-packages/ipykernel/__init__.py", line 2, in 

from .connect import *
  File "/usr/lib/python2.7/dist-packages/ipykernel/connect.py", line 10, in 

from subprocess import Popen, PIPE
  File "/usr/lib/python2.7/subprocess.py", line 79, in 
import pickle
  File "/usr/lib/python2.7/pickle.py", line 69, in 
class UnpicklingError(PickleError):
KeyboardInterrupt
.../usr/lib/python2.7/dist-packages/jupyter_client/kernelspec.py:253: 
UserWarning: Invalid kernelspec directory name (Kernel names can only contain 
ASCII letters and numbers and these separators: - . _ (hyphen, period, and 
underscore).): 
/build/1st/jupyter-notebook-5.4.0/debian/tmp-home/runtime/tmpmJC2gx/data/kernels/sample
 2
  d = self.find_kernel_specs()
.../usr/lib/python2.7/dist-packages/ipython_genutils/tempdir.py:58:
 Warning: Implicitly cleaning up 
  Warning)
.There is currently no server running on port 999
Ports currently in use:
  - 100
  - 101
  - 102
  - 103
  - 104
  - 105
  - 106
  - 107
  - 108
  - 109
..S
==
ERROR: test_connections 
(notebook.services.kernels.tests.test_kernels_api.KernelAPITest)
--
Traceback (most recent call last):
  File 
"/build/1st/jupyter-notebook-5.4.0/.pybuild/cpython2_2.7/build/notebook/services/kernels/tests/test_kernels_api.py",
 line 172, in test_connections
ws = self.kern_api.websocket(kid)
  File 
"/build/1st/jupyter-notebook-5.4.0/.pybuild/cpython2_2.7/build/notebook/services/kernels/tests/test_kernels_api.py",
 line 60, in websocket
f = websocket_connect(req, io_loop=loop)
TypeError: websocket_connect() got an unexpected keyword argument 'io_loop'
 >> begin captured logging << 
traitlets: DEBUG: Paths used for configuration of jupyter_notebook_config: 

/build/1st/jupyter-notebook-5.4.0/debian/tmp-home/runtime/jupyter-clean-cfg-v4qdGi/jupyter_notebook_config.json
traitlets: DEBUG: Paths used for configuration of jupyter_notebook_config: 

/build/1st/jupyter-notebook-5.4.0/debian/tmp-home/runtime/tmpYWTo0I/config/jupyter_notebook_config.json
NotebookApp: INFO: Serving notebooks from local directory: 
/build/1st/jupyter-notebook-5.4.0/debian/tmp-home/runtime/tmpYWTo0I/notebooks
NotebookApp: INFO: 0 active kernels
NotebookApp: INFO: The Jupyter Notebook is running at:
NotebookApp: INFO: http://localhost:12341/a%40b/?token=...
NotebookApp: INFO: Use Control-C to stop this server and shut down all kernels 
(twice to skip confirmation).
urllib3.connectionpool: DEBUG: Starting new HTTP connection (1): localhost
NotebookApp: WARNING: Forbidden
NotebookApp: WARNING: 403 GET /a%40b/api/contents (::1) 1.60ms referer=None
urllib3.connectionpool: DEBUG: http://localhost:12341 "GET /a%40b/api/contents 
HTTP/1.1" 403 40
urllib3.connectionpool: DEBUG: Starting new HTTP connection (1): localhost
NotebookApp: INFO: Kernel started: 3fe70fc2-5dc7-4688-9774-5e6cf5c82ce1
urllib3.connectionpool: DEBUG: http://localhost:12341 "POST /a%40b/api/kernels 
HTTP/1.1" 201 162
urllib3.connectionpool: DEBUG: Starting new HTTP connection (1): localhost
urllib3.connectionpool: DEBUG: http://localhost:12341 

Bug#892147: Please create the Pragha package with complete audio (api) support

[Gabriel F. T. Gomes]

Hi, Jürgen Göricke,

Have you tried to do what I suggested? (i.e.: Change the "Audio Device"
in pragha settings to "hw:1" or "default:1")


pgpt6JOT2ujxZ.pgp
Description: OpenPGP digital signature

Bug#856657: gnome-software: Sometimes claims repo is not active

[Donald Pedersen]

This bug is happening to me too on Stretch.  The message reads 
debian-stable-main instead of debian-testing-main.  There's a post on 
the Debian forums about this too.


http://forums.debian.net/viewtopic.php?f=30=135196

Bug#864603: gufw does not launch

[John Scott]

Package: gufw
Version: 17.04.1-1.1
Followup-For: Bug #864603

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

I am able to reproduce this issue exactly as described on
Debian Stretch with GNOME using Wayland. I can not, however,
reproduce this issue in the default X11 session.

To those that have been able to reproduce this bug: are you
using Wayland? If so, then I believe that this is not a bug in
Gufw, but that #880601 (GDM) is causing this. Another thing
that would help is to see if GParted works when Gufw does not,
to narrow this down a little more.

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

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

Versions of packages gufw depends on:
ii  gir1.2-gtk-3.0  3.22.29-2
pn  gir1.2-webkit2-4.0  
pn  net-tools   
ii  policykit-1 0.105-18
ii  python3 3.6.4-1
ii  python3-gi  3.28.1-1
pn  ufw 

gufw recommends no packages.

gufw suggests no packages.

-BEGIN PGP SIGNATURE-

iQFGBAEBCgAwFiEEJwCMxdBfG24Y2trvfWFEpid5MHIFAlrBH9YSHGpzY290dEBw
b3N0ZW8ubmV0AAoJEH1hRKYneTByH2QIAJVe6hksfujmLCF8NGxiNexnHF8bfC33
Fp1aua11/x2JK6ymPC9P9QLORc+QlnUJ8Elz+wRP29yeFw2u5+vtsxn0S8iOwsJi
xYaQ0qgNuZGYIfhJunuHwQfAFgwkwrN9DhdpSpjoPUlyNn3welIz2Vr4eJSF00h4
YDn6ljv6FjReKzabeAsVbQSuoDhwUuljUAUc/guNi2prDQnneK308E/v2ofLxu2C
amESi61Essgxq3BsN1311MVH4oyQsoe+sVaX8TedpuBWuqTf5ZN0DBWTlR2jKgD9
vusYpCFCyWpWPm7KGFGfONKb4jDTOjL3iU2lwkNFGmUohSeKZ30frMk=
=WZo6
-END PGP SIGNATURE-

Bug#894570: openjdk-9-jre: Upgrading (via dist-upgrade) to Java 9 hoses Sage's jmol 3D viewer.

[Emmanuel Charpentier]

Package: openjdk-9-jre
Version: 9.0.4+12-3
Severity: normal

Dear Maintainer,

I noticed that upgrading to Java 9, as testing recently did, hosed my (self-
compiled Sage installation : the jmol 3D viewer could not longer start, for
lack of a suitable Java installation : see
https://groups.google.com/d/msg/sage-release/333nWF3BtIU/6UD9YA4sBQAJ for the
original bug report.

   * What led up to the situation?

Upgrading Java to Java 9 via apt-get dist-upgrade (following testing).

After the upgrade, Sage's 3D jmol viewer couldn't start.


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

Manually reverting to Java 8 (via update-java-alternatives --set
java-1.8.0-openjdk-amd64)
allows Sage's 3D viewer worked correctly. See also
https://trac.sagemath.org/ticket/25026#comment:15 for (little) more detail.

   * What was the outcome of this action?

A working Sage's 3D viewer.

   * What outcome did you expect instead?

A working jmol viewer using the default Java installation (i. e. Java 9)...

(Possibly unrelated) note : I also noticed that Java 9 version does not offer a
default-java-plugin package. Is that normal ?



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

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

Versions of packages openjdk-9-jre depends on:
ii  libasound2   1.1.3-5
ii  libatk-wrapper-java-jni  0.33.3-20
ii  libc62.27-2
ii  libgif7  5.1.4-2
ii  libgl1   1.0.0-2
ii  libgl1-mesa-glx  17.3.7-1
ii  libglib2.0-0 2.56.0-4
ii  libgtk2.0-0  2.24.32-1
ii  libjpeg62-turbo  1:1.5.2-2+b1
ii  libpng16-16  1.6.34-1
ii  libx11-6 2:1.6.5-1
ii  libxext6 2:1.3.3-1+b2
ii  libxinerama1 2:1.1.3-1+b3
ii  libxrandr2   2:1.5.1-1
ii  openjdk-9-jre-headless   9.0.4+12-3
ii  zlib1g   1:1.2.8.dfsg-5

Versions of packages openjdk-9-jre recommends:
ii  fonts-dejavu-extra  2.37-1

Versions of packages openjdk-9-jre suggests:
ii  icedtea-8-plugin  1.6.2-3.1

-- no debconf information

Bug#894462: paraview: edges are blotted [regression]

[Anton Gladky]

Hi Francesco,

thanks for bugreport. The problem with paraview now is that it does
not actually have any active maintainer [1]. I am not using it any more
and the Gert (thanks to him!) is doing some technical uploads.

If you really want it to be fixed (as well as export to AVI), feel free
to join our team and provide some patches. Or at least the communication
with upstream would be very helpful. Otherwise paraview is the good
candidate to be dropped from the next release.

[1] https://tracker.debian.org/pkg/paraview

Best regards

Anton


2018-03-30 18:01 GMT+02:00 Francesco Poli (wintermute)
:
> Package: paraview
> Version: 5.4.1+dfsg4-2
> Severity: grave
> Justification: renders package unusable
>
> Hello paraview Debian package maintainers,
> thanks for uploading a Debian revision that uses Qt5 rather than Qt4!
>
> I've just upgraded to it on my Debian testing box, but I found a bad
> regression that renders the package unusable to create beautiful and
> clear visualizations (this may be considered as basically the main
> purpose of paraview!).
>
>
> The attached test case is based on one of the data files generated
> by the little program included in the test case sent for bug #892293.
> The program source (written in Fortran) is included again for
> completeness' sake.
>
> Steps to reproduce the regression:
>
>   0) start paraview
>
>  $ paraview
>
>   1) click on the "Open" button and open "wave0001.xyz"
>
>   2) specify "PLOT3D Files" in the "Open Data With..." dialog window
>
>   3) click on the "Apply" button
>
>   4) change the representation from "Outline" to "Surface With Edges"
>
>   5) from the File menu, select Save State...
>
>   6) save the state as "wave_PARAVIEW-VERSION.pvsm"
>
>   7) from the File menu, select Save Screenshot...
>
>   8) save the screenshot as "wave_PARAVIEW-VERSION.png"
>
>
> By performing these steps with paraview/5.4.1+dfsg3-2 and
> with paraview/5.4.1+dfsg4-2, I obtained the two attached
> screenshots.
>
> In paraview/5.4.1+dfsg4-2 there seems to be a commendable attempt
> to apply some antialiasing to all the lines (including the edges
> on surfaces, the wireframe edges, but also the lines of the orientation
> axes, and so forth...).
> Unfortunately this new feature creates unsightly images, whenever
> the edges are shown from a distance. Please take a look yourself
> at the wave_5.4.1+dfsg4-2.png screenshot: all the intersections
> between edges seem to be somehow "blotted" and unpleasant to look at.
>
>
> Please fix this regression, as it makes paraview unusable.
>
> Thanks for your time!
> Bye.
>
>
> -- System Information:
> Debian Release: buster/sid
>   APT prefers testing
>   APT policy: (800, 'testing'), (500, 'unstable')
> Architecture: amd64 (x86_64)
>
> Kernel: Linux 4.15.0-2-amd64 (SMP w/4 CPU cores)
> Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
> LANGUAGE=en_US:en (charmap=UTF-8)
> Shell: /bin/sh linked to /bin/dash
> Init: systemd (via /run/systemd/system)
> LSM: AppArmor: enabled
>
> Versions of packages paraview depends on:
> ii  libavcodec57   7:3.4.2-1+b1
> ii  libavformat57  7:3.4.2-1+b1
> ii  libavutil557:3.4.2-1+b1
> ii  libc6  2.27-2
> ii  libcgns3.3 3.3.0-6
> ii  libexpat1  2.2.5-3
> ii  libfreetype6   2.8.1-2
> ii  libgcc11:8-20180321-1
> ii  libgl1 1.0.0-2
> ii  libgl2ps1.41.4.0+dfsg1-2
> ii  libglew2.0 2.0.0-5
> ii  libhdf5-1001.10.0-patch1+docs-4
> ii  libjpeg62-turbo1:1.5.2-2+b1
> ii  libjsoncpp11.7.4-3
> ii  libnetcdf131:4.6.1-1
> ii  libogg01.3.2-1+b1
> ii  libopenmpi22.1.1-8
> ii  libpng16-161.6.34-1
> ii  libprotobuf10  3.0.0-9.1
> ii  libpython2.7   2.7.14-7
> ii  libqt5core5a   5.9.2+dfsg-12
> ii  libqt5gui5 5.9.2+dfsg-12
> ii  libqt5help55.9.2-6
> ii  libqt5network5 5.9.2+dfsg-12
> ii  libqt5widgets5 5.9.2+dfsg-12
> ii  libqt5x11extras5   5.9.2-1
> ii  libstdc++6 8-20180321-1
> ii  libswscale47:3.4.2-1+b1
> ii  libtheora0 1.1.1+dfsg.1-14+b1
> ii  libtiff5   4.0.9-4
> ii  libx11-6   2:1.6.5-1
> ii  libxml22.9.4+dfsg1-6.1
> ii  libxt6 1:1.1.5-1
> ii  python-autobahn17.10.1+dfsg1-2
> ii  python-matplotlib  2.1.1-2
> ii  python-mpi4py  2.0.0-3
> ii  python-six 1.11.0-2
> ii  python-twisted 17.9.0-1
> ii  tcl [tclsh]8.6.0+9
> ii  zlib1g 1:1.2.8.dfsg-5
>
> Versions of packages paraview recommends:
> ii  mpi-default-bin  1.10
> ii  paraview-doc 5.4.1+dfsg4-2
> ii  paraview-python  5.4.1+dfsg4-2
>
> Versions of packages paraview suggests:
> pn  h5utils 
> pn  hdf5-tools  
>
> -- no debconf information
>
> --
> debian-science-maintainers mailing list
> debian-science-maintain...@lists.alioth.debian.org
> http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/debian-science-maintainers

Bug#894569: acme-tiny: compatibility issues

[sergio]

Package: acme-tiny
Version: 20160801-3+deb9u1
Severity: important

Dear Maintainer,

please remove 20160801-3 from stable as it doesn't work more.

Bug#894462: paraview: edges are blotted [regression]

[Gert Wollny]

Am Freitag, den 30.03.2018, 18:01 +0200 schrieb Francesco Poli
(wintermute):
> Package: paraview
> Version: 5.4.1+dfsg4-2
> Severity: grave
> Justification: renders package unusable
> 
> Hello paraview Debian package maintainers,
> thanks for uploading a Debian revision that uses Qt5 rather than Qt4!
> 
> I've just upgraded to it on my Debian testing box, but I found a bad
> regression that renders the package unusable to create beautiful and
> clear visualizations (this may be considered as basically the main
> purpose of paraview!).

Since I did this upload as a team upload I can give you one comment  (I
don't used the program myself, and I have no idea how to use it, I am
only somewhat familiar with VTK, but also only from the "get it to
compile" side and not so much from the "how to use it properly").

With this upload I switched the package from using the deprecated
"OpenGL" redering interface (based on OpenGL 1.1) to the new "OpenGL2"
rendering interface (based on openGL 3.2), which means that his might
be a fallout from this rather big upstream change. 

These two upstream bugs might also be related: 

https://gitlab.kitware.com/paraview/paraview/issues/17202
https://gitlab.kitware.com/paraview/paraview/issues/16882

Best, 
Gert

Bug#894568: python-h11: Incomplete debian/copyright?

[Chris Lamb]

Source: python-h11
Version: 0.8.0-1
Severity: serious
Justication: Policy 12.5
X-Debbugs-CC: Sebastien Delafond 

Hi,

I just ACCEPTed python-h11 from NEW but noticed:

  // Stolen from statsmodels and fixed up

in show-code.js. I'm not sure what the right solution is here, but
we should at *least* point this out in debian/copyright IMHO, and
probably seek clarification from upstream.

(This is not exhaustive so please check over the entire package 
carefully and address these on your next upload.)


Regards,

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

Bug#890311: libdashel-dev: dashelConfig.cmake(.in) broken

[Chris Lamb]

forwarded 890311 https://github.com/aseba-community/dashel/pull/42
forwarded 890568 https://github.com/aseba-community/dashel/pull/42
thanks

FYI I've forwarded this upstream here:

  https://github.com/aseba-community/dashel/pull/42


Regards,

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

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

[Michel Bouissou]

After a more thourough dive in GPGME logs, it is now crystal clear to me
that the matter is that GPG is unable to import the key data that GPGME
tries to feed into it at key import time.

Here is the result of the GPG secret key import (working) inside the
chroot :

[GNUPG:] KEY_CONSIDERED .
[GNUPG:] IMPORTED .
[GNUPG:] IMPORT_OK 1 .
[GNUPG:] IMPORT_RES 1 0 1 0 0 0 0 0 0 1 1 0 0 0 0

- Count : 1
- Imported : 1
- Sec Read : 1
- Sec Imported : 1


And now the failing one from initramfs :

[GNUPG:] IMPORT_RES 1 1 0 0 0 0 0 0 0 1 0 0 0 0 0.

- Count : 1
- No_User_ID : 1
- Imported : 0
- Sec Read : 1
- Sec Imported : 0


IMPORT_RES 
 
  


However it further seems to properly receive the encrypted data, but is
unable to decrypt it because it has no keys.

I have no clue about why, and what the difference can be, but I need a
break for now as I have spent my entire sunday wrestling with this :-\

Thanks again for your help.

ॐ

-- 
Michel Bouissou  OpenPGP ID 0xEB04D09C



signature.asc
Description: OpenPGP digital signature

Bug#856179: ITP: polybar -- fast and easy-to-use status bar

[Jason Pleau]

Small update,

I pushed a change to i3ipcpp that also builds a shared library in
addition to the static library. (The i3ipcpp patches I will probably be
able to send upstream at some point). polybar correctly uses the shared
library, I think it's better this way.

I don't think I can do the same with xpp, since it is a header only
library and a shared library would probably be pointless. I think I can
even remove the static library (libxpp.a); it's empty. The static
linkage happens with the xcb libraries anyway, not with xpp.


-- 
Jason Pleau

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

[Antonio Terceiro]

On Sat, Mar 31, 2018 at 04:42:36PM -0400, John David Anglin wrote:
> Source: ruby2.5
> Version: 2.5.x
> Followup-For: Bug #881773
> 
> Dear Maintainer,
> 
> In the 2.5.1 build, test #361 fails as follows:
> 
> #361 test_insns.rb:389:in `block in ' F 0.090
> stderr output is not empty
>bootstraptest.tmp.rb:3:in `once': stack level too deep (SystemStackError)
>from bootstraptest.tmp.rb:7:in `block in once'
>from bootstraptest.tmp.rb:3:in `once'
>from bootstraptest.tmp.rb:7:in `block in once'
>from bootstraptest.tmp.rb:3:in `once'
>from bootstraptest.tmp.rb:7:in `block in once'
>from bootstraptest.tmp.rb:3:in `once'
>from bootstraptest.tmp.rb:7:in `block in once'
>from bootstraptest.tmp.rb:3:in `once'
> ... 97 levels...
>from bootstraptest.tmp.rb:3:in `once'
>from bootstraptest.tmp.rb:7:in `block in once'
>from bootstraptest.tmp.rb:3:in `once'
>from bootstraptest.tmp.rb:11:in `'
> 
> So, it appears the test causes a stack overflow on hppa.
> 
> It is not uncommon for hppa to require twice the stack space x86 needs.
> Is there a way to increase the stack allocation for hppa (e.g., using ulimit)?
> Otherwise, I would say the test needs to be skipped on hppa.

I don't think working around this in the tests is the correct solution
to the issue. There was a similar problem on ppc64el recently, maybe you
can find a similar solution for hppa:

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

I don't have the cycles to go after this myself, but I'll be happy to
take a patch (but please also send it upstream).


signature.asc
Description: PGP signature

Bug#885947: marco: After updating, restart (user or pc) and log in, desktop fails

[Santiago]

Package: marco
Followup-For: Bug #885947

Dear Maintainer, if I upgrade the following retained packages to the latest 
version, follow the same problem. 

marco (1.18.1-3 => 1.20.0-2)
marco-common (1.18.1-3 => 1.20.0-2)
libmarco-private1 (1.18.1-3 => 1.20.0-2)

Regards.

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

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

Versions of packages marco depends on:
ii  libatk1.0-0   2.28.1-1
ii  libc6 2.27-2
ii  libcairo-gobject2 1.15.10-1
ii  libcairo2 1.15.10-1
ii  libcanberra-gtk3-00.30-6
ii  libcanberra0  0.30-6
ii  libgdk-pixbuf2.0-02.36.11-2
ii  libglib2.0-0  2.56.0-4
ii  libgtk-3-03.22.29-2
ii  libgtop-2.0-112.38.0-2
ii  libice6   2:1.0.9-2
ii  libmarco-private1 1.18.1-3
ii  libpango-1.0-01.42.0-1
ii  libpangocairo-1.0-0   1.42.0-1
ii  libsm62:1.2.2-1+b3
ii  libstartup-notification0  0.12-5
ii  libx11-6  2:1.6.5-1
ii  libxcomposite11:0.4.4-2
ii  libxcursor1   1:1.1.15-1
ii  libxdamage1   1:1.1.4-3
ii  libxext6  2:1.3.3-1+b2
ii  libxfixes31:5.0.3-1
ii  libxinerama1  2:1.1.3-1+b3
ii  libxrandr22:1.5.1-1
ii  libxrender1   1:0.9.10-1
ii  marco-common  1.18.1-3
ii  mate-desktop-common   1.20.0-1
ii  zenity3.28.0-1

marco recommends no packages.

marco suggests no packages.

-- no debconf information

Bug#894567: cyrus-imapd: client certificate revocation (tls_crl_file in imapd.conf) not working?

[Juergen Pfennig]

Package: cyrus-imapd
Version: 2.4.17+nocaldav-0+deb8u2
Severity: normal

Dear Maintainer,

Some clients (Android K9) support TLS client certificates, which works
fine until the device gets stolen. But how to revoke certificates?

At cyrusimap.org they document a tls_crl_file config parameter. See:

https://www.cyrusimap.org/dev/imap/reference/manpages/configs/imapd.conf.html

This parameter does not show up in debian documentation (jessie and stretch).

There is no error message when cyrus-imapd startis with this parameter pointing 
to a non-existing file.

Is this parameter implemented at all or silently ignored?

What else could be done to revoke a single certificate?

Yours
Jürgen

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

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

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


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

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

Versions of packages cyrus-imapd depends on:
ii  cyrus-common  2.4.17+nocaldav-0+deb8u2
ii  dpkg  1.17.27
ii  libc6 2.19-18+deb8u10
ii  libcomerr21.42.12-2+b1
ii  libdb5.3  5.3.28-9+deb8u1
ii  libkrb5-3 1.12.1+dfsg-19+deb8u4
ii  libsasl2-22.1.26.dfsg1-13+deb8u1
ii  libssl1.0.0   1.0.1t-1+deb8u8
ii  libwrap0  7.6.q-25
ii  zlib1g1:1.2.8.dfsg-2+b1

cyrus-imapd recommends no packages.

cyrus-imapd suggests no packages.

-- no debconf information

Bug#894493: lexicon: please make the build reproducible

[Chris Lamb]

forwarded 894493 https://github.com/AnalogJ/lexicon/pull/212
thanks

I've forwarded this upstream here:

  https://github.com/AnalogJ/lexicon/pull/212


Regards,

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

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

[Michel Bouissou]

Again :-)

Le 01/04/2018 à 18:03, Teddy Hogeborn a écrit :
> 
> To be precise, do you mean that the
> /conf/conf.d/mandos/plugin-runner.conf file does not contain the line
> --options-for=mandos-client:--dh-params=/conf/conf.d/mandos/dhparams.pem
> at the top?  What, exactly, *does* it contain?  Does it lack the
> --groupid and --userid options too?

Sorry, my mistake. I hadn't understood that the original config file
had been doctored by scripts before insertion into the initramfs.

So inside the initramfs (and chroot), its actual contents are :


--options-for=mandos-client:--dh-params=/conf/conf.d/mandos/dhparams.pem
--groupid=118
--userid=112
## This is the configuration file for plugin-runner(8mandos).  This
#
# Then follows the rest of the original config file, with my own contents :
--options-for=mandos-client:--interface=eth0,--connect=:9601,--debug


ॐ

-- 
Michel Bouissou  OpenPGP ID 0xEB04D09C

Bug#894566: Please move libkmod to /usr/lib

[Michael Biebl]

Source: kmod
Version: 25-1
Severity: wishlist

Late mounting of /usr is no longer supported since stretch, so it is no
longer necessary to move libs to /lib.
In preparation for a future usrmerge, I would suggest that we already
start moving libs to /usr proper.
I would also not bother setting a different libdir for the udeb build
and instead use the same paths as for the real deb for consistencies
sake.


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

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

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

-- no debconf information

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

[Michel Bouissou]

Hi again,

Le 31/03/2018 à 20:30, Teddy Hogeborn a écrit :
> That is the important message.  It means that it failed to decrypt the
> data from the server using the GPGME library.  In the past, this error
> has been due to all the necessary GnuPG binaries not having been copied
> into the initramfs image.

I could make some further progress. The problem resides in GnuPG being
unable to properly import the keys when running in the true initramfs,
where it works running in the chroot.

I've seen that Mandos creates a temporary directory in /tmp where it put
files, in both situation.

Then I turned on gpgme debug mode using :

export GPGME_DEBUG='9:/tmp/gpgme.log'

...Before running the client, then checked and compared the outputs.

(I won't attach the huge outputs because they obviously contain key
material)

I discovered that gpgme is first fed with a private key, sends it for
GPG to import, then a public key, which it sends to GPG for import, and
further on the decryption occurs.

In the chroot, it ends by GPG replying with :
[GNUPG:] DECRYPTION_OKAY.
[GNUPG:] GOODMDC.
[GNUPG:] END_DECRYPTION.

But in the initramfs, it ends with :
[GNUPG:] NO_SECKEY .
[GNUPG:] BEGIN_DECRYPTION.
[GNUPG:] DECRYPTION_FAILED.
[GNUPG:] PROGRESS - 1189 0 B.
[GNUPG:] END_DECRYPTION.

Then I interested myself to the key imports.

In the chroot, the secret key import replies :
[GNUPG:] KEY_CONSIDERED .
[GNUPG:] IMPORTED .
[GNUPG:] IMPORT_OK 1 .

Where in the actual initramfs, it replies :
[GNUPG:] IMPORT_RES 1 1 0 0 0 0 0 0 0 1 0 0 0 0 0.

So the issue is definitely GPG working in the chroot, and not working in
the initramfs.

I still have to try and figure out what difference could be a cause for
this.

Kind regards.

ॐ

-- 
Michel Bouissou  OpenPGP ID 0xEB04D09C



signature.asc
Description: OpenPGP digital signature

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

[Teddy Hogeborn]

Michel Bouissou  writes:

> /lib/mandos/plugin-runner
>
> I assume the latter starts the clients with the exact options from
> /conf/conf.d/mandos/plugin-runner.conf

Yes, as documented in plugin-runner(8mandos).

> ... and there is no --dh-params option.

There isn't?

To be precise, do you mean that the
/conf/conf.d/mandos/plugin-runner.conf file does not contain the line
--options-for=mandos-client:--dh-params=/conf/conf.d/mandos/dhparams.pem
at the top?  What, exactly, *does* it contain?  Does it lack the
--groupid and --userid options too?

If so, that is odd; these options should have been added when creating
the initramfs image.  The script which adds the Mandos client to the
initramfs image also adds these options when copying the base
/etc/mandos/plugin-runner.conf to /conf/conf.d/mandos/plugin-runner.conf
in the initramfs image.

If the --userid and --groupid options are not in
/conf/conf.d/mandos/plugin-runner.conf, that might explain the observed
behavior.

Maybe the Mandos initramfs creation hook script aborts for some reason
before it comes that far?  Does "update-initramfs -k all -u" (as root,
on the client system) give some error messages or warnings?

> > Since GPGME is giving the error, and it has been a problem in the
> > past, until it has beeen proved otherwise I suspect that the proper
> > binaries are not present in the system, or that they are not
> > runnable somehow.
>
> Well, they are surely there as it works in the chrooted copy of
> initramfs...

Well, maybe they aren't runnable because plugin-runner is switching to
the wrong user and group ID.  But in that case it's strange that it
could read the OpenPGP key files.

/Teddy Hogeborn

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


signature.asc
Description: PGP signature

Bug#893663: freeplane: CVE-2018-1000069 XXE vulnerability

[Markus Koschany]

Am 01.04.2018 um 17:57 schrieb Felix Natter:
[...]
> Thanks, done.
> BTW: Is it ok to close the bug with the stretch-security upload even if
> the jessie-security upload is still pending?

Yes, that's ok. You can close the bug with both uploads.

> What is there to do next?

As soon as the security team has approved the changes, I can upload your
packages to security-master.

>> Distribution should be stretch-security though and the urgency is high.
>> Similar for Jessie, jessie-security and the version is 1.3.12-1+deb8u1
> 
> I will do this soon, hopefully tomorrow.
> 
> Cheers and Best Regards,

Regards,

Markus



signature.asc
Description: OpenPGP digital signature

Bug#893663: freeplane: CVE-2018-1000069 XXE vulnerability

[Felix Natter]

Markus Koschany  writes:

> Hi Felix,

hello Markus,

> Am 01.04.2018 um 16:23 schrieb Felix Natter:
>> hello Markus,
>> 
>> I have prepared the patched 1.5.18-1+deb9u1 for stretch
>> I hope I got the version number right? The changelog entry is probably
>> not correct either. Can you advice what to read?
>> 
>> I briefly tested saving+loading mindmaps.
>> 
>> Here it is:
>> https://anonscm.debian.org/cgit/pkg-java/freeplane.git/log/?h=stretch-CVE-2018-169
>> (branch stretch-CVE-2018-169 in the freeplane alioth repo).
>> 
>> I am in the process of setting up a vbox instance for jessie to address
>> the other update.
>> 
>> Cheers and Best Regards,
>
> The version is correct. I would write in your changelog:
>
> Fix CVE-2018-169: Wojciech Reguła discovered that FreePlane was
> affected by a XML External Entity (XXE) vulnerability in its mindmap
> loader that could compromise a user's machine by opening a specially
> crafted mind map file. (Closes: #893663)

Thanks, done.
BTW: Is it ok to close the bug with the stretch-security upload even if
the jessie-security upload is still pending?

What is there to do next?

> Distribution should be stretch-security though and the urgency is high.
> Similar for Jessie, jessie-security and the version is 1.3.12-1+deb8u1

I will do this soon, hopefully tomorrow.

Cheers and Best Regards,
-- 
Felix Natter
debian/rules!

Bug#893288: Pending fixes for bugs in the libfreemarker-java package

[pkg-java-maintainers]

tag 893288 + pending
thanks

Some bugs in the libfreemarker-java package are closed in revision
2f3cf662d62132d0bbe26d33fcf65c869a3f3dad in branch 'master' by Markus
Koschany

The full diff can be seen at
https://anonscm.debian.org/cgit/pkg-java/libfreemarker-java.git/commit/?id=2f3cf66

Commit message:

Fix FTBFS with Java 9.

Closes: #893288

Bug#889411: Pending fixes for bugs in the libfreemarker-java package

[pkg-java-maintainers]

tag 889411 + pending
thanks

Some bugs in the libfreemarker-java package are closed in revision
13eb8684ba7342c8d5e5078c690544d2fc45460e in branch 'master' by Markus
Koschany

The full diff can be seen at
https://anonscm.debian.org/cgit/pkg-java/libfreemarker-java.git/commit/?id=13eb868

Commit message:

Remove Damien Raude-Morvan from Uploaders.

Closes: #889411

Bug#893663: freeplane: CVE-2018-1000069 XXE vulnerability

[Markus Koschany]

Hi Felix,

Am 01.04.2018 um 16:23 schrieb Felix Natter:
> hello Markus,
> 
> I have prepared the patched 1.5.18-1+deb9u1 for stretch
> I hope I got the version number right? The changelog entry is probably
> not correct either. Can you advice what to read?
> 
> I briefly tested saving+loading mindmaps.
> 
> Here it is:
> https://anonscm.debian.org/cgit/pkg-java/freeplane.git/log/?h=stretch-CVE-2018-169
> (branch stretch-CVE-2018-169 in the freeplane alioth repo).
> 
> I am in the process of setting up a vbox instance for jessie to address
> the other update.
> 
> Cheers and Best Regards,

The version is correct. I would write in your changelog:

Fix CVE-2018-169: Wojciech Reguła discovered that FreePlane was
affected by a XML External Entity (XXE) vulnerability in its mindmap
loader that could compromise a user's machine by opening a specially
crafted mind map file. (Closes: #893663)

Distribution should be stretch-security though and the urgency is high.
Similar for Jessie, jessie-security and the version is 1.3.12-1+deb8u1


Cheers,

Markus



signature.asc
Description: OpenPGP digital signature

Bug#894565: vim: FTBFS: Test failures if build user cannot open /dev/stdout

[Daniel Schepler]

Source: vim
Version: 2:8.0.1453-1
Severity: serious

>From 
>https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/vim.html
(and I'm also seeing pretty much the same failure under pbuilder):

...

Executing Test_z()
Executing Test_z_negative_lnum()
Executing Test_z_overflow()
Executed 345 tests


>From test_writefile.vim:
Found errors in Test_writefile_sync_dev_stdout():
Caught exception in Test_writefile_sync_dev_stdout(): Vim(call):E482:
Can't create file /dev/stdout @ function
RunTheTest[38]..Test_writefile_sync_dev_stdout, line 5

Test results:


>From test_writefile.vim:
Found errors in Test_writefile_sync_dev_stdout():
Caught exception in Test_writefile_sync_dev_stdout(): Vim(call):E482:
Can't create file /dev/stdout @ function
RunTheTest[38]..Test_writefile_sync_dev_stdout, line 5
TEST FAILURE
make[2]: *** [Makefile:42: report] Error 1
make[2]: Leaving directory '/build/1st/vim-8.0.1453/src/vim-basic/testdir'
make[1]: *** [Makefile:2069: scripttests] Error 2
make[1]: Leaving directory '/build/1st/vim-8.0.1453/src/vim-basic'
make: *** [debian/rules:272: build-stamp-vim-basic] Error 2
rm configure-stamp-vim-basic
dpkg-buildpackage: error: debian/rules binary subprocess returned exit status 2
-- 
Daniel Schepler

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

[Pirate Praveen]

On April 1, 2018 5:24:05 AM GMT+05:30, "David López Zajara" 
 wrote:
>-BEGIN PGP SIGNED MESSAGE-
>Hash: SHA256
>
>
>Hi,
>
>After latest updates (Including gitlab-workhorse), login page are
>working
>now.
>
>I've recovered the old database and repositories now. Gitlab detected
>it
>and it's working.
>
>I have two problems now.
>
>First:
>Gitlab API is not working. Error 401:
>
>Running /usr/share/gitlab-shell/bin/check
>Check GitLab API access: FAILED. code: 401
>gitlab-shell self-check failed
>  Try fixing it:
>  Make sure GitLab is running;
>  Check the gitlab-shell configuration file:
>  sudo -u gitlab -H editor /usr/share/gitlab-shell/config.yml
>  Please fix the error above and rerun the checks.

You will need to start gitaly manually. We are trying to do that automatically, 
but facing some issues currently.

>gitlab-shell error log:
>I, [2018-04-01T01:42:02.543546 #30418]  INFO -- : GET
>http://localhost:8080/api/v4/internal/check 0.06425
>E, [2018-04-01T01:42:02.573128 #30418] ERROR -- : API call http://localhost:8080/api/v4/internal/check> failed: 401 =>
><{"message":"401 Unauthorized"}>.
>
>gitlab production.log:
>Started GET "/api/v4/internal/check" for 127.0.0.1 at 2018-04-01
>01:42:02
>+0200
>
>
>Second:
>Gitlab interfaces got an error viewing repository: On Overview ->
>Details
>page:
>message: "Error loading viewer".
>
>production.log:
>
>Started GET "/repository" for x.x.x.x at 2018-04-01 01:31:03 +0200
>Completed 200 OK in 225ms (Views: 184.2ms | ActiveRecord: 17.2ms)
>Started GET "/repository/blob/master/README.md?format=json=rich"
>for
>x.x.x.x at 2018-04-01 01:31:05 +0200
>Started GET "/repository/refs/master/logs_tree/?format=js" for x.x.x.x
>at
>2018-04-01 01:31:05 +0200
>Processing by Projects::BlobController#show as JSON
>Processing by Projects::RefsController#logs_tree as JS
>Completed 500 Internal Server Error in 69ms (ActiveRecord: 2.0ms)
>
>ActionView::Template::Error (undefined method `html_escape' for
>#

We dropped one patch in this version, I think we need to adapt that patch.

>Did you mean?  html_safe?):
>1: - blob = viewer.blob
>2: - rendered_markup = blob.rendered_markup if
>blob.respond_to?(:rendered_markup)
>3: .file-content.wiki
>4:   = markup(blob.name, blob.data, rendered: rendered_markup)
>  lib/banzai/renderer/redcarpet/html.rb:9:in `block_code'
>  lib/banzai/filter/markdown_engines/redcarpet.rb:27:in `render'
>  lib/banzai/filter/markdown_engines/redcarpet.rb:27:in `render'
>  lib/banzai/filter/markdown_filter.rb:12:in `call'
>lib/banzai/pipeline/base_pipeline.rb:21:in `block (2 levels) in
>singleton
>class'
>  lib/banzai/renderer.rb:108:in `render_result'
>  lib/banzai/renderer.rb:139:in `block in cacheless_render'
>  lib/gitlab/metrics/influx_db.rb:98:in `measure'
>  lib/banzai/renderer.rb:138:in `cacheless_render'
>  lib/banzai/renderer.rb:28:in `render'
>  lib/banzai.rb:3:in `render'
>  app/helpers/markup_helper.rb:244:in `markdown_unsafe'
>  app/helpers/markup_helper.rb:143:in `markup_unsafe'
>  app/helpers/markup_helper.rb:110:in `markup'
>  app/views/projects/blob/viewers/_markup.html.haml:4:in
>`_app_views_projects_blob_viewers__markup_html_haml__60150874817435_3348073215480'
>  app/views/projects/blob/_viewer.html.haml:20:in
>`_app_views_projects_blob__viewer_html_haml__3018189872610422686_3348073432260'
> app/controllers/application_controller.rb:252:in `view_to_html_string'
>  app/controllers/concerns/renders_blob.rb:18:in `blob_json'
>  app/controllers/projects/blob_controller.rb:200:in `show_json'
> app/controllers/projects/blob_controller.rb:47:in `block (2 levels) in
>show'
>  app/controllers/projects/blob_controller.rb:39:in `show'
>  lib/gitlab/i18n.rb:50:in `with_locale'
>  lib/gitlab/i18n.rb:56:in `with_user_locale'
>  app/controllers/application_controller.rb:330:in `set_locale'
>  lib/gitlab/middleware/multipart.rb:95:in `call'
>  lib/gitlab/request_profiler/middleware.rb:14:in `call'
>  lib/gitlab/middleware/go.rb:17:in `call'
>  lib/gitlab/etag_caching/middleware.rb:11:in `call'
>  lib/gitlab/middleware/read_only/controller.rb:28:in `call'
>  lib/gitlab/middleware/read_only.rb:16:in `call'
>  lib/gitlab/request_context.rb:18:in `call'
>  lib/gitlab/metrics/requests_rack_middleware.rb:27:in `call'
>  lib/gitlab/middleware/release_env.rb:10:in `call'
>
>
>On gitlab interface, I cannot view readme.md file.
>Also, on commits list, I see this error:
>message: An error ocurred while loading commits.
>
>Production.log:
>Completed 500 Internal Server Error in 760ms (ActiveRecord: 45.2ms)
>
>ActiveRecord::StatementInvalid (PG::CharacterNotInRepertoire: ERROR:
>invalid byte sequence for encoding "UTF8": 0xf3 0x70 0x65 0x7a
>: INSERT INTO "gpg_signatures" ("gpg_key_primary_keyid", "commit_sha",
>"project_id", "gpg_key_id", "gpg_key_user_name", "gpg_key_user_email",
>"verification_status", "created_at", "updated_at") VALUES ($1, $2, $3,
>$4,
>$5, $6, $7, $8, $9) RETURNING "id"):
>  

Bug#893635: does not show up in GNOME's application menus

[Felix Natter]

hello Antoine,

thank you for the report. I cannot reproduce this on stretch with
GNOME3: It shows up in the list of applications (super key), and in both
"menu editors". Can you provide your desktop environment (GNOME3?) and a
screenshot that shows the problem?

I will ask x...@lists.freedesktop.org.

Cheers and Best Regards,
-- 
Felix Natter
debian/rules!

Bug#894564: RFS: engauge-digitizer/10.5+ds.1-1

[Tobias Winchen]

Package: sponsorship-requests
Severity: normal

Dear mentors,

I am looking for a sponsor for my package "engauge-digitizer"

 * Package name: engauge-digitizer
   Version : 10.5+ds.1-1
  Upstream Author : Mark Mitchell 
 * URL : https://github.com/markummitchell/engauge6
 * License : GPL-2+
   Section : science

 It builds those binary packages:

engauge-digitizer - interactively extracts numbers from bitmap graphs or 
maps
 engauge-digitizer-doc - engauge-digitizer user manual and tutorial

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

  https://mentors.debian.net/package/engauge-digitizer

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

dget -x https://mentors.debian.net/debian/pool/main/e/engauge-digitizer/
engauge-digitizer_10.5+ds.1-1.dsc

  Changes since the last upload:
   
 *  New upstream release
 *  Updated to standards version 4.1.3
 *  Use https link for homepage



Bests,
   Tobias Winchen

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

Bug#874498: [Pkg-protobuf-devel] Bug#874498: protobuf: Please package latest upstream version

[Dmitry Smirnov]

On Saturday, 31 March 2018 7:12:03 PM AEST László Böszörményi (GCS) wrote:
>  We are three here as I count. I do plan to update it, but I still
> have some time constraints.

Sorry László, somehow I didn't think that you are still interested...


> But to be honest Dmitry, you have the most
> possibilities here as I know. As I understand, you also have time
> issues and maybe don't want to work on this package even.

Unfortunately I won't be able to work on protobuf for a very long time, if 
ever... Please don't count on me.

-- 
Regards,
 Dmitry Smirnov.

---

Human beings, who are almost unique in having the ability to learn from the
experience of others, are also remarkable for their apparent disinclination
to do so.
-- Mahatma Gandhi


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

Bug#893663: freeplane: CVE-2018-1000069 XXE vulnerability

[Felix Natter]

hello Markus,

I have prepared the patched 1.5.18-1+deb9u1 for stretch
I hope I got the version number right? The changelog entry is probably
not correct either. Can you advice what to read?

I briefly tested saving+loading mindmaps.

Here it is:
https://anonscm.debian.org/cgit/pkg-java/freeplane.git/log/?h=stretch-CVE-2018-169
(branch stretch-CVE-2018-169 in the freeplane alioth repo).

I am in the process of setting up a vbox instance for jessie to address
the other update.

Cheers and Best Regards,
-- 
Felix Natter
debian/rules!

Bug#894552: horizon-eda: Incomplete debian/copyright?

[Wookey]

On 2018-04-01 11:11 +0100, Chris Lamb wrote:
> Source: horizon-eda
> Version: 0.20180331-1
> Severity: serious
> Justication: Policy 12.5
> X-Debbugs-CC: Wookey 
> 
> Hi,
> 
> I just ACCEPTed horizon-eda from NEW but noticed it was missing 
> attribution in debian/copyright for at least Intel & Willow
> Garage, etc. in hershey_fonts.cpp.

Well spotted. I did use licensecheck, and contact upstream about
debian/collage.png and its licencing. But missed that file being
different from its surroundings. rgrepping for opyright noticed it.
All the other files in there are by the author.

Wookey
-- 
Principal hats:  Linaro, Debian, Wookware, ARM
http://wookware.org/


signature.asc
Description: PGP signature

Bug#894342: transition: kdepim

[Sandro Knauß]

Hey,

after uploading kdepim, the buildds had built KDE Pim 17.12.3 successfully for 
amd64 and i386 (other archs are still building).

Now we needs some binNMUs. I don't know, do I need to use a separate bug for 
those requests or is it the correct way to file the wb actions just here inside 
the transition bug?

KGPG need to recompiled too as Akonadi has/had some issues with building on 
many archs (because of the dep to python). So KGPG got compiled against the old 
kdepim 17.08, just amd64 and armel were fast enough. Still archs do not built 
kdepim completely, so the BD are not available on the archs yet, so you may 
want to set dep-wait for those packages.

  nmu kgpg_17.12.3-1 . ANY -amd64 -armel . -m 'rebuilt against kdepim 17.12.3'
  dw kgpg_17.12.3-1 . ANY -amd64 -armel . -m 'libkf5akonadicontact-dev (>= 
4:17.12.3~)'

and kjots and zanshin needs to get rebuilt. As those are not inside kdepim, 
they needs to get rebuilt on any architecture. 

 nmu kjots_5.0.2-1 . ANY . -m 'rebuilt against kdepim 17.12.3'
 dw kjots_5.0.2-1 . ANY . -m 'libkf5akonadinotes-dev (>= 4:17.12.3~), 
libkf5kontactinterface-dev (>= 17.12.3~)'
 nmu zanshin_5.0-1 . ANY . -m 'rebuilt against kdepim 17.12.3'
 dw zanshin_5.0.-1 . ANY . -m 'libkf5akonadicalendar-dev (>= 4:17.12.3~)'

hefee

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

Bug#887032: sane-backends: FTBFS twice in a row

[Jörg Frings-Fürst]

Hello Andreas,

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

I have fix the bug with the attached diff file.

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
Skype:joergpenguin
Ring: jff
Telegram: @joergfringsfuerst

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

My wish list: 
 - Please send me a picture from the nature at your home.
diff --git a/debian/changelog b/debian/changelog
index f76a538..5e05986 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,6 +1,9 @@
 sane-backends (1.0.27-1~experimental4) UNRELEASED; urgency=medium
 
   * Change to my new email address.
+  * debian/rules:
+- Add override_dh_autoreconf to prevend delete of libtool.m4
+  (Closes: #887032).
 
  -- Jörg Frings-Fürst   Sun, 12 Nov 2017 13:59:10 +0100
 
diff --git a/debian/rules b/debian/rules
index 293d798..3d56db8 100755
--- a/debian/rules
+++ b/debian/rules
@@ -39,6 +39,9 @@ override_dh_auto_configure:
 		--with-usb \
 		--without-v4l
 
+override_dh_autoreconf:
+	dh_autoreconf -Xlibtool.m4
+
 override_dh_auto_build-indep:
 	# generate POT file for translators
 	(cd po && make sane-backends.pot)


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

Bug#894373: blender: Assertion Non-finite sum in path_radiance_clamp_and_sum failed

[Matteo F. Vescovi]

Control: tag -1 + moreinfo

Hi!

On 2018-03-29 at 16:01 (+0200), Lars Schimmer wrote:
> Blender dies with error: blender:
> /build/blender-AiaOIi/blender-2.79.a+dfsg0/intern/cycles/kernel/../kernel/kernel_accumulate.h:514:
> ccl::float3 ccl::path_radiance_clamp_and_sum(ccl::KernelGlobals*,
> ccl::PathRadiance*): Assertion `!"Non-finite sum in
> path_radiance_clamp_and_sum!"' failed.
>
> zsh: abort  blender -b -y Glass\ Tris\ VR\ 2\ anim.blend -noaudio
> -nojoystick -o render_
>
> Upstream 2.79b from blender.org does work without that problem on the
> same machine.
>
> If needed I can supply the .blend file (90MB)
>
> -- System Information:
> Debian Release: 9.4
>   APT prefers stable-updates
>   APT policy: (500, 'stable-updates'), (450, 'stable'), (400,
> 'testing'), (300, 'unstable'), (100, 'experimental')
> Architecture: amd64 (x86_64)

Can you explain me why you are mixing all these Debian releases?

Could you please check if the issue persists on an unstable-only-based
environment because I fear that mixing releases with different libraries
versions could be the culprit for this mess.

I'll wait for feedback.

Cheers.


-- 
Matteo F. Vescovi || Debian Developer
GnuPG KeyID: 4096R/0x8062398983B2CF7A


signature.asc
Description: PGP signature

Bug#894563: troffcvt FTBFS: /bin/sh: 1: Syntax error: word unexpected

[Adrian Bunk]

Source: troffcvt
Version: 1.04-23
Severity: serious
Tags: buster sid

Some recent change in unstable makes troffcvt FTBFS:

https://tests.reproducible-builds.org/debian/history/troffcvt.html
https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/troffcvt.html

...
touch portlib-1.01/_x_
set -e; cd portlib-1.01 ; make World INCLUDES="-I `pwd`/../lib" 
CCOPTIONS="-Wdate-time -D_FORTIFY_SOURCE=2 -g -O2 -fstack-protector-strong 
-Wformat -Werror=format-security" LDFLAGS="-Wl,-z,relro -L `pwd`/../lib" set 
-e; file_list=`find portlib-1.01 -name \*.[ah] -o -perm /111 -a -type f`; cd 
lib; for d in $file_list; do ln -sf ../$d .; done cd portlib-1.01 ; touch _b_
/bin/sh: 1: Syntax error: word unexpected
make[1]: *** [debian/rules:201: portlib-1.01/_b_] Error 2

Bug#894562: ITP: node-fuzzysort -- Fast SublimeText-like fuzzy search for JavaScript

[Michael Meskes]

Package: wnpp
Severity: wishlist
Owner: Michael Meskes 

* Package name: node-fuzzysort
  Version : 1.1.1.
  Upstream Author : Stephen Kamenar 
* URL : https://github.com/farzher/fuzzysort
* License : MIT
  Programming Lang: JavaScript
  Description : Fast SublimeText-like fuzzy search for JavaScript

An open source JavaScript implementation that gives results similar to
SublimeText search feature.

This is needed as a new dependency for the browserpass webextension.

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

[Adam D. Barratt]

On Sun, 2018-04-01 at 14:42 +0200, Philipp Huebner wrote:
> Hi,
> 
> Am 31.03.2018 um 23:34 schrieb Adam D. Barratt:
> > It's unclear to me that this actually affects stretch in any
> > meaningful
> >  way.
> > 
> > While the version tracking information does include the stretch
> > version
> > in the "found" list, the bug is tagged "buster sid". From reading
> > the
> > bug log, it looks like this is because the issue only occurs when
> > using
> >  GCC 7, which is not present in stretch.
> 
> that is definitely incorrect. Work colleagues of mine ran into this
> bug on plain Stretch systems, and it disappeared when using the
> patched boost packages I provided.
> 
> I cannot share the code because that's privileged information, but
> you can take my word for it. I am already providing the patched
> packages to dozens of machines via a local repository.
> 

Andreas - you tagged #883987 as "buster sid" despite the version
tracking implying that stretch was affected. Do you remember the
details as to why?

Regards,

Adam

Bug#894561: fai - Make non-existing packages fatal

[Bastian Blank]

Source: fai
Version: 5.6
Severity: important

fai currently ignores all unavaible packages during the normal install
step.  This behaviour is not configurable.

In the case of fai-diskimage, this behaviour is rarely useful, because
it usualy produces broken images and finding problems faster is usualy
the better behaviour.  For the cloud stuff I consider that a serious
problem.

Bastian

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

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

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

[Philipp Huebner]

Hi,

Am 31.03.2018 um 23:34 schrieb Adam D. Barratt:
> It's unclear to me that this actually affects stretch in any meaningful
>  way.
> 
> While the version tracking information does include the stretch version
> in the "found" list, the bug is tagged "buster sid". From reading the
> bug log, it looks like this is because the issue only occurs when using
>  GCC 7, which is not present in stretch.

that is definitely incorrect. Work colleagues of mine ran into this bug
on plain Stretch systems, and it disappeared when using the patched
boost packages I provided.

I cannot share the code because that's privileged information, but you
can take my word for it. I am already providing the patched packages to
dozens of machines via a local repository.

Obviously I would like them very much to go back to Debian so all users
can benefit from it.

Kind regards,
-- 
 .''`.   Philipp Huebner 
: :'  :  pgp fp: 6719 25C5 B8CD E74A 5225  3DF9 E5CA 8C49 25E4 205F
`. `'`
  `-





signature.asc
Description: OpenPGP digital signature

Bug#894560: pygame: Don't drop python2 package

[Jeremy Bicha]

Source: pygame
Version: 1.9.3+dfsg2-1
Severity: serious
X-Debbugs-CC:naturesha...@debian.org

Your latest upload drops the python-pygame pacakge but I count 35
packages in Debian Testing that depend on it. Please restore the
python-pygame package until all those packages no longer depend on it.

Even without a bug being filed, I believe the broken dependency issue
would have prevented this package from migrating to Testing.

Thanks,
Jeremy Bicha

Bug#894553: RM: pyosmium [arm64 armhf] -- ROM; Missing python3.6 build dependencies

[Sebastiaan Couwenberg]

Control: tags -1 - moreinfo

On 04/01/2018 02:13 PM, Mattia Rizzolo wrote:
> Control: tag -1 moreinfo
> 
> On Sun, Apr 01, 2018 at 12:43:48PM +0200, Bas Couwenberg wrote:
>> Please remove pyosmium from arm64 & armhf, the python3.6 dependency
>> chain is not installable on those architectures, and the missing builds
>> will block testing migration.
> 
> 1) is there a good reason for which pyosmium needs to migrate to testing
>right away and couldn't possibly wait a few days more?

Yes, python3.6 is already available in testing, that is sufficient to
have pyosmium working there.

> 2) arm64 is already good again, waiting a couple more hours would have
>been enough indeed

armhf still looks hopeless.

> 3) I'm quite sure we want python3.6 to be installable on those
>architectures, so I'm very positive the underlying issue will be
>fixed given enough time, instead of having to workaround it like you
>are trying to do.

I don't want users of pyosmium to have to wait for that. They primarily
use amd64 and shouldn't be penalised by issues in Debians other
architectures.

Kind Regards,

Bas



signature.asc
Description: OpenPGP digital signature