Bug#810672: firmware-free should include the ath9k_htc firmware binaries

[Paul Fertser]

Package: firmware-free
Version: 3.4
Severity: wishlist

Hello,

According to the upstream commit[1] ath9k_htc version 1.4.0 is free
software (and the future versions will be free software as well,
obviously).

Please add it to this package (and remove from firmware-atheros).

There's one important thing to consider though: location of the
firmware files.

If you add the binaries just as they're located in linux-firmware they
will be seen and used only by the kernel versions that include [2]. If
you copy them to the old place then the older kernels will work with
1.4.0 too (it's backwards-compatible to 1.3.0). Please see [2] for
more rationale and details regarding this.

The maintainer of the open ath9k_htc firmware is in Cc.

[1] 
https://git.kernel.org/cgit/linux/kernel/git/firmware/linux-firmware.git/commit/?id=3f3aa3a12d5e5d34bda87a691cf7176baef95bf3
[2] 
https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=e904cf6fe23022cde4e0ea9d41601411a315a3dc

Bug#498067: dh_install wildcard exception mechanism request

[Gergely Nagy]

Hi!

This wishlist was recently brought to my attention, as something that
could be added via dh-exec. I have a couple of ideas for the syntax:

1) usr/bin/djview3 => usr/bin/djview3

This is the existing syntax for dh-exec-install-rename, which does a
copy behind the scenes. For this feature, it would need to do a rename.
I do not want to break existing functionality, so if I go with this
syntax, we will need a flag to tell dh-exec to do a move instead of
copy.

Something like -Oinstall-rename=move or --move-files. Or, following
existing syntax: --with-scripts=install-movefiles. I am leaning towards
this last one.

2) => usr/bin/djview3

Kind of like the rename syntax, but only with the second part of it.
This is shorter, and does not need additional flags on the #! line. But
it does not allow renaming with a move. I suppose that is not
particularly important, seeing that I know of no such request.

3) A combination of both.

By default, install-movefiles would come after install-rename, thus the
latter would rewrite the src => dest form before install-move gets
there. With a --with-scripts argument, movefiles would win the race
instead.

Having dumped this here, I will go with the third option. Thank you for
listening.

-- 
|8]

Bug#634073: Svn launches kwallet

[Brainslug]

It's two years later now, but subversion 1.9.2 on Debian/stretch still
launches stupid kwallet.

+1 on setting "password-stores=" to an empty string by default.


Cheers!

Bug#810670: Acknowledgement (mlocate: Using grub-mount dir (/var/lib/os-prober/mount) blocks execution of update-grub)

[Andrey Nikitin]

I think that to solve this problem will be enough
to append "fuse.grub-mount"
to PRUNEFS variable (/etc/updatedb.conf).

Bug#700045: linphone: account wizard rejects user names starting with a digit (required by sipgate)

[Michael Stapelberg]

Hi Helmut,

Helmut Grohne  writes:
> Start linphone. Click "Options", select "Preferences". Select tab
> "Manage SIP Accounts". Click the "Wizard" button. Click "Forward".
> Select "I have already a sip account ...". Click "Forward". Enter
> arbitray 6 digits into the username field. Enter an arbitrary non-empty
> character sequence into the password field. Enter a valid domain (such
> as "sipgate.com") into the domain field.
>
> Expected behaviour: The "Apply" button would be clickable.
> Observed behaviour: The "Apply" button is not clickable.
>
> Further details. The acceptance of the input data seems to depend on the
> value in the username field to start with a letter. This precludes
> sipgate users from using linphone.

I also ran into this bug.

A workaround is to prefix your sipgate username (e.g. 1234) with a
letter (e.g. a1234). Login will fail, but linphone will allow you to add
the account. Afterwards, choose Options → Preferences → Manage SIP
Accounts, select the account in question, click the Edit button, remove
the letter.

Upstream says this was fixed in 3.7.0:
https://lists.gnu.org/archive/html/linphone-users/2015-01/msg5.html

-- 
Best regards,
Michael

Bug#810673: proposed RM: mountall -- RoQA; only used by upstart which was removed

[Ansgar Burchardt]

Package: mountall
Version: 2.54
Severity: serious
Tags: sid

upstart was removed from Debian and Michael Biebl pointed out that the
"mountall" tool was only packaged for use with it.  So it should
probably be removed as well.

Besides upstart, apt-cache rdepends shows only cgroupfs-mount, but the
current version only suggests mountall.

If there are no objections, I'll reassign the removal request to ftp.d.o
later.

Ansgar

Bug#806844: unattended-upgrades: needs to be rebuilt with fixed debhelper

[Andreas Beckmann]

Followup-For: Bug #806844
Control: tag -1 pending

no-change rebuild NMU uploaded to DELAYED/2


Andreas

Bug#810663: Include Device Tree model in reportbug script

[Uwe Kleine-König]

Hello,

On Sun, Jan 10, 2016 at 09:23:40PM -0800, Martin Michlmayr wrote:
> Please note that the strange "echo ... $(cat ..)" construct is
> intentional.  'cat /proc/device-tree/model' leads to a strange
> character at the end because there's no newline and using echo
> gets rid of it.

Maybe put this info also (or instead) in a source comment?

> diff --git a/debian/templates/image.plain.bug/include-model 
> b/debian/templates/image.plain.bug/include-model
> index 60a7112..9c6aedd 100644
> --- a/debian/templates/image.plain.bug/include-model
> +++ b/debian/templates/image.plain.bug/include-model
> @@ -39,6 +39,11 @@ grep_model() {
>  false
>  ;;
>esac
> +
> +  # Device Tree model
> +  if [ -r /proc/device-tree/model ]; then
> +echo "Device Tree model:" $(cat /proc/device-tree/model)

In recent kernels[1] /proc/device-tree is a symlink to
/sys/firmware/devicetree/base. I expect that it stays there for quite a
while, but I wonder if it would be cleaner to use /sys/firmware...
directly. Hmm, probably not, because using proc also covers
2.6.36..3.15.

Best regards
Uwe

[1] since 75b57ecf9d1d ("of: Make device nodes kobjects so they show up
in sysfs") which appeared in 3.15. 

-- 
Pengutronix e.K.   | Uwe Kleine-König|
Industrial Linux Solutions | http://www.pengutronix.de/  |

Bug#810676: python-keyring: Unable to autolaunch a dbus-daemon without a $DISPLAY for X11

[Neil Williams]

Package: python-keyring
Version: 6.1-1
Severity: grave
Justification: renders package unusable

Processes using python-keyring 6.1 can no longer run as a daemon - a regression
from previous support, causing lava-server to halt all daemon operations.

dbus.exceptions.DBusException: org.freedesktop.DBus.Error.NotSupported: Unable 
to autolaunch a dbus-daemon without a $DISPLAY for X11

Traceback (most recent call last):
  File "/usr/bin/lava-server", line 9, in 
load_entry_point('lava-server==2015.12+5459.74d110f', 'console_scripts', 
'lava-server')()
  File "/usr/lib/python2.7/dist-packages/lava_server/manage.py", line 125, in 
main
run_with_dispatcher_class(LAVAServerDispatcher)
  File "/usr/lib/python2.7/dist-packages/lava_tool/dispatcher.py", line 45, in 
run_with_dispatcher_class
raise cls.run()
  File "/usr/lib/python2.7/dist-packages/lava/tool/dispatcher.py", line 153, in 
run
raise SystemExit(cls().dispatch(args))
  File "/usr/lib/python2.7/dist-packages/lava/tool/dispatcher.py", line 143, in 
dispatch
return command.invoke()
  File "/usr/lib/python2.7/dist-packages/lava_server/manage.py", line 114, in 
invoke
execute_from_command_line(['lava-server'] + self.args.command)
  File "/usr/lib/python2.7/dist-packages/django/core/management/__init__.py", 
line 353, in execute_from_command_line
utility.execute()
  File "/usr/lib/python2.7/dist-packages/django/core/management/__init__.py", 
line 345, in execute
self.fetch_command(subcommand).run_from_argv(self.argv)
  File "/usr/lib/python2.7/dist-packages/django/core/management/base.py", line 
348, in run_from_argv
self.execute(*args, **cmd_options)
  File "/usr/lib/python2.7/dist-packages/django/core/management/base.py", line 
399, in execute
output = self.handle(*args, **options)
  File 
"/usr/lib/python2.7/dist-packages/lava_scheduler_app/management/commands/scheduler.py",
 line 46, in handle
from lava_scheduler_daemon.service import JobQueue
  File "/usr/lib/python2.7/dist-packages/lava_scheduler_daemon/service.py", 
line 28, in 
from lava_scheduler_daemon.worker import WorkerData
  File "/usr/lib/python2.7/dist-packages/lava_scheduler_daemon/worker.py", line 
31, in 
from lava_tool.authtoken import AuthenticatingServerProxy, MemoryAuthBackend
  File "/usr/lib/python2.7/dist-packages/lava_tool/authtoken.py", line 25, in 

import keyring.core
  File "/usr/lib/python2.7/dist-packages/keyring/__init__.py", line 12, in 

from .core import (set_keyring, get_keyring, set_password, get_password,
  File "/usr/lib/python2.7/dist-packages/keyring/core.py", line 158, in 
init_backend()
  File "/usr/lib/python2.7/dist-packages/keyring/core.py", line 58, in 
init_backend
set_keyring(load_config() or _get_best_keyring())
  File "/usr/lib/python2.7/dist-packages/keyring/core.py", line 66, in 
_get_best_keyring
keyrings = backend.get_all_keyring()
  File "/usr/lib/python2.7/dist-packages/keyring/util/__init__.py", line 20, in 
wrapper
func.always_returns = func(*args, **kwargs)
  File "/usr/lib/python2.7/dist-packages/keyring/backend.py", line 180, in 
get_all_keyring
exceptions=TypeError))
  File "/usr/lib/python2.7/dist-packages/keyring/util/__init__.py", line 29, in 
suppress_exceptions
for callable in callables:
  File "/usr/lib/python2.7/dist-packages/keyring/backend.py", line 172, in 
is_class_viable
keyring_cls.priority
  File "/usr/lib/python2.7/dist-packages/keyring/util/properties.py", line 22, 
in __get__
return self.fget.__get__(None, owner)()
  File "/usr/lib/python2.7/dist-packages/keyring/util/XDG.py", line 18, in 
wrapper
return func(*args, **kwargs) * self.multiplier
  File "/usr/lib/python2.7/dist-packages/keyring/backends/kwallet.py", line 
134, in priority
bus = dbus.SessionBus()
  File "/usr/lib/python2.7/dist-packages/dbus/_dbus.py", line 211, in __new__
mainloop=mainloop)
  File "/usr/lib/python2.7/dist-packages/dbus/_dbus.py", line 100, in __new__
bus = BusConnection.__new__(subclass, bus_type, mainloop=mainloop)
  File "/usr/lib/python2.7/dist-packages/dbus/bus.py", line 122, in __new__
bus = cls._new_for_bus(address_or_type, mainloop=mainloop)
dbus.exceptions.DBusException: org.freedesktop.DBus.Error.NotSupported: Unable 
to autolaunch a dbus-daemon without a $DISPLAY for X11

python-keyring must NOT require X11 to operate.

Downgrading to 5.7.1-1 in testing fixes the problem.

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

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

Bug#810674: ITP: golang-github-kolo-xmlrpc -- Implementation of the XMLRPC client protocol in Go

[Martín Ferrari]

Package: wnpp
Severity: wishlist
Owner: "Martín Ferrari" 

* Package name: golang-github-kolo-xmlrpc
  Version : 0+git20150413.0826b98
  Upstream Author : Dmitry Maksimov 
* URL : https://github.com/kolo/xmlrpc
* License : MIT
  Programming Lang: Go
  Description : Implementation of the XMLRPC client protocol in Go

 The github.com/kolo/xmlrpc package is an implementation of client side part of
 XMLRPC protocol in the Go language.

Bug#810675: New Upstream Version - v0.7.06

[Michael D]

Package: duplicity
Version: 0.7.05-2

Upstream version v0.7.06 was released 2015/12/07 - would be great to please
get an update for it. Would also resolve #799237 and maybe others.

Thanks

Bug#810655: libembperl-perl: post-installation script returned error

[Dominic Hargreaves]

On Mon, Jan 11, 2016 at 02:32:36AM +0100, Rosario Maddox wrote:
> Package: libembperl-perl
> Version: 2.5.0-4
> Severity: grave
> Justification: renders package unusable
> 
> Dear Maintainer,
> 
>* What led up to the situation?
> 
> Tried to install it:
> 
> Reading package lists... Done
> Building dependency tree   
> Reading state information... Done
> libembperl-perl is already the newest version.
> 0 upgraded, 0 newly installed, 0 to remove and 7 not upgraded.
> 1 not fully installed or removed.
> After this operation, 0 B of additional disk space will be used.
> Do you want to continue? [Y/n] 
> Setting up libembperl-perl (2.5.0-4) ...
> dpkg: error processing package libembperl-perl (--configure):
>  subprocess installed post-installation script returned error exit status 1
> Errors were encountered while processing:
>  libembperl-perl
> E: Sub-process /usr/bin/dpkg returned an error code (1)
> 
> This should not happen.

Could you try editing /var/lib/dpkg/info/libembperl-perl.postinst to
add ' -x' to the first shebang line, and then rerun this configuration
(dpkg --configure -a)? This should give a bit more information about
where it's failing.

Thanks,
Dominic.

Bug#810677: nmu: tarantool_1.6.7.551.ga5bafc5-1

[Andreas Beckmann]

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

nmu tarantool_1.6.7.551.ga5bafc5-1 . ANY . unstable . -m "Rebuild against 
binutils 2.25.90.20160101"

Isn't there a way to automate these binNMUs on new binutils snapshots?


Andreas

Bug#790762: src:hplip: Many PPD files for postscript drivers are missing in printer-driver-postscript-hp

[John Paul Adrian Glaubitz]

Hi!

On 07/01/2015 05:22 PM, John Paul Adrian Glaubitz wrote:
> While setting up a new print server on the network, we noticed that the binary
> package printer-driver-postscript-hp is missing the PPDs for many postscript
> printers actually supported by hplip.

Just saw that hplip was finally updated again in Debian. Looking at the
package in question, the problem is still prevalent:

glaubitz@z6:/tmp> wget
ftp://ftp.debian.org/debian/pool/main/h/hplip/printer-driver-postscript-hp_3.15.11+repack0-1_all.deb
--2016-01-11 09:53:15--
ftp://ftp.debian.org/debian/pool/main/h/hplip/printer-driver-postscript-hp_3.15.11+repack0-1_all.deb
   => ‘printer-driver-postscript-hp_3.15.11+repack0-1_all.deb’
Resolving ftp.debian.org (ftp.debian.org)... 130.89.148.12,
2001:610:1908:b000::148:12
Connecting to ftp.debian.org (ftp.debian.org)|130.89.148.12|:21...
connected.
Logging in as anonymous ... Logged in!
==> SYST ... done.==> PWD ... done.
==> TYPE I ... done.  ==> CWD (1) /debian/pool/main/h/hplip ... done.
==> SIZE printer-driver-postscript-hp_3.15.11+repack0-1_all.deb ... 843884
==> PASV ... done.==> RETR
printer-driver-postscript-hp_3.15.11+repack0-1_all.deb ... done.
Length: 843884 (824K) (unauthoritative)

printer-driver-postscript-hp_3.15.
100%[>]
824.11K  --.-KB/sin 0.1s

2016-01-11 09:53:16 (6.42 MB/s) -
‘printer-driver-postscript-hp_3.15.11+repack0-1_all.deb’ saved [843884]

glaubitz@z6:/tmp> dpkg-deb -c
printer-driver-postscript-hp_3.15.11+repack0-1_all.deb
drwxr-xr-x root/root 0 2016-01-10 02:00 ./
drwxr-xr-x root/root 0 2016-01-10 02:00 ./usr/
drwxr-xr-x root/root 0 2016-01-10 02:00 ./usr/lib/
drwxr-xr-x root/root 0 2016-01-10 02:00 ./usr/lib/cups/
drwxr-xr-x root/root 0 2016-01-10 02:00 ./usr/lib/cups/driver/
-rwxr-xr-x root/root998446 2016-01-10 02:00
./usr/lib/cups/driver/postscript-hp
drwxr-xr-x root/root 0 2016-01-10 02:00 ./usr/share/
drwxr-xr-x root/root 0 2016-01-10 02:00 ./usr/share/doc/
drwxr-xr-x root/root 0 2016-01-10 02:00
./usr/share/doc/printer-driver-postscript-hp/
-rw-r--r-- root/root 75864 2016-01-09 22:42
./usr/share/doc/printer-driver-postscript-hp/changelog.Debian.gz
-rw-r--r-- root/root  4830 2016-01-09 22:42
./usr/share/doc/printer-driver-postscript-hp/copyright
drwxr-xr-x root/root 0 2016-01-10 02:00 ./usr/share/cups/
drwxr-xr-x root/root 0 2016-01-10 02:00
./usr/share/cups/ppd-updaters/
-rw-r--r-- root/root   110 2016-01-10 02:00
./usr/share/cups/ppd-updaters/printer-driver-postscript-hp.ppd-updater
glaubitz@z6:/tmp>

The PPD files are not to be found in the PPD package either:

glaubitz@z6:/tmp> wget
ftp://ftp.debian.org/debian/pool/main/h/hplip/hpijs-ppds_3.15.11+repack0-1_all.deb
--2016-01-11 09:57:14--
ftp://ftp.debian.org/debian/pool/main/h/hplip/hpijs-ppds_3.15.11+repack0-1_all.deb
   => ‘hpijs-ppds_3.15.11+repack0-1_all.deb’
Resolving ftp.debian.org (ftp.debian.org)... 130.89.148.12,
2001:610:1908:b000::148:12
Connecting to ftp.debian.org (ftp.debian.org)|130.89.148.12|:21...
connected.
Logging in as anonymous ... Logged in!
==> SYST ... done.==> PWD ... done.
==> TYPE I ... done.  ==> CWD (1) /debian/pool/main/h/hplip ... done.
==> SIZE hpijs-ppds_3.15.11+repack0-1_all.deb ... 160598
==> PASV ... done.==> RETR hpijs-ppds_3.15.11+repack0-1_all.deb ...
done.
Length: 160598 (157K) (unauthoritative)

hpijs-ppds_3.15.11+repack0-1_all.d
100%[>]
156.83K  --.-KB/sin 0.07s

2016-01-11 09:57:15 (2.09 MB/s) - ‘hpijs-ppds_3.15.11+repack0-1_all.deb’
saved [160598]

glaubitz@z6:/tmp> dpkg-deb -c hpijs-ppds_3.15.11+repack0-1_all.deb |grep
postscript
glaubitz@z6:/tmp>

Could you please add the missing postscript PPDs.

Thanks,
Adrian

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

Bug#810678: dia2code segfaults

[Ophir LOJKINE]

Package: dia2code

Hello,
  I've recently started to use dia2code. Apparently, the code is very old and 
is not maintained anymore.
  I've found the program to segfaults on several cases, and have corrected 
these.
  I've also added the ability to import database diagrams (useful for the SQL 
export).
  There are several different patches for the different problems.
  I've forked the code on github, and you can see the commits here:
https://github.com/lovasoa/dia2code/commits/master

Thanks,
lovasoa

Bug#810679: [PATCH] IPv6 broken due with exosip 4

[Michael Stapelberg]

Package: linphone
Version: 3.6.1-2.4
Severity: normal
Tags: ipv6 patch

exosip 4 deprecated eXosip_enable_ipv6() in such a way that it fails
silently: https://sources.debian.net/src/libexosip2/4.1.0-2/src/eXconf.c/#L55

As a consequence, when enabling IPv6 in linphone, it tries to bind to an
IPv6 address (“::0”) while specifying IPv4 as address family, which
fails.

We need to switch to eXosip_set_option:

  eXosip_set_option(ctx->excontext, EXOSIP_OPT_ENABLE_IPV6, &ipv6);

I’ve attached a patch which updates debian/patches/port-to-exosip-4.patch
Unfortunately, it seems I’m using a different quilt version than you
are, so quilt touched all hunks, making the patch bigger than it needs
to be. The important hunk of my patch is:

@@ -704,7 +722,14 @@
sal_set_dscp(ctx,ctx->dscp);
sal_use_dates(ctx,ctx->add_dates);
  
-@@ -429,7 +482,11 @@ int sal_listen_port(Sal *ctx, const char
+   ipv6=strchr(addr,':')!=NULL;
++#ifdef HAVE_STRUCT_EXOSIP_T
++  eXosip_set_option(ctx->excontext, EXOSIP_OPT_ENABLE_IPV6, &ipv6);
++#else
+   eXosip_enable_ipv6(ipv6);
++#endif
+ 
+   if (is_secure && tr == SalTransportUDP){
ms_fatal("SIP over DTLS is not supported yet.");
return -1;
}

Feel free to re-do my patch if that makes merging easier.

Thanks for your work on linphone!

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

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

Versions of packages linphone depends on:
ii  libasound21.0.29-1
ii  libatk1.0-0   2.18.0-1
ii  libavcodec-ffmpeg56   7:2.8.1-1
ii  libavutil-ffmpeg547:2.8.1-1
ii  libc6 2.19-22
ii  libcairo2 1.14.2-2
ii  libexosip2-11 4.1.0-2+b1
ii  libfontconfig12.11.0-6.3
ii  libfreetype6  2.6-2
ii  libgdk-pixbuf2.0-02.32.1-1
ii  libgl1-mesa-glx [libgl1]  11.0.5-1
ii  libglew1.13   1.13.0-2
ii  libglib2.0-0  2.46.2-3
ii  libglu1-mesa [libglu1]9.0.0-2.1
ii  libgtk2.0-0   2.24.28-1
ii  liblinphone5  3.6.1-2.4
ii  libmediastreamer-base33.6.1-2.4+b4
ii  libnotify40.7.6-2
ii  libogg0   1.3.2-1
ii  libopus0  1.1-2
ii  libortp9  3.6.1-2.4+b4
ii  libosip2-11   4.1.0-2
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  libpulse0 7.1-2
ii  libsoup2.4-1  2.52.1-1
ii  libspandsp2   0.0.6-2.1
ii  libspeex1 1.2~rc1.2-1
ii  libspeexdsp1  1.2~rc1.2-1
ii  libsqlite3-0  3.8.11.1-1
ii  libswscale-ffmpeg37:2.8.1-1
ii  libtheora01.1.1+dfsg.1-7
ii  libudev1  227-2
ii  libupnp6  1:1.6.19+git20141001-1
ii  libv4l-0  1.8.0-1
ii  libvpx3   1.5.0-2
ii  libx11-6  2:1.6.3-1
ii  libxv12:1.0.10-1+b1
ii  linphone-nogtk3.6.1-2.4

linphone recommends no packages.

Versions of packages linphone suggests:
pn  yelp  

-- no debconf information
--- linphone-3.6.1/debian/patches/port-to-exosip-4.patch	2013-07-30 22:45:13.0 +0200
+++ /tmp/linphone-3.6.1/debian/patches/port-to-exosip-4.patch	2016-01-11 09:45:22.990338912 +0100
@@ -10,8 +10,10 @@
 Only in linphone-3.6.1: config.sub
 Only in linphone-3.6.1: configure
 Only in linphone-3.6.1/console: Makefile.in
 a/coreapi/authentication.c
-+++ b/coreapi/authentication.c
+Index: linphone-3.6.1/coreapi/authentication.c
+===
+--- linphone-3.6.1.orig/coreapi/authentication.c
 linphone-3.6.1/coreapi/authentication.c
 @@ -308,7 +308,7 @@ void linphone_core_add_auth_info(Linphon
  			sai.userid=ai->userid;
  			sai.realm=ai->realm;
@@ -21,8 +23,10 @@
  			ai->usecount++;
  		}
  	}
 a/coreapi/callbacks.c
-+++ b/coreapi/callbacks.c
+Index: linphone-3.6.1/coreapi/callbacks.c
+===
+--- linphone-3.6.1.orig/coreapi/callbacks.c
 linphone-3.6.1/coreapi/callbacks.c
 @@ -224,19 +224,19 @@ static void call_received(SalOp *h){
  	lc->presence_mode==LinphoneStatusDoNotDisturb ||
  	lc->presence_mode==LinphoneStatusMoved){
@@ -96,8 +100,10 @@
  	}
  }
  
 a/coreapi/chat.c
-+++ b/coreapi/chat.c
+Index: linphone-3.6.1/coreapi/chat.c
+===
+--- linphone-3.6.1.orig/coreapi/chat.c
 linphone-3.6.1/coreapi/chat.c
 @@ -98,10 +98,10 @@ static void _linphone_chat_room_send_mes
  	}
  	if (msg->external_body_ur

Bug#810666: install of version 0.8.6 remove systemd

[Guus Sliepen]

severity 810666 normal
thanks

On Mon, Jan 11, 2016 at 07:12:28AM +0100, Jörg Frings-Fürst wrote:

> Package: ifupdown
> Version: 0.7.54
> Severity: critical
> 
> ~# apt-get dist-upgrade
> Paketlisten werden gelesen... Fertig
> Abhängigkeitsbaum wird aufgebaut.   
> Statusinformationen werden eingelesen Fertig
> Paketaktualisierung (Upgrade) wird berechnet... Fertig
> Die folgenden Pakete sind zurückgehalten worden:
>   ifupdown
> 0 aktualisiert, 0 neu installiert, 0 zu entfernen und 1 nicht aktualisiert.

dist-upgrade detects that there is a transition going on and that
upgrading ifupdown now would cause other packages to be removed, that is
why it keeps it back.

> ~# apt-get install ifupdown

Now you are telling apt-get to explicitly upgrade the ifupdown package:

> Paketlisten werden gelesen... Fertig
> Abhängigkeitsbaum wird aufgebaut.   
> Statusinformationen werden eingelesen Fertig
> The following additional packages will be installed:
>   sysvinit-core
> Vorgeschlagene Pakete:
>   ppp rdnssd
> Die folgenden Pakete werden ENTFERNT:
>   systemd systemd-sysv
> Die folgenden NEUEN Pakete werden installiert:
>   sysvinit-core

And it tells you here what will happen if you continue.

> Die folgenden Pakete werden aktualisiert (Upgrade):
>   ifupdown
> 1 aktualisiert, 1 neu installiert, 2 zu entfernen und 0 nicht aktualisiert.
> Es müssen 204 kB an Archiven heruntergeladen werden.
> Nach dieser Operation werden 17,9 MB Plattenplatz freigegeben.
> Möchten Sie fortfahren? [J/n] n

It asks you if you really want to do this or not. Note that your system
would still be perfectly working when it installs sysvinit. So nothing
is broken by the ifupdown package, therefore I'm reducing the severity.

-- 
Met vriendelijke groet / with kind regards,
  Guus Sliepen 


signature.asc
Description: Digital signature

Bug#810656: ifupdown: deadlocks: A start job is running for LSB: Raise network interfaces

[Guus Sliepen]

tags 810656 + pending
thanks

On Sun, Jan 10, 2016 at 05:50:05PM -0800, Alan W. Irwin wrote:

> I was going to add this additional report to
> , but that one
> has been closed so apparently I have to start a new bug report for this
> on-going issue.

You can reopen bugs that were closed, but it's OK to open a new one.

> This fairly modest recent update made the other computer unbootable.  The
> last message in the boot sequence is
> 
> "A start job is running for LSB: Raise network interfaces. (HHh MMmin SSsec / 
> no limit)
> 
> where HH is now up to 3 (hours).  Ctrl-C doesn't break the deadlock
> and if I type ctrl-alt-del, then the boot sequence is gone through
> again until this same deadlock is reached.
[...]
> So can we have an immediate Jessie fix for that unlimited timeout at
> least? A slowly booting machine is far preferable to one that won't
> boot at all.  :-)

That's indeed a problem. The upcoming version of ifupdown will have a
timeout of 5 minutes.

> Also, could someone here give clear directions about how to get out of
> the current deadlock so I can use that other computer or is a rescue
> distro like RIP necessary to get that computer working again? Note
> again, ctrl-C has no effect and ctrl-alt-del just reboots into the
> same deadlock again.

That I actually don't know, I suspect you have to ask some systemd gurus
about how to do that.

> >From previous experience with this deadlock on my current computer, I
> suspect this deadlock was caused because of the following stanza in
> /etc/network/interfaces on the currently deadlocked system (with the
> pre-up commands commented out on my current computer to avoid the
> deadlock).
> 
> auto eth0
> iface eth0 inet dhcp
> pre-up [ -f /etc/init.d/ferm ]
> pre-up /etc/init.d/ferm start >| /tmp/ferm.out 2>&1
> 
> The point of those two pre-up commands (which I have used on Debian
> for a very long time) was to work around a slight ferm issue where the
> configured firewall is put into place by ferm after networking is up,
> and I prefer to do that before (on at least non-NFS systems like this
> one where /etc/init.d/ferm is available regardless of networking) to
> avoid that small gap in firewall coverage.
> 
> Up to today's modest update the above pre-up commands were not causing
> any trouble on that system (which has a USB stick drive rather than
> a normal HD) so I did not comment them out.
> 
> Could you advise me how to get the above ferm workaround to work on
> non-NFS systems like this one (and also my present one) without generating a 
> deadlock?

If it's ferm itself that is stuck, then you can apply a timeout to that
one, like this:

auto eth0
iface eth0 inet dhcp
pre-up timeout 1m service ferm start

The timeout command should always be installed on a Debian system, in
/usr/bin. I hope this helps.

-- 
Met vriendelijke groet / with kind regards,
  Guus Sliepen 


signature.asc
Description: Digital signature

Bug#797623: opensaml2: transition needed for g++-5 ABIs

[Andreas Beckmann]

Control: block 797770 with -1

On Tue, 01 Sep 2015 10:48:28 +0200 Ferenc Wagner  wrote:
> Hi,
> 
> Thanks for the detailed report.  Right now I'm doing urgent work on HA
> packages, but once that's done, I'll package new upstream versions of
> the whole Shibboleth stack to fix the outstanding OpenSAML security bug
> in unstable.  This will change the SO version of xml-security-c and
> probably all other library packages in the stack.  Does this change the
> big picture somehow?  I don't understand the interdependencies of this
> transition.  Anyway, feel free to NMU these packages if that helps
> unblocking other stuff, just don't be too concerned about the fate of
> the current versions in unstable, expect new upstream versions after a
> couple of weeks.

A couple of months later: What's the status?


Andreas

Bug#810680: Poweroff not working on QNAP: POWER_RESET=y missing

[Martin Michlmayr]

Package: linux
Version: 4.3.3-5
Tags: patch

I finally figured out why poweroff is not working on QNAP devices
despite the fix I mentioned in #807696 recently.  POWER_RESET is not
enabled, so POWER_RESET_QNAP is not built in.

I also enabled POWER_RESET_GPIO since that's needed by some Kirkwood
devices we support.

diff --git a/debian/config/armel/config.kirkwood 
b/debian/config/armel/config.kirkwood
index 8ab415d..ad11867 100644
--- a/debian/config/armel/config.kirkwood
+++ b/debian/config/armel/config.kirkwood
@@ -438,6 +438,8 @@ CONFIG_PCI_MVEBU=y
 ##
 ## file: drivers/power/reset/Kconfig
 ##
+CONFIG_POWER_RESET=y
+CONFIG_POWER_RESET_GPIO=y
 CONFIG_POWER_RESET_QNAP=y
 CONFIG_POWER_RESET_RESTART=y
 

-- 
Martin Michlmayr
http://www.cyrius.com/

Bug#810131: RM: python-pygithub [all] -- NBS; renamed to python-github

[Gianfranco Costamagna]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Hi ftpmasters!

>> 
> This is already on the cruft report.  Once the rdepends are fixed,
> this will be taken care of automatically.
> 

well, actually it used to be automatically handled, but something is
preventing it to disappear.

I have the same issue with src:python-udiskie, that has been included
into a new src:udiskie package, but I still see the old source around

(and I confirm before it was correctly deleted).

Can it be a regression in some script?

(BTW my udiskie shouldn't have any rdep, being an application)

thanks,
Gianfranco

> Scott K
> 
> 
-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQIcBAEBCAAGBQJWk3i8AAoJEPNPCXROn13ZLSQQAM0TNtWRuRjt+a21gXacePa4
+zoQ4cm4WGvNDSJazzl1fJTNna8xtoM1+fhOaxPuwx8vMDsRxCAoBdowqnxZiP7m
cN8SlZrgBnc+2fX5SxmHwg0xGc5CSnWCTfrTDrAPQiggdOlXIwiCaadqfFRAXpGw
4UfPka8bV3ahjtzC4AOMQTAEMTsW7qUue1NN+G8BZ5PEdMucnIPR3pZX9QsiCaSF
IyBqBOw79kxKHDTrsNzRzk2cNq1Entqe173+hbsVymqGCX0GvmvtVlf/ta9ngQ3P
G3YTAR+K8AiCcXsG2MUC4zCXQXx1v4zflYULFphyJFWx5D90Jr4fHVdnqK9NdOUC
TdaSGVLXws3KwTeyrxf4HOJrwT2YIbN/Zf+l2tcf/ggKUMn7qOiQ2PKC3TpVLwvw
Rv6Lx1JLpDoQ29kUagm7AZM0fqcdQ5m4AwThlDSjqLJxOJxcbuEnDlcBx/trXh74
6ZogDrqQ4uAA76cTPbbFOrlLM4YVEiBsU6AkmIys00+1h6MSFXjbMScoG20Jwdp1
E93xMILcOZvOEYQtcXJQyoiTmGUkdu6tKU3Iejk6l5zq2yr8CkfWf5tNQv0jOVyp
c0srNqktocI9x6fij4cAFp2d/yzMkIaHKNs8AhGRkytzNR1iv8lCIk/C1LH/EMG6
7x7UIusI9eZxocOpJwF7
=eo2s
-END PGP SIGNATURE-

Bug#810131: RM: python-pygithub [all] -- NBS; renamed to python-github

[Mattia Rizzolo]

On Mon, Jan 11, 2016 at 10:41:16AM +0100, Gianfranco Costamagna wrote:
> > This is already on the cruft report.  Once the rdepends are fixed,
> > this will be taken care of automatically.
> > 
> 
> well, actually it used to be automatically handled, but something is
> preventing it to disappear.
> 
> I have the same issue with src:python-udiskie, that has been included
> into a new src:udiskie package, but I still see the old source around

the problem is actually different:

in your case it's an old source, which afaik needs a manual removal,
mine is an old binary, which will be dealt automatically once the rdep
is done, but I'd love it to be taken care of before that will happen
(because waiting s not really needed, and because otherwise britney
won't migrate it).

-- 
regards,
Mattia Rizzolo

GPG Key: 66AE 2B4A FCCF 3F52 DA18  4D18 4B04 3FCD B944 4540  .''`.
more about me:  http://mapreri.org  : :'  :
Launchpad user: https://launchpad.net/~mapreri  `. `'`
Debian QA page: https://qa.debian.org/developer.php?login=mattia  `-


signature.asc
Description: PGP signature

Bug#810681: heimdal-clients: installing package forces krb5-user to be removed

[Paul Millar]

Package: heimdal-clients
Version: 1.6~rc2+dfsg-9
Severity: important

Dear Maintainer,

I am trying to install the heimdal-clients package because it contains some
"kerberised" applications that do not exist in the MIT equivalent package:
krb5-user.

However, installing heimdal-clients would force krb5-user to be remove:


paul@celebrimbor:~$ sudo apt-get --dry-run install heimdal-clients
Reading package lists... Done
Building dependency tree
Reading state information... Done
The following extra packages will be installed:
  libhdb9-heimdal libkadm5clnt7-heimdal libkadm5srv8-heimdal libkafs0-heimdal
libotp0-heimdal libsl0-heimdal
Suggested packages:
  heimdal-docs heimdal-kcm
The following packages will be REMOVED:
  krb5-user
The following NEW packages will be installed:
  heimdal-clients libhdb9-heimdal libkadm5clnt7-heimdal libkadm5srv8-heimdal
libkafs0-heimdal libotp0-heimdal libsl0-heimdal
0 upgraded, 7 newly installed, 1 to remove and 0 not upgraded.
Remv krb5-user [1.12.1+dfsg-19+deb8u1]
Inst libhdb9-heimdal (1.6~rc2+dfsg-9 Debian:8.2/stable [amd64])
Inst libkadm5clnt7-heimdal (1.6~rc2+dfsg-9 Debian:8.2/stable [amd64])
Inst libkadm5srv8-heimdal (1.6~rc2+dfsg-9 Debian:8.2/stable [amd64])
Inst libkafs0-heimdal (1.6~rc2+dfsg-9 Debian:8.2/stable [amd64])
Inst libotp0-heimdal (1.6~rc2+dfsg-9 Debian:8.2/stable [amd64])
Inst libsl0-heimdal (1.6~rc2+dfsg-9 Debian:8.2/stable [amd64])
Inst heimdal-clients (1.6~rc2+dfsg-9 Debian:8.2/stable [amd64])
Conf libhdb9-heimdal (1.6~rc2+dfsg-9 Debian:8.2/stable [amd64])
Conf libkadm5clnt7-heimdal (1.6~rc2+dfsg-9 Debian:8.2/stable [amd64])
Conf libkadm5srv8-heimdal (1.6~rc2+dfsg-9 Debian:8.2/stable [amd64])
Conf libkafs0-heimdal (1.6~rc2+dfsg-9 Debian:8.2/stable [amd64])
Conf libotp0-heimdal (1.6~rc2+dfsg-9 Debian:8.2/stable [amd64])
Conf libsl0-heimdal (1.6~rc2+dfsg-9 Debian:8.2/stable [amd64])
Conf heimdal-clients (1.6~rc2+dfsg-9 Debian:8.2/stable [amd64])
paul@celebrimbor:~$


>From manual dry-run installing each of the dependencies, I see that only the
heimdal-clients package requires the removal of the krb5-user package.

I don't understand the reason for requiring krb5-user package to be removed: in
case of conflicting names, alternatives (as provided by dpkg) allows multiple
instances to exist concurrently.

I've classified this bug as IMPORTANT, but it could also be classified as
WISHLIST, depending on one's point-of-view.

Cheers,

Paul.



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

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

Bug#810682: libncarg-dev: unsatisfiable Depends: ncl-narg

[Andreas Beckmann]

Package: libncarg-dev
Version: 6.3.0-5
Severity: serious
User: debian...@lists.debian.org
Usertags: piuparts

Hi,

during a test with piuparts I noticed your package is no longer
installable in sid:

unsatisfiable Depends: ncl-narg

Did you mean ncl-ncarg?


Cheers,

Andreas

Bug#810684: audacity: Freeze during playback

[Jerry Quinn]

Package: audacity
Version: 2.0.6-2+b3
Severity: normal

Dear Maintainer,

I have a 45 minute mp3 loaded.  I was playing bits, moving around near the
beginning and playing again.  After several times, audacity locked up hard.

I attached gdb and dumped the backtrace for each of the active threads.

jlquinn@cerberus:~/fast$ gdb -p 27627
GNU gdb (Debian 7.10-1) 7.10
Copyright (C) 2015 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
.
Find the GDB manual and other documentation resources online at:
.
For help, type "help".
Type "apropos word" to search for commands related to "word".
Attaching to process 27627
Reading symbols from /usr/bin/audacity...(no debugging symbols found)...done.
Reading symbols from /lib/x86_64-linux-gnu/libexpat.so.1...(no debugging
symbols found)...done.
Reading symbols from /usr/lib/x86_64-linux-gnu/libportaudio.so.2...(no
debugging symbols found)...done.
Reading symbols from /usr/lib/x86_64-linux-gnu/libsndfile.so.1...(no debugging
symbols found)...done.
Reading symbols from /usr/lib/x86_64-linux-gnu/libwx_gtk2u_html-3.0.so.0...(no
debugging symbols found)...done.
Reading symbols from /usr/lib/x86_64-linux-gnu/libwx_gtk2u_adv-3.0.so.0...(no
debugging symbols found)...done.
Reading symbols from /usr/lib/x86_64-linux-gnu/libwx_gtk2u_core-3.0.so.0...(no
debugging symbols found)...done.
Reading symbols from /usr/lib/x86_64-linux-gnu/libwx_baseu-3.0.so.0...(no
debugging symbols found)...done.
Reading symbols from /usr/lib/x86_64-linux-gnu/libavcodec-ffmpeg.so.56...(no
debugging symbols found)...done.
Reading symbols from /usr/lib/x86_64-linux-gnu/libavformat-ffmpeg.so.56...(no
debugging symbols found)...done.
Reading symbols from /usr/lib/x86_64-linux-gnu/libavutil-ffmpeg.so.54...(no
debugging symbols found)...done.
Reading symbols from /usr/lib/x86_64-linux-gnu/libmp3lame.so.0...(no debugging
symbols found)...done.
Reading symbols from /usr/lib/x86_64-linux-gnu/libFLAC++.so.6...(no debugging
symbols found)...done.
Reading symbols from /usr/lib/x86_64-linux-gnu/libFLAC.so.8...(no debugging
symbols found)...done.
Reading symbols from /usr/lib/libid3tag.so.0...(no debugging symbols
found)...done.
Reading symbols from /usr/lib/x86_64-linux-gnu/libmad.so.0...(no debugging
symbols found)...done.
Reading symbols from /usr/lib/x86_64-linux-gnu/libSoundTouch.so.1...(no
debugging symbols found)...done.
Reading symbols from /usr/lib/x86_64-linux-gnu/libsoxr.so.0...(no debugging
symbols found)...done.
Reading symbols from /usr/lib/x86_64-linux-gnu/libtwolame.so.0...(no debugging
symbols found)...done.
Reading symbols from /usr/lib/x86_64-linux-gnu/libvorbisenc.so.2...(no
debugging symbols found)...done.
Reading symbols from /usr/lib/x86_64-linux-gnu/libvorbisfile.so.3...(no
debugging symbols found)...done.
Reading symbols from /usr/lib/x86_64-linux-gnu/libvorbis.so.0...(no debugging
symbols found)...done.
Reading symbols from /usr/lib/x86_64-linux-gnu/libogg.so.0...(no debugging
symbols found)...done.
Reading symbols from /usr/lib/x86_64-linux-gnu/libportSMF.so.0...(no debugging
symbols found)...done.
Reading symbols from /usr/lib/x86_64-linux-gnu/libsbsms.so.10...(no debugging
symbols found)...done.
Reading symbols from /usr/lib/x86_64-linux-gnu/libvamp-hostsdk.so.3...(no
debugging symbols found)...done.
Reading symbols from /lib/x86_64-linux-gnu/libdl.so.2...Reading symbols from
/usr/lib/debug/.build-id/4e/f0d5906cc076c075416d683c32960cca5597f5.debug...done.
done.
Reading symbols from /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0...Reading
symbols from
/usr/lib/debug/.build-id/b2/2926c9347c837b223a930fa8047344d0412d27.debug...done.
done.
Reading symbols from /usr/lib/x86_64-linux-gnu/libasound.so.2...(no debugging
symbols found)...done.
Reading symbols from /lib/x86_64-linux-gnu/libpthread.so.0...Reading symbols
from
/usr/lib/debug/.build-id/75/d11a3ee55319e6cebcf33286de8df9a39bcaea.debug...done.
done.
[New LWP 28047]
[New LWP 28046]
[New LWP 27809]
[New LWP 27808]
[New LWP 27637]
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
Reading symbols from /usr/lib/x86_64-linux-gnu/libstdc++.so.6...(no debugging
symbols found)...done.
Reading symbols from /lib/x86_64-linux-gnu/libm.so.6...Reading symbols from
/usr/lib/debug/.build-id/32/cf2a6213282743ee4531d19850652c3fc0a143.debug...done.
done.
Reading symbols from /lib/x86_64-linux-gnu/libgcc_s.so.1...(no debugging
symbols found)...done.
Reading symbols from /lib/x86_64-linux-gnu/libc.so.6...Reading symbols from
/usr/lib/d

Bug#810683: nmu: openblas_0.2.15-1 atlas_3.10.2-9

[Sébastien Villemot]

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

Dear Release Team,

Please schedule a binNMU of openblas and atlas. The libraries build by these
packages contain some binary objects that are taken from lapack (via the
liblapack-pic package), as reflected by their Built-Using field. They need to
be rebuild against the newly uploaded lapack 3.6.0-2.

nmu openblas_0.2.15-1 atlas_3.10.2-9 . ANY . unstable . -m "Rebuild against 
LAPACK 3.6.0"

Cheers,

-- 
 .''`.Sébastien Villemot
: :' :Debian Developer
`. `' http://sebastien.villemot.name
  `-  GPG Key: 4096R/381A7594


signature.asc
Description: PGP signature

Bug#810685: [apt] apt has no bash-completion

[Bogdan Vatra]

Package: apt
Version: 1.1.10
Severity: wishlist

--- Please enter the report below this line. ---
apt-get has full bash completion, but sadly, apt has none.
It will be great if apt command will gain bash completion.

Thanks.

BogDan.

Bug#741935: Bug#803800: avbin: FTBFS with FFmpeg 2.9

[Jonathan Peirce]

Thanks for the note Andreas. I think for the psychopy package we now 
have sufficient alternatives that we can live without avbin.

best wishes
Jon

On 07/01/16 22:31, Andreas Cadhalpun wrote:

Hi,

the next version of FFmpeg is planned to be released this month
(and it might be called 3.0 instead of 2.9).

As this package is currently broken (#750577), not in testing
due to #741935, and still orphaned, I think it should be removed
from sid.

Therefore I'll request it's removal soon, unless someone fixes
the outstanding issues of this package.

Best regards,
Andreas


--
Dr Jonathan Peirce
School of Psychology
University of Nottingham





This message and any attachment are intended solely for the addressee
and may contain confidential information. If you have received this
message in error, please send it back to me, and immediately delete it. 


Please do not use, copy or disclose the information contained in this
message or in any attachment.  Any views or opinions expressed by the
author of this email do not necessarily reflect the views of the
University of Nottingham.

This message has been checked for viruses but the contents of an
attachment may still contain software viruses which could damage your
computer system, you are advised to perform your own checks. Email
communications with the University of Nottingham may be monitored as
permitted by UK legislation.

Bug#741223: Simplifying the patch

[Sunil Mohan Adapa]

I believe, the patch can and must be simplified.

*Current state*: The current patch creates a subvol called "@" and then
makes a lot of code changes to various activities to make sure that all
the activities happen on that subvol. The main brtfs volume is mounted
and then root directory path (the subvolume to work on) argument is
passed to all the necessary functions. This technique is based on
conventions specified in https://help.ubuntu.com/community/btrfs. On
this page, the only reason specified for not using default subvolume
feature of btrfs is that it does not work with rootfsflags recommended
in the page. I find that this convention makes it easy to examine
subvolumes and organize them but makes it hard to actually use a
subvolume. Typical process of reverting to a snapshot (which is a
subvolume) involves switching the default subvolume and rebooting.
However, in this convention, switching to a subvolume involves changing
boot arguments and modifying the fstab. From a reliability point of
view, this is troubling because we have to reliably update the uboot
environment, grub configuration and fstab.

*Proposal*: We should use the default volume feature of the btrfs
filesytem and we should not pass "subvol=@" etc. in fstab and kernel
boot arguments. In fact we should not even create a default subvolume
called "@". Then the patch will become very simple. No need to create
subvolume, no need to pass rootfsdir to all methods, no need for extra
/btrfs directory, no need to have special grub arguments and no need to
have special fstab options. The patch should simply create filesystem
with type 'btrfs' then treat it like any other filesystem by mounting,
debootstrapping, running grub-install etc. This mostly means that the
patch is not necessary. We just need to create some test cases (based on
existing cases for ext4) to make sure btrfs is building/running fine.

Snapshotting tools will then deal with complexity of
snapshots/subvolumes. A good example is how Snapper (snapper.io) works.
It creates snapshots underneath /.snapshots. When someone reverts to a
snapshot, it will set the default subvolume of the btrfs filesystem and
recommend a reboot. All of this can be done without the "@" subvolume. I
will post a separate proposal for snapshotting in FreedomBox in more
detail based on this plan.

-- 
Sunil



signature.asc
Description: OpenPGP digital signature

Bug#790762: src:hplip: Many PPD files for postscript drivers are missing in printer-driver-postscript-hp

[John Paul Adrian Glaubitz]

On 01/11/2016 11:23 AM, Didier 'OdyX' Raboud wrote:
>> While setting up a new print server on the network, we noticed 
>> that the binary package printer-driver-postscript-hp is missing 
>> the PPDs for many postscript printers actually supported by 
>> hplip.
> 
> It's not. These are now compressed using pyppd, since version 
> 3.10.9-1: They are in the /usr/lib/cups/driver/postscript-hp python
> script.
> 
> CUPS uses these "PPD-compressed scripts" in /usr/lib/cups/driver 
> itself to extract the needed PPDs, and there should be little need 
> for you to need the PPD files directly.

Ok, strange concept. On the other hand, the hpijs-ppds package contains
the PPDs uncompressed:

glaubitz@z6:/tmp> dpkg-deb -c hpijs-ppds_3.15.11+repack0-1_all.deb |
head -n 20
drwxr-xr-x root/root 0 2016-01-10 02:00 ./
drwxr-xr-x root/root 0 2016-01-10 02:00 ./usr/
drwxr-xr-x root/root 0 2016-01-10 02:00 ./usr/share/
drwxr-xr-x root/root 0 2016-01-10 02:00 ./usr/share/doc/
drwxr-xr-x root/root 0 2016-01-10 02:00
./usr/share/doc/hpijs-ppds/
-rw-r--r-- root/root 75864 2016-01-09 22:42
./usr/share/doc/hpijs-ppds/changelog.Debian.gz
-rw-r--r-- root/root  4830 2016-01-09 22:42
./usr/share/doc/hpijs-ppds/copyright
drwxr-xr-x root/root 0 2016-01-10 02:00 ./usr/share/ppd/
drwxr-xr-x root/root 0 2016-01-10 02:00 ./usr/share/ppd/hplip/
drwxr-xr-x root/root 0 2016-01-10 02:00 ./usr/share/ppd/hplip/HP/
-rw-r--r-- root/root 19199 2016-01-10 02:00
./usr/share/ppd/hplip/HP/hp-scanjet_pro_3500_f1-hpijs.ppd
-rw-r--r-- root/root 19417 2016-01-10 02:00
./usr/share/ppd/hplip/HP/hp-psc_950xi-hpijs.ppd
-rw-r--r-- root/root 19417 2016-01-10 02:00
./usr/share/ppd/hplip/HP/hp-psc_950vr-hpijs.ppd
-rw-r--r-- root/root 19399 2016-01-10 02:00
./usr/share/ppd/hplip/HP/hp-psc_950-hpijs.ppd
-rw-r--r-- root/root 19399 2016-01-10 02:00
./usr/share/ppd/hplip/HP/hp-psc_920-hpijs.ppd
-rw-r--r-- root/root 19455 2016-01-10 02:00
./usr/share/ppd/hplip/HP/hp-psc_900_series-hpijs.ppd
-rw-r--r-- root/root 19417 2016-01-10 02:00
./usr/share/ppd/hplip/HP/hp-psc_780xi-hpijs.ppd
-rw-r--r-- root/root 19399 2016-01-10 02:00
./usr/share/ppd/hplip/HP/hp-psc_780-hpijs.ppd
-rw-r--r-- root/root 19399 2016-01-10 02:00
./usr/share/ppd/hplip/HP/hp-psc_760-hpijs.ppd
-rw-r--r-- root/root 19417 2016-01-10 02:00
./usr/share/ppd/hplip/HP/hp-psc_750xi-hpijs.ppd
dpkg-deb: error: subprocess tar was killed by signal (Broken pipe)
glaubitz@z6:/tmp>

So the packaging is somewhat inconsistent. I also really don't see the
advantage in obfuscating and compressing a few text files like that,
but ok.

> You can always get the PPD file with calling the archive as 
> follows:
> 
> $ /usr/lib/cups/driver/postscript-hp cat 
> "postscript-hp:0/ppd/hplip/HP/hp-designjet_t2300_postscript-ps.ppd"

Ok, good to know. Thanks for the heads-up!

Adrian

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

Bug#810686: Creepy: Add Youtube plugin?

[Petter Reinholdtsen]

Package: creepy
Version: 1.3-1
Severity: wishlist

According to
https://code.google.com/p/gdata-issues/issues/detail?id=4234 >,
there is a API on Youtube to find videos by location.

The URL
https://gdata.youtube.com/feeds/api/videos?v=2&alt=json&location=51.7248487,-1.2328819!&location-radius=1km
 >
is supposed to be working, but when I tested it I got this reply:

  

  GData
  NoLongerAvailableException
  No longer available

  

I have not been able to find out if the API is replaced or simply
removed.

-- 
Happy hacking
Petter Reinholdtsen

Bug#808581: chromium: reactivate NPAPI option

[Pierre Crescenzo]

Hello,

I have gnome-shell-extensions package. But this is not an alternative of
the web functionalities.

Regards,


Pierre Crescenzo
  mailto:pie...@crescenzo.nom.fr
  http://www.crescenzo.nom.fr/

Bug#810687: mdadm: eats all cpu time on all cores

[Michal Suchanek]

Package: mdadm
Version: 3.3.4-1.1+b1
Severity: normal

hello,

mdadm eats all CPU time of all cores.

This ShouldNotHappen(tm)

I had a lvm volume on a disk which failed while I was trying to upgrade
the volume to raid1 so my raid configureation is very broken.

killing mdadm only helps temporarily. it restarts itself.

Is there any debug information I can provide before I trash the disks?

Thanks

Michal


-- Package-specific info:
--- mdadm.conf
CREATE owner=root group=disk mode=0660 auto=yes
HOMEHOST 
MAILADDR root
ARRAY metadata=ddf UUID=587baab3:c41402e5:c334b912:99c2ce3f
ARRAY container=587baab3:c41402e5:c334b912:99c2ce3f member=0 
UUID=363fa001:b5660ad0:24715b0d:afaecdb2

--- /etc/default/mdadm
INITRDSTART='none'
AUTOCHECK=true
START_DAEMON=true
DAEMON_OPTIONS="--syslog"
VERBOSE=false

--- /proc/mdstat:
Personalities : [linear] [raid1] 
md126 : inactive sdg[0]
  975585280 blocks super external:/md127/0
   
md127 : inactive sdg[0](S)
  1177304 blocks super external:ddf
   
unused devices: 

--- /proc/partitions:
major minor  #blocks  name

   8   80   31266648 sdf
   8   814193280 sdf1
   8   82   27070464 sdf2
   8   96  976762584 sdg
   8  112  244198584 sdh
   8  113  244197376 sdh1
   8  128  244198584 sdi
   8  129   20481024 sdi1
   8  1303148740 sdi2
   8  132  220564417 sdi4
   70   55562240 loop0
   80   30310400 sda
   81   30310384 sda1

--- LVM physical volumes:
  PV VG   Fmt  Attr PSize   PFree
  /dev/sdg   scratchg lvm2 a--  931.51g 8.00m
--- mount output
sysfs on /sys type sysfs (rw,nosuid,nodev,noexec,relatime)
proc on /proc type proc (rw,relatime)
udev on /dev type devtmpfs (rw,relatime,size=10240k,nr_inodes=1005252,mode=755)
devpts on /dev/pts type devpts 
(rw,nosuid,noexec,relatime,gid=5,mode=620,ptmxmode=000)
tmpfs on /run type tmpfs (rw,nosuid,relatime,size=1612848k,mode=755)
/dev/sdf2 on / type ext3 (rw,relatime,errors=remount-ro,data=ordered)
securityfs on /sys/kernel/security type securityfs 
(rw,nosuid,nodev,noexec,relatime)
tmpfs on /dev/shm type tmpfs (rw,nosuid,nodev)
tmpfs on /run/lock type tmpfs (rw,nosuid,nodev,noexec,relatime,size=5120k)
tmpfs on /sys/fs/cgroup type tmpfs (ro,nosuid,nodev,noexec,mode=755)
cgroup on /sys/fs/cgroup/systemd type cgroup 
(rw,nosuid,nodev,noexec,relatime,xattr,release_agent=/lib/systemd/systemd-cgroups-agent,name=systemd)
pstore on /sys/fs/pstore type pstore (rw,nosuid,nodev,noexec,relatime)
cgroup on /sys/fs/cgroup/cpuset type cgroup 
(rw,nosuid,nodev,noexec,relatime,cpuset)
cgroup on /sys/fs/cgroup/blkio type cgroup 
(rw,nosuid,nodev,noexec,relatime,blkio)
cgroup on /sys/fs/cgroup/cpu,cpuacct type cgroup 
(rw,nosuid,nodev,noexec,relatime,cpu,cpuacct)
cgroup on /sys/fs/cgroup/freezer type cgroup 
(rw,nosuid,nodev,noexec,relatime,freezer)
cgroup on /sys/fs/cgroup/perf_event type cgroup 
(rw,nosuid,nodev,noexec,relatime,perf_event)
cgroup on /sys/fs/cgroup/devices type cgroup 
(rw,nosuid,nodev,noexec,relatime,devices)
cgroup on /sys/fs/cgroup/net_cls,net_prio type cgroup 
(rw,nosuid,nodev,noexec,relatime,net_cls,net_prio)
systemd-1 on /proc/sys/fs/binfmt_misc type autofs 
(rw,relatime,fd=35,pgrp=1,timeout=0,minproto=5,maxproto=5,direct)
debugfs on /sys/kernel/debug type debugfs (rw,relatime)
hugetlbfs on /dev/hugepages type hugetlbfs (rw,relatime)
mqueue on /dev/mqueue type mqueue (rw,relatime)
/dev/sdh1 on /srv/rhev type ext4 (rw,relatime,data=ordered)
/dev/sdi1 on /home type ext3 (rw,relatime,errors=remount-ro,data=ordered)
/dev/sdi4 on /scratch type ext3 (rw,relatime,data=ordered)
rpc_pipefs on /run/rpc_pipefs type rpc_pipefs (rw,relatime)
nfsd on /proc/fs/nfsd type nfsd (rw,relatime)
binfmt_misc on /proc/sys/fs/binfmt_misc type binfmt_misc (rw,relatime)
tmpfs on /run/user/1000 type tmpfs 
(rw,nosuid,nodev,relatime,size=806424k,mode=700,uid=1000,gid=1000)
gvfsd-fuse on /run/user/1000/gvfs type fuse.gvfsd-fuse 
(rw,nosuid,nodev,relatime,user_id=1000,group_id=1000)
fusectl on /sys/fs/fuse/connections type fusectl (rw,relatime)
usmb on /home/hramrach/mnt type fuse.usmb 
(rw,nosuid,nodev,relatime,user_id=1000,group_id=1000,max_read=32768)
servo:/srv/samba/au on /home/hramrach/au type fuse.sshfs 
(rw,nosuid,nodev,relatime,user_id=1000,group_id=1000)
servo:/srv/scratch/Incoming on /home/hramrach/inc type fuse.sshfs 
(rw,nosuid,nodev,relatime,user_id=1000,group_id=1000)
usmb on /home/hramrach/win type fuse.usmb 
(rw,nosuid,nodev,relatime,user_id=1000,group_id=1000,max_read=32768)
/dev/sda1 on /srv/flash type ext4 (rw,relatime,data=ordered)
usmb on /home/hramrach/data type fuse.usmb 
(rw,nosuid,nodev,relatime,user_id=1000,group_id=1000,max_read=32768)
usmb on /home/hramrach/inst type fuse.usmb 
(rw,nosuid,nodev,relatime,user_id=1000,group_id=1000,max_read=32768)
heretic:/media/sdg1 on /home/hramrach/test type fuse.sshfs 
(rw,nosuid,nodev,relatime,user_id=1000,group_id=1000)

--- initrd.img-3.16.0-4-amd64:

gzip: /boot/initrd.img-3.16.0-4-amd64: not

Bug#810688: shadowsocks: man page references texinfo documents which don't exist

[Michal Suchanek]

Package: shadowsocks
Version: 2.1.0-1
Severity: normal

Hello,

when reading shadowsocks(1) man page I get this at the bottom:

SEE ALSO
   The  programs  are  documented fully by Shell Xu
and Clowwindy ,
   available via the
  Info system.

However, both info shadowsocks and info ssserver return the stub
manpages and no actual texinfo documentation.

Please add the texinfo documentation or remove the reference.

Thanks

-- System Information:
Debian Release: stretch/sid
  APT prefers testing
  APT policy: (910, 'testing'), (900, 'stable'), (610, 'oldstable'), (410, 
'unstable'), (400, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386, armhf

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) (ignored: LC_ALL 
set to en_US.UTF-8)
Shell: /bin/sh linked to /bin/bash
Init: systemd (via /run/systemd/system)

Versions of packages shadowsocks depends on:
ii  dpkg  1.18.3
ii  python2.7.11-1
ii  python-m2crypto   0.22.6~rc4-1
ii  python-pkg-resources  18.8-1

shadowsocks recommends no packages.

shadowsocks suggests no packages.

-- no debconf information

Bug#789931: tag this as wontfix/severity normal

[Gert Wollny]

tags 789931 wontfix 
severity 789931 severity
thanks

The bug was reported against version 2.2.0 which is outdated, version
3.2.0 now builds find on all architectures that are supported by the
insighttoolkit4. 

On the other hand,  the bug reports build failure on arm64 - this is an
arch that is not (yet) supported by insighttoolkit4 and the arch
support depends on upstream. Hence the downgrade and tag.

Bast, 
Gert 

Bug#810602: ITP: argon2 -- memory-hard hashing function

[Luca BRUNO]

On Monday, January 11, 2016 08:57:23 AM Paul Wise wrote:
> On Sun, Jan 10, 2016 at 8:03 PM, Luca Bruno wrote:
> >  Argon2 is a password-hashing function that can be used to hash passwords
> >  for credential storage, key derivation, or other applications.
> 
> It might be better to move to client-side SSL certificates than keep
> using passwords :)

The description should probably be reworded a bit to stress that this is the 
outcome of the https://password-hashing.net/ competition.

Cheers, Luca

-- 
 .''`.  ** Debian GNU/Linux **  | Luca Bruno (kaeso)
: :'  :   The Universal O.S.| lucab (AT) debian.org
`. `'`  | GPG: 0xBB1A3A854F3BBEBF
  `- http://www.debian.org  | Debian GNU/Linux Developer


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

Bug#810689: php5.6-cli: unowned symlink after purge (policy 6.8, 10.8): /etc/php/5.6/cli/conf.d/20-opcache.ini -> /etc/php/mods-available/opcache.ini

[Andreas Beckmann]

Package: php5.6-cli
Version: 5.6.17+dfsg-1
Severity: important
User: debian...@lists.debian.org
Usertags: piuparts

Hi,

during a test with piuparts I noticed your package left unowned files on
the system after purge, which is a violation of policy 6.8 (or 10.8):

https://www.debian.org/doc/debian-policy/ch-maintainerscripts.html#s-removedetails

Filing this as important as having a piuparts clean archive is a release
goal since lenny.

>From the attached log (scroll to the bottom...):

0m59.8s ERROR: FAIL: Package purging left files on system:
  /etc/php/5.6/cli/  owned by: php5.6-cli
  /etc/php/5.6/cli/conf.d/   owned by: php5.6-cli
  /etc/php/5.6/cli/conf.d/20-opcache.ini -> /etc/php/mods-available/opcache.ini 
 not owned


cheers,

Andreas


php5.6-cli_5.6.17+dfsg-1.log.gz
Description: application/gzip

Bug#799237:

[Michael D]

#810675 - upgrading to the latest upstream version fixes this.

Bug#810690: php7.0-cli: unowned symlinks after purge (policy 6.8, 10.8): /etc/php/7.0/cli/conf.d/20-{json, opcache}.ini -> /etc/php/mods-available/*.ini

[Andreas Beckmann]

Package: php7.0-cli
Version: 7.0.2-1
Severity: important
User: debian...@lists.debian.org
Usertags: piuparts

Hi,

during a test with piuparts I noticed your package left unowned files on
the system after purge, which is a violation of policy 6.8 (or 10.8):

https://www.debian.org/doc/debian-policy/ch-maintainerscripts.html#s-removedetails

Filing this as important as having a piuparts clean archive is a release
goal since lenny.

>From the attached log (scroll to the bottom...):

0m47.4s ERROR: FAIL: Package purging left files on system:
  /etc/php/7.0/cli/  owned by: php7.0-cli
  /etc/php/7.0/cli/conf.d/   owned by: php7.0-cli
  /etc/php/7.0/cli/conf.d/20-json.ini -> /etc/php/mods-available/json.ini   
 not owned
  /etc/php/7.0/cli/conf.d/20-opcache.ini -> /etc/php/mods-available/opcache.ini 
 not owned


cheers,

Andreas


php7.0-cli_7.0.2-1.log.gz
Description: application/gzip

Bug#777791: ball: ftbfs with GCC-5

[Danny Edel]

Hello Andreas, hello list(s),

I tried to reproduce this build failure on a current sid and investigate
a bit.  On my machine it outputs the same basic error messages (although
the line numbers in the basic_string template file are a bit different).

I try to quote the error message partially so it becomes a bit clearer
what is really going on:

On 01/07/2016 01:12 PM, Andreas Tille wrote:
> /build/ball-1.4.3~beta1/include/BALL/DATATYPE/string.iC: In member function 
> 'BALL::String& BALL::String::insert(BALL::String::const_iterator, 
> std::initializer_list)':
> /build/ball-1.4.3~beta1/include/BALL/DATATYPE/string.iC:1379:19: error: no 
> matching function for call to 
> 'std::__cxx11::basic_string::insert(BALL::String::const_iterator&, 
> std::initializer_list&)'
>   str_.insert(p, li);
>^

(...)

Info:
BALL::String::const_iterator is a typedef for std::string::const_iterator


> /usr/include/c++/5/bits/basic_string.h:1308:7: note: candidate: void 
> std::__cxx11::basic_string<_CharT, _Traits, 
> _Alloc>::insert(std::__cxx11::basic_string<_CharT, _Traits, 
> _Alloc>::iterator, std::   initializer_list<_Tp>) [with _CharT = 
> char; _Traits = std::char_traits; _Alloc = std::allocator; 
> std::__cxx11::basic_string<_CharT, _Traits, _Alloc>::iterator = 
> __gnu_cxx::__normal_iterator >; 
> typename __gnu_cxx::__alloc_traits __gnu_cxx::__alloc_traits<_Alloc>::rebind<_CharT>::other>::pointer = char*]
>insert(iterator __p, initializer_list<_CharT> __l)
>^
> /usr/include/c++/5/bits/basic_string.h:1308:7: note:   no known conversion 
> for argument 1 from 'BALL::String::const_iterator {aka 
> __gnu_cxx::__normal_iterator 
> >}' to 'std::__cxx11::basic_string::iterator {aka 
> __gnu_cxx::__normal_iterator >}'


In essence this says:

(1) No matching function for
string::insert(string::const_iterator, initializer_list),

because (when trying the correct overload),
(2) Cannot convert from string::const_iterator to string::iterator


Which raises the question: Why does the compiler try to convert to a
non-const-iterator in the first place?

According to both cplusplus.com[1] and cppreference.com[2] the insert
function with an initializer_list as second parameter should take a
*const_*iterator directly.

I have condensed this into a simple test case (see attached string.cc)
and for me, this testcase fails in the same way as ball when called with
GCC.

Try it like this:

g++ -std=c++11 string.cc -o string && ./string
(long error message)

Now, with clang++ this fails too:

clang++ -std=c++11 string.cc -o string && ./string
(a bit shorter error message, but essentially the same)

However, if I try the example using clang's STL implementation (from
debian package libc++-dev) it builds *and runs* as expected:

clang++ -std=c++11 -stdlib=libc++ string.cc -o string && ./string
(outputs "Some new string")


I am not sure how to continue from here - this might be a bug in clang's
or gcc's std::string implementation, unportable usage from upstream, or
any number of other things.  If you have access to other compilers, it
may help to test the snippet on them too and report the results.

For reference:

$ g++ -dumpversion
5.3.1

-> Does not compile, cannot convert const_iterator->iterator
-> libstdc++-5-dev 5.3.1-5

$ clang++ -dumpversion
4.2.1

-> Does not compile with default/gcc STL implementation
-> Compiles and runs with libc++-dev 3.7.0-1


I hope this helps in resolving this, or at least in figuring out *where*
the issue actually is located.

- Danny


[1]: http://www.cplusplus.com/reference/string/string/insert/
[2]: http://en.cppreference.com/w/cpp/string/basic_string/insert
#include 
#include 

using namespace std;

int main(){
	string s = "Somestring";
	string::const_iterator ci = s.cbegin()+4;
	initializer_list il = { ' ', 'n', 'e', 'w' , ' ' };
	s.insert(ci, il);
	cout << s << endl;
	return 0;
}

Bug#810691: backuppc: unowned files after purge (policy 6.8, 10.8): /etc/backuppc/{htpasswd, pc}

[Andreas Beckmann]

Package: backuppc
Version: 3.3.1-2
Severity: important
User: debian...@lists.debian.org
Usertags: piuparts

Hi,

during a test with piuparts I noticed your package left unowned files on
the system after purge, which is a violation of policy 6.8 (or 10.8):

https://www.debian.org/doc/debian-policy/ch-maintainerscripts.html#s-removedetails

Filing this as important as having a piuparts clean archive is a release
goal since lenny.

>From the attached log (scroll to the bottom...):

1m20.0s ERROR: FAIL: Package purging left files on system:
  /etc/backuppc/ owned by: backuppc
  /etc/backuppc/htpasswd not owned
  /etc/backuppc/pc -> /etc/backuppc  not owned


cheers,

Andreas


backuppc_3.3.1-2.log.gz
Description: application/gzip

Bug#810692: python3-twisted: unowned files after purge (policy 6.8, 10.8): /usr/lib/python3/dist-packages/twisted/plugins/dropin.cache

[Andreas Beckmann]

Package: python3-twisted
Version: 15.5.0-4
Severity: important
User: debian...@lists.debian.org
Usertags: piuparts

Hi,

during a test with piuparts I noticed your package left unowned files on
the system after purge, which is a violation of policy 6.8 (or 10.8):

https://www.debian.org/doc/debian-policy/ch-maintainerscripts.html#s-removedetails

Filing this as important as having a piuparts clean archive is a release
goal since lenny.

>From the attached log (scroll to the bottom...):

0m43.5s ERROR: FAIL: Package purging left files on system:
  /usr/lib/python3/dist-packages/twisted/owned by: python3-twisted
  /usr/lib/python3/dist-packages/twisted/plugins/owned by: 
python3-twisted
  /usr/lib/python3/dist-packages/twisted/plugins/dropin.cachenot owned


cheers,

Andreas


python3-twisted_15.5.0-4.log.gz
Description: application/gzip

Bug#810693: Versionless Metapackage

[Michael D]

Package: linux-grsec

Corsac, in reference to https://www.corsac.net/?rub=blog&post=1583 I would
like to see some versionless metapackages that we can use to replace
linux-image-amd64.

Thanks for your work on this project and I hope it will eventually drive up
the popularity of grsecurity once it reaches testing. On that note, if
someone can sponsor access to grsecurity stable for Debian there should be
no issues continuing forward due to the patches being GPL.

Thanks.

Bug#810694: west-chamber-dkms: does not clean after module build

[Andreas Beckmann]

Package: west-chamber-dkms
Version: 20100405+svn2007.r124-5
Severity: serious
User: debian...@lists.debian.org
Usertags: piuparts

Hi,

during a test with piuparts I noticed your package left unowned files on
the system after purge, which is a violation of policy 6.8 (or 10.8):

https://www.debian.org/doc/debian-policy/ch-maintainerscripts.html#s-removedetails

This looks like only a partial cleaning is performed after a
module build, which could cause problems when building for a
different kernel later on.

>From the attached log (scroll to the bottom...):

2m41.3s ERROR: FAIL: Package purging left files on system:
  /usr/src/west-chamber-20100405+svn2007.r124/   owned by: 
west-chamber-dkms
  /usr/src/west-chamber-20100405+svn2007.r124/extensions/owned by: 
west-chamber-dkms
  
/usr/src/west-chamber-20100405+svn2007.r124/extensions/.compat_xtables.o.cmd
   not owned
  /usr/src/west-chamber-20100405+svn2007.r124/extensions/.tmp_versions/ 
 not owned
  
/usr/src/west-chamber-20100405+svn2007.r124/extensions/.tmp_versions/compat_xtables.mod
not owned
  /usr/src/west-chamber-20100405+svn2007.r124/extensions/compat_xtables.o   
 not owned


cheers,

Andreas


west-chamber-dkms_20100405+svn2007.r124-5.log.gz
Description: application/gzip

Bug#810695: vim-ultisnips: unowned directories after purge: /var/lib/vim/addons/**/

[Andreas Beckmann]

Package: vim-ultisnips
Version: 3.1-2
Severity: important
User: debian...@lists.debian.org
Usertags: piuparts

Hi,

during a test with piuparts I noticed your package left unowned
directories on the system after purge, which is a violation of
policy 6.8:

https://www.debian.org/doc/debian-policy/ch-maintainerscripts.html#s-removedetails

Filing this as important as having a piuparts clean archive is a release
goal since lenny.

The maintainer scripts create (and later remove) a file in that
directory. Manual directory removal may be not appropriate as this
directory is shared between several packages.

If the package would ship this as an empty directory, dpkg would take
care of the creation and removal (if it's empty).

>From the attached log (scroll to the bottom...):

0m56.2s ERROR: FAIL: Package purging left files on system:
  /var/lib/vim/addons/autoload/  not owned
  /var/lib/vim/addons/pythonx/   not owned
  /var/lib/vim/addons/pythonx/UltiSnips/ not owned
  /var/lib/vim/addons/pythonx/UltiSnips/snippet/ not owned
  /var/lib/vim/addons/rplugin/   not owned
  /var/lib/vim/addons/rplugin/python3/   not owned


cheers,

Andreas


vim-ultisnips_3.1-2.log.gz
Description: application/gzip

Bug#805512: usb-modeswitch-data: Huawei 12d1:1446 does not switch due to bad udev rule

[Josua Dietze]

Am 09.01.2016 um 00:14 schrieb Blake Miner:

Honestly, I did try the whole usbmodeswitch logging thing to no avail


There is only the one global switch in /etc/usb_modeswitch.conf - if that did 
not work, then it's very likely that the dispatcher is never run.

I'll have a closer look at /lib/udev/usb_modeswitch. There may also be systemd 
involved, as I have stated before.


Best regards,
Josh

Bug#810696: Please move state files from /var/ to /run

[Martin Pitt]

Package: open-iscsi
Version: 2.0.873+git0.3b4b4500-12
Tags: patch
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu ubuntu-patch xenial

Hello,

open-iscsi still uses a lot of paths in /var/run and /var/lock/. These
have been symlinks to /run and /run/lock for many Debian releases now.
The problem with using those is that open-isci is typically used
during early boot, but /var might be mounted late (in setups where it
is a remote file system).

Colin Watson fixed this in Ubuntu's open-iscsi about five years ago. I
adjusted the patch to the current Debian version.

Thanks for considering,

Martin

-- 
Martin Pitt| http://www.piware.de
Ubuntu Developer (www.ubuntu.com)  | Debian Developer  (www.debian.org)
diff -Nru open-iscsi-2.0.873+git0.3b4b4500/debian/changelog 
open-iscsi-2.0.873+git0.3b4b4500/debian/changelog
--- open-iscsi-2.0.873+git0.3b4b4500/debian/changelog   2015-10-21 
11:49:30.0 +0200
+++ open-iscsi-2.0.873+git0.3b4b4500/debian/changelog   2016-01-11 
12:18:48.0 +0100
@@ -1,3 +1,10 @@
+open-iscsi (2.0.873+git0.3b4b4500-13) UNRELEASED; urgency=medium
+
+  * Migrate from /var/run /run and from /var/lock to /run/lock. This stops
+depending on /var (which might be on a remote file system).
+
+ -- Martin Pitt   Mon, 11 Jan 2016 12:17:42 +0100
+
 open-iscsi (2.0.873+git0.3b4b4500-12) unstable; urgency=low
 
   [ Christian Perrier ]
diff -Nru open-iscsi-2.0.873+git0.3b4b4500/debian/extra/logout-all.sh 
open-iscsi-2.0.873+git0.3b4b4500/debian/extra/logout-all.sh
--- open-iscsi-2.0.873+git0.3b4b4500/debian/extra/logout-all.sh 2015-10-21 
11:49:30.0 +0200
+++ open-iscsi-2.0.873+git0.3b4b4500/debian/extra/logout-all.sh 2016-01-11 
12:16:06.0 +0100
@@ -7,7 +7,7 @@
 #
 
 ISCSIADM=/sbin/iscsiadm
-PIDFILE=/var/run/iscsid.pid
+PIDFILE=/run/iscsid.pid
 
 ISCSI_ROOT_KEEP_ALL_SESSIONS_AT_SHUTDOWN=0
 if [ -f /etc/default/open-iscsi ]; then
diff -Nru open-iscsi-2.0.873+git0.3b4b4500/debian/iscsid.init 
open-iscsi-2.0.873+git0.3b4b4500/debian/iscsid.init
--- open-iscsi-2.0.873+git0.3b4b4500/debian/iscsid.init 2015-10-21 
11:49:30.0 +0200
+++ open-iscsi-2.0.873+git0.3b4b4500/debian/iscsid.init 2016-01-11 
12:15:47.0 +0100
@@ -21,7 +21,7 @@
 
 DESC="iSCSI initiator daemon"
 DAEMON=/sbin/iscsid
-PIDFILE=/var/run/iscsid.pid
+PIDFILE=/run/iscsid.pid
 OMITDIR=/run/sendsigs.omit.d
 
 do_start_prepare() {
diff -Nru open-iscsi-2.0.873+git0.3b4b4500/debian/iscsid.service 
open-iscsi-2.0.873+git0.3b4b4500/debian/iscsid.service
--- open-iscsi-2.0.873+git0.3b4b4500/debian/iscsid.service  2015-10-21 
11:49:30.0 +0200
+++ open-iscsi-2.0.873+git0.3b4b4500/debian/iscsid.service  2016-01-11 
12:15:39.0 +0100
@@ -10,7 +10,7 @@
 
 [Service]
 Type=forking
-PIDFile=/var/run/iscsid.pid
+PIDFile=/run/iscsid.pid
 ExecStartPre=/lib/open-iscsi/startup-checks.sh
 ExecStart=/sbin/iscsid
 ExecStop=/sbin/iscsiadm -k 0 2
diff -Nru open-iscsi-2.0.873+git0.3b4b4500/debian/open-iscsi.init 
open-iscsi-2.0.873+git0.3b4b4500/debian/open-iscsi.init
--- open-iscsi-2.0.873+git0.3b4b4500/debian/open-iscsi.init 2015-10-21 
11:49:30.0 +0200
+++ open-iscsi-2.0.873+git0.3b4b4500/debian/open-iscsi.init 2016-01-11 
12:14:51.0 +0100
@@ -13,7 +13,7 @@
 PATH=/sbin:/bin
 DAEMON=/sbin/iscsid
 ADM=/sbin/iscsiadm
-PIDFILE=/var/run/iscsid.pid
+PIDFILE=/run/iscsid.pid
 NAMEFILE=/etc/iscsi/initiatorname.iscsi
 CONFIGFILE=/etc/iscsi/iscsid.conf
 OMITDIR=/run/sendsigs.omit.d
diff -Nru 
open-iscsi-2.0.873+git0.3b4b4500/debian/patches/06_var-lock_var-run_transition 
open-iscsi-2.0.873+git0.3b4b4500/debian/patches/06_var-lock_var-run_transition
--- 
open-iscsi-2.0.873+git0.3b4b4500/debian/patches/06_var-lock_var-run_transition  
1970-01-01 01:00:00.0 +0100
+++ 
open-iscsi-2.0.873+git0.3b4b4500/debian/patches/06_var-lock_var-run_transition  
2016-01-11 12:17:39.0 +0100
@@ -0,0 +1,110 @@
+Description: Move from /var/lock and /var/run to /run/lock and /run
+Author: Stéphane Graber 
+
+Index: open-iscsi-2.0.873+git0.3b4b4500/doc/iscsid.8
+===
+--- open-iscsi-2.0.873+git0.3b4b4500.orig/doc/iscsid.8
 open-iscsi-2.0.873+git0.3b4b4500/doc/iscsid.8
+@@ -40,7 +40,7 @@ do not write a process ID file.
+ .TP
+ .BI [-p|--pid=]\fIpid\-file\fP
+ write process ID to \fIpid\-file\fR rather than the default
+-\fI/var/run/iscsid.pid\fR
++\fI/run/iscsid.pid\fR
+ .TP
+ .BI [-h|--help]
+ display this help and exit
+Index: open-iscsi-2.0.873+git0.3b4b4500/usr/initiator.h
+===
+--- open-iscsi-2.0.873+git0.3b4b4500.orig/usr/initiator.h
 open-iscsi-2.0.873+git0.3b4b4500/usr/initiator.h
+@@ -38,9 +38,9 @@
+ #define CONFIG_FILE   ISCSI_CONFIG_ROOT"iscsid.conf"
+ #define INITIATOR_NAME_FILE   ISCSI_CONFIG_ROOT"initiatorname.iscsi"
+ 
+-#define PID_FILE  "/var/run/iscsid.pid"
++#define PID_FILE  

Bug#810697: fwupdate: unowned files after purge (policy 6.8, 10.8): /var/cache/fwupdate/done

[Andreas Beckmann]

Package: fwupdate
Version: 0.5-1
Severity: important
User: debian...@lists.debian.org
Usertags: piuparts

Hi,

during a test with piuparts I noticed your package left unowned files on
the system after purge, which is a violation of policy 6.8 (or 10.8):

https://www.debian.org/doc/debian-policy/ch-maintainerscripts.html#s-removedetails

Filing this as important as having a piuparts clean archive is a release
goal since lenny.

>From the attached log (scroll to the bottom...):

0m40.1s ERROR: FAIL: Package purging left files on system:
  /boot/efi/ not owned
  /boot/efi/EFI/ not owned
  /boot/efi/EFI/fw/  not owned
  /var/cache/fwupdate/   owned by: fwupdate
  /var/cache/fwupdate/done   not owned

I'm not exactly sure how the hierarchy under /boot/efi/
should be handled, but the stamp file has to be cleaned up.


cheers,

Andreas


fwupdate_0.5-1.log.gz
Description: application/gzip

Bug#810698: yrmcds: unowned files after purge (policy 6.8, 10.8): /etc/init/yrmcds.override

[Andreas Beckmann]

Package: yrmcds
Version: 1.1.5-1
Severity: important
User: debian...@lists.debian.org
Usertags: piuparts

Hi,

during a test with piuparts I noticed your package left unowned files on
the system after purge, which is a violation of policy 6.8 (or 10.8):

https://www.debian.org/doc/debian-policy/ch-maintainerscripts.html#s-removedetails

Filing this as important as having a piuparts clean archive is a release
goal since lenny.

>From the attached log (scroll to the bottom...):

0m34.0s ERROR: FAIL: Package purging left files on system:
  /etc/init/yrmcds.override  not owned


cheers,

Andreas


yrmcds_1.1.5-1.log.gz
Description: application/gzip

Bug#810699: pnp4nagios-web: Does not show images via web - extra "\n\n\n\n\n\" before PNG header

[Max Kosmach]

Package: pnp4nagios-web
Version: 0.6.24+dfsg1-4
Severity: important

Hi

pnp4nagios-web 0.6.24+dfsg1-4 does not work for me.

All browsers shows errors on any images from pnp4nagios

If I try to get image via curl I see

curl -s 
"http://127.0.0.1/pnp4nagios/image?host=localhost&srv=CPU_utilization&theme=multisite&baseurl=.."%"2Fcheck_mk"%"2F&view=0&source=0&start=1452248124&end=1452262524"; 
-H "Authorization: Basic " |hexdump  -C


  0a 0a 0a 0a 0a 89 50 4e  47 0d 0a 1a 0a 00 00 00  |..PNG...|
0010  0d 49 48 44 52 00 00 02  55 00 00 00 bb 08 02 00  |.IHDR...U...|
0020  00 00 c3 b5 fc 3e 00 00  00 06 62 4b 47 44 00 ff  |.>bKGD..|
0030  00 ff 00 ff a0 bd a7 93  00 00 20 00 49 44 41 54  |.. .IDAT|
0040  78 9c ed 9d 79 5c 15 55  ff c7 cf 65 11 2d 40 14  |x...y\.U...e.-@.|
0050  f0 0a 28 0a 48 2e 2c a6  50 29 8f c5 a2 22 8f a6  |..(.H.,.P)..."..|


I think PNG header is wrong -  see 5 x 0x0a before real PNG

rrdtool generates correct PNG header

echo " graph --daemon=unix:/var/run/rrdcached.sock -  --width=500 --height=100 --start 1452248124 --end 1452262524  --vertical-label 'CPU utilization 
%' -l0  -u 100 --title \"CPU Utilization for localhost\"  DEF:user=/var/lib/pnp4nagios/perfdata/localhost/CPU_utilization.rrd:1:AVERAGE 
DEF:system=/var/lib/pnp4nagios/perfdata/localhost/CPU_utilization.rrd:2:AVERAGE 
DEF:wait=/var/lib/pnp4nagios/perfdata/localhost/CPU_utilization.rrd:3:AVERAGE CDEF:us=user,system,+ CDEF:sum=us,wait,+ CDEF:idle=100,sum,- 
COMMENT:Average\\:  AREA:system#ff6000:\"System\" GPRINT:system:AVERAGE:\"%4.1lf%%  \" AREA:user#60f020:\"User\":STACK GPRINT:user:AVERAGE:\"%4.1lf%% 
 \" AREA:wait#00b0c0:\"Wait\":STACK GPRINT:wait:AVERAGE:\"%4.1lf%%  \" LINE:sum#004080:\"Total\" GPRINT:sum:AVERAGE:\"%4.1lf%%  \\n\" 
COMMENT:\"Last\\:   \" AREA:system#ff6000:\"System\" GPRINT:system:LAST:\"%4.1lf%%  \" AREA:user#60f020:\"User\":STACK GPRINT:user:LAST:\"%4.1lf%%  \" 
AREA:wait#00b0c0:\"Wait\":STACK GPRINT:wait:LAST:\"%4.1lf%%  \" LINE:sum#004080:\"Total\" GPRINT:sum:LAST:\"%4.1lf%%  \\n\" " |/usr/bin/rrdtool - 
|hexdump  -C |head -n 5


  89 50 4e 47 0d 0a 1a 0a  00 00 00 0d 49 48 44 52  |.PNGIHDR|
0010  00 00 02 55 00 00 00 bb  08 02 00 00 00 c3 b5 fc  |...U|
0020  3e 00 00 00 06 62 4b 47  44 00 ff 00 ff 00 ff a0  |>bKGD...|
0030  bd a7 93 00 00 20 00 49  44 41 54 78 9c ed 9d 79  |. .IDATx...y|
0040  58 14 47 fe ff 6b 40 54  12 86 43 18 c6 01 44 01  |X.G..k@T..C...D.|

So I don't know where pnp4nagios insert this "\n\n\n\n\n\"


PS. I use
libkohana2-php 2.3.4-2
libapache2-mod-php5/php5-cgi 5.6.17+dfsg-1
rrdtool 1.5.5-3+b1


--
With best wishes
Max

Bug#721149: fixed since a long time

[Andreas Henriksson]

Control: fixed -1 2.88dsf-59

The reported issue should be fixed since
http://anonscm.debian.org/cgit/collab-maint/sysvinit.git/commit/debian/service/service?id=fbf700964e86953d2c573229c39482db0b9e1eb7
which instead requires the init scripts to print the "usage:" string if
it does not support status.

Regards,
Andreas Henriksson

Bug#810700: gnocchi-common: unowned directories after purge: /var/{lib,log}/gnocchi/*

[Andreas Beckmann]

Package: gnocchi-common
Version: 1.3.0-4
Severity: important
User: debian...@lists.debian.org
Usertags: piuparts

Hi,

during a test with piuparts I noticed your package left unowned
directories on the system after purge, which is a violation of
policy 6.8:

https://www.debian.org/doc/debian-policy/ch-maintainerscripts.html#s-removedetails

Filing this as important as having a piuparts clean archive is a release
goal since lenny.

The maintainer scripts create (and later remove) a file in that
directory. Manual directory removal may be not appropriate as this
directory is shared between several packages.

If the package would ship this as an empty directory, dpkg would take
care of the creation and removal (if it's empty).

>From the attached log (scroll to the bottom...):

3m13.6s ERROR: FAIL: Package purging left files on system:
  /var/lib/gnocchi/  not owned
  /var/lib/gnocchi/cache/not owned
  /var/log/gnocchi/  not owned


cheers,

Andreas


gnocchi-common_1.3.0-4.log.gz
Description: application/gzip

Bug#810576: ITP: hail -- Efficiently extract arbitrary lines from a file or stream

[Lars Wirzenius]

I'm not objecting to this package, but for those who want achieve what
it does without having to depend on an extra package, I offer the
following.

On Sun, Jan 10, 2016 at 10:17:22AM +1100, Kevin Murray wrote:
> Hail gets its name from a contraction of head and tail, the common alternative
> to this program. It extracts lines from a file, taken on stdin, and prints 
> them
> on stdout. It's so simple that the Unix wizards of old never bothered.

The README gives the following examples:

# prints 1 through 10, i.e. does nothing
seq 1 10 | hail 1-

# prints 1 through 3, i.e. equivalent to `head -n 3`
seq 1 10 | hail 1-3

# prints 3 through 5, i.e. equivalent to `head -n 5 | tail -n 3`
seq 1 10 | hail 3-5

# prints 5 through 10, i.e. equivalent to `tail -n 6`
seq 1 10 | hail 5-

# prints 2, 3, 5 and 7, which is where I'll give up on my comparisons to
# head and tail
seq 1 10 | hail 2-3 5-5 7-7

These can be done with sed:

seq 1 10 | sed -n '1,$p'
seq 1 10 | sed -n '1,3p'
seq 1 10 | sed -n '3,5p'
seq 1 10 | sed -n '5,$p'
seq 1 10 | sed -n '2,3p;5p;7p'

The syntax is not quite as easy, of course.

Happy hacking.

-- 
Schrödinger's backup hypothesis: the condition of any backup is
undefined until a restore is attempted. -- andrewsh


signature.asc
Description: Digital signature

Bug#810701: debci: unowned directory after purge: /var/log/debci/

[Andreas Beckmann]

Package: debci
Version: 1.0.1
Severity: important
User: debian...@lists.debian.org
Usertags: piuparts

Hi,

during a test with piuparts I noticed your package left unowned
directories on the system after purge, which is a violation of
policy 6.8:

https://www.debian.org/doc/debian-policy/ch-maintainerscripts.html#s-removedetails

Filing this as important as having a piuparts clean archive is a release
goal since lenny.

The maintainer scripts create (and later remove) a file in that
directory. Manual directory removal may be not appropriate as this
directory is shared between several packages.

If the package would ship this as an empty directory, dpkg would take
care of the creation and removal (if it's empty).

>From the attached log (scroll to the bottom...):

0m59.3s ERROR: FAIL: Package purging left files on system:
  /var/log/debci/not owned


cheers,

Andreas


debci_1.0.1.log.gz
Description: application/gzip

Bug#803861: spek: FTBFS with FFmpeg 2.9

[Andreas Cadhalpun]

Hi Alexander,

On 11.01.2016 03:49, Alexander Kojevnikov wrote:
> On Sun, Jan 10, 2016 at 2:14 AM, Andreas Cadhalpun
>  wrote:
>>
>> [...]
>>
>>> feel free to update and NMU the Debian package.
>>
>> I think it would be better if you made a maintainer upload,
>> as the package otherwise looks a bit unmaintained with only
>> two NMUs in the last two years...
>> (I'm sure Felipe Sateler would be willing to sponsor such an upload,
>> like he did for dvbcut[1].)
> 
> Felipe, could you sponsor the upload? It's on m.d.n:
> http://mentors.debian.net/package/spek

Thanks for preparing the upload. I confirm that it builds with FFmpeg
from git master.

There are two things that would be nice to get fixed, though:
 * obsolete-url-in-packaging: The watchfile should use github instead
   of the obsolete code.google.com.
 * FFmpeg upstream introduced new deprecations in git master,
   in particular deprecating av_free_packet in favor of av_packet_unref.
   Since the replacement has been available already since quite some
   time (libavcodec 55.25.100 / 55.16.0) it would be nice if you
   would use it. That way spek should be API compatible with FFmpeg
   for at least the next two years. Patch:
--- spek-0.8.2.orig/src/spek-audio.cc
+++ spek-0.8.2/src/spek-audio.cc
@@ -224,7 +224,7 @@ AudioFileImpl::~AudioFileImpl()
 this->packet.data -= this->offset;
 this->packet.size += this->offset;
 this->offset = 0;
-av_free_packet(&this->packet);
+av_packet_unref(&this->packet);
 }
 if (this->format_context) {
 if (this->audio_stream >= 0) {
@@ -299,7 +299,7 @@ int AudioFileImpl::read()
 this->packet.data -= this->offset;
 this->packet.size += this->offset;
 this->offset = 0;
-av_free_packet(&this->packet);
+av_packet_unref(&this->packet);
 }
 
 int res = 0;
@@ -307,7 +307,7 @@ int AudioFileImpl::read()
 if (this->packet.stream_index == this->audio_stream) {
 break;
 }
-av_free_packet(&this->packet);
+av_packet_unref(&this->packet);
 }
 if (res < 0) {
 // End of file or error.

Best regards,
Andreas

Bug#810702: Generate initiator name on install, not first boot

[Martin Pitt]

Package: open-iscsi
Version: 2.0.873+git0.3b4b4500-12
Tags: patch
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu ubuntu-patch xenial

Hello,

In https://launchpad.net/bugs/1057635 it was reported that an
initramfs built during install does not contain a valid iscsi
initiator name. This is because /etc/iscsi/initiatorname.iscsi is
currently created by the init scripts, not the postinst. Thus if d-i
installs open-iscsi, or if you build an OS in a schroot, this will
never happen and the built initramfs will contain only the dummy
initiatorname.iscsi.

James Page fixed this a few years ago in Ubuntu, I adjusted the patch
to the current Debian version.

Disclaimer: I don't know much about open-iscsi, I'm just looking into
our delta and see what's still relevant and what would be beneficial
to Debian too.

Thanks for considering,

Martin

-- 
Martin Pitt| http://www.piware.de
Ubuntu Developer (www.ubuntu.com)  | Debian Developer  (www.debian.org)
diff -Nru open-iscsi-2.0.873+git0.3b4b4500/debian/changelog 
open-iscsi-2.0.873+git0.3b4b4500/debian/changelog
--- open-iscsi-2.0.873+git0.3b4b4500/debian/changelog   2015-10-21 
11:49:30.0 +0200
+++ open-iscsi-2.0.873+git0.3b4b4500/debian/changelog   2016-01-11 
12:39:48.0 +0100
@@ -1,3 +1,12 @@
+open-iscsi (2.0.873+git0.3b4b4500-13) UNRELEASED; urgency=medium
+
+  * debian/open-iscsi.postinst: Generate initiator name on install, not first
+boot, ensuring that the initramfs built during install contains a valid
+iSCSI initiator name resulting in a iSCSI based root volume that will
+actually boot. Drop debian/initiatorname.iscsi stub. (LP: #1057635)
+
+ -- Martin Pitt   Mon, 11 Jan 2016 12:38:07 +0100
+
 open-iscsi (2.0.873+git0.3b4b4500-12) unstable; urgency=low
 
   [ Christian Perrier ]
diff -Nru open-iscsi-2.0.873+git0.3b4b4500/debian/initiatorname.iscsi 
open-iscsi-2.0.873+git0.3b4b4500/debian/initiatorname.iscsi
--- open-iscsi-2.0.873+git0.3b4b4500/debian/initiatorname.iscsi 2015-08-20 
15:51:06.0 +0200
+++ open-iscsi-2.0.873+git0.3b4b4500/debian/initiatorname.iscsi 1970-01-01 
01:00:00.0 +0100
@@ -1 +0,0 @@
-GenerateName=yes
diff -Nru open-iscsi-2.0.873+git0.3b4b4500/debian/open-iscsi.install 
open-iscsi-2.0.873+git0.3b4b4500/debian/open-iscsi.install
--- open-iscsi-2.0.873+git0.3b4b4500/debian/open-iscsi.install  2015-10-21 
11:49:30.0 +0200
+++ open-iscsi-2.0.873+git0.3b4b4500/debian/open-iscsi.install  2016-01-11 
12:40:21.0 +0100
@@ -4,7 +4,6 @@
 usr/iscsistart /sbin
 utils/iscsi_discovery  /sbin
 utils/iscsi-iname  /sbin
-debian/initiatorname.iscsi /etc/iscsi
 etc/iscsid.conf/etc/iscsi
 debian/extra/initramfs.hook => /usr/share/initramfs-tools/hooks/iscsi
 debian/extra/initramfs.local-top=> 
/usr/share/initramfs-tools/scripts/local-top/iscsi
diff -Nru open-iscsi-2.0.873+git0.3b4b4500/debian/open-iscsi.postinst 
open-iscsi-2.0.873+git0.3b4b4500/debian/open-iscsi.postinst
--- open-iscsi-2.0.873+git0.3b4b4500/debian/open-iscsi.postinst 2015-10-21 
11:49:30.0 +0200
+++ open-iscsi-2.0.873+git0.3b4b4500/debian/open-iscsi.postinst 2016-01-11 
12:38:05.0 +0100
@@ -68,6 +68,30 @@
rmdir --ignore-fail-on-non-empty /var/lib/open-iscsi
fi
 
+# generate a unique iSCSI InitiatorName
+NAMEFILE=/etc/iscsi/initiatorname.iscsi
+if [ ! -e $NAMEFILE ] && [ -z "$2" ] ; then
+if [ ! -x /usr/sbin/iscsi-iname ] ; then
+echo "Error: /usr/sbin/iscsi-iname does not exist, driver was 
not successfully installed"
+exit 1;
+fi
+# Generate a unique InitiatorName and save it
+INAME=`/usr/sbin/iscsi-iname -p iqn.1993-08.org.debian:01`
+if [ "$INAME" != "" ] ; then
+echo "## DO NOT EDIT OR REMOVE THIS FILE!" > $NAMEFILE
+echo "## If you remove this file, the iSCSI daemon will not 
start." >> $NAMEFILE
+echo "## If you change the InitiatorName, existing access 
control lists" >> $NAMEFILE
+echo "## may reject this initiator.  The InitiatorName must be 
unique">> $NAMEFILE
+echo "## for each iSCSI initiator.  Do NOT duplicate iSCSI 
InitiatorNames." >> $NAMEFILE
+printf "InitiatorName=$INAME\n"  >> $NAMEFILE
+chmod 600 $NAMEFILE
+else
+echo "Error: failed to generate an iSCSI InitiatorName, driver 
cannot start."
+echo
+exit 1;
+fi
+fi
+
update_initramfs
 ;;
 

Bug#803448: python{, 3}-django-countries: unowned directory after purge: /usr/share/python{, 3}-django-countries/

[Andreas Beckmann]

Followup-For: Bug #803448
Control: found -1 3.4.1-2

Hi,

/usr/share/python{,3}-django-countries/
is still left around, the packages should really ship this as an empty
directory.


Andreas

Bug#810703: caml-crush-server: unowned directory after purge: /var/lib/pkcs11proxyd/

[Andreas Beckmann]

Package: caml-crush-server
Version: 1.0.7-1
Severity: important
User: debian...@lists.debian.org
Usertags: piuparts

Hi,

during a test with piuparts I noticed your package left unowned
directories on the system after purge, which is a violation of
policy 6.8:

https://www.debian.org/doc/debian-policy/ch-maintainerscripts.html#s-removedetails

Filing this as important as having a piuparts clean archive is a release
goal since lenny.

The maintainer scripts create (and later remove) a file in that
directory. Manual directory removal may be not appropriate as this
directory is shared between several packages.

If the package would ship this as an empty directory, dpkg would take
care of the creation and removal (if it's empty).

>From the attached log (scroll to the bottom...):

0m39.4s ERROR: FAIL: Package purging left files on system:
  /var/lib/pkcs11proxyd/ not owned


cheers,

Andreas


caml-crush-server_1.0.7-1.log.gz
Description: application/gzip

Bug#810704: xinetd: unowned files after purge (policy 6.8, 10.8): /etc/init/xinetd.override

[Andreas Beckmann]

Package: xinetd
Version: 1:2.3.15-5
Severity: important
User: debian...@lists.debian.org
Usertags: piuparts

Hi,

during a test with piuparts I noticed your package left unowned files on
the system after purge, which is a violation of policy 6.8 (or 10.8):

https://www.debian.org/doc/debian-policy/ch-maintainerscripts.html#s-removedetails

Filing this as important as having a piuparts clean archive is a release
goal since lenny.

>From the attached log (scroll to the bottom...):

0m54.4s ERROR: FAIL: Package purging left files on system:
  /etc/init/xinetd.override  not owned


cheers,

Andreas


xinetd_1:2.3.15-5.log.gz
Description: application/gzip

Bug#810705: neutron-l2gateway-agent: unowned files after purge (policy 6.8, 10.8): /etc/init/neutron-l2gateway-agent.override

[Andreas Beckmann]

Package: neutron-l2gateway-agent
Version: 2015.1.1+git20151117.4ec821f-1
Severity: important
User: debian...@lists.debian.org
Usertags: piuparts

Hi,

during a test with piuparts I noticed your package left unowned files on
the system after purge, which is a violation of policy 6.8 (or 10.8):

https://www.debian.org/doc/debian-policy/ch-maintainerscripts.html#s-removedetails

Filing this as important as having a piuparts clean archive is a release
goal since lenny.

>From the attached log (scroll to the bottom...):

2m34.8s ERROR: FAIL: Package purging left files on system:
  /etc/init/neutron-l2gateway-agent.override not owned


cheers,

Andreas


neutron-l2gateway-agent_2015.1.1+git20151117.4ec821f-1.log.gz
Description: application/gzip

Bug#810693: Versionless Metapackage

[Yves-Alexis Perez]

On lun., 2016-01-11 at 11:18 +, Michael D wrote:
> Package: linux-grsec
> 
> Corsac, in reference to https://www.corsac.net/?rub=blog&post=1583 I would
> like to see some versionless metapackages that we can use to replace
> linux-image-amd64.

Noted :) Note that it won't replace linux-image-amd64, but it should fit the
same purpose.
> 
> Thanks for your work on this project and I hope it will eventually drive up
> the popularity of grsecurity once it reaches testing.

As already said on the above blog post, linux-grsec won't reach testing.
Testing is a distribution for package supposed to land in the next stable
release, which is not the case for linux-grsec right now.

>  On that note, if
> someone can sponsor access to grsecurity stable for Debian there should be
> no issues continuing forward due to the patches being GPL.

It's not a GPL issue. It's perfectly clear in the stable patches terms of
service that you're *not* supposed to share the patches in the wild.

Regards,
-- 
Yves-Alexis



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

Bug#810693: Versionless Metapackage

[Michael D]

>It's not a GPL issue. It's perfectly clear in the stable patches terms of
service that you're *not* supposed to share the patches in the wild.

Supposed != not allowed. Whilst they could in theory revoke access to
whoever shares them, the GPL cannot be overridden by any such terms of
service or non disclosure agreements.

I would like to see grsec become more mainstream thanks to projects such as
this, but if upstream wants to limit that I guess it's their choice.

Bug#810693: Versionless Metapackage

[Yves-Alexis Perez]

On lun., 2016-01-11 at 12:05 +, Michael D wrote:
> > It's not a GPL issue. It's perfectly clear in the stable patches terms of
> service that you're *not* supposed to share the patches in the wild.
> 
> Supposed != not allowed. Whilst they could in theory revoke access to
> whoever shares them, the GPL cannot be overridden by any such terms of
> service or non disclosure agreements.

I don't want to argue on this, so final point: it's not a GPL issue per se,
it's just that getting access to *one* patch doesn't interest me.
> 
> I would like to see grsec become more mainstream thanks to projects such as
> this, but if upstream wants to limit that I guess it's their choice.

Indeed.
-- 
Yves-Alexis



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

Bug#808956: ruby-hpricot: uninstallable due to file overwrite conflict with direct dependency ruby-fast-xs

[Antonio Terceiro]

Control: forcemerge 806191 -1

On Sun, Jan 10, 2016 at 10:06:49AM +0100, Andreas Beckmann wrote:
> Control: retitle -1 ruby-hpricot: package contains fast_xs.so if built with 
> DEB_BUILD_OPTIONS=nocheck
> Control: tag -1 sid stretch
> 
> On Thu, 24 Dec 2015 20:40:28 + (UTC) Thorsten Glaser  
> wrote:
> > Unpacking ruby-hpricot (0.8.6-5+b1) ...
> > dpkg: error processing archive 
> > /var/cache/apt/archives/ruby-hpricot_0.8.6-5+b1_m68k.deb (--unpack):
> >  trying to overwrite 
> > '/usr/lib/m68k-linux-gnu/ruby/vendor_ruby/2.2.0/fast_xs.so', which is also 
> > in package ruby-fast-xs 0.8.0-3+b1
> 
> At a first glance I thought this is m68k specific ... no release
> architecture contains the conflicting file.
> 
> But it's also reproducible on amd64 if built with nocheck.
> 
> debian/ruby-tests.rb contains
>   system("find -name fast_xs.so -delete")
> which seems to be the wrong place to do this ...

See #806191 for a previous instance of this, and explanation 
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=806191

-- 
Antonio Terceiro 


signature.asc
Description: PGP signature

Bug#810033: package resubmit request

[Breno Leitao]

Hi Keith,

On 01/08/2016 06:16 PM, Busch, Keith wrote:
> I received notification the package was rejected as my email was not a user on
> mentors.debian.net. I’ve signed up on this site today, so I think it’s safe to
> resubmit.
I am sorry about it, I probably need to change the debian maintainer to my 
email,
not yours. You are the upstream maintainer.

I will fix it and resend.

Bug#808953: xhci regression for large transfers (commit e210c422b)

[Mathias Nyman]

On 08.01.2016 17:19, Ron wrote:

On Fri, Jan 08, 2016 at 04:10:09PM +0200, Mathias Nyman wrote:

On 07.01.2016 20:47, Ron wrote:

On Fri, Jan 08, 2016 at 03:09:20AM +1030, Ron wrote:

On Fri, Jan 08, 2016 at 02:52:28AM +1030, Ron wrote:

On Thu, Jan 07, 2016 at 05:38:09PM +0200, Mathias Nyman wrote:

Hi

On 02.01.2016 08:32, Ron wrote:


Hi,

It appears the commit e210c422b6fdd2dc123bedc588f399aefd8bf9de
"xhci: don't finish a TD if we get a short transfer event mid TD"
is causing transfers larger than 16kB to be unreliable.

If I limit transfers to be no larger than 16kB, then it also works as
expected in an XHCI port with an unmodified build of Linus' current
head (v4.4-rc7-76-g9c982e8), but transfers larger than that do not.
I see an alternating cycle of a successful transfer, followed by two
that will time out waiting in libusb (with a 5 second timeout set),
before getting another successful transfer and the cycle repeating.

I can run more tests and dig into this deeper if the reason for it
isn't immediately obvious in hindsight.



Thanks for the info,
I can't spot anything obvious, but my brain might still be in vacation mode.

Could you reproduce it with the attached patch, it only adds extra debugging?

We should either see no output, or the following sequence:

  1. "mid bulk/intr SP, wait for last TRB event"
  2. "last trb has length set"
  3. "and last trb is SHORT_TX, OK"



I guess one out of 3 ain't good ...  all I see logged is:

  [   60.015708] xhci_hcd :04:00.0: mid bulk/intr SP, wait for last TRB 
event
  [   65.017374] xhci_hcd :04:00.0: mid bulk/intr SP, wait for last TRB 
event
  [   70.455451] xhci_hcd :04:00.0: mid bulk/intr SP, wait for last TRB 
event
  [   75.456248] xhci_hcd :04:00.0: mid bulk/intr SP, wait for last TRB 
event

I'm passing 5 seconds to libusb as the requested timeout.


And if I limit the maximum transfer size to 16kB (the above was with
64kB transfers), then I see nothing logged at all.

So if that code does indeed look sane, perhaps the issue is really
in the code that's splitting large transfers doing something funny?


So, tracing this a bit deeper, what I'm seeing is that in the case of
a transfer of 16kB or less, there's only one TRB in the TD, so it's
always the last_trb and the wait code never triggers (ie. basically
the same code path as with this patch reverted).

In the case of a larger transfer, there are N / 16kB TRBs in the TD,
and in the case where it stalls, I get a short transfer on the first
TRB, and then it just hangs waiting until it times out, reporting:

  xhci_hcd ep 0x81 - asked for 65536 bytes, 16382 bytes untransferred

with event_trb == td->first_trb.


What's still not clear to me yet is which assumption is broken.
Clearly we aren't actually getting more TRB events after the short
transfer.

And the other thing which possibly makes this odd is that the FTDI will
always return 2 bytes in a packet, even when there "no data" in it,
since it prefixes each packet with 2 "modem status" bytes.  Which means
the 16382 untransferred above is it returning 2 status bytes and none
of the data that we actually requested from it (which is a normal thing
for it to do sometimes, and if we issue another read the data will
eventually come - but I don't yet know if that's also contributing here).


Sorry for the trickle of small facts, I'm still wrapping my head around
everything I need to know to understand this properly.



This is all good information.

We mark all TRBs for incoming bulk transfers as "interrupt on short transfer"
and the last TRB of the TD as "interrupt on completion"

If the we get a short packet event mid TD xhc should create two events, the 
first
one for the trb that was short, and a second one one the last trb, with the 
"interrupt on completion"


There is one thing we need to be careful of here, with the FTDI at least.
Once we get a short packet, we do actually need to end the transaction
there and not append any further data to it.  The reason for that is
those modem status bytes.  The only way to find them and filter them from
the actual data you want is to split the received transfer back into
wMaxPacketSize'd blocks and remove the first 2 bytes from each packet,
since it prepends them to every packet.

If a subsequent trb after the short was to add more data to that, we'd
lose that framing and not be able to extract the data from it reliably
(since we wouldn't know where the short in the middle ended).

I'm not sure if the events we expect in this case already cover that,
but it seemed worth mentioning in case they might return more data.


There was an errata added to the specs specifying in more detail what this 
second events status should be,
but the second event should be there anyways. controller will "fast forward" 
through the remains of the TD after
a short packet, generating the event.


If I understand that part though, then we shouldn't actually get more
data, just a final completion event for t

Bug#807579: Acknowledgement ([patch] CUDA 7.5 works well with GCC5, while CUDA 7.0 fails to.)

[Breno Leitao]

> Architectures supported are X86_64 and ppc64le.
Correct. We are testing this ppc64le binaries and they are working fine on Power
architecture.

> I've almost forgot the ppc64el stuff until you reminded me that.
> the deb file for ppc64el is of size ~1GB.
Yes. Do you need any help here?

Bug#810706: RM: avbin -- RoQA; unmaintained, outdated, FTBFS with ffmpeg 2.9/3.0

[Andreas Cadhalpun]

Package: ftp.debian.org
Severity: normal

Hi,

avbin has only ever seen one maintainer upload (in 2009) and since
then required constant QA work (the following 8 uploads).
Now it would need an update for FFmpeg API changes (#803800).

The current upstream version is 10 (from 2012), while we still have
version 7 in the archive.
Thus the removal of avbin was suggested two years ago in #741935.
It has been orphaned meanwhile.

The only user of avbin, psychopy, found sufficient alternatives [1].

Since avbin is already not in testing or stable it's of not much use
to keep it in unstable either. So please remove it.

Best regards,
Andreas


1: https://bugs.debian.org/741935#56

Bug#741935: Bug#803800: avbin: FTBFS with FFmpeg 2.9

[Andreas Cadhalpun]

Hi Jon,

On 11.01.2016 11:24, Jonathan Peirce wrote:
> Thanks for the note Andreas. I think for the psychopy package we now
> have sufficient alternatives that we can live without avbin.

Thanks for the confirmation. I requested the removal of avbin now
in bug #810706 [1].

Best regards,
Andreas


1: https://bugs.debian.org/810706

Bug#784734: /usr/bin/column: Re: column segfaults on jessie

[Ph. Marek]

Package: bsdmainutils
Version: 9.0.6+b1
Followup-For: Bug #784734

I don't believe that it's *just* the stack size:

$ column
Segmentation fault
$ ulimit -a
core file size  (blocks, -c) 0
data seg size   (kbytes, -d) 90
scheduling priority (-e) 0
file size   (blocks, -f) unlimited
pending signals (-i) 44301
max locked memory   (kbytes, -l) 2097144
max memory size (kbytes, -m) 100
open files  (-n) 65536
pipe size(512 bytes, -p) 8
POSIX message queues (bytes, -q) 819200
real-time priority  (-r) 95
stack size  (kbytes, -s) 1024
cpu time   (seconds, -t) unlimited
max user processes  (-u) 44301
virtual memory  (kbytes, -v) unlimited
file locks  (-x) unlimited

1M stack size should be reasonable, shouldn't it?

Bug#810708: twinkle: Uses deprecated Qt Quick 1

[Dmitry Shachnev]

Source: twinkle
Version: 1:1.9.0+dfsg-2
Tags: fixed-upstream
Forwarded: https://github.com/LubosD/twinkle/issues/52

Twinke currently uses Qt Quick 1 (src:qtquick1-opensource-src) which is no
longer developed and won't be part of Qt 5.6 release.

Please port this package to Qt Quick 2 (src:qtdeclarative-opensource-src) so
that it works with Qt 5.6.

I have filed a bug upstream about this and they already fixed it.

--
Dmitry Shachnev

signature.asc
Description: OpenPGP digital signature

Bug#810707: libdbd-sqlite3-perl: FTBFS: t/virtual_table/21_perldata_charinfo.t (Wstat: 512 Tests: 4 Failed: 1)

[Chris Lamb]

Source: libdbd-sqlite3-perl
Version: 1.46-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,

libdbd-sqlite3-perl fails to build from source in unstable/amd64:

  [..]

  t/virtual_table/20_perldata.t . 
  1..29
  ok 1 - An object of class 'DBI::db' isa 'DBI::db'
  ok 2 - create_module
  ok 3 - create vtable
  ok 4 - got 3 rows
  ok 5 - got 1 in a
  ok 6 - got 2 in b
  ok 7 - got 2 rows
  ok 8 - got 4 in first a
  ok 9 - got 1 in second a
  ok 10 - SELECT rowid FROM vtb WHERE c = 'six'
  ok 11 - SELECT c FROM vtb WHERE c MATCH 'i' ORDER BY c
  ok 12 - new rowid is 3
  ok 13 - perl_rows expanded
  ok 14 - new row is correct
  ok 15 - create vtable
  ok 16 - got 2 rows
  ok 17 - got 4 in first a
  ok 18 - got 1 in second a
  ok 19 - create vtable intarray
  ok 20 - SELECT i FROM intarray WHERE i BETWEEN 0 AND 5
  ok 21 - INSERT INTO intarray VALUES (98), (99)
  ok 22 - added 2 ints
  ok 23 - IN intarray
  ok 24 - create vtable strarray
  ok 25 - INSERT INTO strarray VALUES ('aa'), ('bb')
  ok 26 - added 2 strings
  ok 27 - IN strarray
  ok 28 - IN SELECT FROM strarray
  ok 29 - no warnings
  ok
  couldn't eval q{sub {my ($self, $i) = @_; my $row = $self->row($i); 
(defined($row->{script}) && defined($vals[0]) && $row->{script} eq $vals[0]) && 
(defined($row->{name}) && defined($vals[1]) && $row->{name}  $vals[1])}} : 
syntax error at (eval 13) line 1, near "}  $vals"
  
  #   Failed test 'no warnings'
  #   at inc/Test/NoWarnings.pm line 38.
  # There were 1 warning(s)
  # Previous test 3 'create table'
  # Use of uninitialized value $op in concatenation (.) or string at 
/home/lamby/temp/cdt.2016022431.7Ar4Lc9KXd/libdbd-sqlite3-perl-1.46/blib/lib/DBD/SQLite/VirtualTable/PerlData.pm
 line 98.
  #  at 
/home/lamby/temp/cdt.2016022431.7Ar4Lc9KXd/libdbd-sqlite3-perl-1.46/blib/lib/DBD/SQLite/VirtualTable/PerlData.pm
 line 98.
  # 
DBD::SQLite::VirtualTable::PerlData::BEST_INDEX(DBD::SQLite::VirtualTable::PerlData=HASH(0x1c029b8),
 ARRAY(0x1c25d20), ARRAY(0x1c02be0)) called at 
/home/lamby/temp/cdt.2016022431.7Ar4Lc9KXd/libdbd-sqlite3-perl-1.46/blib/lib/DBD/SQLite.pm
 line 200
  # DBD::SQLite::db::prepare(DBI::db=HASH(0x1bba508), "SELECT * FROM 
charinfo WHERE script='Greek' AND name LIKE '%S"..., HASH(0xf390c8)) called at 
/usr/lib/x86_64-linux-gnu/perl5/5.22/DBI.pm line 1669
  # DBD::_::db::selectall_arrayref(DBI::db=HASH(0x1bba508), "SELECT * FROM 
charinfo WHERE script='Greek' AND name LIKE '%S"..., HASH(0xf390c8)) called at 
t/virtual_table/21_perldata_charinfo.t line 42
  # 
  # Looks like you planned 10 tests but ran 4.
  # Looks like you failed 1 test of 4 run.
  # Looks like your test exited with 2 just after 4.
  t/virtual_table/21_perldata_charinfo.t  
  1..10
  ok 1 - An object of class 'DBI::db' isa 'DBI::db'
  ok 2 - create_module
  ok 3 - create table
  not ok 4 - no warnings
  Dubious, test returned 2 (wstat 512, 0x200)
  Failed 7/10 subtests 
  t/virtual_table/rt_99748.t  
  1..52
  ok 1 - An object of class 'DBI::db' isa 'DBI::db'
  ok 2 - create_module
  ok 3 - create vtable
  ok 4 - SELECT rowid, * FROM rtb: got 3 rows
  ok 5 - got 1 in a
  ok 6 - got undef in b
  ok 7 - got 1 in a
  ok 8 - SELECT rowid FROM rtb WHERE c = 'six'
  ok 9 - SELECT a FROM rtb WHERE b IS NULL ORDER BY a
  ok 10 - SELECT a FROM rtb WHERE b IS NOT NULL ORDER BY a
  ok 11 - SELECT a FROM rtb WHERE c IS NULL ORDER BY a
  ok 12 - SELECT a FROM rtb WHERE c IS NOT NULL ORDER BY a
  ok 13 - SELECT a FROM rtb WHERE c = ?
  ok 14 - SELECT a FROM rtb WHERE c = ?
  ok 15 - SELECT a FROM rtb WHERE c = ?
  ok 16 - SELECT a FROM rtb WHERE c = ?
  ok 17 - SELECT a FROM rtb WHERE c = ?
  ok 18 - SELECT a FROM rtb WHERE c IS ?
  ok 19 - SELECT rowid, * FROM vtb: got 3 rows
  ok 20 - got 1 in a
  ok 21 - got undef in b
  ok 22 - got 1 in a
  ok 23 - SELECT rowid FROM vtb WHERE c = 'six'
  ok 24 - SELECT a FROM vtb WHERE b IS NULL ORDER BY a
  ok 25 - SELECT a FROM vtb WHERE b IS NOT NULL ORDER BY a
  ok 26 - SELECT a FROM vtb WHERE c IS NULL ORDER BY a
  ok 27 - SELECT a FROM vtb WHERE c IS NOT NULL ORDER BY a
  ok 28 - SELECT a FROM vtb WHERE c = ?
  ok 29 - SELECT a FROM vtb WHERE c = ?
  ok 30 - SELECT a FROM vtb WHERE c = ?
  ok 31 - SELECT a FROM vtb WHERE c = ?
  ok 32 - SELECT a FROM vtb WHERE c = ?
  ok 33 - SELECT a FROM vtb WHERE c IS ?
  ok 34 - SELECT c FROM vtb WHERE c MATCH '^.i' ORDER BY c
  ok 35 - @{[die -1]}
  ok 36 - (foobar
  ok 37 - (?{die 999})
  ok 38 - $foobar
  ok 39 - $self->{row_ix}
  ok 40 - $main::ARGV[ die 999 ]
  ok 41 - @main::ARGV
  ok 42 - $0
  ok 43 - $self
  ok 44 - SELECT a FROM vtb WHERE c MATCH ?
  ok 45 - SELECT a FROM vtb WHERE c MATCH ?
  ok 46 - SELECT a FROM vtb WHERE c MATCH ?
  ok 47 - SELECT a FROM vtb WHERE c MATCH ?
  ok 48 - SELECT a FRO

Bug#810709: yt: FTBFS: TypeError: can't pickle Cython.Compiler.FlowControl.NameAssignment objects

[Chris Lamb]

Source: yt
Version: 3.2.1-2
Severity: serious
Justification: fails to build from source
User: reproducible-bui...@lists.alioth.debian.org
Usertags: ftbfs
X-Debbugs-Cc: reproducible-bui...@lists.alioth.debian.org

Dear Maintainer,

yt fails to build from source in unstable/amd64:

  [..]

  I: pybuild base:184: /usr/bin/python3.5 setup.py build 
  non-existing path in 'yt/utilities/spatial': 'yt/utilities/spatial/tests'
  running build
  running config_cc
  unifing config_cc, config, build_clib, build_ext, build commands --compiler 
options
  running config_fc
  unifing config_fc, config, build_clib, build_ext, build commands --fcompiler 
options
  running build_src
  build_src
  building py_modules sources
  creating build/src.linux-x86_64-3.5
  creating build/src.linux-x86_64-3.5/yt
  creating build/src.linux-x86_64-3.5/yt/analysis_modules
  creating 
build/src.linux-x86_64-3.5/yt/analysis_modules/cosmological_observation
  creating 
build/src.linux-x86_64-3.5/yt/analysis_modules/cosmological_observation/light_cone
  creating 
build/src.linux-x86_64-3.5/yt/analysis_modules/cosmological_observation/light_ray
  creating build/src.linux-x86_64-3.5/yt/analysis_modules/halo_finding
  creating build/src.linux-x86_64-3.5/yt/analysis_modules/halo_finding/fof
  creating build/src.linux-x86_64-3.5/yt/analysis_modules/halo_finding/hop
  creating build/src.linux-x86_64-3.5/yt/analysis_modules/halo_mass_function
  creating build/src.linux-x86_64-3.5/yt/analysis_modules/level_sets
  creating build/src.linux-x86_64-3.5/yt/analysis_modules/particle_trajectories
  creating build/src.linux-x86_64-3.5/yt/analysis_modules/photon_simulator
  creating build/src.linux-x86_64-3.5/yt/analysis_modules/spectral_integrator
  creating build/src.linux-x86_64-3.5/yt/analysis_modules/star_analysis
  creating build/src.linux-x86_64-3.5/yt/analysis_modules/two_point_functions
  creating build/src.linux-x86_64-3.5/yt/analysis_modules/sunyaev_zeldovich
  creating build/src.linux-x86_64-3.5/yt/analysis_modules/ppv_cube
  creating build/src.linux-x86_64-3.5/yt/data_objects
  creating build/src.linux-x86_64-3.5/yt/fields
  creating build/src.linux-x86_64-3.5/yt/extern
  creating build/src.linux-x86_64-3.5/yt/frontends
  creating build/src.linux-x86_64-3.5/yt/frontends/art
  creating build/src.linux-x86_64-3.5/yt/frontends/artio
  creating build/src.linux-x86_64-3.5/yt/frontends/athena
  creating build/src.linux-x86_64-3.5/yt/frontends/boxlib
  creating build/src.linux-x86_64-3.5/yt/frontends/chombo
  creating build/src.linux-x86_64-3.5/yt/frontends/eagle
  creating build/src.linux-x86_64-3.5/yt/frontends/enzo
  creating build/src.linux-x86_64-3.5/yt/frontends/fits
  creating build/src.linux-x86_64-3.5/yt/frontends/flash
  creating build/src.linux-x86_64-3.5/yt/frontends/gadget
  creating build/src.linux-x86_64-3.5/yt/frontends/gadget_fof
  creating build/src.linux-x86_64-3.5/yt/frontends/gdf
  creating build/src.linux-x86_64-3.5/yt/frontends/halo_catalog
  creating build/src.linux-x86_64-3.5/yt/frontends/http_stream
  creating build/src.linux-x86_64-3.5/yt/frontends/moab
  creating build/src.linux-x86_64-3.5/yt/frontends/owls
  creating build/src.linux-x86_64-3.5/yt/frontends/owls_subfind
  creating build/src.linux-x86_64-3.5/yt/frontends/ramses
  creating build/src.linux-x86_64-3.5/yt/frontends/rockstar
  creating build/src.linux-x86_64-3.5/yt/frontends/sdf
  creating build/src.linux-x86_64-3.5/yt/frontends/sph
  creating build/src.linux-x86_64-3.5/yt/frontends/stream
  creating build/src.linux-x86_64-3.5/yt/frontends/tipsy
  creating build/src.linux-x86_64-3.5/yt/geometry
  creating build/src.linux-x86_64-3.5/yt/gui
  creating build/src.linux-x86_64-3.5/yt/units
  creating build/src.linux-x86_64-3.5/yt/utilities
  creating build/src.linux-x86_64-3.5/yt/utilities/answer_testing
  creating build/src.linux-x86_64-3.5/yt/utilities/grid_data_format
  creating build/src.linux-x86_64-3.5/yt/utilities/grid_data_format/conversion
  creating build/src.linux-x86_64-3.5/yt/utilities/lib
  creating build/src.linux-x86_64-3.5/yt/visualization
  creating build/src.linux-x86_64-3.5/yt/visualization/image_panner
  creating build/src.linux-x86_64-3.5/yt/visualization/volume_rendering
  building extension "yt.analysis_modules.halo_finding.fof.EnzoFOF" sources
  building extension "yt.analysis_modules.halo_finding.hop.EnzoHop" sources
  building extension "yt.analysis_modules.ppv_cube.ppv_utils" sources
  cythonc:> build/src.linux-x86_64-3.5/yt/analysis_modules/ppv_cube/ppv_utils.c
  building extension "yt.frontends.artio._artio_caller" sources
  cythonc:> build/src.linux-x86_64-3.5/yt/frontends/artio/_artio_caller.c
  building extension "yt.geometry.grid_visitors" sources
  cythonc:> build/src.linux-x86_64-3.5/yt/geometry/grid_visitors.c
  building extension "yt.geometry.grid_container" sources
  cythonc:> build/src.linux-x86_64-3.5/yt/geometry/grid_container.c
  building extension "yt.geometry.oct_container" sources
  cythonc:> build/src.linux-x86_64-3.5/yt/g

Bug#809053: xindy FTBFS due to CPPFLAGS containing spaces

[Agustin Martin]

Hi, Norbert,

On Mon, Jan 04, 2016 at 01:35:22PM +0900, Norbert Preining wrote:
> 
> For those who are interested, here are preliminary packages
> of xindy 2.5.1 from TeX Live sources 20150104 (today):
> 
> deb http://www.preining.info/debian/ xindy main
> deb-src http://www.preining.info/debian/ xindy main
> 
> (amd64)
> 
> If someone can give it some tests that would be great.

Tested with one of my usual .idx and my usual style file. Seems to work
pretty well. 

Furthermore, with recent changes seems I no longer reproduce
http://sourceforge.net/p/xindy/bugs/57/. Not sure how, but seems that
recent texlive changes made this problem disappear.

Just a couple of minor issues,

 * debian/README.source: It is still about old dpatch.
 * debian/gbp.conf: Should it be in the sources?

Did not find other issues, your xindy package really seems ready for
upload when you want. 

Thanks a lot for your work and for caring about xindy.

Regards,

-- 
Agustin

Bug#810710: libdata-objectdriver-perl: FTBFS: t/02-basic.t (Wstat: 256 Tests: 67 Failed: 1)

[Chris Lamb]

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

Dear Maintainer,

libdata-objectdriver-perl fails to build from source in unstable/amd64:

  [..]

  ok 28 - Ingredient has an ID
  ok 29 - ID is 2
  ok 30 - Name is Bananas
  ok 31 - Got one ingredient back from search
  ok 32 - ID is for the Bananas object
  ok 33 - Name is Bananas
  ok 34 - Object saved successfully
  ok 35 - Recipe has an ID
  ok 36 - Recipe assigned to a cluster
  ok 37 - Title is Chocolate Chip Cookies
  ok 38 - Ingredient saved successfully
  ok 39 - Ingredient has an ID
  ok 40 - ID is 1
  ok 41 - Name is Chocolate Chips
  ok 42 - lookup gave us an ingredient
  ok 43 - Name is Chocolate Chips
  ok 44
  ok 45
  ok 46
  ok 47
  ok 48 - Ingredient removed successfully
  ok 49 - Ingredient removed successfully
  ok 50 - Ingredient removed successfully
  ok 51 - Recipe removed successfully
  ok 52 - Recipe removed successfully
  ok 53 - Object saved successfully
  ok 54 - Recipe has an ID
  ok 55 - Title is set
  ok 56 - Ingredient saved successfully
  ok 57 - Ingredient has an ID
  ok 58 - ID is defined
  ok 59 - got a name for the ingredient
  ok 60 - no trace of object
  ok 61 - no trace of object
  ok 62
  ok 63 - Object saved successfully
  ok 64 - Recipe has an ID
  ok 65 - Title is set
  ok 66 - Ingredient saved successfully
  ok 67 - Ingredient has an ID
  ok 68 - ID is defined
  ok 69 - got a name for the ingredient
  ok 70 - still here
  ok 71 - still here
  ok 72
  ok 73 - still here
  ok 74 - finally deleted
  ok 75
  ok 76 - committing with no active transaction caused warning
  ok 77
  ok 78
  ok 79 - Object saved successfully
  ok 80 - beginning new transaction with a transaction already open causes 
warning
  ok 81 - beginning new transaction with two transactions already open causes 
warning
  ok 82
  ok 83
  ok 84
  ok 85 - got committed
  ok 86 - got committed
  ok 87
  ok 88 - Object saved successfully
  ok 89 - beginning new transaction with a transaction already open still 
causes warning
  ok 90
  ok 91 - rollback
  ok 92 - rollback
  ok
  t/33-views.t ... 
  1..6
  ok 1
  ok 2
  ok 3
  ok 4
  ok 5 # skip DBD::SQLite bug?
  ok 6 # skip DBD::SQLite bug?
  ok
  t/34-both.t  
  1..90
  ok 1
  ok 2
  ok 3 - A reference of type 'ARRAY' isa 'ARRAY'
  ok 4
  ok 5 - A reference of type 'ARRAY' isa 'ARRAY'
  ok 6
  ok 7
  ok 8
  ok 9 - A reference of type 'ARRAY' isa 'ARRAY'
  ok 10
  ok 11 - An object of class 'Ingredient' isa 'Ingredient'
  ok 12
  ok 13
  ok 14
  ok 15
  ok 16
  ok 17
  ok 18
  ok 19
  ok 20
  ok 21
  ok 22
  ok 23
  ok 24
  ok 25
  ok 26 - it's in the cache
  ok 27 - It's been purged from the cache
  ok 28
  ok 29
  ok 30
  ok 31
  ok 32
  ok 33
  ok 34
  ok 35
  ok 36
  ok 37
  ok 38 - A reference of type 'ARRAY' isa 'ARRAY'
  ok 39
  ok 40 - An object of class 'Ingredient' isa 'Ingredient'
  ok 41
  ok 42
  ok 43
  ok 44
  ok 45
  ok 46
  ok 47
  ok 48
  ok 49
  ok 50
  ok 51 - Object saved successfully
  ok 52 - Recipe has an ID
  ok 53 - Title is set
  ok 54 - Ingredient saved successfully
  ok 55 - Ingredient has an ID
  ok 56 - ID is defined
  ok 57 - got a name for the ingredient
  ok 58 - no trace of object
  ok 59 - no trace of object
  ok 60
  ok 61 - Object saved successfully
  ok 62 - Recipe has an ID
  ok 63 - Title is set
  ok 64 - Ingredient saved successfully
  ok 65 - Ingredient has an ID
  ok 66 - ID is defined
  ok 67 - got a name for the ingredient
  ok 68 - still here
  ok 69 - still here
  ok 70
  ok 71 - still here
  ok 72 - finally deleted
  ok 73
  ok 74 - committing with no active transaction caused warning
  ok 75
  ok 76
  ok 77 - Object saved successfully
  ok 78 - beginning new transaction with a transaction already open causes 
warning
  ok 79 - beginning new transaction with two transactions already open causes 
warning
  ok 80
  ok 81
  ok 82
  ok 83 - got committed
  ok 84 - got committed
  ok 85
  ok 86 - Object saved successfully
  ok 87 - beginning new transaction with a transaction already open still 
causes warning
  ok 88
  ok 89 - rollback
  ok 90 - rollback
  ok
  t/35-multiplexed.t . 
  1..42
  ok 1 - An object of class 'Data::ObjectDriver::Driver::DBI' isa 
'Data::ObjectDriver::Driver::DBI'
  ok 2 - An object of class 'Data::ObjectDriver::Driver::DBI' isa 
'Data::ObjectDriver::Driver::DBI'
  ok 3 - lookup lives
  ok 4 - lookup_multi lives
  ok 5 - exists lives
  ok 6
  ok 7
  ok 8 - An object of class 'Ingredient2Recipe' isa 'Ingredient2Recipe'
  ok 9 - An object of class 'Ingredient2Recipe' isa 'Ingredient2Recipe'
  ok 10
  ok 11
  ok 12 - Record exists in Data::ObjectDriver::Driver::DBI=HASH(0x2074f48) 
backend database
  ok 13 - Record exists in Data::ObjectDriver::Driver::DBI=HASH(0x2074f60) 
backend database
  ok 14 - An object of class '

Bug#810681: heimdal-clients: installing package forces krb5-user to be removed

[Jelmer Vernooij]

On Mon, Jan 11, 2016 at 11:03:43AM +0100, Paul Millar wrote:
> I am trying to install the heimdal-clients package because it contains some
> "kerberised" applications that do not exist in the MIT equivalent package:
> krb5-user.
Are you referring to kftp ? That's the only application for which this is the
case as far as I can tell.

> >From manual dry-run installing each of the dependencies, I see that only the
> heimdal-clients package requires the removal of the krb5-user package.
> 
> I don't understand the reason for requiring krb5-user package to be removed: 
> in
> case of conflicting names, alternatives (as provided by dpkg) allows multiple
> instances to exist concurrently.
> 
> I've classified this bug as IMPORTANT, but it could also be classified as
> WISHLIST, depending on one's point-of-view.
I've changed the severity to wishlist.

Cheers,

Jelmer

Bug#806191: ruby-fast-xs: Missing Breaks or Conflicts with ruby-hpricot

[Andreas Beckmann]

On Wed, 25 Nov 2015 10:59:36 -0200 Antonio Terceiro
> according to
> https://packages.debian.org/search?searchon=contents&keywords=fast_xs.so&mode=filename&suite=unstable&arch=any
> sh4 is the only architecture where ruby-hpricot ships that file.

That output is seriously outdated (#810590), or did you see a ruby 2.2.0
path anywhere?


Andreas

Bug#810557: cmus: FTBFS with FFmpeg 2.9/3.0

[Sebastian Ramacher]

On 2016-01-09 22:15:49, Andreas Cadhalpun wrote:
> Package: cmus
> Version: 2.7.1-1
> Severity: important
> Tags: patch
> User: pkg-multimedia-maintain...@lists.alioth.debian.org
> Usertags: ffmpeg2.9
> 
> Dear Maintainer,
> 
> your package fails to build with the upcoming version
> of ffmpeg, which is planned to be released this month
> (and will be called 2.9 or 3.0).
> This bug will become release-critical at some point when this
> ffmpeg transition gets closer.
> 
> Attached is a patch replacing the deprecated functionality.
> It also works with ffmpeg 2.8.
> Please apply this patch and forward it upstream, if necessary.
> 
> These changes have little regression potential.

I have forwarded your patch upsteram (https://github.com/cmus/cmus/pull/383).
Could you please follow up to the questions asked there?

Cheers
-- 
Sebastian Ramacher


signature.asc
Description: PGP signature

Bug#810711: kbd: examples/vcstime.service: move to /lib/systemd

[Paul Wise]

Package: kbd
Version: 2.0.3-2
Severity: wishlist
File: /usr/share/doc/kbd/examples/vcstime.service

It would be nice to move vcstime.service to the standard systemd
directory (and enable all the hardening) but disabled by default so
that it is just a systemctl enable/start away from working on boot.
There isn't any downside to this as far as I can tell.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise




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

Bug#810367: [PATCH] depmod: Don't insert comment in modules.devname if otherwise empty

[Lucas De Marchi]

On Sun, Jan 10, 2016 at 1:10 PM, Josh Triplett  wrote:
> This allows tools to detect the file as empty, such as via systemd's
> ConditionFileNotEmpty.
> ---
>
> The string constant extends past 80 columns, per CODING-STYLE.
>
> The motivation for this patch came from Debian bug 810367.  This change
> would allow kmod-static-nodes.service to use ConditionFileNotEmpty
> instead of ConditionPathExists.
>
>  tools/depmod.c | 12 
>  1 file changed, 8 insertions(+), 4 deletions(-)
>
> diff --git a/tools/depmod.c b/tools/depmod.c
> index a585d47..6e9bb4d 100644
> --- a/tools/depmod.c
> +++ b/tools/depmod.c
> @@ -1999,8 +1999,7 @@ static int output_builtin_bin(struct depmod *depmod, 
> FILE *out)
>  static int output_devname(struct depmod *depmod, FILE *out)
>  {
> size_t i;
> -
> -   fputs("# Device nodes to trigger on-demand module loading.\n", out);
> +   bool empty = true;
>
> for (i = 0; i < depmod->modules.count; i++) {
> const struct mod *mod = depmod->modules.array[i];
> @@ -2036,10 +2035,15 @@ static int output_devname(struct depmod *depmod, FILE 
> *out)
> }
>
> if (devname != NULL) {
> -   if (type != '\0')
> +   if (type != '\0') {
> +   if (empty) {
> +   fputs("# Device nodes to trigger 
> on-demand module loading.\n",
> + out);
> +   empty = false;
> +   }
> fprintf(out, "%s %s %c%u:%u\n", mod->modname,
> devname, type, major, minor);
> -   else
> +} else
> ERR("Module '%s' has devname (%s) but "
> "lacks major and minor information. "
> "Ignoring.\n", mod->modname, devname);
> --

Applied, thanks.


Lucas De Marchi

Bug#810712: Please consider providing python bindings

[VA]

Package: src:libseccomp
Version: 2.2.3-2
Severity: wishlist

libseccomp provides Python bindings 
(https://github.com/seccomp/libseccomp/tree/master/src/python), so it 
would be nice to have a debian package python-seccomp out of the 
libseccomp source package.

Bug#809136: borgbackup: Mention API incompatibilities in README

[Danny Edel]

Hello everyone,

after our discussions and the clarifications from anarcat, it seems that
the only sensible way to solve this is by trying to inform the end-user
as much as possible to help her/him make an informed decision whether
they should use the 0.x software or wait for the 1.0 version.

On future compat-breaking updates, I will take care to copy any relevant
parts from upstream changelog to a NEWS.Debian file, to make sure they
pop up during installation / get e-mailed to the admin, although that
does of course not cover new installations.

I have already split the Debian-READMEs into source[1] and end-user[2]
and I tried to find a sensible wording for both.

If you have better ideas, send patches!  (feel free to spawn new
branches on the collab-maint repository)


Under the assumption that the enduser can be expected to at least read
README.Debian, (upstream) README.rst, and NEWS.Debian upon updates, I
believe that it should be appropriate to post stuff there.


Please state whether you think this (write README and hope user actually
reads it) is an appropriate solution to the compatibility problem,
meaning we could close the bug this way.


Cheers

- Danny


[1]:
https://anonscm.debian.org/cgit/collab-maint/borgbackup.git/tree/debian/README.source
[2]:
https://anonscm.debian.org/cgit/collab-maint/borgbackup.git/tree/debian/README.Debian

Bug#810587: mime-support: warnings about { depricated in regex

[Charles Plessy]

Le Sun, Jan 10, 2016 at 01:35:40AM -0500, Jason Woofenden a écrit :
> 
> I frequently get this warning message:
> 
>   Unescaped left brace in regex is deprecated, passed through in regex; 
> marked by <-- HERE in m/%{ <-- HERE (.*?)}/ at /usr/bin/run-mailcap line 528.

Thanks Jason,

I think that this is because Perl 5.22 deprecated unescapted left braces.

Can you test the attached patch ?  I do not have a Sid machine ready at the
moment.

Have a nice day,

-- 
Charles Plessy
Tsurumi, Kanagawa, Japan
>From d2b5636a2fa478e8d5355e4b5d7eb19886f90146 Mon Sep 17 00:00:00 2001
From: Charles Plessy 
Date: Mon, 11 Jan 2016 21:55:32 +0900
Subject: [PATCH] Escape a left curly bracket with a backslash.  (Warning since
 Perl 5.22).

Closes: #810587
---
 run-mailcap | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/run-mailcap b/run-mailcap
index 3690f54..8ef4665 100755
--- a/run-mailcap
+++ b/run-mailcap
@@ -531,7 +531,7 @@ foreach (@files) {
 
 $comm =~ s!([^%])%t!$1$type!g;
 $comm =~ s!([^%])%F!$1!g;
-$comm =~ s!%{(.*?)}!$_="'$ENV{$1}'";s/\`//g;s/\'\'//g;$_!ge;
+$comm =~ s!%\{(.*?)}!$_="'$ENV{$1}'";s/\`//g;s/\'\'//g;$_!ge;
 $comm =~ s!\\(.)!$1!g;
 $comm =~ s!\'\'!\'!g;
 $comm =~ s!$quotedsemi!;!go;
-- 
2.1.4

Bug#810681: heimdal-clients: installing package forces krb5-user to be removed

[Paul Millar]

Hi Jelmer,

On 11/01/16 13:34, Jelmer Vernooij wrote:

Are you referring to kftp ? That's the only application for which this is the
case as far as I can tell.


Yes, that's exactly it.

To give the full story, I have an FTP server that accepts 
Kerberose-based authentication (amongst others) and would like to be 
able to test it.


If krb5-user also included a Kerberos FTP client then that, too, would 
solve my problem.


[...]

I've classified this bug as IMPORTANT, but it could also be classified as
WISHLIST, depending on one's point-of-view.

>

I've changed the severity to wishlist.


Fair enough -- this is certainly not urgent: I wanted to record the issue.

Thanks!

Paul.

Bug#810682: libncarg-dev: unsatisfiable Depends: ncl-narg

[Alastair McKinstry]

Thanks, yes I meant ncl-ncarg.

regards
Alastair


On 11/01/2016 10:05, Andreas Beckmann wrote:
> Package: libncarg-dev
> Version: 6.3.0-5
> Severity: serious
> User: debian...@lists.debian.org
> Usertags: piuparts
>
> Hi,
>
> during a test with piuparts I noticed your package is no longer
> installable in sid:
>
> unsatisfiable Depends: ncl-narg
>
> Did you mean ncl-ncarg?
>
>
> Cheers,
>
> Andreas

-- 
Alastair McKinstry, , , 
https://diaspora.sceal.ie/u/amckinstry
Misentropy: doubting that the Universe is becoming more disordered. 

Bug#805512: usb-modeswitch-data: Huawei 12d1:1446 does not switch due to bad udev rule

[Josua Dietze]

Am 09.01.2016 um 00:14 schrieb Blake Miner:

Honestly, I did try the whole usbmodeswitch logging thing to no avail


I have found a stupid bug in the dispatcher which prevented early
logging ...

Edit the dispatcher script "/sbin/usb_modeswitch_dispatcher" (or
"usb_modeswitch.tcl" in the source).

Change line #731 from

set $flags(logwrite) 1

to

set flags(logwrite) 1

Now you should get a (short) log, showing at least the input parameter the
dispatcher receives.



Best regards,
Josh

Bug#810681: heimdal-clients: installing package forces krb5-user to be removed

[Jelmer Vernooij]

On Mon, Jan 11, 2016 at 02:02:02PM +0100, Paul Millar wrote:
> Hi Jelmer,
> 
> On 11/01/16 13:34, Jelmer Vernooij wrote:
> >Are you referring to kftp ? That's the only application for which this is the
> >case as far as I can tell.
> 
> Yes, that's exactly it.
> 
> To give the full story, I have an FTP server that accepts Kerberose-based
> authentication (amongst others) and would like to be able to test it.
> 
> If krb5-user also included a Kerberos FTP client then that, too, would solve
> my problem.
Note that there are several other FTP clients in Debian that support Kerberos, 
e.g. yafc.

Cheers,

Jelmer

Bug#378506: installation-reports: installer ignores unusual default gateway

[Sam Morris]

On Sun, 2016-01-10 at 22:33 +0100, Guus Sliepen wrote:
> This is neither a bug in the installer or in ifupdown; a default
> gateway should always be inside the local network. It is the kernel
> that refuses to accept such a gateway route.

I'm not sure I follow. If the kernel rejects the gateway then how come
it's possible to configure this manually? It's been a while since I
filed the original bug but I'm pretty sure the problem was with the
installer rejecting the configuration provided by 1and1's DHCP server.

I know their setup looks bonkers, but failing to interoperate with it
makes it a lot more difficult to get Debian working on their dedicated
servers.

-- 
Sam Morris 
CAAA AA1A CA69 A83A 892B  1855 D20B 4202 5CDA 27B9



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

Bug#810713: liburi-namespacemap-perl should recommend librdf-ns-curated-perl

[Kjetil Kjernsmo]

Package: liburi-namespacemap-perl
Version: 0.28-1
Severity: minor

Dear Maintainer,

The upstream version of 0.28 recommends RDF::NS::Curated, and it would
be nice if the Debian package also did that, now that it is in
Debian. In fact, I think this what most users would want. Also,
upstream has no plans for a new release in a while, so it would be
nice to do that update on the current package.

Cheers,

Kjetil (aka upstream of both of these :-) )

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

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

Versions of packages liburi-namespacemap-perl depends on:
ii  libiri-perl  0.004-1
ii  libmoo-perl  1.006001-1
ii  libnamespace-autoclean-perl  0.20-1
ii  libtry-tiny-perl 0.22-1
ii  libtypes-uri-perl0.006-1
ii  liburi-perl  1.64-1
ii  perl 5.20.2-3+deb8u1

Versions of packages liburi-namespacemap-perl recommends:
ii  librdf-ns-perl20140910-1
ii  librdf-prefixes-perl  0.005-1
ii  libxml-commonns-perl  0.06-3

liburi-namespacemap-perl suggests no packages.

-- no debconf information

Bug#805291: preseed: Offer a way to override initrd-level preseeding with kernel command line preseeding

[Raphael Hertzog]

Hi Philip,

On Sun, 10 Jan 2016, Philip Hands wrote:
> BTW would you happen to know if the example for checksums on CDs is
> relevant any more?
> 
>   - if you're booting a remastered CD:
> preseed/file=/cdrom/preseed.cfg
> preseed/file/checksum=5da499872becccfeda2c4872f9171c3d
> 
> which is supposedly an example where one might specify the checksum for
> the CD's preseed.cfg -- it strikes me that a) this is a bit pointless
> (although it would catch corruption of the media), and b) it presumably
> doesn't work any more, because that file will already have been used by
> the time we get to the kernel parameters.

I believe you mix up file preseeding and initrd preseeding. This file
based preseeding happens after initrd preseeding and kernel parameter
preseeding.

So the above debconf entries are defined early in the process via
"env-preseed" but they are only used later by "file-preseed".

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

Support Debian LTS: http://www.freexian.com/services/debian-lts.html
Learn to master Debian: http://debian-handbook.info/get/

Bug#731742: [Pkg-systemd-maintainers] Bug#731742: systemd will not start syslog.socket. This causes rsyslogd to not start

[ge...@riseup.net]

On Fri, 11 Dec 2015 16:26:12 +0100 Michael Biebl  wrote:
> On Thu, 6 Mar 2014 10:08:27 -0500 Eric Cooper  wrote:
> > On Thu, Mar 06, 2014 at 06:20:54AM +0100, Michael Biebl wrote:
> > > Ah good, we are finally getting somewhere. Could you try to
> > > compare the date of the /etc/systemd/system/syslog.service symlink
> > > with you dpkg.log. If you find a match, please also check, which
> > > version of i-s-h was installed then.
> > 
> > Unfortunately, I already did a "systemctl disable rsyslog" and then
> > "systemctl enable rsyslog" to recreate the symlink in
> > multi-user.target.wants/.
> > 
> > The good news is that fixed my problem, but I no longer have the
> > metadata you're asking for.
> 
> Given this, I'm going to close this old bug report.
> 
> Feel free to reopen, if you run into this issue again.

Sorry to do this, but I've just run into the same problem while doing a
dist-upgrade from wheezy to jessie.

After doing a reboot:

# systemctl daemon-reload
# systemctl restart syslog.service 
Failed to restart syslog.service: Unit syslog.service failed to load: No
such file or directory.

# systemctl disable rsyslog
Synchronizing state for rsyslog.service with sysvinit using update-rc.d...
Executing /usr/sbin/update-rc.d rsyslog defaults
Executing /usr/sbin/update-rc.d rsyslog disable
insserv: warning: current start runlevel(s) (empty) of script `rsyslog' 
overrides LSB defaults (2 3 4 5).
insserv: warning: current stop runlevel(s) (0 1 2 3 4 5 6) of script `rsyslog' 
overrides LSB defaults (0 1 6).
# systemctl enable rsyslog.service 
Synchronizing state for rsyslog.service with sysvinit using update-rc.d...
Executing /usr/sbin/update-rc.d rsyslog defaults
insserv: warning: current start runlevel(s) (empty) of script `rsyslog' 
overrides LSB defaults (2 3 4 5).
insserv: warning: current stop runlevel(s) (0 1 2 3 4 5 6) of script `rsyslog' 
overrides LSB defaults (0 1 6).
Executing /usr/sbin/update-rc.d rsyslog enable
Created symlink from /etc/systemd/system/syslog.service to 
/lib/systemd/system/rsyslog.service.
[Please note: This symlink was missing before.]

# systemctl status rsyslog.service 
● rsyslog.service - System Logging Service
   Loaded: loaded (/lib/systemd/system/rsyslog.service; enabled)
   Active: inactive (dead)
 Docs: man:rsyslogd(8)
   http://www.rsyslog.com/doc/
# systemctl restart syslog.service
# systemctl status syslog.socket 
● syslog.socket - Syslog Socket
   Loaded: loaded (/lib/systemd/system/syslog.socket; static)
   Active: active (running) since Mon 2016-01-11 02:42:50 CET; 6s ago
 Docs: man:systemd.special(7)
   http://www.freedesktop.org/wiki/Software/systemd/syslog
   Listen: /run/systemd/journal/syslog (Datagram)

I didn't had the time to debug this further yet, but I suspect, that
during dist-upgrade, the symlink isn't created correctly / at all.

Thats all for the moment,
Georg


signature.asc
Description: Digital signature

Bug#780392: asterisk-modules: Asterisk fai to load some modules

[José Miguel Gonçalves]

Hi,

The default '/etc/asterisk/modules.conf' packaged in "asterisk-config" has these 
problems, and should be fixed for something that does not give 'undefined symbols' 
out of the box.


After some experiments, what worked well for me in a Debian 8 installation with 
FreePBX was this:


[modules]
autoload=yes
preload = pbx_config.so
preload = chan_local.so
preload = res_speech.so
preload = res_agi.so
preload = res_calendar.so
preload = res_crypto.so
preload = res_smdi.so
preload = res_http_websocket.so
preload = res_monitor.so
noload = chan_skinny.so
noload = chan_unistim.so
noload = chan_motif.so
noload = pbx_dundi.so
noload = pbx_lua.so
noload = pbx_ael.so
noload = cdr_pgsql.so
noload = cel_pgsql.so
noload = cel_tds.so
noload = res_corosync.so
noload = res_config_sqlite.so
noload = res_config_pgsql.so
noload = res_config_odbc.so
noload = res_odbc.so
noload = cel_odbc.so
noload = cdr_odbc.so
noload = cdr_adaptive_odbc.so
noload = func_odbc.so
noload = res_fax_spandsp.so
noload = codec_dahdi.so
noload = chan_woomera.so
noload = pbx_gtkconsole.so
noload = pbx_kdeconsole.so
noload = app_intercom.so
noload = chan_modem.so
noload = chan_modem_bestdata.so
noload = chan_modem_i4l.so
noload = app_trunkisavail.so
noload = chan_alsa.so
noload = chan_oss.so
noload = app_directory_odbcstorage.so
noload = app_voicemail_odbcstorage.so
noload = chan_modem_aopen.so
noload = chan_woomera.so
noload = cdr_radius.so
noload = cel_radius.so
load = format_wav.so
load = format_pcm.so
load = res_musiconhold.so

Best regards,
José Gonçalves

Bug#805291: preseed: Offer a way to override initrd-level preseeding with kernel command line preseeding

[Philip Hands]

Raphael Hertzog  writes:

> Hi Philip,
>
> On Sun, 10 Jan 2016, Philip Hands wrote:
>> BTW would you happen to know if the example for checksums on CDs is
>> relevant any more?
>> 
>>   - if you're booting a remastered CD:
>> preseed/file=/cdrom/preseed.cfg
>> preseed/file/checksum=5da499872becccfeda2c4872f9171c3d
>> 
>> which is supposedly an example where one might specify the checksum for
>> the CD's preseed.cfg -- it strikes me that a) this is a bit pointless
>> (although it would catch corruption of the media), and b) it presumably
>> doesn't work any more, because that file will already have been used by
>> the time we get to the kernel parameters.
>
> I believe you mix up file preseeding and initrd preseeding. This file
> based preseeding happens after initrd preseeding and kernel parameter
> preseeding.

You are correct -- I was confusing the file that would be in the root of
the initrd, and the file that (in the example above) would be in the
root of the CD.

Cheers, Phil.
-- 
|)|  Philip Hands  [+44 (0)20 8530 9560]  HANDS.COM Ltd.
|-|  http://www.hands.com/http://ftp.uk.debian.org/
|(|  Hugo-Klemm-Strasse 34,   21075 Hamburg,GERMANY


signature.asc
Description: PGP signature

Bug#797702:

[Richard Hartmann]

Hi Alexandre, Dmitry,

it seems all dependencies have been packaged. Is there still a
blocking issue anywhere?

FWIW, I can sponsor packages.


Thanks,
Richard

Bug#780392: asterisk-modules: Asterisk fai to load some modules

[Tzafrir Cohen]

On Sun, Jan 10, 2016 at 01:06:01PM -0600, Samuel Smith wrote:
> Same issue with me as well after an upgrade from Wheezy to Jessie:
> 
> 
> [Jan 10 06:01:31] Asterisk 11.13.1~dfsg-2+b1 built by buildd @ brahms on a
> x86_64 running Linux on 2015-01-05 21:34:10 UTC
> [Jan 10 06:01:31] NOTICE[23936] cdr.c: CDR simple logging enabled.
> [Jan 10 06:01:32] NOTICE[23936] loader.c: 219 modules will be loaded.
> [Jan 10 06:01:32] WARNING[23936] loader.c: Error loading module
> 'res_agi.so': /usr/lib/asterisk/modules/res_agi.so: undefined symbol:
> ast_speech_change
> [Jan 10 06:01:32] WARNING[23936] loader.c: Error loading module
> 'res_calendar_caldav.so': /usr/lib/asterisk/modules/res_calendar_caldav.so:
> undefined symbol: ast_calendar_event_container_alloc

Please check that the module has indeed fails to load.

Asterisk's module loader has no information about module dependency, and
thus just tries loading modules in a loop, and keeps retrying. The
problem is that it emits those error messages each time it fails and not
just when it gives up.

And yes, this is a bug on its own.

-- 
Tzafrir Cohen | tzaf...@jabber.org | VIM is
http://tzafrir.org.il || a Mutt's
tzaf...@cohens.org.il ||  best
tzaf...@debian.org|| friend

Bug#810715: pbuilder: pdebuild complains about DEBEMAIL

[Yves-Alexis Perez]

Package: pbuilder
Version: 0.222
Severity: normal

Hi,

since last upload, pdebuild complains about DEBEMAIL variable:


W: The configuration option DEBEMAIL is deprecated.  Please pass the
required options to DEBBUILDOPTS (--debbuildopts command line flag)
instead.


I actually don't set DEBEMAIL for pdebuild/pbuilder (I don't even know
what it does here), but for other stuff (like dch or reportbug), so it's a bit
annoying for me to have that warning everytime. Would it be possible to
stop complaining about it at one point?

Regards,
-- 
Yves-Alexis

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

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

Versions of packages pbuilder depends on:
ii  cdebootstrap   0.7.1
ii  debconf [debconf-2.0]  1.5.58
ii  debootstrap1.0.75
ii  dpkg-dev   1.18.4
ii  wget   1.17.1-1

Versions of packages pbuilder recommends:
ii  devscripts  2.15.10
ii  fakeroot1.20.2-1
ii  iproute24.3.0-1
ii  net-tools   1.60+git20150829.73cef8a-2
ii  sudo1.8.15-1.1

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

-- debconf information:
  pbuilder/mirrorsite: http://ftp.fr.debian.org/debian
  pbuilder/nomirror:
  pbuilder/rewrite: false

Bug#810714: upower: CriticalPowerAction respects systemd inhibitors

[Vinothan Shankar]

Package: upower
Version: 0.99.3-1+b2
Severity: normal

Dear Maintainer,


   * What led up to the situation?

   Running a laptop on battery with the GNOME Shell extension
   "Caffeine" active and a fullscreen application running.

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

 Continued using the computer without seeing any low-battery
 alerts due to aforementioned fullscreen applications.

   * What was the outcome of this action?

   Computer continued to run until battery was well below the
   "critical" threshold, then shut down.

   * What outcome did you expect instead?

   The machine should respect UPower's CriticalPowerAction (which in
   this case is set to the default HybridSleep).

   * Additional Notes

   I have confirmed that Caffeine is the trigger for this behaviour:
   With no full-screen applications running and Caffeine not manually
   activated, the same computer correctly enters hybrid sleep on
   critical battery.  It is fully able to resume in that case, as well
   as if sleep (hybrid or plain) or hibernate is activated manually,
   so that is not the issue.  Presumably, however, any other inhibitor
   would result in the same behaviour.

   Were it not for Caffeine's default behaviour of inhibiting suspend
   and lock automatically when an application is fullscreen, this
   would not be such a problem, but a fullscreen application will also
   mask any low-battery warnings, so (without some kind of hardware
   alert, the way some laptops start beeping at low power) the
   shutdown will come without warning and without the ease of resume
   provided by suspend, hibernate, or hybrid sleep.




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

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

Versions of packages upower depends on:
ii  dbus   1.10.6-1
ii  libc6  2.21-6
ii  libdbus-1-31.10.6-1
ii  libdbus-glib-1-2   0.102-1
ii  libglib2.0-0   2.46.2-3
ii  libgudev-1.0-0 230-2
ii  libimobiledevice4  1.1.6+dfsg-3.1+b1
ii  libplist3  1.12-3.1
ii  libupower-glib30.99.3-1+b2
ii  libusb-1.0-0   2:1.0.20-1
ii  udev   228-2+b1

Versions of packages upower recommends:
ii  policykit-1  0.105-14

upower suggests no packages.

-- no debconf information

Bug#810716: bumprace: A very simple bug fix test, adding "Homepage" line to debian/control.

[Sina Momken]

Package: bumprace
Version: 1.5.4-1
Severity: minor
Tags: patch
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu xenial ubuntu-patch

Dear Maintainer,

It is a very simple bug fix test to learn how to fix a minor bug, and after 
testing upload it to Debian BTS
to be considered for inclusion.

I just added a "Homepage" line to debian/control file to add extra info for 
final package.

I followed tutorial here: 
http://packaging.ubuntu.com/html/fixing-a-bug-example.html


*** /tmp/tmpc99bjs/bug_body

In Ubuntu, the attached patch was applied to achieve the following:

Test the procedure of fixing a minor bug and submitting it to Debian.
This fix only adds a "Homepage" line to debian/control, so should be included 
for packages both in
Debian and Ubuntu.
Just look at: http://packaging.ubuntu.com/html/fixing-a-bug-example.html


  * debian/control: Added project's homepage.


Thanks for considering the patch.


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

Kernel: Linux 3.13.0-74-generic (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
=== modified file 'debian/changelog'

=== modified file 'debian/control'
--- debian/control	2012-05-14 23:38:14 +
+++ debian/control	2016-01-11 13:40:00 +
@@ -1,7 +1,8 @@
 Source: bumprace
 Section: games
 Priority: optional
-Maintainer: Christian T. Steigies 
+Maintainer: Ubuntu Developers 
+XSBC-Original-Maintainer: Christian T. Steigies 
 Build-Depends: autotools-dev,
cdbs,
debhelper (>> 5),
@@ -12,6 +13,7 @@
libtool,
zlib1g-dev
 Standards-Version: 3.9.3
+Homepage: http://www.linux-games.com/bumprace/
 
 Package: bumprace
 Architecture: any

Bug#810154: remove busybox hook, leave responsibility to busybox package

[Andreas Beckmann]

Followup-For: Bug #810154
Control: found -1 0.121~rc2
Control: severity -1 serious

Right now the default configuration in experimental is broken:
* busybox is enabled by default
* missing busybox is a hard failure
* nothing depends on busybox

as noticed by piuparts:

[...]
  Selecting previously unselected package initramfs-tools-core.
  Preparing to unpack .../initramfs-tools-core_0.121~rc2_all.deb ...
  Unpacking initramfs-tools-core (0.121~rc2) ...
  Selecting previously unselected package initramfs-tools.
  Preparing to unpack .../initramfs-tools_0.121~rc2_all.deb ...
  Unpacking initramfs-tools (0.121~rc2) ...
[...]
  Setting up initramfs-tools-core (0.121~rc2) ...
  Setting up initramfs-tools (0.121~rc2) ...
  update-initramfs: deferring update (trigger activated)
  Setting up piuparts-depends-dummy (0.invalid.0) ...
  Processing triggers for systemd (228-3) ...
  Processing triggers for libc-bin (2.22-0experimental1) ...
  Processing triggers for initramfs-tools (0.121~rc2) ...

  Selecting previously unselected package linux-image-4.4.0-rc8-amd64.
  (Reading database ... 
(Reading database ... 7678 files and directories currently installed.)
  Preparing to unpack .../linux-image-4.4.0-rc8-amd64_4.4~rc8-1~exp1_amd64.deb 
...
  Unpacking linux-image-4.4.0-rc8-amd64 (4.4~rc8-1~exp1) ...
  Setting up linux-image-4.4.0-rc8-amd64 (4.4~rc8-1~exp1) ...
  /etc/kernel/postinst.d/initramfs-tools:
  update-initramfs: Generating /boot/initrd.img-4.4.0-rc8-amd64
  E: busybox is required but not installed
  E: /usr/share/initramfs-tools/hooks/busybox failed with return 1.
  update-initramfs: failed for /boot/initrd.img-4.4.0-rc8-amd64 with 1.
  run-parts: /etc/kernel/postinst.d/initramfs-tools exited with return code 1
  Failed to process /etc/kernel/postinst.d at 
/var/lib/dpkg/info/linux-image-4.4.0-rc8-amd64.postinst line 634,  line 
2.
  dpkg: error processing package linux-image-4.4.0-rc8-amd64 (--configure):
   subprocess installed post-installation script returned error exit status 1
  Errors were encountered while processing:
   linux-image-4.4.0-rc8-amd64


Andreas

Bug#810711: [Pkg-kbd-devel] Bug#810711: kbd: examples/vcstime.service: move to /lib/systemd

[Andreas Henriksson]

Hello Paul Wise.

Thanks for your bug report.

On Mon, Jan 11, 2016 at 08:43:41PM +0800, Paul Wise wrote:
> Package: kbd
> Version: 2.0.3-2
> Severity: wishlist
> File: /usr/share/doc/kbd/examples/vcstime.service
> 
> It would be nice to move vcstime.service to the standard systemd
> directory (and enable all the hardening) but disabled by default so
> that it is just a systemctl enable/start away from working on boot.
> There isn't any downside to this as far as I can tell.

I was debating with myself over shipping it disabled or as an example.
Here are the reasons I decided for example:

 * shipping only a service is not policy compliant and does not work
   (cf. #747851), so I'd have to write and maintain an init script as well.
   (Contributions welcome, preferably via getting both init script/service
   merged upstream.)
 * From my quick look at vcstime.c it doesn't give me the impression to
   be a very efficient program or otherwise of quality I would recommend
   people to use/enable.
 * The vcstime is shipped by upstream under "contrib" which I'm not sure
   what it means but doesn't give me the feeling it's not fully supported
   by upstream. The contrib tools are not even built by a regular upstream
   build.
 * The vcstime utility really has nothing to do with the main functionality
   of the kbd package (which I think is quite core os stuff), maybe we should
   consider splitting core kbd parts from contrib stuff which means
   we would have to move conffiles between packages which AFAIK is still
   an unsolved problem.
 * ...

In short, I'm too lazy and don't want to commit to support vcstime.

For now I'm of the opinion that anyone who really wants to enable vcstime
should atleast get to ask themselves "maybe there was a reason for shipping
this as an example so I have to copy it myself to /etc/systemd/system before
enabling it?". I think this is easy enough that enabling it isn't annoyingly
hard if you really want it. The distinction between shipped-disabled and
example units is the best way to signal "supported" vs.
"you're-welcome-but-do-expect-you-have-to-maintain-it-yourself".

Regards,
Andreas Henriksson