Bug#614296: xserver-xorg-video-intel: additional rendering corruption (screenshot included)

[Luke Kenneth Casson Leighton]

On Sat, Feb 25, 2017 at 3:54 AM, Luke Kenneth Casson Leighton
 wrote:
> is linux-kernel driver-related.  4.9.6 problem is gone.  bug may be closed.

 darn it, sorry - no it can't: bug is still present, encountered on
xpdf and gerbv.  rendering still corrupted and requires multiple
refreshes or attempts.

l.

Bug#261929: Can't use tasksel to install multi l10n tasks

[Anthony Wong]

Hi all,

This is my first attempt to implement this feature. The attached patch
adds a second screen and lists all l10n tasks in a flat list. Any
comments welcome!

Currently the patch does not take into account additional locales
chosen at localechooser. I haven't looked into how to do this yet but
can add it later.

Besides, if the system does not have the locales for the chosen l10n
tasks, or the user has not selected these locales in localechooser,
should we generate these locales for them?

Thanks,
Anthony
From 827842491bbef166e46a7d0e898477b974c22484 Mon Sep 17 00:00:00 2001
From: Anthony Wong 
Date: Sat, 25 Feb 2017 01:30:56 -0500
Subject: [PATCH] Add a second screen for choosing language tasks.

This is a first stab on bug#261929.

Signed-off-by: Anthony Wong 
---
 debian/templates |  7 +++
 tasksel.pl   | 28 
 tests/lang   |  6 +++---
 3 files changed, 34 insertions(+), 7 deletions(-)

diff --git a/debian/templates b/debian/templates
index afb6efa0..1344a2cc 100644
--- a/debian/templates
+++ b/debian/templates
@@ -23,3 +23,10 @@ Description: This can be preseeded to override the default desktop.
 Template: tasksel/title
 Type: title
 _Description: Software selection
+
+Template: tasksel/l10n
+Type: multiselect
+Choices-C: ${CHOICES_C}
+Choices: ${CHOICES}
+_Description: Choose languages to install:
+ You can choose to install one or more of the following languages.
diff --git a/tasksel.pl b/tasksel.pl
index 799c0417..f7d4e3ff 100755
--- a/tasksel.pl
+++ b/tasksel.pl
@@ -457,6 +457,7 @@ sub getopts {
 
 sub interactive {
 	my $options = shift;
+	my $page = shift;
 	my @tasks = @_;
 
 	if (! $options->{"new-install"}) {
@@ -464,6 +465,13 @@ sub interactive {
 		map { $_->{_install} = 0 } grep { $_->{_display} == 0 } @tasks;
 	}
 
+	if ($page == 0) {
+		map { $_->{_display} = 0 } grep { $_->{section} eq "l10n" } @tasks;
+	} elsif ($page == 1) {
+		map { $_->{_display} = 1 } grep { $_->{section} eq "l10n" } @tasks;
+		map { $_->{_display} = 0 } grep { $_->{section} ne "l10n" } @tasks;
+	}
+
 	my @list = order_for_display(grep { $_->{_display} == 1 } @tasks);
 	if (@list) {
 		if (! $options->{"new-install"}) {
@@ -478,7 +486,12 @@ sub interactive {
 			# installs.
 			map { $_->{_installed} = 0 } @list;
 		}
-		my $question="tasksel/tasks";
+		my $question;
+		if ($page == 0) {
+			$question="tasksel/tasks";
+		} elsif ($page == 1) {
+			$question="tasksel/l10n";
+		}
 		if ($options->{"new-install"}) {
 			$question="tasksel/first";
 		}
@@ -609,8 +622,7 @@ sub main {
 
 	# This is relatively expensive, get the full list of available tasks and
 	# mark them.
-	my @tasks=map { hide_enhancing_tasks($_) } map { task_test($_, $options{"new-install"}, 1, 0) }
-	  grep { task_avail($_) } all_tasks();
+	my @tasks = map { hide_enhancing_tasks($_) } map { task_test($_, $options{"new-install"}, 1, 0) } grep { task_avail($_) } all_tasks();
 	
 	if ($options{"list-tasks"}) {
 		map { $_->{_installed} = task_installed($_) } @tasks;
@@ -627,12 +639,20 @@ sub main {
 		@tasks_remove = map { name_to_task($_, @tasks) } @{$options{cmd_remove}};
 	}
 	else {
-		interactive(\%options, @tasks);
+		my @tasks_copy = @tasks;
+		interactive(\%options, 0, @tasks);
 
 		# Add tasks to install
 		@tasks_install = grep { $_->{_install} } @tasks;
 		# Add tasks to remove
 		@tasks_remove = grep { $_->{_remove} } @tasks;
+
+		@tasks = @tasks_copy;
+		interactive(\%options, 1, @tasks);
+		# Add tasks to install
+		@tasks_install = (grep { $_->{_install} } @tasks, @tasks_install);
+		# Add tasks to remove
+		@tasks_remove = (grep { $_->{_remove} } @tasks, @tasks_remove);
 	}
 
 	my @cmd;
diff --git a/tests/lang b/tests/lang
index 243b9cc0..20b96edb 100755
--- a/tests/lang
+++ b/tests/lang
@@ -10,10 +10,10 @@ if [ "$NEW_INSTALL" ]; then
 		if ( [ -n "$LANG" ] && [ "$LANG" = "$locale" ] ) || \
 		   ( [ -n "$fulllang" ] && [ "$fulllang" = "$locale" ] ) || \
 		   ( [ -n "$baselang" ] && [ "$baselang" = "$locale" ] ); then
-		   exit 0 # install without display
+		   exit 2 # always display
 		fi
 	done
-	exit 1 # do not display
+	exit 3 # always display
 else
-	exit 1
+	exit 3 # always display
 fi
-- 
2.11.0

Bug#856050: unblock: pkgconf/0.9.12-3

[Niels Thykier]

Control: tags -1 moreinfo

Andrew Shadura:
> Package: release.debian.org
> Severity: normal
> User: release.debian@packages.debian.org
> Usertags: unblock
> 
> Please unblock package pkgconf.
> 
> Since pkg-config (= 0.29-1), pkg-config package provides
> /usr/bin/$DEB_HOST_GNU_TYPE-pkg-config symlinks as explained in #842529.
> Build tools already expect those symlinks in place, which causes random build
> failures when pkgconf is pulled instead of pkg-config.
> 
> This upload fixes the issue by syncing cross-wrapper from pkg-config,
> adopting dpkg hook from pkg-config and preventing pkg-config from being
> co-installed with pkgconf:
> 
> [...]
> 
> Thanks.
> 
> unblock pkgconf/0.9.12-3
> 
> 

Hi,

Thanks for providing this fix.

I got one question about the "Breaks".  Why Breaks and why a versioned
breaks rather than an unconditional Conflicts?  AFAICT, pkgconf attempts
to be an "mutually exclusive alternative" to pkg-config (a la exim vs.
postfix).

Thanks,
~Niels

Bug#856040: unblock: syncevolution/1.5.2-2

[Niels Thykier]

Control: tags -1 confirmed

Tino Mettler:
> Package: release.debian.org
> Severity: normal
> User: release.debian@packages.debian.org
> Usertags: unblock
> 
> Please unblock package syncevolution
> 
> It was discovered that the DBus activation of syncevo-dbus-server doesn't
> work anymore. This totally breaks sync-ui, also also automatic background
> syncs, as syncevo-dbus-server is never started.
> 
> The fix is trivial, as it just adds a file which was introduced in the
> 1.5.2 upstream release, but not included in the 1.5.2-1 package.
> 
> The corresponding bug is #854941.
> 
> unblock syncevolution/1.5.2-2
> 
> [...]

Ack, please go ahead.

~Niels

Bug#856071: unblock repo/1.12.37-2

[Niels Thykier]

Control: tags -1 confirmed

Hans-Christoph Steiner:
> Package: release.debian.org
> Severity: normal
> User: release.debian@packages.debian.org
> Usertags: unblock
> 
> Please unblock package: repo
> 
> This moves the package from main to contrib, due to a violation in
> Policy 2.2.1:
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=855846
> 
> unblock repo/1.12.37-2
> 
> Here's the diff
> 
> [...]
> 

Ack, please go ahead.

~Niels

Bug#856108: surfraw: most elvi use insecure URLs

[Adam Borowski]

Package: surfraw
Version: 2.2.9-1
Severity: normal


Hi!
All elvi point to http URLs, and at most sometimes allow an option to use
"experimental" SSL support with an old URL, such as wikipedia:
https://secure.wikimedia.org/wikipedia/$LANG/w/index.php?search=%s=Go
instead of https://$LANG.wikipedia.org/wiki/%s

I've checked ~10 at random, all of them not only support https as the
primary URL but even redirect http to https.

Thus, giving the query over http is strictly harmful: it allows an attacker
to spy on and/or redirect your queries, slows down the connection (there's
the redirect first) and gives no benefit in case either your browser or the
server has SSL problems, as the redirect will block access to http anyway.

So, please switch all sites to https.

Bug#856107: libqt5widgets5: Qmapshack crashed after manipulating tracks

[rbit]

Package: libqt5widgets5
Version: 5.7.1+dfsg-3+b1
Severity: normal
Tags: d-i

Dear Maintainer,

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

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

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


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

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

Versions of packages libqt5widgets5 depends on:
ii  libc62.24-9
ii  libqt5core5a [qtbase-abi-5-7-1]  5.7.1+dfsg-3+b1
ii  libqt5gui5   5.7.1+dfsg-3+b1
ii  libstdc++6   6.3.0-6

libqt5widgets5 recommends no packages.

libqt5widgets5 suggests no packages.

-- no debconf information
 
I use a selfcompiled version of QMS 1.7.2 with Debian Linux "Testing".

If I change a track > right click on the track in data > rework > style
  > source > altitude

QMS crashed. 


I compiled with Debug option and use gdb

Output gdb bt:

0x73d82f0f in  () from
/usr/lib/x86_64-linux-gnu/libQt5Widgets.so.5
(gdb) bt
#0  0x73d82f0f in ?? () from
/usr/lib/x86_64-linux-gnu/libQt5Widgets.so.5
#1  0x7fffd69a63a6 in ?? () from
/usr/lib/x86_64-linux-gnu/libQt5XcbQpa.so.5
#2  0x73dc23c0 in QListView::selectionChanged(QItemSelection
const&, QItemSelection const&) ()
from /usr/lib/x86_64-linux-gnu/libQt5Widgets.so.5
#3  0x73d9c721 in ?? () from
/usr/lib/x86_64-linux-gnu/libQt5Widgets.so.5
#4  0x732945e9 in QMetaObject::activate(QObject*, int, int,
void**) () from /usr/lib/x86_64-linux-gnu/libQt5Core.so.5
#5  0x73217be7 in
QItemSelectionModel::selectionChanged(QItemSelection const&,
QItemSelection const&) ()
from /usr/lib/x86_64-linux-gnu/libQt5Core.so.5
#6  0x7321c44b in
QItemSelectionModel::emitSelectionChanged(QItemSelection const&,
QItemSelection const&) ()
from /usr/lib/x86_64-linux-gnu/libQt5Core.so.5
#7  0x7321ff92 in QItemSelectionModel::select(QItemSelection
const&, QFlags) ()
from /usr/lib/x86_64-linux-gnu/libQt5Core.so.5
#8  0x7321997c in QItemSelectionModel::select(QModelIndex
const&, QFlags) ()
from /usr/lib/x86_64-linux-gnu/libQt5Core.so.5
#9  0x73218034 in
QItemSelectionModel::setCurrentIndex(QModelIndex const&,
QFlags) ()
from /usr/lib/x86_64-linux-gnu/libQt5Core.so.5
#10 0x73c51f91 in QComboBox::showPopup() () from
/usr/lib/x86_64-linux-gnu/libQt5Widgets.so.5
#11 0x73c52cf5 in  () from
/usr/lib/x86_64-linux-gnu/libQt5Widgets.so.5
#12 0x73b93bef in QWidget::event(QEvent*) () from
/usr/lib/x86_64-linux-gnu/libQt5Widgets.so.5
#13 0x73c4ee16 in QComboBox::event(QEvent*) () from
/usr/lib/x86_64-linux-gnu/libQt5Widgets.so.5
#14 0x73b4bb8c in QApplicationPrivate::notify_helper(QObject*,
QEvent*) () from /usr/lib/x86_64-linux-gnu/libQt5Widgets.so.5
#15 0x73b541fd in QApplication::notify(QObject*, QEvent*) ()
from /usr/lib/x86_64-linux-gnu/libQt5Widgets.so.5
#16 0x732689e0 in QCoreApplication::notifyInternal2(QObject*,
QEvent*) () from /usr/lib/x86_64-linux-gnu/libQt5Core.so.5
#17 0x73b528ad in QApplicationPrivate::sendMouseEvent(QWidget*,
QMouseEvent*, QWidget*, QWidget*, QWidget**, QPointer&, bool)
() from /usr/lib/x86_64-linux-gnu/libQt5Widgets.so.5
#18 0x73bad906 in  () from
/usr/lib/x86_64-linux-gnu/libQt5Widgets.so.5
#19 0x73bb0313 in  () from
/usr/lib/x86_64-linux-gnu/libQt5Widgets.so.5
#20 0x73b4bb8c in QApplicationPrivate::notify_helper(QObject*,
QEvent*) () from /usr/lib/x86_64-linux-gnu/libQt5Widgets.so.5
#21 0x73b53341 in QApplication::notify(QObject*, QEvent*) ()
from /usr/lib/x86_64-linux-gnu/libQt5Widgets.so.5
#22 0x732689e0 in QCoreApplication::notifyInternal2(QObject*,
QEvent*) () from /usr/lib/x86_64-linux-gnu/libQt5Core.so.5
#23 0x735b0b03 in
QGuiApplicationPrivate::processMouseEvent(QWindowSystemInterfacePrivate::Mou
seEvent*) ()
from /usr/lib/x86_64-linux-gnu/libQt5Gui.so.5
#24 0x735b2685 in
QGuiApplicationPrivate::processWindowSystemEvent(QWindowSystemInterfacePriva
te::WindowSystemEvent*) ()
from /usr/lib/x86_64-linux-gnu/libQt5Gui.so.5
#25 0x7359061b in
QWindowSystemInterface::sendWindowSystemEvents(QFlags) ()
from /usr/lib/x86_64-linux-gnu/libQt5Gui.so.5
#26 0x7fffd69894c0 in  () from
/usr/lib/x86_64-linux-gnu/libQt5XcbQpa.so.5
#27 0x7fffe6b2a7f7 in g_main_context_dispatch () from
/lib/x86_64-linux-gnu/libglib-2.0.so.0
#28 0x7fffe6b2aa60 in  () from /lib/x86_64-linux-gnu/libglib-2.0.so.0
#29 0x7fffe6b2ab0c in 

Bug#856024: molly-guard: causes failure to update systemd-sysv

[Francois Marier]

On 2017-02-24 at 13:02:05, Jonas Smedegaard wrote:
> This seems quite similar to bug#837928. Filing separately as I believe
> this (instance of a common) issue is so severe that in my opinion it is
> better to release _without_ molly-guard than status quo.

Or perhaps a Conflict in systemd-sysv?

Francois

Bug#856106: surfraw: please add "wikt" for wiktionary

[Adam Borowski]

Package: surfraw
Version: 2.2.9-1
Severity: wishlist


Hi!
Please let surfraw access the Wiktionary.
The URL is https://${LANG:-en}.wiktionary.org/wiki/%s

There's no point in supporting non-https as it gets redirected immediately.

Bug#856105: Improve locale-gen to accept locales to generate from command line

[Anthony Wong]

Package: locales
Version: 2.24.9
Tags: patch

Attached is a patch to allow locale-gen to accept one or more locales
to generate.
One or more locales can be provided, and all of them will be generated
instead of looking in /etc/locale.gen. Locales in arguments will be
uncommented in /etc/locale.gen.

Thanks,
Anthony Wong
From f5357055243813daaf7d9c0f8f7b7819e4eac521 Mon Sep 17 00:00:00 2001
From: Anthony Wong 
Date: Fri, 24 Feb 2017 23:31:05 -0500
Subject: [PATCH] Locales to generate can be provided as command line argument.

One or more locales can be provided, and all of them will be generated
instead of looking in /etc/locale.gen. Locales in arguments will be
uncommented in /etc/locale.gen.

Signed-off-by: Anthony Wong 
---
 debian/local/usr_sbin/locale-gen | 43 ++--
 1 file changed, 41 insertions(+), 2 deletions(-)

diff --git a/debian/local/usr_sbin/locale-gen b/debian/local/usr_sbin/locale-gen
index 3d13dadf..ff0be194 100755
--- a/debian/local/usr_sbin/locale-gen
+++ b/debian/local/usr_sbin/locale-gen
@@ -5,6 +5,7 @@ set -e
 LOCALEGEN=/etc/locale.gen
 LOCALES=/usr/share/i18n/locales
 USER_LOCALES=/usr/local/share/i18n/locales
+SUPPORTED=/usr/share/i18n/SUPPORTED
 if [ -n "$POSIXLY_CORRECT" ]; then
   unset POSIXLY_CORRECT
 fi
@@ -35,8 +36,46 @@ is_entry_ok() {
   fi
 }
 
+add_to_locale_gen() {
+  echo "$1" | while read locale; do
+if ! grep -q "^[# ]*$locale *\$" $LOCALEGEN; then
+  echo "# $locale" >> $LOCALEGEN
+fi
+sed -i -e "0,/^[# ]*$locale *$/ s/^[# ]*$locale *$/$locale/" $LOCALEGEN
+  done
+}
+
+if [ -z "$1" ]; then
+  GENERATE="`cat $LOCALEGEN 2>/dev/null || true`"
+else
+  GENERATE=
+  while [ -n "$1" ]; do
+LL="`echo "$1" | sed 's/\./ /'`" 
+# Check validity of supplied locale string
+if ! echo "$1" | grep -q -e "^[a-z]\{2,3\}_[A-Z]\{2\}\(@[a-z0-9]\+\)\{0,1\}\.[A-Z0-9-]\+$" \
+ -e "^[a-z]\{2,3\}_[A-Z]\{2\}$"; then
+  echo "Error: '$1' is not a valid locale format" >&2
+elif L=`grep "^$1 " $SUPPORTED`; then
+  # for cases that match the complete locale string
+  GENERATE="$GENERATE\n$L"
+  echo "Adding $L"
+  add_to_locale_gen "$L"
+elif L=`grep "^$LL" $SUPPORTED`; then
+  # for cases like "aa_ER.UTF-8", where the entry is written as "aa_ER UTF-8"
+  GENERATE="$GENERATE\n$L"
+  echo "Adding $L"
+  add_to_locale_gen "$L"
+else
+  echo "Error: '$1' is not a supported language or locale" >&2
+fi
+shift
+  done
+fi
+
+[ -z "$GENERATE" ] && echo "Error: nothing to do" >&2 && exit 1
+
 echo "Generating locales (this might take a while)..."
-while read locale charset; do \
+echo "$GENERATE" | sort -u | while read locale charset; do \
 	case $locale in \#*) continue;; "") continue;; esac; \
 	is_entry_ok || continue
 	if [ "$KEEP" ] && PERL_BADLANG=0 perl -MPOSIX -e \
@@ -59,5 +98,5 @@ while read locale charset; do \
 	fi
 	localedef -i $input -c -f $charset -A /usr/share/locale/locale.alias $locale || :; \
 	echo ' done'; \
-done < $LOCALEGEN
+done
 echo "Generation complete."
-- 
2.11.0

Bug#844943: python-bleach: FTBFS: Tests failures

[Scott Kitterman]

On Tue, 14 Feb 2017 14:52:01 -0500 Scott Kitterman  
wrote:
> On Mon, 19 Dec 2016 20:54:02 +0530 Pirate Praveen  
wrote:
> ...
> > Seems python-html5lib was updated without checking reverse dependency
> > compatibility  https://github.com/mozilla/bleach/issues/212
> > 
> 
> Based on recent discussions in the upstream bugs, it looks like they are 
> making some progress on this.  If they don't, I think the only option is to 
> embed a copy of the older html5lib in bleach (not ideal, I know).

Upstream git now passes all tests with the new html5lib.  Pending some 
additional testing, a new release is planned next week.  I intent to ask the 
RT for permission to update to the new upstream.  I have a local test package 
of the current git and it passes all tests.

Scott K

Bug#854658: unblock pre-approval request for gitlab

[Pirate Praveen]

On വെള്ളി 24 ഫെബ്രുവരി 2017 08:19 വൈകു, Balasankar C wrote:
> Should I share the source debdiff of both these uploads to this issue or is a
> separate issue necessary for gitlab-shell (The change is exactly the one
> mentioned for gitlab. Not using /usr/share/gitlab-shell/doc ) ?
>
Attaching the source debdiffs.

diff -Nru gitlab-8.13.11+dfsg/debian/changelog 
gitlab-8.13.11+dfsg/debian/changelog
--- gitlab-8.13.11+dfsg/debian/changelog2017-02-16 17:35:29.0 
+0530
+++ gitlab-8.13.11+dfsg/debian/changelog2017-02-24 17:06:52.0 
+0530
@@ -1,3 +1,18 @@
+gitlab (8.13.11+dfsg-4) unstable; urgency=medium
+
+  [ Balasankar C ]
+  * Update description to specify that the package is non-omnibus, unlike the
+official one from GitLab.
+  * Remove database on purge only if necessary commands are available
+(Closes: #855579)
+
+  [ Pirate Praveen ]
+  * Use /usr/lib/gitlab/templates for config file templates used in postinst
+(See 854658#34)
+  * Add more checks in postrm to avoid failures which can be ignored
+
+ -- Balasankar C   Fri, 24 Feb 2017 17:06:52 +0530
+
 gitlab (8.13.11+dfsg-3) unstable; urgency=medium
 
   * Allow choosing gitlab user (Closes: #854617)
diff -Nru gitlab-8.13.11+dfsg/debian/conf/gitlab-debian.conf.example 
gitlab-8.13.11+dfsg/debian/conf/gitlab-debian.conf.example
--- gitlab-8.13.11+dfsg/debian/conf/gitlab-debian.conf.example  2017-02-16 
17:35:29.0 +0530
+++ gitlab-8.13.11+dfsg/debian/conf/gitlab-debian.conf.example  2017-02-20 
18:08:33.0 +0530
@@ -4,13 +4,13 @@
 gitlab_data_dir=/var/lib/gitlab
 gitlab_cache_path=/var/cache/gitlab
 gitlab_scripts=/usr/lib/gitlab/scripts
-gitlab_yml_example=/usr/share/doc/gitlab/gitlab.yml.example
+gitlab_yml_example=/usr/lib/gitlab/templates/gitlab.yml.example
 gitlab_yml_private=/var/lib/gitlab/gitlab.yml
 gitlab_yml=/etc/gitlab/gitlab.yml
-gitlab_debian_conf_example=/usr/share/doc/gitlab/gitlab-debian.conf.example
+gitlab_debian_conf_example=/usr/lib/gitlab/templates/gitlab-debian.conf.example
 gitlab_debian_conf_private=/var/lib/gitlab/gitlab-debian.conf
 gitlab_debian_conf=/etc/gitlab/gitlab-debian.conf
-gitlab_shell_config_example=/usr/share/doc/gitlab-shell/config.yml.example
+gitlab_shell_config_example=/usr/lib/gitlab-shell/config.yml.example
 gitlab_shell_config_private=/var/lib/gitlab/gitlab-shell-config.yml
 gitlab_shell_config=/etc/gitlab-shell/config.yml
 gitlab_nginx_log=/var/log/gitlab
@@ -19,10 +19,10 @@
 gitlab_shell_log=/var/log/gitlab-shell
 gitlab_log_dir=/var/log/gitlab
 gitlab_pid_path=/run/gitlab
-gitlab_tmpfiles_example=/usr/share/doc/gitlab/tmpfiles.d/gitlab.conf.example
+gitlab_tmpfiles_example=/usr/lib/gitlab/templates/tmpfiles.d/gitlab.conf.example
 gitlab_tmpfiles_private=/var/lib/gitlab/tmpfiles.d-gitlab.conf
 gitlab_tmpfiles=/usr/lib/tmpfiles.d/gitlab.conf
 nginx_user=www-data
-nginx_conf_example=/usr/share/doc/gitlab/nginx.conf.example
-nginx_ssl_conf_example_gz=/usr/share/doc/gitlab/nginx.ssl.conf.example.gz
+nginx_conf_example=/usr/lib/gitlab/templates/nginx.conf.example
+nginx_ssl_conf_example=/usr/lib/gitlab/templates/nginx.ssl.conf.example
 nginx_site_private=/var/lib/gitlab/nginx.conf
diff -Nru gitlab-8.13.11+dfsg/debian/control gitlab-8.13.11+dfsg/debian/control
--- gitlab-8.13.11+dfsg/debian/control  2017-02-16 17:35:29.0 +0530
+++ gitlab-8.13.11+dfsg/debian/control  2017-02-20 19:54:52.0 +0530
@@ -31,7 +31,7 @@
  postfix | exim4 | mail-transport-agent,
  openssh-client,
  ucf,
- gitlab-shell (>= 3.6.6-3~),
+ gitlab-shell (>= 3.6.6-4~),
  gitlab-workhorse (>= 0.8.5~),
  ruby-rails (>= 2:4.2.7~),
  ruby-rails (<< 2:5),
@@ -241,8 +241,11 @@
  libjs-graphael,
  libjs-fuzzaldrin-plus (>= 0.3.1+git.20161008.da2cb58+dfsg-4~)
 Recommends: certbot
-Description: git powered software platform to collaborate on code
+Description: git powered software platform to collaborate on code (non-omnibus)
  gitlab provides web based interface to host source code and track issues.
  It allows anyone for fork a repository and send merge requests. Code review
  is possible using merge request workflow. Using groups and roles project 
  access can be controlled.
+ .
+ Unlike the official package from GitLab Inc., this package does not use
+ omnibus.
diff -Nru gitlab-8.13.11+dfsg/debian/gitlab.docs 
gitlab-8.13.11+dfsg/debian/gitlab.docs
--- gitlab-8.13.11+dfsg/debian/gitlab.docs  2017-02-16 17:35:29.0 
+0530
+++ gitlab-8.13.11+dfsg/debian/gitlab.docs  2017-02-20 16:56:50.0 
+0530
@@ -1,4 +1,2 @@
 README.md
 debian/README.Debian
-debian/conf/nginx.conf.example
-debian/conf/nginx.ssl.conf.example
diff -Nru gitlab-8.13.11+dfsg/debian/install gitlab-8.13.11+dfsg/debian/install
--- gitlab-8.13.11+dfsg/debian/install  2017-02-16 17:35:29.0 +0530
+++ gitlab-8.13.11+dfsg/debian/install  2017-02-20 16:56:47.0 +0530
@@ -1,12 +1,14 @@
 debian/conf/gitlab etc/default
 debian/conf/unicorn.rb etc/gitlab
 

Bug#855644: devscripts: grep-excuses doesn't work with maintainer name

[James McCoy]

On Fri, Feb 24, 2017 at 11:59:56PM -0500, James McCoy wrote:
> I'm splitting this bug into two pieces.  One, for the release team, to
> fix the generation of the HTML so grep-excuses is fixed now, and another
> for grep-excuses to start consuming YAML instead of parsing HTML.

As far as using YAML instead of HTML, that would cause a slight change
to the output from grep-excuses.  However, I think it still maintains
all the salient information:

# New YAML-based version
$ ./scripts/grep-excuses.pl firefox
firefox (- to 51.0.1-3)
Maintainer: Maintainers of Mozilla-related packages
Too young, only 1 of 10 days old
Not touching package due to block request by freeze (check 
https://release.debian.org/testing/freeze_policy.html if update is needed)
firefox has new bugs!
Updating firefox introduces new bugs: #813054, #817954, #849602
Piuparts tested OK - https://piuparts.debian.org/sid/source/f/firefox.html

# Current HTML-based version
$ grep-excuses firefox
firefox (- to 51.0.1-3)
Migration status: BLOCKED: Rejected/introduces a regression (please see 
below)
Maintainer: Maintainers of Mozilla-related packages
Too young, only 1 of 10 days old
Not touching package due to block request by freeze (check 
https://release.debian.org/testing/freeze_policy.html if update is needed)
firefox has new bugs!
Updating firefox introduces new bugs: #813054, #817954, #849602
Piuparts tested OK - https://piuparts.debian.org/sid/source/f/firefox.html
Not considered

Cheers,
-- 
James
GPG Key: 4096R/91BF BF4D 6956 BD5D F7B7  2D23 DFE6 91AE 331B A3DB

Bug#855644: devscripts: grep-excuses doesn't work with maintainer name

[James McCoy]

Control: clone -1 -2
Control: retitle -2 [britney] Add an EOL to the verdict summary line in HTML 
output
Control: tag -2 patch
Control: retitle -1 grep-excuses: Use excuses.yaml instead of 
update_excuses.html.gz
Control: severity -1 normal

On Mon, Feb 20, 2017 at 10:42:17PM +0100, Christian Marillat wrote:
> $ grep-excuses sawfish-merlin-ugliness
> sawfish-merlin-ugliness (- to 1.3.1-1)
> Migration status: BLOCKED: Rejected/introduces a regression (please see 
> below)
> Maintainer: Christian Marillat
> 4589 days old (needed 10 days)
> Not touching package due to block request by freeze (check 
> https://release.debian.org/testing/freeze_policy.html if update is needed)
> sawfish-merlin-ugliness has new bugs!
> Updating sawfish-merlin-ugliness introduces new bugs: #800278
> Piuparts tested OK - 
> https://piuparts.debian.org/sid/source/s/sawfish-merlin-ugliness.html
> 
> When 'grep-excuses Marillat' or grep-excuses 'Christian Marillat' return 
> nothing.

This is due to a recent change in the script that generates the
update_excuses.html page, which breaks grep-excuses' parsing.

I'm splitting this bug into two pieces.  One, for the release team, to
fix the generation of the HTML so grep-excuses is fixed now, and another
for grep-excuses to start consuming YAML instead of parsing HTML.

I have patches for both bugs, but the YAML one will need to wait until
Buster, since it's essentially a rewrite of that part of grep-excuses.

Cheers,
-- 
James
GPG Key: 4096R/91BF BF4D 6956 BD5D F7B7  2D23 DFE6 91AE 331B A3DB
>From a04d730bb7ba63df17117c3bfc4afd93bab9f37c Mon Sep 17 00:00:00 2001
From: James McCoy 
Date: Fri, 24 Feb 2017 23:43:57 -0500
Subject: [PATCH] excuse: Add an EOL to the verdict summary line in HTML output

devscripts' grep-excuses expects each  to be on its own line.  When
d7a676d0741729bb643e0b8c54b989cb747c6a4b added the verdict summary,
without an EOL, it broke grep-excuses' ability to search by maintainer.

Signed-off-by: James McCoy 
---
 britney2/excuse.py | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/britney2/excuse.py b/britney2/excuse.py
index 4dbd703..e301cfe 100644
--- a/britney2/excuse.py
+++ b/britney2/excuse.py
@@ -182,7 +182,7 @@ class Excuse(object):
 """Render the excuse in HTML"""
 res = "%s (%s to %s)\n\n" % \
 (self.name, self.name, self.name, self.ver[0], self.ver[1])
-res += "Migration status: %s" % self._format_verdict_summary()
+res += "Migration status: %s\n" % self._format_verdict_summary()
 if self.maint:
 res = res + "Maintainer: %s\n" % (self.maint)
 if self.section and self.section.find("/") > -1:
-- 
2.11.0

Bug#801822: Patch to fix

[Jakobus Schürz]

Hi there!

I tried this

--- /usr/bin/deb-systemd-helper 2017-02-25 03:56:20.844471315 +0100
+++ /usr/bin/deb-systemd-helper-instantunits2017-02-25
04:27:56.794876790 +0100
@@ -118,6 +118,7 @@
 my ($scriptname) = @_;

 my $service_path = $scriptname;
+$scriptname =~ s/\@.*\.([a-z]*)$/@.\1/;
 if (-f "/etc/systemd/system/$scriptname") {
 $service_path = "/etc/systemd/system/$scriptname";
 } elsif (-f "/lib/systemd/system/$scriptname") {


and now i can work with instantiated unit-files.

Regards!

Jakob

-- 
Jakobus Schürz
Roseggergasse 37/21
1160 Wien

+43/699/107 66 126

http://xundeenergie.at
http://cogitationum.wordpress.com/
http://verkehrsloesungen.wordpress.com/


0x43B88572.asc
Description: application/pgp-keys


signature.asc
Description: OpenPGP digital signature

Bug#801822: Patch to fix

[Jakobus Schürz]

Hi there!

I tried this

--- /usr/bin/deb-systemd-helper 2017-02-25 03:56:20.844471315 +0100
+++ /usr/bin/deb-systemd-helper-instantunits2017-02-25
04:27:56.794876790 +0100
@@ -118,6 +118,7 @@
 my ($scriptname) = @_;

 my $service_path = $scriptname;
+$scriptname =~ s/\@.*\.([a-z]*)$/@.\1/;
 if (-f "/etc/systemd/system/$scriptname") {
 $service_path = "/etc/systemd/system/$scriptname";
 } elsif (-f "/lib/systemd/system/$scriptname") {


and now i can work with instantiated unit-files.

Regards!

Jakob

-- 
Jakobus Schürz
Roseggergasse 37/21
1160 Wien

+43/699/107 66 126

http://xundeenergie.at
http://cogitationum.wordpress.com/
http://verkehrsloesungen.wordpress.com/



0x43B88572.asc
Description: application/pgp-keys

Bug#832088: sed: silently fails with -n option specified first

[Assaf Gordon]

Hello,

Paolo Bonzini wrote:

On 22/07/2016 09:02, Daniel Iancu wrote:

sed -ni 's/foo/bar/' test # fails


So this is not a bug.


I've expanded sed's manual to mention this specific issue:
https://git.savannah.gnu.org/cgit/sed.git/commit/?id=a36e8abccc5db38e4d2f8ea2bbb3e78dfddacd78

regards,
- assaf

Bug#614296: xserver-xorg-video-intel: additional rendering corruption (screenshot included)

[Luke Kenneth Casson Leighton]

is linux-kernel driver-related.  4.9.6 problem is gone.  bug may be closed.
---
crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68


On Fri, Jan 27, 2017 at 7:37 AM, lkcl  wrote:
> Package: xserver-xorg-video-intel
> Version: 2:2.99.917+git20161105-1+b1
> Followup-For: Bug #614296
>
> this is a complex setup on very modern (skylake) hardware, so may actually
> be linux-kernel 4.8.11-related: am raising it here however.
>
> screenshot: http://hands.com/~lkcl/screen_corruption.png
>
>
>
>
> -- Package-specific info:
> X server symlink status:
> 
> lrwxrwxrwx 1 root root 13 Apr 17  2014 /etc/X11/X -> /usr/bin/Xorg
> -rwxr-xr-x 1 root root 274 Nov 25 03:52 /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 
> /usr/lib/mesa-diverted/x86_64-linux-gnu/libGL.so by glx-diversions
> diversion of /usr/lib/x86_64-linux-gnu/libGLESv2.so.2.0.0 to 
> /usr/lib/mesa-diverted/x86_64-linux-gnu/libGLESv2.so.2.0.0 by 

Bug#856103: libav-tools : concat Protocol not found

[NBaH]

Package: libav-tools
Version: 6:11.8-1~deb8u1
Severity: normal

Dear Maintainer,

I'm trying to concatenate mp3 files using avconv (from libav-tools) with 
this line :


$ avconv -i 
concat:./The_Beach_Boys_-_God_Only_Knows.mp3\|./Order_Of_Era_-_one_is_the_loneliest_number.mp3 
-c copy /tmp/mix.mp3
avconv version 11.8-6:11.8-1~deb8u1, Copyright (c) 2000-2016 the Libav 
developers

  built on Oct  1 2016 07:16:29 with gcc 4.9.2 (Debian 4.9.2-10)

and I get :

concat:./The_Beach_Boys_-_God_Only_Knows.mp3|./Order_Of_Era_-_one_is_the_loneliest_number.mp3: 
Protocol not found


it's the same if I put quotes:

$ avconv -i 
'concat:./The_Beach_Boys_-_God_Only_Knows.mp3|./Order_Of_Era_-_one_is_the_loneliest_number.mp3' 
-c copy /tmp/mix.mp3
avconv version 11.8-6:11.8-1~deb8u1, Copyright (c) 2000-2016 the Libav 
developers

  built on Oct  1 2016 07:16:29 with gcc 4.9.2 (Debian 4.9.2-10)
concat:./The_Beach_Boys_-_God_Only_Knows.mp3|./Order_Of_Era_-_one_is_the_loneliest_number.mp3: 
Protocol not found



this protocol is listed in the manpage, but not showed by

$ avconv -protocols

thank you.

--

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

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

Versions of packages libav-tools depends on:
ii  dpkg 1.17.27
ii  libavcodec56 6:11.8-1~deb8u1
ii  libavdevice556:11.8-1~deb8u1
ii  libavfilter5 6:11.8-1~deb8u1
ii  libavformat566:11.8-1~deb8u1
ii  libavresample2   6:11.8-1~deb8u1
ii  libavutil54  6:11.8-1~deb8u1
ii  libc62.19-18+deb8u7
ii  libsdl1.2debian  1.2.15-10+b1
ii  libswscale3  6:11.8-1~deb8u1
ii  libvdpau10.8-3+deb8u2
ii  libx11-6 2:1.6.2-3

libav-tools recommends no packages.

Versions of packages libav-tools suggests:
pn  frei0r-plugins  

-- no debconf information

Bug#856082: libao: Please drop the (build-)dependency against esound

[Ron]

Hi Laurent,

On Sat, Feb 25, 2017 at 01:14:24AM +0100, bi...@debian.org wrote:
> Source: libao
> Version: 1.2.2-1
> Severity: wishlist
> Tags: sid buster
> User: pkg-gnome-maintain...@lists.alioth.debian.org
> Usertags: esd-removal
> 
> Dear maintainer,
> 
> Your package is {build-}depending against esound which is deprecated
> for quite some times now.
> 
> We are planning to remove esound for Buster if possible.
> 
> Could you please verify that this dependency is mandatory and if it's
> not the case, could you please remove it?

There is no hard requirement on esound for libao, it's just one of
many supported audio subsystems which it has plugin support for.

So if libesd is being removed from Debian, it's an easy enough change
to just not build that plugin for Buster+.  I won't do that until the
current freeze is over so we still have an easy path through unstable
if anything urgent does need updating in this - but you can put this
one on your easy list for the Buster cycle.

  Cheers,
  Ron

Bug#856102: firefox-esr: clicking on some links crashes xorg

[Bruno Dantas]

Package: firefox-esr
Version: 45.7.0esr-4
Severity: normal

Dear Maintainer,

Clicking on some links while using firefox-esr causes X to crash and desktop
session to abruptly end. Clicking the "download patch" link here, for example,
reproduces the problem: https://patchwork.freedesktop.org/patch/135036/ (the
patch supposedly remedies the issue... gotta love the irony). Clicking that
same link in Chromium does not cause a crash. Icedove has a similar issue,
where X crashes sometimes immediately after I press the "Send" button.

My package versions:
firefox-esr 45.7.0esr-4
icedove 1:45.6.0-2
xorg 1:7.7+18

Whether the crash is caused by firefox-esr or icedove, the text console that
shows up after X crashes shows this message: "glamor_picture.c:291:
glamor_upload_picture_to_texture: Assertion
`!pixmap_priv->fbo' failed. xinit: connection to x server lost".

I'm not sure if this is an issue with mozilla applications or with xorg, so I
also submitted a bug report to Debian's X team (https://bugs.debian.org/cgi-
bin/bugreport.cgi?bug=856041). A more experienced debian user suggested that I
submit the report to both X and mozilla folk, so I obliged.



-- Package-specific info:

-- Extensions information
Name: Default theme
Location: 
/usr/lib/firefox-esr/browser/extensions/{972ce4c6-7e08-4474-a285-3208198ce6fd}.xpi
Package: firefox-esr
Status: enabled

Name: Firefox Hello Beta
Location: ${PROFILE_EXTENSIONS}/l...@mozilla.org.xpi
Status: enabled

Name: HTTPS Everywhere
Location: ${PROFILE_EXTENSIONS}/https-everywhere-...@eff.org.xpi
Status: enabled

Name: Privacy Badger
Location: ${PROFILE_EXTENSIONS}/jid1-mnnxcxisbpn...@jetpack.xpi
Status: enabled

Name: Random Agent Spoofer
Location: ${PROFILE_EXTENSIONS}/jid1-avgcef1zovz...@jetpack.xpi
Status: enabled

Name: Saved Password Editor
Location: ${PROFILE_EXTENSIONS}/savedpasswordedi...@daniel.dawson.xpi
Status: enabled

Name: Stop Fingerprinting
Location: ${PROFILE_EXTENSIONS}/@stop-fingerprinting.xpi
Status: enabled

-- Plugins information
Name: IcedTea-Web Plugin (using IcedTea-Web 1.6.2 (1.6.2-3.1))
Location: /usr/lib/jvm/java-8-openjdk-amd64/jre/lib/amd64/IcedTeaPlugin.so
Package: icedtea-8-plugin:amd64
Status: enabled


-- Addons package information
ii  firefox-esr45.7.0esr-4  amd64Mozilla Firefox web browser - Ext
ii  icedtea-8-plug 1.6.2-3.1amd64web browser plugin based on OpenJ

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

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

Versions of packages firefox-esr depends on:
ii  debianutils   4.8.1
ii  fontconfig2.11.0-6.7
ii  libasound21.1.3-5
ii  libatk1.0-0   2.22.0-1
ii  libc6 2.24-9
ii  libcairo2 1.14.8-1
ii  libdbus-1-3   1.10.16-1
ii  libdbus-glib-1-2  0.108-2
ii  libevent-2.0-52.0.21-stable-3
ii  libffi6   3.2.1-6
ii  libfontconfig12.11.0-6.7
ii  libfreetype6  2.6.3-3+b1
ii  libgcc1   1:6.3.0-6
ii  libgdk-pixbuf2.0-02.36.4-1
ii  libglib2.0-0  2.50.2-2
ii  libgtk2.0-0   2.24.31-2
ii  libhunspell-1.4-0 1.4.1-2+b1
ii  libnspr4  2:4.12-6
ii  libnss3   2:3.26.2-1
ii  libpango-1.0-01.40.3-3
ii  libsqlite3-0  3.16.2-2
ii  libstartup-notification0  0.12-4
ii  libstdc++66.3.0-6
ii  libvpx4   1.6.1-2
ii  libx11-6  2:1.6.4-3
ii  libxcomposite11:0.4.4-2
ii  libxdamage1   1:1.1.4-2+b1
ii  libxext6  2:1.3.3-1
ii  libxfixes31:5.0.3-1
ii  libxrender1   1:0.9.10-1
ii  libxt61:1.1.5-1
ii  procps2:3.3.12-3
ii  zlib1g1:1.2.8.dfsg-5

Versions of packages firefox-esr recommends:
ii  gstreamer1.0-libav 1.10.3-1
ii  gstreamer1.0-plugins-good  1.10.3-1

Versions of packages firefox-esr suggests:
pn  fonts-lmodern  
pn  fonts-stix | otf-stix  
ii  libcanberra0   0.30-3
ii  libgnomeui-0   2.24.5-3.1
ii  libgssapi-krb5-2   1.15-1
pn  mozplugger 

-- no debconf information

Bug#801822: same here

[Jakob Schürz]

Hi there!

I wrote a backupscript for btrfs-filesystem and need to activate on
instantiated unit on several timer-units.

Manually
systemctl enable mkbackup@weekly.service mkbackup@daily.service
works.

But  deb-systemd-helper enable $SERVICE >/dev/null || true

But deb-systemd-helper gives me
/usr/bin/deb-systemd-helper: error: unable to read kbackup@daily.service
/usr/bin/deb-systemd-helper: error: unable to read kbackup@weekly.service
for this services.

regards

jakob

Bug#856101: libgexiv2-2: assertion when reading unrotated image from Minolta camera

[Jason Crain]

Package: libgexiv2-2
Version: 0.10.4-1
Severity: important

Tags: patch
Forwarded: https://bugzilla.gnome.org/776233

If the image at https://bugzilla.redhat.com/attachment.cgi?id=1228168 is opened
in shotwell, it aborts with the following message:

**
ERROR:gexiv2/gexiv2-metadata.cpp:405:GExiv2Orientation
gexiv2_metadata_get_orientation(GExiv2Metadata*): code should not be reached
Aborted

A patch to fix the issue is available at https://bugzilla.gnome.org/776233.

backtrace:

#0  0x7fffef0bdfdf in __GI_raise (sig=sig@entry=6) at
../sysdeps/unix/sysv/linux/raise.c:58
#1  0x7fffef0bf40a in __GI_abort () at abort.c:89
#2  0x7fffef8e4515 in g_assertion_message (domain=domain@entry=0x0,
file=file@entry=0x77905ba1 "gexiv2/gexiv2-metadata.cpp",
line=line@entry=405, func=func@entry=0x77906860
 "GExiv2Orientation
gexiv2_metadata_get_orientation(GExiv2Metadata*)",
message=message@entry=0x7fffb4001f00 "code should not be reached") at
././glib/gtestutils.c:2432
#3  0x7fffef8e45aa in g_assertion_message_expr (domain=domain@entry=0x0,
file=file@entry=0x77905ba1 "gexiv2/gexiv2-metadata.cpp",
line=line@entry=405, func=func@entry=0x77906860
 "GExiv2Orientation
gexiv2_metadata_get_orientation(GExiv2Metadata*)", expr=expr@entry=0x0) at
././glib/gtestutils.c:2455
#4  0x778f7939 in gexiv2_metadata_get_orientation(GExiv2Metadata*)
(self=0x569a20a0 [GExiv2Metadata]) at gexiv2/gexiv2-metadata.cpp:405
#5  0x5562b9c4 in photo_metadata_get_orientation (self=0x568401e0
[PhotoMetadata]) at ./src/photos/PhotoMetadata.vala:1121
#6  0x55734e8d in photo_prepare_for_import
(params=params@entry=0x7fffb000d5e0) at ./src/Photo.vala:1218
#7  0x55761224 in prepared_file_import_job_real_execute
(base=) at ./src/BatchImport.vala:1983
#8  0x555e7068 in workers_thread_start (ignored=,
self=0x569890d0) at ./src/threads/Workers.vala:96
#9  0x555e7068 in _workers_thread_start_gfunc (data=,
self=0x569890d0) at ./src/threads/Workers.vala:31
#10 0x7fffef8e5d3e in g_thread_pool_thread_proxy (data=) at
././glib/gthreadpool.c:307
#11 0x7fffef8e5345 in g_thread_proxy (data=0x56a7d720) at
././glib/gthread.c:784
#12 0x7fffef430424 in start_thread (arg=0x7fffc5cfe700) at
pthread_create.c:333
#13 0x7fffef1739bf in clone () at
../sysdeps/unix/sysv/linux/x86_64/clone.S:105



-- System Information:
Debian Release: 9.0
  APT prefers testing
  APT policy: (9000, 'testing')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

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

Versions of packages libgexiv2-2 depends on:
ii  libc6 2.24-9
ii  libexiv2-14   0.25-3
ii  libgcc1   1:6.3.0-6
ii  libglib2.0-0  2.50.2-2
ii  libstdc++66.3.0-6

libgexiv2-2 recommends no packages.

libgexiv2-2 suggests no packages.

-- no debconf information

Bug#284646: sed: Documentation does not properly document effects of multiple commands

[Assaf Gordon]

Hello,


- it is not specified whether address selections following a command
  act on unchanged input lines [...] or on the lines as changed by the 
  previous command


I've clarified this point in sed's manual and man-page:
https://git.savannah.gnu.org/cgit/sed.git/commit/?id=de6b6ccd7400b6483ecee5eebc7d48666b497680

regards,
- assaf

Bug#605142: sed: incorrectly interprets \x hexadecimal escapes sometimes

[Assaf Gordon]

Hello,

I've added a paragraph about the current behavior
with your example to sed's manual:

https://git.savannah.gnu.org/cgit/sed.git/commit/?id=a805d57e1f6427b55

regards,
- assaf

Bug#856100: libav-tools : concat Protocol not found

[Bálint Réczey]

Control: notfound -1 6:11.8-1~deb8u1

Hi,

2017-02-25 1:58 GMT+01:00 ça vaaa :
> Package: libav-tools
> Version: 6:11.8-1~deb8u1
> Severity: normal
>
> Dear Maintainer,
>
> I'm trying to concatenate mp3 files using avconv (from libav-tools) with
> this line :
>
> $ avconv -i
> concat:./The_Beach_Boys_-_God_Only_Knows.mp3\|./Order_Of_Era_-_one_is_the_loneliest_number.mp3
> -c copy /tmp/mix.mp3
You need to put the '|' (pipe) between apostrophes because it has
special meaning in shell:
avconv -i 
'concat:./The_Beach_Boys_-_God_Only_Knows.mp3\|./Order_Of_Era_-_one_is_the_loneliest_number.mp3'
-c copy /tmp/mix.mp3

Cheers,
Balint


> avconv version 11.8-6:11.8-1~deb8u1, Copyright (c) 2000-2016 the Libav
> developers
>   built on Oct  1 2016 07:16:29 with gcc 4.9.2 (Debian 4.9.2-10)
>
> and I get :
>
> concat:./The_Beach_Boys_-_God_Only_Knows.mp3|./Order_Of_Era_-_one_is_the_loneliest_number.mp3:
> Protocol not found
>
> this protocol is listed in the manpage, but not showed by
>
> $ avconv -protocols
>
> thank you.
>
> --
>
> -- System Information:
> Debian Release: 8.7
>   APT prefers stable-updates
>   APT policy: (500, 'stable-updates'), (500, 'stable')
> Architecture: amd64 (x86_64)
>
> Kernel: Linux 3.16.0-4-amd64 (SMP w/2 CPU cores)
> Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8)
> Shell: /bin/sh linked to /bin/dash
> Init: systemd (via /run/systemd/system)
>
> Versions of packages libav-tools depends on:
> ii  dpkg 1.17.27
> ii  libavcodec56 6:11.8-1~deb8u1
> ii  libavdevice556:11.8-1~deb8u1
> ii  libavfilter5 6:11.8-1~deb8u1
> ii  libavformat566:11.8-1~deb8u1
> ii  libavresample2   6:11.8-1~deb8u1
> ii  libavutil54  6:11.8-1~deb8u1
> ii  libc62.19-18+deb8u7
> ii  libsdl1.2debian  1.2.15-10+b1
> ii  libswscale3  6:11.8-1~deb8u1
> ii  libvdpau10.8-3+deb8u2
> ii  libx11-6 2:1.6.2-3
>
> libav-tools recommends no packages.
>
> Versions of packages libav-tools suggests:
> pn  frei0r-plugins  
>
> -- no debconf information
>

Bug#856100: libav-tools : concat Protocol not found

[ça vaaa]

Package: libav-tools
Version: 6:11.8-1~deb8u1
Severity: normal

Dear Maintainer,

I'm trying to concatenate mp3 files using avconv (from libav-tools) with 
this line :


$ avconv -i 
concat:./The_Beach_Boys_-_God_Only_Knows.mp3\|./Order_Of_Era_-_one_is_the_loneliest_number.mp3 
-c copy /tmp/mix.mp3
avconv version 11.8-6:11.8-1~deb8u1, Copyright (c) 2000-2016 the Libav 
developers

  built on Oct  1 2016 07:16:29 with gcc 4.9.2 (Debian 4.9.2-10)

and I get :

concat:./The_Beach_Boys_-_God_Only_Knows.mp3|./Order_Of_Era_-_one_is_the_loneliest_number.mp3: 
Protocol not found


this protocol is listed in the manpage, but not showed by

$ avconv -protocols

thank you.

--

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

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

Versions of packages libav-tools depends on:
ii  dpkg 1.17.27
ii  libavcodec56 6:11.8-1~deb8u1
ii  libavdevice556:11.8-1~deb8u1
ii  libavfilter5 6:11.8-1~deb8u1
ii  libavformat566:11.8-1~deb8u1
ii  libavresample2   6:11.8-1~deb8u1
ii  libavutil54  6:11.8-1~deb8u1
ii  libc62.19-18+deb8u7
ii  libsdl1.2debian  1.2.15-10+b1
ii  libswscale3  6:11.8-1~deb8u1
ii  libvdpau10.8-3+deb8u2
ii  libx11-6 2:1.6.2-3

libav-tools recommends no packages.

Versions of packages libav-tools suggests:
pn  frei0r-plugins  

-- no debconf information

Bug#856064: libdbd-mysql-perl: reads of floats currupted as 0

[pali]

Hi!

On Saturday 25 February 2017 00:41:31 gregor herrmann wrote:
> On Sat, 25 Feb 2017 09:29:23 +1100, Brian May wrote:
> > Package: libdbd-mysql-perl
> > Version: 4.041-1
> > Severity: grave
> > Justification: causes non-serious data loss
> > 
> > When reading floats from mysql, they are always read as 0.
> 
> Thanks for the bug report and all the information!
> 
> > Upstream patch:
> > https://github.com/perl5-dbi/DBD-mysql/pull/102
> 
> This patch doesn't apply against 4.041-1 in Debian (or 4.041
> upstream), and neither against the master branch in the upstream repo
> (so unless I'm missing something, this pull request won't work
> as-is),

That patch in github PR 102 applies cleanly on DBD-mysql master branch. 
It is based on top of master branch. Patch is not merged yet.

Note that nobody was able to create any test which cause this problem 
yet. The only one affected application (which was reported) is amavis. 
Seems unbelievable but it is truth.

> as Pali's master has been massively rewritten since then. [0]

Yes, there are more bug fixes in DBD-mysql. E.g. zerofill support fixed 
in commit dc4d40b1df2f05b9e23105ab6d7b98c77eb318de which worked for 10 
years until 4.040: https://rt.cpan.org/Public/Bug/Display.html?id=118977 
(even it was not explicitly supported).

Or fixed UTF-8 support which was broken for a long time: 
https://github.com/perl5-dbi/DBD-mysql/pull/67

> From looking at the comments in the diff I could possibly find the
> places in the shipped dbdimp.c to make this build somehow, but I'm
> rather reluctant to do this blindly.

Replace "(void) SvNV(sv); SvNOK_only(sv);" by "sv_setnv(sv, SvNV(sv));". 
And similarly also for IV and UV.

> Pali, could you perhaps come up with a patch that applies against
> 4.041?

This one is for libdbd-mysql-perl_4.041-1.dsc:

--- dbdimp.c
+++ dbdimp.c
@@ -4250,8 +4250,7 @@ process:
 switch (mysql_to_perl_type(fields[i].type)) {
 case MYSQL_TYPE_DOUBLE:
   /* Coerce to dobule and set scalar as NV */
-  (void) SvNV(sv);
-  SvNOK_only(sv);
+  sv_setnv(sv, SvNV(sv));
   break;
 
 case MYSQL_TYPE_LONG:
@@ -4259,13 +4258,11 @@ process:
   /* Coerce to integer and set scalar as UV resp. IV */
   if (fields[i].flags & UNSIGNED_FLAG)
   {
-(void) SvUV(sv);
-SvIOK_only_UV(sv);
+sv_setuv(sv, SvUV(sv));
   }
   else
   {
-(void) SvIV(sv);
-SvIOK_only(sv);
+sv_setiv(sv, SvIV(sv));
   }
   break;
 

But if you are fixing "regressions" from older versions, consider apply 
also fix for zerofill.

> 
> Cheers,
> gregor
> 
> [0] especially caea0b774028650c0cbd9d8f9c4a0b47831116df changes the
> variable types in the switch/case construct

Bug#855997: (no subject)

[Michael Lustfield]

License: LGPL-3+

-- 
Michael Lustfield

Bug#856064: libdbd-mysql-perl: reads of floats currupted as 0

[gregor herrmann]

On Sat, 25 Feb 2017 09:29:23 +1100, Brian May wrote:

> Package: libdbd-mysql-perl
> Version: 4.041-1
> Severity: grave
> Justification: causes non-serious data loss
> 
> When reading floats from mysql, they are always read as 0.

Thanks for the bug report and all the information!
 
> Upstream patch:
> https://github.com/perl5-dbi/DBD-mysql/pull/102

This patch doesn't apply against 4.041-1 in Debian (or 4.041
upstream), and neither against the master branch in the upstream repo
(so unless I'm missing something, this pull request won't work as-is), as
Pali's master has been massively rewritten since then. [0]

From looking at the comments in the diff I could possibly find the
places in the shipped dbdimp.c to make this build somehow, but I'm
rather reluctant to do this blindly.

Pali, could you perhaps come up with a patch that applies against 4.041?


Cheers,
gregor

[0] especially caea0b774028650c0cbd9d8f9c4a0b47831116df changes the
variable types in the switch/case construct

-- 
 .''`.  https://info.comodo.priv.at/ - Debian Developer https://www.debian.org
 : :' : OpenPGP fingerprint D1E1 316E 93A7 60A8 104D  85FA BB3A 6801 8649 AA06
 `. `'  Member of VIBE!AT & SPI, fellow of the Free Software Foundation Europe
   `-   NP: Led Zeppelin: Kashmir


signature.asc
Description: Digital Signature

Bug#855827: tmux: Please build tmux with utf8proc to allow utf8 in status line

[Romain Francoise]

On Wed, Feb 22, 2017 at 09:19:48AM +0100, Kevin Brubeck Unhammer wrote:
> The version of tmux in Debian seems to be built without utf8proc,
> which leads to strange utf8 bugs in the status line.
[...]
> Could we have tmux built with --enable-utf8proc? It would give a
> runtime dep on libutf8proc2 and build-dep on libutf8proc-dev.

The behavior you're seeing is due to your terminal being based on a
different Unicode version than the system; my guess is that you're using
a vte-based terminal based on Unicode 9, glibc is still using Unicode 8
and the width of this character has changed. That, or your font doesn't
have the right width for it.

Building tmux against utf8proc just reconciles the Unicode
implementation between your terminal and tmux, but it would break things
in other cases (if the terminal is behind). And as it's not the default
configuration, it's probably less tested.

In any case UTF-8 in the status line works perfectly fine as long as you
don't use those problematic characters.

-- 
Romain Francoise 
http://people.debian.org/~rfrancoise/

Bug#661698: [smstools] /var/run/smstools/smsd.working not created

[smstools3]

> Package: smstools
> Severity: normal
>
> The infofile, which is defined in /etc/default/smstools can't be found here.
> The running process is:
>
> /usr/sbin/smsd -p/var/run/smstools/smsd.pid -i/var/run/smstools/smsd.working -
> usmsd -gdialout
>
> Many thanks, Jan.
> --
> Never write mail to , you have been warned!
> -BEGIN GEEK CODE BLOCK-
> Version: 3.12
> GIT d-- s+: a C+++ UL P+ L+++ E--- W+++ N+++ o++ K++ w--- O M V- PS PE Y++
> PGP++ t-- 5 X R tv- b+ DI D+ G++ e++ h r+++ y
> --END GEEK CODE BLOCK--

Although this bug is reported long time ago, I try to give an answer, as 
nowadays new version 3.1.17 of this software
is released.

When this daemon starts, it checks that it can create infofile, if it's 
defined. If there is any problem with
creation, daemon shows an error message and does not start.

When daemon is running, infofile does not exists all the time.

Infofile is only created when a modem process sees that daemon is going to 
terminate, but the current sending job is
not completed. Termination signal was received after the sending job of 1 SMS 
(perhaps containing multiple parts) was
started, and because the signal is "soft" termination, modem process tries to 
complete the sending. Infofile is used
to tell to the init.d script, that there is still job to do and modem process 
will stop as soon as the job is
completed. Usually this does not cause delays more than couple of seconds. When 
I published infofile in the past, the
idea was that the user likely does not want to make current message to be sent 
only partially, or fail, when daemon is
stopped "smoothly". Kill -9 is used if daemon should stop immediately, 
regardless of the status of sending.

So if I have understood this bug report correctly, I think that it's not a bug. 
It's a feature where infofile does not
exist when there is no information to give to the init.d script.

Regards,
Keke

Bug#856072: mate-volume-control-applet crashes on mouseover

[Julian]

Package: mate-media
Version: 1.16.0-1
Severity: normal
File: /usr/bin/mate-volume-control-applet

Hi,

the mate-volume-control-applet crashes at least once a day (but randomly) when
the mouse cursor is put above the applet symbol or it is clicked. I have then
to restart the applet manually.

Console output says:

(mate-volume-control-applet:11484): Gtk-WARNING **: Calling
gtk_widget_realize() on a widget that isn't inside a toplevel window is not
going to work very well. Widgets must be inside a toplevel container before
realizing them.

(mate-volume-control-applet:11484): GLib-GObject-CRITICAL **: g_object_ref:
assertion 'G_IS_OBJECT (object)' failed

(mate-volume-control-applet:11484): Gdk-CRITICAL **:
gdk_window_get_scale_factor: assertion 'GDK_IS_WINDOW (window)' failed
**
Gtk:ERROR:/build/gtk+3.0-LMY5Pb/gtk+3.0-3.22.7/./gtk/gtkwidget.c:5808:gtk_widget_get_frame_clock:
assertion failed: (window != NULL)

There are no syslog entries.



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

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

Versions of packages mate-media depends on:
ii  libatk1.0-0   2.22.0-1
ii  libc6 2.24-9
ii  libcairo-gobject2 1.14.8-1
ii  libcairo2 1.14.8-1
ii  libcanberra-gtk3-00.30-3
ii  libcanberra0  0.30-3
ii  libgdk-pixbuf2.0-02.36.4-1
ii  libglib2.0-0  2.50.2-2
ii  libgtk-3-03.22.7-2
ii  libmate-desktop-2-17  1.16.1-1
ii  libmatemixer0 1.16.0-2
ii  libpango-1.0-01.40.3-3
ii  libpangocairo-1.0-0   1.40.3-3
ii  libstartup-notification0  0.12-4
ii  libunique-3.0-0   3.0.2-2
ii  libx11-6  2:1.6.4-3
ii  libxml2   2.9.4+dfsg1-2.2
ii  mate-desktop-common   1.16.1-1
ii  mate-media-common 1.16.0-1

Versions of packages mate-media recommends:
ii  alsa-utils   1.1.3-1
ii  sound-theme-freedesktop  0.8-1

mate-media suggests no packages.

-- no debconf information

Bug#848938: xserver-xorg-video-nouveau: KDE freezes sometimes. Nouveau gives a message like "CACHE_ERROR".

[Holger Strubelt]

A similar bug happens on my iMac G5 => it’s not just an Intel issue but also 
happens on ppc. Just installed Debian a couple of days ago with the actual 
network install procedure. My motivation was that MacOS X 10.5 is the „latest“ 
release the iMac can take, which is too old to use modern web technologies, and 
it’s definitely slowing down the iMac so I wanted to try a modern OS with 
lightweight options. As a Linux newbie, I was delighted by the easy install 
procedure.

But when booting into Linux, it starts by rushing through all these text 
startup messages, but when switching to graphics modes, it ALWAYS ends with a 
black screen, prohibiting the X server to be useful at all. This happened the 
first time and every time, so it’s impossible to use the desktop environment.

After ctrl-alt-F1, a tty login is possible, but nouveau sends error messages 
every 3-10 seconds stating exactly the „CACHE_ERROR“ message that appears at 
the end of the system log file that Serkan has provided. Which makes working in 
text mode a bit irritating… Even on shutdown -h now, the X server takes about 2 
minutes before it is forced to stop, still producing these error messages. I 
guess the nouveau driver hangs somewhere so it can’t shutdown normally.

Unfortunately, I can’t access my ext4 partition from Mac OS X (failed to 
compile ext2fs over Fuse), so I can’t copy /var/log/Xorg.0.log. And as the X 
server is useless with a black screen, I can’t configure my mail program to 
send the log file. Plus, Linux can’t write-access the journaled Mac OS 
partitions. So I was a bit lost to transfer the information… Please just take 
this manually hacked information:

My iMac G5 holds an NVIDIA FX 5200 graphics card, which is correctly detected 
by nouveau, according to the log file. The internal display is recognized 
correctly with its resolution of 1680x1050 at 59.9Hz.
However, some strange errors are printed - like pixel frequency table missing 
for the DRM part of the driver.

When booting with Linux nouveau.modeset=0, the X server shows up, but with 
weird colors that make everything almost unreadable. I’ve installed LXDE since 
I didn’t want to overload the old iMac (from 2004). However, first install was 
with GNOME and the result the same. Since I suspected GNOME and couldn’t get to 
any kind of configuration options, I erased the whole install partitions and 
started from scratch with LXDE.

Nouveau version is from stable branch (1:1.0.11-1).

For me, this issue is „grave“ since it ALWAYS prevents Xorg from starting up at 
all. So the whole Debian install is useless for me. Please feel free to ask for 
more details - and if you could give me a hint on how to transfer files out of 
my iMac just using tty mode and without write access to the MacOS partitions, 
I’d be delighted to send more information.

Is there anything more to test - e.g. some more nouveau.modeset options that 
might help hunting down the bug? Is there a simple framebuffer driver available 
for the nvidia card, that would at least make X work so I could start using 
Debian before the bug is fixed?

Thx a lot,
Holger

Bug#856071: unblock repo/1.12.37-2

[Hans-Christoph Steiner]

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

Please unblock package: repo

This moves the package from main to contrib, due to a violation in
Policy 2.2.1:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=855846

unblock repo/1.12.37-2

Here's the diff

diff --git a/debian/changelog b/debian/changelog
index d0c62cc..d6ba08a 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,9 @@
+repo (1.12.37-2) unstable; urgency=medium
+
+  * move to contrib, it violates policy 2.2.1 (Closes: #855846)
+
+ -- Hans-Christoph Steiner   Fri, 24 Feb 2017 23:59:16 +0100
+
 repo (1.12.37-1) unstable; urgency=medium

   * New upstream release
diff --git a/debian/control b/debian/control
index 0336ba6..a75eb35 100644
--- a/debian/control
+++ b/debian/control
@@ -1,5 +1,5 @@
 Source: repo
-Section: devel
+Section: contrib/devel
 Priority: extra
 Maintainer: Android tools Maintainer

 Uploaders: Hans-Christoph Steiner 

Bug#856070: RM: hama-slide-mouse-control -- ROM; unmaintained, dead upstream

[Michael Biebl]

Package: ftp.debian.org
Severity: normal

This package is unmaintained, dead upstream and has extremely low
popcon. It has been orphaned (#833159) for a while.

The hardware itself can't be bought anymore today.

I think it's best to remove this software from the archive.

Bug#856069: unblock vagrant-libvirt/0.0.37-1

[Hans-Christoph Steiner]

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

Please unblock package vagrant-libvirt

0.0.37 is the first upstream release since the git version that is
already included in stretch.  0.0.37 fixes a number of key bugs
including #855700 "vagrant package command fails".  0.0.37 also adds a
new dependency, which can safely be added to Recommends:.  0.0.37-1 is
already in unstable.

The hard part about this update is that the debdiff is large, even
though the actual code changes are quite small.  Between
0.0.36.git20161125.a894dc0 and 0.0.37, upstream ran a ruby linter on the
code which found some of the key bugs that we want fixed.  It also
normalized the code for spacing, uses of quotes, if block structure,
etc.  Even though the diff is long, 0.0.37 is the version that received
lots of testing, and is the version that fixed the specific issues that
we were having.  Also, to fix an earlier bug, a git snapshot was upload,
and that this new version has almost no functional changes with regards
to that git snapshot, according to Antonio Terceiro and I (see #855700).

The first attached debdiff is the full debdiff.  The second removes the
whitespace only changes, making it a quarter smaller.


vagrant-libvirt_0.0.37-1.debdiff.bz2
Description: application/bzip


vagrant-libvirt_0.0.37-1.ignore-space.debdiff.bz2
Description: application/bzip

Bug#856064: libdbd-mysql-perl: reads of floats currupted as 0

[Brian May]

Brian May  writes:

> Possibly only happens in Perl's tainted mode; I have asked for
> confirmation.

Actually is a fair bit more complicated then that. See:
https://github.com/perl5-dbi/DBD-mysql/issues/78#issuecomment-282425847

The fix is simple. Understanding what the bug breaks is a lot more
complicated.
-- 
Brian May 

Bug#855424: mutt: don't check errno if read/write didn't error

[jl . debbugtrac]

To confirm, with mutt and imap, I also receive the error message:

> Error talking to localhost (Interrupted system call)

I am running an up-to-date Debian Stretch (NeoMutt 20170113 (1.7.2)).

Bug#856068: udev rules should be installed in /lib/udev/rules.d

[Michael Biebl]

Package: mouseemu
Version: 0.15-10
Severity: normal

Hi,

the package ships the following udev rules

mouseemu: /etc/udev/mouseemu.rules

those should be moved to /lib/udev/rules.d/
The /etc directory is reserved for local overrides.


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

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

Bug#856067: unblock: amavisd-new/1:2.10.1-4

[Brian May]

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

Request dialog concerning amavisd-new situation.

amavisd-new has a release critical bug. #847311. The justification given
was "causes non-serious data loss" presumably because emails were being
incorrectly classified as SPAM. This only happened for people using the
mysql functionality which is an optional feature of amavisd-new. I do
not agree this makes it RC, however I have not tried to change it,
however an earlier attempt to change it to important resulted it in
being changed back to grave.

The bug is not a bug in amavisd-new. It is a bug in libdbd-mysql-perl.
I have opened a bug #856064 (grave). There is an upstream patch:

https://github.com/perl5-dbi/DBD-mysql/pull/102

It has been proven to fix the problem:

https://github.com/perl5-dbi/DBD-mysql/issues/78#issuecomment-282270330

So question is, where do we proceed from here? I guess first step would
be to wait for a response for #856064.

I am also guessing tha since amavisd-new has already been removed from
testing, there is no chance of getting it back in. If this is the case,
is there any chance of getting it back into a future point release?

I believe amavisd-new is a somewhat popular package, not including it in
the next release is going to inconvenience a large number of people.

-- System Information:
Debian Release: 9.0
  APT prefers testing
  APT policy: (500, 'testing'), (500, 'stable'), (500, 'oldstable'), (100, 
'unstable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

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

Bug#856066: udev rules should be installed in /lib/udev/rules.d

[Michael Biebl]

Package: hama-slide-mouse-control
Version: 1.0-2
Severity: normal


Hi,

the package ships the following udev rules

hama-slide-mouse-control: /etc/udev/rules.d/60-hama-slide-mouse-control.rules

those should be moved to /lib/udev/rules.d/

The /etc directory is reserved for local overrides.





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

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

Bug#856065: udev rules should be installed in /lib/udev/rules.d

[Michael Biebl]

Package: waagent
Version: 2.2.2-1
Severity: normal

Hi,

the package ships the following udev rules

waagent: /etc/udev/rules.d/66-azure-storage.rules
waagent: /etc/udev/rules.d/99-azure-product-uuid.rules

those should be moved to /lib/udev/rules.d/

The /etc directory is reserved for local overrides.



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

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

Bug#856064: libdbd-mysql-perl: reads of floats currupted as 0

[Brian May]

Package: libdbd-mysql-perl
Version: 4.041-1
Severity: grave
Justification: causes non-serious data loss

When reading floats from mysql, they are always read as 0.

As values are currupted and as it is the cause of a grave bug in another
package, I have set this to grave.

Possibly only happens in Perl's tainted mode; I have asked for
confirmation.

Upstream bug report:
https://github.com/perl5-dbi/DBD-mysql/issues/78

Upstream patch:
https://github.com/perl5-dbi/DBD-mysql/pull/102

This is the cause of a RC bug against amavisd-new:
https://bugs.debian.org/847311

-- System Information:
Debian Release: 9.0
  APT prefers testing
  APT policy: (500, 'testing'), (500, 'stable'), (500, 'oldstable'), (100, 
'unstable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

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

Versions of packages libdbd-mysql-perl depends on:
ii  libc6 2.24-9
ii  libdbi-perl [perl-dbdabi-94]  1.636-1+b1
ii  libmariadbclient1810.1.21-5
ii  perl  5.24.1-1
ii  perl-base [perlapi-5.24.1]5.24.1-1

libdbd-mysql-perl recommends no packages.

libdbd-mysql-perl suggests no packages.

-- no debconf information

Bug#856005: systemd-udevd.service: Failed at step ADDRESS_FAMILIES during upgrade

[Marcel Šebek]

> Which version of libseccomp2 is installed?

Yes, that is the culprit, thank you.

I forgot that I had installed a libseccomp 2.1.1 in /usr/local/lib a few years 
ago.
I also have 2.3.1 in the system, but this one overrides it.

Thank you again for your help and sorry for the noise.

Bug#856063: CVE-2017-6197

[Thorsten Alteholz]

Package: radare2
Severity: important
Tags: security

Hi,

the following vulnerability was published for radare2.

CVE-2017-6197[0]:
| The r_read_* functions in libr/include/r_endian.h in radare2 1.2.1
| allow remote attackers to cause a denial of service (NULL pointer
| dereference and application crash) via a crafted binary file, as
| demonstrated by the r_read_le32 function.

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

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2017-6197
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-6197
Please adjust the affected versions in the BTS as needed.

Bug#856061: Please don't use obsolete libsysfs-dev any more

[Michael Biebl]

Source: s390-netdevice
Version: 0.0.53
Severity: important
User: mp...@debian.org
Usertags: libsysfs-deprecation

Hello,

Some years ago libsysfs (source package: sysfsutils) was written as an
abstraction layer for accessing /sys/. However, this turned out to be
a historical error and evolutionary dead end: It does not actually
abstract anything (it's just as specific to the Linux kernel and a
particular version thereof as /sys itself), and just adds unnecessary
complexity, RAM overhead, and bugs. Thus its development has ceased
years ago, in favor of programs just using /sys as it is.

In fact, most applications probably don't want to access /sys at all,
but use libudev [1] or gudev [2] instead. These provide a better API
for device enumeration, properties, and callbacks for hardware
changes.

This package is one of the few which still use the old libsysfs. Can
you please check with upstream to prepare a migration away from
libsysfs to using plain /sys or libudev?

Thank you for considering!


[1] http://www.kernel.org/pub/linux/utils/kernel/hotplug/libudev/
[2] http://www.kernel.org/pub/linux/utils/kernel/hotplug/gudev/



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

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

Bug#856062: Please don't use obsolete libsysfs-dev any more

[Michael Biebl]

Source: s390-tools
Version: 1.36.1-1
Severity: important
User: mp...@debian.org
Usertags: libsysfs-deprecation

Hello,

Some years ago libsysfs (source package: sysfsutils) was written as an
abstraction layer for accessing /sys/. However, this turned out to be
a historical error and evolutionary dead end: It does not actually
abstract anything (it's just as specific to the Linux kernel and a
particular version thereof as /sys itself), and just adds unnecessary
complexity, RAM overhead, and bugs. Thus its development has ceased
years ago, in favor of programs just using /sys as it is.

In fact, most applications probably don't want to access /sys at all,
but use libudev [1] or gudev [2] instead. These provide a better API
for device enumeration, properties, and callbacks for hardware
changes.

This package is one of the few which still use the old libsysfs. Can
you please check with upstream to prepare a migration away from
libsysfs to using plain /sys or libudev?

Thank you for considering!

[1] http://www.kernel.org/pub/linux/utils/kernel/hotplug/libudev/
[2] http://www.kernel.org/pub/linux/utils/kernel/hotplug/gudev/



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

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

Bug#856060: Please don't use obsolete libsysfs-dev any more

[Michael Biebl]

Source: s390-dasd
Version: 0.0.47
Severity: important
User: mp...@debian.org
Usertags: libsysfs-deprecation

Hello,

Some years ago libsysfs (source package: sysfsutils) was written as an
abstraction layer for accessing /sys/. However, this turned out to be
a historical error and evolutionary dead end: It does not actually
abstract anything (it's just as specific to the Linux kernel and a
particular version thereof as /sys itself), and just adds unnecessary
complexity, RAM overhead, and bugs. Thus its development has ceased
years ago, in favor of programs just using /sys as it is.

In fact, most applications probably don't want to access /sys at all,
but use libudev [1] or gudev [2] instead. These provide a better API
for device enumeration, properties, and callbacks for hardware
changes.

This package is one of the few which still use the old libsysfs. Can
you please check with upstream to prepare a migration away from
libsysfs to using plain /sys or libudev? I hope that we can drop the
old libsysfs entirely for wheezy.

Thank you for considering!


[1] http://www.kernel.org/pub/linux/utils/kernel/hotplug/libudev/
[2] http://www.kernel.org/pub/linux/utils/kernel/hotplug/gudev/



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

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

Bug#855937: apt-get's error messages don't include its name.

[Ralph Corderoy]

Hi Julian,

> Not going to happen. The output has been this way for almost 20 years, 

I agree it's been broken for almost 20 years.
I think apt-get has 20 years left in it yet.

> we're not suddenly going to prepend stuff to it - that would actually
> break things.

So perhaps an option could be added that improves errors to have the
progname at the start so other commands and scripts, users of apt-get,
can be lobbied to improve their invocation, including home-grown ones.
But we need the mechanism.

Cheers, Ralph.

Bug#837652: mate-settings-daemon: fills the logs with them parsing error messages

[Mike Gabriel]

Control: close -1

On  Mo 13 Feb 2017 17:43:27 CET, Francesco Potortì wrote:

The above issue should be gone since MATE 1.16 and GTK 3.22 is  
around. Right?


Yes.  It has gone away.  Thanks


Ack.

Thanks,
Mike
--

DAS-NETZWERKTEAM
mike gabriel, herweg 7, 24357 fleckeby
mobile: +49 (1520) 1976 148
landline: +49 (4354) 8390 139

GnuPG Fingerprint: 9BFB AEE8 6C0A A5FF BF22  0782 9AF4 6B30 2577 1B31
mail: mike.gabr...@das-netzwerkteam.de, http://das-netzwerkteam.de



pgp3ZWhLFoKRH.pgp
Description: Digitale PGP-Signatur

Bug#856005: systemd-udevd.service: Failed at step ADDRESS_FAMILIES during upgrade

[Michael Biebl]

Am 24.02.2017 um 22:32 schrieb Marcel Šebek:
> Yes, the problem is reproducible after reboot, the system cannot
> start udev manager and boots into single-user mode.
> 
> Maybe it is irrelevant for this bug report, but about a week ago, I
> accidentally upgraded my system to unstable (except kernel).
> The same bug was triggered as well, so I had to downgrade systemd.
> So now I have some mix of testing and unstable distribution.

Which version of libseccomp2 is installed?

-- 
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#855208: [pkg-go] Bug#855208: docker still broken

[Vincent Bernat]

 ❦ 24 février 2017 12:34 -0800, Norbert Kiesel  :

> What else can I do to get docker working again?

You can install the one from experimental. It works fine with runc and
containerd from unstable. At this point, Tim should just upload it to
unstable.
-- 
Use variable names that mean something.
- The Elements of Programming Style (Kernighan & Plauger)


signature.asc
Description: PGP signature

Bug#856059: new upstream version avaioable (1.2.0 released on 16 Aug 2016)

[Sylwester Arabas]

Package: latexdiff
Version: 1.1.1-2

Dear latexdiff Maintainers,

On Aug 16th 2016, a new version of latexdiff was released:
https://github.com/ftilmann/latexdiff/releases/tag/1.2.0

HTH,
Sylwester

Bug#856005: systemd-udevd.service: Failed at step ADDRESS_FAMILIES during upgrade

[Marcel Šebek]

Hi.

> Is this problem happening on the same system you filed this bug report,
>i.e. were you running kernel 4.9.0-2-amd64 during the upgrade?

Yes, this report is from the system which reporoduces the bug.

> Can you attach the full journalctl -alb output.

I've attached the journal -alb output.

> Is the problem reproducible after a reboot?

Yes, the problem is reproducible after reboot, the system cannot
start udev manager and boots into single-user mode.

Maybe it is irrelevant for this bug report, but about a week ago, I
accidentally upgraded my system to unstable (except kernel).
The same bug was triggered as well, so I had to downgrade systemd.
So now I have some mix of testing and unstable distribution.-- Logs begin at Fri 2017-02-24 22:14:17 CET, end at Fri 2017-02-24 22:18:21 
CET. --
Feb 24 22:14:17 themeline kernel: microcode: microcode updated early to 
revision 0xa0b, date = 2010-09-28
Feb 24 22:14:17 themeline kernel: Linux version 4.9.0-2-amd64 
(debian-ker...@lists.debian.org) (gcc version 6.3.0 20170205 (Debian 6.3.0-6) ) 
#1 SMP Debian 4.9.10-1 (2017-02-17)
Feb 24 22:14:17 themeline kernel: Command line: 
BOOT_IMAGE=/vmlinuz-4.9.0-2-amd64 root=/dev/mapper/vg1-root64 ro
Feb 24 22:14:17 themeline kernel: x86/fpu: Supporting XSAVE feature 0x001: 'x87 
floating point registers'
Feb 24 22:14:17 themeline kernel: x86/fpu: Supporting XSAVE feature 0x002: 'SSE 
registers'
Feb 24 22:14:17 themeline kernel: x86/fpu: Enabled xstate features 0x3, context 
size is 576 bytes, using 'standard' format.
Feb 24 22:14:17 themeline kernel: x86/fpu: Using 'eager' FPU context switches.
Feb 24 22:14:17 themeline kernel: e820: BIOS-provided physical RAM map:
Feb 24 22:14:17 themeline kernel: BIOS-e820: [mem 
0x-0x0009fbff] usable
Feb 24 22:14:17 themeline kernel: BIOS-e820: [mem 
0x0009fc00-0x0009] reserved
Feb 24 22:14:17 themeline kernel: BIOS-e820: [mem 
0x000e4000-0x000f] reserved
Feb 24 22:14:17 themeline kernel: BIOS-e820: [mem 
0x0010-0x7ff8] usable
Feb 24 22:14:17 themeline kernel: BIOS-e820: [mem 
0x7ff9-0x7ff9dfff] ACPI data
Feb 24 22:14:17 themeline kernel: BIOS-e820: [mem 
0x7ff9e000-0x7ffc] ACPI NVS
Feb 24 22:14:17 themeline kernel: BIOS-e820: [mem 
0x7ffd-0x7ffddfff] reserved
Feb 24 22:14:17 themeline kernel: BIOS-e820: [mem 
0x7ffe-0x7fff] reserved
Feb 24 22:14:17 themeline kernel: BIOS-e820: [mem 
0xfee0-0xfee00fff] reserved
Feb 24 22:14:17 themeline kernel: BIOS-e820: [mem 
0xfff0-0x] reserved
Feb 24 22:14:17 themeline kernel: NX (Execute Disable) protection: active
Feb 24 22:14:17 themeline kernel: SMBIOS 2.5 present.
Feb 24 22:14:17 themeline kernel: DMI: System manufacturer System Product 
Name/P5KPL-SE, BIOS 050706/10/2009
Feb 24 22:14:17 themeline kernel: e820: update [mem 0x-0x0fff] 
usable ==> reserved
Feb 24 22:14:17 themeline kernel: e820: remove [mem 0x000a-0x000f] 
usable
Feb 24 22:14:17 themeline kernel: e820: last_pfn = 0x7ff90 max_arch_pfn = 
0x4
Feb 24 22:14:17 themeline kernel: MTRR default type: uncachable
Feb 24 22:14:17 themeline kernel: MTRR fixed ranges enabled:
Feb 24 22:14:17 themeline kernel:   0-9 write-back
Feb 24 22:14:17 themeline kernel:   A-B uncachable
Feb 24 22:14:17 themeline kernel:   C-D write-protect
Feb 24 22:14:17 themeline kernel:   E-E write-through
Feb 24 22:14:17 themeline kernel:   F-F write-protect
Feb 24 22:14:17 themeline kernel: MTRR variable ranges enabled:
Feb 24 22:14:17 themeline kernel:   0 base 0 mask F8000 write-back
Feb 24 22:14:17 themeline kernel:   1 disabled
Feb 24 22:14:17 themeline kernel:   2 disabled
Feb 24 22:14:17 themeline kernel:   3 disabled
Feb 24 22:14:17 themeline kernel:   4 disabled
Feb 24 22:14:17 themeline kernel:   5 disabled
Feb 24 22:14:17 themeline kernel:   6 disabled
Feb 24 22:14:17 themeline kernel:   7 disabled
Feb 24 22:14:17 themeline kernel: x86/PAT: Configuration [0-7]: WB  WC  UC- UC  
WB  WC  UC- WT  
Feb 24 22:14:17 themeline kernel: found SMP MP-table at [mem 
0x000ff780-0x000ff78f] mapped at [8da4c00ff780]
Feb 24 22:14:17 themeline kernel: Base memory trampoline at [8da4c0099000] 
99000 size 24576
Feb 24 22:14:17 themeline kernel: BRK [0x3d14c000, 0x3d14cfff] PGTABLE
Feb 24 22:14:17 themeline kernel: BRK [0x3d14d000, 0x3d14dfff] PGTABLE
Feb 24 22:14:17 themeline kernel: BRK [0x3d14e000, 0x3d14efff] PGTABLE
Feb 24 22:14:17 themeline kernel: BRK [0x3d14f000, 0x3d14] PGTABLE
Feb 24 22:14:17 themeline kernel: BRK [0x3d15, 0x3d150fff] PGTABLE
Feb 24 22:14:17 themeline kernel: BRK [0x3d151000, 0x3d151fff] PGTABLE
Feb 24 22:14:17 themeline kernel: RAMDISK: [mem 0x358e3000-0x36c68fff]
Feb 24 22:14:17 themeline kernel: ACPI: Early table checksum verification 
disabled
Feb 24 22:14:17 themeline 

Bug#856058: freeplane: Fails to export to pdf due to missing class (org/apache/avalon/framework/configuration/Configurable)

[Hans Joachim Desserud]

Package: freeplane
Version: 1.5.18-1
Severity: normal

Dear Maintainer,

Freeplane shows an error dialog when attempting to export to pdf.

Steps to reproduce:
1. Start freeplane
2. File -> Export map
3. Select pdf as file type
4. Press Save

Instead of storing a pdf, a dialog appear with the following error 
message:


STDERR: java.lang.NoClassDefFoundError: 
org/apache/avalon/framework/configuration/Configurable

STDERR: at java.lang.ClassLoader.defineClass1(Native Method)
STDERR: at java.lang.ClassLoader.defineClass(ClassLoader.java:763)
STDERR: 	at 
org.knopflerfish.framework.BundleClassLoader.access$400(BundleClassLoader.java:60)
STDERR: 	at 
org.knopflerfish.framework.BundleClassLoader$1.get(BundleClassLoader.java:956)
STDERR: 	at 
org.knopflerfish.framework.BundleClassLoader.searchFor0(BundleClassLoader.java:812)
STDERR: 	at 
org.knopflerfish.framework.BundleClassLoader.searchFor(BundleClassLoader.java:615)
STDERR: 	at 
org.knopflerfish.framework.SecurePermissionOps$3.run(SecurePermissionOps.java:551)

STDERR: at java.security.AccessController.doPrivileged(Native Method)
STDERR: 	at 
org.knopflerfish.framework.SecurePermissionOps.callSearchFor(SecurePermissionOps.java:548)
STDERR: 	at 
org.knopflerfish.framework.BundleClassLoader.findClass(BundleClassLoader.java:155)
STDERR: 	at 
org.knopflerfish.framework.BundleClassLoader.loadClass(BundleClassLoader.java:306)

STDERR: at java.lang.ClassLoader.loadClass(ClassLoader.java:357)
STDERR: at java.lang.ClassLoader.defineClass1(Native Method)
STDERR: at java.lang.ClassLoader.defineClass(ClassLoader.java:763)
STDERR: 	at 
org.knopflerfish.framework.BundleClassLoader.access$400(BundleClassLoader.java:60)
STDERR: 	at 
org.knopflerfish.framework.BundleClassLoader$1.get(BundleClassLoader.java:956)
STDERR: 	at 
org.knopflerfish.framework.BundleClassLoader.searchFor0(BundleClassLoader.java:812)
STDERR: 	at 
org.knopflerfish.framework.BundleClassLoader.searchFor(BundleClassLoader.java:615)
STDERR: 	at 
org.knopflerfish.framework.SecurePermissionOps$3.run(SecurePermissionOps.java:551)

STDERR: at java.security.AccessController.doPrivileged(Native Method)
STDERR: 	at 
org.knopflerfish.framework.SecurePermissionOps.callSearchFor(SecurePermissionOps.java:548)
STDERR: 	at 
org.knopflerfish.framework.BundleClassLoader.findClass(BundleClassLoader.java:155)
STDERR: 	at 
org.knopflerfish.framework.BundleClassLoader.loadClass(BundleClassLoader.java:306)

STDERR: at java.lang.ClassLoader.loadClass(ClassLoader.java:357)
STDERR: at org.freeplane.plugin.svg.ExportPdf.export(ExportPdf.java:60)
STDERR: 	at 
org.freeplane.features.export.mindmapmode.ExportDialog.export(ExportDialog.java:190)
STDERR: 	at 
org.freeplane.features.export.mindmapmode.ExportAction.export(ExportAction.java:54)
STDERR: 	at 
org.freeplane.features.export.mindmapmode.ExportAction.actionPerformed(ExportAction.java:50)
STDERR: 	at 
org.freeplane.core.ui.AccelerateableAction.actionPerformed(AccelerateableAction.java:91)
STDERR: 	at 
javax.swing.AbstractButton.fireActionPerformed(AbstractButton.java:2022)
STDERR: 	at 
javax.swing.AbstractButton$Handler.actionPerformed(AbstractButton.java:2348)
STDERR: 	at 
javax.swing.DefaultButtonModel.fireActionPerformed(DefaultButtonModel.java:402)
STDERR: 	at 
javax.swing.DefaultButtonModel.setPressed(DefaultButtonModel.java:259)

STDERR: at javax.swing.AbstractButton.doClick(AbstractButton.java:376)
STDERR: 	at 
javax.swing.plaf.basic.BasicMenuItemUI.doClick(BasicMenuItemUI.java:833)
STDERR: 	at 
javax.swing.plaf.basic.BasicMenuItemUI$Handler.mouseReleased(BasicMenuItemUI.java:877)

STDERR: at java.awt.Component.processMouseEvent(Component.java:6533)
STDERR: 	at 
javax.swing.JComponent.processMouseEvent(JComponent.java:3324)

STDERR: at java.awt.Component.processEvent(Component.java:6298)
STDERR: at java.awt.Container.processEvent(Container.java:2236)
STDERR: at java.awt.Component.dispatchEventImpl(Component.java:4889)
STDERR: at java.awt.Container.dispatchEventImpl(Container.java:2294)
STDERR: at java.awt.Component.dispatchEvent(Component.java:4711)
STDERR: 	at 
java.awt.LightweightDispatcher.retargetMouseEvent(Container.java:4888)
STDERR: 	at 
java.awt.LightweightDispatcher.processMouseEvent(Container.java:4525)
STDERR: 	at 
java.awt.LightweightDispatcher.dispatchEvent(Container.java:4466)

STDERR: at java.awt.Container.dispatchEventImpl(Container.java:2280)
STDERR: at java.awt.Window.dispatchEventImpl(Window.java:2746)
STDERR: at java.awt.Component.dispatchEvent(Component.java:4711)
STDERR: at java.awt.EventQueue.dispatchEventImpl(EventQueue.java:758)
STDERR: at java.awt.EventQueue.access$500(EventQueue.java:97)
STDERR: at java.awt.EventQueue$3.run(EventQueue.java:709)
STDERR: at java.awt.EventQueue$3.run(EventQueue.java:703)
STDERR: at 

Bug#813226: tzdata config script ignores /etc/timezone on non-interactive configuration

[Tomáš Ebenlendr]

On Fri, 12 Feb 2016 10:01:34 +0100
Aurelien Jarno  wrote:

> On 2016-02-02 00:23, YAMADA Tsuyoshi wrote:
> > 2016-02-01 16:43 GMT+09:00 Aurelien Jarno :
> > > I don't think it is a bug. The correct way to configure the
> > > timezone has always been to change /etc/localtime symlink, ie in
> > > your case by doing "ln
> > > -sf /usr/share/zoneinfo/Asia/Tokyo /etc/localtime". This is what
> > > desktop environments do when changing the timezone and it is what
> > > systemd expects.
> > >
> > > Changing /etc/timezone worked in some cases before as we use to
> > > store /etc/localtime as a copy of the file instead of a symlink
> > > when possible, in order to allow the timezone to be correct
> > > without a /usr partition. This is not needed anymore given /usr
> > > is now mount from the initramfs when needed.
> > 
> > Hmm, I understand the correct way, but many people are using
> > incorrect way. ("echo Foo/Bar > /etc/timezone" and
> > "dpkg-reconfigure -f noninteractive tzdata")
> > 
> > Please see github:
> > https://github.com/search?q=%2Fetc%2Ftimezone+dpkg-reconfigure+noninteractive+tzdata=Code=%E2%9C%93
> > 
> > There are about 4,000 codes!
> > 
> > I think this incompatibility for those codes is not so good.
> > 
> > I propose a patch for debian/tzdata.config
> > (/var/lib/dpkg/info/tzdata.config):
> > 
> >   --- /tmp/tzdata.config.bak 2016-01-29 20:28:52.0 +
> >   +++ tzdata.config 2016-02-01 14:42:09.462282218 +
> >   @@ -326,15 +326,6 @@
> >esac
> >}
> > 
> >   -# If /etc/localtime is a link, update /etc/timezone
> >   -if [ -L /etc/localtime ] ; then
> >   -TIMEZONE="$(readlink /etc/localtime)"
> >   -TIMEZONE="${TIMEZONE#/usr/share/zoneinfo/}"
> >   -if [ -f "/usr/share/zoneinfo/$TIMEZONE" ] ; then
> >   -echo ${TIMEZONE} > /etc/timezone
> >   -fi
> >   -fi
> >   -
> ># Read /etc/timezone
> >if [ -e /etc/timezone ]; then
> >TIMEZONE="$(head -n 1 /etc/timezone)"
> >   @@ -350,6 +341,15 @@
> >fi
> >fi
> > 
> >   +# If /etc/localtime is a link, update /etc/timezone
> >   +if [ -L /etc/localtime ] ; then
> >   +TIMEZONE="$(readlink /etc/localtime)"
> >   +TIMEZONE="${TIMEZONE#/usr/share/zoneinfo/}"
> >   +if [ -f "/usr/share/zoneinfo/$TIMEZONE" ] ; then
> >   +echo ${TIMEZONE} > /etc/timezone
> >   +fi
> >   +fi
> >   +
> ># The timezone is already configured
> >if [ -e /etc/timezone ] && [ -e /etc/localtime ] ; then
> ># Don't ask the user, except if he/she explicitely asked that
> > 
> > 
> > This patch will keep compatibility like this:
> > 
> >   root@031baca8faac:~# echo Asia/Tokyo > /etc/timezone
> >   root@031baca8faac:~# readlink /etc/localtime
> >   /usr/share/zoneinfo/Etc/UTC
> >   root@031baca8faac:~# dpkg-reconfigure -f noninteractive tzdata
> > 
> >   Current default time zone: 'Asia/Tokyo'
> >   Local time is now:  Mon Feb  1 23:45:19 JST 2016.
> >   Universal Time is now:  Mon Feb  1 14:45:19 UTC 2016.
> > 
> >   root@031baca8faac:~# cat /etc/timezone
> >   Asia/Tokyo
> >   root@031baca8faac:~# readlink /etc/localtime
> >   /usr/share/zoneinfo/Asia/Tokyo
> > 
> > Could you please consider this patch?
> 
> This patch will break all software which change /etc/localtime without
> changing /etc/timezone. I don't know if it is better to break the
> compatibility with external scripts or with software we ship in
> debian.
> 
> Aurelien
> 

There is also possibility, to decide by mtime of /etc/localtime
and /etc/timezone. The newer file will be the source of truth.
Then both types of software will work, provided that dpkg-reconfigure
will be run to synchronize state of those files. This is not a clean
solution (and I would hesitate to accept it), but your opinion may be
different, so I wanted to mention this idea. Anyways, the final
solution should be documented, as I mentioned in my previous email.



-- 
*Úspěch, charisma a inspirace v jednom magazínu. *
*Čtěte o nejúspěšnějších ženách Česka.*

*Objednejte si exkluzivní magazín Hospodářských novin Top ženy Česka 2016 
.*


signature.asc
Description: PGP signature

Bug#856049: ethtool: Can not use --change-eeprom option

[Yvan Masson]

Thanks for this fast and precise answer!

> As for why the driver failed to access the EEPROM, I can't tell -
> there are several possible error cases.  It might be worth trying to
> pass the EEPROM contents as a binary file on stdin, instead of trying
> to set a single byte.

I already tried this, and if I am not wrong in the procedure, this
produces the same error:
- dump EEPROM from working NIC on another laptop:
ethtool --eeprom-dump enp2s1 raw on > dump
- write dump file on faulty NIC:
ethtool --change-eeprom enp2s1 magic 0x100e8086 < dump

> As the e1000 driver is no longer maintained by Intel, I'm afraid these
> bugs are unlikely to be fixed.

So I will have to try other ways :-(

Regards,
Yvan



pgpna0MAGgZyI.pgp
Description: Signature digitale OpenPGP

Bug#850405: Two node-imurmurhash ITPs

[Adrian Bunk]

Control: forcemerge -1 854532

Hi Roshan, hi Aarti,

you both submitted ITPs for node-imurmurhash.

Please coordinate on who of you will actually package it.

cu
Adrian

-- 

   "Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
   "Only a promise," Lao Er said.
   Pearl S. Buck - Dragon Seed

Bug#854490: RFP: xva-img -- Citrix XenServer .xva disk extraction tool

[Axel Beckert]

Hi,

Axel Beckert wrote:
> I'll probably come up with a complete packaging for this tool, but don't
> want to maintain it alone, hence RFP and not ITP.

My packaging is now at
https://anonscm.debian.org/git/collab-maint/xva-img.git

The only thing yet missing is a proper man page, hence it still
throughs these two lintian warnings:

W: xva-img source: dh-make-template-in-source debian/manpage.1.ex
W: xva-img: binary-without-manpage usr/bin/xva-img

Regards, Axel
-- 
 ,''`.  |  Axel Beckert , http://people.debian.org/~abe/
: :' :  |  Debian Developer, ftp.ch.debian.org Admin
`. `'   |  4096R: 2517 B724 C5F6 CA99 5329  6E61 2FF9 CD59 6126 16B5
  `-|  1024D: F067 EA27 26B9 C3FC 1486  202E C09E 1D89 9593 0EDE

Bug#856057: opendmarc: Conflicting/outdated documentation

[Gerhard Mack]

Package: opendmarc
Version: 1.3.2~Beta1-2
Severity: normal

Dear Maintainer,

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

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

*** End of the template - remove these template lines ***
This has been driving me crazy!  /usr/share/doc/opendmarc/README.gz points to 
/etc/default/opendmarc which no longer exists.
/usr/share/zcot/opendmarc/NEWS.Debian.gz finally explained that the 
/etc/default/opendmarc is now 
/etc/systemd/system/opendmarc.service.d/overrride.conf but offers no advice on 
the format of that file.

Please update the documentation to be less confusing.


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

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

Versions of packages opendmarc depends on:
ii  adduser 3.115
ii  libbsd0 0.8.3-1
ii  libc6   2.24-9
ii  libmilter1.0.1  8.15.2-8
ii  libopendmarc2   1.3.2~Beta1-2
ii  libspf2-2   1.2.10-7+b1
ii  lsb-base9.20161125
ii  publicsuffix20170117-1

Versions of packages opendmarc recommends:
ii  libdbd-mysql-perl 4.041-1
ii  libdbi-perl   1.636-1+b1
ii  libhttp-message-perl  6.11-1
ii  libopendbx1   1.4.6-11
ii  libopendbx1-mysql 1.4.6-11
ii  libswitch-perl2.17-2
ii  perl  5.24.1-1
pn  perl:any  

opendmarc suggests no packages.

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

-- no debconf information

Bug#856056: tangerine: FTBFS on arm64

[Edmund Grimley Evans]

Source: tangerine
Version: 0.3.4-6
Tags: patch
User: debian-...@lists.debian.org
Usertags: arm64

It failed to build on arm64:

http://buildd.debian.org/status/package.php?p=tangerine=sid

The error was:

src/inotify-syscalls.h:47:3: error: #error "Unsupported architecture!"
 # error "Unsupported architecture!"

I think the attached trivial patch fixes it.
diff -ru tangerine-0.3.4.orig/libtangglue/src/inotify-syscalls.h tangerine-0.3.4/libtangglue/src/inotify-syscalls.h
--- tangerine-0.3.4.orig/libtangglue/src/inotify-syscalls.h
+++ tangerine-0.3.4/libtangglue/src/inotify-syscalls.h
@@ -43,13 +43,21 @@
 # define __NR_inotify_init	318
 # define __NR_inotify_add_watch	319
 # define __NR_inotify_rm_watch	320
+#elif defined (__aarch64__)
+# define __NR_inotify_init1	26
+# define __NR_inotify_add_watch	27
+# define __NR_inotify_rm_watch	28
 #else
 # error "Unsupported architecture!"
 #endif
 
 static inline int inotify_init (void)
 {
+#ifdef __NR_inotify_init
 	return syscall (__NR_inotify_init);
+#else
+	return syscall (__NR_inotify_init1, 0);
+#endif
 }
 
 static inline int inotify_add_watch (int fd, const char *name, __u32 mask)

Bug#855208: docker still broken

[Norbert Kiesel]

Hi,

docker stopped working for me (`docker ps` etc simply hangs).  I
manually downgraded runc using `dpkg -i
/home/nkiesel/Downloads/runc_0.1.1+dfsg1-2_amd64.deb`
but this did not make a difference.

Otherwise my system is up-to-date (`aptitude update; aptitude
full-upgrade` only reports `runc`), and I have

# dpkg -l '*docker*' '*runc*'
Desired=Unknown/Install/Remove/Purge/Hold
| Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend
|/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad)
||/ Name   Version
 Architecture Description
+++-==---==
un  docker 
(no description available)
ii  docker-compose 1.8.0-2
 all  Punctual, lightweight
development environments using Docker
un  docker-doc 
(no description available)
ii  docker.io  1.11.2~ds1-6
 amd64Linux container runtime
ii  libnss-docker:amd640.02-1
 amd64nss module for finding Docker
containers
ii  python-docker  1.9.0-1
 all  Python wrapper to access
docker.io's control socket
ii  python-dockerpty   0.4.1-1
 all  Pseudo-tty handler for docker
Python client (Python 2.x)
ii  python3-docker 1.9.0-1
 all  Python 3 wrapper to access
docker.io's control socket
ii  runc   0.1.1+dfsg1-2
 amd64Open Container Project - runtime
ii  systemd-docker 0.2.1+dfsg-2
 amd64wrapper for "docker run" to
handle systemd quirks

What else can I do to get docker working again?

Bug#855911: linux-image-4.9.0-1-armmp: MMC failure on A20-OLinuXIno-LIME2

[Thibaut Girka]

I have made some more tests using the “spew” and “stress” packages, but it
doesn't seem to cause the issue. So far, it mainly happened during package
installation (thus causing the additional pain of leaving some packages in a
broken state).

I have been unable to reproduce the issue with older kernels, but since I don't
have a reliable way to trigger it, and that it took up to several hours to
manifest, I cannot rule out this bug being present in older kernel verions, nor
rule out it being a u-boot-related bug rather than a kernel one.
(I am using the u-boot binary 
/usr/lib/u-boot/A20-OLinuXino-Lime2/u-boot-sunxi-with-spl.bin
from u-boot-sunxi=2016.11+dfsg1-3 on both systems)

Another annoying issue with this bug is that a full power cycle is needed for
the µSD reader to be usable: even if I manage to trigger a reboot (opening
/dev/watchdog for instance), the system won't actually be brought up again,
and I have to physically switch it off and back. Not having any output set-up
for this system, I can only presume that it fails to boot due to the µSD reader
still being in a messed-up state and needing a full power-cycle to recover.

Bug#855705: [munin-monitoring/munin] munin-cgi-graph CGI::param security problem (#721)

[Holger Levsen]

On Fri, Feb 24, 2017 at 09:00:00PM +0100, Jonas Meurer wrote:
> I already prepared 2.0.6-4+deb7u3 with Thomaž' patch for
> wheezy-security.

thanks for this, though maybe the patch from 2.0.31 will be better?

(once 2.0.31 is released which Steve planned to do today…)

> I'm inclined to upload munin 2.0.6-4+deb7u3 with Thomaž' patch to
> wheezy-security tomorrow.

see above…
 
> Holger, do you take care of the upload to unstable yourself?

yes

> Probably
> there a straightforward patch (without too much new code) would be good
> as well, to simplify/speed up the transition to Stretch.

I rather hope that 2.0.31 will be suitable for this ;-)


-- 
cheers,
Holger


signature.asc
Description: Digital signature

Bug#780162: FreeBSD notes about SCT

[Daniel Pocock]

Looking at the Wikipedia article about Error Recovery Control, it
mentions[1] the FreeBSD handles this better.

Just what do they do and could it be done in Debian?  Or is somebody
already working on something like this for the kernel?

"In a software RAID configuration whether or not TLER is helpful is
dependent on the operating system. For example, in FreeBSD the ATA/CAM
stack controls the timeouts, and is set to progressively increase the
timeouts as they occur. Thus, if a desktop disk without TLER starts
delaying a response to a sector read, FreeBSD will retry the read with
successively longer timeouts to prevent prematurely dropping the disk
out of the array."






1.
https://en.wikipedia.org/wiki/Error_recovery_control#Standalone_vs._RAID_considerations

Bug#780162: syslog / dmesg warnings

[Daniel Pocock]

I understand that the mdadm maintainer chose[1] not to include a patch
for changing SCT values, but maybe md, lvm, btrfs and friends could be
patched to simply check the SCT values and emit warnings through syslog
or dmesg if they find SCT has not bee configured before a device is
assembled or mounted?



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

Bug#582660: ProFTPD-Basic problem with

[Hilmar Preuße]

Am 22.05.2010 um 18:47 tastete Андрей Василишин:

Hi all,

https://bugs.debian.org/582660


I am using proftpd-basic 1.3.2e-4 and proftpd-basic 1.3.3-1 on other
server.
I am using an example from
http://www.proftpd.org/docs/howto/Limit.html for "First, a common
configuration: an upload-only directory" My config:


Are you still able to reproduce the problem?

Further your example is not a verbatim copy from the web page.




  DenyAll








>
In the example a specific directory has been specified. Are you able to 
reproduce the problem when specifying "/emili" in this config?


Thanks,
  Hilmar
--
#206401 http://counter.li.org

Bug#856051: more verbose output for checkbashisms (devscripts)

[Adam D. Barratt]

Control: tags -1 + patch

On Fri, 2017-02-24 at 19:13 +, Dmitriy Getman wrote:
> package: devscripts
> version: 2.17.1
> I added more verbose output for script checkbashisms:
> possible bashism in ../bash/saymyname line 45 ($MACHTYPE should be
> "$(gcc -dumpmachine"):
>  
> possible bashism in ../bash/saymyname line 188 ($HOSTNAME should be
> "$(uname -n)"):

Thanks for the update.

In general, please provide patches against the existing script, rather
than complete new scripts. I've done so now, and attached the patch.

Regards,

Adam

--- scripts/checkbashisms.pl	2016-10-01 16:15:56.659665607 +0100
+++ /home/adam/.cache/evolution/tmp/evolution-adam-UUToFC/checkbashisms.pl	2017-02-24 20:10:51.680837263 +
@@ -665,8 +665,10 @@
 	qr'\$\{(?:\w+|@|\*)(/.+?){1,2}\}' =>  q<${parm/?/pat[/str]}>,
 	qr'\$\{\#?\w+\[.+\](?:[/,:#%^].+?)?\}' => q,
 	qr'\$\{?RANDOM\}?\b' =>  q<$RANDOM>,
-	qr'\$\{?(OS|MACH)TYPE\}?\b'   => q<$(OS|MACH)TYPE>,
-	qr'\$\{?HOST(TYPE|NAME)\}?\b' => q<$HOST(TYPE|NAME)>,
+	qr'\$\{?OSTYPE\}?\b'   => q<$OSTYPE>,
+	qr'\$\{?MACHTYPE\}?\b'   => q<$MACHTYPE should be "$(gcc -dumpmachine">,
+	qr'\$\{?HOSTTYPE\}?\b' => q<$HOSTTYPE should be "$(uname -m)">,
+	qr'\$\{?HOSTNAME\}?\b' => q<$HOSTNAME should be "$(uname -n)">,
 	qr'\$\{?DIRSTACK\}?\b'=> q<$DIRSTACK>,
 	qr'\$\{?EUID\}?\b'	  => q<$EUID should be "$(id -u)">,
 	qr'\$\{?UID\}?\b'	   => q<$UID should be "$(id -ru)">,

Bug#856055: NetCDF import broken on amd64

[Timo Korvola]

Package: dx
Version: 1:4.4.4-9+b1

Import of NetCDF files produces incorrect integer values on systems 
where long is not 32 bits.  This can be seen by running the attached 
nctest.net and importing nctest.nc.  The file can be inspected with

ncdump.  The connections, being int valued, will be imported incorrectly.

The attached patch should fix the problem.  The erroneous code assumed 
that the NetCDF type NC_LONG corresponds to long.  However, NC_LONG is a 
deprecated alias for NC_INT and by definition 32 bits, whereas long 
varies by platform.  These days it is better to leave such type 
conversions to the NetCDF library, which provides likely more efficient 
and correct routines.


The patch also fixes a debug output routine, which casts pointers into 
unsigned int for printing.  It seems that the routine is never called 
but at least compiler warnings are eliminated.


--
Timo Korvola


nctest.nc
Description: Cdf file
//
// time: Fri Feb 24 00:10:21 2017
//
// version: 3.2.0 (format), 4.4.4 (DX)
//
//
// MODULE main
// workspace: width = 321, height = 499
// layout: snap = 0, width = 50, height = 50, align = NN
//
macro main(
) -> (
) {
// 
// node FileSelector[1]: x = 72, y = 14, inputs = 0, label = FileSelector
// output[1]: visible = 1, type = 32, value = "/home/thk/src/test/nctest.nc"
// output[2]: visible = 1, type = 32, value = "nctest.nc"
//
// 
// node Import[1]: x = 90, y = 118, inputs = 6, label = Import
//
main_Import_1_out_1 = 
Import(
main_FileSelector_1_out_1,
main_Import_1_in_2,
main_Import_1_in_3,
main_Import_1_in_4,
main_Import_1_in_5,
main_Import_1_in_6
) [instance: 1, cache: 1];
// 
// node AutoColor[1]: x = 138, y = 191, inputs = 10, label = AutoColor
//
main_AutoColor_1_out_1,
main_AutoColor_1_out_2 = 
AutoColor(
main_Import_1_out_1,
main_AutoColor_1_in_2,
main_AutoColor_1_in_3,
main_AutoColor_1_in_4,
main_AutoColor_1_in_5,
main_AutoColor_1_in_6,
main_AutoColor_1_in_7,
main_AutoColor_1_in_8,
main_AutoColor_1_in_9,
main_AutoColor_1_in_10
) [instance: 1, cache: 1];
// 
// node AutoGlyph[1]: x = 201, y = 278, inputs = 7, label = AutoGlyph
// input[2]: defaulting = 0, visible = 1, type = 32, value = "text"
//
main_AutoGlyph_1_out_1 = 
AutoGlyph(
main_AutoColor_1_out_1,
main_AutoGlyph_1_in_2,
main_AutoGlyph_1_in_3,
main_AutoGlyph_1_in_4,
main_AutoGlyph_1_in_5,
main_AutoGlyph_1_in_6,
main_AutoGlyph_1_in_7
) [instance: 1, cache: 1];
// 
// node Tube[1]: x = 114, y = 280, inputs = 4, label = Tube
//
main_Tube_1_out_1 = 
Tube(
main_AutoColor_1_out_1,
main_Tube_1_in_2,
main_Tube_1_in_3,
main_Tube_1_in_4
) [instance: 1, cache: 1];
// 
// node Collect[1]: x = 177, y = 360, inputs = 2, label = Collect
//
main_Collect_1_out_1 = 
Collect(
main_Tube_1_out_1,
main_AutoGlyph_1_out_1
) [instance: 1, cache: 1];
// 
// node Image[1]: x = 175, y = 437, inputs = 49, label = Image
// input[1]: defaulting = 0, visible = 0, type = 67108863, value = "Image_1"
// input[4]: defaulting = 0, visible = 0, type = 1, value = 1
// input[5]: defaulting = 0, visible = 0, type = 8, value = [0.0407761 
0.608095 3.3903]
// input[6]: defaulting = 0, visible = 0, type = 8, value = [1.05857 
-0.449439 16.9762]
// input[7]: defaulting = 1, visible = 0, type = 5, value = 7.32305
// input[8]: defaulting = 0, visible = 0, type = 1, value = 640
// input[9]: defaulting = 0, visible = 0, type = 5, value = 0.75
// input[10]: defaulting = 0, visible = 0, type = 8, value = [0.0102178 
0.996991 0.076841]
// input[11]: defaulting = 0, visible = 0, type = 5, value = 30.0001
// input[12]: defaulting = 0, visible = 0, type = 1, value = 1
// input[14]: defaulting = 0, visible = 0, type = 1, value = 1
// input[15]: defaulting = 1, visible = 0, type = 32, value = "none"
// input[16]: defaulting = 1, visible = 0, type = 32, value = "none"
// input[17]: defaulting = 1, visible = 0, type = 1, value = 1
// input[18]: defaulting = 1, visible = 0, type = 1, value = 1
// input[19]: defaulting = 0, visible = 0, type = 1, value = 0
// input[29]: defaulting = 1, visible = 0, type = 3, value = 0
// input[41]: defaulting = 0, visible = 0, type = 32, value = "navigate"
// depth: value = 24
// window: position = (0.3708,0.4114), size = 0.3893x0.4971, screen = 0
// internal caching: 1
//
main_Image_1_out_1,
main_Image_1_out_2,
main_Image_1_out_3 = 
Image(
main_Image_1_in_1,
main_Collect_1_out_1,
main_Image_1_in_3,
main_Image_1_in_4,
main_Image_1_in_5,
main_Image_1_in_6,
main_Image_1_in_7,
main_Image_1_in_8,
main_Image_1_in_9,
main_Image_1_in_10,
main_Image_1_in_11,
main_Image_1_in_12,
main_Image_1_in_13,

Bug#855705: [munin-monitoring/munin] munin-cgi-graph CGI::param security problem (#721)

[Jonas Meurer]

Hi Holger, hi Steve,

On Fri, 24 Feb 2017 11:24:42 + Holger Levsen 
wrote:
> On Fri, Feb 24, 2017 at 01:37:55AM -0800, mejo- wrote:
> > I just gave 2.0.6 (from Debian/Wheezy) a try and indeed it's
> > vulnerable too.
> > The proposed patch by Tomaž Šolc from Debian Bugreport #855705
> > fixes this particular vulnerability.
> 
> thanks, mejo, for confirming this both!

I already prepared 2.0.6-4+deb7u3 with Thomaž' patch for
wheezy-security. As Steve announced an upstream fix for the 2.4 branch
for today, I waited some longer with the upload.

On Thu, 23 Feb 2017 19:24:20 +0100 Steve Schnepp
 wrote:
> The patch is indeed quite minimal, and address the issue. It therefore
> looks very ok to me.
>
> Note that I did not plan to take it as is, but use the 2.999.x code
> snippet instead which doesn't have the bug.
>
> I'll plan to do a secfix upstream release tomorrow so you'll have the
> choice of which patch you take ;-)

Steve, do you still plan to do the upstream fix anytime soon? Also, as
you intend to backport the changes from munin 2.999, I gusss that your
fix will be much more intrusive, right?

I'm inclined to upload munin 2.0.6-4+deb7u3 with Thomaž' patch to
wheezy-security tomorrow.

Holger, do you take care of the upload to unstable yourself? Probably
there a straightforward patch (without too much new code) would be good
as well, to simplify/speed up the transition to Stretch.

Cheers,
 jonas



signature.asc
Description: OpenPGP digital signature

Bug#855902: [Pkg-xfce-devel] Bug#855902: Bug#855902: xfce4: Moving mouse won't bring a locked screen back. Have to use Ctrl-Alt-F2, Ctrl-Alt-F1, which brings the Desktop Manager (such as GDM) login sc

[Hong Xu]

On 02/24/2017 08:09 AM, Yves-Alexis Perez wrote:
> On Fri, 2017-02-24 at 01:41 -0800, Hong Xu wrote:
>> On 02/23/2017 01:17 PM, Yves-Alexis Perez wrote:
>>> control: tag -1 moreinfo
>>>
>>> On Wed, 2017-02-22 at 22:53 -0800, Hong Xu wrote:
 If wait long enough after the screen is locked, I have to use "Ctrl-Alt-
 F2,
 Ctrl-Alt-F1" to bring the screen back on. However, when it is on, the
 desktop
 manager (GDM) pops up, instead of the xfce password dialog.
>>>
>>> What screen locker are you using? Note that light-locker only works with
>>> lightdm, not GDM.
>>>
>>
>> For lightdm, the password dialog is still missing; but I don't need to
>> use "Ctrl-Alt-F*" any more.
> 
> Then it looks a bit like #855626, could you confirm it?
> 

No, it's a different issue. I can still log in back. The point is, I
used to see a simple password dialog, but now it's lightdm (and I have
to retype my user name).

Bug#856053: kernel BUG at /home/zumbi/linux-4.9.2/fs/ocfs2/suballoc.c:2017!

[Russell Mosemann]

Package: src:linux
Version: 4.9.2-2~bpo8+1
Severity: important

Dear Maintainer,

   * What led up to the situation?
The system was relatively inactive. There are two vm's running, but they were 
not doing much at all. This bug might be related to bug #841144.

Feb 24 13:01:53 vhost172 kernel: [ cut here ]
Feb 24 13:01:53 vhost172 kernel: kernel BUG at 
/home/zumbi/linux-4.9.2/fs/ocfs2/suballoc.c:2017!
Feb 24 13:01:53 vhost172 kernel: invalid opcode:  [#1] SMP
Feb 24 13:01:53 vhost172 kernel: Modules linked in: btrfs xor raid6_pq ufs qnx4 
hfsplus hfs minix ntfs vfat msdos fat jfs xfs vhost_net vhost macvtap macvlan 
tun ocfs2 quota_tree hmac veth iptable_filter ip_tables x_tables nfsd 
auth_rpcgss nfs_acl nfs lockd grace fscache sunrpc ocfs2_dlmfs ocfs2_stack_o2cb 
ocfs2_dlm ocfs2_nodemanager ocfs2_stackglue configfs bridge stp llc bonding 
intel_rapl sb_edac edac_core x86_pkg_temp_thermal intel_powerclamp coretemp 
kvm_intel kvm ast irqbypass ttm crct10dif_pclmul iTCO_wdt crc32_pclmul 
iTCO_vendor_support drm_kms_helper mxm_wmi evdev ghash_clmulni_intel 
intel_cstate drm xhci_pci xhci_hcd ehci_pci igb ehci_hcd intel_uncore e1000e 
usbcore dca lpc_ich ptp mei_me i2c_i801 i2c_algo_bit intel_rapl_perf pcspkr sg 
mei i2c_smbus shpchp usb_common pps_core mfd_core ipmi_si fjes ipmi_msghandler
Feb 24 13:01:53 vhost172 kernel:  wmi tpm_tis tpm_tis_core acpi_power_meter tpm 
acpi_pad button fuse drbd lru_cache libcrc32c crc32c_generic autofs4 ext4 crc16 
jbd2 fscrypto mbcache dm_mod md_mod sd_mod crc32c_intel ahci libahci libata 
aesni_intel aes_x86_64 glue_helper lrw gf128mul ablk_helper cryptd scsi_mod
Feb 24 13:01:53 vhost172 kernel: CPU: 5 PID: 26191 Comm: qemu-system-x86 Not 
tainted 4.9.0-0.bpo.1-amd64 #1 Debian 4.9.2-2~bpo8+1
Feb 24 13:01:53 vhost172 kernel: Hardware name: To Be Filled By O.E.M. To Be 
Filled By O.E.M./EPC612D4I, BIOS P2.10 03/31/2016
Feb 24 13:01:53 vhost172 kernel: task: 9b77b48c8140 task.stack: 
c1f2c79c4000
Feb 24 13:01:53 vhost172 kernel: RIP: 0010:[]  
[] ocfs2_claim_metadata+0x172/0x180 [ocfs2]
Feb 24 13:01:53 vhost172 kernel: RSP: 0018:c1f2c79c74a8  EFLAGS: 00010297
Feb 24 13:01:53 vhost172 kernel: RAX: 0004 RBX: 0001 
RCX: c1f2c79c7530
Feb 24 13:01:53 vhost172 kernel: RDX: 0001 RSI: 9b6986757b00 
RDI: 9b689acf5b40
Feb 24 13:01:53 vhost172 kernel: RBP:  R08: c1f2c79c752a 
R09: c1f2c79c752c
Feb 24 13:01:53 vhost172 kernel: R10: 001d7381 R11: 9b6985e950c0 
R12: 9b69aa71
Feb 24 13:01:53 vhost172 kernel: R13: 9b689acf5b40 R14: c1f2c79c7538 
R15: 9b6986757b00
Feb 24 13:01:53 vhost172 kernel: FS:  7fc2c27fc700() 
GS:9b77bf34() knlGS:
Feb 24 13:01:53 vhost172 kernel: CS:  0010 DS:  ES:  CR0: 
80050033
Feb 24 13:01:53 vhost172 kernel: CR2: 7ff9ce911000 CR3: 000201dc7000 
CR4: 001426e0
Feb 24 13:01:53 vhost172 kernel: Stack:
Feb 24 13:01:53 vhost172 kernel:  9b689acf5b40  
 
Feb 24 13:01:53 vhost172 kernel:   33a0682b 
0001 
Feb 24 13:01:53 vhost172 kernel:  9b69aa71 9b689acf5b40 
c1f2c79c7980 9b6986757b00
Feb 24 13:01:53 vhost172 kernel: Call Trace:
Feb 24 13:01:53 vhost172 kernel:  [] ? 
ocfs2_create_new_meta_bhs.isra.49+0x79/0x360 [ocfs2]
Feb 24 13:01:53 vhost172 kernel:  [] ? 
ocfs2_journal_dirty+0x39/0x180 [ocfs2]
Feb 24 13:01:53 vhost172 kernel:  [] ? __kmalloc+0x18b/0x240
Feb 24 13:01:53 vhost172 kernel:  [] ? 
ocfs2_add_branch+0x1ea/0x820 [ocfs2]
Feb 24 13:01:53 vhost172 kernel:  [] ? 
ocfs2_grow_tree+0x30d/0x780 [ocfs2]
Feb 24 13:01:53 vhost172 kernel:  [] ? 
ocfs2_split_and_insert+0x307/0x490 [ocfs2]
Feb 24 13:01:53 vhost172 kernel:  [] ? 
ocfs2_split_extent+0x3ee/0x560 [ocfs2]
Feb 24 13:01:53 vhost172 kernel:  [] ? 
ocfs2_change_extent_flag+0x273/0x450 [ocfs2]
Feb 24 13:01:53 vhost172 kernel:  [] ? 
ocfs2_mark_extent_written+0x110/0x1d0 [ocfs2]
Feb 24 13:01:53 vhost172 kernel:  [] ? 
ocfs2_dio_end_io_write+0x44d/0x600 [ocfs2]
Feb 24 13:01:53 vhost172 kernel:  [] ? 
ocfs2_allocate_extend_trans+0x180/0x180 [ocfs2]
Feb 24 13:01:53 vhost172 kernel:  [] ? 
ocfs2_dio_end_io+0x3b/0x60 [ocfs2]
Feb 24 13:01:53 vhost172 kernel:  [] ? dio_complete+0x7e/0x190
Feb 24 13:01:53 vhost172 kernel:  [] ? 
do_blockdev_direct_IO+0x2168/0x2860
Feb 24 13:01:53 vhost172 kernel:  [] ? 
ocfs2_write_end_nolock+0x550/0x550 [ocfs2]
Feb 24 13:01:53 vhost172 kernel:  [] ? 
ocfs2_direct_IO+0x83/0x90 [ocfs2]
Feb 24 13:01:53 vhost172 kernel:  [] ? 
generic_file_direct_write+0xb3/0x180
Feb 24 13:01:53 vhost172 kernel:  [] ? 
__generic_file_write_iter+0xb6/0x1e0
Feb 24 13:01:53 vhost172 kernel:  [] ? 
ocfs2_file_write_iter+0x44e/0xae0 [ocfs2]
Feb 24 13:01:53 vhost172 kernel:  [] ? hrtimer_init+0xf0/0xf0
Feb 24 13:01:53 vhost172 kernel:  [] ? 
do_iter_readv_writev+0xb0/0x130
Feb 24 

Bug#856049: ethtool: Can not use --change-eeprom option

[Ben Hutchings]

Control: reassign -1 src:linux 4.9.6-3
Control: retitle -1 e1000: EEPROM write failed on 82540EM
Control: tag -1 upstream

On Fri, 2017-02-24 at 19:52 +0100, Yvan Masson wrote:
> Package: ethtool
> Version: 1:4.8-1
> Severity: normal
> 
> Dear maintainer,
> 
> The EEPROM of my Ethernet NIC has been flushed for some unknown reason.
> I would like to use ethtool to restore my EEPROM (fortunately I have a
> dump).
> 
> Here is one simple "test command" I tried and which should be valid
> according to the manpage and examples found on the net:
> # ethtool --change-eeprom enp2s1 magic 0x100e8086 offset 0x10 length 1 \
> value 0xff
> 
> But unfortunately, I always get this error:
> "Cannot set EEPROM data: Operation not permitted"
> 
> I am probably missing something, in which case please apologize, but
> maybe it is really a bug/something we can not do anymore with recent
> kernels? Maybe what I am probably be missing should be written in the
> manpage or in /usr/share/doc/ethtool/...?
> 
> Do not hesitate to ask if i can provide more information.
[...]

The e1000 driver's low-level EEPROM access functions return error code
1 on failure, and this code is propagated all the way up to the ethtool
program.  But the standard meaning of error code 1 is "Operation not
permitted", so that's what ethtool shows.  So that's a bug in the
driver's error reporting.

As for why the driver failed to access the EEPROM, I can't tell - there
are several possible error cases.  It might be worth trying to pass the
EEPROM contents as a binary file on stdin, instead of trying to set a
single byte.

As the e1000 driver is no longer maintained by Intel, I'm afraid these
bugs are unlikely to be fixed.

Ben.

-- 
Ben Hutchings
All the simple programs have been written, and all the good names
taken.


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

Bug#856052: postfwd: Allow to configure unix socket using /etc/default/postfwd

[Sven Strickroth]

Package: postfwd
Version: 1.35-3
Severity: wishlist

Dear Maintainer,

right now in /etc/default/postfwd there are specific variables for INET and
PORT which prevents the usage of the default initscript for configuring
postfwd2 to use an unix socket instead of an inet socket.

A solution could be to drop the special INET and PORT variables in
/etc/default/postfwd as well as  "--interface=${INET} --port=${PORT}"
in /etc/init.d/postfwd2 and pass those parameters in ARGS as other
packages such as postgrey do.

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

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

Versions of packages postfwd depends on:
ii  adduser 3.113+nmu3
ii  libnet-dns-perl 0.81-2+deb8u1
ii  libnet-server-perl  2.008-1
ii  perl5.20.2-3+deb8u6

postfwd recommends no packages.

postfwd suggests no packages.

-- Configuration Files:
/etc/default/postfwd changed [not included]

-- no debconf information

Bug#856051: more verbose output for checkbashisms (devscripts)

[Dmitriy Getman]

package: devscripts
version: 2.17.1
I added more verbose output for script checkbashisms:
possible bashism in ../bash/saymyname line 45 ($MACHTYPE should be "$(gcc
-dumpmachine"):

possible bashism in ../bash/saymyname line 188 ($HOSTNAME should be
"$(uname -n)"):
Also this script should show bashisms regardless if it dash or bash script
or regular file like /etc/profile


checkbashisms.pl
Description: Perl program

Bug#855941: RFS: scala-pickling/0.10.1-1 ITP: scala-pickling -- Fast, customizable, boilerplate-free pickling support for Scala

[Andreas Tille]

Hi,

I'd willing to sponsor scala-pickling since I need sbt for some project.
However, my personal policy is to sponsor only team maintained packages.
So please if you are not yet a member of the Debian Java team (which
IMHO perfectly fits for this package) join the team and commit the
packaging to Debian Java Git.  Just let me know if you need help to do
so.

Kind regards and thanks for working on this package

Andreas.

-- 
http://fam-tille.de

Bug#813226: tzdata config script ignores /etc/timezone on non-interactive configuration

[Tomas Ebenlendr]

On Mon, 1 Feb 2016 08:43:32 +0100
Aurelien Jarno  wrote:

> ...
> I don't think it is a bug. The correct way to configure the timezone has
> always been to change /etc/localtime symlink, ie in your case by doing
> "ln -sf /usr/share/zoneinfo/Asia/Tokyo /etc/localtime". This is what
> desktop environments do when changing the timezone and it is what
> systemd expects.

But after dpkg-reconfigure tzdata, content of this symlink was written
into /etc/timezone and the symlink was turned into real file.
Subsequent runs of dpkg-reconfigure have seen /etc/localtime real file,
thus behaving as if /etc/timezone is the source of authority here,
and /etc/localtime symlink is some obsure state which needs to be
transformed into /etc/timezone authority and /etc/localtime real file,
driven by /etc/timezone.

New package completely changes source of authority to /etc/localtime,
as tzdata.postinst script makes /etc/localtime into symlink, and
subsequent run of tzdata.config rewrites contents of /etc/timezone
based on the value of the symlink.

This change in behaviour should be documented, at least somewhere
in /usr/share/doc/tzdata/...

P.S.: Ansible (or other orchestration tool), usually checks file not
only by its contents, but also by its type. Thus there must be now two
paths (old tzdata and new tzdata) when checking /etc/localtime.
Checking /etc/timezone is not sufficient after the change. I spent 4
hours by debugging our ansible environment because of poor
documentation of this change and poor documentation of relation
between /etc/timezone and /etc/localtime in older versions of tzdata.

> Changing /etc/timezone worked in some cases before as we use to store
> /etc/localtime as a copy of the file instead of a symlink when possible,
> in order to allow the timezone to be correct without a /usr partition.
> This is not needed anymore given /usr is now mount from the initramfs
> when needed.
> 
> Aurelien
> 



-- 
 Tomáš 'ebík' Ebenlendr
 Economia a.s.
 PF 2017.15021197996


-- 
*Úspěch, charisma a inspirace v jednom magazínu. *
*Čtěte o nejúspěšnějších ženách Česka.*

*Objednejte si exkluzivní magazín Hospodářských novin Top ženy Česka 2016 
.*


pgpt1e99w1Zx2.pgp
Description: OpenPGP digital signature

Bug#856049: ethtool: Can not use --change-eeprom option

[Yvan Masson]

Package: ethtool
Version: 1:4.8-1
Severity: normal

Dear maintainer,

The EEPROM of my Ethernet NIC has been flushed for some unknown reason.
I would like to use ethtool to restore my EEPROM (fortunately I have a
dump).

Here is one simple "test command" I tried and which should be valid
according to the manpage and examples found on the net:
# ethtool --change-eeprom enp2s1 magic 0x100e8086 offset 0x10 length 1 \
value 0xff

But unfortunately, I always get this error:
"Cannot set EEPROM data: Operation not permitted"

I am probably missing something, in which case please apologize, but
maybe it is really a bug/something we can not do anymore with recent
kernels? Maybe what I am probably be missing should be written in the
manpage or in /usr/share/doc/ethtool/...?

Do not hesitate to ask if i can provide more information.

Best regards,
Yvan


# ethtool -e enp2s1
Offset  Values
--  --
0x: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
0x0010: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
0x0020: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
0x0030: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
0x0040: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
0x0050: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
0x0060: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
0x0070: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00


# lspci -vnn:
...
02:01.0 Ethernet controller [0200]: Intel Corporation 82540EM Gigabit
Ethernet Controller [8086:100e] (rev 03)
Subsystem: Intel Corporation 82540EM Gigabit Ethernet
Controller [8086:100e]
Flags: bus master, 66MHz, medium devsel, latency 64, IRQ 11
Memory at c022 (64-bit, non-prefetchable) [size=128K]
Memory at c020 (64-bit, non-prefetchable) [size=64K]
I/O ports at 8000 [size=64]
[virtual] Expansion ROM at c021 [disabled] [size=64K]
Capabilities: [dc] Power Management version 2
Capabilities: [e4] PCI-X non-bridge device
Capabilities: [f0] MSI: Enable- Count=1/1 Maskable- 64bit+
Kernel driver in use: e1000
Kernel modules: e1000


The dump I would like to restore at the end (I just need to change the
MAC address):
Offset  Values
--  --
0x: 00 01 6c cb 09 3c 00 0b ff ff ff ff ff ff ff ff 
0x0010: 00 00 00 00 0b 66 49 05 14 10 1e 10 86 80 a5 b1 
0x0020: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff 
0x0030: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff 
0x0040: cf 00 61 78 0b 14 00 00 c8 04 ff ff ff ff ff ff 
0x0050: ff ff ff ff ff ff ff ff ff ff ff ff ff ff 02 06 
0x0060: 2c 01 00 40 11 12 ff ff ff ff ff ff ff ff ff ff 
0x0070: ff ff ff ff ff ff ff ff ff ff ff ff ff ff 7c fe 


You will also find attached the strace for the above command.



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

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

Versions of packages ethtool depends on:
ii  libc6  2.24-9

ethtool recommends no packages.

ethtool suggests no packages.

-- no debconf information


ethtool.strace
Description: Binary data


pgpPn3p0v4pWO.pgp
Description: Signature digitale OpenPGP

Bug#531005: [Pkg-alsa-devel] Bug#531005: [alsa-utils] wishlist: Add alsa-info.sh script

[OmegaPhil]

On 24/02/17 18:15, Elimar Riesebieter wrote:
> * OmegaPhil  [2017-02-24 17:43 +]:
> 
>> Package: alsa-utils
>> Version: 1.1.3-1
>>
>> I'm looking into alsa-info.sh, I noticed that this package includes the
>> manpage but not the script itself. Is that intended?
> 
> The script is included in /usr/sbin/alsa-info.
> 
> Elimar
> 


Ah... sorry for the noise, I was automatically searching on .sh...
thanks for your help.




signature.asc
Description: OpenPGP digital signature

Bug#856048: Missing CSRF parameter in "Manage users" and "Preferences" menu in the web interface

[Juan Carlos Romero]

The bug is debian testing/sid, not in debian stable.

Sorry, but I reported the bug using reportbug from my debian stable laptop.

--
J. Carlos

Bug#531005: [Pkg-alsa-devel] Bug#531005: [alsa-utils] wishlist: Add alsa-info.sh script

[Elimar Riesebieter]

* OmegaPhil  [2017-02-24 17:43 +]:

> Package: alsa-utils
> Version: 1.1.3-1
> 
> I'm looking into alsa-info.sh, I noticed that this package includes the
> manpage but not the script itself. Is that intended?

The script is included in /usr/sbin/alsa-info.

Elimar
-- 
  Excellent day for drinking heavily.
  Spike the office water cooler;-)

Bug#531005: [Pkg-alsa-devel] Bug#531005: [alsa-utils] wishlist: Add alsa-info.sh script

[Elimar Riesebieter]

* OmegaPhil  [2017-02-24 17:43 +]:

> Package: alsa-utils
> Version: 1.1.3-1
> 
> I'm looking into alsa-info.sh, I noticed that this package includes the
> manpage but not the script itself. Is that intended?

No! Should be removed on next upload after stretch release.

Elimar
-- 
  Obviously the human brain works like a computer.
  Since there are no stupid computers humans can't be stupid.
  There are just a few running with Windows or even CE ;-)

Bug#856046: [Pkg-zsh-devel] Bug#856046: zsh: fix two segfaults in zsh/parameter module appends

[Axel Beckert]

Control: tag -1 + confirmed
Control: forwarded -1 http://www.zsh.org/mla/workers/2017/msg00251.html
Control: found -1 4.3.17-1
Control: found -1 5.0.7-5

Hi,

thanks to Daniel for the report and especially the patches.

Daniel Shahaf wrote:
> Version: 5.3.1-3

Actually this issue seems to be no (recent) regression but a crash
which can be reproduced on Debian Jessie and Wheezy, too. It though
looks slightly different with older zsh versions and requires a little
bit more constraints to be triggered. See below.

> Please find attached two segfault fixes for zsh.

The according upstream bug report (which only covers one half of the
issue as it's currently known) can be found at
http://www.zsh.org/mla/workers/2017/msg00251.html

Following is a minimal case reproduce this on Debian Sid/Stretch with
5.3.1-3:

→ zsh -f
stretch% options+=()
stretch% options+=()
[1]  - 17934 segmentation fault (core dumped)  zsh -f
→ zsh -f
stretch% functions+=()
stretch% functions+=()
[1]18988 segmentation fault (core dumped)  zsh -f

On Jessie (zsh 5.0.7-5) it requires at least one pair of values to
crash, so not requiring a value to crash might be considered a
regression:

→ zsh -f
jessie% options+=(a b)
zsh: invalid value: b
jessie% options+=(a b)
zsh: invalid value: b
[1]25740 segmentation fault (core dumped)  zsh -f
→ zsh -f
jessie% functions+=(a b)
jessie% functions+=(a b)
[1]25785 segmentation fault (core dumped)  zsh -f

On Wheezy (zsh 4.3.17-1) it even crashes on the first invocation, but
requires at least one pair of values to crash:

→ zsh -f
wheezy% functions+=(a b) 
*** glibc detected *** zsh: free(): invalid pointer: 0x7f98af455c78 ***
=== Backtrace: =
/lib/x86_64-linux-gnu/libc.so.6(+0x75bb6)[0x7f98ae678bb6]
/lib/x86_64-linux-gnu/libc.so.6(cfree+0x6c)[0x7f98ae67d95c]
zsh(strsetfn+0x1d)[0x45c28d]
zsh(setstrvalue+0x482)[0x45e5b2]
zsh(arrhashsetfn+0x95)[0x45e6b5]
zsh(assignaparam+0x10e)[0x46201e]
zsh[0x4276bc]
zsh[0x427a49]
zsh(execlist+0x1f1)[0x42de41]
zsh(execode+0xaf)[0x42e57f]
zsh(loop+0xa2)[0x43eaf2]
zsh(zsh_main+0x606)[0x4418d6]
/lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xfd)[0x7f98ae621ead]
zsh[0x410551]
=== Memory map: 
0040-004a4000 r-xp  ca:02 5464232
/bin/zsh4
006a3000-006a4000 r--p 000a3000 ca:02 5464232
/bin/zsh4
006a4000-006aa000 rw-p 000a4000 ca:02 5464232
/bin/zsh4
006aa000-006be000 rw-p  00:00 0 
010af000-010f1000 rw-p  00:00 0  [heap]
7f98a800-7f98a8021000 rw-p  00:00 0 
7f98a8021000-7f98ac00 ---p  00:00 0 
7f98acd6-7f98acd75000 r-xp  ca:02 16318790   
/lib/x86_64-linux-gnu/libgcc_s.so.1
7f98acd75000-7f98acf75000 ---p 00015000 ca:02 16318790   
/lib/x86_64-linux-gnu/libgcc_s.so.1
7f98acf75000-7f98acf76000 rw-p 00015000 ca:02 16318790   
/lib/x86_64-linux-gnu/libgcc_s.so.1
7f98acf76000-7f98acf7f000 r-xp  ca:02 4235476
/usr/lib/zsh/4.3.17/zsh/parameter.so
7f98acf7f000-7f98ad17e000 ---p 9000 ca:02 4235476
/usr/lib/zsh/4.3.17/zsh/parameter.so
7f98ad17e000-7f98ad17f000 r--p 8000 ca:02 4235476
/usr/lib/zsh/4.3.17/zsh/parameter.so
7f98ad17f000-7f98ad18 rw-p 9000 ca:02 4235476
/usr/lib/zsh/4.3.17/zsh/parameter.so
7f98ad18-7f98ad18f000 r-xp  ca:02 4235518
/usr/lib/zsh/4.3.17/zsh/compctl.so
7f98ad18f000-7f98ad38f000 ---p f000 ca:02 4235518
/usr/lib/zsh/4.3.17/zsh/compctl.so
7f98ad38f000-7f98ad39 r--p f000 ca:02 4235518
/usr/lib/zsh/4.3.17/zsh/compctl.so
7f98ad39-7f98ad391000 rw-p 0001 ca:02 4235518
/usr/lib/zsh/4.3.17/zsh/compctl.so
7f98ad391000-7f98ad3b4000 r-xp  ca:02 4235513
/usr/lib/zsh/4.3.17/zsh/complete.so
7f98ad3b4000-7f98ad5b4000 ---p 00023000 ca:02 4235513
/usr/lib/zsh/4.3.17/zsh/complete.so
7f98ad5b4000-7f98ad5b5000 r--p 00023000 ca:02 4235513
/usr/lib/zsh/4.3.17/zsh/complete.so
7f98ad5b5000-7f98ad5b6000 rw-p 00024000 ca:02 4235513
/usr/lib/zsh/4.3.17/zsh/complete.so
7f98ad5b6000-7f98ad5b7000 rw-p  00:00 0 
7f98ad5b7000-7f98ad5f8000 r-xp  ca:02 4235500
/usr/lib/zsh/4.3.17/zsh/zle.so
7f98ad5f8000-7f98ad7f8000 ---p 00041000 ca:02 4235500
/usr/lib/zsh/4.3.17/zsh/zle.so
7f98ad7f8000-7f98ad7f9000 r--p 00041000 ca:02 4235500
/usr/lib/zsh/4.3.17/zsh/zle.so
7f98ad7f9000-7f98ad80 rw-p 00042000 ca:02 4235500
/usr/lib/zsh/4.3.17/zsh/zle.so
7f98ad80-7f98ad801000 rw-p  00:00 0 
7f98ad801000-7f98ad80c000 r-xp  ca:02 9486598
/lib/x86_64-linux-gnu/libnss_files-2.13.so
7f98ad80c000-7f98ada0b000 ---p b000 

Bug#848663: vim: sh syntax highlighting of command substitution $() is wrong

[Francesco Poli]

On Mon, 19 Dec 2016 14:34:54 +0100 Bas Zoetekouw wrote:

> Hi,
> 
> On 19/12/16 14:02, James McCoy wrote:
> > On Mon, Dec 19, 2016 at 11:55:50AM +0100, Bas Zoetekouw wrote:
> >> Vim's currenr behaviour for syntax highlighting of shell scripts (with
> >> #!/bin/sh and /bin/sh pointing to dash) is to mark command
> >> substititions using the $(foo) construction as an error.
> > 
> > Not that I can see.
> 
> I've just tried this with a clean strecht system (no ~/.vim* present):
> screenshot is attached.  The $(foo) is clearly marked as an error there
> (inverse colors in this color scheme), in the same way as real bashisms
> like $'' and ${foo%bar}.

Hello,
I am another user bitten by this bug.

Indeed, $(foo) does not appear to be a bashism, yet it's incorrectly
marked as an error by vim, when found in a POSIX shell script.

$'foo' is an actual bashism, so marking it as an error in a POSIX shell
script is OK.

On the other hand, substring processing (${FOO%bar}, ${FOO%%bar},
${FOO#bar}, ${FOO##bar}) is not a bashism: the man page for dash(1)
states that it is supported and checkbashism does not complain...

Hence, I think vim should not mark it as an error.
Actually vim-runtime/2:7.4.488-7+deb8u2 (which is in jessie) correctly
highlights substring processing, as shown in the first attached
screenshot.
Unfortunately, vim-runtime/2:8.0.0197-2 (which is in stretch) wrongly
considers it as a syntax error in POSIX shell scripts, as shown in the
second attached screenshot.

The two screenshots were obtained (on jessie and stretch, respectively)
with

  $ view -u NONE test.sh

followed by

 :syn on 
 :set bg=dark


I am under the impression that this misbehavior is caused by the same
bug reported by Bas.
Dear Debian Vim Maintainers, would you like me to file a separate bug
report for this?
Please let me know.

At any rate, please fix the bug(s) and/or forward the report(s)
upstream, as appropriate.

Thanks for your time!
Bye.


-- 
 http://www.inventati.org/frx/
 There's not a second to spare! To the laboratory!
. Francesco Poli .
 GnuPG key fpr == CA01 1147 9CD2 EFDF FB82  3925 3E1C 27E1 1F69 BFFE


pgpqqHkEe6TSv.pgp
Description: PGP signature

Bug#851750: kpatch: module FTBFS for Linux 4.9

[James Beck]

Hi,

I made a patch for kmod/core/core.c using the upstream commit that fixes
the problem. When I apply this to core.c, kpatch 0.3.2 builds on kernel
4.9:


45a46
> #include 
71,75d71
< struct kpatch_backtrace_args {
<   struct kpatch_module *kpmod;
<   int ret;
< };
< 
135a132,138
> #define MAX_STACK_TRACE_DEPTH   64
> static unsigned long stack_entries[MAX_STACK_TRACE_DEPTH];
> struct stack_trace trace = {
>.max_entries= ARRAY_SIZE(stack_entries),
>.entries= _entries[0],
> };
> 
197,198c200,201
< static void kpatch_backtrace_address_verify(void *data, unsigned long address,
<   int reliable)
---
> static int kpatch_backtrace_address_verify(struct kpatch_module *kpmod,
>   unsigned long address)
200,201d202
<   struct kpatch_backtrace_args *args = data;
<   struct kpatch_module *kpmod = args->kpmod;
205,206c206
<   if (args->ret)
<   return;
---
>   int ret;
230,233c230,233
<   args->ret = kpatch_compare_addresses(address, func_addr,
ret)
<   return;
---
>ret = kpatch_compare_addresses(address, func_addr,
>   func_size, func_name);
>if (ret)
>return ret;
239,244c239,244
<   args->ret = kpatch_compare_addresses(address,
new_addr,
new_size,
name);
<   if (args->ret)
<   return;
---
>ret = kpatch_compare_addresses(address,
>   func->new_addr,
>   func->new_size,
>   func->name);
>if (ret)
>return ret;
247,258d246
< }
< 
< static int kpatch_backtrace_stack(void *data, char *name)
< {
<   return 0;
< }
< 
< static const struct stacktrace_ops kpatch_backtrace_ops = {
<   .address= kpatch_backtrace_address_verify,
<   .stack  = kpatch_backtrace_stack,
<   .walk_stack = print_context_stack_bp,
< };
260,263c248
< static int kpatch_print_trace_stack(void *data, char *name)
< {
<   pr_cont(" <%s> ", name);
<   return 0;
---
>   return ret;
266,278d250
< static void kpatch_print_trace_address(void *data, unsigned long addr,
<  int reliable)
< {
<   if (reliable)
<   pr_info("[<%p>] %pB\n", (void *)addr, (void *)addr);
< }
< 
< static const struct stacktrace_ops kpatch_print_trace_ops = {
<   .stack  = kpatch_print_trace_stack,
<   .address= kpatch_print_trace_address,
<   .walk_stack = print_context_stack,
< };
< 
287a260
>   int i;
290,294d262
<   struct kpatch_backtrace_args args = {
<   .kpmod = kpmod,
<   .ret = 0
<   };
< 
297,302c265,271
<   dump_trace(t, NULL, NULL, 0, _backtrace_ops, );
<   if (args.ret) {
<   ret = args.ret;
<   pr_info("PID: %d Comm: %.20s\n", t->pid, t->comm);
<   dump_trace(t, NULL, (unsigned long *)t->thread.sp,
<  0, _print_trace_ops, NULL);
---
> 
>trace.nr_entries = 0;
>save_stack_trace_tsk(t, );
>if (trace.nr_entries >= trace.max_entries) {
>ret = -EBUSY;
>pr_err("more than %u trace entries!\n",
>   trace.max_entries);
304a274,283
> 
> for (i = 0; i < trace.nr_entries; i++) {
>if (trace.entries[i] == ULONG_MAX)
>break;
>ret = kpatch_backtrace_address_verify(kpmod,
>  
> trace.entries[i]);
>if (ret)
>goto out;
>}
> 
307a287,297
>if (ret) {
>pr_err("PID: %d Comm: %.20s\n", t->pid, t->comm);
>for (i = 0; i < trace.nr_entries; i++) {
>if (trace.entries[i] == ULONG_MAX)
>break;
>pr_err("  [<%pK>] %pB\n",
>   (void *)trace.entries[i],
>   (void *)trace.entries[i]);
>}
>}
> 

Bug#856048: ntopng: Missing CSRF parameter in "Manage users" and "Preferences" menu in the web interface

[Juan Carlos Romero]

Source: ntopng
Severity: normal

Dear Maintainer,

It is not possible to use the "Manage users" or "Preferences" menu in
the web interface. I get the following errors:

 Script "/lua/admin/users.lua" returned an error:
 Missing CSRF parameter

 Script "/lua/admin/prefs.lua" returned an error:
 Missing CSRF parameter

Thanks.

-- System Information:
Debian Release: 8.7
  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=es_ES.UTF-8, LC_CTYPE=es_ES.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash
Init: systemd (via /run/systemd/system)

Bug#531005: [alsa-utils] wishlist: Add alsa-info.sh script

[OmegaPhil]

Package: alsa-utils
Version: 1.1.3-1

I'm looking into alsa-info.sh, I noticed that this package includes the
manpage but not the script itself. Is that intended?


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

Debian Release: stretch/sid
  990 testing 10.1.0.3   500 unstable10.1.0.3   500
quodlibet-unstable lazka.github.io
--- Package information. ---
Depends   (Version) | Installed
===-+-===
kmod (>= 17-1~) | 23-2
lsb-base (>= 3.0-9) | 4.1+devuan2
whiptail| 0.52.19-1
 OR dialog  | 1.3-20160828-2
libasound2   (>= 1.1.1) | libc6 (>= 2.15) |
libfftw3-single3 (>= 3.3.5) | libncursesw5 (>= 6) |
libsamplerate0   (>= 0.1.7) | libtinfo5(>= 6) |

Package's Recommends field is empty.

Package's Suggests field is empty.



signature.asc
Description: OpenPGP digital signature

Bug#856026: Acknowledgement (audacity: Fails to start)

[Fred DC]

On 24/02/2017 14:12, Debian Bug Tracking System wrote:

...
If you wish to submit further information on this problem, please
send it to 856...@bugs.debian.org.


I guess I was a bit too trigger-happy with my bug-report.

After I removed the existing ~/audacity-data the problem has gone away.

My apologies.

Fred

Bug#856047: locale-gen manpage is not up-to-date

[Anthony Wong]

Package: locales
Version: 2.24.9

Manpage of locale-gen does not mention the --keep-existing option. In
the source I see there is locale-gen.8.sgml, which has this option,
but apparently it is not used for generating locale-gen.8, and these
two files are now out-of-sync. If you prefer to keep using
locale-gen.8, I suggest to remove the sgml file from git to avoid
confusion, otherwise we should keep the sgml file up-to-date. I can
send a patch to fix this if you let me know which way is preferred.

Thanks,

Anthony Wong

Bug#635717: smsd should respect TMPDIR

[smstools3]

> Package: smstools
> Version: 3.1.11-1
>
> Hi,
>
> with /tmp mounted "noexec":
>
> 2011-07-28 11:38:21,3, smsd: Exec: startup_check (shell) encountered errors:
> 2011-07-28 11:38:21,3, smsd: ! sh: /tmp/smsd_script.hh5rLQ: Permission denied
> 2011-07-28 11:38:21,2, smsd: Shell /bin/sh testing failed: Failed to execute 
> test script.
> 2011-07-28 11:38:21,2, smsd: There was 1 major problem found.
>
> /tmp is even used when TMPDIR=/var/tmp is set. Please respect this.
>
> (When using mktemp() and friends, this should actually be the default,
> so this change shouldn't be hard to implement.)
>
> Mit freundlichen Grüßen,
> Christoph Berg
> --
> Dembach Goo Informatik GmbH & Co. KG
> Unter Sachsenhausen 33, D-50667 Köln
> Tel.: +49 2161 4643 187, Fax: +49 221 801483 20
> E-Mail: c...@dg-i.net, Support-Hotline: 0800 / 100 4323
>
> Amtsgericht Köln HRA 22794, USt-IdNr.: DE242 159 527
> Haftende Gesellschafterin: Dembach Goo Verwaltungsgesellschaft mbH
> Deren Geschäftsführer: Manon Goo, Andreas Dembach

Thanks for the information. Version >= 3.1.16 (upstream) now respects TMPDIR 
and TEMPDIR variables.

Regards,
Keke

Bug#703687: smstools: inefficient polling of directories should be replaced by inotify interface

[smstools3]

> Package: smstools
> Version: 3.1.14-1
> Severity: minor
>
>
> Hi,
>
> Smstools currently checks a couple of directories every x seconds.
> That is inefficient:
>  1. it doesn't react immediately on new outgoing sms messages, delaying their 
> transmission
>  2. it polls when it is not neccessary, using system resources
>
> Regarding point 2: this is a real problem in situations where for example a 
> simple server like a raspberry pi is used.
>
> I suggest to use inotify: smstools can then sleep forever and as soon as a 
> new file appears in its outbound
directory, >it is woken up immediately.
> Of course it needs to explicitly scan the outbound directory when it starts 
> up as new files may have appeared while
it was not running.
>

Thanks for the suggestion. Version 3.1.17 (upstream) can now use inotifywait, 
if user wants and needs to use it.

Regards,
Keke

Bug#856046: zsh: fix two segfaults in zsh/parameter module appends

[Daniel Shahaf]

Package: zsh
Version: 5.3.1-3
Severity: important
Tags: upstream patch

Dear Maintainer,

Please find attached two segfault fixes for zsh.

The first was committed upstream already, the second is expected to be
committed upstream tomorrow.

Upstream hasn't yet audited the module for additional similar instances.

Cheers,

Daniel
>From e9267adb49877bf3e7b30a740745535109202001 Mon Sep 17 00:00:00 2001
From: Daniel Shahaf 
Date: Tue, 7 Feb 2017 04:28:50 +
Subject: [PATCH] 40508: Make $functions re-settable.

---
 ChangeLog   | 5 +
 Src/Modules/parameter.c | 4 ++--
 Test/V06parameter.ztst  | 6 ++
 3 files changed, 13 insertions(+), 2 deletions(-)

diff --git a/ChangeLog b/ChangeLog
index 0f24ac9..09e9b62 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,3 +1,8 @@
+2017-02-08  Daniel Shahaf  
+
+	* 40508: Src/Modules/parameter.c, Test/V06parameter.ztst:
+	Make $functions re-settable.
+
 2017-02-07  Peter Stephenson  
 
 	* Sebastian: 40507: Src/Modules/db_gdbm.c: remove extraneous
diff --git a/Src/Modules/parameter.c b/Src/Modules/parameter.c
index 6e62287..c251e4f 100644
--- a/Src/Modules/parameter.c
+++ b/Src/Modules/parameter.c
@@ -330,7 +330,7 @@ unsetpmfunction(Param pm, UNUSED(int exp))
 
 /**/
 static void
-setfunctions(UNUSED(Param pm), HashTable ht, int dis)
+setfunctions(Param pm, HashTable ht, int dis)
 {
 int i;
 HashNode hn;
@@ -349,7 +349,7 @@ setfunctions(UNUSED(Param pm), HashTable ht, int dis)
 
 	setfunction(hn->nam, ztrdup(getstrvalue()), dis);
 	}
-deleteparamtable(ht);
+hashsetfn(pm, ht);
 }
 
 /**/
diff --git a/Test/V06parameter.ztst b/Test/V06parameter.ztst
index 10e0a27..27d5878 100644
--- a/Test/V06parameter.ztst
+++ b/Test/V06parameter.ztst
@@ -86,6 +86,12 @@
 >I have been autoloaded
 >$mydir/myfunc
 
+ functions+=(a 'echo foo'); a
+ functions+=(a 'echo bar'); a
+0:$functions can be appended to twice
+>foo
+>bar
+
 %clean
 
  rm -f autofn functrace.zsh rocky3.zsh sourcedfile myfunc
>From 9d9661b670850ada1169adf0781273721fd579e9 Mon Sep 17 00:00:00 2001
From: Daniel Shahaf 
Date: Fri, 24 Feb 2017 05:01:34 +
Subject: [PATCH] Make $options re-settable.

Follow-up to 40508.

Reported-by: James McGlashan
---
 Src/Modules/parameter.c | 4 ++--
 Test/V06parameter.ztst  | 3 +++
 2 files changed, 5 insertions(+), 2 deletions(-)

diff --git a/Src/Modules/parameter.c b/Src/Modules/parameter.c
index c251e4f..c7aac88 100644
--- a/Src/Modules/parameter.c
+++ b/Src/Modules/parameter.c
@@ -937,7 +937,7 @@ unsetpmoption(Param pm, UNUSED(int exp))
 
 /**/
 static void
-setpmoptions(UNUSED(Param pm), HashTable ht)
+setpmoptions(Param pm, HashTable ht)
 {
 int i;
 HashNode hn;
@@ -962,7 +962,7 @@ setpmoptions(UNUSED(Param pm), HashTable ht)
 			  (val && strcmp(val, "off")), 0, opts))
 		zwarn("can't change option: %s", hn->nam);
 	}
-deleteparamtable(ht);
+hashsetfn(pm, ht);
 }
 
 static const struct gsu_scalar pmoption_gsu =
diff --git a/Test/V06parameter.ztst b/Test/V06parameter.ztst
index 27d5878..2b66713 100644
--- a/Test/V06parameter.ztst
+++ b/Test/V06parameter.ztst
@@ -92,6 +92,9 @@
 >foo
 >bar
 
+ options+=(); options+=()
+0:$options can be appended to twice
+
 %clean
 
  rm -f autofn functrace.zsh rocky3.zsh sourcedfile myfunc

Bug#688451: smstools causes huge cpu-usage spikes

[smstools3]

> I got frusted a bit by this problem (smsd using incredible much cpu
> even when idle) so I ran smsd through valgrind (well, callgrind).
> It looks like tons of time is spend in an usleep(100); (yes, hundred).
> I always thought that Linux would just round it up to the next
> scheduling interval but it looks like that is a busy loop these days?
> I changed it from 100us to 10ms and now the cpu usage dropped from on
> average > 8% to < 1%. And that is on a "Intel(R) Core(TM) i7-3930K CPU
> @ 3.20GHz".
> Really something that communicates with a device at 19.2kBps should
> not use that much cpu.
> So please apply.
> Thanks.
> Oh and I think there maybe other possibilities of optimizing smsd left.
>
>
>
> Regards,
>
>
> Folkert van Heusden
>
> www.smartwinning.info

This fix is applied in the version >= 3.1.16 (upstream).

Regards,
Keke

Bug#569346: Re: Bug#569346: zombies after abnormal termination of modem handlers

[smstools3]

> > Package: smstools
> > Version: 3.1-2+lenny1
> > Severity: normal
> > Tags: patch
> >
> > After abnormal termination of modem handlers they chanded zombies.
> > The attached patch would solve the problem.
> > Should also apply to version 3.1.6.
> >
>
> Hi,
>
> thank's for the information.
>
> I tried this patch and it resolved the Zombie-issue, for example when a
> port definition was incorrect while starting the smsd. However, with this
> patch calling of eventhandler, checkhandler and other external processes
> does not work anymore.
>
> Another issue: writelogfile() should not be called from the signal
> handlers. This has been fixed in the version 3.1.2, published at
> 10.08.2008 (upstream).
>
> Regards,
> Keke

Zombie-issue is fixed in the version >= 3.1.16 (upstream).

Regards,
Keke

Bug#755898: smstools: Great delays before messages are processed

[smstools3]

> Package: smstools
> Severity: important
> Version: 3.1.14-1
> Tags: patch
>
> On a monitoring system with otherwie heavy I/O load (due to a large
> number of RRDs being updated on a regular basis), it was noticed that
> sending of a generated SMS was delayed for hours.
>
> Attaching gdb and strace to the stalled daemon revealed that it was
> stuck in a sync(2) call.
>
> Investigation of the source code showed that smsd makes frequent use of
> lock files as part of operations that involve reading from spool files
> and moving files around in its spool directories. After creating lock
> files, sync(2) is called which causes the kernel to write buffered file
> metadata modifications *for all filesystems*. This can have significatnt
> negative effects on overall filesystem performance.
>
> Lock files have no use after a system reboot and there seems to be no
> other part of smstools that is interested in the lock files' contents,
> therefore it is unclear why "sync" operation is needed at all. Even if
> it was important to preserve the lock file contents across system
> crashes, fsync(2) or fdatasync(2) would be the right calls to use.
>
> I suggest simply removing the sync() call from lockfile() in
> src/locking.c (that's why I set the "patch" tag.)
>
> As a quick and easy workaround here we have overridden the sync(2) call
> on the affected system by running smsd with the eatmydata shared library
> preloaded. This has solved our latency issue.
>
> Cheers,
> -Hilko

This bug is fixed in the version >= 3.1.16 (upstream).

Regards,
Keke

Bug#856045: x11-xserver-utils: Incorrect xrandr: cannot find crtc for output HDMI2

[William Herrin]

Package: x11-xserver-utils
Version: 7.7+3+b1
Severity: normal

Dear Maintainer,

Running debian stable (jessie) I moved my laptop from home (with one monitor
setup) to work (with a different one) using hibernate/resume (that is,
no reboot). At home my monitors are eDP1, DP1 and HDMI1. At work they're
eDP1, HDMI1 and HDMI2. Arandr generated the following xrandr command to
reconfigure the screens for my work environment. It failed. I attempted
the xrandr command it generted by hand:

xrandr --output HDMI2 --mode 1920x1080 --pos 152x2352 --rotate normal --output 
HDMI1 --mode 1920x1080 --pos 3992x2352 --rotate normal --output DP1 --off 
--output eDP1 --mode 1920x1080 --pos 2072x2352 --rotate normal --output DP2 
--off

The command failed with the following error:

xrandr: cannot find crtc for output HDMI2

Despite what the error said, HDMI2 was connected and recognized by xrandr
as being connected.

The following sequence of commands (the second identical to the original
above) successfully configured the display as intended.

xrandr --output DP1 --off 
xrandr --output HDMI2 --mode 1920x1080 --pos 152x2352 --rotate normal --output 
HDMI1 --mode 1920x1080 --pos 3992x2352 --rotate normal --output DP1 --off 
--output eDP1 --mode 1920x1080 --pos 2072x2352 --rotate normal --output DP2 
--off

Regards,
Bill Herrin



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

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

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


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

Kernel: Linux 3.16.39-desktop (SMP w/2 CPU cores; PREEMPT)
Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages x11-xserver-utils depends on:
ii  cpp  4:4.9.2-2
ii  libc62.19-18+deb8u7
ii  libice6  2:1.0.9-1+b1
ii  libx11-6 2:1.6.2-3
ii  libxaw7  2:1.0.12-2+b1
ii  libxcursor1  1:1.1.14-1+b1
ii  libxext6 2:1.3.3-1
ii  libxi6   2:1.7.4-1+b2
ii  libxmu6  2:1.1.2-1
ii  libxmuu1 2:1.1.2-1
ii  libxrandr2   2:1.4.2-1+b1
ii  libxrender1  1:0.9.8-1+b1
ii  libxt6   1:1.1.4-1+b1
ii  libxxf86vm1  1:1.1.3-1+b1

x11-xserver-utils recommends no packages.

Versions of packages x11-xserver-utils suggests:
pn  cairo-5c
pn  nickle  
ii  xorg-docs-core  1:1.7-1

-- no debconf information

Bug#855187: network-manager: Connection to WPA2 enterprise network (eduroam) is dysfunctional

[Ralf Jung]

Hi,

>> when I try to connect to the eduroam network of my institution, the resulting
>> connection does not actuall work.  NetworkManager considers the network to be
>> "connected" if I enter my credentials correctly (whereas it times out during
>> connection if I do not).  I even obtain an IPv4 address via DHCP.  However, 
>> the
>> resulting connection does not work: I cannot even ping my router 
>> ("Destination
>> Host Unreachable"), let alone anything on the internet.
> 
> Could you please test with 1.6.2 and report back

No change in behavior, i.e., the bug persists.

; Ralf

Bug#856044: sysvinit: Any update-rc.d command executed in dry-run mode causes a 'systemctl daemon-reload'

[Stefano Rago]

Package: sysvinit
Version: 2.88dsf-59
Severity: normal

Dear Maintainer,


   * What led up to the situation?
Several of the Debian Jessie machines in our infrastructures are 
running Chef as configuration management system. Part of the provisioning 
process involves running commands like 'update-rc.d -n -f  
remove' whose output used to determine the status of a certain managed service.
This is supposed to be a dry-run command, but it issues a 'systemctl 
daemon-reload' with undesirable side-effects, at every provisioning.

   * What exactly did you do (or not do) that was effective (or
 ineffective)?
I managed to figure this out running this command:
strace -f -e execve update-rc.d -n -f apache2 remove

   * What was the outcome of this action?
the following stacktrace:

execve("/usr/sbin/update-rc.d", ["update-rc.d", "-n", "-f", "apache2", 
"remove"], [/* 29 vars */]) = 0
Process 9413 attached
[pid  9413] execve("/sbin/insserv", ["/sbin/insserv", "-n", "-f"], [/* 29 vars 
*/]) = 0
insserv: dryrun, not creating .depend.boot, .depend.start, and .depend.stop
[pid  9413] +++ exited with 0 +++
--- SIGCHLD {si_signo=SIGCHLD, si_code=CLD_EXITED, si_pid=9413, si_uid=0, 
si_status=0, si_utime=2, si_stime=2} ---
Process 9420 attached
[pid  9420] execve("/usr/local/sbin/systemctl", ["systemctl", "daemon-reload"], 
[/* 29 vars */]) = -1 ENOENT (No such file or directory)
[pid  9420] execve("/usr/local/bin/systemctl", ["systemctl", "daemon-reload"], 
[/* 29 vars */]) = -1 ENOENT (No such file or directory)
[pid  9420] execve("/usr/sbin/systemctl", ["systemctl", "daemon-reload"], [/* 
29 vars */]) = -1 ENOENT (No such file or directory)
[pid  9420] execve("/usr/bin/systemctl", ["systemctl", "daemon-reload"], [/* 29 
vars */]) = -1 ENOENT (No such file or directory)
[pid  9420] execve("/sbin/systemctl", ["systemctl", "daemon-reload"], [/* 29 
vars */]) = -1 ENOENT (No such file or directory)
[pid  9420] execve("/bin/systemctl", ["systemctl", "daemon-reload"], [/* 29 
vars */]) = 0
[pid  9420] +++ exited with 0 +++
--- SIGCHLD {si_signo=SIGCHLD, si_code=CLD_EXITED, si_pid=9420, si_uid=0, 
si_status=0, si_utime=0, si_stime=0} ---
+++ exited with 0 +++

   * What outcome did you expect instead?
that the 'systemctl daemon-reload' command is not issued as part of the 
dry-run



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

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

Versions of packages sysvinit depends on:
ii  init 1.22
ii  libc62.19-18+deb8u7
ii  libselinux1  2.3-2
ii  libsepol12.3-2

sysvinit recommends no packages.

sysvinit suggests no packages.

-- no debconf information

Bug#844367: Debian local ada patches need an update for GCC 7

[Nicolas Boulenguez]

Package: src:gcc-7
Followup-For: Bug #844367

Hello.

Despite my overoptimistic expectations, libgnatvsn is still required.

libgnatvsn-with-gnat-7-safe.diff applies to gcc-7/7-20170129-1. It has
not been tested, but only fixes trivial issues and can probably be
applied now.

libgnatvsn-with-gnat-7.diff starts the actual restoration of
libgnatvsn. It may be a starting point to work on this bug.
Description: trivial fixes for gcc-7/7-20170129-1
 Remove obsolete references to libgnatprj, but keep existing
 references to libgnatvsn as it will be restored.
 .
 Drop obsolete and unapplied ada-default-project-path.diff.
 .
 debian/copyright must be regenerated from the updated copyright.in.
 .
 Remove libgnatvsn7.overrides, currently unused and replaced with a
 more simple solution once libgnatvsn is restored.
 .
 Fix impbit.out line in patches/ada-acats.diff, currently wrong in
 gcc-7 (`|sed instead of |sed`, and only spaces instead of blank and
 spaces, see 814978).
 .
 These changes have not been tested.
Author: Nicolas Boulenguez 

--- a/debian/copyright.in
+++ b/debian/copyright.in
@@ -48,7 +48,6 @@ gcc-@BV@-source  The sources with patches
 
 Ada:
 libgnatvsn-dev, libgnatvsn@BV@   GNAT version library
-libgnatprj-dev, libgnatprj@BV@   GNAT Project Manager library
 
 C:
 cpp-@BV@, cpp-@BV@-docGNU C Preprocessor
@@ -116,9 +115,6 @@ Runtime Library Exception (included in this file):
  - Various config files in gcc/config/ used in runtime libraries.
  - libvtv
 
-In contrast, libgnatprj is licensed under the terms of the pure GNU
-General Public License.
-
 The libbacktrace library is licensed under the following terms:
 
 Redistribution and use in source and binary forms, with or without
--- a/debian/gnatprj.gpr
+++ /dev/null
@@ -1,32 +0,0 @@
---  Project file for use with GNAT
---  Copyright (c) 2005, 2008 Ludovic Brenta 
---
---  This program is free software; you can redistribute it and/or modify
---  it under the terms of the GNU General Public License as published by
---  the Free Software Foundation; either version 3 of the License, or
---  (at your option) any later version.
---
---  This program 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.
---
---  This project file is designed to help build applications that use
---  GNAT project files.  Here is an example of how to use this project file:
---
---  with "gnatprj";
---  project Example is
--- for Object_Dir use "obj";
--- for Exec_Dir use ".";
--- for Main use ("example");
---  end Example;
-
-with "gnatvsn.gpr";
-project Gnatprj is
-   for Library_Name use "gnatprj";
-   for Library_Dir use "/usr/lib";
-   for Library_Kind use "dynamic";
-   for Source_Dirs use ("/usr/share/ada/adainclude/gnatprj");
-   for Library_ALI_Dir use "/usr/lib/ada/adalib/gnatprj";
-   for Externally_Built use "true";
-end Gnatprj;
--- a/debian/libgnatprj7.overrides
+++ /dev/null
@@ -1 +0,0 @@
-libgnatprj7 binary: missing-dependency-on-libc
--- a/debian/libgnatvsn7.overrides
+++ /dev/null
@@ -1 +0,0 @@
-libgnatvsn7 binary: missing-dependency-on-libc
--- a/debian/rules.d/binary-ada.mk
+++ b/debian/rules.d/binary-ada.mk
@@ -32,8 +35,6 @@ d_gnatsjlj	= debian/$(p_gnatsjlj)
 d_lgnat	= debian/$(p_lgnat)
 d_lgnatvsn = debian/$(p_lgnatvsn)
 d_lgnatvsn_dev = debian/$(p_lgnatvsn_dev)
-d_lgnatprj = debian/$(p_lgnatprj)
-d_lgnatprj_dev = debian/$(p_lgnatprj_dev)
 d_gnatd	= debian/$(p_gnatd)
 
 GNAT_TOOLS = gnat gnatbind gnatchop gnatclean gnatfind gnatkr gnatlink \
@@ -241,7 +291,7 @@ endif
 	find $(d_gnat) -name '*.ali' | xargs chmod 444
 	$(cross_shlibdeps) dh_shlibdeps -p$(p_gnat) \
 		$(call shlibdirs_to_search, \
-			$(p_lgcc) $(p_lgnat) $(p_lgnatvsn) $(p_lgnatprj) \
+			$(p_lgcc) $(p_lgnat) $(p_lgnatvsn) \
 		,)
 	echo $(p_gnat) >> debian/arch_binaries
 
--- a/debian/rules.patch
+++ b/debian/rules.patch
@@ -116,10 +116,6 @@ debian_patches += ada-arm
 # there should be no harm to always apply these, except for new GCC versions
 #ifeq ($(with_ada),yes)
 
-# FIXME: needs an update
-#  debian_patches += \
-#	ada-default-project-path
-
   debian_patches += \
 	ada-driver-check \
 	ada-gcc-name \
--- a/debian/rules2
+++ b/debian/rules2
@@ -2171,12 +2171,10 @@ ifneq ($(with_libgnat),yes)
 	rm -f $(d)/$(gcc_lib_dir)/adalib/lib*.so*
 endif
 
-# FIXME: libgnatprj and libgnatvsn need proper configury/Makefiles
+# FIXME: libgnatvsn needs proper configure/Makefile
 ifeq ($(DEB_CROSS),yes)
   ifeq ($(with_ada),yes)
-	for i in 'libgnatprj*' 'libgnatvsn*'; do \
-	  mv $(d)/$(PF)/lib/$$i $(d)/$(usr_lib)/. || true; \
-	done
+	mv $(d)/$(PF)/lib/libgnatvsn* $(d)/$(usr_lib)/. || true; \
   endif
 endif
 
--- a/debian/patches/ada-acats.diff
+++ b/debian/patches/ada-acats.diff
@@ -33,7 +107,7 @@ Index: