Bug#803149: [php-maint] Bug#803149: libapache2-mod-php5: Segfaulting in zend_hash_find

[Ondřej Surý]

Control: reassign -1 php5-xcache
Control: found -1 php5-xcache/3.2.0-1

Hi Lukas,

On Wed, Oct 28, 2015, at 11:46, Lukas Barth wrote:
> On 10/28/2015 09:05 AM, Ondřej Surý wrote:
> > could you try disabling xcache?
> 
> That fixes it! Please let me know if I can help with debugging any
> further. I'm fine with running without xcache, but this is probably
> something that should be fixed anyway?

I am reassigning the package to php5-xcache package, so it could be
handled there.

Cheers,
-- 
Ondřej Surý 
Knot DNS (https://www.knot-dns.cz/) – a high-performance DNS server

Bug#803244: [php-maint] Bug#803244: php5-common: upgrading enables manually disabled opcache

[Ondřej Surý]

Control: severity -1 minor
Control: reassign 797350 php5-common
Control: forcemerge 797350 -1

Dear Antti,

yes, the documentation on module management could be improved, and it
has been already filled as 803244.

Cheers,
Ondrej

On Wed, Oct 28, 2015, at 12:30, Antti Salmela wrote:
> Package: php5-common
> Version: 5.6.14+dfsg-0+deb8u1
> Severity: serious
> 
> Dear Maintainer,
> 
> I was under impression that maintainer scripts shouldn't recreate
> configuration files removed by system administrator. php5-common just
> recreated symbolic link from /etc/php5/sapi/conf.d/05-opcache.ini to
> mods-available,
> which I had removed since xcache works better for us and enabling both
> segfaults apache.
> 
> And yes, after enough digging I found about php5dismod and
> /var/lib/php5/modules/fpm/disabled_by_admin/,
> but this behaviour is quite unexpected.
> 
> -- Package-specific info:
>  Additional PHP 5 information 
> 
>  PHP 5 SAPI (php5query -S): 
> fpm
> cli
> cgi
> 
>  PHP 5 Extensions (php5query -M -v): 
> mysql (Enabled for fpm by maintainer script)
> mysql (Enabled for cli by maintainer script)
> mysql (Enabled for cgi by maintainer script)
> pspell (Enabled for fpm by maintainer script)
> pspell (Enabled for cli by maintainer script)
> pspell (Enabled for cgi by maintainer script)
> intl (Enabled for fpm by maintainer script)
> intl (Enabled for cli by maintainer script)
> intl (Enabled for cgi by maintainer script)
> pdo (Enabled for fpm by maintainer script)
> pdo (Enabled for cli by maintainer script)
> pdo (Enabled for cgi by maintainer script)
> mysqli (Enabled for fpm by maintainer script)
> mysqli (Enabled for cli by maintainer script)
> mysqli (Enabled for cgi by maintainer script)
> curl (Enabled for fpm by maintainer script)
> curl (Enabled for cli by maintainer script)
> curl (Enabled for cgi by maintainer script)
> mcrypt (Enabled for fpm by maintainer script)
> mcrypt (Enabled for cli by maintainer script)
> mcrypt (Enabled for cgi by maintainer script)
> pdo_mysql (Enabled for fpm by maintainer script)
> pdo_mysql (Enabled for cli by maintainer script)
> pdo_mysql (Enabled for cgi by maintainer script)
> gd (Enabled for fpm by maintainer script)
> gd (Enabled for cli by maintainer script)
> gd (Enabled for cgi by maintainer script)
> pgsql (Enabled for fpm by maintainer script)
> pgsql (Enabled for cli by maintainer script)
> pgsql (Enabled for cgi by maintainer script)
> pdo_sqlite (Enabled for fpm by maintainer script)
> pdo_sqlite (Enabled for cli by maintainer script)
> pdo_sqlite (Enabled for cgi by maintainer script)
> pdo_pgsql (Enabled for fpm by maintainer script)
> pdo_pgsql (Enabled for cli by maintainer script)
> pdo_pgsql (Enabled for cgi by maintainer script)
> json (Enabled for fpm by maintainer script)
> json (Enabled for cli by maintainer script)
> json (Enabled for cgi by maintainer script)
> imap (Enabled for fpm by maintainer script)
> imap (Enabled for cli by maintainer script)
> imap (Enabled for cgi by maintainer script)
> xcache (Enabled for fpm by maintainer script)
> xcache (Enabled for cli by maintainer script)
> xcache (Enabled for cgi by maintainer script)
> sqlite3 (Enabled for fpm by maintainer script)
> sqlite3 (Enabled for cli by maintainer script)
> sqlite3 (Enabled for cgi by maintainer script)
> 
>  Configuration files: 
>  /etc/php5/mods-available/pdo.ini 
> extension=pdo.so
> 
>  /etc/php5/mods-available/opcache.ini 
> zend_extension=opcache.so
> 
> 
> -- System Information:
> Debian Release: 8.2
>   APT prefers stable
>   APT policy: (900, 'stable'), (890, 'testing'), (499, 'unstable'), (101,
>   'experimental')
> Architecture: amd64 (x86_64)
> 
> Kernel: Linux 3.16.0-4-amd64 (SMP w/4 CPU cores)
> Locale: LANG=en_US.UTF-8, LC_CTYPE=fi_FI.UTF-8 (charmap=UTF-8)
> Shell: /bin/sh linked to /bin/dash
> Init: systemd (via /run/systemd/system)
> 
> Versions of packages php5-common depends on:
> ii  libc6   2.19-18+deb8u1
> ii  lsof4.86+dfsg-1
> ii  psmisc  22.21-2
> ii  sed 4.2.2-4+b1
> ii  ucf 3.0030
> 
> php5-common recommends no packages.
> 
> Versions of packages php5-common suggests:
> ii  php5-xcache [php5-user-cache]  3.2.0-1
> 
> Versions of packages php5-cli depends on:
> ii  libbz2-1.01.0.6-7+b3
> ii  libc6 2.19-18+deb8u1
> ii  libcomerr21.42.12-1.1
> ii  libdb5.3  5.3.28-9
> ii  libedit2  3.1-20140620-2
> ii  libgssapi-krb5-2  1.12.1+dfsg-19
> ii  libk5crypto3  1.12.1+dfsg-19
> ii  libkrb5-3 1.12.1+dfsg-19
> ii  libmagic1 1:5.22+15-2
> ii  libonig2  5.9.5-3.2
> ii  libpcre3  2:8.35-3.3
> ii  libqdbm14 1.8.78-5+b1
> ii  libssl1.0.0   1.0.2d-1
> ii  libxml2   2.9.1+dfsg1-5
> ii  mime-support  3.58
> ii  php5-json 1.3.6-1
> ii  tzdata2015f-0+deb8u1
> ii  ucf   3.0030
> ii  zlib1g1:1.2.8.dfsg-2+b1
> 
> Versions of packages php5-cli recommends:
> pn 

Bug#803251: maxima do not load the draw package.

[Renato Alvarez Nodarse]

Package: maxima
Version: 5.37.2-7
Severity: normal

Dear Maintainer,

Reporter, please consider answering these questions, where appropriate

When one writes
load(draw); the result is loadfile: failed to load
/usr/share/maxima/5.37.2/share/draw/draw.lisp
but the file is present in the aforesaid location. This happens in console mode
and also woth wxmaxima and Xmaxima
as well. That is the exact outcome.

(%i3) load(draw);
loadfile: failed to load /usr/share/maxima/5.37.2/share/draw/draw.lisp
 -- an error. To debug this try: debugmode(true);

After that all the draw commands onviously do not work. In the stable version
it is working
and in my previous testing version 5.36 it was also working. This happens after
my last updating
yesterday Octuber 28, 2015

Sincerely yours

Renato



-- System Information:
Debian Release: stretch/sid
  APT prefers testing
  APT policy: (900, 'testing'), (100, 'stable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

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

Versions of packages maxima depends on:
ii  libc6 2.19-22
ii  libgmp10  2:6.0.0+dfsg-7
ii  libreadline6  6.3-8+b3
ii  libx11-6  2:1.6.3-1

Versions of packages maxima recommends:
ii  gnuplot-x11   4.6.6-3
ii  maxima-share  5.37.2-6

Versions of packages maxima suggests:
ii  maxima-doc5.37.2-6
pn  maxima-emacs  
pn  texmacs   
ii  tk [wish] 8.6.0+8
pn  xmaxima   

-- no debconf information

Bug#803252: util-linux: avoid static build of fdisk-udeb

[Andreas Henriksson]

Source: util-linux
Version: 2.27-2
Severity: wishlist
Tags: help

It would be nice if we could revert the changes made in 2.27-2 and 2.27-3
and again build the udebs dynamically.

The problem (originally reported in http://bugs.debian.org/798347 ) is
that both fdisk and sfdisk has since v2.27 (upstream release) picked
up dependencies on libtinfo5 (from src:ncurses) via libtcolors.la,
which in turn caused fdisk-udeb to depend on tinfo deb (which there
is no udeb for).

See:
disk-utils/Makemodule.am where libtcolors.la is added to fdisk_LDADD etc.
lib/Makemodule.am for libtcolors_la_SOURCES
lib/colors.c which contains #ifdef HAVE_LIBTINFO
configure.ac which has AC_ARG_WITH([tinfo], AS_HELP_STRING([--without-tinfo], 
...

In theory I guess we should be able to do a build which just disables
tinfo via configure At the same time we want tinfo enabled for the
normal .deb builds

Doing multi-flavor builds with dh is a hassle. Switching over to CDBS only
for this seems like much work for little win. Maybe there's some simple
hack to rebuild just fdisk and sfdisk --without-tinfo, but special
considerations needs to be taken to make sure whatever solution we end
up with is dead simple to maintain. In my opinion it's not worth adding
maintenance burden to solve this issue Hopefully we'll come up with
something easy soon but filing this bug report as a reminder.

An alternative to all of the above is to convince src:ncurses maintainers
to add a tinfo udeb (but configurable terminal colors support is probably
something we'd like to see disabled in the udeb build anyway)

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

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

Versions of packages util-linux depends on:
ii  initscripts 2.88dsf-59.2
ii  libblkid1   2.27-1
ii  libc6   2.19-18+deb8u1
ii  libfdisk1   2.27-1
ii  libmount1   2.27-1
ii  libncursesw55.9+20140913-1+b1
ii  libpam0g1.1.8-3.1
ii  libselinux1 2.3-2
ii  libsmartcols1   2.27-1
ii  libsystemd0 215-17+deb8u2
ii  libtinfo5   5.9+20140913-1+b1
ii  libuuid12.27-1
ii  lsb-base4.1+Debian13+nmu1
ii  sysvinit-utils  2.88dsf-59.2
ii  tzdata  2015g-0+deb8u1
ii  zlib1g  1:1.2.8.dfsg-2+b1

util-linux recommends no packages.

Versions of packages util-linux suggests:
ii  dosfstools   3.0.27-1
pn  kbd | console-tools  
ii  util-linux-locales   2.25.2-6

-- debconf information excluded

Bug#786957: php-cgi: segfault after exec

[Ondřej Surý]

Dear NetLeaders,

unfortunately you have filled the bug against a wrong package (php-cgi
vs php5-cgi) and thus the bug script was not executed.

Could you run this command on affected system:

/usr/share/bug/php5-cli/script 3>&1

and attach the output to the #786957 bug?

Also upgrade to latest available version first before trying to
reproduce the bug again.

As a side note it's usually better to use php5-fpm these days instead of
running a pure php5-cgi in FastCGI mode.

Cheers,
-- 
Ondřej Surý 
Knot DNS (https://www.knot-dns.cz/) – a high-performance DNS server

Bug#803253: mosh: error: --compare-versions takes three arguments:

[Jakub Wilk]

Package: mosh
Version: 1.2.5-1+b1

I get this when I install mosh:

Preparing to unpack .../mosh_1.2.5-1+b1_i386.deb ...
dpkg: error: --compare-versions takes three arguments:   


Type dpkg --help for help about installing and deinstalling packages [*];
Use 'apt' or 'aptitude' for user-friendly package management;
Type dpkg -Dhelp for a list of dpkg debug flag values;
Type dpkg --force-help for a list of forcing options;
Type dpkg-deb --help for help about manipulating *.deb files;

Options marked [*] produce a lot of output - pipe it through 'less' or 'more' !
Unpacking mosh (1.2.5-1+b1) ...


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

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

Versions of packages mosh depends on:
ii  dpkg1.18.3
ii  libc6   2.19-22
ii  libgcc1 1:5.2.1-22
ii  libprotobuf9v5  2.6.1-1.3
ii  libssl1.0.0 1.0.2d-1
ii  libstdc++6  5.2.1-22
ii  libtinfo5   6.0+20151024-1
ii  libutempter01.1.6-1
ii  openssh-client  1:6.9p1-2
ii  zlib1g  1:1.2.8.dfsg-2+b1

Versions of packages mosh recommends:
ii  perl-base [libio-socket-ip-perl]  5.20.2-6

--
Jakub Wilk

Bug#803254: xserver-xorg-core: Compile Xorg against libsystemd-daemon-dev, to enable socket activation support.

[Jeremiejig]

Package: xserver-xorg-core
Version: 2:1.16.4-1+aptbuild5
Severity: wishlist

Dear Maintainer,

I hope to see Xorg compiled with libsystemd to have systemd socket
activation support.
I checked the package xserver-xorg-core_1.17.2-3_amd64.deb (stretch)
with `grep sd_listen usr/lib/Xorg`, and got a negative match
`ldd usr/lib/Xorg` show that it isn't compiled with libsystemd

My version of xserver-xorg is compiled with the flag
(--with-systemd-daemon) to see if which package was required for the
build (libsystemd-daemon-dev)

Below are the xorg@.service and xorg@.socket I used to test the socket
activation.

Feel free to change /usr/bin/X with /usr/bin/Xorg to test X without root
if the graphic cards support its.

ls -l /usr/bin/X
-rwsr-sr-x 1 root root 10104 avril  1  2014 /usr/bin/X


Best regards


-- /etc/systemd/system/xorg@.service

[Unit]
Description=Xorg server for UID %I.
Requires=xorg@%i.socket
After=systemd-user-sessions.service
After=rc-local.service

# On systems without virtual consoles, don't start any getty. Note
# that serial gettys are covered by serial-getty@.service, not this
# unit.
ConditionPathExists=/dev/tty0

[Service]
Type=idle
User=%i
ExecStart=/usr/bin/X :%i -nolisten tcp -seat seat0 -auth 
/run/xorg-server/auth-%i/database -terminate vt10

PAMName=systemd-xsession

StandardInput=tty
StandardOutput=tty
StandardError=syslog
TTYPath=/dev/tty10

Sockets=xorg@%i.socket

Slice=user-%i.slice


-- /etc/systemd/system/xorg@.socket
---
[Unit]
Description=Xorg Socket for User UID %i

[Socket]
ExecStartPre=-/bin/mkdir -p -m 711 /run/xorg-server
ExecStartPre=-/bin/mkdir -p -m 750 /run/xorg-server/auth-%i
ExecStartPre=/bin/touch /run/xorg-server/auth-%i/database
ExecStartPre=/bin/bash -c "xauth -f /run/xorg-server/auth-%i/database add :%i . 
`mcookie`"
ExecStartPre=/bin/chown -R %i /run/xorg-server/auth-%i
ExecStopPost=-/bin/rm -rf /run/xorg-server/auth-%i
UMask=0027

ListenStream=/tmp/.X11-unix/X%i
SocketMode=0777
DirectoryMode=1777

[Install]
WantedBy=sockets.target


-- Package-specific info:
X server symlink status:

lrwxrwxrwx 1 root root 13 Oct 18 16:09 /etc/X11/X -> /usr/bin/Xorg
-rwxr-xr-x 1 root root 2409824 Oct 26 15:32 /usr/bin/Xorg

Kernel version (/proc/version):
---
Linux version 3.16.0-4-amd64 (debian-ker...@lists.debian.org) (gcc version 
4.8.4 (Debian 4.8.4-1) ) #1 SMP Debian 3.16.7-ckt11-1+deb8u5 (2015-10-09)

Contents of most recent Xorg X server log file (/var/log/Xorg.1000.log):

[317697.276] 
X.Org X Server 1.16.4
Release Date: 2014-12-20
[317697.276] X Protocol Version 11, Revision 0
[317697.276] Build Operating System: Linux 3.16.0-4-amd64 x86_64 Debian
[317697.276] Current Operating System: Linux jpaul-linux 3.16.0-4-amd64 #1 SMP 
Debian 3.16.7-ckt11-1+deb8u5 (2015-10-09) x86_64
[317697.276] Kernel command line: placeholder 
root=UUID=1b8c27ad-01f2-4c72-84ca-df50e1017920 ro
[317697.276] Build Date: 26 October 2015  03:24:39PM
[317697.276] xorg-server 2:1.16.4-1+aptbuild5 (http://www.debian.org/support) 
[317697.276] Current version of pixman: 0.32.6
[317697.276]Before reporting problems, check http://wiki.x.org
to make sure that you have the latest version.
[317697.276] Markers: (--) probed, (**) from config file, (==) default setting,
(++) from command line, (!!) notice, (II) informational,
(WW) warning, (EE) error, (NI) not implemented, (??) unknown.
[317697.276] (==) Log file: "/var/log/Xorg.1000.log", Time: Wed Oct 28 10:59:43 
2015
[317697.276] (==) Using system config directory "/usr/share/X11/xorg.conf.d"
[317697.276] (==) No Layout section.  Using the first Screen section.
[317697.276] (==) No screen section available. Using defaults.
[317697.276] (**) |-->Screen "Default Screen Section" (0)
[317697.276] (**) |   |-->Monitor ""
[317697.276] (==) No monitor specified for screen "Default Screen Section".
Using a default monitor configuration.
[317697.276] (==) Automatically adding devices
[317697.276] (==) Automatically enabling devices
[317697.276] (==) Automatically adding GPU devices
[317697.276] (WW) The directory "/usr/share/fonts/X11/cyrillic" does not exist.
[317697.276]Entry deleted from font path.
[317697.277] (==) FontPath set to:
/usr/share/fonts/X11/misc,
/usr/share/fonts/X11/100dpi/:unscaled,
/usr/share/fonts/X11/75dpi/:unscaled,
/usr/share/fonts/X11/Type1,
/usr/share/fonts/X11/100dpi,
/usr/share/fonts/X11/75dpi,
built-ins
[317697.277] (==) ModulePath set to "/usr/lib/xorg/modules"
[317697.277] (II) The server relies on udev to provide the list of input 
devices.
If no devices become available, reconfigure udev or disable 
AutoAddDevices.
[317697.277] (II) Loader magic: 0x7f13d2d39e40
[317697.277] (II) Module ABI versions:
[317697.277]X.Org ANSI C Emulation

Bug#803255: exim4: segfault upon reading /etc/email-addresses

[Sylvain LEVEQUE]

Package: exim4
Version: 4.86-4
Severity: important

Dear Maintainer,

After upgrading from exim4 4.86-3 to 4.86-4, I observe a segfault when 
/etc/email-addresses is looked up by sendmail/exim and an entry with a 
rewriting rule is found. These mails don't get sent.

Commenting out the corresponding line in /etc/email-addresses fixes the 
problem. 

I am seeing this segfault on armel, but not on amd64.

# cat /etc/email-addresses
# This is /etc/email-addresses. It is part of the exim package
#
# This file contains email addresses to use for outgoing mail. Any local
# part not in here will be qualified by the system domain as normal.
#
# It should contain lines of the form:
#
#user: some...@isp.com
#otheruser: someonee...@anotherisp.com
sleveque: sylv...@gromi.net
monit@donkeykong: sylv...@gromi.net
root: sylv...@gromi.net

# echo "Subject: test" | /usr/lib/sendmail -v sylv...@gromi.net
Segmentation fault

# echo "Subject: test" | strace /usr/lib/sendmail -v sylv...@gromi.net
[snip]
rt_sigaction(SIGTERM, {0xb6ec3b4c, [TERM], SA_RESTORER|SA_RESTART, 0xb68accf0}, 
{SIG_DFL, [], 0}, 8) = 0
rt_sigaction(SIGINT, {0xb6ec3b4c, [INT], SA_RESTORER|SA_RESTART, 0xb68accf0}, 
{SIG_DFL, [], 0}, 8) = 0
fstat64(0, {st_mode=S_IFIFO|0600, st_size=0, ...}) = 0
mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 
0xb6e58000
read(0, "Subject: test\n", 4096)= 14
read(0, "", 4096)   = 0
open("/etc/email-addresses", O_RDONLY|O_LARGEFILE) = 4
fstat64(4, {st_mode=S_IFREG|0644, st_size=400, ...}) = 0
fstat64(4, {st_mode=S_IFREG|0644, st_size=400, ...}) = 0
mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 
0xb6e57000
_llseek(4, 0, [0], SEEK_SET)= 0
read(4, "# This is /etc/email-addresses. "..., 4096) = 400
read(4, "", 4096)   = 0
--- SIGSEGV {si_signo=SIGSEGV, si_code=SEGV_MAPERR, si_addr=0xc8b80b28} ---
+++ killed by SIGSEGV +++
Segmentation fault

# cat /etc/email-addresses
# This is /etc/email-addresses. It is part of the exim package
#
# This file contains email addresses to use for outgoing mail. Any local
# part not in here will be qualified by the system domain as normal.
#
# It should contain lines of the form:
#
#user: some...@isp.com
#otheruser: someonee...@anotherisp.com
sleveque: sylv...@gromi.net
monit@donkeykong: sylv...@gromi.net
#root: sylv...@gromi.net

# echo "Subject: test" | /usr/lib/sendmail -v sylv...@gromi.net
LOG: MAIN
  <= r...@donkeykong.gromi.net U=root P=local S=358
donkeykong:~# delivering 1ZrPx0-0002Kr-GX
R: smarthost for sylv...@gromi.net
T: remote_smtp_smarthost for sylv...@gromi.net
Connecting to XXX:25 ... connected
  SMTP<< 220  ESMTP Postfix
  SMTP>> EHLO donkeykong.gromi.net
  SMTP<< 250-
 250-PIPELINING
 250-SIZE 3500
 250-VRFY
 250-ETRN
 250-STARTTLS
 250-ENHANCEDSTATUSCODES
 250-8BITMIME
 250 DSN
  SMTP>> STARTTLS
  SMTP<< 220 2.0.0 Ready to start TLS
  SMTP>> EHLO donkeykong.gromi.net
  SMTP<< 250-
 250-PIPELINING
 250-SIZE 3500
 250-VRFY
 250-ETRN
 250-ENHANCEDSTATUSCODES
 250-8BITMIME
 250 DSN
  SMTP>> MAIL FROM: SIZE=1390
  SMTP>> RCPT TO:
  SMTP>> DATA
  SMTP<< 250 2.1.0 Ok
  SMTP<< 250 2.1.5 Ok
  SMTP<< 354 End data with .
  SMTP>> writing message and terminating "."
  SMTP<< 250 2.0.0 Ok: queued as 8F372D480B3
  SMTP>> QUIT
LOG: MAIN
  => sylv...@gromi.net R=smarthost T=remote_smtp_smarthost H=X 
[XX] X=TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128 CV=no 
DN="OU=GT42558204,OU=See www.rapidssl.com/resources/cps (c)15,OU=Domain Control 
Validated - RapidSSL(R),CN=" C="250 2.0.0 Ok: queued as 8F372D480B3"
LOG: MAIN
  Completed

-- Package-specific info:
Exim version 4.86 #3 built 17-Oct-2015 13:01:01
Copyright (c) University of Cambridge, 1995 - 2015
(c) The Exim Maintainers and contributors in ACKNOWLEDGMENTS file, 2007 - 2015
Berkeley DB: Berkeley DB 5.3.28: (September  9, 2013)
Support for: crypteq iconv() IPv6 GnuTLS move_frozen_messages DKIM DNSSEC PRDR 
OCSP
Lookups (built-in): lsearch wildlsearch nwildlsearch iplsearch cdb dbm dbmjz 
dbmnz dnsdb dsearch nis nis0 passwd
Authenticators: cram_md5 plaintext
Routers: accept dnslookup ipliteral manualroute queryprogram redirect
Transports: appendfile/maildir/mailstore autoreply lmtp pipe smtp
Fixed never_users: 0
Size of off_t: 8
Configuration file is /var/lib/exim4/config.autogenerated

-- System Information:
Debian Release: stretch/sid
  APT prefers testing
  APT policy: (990, 'testing'), (50, 'unstable'), (40, 'experimental')
Architecture: armel (armv5tel)

Kernel: Linux 3.15-rc8-kirkwood
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)

Versions of packages exim4 depends on:
ii  debconf [debconf-2.0]  1.5.57
ii  exim4-base 4.86-4

Bug#803242: Processed: Re: Bug#803242: pybuild leaves artefacts from testing, and produces different packages with nocheck

[Matthias Klose]

Control: reassign -1 dh-python
Control: retitle -1 pybuild leaves artefacts from testing, and produces 
different packages with nocheck


a reassignment without comment, but a rant on irc:

 doko: Et tu, Brute? python3.5 setup.py test is doing bad things and you 
report bugs against dh-python? yes, if you do not use puybuild setup.py is NOT 
invoked and bug is not exposed, but IT DOESN'T MEAN the bug is in dh-python


this behaviour is rude.

And even the change of the bug title is wrong. This behaviour is the very same 
as in python3.4.  Attaching a build log.




On 28.10.2015 13:12, Debian Bug Tracking System wrote:

Processing commands for cont...@bugs.debian.org:


retitle 803242 python3.5 creates versioned egg-dir when setup.py test is invoked

Bug #803242 [dh-python] pybuild leaves artefacts from testing, and produces 
different packages with nocheck
Changed Bug title to 'python3.5 creates versioned egg-dir when setup.py test is 
invoked' from 'pybuild leaves artefacts from testing, and produces different 
packages with nocheck'

reassign 803242 python3.5 3.5.0-3

Bug #803242 [dh-python] python3.5 creates versioned egg-dir when setup.py test 
is invoked
Bug reassigned from package 'dh-python' to 'python3.5'.
No longer marked as found in versions dh-python/2.20150826.
Ignoring request to alter fixed versions of bug #803242 to the same values 
previously set
Bug #803242 [python3.5] python3.5 creates versioned egg-dir when setup.py test 
is invoked
Marked as found in versions python3.5/3.5.0-3.

thanks

Stopping processing here.

Please contact me if you need assistance.



dpkg-buildpackage: source package zope.testing
dpkg-buildpackage: source version 4.5.0-2
dpkg-buildpackage: source distribution unstable
dpkg-buildpackage: source changed by Barry Warsaw 
 dpkg-source --before-build zope.testing-4.5.0
dpkg-buildpackage: host architecture amd64
dpkg-source: info: using options from zope.testing-4.5.0/debian/source/options: 
--extend-diff-ignore=\.egg-info
 fakeroot debian/rules clean
dh clean --with python2,python3 --buildsystem=pybuild
   dh_testdir -O--buildsystem=pybuild
   dh_auto_clean -O--buildsystem=pybuild
I: pybuild base:170: python2.7 setup.py clean 
running clean
removing '/home/packages/tmp/zope.testing-4.5.0/.pybuild/pythonX.Y_2.7/build' 
(and everything under it)
'build/bdist.linux-x86_64' does not exist -- can't clean it
'build/scripts-2.7' does not exist -- can't clean it
I: pybuild base:170: python3.5 setup.py clean 
running clean
removing '/home/packages/tmp/zope.testing-4.5.0/.pybuild/pythonX.Y_3.5/build' 
(and everything under it)
'build/bdist.linux-x86_64' does not exist -- can't clean it
'build/scripts-3.5' does not exist -- can't clean it
I: pybuild base:170: python3.4 setup.py clean 
running clean
removing '/home/packages/tmp/zope.testing-4.5.0/.pybuild/pythonX.Y_3.4/build' 
(and everything under it)
'build/bdist.linux-x86_64' does not exist -- can't clean it
'build/scripts-3.4' does not exist -- can't clean it
   dh_clean -O--buildsystem=pybuild
 debian/rules build
dh build --with python2,python3 --buildsystem=pybuild
   dh_testdir -O--buildsystem=pybuild
   dh_auto_configure -O--buildsystem=pybuild
I: pybuild base:170: python2.7 setup.py config 
running config
I: pybuild base:170: python3.5 setup.py config 
running config
I: pybuild base:170: python3.4 setup.py config 
running config
   dh_auto_build -O--buildsystem=pybuild
I: pybuild base:170: /usr/bin/python setup.py build 
running build
running build_py
creating /home/packages/tmp/zope.testing-4.5.0/.pybuild/pythonX.Y_2.7/build/zope
copying src/zope/__init__.py -> 
/home/packages/tmp/zope.testing-4.5.0/.pybuild/pythonX.Y_2.7/build/zope
creating 
/home/packages/tmp/zope.testing-4.5.0/.pybuild/pythonX.Y_2.7/build/zope/testing
copying src/zope/testing/module.py -> 
/home/packages/tmp/zope.testing-4.5.0/.pybuild/pythonX.Y_2.7/build/zope/testing
copying src/zope/testing/doctestcase.py -> 
/home/packages/tmp/zope.testing-4.5.0/.pybuild/pythonX.Y_2.7/build/zope/testing
copying src/zope/testing/wait.py -> 
/home/packages/tmp/zope.testing-4.5.0/.pybuild/pythonX.Y_2.7/build/zope/testing
copying src/zope/testing/server.py -> 
/home/packages/tmp/zope.testing-4.5.0/.pybuild/pythonX.Y_2.7/build/zope/testing
copying src/zope/testing/renormalizing.py -> 
/home/packages/tmp/zope.testing-4.5.0/.pybuild/pythonX.Y_2.7/build/zope/testing
copying src/zope/testing/setupstack.py -> 
/home/packages/tmp/zope.testing-4.5.0/.pybuild/pythonX.Y_2.7/build/zope/testing
copying src/zope/testing/exceptions.py -> 
/home/packages/tmp/zope.testing-4.5.0/.pybuild/pythonX.Y_2.7/build/zope/testing
copying src/zope/testing/__init__.py -> 
/home/packages/tmp/zope.testing-4.5.0/.pybuild/pythonX.Y_2.7/build/zope/testing
copying src/zope/testing/cleanup.py -> 
/home/packages/tmp/zope.testing-4.5.0/.pybuild/pythonX.Y_2.7/build/zope/testing
copying src/zope/testing/formparser.py -> 
/home/packages/tmp/zope.testing-4.5.0/.pybuild/pythonX.Y_2.7/build/zope/testing
copyi

Bug#784070: mdadm: diff for NMU version 3.3.2-5.1

[yann-externe . soubeyrand]

Control: tags 784070 + patch

Dear maintainer,

I'm about to prepare an NMU for mdadm (versioned as 3.3.2-5.1). The diff is
attached to this message. Let me know if you want me to upload it.

Regards.
diff -Nru mdadm-3.3.2/debian/changelog mdadm-3.3.2/debian/changelog
--- mdadm-3.3.2/debian/changelog2014-12-20 09:48:54.0 +0100
+++ mdadm-3.3.2/debian/changelog2015-10-28 09:23:56.0 +0100
@@ -1,3 +1,11 @@
+mdadm (3.3.2-5.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * disable-incremental-assembly.patch: incremental assembly prevents booting
+in degraded mode (Closes: #784070)
+
+ -- Yann Soubeyrand   Tue, 27 Oct 2015 
17:16:30 +0100
+
 mdadm (3.3.2-5) unstable; urgency=medium
 
   * use-tempnode-not-devnode.patch: change udev rules file to use
diff -Nru mdadm-3.3.2/debian/patches/disable-incremental-assembly.patch 
mdadm-3.3.2/debian/patches/disable-incremental-assembly.patch
--- mdadm-3.3.2/debian/patches/disable-incremental-assembly.patch   
1970-01-01 01:00:00.0 +0100
+++ mdadm-3.3.2/debian/patches/disable-incremental-assembly.patch   
2015-10-28 09:14:09.0 +0100
@@ -0,0 +1,12 @@
+--- a/udev-md-raid-assembly.rules
 b/udev-md-raid-assembly.rules
+@@ -25,6 +25,9 @@ GOTO="md_inc_end"
+
+ LABEL="md_inc"
+
++# Disable incremental assembly to fix Debian bug #784070
++GOTO="md_inc_end"
++
+ # remember you can limit what gets auto/incrementally assembled by
+ # mdadm.conf(5)'s 'AUTO' and selectively whitelist using 'ARRAY'
+ ACTION=="add|change", IMPORT{program}="BINDIR/mdadm --incremental --export 
$tempnode --offroot ${DEVLINKS}"
diff -Nru mdadm-3.3.2/debian/patches/series mdadm-3.3.2/debian/patches/series
--- mdadm-3.3.2/debian/patches/series   2014-12-05 16:59:42.0 +0100
+++ mdadm-3.3.2/debian/patches/series   2015-10-27 17:20:07.0 +0100
@@ -7,3 +7,4 @@
 rebuildmap-strip-local-host-name-from-device-name.patch
 readlink-path.patch
 mdmonitor-service-simplify.diff
+disable-incremental-assembly.patch

Bug#803256: laptop goes to sleep during log in to gnome

[Brent S. Elmer]

Package: gdm3
Version: 3.18.0-2
Severity: normal

The following problem just recently started happening after upgrading to gdm3
3.18.0-2.  I have a Lenovo w540 laptop in a dock with two external monitors
connected.  I boot with the laptop lid closed.  My two external monitors come
up and the login screen is on the right side external screen.  I select my user
and enter the password and log in.  Both of the external monitors go black and
go into standby mode.  I hear the fan on the laptop go off and it appears that
the laptop has gone to sleep.  I lift the laptop lid and the laptop wakes up
and the monitors wake up and come on.  I have been using this setup for a while
and this did not use to happen.



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

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

Versions of packages gdm3 depends on:
ii  accountsservice   0.6.40-3
ii  adduser   3.113+nmu3
ii  dconf-cli 0.24.0-2
ii  dconf-gsettings-backend   0.24.0-2
ii  debconf [debconf-2.0] 1.5.57
ii  gir1.2-gdm3   3.18.0-2
ii  gnome-session [x-session-manager] 3.16.0-1
ii  gnome-session-bin 3.16.0-1
ii  gnome-settings-daemon 3.16.3-1
ii  gnome-shell   3.16.3-2+b1
ii  gnome-terminal [x-terminal-emulator]  3.18.0-1
ii  gsettings-desktop-schemas 3.18.0-1
ii  libaccountsservice0   0.6.40-3
ii  libaudit1 1:2.4-1+b1
ii  libc6 2.19-22
ii  libcanberra-gtk3-00.30-2.1
ii  libcanberra0  0.30-2.1
ii  libgdk-pixbuf2.0-02.31.1-2+deb8u2
ii  libgdm1   3.18.0-2
ii  libglib2.0-0  2.46.0-2
ii  libglib2.0-bin2.46.0-2
ii  libgtk-3-03.16.6-1
ii  libpam-modules1.1.8-3.1
ii  libpam-runtime1.1.8-3.1
ii  libpam-systemd226-4
ii  libpam0g  1.1.8-3.1
ii  librsvg2-common   2.40.10-1
ii  libselinux1   2.3-2
ii  libsystemd0   226-4
ii  libwrap0  7.6.q-25
ii  libx11-6  2:1.6.3-1
ii  libxau6   1:1.0.8-1
ii  libxdmcp6 1:1.1.2-1
ii  lsb-base  4.1+Debian13+nmu1
ii  metacity [x-window-manager]   1:3.18.0-2
ii  mutter [x-window-manager] 3.16.3-1
ii  policykit-1   0.105-8
ii  ucf   3.0030
ii  x11-common1:7.7+12
ii  x11-xserver-utils 7.7+5
ii  xterm [x-terminal-emulator]   320-1

Versions of packages gdm3 recommends:
ii  at-spi2-core   2.18.0-1
ii  desktop-base   8.0.2
ii  gnome-icon-theme   3.12.0-1
ii  gnome-icon-theme-symbolic  3.12.0-1
ii  x11-xkb-utils  7.7+2
ii  xserver-xephyr 2:1.17.2-3
ii  xserver-xorg   1:7.7+12
ii  zenity 3.18.0-1

Versions of packages gdm3 suggests:
ii  gnome-orca3.16.2-2
ii  libpam-gnome-keyring  3.14.0-1+b1

-- debconf information:
  gdm3/daemon_name: /usr/sbin/gdm3
* shared/default-x-display-manager: gdm3

Bug#803257: ITP: reactivedata -- FRP with incremental changes in data structures

[Stéphane Glondu]

Package: wnpp
Severity: wishlist
Owner: "Stéphane Glondu" 

* Package name: reactivedata
  Version : 0.1
  Upstream Author : Hugo Heuzard
* URL : https://github.com/ocsigen/reactiveData
* License : LGPL
  Programming Lang: OCaml
  Description : FRP with incremental changes in data structures

 ReactiveData is an OCaml module for functional reactive programming
 (FRP) based on React. It adds support to incremental changes in data
 structures by reasoning on patches instead of absolute values.

This package is a new dependency of eliom. It will be maintained in
the Debian OCaml Team.

Bug#803258: freetds: new upstream release

[Sandro Tosi]

Source: freetds
Severity: wishlist

Hello,
freetds released a new version, 0.95, please update freetds in Debian.

Regards,
Sandro

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

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

Bug#803208: info: mouse unusable after exiting info with C-c

[Norbert Preining]

forcemerge 797872 803208
thanks

On Tue, 27 Oct 2015, Andy Isaacson wrote:
> when exiting due to SIGINT, info should turn off any special modes it
> turned on at startup.

Mouse support will be disabled in the next release, it is already
in the git repo.

Norbert


PREINING, Norbert   http://www.preining.info
JAIST, Japan TeX Live & Debian Developer
GPG: 0x860CDC13   fp: F7D8 A928 26E3 16A1 9FA0  ACF0 6CAC A448 860C DC13

Bug#803259: support for deprecated openssl features

[Robert Bihlmeyer]

Package: testssl.sh
Version: 2.6+dfsg1-2
Severity: wishlist

Debian's standard openssl installation does not provide every
(mis)feature. This results in some things not being testable by
testssl.sh. Example snippet:

 56 Bit encryptionLocal problem: No 56 Bit encryption configured in 
/usr/bin/openssl

Upstream offers statically linked openssl binaries for this.

I'm not sure what an appropriate solution for Debian is. Maybe the openssl
maintainers could be persuaded to build a openssl-insecure package from their
source.

Bug#803244: [php-maint] Bug#803244: php5-common: upgrading enables manually disabled opcache

[Antti Salmela]

I don't think that this is just a documentation issue, behaviour is just too 
unexpected.
dpkg doesn't recreate removed config files, apache2 has similar helpers, but it 
doesn't recreate
links removed by hand on update.

-- Antti

On Wed, Oct 28, 2015 at 01:21:06PM +0100, Ondřej Surý wrote:
> Control: severity -1 minor
> Control: reassign 797350 php5-common
> Control: forcemerge 797350 -1
> 
> Dear Antti,
> 
> yes, the documentation on module management could be improved, and it
> has been already filled as 803244.
> 
> Cheers,
> Ondrej
> 
> On Wed, Oct 28, 2015, at 12:30, Antti Salmela wrote:
> > Package: php5-common
> > Version: 5.6.14+dfsg-0+deb8u1
> > Severity: serious
> > 
> > Dear Maintainer,
> > 
> > I was under impression that maintainer scripts shouldn't recreate
> > configuration files removed by system administrator. php5-common just
> > recreated symbolic link from /etc/php5/sapi/conf.d/05-opcache.ini to
> > mods-available,
> > which I had removed since xcache works better for us and enabling both
> > segfaults apache.
> > 
> > And yes, after enough digging I found about php5dismod and
> > /var/lib/php5/modules/fpm/disabled_by_admin/,
> > but this behaviour is quite unexpected.
> > 
> > -- Package-specific info:
> >  Additional PHP 5 information 
> > 
> >  PHP 5 SAPI (php5query -S): 
> > fpm
> > cli
> > cgi
> > 
> >  PHP 5 Extensions (php5query -M -v): 
> > mysql (Enabled for fpm by maintainer script)
> > mysql (Enabled for cli by maintainer script)
> > mysql (Enabled for cgi by maintainer script)
> > pspell (Enabled for fpm by maintainer script)
> > pspell (Enabled for cli by maintainer script)
> > pspell (Enabled for cgi by maintainer script)
> > intl (Enabled for fpm by maintainer script)
> > intl (Enabled for cli by maintainer script)
> > intl (Enabled for cgi by maintainer script)
> > pdo (Enabled for fpm by maintainer script)
> > pdo (Enabled for cli by maintainer script)
> > pdo (Enabled for cgi by maintainer script)
> > mysqli (Enabled for fpm by maintainer script)
> > mysqli (Enabled for cli by maintainer script)
> > mysqli (Enabled for cgi by maintainer script)
> > curl (Enabled for fpm by maintainer script)
> > curl (Enabled for cli by maintainer script)
> > curl (Enabled for cgi by maintainer script)
> > mcrypt (Enabled for fpm by maintainer script)
> > mcrypt (Enabled for cli by maintainer script)
> > mcrypt (Enabled for cgi by maintainer script)
> > pdo_mysql (Enabled for fpm by maintainer script)
> > pdo_mysql (Enabled for cli by maintainer script)
> > pdo_mysql (Enabled for cgi by maintainer script)
> > gd (Enabled for fpm by maintainer script)
> > gd (Enabled for cli by maintainer script)
> > gd (Enabled for cgi by maintainer script)
> > pgsql (Enabled for fpm by maintainer script)
> > pgsql (Enabled for cli by maintainer script)
> > pgsql (Enabled for cgi by maintainer script)
> > pdo_sqlite (Enabled for fpm by maintainer script)
> > pdo_sqlite (Enabled for cli by maintainer script)
> > pdo_sqlite (Enabled for cgi by maintainer script)
> > pdo_pgsql (Enabled for fpm by maintainer script)
> > pdo_pgsql (Enabled for cli by maintainer script)
> > pdo_pgsql (Enabled for cgi by maintainer script)
> > json (Enabled for fpm by maintainer script)
> > json (Enabled for cli by maintainer script)
> > json (Enabled for cgi by maintainer script)
> > imap (Enabled for fpm by maintainer script)
> > imap (Enabled for cli by maintainer script)
> > imap (Enabled for cgi by maintainer script)
> > xcache (Enabled for fpm by maintainer script)
> > xcache (Enabled for cli by maintainer script)
> > xcache (Enabled for cgi by maintainer script)
> > sqlite3 (Enabled for fpm by maintainer script)
> > sqlite3 (Enabled for cli by maintainer script)
> > sqlite3 (Enabled for cgi by maintainer script)
> > 
> >  Configuration files: 
> >  /etc/php5/mods-available/pdo.ini 
> > extension=pdo.so
> > 
> >  /etc/php5/mods-available/opcache.ini 
> > zend_extension=opcache.so
> > 
> > 
> > -- System Information:
> > Debian Release: 8.2
> >   APT prefers stable
> >   APT policy: (900, 'stable'), (890, 'testing'), (499, 'unstable'), (101,
> >   'experimental')
> > Architecture: amd64 (x86_64)
> > 
> > Kernel: Linux 3.16.0-4-amd64 (SMP w/4 CPU cores)
> > Locale: LANG=en_US.UTF-8, LC_CTYPE=fi_FI.UTF-8 (charmap=UTF-8)
> > Shell: /bin/sh linked to /bin/dash
> > Init: systemd (via /run/systemd/system)
> > 
> > Versions of packages php5-common depends on:
> > ii  libc6   2.19-18+deb8u1
> > ii  lsof4.86+dfsg-1
> > ii  psmisc  22.21-2
> > ii  sed 4.2.2-4+b1
> > ii  ucf 3.0030
> > 
> > php5-common recommends no packages.
> > 
> > Versions of packages php5-common suggests:
> > ii  php5-xcache [php5-user-cache]  3.2.0-1
> > 
> > Versions of packages php5-cli depends on:
> > ii  libbz2-1.01.0.6-7+b3
> > ii  libc6 2.19-18+deb8u1
> > ii  libcomerr21.42.12-1.1
> > ii  libdb5.3  5.3.28-9
> > ii  libedit2  3.1-20140620-2
> > ii  l

Bug#802811: libqt5x11extras5: causes konsole to segfault in libX11 on startup

[Dmitry Shachnev]

The issue here is that KApplicationPrivate::init() (from kdelibs4support) has
this call:

  XInternAtoms(QX11Info::display(), names, n, false, atoms_return);

However QX11Info::display() behavior changed in Qt 5.5 [1], and it returns a
null pointer when ran with old qtbase (5.4), therefore XInternAtoms crashes.

So the only thing we can do here is tightening the qtx11extras dependencies to
make sure it will pull in libqt5gui5 5.5 (which I will do now).

[1]: http://code.qt.io/cgit/qt/qtx11extras.git/commit/?id=e6a813c7869fb367

--
Dmitry Shachnev

signature.asc
Description: OpenPGP digital signature

Bug#803256: downgrading to 3.14.2-2 fixes the problem

[Brent S. Elmer Ph.D.]

I downgraded gdm3, gir1.2-gdm3, and libgdm1 to 3.14.2-2 and the problem
went away.  Gnome starts after logging in without putting the laptop to
sleep.

Bug#803244: [php-maint] Bug#803244: php5-common: upgrading enables manually disabled opcache

[Antti Salmela]

Actually, isn't this policy violation?

10.7.3: 

Configuration file handling must conform to the following behavior:

local changes must be preserved during a package upgrade


On Wed, Oct 28, 2015 at 03:02:46PM +0200, Antti Salmela wrote:
> I don't think that this is just a documentation issue, behaviour is just too 
> unexpected.
> dpkg doesn't recreate removed config files, apache2 has similar helpers, but 
> it doesn't recreate
> links removed by hand on update.
> 
> -- Antti
> 
> On Wed, Oct 28, 2015 at 01:21:06PM +0100, Ondřej Surý wrote:
> > Control: severity -1 minor
> > Control: reassign 797350 php5-common
> > Control: forcemerge 797350 -1
> > 
> > Dear Antti,
> > 
> > yes, the documentation on module management could be improved, and it
> > has been already filled as 803244.
> > 
> > Cheers,
> > Ondrej
> > 
> > On Wed, Oct 28, 2015, at 12:30, Antti Salmela wrote:
> > > Package: php5-common
> > > Version: 5.6.14+dfsg-0+deb8u1
> > > Severity: serious
> > > 
> > > Dear Maintainer,
> > > 
> > > I was under impression that maintainer scripts shouldn't recreate
> > > configuration files removed by system administrator. php5-common just
> > > recreated symbolic link from /etc/php5/sapi/conf.d/05-opcache.ini to
> > > mods-available,
> > > which I had removed since xcache works better for us and enabling both
> > > segfaults apache.
> > > 
> > > And yes, after enough digging I found about php5dismod and
> > > /var/lib/php5/modules/fpm/disabled_by_admin/,
> > > but this behaviour is quite unexpected.
> > > 
> > > -- Package-specific info:
> > >  Additional PHP 5 information 
> > > 
> > >  PHP 5 SAPI (php5query -S): 
> > > fpm
> > > cli
> > > cgi
> > > 
> > >  PHP 5 Extensions (php5query -M -v): 
> > > mysql (Enabled for fpm by maintainer script)
> > > mysql (Enabled for cli by maintainer script)
> > > mysql (Enabled for cgi by maintainer script)
> > > pspell (Enabled for fpm by maintainer script)
> > > pspell (Enabled for cli by maintainer script)
> > > pspell (Enabled for cgi by maintainer script)
> > > intl (Enabled for fpm by maintainer script)
> > > intl (Enabled for cli by maintainer script)
> > > intl (Enabled for cgi by maintainer script)
> > > pdo (Enabled for fpm by maintainer script)
> > > pdo (Enabled for cli by maintainer script)
> > > pdo (Enabled for cgi by maintainer script)
> > > mysqli (Enabled for fpm by maintainer script)
> > > mysqli (Enabled for cli by maintainer script)
> > > mysqli (Enabled for cgi by maintainer script)
> > > curl (Enabled for fpm by maintainer script)
> > > curl (Enabled for cli by maintainer script)
> > > curl (Enabled for cgi by maintainer script)
> > > mcrypt (Enabled for fpm by maintainer script)
> > > mcrypt (Enabled for cli by maintainer script)
> > > mcrypt (Enabled for cgi by maintainer script)
> > > pdo_mysql (Enabled for fpm by maintainer script)
> > > pdo_mysql (Enabled for cli by maintainer script)
> > > pdo_mysql (Enabled for cgi by maintainer script)
> > > gd (Enabled for fpm by maintainer script)
> > > gd (Enabled for cli by maintainer script)
> > > gd (Enabled for cgi by maintainer script)
> > > pgsql (Enabled for fpm by maintainer script)
> > > pgsql (Enabled for cli by maintainer script)
> > > pgsql (Enabled for cgi by maintainer script)
> > > pdo_sqlite (Enabled for fpm by maintainer script)
> > > pdo_sqlite (Enabled for cli by maintainer script)
> > > pdo_sqlite (Enabled for cgi by maintainer script)
> > > pdo_pgsql (Enabled for fpm by maintainer script)
> > > pdo_pgsql (Enabled for cli by maintainer script)
> > > pdo_pgsql (Enabled for cgi by maintainer script)
> > > json (Enabled for fpm by maintainer script)
> > > json (Enabled for cli by maintainer script)
> > > json (Enabled for cgi by maintainer script)
> > > imap (Enabled for fpm by maintainer script)
> > > imap (Enabled for cli by maintainer script)
> > > imap (Enabled for cgi by maintainer script)
> > > xcache (Enabled for fpm by maintainer script)
> > > xcache (Enabled for cli by maintainer script)
> > > xcache (Enabled for cgi by maintainer script)
> > > sqlite3 (Enabled for fpm by maintainer script)
> > > sqlite3 (Enabled for cli by maintainer script)
> > > sqlite3 (Enabled for cgi by maintainer script)
> > > 
> > >  Configuration files: 
> > >  /etc/php5/mods-available/pdo.ini 
> > > extension=pdo.so
> > > 
> > >  /etc/php5/mods-available/opcache.ini 
> > > zend_extension=opcache.so
> > > 
> > > 
> > > -- System Information:
> > > Debian Release: 8.2
> > >   APT prefers stable
> > >   APT policy: (900, 'stable'), (890, 'testing'), (499, 'unstable'), (101,
> > >   'experimental')
> > > Architecture: amd64 (x86_64)
> > > 
> > > Kernel: Linux 3.16.0-4-amd64 (SMP w/4 CPU cores)
> > > Locale: LANG=en_US.UTF-8, LC_CTYPE=fi_FI.UTF-8 (charmap=UTF-8)
> > > Shell: /bin/sh linked to /bin/dash
> > > Init: systemd (via /run/systemd/system)
> > > 
> > > Versions of packages php5-common depends on:
> > > ii  libc6   2.19-18+deb8u1
> > > ii  lsof4

Bug#803260: php5: setcookie() function can no longer be used with value as specified in PHP doc

[Thibault Richard]

Package: php5-common
Version: 5.6.14+dfsg-0+deb8u1
Severity: important
Tags: upstream

Dear Maintainer,

Since the application of those versions (security updates)

libapache2-mod-php5 5.6.14+dfsg-0+deb8u1
php5 5.6.14+dfsg-0+deb8u1
php5-cli 5.6.14+dfsg-0+deb8u1
php5-common 5.6.14+dfsg-0+deb8u1
php5-curl 5.6.14+dfsg-0+deb8u1
php5-gd 5.6.14+dfsg-0+deb8u1
php5-mcrypt 5.6.14+dfsg-0+deb8u1
php5-mysql 5.6.14+dfsg-0+deb8u1
php5-readline 5.6.14+dfsg-0+deb8u1

The setcookie() function no longer works when called without value parameter 
According to http://php.net/manual/en/function.setcookie.pha, only the name is 
required. It worked like this before  php5 5.6.14+dfsg-0+deb8u1
 
   * What exactly did you do (or not do) that was effective (or
 ineffective)?
   * What was the outcome of this action?
   * What outcome did you expect instead?

-- Package-specific info:
 Additional PHP 5 information 

 PHP 5 SAPI (php5query -S): 
apache2
cli

 PHP 5 Extensions (php5query -M -v): 
mcrypt (Enabled for apache2 by maintainer script)
mcrypt (Enabled for cli by maintainer script)
pdo (Enabled for apache2 by maintainer script)
pdo (Enabled for cli by maintainer script)
mysqli (Enabled for apache2 by maintainer script)
mysqli (Enabled for cli by maintainer script)
gd (Enabled for apache2 by maintainer script)
gd (Enabled for cli by maintainer script)
imagick (Enabled for apache2 by maintainer script)
imagick (Enabled for cli by maintainer script)
pdo_mysql (Enabled for apache2 by maintainer script)
pdo_mysql (Enabled for cli by maintainer script)
readline (Enabled for apache2 by maintainer script)
readline (Enabled for cli by maintainer script)
curl (Enabled for apache2 by maintainer script)
curl (Enabled for cli by maintainer script)
opcache (Enabled for apache2 by maintainer script)
opcache (Enabled for cli by maintainer script)
mysql (Enabled for apache2 by maintainer script)
mysql (Enabled for cli by maintainer script)
json (Enabled for apache2 by maintainer script)
json (Enabled for cli by maintainer script)

 Configuration files: 
 /etc/php5/mods-available/pdo.ini 
extension=pdo.so

 /etc/php5/mods-available/opcache.ini 
zend_extension=opcache.so


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

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

Versions of packages php5 depends on:
ii  libapache2-mod-php5  5.6.14+dfsg-0+deb8u1
ii  php5-common  5.6.14+dfsg-0+deb8u1

php5 recommends no packages.

php5 suggests no packages.

Versions of packages php5-common depends on:
ii  libc6   2.19-18+deb8u1
ii  lsof4.86+dfsg-1
ii  psmisc  22.21-2
ii  sed 4.2.2-4+b1
ii  ucf 3.0030

Versions of packages php5-common suggests:
pn  php5-user-cache  

-- no debconf information

Bug#803244: [php-maint] Bug#803244: php5-common: upgrading enables manually disabled opcache

[Ondřej Surý]

The configuration changes done by the helper utilities are conserved, so
I don't think this violates the policies.

Anyway I would be very happy to apply any patch that would detect a ini
file deleted by an user. But it has to be well tested on single
installs, upgrades and cross-release upgrades (<-- that's one of the
reasons why it hasn't been done yet).

Cheers,
Ondrej

On Wed, Oct 28, 2015, at 14:07, Antti Salmela wrote:
> Actually, isn't this policy violation?
> 
> 10.7.3: 
> 
> Configuration file handling must conform to the following behavior:
> 
> local changes must be preserved during a package upgrade
> 
> 
> On Wed, Oct 28, 2015 at 03:02:46PM +0200, Antti Salmela wrote:
> > I don't think that this is just a documentation issue, behaviour is just 
> > too unexpected.
> > dpkg doesn't recreate removed config files, apache2 has similar helpers, 
> > but it doesn't recreate
> > links removed by hand on update.
> > 
> > -- Antti
> > 
> > On Wed, Oct 28, 2015 at 01:21:06PM +0100, Ondřej Surý wrote:
> > > Control: severity -1 minor
> > > Control: reassign 797350 php5-common
> > > Control: forcemerge 797350 -1
> > > 
> > > Dear Antti,
> > > 
> > > yes, the documentation on module management could be improved, and it
> > > has been already filled as 803244.
> > > 
> > > Cheers,
> > > Ondrej
> > > 
> > > On Wed, Oct 28, 2015, at 12:30, Antti Salmela wrote:
> > > > Package: php5-common
> > > > Version: 5.6.14+dfsg-0+deb8u1
> > > > Severity: serious
> > > > 
> > > > Dear Maintainer,
> > > > 
> > > > I was under impression that maintainer scripts shouldn't recreate
> > > > configuration files removed by system administrator. php5-common just
> > > > recreated symbolic link from /etc/php5/sapi/conf.d/05-opcache.ini to
> > > > mods-available,
> > > > which I had removed since xcache works better for us and enabling both
> > > > segfaults apache.
> > > > 
> > > > And yes, after enough digging I found about php5dismod and
> > > > /var/lib/php5/modules/fpm/disabled_by_admin/,
> > > > but this behaviour is quite unexpected.
> > > > 
> > > > -- Package-specific info:
> > > >  Additional PHP 5 information 
> > > > 
> > > >  PHP 5 SAPI (php5query -S): 
> > > > fpm
> > > > cli
> > > > cgi
> > > > 
> > > >  PHP 5 Extensions (php5query -M -v): 
> > > > mysql (Enabled for fpm by maintainer script)
> > > > mysql (Enabled for cli by maintainer script)
> > > > mysql (Enabled for cgi by maintainer script)
> > > > pspell (Enabled for fpm by maintainer script)
> > > > pspell (Enabled for cli by maintainer script)
> > > > pspell (Enabled for cgi by maintainer script)
> > > > intl (Enabled for fpm by maintainer script)
> > > > intl (Enabled for cli by maintainer script)
> > > > intl (Enabled for cgi by maintainer script)
> > > > pdo (Enabled for fpm by maintainer script)
> > > > pdo (Enabled for cli by maintainer script)
> > > > pdo (Enabled for cgi by maintainer script)
> > > > mysqli (Enabled for fpm by maintainer script)
> > > > mysqli (Enabled for cli by maintainer script)
> > > > mysqli (Enabled for cgi by maintainer script)
> > > > curl (Enabled for fpm by maintainer script)
> > > > curl (Enabled for cli by maintainer script)
> > > > curl (Enabled for cgi by maintainer script)
> > > > mcrypt (Enabled for fpm by maintainer script)
> > > > mcrypt (Enabled for cli by maintainer script)
> > > > mcrypt (Enabled for cgi by maintainer script)
> > > > pdo_mysql (Enabled for fpm by maintainer script)
> > > > pdo_mysql (Enabled for cli by maintainer script)
> > > > pdo_mysql (Enabled for cgi by maintainer script)
> > > > gd (Enabled for fpm by maintainer script)
> > > > gd (Enabled for cli by maintainer script)
> > > > gd (Enabled for cgi by maintainer script)
> > > > pgsql (Enabled for fpm by maintainer script)
> > > > pgsql (Enabled for cli by maintainer script)
> > > > pgsql (Enabled for cgi by maintainer script)
> > > > pdo_sqlite (Enabled for fpm by maintainer script)
> > > > pdo_sqlite (Enabled for cli by maintainer script)
> > > > pdo_sqlite (Enabled for cgi by maintainer script)
> > > > pdo_pgsql (Enabled for fpm by maintainer script)
> > > > pdo_pgsql (Enabled for cli by maintainer script)
> > > > pdo_pgsql (Enabled for cgi by maintainer script)
> > > > json (Enabled for fpm by maintainer script)
> > > > json (Enabled for cli by maintainer script)
> > > > json (Enabled for cgi by maintainer script)
> > > > imap (Enabled for fpm by maintainer script)
> > > > imap (Enabled for cli by maintainer script)
> > > > imap (Enabled for cgi by maintainer script)
> > > > xcache (Enabled for fpm by maintainer script)
> > > > xcache (Enabled for cli by maintainer script)
> > > > xcache (Enabled for cgi by maintainer script)
> > > > sqlite3 (Enabled for fpm by maintainer script)
> > > > sqlite3 (Enabled for cli by maintainer script)
> > > > sqlite3 (Enabled for cgi by maintainer script)
> > > > 
> > > >  Configuration files: 
> > > >  /etc/php5/mods-available/pdo.ini 
> > > > extension=pdo.so
> > > 

Bug#803187: RFS: drumgizmo/0.9.8.1-1 ITP

[Víctor Cuadrado Juan]

On 15-10-28 09:22:32, Gianfranco Costamagna wrote:
> the packaging looks good to me, I need to do a build&run and a copyright 
> check.

Thanks for the review :)

> However I'm wondering about the discussion on huge files.
> Does the package work without them?

The package purpose is to take those sound files, process them, and
outputs them. The package works, in the sense that you can install it
and run it, but you are only going to have any functionality from it.

> does the package download them from internet?

No, and it doesn't have other cue of where to find those files apart from
the README.Debian.

I have just talked with upstream, and their stance is that they don't
want to promote any data kits over the others, nor make the (incorrect)
impression that some data kits are the "official" ones. They are trying
to foster the community into creating more data kits, and possibly
having a community repo of all the kits.

With that in mind, they have friendly shared their opinion that they
don't think making downloader packages is a good idea. I have to say
that I fail to see a downcoming of having downloader packages.

> another question: how do you feel about making it team maintained?
> maybe this team fits your needs
> https://wiki.debian.org/DebianMultimedia

Good suggestion :). I have talked with them on #debian-multimedia, and I 
will follow their channels to have them sponsor this package.


-- 
Víctor Cuadrado juan
--
E-Mail: , OpenPGP-Key-ID: 0xA2591E231E251F36
Key fingerprint: E3C5 114C 0C5B 4C49 BA03  0991 A259 1E23 1E25 1F36
My signed E-Mails are trustworthy.


signature.asc
Description: PGP signature

Bug#803261: jsurf-alggeo: FTBFS: help2man: can't get `--help' info from ./debian/jsurf-alggeo/usr/bin/jsurf-alggeo

[Chris Lamb]

Source: jsurf-alggeo
Version: 0.1.4+ds-1
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,

jsurf-alggeo fails to build from source in unstable/amd64:

  [..]

  jh_exec
  /usr/bin/make -f debian/adhoc/Makefile manpages
  make[2]: Entering directory '/build/jsurf-alggeo-0.1.4+ds'
  help2man \
-s 1 \
--manual="IMAGINARY" --source="jsurf-alggeo 0.1.4+ds-1"
--version-string="0.1.4+ds-1" --no-info \
-I debian/man/jsurf-alggeo.h2m \
-n  "Java based renderer for ALGebraic GEOmetric
SURFaces" \
-o jsurf-alggeo.1 \
./debian/jsurf-alggeo/usr/bin/jsurf-alggeo
  help2man: can't get `--help' info from
  ./debian/jsurf-alggeo/usr/bin/jsurf-alggeo
  Try `--no-discard-stderr' if option outputs to stderr
  debian/adhoc/Makefile:18: recipe for target 'jsurf-alggeo.1' failed
  make[2]: *** [jsurf-alggeo.1] Error 2
  make[2]: Leaving directory '/build/jsurf-alggeo-0.1.4+ds'
  debian/rules:28: recipe for target 'override_jh_exec' failed
  make[1]: *** [override_jh_exec] Error 2
  make[1]: Leaving directory '/build/jsurf-alggeo-0.1.4+ds'
  debian/rules:14: recipe for target 'binary' failed
  make: *** [binary] Error 2
  dpkg-buildpackage: error: fakeroot debian/rules binary gave error exit
  status 2

  [..]

The full build log is attached or (an alternate build) can be viewed
here:


https://reproducible.debian.net/logs/unstable/amd64/jsurf-alggeo_0.1.4+ds-1.build1.log.gz


Regards,

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


jsurf-alggeo.0.1.4+ds-1.unstable.amd64.log.txt.gz
Description: application/gzip

Bug#803263: flask-autoindex: FTBFS: rm: cannot remove 'debian/tmp/usr/lib/python*/*-packages/Flask_AutoIndex-*.egg-info/SOURCES.txt': No such file or directory

[Chris Lamb]

Source: flask-autoindex
Version: 0.5-3
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,

flask-autoindex fails to build from source in unstable/amd64:

  [..]
  running install_egg_info
  Copying Flask_AutoIndex.egg-info to
  
/build/flask-autoindex-0.5/debian/tmp/usr/lib/python2.7/dist-packages/Flask_AutoIndex-0.5.egg-info
  Skipping SOURCES.txt
  running install_scripts
  rm
  debian/tmp/usr/lib/python*/*-packages/Flask_AutoIndex-*.egg-info/SOURCES.txt
  rm: cannot remove
  
'debian/tmp/usr/lib/python*/*-packages/Flask_AutoIndex-*.egg-info/SOURCES.txt':
  No such file or directory
  debian/rules:21: recipe for target 'override_dh_auto_install' failed
  make[1]: *** [override_dh_auto_install] Error 1
  make[1]: Leaving directory '/build/flask-autoindex-0.5'
  debian/rules:10: recipe for target 'binary' failed
  make: *** [binary] Error 2
  dpkg-buildpackage: error: fakeroot debian/rules binary gave error exit
  status 2

  [..]

The full build log is attached or (an alternate build) can be viewed
here:


https://reproducible.debian.net/logs/unstable/amd64/flask-autoindex_0.5-3.build1.log.gz


Regards,

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


flask-autoindex.0.5-3.unstable.amd64.log.txt.gz
Description: application/gzip

Bug#803262: flask-babel: FTBFS: cannot remove 'debian/tmp/usr/lib/python*/*-packages/Flask_Babel-*.egg-info/SOURCES.txt': No such file or directory

[Chris Lamb]

Source: flask-babel
Version: 0.9-1
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,

flask-babel fails to build from source in unstable/amd64:

  [..]

  writing manifest file 'Flask_Babel.egg-info/SOURCES.txt'
  Copying Flask_Babel.egg-info to
  
/build/flask-babel-0.9/debian/tmp/usr/lib/python2.7/dist-packages/Flask_Babel-0.9.egg-info
  Skipping SOURCES.txt
  running install_scripts
  rm
  debian/tmp/usr/lib/python*/*-packages/Flask_Babel-*.egg-info/SOURCES.txt
  rm: cannot remove
  'debian/tmp/usr/lib/python*/*-packages/Flask_Babel-*.egg-info/SOURCES.txt':
  No such file or directory
  debian/rules:21: recipe for target 'override_dh_auto_install' failed
  make[1]: *** [override_dh_auto_install] Error 1
  make[1]: Leaving directory '/build/flask-babel-0.9'
  debian/rules:10: recipe for target 'binary' failed
  make: *** [binary] Error 2
  dpkg-buildpackage: error: fakeroot debian/rules binary gave error exit
  status 2

  [..]

The full build log is attached or (an alternate build) can be viewed
here:


https://reproducible.debian.net/logs/unstable/amd64/flask-babel_0.9-1.build1.log.gz


Regards,

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


flask-babel.0.9-1.unstable.amd64.log.txt.gz
Description: application/gzip

Bug#803265: bluetooth.service: sap-server: Operation not permitted (1)

[Michal Suchanek]

Package: bluez
Version: 5.33-1
Severity: normal
File: bluetooth.service

Hello,

I tried to use bluetooth headphones.

However, bluetooth does not start.

There are missing configuration files. I did not remove thsese so
probably some upgrade script did.

● bluetooth.service - Bluetooth service
   Loaded: loaded (/lib/systemd/system/bluetooth.service; enabled; vendor 
preset: enabled)
   Active: failed (Result: timeout) since Fri 2015-10-23 18:34:06 CEST; 4 days 
ago
 Docs: man:bluetoothd(8)
  Process: 27310 ExecStart=/usr/lib/bluetooth/bluetoothd (code=exited, 
status=0/SUCCESS)
 Main PID: 27310 (code=exited, status=0/SUCCESS)
   Status: "Quitting"

Oct 23 18:32:36 iscsi bluetoothd[27310]: Sap driver initialization failed.
Oct 23 18:32:36 iscsi bluetoothd[27310]: sap-server: Operation not permitted (1)
Oct 23 18:32:36 iscsi bluetoothd[27310]: hci0 Load Connection Parameters 
failed: Unknown Command (0x01)
Oct 23 18:34:06 iscsi systemd[1]: bluetooth.service: Start operation timed out. 
Terminating.
Oct 23 18:34:06 iscsi bluetoothd[27310]: Terminating
Oct 23 18:34:06 iscsi bluetoothd[27310]: Stopping SDP server
Oct 23 18:34:06 iscsi bluetoothd[27310]: Exit
Oct 23 18:34:06 iscsi systemd[1]: Failed to start Bluetooth service.
Oct 23 18:34:06 iscsi systemd[1]: bluetooth.service: Unit entered failed state.
Oct 23 18:34:06 iscsi systemd[1]: bluetooth.service: Failed with result 
'timeout'.


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

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

Versions of packages bluez depends on:
ii  dbus 1.10.0-3
ii  init-system-helpers  1.23
ii  kmod 18-3
ii  libc62.19-22
ii  libdbus-1-3  1.10.0-3
ii  libglib2.0-0 2.46.0-2
ii  libreadline6 6.3-8+b3
ii  libudev1 215-17+deb8u2
ii  lsb-base 9.20150917
ii  udev 215-17+deb8u2

bluez recommends no packages.

bluez suggests no packages.

-- Configuration Files:
/etc/init.d/bluetooth [Errno 2] No such file or directory: 
u'/etc/init.d/bluetooth'
/etc/init/bluetooth.conf e6b0122c1e5cd56016859a0767a8cfcb [Errno 2] No such 
file or directory: u'/etc/init/bluetooth.conf e6b0122c1e5cd56016859a0767a8cfcb'

-- no debconf information

Bug#803264: libvirt-daemon: macvtap interface for a VM won't get up

[Thomas SILVESTRE]

Package: libvirt-daemon
Version: 1.2.9-9+deb8u1
Severity: normal

Dear Maintainer,

I'm using libvirt to virtualize a VM on my laptop, this vm has to be bridged on
the network and I'm using macvtap technology (trough virt-manager)

here is the xml part of the domain regarding network:

  
  
  
  
  
  


  
  
  
  
  
  


When the laptop boot and I start the VM, there's no problem.
But when I put the laptop to sleep, the macvtap interface will never get up
again.

I even tried to stop the vm, libvirt, unload modules (macvtap, vhost_net,
vhost, e1000e), but nothing help.

The only way to get it back working is to reboot the host os (like Windows,
booohooo :-( )

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

   * What led up to the situation?

I'm not sure, either unplug/plug the ethernet connection (like removing the
laptop from its docking station), or put laptop on sleep and wake him.


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

Appart a reboot, nothing effective.

   * What was the outcome of this action?
   * What outcome did you expect instead?

When the system is wokring, the macvtap interface is "UP", but when the problem
occurs the interface is "DOWN". Of course a "ip link set macvtap0 up" or delete
interface and recreate them did not help.

The only thing I founded in the log is this message:
IPv6: ADDRCONF(NETDEV_UP): macvtap0: link is not ready

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

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 libvirt-daemon depends on:
ii  libapparmor12.9.0-3
ii  libaudit1   1:2.4-1+b1
ii  libavahi-client30.6.31-5
ii  libavahi-common30.6.31-5
ii  libblkid1   2.25.2-6
ii  libc6   2.19-18+deb8u1
ii  libcap-ng0  0.7.4-2
ii  libdbus-1-3 1.8.20-0+deb8u1
ii  libdevmapper1.02.1  2:1.02.90-2.2
ii  libfuse22.9.3-15+deb8u1
ii  libgnutls-deb0-28   3.3.8-6+deb8u3
ii  libnetcf1   1:0.2.3-4.1
ii  libnl-3-200 3.2.24-2
ii  libnl-route-3-200   3.2.24-2
ii  libnuma12.0.10-1
ii  libparted2  3.2-7
ii  libpcap0.8  1.6.2-2
ii  libpciaccess0   0.13.2-3+b1
ii  librados2   0.80.7-2
ii  librbd1 0.80.7-2
ii  libsasl2-2  2.1.26.dfsg1-13+deb8u1
ii  libselinux1 2.3-2
ii  libssh2-1   1.4.3-4.1
ii  libsystemd0 215-17+deb8u2
ii  libudev1215-17+deb8u2
ii  libvirt01.2.9-9+deb8u1
ii  libxen-4.4  4.4.1-9+deb8u1
ii  libxenstore3.0  4.4.1-9+deb8u1
ii  libxml2 2.9.1+dfsg1-5
ii  libyajl22.1.0-2

Versions of packages libvirt-daemon recommends:
ii  libxml2-utils   2.9.1+dfsg1-5
ii  netcat-openbsd  1.105-7
ii  qemu-kvm1:2.1+dfsg-12+deb8u4

Versions of packages libvirt-daemon suggests:
ii  libvirt-daemon-system  1.2.9-9+deb8u1

Bug#803036: qemu-system-x86: Qemu guest hangs 100% CPU on IO

[Michael Tokarev]

26.10.2015 11:54, Gavin Pidgley wrote:
> Package: qemu-system-x86
> Version: 2.1+dfsg-12~bpo70+1
> Severity: important
> 
> Dear Maintainer,
> 
> We are seeing guests lockup/hang with qemu. The guests hang with 100% CPU
> usage. The problem seems to be storage/IO related, but there is not 
> necessarily
> high IO happening on the host at the time the guest hangs.

There were some revork in this layer for 2.4 version, which is not easily to
backport to 2.1.  This _might_ be the issue you're expiriencing, or it might
be a different one.  There were several reports about qemu locking up on slow
I/O, but it is very difficult to debug, and reportedly after the rework the
lockups stopped from occuring.


That's what I have in mind:

https://lists.gnu.org/archive/html/qemu-devel/2015-09/msg05294.html

Thanks,

/mjt

Bug#802971: libxslt: Type confusion may cause DoS

[Salvatore Bonaccorso]

Control: retitle -1 libxslt: CVE-2015-7995: Type confusion may cause DoS 

Hi,

CVE-2015-7995 has now been assigned to this issue.

Regards,
Salvatore

Bug#803266: ITP: python-packaging -- core utilities for python packages

[Matthias Klose]

Package: wnpp
Severity: wishlist
Owner: Matthias Klose 

* Package name: python-packaging
  Version : 15.3
  Upstream Author : Donald Stufft

* URL : https://pypi.python.org/pypi/packaging
* License : Apache
  Programming Lang: Python
  Description : core utilities for python packages

 These core utilies consist of:
  - Version Handling (PEP 440)
  - Dependency Specification (PEP 440)

Bug#731420: python-radicale supported by python3

[Jonas Smedegaard]

Hi Michael,

Quoting Michael Fladischer (2015-10-28 12:29:26)
> On Thu, 05 Dec 2013 17:21:36 +0100 Jonas Smedegaard  wrote:
>> Quoting NachE (2013-12-05 12:22:18)
>>> The radicale soft needs run over python >= 3.2 for tls/imap support. 
>>> Instead the python-radicale package on Wheezy is installed only into 
>>> python 2.6 and 2.7 versions 
>>> (/usr/lib/python2.6/dist-packages/radicale/ and 
>>> /usr/lib/python2.7/dist-packages/radicale/). I try to move files to 
>>> /usr/lib/python3/dist-packages/radicale and works perfectly.
>>>
>>> I suggest that the package add support to python 3.[2].
>>
>> Thanks for the suggestion.
>>
>> I agree, we should sure support Python3.  Nice that you've tested 
>> that it works! :-)
>
> Tested the python-radicale package with mod_wsgi for Python3 (using a 
> symlink) and it works perfectly fine.
>
> is there anything that I can help to get Python3 support to this package?

Thanks for testing - and bring attention to this old issue.

I had a look now, and noticed that if we switch to python3 then we will 
loose LDAP support, because there's no python3-ldap package.

Would be great if someone could try hack Radicale code to use 
python-ldap3.  Or alternatively convince maintainers of python-ldap to 
alse build it for Python3 (which I suspect is more work).

With one of above in place we should be able to switch to Python3 
without regressions.


 - Jonas

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

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


signature.asc
Description: signature

Bug#798661: libqt5widgets5: regression in 5.5 breaks vlc video playback

[Rémi Denis-Courmont]

tags 798661 + patch
thanks

Upstream bug report has a fix.

--
Rémi Denis-Courmont
http://www.remlab.net/

Bug#803193: closed by Michal Čihař (Re: Bug#803193: wammu: PyAssertionError on attempting to create new text message)

[Ian Jackson]

(CCing debian-release)

Debian Bug Tracking System writes ("Bug#803193 closed by Michal Čihař 
 (Re: Bug#803193: wammu: PyAssertionError on attempting to 
create new text message)"):
> this has been already fixed in 0.38.

Great, thanks.  I think this fix should go into a stable update.  The
bug makes the current wammu unuseable for many (but not all) purposes.

If we do do a stable update, should we try to cherry pick the relevant
fix into 0.37 for stable, or update stable to 0.38 or 0.39 ?

The upstream changelog for 0.37 (current stable) to 0.38 says:

  2014-12-29

  * Compatibility with latest wxPython releases.
  * Fixed corrupted appdata metadata.
  * Fixed broken desktop file due to Chinese translation.
  * Translation updates.

I have reviewed the debdiff between 0.37-1 and 0.38-1 and that
changelog looks accurate.  That all seems low-risk and worth having if
we are going to do an update anyway.  It's probably better to bring in
all of those than to try an adhoc cherry-pick.


0.39 says:

 2015-07-14

 * Fixed connecting to phone with no SMSC set.
 * Various code cleanups.

That seems higher risk.  I'm not convinced that "various code
cleanups" is something we would want to take into stable.


Would you like me to negotiate with the release team and prepare and
upload a stable update ?

Thanks,
Ian.

Bug#741464:

[Vebryn]

Hi,

I encount the same issue using french layout and IBM x3550 M4 (efi boot).

Any news regarding this issue ?

Best regards.

Bug#803267: Instructions for creating syslinux.cfg are incorrect

[Matt Kraai]

Package: installation-guide
Tags: patch

Hi,

Syslinux 5.00 makes global APPEND directives be ignored by the DEFAULT
directive:

 http://www.syslinux.org/wiki/index.php/Directives/append#default

Since the Debian installer manual recommends using a global APPEND
directive to specify the initrd, "initrd=initrd.gz" is not used by the
DEFAULT directive, which causes the installer to fail to boot.  The
following patch is one way to address this problem:


Index: manual/en/install-methods/usb-setup/x86.xml
===
--- manual/en/install-methods/usb-setup/x86.xml (revision 70046)
+++ manual/en/install-methods/usb-setup/x86.xml (working copy)
@@ -93,17 +93,18 @@
 
 
 Next you should create a syslinux.cfg configuration
-file, which at a bare minimum should contain the following two lines (change
-the name of the kernel binary to linux
-if you used a netboot image):
+file, which at a bare minimum should contain the following line (change
+the name of the kernel binary from
+vmlinuz to
+linux if you used a
+netboot image):
 
 
-default vmlinuz
-append initrd=initrd.gz
+default vmlinuz initrd=initrd.gz
 
 
 For the graphical installer you should add vga=788 to 
the
-second line. Other parameters can be appended as desired.
+line. Other parameters can be appended as desired.
 
 
 


The Syslinux wiki recommends using something like the following, but I
assume the above, shorter version is preferred:

 DEFAULT mylabel
 LABEL mylabel
 KERNEL vmlinuz
 APPEND initrd=initrd.gz

-- 
Matt   https://ftbfs.org/~kraai/

Bug#803268: neurodebian-dev: nd_adddistall fails to create nd+debian-squeeze and nd+ubuntu-utopic chroots

[Daniele E. Domenichelli]

Package: neurodebian-dev
Version: 0.37.2
Severity: normal

Dear Maintainer,

nd_adddistall (and nd_adddist) fail to create nd+debian-squeeze and
nd+ubuntu-utopic chroots from scratch.

The issue with nd+debian-squeeze seems to be related to the fact that
the 'debootstrap' package is in the neurodebian archive, but the
neurodebian archive key is not available when the chroot is created.
See also attached log and
http://neuro.debian.net/pkgs/debootstrap.html?highlight=debootstrap

The issue with ubuntu utopic is the utopic release reached its end of
life on July 23, 2015, and therefore it is no longer downloadable from
ubuntu mirrors.
Using http://old-releases.ubuntu.com/ubuntu/ as mirror fixes this issue
(I just added an "if" in my /etc/neurodebian/cmdsettings.sh to handle
this)


-- Log nd+debian-squeeze

# nd_adddist nd+debian squeeze
Building i386 base path...
Including NeuroDebian repository...
 -> Invoking pbuilder
  forking: pbuilder create --debootstrap debootstrap --aptcache 
/home/neurodebian/debian_aptcache --debootstrapopts 
--keyring=/usr/share/keyrings/debian-archive-keyring.gpg --components main 
contrib non-free --debootstrapopts --arch=i386 --othermirror deb 
http://httpredir.debian.org/debian squeeze-updates main contrib non-free 
|#deb-src http://httpredir.debian.org/debian squeeze-updates main contrib 
non-free |deb http://neuro.debian.net/debian squeeze main contrib non-free | 
deb http://neuro.debian.net/debian data main contrib non-free --buildplace 
/home/neurodebian/cow/nd+debian-squeeze-i386.cow --mirror 
http://httpredir.debian.org/debian --distribution squeeze --no-targz 
--extrapackages cowdancer 
W: /root/.pbuilderrc does not exist
I: Running in no-targz mode
I: Distribution is squeeze.
I: Current time: Wed Oct 28 14:54:08 CET 2015
I: pbuilder-time-stamp: 1446040448
I: Building the build environment
I: running debootstrap
/usr/sbin/debootstrap
I: Retrieving Release 
I: Retrieving Release.gpg 
I: Checking Release signature
I: Valid Release signature (key id 0E4EDE2C7F3E1FC0D033800E64481591B98321F9)
I: Retrieving Packages 
I: Validating Packages 
I: Resolving dependencies of required packages...
I: Resolving dependencies of base packages...
I: Found additional required dependencies: insserv libbz2-1.0 libdb4.8 
libslang2 
I: Found additional base dependencies: binutils bzip2 cpp cpp-4.4 
debian-archive-keyring dpkg-dev g++ g++-4.4 gcc gcc-4.4 gnupg gpgv libc-dev-bin 
libc6-dev libdb4.7 libdpkg-perl libgdbm3 libgmp3c2 libgomp1 libmpfr4 
libreadline6 libstdc++6-4.4-dev libtimedate-perl libusb-0.1-4 linux-libc-dev 
make patch perl perl-modules readline-common 
I: Checking component main on http://httpredir.debian.org/debian...
I: Retrieving libacl1 2.2.49-4
I: Validating libacl1 2.2.49-4
I: Retrieving apt 0.8.10.3+squeeze1
I: Validating apt 0.8.10.3+squeeze1
I: Retrieving libattr1 1:2.4.44-2
I: Validating libattr1 1:2.4.44-2
I: Retrieving base-files 6.0squeeze10
I: Validating base-files 6.0squeeze10
I: Retrieving base-passwd 3.5.22
I: Validating base-passwd 3.5.22
I: Retrieving bash 4.1-3
I: Validating bash 4.1-3
I: Retrieving binutils 2.20.1-16
I: Validating binutils 2.20.1-16
I: Retrieving build-essential 11.5
I: Validating build-essential 11.5
I: Retrieving bzip2 1.0.5-6+squeeze1
I: Validating bzip2 1.0.5-6+squeeze1
I: Retrieving libbz2-1.0 1.0.5-6+squeeze1
I: Validating libbz2-1.0 1.0.5-6+squeeze1
I: Retrieving coreutils 8.5-1
I: Validating coreutils 8.5-1
I: Retrieving dash 0.5.5.1-7.4
I: Validating dash 0.5.5.1-7.4
I: Retrieving libdb4.7 4.7.25-9
I: Validating libdb4.7 4.7.25-9
I: Retrieving libdb4.8 4.8.30-2
I: Validating libdb4.8 4.8.30-2
I: Retrieving debconf-i18n 1.5.36.1
I: Validating debconf-i18n 1.5.36.1
I: Retrieving debconf 1.5.36.1
I: Validating debconf 1.5.36.1
I: Retrieving debian-archive-keyring 2010.08.28+squeeze1
I: Validating debian-archive-keyring 2010.08.28+squeeze1
I: Retrieving debianutils 3.4
I: Validating debianutils 3.4
I: Retrieving diffutils 1:3.0-1
I: Validating diffutils 1:3.0-1
I: Retrieving dpkg-dev 1.15.11
I: Validating dpkg-dev 1.15.11
I: Retrieving dpkg 1.15.11
I: Validating dpkg 1.15.11
I: Retrieving libdpkg-perl 1.15.11
I: Validating libdpkg-perl 1.15.11
I: Retrieving e2fslibs 1.41.12-4stable1
I: Validating e2fslibs 1.41.12-4stable1
I: Retrieving e2fsprogs 1.41.12-4stable1
I: Validating e2fsprogs 1.41.12-4stable1
I: Retrieving libcomerr2 1.41.12-4stable1
I: Validating libcomerr2 1.41.12-4stable1
I: Retrieving libss2 1.41.12-4stable1
I: Validating libss2 1.41.12-4stable1
I: Retrieving libc-bin 2.11.3-4
I: Validating libc-bin 2.11.3-4
I: Retrieving libc-dev-bin 2.11.3-4
I: Validating libc-dev-bin 2.11.3-4
I: Retrieving libc6-dev 2.11.3-4
I: Validating libc6-dev 2.11.3-4
I: Retrieving libc6 2.11.3-4
I: Validating libc6 2.11.3-4
I: Retrieving findutils 4.4.2-1+b1
I: Validating findutils 4.4.2-1+b1
I: Retrieving cpp-4.4 4.4.5-8
I: Validating cpp-4.4 4.4.5-8
I: Retrieving g++-4.4 4.4.5-8
I: Validating g++-4.4 4.4.5-8
I: Retrieving gcc-4.4-base 4.4.5-

Bug#803269: libsdl-perl: FTBFS on hurd-i386

[Svante Signell]

Source: libsdl-perl
Version: 2.546-2
Severity: important
Tags: patch
Usertags: hurd
User: debian-h...@lists.debian.org

Hello,

Currently libsdl-cdrom FTBFS on GNU/Hurd since the test
SDL::CDROM::num_drives() in t/core_cd.t returns -1. This return value is
expected when the SDL_INIT_CDROM flag is not used for SDL_init(). From
/usr/include/SDL/SDL_cdrom.h:
/**
 *  Returns the number of CD-ROM drives on the system, or -1 if
 *  SDL_Init() has not been called with the SDL_INIT_CDROM flag.
*/

Note: This is confusing since the  test i t/core_cd.t succeeds:
plan( skip_all => 'Failed to init cdrom' )
  unless SDL::TestTool->init(SDL_INIT_CDROM);

Anyway, the attached patch, fix-core_cd-tests, fixes the test when
SDL::CDROM::num_drives() returns a number <= 0.

Thanks!
Index: libsdl-perl-2.546/t/core_cd.t
===
--- libsdl-perl-2.546.orig/t/core_cd.t
+++ libsdl-perl-2.546/t/core_cd.t
@@ -37,12 +37,13 @@ is( SDL_DATA_TRACK,4, 'SDL_DATA_TRAC
 is( SDL_DATA_TRACK(),  4, 'SDL_DATA_TRACK() should also be available' );
 
 my $num_drives = SDL::CDROM::num_drives();
-ok( $num_drives >= 0, "[SDL::CDROM::num_drives] is $num_drives" );
 
 SKIP:
 {
-	skip( "no drives available or SDL_RELEASE_TESTING not set", 17 )
+	skip( "no drives available or SDL_RELEASE_TESTING not set", 18 )
 		if $num_drives <= 0 || !$ENV{SDL_RELEASE_TESTING};
+
+	ok( $num_drives > 0, "[SDL::CDROM::num_drives] is $num_drives" );
 	for ( 0 .. $num_drives - 1 ) {
 		my $name = SDL::CDROM::name($_);
 		ok( $name, "[SDL::CDROM::name] for drive $_ is $name" );

Bug#607329: cpufrequtils should use /etc/default

[PaulTT]

imho, at least ENABLE and GOVERNOR options should be in a default 
installed file

Bug#803270: nmu: tvc_5.0.2+dfsg-1

[Andreas Beckmann]

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

nmu tvc_5.0.2+dfsg-1 . amd64 . experimental . -m "Rebuild against 
libarmadillo6."

Recent maintainer upload was built against the old library.


Andreas

Bug#803260: Upstream bug

[thibault.richard]

This last patch includes all the upstream bugfixes including 
https://bugs.php.net/bug.php?id=67131

With this fix PHP sems to no longer repspecting its own documentation

_

Ce message et ses pieces jointes peuvent contenir des informations 
confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce 
message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages 
electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou 
falsifie. Merci.

This message and its attachments may contain confidential or privileged 
information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete 
this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been 
modified, changed or falsified.
Thank you.

Bug#803212: kate: Crash (segmentation fault) on startup in xcb_send_request

[Lisandro Damián Nicanor Pérez Meyer]

tag 803212 moreinfo
thanks

Please take a look at

http://bugs.debian.org/802811

and please check if that's your situation.

Thanks!

-- 
You know you're brilliant, but maybe you'd like to understand what
you did 2 weeks from now.
  Linus Benedict Torvalds.

Lisandro Damián Nicanor Pérez Meyer
http://perezmeyer.com.ar/
http://perezmeyer.blogspot.com/


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

Bug#798661: pending

[Lisandro Damián Nicanor Pérez Meyer]

tag 798661 pending
thanks

We are about to push the fix for this one.

-- 
"If I have been able to see farther, it was only because I stood on the
shoulders of giants"
 Sir Isaac Newton

Lisandro Damián Nicanor Pérez Meyer
http://perezmeyer.com.ar/
http://perezmeyer.blogspot.com/


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

Bug#803176: autodep8: please fix the way nodejs/generate gets upstream_name

[Antonio Terceiro]

On Tue, Oct 27, 2015 at 10:32:06PM +0100, Jérémy Lal wrote:
> 2015-10-27 22:09 GMT+01:00 Antonio Terceiro :
> 
> > On Tue, Oct 27, 2015 at 06:09:00PM +0100, Jérémy Lal wrote:
> > > Package: autodep8
> > > Version: 0.2
> > > Severity: normal
> > >
> > > Dear Maintainer,
> > >
> > > Please use this one-liner instead
> > >
> > > upstream_name=$(python -c "import json;
> > print(json.load(open('package.json'))['name'])")
> >
> > this broke on the very first NodeJS package I went to try it (requirejs):
> >
> > $ pwd
> > /tmp/requirejs-2.1.20
> > $ python -c "import json; print(json.load(open('package.json'))['name'])"
> > Traceback (most recent call last):
> >   File "", line 1, in 
> >   KeyError: 'name'
> >
> > We probably want to fallback to looking at the source package name?
> 
> 
> This is the first time i see this.
> Yes, keeping existing code as fallback seems to be safer.
> 
> Note that there is something odd with that module...
> 
> https://github.com/jrburke/r.js
> https://github.com/jrburke/r.js/commit/40fa066e
> 
> https://github.com/jrburke/requirejs
> https://github.com/jrburke/requirejs/commit/a2029ccd
> 
> So the correct upstream source seems to be requirejs, not r.js.
> In any case upstream is using a meta-packager (volo) so in this case
> package.json cannot be trusted (the fact it is available in the git
> repository is misleading - it shouldn't even be there).

I improved the situation with this commit:
http://anonscm.debian.org/cgit/collab-maint/autodep8.git/commit/

However, even then the actual tests are still just a simple load test.
It will make sure the dependency chain is ok, and that is it.

Is there any way we can improve on that? Is `npm run test` a more or
less standard practice in the Node community?

-- 
Antonio Terceiro 


signature.asc
Description: PGP signature

Bug#803272: libreoffice-dev: apt-get dist-upgrade -u -f *HANGS* on libreoffice-dev 3a5.0.3~rc1-2

[Emmanuel Charpentier]

Package: libreoffice-dev
Version: 1:5.0.2-1
Severity: critical
Justification: breaks unrelated software

Dear Maintainer,

   * What led up to the situation?

apt-get update # Then
apt-get dist-upgrade -u -f

results in a hung apt-get. From another terminal, ps axfw says :

[ ... ]

3143 pts/0Ss 0:00  \_ bash
 3149 pts/0S  0:00  |   \_ sudo -i
 3178 pts/0S  0:00  |   \_ -bash
19191 pts/0S+ 0:09  |   \_ apt-get dist-upgrade -u -f
20570 pts/1Ss+0:00  |   \_ /usr/bin/dpkg --status-fd 107
--unpack --auto-deconfigure /var/cache/apt/archives/libreoffice-
dev_1%3a5.0.3~rc1
20616 pts/1S+ 0:00  |   \_ /bin/sh
/var/lib/dpkg/tmp.ci/preinst upgrade 1:5.0.2-1
20617 pts/1S+ 0:00  |   \_ /bin/sh /usr/bin/dpkg-
maintscript-helper dir_to_symlink /usr/share/doc/libreoffice-dev
/usr/share/doc/l
20625 pts/1S+ 0:00  |   \_ find /usr/share/doc
/libreoffice-dev -print0
20626 pts/1S+ 0:00  |   \_ xargs -0 -n1 sh -c
??package="$1" ??file="$2" ??if ! dpkg-query -L "$package" | grep -q -x "$file"

[ ... ]

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

sudo kill  : unhangs the apt-get console.
dpkg -C : shows libreoffice-dev to be in an incoherent state
dpkg --configure --pending : dpkg state database locked by another process
apt-get dist-upgrade -u -f : [ Can't get the lock ]
rm /var/lib/dpkg/lock ; dpkg -C : [ Can't get the lock : no such file ]


   * What was the outcome of this action?


===> apt-get hosed.

   * What outcome did you expect instead?

An uneventful update...




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

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

Versions of packages libreoffice-dev depends on:
ii  libc6 2.19-22
ii  libgcc1   1:5.2.1-22
ii  libgl1-mesa-glx [libgl1]  10.6.8-1
ii  libreoffice-core  1:5.0.3~rc1-2
ii  libstdc++65.2.1-22
ii  libx11-6  2:1.6.3-1
ii  ucpp  1.3.2-1
ii  uno-libs3 5.0.3~rc1-2
ii  ure   5.0.3~rc1-2

Versions of packages libreoffice-dev recommends:
ii  default-jre [java5-runtime]2:1.7-52
ii  g++4:5.2.1-4
ii  libreoffice-java-common1:5.0.3~rc1-2
ii  openjdk-6-jre [java5-runtime]  6b31-1.13.3-1
ii  openjdk-7-jre [java5-runtime]  7u85-2.6.1-5

Versions of packages libreoffice-dev suggests:
ii  libmythes-dev2:1.2.4-1
ii  libreoffice-dev-doc  1:5.0.2-1
pn  libreofficekit-dev   

-- no debconf information

Bug#764401: ksh

[Thorsten Glaser]

Nicholas Bamber dixit:

> 2. mksh also should provide 'ksh' as a virtual package.

It is my agreement with David Korn (the ‘k’ in “ksh”) that
mksh must not be confused for the original, so please refrain
from doing so.

bye,
//mirabilos
-- 
„Cool, /usr/share/doc/mksh/examples/uhr.gz ist ja ein Grund,
mksh auf jedem System zu installieren.“
-- XTaran auf der OpenRheinRuhr, ganz begeistert
(EN: “[…]uhr.gz is a reason to install mksh on every system.”)

Bug#803271: caja crashes when I try to delete network file

[Pol Hallen]

Package: caja
Version: 1.10.4-1
Severity: normal

Hello,
using the latest version of caja, when I try to delete a network file (a shared 
folder mounted as smb://ip/share) caja crashed...

any way to solve this problem?
thanks

Pol


-- System Information:
Debian Release: stretch/sid
  APT prefers testing
  APT policy: (500, 'testing')
Architecture: i386 (i686)

Kernel: Linux 3.13-1-686-pae (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: sysvinit (via /sbin/init)

Versions of packages caja depends on:
ii  caja-common   1.10.4-1
ii  desktop-file-utils0.22-1
ii  gvfs  1.22.2-1
ii  libatk1.0-0   2.18.0-1
ii  libc6 2.19-22
ii  libcairo2 1.14.2-2
ii  libcaja-extension11.10.4-1
ii  libexempi32.2.2-2+b1
ii  libexif12 0.6.21-2
ii  libfontconfig12.11.0-6.3
ii  libfreetype6  2.6-2
ii  libgail18 2.24.28-1
ii  libgdk-pixbuf2.0-02.32.1-1
ii  libglib2.0-0  2.46.1-1
ii  libglib2.0-data   2.46.1-1
ii  libgtk2.0-0   2.24.28-1
ii  libice6   2:1.0.9-1+b1
ii  libmate-desktop-2-17  1.10.2-1
ii  libpango-1.0-01.38.1-1
ii  libpangocairo-1.0-0   1.38.1-1
ii  libpangoft2-1.0-0 1.38.1-1
ii  libselinux1   2.3-2+b1
ii  libsm62:1.2.2-1+b1
ii  libstartup-notification0  0.12-4
ii  libunique-1.0-0   1.1.6-5
ii  libx11-6  2:1.6.3-1
ii  libxext6  2:1.3.3-1
ii  libxml2   2.9.2+zdfsg1-4
ii  libxrender1   1:0.9.8-1+b1
ii  mate-desktop  1.10.2-1
ii  shared-mime-info  1.5-2

Versions of packages caja recommends:
ii  gvfs-backends  1.22.2-1

Versions of packages caja suggests:
ii  engrampa1.10.2-1
pn  gstreamer1.0-tools  
ii  meld3.14.1-1

-- no debconf information

Bug#764401: clarity please

[Thorsten Glaser]

Nicholas Bamber dixit:

> Could we get some clarity on this bug report please? I am considering adopting

Yeah, some people have a life and don’t answer eMails 24/7…

> the 'ksh' package and if I do I either want to adopt mksh as well, or work
> closely with the mksh owner.

Mh. I’m maintaining mksh in Debian via sponsors currently, even if
the package doesn’t formally say so, as I left the project.

I answered your original mail in the meantime. The idea is that,
when ksh93 is not available, mksh may provide /bin/ksh, but it
should not do so otherwise.

bye,
//mirabilos
-- 
 exceptions: a truly awful implementation of quite a nice idea.
 just about the worst way you could do something like that, afaic.
 it's like anti-design.   that too… may I quote you on that?
 sure, tho i doubt anyone will listen ;)

Bug#803214: gcl ftbfs on amd64 and i386 with binutils from experimental

[Camm Maguire]

Greeings, and thanks for the report!  While I cannot reproduce this at
first attempt in an experimental chroot on barriere, my guess is that
the libc symbol for gprof's mcount routine has changed from '_mcount' to
'mcount'.  Could this be?

Take care,

Matthias Klose  writes:

> Package: src:gcl
> Version: 2.6.12-27
> Severity: important
> Tags sid stretch
>
> Hi Camm,
>
> gcl ftbfs on amd64 and i386 with binutils from experimental. Would you
> mind having a look at the build failure?
>
> OPTIMIZE levels: Safety=1 (No runtime error checking), Space=0, Speed=3
> Finished compiling /«PKGBUILDDIR»/unixport/../pcl/gcl_pcl_pkg.o.
> Loading binary of GCL_PCL_PKG...
> Loading /«PKGBUILDDIR»/unixport/../pcl/gcl_pcl_pkg.o
> Unrelocated non-local symbol: mcount
>
> Error: ERROR "The assertion !emsg(\"Unrelocated non-local symbol:
> %s\\n\",st1+sym->st_name) on line 236 of sfaslelf.c in function
> relocate_symbols failed"
> Fast links are on: do (si::use-fast-links nil) for debugging
> Signalled by LOAD.
> ERROR "The assertion !emsg(\"Unrelocated non-local symbol:
> %s\\n\",st1+sym->st_name) on line 236 of sfaslelf.c in function
> relocate_symbols failed"
>
> Broken at LOAD.  Type :H for Help.
> 1  Return to top level.
> make[2]: *** [gcl_pcl_boot.c] Error 255
>
> please have a look at these build logs for a reference:
> https://launchpad.net/ubuntu/+source/gcl/2.6.12-27
>
> I haven't looked yet if this is a bad gcl assumption or a binutils
> regression (CCed H.J. Lu on the initial report).
>
> Matthias
>
>
>
>

-- 
Camm Maguirec...@maguirefamily.org
==
"The earth is but one country, and mankind its citizens."  --  Baha'u'llah

Bug#803273: prepare for giflib5

[Matthias Klose]

Package: src:fontforge
Version: 20120731.b-5
Tags: sid stretch patch
Blocks: 803158
User: gif...@packages.debian.org
Usertags: giflib5

Planning an update of giflib to the current version 5.1.1. Giflib slightly 
changes it's API, requiring soureful changes. There are some options for getting 
giflib5.1 support:


- Look for a newer upstream version, if upstream supports
both giflib4 and giflib5.1. Upload the new package,
and close the bug report.

- Patch the code to both use the NEW API. This can be done using
#if GIFLIB_MAJOR >= 5

#else

#endif
Please upload the package, and close the report.

- Unconditionally patch the code, not supporting giflib4 anymore.
Please upload a package to experimental once giflib5 hits
experimental.

For the latter two options, please see a patch at
http://launchpadlibrarian.net/222916207/fontforge_20120731.b-5build2_20120731.b-5ubuntu1.diff.gz

To test your changes before giflib5 is found in experimental, please use

deb https://people.debian.org/~doko/tmp/giflib5 ./

Thanks, Matthias

Bug#803275: yt: FTBFS: tests fail on several architectures

[Aaron M. Ucko]

Source: yt
Version: 3.2.1-2
Severity: important
Justification: fails to build from source

Thanks for fixing yt's Build-Depends setting!  Automated builds are
doing better, but several have failed with test suite errors, and I
suspect more will follow.  Could you please take a look?  You can find
the logs at https://buildd.debian.org/status/logs.php?pkg=yt&ver=3.2.1-2 .

Thanks!

Bug#803276: prepare for giflib5

[Matthias Klose]

Package: src:aseprite
Version: 1.0.9+ds-3
Tags: sid stretch patch
Blocks: 803158
User: gif...@packages.debian.org
Usertags: giflib5

Planning an update of giflib to the current version 5.1.1. Giflib slightly 
changes it's API, requiring soureful changes. There are some options for getting 
giflib5.1 support:


- Look for a newer upstream version, if upstream supports
both giflib4 and giflib5.1. Upload the new package,
and close the bug report.

- Patch the code to both use the NEW API. This can be done using
#if GIFLIB_MAJOR >= 5

#else

#endif
Please upload the package, and close the report.

- Unconditionally patch the code, not supporting giflib4 anymore.
Please upload a package to experimental once giflib5 hits
experimental.

For the latter two options, please see a patch at

To test your changes before giflib5 is found in experimental, please use
http://launchpadlibrarian.net/222921416/aseprite_1.0.9%2Bds-3build3_1.0.9%2Bds-3ubuntu1.diff.gz

deb https://people.debian.org/~doko/tmp/giflib5 ./

Thanks, Matthias

Bug#803274: prepare for giflib5

[Matthias Klose]

Package: src:libgdiplus
Version: 3.6-1
Tags: sid stretch patch
Blocks: 803158
User: gif...@packages.debian.org
Usertags: giflib5

Planning an update of giflib to the current version 5.1.1. Giflib slightly 
changes it's API, requiring soureful changes. There are some options for getting 
giflib5.1 support:


- Look for a newer upstream version, if upstream supports
both giflib4 and giflib5.1. Upload the new package,
and close the bug report.

- Patch the code to both use the NEW API. This can be done using
#if GIFLIB_MAJOR >= 5

#else

#endif
Please upload the package, and close the report.

- Unconditionally patch the code, not supporting giflib4 anymore.
Please upload a package to experimental once giflib5 hits
experimental.

For the latter two options, please see a patch at
http://launchpadlibrarian.net/222916930/libgdiplus_3.6-1build2_3.6-1ubuntu1.diff.gz

To test your changes before giflib5 is found in experimental, please use

deb https://people.debian.org/~doko/tmp/giflib5 ./

Thanks, Matthias

Bug#803278: prepare for giflib5

[Matthias Klose]

Package: src:efl
Version: 1.8.6-2.2
Tags: sid stretch patch
Blocks: 803158
User: gif...@packages.debian.org
Usertags: giflib5

Planning an update of giflib to the current version 5.1.1. Giflib slightly 
changes it's API, requiring soureful changes. There are some options for getting 
giflib5.1 support:


- Look for a newer upstream version, if upstream supports
both giflib4 and giflib5.1. Upload the new package,
and close the bug report.

- Patch the code to both use the NEW API. This can be done using
#if GIFLIB_MAJOR >= 5

#else

#endif
Please upload the package, and close the report.

- Unconditionally patch the code, not supporting giflib4 anymore.
Please upload a package to experimental once giflib5 hits
experimental.

For the latter two options, please see a patch at
http://launchpadlibrarian.net/222923447/efl_1.8.6-2.2ubuntu3_1.8.6-2.2ubuntu4.diff.gz

To test your changes before giflib5 is found in experimental, please use

deb https://people.debian.org/~doko/tmp/giflib5 ./

Thanks, Matthias

Bug#799200: network-manager-strongswan: configuration GUI broken

[Harald Dunkel]

I am surely no gnome user, but if I run gnome-control-center in xfce,
then I don't even get the "IPsec/IKEv2 (strongswan)" menu (with or
without your patch). There is only VPN --> openvpn. ???

In the network manager applet on xfce I can configure a few strongswan
config items (gateway, certificates, a few options), but I am not sure
if others are missing. I do not know if we see the same config
options.

Would you mind to send a screenshot of your IKEv2 config menu in
g-c-c showing the options that are supposed to be added by your fix?
Probably the Ubuntu version is fine; no reason to install Debian.

Thanx very much
Harri

Bug#803277: prepare for giflib5

[Matthias Klose]

Package: src:driftnet
Version: 1.1.5-1
Tags: sid stretch patch
Blocks: 803158
User: gif...@packages.debian.org
Usertags: giflib5

Planning an update of giflib to the current version 5.1.1. Giflib slightly 
changes it's API, requiring soureful changes. There are some options for getting 
giflib5.1 support:


- Look for a newer upstream version, if upstream supports
both giflib4 and giflib5.1. Upload the new package,
and close the bug report.

- Patch the code to both use the NEW API. This can be done using
#if GIFLIB_MAJOR >= 5

#else

#endif
Please upload the package, and close the report.

- Unconditionally patch the code, not supporting giflib4 anymore.
Please upload a package to experimental once giflib5 hits
experimental.

For the latter two options, please see a patch at

To test your changes before giflib5 is found in experimental, please use

deb https://people.debian.org/~doko/tmp/giflib5 ./

Thanks, Matthias

Bug#803279: prepare for giflib5

[Matthias Klose]

Package: src:fenix
Version: 0.92a.dfsg1-11
Tags: sid stretch patch
Blocks: 803158
User: gif...@packages.debian.org
Usertags: giflib5

Planning an update of giflib to the current version 5.1.1. Giflib slightly 
changes it's API, requiring soureful changes. There are some options for getting 
giflib5.1 support:


- Look for a newer upstream version, if upstream supports
both giflib4 and giflib5.1. Upload the new package,
and close the bug report.

- Patch the code to both use the NEW API. This can be done using
#if GIFLIB_MAJOR >= 5

#else

#endif
Please upload the package, and close the report.

- Unconditionally patch the code, not supporting giflib4 anymore.
Please upload a package to experimental once giflib5 hits
experimental.

For the latter two options, please see a patch at
http://launchpadlibrarian.net/222923546/fenix_0.92a.dfsg1-11build2_0.92a.dfsg1-11ubuntu1.diff.gz

To test your changes before giflib5 is found in experimental, please use

deb https://people.debian.org/~doko/tmp/giflib5 ./

Thanks, Matthias

Bug#727059: RE: freeplane: Wrong icon appears on GNOME 3 main and left panels

[Alessio Paonessa]

Hi Felix,





No, no progress. I switched to Debian 8 and the error is still there.





If I'm not wrong, I didn't notice for other java applications. I tried 
JEdit, Eclipse and GNOME Split just now, and the error doesn’t occur. I 
see the right icon when they’re active. It appears a similar error if I 
try Freemind.





I’m not a programmer and I can’t help you so much. Anyway I’m at your disposal 
for simple tasks or testing.





Best Regards





Alessio Paonessa

> From: fnat...@gmx.net
> To: 727...@bugs.debian.org
> CC: livm...@hotmail.com
> Subject: Re: Bug#727059: RE: freeplane: Wrong icon appears on GNOME 3 main 
> and left panels
> Date: Sat, 24 Oct 2015 11:15:05 +0200
> 
> hello Alessio,
> 
> did you make any progress with this?
> 
> I tend to close this, because it's a Ubuntu and not a Freeplane issue
> (the behavior should be the same for other java apps).
> 
> What do you think?
> 
> Best Regards,
> -- 
> Felix Natter
  

Bug#803176: autodep8: please fix the way nodejs/generate gets upstream_name

[Jérémy Lal]

2015-10-28 15:14 GMT+01:00 Antonio Terceiro :

> On Tue, Oct 27, 2015 at 10:32:06PM +0100, Jérémy Lal wrote:
> > 2015-10-27 22:09 GMT+01:00 Antonio Terceiro :
> >
> > > On Tue, Oct 27, 2015 at 06:09:00PM +0100, Jérémy Lal wrote:
> > > > Package: autodep8
> > > > Version: 0.2
> > > > Severity: normal
> > > >
> > > > Dear Maintainer,
> > > >
> > > > Please use this one-liner instead
> > > >
> > > > upstream_name=$(python -c "import json;
> > > print(json.load(open('package.json'))['name'])")
> > >
> > > this broke on the very first NodeJS package I went to try it
> (requirejs):
> > >
> > > $ pwd
> > > /tmp/requirejs-2.1.20
> > > $ python -c "import json;
> print(json.load(open('package.json'))['name'])"
> > > Traceback (most recent call last):
> > >   File "", line 1, in 
> > >   KeyError: 'name'
> > >
> > > We probably want to fallback to looking at the source package name?
> >
> >
> > This is the first time i see this.
> > Yes, keeping existing code as fallback seems to be safer.
> >
> > Note that there is something odd with that module...
> >
> > https://github.com/jrburke/r.js
> > https://github.com/jrburke/r.js/commit/40fa066e
> >
> > https://github.com/jrburke/requirejs
> > https://github.com/jrburke/requirejs/commit/a2029ccd
> >
> > So the correct upstream source seems to be requirejs, not r.js.
> > In any case upstream is using a meta-packager (volo) so in this case
> > package.json cannot be trusted (the fact it is available in the git
> > repository is misleading - it shouldn't even be there).
>
> I improved the situation with this commit:
> http://anonscm.debian.org/cgit/collab-maint/autodep8.git/commit/
>
> However, even then the actual tests are still just a simple load test.
> It will make sure the dependency chain is ok, and that is it.
>

That's something !

Is there any way we can improve on that? Is `npm run test` a more or
> less standard practice in the Node community?
>

It's `npm test` but it wouldn't work because test are run using the
devDependencies listed in package.json, and many debian packages
have devDependencies that are not available in debian.


Jérémy

Bug#799149: emacs24: huge character height in file containing U+FB00 LATIN SMALL LIGATURE FF

[Vincent Lefevre]

Control: reassign -1 fonts-lmodern 2.004.4-5

The problem no longer occurred. Then I found that it reappeared
when downgrading fonts-lmodern alone to 2.004.4-5. Removing this
package solves the problem too. The problem still no longer
occurs if I reinstall the new version fonts-lmodern 2.004.5-1.

On 2015-09-20 01:08:10 +0200, Vincent Lefevre wrote:
> So, it seems that the problem occurs in Emacs only for fonts that
> don't have the U+FB00 LATIN SMALL LIGATURE FF glyph.

So, I suppose that in this case, Emacs tries to find an alternate
font that has such a glyph. With fonts-lmodern 2.004.4-5, strace
shows that it opens

/usr/share/texmf/fonts/opentype/public/lm-math/latinmodernmath-regular.otf

fonts-lmodern 2.004.5-1 no longer has this buggy file, and instead,
Emacs chooses:

/usr/share/fonts/truetype/gentium/Gentium-R.ttf

from the fonts-sil-gentium package.

I'll close the bug once it has been reassigned.

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

Bug#803277: Acknowledgement (prepare for giflib5)

[Matthias Klose]

patch at
http://launchpadlibrarian.net/222922462/driftnet_1.1.5-1build2_1.1.5-1ubuntu1.diff.gz

Bug#803281: prepare for giflib5

[Matthias Klose]

Package: src:gladtex
Version:1.4.2-1
Tags: sid stretch patch
Blocks: 803158
User: gif...@packages.debian.org
Usertags: giflib5

Planning an update of giflib to the current version 5.1.1. Giflib slightly 
changes it's API, requiring soureful changes. There are some options for getting 
giflib5.1 support:


- Look for a newer upstream version, if upstream supports
both giflib4 and giflib5.1. Upload the new package,
and close the bug report.

- Patch the code to both use the NEW API. This can be done using
#if GIFLIB_MAJOR >= 5

#else

#endif
Please upload the package, and close the report.

- Unconditionally patch the code, not supporting giflib4 anymore.
Please upload a package to experimental once giflib5 hits
experimental.

For the latter two options, please see a patch at
http://launchpadlibrarian.net/222923611/gladtex_1.4.2-1build2_1.4.2-1ubuntu1.diff.gz

To test your changes before giflib5 is found in experimental, please use

deb https://people.debian.org/~doko/tmp/giflib5 ./

Thanks, Matthias

Bug#784070: mdadm: diff for NMU version 3.3.2-5.1

[Dimitri John Ledkov]

Hello,

On 28 October 2015 at 12:41,   wrote:
> Control: tags 784070 + patch
>
> Dear maintainer,
>
> I'm about to prepare an NMU for mdadm (versioned as 3.3.2-5.1). The diff is
> attached to this message. Let me know if you want me to upload it.
>

I agree. there have been multiple reports (in debian & ubuntu) that
incremental assembly does not work reliably during early boot,
especially in the initramfs, without e.g. main-loop / systemd
generators / timers support.

Please go ahead, or alternatively I will upload this by the end of the week.

Regards,

Dimitri.

> Regards.
> diff -Nru mdadm-3.3.2/debian/changelog mdadm-3.3.2/debian/changelog
> --- mdadm-3.3.2/debian/changelog2014-12-20 09:48:54.0 +0100
> +++ mdadm-3.3.2/debian/changelog2015-10-28 09:23:56.0 +0100
> @@ -1,3 +1,11 @@
> +mdadm (3.3.2-5.1) unstable; urgency=medium
> +
> +  * Non-maintainer upload.
> +  * disable-incremental-assembly.patch: incremental assembly prevents booting
> +in degraded mode (Closes: #784070)
> +
> + -- Yann Soubeyrand   Tue, 27 Oct 2015 
> 17:16:30 +0100
> +
>  mdadm (3.3.2-5) unstable; urgency=medium
>
>* use-tempnode-not-devnode.patch: change udev rules file to use
> diff -Nru mdadm-3.3.2/debian/patches/disable-incremental-assembly.patch 
> mdadm-3.3.2/debian/patches/disable-incremental-assembly.patch
> --- mdadm-3.3.2/debian/patches/disable-incremental-assembly.patch   
> 1970-01-01 01:00:00.0 +0100
> +++ mdadm-3.3.2/debian/patches/disable-incremental-assembly.patch   
> 2015-10-28 09:14:09.0 +0100
> @@ -0,0 +1,12 @@
> +--- a/udev-md-raid-assembly.rules
>  b/udev-md-raid-assembly.rules
> +@@ -25,6 +25,9 @@ GOTO="md_inc_end"
> +
> + LABEL="md_inc"
> +
> ++# Disable incremental assembly to fix Debian bug #784070
> ++GOTO="md_inc_end"
> ++
> + # remember you can limit what gets auto/incrementally assembled by
> + # mdadm.conf(5)'s 'AUTO' and selectively whitelist using 'ARRAY'
> + ACTION=="add|change", IMPORT{program}="BINDIR/mdadm --incremental --export 
> $tempnode --offroot ${DEVLINKS}"
> diff -Nru mdadm-3.3.2/debian/patches/series mdadm-3.3.2/debian/patches/series
> --- mdadm-3.3.2/debian/patches/series   2014-12-05 16:59:42.0 +0100
> +++ mdadm-3.3.2/debian/patches/series   2015-10-27 17:20:07.0 +0100
> @@ -7,3 +7,4 @@
>  rebuildmap-strip-local-host-name-from-device-name.patch
>  readlink-path.patch
>  mdmonitor-service-simplify.diff
> +disable-incremental-assembly.patch



-- 
Regards,

Dimitri.

Bug#803282: prepare for giflib5

[Matthias Klose]

Package: src:libextractor
Version: 1:1.3-2
Tags: sid stretch patch
Blocks: 803158
User: gif...@packages.debian.org
Usertags: giflib5

Planning an update of giflib to the current version 5.1.1. Giflib slightly 
changes it's API, requiring soureful changes. There are some options for getting 
giflib5.1 support:


- Look for a newer upstream version, if upstream supports
both giflib4 and giflib5.1. Upload the new package,
and close the bug report.

- Patch the code to both use the NEW API. This can be done using
#if GIFLIB_MAJOR >= 5

#else

#endif
Please upload the package, and close the report.

- Unconditionally patch the code, not supporting giflib4 anymore.
Please upload a package to experimental once giflib5 hits
experimental.

For the latter two options, please see a patch at
http://launchpadlibrarian.net/222924668/libextractor_1%3A1.3-2build3_1%3A1.3-2ubuntu1.diff.gz

To test your changes before giflib5 is found in experimental, please use

deb https://people.debian.org/~doko/tmp/giflib5 ./

Thanks, Matthias

Bug#803284: plasmashell: Crash in xcb_send_request/xcb_intern_atom

[Gregor Riepl]

5  5.4.2+dfsg-9
ii  libqt5qml5  5.4.2-6
ii  libqt5quick55.4.2-6
ii  libqt5script5   5.4.2+dfsg-4
ii  libqt5sql5  5.4.2+dfsg-9
ii  libqt5webkit5   5.4.2+dfsg-3
ii  libqt5widgets5  5.4.2+dfsg-9
ii  libqt5x11extras55.5.1-2
ii  libqt5xml5  5.4.2+dfsg-9
ii  libsm6  2:1.2.2-1+b1
ii  libstdc++6  5.2.1-22
ii  libtaskmanager5 4:5.4.2-1
ii  libwayland-client0  1.9.0-1
ii  libwayland-server0  1.9.0-1
ii  libweather-ion7 4:5.4.2-1
ii  libx11-62:1.6.3-1
ii  libxcb-keysyms1 0.4.0-1
ii  libxcb1 1.10-3+b1
ii  libxfixes3  1:5.0.1-2+b2
ii  libxi6  2:1.7.5-1
ii  libxrender1 1:0.9.8-1+b1
ii  milou   4:5.4.2-1
ii  phonon4qt5  4:4.8.3-2
ii  plasma-framework5.15.0-1
ii  qdbus-qt5   5.4.2-3
ii  qml-module-org-kde-extensionplugin  5.15.0-1
ii  qml-module-org-kde-kwindowsystem5.15.0-1
ii  qml-module-qtgraphicaleffects   5.5.1-2
ii  qml-module-qtquick-controls 5.4.2-2+b1
ii  qml-module-qtquick-dialogs  5.4.2-2+b1
ii  qml-module-qtquick-layouts  5.4.2-2+b1
ii  qml-module-qtquick-window2  5.4.2-6
ii  qml-module-qtquick2 5.4.2-6
ii  qtdeclarative5-kf5declarative   5.15.0-1
ii  qtdeclarative5-kf5solid 5.15.0-1
ii  qttools5-dev-tools  5.4.2-3
ii  udisks2 2.1.6-2
ii  x11-utils   7.7+3
ii  x11-xserver-utils   7.7+5
ii  zlib1g  1:1.2.8.dfsg-2+b1

Versions of packages plasma-workspace recommends:
ii  kio-extras   4:15.08.2-1
pn  libpam-kwallet5  

plasma-workspace suggests no packages.

-- no debconf information

*** plasmashell-20151028-034631.kcrash.txt
Application: Plasma (plasmashell), signal: Segmentation fault
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
[Current thread is 1 (Thread 0x7fbd26c36940 (LWP 15860))]

Thread 2 (Thread 0x7fbdd700 (LWP 15866)):
#0  0x7fbd213e52d3 in select () at ../sysdeps/unix/syscall-template.S:81
#1  0x7fbd21c3fb1f in ?? () from /usr/lib/x86_64-linux-gnu/libQt5Core.so.5
#2  0x7fbd21acc25e in ?? () from /usr/lib/x86_64-linux-gnu/libQt5Core.so.5
#3  0x7fbd20bec0a4 in start_thread (arg=0x7fbdd700) at
pthread_create.c:309
#4  0x7fbd213ec06d in clone () at
.../sysdeps/unix/sysv/linux/x86_64/clone.S:111

Thread 1 (Thread 0x7fbd26c36940 (LWP 15860)):
[KCrash Handler]
#4  xcb_send_request (c=0x0, flags=flags@entry=1,
vector=vector@entry=0x7ffe1c794010, req=req@entry=0x7fbd25443280 ) at
.../../src/xcb_out.c:160
#5  0x7fbd25438caf in xcb_intern_atom (c=,
only_if_exists=only_if_exists@entry=0 '\000', name_len=,
name=name@entry=0x7fbd23e302e0 "UTF8_STRING") at xproto.c:3338
#6  0x7fbd23e20380 in Atoms::init (this=this@entry=0x241dca0) at
.../../src/platforms/xcb/netwm.cpp:304
#7  0x7fbd23e24e37 in Atoms::Atoms (c=, this=0x241dca0) at
.../../src/platforms/xcb/netwm.cpp:83
#8  atomsForConnection (c=c@entry=0x0) at ../../src/platforms/xcb/netwm.cpp:69
#9  0x7fbd23e27373 in NETRootInfo::NETRootInfo (this=0x2412cb0,
connection=0x0, properties=..., properties2=..., screen=-1,
doActivate=) at ../../src/platforms/xcb/netwm.cpp:517
#10 0x7fbd10509e9b in NETEventFilter::NETEventFilter (this=0x2412cb0,
_what=KWindowSystemPrivateX11::INFO_BASIC) at
.../../../../src/platforms/xcb/kwindowsystem.cpp:98
#11 0x7fbd1050a421 in MainThreadInstantiator::createNETEventFilter
(this=0x7ffe1c794640) at ../../../../src/platforms/xcb/kwindowsystem.cpp:85
#12 KWindowSystemPrivateX11::init (this=this@entry=0x2415cf0, what=) at ../../../../src/platforms/xcb/kwindowsystem.cpp:448
#13 0x7fbd1050a586 in KWindowSystemPrivateX11::connectNotify
(this=0x2415cf0, signal=...) at
.../../../../src/platforms/xcb/kwindowsystem.cpp:425
#14 0x7fbd23e17f08 in KWindowSystem::connectNotify (this=0x7fbd2403d200
<(anonymous namespace)::Q_QGS_g_kwmInstanceContainer::innerFunction()::holder>,
signal=...) at ../../src/kwindowsystem.cpp:365
#15 0x7fbd21cdf85a in QObjectPrivate::connectImpl(QObject const*, int,
QObject const*, void**, QtPrivate::QSlotObjectBase*, Qt::ConnectionType, int
const*, QMetaObject const*) () from /usr/lib/x86_64-linux-gnu/libQt5Core.so.5
#16 0x7fbd21cdfa1a in QObject::connectImpl(QObject const*, void**, QObject
const*, void**, QtPrivate::QSlotObjectBase*, Qt::ConnectionType, int const*,
QMetaObject const*) () from /usr/lib/x86_64-linux-gnu/libQt5Core.so.5
#17 0x00457489 in Shel

Bug#803283: prepare for giflib5

[Matthias Klose]

Package: src:gnustep-gui
Version: 0.24.0-3
Tags: sid stretch patch
Blocks: 803158
User: gif...@packages.debian.org
Usertags: giflib5

Planning an update of giflib to the current version 5.1.1. Giflib slightly 
changes it's API, requiring soureful changes. There are some options for getting 
giflib5.1 support:


- Look for a newer upstream version, if upstream supports
both giflib4 and giflib5.1. Upload the new package,
and close the bug report.

- Patch the code to both use the NEW API. This can be done using
#if GIFLIB_MAJOR >= 5

#else

#endif
Please upload the package, and close the report.

- Unconditionally patch the code, not supporting giflib4 anymore.
Please upload a package to experimental once giflib5 hits
experimental.

For the latter two options, please see a patch at
http://launchpadlibrarian.net/222924806/gnustep-gui_0.24.0-3build4_0.24.0-3ubuntu1.diff.gz

To test your changes before giflib5 is found in experimental, please use

deb https://people.debian.org/~doko/tmp/giflib5 ./

Thanks, Matthias

Bug#803285: prepare for giflib5

[Matthias Klose]

Package: src:metapixel
Version: 1.0.2-7.1
Tags: sid stretch patch
Blocks: 803158
User: gif...@packages.debian.org
Usertags: giflib5

Planning an update of giflib to the current version 5.1.1. Giflib slightly 
changes it's API, requiring soureful changes. There are some options for getting 
giflib5.1 support:


- Look for a newer upstream version, if upstream supports
both giflib4 and giflib5.1. Upload the new package,
and close the bug report.

- Patch the code to both use the NEW API. This can be done using
#if GIFLIB_MAJOR >= 5

#else

#endif
Please upload the package, and close the report.

- Unconditionally patch the code, not supporting giflib4 anymore.
Please upload a package to experimental once giflib5 hits
experimental.

For the latter two options, please see a patch at
http://launchpadlibrarian.net/222924863/metapixel_1.0.2-7.1build2_1.0.2-7.1ubuntu1.diff.gz

To test your changes before giflib5 is found in experimental, please use

deb https://people.debian.org/~doko/tmp/giflib5 ./

Thanks, Matthias

Bug#803280: ITP: libtext-unicode-equivalents-perl -- build Unicode canonically equivalent strings

[Daniel Glassey]

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

Package name: libtext-unicode-equivalents-perl
Version : 0.05
Upstream Author : Bob Hallissy 
URL : https://metacpan.org/release/Text-Unicode-Equivalents
License : Artistic
Programming Lang: Perl
Description : build Unicode canonically equivalent strings
 Given an arbitrary string, "all_strings()" returns a reference to an
 unsorted array of all unique strings that are canonically equivalent
 to the argument.

The package will be maintained under the umbrella of the Debian Perl Group.

It is a dependency of Font::TTF::Scripts (#614917)

Bug#803286: prepare for giflib5

[Matthias Klose]

Package: src:mtpaint
Version: 3.40-2
Tags: sid stretch patch
Blocks: 803158
User: gif...@packages.debian.org
Usertags: giflib5

Planning an update of giflib to the current version 5.1.1. Giflib slightly 
changes it's API, requiring soureful changes. There are some options for getting 
giflib5.1 support:


- Look for a newer upstream version, if upstream supports
both giflib4 and giflib5.1. Upload the new package,
and close the bug report.

- Patch the code to both use the NEW API. This can be done using
#if GIFLIB_MAJOR >= 5

#else

#endif
Please upload the package, and close the report.

- Unconditionally patch the code, not supporting giflib4 anymore.
Please upload a package to experimental once giflib5 hits
experimental.

For the latter two options, please see a patch at
http://launchpadlibrarian.net/222926300/mtpaint_3.40-2build2_3.40-2ubuntu1.diff.gz

To test your changes before giflib5 is found in experimental, please use

deb https://people.debian.org/~doko/tmp/giflib5 ./

Thanks, Matthias

Bug#803287: prepare for giflib5

[Matthias Klose]

Package: src:ming
Version: 1:0.4.5-1.2
Tags: sid stretch patch
Blocks: 803158
User: gif...@packages.debian.org
Usertags: giflib5

Planning an update of giflib to the current version 5.1.1. Giflib slightly 
changes it's API, requiring soureful changes. There are some options for getting 
giflib5.1 support:


- Look for a newer upstream version, if upstream supports
both giflib4 and giflib5.1. Upload the new package,
and close the bug report.

- Patch the code to both use the NEW API. This can be done using
#if GIFLIB_MAJOR >= 5

#else

#endif
Please upload the package, and close the report.

- Unconditionally patch the code, not supporting giflib4 anymore.
Please upload a package to experimental once giflib5 hits
experimental.

For the latter two options, please see a patch at
http://launchpadlibrarian.net/222927502/ming_1%3A0.4.5-1.2ubuntu4_1%3A0.4.5-1.2ubuntu5.diff.gz

To test your changes before giflib5 is found in experimental, please use

deb https://people.debian.org/~doko/tmp/giflib5 ./

Thanks, Matthias

Bug#803036: qemu-system-x86: Qemu guest hangs 100% CPU on IO

[Gavin Pidgley]

 

Is it possible that these changes can be backported? I can see 2.4 is
available in "testing", but won't be released for the foreseeable future
and I presume 2.4 itself it unlikely to get backported to Wheezy anyhow.


It would be greatly appreciated if these specific fixes can be
backported at least, as it's causing us issues on our production
environment and upgrading doesn't look like it will be an option for
some time. 

Thanks, 

Gavin 

On 2015-10-28 13:46, Michael Tokarev wrote: 

> 26.10.2015 11:54, Gavin Pidgley wrote:
> 
>> Package: qemu-system-x86 Version: 2.1+dfsg-12~bpo70+1 Severity: important 
>> Dear Maintainer, We are seeing guests lockup/hang with qemu. The guests hang 
>> with 100% CPU usage. The problem seems to be storage/IO related, but there 
>> is not necessarily high IO happening on the host at the time the guest hangs.
> 
> There were some revork in this layer for 2.4 version, which is not easily to
> backport to 2.1. This _might_ be the issue you're expiriencing, or it might
> be a different one. There were several reports about qemu locking up on slow
> I/O, but it is very difficult to debug, and reportedly after the rework the
> lockups stopped from occuring.
> 
> That's what I have in mind:
> 
> https://lists.gnu.org/archive/html/qemu-devel/2015-09/msg05294.html [1]
> 
> Thanks,
> 
> /mjt
 

Links:
--
[1] https://lists.gnu.org/archive/html/qemu-devel/2015-09/msg05294.html

Bug#803289: prepare for giflib5

[Matthias Klose]

Package: src:prima
Version: 1.28-1.3
Tags: sid stretch patch
Blocks: 803158
User: gif...@packages.debian.org
Usertags: giflib5

Planning an update of giflib to the current version 5.1.1. Giflib slightly 
changes it's API, requiring soureful changes. There are some options for getting 
giflib5.1 support:


- Look for a newer upstream version, if upstream supports
both giflib4 and giflib5.1. Upload the new package,
and close the bug report.

- Patch the code to both use the NEW API. This can be done using
#if GIFLIB_MAJOR >= 5

#else

#endif
Please upload the package, and close the report.

- Unconditionally patch the code, not supporting giflib4 anymore.
Please upload a package to experimental once giflib5 hits
experimental.

For the latter two options, please see a patch at
http://launchpadlibrarian.net/222930891/prima_1.28-1.3build3_1.28-1.3ubuntu1.diff.gz
To test your changes before giflib5 is found in experimental, please use

deb https://people.debian.org/~doko/tmp/giflib5 ./

Thanks, Matthias

Bug#803036: qemu-system-x86: Qemu guest hangs 100% CPU on IO

[Michael Tokarev]

28.10.2015 17:41, Gavin Pidgley пишет:
> Is it possible that these changes can be backported?

Not by me, and it is very unlikely the release team can be convinced the
result is safe.  These patches applies on top of event loop refactoring
happened during 2.4 release cycle and requires relatively large number
of other changes all over.

>  I can see 2.4 is available in "testing", but won't be released for the 
> foreseeable future and I presume 2.4 itself it unlikely to get backported to 
> Wheezy anyhow.

I will provide backports of current version to stable (and current
version is already in stable-backports).  Wheezy only receives
"backports" from jessie.

Thanks,

/mjt

Bug#803290: prepare for giflib5

[Matthias Klose]

Package: src:qutemol
Version: 0.4.1~cvs2008-3.2
Tags: sid stretch patch
Blocks: 803158
User: gif...@packages.debian.org
Usertags: giflib5

Planning an update of giflib to the current version 5.1.1. Giflib slightly 
changes it's API, requiring soureful changes. There are some options for getting 
giflib5.1 support:


- Look for a newer upstream version, if upstream supports
both giflib4 and giflib5.1. Upload the new package,
and close the bug report.

- Patch the code to both use the NEW API. This can be done using
#if GIFLIB_MAJOR >= 5

#else

#endif
Please upload the package, and close the report.

- Unconditionally patch the code, not supporting giflib4 anymore.
Please upload a package to experimental once giflib5 hits
experimental.

For the latter two options, please see a patch at
http://launchpadlibrarian.net/222931449/qutemol_0.4.1~cvs2008-3.2build3_0.4.1~cvs2008-3.2ubuntu1.diff.gz

To test your changes before giflib5 is found in experimental, please use

deb https://people.debian.org/~doko/tmp/giflib5 ./

Thanks, Matthias

Bug#803291: prepare for giflib5

[Matthias Klose]

Package: src:swftools_
Version: 0.9.2+git20130725-2
Tags: sid stretch patch
Blocks: 803158
User: gif...@packages.debian.org
Usertags: giflib5

Planning an update of giflib to the current version 5.1.1. Giflib slightly 
changes it's API, requiring soureful changes. There are some options for getting 
giflib5.1 support:


- Look for a newer upstream version, if upstream supports
both giflib4 and giflib5.1. Upload the new package,
and close the bug report.

- Patch the code to both use the NEW API. This can be done using
#if GIFLIB_MAJOR >= 5

#else

#endif
Please upload the package, and close the report.

- Unconditionally patch the code, not supporting giflib4 anymore.
Please upload a package to experimental once giflib5 hits
experimental.

For the latter two options, please see a patch at
http://launchpadlibrarian.net/222931742/swftools_0.9.2%2Bgit20130725-2build2_0.9.2%2Bgit20130725-2ubuntu1.diff.gz

To test your changes before giflib5 is found in experimental, please use

deb https://people.debian.org/~doko/tmp/giflib5 ./

Thanks, Matthias

Bug#803288: RM: amsn -- ROM; deprecated, servers down, can't be used anymore

[Vivia Nikolaidou]

Package: ftp.debian.org
Severity: normal

Hi,

please remove amsn (and amsn-data). It was relying on using
Microsoft's Windows Live Messenger servers to connect. However,
Microsoft deprecated that service in favor of Skype. Therefore, amsn
can now be removed, as it cannot be used anymore.

Thanks!

Bug#803294: prepare for giflib5

[Matthias Klose]

Package: src:ziproxy
Version: 3.2.0-2
Tags: sid stretch patch
Blocks: 803158
User: gif...@packages.debian.org
Usertags: giflib5

Planning an update of giflib to the current version 5.1.1. Giflib slightly 
changes it's API, requiring soureful changes. There are some options for getting 
giflib5.1 support:


- Look for a newer upstream version, if upstream supports
both giflib4 and giflib5.1. Upload the new package,
and close the bug report.

- Patch the code to both use the NEW API. This can be done using
#if GIFLIB_MAJOR >= 5

#else

#endif
Please upload the package, and close the report.

- Unconditionally patch the code, not supporting giflib4 anymore.
Please upload a package to experimental once giflib5 hits
experimental.

For the latter two options, please see a patch at
http://launchpadlibrarian.net/222933036/ziproxy_3.2.0-2build2_3.2.0-2ubuntu1.diff.gz

To test your changes before giflib5 is found in experimental, please use

deb https://people.debian.org/~doko/tmp/giflib5 ./

Thanks, Matthias

Bug#803292: prepare for giflib5

[Matthias Klose]

Package: src:wmaker
Version: 0.95.6-1.1
Tags: sid stretch patch
Blocks: 803158
User: gif...@packages.debian.org
Usertags: giflib5

Planning an update of giflib to the current version 5.1.1. Giflib slightly 
changes it's API, requiring soureful changes. There are some options for getting 
giflib5.1 support:


- Look for a newer upstream version, if upstream supports
both giflib4 and giflib5.1. Upload the new package,
and close the bug report.

- Patch the code to both use the NEW API. This can be done using
#if GIFLIB_MAJOR >= 5

#else

#endif
Please upload the package, and close the report.

- Unconditionally patch the code, not supporting giflib4 anymore.
Please upload a package to experimental once giflib5 hits
experimental.

For the latter two options, please see a patch at
http://launchpadlibrarian.net/222932082/wmaker_0.95.6-1.1build2_0.95.6-1.1ubuntu1.diff.gz

To test your changes before giflib5 is found in experimental, please use

deb https://people.debian.org/~doko/tmp/giflib5 ./

Thanks, Matthias

Bug#803293: prepare for giflib5

[Matthias Klose]

Package: src:xplanet
Version: 1.3.0-2
Tags: sid stretch patch
Blocks: 803158
User: gif...@packages.debian.org
Usertags: giflib5

Planning an update of giflib to the current version 5.1.1. Giflib slightly 
changes it's API, requiring soureful changes. There are some options for getting 
giflib5.1 support:


- Look for a newer upstream version, if upstream supports
both giflib4 and giflib5.1. Upload the new package,
and close the bug report.

- Patch the code to both use the NEW API. This can be done using
#if GIFLIB_MAJOR >= 5

#else

#endif
Please upload the package, and close the report.

- Unconditionally patch the code, not supporting giflib4 anymore.
Please upload a package to experimental once giflib5 hits
experimental.

For the latter two options, please see a patch at
http://launchpadlibrarian.net/222932858/xplanet_1.3.0-2build2_1.3.0-2ubuntu1.diff.gz

To test your changes before giflib5 is found in experimental, please use

deb https://people.debian.org/~doko/tmp/giflib5 ./

Thanks, Matthias

Bug#764401: clarity please

[Nicholas Bamber]

Okay removing Kenneth as he clearly does not want to be involved.

Please could Thorsten and Dominik please work out who will be 
responsible for mksh in Debian? Can you work together if that makes 
sense? I can sign and upload  if necessary.


I have an issue with this:

> I answered your original mail in the meantime. The idea is that,
> when ksh93 is not available, mksh may provide /bin/ksh, but it
> should not do so otherwise.


It seems to me one of the following hold:
1.) The current ksh package IS ksh. mksh is a different (albeit similar) 
package. In this case ksh should never be a link to mksh.
2.) ksh93 and mksh are alternative implementations of ksh (with subtle 
differences that should be documented). In this case both can coexist on 
Debian but one (potentially either but by default ksh93) should assume 
the role of ksh.


On 28/10/15 14:19, Thorsten Glaser wrote:

Nicholas Bamber dixit:


Could we get some clarity on this bug report please? I am considering adopting


Yeah, some people have a life and don’t answer eMails 24/7…


the 'ksh' package and if I do I either want to adopt mksh as well, or work
closely with the mksh owner.


Mh. I’m maintaining mksh in Debian via sponsors currently, even if
the package doesn’t formally say so, as I left the project.

I answered your original mail in the meantime. The idea is that,
when ksh93 is not available, mksh may provide /bin/ksh, but it
should not do so otherwise.

bye,
//mirabilos

Bug#803295: prepare for giflib5

[Matthias Klose]

Package: src:spamprobe
Version: 1.4d-13
Tags: sid stretch patch
Blocks: 803158
User: gif...@packages.debian.org
Usertags: giflib5

Planning an update of giflib to the current version 5.1.1. Giflib slightly 
changes it's API, requiring soureful changes. There are some options for getting 
giflib5.1 support:


- Look for a newer upstream version, if upstream supports
both giflib4 and giflib5.1. Upload the new package,
and close the bug report.

- Patch the code to both use the NEW API. This can be done using
#if GIFLIB_MAJOR >= 5

#else

#endif
Please upload the package, and close the report.

- Unconditionally patch the code, not supporting giflib4 anymore.
Please upload a package to experimental once giflib5 hits
experimental.

For the latter two options, please see a patch at
http://launchpadlibrarian.net/222933095/spamprobe_1.4d-13build2_1.4d-13ubuntu1.diff.gz

To test your changes before giflib5 is found in experimental, please use

deb https://people.debian.org/~doko/tmp/giflib5 ./

Thanks, Matthias

Bug#764401: clarity please

[Dominik George]

Thorsten,

> Mh. I’m maintaining mksh in Debian via sponsors currently, even if
> the package doesn’t formally say so, as I left the project.

please either maintain mksh, or don't.

Saying „I have left the project, but want control over packages so and so“ 
does not make very much sense for the project.

Please clearly state what your intention is, both here and in the package 
control.

-nik

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

Dominik George · Mobil: +49-151-61623918

Teckids e.V. · FrOSCon e.V. · OpenRheinRuhr e.V.
Fellowship of the FSFE · Piratenpartei Deutschland
Opencaching Deutschland e.V. · Debian Contributor

LPIC-3 Linux Enterprise Professional (Security)

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

Bug#803297: prepare for giflib5

[Matthias Klose]

Package: src:kmess
Version: 2.0.6.1-3
Tags: sid stretch patch
Blocks: 803158
User: gif...@packages.debian.org
Usertags: giflib5

Planning an update of giflib to the current version 5.1.1. Giflib slightly 
changes it's API, requiring soureful changes. There are some options for getting 
giflib5.1 support:


- Look for a newer upstream version, if upstream supports
both giflib4 and giflib5.1. Upload the new package,
and close the bug report.

- Patch the code to both use the NEW API. This can be done using
#if GIFLIB_MAJOR >= 5

#else

#endif
Please upload the package, and close the report.

- Unconditionally patch the code, not supporting giflib4 anymore.
Please upload a package to experimental once giflib5 hits
experimental.

For the latter two options, please see a patch at
http://launchpadlibrarian.net/222935645/kmess_2.0.6.1-3build2_2.0.6.1-3ubuntu1.diff.gz

To test your changes before giflib5 is found in experimental, please use

deb https://people.debian.org/~doko/tmp/giflib5 ./

Thanks, Matthias

Bug#803296: prepare for giflib5

[Matthias Klose]

Package: src:exactimage
Version: 0.9.1-6
Tags: sid stretch patch
Blocks: 803158
User: gif...@packages.debian.org
Usertags: giflib5

Planning an update of giflib to the current version 5.1.1. Giflib slightly 
changes it's API, requiring soureful changes. There are some options for getting 
giflib5.1 support:


- Look for a newer upstream version, if upstream supports
both giflib4 and giflib5.1. Upload the new package,
and close the bug report.

- Patch the code to both use the NEW API. This can be done using
#if GIFLIB_MAJOR >= 5

#else

#endif
Please upload the package, and close the report.

- Unconditionally patch the code, not supporting giflib4 anymore.
Please upload a package to experimental once giflib5 hits
experimental.

For the latter two options, please see a patch at
http://launchpadlibrarian.net/222935404/exactimage_0.9.1-6build2_0.9.1-6ubuntu1.diff.gz

To test your changes before giflib5 is found in experimental, please use

deb https://people.debian.org/~doko/tmp/giflib5 ./

Thanks, Matthias

Bug#802830: amsn: non-DFSG file licensed under APSL-1.1

[Vivia Nikolaidou]

Hi and thanks for reporting the bug. I am the maintainer of aMSN.

The whole utils/macosx directory can go away, because obviously
there's no use for it on Linux (It should have been removed at the
first place).

However, given that now aMSN is obsolete, I've requested for the whole
package to be removed [1].

Thanks,

Vivia

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

On 24 October 2015 at 00:46, Dmitry Smirnov  wrote:
> Source: amsn
> Version: 0.98.9-1
> Severity: important
>
> According to its header, the following file is licensed as non-DFSG
> APSL-1.1 [1] license:
>
> utils/macosx/make_dmg/openUp.c
>
> Also right next to it there is a pre-built binary
> "utils/macosx/make_dmg/openUp" which would be nice to remove from tarball
> as well.
>
> Please investigate.
>
> [1]: 
> https://wiki.debian.org/DFSGLicenses#Apple_Public_Source_License_.28APSL.29
>
> --
> Regards,
>  Dmitry Smirnov
>  GPG key : 4096R/53968D1B

Bug#803299: prepare for giflib5

[Matthias Klose]

Package: src:mapserver
Version: 7.0.0-5
Tags: sid stretch patch
Blocks: 803158
User: gif...@packages.debian.org
Usertags: giflib5

Planning an update of giflib to the current version 5.1.1. Giflib slightly 
changes it's API, requiring soureful changes. There are some options for getting 
giflib5.1 support:


- Look for a newer upstream version, if upstream supports
both giflib4 and giflib5.1. Upload the new package,
and close the bug report.

- Patch the code to both use the NEW API. This can be done using
#if GIFLIB_MAJOR >= 5

#else

#endif
Please upload the package, and close the report.

- Unconditionally patch the code, not supporting giflib4 anymore.
Please upload a package to experimental once giflib5 hits
experimental.

For the latter two options, please see a patch at
http://launchpadlibrarian.net/222944103/mapserver_7.0.0-5build1_7.0.0-5ubuntu1.diff.gz

To test your changes before giflib5 is found in experimental, please use

deb https://people.debian.org/~doko/tmp/giflib5 ./

Thanks, Matthias

Bug#803298: prepare for giflib5

[Matthias Klose]

Package: src:boats
Version: 201307-1
Tags: sid stretch patch
Blocks: 803158
User: gif...@packages.debian.org
Usertags: giflib5

Planning an update of giflib to the current version 5.1.1. Giflib slightly 
changes it's API, requiring soureful changes. There are some options for getting 
giflib5.1 support:


- Look for a newer upstream version, if upstream supports
both giflib4 and giflib5.1. Upload the new package,
and close the bug report.

- Patch the code to both use the NEW API. This can be done using
#if GIFLIB_MAJOR >= 5

#else

#endif
Please upload the package, and close the report.

- Unconditionally patch the code, not supporting giflib4 anymore.
Please upload a package to experimental once giflib5 hits
experimental.

For the latter two options, please see a patch at
http://launchpadlibrarian.net/222938828/boats_201307-1build2_201307-1ubuntu1.diff.gz

To test your changes before giflib5 is found in experimental, please use

deb https://people.debian.org/~doko/tmp/giflib5 ./

Thanks, Matthias

Bug#803300: prepare for giflib5

[Matthias Klose]

Package: src:openscenegraph
Version: 3.2.1-7
Tags: sid stretch patch
Blocks: 803158
User: gif...@packages.debian.org
Usertags: giflib5

Planning an update of giflib to the current version 5.1.1. Giflib slightly 
changes it's API, requiring soureful changes. There are some options for getting 
giflib5.1 support:


- Look for a newer upstream version, if upstream supports
both giflib4 and giflib5.1. Upload the new package,
and close the bug report.

- Patch the code to both use the NEW API. This can be done using
#if GIFLIB_MAJOR >= 5

#else

#endif
Please upload the package, and close the report.

- Unconditionally patch the code, not supporting giflib4 anymore.
Please upload a package to experimental once giflib5 hits
experimental.

For the latter two options, please see a patch at
http://launchpadlibrarian.net/222944251/openscenegraph_3.2.1-7ubuntu2_3.2.1-7ubuntu3.diff.gz

To test your changes before giflib5 is found in experimental, please use

deb https://people.debian.org/~doko/tmp/giflib5 ./

Thanks, Matthias

Bug#803214: gcl ftbfs on amd64 and i386 with binutils from experimental

[Camm Maguire]

Greetings!  Just a followup -- gcl builds in current Debian
experimental.  Perhaps something else ubuntu specific?

Take care,
-- 
Camm Maguirec...@maguirefamily.org
==
"The earth is but one country, and mankind its citizens."  --  Baha'u'llah

Bug#803242: (no subject)

[Barry Warsaw]

Thanks for diagnosing this further Matthias.  I think you're on the right
track.  For example, if I add this to zope.testing's d/rules, the bogus empty
/usr/lib/python3.5/dist-packages directory does not get installed:

override_dh_auto_test:
dh_auto_test
rm -rf .pybuild/pythonX.Y_*/build/zope.testing.egg-info

So it does seem to be an artifact of running the test suite.

Bug#764401: clarity please

[Nicholas Bamber]

I have thought about this comment a little more:


> It is my agreement with David Korn (the ‘k’ in “ksh”) that
> mksh must not be confused for the original, so please refrain
> from doing so.

It seems to me that if a link from ksh to mksh is not an infringement of 
this agreement, then big notices in the mksh man page, package 
description etc that mksh is NOT the original korn shell, would be a 
more appropriate way of adhering to the agreement then leaving mksh/ksh 
interactions in a messed up state.

Bug#801106: sddm still fails to start

[Gary Dale]

Package: sddm
Version: 0.12.0-4
Followup-For: Bug #801106

Dear Maintainer,

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

   * What led up to the situation?
I restarted my system this morning but it failed to bring up a login screen

   * What exactly did you do (or not do) that was effective (or ineffective)?
Booted to rescue mode and did an update/full-upgrade. When that didn't fix 
the problem, I installed xdm.

   * What was the outcome of this action?
I can now get to a login screen and run a gui.

   * What outcome did you expect instead?

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


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

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

Versions of packages sddm depends on:
ii  adduser 3.113+nmu3
ii  debconf [debconf-2.0]   1.5.57
ii  libc6   2.19-22
ii  libgcc1 1:5.2.1-22
ii  libpam0g1.1.8-3.1
ii  libqt5core5a5.4.2+dfsg-9
ii  libqt5dbus5 5.4.2+dfsg-9
ii  libqt5gui5  5.4.2+dfsg-9
ii  libqt5network5  5.4.2+dfsg-9
ii  libqt5qml5  5.4.2-6
ii  libqt5quick55.4.2-6
ii  libstdc++6  5.2.1-22
ii  libsystemd0 227-2
ii  libxcb-xkb1 1.10-3+b1
ii  libxcb1 1.10-3+b1
ii  qml-module-qtquick2 5.4.2-6
ii  sddm-theme-breeze [sddm-theme]  4:5.4.2-1

sddm recommends no packages.

Versions of packages sddm suggests:
ii  libpam-kwallet5  5.4.2-1

-- debconf information:
* shared/default-x-display-manager: xdm
  sddm/daemon_name: /usr/bin/sddm

Bug#799281: Any update to packaging Mailman3-core ?

[Pierre-Elliott Bécue]

On mer. 28 oct. 2015 à 20:19:49, shirish wrote:
> Dear Pierre-Elliott Bécue,
> 
> Any update on the packaging of Mailman-3-core ?
> 
> Looking forward to learn more.

Good afternoon,

Heres some update:

 * I had some troubles with dependencies, that were fixed in the begining of
   October.
 * I met a lot of troubles having tests working, because they require the
   package to be installed. finally worked around using adt.
 * The packaging was working under experimental at the begining of October
 * The packaging is working under sid for some day
 * I'm currently working on a patch to move some binaries in
   /var/lib/mailman3/bin instead of /usr/bin, and I intend to see with
   upstream if they agree on merging that patch (some binaries have cool names
   but these names are too generic)
 * I'm also designing a basic configuration file and systemd unit

So, it's going on, slowly. Anyway, it is planned to wait the next (minor) 
release
before packaging, so that some issues reported since initial release will be
fixed.

I hope my answer satisfies your curiosity. :)

-- 
PEB

Bug#764401: clarity please

[Thorsten Glaser]

Nicholas Bamber dixit:

> Please could Thorsten and Dominik please work out who will be responsible for
> mksh in Debian? Can you work together if that makes sense? I can sign and
> upload  if necessary.

OK, we had a short talk on the office floor about this ;-) and
I’ll be putting myself back into the Maintainer field and take
formal responsibility for this as external contributor.

> 2.) ksh93 and mksh are alternative implementations of ksh (with subtle
> differences that should be documented). In this case both can coexist on 
> Debian
> but one (potentially either but by default ksh93) should assume the role of
> ksh.

This is what is currently true, and the desired outcome:

• scripts specific to ksh93 use ksh93 in the shebang
• scripts specific to mksh use mksh in the shebang
• scripts using ksh in the shebang can be…
  – old pdksh scripts,
  – old ksh88 scripts,
  – or scripts written for “any ksh subset” – I did a short
UDD search just now, and all cases of this in Debian
also accept zsh as ksh providing package.

This means that, if only one of ksh93 or mksh is installed,
that package takes over ksh, but if both are installed, the
official Korn Shell should take over ksh (unless the local
admin overrides, of course).

All use cases in Debian use alternative package relationships,
i.e. don’t force the installation of one specific variant but
don’t use a virtual package either. Let’s not introduce one.
Renaming ksh93 from ksh to ksh93 would also make backporting
much harder. KISS.

bye,
//mirabilos
-- 
I believe no one can invent an algorithm. One just happens to hit upon it
when God enlightens him. Or only God invents algorithms, we merely copy them.
If you don't believe in God, just consider God as Nature if you won't deny
existence.  -- Coywolf Qi Hunt

Bug#803272: libreoffice-dev: apt-get dist-upgrade -u -f *HANGS* on libreoffice-dev 3a5.0.3~rc1-2

[Rene Engelhard]

notfound 803272 1:5.0.2-1
found 803272 1:5.0.3~rc1-2
severity 803272 important
tag 803272 + confirmed
retitle 803272 upgrade to 1:5.0.3~rc1-2 from previous versions slow with 
-dev-doc installed
thanks
 
Hi,

On Wed, Oct 28, 2015 at 03:10:36PM +0100, Emmanuel Charpentier wrote:
> Package: libreoffice-dev
> Version: 1:5.0.2-1

Wrong. See below. Use care when using this as this is represented in the
bug graph.

> Severity: critical
> Justification: breaks unrelated software

I don't think this is critical. I don't even think this is a bug at all.
See below.

Don't overinflate bugs. And a bit of more research should be possible if
you use testing.

> 3143 pts/0Ss 0:00  \_ bash
>  3149 pts/0S  0:00  |   \_ sudo -i
>  3178 pts/0S  0:00  |   \_ -bash
> 19191 pts/0S+ 0:09  |   \_ apt-get dist-upgrade -u -f
> 20570 pts/1Ss+0:00  |   \_ /usr/bin/dpkg --status-fd 107
> --unpack --auto-deconfigure /var/cache/apt/archives/libreoffice-
> dev_1%3a5.0.3~rc1

Aha. So it was a upgrade to 1:5.0.3~rc1 (then it got stripped, but I assume
-2, as that migrated to testing shortly ago - I think yesterday). So you
specified Version: wrong.

> 20616 pts/1S+ 0:00  |   \_ /bin/sh
> /var/lib/dpkg/tmp.ci/preinst upgrade 1:5.0.2-1
> 20617 pts/1S+ 0:00  |   \_ /bin/sh /usr/bin/dpkg-
> maintscript-helper dir_to_symlink /usr/share/doc/libreoffice-dev
> /usr/share/doc/l
> 20625 pts/1S+ 0:00  |   \_ find /usr/share/doc
> /libreoffice-dev -print0
> 20626 pts/1S+ 0:00  |   \_ xargs -0 -n1 sh -c
> ??package="$1" ??file="$2" ??if ! dpkg-query -L "$package" | grep -q -x 
> "$file"

That tree is big (especially if you have -dev-doc installed) and the find may
take some time. And that saifd, I don't have any influence on that find given
it's dpkg-maintscript-helper (from dpkg!) doing it's job to convert a dir
to a symlink. Which is needed in this upgrade and even if I reverted the
doc linking needing this I still need to do this for intermediate versions
in sid..

If you looked whether the process(es) do something you would have seen that
the find does it's job...
Even installing -dev-doc takes a long time due to its sheer count of files.

This is from stable:
root@Cubie:/usr/share/doc/libreoffice-dev# du -hs && find . -print | wc -l
396M.
22200

A upgrade from clean stable chroot + libreoffice + libreoffice-dev 
+ libreoffice-dev-doc to sid works fine here, but yes, takes a while
(this is even a armhf and a micro-SD card, so even more slow...)

# time apt-get dist-upgrade
[...]
Preparing to unpack .../libreoffice-dev_1%3a5.0.3~rc1-2_armhf.deb ...



Yeah, this defnitely is unfortunate and unexpected, but it's not a hang, dpkg
does its job.

> Versions of packages libreoffice-dev suggests:
> ii  libmythes-dev2:1.2.4-1
> ii  libreoffice-dev-doc  1:5.0.2-1

OK, now we at least now you *do* have a big tree under 
/usr/share/doc/libreoffice-dev/docs.
As I thought.

Regards,

Rene

Bug#803178: libmongodb-perl: FTBFS on various architectures

[gregor herrmann]

On Wed, 28 Oct 2015 00:01:24 +0100, gregor herrmann wrote:

> > I only had a chance to skim the output, but that was my assessment as
> > well.  I have no problem applying that patch, but a test to verify would be
> > appreciated (and would save us another round of automated failures).
> 
> You can follow the output of the buildds with Niko's patch applied at
> https://buildd.debian.org/status/package.php?p=libmongodb-perl

This looks all good, seems like Niko's patch was spot-on.
 
> and the patches are at
> https://anonscm.debian.org/cgit/pkg-perl/packages/libmongodb-perl.git
> https://anonscm.debian.org/cgit/pkg-perl/packages/libmongodb-perl.git/tree/debian/patches

Feel free to grab the patch(es) are your convenience.


Cheers,
gregor


-- 
 .''`.  Homepage: http://info.comodo.priv.at/ - OpenPGP key 0xBB3A68018649AA06
 : :' : Debian GNU/Linux user, admin, and developer -  https://www.debian.org/
 `. `'  Member of VIBE!AT & SPI, fellow of the Free Software Foundation Europe
   `-   NP: Beach Boys: Do You Wanna Dance


signature.asc
Description: Digital Signature

Bug#803301: otrs2: Should depends on libschedule-cron-events-perl

[Olivier Tétard]

Source: otrs2
Version: 5.0.1-1
Severity: normal

Hi,

OTRS5 requires Schedule::Cron::Events to be installed. If not, the
following error is raised by otrs.Daemon.pl, which prevent scheduled
tasks from being executed:

,
| otrs.Daemon.pl: Kernel::System::CronEvent could not be loaded: Can't locate 
Schedule/Cron/Events.pm in @INC (you may need to install the 
Schedule::Cron::Events module) (@INC contains: /usr/share/otrs/Custom 
/usr/share/otrs/Kernel/cpan-lib /usr/share/otrs /usr/share/otrs2 /etc/perl 
/usr/local/lib/x86_64-linux-gnu/perl/5.20.2 /usr/local/share/perl/5.20.2 
/usr/lib/x86_64-linux-gnu/perl5/5.20 /usr/share/perl5 
/usr/lib/x86_64-linux-gnu/perl/5.20 /usr/share/perl/5.20 
/usr/local/lib/site_perl .) at /usr/share/otrs/Kernel/System/CronEvent.pm line 
14.
| otrs.Daemon.pl: BEGIN failed--compilation aborted at 
/usr/share/otrs/Kernel/System/CronEvent.pm line 14.
| otrs.Daemon.pl: Compilation failed in require at 
/usr/share/otrs/Kernel/System/ObjectManager.pm line 191.
| otrs.Daemon.pl:  at /usr/share/otrs/Kernel/System/Daemon/SchedulerDB.pm line 
1600.
`

Unfortunately, the libschedule-cron-events-perl package is not available
in Debian.

Olivier;

Bug#803303: general: Standardized troubleshooting

[Stefan Monnier]

Package: general
Severity: wishlist

Dear Maintainer,

I've been using Debian on all my machines for many years and am generally very
happy with it but I recently realized that my experience could have been even
better (both for me and for the maintainers of all the packages I use) if it
were easier to figure out how to troubleshoot problems.

Concrete suggestion: add a "TROUBLESHOOTING" section in the manpage of every
program, explaining how to get more info about what's going on when the program
doesn't do what the user wants.

I've often gone through steps like:
1- Program Foo crashes/hangs/misbehaves/younameit when I do something.
2- Search the web to see if someone else bumped into the same problem and found
a fix for it.
3- No luck, so I report the bug to Debian or to the upstream.
4- Someone gets back to me telling me to set env-var FOO_DEBUG=99 then re-run
the program and show her what is reported in file .foo_debug_log.

My suggestion is to try and skip step 3 and 4, replacing them with "man foo;
then look for the TROUBLESHOOTING section".  Usually this troubleshooting info
can be found somewhere, but every program puts it at a different place, making
it difficult to find.

Furthermore, the troubleshooting info needed may go further than the program
itself, e.g. when the program is not started from the command line but via some
other mechanism (inetd, systemd, gnome-shell, ...).

In the longer run, it would be even better to try and standardize not just the
place where the troubleshooting info is located, but the way troubleshooting is
done (e.g. always provide a "--troubleshoot" command-line flag which always
gives the output at "the same place"), so that I could for example do
"systemctl troubleshoot gdm3" and systemd would know how to start gdm3 in order
to get debugging info.

But a good first step seems to be to start collecting the troubleshooting info
at a standardized place (e.g. the manpage).
Of course if you prefer putting that info in
/usr/share/doc//TROUBLESHOOTING, that's fine as well.  As long as it's
always the same place.



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

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

Bug#803302: iceweasel: hangs with grey window after openjdk upgrade

[Karl O. Pinc]

Package: iceweasel
Version: 38.3.0esr-1~deb8u1
Severity: important

Hi,

Upon start, iceweasel opens window, which is left with a title
but with grey content, and then seems to hang.  Closing the
window produces a dialog from my window manager telling
me the app is not responding and asking if it should be
killed.  Answering yes makes the window go away but leaves
iceweasel running, which must be killed from the command line.

Same thing using -safe-mode, only the opened window is
dialog sized.

Moving .mozilla/firefox somewhere else does not change things.

MOZILLA_DISABLE_PLUGINS=1 iceweasel -safe-mode
does not change things either.

Running gdb gets me the output at bottom, which does not
have a stack trace (probably because the process is killed).

The only thing I can think of is that since the last
restart I have updated to:
 libsctp1_1.0.16+dfsg-2_amd64.deb
 openjdk-7-jre_7u85-2.6.1-5~deb8u1_amd64.deb
 icedtea-7-jre-jamvm_7u85-2.6.1-5~deb8u1_amd64.deb
 openjdk-7-jre-headless_7u85-2.6.1-5~deb8u1_amd64.deb
 lksctp-tools_1.0.16+dfsg-2_amd64.deb
(From the debian security repos.)

FWIW, I normally keep the icetea plugin disabled.

The only other thing of note is that I'm running
my desktop on a (slow) X server.



(gdb) set pagination off
(gdb) run
Starting program: /usr/bin/iceweasel -safe-mode
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
[New Thread 0x7fffe9010700 (LWP 4582)]
[Thread 0x7fffe9010700 (LWP 4582) exited]

(process:4576): GLib-CRITICAL **: g_slice_set_config: assertion 'sys_page_size 
== 0' failed
[New Thread 0x7fffe9010700 (LWP 4584)]
[New Thread 0x7fffe13ff700 (LWP 4585)]
[New Thread 0x7fffe0bfe700 (LWP 4586)]
[New Thread 0x76def700 (LWP 4587)]
[New Thread 0x7fffe03fd700 (LWP 4588)]
[New Thread 0x7fffdfff3700 (LWP 4589)]
[New Thread 0x7fffdff72700 (LWP 4590)]
[New Thread 0x7fffdfef1700 (LWP 4591)]
[New Thread 0x7fffdfe70700 (LWP 4592)]
[New Thread 0x7fffdfdef700 (LWP 4593)]
[New Thread 0x7fffdfd6e700 (LWP 4594)]
[New Thread 0x7fffdebff700 (LWP 4595)]
[New Thread 0x7fffde0ff700 (LWP 4596)]
[New Thread 0x7fffdd8fe700 (LWP 4597)]
[New Thread 0x7fffdc9ff700 (LWP 4600)]
[New Thread 0x7fffe152c700 (LWP 4601)]
[New Thread 0x7fffdbcff700 (LWP 4602)]
[New Thread 0x7fffdb4fe700 (LWP 4603)]
[New Thread 0x7fffd9dc5700 (LWP 4604)]
[New Thread 0x7fffd8dff700 (LWP 4605)]
[New Thread 0x7fffd85fe700 (LWP 4606)]
[New Thread 0x7fffd7dfd700 (LWP 4607)]
[New Thread 0x7fffd7bfc700 (LWP 4608)]
[New Thread 0x7fffd6fff700 (LWP 4609)]
[New Thread 0x7fffd65ff700 (LWP 4610)]
[New Thread 0x7fffd5dfe700 (LWP 4611)]
[Thread 0x7fffdfd6e700 (LWP 4594) exited]
[Thread 0x7fffe9010700 (LWP 4584) exited]
[Thread 0x77fd9740 (LWP 4576) exited]
[Thread 0x7fffd8dff700 (LWP 4605) exited]
[Thread 0x7fffd6fff700 (LWP 4609) exited]
[Thread 0x7fffd5dfe700 (LWP 4611) exited]
[Thread 0x7fffd65ff700 (LWP 4610) exited]
[Thread 0x7fffd7bfc700 (LWP 4608) exited]
[Thread 0x7fffd7dfd700 (LWP 4607) exited]
[Thread 0x7fffd85fe700 (LWP 4606) exited]
[Thread 0x7fffd9dc5700 (LWP 4604) exited]
[Thread 0x7fffdb4fe700 (LWP 4603) exited]
[Thread 0x7fffdbcff700 (LWP 4602) exited]
[Thread 0x7fffe152c700 (LWP 4601) exited]
[Thread 0x7fffdc9ff700 (LWP 4600) exited]
[Thread 0x7fffdd8fe700 (LWP 4597) exited]
[Thread 0x7fffde0ff700 (LWP 4596) exited]
[Thread 0x7fffdfdef700 (LWP 4593) exited]
[Thread 0x7fffdfe70700 (LWP 4592) exited]
[Thread 0x7fffdfef1700 (LWP 4591) exited]
[Thread 0x7fffdff72700 (LWP 4590) exited]
[Thread 0x7fffdfff3700 (LWP 4589) exited]
[Thread 0x7fffe03fd700 (LWP 4588) exited]
[Thread 0x76def700 (LWP 4587) exited]
[Thread 0x7fffe0bfe700 (LWP 4586) exited]
[Thread 0x7fffe13ff700 (LWP 4585) exited]

Program terminated with signal SIGKILL, Killed.
The program no longer exists.
(gdb) bt full
No stack.


-- Package-specific info:


-- Addons package information

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

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 iceweasel depends on:
ii  debianutils   4.4+b1
ii  fontconfig2.11.0-6.3
ii  libasound21.0.28-1
ii  libatk1.0-0   2.14.0-1
ii  libc6 2.19-18+deb8u1
ii  libcairo2 1.14.0-2.1
ii  libdbus-1-3   1.8.20-0+deb8u1
ii  libdbus-glib-1-2  0.102-1
ii  libevent-2.0-52.0.21-stable-2
ii  libffi6   3.1-2+b2
ii  libfontconfig12.11.0-6.3
ii  libfreetype6  2.5.2-3+deb8u1
ii  libgcc1   1:4.9.2-10
ii  libgdk-pixbuf2.0-02.31.1-2+deb8u3
ii  libglib2.0-0  2.42.1-1
ii  libgtk2.0-0   2.24.25-3
ii  libhunspell-1.3-0 1.3.3-3
ii  libpango-1.0-01.36.8-3
ii  libsqlite3-0   

Bug#803124: debian.org XMPP pending tasks (updated)

[Daniel Pocock]

Hi all,

I'm just wondering if anybody from the XMPP packaging group may want to
take ownership of this bug[1] and bring it to the stage where the
service can be announced or even just help to chip away at any one of
the tasks on the list.

There are a few things to do but as far as I am aware they are mostly
routine tasks, no new development work required:

- add yourself to the debian-rtc-admin group[2] and mailing list[3]

- submit an RT request[4] to DSA to add you to the debvoip UNIX group
and assist DSA with the outstanding actions on their list (see below)

- decide on most recommended XMPP client for desktop users and for the
most common mobile platform(s) (Android) and add some brief notes about
them or screenshots to the wiki[5].  Ralph offered to provide some
feedback on this topic too, the XMPP mailing list[6] may also be a good
place to seek ideas for this.  I've recently been trying the
Conversations app on Android.

- send an announcement to the debian-devel-announce list[7] (must be PGP
signed) and the official Debian newsletter and blog (contact publicity
team[8]).  The announcement should probably repeat some of the links
about the support team[9]

I feel the mini-DebConf in Cambridge[10] would be a great place to
launch this service but I understand it may take longer.  I will be at
the mini-DebConf myself (at least on 7 November) and would be happy to
meet with anybody who wants to discuss or collaborate on any of this in
person.

Many things have already been done for XMPP, e.g. we have the TURN
server running, a custom authentication module, the users can create
LDAP accounts, Prosody itself is installed and running, certificates,
DNS and firewall changes were already made, Luca in particular has put a
great effort into getting the project to this stage.

Even if you can only help with one of the things on this list and give
feedback to this bug that would be perfectly welcome.

Regards,

Daniel


--- DSA tasks ---

1. backup (bacula) for buddy lists in /var/lib/prosody

2. installing the prosody-modules package from jessie-backports and
verify that /usr/lib/prosody/modules/mod_auth_ha1.lua is working
(the version of mod_auth_ha1.lua that we developed and tested at
DebConf15 is in ~pocock/prosody-mod/mod_auth_ha1.lua)

3. ensuring the text file with password hashes from LDAP is
automatically updated when something changes in LDAP and then a HUP
signal is sent to Prosody.  This is very similar to what has already
been scripted to provide the password hashes to the TURN server, reTurn.

4. set up monitoring of the TCP ports, maybe use:
https://packages.debian.org/jessie-backports/nagios-check-xmppng




1. https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=803124
2. https://alioth.debian.org/project/request.php?group_id=100991
3. https://lists.alioth.debian.org/mailman/listinfo/debian-rtc-admin
4. https://wiki.debian.org/Teams/DSA/RTUsage#How_to_submit_a_ticket
5. http://wiki.debian.org/UnifiedCommunications/DebianDevelopers/UserGuide
6. http://mail.jabber.org/mailman/listinfo/juser
7. https://lists.debian.org/debian-devel-announce/
8. https://lists.debian.org/debian-publicity/
9. https://lists.debian.org/debian-project/2015/10/msg00032.html
10. https://wiki.debian.org/DebianEvents/gb/2015/MiniDebConfCambridge

Bug#764401: clarity please

[Nicholas Bamber]

On 28/10/15 15:19, Thorsten Glaser wrote:

Nicholas Bamber dixit:


Please could Thorsten and Dominik please work out who will be responsible for
mksh in Debian? Can you work together if that makes sense? I can sign and
upload  if necessary.


OK, we had a short talk on the office floor about this ;-) and
I’ll be putting myself back into the Maintainer field and take
formal responsibility for this as external contributor.


2.) ksh93 and mksh are alternative implementations of ksh (with subtle
differences that should be documented). In this case both can coexist on Debian
but one (potentially either but by default ksh93) should assume the role of
ksh.


This is what is currently true, and the desired outcome:

• scripts specific to ksh93 use ksh93 in the shebang
• scripts specific to mksh use mksh in the shebang
• scripts using ksh in the shebang can be…
   – old pdksh scripts,
   – old ksh88 scripts,
   – or scripts written for “any ksh subset” – I did a short
 UDD search just now, and all cases of this in Debian
 also accept zsh as ksh providing package.

This means that, if only one of ksh93 or mksh is installed,
that package takes over ksh, but if both are installed, the
official Korn Shell should take over ksh (unless the local
admin overrides, of course).

All use cases in Debian use alternative package relationships,
i.e. don’t force the installation of one specific variant but
don’t use a virtual package either. Let’s not introduce one.
Renaming ksh93 from ksh to ksh93 would also make backporting
much harder. KISS.

bye,
//mirabilos



Okay we can separate the virtual ksh package question from more 
fundamental issues. Namely:


1.) If ksh is installed then ksh should be in /etc/shells. (#790118)

2.) If ksh is not installed but mksh is and ksh links to mksh via 
alternatives, then the ksh man page must also link to the mksh man page, 
and ksh should be in /etc/shells.


But then the original questions come back.

3.) mksh IS in this situation being confused for ksh.

4.) So you would still need disclaimers in the mksh documentation that 
mksh IS NOT ksh.


5.) mksh would effectively be Providing ksh, but that this would not be 
declared.


Other questions:
1. As I said I can upload for you.

2. In coming back to Debian are you offering to work with Dominik or 
trying to wrest the WNPP bug from his hands? Since the package is 
currently owned by the Debian QA group I am not sure if you can do that.