Bug#888644: prosody: logrotate error when prosody is not running

[Kevin Locke]

Package: prosody
Version: 0.10.0-1
Severity: normal
Tags: patch

Dear Maintainer,

When prosody is not running, the postrotate script of
/etc/logrotate.d/prosody exits with code 1 and causes logrotate to print
the following error message:

/etc/cron.daily/logrotate:
error: error running shared postrotate script for 
'/var/log/prosody/prosody.log /var/log/prosody/prosody.err '
run-parts: /etc/cron.daily/logrotate exited with return code 1

Since prosody is not running, there is no need to reload its
configuration and the postrotate script should exit without error.  The
attached patch makes this change.

Cheers,
Kevin


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

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

Versions of packages prosody depends on:
ii  adduser 3.116
ii  libc6   2.26-4
ii  libidn111.33-2.1
ii  libssl1.1   1.1.0g-2
ii  lsb-base9.20170808
ii  lua-bitop [lua5.1-bitop]1.0.2-4
ii  lua-expat [lua5.1-expat]1.3.0-4
pn  lua-filesystem  
ii  lua-socket [lua5.1-socket]  3.0~rc1+git+ac3201d-3
pn  lua5.1  
pn  lua5.1-filesystem   
pn  lua5.1-sec  
ii  ssl-cert1.0.39

Versions of packages prosody recommends:
pn  lua5.1-event  

Versions of packages prosody suggests:
pn  lua-dbi-mysql   
pn  lua-dbi-postgresql  
pn  lua-dbi-sqlite3 
pn  lua-zlib
>From fa736e4f89990d0fb5055bbfe34a5efe6df207d5 Mon Sep 17 00:00:00 2001
Message-Id: 

From: Kevin Locke 
Date: Sun, 28 Jan 2018 00:26:08 -0700
Subject: [PATCH] Avoid postrotate error when prosody is not running

When prosody is not running, /var/run/prosody/prosody.pid will not
exist.  This caused the postrotate script to exit with code 1 and caused
logrotate to print the following error message:

/etc/cron.daily/logrotate:
error: error running shared postrotate script for 
'/var/log/prosody/prosody.log /var/log/prosody/prosody.err '
run-parts: /etc/cron.daily/logrotate exited with return code 1

Fix this by exiting with code 0 when the PID file does not exist, since
reloading prosody is not required in this case.

Signed-off-by: Kevin Locke 
---
 debian/prosody.logrotate | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/debian/prosody.logrotate b/debian/prosody.logrotate
index c13ccd7..1869e3d 100644
--- a/debian/prosody.logrotate
+++ b/debian/prosody.logrotate
@@ -5,7 +5,7 @@
delaycompress
create 640 prosody adm
postrotate
-   [ -e /var/run/prosody/prosody.pid ] && /etc/init.d/prosody 
reload > /dev/null
+   [ ! -e /var/run/prosody/prosody.pid ] || /etc/init.d/prosody 
reload > /dev/null
endscript
sharedscripts
missingok
-- 
2.15.1

Bug#888643: Pending fixes for bugs in the libmail-chimp3-perl package

[pkg-perl-maintainers]

tag 888643 + pending
thanks

Some bugs in the libmail-chimp3-perl package are closed in revision
291fef5eae8e89fe36d2a743d131ca70f26ce320 in branch 'master' by
Christopher Hoskin

The full diff can be seen at
https://anonscm.debian.org/cgit/pkg-perl/packages/libmail-chimp3-perl.git/commit/?id=291fef5

Commit message:

Initial release. (Closes: #888643: ITP: libmail-chimp3-perl -- interface to 
mailchimp.com's RESTful Web API v3)

Bug#888596: firefox-esr-l10n-hi-in: misplaces locale file

[I Sagar]

On Sat, 27 Jan 2018 16:32:03 +0100 Jonas Smedegaard  wrote:
> The source tarball firefox-esr_52.6.0esr.orig-l10n-hi-IN.tar.bz2 used to
> build binary package firefox-esr-l10n-hi-in contains paths
> hi-IN/browser/branding/official and hi-IN/branding/official - the latter
> seems unique to this locale tarball and several string at former path is
> left untranslated, so I suspect the latter should be moved to the former
> location.
> 
> I don't speak Hindi, so this is just a guess.
> 
>  - Jonas
> 
 I have checked firefox-esr with hi_IN locale and shows that some
strings in "About Firefox" box are not translated to Hindi. As Jonas
suggested it should use hi-IN/branding/official
 files content.

Thanks,
Sagar

Bug#884497: lintian: Pedantic check for co-maintained packages with no Vcs-* fields

[Chris Lamb]

tags 884497 + pending
thanks

Fixed in Git:

  
https://anonscm.debian.org/git/lintian/lintian.git/commit/?id=b5101b37c9dffdb0d08cf8e0eb2a593c76d11ca8


Regards,

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

Bug#888643: ITP: libmail-chimp3-perl -- interface to mailchimp.com's RESTful Web API v3

[Christopher Hoskin]

Package: wnpp
Owner: Christopher Hoskin 
Severity: wishlist
X-Debbugs-CC: debian-de...@lists.debian.org, debian-p...@lists.debian.org

* Package name: libmail-chimp3-perl
  Version : 0.04
  Upstream Author : Josh Lavin 
* URL : https://metacpan.org/release/Mail-Chimp3
* License : Artistic or GPL-1+
  Programming Lang: Perl
  Description : interface to mailchimp.com's RESTful Web API v3

Mail::Chimp3 is a Perl package for interacting with The Rocket Science Group's
MailChimp service via its RESTful Web API v3.0. The package makes use of
WEB::API.

The package will be maintained under the umbrella of the Debian Perl Group.

--
Generated with the help of dpt-gen-itp(1) from pkg-perl-tools.

Bug#888642: Starting blueman fails because /usr/bin/dbus-launch terminated abnormally without any error message

[Michelle Konzack]

Package: blueman
Version: 2.0.4
Release: Stretch

Hello Maintainer,

currently I do not know, whether this is really
a blueman problem or dbus.

I have activated the bluetooth stuff from

but if I start blueman-applet I get the attached error

[ c 'blueman-applet' ]--
blueman-applet version 2.0.4 starting
Traceback (most recent call last):
  File "/usr/bin/blueman-applet", line 121, in 
BluemanApplet()
  File "/usr/bin/blueman-applet", line 59, in __init__
self.DbusSvc = DbusService("org.blueman.Applet", "/")
  File "/usr/lib/python3/dist-packages/blueman/main/DbusService.py", line
18, in __init__
self.bus = bus()
  File "/usr/lib/python3/dist-packages/dbus/_dbus.py", line 211, in
__new__
mainloop=mainloop)
  File "/usr/lib/python3/dist-packages/dbus/_dbus.py", line 100, in
__new__
bus = BusConnection.__new__(subclass, bus_type, mainloop=mainloop)
  File "/usr/lib/python3/dist-packages/dbus/bus.py", line 122, in __new__
bus = cls._new_for_bus(address_or_type, mainloop=mainloop)
dbus.exceptions.DBusException:
org.freedesktop.DBus.Error.Spawn.ExecFailed: /usr/bin/dbus-launch
terminated abnormally without any error message


Note:  I used bluetoothctl to connect to my "Sony Xperia E dual"
   with success, entered the PIN and set the device to
   "default" and "trusted".

I have checked all possibilities found in the internet (mainly
Archlinux and Ubuntu) but failed to find a solution.

Thanks in avance
Michelle



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

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


-- 
Michelle KonzackMiila ITSystems @ TDnet
GNU/Linux Developer 00372-54541400

Bug#865347: libdvd-pkg: use https for the download

[Hideki Yamane]

Hi,

 I've created patches for this https download issue, could you
 check and apply it, please? 


-- 
Regards,

 Hideki Yamane henrich @ debian.org/iijmio-mail.jp
>From c25290336b8999f7342f14f1e26376404b1875f9 Mon Sep 17 00:00:00 2001
From: Hideki Yamane 
Date: Sun, 28 Jan 2018 14:01:30 +0900
Subject: [PATCH 1/2] check with https

---
 debian/watch | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/debian/watch b/debian/watch
index eec941e..76cedb2 100644
--- a/debian/watch
+++ b/debian/watch
@@ -9,7 +9,7 @@ version=3
 opts=\
 downloadurlmangle=s/([\d.]+)\//$1\/libdvdcss-$1\.tar\.bz2/,\
 filenamemangle=s/\D*(\d+\.\d+\.\d+)\D*/libdvdcss-$1.tar.bz2/,\
- http://download.videolan.org/pub/libdvdcss/ (\d[\d.]+)/
+ https://download.videolan.org/pub/libdvdcss/ (\d[\d.]+)/
 
 # latest version
 #http://download.videolan.org/pub/libdvdcss/last/libdvdcss-([\d.]+)\.tar\.(?:xz|bz2|gz)
-- 
2.15.1

>From bdca82b5a8c9ab586de94053f2ae359f729d363d Mon Sep 17 00:00:00 2001
From: Hideki Yamane 
Date: Sun, 28 Jan 2018 14:03:10 +0900
Subject: [PATCH 2/2] fix #865347: use https for the download

---
 ...001-fix-865347-use-https-for-the-download.patch | 33 ++
 debian/patches/series  |  1 +
 2 files changed, 34 insertions(+)
 create mode 100644 debian/patches/0001-fix-865347-use-https-for-the-download.patch
 create mode 100644 debian/patches/series

diff --git a/debian/patches/0001-fix-865347-use-https-for-the-download.patch b/debian/patches/0001-fix-865347-use-https-for-the-download.patch
new file mode 100644
index 000..dc90491
--- /dev/null
+++ b/debian/patches/0001-fix-865347-use-https-for-the-download.patch
@@ -0,0 +1,33 @@
+From: Hideki Yamane 
+Date: Sun, 28 Jan 2018 14:02:26 +0900
+Subject: fix #865347: use https for the download
+
+---
+ libdvdcss/debian/rules | 2 +-
+ libdvdcss/debian/watch | 2 +-
+ 2 files changed, 2 insertions(+), 2 deletions(-)
+
+diff --git a/libdvdcss/debian/rules b/libdvdcss/debian/rules
+index 81f5acc..1493de8 100755
+--- a/libdvdcss/debian/rules
 b/libdvdcss/debian/rules
+@@ -22,5 +22,5 @@ VER ?= $(shell dpkg-parsechangelog -l$(PKD)/changelog | perl -ne 'print $$1 if m
+ .PHONY: get-orig-source
+ get-orig-source:  $(info I: $(PKG)_$(VER))
+ 	/usr/bin/wget --tries=3 --timeout=40 --read-timeout=40 --continue -O libdvdcss_$(VER).orig.tar.bz2 \
+-  http://download.videolan.org/pub/libdvdcss/$(VER)/libdvdcss-$(VER).tar.bz2 \
++  https://download.videolan.org/pub/libdvdcss/$(VER)/libdvdcss-$(VER).tar.bz2 \
+ || /usr/bin/uscan --noconf --verbose --rename --destdir=$(CURDIR) --check-dirname-level=0 --force-download --download-current-version $(PKD)
+diff --git a/libdvdcss/debian/watch b/libdvdcss/debian/watch
+index 91d8609..8653940 100644
+--- a/libdvdcss/debian/watch
 b/libdvdcss/debian/watch
+@@ -4,7 +4,7 @@ version=3
+ opts=\
+ downloadurlmangle=s/([\d.]+)\//$1\/libdvdcss-$1\.tar\.bz2/,\
+ filenamemangle=s/\D*(\d+\.\d+\.\d+)\D*/libdvdcss-$1.tar.bz2/,\
+- http://download.videolan.org/pub/libdvdcss/ (\d[\d.]+)/
++ https://download.videolan.org/pub/libdvdcss/ (\d[\d.]+)/
+ 
+ # latest version
+ #http://download.videolan.org/pub/libdvdcss/last/libdvdcss-([\d.]+)\.tar\.(?:xz|bz2|gz)
diff --git a/debian/patches/series b/debian/patches/series
new file mode 100644
index 000..2797d13
--- /dev/null
+++ b/debian/patches/series
@@ -0,0 +1 @@
+0001-fix-865347-use-https-for-the-download.patch
-- 
2.15.1

Bug#888606: Fwd: Bug#888606: cysignals: FTBFS with debhelper/11.1 due to empty build target

[Jerome BENOIT]

Hello,

this issue was fixed in 1.6.6+ds-2 which is current in experimental:
can we migrate cysingals 1.6.6+ds-2 to unstable ?

Thanks,
Jerome


 Forwarded Message 
Subject: Bug#888606: cysignals: FTBFS with debhelper/11.1 due to empty build 
target
Resent-Date: Sat, 27 Jan 2018 17:51:02 +
Resent-From: Niels Thykier 
Resent-To: debian-bugs-dist@lists.debian.org
Resent-CC: Jerome Benoit 
Date: Sat, 27 Jan 2018 18:44:34 +0100
From: Niels Thykier 
Reply-To: Niels Thykier , 888...@bugs.debian.org
To: Debian Bug Tracking System 

Source: cysignals
Version: 1.6.5+ds-2
Severity: serious
Tags: patch

Hi,

The cysignals package FTBFS with debhelper/11.1 as it has an empty
build target.  This is caused by debhelper had a bug in its handling
of "explicitly defined rules targets" that has now been fixed.

Previously, this happened to work because dpkg-buildpackage would
invoke "debian/rules build" (which would be a no-op) followed by
"fakeroot debian/rules binary".  During the binary target, dh's
suboptimal handling would run the build commands.


The solution is trivial but less pretty; explicitly define "build"
with the same content as the "%:" target (or rename the "build" folder
and drop the ".PHONY" target).  I have attached a patch for this.


More details can be found in:
 * #886901 comment #35
 * #887688 comment #37
 * #880840

Apologies for the inconvenience.

Thanks,
~Niels

From 3a57538b93ca415f235feb04b19395a576dfc60f Mon Sep 17 00:00:00 2001
From: Niels Thykier 
Date: Sat, 27 Jan 2018 17:43:04 +
Subject: [PATCH] Avoid empty build target

The dh sequencer as of debhelper/11.1 is stricter with this in order
to solve #880840 (where debhelper would fail to handle such targets
correctly).

Signed-off-by: Niels Thykier 
---
 debian/rules | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/debian/rules b/debian/rules
index 4872a50..bfd28fb 100755
--- a/debian/rules
+++ b/debian/rules
@@ -18,6 +18,12 @@ default:
 %:
dh $@ --with autoreconf --with python2  --with sphinxdoc 
--buildsystem=pybuild
 
+# The build target must not be empty.  Sadly because of how make
+# works, we have do duplicate the target in this case.
+build:
+   dh $@ --with autoreconf --with python2  --with sphinxdoc 
--buildsystem=pybuild
+
+
 override_dh_auto_configure-arch:
$(call adhoc_dh_auto_configure_do,bare)
$(call adhoc_dh_auto_configure_do,pari)
-- 
2.15.1




signature.asc
Description: OpenPGP digital signature

Bug#871585: python-apt: FTBFS: Test failure

[Andreas Beckmann]

Control: tag -1 unreproducible moreinfo

On Wed, 9 Aug 2017 08:48:19 -0700 Daniel Schepler 
wrote:
>debian/rules override_dh_auto_test
> make[1]: Entering directory '/build/python-apt-1.4.0~beta3'
> set -e; for python in python2.7 python3.6 python3.5 ; do \
>$python tests/test_all.py -q || [ "linux" = "hurd" ]; \
> done;
> [tests] Running on 2.7.13+ (default, Jul 19 2017, 18:15:03) [GCC 6.4.0 
> 20170704]
> Using library_dir:
> '/build/python-apt-1.4.0~beta3/build/lib.linux-x86_64-2.7'WARNING:
> Failed to read mirror file
> WARNING: Failed to read mirror file

Was this a one-time failure or is it reproducible?

I cannot reproduce it because the tests are skipped in my setup as well
as they are skipped on the buildds: because there is no
/etc/apt/sources.list in my pbuilders - only
/etc/apt/sources.list.d/*.list. The buildds seem to use a similar chroot
setup without /etc/apt/sources.list

So the bigger underlying problem is "tests require /etc/apt/sources.list
to be run". And thereafter perhaps "tests require network access".


Andreas

Bug#790196: Please help porting rasmol to latest vte (Was: Bug#790196: rasmol: depends on vte which is deprecated)

[Jeremy Bicha]

On Mon, Jan 15, 2018 at 3:14 AM, Andreas Tille  wrote:
> Would you be able to give any better replacement for the deprecated
> libvte9 which does not require a gtk3 port?  Sorry for my very naive
> attempt but I simply have no idea about GTK porting issues.

I am unaware of any such library. The last major standalone gtk2
terminal, lxterminal, just switched to gtk3 and vte2.91 in Debian.

Thanks,
Jeremy BIcha

Bug#888641: RM: hotssh -- RoQA; unmaintained, depends on unmaintained vte

[Jeremy Bicha]

Package: ftp.debian.org
X-Debbugs-Cc: hot...@packages.debian.org

Please remove hotssh from Debian.

>From what I can tell, hotssh's last release, 0.2.7, was in 2010.
hotssh is one of the apps
blocking the removal of the unmaintained 'vte' library from Debian.
(The maintained library is vte2.91.) [1]

I did email Thomas Bläsing a month ago asking for permission to remove
hotssh from Debian but I have not received a response yet. I then
noticed that the MIA Team requested 5 years ago that Thomas be removed
from the Uploaders list. [2] The last NMU was in 2013.

[1] https://bugs.debian.org/822603
[2] https://bugs.debian.org/700551

Thanks,
Jeremy Bicha

Bug#885967: #885967: FTBFS: FAILED test of gethostid ENOENT

[Andreas Beckmann]

On Thu, 4 Jan 2018 21:40:48 +0100 Adam Borowski  wrote:
> } PATH=`pwd`/bin:$PATH /bin/sh test/07/t0705a.sh
> } 2,3c2,3
> } < (ENOENT) because there is no "hostid" regular file in the pathname "/etc"
> } < directory; did you mean the "hosts" regular file instead?
> } ---
> } > (ENOENT) because there is no "hostid" regular file in the pathname
> } > "/etc" directory
> } FAILED test of gethostid ENOENT
> 
> Adrian Bunk wrote:
> > /etc/hosts is created in the postinst of the netbase package,
> > so "missing build dependency on netbase" would be another way
> > to describe the problem.
> 
> Not sure if this is the best way to fix the failure, although it _would_
> make the error message find /etc/hosts there so it can be suggested.
> 
> This test is fragile, though -- if you have a file named /etc/hosting or
> such, it'll be picked instead of "hosts".
> 
> The root cause, though, is that libexplain knows about gethostid, thus it
> can rule out an user making a typo -- the function looks for /etc/hostid and
> hothing else.

At a quick glance the look_for_similar() functionality in
libexplain/buffer/errno/path_resolution.c cannot be disabled, therefore
a proper solution for making the test output deterministic (independent
of the content of /etc) is not easily possible. The tests also don't
seem to support regular expressions ...

I'd suggest to add the B-D: netbase, and reconsider this decision once
base-files ships /etc/hostile in case that is a better suggestion than
/etc/hosts :-)

Can this bug be reproduced in stretch or jessie buildd chroots - or can
we tag it sid+buster?


Andreas

Bug#880144: snapper: Please provide option to disable apt snapshotting

[James Valleroy]

I'm attaching a patch for this change to Pre-Invoke and Post-Invoke scripts:
- It sources /etc/default/snapper, if it exists.
- If DISABLE_APT_SNAPSHOT is defined and equal to 'yes', then snapshot
creation is skipped. Otherwise, continue as normal.

Regards,
James
>From 1806f42bfd169f1c3194a61ae436d1f1a9e574c0 Mon Sep 17 00:00:00 2001
From: James Valleroy 
Date: Sun, 28 Jan 2018 09:59:51 +0530
Subject: [PATCH] Add option to disable apt snapshot

---
 debian/80snapper | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/debian/80snapper b/debian/80snapper
index 0007402..ddf1f8b 100644
--- a/debian/80snapper
+++ b/debian/80snapper
@@ -1,3 +1,3 @@
 # https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=770938
-  DPkg::Pre-Invoke  { "if [ -x /usr/bin/snapper -a -e /etc/snapper/configs/root ]; then rm /var/tmp/snapper-apt || true ; snapper create -d apt -c number -t pre -p > /var/tmp/snapper-apt || true ; fi"; };
-  DPkg::Post-Invoke { "if [ -x /usr/bin/snapper -a -e /var/tmp/snapper-apt ]; then snapper create -d apt -c number -t post --pre-number=`cat /var/tmp/snapper-apt` || true ; fi"; };
+  DPkg::Pre-Invoke  { "if [ -e /etc/default/snapper ]; then . /etc/default/snapper; fi; if [ -x /usr/bin/snapper -a ! x$DISABLE_APT_SNAPSHOT = 'xyes' -a -e /etc/snapper/configs/root ]; then rm /var/tmp/snapper-apt || true ; snapper create -d apt -c number -t pre -p > /var/tmp/snapper-apt || true ; fi"; };
+  DPkg::Post-Invoke { "if [ -e /etc/default/snapper ]; then . /etc/default/snapper; fi; if [ -x /usr/bin/snapper -a ! x$DISABLE_APT_SNAPSHOT = 'xyes' -a -e /var/tmp/snapper-apt ]; then snapper create -d apt -c number -t post --pre-number=`cat /var/tmp/snapper-apt` || true ; fi"; };
-- 
2.11.0

Bug#888588: ?

[Clint Adams]

>From 0d832f52ce3bffe4c240a6dd92cd391e16bb2bbd Mon Sep 17 00:00:00 2001
From: Clint Adams 
Date: Sat, 27 Jan 2018 23:10:11 -0500
Subject: [PATCH] s/iteritems/items/

Relevant to Debian bug #888588
---
 debiancontributors/scanners/mailbox.py  | 2 +-
 debiancontributors/scanners/postgres.py | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/debiancontributors/scanners/mailbox.py b/debiancontributors/scanners/mailbox.py
index e3f6edc..d3f88b5 100644
--- a/debiancontributors/scanners/mailbox.py
+++ b/debiancontributors/scanners/mailbox.py
@@ -96,7 +96,7 @@ class MailFrom(scanner.Scanner):
 finally:
 folder.close()
 
-for addr, (begin, end) in contribs.iteritems():
+for addr, (begin, end) in contribs.items():
 ident = Identifier("email", addr, desc_by_email.get(addr, None))
 begin = datetime.date.fromtimestamp(begin)
 end = datetime.date.fromtimestamp(end)
diff --git a/debiancontributors/scanners/postgres.py b/debiancontributors/scanners/postgres.py
index 0b08f33..04f4727 100644
--- a/debiancontributors/scanners/postgres.py
+++ b/debiancontributors/scanners/postgres.py
@@ -121,7 +121,7 @@ class Postgres(scanner.Scanner):
 
 contribs.add(id, date)
 
-for id, (begin, end) in contribs.iteritems():
+for id, (begin, end) in contribs.items():
 if self.identifier == "auto":
 try:
 ident = Identifier.create_auto(id, default_desc=desc_by_id.get(id, None))
-- 
2.15.1

Bug#888639: rtklib: FTBFS on hurd-i386: many undefined references

[Aaron M. Ucko]

Source: rtklib
Version: 2.4.3+dfsg1-1
Severity: normal
Tags: upstream
Justification: fails to build from source
User: debian-h...@lists.debian.org
Usertags: hurd

The build of rtklib for hurd-i386 (admittedly not a release
architecture) failed with many undefined references, as detailed in
https://buildd.debian.org/status/fetch.php?pkg=rtklib&arch=hurd-i386&ver=2.4.3%2Bdfsg1-1&stamp=1516747222&raw=0:

  viewer.o: In function `TextViewer::Read(QString const&)':
  ./app/rtknavi_qt/../appcmn_qt/viewer.cpp:98: undefined reference to `expath'
  refdlg.o: In function `RefDialog::UpdateDist()':
  ./app/rtknavi_qt/../appcmn_qt/refdlg.cpp:221: undefined reference to `norm'
  ./app/rtknavi_qt/../appcmn_qt/refdlg.cpp:223: undefined reference to 
`pos2ecef'
  [...]
  naviopt.o: In function `OptDialog::BtnRefPosClick()':
  ./app/rtknavi_qt/naviopt.cpp:293: undefined reference to `ecef2pos'
  ./app/rtknavi_qt/naviopt.cpp:308: undefined reference to `pos2ecef'
  collect2: error: ld returned 1 exit status
  Makefile:243: recipe for target 'rtknavi_qt' failed
  make[4]: *** [rtknavi_qt] Error 1

Could you please take a look?

Thanks!

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

Bug#888640: gcab: FTBFS on hurd-i386: PATH_MAX undeclared

[Aaron M. Ucko]

Source: gcab
Version: 1.0-1
Severity: normal
Tags: upstream
User: debian-h...@lists.debian.org
Usertags: hurd

The latest build of gcab for hurd-i386 (admittedly not a release
architecture) failed:

  ../tests/gcab-self-test.c:33:19: error: ‘PATH_MAX’ undeclared (first use in 
this function); did you mean ‘NAME_MAX’?

The Hurd notoriously has no static PATH_MAX.  Best practice is
dynamically accommodating whatever you actually encounter, since
fixed-size buffers generally run the risk of either wasting memory or
yielding truncation (or, worse, buffer overflows).  However, if that's
infeasible, you can also look up _PC_PATH_MAX via pathconf or even
supply a fallback constant (traditionally 4096).

Could you please take a look?

Thanks!

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

Bug#888638: firefox: FTBFS on powerpc and ppc64: Error updating ICU data file

[Aaron M. Ucko]

Source: firefox
Version: 58.0-1
Severity: normal
Tags: upstream
User: debian-powe...@lists.debian.org
Usertags: powerpc ppc64

Builds of firefox for powerpc and ppc64 (the only big-endian
architectures rustc supports at present, and admittedly not release
architectures) have been failing lately.  As of 58.0-1, the
(immediate) errors take the form

  cd build-browser && MOZCONFIG=mozconfig.icu ../mach python 
../intl/icu_sources_data.py "/«PKGBUILDDIR»"
  New python executable in 
/«PKGBUILDDIR»/build-browser/_virtualenv/bin/python2.7
  Also creating executable in 
/«PKGBUILDDIR»/build-browser/_virtualenv/bin/python
  Installing setuptools, pip, wheel...done.
  WARNING: Python.h not found. Install Python development headers.
  Error processing command. Ignoring because optional. 
(optional:setup.py:third_party/python/psutil:build_ext:--inplace)
  Error processing command. Ignoring because optional. 
(optional:packages.txt:comm/build/virtualenv_packages.txt)
  Error running "make" in directory /tmp/icu-obj-aDwfA5
  See output in /tmp/icu-make84ZXyL
  Error updating ICU data file
  Updating ICU sources lists...
  Running ICU configure...
  Running ICU make...
  debian/rules:205: recipe for target 'stamps/configure-browser' failed
  make[1]: *** [stamps/configure-browser] Error 1

When I tried to reproduce these errors on porter boxes for both
architectures to see what they actually were, I ran into *different*
errors:

  cd build-browser && MOZCONFIG=mozconfig.icu ../mach python 
../intl/icu_sources_data.py "/home/ucko/firefox"
  Traceback (most recent call last):
File "../mach", line 86, in 
  main(sys.argv[1:])
File "../mach", line 78, in main
  mach = get_mach()
File "../mach", line 68, in get_mach
  mach = check_and_get_mach(dir_path)
File "../mach", line 42, in check_and_get_mach
  return load_mach(dir_path, mach_path)
File "../mach", line 30, in load_mach
  return mach_bootstrap.bootstrap(dir_path)
File "/home/ucko/firefox/build/mach_bootstrap.py", line 335, in bootstrap
  driver.load_commands_from_file(os.path.join(mozilla_dir, path))
File "/home/ucko/firefox/python/mach/mach/main.py", line 267, in 
load_commands_from_file
  imp.load_source(module_name, path)
File "/home/ucko/firefox/build/valgrind/mach_commands.py", line 16, in 

  from mozbuild.base import (
File "/home/ucko/firefox/build/mach_bootstrap.py", line 364, in __call__
  module = self._original_import(name, globals, locals, fromlist, level)
File "/home/ucko/firefox/python/mozbuild/mozbuild/base.py", line 16, in 

  from mach.mixin.process import ProcessExecutionMixin
File "/home/ucko/firefox/build/mach_bootstrap.py", line 364, in __call__
  module = self._original_import(name, globals, locals, fromlist, level)
File "/home/ucko/firefox/python/mach/mach/mixin/process.py", line 29, in 

  raise Exception('Could not detect environment shell!')
  Exception: Could not detect environment shell!
  debian/rules:205: recipe for target 'stamps/configure-browser' failed

Due to this discrepancy, and the lack of available details for the
autobuilders' failures, I have *not* reported anything upstream here.

Could you please take a look?

Thanks!

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

Bug#876592: gconf: diff for NMU version 3.2.6-4.1

[Adrian Bunk]

Control: tags 876592 + patch
Control: tags 876592 + pending

Dear maintainer,

I've prepared an NMU for gconf (versioned as 3.2.6-4.1) and uploaded
it to DELAYED/5. Please feel free to tell me if I should cancel 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

diff -Nru gconf-3.2.6/debian/changelog gconf-3.2.6/debian/changelog
--- gconf-3.2.6/debian/changelog	2016-10-11 18:42:18.0 +0300
+++ gconf-3.2.6/debian/changelog	2018-01-28 06:17:32.0 +0200
@@ -1,3 +1,11 @@
+gconf (3.2.6-4.1) unstable; urgency=low
+
+  * Non-maintainer upload.
+  * Update gtk-doc.make from gtk-doc-tools 1.27-1,
+fixing a FTBFS with gtk-doc-tools >= 1.26. (Closes: #876592)
+
+ -- Adrian Bunk   Sun, 28 Jan 2018 06:17:32 +0200
+
 gconf (3.2.6-4) unstable; urgency=medium
 
   [ Raphael Geissert ]
diff -Nru gconf-3.2.6/debian/control gconf-3.2.6/debian/control
--- gconf-3.2.6/debian/control	2016-10-11 18:42:18.0 +0300
+++ gconf-3.2.6/debian/control	2018-01-28 06:17:32.0 +0200
@@ -6,7 +6,7 @@
 Section: libs
 Priority: optional
 Maintainer: Josselin Mouette 
-Uploaders: Andreas Henriksson , Debian GNOME Maintainers , Jordi Mallach , Laurent Bigonville , Michael Biebl 
+Uploaders: Debian GNOME Maintainers , Jordi Mallach , Laurent Bigonville , Michael Biebl 
 Build-Depends: debhelper (>= 8.1.3),
cdbs (>= 0.4.93),
dh-autoreconf,
diff -Nru gconf-3.2.6/debian/patches/26_gtk-doc.patch gconf-3.2.6/debian/patches/26_gtk-doc.patch
--- gconf-3.2.6/debian/patches/26_gtk-doc.patch	1970-01-01 02:00:00.0 +0200
+++ gconf-3.2.6/debian/patches/26_gtk-doc.patch	2018-01-28 06:17:20.0 +0200
@@ -0,0 +1,334 @@
+Description: Update gtk-doc.make from gtk-doc-tools 1.27-1
+ This fixes a FTBFS with gtk-doc-tools >= 1.26.
+Author: Adrian Bunk 
+Bug-Debian: https://bugs.debian.org/876592
+
+--- gconf-3.2.6.orig/gtk-doc.make
 gconf-3.2.6/gtk-doc.make
+@@ -1,4 +1,22 @@
+ # -*- mode: makefile -*-
++#
++# gtk-doc.make - make rules for gtk-doc
++# Copyright (C) 2003 James Henstridge
++#   2004-2007 Damon Chaplin
++#   2007-2017 Stefan Sauer
++#
++# 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.
++#
++# You should have received a copy of the GNU General Public License
++# along with this program.  If not, see .
+ 
+ 
+ # Everything below here is generic #
+@@ -25,6 +43,7 @@ TARGET_DIR=$(HTML_DIR)/$(DOC_MODULE)
+ 
+ SETUP_FILES = \
+ 	$(content_files)		\
++	$(expand_content_files)		\
+ 	$(DOC_MAIN_SGML_FILE)		\
+ 	$(DOC_MODULE)-sections.txt	\
+ 	$(DOC_MODULE)-overrides.txt
+@@ -33,9 +52,9 @@ EXTRA_DIST = \
+ 	$(HTML_IMAGES)			\
+ 	$(SETUP_FILES)
+ 
+-DOC_STAMPS=setup-build.stamp scan-build.stamp tmpl-build.stamp sgml-build.stamp \
++DOC_STAMPS=setup-build.stamp scan-build.stamp sgml-build.stamp \
+ 	html-build.stamp pdf-build.stamp \
+-	tmpl.stamp sgml.stamp html.stamp pdf.stamp
++	sgml.stamp html.stamp pdf.stamp
+ 
+ SCANOBJ_FILES = 		 \
+ 	$(DOC_MODULE).args 	 \
+@@ -49,9 +68,13 @@ REPORT_FILES = \
+ 	$(DOC_MODULE)-undeclared.txt \
+ 	$(DOC_MODULE)-unused.txt
+ 
+-CLEANFILES = $(SCANOBJ_FILES) $(REPORT_FILES) $(DOC_STAMPS)
++gtkdoc-check.test: Makefile
++	$(AM_V_GEN)echo "#!/bin/sh -e" > $@; \
++		echo "$(GTKDOC_CHECK_PATH) || exit 1" >> $@; \
++		chmod +x $@
++
++CLEANFILES = $(SCANOBJ_FILES) $(REPORT_FILES) $(DOC_STAMPS) gtkdoc-check.test
+ 
+-if ENABLE_GTK_DOC
+ if GTK_DOC_BUILD_HTML
+ HTML_BUILD_STAMP=html-build.stamp
+ else
+@@ -63,9 +86,11 @@ else
+ PDF_BUILD_STAMP=
+ endif
+ 
+-all-local: $(HTML_BUILD_STAMP) $(PDF_BUILD_STAMP)
+-else
+-all-local:
++all-gtk-doc: $(HTML_BUILD_STAMP) $(PDF_BUILD_STAMP)
++.PHONY: all-gtk-doc
++
++if ENABLE_GTK_DOC
++all-local: all-gtk-doc
+ endif
+ 
+ docs: $(HTML_BUILD_STAMP) $(PDF_BUILD_STAMP)
+@@ -74,92 +99,70 @@ $(REPORT_FILES): sgml-build.stamp
+ 
+  setup 
+ 
+-GTK_DOC_V_SETUP=$(GTK_DOC_V_SETUP_$(V))
+-GTK_DOC_V_SETUP_=$(GTK_DOC_V_SETUP_$(AM_DEFAULT_VERBOSITY))
++GTK_DOC_V_SETUP=$(GTK_DOC_V_SETUP_@AM_V@)
++GTK_DOC_V_SETUP_=$(GTK_DOC_V_SETUP_@AM_DEFAULT_V@)
+ GTK_DOC_V_SETUP_0=@echo "  DOC   Preparing build";
+ 
+ setup-build.stamp:
+ 	-$(GTK_DOC_V_SETUP)if test "$(abs_srcdir)" != "$(abs_builddir)" ; then \
+-	files=`echo $(SETUP_FILES) $(expand_content_files) $(DOC_MODULE).types`;

Bug#882159:

[Joseph Foster]

Unsubscribe

Bug#490848: https://packages.debian.org/wheezy/openssh-server links to non-existing Changelog

[Paul Wise]

On Sun, Jan 28, 2018 at 8:09 AM, Tomasz Papszun wrote:

> On clicking the link the browser lands at
> http://metadata.ftp-master.debian.org/changelogs/main/o/openssh/openssh_6.0p1-4+deb7u7_changelog
>
> which says:
>
> "Not Found
>
> The requested URL
> /changelogs/main/o/openssh/openssh_6.0p1-4+deb7u7_changelog was not
> found on this server.
> Apache Server at metadata.ftp-master.debian.org Port 80".
>
> Is the problem known?

This problem is known since 2008:

https://bugs.debian.org/490848

-- 
bye,
pabs

https://wiki.debian.org/PaulWise

Bug#885963: FTBFS: failed to open /etc/hosts

[Andreas Beckmann]

On Mon, 01 Jan 2018 01:13:57 +0100 Adam Borowski 
wrote:
> And indeed, in a chroot created with debootstrap --variant=buildd there is
> no such file anymore.  But, I see that the package doesn't actually need
> /etc/hosts but just the testsuite uses it as a random file it -thinks- will
> be always there.  Thanks to our efforts to unbloat the default install, this
> is no longer true.  Thus, you'd need to pick something else.

Is the lack of /etc/hosts also a "problem" for the buildd chroots used
for stretch and jessie? (I don't know how they get created.)
I.e. should we fix this bug there as well or can we tag it sid+buster?


Andreas

Bug#879809: lintian: warn about empty fields in binary package control files

[Chris Lamb]

tags 879809 + moreinfo
thanks

Hi,

> When the binary package control file is generated by the package build
> process, it could mistakenly generate a field that is empty.
> 
> I have not seen any specific instances of this yet though.

Tagging "moreinfo" until then :)

I suspect we might also need to workaround potential false positives
where various substvars are (correctly) empty and result in legitimately
empty fields.


Best wishes,

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

Bug#879235: lintian: Check that "Files: *" is the first entry in DEP-5 copyright files

[Chris Lamb]

tags 879235 + pending
thanks

Fixed in Git:

  
https://anonscm.debian.org/git/lintian/lintian.git/commit/?id=54c3b0095bd3444bfa756671c0833685abfa71df


Regards,

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

Bug#886116: FTBFS: chown: cannot access '.../t.so': No such file or directory

[Andreas Beckmann]

Control: tag -1 moreinfo

On Tue, 02 Jan 2018 14:32:03 +0100 Adam Borowski  wrote:
>dh_fixperms
> chown: cannot access 'debian/xppaut/usr/share/doc/xppaut/examples/ode/t.so': 
> No such file or directory
> chown: cannot access 
> 'debian/xppaut/usr/share/doc/xppaut/examples/ode/testbd.ps': No such file or 
> directory
> dh_fixperms: find debian/xppaut -true -print0 2>/dev/null | xargs -0r chown 
> --no-dereference 0:0 returned exit cod
> e 123
> dh_fixperms: Aborting due to earlier error

Hi,

I cannot reproduce this failure in pbuilder (amd64, i386,
armhf in qemubuilder on amd64).
Can you still reproduce it with current debhelper?

Two things I noticed in your log:

* dh_compress did not emit the compat level deprecation warning:
  "dh_compress: Compatibility levels before 9 are deprecated (level 7 in use)"

Is this a pristine dh_compress? The error sounds like a file system race
between dh_compress and dh_fixperms (s.t. find sees the uncompressed files
but chown only sees the compressed ones), but these two shouldn't run in
parallel ...

* the disk space calculation failed:

/usr/bin/du: cannot access 
'/<>/xppaut-6.11b+1.dfsg/debian/xppaut/usr/share/doc/xppaut/examples/ode/t.so':
 No such file or directory
/usr/bin/du: cannot access 
'/<>/xppaut-6.11b+1.dfsg/debian/xppaut/usr/share/doc/xppaut/examples/ode/testbd.ps':
 No such file or directory
E: read_command failed to execute du
E: Cannot determine space needed for /<>/xppaut-6.11b+1.dfsg (du 
failed)

That sounds fishy ... kind of a filesystem problem?


Andreas

Bug#315558: gozer: How to specify fontpath in .gozerrc

[Ricardo Fabian Peliquero]

Package: gozer
Version: 0.7.nofont.1-6+b1
Followup-For: Bug #315558

Dear Maintainer,

Please consider adding more fontpath information in the man page
(e.g.: in Debian, had to add full path to installed font in order
to make gozer work).

; echo 'fontpath /usr/share/fonts/truetype/noto' >> .gozerrc

Kind regards,

Ricardo

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

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

Versions of packages gozer depends on:
ii  giblib11.2.4-11
ii  libc6  2.26-6
ii  libimlib2  1.4.10-1

gozer recommends no packages.

gozer suggests no packages.

-- no debconf information

Bug#888637: gozer: Update URL

[Ricardo Fabian Peliquero]

Package: gozer
Version: 0.7.nofont.1-6+b1
Severity: minor

Dear Maintainer,

Please consider updating URL in package information.
Current URL (http://linuxbrit.co.uk/gozer/) is not reachable.

Thank you!

Ricardo

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

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

Versions of packages gozer depends on:
ii  giblib11.2.4-11
ii  libc6  2.26-6
ii  libimlib2  1.4.10-1

gozer recommends no packages.

gozer suggests no packages.

-- no debconf information

Bug#879235: lintian: Check that "Files: *" is the first entry in DEP-5 copyright files

[Chris Lamb]

retitle 879235 lintian: Check that "Files: *" is the first entry in DEP-5 
copyright files
thanks

Hi,

> add a sentence to this checks's description like "Remember: The
> applicable File: paragraph is selected using the principle of '*last*
> match wins'.
[..]
> add an extra check for "File: *" which, if present, should be the
> very first File: paragraph.

As the former was done part was done in #762261 I am retitling to match
the latter. :)


Regards,

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

Bug#888636: epiphany-browser: Can't get quality above 360p on Youtube

[Byron]

Package: epiphany-browser
Version: 3.22.7-1
Severity: normal

Dear Maintainer,

First I should make it clear that although I am running Stretch, I downloaded
and installed Epiphany from Flathub in order to get the latest stable version
(3.26.5.1, to be exact.) In case you need to know, I'm using a 1280x1024
screen.

I went to Youtube and watched any video. On the version of Epiphany which comes
with Debian (3.22.7), I can get up to 720p resolution on videos that are shot
in 1080p or 4K, but never above 720p. On Epiphany 3.26, I'm unable (as of yet)
to find out how to get a resolution past 320p.

I tried both Xorg and Xwayland with the same result. I'll try more as more
ideas slowly come to my brain.

I do a lot of media consumption so it would be nice to have sharper video.

Thanks for your time. =)



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

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

Versions of packages epiphany-browser depends on:
ii  dbus-user-session [default-dbus-session-bus]  1.10.24-0+deb9u1
ii  dbus-x11 [dbus-session-bus]   1.10.24-0+deb9u1
ii  epiphany-browser-data 3.22.7-1
ii  gsettings-desktop-schemas 3.22.0-1
ii  iso-codes 3.75-1
ii  libavahi-client3  0.6.32-2
ii  libavahi-common3  0.6.32-2
ii  libavahi-gobject0 0.6.32-2
ii  libc6 2.24-11+deb9u1
ii  libcairo2 1.14.8-1
ii  libgcr-base-3-1   3.20.0-5.1
ii  libgcr-ui-3-1 3.20.0-5.1
ii  libgdk-pixbuf2.0-02.36.5-2+deb9u2
ii  libglib2.0-0  2.50.3-2
ii  libgnome-desktop-3-12 3.22.2-1
ii  libgtk-3-03.22.11-1
ii  libjavascriptcoregtk-4.0-18   2.16.6-0+deb9u1
ii  libnotify40.7.7-2
ii  libpango-1.0-01.40.5-1
ii  libpangocairo-1.0-0   1.40.5-1
ii  libsecret-1-0 0.18.5-3.1
ii  libsoup2.4-1  2.56.0-2+deb9u1
ii  libsqlite3-0  3.16.2-5+deb9u1
ii  libwebkit2gtk-4.0-37  2.16.6-0+deb9u1
ii  libx11-6  2:1.6.4-3
ii  libxml2   2.9.4+dfsg1-2.2+deb9u2
ii  libxslt1.11.1.29-2.1

Versions of packages epiphany-browser recommends:
ii  browser-plugin-evince  3.22.1-3+deb9u1
ii  ca-certificates20161130+nmu1
ii  evince 3.22.1-3+deb9u1
ii  yelp   3.22.0-1

epiphany-browser suggests no packages.

-- no debconf information

Bug#888635: firefox: FTBFS on ppc64el: jit unexpected alignment requirements

[Aaron M. Ucko]

Source: firefox
Version: 58.0-1
Severity: serious
Tags: patch upstream
Justification: fails to build from source (but built successfully in the past)
User: debian-powe...@lists.debian.org
Usertags: ppc64el
Control: forwarded -1 https://bugzilla.mozilla.org/show_bug.cgi?id=1425413

Builds of firefox for ppc64el have been failing lately.  As of 58.0-1,
the (immediate) problem is

  /<>/js/src/jit/Linker.cpp:27:5: error: static assertion failed: 
Unexpected alignment requirements
   static_assert(CodeAlignment >= ExecutableAllocatorAlignment,

This appears to be the same problem as in
https://bugzilla.mozilla.org/show_bug.cgi?id=1425413, reportedly fixed
upstream with a one-line patch:

https://hg.mozilla.org/integration/mozilla-inbound/rev/34839f53008f

Could you please take a look?

Thanks!

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

Bug#888634: firefox: FTBFS on armhf: spurious -mfloat-abi=softfp, no

[Aaron M. Ucko]

Source: firefox
Version: 58.0-1
Severity: serious
Tags: upstream
Justification: fails to build from source (but built successfully in the past)
User: debian-...@lists.debian.org
Usertags: armhf
Control: forwarded -1 https://bugzilla.mozilla.org/show_bug.cgi?id=1433725

Builds of firefox for armhf have been failing lately, per the below
excerpts from 
https://buildd.debian.org/status/fetch.php?pkg=firefox&arch=armhf&ver=58.0-1&stamp=1516880296&raw=0:

  usr/bin/g++ -std=gnu++11 -o Unified_cpp_utility0.o -c 
-I/<>/build-browser/dist/system_wrappers -include 
/<>/config/gcc_hidden.h -DNDEBUG -DTRIMMED=1 
-D_FILE_OFFSET_BITS=64 -DCHROMIUM_BUILD -DUSE_LIBJPEG_TURBO=1 -DUSE_NSS=1 
-DENABLE_ONE_CLICK_SIGNIN -DGTK_DISABLE_SINGLE_INCLUDES=1 -D_ISOC99_SOURCE=1 
-DENABLE_REMOTING=1 -DENABLE_WEBRTC=1 -DENABLE_CONFIGURATION_POLICY 
-DENABLE_INPUT_SPEECH -DENABLE_NOTIFICATIONS -DENABLE_GPU=1 -DENABLE_EGLIMAGE=1 
-DUSE_SKIA=1 -DENABLE_TASK_MANAGER=1 -DENABLE_WEB_INTENTS=1 
-DENABLE_EXTENSIONS=1 -DENABLE_PLUGIN_INSTALLATION=1 
-DENABLE_PROTECTOR_SERVICE=1 -DENABLE_SESSION_SERVICE=1 -DENABLE_THEMES=1 
-DENABLE_BACKGROUND=1 -DENABLE_AUTOMATION=1 -DENABLE_PRINTING=1 
-DENABLE_CAPTIVE_PORTAL_DETECTION=1 -DWEBRTC_RESTRICT_LOGGING 
-DWEBRTC_MOZILLA_BUILD -DWEBRTC_VOE_EXTERNAL_REC_AND_PLAYOUT 
-DEXPAT_RELATIVE_PATH -DWEBRTC_ARCH_ARM -DWEBRTC_ARCH_ARM_V7 
-DWEBRTC_BUILD_NEON_LIBS -DWEBRTC_HAS_NEON -DWEBRTC_POSIX -DWEBRTC_LINUX 
-DWEBRTC_INCLUDE_INTERNAL_AUDIO_DEVICE -DWEBRTC_BUILD_LIBEVENT 
-D__STDC_FORMAT_MACROS -DNVALGRIND -DDYNAMIC_ANNOTATIONS_ENABLED=0 
-DSTATIC_EXPORTABLE_JS_API -DMOZ_HAS_MOZGLUE -DMOZILLA_INTERNAL_API 
-DIMPL_LIBXUL 
-I/<>/media/webrtc/trunk/webrtc/modules/video_coding/utility 
-I/<>/build-browser/media/webrtc/trunk/webrtc/modules/video_coding/utility/video_coding_utility_video_coding_utility
 -I/<>/media/webrtc/trunk 
-I/<>/media/webrtc/trunk/webrtc/common_video/include 
-I/<>/media/webrtc/trunk/webrtc/common_video/libyuv/include 
-I/<>/build-browser/ipc/ipdl/_ipdlheaders 
-I/<>/ipc/chromium/src -I/<>/ipc/glue 
-I/<>/build-browser/dist/include -fPIC -DMOZILLA_CLIENT -include 
/<>/build-browser/mozilla-config.h -Wdate-time -D_FORTIFY_SOURCE=2 
-Wall -Wc++11-compat -Wempty-body -Wignored-qualifiers -Woverloaded-virtual 
-Wpointer-arith -Wsign-compare -Wtype-limits -Wunreachable-code -Wwrite-strings 
-Wno-invalid-offsetof -Wc++14-compat -Wc++1z-compat -Wduplicated-cond 
-Wimplicit-fallthrough -Wno-error=maybe-uninitialized 
-Wno-error=deprecated-declarations -Wno-error=array-bounds 
-Wno-error=free-nonheap-object -Wformat -Wformat-overflow=2 
-fstack-protector-strong -Wformat -Werror=format-security -fno-schedule-insns2 
-fno-lifetime-dse -fno-delete-null-pointer-checks -fno-schedule-insns 
-fno-exceptions -fno-strict-aliasing -fno-rtti -ffunction-sections 
-fdata-sections -fno-exceptions -fno-math-errno -pthread -pipe -g 
-freorder-blocks -O2 -fomit-frame-pointer -mfloat-abi=softfp -mfpu=neon  -MD 
-MP -MF .deps/Unified_cpp_utility0.o.pp   
/<>/build-browser/media/webrtc/trunk/webrtc/modules/video_coding/utility/video_coding_utility_video_coding_utility/Unified_cpp_utility0.cpp
  In file included from /usr/include/features.h:443:0,
  [...]
   from 
/<>/build-browser/media/webrtc/trunk/webrtc/modules/video_coding/utility/video_coding_utility_video_coding_utility/Unified_cpp_utility0.cpp:2:
  /usr/include/arm-linux-gnueabihf/gnu/stubs.h:7:11: fatal error: 
gnu/stubs-soft.h: No such file or directory

Note the explicit use of -mfloat-api=softp, which is inappropriate
here.  Per your general instructions, I have also reported this bug
upstream, as https://bugzilla.mozilla.org/show_bug.cgi?id=1433725 (and
proceeded to mark it as forwarded).

Could you please take a look?

Thanks!

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

Bug#885051: pdfmod: Drop unnecessary Build-Depend on libgnome2.0-cil-dev

[Jeremy Bicha]

There was a typo in my second patch.

I have imported my corrected patches to

https://salsa.debian.org/jbicha/pdfmod

Thanks,
Jeremy Bicha

Bug#888633: libgl1-mesa-dri: Problem with Firefox and other XWayland applications on AMD GPU

[Christophe Aubry]

Package: libgl1-mesa-dri
Version: 17.3.3-1.1
Severity: important
Tags: patch

Hi,

it's seems that last version of Mesa 17.3 (17.3.3-1) present in unstable cause
problem with firefox and other XWayland applications when computer run on AMD
GPU, there is a bug report upstream at
https://bugs.freedesktop.org/show_bug.cgi?id=104306 and a patch available here
https://patchwork.freedesktop.org/patch/200999/.

I managed to apply the patch on my system and that solved the problem.



-- Package-specific info:
glxinfo:

name of display: :0
display: :0  screen: 0
direct rendering: Yes
server glx vendor string: SGI
server glx version string: 1.4
server glx extensions:
GLX_ARB_create_context, GLX_ARB_create_context_profile, 
GLX_ARB_fbconfig_float, GLX_ARB_framebuffer_sRGB, GLX_ARB_multisample, 
GLX_EXT_create_context_es2_profile, GLX_EXT_create_context_es_profile, 
GLX_EXT_fbconfig_packed_float, GLX_EXT_framebuffer_sRGB, 
GLX_EXT_import_context, GLX_EXT_libglvnd, GLX_EXT_texture_from_pixmap, 
GLX_EXT_visual_info, GLX_EXT_visual_rating, GLX_MESA_copy_sub_buffer, 
GLX_OML_swap_method, GLX_SGIS_multisample, GLX_SGIX_fbconfig, 
GLX_SGIX_pbuffer, GLX_SGIX_visual_select_group, GLX_SGI_make_current_read
client glx vendor string: Mesa Project and SGI
client glx version string: 1.4
client glx extensions:
GLX_ARB_create_context, GLX_ARB_create_context_profile, 
GLX_ARB_create_context_robustness, GLX_ARB_fbconfig_float, 
GLX_ARB_framebuffer_sRGB, GLX_ARB_get_proc_address, GLX_ARB_multisample, 
GLX_EXT_buffer_age, GLX_EXT_create_context_es2_profile, 
GLX_EXT_create_context_es_profile, GLX_EXT_fbconfig_packed_float, 
GLX_EXT_framebuffer_sRGB, GLX_EXT_import_context, 
GLX_EXT_texture_from_pixmap, GLX_EXT_visual_info, GLX_EXT_visual_rating, 
GLX_INTEL_swap_event, GLX_MESA_copy_sub_buffer, 
GLX_MESA_multithread_makecurrent, GLX_MESA_query_renderer, 
GLX_MESA_swap_control, GLX_OML_swap_method, GLX_OML_sync_control, 
GLX_SGIS_multisample, GLX_SGIX_fbconfig, GLX_SGIX_pbuffer, 
GLX_SGIX_visual_select_group, GLX_SGI_make_current_read, 
GLX_SGI_swap_control, GLX_SGI_video_sync
GLX version: 1.4
GLX extensions:
GLX_ARB_create_context, GLX_ARB_create_context_profile, 
GLX_ARB_fbconfig_float, GLX_ARB_framebuffer_sRGB, 
GLX_ARB_get_proc_address, GLX_ARB_multisample, GLX_EXT_buffer_age, 
GLX_EXT_create_context_es2_profile, GLX_EXT_create_context_es_profile, 
GLX_EXT_fbconfig_packed_float, GLX_EXT_framebuffer_sRGB, 
GLX_EXT_import_context, GLX_EXT_texture_from_pixmap, GLX_EXT_visual_info, 
GLX_EXT_visual_rating, GLX_MESA_copy_sub_buffer, 
GLX_MESA_multithread_makecurrent, GLX_MESA_query_renderer, 
GLX_MESA_swap_control, GLX_OML_swap_method, GLX_OML_sync_control, 
GLX_SGIS_multisample, GLX_SGIX_fbconfig, GLX_SGIX_pbuffer, 
GLX_SGIX_visual_select_group, GLX_SGI_make_current_read, 
GLX_SGI_video_sync
Extended renderer info (GLX_MESA_query_renderer):
Vendor: X.Org (0x1002)
Device: AMD CAPE VERDE (DRM 2.50.0 / 4.14.15-towo.1-siduction-amd64, LLVM 
5.0.1) (0x6820)
Version: 17.3.3
Accelerated: yes
Video memory: 2048MB
Unified memory: no
Preferred profile: core (0x1)
Max core profile version: 4.5
Max compat profile version: 3.0
Max GLES1 profile version: 1.1
Max GLES[23] profile version: 3.1
OpenGL vendor string: X.Org
OpenGL renderer string: AMD CAPE VERDE (DRM 2.50.0 / 
4.14.15-towo.1-siduction-amd64, LLVM 5.0.1)
OpenGL core profile version string: 4.5 (Core Profile) Mesa 17.3.3
OpenGL core profile shading language version string: 4.50
OpenGL core profile context flags: (none)
OpenGL core profile profile mask: core profile
OpenGL core profile extensions:
GL_AMD_conservative_depth, GL_AMD_draw_buffers_blend, 
GL_AMD_performance_monitor, GL_AMD_pinned_memory, 
GL_AMD_seamless_cubemap_per_texture, GL_AMD_shader_stencil_export, 
GL_AMD_shader_trinary_minmax, GL_AMD_vertex_shader_layer, 
GL_AMD_vertex_shader_viewport_index, GL_ANGLE_texture_compression_dxt3, 
GL_ANGLE_texture_compression_dxt5, GL_ARB_ES2_compatibility, 
GL_ARB_ES3_1_compatibility, GL_ARB_ES3_2_compatibility, 
GL_ARB_ES3_compatibility, GL_ARB_arrays_of_arrays, GL_ARB_base_instance, 
GL_ARB_bindless_texture, GL_ARB_blend_func_extended, 
GL_ARB_buffer_storage, GL_ARB_clear_buffer_object, GL_ARB_clear_texture, 
GL_ARB_clip_control, GL_ARB_color_buffer_float, 
GL_ARB_compressed_texture_pixel_storage, GL_ARB_compute_shader, 
GL_ARB_compute_variable_group_size, GL_ARB_conditional_render_inverted, 
GL_ARB_conservative_depth, GL_ARB_copy_buffer, GL_ARB_copy_image, 
GL_ARB_cull_distance, GL_ARB_debug_output, GL_ARB_depth_buffer_float, 
GL_ARB_depth_clamp, GL_ARB_derivative_control, GL_ARB_direct_state_access, 
GL_ARB_draw_buffers, GL_ARB_draw_buffers_blend, 
GL_ARB_draw_elements_base_vertex, GL_ARB_draw_indirect, 
GL_ARB_draw_instanced, GL_ARB

Bug#888484: [Pkg-clamav-devel] Bug#888484: Patch still not available

[Scott Kitterman]

On Sunday, January 28, 2018 12:14:36 AM Ninos Ego wrote:
> Hey there,
> 
> I do not want to stress, but does it have any reasons, why it takes so
> long to patch clamav with severity "grave"? Can you guys may tell me how
> long you still need to fix clamav in current debian stable (stretch)?
> ATM clamav is running on our systems for spam mail protection. If you
> still need some time (> 12h), I'm forced to disable clamav as long as
> it's not fixed. < 0.99.3 is vulnerable for code execution...

We're currently waiting on approval from a stable release manager to upload 
the fix:

https://bugs.debian.org/888552
https://bugs.debian.org/888553

Clamav is not supported through the normal Debian security release process 
because of the general necessity of updating clamav in complete upstream 
releases that carry much more than security fixes.  As a result, it takes a 
little longer.

If you know how to build a Debian package (and honestly, if you are 
administering Debian systems, you should), then you can grab the stable source 
package, apply the patch from the bug, and build a local package for use until 
we get this approved and uploaded.

Scott K

Bug#888632: mono-tools: Unnecessary Build-Depends on old GNOME libraries

[Jeremy Bicha]

Source: mono-tools
Version: 1.0.7-1
Severity: serious
User: pkg-gnome-maintain...@lists.alioth.debian.org
Usertags: oldlibs libgnome gconf
Tags: sid buster patch
X-Debbugs-CC: jo.shie...@xamarin.com

As announced [1], we do not intend to release Debian 10 "Buster" with
the old libgnome (and related) libraries. These libraries have been
deprecated and unmaintained for several years.

Your package has apparently unnecessary Build-Depends on these
libraries:

 libgconf2.0-cil-dev
 libgnome2.0-cil-dev

Please remove these Build-Depends. (No patch attached but this seems a
pretty trivial fix.)

[1] https://lists.debian.org/debian-devel/2017/10/msg00299.html

On behalf of the Debian GNOME team,
Jeremy Bicha

Bug#888563: ibus-libpinyin 1.9.2 in Ubuntu

[Boyuan Yang]

2018-01-27 23:07 GMT+08:00 ChangZhuo Chen (陳昌倬) :
> On Sat, Jan 27, 2018 at 03:24:33PM +0100, Gunnar Hjalmarsson wrote:
>> So, as far as I now understand, the fcitx-zhuyin and libzhuyin source
>> packages should simply be dropped from sid, and these packages in
>> experimental:
>>
>> libpinyin
>> ibus-libpinyin
>> ibus-libzhuyin
>> fcitx-libpinyin
>>
>> should be moved to sid.
>>
>> Does that make sense to you?
>
> Looks good to me. I will following this if there is no objection.
>
>
> To Boyuan Yang,
>
> Since you request a transition for fcitx, and libpinyin transition also
> need to rebuild fcitx, maybe we shall do it together so that we don't
> need to build fcitx twice?

I'm still waiting for the ACK from release team. Building twice is not
really a big problem,
please make upload new versions and make binNMUs ASAP when applicable.
Of course, if the release team approves the transition before you get ready,
uploading onto Unstable can be coordinated.

Regards,
Boyuan Yang

Bug#885537: Accepted nullmailer 1:2.1-6 (source) into experimental

[Adam Borowski]

On Sat, Jan 27, 2018 at 05:21:17PM +, David Bremner wrote:
>  nullmailer (1:2.1-6) experimental; urgency=medium
>  .
>[ David Bremner]
>* Drop "Recommends: rsyslog | system-log-daemon"; a typical user for
>  nullmailer is probably in minimizing installed packages. Logging is
>  available via the systemd journal.
>* Restore /etc/init.d/nullmailer, drop dependency on systemd-sysv
> (Closes: #886121, #885537).

Confirmed: works for me.  Both for immediate delivery and the no-network
case.  An armhf box, openrc.

The changelog message is a bit misleading: logging via syslog works fine.

Thanks!
Meow.
-- 
⢀⣴⠾⠻⢶⣦⠀ The bill with 3 years prison for mentioning Polish concentration
⣾⠁⢰⠒⠀⣿⡁ camps is back.  What about KL Warschau (operating until 1956)?
⢿⡄⠘⠷⠚⠋⠀ Zgoda?  Łambinowice?  Most ex-German KLs?  If those were "soviet
⠈⠳⣄ puppets", Bereza Kartuska?  Sikorski's camps in UK (thanks Brits!)?

Bug#888631: dput: Allow override of remote ‘chmod’ operation

[Ben Finney]

Package: dput
Severity: minor
Control: block 389908 by -1
Control: block 876896 by -1

On 7-Sep-2011, Marc Haber wrote:

> Additionally, the chmod should be optional or configurable. It fails
> when the scp target account has its shell set to scponly.

On 26-Sep-2017, Ansgar Burchardt wrote:

> The separate `chmod` call [after ‘rsync’ upload] can be replaced by
> `--chmod=F644` or `--chmod=ugo=rwX`. Please also include an option
> to *not* affect permissions and just use the default permissions.


The ‘dput’ command currently forces a change of file permission (a
‘chmod’ operation) when uploading via some methods. This is
undesirable in some environments.

Implement configuration options to specify:

* Whether to perform the ‘chmod’ operation (default: yes).

* What permission flags to set (default: 0o0644).

-- 
 \“Technology is neither good nor bad; nor is it neutral.” |
  `\   —Melvin Kranzberg's First Law of Technology |
_o__)  |
Ben Finney 


signature.asc
Description: PGP signature

Bug#888134: screenfetch - Missing dependency

[Hideki Yamane]

On Tue, 23 Jan 2018 12:36:28 -0300
Yadickson Soto  wrote:
> */usr/bin/screenfetch: line 1264: bc: command not found*

 Good catch :)

 It was not visible on VM since it doesn't have some devices 
 (e.g. /sys/class/hwmon/hwmon0/temp1_input)

 And I also find pgrep from procps is necessary but doesn't exist
 on minimal environment.
 

-- 
Regards,

 Hideki Yamane henrich @ debian.org/iijmio-mail.jp

Bug#888630: r instruction in score partition doesn't work as expected

[Mickael Viey]

Package: csound


Version: 1:6.08.0~dfsg-1
Severity: normal

Dear Maintainer,


the r instruction doesn't work as expected. The section is not repeated. 
If we test with example file from the documentation, we got an error 
about Macro which is undefined:


$ csound r.csd
virtual_keyboard real time MIDI plugin for Csound
0dBFS level = 32768.0
--Csound version 6.08 (double samples) 2016-12-01
[commit: none]
libsndfile-1.0.27
UnifiedCSD:  r.csd
STARTING FILE
Creating options
Creating orchestra
Creating score
rtaudio: ALSA module enabled
rtmidi: ALSA Raw MIDI module enabled
Elapsed time at end of orchestra compile: real: 0.003s, CPU: 0.003s
sorting score ...
Undefined macro: '$REPS_MACRO'end of score. overall amps:  0.0
   overall samples out of range:    0
0 errors in performance
Elapsed time at end of performance: real: 0.003s, CPU: 0.003s

I join the r.csd file for your tests.


If I omit macro, section is not repeated. However we see csound entering 
in the sections, but making no sound.


This the file content:


  
  -odac
  
  r
sr =    44100
;kr =    4410
ksmps  =    256
 0dbfs = 40

    instr 1
    ;xamp, ;kcps    xcar xmod kndx    
ifn iphs
    a1 foscil  p4, p5, 1,   p7, p6, 
1, 0

 out a1
    endin


  
  
    f 1 0 4096 10 1 0.5 0.25 0.25 0.10 0.05 0.05 0.025 0.0125
    f 2 0 4096 10 1
;1  2   3   4 5   6   7
 ;inst  time    dur amp note 
p6  p7

r 4
i1  0   0.15   2 120   1.5 6
i1  +   .  .   [ 120 * 2^(4/8)]  
1.0 .
i1  +   .  .   [ 120 * 2^(8/8)]  
1.9 .
i1  +   .  .   [ 120 * 2^(4/8)]  
1.0 .

s
e
    


and the output:

$ csound test_mel2.csd
virtual_keyboard real time MIDI plugin for Csound
0dBFS level = 32768.0
--Csound version 6.08 (double samples) 2016-12-01
[commit: none]
libsndfile-1.0.27
UnifiedCSD:  test_mel2.csd
STARTING FILE
Creating options
Creating orchestra
Creating score
rtaudio: ALSA module enabled
rtmidi: ALSA Raw MIDI module enabled
Elapsed time at end of orchestra compile: real: 0.003s, CPU: 0.003s
sorting score ...
Repeats=4
Repeat section
Repeat section
Repeat section
    ... done
Elapsed time at end of score sort: real: 0.003s, CPU: 0.003s
graphics suppressed, ascii substituted
0dBFS level = 40.0
orch now loaded
audio buffered in 256 sample-frame blocks
ALSA output: total buffer size: 1024, period size: 256
writing 256 sample blks of 64-bit floats to dac
SECTION 1:
ftable 1:
ftable 1:   4096 points, scalemax 1.000
    _'''-_
  '._
   - -_
   '._
  -   '''--._
 '.
   '.
 '   -_
   -_
_'--.._
    ''--.._
   -_
-_   -
   -_
-_  _
   '-.___
 ''._
-. '
'._ _
-.__.
ftable 2:
ftable 2:   4096 points, scalemax 1.000
   .-''-._
    _-'   '.
  _-    '.
 -    '_
   .'   -
  -  '_
    _' .
   .    -
  -  '_
_'_.___
- .
-   -
'_   _'
. .
-   -
'.   _'
-_    -
-_    .'
    -_ _.'
  '-._..'
end of section 1 sect peak amps:    0.000
SECTION 2:
new alloc for instr 1:
B  0.000 ..  0.150 T  0.151 TT  0.151 M:    2.000
B  0.150 ..  0.300 T  0.302 TT  0.302 M:    2.000
B  0.300 ..  0.450 T  0.453 TT  0.453 M:    2.000
B  0.450 ..  0.600 T  0.598 TT  0.598 M:    2.000
end of section 2 sect peak amps:    2.000
inactive allocs returned to freespace
SECTION 3:
end of section 3 sect peak amps:    0.000
SECTION 4:
end of section 4 sect peak amps:    0.000
Score finished in csoundPerform().
inactive allocs returned to freespace
end of score.  overall amps:    2.000
   overall samples out of range:    0
0 errors in performance
Elapsed time at end of performance: re

Bug#888629: smuxi: Unnecessary Build-Depends on old GNOME libraries

[Jeremy Bicha]

Source: smuxi
Version: 1.0.7-1
Severity: serious
User: pkg-gnome-maintain...@lists.alioth.debian.org
Usertags: oldlibs libgnomeui libgnome gnome-vfs-removal
Tags: sid buster patch

As announced [1], we do not intend to release Debian 10 "Buster" with
the old libgnome (and related) libraries. These libraries have been
deprecated and unmaintained for several years.

Your package has apparently unnecessary Build-Depends on these
libraries:

 libart2.0-cil-dev
 libgnome-vfs2.0-cil-dev
 libgnome2.0-cil-dev

Please remove these Build-Depends. (No patch attached but this seems a
pretty trivial fix.)

[1] https://lists.debian.org/debian-devel/2017/10/msg00299.html

On behalf of the Debian GNOME team,
Jeremy Bicha

Bug#888627: m instruction in score partition cause segfault

[Mickael Viey]

Package: csound

Version: 1:6.08.0~dfsg-1
Severity: normal

Dear Maintainer,


the m instruction doesn't work as expected this score make a segfault 
when run:



  
  -odac
  
  r
sr =    44100
;kr =    4410
ksmps  =    256
 0dbfs = 40

    instr 1
    ;xamp, ;kcps    xcar xmod kndx    
ifn iphs
    a1 foscil  p4, p5, 1,   p7, p6, 
1, 0

 out a1
    endin


  
  
    f 1 0 4096 10 1 0.5 0.25 0.25 0.10 0.05 0.05 0.025 0.0125

;1  2   3   4 5   6   7
 ;inst  time    dur amp note 
p6  p7

m foo
i1  0  0.15   2 120   1.5 6
i1  +   .  .  139 1.0 .
i1  +   .  .  67 1.9 .
i1  +   .  .  110 1.0 .
s
n foo
e
    



here the output when run this with csound:

csound test_mel2.csd
virtual_keyboard real time MIDI plugin for Csound
0dBFS level = 32768.0
--Csound version 6.08 (double samples) 2016-12-01
[commit: none]
libsndfile-1.0.27
UnifiedCSD:  test_mel2.csd
STARTING FILE
Creating options
Creating orchestra
Creating score
rtaudio: ALSA module enabled
rtmidi: ALSA Raw MIDI module enabled
Elapsed time at end of orchestra compile: real: 0.003s, CPU: 0.003s
sorting score ...
Named section >>>foo<<<

csound command: Segmentation fault
end of score.  overall amps:    0.000
   overall samples out of range:    0
0 errors in performance
Elapsed time at end of performance: real: 0.254s, CPU: 0.004s


the debian version of this package seems to be buggy. I will make 
another report about another bug soon.



I join the csd file wich cause the segfault for test purpose.


Thx


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

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

Versions of packages csound depends on:
ii  libc6    2.24-11+deb9u1
ii  libcsound64-6.0  1:6.08.0~dfsg-1
ii  libgcc1  1:6.3.0-18
ii  libgomp1 6.3.0-18
ii  libstdc++6   6.3.0-18

Versions of packages csound recommends:
ii  csound-utils  1:6.08.0~dfsg-1

csound suggests no packages.

-- no debconf information



test_mel2.csd
Description: audio/csound

Bug#888628: Also mention best way to read all man pages one has found

[積丹尼 Dan Jacobson]

Package: man-db
Version: 2.7.6.1-4
Severity: wishlist
File: /usr/share/man/man1/apropos.1.gz

Mention the best way to not only search for man pages, but also show
their contents.

Just like one can do
$ aptitude search 256
$ aptitude show ~n256

So for apropos that would probably be
$ apropos 256 #and then if happy with the results, do
$ apropos 256|sed 's/ .*//'|xargs man

(Thus reading up on lots of SHA256 related programs installed on his
system, all via a one liner.)

Bug#885256: activity-log-manager: Depends on unmaintained pygtk

[Jeremy Bicha]

Adrian,

Are you interested in doing an NMU to update this package then?

If not, I think it would be better if this package were orphaned and
even removed from Debian, since no one is maintaining it.

Thanks,
Jeremy Bicha

Bug#885046: gnome-do: Depends on old GNOME libraries

[Jeremy Bicha]

Sorry that this wasn't mentioned in the original bug, but gnome-do
also depends on libgnome-keyring1.0-cil which has been removed from
Debian Testing. See https://bugs.debian.org/867941

Thanks,
Jeremy Bicha

Bug#888334: survex: FTBFS with FFmpeg 3.5

[James Cowgill]

Hi,

On 26/01/18 05:36, Olly Betts wrote:
> Control: tags -1 + fixed-upstream patch
> 
>> Build log:
>> https://people.debian.org/~jcowgill/ffmpeg-3.5-20180122/survex_amd64.build
> 
> Thanks James,
> 
> Based on the two errors in the log I've pushed a patch upstream (though
> not tested with the new FFmpeg yet):
> 
> https://git.survex.com/?p=survex/.git;a=commit;h=5e46ae2e95e0f88c9efe8fe2a6632069ef09a18d

I tested 1.2.32-1 with that commit applied and survex does build
successfully with FFmpeg 3.5.

> I'll probably wait for the next upstream release to upload, unless
> FFmpeg 3.5 appears first.

That should be fine.

Thanks,
James



signature.asc
Description: OpenPGP digital signature

Bug#878088: [Reportbug-maint] Bug#878088: reportbug: please inform security and lts teams about security update regressions

[Nis Martensen]

On 26-01-2018 15:45, Markus Koschany wrote:
> I am not convinced that the apt-cache method is more efficient than
> parsing the version string. I believe my method is simpler and it would
> catch the same potential candidates as your apt-cache idea. Manual
> intervention (answering a question) cannot be avoided unless the
> security team agrees to receive all bug reports against a version with a
> security update. I am absolutely sure that is not desired.

I agree that the question should be asked when the package version is a
security update.  What I am trying to achieve using the apt-cache method
(on top of the version string method) is to avoid asking the question
for "normal" package updates in stable.

Attached a new version of the is_security_update function. This could be
further refined by fetching the changelog from the package tracker if
the package version is not the installed one, but this is probably going
too far...

No idea how many of the stable package updates are usually normal bug
fix updates compared to the number of security updates. If updates are
almost all security updates, then we should definitely not do such
micro-optimization and go with your original approach.


> I favor my current patch because of the reasons I mentioned before. I
> can remove the sys.exit call? What else should be done?

"secversion[2]" should be "secversion.group(2)", right?  The former
variant did not work for me in a quick test.

Using an else clause may be more pythonic than my previous suggestion of
moving more stuff into the try block.

Reportbug has an "ewrite()" function that you can use for the warning
message.

Reportbug has a concept of user expertise levels.  Can the question be
skipped in novice mode?

Should reportbug incorporate a default version of the json file to fall
back to if the lookup fails? Reportbug is probably going to be updated
more often than the online version of the json file. An internal version
could also be updated regularly.
>From 56d6dbffd3075bb9f06aa1b31fd8f688b6b16d4b Mon Sep 17 00:00:00 2001
From: Nis Martensen 
Date: Sat, 27 Jan 2018 22:22:31 +0100
Subject: [PATCH] utils: add new is_security_update() function

The security and LTS teams want to ask the reporting user for
notification if one of their updates caused a regression.  On the other
hand, reportbug should not ask users unnecessary questions.  So let's
try to collect evidence that this report is really about a package
version from a security update.
---
 reportbug/utils.py | 79 ++
 1 file changed, 79 insertions(+)

diff --git a/reportbug/utils.py b/reportbug/utils.py
index b376c6c..c372727 100644
--- a/reportbug/utils.py
+++ b/reportbug/utils.py
@@ -39,6 +39,8 @@ import email
 import socket
 import subprocess
 import pipes
+import apt
+import gzip
 
 from .urlutils import open_url
 from string import ascii_letters, digits
@@ -1333,3 +1335,80 @@ def get_lsm_info():
 break
 
 return lsminfo
+
+
+def is_security_update(pkgname, pkgversion):
+"""Determine whether a given package is a security update.
+
+Detection of security update versions works most reliably if the
+package version under investigation is the currently installed
+version.  If this is not the case, the probability of false
+negatives increases.
+
+Parameters
+--
+pkgname : str
+package name
+pkgversion : str
+package version
+
+Returns
+---
+bool
+True if there is evidence that this version is a security
+update, otherwise False
+"""
+# Check 1:
+# If it does not follow the debXuY version number pattern, it is
+# definitely no security update.
+#
+# This check is not sufficient to detect security updates reliably,
+# since other stable updates also use the same version pattern.
+regex = re.compile('(\+|~)deb(\d+)u(\d+)')
+secversion = regex.search(pkgversion)
+if not secversion:
+return False
+
+# Check 2:
+# If the package comes from the Debian-Security package source, it
+# is definitely a security update.
+#
+# This check does not identify all security updates, since some of
+# them are distributed through the normal channels as part of a
+# stable release update.
+try:
+p = apt.Cache()[pkgname]
+if 'Debian-Security' in [o.label for o in
+p.versions[pkgversion].origins]:
+return True
+except:
+pass
+
+# Check 3:
+# Inspect the package changelog if it mentions any vulnerability,
+# identified by a CVE number, in the section of the latest version.
+
+cl = None
+for cl in ['/usr/share/doc/{}/changelog.Debian.gz'.format(pkgname),
+   '/usr/share/doc/{}/changelog.gz'.format(pkgname)]:
+if os.path.exists(cl):
+break
+
+try:
+with gzip.open(cl, 'rt') as f:
+ln = f.readlin

Bug#888626: debian-edu-config: do we really need ./bin/ltsp-arch-debian-edu

[Holger Levsen]

On Sun, Jan 28, 2018 at 12:48:26AM +0100, Holger Levsen wrote:
> do we really need ./bin/ltsp-arch-debian-edu ? I mean:
 
I mean: for the purpose of debian-edu (currently) 'echo i386' would be
sufficient…

> $ cat ./bin/ltsp-arch-debian-edu
> #!/bin/sh
> LC_ALL=C
> export LC_ALL
> arch="$(/usr/bin/dpkg --print-architecture)"
> if [ 'amd64' = "$arch" ] ; then
> /bin/echo i386
> else
> echo "$arch"
> fi

…or would have been?

$ git log -p  5d5a545c75379f24bcc69dd7339e6bea8d1fc6ad
commit 5d5a545c75379f24bcc69dd7339e6bea8d1fc6ad
Author: Wolfgang Schweer 
Date:   Mon Jan 22 20:33:51 2018 +0100

Adjust PXE menu generation to handle also the case for 64-Bit-PC.

  Replace hardcoded i386 arch with 'ltsparch' variable with i386 default.
  Add code to discover a diskless workstation LTSP chroot installation.
  Add configuration file /etc/debian-edu/pxeinstall.conf with examples.


-- 
cheers,
Holger


signature.asc
Description: PGP signature

Bug#888626: debian-edu-config: do we really need ./bin/ltsp-arch-debian-edu

[Holger Levsen]

Package: debian-edu-config
Severity: normal

hi,

do we really need ./bin/ltsp-arch-debian-edu ? I mean:

$ cat ./bin/ltsp-arch-debian-edu
#!/bin/sh
LC_ALL=C
export LC_ALL
arch="$(/usr/bin/dpkg --print-architecture)"
if [ 'amd64' = "$arch" ] ; then
/bin/echo i386
else
echo "$arch"
fi


-- 
cheers,
Holger


signature.asc
Description: PGP signature

Bug#888484: Patch still not available

[Ninos Ego]

Hey there,

I do not want to stress, but does it have any reasons, why it takes so
long to patch clamav with severity "grave"? Can you guys may tell me how
long you still need to fix clamav in current debian stable (stretch)?
ATM clamav is running on our systems for spam mail protection. If you
still need some time (> 12h), I'm forced to disable clamav as long as
it's not fixed. < 0.99.3 is vulnerable for code execution...

Kindest regards

Bug#888625: RM: d-conf -- RoM; source package has been renamed to dconf

[Jeremy Bicha]

Package: ftp.debian.org
X-Debbugs-Cc: d-c...@packages.debian.org, elb...@debian.org

The d-conf source package has been renamed to dconf in testing and
unstable. Please remove the d-conf source package only (from
unstable). Do not remove any binary packages since they are all
provided by the new dconf source package instead. There is no need to
worry about reverse dependencies since we aren't removing binary
pacakges.

I suspect d-conf doesn't show on the cruft report because libdconf-doc
is arch: all and arch:all isn't handled very well yet.

On behalf of the Debian GNOME team,
Jeremy Bicha

Bug#884173: Extensions are just part of it

[Matías Bellone]

Thanks to my wife who did a lot of research on this, it would appear that
it is not a new issue. The last time this happened was with Chromium
58.0.3071.109 and can be seen reported in the armbian forums:
https://forum.armbian.com/topic/4668-chromium-browser-fails-to-launch/

The extension to blame in the "media router" internal extension, and can be
disabled through chromium://flags

That solution is based off the corresponding Ubuntu bug:
https://bugs.launchpad.net/ubuntu/+source/chromium-browser/+bug/1702407

Regards,
Toote

Bug#880612: RFS: imenu-list/0.8-1 [ITP]

[Nicholas D Steeves]

Dear mentors and emacsen team,

I am looking for a sponsor for my package "imenu-list".  It is a
dependency for the spacemacs packaging effort and should also be a
recommended dependency for fountain-mode (see blocking bugs for more
info).

Package name: imenu-list
Version : 0.8-1
Upstream Author : Bar Magal 
URL : https://github.com/bmag/imenu-list
License : GPL-3+
Section : lisp

It builds this binary package:

elpa-imenu-list - show the current Emacs buffer's imenu entries in a 
separate window

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

https://mentors.debian.net/package/imenu-list

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

dget -x 
https://mentors.debian.net/debian/pool/main/i/imenu-list/imenu-list_0.8-1.dsc

Alternatively, the repository can be cloned with this command:

git clone https://salsa.debian.org/emacsen-team/imenu-list

More information about hello can be obtained from 
https://github.com/bmag/imenu-list

Regards,
Nicholas


signature.asc
Description: PGP signature

Bug#888548: kismet: Update to a more recent version

[Nikos Andrikos]

Hi Thomas,

>From what I see there is no newer release in the downloads page:
https://www.kismetwireless.net/download.shtml

Do you think there are changes to be included in a new release?
If yes, we should contact upstream in order to ask them about.

Kind regards,
Nick

--
=Do-
N.AND

2018-01-27 0:21 GMT+01:00 Thomas Andrejak :

> Source: kismet
> Version: 2016.07.R1-1
> Severity: wishlist
>
> The actual version is 2016 and start to be old. Please update to a
> more recent version.
>
> Regards
>
> Thanks
>
> Thomas
>

Bug#888624: ITP: python-josepy -- JOSE implementation for Python

[Harlan Lieberman-Berg]

Package: wnpp
Severity: wishlist
Owner: Harlan Lieberman-Berg 

* Package name: python-josepy
  Version : 1.0.1
  Upstream Author : Certbot Team
* URL : https://pypi.python.org/pypi/josepy
* License : Apache-2.0
  Programming Lang: Python
  Description : JOSE implementation for Python

 This package is a Python implementation of the standards developed by
 IETF Javascript Object Signing and Encryption (Active WG), in
 particular the following RFCs:

 - JSON Web Algorithms (JWA)
 - JSON Web Key (JWK)
 - JSON Web Signature (JWS)

 This package was originally developed as part of the ACME protocol
 implementation in python-acme, but has now been split out into its
 own module.

Bug#888564: www.debian.org: Release-critical bugs status page has wrong designation for stable and testing

[Don Armstrong]

On Sat, 27 Jan 2018, Adam D. Barratt wrote:
> On Sat, 2018-01-27 at 14:39 +0800, Boyuan Yang wrote:
> > Thanks for your work!
> > 
> > Just out of curiosity, why is the source code of bugs.debian.org
> > component not hosted on Debian infrastructure?
> 
> It is - https://bugs.debian.org/debbugs-source/ - I don't believe
> there's a web interface over that repository though, so it's not as
> convenient for pointing to individual fixes.

That's correct. [I would have linked to salsa, but I don't know how to
easily generate a link to a single commit; I've got redirect rules for
git.donarmstrong.com that do that.]

> My understanding (although Don can obviously confirm / correct) is that
> Don tends to develop on his own instance and then push to the Debian
> instance once it's ready.

That's correct. I try to push everything to that instance (and the one
on salsa.debian.org and github.com) as quickly as possible. [The code
that is running on bugs.debian.org is guaranteed to be on
https://bugs.debian.org/debbugs-source/.]

Though I probably should drop a README.html in that directory to
describe what is actually in that directory and link to everywhere else.

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

"The trouble with you, Ibid" he said, "is that you think you're the
biggest bloody authority on everything"
 -- Terry Pratchet _Pyramids_ p146

Bug#888623: pkg-perl-tools: dpt forward fails to fork GitHub repo without org

[Christopher Hoskin]

Package: pkg-perl-tools
Version: 0.39
Severity: normal

Dear Maintainer,

There doesn't appear to be a way for a user who is not a member of 
pkg-perl-tools or another organisation on GitHub to use dpt forward to forward 
a patch upstream via forking.

If the user is not a member of pkg-perl-tools on GitHub the following messages 
are displayed:

dpt forward 
Use of uninitialized value $url in concatenation (.) or string at 
/usr/share/pkg-perl-tools/forward line 428.
Use of uninitialized value $url in concatenation (.) or string at 
/usr/share/pkg-perl-tools/forward line 429.
Use of uninitialized value $url in concatenation (.) or string at 
/usr/share/pkg-perl-tools/forward line 468.

the repo is not forked, and the pull request not issued.

If the user instead does:

DPT_GITHUB_ORGNAME= dpt forward debian/patches/grammar.patch 

where  is a GitHub organisation the user is a member of then the error 
does not occur.

I tried DPT_GITHUB_ORGNAME= but that doesn't appear to help.

Thanks.

Christopher Hoskin

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

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

Versions of packages pkg-perl-tools depends on:
ii  debhelper  11.1.3
ii  devscripts 2.17.12
ii  dh-make-perl   0.98
ii  dpkg-dev   1.19.0.5
ii  git1:2.15.1-3
ii  git-buildpackage   0.9.6
ii  libdatetime-perl   2:1.45-1
ii  libdpkg-perl   1.19.0.5
ii  libgit-repository-perl 1.321-1
ii  libipc-run-perl0.96-1
ii  libjson-xs-perl3.040-1
ii  libparse-debianchangelog-perl  1.2.0-12
ii  libproc-invokeeditor-perl  1.13-1
ii  librt-client-rest-perl 1:0.50-1
ii  lintian2.5.72
ii  openssh-client [ssh-client]1:7.6p1-3
ii  perl   5.26.1-4
ii  pristine-tar   1.42
ii  quilt  0.63-8.2

Versions of packages pkg-perl-tools recommends:
ii  autodep8   0.10
ii  autopkgtest5.1
ii  libconfig-model-dpkg-perl  2.105
ii  libconfig-model-perl   2.116-1
ii  libdebian-copyright-perl   0.2-4
ii  libfile-slurp-perl .19-6
ii  libmime-lite-perl  3.030-2
ii  libmodule-inspector-perl   1.05-2
ii  libnet-github-perl 0.93-1
ii  libsoap-lite-perl  1.26-1
ii  libwww-mechanize-perl  1.86-1
ii  libyaml-libyaml-perl   0.69+repack-1
ii  lintian2.5.72
ii  myrepos [mr]   1.20160123

Versions of packages pkg-perl-tools suggests:
ii  bc   1.07.1-1
ii  cdbs 0.4.156
pn  duck 
pn  moreutils
pn  perl-depends 
ii  python   2.7.14-4
ii  python-launchpadlib  1.10.5-1

-- no debconf information

Bug#886769: Processed (with 1 error): progress

[Geert Stappers]

Control: block 886772 by -1

On Sat, Jan 27, 2018 at 09:51:03PM +, Debian Bug Tracking System wrote:
> Processing control commands:
> 
> > -1 blocks 886772
> Unknown command or malformed arguments to command.
> 

My second and last attempt
for marking #886772 as being blocked by #886769.

Having in the webI/F of the BTS links to both bugs is nice,
but not important.


Groeten
Geert Stappers
-- 
Leven en laten leven

Bug#888622: ITP: randrctl -- Profile based screen manager for X

[Gaetano Guerriero]

Package: wnpp
Severity: wishlist

* Package name: randrctl
  Version : 1.5.0
  Upstream Author : Dmytro Kostiuchenko 
* URL or Web page : http://github.com/edio/randrctl
* License : GPLv3
  Description : Profile based screen manager for X


randrdctl is a solution to automatically manage xrandr profiles.

It is especially useful to handle multiple screens when not using a full
desktop environment.
It is implemented as a python (3) script with minimal external dependencies.

Bug#873047: libgfshare: gfsplit SIGSEGV if /dev/urandom is not accessible

[Simon McVittie]

On Wed, 23 Aug 2017 at 19:13:57 -0700, Chris Lamb wrote:
> gfsplit SIGSEGV if /dev/urandom is not accessible as it doesn't fallback
> to the (correctly named!) gfshare_bad_idea_but_fill_rand_using_random; it
> prints a warning to stderr.

I can't help wondering whether this might be deliberate, or at least,
not a bad idea. The upstream commit message that changed the ABI to make
it mandatory to set a randomness-obtaining function says:

"""
Update to require gfshare_fill_rand to be initialised.

Require explicit initialisation of gfshare_fill_rand so that
numpties get a SEGV instead of bad randomness.
"""
— 
https://git.gitano.org.uk/libgfshare.git/commit/?id=da0566422af4e0ad5c9e17cfe21f563e4274338d

and I think failure to read /dev/urandom is a similar situation? If
you're using gfsplit/gfcombine for crypto, it had better be using
crypto-quality randomness (I don't think the theoretical basis for
libgfshare is sound if your randomness isn't random).

If that's the intention, it would be better if it was clearly deliberate
by calling abort() or fprintf() + exit().

smcv

Bug#886769: progress

[Geert Stappers]

Control: -1 blocks 886772

It is nice to see that fakemachine build-depency "gocpio" is allready
packaged in Debian ( https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=886763 )

So one step closer to having debos package in Debian
 ( https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=886772 )
 

@Hector: Thanks


Groeten
Geert Stappers
-- 
Leven en laten leven

Bug#886332: autopkgtest-virt-qemu: how to make persistent dist-upgrades

[Martin Pitt]

Hello Johannes,

Johannes Schauer [2018-01-12 14:27 +0100]:
> My central question: is it totally out of scope for autopkgtest to support
> modifying the underlying base image?

IMHO yes, as I laid out in my previous reply. I don't want autopkgtest to get
into the business of being a "VM manager", as this just opens a huge ratsnest.
There are other tools for this, and autopkgtest should avoid making any
assumptions about what's inside a VM that isn't absolutely necessary for
running tests, as with every new assumption you limit which kinds of VMs you
can use with it.

> When I added the autopkgtest backend to sbuild in addition to schroot, I did
> this with the long term goal in mind that at some point I could also update 
> the
> sbuild-update program to support the autopkgtest backend.

It's not what I would recommend doing actually, as with backends like LXC, lxd,
or qemu it's actually more reliable and presumably not even slower to just
download a current daily image than upgrading existing ones. With schroots it
makes a lot more sense, but there's already mk-sbuild for that job. Of course
you can work with upgraded testbeds, but by nature they are less reliable.

> Users could then use sbuild-update which would automatically do the right
> thing independent of the backend. But if you say that autopkgtest never ever
> touches the VM image this feature seems to be impossible to implement.

But this just shifts the whole ratsnest into autopkgtest: E. g. what do you do
when upgrades fail?  Or if the image is not a "classic" full-rpm image, but
something like the Ubuntu Touch or snappy images, or has a read-only root, or
whatnot? autopkgtest would then need to grow/impose a system for snapshotting
(in the VM case) and a backup schema for schroots and LXC containers, etc. None
of that is it's core business, and all of that potentially interferes with what
the admin does, etc.

> So do you really see such a feature totally out of scope for autopkgtest?

That's my current gut feeling, yes. That said, if some other maintainer thinks
that this is a good idea, I won't veto them, but IMHO it's a rather slippy
slope, and prone to become a parallel implementation of libguestfs :-)

> Because unless I'm mistaken, I don't think there exists another software
> besides autopkgtest which offers a unified interface to such a wide range of
> backends.

For talking to a testbed, yes. But there is no unified approach/code for
updating the original testbed (like making a new LXC image, or applying an
overlay to a qemu image, or working with a source: schroot, etc.), or managing
revisions or rollback of schroot/lxc/lxd/qemu images, as each backend needs
specific ways of dealing with that problem. The two concrete CI system that use
autopkgtest today (Debian's debci and Ubuntu's autopkgtest-cloud can restrict
that logic to the specific backends that they use, and these are complicated
enough already IMHO.

So implementing it in autopkgtest would not really be less work than just
running a specific thing like sbuild-update or lxc-download'ing a current
daily. It would be a lot *more* complicated to try and reimplement all these
tools in autopkgtest.

Martin


signature.asc
Description: PGP signature

Bug#888621: Regression, Please Rebuild

[Barak A. Pearlmutter]

Package: libace-dev
Version: 6.4.5+dfsg-1+b1

I'm having trouble building ivtools, see
https://bugs.debian.org/887774 which is a reappearance of
https://bugs.debian.org/701300 which was due to some difference in
symbol mangling between the compiler used for libace-dev and the
compiler used in ivtools.

I just recompiled ace using the same compiler as ivtools and
everything went swimmingly.

So, please push an update is libace-dev as soon as you can. In fact,
just tickling a rebuild might be enough---but upstream ace 6.4.6 is
out anyway so I'd imagine you'll want to upload that.

Thanks for your help.

Cheers,

--Barak.

Bug#888126: [patch] Please enable systemd-sysusers unit

[Martin Pitt]

Hello Michael, all,

Michael Vogt [2018-01-23 16:15 +0100]:
> There is no downside (AFAICS), the unit is conditiional on
> ConditionNeedsUpdate=/etc so it will never run on default Debian
> systems.

Agreed. It will mostly be dead weight in the systemd packages, but the new tool
isn't too big, and most importantly, it doesn't drag in a new dependency.

> I also looked into providing debian specific basic.conf that would
> re-generate the base-passwd passwd.master (and group) file.  However it looks
> like the systemd-sysusers file format is not expressive enough for this
> (which is slightly unfortunate). I.e. we have entries like

Felipe and I also looked at this some years ago, and stumbled over the same
issues. I can't find the discussion on the ML or bugs.d.o now, though. But this
was the reason why we never enabled it, as it couldn't faithfully replicate
Debian's static system users.

> sync:*:4:65534:sync:/bin:/bin/sync
> 
> which cannot be represented because you cannot specify a different
> primary gid in the sysusers file (or a login shell). So extra work is
> required for this but (personally) I would love to this is.

Since you freshly looked at this, was this the only problem? I figure the sync
group is mostly unused anyway, and completely irrelevant for containers - but
does this also affect static groups which are actually important? I. e. which
static groups cannot be replicated with sysusers?

IMHO if we enable this, we should also provide a reasonably correct static
sysusers so that the program actually works as intended. It doesn't need to
(and can't right now) be perfect, but at least not completely break your
system.

Thanks,

Martin

Bug#888620: evince: apparmor profile prevents loading git-annex files

[Michael Gold]

Package: evince
Version: 3.26.0-2

A recent kernel upgrade pulled in AppArmor, after which I was no longer
able to view (some) PDF files in git-annex repositories.  For example:
$ cd
$ pwd -P
/home/michael
$ cd ~/x
$ mkdir git-annex-test
$ cd git-annex-test/
$ pwd -P
/xr0/michael/x/git-annex-test
$ git init
Initialized empty Git repository in /xr0/michael/x/git-annex-test/.git/
$ git annex init
init  ok
(recording state in git...)
$ cp ~/download/meltdown.pdf .
$ git annex add --backend=SHA256 meltdown.pdf
add meltdown.pdf ok
(recording state in git...)
$ ls -l
total 4
lrwxrwxrwx 1 michael michael 186 Jan 27 14:54 meltdown.pdf -> 
.git/annex/objects/j9/5J/SHA256-s188549--593ea59090a096211b06194fb5985d5c2ea2b5bd85b540d01802d5d7da2d36f8/SHA256-s188549--593ea59090a096211b06194fb5985d5c2ea2b5bd85b540d01802d5d7da2d36f8
$ /usr/bin/evince meltdown.pdf

(This is basically the same setup I use to store most of my PDF files.)

The evince window appears and shows this error:
Unable to open document 
“file:///home/michael/x/git-annex-test/meltdown.pdf”.
And this message is logged:
apparmor="DENIED" operation="open" profile="/usr/bin/evince" 
name="/xr0/michael/x/git-annex-test/.git/annex/objects/j9/5J/SHA256-s188549--593ea59090a096211b06194fb5985d5c2ea2b5bd85b540d01802d5d7da2d36f8/SHA256-s188549--593ea59090a096211b06194fb5985d5c2ea2b5bd85b540d01802d5d7da2d36f8"
 pid=21442 comm="EvJobScheduler" requested_mask="r" denied_mask="r" fsuid=1000 
ouid=1000

The problem seems to be that the file isn't treated as being under $HOME
and isn't treated as having a ".pdf" suffix.  Both are true for the name
being opened, but not for the target.

Workaround (disables the policy):
# ln -s ../usr.bin.evince /etc/apparmor.d/disable/
# apparmor_parser -R /etc/apparmor.d/usr.bin.evince

I don't understand what the policy is trying to guard against; a comment
says requiring an extension is "more secure", but doesn't explain why.

- Michael


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

Kernel: Linux 4.14.0-3-amd64 (SMP w/8 CPU cores)
Locale: LANG=en_CA.UTF-8, LC_CTYPE=en_CA.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_CA:en (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)
LSM: AppArmor: enabled

Versions of packages evince depends on:
ii  dconf-gsettings-backend [gsettings-backend]  0.26.1-2
ii  evince-common3.26.0-2
ii  gsettings-desktop-schemas3.24.1-2
ii  libatk1.0-0  2.26.1-2
ii  libc62.26-2
ii  libcairo-gobject21.15.8-3
ii  libcairo21.15.8-3
ii  libevdocument3-4 3.26.0-2
ii  libevview3-3 3.26.0-2
ii  libgdk-pixbuf2.0-0   2.36.11-1
ii  libglib2.0-0 2.54.2-5
ii  libgnome-desktop-3-123.26.2-4
ii  libgtk-3-0   3.22.26-2
ii  libnautilus-extension1a  3.26.2-1
ii  libpango-1.0-0   1.40.14-1
ii  libpangocairo-1.0-0  1.40.14-1
ii  libsecret-1-00.18.5-5
ii  shared-mime-info 1.9-2

Versions of packages evince recommends:
ii  dbus-x11 [dbus-session-bus]  1.12.2-1

Versions of packages evince suggests:
pn  gvfs 
pn  nautilus-sendto  
ii  poppler-data 0.4.8-2
pn  unrar

-- no debconf information


signature.asc
Description: PGP signature

Bug#888566: vim FTBFS on alpha: vim segfaults in the build

[James McCoy]

On Sat, Jan 27, 2018 at 02:37:21PM -0500, James McCoy wrote:
> On Sat, Jan 27, 2018 at 05:50:16PM +1300, Michael Cree wrote:
> > [snip useful details]
> > 
> > Four of those bytes difference are due to the field b_ino in the
> > struct (of type ino_t).  And indeed examining the build log [1]
> > one sees option.c is compiled with -DFILE_OFFSET_BITS=64 but
> > misc1.c is NOT compiled with that option, hence the difference
> > in offsets to fields in the buf_T struct.
> 
> It looks like you came to the same conclusion as we did in #827319.  Vim
> uses autoconf's AC_SYS_LARGEFILE to determine whether _FILE_OFFSET_BITS
> needs to be set (and decides it doesn't), however the Perl bindings
> always force _FILE_OFFSET_BITS=64[0].

[0]: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=827319#118

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

Bug#887774: My hate for C++ is a bottomless cup; I pour and pour

[Barak A. Pearlmutter]

This is a recurrence of https://bugs.debian.org/701300 which was
caused by libace being compiled with a different version of the
compiler than ivtools, and these two versions mangling a particular
symbol differently.

If libace (src:pkg-ace) could be tickled into a rebuild against the
latest sid toolchain, that might solve the problem.

Bug#888316: jackson-databind: CVE-2018-5968

[Markus Koschany]

Hi folks,

Am 25.01.2018 um 15:23 schrieb Salvatore Bonaccorso:
> Hi Markus,
> 
> On Thu, Jan 25, 2018 at 02:40:10PM +0100, Markus Koschany wrote:
>> Hi,
>>
>> On Wed, 24 Jan 2018 23:02:44 +0100 Salvatore Bonaccorso
>>  wrote:
>>> Source: jackson-databind
>>> Version: 2.9.1-1
>>> Severity: grave
>>> Tags: patch security upstream
>>> Forwarded: https://github.com/FasterXML/jackson-databind/issues/1899
>>> Control: found -1 2.8.6-1+deb9u2
>>> Control: found -1 2.4.2-2+deb8u2
>>>
>>> Hi,
>>>
>>> the following vulnerability was published for jackson-databind.
>>
>> [...]
>>
>> Thanks for reporting. I had a look at jackson-databind in Stretch. We
>> just need to apply the patch to BeanDeserializerFactory.java again. As
>> for Sid upgrading to the latest upstream release 2.9.4 should also
>> resolve this. I'm working on it now.
> 
> Perfect, thank you! We (Moritz) have added it to the dsa-needed list
> for jessie and stretch, so once you have the update can you contact
> the security team alias, one of us will then ack the upload.

I have prepared security updates of jackson-databind for Stretch and
Jessie and would appreciate another look at the patches.

The fix for CVE-2018-5968 is straightforward. The blacklist is simply
extended.

However upstream decided to refactor the code for CVE-2017-17485 and I
decided to apply the changes to BeanDeserializerFactory.java again
instead of using the new helper class SubTypeValidator. Here is my
thought process how to create the patch based on the solution in
upstream bug 1855 [1]

1. Extend the blacklist. [2]
2. Instead of creating a new method validateSubType, I copied the fix
into checkIllegalTypes in BeanDeserializerFactory again.[3] The behavior
remains the same. This code catches some specific cases for the spring
framework.
3. I also applied the regression fix in [4] (also mentioned in bug 1855)
4. I believe that [5] only applies to the refactored code and since we
don't use that it is irrelevant for us.

Regards,

Markus

[1] https://github.com/FasterXML/jackson-databind/issues/1855
[2]
https://github.com/FasterXML/jackson-databind/commit/f031f27a31625d07922bdd090664c69544200a5d
[3]
https://github.com/FasterXML/jackson-databind/commit/2235894210c75f624a3d0cd60bfb0434a20a18bf
[4]
https://github.com/FasterXML/jackson-databind/commit/bb45fb16709018842f858f1a6e1118676aaa34bd
[5]
https://github.com/FasterXML/jackson-databind/commit/978798382ceb72229e5036aa1442943933d6d171
diff -Nru jackson-databind-2.4.2/debian/changelog 
jackson-databind-2.4.2/debian/changelog
--- jackson-databind-2.4.2/debian/changelog 2017-11-16 09:13:27.0 
+0100
+++ jackson-databind-2.4.2/debian/changelog 2018-01-27 19:37:47.0 
+0100
@@ -1,3 +1,13 @@
+jackson-databind (2.4.2-2+deb8u3) jessie-security; urgency=high
+
+  * Team upload.
+  * Fix CVE-2017-17485 and CVE-2018-5968:
+Bybass of deserialization blackist to disallow unauthenticated remote code
+execution. These CVE exist due to an incomplete fix for CVE-2017-7525.
+(Closes: #888316, #888318)
+
+ -- Markus Koschany   Sat, 27 Jan 2018 19:37:47 +0100
+
 jackson-databind (2.4.2-2+deb8u2) jessie-security; urgency=high
 
   * Team upload
diff -Nru jackson-databind-2.4.2/debian/patches/CVE-2017-17485.patch 
jackson-databind-2.4.2/debian/patches/CVE-2017-17485.patch
--- jackson-databind-2.4.2/debian/patches/CVE-2017-17485.patch  1970-01-01 
01:00:00.0 +0100
+++ jackson-databind-2.4.2/debian/patches/CVE-2017-17485.patch  2018-01-27 
19:37:47.0 +0100
@@ -0,0 +1,75 @@
+From: Markus Koschany 
+Date: Sat, 27 Jan 2018 20:16:02 +0100
+Subject: CVE-2017-17485
+
+Bug-Debian: https://bugs.debian.org/888318
+Bug-Upstream: https://github.com/FasterXML/jackson-databind/issues/1855
+Origin: 
https://github.com/FasterXML/jackson-databind/commit/f031f27a31625d07922bdd090664c69544200a5d
+Origin: 
https://github.com/FasterXML/jackson-databind/commit/2235894210c75f624a3d0cd60bfb0434a20a18bf
+Origin: 
https://github.com/FasterXML/jackson-databind/commit/bb45fb16709018842f858f1a6e1118676aaa34bd
+---
+ .../databind/deser/BeanDeserializerFactory.java| 37 +++---
+ 1 file changed, 32 insertions(+), 5 deletions(-)
+
+diff --git 
a/src/main/java/com/fasterxml/jackson/databind/deser/BeanDeserializerFactory.java
 
b/src/main/java/com/fasterxml/jackson/databind/deser/BeanDeserializerFactory.java
+index c536b46..9b56b08 100644
+--- 
a/src/main/java/com/fasterxml/jackson/databind/deser/BeanDeserializerFactory.java
 
b/src/main/java/com/fasterxml/jackson/databind/deser/BeanDeserializerFactory.java
+@@ -38,6 +38,8 @@ public class BeanDeserializerFactory
+ {
+ private static final long serialVersionUID = 1;
+ 
++protected final static String PREFIX_STRING = "org.springframework.";
++
+ /**
+  * Signature of Throwable.initCause method.
+  */
+@@ -75,6 +77,9 @@ public class BeanDeserializerFactory
+ 
s.add("org.springframework.beans.factory.config.PropertyPathFactoryBean");
+   

Bug#888619: gzip: please add Homepage field

[Jakub Wilk]

Source: gzip
Version: 1.6-5
Severity: wishlist

Please add

  Homepage: https://www.gnu.org/software/gzip/

to debian/control.

--
Jakub Wilk

Bug#888618: youtube-dl: package youtube-dl to 28-01-2018 or later.

[shirish शिरीष]

Package: youtube-dl
Version: 2017.12.31-1
Severity: wishlist

Dear Maintainer,

Please update the package to 2018-01-28

https://github.com/rg3/youtube-dl/releases/download/2018.01.27/youtube-dl-2018.01.27.tar.gz


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

Kernel: Linux 4.14.0-3-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_IN.UTF-8, LC_CTYPE=en_IN.UTF-8 (charmap=UTF-8)
(ignored: LC_ALL set to en_IN.UTF-8), LANGUAGE=en_IN.UTF-8
(charmap=UTF-8) (ignored: LC_ALL set to en_IN.UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages youtube-dl depends on:
ii  dpkg   1.19.0.5
ii  python33.6.4-1
ii  python3-pkg-resources  38.2.4-2

Versions of packages youtube-dl recommends:
ii  ca-certificates  20170717
ii  curl 7.57.0-1
ii  ffmpeg   7:3.4.1-1+b2
ii  mpv  0.27.0-2+b3
ii  phantomjs2.1.1+dfsg-2
ii  rtmpdump 2.4+20151223.gitfa8646d.1-1+b1
ii  wget 1.19.3-2

youtube-dl suggests no packages.

-- no debconf information


-- 
  Regards,
  Shirish Agarwal  शिरीष अग्रवाल
  My quotes in this email licensed under CC 3.0
http://creativecommons.org/licenses/by-nc/3.0/
http://flossexperiences.wordpress.com
EB80 462B 08E1 A0DE A73A  2C2F 9F3D C7A4 E1C4 D2D8

Bug#888617: php7.0-fpm: php7.0 fpm causes content encoding error when parent directory with php file is in a symlink

[Christopher]

Package: php7.0-fpm
Version: 7.0.27-0+deb9u
Severity: important

Dear Maintainer,

I was upgrading from old-stable to stable.
I was using php-fpm to serve content from several website via virtual servers.
These websites have different directories. The webserver-root is a symlinked 
directory linking to a different directory.

When upgrading to stretch this setup failed for some php-applications but not 
all producing a content encoding error.
Tested the following with recent installation of Firefox, Opera and Chrome. 
Client OS is an Ubuntu 17.10. Server-OS is a Debian-Stable.

Setup for diagnosis:
* Fresh install with untouched config for php7.0-fpm (except logging to syslog)
* Fresh install with untouched config for phpmyadmin - integrated via "alias" 
directive in apache config
* phpinfo.php file with 
* Fresh download with untouched config for extplorer - files are in webroot - 
no "alias" directive
--> Using standard config. Shouldn't be some wierd config issue
Looking at apache2 error, phperrorlog, fpm logs and syslog but the issue does 
not produce any messages or entries.

* phpmyadmin or extplorer in symlinked webroot with php7.0-fpm --> Encoding 
error; Content is gzipped (verified with wget --header "Accept-Encoding: gzip, 
deflate")
* phpinfo in symlinked webroot with php7.0-fpm --> No Encoding error; Content 
is gzipped
* phpmyadmin or extplorer in symlinked webroot with libapache2-mod-php7.0 --> 
No Encoding error
* phpmyadmin or extplorer in not-symlinked webroot with php7.0-fpm --> No 
Encoding error
* when using wget without --header "Accept-Encoding: gzip, deflate" --> No 
Encoding error

Workaround:
* In php.ini for fpm: disable_functions = ob_gzhandler
--> Might make problems for other apps or setups?

Conclusion:
My deduction is, that for some wierd reason it seems to be a problem when a 
php-application is capable of using the gzip function in php7.0-fpm when the 
path leading to the file contains a symlink somewhere along the path
Perhaps some dual compression as apache seems to compress the output as well? 
But wasn't able to see any difference in the compressed output using wget...

apache2-mod-deflate is installed and activated. Configuration of 
mods-available/deflate.conf is unchanged

Feel free to ask for more details :)

Thanks

Christopher


-- Package-specific info:
 Additional PHP 7.0 information 

 PHP 7.0 SAPI (php7.0query -S): 

 PHP 7.0 Extensions (php7.0query -M -v): 

 Configuration files: 
[PHP]
engine = On
short_open_tag = Off
precision = 14
output_buffering = 4096
zlib.output_compression = Off
implicit_flush = Off
unserialize_callback_func =
serialize_precision = 17
disable_functions = 
pcntl_alarm,pcntl_fork,pcntl_waitpid,pcntl_wait,pcntl_wifexited,pcntl_wifstopped,pcntl_wifsignaled,pcntl_wifcontinued,pcntl_wexitstatus,pcntl_wtermsig,pcntl_wstopsig,pcntl_signal,pcntl_signal_dispatch,pcntl_get_last_error,pcntl_strerror,pcntl_sigprocmask,pcntl_sigwaitinfo,pcntl_sigtimedwait,pcntl_exec,pcntl_getpriority,pcntl_setpriority
disable_classes =
zend.enable_gc = On
expose_php = Off
max_execution_time = 30
max_input_time = 60
memory_limit = 128M
error_reporting = E_ALL
display_errors = Off
display_startup_errors = On
log_errors = On
log_errors_max_len = 1024
ignore_repeated_errors = Off
ignore_repeated_source = Off
report_memleaks = On
track_errors = Off
html_errors = On
error_log = syslog
variables_order = "GPCS"
request_order = "GP"
register_argc_argv = Off
auto_globals_jit = On
post_max_size = 8M
auto_prepend_file =
auto_append_file =
default_mimetype = "text/html"
default_charset = "UTF-8"
doc_root =
user_dir =
enable_dl = Off
file_uploads = On
upload_max_filesize = 2M
max_file_uploads = 20
allow_url_fopen = On
allow_url_include = Off
default_socket_timeout = 60
[CLI Server]
cli_server.color = On
[Date]
[filter]
[iconv]
[intl]
[sqlite3]
[Pcre]
[Pdo]
[Pdo_mysql]
pdo_mysql.cache_size = 2000
pdo_mysql.default_socket=
[Phar]
[mail function]
SMTP = localhost
smtp_port = 25
mail.add_x_header = On
[SQL]
sql.safe_mode = Off
[ODBC]
odbc.allow_persistent = On
odbc.check_persistent = On
odbc.max_persistent = -1
odbc.max_links = -1
odbc.defaultlrl = 4096
odbc.defaultbinmode = 1
[Interbase]
ibase.allow_persistent = 1
ibase.max_persistent = -1
ibase.max_links = -1
ibase.timestampformat = "%Y-%m-%d %H:%M:%S"
ibase.dateformat = "%Y-%m-%d"
ibase.timeformat = "%H:%M:%S"
[MySQLi]
mysqli.max_persistent = -1
mysqli.allow_persistent = On
mysqli.max_links = -1
mysqli.cache_size = 2000
mysqli.default_port = 3306
mysqli.default_socket =
mysqli.default_host =
mysqli.default_user =
mysqli.default_pw =
mysqli.reconnect = Off
[mysqlnd]
mysqlnd.collect_statistics = On
mysqlnd.collect_memory_statistics = Off
[OCI8]
[PostgreSQL]
pgsql.allow_persistent = On
pgsql.auto_reset_persistent = Off
pgsql.max_persistent = -1
pgsql.max_links = -1
pgsql.ignore_notice = 0
pgsql.log_notice = 0
[bcmath]
bcmath.scale = 0
[browscap]
[Session]
session.save_handler = files
session.use_stri

Bug#888616: libtk8.7 : Depends: libtcl8.7 (>= 8.7.0-2) but 8.7.0~a1+dfsg-1 is installed

[積丹尼 Dan Jacobson]

Package: libtk8.7

I see:

The following NEW packages will be installed:
  libtk8.7{ab} (D: libtcl8.7)  tk8.7{a} (D: tk, S: libtk8.7)
The following packages will be REMOVED:
  libtcl8.6{pu} (D: libtk8.6, D: tk8.6)  libtk8.6{pu} (D: tk8.6)  tk8.6{pu} (D: 
tk, S: libtk8.6)
The following packages will be upgraded:
  tk
1 packages upgraded, 2 newly installed, 3 to remove and 0 not upgraded.
Need to get 873 kB of archives. After unpacking 4,278 kB will be freed.
The following packages have unmet dependencies:
 libtk8.7 : Depends: libtcl8.7 (>= 8.7.0-2) but 8.7.0~a1+dfsg-1 is installed
The following actions will resolve these dependencies:

 Remove the following packages:
1) tk [8.6.0+9 (now, unstable)]
2) tk5 [0.6-6.2 (now, unstable)]

 Keep the following packages at their current version:
3) libtk8.7 [Not Installed]
4) tk8.7 [Not Installed]


Accept this solution? [Y/n/q/?] n
The following actions will resolve these dependencies:

 Keep the following packages at their current version:
1) libtcl8.6 [8.6.8+dfsg-2 (now, unstable)]
2) libtk8.6 [8.6.8-2 (now, unstable)]
3) libtk8.7 [Not Installed]
4) tk [8.6.0+9 (now, unstable)]
5) tk8.6 [8.6.8-2 (now, unstable)]
6) tk8.7 [Not Installed]

Bug#888615: ITP: libweb-api-perl -- simple base module for implementing RESTful APIs

[Christopher Hoskin]

Package: wnpp
Owner: Christopher Hoskin 
Severity: wishlist
X-Debbugs-CC: debian-de...@lists.debian.org, debian-p...@lists.debian.org

* Package name: libweb-api-perl
  Version : 2.2.3
  Upstream Author : Tobias Kirschstein 
* URL : https://metacpan.org/release/Web-API
* License : BSD-3-clause
  Programming Lang: Perl
  Description : simple base module for implementing RESTful APIs

Web::API is a simple base module to implement almost any RESTful API with just
a few lines of configuration. Implement the RESTful API of your choice in 10
minutes, roughly.

The package will be maintained under the umbrella of the Debian Perl Group.

--
Generated with the help of dpt-gen-itp(1) from pkg-perl-tools.

Bug#888614: Installation of dotnet35 doesn't finalize

[David Cortes]

Package: playonlinux
Version: 4.2.10-2

When trying to install dotnet35 on a wine prefix, the installer doesn't  
finalize, and seems to get stuck in an infinite loop about deleting an  
entry in the registry. It keeps repeating this same message:


(Yes|No) Are you sure you want to delete the registry key  
'HKEY_LOCAL_MACHINE\Software\Microsoft\NET Framework Setup\NDP\v3.5'?

Bug#888566: vim FTBFS on alpha: vim segfaults in the build

[James McCoy]

On Sat, Jan 27, 2018 at 05:50:16PM +1300, Michael Cree wrote:
> [snip useful details]
> 
> Four of those bytes difference are due to the field b_ino in the
> struct (of type ino_t).  And indeed examining the build log [1]
> one sees option.c is compiled with -DFILE_OFFSET_BITS=64 but
> misc1.c is NOT compiled with that option, hence the difference
> in offsets to fields in the buf_T struct.

It looks like you came to the same conclusion as we did in #827319.  Vim
uses autoconf's AC_SYS_LARGEFILE to determine whether _FILE_OFFSET_BITS
needs to be set (and decides it doesn't), however the Perl bindings
always force _FILE_OFFSET_BITS=64[0].

This discrepancy seems to be at least part of the problem.

> I am not sure why only some modules are compiled with
> -DFILE_OFFSET_BITS=64. Whatever the reason, it leads to a broken
> vim on Alpha.

When Vim gained support to dynamically link against Perl on Linux, it
changed the build to only use $(PERL_CFLAGS) for files which use
directly use Perl's APIs.  Since $(PERL_CFLAGS) is what's exporting
_FILE_OFFSET_BITS=64, only those files are compiled with that set.

So, we come back to the same question as before, I think.  Why doesn't
autoconf think _FILE_OFFSET_BITS=64 is needed (presumably this is
because it determines the relevant structures are _already_ 64-bit)?

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

Bug#888612: monotone: FTBFS with debhelper/11.1 due to empty build target

[Niels Thykier]

Source: monotone
Version: 1.1-9
Severity: serious
Tags: patch

Hi,

The monotone package FTBFS with debhelper/11.1 as it has an
empty build target.  This is caused by debhelper had a bug in its
handling of "explicitly defined rules targets" that has now been
fixed.

Previously, this happened to work because dpkg-buildpackage would
invoke "debian/rules build" (which would be a no-op) followed by
"fakeroot debian/rules binary".  During the binary target, dh's
suboptimal handling would run the build commands.


In the given case, monotone has an empty "build"-target to work around
rather old Debian practises.  Any supported version of Debian no
longer need these work arounds (as far as I remember), so I have
included a patch to remove said work arounds.


More details can be found in:
 * #886901 comment #35
 * #887688 comment #37
 * #880840

Apologies for the inconvenience.

Thanks,
~Niels
>From 58a8dd850ff9c294517677ce07487cc3f878b39d Mon Sep 17 00:00:00 2001
From: Niels Thykier 
Date: Sat, 27 Jan 2018 19:12:20 +
Subject: [PATCH] Remove dummy "build" target and now obsolete work arounds

Today, Debian buildds support build-arch and build-indep targets.
Remove the work arounds that assume that do not and also remove the
"magic" that attempts to undo "fakeroot" now that the build always
happens as a regular user.

Signed-off-by: Niels Thykier 
---
 debian/nofakeroot | 33 
 debian/rules  | 56 +++
 2 files changed, 3 insertions(+), 86 deletions(-)
 delete mode 100755 debian/nofakeroot

diff --git a/debian/nofakeroot b/debian/nofakeroot
deleted file mode 100755
index 18f0d02..000
--- a/debian/nofakeroot
+++ /dev/null
@@ -1,33 +0,0 @@
-#! /bin/sh
-
-# Usage:
-#   nofakeroot [command ...]
-#
-# Runs command after removing any trace of fakeroot from the environment it
-# receives.
-
-my_PRELOAD=
-for l in $LD_PRELOAD; do
-if ! echo $l | grep "libfakeroot[-a-z]*\\.so" > /dev/null; then
-   if [ -n "$my_PRELOAD" ]; then
-   my_PRELOAD="$my_PRELOAD $l"
-   else
-   my_PRELOAD="$l"
-   fi
-fi
-done
-
-was_IFS="$IFS" IFS=:
-my_LIBRARY_PATH=
-for p in $LD_LIBRARY_PATH; do
-if ! echo $p | grep "/libfakeroot\$" > /dev/null; then
-   if [ -n "$my_LIBRARY_PATH" ]; then
-   my_LIBRARY_PATH="${my_LIBRARY_PATH}:$p"
-   else
-   my_LIBRARY_PATH="$p"
-   fi
-fi
-done
-IFS="$was_IFS"
-
-LD_PRELOAD="$my_PRELOAD" LD_LIBRARY_PATH="$my_LIBRARY_PATH" eval "$@"
diff --git a/debian/rules b/debian/rules
index f3cabd8..ab54843 100755
--- a/debian/rules
+++ b/debian/rules
@@ -4,47 +4,6 @@
 # debian/rules for monotone, by Richard Levitte
 # based on the dh7 template provided by dh_make(1)
 
-# put this up top so it's the default rule.
-#
-# Policy (version 3.9.1.0, 2010-07-26, section 4.9) says that when
-# different binary packages are produced in different ways, it doesn't
-# make sense to have a build target that builds it all.  Quoted:
-#
-#   or some packages, notably ones where the same source tree is
-#   compiled in different ways to produce two binary packages, the
-#   build target does not make much sense. For these packages it is
-#   good enough to provide two (or more) targets (build-a and build-b
-#   or whatever) for each of the ways of building the package, and a
-#   build target that does nothing. The binary target will have to
-#   build the package in each of the possible ways and make the binary
-#   package out of each.
-#
-#   ...
-#
-#   When a package has a configuration and build routine which takes a
-#   long time, or when the makefiles are poorly designed, or when
-#   build needs to run clean first, it is a good idea to touch build
-#   when the build process is complete. This will ensure that if
-#   debian/rules build is run again it will not rebuild the whole
-#   program.
-#
-# We definitely have this situation, as we have -indep packages and
-# -arch packages, and we need to treat them separately, because the
-# buildds will build with -B after having installed only the Build-
-# Depends (for they are ignorant of B-D-I.  All die, O the
-# embarrassment)
-#
-# However, it also means that we're having configuring, building and
-# testing done via fakeroot, which isn't a good idea.  However, that's
-# easy to deal with with a little hack (see the file 'nofakeroot' in
-# this directory) and overrides for those cases.
-#
-# So, we disable the build target entirely and let the binary targets
-# take care of building as well (which dh provides support for, so we
-# really need nothing extra here).
-build:
-   @echo 'The build target is disabled, please use the appropriate binary 
target.'
-
 # Uncomment this to turn on verbose mode.
 export DH_VERBOSE=1
 
@@ -63,9 +22,6 @@ export BUILD_DATE = $(shell LC_ALL=C \
 %:
dh $@ --with=bash_completion,autoreconf
 
-override_dh_auto_configure:
-   debian/nofakeroot dh_auto_configure
-
 overri

Bug#888613: dnsmasq is started with argument -r /var/run/dnsmasq/resolv.conf by default. This configuration file is empty and dnsmasq will not resolve any DNS queries outside of the LAN. Writing local

[Lukas B.]

Package: dnsmasq
Version: 2.76-5+rpt1+deb9u1
Severity: important

Dear Maintainer,

Hi

-- System Information:
Distributor ID: Raspbian
Description:Raspbian GNU/Linux 9.3 (stretch)
Release:9.3
Codename:   stretch
Architecture: armv7l

Kernel: Linux 4.9.59-v7+ (SMP w/4 CPU cores)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8) (ignored: LC_ALL 
set to de_DE.UTF-8), LANGUAGE=de_DE.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set 
to de_DE.UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages dnsmasq depends on:
ii  dnsmasq-base 2.76-5+rpt1+deb9u1
ii  init-system-helpers  1.48
ii  netbase  5.4

dnsmasq recommends no packages.

Versions of packages dnsmasq suggests:
ii  openresolv [resolvconf]  3.8.0-1

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

-- no debconf information

Bug#886222: ld.gold: internal error in get_got_page_offset, at ../../gold/mips.cc:6271

[Gianfranco Costamagna]

On Fri, 5 Jan 2018 16:12:14 +0100 Gianfranco Costamagna 
 wrote:
> On Thu, 4 Jan 2018 14:30:08 + James Cowgill  wrote:
> > Hi,
> > 
> > On 04/01/18 14:26, Gianfranco Costamagna wrote:
> > > Hello,
> > > 
> > >> Is there a way for me to run your testcase without ghc-stage1 (which
> > >> would require building ghc)?
> > > 
> > > I don't know, however I attached ghc-stage1 binaries to the report
> > 
> > The "ghc-stage1" you attached is a shell script which execs some other
> > binary which you didn't attach.
> > 
> 
> this is true, I hope you can get from my home in eller.debian.org :)
> 

hello, ping?
(this is the last blocker for ghc 8.2 in unstable, unfortunately somebody would 
like to remove from mips instead of delaying the transition any longer)

G.



signature.asc
Description: OpenPGP digital signature

Bug#888610: gnome-shell: gdm greeter session sometimes exits 1: Can't initialize KMS backend: could not find drm kms device

[Manuel Bilderbeek]

Hi,

On 27-01-18 19:29, Simon McVittie wrote:

On Sat, 27 Jan 2018 at 16:02:19 +0100, Manuel Bilderbeek wrote:

I do still see the issue at startup (I guess when the greeter is started):
¯
jan 27 10:13:47 sonata gnome-shell[1297]: Can't initialize KMS backend: could 
not find drm kms device
jan 27 10:13:47 sonata gnome-session[1276]: gnome-session-binary[1276]: 
WARNING: App 'org.gnome.Shell.desktop' exited with code 1
jan 27 10:13:47 sonata gnome-session-binary[1276]: WARNING: App 
'org.gnome.Shell.desktop' exited with code 1
jan 27 10:13:47 sonata gnome-session-binary[1276]: Unrecoverable failure in 
required component org.gnome.Shell.desktop


Am I right in thinking that immediately after this, gdm restarts the
greeter, and on this second attempt (or on a third or fourth attempt)
it works OK?


I should take a better look, I'll let you know if it's different than this.


Does this have any practical effect on your use of gdm or GNOME, other
than delaying your first opportunity to log in?


So: no.

But the 'sometimes' isn't valid for me: this seems to happen all the 
time for me. (I.e.: it happened at every boot I checked the log for in 
the last couple of days.)


--
Kind regards,
Manuel

Bug#888528: libnot-yet-commons-ssl-java - missing on buster

[tony mancill]

On Fri, Jan 26, 2018 at 03:58:32PM -0300, Yadickson Soto wrote:
> Package: libnot-yet-commons-ssl-java
> Version: 0.3.17
> Branch: buster (testing)
> 
> Hi,
> 
> On debian buster is missing the libnot-yet-commons-ssl-java library.
> Please, is posible add the libnot-yet-commons-ssl-java to repository.

Hello,

This package was intentionally removed from Debian.  Please refer to
this bug report [0].  The Debian Package Tracker page [1] is a good
place to start when attempting to determine why a package is no longer
in the archive.

Cheers,
tony

[0] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=883092
[1] https://tracker.debian.org/pkg/not-yet-commons-ssl


signature.asc
Description: PGP signature

Bug#888611: [gajim] Fails to keep connection against prosody 0.9.12-2 (Debian Stretch)

[Charlemagne Lasse]

Package: gajim
Version: 1.0.0~alpha2-1
Severity: normal

The gajim version from Debian Stretch worked fine but now with gajim
1.0.0~alpha2-1 (0.98.2 according to the about page), the connection
drops all the time against a prosody 0.9.12-2 server (Debian Stretch).
I see following in the XML log:


























This makes it impossible to use gajim for me.


--- System information. ---
Architecture:
Kernel:   Linux 4.14.0-3-amd64

Debian Release: buster/sid
  500 testing-debug   debug.mirrors.debian.org
  500 testing httpredir.debian.org
1 testing www.deb-multimedia.org

--- Package information. ---
Depends  (Version) | Installed
==-+-==
python3-nbxmpp  (>= 0.6.0) | 0.6.2-1
python3-openssl  (>= 0.12) | 17.5.0-1
python3-pyasn1 | 0.4.2-3
python3:any  (>= 3.3.2-2~) |
gir1.2-gtk-3.0 | 3.22.26-2
python3| 3.6.4-1
python3-gi | 3.26.1-2
python3-gi-cairo   | 3.26.1-2
python3-idna   | 2.6-1


Recommends   (Version) | Installed
==-+-===
aspell-en  | 2017.08.24-0-0.1
 OR aspell-dictionary  |
ca-certificates| 20170717
dbus   | 1.12.2-1
fonts-noto-color-emoji | 0~20180102-1
gajim-omemo (>= 2.5.1) | 2.5.4-1
gajim-pgp  | 1.2.1-2
gir1.2-farstream-0.2   | 0.2.8-2
gir1.2-geoclue-2.0 | 2.4.7-1
gir1.2-gspell-1| 1.6.1-1
gir1.2-gst-plugins-base-1.0| 1.12.4-1
gir1.2-gstreamer-1.0   | 1.12.4-1
gir1.2-gupnpigd-1.0| 0.2.4-2
gir1.2-networkmanager-1.0  | 1.10.2-1
gir1.2-secret-1| 0.18.5-5
gstreamer0.10-plugins-ugly |
notification-daemon| 3.20.0-2
pulseaudio-utils   | 11.1-4
 OR alsa-utils | 1.1.3-1
 OR sox| 14.4.2-3
 OR oss4-base  |
python3-crypto | 2.6.1-8
python3-dbus (>= 0.81) | 1.2.4-1+b4
python3-gnupg   (>= 0.4.1) | 0.4.1-1
python3-pil| 4.3.0-2
python3-precis-i18n|


Suggests  (Version) | Installed
===-+-===
avahi-daemon| 0.7-3
libxss1 |
nautilus-sendto |
python3-avahi   |
python3-gconf   |
python3-gnome2  |
python3-kerberos   (>= 1.1) |
python3-pycurl  |

Bug#888485: fixed in gjs 1.50.3-2

[Simon McVittie]

On Fri, 26 Jan 2018 at 23:27:54 +, Simon McVittie wrote:
> #888485 is really two bugs:
> 
> * the Places extension continues to use objects after they've been
>   destroyed (this is the Places extension's fault);

I've opened #888608 to represent this part.

> * when that happens, gjs treats it as an uncatchable exception instead
>   of coping gracefully, for reasons I don't fully understand yet
>   (this is gjs' fault)

Let's continue to use #888485 to represent this part.

smcv

Bug#842716: powerline: VIM powerline plugin makes tmux powerline insert 'q' and newlines

[Gilles Mocellin]

Package: powerline
Version: 2.6-1
Followup-For: Bug #842716

Dear Maintainer,

I have something similar in my setup.
I found that tmux with the powerline conf starts to duplicate the status line 
and show insert 'q' where
my cursor is each time tmux status bar is refreshed when I open a file with vim 
with the powerline plugin.

I tried the following :
- deactivate the VIM plugin : No more problem with local user, but
  problem sill there when I use 'sudo vim'
- remove .tmux.conf pointing to
  /usr/share/vim/addons/plugin/powerline.vim : problem persist with the
  vim plugin

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

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

Versions of packages powerline depends on:
ii  python2.7.14-4
ii  python-powerline  2.6-1

Versions of packages powerline recommends:
ii  fonts-powerline2.6-1
ii  python3-powerline  2.6-1

Versions of packages powerline suggests:
pn  python-powerline-doc  
ii  vim-addon-manager 0.5.7

-- no debconf information

Bug#888610: gnome-shell: gdm greeter session sometimes exits 1: Can't initialize KMS backend: could not find drm kms device

[Simon McVittie]

Package: gnome-shell
Version: 3.26.2-3
Severity: normal
Tags: moreinfo
Control: submitter -1 manuel.bilderb...@gmail.com

(This is split out from the logs sent to gjs bug #888052, since it
appears to be an unrelated issue.)

On Sat, 27 Jan 2018 at 16:02:19 +0100, Manuel Bilderbeek wrote:
> I do still see the issue at startup (I guess when the greeter is started):
>¯
> jan 27 10:13:47 sonata gnome-shell[1297]: Can't initialize KMS backend: could 
> not find drm kms device
> jan 27 10:13:47 sonata gnome-session[1276]: gnome-session-binary[1276]: 
> WARNING: App 'org.gnome.Shell.desktop' exited with code 1
> jan 27 10:13:47 sonata gnome-session-binary[1276]: WARNING: App 
> 'org.gnome.Shell.desktop' exited with code 1
> jan 27 10:13:47 sonata gnome-session-binary[1276]: Unrecoverable failure in 
> required component org.gnome.Shell.desktop

Am I right in thinking that immediately after this, gdm restarts the
greeter, and on this second attempt (or on a third or fourth attempt)
it works OK?

Does this have any practical effect on your use of gdm or GNOME, other
than delaying your first opportunity to log in?

Thanks,
smcv

-- System Information:
See https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=888052#5

Bug#888070: [pkg-boost-devel] Bug#888070: boost CUDA compatibility

[Steve Robbins]

On Monday, January 22, 2018 9:51:23 PM CST Lumin wrote:

> It seems that updating boost to a newer version may solve this
> problem.

You can find sources to build a Boost 1.65.1 package here:
svn://anonscm.debian.org/pkg-boost/boost/

There is no binary package available for 1.65.1 and I have no estimate on when 
there might be one.

Best,
-Steve


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

Bug#733750: release?

[Simon McVittie]

On Sat, 27 Jan 2018 at 11:24:04 +0800, gustavo panizzo wrote:
> any idea when this will be released? I'd like add it to Recommends on
> uhexen2

It'll be included in game-data-packager version 58, probably later today.

smcv

Bug#888609: [smb4k] Retrieving the list of available domains failed

[Charlemagne Lasse]

Package: smb4k
Version: 2.0.2-1
Severity: normal

smb4k shows me following when it gets started under Debian buster:

Retrieving the list of available domains failed:
Usage: [-?fMRSTrAV] [-?|--help] [--usage] [-B|--broadcast=BROADCAST-ADDRESS]
[-f|--flags] [-U|--unicast=STRING] [-M|--master-browser]
[-R|--recursion] [-S|--status] [-T|--translate] [-r|--root-port]
[-A|--lookup-by-ip] [-d|--debuglevel=DEBUGLEVEL]
[-s|--configfile=CONFIGFILE] [-l|--log-basename=LOGFILEBASE]
[-V|--version] [--option=name=value]
[-O|--socket-options=SOCKETOPTIONS] [-n|--netbiosname=NETBIOSNAME]
[-W|--workgroup=WORKGROUP] [-i|--scope=SCOPE] ...


--- System information. ---
Architecture:
Kernel:   Linux 4.14.0-3-amd64

Debian Release: buster/sid
  500 testing-debug   debug.mirrors.debian.org
  500 testing httpredir.debian.org
1 testing www.deb-multimedia.org

--- Package information. ---
Depends  (Version) | Installed
==-+-==
cifs-utils  (>= 2:4.1) | 2:6.7-1
samba-common-bin (>= 2:3.4.7~dfsg) | 2:4.7.4+dfsg-1
smbclient(>= 2:3.4.7~dfsg) | 2:4.7.4+dfsg-1
kio| 5.37.0-2
libc6(>= 2.14) |
libkf5auth5(>= 4.96.0) |
libkf5completion5  (>= 4.97.0) |
libkf5configcore5  (>= 4.98.0) |
libkf5configgui5   (>= 4.97.0) |
libkf5configwidgets5   (>= 4.96.0) |
libkf5coreaddons5   (>= 5.2.0) |
libkf5dbusaddons5  (>= 4.97.0) |
libkf5i18n5(>= 4.97.0) |
libkf5iconthemes5  (>= 5.11.0) |
libkf5jobwidgets5  (>= 4.96.0) |
libkf5kiocore5 (>= 4.96.0) |
libkf5kiowidgets5(>= 5.5.0+git20141226.0011+15.04) |
libkf5notifications5   (>= 4.96.0) |
libkf5parts5   (>= 4.96.0) |
libkf5solid5   (>= 4.97.0) |
libkf5wallet-bin   |
libkf5wallet5  (>= 4.96.0) |
libkf5widgetsaddons5   (>= 4.96.0) |
libkf5windowsystem5(>= 4.96.0) |
libkf5xmlgui5  (>= 4.98.0) |
libqt5core5a   (>= 5.9.0~beta) |
libqt5gui5  (>= 5.7.0) |
libqt5network5  (>= 5.0.2) |
libqt5printsupport5 (>= 5.0.2) |
libqt5test5 (>= 5.0.2) |
libqt5widgets5  (>= 5.7.0) |
libstdc++6  (>= 4.1.1) |


Recommends  (Version) | Installed
=-+-===
sudo  | 1.8.21p2-3


Suggests(Version) | Installed
=-+-===
kwalletmanager| 4:17.08.3-1

Bug#883867: Anyone interested in packaging bookworm?

[Francesco Poli]

Hello Debian Vala package maintainers!

I filed an RFP bug report for boorworm, a small e-book reader (written
in Vala).
For further details, see bug #883867.

Is anyone interested in packaging it?
I would really appreciate it.

Thanks for considering.
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


pgpT7AF54v76N.pgp
Description: PGP signature

Bug#888608: gnome-shell-extensions: places menu accesses a destroyed Gio.DBusProxy

[Simon McVittie]

Package: gnome-shell-extensions
Version: 3.26.2-2
Severity: normal
Tags: patch fixed-upstream

After fixing the crash in #888485, gnome-shell with gjs >= 1.50.2-3 and
the Places Menu extension logs warnings like these:

> jan 27 10:14:06 sonata gnome-shell[1764]: Object Gio.DBusProxy 
> (0x55d13d734f50), has been already deallocated - impossible to access to it. 
> This might be caused by the fact that the object has been destroyed
> jan 27 10:14:06 sonata org.gnome.Shell.desktop[1764]: == Stack trace for 
> context 0x55d139f99170 ==
> jan 27 10:14:06 sonata org.gnome.Shell.desktop[1764]: #0 0x7ffc20b6fe90 b   
> resource:///org/gnome/gjs/modules/overrides/Gio.js:197 (0x7f75a4403d58 @ 26)
> jan 27 10:14:06 sonata org.gnome.Shell.desktop[1764]: == Stack trace for 
> context 0x55d139f99170 ==
> jan 27 10:14:06 sonata org.gnome.Shell.desktop[1764]: #0 0x55d13a4dbc50 i   
> /home/manuel/.local/share/gnome-shell/extensions/places-m...@gnome-shell-extensions.gcampax.github.com/placeDisplay.js:146
>  (0x7f758
> jan 27 10:14:06 sonata org.gnome.Shell.desktop[1764]: #1 0x7ffc20b6f6e0 I   
> self-hosted:917 (0x7f75a46ee5e8 @ 394)
> jan 27 10:14:06 sonata org.gnome.Shell.desktop[1764]: #2 0x7ffc20b6fe90 b   
> resource:///org/gnome/gjs/modules/overrides/Gio.js:203 (0x7f75a4403d58 @ 89)
> jan 27 10:14:06 sonata org.gnome.Shell.desktop[1764]: == Stack trace for 
> context 0x55d139f99170 ==
> jan 27 10:14:06 sonata org.gnome.Shell.desktop[1764]: #0 0x55d13a4dbcf8 i   
> /home/manuel/.local/share/gnome-shell/extensions/places-m...@gnome-shell-extensions.gcampax.github.com/placeDisplay.js:159
>  (0x7f758
> jan 27 10:14:06 sonata org.gnome.Shell.desktop[1764]: #1 0x7ffc20b6eae0 I   
> resource:///org/gnome/gjs/modules/_legacy.js:82 (0x7f75a46c2bc0 @ 71)
> jan 27 10:14:06 sonata org.gnome.Shell.desktop[1764]: #2 0x55d13a4dbc50 i   
> /home/manuel/.local/share/gnome-shell/extensions/places-m...@gnome-shell-extensions.gcampax.github.com/placeDisplay.js:148
>  (0x7f758
> jan 27 10:14:06 sonata org.gnome.Shell.desktop[1764]: #3 0x7ffc20b6f6e0 I   
> self-hosted:917 (0x7f75a46ee5e8 @ 394)
> jan 27 10:14:06 sonata org.gnome.Shell.desktop[1764]: #4 0x7ffc20b6fe90 b   
> resource:///org/gnome/gjs/modules/overrides/Gio.js:203 (0x7f75a4403d58 @ 89)
> jan 27 10:14:06 sonata org.gnome.Shell.desktop[1764]: == Stack trace for 
> context 0x55d139f99170 ==
> jan 27 10:14:06 sonata org.gnome.Shell.desktop[1764]: #0 0x7ffc20b6fe90 b   
> resource:///org/gnome/gjs/modules/overrides/Gio.js:197 (0x7f75a4403d58 @ 26)
> jan 27 10:14:06 sonata org.gnome.Shell.desktop[1764]: == Stack trace for 
> context 0x55d139f99170 ==
> jan 27 10:14:06 sonata org.gnome.Shell.desktop[1764]: #0 0x55d13a4dbc50 i   
> /home/manuel/.local/share/gnome-shell/extensions/places-m...@gnome-shell-extensions.gcampax.github.com/placeDisplay.js:146
>  (0x7f758
> jan 27 10:14:06 sonata org.gnome.Shell.desktop[1764]: #1 0x7ffc20b6f6e0 I   
> self-hosted:917 (0x7f75a46ee5e8 @ 394)
> jan 27 10:14:06 sonata org.gnome.Shell.desktop[1764]: #2 0x7ffc20b6fe90 b   
> resource:///org/gnome/gjs/modules/overrides/Gio.js:203 (0x7f75a4403d58 @ 89)

See also #888485, #888052.

I believe this is fixed by this upstream commit:
https://gitlab.gnome.org/GNOME/gnome-shell-extensions/commit/3284fe81d7cdb362fc7d8013bf7d958b253c4b44

I deliberately haven't fixed this yet, because it's the only way I know
of to reproduce the crash seen in #888485, which is a lot more serious
than some warnings; and I'd like to be able to be sure that we've really
fixed that crash before removing the only way I can reproduce it.

smcv

Bug#837796: paraview: segfaults when performing query-based selections

[Francesco Poli]

Control: found -1 paraview/5.4.1+dfsg3-1


On Wed, 14 Sep 2016 18:54:28 +0200 Francesco Poli (wintermute) wrote:

> Package: paraview
> Version: 5.1.2+dfsg1-1
> Severity: important
[...]
> 
> I noticed a segfault that can be obtained reproducibly.
[...]
> Please investigate and fix this bug and/or forward my bug report
> upstream.

Hello again,
I've just checked and the bug is still reproducible on current Debian
testing (paraview/5.4.1+dfsg3-1+b2).

Is there any progress?
Have you investigated?
Have you forwarded my bug report upstream?

Please let me know, thanks for your time.


-- 
 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


pgpe7Dzs8ysyq.pgp
Description: PGP signature

Bug#888484: [Pkg-clamav-devel] Bug#888484: Processed (with 1 error): Re: Bug#888484: clamav: Security release 0.99.3 available

[Sebastian Andrzej Siewior]

On 27 January 2018 15:30:45 CET, Salvatore Bonaccorso  wrote:
>So "the remaining CVEs were not address yet" part.
>
I was referring to the Stretch release. The fd bug is fixed but not the CVEs.
In the meantime I opened pu bugs for stable and oldstable.


Sebastian

Bug#888606: cysignals: FTBFS with debhelper/11.1 due to empty build target

[Niels Thykier]

Source: cysignals
Version: 1.6.5+ds-2
Severity: serious
Tags: patch

Hi,

The cysignals package FTBFS with debhelper/11.1 as it has an empty
build target.  This is caused by debhelper had a bug in its handling
of "explicitly defined rules targets" that has now been fixed.

Previously, this happened to work because dpkg-buildpackage would
invoke "debian/rules build" (which would be a no-op) followed by
"fakeroot debian/rules binary".  During the binary target, dh's
suboptimal handling would run the build commands.


The solution is trivial but less pretty; explicitly define "build"
with the same content as the "%:" target (or rename the "build" folder
and drop the ".PHONY" target).  I have attached a patch for this.


More details can be found in:
 * #886901 comment #35
 * #887688 comment #37
 * #880840

Apologies for the inconvenience.

Thanks,
~Niels
>From 3a57538b93ca415f235feb04b19395a576dfc60f Mon Sep 17 00:00:00 2001
From: Niels Thykier 
Date: Sat, 27 Jan 2018 17:43:04 +
Subject: [PATCH] Avoid empty build target

The dh sequencer as of debhelper/11.1 is stricter with this in order
to solve #880840 (where debhelper would fail to handle such targets
correctly).

Signed-off-by: Niels Thykier 
---
 debian/rules | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/debian/rules b/debian/rules
index 4872a50..bfd28fb 100755
--- a/debian/rules
+++ b/debian/rules
@@ -18,6 +18,12 @@ default:
 %:
dh $@ --with autoreconf --with python2  --with sphinxdoc 
--buildsystem=pybuild
 
+# The build target must not be empty.  Sadly because of how make
+# works, we have do duplicate the target in this case.
+build:
+   dh $@ --with autoreconf --with python2  --with sphinxdoc 
--buildsystem=pybuild
+
+
 override_dh_auto_configure-arch:
$(call adhoc_dh_auto_configure_do,bare)
$(call adhoc_dh_auto_configure_do,pari)
-- 
2.15.1

Bug#888607: paraview: complaints about deprecated functions in VTK 7.0

[Francesco Poli (wintermute)]

Package: paraview
Version: 5.4.1+dfsg3-1+b2
Severity: important

Hello!
Thanks for maintaining ParaView in Debian.

For some time lately, I have been experienced an annoying issue:
each time I load some data (it seems that this happens with different
data file formats, if not with all of them), a dialog window appears
telling me that

  + !  vtkVolumeTextMapper3D was deprecated for VTK 7.0 and
   will be removed in a future version
  + !  vtkOpenGLVolumeTextureMapper3D was deprecated for VTK 7.0 and
   will be removed in a future version

If I click on "Show full messages", I read:

  Generic Warning: In 
/build/paraview-8H5PCo/paraview-5.4.1+dfsg3/VTK/Rendering/Volume/vtkVolumeTextureMapper3D.cxx,
 line 680
  vtkVolumeTextureMapper3D::vtkVolumeTextureMapper3D was deprecated for VTK 7.0 
and will be removed in a future version.

  Generic Warning: In 
/build/paraview-8H5PCo/paraview-5.4.1+dfsg3/VTK/Rendering/VolumeOpenGL/vtkOpenGLVolumeTextureMapper3D.cxx,
 line 57
  vtkOpenGLVolumeTextureMapper3D::vtkOpenGLVolumeTextureMapper3D was deprecated 
for VTK 7.0 and will be removed in a future version.


Since the warning messages appear to come from the VTK library copy
included in the paraview package itself, I assume that this misbehavior
began with one of the latest paraview package upgrades.
And that it depends on some inconsistency between ParaView and its
own VTK library copy.

Having to take a look at the dialog (in order to check that it only
contains the above quoted warnings and nothing worse) and to close it,
*each* time I read new data, is quite annoying.

Please fix this misbehavior and/or forward the bug report upstream.

Thanks for your time.
Bye!


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

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

Versions of packages paraview depends on:
ii  libavcodec57   7:3.4.1-1+b2
ii  libavformat57  7:3.4.1-1+b2
ii  libavutil557:3.4.1-1+b2
ii  libc6  2.26-4
ii  libcgns3.3 3.3.0-4+b1
ii  libexpat1  2.2.5-3
ii  libfreetype6   2.8.1-1
ii  libgcc11:7.2.0-19
ii  libgl1 1.0.0-1.1
ii  libgl2ps1.41.4.0+dfsg1-1
ii  libhdf5-1001.10.0-patch1+docs-4
ii  libjpeg62-turbo1:1.5.2-2+b1
ii  libjsoncpp11.7.4-3
ii  libnetcdf131:4.5.0-2
ii  libogg01.3.2-1+b1
ii  libopenmpi22.1.1-7
ii  libpng16-161.6.34-1
ii  libprotobuf10  3.0.0-9.1
ii  libpython2.7   2.7.14-4
ii  libqt4-help4:4.8.7+dfsg-11
ii  libqt4-network 4:4.8.7+dfsg-11
ii  libqtcore4 4:4.8.7+dfsg-11
ii  libqtgui4  4:4.8.7+dfsg-11
ii  libstdc++6 7.2.0-19
ii  libswscale47:3.4.1-1+b2
ii  libtheora0 1.1.1+dfsg.1-14+b1
ii  libtiff5   4.0.9-3
ii  libx11-6   2:1.6.4-3
ii  libxml22.9.4+dfsg1-6.1
ii  libxt6 1:1.1.5-1
ii  python-autobahn17.7.1+dfsg1-3
ii  python-matplotlib  2.0.0+dfsg1-2+b1
ii  python-mpi4py  2.0.0-3
ii  python-six 1.11.0-1
ii  python-twisted 17.9.0-1
ii  tcl [tclsh]8.6.0+9
ii  zlib1g 1:1.2.8.dfsg-5

Versions of packages paraview recommends:
ii  mpi-default-bin  1.9
ii  paraview-doc 5.4.1+dfsg3-1
ii  paraview-python  5.4.1+dfsg3-1+b2

Versions of packages paraview suggests:
pn  h5utils 
pn  hdf5-tools  

-- no debconf information

Bug#888007: password-gorilla uses deprecated Tcl/Tk 8.5

[Alexandre Raymond]

Hi,

I am in the process of releasing a new package for password-gorilla, which
will include those fixes.

Thanks for the reminder.

Alexandre

On Mon, Jan 22, 2018 at 10:53 AM, Sergei Golovan  wrote:

> Source: password-gorilla
> Version: 1.5.3.7-1
> Severity: important
> Tags: patch
>
> Dear Maintainer,
>
> Tcl/Tk 8.5 has reached its end-of-life, so it'll be removed from Debian
> soon.
> So please, switch to more recent version in the password-gorilla package.
>
> I've attached a diff for a NMU which switches to tk from tk8.5 in the
> package
> dependencies, and if you don't mind, I could do this upload myself. As far
> as
> I can see, the program runs fine after rebuilding.
>
> -- System Information:
> Debian Release: 9.3
>   APT prefers stable-debug
>   APT policy: (500, 'stable-debug'), (500, 'proposed-updates'), (500,
> 'stable'), (1, 'unstable'), (1, 'testing')
> Architecture: amd64 (x86_64)
> Foreign Architectures: i386
>
> Kernel: Linux 4.14.0-0.bpo.3-amd64 (SMP w/12 CPU cores)
> Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8),
> LANGUAGE=en_US:en (charmap=UTF-8)
> Shell: /bin/sh linked to /bin/dash
> Init: systemd (via /run/systemd/system)
>
> -- no debconf information
>

Bug#887862: closed by Ondřej Nový (Bug#887862: fixed in git-review 1.26.0-1)

[Jaap Keuter]

On 21-01-18 14:39, Debian Bug Tracking System wrote:
> This is an automatic notification regarding your Bug report
> which was filed against the git-review package:
> 
> #887862: git-review: Download of change branch fails

Thanks Ondřej! This fixes both problems.

Bug#887835: qt5ct just *doesn't* work - The QT_QPA_PLATFORMTHEME environment variable is not set correctly

[Mateusz Łukasik]

On Sat, 20 Jan 2018 21:52:55 +0900 Norbert Preining 
 wrote:

> Package: qt5ct
> Version: 0.34-1
> Severity: grave
> Justification: renders package unusable
>
> Dear all,
>
> although the man page of qt5ct proudly states:
> qt5ct hasn't options. It just works.
> reality is that it simply doesn't start, but shows a warning dialog with
> The QT_QPA_PLATFORMTHEME environment variable is not set correctly
> and that's it.
>
> Best
>
> Norbert
>
>
> -- System Information:
> Debian Release: buster/sid
> APT prefers unstable-debug
> APT policy: (500, 'unstable-debug'), (500, 'unstable'), (1, 
'experimental')

> Architecture: amd64 (x86_64)
> Foreign Architectures: i386
>
> Kernel: Linux 4.14.14 (SMP w/8 CPU cores)
> Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US:en (charmap=UTF-8)

> Shell: /bin/sh linked to /bin/dash
> Init: systemd (via /run/systemd/system)
>
> Versions of packages qt5ct depends on:
> ii libc6 2.26-4
> ii libgcc1 1:7.2.0-19
> ii libgl1 1.0.0-1.1
> ii libqt5core5a [qtbase-abi-5-9-2] 5.9.2+dfsg-7
> ii libqt5dbus5 5.9.2+dfsg-7
> ii libqt5gui5 5.9.2+dfsg-7
> ii libqt5widgets5 5.9.2+dfsg-7
> ii libstdc++6 7.2.0-19
>
> qt5ct recommends no packages.
>
> Versions of packages qt5ct suggests:
> pn qt5-style-plugins 
>
> -- no debconf information
>
>

control: + moreinfo
control: severity ! |normal


Which one vm or dm do you have? This bug look like for me on ignored 
environment variables.

I need more information for reproduced this.
|

--
 .''`.  Mateusz Łukasik
: :' :  https://l0calh0st.pl
`. `'   Debian Member - mat...@linuxmint.pl
  `-GPG: D93B 0C12 C8D0 4D7A AFBC  FA27 CCD9 1D61 11A0 6851

Bug#888605: [gajim] Regression: kwallet integration missing

[Charlemagne Lasse]

Package: gajim
Version: 1.0.0~alpha2-1
Severity: important

The kwallet integration was done in the gajim stretch version using
kwalletcli. But upstream removed it in 13a61d76187c ("Remove support for GNOME
Keyring and KWalletCLI, instead always use libsecret.") without a replacement
for KDE. The kwallet can  currently no longer be used with this gajim version.
This is a regression compared to the older version.

Either kwalletcli is added again to gajim or org.freedesktop.secrets dbus
support must be added to kwalletd5


--- System information. ---
Architecture:
Kernel:   Linux 4.14.0-3-amd64

Debian Release: buster/sid
  500 testing-debug   debug.mirrors.debian.org
  500 testing httpredir.debian.org
1 testing www.deb-multimedia.org

--- Package information. ---
Depends  (Version) | Installed
==-+-==
python3-nbxmpp  (>= 0.6.0) | 0.6.2-1
python3-openssl  (>= 0.12) | 17.5.0-1
python3-pyasn1 | 0.4.2-3
python3:any  (>= 3.3.2-2~) |
gir1.2-gtk-3.0 | 3.22.26-2
python3| 3.6.4-1
python3-gi | 3.26.1-2
python3-gi-cairo   | 3.26.1-2
python3-idna   | 2.6-1


Recommends   (Version) | Installed
==-+-===
aspell-en  | 2017.08.24-0-0.1
 OR aspell-dictionary  |
ca-certificates| 20170717
dbus   | 1.12.2-1
fonts-noto-color-emoji | 0~20180102-1
gajim-omemo (>= 2.5.1) | 2.5.4-1
gajim-pgp  | 1.2.1-2
gir1.2-farstream-0.2   | 0.2.8-2
gir1.2-geoclue-2.0 | 2.4.7-1
gir1.2-gspell-1| 1.6.1-1
gir1.2-gst-plugins-base-1.0| 1.12.4-1
gir1.2-gstreamer-1.0   | 1.12.4-1
gir1.2-gupnpigd-1.0| 0.2.4-2
gir1.2-networkmanager-1.0  | 1.10.2-1
gir1.2-secret-1| 0.18.5-5
gstreamer0.10-plugins-ugly |
notification-daemon| 3.20.0-2
pulseaudio-utils   | 11.1-4
 OR alsa-utils | 1.1.3-1
 OR sox| 14.4.2-3
 OR oss4-base  |
python3-crypto | 2.6.1-8
python3-dbus (>= 0.81) | 1.2.4-1+b4
python3-gnupg   (>= 0.4.1) | 0.4.1-1
python3-pil| 4.3.0-2
python3-precis-i18n|


Suggests  (Version) | Installed
===-+-===
avahi-daemon| 0.7-3
libxss1 |
nautilus-sendto |
python3-avahi   |
python3-gconf   |
python3-gnome2  |
python3-kerberos   (>= 1.1) |
python3-pycurl  |

Bug#888604: util-linux mount/unmount ASLR bypass via environment variable

[halfdog]

Package: mount
Version: 2.29.2-1
Severity: normal
Tags: security

Debugging of libmount can be activated, also in SUID
binaries, thus spilling out the heap addresses. Note that "CXT"
structure contains function pointers to overwrite.

Test:

LIBMOUNT_DEBUG=all /bin/umount /

Output:

2401: libmount:  CXT: [0x562d3abb0760]: > allocate [RESTRICTED]
2401: libmount:  CXT: [0x562d3abb0760]: umount: /
2401: libmount:  CXT: [0x562d3abb0760]: umount: lookup FS for '/'
2401: libmount:  CXT: [0x562d3abb0760]: checking for writable tab files
2401: libmount:UTILS: utab: /run/mount/utab
2401: libmount:CACHE: [0x562d3abb1950]: alloc
2401: libmount:CACHE: [0x562d3abb1950]: canonicalize path /
2401: libmount:CACHE: [0x562d3abb1950]: add entry [ 1] (path): /: /
2401: libmount:  CXT: [0x562d3abb0760]: tabfilter ENABLED!
2401: libmount:  TAB: [0x562d3abb35b0]: alloc
...

The output can easily be used by creating a local domain socket
with only 4k buffer size, filling it up until writes are blocking
and then start umount with that socket as stdout. This allows
race-free reading of the address output before umount accesses
other user-controlled resource. Thus any error during the downstream
procedure creating some kind of write-where vulnerability will
always find the correct target.

See also:

* https://www.spinics.net/lists/util-linux-ng/msg14978.html
* https://bugzilla.redhat.com/show_bug.cgi?id=1534076

Bug#844125: dgit: Built-in support for pbuilder

[Sean Whitton]

Hello,

On Sat, Jan 27, 2018 at 09:27:58AM -0700, Sean Whitton wrote:
> 3. dgit invokes `pbuilder build foo_1.2.3-1.dsc `

On IRC, Mattia reports that this should be

pbuilder build  foo_1.2.3-1.dsc

> 4. dgit invokes mergechanges to merge its _source.changes and the
> binary .changes produced by pbuilder.
> 
> This is exactly the pattern of `dgit sbuild`, so we can probably
> refactor the cmd_sbuild() sub and then trivially add cmd_pbuilder().

On IRC, Mattia reports a slight wrinkle here: the .changes produced by
pbuilder will include a rebuilt .dsc.  So we need to pass
`--debbuildopts -b` to pbuilder.

Note that the changes will include arch-indep and arch binaries by
default.  This differs from sbuild, which requires you to pass -A to get
arch-indep binaries.  I think it is fine for `dgit pbuilder` to include
arch-indep binaries, because that is the pbuilder default.

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#887915: gir1.2-matepanelapplet-4.0: fails to upgrade from 'testing' - trying to overwrite /usr/lib/x86_64-linux-gnu/girepository-1.0/MatePanelApplet-4.0.typelib

[Mike Gabriel]

Control: close -1
Control: fixed -1 1.18.7-4

Hi,

On  So 21 Jan 2018 17:54:46 CET, Andreas Beckmann wrote:


Package: gir1.2-matepanelapplet-4.0
Version: 1.18.7-3
Severity: serious
User: debian...@lists.debian.org
Usertags: piuparts

Hi,

during a test with piuparts I noticed your package fails to upgrade from
'testing'.
It installed fine in 'testing', then the upgrade to 'sid' fails
because it tries to overwrite other packages files without declaring a
Breaks+Replaces relation.

See policy 7.6 at
https://www.debian.org/doc/debian-policy/#overwriting-files-and-replacing-packages-replaces

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

  Selecting previously unselected package gir1.2-matepanelapplet-4.0:amd64.
  Preparing to unpack  
.../11-gir1.2-matepanelapplet-4.0_1.18.7-3_amd64.deb ...

  Unpacking gir1.2-matepanelapplet-4.0:amd64 (1.18.7-3) ...
  dpkg: error processing archive  
/tmp/apt-dpkg-install-NbeHlL/11-gir1.2-matepanelapplet-4.0_1.18.7-3_amd64.deb  
(--unpack):
   trying to overwrite  
'/usr/lib/x86_64-linux-gnu/girepository-1.0/MatePanelApplet-4.0.typelib',  
which is also in package gir1.2-mate-panel 1.18.7-1



cheers,

Andreas


This issue should have been resolved by
https://anonscm.debian.org/git/pkg-mate/mate-panel.git/commit/?id=bec3abd78e19ca092154c41ced37cb678fb0acd2

... shipped with 1.18.7-4.

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



pgpYeGyoAayOF.pgp
Description: Digitale PGP-Signatur

Bug#887723: mate-screensaver: the screen stays darken and desktop not available anymore

[Mike Gabriel]

Control: severity -1 important

Hi,

On  Fr 19 Jan 2018 13:57:31 CET, Mike Gabriel wrote:


Hi!

On  Fr 19 Jan 2018 12:20:11 CET, Joël Krähemann wrote:


Package: mate-screensaver
Version: 1.18.2-1
Severity: serious
Justification: the desktop must be available

Dear Maintainer,

I have installed mate-desktop and its screensaver. The screen
stays darken after a while it was darken. Hitting my Logitech
USB wireless keyboard doesn't show up login screen.

Only way out is to restart lightdm:

`systemctl restart lightdm`

This possibily leads to data loss.

Best regards,
Joël



Can you try other input devices for un-blackening the screensaver?  
Mouse movement, other USB ticket, etc.?


Work-around for unlockable screensaver. CTRL+ALT+F2 (console tty),  
log in as same user and then killall mate-screenaver.


Mike


No feedback received so far, nor having seen this on other systems  
(except on rare occasions). This is definitely a sometime occurring  
bug, but this does not justify to have this bug with serious severity.


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



pgp9dU3WIOnXP.pgp
Description: Digitale PGP-Signatur