Bug#831536: gnome-keyring: Unencrypted login keyring remains "locked" after autologin

[Daniel Gnoutcheff]

Package: gnome-keyring
Version: 3.20.0-1
Severity: normal

I've enabled autologin on one of my workstations, and in a bid to get
gnome-keyring to play nice with it,  I've set an empty password on the
login keyring.  This worked nicely in wheezy.

Since at least jessie, however, the (unencrypted) login keyring remains
"locked" after autologin, and e.g. password autofill in Chromium doesn't
happen.  To fix this, I end up starting seahorse and asking it to unlock
the keyring, which of course it does immediately with no password
prompt.

This seems silly.  I would expect that an unencrypted keyring would
always be "unlocked", as far as client apps are concerned.

This has also been noted by Maciej Mensfeld on his blog, along with his
workaround:
  
http://dev.mensfeld.pl/2014/09/ubuntu-14-04-gnome-keyring-seahorse-auto-unlock-when-auto-login/



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

Kernel: Linux 4.6.0-1-amd64 (SMP w/2 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 gnome-keyring depends on:
ii  dbus-x11 1.10.8-1
ii  dconf-gsettings-backend [gsettings-backend]  0.26.0-1
ii  gcr  3.20.0-2
ii  libc62.23-1
ii  libcap-ng0   0.7.7-3
ii  libcap2-bin  1:2.25-1
ii  libgck-1-0   3.20.0-2
ii  libgcr-base-3-1  3.20.0-2
ii  libgcrypt20  1.7.1-2
ii  libglib2.0-0 2.48.1-1
ii  p11-kit  0.23.2-3
ii  pinentry-gnome3  0.9.7-5

Versions of packages gnome-keyring recommends:
ii  libpam-gnome-keyring  3.20.0-1

gnome-keyring suggests no packages.

-- no debconf information

Bug#830770: mdadm: initramfs broken

[Jamie Heilman]

Jamie Heilman wrote:
> I wouldn't be stunned if this problem mostly stemmed from the fact
> that /scripts/init-top/udev executes prior to loading kernel modules.
> It might be interesting to see what happens if we toss
>  udevadm trigger --action=add
>  udevadm settle || true
> into a script in /scripts/init-premount ... 

So, I tried that, it works; though I'm not entirely happy with the
solution, it seems rather brutish.  The init-premount/mdadm script I
used was:

#!/bin/sh

PREREQS="udev"

prereqs() { echo "$PREREQS"; }

case "$1" in
prereqs) prereqs; exit 0 ;;
esac

udevadm trigger --action=add -s block
udevadm settle || true

exit 0

What strikes me as annoying about this though, is that the only real
change between scripts/init-top/udev running and init-premount/mdadm
running, is the load_modules call.  I noticed that when I ran modprobe
md_mod manually, then ran udevadm trigger --action=add -s block, udev
would automatically assemble the array without further complaint, so I
figured if I just added:
TEST!="[module/md_mod]", RUN{builtin}+="kmod load md_mod"
after the md_inc label in 64-md-raid-assembly.rules that I might not
need the init-premount/mdadm script at all, and that the array would
be assembled automaticaly when init-top/udev ran.  So, I tried that
too, but it doesn't work for reasons that I haven't figured out yet,
maybe due to race conditions or something.

If udev can't be used to automatically construct the array, maybe
calling mdadm --assemble --scan in an init-premount script really is
the better appraoch.  Replying all the block device add events seems
like it could have unwanted side-effects.

Anyway, so there are workarounds, but what the Right Way to fix this
is, I'm not sure about.  Attached patch takes care of the
aforementioned case sensitivity regression.

-- 
Jamie Heilman http://audible.transient.net/~jamie/
--- hooks.mdadm	2016-07-16 07:55:56.057651332 +
+++ /usr/share/initramfs-tools/hooks/mdadm	2016-07-16 08:00:25.331825532 +
@@ -97,8 +97,8 @@
 else
 # make sure the configuration file knows about all running devices
 /sbin/mdadm --detail --scan | while read array device params; do
-uuid=${params#*UUID=}; uuid=${uuid%% *}
-if ! grep -q "UUID=$uuid" $DESTMDADMCONF; then
+uuid=`echo "$params" | grep -iom 1 ' uuid=[0-9a-f:]\+'`
+if ! grep -qi "$uuid" $DESTMDADMCONF; then
 warn "the array $device with UUID $uuid"
 warn "is currently active, but it is not listed in mdadm.conf. if"
 warn "it is needed for boot, then YOUR SYSTEM IS NOW UNBOOTABLE!"

Bug#831535: akregator: missing dependencies prevent akregator from fetching feeds

[Francois Marier]

Package: akregator
Version: 4:16.04.2-2
Severity: grave
Justification: renders package unusable

The last update to akregator broke feed fetching with the following error:

  could not start process cannot talk to klauncher the name org.kde.klauncher5 
was not provided by any .service files

This can be fixed by installing the "kinit" package, but then you run into
this error:

  could not start process unable to create io-slave klauncher said: unknown 
protocol 'file'

which I was only able to get working by installing the "kio" package and
then rebooting.

Therefore, I think akregator needs to depend on "kio" and "kinit".

Francois

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

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

Versions of packages akregator depends on:
ii  libc62.23-1
ii  libgcc1  1:6.1.1-9
ii  libkf5codecs55.23.0-1
ii  libkf5completion55.23.0-1
ii  libkf5configcore55.23.0-1
ii  libkf5configgui5 5.23.0-1
ii  libkf5configwidgets5 5.23.0-1
ii  libkf5coreaddons55.23.0-1
ii  libkf5grantleetheme-plugins  16.04.2-1
ii  libkf5grantleetheme5 16.04.2-1
ii  libkf5i18n5  5.23.0-1
ii  libkf5iconthemes55.23.0-1
ii  libkf5jobwidgets55.23.0-1
ii  libkf5kcmutils5  5.23.0-1
ii  libkf5kiocore5   5.23.0-1
ii  libkf5kiogui55.23.0-1
ii  libkf5kiowidgets55.23.0-1
ii  libkf5kontactinterface5  16.04.2-1
ii  libkf5libkdepim-plugins  4:16.04.2-3
ii  libkf5libkdepim5 4:16.04.2-3
ii  libkf5messageviewer5 4:16.04.3-1
ii  libkf5notifications5 5.23.0-1
ii  libkf5notifyconfig5  5.23.0-1
ii  libkf5parts5 5.23.0-1
ii  libkf5pimcommon-plugins  4:16.04.2-2
ii  libkf5pimcommon5 4:16.04.2-2
ii  libkf5pimtextedit5   16.04.2-1
ii  libkf5service-bin5.23.0-1
ii  libkf5service5   5.23.0-1
ii  libkf5syndication5   16.04.2-1
ii  libkf5textwidgets5   5.23.0-1
ii  libkf5webkit55.23.0-1
ii  libkf5widgetsaddons5 5.23.0-1
ii  libkf5xmlgui55.23.0-1
ii  libqt5core5a 5.6.1+dfsg-3
ii  libqt5dbus5  5.6.1+dfsg-3
ii  libqt5gui5   5.6.1+dfsg-3
ii  libqt5network5   5.6.1+dfsg-3
ii  libqt5printsupport5  5.6.1+dfsg-3
ii  libqt5webkit55.6.1+dfsg-4
ii  libqt5widgets5   5.6.1+dfsg-3
ii  libqt5xml5   5.6.1+dfsg-3
ii  libstdc++6   6.1.1-9

akregator recommends no packages.

akregator suggests no packages.

Bug#821967: bitlbee: diff for NMU version 3.4.2-1.1+nmu1

[Michael Lustfield]

X-NMUDIFF-Version: 2.15.3

Control: tags 821967 + patch
Control: tags 821967 + pending

Wilmer,

I've prepared an NMU for bitlbee (versioned as 3.4.2-1.1+nmu1) and
uploaded it to Debian Mentors. Per our discussion, I will request a sponsor
upload it unstable as quickly as possible.

Note, I have marked the urgency high because of the short timeline until this
package is auto-removed from testing.

diff -u bitlbee-3.4.2/debian/changelog bitlbee-3.4.2/debian/changelog
--- bitlbee-3.4.2/debian/changelog
+++ bitlbee-3.4.2/debian/changelog
@@ -1,3 +1,10 @@
+bitlbee (3.4.2-1.1+nmu1) unstable; urgency=high
+
+  * Non-maintainer upload.
+  * Adding build-{arch,indep} targets. (Closes: #821967)
+
+ -- Michael Lustfield   Sat, 16 Jul 2016 19:41:15 -0700
+
 bitlbee (3.4.2-1) unstable; urgency=medium
 
   [ Jelmer Vernooij ]
diff -u bitlbee-3.4.2/debian/rules bitlbee-3.4.2/debian/rules
--- bitlbee-3.4.2/debian/rules
+++ bitlbee-3.4.2/debian/rules
@@ -39,6 +39,10 @@
 
 CONFIGURE_OVERRIDES:=CPPFLAGS="$(CPPFLAGS)" CFLAGS="$(CFLAGS)"
LDFLAGS="$(LDFLAGS)" 
+# https://bugs.debian.org/821967
+build-indep: binary-indep
+build-arch: binary-arch
+
 build: build-stamp
 build-stamp:
dh_testdir

-- 
Michael Lustfield


pgpHvnyalgHEd.pgp
Description: OpenPGP digital signature

Bug#831534: terminix: FTBFS on 32-bit systems: type mismatch errors

[Aaron M. Ucko]

Source: terminix
Version: 1.0.0-1
Severity: serious
Justification: fails to build from source

The i386 build of terminix failed due to a number of complaints of type
mismatches (long vs. size_t and [u]long vs. [u]int).

  /usr/include/d/std/algorithm/mutation.d(1697): Error: template 
std.range.primitives.popFrontExactly cannot deduce function from argument types 
!()(bool delegate(ActionType)[], long), candidates are:
  /usr/include/d/std/range/primitives.d(1798):
std.range.primitives.popFrontExactly(Range)(ref Range r, size_t n) if 
(isInputRange!Range)
  [...]

I presume builds for other 32-bit architectures would fail the same
way if ldc didn't FTBFS itself there.  Could you please take a look?

Thanks!

Bug#812150: bluetooth unavailable after rfkill hard (or soft) unblocking

[Thomas Mayer]

In ubuntu 16.04, I experienced the same issue for hard blocking as well.
Plus, can I confirm the soft blocking issue for ubuntu 16.04 as well.

Full report at https://bugs.launchpad.net/systemd/+bug/1603715

Please take into account that Debian might have the hard blocking issue
as well. I cannot test this myself for the moment.



signature.asc
Description: OpenPGP digital signature

Bug#830977: Please add Python 3 support

[Timo Aaltonen]

On 13.07.2016 16:33, Thomas Goirand wrote:
> Package: python-qrcode
> Version: 5.0.1-1
> Severity: important
> Tags: patch
> 
> Hi,
> 
> I have pushed to collab-maint the Python 3 support for this package, plus
> a few refresh. Here's the changelog:
> 
>   * Non-maintainer upload.
>   * Added Python 3 support.
>   * Using debhelper >= 9.
>   * Standards-Version is now 3.9.8 (no change).
>   * debian/copyright in parseable format 1.0.
>   * Fixes URLs (using https everywhere).
>   * Using update-alternatives to provide /usr/bin/qr.
>   * rm debian/source/include-binaries.
> 
> If you don't like these changes, they can always be reverted (and I can do
> it for you), though I don't think any of them are controvertial.
> 
> Would you be ok that I NMU the current Git version then? I need it to be
> able to upload the latest version of python-autobahn that's using this package
> as well (and has Py3 support).
> 
> Please let me know ASAP,
> Cheers,
> 
> Thomas Goirand (zigo)

sorry, I didn't see this until now.. go ahead with the upload, thanks.

Bug#821114: (no subject)

[Michael Lustfield]

I feel like this probably is required to keep systemd handling the way nginx
reloads without troubles. I'll try to test the more simple solution under load.

-- 
Michael Lustfield

Bug#831533: icingaweb2: please ship log directory and logrotate script

[Christoph Anton Mitterer]

Source: icingaweb2
Severity: wishlist


Hey.

One way of logging in Icinga Web2 is into files (the other being into syslog).
So it would be nice, if the package could contain a:
/var/log/icingaweb2
which is automatically set to be owned by the icingaweb2 group (which in turn
allows rather easy integration with the various PHP SAPIs, by simply adding
whichever effective user the code actually runs as, to that group :) ).


It would further be nice, if a logrotate script for the default logfile
/var/log/icingaweb2/icingaweb2.log (this is what the webinterface suggests)
would be in place.
Ideally with the option "notifempty" so that users which don't choose to do
file based logging, get an empty rotated file :)
Of course "missingok" is also needed.

Admittedly I'm a bit uncertain as for how the rotation should work (lograte
has different modes):
At least with CGI SAPI, the logfile must of course always be reopened on
every request,… so one can simply move the logfile to be rotated and doesn't
have to create or truncate.
IIRC, the options should then be nocopy AND nocopytruncate (in order to override
any possible global defaults).
But I don't know how things work with the Apache Module SAPI of PHP.


Cheers,
Chris.

Bug#831531: icingacli shows only enabled modules

[Christoph Anton Mitterer]

Package: icingacli
Version: 2.3.4-1
Severity: normal


Hi.

When just calling icingacli it gives e.g.:
# icingacli 
USAGE: icingacli [module]  [action] [options]

Available commands:

  helpHelp for modules, commands and actions
  module  List and handle modules
  web 

Available modules:

  monitoring
  translation

Global options:

  --log [t]   Log to , either stderr, file or syslog (default: stderr)
  --log-path   Which file to log into in case of --log file
  --verbose   Be verbose
  --debug Show debug output
  --help  Show help
  --benchmark Show benchmark summary
  --watch [s] Refresh output every  seconds (default: 5)

Show help on a specific command : icingacli help 
Show help on a specific module  : icingacli help 


The Section "Available Modules" does however only list the enabled
modules, not all the ones available, e.g. it misses the doc
module here.


Cheers,
Chris.

Bug#831530: icingaweb2-module-monitoring: missing module configuration directory

[Christoph Anton Mitterer]

Package: icingaweb2-module-monitoring
Severity: normal


Hi.

When configuring the monitoring backend, then the Icinga Web 2 interface
apparently wants to write to /etc/icingaweb2/modules/monitoring/backends.ini
and possibly others in that path.

However, /etc/icingaweb2/modules/monitoring/ doesn't exist.

Please ship it with the package file and set proper permissions (i.e.
icingaweb2 as group owner that is allowed to write).


Cheers,
Chris.

Bug#831532: icingaweb2: handle auth DB with dbconfig-common

[Christoph Anton Mitterer]

Source: icingaweb2
Severity: wishlist


Hi.

Currently, icingaweb2 doesn't set up/manage the Icinga Web 2 specific DBs
at all, it even doesn't depend on php-mysql|php-pgsql...

This is of course great, as Icinga Web 2 doesn't stricly need and DB for
authentication, but can also use local files, LDAP, etc..

But it also seems, that even when auth/authz is done e.g. via webserver
authentication (HTTP Basic auth) and local INI files, one would need
a DB if one wanted to use groups.

So in the end it would be nice, if icingaweb2 would provide and *optional*
way to manage that DB (and perhaps even initially add an admin user if
the installing user wishes to do so), ideally with dbconfig-common.


My idea would be, that perhaps icingaweb2 Suggests a icingaweb2-db-auth
package (or perhaps using some better name).
This could then depend on dbconfig-common, contain the schema files and
depend on php-psql|php-mysql.
On installation, dbconfig would kick in and allow the user to take over
management and future schema upgrades.
Since icingaweb2-db-auth would be only Suggested, users could still opt-out
of the whole DB-for-Icinga-Web2 thingy.

And of course php-icinga would still continue to Recommend php-mysql|php-pgsql
which are of course e.g. still needed to connect to IDO.


Cheers,
Chris.

Bug#822792: (no subject)

[Michael Lustfield]

Using conf.d/* is a very common practice with web servers. Apache has this
exact same structure.

Because of the way inheritance works in nginx configuration files, things that
would typically work in apache do not work with Nginx. You're requesting we
change away from how web server packages typically handle configuration files
to something that suits the use of sub-directories for web applications.

I'm not against modifying the main nginx config file to support this, but I'm
against the proposed solution and not sure I see an obvious solution that seems
to be sensible.

-- 
Michael Lustfield

Bug#770408: fails to mount multi-device Btrfs from fstab (mount by label)

[Michael Biebl]

On Fri, 21 Nov 2014 13:31:21 +1100 Dmitry Smirnov 
wrote:
> Package: systemd
> Version: 215-5+b1
> Severity: normal
> 
> Switching to systemd with Wheezy to Jessie upgrade broke a particular
> Btrfs mount in fstab. Btrfs consists of three devices:
> 
>  $ sudo btrfs fi show
> Label: 'tmp_area'  uuid: aa5965b1-a602-4f71-8535-8601dfaae540
> Total devices 3 FS bytes used 528.00GiB
> devid4 size 601.00GiB used 517.03GiB path /dev/mapper/tmp@700
> devid6 size 834.00GiB used 547.03GiB path /dev/mapper/tmp@900
> devid7 size 834.00GiB used 30.00GiB path /dev/mapper/tmp@900hy
> 
> 
> Mounted from "/etc/fstab" as follows:
> 
>  /etc/fstab:
> #LABEL="tmp_area"/mnt/tmp  btrfs  
> _netdev,noatime,nodiratime,autodefrag00
> /dev/disk/by-label/tmp_area  /mnt/tmp  btrfs  
> _netdev,noatime,nodiratime,autodefrag00
> 
> 
> All underlying devices are successfully unlocked automatically
> as per "/etc/crypttab":
> 
>  /etc/crypttab:
> tmp@700UUID=eaa37bee-5df3-429c-b3e2-ee28f9fde282  /root/hddkey.txt  luks
> tmp@900UUID=e66b87a9-1090-4077-b476-a33e19e9a341  /root/hddkey.txt  luks
> tmp@900hy  UUID=379dd7f5-f04e-4f45-8856-7bff929a34ce  /root/hddkey.txt  luks
> 
> 
> On boot systemd waits for 1.5 min. then gives up and goes on so first thing
> I have to do when system boots is to run the following command as root:
> 
> mount -av
> 
> Which successfully mounts "/mnt/tmp".
> 
> I don't understand why systemd fails to notice appearance of
> "/dev/disk/by-label/tmp_area" long after all three block devices
> became available... As you can see I tried "_netdev" workaround
> to delay mount but it did not help...

Looks like a duplicate of #747629.
Could you check the output of udevadm info --query=all for the
underlying devices and see what ID_BTRFS_READY is set to.

Thanks


-- 
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#411194: apcupsd-doc: -doc package does not include documentation in any "compiled" form

[Christian Hofstaedtler]

Control: fixed -1 3.14.8-2

Starting in 3.14.8-2 the links in the HTML should have been working.

-- 
 ,''`.  Christian Hofstaedtler 
: :' :  Debian Developer
`. `'   7D1A CFFA D9E0 806C 9C4C  D392 5C13 D6DB 9305 2E03
  `-

Bug#831518: [pulseaudio]

[Marek Straka]

Package: pulseaudio
Version: 9.0-1.1

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

I had the same Problem. Installation of pulseaudio-module-udev package 
helped here.


--- System information. ---
Architecture: amd64
Kernel: Linux 4.6.0-1-amd64

Debian Release: stretch/sid
500 testing ftp.at.debian.org

--- Package information. ---
Depends (Version) | Installed
==-+-===
libasound2 (>= 1.0.24.1) |
libc6 (>= 2.15) |
libcap2 (>= 1:2.10) |
libdbus-1-3 (>= 1.9.14) |
libfftw3-single3 |
libgcc1 (>= 1:3.0) |
libice6 (>= 1:1.0.0) |
libltdl7 (>= 2.4.6) |
liborc-0.4-0 (>= 1:0.4.25) |
libpulse0 (= 9.0-1.1) |
libsm6 |
libsndfile1 (>= 1.0.20) |
libsoxr0 (>= 0.1.0) |
libspeexdsp1 (>= 1.2~beta3.2-1) |
libstdc++6 (>= 4.1.1) |
libsystemd0 |
libtdb1 (>= 1.2.7+git20101214) |
libudev1 (>= 183) |
libwebrtc-audio-processing1 |
libx11-6 |
libx11-xcb1 |
libxcb1 |
libxtst6 |
adduser |
lsb-base (>= 3.2-13) |
libasound2-plugins |
pulseaudio-utils |


Recommends (Version) | Installed
=-+-===
pulseaudio-module-x11 |
rtkit |
pulseaudio-module-udev | 9.0-1.1


Suggests (Version) | Installed
==-+-===
pavumeter |
pavucontrol | 3.0-3+b2
paman |
paprefs |

Bug#831529: gstreamer1.0-libav: segfault when trying to play h264 video

[Tim Dengel]

Package: gstreamer1.0-libav
Version: 1.8.2-1
Severity: important

Dear Maintainer,

applications that use gstreamer segfault when trying to play any h264 video. 
Other codecs work fine.

I assume this is due to a recent ffmpeg update, but ffmpeg itself (and other 
applications using libav) continue to work, so I think the problem is in 
gstreamer.

Here is a backtrace I got from gst-launch-1.0 -v playbin 
uri=file:///path/to/video.mp4

--SNIP

Thread 6 "multiqueue0:src" received signal SIGABRT, Aborted.
[Switching to Thread 0x7fffedf1e700 (LWP 26245)]
0x76fc01c8 in __GI_raise (sig=sig@entry=6) at 
../sysdeps/unix/sysv/linux/raise.c:54
54  ../sysdeps/unix/sysv/linux/raise.c: Datei oder Verzeichnis nicht 
gefunden.
(gdb) bt full
#0  0x76fc01c8 in __GI_raise (sig=sig@entry=6) at 
../sysdeps/unix/sysv/linux/raise.c:54
resultvar = 0
pid = 26237
selftid = 26245
#1  0x76fc164a in __GI_abort () at abort.c:89
save_stage = 2
act = 
  {__sigaction_handler = {sa_handler = 0x20, sa_sigaction = 0x20}, 
sa_mask = {__val = {140736585731512, 140736586987917, 142, 140736585750902, 
140736817862560, 8, 140736885465681, 140736817858928, 16237680842874452480, 
140736591042816, 140736817862560, 140736817863744, 16237680842874452480, 1136, 
140736590853200, 140736817862560}}, sa_flags = -670496400, sa_restorer = 
0x7fffd8090660}
sigs = {__val = {32, 0 }}
#2  0x7fffc9e78f5b in init_context_defaults (s=s@entry=0x7fffd80917a0, 
codec=codec@entry=0x7fffca841900 )
at src/libavcodec/options.c:142
ret = 
d = 0x7fffca813450 
flags = 
#3  0x7fffc9e79026 in avcodec_alloc_context3 (codec=0x7fffca841900 
) at src/libavcodec/options.c:163
avctx = 0x7fffd80917a0
#4  0x7fffdc380540 in gst_ffmpeg_cfg_install_property 
(klass=0x7fffd8090970, base=8) at gstavcfg.c:732
pspec = 
list = 
prop_id = 8
ctx = 
__func__ = "gst_ffmpeg_cfg_install_property"
#5  0x7fffdc376e53 in gst_ffmpegvidenc_class_init (klass=0x7fffd8090970) at 
gstavvidenc.c:225
gobject_class = 0x7fffd8090970
venc_class = 0x7fffd8090970
caps = 
#6  0x7788c22d in g_type_class_ref (pclass=0x7fffd8090660, 
node=0x7fffd8090380)
at /build/glib2.0-vjfO_h/glib2.0-2.48.1/./gobject/gtype.c:2241
slist = 
init_slist = 
i = 
class = 0x7fffd8090970
entries = 
entry = 
---Type  to continue, or q  to quit---
bnode = 
ptype = 
holds_ref = 
pclass = 
#7  0x7788c22d in g_type_class_ref (type=type@entry=140736817857408) at 
/build/glib2.0-vjfO_h/glib2.0-2.48.1/./gobject/gtype.c:2956
ptype = 
holds_ref = 
pclass = 
#8  0x77b09da4 in gst_element_register (plugin=plugin@entry=0x6df290 
[GstPlugin], name=name@entry=0x7fffd806cea0 "avenc_h264_vaapi", 
rank=rank@entry=128, type=type@entry=140736817857408) at gstelementfactory.c:243
existing_feature = 
registry = 0x61b950 [GstRegistry]
factory = 0x7fffe0022160 [GstElementFactory]
interfaces = 
n_interfaces = 32767
i = 
klass = 
item = 
__func__ = "gst_element_register"
__PRETTY_FUNCTION__ = "gst_element_register"
#9  0x7fffdc3775b3 in gst_ffmpegvidenc_register 
(plugin=plugin@entry=0x6df290 [GstPlugin]) at gstavvidenc.c:1009
type_name = 0x7fffd806cea0 "avenc_h264_vaapi"
typeinfo = 
  {class_size = 792, base_init = 0x7fffdc376ef0 
, base_finalize = 0x0, class_init = 0x7fffdc376c50 
, class_finalize = 0x0, class_data = 0x0, 
instance_size = 1944, n_preallocs = 0, instance_init = 0x7fffdc375540 
, value_table = 0x0}
type = 140736817857408
in_plugin = 0x7fffca841900 
__func__ = "gst_ffmpegvidenc_register"
#10 0x7fffdc369e20 in plugin_init (plugin=0x6df290 [GstPlugin]) at 
gstav.c:158
plugin = 0x6df290 [GstPlugin]
#11 0x77b2b537 in gst_plugin_register_func (plugin=0x6df290 
[GstPlugin], desc=0x7fffdc598180 , user_data=0x0)
at gstplugin.c:523
user_data = 0x0
desc = 0x7fffdc598180 
plugin = 0x6df290 [GstPlugin]
---Type  to continue, or q  to quit---
#12 0x77b2d425 in _priv_gst_plugin_load_file_for_registry 
(filename=0x6dec50 "/usr/lib/x86_64-linux-gnu/gstreamer-1.0/libgstlibav.so", 
registry=0x61b950 [GstRegistry], registry@entry=0x0, 
error=error@entry=0x7fffedf1d060) at gstplugin.c:826
desc = 
plugin = 0x6df290 [GstPlugin]
module = 
ret = 
ptr = 0x7fffdc598180 
file_status = 
{st_dev = 20, st_ino = 12284313, st_nlink = 1, st_mode = 33188, 
st_uid = 0, st_gid = 0, __pad0 = 0, st_rdev = 0, st_size = 241040, st_blksize = 
4096, st_blocks = 472, st_atim = {tv_sec = 1465819700, tv_nsec = 0}, st_mtim = 
{tv_sec = 1465462429, tv_nsec = 

Bug#830266: r-base-dev: r-cran.mk should check for xauth, not just xvfb-run

[Charles Plessy]

Hi Dirk and Aaron,

quick followup.

Le Sun, Jul 10, 2016 at 03:02:44PM +0900, Charles Plessy a écrit :
> 
> after reading the whole discussion, and looking at the history of the xvfb
> package, I opened , where I ask to change the
> Recommends relationship on xauth to a Depends.  That would prevent further
> build failures.

The xvfb maintainers refused to Depend on xauth.

> The failure happened on the hppa architecture, which is not a release
> architecture.  In addition, other hppa buildds are clean, and whithin a day,
> r-cran-rngtools was built successfully on "physik".  This also means that one
> can ask the hppa porters to clean the "bell" buildd (where the failure
> happened), since the presence of xvfb there does not seem to be necessary.

The hppa porters promptly removed xvfb from their buildd.

> If none of this works and failures pop up on release architectures, then
> I think that adding an ad-hoc test in r-cran.mk would be safe, although it
> is not the most satisfying solution.

As of now, we are sure that build will fail again of one installs xvfb without
xauth, but we also know that this happens very rarely.

Obviously, it is up to Dirk to add a test for xauth or just close the bug.

Have a nice Sunday,

-- 
Charles Plessy
Debian Med packaging team,
http://www.debian.org/devel/debian-med
Tsurumi, Kanagawa, Japan

Bug#831528: ntptime program gives warning when attempting to prelink

[Arthur Marsh]

Package: ntp
Version: 1:4.2.8p8+dfsg-1
Severity: normal

Dear Maintainer,

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

   * What led up to the situation?

Running prelink:
prelink: /usr/sbin/ntptime: R_386_32 relocs should not be present in 
prelinked REL sections

prelink version is 0.0.20130503-1.1+b1

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

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


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

Kernel: Linux 4.7.0-rc7+ (SMP w/1 CPU core; PREEMPT)
Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash
Init: sysvinit (via /sbin/init)

Versions of packages ntp depends on:
ii  adduser  3.115
ii  dpkg 1.18.9
ii  libc62.23-1
ii  libcap2  1:2.25-1
ii  libedit2 3.1-20150325-1+b1
ii  libopts251:5.18.7-3
ii  libssl1.0.2  1.0.2h-1
ii  lsb-base 9.20160629
ii  netbase  5.3

Versions of packages ntp recommends:
ii  perl  5.22.2-2

Versions of packages ntp suggests:
ii  ntp-doc  1:4.2.8p8+dfsg-1

-- Configuration Files:
/etc/init.d/ntp changed:
PATH=/sbin:/bin:/usr/sbin:/usr/bin
. /lib/lsb/init-functions
DAEMON=/usr/sbin/ntpd
PIDFILE=/var/run/ntpd.pid
test -x $DAEMON || exit 5
if [ -r /etc/default/ntp ]; then
. /etc/default/ntp
fi
if [ -e /var/lib/ntp/ntp.conf.dhcp ]; then
NTPD_OPTS="$NTPD_OPTS -c /var/lib/ntp/ntp.conf.dhcp"
fi
LOCKFILE=/run/lock/ntpdate
RUNASUSER=ntp
UGID=$(getent passwd $RUNASUSER | cut -f 3,4 -d:) || true
if test "$(uname -s)" = "Linux"; then
NTPD_OPTS="$NTPD_OPTS -u $UGID"
fi
case $1 in
start)
log_daemon_msg "Starting NTP server" "ntpd"
if [ -z "$UGID" ]; then
log_failure_msg "user \"$RUNASUSER\" does not exist"
exit 1
fi
ntpdate 192.231.203.132
(
flock -w 180 9
start-stop-daemon --start --quiet --oknodo --pidfile 
$PIDFILE --startas $DAEMON -- -p $PIDFILE $NTPD_OPTS
) 9>$LOCKFILE
log_end_msg $?
;;
stop)
log_daemon_msg "Stopping NTP server" "ntpd"
start-stop-daemon --stop --quiet --oknodo --pidfile $PIDFILE
log_end_msg $?
rm -f $PIDFILE
;;
restart|force-reload)
$0 stop && sleep 2 && $0 start
;;
try-restart)
if $0 status >/dev/null; then
$0 restart
else
exit 0
fi
;;
reload)
exit 3
;;
status)
status_of_proc $DAEMON "NTP server"
;;
*)
echo "Usage: $0 
{start|stop|restart|try-restart|force-reload|status}"
exit 2
;;
esac


-- debconf-show failed

Bug#695547: sprint/bof @ Debconf to fix fpc bugs #695547 and #826300

[Steve McIntyre]

Hi Peter,

Sorry to keep you waiting - I was on VAC in South Africa after
DebConf, and I'm just catching up on things again now.

On Wed, Jul 06, 2016 at 01:31:54AM +0100, Peter Green wrote:
>Tags 695547 +patch
>Thanks
>
>On 05/07/16 23:37, Steve McIntyre wrote:
>>So Peter and I were talking a little earlier on #debian-arm,
>Specifically we were talking about the arm tag/flag stuff. I haven't looked
>into the powerpc issue.  Freepascal has a chunk of platform/cpu specific
>assembler code that is used for mixed pascal/c programs to initialise both
>the freepascal runtime library and libc. The powerpc linux version of this
>file is located at rtl/linux/powerpc/cprt0.as . It would not surprise me if
>it was something to do with this init code.
>
>It would be good to try and get a backtrace ("access violation" generally
>means that the freepascal runtime library trapped a segfault and turned it
>into an exception).
>
>The remainder of this mail is about the arm tag/flag stuff.
>>  and he
>>was making good progress on fixing stuff. He may have stuff all done
>>shortly, I guess... :-)
>I think i've fixed the arm tag/flag stuff. With the small patch attached I
>get the following.
>
>root@odroidu2:/# readelf --file-header /usr/bin/fpc
>ELF Header:
>  Magic:   7f 45 4c 46 01 01 01 00 00 00 00 00 00 00 00 00
>  Class: ELF32
>  Data:  2's complement, little endian
>  Version:   1 (current)
>  OS/ABI:UNIX - System V
>  ABI Version:   0
>  Type:  EXEC (Executable file)
>  Machine:   ARM
>  Version:   0x1
>  Entry point address:   0x100ec
>  Start of program headers:  52 (bytes into file)
>  Start of section headers:  410616 (bytes into file)
>  Flags: 0x5000400, Version5 EABI, hard-float ABI
>  Size of this header:   52 (bytes)
>  Size of program headers:   32 (bytes)
>  Number of program headers: 4
>  Size of section headers:   40 (bytes)
>  Number of section headers: 8
>  Section header string table index: 7
>root@odroidu2:/#
>
>root@odroidu2:/# readelf -a /usr/bin/fpc
>ELF Header:
>  Magic:   7f 45 4c 46 01 01 01 00 00 00 00 00 00 00 00 00
>  Class: ELF32
>  Data:  2's complement, little endian
>  Version:   1 (current)
>  OS/ABI:UNIX - System V
>  ABI Version:   0
>  Type:  EXEC (Executable file)
>  Machine:   ARM
>  Version:   0x1
>  Entry point address:   0x100ec
>  Start of program headers:  52 (bytes into file)
>  Start of section headers:  410616 (bytes into file)
>  Flags: 0x5000400, Version5 EABI, hard-float ABI
>  Size of this header:   52 (bytes)
>  Size of program headers:   32 (bytes)
>  Number of program headers: 4
>  Size of section headers:   40 (bytes)
>  Number of section headers: 8
>  Section header string table index: 7
>
>
>Section Headers:
>  [Nr] Name  TypeAddr OffSize   ES Flg Lk Inf 
> Al
>  [ 0]   NULL 00 00 00  0   0  > 0
>  [ 1] .note.ABI-tag NOTE000100c0 c0 20 00   A  0   0 
> 16
>  [ 2] .text PROGBITS000100e0 e0 0501a4 00  AX  0   0  
> 4
>  [ 3] .rodata   PROGBITS00060288 050288 010828 00   A  0   0  
> 8
>  [ 4] .data PROGBITS00081000 061000 003395 00  WA  0   0  
> 8
>  [ 5] .bss  NOBITS  00084398 064395 00237c 00  WA  0   0  
> 4
>  [ 6] .ARM.attributes   ARM_ATTRIBUTES   064395 21 00  0   0  
> 1
>  [ 7] .shstrtab STRTAB   0643b6 42 00  0   0  
> 1
>Key to Flags:
>  W (write), A (alloc), X (execute), M (merge), S (strings)
>  I (info), L (link order), G (group), T (TLS), E (exclude), x (unknown)
>  O (extra OS processing required) o (OS specific), p (processor specific)
>
>There are no section groups in this file.
>
>Program Headers:
>  Type   Offset   VirtAddr   PhysAddr   FileSiz MemSiz  Flg Align
>  LOAD   0x00 0x0001 0x0001 0x60ab0 0x60ab0 R E 0x1
>  LOAD   0x061000 0x00081000 0x00081000 0x03395 0x05714 RW  0x1
>  NOTE   0xc0 0x000100c0 0x000100c0 0x00020 0x00020 R   0x10
>  GNU_STACK  0x00 0x 0x 0x0 0x0 RW  0x10
>
> Section to Segment mapping:
>  Segment Sections...
>   00 .note.ABI-tag .text .rodata
>   01 .data .bss
>   02 .note.ABI-tag
>   03
>
>There is no dynamic section in this file.
>
>There are no relocations in this file.
>
>There are no unwind 

Bug#165940: Delivery Notification, ID 00000618020

[FedEx International MailService]

Dear Customer,

We could not deliver your parcel.
Shipment Label is attached to email.

Thank you for choosing FedEx,
Ian Hendrix,
Support Manager.



Malware Alert Text.txt
Description: Malware Alert Text.txt

Bug#826061: nginx: FTBFS on kfreebsd: incomplete type 'struct in6_pktinfo'

[Michael Lustfield]

Thanks for looking into this and building a patch so quickly! I'm
currently testing this patch and will send upstream, unless you prefer
handle it, once the build is succeeding in debian-kbsd.

On Sat, Jul 16, 2016 at 3:57 PM, Steven Chamberlain  wrote:
> tags 826061 + patch
> user debian-...@lists.debian.org
> usertags 826061 + kfreebsd
> thanks
>
> Hello,
>
> Andreas Beckmann wrote:
>> src/event/ngx_event_accept.c:65:17: warning: implicit declaration of 
>> function 'accept4' [-Wimplicit-function-declaration]
>> src/event/ngx_event_accept.c:348:55: error: invalid application of 'sizeof' 
>> to incomplete type 'struct in6_pktinfo'
>> src/event/ngx_event_accept.c:546:43: error: dereferencing pointer to 
>> incomplete type 'struct in6_pktinfo'
>
> Please find a simple patch for this attached.  Thanks!
>
> Regards,
> --
> Steven Chamberlain
> ste...@pyro.eu.org

Bug#831502: [Pkg-sugar-devel] Bug#831502: sucrose: Freezes X after initial configuration

[Jonas Smedegaard]

Hi Helge,

Quoting Helge Kreutzmann (2016-07-16 18:11:03)
> I wanted to try out sugar. Hence I installed succrose using apt-get 
> (up-to-date testing system).
> 
> Next I switchted my environment so sugar on sddm.
> 
> After entering my credentials I was asked a few questions (age, 
> gender).
> 
> Then sddm returned but does no longer react to mouse or keyboard 
> input. The mouse is also a big arrow.
> 
> I can restart x (Cmd-Alt-Backspace).
> 
> Whenever I choose sugar again, the only effect is that the mouse 
> cursor changes as described above and I can no longer use sddm.
> 
> I did not find anything on the sugar wiki helping me :-((

This I have never heard of before - but also I have never used sddm.

Please try use another login manager.  You should not need to remove 
sddm, just install one more, e.g. lightdm, and pick that as the default.

If that works, then we still have a bug somewhere, but can narrow it 
down to the interaction with that particular login manager (i.e. one of 
them not fully complying with needed specs).


 - 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#824956: Re. the Musescore situation in sid

[Thorsten Glaser]

Fabian Greffrath dixit:

>Ah, whatever. It compiled fine and so I uploaded it. So users can

Looks like build-arch/binary-arch is broken.

bye,
//mirabilos (no, I probably wouldn’t have caught that either)
-- 
Stéphane, I actually don’t block Googlemail, they’re just too utterly
stupid to successfully deliver to me (or anyone else using Greylisting
and not whitelisting their ranges). Same for a few other providers such
as Hotmail. Some spammers (Yahoo) I do block.

Bug#831495: totem does not start, Aborted.

[Kai Weber]

> They are in a separate archive:
> https://wiki.debian.org/AutomaticDebugPackages

totem works again.

I ran totem again in gdb, and the backtrace mentioned libavcodec.so.57.
libavcodec57 was upgraded on my machine last week

2016-07-12 19:59:08 upgrade libavcodec57:amd64 7:3.0.2-4 7:3.1.1-1
2016-07-13 08:26:22 upgrade libavcodec57:amd64 7:3.1.1-1 7:3.1.1-2

I could not downgrade to the version 3.0.2 easily because totem would be
removed by the downgrade. But with some trial and error I found totem
install gstreamer1.0-libav. I removed the package and reinstalled it and
now totem works!

This was the backtrace:

#0  0x760c11c8 in __GI_raise (sig=sig@entry=6) at 
../sysdeps/unix/sysv/linux/raise.c:54
resultvar = 0
pid = 15119
selftid = 15133
#1  0x760c264a in __GI_abort () at abort.c:89
save_stage = 2
act = {__sigaction_handler = {sa_handler = 0x20, sa_sigaction = 0x20}, 
sa_mask = {__val = {14073623472, 140736235985293, 142, 140736234748278, 
140735878064032, 8, 140736220803665,
  140735878062864, 5993174354767485440, 140736240040192, 
140735878064032, 140735878065216, 5993174354767485440, 1136, 140736239850576, 
140735878064032}}, sa_flags = -1610292464,
  sa_restorer = 0x7fffa004e000}
sigs = {__val = {32, 0 }}
#2  0x7fffb4fbaf5b in ?? () from /usr/lib/x86_64-linux-gnu/libavcodec.so.57
No symbol table info available.
#3  0x7fffb4fbb026 in avcodec_alloc_context3 () from 
/usr/lib/x86_64-linux-gnu/libavcodec.so.57
No symbol table info available.
#4  0x7fffb6962540 in ?? () from 
/usr/lib/x86_64-linux-gnu/gstreamer-1.0/libgstlibav.so
No symbol table info available.
#5  0x7fffb6958e53 in ?? () from 
/usr/lib/x86_64-linux-gnu/gstreamer-1.0/libgstlibav.so
No symbol table info available.
#6  0x7698d22d in g_type_class_ref () from 
/usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0
No symbol table info available.
#7  0x74f41da4 in gst_element_register () from 
/usr/lib/x86_64-linux-gnu/libgstreamer-1.0.so.0
No symbol table info available.
#8  0x7fffb69595b3 in ?? () from 
/usr/lib/x86_64-linux-gnu/gstreamer-1.0/libgstlibav.so
No symbol table info available.
#9  0x7fffb694be20 in ?? () from 
/usr/lib/x86_64-linux-gnu/gstreamer-1.0/libgstlibav.so
No symbol table info available.
#10 0x74f63537 in ?? () from 
/usr/lib/x86_64-linux-gnu/libgstreamer-1.0.so.0
No symbol table info available.
#11 0x74f65425 in ?? () from 
/usr/lib/x86_64-linux-gnu/libgstreamer-1.0.so.0
No symbol table info available.
#12 0x74f6612c in gst_plugin_load_by_name () from 
/usr/lib/x86_64-linux-gnu/libgstreamer-1.0.so.0
No symbol table info available.
#13 0x74f66a8d in gst_plugin_feature_load () from 
/usr/lib/x86_64-linux-gnu/libgstreamer-1.0.so.0
No symbol table info available.
#14 0x74f4146e in gst_element_factory_create () from 
/usr/lib/x86_64-linux-gnu/libgstreamer-1.0.so.0
No symbol table info available.
#15 0x7fffdab36398 in ?? () from 
/usr/lib/x86_64-linux-gnu/gstreamer-1.0/libgstplayback.so
No symbol table info available.
#16 0x7fffdab42202 in ?? () from 
/usr/lib/x86_64-linux-gnu/gstreamer-1.0/libgstplayback.so
No symbol table info available.
#17 0x7fffdab42ab2 in ?? () from 
/usr/lib/x86_64-linux-gnu/gstreamer-1.0/libgstplayback.so
No symbol table info available.
#18 0x7fffdab42cff in ?? () from 
/usr/lib/x86_64-linux-gnu/gstreamer-1.0/libgstplayback.so
No symbol table info available.
#19 0x7696cfa5 in g_closure_invoke () from 
/usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0
No symbol table info available.
#20 0x7697efc1 in ?? () from 
/usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0
---Type  to continue, or q  to quit---
No symbol table info available.
#21 0x76987d5c in g_signal_emit_valist () from 
/usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0
No symbol table info available.
#22 0x7698808f in g_signal_emit () from 
/usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0
No symbol table info available.
#23 0x769714d4 in ?? () from 
/usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0
No symbol table info available.
#24 0x74f14d44 in ?? () from 
/usr/lib/x86_64-linux-gnu/libgstreamer-1.0.so.0
No symbol table info available.
#25 0x76973a79 in g_object_notify_by_pspec () from 
/usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0
No symbol table info available.
#26 0x74f52fbc in ?? () from 
/usr/lib/x86_64-linux-gnu/libgstreamer-1.0.so.0
No symbol table info available.
#27 0x74f5e710 in gst_pad_push_event () from 
/usr/lib/x86_64-linux-gnu/libgstreamer-1.0.so.0
No symbol table info available.
#28 0x7fffb6b80a1b in ?? () from 
/usr/lib/x86_64-linux-gnu/gstreamer-1.0/libgstaudioparsers.so
No symbol table info available.
#29 0x7fffb6b8128f in ?? () from 
/usr/lib/x86_64-linux-gnu/gstreamer-1.0/libgstaudioparsers.so
No symbol table info available.
#30 0x7fffef750963 in ?? () from 

Bug#831527: flashplugin-nonfree: New Flash player 11.2.202.632 is available -- fixes a security issue

[vrishab]

Package: flashplugin-nonfree
Version: 1:3.6.1
Severity: important

Flash player 11.2.202.632 needs to be updated at
https://people.debian.org/~bartm/flashplugin-nonfree/D5C0FC14/.

Most recent version avaialble is:

fp.11.2.202.626.sha512.i386.pgp.asc
fp.11.2.202.626.sha512.amd64.pgp.asc

It should have the following updates:

fp.11.2.202.632.sha512.i386.pgp.asc
fp.11.2.202.632.sha512.amd64.pgp.asc



-- Package-specific info:
Debian version: jessie/sid
Architecture: amd64
Package version: 1:3.6.1
Adobe Flash Player version: LNX 11,2,202,626
MD5 checksums:
6a528f044752181e749e426c854bcc64  /var/cache/flashplugin-nonfree/get-
upstream-version.pl
48a2167247b42b04f3610eb7350a053f  /var/cache/flashplugin-
nonfree/install_flash_player_11_linux.x86_64.tar.gz
1b0b549f4c1e1d60bd0bbc6799c87824  /usr/lib/flashplugin-
nonfree/libflashplayer.so
Alternatives:
flash-mozilla.so - auto mode
  link currently points to /usr/lib/flashplugin-
nonfree/libflashplayer.so
/usr/lib/flashplugin-nonfree/libflashplayer.so - priority 50
Current 'best' version is '/usr/lib/flashplugin-
nonfree/libflashplayer.so'.
lrwxrwxrwx 1 root root 34 Jul 17 02:49 /usr/lib/mozilla/plugins/flash-
mozilla.so -> /etc/alternatives/flash-mozilla.so
/usr/lib/mozilla/plugins/flash-mozilla.so: symbolic link to
/etc/alternatives/flash-mozilla.so

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

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

Versions of packages flashplugin-nonfree depends on:
ii  binutils   2.25-5
ii  ca-certificates20141019+deb8u1
ii  debconf [debconf-2.0]  1.5.56
ii  gnupg  1.4.18-7+deb8u1
ii  libatk1.0-02.14.0-1
ii  libcairo2  1.14.0-2.1+deb8u1
ii  libcurl3-gnutls7.38.0-4+deb8u3
ii  libfontconfig1 2.11.0-6.3
ii  libfreetype6   2.5.2-3+deb8u1
ii  libgcc11:4.9.2-10
ii  libglib2.0-0   2.42.1-1+b1
ii  libgtk2.0-02.24.25-3+deb8u1
ii  libnspr4   2:4.10.7-1+deb8u1
ii  libnss32:3.17.2-1.1+deb8u2
ii  libpango1.0-0  1.36.8-3
ii  libstdc++6 4.9.2-10
ii  libx11-6   2:1.6.2-3
ii  libxext6   2:1.3.3-1
ii  libxt6 1:1.1.4-1+b1
ii  wget   1.16-1

flashplugin-nonfree recommends no packages.

Versions of packages flashplugin-nonfree suggests:
ii  fonts-dejavu   2.34-1
pn  hal
ii  iceweasel  45.2.0esr-1~deb8u1
pn  konqueror-nsplugins
pn  ttf-mscorefonts-installer  
pn  ttf-xfree86-nonfree

Bug#830300: RE: Bug#830300: bug in mdadm

[Любен Каравелов]

- Цитат от Michael Biebl (bi...@debian.org), на 16.07.2016 в 15:10 -

> On Sat, 9 Jul 2016 19:47:07 +0300
> =?utf-8?B?0JvRjtCx0LXQvSDQmtCw0YDQsNCy0LXQu9C+0LI=?= 
> wrote:
>> Hi,
>> 
>> The problem I am trying to solve is that my laptop (ASUS Zenbook UX301LAA) 
>> is using Intel RAID0 setup:
>> 
>> 00:1f.2 RAID bus controller: Intel Corporation 82801 Mobile SATA Controller 
>> [RAID mode] (rev 04)
>> 
>> But it stopped working 5-6 months ago (3.3.2-5 was the last version that was 
>> working out of the box). My understanding is that for some reason mdadm is 
>> not recognizing the setup as being a IMSM RAID and I was forcing the RAID 
>> assembly to bypass this check with the envvars until this was also broken by 
>> the last mdadm update.
>> 
> 
> Have you filed a bug report back then?
> Seems to me that fixing the root cause is a better approach then keeping
> this workaround alive (and 3.4-2 out of testing).
> 
> Michael
> 

No, I have not. It seems that it's know that it misses
to detect some controllers:

http://marc.info/?l=linux-raid=143872588405500=2

The man page suggest upgrading the BIOS and I have done so
to the latest available version without any effect. 

BTW, here are the details of my controller:

~ # mdadm --detail-platform
   Platform : Intel(R) Rapid Storage Technology
Version : 12.7.0.1936
RAID Levels : raid0 raid1
Chunk Sizes : 4k 8k 16k 32k 64k 128k
2TB volumes : supported
  2TB disks : supported
  Max Disks : 6
Max Volumes : 2 per array, 4 per controller
 I/O Controller : /sys/devices/pci:00/:00:1f.2 (SATA)
  Port0 : /dev/sda (135178400807)
  Port1 : /dev/sdb (135178400963)
  Port2 : - no device attached -
  Port3 : - no device attached -

~ # lspci -v
...
00:1f.2 RAID bus controller: Intel Corporation 82801 Mobile SATA Controller 
[RAID mode] (rev 04)
Subsystem: ASUSTeK Computer Inc. 82801 Mobile SATA Controller [RAID 
mode]
Flags: bus master, 66MHz, medium devsel, latency 0, IRQ 43
I/O ports at f0b0 [size=8]
I/O ports at f0a0 [size=4]
I/O ports at f090 [size=8]
I/O ports at f080 [size=4]
I/O ports at f060 [size=32]
Memory at f7d22000 (32-bit, non-prefetchable) [size=2K]
Capabilities: [80] MSI: Enable+ Count=1/1 Maskable- 64bit-
Capabilities: [70] Power Management version 3
Capabilities: [a8] SATA HBA v1.0
Kernel driver in use: ahci
Kernel modules: ahci
...
~ # dmidecode
# dmidecode 3.0
Getting SMBIOS data from sysfs.
SMBIOS 2.7 present.
24 structures occupying 1689 bytes.
Table at 0xDAE7C018.

Handle 0x, DMI type 0, 24 bytes
BIOS Information
Vendor: American Megatrends Inc.
Version: UX301LAA.211
Release Date: 06/05/2015
Address: 0xF
Runtime Size: 64 kB
ROM Size: 6144 kB
Characteristics:
PCI is supported
BIOS is upgradeable
BIOS shadowing is allowed
Boot from CD is supported
Selectable boot is supported
BIOS ROM is socketed
EDD is supported
5.25"/1.2 MB floppy services are supported (int 13h)
3.5"/720 kB floppy services are supported (int 13h)
3.5"/2.88 MB floppy services are supported (int 13h)
Print screen service is supported (int 5h)
8042 keyboard services are supported (int 9h)
Serial services are supported (int 14h)
Printer services are supported (int 17h)
ACPI is supported
USB legacy is supported
Smart battery is supported
BIOS boot specification is supported
Targeted content distribution is supported
UEFI is supported
BIOS Revision: 4.6
...

and here is my mdadm.conf:

~ # cat /etc/mdadm/mdadm.conf   

 root@zenbook
# mdadm.conf
#
# Please refer to mdadm.conf(5) for information about this file.
#

# by default (built-in), scan all partitions (/proc/partitions) and all
# containers for MD superblocks. alternatively, specify devices to scan, using
# wildcards if desired.
#DEVICE partitions containers

# auto-create devices with Debian standard permissions
CREATE owner=root group=disk mode=0660 auto=yes

# automatically tag new arrays as belonging to the local system
HOMEHOST 

# instruct the monitoring daemon where to send mail alerts
MAILADDR root

# definitions of existing MD arrays
ARRAY metadata=imsm UUID=518b7355:90f15f1b:d74e62c6:e0c9c9da
ARRAY /dev/md/ASUS_OS container=518b7355:90f15f1b:d74e62c6:e0c9c9da member=0 
UUID=6274cc4a:a22ed1d4:7a1173d6:f24c1fc7

# This file was auto-generated on Tue, 12 Aug 2014 21:01:58 -0700
# by mkconf 3.3-2


Thanks in 

Bug#826061: nginx: FTBFS on kfreebsd: incomplete type 'struct in6_pktinfo'

[Steven Chamberlain]

tags 826061 + patch
user debian-...@lists.debian.org
usertags 826061 + kfreebsd
thanks

Hello,

Andreas Beckmann wrote:
> src/event/ngx_event_accept.c:65:17: warning: implicit declaration of function 
> 'accept4' [-Wimplicit-function-declaration]
> src/event/ngx_event_accept.c:348:55: error: invalid application of 'sizeof' 
> to incomplete type 'struct in6_pktinfo'
> src/event/ngx_event_accept.c:546:43: error: dereferencing pointer to 
> incomplete type 'struct in6_pktinfo'

Please find a simple patch for this attached.  Thanks!

Regards,
-- 
Steven Chamberlain
ste...@pyro.eu.org
Date: Sat, 16 Jul 2016 23:52:50 +0100
From: Steven Chamberlain 
Subject: Use _GNU_SOURCE on GNU/kFreeBSD

Define _GNU_SOURCE not only on GNU/Hurd, but also other glibc-based
platforms including GNU/kFreeBSD.

diff --git a/src/os/unix/ngx_posix_config.h b/src/os/unix/ngx_posix_config.h
index 5d1358e..69b8dd1 100644
--- a/src/os/unix/ngx_posix_config.h
+++ b/src/os/unix/ngx_posix_config.h
@@ -21,10 +21,13 @@
 #endif
 
 
-#if (NGX_GNU_HURD)
+#if defined(__GLIBC__)
 #ifndef _GNU_SOURCE
 #define _GNU_SOURCE /* accept4() */
 #endif
+#endif
+
+#if (NGX_GNU_HURD)
 #define _FILE_OFFSET_BITS   64
 #endif
 


signature.asc
Description: Digital signature

Bug#736548: monkeysign: Reports "key is expired, cannot sign" on non-expired key

[Jerome Charaoui]

Alas, the previous patch is insufficient as monkeysign halts on a
KEYEXPIRED error which occurs later on, probably when it's attempting to
cleanup uids.

I'm pondering whether we should instead patch expect_pattern() to always
ignore KEYEXPIRED and SIGEXPIRED messages.

Would this be detrimental in other keysigning scenarios?

-- Jerome



signature.asc
Description: OpenPGP digital signature

Bug#752998: zfs dump magic

[Christoph Biedl]

tags 752998 moreinfo
thanks

Russell Coker wrote...

> https://wiki.freebsd.org/ZFS
> 
> I have attached a magic file for ZFS dumps downloaded from the above page.  I 
> have never tested it but I expect that the FreeBSD people know what they are 
> doing.

Now I'm confused. Your attached file is virtually identical to
magic/Magic/zfs in the file(1) sources, and is present since 5.11
which is in wheezy.

Did I miss something?

Christoph


signature.asc
Description: Digital signature

Bug#825118: python-openssl: 'CompiledFFI' object has no attribute 'def_extern'

[Sandro Tosi]

control: reassign -n python-cryptography

the path producing the error is in  python-cryptography, reassigning accordingly

On Mon, May 23, 2016 at 8:22 PM, Nicola Spanti
 wrote:
> Package: python-openssl
> Version: 16.0.0-1
> Severity: important
>
> Dear Maintainer,
>
>
> Apps that use python-openssl do not work anymore. For example:
>
> # pip freeze --local | grep -v '^\-e' | cut -d = -f 1  | xargs -n1 pip 
> install -U
> Traceback (most recent call last):
>   File "/usr/bin/pip", line 9, in 
> from pip import main
>   File "/usr/lib/python2.7/dist-packages/pip/__init__.py", line 13, in 
> 
> from pip.exceptions import InstallationError, CommandError, PipError
>   File "/usr/lib/python2.7/dist-packages/pip/exceptions.py", line 6, in 
> 
> from pip._vendor.six import iteritems
>   File "/usr/lib/python2.7/dist-packages/pip/_vendor/__init__.py", line 64, 
> in 
> vendored("cachecontrol")
>   File "/usr/lib/python2.7/dist-packages/pip/_vendor/__init__.py", line 36, 
> in vendored
> __import__(modulename, globals(), locals(), level=0)
>   File 
> "/usr/share/python-wheels/CacheControl-0.11.5-py2.py3-none-any.whl/cachecontrol/__init__.py",
>  line 9, in 
>   File 
> "/usr/share/python-wheels/CacheControl-0.11.5-py2.py3-none-any.whl/cachecontrol/wrapper.py",
>  line 1, in 
>   File 
> "/usr/share/python-wheels/CacheControl-0.11.5-py2.py3-none-any.whl/cachecontrol/adapter.py",
>  line 3, in 
>   File 
> "/usr/share/python-wheels/requests-2.9.1-py2.py3-none-any.whl/requests/__init__.py",
>  line 53, in 
>   File 
> "/usr/share/python-wheels/urllib3-1.13.1-py2.py3-none-any.whl/urllib3/contrib/pyopenssl.py",
>  line 54, in 
>   File "/usr/lib/python2.7/dist-packages/OpenSSL/__init__.py", line 8, in 
> 
> from OpenSSL import rand, crypto, SSL
>   File "/usr/lib/python2.7/dist-packages/OpenSSL/rand.py", line 12, in 
> 
> from OpenSSL._util import (
>   File "/usr/lib/python2.7/dist-packages/OpenSSL/_util.py", line 6, in 
> 
> from cryptography.hazmat.bindings.openssl.binding import Binding
>   File 
> "/usr/lib/python2.7/dist-packages/cryptography/hazmat/bindings/openssl/binding.py",
>  line 88, in 
> error=-1)
>   File 
> "/usr/lib/python2.7/dist-packages/cryptography/hazmat/bindings/openssl/binding.py",
>  line 77, in wrapper
> ffi.def_extern(name=name, **kwargs)(func)
> AttributeError: 'CompiledFFI' object has no attribute 'def_extern'
> Traceback (most recent call last):
>   File "/usr/bin/pip", line 9, in 
> from pip import main
>   File "/usr/lib/python2.7/dist-packages/pip/__init__.py", line 13, in 
> 
> from pip.exceptions import InstallationError, CommandError, PipError
>   File "/usr/lib/python2.7/dist-packages/pip/exceptions.py", line 6, in 
> 
> from pip._vendor.six import iteritems
>   File "/usr/lib/python2.7/dist-packages/pip/_vendor/__init__.py", line 64, 
> in 
> vendored("cachecontrol")
>   File "/usr/lib/python2.7/dist-packages/pip/_vendor/__init__.py", line 36, 
> in vendored
> __import__(modulename, globals(), locals(), level=0)
>   File 
> "/usr/share/python-wheels/CacheControl-0.11.5-py2.py3-none-any.whl/cachecontrol/__init__.py",
>  line 9, in 
>   File 
> "/usr/share/python-wheels/CacheControl-0.11.5-py2.py3-none-any.whl/cachecontrol/wrapper.py",
>  line 1, in 
>   File 
> "/usr/share/python-wheels/CacheControl-0.11.5-py2.py3-none-any.whl/cachecontrol/adapter.py",
>  line 3, in 
>   File 
> "/usr/share/python-wheels/requests-2.9.1-py2.py3-none-any.whl/requests/__init__.py",
>  line 53, in 
>   File 
> "/usr/share/python-wheels/urllib3-1.13.1-py2.py3-none-any.whl/urllib3/contrib/pyopenssl.py",
>  line 54, in 
>   File "/usr/lib/python2.7/dist-packages/OpenSSL/__init__.py", line 8, in 
> 
> from OpenSSL import rand, crypto, SSL
>   File "/usr/lib/python2.7/dist-packages/OpenSSL/rand.py", line 12, in 
> 
> from OpenSSL._util import (
>   File "/usr/lib/python2.7/dist-packages/OpenSSL/_util.py", line 6, in 
> 
> from cryptography.hazmat.bindings.openssl.binding import Binding
>   File 
> "/usr/lib/python2.7/dist-packages/cryptography/hazmat/bindings/openssl/binding.py",
>  line 88, in 
> error=-1)
>   File 
> "/usr/lib/python2.7/dist-packages/cryptography/hazmat/bindings/openssl/binding.py",
>  line 77, in wrapper
> ffi.def_extern(name=name, **kwargs)(func)
> AttributeError: 'CompiledFFI' object has no attribute 'def_extern'
>
>
> Regards.
>
>
> -- System Information:
> Debian Release: stretch/sid
>   APT prefers testing
>   APT policy: (500, 'testing'), (500, 'stable'), (500, 'oldstable')
> Architecture: amd64 (x86_64)
>
> Kernel: Linux 4.5.0-2-amd64 (SMP w/8 CPU cores)
> Locale: LANG=fr_FR.utf8, LC_CTYPE=fr_FR.utf8 (charmap=UTF-8)
> Shell: /bin/sh linked to /bin/dash
> Init: systemd (via /run/systemd/system)
>
> Versions of packages python-openssl depends on:
> ii  python-cryptography  1.3.1-2
> ii  python-six   1.10.0-3
> pn  python:any   
>
> python-openssl 

Bug#819856: dnsmasq: diff for NMU version 2.76-1.2

[Christian Hofstaedtler]

* Simon Kelley  [160717 00:01]:
> Thanks for this. I need to upload 2.76-2, which has a fix for a
> different bug, #831372. I've patched this with the 2.76-1.1 and 2.76-1.2
> NMUs, so they're included. However by the time 2.76-1.2 gets to the end
> of the delay, 2.76-2 will be in place. That's not going to confuse
> things, is it? 2.76-2 > 2.76-1.2, so the NMU won't overwrite my later
> upload, which includes the NMU patch?

It shouldn't; just go ahead and I'll cancel my upload once I'm back
home.

Cheers,

-- 
 ,''`.  Christian Hofstaedtler 
: :' :  Debian Developer
`. `'   7D1A CFFA D9E0 806C 9C4C  D392 5C13 D6DB 9305 2E03
  `-

Bug#831526: gcin: drop unnecessary override_dh_auto_clean rule

[Jeremy Bicha]

Source: gcin
Version: 2.8.4+dfsg1-8
Severity: minor

The gcin packaging overrides dh_auto_clean to run 'make clean'
instead, but dh_auto_clean should already run 'make clean' so this is
unnecessary.

https://manpages.debian.org/cgi-bin/man.cgi?query=dh_auto_clean=Debian+testing+stretch

Thanks,
Jeremy Bicha

Bug#821967: NMU Upload

[Michael Lustfield]

This is a package that a large number of people use. It is also set for
auto-removal on the 22nd because of this bug. I plan to follow the NMU process
for this bug as quickly as possible.

-- 
Michael Lustfield


pgpbLskZN2tkf.pgp
Description: OpenPGP digital signature

Bug#805228: Bug#806630: libnative-platform-java: FTBFS when built with dpkg-buildpackage -A (mh_installjar fails)

[Santiago Vila]

On Sat, 16 Jul 2016, tony mancill wrote:

> The first two packages I tried, src:pegdown and src:libjbcrypt-java,
> both appear in the "successfully built reproducibly" set here [1], and
> neither has any bugs assigned to it.  Maybe I'm looking in the wrong place?

If those packages generate only "Arch: all" packages and they build ok
in the reproducible builds setup, then those packages are ok.

The problem with the helper program you are using seems to be that it
makes "dpkg-buildpackage -A" to fail on packages generating both
"Arch: all" and "Arch: any" binary packages.

The same packages might appear as "ok" in reproducible builds because
they just test for "dpkg-buildpackage".

So, it is possible that there are no other affected packages than the
ones in my list.

Thanks.

Bug#762829: file: Pascal modules (ISO 10206) wrongly classified as text/x-ruby

[Christoph Biedl]

tags 762829 confirmed upstream help
thanks

It's been a while but it hasn't been forgotten ...

Peter wrote...

> Some Pascal source files are classified as Ruby.
> Maybe file is confused by the keywords 'module', 'import' and export,
> which are valid Pascal extension keywords in ISO 10206?

Correct, the "module" keyword in the first line of your example
triggers one of the tests for ruby (magic/Magdir/ruby:25).

However I'm reluctant to change this as it easily might create
false-positives. If there's is a distinct rule to tell Ruby and
Pascal apart, I'll happily forward it to upstream.

Christoph


signature.asc
Description: Digital signature

Bug#831525: [libretro-mupen64plus] Remove copies of mupen64plus-*

[Charlemagne Lasse]

Source: libretro-mupen64plus
Version: 2.0+git20160207+dfsg2-1
Severity: serious

Marked as serious because it is a violation of paragraph 4.13 from the
Debian Policy.

Debian should not ship the same things twice. So the Debian Games Team
should decide whether it wants to ship mupen64plus-* or
libretro-mupen64plus

Maybe it is also possible not to use the included copies and instead
load the plugins from mupen64plus-*

Bug#831524: dpkg: Add a way to drop the Built-For-Profiles field

[Javier Serrano Polo]

Package: dpkg
Version: 1.18.9
Severity: wishlist

As discussed in
https://lists.debian.org/debian-dpkg/2016/07/threads.html#00021 , there
should be a way to include the Built-For-Profiles field only when dirty
build profiles are active. Clean build profiles should yield identical
binary packages to those when no build profiles are active.

This may be useful when building a subset of binary packages for
testing, debugging, derivatives waiting for their changes to be merged
in Debian, and providing faster security updates locally. In Squeeze,
there were 21 packages (including exim4, gcc-4.4, gtk+2.0 and linux-2.6)
where building only a subset reduced compilation time or disk space
significantly.

Building a subset of packages can be achieved with build profiles. This
can also be solved with an independent environment variable, such as
DEB_BUILD_FLAVOURS or DEB_BUILD_PACKAGES, which would avoid
Built-For-Profiles.

The solution for the Built-For-Profiles field is to either drop it and
rely on .buildinfo files, or mark some build profiles as dirty or clean.
One way to mark is in binary stanzas with
"Build-Profiles-Content-Changes"; another way is in source stanzas with
"Clean-Build-Profiles" (or "Dirty-Build-Profiles"); a third way is at
build time with a build profile named "clean" (or "dirty") in
DEB_BUILD_PROFILES.


smime.p7s
Description: S/MIME cryptographic signature

Bug#831382: closed by Sebastian Ramacher <sramac...@debian.org> (Re: Bug#831382: mplayer2: keyboard shortcuts fail for up/down/left/right arrows.. program hangs in "seek" (apparently))

[Ralph Ronnquist]

I'll take this as an impolite way of aking "Does this happen on Debian 8 
Jessie as well?", and the answer is "Yes, it does indeed."


On 15/07/16 20:42, Debian Bug Tracking System wrote:

This is an automatic notification regarding your Bug report
which was filed against the mplayer2 package:

#831382: mplayer2: keyboard shortcuts fail for up/down/left/right arrows.. program hangs 
in "seek" (apparently)

It has been closed by Sebastian Ramacher .

Their explanation is attached below along with your original report.
If this explanation is unsatisfactory and you have not received a
better one in a separate message then please contact Sebastian Ramacher 
 by
replying to this email.

Bug#831515: ITP: sdnotify -- A pure Python implementation of systemd's service notification protocol

[Guus Sliepen]

On Sat, Jul 16, 2016 at 10:29:51PM +0200, Orestis Ioannou wrote:

> * Package name: sdnotify
>   Description : A pure Python implementation of systemd's service
> notification protocol

You should probably name the package (both binary and source)
"python-sdnotify".

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


signature.asc
Description: Digital signature

Bug#819856: dnsmasq: diff for NMU version 2.76-1.2

[Simon Kelley]

Hi,

Thanks for this. I need to upload 2.76-2, which has a fix for a
different bug, #831372. I've patched this with the 2.76-1.1 and 2.76-1.2
NMUs, so they're included. However by the time 2.76-1.2 gets to the end
of the delay, 2.76-2 will be in place. That's not going to confuse
things, is it? 2.76-2 > 2.76-1.2, so the NMU won't overwrite my later
upload, which includes the NMU patch?

Cheers,

Simon.




On 16/07/16 01:31, z...@debian.org wrote:
> Control: tags 819856 + patch
> Control: tags 819856 + pending
> 
> Dear maintainer,
> 
> I've prepared an NMU for dnsmasq (versioned as 2.76-1.2) and
> uploaded it to DELAYED/5. Please feel free to tell me if I
> should delay it longer.
> 
> Best,
> Chris
> 
> 
> diff -u dnsmasq-2.76/debian/changelog dnsmasq-2.76/debian/changelog
> --- dnsmasq-2.76/debian/changelog
> +++ dnsmasq-2.76/debian/changelog
> @@ -1,3 +1,11 @@
> +dnsmasq (2.76-1.2) unstable; urgency=medium
> +
> +  * Non-maintainer upload.
> +  * dnsmasq: Install marker file to determine package installed state,
> +for the benefit of the init script. (Closes: #819856)
> +
> + -- Christian Hofstaedtler   Sat, 16 Jul 2016 00:17:57 +
> +
>  dnsmasq (2.76-1.1) unstable; urgency=medium
>  
>* Non-maintainer upload.
> diff -u dnsmasq-2.76/debian/init dnsmasq-2.76/debian/init
> --- dnsmasq-2.76/debian/init
> +++ dnsmasq-2.76/debian/init
> @@ -33,7 +33,7 @@
>  # The following test ensures the dnsmasq service is not started, when the
>  # package 'dnsmasq' is removed but not purged, even if the dnsmasq-base 
>  # package is still in place.
> -test -d /usr/share/doc/dnsmasq || exit 0
> +test -e /usr/share/dnsmasq/installed-marker || exit 0
>   
>  test -x $DAEMON || exit 0
>  
> diff -u dnsmasq-2.76/debian/rules dnsmasq-2.76/debian/rules
> --- dnsmasq-2.76/debian/rules
> +++ dnsmasq-2.76/debian/rules
> @@ -105,6 +105,7 @@
>   -d debian/daemon/etc/dnsmasq.d \
>   -d debian/daemon/etc/resolvconf/update.d \
>   -d debian/daemon/usr/lib/resolvconf/dpkg-event.d \
> + -d debian/daemon/usr/share/dnsmasq \
>   -d debian/daemon/etc/default \
>   -d debian/daemon/lib/systemd/system \
>  -d debian/daemon/etc/insserv.conf.d
> @@ -113,6 +114,7 @@
>   install -m 755 debian/init debian/daemon/etc/init.d/dnsmasq
>   install -m 755 debian/resolvconf 
> debian/daemon/etc/resolvconf/update.d/dnsmasq
>   install -m 755 debian/resolvconf-package 
> debian/daemon/usr/lib/resolvconf/dpkg-event.d/dnsmasq
> + install -m 644 debian/installed-marker debian/daemon/usr/share/dnsmasq
>   install -m 644 debian/default debian/daemon/etc/default/dnsmasq
>   install -m 644 dnsmasq.conf.example debian/daemon/etc/dnsmasq.conf
>   install -m 644 debian/readme.dnsmasq.d 
> debian/daemon/etc/dnsmasq.d/README
> only in patch2:
> unchanged:
> --- dnsmasq-2.76.orig/debian/installed-marker
> +++ dnsmasq-2.76/debian/installed-marker
> @@ -0,0 +1,2 @@
> +# This file indicates dnsmasq (and not just dnsmasq-base) is installed.
> +# It is an implementation detail of the dnsmasq init script.
> 

Bug#831523: RM: python-kineticstools [armel mipsel] -- ROM; not installable

[Afif Elghraoui]

Package: ftp.debian.org
Severity: normal


This package is not installable on the named architectures because
of the absence of python-pysam there.

Many thanks and regards
Afif

Bug#831522: RM: pbh5tools [armel mipsel] -- ROM; not installable

[Afif Elghraoui]

Package: ftp.debian.org
Severity: normal


This package is not installable on the named architectures because
of the absence of python-pysam there.

Thanks and regards
Afif

Bug#831521: uscan: Implement new 'nomktar' option on watch file

[Sergio Durigan Junior]

Package: devscripts
Tags: patch

Hi,

Rationale: 

Some Debian maintainers have to deal with upstream projects that do not
offer tarballs for releases.  The modus operandi for working around this
"issue" is to provide your own replacement for the 'uupdate' script,
which should be responsible for manipulating the file(s) downloaded from
upstream and prepare a "fake" tarball to be provided to 'uupdate'.

This works, but has one drawback: there is no "easy" way to suppress the
'mk-origtargz' program to run.  And the problem with this is that
'mk-origtargz' expects a compressed tarball as its input, always.
Calling it in the situation described above leads to an error.  So, the
user is left with some non-ideal options:

1) Invoke 'uscan' passing '--no-symlink' as one of the parameters.  This
has the side-effect of skipping the call to 'mk-origtargz'.  The obvious
disadvantages are: (a) it is not obvious to the user that this option
solves the problem described above, and (b) the user will have to
remember to pass this option every time.

2) Hacking the 'uupdate'-replacement script in order to invoke it by
hand.  The obvious disadvantage is that the user won't be able to use
'uscan', and also will have to remember this every time.

Therefore, to fix this issue, I am proposing a new option, to be
provided via 'opts=' in the watch file, whose purpose is to suppress the
execution of 'mk-origtargz'.  Its effect will be similar to passing
'--no-symlink', although the user will still be able to provide
'--rename', for example.

Opinions?

Cheers,

-- 
Sergio
GPG key ID: 237A 54B1 0287 28BF 00EF  31F4 D0EB 7628 65FC 5E36
Please send encrypted e-mail if possible
http://sergiodj.net/

From b40dbd4f6b052f0753aede3822a372149d8d0c7f Mon Sep 17 00:00:00 2001
From: Sergio Durigan Junior 
Date: Sat, 16 Jul 2016 17:36:29 -0400
Subject: [PATCH] uscan: Implement 'nomktar' option to allow user to specify
 when she does not want mk-origtargz to be invoked.

---
 debian/changelog |  6 ++
 scripts/uscan.pl | 11 ++-
 2 files changed, 16 insertions(+), 1 deletion(-)

diff --git a/debian/changelog b/debian/changelog
index 3b9e5a0..3207485 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,8 +1,14 @@
 devscripts (2.16.7) UNRELEASED; urgency=medium
 
+  [ Paul Wise ]
   * grep-excuses:
 + Fix the script for the removal of testing.pl from release.debian.org
 
+  [ Sergio Durigan Junior ]
+  * uscan:
++ Implement 'nomktar' option to allow user to specify when she does
+  not want mk-origtargz to be invoked.
+
  -- Paul Wise   Fri, 15 Jul 2016 22:36:19 +0800
 
 devscripts (2.16.6) unstable; urgency=medium
diff --git a/scripts/uscan.pl b/scripts/uscan.pl
index 9403ba6..818292e 100755
--- a/scripts/uscan.pl
+++ b/scripts/uscan.pl
@@ -408,6 +408,13 @@ No signature available. (No warning.)
 
 Decompress compressed archive before the pgp/gpg signature verification.
 
+=item B
+
+Do not invoke B after saving the downloaded file.  This
+is useful if you are dealing with files that are not tarballs, for
+example.  The side effect of this option is that no symlink will be
+created.
+
 =item B
 
 Disable all site specific special case code such as URL redirector uses and
@@ -2551,6 +2558,8 @@ sub process_watchline ($$)
 		$options{'pgpmode'} = 'mangle';
 		} elsif ($opt =~ /^\s*oversionmangle\s*=\s*(.+?)\s*$/) {
 		@{$options{'oversionmangle'}} = split /;/, $1;
+		} elsif ($opt =~ /^\s*nomktar\s*$/) {
+		$options{'nomktar'} = 1;
 		} else {
 		uscan_warn "unrecognised option $opt\n";
 		}
@@ -3700,7 +3709,7 @@ EOF
 my $mk_origtargz_out;
 my $path = "$destdir/$newfile_base";
 my $target = $newfile_base;
-unless ($symlink eq "no") {
+unless ($symlink eq "no" || $options{'nomktar'} ) {
 	my @cmd = ("mk-origtargz");
 	push @cmd, "--package", $pkg;
 	push @cmd, "--version", $common_mangled_newversion;
-- 
2.8.1



signature.asc
Description: PGP signature

Bug#831252: [Pkg-julia-devel] Bug#831252: julia: FTBFS: Tests failures

[Peter Colberg]

Hi Lucas,

On Thu, Jul 14, 2016 at 11:57:56AM +0200, Lucas Nussbaum wrote:
> During a rebuild of all packages in sid, your package failed to build on
> amd64.

I rebuilt julia successfully five times on my amd64 machine with sbuild.

> The full build log is available from:
>
> http://people.debian.org/~lucas/logs/2016/07/14/julia_0.4.6-1_unstable_gcc5.log

The test log is full of segmentation faults, which might indicate a
problem with the build machine. Does your instance have enough RAM?

Julia requires ~1 GB per process to run the test suite.

Regards,
Peter

Bug#831520: RM: pbbarcode [armel mipsel i386 kfreebsd-i386] -- ROM; not installable

[Afif Elghraoui]

Package: ftp.debian.org
Severity: normal


This package is not installable on the named architectures because
of its eventual dependency python-pysam not being available there.

Thanks and regards
Afif

Bug#831518: pulseaudio: no sound after upgrade from 8.0.2+b2 to 9.0-1.1

[Felipe Sateler]

Control: tags -1 moreinfo

On 16 July 2016 at 17:34, Eric Cooper  wrote:
> Package: pulseaudio
> Version: 9.0-1.1
> Severity: important
>
> I use USB-attached speakers (Audioengine 2+) on my desktop machine.
> They worked fine until I upgraded pulseaudio to version 9.  I
> reinstalled the version 8 pulseaudio packages and they work again.
>
> Before realizing it was the pulseaudio package, I tried older (4.5) and
> newer (4.7) Linux kernels, but the behavior was the same.

Did you install the pulseaudio-module-udev package?

-- 

Saludos,
Felipe Sateler

Bug#831519: [vizigrep] ImportError: cannot import name GtkSource

[Marek Straka]

Package: vizigrep
Version: 1.3-1
Severity: normal

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

Add dependency on "gir1.2-gtksource-3.0".  Otherwise you get something like:

marek@dell-e6220:~$ vizigrep
** (vizigrep:4562): WARNING **: Error retrieving accessibility bus 
address: org.freedesktop.DBus.Error.ServiceUnknown: The name 
org.a11y.Bus was not provided by any .service files
/usr/lib/python2.7/dist-packages/vizigrep/main.py:5: PyGIWarning: Gtk 
was imported without specifying a version first. Use 
gi.require_version('Gtk', '3.0') before import to ensure that the right 
version gets loaded.

  from gi.repository import Gtk, GObject
Traceback (most recent call last):
  File "/usr/bin/vizigrep", line 9, in 
load_entry_point('vizigrep==1.3', 'gui_scripts', 'vizigrep')()
  File "/usr/lib/python2.7/dist-packages/pkg_resources/__init__.py", 
line 542, in load_entry_point

return get_distribution(dist).load_entry_point(group, name)
  File "/usr/lib/python2.7/dist-packages/pkg_resources/__init__.py", 
line 2569, in load_entry_point

return ep.load()
  File "/usr/lib/python2.7/dist-packages/pkg_resources/__init__.py", 
line 2229, in load

return self.resolve()
  File "/usr/lib/python2.7/dist-packages/pkg_resources/__init__.py", 
line 2235, in resolve

module = __import__(self.module_name, fromlist=['__name__'], level=0)
  File "/usr/lib/python2.7/dist-packages/vizigrep/main.py", line 7, in 


from ViziGrepWindow import ViziGrepWindow
  File "/usr/lib/python2.7/dist-packages/vizigrep/ViziGrepWindow.py", 
line 3, in 

from guiapp.Window import Window
  File "/usr/lib/python2.7/dist-packages/vizigrep/guiapp/Window.py", 
line 2, in 

from SuperGtkBuilder import SuperGtkBuilder
  File 
"/usr/lib/python2.7/dist-packages/vizigrep/guiapp/SuperGtkBuilder.py", 
line 1, in 

from gi.repository import Gtk, GObject, GtkSource
ImportError: cannot import name GtkSource


--- System information. ---
Architecture: amd64
Kernel: Linux 4.6.0-1-amd64

Debian Release: stretch/sid
500 testing ftp.at.debian.org

--- Package information. ---
Depends (Version) | Installed
==-+-==
python:any (<< 2.8) |
python:any (>= 2.7.5-5~) |
python-pkg-resources | 20.10.1-1.1
gir1.2-gtk-3.0 | 3.20.6-2
python-gi | 3.20.1-1

Package's Recommends field is empty.

Package's Suggests field is empty.

Bug#831518: pulseaudio: no sound after upgrade from 8.0.2+b2 to 9.0-1.1

[Eric Cooper]

Package: pulseaudio
Version: 9.0-1.1
Severity: important

I use USB-attached speakers (Audioengine 2+) on my desktop machine.
They worked fine until I upgraded pulseaudio to version 9.  I
reinstalled the version 8 pulseaudio packages and they work again.

Before realizing it was the pulseaudio package, I tried older (4.5) and
newer (4.7) Linux kernels, but the behavior was the same.
# This file is part of PulseAudio.
#
# PulseAudio is free software; you can redistribute it and/or modify
# it under the terms of the GNU Lesser General Public License as published by
# the Free Software Foundation; either version 2 of the License, or
# (at your option) any later version.
#
# PulseAudio is distributed in the hope that it will be useful, but
# WITHOUT ANY WARRANTY; without even the implied warranty of
# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
# General Public License for more details.
#
# You should have received a copy of the GNU Lesser General Public License
# along with PulseAudio; if not, see .

## Configuration file for PulseAudio clients. See pulse-client.conf(5) for
## more information. Default values are commented out.  Use either ; or # for
## commenting.

; default-sink =
; default-source =
; default-server =
; default-dbus-server =

; autospawn = yes
; daemon-binary = /usr/bin/pulseaudio
; extra-arguments = --log-target=syslog

; cookie-file =

; enable-shm = yes
; shm-size-bytes = 0 # setting this 0 will use the system-default, usually 64 
MiB

; auto-connect-localhost = no
; auto-connect-display = no
# This file is part of PulseAudio.
#
# PulseAudio is free software; you can redistribute it and/or modify
# it under the terms of the GNU Lesser General Public License as published by
# the Free Software Foundation; either version 2 of the License, or
# (at your option) any later version.
#
# PulseAudio is distributed in the hope that it will be useful, but
# WITHOUT ANY WARRANTY; without even the implied warranty of
# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
# General Public License for more details.
#
# You should have received a copy of the GNU Lesser General Public License
# along with PulseAudio; if not, see .

## Configuration file for the PulseAudio daemon. See pulse-daemon.conf(5) for
## more information. Default values are commented out.  Use either ; or # for
## commenting.

; daemonize = no
; fail = yes
; allow-module-loading = yes
; allow-exit = yes
; use-pid-file = yes
; system-instance = no
; local-server-type = user
; enable-shm = yes
; shm-size-bytes = 0 # setting this 0 will use the system-default, usually 64 
MiB
; lock-memory = no
; cpu-limit = no

; high-priority = yes
; nice-level = -11

; realtime-scheduling = yes
; realtime-priority = 5

; exit-idle-time = 20
; scache-idle-time = 20

; dl-search-path = (depends on architecture)

; load-default-script-file = yes
; default-script-file = /etc/pulse/default.pa

; log-target = auto
; log-level = notice
; log-meta = no
; log-time = no
; log-backtrace = 0

; resample-method = speex-float-1
; enable-remixing = yes
; enable-lfe-remixing = yes
; lfe-crossover-freq = 120

; flat-volumes = yes

; rlimit-fsize = -1
; rlimit-data = -1
; rlimit-stack = -1
; rlimit-core = -1
; rlimit-as = -1
; rlimit-rss = -1
; rlimit-nproc = -1
; rlimit-nofile = 256
; rlimit-memlock = -1
; rlimit-locks = -1
; rlimit-sigpending = -1
; rlimit-msgqueue = -1
; rlimit-nice = 31
; rlimit-rtprio = 9
; rlimit-rttime = 20

; default-sample-format = s16le
; default-sample-rate = 44100
; alternate-sample-rate = 48000
; default-sample-channels = 2
; default-channel-map = front-left,front-right

; default-fragments = 4
; default-fragment-size-msec = 25

; enable-deferred-volume = yes
; deferred-volume-safety-margin-usec = 8000
; deferred-volume-extra-delay-usec = 0
#!/usr/bin/pulseaudio -nF
#
# This file is part of PulseAudio.
#
# PulseAudio is free software; you can redistribute it and/or modify it
# under the terms of the GNU Lesser General Public License as published by
# the Free Software Foundation; either version 2 of the License, or
# (at your option) any later version.
#
# PulseAudio is distributed in the hope that it will be useful, but
# WITHOUT ANY WARRANTY; without even the implied warranty of
# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
# General Public License for more details.
#
# You should have received a copy of the GNU Lesser General Public License
# along with PulseAudio; if not, see .

# This startup script is used only if PulseAudio is started per-user
# (i.e. not in system mode)

.nofail

### Load something into the sample cache
#load-sample-lazy x11-bell /usr/share/sounds/freedesktop/stereo/bell.oga
#load-sample-lazy pulse-hotplug 
/usr/share/sounds/freedesktop/stereo/device-added.oga
#load-sample-lazy pulse-coldplug 
/usr/share/sounds/freedesktop/stereo/device-added.oga
#load-sample-lazy 

Bug#824956: Re. the Musescore situation in sid

[Thorsten Glaser]

Fabian Greffrath dixit:

>Ah, whatever. It compiled fine and so I uploaded it. So users can
>upgrade their sid systems. Everything else could be buffed out in a
>revision -2 upload.

True.

Thank you,
//mirabilos (no more ~280 held packages!)
-- 
15:39⎜«mika:#grml» mira|AO: "mit XFree86® wär’ das nicht passiert" - muhaha
15:48⎜ also warum machen die xorg Jungs eigentlich alles
kaputt? :)15:49⎜ thkoehler: weil sie als Kinder nie den
gebauten Turm selber umschmeissen durften?  -- ~/.Xmodmap wonders…

Bug#736548: monkeysign: Reports "key is expired, cannot sign" on non-expired key

[Jerome Charaoui]

tag patch
thanks

This ugly little patch appears to fix the problem for me.

Thanks,

-- Jerome
From 818778fb4ed3d288bd03c0d27c452255629e8304 Mon Sep 17 00:00:00 2001
From: Jerome Charaoui 
Date: Sat, 16 Jul 2016 17:18:26 -0400
Subject: [PATCH] Ignore KEYEXPIRED GnuPG error (closes #736548)

Allows us to sign a key which has one or more expired subkeys.
---
 monkeysign/gpg.py | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/monkeysign/gpg.py b/monkeysign/gpg.py
index 456cf3b..5e4e874 100644
--- a/monkeysign/gpg.py
+++ b/monkeysign/gpg.py
@@ -478,6 +478,13 @@ class Keyring():
 multiuid = self.context.seek(proc.stderr, 'GET_BOOL keyedit.sign_all.okay')
 except GpgProtocolError as e:
 raise GpgRuntimeError(self.context.returncode, _('cannot select uid for signing: %s') % e.found().decode('utf-8'))
+elif '[GNUPG:] KEYEXPIRED' in str(e):
+# This is a protocol error but should be ignored,
+# see doc/DETAILS in GnuPG documentation.
+try:
+multiuid = self.context.seek(proc.stderr, 'GET_BOOL keyedit.sign_all.okay')
+except GpgProtocolError as e:
+raise GpgRuntimeError(self.context.returncode, _('cannot select uid for signing: %s') % e.found().decode('utf-8'))
 else:
 raise GpgRuntimeError(self.context.returncode, _('cannot select uid for signing: %s') % e.found().decode('utf-8'))
 if multiuid:
-- 
2.8.1



signature.asc
Description: OpenPGP digital signature

Bug#828803: aptitude: SIGSEGV in debVersioningSystem::CheckDep from /usr/lib/x86_64-linux-gnu/libapt-pkg.so.5.0

[Manuel A. Fernandez Montecelo]

Control: tags -1 + moreinfo


Hi,

2016-06-28 02:29 Zhang Jingqiang:

Package: aptitude
Version: 0.8.1-1
Severity: normal

Hello,
I have previous kdepimlibs-data package installed, which has version 
4:16.04.1-2.
After this morning's update, there's two experimental version in the repo,
4:16.04.1-1 and 4:16.04.2-1, then I try to install 4:16.04.2-1 (mark this 
version to install),
and I got SIGSEGV.

There's no dbg package for this version of aptitude, so the backtrace attached 
may be useless.


The packages are provided now with the new method, -dbgsym ones.



Thread 1 "aptitude" received signal SIGSEGV, Segmentation fault.
0x77b420ed in debVersioningSystem::CheckDep(char const*, int, char 
const*) () from /usr/lib/x86_64-linux-gnu/libapt-pkg.so.5.0
#0  0x77b420ed in debVersioningSystem::CheckDep(char const*, int, char 
const*) () from /usr/lib/x86_64-linux-gnu/libapt-pkg.so.5.0
#1  0x557767c1 in ?? ()
#2  0x55650418 in ?? ()
#3  0x5564abcc in ?? ()
#4  0x55630a7a in ?? ()
#5  0x55638bd8 in ?? ()
#6  0x771d5fe5 in cwidget::widgets::tree::handle_key(cwidget::config::key 
const&) () from /usr/lib/x86_64-linux-gnu/libcwidget.so.3
#7  0x5561641d in ?? ()
#8  0x771dbab3 in 
cwidget::widgets::widget::dispatch_key(cwidget::config::key const&) () from 
/usr/lib/x86_64-linux-gnu/libcwidget.so.3
#9  0x771c3da7 in cwidget::widgets::table::handle_key(cwidget::config::key 
const&) () from /usr/lib/x86_64-linux-gnu/libcwidget.so.3
#10 0x771dbab3 in 
cwidget::widgets::widget::dispatch_key(cwidget::config::key const&) () from 
/usr/lib/x86_64-linux-gnu/libcwidget.so.3
#11 0x771af4bb in 
cwidget::widgets::passthrough::handle_key(cwidget::config::key const&) () from 
/usr/lib/x86_64-linux-gnu/libcwidget.so.3
#12 0x771dbab3 in 
cwidget::widgets::widget::dispatch_key(cwidget::config::key const&) () from 
/usr/lib/x86_64-linux-gnu/libcwidget.so.3
#13 0x771c3da7 in cwidget::widgets::table::handle_key(cwidget::config::key 
const&) () from /usr/lib/x86_64-linux-gnu/libcwidget.so.3
#14 0x771dbab3 in 
cwidget::widgets::widget::dispatch_key(cwidget::config::key const&) () from 
/usr/lib/x86_64-linux-gnu/libcwidget.so.3
#15 0x771af4bb in 
cwidget::widgets::passthrough::handle_key(cwidget::config::key const&) () from 
/usr/lib/x86_64-linux-gnu/libcwidget.so.3
#16 0x771dbab3 in 
cwidget::widgets::widget::dispatch_key(cwidget::config::key const&) () from 
/usr/lib/x86_64-linux-gnu/libcwidget.so.3
#17 0x771901f1 in 
cwidget::widgets::menubar::handle_key(cwidget::config::key const&) () from 
/usr/lib/x86_64-linux-gnu/libcwidget.so.3
#18 0x771dbab3 in 
cwidget::widgets::widget::dispatch_key(cwidget::config::key const&) () from 
/usr/lib/x86_64-linux-gnu/libcwidget.so.3
#19 0x7715ddc9 in 
cwidget::toplevel::input_thread::get_input_event::dispatch() () from 
/usr/lib/x86_64-linux-gnu/libcwidget.so.3
#20 0x771556b5 in cwidget::toplevel::mainloop(int) () from 
/usr/lib/x86_64-linux-gnu/libcwidget.so.3
#21 0x5568c64a in ?? ()
#22 0x555b50e0 in ?? ()
#23 0x755935f0 in __libc_start_main (main=0x555b3990, argc=1, argv=0x7fffe0b8, 
init=, fini=, rtld_fini=, 
stack_end=0x7fffe0a8) at libc-start.c:291
#24 0x555be899 in ?? ()


I think that there's a similar bug to this one in recent weeks, but I
lost track a bit due to real-life events, will try to get back to this
soon.


Cheers.
--
Manuel A. Fernandez Montecelo 

Bug#831517: ITP: u-msgpack-python -- A portable, lightweight MessagePack serializer and deserializer written in pure Python

[Orestis Ioannou]

Package: wnpp
Severity: wishlist
Owner: Orestis Ioannou 

* Package name: u-msgpack-python
  Version : 2.1
  Upstream Author : Vanya Sergeev 
* URL : ttps://github.com/vsergeev/u-msgpack-python
* License : MIT
  Programming Lang: Python
  Description : A portable, lightweight MessagePack serializer and
deserializer written in pure Python

u-msgpack-python is a lightweight MessagePack serializer and deserializer
module written in pure Python,
compatible with both Python 2 and Python 3, as well as CPython and PyPy
implementations of Python.
u-msgpack-python is fully compliant with the latest MessagePack specification.
In particular, it supports the new binary, UTF-8 string, and application-
defined ext types.

This is a dependency for crossbar

Bug#805228: Bug#806630: libnative-platform-java: FTBFS when built with dpkg-buildpackage -A (mh_installjar fails)

[tony mancill]

On 07/16/2016 01:58 PM, Santiago Vila wrote:
> On Sat, 16 Jul 2016, tony mancill wrote:
> 
>>> https://bugs.debian.org/cgi-bin/pkgreport.cgi?tag=binary-indep;users=sanv...@debian.org
>>
>> Hi Santiago,
>>
>> Thanks for the list.  For 806640, the only bug that appears in this list
>> related to mh_install 805228, I will mark it as blocked by 805228, but I
>> won't reassign.
>>
>> It might be worth noting that there are other arch:all packages that
>> FTBFS with the same mh_install issue, but don't appear in your list of
>> binary-indep packages.  Did your test build perhaps exclude packages
>> that are strictly arch:all - as compared to src:libnative-platform-java,
>> which builds both arch:any and arch:all binary packages? [...]
> 
> Yes, I have only tested packages which generate both "Arch: any" and
> "Arch: all" packages, so source packages which only generate "Arch: all"
> packages are excluded from my tests.
> 
> The reason is that those packages are already tested (and reported)
> in the reproducible builds project, so I decided to concentrate
> on packages that nobody tested.

The first two packages I tried, src:pegdown and src:libjbcrypt-java,
both appear in the "successfully built reproducibly" set here [1], and
neither has any bugs assigned to it.  Maybe I'm looking in the wrong place?

In any event, that entire class of bug (I am sure that there are other
instances) will be addressed by the resolution of 805228.

Thank you,
tony

[1]
https://tests.reproducible-builds.org/debian/unstable/amd64/pkg_set_maint_pkg-java-maintainers.html





signature.asc
Description: OpenPGP digital signature

Bug#805228: Bug#806630: libnative-platform-java: FTBFS when built with dpkg-buildpackage -A (mh_installjar fails)

[Santiago Vila]

On Sat, 16 Jul 2016, tony mancill wrote:

> > https://bugs.debian.org/cgi-bin/pkgreport.cgi?tag=binary-indep;users=sanv...@debian.org
> 
> Hi Santiago,
> 
> Thanks for the list.  For 806640, the only bug that appears in this list
> related to mh_install 805228, I will mark it as blocked by 805228, but I
> won't reassign.
> 
> It might be worth noting that there are other arch:all packages that
> FTBFS with the same mh_install issue, but don't appear in your list of
> binary-indep packages.  Did your test build perhaps exclude packages
> that are strictly arch:all - as compared to src:libnative-platform-java,
> which builds both arch:any and arch:all binary packages? [...]

Yes, I have only tested packages which generate both "Arch: any" and
"Arch: all" packages, so source packages which only generate "Arch: all"
packages are excluded from my tests.

The reason is that those packages are already tested (and reported)
in the reproducible builds project, so I decided to concentrate
on packages that nobody tested.

Thanks.

Bug#826241: [Pkg-dns-devel] Bug#826241: Bug#826241: Bug#826241: Bug#826241: Bug#826241: unbound: Provide $named facility under systemd

[Michael Biebl]

Am 16.07.2016 um 22:52 schrieb Michael Biebl:
> So, it seems to me as something resets PATH within resolvconf.
> If that is true, then this should also affect the old sysv init script
> for unbound. Is this actually still working?

That something is resolvconf itself:


$ head /sbin/resolvconf
#!/bin/sh
#
# This file is part of the resolvconf package.
#

set -e

echo_usage() { echo "Usage: resolvconf (-d IFACE|-a
IFACE|-u|--enable-updates|--disable-updates|--updates-are-enabled)" ; }

PATH=/sbin:/bin
^^^

So, afaics the current postfix hook is broken. No matter if you use
native service files for unbound or the sysv init script.


Regards,
Michael
-- 
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#831516: RM: pbbam [i386 armel mipsel] -- ROM; Antiquated and prevents testing migration

[Afif Elghraoui]

Package: ftp.debian.org
Severity: normal


The latest upload of the pbbam package has major changes, a new binary package,
and also runs a test suite. This test suite fails on 32-bit platforms,
where the original (very old version) used to be able to build.
The presence of the outdated binaries on the named architectures prevents
testing migration while upstream appears not interested in supporting them.

You might also prefer to remove the outdated binaries on the non-release
architectures for purposes of cruft removal.

Thanks and regards
Afif

Bug#826241: [Pkg-dns-devel] Bug#826241: Bug#826241: Bug#826241: Bug#826241: Bug#826241: unbound: Provide $named facility under systemd

[Michael Biebl]

Hi Robert

Am 16.07.2016 um 20:44 schrieb Robert Edmonds:

> That's weird, 'service' is in /usr/sbin… So I edited the hook script to
> print $PATH:
> 
> Jul 16 18:22:37 unbound package-helper[2484]: run-parts: executing 
> /etc/resolvconf/update-libc.d/postfix
> Jul 16 18:22:37 unbound package-helper[2484]: + echo /sbin:/bin
> Jul 16 18:22:37 unbound package-helper[2484]: /sbin:/bin
> Jul 16 18:22:37 unbound package-helper[2484]: + service postfix status
> Jul 16 18:22:37 unbound package-helper[2484]: 
> /etc/resolvconf/update-libc.d/postfix: 7: 
> /etc/resolvconf/update-libc.d/postfix: service: not found
> Jul 16 18:22:37 unbound package-helper[2484]: + exit 0

> So, 'service' is in /usr/sbin, but /usr/sbin is not in $PATH, and
> 'service' is not invoked with an absolute path. Then I edited the hook
> script to fix $PATH:

That's a bit surprising. systemd should add /usr/sbin to PATH. A minimal
test case

# cat /etc/systemd/system/env.service
[Unit]
Description="dump env"

[Service]
ExecStart=/bin/sh -c "env"

# journalctl -u env
-- Logs begin at So 2016-05-08 15:58:46 CEST, end at Sa 2016-07-16
22:46:15 CEST. --
Jul 16 22:46:15 pluto systemd[1]: Started "dump env".
Jul 16 22:46:15 pluto sh[28592]:
PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
Jul 16 22:46:15 pluto sh[28592]: LANG=en_US.UTF-8
Jul 16 22:46:15 pluto sh[28592]: PWD=/



So for some reason $PATH is reset. I wonder where that happens.
I noticed that postfix's resolvconf in jessie uses
/etc/init.d/postfix instead of service postfix, so doesn't run into this
issue.


> Anyway, this needs to be fixed before I can upload an unbound package
> with native service units. I can't upload an unbound that breaks
> postfix. Does the fix need to go in the unbound or resolvconf or postfix
> package?

So, it seems to me as something resets PATH within resolvconf.
If that is true, then this should also affect the old sysv init script
for unbound. Is this actually still working?

Regards,
Michael

-- 
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#805228: Bug#806630: libnative-platform-java: FTBFS when built with dpkg-buildpackage -A (mh_installjar fails)

[tony mancill]

On 07/16/2016 01:47 PM, tony mancill wrote:

> Thanks for the list.  For 806640, the only bug that appears in this list
> related to mh_install 805228, I will mark it as blocked by 805228, but I
> won't reassign.

Grrr sorry for the typos.  I meant 806630, and to say that I will
mark it blocked by 805228.  That's all.




signature.asc
Description: OpenPGP digital signature

Bug#805228: Bug#806630: libnative-platform-java: FTBFS when built with dpkg-buildpackage -A (mh_installjar fails)

[tony mancill]

On 07/16/2016 01:31 PM, Santiago Vila wrote:
> On Sat, 16 Jul 2016, Markus Koschany wrote:
> 
>> On 16.07.2016 18:22, tony mancill wrote:
>> [...]
>>> I'd like to discuss options with the Java Team.  For example, we could
>>> change mh_install to ignore '-i' when not passed in conjunction with a
>>> maven.ignoreRules file, or change the DH sequencer, and probably some
>>> other better options that I'm not creative enough to think of right now.
>>
>> Hi,
>>
>> I think
>>
>> https://bugs.debian.org/805228
>>
>> is the best place to discuss this issue.
> 
> Indeed.
> 
> 
> One thing that you might want to do is to identify the affected
> packages. The complete list of bugs I reported regarding
> "dpkg-buildpackage -A" is available here in case it helps:
> 
> https://bugs.debian.org/cgi-bin/pkgreport.cgi?tag=binary-indep;users=sanv...@debian.org

Hi Santiago,

Thanks for the list.  For 806640, the only bug that appears in this list
related to mh_install 805228, I will mark it as blocked by 805228, but I
won't reassign.

It might be worth noting that there are other arch:all packages that
FTBFS with the same mh_install issue, but don't appear in your list of
binary-indep packages.  Did your test build perhaps exclude packages
that are strictly arch:all - as compared to src:libnative-platform-java,
which builds both arch:any and arch:all binary packages?  Put another
way, do we need to be concerned that the strictly arch:all packages for
this binary-indep tag?

Cheers,
tony



signature.asc
Description: OpenPGP digital signature

Bug#831514: O: aspell-sl -- The Slovenian dictionary for GNU Aspell

[Tobias Frost]

Package: wnpp
Severity: normal

The current maintainer of aspell-sl, Jure Cuhalev ,
is apparently not active anymore.  Therefore, I orphan this package now.

Maintaining a package requires time and skills. Please only adopt this
package if you will have enough time and attention to work on it.

If you want to be the new maintainer, please see
https://www.debian.org/devel/wnpp/index.html#howto-o for detailed
instructions how to adopt a package properly.

Some information about this package:

Package: aspell-sl
Binary: aspell-sl
Version: 0.60-3
Maintainer: Jure Cuhalev 
Build-Depends: debhelper (>= 4.9.5), cdbs (>= 0.4.9.5), dictionaries-common-dev 
(>= 0.9.1)
Architecture: all
Standards-Version: 3.6.2
Format: 1.0
Files:
 b9e99d6f60a6574e8f6357883644ef21 620 aspell-sl_0.60-3.dsc
 2bf815167b8518594e26e1bc7726f9c3 571822 aspell-sl_0.60.orig.tar.gz
 80d5e67da97b696c5ca412b214ebe4b4 2244 aspell-sl_0.60-3.diff.gz
Checksums-Sha256:
 5777da494d98536c6820261851d0ed2d77241a7cc70c1411f1f57f10aaa95289 620 
aspell-sl_0.60-3.dsc
 80bdc13b94b8a51f77b6bcfa451b8273f2b570e7b0881f3031748ee5992b09bb 2244 
aspell-sl_0.60-3.diff.gz
 17943de3a4175d29cb0c7fea04faa0714e27c149ad02f014e58d282573519056 571822 
aspell-sl_0.60.orig.tar.gz
Directory: pool/main/a/aspell-sl
Priority: source
Section: text

Package: aspell-sl
Version: 0.60-3
Installed-Size: 652
Maintainer: Jure Cuhalev 
Architecture: all
Provides: aspell-dictionary
Depends: aspell (>= 0.60.3-3), dictionaries-common (>= 0.49.2)
Description-en: The Slovenian dictionary for GNU Aspell
 This package contains all the required files to add support
 for Slovenian language to the GNU Aspell spell checker.
 .
 Homepage: http://nl.ijs.si/GNUsl/
Description-md5: 114a71d664925b0cf1fe7b6cab38a72f
Tag: made-of::dictionary, role::app-data, suite::gnu, use::checking
Section: text
Priority: optional
Filename: pool/main/a/aspell-sl/aspell-sl_0.60-3_all.deb
Size: 563426
MD5sum: 5da8afb3d12a1aa2780207580d94ad1a
SHA256: 8f7301a6f3fd0d531ce78b19601c03745683ade6790fae33c964f542a3bcdd5e



signature.asc
Description: PGP signature

Bug#831515: ITP: sdnotify -- A pure Python implementation of systemd's service notification protocol

[Orestis Ioannou]

Package: wnpp
Severity: wishlist
Owner: Orestis Ioannou 

* Package name: sdnotify
  Version : 0.3.1
  Upstream Author : Brett Bethke 
* URL : https://github.com/bb4242/sdnotify
* License : MIT
  Programming Lang: Python
  Description : A pure Python implementation of systemd's service
notification protocol

his is a pure Python implementation of the systemd sd_notify protocol.

This protocol can be used to inform systemd about service start-up completion,
watchdog events, and other service status changes.
Thus, this package can be used to write system services in Python that play
nicely with systemd.

sdnotify is compatible with both Python 2 and Python 3.

I need this package as it is a dependency for crossbar

Bug#830805: jessie-pu: package cacti/0.8.8b+dfsg-8+deb8u4

[Adam D. Barratt]

Control: tags -1 + pending

On Fri, 2016-07-15 at 14:21 +0200, Paul Gevers wrote:
> On 12-07-16 22:46, Adam D. Barratt wrote:
> > Please go ahead.
> 
> Just uploaded to jessie-proposed-updates.

Flagged for acceptance.

Regards,

Adam

Bug#827781: jessie-pu: package lxc/1:1.0.6-6+deb8u3

[Adam D. Barratt]

Control: tags -1 + pending

On Thu, 2016-07-14 at 08:48 -0300, Antonio Terceiro wrote:
> On Tue, Jul 12, 2016 at 09:57:40PM +0100, Adam D. Barratt wrote:
> > On Wed, 2016-06-29 at 16:54 -0300, Antonio Terceiro wrote:
> > > On Tue, Jun 28, 2016 at 12:16:21PM +0200, Julien Cristau wrote:
> > [...]
> > > > Ack.  Please go ahead.
> > > 
> > > Hi, actually I was just made aware of a regression: including `init` in
> > > the package list breaks the creation of wheezy containers because `init`
> > > did not exist then. The regression was fixed in 1:2.0.1-3 just uploaded
> > > to unstable.
> > > 
> > > The updated diff is attached.
> > 
> > Please go ahead.
> 
> Just uploaded, thanks.

Flagged for acceptance.

Regards,

Adam

Bug#829650: jessie-pu: package ruby-eventmachine/1.0.3-6+deb8u1

[Adam D. Barratt]

Control: tags -1 + pending

On Tue, 2016-07-12 at 21:50 +0100, Adam D. Barratt wrote:
> Control: tags -1 + confirmed
> 
> On Tue, 2016-07-05 at 04:40 +0200, Balint Reczey wrote:
> > The Security Team suggested fixing the TEMP-0678512-2E167C [1] security
> > issue through a point release.
> > 
> > The issue is a remotely triggerable crash due to stack overflow.
> 
> Please go ahead.

Uploaded and flagged for acceptance.

Regards,

Adam

Bug#829603: jessie-pu: package conkeror/1.0~~pre-1+git141025-1+deb8u2

[Adam D. Barratt]

Control: tags -1 + pending

On Wed, 2016-07-13 at 12:00 +0200, Axel Beckert wrote:
> Hi Adam,
> 
> Adam D. Barratt wrote:
> > > Cherry-picking the according upstream fix solves the issue also in
> > > Jessie. I've prepared and tested an upload for that and would like to
> > > upload this to jessie-proposed-updates.
> > 
> > Please go ahead.
> 
> Thanks, uploaded.

Flagged for acceptance; thanks.

Regards,

Adam

Bug#825699: jessie-pu: package glibc/2.19-18+deb8u5

[Adam D. Barratt]

Control: tags -1 + pending

On Wed, 2016-07-13 at 00:45 +0200, Aurelien Jarno wrote:
> On 2016-07-12 21:33, Adam D. Barratt wrote:
> > On Wed, 2016-06-08 at 00:28 +0200, Aurelien Jarno wrote:
> > > On 2016-05-29 17:19, Adam D. Barratt wrote:
> > > > Control: tags -1 -moreinfo +confirmed
> > > > 
> > > > On Sun, 2016-05-29 at 17:53 +0200, Aurelien Jarno wrote:
> > > > 
> > > > > Can we get this into jessie-proposed-updates just after the 8.5 
> > > > > release,
> > > > > so that it doesn't happen again for 8.6? Most of these changes were
> > > > > ready in our git repository for over a month, it's just I didn't got 
> > > > > time
> > > > > this week to finish preparing the final upload.
> > > > 
> > > > That sounds like a good plan.
> > > 
> > > Now that the 8.5 release is out, I would like to upload glibc version
> > > 2.19-18+deb8u5 to jessie-proposed-updates. You will find the diff below,
> > > it only differs to the previous one by the addition of the CVE-2016-4429
> > > fix.
> > 
> > Please go ahead; apologies for the delay.
> 
> Thanks, I have just uploaded it.

Flagged for acceptance; thanks.

Regards,

Adam

Bug#806630: libnative-platform-java: FTBFS when built with dpkg-buildpackage -A (mh_installjar fails)

[Santiago Vila]

On Sat, 16 Jul 2016, tony mancill wrote:

> There are 320-odd packages that build-depend on maven-repo-helper,
> although only a subset of them will use the DH sequencer.  Still, I
> think the bug belongs there as a problem in the tool chain and not
> against all of the packages that depend on it.

Hi.

As Markus Koschany has pointed out, there is already a bug reported
specifically for that.

So, even if this is considered as a bug in maven-repo-helper, please
don't reassign the bugs to that package, because then it would be a
lot more difficult for me to track the affected packages.

Thanks.

Bug#805228: Bug#806630: libnative-platform-java: FTBFS when built with dpkg-buildpackage -A (mh_installjar fails)

[Santiago Vila]

On Sat, 16 Jul 2016, Markus Koschany wrote:

> On 16.07.2016 18:22, tony mancill wrote:
> [...]
> > I'd like to discuss options with the Java Team.  For example, we could
> > change mh_install to ignore '-i' when not passed in conjunction with a
> > maven.ignoreRules file, or change the DH sequencer, and probably some
> > other better options that I'm not creative enough to think of right now.
> 
> Hi,
> 
> I think
> 
> https://bugs.debian.org/805228
> 
> is the best place to discuss this issue.

Indeed.


One thing that you might want to do is to identify the affected
packages. The complete list of bugs I reported regarding
"dpkg-buildpackage -A" is available here in case it helps:

https://bugs.debian.org/cgi-bin/pkgreport.cgi?tag=binary-indep;users=sanv...@debian.org


Thanks.

Bug#830694: ncurses-base doesn't work with iso-8859-2 locale

[Thomas Dickey]

On Sun, Jul 10, 2016 at 03:45:39PM +0200, Mikulas Patocka wrote:
> Package: ncurses-base
> Version: 6.0+20160319-2
> Severity: normal
> Tags: l10n
> 
> Dear Maintainer,
> 
> *** Reporter, please consider answering these questions, where appropriate ***
> 
>* What led up to the situation?
> 
> Updating the ncurses-base package from 6.0+20160319-2 to 6.0+20160625-1 breaks
> the iso-8859-2 locale.
> 
> The reason for this bug is that the package 6.0+20160625-1 sends the 
> characters
> "\e(B\e)0" when initializing a full screen program. The code "\e(B" breaks the
> iso-8859-2 locale. (the locale needs "\e(K" so that it uses the alternate map,
> "\e(B" resets this setting to use the incorrect iso-8859-1 map)
> 
> The version 6.0+20160319-2 doesn't send the characters "\e(B\e)0" at
> initialization, so iso-8859-2 works there.

It's not that simple.

comparing linux2.2 to linux2.6.
comparing booleans.
comparing numbers.
comparing strings.
acsc: 
'+\020\,\021-\030.^Y0\333`\004a\261f\370g\361h\260i\316j\331k\277l\332m\300n\305o~p\304q\304r\304s_t\303u\264v\301w\302x\263y\363z\362{\343|\330}\234~\376',
 '++\,\,--..00__``aaffgghhiijjkkllmmnnooppqqrrssttuuvvwwxxyyzz{{||}c~~'.
enacs: NULL, '\E(B\E)0'.
rmacs: '\E[10m', '^O'.
sgr: 
'\E[0;10%?%p1%t;7%;%?%p2%t;4%;%?%p3%t;7%;%?%p4%t;5%;%?%p5%t;2%;%?%p6%t;1%;%?%p9%t;11%;m',
 
'\E[0;10%?%p1%t;7%;%?%p2%t;4%;%?%p3%t;7%;%?%p4%t;5%;%?%p5%t;2%;%?%p6%t;1%;m%?%p9%t\016%e\017%;'.
sgr0: '\E[0;10m', '\E[m\017'.
smacs: '\E[11m', '^N'.

The manual page console_codes states

   Character Sets
   The kernel knows about 4 translations of bytes into console-screen sym‐
   bols.  The four tables are: a) Latin1 -> PC, b) VT100 graphics  ->  PC,
   c) PC -> PC, d) user-defined.

   There  are two character sets, called G0 and G1, and one of them is the
   current character set.  (Initially G0.)  Typing ^N causes G1 to  become
   current, ^O causes G0 to become current.

   These  variables  G0  and  G1  point at a translation table, and can be
   changed by the user.  Initially they point at tables a) and b), respec‐
   tively.   The  sequences  ESC  (  B and ESC ( 0 and ESC ( U and ESC ( K
   cause G0 to point at translation table a), b), c) and d), respectively.
   The  sequences  ESC ) B and ESC ) 0 and ESC ) U and ESC ) K cause G1 to
   point at translation table a), b), c) and d), respectively.

That is, a hard reset would have the same effect, pointing G0/G1 to
the Latin1 and VT100 graphics tables.  The "reset" program does this.

Also, console_codes documents SGR:

   10  reset selected mapping, display control flag, and  toggle
   meta flag (ECMA-48 says "primary font").
   11  select null mapping, set display control flag, reset tog‐
   gle meta flag (ECMA-48 says "first alternate font").

...which is vague.  The source-code (drivers/tty/vt/vt.c) helps:

case 10: /* ANSI X3.64-1979 (SCO-ish?) 
  * Select primary font, don't display 
  * control chars if defined, don't set 
  * bit 8 on output. 
  */
vc->vc_translate = set_translate(vc->vc_charset == 0
? vc->vc_G0_charset
: vc->vc_G1_charset, vc);
vc->vc_disp_ctrl = 0;
vc->vc_toggle_meta = 0;
break;
case 11: /* ANSI X3.64-1979 (SCO-ish?) 
  * Select first alternate font, lets 
  * chars < 32 be displayed as ROM chars. 
  */
vc->vc_translate = set_translate(IBMPC_MAP, vc);
vc->vc_disp_ctrl = 1;
vc->vc_toggle_meta = 0;
break;

and

case 14:
vc->vc_charset = 1; 
vc->vc_translate = set_translate(vc->vc_G1_charset, vc);
vc->vc_disp_ctrl = 1;
return;
case 15:
vc->vc_charset = 0;
vc->vc_translate = set_translate(vc->vc_G0_charset, vc);
vc->vc_disp_ctrl = 0;
return;

It's a bit of a mess, but basically the old/new control codes don't work
together. (more later)

-- 
Thomas E. Dickey 
http://invisible-island.net
ftp://invisible-island.net


signature.asc
Description: Digital signature

Bug#806067: lilypond: FTBFS when built with dpkg-buildpackage -A (No such file or directory)

[Santiago Vila]

On Sat, 16 Jul 2016, Don Armstrong wrote:

> Control: severity -1 serious
> 
> On Thu, 14 Jul 2016, Santiago Vila wrote:
> > I have the ok from the Release Managers to consider this issue as RC
> > for stretch. I'm going to wait at least one week before raising
> > this to "serious".
> 
> I've gone ahead and made it serious anyway; the fix seems pretty simple.
> 
> Although it's kind of a silly bug for lilypond, because lilypond
> requires the architecture dependent pieces to be built before it can
> build the architecture independent package. But that's probably a fairly
> common issue for packages anyway.

You can always have build-arch and build-indep targets to depend on
the build target and have the build target to build everything.

Whether it's a common issue or not, I don't know.

After all the bugs like this one are fixed, I'd like to spend some
time to make sure packages build things efficiently regarding
"Arch: all" and "Arch: any" autobuilders, because I've seen things you
wouldn't believe:

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=829347


Thanks.

Bug#830324: Pending fixes for bugs in the libhttp-async-perl package

[pkg-perl-maintainers]

tag 830324 + pending
thanks

Some bugs in the libhttp-async-perl package are closed in revision
0cbb4940b8e7d1ef12cc7278e3b41101c2f4c3d0 in branch 'master' by gregor
herrmann

The full diff can be seen at
https://anonscm.debian.org/cgit/pkg-perl/packages/libhttp-async-perl.git/commit/?id=0cbb494

Commit message:

Add patch to disable tests which need DNS queries.

Thanks: Chris Lamb for the bug report.
Closes: #830324

Bug#831513: installation-reports: Install on Asus ZenBook UX305CA largely successful (with a workaround)

[Diederik de Haas]

Package: installation-reports
Severity: normal
Tags: d-i



-- Package-specific info:

Boot method: usb stick 
Image version: 
http://cdimage.debian.org/cdimage/stretch_di_alpha7/amd64/iso-cd/debian-stretch-DI-alpha7-amd64-netinst.iso
 retrieved on 2016-07-15
Date: 2016-07-15 05:22

Machine: Asus ZenBook UX305-CA
Partitions: 
# fdisk -l
Disk /dev/sda: 119.2 GiB, 128035676160 bytes, 250069680 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
Disklabel type: gpt
Disk identifier: 76B7BAFA-A09C-484A-B7D9-64D7A011696A

Device Start   End   Sectors  Size Type
/dev/sda1   2048534527532480  260M EFI System
/dev/sda2 534528567295 32768   16M Microsoft reserved
/dev/sda3 567296  75251711  74684416 35.6G Microsoft basic data
/dev/sda4  249047040 250068991   1021952  499M Windows recovery environment
/dev/sda5   75251712  90875903  15624192  7.5G Linux filesystem
/dev/sda6   90875904 106500095  15624192  7.5G Linux swap
/dev/sda7  106500096 249047039 142546944   68G Linux filesystem

Partition table entries are not in disk order.

/dev/sda5 and /dev/sda7 are formatted with btrfs

# df -Tl
Filesystem Type 1K-blocksUsed Available Use% Mounted on
udev   devtmpfs   4026704   0   4026704   0% /dev
tmpfs  tmpfs   8073769024798352   2% /run
/dev/sda5  btrfs  7812096 3511580   4138580  46% /
tmpfs  tmpfs  4036880  92   4036788   1% /dev/shm
tmpfs  tmpfs 5120   0  5120   0% /run/lock
tmpfs  tmpfs  4036880   0   4036880   0% /sys/fs/cgroup
/dev/sda7  btrfs 71273472 6749128  63489096  10% /home
/dev/sda1  vfat262144   20328241816   8% /boot/efi
tmpfs  tmpfs   807376   0807376   0% /run/user/110
tmpfs  tmpfs   807376  12807364   1% /run/user/1000


Base System Installation Checklist:
[O] = OK, [E] = Error (please elaborate below), [ ] = didn't try it

Initial boot:   [O]
Detect network card:[O]
Configure network:  [O]
Detect CD:  [O]
Load installer modules: [O]
Clock/timezone setup:   [O]
User/password setup:[O]
Detect hard drives: [O]
Partition hard drives:  [O]
Install base system:[O]
Install tasks:  [ ]
Install boot loader:[O]
Overall install:[O]

Comments/Problems:

This system came preloaded with the virus/malware known as Win10 and this was 
my first experience with UEFI. As I wasn't sure things would work I first 
needed to make a backup image of it which turned out to be quite a problem.
Live 'CD's like systemrescuecd and knoppix wouldn't boot (I may have done 
things incorrectly) and I finally managed to boot one, namely Ubuntu Y 
and could make the image with dd.

Then I resized the main disk to make room for Debian in Win10 as even GParted 
Live had problems with the 512/4096 logical/physical sector sizes.
So I had lots of problems before trying the Debian installation itself.

But wow, it booted into the UEFI installer straight away and most of the
installation was a breeze.
I did run into a firmware issue though for my wireless device, but that was 
due to the firmware-iwlwifi package being too old for it.
# lspci | grep -i net
01:00.0 Network controller: Intel Corporation Wireless 7265 (rev 59)
# dmesg | grep ucode
[3.508832] iwlwifi :01:00.0: firmware: direct-loading firmware 
iwlwifi-7265D-21.ucode
[3.509446] iwlwifi :01:00.0: firmware: failed to load 
iwlwifi-7265D-20.ucode (-2)
[3.509455] iwlwifi :01:00.0: Direct firmware load for 
iwlwifi-7265D-20.ucode failed with error -2
[3.509475] iwlwifi :01:00.0: firmware: failed to load 
iwlwifi-7265D-19.ucode (-2)
[3.509481] iwlwifi :01:00.0: Direct firmware load for 
iwlwifi-7265D-19.ucode failed with error -2
[3.509512] iwlwifi :01:00.0: firmware: failed to load 
iwlwifi-7265D-18.ucode (-2)
[3.509517] iwlwifi :01:00.0: Direct firmware load for 
iwlwifi-7265D-18.ucode failed with error -2
[3.531238] iwlwifi :01:00.0: firmware: direct-loading firmware 
iwlwifi-7265D-17.ucode
[3.535712] iwlwifi :01:00.0: firmware: direct-loading firmware 
iwlwifi-7265D-16.ucode

But after grabbing the -21.ucode file from the upstream git repo I could 
continue with the installation. Added my findings to 
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=808792#47
What was nice is that the ucode file was (apparently) copied to the 
installed system :-)
What could be improved was the error message that I got, which was none 
basically and just got the prompt again to provide firmware which I had 
already done, at least that's what I thought at first.
After checking one of the alternative consoles and inspecting the .deb file 
(on another computer) I realized that it didn't contain the right version 
for my device.

When I got to the stage of 

Bug#824956: Re. the Musescore situation in sid

[Fabian Greffrath]

Am Samstag, den 16.07.2016, 19:17 + schrieb Thorsten Glaser:
> I’ll compile and test it now (modulo time needed for cooking,
> eating, etc). and mail back.

Ah, whatever. It compiled fine and so I uploaded it. So users can
upgrade their sid systems. Everything else could be buffed out in a
revision -2 upload.

 - Fabian


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

Bug#825833: libkms

[Víctor M . Jáquez L .]

On 07/16/16 at 09:46pm, Julien Cristau wrote:
> On Sat, Jul 16, 2016 at 10:20:12 +0200, Víctor M. Jáquez L. wrote:
> 
> > On 07/15/16 at 10:33pm, Julien Cristau wrote:
> > > On Wed, Jul  6, 2016 at 18:46:32 +0200, ydir...@free.fr wrote:
> > > 
> > > > In fact, it looks like libkms was built in the past, but is explicitely
> > > > disabled now.  There is probably a reason for this, but there is no more
> > > > information than that in the changelog, and no README.Debian.
> > > > 
> > > > Could we please have more insight about why this decision was made ?
> > > > 
> > > libkms wasn't used/useful then, I'd need some convincing to re-enable
> > > it.
> > 
> > Perhaps it won't be useful in desktop systems or servers, but, as far as I
> > see, it is useful in embedded, if you want to draw without any display
> > server.
> > 
> > But I agree, I only have one modest example: kmssink, a simple GStreamer 
> > video
> > sink, targeted precisely to embedded systems.
> > 
> Where can I see that code?  Why can't it use libdrm directly?
> "embedded" is not an explanation.

Here's the code of gstkmssink

https://cgit.freedesktop.org/gstreamer/gst-plugins-bad/tree/sys/kms


libkms API is used mostly by the buffer allocator:

https://cgit.freedesktop.org/gstreamer/gst-plugins-bad/tree/sys/kms/gstkmsallocator.c


vmjl

Bug#810548: random crashes with hd5850

[nsa spy]

i think i have same bug, but different gpu which is amd hd5850.
crashes are rare, roughly speaking once a month but recently somewhat more 
common. crashes happen randomly but i suspect some kind of action is needed to 
crash the system like drawing web page or clicking the mouse button. when 
crashes happen it usually gets into black screen with total linux freeze, and 
log files doesn't contain anything relevant, last time i used netconsole 
(kernel logs) without anything relevant. one time screen has gone into black 
and recovered and crashed after that. one time it rebooted (though i was 
sleeping so i didn't know what was going on exactly, xscreensaver was on 
though).

this bug report exist already so i send this information but i have other 
suspects like motherboard.

Package: xserver-xorg-video-radeon
Version: 1:7.5.0-1



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

lrwxrwxrwx 1 root root 13 Oct 11  2015 /etc/X11/X -> /usr/bin/Xorg
-rwxr-xr-x 1 root root 2401376 Feb 11  2015 /usr/bin/Xorg

Diversions concerning libGL are in place

diversion of /usr/lib/arm-linux-gnueabihf/libGL.so.1.2.0 to 
/usr/lib/mesa-diverted/arm-linux-gnueabihf/libGL.so.1.2.0 by glx-diversions
diversion of /usr/lib/libGL.so.1 to /usr/lib/mesa-diverted/libGL.so.1 by 
glx-diversions
diversion of /usr/lib/arm-linux-gnueabihf/libGLESv2.so.2.0.0 to 
/usr/lib/mesa-diverted/arm-linux-gnueabihf/libGLESv2.so.2.0.0 by glx-diversions
diversion of /usr/lib/libGLESv2.so.2 to /usr/lib/mesa-diverted/libGLESv2.so.2 
by glx-diversions
diversion of /usr/lib/arm-linux-gnueabihf/libGL.so to 
/usr/lib/mesa-diverted/arm-linux-gnueabihf/libGL.so by glx-diversions
diversion of /usr/lib/x86_64-linux-gnu/libGLESv1_CM.so.1.1.0 to 
/usr/lib/mesa-diverted/x86_64-linux-gnu/libGLESv1_CM.so.1.1.0 by glx-diversions
diversion of /usr/lib/arm-linux-gnueabihf/libGLESv1_CM.so to 
/usr/lib/mesa-diverted/arm-linux-gnueabihf/libGLESv1_CM.so by glx-diversions
diversion of /usr/lib/i386-linux-gnu/libGLESv2.so.2 to 
/usr/lib/mesa-diverted/i386-linux-gnu/libGLESv2.so.2 by glx-diversions
diversion of /usr/lib/x86_64-linux-gnu/libGLESv2.so.2 to 
/usr/lib/mesa-diverted/x86_64-linux-gnu/libGLESv2.so.2 by glx-diversions
diversion of /usr/lib/arm-linux-gnueabihf/libGL.so.1.2 to 
/usr/lib/mesa-diverted/arm-linux-gnueabihf/libGL.so.1.2 by glx-diversions
diversion of /usr/lib/libGLESv1_CM.so.1.1.0 to 
/usr/lib/mesa-diverted/libGLESv1_CM.so.1.1.0 by glx-diversions
diversion of /usr/lib/i386-linux-gnu/libGLESv1_CM.so.1 to 
/usr/lib/mesa-diverted/i386-linux-gnu/libGLESv1_CM.so.1 by glx-diversions
diversion of /usr/lib/x86_64-linux-gnu/libGLESv1_CM.so to 
/usr/lib/mesa-diverted/x86_64-linux-gnu/libGLESv1_CM.so by glx-diversions
diversion of /usr/lib/arm-linux-gnueabihf/libGLESv1_CM.so.1.1.0 to 
/usr/lib/mesa-diverted/arm-linux-gnueabihf/libGLESv1_CM.so.1.1.0 by 
glx-diversions
diversion of /usr/lib/libGL.so.1.2.0 to /usr/lib/mesa-diverted/libGL.so.1.2.0 
by glx-diversions
diversion of /usr/lib/libGLESv2.so to /usr/lib/mesa-diverted/libGLESv2.so by 
glx-diversions
diversion of /usr/lib/libGL.so.1.2 to /usr/lib/mesa-diverted/libGL.so.1.2 by 
glx-diversions
diversion of /usr/lib/i386-linux-gnu/libGLESv1_CM.so.1.1.0 to 
/usr/lib/mesa-diverted/i386-linux-gnu/libGLESv1_CM.so.1.1.0 by glx-diversions
diversion of /usr/lib/x86_64-linux-gnu/libGL.so.1.2.0 to 
/usr/lib/mesa-diverted/x86_64-linux-gnu/libGL.so.1.2.0 by glx-diversions
diversion of /usr/lib/arm-linux-gnueabihf/libGLESv2.so to 
/usr/lib/mesa-diverted/arm-linux-gnueabihf/libGLESv2.so by glx-diversions
diversion of /usr/lib/libGL.so to /usr/lib/mesa-diverted/libGL.so by 
glx-diversions
diversion of /usr/lib/arm-linux-gnueabihf/libGLESv2.so.2 to 
/usr/lib/mesa-diverted/arm-linux-gnueabihf/libGLESv2.so.2 by glx-diversions
diversion of /usr/lib/x86_64-linux-gnu/libGL.so.1.2 to 
/usr/lib/mesa-diverted/x86_64-linux-gnu/libGL.so.1.2 by glx-diversions
diversion of /usr/lib/i386-linux-gnu/libGLESv2.so to 
/usr/lib/mesa-diverted/i386-linux-gnu/libGLESv2.so by glx-diversions
diversion of /usr/lib/libGLESv1_CM.so to /usr/lib/mesa-diverted/libGLESv1_CM.so 
by glx-diversions
diversion of /usr/lib/i386-linux-gnu/libGL.so.1.2.0 to 
/usr/lib/mesa-diverted/i386-linux-gnu/libGL.so.1.2.0 by glx-diversions
diversion of /usr/lib/i386-linux-gnu/libGL.so to 
/usr/lib/mesa-diverted/i386-linux-gnu/libGL.so by glx-diversions
diversion of /usr/lib/x86_64-linux-gnu/libGL.so.1 to 
/usr/lib/mesa-diverted/x86_64-linux-gnu/libGL.so.1 by glx-diversions
diversion of /usr/lib/arm-linux-gnueabihf/libGL.so.1 to 
/usr/lib/mesa-diverted/arm-linux-gnueabihf/libGL.so.1 by glx-diversions
diversion of /usr/lib/i386-linux-gnu/libGLESv2.so.2.0.0 to 
/usr/lib/mesa-diverted/i386-linux-gnu/libGLESv2.so.2.0.0 by glx-diversions
diversion of /usr/lib/libGLESv1_CM.so.1 to 
/usr/lib/mesa-diverted/libGLESv1_CM.so.1 by glx-diversions
diversion of /usr/lib/x86_64-linux-gnu/libGL.so to 

Bug#830476: Pending fixes for bugs in the libpoe-component-client-http-perl package

[pkg-perl-maintainers]

tag 830476 + pending
thanks

Some bugs in the libpoe-component-client-http-perl package are closed
in revision df38cc395ef80a7408f6d542f727861804668cc4 in branch
'master' by gregor herrmann

The full diff can be seen at
https://anonscm.debian.org/cgit/pkg-perl/packages/libpoe-component-client-http-perl.git/commit/?id=df38cc3

Commit message:

Update disable_network_tests.patch

to disable a DNS query.

Thanks: Chris Lamb for the bug report.
Closes: #830476

Bug#825833: libkms

[Julien Cristau]

On Sat, Jul 16, 2016 at 10:20:12 +0200, Víctor M. Jáquez L. wrote:

> On 07/15/16 at 10:33pm, Julien Cristau wrote:
> > On Wed, Jul  6, 2016 at 18:46:32 +0200, ydir...@free.fr wrote:
> > 
> > > In fact, it looks like libkms was built in the past, but is explicitely
> > > disabled now.  There is probably a reason for this, but there is no more
> > > information than that in the changelog, and no README.Debian.
> > > 
> > > Could we please have more insight about why this decision was made ?
> > > 
> > libkms wasn't used/useful then, I'd need some convincing to re-enable
> > it.
> 
> Perhaps it won't be useful in desktop systems or servers, but, as far as I
> see, it is useful in embedded, if you want to draw without any display
> server.
> 
> But I agree, I only have one modest example: kmssink, a simple GStreamer video
> sink, targeted precisely to embedded systems.
> 
Where can I see that code?  Why can't it use libdrm directly?
"embedded" is not an explanation.

Cheers,
Julien

Bug#757760: debian-policy: please document build profiles

[Javier Serrano Polo]

On Wed, 13 Jul 2016 07:10:16 +0200 Johannes Schauer  wrote:
> because of technical reasons?

Administrative reasons (https://bugs.debian.org/831059). I will have to
open a bug against dpkg for this issue.

(I have worked around the error in my mail server.)


smime.p7s
Description: S/MIME cryptographic signature

Bug#830354: Pending fixes for bugs in the libhttp-proxy-perl package

[pkg-perl-maintainers]

tag 830354 + pending
thanks

Some bugs in the libhttp-proxy-perl package are closed in revision
d4728472c9a6a9e82af75cacab0d159bf983a6c2 in branch 'master' by gregor
herrmann

The full diff can be seen at
https://anonscm.debian.org/cgit/pkg-perl/packages/libhttp-proxy-perl.git/commit/?id=d472847

Commit message:

Explicitly disable tests which need network access.

Thanks: Chris Lamb for the bug report.
Closes: #830354

Bug#824956: Re. the Musescore situation in sid

[Thorsten Glaser]

Fabian Greffrath dixit:

>I could do a team upload of the current state in GIT this evening.

Thanks!

>Could you confirm this is fine for uploading as it is now?

I’ll compile and test it now (modulo time needed for cooking,
eating, etc). and mail back.

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

Bug#830491: Please package new upstream release 1.12

[Julien Cristau]

On Fri, Jul  8, 2016 at 16:23:51 +0200, Michael Stapelberg wrote:

> Source: libxcb
> Severity: wishlist
> 
> It’d be great to have libxcb 1.12 in Debian for the next stable release,
> as it includes changes to support RandR 1.5, which in turn brings
> support for MST (multi-stream transport) monitors, i.e. some 4K/5K
> monitors.
> 
> Let me know if you need any help with the packaging.
> 
I seem to remember there were regressions with that release, or with the
corresponding protocol or generator changes?

Cheers,
Julien

Bug#831512: RFP: twemoji-color-font -- Twitter Color Emoji SVGinOT Font

[Pierre Rudloff]

Package: wnpp
Severity: wishlist

* Package name: twemoji-color-font
  Version : 1.1
  Upstream Author : Brad Erickson
* URL : https://github.com/eosrei/twemoji-color-font
* License : CC-BY-4.0
  Programming Lang: OpenType
  Description : Twitter Color Emoji SVGinOT Font

A color and B emoji SVGinOT font built from the Twitter Emoji for Everyone
artwork with support for ZWJ, skin tone diversity and country flags.

The font works in all operating systems, but will currently only show color
emoji in Firefox, Thunderbird and other Mozilla Gecko-based applications. This
is not a limitation of the font, but of the operating systems and applications.
Regular B outline emoji are included for backwards/fallback compatibility.

Bug#831494: t/maintscript failed all subtests during compilation

[Sven Joachim]

On 2016-07-16 18:32 +, Niels Thykier wrote:

> Control: tags -1 moreinfo unreproducible
>
> jean-christophe manciot:
>> Package: debhelper
>> 
>> Version: 9.20160709
>> 
>> kernel version: Ubuntu 16.04 4.4.0-31-generic
>> 
>> shared C library Version: 2.23-0ubuntu3
>> 
>> hardware: x86_64
>> 
>>  [...]
>> 
>> [...]
>> 
>> Test Summary Report
>> ---
>> t/maintscript (Wstat: 0 Tests: 8 Failed: 8)
>>   Failed tests:  1-8
>> t/buildsystems/parallel.mk(Wstat: 65280 Tests: 0 Failed: 0)
>>   Non-zero exit status: 255
>>   Parse errors: No plan found in TAP output
>> Files=11, Tests=599,  9 wallclock secs ( 0.09 usr  0.02 sys +  2.41 cusr
>>  0.20 csys =  2.72 CPU)
>> Result: FAIL
>> Failed 2/11 test programs. 8/599 subtests failed.
>> Makefile:104: recipe for target 'test' failed
>> make[1]: *** [test] Error 255
>> make[1]: Leaving directory
>> '/home/actionmystique/Program-Files/Ubuntu/Debhelper/git-debhelper'
>> dh_auto_test: make -j1 test returned exit code 2
>> debian/rules:14: recipe for target 'build' failed
>> make: *** [build] Error 2
>> dpkg-buildpackage: error: debian/rules build gave error exit status 2
>> 
>> *Full log*.:see below
>> Regards.
>> 
>> [...]
>
> Hi,
>
> I cannot reproduce this at all.  :-/

Neither t/maintscript nor t/buildsystems/parallel.mk are executable in
the debhelper source, so they should not be run during 'make test'.  And
I cannot reproduce this either.

I suspect that t/maintscript should actually be executable, but it never
has been.  As for t/buildsystems/parallel.mk, it is an auxiliary file.

Cheers,
   Sven

Bug#829741: pbbam: severity is important

[Afif Elghraoui]

Control: severity -1 important

I have reported this upstream, but have not gotten a response. It is not
clear that they care for 32-bit platforms. In any case, I do not think
that this bug represents a regression, because the first version
uploaded was a minimal early release. The latest uploaded version adds
much more functionality and runs a test suite that wasn't run before.

-- 
Afif Elghraoui | عفيف الغراوي
http://afif.ghraoui.name

Bug#826241: [Pkg-dns-devel] Bug#826241: Bug#826241: Bug#826241: Bug#826241: Bug#826241: unbound: Provide $named facility under systemd

[Robert Edmonds]

Michael Biebl wrote:
> Am 09.07.2016 um 23:36 schrieb Robert Edmonds:
> > But it looks like “systemctl restart unbound“ takes 90 seconds to
> > complete, though it eventually exits with return code 0. When “systemctl
> > restart unbound“ is running, I see the following initially printed to
> > the journal:
> 
> ..
> 
> > I'm not quite sure what the issue is. Any ideas? This is on an
> > up-to-date stretch VM, with these unbound packages installed:
> > 
> > https://people.debian.org/~edmonds/build/unbound/1.5.9-2/
> > 
> > along with resolvconf and postfix from testing.
> 
> 
> I did test those packages on a clean, up-to-date stretch system, where I ran
> apt install unbound resolvconf postfix
> reboot
> 
> systemctl restart unbound
> 
> That worked just fine without delay.

Hi, Michael:

It appears postfix introduced native systemd unit files in version
3.1.0-3.1, which migrated to testing a day before your email, and a few
days after mine. So you must have been testing postfix with the new unit
files, and I was testing postfix with the old sysvinit scripts. So we
were both testing on up-to-date stretch systems :-)

> So I'm unable to reproduce the problem and from my POV the packages
> would be good to go.

OK, I'll try it again.

I installed a fresh stretch VM from scratch. I have these packages
installed:

 * unreleased unbound (from p.d.o/~edmonds/build/unbound/1.5.9-2/)

 * postfix 3.1.0-3.1

 * resolvconf 1.79

I do see “systemctl restart unbound” returning instantly now, and
unbound-resolvconf.service is running and causing /etc/resolv.conf to be
updated.

However, it looks like the copy of resolv.conf inside postfix's chroot
*is not being updated*, which appears to be the whole point of postfix's
resolvconf hook. If that doesn't happen, then postfix won't have working
name resolution(!).

Here is with a freshly booted system:

root@unbound:~# stat '--format=%n: %y' /etc/resolvconf/run/resolv.conf  
/var/spool/postfix/etc/resolv.conf
/etc/resolvconf/run/resolv.conf: 2016-07-16 17:35:53.37200 +
/var/spool/postfix/etc/resolv.conf: 2016-07-16 17:35:52.98400 +
root@unbound:~# head -999 /etc/resolv.conf 
/var/spool/postfix/etc/resolv.conf
==> /etc/resolv.conf <==
# Dynamic resolv.conf(5) file for glibc resolver(3) generated by 
resolvconf(8)
# DO NOT EDIT THIS FILE BY HAND -- YOUR CHANGES WILL BE OVERWRITTEN
nameserver 127.0.0.1
search hsd1.ga.comcast.net

==> /var/spool/postfix/etc/resolv.conf <==
# Dynamic resolv.conf(5) file for glibc resolver(3) generated by 
resolvconf(8)
# DO NOT EDIT THIS FILE BY HAND -- YOUR CHANGES WILL BE OVERWRITTEN
root@unbound:~# 

It looks like postfix is starting early enough that it copies
resolv.conf into its chroot before resolv.conf has usable content, and
then when resolvconf does get updated, the postfix resolvconf hook
either isn't being invoked, or is being invoked but is not successfully
performing the copy.

Manually restarting unbound also doesn't cause postfix's copy of
resolv.conf to be updated:

root@unbound:~# systemctl restart unbound
root@unbound:~# stat '--format=%n: %y' /etc/resolvconf/run/resolv.conf  
/var/spool/postfix/etc/resolv.conf
/etc/resolvconf/run/resolv.conf: 2016-07-16 17:38:51.287627372 +
/var/spool/postfix/etc/resolv.conf: 2016-07-16 17:35:52.98400 +
root@unbound:~# head -999 /etc/resolv.conf 
/var/spool/postfix/etc/resolv.conf
==> /etc/resolv.conf <==
# Dynamic resolv.conf(5) file for glibc resolver(3) generated by 
resolvconf(8)
# DO NOT EDIT THIS FILE BY HAND -- YOUR CHANGES WILL BE OVERWRITTEN
nameserver 127.0.0.1
search hsd1.ga.comcast.net

==> /var/spool/postfix/etc/resolv.conf <==
# Dynamic resolv.conf(5) file for glibc resolver(3) generated by 
resolvconf(8)
# DO NOT EDIT THIS FILE BY HAND -- YOUR CHANGES WILL BE OVERWRITTEN
root@unbound:~# 

When I run the postfix resolvconf hook by hand, it does cause the
postfix chroot's resolv.conf to be updated:

root@unbound:~# head -999 /etc/resolv.conf 
/var/spool/postfix/etc/resolv.conf
==> /etc/resolv.conf <==
# Dynamic resolv.conf(5) file for glibc resolver(3) generated by 
resolvconf(8)
# DO NOT EDIT THIS FILE BY HAND -- YOUR CHANGES WILL BE OVERWRITTEN
nameserver 127.0.0.1
search hsd1.ga.comcast.net

==> /var/spool/postfix/etc/resolv.conf <==
# Dynamic resolv.conf(5) file for glibc resolver(3) generated by 
resolvconf(8)
# DO NOT EDIT THIS FILE BY HAND -- YOUR CHANGES WILL BE OVERWRITTEN
root@unbound:~# sh -x /etc/resolvconf/update-libc.d/postfix
+ service postfix status
+ /usr/sbin/postconf -h queue_directory
+ QUEUEDIR=/var/spool/postfix
+ [ -n /var/spool/postfix ]
+ cp /etc/resolv.conf /var/spool/postfix/etc/resolv.conf
+ service postfix reload
+ exit 0
root@unbound:~# head -999 /etc/resolv.conf 
/var/spool/postfix/etc/resolv.conf
==> 

Bug#831495: totem does not start, Aborted.

[Michael Biebl]

Am 16.07.2016 um 19:50 schrieb Kai Weber:
> ❦ Michael Biebl :
> 
>> Can you install the totem-dbgsym and related packages to get a more
>> useful backtrace.
> 
> It seems, totem-dbgsym is not available for amd64. I double checked
> https://packages.debian.org/sid/totem-dbgsym
> 
> Do I have to build it by myself? How?

They are in a separate archive:
https://wiki.debian.org/AutomaticDebugPackages




-- 
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#831227: mediawiki: fails to upgrade from 'jessie' - trying to overwrite /var/lib/mediawiki/extensions/Cite

[Jeremy Bicha]

The change you proposed is fine.

However, Breaks/Replaces is usually adequate instead of Conflicts/Replaces.

They are discussed in Chapter 7 of Debian Policy:
https://www.debian.org/doc/debian-policy/ch-relationships.html#s-conflicts

Thanks,
Jeremy Bicha

Bug#577113: includes gone orig components

[Ximin Luo]

+1, this would also be useful for bootstrapping compilers.

step 1. version 1-1, include a orig-bootstrap.tar.gz and upload this

step 2. version 1-2, don't include orig-bootstrap, and add a build-depend on 
version 1-1. But now when I run "dpkg-source -b" it will pick up orig-bootstrap 
automatically and there is no easy way to prevent this. (Yes I can rm/mv 
orig-bootstrap, but this makes it harder to rebuild version 1-1 later, e.g. to 
check the reproducibility of its build.)

I support the naming of debian/source/components and in fact I thought this 
would be a good name even before I saw this bug report. I'd suggest the 
following behaviour:

A. If debian/source/components exists with contents "$x[0]\n$x[1]\n..$x[n]\n", 
then "dpkg-source" should expect to see ../$src_$version.orig-$x[i].tar.* for i 
= [0..n], and fail if these files are not found. Any extra component files 
should be not used, but dpkg-source should simply print a warning and not fail.

B. If debian/source/components does not exist, then stick with the current 
behaviour (i.e. use all component tarballs that actually exist in the parent 
directory).

X

On Fri, 9 Apr 2010 20:08:42 +0200 Rene Engelhard  wrote:
> Package: dpkg-dev
> Version: 1.15.5.6
> Severity: normal
> 
> Hi,
> 
> openoffice.org 3.2.0-6 contains three .orig-component.tar.gzs:
> 
> - ooo-build-3-2-0-9
> - ext-sources-ooo-build-3-2-0-9
> - translation-updates-translation-updates-20100219
> 
> this matches the ooo-build 3.2.0.9 release. Now I am going to update
> to the ooo-build 3.2.0.10 release and did the following:
> 
> - create new .orig-*ooo-build-3-0-10.tar.gz
> - remove old ooo-build-3-2-0-9 in the tree
> - update debian/source/components [1]
> 
> OK, let's look what then happens when building:
> 
> (sorry, german, but should be understandable):
> 
>  dpkg-source -i -b openoffice.org-3.2.0
> dpkg-source: Information: verwende Quellformat »3.0 (quilt)«
> dpkg-source: Information: baue openoffice.org unter Benutzung des 
> existierenden 
> ./openoffice.org_3.2.0.orig-ext-sources-ooo-build-3-2-0-10.tar.gz 
> ./openoffice.org_3.2.0.orig-ext-sources-ooo-build-3-2-0-9.tar.gz 
> ./openoffice.org_3.2.0.orig-ooo-build-3-2-0-10.tar.gz 
> ./openoffice.org_3.2.0.orig-ooo-build-3-2-0-9.tar.gz 
> ./openoffice.org_3.2.0.orig-translation-updates-20100219.tar.gz 
> ./openoffice.org_3.2.0.orig.tar.gz
> [...]
> 
> It even complains about the removal of ooo-build-3-2-0-9 and that it'll
> be ignored.
> 
> So it's somehow thinking it still should include *ooo-build-3-2-0-9? Why?
> Because the .dsc of an old build references it? The dir is completely gone
> from the tree and debian/source/components does not have it either.
> 
> The only way to get a sane .changes/.dsc (ok, for upload I need to edit
> the main .orig.tar.gz out of the changes after building with -sa) is now
> to delete those files/move them away.
> 
> I think dpkg should 
>   - not think stuff should be included when the *whole toplevel dir* of
> that component is gone
>   - maybe honour debian/source/components [1]
> except of grabbing not used tarballs anymore.
> 
> Regards,
> 
> Rene
> 
> [1] Yes, I know debian/source/components is not officially handled by dpkg. 
> But
> I added it in the thought that it was (and I needed a file where the names
> are recorded anyways). In this case it'd have immensively helped if dpkg
> knew it though because then dpkg can be sure that everything what *should*
> be included is mentioned in that file.
> 
> -- System Information:
> Debian Release: squeeze/sid
>   APT prefers unstable
>   APT policy: (500, 'unstable'), (1, 'experimental')
> Architecture: amd64 (x86_64)

-- 
GPG: ed25519/56034877E1F87C35
GPG: rsa4096/1318EFAC5FBBDBCE
https://github.com/infinity0/pubkeys.git

Bug#830985: tulip: error while loading shared libraries: libbfd-2.26-system.so

[Yuri D'Elia]

On Sat, Jul 16 2016, ydir...@free.fr wrote:
>> Seems like tulip depends on libbfd-2.26-system.so, but only
>> libbfd-2.26-system.so.1 is available on my system.
>
> You mean "libbfd-2.26.1-system.so", right ?

Indeed, just a typo in my part.

Bug#831494: [debhelper-devel] Bug#831494: t/maintscript failed all subtests during compilation

[Niels Thykier]

Control: tags -1 moreinfo unreproducible

jean-christophe manciot:
> Package: debhelper
> 
> Version: 9.20160709
> 
> kernel version: Ubuntu 16.04 4.4.0-31-generic
> 
> shared C library Version: 2.23-0ubuntu3
> 
> hardware: x86_64
> 
>   [...]
> 
> [...]
> 
> Test Summary Report
> ---
> t/maintscript (Wstat: 0 Tests: 8 Failed: 8)
>   Failed tests:  1-8
> t/buildsystems/parallel.mk(Wstat: 65280 Tests: 0 Failed: 0)
>   Non-zero exit status: 255
>   Parse errors: No plan found in TAP output
> Files=11, Tests=599,  9 wallclock secs ( 0.09 usr  0.02 sys +  2.41 cusr
>  0.20 csys =  2.72 CPU)
> Result: FAIL
> Failed 2/11 test programs. 8/599 subtests failed.
> Makefile:104: recipe for target 'test' failed
> make[1]: *** [test] Error 255
> make[1]: Leaving directory
> '/home/actionmystique/Program-Files/Ubuntu/Debhelper/git-debhelper'
> dh_auto_test: make -j1 test returned exit code 2
> debian/rules:14: recipe for target 'build' failed
> make: *** [build] Error 2
> dpkg-buildpackage: error: debian/rules build gave error exit status 2
> 
> *Full log*.:see below
> Regards.
> 
> [...]

Hi,

I cannot reproduce this at all.  :-/

Do you have a non-standard build-environment?  What versions of the
various tools (e.g. perl and make) are in your PATH?

Thanks,
~Niels

Bug#806067: lilypond: FTBFS when built with dpkg-buildpackage -A (No such file or directory)

[Don Armstrong]

Control: severity -1 serious

On Thu, 14 Jul 2016, Santiago Vila wrote:
> I have the ok from the Release Managers to consider this issue as RC
> for stretch. I'm going to wait at least one week before raising
> this to "serious".

I've gone ahead and made it serious anyway; the fix seems pretty simple.

Although it's kind of a silly bug for lilypond, because lilypond
requires the architecture dependent pieces to be built before it can
build the architecture independent package. But that's probably a fairly
common issue for packages anyway.

[It won't be fixed for a while in unstable, because the current stable
release of lilypond requires a version of guile which is no longer
included in the archive. Hopefully a newer stable release of lilypond
will be made before we freeze for squeeze.]

-- 
Don Armstrong  https://www.donarmstrong.com

Herodotus says, "Very few things happen at the right time, and the
rest do not happen at all. The conscientious historian will correct
these defects".
 -- Mark Twain _A Horse's Tail_

Bug#831348: procps: includes /bin/kill.procps/kill on kfreebsd

[Sven Joachim]

On 2016-07-16 19:11 +0100, Steven Chamberlain wrote:

> Sven Joachim wrote:
>> Attached is a patch which should fix that.  I am fairly confident that
>> it works, but as I don't have a kfreebsd system it is not tested.
>
> I've tested this from procps Git, but currently not working:
>
> | mkdir /home/steven/procps/debian/tmp/bbin
> | mv /home/steven/procps/debian/tmp/bin/kill 
> /home/steven/procps/debian/tmp/bbin/
> | mv /home/steven/procps/debian/tmp/bin/ps 
> /home/steven/procps/debian/tmp/bbin/
> | # Rename w as there are two of them
> | (cd /home/steven/procps/debian/tmp/bin && mv w w.procps )
> | (cd /home/steven/procps/debian/tmp/usr/share/man/man1 && mv w.1 w.procps.1 )
> | rm -f \
> | /home/steven/procps/debian/tmp/bin/slabtop \
> | /home/steven/procps/debian/tmp/usr/share/man/man1/slabtop.1 \
> | /home/steven/procps/debian/tmp/sbin/sysctl \
> | /home/steven/procps/debian/tmp/usr/share/man/man8/sysctl.8 \
> | /home/steven/procps/debian/tmp/usr/share/man/man5/sysctl.conf.5 \
> | 
> | (cd /home/steven/procps/debian/tmp/bin && mv kill kill.procps )
> | mv: cannot stat ‘kill’: No such file or directory
> | debian/rules:44: recipe for target 'override_dh_auto_install' failed
> | make[1]: *** [override_dh_auto_install] Error 1
> | make[1]: Leaving directory '/home/steven/procps'
> | debian/rules:24: recipe for target 'binary-arch' failed
> | make: *** [binary-arch] Error 2
>
> $ ls debian/tmp/bin
> free   pkill  pwdx   snice  top vmstat  w.procps
> pgrep  pmap   skill  tload  uptime  watch
>
> $ ls debian/tmp/bbin
> kill  ps

Thanks for testing!  The attached patch should take care of this.

Cheers,
   Sven

>From 5c2293e8a2e8b3e1611bcf3a57f2ab3abccebf3c Mon Sep 17 00:00:00 2001
From: Sven Joachim 
Date: Sat, 16 Jul 2016 20:23:34 +0200
Subject: [PATCH] Fix renaming kill and ps in debian/rules

Thanks to Steven Chamberlain for noticing this.
---
 debian/rules | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/debian/rules b/debian/rules
index 0414541..82f9a9e 100755
--- a/debian/rules
+++ b/debian/rules
@@ -61,7 +61,7 @@ ifneq ($(DEB_HOST_ARCH_OS), linux)
 		$(NULL)
 
 # Rename kill as there are two of them
-	(cd $(DEBROOT)/bin && mv kill kill.procps )
+	(cd $(DEBROOT)/bbin && mv kill kill.procps )
 	(cd $(DEBROOT)/usr/share/man/man1 && mv kill.1 kill.procps.1 )
 endif
 ifeq ($(DEB_HOST_ARCH_OS), hurd)
@@ -79,7 +79,7 @@ ifeq ($(DEB_HOST_ARCH_OS), hurd)
 	(cd $(DEBROOT)/usr/share/man/man1 && mv uptime.1 uptime.procps.1 )
 
 	# Rename ps as there are two of them
-	(cd $(DEBROOT)/bin && mv ps ps.procps )
+	(cd $(DEBROOT)/bbin && mv ps ps.procps )
 	(cd $(DEBROOT)/usr/share/man/man1 && mv ps.1 ps.procps.1 )
 endif
 
-- 
2.8.1

Bug#831511: cryptsetup fails to unlock volumes with accented letters passwords

[André Cardoso]

Source: cryptsetup
Severity: important

Dear Maintainer,

During the installation process of setting up my operating system, I
chose as the default keyboard layout the Portuguese (Brazilian), then
set up the encryption of disk volumes and then set an encryption
password using accented characters.

After the initial boot was presented the prompt "Please unlock disk
sda1_crypt:"

Then I typed my password and received the following message: "cryptseup:
cryptsetup failed, bad password or option?". So I ended up locked out
of the operating system.

To solve the problem, I had to re-install Debian Jessie and set a
cryptographic password without accented characters and then managed to
unlock the encrypted volume.



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

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

Bug#753492: refcard: Typo, wording and item updates

[Guillem Jover]

Hi!

On Wed, 2014-07-02 at 16:03:51 +0200, Guillem Jover wrote:
> Source: refcard
> Source-Version: 5.0.9
> Severity: wishlist
> Tags: patch

> Here's a patch, which fixes a typo, makes the Debian distribution
> references system-neutral now that we have other non-GNU/Linux released
> architectures (although the ip command is Linux-specific), and switches
> the debsums item to use the new native «dpkg -V».

> (The  still has system
> specific references to Debian GNU/Linux.)

The typo fix got fixed independently now. The reset still applies, and
I've split it into logical patches, and added some more corrections,
namely:

 * Switch URLs to new canonical addresses and https.
 * Update apt frontend command usage.

> Note that I've not build-tested it, as the Build-Depends where quite big.

This still applies.

> And sorry for bundling this in a single patch, but splitting it with svn
> is rather painful, but I could do that if you wanted though.

And for this I ended up using git-svn. :)

Thanks,
Guillem
From a2862d4582af7737771d8ce46028b9fb1a1b2175 Mon Sep 17 00:00:00 2001
From: Guillem Jover 
Date: Thu, 10 Mar 2016 01:30:42 +0100
Subject: [PATCH 1/4] Use Debian instead of kernel specific references

---
 entries.dbk |  8 +++-
 refcard.dbk | 11 +--
 2 files changed, 8 insertions(+), 11 deletions(-)

diff --git a/entries.dbk b/entries.dbk
index 9dc1c49..1ee125c 100644
--- a/entries.dbk
+++ b/entries.dbk
@@ -2,13 +2,11 @@
 http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd;>
 
-  
-  DebianGNU/Linux Reference Card
+  
+  Debian Reference Card
   
-  The 101 most important things when using Debian
-  GNU/Linux
+  The 101 most important things when using Debian
   
 
   2004
diff --git a/refcard.dbk b/refcard.dbk
index ec7de0b..bbf8d01 100644
--- a/refcard.dbk
+++ b/refcard.dbk
@@ -2,9 +2,8 @@
 http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd;>
 
-  DebianGNU/Linux Reference Card
-  The 101 most important things when using Debian
-  GNU/Linux
+  Debian Reference Card
+  The 101 most important things when using Debian
   
 
   
 
   The idea of this reference card is to provide new users of
-  Debian GNU/Linux with the most important commands.  Basic (or
+  Debian with the most important commands.  Basic (or
   better) knowledge of computers, files, directories and the
   command line is required.  Some acronyms related to Debian
-  GNU/Linux can be found here.
+  can be found here.
 
   
   
@@ -985,7 +984,7 @@
 
   
   
-Acronyms related to Debian GNU/Linux
+Acronyms related to Debian
 
 
   From aa570a0d43e614ace96a37e6af7f07d6fd618698 Mon Sep 17 00:00:00 2001
From: Guillem Jover 
Date: Thu, 10 Mar 2016 01:30:52 +0100
Subject: [PATCH 2/4] List dpkg -V instead of debsums

This option appearing in dpkg 1.17.2, present in Debian jessie.
---
 entries.dbk | 9 +
 1 file changed, 5 insertions(+), 4 deletions(-)

diff --git a/entries.dbk b/entries.dbk
index 1ee125c..bbfcdde 100644
--- a/entries.dbk
+++ b/entries.dbk
@@ -502,10 +502,11 @@
 	pkg.deb
 	Install package files.
   
-  
-	debsums
-	Audit check sums of installed packages, needs
-	debsums.
+  
+	dpkg -V
+	names
+	Audit check sums of installed
+	packages.
   
   
 	dpkg-divert options
-- 
2.8.1

From d2af06a10dbfe5e1853b145b1a631f2c1d6db112 Mon Sep 17 00:00:00 2001
From: Guillem Jover 
Date: Thu, 10 Mar 2016 01:30:55 +0100
Subject: [PATCH 3/4] Update links

Switch http: to https:, remove dead links, and update VCS links to
canonical URLs.
---
 dblatex.xsl|  2 +-
 debian/control |  4 ++--
 entries.dbk| 32 
 refcard.dbk| 11 ---
 4 files changed, 23 insertions(+), 26 deletions(-)

diff --git a/dblatex.xsl b/dblatex.xsl
index 671c41e..1d1e1c4 100644
--- a/dblatex.xsl
+++ b/dblatex.xsl
@@ -100,7 +100,7 @@
 {\scriptsize \DBKcopyright \\
 
-: \url{http://www.debian.org/doc/user-manuals#refcard}};
+: \url{https://www.debian.org/doc/user-manuals#refcard}};
 \end{minipage}
   
 
diff --git a/debian/control b/debian/control
index 08737e4..6835d61 100644
--- a/debian/control
+++ b/debian/control
@@ -31,8 +31,8 @@ Build-Depends: cdbs,
xmlroff,
xsltproc
 Vcs-Svn: svn://anonscm.debian.org/ddp/manuals/trunk/refcard
-Vcs-Browser: http://anonscm.debian.org/viewvc/ddp/manuals/trunk/refcard/
-Homepage: http://www.debian.org/doc/user-manuals#refcard
+Vcs-Browser: https://anonscm.debian.org/viewvc/ddp/manuals/trunk/refcard/
+Homepage: https://www.debian.org/doc/user-manuals#refcard
 
 Package: debian-refcard
 Architecture: all
diff --git a/entries.dbk b/entries.dbk
index bbfcdde..4affe22 100644
--- a/entries.dbk
+++ b/entries.dbk
@@ -25,7 +25,7 @@
 
   This document may be used under the terms of the GNU General
   Public License version 3 or 

Bug#831348: procps: includes /bin/kill.procps/kill on kfreebsd

[Steven Chamberlain]

Hi,

Sven Joachim wrote:
> Attached is a patch which should fix that.  I am fairly confident that
> it works, but as I don't have a kfreebsd system it is not tested.

I've tested this from procps Git, but currently not working:

| mkdir /home/steven/procps/debian/tmp/bbin
| mv /home/steven/procps/debian/tmp/bin/kill 
/home/steven/procps/debian/tmp/bbin/
| mv /home/steven/procps/debian/tmp/bin/ps /home/steven/procps/debian/tmp/bbin/
| # Rename w as there are two of them
| (cd /home/steven/procps/debian/tmp/bin && mv w w.procps )
| (cd /home/steven/procps/debian/tmp/usr/share/man/man1 && mv w.1 w.procps.1 )
| rm -f \
|   /home/steven/procps/debian/tmp/bin/slabtop \
|   /home/steven/procps/debian/tmp/usr/share/man/man1/slabtop.1 \
|   /home/steven/procps/debian/tmp/sbin/sysctl \
|   /home/steven/procps/debian/tmp/usr/share/man/man8/sysctl.8 \
|   /home/steven/procps/debian/tmp/usr/share/man/man5/sysctl.conf.5 \
|   
| (cd /home/steven/procps/debian/tmp/bin && mv kill kill.procps )
| mv: cannot stat ‘kill’: No such file or directory
| debian/rules:44: recipe for target 'override_dh_auto_install' failed
| make[1]: *** [override_dh_auto_install] Error 1
| make[1]: Leaving directory '/home/steven/procps'
| debian/rules:24: recipe for target 'binary-arch' failed
| make: *** [binary-arch] Error 2

$ ls debian/tmp/bin
free   pkill  pwdx   snice  top vmstat  w.procps
pgrep  pmap   skill  tload  uptime  watch

$ ls debian/tmp/bbin
kill  ps

Regards,
-- 
Steven Chamberlain
ste...@pyro.eu.org


signature.asc
Description: Digital signature

Bug#831510: gnupg2: Deletes pub keyring

[Kurt Roeckx]

Package: gnupg2
Version: 2.1.11-7
Severity: important

Hi,

I was running --refresh-keys, I pressed ^C, I tried to start it
again, and I get:
gpg: signal Interrupt caught ... exiting

kurt@intrepid:~$ gpg2 --refresh-keys
gpg: keybox '/home/kurt/.gnupg/pubring.kbx' created

And of course my pubring.gpg didn't exist anymore.

I've had this happen to me several times (with gnupg 1.x too) over
the years, and it's of course not reproducable.  In this case I
still had a .tmp file I could restore from.


Kurt

Bug#831509: cryptsetup fails to unlock volumes with accented letters passwords

[Andre]

Source: cryptsetup
Severity: important

Dear Maintainer,

During the installation process of setting up my operating system, I
chose as the default keyboard layout the Portuguese (Brazilian), then
set up the encryption of disk volumes and then set an encryption
password using accented characters.

After the initial boot was presented the prompt "Please unlock disk
sda1_crypt:"

Then I typed my password and received the following message: "cryptseup:
cryptsetup failed, bad password or option?". So I ended up locked out
of the operating system.

To solve the problem, I had to re-install Debian Jessie and set a
cryptographic password without accented characters and then managed to
unlock the encrypted volume.



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

Kernel: Linux 3.16.0-4-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8)

Bug#831396: procps: [ps] fails on kfreebsd

[Steven Chamberlain]

Hello,

I'm glad you both managed to figure out the cause of this...
sorry for not filing a bug about it already.

Carsten Leonhardt wrote:
> $ more /proc/sys/kernel/osrelease
> 2.6.32

This affects sid (kfreebsd 10.3) but not older kernel versions.

Note that as a quick workaround you can set this on 10.3:
# sysctl -w compat.linux.osrelease=2.6.16

Regards,
-- 
Steven Chamberlain
ste...@pyro.eu.org


signature.asc
Description: Digital signature

Bug#831495: totem does not start, Aborted.

[Kai Weber]

❦ Michael Biebl :

> Can you install the totem-dbgsym and related packages to get a more
> useful backtrace.

It seems, totem-dbgsym is not available for amd64. I double checked
https://packages.debian.org/sid/totem-dbgsym

Do I have to build it by myself? How?

> Since we didn't have any recent updates of totem, I wonder if it's
> related to some other package upgrades, like gstreamer.

It's my guess as well, but I have no idea when it started exactly,
sometime last week July, 11th to 14th. I had no upgrade of gstreamer
last week. The candidate I had in mind was libglib but I just upgraded
to experimental version 2.49.2-2 and it did not solve the problem.

Thanks, Kai