Bug#825868: e2fsprogs: isn't Recommends on fuse2fs too much?

[Theodore Ts'o]

On Tue, May 31, 2016 at 01:34:03AM +0200, Christoph Anton Mitterer wrote:
> Package: e2fsprogs
> Version: 1.43-3
> Severity: wishlist
> 
> Is there anything that the e2fsprogrs package itself gains from
> having fuse2fs installed (as it would be in default configurations)?
> 
> Perhaps a Suggests on it would be enough, if at all.

Agreed, thanks for pointing this out.

- Ted

Bug#823990: dh_gconf no longer needs to add gconf2 dependency to misc:Depends?

[Niels Thykier]

Josselin Mouette:
> Hi Niels,
> 
> Le lundi 30 mai 2016 à 19:32 +, Niels Thykier a écrit :
>> Can you confirm that this dependency on gconf2 is now unnecessary?  At
>> first glance I cannot see a need for it now that the autoscripts have
>> been removed.
> 
> Unless the functionality is optional in the package (which is the case
> of pidgin), the gconf2 dependency is still needed. Not because of the
> scripts anymore, but because functionally, a binary shipped with gconf
> schemas will usually require them to execute.
> 
> Otherwise, you might end up with the binary aborting on startup.
> 
> Cheers,
> 

Ok, thanks.

Ari, the best I can then offer would be a switch for skipping the gconf2
dependency (i.e. an opt-out).  Is that still interesting?

Thanks,
~Niels





signature.asc
Description: OpenPGP digital signature

Bug#825840: linux-image-4.5.0-2-powerpc: radeonfb display inverted red and blue color

[Geert Stappers]

On Mon, May 30, 2016 at 08:50:46PM +0100, Ben Hutchings wrote:
> On Mon, 2016-05-30 at 18:42 +0200, Mathieu Malaterre wrote:
[ ... ]
> > 
> > I'd like to keep this bug open until I find what is going on with this
> > color inversion on PPC/ATI.
> [...]
> 
> I'm sorry, but no-one is likely to help with this. The Linux port to
> Power Macs is no longer actively developed and no-one on the Debian
> kernel team looks after them.

I had fun with PowerPC Macintosh. Something about eight years ago.
Maybe ten years ago.

Ben is right where he wrote "no-one is likely to help with PowerPC"

I would have wrote "be aware that you might on your own", now doing so.

I don't know what PowerPC hardware is available these days.  But those who
want to spend time on PowerPC software should go there way.  Remember that
Linus Torvalds started on is own.


Groeten
Geert Stappers
-- 
Leven en laten leven

Bug#825879: zopfli: zopflipng tool and shared libraries missing

[zopfli@discard.email]

Source: zopfli
Version: 1.0.1+git160119-1
Severity: wishlist
 
Please also provide  the zopflipng tool and the associated shared libraries if 
& when they are sufficiently mature for distribution.
 

Bug#825878: RFS: groonga-normalizer-mysql/1.1.1-1

[Kentaro Hayashi]

Package: sponsorship-requests
Severity: normal

Dear mentors,

I am looking for a sponsor for my package "groonga-normalizer-mysql"

* Package name: groonga-normalizer-mysql
  Version : 1.1.1-1
  Upstream Author : Kouhei Sutou 
* URL : https://github.com/groonga/groonga-normalizer-mysql
* License : LGPL-2
  Section : libs

It builds those binary packages:

  groonga-normalizer-mysql - MySQL derived normalizer for Groonga

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

  https://mentors.debian.net/package/groonga-normalizer-mysql


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

  dget -x 
https://mentors.debian.net/debian/pool/main/g/groonga-normalizer-mysql/groonga-normalizer-mysql_1.1.1-1.dsc

More information about groonga-normalizer-mysql can be obtained from 
https://github.com/groonga/groonga-normalizer-mysql

Changes since the last upload:

  * Team upload.
  * New upstream release.
  * debian/control
- Update to latest standard-version 3.9.8.

Regards,
  Kentaro Hayashi


pgp7NF7x26_4Z.pgp
Description: PGP signature

Bug#825877: firejail: conffiles not removed

[Paul Wise]

Package: firejail
Version: 0.9.40~rc1-1
Severity: normal
User: debian...@lists.debian.org
Usertags: obsolete-conffile adequate

The experimental version does not not deal with obsolete conffiles
properly. Please use the dpkg-maintscript-helper support provided by
dh_installdeb to remove these obsolete conffiles on upgrade.

https://www.debian.org/doc/debian-policy/ch-files.html#s-config-files
http://manpages.debian.org/man/1/dh_installdeb

This bug report brought to you by adequate:

http://bonedaddy.net/pabs3/log/2013/02/23/inadequate-software/

$ pkg=firejail ; adequate $pkg ; dpkg-query -W -f='${Conffiles}\n' $pkg | grep 
obsolete
firejail: obsolete-conffile /etc/firejail/disable-mgmt.inc
firejail: obsolete-conffile /etc/firejail/disable-secret.inc
 /etc/firejail/disable-mgmt.inc 50bda0b6c6837b0ee7409255b445037a obsolete
 /etc/firejail/disable-secret.inc 9372a028cb5e15d15d1a95aa55d4015a obsolete

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

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

Versions of packages firejail depends on:
ii  libc6  2.22-9

Versions of packages firejail recommends:
ii  xpra0.17.2+dfsg-1
ii  xserver-xephyr  2:1.18.3-1

firejail suggests no packages.

-- no debconf information

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


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

Bug#825875: freedombox-setup: Remove flash-kernel script from first-run

[Sunil Mohan Adapa]

On 05/31/2016 07:21 AM, James Valleroy wrote:
> Package: freedombox-setup
> Severity: normal
> Tags: patch
> 
> Dear Maintainer,
> 
> As discussed in #825677, the script to run flash-kernel during first-run has a
> number of issues and does not work as intended. But there's no need to run it
> during first-run anyway, so it can be removed. Also the machine-detect script
> is not used anymore, and can be removed.
> 
> I have tested a Dreamplug image with this change included. I was able to 
> access
> Plinth after first-run and after subsequent restarts.
> 

Looks good to me.  Committed this patch based on your testing.

-- 
Sunil



signature.asc
Description: OpenPGP digital signature

Bug#825394: systemd kill background processes after user logs out

[Duraid Madina]

If there were ever any doubt, this surely settles it:

systemd truly is the pulseaudio of process control!

Bug#825811: Missing component 'vgauth' in Open-VM-Tools of Debian 7.9 & 7.10 & 8.2 & 8.3 & 8.4 Guest

[Yanhui He]

Hi Oliver,

Please help me to answer this too, thanks in advance!

Best regards,
Yanui

On 5/30/16, 7:21 PM, "Bernd Zeimetz"  wrote:

>Hi,
>
>> VGAuth service was disabled in open-vm-tools 9.4.6 included in Debian
>>7.9
>> & 7.10 & 8.2 & 8.3 & 8.4. This needs to enabled as soon as possible
>> because it makes open-vm-tools in Debian less usable than VMware Tools.
>
>first you should realize that you should not treat Debian point releases
>as a different release on its own. This was the case for Debian 3 and 4.
>For you there  should never be a visible difference between Debian 8.1
>and 8.4.
>
>open-vm-tools 9.4.6 was basically built with a simple 'configure; make;
>make install' - and looking at the build logs like
>
>https://urldefense.proofpoint.com/v2/url?u=https-3A__buildd.debian.org_sta
>tus_fetch.php-3Fpkg-3Dopen-2Dvm-2Dtools-26arch-3Di386-26ver-3D2-253A9.4.6-
>2D1770165-2D8-26stamp-3D1423826483=CwIDaQ=Sqcl0Ez6M0X8aeM67LKIiDJAXVeA
>w-YihVMNtXt-uEs=EWtp6eb9bfT1h5Xz7k40uBCAtmHtQpbLBghzeC1lnEY=BKOIhfGkeW
>Fg4U83sLqhKxaOmrNqKJ3c-YqRoh6gwak=_U14HMgIEXHyVNtZ2aZwHV6rheSVK4UmNnhPfd
>6JnpY= 
>
>you will see, that configure did not complain about missing things, it
>also just did not build vgauth. So I could not know something is missing.
>
>
>To avoid such things, please test open-vm-tools in Debian testing and/or
>unstable.
>
>
>There is a backport of the last 10.0.7 release in wheezy-backports and
>jessie-backports. Please use it instead of the package from the release.
>Also if you are interested in using the latest open-vm-tools version in
>a stable, please use backports. If possible I'll backport the current
>version to stable and oldstable.
>
>In stable Debian releases we'll only add bugfixes, no new features.
>
>
>Best regards,
>
>Bernd
>
>-- 
> Bernd ZeimetzDebian GNU/Linux Developer
> 
>https://urldefense.proofpoint.com/v2/url?u=http-3A__bzed.de=CwIDaQ=Sqc
>l0Ez6M0X8aeM67LKIiDJAXVeAw-YihVMNtXt-uEs=EWtp6eb9bfT1h5Xz7k40uBCAtmHtQpb
>LBghzeC1lnEY=BKOIhfGkeWFg4U83sLqhKxaOmrNqKJ3c-YqRoh6gwak=P9n4-BVKKy4jX
>OxIM-6cx2uCBZb5ZVD832PhF9UmgR4=
>https://urldefense.proofpoint.com/v2/url?u=http-3A__www.debian.org=CwIDa
>Q=Sqcl0Ez6M0X8aeM67LKIiDJAXVeAw-YihVMNtXt-uEs=EWtp6eb9bfT1h5Xz7k40uBCA
>tmHtQpbLBghzeC1lnEY=BKOIhfGkeWFg4U83sLqhKxaOmrNqKJ3c-YqRoh6gwak=Y8VZeI
>wfWb6lOwezvRotp17P3G2TwUtCjdutGh6CrMM=
> GPG Fingerprint: ECA1 E3F2 8E11 2432 D485  DD95 EB36 171A 6FF9 435F

Bug#825810: After uninstall open-vm-tools in debian, the open-vm-tools version number is not 0

[Yanhui He]

Hi Oliva,

Would you please help me to answer Bernd more professionally?

Thanks in advance!

Best regards,
Yanhui

On 5/30/16, 7:26 PM, "Bernd Zeimetz"  wrote:

>Hi Yanhui!
>
>> This bug is the same as the one of Bug#825812 for my re-send. Please
>> ignore one of them.
>
>I've merged them, don't worry :)
>
>> When install debian in Vmware ESXi Host Server, it will display the
>> open-vm-tools for each guest OS in vSphere Client, such as the attached
>> screenshot of “guest info on vSphere Client.png”.
>> 
>> The right display should be:
>> Vmware Tools: Not running, version 0 (Guest Managed)
>> 
>> But the wrong display is shown as below.
>> Vmware Tools: Not running, version 2147483647 (Guest Managed)
>
>Actually I have no idea what I should do against that :)
>While removing the package vmtoolsd is being stopped (sigterm + sigkill
>if it doesn't react) and that is all we do.
>
>It is no problem to execute something else when the package is being
>removed, but then you'd have to tell me what to run :)
>
>
>Also, as a related question: is there a way to tell from "version
>2147483647 (Guest Managed)" which open-vm-tools version is avtually
>installed?
>
>Thanks & best regards,
>
>Bernd
>
>
>-- 
> Bernd ZeimetzDebian GNU/Linux Developer
> 
>https://urldefense.proofpoint.com/v2/url?u=http-3A__bzed.de=CwIDaQ=Sqc
>l0Ez6M0X8aeM67LKIiDJAXVeAw-YihVMNtXt-uEs=EWtp6eb9bfT1h5Xz7k40uBCAtmHtQpb
>LBghzeC1lnEY=wFFtXTwdstlJaYE1oHyr9tMEMl3ygOdng1ZaHpBbQf8=m_8CWIdxsmZZx
>4tpR7XfpYDPQQbXhY3CKeNYOje_zTA=
>https://urldefense.proofpoint.com/v2/url?u=http-3A__www.debian.org=CwIDa
>Q=Sqcl0Ez6M0X8aeM67LKIiDJAXVeAw-YihVMNtXt-uEs=EWtp6eb9bfT1h5Xz7k40uBCA
>tmHtQpbLBghzeC1lnEY=wFFtXTwdstlJaYE1oHyr9tMEMl3ygOdng1ZaHpBbQf8=jw1n8J
>Sh_y56uEJGM8tJ787aOVnJjFJT-DdrZbKysvM=
> GPG Fingerprint: ECA1 E3F2 8E11 2432 D485  DD95 EB36 171A 6FF9 435F

Bug#821308: Bug doesn't appear in 4.3.5-1

[Nicholas D Steeves]

Hi Markus,

Just to confirm, a downgrade to linux-image-4.3.5-1 fixed this?  Is it
also fixed in one of linux-image-4.5.3-1, 4.5.4-1, or 4.5.5-1 (if
you're running unstable)?

Thanks,
Nicholas

Bug#825876: adduser: [INTL:ru] Russian program translation update

[Yuri Kozlov]

Package: adduser
Version: 3.115
Severity: wishlist
Tags: l10n patch

Dear Maintainer,

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

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

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

Russian program translation update is attached.

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

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


ru.po.gz
Description: application/gzip

Bug#794443: [Pkg-octave-devel] Bug#794443: octave: should notrecommendlibopenblas-base

[Wang S]

Dear maintainers,
I'm sorry that in my system Debian stable (jessie) there is no package 
libopenblas-dbg, so I could not do the backtrace.
Besides, after octave 4.0 came into jessie-backports I had upgrade my octave 
package from 3.8 to 4.0 (currently version is octave 4.0.2-1~bpo8+1), and in 
this new version this crash bug no longer exists.
Thanks maintainers.
Wang S
 
-- Original --
From:  "Sébastie Villemot";
Date:  Sat, Oct 3, 2015 05:31 PM
To:  "Wang S"; "794443"<794...@bugs.debian.org>; 
Subject:  Re: [Pkg-octave-devel] Bug#794443: octave: should 
notrecommendlibopenblas-base
 
Thanks for your feedback.

A backtrace would be useful. Please do the following:

- install the following packages: gdb, octave-dbg, libopenblas-dbg
- run octave from gdb (with "gdb octave-cli"), then type "run" at the
gdb prompt. You should get the octave prompt
- from the octave prompt, trigger the crash. You should be given back a
gdb prompt
- type "backtrace" at the gdb prompt, and send the output to this
bugreport
Thanks,
-- 
 .''`.Sébastien Villemot
: :' :Debian Developer
`. `' http://sebastien.villemot.name
  `-  GPG Key: 4096R/381A7594

Bug#816679: icedove: Please rename icedove to thunderbird

[Christoph Anton Mitterer]

mhh one problem could be that icedove unfortunately chose to use
~/.icedove for settings.

That in turn seems to be stored in many places within the profile, not
to talk about possible add-ons which may store that in encoded or
binary form...

So that's going to be difficult to migrate :-/


Cheers,
Chris.

smime.p7s
Description: S/MIME cryptographic signature

Bug#824758: gtk3-nocsd: shows additional widgets that doesn't appear without gtk3-nocsd

[Christoph Anton Mitterer]

I've just noted one further thing (but again with the version from sid,
no patches), so maybe it's no longer the case already:

When a CSD program isn't maximised (or when there is no maximised
state), it has rounded corners on the top of the "window".

When run with gtk3-nocsd, one still has this round corners with a black
background in the proper window, see attached screenshot.


Cheers,
Chris.

smime.p7s
Description: S/MIME cryptographic signature

Bug#825875: freedombox-setup: Remove flash-kernel script from first-run

[James Valleroy]

Package: freedombox-setup
Severity: normal
Tags: patch

Dear Maintainer,

As discussed in #825677, the script to run flash-kernel during first-run has a
number of issues and does not work as intended. But there's no need to run it
during first-run anyway, so it can be removed. Also the machine-detect script
is not used anymore, and can be removed.

I have tested a Dreamplug image with this change included. I was able to access
Plinth after first-run and after subsequent restarts.



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

Kernel: Linux 4.5.0-2-amd64 (SMP w/12 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
>From 39299eee76a5f3714ed380a31edaa9bc3556b1a6 Mon Sep 17 00:00:00 2001
From: James Valleroy 
Date: Mon, 30 May 2016 10:13:29 -0400
Subject: [PATCH] Remove flash-kernel script from first-run. Also remove
 machine-detect which is no longer needed.

---
 debian/freedombox-setup.install |  1 -
 first-run.d/80_flash-kernel | 30 --
 lib/machine-detect  | 35 ---
 3 files changed, 66 deletions(-)
 delete mode 100755 first-run.d/80_flash-kernel
 delete mode 100755 lib/machine-detect

diff --git a/debian/freedombox-setup.install b/debian/freedombox-setup.install
index 25739e3..6be704d 100644
--- a/debian/freedombox-setup.install
+++ b/debian/freedombox-setup.install
@@ -1,7 +1,6 @@
 setup usr/lib/freedombox
 setup.d usr/lib/freedombox
 first-run.d usr/lib/freedombox
-lib/machine-detect usr/lib/freedombox
 data/etc/apache2/conf-available/freedombox.conf etc/apache2/conf-available
 data/etc/avahi/services/*.service etc/avahi/services
 data/etc/sudoers.d/freedombox etc/sudoers.d
diff --git a/first-run.d/80_flash-kernel b/first-run.d/80_flash-kernel
deleted file mode 100755
index e4f8f5d..000
--- a/first-run.d/80_flash-kernel
+++ /dev/null
@@ -1,30 +0,0 @@
-#!/bin/bash
-#
-# Update the kernel if package flash-kernel is install unless
-# requested otherwise.
-
-. /lib/lsb/init-functions
-
-if ! type flash-kernel > /dev/null 2>&1 ; then
-log_warning_msg "Skipped Flashing Kernel: flash-kernel is not installed."
-exit 0
-fi
-
-if [ -e /var/freedombox/dont-tweak-kernel ]
-then
-log_warning_msg "Skipped Flashing Kernel."
-exit 0
-else
-. /usr/lib/freedombox/machine-detect
-if [ "$MACHINE" = "dreamplug" ]; then
-kernel_version="$(/bin/ls /boot/vmlinuz-*-kirkwood | sort -rn | head -n1 | sed s#/boot/vmlinuz-##)"
-fi
-
-log_action_begin_msg "Flashing Kernel version $kernel_version "
-
-if flash-kernel "$kernel_version" ; then
-	log_action_end_msg 0
-else
-	log_action_end_msg 1
-fi
-fi
diff --git a/lib/machine-detect b/lib/machine-detect
deleted file mode 100755
index 498bf7a..000
--- a/lib/machine-detect
+++ /dev/null
@@ -1,35 +0,0 @@
-#!/bin/sh
-#
-# Exports the currently-detected hardware to MACHINE.
-#
-# Return true if the MACHINE was detected, and false otherwise.
-#
-# Currently look in /sys/devices for indicators.
-#
-# Other possibilities:
-#
-# echo $(cat /proc/device-tree/model)
-# Globalscale Technologies Dreamplug
-
-MACHINE=""
-
-case $(dpkg --print-architecture) in
-armel)
-	# Matches these:
-	# /sys/devices/gpio-leds.1/leds/dreamplug:blue:bluetooth
-	# /sys/devices/gpio-leds.1/leds/dreamplug:green:wifi_ap
-	# /sys/devices/gpio-leds.1/leds/dreamplug:green:wifi
-	if find /sys/devices -name 'dreamplug:*' | grep -q dreamplug: ; then
-MACHINE=dreamplug
-	fi
-	;;
-esac
-
-export MACHINE
-
-if [ -n "$MACHINE" ]
-then
-return 0
-fi
-
-return 1
-- 
2.8.1

Bug#816875: Update

[Dark Penguin]

I've tried it with relatively recent versions of x11vnc and 
tightvncserver on Debian Jessie and Linux Mint. It works. Apparently, it 
doesn't work with older versions of various VNC servers on various 
operating systems... but I don't think this is something that really 
needs to be fixed.


I think we can close this bug now. Sorry for not checking it with recent 
versions of VNC servers in the beginning - I did not have an opportunity 
back then...


--
darkpenguin

Bug#820897: Update

[Dark Penguin]

I've tried it with relatively recent versions of x11vnc and 
tightvncserver on Debian Jessie and Linux Mint. It works. Apparently, it 
doesn't work with older versions of various VNC servers on various 
operating systems - upon closer inspection, it seems that the Alt key 
tends to get "stuck" if you release it before releasing Shift... but I 
don't think this is something that really needs to be fixed.


I think we can close this bug now. Sorry for not checking it with recent 
versions of VNC servers in the beginning - I did not have an opportunity 
back then...



--
darkpenguin

Bug#825874: python-escript: FTBFS - netcdf.h not found under /usr

[Aaron M. Ucko]

Source: python-escript
Version: 4.2.0.1-1
Severity: serious
Justification: fails to build from source (but built successfully in the past)

Builds of python-escript in minimal environments (notably, on the
autobuilders) have been failing:

  RuntimeError: netcdf.h not found under /usr:
File "/«PKGBUILDDIR»/SConstruct", line 520:
  env=checkOptionalLibraries(env)
File "/«PKGBUILDDIR»/site_scons/dependencies.py", line 286:
  netcdf_inc_path,netcdf_lib_path=findLibWithHeader(env, 
env['netcdf_libs'], 'netcdf.h', env['netcdf_prefix'], lang='c++')
File "/«PKGBUILDDIR»/site_scons/site_init.py", line 44:
  raise RuntimeError('%s not found under %s'%(header,paths))
  debian/rules:58: recipe for target 'override_dh_auto_build' failed
  make[1]: *** [override_dh_auto_build] Error 2

Please declare a build dependency on libnetcdf-dev, and confirm with
pbuilder or the like that you haven't missed any others.  (Please note
that the build dependency on libnetcdf-cxx-legacy-dev is insufficient,
because that package does NOT depend on libnetcdf-dev, though perhaps
it should.)

Thanks!

Bug#825873: kodi-data depends on font unavailable in jessie/jessie-backports

[Jesse Rhodes]

Package: kodi
Version: 16.1+dfsg1-1~bpo8+1
Severity: important

Dear Maintainer,

When installing kodi from jessie-backports on a my media player running
jessie, I noticed that kodi-data depends on the 'fonts-roboto-hinted'
package, which only exists in sid and stretch at present. 

Thus the current kodi in jessie-backports is not installable. 

I self-backported fonts-roboto and installing that resolved the problem,
so my suggestion is that fonts-roboto should be maintained as a backport
as well. 

Please let me know if you need anything else, 

sney

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

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

Bug#816874: New information

[Dark Penguin]

First of all, I mistyped about LMDE: I mean, I'm using MATE on Jessie, 
of course.


Now, I've tried to gather more data.

- Click the Remmina tray icon, then quickly (within the double-click 
timeout) click one of the items in the context menu: the item is 
activated, but the main Remmina window also pops up. (This is what's 
most annoying.)


- Move the mouse over the tray icon, hold the left mouse button, quickly 
move the mouse over to some item in the context menu, release the 
button: the item is activated, but the main Remmina window also pops up.


- Left-click the tray icon, then immediately right-click it (just for 
testing purposes): the main Remmina window pops up.


However:

- Double-right-click the tray icon: nothing happens.

- Right-click the icon, then immediately left-click it: the main window 
does not pop up.


- Click the tray icon (the context menu pops up). Now, double-click the 
icon (intending to open the main window). It does not pop up - the 
context menu disappears and then reappears again, but the main window 
does not pop up.



--
darkpenguin

Bug#825872: [PATCH] explain how to enable the TPM's TRNG in README

[Nicholas D Steeves]

Package: rng-tools
Version: 2-unofficial-mt.14-1
Tags: patch

With a fresh install on a Xeon 1226 v3, reading 52KiB from /dev/random
occurs at ~20bits/s
Adding haveged gets it up to the ~60bits/s range
But wow, adding the TPM's TRNG gets it as high as ~2.58MiB/s !
Removing haveged at this point drops it to ~1.68KiB/s
Adding haveged bumps it back up again...

Yeah, something seems strange with these haveged results, but the
improvement from ~20bits/s to ~1.68KiB/s by mixing tpm_rng into the
pool is a *massive* improvement.  I used pv -pabet /dev/random >
/dev/null for my casual tests, and manually interrupted once the 52KiB
target was read.

Please use something like the following to patch the README:

diff -ur rng-tools-2-unofficial-mt.14.orig/README
rng-tools-2-unofficial-mt.14/README
--- rng-tools-2-unofficial-mt.14.orig/README2011-06-17
23:06:56.0 -0400
+++ rng-tools-2-unofficial-mt.14/README 2016-05-30 20:28:48.201323887 -0400
@@ -74,6 +74,10 @@
   A: Sorry, but you DON'T have a working TRNG.  Refer to the "testing rngd"
  section for more details.

+* Q: "I can't get the Intel TRNG to work, but I have a TPM.  Can I use it?"
+  A: Yes, like this: modprobe tpm-rng && echo tpm-rng >> /etc/modules && \
+ echo "Your TPM's TRNG has been enabled"
+
 * Q: "I see no errors anywhere, but rngd doesn't appear to be working.  Why?"
   A: See the "testing rngd" section for details.

Bug#825871: kmldonkey: Editing toolbar disables menu

[Francesco]

Package: kmldonkey
Version: 2.0.5+kde4.3.3-3
Severity: minor

Dear Maintainer,


  I tried to edit toolbar, for example adding or removing a button, and
menu bar disappeared. I found that it was set MenuBar=Disabled in
~/.kde/share/config/kmldonkeyrc, edited it to "Enabled" and it appeared
again. Under normal user it seems not to be used (is it Enabled by
default? It's not normally present in the file after one start and stop
kmldonkey).
  Another thing to report there is no way to enable/disable menu in 
graphical configuration nor there are shortcuts to do this, or maybe
shortcuts are undocumented.


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

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

Versions of packages kmldonkey depends on:
ii  kde-runtime4:15.08.3-1+b1
ii  libc6  2.22-9
ii  libgcc11:6.1.1-4
ii  libkde3support44:4.14.14-1+b2
ii  libkdecore54:4.14.14-1+b2
ii  libkdeui5  4:4.14.14-1+b2
ii  libkfile4  4:4.14.14-1+b2
ii  libkhtml5  4:4.14.14-1+b2
ii  libkio54:4.14.14-1+b2
ii  libkjsapi4 4:4.14.14-1+b2
ii  libknotifyconfig4  4:4.14.14-1+b2
ii  libkparts4 4:4.14.14-1+b2
ii  libnepomuk44:4.14.14-1+b2
ii  libnepomukutils4   4:4.14.14-1+b2
ii  libphonon4 4:4.9.0-2
ii  libplasma3 4:4.14.14-1+b2
ii  libqt4-dbus4:4.8.7+dfsg-7
ii  libqt4-network 4:4.8.7+dfsg-7
ii  libqt4-qt3support  4:4.8.7+dfsg-7
ii  libqt4-svg 4:4.8.7+dfsg-7
ii  libqt4-xml 4:4.8.7+dfsg-7
ii  libqtcore4 4:4.8.7+dfsg-7
ii  libqtgui4  4:4.8.7+dfsg-7
ii  libsoprano42.9.4+dfsg-3+b1
ii  libstdc++6 6.1.1-4

Versions of packages kmldonkey recommends:
ii  mldonkey-server  3.1.5-3+b1

kmldonkey suggests no packages.

-- no debconf information

Bug#825870: sysvinit-utils: Second stop command does not use process matchers name and pidfile

[Steven Roose]

Package: sysvinit-utils
Version: 2.88dsf-59
Severity: normal
Tags: patch

Dear Maintainer,

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

   * What led up to the situation?
I used /etc/init.d/skeleton to make a script for a daemon. 
The daemon does not make it's own pidfile, so I added following relevant 
variables:
PIDFILE=/pidfile
START_ARGS=" --make-pidfile"
STOP_ARGS=" --remove-pidfile"
NAME=
DAEMON=

   * What exactly did you do (or not do) that was effective (or
 ineffective)?
/etc/init.d/mydaemon start
/etc/init.d/mydaemon stop

   * What was the outcome of this action?
The following error message:
"start-stop-daemon: --remove-pidfile requires --pidfile"

   * What outcome did you expect instead?
The daemon would be stopped.


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

Kernel: Linux 3.16.0-4-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=locale: Cannot set 
LC_ALL to default locale: No such file or directory
UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages sysvinit-utils depends on:
ii  libc62.19-18+deb8u4
ii  libselinux1  2.3-2
ii  startpar 0.59-3

sysvinit-utils recommends no packages.

Versions of packages sysvinit-utils suggests:
pn  bootlogd  
pn  sash  

-- debconf information excluded
>From db2dcfa27188f4ba983f7bf74564ee942d8464b9 Mon Sep 17 00:00:00 2001
From: Steven Roose 
Date: Tue, 31 May 2016 01:56:44 +0200
Subject: [PATCH] Fix problem in do_stop_cmd() of init-d-script

The second stop command does not contain the --name and --pidfile identifiers.
---
 debian/init-d-script | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/debian/init-d-script b/debian/init-d-script
index 334dc32..3b2a51d 100755
--- a/debian/init-d-script
+++ b/debian/init-d-script
@@ -95,7 +95,7 @@ do_stop_cmd() {
 	# sleep for some time.
 	start-stop-daemon --stop --quiet --oknodo --retry=0/30/KILL/5 \
 	$STOP_ARGS \
-	--exec $DAEMON
+	${PIDFILE:+--pidfile ${PIDFILE}} --name $NAME --exec $DAEMON  
 	[ "$?" = 2 ] && return 2
 	# Many daemons don't delete their pidfiles when they exit.
 	rm -f $PIDFILE
-- 
1.9.1

>From db2dcfa27188f4ba983f7bf74564ee942d8464b9 Mon Sep 17 00:00:00 2001
From: Steven Roose 
Date: Tue, 31 May 2016 01:56:44 +0200
Subject: [PATCH] Fix problem in do_stop_cmd() of init-d-script

The second stop command does not contain the --name and --pidfile identifiers.
---
 debian/init-d-script | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/debian/init-d-script b/debian/init-d-script
index 334dc32..3b2a51d 100755
--- a/debian/init-d-script
+++ b/debian/init-d-script
@@ -95,7 +95,7 @@ do_stop_cmd() {
 	# sleep for some time.
 	start-stop-daemon --stop --quiet --oknodo --retry=0/30/KILL/5 \
 	$STOP_ARGS \
-	--exec $DAEMON
+	${PIDFILE:+--pidfile ${PIDFILE}} --name $NAME --exec $DAEMON  
 	[ "$?" = 2 ] && return 2
 	# Many daemons don't delete their pidfiles when they exit.
 	rm -f $PIDFILE
-- 
1.9.1

Bug#825794: procmail: attachments containing the string From at the beginning of a line confuse procmail

[Rick Thomas]

On May 30, 2016, at 2:36 AM, Santiago Vila  wrote:

> On Sun, 29 May 2016, Rick Thomas wrote:
> 
>> Package: procmail
>> Version: 3.22-24
>> Severity: normal
>> 
>> Dear Maintainer,
>> 
>> *** Reporter, please consider answering these questions, where appropriate 
>> ***
>> 
>> If procmail processes a mail with body containing a plaintext attachment 
>> that has a line
>> that begins with the string "From " it seems to think this is a separator 
>> between mails.
>> It winds up splitting the original mail into two parts and filing each as a 
>> separate mail
>> item.
>> 
>> This can happen when the attachment is a mail item that has not had the 
>> proper quoting
>> for lines beginning with "From ".  I have attached such an email to this 
>> bugreport.
> 
> procmail does not split anything unless explicitly told.
> 
> In fact, it is usually "formail -s" who split emails, not procmail.
> 
>> There needs to be some way of telling procmail that it will receive input 
>> one email item
>> at a time, (as when being fed by fetchmail) so the line-begins-with-From 
>> processing is
>> not necessary.
> 
> And there is a way indeed, which is to use procmail alone, not "formail -s 
> procmail".
> 
> Your report says "If procmail processes a mail". What do you mean
> exactly by "processes a mail"? Could you please be more explicit?
> A sample email is good, but the report is incomplete if you don't
> tell me what I'm supposed to do with the email.
> 
> Thanks.

Thank you very much, Santiago, for the prompt reply!

Here’s the setup:

I have a POP/IMAP account at pobox.com.  I use cron to run fetchmail which 
retrieves (POP3) mail from pobox to a local server on my home network.
I process the retrieved mail with procmail to split it into folders and 
subfolders based on who it’s from, addressed to, subject, etc…

Here’s the .fetchmailrc file”:
= .fetchmailrc ===
# Configuration created Thu Aug 15 20:08:16 2002 by fetchmailconf
# Lightly edited later by Rick Thomas
set postmaster "rbthomas"
set bouncemail
set no spambounce
set properties ""
# set syslog

poll mail.pobox.com with proto POP3 timeout 20 and options uidl
   user 'XXX' there with password 'YY' is 'rbthomas' here options 
keep ssl 

mda "formail -s procmail"
==

As I interpret your reply, I should be using a different mda — NOT formail.  
Can you give me some hint as to what it should look like?

Thanks!
Rick

Bug#825869: new upstream release of netrek-client-cow

[James Cameron]

Package: netrek-client-cow
Version: 3.3.0-3.1

New upstream release available; 3.3.1

http://www.netrek.org/files/COW/netrek-client-cow-3.3.1.tar.gz
http://mailman.us.netrek.org/pipermail/netrek-dev/2011-October/005754.html

We restored server from an older backup after 3.3.1 release.

Happy to take any patches.

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

Bug#822504: Duplicate Word Check - More False Positives

[Paul Hardy]

thanks

I have a duplicate spelling warning in three Unifont packages:

ttf-unifont
unifont
xfonts-unifont

The error is from the debian/description file common to all three
(same mistaken duplicate as the original bug report, different file):

spelling-error-in-description Plane Plane (duplicate word) Plane

I have text in the debian/ directory and in some other places of the form

"Basic Multilingual Plane (Plane 0)"
"Supplemental Multilingual Plane (Plane 1)"

In my case, there is intervening punctuation, '(', between the words.
Maybe you can allow for that situation in your pattern matching (if
you don't remove the duplicate checking, as you mentioned you might).
You can see these listed at:

https://lintian.debian.org/full/unifoun...@unifoundry.com.html#unifont_1_x3a8.0.01-1

On the other hand, the spelling checker did find two legitimate
spelling errors.  I am fixing those in my next upload.  I mentioned
the deltas in my ChangeLog file, so the spell checker will probably
complain about those misspellings in that file.

Thank you for your work on Lintian!


Paul Hardy

Bug#825868: e2fsprogs: isn't Recommends on fuse2fs too much?

[Christoph Anton Mitterer]

Package: e2fsprogs
Version: 1.43-3
Severity: wishlist


Hi.

Is there anything that the e2fsprogrs package itself gains from
having fuse2fs installed (as it would be in default configurations)?

Perhaps a Suggests on it would be enough, if at all.


Cheers,
Chris.

Bug#824778: cinnamon: consider to recommen gtk3-nocsd

[Christoph Anton Mitterer]

Hey Margarita.

On Fri, 2016-05-27 at 20:44 +, Margarita Manterola wrote:
> I tested gtk3-nocsed as it currently is in stretch and the result 
> wasn't very nice.
Well there are some bugs in it, which are to be fixed in the next
uploads which is going to happen pretty soon.

But I think your judgement is a bit harsh, isn't it?



>  I'm not sure what it is supposed to do, but I 
> was sort of expecting a File/Edit/View menu.  Instead, what I got 
> was a window title on top of the CSD window title and it really 
> didn't look good to me.
> 
> Is this how it's supposed to look?

Well, the CSDs are IMHO a highly questionable "feature" and not only
completely useless for desktops (they might have some value on small-
screen devices like smart phones) and the way upstream implemented it
or better said, the way upstream projects that use CSDs implemented it
is the typical GNOME hostile way: not obeying other peoples needs, not
being compatible to long proven standards and concepts.

So AFAIU, there is no real automatic way of getting back proper old
looks (i.e. wit menus, etc. as you wished)... and unless the respective
projects upstream supports both modes (CSD / non-CSD) as e.g. gnome-
terminal seems to do (at least so far),... the results we get from
gtk3-nocsd is the best one can have.

It's not necessarily perfect, but that's rather the fault of CSDs, less
of gtk3-nocsd and at least it gives people back proper window
decorations.
So IMHO, it's still pretty valuable for non GNOME3 users.


> > I've CCed, Christian, the gtk3-nocsd maintainer (and as it seems
> > most active upstream dev)...perhaps he has some ideas to share
> > about this one.
> 
> You don't seem to have done this.

mhh.. strange... I though I'd have added him in reportbug.
CCing him again now, just in case he's interested.


Cheers,
Chris.

smime.p7s
Description: S/MIME cryptographic signature

Bug#492432: aptitude: fetch and display copyright (like changelog)

[Mike Gerow]

On Mon, May 30, 2016 at 02:35:04PM +0200, David Kalnischkies wrote:
> Ideally, this would be implemented in libapt directly. It nowadays
> sports a pkgAcqChangelog which deals with most of the complexity around
> changelogs including the constructing the URI (as different archives
> have different storage places and such) [which from a casual look seem
> not to be used by aptitude which constructs the URI on its own (for
> Debian only)].
> 
> A good way to deal with this hence might perhaps be to fully adopt
> pkgAcqChangelog in aptitude, mostly copy pkgAcqChangelog and paste as
> pkgAcqCopyright in libapt (src:apt) and copy the changelog-code in
> aptitude to deal with copyright [Bonuspoints if abstraction is used
> instead of copy].
Alright, that makes a lot of sense. I'll take a look at libapt and see if
there's a nice way add support for fetching the copyright info without too much
copy/pasting.

> I can't speak for the aptitude team of course, but at least for the apt
> team and I would be happy to help on the apt side. If you are interested
> feel free to ask me (DonKult), us (de...@lists.debian.org) and/or on IRC
> (#debian-apt – where apt & aptitude people hang out together)!
I'll definitely drop the irc by when I inevitably have qestions. Thanks!

-- 
Mike Gerow
ge...@mgerow.com


signature.asc
Description: PGP signature

Bug#825394: systemd kill background processes after user logs out

[erdnaxeli]

On Mon, 30 May 2016 22:19:48 +0200 John Paul Adrian Glaubitz <
glaub...@physik.fu-berlin.de> wrote:
> Hi!
>
> > don't think the right response should be to just fix it one way
> > for everyone, especially not since those people in charge of hundreds
> > of systems have exactly one vote, similar to those who just develop
> > for their own home workstation.
>
> I'm sorry, but this is a very bad argument. People who are in charge
> of hundreds of systems almost never use the default settings but use
> something like FAI, Puppet or ansible to configure their systems
> exactly the way they need them. No one is installing hundreds of
> computers manually with the d-i images like you would do on a single
> machine, that would just be nuts. And in these scenarios, changing
> the default settings of configuration files in packages is a daily
> routine and nothing special. So, this change has *zero* negative
> impact for these users.
>
> As for the usefulness of this change: I used to work at the IT departmant
> of a large university in the past and I have some experience in this
regard.
> In fact, this particular change in systemd solves a *very* common problem
in
> these setups which are leftover processes on the computers in the student
computer
> pools as around at least a dozen different users are logging in and out
again
> on these machines per day with many different processes still staying
around, and,
> no, this is not particularly a GNOME problem - it's a general problem
which
> is usually solved with a cron job which kills leftover processes
regularly.
>
> Some people here suggested that, instead of adding such a functionality to
> the session manager, affected projects should just fix their software
which
> effectively translates to "People should write bug-free software" which
> is, of course, an unrealistic goal and therefore not really adding to
> the discussion in any fruitful manner.
>
> Thus, the systemd approach is actually sane and exactly what most admins
of
> larger setups with many users want. And it's not that the systemd
developers
> did not provide an opt-out solution. As it was clearly documented in the
> release notes, users are free to disable this feature or use systemd-run
> to explicitly prevent a process from being killed upon logout which is
> *exactly* what every admin wants: Processes should be killed upon logout
> by default and anything that should remain running should request an
> explicit permission from the session management. There is really no other
> good way to tackle this problem. Admins will neither be able to prevent
> buggy software (since users could just write and run their own buggy
> software) nor is it practical to keep a long black list with runaway
> processes which are being killed upon logout.

I don't understand something. You are a sysadmin, in an IT department. So I
suppose
you use something like « FAI, Putter or ansible to configure [your] systems
». Why
can't *you* set the right option you want? The feature already exists!

I think the problem is not about the feature. The problem is only about the
default value. The solution with debconf seems pretty good to me for end
users,
and the sysadmin already know what they want, as you say it.

>
> It's honestly very frustrating to read bug reports like these as they
> are usually written by people who lack the necessary background or refuse
> to accept that their particular use case is not the common use case. And I
> have more the impression that these bug reports are merely written to
> stir up emotions because, again, the systemd developers dared to touch
> something in the Linux software stack which has not been touch for years
> while solving yet another long-existing problem. A reasonable person
wouldn't
> even mind about such changes. They would either just disable the feature
> completely or use the provided mechanisms to white-list individual
processes
> which takes less time than writing up such a bug report and stirring up
> emotions.
>
> Thanks,
> Adrian
>


Alexandre Morignot

Bug#825867: adduser: [INTL:pt] Updated Portuguese translation - program and manpage

[Américo Monteiro]

Package: adduser
Version: 3.115
Tags: l10n, patch
Severity: wishlist

Updated Portuguese translation for adduser's program and manpage.
Translator: Américo Monteiro 
Feel free to use it.

For translation updates please contact 'Last Translator' or the
Portuguese Translation Team .

-- 
Melhores cumprimentos/Best regards,

Américo Monteiro

adduser_3.115_pt.po.gz
Description: application/gzip


adduser_manpage_3.115_pt.po.gz
Description: application/gzip

Bug#825866: using "=" to hold a package is not interoperable with apt-get

[Jeffrey Sheinberg]

Package: aptitude
Version: 0.6.11-1+b1
Severity: normal

Dear Maintainer,

If I set a package status to hold using dpkg-hold, then the hold is
honored by aptitude, apt-get, and dselect.

If I set a package status to hold using aptitude's "=" cpmmand, then the
hold is honored by aptitude, but the hold is not honored by either
apt-get or by dselect.

Thanks,
Jeffrey Sheinberg


-- Package-specific info:
Terminal: xterm
$DISPLAY is set.
which aptitude: /usr/bin/aptitude

aptitude version information:
aptitude 0.6.11 compiled at Nov  8 2014 13:34:39
Compiler: g++ 4.9.1
Compiled against:
  apt version 4.12.0
  NCurses version 5.9
  libsigc++ version: 2.4.0
  Gtk+ support disabled.
  Qt support disabled.

Current library versions:
  NCurses version: ncurses 5.9.20140913
  cwidget version: 0.5.17
  Apt version: 4.12.0

aptitude linkage:
linux-vdso.so.1 (0x7ffd09d5e000)
libapt-pkg.so.4.12 => /usr/lib/x86_64-linux-gnu/libapt-pkg.so.4.12 
(0x7f32e601c000)
libncursesw.so.5 => /lib/x86_64-linux-gnu/libncursesw.so.5 
(0x7f32e5de6000)
libtinfo.so.5 => /lib/x86_64-linux-gnu/libtinfo.so.5 
(0x7f32e5bbb000)
libsigc-2.0.so.0 => /usr/lib/x86_64-linux-gnu/libsigc-2.0.so.0 
(0x7f32e59b5000)
libcwidget.so.3 => /usr/lib/x86_64-linux-gnu/libcwidget.so.3 
(0x7f32e569f000)
libsqlite3.so.0 => /usr/lib/x86_64-linux-gnu/libsqlite3.so.0 
(0x7f32e53d5000)
libboost_iostreams.so.1.55.0 => 
/usr/lib/x86_64-linux-gnu/libboost_iostreams.so.1.55.0 (0x7f32e51bd000)
libxapian.so.22 => /usr/lib/x86_64-linux-gnu/libxapian.so.22 
(0x7f32e4da6000)
libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 
(0x7f32e4b88000)
libstdc++.so.6 => /usr/lib/x86_64-linux-gnu/libstdc++.so.6 
(0x7f32e487d000)
libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x7f32e457c000)
libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 
(0x7f32e4365000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x7f32e3fba000)
libutil.so.1 => /lib/x86_64-linux-gnu/libutil.so.1 (0x7f32e3db7000)
libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x7f32e3bb2000)
libz.so.1 => /lib/x86_64-linux-gnu/libz.so.1 (0x7f32e3997000)
libbz2.so.1.0 => /lib/x86_64-linux-gnu/libbz2.so.1.0 
(0x7f32e3787000)
liblzma.so.5 => /lib/x86_64-linux-gnu/liblzma.so.5 (0x7f32e3563000)
librt.so.1 => /lib/x86_64-linux-gnu/librt.so.1 (0x7f32e335b000)
libuuid.so.1 => /lib/x86_64-linux-gnu/libuuid.so.1 (0x7f32e3155000)
/lib64/ld-linux-x86-64.so.2 (0x55f40ed9e000)

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

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

Versions of packages aptitude depends on:
ii  aptitude-common   0.6.11-1
ii  libapt-pkg4.121.0.9.8.3
ii  libboost-iostreams1.55.0  1.55.0+dfsg-3
ii  libc6 2.19-18+deb8u4
ii  libcwidget3   0.5.17-2
ii  libgcc1   1:4.9.2-10
ii  libncursesw5  5.9+20140913-1+b1
ii  libsigc++-2.0-0c2a2.4.0-1
ii  libsqlite3-0  3.8.7.1-1+deb8u1
ii  libstdc++64.9.2-10
ii  libtinfo5 5.9+20140913-1+b1
ii  libxapian22   1.2.22-3~bpo8+1

Versions of packages aptitude recommends:
ii  aptitude-doc-en [aptitude-doc]  0.6.11-1
ii  libparse-debianchangelog-perl   1.2.0-1.1
ii  sensible-utils  0.0.9

Versions of packages aptitude suggests:
ii  apt-xapian-index  0.47
ii  debtags   1.12.3
ii  tasksel   3.31+deb8u1

-- no debconf information

Bug#652999: xfce4-terminal: please add a way to disable (redefine?) middle click running mailto:

[Matt Taggart]

This bug is a couple years old, but I still would like a way to change
this behavior. Has anything happened upstream?

Thanks,

-- 
Matt Taggart
tagg...@debian.org

Bug#822085: future of root-system: removal?

[Mattia Rizzolo]

Hi science people!

So, not root-system got entangled it Yet Another Transition (actually
this is only the remaining decrufting from sid): openssl.

The old binaries still there depend on libssl1.0.0, whilst now there is
libssl1.0.2, removing SSLv3 methods.
I also see this as a kind of important (as security-related) change that
really needs to be done.

I saw nobody willing to step trying to tackle and tame that huge beast,
I tried earlier in the year, but ran out of steam without managing to do
anything useful.

So, IMHO, we should just remove it, until somebody else doing another
physic PhD comes wanting to put it back for another bunch of years,
maybe improving the scripts around and making the maintenance easy also
to one-time shooters.

There are only 2 rdeps, fastjet and rivet, and they do it only for 2
binary packages, which could be just dropped¹.

I'm CCing the person listed in the Uploaders field of all those 3
packages, which seems to be gone.

If once again I'm not hearing any complaint in 2 weeks or so I'll team
upload rivet and fastjet to drop the binaries depending on root, and
then RM root itself.

Thanks for listening and reading till now :)



¹ On a related note, also fastject and river and their rdeps herwig++
and thepeg and their rdep pythia8 and its rdep hepmc could just go:
there is currently nobody caring, some have NMUs, and the maintainer is
seemingly gone.  They are not bothering me though, so I'm not going to
to ask for RM of them anytime soon.

-- 
regards,
Mattia Rizzolo

GPG Key: 66AE 2B4A FCCF 3F52 DA18  4D18 4B04 3FCD B944 4540  .''`.
more about me:  https://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#825865: glibc: Testsuite failure on sparc64 due to unaligned access in wcsmbs/test-wcsncmp.c

[John Paul Adrian Glaubitz]

Source: glibc
Version: 2.22-9
Severity: normal
Tags: patch
User: debian-sp...@lists.debian.org
Usertags: sparc64

Hi!

glibc currently fails to build from source on sparc64 due at least one test
in the testsuite failing which is due to a bus error (unaligned access):

--
XFAIL: wcsmbs/test-wcsncmp
original exit status 1
wcsncmp simple_wcsncmp  stupid_wcsncmp
Didn't expect signal from child: got `Bus error'
--

I have notified glibc upstream of these issue - not in a bug report but by
talking to one of the developers and I have now a patch that fixes the
problem [1].

This patch applies cleanly to glibc 2.22-9 in Debian unstable when dropping
the Changelog part from the upstream patch, so I'm attaching a patch with
this part removed as a suggestion for what to include in the Debian package.

Please note: I was still getting some spurious test failures in rt/tst-mqueue5
due to timeouts. But those could also be a local issue which needs some further
investiogation (might be related to TIMEOUTFACTOR in debian/build.mk).

Cheers,
Adrian

> [1] https://sourceware.org/ml/libc-alpha/2016-05/msg00710.html

-- 
 .''`.  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
Description: Fix string/test-strncmp.c to work with wide chars.
 wcsmbs/test-wcsncmp.c (i.e. string/test-strncmp with defined WIDE)
 triggers a signal in aligment-strict platforms, like sparc*-*-*.
 .
 This patch fixes string/test-strncmp.c to work properly when the test is
 performed on arrays of wide chars.  This includes passing align1 and
 align2 to do_test as bytes, and to use more meaningful values for middle
 chars and large chars.
 .

--- glibc-2.22.orig/string/test-strncmp.c
+++ glibc-2.22/string/test-strncmp.c
@@ -38,6 +38,8 @@
 # define CHAR wchar_t
 # define UCHAR wchar_t
 # define CHARBYTES 4
+# define MIDCHAR 0x7fff
+# define LARGECHAR 0xfffe
 # define CHAR__MAX WCHAR_MAX
 # define CHAR__MIN WCHAR_MIN
 
@@ -88,6 +90,8 @@ stupid_wcsncmp (const CHAR *s1, const CH
 # define CHAR char
 # define UCHAR unsigned char
 # define CHARBYTES 1
+# define MIDCHAR 0x7f
+# define LARGECHAR 0xfe
 # define CHAR__MAX CHAR_MAX
 # define CHAR__MIN CHAR_MIN
 
@@ -414,56 +418,56 @@ test_main (void)
 
   for (i =0; i < 16; ++i)
 {
-  do_test (0, 0, 8, i, 127, 0);
-  do_test (0, 0, 8, i, 127, -1);
-  do_test (0, 0, 8, i, 127, 1);
-  do_test (i, i, 8, i, 127, 0);
-  do_test (i, i, 8, i, 127, 1);
-  do_test (i, i, 8, i, 127, -1);
-  do_test (i, 2 * i, 8, i, 127, 0);
-  do_test (2 * i, i, 8, i, 127, 1);
-  do_test (i, 3 * i, 8, i, 127, -1);
-  do_test (0, 0, 8, i, 255, 0);
-  do_test (0, 0, 8, i, 255, -1);
-  do_test (0, 0, 8, i, 255, 1);
-  do_test (i, i, 8, i, 255, 0);
-  do_test (i, i, 8, i, 255, 1);
-  do_test (i, i, 8, i, 255, -1);
-  do_test (i, 2 * i, 8, i, 255, 0);
-  do_test (2 * i, i, 8, i, 255, 1);
-  do_test (i, 3 * i, 8, i, 255, -1);
+  do_test (0, 0, 8, i, MIDCHAR, 0);
+  do_test (0, 0, 8, i, MIDCHAR, -1);
+  do_test (0, 0, 8, i, MIDCHAR, 1);
+  do_test (CHARBYTES * i, CHARBYTES * i, 8, i, MIDCHAR, 0);
+  do_test (CHARBYTES * i, CHARBYTES * i, 8, i, MIDCHAR, 1);
+  do_test (CHARBYTES * i, CHARBYTES * i, 8, i, MIDCHAR, -1);
+  do_test (CHARBYTES * i, 2 * CHARBYTES * i, 8, i, MIDCHAR, 0);
+  do_test (2 * CHARBYTES * i, CHARBYTES * i, 8, i, MIDCHAR, 1);
+  do_test (CHARBYTES * i, 3 * CHARBYTES * i, 8, i, MIDCHAR, -1);
+  do_test (0, 0, 8, i, LARGECHAR, 0);
+  do_test (0, 0, 8, i, LARGECHAR, -1);
+  do_test (0, 0, 8, i, LARGECHAR, 1);
+  do_test (CHARBYTES * i, CHARBYTES * i, 8, i, LARGECHAR, 0);
+  do_test (CHARBYTES * i, CHARBYTES * i, 8, i, LARGECHAR, 1);
+  do_test (CHARBYTES * i, CHARBYTES * i, 8, i, LARGECHAR, -1);
+  do_test (CHARBYTES * i, 2 * CHARBYTES * i, 8, i, LARGECHAR, 0);
+  do_test (2 * CHARBYTES * i, CHARBYTES * i, 8, i, LARGECHAR, 1);
+  do_test (CHARBYTES * i, 3 * CHARBYTES * i, 8, i, LARGECHAR, -1);
 }
 
   for (i = 1; i < 8; ++i)
 {
-  do_test (0, 0, 8 << i, 16 << i, 127, 0);
-  do_test (0, 0, 8 << i, 16 << i, 127, 1);
-  do_test (0, 0, 8 << i, 16 << i, 127, -1);
-  do_test (0, 0, 8 << i, 16 << i, 255, 0);
-  do_test (0, 0, 8 << i, 16 << i, 255, 1);
-  do_test (0, 0, 8 << i, 16 << i, 255, -1);
-  do_test (8 - i, 2 * i, 8 << i, 16 << i, 127, 0);
-  do_test (8 - i, 2 * i, 8 << i, 16 << i, 127, 1);
-  do_test (2 * i, i, 8 << i, 16 << i, 255, 0);
-  do_test (2 * i, i, 8 << i, 16 << i, 255, 1);
-}
-
-  do_test_limit (0, 0, 0, 0, 127, 0);
-  do_test_limit (4, 0, 21, 20, 127, 0);
-  do_test_limit (0, 4, 21, 20, 127, 0);
-  do_test_limit (8, 0, 25, 24, 127, 0);
-  do_test_limit (0, 8, 25, 24, 127, 0);
+  do_test (0, 0, 8 << i, 16 << i, MIDCHAR, 

Bug#823314: rkt 1.5.0 can't start ACI because of missing systemd-sysusers binary

[Dmitry Smirnov]

Could we introduce raw "systemd-sysusers" binary ASAP to fix "rkt" please?

Other supporting files can be added later at your convenience.

I understand there were no objections so what are we waiting for?

Pretty please?

-- 
Best wishes,
 Dmitry Smirnov.

---

No person, no idea, and no religion deserves to be illegal to insult,
not even the Church of Emacs.
-- Richard Stallman


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

Bug#804619: tlsdate: FTBFS: undefined reference to `SSLv3_client_method'

[Sebastian Andrzej Siewior]

On 2016-05-30 21:40:17 [+], Mattia Rizzolo wrote:
> Hello everybody!
Hi,

> Is anybody working on this?
> We would like to proceed with the complete RM of the old libssl1.0.0
> library, and this package is one of the very few left.

A side note: if we apply the patch then it builds against current libssl
but not against the not yet released libssl1.1.0 [0] currently in exp.

[0] 
https://breakpoint.cc/openssl-1.1-rebuild-2016-05-29/Attempted/tlsdate_0.0.13-1_amd64-20160529-1544

Sebatian

Bug#825858: systemd-insserv-generator shouldn't create insserv dependencies if the unit is masked

[Felipe Sateler]

On 30 May 2016 at 16:25, Laurent Bigonville  wrote:
> Hi,
>
> rpcbind is now providing a .service file, but the
> systemd-insserv-generator is still creating dependency information base
> on it:

Indeed. The long term solution is to drop insserv-generator (bugs
missing, I should finally sit and file them...).

But given the speed at which things are moving (we don't even have
bugs yet!), it may be worthwhile to borrow the check used in the
sysv-generator[1] and put it in the insserv-generator before checking
if the initscript exists[2]

[1] 
http://sources.debian.net/src/systemd/230-1/src/sysv-generator/sysv-generator.c/#L828-L835
[2] 
http://sources.debian.net/src/systemd/230-1/src/insserv-generator/insserv-generator.c/#L204


-- 

Saludos,
Felipe Sateler

Bug#825864: ITP: sedutil -- Tool to use functionality of Self Encrypting Drives (SED) that comply with the TCG OPAL 2.00 standard

[Jan Luca Naumann]

Package: wnpp
Severity: wishlist
Owner: Jan Luca Naumann 

* Package name: sedutil
  Version : 1.12
  Upstream Author : Bright Plaza Inc. , r0m30 

* URL : https://github.com/Drive-Trust-Alliance/sedutil
* License : GPL
  Programming Lang: C++
  Description : Tool to use functionality of Self Encrypting Drives (SED) 
that comply with the TCG OPAL 2.00 standard

Tool to use functionality of Self Encrypting Drives (SED) that comply with the 
TCG OPAL 2.00 standard. 

The tool includes a Pre-Boot Authorization image to unlock the drive 
independently of the BIOS functions.

The package allows users to use their OPAL disks with free software.

I need a sponsor for the package to upload it to Debian.

Bug#825394: systemd kill background processes after user logs out

[martin f krafft]

also sprach John Paul Adrian Glaubitz  
[2016-05-30 23:30 +0200]:
> Well, come on. Look what the usual arguments against it are: "This
> has been the default for the past 30 years and now it has changed
> and I am forced to change two options." This is not, by any
> stretch, a technical argument. This is just being against change
> for the sake of it being a change.

Wrong conclusion. If you don't understand the value of being able to
consider more than just the technical side, then maybe Debian isn't
the right project for you.

-- 
 .''`.   martin f. krafft  @martinkrafft
: :'  :  proud Debian developer
`. `'`   http://people.debian.org/~madduck
  `-  Debian - when you have better things to do than fixing systems
 
eleventh law of acoustics:
  in a minimum-phase system there is an inextricable link between
  frequency response, phase response and transient response, as they
  are all merely transforms of one another. this combined with
  minimalization of open-loop errors in output amplifiers and correct
  compensation for non-linear passive crossover network loading can
  lead to a significant decrease in system resolution lost. however,
  of course, this all means jack when you listen to pink floyd.


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

Bug#784316: Please do not remove hoauth

[Joachim Breitner]

Hi John,

nice to hear from you again.

Am Montag, den 30.05.2016, 15:40 -0500 schrieb John Goerzen:
> Hello folks,
> 
> I know I have had no time to work on my Haskell packages in awhile - but
> I am working to get them all into shape.
> 
> Bug 784316 requested twidge upgrade to hoauth2.  Unfortunately, twitter
> is still using OAuth 1.0A [1].  A request to support it in the hoauth2
> library was rejected for this reason. [2]   Therefore, hoauth is still
> required for building a twitter client, and therefore is still required
> for twidge.
> 
> The other fixes required are mostly trivial and I hope to fix the
> remaining items and add a number of features in the coming days as well.
> 
> Can we, therefore, keep hoauth in sid?

hmm, according to https://packages.qa.debian.org/h/hoauth.html you are
5 days too late to ask this.

Of course it can still be added back. I would be happier, though, if it
(hand twidge) were to enter stackage as well, as this gives us better
QA. It’s easy to do: http://www.stackage.org/authors

Greetings,
Joachim

PS: Happy landings from a fellow air-traveler (though unmotorized –
paragliding).


-- 
Joachim “nomeata” Breitner
Debian Developer
  nome...@debian.org • https://people.debian.org/~nomeata
  XMPP: nome...@joachim-breitner.de • GPG-Key: 0xF0FBF51F
  https://www.joachim-breitner.de/

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

Bug#822777: cinnamon-control-center: There are not Gtk-3 themes in the list of window themes, only Gtk-2.

[Christoph Anton Mitterer]

On Sun, 2016-05-29 at 11:02 +, Margarita Manterola wrote:
> Yes, I noticed yesterday that with the minimal install there are no 
> window border themes.
Strange... especially because the Adwaita package is installed...


>  I'm adding metacity-common as a 
> recommends for the cinnamon package, so that there will be 
> windowing themes to choose from.
hmm sounds like some other issue however, if a package from a specific
WM that isn't even used, is needed to get themes from other, installed
packages, usable.

Wouldn't it be better to have, whatever metacity-common contains
special that is needed to make the themes visible, be put in another *-
common package?

> > >Can you please clarify how you downloaded and how you installed 
> > > the mentioned theme?
> > I'm only using the themes from Debian packages.
> 
> Ok, so Maxy tells me that there was some conversation on IRC 
> that I missed about this.  Apparently by the end of this
> conversation 
> it was figured that only themes with both GTK2 and GTK3 
> engines are taken into account, which makes sense given 
> that we currently still have GTK2 programs.
> 
> So, I guess this part is working as intended, and then the fact 
> that no theme is shown is due to the lack of metacity-common, 
> which will be fixed in cinnamon's next upload.

Hmm I see... but why does adwaita then show up for the controls themes,
if it would have no gtk2 version?


> Do you agree?
Well I don't know too little of the inner workings of GTK2/3 themes,
that I could judge a lot here.
I just think it seems a bit odd, that cinnamon, which has nothing to do
with metacity, would need to depend on one of its package.


Cheers,
Chris.

smime.p7s
Description: S/MIME cryptographic signature

Bug#803112: Upgrading kernel fixes bug

[debianbug...@gmail.com]

I discovered that upgrading to kernel linux-image-4.5.0-2-amd64 fixes 
this bug completely. To be clear I was on 3.14-rt beforehand and didn't 
have the correct package installed for the kernel to auto-update to 
newer versions.


However for the benefit of others it's probably worth noting that with 
the 4.5.0-2 kernel I get another bug, which causes these errors when 
switching consoles with Ctrl-Alt-F[1-9]:


[drm:intel_set_cpu_fifo_underrun_reporting [i915]] *ERROR* uncleared 
fifo underrun on pipe A

[drm:ironlake_irq_handler [i915]] *ERROR* CPU pipe A FIFO underrun
[drm:intel_set_pch_fifo_underrun_reporting [i915]] *ERROR* uncleared pch 
fifo underrun on pch transcoder A

[drm:cpt_irq_handler [i915]] *ERROR* PCH transcoder A FIFO underrun

Sometimes this can cause a crash. So I've compiled the mainline kernel 
4.7.0-rc1 (not tested any lower versions yet). Finally everything seems 
to be working OK!

Bug#804619: tlsdate: FTBFS: undefined reference to `SSLv3_client_method'

[Mattia Rizzolo]

Hello everybody!

On Wed, Apr 27, 2016 at 09:18:46PM +, Holger Levsen wrote:
> On Wed, Apr 27, 2016 at 09:59:07PM +0200, Sebastian Andrzej Siewior wrote:
> > control: tags -1 +patch
> [...]
> > The patch attached fixes the problem by sticking to the SSLv23_*
> > function as suggested by Kurt.
> 
> Sebastian, thanks for your patch! Now let's see what upstream (hi
> Jacob! :) says to it…

Is anybody working on this?
We would like to proceed with the complete RM of the old libssl1.0.0
library, and this package is one of the very few left.

-- 
regards,
Mattia Rizzolo

GPG Key: 66AE 2B4A FCCF 3F52 DA18  4D18 4B04 3FCD B944 4540  .''`.
more about me:  https://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#825852: icedove: segfault

[Carsten Schoenert]

On Mon, May 30, 2016 at 10:22:30PM +0100, George B. wrote:
 
> Thanks for the hint! I attach the output of `thread apply all bt` (as a file 
> because it is so big).

Can you please describe what you have done and on which action the
segfault is happening?

So I can only see something related to the JS engine. That can be
everything.

Regards
Carsten

Bug#744003: zfs nfs exports

[Joel Nelson]

This is preventing zfs nfs exports from working. They're configured with
'zfs set sharenfs', no need to touch /etc/exports

Bug#805112: uploaded on deferred/0

[Gianfranco Costamagna]

control: tags -1 patch
control: tags -1 pending

The following debdiff has been uploaded on deferred/0.

Please update also zorp/zorpll to the latest upstream releases.

thanks

G.
diff -Nru zorp-3.9.5/debian/changelog zorp-3.9.5/debian/changelog
--- zorp-3.9.5/debian/changelog 2015-06-30 22:00:37.0 +0200
+++ zorp-3.9.5/debian/changelog 2016-05-30 21:54:44.0 +0200
@@ -1,3 +1,12 @@
+zorp (3.9.5-7.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * d/p/remove-ssl3.patch:
+- remove deprecated SSL3 function to fix FTBFS with
+  recent openssl (Closes: #805112).
+
+ -- Gianfranco Costamagna   Mon, 30 May 2016 
11:10:43 +0200
+
 zorp (3.9.5-7) unstable; urgency=medium
 
   * [1c630b8] Added a basic autopkgtest test case.
diff -Nru zorp-3.9.5/debian/patches/remove-ssl3.patch 
zorp-3.9.5/debian/patches/remove-ssl3.patch
--- zorp-3.9.5/debian/patches/remove-ssl3.patch 1970-01-01 01:00:00.0 
+0100
+++ zorp-3.9.5/debian/patches/remove-ssl3.patch 2016-05-30 21:53:59.0 
+0200
@@ -0,0 +1,21 @@
+Description: Remove ssl3 methods.
+Author: Gianfranco Costamagna 
+
+--- zorp-3.9.5.orig/lib/proxyssl.c
 zorp-3.9.5/lib/proxyssl.c
+@@ -1372,6 +1372,7 @@ z_proxy_ssl_setup_handshake(ZProxySSLHan
+ ctx = SSL_CTX_new(SSLv2_client_method());
+ }
+ #endif
++#ifndef OPENSSL_NO_SSL3
+   else if (strcmp(self->ssl_opts.ssl_method[side]->str, "SSLv3") == 0)
+ {
+   if (side == EP_CLIENT)
+@@ -1379,6 +1380,7 @@ z_proxy_ssl_setup_handshake(ZProxySSLHan
+   else
+ ctx = SSL_CTX_new(SSLv3_client_method());
+ }
++#endif
+   else if (strcmp(self->ssl_opts.ssl_method[side]->str, "TLSv1") == 0)
+ {
+   if (side == EP_CLIENT)
diff -Nru zorp-3.9.5/debian/patches/series zorp-3.9.5/debian/patches/series
--- zorp-3.9.5/debian/patches/series2015-05-26 21:55:44.0 +0200
+++ zorp-3.9.5/debian/patches/series2016-05-30 11:11:33.0 +0200
@@ -10,3 +10,4 @@
 0010-tests-Makefile.am-Removed-python-directory-because-o.patch
 0011-tests-Makefile.am-Removed-kzorp-directory-too-becaus.patch
 0012-Makefile.am-Removed-test-directory-because-of-an-err.patch
+remove-ssl3.patch


signature.asc
Description: OpenPGP digital signature

Bug#825862: qrq: segfault using pulseaudio at qrs

[Andreas Krüger]

Package: qrq
Version: 0.3.1-1
Severity: normal
Tags: patch

Dear Maintainer,

I'm running qrq using pulseaudio (as is the default on my system).
I've configured the speed to slower than normal, and then goofed quite a bit.
This led to slower and slower speeds and finally to quite reproducible
segfaults.

Investigating, I found that pulseaudio.c reserves a fixed buffer
which is good for 10 seconds.  If a long callsign at slow speed exceeds that
limit, a segfault results.

Fortunately, it is easy to replace the fixed buffer with a dynamically
allocated one that is enlarged dynamically as needed.

Find a patch to this respect included.

Regards, and thank you for providing fine software,

Andreas, DJ3EI.



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

Kernel: Linux 3.16.0-4-amd64 (SMP w/4 CPU cores)
Locale: LANG=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 qrq depends on:
ii  libc62.19-18+deb8u4
ii  libncurses5  5.9+20140913-1+b1
ii  libpulse05.0-13
ii  libtinfo55.9+20140913-1+b1

qrq recommends no packages.

Versions of packages qrq suggests:
pn  gnuplot  

-- no debconf information

Common subdirectories: qrq-0.3.1/.pc and qrq-mine/.pc
Common subdirectories: qrq-0.3.1/OSXExtras and qrq-mine/OSXExtras
Common subdirectories: qrq-0.3.1/debian and qrq-mine/debian
diff -u qrq-0.3.1/pulseaudio.c qrq-mine/pulseaudio.c
--- qrq-0.3.1/pulseaudio.c  2013-01-06 15:14:09.0 +0100
+++ qrq-mine/pulseaudio.c   2016-05-30 22:19:03.214507268 +0200
@@ -29,7 +29,8 @@
 extern long samplerate;
 extern void  *dsp_fd;
 
-short int buf[441000]; /* 10 secs buffer */
+short int *buf = 0;
+int bufsize = 0;
 int bufpos = 0;
 
 void *open_dsp () {
@@ -64,8 +65,13 @@
 /* actually just puts samples into the buffer that is played at the end 
 (close_audio) */
 void write_audio (void *bla, int *in, int size) {
+   int sample_count = size/sizeof(int);
int i = 0;
-   for (i=0; i < size/sizeof(int); i++) {
+   if(bufsize <= bufpos + sample_count) {
+   buf = realloc(buf, (bufpos + sample_count) * sizeof(short int));
+   bufsize = bufpos + sample_count;
+   }
+   for (i=0; i < sample_count; i++) {
buf[bufpos] = (short int) in[i];
bufpos++;
}   



signature.asc
Description: OpenPGP digital signature

Bug#825863: percona-xtradb-cluster-galera-2.x: should it be removed from Debian?

[Mattia Rizzolo]

Package: percona-xtradb-cluster-galera-2.x
Version: 1:2.11.2675-1.2
Severity: serious

I think RM of this package should be seriously considered:

* NPOASR
* FTBFS
* RC-buggy with no answers in 6 months
* 2 NMUs
* should be superseded by -3.x
* very low popcon

RM; percona-xtradb-cluster-galera-2.x -- RoQA; NPOASR; FTBFS; RC-buggy; 
unmaintained; low popcon

-- 
regards,
Mattia Rizzolo

GPG Key: 66AE 2B4A FCCF 3F52 DA18  4D18 4B04 3FCD B944 4540  .''`.
more about me:  https://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#825394: systemd kill background processes after user logs out

[John Paul Adrian Glaubitz]

On 05/30/2016 10:52 PM, Iustin Pop wrote:
> As long as they know about it. In an ideal world, yes, every such admin
> would read in detail all release notes. In the real world, you've just
> added more trouble for the (usually overworked) admins.

An admin who is upgrading to a new version of the operating system (assuming
that no one in their right mind runs unstable in their production
environment where systemd_230 would already be installed in the next
upgrade) will run lots of tests before actually deploying which is
how these things are usually caught.

And, moreover, if something like this slips through the cracks, you will
usually get a ticket from a user very quickly after deployment who would
complain about that change and you could adjust the configuration
accordingly.

An admin who runs into such upgrades blindly and unprepared will not
keep their jobs for a very long time.

>> As for the usefulness of this change: I used to work at the IT departmant
>> of a large university in the past and I have some experience in this regard.
>> In fact, this particular change in systemd solves a *very* common problem in
>> these setups which are leftover processes on the computers in the student 
>> computer
>> pools as around at least a dozen different users are logging in and out again
>> on these machines per day with many different processes still staying 
>> around, and,
>> no, this is not particularly a GNOME problem - it's a general problem which
>> is usually solved with a cron job which kills leftover processes regularly.
> 
> It's true that for shared machines this makes sense. But not for
> individual workstations, e.g. in a company which deploys Linux as the
> default OS for engineers.

It makes as much sense there as well. See above what Martin said [1]: When you
log out, you expect processes to be terminated, not to continue them running
since this a potential security problem.

>> Some people here suggested that, instead of adding such a functionality to
>> the session manager, affected projects should just fix their software which
>> effectively translates to "People should write bug-free software" which
>> is, of course, an unrealistic goal and therefore not really adding to
>> the discussion in any fruitful manner.
> 
> Sure, but nobody in this bug proposed that.

Yes, that was proposed multiple times [2,3,4]. Plus, it was also mentioned
across multiple bug trackers like the tmux bug [5]. All of them are basically
asking to write bug-free software which is not possible. Again, the only
real feasible solution is have the session manager clean up leftover
processes after the user logs out. The same way the janitor in a large
company locks all doors, sets up the alarm and turns off the lights
after the last employee has left.

> Again, you're looking at it from the point of view of shard machines. In
> the case however where we're talking about individual machines, this
> becomes a counter-argument. Similarly here in this bug people proposed
> whitelists of processes which should not be killed, a similarly bad
> measure.

First of all, Linux is a multi-user operating system, so I think it should,
by any means, behave sanely in this regard by default. Furthermore,
as I have mentioned before, I think most users will expect all processes
to be killed upon log out. I mean, you *closed* a session after all. Why
would you want anything from that session to continue running after
you closed it. That doesn't remotely make any sense, really.

If I wanted some process to survive logout, I should be forced to
explicitly tell that to the session manager. This is the only way
the session management is able to clean up a session properly. If
it will have to guess, there will always be random leftover processes.

>> It's honestly very frustrating to read bug reports like these as they
>> are usually written by people who lack the necessary background or refuse
>> to accept that their particular use case is not the common use case.
> 
> This can be argued from the other side as well. Exactly the same
> argument. What makes _your_ argument the right one? They are two sides
> of the same problem.

Well, my argument is that the people who made the change are the ones
who do the actual work. And for that, they most certainly get to decide
what the defaults are. People seem to feel entitled to have free software
catered to their personal needs. But that isn't the case. Everyone
gets to make their decisions in their own code and others can just
use it and adjust it to their own needs.

This is the whole idea of open source, after all. But open source most
certainly doesn't mean, you get to tell others how to develop their software.

> No, that's not the case. The problem is that, unilaterally, systemd
> authors/systemd packaging team decided to change the default. IMHO, a
> reasonable and less conflictual path forward would have been to
> advertise this feature, allow the needed software changes to propagate
> to 

Bug#825852: icedove: segfault

[George B.]

On 30/05/16 21:49, Carsten Schoenert wrote:


I can't see any segfault here, did you mentioned the hints on

  https://wiki.debian.org/Icedove#Debugging

Please create a log decribed on the wiki page. otherwise it's impossible
to grab the needed informations.


Hi Carsten,

Thanks for the hint! I attach the output of `thread apply all bt` (as a file 
because it is so big).

Here is the extract of the specific thread:

```
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
Core was generated by `icedove'.
Program terminated with signal SIGSEGV, Segmentation fault.
#0  0x7fc4b4ec2c09 in raise (sig=sig@entry=11) at 
../sysdeps/unix/sysv/linux/pt-raise.c:36
36  ../sysdeps/unix/sysv/linux/pt-raise.c: No such file or directory.
[Current thread is 1 (Thread 0x7fc4b52c5740 (LWP 3364))]
(gdb) thread apply all bt

[...]

Thread 1 (Thread 0x7fc4b52c5740 (LWP 3364)):
#0  0x7fc4b4ec2c09 in raise (sig=sig@entry=11) at 
../sysdeps/unix/sysv/linux/pt-raise.c:36
#1  0x7fc4b0d8e7e1 in nsProfileLock::FatalSignalHandler (signo=11, 
info=0x7fff5a104270, context=0x7fff5a104140) at 
/build/icedove-SXJ_d3/icedove-45.1.0/mozilla/toolkit/profile/nsProfileLock.cpp:185
#2  0x7fc4b154ffb1 in AsmJSFaultHandler (signum=, 
info=0x7fff5a104270, context=0x7fff5a104140) at 
/build/icedove-SXJ_d3/icedove-45.1.0/mozilla/js/src/asmjs/AsmJSSignalHandlers.cpp:1161
#3  
#4  XPCWrappedNativeScope::TraceWrappedNativesInAllScopes 
(trc=trc@entry=0x7fff5a1047d8, rt=rt@entry=0x7fc4a2364000) at 
/build/icedove-SXJ_d3/icedove-45.1.0/mozilla/js/xpconnect/src/XPCWrappedNativeScope.cpp:476
#5  0x7fc4af9ace39 in XPCJSRuntime::TraceAdditionalNativeGrayRoots 
(this=0x7fc4a2364000, trc=0x7fff5a1047d8) at 
/build/icedove-SXJ_d3/icedove-45.1.0/mozilla/js/xpconnect/src/XPCJSRuntime.cpp:606
#6  0x7fc4af579841 in 
mozilla::CycleCollectedJSRuntime::TraceNativeGrayRoots (this=0x7fc4a2364000, 
aTracer=0x7fff5a1047d8)
at 
/build/icedove-SXJ_d3/icedove-45.1.0/mozilla/xpcom/base/CycleCollectedJSRuntime.cpp:823
#7  0x7fc4b14b1f26 in js::gc::GCRuntime::bufferGrayRoots 
(this=this@entry=0x7fc49b01e3f8) at 
/build/icedove-SXJ_d3/icedove-45.1.0/mozilla/js/src/gc/RootMarking.cpp:384
#8  0x7fc4b12a873f in js::gc::GCRuntime::beginMarkPhase 
(this=this@entry=0x7fc49b01e3f8, reason=reason@entry=JS::gcreason::CC_WAITING) 
at /build/icedove-SXJ_d3/icedove-45.1.0/mozilla/js/src/jsgc.cpp:4050
#9  0x7fc4b12a9d40 in js::gc::GCRuntime::incrementalCollectSlice 
(this=this@entry=0x7fc49b01e3f8, budget=..., 
reason=reason@entry=JS::gcreason::CC_WAITING)
at /build/icedove-SXJ_d3/icedove-45.1.0/mozilla/js/src/jsgc.cpp:6024
#10 0x7fc4b12aa9bc in js::gc::GCRuntime::gcCycle 
(this=this@entry=0x7fc49b01e3f8, 
nonincrementalByAPI=nonincrementalByAPI@entry=false, budget=..., 
reason=reason@entry=JS::gcreason::CC_WAITING)
at /build/icedove-SXJ_d3/icedove-45.1.0/mozilla/js/src/jsgc.cpp:6278
#11 0x7fc4b12aadad in js::gc::GCRuntime::collect (this=0x7fc49b01e3f8, 
nonincrementalByAPI=nonincrementalByAPI@entry=false, budget=..., 
reason=JS::gcreason::CC_WAITING)
at /build/icedove-SXJ_d3/icedove-45.1.0/mozilla/js/src/jsgc.cpp:6384
#12 0x7fc4b12ab1e7 in js::gc::GCRuntime::startGC (this=, 
gckind=gckind@entry=GC_NORMAL, reason=reason@entry=JS::gcreason::CC_WAITING, 
millis=millis@entry=0)
at /build/icedove-SXJ_d3/icedove-45.1.0/mozilla/js/src/jsgc.cpp:6450
#13 0x7fc4b12ab29c in JS::StartIncrementalGC (rt=, 
gckind=gckind@entry=GC_NORMAL, reason=reason@entry=JS::gcreason::CC_WAITING, 
millis=millis@entry=0)
at /build/icedove-SXJ_d3/icedove-45.1.0/mozilla/js/src/jsgc.cpp:7347
#14 0x7fc4afd6dd11 in nsJSContext::GarbageCollectNow 
(aReason=JS::gcreason::CC_WAITING, aIncremental=nsJSContext::IncrementalGC, 
aShrinking=nsJSContext::NonShrinkingGC, aSliceMillis=0)
at 
/build/icedove-SXJ_d3/icedove-45.1.0/mozilla/dom/base/nsJSEnvironment.cpp:1317
#15 0x7fc4af5bda9c in nsTimerImpl::Fire (this=0x7fc475e1c9b0) at 
/build/icedove-SXJ_d3/icedove-45.1.0/mozilla/xpcom/threads/nsTimerImpl.cpp:526
#16 0x7fc4af5b4138 in nsTimerEvent::Run (this=0x7fc49169b430) at 
/build/icedove-SXJ_d3/icedove-45.1.0/mozilla/xpcom/threads/TimerThread.cpp:282
#17 0x7fc4af5b72a8 in nsThread::ProcessNextEvent (this=0x7fc4b3e77ae0, 
aMayWait=, aResult=0x7fff5a104cc7) at 
/build/icedove-SXJ_d3/icedove-45.1.0/mozilla/xpcom/threads/nsThread.cpp:972
#18 0x7fc4af5d2c4b in NS_ProcessNextEvent (aThread=, 
aMayWait=aMayWait@entry=true) at 
/build/icedove-SXJ_d3/icedove-45.1.0/mozilla/xpcom/glue/nsThreadUtils.cpp:297
#19 0x7fc4af7b2074 in mozilla::ipc::MessagePump::Run (this=0x7fc4a23871c0, 
aDelegate=0x7fc4b3e9a690) at 
/build/icedove-SXJ_d3/icedove-45.1.0/mozilla/ipc/glue/MessagePump.cpp:127
#20 0x7fc4af7a2058 in MessageLoop::RunHandler (this=) at 
/build/icedove-SXJ_d3/icedove-45.1.0/mozilla/ipc/chromium/src/base/message_loop.cc:227
#21 MessageLoop::Run (this=) at 

Bug#825844: mrpt: FTBFS on armhf: parse_NMEA_ZDA bus error

[Jose Luis Blanco]

>> I noticed it and it took me 2 days of research until I found the
>> problem to be inside a gtest template. A possible solution is now
>> committed upstream [1],
>
> Great, thanks!

Confirmed, it's fixed now upstream. Will mark it as done in the next release.

>> I'm waiting for build farms in Ubuntu PPA to
>> test if the patch works... It would be great to know of some easy way
>> of doing the test directly on Debian, but I'm unaware of any!
>
> You can request guest access to porterboxes:
> https://dsa.debian.org/doc/guest-account/

Thanks for the pointer Aaron, will try it...

Cheers,
JL

-- 
___

Jose Luis Blanco-Claraco
CITE-IV 1.05
Universidad de Almería, Departamento de Ingeniería
04120 Almería (Spain)
http://www.ual.es/~jlblanco/
___

Bug#825861: freecad: After update to 0.16 design contents are "invisible", ViewProvider2DObjectPython on console

[Sascha Silbe]

Package: freecad
Version: 0.16+dfsg2-1~bpo8+1
Severity: important

Dear Maintainer,

thanks for providing a backport for 0.16! Unfortunately after
updating, I cannot load my document created with the 0.15.4671
backport anymore.

When loading my "old" document, the 3D view continues to show the
start page, even though the tab for my document is active. In
addition, the following errors appear on the terminal I started
FreeCAD on:

=== Begin ===
PartGui::ViewProvider2DObjectPython: Overread data for property GridSize of 
type App::PropertyLength, expected type is App::PropertyDistance
Coin error in SoGroup::removeChild(): tried to remove non-existent child 
0x4d487c0 (Separator)
Coin error in SoGroup::removeChild(): tried to remove non-existent child 
0x4d1f990 (Sphere)
Coin error in SoGroup::removeChild(): tried to remove non-existent child 
0x4d487c0 (Separator)
PartGui::ViewProvider2DObjectPython: Overread data for property GridSize of 
type App::PropertyLength, expected type is App::PropertyDistance
PartGui::ViewProvider2DObjectPython: Overread data for property GridSize of 
type App::PropertyLength, expected type is App::PropertyDistance
Coin error in SoGroup::removeChild(): tried to remove non-existent child 
0x4a025a0 (Separator)
Coin error in SoGroup::removeChild(): tried to remove non-existent child 
0x4da6940 (Sphere)
Coin error in SoGroup::removeChild(): tried to remove non-existent child 
0x4a025a0 (Separator)
PartGui::ViewProvider2DObjectPython: Overread data for property GridSize of 
type App::PropertyLength, expected type is App::PropertyDistance
Coin error in SoGroup::removeChild(): tried to remove non-existent child 
0x4d17b90 (Separator)
Coin error in SoGroup::removeChild(): tried to remove non-existent child 
0x4da6440 (Sphere)
Coin error in SoGroup::removeChild(): tried to remove non-existent child 
0x4d17b90 (Separator)
PartGui::ViewProvider2DObjectPython: Overread data for property GridSize of 
type App::PropertyLength, expected type is App::PropertyDistance
Coin error in SoGroup::removeChild(): tried to remove non-existent child 
0x4d09b20 (Separator)
Coin error in SoGroup::removeChild(): tried to remove non-existent child 
0x4ca4420 (Sphere)
Coin error in SoGroup::removeChild(): tried to remove non-existent child 
0x4d09b20 (Separator)
PartGui::ViewProvider2DObjectPython: Overread data for property GridSize of 
type App::PropertyLength, expected type is App::PropertyDistance
Coin error in SoGroup::removeChild(): tried to remove non-existent child 
0x4d214a0 (Separator)
Coin error in SoGroup::removeChild(): tried to remove non-existent child 
0x4d33cb0 (Sphere)
Coin error in SoGroup::removeChild(): tried to remove non-existent child 
0x4d214a0 (Separator)
PartGui::ViewProvider2DObjectPython: Overread data for property GridSize of 
type App::PropertyLength, expected type is App::PropertyDistance
PartGui::ViewProvider2DObjectPython: Overread data for property GridSize of 
type App::PropertyLength, expected type is App::PropertyDistance
Coin error in SoGroup::removeChild(): tried to remove non-existent child 
0x4a48c30 (Separator)
Coin error in SoGroup::removeChild(): tried to remove non-existent child 
0x4a63840 (Sphere)
Coin error in SoGroup::removeChild(): tried to remove non-existent child 
0x4a48c30 (Separator)
PartGui::ViewProvider2DObjectPython: Overread data for property GridSize of 
type App::PropertyLength, expected type is App::PropertyDistance
Coin error in SoGroup::removeChild(): tried to remove non-existent child 
0x4a5fc10 (Separator)
Coin error in SoGroup::removeChild(): tried to remove non-existent child 
0x4a035a0 (Sphere)
Coin error in SoGroup::removeChild(): tried to remove non-existent child 
0x4a5fc10 (Separator)
PartGui::ViewProvider2DObjectPython: Overread data for property GridSize of 
type App::PropertyLength, expected type is App::PropertyDistance
Coin error in SoGroup::removeChild(): tried to remove non-existent child 
0x4a0a9c0 (Separator)
Coin error in SoGroup::removeChild(): tried to remove non-existent child 
0x4a62950 (Sphere)
Coin error in SoGroup::removeChild(): tried to remove non-existent child 
0x4a0a9c0 (Separator)
PartGui::ViewProvider2DObjectPython: Overread data for property GridSize of 
type App::PropertyLength, expected type is App::PropertyDistance
Coin error in SoGroup::removeChild(): tried to remove non-existent child 
0x4a843b0 (Separator)
Coin error in SoGroup::removeChild(): tried to remove non-existent child 
0x4c818f0 (Sphere)
Coin error in SoGroup::removeChild(): tried to remove non-existent child 
0x4a843b0 (Separator)
PartGui::ViewProvider2DObjectPython: Overread data for property GridSize of 
type App::PropertyLength, expected type is App::PropertyDistance
Coin error in SoGroup::removeChild(): tried to remove non-existent child 
0x4a0a020 (Separator)
Coin error in SoGroup::removeChild(): tried to remove non-existent child 
0x4d67a30 (Sphere)
Coin error in SoGroup::removeChild(): tried to remove non-existent child 
0x4a0a020 

Bug#825295: openscad: file causing segfault on render

[Marius Kintel]

Upstream issue tracker: https://github.com/openscad/openscad/issues/1655

Bug#784316: Please do not remove hoauth

[John Goerzen]

Hello folks,

I know I have had no time to work on my Haskell packages in awhile - but
I am working to get them all into shape.

Bug 784316 requested twidge upgrade to hoauth2.  Unfortunately, twitter
is still using OAuth 1.0A [1].  A request to support it in the hoauth2
library was rejected for this reason. [2]   Therefore, hoauth is still
required for building a twitter client, and therefore is still required
for twidge.

The other fixes required are mostly trivial and I hope to fix the
remaining items and add a number of features in the coming days as well.

Can we, therefore, keep hoauth in sid?

Thanks,

John

[1] https://dev.twitter.com/oauth

[2] https://github.com/freizl/hoauth2/issues/18

Bug#822621: xscreensaver-data-extra and xscreensaver-gl-extra should Enhance cinnamon-screensaver

[Christoph Anton Mitterer]

On Tue, 2016-04-26 at 17:56 +0200, Tormod Volden wrote:
> > Well it's the same case as with gnome-screensaver, I thought.
> > Both can use the screensaver modules provided by xscreensaver
> I should probably remove the Enhance for gnome-screensaver.

Or that... and tell the gnome-screensaver guys, that they should
Recommend/Suggest your packages directly.
In any case however, I think that the dependencies(i.e. Enhances), at
least on the xscreensaver packages) should be the same for all possible
users (at least, cinnamon-screensaver, gnome-screensaver and mate-
screensaver)

btw: I just noticed, that you also mention gnome-screensaver in the
package descriptions... I think that should also go away then, since
gnome-screensaver is in no way more special than e.g. cinnamon-
screensaver (or possible others like mate-screensaver).


> > > Wouldn't it be better to have cinnamon-screensaver Suggest these
> > > packages? I guess cinnamon-screensaver Recommends xscreensaver-
> > > data
> > > and xscreensaver-gl already.
> > Well they recommend it already... so no need for a Suggests.
> Note that I was talking about two other packages here. I would think
> all 4 should be Suggested.

At least in the current version they recommend all 4... I personally
have no strong opinion on whether the -extra packages should only be
suggested...


Cheers,
Chris.

smime.p7s
Description: S/MIME cryptographic signature

Bug#825394: systemd kill background processes after user logs out

[martin f krafft]

also sprach John Paul Adrian Glaubitz  
[2016-05-30 22:19 +0200]:
> I'm sorry, but this is a very bad argument. People who are in
> charge of hundreds of systems almost never use the default
> settings but use something like FAI, …

In this case: agreed. In general, I just wanted to point out that
a head count in Debian never translates to number of systems.

> It's honestly very frustrating to read bug reports like these as
> they are usually written by people who lack the necessary
> background or refuse to accept that their particular use case is
> not the common use case. And I have more the impression that these
> bug reports are merely written to stir up emotions because, again,
> the systemd developers dared to touch something in the Linux
> software stack which has not been touch for years while solving
> yet another long-existing problem.

I disagree with your assessment. At least for my part, I am
a systemd supporter, especially after having seen the great work our
Debian packagers have done.

However, this does not mean I have to agree with every change that
systemd is imposing, and as I wrote in my original message,
Unix/Linux has become successful (also) *because* it doesn't just
break with tradition, but adheres to standards and doesn't surprise
people.

The proposed default might very well be what our users want, but we
have no way of knowing and until we do, we should refrain from
making invasive changes, whether in the systemd ecosystem or
anywhere else.

As such, I appreciate that Martin reverted the default and I trust
that the debian-systemd team will find a solution suitable for the
universal operating system.

> A reasonable person wouldn't even mind about such changes.

I am sure you didn't mean to call everyone unreasonable who minds
about this change.

> They would either just disable the feature completely or use the
> provided mechanisms to white-list individual processes which takes
> less time than writing up such a bug report and stirring up
> emotions.

We are Debian developers. We love what we do and we cherrish our
product. We do not satisfy ourselves with hacks, or turn a blind eye
to problems, and I hope that will never change.

-- 
 .''`.   martin f. krafft  @martinkrafft
: :'  :  proud Debian developer
`. `'`   http://people.debian.org/~madduck
  `-  Debian - when you have better things to do than fixing systems
 
"although occasionally there is something to be said for solitude."
-- special agent dale cooper


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

Bug#825726: debian-security-support: [INTL:it] Updated Italian debconf translation

[Santiago Ruano Rincón]

Control: tags -1 + pending
Thanks

pushed into the git repo.

Thanks,

Santiago


signature.asc
Description: PGP signature

Bug#825394: systemd kill background processes after user logs out

[Iustin Pop]

On 2016-05-30 22:19:48, John Paul Adrian Glaubitz wrote:
> Hi!
> 
> > don't think the right response should be to just fix it one way
> > for everyone, especially not since those people in charge of hundreds
> > of systems have exactly one vote, similar to those who just develop
> > for their own home workstation.
> 
> I'm sorry, but this is a very bad argument. People who are in charge
> of hundreds of systems almost never use the default settings but use
> something like FAI, Puppet or ansible to configure their systems
> exactly the way they need them. No one is installing hundreds of
> computers manually with the d-i images like you would do on a single
> machine, that would just be nuts. And in these scenarios, changing
> the default settings of configuration files in packages is a daily
> routine and nothing special. So, this change has *zero* negative
> impact for these users.

As long as they know about it. In an ideal world, yes, every such admin
would read in detail all release notes. In the real world, you've just
added more trouble for the (usually overworked) admins.

> As for the usefulness of this change: I used to work at the IT departmant
> of a large university in the past and I have some experience in this regard.
> In fact, this particular change in systemd solves a *very* common problem in
> these setups which are leftover processes on the computers in the student 
> computer
> pools as around at least a dozen different users are logging in and out again
> on these machines per day with many different processes still staying around, 
> and,
> no, this is not particularly a GNOME problem - it's a general problem which
> is usually solved with a cron job which kills leftover processes regularly.

It's true that for shared machines this makes sense. But not for
individual workstations, e.g. in a company which deploys Linux as the
default OS for engineers.

> Some people here suggested that, instead of adding such a functionality to
> the session manager, affected projects should just fix their software which
> effectively translates to "People should write bug-free software" which
> is, of course, an unrealistic goal and therefore not really adding to
> the discussion in any fruitful manner.

Sure, but nobody in this bug proposed that.

> Thus, the systemd approach is actually sane and exactly what most admins of
> larger setups with many users want. And it's not that the systemd developers
> did not provide an opt-out solution. As it was clearly documented in the
> release notes, users are free to disable this feature or use systemd-run
> to explicitly prevent a process from being killed upon logout which is
> *exactly* what every admin wants: Processes should be killed upon logout
> by default and anything that should remain running should request an
> explicit permission from the session management. There is really no other
> good way to tackle this problem. Admins will neither be able to prevent
> buggy software (since users could just write and run their own buggy
> software) nor is it practical to keep a long black list with runaway
> processes which are being killed upon logout.

Again, you're looking at it from the point of view of shard machines. In
the case however where we're talking about individual machines, this
becomes a counter-argument. Similarly here in this bug people proposed
whitelists of processes which should not be killed, a similarly bad
measure.

> It's honestly very frustrating to read bug reports like these as they
> are usually written by people who lack the necessary background or refuse
> to accept that their particular use case is not the common use case.

This can be argued from the other side as well. Exactly the same
argument. What makes _your_ argument the right one? They are two sides
of the same problem.

> And I
> have more the impression that these bug reports are merely written to
> stir up emotions because, again, the systemd developers dared to touch
> something in the Linux software stack which has not been touch for years
> while solving yet another long-existing problem. A reasonable person wouldn't
> even mind about such changes. They would either just disable the feature
> completely or use the provided mechanisms to white-list individual processes
> which takes less time than writing up such a bug report and stirring up
> emotions.

No, that's not the case. The problem is that, unilaterally, systemd
authors/systemd packaging team decided to change the default. IMHO, a
reasonable and less conflictual path forward would have been to
advertise this feature, allow the needed software changes to propagate
to the most common programs affected (screen, tmux, etc.) and only later
make the switch to it.

The other issue is that, and here maybe it's only my experience,
unintended leftover processes usually only consume resources, but
unintentionally killed processes can result in data loss. Thus, this
setting is on the more dangerous default.

I'm 

Bug#825860: RM: kfreebsd-headers-9.0-2 [armel armhf ia64 mips powerpc s390 s390x sparc] -- RoQA; ANAIS

[Adam D. Barratt]

Package: release.debian.org
User: release.debian@packages.debian.org
Usertags: rm
Tags: wheezy pending

kfreebsd-headers-9.0-2 was inadvertently built on a number of
architectures in wheezy-pu some time ago. The wanna-build side seems to
have been cleaned up in the meantime but the cruft should be cleaned up.

Bug#825852: icedove: segfault

[Carsten Schoenert]

Hello George,

On Mon, May 30, 2016 at 08:07:33PM +0100, George B. wrote:
> Package: icedove
> Version: 1:45.1.0-1
> Severity: normal
> 
> Hello,
> 
> I had icedove crash with the follwing backtrace:
> 
> ```

I can't see any segfault here, did you mentioned the hints on

  https://wiki.debian.org/Icedove#Debugging

Please create a log decribed on the wiki page. otherwise it's impossible
to grab the needed informations.

Regards
Carsten

Bug#825727: python-babel: FTBFS: assert 'GMT+00:00' == 'GMT-01:59'

[Chris Lamb]

> I'm afaid I still cannot reproduce it. Downgrading until somebody else can.

The reproducible builds Jenkins instance can also reproduce:

 
https://tests.reproducible-builds.org/rbuild/unstable/amd64/python-babel_2.3.4+dfsg.1-2.rbuild.log



Regards,

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

Bug#825859: Possible GPL violation by linking with libappindicator3-1

[Benjamin Barenblat]

Source: transmission-remote-gtk
Version: 1.1.1-1

transmission-remote-gtk is licensed under the GPLv2
only. libappindicator3-1 is licensed under the GPLv3 only. Therefore,
distributing a transmission-remote-gtk linked against libappindicator3-1
may violate the GPL.

The fix for this should be fairly straightforward; I can simply build
--without-libappindicator.

Bug#825858: systemd-insserv-generator shouldn't create insserv dependencies if the unit is masked

[Laurent Bigonville]

On Mon, 30 May 2016 22:25:25 +0200 Laurent Bigonville  
wrote:


> Hi,
>
> rpcbind is now providing a .service file, but the
> systemd-insserv-generator is still creating dependency information base
> on it:
>
> # /run/systemd/generator/rpcbind.service.d/50-rpcbind-$portmap.conf
> # Automatically generated by systemd-insserv-generator
>
> [Unit]
> Wants=rpcbind.target
> Before=rpcbind.target
>
> and also
>
> # 
/run/systemd/generator/rpcbind.target.d/50-hard-dependency-rpcbind-$portmap.conf

> # Automatically generated by systemd-insserv-generator
>
> [Unit]
> SourcePath=/etc/insserv.conf.d/rpcbind
> Requires=rpcbind.service
>
> Shouldn't systemd-insserv-generator ignore inserv informations if the
> LSB initscript is masked by a systemd service?
>
> That would also need to check that the .service files have the proper
> dependencies.

On the other hand, it seems that the generator is not adding a Requires 
in the .service generated for nfs-common:


# /run/systemd/generator.late/nfs-common.service
# Automatically generated by systemd-sysv-generator

[Unit]
Documentation=man:systemd-sysv-generator(8)
SourcePath=/etc/init.d/nfs-common
Description=LSB: NFS support files common to client and server
DefaultDependencies=no
Before=sysinit.target
Before=multi-user.target
Before=multi-user.target
Before=multi-user.target
Before=graphical.target
Before=shutdown.target
After=rpcbind.target
After=time-sync.target
Conflicts=shutdown.target

[Service]
Type=forking
Restart=no
TimeoutSec=0
IgnoreSIGPIPE=no
KillMode=process
GuessMainPID=no
RemainAfterExit=yes
ExecStart=/etc/init.d/nfs-common start
ExecStop=/etc/init.d/nfs-common stop

$ grep portmap /etc/init.d/nfs-common
# Required-Start:$portmap $time

Bug#654924: [Pkg-tigervnc-devel] Bug#654924: Re: Helping with tigervnc 1.5.0

[Ola Lundqvist]

Hi Martin

Good point about the depth. I guess we should consider that.

Regarding -localhost, yes that is a good security practice. On the other
hand this is nothing that is started by default, it is always started by a
human (or a human writing a script for it) so it is not a very important
thing.

However there are plenty of use-cases for connecting to local host. You can
run applications in a chroot, you can have a different desktop session as
another user in the vnc server, you can have that server running there with
more important tasks that must survive in case you have to restart your
desktop session and so on. So there are plenty of use-cases. However they
may not be the most common ones of course.

// Ola

On Wed, May 25, 2016 at 7:43 AM, Martin Dorey  wrote:

> I'm concerned why /etc/vnc.conf and /usr/bin/tigervncserver set a depth of
> 32.  Per man Xtigervnc, that will cause problems for applications, problems
> that I've just described in a little more detail at
> http://stackoverflow.com/a/37428300/18096.  I think it should be 24, a
> setting which doesn't prevent applications from using transparency.
>
> I'm also mildly bemused as to why /usr/bin/tigervncserver's default for
> -localhost is yes, again unlike the default for the underlying Xtigervnc.
> I can imagine there being an argument that default security should be
> locked down.  Perhaps I'm just lacking in imagination as to why I might
> want to connect to localhost.
>
> > Getting the llvmpipe part to work was a challenge.  I failed on the
> first system I tried, which had an nvidia :0.
>
> In the perhaps unlikely event that there's anyone in the same boat, I
> succeeded with:
>
> sudo update-alternatives --set glx /usr/lib/mesa-diverted
> sudo update-initramfs -u
>
> ... though I eventually went into production setting this before starting
> tigervncserver:
>
> LD_LIBRARY_PATH=/usr/lib/mesa-diverted/x86_64-linux-gnu:$LD_LIBRARY_PATH
>
> ___
> Pkg-tigervnc-devel mailing list
> pkg-tigervnc-de...@lists.alioth.debian.org
> http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-tigervnc-devel
>



-- 
 - Ola Lundqvist ---
/  o...@debian.org Folkebogatan 26  \
|  o...@inguza.com  654 68 KARLSTAD  |
|  http://inguza.com/  +46 (0)70-332 1551   |
\  gpg/f.p.: 7090 A92B 18FE 7994 0C36  4FE4 18A1 B1CF 0FE5 3DD9 /
 ---

Bug#823990: dh_gconf no longer needs to add gconf2 dependency to misc:Depends?

[Josselin Mouette]

Hi Niels,

Le lundi 30 mai 2016 à 19:32 +, Niels Thykier a écrit :
> Can you confirm that this dependency on gconf2 is now unnecessary?  At
> first glance I cannot see a need for it now that the autoscripts have
> been removed.

Unless the functionality is optional in the package (which is the case
of pidgin), the gconf2 dependency is still needed. Not because of the
scripts anymore, but because functionally, a binary shipped with gconf
schemas will usually require them to execute.

Otherwise, you might end up with the binary aborting on startup.

Cheers,
-- 
 .''`.  Josselin Mouette
: :' :
`. `'
  `-

Bug#825857: Updated patch

[Anton Gladky]

Updated patch is attached. (Bug number added).

Cheers

Anton
Description: sort libs in native_libs.txt
Author: Anton Gladky 
Bug-Debian: https://bugs.debian.org/825857
Last-Update: 2016-05-30

--- python-setuptools-20.10.1.orig/setuptools/command/bdist_egg.py
+++ python-setuptools-20.10.1/setuptools/command/bdist_egg.py
@@ -197,7 +197,7 @@ class bdist_egg(Command):
 if not self.dry_run:
 ensure_directory(native_libs)
 libs_file = open(native_libs, 'wt')
-libs_file.write('\n'.join(all_outputs))
+libs_file.write('\n'.join(sorted(all_outputs)))
 libs_file.write('\n')
 libs_file.close()
 elif os.path.isfile(native_libs):

Bug#801081: Re: Bug#801081: Re: xserver-xorg-video-qxl: QXL video unusable due to performance

[Jason Briggs]

Thank you! 

I had same issue on other distro I do not use anymore (mageia) so upstream is 
better, but it looked like it was never going to happen (they do not appear in 
his git yet or I miss it).

 On Mon, 30 May 2016 03:50:41 -0400 Laurent Bigonville  wrote  
> 
> 
>Le 30/05/16  08:35, Julien Cristau a crit : 
>> On Sun, May 29, 2016 at 15:53:28 -0400, Jason Briggs wrote: 
>> 
>>> Please include this patch as well: 
>>> 
>>> http://pkgs.fedoraproject.org/cgit/rpms/xorg-x11-drv-qxl.git/plain/qxl-kms-disable-composite.patch
>>>  
>>> 
>>> it appear to help with glitches. 
>>> 
>>> Is there any chance these two patch can make it into Jessie? The reason is 
>>> because it affects all jessie live CD and live CD can't be used properly at 
>>> all with KVM/spice, it really break functionality and there is no 
>>> workaround there unless you rebuild the CD. There is still 2 years of life 
>>> to jessie and all downstream suffer. 
>>> 
>> The patches need to make it into an upstream release first. 
>> 
>I would also prefer that. 
> 
>I already contacted upstream about it, he's aware of the patches and 
>merging them somewhere on his list. 
>
>

Bug#825857: Libs in native_libs.txt are listed in random order

[Anton Gladky]

Package: python-setuptools
Version: 20.10.1-1
Severity: wishlist
Tags: patch
User: reproducible-bui...@lists.alioth.debian.org
Usertags: toolchain randomness

Dear maintainer,

I have noticed that the package pysph is not reproducible due to a
random order of libs listed in "native_libs.txt" [1]. Attached patch fixes
the problem. Please consider to apply the patch.

It is similar to a bug #773969.


[1] https://tests.reproducible-builds.org/rb-pkg/unstable/armhf/pysph.html

Thank you

Anton
Description: sort libs in native_libs.txt
Author: Anton Gladky 
Bug-Debian: https://bugs.debian.org/
Last-Update: 2016-05-30

--- python-setuptools-20.10.1.orig/setuptools/command/bdist_egg.py
+++ python-setuptools-20.10.1/setuptools/command/bdist_egg.py
@@ -197,7 +197,7 @@ class bdist_egg(Command):
 if not self.dry_run:
 ensure_directory(native_libs)
 libs_file = open(native_libs, 'wt')
-libs_file.write('\n'.join(all_outputs))
+libs_file.write('\n'.join(sorted(all_outputs)))
 libs_file.write('\n')
 libs_file.close()
 elif os.path.isfile(native_libs):

Bug#825858: systemd-insserv-generator shouldn't create insserv dependencies if the unit is masked

[Laurent Bigonville]

Package: systemd
Version: 230-1
Severity: normal

Hi,

rpcbind is now providing a .service file, but the
systemd-insserv-generator is still creating dependency information base
on it:

# /run/systemd/generator/rpcbind.service.d/50-rpcbind-$portmap.conf
# Automatically generated by systemd-insserv-generator

[Unit]
Wants=rpcbind.target
Before=rpcbind.target

and also

# 
/run/systemd/generator/rpcbind.target.d/50-hard-dependency-rpcbind-$portmap.conf
# Automatically generated by systemd-insserv-generator

[Unit]
SourcePath=/etc/insserv.conf.d/rpcbind
Requires=rpcbind.service

Shouldn't systemd-insserv-generator ignore inserv informations if the
LSB initscript is masked by a systemd service?

That would also need to check that the .service files have the proper
dependencies.

Cheers,

Laurent Bigonville

-- Package-specific info:

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

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

Versions of packages systemd depends on:
ii  adduser 3.114
ii  libacl1 2.2.52-3
ii  libapparmor12.10-4
ii  libaudit1   1:2.5.2-1
ii  libblkid1   2.28-5
ii  libc6   2.22-9
ii  libcap2 1:2.25-1
ii  libcap2-bin 1:2.25-1
ii  libcryptsetup4  2:1.7.0-2
ii  libgcrypt20 1.7.0-2
ii  libgpg-error0   1.22-2
ii  libkmod222-1.1
ii  liblzma55.1.1alpha+20120614-2.1
ii  libmount1   2.28-5
ii  libpam0g1.1.8-3.2
ii  libseccomp2 2.3.1-2
ii  libselinux1 2.5-3
ii  libsystemd0 230-1
ii  mount   2.28-5
ii  util-linux  2.28-5

Versions of packages systemd recommends:
ii  dbus1.10.8-1
ii  libpam-systemd  230-1

Versions of packages systemd suggests:
pn  systemd-container  
pn  systemd-ui 

Versions of packages systemd is related to:
ii  udev  230-1

-- no debconf information

Bug#825844: mrpt: FTBFS on armhf: parse_NMEA_ZDA bus error

[Aaron M. Ucko]

Jose Luis Blanco  writes:

> I noticed it and it took me 2 days of research until I found the
> problem to be inside a gtest template. A possible solution is now
> committed upstream [1],

Great, thanks!

> I'm waiting for build farms in Ubuntu PPA to
> test if the patch works... It would be great to know of some easy way
> of doing the test directly on Debian, but I'm unaware of any!

You can request guest access to porterboxes:
https://dsa.debian.org/doc/guest-account/

-- 
Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org)
http://www.mit.edu/~amu/ | http://stuff.mit.edu/cgi/finger/?a...@monk.mit.edu

Bug#824673: wine32-development-tools:i386 cannot be installed on amd64

[Javier Serrano Polo]

El dl 30 de 05 de 2016 a les 01:27 +0200, Jens Reyer va escriure: 
> I'll change the dependencies once I've verified if pkg:i386
> or pkg:amd64 are legit notations.

If it helps, the lmms package has a relationship with this notation
(lmms-vst-server:i386). https://bugs.debian.org/822269 is related to the
notation and is fixed in Lintian.

> ${perl:Depends} | perl:any [i386],

This might break in the future if ${perl:Depends} is substituted with
"perl, foobar".


smime.p7s
Description: S/MIME cryptographic signature

Bug#825394: systemd kill background processes after user logs out

[John Paul Adrian Glaubitz]

Hi!

> don't think the right response should be to just fix it one way
> for everyone, especially not since those people in charge of hundreds
> of systems have exactly one vote, similar to those who just develop
> for their own home workstation.

I'm sorry, but this is a very bad argument. People who are in charge
of hundreds of systems almost never use the default settings but use
something like FAI, Puppet or ansible to configure their systems
exactly the way they need them. No one is installing hundreds of
computers manually with the d-i images like you would do on a single
machine, that would just be nuts. And in these scenarios, changing
the default settings of configuration files in packages is a daily
routine and nothing special. So, this change has *zero* negative
impact for these users.

As for the usefulness of this change: I used to work at the IT departmant
of a large university in the past and I have some experience in this regard.
In fact, this particular change in systemd solves a *very* common problem in
these setups which are leftover processes on the computers in the student 
computer
pools as around at least a dozen different users are logging in and out again
on these machines per day with many different processes still staying around, 
and,
no, this is not particularly a GNOME problem - it's a general problem which
is usually solved with a cron job which kills leftover processes regularly.

Some people here suggested that, instead of adding such a functionality to
the session manager, affected projects should just fix their software which
effectively translates to "People should write bug-free software" which
is, of course, an unrealistic goal and therefore not really adding to
the discussion in any fruitful manner.

Thus, the systemd approach is actually sane and exactly what most admins of
larger setups with many users want. And it's not that the systemd developers
did not provide an opt-out solution. As it was clearly documented in the
release notes, users are free to disable this feature or use systemd-run
to explicitly prevent a process from being killed upon logout which is
*exactly* what every admin wants: Processes should be killed upon logout
by default and anything that should remain running should request an
explicit permission from the session management. There is really no other
good way to tackle this problem. Admins will neither be able to prevent
buggy software (since users could just write and run their own buggy
software) nor is it practical to keep a long black list with runaway
processes which are being killed upon logout.

It's honestly very frustrating to read bug reports like these as they
are usually written by people who lack the necessary background or refuse
to accept that their particular use case is not the common use case. And I
have more the impression that these bug reports are merely written to
stir up emotions because, again, the systemd developers dared to touch
something in the Linux software stack which has not been touch for years
while solving yet another long-existing problem. A reasonable person wouldn't
even mind about such changes. They would either just disable the feature
completely or use the provided mechanisms to white-list individual processes
which takes less time than writing up such a bug report and stirring up
emotions.

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#788429: spamassassin: /etc/init.d/spamassassin restart fails on Jessie/sysvinit

[Miklos Quartus]

Package: spamassassin
Version: 3.4.1-4
Followup-For: Bug #788429

> So the 'start-stop-daemon --stop' calls in /etc/init.d/spamassassin are not 
> able to identify the running spamd processes.
Note that this bug does not apply, since systemd we normally restart services 
via 'systemctl restart '. 
In my Debian sid, the restarting the service works perfectly well:

"
root@qmitoshiba:/etc/default# ps -ef |grep spamd
root 20738 1  1 21:44 ?00:00:01 /usr/sbin/spamd -d 
--pidfile=/var/run/spamassassin.pid --create-prefs --max-children 5 
--helper-home-dir
root 20739 20738  0 21:44 ?00:00:00 spamd child
root 20740 20738  0 21:44 ?00:00:00 spamd child
root 20763 13386  0 21:47 pts/200:00:00 grep spamd
root@qmitoshiba:/etc/default# systemctl restart spamassassin
root@qmitoshiba:/etc/default# systemctl status spamassassin
● spamassassin.service - Perl-based spam filter using text analysis
   Loaded: loaded (/lib/systemd/system/spamassassin.service; enabled; vendor 
preset: enabled)
   Active: active (running) since Mon 2016-05-30 21:47:35 CEST; 12s ago
  Process: 20771 ExecStart=/usr/sbin/spamd -d 
--pidfile=/var/run/spamassassin.pid $OPTIONS (code=exited, status=0/SUCCESS)
 Main PID: 20777 (/usr/sbin/spamd)
   CGroup: /system.slice/spamassassin.service
   ├─20777 /usr/sbin/spamd -d --pidfile=/var/run/spamassassin.pid 
--create-prefs --max-children 5 --helper-home-di
   ├─20778 spamd chil
   └─20779 spamd chil

May 30 21:47:33 qmitoshiba systemd[1]: Starting Perl-based spam filter using 
text analysis...
May 30 21:47:33 qmitoshiba spamd[20771]: logger: removing stderr method
May 30 21:47:34 qmitoshiba spamd[20777]: zoom: able to use 353/353 'body_0' 
compiled rules (100%)
May 30 21:47:35 qmitoshiba spamd[20777]: spamd: server started on 
IO::Socket::IP [::1]:783, IO::Socket::IP [127.0.0.1]:783 (running version 3.4.1)
May 30 21:47:35 qmitoshiba spamd[20777]: spamd: server pid: 20777
May 30 21:47:35 qmitoshiba spamd[20777]: spamd: server successfully spawned 
child process, pid 20778
May 30 21:47:35 qmitoshiba spamd[20777]: spamd: server successfully spawned 
child process, pid 20779
May 30 21:47:35 qmitoshiba spamd[20777]: prefork: child states: SI
May 30 21:47:35 qmitoshiba systemd[1]: Started Perl-based spam filter using 
text analysis.
May 30 21:47:35 qmitoshiba spamd[20777]: prefork: child states: II
root@qmitoshiba:/etc/default#
"

As you can see above, before the restart spamd had PID of 20738, after
it was restarted, it changed to 20777. Because Jessie is already on
systemd, restarting as shown above should also work on Jessie.

Any comments or concerns, please do not hold off.

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

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

Versions of packages spamassassin depends on:
ii  adduser  3.114
ii  curl 7.47.0-1
ii  init-system-helpers  1.33
ii  libhtml-parser-perl  3.72-1
ii  libhttp-date-perl6.02-1
ii  libnet-dns-perl  1.05-2
ii  libnetaddr-ip-perl   4.079+dfsg-1
ii  libsocket6-perl  0.27-1
ii  libsys-hostname-long-perl1.5-1
ii  libwww-perl  6.15-1
ii  perl 5.22.2-1
ii  perl-modules-5.22 [libarchive-tar-perl]  5.22.2-1
ii  w3m  0.5.3-28

Versions of packages spamassassin recommends:
ii  gnupg 1.4.20-6
ii  libio-socket-inet6-perl   2.72-2
ii  libmail-spf-perl  2.9.0-4
ii  libperl5.22 [libsys-syslog-perl]  5.22.2-1
ii  sa-compile3.4.1-4
ii  spamc 3.4.1-4

Versions of packages spamassassin suggests:
pn  libdbi-perl  
pn  libencode-detect-perl
ii  libio-socket-ssl-perl2.027-1
pn  libmail-dkim-perl
ii  libperl5.22 [libcompress-zlib-perl]  5.22.2-1
pn  pyzor
pn  razor

-- Configuration Files:
/etc/spamassassin/local.cf changed [not included]

-- no debconf information

Regards,

-- 
Miklos Quartus
WWW: http://www.miklos.info
GPG: 3C4B 1364 A379 7366 7FED  260A 2208 F2CE 3FCE A0D3

Bug#752876: r-cran-spdep_0.6-4-1_amd64.changes REJECTED

[Andreas Tille]

Hi Roger,

On Mon, May 30, 2016 at 05:51:57PM +0200, Roger Bivand wrote:
> Please tell them that I am not willing to make any further changes. If they
> bothered to look, they would have seen that the functions are not simply
> copied from arm.c, but modified to use double rather than integer
> coordinates. I can add arm.c for documentation and change the soigraph.c
> function names to show that they are modified from those in arm.c, but I do
> not see the point.

I think the point is pretty clear:  Its no question that you changed
something but if you have permission to change the existing files is the
basic question.  To quote again:

   This book is in copyright. (...) no reproduction of any part may take 
   place without the written permission of Cambridge University Press.

So did you got the written permission of  Cambridge University Press?
If yes, could you please attach a copy of this permission to the code.

Kind regards

   Andreas.
 
> Best wishes,
> 
> Roger
> 
> On Mon, 30 May 2016, Andreas Tille wrote:
> 
> >Hi again Roger,
> >
> >this is just a ping in case you might have missed my last mail about the
> >licensing of the file copied from "Computational Geometry in C".  Were
> >you able to clarify the issue or to rewrite the code in question?
> >
> >Thanks for your cooperation
> >
> >  Andreas.
> >
> >On Fri, May 13, 2016 at 05:26:09PM +0200, Andreas Tille wrote:
> >>Hi Roger,
> >>
> >>I'm afraid I need to come back to you again about the licensing of the
> >>file in question in the spdep package.  Please read below what the
> >>Debian ftpmasters think about the license:
> >>
> >>On Fri, May 13, 2016 at 01:00:23PM +, Thorsten Alteholz wrote:
> >>>
> >>>Hi Andreas,
> >>>
> >>>ok, one step further, but two questions remain:
> >>>
> >>>- "... in its entirety ...", not being a native speaker, but for me that
> >>>  sounds like you are only allowed to distribute the whole example code
> >>>  and are not allowed to use just parts of it
> >>>- anyway, the main point is that you are only allowed to redistribute
> >>>  the code but have no permission to modify it, which is against DFSG 3.
> >>>
> >>>  Thorsten
> >>
> >>I'm sorry that this is such a longish process bit it would be really
> >>cool if you could have another look or try to contact the authors (or
> >>rewrite this code? - I think in some previous conversation you wrote
> >>about this option as well).
> >>
> >>Kind regards and thanks for your cooperation
> >>
> >>  Andreas.
> >>
> >>--
> >>http://fam-tille.de
> >
> >
> 
> -- 
> Roger Bivand
> Department of Economics, Norwegian School of Economics,
> Helleveien 30, N-5045 Bergen, Norway.
> voice: +47 55 95 93 55; fax +47 55 95 91 00
> e-mail: roger.biv...@nhh.no
> http://orcid.org/-0003-2392-6140
> https://scholar.google.no/citations?user=AWeghB0J=en
> http://depsy.org/person/434412
> 
> -- 
> debian-science-maintainers mailing list
> debian-science-maintain...@lists.alioth.debian.org
> http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/debian-science-maintainers
> 

-- 
http://fam-tille.de

Bug#795186: portsentry is starting too early

[TheSin]

I am running into the same issue, though for me it’s when I’m in systemd mode.  
It’s find in sysv.  Maybe portsentry should have a proper systemd service file?

Bug#825856: openntpd: CVE-2016-5117

[Salvatore Bonaccorso]

Source: openntpd
Version: 1:5.7p4-4
Severity: normal
Tags: security upstream patch

Hi,

the following vulnerability was published for openntpd.

CVE-2016-5117[0]:
OpenNTPD not verifying CN during HTTPS constraints request

As far I can tell we though are not affected in default Debian
installations, since constraints not enabled. The source seems though
affected, so this bug is to track the issue. Let me know though if I'm
wrong here.

If you fix the vulnerability please also make sure to include the
CVE (Common Vulnerabilities & Exposures) id in your changelog entry.

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2016-5117
[1] http://www.openwall.com/lists/oss-security/2016/05/23/2
[2] 
http://cvsweb.openbsd.org/cgi-bin/cvsweb/src/usr.sbin/ntpd/constraint.c.diff?r1=1.27=1.28

Regards,
Salvatore

Bug#825840: Acknowledgement (linux-image-4.5.0-2-powerpc: radeonfb display inverted red and blue color)

[Ben Hutchings]

On Mon, 2016-05-30 at 19:06 +0200, Mathieu Malaterre wrote:
> Some actual progress. The trick was to prevent Open Firmware to
> provide the framebuffer for us (??does that even make sense??).
> 
> Before;
> 
> [0.740726] Using unsupported 800x600 ATY,RockHopper2_A at
> 9c008000, depth=8, pitch=1024
> [0.750458] Console: switching to colour frame buffer device 100x37
> [0.759850] fb0: Open Firmware frame buffer device on
> /pci@f000/ATY,RockHopper2Parent@10/ATY,RockHopper2_A@0
> 
> Change:
> 
> #  echo 'append="nomodeset video=offb:off"' >> /etc/yaboot.conf
> # reboot
> 
> At this point should have nothing associated with framebuffer. Then
> simply `modprobe radeonfb`:
[...]
> Turns out: everything works as expected ! `fim` happily display a nice
> red or blue bmp image. dmesg output is still very nicely coloured.
> 
> Maybe the issue is directly in d-i where PPC is setup with a different
> layout for some reason.

It sounds like offb has an incorrect view of what order the RGB
components are stored in memory in the framebuffer set up by Open
Firmware.  When radeonfb is loaded, it take over this framebuffer and
accept the incorrect description that offb gave it (I think).

If you disable offb, radeonfb won't know anything about the Open
Firmware framebuffer.  It will create a fresh framebuffer and set the
screen mode itself, so they are consistent.

Ben.

-- 
Ben Hutchings
Absolutum obsoletum. (If it works, it's out of date.) - Stafford Beer


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

Bug#825110: /pci@f400000/ata-6@d/@0:3,/boot/vmlinux: Unknown or corrupt

[Milan Kupcevic]

On 05/30/2016 12:20 PM, Lennart Sorensen wrote:
> On Mon, May 30, 2016 at 12:17:19AM -0400, Milan Kupcevic wrote:
>> affects 825110 yaboot
>> tags 825110 pending
>> thanks
>>
>> Yaboot is not able to load files from a partition with metadata_csum and 
>> 64bit ext4 features enabled.
> 

[...]

> Of course if ext4 is being created by default in 64bit mode these days
> (I have no idea), then the installer may need to be taught to not do
> that for whatever filesystem /boot is going in.
> 

It seems ext4 is being created by default with 64bit and metadata_csum
features since stretch beta 6 d-i release. A separate /boot partition
formatted as ext3 would be a solution; as it was for some time before
yaboot got support for ext4.

Instead of doing separate /boot we might be better off to adjust
newworld partition recipe to accommodate grub installation while
disabling d-i 64bit and metadata_csum features on powerpc to allow for
installation of yaboot.[0] Once we transition to grub we can get rid of
yaboot-installer together with ext4 feature limitations. Mathieu is
volunteering to do some work in this regard.[1]

Milan

[0]
https://anonscm.debian.org/cgit/d-i/partman-ext3.git/commit/?id=f87dc92157262de1ad8dd3f2343436f08271b4dc
[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=610206#14







signature.asc
Description: OpenPGP digital signature

Bug#825783: cyrus-imapd-2.4: Cyrus does not create directory in /var/run if it differs from default one (/var/run/cyrus)

[Dmitry Katsubo]

Thanks for reply Ondřej,

After analysing /usr/lib/cyrus/bin/init-helper I see what is the problem.
>From one side everything is implemented correctly: once I use the default
imap.conf, the script should also work OK (and it indeed creates
/var/run/cyrus/socket and other stuff). However I was not 100% exact with
problem description -- sorry for that. The actual value is:

lmtpsocket: /var/run/postfix/cyrus/lmtp

I used different from default once location because later /var/run/postfix
is bound to /var/spool/postfix/var/run (to make it possible for chrooted
postfix to communicate with cyrus).

That is why I re-formulate the problem:

Cyrus does not create directory in /var/run if it differs from default
one (/var/run/cyrus).

Expected that the actual values from configuration file /etc/imapd.conf are
considered in function fixdirs().

On 2016-05-30 09:46, Ondřej Surý wrote:
> Hi Dmitry,
> 
> each init script runs:
> 
> /usr/sbin/cyrus init-helper start
> 
> that creates /var/run/cyrus and /var/run/cyrus/socket directories.
> 
> Could you run:
> 
> bash -x /usr/lib/cyrus/bin/init-helper start
> 
> on your system to see what went wrong?
> 
> Cheers,
>
> -- Ondřej Surý  Knot DNS (https://www.knot-dns.cz/)
>>> On Sun, May 29, 2016, at 21:43, Dmitry Katsubo wrote:
>>> Package: cyrus-imapd-2.4
>>> Version: 2.4.17+nocaldav-2+b1
>>> 
>>> Hello,
>>> 
>>> I have noticed that Cyrus does not create necessary directory in /var/run
>>> when needed. For example, when the following is specified in
>>> /etc/imapd.conf
>>> 
>>> lmtpsocket: /var/run/cyrus/lmtp
>>> 
>>> the directory /var/run/cyrus is not created, even though Cyrus starts up
>>> and functions ok.
>>> 
>>> Expected: the directory /var/run/cyrus (or any other necessary top-level
>>> directory) is created or Cyrus complains that directory is not writeable.
>>> 
>>> Solution: Do it in init.d script (very draft suggestion is attached) or
>>> via /etc/tmpfiles.d/cyrus.conf:
>>> 
>>> d /var/run/cyrus 0755 cyrus mail

-- 
With best regards,
Dmitry

Bug#821308: Bug doesn't appear in 4.3.5-1

[Markus Grunwald]

Hello,

have been booting my machine with linux image 4.3.5-1 for a few weeks now: the
bug didn't appear there!


-- 
Markus Grunwald
https://www.the-grue.de

Fragen zur Mail? https://www.the-grue.de/mail_und_co
https://www.the-grue.de/~markus/markus_grunwald.gpg

Bug#825840: linux-image-4.5.0-2-powerpc: radeonfb display inverted red and blue color

[Ben Hutchings]

Control: reassign src:linux 4.5.4-1
Control: tag -1 help

On Mon, 2016-05-30 at 18:42 +0200, Mathieu Malaterre wrote:
> Package: linux-image-4.5.0-2-powerpc
> Version: 4.5.4-1
> 
> During Debian installation the background color is inverted on PPC system.
> At least on my Mac Mini G4, the default background color shows up as red
> from begining to start (only the last screen turn blue).
> 
> Looking at the module loaded during the installation I can see radeonfb,
> which I suspect is the one responsible for handling of `/dev/fb0`.
> 
> After installation I tried reproducing this color inversion without any
> luck so far.
> 
> It is non-trivial to `rmmod radeon`, so instead I used (and rebooted):
> 
> $ cat /etc/modprobe.d/radeon.conf
> blacklist radeon
> 
> However upon reboot `/dev/fb0` is already setup.

Of course, because there is no character-based display mode on Power
Macs (in general).

> But neither radeonfb nor
> radeon module seems to be loaded (using lsmod) but lspci output is rather
> confusing [*].

lspci lists all kernel modules that match a particular PCI device's ID,
and separately whether any kernel driver is currently bound to the
device.

> I can also see:
> 
> $ cat /proc/fb
> 0 OFfb ATY,RockHo

As I would expect, the generic Open Firmware framebuffer driver is
behind /dev/fb0.  If a hardware-specific driver is loaded, that will
take over from it.

> Playing with the virtual screen with a red and blue color and `fim`, all
> images looks weird, I could not figure out if there was something special
> to setup so that I can display a red or blue image in `fim`.
> 
> Lastly, I can run `dmesg` and the color looks right (error messages are
> displayed in red, timestamp in green).
> 
> I'd like to keep this bug open until I find what is going on with this
> color inversion on PPC/ATI.
[...]

I'm sorry, but no-one is likely to help with this.  The Linux port to
Power Macs is no longer actively developed and no-one on the Debian
kernel team looks after them.

Ben.

-- 
Ben Hutchings
Absolutum obsoletum. (If it works, it's out of date.) - Stafford Beer


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

Bug#825821: ITP: neomutt -- NeoMutt is a place to gather all the patches against Mutt.

[Elimar Riesebieter]

* Evgeni Golov  [2016-05-30 21:11 +0200]:

> Hi,
> 
> > > On Mon, 2016-05-30 at 13:00 +0200, Elimar Riesebieter wrote:
> > > > * Package name: neomutt
> 
> Please don't. We don't need another mutt fork in Debian.

Its not a fork. It's just an additional packege like in real life:
mutt and neomutt

Elimar
-- 
  The path to source is always uphill!
-unknown-


signature.asc
Description: PGP signature

Bug#825855: mxml: CVE-2016-4570 CVE-2016-4571: Stack exhaustion

[Salvatore Bonaccorso]

Source: mxml
Version: 2.6-2
Severity: important
Tags: security upstream
Forwarded: http://www.msweet.org/bugs.php?U549

Hi,

the following vulnerabilities were published for mxml.

CVE-2016-4570[0]:
Recursion using mxmlDelete at mxml-node.c:217 (stack-exhaustion-1.xml)

CVE-2016-4571[1]:
Recursion using mxml_write_node at mxml-file.c:2739 (stack-exhaustion-2.xml

If you fix the vulnerabilities please also make sure to include the
CVE (Common Vulnerabilities & Exposures) ids in your changelog entry.

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2016-4570
[1] https://security-tracker.debian.org/tracker/CVE-2016-4571
[2] http://www.msweet.org/bugs.php?U549
[3] http://seclists.org/oss-sec/2016/q2/276
[4] http://seclists.org/oss-sec/2016/q2/325

Regards,
Salvatore

Bug#823990: dh_gconf no longer needs to add gconf2 dependency to misc:Depends?

[Niels Thykier]

On Tue, 10 May 2016 21:58:36 -0400 Ari Pollak  wrote:
> Package: debhelper
> Version: 9.20160403
> Severity: wishlist
> 
> dh_gconf still adds gconf2 to ${misc:Depends}, but AFAICT that's a legacy
> holdout and is no longer needed anymore. The gconf2 package uses triggers to
> update its database with new schemas; if you install gconf2, it will
> rebuild the database from scratch anyway. So for something like pidgin, which
> adds URL handlers to gconf (not used by GNOME 3 anyway) but doesn't need gconf
> for normal operation, that's just an extraneous dependency that just seems to
> irritate certain users.
> 
> 
> [...]

Hi Joss,

Can you confirm that this dependency on gconf2 is now unnecessary?  At
first glance I cannot see a need for it now that the autoscripts have
been removed.

Thanks,
~Niels

Bug#825854: RM: speaklater -- ROM; no longer needed, dead upstream

[Sebastian Ramacher]

Package: ftp.debian.org
Severity: normal

Please remove speaklater from the archive. flask-babel (the only reverse
dependency) integrated the parts it needs. Also upstream seems pretty dead.

Regards
-- 
Sebastian Ramacher


signature.asc
Description: PGP signature

Bug#825203: pidgin-sipe: segfault

[George B.]

On 25/05/16 06:28, Jakub Adam wrote:

Hi,

On 05/24/2016 04:24 PM, George B. wrote:

I could not find a sipe debug package, so backtrace may not be very useful


pidgin-sipe has switched to automatic debug packages [1]. You should add
the repository listed at [1] matching your distribution and install 
pidgin-sipe-dbgsym.

I think this is a crash in Sipe, but proper 'bt full' with debug symbols would
come useful.


A bit more data after installing the package:

```
#0  0x7fdb0132f458 in __GI_raise (sig=sig@entry=6) at 
../sysdeps/unix/sysv/linux/raise.c:55
 resultvar = 0
 pid = 3739
 selftid = 3739
#1  0x7fdb013308da in __GI_abort () at abort.c:89
 save_stage = 2
 act = {__sigaction_handler = {sa_handler = 0x0, sa_sigaction = 0x0}, 
sa_mask = {__val = {140578594944623, 140578598270272, 496, 94550494222128, 496, 
94550494222128, 140578594942067, 140578598270272,
   496, 496, 140578594946166, 140578598270272, 94550494222128, 496, 
9705, 94550499112352}}, sa_flags = 20337240, sa_restorer = 0x55fe40fbe720}
 sigs = {__val = {32, 0 }}
#2  0x55fe4042630a in sighandler (sig=11) at 
/build/pidgin-2.10.12/./pidgin/gtkmain.c:179
 written = 
#3  
No locals.
#4  0x7fdaf1ebba21 in sipe_http_request_response 
(conn_public=conn_public@entry=0x55fe40e9b5a0, msg=msg@entry=0x55fe40efc1a0) at 
sipe-http-request.c:474
 sipe_private = 0x55fe40fb5210
 req = 
 failed = 
#5  0x7fdaf1ebc9e5 in sipe_http_transport_input (connection=0x55fe40fbe720) 
at sipe-http-transport.c:409
 msg = 0x55fe40efc1a0
 drop = 0
 next = 
 conn = 0x55fe40e9b5a0
 current = 
#6  0x55fe4040dc4e in pidgin_io_invoke (source=, 
condition=, data=0x55fe416066a0) at 
/build/pidgin-2.10.12/./pidgin/gtkeventloop.c:73
 closure = 0x55fe416066a0
 purple_cond = PURPLE_INPUT_READ
#7  0x7fdb01f4105a in g_main_context_dispatch () from 
/lib/x86_64-linux-gnu/libglib-2.0.so.0
No symbol table info available.
#8  0x7fdb01f41400 in ?? () from /lib/x86_64-linux-gnu/libglib-2.0.so.0
No symbol table info available.
#9  0x7fdb01f41722 in g_main_loop_run () from 
/lib/x86_64-linux-gnu/libglib-2.0.so.0
No symbol table info available.
#10 0x7fdb031e85b7 in gtk_main () from 
/usr/lib/x86_64-linux-gnu/libgtk-x11-2.0.so.0
No symbol table info available.
#11 0x55fe403d4267 in main (argc=1, argv=0x7ffd31201a38) at 
/build/pidgin-2.10.12/./pidgin/gtkmain.c:937
 opt_force_online = 0
 opt_help = 
 opt_login = 0
 opt_nologin = 0
 opt_version = 
 opt_si = 
 opt_config_dir_arg = 
 opt_login_arg = 
 opt_session_arg = 
 search_path = 
 accounts = 
 sig_indx = 1
 sigset = {__val = {91142, 0 }}
 errmsg = 
"\000\020\b\000\000\000\000\000\003\000\000\000\333\177\000\000\000\060#\000\000\000\000\000\000P#\000\000\000\000\000`F#\000\000\000\000\000hF#\000\000\000\000\000\000\060\003\000\000\000\000\000\003\000\000\000\333\177\000\000\000@#\000\000\000\000\000\000p#\000\000\000\000\000\220d#\000\000\000\000\000\260d#\000\000\000\000\000\000@\003\000\000\000\000\000\003\000\000\000\333\177\000\000\000\020!\000\000\000\000\000\000\060!\000\000\000\000\000\f
 
!\000\000\000\000\000\350\"!\000\000\000\000\000\000\020\001\000\000\000\000\000'\000\000\000\000\000\000\000\001\000\000\000\000\000\000\000X\221\177\004\333\177\000\000(j\224\004\333\177\000\000'\000\000\000\000\000\000\000/\000\000\000\001\000\000\000"...
 signal_channel = 
 signal_status = 
 signal_channel_watcher = 1
 segfault_message_tmp = 
 error = 0x0
 opt = 
 gui_check = 
 debug_enabled = 
 migration_failed = 0
 active_accounts = 
 long_options = {{name = 0x55fe40470db1 "config", has_arg = 1, flag = 0x0, val = 99}, {name 
= 0x55fe4045f1f9 "debug", has_arg = 0, flag = 0x0, val = 100}, {name = 0x55fe4046cd41 
"force-online",
 has_arg = 0, flag = 0x0, val = 102}, {name = 0x55fe40460d7a "help", has_arg 
= 0, flag = 0x0, val = 104}, {name = 0x55fe4046cbed "login", has_arg = 2, flag = 0x0, val 
= 108}, {
 name = 0x55fe4046cd4e "multiple", has_arg = 0, flag = 0x0, val = 109}, {name = 
0x55fe4046cd57 "nologin", has_arg = 0, flag = 0x0, val = 110}, {name = 0x55fe40470da7 
"session", has_arg = 1,
 flag = 0x0, val = 115}, {name = 0x55fe4046356d "version", has_arg = 0, flag = 0x0, val 
= 118}, {name = 0x55fe40470dba "display", has_arg = 1, flag = 0x0, val = 68}, {name = 
0x55fe4046d903 "sync",
 has_arg = 0, flag = 0x0, val = 83}, {name = 0x0, has_arg = 0, flag 
= 0x0, val = 0}}
```


Best regards,

George

Bug#825853: gnome-session: Crash after 5 minutes after logging in

[Manuel Bilderbeek]

Package: gnome-session
Version: 3.20.1-2
Severity: important

Dear Maintainer,

I logged in after booting my "testing" machine and did nothing (had other stuff 
to do). When I came back, I noticed it was back on the login screen.

I saw this in the journalctl output:

mei 30 20:42:18 sonata systemd[1]: Started Session c3 of user Debian-gdm.
mei 30 20:42:18 sonata systemd[2340]: Reached target Sockets.
mei 30 20:42:18 sonata systemd[2340]: Reached target Paths.
mei 30 20:42:18 sonata systemd[2340]: Reached target Timers.
mei 30 20:42:18 sonata systemd[2340]: Reached target Basic System.
mei 30 20:42:18 sonata systemd[2340]: Reached target Default.
mei 30 20:42:18 sonata systemd[2340]: Startup finished in 13ms.
mei 30 20:42:18 sonata systemd[1]: Started User Manager for UID 116.
mei 30 20:42:18 sonata kernel: gnome-shell[2357]: segfault at 0 ip   
(null) sp 7ffc334e6dc8 error 14 in gnome-shell[40+4000]
mei 30 20:42:18 sonata gnome-session[2349]: gnome-session-binary[2349]: 
WARNING: Application 'org.gnome.Shell.desktop' killed by signal 11
mei 30 20:42:18 sonata gnome-session-binary[2349]: WARNING: Application 
'org.gnome.Shell.desktop' killed by signal 11
mei 30 20:42:18 sonata gnome-session-binary[2349]: Unrecoverable failure in 
required component org.gnome.Shell.desktop
mei 30 20:42:18 sonata gdm-launch-environment][2329]: 
pam_unix(gdm-launch-environment:session): session closed for user Debian-gdm
mei 30 20:42:18 sonata gdm3[650]: GdmDisplay: display lasted 0.367717 seconds
mei 30 20:42:18 sonata systemd[1]: Stopped Session c3 of user Debian-gdm.
mei 30 20:42:18 sonata systemd-logind[516]: Removed session c3.
mei 30 20:42:18 sonata systemd[1]: Stopping User Manager for UID 116...
mei 30 20:42:18 sonata systemd[2340]: Stopped target Default.
mei 30 20:42:18 sonata systemd[2340]: Stopped target Basic System.
mei 30 20:42:18 sonata gdm3[650]: Child process -2346 was already dead.
mei 30 20:42:18 sonata systemd[2340]: Stopped target Paths.
mei 30 20:42:18 sonata gdm3[650]: Child process 2329 was already dead.
mei 30 20:42:18 sonata systemd[2340]: Stopped target Timers.
mei 30 20:42:18 sonata gdm3[650]: Unable to kill session worker process
mei 30 20:42:18 sonata systemd[2340]: Stopped target Sockets.
mei 30 20:42:18 sonata systemd[2340]: Reached target Shutdown.
mei 30 20:42:18 sonata systemd[2340]: Starting Exit the Session...
mei 30 20:42:18 sonata systemd[2340]: Received SIGRTMIN+24 from PID 2370 (kill).
mei 30 20:42:18 sonata systemd[2343]: pam_unix(systemd-user:session): session 
closed for user Debian-gdm
mei 30 20:42:18 sonata systemd[1]: Stopped User Manager for UID 116.

etc.

Main point is that line:
mei 30 20:42:18 sonata kernel: gnome-shell[2357]: segfault at 0 ip   
(null) sp 7ffc334e6dc8 error 14 in gnome-shell[40+4000]
mei 30 20:42:18 sonata gnome-session[2349]: gnome-session-binary[2349]: 
WARNING: Application 'org.gnome.Shell.desktop' killed by signal 11
mei 30 20:42:18 sonata gnome-session-binary[2349]: WARNING: Application 
'org.gnome.Shell.desktop' killed by signal 11
mei 30 20:42:18 sonata gnome-session-binary[2349]: Unrecoverable failure in 
required component org.gnome.Shell.desktop

Is there any extra information I can provide?

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

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

Versions of packages gnome-session depends on:
ii  gnome-session-bin  3.20.1-2
ii  gnome-session-common   3.20.1-2
ii  gnome-settings-daemon  3.20.1-1
ii  gnome-shell3.20.2-1

gnome-session recommends no packages.

Versions of packages gnome-session suggests:
ii  desktop-base  8.0.2
ii  gnome-keyring 3.20.0-1
ii  gnome-user-guide  3.20.2-1

-- no debconf information

Bug#825821: ITP: neomutt -- NeoMutt is a place to gather all the patches against Mutt.

[Evgeni Golov]

Hi,

> > On Mon, 2016-05-30 at 13:00 +0200, Elimar Riesebieter wrote:
> > > * Package name: neomutt

Please don't. We don't need another mutt fork in Debian.

> > Did you talk to the current mutt maintainers about this?
> > 
> > The changelog for the mutt 1.6.1-1 upload to experimental includes:
[ lots of patches taken from neomutt ]

The current plan is to replace Debian's mutt-patched patchset with neomutt. [1]
Maybe even s/mutt/neomutt/ at some point.

Regards
Evgeni, pkg-mutt

[1] https://github.com/neomutt/neomutt/issues/23

Bug#825852: icedove: segfault

[George B.]

Package: icedove
Version: 1:45.1.0-1
Severity: normal

Hello,

I had icedove crash with the follwing backtrace:

```
#0  0x7fc4b4ec2c09 in raise (sig=sig@entry=11) at 
../sysdeps/unix/sysv/linux/pt-raise.c:36
resultvar = 0
pid = 
#1  0x7fc4b0d8e7e1 in nsProfileLock::FatalSignalHandler (signo=11, 
info=0x7fff5a104270, context=0x7fff5a104140) at 
/build/icedove-SXJ_d3/icedove-45.1.0/mozilla/toolkit/profile/nsProfileLock.cpp:185
unblock_sigs = {__val = {1024, 0 }}
oldact = 
#2  0x7fc4b154ffb1 in AsmJSFaultHandler (signum=, 
info=0x7fff5a104270, context=0x7fff5a104140) at 
/build/icedove-SXJ_d3/icedove-45.1.0/mozilla/js/src/asmjs/AsmJSSignalHandlers.cpp:1161
context = 0x7fff5a104140
info = 0x7fff5a104270
signum = 11
#3  
No locals.
#4  XPCWrappedNativeScope::TraceWrappedNativesInAllScopes 
(trc=trc@entry=0x7fff5a1047d8, rt=rt@entry=0x7fc4a2364000) at 
/build/icedove-SXJ_d3/icedove-45.1.0/mozilla/js/xpconnect/src/XPCWrappedNativeScope.cpp:476
entry = 0x7fc47cd24180
wrapper = 0x0
i = {mTable = 0x7fc49687b9d0, mStart = 0x7fc47cd24000 "", mLimit = 
0x7fc47cd24300 '\345' , ..., 
mCurrent = 0x7fc47cd24180 "x\211l}\304\177", mNexts = 8, 
  mNextsLimit = 14, mHaveRemoved = false}
cur = 0x7fc4968a43e0
#5  0x7fc4af9ace39 in XPCJSRuntime::TraceAdditionalNativeGrayRoots 
(this=0x7fc4a2364000, trc=0x7fff5a1047d8) at 
/build/icedove-SXJ_d3/icedove-45.1.0/mozilla/js/xpconnect/src/XPCJSRuntime.cpp:606
No locals.
#6  0x7fc4af579841 in 
mozilla::CycleCollectedJSRuntime::TraceNativeGrayRoots (this=0x7fc4a2364000, 
aTracer=0x7fff5a1047d8)
at 
/build/icedove-SXJ_d3/icedove-45.1.0/mozilla/xpcom/base/CycleCollectedJSRuntime.cpp:823
No locals.
#7  0x7fc4b14b1f26 in js::gc::GCRuntime::bufferGrayRoots 
(this=this@entry=0x7fc49b01e3f8) at 
/build/icedove-SXJ_d3/icedove-45.1.0/mozilla/js/src/gc/RootMarking.cpp:384
op = 
grayBufferer = { = { = {runtime_ = 
0x7fc49b01e000, weakMapAction_ = TraceWeakMapValues, tag_ = 
JSTracer::TracerKindTag::Callback}, 
_vptr.CallbackTracer = 0x7fc4b2a41a00 , static InvalidIndex = 18446744073709551615, 
contextName_ = 0x0, contextIndex_ = 18446744073709551615, 
contextFunctor_ = 0x0}, bufferingGrayRootsFailed = false}
#8  0x7fc4b12a873f in js::gc::GCRuntime::beginMarkPhase 
(this=this@entry=0x7fc49b01e3f8, reason=reason@entry=JS::gcreason::CC_WAITING) 
at /build/icedove-SXJ_d3/icedove-45.1.0/mozilla/js/src/jsgc.cpp:4050
ap3 = {stats = @0x7fc49b01e590, task = 0x0, phase = 
js::gcstats::PHASE_BUFFER_GRAY_ROOTS, enabled = true}
currentTime = 
any = 
gcmarker = 0x7fc49b020240
ap1 = {stats = @0x7fc49b01e590, task = 0x0, phase = 
js::gcstats::PHASE_MARK, enabled = true}
ap2 = {stats = @0x7fc49b01e590, task = 0x0, phase = 
js::gcstats::PHASE_MARK_ROOTS, enabled = true}
#9  0x7fc4b12a9d40 in js::gc::GCRuntime::incrementalCollectSlice 
(this=this@entry=0x7fc49b01e3f8, budget=..., 
reason=reason@entry=JS::gcreason::CC_WAITING)
at /build/icedove-SXJ_d3/icedove-45.1.0/mozilla/js/src/jsgc.cpp:6024
copy = {runtime = 0x7fc49b01e000}
slice = {runtime = 0x7fc49b01e000}
destroyingRuntime = false
initialState = js::gc::NO_INCREMENTAL
#10 0x7fc4b12aa9bc in js::gc::GCRuntime::gcCycle 
(this=this@entry=0x7fc49b01e3f8, 
nonincrementalByAPI=nonincrementalByAPI@entry=false, budget=..., 
reason=reason@entry=JS::gcreason::CC_WAITING)
at /build/icedove-SXJ_d3/icedove-45.1.0/mozilla/js/src/jsgc.cpp:6278
session = {lock = {runtime = 0x7fc49b01e000}, runtime = 0x7fc49b01e000, 
prevState = JS::HeapState::Idle, pseudoFrame = {profiler_ = 0x7fc49b021760, 
sizeBefore_ = {}}}
prevState = 
#11 0x7fc4b12aadad in js::gc::GCRuntime::collect (this=0x7fc49b01e3f8, 
nonincrementalByAPI=nonincrementalByAPI@entry=false, budget=..., 
reason=JS::gcreason::CC_WAITING)
at /build/icedove-SXJ_d3/icedove-45.1.0/mozilla/js/src/jsgc.cpp:6384
wasReset = 
repeatForDeadZone = 
logGC = {logger = 0x7fc4b3e6bd60, payload = {event = 0x7fc40005, id 
= TraceLogger_GC}, isEvent = false, executed = false, prev = 0x0}
aept = {gc_ = @0x7fc49b01e3f8}
asz = {rt_ = 0x7fc49b01e000}
agc = {stats = @0x7fc49b01e590}
repeat = false
#12 0x7fc4b12ab1e7 in js::gc::GCRuntime::startGC (this=, 
gckind=gckind@entry=GC_NORMAL, reason=reason@entry=JS::gcreason::CC_WAITING, 
millis=millis@entry=0)
at /build/icedove-SXJ_d3/icedove-45.1.0/mozilla/js/src/jsgc.cpp:6450
No locals.
#13 0x7fc4b12ab29c in JS::StartIncrementalGC (rt=, 
gckind=gckind@entry=GC_NORMAL, reason=reason@entry=JS::gcreason::CC_WAITING, 
millis=millis@entry=0)
at /build/icedove-SXJ_d3/icedove-45.1.0/mozilla/js/src/jsgc.cpp:7347
No locals.
#14 0x7fc4afd6dd11 in nsJSContext::GarbageCollectNow 
(aReason=JS::gcreason::CC_WAITING, 

Bug#825292: grub-common: does not provide the correct device name for booting the Hurd.

[Samuel Thibault]

Hello,

Rodrigo Valiña Gutiérrez, on Thu 26 May 2016 12:05:37 +0200, wrote:
> -
> --- 30_os-prober    2016-02-05 18:30:35.0 +0100
> +++ 30_os-prober-3    2016-05-26 11:54:35.819822599 +0200
> @@ -331,7 +331,7 @@
>    save_default_entry | grub_add_tab
>    prepare_grub_to_access_device ${DEVICE} | grub_add_tab
>    grub_device="`${grub_probe} --device ${DEVICE} --target=drive`"
> -  mach_device="`echo "${grub_device}" | sed -e 
> 's/(\(hd.*\),msdos\(.*\))/\
> 1s\2/'`"
> +  mach_device=`${grub_probe} --device ${DEVICE} --target=
> compatibility_hint | sed 's/,msdos/s/'`
>    grub_fs="`${grub_probe} --device ${DEVICE} --target=fs`"
>    case "${grub_fs}" in
>  *fs)    hurd_fs="${grub_fs}" ;;
> -

Yes, that should be correct. Note that it's the 30_os-prober.in file
which needs to be modified. Also, since this is an upstream file, you
should probably contact upstream to get it integrated there, so Debian
doesn't maintain the change ad æternam.

> So this is one more step to get working flawlessly and out of the box the
> procedure at:
> [2]https://www.gnu.org/software/hurd/hurd/running/debian/CrossInstall.html
> It remains at least to determine whether --readonly is needed,

Yes it is.

> and maybe to provide a way to boot in single user mode (-s) (needed
> for the first two reboots).

That would be useful indeed.

Samuel

Bug#825851: ITP: meteo-qt -- Application to display weather information

[Alf Gaida]

Package: wnpp
Severity: wishlist
Owner: Alf Gaida 

* Package name: meteo-qt
  Version : 0.9.3
  Upstream Author : Dimitrios Glentadakis 
* URL : https://github.com/dglent/meteo-qt
* License : GPL
  Programming Lang: Python
  Description : Application to display weather information

meteo-qt is an application to display weather information in desktop panels,
desktop notifications and it's own window.
.
Weather data is taken from OpenWeatherMap (http://openweathermap.org/). The
application is based on Python 3 and Qt 5.

Bug#813649: closed by Alastair McKinstry <mckins...@debian.org> (Bug#813649: fixed in emoslib 2:4.3.7-1)

[John Paul Adrian Glaubitz]

Control: unarchive -1
Control: reopen -1

On 02/07/2016 01:12 PM, John Paul Adrian Glaubitz wrote:
> Control: tags -1 patch
> 
> On 02/06/2016 10:29 PM, John Paul Adrian Glaubitz wrote:
>> Back to the drawing board.
> 
> -fPIC was necessary as well:
> 
> --- debian/rules.old  2016-02-03 20:20:51.0 +0100
> +++ debian/rules  2016-02-07 11:23:58.0 +0100
> @@ -24,7 +24,7 @@
>LITTLE:= true
>  endif
> 
> -FPIC_LIST:= "s390x amd64 ppc64el m68k"
> +FPIC_LIST:= "s390x amd64 ppc64el m68k sparc64"
>  ifneq (,$(findstring $(ARCH),$(FPIC_LIST)))
>FPIC:= -fPIC
>  else

This has been reverted for some reason and emoslib is again FTBFS
on sparc64 [1].

Could you please re-apply the patch above?

Thanks,
Adrian

> [1] 
> https://buildd.debian.org/status/fetch.php?pkg=emoslib=sparc64=2%3A4.4.1-3=1464628341

-- 
 .''`.  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#825850: [systemd] Long time to load accounts-daemon.service and issue with X

[Fenix]

Package: systemd
Version: 230-1
Severity: normal

--- Please enter the report below this line. ---


   Dear maintainer:


After 229.6 (I waited that 230-1 fix it, but it is the same) update I 
have a strange issue. First, as you can see the accounts-daemon.service 
takes a lot of time to load:



--
53.366s accounts-daemon.service
15.657s ModemManager.service
15.655s timidity.service
 14.075s loadcpufreq.service
 12.843s networking.service
  9.097s irqbalance.service
  9.041s dev-sda2.device
  8.415s fancontrol.service
  8.323s console-kit-log-system-start.service
  8.277s mono-xsp2.service
  8.243s firewall.service
  8.240s vboxdrv.service
  8.231s lm-sensors.service
  8.220s avahi-daemon.service
  8.208s alsa-restore.service
  8.160s gdomap.service
  8.159s iio-sensor-proxy.service
  8.159s klogd.service
  6.378s NetworkManager.service
  4.550s systemd-modules-load.service
  3.724s systemd-udevd.service
  3.213s console-screen.service
  2.988s polkitd.service
  2.452s packagekit.service
  2.282s binfmt-support.service
  1.684s gdm.service
  1.540s systemd-logind.service
  1.534s wpa_supplicant.service
  1.509s ntp.service
  1.486s keyboard-setup.service
  1.397s systemd-tmpfiles-setup-dev.service
  1.320s systemd-journald.service
  1.125s xfstt.service
  1.116s colord.service
   951ms dev-hugepages.mount
   950ms dev-mqueue.mount
   949ms sys-kernel-debug.mount
   923ms systemd-remount-fs.service
   895ms systemd-tmpfiles-setup.service
   830ms systemd-update-utmp.service
   796ms apt-daily.service
   480ms kmod-static-nodes.service
   478ms systemd-journal-flush.service
   441ms vboxautostart-service.service
   432ms vboxballoonctrl-service.service
   420ms systemd-udev-trigger.service
   407ms muroard.service
   393ms darkice.service
   354ms systemd-tmpfiles-clean.service
   345ms systemd-user-sessions.service
   307ms udisks2.service
   302ms rc-local.service
   265ms upower.service
   255ms systemd-sysctl.service
   243ms vboxweb-service.service
   233ms proc-sys-fs-binfmt_misc.mount
   218ms console-kit-daemon.service
   216ms 
dev-disk-by\x2duuid-91cc575f\x2d9cd7\x2d49c8\x2d91cd\x2d998cc528f7ef.swap

   143ms console-setup.service
   139ms user@1000.service
   104ms systemd-random-seed.service
75ms hddtemp.service
53ms cpufrequtils.service
41ms rtkit-daemon.service
35ms decnet.service
15ms nullmailer.service
13ms autofs.service
12ms sysklogd.service
 8ms systemd-update-utmp-runlevel.service
--


In the boot, systemd show me the message: A start job is running for 
Accouns Service ([a time counter up of one minute]).




Anyway, the gdm3 show me the login for the X and I can login right. But 
the real problem is that about one minute to be in the X, the system 
throws me out to the first text console. I need to enter again with 
ALT-F2. But in this situation only Gnome3 works (he reset one time after 
hang). If I use XFCE the system hangout.





Here is the critial-chain:

--
graphical.target @1min 4.934s
└─accounts-daemon.service @11.567s +53.366s
  └─basic.target @11.465s
└─sockets.target @11.465s
  └─cups.socket @11.465s
└─sysinit.target @11.386s
  └─swap.target @11.386s

└─dev-disk-by\x2duuid-91cc575f\x2d9cd7\x2d49c8\x2d91cd\x2d998cc528f7ef.swap 
@11.169s


└─dev-disk-by\x2duuid-91cc575f\x2d9cd7\x2d49c8\x2d91cd\x2d998cc528f7ef.device 
@11.1

--



I have not activate the systemd journal.



If you need more or extra information , please, feel free to ask.



Thanks.






--- System information. ---
Architecture: i386
Kernel:   Linux 4.5.0-2-686-pae

Debian Release: stretch/sid
  500 testing www.deb-multimedia.org
  500 testing ftp.de.debian.org
  500 stable  dl.google.com

--- Package information. ---
Depends (Version) | Installed
=-+-==
libacl1 (>= 2.2.51-8) | 2.2.52-3
libaudit1(>= 1:2.2.1) | 1:2.5.2-1
libblkid1 (>= 2.17.2) | 2.28-5
libcap2   (>= 1:2.10) | 1:2.25-1
libcryptsetup4   (>= 2:1.4.3) | 2:1.7.0-2
libdbus-1-3(>= 1.1.1) | 1.10.8-1
libkmod2  (>= 5~) | 22-1.1
libpam0g(>= 0.99.7.1) | 1.1.8-3.2
libselinux1(>= 2.1.9) | 2.5-3
libsystemd-journal0 (= 208-8) | 215-17
libudev1 (>= 

Bug#825821: ITP: neomutt -- NeoMutt is a place to gather all the patches against Mutt.

[Elimar Riesebieter]

* Faidon Liambotis  [2016-05-30 20:56 +0300]:

> On Mon, May 30, 2016 at 06:42:21PM +0200, Elimar Riesebieter wrote:
> > I've contacted Antonio Radici, Christoph Berg, "Matteo F. Vescovi" and 
> > Faidon Liambotis via PM a while ago.
> 
> I'll respond here, unfortunately without not much context, as that was a
> PM and I wouldn't want to forward without permission.

All is said in this thread. Nothing mysterious ;-)

> So, first of, a bit of a background for the ITP:
> 
> - The mutt maintainers have been engaging with the neomutt upstream
>   already. I, in fact, joined the mutt maintainer group precisely for
>   this purpose. See https://github.com/neomutt/neomutt/issues/23 and
>   others.

Well, I've noticed that you prepared mutt-1.6.1 which resides in
experimental. I suppose you had to rework the neomutt patches so
that they apply? The neomutt part is foreseen as a patch bomb to
mutt-patched which is IMHO a bad idea and will increase the gap to
mutt a lot. And this is the point where a neomutt package should
jump in ;-)

> - Debian is already shipping neomutt partially already; mutt 1.6.1-1
>   already replaces some of our home-grown patches with neomutt's.

See above. You will always maintain patches and not an upstream
source.

> - Debian has *not* been shipping a vanilla mutt for years. Debian has
>   been shipping mutt, mutt-patched and mutt-kz, the former two from
>   src:mutt and the latter from src:mutt-kz. All of them, including the
>   binary package called "mutt" are heavily patched, to a large extent
>   with patches that neomutt ships (ifdef, compressed folders,
>   trash/purge) but a lot of others as well.

The patches Debian provides for the mutt package (not mutt-patched!)
carry mutt to a more modern mutt package and should just remain!

> - The neomutt upstream (Cc'ed) has been incredibly responsive and
>   receptive to requests, both in general and to Debian's needs
>   specifically. Besides us, he's been bringing together many other
>   downstreams (distros and BSDs).

Richard did a famous work and released a neomutt-distro patch
package, where beside others all Debian specific patches are
included and made applicable. A big thank you for him ;-)

> - Considering the above, consensus between the mutt maintainers so far
>   (and AIUI) has been that the mutt source package should switch
>   upstreams and start tracking neomutt. This would basically mean having
>   *one* source and *one* binary package for mutt in Debian (not counting
>   transitional packages).

You will have a mutt including a patch bomb.

> - This has been waiting to some extent on the new neomutt release which
>   includes compressed folders and NNTP, released just today.
> 
> As such, I think this ITP is superfluous, at least for now. Even if it
> is not, pkg-mutt should own this ITP, not Elimar alone -- as we are
> already the de facto downstreams of neomutt in Debian.

I intend to package neomutt which is an intrinsically package which
has a cooperative upstream. If we have a separated neomutt package
it should be easy to maintain and one doesn't have to fight with
fuzzes and offsets. It can't be the intention of Debian to patch a
GPL'd upstream to a totally over patched monster.

I would be happy about every co-maintainer as I am thinking about a
git repo at alioth maintained by the "neomutt-package-maintainers",
yay.

> We could certainly revisit the decision to ship two source packages in
> Debian, src:mutt and src:neomutt (the eventual deprecation of
> mutt-patched and src:mutt-kz is widely agreed at this point, I think).
> I still haven't heard a convincing response of what would happen to the
> "mutt" binary package, though. As I explained above, we're not shipping
> a vanilla mutt and haven't been doing so for many years now. Switching
> back to the vanilla mutt would be a regression at this point and break
> user expectations on upgrades. Keeping the status quo, on the other
> hand, would mean just a huge waste of effort for maintaining and
> forward-porting patches that neomutt upstream is already doing a better
> job at.

From my point of view the mutt package should remain as it is.
There will be much users who don't want to use mutt-patched or
neomutt. The sidebar, notmuch and nntp features for instance aren't
that popular for legacy, let say conservative, users. There will be
always a chance to choose between a mutt (with some incorporated
patches) and a neomutt package. And with a neomutt package in Debian
we will honour the work of its upstream!
> 
> I also haven't heard a convincing response on what would happen
> with all of the patches shipped in src:mutt's debian/patches that
> are not in neomutt yet; effectively forking off the two packages
> would suck for either future maintenance or for our users'
> upgrades, both of which I find unacceptable options.

Well, the Debian specific patches could be merged into the neomutt
package and maybe pulled in to the neomutt git hub. 

Bug#825844: mrpt: FTBFS on armhf: parse_NMEA_ZDA bus error

[Jose Luis Blanco]

Thanks Aaron!

I noticed it and it took me 2 days of research until I found the
problem to be inside a gtest template. A possible solution is now
committed upstream [1], I'm waiting for build farms in Ubuntu PPA to
test if the patch works... It would be great to know of some easy way
of doing the test directly on Debian, but I'm unaware of any!


Best,

[1] https://github.com/MRPT/mrpt/commit/70c9d5a5ebd01bce09537249bbc2acf4d15f038c


On Mon, May 30, 2016 at 7:46 PM, Aaron M. Ucko  wrote:
> Source: mrpt
> Version: 1:1.4.0-1
> Severity: serious
> Justification: fails to build from source (but built successfully in the past)
>
> The mrpt build for armhf has started failing:
>
>   [ RUN  ] CGPSInterface.parse_NMEA_ZDA
>   Bus error
>   tests/CMakeFiles/run_tests_mrpt_hwdrivers.dir/build.make:60: recipe for 
> target 'tests/CMakeFiles/run_tests_mrpt_hwdrivers' failed
>
> Could you please take a look?
>
> Thanks!



-- 
___

Jose Luis Blanco-Claraco
CITE-IV 1.05
Universidad de Almería, Departamento de Ingeniería
04120 Almería (Spain)
http://www.ual.es/~jlblanco/
___

Bug#825727: python-babel: FTBFS: assert 'GMT+00:00' == 'GMT-01:59'

[Sebastian Ramacher]

Control: tags -1 + help
Control: severity -1 important

On 2016-05-29 17:35:44, Chris Lamb wrote:
> > > > Could you try if
> > > > https://github.com/python-babel/babel/commit/476515c2418039e471656f47efbfc43e5230c1fd
> > > > fixes the issue for you?
> > > 
> > > It does not. (Log attached; patch was in debian/patches/blah.patch)
> > 
> > What do you have in /etc/timezone?
> 
> Europe/London

I'm afaid I still cannot reproduce it. Downgrading until somebody else can.

Cheers
-- 
Sebastian Ramacher


signature.asc
Description: PGP signature

Bug#819017: kadm5.acl stub should be provided as is

[Sam Hartman]

Hi.  I took a look at this in preparation for the 1.14.2 update.

Unfortunately, I can't really do what you ask and ship kadm5.acl as a
conffile.

to be a conffile, in the usual case, the file needs to not be modified
from what the package ships.
However, by default we currently ship a version with all entries
commented out.
:So, it's fairly likely that sysadmins have modified the file at least
to uncomment the entry.

I'd appreciate your input on  what we want the behavior to be.

do you think it would be reasonable to ship a kadm5.acl that had */admin
uncommented by default?
If so, then I could convert either the default we ship in jessie or the
version with that uncommented into a conffile.

however, if it becomes a conffile, neither freeipa setup scripts nor
package scripts can touch it.
Will that be okay for you?

--Sam

Bug#825394: systemd kill background processes after user logs out

[martin f krafft]

also sprach Martin Pitt  [2016-05-29 11:13 +0200]:
> I believe this *is* it the expected thing to do on personal
> computers. This is certainly different in environments like
> universities where one often does put long-running stuff in the
> background, but this doesn't appeal to me as being the behaviour
> to optimize for.

The problem with this statement that I have is that we're the
universal operating system, and while that should not keep us from
"optimising", we really ought not light-heartedly move away from how
things have worked ever since the inception of multics/unix/linux.

It may well be that a non-negligible part of our user base would
benefit from this new behaviour, but at this stage, assuming that
the majority would want this change and calling those speaking up
here a "vocal minority" is IMHO not the right thing to do. Even if
you were to have a GR over this, I don't think the right response
should be to just fix it one way for everyone, especially not since
those people in charge of hundreds of systems have exactly one vote,
similar to those who just develop for their own home workstation.

We have a tool to handle divergent default behaviours in Debian and
it's called debconf. systemd-logind should engage debconf and prompt
on upgrade/install what the local behaviour should be. And until the
point comes that we have enough data to determine that we're
inconveniencing the majority of our users with the default (i.e.
they are choosing the other behaviour), we should leave the default
as how it's been.

> However, this really shouldn't be such a general problem: If/when
> we can change tmux and screen to use PAM or enable lingering, then
> I think we get the best of both worlds: Logging out would clean up
> properly, but the (relatively few) users who use screen/tmux on
> a PC would get the expected behaviour of those processes
> surviving.

There is more than tmux and screen. For instance, my shell knows
that I specifically do *not* want it to HUP background processes
when I leave the shell session:

  http://git.madduck.net/v/etc/zsh.git/blob/HEAD:/.zsh/zshrc/99_TODO#l31

Please do not assume that everything is as simple as how you're
portraying it to be. Linux is a very very very diverse ecosystem and
it grew to be such as a function of the principle of least surprise,
among other things.

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


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