Bug#844719: Out of bounds read when using a malformated pcap file

[Lucian Cojocar]

Package: tcptrace
Version: 6.6.7-4.1
Severity: normal
File: /usr/bin/tcptrace

Dear Maintainer,

   * What led up to the situation?
While developing a new fuzzer we discovered this bug.

   * What outcome did you expect instead?
We expected the program not to crash. I'm attaching an input file that
triggers this bug. The bug can be triggered on x86_64 as well.

Here's a stack trace:
"""
Ostermann's tcptrace -- version 6.6.7 -- Thu Nov  4, 2004

TCP packet 10: reserved bits are not all zero.
Further warnings disabled, use '-w' for more info

Program received signal SIGSEGV, Segmentation fault.
0x08058ecc in MemCpy (vp1=0x80caab0, vp2=0x80baab6, n=4294699681) at
tcptrace.c:2620
2620*p1++=*p2++;
(gdb) bt
#0  0x08058ecc in MemCpy (vp1=0x80caab0, vp2=0x80baab6, n=4294699681) at
tcptrace.c:2620
#1  0x080558c4 in callback (user=0x0, phdr=0xb1bc, buf=0x80baaa8 "")
at tcpdump.c:166
#2  0xb7f4ba18 in pcap_offline_read (p=0x80ba8a0, cnt=1,
callback=0x8055850 ,
user=0x0) at ./savefile.c:404
#3  0xb7f3c8f6 in pcap_dispatch (p=0x80ba8a0, cnt=1, callback=0x8055850
,
user=0x0) at ./pcap.c:829
#4  0x080556d8 in pread_tcpdump (ptime=0x80a75c8 ,
plen=0xb29c,
ptlen=0xb2a0, pphys=0xb298, pphystype=0xb294,
ppip=0xb28c,
pplast=0xb2a4) at tcpdump.c:247
#5  0x08058098 in ProcessFile (filename=0x80caab0 "E`") at tcptrace.c:966
#6  0x08049fba in main (argc=1, argv=0xb4f4) at tcptrace.c:785
"""


-- System Information:
Debian Release: 8.5
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable')
Architecture: i386 (i686)

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

Versions of packages tcptrace depends on:
ii  libc6   2.19-18+deb8u4
ii  libpcap0.8  1.6.2-2

Versions of packages tcptrace recommends:
ii  tcpdump  4.6.2-5+deb8u1
ii  xplot-xplot.org  0.90.7.1-2

tcptrace suggests no packages.

-- debconf-show failed


tcptrace-2016-05-18T02-38-38.155527.pcap
Description: tcptrace-2016-05-18T02-38-38.155527.pcap


signature.asc
Description: OpenPGP digital signature

Bug#844618: ITP: bornagain -- Simulating and fitting X-ray and neutron small-angle scattering at grazing incidence

[Mika Pflüger]

Hi Frederic,

I was just accepted in the debian-science team on alioth, my login is 
mikapfl-guest.
Thanks for creating the git repository on alioth, I'll commit what I've 
done so far (mostly some metadata like watchfile and copyright) using 
git-buildpackage soon.
bornagain is a pretty complex program, with a C++ shared library, a qt 
GUI and bindings for python as well as python3. I'll first try to build 
one monolithic package with GUI, library and python bindings, and then 
see how to split it and build the python3 bindings as well.
Another problem might be the bundled libraries, the upstream tarball is 
bundling patched versions of gtest, some fitting routines from other 
packages like ROOT and some themes and widgets from qt.


Cheers

Mika

Am 2016-11-18 08:07, schrieb PICCA Frederic-Emmanuel:

Hello Mika,

VEry glade to hear that you decided to integrate bornagain into Debian.

I created a git repository for it under

ssh://git.debian.org/git/debian-science/packages/bornagain.git

do you have an alioth account, and are you already member of the
debian-science team ?


Cheers


Frederic

Bug#844718: kmail: Kmail cannot be synchronized between 2 computers anymore

[Joerg Hau]

Package: kmail
Version: 4:4.14.1-1
Severity: important

Dear Maintainer,

I am using kmail on different computers (in particular: 1 desktop and 1 laptop) 
and I need to keep all mail synchronized between these computers. That is all 
:-)

In all previous kmail versions including those in Debian 7, it was possible to 
transfer/synchronize the complete mail settings and folders between different 
computers. I simply used to quit kmail, used 'unison' to sync the relevant 
files and directories from pc-1 to pc-2, continued to work on pc-2 (think 
travel) and then sync back from pc-2 to pc-1. This took only seconds.

With the introduction of a different kmail/akonadi/... architecture in Debian 
8, this is no longer possible. The relevant data seem now now be spread across 
a multitude of databases that are all "live" as soon as I am logged in, i.e. I 
cannot sync them - some software (akonadi? baloo?) starts as soon as I log in 
and keeps these files open.

=> How can I get back to a state where all mail on my notebook computer could 
be kept identical with that on my desktop? 

Notes:

o the key problem is the non-sync of the "local" folders since I transfer lots 
of mails from IMAP to "local" folders, and these must stay in sync. (hey, 
syncing IMAP is not a problem ;-)

o I have tried 'pimsettingexporter' but this was a major mess - (a) it takes a 
very long time to create the archive, and (2) on unpacking, both the mail 
folders and account settings/names are lost/garbled. This is not a valid option 
:-/

   * What led up to the situation?

 The switch to a different kmail/akonadi/... architecture in Debian 8. 


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

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

Versions of packages kmail depends on:
ii  kde-runtime   4:4.14.2-2
ii  kdepim-runtime4:4.14.2-3
ii  kdepimlibs-kio-plugins4:4.14.2-2+deb8u2
ii  libakonadi-calendar4  4:4.14.2-2+deb8u2
ii  libakonadi-contact4   4:4.14.2-2+deb8u2
ii  libakonadi-kde4   4:4.14.2-2+deb8u2
ii  libakonadi-kmime4 4:4.14.2-2+deb8u2
ii  libakonadiprotocolinternals1  1.13.0-2+deb8u2
ii  libc6 2.19-18+deb8u6
ii  libcalendarsupport4   4:4.14.1-1
ii  libfollowupreminder4  4:4.14.1-1
ii  libgcc1   1:4.9.2-10
ii  libgpgme++2   4:4.14.2-2+deb8u2
ii  libgrantlee-core0 0.4.0-2
ii  libincidenceeditorsng44:4.14.1-1
ii  libkabc4  4:4.14.2-2+deb8u2
ii  libkalarmcal2 4:4.14.2-2+deb8u2
ii  libkcalcore4  4:4.14.2-2+deb8u2
ii  libkcalutils4 4:4.14.2-2+deb8u2
ii  libkcmutils4  4:4.14.2-5+deb8u1
ii  libkdecore5   4:4.14.2-5+deb8u1
ii  libkdepim44:4.14.1-1
ii  libkdeui5 4:4.14.2-5+deb8u1
ii  libkio5   4:4.14.2-5+deb8u1
ii  libkleo4  4:4.14.1-1
ii  libkmanagesieve4  4:4.14.1-1
ii  libkmime4 4:4.14.2-2+deb8u2
ii  libknewstuff3-4   4:4.14.2-5+deb8u1
ii  libknotifyconfig4 4:4.14.2-5+deb8u1
ii  libkontactinterface4a 4:4.14.2-2+deb8u2
ii  libkparts44:4.14.2-5+deb8u1
ii  libkpgp4  4:4.14.1-1
ii  libkpimidentities44:4.14.2-2+deb8u2
ii  libkpimtextedit4  4:4.14.2-2+deb8u2
ii  libkpimutils4 4:4.14.2-2+deb8u2
ii  libkprintutils4   4:4.14.2-5+deb8u1
ii  libksieveui4  4:4.14.1-1
ii  libktnef4 4:4.14.2-2+deb8u2
ii  libmailcommon44:4.14.1-1
ii  libmailimporter4  4:4.14.1-1
ii  libmailtransport4 4:4.14.2-2+deb8u2
ii  libmessagecomposer4   4:4.14.1-1
ii  libmessagecore4   4:4.14.1-1
ii  libmessagelist4   4:4.14.1-1
ii  libmessageviewer4 4:4.14.1-1
ii  libpimcommon4 4:4.14.1-1
ii  libqt4-dbus   4:4.8.6+git64-g5dc8b2b+dfsg-3+deb8u1
ii  libqt4-network4:4.8.6+git64-g5dc8b2b+dfsg-3+deb8u1
ii  libqt4-xml4:4.8.6+git64-g5dc8b2b+dfsg-3+deb8u1
ii  libqtcore44:4.8.6+git64-g5dc8b2b+dfsg-3+deb8u1
ii  libqtgui4 4:4.8.6+git64-g5dc8b2b+dfsg-3+deb8u1
ii  libqtwebkit4  2.3.4.dfsg-3
ii  libsendlater4 4:4.14.1-1
ii  libsolid4 4:4.14.2-5+deb8u1
ii  libstdc++64.9.2-10
ii  libtemplateparser44:4.14.1-1
ii  perl  5.20.2-3+deb8u6

Versions of packages kmail recommends:
ii  

Bug#844717: pydb suggests outdated emacs

[Martin Pitt]

Package: pydb
Version: 1.26-2
Tags: patch
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu ubuntu-patch zesty

Hello,

In https://launchpad.net/bugs/1537938 it was reported that pydb
suggests an outdated emacs version (22). Jeff submitted a patch for
this (attached).

Thanks for considering,

Martin

-- 
Martin Pitt| http://www.piware.de
Ubuntu Developer (www.ubuntu.com)  | Debian Developer  (www.debian.org)
diff -Naur pydb-1.26/debian/changelog pydb-next/debian/changelog
--- pydb-1.26/debian/changelog	2015-12-11 17:09:31.0 -0500
+++ pydb-next/debian/changelog	2016-10-18 20:56:24.223941838 -0400
@@ -1,3 +1,10 @@
+pydb (1.26-2ubuntu1) yakkety; urgency=low
+
+  * changed emacs to actually available emacs
+  * nmu update
+
+ -- Jeff Cliff   Tue, 17 Oct 2016 12:00:00 +0600
+
 pydb (1.26-2) unstable; urgency=low
 
   * Team Upload
diff -Naur pydb-1.26/debian/control pydb-next/debian/control
--- pydb-1.26/debian/control	2015-12-11 17:04:05.0 -0500
+++ pydb-next/debian/control	2016-10-18 20:54:53.073612427 -0400
@@ -13,7 +13,7 @@
 Package: pydb
 Architecture: all
 Depends: ${python:Depends}
-Suggests: ddd, emacs22
+Suggests: ddd, emacs25
 Description: An enhanced Python command-line debugger
  Pydb is a command-line debugger for Python. It is based on the standard
  Python debugger pdb, but has a number of added features. Particularly, it is
diff -Naur pydb-1.26/debian/pydb.emacsen-remove pydb-next/debian/pydb.emacsen-remove
--- pydb-1.26/debian/pydb.emacsen-remove	2015-12-11 16:40:06.0 -0500
+++ pydb-next/debian/pydb.emacsen-remove	2016-10-18 20:54:40.865300218 -0400
@@ -3,8 +3,23 @@
 
 FLAVOR=$1
 PACKAGE=pydb
+EMACS=no
+
+if [ ${FLAVOR} = emacs22 ] ; then
+	EMACS="yes"
+fi
+if [ ${FLAVOR} = emacs23 ] ; then
+	EMACS="yes"
+fi
+if [ ${FLAVOR} = emacs24 ] ; then
+	EMACS="yes"
+fi
+if [ ${FLAVOR} = emacs25 ] ; then
+	EMACS="yes"
+fi
+
+if [ ${EMACS} = "yes" ] ; then
 
-if [ ${FLAVOR} = emacs22 ]; then
 if test -x /usr/sbin/install-info-altdir; then
 echo remove/${PACKAGE}: removing Info links for ${FLAVOR}
 install-info-altdir --quiet --remove --dirname=${FLAVOR} /usr/share/info/${PACKAGE}.info.gz
@@ -12,4 +27,5 @@
 
 echo remove/${PACKAGE}: purging byte-compiled files for ${FLAVOR}
 rm -rf /usr/share/${FLAVOR}/site-lisp/${PACKAGE}
+
 fi

Bug#844716: speedtest-cli: please consider packaging 1.0.0

[Félix Sipma]

Package: speedtest-cli
Version: 0.3.4-1
Severity: wishlist

Upstream recently released 1.0.0. Could you please consider packaging it?


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

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

Versions of packages speedtest-cli depends on:
ii  python2.7.11-2
ii  python-pkg-resources  28.7.1-1

speedtest-cli recommends no packages.

speedtest-cli suggests no packages.

-- no debconf information


signature.asc
Description: PGP signature

Bug#844713: ITP: partman-swapfile -- add support for creating swapfiles

[Philipp Kern]

On 18.11.2016 12:44, Dimitri John Ledkov wrote:
> Another thing I am investigating is moving away from swap partitions to
> swap files, on non-lvm installations. This will involve tweaking the
> default partman-auto recipes & the no-swap warning.

Note that you should then also check that the memory available to the
installer is sufficient to proceed without swap. (Especially for locales
generation and such.)

Kind regards
Philipp Kern



signature.asc
Description: OpenPGP digital signature

Bug#844715: openssl: segfault in shlibloadtest (observed on x32) due to dlopen/dlclose/OPENSSL_atexit/OPENSSL_cleanup ordering

[Thorsten Glaser]

Source: openssl
Version: 1.1.0c-1
Severity: important

[…]
ok 1 - running secmemtest
ok
../util/shlib_wrap.sh ./shlibloadtest -crypto_first libcrypto.so libssl.so => 
139

#   Failed test 'running shlibloadtest -crypto_first'
#   at ../test/recipes/90-test_shlibload.t line 30.
../util/shlib_wrap.sh ./shlibloadtest -ssl_first libcrypto.so libssl.so => 0
../util/shlib_wrap.sh ./shlibloadtest -just_crypto libcrypto.so libssl.so => 0
# Looks like you failed 1 test of 3.
../test/recipes/90-test_shlibload.t 
1..3
not ok 1 - running shlibloadtest -crypto_first
Success
ok 2 - running shlibloadtest -ssl_first
Success
ok 3 - running shlibloadtest -just_crypto
Dubious, test returned 1 (wstat 256, 0x100)
Failed 1/3 subtests 
[…]

The cause here seems to be:

(pbuild24392)root@tglase:/tmp/buildd/openssl-1.1.0c # export SHELL=/bin/sh 
LD_LIBRARY_PATH=/tmp/buildd/openssl-1.1.0c:/usr/lib/libeatmydata:/usr/lib/libeatmydata
(pbuild24392)root@tglase:/tmp/buildd/openssl-1.1.0c # gdb --args 
test/shlibloadtest -crypto_first libcrypto.so libssl.so
GNU gdb (Debian 7.10-1.1) 7.10
Copyright (C) 2015 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-linux-gnux32".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
.
Find the GDB manual and other documentation resources online at:
.
For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from test/shlibloadtest...done.
(gdb) r
Starting program: /tmp/buildd/openssl-1.1.0c/test/shlibloadtest -crypto_first 
libcrypto.so libssl.so
warning: linux_ptrace_test_ret_to_nx: Cannot PTRACE_PEEKUSER: Input/output error
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnux32/libthread_db.so.1".

Program received signal SIGSEGV, Segmentation fault.
0xf6745c50 in ?? ()
(gdb) bt
#0  0xf6745c50 in ?? ()
#1  0xf6ac51c5 in OPENSSL_cleanup () at crypto/init.c:395
#2  0xf724fece in __cxa_finalize () from /lib/x86_64-linux-gnux32/libc.so.6
#3  0xf69d80d1 in __do_global_dtors_aux () from 
/tmp/buildd/openssl-1.1.0c/libcrypto.so
#4  0xce90 in ?? ()
Backtrace stopped: previous frame identical to this frame (corrupt stack?)
(gdb) frame 1
#1  0xf6ac51c5 in OPENSSL_cleanup () at crypto/init.c:395
395 currhandler->handler();
(gdb) list
390  */
391 ossl_init_thread_stop(ossl_init_get_thread_local(0));
392
393 currhandler = stop_handlers;
394 while (currhandler != NULL) {
395 currhandler->handler();
396 lasthandler = currhandler;
397 currhandler = currhandler->next;
398 OPENSSL_free(lasthandler);
399 }
(gdb) print *currhandler
$1 = {handler = 0xf6745c50, next = 0x0}
(gdb) x/i currhandler->handler
   0xf6745c50:  Cannot access memory at address 0xf6745c50

So, when does that value get written?

(gdb) x/4xc currhandler
0x5675b170: 80 'P'  92 '\\' 116 't' -10 '\366'

This looks only vaguely ASCII-ish, so that’s not like it.

The memory map of the process is:

tglase@tglase:~ $ sudo cat /proc/13583/maps
56555000-56556000 r-xp  fd:00 4511408
/var/cache/pbuilder/build/cow.24367/tmp/buildd/openssl-1.1.0c/test/shlibloadtest
56755000-56756000 r--p  fd:00 4511408
/var/cache/pbuilder/build/cow.24367/tmp/buildd/openssl-1.1.0c/test/shlibloadtest
56756000-56757000 rw-p 1000 fd:00 4511408
/var/cache/pbuilder/build/cow.24367/tmp/buildd/openssl-1.1.0c/test/shlibloadtest
56757000-56779000 rw-p  00:00 0  [heap]
f6982000-f6bbf000 r-xp  fd:00 4511417
/var/cache/pbuilder/build/cow.24367/tmp/buildd/openssl-1.1.0c/libcrypto.so.1.1
f6bbf000-f6dbf000 ---p 0023d000 fd:00 4511417
/var/cache/pbuilder/build/cow.24367/tmp/buildd/openssl-1.1.0c/libcrypto.so.1.1
f6dbf000-f6dd1000 r--p 0023d000 fd:00 4511417
/var/cache/pbuilder/build/cow.24367/tmp/buildd/openssl-1.1.0c/libcrypto.so.1.1
f6dd1000-f6dda000 rw-p 0024f000 fd:00 4511417
/var/cache/pbuilder/build/cow.24367/tmp/buildd/openssl-1.1.0c/libcrypto.so.1.1
f6dda000-f6dde000 rw-p  00:00 0 
f6dde000-f6dfe000 r-xp  fd:00 2304977
/var/cache/pbuilder/build/cow.24367/lib/x86_64-linux-gnux32/libtinfo.so.5.9
f6dfe000-f6ffe000 ---p 0002 fd:00 2304977
/var/cache/pbuilder/build/cow.24367/lib/x86_64-linux-gnux32/libtinfo.so.5.9
f6ffe000-f700 r--p 0002 fd:00 

Bug#844633: coz-profiler: Cannot run build tests (insufficient permissions for perf)

[Lluís Vilanova]

Petter Reinholdtsen writes:

> [Lluís Vilanova]
>> The package currently fails to run its tests during build due to
>> insufficient permissions to access Linux's perf interface.

> Is there some way to figure out if such permissions are missing or not?

> On my machine, where the build work, the value of 
> /proc/sys/kernel/perf_event_paranoid is '1', so '0' is not required.

> I notice the autobuilders work, the ci.debian.org builders work, but the
> reproducable build builders do not.  No idea what the difference is.

I've rechecked, and things seem to be a bit different...

For some reason my kernel (4.7.0-1-amd64) ignores changes through the file
system. It's more reliable to use:

  /sbin/sysctl kernel.perf_event_paranoid
  sudo /sbin/sysctl kernel.perf_event_paranoid=

Now, I've tried on a nother machine, and (strangely) the kernel starts with a
perf paranoid level of 3, which is not even documented as a valid value on
Linux's source code.

Getting it down to 2 is sufficient to run the check successfully.

A possible check could be:

  if [ `/sbin/sysctl kernel.perf_event_paranoid` -gt 2 ]; then
  echo "ERROR: perf is too paranoid for us"
  exit 1
  fi

This would build-depend on procps (which installs sysctl).

Cheers,
  Lluis

Bug#844710: [Pkg-zsh-devel] Bug#844710: autocorrection suggested rm for typing mr without typing "y"

[Axel Beckert]

Control: tag -1 + confirmed
Control: found -1 5.0.7-5
Control: found -1 4.3.17-1

Hi Martin,

Martin Steigerwald wrote:
> ms@intraws:~/Backup/Mail/Linux> mr kernel-ml_archive.gz 
> kernel-ml_archive_2014-1b.gz
> zsh: correct 'mr' to 'rm' [nyae]?
> rm: das Entfernen von „kernel-ml_archive_2014-1b.gz“ ist nicht möglich: Datei 
> oder Verzeichnis nicht gefunden
> 
> I didn´t type yes, as when I type "y", it is shown on command line:
> 
> ms@intraws:~/Backup/Mail/Linux#1> LANG=C mr test
> zsh: correct 'mr' to 'rm' [nyae]? y
> rm: cannot remove 'test': No such file or directory
> 
> And I really didn´t type "y" there, I am pretty sure of that, but I may
> have hit another key by accident.

Indeed scary.

>From the output it look to as if "Enter" had been pressed on a
first glance. But if I press "Enter" (on Sid at least) it shows an "n"
instead afterwards. (Since I have mr installed, I tested it with "rmm"
which is only available if nmh or mailutils-mh is installed.)

After some experimenting I noticed that while pressing Enter is
equivalent to pressing "n" and also prints an "n", pressing the space
bar is equivalent to "y" _without_ printing a "y".

So you very likely hit the space bar accidentially.

I was able to reproduce this behaviour on Debian 7 Wheezy, Debian 8
Jessie and Debian Sid.

> 2. Do not autocorrect to dangerous commands.

You might want to have a look at CORRECT_IGNORE in zshall(1).

CORRECT_IGNORE=rm did the trick for me.

> I think this is an upstream issue and would also report it there, if
> it helps.

Thanks for the offer, appreciated. And yes, I also think that is very
likely an upstream issue, so please do. Write an e-mail to
zsh-work...@zsh.org for that.

Regards, Axel
-- 
 ,''`.  |  Axel Beckert , http://people.debian.org/~abe/
: :' :  |  Debian Developer, ftp.ch.debian.org Admin
`. `'   |  4096R: 2517 B724 C5F6 CA99 5329  6E61 2FF9 CD59 6126 16B5
  `-|  1024D: F067 EA27 26B9 C3FC 1486  202E C09E 1D89 9593 0EDE

Bug#841247: [Calendarserver-maintainers] Bug#841247: calypso: UnicodeDecodeError when importing an .ics

[Mathias Behrle]

* Guido Günther: " Re: [Calendarserver-maintainers] Bug#841247: calypso:
  UnicodeDecodeError when importing an .ics" (Thu, 17 Nov 2016 20:22:46 +0100):

> On Thu, Nov 17, 2016 at 01:20:59PM +0100, Mathias Behrle wrote:
> > * Guido Günther: " Re: [Calendarserver-maintainers] Bug#841247: calypso:
> >   UnicodeDecodeError when importing an .ics" (Wed, 2 Nov 2016 21:30:21
> > +0100):
> > 
> > Hi Guido,
> >   
> > > Hi Mathias,
> > > 
> > > On Wed, Nov 02, 2016 at 01:14:02PM +0100, Mathias Behrle wrote:  
> > > > control: affects -1 + tryton-modules-calendar
> > > > tryton-modules-calendar-classification
> > > > tryton-modules-calendar-scheduling tryton-modules-calendar-todo
> > > > tryton-modules-party-vcarddav tryton-meta   
> > > > > From: Guido Günther 
> > > > > To: Jens Reyer , 841...@bugs.debian.org
> > > > > Subject: Re: Bug#841247: calypso: UnicodeDecodeError when importing
> > > > > an .ics Date: Sun, 23 Oct 2016 12:28:37 +0200
> > > >  
> > > > 
> > > > Hi Guido,
> > > > 
> > > > > The unicode handling for python 2.7 got broken in upstream commit
> > > > > 
> > > > > 
> > > > > https://github.com/eventable/vobject/commit/b3f9bbcf4cf222f0dda3ac29f96364c5d7ab5f16
> > > > > 
> > > > > Let's see if upstream cares at all. If not we should rather drop the
> > > > > python2.7 version for stretch.
> > > > 
> > > > There are currently 6 Tryton modules affected as rdepends of
> > > > python-vobject. There are still some bits in the Tryton framework
> > > > lacking Python3 support, so it is currently not possible to switch the
> > > > whole Tryton stuff to Python3 (and I suppose this won't be the case for
> > > > stretch). Dropping the Python2 version of python-vobject would
> > > > seriously hurt those Tryton modules. So please let's find a way to keep
> > > > the Python2 version in the archive (for stretch).
> > > 
> > > It breaks calyso as well which I'd rather see in the archive than
> > > removed.
> > > 
> > > The bug is fixable. Someone needs to sit down and cook a patch. I have
> > > it on the TODO list but work is piling up at the moment - but I hope to
> > > get it done til the end of the year.  
> > 
> > While I am currently not able to assist in making a patch I had a quite
> > intensive test with a complete Tryton calendar setup using vobject 0.9.3
> > under Python2. It is working like a charm. So it seems the Tryton modules
> > are not *directly* affected by this bug.
> > 
> > I would want to elaborate the different measures to take now (time is
> > running away and the autoremoval is scheduled in 27 days).
> > 
> > For me the severity of this bug is definitely important, not grave. I think
> > we should downgrade the severity immediately. Would you agree with this?

You didn't answer this question. Severity grave was set explicitely by you, not
by the original bug reporter, hence I am asking you to re-consider the
situation with the new information (see above). According to my tests this
severity is wrong, but severity important is just correct:

A bug which has a major effect on the usability of a package, without rendering
it completely unusable to everyone.

What's your opinion on this one?

> > As another measure to avoid the autoremoval of basically unaffected
> > Tryton modules it could be argued, that calypso is not ready for current
> > vobject and reassign the bug to calypso.  
> 
> This is not related to calypso. The ABI has changed significantly.

There was a jump from 0.8 to 0.9 in python-vobject, which in many softwares
means, that ABI breakage must be expected. 
 
> We're miles away from an autoremoval so keep calm ;)

It is not my way to keep calm, if problems can be solved. And you said,
that you only have time for a fix by the end of the year, which is way
after the autoremoval date.

Sorry if stepping on your toes, it is for sure not my intention to create more
work load for you. But this issue can be solved right now with respect to the
tryton-modules, why I am asking you again to agree on a correct bug severity.

Cheers,

Mathias


-- 

Mathias Behrle
PGP/GnuPG key availabable from any keyserver, ID: 0xD6D09BE48405BBF6
AC29 7E5C 46B9 D0B6 1C71  7681 D6D0 9BE4 8405 BBF6

Bug#844709: [Pkg-freeipa-devel] Bug#844709: Bug#844709: certmonger: Certmonger runs its programs from nonexistent path

[Michal Kašpar]

No. After start/stop (without editing the cas/* files) the problem
remains.

-- 
Michal Kašpar

Bug#843402: reprepro cannot handle .changes files that reference .buildinfo files

[Guillem Jover]

Hi!

On Sun, 2016-11-06 at 14:16:14 +0100, Helmut Grohne wrote:
> Package: reprepro
> Version: 4.17.1-1
> Severity: important
> User: helm...@debian.org
> Usertags: rebootstrap
> 
> Since dpkg 1.18.11, a .buildinfo file is generated as part of package
> builds and referenced by .changes files. Supplying such a .changes file
> to "reprepro include" results in an error:
> 
> | Unknown file type: '2d3e9992648837b6a4a8a5b819e6da8e 4791 devel optional 
> binutils_2.27.51.20161105-1_20161106T104833z-2d3e9992.buildinfo', assuming 
> source format...
> | .changes put in a
> | distribution not listed within it!
> | Ignoring as --ignore=wrongdistribution given.
> | 'binutils_2.27.51.20161105-1_20161106T104833z-2d3e9992.buildinfo' looks 
> like part of an source package, but no dsc file listed in the .changes file!
> | There have been errors! 
>   
>   
> 
> So any workflow based on importing .changes files from unstable (soon
> stretch) is now broken.

I've just prepared a patch supposedly fixing this, but I've never used
reprepro and don't even know how it works, so it's just built-tested.
We are now performing some tests, and will update the report once this
is confirmed to work.

(The preliminary and perhaps non-working patch can be found for now at
https://www.hadrons.org/~guillem/tmp/0001-Add-preliminary-.buildinfo-support.patch)

Thanks,
Guillem

Bug#844713: ITP: partman-swapfile -- add support for creating swapfiles

[Steve McIntyre]

On Fri, Nov 18, 2016 at 11:44:25AM +, Dimitri John Ledkov wrote:
>Package: wnpp
>Owner: Dimitri John Ledkov 
>Severity: wishlist
>
>* Package name: partman-swapfile
>  Version : 1
>  Upstream Author : d-i team
>* URL or Web page : d-i
>* License : GPL
>  Description : add support for creating swapfiles
>
>I am working on minimising number of partitions used in the default
>instalations in Ubuntu.

Might I ask why?

-- 
Steve McIntyre, Cambridge, UK.st...@einval.com
"Further comment on how I feel about IBM will appear once I've worked out
 whether they're being malicious or incompetent. Capital letters are forecast."
 Matthew Garrett, http://www.livejournal.com/users/mjg59/30675.html

Bug#768495: Bug looks RC and is also in jessie

[Adrian Bunk]

Control: severity -1 serious
Countrl: found -1 2.14-1.1
Control: fixed -1 2.16-1
Control: close -1

Based on the initial bug report, this looks like an issue where the
fix should also be added to the package in jessie.

cu
Adrian

-- 

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

Bug#844709: [Pkg-freeipa-devel] Bug#844709: Bug#844709: certmonger: Certmonger runs its programs from nonexistent path

[Timo Aaltonen]

On 18.11.2016 13:33, Michal Kašpar wrote:
> # grep -r 'usr\/lib' /var/lib/certmonger/cas
> /var/lib/certmonger/cas/20141030220219-
> 3:ca_external_helper=/usr/lib/x86_64-linux-gnu/certmonger/dogtag-ipa-
> renew-agent-submit
> 
> So yes. They are there. Should I delete them or change the path?

Does stop/start of certmonger fix it? I wonder if postinst should mangle
them..


-- 
t

Bug#844714: python-pycparser: Not installable

[Ondřej Nový]

Package: python-pycparser
Version: 2.17-1
Severity: grave
Justification: renders package unusable

Hi,

this package can't be installed:

The following packages have unmet dependencies:
 python-pycparser : Depends: python-ply-lex-3.5 but it is not
 installable
 Depends: python-ply-yacc-3.5 but it is not
 installable

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

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

Bug#844713: ITP: partman-swapfile -- add support for creating swapfiles

[Dimitri John Ledkov]

Package: wnpp
Owner: Dimitri John Ledkov 
Severity: wishlist

* Package name: partman-swapfile
  Version : 1
  Upstream Author : d-i team
* URL or Web page : d-i
* License : GPL
  Description : add support for creating swapfiles

I am working on minimising number of partitions used in the default
instalations in Ubuntu. One of the things I have done already in Ubuntu is to
tweak and not use dedicated /boot partition for non-encrypted LVM based
installations. Simply by tweaking the partman-auto recipes, on
architectures/bootloaders that support booting off LVM.

Another thing I am investigating is moving away from swap partitions to
swap files, on non-lvm installations. This will involve tweaking the
default partman-auto recipes & the no-swap warning.

However, to provide swapfiles out of the box I wrote this
partman-swapfile module which hooks into /lib/partman/finish.d to create
/target/swapfile with an appropriate stanza in /target/etc/fstab. Care
is taken not to create swapfiles uncessory, reuse existing one, or do
nothing if a swap partition is already present, or swapfiles not
supported on a given filesystem (e.g. btrfs).

There are two control options to configure the size of the
swapfile. Absolute size, and percentage of free space on the
rootfs. The defaults are 2GB and 5%, meaning the swapfile will be 2GB in
size or 5% of the free space on rootfs, whichever is lower. Setting the
size or percentage to zero will skip creating the swapfile. This is a
strategy to make sure there is some swap available, without wasting too
much of disk space on high-memory-to-disk ratio systems (e.g. 1TB of RAM
with a 200GB hard drive).

I am not at all sure if this functionality is at all welcomed, needed,
or will generate any interest. I do not know if it's wanted to be
available by default in Debian's d-i. At the moment I created a git
repository in the d-i team, and plan to upload this to experimental for
people to try this out.

On the implementation side, swapfile is allocated using fallocate (if
avaialble and target filesystem creates files without holes using
fallocate) otherwise "slow" dd is used. This makes swapfile creation
really quick on ext4 rootfs.

All the glory details are here:
https://anonscm.debian.org/cgit/d-i/partman-swapfile.git/tree/finish.d

Regards,

Dimitri.

Bug#836126: trafficserver: add Build-Depends to ensure tstop builds

[Jean Baptiste Favre]

Hello,

Thanks for your report.
I'll have a look at it.

Please note that tstop has been renamed to traffic_top since 2013

Regards,
JB



signature.asc
Description: OpenPGP digital signature

Bug#844220: maybe not /usr-merged but 0700 for / could be the culprit here

[Marco d'Itri]

On Nov 18, Holger Levsen  wrote:

> someone mailed me privately and pointed me to this forum post
> https://bbs.archlinux.org/viewtopic.php?id=186056=2 which made me
> realize that debootstrap had another change: TARGET is now created with
> 0700 permissions and not 0755 anymore, though I couldnt find this in
> debootstrap's changelog, so maybe I'm confused.
I can't see how this could be related to the usrmerge patch.

-- 
ciao,
Marco


signature.asc
Description: PGP signature

Bug#838768: sbuild-createchroot should let me re-create an existing chroot/tarball

[Ben Finney]

Control: found -1 sbuild/0.72.0-2
Control: tags -1 - moreinfo

On 24-Sep-2016, Julien Cristau wrote:

> I want to be able to update a sbuild chroot by re-creating the tarball
> from scratch, rather than running sbuild-update.  sbuild-createchroot
> used to let me do that by creating a new tarball and deleting the new
> duplicate config, but that doesn't seem to work anymore:
> chroot with name sid-amd64-sbuild already exists at 
> /usr/sbin/sbuild-createchroot line 214, <$pipe> line 7.

I get the same behaviour:

=
$ sudo rm /etc/sbuild/chroot/unstable-amd64-sbuild
rm: cannot remove '/etc/sbuild/chroot/unstable-amd64-sbuild': No such file or 
directory

$ sudo rm -r /srv/chroot/unstable-amd64-sbuild/
rm: cannot remove '/srv/chroot/unstable-amd64-sbuild/': No such file or 
directory

$ sudo sbuild-createchroot unstable /srv/chroot/unstable-amd64-sbuild/ 
http://httpredir.debian.org/debian/
chroot with name unstable-amd64-sbuild already exists at 
/usr/sbin/sbuild-createchroot line 214, <$pipe> line 1.
=


On 10-Nov-2016, Johannes Schauer wrote:

> so... is there then still a bug?

The bug in the above behaviour is:

* The obvious filesystem entries where the chroot might “already
  exist” do not actually exist, yet the tool refuses with the above
  message anyway.

* The user needs to make a decision about how to resolve the problem,
  but the message gives no help in finding what problematic thing
  “already exists”.

Both those, IMO, need to be correct to resolve this bug.

-- 
 \“I took a course in speed waiting. Now I can wait an hour in |
  `\ only ten minutes.” —Steven Wright |
_o__)  |
Ben Finney 


signature.asc
Description: PGP signature

Bug#844709: [Pkg-freeipa-devel] Bug#844709: certmonger: Certmonger runs its programs from nonexistent path

[Michal Kašpar]

# grep -r 'usr\/lib' /var/lib/certmonger/cas
/var/lib/certmonger/cas/20141030220219-
3:ca_external_helper=/usr/lib/x86_64-linux-gnu/certmonger/dogtag-ipa-
renew-agent-submit

So yes. They are there. Should I delete them or change the path?

> That's weird, configure is told to use --libexecdir=/usr/lib.. are
> you
> sure you don't have old files in /var/lib/certmonger/cas? Grep for
> 'usr/lib'.

-- 
Michal Kašpar

Bug#810158: This needs to be fixed

[Marga Manterola]

Control: tags -1 -wontfix

With the change in debootstrap, this bug is now preventing ksh from getting
installed in a fresh installation.  In my case, this is even causing my
automated install to fail because there's a package that tries to pull in
ksh and so everything fails.

The patch is pretty straightforward and it's basically the same that has
already been applied in mksh:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=807185

Please fix this.

Thanks.

-- 
Cheers,
Marga

Bug#844712: nginx: French debconf templates translation

[Julien Patriarca]

Package: nginx
Version: N/A
Severity: wishlist
Tags: patch l10n


Please find attached the french debconf templates translation, proofread by the
debian-l10n-french mailing list contributors.

This file should be put as debian/po/fr.po in your package build tree.



-- System Information:
Debian Release: stretch/sid
  APT prefers testing
  APT policy: (900, 'testing'), (90, 'unstable')
Architecture: amd64 (x86_64)

Kernel: Linux 4.7.0-1-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
# Translation of nginx debconf templates to French
# Copyright (C) 2016 Christos Trochalakis
# This file is distributed under the same license as the nginx package.
# Chrirtos Trochalakis , 2016.
# Julien Patriarca , 2016.
msgid ""
msgstr ""
"Project-Id-Version: nginx\n"
"Report-Msgid-Bugs-To: ng...@packages.debian.org\n"
"POT-Creation-Date: 2016-10-04 20:03+0300\n"
"PO-Revision-Date: 2016-11-02 09:52+0100\n"
"Language: fr\n"
"MIME-Version: 1.0\n"
"Content-Type: text/plain; charset=UTF-8\n"
"Content-Transfer-Encoding: 8bit\n"
"Last-Translator: Julien Patriarca \n"
"Language-Team: French \n"
"X-Generator: Poedit 1.8.11\n"

#. Type: note
#. Description
#: ../nginx-common.templates:1001
msgid "Possible insecure nginx log files"
msgstr "Certains fichiers de journaux semblent non sécurisés"

#. Type: note
#. Description
#: ../nginx-common.templates:1001
msgid ""
"The following log files under /var/log/nginx directory are symlinks owned by "
"www-data:"
msgstr ""
"Les fichiers de journaux suivants se trouvant dans le dossier /var/log/nginx "
"sont des liens symboliques qui appartiennent à www-data :"

#. Type: note
#. Description
#: ../nginx-common.templates:1001
msgid "${logfiles}"
msgstr "${logfiles}"

#. Type: note
#. Description
#: ../nginx-common.templates:1001
msgid ""
"Since nginx 1.4.4-4 /var/log/nginx was owned by www-data. As a result www-"
"data could symlink log files to sensitive locations, which in turn could "
"lead to privilege escalation attacks. Although /var/log/nginx permissions "
"are now fixed it is possible that such insecure links already exist. So, "
"please make sure to check the above locations."
msgstr ""
"Depuis la version 1.4.4-4 de nginx, /var/log/nginx appartient à www-data. "
"Par conséquent www-data peut faire des liens symboliques des fichiers de "
"journaux vers des emplacements sensibles, ce qui pourrait amener à des "
"attaques par augmentation de droits. Même si désormais les droits de /var/"
"log/nginx ont été sécurisés, il est possible que de tels liens existent "
"déjà. Aussi, veuillez vous assurer d'avoir contrôlé les emplacements ci-"
"dessus."

Bug#844709: [Pkg-freeipa-devel] Bug#844709: certmonger: Certmonger runs its programs from nonexistent path

[Timo Aaltonen]

On 18.11.2016 12:47, Michal Kašpar wrote:
> Package: certmonger
> Version: 0.78.6-4
> Severity: important
> 
> Dear Maintainer,
> I've noticed the certmonger processes ends as defunct in process list.
> When looking into it via running certmonger in foreground debug mode
> (certmonger -f -d 5), I've found out the certmonger tries to run its
> components from /usr/lib/x86_64-linux-gnu/certmonger/ while they are
> installed in /usr/lib/certmonger. The symlink 
> /usr/lib/x86_64-linux-gnu/certmonger -> /usr/lib/certmonger fixes this, 
> however the correct fix is probably either to install those binaries to arch 
> dependent path or let them run from path where they are really installed.

That's weird, configure is told to use --libexecdir=/usr/lib.. are you
sure you don't have old files in /var/lib/certmonger/cas? Grep for
'usr/lib'.


-- 
t

Bug#840186: [Debichem-devel] Bug#840186: Bug#840186: nwchem builds on amd64 with -march=native

[Michael Banck]

Hi,

> On Fri, Nov 18, 2016 at 01:18:23AM +, Apra, Edoardo wrote:
> > -  FOPTIONS +=  -mtune=native
> > +  FOPTIONS += -march=native -mtune=native

By the way, it seems this patch is reversed, as it adds -march=native.


Michael

Bug#837926: debian-installer: please use fonts-noto-hinted to display the Sinhala script

[Jonas Smedegaard]

Quoting Christian Perrier (2016-11-18 09:11:00)
> Le 17/11/2016 à 15:32, Jonas Smedegaard a écrit :
>> Quoting Harshula (2016-11-17 14:58:33)
>>> On 19/09/16 02:07, Christian PERRIER wrote:
 I'd be happy to do this, however the fonts-noto-hinted-udeb package 
 is 5 megabytes in size while the former fonts-lklug-sinhala-udeb 
 package is only 67kilobytes.

>> I can create a udeb specifically for Sinhala.  Or I can create a udeb 
>> for each single font part of the Noto deb.  What do the 
>> debian-installer team consider useful?

> Chagning the D-I font to Noto for all languages hasn't been 
> validated...and the current font is well tested and accepted.
> 
> So, as a consequence, I'd prefer a udeb that would be suited for 
> Sinhala.

Makes sense.

udeb package fonts-noto-hinted-udeb now, since 20161116-1, contains only 
fonts relevant for debian-installer - i.e. for now only Sinhala fonts.

 - Jonas

-- 
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/

 [x] quote me freely  [ ] ask before reusing  [ ] keep private

Bug#840186: [Debichem-devel] Bug#840186: nwchem builds on amd64 with -march=native

[Michael Banck]

tags 840186 +patch
tags 840186 +pending
thanks

On Fri, Nov 18, 2016 at 01:18:23AM +, Apra, Edoardo wrote:
> The attached patch disables the gfortran flag -march=native.
> Same patch can be found at the URL
> http://www.nwchem-sw.org/images/Disable_march_native.patch.gz

> --- nwchem-6.6/src/config/makefile.h  2016-11-17 22:29:09.794581240 +
> +++ nwchem-6.6/src/config/makefile.h.orig 2016-11-17 22:26:29.497599135 
> +
> @@ -1956,7 +1956,7 @@
>FOPTIONS +=  -ff2c -fno-second-underscore
>  endif
>  ifeq ($(GNU_GE_4_6),true) 
> -  FOPTIONS +=  -mtune=native
> +  FOPTIONS += -march=native -mtune=native
>FOPTIONS += -finline-functions
>  else
>  ifeq ($(_GOT3DNOW),Y) 

Thanks Edoardo, I've applied it to our packaging repository and will
look at uploading a new package with this patch later today.


Michael

Bug#844700: pbuilder: please support build profiles

[James Clarke]

Control: retitle -1 pbuilder: Add --profiles flag

Hi,
> On 18 Nov 2016, at 08:22, Samuel Thibault  wrote:
> 
> Package: pbuilder
> Version: 0.226.1
> Severity: wishlist
> 
> Hello,
> 
> When bootstrapping a package which depends on itself (directly or
> through a loop), one uses e.g.
> 
> dpkg-buildpackage -Pstage1
> 
> which disables the self-dependency in Build-Depends.
> 
> However, using
> 
> pdebuild --debbuildopts -Pstage1
> 
> tries to install the self-dependency, I have to explicitly remove the
> dependency from debian/control.
> 
> It would be nice if pdebuild had a way to specify a build profile, so
> that it only tries to install what is needed for the bootstrap.

There's no flag that I know of (we should probably add one), but
setting DEB_BUILD_PROFILES should work and be honoured by
all the resolvers (except gdebi). --debbuildopts doesn't look
inside its argument, hence why the resolvers don't know to use
certain build profiles.

Regards,
James

Bug#844710: autocorrection suggested rm for typing mr without typing "y"

[Martin Steigerwald]

Package: zsh
Version: 5.2-5+b1
Severity: normal
Tags: upstream

Dear maintainer,

# Actual result

Both zsh 5.0.7-5 on Jessie…

ms@intraws:~/Backup/Mail/Linux#1> mr test
zsh: correct 'mr' to 'rm' [nyae]? n
zsh: command not found: mr

as well as 5.2-5+b1

ms@merkaba:~#127> mr test
zsh: correct 'mr' to 'rm' [nyae]? n
zsh: command not found: mr

suggest "rm" for "mr" but on simply typing return they choose "n", which is
a sane default.

Yet, I had this:

ms@intraws:~/Backup/Mail/Linux> mr kernel-ml_archive.gz 
kernel-ml_archive_2014-1b.gz
zsh: correct 'mr' to 'rm' [nyae]?
rm: das Entfernen von „kernel-ml_archive_2014-1b.gz“ ist nicht möglich: Datei 
oder Verzeichnis nicht gefunden

I didn´t type yes, as when I type "y", it is shown on command line:

ms@intraws:~/Backup/Mail/Linux#1> LANG=C mr test
zsh: correct 'mr' to 'rm' [nyae]? y
rm: cannot remove 'test': No such file or directory

And I really didn´t type "y" there, I am pretty sure of that, but I may
have hit another key by accident. And lost a (not so important) file, as
it was completed after last snapshot was being taken.

Unfortunately so far I have no idea on how to reproduce this.


# Expected results

1. Never autocorrect until I say "y"!

Ideally also:

2. Do not autocorrect to dangerous commands.


I think this is an upstream issue and would also report it there, if it shelps.

Thanks,
Martin


-- Package-specific info:
Packages which depend, recommend, suggest or enhance a zsh package and hence 
may provide code meant to be sourced in .zshrc:

Desired=Unknown/Install/Remove/Purge/Hold
| Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend
|/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad)
||/ Name  Version Architecture  
  Description
+++-=-===-===-===
ii  fizsh 1.0.7-1 all   
  Friendly Interactive ZSHell
ii  zsh-syntax-highlighting   0.5.0-1 all   
  Fish shell like syntax highlighting for zsh
debsums: missing file /etc/fizsh/modify-etc-shells.zsh (from fizsh package)

Packages which provide vendor completions:

Desired=Unknown/Install/Remove/Purge/Hold
| Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend
|/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad)
||/ Name  Version Architecture  
  Description
+++-=-===-===-===
ii  curl  7.51.0-1amd64 
  command line tool for transferring data with URL syntax
ii  git-buildpackage  0.8.6   all   
  Suite to help with Debian packages in Git repositories
ii  mpv   0.21.0-2amd64 
  video player based on MPlayer/mplayer2
ii  pass  1.6.5-3 all   
  lightweight directory-based password manager
ii  pdfgrep   1.4.1-2 amd64 
  search in pdf files for strings matching a regular expression
ii  pulseaudio9.0-5   amd64 
  PulseAudio sound server
ii  sysdig0.9.0-1 amd64 
  system-level exploration and troubleshooting tool
ii  systemd   232-3   amd64 
  system and service manager
ii  systemd-container 232-3   amd64 
  systemd container/nspawn tools
ii  udev  232-3   amd64 
  /dev/ and hotplug management daemon
ii  vlc-bin   2.2.4-8 amd64 
  binaries from VLC

The following files were modified:

/etc/systemd/resolved.conf
/etc/pulse/daemon.conf

dpkg-query: no path found matching pattern /usr/share/zsh/vendor-functions/


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

Kernel: Linux 4.8.0-1-amd64 (SMP w/4 CPU cores)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)

Versions of packages zsh depends on:
ii  dpkg1.18.15
ii  libc6   2.24-5
ii  libcap2 1:2.25-1
ii  libtinfo5   6.0+20160917-1
ii  zsh-common  5.2-5

Versions of packages zsh recommends:
ii  libc6  

Bug#844711: libxkbcommon: Documentation incomplete, needs B-D graphviz

[Jakob Haufe]

Source: libxkbcommon
Version: 0.6.1-1
Severity: normal

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Dear Maintainer,

libxkbcommon uses doxygen which in turn needs dot from graphviz.

See [1] line 1121+ and e.g. [2].

Should be fixed by adding graphviz as build dependency.

Cheers,
sur5r

[1] 
https://buildd.debian.org/status/fetch.php?pkg=libxkbcommon=i386=0.6.1-1=1471852715
[2] /usr/share/doc/libxkbcommon-dev/graph_legend.html

- -- System Information:
Debian Release: stretch/sid
Architecture: amd64 (x86_64)
Foreign Architectures: i386

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

Versions of packages libxkbcommon-dev depends on:
ii  libxkbcommon0  0.6.1-1

libxkbcommon-dev recommends no packages.

libxkbcommon-dev suggests no packages.

- -- no debconf information

-BEGIN PGP SIGNATURE-

iQIcBAEBCgAGBQJYLtwJAAoJEEzyshj1Ta49V/UP/0odVEA+7UEY04ufdUR2sFIJ
JTue/3OC83UM1dqZjsgNvtoxD4gYwQfXw0pcNG20Y8H/v0lbnA3glftAP/nV5FdL
4iBJDOMbKdTsAqUI/Ked7DtNzDbueO4TTD9DQrzZBinJx79n0G5khY16/Ko2WBVn
JtP0NyYWYFzvWaKgAUfMQwNy09kqQExGkXr53lVJNu4htwkHmlw24cWWczmvJHm8
If9J7PftOWrOgnr1h0zt+0iHcrtLyuz3gVR0XL5RytXIlf3wCJYI56vFn3p9/V0X
aTpCOzqdTLV+8Y+XLCjOB0bp26qlmkzgOJ625V3qs8h/c0f6izRhwNGtNx0EQQx8
Y0lvQabTWbbzVcc7gnwobKqnG4F8xxCYs3THG+j/YO3xcUivnBmoOsdCjuG7osdx
GlUC6zv/9p4hfxctx1yArqP6nGzLt/IORQKdvdInsjcE/8Mqwsmhs5j00Fy/3rRU
MvVumRUhxwUBaGiBaFLmaYs8HyAk7UsG2tPICaichGnDqodK/BIULtXWa3lN0ko4
e/l/915zg7jcfnwlwqViYQK+FHSYhMCmXn1WMbYK4p5tgmYxBLtznJW3fQkcX3yl
ZgDOOdUufONObCwq9ldYRy9Z+RUgILzP/luAGtPHMUn/dcWvJp3vFU1wGGSu45CL
Wa4HMoT38zLs7kLuklKC
=ZEcS
-END PGP SIGNATURE-

Bug#844709: certmonger: Certmonger runs its programs from nonexistent path

[Michal Kašpar]

Package: certmonger
Version: 0.78.6-4
Severity: important

Dear Maintainer,
I've noticed the certmonger processes ends as defunct in process list.
When looking into it via running certmonger in foreground debug mode
(certmonger -f -d 5), I've found out the certmonger tries to run its
components from /usr/lib/x86_64-linux-gnu/certmonger/ while they are
installed in /usr/lib/certmonger. The symlink 
/usr/lib/x86_64-linux-gnu/certmonger -> /usr/lib/certmonger fixes this, however 
the correct fix is probably either to install those binaries to arch dependent 
path or let them run from path where they are really installed.

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

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

Versions of packages certmonger depends on:
ii  dbus 1.10.12-1
ii  init-system-helpers  1.46
ii  libc62.24-5
ii  libcomerr2   1.43.3-1
ii  libcurl3-nss 7.51.0-1
ii  libdbus-1-3  1.10.12-1
ii  libidn11 1.33-1
ii  libk5crypto3 1.15~beta1-1
ii  libkrb5-31.15~beta1-1
ii  libldap-2.4-22.4.42+dfsg-2+b3
ii  libnspr4 2:4.12-6
ii  libnss3  2:3.26.2-1
ii  libpopt0 1.16-10
ii  libssl1.0.2  1.0.2j-4
ii  libtalloc2   2.1.8-1
ii  libtevent0   0.9.31-1
ii  libuuid1 2.29-1
ii  libxml2  2.9.4+dfsg1-2.1
ii  libxmlrpc-core-c31.33.14-3

certmonger recommends no packages.

certmonger suggests no packages.

-- no debconf information

Bug#844708: maildir-utils: `--clearlinks' option seems broken

[Gian Piero Carrubba]

Package: maildir-utils
Version: 0.9.17-1
Severity: important

Dear Maintainer,

thank you for your work on maildir-utils.

Version 0.9.17-1 seems to have broken the `--clearlinks' functionality,
at least on my system.

(ins) ~ $ mu find --muhome "${HOME}/.cache/mu" --format=links 
--linksdir="${HOME}/.cache/mu/results" --clearlinks email
mu: failed to open /home/gpiero/.cache/mu/results/cur: No such file or 
directory (73)
(cmd) ~ 73! mu find --muhome "${HOME}/.cache/mu" --format=links 
--linksdir="${HOME}/.cache/mu/results" --clearlinks email
mu: failed to open /home/gpiero/.cache/mu/results/cur: No such file or 
directory (73)
(cmd) ~ 73! mu find --muhome "${HOME}/.cache/mu" --format=links 
--linksdir="${HOME}/.cache/mu/results" --clearlinks email
mu: failed to open /home/gpiero/.cache/mu/results/cur8: No such file or 
directory (73)
(cmd) ~ 73! mu find --muhome "${HOME}/.cache/mu" --format=links 
--linksdir="${HOME}/.cache/mu/results" --clearlinks email
mu: failed to open /home/gpiero/.cache/mu/results/curK: No such file or 
directory (73)
(cmd) ~ 73! mu find --muhome "${HOME}/.cache/mu" --format=links 
--linksdir="${HOME}/.cache/mu/results" --clearlinks email
mu: failed to open /home/gpiero/.cache/mu/results/cur: No such file or 
directory (73)
(cmd) ~ 73! mu find --muhome "${HOME}/.cache/mu" --format=links 
--linksdir="${HOME}/.cache/mu/results" --clearlinks email
mu: failed to open /home/gpiero/.cache/mu/results/curf: No such file or 
directory (73)


Please note the seemingly random chars added at the end of the directory
path it cannot found. Maybe when not shown it's a non-printable char?

Anyway:

$ ls -ld /home/gpiero/.cache/mu/results/cur
drwx-- 2 gpiero gpiero 4096 Nov 18 11:23 /home/gpiero/.cache/mu/results/cur

Path exists w/ right permissions.

Without the use of the `--clearlinks' option it works (but links
have to be manually removed). Downgrading to 0.9.16-1+b1 re-enables the
right behaviour for `--clearlinks'.

Thank you,
Gian Piero.


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

Kernel: Linux 4.8.0-1-amd64 (SMP w/2 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)

Versions of packages maildir-utils depends on:
ii  dpkg1.18.15
ii  guile-2.0-libs  2.0.13+1-2
ii  install-info6.3.0.dfsg.1-1+b1
ii  libc6   2.24-5
ii  libgc1c21:7.4.2-8
ii  libgcc1 1:6.2.0-13
ii  libglib2.0-02.50.2-1
ii  libgmime-2.6-0  2.6.20-8
ii  libstdc++6  6.2.0-13
ii  libxapian30 1.4.1-1

maildir-utils recommends no packages.

maildir-utils suggests no packages.

-- no debconf information

Bug#844629: transcriber: sound stops after less than a second

[Giulio Paci]

Hi,
  thank you for your bug report. Unfortunately using transcriber with 
pulseaudio has always lead to issues.
As far as I know, the issues are shared among all the software that use snack 
library.

Can you check if you have similar experience with wavesurfer?

Best,
Giulio


On 17/11/2016 18:28, Frank Doepper wrote:
> Package: transcriber
> Version: 1.5.1.1-10
> Severity: important
> 
> Dear Maintainer,
> 
> trying to use transcriber in stretch I experience that the sound output
> stops after less than a second, although the cursor moves on. Stopping
> (with tab) and restarting starts playing again, which stops then again
> in the same way. Pulseaudio is installed, the transcriber sound source
> does not dissapear.
> 
> I would expect to hear the sound without interruption. I remember it
> worked some time ago (wheezy?), before Pulseaudio.
> 
> -- System Information:
> Debian Release: stretch/sid
>   APT prefers testing
>   APT policy: (990, 'testing'), (500, 'unstable'), (500, 'stable'), (1, 
> 'experimental')
> Architecture: amd64 (x86_64)
> Foreign Architectures: i386
> 
> Kernel: Linux 4.8.0-1-amd64 (SMP w/4 CPU cores)
> Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8)
> Shell: /bin/sh linked to /bin/dash
> Init: systemd (via /run/systemd/system)
> 
> Versions of packages transcriber depends on:
> ii  libc6  2.24-5
> ii  libx11-6   2:1.6.3-1
> ii  sox14.4.1-5+b1
> ii  tcl-snack  2.2.10.20090623-dfsg-6
> ii  tcl-tclex  1.2a1-16
> ii  tcl8.5 8.5.19-2
> ii  tk 8.6.0+9
> ii  tk8.5  8.5.19-1
> 
> transcriber recommends no packages.
> 
> transcriber suggests no packages.
> 
> -- no debconf information
> 

Bug#844220: maybe not /usr-merged but 0700 for / could be the culprit here

[Holger Levsen]

reassign 844220 usrmerge,debootstrap

Hi,

someone mailed me privately and pointed me to this forum post
https://bbs.archlinux.org/viewtopic.php?id=186056=2 which made me
realize that debootstrap had another change: TARGET is now created with
0700 permissions and not 0755 anymore, though I couldnt find this in
debootstrap's changelog, so maybe I'm confused.


-- 
cheers,
Holger


signature.asc
Description: Digital signature

Bug#844707: plasma-workspace: plasmadesktop - excessive cpu usage, slow desktop operation

[Tim Small]

Package: plasma-workspace
Version: 4:5.8.2-1
Severity: important

plasmashell consumes excessive CPU, increases over time.

Possibly I'm hitting a couple of bugs here, but I'm not sure...

plasmashell starts by stat()ing about 4 files per second, and
consuming 50% of one CPU core.  CPU then climbs to around 110% of one
core, and the stat() rate (under strace) falls to about 3 per second.

This is 10 seconds of strace output from a freshly started plasmashell:

http://buttersideup.com/plasmashell-debug/plasmashell-highcpu-strace-fresh

and a summary output taken afterwards:

http://buttersideup.com/plasmashell-debug/plasmashell-highcpu-strace-fresh-summary

These two are for processes that have been running longer, and have
climbed to >100% usage:

http://buttersideup.com/plasmashell-debug/plasmashell-highcpu-strace

http://buttersideup.com/plasmashell-debug/plasmashell-highcpu-strace-summary

Tim.


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

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

Versions of packages plasma-workspace depends on:
ii  dbus-x11 1.10.12-1
ii  frameworkintegration 5.27.0-1
iu  gdb  7.11.1-2+b1
ii  iso-codes3.70-1
ii  kactivitymanagerd5.8.2-1
ii  kde-cli-tools4:5.8.2-1
ii  kded55.27.0-1
ii  kinit5.27.0-1
ii  kio  5.27.0-2
ii  kpackagetool55.27.0-1
ii  libc62.24-5
ii  libcln6  1.3.4-2
ii  libdbusmenu-qt5-20.9.3+16.04.20160218-1
ii  libgcc1  1:6.2.0-13
ii  libgps22 3.16-4
ii  libice6  2:1.0.9-1+b1
ii  libkf5activities55.27.0-1
ii  libkf5auth5  5.27.0-1
ii  libkf5baloo5 5.27.0-1
ii  libkf5bookmarks5 5.27.0-1
ii  libkf5calendarevents55.27.0-1+b1
ii  libkf5completion55.27.0-1
ii  libkf5configcore55.27.0-1
ii  libkf5configgui5 5.27.0-1
ii  libkf5configwidgets5 5.27.0-1
ii  libkf5coreaddons55.27.0-1
ii  libkf5crash5 5.27.0-1
ii  libkf5dbusaddons55.27.0-1
ii  libkf5declarative5   5.27.0-1+b1
ii  libkf5globalaccel-bin5.27.0-1
ii  libkf5globalaccel5   5.27.0-1
ii  libkf5guiaddons5 5.27.0-1
ii  libkf5holidays5  16.04.2-1
ii  libkf5i18n5  5.27.0-2
ii  libkf5iconthemes55.27.0-1
ii  libkf5idletime5  5.27.0-1
ii  libkf5itemviews5 5.27.0-1
ii  libkf5jobwidgets55.27.0-1
ii  libkf5js55.27.0-1
ii  libkf5jsembed5   5.27.0-1
ii  libkf5kdelibs4support5   5.27.0-1
ii  libkf5kiocore5   5.27.0-2
ii  libkf5kiofilewidgets55.27.0-2
ii  libkf5kiowidgets55.27.0-2
ii  libkf5networkmanagerqt6  5.27.0-1
ii  libkf5newstuff5  5.27.0-1
ii  libkf5notifications5 5.27.0-1
ii  libkf5notifyconfig5  5.27.0-1
ii  libkf5package5   5.27.0-1
ii  libkf5plasma55.27.0-1
ii  libkf5plasmaquick5   5.27.0-1
ii  libkf5quickaddons5   5.27.0-1+b1
ii  libkf5runner55.27.0-1
ii  libkf5service-bin5.27.0-1
ii  libkf5service5   5.27.0-1
ii  libkf5solid5 5.27.0-1
ii  libkf5texteditor55.27.0-1
ii  libkf5textwidgets5   5.27.0-1
ii  libkf5wallet-bin 5.27.0-1
ii  libkf5wallet55.27.0-1
ii  libkf5waylandclient5 4:5.27.0-1
ii  libkf5widgetsaddons5 5.27.0-1
ii  libkf5windowsystem5  5.27.0-1
ii  libkf5xmlgui55.27.0-1
ii  libkf5xmlrpcclient5  5.27.0-1
ii  libkscreenlocker55.8.2-1
ii  libksgrd7

Bug#834228: more info

[Russell Coker]

~/systemd-tmpfiles --create /usr/lib/tmpfiles.d/systemd.conf

I copied /bin/systemd-tmpfiles to /root (so I can give it a different 
context).  When I run the above command after logging in as root:sysadm_r it 
sets the correct context.  But when I delete /run/utmp and run it again it 
doesn't recreate the file.

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

Bug#844433: libdr-tarantool-perl: Non-determistically FTBFS due to unreliable tests

[Chris Lamb]

Hi,

> I think Your build system (container?) is overloaded so these tests
> are not passed from time to time.
[..]
> So I'll reduce severity for the ticket. If the problem is appeared on
> debian buildd I'll do something.

Not entirely comfortable with that conclusion. If our users or QA tools
cannot reliably build your package, then that is surely a problem.


Regards,

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

Bug#844706: libssl1.1 needs Breaks on salt-common

[Adrian Bunk]

Package: libssl1.1
Version: 1.1.0c-1
Severity: serious
Control: block 827061 by -1
Control: block -1 by 843871

libssl1.1 needs a Breaks on salt-common versions without the fix
for #843871 to avoid breakages for users upgrading from jessie.

Bug#842555: QA upload

[Tobias Frost]

Hi Dimitry, 

On Sun, 06 Nov 2016 07:58:14 +0300 Dmitry Bogatov 
wrote:
> 
> [2016-11-03 09:37] "gustavo panizzo (gfa)" 
> >
> > I intend to do a QA upload for this package soon, if anybody wants
to be
> > the real maintainer, ping me I can handover my improvements to you
> 
> Hello! I am interested in tsocks maintainership and your
improvements.
> 

Gustavo did now thie QA upload, you're very welcome to adopt this
package now, if you're still interested.
Pease indicate this by retitling this bug to
"ITA: tsocks -- transparent network access through a SOCKS 4 or 5
proxy", so that everyone knows about your intentions.

Many thanks for contributing to Debian!

--
tobi

Bug#844705: libedit-dev: Missing build dependency - ncurses

[Mark Gillott]

Package: libedit-dev
Version: 3.1-20160903-1
Severity: normal

Dear Maintainer,

An application makes use of the libedit-dev library. In a recent updated
from Debian8 to Debian9 the (previously working) build failed. The
reason for the failure was a missing library - ncurses:

[   68s] cc -g -fdebug-prefix-map=/usr/src/packages/BUILD=.
-fstack-protector-strong -Wformat -Werror=format-security -O3 -g -Wall
-Wextra -Werror -I/usr/include/json-c -I/usr/include/editline
-Wdate-time -D_FORTIFY_SOURCE=2 -D_GNU_SOURCE -I ../ctrldb -Wl,-z,relro
-o vplsh \
[   68s]   vplsh.o ../ctrldb/ctrldb.o -lczmq -lzmq -ljson-c -ledit
-lncurses -lbsd
[   68s] /usr/bin/ld: cannot find -lncurses
[   68s] collect2: error: ld returned 1 exit status
[   68s] Makefile:21: recipe for target 'vplsh' failed
[   68s] make[2]: *** [vplsh] Error 1

The line in the makefile is simply:

   VPLSH_LIBS  = $(LIBS) $(shell pkg-config --libs libedit)

The fix was to modify the application control file so as to add
libncurses5-dev as an explicit dependency.

Ultimately the libedit-dev package file should have called out the
dependency and pulled in the necessary support library. Either that or
eliminate ncurses if its not actually required.

Thanks,

Mark

Bug#844704: gdc fails to build, user_defined_section_attribute removed on trunk

[Matthias Klose]

Package: gdc-7

after this change, D fails to build with the current trunk:

2016-11-16  Andrew Burgess  

* gcc/bb-reorder.c: Remove 'toplev.h' include.
(pass_partition_blocks::gate): No longer check
user_defined_section_attribute, instead check the function decl
for a section attribute.
* gcc/c-family/c-attribs.c (handle_section_attribute): No longer
set user_defined_section_attribute.
* gcc/final.c (rest_of_handle_final): Likewise.
* gcc/toplev.c: Remove definition of user_defined_section_attribute.
* gcc/toplev.h: Remove declaration of
user_defined_section_attribute.

../../src/gcc/d/d-attribs.c: In function 'tree_node*
d_handle_section_attribute(tree_node**, tree, tree, int, bool*)':
../../src/gcc/d/d-attribs.c:591:7: error: 'user_defined_section_attribute' was
not declared in this scope
   user_defined_section_attribute = true;
   ^~
Makefile:1100: recipe for target 'd/d-attribs.o' failed
make[4]: *** [d/d-attribs.o] Error 1

Bug#843349: linux-image-4.7.0-1-amd64: Intermittently high system load, sluggish response, no /proc//stat utime,stime,etc. reported

[Christophe Aguettaz]

On Sun, 13 Nov 2016 04:23:54 + Ben Hutchings  wrote:
> Control: tag -1 moreinfo
>
> On Sun, 2016-11-06 at 00:02 -0700, Tom Lee wrote:
> [...]
> > Downgrading to linux-image-4.6.0-1-amd64 fixed all symptoms. Haven't yet
> > tried 4.8.0-1 from unstable, not sure if it's impacted.
> [...]
>
> Please do.
>
> Ben.
>
> --
> Ben Hutchings
> Nothing is ever a complete failure; it can always serve as a bad
> example.
>

Hi,

I stumbled on the same problem using sid's 4.8.0-1 kernel.
I had been using linux-image-4.7.0-1-amd64 for a while without
trouble, and noticed the issue after upgrading to 4.8.0-1.
I then reverted to using 4.7.0-1... and still the issue persisted!

A colleague of mine told me that he had noticed the problem as well a
while ago. He switched back to kernel version 4.6.0-1, which fixed it.
Later he started using 4.7.0-1 again, but the problem had gone away.
Nasty.

After much rebooting and hair-pulling, I noticed that we three had one
thing in common:

sys_vendor: Alienware
product_name: Aurora-R4
product_version: 00
chassis_vendor: Alienware
chassis_version: 00
bios_vendor: Alienware
bios_version: A11


So here's my theory: there's a bug at some point in the reboot process
that leaves the CPU in a weird state in which some counter are not
getting updated at all. This explains the utime/stime values being
always 0, and this would also probably wreak havoc on the scheduler if
it relied on these counters to account for time slices, explaining the
overall sluggishness.

Since it seems to only affect Aurora-R4 users, I'm guessing the
motherboard might be doing something funky to reset the CPU during
reboots. This behavior may have been revealed by changes in the
4.7.0-1 kernel. So, motherboard bug? Kernel regression? Both? I don't
know.

Long story short, I performed a cold reboot (even pulling the plug for
extra safety), and my system went back to running smoothly using sid's
linux 4.8.0-1.

Hope this helps,

Christophe Aguettaz

Bug#771183: Specific to gdm3

[Bryan Quigley]

Hi Maintainer,

The gdm3 dependency is a bit different than just including an application.
Could we move the gdm3 dependency to task-gnome-desktop? or to the
gnome metapackage?

Thank you

Bug#836124: trafficserver is built with --enable-linux-aio, which is unstable and will be removed in 7.0

[Jean Baptiste Favre]

Hello,
I'm one of the uploader for trafficserver package.

--enable-linux-aio build option has not been removed from 7.0.0.
Instead, it's been decided to rename it.

I use trafficserver with Linux AIO without any issues for 3 years now.
Enabling it actually improved performance a bit.

But, since the feature future isn't clear, I'll consider removing the
option in 7.0.0 package.

Regards,
Jean Baptiste Favre



signature.asc
Description: OpenPGP digital signature

Bug#843520: [debian-mysql] Bug#843520: Bug#843520: mysql-server-5.5 cannot be automatically upgraded

[Jean Louis]

I have no console logs, it was just hanging. That is the problem
encountered, the upgrade was hanging forever without giving error
messages.

Thank you.

On Fri, Nov 18, 2016 at 08:00:34AM +0100, Lars Tangvald wrote:
> Hi,
> 
> On 11/17/2016 06:02 PM, Jean Louis wrote:
> > I am sorry, that I filed bug in the wrong package, it was
> > unintentional mistake. It should be in mysql-server. And I know all
> > about specifics.
> > 
> > In my case, there is nothing that I have changed in my Mysql
> > configuration from the plain install. That is why I filed the
> > bug. Otherwise I would look first on my side.
> > 
> > And I was surprised it did not work, as I was used to the stability
> > and certainty when upgrading.
> > 
> > I could not find the solution
> > 
> > I was reading other bugs and I found:
> > 
> > [mysqld]
> > secure_file_priv = /var/lib/mysql
> > 
> > So I have put it in /etc/mysql/conf.d and now I got it working. Even I
> > don't even know what is it about, as being so lazy to read the
> > documentation. Sorry.
> > 
> > Still I think it should not be like that, the upgrade should go
> > smooth, especially for databases. Nothing angers me, thank you for
> > putting attention. I am supporter of free software and use Debian on
> > remote servers.
> > 
> > Jean Louis
> Hi,
> 
> In this case, the server defaults to secure_file_priv=/var/lib/mysql-files,
> and will require this directory to be created.
> This is a big change to make in a stable release, but the old behavior was a
> potential security risk, so we felt it was justified. The upgrade _should_
> have created this directory automatically, so if it failed for you then
> there's probably something with your environment we didn't account for. If
> you have any console logs or mysql error logs from the update it would be
> good if you can attach them to the bug.
> 
> One important note, however:
> The solution you note, setting secure_file_priv=/var/lib/mysql (the data
> directory) is not a good one. You should either set it to NULL or to a
> separate, empty directory owned by the mysql user.
> 
> The secure_file_priv setting determines where the server is allowed to read
> and write files using import/export operations. Setting it to the same
> location as the database will mean that any user of your database can get
> full access.
> 
> --
> Lars
> 
> 
> > 
> > On Tue, Nov 15, 2016 at 12:10:10PM +, Robie Basak wrote:
> > > Hi Jean,
> > > 
> > > On Tue, Nov 15, 2016 at 12:08:18PM +0100, Jean Louis wrote:
> > > > sudo apt-get update
> > > > sudo apt-get upgrad
> > > > 
> > > > * What exactly did you do (or not do) that was effective (or
> > > >   ineffective)?
> > > > 
> > > > Starting or configuring mysql-server-5.5 hangs forever. System is 
> > > > broken.
> > > > 
> > > > * What was the outcome of this action?
> > > > 
> > > > It hangs forever.
> > > Unfortunately I think this isn't enough for anyone to understand what
> > > happened in your case. This is a problem statement, not a bug report.
> > > 
> > > Clearly a simple upgrade on a fresh install of jessie works; otherwise
> > > we would have thousands of bug reports. Something must be different on
> > > your system, but we do not know what that is. Please provide full steps
> > > to reproduce your problem so that we may figure that out.
> > > 
> > > > I see that several bugs have been filed and marked as RESOLVED, how
> > > > they can be resolved when it is happening over and over again.
> > > Because they are different bugs with different root causes. This
> > > particular issue was determined to be something that needs to be fixed
> > > in akonadi packaging and is now being tracked in bug 843534. Presumably
> > > though you have a different issue as you did not mention akonadi in your
> > > bug report.
> > > 
> > > Please understand that your report cannot be addressed because you have
> > > not provided enough information. If this angers you, try reading
> > > http://www.chiark.greenend.org.uk/~sgtatham/bugs.html which is a great
> > > essay that explains this problem well.
> > > 
> > > Please file a new bug report with full steps on how to reproduce your
> > > bug. If it turns out to have a common root cause, we can always mark it
> > > as a duplicate later.
> > > 
> > > Robie
> > ___
> > pkg-mysql-maint mailing list
> > pkg-mysql-ma...@lists.alioth.debian.org
> > http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-mysql-maint
> 

Bug#834369: ITP: python-libusb1 -- Python wrapper for libusb1

[Vincent Pelletier]

Thanks for the update.

On Fri, 18 Nov 2016 17:05:49 +0900, Arnaud Fontaine 
wrote:
> Sorry for the lag. I have prepared a package:
> https://people.debian.org/~arnau/packages/python-libusb1_1.5.3-1_all.deb

  x2:~/git$ dpkg-deb -c python-libusb1_1.5.3-1_all.deb
  [...]
  -rw-r--r-- root/root 50327 2016-08-21 23:20 
./usr/lib/python2.7/dist-packages/libusb1.py
  -rwxr-xr-x root/root 11486 2016-11-18 07:00 
./usr/lib/python2.7/dist-packages/testUSB1.py

I did not intend this file to appear in the modules namespace. It's
nice to run it while building, of course.

Personally, I would not package it - or maybe
in /usr/share/doc/python-libusb1/examples/ ?

I confirm I could run my protocol analyser user-land driver with
installed package with python2.7 2.7.12-5 .

  $ pypy
  Python 2.7.12 (5.6.0+dfsg-2, Nov 12 2016, 10:14:18)
  [PyPy 5.6.0 with GCC 6.2.0 20161103] on linux2
  Type "help", "copyright", "credits" or "license" for more information.
   import usb1
  Traceback (most recent call last):
File "", line 1, in 
  ImportError: No module named usb1

Maybe you intend to enable pypy (and python3, maybe needing some
packaging overhead to run 2to3) support after first tests ?

Regards,
-- 
Vincent Pelletier


pgpLM1I6cH20m.pgp
Description: Signature digitale OpenPGP

Bug#844598: [haskell-stack] relocations errors on compiling

[frederic wagner]

just a small mail to confirm it works correctly in unstable

Fred

Thanks for reporting this.

The above works for me with haskell-stack and ghc both from unstable.
The current version of ghc in testing is known to be broken (see #712228):

   https://bugs.debian.org/712228

Could you give it a try?

Best,

Bug#844655: plasma-desktop-5: problem with autostart

[chatrapati]

I think, my message is difficult to understand. Excuse me for my English.

I put file "firefox-esr.desktop" in ~/.config/autostart/ and when I 
reboot system firefox-esr trying to go in URI-adress http://www.%u.com/ 
. So I have an error "server is not found".There is a string 
"Exec=firefox-esr %u" in firefox-esr.desktop


I do similarly with "inkscape.desktop". I have similar problem: inkscape 
starting trying to open file with name "%F", but there is no file with 
this name! There is a string "Exec=inkscape %F" in file inkscape.desktop".


So I should to delete these "%u" and "%F" in files *.desktop if I use 
them (*.desktop) in .config/autostart/

Bug#844433: libdr-tarantool-perl: Non-determistically FTBFS due to unreliable tests

[Dmitry E. Oboukhov]

severity 844433 important
thanks

the package contains some tests that relay to the other program
(tarantool_box) does something while fixed interval exceeded.

I think Your build system (container?) is overloaded so these tests
are not passed from time to time.

Debian's buildd built the package successfully.

So I'll reduce severity for the ticket. If the problem is appeared on
debian buildd I'll do something.
Now the package is (de-facto) LTS, so I don't want to change it. I
also don't want to disable tests.


> Source: libdr-tarantool-perl
> Version: 0.45-2
> Severity: serious
> Justification: fails to build from source
> User: reproducible-bui...@lists.alioth.debian.org
> Usertags: ftbfs
> X-Debbugs-Cc: reproducible-bui...@lists.alioth.debian.org

> Dear Maintainer,

> libdr-tarantool-perl's testsuite appears to non-deterministically fail, 
> causing
> itself to FTBFS.

> Using wall-clock time is inherently unreliable.

> […]

> #   Failed test 'total time less than 1 second'
> #   at t/090-parallel-requests.t line 153.
> # '8.6400101184845'
> # <=
> # '1'
> # Looks like you failed 1 test of 48.
> t/090-parallel-requests.t ...
> 1..48
> ok 1 - use DR::Tarantool::LLClient;
> ok 2 - use DR::Tarantool;
> ok 3 - use File::Spec::Functions;
> ok 4 - use File::Basename;
> ok 5 - use AnyEvent;
> ok 6 - use DR::Tarantool::AsyncClient;
> ok 7 - directory with test data
> ok 8 - t/test-data/llc-easy2.cfg
> ok 9 - -d t/test-data
> ok 10 - -r t/test-data/init.lua
> ok 11 - An object of class 'DR::Tarantool::AsyncClient' isa 
> 'DR::Tarantool::AsyncClient'
> ok 12 - first call test_parallel: status
> ok 13 - return value
> ok 14 - id: 6
> ok 15 - delay minimum
> ok 16 - delay maximum
> ok 17 - id: 1
> ok 18 - delay minimum
> ok 19 - delay maximum
> ok 20 - id: 4
> ok 21 - delay minimum
> ok 22 - delay maximum
> ok 23 - id: 7
> ok 24 - delay minimum
> ok 25 - delay maximum
> ok 26 - id: 3
> ok 27 - delay minimum
> ok 28 - delay maximum
> ok 29 - id: 10
> ok 30 - delay minimum
> ok 31 - delay maximum
> ok 32 - id: 2
> ok 33 - delay minimum
> ok 34 - delay maximum
> ok 35 - id: 5
> ok 36 - delay minimum
> ok 37 - delay maximum
> ok 38 - id: 9
> ok 39 - delay minimum
> ok 40 - delay maximum
> ok 41 - id: 8
> ok 42 - delay minimum
> ok 43 - delay maximum
> ok 44 - id: 0
> ok 45 - delay minimum
> ok 46 - delay maximum
> ok 47 - total time
> not ok 48 - total time less than 1 second
> Dubious, test returned 1 (wstat 256, 0x100)
> Failed 1/48 subtests

> […]

> The full build log is attached or can be viewed here:

> https://tests.reproducible-builds.org/debian/logs/unstable/amd64/libdr-tarantool-perl_0.45-2.build2.log.gz

> Regards,

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

. ''`.   Dmitry E. Oboukhov
: :’  :   email: un...@debian.org jabber://un...@uvw.ru
`. `~’  GPGKey: 1024D / F8E26537 2006-11-21
  `- 1B23 D4F8 8EC0 D902 0555  E438 AB8C 00CF F8E2 6537


signature.asc
Description: Digital signature

Bug#844703: [l10n] Updated Czech translation of apt-listbugs

[Miroslav Kure]

Package: apt-listbugs
Severity: wishlist
Tags: l10n, patch

Hi,

in attachement there is updated Czech (cs.po) translation of 
apt-listbugs. Please include it with the package.

Thank you
-- 
Miroslav Kure
# Czech translation of apt-listbugs.
# Copyright (C) 2002-2014 Masato Taruishi et al.
# This file is distributed under the same license as the apt-listbugs package.
# Miroslav Kure , 2005, 2009, 2012, 2014, 2016.
#
msgid ""
msgstr ""
"Project-Id-Version: apt-listbugs 0.1.16\n"
"Report-Msgid-Bugs-To: invernom...@paranoici.org\n"
"POT-Creation-Date: 2016-09-25 17:59+0200\n"
"PO-Revision-Date: 2016-11-18 10:06+0100\n"
"Last-Translator: Miroslav Kure \n"
"Language-Team: Czech \n"
"Language: cs\n"
"MIME-Version: 1.0\n"
"Content-Type: text/plain; charset=UTF-8\n"
"Content-Transfer-Encoding: 8bit\n"
"Plural-Forms: nplurals=3; plural=(n==1) ? 0 : (n>=2 && n<=4) ? 1 : 2;\n"

#. TRANSLATORS: "E: " is a label for error messages; you may translate it with 
a suitable abbreviation of the word "error"
#: ../bin/apt-listbugs:416 ../bin/apt-listbugs:449 ../bin/apt-listbugs:454
#: ../bin/apt-listbugs:460 ../bin/apt-listbugs:474 ../bin/apt-listbugs:504
#: ../bin/apt-listbugs:535 ../bin/apt-listbugs:584 ../bin/apt-listbugs:597
#: ../lib/aptlistbugs/aptcleanup:52 ../lib/aptlistbugs/aptcleanup:55
#: ../lib/aptlistbugs/logic.rb:285 ../lib/aptlistbugs/logic.rb:295
#: ../lib/aptlistbugs/logic.rb:931 ../lib/aptlistbugs/logic.rb:943
#: ../lib/aptlistbugs/logic.rb:956 ../lib/aptlistbugs/migratepins:52
#: ../lib/aptlistbugs/migratepins:55
msgid "E: "
msgstr "E: "

#: ../bin/apt-listbugs:417
msgid "This may be caused by a package lacking support for the ruby interpreter 
in use. Try to fix the situation with the following commands:"
msgstr "To může být způsobeno balíkem bez podpory použitého interpretru ruby. 
Zkuste vzniklou situaci vyřešit těmito příkazy:"

#: ../bin/apt-listbugs:449
msgid "APT_HOOK_INFO_FD is undefined.\n"
msgstr "APT_HOOK_INFO_FD není definovaná.\n"

#: ../bin/apt-listbugs:454
msgid "APT_HOOK_INFO_FD is not correctly defined.\n"
msgstr "APT_HOOK_INFO_FD není definovaná správně.\n"

#: ../bin/apt-listbugs:460
msgid "Cannot read from file descriptor %d"
msgstr "Nelze číst z deskriptoru souboru %d"

#: ../bin/apt-listbugs:474
msgid "APT Pre-Install-Pkgs is not giving me expected 'VERSION 3' string.\n"
msgstr "APT Pre-Install-Pkgs nevrací očekávaný řetězec „VERSION 3“.\n"

#: ../bin/apt-listbugs:504
msgid "APT Pre-Install-Pkgs is giving me fewer fields than expected.\n"
msgstr "APT Pre-Install-Pkgs vrací méně polí, než je očekáváno.\n"

#: ../bin/apt-listbugs:535
msgid "APT Pre-Install-Pkgs is giving me an invalid direction of version 
change.\n"
msgstr "APT Pre-Install-Pkgs vrací neplatný směr změny verze.\n"

#: ../bin/apt-listbugs:614
msgid "** Exiting with an error in order to stop the installation. **"
msgstr "** Ukončeno s chybou s cílem ukončit instalaci. **"

#: ../lib/aptlistbugs/aptcleanup:52 ../lib/aptlistbugs/logic.rb:355
#: ../lib/aptlistbugs/migratepins:52
msgid "Cannot read from %s"
msgstr "Nelze číst z %s"

#: ../lib/aptlistbugs/aptcleanup:123
msgid "Fixed packages : "
msgstr "Opravené balíky: "

#: ../lib/aptlistbugs/logic.rb:47
msgid "Usage: "
msgstr "Použití: "

#: ../lib/aptlistbugs/logic.rb:48
msgid " [options]  [arguments]"
msgstr " [volby]  [argumenty]"

#: ../lib/aptlistbugs/logic.rb:50
msgid "Options:\n"
msgstr "Volby:\n"

#. TRANSLATORS: the colons (:) in the following strings are vertically aligned, 
please keep their alignment consistent
#. TRANSLATORS: the \"all\" between quotes should not be translated
#: ../lib/aptlistbugs/logic.rb:53
msgid ""
" -s   : Filter bugs by severities you want to see\n"
"(or \"all\" for all)\n"
"[%s].\n"
msgstr ""
" -s   : Zobrazí jen chyby daných závažností\n"
"(nebo „all“ pro všechny)\n"
"[%s].\n"

#: ../lib/aptlistbugs/logic.rb:54
msgid " -T : Filter bugs by tags you want to see.\n"
msgstr " -T <štítky>  : Zobrazí jen chyby s danými štítky.\n"

#: ../lib/aptlistbugs/logic.rb:55
msgid ""
" -S   : Filter bugs by pending-state categories you want to see\n"
"[%s].\n"
msgstr ""
" -S: Zobrazí jen chyby daných stavů\n"
"[%s].\n"

#: ../lib/aptlistbugs/logic.rb:56
msgid " -B : Filter bugs by number, showing only the specified 
bugs.\n"
msgstr " -B   : Zobrazí pouze chyby daných čísel.\n"

#: ../lib/aptlistbugs/logic.rb:57
msgid " -D   : Show downgraded packages, too.\n"
msgstr " -D   : Vypíše také chyby v degradovaných balících.\n"

#: ../lib/aptlistbugs/logic.rb:58
msgid " -H : Hostname of Debian Bug Tracking System [%s].\n"
msgstr " -H  : Jméno počítače na němž běží debianí BTS [%s].\n"

#: ../lib/aptlistbugs/logic.rb:59
msgid " -p : 

Bug#844694: firefox: high-lighting issues with the new release (maybe gtk3 issue ? )

[shirish शिरीष]

update at bottom :-

On 18/11/2016, shirish शिरीष  wrote:
> at bottom :-
>
> On 18/11/2016, Mike Hommey  wrote:
>> On Fri, Nov 18, 2016 at 12:21:25PM +0530, shirish शिरीष wrote:
>>> Package: firefox
>>> Version: 50.0-1
>>> Severity: normal
>>>
>>> Dear Maintainer,
>>> In Debian mate, previous versions of Mozilla Firefox used the
>>> high-lighting color (from the theme selected/used) while in the new
>>> version the highlighting while going through the different drop-down
>>> menus is unavailable. Can this be fixed ?
>>>
>>> https://jumpshare.com/v/CMeKzSwl83vyRrEvzSEe also has the same video
>>> which I have attached, it shows the problem in case I have been unable
>>> to explain well.
>>>
>>> Notice that the new version doesn't tell you which option you are
>>> choosing while in tor the green band always tells you visually which
>>> option you are taking.
>>>
>>> The video has been bought to you by simplescreenrecorder.
>>
>> Run gtk3-demo from the gtk-3-examples package. In the list it brings,
>> select "Menus" then click the "Run" button. Does the same happen there?
>
> Dear Mike,
>
> Nope. It runs similar to what I shared as the behaviour of tor. No
> change from tor behaviour.
>
>> Mike
>>

I also ran firefox in safe-mode, the odd behaviour in firefox persists
here too :(

-- 
  Regards,
  Shirish Agarwal  शिरीष अग्रवाल
  My quotes in this email licensed under CC 3.0
http://creativecommons.org/licenses/by-nc/3.0/
http://flossexperiences.wordpress.com
EB80 462B 08E1 A0DE A73A  2C2F 9F3D C7A4 E1C4 D2D8

Bug#844702: firewall-applet: Firewall-applet icon is missing in panel

[Simon Frei]

Package: firewall-applet
Version: 0.4.4.1-1
Severity: normal

Since my last update the panel icon is not shown anymore for firewall-applet. 
It is running, space is reserved on the panel and it works as expected, but no 
symbol. Starting firewall-applet from command line produces the following 
message:

QSystemTrayIcon::setVisible: No Icon set

I update from 0.4.3.3-1, where this problem was not present.

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

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

Versions of packages firewall-applet depends on:
ii  firewall-config  0.4.4.1-1
ii  firewalld0.4.4.1-1
ii  gir1.2-networkmanager-1.01.4.2-2
ii  gir1.2-notify-0.70.7.7-1
ii  python3-dbus 1.2.4-1
ii  python3-dbus.mainloop.pyqt5  5.7+dfsg-2+b1
ii  python3-gi   3.22.0-1
ii  python3-pyqt55.7+dfsg-2+b1
ii  python3-slip-dbus0.6.1-3
pn  python3:any  

firewall-applet recommends no packages.

firewall-applet suggests no packages.

-- no debconf information

Bug#844694: firefox: high-lighting issues with the new release (maybe gtk3 issue ? )

[shirish शिरीष]

at bottom :-

On 18/11/2016, Mike Hommey  wrote:
> On Fri, Nov 18, 2016 at 12:21:25PM +0530, shirish शिरीष wrote:
>> Package: firefox
>> Version: 50.0-1
>> Severity: normal
>>
>> Dear Maintainer,
>> In Debian mate, previous versions of Mozilla Firefox used the
>> high-lighting color (from the theme selected/used) while in the new
>> version the highlighting while going through the different drop-down
>> menus is unavailable. Can this be fixed ?
>>
>> https://jumpshare.com/v/CMeKzSwl83vyRrEvzSEe also has the same video
>> which I have attached, it shows the problem in case I have been unable
>> to explain well.
>>
>> Notice that the new version doesn't tell you which option you are
>> choosing while in tor the green band always tells you visually which
>> option you are taking.
>>
>> The video has been bought to you by simplescreenrecorder.
>
> Run gtk3-demo from the gtk-3-examples package. In the list it brings,
> select "Menus" then click the "Run" button. Does the same happen there?

Dear Mike,

Nope. It runs similar to what I shared as the behavior of tor. No
change from tor behavior.

> Mike
>

-- 
  Regards,
  Shirish Agarwal  शिरीष अग्रवाल
  My quotes in this email licensed under CC 3.0
http://creativecommons.org/licenses/by-nc/3.0/
http://flossexperiences.wordpress.com
EB80 462B 08E1 A0DE A73A  2C2F 9F3D C7A4 E1C4 D2D8

Bug#844701: dpkg: buggy dpkg 1.8.11 and above ? Package: dpkg

[shirish शिरीष]

Package: dpkg
Version: 1.18.14
Severity: normal

Dear Maintainer,
It seems the bug is in dpkg 1.18.11 and above. I was suffering from
some sort of broken packages. I shared my issue at
http://unix.stackexchange.com/questions/323817/debian-strech-update-broken-seems-buggy-dpkg
. It took quite some time but it seems that dpkg at least 1.18.14 is
somewhat broken/buggy in its implementation. In dpkg 1.18.10 I am able
to fix the broken packages. These happened a few more times. I did run
a few checks 
http://unix.stackexchange.com/questions/324151/how-to-find-out-half-configured-broken-packages-in-debian
but found nothing untoward.

I would update to 1.18.15 as and when it comes to testing.

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

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

Versions of packages dpkg depends on:
ii  libbz2-1.0   1.0.6-8
ii  libc62.24-5
ii  liblzma5 5.2.2-1.2
ii  libselinux1  2.6-3
ii  tar  1.29b-1.1
ii  zlib1g   1:1.2.8.dfsg-2+b3

dpkg recommends no packages.

Versions of packages dpkg suggests:
ii  apt  1.3.1

-- Configuration Files:
/etc/dpkg/dpkg.cfg changed:
debug=1
no-debsig
log /var/log/dpkg.log


-- no debconf information


-- 
  Regards,
  Shirish Agarwal  शिरीष अग्रवाल
  My quotes in this email licensed under CC 3.0
http://creativecommons.org/licenses/by-nc/3.0/
http://flossexperiences.wordpress.com
EB80 462B 08E1 A0DE A73A  2C2F 9F3D C7A4 E1C4 D2D8

Bug#837926: debian-installer: please use fonts-noto-hinted to display the Sinhala script

[Christian Perrier]

Le 17/11/2016 à 15:32, Jonas Smedegaard a écrit :

Quoting Harshula (2016-11-17 14:58:33)

On 19/09/16 02:07, Christian PERRIER wrote:

I'd be happy to do this, however the fonts-noto-hinted-udeb package
is 5 megabytes in size while the former fonts-lklug-sinhala-udeb
package is only 67kilobytes.

Size is somehow constrained in Debian Installer, so I'd prefer
getting more input and advice before replacing
fonts-lklug-sinhala-udeb byt fonts-notohinted-udeb in D-I


Perhaps the Noto maintainers might consider splitting Noto into script
based debs. IIRC, that's what was done in Fedora.


I'd be happy to improve the usefulnes of the Noto package(s), but will
need more guidance.

I suspect easiest approach would be for debian-installer to use Noto
generally - i.e. replace not only the font for Sinhala but (I guess) a
larger range of region-specific fonts.

If debian-installer installs locale-specific fonts only when needed, or
there are reasons to not shift generally to Noto, then indeed there is a
benefit in creating udeb packages for smaller regions.

I can create a udeb specifically for Sinhala.  Or I can create a udeb
for each single font part of the Noto deb.  What do the debian-installer
team consider useful?

 - Jonas



Chagning the D-I font to Noto for all languages hasn't been 
validated...and the current font is well tested and accepted.


So, as a consequence, I'd prefer a udeb that would be suited for Sinhala.

Bug#844339: [PATCH v2 2/4] libvirt-daemon-system.{config,templates,postinst}: warn if allocated uid/gid cannot be used

[Guido Günther]

Hi Mauricio,

On Thu, Nov 17, 2016 at 07:53:55PM -0200, Mauricio Faria de Oliveira wrote:
> On 11/17/2016 05:37 PM, Guido Günther wrote:
> > I'm basically fine with all of this (but did not du any actual testing)
> 
> Cool.
> 
> > but we should not warn if the user/group already exists (even with the
> > wrong uid). Otherwise we'd warn over and over again, we don't want to
> > force users to change existing installations.
> 
> Actually the warning is not repeated; the answer is saved by debconf.

Debconf is not a registry that is you must not rely on the debconf
database saving values for you:

https://lintian.debian.org/tags/debconf-is-not-a-registry.html

> If you just install/upgrade after having answered the question once,
> it doesn't show up.

And it means all users of existing installation see it although they
can't do much about it - you really don't want to change uid/gid of the
user on an installed system since this requires cleanup of disk images,
etc. - leaving the user with a broken installation.

> You only get it again in intentional cases:
> 1) dpkg-reconfigure
> 2) apt-get purge && re-install
> 3) remove its 'Flags: seen' line from /var/cache/debconf/config.dat
> 
> > If we want to notify users of existing installations we have a
> > Debian.NEWS for this that can explain that switching to uid/git 64055 is
> > recommended.
> 
> Good point. I can write a snippet for that too if you want, but not
> sure it's enough depending on your decision about how/when to notify
> users (paragraph below).

I think it's sufficient for existing installations. People will see it
and can plan for the change to happen (they obviosly didn't run into the
problem for the last 10 years).

> 
> > IMHO the only important case to warn about is the case where user or
> > group does not yet exist _and_ the uid/gid is already taken by another
> > user or group. What do you think?
> 
> Well, I still think it's also important to warn when the user/group
> already exists (with a different uid/gid).
> 
> The main reason is to help users not to hit a known problem, and help
> maintainers not to get unnecessary bug reports, or having to debug it
> again (it was hard to debug/trace this, the root cause is very subtle,
> and the stack components pile up -- I ended up strace'ing qemu, found
> EACCES in read/write syscalls, and had to understand how NFS had come
> up with this type of error -- not that I'm proud, I imagine it's easy
> for people more experienced w/ the virtualization stack; just a story).
> 
> If existing installations are never told about this, they didn't
> even have a chance to try to fix their environment not to hit it,
> and I guess it's a valid expectation from the packages to set up
> things up correctly so not to hit problems (of course this case
> is not easy/automatic to resolve..)

And that's exactly what NEWS.Debian is for. We use your code for the
error case. That is we want to do the right thing but can't since the
uid/gid is already taken.

> (some systems will never hit it because users were just created
> in the same order on source/destination hosts; but that's luck)
> 
> On the other hand, I'm not sure how disruptive such a warning is
> for automated deployments/upgrades, specially because the default
> is to abort the install (perhaps we should change it).

Exactly. That's why NEWS.Debian is nicer iff the user libvirt-qemu
exists but with "wrong" (legacy) uid/gid on existing installations and
Debconf is better for new installations where the uid/gid is already
taken.

> Anyway, just trying to provide some pondering and other thoughts/
> views on the matter, with the intention it may help :- )  Let me
> know what/how you'd like it in the patches and I'll spin v3 ;- )

Please spin a v3 ;)
Cheers,
 -- Guido

Bug#844700: pbuilder: please support build profiles

[Samuel Thibault]

Package: pbuilder
Version: 0.226.1
Severity: wishlist

Hello,

When bootstrapping a package which depends on itself (directly or
through a loop), one uses e.g.

dpkg-buildpackage -Pstage1

which disables the self-dependency in Build-Depends.

However, using

pdebuild --debbuildopts -Pstage1

tries to install the self-dependency, I have to explicitly remove the
dependency from debian/control.

It would be nice if pdebuild had a way to specify a build profile, so
that it only tries to install what is needed for the bootstrap.

Samuel

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

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

Versions of packages pbuilder depends on:
ii  cdebconf [debconf-2.0]  0.218
ii  debconf [debconf-2.0]   1.5.59
ii  debootstrap 1.0.86
ii  dpkg-dev1.18.10
ii  wget1.18-4

Versions of packages pbuilder recommends:
ii  devscripts  2.16.8
ii  eatmydata   105-5
ii  fakeroot1.21-2
ii  iproute24.8.0-1
ii  net-tools   1.60+git20150829.73cef8a-2
ii  sudo1.8.17p1-2

Versions of packages pbuilder suggests:
pn  cowdancer   
ii  gdebi-core  0.9.5.7

-- debconf information excluded

-- 
Samuel
 le y est un animal discret se logeant facilement dans un terminal
*** c has changed the topic on channel #ens-mim to ne pas jeter de cacahuetes 
aux ys, svp
 -+- #ens-mim - n'oubliez pas le guide -+-

Bug#842638: gbp buildpackage: support basic version mangling for --git-upstream-tag

[Guido Günther]

Hi Jonas,
On Fri, Nov 04, 2016 at 03:24:56PM +0100, Guido Günther wrote:
> Hi Jonas,
> On Mon, Oct 31, 2016 at 03:21:46PM +0100, Jonas Meurer wrote:
> > Hi Guido,
> > 
> > Am 31.10.2016 um 11:21 schrieb Guido Günther:
> > >> See attached patch which implements basic version mangling for
> > >> '--git-upstream-tag' in a simple substitute fashion: if the provided
> > >> format contains the syntax '%(version%OLD%NEW)s', then the version used
> > >> for '%(version)s' has 'OLD' replaced by 'NEW'.
> > >>
> > >> This allows us to let gbp create the upstream tarball from upstream Git
> > >> release tag for new releases:
> > >>
> > >> $ gbp buildpackage --git-upstream-tag="v%(version%.%_)s"
> > >>
> > >>
> > >> In case that you like the approach and agree to add this feature to gbp,
> > >> I could write a few corresponding words for the related paragraphs of
> > >> gbp documentation.
> > >>
> > >> If you're not happy with the way it's implmented, just let me know why
> > >> and we can search for a better solution :)
> > > 
> > > The general approach is fine. Thanks for the patch. See my comments below:
> > 
> > Great :) I  tried to address your comments, see below.
> > 
> > >> commit f6a7e8f83935d74dc0cd67a5afa26b243357d04f
> > >> Author: Jonas Meurer 
> > >> Date:   Sun Oct 30 23:44:34 2016 +0100
> > >>
> > >> gbp/deb/git.py: add basic version mangling to version_to_tag()
> > >>
> > >> diff --git a/gbp/deb/git.py b/gbp/deb/git.py
> > >> index 64cd321..3070d93 100644
> > >> --- a/gbp/deb/git.py
> > >> +++ b/gbp/deb/git.py
> > >> @@ -142,12 +142,18 @@ class DebianGitRepository(GitRepository):
> > >>  hversion is useful for upstreams with tagging policies that 
> > >> prohibit .
> > >>  characters.
> > >>  
> > >> +%(version%A%B)s provides %(version)s with 'A' replaced by 'B'.
> > >> +
> > > 
> > > Please add tests using docstrings as below (including one that show how
> > > to use '%' as a replacement (e.g. 0-1.2.3 -> 0%1.2.3.4 and as replaced
> > > pattern 0%1%2%3 -> 0.1.2.3).
> > 
> > Done.
> > 
> > >>  >>> DebianGitRepository.version_to_tag("debian/%(version)s", 
> > >> "0:0~0")
> > >>  'debian/0%0_0'
> > >>  >>> DebianGitRepository.version_to_tag("libfoo-%(hversion)s", 
> > >> "1.8.1")
> > >>  'libfoo-1-8-1'
> > >>  
> > >>  """
> > >> +r = re.search(r"\%\(version\%([^%s]+)\%([^\%]+)\)s", format)
> > >> +if r:
> > >> +format = re.sub(r"\%\(version\%[^%s]+\%[^\%]+\)s", 
> > >> "%(version)s", format)
> > >> +version = version.replace(r.group(1), r.group(2))
> > >>  return format_str(format, 
> > >> dict(version=DebianGitRepository._sanitize_version(version),
> > >> 
> > >> hversion=DebianGitRepository._sanitize_version(version).replace('.', 
> > >> '-')))
> > >>  
> > > 
> > > Please document the behaviour. The current place that has the most
> > > information on how to modify the upstream version is in
> > > 
> > >  docs/chapters/import.sgml
> > 
> > Done.
> > 
> > See the attached updated patch.

While looking into this in some more details I noticed that we're
missing the reverse operation. In 'gbp buildpackage' we need to map from
the Debian version to the upstream tag while in 'gbp dch' we need to
map from the upstream tag to the debian version. This is not reversible
since '_' will be mapped back to '~'. Therefore I added a warning to the
docs. I've also made some simplifications to allow for easier future
expansion like only allowing for single character replacements for now.

If you have some time it owuld be great if you could have a look
at these commits:

 0b317eeb649090ab8bdd8507c189477670a91cd1 docs: Use version mangling with care
 7ed5e2b5ffbaf8dec310f98162e653fc95cd45f9 DebianGitRepository: Unmangle version
 25a5d679daf6ca90e03fe3bede787396fc630687 DebianGitRepository: split out 
version mangling
 d360a6d92d744762f9f13555ed03726b6d4ba937 DebianGitRepository: simplify version 
mangling

Cheers,
 -- Guido

Bug#844598: [haskell-stack] relocations errors on compiling

[frederic wagner]

hi,

ghc is working for me ; only stack is causing troubles.

i tried the latest upstream stack version with the same problem.

luckily someone pointed me to this thread : 
https://github.com/commercialhaskell/stack/issues/2712


using this hint made everything work :

"""

It builds in my case
Just adapt the ghc version which has the error (ghc-8.0.01 above or 
ghc-7.10 in my case:

~/.stack/programs/x86_64-linux/ghc-7.10.3/lib/ghc-7.10.3/settings )

cp settings settings.bak

And change the options as @senorhesles  
mentionned previously:

("C compiler flags", "-fno-PIE -fno-stack-protector"),
("C compiler link flags", "-no-pie"),
("ld flags", "-no-pie"),

It builds, yes, but I wonder the effects of adding such options 
(-no-pie) in long term use.
Ok for the hack but how long should we maintain it (mv settings.bak 
settings) ?


"""

i'm not too sure about upgrading to unstable.

thanks for the suggestion though

Fred

Le 17/11/2016 à 16:36, Ilias Tsitsimpis a écrit :

Hi Frederic,

On Thu, Nov 17, 2016 at 01:35PM, frederic wagner wrote:

I cannot build anything using stack.

to reproduce :

  stack new test simple
  cd test
  stack build

-> gives following output :
[1 of 1] Compiling Main ( /tmp/stack28309/Setup.hs,
/tmp/stack28309/Setup.o )
Linking 
/home/wagnerf/.stack/setup-exe-cache/x86_64-linux/tmp-setup-Simple-Cabal-1.24.0.0-ghc-8.0.1
...
/usr/bin/ld: /tmp/stack28309/Setup.o: relocation R_X86_64_32S against symbol
`stg_bh_upd_frame_info' can not be used when making a shared object;
recompile with -fPIC
/usr/bin/ld: 
/home/wagnerf/.stack/programs/x86_64-linux/ghc-8.0.1/lib/ghc-8.0.1/Cabal-1.24.0.0/libHSCabal-1.24.0.0.a(Simple__87.o):
relocation R_X86_64_32S against `.text' can not be used when making a shared
object; recompile with -fPIC

Thanks for reporting this.

The above works for me with haskell-stack and ghc both from unstable.
The current version of ghc in testing is known to be broken (see #712228):

   https://bugs.debian.org/712228

Could you give it a try?

Best,

Bug#844699: ITP: tdiary-style-gfm -- GFM Style for tDiary

[Youhei SASAKI]

Package: wnpp
Owner: Youhei SASAKI 
Severity: wishlist

* Package name: tdiary-style-gfm
  Version : 0.4.0-1
  Upstream Author :  2003 TADA Tadashi 
 2004 MoonWolf 
 2012 kdmsnr 
 2013 hsbt 
* URL or Web page : https://github.com/tdiary/tdiary-style-gfm
* License : GPL-3+
  Description : GFM Style for tDiary

GFM Style for tDiary (>= 2.x) format.
.
The tDiary is a weblog system, which makes your weblog
communication-friendly for the writer (you) and readers. It consists of
Ruby scripts for CGI (Common Gateway Interface).
.
This package provides GFM(Github Flavored Markdown) style.
   

Bug#844655: plasma-desktop-5: problem with autostart

[chatrapati]

Excuse me.
"firefox-esr trying to go in IP-adress "%u" "
URI-adress insted of IP-adress.

Bug#844658: stretch GIT broken

[Nikos Mavrogiannopoulos]

I think few months ago a similar issue was reported.  The culprit was librtmp 
or some other lib linking to a version of nettle with unversioned symbols. That 
resulted to a symbol clash which caused that issue. The solution was to update 
that lib.

On 18 November 2016 02:50:14 CET, Daniel Kahn Gillmor  
wrote:
>On Fri 2016-11-18 06:03:59 +0900, martin carmichael wrote:
>> Package: gnutls-bin (3.5.5-6)
>>
>>
>> message: fatal: unable to access 'https://github.com :
>gnutls_handshake() failed: Public key signature verification has
>failed.
>>
>>
>>  git --version
>> git version 2.10.2
>>
>> uname -a
>> Linux debian 4.7.0-1-amd64 #1 SMP Debian 4.7.8-1 (2016-10-19) x86_64
>GNU/Linux
>>
>> git push
>> fatal: unable to access 'https://github.com...  : gnutls_handshake()
>failed: Public key signature verification has failed.
>
>I'm not seeing this at all:
>
>0 dkg@alice:/tmp/cdtemp.B2ws82$ git clone https://github.com/dkg/s6
>Cloning into 's6'...
>remote: Counting objects: 1899, done.
>remote: Total 1899 (delta 0), reused 0 (delta 0), pack-reused 1899
>  Receiving objects: 100% (1899/1899), 503.91 KiB | 283.00 KiB/s, done.
>Resolving deltas: 100% (1169/1169), done.
>0 dkg@alice:/tmp/cdtemp.B2ws82$
>
>Regards,
>
>--dkg

-- 
Sent fron my mobile. Please excuse my brevity.

Bug#834369: ITP: python-libusb1 -- Python wrapper for libusb1

[Arnaud Fontaine]

Hello,

> Any news on the ITP ?
> If I can help getting this packaged in any way, please tell me.

Sorry for the lag. I have prepared a package:
https://people.debian.org/~arnau/packages/python-libusb1_1.5.3-1_all.deb

And the git repository of the package:
https://anonscm.debian.org/cgit/python-modules/packages/python-libusb1.git/

Please try it out.

Cheers,
-- 
Arnaud Fontaine


signature.asc
Description: PGP signature

Bug#844698: Uses hard-coded /run/media/ paths which don't work in Debian

[Michael Biebl]

Package: zulumount-cli
Version: 4.9.0-2
Severity: important

I tried to use zulumount-gui and cli together with cryfs.
Unfortunately this fails, the error message I get is that zulumount was
unable to create the mountpoint.

I suspect this is due to the use of /run/media/private/$USER

That directory does not exist here and /run is not writable for an
unprivileged user. As I run zulumount as user and not root, it is unable
to create that directory.



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

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

Versions of packages zulumount-cli depends on:
ii  libblkid1   2.29-1
ii  libc6   2.24-5
ii  libgcrypt20 1.7.3-2
ii  libzulucrypt-exe1.2.0   4.9.0-2
ii  libzulucrypt1.2.0   4.9.0-2
ii  libzulucryptpluginmanager1.0.0  4.9.0-2

zulumount-cli recommends no packages.

zulumount-cli suggests no packages.

-- no debconf information

Bug#268658: Achtung: Überprüfen Sie Ihr Outlook-Konto.

[Mira Pavlicic]

Achtung: Lieber Outlook User,



Dies ist für alle Outlook-Benutzer informieren, dass wir derzeit aktualisieren 
unsere Outlook-Konto heute und Sie haben 24 Stunden, dies zu tun.
Bitte versäumt, Ihr Outlook-Konto, Ihr Microsoft Outlook-Konto zu aktualisieren 
/ zu bestätigen, das wir aussetzen und aus unserer Datenbank löschen.

Bitte aktualisieren / überprüfen Sie Ihr Outlook-Konto Klicken Sie auf die 
Outlook Web Apps, um Ihr Outlook-Konto zu 
aktualisieren.



Danke für dein Verständnis.



ADMIN-TEAM

Bug#844694: firefox: high-lighting issues with the new release (maybe gtk3 issue ? )

[Mike Hommey]

On Fri, Nov 18, 2016 at 12:21:25PM +0530, shirish शिरीष wrote:
> Package: firefox
> Version: 50.0-1
> Severity: normal
> 
> Dear Maintainer,
> In Debian mate, previous versions of Mozilla Firefox used the
> high-lighting color (from the theme selected/used) while in the new
> version the highlighting while going through the different drop-down
> menus is unavailable. Can this be fixed ?
> 
> https://jumpshare.com/v/CMeKzSwl83vyRrEvzSEe also has the same video
> which I have attached, it shows the problem in case I have been unable
> to explain well.
> 
> Notice that the new version doesn't tell you which option you are
> choosing while in tor the green band always tells you visually which
> option you are taking.
> 
> The video has been bought to you by simplescreenrecorder.

Run gtk3-demo from the gtk-3-examples package. In the list it brings,
select "Menus" then click the "Run" button. Does the same happen there?

Mike

Bug#844697: maxima-emacs: imaxima does not load in maxima

[Emmanuel Charpentier]

Package: maxima-emacs
Version: 5.38.1-5
Severity: important

Dear Maintainer,

This is almost a duplicate of bug#842164 : maxima *cannot*
load /usr/share/emacs24/site-lisp/maxima/imaxima.lisp, which is
a symlink to /usr/share/emacs/site-lisp/maxima/imaxima.lisp, and
*can* be used :

Cut'n paste from emacs :

Maxima 5.38.1 http://maxima.sourceforge.net
using Lisp GNU Common Lisp (GCL) GCL 2.6.12
Distributed under the GNU Public License. See the file COPYING.
Dedicated to the memory of William Schelter.
The function bug_report() provides bug reporting information.
(%i1) block(load(("/usr/share/emacs24/site-lisp/maxima/imaxima.lisp")),
linenum:0)$

file_search1: /usr/share/emacs24/site-lisp/maxima/imaxima.lisp not found in
   file_search_maxima,file_search_lisp.
 -- an error. To debug this try: debugmode(true);

/* Manually done : */

(%i2) block(load(("/usr/share/emacs/site-lisp/maxima/imaxima.lisp")),
linenum:0)

After this load, imaxima works as expected...

The only maxima-related snippet in my .emacs is :

;; Pour (i)maxima
(setq imaxima-use-maxima-mode-flag t)

For completeness :
charpent@asus16-ec:~$ ls -l  /usr/share/emacs24/site-lisp/maxima/imaxima.lisp
lrwxrwxrwx 1 root root 46 nov.   4 09:00 /usr/share/emacs24/site-
lisp/maxima/imaxima.lisp -> /usr/share/emacs/site-lisp/maxima/imaxima.lisp
charpent@asus16-ec:~$ ls -l /usr/share/emacs/site-lisp/maxima/imaxima.lisp
-rw-r--r-- 1 root root 22299 nov.   1 14:00 /usr/share/emacs/site-
lisp/maxima/imaxima.lisp

HTH,

--
Emmanuel Charpentier



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

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

Versions of packages maxima-emacs depends on:
ii  emacs24 [emacsen]24.5+1-7
ii  emacsen-common   2.0.8
ii  maxima   5.38.1-5
ii  maxima-doc   5.38.1-5
ii  tex-common   6.05
ii  texlive-binaries [texlive-base-bin]  2016.20160513.41080-6
ii  texlive-latex-recommended2016.20161103-1

Versions of packages maxima-emacs recommends:
ii  evince [postscript-viewer]   3.22.1-2
ii  ghostscript [postscript-viewer]  9.19~dfsg-3.1
ii  mime-support 3.60
ii  xpdf [pdf-viewer]3.04-1+b1

maxima-emacs suggests no packages.

-- no debconf information

Bug#844696: And the patches...

[Mathieu Parent]

See attached patches.

Regards

-- 
Mathieu Parent
From f12fe5c931a8c47bd606671bf2c9cd3ba940f984 Mon Sep 17 00:00:00 2001
From: Mathieu Parent 
Date: Sat, 5 Nov 2016 21:36:54 +0100
Subject: [PATCH 1/2] Add luasandbox-lpeg (Closes: #844696)

---
 debian/control| 2 +-
 debian/luasandbox.dh-lua.conf | 1 +
 2 files changed, 2 insertions(+), 1 deletion(-)
 create mode 12 debian/luasandbox.dh-lua.conf

diff --git a/debian/control b/debian/control
index 2cbb602..cc90429 100644
--- a/debian/control
+++ b/debian/control
@@ -2,7 +2,7 @@ Source: lua-lpeg
 Section: interpreters
 Priority: optional
 Maintainer: Enrico Tassi 
-Build-Depends: dh-lua, debhelper (>= 8.0.0)
+Build-Depends: dh-lua (>= 24~), debhelper (>= 8.0.0)
 Standards-Version: 3.9.6
 Homepage: http://www.inf.puc-rio.br/~roberto/lpeg.html
 Vcs-Git: git://git.debian.org/git/pkg-lua/lua-lpeg.git
diff --git a/debian/luasandbox.dh-lua.conf b/debian/luasandbox.dh-lua.conf
new file mode 12
index 000..ba875b6
--- /dev/null
+++ b/debian/luasandbox.dh-lua.conf
@@ -0,0 +1 @@
+lua5.1.dh-lua.conf
\ No newline at end of file
-- 
2.10.2

From 6b805e8f1e8c0275666229ef494f7c4f4bb96ae5 Mon Sep 17 00:00:00 2001
From: Mathieu Parent 
Date: Fri, 18 Nov 2016 06:28:58 +0100
Subject: [PATCH 2/2] Release 0.12.2-2

---
 debian/changelog | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/debian/changelog b/debian/changelog
index e1c34de..e5a5ee2 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,10 @@
+lua-lpeg (0.12.2-2) unstable; urgency=medium
+
+  * Team upload
+  * Add luasandbox-lpeg (Closes: #844696)
+
+ -- Mathieu Parent   Fri, 18 Nov 2016 08:57:36 +0100
+
 lua-lpeg (0.12.2-1) unstable; urgency=medium
 
   * New upstream release
-- 
2.10.2

Bug#843520: [debian-mysql] Bug#843520: Bug#843520: Bug#843520: mysql-server-5.5 cannot be automatically upgraded

[Lars Tangvald]

On 11/18/2016 08:00 AM, Lars Tangvald wrote:

Hi,

On 11/17/2016 06:02 PM, Jean Louis wrote:

I am sorry, that I filed bug in the wrong package, it was
unintentional mistake. It should be in mysql-server. And I know all
about specifics.

In my case, there is nothing that I have changed in my Mysql
configuration from the plain install. That is why I filed the
bug. Otherwise I would look first on my side.

And I was surprised it did not work, as I was used to the stability
and certainty when upgrading.

I could not find the solution

I was reading other bugs and I found:

[mysqld]
secure_file_priv = /var/lib/mysql

So I have put it in /etc/mysql/conf.d and now I got it working. Even I
don't even know what is it about, as being so lazy to read the
documentation. Sorry.

Still I think it should not be like that, the upgrade should go
smooth, especially for databases. Nothing angers me, thank you for
putting attention. I am supporter of free software and use Debian on
remote servers.

Jean Louis

Hi,

In this case, the server defaults to 
secure_file_priv=/var/lib/mysql-files, and will require this directory 
to be created.
This is a big change to make in a stable release, but the old behavior 
was a potential security risk, so we felt it was justified. The 
upgrade _should_ have created this directory automatically, so if it 
failed for you then there's probably something with your environment 
we didn't account for. If you have any console logs or mysql error 
logs from the update it would be good if you can attach them to the bug.


One important note, however:
The solution you note, setting secure_file_priv=/var/lib/mysql (the 
data directory) is not a good one. You should either set it to NULL or 
to a separate, empty directory owned by the mysql user.


The secure_file_priv setting determines where the server is allowed to 
read and write files using import/export operations. Setting it to the 
same location as the database will mean that any user of your database 
can get full access.



Correction here: You need the FILE privilege to use these operations.

--
Lars

Bug#811634: meshlab: FTBFS with GCC 6: cannot convert x to y

[Graham Inggs]

On 17 November 2016 at 18:27, Graham Inggs  wrote:
> Copying to debian-science-maintainers list in case someone is
> interested in rescuing this package.

Meshlab is already maintained in the debian-science's git repository [1].
All of Teemu Ikonen's other packages have Debian Science Maintainers
in the Maintainer field.

I will update the Maintainer field and prepare a team upload.


[1] https://anonscm.debian.org/cgit/debian-science/packages/meshlab.git/