Bug#822931: golang-github-hashicorp-go-msgpack: please update to latest upstream snapshot

[Potter, Tim (HPE Linux Support)]

Package: golang-github-hashicorp-go-msgpack
Severity: wishlist
X-Debbugs-CC: pkg-go 

Please upload the latest release of the golang-github-hashicorp-go-msgpack 
package,
0.0~git20150518.0.fa3f638.  I've already packaged this in the repo on alioth.


Tim.


signature.asc
Description: Message signed with OpenPGP using GPGMail

Bug#822930: golang-github-hashicorp-memberlist: please update to latest upstream snapshot

[Potter, Tim (HPE Linux Support)]

Package: golang-github-hashicorp-memberlist
Severity: wishlist
X-Debbugs-CC: pkg-go 

Please upload the latest release of the golang-github-hashicorp-memberlist 
package,
0.0~git20160329.0.88ac4de.  I've already packaged this in the repo on alioth.


Tim.


signature.asc
Description: Message signed with OpenPGP using GPGMail

Bug#822929: golang-github-gorilla-mux: Please review and upload latest upstream release

[Potter, Tim (HPE Linux Support)]

Package: golang-github-gorilla-mux
Severity: wishlist
X-Debbugs-CC: pkg-go 

Please upload the latest release of the golang-github-gorilla-mux package , 
1.1.  I've already packaged
this in the repo on alioth.

I noticed a strange set of Conflicts/Provides/Replaces which looked wrong, so 
I've replaced it with
the ones recommended by the PackageTransition[1] page for case #5.  I think 
this is right but
another set of eyes on this would be much appreciated.


Tim.

[1] https://wiki.debian.org/PackageTransition


signature.asc
Description: Message signed with OpenPGP using GPGMail

Bug#822697: general: qt5 apps in gnome do not use the gtk style as they should

[Paul Wise]

On Thu, 2016-04-28 at 15:13 +0300, Dmitry Shachnev wrote:

> Please install libqt5libqgtk2 package as I suggested to Miguel.

Thanks.

> Basically GTK+ 2.x is going away ...

Thanks for the info, makes sense.

A shame, it would be lovely to have a consistent desktop one day.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise




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

Bug#820521: cacti: CVE-2016-3659: SQL injection vulnerability in graph_view.php

[Paul Gevers]

Control: tags -1 help

For the record of this bug.

I have not been able to reproduce this on my Debian system, and upstream
hasn't responded yet to the bug report. Any help in reproducing and
providing a script to reproducing is welcome. The script from the
upstream bug report does not reproduce the issue for me.

One data point, I have verified that the code we try to inject is valid
MySQL code in the Debian (sid) version and as such should delay if one
is able to trigger the vulnerability.

Paul

 Forwarded Message 
Subject: reproducing vulnerability
Date: Sun, 10 Apr 2016 13:47:54 +0200
From: Paul Gevers 
To: Debian Security 

Hi,

Call me dumb or ignorant, but even with multiple tries over the last
couple of days, I have not been able to reproduce a CVE¹ against my
package cacti. I have tried using wget with the code below and also in
my browser (iceweasel with "Web Developer" plugin) by changing "hidden"
fields to trigger the issue without success. Am I doing this wrong? Do
you have tips or tricks how to test these kind of security issues?

(Obviously, I am not doubting the CVE itself, although it may be so that
Debian is not vulnerable. I would be surprised though.)

 Initializing stuff
database_pw=theAdminPasswordHere
tmpFile1=$(mktemp)
tmpFile2=$(mktemp)
cookieFile=$(mktemp)
loadSaveCookie="--load-cookies $cookieFile --keep-session-cookies
--save-cookies $cookieFile"

# Make sure we get the magic, this is stored in the cookies for future use.
wget --keep-session-cookies --save-cookies "$cookieFile"
--output-document="$tmpFile1" http://localhost/cacti/index.php
magic=$(grep "name='__csrf_magic' value=" "$tmpFile1" | sed
"s/.*__csrf_magic' value=\"//" | sed "s/\" \/>//")
postData="action=login_username=admin_password=${database_pw}&__csrf_magic=${magic}"
wget $loadSaveCookie --post-data="$postData"
--output-document="$tmpFile2" http://localhost/cacti/index.php

 and then the real tries here:
# CVE-2016-3659 Unfortunately, I am not able to trigger the issue
wget $loadSaveCookie --timeout=10 --tries=1
"http://localhost/cacti/graph_view.php?action=tree_id=1_id=7=node1_7_group_data=graph_template:1
union select case when ord(substring((select version()) from 1 for 1))
between 53 and 53 then sleep(100) else 0 end"

wget $loadSaveCookie --timeout=10 --tries=1
--post-data="__csrf_magic=${magic}=tree_id=1_id=7=node1_7_group_data=graph_template:1%20union%20select%20case%20when%20ord(substring((select%20version())%20from%201%20for%201))%20between%2053%20and%2053%20then%20sleep(100)%20else%200%20end"
"http://localhost/cacti/graph_view.php;

Paul

¹ https://security-tracker.debian.org/tracker/CVE-2016-3659







signature.asc
Description: OpenPGP digital signature

Bug#822928: udev: Fail to start

[Corcodel Marian]

Package: udev
Version: 229-4
Severity: normal

root@marian1000:/home/asu# systemctl status udev
● systemd-udevd.service - udev Kernel Device Manager
   Loaded: loaded (/lib/systemd/system/systemd-udevd.service; static; vendor
preset: enabled)
   Active: active (running) since Fri 2016-04-29 07:04:38 EEST; 2min 32s ago
 Docs: man:systemd-udevd.service(8)
   man:udev(7)
 Main PID: 250 (systemd-udevd)
   Status: "Processing..."
Tasks: 1 (limit: 512)
   CGroup: /system.slice/systemd-udevd.service
   └─250 /lib/systemd/systemd-udevd

Apr 29 07:04:39 marian1000 mtp-probe[277]: checking bus 3, device 2:
"/sys/devices/pci:00/:00:1d.1/usb3/3-1"
Apr 29 07:04:39 marian1000 mtp-probe[277]: bus: 3, device: 2 was not an MTP
device
Apr 29 07:04:39 marian1000 mtp-probe[278]: checking bus 3, device 3:
"/sys/devices/pci:00/:00:1d.1/usb3/3-2"
Apr 29 07:04:39 marian1000 mtp-probe[278]: bus: 3, device: 3 was not an MTP
device
Apr 29 07:04:39 marian1000 systemd-udevd[303]: failed to execute
'/lib/udev/net.agent' 'net.agent': No such file or directory
Apr 29 07:04:39 marian1000 systemd-udevd[265]: Process 'net.agent' failed with
exit code 2.
Apr 29 07:04:39 marian1000 systemd-udevd[274]: Process '/lib/udev/hdparm'
failed with exit code 5.
Apr 29 07:04:40 marian1000 systemd-udevd[274]: Process '/lib/udev/hdparm'
failed with exit code 5.
Apr 29 07:04:40 marian1000 systemd-udevd[266]: Process '/lib/udev/hdparm'
failed with exit code 5.
Apr 29 07:04:40 marian1000 systemd-udevd[265]: Process '/lib/udev/hdparm'
failed with exit code 5.

Seems like missing /lib/udev/net.agent



-- Package-specific info:

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

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

Versions of packages udev depends on:
ii  adduser  3.114
ii  dpkg 1.18.4
ii  libacl1  2.2.52-3
ii  libblkid12.28-1
ii  libc62.22-7
ii  libkmod2 22-1.1
ii  libselinux1  2.4-3+b1
ii  libudev1 229-4
ii  lsb-base 9.20160110
ii  procps   2:3.3.11-3
ii  util-linux   2.28-1

udev recommends no packages.

udev suggests no packages.

Versions of packages udev is related to:
ii  systemd  229-4

-- debconf information:
  udev/reboot_needed:
  udev/sysfs_deprecated_incompatibility:
  udev/title/upgrade:
  udev/new_kernel_needed: false
P: /devices/LNXSYSTM:00
E: DEVPATH=/devices/LNXSYSTM:00
E: MODALIAS=acpi:LNXSYSTM:
E: SUBSYSTEM=acpi

P: /devices/LNXSYSTM:00/LNXCPU:00
E: DEVPATH=/devices/LNXSYSTM:00/LNXCPU:00
E: MODALIAS=acpi:LNXCPU:
E: SUBSYSTEM=acpi

P: /devices/LNXSYSTM:00/LNXCPU:01
E: DEVPATH=/devices/LNXSYSTM:00/LNXCPU:01
E: MODALIAS=acpi:LNXCPU:
E: SUBSYSTEM=acpi

P: /devices/LNXSYSTM:00/LNXCPU:02
E: DEVPATH=/devices/LNXSYSTM:00/LNXCPU:02
E: MODALIAS=acpi:LNXCPU:
E: SUBSYSTEM=acpi

P: /devices/LNXSYSTM:00/LNXCPU:03
E: DEVPATH=/devices/LNXSYSTM:00/LNXCPU:03
E: MODALIAS=acpi:LNXCPU:
E: SUBSYSTEM=acpi

P: /devices/LNXSYSTM:00/LNXPWRBN:00
E: DEVPATH=/devices/LNXSYSTM:00/LNXPWRBN:00
E: DRIVER=button
E: MODALIAS=acpi:LNXPWRBN:
E: SUBSYSTEM=acpi

P: /devices/LNXSYSTM:00/LNXPWRBN:00/input/input7
E: DEVPATH=/devices/LNXSYSTM:00/LNXPWRBN:00/input/input7
E: EV=3
E: ID_FOR_SEAT=input-acpi-LNXPWRBN_00
E: ID_INPUT=1
E: ID_INPUT_KEY=1
E: ID_PATH=acpi-LNXPWRBN:00
E: ID_PATH_TAG=acpi-LNXPWRBN_00
E: KEY=10 0
E: MODALIAS=input:b0019vp0001e-e0,1,k74,ramlsfw
E: NAME="Power Button"
E: PHYS="LNXPWRBN/button/input0"
E: PRODUCT=19/0/1/0
E: PROP=0
E: SUBSYSTEM=input
E: TAGS=:seat:
E: USEC_INITIALIZED=8850517

P: /devices/LNXSYSTM:00/LNXPWRBN:00/input/input7/event4
N: input/event4
E: BACKSPACE=guess
E: DEVNAME=/dev/input/event4
E: DEVPATH=/devices/LNXSYSTM:00/LNXPWRBN:00/input/input7/event4
E: ID_INPUT=1
E: ID_INPUT_KEY=1
E: ID_PATH=acpi-LNXPWRBN:00
E: ID_PATH_TAG=acpi-LNXPWRBN_00
E: MAJOR=13
E: MINOR=68
E: SUBSYSTEM=input
E: TAGS=:power-switch:
E: USEC_INITIALIZED=9184118
E: XKBLAYOUT=us
E: XKBMODEL=pc105

P: /devices/LNXSYSTM:00/LNXSYBUS:00
E: DEVPATH=/devices/LNXSYSTM:00/LNXSYBUS:00
E: MODALIAS=acpi:LNXSYBUS:
E: SUBSYSTEM=acpi

P: /devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00
E: DEVPATH=/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00
E: MODALIAS=acpi:PNP0A08:PNP0A03:
E: SUBSYSTEM=acpi

P: /devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/PNP0C01:00
E: DEVPATH=/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/PNP0C01:00
E: MODALIAS=acpi:PNP0C01:
E: SUBSYSTEM=acpi

P: /devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/PNP0C02:04
E: DEVPATH=/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/PNP0C02:04
E: MODALIAS=acpi:PNP0C02:
E: SUBSYSTEM=acpi

P: /devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/device:00
E: DEVPATH=/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/device:00
E: SUBSYSTEM=acpi

P: /devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/device:01
E: 

Bug#822927: golang-toml: Please update to latest upstream release

[Potter, Tim (HPE Linux Support)]

Package: golang-toml
Severity: wishlist
X-Debbugs-CC: pkg-go 

Please upload the latest release of the golang-logrus, 0.10.0.  I've already 
packaged this
in the repo on alioth.


Tim.


signature.asc
Description: Message signed with OpenPGP using GPGMail

Bug#822429: plasma-nm: Upstream Bug 362141: Connection editor fails with "connection.gateway-ping-timeout: can not set property: value"

[Manas Bhatnagar]

Hello,

I am experiencing this bug on my Debian computer.
I ran an "apt-get update && apt-get dist-upgrade" today but the issue still
persists.

Thanks,
Manas

Bug#822926: golang-logrus: Please update to latest upstream release

[Potter, Tim (HPE Linux Support)]

Package: golang-logrus
Severity: wishlist
X-Debbugs-CC: pkg-go 

Please upload the latest release of the golang-logrus, 0.10.0.  I've already 
packaged this
in the repo on alioth.


Tim.


signature.asc
Description: Message signed with OpenPGP using GPGMail

Bug#822925: golang-github-gorilla-context: Please update to latest upstream snapshot

[Potter, Tim (HPE Linux Support)]

Package: golang-github-gorilla-context
Severity: wishlist
X-Debbugs-CC: pkg-go 

Please upload the latest release of the 
golang-github-fluent-fluent-logger-golang,
0.0~git20160226.0.1ea2538.  I've already packaged this in the repo on alioth.

I've transitioned the binary package name in this update also - I've double 
checked but
it would be great if someone double-checked my work here.


Tim.


signature.asc
Description: Message signed with OpenPGP using GPGMail

Bug#822924: libsdl2-2.0-0: ibus support is disabled

[ookawa michiaki]

Package: libsdl2-2.0-0
Version: 2.0.4+dfsg1-2+b1
Severity: normal

Dear Maintainer,
Since 2.0.4, SDL can use ibus for input method.
Currently, libsdl2-2.0-0 doesn't support it.
Please add depends for libibus-1.0 and rebuild with it.

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

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

Versions of packages libsdl2-2.0-0 depends on:
ii  libasound2  1.1.0-1
ii  libc6   2.22-7
ii  libpulse0   8.0-2+b2
ii  libsndio6.1 1.1.0-2
ii  libwayland-client0  1.10.0-2
ii  libwayland-cursor0  1.10.0-2
ii  libwayland-egl1-mesa [libwayland-egl1]  11.1.3-1
ii  libx11-62:1.6.3-1
ii  libxcursor1 1:1.1.14-1+b1
ii  libxext62:1.3.3-1
ii  libxi6  2:1.7.6-1
ii  libxinerama12:1.1.3-1+b1
ii  libxkbcommon0   0.5.0-1
ii  libxrandr2  2:1.5.0-1
ii  libxss1 1:1.2.2-1
ii  libxxf86vm1 1:1.1.4-1

libsdl2-2.0-0 recommends no packages.

libsdl2-2.0-0 suggests no packages.

-- no debconf information

Bug#821103: ZFS support

[Russell Coker]

801189825  => "ZFS", # 0x2FC12FC1

Add the above line to the same file for ZFS support.

These changes are needed for freespace.monitor in package mon to monitor ZFS 
and BTRFS filesystems.

deb http://www.coker.com.au jessie misc

The above repository for i386 and amd64 has this package built with ZFS and 
BTRFS support.

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

Bug#815641: geary: please package the new fork of geary

[Vincent Cheng]

On Tue, Feb 23, 2016 at 1:00 AM, Kristof Csillag
 wrote:
> Package: geary
> Severity: wishlist
>
> The package hasn't been updated for almost a year now,
> because upstream development has ceased.
>
> Quoting to the wikipedia page for geary,
> https://en.wikipedia.org/wiki/Geary_(software)
>
>> As Yorba Foundation stopped its activities and the future
>> of this application was unclear, elementary OS still using
>> this email client by default, has decided to fork the project
>> on November 18, 2015, renaming the project to Pantheon Mail
>> during the process.
>
> Maybe Debian could also ship the fork, which is under active
> development?

There seems to be activity on the mailing list, as well as potentially
new maintainers stepping up to take care of geary [1]. In light of
this, I don't think it's appropriate to ship the eOS fork as geary;
rather, I think Pantheon Mail should be packaged separately.

Regards,
Vincent

[1] https://mail.gnome.org/archives/geary-list/2016-March/msg2.html

Bug#815639: geary: Geary won't start

[Vincent Cheng]

On Tue, Feb 23, 2016 at 12:39 AM, Kristof Csillag
 wrote:
> Package: geary
> Version: 0.10.0-1
> Severity: important
>
> When I try to launch geary, I get this:
>
> user@host:~$ geary
>
> (geary:17024): GLib-GIO-ERROR **: Settings schema 'org.yorba.geary' does not 
> contain a key named 'composer-pane-position'
> Trace/breakpoint trap
>
> and the it exits.
>
> The same version of geary (0.10.0) works for me if I compile it myself,
> this only happens with the debian package.
>
> It would be great if it could be fixed.

I'm unable to reproduce this; geary/0.10.0-1 launches fine for me on
my current testing/sid system, without needing to be rebuilt. You
shouldn't expect packages from sid to function on a stable system
as-is; re-building it in a stable environment/chroot before being able
to use a given package on stable is often necessary, assuming that's
what you're trying to achieve.

Regards,
Vincent

Bug#822672: RFS: freecell-solver/4.2.0-0.1 [NMU]

[Paul Wise]

On Thu, Apr 28, 2016 at 8:41 PM, Shlomi Fish wrote:

> I fixed most pep8 warnings there, except for some in the TAP library which was
> copied from https://github.com/rjbs/pytap .

Embedded code copies are discouraged in Debian, could you remove it
from upstream VCS and tarballs and make it a dependency instead?

https://wiki.debian.org/EmbeddedCodeCopies

-- 
bye,
pabs

https://wiki.debian.org/PaulWise

Bug#781501: gnote segfaults when it can't find a .note file

[Vincent Cheng]

Control: forwarded -1 https://bugzilla.gnome.org/show_bug.cgi?id=765791

Hi Michael,

On Sun, Apr 17, 2016 at 3:46 PM, Michael Biebl  wrote:
> Control: severity -1 grave
> Control: tags -1 - moreinfo unreproducible
>
> Hi Vincent
>
> Am 18.04.2016 um 00:35 schrieb Michael Biebl:
>>
>> I can reproduce the issue (backtrace attached).
>>
>> I do have a ~/.gnote folder. gnote has been installed a long time.
>> Moving ~/.gnote away, makes gnote start up.
>>
>> I do think this makes it a RC bug, as gnote should be able to deal with
>> old data after an upgrade.
>
> Here is a simple way to reproduce the bug:
>
> # remove existing data
> rm -rf ~/.local/share/gnote
> # create some legacy data
> mkdir ~/.gnote
> then copy the attached file to ~/.gnote/
>
> If you now start gnote, you'll get the crash. In the light of this
> simple reproducer and assuming that there are possibly quite a few users
> with old data, I'm raising the severity.

Thanks, I can reproduce it now. It seems like you don't even need
legacy data to trigger this segfault; any note file will do (I tried
with some of my current note files), so long as neither
$XDG_CONFIG_HOME/gnote or $XDG_DATA_HOME/gnote are present.

Regards,
Vincent

Bug#822923: base: Lenovo ThinkPad x220 tablet built in camera failes to work as expected.

[Demien M]

Package: base
Severity: important

Dear Maintainer,

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

   * What led up to the situation?
I installed a fresh Debian 8 (Jessie) on my Lenovo ThinkPad X220 
tablet. All features  worked as expected and to a usable/reasonable extend, 
INCLUDING the build in video camera (web-camera above the LCD bezel).

To test it i used cheese app and camera initiated as expected, produced video 
at the correct resolution, LED next to the camera turned on... all was good. 

A week in to using the OS/Laptop camera related issues surfaced. 

Bug#1. If tabled's screen folded in to a tablet mode (twisted and folded to 
that back of the LCD panel faces the keyboard on Lenovo X220 tablet, camera is 
no longer detected by OS. 

Returning (twisting) the LCD panel back in to traditional laptop mode does not 
resolve the issue. Camera still not detected. 

Bug#2. As of right now, at the full OS restart, running Cheese app - camera 
turns on as expected, produces a video from the camera in the app fro ~40 
seconds, and camera shuts off, while LED next to the camera stays on, and the 
Cheese app displays a message: "No camera detected".
LED stays on for another 5-10 seconds and turns off. 
At that point running "dmesg" shows a lot of errors related to /dev/video1 :


[   11.673646] thinkpad_acpi: This ThinkPad has standard ACPI backlight 
brightness control, supported by the ACPI video driver
[   58.933027] Linux video capture interface: v2.00
[   58.940526] uvcvideo: Found UVC 1.00 device Integrated Camera (04f2:b217)
[   59.113458] usbcore: registered new interface driver uvcvideo
[   61.752806] uvcvideo: Found UVC 1.00 device Integrated Camera (04f2:b217)
[   75.679877] uvcvideo: Failed to resubmit video URB (-19).
[   77.970672] uvcvideo: Found UVC 1.00 device Integrated Camera (04f2:b217)
[   92.368755] Modules linked in: uvcvideo videobuf2_vmalloc videobuf2_memops 
videobuf2_core v4l2_common videodev media bnep nfsd auth_rpcgss oid_registry 
nfs_acl nfs lockd fscache sunrpc nls_utf8 nls_cp437 vfat fat snd_hda_codec_hdmi 
ecb arc4 iTCO_wdt iTCO_vendor_support x86_pkg_temp_thermal intel_powerclamp 
intel_rapl iwldvm coretemp snd_hda_codec_conexant kvm_intel wacom mac80211 kvm 
snd_hda_codec_generic efi_pstore btusb bluetooth 6lowpan_iphc evdev joydev 
pcspkr serio_raw efivars i915 iwlwifi snd_hda_intel snd_hda_controller cfg80211 
snd_hda_codec lpc_ich thinkpad_acpi i2c_i801 mfd_core wmi snd_hwdep 
drm_kms_helper snd_pcm drm nvram snd_timer snd i2c_algo_bit rfkill soundcore 
tpm_tis battery ac i2c_core tpm mei_me video mei shpchp button processor fuse 
parport_pc ppdev lp parport autofs4 ext4 crc16
[   92.368942]  [] ? uvc_delete+0x13/0x160 [uvcvideo]
[   92.368970]  [] ? v4l2_release+0x4a/0x80 [videodev]
[   92.381641] Modules linked in: uvcvideo videobuf2_vmalloc videobuf2_memops 
videobuf2_core v4l2_common videodev media bnep nfsd auth_rpcgss oid_registry 
nfs_acl nfs lockd fscache sunrpc nls_utf8 nls_cp437 vfat fat snd_hda_codec_hdmi 
ecb arc4 iTCO_wdt iTCO_vendor_support x86_pkg_temp_thermal intel_powerclamp 
intel_rapl iwldvm coretemp snd_hda_codec_conexant kvm_intel wacom mac80211 kvm 
snd_hda_codec_generic efi_pstore btusb bluetooth 6lowpan_iphc evdev joydev 
pcspkr serio_raw efivars i915 iwlwifi snd_hda_intel snd_hda_controller cfg80211 
snd_hda_codec lpc_ich thinkpad_acpi i2c_i801 mfd_core wmi snd_hwdep 
drm_kms_helper snd_pcm drm nvram snd_timer snd i2c_algo_bit rfkill soundcore 
tpm_tis battery ac i2c_core tpm mei_me video mei shpchp button processor fuse 
parport_pc ppdev lp parport autofs4 ext4 crc16
[   92.381741]  [] ? uvc_delete+0x13/0x160 [uvcvideo]
[   92.381749]  [] ? v4l2_release+0x4a/0x80 [videodev]
[   92.381783] Modules linked in: uvcvideo videobuf2_vmalloc videobuf2_memops 
videobuf2_core v4l2_common videodev media bnep nfsd auth_rpcgss oid_registry 
nfs_acl nfs lockd fscache sunrpc nls_utf8 nls_cp437 vfat fat snd_hda_codec_hdmi 
ecb arc4 iTCO_wdt iTCO_vendor_support x86_pkg_temp_thermal intel_powerclamp 
intel_rapl iwldvm coretemp snd_hda_codec_conexant kvm_intel wacom mac80211 kvm 
snd_hda_codec_generic efi_pstore btusb bluetooth 6lowpan_iphc evdev joydev 
pcspkr serio_raw efivars i915 iwlwifi snd_hda_intel snd_hda_controller cfg80211 
snd_hda_codec lpc_ich thinkpad_acpi i2c_i801 mfd_core wmi snd_hwdep 
drm_kms_helper snd_pcm drm nvram snd_timer snd i2c_algo_bit rfkill soundcore 
tpm_tis battery ac i2c_core tpm mei_me video mei shpchp button processor fuse 
parport_pc ppdev lp parport autofs4 ext4 crc16
[   92.381833]  [] ? uvc_delete+0x13/0x160 [uvcvideo]
[   92.381838]  [] ? v4l2_release+0x4a/0x80 [videodev]
[   92.381857] Modules linked in: uvcvideo videobuf2_vmalloc videobuf2_memops 
videobuf2_core v4l2_common videodev media bnep nfsd auth_rpcgss oid_registry 
nfs_acl nfs lockd fscache sunrpc nls_utf8 nls_cp437 vfat fat snd_hda_codec_hdmi 
ecb arc4 iTCO_wdt iTCO_vendor_support x86_pkg_temp_thermal intel_powerclamp 

Bug#822844: openssh-client: can't use an in-memory-only certificate that doesn't also have another in-memory private key

[gustavo panizzo]

On Thu, Apr 28, 2016 at 11:41:39 +0100, Colin Watson wrote:
> Are you sure that you were affected by this in 1:7.2p2-5, and not in
> 1:7.2p2-4 or earlier versions?

Hi Colin

I'm using a propietary tool which calls OpenSSH, called scaleFT

second bastion: i-9a366215 52.196.150.130
target server: i-c2a3f64d 10.0.0.21

$ sft ssh i-c2a3f64d --via=gust9547@bastion --via=i-9a366215
debug1: Executing proxy command: exec /usr/bin/sft _ssh-chain 
remote_user@52.196.150.130\342\213\256/home/gust9547/.local/share/ScaleFT/ssh/08917140d1a421d4b705bf92a77bc99eb2d93af60,/home/gust9547/.local/share/ScaleFT/ssh_known_hosts/4d6d5469f19216a407c5757f848f86e1ef1b8ceb
 gust9547@bastion --netcat 10.0.0.21:22
debug1: permanently_drop_suid: 1000
debug1: key_load_public: No such file or directory
debug1: identity file 
/home/gust9547/.local/share/ScaleFT/ssh/08917140d1a421d4b705bf92a77bc99eb2d93af60
 type -1
debug1: identity file 
/home/gust9547/.local/share/ScaleFT/ssh/08917140d1a421d4b705bf92a77bc99eb2d93af60-cert
 type 5
debug1: identity file /home/gust9547/.ssh/id_rsa type 1
debug1: key_load_public: No such file or directory
debug1: identity file /home/gust9547/.ssh/id_rsa-cert type -1
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_7.2p2 Debian-5
debug1: Executing proxy command: exec /usr/bin/sft _ssh-chain gust9547@bastion 
--netcat 52.196.150.130:22
debug1: permanently_drop_suid: 1000
debug1: key_load_public: No such file or directory
debug1: identity file 
/home/gust9547/.local/share/ScaleFT/ssh/08917140d1a421d4b705bf92a77bc99eb2d93af60
 type -1
debug1: identity file 
/home/gust9547/.local/share/ScaleFT/ssh/08917140d1a421d4b705bf92a77bc99eb2d93af60-cert
 type 5
debug1: identity file /home/gust9547/.ssh/id_rsa type 1
debug1: key_load_public: No such file or directory
debug1: identity file /home/gust9547/.ssh/id_rsa-cert type -1
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_7.2p2 Debian-5
debug1: Connecting to bastion [10.11.57.10] port 22.
debug1: Connection established.
debug1: identity file /home/gust9547/.ssh/id_rsa type 1
debug1: key_load_public: No such file or directory
debug1: identity file /home/gust9547/.ssh/id_rsa-cert type -1
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_7.2p2 Debian-5
debug1: Remote protocol version 2.0, remote software version OpenSSH_4.3
debug1: match: OpenSSH_4.3 pat OpenSSH_4* compat 0x
debug1: Authenticating to bastion:22 as 'gust9547'
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: algorithm: diffie-hellman-group-exchange-sha1
debug1: kex: host key algorithm: ssh-rsa
debug1: kex: server->client cipher: aes128-ctr MAC: hmac-sha1 compression: none
debug1: kex: client->server cipher: aes128-ctr MAC: hmac-sha1 compression: none
debug1: SSH2_MSG_KEX_DH_GEX_REQUEST(2048<7680<8192) sent
debug1: got SSH2_MSG_KEX_DH_GEX_GROUP
debug1: SSH2_MSG_KEX_DH_GEX_INIT sent
debug1: got SSH2_MSG_KEX_DH_GEX_REPLY
debug1: Server host key: ssh-rsa 
SHA256:zDv30XNTXeXQA3kophOAMmZb+uIHcehGPo4L840l+ro
debug1: Host 'bastion' is known and matches the RSA host key.
debug1: Found key in /home/gust9547/.ssh/known_hosts:1
debug1: rekey after 4294967296 blocks
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: rekey after 4294967296 blocks
debug1: SSH2_MSG_NEWKEYS received
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: Authentications that can continue: publickey,keyboard-interactive
debug1: Next authentication method: publickey
debug1: Offering RSA public key: /home/gust9547/.ssh/id_rsa
debug1: Server accepts key: pkalg ssh-rsa blen 279
debug1: Authentication succeeded (publickey).
Authenticated to bastion ([10.11.57.10]:22).
debug1: channel_connect_stdio_fwd 52.196.150.130:22
debug1: channel 0: new [stdio-forward]
debug1: getpeername failed: Bad file descriptor
debug1: Entering interactive session.
debug1: pledge: network
debug1: Remote protocol version 2.0, remote software version OpenSSH_6.6.1
debug1: match: OpenSSH_6.6.1 pat OpenSSH_6.6.1* compat 0x0400
debug1: Authenticating to 52.196.150.130:22 as 'remote_user'
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: algorithm: curve25519-sha...@libssh.org
debug1: kex: host key algorithm: ecdsa-sha2-nistp256
debug1: kex: server->client cipher: chacha20-poly1...@openssh.com MAC: 
 compression: none
debug1: kex: client->server cipher: chacha20-poly1...@openssh.com MAC: 
 compression: none
debug1: expecting SSH2_MSG_KEX_ECDH_REPLY
debug1: Server host key: ecdsa-sha2-nistp256 
SHA256:GS4hAJXHiSRmkkhbvaKNnlA1vve+iZSNWYDAGQJQp5g
debug1: Host '52.196.150.130' is known and matches the ECDSA host key.
debug1: Found key in 
/home/gust9547/.local/share/ScaleFT/ssh_known_hosts/4d6d5469f19216a407c5757f848f86e1ef1b8ceb:5
debug1: rekey after 134217728 blocks
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: rekey after 

Bug#821454: [pkg-golang-devel] Bug#821454: [pkg-go] Bug#821454: dh-golang: Position-independent executables (PIE)

[Michael Hudson-Doyle]

On 29 April 2016 at 13:17, Michael Hudson-Doyle
 wrote:
> On 29 April 2016 at 12:40, Peter Colberg  wrote:
>> Hi Michael,
>>
>> On Wed, Apr 27, 2016 at 01:35:30PM +1200, Michael Hudson-Doyle wrote:
>>> I think only pie, bindnow and relro make sense for Go.
>>
>> I figured out how to link with BINDNOW and RELRO using -extldflags:
>>
>> # Pass hardening flags to linker
>> GO_LDFLAGS += -extldflags=-Wl,-z,now,-z,relro
>
> Ah yes, makes sense. TBH, I wonder about changing Go to always pass
> those flags...

In fact, I'm pretty sure that not passing relro is just a bug:
https://github.com/golang/go/issues/15485

Cheers,
mwh

Bug#822922: ITP: python-stopit -- Timeout control decorator and context manager

[Adrian Alves]

Package: wnpp
Severity: wishlist
Owner: Adrian Alves 

* Package name: python-stopit
  Version : 1.1.1
  Upstream Author : Gilles Lenfant 
* URL : https://github.com/glenfant/stopit
* License : GPL-3+
  Programming Lang: Python
  Description : Timeout control decorator and context manager

Raise asynchronous exceptions in other threads, control
the timeout of blocks or callables with two context
managers and two decorators.

Bug#821454: [pkg-golang-devel] Bug#821454: [pkg-go] Bug#821454: dh-golang: Position-independent executables (PIE)

[Michael Hudson-Doyle]

On 29 April 2016 at 12:40, Peter Colberg  wrote:
> Hi Michael,
>
> On Wed, Apr 27, 2016 at 01:35:30PM +1200, Michael Hudson-Doyle wrote:
>> I think only pie, bindnow and relro make sense for Go.
>
> I figured out how to link with BINDNOW and RELRO using -extldflags:
>
> # Pass hardening flags to linker
> GO_LDFLAGS += -extldflags=-Wl,-z,now,-z,relro

Ah yes, makes sense. TBH, I wonder about changing Go to always pass
those flags...

> # hardening-check acmetool
> acmetool:
>  Position Independent Executable: yes
>  Stack protected: no, not found!
>  Fortify Source functions: no, only unprotected functions found!
>  Read-only relocations: yes
>  Immediate binding: yes
>
>> If you use -pkgdir, the standard library is rebuilt whatever you do.
>
> I think -pkgdir is not needed at all for building with -buildmode=pie.

So long as we add the golang-std-pie-dev flag, yeah.

> I suggest the following path going forward:
>
>  * Ship the -buildmode=pie std library in a separate package
>golang-std-pie-dev as part of the golang source package.
>
>  * Extend dh-golang to translate the dpkg hardening flags into
>-buildmode=pie and -extldflags=-Wl,-z,now,-z,relro as needed.
>
> I am filing a separate bug to implement the first change.
>
> The second change need not happen right away; since it only affects
> packages that build executables, which are very few among the many
> golang packages, this can also be implemented on a case-by-case
> basis for now.

So we'll leave this bug for that bit?

>> The performance and binary size hit of PIE on i386 in particular is
>> likely to be large. Do you care at all about that?
>
> I noticed for amd64 that the size of the stripped acmetool executable
> increases from 10 to 15 MB, which is significant but not dramatic
> compared to the overall bloat of Go executables. The size of the
> compressed Debian package increases from 2.2 to 2.7 MB. (That is
> a compression ratio of 5:1 in both cases.)

That's not too bad. It will be better in Go 1.7!

> Is this not a general issue that affects all Debian packages compiled
> with hardening flags? Or do you potentially see Go-specific size and
> performance issues?

Well, I mentioned i386 for a reason: the PIE code gen for Go on 386 is
extremely stupid (I should know, I wrote it). For other architectures
it should not be nearly so bad. So if you care about performance at
all on 386, you might not want to build PIE there. But I'm not sure
anyone does any more?

Cheers,
mwh

Bug#822667: RFP: gcc-6-doc -- documentation for the GNU compilers (gcc, gobjc, g++)

[Guo Yixuan (郭溢譞)]

Package: wnpp
Followup-For: Bug #822667
Owner: "Guo Yixuan (郭溢譞)" 
Control: retitle -1 ITP: gcc-6-doc -- documentation for the GNU compilers (gcc, 
gobjc, g++)

Hello,

Thank you for the notice. I'll work on it shortly.

Regards,
Yixuan

Bug#821454: [pkg-golang-devel] Bug#821454: [pkg-go] Bug#821454: dh-golang: Position-independent executables (PIE)

[Peter Colberg]

Hi Michael,

On Wed, Apr 27, 2016 at 01:35:30PM +1200, Michael Hudson-Doyle wrote:
> I think only pie, bindnow and relro make sense for Go.

I figured out how to link with BINDNOW and RELRO using -extldflags:

# Pass hardening flags to linker
GO_LDFLAGS += -extldflags=-Wl,-z,now,-z,relro

# hardening-check acmetool
acmetool:
 Position Independent Executable: yes
 Stack protected: no, not found!
 Fortify Source functions: no, only unprotected functions found!
 Read-only relocations: yes
 Immediate binding: yes

> If you use -pkgdir, the standard library is rebuilt whatever you do.

I think -pkgdir is not needed at all for building with -buildmode=pie.

I suggest the following path going forward:

 * Ship the -buildmode=pie std library in a separate package
   golang-std-pie-dev as part of the golang source package.

 * Extend dh-golang to translate the dpkg hardening flags into
   -buildmode=pie and -extldflags=-Wl,-z,now,-z,relro as needed.

I am filing a separate bug to implement the first change.

The second change need not happen right away; since it only affects
packages that build executables, which are very few among the many
golang packages, this can also be implemented on a case-by-case
basis for now.

> The performance and binary size hit of PIE on i386 in particular is
> likely to be large. Do you care at all about that?

I noticed for amd64 that the size of the stripped acmetool executable
increases from 10 to 15 MB, which is significant but not dramatic
compared to the overall bloat of Go executables. The size of the
compressed Debian package increases from 2.2 to 2.7 MB. (That is
a compression ratio of 5:1 in both cases.)

Is this not a general issue that affects all Debian packages compiled
with hardening flags? Or do you potentially see Go-specific size and
performance issues?

Regards,
Peter

Bug#822921: uwsgi: FTBFS with latest apache2

[Jonas Smedegaard]

Hi Vincent,

Thanks a lot for your analysis - and for sharing why uwsgi was binNMU'ed 
(QA page didn't reveal it).

Quoting Vincent Cheng (2016-04-29 02:14:08)
> Buildd logs show that uwsgi FTBFS after having been binNMU-ed for the 
> gloox transition, but uwsgi actually builds fine with either version 
> of gloox (1.0.13-3 or 1.0.15-2) as long as the older version of 
> apache2-dev is installed, so this FTBFS wasn't caused by the gloox 
> transition.

I agree this does not look like caused by the gloox change.  It is my 
headache to tackle.

Thanks again,

 - Jonas

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

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


signature.asc
Description: signature

Bug#822921: uwsgi: FTBFS with latest apache2

[Vincent Cheng]

Source: uwsgi
Version: 2.0.12-5
Severity: serious
Justification: fails to build from source (but built successfully in the past)

Hi,

uwsgi currently FTBFS in sid. It looks like it might have something to
do with recent changes in apache2, because uwsgi builds fine with
apache2-dev/2.4.18-2 installed, but FTBFS with apache2-dev/2.4.20-1
(currently in sid). Buildd logs show that uwsgi FTBFS after having
been binNMU-ed for the gloox transition, but uwsgi actually builds
fine with either version of gloox (1.0.13-3 or 1.0.15-2) as long as
the older version of apache2-dev is installed, so this FTBFS wasn't
caused by the gloox transition.

buildd logs can be found at [1] as usual, tail as follows:

apache2/mod_proxy_uwsgi.c:262:21: error: static declaration of
'ap_proxy_buckets_lifetime_transform' follows non-static declaration
 static apr_status_t ap_proxy_buckets_lifetime_transform(request_rec *r,
 ^
In file included from apache2/mod_proxy_uwsgi.c:50:0:
/usr/include/apache2/mod_proxy.h:1069:29: note: previous declaration
of 'ap_proxy_buckets_lifetime_transform' was here
 PROXY_DECLARE(apr_status_t) ap_proxy_buckets_lifetime_transform(request_rec *r,
 ^
apxs:Error: Command failed with rc=65536

Regards,
Vincent

[1] https://buildd.debian.org/status/package.php?p=uwsgi=unstable

Bug#822856: RFS: dvtm/0.15-0.1 NMU

[Dmitry Bogatov]

> >  * Bump debhelper compat level (9 -> 10),
> Compat level 10 is an experimental feature. NMUs is not a place to make
> experiments.
>
> >  * Convert debian/changelog into DEP-5 format
>
> ITYM debian/copyright, but this is not appropriate for an NMU either.
Will fix it.

> >  * Bump standards version to 3.9.8 (no changes needed)
> Ditto.

> maybe we can also start a MIA process?

I do not want to put a pressure on anyone, but if it is the only way
to make big changes to package, let's do it.

BTW, is it some rule of thumb, how many days of no response to
please-package-new-upstream-version-bug should pass before considering
NMU/MIA?

-- 
Accept: text/plain, text/x-diff
Accept-Language: eo,en,ru
X-Keep-In-CC: yes
X-Web-Site: sinsekvu.github.io

Bug#822895: RFS: singular/4.0.3-p1+ds-1 [NEW VERSION] - Computer Algebra System for Polynomial Computations

[Jerome BENOIT]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Many thanks to Andreas, Jerome
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQEcBAEBCAAGBQJXIphPAAoJEIC/w4IMSybjspkIAKQeNlspUT0+hKAAb1O8YStL
QzPjMeU8bx1wzqNJChXCkdIBHEiFOeC3zC5mNadyQuK67/QULtY1wTqsxaeoiOJl
uRZdD9zgXZuAGlSo0Ygz+NtFvvivFvjQaF77GOlAjm5S64YPprcAHnnPkjWYZjJL
V7O69iechNIXZ/9VzsOMYapLW/kcMUv0Vn+atPQAZPj0M4YlzJNm/hUSZ5XzKM0w
gLkclcTXgcYLu4z8AJLSawjAvCAV8HYCaEPUzfTRbIkcUBMS3bbD8tcb3tWtNI3d
Fzz8KJvUKZlAwhf/hq1zcTJNaL8mE56znW+bZZWcrodS7iw+RmgVrv8JYZCKtG0=
=hgcj
-END PGP SIGNATURE-

Bug#822890: aptitude: [INTL:nl] Dutch po file for the aptitude package's documentation

[Manuel A. Fernandez Montecelo]

Control: tags -1 + pending


Hi,

2016-04-28 19:41 Frans Spiesschaert:



Package: aptitude
Severity: wishlist
Tags: l10n patch


Dear Maintainer,

==
Please find attached the updated Dutch po file for the aptitude package's
documentation. It has been submitted for review to the
debian-l10n-dutch mailing list. Please add it to your next package
revision. It should be put as "doc/po4a/po/nl.po" in your package build tree.
===


Committed, thanks!


--
Manuel A. Fernandez Montecelo 

Bug#822919: xfce4-terminal: solarized preset breaks ls colors

[Matt Taggart]

Package: xfce4-terminal
Version: 0.6.3-1+b1
Severity: wishlist

When I load the "solarized (dark)" color presets, the formerly colorful ls 
output becomes mostly bold text. Using the current upstream solarized config 
does the same thing.

Ideally the ls output colors would use the same solarized palette.

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

Bug#822889: aptitude: [INTL:nl] Dutch po file for the aptitude package

[Manuel A. Fernandez Montecelo]

Control: tags -1 + pending


Hi,

2016-04-28 19:34 Frans Spiesschaert:



Package: aptitude
Severity: wishlist
Tags: l10n patch


Dear Maintainer,

==
Please find attached the updated Dutch po file for the aptitude package.
It has been submitted for review to the debian-l10n-dutch mailing list.
Please add it to your next package revision.
It should be put as "po/nl.po" in your package build tree.
===


Commited, thanks!


--
Manuel A. Fernandez Montecelo 

Bug#822918: sysvinit-utils: init-d-script and NAME environment variable conflict

[Ben Kibbey]

Package: sysvinit-utils
Version: 2.88dsf-59.3
Severity: normal

Dear Maintainer,

   * What led up to the situation?

The NAME environment variable is used by a few applications to obtain the users
real name but the NAME variable is not overwritten when set during an upgrade
of lvm2. Renaming the NAME variable in /lib/init/init-d-script to something
else (e.g., PROGNAME) should fix it.

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

After the upgrade was complete, insserv exec'd /etc/init.d/lvmetad which
sources /lib/init/init-d-script.

   * What was the outcome of this action?

/etc/init.d/lvm2-lvmetad: 183: [: /etc/default/Ben: unexpected operator
Restarting LVM2 metadata daemon: Ben Kibbey.

   * What outcome did you expect instead?

Restarting LVM2 metadata daemon: lvm2-lvmetad



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

Kernel: Linux 4.5.2-1-g3c69b4d (SMP w/8 CPU cores; PREEMPT)
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 sysvinit-utils depends on:
ii  init-system-helpers  1.29
ii  libc62.22-7
ii  startpar 0.59-3

sysvinit-utils recommends no packages.

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

-- no debconf information
--- init-d-script.orig	2016-04-28 18:25:28.0 -0400
+++ init-d-script	2016-04-28 18:25:04.0 -0400
@@ -45,11 +45,11 @@
 do_start_cmd() {
 	start-stop-daemon --start --quiet ${PIDFILE:+--pidfile ${PIDFILE}} \
 	$START_ARGS \
-	--startas $DAEMON --name $NAME --exec $DAEMON --test > /dev/null \
+	--startas $DAEMON --name $PROGNAME --exec $DAEMON --test > /dev/null \
 	|| return 1
 	start-stop-daemon --start --quiet ${PIDFILE:+--pidfile ${PIDFILE}} \
 	$START_ARGS \
-	--startas $DAEMON --name $NAME --exec $DAEMON -- $DAEMON_ARGS \
+	--startas $DAEMON --name $PROGNAME --exec $DAEMON -- $DAEMON_ARGS \
 	|| return 2
 	# Add code here, if necessary, that waits for the process to be ready
 	# to handle requests from services started subsequently which depend
@@ -61,7 +61,7 @@
 	if is_call_implemented do_start_prepare ; then
 		call do_start_prepare
 	fi
-	[ "$VERBOSE" != no ] && log_daemon_msg "Starting $DESC" "$NAME"
+	[ "$VERBOSE" != no ] && log_daemon_msg "Starting $DESC" "$PROGNAME"
 	call do_start_cmd
 	case "$?" in
 		0|1) [ "$VERBOSE" != no ] && log_end_msg 0 ;;
@@ -84,7 +84,7 @@
 do_stop_cmd() {
 	start-stop-daemon --stop --quiet --retry=TERM/30/KILL/5 \
 	$STOP_ARGS \
-	${PIDFILE:+--pidfile ${PIDFILE}} --name $NAME --exec $DAEMON
+	${PIDFILE:+--pidfile ${PIDFILE}} --name $PROGNAME --exec $DAEMON
 	RETVAL="$?"
 	[ "$RETVAL" = 2 ] && return 2
 	# Wait for children to finish too if this is a daemon that forks
@@ -107,7 +107,7 @@
 	if is_call_implemented do_stop_prepare ; then
 		call do_stop_prepare
 	fi
-	[ "$VERBOSE" != no ] && log_daemon_msg "Stopping $DESC" "$NAME"
+	[ "$VERBOSE" != no ] && log_daemon_msg "Stopping $DESC" "$PROGNAME"
 	call do_stop_cmd
 	case "$?" in
 		0|1) [ "$VERBOSE" != no ] && log_end_msg 0 ;;
@@ -119,7 +119,7 @@
 }
 
 do_restart() {
-	[ "$VERBOSE" != no ] && log_daemon_msg "Restarting $DESC" "$NAME"
+	[ "$VERBOSE" != no ] && log_daemon_msg "Restarting $DESC" "$PROGNAME"
 	call do_stop_cmd
 	call do_start_cmd
 	case "$?" in
@@ -139,14 +139,14 @@
 # Enable this using
 # alias do_reload=do_reload_sigusr1
 do_reload_sigusr1() {
-log_daemon_msg "Reloading $DESC configuration files" "$NAME"
+log_daemon_msg "Reloading $DESC configuration files" "$PROGNAME"
 start-stop-daemon --oknodo --stop --signal 1 --quiet \
   --pidfile "$PIDFILE" --exec "$DAEMON"
 log_end_msg $?
 }
 
 do_status() {
-	status_of_proc "$DAEMON" "$NAME" && return 0 || return $?
+	status_of_proc "$DAEMON" "$PROGNAME" && return 0 || return $?
 }
 
 if [ "$DEBUG" = "true" ] ; then
@@ -163,15 +163,15 @@
 exit 0
 fi
 
-NAME=${NAME:=$(basename $DAEMON)}
-DESC=${DESC:=$NAME}
+PROGNAME=${PROGNAME:=$(basename $DAEMON)}
+DESC=${DESC:=$PROGNAME}
 
 # Do not use pid file if $PIDFILE is 'none'.  Otherwise, generate from
-# $NAME or use the value provided by the init.d script.
+# $PROGNAME or use the value provided by the init.d script.
 if [ none = "$PIDFILE" ] ; then
 PIDFILE=
 elif [ -z "$PIDFILE" ] ; then
-PIDFILE=/var/run/$NAME.pid
+PIDFILE=/var/run/$PROGNAME.pid
 fi
 
 # Exit if the package is not installed
@@ -180,7 +180,7 @@
 fi
 
 # Read configuration variable file if it is present
-[ -r /etc/default/$NAME ] && . /etc/default/$NAME
+[ -r /etc/default/$PROGNAME ] && . /etc/default/$PROGNAME
 
 # Load the VERBOSE setting and other rcS variables
 . /lib/init/vars.sh
@@ -213,7 +213,7 @@
 	call do_restart
 	;;
   try-restart)
-

Bug#819859: fixed in sawfish 1:1.11.90-1

[dave]

"Anne C. Hanna"  writes:

> Upgrading to 1:1.11.90-1 didn't fix the bug for me, but I am now seeing errors
> more exactly like what others have reported.

I just tried on my unstable machine and for me it seems to have fixed
the main issue. Now sawfish starts up and doesn't exit, even after
removing the sawfish-lisp-source package.

> Sawfish error:
> File error: No such file or directory, gnome

I still get that error in the log and the popup message.

> Sawfish error:
> Unbound variable: expert

I think this one is related to the theme. I'm using a custom theme
and I got a similar message when I first upgraded to the earlier
1.11 version. It's to do with themes being able to designate config
options as being for expert or novice users. I assumed that had
been removed from the upstream sawfish so I removed it from my
theme and it stopped that errror message. The lines I had to remove
looked like this, in the theme.jl:

   :user-level novice

> Sawfish error:
> File error: No such file or directory, sawfish/wm/ext/edge-flip

I don't use that but it looks like the file has moved. So if you have...

(require 'sawfish.wm.ext.edge-flip)

...it probably needs changing to...

(require 'sawfish.wm.edge.flip)

also seems to work with just...

(require 'edge-flip)

> I also saw an error during installation of 1:1.11.90-1:
[...]
> ERROR: sawfish is broken - called emacs-package-install as a new-style add-on,
> but has no compat file.

I got that one too. But sawfish mode still seems to work.

Bug#742282: Re: btrfs-tools: receive fails if btrfs is mounted with a non-root default subvolume

[Γιώργος Πάλλας]

On 25/04/16 21:53, Nicholas D Steeves wrote:

Followup-For: Bug #742282

Hi Giorgos,

Does your script trigger this behaviour with btrfs-tools-3.17-1.1?  If
it doesn't, great!  If it does, please read on.


Hi Nicholas!

The behaviour has changed. I don't get anymore the "ERROR: open 
def/subvROsnap1 failed. No such file or directory" but the following:


It seems that you have changed your default subvolume or you specify 
other subvolume to
mount btrfs, try to remount this btrfs filesystem with fs tree, and run 
btrfs receive again!



#1: There are known issues with btrfs send|receive when operating on
volumes mounted with the default subvolume (subvolid=5); This is what
happens with a simple mkfs.btrfs /dev/sdX && mount /dev/sdX /mnt/1.
The following instructions exists primarily to gather the negative
results necessary to confirm this.  If it works, you will have
succeeded in providing data that disproves commonly held btrfs lore.
#2 and #3 are also possible causes.

#2: If you still get "no such file or directory," it may be that that
you've encountered one of the "timing issues" in btrfs.  There are
fewer and fewer of these with every release, but I still keep a couple
of "work around the timing issues" lines in my backup scripts.  For
the record, my scripts don't use btrfs send|receive, and I had timing
issues which hung subvolume management until the system was rebooted.
I've also read about some nasty interactions between the loop
subsystem and btrfs...it might be worth increasing the sleep times
even more, in case transactions are stalling somewhere in the loop.
It would be appreciated if you could find a small usb flash drive to
test this, to eliminate the loop subsystem as a contributing factor.

#3: I've read that another data needs to be committed to the disk
before a snapshot actually exists.  This would also explain why you
received a "no such file or directory" error.  Arguably, this is part
of the #2 group of issues, but I've broken it out into it's own point
because #2 is a huge and complicated category of issues.  #3 can be
eliminated simply by making sure that the data is physically on the
disk (eg: sync the FS to get it into a consistent state, then sync to
disk).

Could you please try replacing the btrfs sub section and the btrfs
send section with the following:

btrfs sub create mnt/1/subv
sleep 3
date > mnt/1/subv/fileA
btrfs fi sync /mnt/1
sleep 3
sync
sleep 3
btrfs sub snap -r mnt/1/subv mnt/1/subvROsnap1
date > mnt/1/subv/fileB
btrfs fi sync /mnt/1
sleep 3
sync
sleep 3
btrfs sub snap -r mnt/1/subv mnt/1/subvROsnap2

btrfs send mnt/1/subvROsnap1 | btrfs receive mnt/2
btrfs fi sync /mnt/1
sleep 3
sync
sleep 3
btrfs send -p mnt/1/subvROsnap1 mnt/1/subvROsnap2 | btrfs receive mnt/2
##


This worked without any problems :-)
(note that I fixed the typo '/mnt' which should be 'mnt')



and also, if you have the time, please test this one too:

btrfs sub create mnt/1/subv
sleep 3
date > mnt/1/subv/fileA
btrfs sub sync /mnt/1/subv
sleep 3
sync
sleep 3
btrfs sub snap -r mnt/1/subv mnt/1/subvROsnap1
date > mnt/1/subv/fileB
btrfs sub sync /mnt/1
sleep 3
sync
sleep 3
btrfs sub snap -r mnt/1/subv mnt/1/subvROsnap2

btrfs send mnt/1/subvROsnap1 | btrfs receive mnt/2
btrfs sub sync /mnt/1
sleep 3
sync
sleep 3
btrfs send -p mnt/1/subvROsnap1 mnt/1/subvROsnap2 | btrfs receive mnt/2

Kind regards,
Nicholas



This also worked without any problems!
(fixed same typo as before)

Cheers,
Giorgos




smime.p7s
Description: S/MIME Cryptographic Signature

Bug#822917: mirrors: carroll.aset.psu.edu not working

[Matt Taggart]

Package: mirrors
Version: 20160428

carroll.aset.psu.edu seems to be broken. When you go to 

ftp://carroll.aset.psu.edu/pub/linux/distributions/debian/

(as listed on the mirrors page) you get "550 failed to change directory"

If you look in the parent dir it has "ubuntu" and "centos" but not debian.

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

Bug#820895: sphinx: please extend SOURCE_DATE_EPOCH support

[Alexis Bienvenüe]

Control: forwarded -1 https://github.com/sphinx-doc/sphinx/pull/2503

Hi Dmitry.

Le 24/04/2016 14:40, Dmitry Shachnev a écrit :
> Can you please submit your patch upstream (like you did it for #822197)?
> 
> I would really prefer to get this patch reviewed/accepted by upstream before
> including it in the Debian packaging. (Also, if you will be submitting it,
> better use stable branch of git rather than master, which will make sure your
> change will be in the next bugfix release if accepted.)

As suggested - thanks, and sorry for the delay.

Alexis.

Bug#765175: systemd init script integration: status action should use --lines=0

[Michael Biebl]

Am 28.04.2016 um 23:43 schrieb Martin Pitt:
> Michael Biebl [2016-04-28 23:14 +0200]:
>> I was under the impression that the systemctl command detects if you are
>> running it from a terminal or not and disables the pager in the latter case.
> 
> It does, but if the calling command runs in a terminal itself (like
> "vagrant up") that doesn't help.

Well, if that is the case, wouldn't it be better if vagrant would set
$SYSTEMD_PAGER="" (or cat), so systemctl, invoke-rc.d, service and
/etc/init.d/foo would *all* work.

It seems odd to special-case /etc/init.d/foo imho.


-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?



signature.asc
Description: OpenPGP digital signature

Bug#822916: lives: crashes on startup

[koanhead]

Package: lives
Version: 2.2.6~ds0-1
Severity: important

Dear Maintainer,

Attempting to start LiVES (aka 'lives'), both from menu and from terminal,
results in a crash with the following message:

"
LiVES 2.2.6
Copyright 2002-2014 Gabriel Finch (salsa...@gmail.com) and others.
LiVES comes with ABSOLUTELY NO WARRANTY
This is free software, and you are welcome to redistribute it
under certain conditions; see the file COPYING for details.

LiVES info: Invalid effect farneback_analyserfarneback_analysersalsaman1 found
in compound effect image_stabilizer, line 4

LiVES info: Invalid effect farneback_analyserfarneback_analysersalsaman1 found
in compound effect motion_analyser, line 4

**
Gtk:ERROR:/tmp/buildd/gtk+3.0-3.14.5/./gtk/gtkprogressbar.c:604:tick_cb:
assertion failed: (priv->pulse2 > priv->pulse1)

Unfortunately LiVES crashed.
Please report this bug at
http://sourceforge.net/tracker/?group_id=64341=507139
"



Invoking `lives -debug` from terminal results in the following:

"
LiVES 2.2.6
Copyright 2002-2014 Gabriel Finch (salsa...@gmail.com) and others.
LiVES comes with ABSOLUTELY NO WARRANTY
This is free software, and you are welcome to redistribute it
under certain conditions; see the file COPYING for details.

LiVES info: Invalid effect farneback_analyserfarneback_analysersalsaman1 found
in compound effect image_stabilizer, line 4

LiVES info: Invalid effect farneback_analyserfarneback_analysersalsaman1 found
in compound effect motion_analyser, line 4

**
Gtk:ERROR:/tmp/buildd/gtk+3.0-3.14.5/./gtk/gtkprogressbar.c:604:tick_cb:
assertion failed: (priv->pulse2 > priv->pulse1)

Unfortunately LiVES crashed.
Please report this bug at
http://sourceforge.net/tracker/?group_id=64341=507139
Thanks. Recovery should be possible if you restart LiVES.


When reporting crashes, please include details of your operating system,
distribution, and the LiVES version (2.2.6)
and any information shown below:

#0  0x7f36ada074c9 in __libc_waitpid (pid=26891, stat_loc=0x7fff7edb87cc,
#1  0x7f36b0657613 in g_on_error_stack_trace ()
#2  0x0041cdb8 in ?? ()
#3  
#4  0x7f36ad67d067 in __GI_raise (sig=sig@entry=6)
#5  0x7f36ad67e448 in __GI_abort () at abort.c:89
#6  0x7f36b06a7a45 in g_assertion_message ()
#7  0x7f36b06a7ada in g_assertion_message_expr ()
#8  0x7f36b21ff20e in ?? () from /usr/lib/x86_64-linux-gnu/libgtk-3.so.0
#9  0x7f36b22e9684 in ?? () from /usr/lib/x86_64-linux-gnu/libgtk-3.so.0
#10 0x7f36b0958474 in ?? ()
#11 0x7f36b0972087 in g_signal_emit_valist ()
#12 0x7f36b0972f2a in g_signal_emit_by_name ()
#13 0x7f36b1d2e79c in ?? () from /usr/lib/x86_64-linux-gnu/libgdk-3.so.0
#14 0x7f36b1d20e78 in ?? () from /usr/lib/x86_64-linux-gnu/libgdk-3.so.0
#15 0x7f36b0682613 in ?? () from /lib/x86_64-linux-gnu/libglib-2.0.so.0
#16 0x7f36b0681b6d in g_main_context_dispatch ()
#17 0x7f36b0681f48 in ?? () from /lib/x86_64-linux-gnu/libglib-2.0.so.0
#18 0x7f36b0681ffc in g_main_context_iteration ()
#19 0x00418259 in ?? ()
#20 0x004b45a4 in ?? ()
#21 0x00421be8 in ?? ()
#22 0x00422b6f in ?? ()
#23 0x7f36b0681b6d in g_main_context_dispatch ()
#24 0x7f36b0681f48 in ?? () from /lib/x86_64-linux-gnu/libglib-2.0.so.0
#25 0x7f36b0682272 in g_main_loop_run ()
#26 0x7f36b21abc25 in gtk_main ()
#27 0x00417361 in ?? ()
#28 0x7f36ad669b45 in __libc_start_main (main=0x416c70, argc=2,
#29 0x004180ca in ?? ()
"

I'll be happy to report this upstream (as instructed in the crash message) if
the maintainers desire, but won't do so unless instructed. Please let me know
if I can provide any further information.



-- 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.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages lives depends on:
ii  frei0r-plugins1.4-3
ii  imagemagick   8:6.8.9.9-5+deb8u1
ii  libasound21.0.28-1
ii  libatk1.0-0   2.14.0-1
ii  libavc1394-0  0.5.4-2
ii  libavutil54   6:11.6-1~deb8u1
ii  libc6 2.19-18+deb8u4
ii  libcairo-gobject2 1.14.0-2.1+deb8u1
ii  libcairo2 1.14.0-2.1+deb8u1
ii  libgdk-pixbuf2.0-02.31.1-2+deb8u4
ii  libglib2.0-0  2.42.1-1+b1
ii  libgtk-3-03.14.5-1+deb8u1
ii  libjack-jackd2-0 [libjack-0.116]  1.9.10+20140719git3eb0ae6a~dfsg-2
ii  libmjpegutils-2.1-0   1:2.1.0+debian-3
ii  liboil0.3 0.3.17-2
ii  libpango-1.0-01.36.8-3
ii  libpangocairo-1.0-0   1.36.8-3
ii  libpng12-0

Bug#822767: libgtk-3-0: firefox scrollbar unusable

[Jörg-Volker Peetz]

On Wed, 27 Apr 2016 11:47:58 +0200 =?UTF-8?Q?J=c3=b6rg-Volker_Peetz?=
 wrote:
> Package: libgtk-3-0
> Version: 3.20.3-1
> Severity: normal
>
> Dear Maintainer(s),
>
> this version changes the emacs24 (24.5+1-6) appearance. The icons in the
> menu bar vanish and in the scrollbar the up and down arrows
> ("-GtkScrollbar-has-backward-stepper") disappear.
>
> Are changes in gtk.css needed or additional packages?

On Wed, 27 Apr 2016 23:31:17 +0200 Michael Biebl  wrote:
> Am 27.04.2016 um 20:45 schrieb Jörg-Volker Peetz:
> > Package: libgtk-3-0
> > Version: 3.20.3-1
> > Severity: normal
> > 
> > Dear Maintainer(s),
> > 
> > also for the new firefox version in sid (46.0-1) the scrollbars are 
> > unusable.
> > Going back to version 3.18.9-1 of the libgtk-3 packages makes the scrollbars
> > work again.
> 
> That's something which needs to be fixed in Firefox
> 
> See https://bugzilla.mozilla.org/show_bug.cgi?id=1234158
> 

Then a bug report should also be filed for emacs24?

Regards,
jvp.

Bug#752876: Comments regarding r-cran-spdep_0.5-92-1_amd64.changes

[Andreas Tille]

Hi Roger,

just to leave your quick and helpful reply not unanswered:  I was hoping
for faster processing to be able to answer your question whether further
changes are needed.  For the moment I just say thanks for your kind
cooperation and I might (or hopefully might not) come back to you in
case of further issues.

Kind regards

   Andreas.

On Sat, Apr 09, 2016 at 04:29:50PM +0200, Andreas Tille wrote:
> Hi Thorsten,
> 
> would it be acceptable if I add this text to d/copyright?
> 
> Kind regards
> 
>   Andreas.
> 
> 
> On Mon, Apr 04, 2016 at 06:52:24PM +0200, Roger Bivand wrote:
> > Hi Andreas,
> > 
> > I have added:
> > 
> > /*
> > This code is described in "Computational Geometry in C" (Second Edition),
> > Chapter 8.  It is not written to be comprehensible without the
> > explanation in that book.
> > 
> > Prints out one arm configuration to reach given target.
> > Assumes number of links >= 3.
> > Input:
> >nlinks   Number of links
> >L1 L2 ... Ln Link lengths
> >x0 y0target0
> >x1 x2target1
> >...
> > 
> > Written by Joseph O'Rourke.
> > Last modified: December 1997
> > Questions to orou...@cs.smith.edu.
> > 
> > This code is Copyright 1998 by Joseph O'Rourke.  It may be freely
> > redistributed in its entirety provided that this copyright notice is
> > not removed.
> > 
> > */
> > 
> > to spdep/src/soigraph.c (committed to R-forge, will be released when the
> > next release occurs). This is the comment at the top of arm.c from:
> > 
> > http://cs.smith.edu/~orourke/CGCode/SecondEdition/Ccode2.tar.gz
> > 
> > which is the author's code distribution site, and is more relevant than the
> > printed text of the book. We've used the same approach in sp/src/pip.c for
> > over ten years without attracting Debian's ire.
> > 
> > Nicholas and I understood in 2001 that ... may be freely redistributed ...
> > could reasonably be taken as permission to include and redistribute these
> > small functions.
> > 
> > Do you want me to revisit the separate packaging of data sets?
> > 
> > Best wishes,
> > 
> > Roger
> > 
> > On Mon, 4 Apr 2016, Andreas Tille wrote:
> > 
> > >Hi Roger,
> > >
> > >I hope you remember the discussion we had two years ago when I tried to
> > >package spdep for Debian as a dependency to test some R epipdemiology
> > >tools.  I somehow gave up since the packages can be run with out spdep.
> > >However, we have now some bioinformatics tools that have a strong
> > >dependency and so we need to dive into this again.
> > >
> > >As you can read below the Debian ftpmaster has reviewed the source code
> > >of spdep and found a weak part in the licensing.  If you ask me this
> > >issue is also relevant for distributing spdep code on CRAN but nobody
> > >has stumbled upon this before.  It would be great if you could clarify
> > >the license of these pieces of code or replace it by some alternative
> > >free code.
> > >
> > >Kind regards and thanks for your support
> > >
> > > Andreas.
> > >
> > >On Sun, Apr 03, 2016 at 04:49:37PM +, Thorsten Alteholz wrote:
> > >>Hi Andreas,
> > >>
> > >>the issues about src/soigraph.c are not really solved.
> > >>
> > >>According to the file:
> > >>* The subroutines TwoCirclesxx and SubVec are adapted for R and Double
> > >>* precision coordinates by Nicholas Lewin-Koh, from Computational
> > >>* Geometry in C, Joseph O'Rourke, Cambridge University Press
> > >>* (1998), specifically from arm/arm.c. Copyright for those subroutines
> > >>*  remains his.
> > >>
> > >>As you can see, for example on Amazon, this book contains a paragraph:
> > >>
> > >>This book is in copyright. (...) no reproduction of any part may take
> > >>place without the written permission of Cambridge University Press.
> > >>
> > >>From my point of view this does not look like that "This code may be
> > >>freely redistributed" ...
> > >>
> > >>  Thorsten
> > >>
> > >>
> > >>
> > >>
> > >>--
> > >>debian-science-maintainers mailing list
> > >>debian-science-maintain...@lists.alioth.debian.org
> > >>http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/debian-science-maintainers
> > >>
> > >
> > >
> > 
> > -- 
> > 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
> > 
> 
> -- 
> http://fam-tille.de
> 
> -- 
> 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#809467: FTCBFS on non-linux: not found

[Christian Kastner]

Hi Helmut, Steven,

On 2016-01-02 04:22, Steven Chamberlain wrote:
> To clarify slightly, sys/capability.h *is* found, because a copy is
> bundled in libcap/sys/.  But it depends on arch-specific Linux headers.
> 
> Helmut Grohne wrote:
>> Steven, can you confirm that libcap2 can be crossed after applying this
>> patch?
> 
> I just checked this patch on kfreebsd-amd64, it works perfectly!
> libcap/_makenames still gives the right output.  Thanks.

I have prepared a tentative package based on the new upstream release
v2.25 in which I included Helmut's patch.

While the overall diff to v2.24 is relatively small, upstream did
shuffle around headers a bit. However, it is my understanding that this
should only affect the target environment, not the build environment for
which Helmut's patch is intended.

Steven, can you confirm that this new version [1] can also be cross-built?

[1] http://www.kvr.at/debian/pool/main/libc/libcap2/libcap2_2.25-1.dsc

Regards,
Christian




signature.asc
Description: OpenPGP digital signature

Bug#765175: systemd init script integration: status action should use --lines=0

[Martin Pitt]

Michael Biebl [2016-04-28 23:14 +0200]:
> I was under the impression that the systemctl command detects if you are
> running it from a terminal or not and disables the pager in the latter case.

It does, but if the calling command runs in a terminal itself (like
"vagrant up") that doesn't help.

Martin
-- 
Martin Pitt| http://www.piware.de
Ubuntu Developer (www.ubuntu.com)  | Debian Developer  (www.debian.org)


signature.asc
Description: PGP signature

Bug#740503: Still broken in 8.0.4

[Steve McIntyre]

On Thu, Apr 28, 2016 at 11:23:37PM +0200, Jan Heitkötter wrote:
>Dear Maintainer,

Hi Jan,

>I'm currently running an installation from 8.0.4-amd64 CD and can
>confirm that this bug still exists. I had to apply the workaround
>described above to make installation work.

You say 8.0.4; I assume you actually meant 8.4.0?

>BTW, information in Debian Wiki  is
>outdated. The text talks about tarballs, but
> only
>holds .deb files.

I'm looking at 

  http://cdimage.debian.org/cdimage/unofficial/non-free/firmware/jessie/current/

and it definitely holds a tarball (along with a zip file and a cpio
archive). Are you not seeing that?

-- 
Steve McIntyre, Cambridge, UK.st...@einval.com
"We're the technical experts.  We were hired so that management could
 ignore our recommendations and tell us how to do our jobs."  -- Mike Andrews

Bug#822915: jwm: There is no confirm attribute in program tag

[darthcat]

Package: jwm
Version: 2.1.0+svn579-2
Severity: normal

Dear Maintainer,

as we can see in the manual page of jwm, there is no confirm attribute in the
program tag of the configuration file of jwm. Could you please remove the two
confirm="false" from the supported...endsupported block of the file
/etc/menu-methods/jwm?
This bug affects also wheezy.

Best regards.
Darthcat.

-- 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=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages jwm depends on:
ii  gnome-terminal [x-terminal-emulator]  3.14.1-1+deb8u1
ii  libc6 2.19-18+deb8u4
ii  libfribidi0   0.19.6-3
ii  libpng12-01.2.50-2+deb8u2
ii  libx11-6  2:1.6.2-3
ii  libxext6  2:1.3.3-1
ii  libxft2   2.3.2-1
ii  libxinerama1  2:1.1.3-1+b1
ii  libxpm4   1:3.5.11-1+b1
ii  libxrender1   1:0.9.8-1+b1
ii  sakura [x-terminal-emulator]  3.1.5-1
ii  xfce4-terminal [x-terminal-emulator]  0.6.3-1+b1
ii  xterm [x-terminal-emulator]   312-2

jwm recommends no packages.

Versions of packages jwm suggests:
ii  menu  2.1.47
ii  x11-apps  7.7+4

-- no debconf information

Bug#821791: [Letsencrypt-devel] Bug#821791: acme-tiny: Source package includes modified source in .orig.tar.gz

[Jeremías Casteglione]

On Sat, 23 Apr 2016 14:03:38 +0200
Tomaž Šolc  wrote:

> Another solution would be to state in the copyright file that the
> package upstream is your repo, not diafygi's.
> 
> As it is right now, there is no mention of
> "https://github.com/jrmsgit/acme-tiny; anywhere in the package.

Right, good point...

I'll work on the quilt patches surely, soon I hope.

Cheers,


-- 
Jeremías


pgp1YV4ug47A1.pgp
Description: OpenPGP digital signature

Bug#822914: dpkg: Please add support for new architecture "riscv64" (RISC-V 64 bits little-endian)

[Manuel A. Fernandez Montecelo]

Package: dpkg
Version: 1.18.4
Severity: wishlist
Tags: patch
Control: user debian-ri...@lists.debian.org
Control: usertag -1 + riscv64

Hi!

What ${subject} says.  Patch attached with the line that needs to be added to
cputable.

I think that it's all what's needed, if not please tell me what else is missing.


Cheers.
--
Manuel
diff -Nru dpkg-1.18.4/cputable dpkg-1.18.4+nmu1/cputable
--- dpkg-1.18.4/cputable	2015-12-25 03:53:50.0 +
+++ dpkg-1.18.4+nmu1/cputable	2016-04-28 21:08:36.0 +
@@ -35,6 +35,7 @@
 powerpcel	powerpcle	powerpcle		32	little
 ppc64		powerpc64	(powerpc|ppc)64		64	big
 ppc64el		powerpc64le	powerpc64le		64	little
+riscv64		riscv64		riscv64			64	little
 s390		s390		s390			32	big
 s390x		s390x		s390x			64	big
 sh3		sh3		sh3			32	little
diff -Nru dpkg-1.18.4/debian/changelog dpkg-1.18.4+nmu1/debian/changelog
--- dpkg-1.18.4/debian/changelog	2015-12-25 12:47:31.0 +
+++ dpkg-1.18.4+nmu1/debian/changelog	2016-04-28 21:15:57.0 +
@@ -1,3 +1,10 @@
+dpkg (1.18.4+nmu1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Add support for riscv64 (RISC-V 64 bits little-endian). Closes: #-1
+
+ -- Manuel A. Fernandez Montecelo   Thu, 28 Apr 2016 21:08:47 +
+
 dpkg (1.18.4) unstable; urgency=medium
 
   [ Guillem Jover ]

Bug#765175: systemd init script integration: status action should use --lines=0

[Gerben Meijer]

On 28/04/16 23:14, Michael Biebl wrote:

Do we? If I run /etc/init.d/foo status on a terminal having a pager
might be useful.
I was under the impression that the systemctl command detects if you are
running it from a terminal or not and disables the pager in the latter case.


It may be useful, but sysv initscripts are never expected to invoke a 
pager. If user wants to see paged status, 'systemctl status foo' is 
adequate. What's worse, it can't be skipped - passing arguments after 
'/etc/init.d/foo status' isn't supported by the lsb init-functions 
wrapper; only when invoking systemctl directly can this be done.


As far as detection on a terminal goes, if I run some program or script 
that does a sysv style '/etc/init.d/foo status' as part of a service 
check (re Vagrant in my report) it will block - and in this case it 
blocks 5 times, once for each /etc/init.d/foo status call. There is no 
way around this other than to hack the source.


IMHO it's a matter of reasonable defaults; for 'systemctl status foo' a 
pager is expected, for '/etc/init.d/foo status' historically it is not 
and I feel this should be honored for compatibility reasons.

Bug#740503: Still broken in 8.0.4

[Jan Heitkötter]

Dear Maintainer,

I'm currently running an installation from 8.0.4-amd64 CD and can
confirm that this bug still exists. I had to apply the workaround
described above to make installation work.

BTW, information in Debian Wiki  is
outdated. The text talks about tarballs, but
 only
holds .deb files.

Now watching 8.0.4 install on my venerable X61s...

Cheers

Jan

Bug#822910: mutt-patched: silently dropped the sidebar-dotpathsep patch in favor of sidebar-dotted

[Gian Piero Carrubba]

* [Thu, Apr 28, 2016 at 10:32:17PM +0200] Gian Piero Carrubba:

I personally prefer the sidebar-dotpathsep patch because:

- has a summary listing # of unread/flagged/total messages instead of only
 unread/total


Please disregard this, it seems I cannot see a number if it's just a few 
pixel away from where I suppose it should be.


Ciao,
Gian Piero.

Bug#765175: systemd init script integration: status action should use --lines=0

[Michael Biebl]

Am 28.04.2016 um 22:56 schrieb Martin Pitt:
> It's also the wrong fix -- it might be argued that we don't want/need
> journal output for this case for some corner-case performance reasons,
> but for the most part this is pretty useful. What we really want (for
> this bug report anyway) is to disable the pager. 

Do we? If I run /etc/init.d/foo status on a terminal having a pager
might be useful.

I was under the impression that the systemctl command detects if you are
running it from a terminal or not and disables the pager in the latter case.



-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?



signature.asc
Description: OpenPGP digital signature

Bug#822912: Please disable Gnome-VFS support

[Michael Biebl]

Source: inkscape
Version: 0.91-8
Severity: normal
Tags: patch

Hi,

Gnome-VFS is is no longer maintained upstream and not really used
anymore in a modern GNOME(-based) desktop

Please consider disabling Gnome-VFS support.

I made a test-build with Gnome-VFS disabled and didn't notice any
functionality regression.

I'm running GNOME 3.20, where gvfs, the successor is installed.
In the file picker I could open files from remote mounts without
problems.

So to me it seems like it should be safe to disable Gnome-VFS (and
eventually depend on gvfs instead).

I have to add that inkscape is the last application on my desktop which
pulls in libgnome-vfs and its dependencies.
It would be nice to get rid of them.

Regards,
Michael


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

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

-- no debconf information
diff -Nru inkscape-0.91/debian/changelog inkscape-0.91/debian/changelog
--- inkscape-0.91/debian/changelog	2016-04-28 03:28:30.0 +0200
+++ inkscape-0.91/debian/changelog	2016-04-27 00:09:38.0 +0200
@@ -1,10 +1,3 @@
-inkscape (0.91-8.1) UNRELEASED; urgency=medium
-
-  * Non-maintainer upload.
-  * Disable Gnome-VFS.
-
- -- Michael Biebl   Thu, 28 Apr 2016 03:28:21 +0200
-
 inkscape (0.91-8) unstable; urgency=medium
 
   * debian/control:
diff -Nru inkscape-0.91/debian/control inkscape-0.91/debian/control
--- inkscape-0.91/debian/control	2016-04-28 03:28:44.0 +0200
+++ inkscape-0.91/debian/control	2016-04-26 23:56:33.0 +0200
@@ -19,6 +19,7 @@
  libcdr-dev,
  libgc-dev (>= 1:6.8),
  libglib2.0-dev,
+ libgnomevfs2-dev,
  libgsl-dev,
  libgtk2.0-dev (>= 2.10.0),
  libgtkmm-2.4-dev,
@@ -56,6 +57,7 @@
 Recommends:
  aspell,
  imagemagick,
+ libgnomevfs2-extra,
  libimage-magick-perl,
  libwmf-bin,
  python-lxml,
diff -Nru inkscape-0.91/debian/rules inkscape-0.91/debian/rules
--- inkscape-0.91/debian/rules	2016-04-28 03:28:20.0 +0200
+++ inkscape-0.91/debian/rules	2016-02-21 12:46:11.0 +0100
@@ -11,5 +11,5 @@
 override_dh_auto_configure:
 	dh_auto_configure \
 		--buildsystem=autoconf -- \
-		--without-gnome-vfs \
+		--with-gnome-vfs \
 		--enable-lcms

Bug#822913: libopenmpi1.10: add Breaks+Replaces: libopenmpi1

[Andreas Beckmann]

Package: libopenmpi1.10
Version: 1.10.2-12
Severity: important
User: debian...@lists.debian.org
Usertags: piuparts

Hi,

during a test with piuparts I noticed your package fails to upgrade from
'lenny' via squeeze, wheezy and jessie to stretch.
It installed fine in 'lenny', and upgraded to 'squeeze', 'wheezy', and
'jessie' successfully,
but then the upgrade to 'stretch' failed because it tries to overwrite
other packages files without declaring a Breaks+Replaces relation.

See policy 7.6 at
https://www.debian.org/doc/debian-policy/ch-relationships.html#s-replaces

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

  Selecting previously unselected package libopenmpi1.10.
  Preparing to unpack .../libopenmpi1.10_1.10.2-12_amd64.deb ...
  Unpacking libopenmpi1.10 (1.10.2-12) ...
  dpkg: error processing archive 
/var/cache/apt/archives/libopenmpi1.10_1.10.2-12_amd64.deb (--unpack):
   trying to overwrite '/usr/lib/openmpi/lib/mpi.mod', which is also in package 
libopenmpi1 1.2.7~rc2-2


cheers,

Andreas


libpetsc2.3.3_None.log.gz
Description: application/gzip

Bug#765175: systemd init script integration: status action should use --lines=0

[Martin Pitt]

Control: retitle -1 systemd init script integration: status action should 
disable pager
Control: severity -1 important
Control: tag -1 pending

Hello Gerben,

Gerben Meijer [2016-04-28 21:12 +0200]:
> For example, on a 'vagrant up' with a Vagrantfile using an nfs
> synced_folder, vagrant will invoke '/etc/init.d/nfs-kernel-server status'
> for each VM it is bringing up that has such a config. Systemctl then invokes
> a pager for every VM, effectively halting the process until the user exits
> the pager. It isn't even clear that a pager is invoked.

Indeed, that's a nuisance.
 
> So please raise the priority on this as it seems only logical to have
> traditional init scripts not invoke a pager when passing the 'status'
> argument; using --lines=0 is a viable solution and likely better than
> --no-pager.

I disagree. --lines=0 still invokes a pager if the init.d script has a
lot of non-journal information. E. g. "/etc/init.d/networking status"
still opens a pager with --lines=0.

It's also the wrong fix -- it might be argued that we don't want/need
journal output for this case for some corner-case performance reasons,
but for the most part this is pretty useful. What we really want (for
this bug report anyway) is to disable the pager. So I committed

  http://anonscm.debian.org/cgit/pkg-systemd/systemd.git/commit/?id=e30830

now.

Thanks,

Martin

-- 
Martin Pitt| http://www.piware.de
Ubuntu Developer (www.ubuntu.com)  | Debian Developer  (www.debian.org)


signature.asc
Description: PGP signature

Bug#822911: Please raise the priority of ruby2.3 to optional

[Jean-Michel Vourgère]

Package: libruby2.3
Version: 2.3.1-1
Severity: normal

There no longer is an "optional" ruby version, probably because of removal of
ruby2.2.
ruby2.3 is priority extra.

As a result, ruby packages can no longer be priority optional, since no
alternative version is optional. (policy 2.5)

Please raise the priority of ruby2.3 from extra to optionnal.

Bug#822910: mutt-patched: silently dropped the sidebar-dotpathsep patch in favor of sidebar-dotted

[Gian Piero Carrubba]

Package: mutt-patched
Version: 1.6.0-1
Severity: normal

Dear Maintainers,

thank you for your work on mutt.

Mutt 1.6.0-1 is using the sidebar-dotted patch that was abandoned in
1.5.22-2 in favor of Gentoo's sidebar-dotpathsep.

I personally prefer the sidebar-dotpathsep patch because:

- has a summary listing # of unread/flagged/total messages instead of only
  unread/total
- has configurable mailboxes separator (in my case, the newly reintroduced
  patch does not correctly display maildirs containing a dot in the name)

Anyway, if even the reintroduction of the old patch was intentional, please
document it in the NEWS.Debian file, noting that 'sidebar_delim_chars' is
not valid anymore and 'sidebar_shortpath' can be used instead (sort of).

Thank you,
Gian Piero.

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

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

Versions of packages mutt-patched depends on:
ii  libassuan02.4.2-3
ii  libc6 2.22-7
ii  libcomerr21.43~WIP.2016.03.15-2
ii  libgnutls30   3.4.11-4
ii  libgpg-error0 1.22-1
ii  libgpgme111.6.0-3
ii  libgssapi-krb5-2  1.13.2+dfsg-5
ii  libidn11  1.32-3
ii  libk5crypto3  1.13.2+dfsg-5
ii  libkrb5-3 1.13.2+dfsg-5
ii  libncursesw5  6.0+20160319-1
ii  libsasl2-22.1.26.dfsg1-15
ii  libtinfo5 6.0+20160319-1
ii  libtokyocabinet9  1.4.48-10
ii  mutt  1.6.0-1

mutt-patched recommends no packages.

mutt-patched suggests no packages.

-- no debconf information

Bug#816861: fuser does not show the PID that keeps busy a schroot mount-point

[Franco Martelli]

For sake of clarity this is a schroot command issue related bug report,
all works fine with chroot ordinary command.
As you suggest I try the -M switch, once started schroot's session:
$ kubuntu

then open a new console and run these commands:
~# killall cupsd
~# service cups start

then come back to schroot's console and logout:
~$ logout
E: 10mount: rmdir: failed to remove
'/var/lib/schroot/mount/kubuntu-e1c05063-2aca-491c-b5e4-4a4e1c41c65c':
Device or resource busy
E: kubuntu-e1c05063-2aca-491c-b5e4-4a4e1c41c65c: Chroot setup failed:
stage=setup-stop
$ fuser -M
/var/lib/schroot/mount/kubuntu-e1c05063-2aca-491c-b5e4-4a4e1c41c65c
Specified filename
/var/lib/schroot/mount/kubuntu-e1c05063-2aca-491c-b5e4-4a4e1c41c65c is
not a mountpoint.

fuser now tell me that it wasn't a mount point but it was indeed,
although actually not mounted anymore:
$ mount | grep
/var/lib/schroot/mount/kubuntu-e1c05063-2aca-491c-b5e4-4a4e1c41c65c
$

attempting to manually remove the directory it fails
# LC_ALL=C rmdir
/var/lib/schroot/mount/kubuntu-e1c05063-2aca-491c-b5e4-4a4e1c41c65c
rmdir: failed to remove
'/var/lib/schroot/mount/kubuntu-e1c05063-2aca-491c-b5e4-4a4e1c41c65c':
Device or resource busy

knowing that cupsd keeps busy the directory:
# killall cupsd

now removing the directory succeed:
# LC_ALL=C rmdir
/var/lib/schroot/mount/kubuntu-e1c05063-2aca-491c-b5e4-4a4e1c41c65c
#

A more interesting scenario, start a schroot session:
$ kubuntu

then open a new console and run these commands:
~# killall cupsd
~# service cups start

search for mount-point grepping the device name:
# mount | grep /dev/mapper/ld0-lv2
/dev/mapper/ld0-lv2 on
/var/lib/schroot/mount/kubuntu-76da7862-ef1b-4b04-920b-459be3350e85 type
ext4 (rw,relatime,stripe=256,data=ordered)

asking fuser which processes keeps busy the mount-point:
# fuser /var/lib/schroot/mount/kubuntu-76da7862-ef1b-4b04-920b-459be3350e85/
/var/lib/schroot/mount/kubuntu-76da7862-ef1b-4b04-920b-459be3350e85:  5681r
# fuser -m
/var/lib/schroot/mount/kubuntu-76da7862-ef1b-4b04-920b-459be3350e85/
/var/lib/schroot/mount/kubuntu-76da7862-ef1b-4b04-920b-459be3350e85:
5681rce
# fuser -M
/var/lib/schroot/mount/kubuntu-76da7862-ef1b-4b04-920b-459be3350e85/
/var/lib/schroot/mount/kubuntu-76da7862-ef1b-4b04-920b-459be3350e85:  5681r
# systemctl status cups
● cups.service - CUPS Printing Service
   Loaded: loaded (/lib/systemd/system/cups.service; enabled)
   Active: active (running) since gio 2016-04-28 21:59:50 CEST; 38s ago
 Docs: man:cupsd(8)
   man:cupsd.conf(5)
 Main PID: 5723 (cupsd)
   CGroup: /system.slice/cups.service
   └─5723 /usr/sbin/cupsd -f

fuser never report cupsd's PID(5723) the 5681 PID number reported refers
to bash:
# pstree -cpan | grep -B2 -A1 5681
  |   |-bash,1148 --rcfile ~/.bashrc_develop -i
  |   |   `-schroot,5608 -c kubuntu --
  |   |   `-bash,5681
  |   `-bash,1152 --rcfile ~/.bashrc_develop -i

HTH best regards

On 25/04/2016 at 04:26, Craig Small wrote:
> The problem is that fuser works off device numbers (it has to otherwise
> symlinks would confuse it) and there is nothing much that makes the
> chroots unique. A chroot is basically saying "start your tree here". My
> chroots for example sit under /var/chroot
> 
> Now, outside the chroot I can work out what process has that open with
> fuser /var/chroot/wheezy (note the lack of -m because these are not
> mount points).
> 
> Remember when you use the -m command you are saying the device ID where
> that file sits. It might be the actual mount point, or just a file (and
> fuser works out where that file sits).
> 
> If you really mean a mount point, then -M is a better idea.
> I don't really understand your setup because you have other mounts
> coming into your chroot. I think your tests are doing simple text
> matching which causes a bunch of failed misses but need to be sure.
> 
> /proc//mountinfo isn't the fix, because just like /proc//fd it
> can be fooled by symlinks.
> 
>  - Craig
> -- 
> Craig Small (@smallsees)   http://enc.com.au/   csmall at :
> enc.com.au 
> Debian GNU/Linux   http://www.debian.org/   csmall at :
> debian.org 
> GPG fingerprint:5D2F B320 B825 D939 04D2  0519 3938 F96B DF50 FEA5

-- 
Franco Martelli

Bug#822463: perl: perlbug reports get rejected by exim4 due to long lines in 'perl -V'

[Niko Tyni]

Control: forwarded -1 https://rt.perl.org/Ticket/Display.html?id=128020

On Thu, Apr 28, 2016 at 08:17:09PM +0100, Dominic Hargreaves wrote:
> On Thu, Apr 28, 2016 at 07:05:40PM +0300, Niko Tyni wrote:
> > On Tue, Apr 26, 2016 at 09:55:38PM +0300, Niko Tyni wrote:
> > 
> > > A better fix would be be to wrap everything, but I don't have a good patch
> > > for that. Hacking build_complete_message() could work I guess, but it's
> > > not used by all the sending backends (at least _send_message_mailsend();
> > > not sure we need to care about that.)
> > > 
> > > I think I need to look at this a bit more.
> > 
> > Revised set of two patches attached. Eyeballs would be welcome.
> 
> This looks sane to me. Thanks for taking the time to refactor!

Thank you for the review. I had to make one more modification to avoid
Text::Wrap eating empty lines from the body. Attached is the version I
sent upstream in [perl #128020].
-- 
Niko
>From 64986731cebb7768237489e00a15f93be660751f Mon Sep 17 00:00:00 2001
From: Niko Tyni 
Date: Thu, 28 Apr 2016 18:50:17 +0300
Subject: [PATCH 1/2] perlbug: Refactor duplicated file reading code

_send_message_mailsend() needs to build the message itself rather than
calling build_complete_message() like the other backends, but they can
still share the file reading code, and so can the 'display report' part.
---
 utils/perlbug.PL | 25 +
 1 file changed, 13 insertions(+), 12 deletions(-)

diff --git a/utils/perlbug.PL b/utils/perlbug.PL
index 885785a..6d6c780 100644
--- a/utils/perlbug.PL
+++ b/utils/perlbug.PL
@@ -834,10 +834,7 @@ EOF
 if ( SaveMessage() ) { exit }
 	} elsif ($action =~ /^(d|l|sh)/i ) { # isplay, ist, ow
 		# Display the message
-		open(REP, '<:raw', $filename) or die "Couldn't open file '$filename': $!\n";
-		binmode(REP, ':raw :crlf') if $Is_MSWin32;
-		while () { print $_ }
-		close(REP) or die "Error closing report file '$filename': $!";
+		print _read_report($filename);
 		if ($have_attachment) {
 		print "\n\n---\nAttachment(s):\n";
 		for my $att (split /\s*,\s*/, $attachments) { print "$att\n"; }
@@ -1080,13 +1077,20 @@ ATTACHMENT
 return $attach;
 }
 
+sub _read_report {
+my $fname = shift;
+my $content;
+open( REP, "<:raw", $fname ) or die "Couldn't open file '$fname': $!\n";
+binmode(REP, ':raw :crlf') if $Is_MSWin32;
+while () { $content .= $_; }
+close(REP) or die "Error closing report file '$fname': $!";
+return $content;
+}
+
 sub build_complete_message {
 my $content = _build_header(%{_message_headers()}) . "\n\n";
 $content .= _add_body_start() if $have_attachment;
-open( REP, "<:raw", $filename ) or die "Couldn't open file '$filename': $!\n";
-binmode(REP, ':raw :crlf') if $Is_MSWin32;
-while () { $content .= $_; }
-close(REP) or die "Error closing report file '$filename': $!";
+$content .= _read_report($filename);
 $content .= _add_attachments() if $have_attachment;
 return $content;
 }
@@ -1137,10 +1141,7 @@ sub _send_message_mailsend {
 $fh = $msg->open;
 binmode($fh, ':raw');
 print $fh _add_body_start() if $have_attachment;
-open(REP, "<:raw", $filename) or die "Couldn't open '$filename': $!\n";
-binmode(REP, ':raw :crlf') if $Is_MSWin32;
-while () { print $fh $_ }
-close(REP) or die "Error closing $filename: $!";
+print $fh _read_report($filename);
 print $fh _add_attachments() if $have_attachment;
 $fh->close or die "Error sending mail: $!";
 
-- 
2.8.0.rc3

>From 4bfb47f4d3a237934e9abe181e04c405c928067c Mon Sep 17 00:00:00 2001
From: Niko Tyni 
Date: Mon, 25 Apr 2016 16:31:00 +0300
Subject: [PATCH 2/2] Make perlbug wrap overly long lines

Mail transport agents limit the length of message lines at SMTP time.
One observed limit is 1000 characters per line. Mail user agents typically
work around these limits by MIME-encoding the message. Since perlbug
doesn't do that, it needs to limit the length of its lines manually to
make sure bug reports get delivered.

The longest lines in perlbug reports normally come from Config::myconfig
output, particularly 'config_args', which has been observed to exceed
1000 characters on some configurations, causing report rejection. While
less likely, the list of local patches is another potential source of
overly long lines.

Use Text::Wrap (if available) to wrap the body of the report at an
arbitrarily chosen and hopefully safe limit of 900 characters. No
indentation or continuation line markers are added, though it would
be easy to add those if desired. Attachments and mail headers are not
wrapped.

Bug-Debian: https://bugs.debian.org/822463
---
 utils/perlbug.PL | 13 -
 1 file changed, 12 insertions(+), 1 deletion(-)

diff --git a/utils/perlbug.PL b/utils/perlbug.PL
index 6d6c780..6bc5bad 100644
--- a/utils/perlbug.PL
+++ b/utils/perlbug.PL
@@ -76,6 +76,8 @@ BEGIN {
 $::HaveTemp = ($@ eq "");
 eval { 

Bug#822909: Please remove Suggests: on php5-adodb

[Jean-Michel Vourgère]

Package: acidbase
Version: 1.4.5-4
Severity: wishlist

Hello

php5-adodb package has been removed from the archive. Only the un-optimized
libphp-adodb remains.
Please drop the suggests on php5-adodb.

Bug#822908: snmpd: #1327 improvements to HOST-RESOURCES-MIB::hrSWInstalled on debian systems

[Elan Ruusamae]

Package: snmpd
Version: 5.7.2.1+dfsg-1
Severity: wishlist

Dear Maintainer,

I've written patch to net-snmp to fix hrSWInstalled date on debian
systems. seems debian8 has swInstalled compiled in, but the install date
was incomplete. this patch adds it

i'd like to see this in debian8 updates, thank you

https://sourceforge.net/p/net-snmp/patches/1327/

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

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

Versions of packages snmpd depends on:
ii  adduser3.113+nmu3
ii  debconf [debconf-2.0]  1.5.56
ii  libc6  2.19-18+deb8u1
ii  libsnmp-base   5.7.2.1+dfsg-1
ii  libsnmp30  5.7.2.1+dfsg-1
ii  lsb-base   4.1+Debian13+nmu1

snmpd recommends no packages.

Versions of packages snmpd suggests:
pn  snmptrapd  

-- Configuration Files:
/etc/default/snmpd changed [not included]
/etc/snmp/snmpd.conf changed [not included]

-- debconf information excluded

Bug#822907: openstack-dashboard: fails to upgrade from 'jessie': ValueError: Unable to configure handler 'null': Cannot resolve 'django.utils.log.NullHandler': No module named NullHandler

[Andreas Beckmann]

Package: openstack-dashboard
Version: 2:9.0.0-2
Severity: serious
User: debian...@lists.debian.org
Usertags: piuparts

Hi,

during a test with piuparts I noticed your package fails to upgrade from
'jessie'.
It installed fine in 'jessie', then the upgrade to 'stretch' fails.

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

  Setting up openstack-dashboard (2:9.0.0-2) ...
  WARNING:root:"dashboards" and "default_dashboard" in (local_)settings is 
DEPRECATED now and may be unsupported in some future release. The preferred way 
to specify the order of dashboards and the default dashboard is the pluggable 
dashboard mechanism (in 
/usr/share/openstack-dashboard/openstack_dashboard/enabled, 
/usr/share/openstack-dashboard/openstack_dashboard/local/enabled).
  Traceback (most recent call last):
File "/usr/share/openstack-dashboard/manage.py", line 25, in 
  execute_from_command_line(sys.argv)
File "/usr/lib/python2.7/dist-packages/django/core/management/__init__.py", 
line 353, in execute_from_command_line
  utility.execute()
File "/usr/lib/python2.7/dist-packages/django/core/management/__init__.py", 
line 327, in execute
  django.setup()
File "/usr/lib/python2.7/dist-packages/django/__init__.py", line 17, in 
setup
  configure_logging(settings.LOGGING_CONFIG, settings.LOGGING)
File "/usr/lib/python2.7/dist-packages/django/utils/log.py", line 71, in 
configure_logging
  logging_config_func(logging_settings)
File "/usr/lib/python2.7/logging/config.py", line 794, in dictConfig
  dictConfigClass(config).configure()
File "/usr/lib/python2.7/logging/config.py", line 576, in configure
  '%r: %s' % (name, e))
  ValueError: Unable to configure handler 'null': Cannot resolve 
'django.utils.log.NullHandler': No module named NullHandler
  dpkg: error processing package openstack-dashboard (--configure):
   subprocess installed post-installation script returned error exit status 1


cheers,

Andreas


openstack-dashboard_2:9.0.0-2.log.gz
Description: application/gzip

Bug#822906: ITP: tryton-modules-product-classification-taxonomic -- Product Classification Taxonomic Module for the Tryton Application Platform

[Mathias Behrle]

X-Debbugs-CC: debian-de...@lists.debian.org
Package: wnpp
Severity: wishlist
Owner: Debian Tryton Maintainers 

* Package name: tryton-modules-product-classification-taxonomic
  Version : 4.0.0
  Upstream Author : Tryton project (www.tryton.org)
* URL : http://downloads.tryton.org/4.0/
* License : GPL-3+
  Programming Lang: Python
  Description : Tryton Application Platform (Product Classification 
Taxonomic Module)
  Tryton is a high-level general purpose application platform.
  It is the base of a complete business solution as well as a comprehensive
  health and hospital information system (GNUHealth).
  .
  This module adds the taxonomic classification to products.
  .
  The available classifications are:
  .  
  Taxon
  A taxon (http://en.wikipedia.org/wiki/Taxon) is defined by a name and a
  taxonomic rank (http://en.wikipedia.org/wiki/Taxonomic_rank). It is stored
  inside a tree structure.
  .
  Cultivar
  A cultivar (http://en.wikipedia.org/wiki/Cultivar) is defined by a name,
  a taxon and a list of cultivar groups
  (http://en.wikipedia.org/wiki/Cultivar_group).



This package is another base module published by the Tryton project.



pgp7McbalU1Hj.pgp
Description: Digitale Signatur von OpenPGP

Bug#822901: ITP: tryton-modules-sale-stock-quantity -- Sale Stock Quantity Module for the Tryton Application Platform

[Mathias Behrle]

X-Debbugs-CC: debian-de...@lists.debian.org
Package: wnpp
Severity: wishlist
Owner: Debian Tryton Maintainers 

* Package name: tryton-modules-sale-stock-quantity
  Version : 4.0.0
  Upstream Author : Tryton project (www.tryton.org)
* URL : http://downloads.tryton.org/4.0/
* License : GPL-3+
  Programming Lang: Python
  Description : Tryton Application Platform (Sale Stock Quantity Module)
 Tryton is a high-level general purpose application platform. It is the base
 of a complete business solution as well as a comprehensive health and hospital
 information system (GNUHealth).
 .
 This module provides a check of the stock quantity of the products when
 quoting a sale. The check will warn the user if the forecast quantity at
 the sale date (and later dates until next supply) is lower than the quantity
 sold by taking into account other sales and the stock forecasts.



This package is another base module published by the Tryton project.


pgp8yARdFc96z.pgp
Description: Digitale Signatur von OpenPGP

Bug#822902: ITP: tryton-modules-purchase-request -- Purchase Request Module for the Tryton Application Platform

[Mathias Behrle]

X-Debbugs-CC: debian-de...@lists.debian.org
Package: wnpp
Severity: wishlist
Owner: Debian Tryton Maintainers 

* Package name: tryton-modules-purchase-request
  Version : 4.0.0
  Upstream Author : Tryton project (www.tryton.org)
* URL : http://downloads.tryton.org/4.0/
* License : GPL-3+
  Programming Lang: Python
  Description : Tryton Application Platform (Purchase Request Module)
 Tryton is a high-level general purpose application platform. It is the base
 of a complete business solution as well as a comprehensive health and hospital
 information system (GNUHealth).
 .
 This module introduces the basic concept of purchase requests serving as the
 central point for requests generated by other processes.



This package is another base module published by the Tryton project. It
contains the refactored code formerly included in the stock_supply module.


pgpWJ9ERY6XZ7.pgp
Description: Digitale Signatur von OpenPGP

Bug#822905: ITP: tryton-modules-webdav -- WebDAV Module for the Tryton Application Platform

[Mathias Behrle]

X-Debbugs-CC: debian-de...@lists.debian.org
Package: wnpp
Severity: wishlist
Owner: Debian Tryton Maintainers 

* Package name: tryton-modules-webdav
  Version : 4.0.0
  Upstream Author : Tryton project (www.tryton.org)
* URL : http://downloads.tryton.org/4.0/
* License : GPL-3+
  Programming Lang: Python
  Description : Tryton Application Platform (WebDAV Module)
 Tryton is a high-level general purpose application platform. It is the base
 of a complete business solution as well as a comprehensive health and hospital
 information system (GNUHealth).
 .
 The WebDAV module provides a WebDAV network interface with a separate
 server process.


This package is another base module published by the Tryton project. It
contains the former (in the main server included) WebDAV module.



pgpvXJaj7V3se.pgp
Description: Digitale Signatur von OpenPGP

Bug#822903: ITP: tryton-modules-production-work -- Production Work Module for the Tryton Application Platform

[Mathias Behrle]

X-Debbugs-CC: debian-de...@lists.debian.org
Package: wnpp
Severity: wishlist
Owner: Debian Tryton Maintainers 

* Package name: tryton-modules-production-work
  Version : 4.0.0
  Upstream Author : Tryton project (www.tryton.org)
* URL : http://downloads.tryton.org/4.0/
* License : GPL-3+
  Programming Lang: Python
  Description : Tryton Application Platform (Production Work Module)
 Tryton is a high-level general purpose application platform. It is the base
 of a complete business solution as well as a comprehensive health and hospital
 information system (GNUHealth).
 .
 This module allows one to manage work orders for productions. It also adds
 the work costs to the production cost.



This package is another base module published by the Tryton project.


pgpAB6zpLw2g6.pgp
Description: Digitale Signatur von OpenPGP

Bug#822904: ITP: tryton-modules-product-classification -- Product Classification Module for the Tryton Application Platform

[Mathias Behrle]

X-Debbugs-CC: debian-de...@lists.debian.org
Package: wnpp
Severity: wishlist
Owner: Debian Tryton Maintainers 

* Package name: tryton-modules-product-classification
  Version : 4.0.0
  Upstream Author : Tryton project (www.tryton.org)
* URL : http://downloads.tryton.org/4.0/
* License : GPL-3+
  Programming Lang: Python
  Description : Tryton Application Platform (Product Classification Module)
 Tryton is a high-level general purpose application platform. It is the base
 of a complete business solution as well as a comprehensive health and hospital
 information system (GNUHealth).
 .
 This module defines the base for other modules to create classifications of
 products.


This package is another base module published by the Tryton project.



pgparLXqStSsf.pgp
Description: Digitale Signatur von OpenPGP

Bug#822900: ITP: tryton-modules-production-routing -- Production Routing Module for the Tryton Application Platform

[Mathias Behrle]

X-Debbugs-CC: debian-de...@lists.debian.org
Package: wnpp
Severity: wishlist
Owner: Debian Tryton Maintainers 

* Package name: tryton-modules-production-routing
  Version : 4.0.0
  Upstream Author : Tryton project (www.tryton.org)
* URL : http://downloads.tryton.org/4.0/
* License : GPL-3+
  Programming Lang: Python
  Description : Tryton Application Platform (Production Routing Module)
 Tryton is a high-level general purpose application platform. It is the base
 of a complete business solution as well as a comprehensive health and hospital
 information system (GNUHealth).
 .
 This module defines the routings for productions:
 - Routing, Step and Operation.





This package is another base module published by the Tryton project. 


pgpSx8BNJvBQT.pgp
Description: Digitale Signatur von OpenPGP

Bug#822899: Should not recommend php-net-url2

[Mathieu Parent]

Package: php-net-url
Version: 1.0.15-4
Severity: important

Hello,

Currently this package pulls php-net-url2 (as install-recommends is on by
default).

  The Recommends field should list packages that would be found together with
  this one in all but unusual installations. 

https://www.debian.org/doc/debian-policy/ch-relationships.html#s-binarydeps

Please drop this dependency (no dependency exists in Debian to advice a
migration, unless it is compatible).

Regards

Mathieu Parent

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

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

Bug#822898: [INTL:da] Danish translation of the template refcard

[Joe Dalton]

Package: refcard
Severity: wishlist
Tags: l10n patch

Please include the attached Danish refcard translation

joe@pc:~/over/debianp/refcard$ msgfmt --statistics -c -v -o /dev/null da.po
da.po: 192 oversatte tekster.

bye
Joe

da.po.tar.gz
Description: application/gzip

Bug#822868: System with AMD A6-7400K Radeon R5 with display errors (Pepper Flash, VLC Video)

[Julien Cristau]

On Thu, Apr 28, 2016 at 16:56:07 +0200, Patrick Frank wrote:

> Package: xserver-xorg-video-radeon
> Version: 1:7.5.0-1
> Severity: normal
> 
You're not actually using that driver...

> DRM Information from dmesg:
> ---
> [0.00] AGP: No AGP bridge found
> [0.00] AGP: Checking aperture...
> [0.00] AGP: No AGP bridge found
> [0.00] AGP: Node 0: aperture [bus addr 0x-0x01ff] (32MB)
> [0.00] AGP: Your BIOS doesn't leave a aperture memory hole
> [0.00] AGP: Please enable the IOMMU option in the BIOS setup
> [0.00] AGP: This costs you 64MB of RAM
> [0.00] AGP: Mapping aperture over RAM [mem 0x9400-0x97ff]
> (65536KB)
> [0.928652] Linux agpgart interface v0.103
> [1.521077] ata1.00: supports DRM functions and may not be fully
> accessible
> [1.521895] ata1.00: supports DRM functions and may not be fully
> accessible
> [1.894511] [drm] Initialized drm 1.1.0 20060810
> [1.923576] [drm] radeon kernel modesetting enabled.
> [1.931630] [drm:radeon_pci_probe] *ERROR* radeon kernel modesetting for
> R600 or later requires firmware-linux-nonfree.
> 
... because it requires the firmware-linux-nonfree package for your
hardware.

Cheers,
Julien

Bug#822896: debci-worker: cronjob produces output after package removal

[Andreas Beckmann]

Package: debci-worker
Version: 1.1.2
Severity: important
User: debian...@lists.debian.org
Usertags: piuparts

Hi,

during a test with piuparts I noticed your packages cronjob produces
output and exist with an error after the package has been removed.

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

1m17.9s DEBUG: Starting command: ['chroot', '/tmp/piupartss/tmpWqTXH4', 
'/etc/cron.daily/debci-worker']
1m18.5s DUMP: 
  Starting testbed setup: Tue Apr 26 12:48:32 UTC 2016
1m18.5s ERROR: Command failed (status=1): ['chroot', 
'/tmp/piupartss/tmpWqTXH4', '/etc/cron.daily/debci-worker']


cheers,

Andreas


debci-worker_1.1.2.log.gz
Description: application/gzip

Bug#822897: ceilometer-collector: cronjob produces output after package removal

[Andreas Beckmann]

Package: ceilometer-collector
Version: 1:6.0.0-1
Severity: important
User: debian...@lists.debian.org
Usertags: piuparts

Hi,

during a test with piuparts I noticed your packages cronjob produces
output after the package has been removed.

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

3m11.3s DEBUG: Starting command: ['chroot', '/tmp/piupartss/tmpByKqOE', 
'/etc/cron.daily/ceilometer-collector']
3m12.6s DUMP: 
  Value 'password-ceilometer-legacy' for '[service_credentials]/auth_type' is 
deprecated. And will be removed in Ceilometer 7.0. Use 'password' instead.
  2016-04-24 13:49:49.489 1957 WARNING oslo_reports.guru_meditation_report [-] 
Guru mediation now registers SIGUSR1 and SIGUSR2 by default for backward 
compatibility. SIGUSR1 will no longer be registered in a future release, so 
please use SIGUSR2 to generate reports.
  2016-04-24 13:49:49.489 1957 INFO ceilometer.cmd.storage [-] Nothing to 
clean, database metering time to live is disabled
  2016-04-24 13:49:49.489 1957 INFO ceilometer.cmd.storage [-] Nothing to 
clean, database event time to live is disabled
3m12.6s DEBUG: Command ok: ['chroot', '/tmp/piupartss/tmpByKqOE', 
'/etc/cron.daily/ceilometer-collector']
3m12.6s ERROR: FAIL: Cron file /etc/cron.daily/ceilometer-collector has output 
with package removed


cheers,

Andreas


ceilometer-collector_1:6.0.0-1.log.gz
Description: application/gzip

Bug#822693: Feature Request: Automatically starting programs under firejail

[Reiner Herrmann]

Hi!

Thanks for your suggestion!

On Tue, Apr 26, 2016 at 06:54:07PM +0200, ban...@openmailbox.org wrote:
> At the moment there is no way to make all programs start with firejail
> automatically. Beginner users can't be expected to start a terminal every
> time they want to launch a program. This usability problem can be a hurdle
> for widespread adoption.

For better usability for beginners there is a graphical frontend called
'firetools' available.

> The suggestion in firejail documentation is to create a symlink between a
> binary's folder and firejail but unfortunately this solution is not
> maintainable on its own because package upgrades will overwrite the
> symlinks.

The upcoming upstream release of firejail (0.9.40) will also include
a helper tool called firecfg. This will create the symlinks for you
in /usr/local/bin (which comes by default before /usr/bin and /bin in PATH),
and are also not touched by package management.
I think this is a simple and usable way to let your programs start with
firejail.

Would this be also an acceptable solution for you?

Kind regards,
  Reiner


signature.asc
Description: Digital signature

Bug#822379: hidrd FTBFS on several platforms

[Fernando Seiti Furusato]

Source: hidrd
Followup-For: Bug #822379

Hi.
I could verify that, at least on ppc64el, it is related to optimization.
When forcing the compilation flag -O0, it does not fail to build.
I still have not figured out the cause of this though, but it is a
starting point just in case.

Regards.

Fernando

Bug#822895: RFS: singular/4.0.3-p1+ds-1 [NEW VERSION] - Computer Algebra System for Polynomial Computations

[Jerome Benoit]

Package: sponsorship-requests
Severity: normal

Dear Sponsors,

I am looking for sponsorship for the Debian package singular, a Computer
Algebra System (CAS) which is key part of Sage. This very pacakge brings
the latest release of singular to Debian.

Thanks in advance,
Jerome

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

Kernel: Linux 3.16.7-ckt20-0001-mbp62 (SMP w/4 CPU cores)
Locale: LANG=en_GB.utf8, LC_CTYPE=en_GB.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)

Bug#822891: Acknowledgement (spamassassin: Net::DNS query result in spamassassin's do_dns_query returns garbage with libnet-dns-perl-0.81-2)

[David Raison]

Due to a mail apparently not being as undeliverable as the mailserver
claimed, this is a duplicate of #822892. I would prefer the other one to
remain and this one to be closed since #822892 has more complete data.

Thanks and sorry for the duplicate.




signature.asc
Description: OpenPGP digital signature

Bug#765175: systemd init script integration: status action should use --lines=0

[Gerben Meijer]

I'd like to escalate this to a higher priority.

There are existing applications that expect init scripts to return a 
string or RC value. The current code in 
/lib/lsb/init-functions.d/40-systemd looks like this:


[ "$command" = status ] || log_daemon_msg "$s" "$service"
/bin/systemctl $sctl_args $command "$service"
rc=$?
[ "$command" = status ] || log_end_msg $rc

A problem arises whenever a script executes the status command, but 
systemctl then invokes a pager.


For example, on a 'vagrant up' with a Vagrantfile using an nfs 
synced_folder, vagrant will invoke '/etc/init.d/nfs-kernel-server 
status' for each VM it is bringing up that has such a config. Systemctl 
then invokes a pager for every VM, effectively halting the process until 
the user exits the pager. It isn't even clear that a pager is invoked.


So please raise the priority on this as it seems only logical to have 
traditional init scripts not invoke a pager when passing the 'status' 
argument; using --lines=0 is a viable solution and likely better than 
--no-pager.

Bug#822894: mariadb-10.0: [INTL:nl] Dutch translation of debconf messages

[Frans Spiesschaert]

 

Package: mariadb-10.0 
Severity: wishlist 
Tags: l10n patch 
 

Dear Maintainer, 
 
== 
Please find attached the updated Dutch translation of mariadb-10.0 debconf 
messages. 
It has been submitted for review to the debian-l10n-dutch mailing list. 
Please add it to your next package revision. 
It should be put as debian/po/nl.po in your package build tree. 
=== 

-- 
Cheers,
Frans

===
http://home.base.be/vt6362833/



nl.po.gz
Description: application/gzip


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

Bug#822881: Systemd related services fail during early boot

[Felipe Sateler]

On 28 Apr 2016 15:09, "Guido Günther"  wrote:
>
> Package: systemd
> Version: 229-4
> Severity: normal
>
> Hi,
> since updating to 229 a couple of weeks ago I'm seeing these during early 
> boot:
>
> Apr 28 19:48:21 bogon systemd[1]: systemd-hwdb-update.service: Start request 
> repeated too quickly.
> Apr 28 19:48:21 bogon systemd[1]: Failed to start Rebuild Hardware Database.
> Apr 28 19:48:21 bogon systemd[1]: systemd-fsck-root.service: Start request 
> repeated too quickly.
> Apr 28 19:48:21 bogon systemd[1]: Failed to start File System Check on Root 
> Device.
> Apr 28 19:48:21 bogon systemd[1]: sys-fs-fuse-connections.mount: Start 
> request repeated too quickly.
> Apr 28 19:48:21 bogon systemd[1]: Failed to mount FUSE Control File System.
> Apr 28 19:48:21 bogon systemd[1]: sys-kernel-config.mount: Start request 
> repeated too quickly.
> Apr 28 19:48:21 bogon systemd[1]: Failed to mount Configuration File System.
> Apr 28 19:48:21 bogon systemd[1]: systemd-binfmt.service: Start request 
> repeated too quickly.
> Apr 28 19:48:21 bogon systemd[1]: Failed to start Set Up Additional Binary 
> Formats.
> Apr 28 19:48:21 bogon systemd[1]: systemd-binfmt.service: Start request 
> repeated too quickly.
> Apr 28 19:48:21 bogon systemd[1]: Failed to start Set Up Additional Binary 
> Formats.
> Apr 28 19:48:21 bogon systemd[1]: systemd-hwdb-update.service: Start request 
> repeated too quickly.
> Apr 28 19:48:21 bogon systemd[1]: Failed to start Rebuild Hardware Database.
> Apr 28 19:48:21 bogon systemd[1]: systemd-fsck-root.service: Start request 
> repeated too quickly.
> Apr 28 19:48:21 bogon systemd[1]: Failed to start File System Check on Root 
> Device.
> Apr 28 19:48:21 bogon systemd[1]: sys-kernel-config.mount: Start request 
> repeated too quickly.
> Apr 28 19:48:21 bogon systemd[1]: Failed to mount Configuration File System.
> Apr 28 19:48:21 bogon systemd[1]: sys-fs-fuse-connections.mount: Start 
> request repeated too quickly.
> Apr 28 19:48:21 bogon systemd[1]: Failed to mount FUSE Control File System.
> Apr 28 19:48:21 bogon systemd[1]: var-lib-machines.mount: Start request 
> repeated too quickly.
> Apr 28 19:48:21 bogon systemd[1]: Failed to mount Virtual Machine and 
> Container Storage.
>
> which makes the boot look scary due to lots of failed units but the
> system boots ok otherwise

Could you please attach a full boot log, with debug output[1]? These
messages say they repeated too quickly, but ideally one would want to
know what is triggering them repeatedly.

[1] Adding systemd.log_level=debug to the kernel command line

-- 
Saludos

Bug#822463: perl: perlbug reports get rejected by exim4 due to long lines in 'perl -V'

[Dominic Hargreaves]

On Thu, Apr 28, 2016 at 07:05:40PM +0300, Niko Tyni wrote:
> On Tue, Apr 26, 2016 at 09:55:38PM +0300, Niko Tyni wrote:
> 
> > A better fix would be be to wrap everything, but I don't have a good patch
> > for that. Hacking build_complete_message() could work I guess, but it's
> > not used by all the sending backends (at least _send_message_mailsend();
> > not sure we need to care about that.)
> > 
> > I think I need to look at this a bit more.
> 
> Revised set of two patches attached. Eyeballs would be welcome.

This looks sane to me. Thanks for taking the time to refactor!

Cheers,
Dominic.

Bug#822893: mutt-patched: nntp no longer working

[Reiner Herrmann]

Package: mutt-patched
Version: 1.6.0-1

Dear maintainer,

I just noticed that NNTP is no longer working in mutt-patched.
In the debian/changelog it is mentioned that the patch was updated
for 1.6.0.

But I also just saw in git that it has been disabled, because it
doesn't build. :(
It would be awesome if you could get it running again! :)

Kind regards,
  Reiner

Bug#822892: spamassassin: Net::DNS query result in sa-update's do_dns_query() returns garbage with libnet-dns-perl-0.81-2

[David Raison]

Package: spamassassin
Version: 3.4.0-6
Severity: important

Dear Maintainer,

sa-update fails to detect rule updates due to do_dns_query() in the
sa-update script not returning a numeric value but a weird result that
does not match the /^(\d+)/ regex used when checking the value of $dnsV.

Executing sa-update with the following command line displays the value
that is being returned from $rr->rdatastr inside do_dns_query.

$ sa-update --gpghomedir /var/lib/spamassassin/sa-update-keys/ -vv
--debug
[…]
Apr 28 20:46:21.161 [4409] dbg: channel: metadata version = 1736402,
from file /var/lib/spamassassin/3.004000/updates_spamassassin_org.cf
DNS TXT query: 0.4.3.updates.spamassassin.org -> \# 8 0731373336343032

Currently, the expected output of the command should be 1736402 which is
also what one gets with a TXT query using dig.

Version 3.3.2 of spamassassin (on an oldstable installation) works fine,
but uses a different function named do_txt_query. However, the contents
of $rr->rdatastr in the 3.3.2 version are correct as well.


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

Kernel: Linux 3.16.0-4-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.113+nmu3
ii  init-system-helpers 1.22
pn  libarchive-tar-perl 
ii  libhtml-parser-perl 3.71-1+b3
ii  libnet-dns-perl 0.81-2
ii  libnetaddr-ip-perl  4.075+dfsg-1+b1
ii  libsocket6-perl 0.25-1+b1
ii  libsys-hostname-long-perl   1.4-3
ii  libwww-perl 6.08-1
ii  perl5.20.2-3+deb8u4
ii  perl-modules [libio-zlib-perl]  5.20.2-3+deb8u4

Versions of packages spamassassin recommends:
ii  gnupg  1.4.18-7+deb8u1
ii  libio-socket-inet6-perl2.72-1
ii  libmail-spf-perl   2.9.0-3
ii  perl [libsys-syslog-perl]  5.20.2-3+deb8u4
ii  sa-compile 3.4.0-6
ii  spamc  3.4.0-6

Versions of packages spamassassin suggests:
ii  libdbi-perl   1.631-3+b1
ii  libio-socket-ssl-perl 2.002-2+deb8u1
ii  libmail-dkim-perl 0.40-1
ii  perl [libcompress-zlib-perl]  5.20.2-3+deb8u4
ii  pyzor 1:0.5.0-2
ii  razor 1:2.85-4.1+b1

-- Configuration Files:
/etc/default/spamassassin changed:
ENABLED=0
OPTIONS="--create-prefs --max-children 5 --helper-home-dir"
PIDFILE="/var/run/spamd.pid"
CRON=1

/etc/spamassassin/local.cf changed:
trusted_networks 31.22.xxx.yyy
required_score 5.0
use_bayes 1
use_razor2 1
razor_timeout 15
use_pyzor 1
pyzor_timeout 15
ifplugin Mail::SpamAssassin::Plugin::Shortcircuit
shortcircuit USER_IN_BLACKLIST   on
shortcircuit SUBJECT_IN_BLACKLISTon
shortcircuit BAYES_99spam
shortcircuit BAYES_00ham
endif # Mail::SpamAssassin::Plugin::Shortcircuit


-- no debconf information



signature.asc
Description: OpenPGP digital signature

Bug#822676: [pkg-apparmor] Moving its AppArmor profiles to the Evince package

[Seth Arnold]

On Thu, Apr 28, 2016 at 11:34:58AM +0200, intrigeri wrote:
> Dear AppArmor team-mates: meaning to take care of the most pressing
> matter (co-installability) in the best way I could given my limited
> resources, I left alone one remaining problem detected by piuparts,
> i.e. aa-p-extra won't delete /etc/apparmor.d/local/usr.bin.evince when
> it's purged. Help is welcome :)

Is that a good idea? After all, the user may have put significant effort
into customizing the file for their site...

Thanks


signature.asc
Description: Digital signature

Bug#822891: spamassassin: Net::DNS query result in spamassassin's do_dns_query returns garbage with libnet-dns-perl-0.81-2

[David Raison]

Package: spamassassin
Version: 3.4.0-6
Severity: important

Dear Maintainer,

sa-update fails to detect rule updates due to do_dns_query() in the
sa-update script not returning a numeric value but a weird result that
does not match the /^(\d+)/ regex used when checking the value of $dnsV.

Executing sa-update with the following command line displays the values
that is being returned from $rr->rdatastr inside do_dns_query.

$ sa-update --gpghomedir /var/lib/spamassassin/sa-update-keys/ -vv
--debug
[…]
Apr 28 20:46:21.161 [4409] dbg: channel: metadata version = 1736402,
from file /var/lib/spamassassin/3.004000/updates_spamassassin_org.cf
DNS TXT query: 0.4.3.updates.spamassassin.org -> \# 8 0731373336343032

The expected output of the command should be 1736402

Version 3.3.2 of spamassassin (on an oldstable installation) works fine,
but uses a different function named do_txt_query. However, the contents
of $rr->rdatastr in the 3.3.2 version are fine as well.


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

Kernel: Linux 3.16.0-4-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.113+nmu3
ii  init-system-helpers 1.22
pn  libarchive-tar-perl 
ii  libhtml-parser-perl 3.71-1+b3
ii  libnet-dns-perl 0.81-2
ii  libnetaddr-ip-perl  4.075+dfsg-1+b1
ii  libsocket6-perl 0.25-1+b1
ii  libsys-hostname-long-perl   1.4-3
ii  libwww-perl 6.08-1
ii  perl5.20.2-3+deb8u4
ii  perl-modules [libio-zlib-perl]  5.20.2-3+deb8u4

Versions of packages spamassassin recommends:
ii  gnupg  1.4.18-7+deb8u1
ii  libio-socket-inet6-perl2.72-1
ii  libmail-spf-perl   2.9.0-3
ii  perl [libsys-syslog-perl]  5.20.2-3+deb8u4
ii  sa-compile 3.4.0-6
ii  spamc  3.4.0-6

Versions of packages spamassassin suggests:
ii  libdbi-perl   1.631-3+b1
ii  libio-socket-ssl-perl 2.002-2+deb8u1
ii  libmail-dkim-perl 0.40-1
ii  perl [libcompress-zlib-perl]  5.20.2-3+deb8u4
ii  pyzor 1:0.5.0-2
ii  razor 1:2.85-4.1+b1

-- Configuration Files:
/etc/default/spamassassin changed:
ENABLED=0
OPTIONS="--create-prefs --max-children 5 --helper-home-dir"
PIDFILE="/var/run/spamd.pid"
CRON=1

/etc/spamassassin/local.cf changed:
trusted_networks 31.22.124.145
required_score 5.0
use_bayes 1
use_razor2 1
razor_timeout 15
use_pyzor 1
pyzor_timeout 15
ifplugin Mail::SpamAssassin::Plugin::Shortcircuit
shortcircuit USER_IN_BLACKLIST   on
shortcircuit SUBJECT_IN_BLACKLISTon
shortcircuit BAYES_99spam
shortcircuit BAYES_00ham
endif # Mail::SpamAssassin::Plugin::Shortcircuit


-- no debconf information

Bug#795019: RM: insighttoolkit -- ROM; Obsoleted by insighttoolkit4

[Mattia Rizzolo]

control: tag -1 - moreinfo

On Wed, Aug 12, 2015 at 11:54:07AM -0400, Scott Kitterman wrote:
> Has rdepends that need updating.  Please remove the moreinfo tag once these 
> are updated.

I think we're finally able to remove it.

| Checking reverse dependencies...
| # Broken Depends:
| camitk: libcamitk3

This is just cruft, today was accepted a version with libcamtik4, it
only needs RM for some archs (#822871) + eventual decruft (there should
be no remaining rdeps)


| # Broken Build-Depends:
| fw4spl: libinsighttoolkit3-dev

this thing is curently binaryless, but currently WIP for a new version.
Please just break it.

-- 
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#767756: glibc: Consider providing a libc build compiled with -fno-omit-frame-pointer to help with profiling

[Andres Freund]

Hi,

On 2016-03-30 06:37:11 +, Alex Reece wrote:
> I would love to bump this bug; I think it would be wonderful to have an
> alternative version of libc with frame pointers.

Yea, I'm hitting this more and more often. Especially with the new eBPF
backed profiling tools like bcc, which, for the forseeable future, only
support frame pointer based unwinding. Also fp based unwinding is a lot
more efficient.


> What would it take for such an alternative to exist (can the Debian
> alternatives system work for libc)?

I was thinking of adding a libc6-frame-pointers which would replace (and
conflict with) libc6. But that's just because it was what I could think
of.

Maybe it'd be better to let those be co-installed by using a different
triplet and allow to chose which to use via /etc/ld.so.conf/something?
Not pretty either :(


> If other people want this, I'm interested in investing some time into
> helping with it.

Same here. I'd primarily like some guidance about what approach is more
likely to be accepted.


Greetings,

Andres Freund

Bug#810587: /usr/bin/run-mailcap: Re: mime-support: warnings about { depricated in regex

[nkiesel]

Package: mime-support
Version: 3.59
Followup-For: Bug #810587

Dear Maintainer,

any timeline for this?  I also just stumbled overthis problem.  I would
recommend to also quote the closing } in the regex, although that is currently
not strictly necessary.

For the record, I'm using the following patch:

--- /usr/bin/run-mailcap2015-08-02 15:57:49.0 -0700
+++ /home/nkiesel/bin/see   2016-04-28 11:23:06.370831388 -0700
@@ -525,7 +525,7 @@

 $comm =~ s!([^%])%t!$1$type!g;
 $comm =~ s!([^%])%F!$1!g;
-$comm =~ s!%{(.*?)}!$_="'$ENV{$1}'";s/\`//g;s/\'\'//g;$_!ge;
+$comm =~ s!%\{(.*?)\}!$_="'$ENV{$1}'";s/\`//g;s/\'\'//g;$_!ge;
 $comm =~ s!\\(.)!$1!g;
 $comm =~ s!\'\'!\'!g;
 $comm =~ s!$quotedsemi!;!go;


For the record, what the changed line does is to replace e.g. %{HOME} with the
value of environment variable HOME (after removing ` and '').



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

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

mime-support depends on no packages.

Versions of packages mime-support recommends:
ii  file  1:5.25-2

mime-support suggests no packages.

-- no debconf information

Bug#818781: r-base: non-standard gcc/g++ used for build (gcc-4.9)

[Mattia Rizzolo]

On Thu, Apr 28, 2016 at 01:34:28PM -0500, Dirk Eddelbuettel wrote:
> R 3.3.0 comes out on May 3. I may just throw in another pre-release into the
> mix.

It can just wait for May 3rd, no need to rush it before (unless the RC
bug annoys you so much, but I don't really think it should, as it would
not even avoid testing migration!)

-- 
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#818781: r-base: non-standard gcc/g++ used for build (gcc-4.9)

[Dirk Eddelbuettel]

On 28 April 2016 at 18:23, Mattia Rizzolo wrote:
| control: reopen -1
| 
| On Wed, Apr 06, 2016 at 12:16:49PM -0500, Dirk Eddelbuettel wrote:
| > Will do. In fact, I just updated it in my sources.
| 
| Apparently, this is still not enough, as the mips build r-base-core has
| a Depends on gcc-4.9.
| 
| Dunno why, but it has to go away :)

Indeed -- and my apologies.  Last iteration had cleaned up Build-Depends but
not the (manual) Depends. Done now.

R 3.3.0 comes out on May 3. I may just throw in another pre-release into the
mix.

Dirk

-- 
http://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org

Bug#822889: aptitude: [INTL:nl] Dutch po file for the aptitude package

[Frans Spiesschaert]

 

Package: aptitude 
Severity: wishlist 
Tags: l10n patch 
 

Dear Maintainer, 
 
== 
Please find attached the updated Dutch po file for the aptitude package. 
It has been submitted for review to the debian-l10n-dutch mailing list. 
Please add it to your next package revision. 
It should be put as "po/nl.po" in your package build tree. 
=== 
 

-- 
Cheers,
Frans

===
http://home.base.be/vt6362833/



nl.po.gz
Description: application/gzip


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

Bug#822887: nova: [INTL:nl] Dutch translation of debconf messages

[Frans Spiesschaert]

 

Package: nova 
Severity: wishlist 
Tags: l10n patch 
 

Dear Maintainer, 
 
== 
Please find attached the updated Dutch translation of nova debconf messages. 
It has been submitted for review to the debian-l10n-dutch mailing list. 
Please add it to your next package revision. 
It should be put as debian/po/nl.po in your package build tree. 
=== 

-- 
Groetjes,
Frans



nl.po.gz
Description: application/gzip


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

Bug#818781: r-base: non-standard gcc/g++ used for build (gcc-4.9)

[Mattia Rizzolo]

control: reopen -1

On Wed, Apr 06, 2016 at 12:16:49PM -0500, Dirk Eddelbuettel wrote:
> Will do. In fact, I just updated it in my sources.

Apparently, this is still not enough, as the mips build r-base-core has
a Depends on gcc-4.9.

Dunno why, but it has to go away :)

-- 
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#822886: postfix: [INTL:nl] Dutch translation of debconf messages

[Frans Spiesschaert]

 

Package: postfix 
Severity: wishlist 
Tags: l10n patch 
 

Dear Maintainer, 
 
== 
Please find attached the updated Dutch translation of postfix debconf messages. 
It has been submitted for review to the debian-l10n-dutch mailing list. 
Please add it to your next package revision. 
It should be put as debian/po/nl.po in your package build tree. 
=== 

-- 
Groetjes,
Frans



nl.po.gz
Description: application/gzip


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

Bug#822888: glance: [INTL:nl] Dutch translation of debconf messages

[Frans Spiesschaert]

 

Package: glance 
Severity: wishlist 
Tags: l10n patch 
 

Dear Maintainer, 
 
== 
Please find attached the updated Dutch translation of glance debconf messages. 
It has been submitted for review to the debian-l10n-dutch mailing list. 
Please add it to your next package revision. 
It should be put as debian/po/nl.po in your package build tree. 
=== 

-- 
Cheers,
Frans

===
http://home.base.be/vt6362833/



nl.po.gz
Description: application/gzip


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

Bug#822885: mistral: [INTL:nl] Dutch translation of debconf messages

[Frans Spiesschaert]

 

Package: mistral 
Severity: wishlist 
Tags: l10n patch 
 

Dear Maintainer, 
 
== 
Please find attached the updated Dutch translation of mistral debconf messages. 
It has been submitted for review to the debian-l10n-dutch mailing list. 
Please add it to your next package revision. 
It should be put as debian/po/nl.po in your package build tree. 
=== 

-- 
Groetjes,
Frans



nl.po.gz
Description: application/gzip


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

Bug#822884: barbican: [INTL:nl] Dutch translation of debconf messages

[Frans Spiesschaert]

 

Package: barbican 
Severity: wishlist 
Tags: l10n patch 
 

Dear Maintainer, 
 
== 
Please find attached the updated Dutch translation of barbican debconf 
messages. 
It has been submitted for review to the debian-l10n-dutch mailing list. 
Please add it to your next package revision. 
It should be put as debian/po/nl.po in your package build tree. 
=== 

-- 
Cheers,
Frans

===
http://home.base.be/vt6362833/



nl.po.gz
Description: application/gzip


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

Bug#822617: Missing symlinks to match locales

[Gunnar Hjalmarsson]

On 2016-04-28 15:28, Mattia Rizzolo wrote:
> Some days ago I finished the work to have it synced (src:hunspell-sv 
> needed RM for $reasons, and to do so src:ubuntu-keyboard and the
> seeds needed changes), and got it synced, so starting for yakkety the
> package is the same.

Saw that, great!

> On Thu, Apr 28, 2016 at 01:10:52AM +0200, Gunnar Hjalmarsson wrote:
>> I gave it another shot in the light of how LO recognizes locales,
>> and dropped a few symlinks including el_CY. Attached please find a
>> new, slightly reduced list of proposed symlinks
> 
> to me that list look mostly sane, but a bit pops in my mind: for 
> hunspell-kmr, shall we provide new virtual packages hunspell-ckb and
> hunspell-ku?

To be quite honest, I don't know how useful the proposed ckb_IQ and
ku_TR symlinks are. They do work in the sense that the kmr_Latn
dictionary is recognized by LO in case of a ckb_IQ or ku_TR locale, but
multiple Kurdish dialects exist, so doing some research before creating
such packages may be advisable.

On 2016-04-28 17:06, Agustin Martin wrote:
> myspell-es ships a bunch of symlinks for that purpose after request
> in a Debian bug report, but later found some bug reports in Ubuntu
> about just the opposite,
> 
> https://bugs.launchpad.net/ubuntu/+source/espa-nol/+bug/663032 
> https://bugs.launchpad.net/ubuntu/+source/espa-nol/+bug/793666 
> https://bugs.launchpad.net/ubuntu/+source/espa-nol/+bug/927256
> 
> myspell-es is the same for all countries, so I think that leaving
> symlinks there is by far the lesser evil, even if it adds some
> noise.

Yeah, I have also seen that kind of complaints in a few bug reports and
Ask Ubuntu questions. There are two possible approaches in my mind to
reduce the noise/pollution.

I just made a Spanish install of Ubuntu, stating New York as the time
zone location, and the installer added LANG="es_US.UTF-8" to
/etc/default/locale. Changing the installer behavior in this respect, so
it instead set LANG to "es_ES.UTF-8", while setting some formats related
LC_* variables to "es_US.UTF-8", would make it possible to get rid of
quite some polluting symlinks.

Another idea is that the source packages, e.g. libreoffice-dictionaries,
provide the symlinks in separate binary packages, so for Spanish we
would then have:

hunspell-es
hunspell-es-mx
hunspell-es-ar
hunspell-es-us
...

with the actual dictionary in hunspell-es and each of the other
hunspell-es-* packages only containing a symlink and a dependency on
hunspell-es.

But I suppose that those thoughts are more long term ones, and would
need careful consideration.

-- 
Gunnar Hjalmarsson
https://launchpad.net/~gunnarhj

Bug#822755: note that kcalc -h or kcal -v does not return (show expected messages but do not return).

[Lisandro Damián Nicanor Pérez Meyer]

On Thursday 28 April 2016 18:17:17 Eric Valette wrote:
> On 04/28/2016 05:58 PM, Lisandro Damián Nicanor Pérez Meyer wrote:
> > On Thursday 28 April 2016 08:45:05 Eric Valette wrote:
> >> note that kcalc -h or kcal -v does not return (show expected messages
> >> but do not return).
> > 
> > Just in case: I have received no attachments nor strace logs.
> 
> Look hard, its in the bug info already (message 20 attachement)

Mm, that mail didn't reach my inbox :-/ Sorry for the noise, but really 
involuntary.

I can't see anything strange in it's output :-/

Can you use debsums to check the relevant packages? Those would be kcalc 
itself and the dependencies listed by reportbug when you filed the bug.

So far I had no other report about this, so I can only think in a problem in 
your side, although if someone can reproduce it that would change, of course.

-- 
La mejor prueba de que la navegación en el tiempo no es posible, es el hecho
de no haber sido invadidos por masas de turistas provenientes del futuro.
  Stephen Hawking

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


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

Bug#822883: qemu-system-misc: typo in short description

[Uwe Kleine-König]

Package: qemu-system-misc
Version: 1:2.5+dfsg-5
Severity: minor

sed -i s/miscelaneous/miscellaneous/ debian/control

Best regards
Uwe

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

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

Bug#822882: RM: gst-plugins-base0.10 -- RoQA; obsolete

[Moritz Muehlenhoff]

Package: ftp.debian.org
Severity: normal

Hi,
please remove gst-plugins-base0.10 from the archive. It's
part of the gstreamer 0.10 and all reverse dependencies
have been removed.

Cheers,
Moritz

Bug#822881: Systemd related services fail during early boot

[Guido Günther]

Package: systemd
Version: 229-4
Severity: normal

Hi,
since updating to 229 a couple of weeks ago I'm seeing these during early boot:

Apr 28 19:48:21 bogon systemd[1]: systemd-hwdb-update.service: Start request 
repeated too quickly.
Apr 28 19:48:21 bogon systemd[1]: Failed to start Rebuild Hardware Database.
Apr 28 19:48:21 bogon systemd[1]: systemd-fsck-root.service: Start request 
repeated too quickly.
Apr 28 19:48:21 bogon systemd[1]: Failed to start File System Check on Root 
Device.
Apr 28 19:48:21 bogon systemd[1]: sys-fs-fuse-connections.mount: Start request 
repeated too quickly.
Apr 28 19:48:21 bogon systemd[1]: Failed to mount FUSE Control File System.
Apr 28 19:48:21 bogon systemd[1]: sys-kernel-config.mount: Start request 
repeated too quickly.
Apr 28 19:48:21 bogon systemd[1]: Failed to mount Configuration File System.
Apr 28 19:48:21 bogon systemd[1]: systemd-binfmt.service: Start request 
repeated too quickly.
Apr 28 19:48:21 bogon systemd[1]: Failed to start Set Up Additional Binary 
Formats.
Apr 28 19:48:21 bogon systemd[1]: systemd-binfmt.service: Start request 
repeated too quickly.
Apr 28 19:48:21 bogon systemd[1]: Failed to start Set Up Additional Binary 
Formats.
Apr 28 19:48:21 bogon systemd[1]: systemd-hwdb-update.service: Start request 
repeated too quickly.
Apr 28 19:48:21 bogon systemd[1]: Failed to start Rebuild Hardware Database.
Apr 28 19:48:21 bogon systemd[1]: systemd-fsck-root.service: Start request 
repeated too quickly.
Apr 28 19:48:21 bogon systemd[1]: Failed to start File System Check on Root 
Device.
Apr 28 19:48:21 bogon systemd[1]: sys-kernel-config.mount: Start request 
repeated too quickly.
Apr 28 19:48:21 bogon systemd[1]: Failed to mount Configuration File System.
Apr 28 19:48:21 bogon systemd[1]: sys-fs-fuse-connections.mount: Start request 
repeated too quickly.
Apr 28 19:48:21 bogon systemd[1]: Failed to mount FUSE Control File System.
Apr 28 19:48:21 bogon systemd[1]: var-lib-machines.mount: Start request 
repeated too quickly.
Apr 28 19:48:21 bogon systemd[1]: Failed to mount Virtual Machine and Container 
Storage.

which makes the boot look scary due to lots of failed units but the
system boots ok otherwise. Looking at the services individually I see
the error as well:

# systemctl status systemd-binfmt.service
● systemd-binfmt.service - Set Up Additional Binary Formats
   Loaded: loaded (/lib/systemd/system/systemd-binfmt.service; static; vendor 
preset: enabled)
   Active: inactive (dead)
Condition: start condition failed at Do 2016-04-28 19:48:21 CEST; 10min ago
   none of the trigger conditions were met
 Docs: man:systemd-binfmt.service(8)
   man:binfmt.d(5)
   https://www.kernel.org/doc/Documentation/binfmt_misc.txt

Apr 28 19:48:21 bogon systemd[1]: systemd-binfmt.service: Start request 
repeated too quickly.
Apr 28 19:48:21 bogon systemd[1]: Failed to start Set Up Additional Binary 
Formats.
Apr 28 19:48:21 bogon systemd[1]: systemd-binfmt.service: Start request 
repeated too quickly.
Apr 28 19:48:21 bogon systemd[1]: Failed to start Set Up Additional Binary 
Formats.

It would be great if the services would start up as expected.

systemd-delta has:

# systemd-delta 
[EXTENDED]   /lib/systemd/system/rc-local.service → 
/lib/systemd/system/rc-local.service.d/debian.conf
[EXTENDED]   /lib/systemd/system/systemd-timesyncd.service → 
/lib/systemd/system/systemd-timesyncd.service.d/disable-with-time-daemon.conf

Please let me know if you require any further information. I went
through the bugreports but couldn't find anything related but upstream
has this:

https://github.com/systemd/systemd/issues/2684

Cheers,
 -- Guido

-- Package-specific info:

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

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

Versions of packages systemd depends on:
ii  adduser 3.114
ii  libacl1 2.2.52-3
ii  libapparmor12.10-4
ii  libaudit1   1:2.4.5-1+b1
ii  libblkid1   2.27.1-6
ii  libc6   2.22-6
ii  libcap2 1:2.24-12
ii  libcap2-bin 1:2.24-12
ii  libcryptsetup4  2:1.7.0-2
ii  libgcrypt20 1.6.5-2
ii  libgpg-error0   1.21-2
ii  libkmod222-1.1
ii  liblzma55.1.1alpha+20120614-2.1
ii  libmount1   2.27.1-6
ii  libpam0g1.1.8-3.2
ii  libseccomp2 2.3.0-1
ii  libselinux1 2.4-3+b1
ii  libsystemd0 229-4
ii  mount   2.27.1-6
ii  util-linux  2.27.1-6

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

Versions of packages systemd suggests:
ii  systemd-container  229-4
pn  systemd-ui 

Versions of packages systemd is related to: