Bug#823514: extra newline added to /etc/apt/listchanges.conf

[Manoj Srivastava]

On Fri, May 06 2016, Robert Luberda wrote:

> This is a side effect of using python's configparser module to write the
> new version of configuration file (Another drawback is that it loses
> comments. But in my opinion it is still better than previously, when
> `dpkg-reconfigure apt-listchanges' forced the prompt if the
> configuration file contained any setting not managed by debconf).

> I can skip calling ucf when the files differ by whitespaces only (i.e.
> when `diff -wB' returns no output).

> Maybe a better way of fixing this would be to add some option to ucf
> that would cause it to ignore differences in whitespaces while deciding
> if files are different; Manoj, what do you think?

Hmm. I can certainly support something along the lines of an
 environment variable or command line option setting
 extra-diff-arguments, which can be then set (or unset) by the
 maintainer script.  I am not sure that white space differences are
 irrelevant for all configuration files, so changing current behaviour
 would have to be done carefully, but opt-in is certainly feasible.

Please do file a wishlist bug to track this feature.

manoj
-- 
It occurred to me lately that nothing has occurred to me lately.
Manoj Srivastava    
4096R/C5779A1C E37E 5EC5 2A01 DA25 AD20  05B6 CF48 9438 C577 9A1C


smime.p7s
Description: S/MIME cryptographic signature

Bug#826701: gnuplot-data: Version 5.0.3+dfsg3-1 tries to overwrite a file which is also in package gnuplot-tex 4.6.6-3

[Wolfgang Karall-Ahlborn]

Package: gnuplot-data
Version: 4.6.6-3
Severity: grave
Justification: renders package unusable

Dear Maintainer,

Can't upgrade 4.6.6-3 -> 5.0.3+dfsg3-1:

Preparing to unpack .../gnuplot-data_5.0.3+dfsg3-1_all.deb ...
Unpacking gnuplot-data (5.0.3+dfsg3-1) over (4.6.6-3) ...
dpkg: error processing archive 
/var/cache/apt/archives/gnuplot-data_5.0.3+dfsg3-1_all.deb (--unpack):
 trying to overwrite 
'/usr/share/texmf/tex/latex/gnuplot/gnuplot-lua-tikz-common.tex', which is also 
in package gnuplot-tex 4.6.6-3

Cheers
Wolfgang

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

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

Versions of packages gnuplot-data depends on:
ii  aglfn1.7-3
pn  gnuplot-tex  

gnuplot-data recommends no packages.

gnuplot-data suggests no packages.

-- no debconf information

Bug#825658: [Pkg-xfce-devel] Bug#825658: Bug#825658: release.debian.org: XFWM4 Compositor Issue - Patches released for LightDM-GTK-Greeter and XFWM4

[Jeff Mills]

Hi Yves,


https://bugs.launchpad.net/xfwm4/+bug/1232804


-Original Message- 
From: Yves-Alexis Perez

Sent: Tuesday, June 7, 2016 5:28 AM
To: Jeff Mills ; 825...@bugs.debian.org
Subject: Re: [Pkg-xfce-devel] Bug#825658: Bug#825658: release.debian.org: 
XFWM4 Compositor Issue - Patches released for LightDM-GTK-Greeter and XFWM4


<1464447190.5301.46.ca...@adam-barratt.org.uk>

<1464454195.27507.4.ca...@debian.org>
<1465113613.27175.8.ca...@quartzdev.net>
Content-Type: multipart/signed; micalg="pgp-sha256";
protocol="application/pgp-signature"; boundary="=-r+ZptO5PzfEf5ZPUzt1Z"
X-Mailer: Evolution 3.20.2-2
Mime-Version: 1.0
X-SmarterMail-Spam: ISpamAssassin 4 [raw: 3], SpamAssassin -1 [raw: 0], 
SPF_None, DK_None, DKIM_None, Custom Rules [], RHSBL

X-SmarterMail-TotalSpamWeight: 6

<1464447190.5301.46.ca...@adam-barratt.org.uk>

<1464454195.27507.4.ca...@debian.org>
<1465113613.27175.8.ca...@quartzdev.net>
Content-Type: multipart/signed; micalg="pgp-sha256";
protocol="application/pgp-signature"; boundary="=-r+ZptO5PzfEf5ZPUzt1Z"
X-Mailer: Evolution 3.20.2-2
Mime-Version: 1.0


--=-r+ZptO5PzfEf5ZPUzt1Z
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On dim., 2016-06-05 at 18:00 +1000, Jeff Mills wrote:

Not sure you got my last reply. =C2=A0By upstream do you mean patched
released packages?


At least committed in upstream repository.


If so I am aware that the package has been updated in=C2=A0Xubuntu 16.04,
this is a link to the related issue on Xfce4 Forum:
https://forum.xfce.org/viewtopic.php?id=3D10859
Patch log for Xfwm4 in the change logs here:
Xfwm4
http://changelogs.ubuntu.com/changelogs/pool/universe/x/xfwm4/xfwm4_4.12
.3-1ubuntu2/changelog
I could not find a patch entry for the LightDM-gtk-greeter package.
Hoping this is what you need.


Unfortunately those links are not exploitable. It's random mess of people
saying =E2=80=9Cme too=E2=80=9D here and there, which I don't have time to =
review.

If you want something to be fixed, please provide a simple, unique link, fo=
r
each issue, pointing to a tested patch, preferably vetted by upstream.

Regards,
--=20
Yves-Alexis
--=-r+ZptO5PzfEf5ZPUzt1Z
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: This is a digitally signed message part

-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQEcBAABCAAGBQJXVc7RAAoJEG3bU/KmdcClpREH/0OzpZj+NINqX4Ah3qSHIBLS
BK2qT48dZ97wMFi0uTIdXcpYOn5v3niKR8RSj8BcnoOJCElD/24QNsAoT7zsXstt
csXcp6wpO6PtLLoSCw5e2h3COlUEHzuGsszh+x0/1iTaGT95ok+ubyqcQC2iuYyQ
DgmZHas+XQf/15H/7vmaQ9kgbad21wazp+SVxzs6ZD3ERdFsWc+t5z7789qlcKjV
zCCY485e3yYjplGhINPx8+FwoYL7l09fYZyP+RCVSfGIzXyZwLSCNwnNrJRbyQjy
JOTnifPG7cPSRQ3asPTl8MxQVQMgT726skKR6nNJ4M5aOGmTzJQaRmMktSQuYy8=
=gVJl
-END PGP SIGNATURE-

--=-r+ZptO5PzfEf5ZPUzt1Z-- 

Bug#826700: strip-nondeterminism: missing Multi-Arch: foreign, breaks cross building of gdbm

[Helmut Grohne]

Package: strip-nondeterminism
Version: 0.018-1
Severity: normal
Tags: patch
User: helm...@debian.org
Usertags: rebootstrap

Hi reproducible folks,

gdbm started Build-Depending on strip-nondeterminism. Since that package
is Arch:all + Multi-Arch:no (implicitly), the Build-Depends is never
satisfiable in a cross compilation setting.

There are two ways to fix this:
1) Mark strip-nondeterminism Multi-Arch: foreign.
2) Remove Build-Depends: strip-nondeterminism from gdbm.

There are strong clues that the first option is correct:
 * strip-nondeterminism essentially does the same as
   dh-strip-nondeterminism and the latter is a dependency of debhelper,
   which is Multi-Arch foreign. So from the perspective of most packages
   the functionality of strip-nondeterminism is implicitly treated as if
   it were Multi-Arch: foreign already.
 * strip-nondeterminism is architecture-independent and uses only
   architecture-independent perl modules. It does not have maintainer
   scripts either (which would have been a common source for being not
   Multi-Arch: foreign).

I therefore attach a patch to add that marking. If you disagree, please
reassign this bug to src:gdbm to have that Build-Depends removed.

Helmut
diff --minimal -Nru strip-nondeterminism-0.018/debian/changelog 
strip-nondeterminism-0.018/debian/changelog
--- strip-nondeterminism-0.018/debian/changelog 2016-05-30 21:07:34.0 
+0200
+++ strip-nondeterminism-0.018/debian/changelog 2016-06-08 05:55:14.0 
+0200
@@ -1,3 +1,11 @@
+strip-nondeterminism (0.018-1.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Mark dh-strip-nondeterminism and strip-nondeterminism Multi-Arch: foreign
+(Closes: #-1)
+
+ -- Helmut Grohne   Wed, 08 Jun 2016 05:54:22 +0200
+
 strip-nondeterminism (0.018-1) unstable; urgency=medium
 
   * New upstream release:
diff --minimal -Nru strip-nondeterminism-0.018/debian/control 
strip-nondeterminism-0.018/debian/control
--- strip-nondeterminism-0.018/debian/control   2016-05-30 21:07:03.0 
+0200
+++ strip-nondeterminism-0.018/debian/control   2016-06-08 05:53:02.0 
+0200
@@ -40,6 +40,7 @@
  libfile-stripnondeterminism-perl (= ${binary:Version}),
  ${misc:Depends},
  ${perl:Depends},
+Multi-Arch: foreign
 Description: file non-deterministic information stripper — stand-alone tool
  StripNondeterminism is a library for stripping non-deterministic
  information, such as timestamps and file system order, from files. It
@@ -59,6 +60,7 @@
  libtimedate-perl,
  ${misc:Depends},
  ${perl:Depends},
+Multi-Arch: foreign
 Description: file non-deterministic information stripper — Debhelper add-on
  StripNondeterminism is a library for stripping non-deterministic
  information, such as timestamps and file system order, from files. It

Bug#824086: Info received (Bug#824086: libqwt-qt5-dev: qt creator doesn't load qwt plugin)

[Kevin Seidel]

It seems to be working now.  I think there was an update, but when I checked 
aptitude it reports the same version.  I'm not sure what changed, but it is not 
a problem now.

Bug#826699: ITP: facebook-insights -- CLI to interact with Insights metrics in the Facebook Graph API

[陳昌倬]

Package: wnpp
Severity: wishlist
Owner: "ChangZhuo Chen (陳昌倬)" 

* Package name: facebook-insights
  Version : 0.3.4
  Upstream Author : Stijn Debrouwere
* URL : http://www.github.com/debrouwere/facebook-insights
* License : ISC
  Programming Lang: Python
  Description : CLI to interact with Insights metrics in the Facebook Graph 
API

 facebook-insights is a command-line utility that makes it easier to interact
 with Insights metrics in the Facebook Graph API. Python users can also
 directly access the API wrapper that the CLI is built on.
 .
  * Authentication. OAuth2 is a bit of a pain and we've made it easier.
  * Querying. Query page and post insights with simple command-line parameters
or through a pythonic interface.
  * Reporting. Outputs simple timeseries of the data rather than verbose API
responses.
  * Portability. JSON output means you can analyze the data in any language
from R to Julia to Ruby to Java.

-- 
ChangZhuo Chen (陳昌倬) 
Debian Developer (https://nm.debian.org/public/person/czchen)
Key fingerprint = EC9F 905D 866D BE46 A896  C827 BE0C 9242 03F4 552D
  BA04 346D C2E1 FE63 C790  8793 CC65 B0CD EC27 5D5B


signature.asc
Description: PGP signature

Bug#826697: fcitx-skk: diff for NMU version 0.1.2-0.1

[dai]

Package: fcitx-skk
Version: 0.1.1-1.1
Severity: normal
Tags: patch pending

Dear maintainer,

I've prepared an NMU for fcitx-skk (versioned as 0.1.2-0.1) and
uploaded it to DELAYED/7. Please feel free to tell me if I
should delay it longer.
-- 
Regards,
dai

GPG Fingerprint = 0B29 D88E 42E6 B765 B8D8 EA50 7839 619D D439 668E
diff -Nru fcitx-skk-0.1.1/README.md fcitx-skk-0.1.2/README.md
--- fcitx-skk-0.1.1/README.md	2014-02-04 22:17:26.0 +0900
+++ fcitx-skk-0.1.2/README.md	2014-12-13 16:39:45.0 +0900
@@ -2,15 +2,37 @@
 
 fcitx-skk is an input method engine for Fcitx, which uses libskk as its backend.
 
-Requirements:
+## Requirements:
+
  - libskk
  - Qt4 (optional), for rule and dictionary configuration UI.
  - fcitx 4.2.8
  - skk-jisyo
 
-Build dependency:
+### For Ubuntu User
+
+Please install this packages before build this Program.
+
+ - libskk-dev
+ - libqt4-dev
+ - fcitx-libs-dev
+ - skkdic
+
+$ sudo aptitude install libskk-dev libqt4-dev fcitx-libs-dev skkdic
+
+
+## Build dependency:
+
  - cmake
+ - C++ Compiler(g++)
 
 You can specify the skk dictionary path by -DSKK_DEFAULT_PATH=path_you_want
 
 By default it's /usr/share/skk/SKK-JISYO.L
+
+## Installation 
+
+git clone https://github.com/fcitx/fcitx-skk.git
+cd fcitx-skk
+cmake .
+sudo make install
diff -Nru fcitx-skk-0.1.1/debian/changelog fcitx-skk-0.1.2/debian/changelog
--- fcitx-skk-0.1.1/debian/changelog	2016-06-08 10:14:41.0 +0900
+++ fcitx-skk-0.1.2/debian/changelog	2016-06-08 11:39:15.0 +0900
@@ -1,3 +1,18 @@
+fcitx-skk (0.1.2-0.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * New upstream release.
+  * debian/rules: enable hardening.
+  * debian/fcitx-skk.lintian-overrides
+- new file.
+- it is caused by /usr/include/fcitx-config/fcitx-config.h (fcitx-libs-dev)
+  see https://bugs.debian.org/826696
+  * debian/control
+- add Vcs-Git and Vcs-Browser.
+- bump up Standards-Version 3.9.8.
+
+ -- HIGUCHI Daisuke (VDR dai)   Wed, 08 Jun 2016 11:39:08 +0900
+
 fcitx-skk (0.1.1-1.1) unstable; urgency=medium
 
   * Non-maintainer upload.
diff -Nru fcitx-skk-0.1.1/debian/control fcitx-skk-0.1.2/debian/control
--- fcitx-skk-0.1.1/debian/control	2016-06-08 10:06:08.0 +0900
+++ fcitx-skk-0.1.2/debian/control	2016-06-08 11:36:08.0 +0900
@@ -3,10 +3,10 @@
 Priority: optional
 Maintainer: Yusuke YATSUO 
 Build-Depends: debhelper (>= 9), cmake, fcitx-libs-dev (>= 1:4.2.8), fcitx-bin (>= 1:4.2.6), libskk-dev, libqt4-dev
-Standards-Version: 3.9.5
+Standards-Version: 3.9.8
 Homepage: https://github.com/fcitx/fcitx-skk
-#Vcs-Git: git://git.debian.org/collab-maint/fcitx-skk.git
-#Vcs-Browser: http://git.debian.org/?p=collab-maint/fcitx-skk.git;a=summary
+Vcs-Git: https://anonscm.debian.org/gitweb/?p=collab-maint/fcitx-skk.git
+Vcs-Browser: https://anonscm.debian.org/gitweb/?p=collab-maint/fcitx-skk.git
 
 Package: fcitx-skk
 Architecture: any
diff -Nru fcitx-skk-0.1.1/debian/fcitx-skk.lintian-overrides fcitx-skk-0.1.2/debian/fcitx-skk.lintian-overrides
--- fcitx-skk-0.1.1/debian/fcitx-skk.lintian-overrides	1970-01-01 09:00:00.0 +0900
+++ fcitx-skk-0.1.2/debian/fcitx-skk.lintian-overrides	2016-06-08 10:40:12.0 +0900
@@ -0,0 +1 @@
+fcitx-skk: spelling-error-in-binary usr/lib/*/fcitx/fcitx-skk.so Erorr Error
diff -Nru fcitx-skk-0.1.1/debian/rules fcitx-skk-0.1.2/debian/rules
--- fcitx-skk-0.1.1/debian/rules	2016-06-08 10:06:05.0 +0900
+++ fcitx-skk-0.1.2/debian/rules	2016-06-08 10:22:24.0 +0900
@@ -4,6 +4,10 @@
 # Uncomment this to turn on verbose mode.
 #export DH_VERBOSE=1
 
+export DEB_BUILD_MAINT_OPTIONS = hardening=+all
+DPKG_EXPORT_BUILDFLAGS = 1
+include /usr/share/dpkg/buildflags.mk
+
 %:
 	dh $@ 
 
diff -Nru fcitx-skk-0.1.1/po/de.po fcitx-skk-0.1.2/po/de.po
--- fcitx-skk-0.1.1/po/de.po	2014-02-04 22:17:26.0 +0900
+++ fcitx-skk-0.1.2/po/de.po	2014-12-13 16:39:45.0 +0900
@@ -3,14 +3,15 @@
 # This file is distributed under the same license as the PACKAGE package.
 #
 # Translators:
-# mar well , 2013
+# mar well , 2013
+# mar well , 2014
 msgid ""
 msgstr ""
 "Project-Id-Version: fcitx\n"
 "Report-Msgid-Bugs-To: fcitx-...@googlegroups.com\n"
-"POT-Creation-Date: 2013-10-31 06:03-0400\n"
-"PO-Revision-Date: 2013-10-31 05:48+\n"
-"Last-Translator: mar well \n"
+"POT-Creation-Date: 2014-12-09 12:02+0100\n"
+"PO-Revision-Date: 2014-12-09 09:44+\n"
+"Last-Translator: mar well \n"
 "Language-Team: German (http://www.transifex.com/projects/p/fcitx/language/;
 "de/)\n"
 "Language: de\n"
@@ -39,6 +40,10 @@
 msgid ":"
 msgstr ":"
 
+#: src/fcitx-skk.desc:60
+msgid "ABC (a,b,c,...)"
+msgstr "ABC (a,b,c,...)"
+
 #: src/fcitx-skk.desc:36
 msgid "Candidate List Layout"
 msgstr "Layout der Kandidatenliste"
@@ -51,13 +56,17 @@
 msgid "Dictionary and Rule"
 

Bug#826698: RM: snappy-player -- RoQA; unmaintained, RC buggy

[Michael Biebl]

Package: ftp.debian.org
Severity: normal

Hi,

the snappy-player package in Debian appears to be in a bad shape and has
been RC buggy for quite a while with no response from the maintainer.
It is now also blocking the removal of clutter-gst-2.0 [1].

I therefor think it's best to remove the snappy-player package from the
archive.

I've CCed pkg-gstreamer maintainers, please speak up if you object to
the removal

Regards,
Michael

[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=805640

Bug#826696: fcitx: fix typos at upstream source and debian/control*

[HIGUCHI Daisuke (VDR dai)]

Source: fcitx
Version: 1:4.2.9.1-1
Severity: normal

Dear Maintainer,

I created 2 patches.

1. fix-debian-control-typos.patch

fix Description typos in debian/control and debian/control.in.

-Description: Flexible Input Method Framework - library of core funtions
+Description: Flexible Input Method Framework - library of core functions

2. 0003-fix-src-typos.patch

fix typos in FcitxLog. This typo causes spelling-error-in-binary at fcitx-*.
-- 
Regards,
dai

GPG Fingerprint = 0B29 D88E 42E6 B765 B8D8 EA50 7839 619D D439 668E

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

Kernel: Linux 4.5.0-2-amd64 (SMP w/8 CPU cores)
Locale: LANG=ja_JP.UTF-8, LC_CTYPE=ja_JP.UTF-8 (charmap=UTF-8) (ignored: LC_ALL 
set to ja_JP.UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
diff --git a/debian/control b/debian/control
index e03b5e1..9c756b0 100644
--- a/debian/control
+++ b/debian/control
@@ -144,7 +144,7 @@ Depends: ${misc:Depends}, ${shlibs:Depends}
 Suggests: fcitx (>= ${source:Upstream-Version})
 Replaces: fcitx (<< ${source:Upstream-Version}), fcitx-libs (<< 1:4.2.8.5-3)
 Breaks: fcitx (<< ${source:Upstream-Version}), fcitx-libs (<< 1:4.2.8.5-3)
-Description: Flexible Input Method Framework - library of core funtions
+Description: Flexible Input Method Framework - library of core functions
  Fcitx is a input method framework with extension support, which provides
  an interface for entering characters of different scripts in applications
  using a variety of mapping systems.
diff --git a/debian/control.in b/debian/control.in
index e03b5e1..9c756b0 100644
--- a/debian/control.in
+++ b/debian/control.in
@@ -144,7 +144,7 @@ Depends: ${misc:Depends}, ${shlibs:Depends}
 Suggests: fcitx (>= ${source:Upstream-Version})
 Replaces: fcitx (<< ${source:Upstream-Version}), fcitx-libs (<< 1:4.2.8.5-3)
 Breaks: fcitx (<< ${source:Upstream-Version}), fcitx-libs (<< 1:4.2.8.5-3)
-Description: Flexible Input Method Framework - library of core funtions
+Description: Flexible Input Method Framework - library of core functions
  Fcitx is a input method framework with extension support, which provides
  an interface for entering characters of different scripts in applications
  using a variety of mapping systems.
From: HIGUCHI Daisuke (VDR dai) 
Date: Wed, 08 Jun 2016 11:02:49 +0900
Subject: fix src typos

diff --git a/src/lib/fcitx-config/fcitx-config.h b/src/lib/fcitx-config/fcitx-config.h
index ad60789..e0c76a6 100644
--- a/src/lib/fcitx-config/fcitx-config.h
+++ b/src/lib/fcitx-config/fcitx-config.h
@@ -416,7 +416,7 @@ extern "C"
 tmpfp = FcitxXDGGetFileWithPrefix("configdesc", path, "r", NULL); \
 if (tmpfp == NULL) \
 { \
-FcitxLog(ERROR, "Load Config Description File %s Erorr, Please Check your install.", path); \
+FcitxLog(ERROR, "Load Config Description File %s Error, Please Check your install.", path); \
 return NULL; \
 } \
 configDesc = FcitxConfigParseConfigFileDescFp(tmpfp); \
diff --git a/src/module/lua/luawrap.c b/src/module/lua/luawrap.c
index d9452a7..6a6f158 100644
--- a/src/module/lua/luawrap.c
+++ b/src/module/lua/luawrap.c
@@ -166,7 +166,7 @@ static int FcitxLog_Export(lua_State *lua) {
 static int ImeRegisterCommand_Export(lua_State *lua) {
 int c = lua_gettop(lua);
 if (c < 2) {
-FcitxLog(WARNING, "register command arugment missing");
+FcitxLog(WARNING, "register command argument missing");
 return 0;
 }
 const char *command_name = lua_tostring(lua, 1);
@@ -194,7 +194,7 @@ static int ImeRegisterTrigger_Export(lua_State *lua) {
 if (c >= kFunctionNameArg) {
 function_name = lua_tostring(lua, kFunctionNameArg);
 if (function_name == NULL || function_name[0] == 0) {
-FcitxLog(WARNING, "register trigger arugment function_name empty");
+FcitxLog(WARNING, "register trigger argument function_name empty");
 return 0;
 }
 }


signature.asc
Description: PGP signature

Bug#826695: chrony stopped working

[David Lawyer]

Package: chrony
Version: 1.31.1

The last statistics log is for March 15, 2016 and it's empty.  chronyc
chronyc sources:
210 Number of sources = 4
MS Name/IP address Stratum Poll Reach LastRx Last sample
===
^? b1-66er.matrix.gs 0  10 0   10y +0ns[   +0ns] +/-0ns
^? propjet.latt.net  0  10 0   10y +0ns[   +0ns] +/-0ns
^? ha82.smatwebdesign.com0  10 0   10y +0ns[   +0ns] +/-0ns
^? ntp.untangle.com  0   9 0   10y +0ns[   +0ns] +/-0ns

The sources seem to frequently change by themselves.  It's as if the
sources can't be reached so it keeps trying new ones, yet I can ping all
the sources shown here and on other tries.  Note that 10y for 10 years ago
is not true.  It likely never received any time data from these sources.

--
cronyc tracking:
Reference ID: 127.127.1.1 ()
Stratum : 10
Ref time (UTC)  : Mon Jun  6 00:33:57 2016
System time : 0.1 seconds slow of NTP time
Last offset : +0.0 seconds
RMS offset  : 0.0 seconds
Frequency   : 5.857 ppm slow
Residual freq   : +0.000 ppm
Skew: 0.000 ppm
Root delay  : 0.00 seconds
Root dispersion : 0.01 seconds
Update interval : 0.0 seconds
Leap status : Not synchronised

The above look OK except the command "date" typed on the shell command line
shows a time that is 16 minutes slower than the actual time (checked by a
wristwatch set to time from the Inet).  And I can't reset the hardware
clock with "settime" since I get "facility not enabled in daemon".  If I
try to use the hwclock program to correct the time it says it has no
method of access to the hardware clock.

---
chrnyc activity:
200 OK
4 sources online
0 sources offline
0 sources doing burst (return to online)
0 sources doing burst (return to offline)
0 sources with unknown address

Here's the start of the tracking log file (note the scew of exactly one
million):

==
   Date (UTC) Time IP Address   St   Freq ppm   Skew ppm Offset L Co  
Offset sd Rem. corr.
==
2016-06-04 08:37:38 0.0.0.0  0 -5.857 100.000  0.000e+00 ?  0  
0.000e+00  1.100e-16
==
   Date (UTC) Time IP Address   St   Freq ppm   Skew ppm Offset L Co  
Offset sd Rem. corr.
==
2016-06-05 08:45:55 0.0.0.0  0 -5.857 100.000  0.000e+00 ?  0  
0.000e+00  9.856e-17
==
   Date (UTC) Time IP Address   St   Freq ppm   Skew ppm Offset L Co  
Offset sd Rem. corr.
==
2016-06-05 08:58:14 0.0.0.0  0 -5.857 100.000  0.000e+00 ?  0  
0.000e+00  9.175e-17
==
---
I restarted chronyd with the -d flag and it only showed a couple of lines
and showed the skew to be 1 million seconds and not 0 as shown in
tracking.  I did chrony>burst and nothing was shown on the terminal,
although if I do chronyc activity it does show the burst running for
awhile (a minute or two).

So why isn't it working?  I'm running Debian 4.2.3 on an old Pentium I PC.
And I updated using aptitude in Nov. 2015 which might be about when
problems with chrony started (but I failed to investigate them then).

David Lawyer

Bug#826694: duck: Should not suggest a switch from HTTP to HTTPS if SSL certificate is not verifiable

[Axel Beckert]

Package: duck
Version: 0.9
Severity: normal

Dear Maintainer,

http://repo.or.cz/ is one of the earliest if not the earliest free Git
hoster.

Some Debian packages refer to code hosted on that website.

The website is also reachable at http://repo.or.cz/, hence duck argues
about not using HTTPS:

I: debian/control: Vcs-Browser: http://repo.or.cz/w/conkeror.git: INFORMATION 
(Certainty:certain)
   The web page at http://repo.or.cz/w/conkeror.git works, but is also 
available via https://repo.or.cz/w/conkeror.git, please consider switching to 
HTTPS urls.

I: debian/copyright:4: URL: http://repo.or.cz/w/conkeror.git: INFORMATION 
(Certainty:possible)
   The web page at http://repo.or.cz/w/conkeror.git works, but is also 
available via https://repo.or.cz/w/conkeror.git, please consider switching to 
HTTPS urls.

But it uses a self-signed SSL certificate for HTTPS and hence the
suggested URLs causes a fat warning in every web browser and also in
OpenSSL:

$ echo QUIT | openssl s_client -connect repo.or.cz:443 | openssl x509 -in 
/dev/stdin -noout -text
depth=1 serialNumber = 
6a:ac:44:8f:07:1d:57:0a:1c:cf:12:a2:a7:8f:29:b9:c0:ed:cc:d7, CN = girocco rorcz 
root certificate
verify error:num=19:self signed certificate in certificate chain
DONE
Certificate:
Data:
Version: 3 (0x2)
Serial Number:
36:27:b4:05:67:14:75:a2:bd:e1:e6:9f:61:ea:48:53:de:48:a6:e8
Signature Algorithm: sha256WithRSAEncryption
Issuer: 
serialNumber=6a:ac:44:8f:07:1d:57:0a:1c:cf:12:a2:a7:8f:29:b9:c0:ed:cc:d7, 
CN=girocco rorcz root certificate
Validity
Not Before: Aug 11 00:00:00 1997 GMT
Not After : Dec 31 23:59:59  GMT
Subject: CN=repo.or.cz
[…]

IMHO, duck should only suggest to switch to HTTPS if the used SSL
certificate can be verified by the SSL certificates shipped in the
package ca-certificates. Probably for local runs of duck, only those
certificates should be taken into account, which are verifiable by
_enabled_ certificates from ca-certificates.

It's probably debatable if sites with SSL certificates verifiable with
the package ca-cacert installed or sites with a self-signed certificate
verifiable via TLSA/DANE should cause such a warning or not. I tend to
say no here, too.

-- System Information:
Debian Release: stretch/sid
Architecture: amd64 (x86_64)

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

Versions of packages duck depends on:
ii  devscripts   2.16.5
ii  dpkg-dev 1.18.7
ii  libconfig-inifiles-perl  2.89-1
ii  libconfig-simple-perl4.59-6
ii  libdomain-publicsuffix-perl  0.10-1
ii  libfile-which-perl   1.21-1
ii  libmailtools-perl2.13-1
ii  libnet-dns-perl  1.05-2
ii  libparse-debcontrol-perl 2.005-4
ii  libpath-class-perl   0.36-1
ii  libregexp-common-email-address-perl  1.01-4
ii  libregexp-common-perl2016060201-1
ii  libstring-similarity-perl1.04-1+b3
ii  libwww-curl-perl 4.17-2+b1
ii  libxml-xpath-perl1.36-1
ii  libyaml-libyaml-perl 0.41-6+b1
ii  lynx 2.8.9dev9-1
ii  perl 5.22.2-1
ii  publicsuffix 20160525-1

duck recommends no packages.

Versions of packages duck suggests:
ii  bzr 2.7.0-7
ii  git 1:2.8.1-1
ii  mercurial   3.8.3-1
ii  subversion  1.9.4-1

-- no debconf information

Bug#826678: reboot solved the immediate problem

[John Comeau]

`reboot -f` worked, and the server seems now fully functional. the
only problem, then, is that no warning is given and/or reload
initiated on post-install. perhaps it's not the libc6 package at
fault, it could be upstart.
-- 
John Comeau KE5TFZ j...@unternet.net http://jc.unternet.net/
"A place for everything, and everything all over the place"

Bug#826693: gnutls28: please mark netstat b-d with

[Steven Chamberlain]

Package: gnutls28
Version: 3.4.13-1
Severity: normal
Tags: patch
User: helm...@debian.org
Usertags: rebootstrap

Hi,

gnutls28 recently added new build-dependencies for netstat:

+ net-tools [!kfreebsd-i386 !kfreebsd-amd64],
+ freebsd-net-tools [kfreebsd-i386 kfreebsd-amd64]

Since this is only needed to run the testsuite, please could you
mark it with build profile  as in the attached patch?
(As is already done for datefudge).

If we're not running the test suite, we shouldn't need this
build-dependency.  And when cross-building the package, a foreign
netstat binary probably won't work anyway.

I noticed this on kfreebsd-amd64 when trying to cross-build gnutls28 for
linux-armhf, using Helmut's rebootstrap script;  we can't currently
satisfy the build-dependency on net-tools.

I've tested that I can cross-build gnutls28 again after this change.
Thanks!

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

Kernel: kFreeBSD 10.1-0-amd64
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)
>From 4309e250ef42e8f643fc0b253f8725bed9076530 Mon Sep 17 00:00:00 2001
From: Steven Chamberlain 
Date: Wed, 8 Jun 2016 00:44:20 +0100
Subject: [PATCH] Mark netstat b-d with 

If the netstat build dependencies are only needed to run the test
suite, they can be excluded from the nocheck build profile.
---
 debian/control | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/debian/control b/debian/control
index cba24e2..321822a 100644
--- a/debian/control
+++ b/debian/control
@@ -12,8 +12,8 @@ Build-Depends: debhelper (>= 9.20150628), nettle-dev (>= 3.1), zlib1g-dev,
  libp11-kit-dev (>= 0.23.1), pkg-config, chrpath, libidn11-dev (>= 1.31),
  autogen (>= 1:5.16-0), bison, dh-autoreconf, libgmp-dev (>= 2:6),
  libopts25-dev, automake (>= 1:1.12.2),
- net-tools [!kfreebsd-i386 !kfreebsd-amd64],
- freebsd-net-tools [kfreebsd-i386 kfreebsd-amd64]
+ net-tools [!kfreebsd-i386 !kfreebsd-amd64] ,
+ freebsd-net-tools [kfreebsd-i386 kfreebsd-amd64] 
 # The b-d on libgmp-dev is not technically necessary, since nettle brings
 # it along. However we want to enforce that gnutls is only built if the
 # dual-licensed GMP is available, otherwise the resulting binary
-- 
1.8.4.rc3

Bug#823064: libmail-srs-perl: decode address with smashed case returns no decoded address

[Dave Norman]

Mail::SRS::Daemon::run() currently makes warnings fatal, so the warn()
in hash_verify() propagates up through parse() to reverse(), where it
kills the daemon.

So, after twelve years, I think it's time to stop making warnings fatal:

diff -r a/usr/share/perl5/Mail/SRS/Daemon.pm
b/usr/share/perl5/Mail/SRS/Daemon.pm
72,75d71
<   # Until we decide that forward() and reverse() can die, this will
<   # allow us to trap the error messages from those subroutines.
<   local $SIG{__WARN__} = sub { die @_; };
<

Note that warnings will still go to the syslog and journal:
# echo 'FORWARD t...@original-to.example.tld forwarding-service.tld' | srsc
SRS0=D4BWnURvl4EWeb6+2Vl/WWhX=R7=original-to.example.tld=t...@forwarding-service.tld
# echo 'REVERSE
SRS0=D4BWnURvl4EWeb6+2Vl/WWhX=R7=original-to.example.tld=t...@forwarding-service.tld'
| srsc
t...@original-to.example.tld
# echo 'REVERSE
srs0=d4bwnurvl4eweb6+2vl/wwhx=r7=original-to.example.tld=t...@forwarding-service.tld'
| srsc
t...@original-to.example.tld
# journalctl -u srsd -l | tail -n1
Jun 07 22:54:40 london.dah31.org srsd[7793]: SRS: Case insensitive
hash match detected. Someone smashed case in the local-part. at
/usr/share/perl5/Mail/SRS.pm line 421,  line 1.

Cheers,

-- 
Dave Norman
bugs.debian@dah31.org

Bug#826335: jessie-pu: package e2fsprogs/1.42.12-2

[Theodore Ts'o]

On Tue, Jun 07, 2016 at 07:30:33PM +0100, Adam D. Barratt wrote:
> 
> It's on my to-do list to review.
> 
> fwiw there's not been any need to formally acknowledge NMUs via closing
> bugs in the changelog since the BTS gained version-tracking some years
> ago, so long as the changelog for the subsequent upload incorporates the
> stanza from the NMU.

OK, I'll wait for you to give me a formal review of things you'd like
change, and then I'll re-upload at that time.

Thanks,

- Ted

Bug#826691: reiserfsprogs-udeb: uninstallable, depends on non-udeb reiserfsprogs

[Cyril Brulebois]

Package: reiserfsprogs-udeb
Version: 1:3.6.25-1
Severity: serious
Justification: uninstallable

Hi,

your package is no longer installable since it depends on a non-udeb
package: reiserfsprogs.

Please contact debian-b...@lists.debian.org (in x-d-cc) if you need
assistance.


KiBi.

Bug#814479: libbusiness-creditcard-perl: New upstream version 0.35 (including new MasterCard ranges)

[Ivan Kohler]

On Tue, Jun 07, 2016 at 10:18:08PM +0200, gregor herrmann wrote:
> On Tue, 07 Jun 2016 12:12:42 -0700, Ivan Kohler wrote:
> 
> I absolutely agree that every functional change needs to be included;
> but not the noise from build tools and unrelated changes in the
> documentation.
> 
> [...]
> 
>  
> And to speed this all up a bit :) I've pushed a jessie branch to our
> git repo:
> https://anonscm.debian.org/cgit/pkg-perl/packages/libbusiness-creditcard-perl.git/log/?h=jessie
> where I left out the non-functional changes and split the rest into
> three logical patches.
> 
> What do you think? If this looks okay to you I'm happy to proceed.

Well, only since you asked, it seems to me if you're going to include 
completely every single functional / code change in 0.35, it *is* 0.35 
and you should honestly declare $VERSION to be 0.35.  Stripping out some 
docs and unused metadata doesn't seem to me to make it 0.33 + 
selectively backported fixes.  This is really just a (very slightly 
riskier) repackaging of 0.35.

Outside of going through these contortious for our release management, a 
dependency or person that wants to check the verison wants to know what 
verison the *code* came from, not whether or not the copyright year or a 
bouncing email address are in the docs are from 0.33...

But the most important thing by far is just getting it fixed so 
transactions don't fail, so if making it a fake 0.33 is what works, then 
yeah, that's a whole lot better than not doing it.

-- 
_ivan

Bug#826692: mkreiserfs-udeb: uninstallable, depends on non-udeb reiserfsprogs

[Cyril Brulebois]

Package: mkreiserfs-udeb
Version: 1:3.6.25-1
Severity: serious
Justification: uninstallable

Hi,

your package is no longer installable since it depends on a non-udeb
package: reiserfsprogs.

Please contact debian-b...@lists.debian.org (in x-d-cc) if you need
assistance.


KiBi.

Bug#826690: dose-doc: removal of dose-doc makes files disappear from dose-distcheck (and others)

[Andreas Beckmann]

Package: dose-doc
Version: 4.3-2
Severity: serious
User: debian...@lists.debian.org
Usertags: piuparts replaces-without-breaks

Hi,

during a test with piuparts and DOSE tools I noticed your package causes
removal of files that also belong to another package.
This is caused by using Replaces without corresponding Breaks.

The installation sequence to reproduce this problem is

  apt-get install dose-distcheck/sid
  # (1)
  apt-get install dose-doc/experimental
  apt-get remove dose-doc
  # (2)

The list of installed files at points (1) and (2) should be identical,
but the following files have disappeared:

  /usr/share/doc-base/debcheck-primer

This is a serious bug violating policy 7.6, see
https://www.debian.org/doc/debian-policy/ch-relationships.html#s-replaces
and also see the footnote that describes this incorrect behavior
https://www.debian.org/doc/debian-policy/footnotes.html#f53

The dose-doc package has the following relationships with dose-distcheck:

  Conflicts: n/a
  Breaks:n/a
  Replaces:  apt-cudf (<< 4.3-2), dose-distcheck (<< 4.3-2), libdose3-ocaml-dev 
(<< 4.3-2)

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

0m42.1s ERROR: FAIL: After purging files have disappeared:
  /usr/share/doc-base/debcheck-primerowned by: dose-doc

0m42.1s ERROR: FAIL: After purging files have been modified:
  /var/lib/dpkg/info/dose-distcheck.list not owned


Similar problems exist with apt-cudf and libdose3-ocaml-dev.


cheers,

Andreas


dose-distcheck=4.2-2_dose-doc=4.3-2.log.gz
Description: application/gzip

Bug#826680: [Pkg-utopia-maintainers] Bug#826680: Bug#826680: Bug#826680: network-manager: please move isc-dhcp-client from Depends: to Recommends:

[Daniel Kahn Gillmor]

On Tue 2016-06-07 18:52:27 -0400, Michael Biebl wrote:
> [ Unknown signature status ]
> Am 08.06.2016 um 00:35 schrieb Michael Biebl:
>> The problem here is that turning the depends into a recommends could
>> lead to isc-dhcp-client to be uninstalled on upgrades.
>> I'd have to verify that, but if the package was marked as auto-installed
>> (which it typically is), I will be uninstalled by "apt autoremove" or
>> aptitude upgrade. This would be very undesirable.
>
> # apt upgrade
> Reading package lists... Done
> Building dependency tree
> Reading state information... Done
> Calculating upgrade... Done
> The following packages were automatically installed and are no longer
> required:
>   iproute2 isc-dhcp-client libdns-export162 libisc-export160
> Use 'sudo apt autoremove' to remove them.
> The following packages will be upgraded:
>   libgdbm3 libnm0 linux-libc-dev network-manager
> 4 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
> Need to get 4640 kB of archives.
> After this operation, 47.1 kB of additional disk space will be used.
> Do you want to continue? [Y/n]

so this isn't auto-installed, but is proposed for removal with
autoremove.

> # aptitude upgrade
> The following packages will be REMOVED:
>   iproute2{u} isc-dhcp-client{u} libdns-export162{u} libisc-export160{u}
> The following packages will be upgraded:
>   libgdbm3 libnm0 linux-libc-dev network-manager
> The following packages are RECOMMENDED but will NOT be installed:
>   crda dnsmasq-base iptables iputils-arping modemmanager ppp wader-core
> 4 packages upgraded, 0 newly installed, 4 to remove and 0 not upgraded.
> Need to get 4640 kB of archives. After unpacking 4822 kB will be freed.
> Do you want to continue? [Y/n/?]

sounds like aptitude is being more aggressive.

But again, this is due to the user having manually configured (at least)

   APT::Install-Recommends "0";

right?   Isn't that what they're asking for?

How frequently do we expect network-manager's built-in dhcp client to
fail on normal networks?

 --dkg


signature.asc
Description: PGP signature

Bug#826689: yquake2: Limited Architextures

[danfun64]

Source: yquake2
Version: 5.32~dfsg1-1
Severity: important

Dear Maintainer,

   * What led up to the situation? Debian originally used the vanilla Quake 2
source before switching to the Yamagi Quake 2 source port.
   * What exactly did you do (or not do) that was effective (or
 ineffective)? I went to yquake2's github page. The resulting bug report is
here: https://github.com/yquake2/yquake2/issues/138
   * What was the outcome of this action? They said that in theory it can be
ported into other architextures, and that I should ask you guys why it's only
available for amd64 and i386. They said that if you address this bug, that they
would be willing to implement any changes you make into their codebase.
   * What outcome did you expect instead? ...they change the code to make it
more portable?




-- System Information:
Debian Release: stretch/sid
  APT prefers xenial-updates
  APT policy: (500, 'xenial-updates'), (500, 'xenial-security'), (500, 
'xenial-proposed'), (500, 'xenial'), (100, 'xenial-backports')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.4.0-23-generic (SMP w/4 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: upstart (via init_is_upstart())

Bug#826680: [Pkg-utopia-maintainers] Bug#826680: Bug#826680: Bug#826680: network-manager: please move isc-dhcp-client from Depends: to Recommends:

[Michael Biebl]

Am 08.06.2016 um 00:35 schrieb Michael Biebl:
> The problem here is that turning the depends into a recommends could
> lead to isc-dhcp-client to be uninstalled on upgrades.
> I'd have to verify that, but if the package was marked as auto-installed
> (which it typically is), I will be uninstalled by "apt autoremove" or
> aptitude upgrade. This would be very undesirable.

# apt upgrade
Reading package lists... Done
Building dependency tree
Reading state information... Done
Calculating upgrade... Done
The following packages were automatically installed and are no longer
required:
  iproute2 isc-dhcp-client libdns-export162 libisc-export160
Use 'sudo apt autoremove' to remove them.
The following packages will be upgraded:
  libgdbm3 libnm0 linux-libc-dev network-manager
4 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
Need to get 4640 kB of archives.
After this operation, 47.1 kB of additional disk space will be used.
Do you want to continue? [Y/n]

# aptitude upgrade
The following packages will be REMOVED:
  iproute2{u} isc-dhcp-client{u} libdns-export162{u} libisc-export160{u}
The following packages will be upgraded:
  libgdbm3 libnm0 linux-libc-dev network-manager
The following packages are RECOMMENDED but will NOT be installed:
  crda dnsmasq-base iptables iputils-arping modemmanager ppp wader-core
4 packages upgraded, 0 newly installed, 4 to remove and 0 not upgraded.
Need to get 4640 kB of archives. After unpacking 4822 kB will be freed.
Do you want to continue? [Y/n/?]




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



signature.asc
Description: OpenPGP digital signature

Bug#826688: python-openturns-dev: fails to upgrade from 'sid' - trying to overwrite /usr/include/openturns/swig/ANCOVA.i

[Andreas Beckmann]

Package: python-openturns-dev
Version: 1.7-1
Severity: serious
User: debian...@lists.debian.org
Usertags: piuparts

Hi,

during a test with piuparts I noticed your package fails to upgrade from
'sid' to 'experimental'.
It installed fine in 'sid', then the upgrade to 'experimental' 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/ch-relationships.html#s-replaces

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

  Selecting previously unselected package python-openturns-dev.
  Preparing to unpack .../python-openturns-dev_1.7-1_all.deb ...
  Unpacking python-openturns-dev (1.7-1) ...
  dpkg: error processing archive 
/var/cache/apt/archives/python-openturns-dev_1.7-1_all.deb (--unpack):
   trying to overwrite '/usr/include/openturns/swig/ANCOVA.i', which is also in 
package libopenturns-dev 1.5-7+b2
  dpkg-deb: error: subprocess paste was killed by signal (Broken pipe)
  Errors were encountered while processing:
   /var/cache/apt/archives/python-openturns-dev_1.7-1_all.deb


cheers,

Andreas


libopenturns-dev=1.5-7+b2_python-openturns-dev=1.7-1.log.gz
Description: application/gzip

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

[Santiago Vila]

tags 806078 + patch
thanks

The following patch should fix this bug.

Note: The patch also disables debhelper verbose mode (which is more
appropriate for debugging) and drops an extra -i option in a cp
command which was out of context (as it was not a dh_* command).

Thanks.--- a/debian/rules
+++ b/debian/rules
@@ -3,7 +3,7 @@
 
 
 # Uncomment this to turn on verbose mode.
-export DH_VERBOSE=1
+# export DH_VERBOSE=1
 
 PACKAGE=mmass
 VERSION="4.0.0"
@@ -34,11 +34,7 @@ clean:
 
 # build #
 build-arch-stamp: 
-   dh_testdir
dh_prep -a
-
-   convert gui/images/gtk/icon_32.png debian/mmass.xpm
-
# This will create the "calculations.so" shared object in
# mspy/plot/build/lib.linux-i686-2.6. This shared object will
# have to be installed as
@@ -49,8 +45,13 @@ build-arch-stamp:
 
touch build-arch-stamp
 
+build-indep-stamp:
+   dh_prep -i
+   convert gui/images/gtk/icon_32.png debian/mmass.xpm
+   touch build-indep-stamp
+
 .PHONY: build-indep
-build-indep: 
+build-indep: build-indep-stamp
 
 .PHONY: build-arch
 build-arch: build-arch-stamp
@@ -88,7 +89,7 @@ binary-indep:
dh_prep  -i
dh_installdirs -i
dh_lintian -i
-   cp debian/start-script $(INSTALLDIR)/usr/bin/mmass -i
+   cp debian/start-script $(INSTALLDIR)/usr/bin/mmass
dh_installchangelogs  -i
dh_installdocs -i
dh_install -i

Bug#774082: lvm2 package update causes errors in Debian 8 systems

[Jered Floyd]

I recently updated my systems to Debian 8.5, which included the lvm2 package 
that closed this bug. 

Now every LVM request always results in: 
WARNING: lvmetad is running but disabled. Restart lvmetad before enabling it! 

This change should be reverted, or fixed to not start lvmetad on systems where 
it wasn't previously running or in use. debian-installer has it disabled by 
default. 

--Jered 

Bug#826680: [Pkg-utopia-maintainers] Bug#826680: Bug#826680: network-manager: please move isc-dhcp-client from Depends: to Recommends:

[Michael Biebl]

Am 08.06.2016 um 00:27 schrieb Daniel Kahn Gillmor:
> Users which turn off Recommends on an already-installed system will
> already have isc-dhcp-client installed, and won't end up with no network
> connection upon upgrade even if the internal dhcp client *doesn't* work
> on their local network.  And users who are doing a fresh install while
> forcing --no-install-recommends on an unusually-broken network might
> need to either drop --no-install-recommends, or add isc-dhcp-client to
> their configuration explicitly.
> 

The problem here is that turning the depends into a recommends could
lead to isc-dhcp-client to be uninstalled on upgrades.
I'd have to verify that, but if the package was marked as auto-installed
(which it typically is), I will be uninstalled by "apt autoremove" or
aptitude upgrade. This would be very undesirable.


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



signature.asc
Description: OpenPGP digital signature

Bug#826684: staden,spin: error when trying to install together

[Tom Lee]

Thanks Andreas, appreciate you bringing this to my attention.

Complicating this: we're still in the process of getting spin through the
ITP/RFS process due to some licensing concerns with parts of the source
package, I think the package may have been accidentally uploaded today
instead of being rejected from the NEW queue. I'll follow up with the FTP
folks to get a sense of what's going on and try to get this resolved as
soon as I can.

Keep you posted.


On Tue, Jun 7, 2016 at 3:07 PM, Andreas Beckmann  wrote:

> Package: staden,spin
> Severity: serious
> User: trei...@debian.org
> Usertags: edos-file-overwrite
>
> Hi,
>
> automatic installation tests of packages that share a file and at the
> same time do not conflict by their package dependency relationships has
> detected the following problem:
>
>   Selecting previously unselected package spin.
>   Preparing to unpack .../spin_6.4.5-1_amd64.deb ...
>   Unpacking spin (6.4.5-1) ...
>   dpkg: error processing archive
> /var/cache/apt/archives/spin_6.4.5-1_amd64.deb (--unpack):
>trying to overwrite '/usr/bin/spin', which is also in package staden
> 2.0.0+b10-5
>   dpkg-deb: error: subprocess paste was killed by signal (Broken pipe)
>   Errors were encountered while processing:
>/var/cache/apt/archives/spin_6.4.5-1_amd64.deb
>
> This is a serious bug as it makes installation fail, and violates
> sections 7.6.1 and 10.1 of the policy. An optimal solution would
> consist in only one of the packages installing that file, and renaming
> or removing the file in the other package. Depending on the
> circumstances you might also consider Replace relations or file
> diversions. If the conflicting situation cannot be resolved then, as a
> last resort, the two packages have to declare a mutual
> Conflict. Please take into account that Replaces, Conflicts and
> diversions should only be used when packages provide different
> implementations for the same functionality.
>
> Here is a list of files that are known to be shared by both packages
> (according to the Contents file for sid/amd64, which may be
> slightly out of sync):
>
>   usr/bin/spin
>   usr/share/man/man1/spin.1.gz
>
> This bug is assigned to both packages. If you, the maintainers of
> the two packages in question, have agreed on which of the packages will
> resolve the problem please reassign the bug to that package. You may
> also register in the BTS that the other package is affected by the bug.
>
> Cheers,
>
> Andreas
>
> PS: for more information about the detection of file overwrite errors
> of this kind see https://qa.debian.org/dose/file-overwrites.html
>



-- 
*Tom Lee */ http://tomlee.co / @tglee 

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

[Aurelien Jarno]

On 2016-05-29 17:19, Adam D. Barratt wrote:
> Control: tags -1 -moreinfo +confirmed
> 
> On Sun, 2016-05-29 at 17:53 +0200, Aurelien Jarno wrote:
> 
> > Can we get this into jessie-proposed-updates just after the 8.5 release,
> > so that it doesn't happen again for 8.6? Most of these changes were
> > ready in our git repository for over a month, it's just I didn't got time
> > this week to finish preparing the final upload.
> 
> That sounds like a good plan.

Now that the 8.5 release is out, I would like to upload glibc version
2.19-18+deb8u5 to jessie-proposed-updates. You will find the diff below,
it only differs to the previous one by the addition of the CVE-2016-4429
fix.

Regards,
Aurelien


diff --git a/debian/changelog b/debian/changelog
index db98ce0..b619b11 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,19 @@
+glibc (2.19-18+deb8u5) UNRELEASED; urgency=medium
+
+  [ Aurelien Jarno ]
+  * Update from upstream stable branch:
+- Drop debian/patches/any/local-CVE-2015-7547.diff.
+- Refresh debian/patches/any/cvs-resolv-first-query-failure.diff.
+- Fix assertion failure with unconnectable name server addresses.
+  (regression introduced by CVE-2015-7547).  Closes: #816669.
+- Fix *context functions on s390x.
+- Fix a buffer overflow in the glob function (CVE-2016-1234).
+- Fix a stack overflow in nss_dns_getnetbyname_r (CVE-2016-3075).
+- Fix a stack overflow in getaddrinfo function (CVE-2016-3706).
+- Fix a stack overflow in Sun RPC clntudp_call() (CVE-2016-4429).
+
+ -- Aurelien Jarno   Sun, 01 May 2016 16:38:48 +0200
+
 glibc (2.19-18+deb8u4) stable; urgency=medium
 
   [ Aurelien Jarno ]
diff --git a/debian/patches/any/cvs-resolv-first-query-failure.diff 
b/debian/patches/any/cvs-resolv-first-query-failure.diff
index d99e636..856d850 100644
--- a/debian/patches/any/cvs-resolv-first-query-failure.diff
+++ b/debian/patches/any/cvs-resolv-first-query-failure.diff
@@ -44,11 +44,11 @@ diff --git a/resolv/res_send.c b/resolv/res_send.c
if (recvresp1 || (buf2 != NULL && recvresp2)) {
  *resplen2 = 0;
  return resplen;
-@@ -1368,7 +1369,6 @@ send_dg(res_state statp,
+@@ -1527,7 +1528,6 @@  send_dg(res_state statp,
goto wait;
  }
  
 -  next_ns:
-   __res_iclose(statp, false);
/* don't retry if called from dig */
if (!statp->pfcode)
+ return close_and_return_error (statp, resplen2);
diff --git a/debian/patches/any/local-CVE-2015-7547.diff 
b/debian/patches/any/local-CVE-2015-7547.diff
deleted file mode 100644
index 0a93cd5..000
--- a/debian/patches/any/local-CVE-2015-7547.diff
+++ /dev/null
@@ -1,541 +0,0 @@
 a/resolv/nss_dns/dns-host.c
-+++ b/resolv/nss_dns/dns-host.c
-@@ -1052,7 +1052,10 @@
-   int h_namelen = 0;
- 
-   if (ancount == 0)
--return NSS_STATUS_NOTFOUND;
-+{
-+  *h_errnop = HOST_NOT_FOUND;
-+  return NSS_STATUS_NOTFOUND;
-+}
- 
-   while (ancount-- > 0 && cp < end_of_message && had_error == 0)
- {
-@@ -1229,7 +1232,14 @@
-   /* Special case here: if the resolver sent a result but it only
-  contains a CNAME while we are looking for a T_A or T_ record,
-  we fail with NOTFOUND instead of TRYAGAIN.  */
--  return canon == NULL ? NSS_STATUS_TRYAGAIN : NSS_STATUS_NOTFOUND;
-+  if (canon != NULL)
-+{
-+  *h_errnop = HOST_NOT_FOUND;
-+  return NSS_STATUS_NOTFOUND;
-+}
-+
-+  *h_errnop = NETDB_INTERNAL;
-+  return NSS_STATUS_TRYAGAIN;
- }
- 
- 
-@@ -1243,11 +1253,101 @@
- 
-   enum nss_status status = NSS_STATUS_NOTFOUND;
- 
-+  /* Combining the NSS status of two distinct queries requires some
-+ compromise and attention to symmetry (A or  queries can be
-+ returned in any order).  What follows is a breakdown of how this
-+ code is expected to work and why. We discuss only SUCCESS,
-+ TRYAGAIN, NOTFOUND and UNAVAIL, since they are the only returns
-+ that apply (though RETURN and MERGE exist).  We make a distinction
-+ between TRYAGAIN (recoverable) and TRYAGAIN' (not-recoverable).
-+ A recoverable TRYAGAIN is almost always due to buffer size issues
-+ and returns ERANGE in errno and the caller is expected to retry
-+ with a larger buffer.
-+
-+ Lastly, you may be tempted to make significant changes to the
-+ conditions in this code to bring about symmetry between responses.
-+ Please don't change anything without due consideration for
-+ expected application behaviour.  Some of the synthesized responses
-+ aren't very well thought out and sometimes appear to imply that
-+ IPv4 responses are always answer 1, and IPv6 responses are always
-+ answer 2, but that's not true (see the implemetnation of send_dg
-+ and send_vc to see response can arrive in any order, particlarly

Bug#826680: [Pkg-utopia-maintainers] Bug#826680: network-manager: please move isc-dhcp-client from Depends: to Recommends:

[Daniel Kahn Gillmor]

On Tue 2016-06-07 17:49:33 -0400, Michael Biebl wrote:
> Am 07.06.2016 um 23:33 schrieb Daniel Kahn Gillmor:
>> Given that network-manager ships with an internal DHCP client, it seems like
>> isc-dhcp-client should be a Recommends: and not a Depends:
>
> The default configuration still uses isc-dhcp-client, unless it's
> explicitly configured otherwise. So not having isc-dhcp-client installed
> means it's very likely that your network connection will be broken.
>  I'm worried that I'll have enough users which turn off Recommends and
> will end up with no network connection.

It sounds to me like you're saying that the internal dhcp client
actually can't handle some common set of networks that users are likely
to encounter.  Is that the case?  In my experience, it works on common
networks i've tried.

fwiw, this is exactly the reason we have Recommends: -- normal users get
to have things that work in the "usual" way, and people who want a
stripped-down system get a stripped-down system (potentially meaning
that they might have to do some additional fiddling if they meet a
corner case).

Users which turn off Recommends on an already-installed system will
already have isc-dhcp-client installed, and won't end up with no network
connection upon upgrade even if the internal dhcp client *doesn't* work
on their local network.  And users who are doing a fresh install while
forcing --no-install-recommends on an unusually-broken network might
need to either drop --no-install-recommends, or add isc-dhcp-client to
their configuration explicitly.

I think this is the right set of tradeoffs, fwiw.  Otherwise, we're
going to end up with "dependency inflation" where we add a
"really-recommends" or a "probably-depends" or something silly like that
;)

Thanks for your work on network-manager!

   --dkg


signature.asc
Description: PGP signature

Bug#826687: translate-toolkit-doc: fails to upgrade from 'sid' - trying to overwrite /usr/share/doc-base/translate-toolkit

[Andreas Beckmann]

Package: translate-toolkit-doc
Version: 2.0.0~b1-1
Severity: serious
User: debian...@lists.debian.org
Usertags: piuparts

Hi,

during a test with piuparts I noticed your package fails to upgrade from
'sid' to 'experimental'.
It installed fine in 'sid', then the upgrade to 'experimental' 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/ch-relationships.html#s-replaces

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

  Selecting previously unselected package translate-toolkit-doc.
  Preparing to unpack .../translate-toolkit-doc_2.0.0~b1-1_all.deb ...
  Unpacking translate-toolkit-doc (2.0.0~b1-1) ...
  dpkg: error processing archive 
/var/cache/apt/archives/translate-toolkit-doc_2.0.0~b1-1_all.deb (--unpack):
   trying to overwrite '/usr/share/doc-base/translate-toolkit', which is also 
in package translate-toolkit 1.13.0-1
  Errors were encountered while processing:
   /var/cache/apt/archives/translate-toolkit-doc_2.0.0~b1-1_all.deb


cheers,

Andreas


translate-toolkit=1.13.0-1_translate-toolkit-doc=2.0.0~b1-1.log.gz
Description: application/gzip

Bug#826686: golang-github-burntsushi-toml-dev: fails to upgrade from 'testing' - trying to overwrite /usr/share/gocode/src/github.com/BurntSushi/toml/_examples/example.go

[Andreas Beckmann]

Package: golang-github-burntsushi-toml-dev
Version: 0.2.0-2
Severity: serious
User: debian...@lists.debian.org
Usertags: piuparts

Hi,

during a test with piuparts I noticed your package fails to upgrade from
'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/ch-relationships.html#s-replaces

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

  Selecting previously unselected package golang-github-burntsushi-toml-dev.
  Preparing to unpack .../golang-github-burntsushi-toml-dev_0.2.0-2_all.deb ...
  Unpacking golang-github-burntsushi-toml-dev (0.2.0-2) ...
  dpkg: error processing archive 
/var/cache/apt/archives/golang-github-burntsushi-toml-dev_0.2.0-2_all.deb 
(--unpack):
   trying to overwrite 
'/usr/share/gocode/src/github.com/BurntSushi/toml/_examples/example.go', which 
is also in package golang-toml-dev 0.2.0-1
  Processing triggers for libc-bin (2.22-9) ...
  Errors were encountered while processing:
   /var/cache/apt/archives/golang-github-burntsushi-toml-dev_0.2.0-2_all.deb


cheers,

Andreas


golang-toml-dev=0.2.0-1_golang-github-burntsushi-toml-dev=0.2.0-2.log.gz
Description: application/gzip

Bug#826685: glances-doc: fails to upgrade from 'testing' - trying to overwrite /usr/share/doc-base/glances-manual

[Andreas Beckmann]

Package: glances-doc
Version: 2.6.2-1
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/ch-relationships.html#s-replaces

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

  Selecting previously unselected package glances-doc.
  Preparing to unpack .../glances-doc_2.6.2-1_all.deb ...
  Unpacking glances-doc (2.6.2-1) ...
  dpkg: error processing archive 
/var/cache/apt/archives/glances-doc_2.6.2-1_all.deb (--unpack):
   trying to overwrite '/usr/share/doc-base/glances-manual', which is also in 
package glances 2.5.1-1
  Errors were encountered while processing:
   /var/cache/apt/archives/glances-doc_2.6.2-1_all.deb


cheers,

Andreas


glances=2.5.1-1_glances-doc=2.6.2-1.log.gz
Description: application/gzip

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

[Santiago Vila]

tags 806026 + patch
thanks

Here is a patch.

Thanks.--- a/debian/rules
+++ b/debian/rules
@@ -28,8 +28,11 @@ override_dh_auto_build:
make -C doc/dbus all
dh_auto_build
 
-override_dh_install:
-   dh_install -X .la -X .a
+override_dh_install-indep:
+   dh_install -i -X .la -X .a
+
+override_dh_install-arch:
+   dh_install -a -X .la -X .a
mkdir -p debian/libpam-fprintd/lib
mv debian/libpam-fprintd/usr/lib/* debian/libpam-fprintd/lib/
find debian/libpam-fprintd/usr -type d -empty -delete

Bug#826684: staden,spin: error when trying to install together

[Andreas Beckmann]

Package: staden,spin
Severity: serious
User: trei...@debian.org
Usertags: edos-file-overwrite

Hi,

automatic installation tests of packages that share a file and at the
same time do not conflict by their package dependency relationships has
detected the following problem:

  Selecting previously unselected package spin.
  Preparing to unpack .../spin_6.4.5-1_amd64.deb ...
  Unpacking spin (6.4.5-1) ...
  dpkg: error processing archive /var/cache/apt/archives/spin_6.4.5-1_amd64.deb 
(--unpack):
   trying to overwrite '/usr/bin/spin', which is also in package staden 
2.0.0+b10-5
  dpkg-deb: error: subprocess paste was killed by signal (Broken pipe)
  Errors were encountered while processing:
   /var/cache/apt/archives/spin_6.4.5-1_amd64.deb

This is a serious bug as it makes installation fail, and violates
sections 7.6.1 and 10.1 of the policy. An optimal solution would
consist in only one of the packages installing that file, and renaming
or removing the file in the other package. Depending on the
circumstances you might also consider Replace relations or file
diversions. If the conflicting situation cannot be resolved then, as a
last resort, the two packages have to declare a mutual
Conflict. Please take into account that Replaces, Conflicts and
diversions should only be used when packages provide different
implementations for the same functionality.

Here is a list of files that are known to be shared by both packages
(according to the Contents file for sid/amd64, which may be
slightly out of sync):

  usr/bin/spin
  usr/share/man/man1/spin.1.gz

This bug is assigned to both packages. If you, the maintainers of
the two packages in question, have agreed on which of the packages will
resolve the problem please reassign the bug to that package. You may
also register in the BTS that the other package is affected by the bug.

Cheers,

Andreas

PS: for more information about the detection of file overwrite errors
of this kind see https://qa.debian.org/dose/file-overwrites.html

Bug#826683: libpam-google-authenticator: Wrong filename in manpage

[Jeremy Bicha]

Updating the URL here too

--- debian/man/pam_google_authenticator.8 2016-06-07 21:47:04 +
+++ debian/man/pam_google_authenticator.8 2016-06-07 22:01:12 +
@@ -6,7 +6,7 @@
 .SH SYNOPSIS
 .B pam_google_authenticator.so
 .SH CAVEATS
-The current version requires the existance of ~/.google\-authenticator.
+The current version requires the existence of ~/.google\_authenticator.
 If the file does not exist for a user, the authentication module will fail.
 Each user MUST create their secret key with google\-authenticator(1)
PRIOR TO enabling this module.

@@ -25,5 +25,4 @@
 .SH "SEE ALSO"
 google-authenticator(1)

-http://code.google.com/p/google-authenticator/
-  /wiki/PamModuleInstructions
+https://github.com/google/google-authenticator/wiki/PAM-Module-Instructions

Bug#826683: libpam-google-authenticator: Wrong filename in manpage

[Jeremy Bicha]

Package: libpam-google-authenticator
Version: 20130529-2
Severity: normal
Tags: patch

As reported at https://launchpad.net/bugs/986802


--- debian/man/pam_google_authenticator.8 2016-06-07 21:47:04 +
+++ debian/man/pam_google_authenticator.8 2016-06-07 21:55:26 +
@@ -6,7 +6,7 @@
 .SH SYNOPSIS
 .B pam_google_authenticator.so
 .SH CAVEATS
-The current version requires the existance of ~/.google\-authenticator.
+The current version requires the existence of ~/.google\_authenticator.
 If the file does not exist for a user, the authentication module will fail.
 Each user MUST create their secret key with google\-authenticator(1)
PRIOR TO enabling this module.


Thanks,
Jeremy Bicha

--- System information. ---
Architecture: amd64
Kernel:   Linux 4.4.0-23-generic
Debian Release: stretch/sid

Bug#826682: ITP: sspace -- scaffolding pre-assembled contigs after extension

[Sascha Steinbiss]

Package: wnpp
Severity: wishlist
Owner: Sascha Steinbiss 

* Package name: sspace
  Version : 2.1.1
  Upstream Author : Marten Boetzer and Walter Pirovano
* URL : https://github.com/nsoranzo/sspace_basic
* License : GPL-2
  Programming Lang: Perl
  Description : scaffolding pre-assembled contigs after extension

SSAKE-based Scaffolding of Pre-Assembled Contigs after Extension (SSPACE) 
is a tool able to extend and scaffold pre-assembled biological contig
sequences using one or more mate pairs or paired-end libraries, or even a 
combination.

This is the free 'basic' version of SSPACE. The non-free 'standard' version is
available directly from Baseclear.

This package will be maintained by the Debian Med Packaging Team.

Bug#826630: ITA?

[Jean-Michel Vourgère]

Hi

I just noticed that you set up a repository on collab-maint with an
upstream git snapshot.
https://anonscm.debian.org/cgit/collab-maint/sshfp.git/

Please retitle this bug indicating an ITA (
https://www.debian.org/devel/wnpp/ ), or I will publish the NMU I
prepared today, that contain my 2013 & 2014 patches.

This evening, I also made a bunch of changes for a QA upload, almost
identical to those you did 2 months ago... A bit frustrating of course ^^

Bug#826680: [Pkg-utopia-maintainers] Bug#826680: network-manager: please move isc-dhcp-client from Depends: to Recommends:

[Michael Biebl]

Am 07.06.2016 um 23:33 schrieb Daniel Kahn Gillmor:
> Given that network-manager ships with an internal DHCP client, it seems like
> isc-dhcp-client should be a Recommends: and not a Depends:

The default configuration still uses isc-dhcp-client, unless it's
explicitly configured otherwise. So not having isc-dhcp-client installed
means it's very likely that your network connection will be broken.
 I'm worried that I'll have enough users which turn off Recommends and
will end up with no network connection.





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



signature.asc
Description: OpenPGP digital signature

Bug#805723: 4.8 has been released

[Amr Ibrahim]

https://launchpad.net/xpad/trunk/4.8.0/+download/ChangeLog

Version 4.8
* Fix: Autostart - Pads did not hide on startup when set in the preferences due 
to the tray icon not being recognized properly (#1560019)

Version 4.7
* Fix: Translations - Updated the translation template, so translaters can 
translate the new or changed strings (#1531634)
* Fix: Autostart - Partial undo of bug report #1395889, preventing autoset of 
system-wide autostart of Xpad (#1517262)
* Fix: Autostart - If Xpad is run for the first time, autostart for the current 
user will be enabled. (#1517262)
* Fix: Technical - The info file of a pad was only saved on proper exit of Xpad 
(#1534925)

Version 4.6
* New: Preferences - The ability to hide the pads from the taskbar (which was 
previously binded to window decorations) (#1029202)
* New: Preferences - The ability to hide the pads from the workspace switcher 
(which was previously binded to window decorations) (#1340331)
* Fix: CLI - the show, hide and toggle command-line options have been fixed 
(#1424081)
* Fix: Menu - Limited the length of the note names in the menu items to 20 
characters. This prevents very wide stretched menus.
* Fix: Internationalization - Added and updated the Xpad.pot file to restore 
the multi-lingual support (#1455888)
* Fix: Help - Set the ability to select and copy the help text (#1415138)
* Fix: Pad focus - Improved the showing and focussing of pads after 
minimization or creation of a new pad.
* Fix: Pad focus - After deleting a pad, it is conveniant to have the focus on 
another pad. This fix added that behavior.
* Fix: Performance - Only save the location of the pad to disk when exiting 
Xpad. This prevents a lot of disk writes when moving pads. (#1459251)
* Fix: Default settings - Window decorations are turned off by default 
(#1395889)
* Fix: Default settings - Autostart Xpad by default for all users (#1395889)
* Fix: Technical - Code cleanup - removed spaces and indentions
* Fix: Technical - Prevent deprecated error messages when not using configure 
--enable-debug=yes
* Fix: Technical - Changed preference window type from GtkDialog to GtkWindow 
(#1395309)
* Fix: Technical - Prevent race condition when application shutdown is requested
* Fix: Technical - Initialized uninitialized variable
* Fix: Technical - Replaced or removed deprecated GTK functions, such as 
gtk_alignment_new
* Fix: Technical - Removed debugging implementaton, since it was not used and 
uses unnecessary resources

Version 4.5
* New: Debug - ability to use built-in debugging functionality for bug solving 
and code improvements by Sagar Ghuge (#1389334)
* New: Systray - ability to open the help from the tray icon menu (#1406378)
* Fix: Menu - Use a more intuitive menu order and menu items by Merlijn 
Sebrechts (#1395889)
* Fix: Technical - Use standard autotools commands for deploying the help file 
by Julien Lavergne (#1402235)
* Fix: Technical - Changed the order of includes according to GTK best 
practices by Sagar Ghuge (#1366510)
* Fix: Technical - Improved head guards and function declarations by 
G_BEGIN_DECLS and G_END_DECLS by Sagar Ghuge (#1366510)
* Fix: Documentation - Improved the installation section of the README file 
with the input of Merlijn Sebrechts and Jason Helfman (#1399294)

Version 4.4
* Fix: Preferences - Redesign of preferences box to make sure it fits on small 
screens (#1333636)
* Fix: Command line - Can't find signal function address when using CLI 
parameter -f by Jaya Tiwari (#1332971)
* Fix: Technical - Clang compiler warning due to two incorrect variable 
initializations (#1395227)
* Fix: Technical - Clang compiler warning due to incorrect parameter usage 
(#1395227)
* Fix: Technical - Added GTK minimum version requirement v3.10 (#1395227)
* Fix: Technical - Seg fault on closing the xpad (#1333727)
* Fix: Technical - Code cleanup - Spaces and indentions by Ankita Patil 
(#1366510)
* Fix: Technical - Replace GtkTextBuffer with GtkSourceBuffer in preparation of 
the search functionality by Sagar Ghuge (#1349838)

Version 4.3
* New: Systray - ability to hide the tray icon (#890334)
* New: Toolbar - ability to add multiple separators (#351775)
* New: Toolbar - ability to add paste button on toolbar (#351775)
* New: Autostart - Ability to set the automatic start of Xpad in the 
Preferences menu (#405314)
* New: Autostart - Ability to set the wait for systray option in the 
Preferences menu (#405314)
* New: Autostart - Ability to delay the start of Xpad in the Preferences menu 
(#405314)
* New: Autostart - Ability to set the automatic creation of a new pad at the 
start of Xpad in the Preferences menu
* New: Autostart - Ability to set the automatic open/hide/restore of all pads 
at the start of Xpad in the Preferences menu (#405314)
* New: Shortcuts - Added shortcuts keys for New pad (CTRL-N) and Delete 
(SHIFT-DEL) and changed Redo from (CTRL-R) to (CTRL-Y)
* Fix: Toolbar - improved default toolbar items to the commonly used items
* Fix: Toolbar - 

Bug#826681: ITP: napalm-nxos -- Network Automation and Programmability Abstraction Layer with Multivendor suppor

[Vincent Bernat]

Package: wnpp
Severity: wishlist
Owner: Vincent Bernat 

* Package name: napalm-nxos
  Version : 0.2.1
  Upstream Author : David Barroso 
* URL : https://github.com/napalm-automation/napalm-nxos
* License : Apache-2.0
  Programming Lang: Python
  Description : abstraction layer for multivendor network automation - 
NX-OS support

Binary package names: python-napalm-nxos

Bug#459984: aptitude: adding bash completion

[Manuel A. Fernandez Montecelo]

Control: close -1


Hi,

2008-01-10 15:57 Daniel Burrows:

On Thu, Jan 10, 2008 at 12:39:41AM +0100, Mathieu GELI  
was heard to say:

Package: aptitude
Version: 0.4.10-1+b2
Severity: normal
Tags: patch

Completion seems to be required for some time.
Here is a quick patch that should make bash users happy for
main options.


 I'm not opposed to the concept, but if I type "aptitude ins",
bash already expands "install".  In fact, it even knows that subsequent
arguments should be expanded as package names.  This is apparently
provided by /etc/bash_completion, and it appears to handle a more
comprehensive set of options.  Moreover, in the bash package it should
be maintained by people who, unlike me, actually understand bash
completion, so that seems like a more appropriate place for it to live. :-)


Similar to Daniel Burrows, I would not have been opposed to add this
file originally, but if this file is provided by "bash-completion" and
has been for many years, I don't think that there's much sense to put it
in aptitude 8 years later.

(Besides that, there would be operational problems with aptitude trying
to take over files from other packages).


2011-12-09 05:03 Daniel Hartwig:

severity 459984 wishlist
thanks


Last point : aptitude completion data should I'm my opinion better sit
in /etc/bash_completiion.d/ as a single file instead of being stacked
in /etc/bash_completiion.


This has been the case for some time:

io:~$ dpkg -L bash-completion | grep aptitude
/etc/bash_completion.d/aptitude


Different location, but same thing:

 /usr/share/bash-completion/completions/aptitude



Anyway here is new version based on the current version in testing which
replaces dist-upgrade and upgrade with safe-upgrade and full-upgrade.  I also
added etc/bash_completion.d to aptitude.dirs and added ...


The version in bash-completion has supported safe-/full-upgrade for
some time.


I am quite sure that it's still up-to-date, we didn't change many
command line options and try to not break existing usage.


So closing the report now.


Cheers.
--
Manuel A. Fernandez Montecelo 

Bug#826680: network-manager: please move isc-dhcp-client from Depends: to Recommends:

[Daniel Kahn Gillmor]

Package: network-manager
Version: 1.2.2-1
Severity: normal

NetworkManager.conf(5) says:

-
   dhcp
   This key sets up what DHCP client NetworkManager will use. Allowed
   values are dhclient, dhcpcd, and internal. The dhclient and dhcpcd
   options require the indicated clients to be installed. The internal
   option uses a built-in DHCP client which is not currently as
   featureful as the external clients.

   If this key is missing, available DHCP clients are looked for in
   this order: dhclient, dhcpcd, internal.
-

But the network-manager package Depends: isc-dhcp-client.

Given that network-manager ships with an internal DHCP client, it seems like
isc-dhcp-client should be a Recommends: and not a Depends:

Regards,

--dkg

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

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

Versions of packages network-manager depends on:
ii  adduser3.114
ii  dbus   1.10.8-1
ii  init-system-helpers1.34
ii  isc-dhcp-client4.3.4-1
ii  libaudit1  1:2.5.2-1
ii  libbluetooth3  5.36-1+b1
ii  libc6  2.22-9
ii  libglib2.0-0   2.48.1-1
ii  libgnutls303.4.12-2
ii  libgudev-1.0-0 230-3
ii  libmm-glib01.4.14-1
ii  libndp01.6-1
ii  libnewt0.520.52.18-3
ii  libnl-3-2003.2.27-1
ii  libnm0 1.2.2-1
ii  libpam-systemd 230-2
ii  libpolkit-agent-1-00.105-15
ii  libpolkit-gobject-1-0  0.105-15
ii  libreadline6   6.3-8+b4
ii  libselinux12.5-3
ii  libsoup2.4-1   2.54.1-1
ii  libsystemd0230-2
ii  libteamdctl0   1.24-1
ii  libuuid1   2.28-5
ii  lsb-base   9.20160601
ii  policykit-10.105-15
ii  udev   230-2
ii  wpasupplicant  2.3-2.3

Versions of packages network-manager recommends:
pn  crda
pn  dnsmasq-base
ii  iptables1.6.0-2
pn  iputils-arping  
pn  modemmanager
ii  ppp 2.4.7-1+2

Versions of packages network-manager suggests:
pn  libteam-utils  

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

-- debconf-show failed

Bug#826679: pngnq: Using -e and -f options together truncates input files, then crashes

[Nils Dagsson Moskopp]

Package: pngnq
Version: 1.0-2.2+b1
Severity: normal

Dear Maintainer,

I wanted to use pngnq to downsize several screenshots. The pngnq man page
suggested to use the “-e .png” and “-f” options together, which resulted
in pngnq truncating the input files and then crashing with this error:

> pngnq - Error in pngnq.c near line 498 :
>   rwpng_read_image() error: 21

My screenshots are lost. Testing revealed the following behaviour:
Invoking “pngnq -e .png -f […]” will truncate all the input files.
It will give no output. Please remove lies from the documentation.

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

Kernel: Linux 3.13-1-686-pae (SMP w/1 CPU core)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)

Versions of packages pngnq depends on:
ii  libc62.19-19
ii  libpng16-16  1.6.21-4
ii  zlib1g   1:1.2.8.dfsg-2+b1

pngnq recommends no packages.

pngnq suggests no packages.

-- no debconf information

Bug#826153: xserver-xorg-input-synaptics: TouchPad does't work on GNOME with version 1.8.3-2

[Jean-Marc]

On Thu, 02 Jun 2016 20:53:31 +0200 Dino Trevisani  wrote:
> Package: xserver-xorg-input-synaptics
> Version: 1.8.3-2
> Severity: normal
> 
> Dear Maintainer,
> 
> Synaptic Driver and Libinput Driver are usually installed simultaneously on 
> the system in standard Debian clean install. Last version of GNOME uses only 
> Libinput Driver and accordingly touchpad does not work on GNOME because of 
> change implemented in version 1.8.3-2 of Synaptic Driver
> 
> * Cherry-pick upstream commit 59e5db, Which renames 50-synaptics.conf
>  to 70-synaptics.conf. This means the synaptic will be used driver
>  instead of the driver libinput When both are installed.

In the comment, you can see they renamed 50-synaptics.conf in 70-synaptics.conf 
because "When specifically installed by the user, the synaptics driver should 
override the system default." (dixit).

But I think they are always installed both in Debian.

It means to make Gnome works, I had to rename 70-synaptics.conf file.

I tried to purge xserver-xorg-input-synaptics but xserver-xorg-input-all 
depends on it.


> [...]

Jean-Marc 


pgpwnbEPnUtmO.pgp
Description: PGP signature

Bug#825572: Source only upload [Was: Uploaded to DELAYED/2]

[David Prévot]

Hi Mathieu,

On Tue, Jun 07, 2016 at 08:33:43PM +0200, Mathieu Parent wrote:
> 2016-06-07 0:16 GMT+02:00 David Prévot :

> > FYI, there is now a buildd available for arch:all, so you could have
> > simply dput the _source.changes without any binary package.
> 
> Yes I know. But I don't have yet a simple way to build this
> _source.changes from "gbp buildpackage". how to ?

I guess it depends on what you use behind gbp to actually build the
package. I use pbuilder, and added a hook [1] recently shared by another
DD in order to get both the _amd64.changes (to run lintian, debdiff and
all) as well as the _source.changes for the upload.

1: https://www.corsac.net/?rub=blog=1579

“debuild -S” does the trick too afterward: the binary packages will
anyway be built inside a proper chroot on the buildd system.

Regards

David


signature.asc
Description: PGP signature

Bug#435829: aptitude-[create|run]-state-bundle commands very annoying

[Manuel A. Fernandez Montecelo]

Control: tags -1 + wontfix
Control: close -1


Hi Lennart,

2007-08-03 14:45 Lennart Sorensen:

Subject: aptitude-[create|run]-state-bundle commands very annoying
Package: aptitude
Version: 0.4.6.1-1
Severity: wishlist

The new commands added to aptitude aptitude-create-state-bundle and
aptitude-run-state-bundle are really annoying.  After these were
added tab completion has become much more annoying.  Fro years I have
been able to type apticommand and get aptitude command.  Now I get
aptitudecommand unless I remember to hit a space after tab.

Given aptitude-create-state-bundle/aptitude-run-state-bundle appear to
be only for debug purposes, could they be moved to /usr/lib/aptitude or
/usr/share/aptitude so that when someone wants to do a debug state save,
they just have to type the whole path to the script.  Many other
packages put rarely needed scripts in such a place to avoid poluting the
normal PATH environment.


After almost a decade, things got worse over the years after this report
(with the binary named aptitude-curses and the now-disabled
aptitude-gtk, etc).  I think that it's too late to address this now.

The solution is simple anyway, just adding the extra space, or creating
aliases if the same mistakes happen too often, etc.

It's a common problem with command-line interfaces that this issues
arise when programs / options / files change between systems, appear in
newer versions, etc.  Even if we prevent this today, maybe tomorrow
somebody comes up with aptitude-on-steroids and "breaks" things again.

So closing the bug now.


Cheers.
--
Manuel A. Fernandez Montecelo 

Bug#826622: jessie-pu: package libdevel-declare-perl/0.006017-1+deb8u1

[Adam D. Barratt]

Control: tags -1 + pending

On Tue, 2016-06-07 at 09:11 +0100, Dominic Hargreaves wrote:
> As per #826563 the recent perl update broke libdevel-declare-perl.
> I've uploaded 0.006017-1+deb8u1 which I recommend is released through
> the stable-updates channel.

Flagged for acceptance.

Regards,

Adam

Bug#826348: jessie-pu: package ruby2.1/2.1.5-2+deb8u3

[Adam D. Barratt]

Control: tags -1 + pending

On Tue, 2016-06-07 at 12:36 +0200, Petter Reinholdtsen wrote:
> [Adam D. Barratt]
> > Judging from the seecurity tracker, CVE-2015-7551 is fixed in any Ruby 
> > versions that exist in unstable, so please go ahead.
> 
> Very good.  I uploaded the package a few seconds ago.

Flagged for acceptance.

Regards,

Adam

Bug#825979: meld: Can no longer read from named pipes

[Bálint Réczey]

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

2016-06-07 22:42 GMT+02:00 Michael Biebl :
> Am 07.06.2016 um 22:10 schrieb Bálint Réczey:
>> Control: forwarded -1 
>> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=825979
>
> Wrong C? The forwarded url is the same as this bug report.

Yes, fixed now.

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

Thanks, ;-)

Bug#826678: libc6: upgrade of libc6 overwrites libraries in active use by Upstart /sbin/init

[John Comeau]

Package: libc6
Version: 2.13-38+deb7u11
Severity: important

Dear Maintainer,

After an `apt-get upgrade` on a Debian stable system running with Upstart
as /sbin/init, `initctl list` no longer works, giving me the error "Failed
to connect to socket /com/ubuntu/upstart: Connection refused". Running
`lsof -p1` shows a number of the linked libraries were deleted and overwritten
during the libc6 upgrade.

root@vps39987:~# lsof -p1
COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME
init 1 root cwd DIR 182,564737 4096 2 /
init 1 root rtd DIR 182,564737 4096 2 /
init 1 root txt REG 182,564737 224568 2202 /sbin/init
init 1 root mem REG 182,564737 274084 
(deleted)/lib/x86_64-linux-gnu/libnss_files-2.13.so (stat: No such file or 
directory)
init 1 root mem REG 182,564737 274087 
(deleted)/lib/x86_64-linux-gnu/libnss_nis-2.13.so (stat: No such file or 
directory)
init 1 root mem REG 182,564737 273955 
(deleted)/lib/x86_64-linux-gnu/libnsl-2.13.so (stat: No such file or directory)
init 1 root mem REG 182,564737 274061 
(deleted)/lib/x86_64-linux-gnu/libnss_compat-2.13.so (stat: No such file or 
directory)
init 1 root mem REG 182,564737 273075 
(deleted)/lib/x86_64-linux-gnu/libdl-2.13.so (stat: No such file or directory)
init 1 root mem REG 182,564737 265765 
(deleted)/lib/x86_64-linux-gnu/libpthread-2.13.so (stat: No such file or 
directory)
init 1 root mem REG 182,564737 272111 
(deleted)/lib/x86_64-linux-gnu/libc-2.13.so (stat: No such file or directory)
init 1 root mem REG 182,564737 274113 
(deleted)/lib/x86_64-linux-gnu/librt-2.13.so (stat: No such file or directory)
init 1 root mem REG 182,564737 39744 262559 
/lib/x86_64-linux-gnu/libjson.so.0.1.0
init 1 root mem REG 182,564737 126232 262470 
/lib/x86_64-linux-gnu/libselinux.so.1
init 1 root mem REG 182,564737 286488 264017 
/lib/x86_64-linux-gnu/libdbus-1.so.3.7.2
init 1 root mem REG 182,564737 38848 264236 /lib/libnih-dbus.so.1.0.0
init 1 root mem REG 182,564737 96216 264225 /lib/libnih.so.1.0.0
init 1 root mem REG 182,564737 272094 (deleted)/lib/x86_64-linux-gnu/ld-2.13.so 
(stat: No such file or directory)
init 1 root 0u CHR 1,3 0t0 95 /dev/null
init 1 root 1u CHR 1,3 0t0 95 /dev/null
init 1 root 2u CHR 1,3 0t0 95 /dev/null
init 1 root 3r FIFO 0,8 0t0 212010621 pipe
init 1 root 4w FIFO 0,8 0t0 212010621 pipe
init 1 root 5r DIR 0,10 0 1 inotify
init 1 root 6r DIR 0,10 0 1 inotify
init 1 root 8u unix 0x880425366100 0t0 212012641 socket
init 1 root 9r DIR 0,10 0 1 inotify
init 1 root 10r FIFO 0,8 0t0 97808 pipe

`reboot` was ineffective. `reboot -f` may work, but I am waiting on my client's
go-ahead, as the server seems to be otherwise working, and it's now the middle
of the business day.

I'm not sure what the solution would be. Just making sure you're aware of the
situation.

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

Kernel: Linux 2.6.32-042stab111.12 (SMP w/2 CPU cores)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages libc6 depends on:
ii  libc-bin  2.13-38+deb7u11
ii  libgcc1   1:4.7.2-5

libc6 recommends no packages.

Versions of packages libc6 suggests:
ii  debconf [debconf-2.0]  1.5.49
pn  glibc-doc  
ii  locales2.13-38+deb7u11

-- debconf information:
  glibc/upgrade: true
  glibc/restart-services:
  libraries/restart-without-asking: false
  glibc/disable-screensaver:
  glibc/restart-failed:

Bug#825112: (no subject)

[Barry Warsaw]

On Jun 07, 2016, at 10:00 PM, Gordon Ball wrote:

>> The packaging looks really good.  I noticed the setting of http_proxy in
>> override_dh_auto_build.  You probably don't strictly need that because I
>> believe pybuild does that automatically.  It can't hurt though and some
>> maintainers prefer to be explicit about that.  
>
>The http_proxy bit was cargo-culted from
>https://wiki.debian.org/Python/LibraryStyleGuide

Ah, I'd forgotten that this was still needed for sphinx-build.

>Good idea. The test suite is extensive but it hadn't occurred to me that
>it is entirely based on importing it as a library rather than actually
>running the binary. I'd tested the installed package but clearly on a
>system with python3-pkg-resources already installed.
>
>I found that this fails in an autopkgtest schroot though - xonsh fails
>to start if $HOME is not writable (which is possibly a bug), so I've
>added a wrapper which sets $HOME=$ADTTMP (and added a couple of extra
>examples).

Looks great, much better than my quick hack. :)

>On hold for the moment then. I'm happy to have it listed as team maintained
>at a future point though. I'm already subscribed to debian-python, I'll apply
>to join the relevant teams soon.

Cool.  It'll be easy to move later.

One possible minor issue is that DPMT did adopt git-dpm for packages, but
since that decision several years ago, git-dpm has apparently stopped being
developed.  It hasn't quite bitrotted yet, but I am advocating that DPMT drop
git-dpm and use gbp-pq for patch management.  I don't see any reason other
than (hopefully temporary) consistency for PAPT to adopt git-dpm once that
switch happens.  We'll have to see what the team says.

For now, let's just assume gbp-pq will be adopted for PAPT.

>Given the script is generated based on `entry_points` in setup.py,
>shouldn't this dependency be generated by pybuild/dh_python?

Actually, that should come from an install_requires section or a
requirements.txt file.  I don't see either of those in the xonsh repo.  But
also pkg_resources is kind of a special case on Debian.  It really comes as
part of setuptools, but in Debian we split it out into a separate binary
package, so I don't know that it would be automatically detected in any case.
Clearly it doesn't since it crashes without an explicit Depends, but we'd have
to ask Piotr on debian-python@ to know whether that's intended behavior or
not.  TBH, I always just add it explicitly.

>There are a couple of remaining (possibly non-) issues:
>
> * lintian reports privacy-breach-generic on the documentation (google
>webfont links). I can't see this explicitly configured anywhere in the
>rst files or conf.py, so I *think* this is being added by
>sphinx/cloud-sptheme

Interesting.  I built the package from the git repo on unstable and ran
lintian over the amd64.changes file.  I don't get any lintian warnings.

> * building the documentation generates (I think) inconsequential errors
>since the xonsh pygments lexer is not available at build time; this
>could be fixed by build-depending on itself, but I'm not sure this is
>worth adding a dependency cycle for.

I see that too.  Agreed it's probably not worth worrying about right now.

> * xonsh supports installing itself as a jupyter kernel, which I'm
>interested to include but for the moment (parts of) jupyter is only in
>experimental, so it can probably wait until a future xonsh upload

+1

Everything else lgtm.  Let me know when you want me to sponsor an upload; I'm
happy to do it any time.  It will have to go through NEW of course, but it
would be nice to get this into peoples hands soon.  (I know I'm not the only
Debuntunista who wants to use it after watching the Pycon talk. :)


pgpxquwJZvesq.pgp
Description: OpenPGP digital signature

Bug#825979: meld: Can no longer read from named pipes

[Michael Biebl]

Am 07.06.2016 um 22:10 schrieb Bálint Réczey:
> Control: forwarded -1 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=825979

Wrong C? The forwarded url is the same as this bug report.


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



signature.asc
Description: OpenPGP digital signature

Bug#826674: gem2deb: FTBFS: test: running dh-make-ruby against a directory should get the package name correctly. :F

[Antonio Terceiro]

On Tue, Jun 07, 2016 at 09:17:06PM +0200, Andreas Beckmann wrote:
> Source: gem2deb
> Version: 0.30.2
> Severity: serious
> Justification: fails to build from source
> 
> Hi,
> 
> gem2deb FTBFS everywhere:
> https://buildd.debian.org/status/package.php?p=gem2deb=unstable
> 
>   test: running dh-make-ruby against a directory should get the package name 
> correctly. :F
> ===
> Failure: test: running dh-make-ruby against a directory should get the 
> package name correctly. (DhMakeRubyTest)
> /«PKGBUILDDIR»/test/unit/dh_make_ruby_test.rb:109:in `block (2 levels) in 
> '
> <["ruby-simplegit"]> expected but was
> <[]>
> 
> diff:
> ? ["ruby-simplegit"]
> ===
> : (0.058675)

At first I could not reproduce this, and was only able to when I moved
my ~/.sbuildrc away. It includes only the following:

$build_source = 1;
$build_arch_all = 1;

I still have no idea why any of those would make the build fail, since
gem2deb just moved to providing only arch:any packages. in $build_source
should never make any difference, and neither should $build_arch_all. I
am still puzzled.


signature.asc
Description: PGP signature

Bug#781324: Feature request: dpkg logging to syslog

[Michael Herold]

Would be really nice to have this in stretch.

Not sure if there is a safe way to leave the syslog open. The following
patch works for me (--log syslog).diff --git a/lib/dpkg/log.c b/lib/dpkg/log.c
index 3079f3c..371ec5e 100644
--- a/lib/dpkg/log.c
+++ b/lib/dpkg/log.c
@@ -26,6 +26,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include 
 #include 
@@ -46,27 +47,35 @@ log_message(const char *fmt, ...)
 	if (!log_file)
 		return;
 
-	if (!logfd) {
-		logfd = fopen(log_file, "a");
-		if (!logfd) {
-			notice(_("could not open log '%s': %s"),
-			   log_file, strerror(errno));
-			log_file = NULL;
-			return;
-		}
-		setlinebuf(logfd);
-		setcloexec(fileno(logfd), log_file);
-	}
-
 	va_start(args, fmt);
 	varbuf_reset();
 	varbuf_vprintf(, fmt, args);
 	va_end(args);
 
-	time();
-	strftime(time_str, sizeof(time_str), "%Y-%m-%d %H:%M:%S",
-	 localtime());
-	fprintf(logfd, "%s %s\n", time_str, log.buf);
+	if (strcmp(log_file, "syslog") == 0) {
+		/* log to syslog */
+		openlog("dpkg", LOG_PID, LOG_USER);
+		syslog(LOG_INFO, "%s", log.buf);
+		closelog();
+	} else {
+		/* log to file */
+		if (!logfd) {
+			logfd = fopen(log_file, "a");
+			if (!logfd) {
+notice(_("could not open log '%s': %s"),
+	   log_file, strerror(errno));
+log_file = NULL;
+return;
+			}
+			setlinebuf(logfd);
+			setcloexec(fileno(logfd), log_file);
+		}
+
+		time();
+		strftime(time_str, sizeof(time_str), "%Y-%m-%d %H:%M:%S",
+			 localtime());
+		fprintf(logfd, "%s %s\n", time_str, log.buf);
+	}
 }
 
 struct pipef {

Bug#519867: [Buildd-tools-devel] Bug#519867: sbuild: run edos-debcheck in case of build failure due to dependency installation

[Johannes Schauer]

Hi,

On Fri, 25 Dec 2015 19:44:09 +0100 Johannes Schauer  wrote:
> In summary, the following should work:
> 
> apt-cache dumpavail | dose-debcheck -v -f -e 
> sbuild-build-depends-yourpackage-dummy
> 
> Together with --build-deps-failed-commands you can create a hook which does
> exactly what this bug requests. Would this be sufficient to fix this bug?

thinking about this a bit more, the above should work but requires
dose-debcheck and its dependencies to be installed inside the chroot. But
installing additional packages might influence the result and should thus not
be done.

Instead, the output of "apt-cache dumpavail" inside the chroot should be piped
to dose-debcheck installed outside the chroot. Unfortunately, the
--build-deps-failed-commands are run inside the chroot and do not offer running
anything outside the chroot.

So as originally suggested, it might be necessary to add the functionality to
sbuild itself. Maybe by sbuild opportunistically running dose-debcheck after
dependency installation failed and sbuild sees the dose-debcheck binary on the
host?

Thanks!

cheers, josch


signature.asc
Description: signature

Bug#814479: libbusiness-creditcard-perl: New upstream version 0.35 (including new MasterCard ranges)

[gregor herrmann]

On Tue, 07 Jun 2016 12:12:42 -0700, Ivan Kohler wrote:

> The crucial point is that _we do not backport changes and create new, 
> un-QAed forks for any of this other "volatile" software like spam/virus 
> scanners and video downloads, so it seems to me that asking for it in the 
> case of libbusiness-creditcard-perl is out-of-line with our practices and 
> procedures for comparable things.  We pull in new versions of e.g. 
> spamassassin and ClamAV for the exact same reasons as this package needs 
> to be updated.

That's correct for some packages but not for others. E.g.
libdatetime-timezone-perl only updates the actual timezone data but
doesn't use new upstream releases with code changes.
 
> Specifially in regard to the desire to "avoid accidental breakage": It 
> seems that using the upstream 0.35 version, which has been QAed with my 
> company's production customers and by CPAN users for half a year, is the 
> more conservative, careful action and is the least likely to break 
> anything.  Backporting updates to an old version and creating a new 
> Debian-specific fork, which will be unable to get any kind of comparable 
> real-world testing, seems to be the riskier action that is more likely to 
> cause breakage.

Right, that's the valid counter-argument. And uploads to stable-* are
always about finding a balance.
 
> > That's true for some packages where backporting fixes is non-trivial,
> > and AFAIK noone is happy with that. In most cases the changes are
> > small and targetted.
[..]
> WRT your assertion that noone is happy with that, FWIW, I would disagree.  
> I'm very happy that my mail server gets updated versions of spamassassin 
> and ClamAV.  I'm glad we don't use our limited volunteer resources trying 
> to try to support older, less-functional, non-QAed/patched versions of 
> those packages on my stable machines like they were stable security 
> updates.

That's of course a valid point as well.
 
> > I totally agree that an update of libbusiness-creditcard-perl in
> > jessie{,-updates} (wheezy is gone by now anyway) makes sense, I just
> > want to prepare a proposal for the release team that doesn't make
> > them cringe :) That's why I'd like to strip down
> > https://metacpan.org/diff/file?target=IVAN%2FBusiness-CreditCard-0.35%2F=IVAN%2FBusiness-CreditCard-0.33%2F
> > to the necessary part(s) before contacting them.
> As the sole purpose of the module is to validate and identify credit 
> cards, few (if any) would even be omitted.  Since 0.33, the version in 
> jessie, _every change_ has been for the purpose of staying up-to-date 
> with real world requirements such as recognizing new cards or processing 
> agreements.  Here is the relevant section of the Changes file.
[..]
> What would you omit in a backport for jessie?  I think everything needs 
> to be included, they're all updates to keep up with the real world.

I absolutely agree that every functional change needs to be included;
but not the noise from build tools and unrelated changes in the
documentation.
 
> As with all of us in the volunteer effort, I only have a limited amount 
> of time and motivation to I only have so much time and effort to devote 
> to Debian work.  In this case, I don't personally anticipate motivating 
> for more work creating a Debian-specific, un-QAed backport in order to 
> keep release managers from "cringing".

I didn't mean to imply that it's you who has to make the changes :)
 
> For the sake of our users and free softwre (you know, our priorities), I 
> would respectfully suggest the release managers should "cringe" and deal 
> with this course of action as the least risky of the less-than-ideal 
> alternatives, with more than ample precedent (e.g. spamassassin, ClamAV, 
> etc.).

If I'm to one who talks to them I'd prefer to prepare the potential
upload in a way that I know makes it easy for them to review.

And to speed this all up a bit :) I've pushed a jessie branch to our
git repo:
https://anonscm.debian.org/cgit/pkg-perl/packages/libbusiness-creditcard-perl.git/log/?h=jessie
where I left out the non-functional changes and split the rest into
three logical patches.

What do you think? If this looks okay to you I'm happy to proceed.
 
> FWIW, we are just a few months away from the October 2016 "deadline" when 
> MasterCard is expected to start issuing cards with the new ranges.  If we 
> have not figured out how to accept these changes by then, our users could 
> start seeing their web sites refuse to accept real-world cards and lose 
> sales and money.  That would be a shame.

Thanks for pointing out this deadline; I'm confident we have
everything sorted by then :)


Cheers,
gregor 

-- 
 .''`.  Homepage https://info.comodo.priv.at/ - OpenPGP key 0xBB3A68018649AA06
 : :' : Debian GNU/Linux user, admin, and developer -  https://www.debian.org/
 `. `'  Member of VIBE!AT & SPI, fellow of the Free Software Foundation Europe
   `-   NP: Pink Floyd: Welcome To The Machine


signature.asc

Bug#824935: sbuild: better support for running autopkgtests

[Johannes Schauer]

Control: tag -1 + moreinfo

Hi,

On Sat, 21 May 2016 23:11:03 +0900 Sean Whitton  
wrote:
> It is possible to run autopkgtests by invoking adt-run as an sbuild
> post-build-command, as described on the wiki.[1]  However, it would be
> better if sbuild could be configured to invoke adt-run as an independent
> stage of the build, like the stages for lintian and piuparts.

I see your point. Unfortunately, there is a big practical consideration for
which I don't see an easy solution. To be able to run autopkgtests, one needs
to have a chroot configured, needs to know which backend to use and needs to
know which distribution to use. The sbuild wiki just plainly assumes that the
user is using schroot, has a chroot configured and is always building for
unstable. But people using sbuild are neither only building for unstable, nor
do they necessarily use the schroot backend and might thus not have a
schroot-style chroot configured.

Now one could say that one could add a similar command line argument like
--piuparts-opts for piuparts or --lintian-opts for lintian. But this then would
mean that users that do not use the defaults (schroot and unstable) would have
to pass these options all the time which gets us back to the original situation
where users had to manually add a --post-build-command.

So is there an elegant way to solve this dilemma and execute adt-run with the
right options with the least amount of user intervention per build?

Thanks!

cheers, josch


signature.asc
Description: signature

Bug#825979: meld: Can no longer read from named pipes

[Bálint Réczey]

Control: forwarded -1 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=825979
Control: tags -1 confirmed upstream

Hi Kyanos,

2016-06-01 4:56 GMT+02:00 Kyanos :
> Package: meld
> Version: 3.16.0-1
> Severity: wishlist
>
> Dear Maintainer,
>
> Since the upgrade to 3.16.0, I cannot compare text read from pipes, such
> as those created from process substitution. When I try to use one, Meld
> says:
>
>> There was a problem opening the file "/dev/fd/63"
>> Not a regular file
>
> I have used process substitution for such things as:
>
> Comparing two gzip'ed text files:
> $ meld <(gunzip -c file1.txt.gz) <(gunzip -c file2.txt.gz)
>
> Comparing a Vim buffer to the file on disk:
> :w !meld % <(cat)
>
> (In the second example, I cannot use ":w !meld % -" because Meld does
> not recognize "-" as standard input.)
>
> If restoring this ability is infeasible, I will understand. Thank you
> for your consideration.

Thank you for the bug report.
I could reproduce it and found that it has been reported to upstream already.

Cheers,
Balint

Bug#814479: Pending fixes for bugs in the libbusiness-creditcard-perl package

[pkg-perl-maintainers]

tag 814479 + pending
thanks

Some bugs in the libbusiness-creditcard-perl package are closed in
revision 423278362ee3a9d2bb68c0b668318a9402044e4d in branch ' 
jessie' by gregor herrmann

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

Commit message:

Backport changes from upstream releases 0.34 and 0.35

to adjust to changes in credit card ranges and processing of various
companies.

Add the following patches:
- ranges.patch: adjust credit card number ranges
- receipt_cardtype.patch: add new function for new Discover receipt
  requirements
- docs.patch: update documentation about processing of different cards in
  various countries

Closes: #814479

Bug#752790: kexec-tools: Please support /etc/default/kexec.d facility

[intrigeri]

Khalid Aziz wrote (07 Jun 2016 19:27:05 GMT) :
> Thanks for the reminder. I am working on it now.

Excellent :)

Bug#825112: (no subject)

[Gordon Ball]

On 07/06/16 18:22, Barry Warsaw wrote:
> On Jun 07, 2016, at 10:35 AM, Gordon Ball wrote:
> 
>> Packaging has been done and can be found in collab-maint [1]
>> (git-buildpackage+pristine-tar format [2]). Current version is
>> 0.3.3+dfsg. Builds for xenial/yakkety can be found in a PPA [3].
> 
> Cool.  I grabbed and looked at the collab branch.
> 
>> The packaging and test suite appear to work, but I've held off trying to
>> get it uploaded since there have been several minor versions in quick
>> succession recently (0.3.0 .. 0.3.3 in the last two weeks) and I was
>> waiting to see if it would settle.
> 
> Hopefully that will calm down after the rush of Pycon.
> 
>> Would you be willing to review and possibly sponsor?
> 
> For sure.  Would you consider adding me to Uploaders?

Done.

> 
> The packaging looks really good.  I noticed the setting of http_proxy in
> override_dh_auto_build.  You probably don't strictly need that because I
> believe pybuild does that automatically.  It can't hurt though and some
> maintainers prefer to be explicit about that.

The http_proxy bit was cargo-culted from
https://wiki.debian.org/Python/LibraryStyleGuide

> 
> It might be good to add an autopkgtest that actually runs the installed xonsh
> as a sanity check.  Maybe even just run a simple xonsh script?  See below.

Good idea. The test suite is extensive but it hadn't occurred to me that
it is entirely based on importing it as a library rather than actually
running the binary. I'd tested the installed package but clearly on a
system with python3-pkg-resources already installed.

I found that this fails in an autopkgtest schroot though - xonsh fails
to start if $HOME is not writable (which is possibly a bug), so I've
added a wrapper which sets $HOME=$ADTTMP (and added a couple of extra
examples).

> 
> Should debian/xonsh.1 be generated from help2man so it doesn't get out of
> sync?

I've implemented this (help2man plus some added sections).

> 
>> [2]: This should probably be under DPMT and git-dpm, but I'm not (yet) a
>> team member
> 
> You should definitely join debian-python!  However, as this is an application
> and not a library, it would probably be best to put it under PAPT.  The
> problem there of course is that PAPT hasn't switched to git yet :(.  I'm
> hoping tumbleweed and others might make that happen at or after debconf2016.
> Until that happens, collab-maint is fine.

On hold for the moment then. I'm happy to have it listed as team
maintained at a future point though. I'm already subscribed to
debian-python, I'll apply to join the relevant teams soon.

> 
>> [3]: ppa:chronitis/misc (contains a variety of other stuff)
> 
> Cool!
> 
> /me builds
> 
> Love the logo output during `python3.5 setup.py clean` ;)
> 
> I think you need to explicitly depend on python3-pkg-resources, otherwise:

Given the script is generated based on `entry_points` in setup.py,
shouldn't this dependency be generated by pybuild/dh_python?
> 
> # xonsh
> Traceback (most recent call last):
>   File "/usr/bin/xonsh", line 5, in 
> from pkg_resources import load_entry_point
> ImportError: No module named 'pkg_resources'
> 
> I made a few of the suggested changes (adding the Depends and an autopkgtest)
> and pushed it to the `review` branch on collab-maint.  Let me know what you
> think.  Great work, and I'm happy to sponsor and/or comaintain xonsh!
> 

Merged (and further modified as noted above).

There are a couple of remaining (possibly non-) issues:

 * lintian reports privacy-breach-generic on the documentation (google
webfont links). I can't see this explicitly configured anywhere in the
rst files or conf.py, so I *think* this is being added by
sphinx/cloud-sptheme
 * building the documentation generates (I think) inconsequential errors
since the xonsh pygments lexer is not available at build time; this
could be fixed by build-depending on itself, but I'm not sure this is
worth adding a dependency cycle for.
 * xonsh supports installing itself as a jupyter kernel, which I'm
interested to include but for the moment (parts of) jupyter is only in
experimental, so it can probably wait until a future xonsh upload

Bug#826677: cadencii: please make the build reproducible

[Chris Lamb]

Source: cadencii
Version: 3.3.9+svn20110818.r1732-4
Severity: wishlist
Tags: patch
User: reproducible-bui...@lists.alioth.debian.org
Usertags: timestamps
X-Debbugs-Cc: reproducible-bui...@lists.alioth.debian.org

Hi,

Whilst working on the "reproducible builds" effort [0], we noticed that 
cadencii could not be built reproducibly.

Patch attached.

 [0] https://wiki.debian.org/ReproducibleBuilds


Regards,

-- 
  ,''`.
 : :'  : Chris Lamb
 `. `'`  la...@debian.org / chris-lamb.co.uk
   `-
--- a/debian/patches/04-reproducible-build.patch1970-01-01 
01:00:00.0 +0100
--- b/debian/patches/04-reproducible-build.patch2016-06-07 
20:50:55.167084083 +0100
@@ -0,0 +1,11 @@
+--- cadencii-3.3.9+svn20110818.r1732.orig/replace_path_separator.pl
 cadencii-3.3.9+svn20110818.r1732/replace_path_separator.pl
+@@ -105,7 +105,7 @@ namespace org.kbinani.cadencii
+ {
+ __EOD__
+ 
+-foreach $key ( keys %directive )
++foreach $key ( sort keys %directive )
+ {
+ my $tbool = $directive{$key} == 0 ? "false" : "true";
+ print CFG "mDirectives.put( \"$key\", $tbool );\n";
--- a/debian/patches/series 2016-06-07 20:49:16.273750883 +0100
--- b/debian/patches/series 2016-06-07 20:50:52.463047408 +0100
@@ -1,3 +1,4 @@
 01-svn-r1744.patch
 02-vconnect.patch
 03-java8-compatibility.patch
+04-reproducible-build.patch
--- a/debian/source/include-binaries1970-01-01 01:00:00.0 +0100
--- b/debian/source/include-binaries2016-06-07 20:50:45.854957769 +0100
@@ -0,0 +1 @@
+cadencii-build-deps_3.3.9+svn20110818.r1732-4_all.deb

Bug#826617: Aw: Re: Bug#826617: Re: Bug#826617: initramfs-tools: intel microcode: 149 EOF on update

[Ben Hutchings]

[Please reply to all, not just to me]

On Tue, 2016-06-07 at 19:30 +0200, phaenol...@web.de wrote:
[...]
> 1
> "dpkg -l intel-microcode" output:
> ||/ Name   Version  Architektur  Beschreibung
> +++-==---
> =
> ii  intel-microcod 3.20150121.1 i386 Processor microcode
> firmware for
>  
> 2
> "debsums -c intel-microcode && echo OK" output:
> /usr/share/initramfs-tools/hooks/intel_microcode
[...]

OK, so that file somehow got corrupted.  You should reinstall intel-
microcode.  But first you need to finish the upgrade of initramfs-
tools.  I think this sequence of commands will sort it out:

    rm /usr/share/initramfs-tools/hooks/intel_microcode
    dpkg --configure --pending
    apt install --reinstall intel-microcode

Ben.


-- 
Ben Hutchings
When in doubt, use brute force. - Ken Thompson


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

Bug#826676: python-openstackclient: please make the build reproducible

[Chris Lamb]

Source: python-openstackclient
Version: 2.3.0-2
Severity: wishlist
Tags: patch
User: reproducible-bui...@lists.alioth.debian.org
Usertags: timestamps
X-Debbugs-Cc: reproducible-bui...@lists.alioth.debian.org

Hi,

Whilst working on the "reproducible builds" effort [0], we noticed that 
python-openstackclient could not be built reproducibly.

Patch attached. It should probably be upstreamed.

 [0] https://wiki.debian.org/ReproducibleBuilds


Regards,

-- 
  ,''`.
 : :'  : Chris Lamb
 `. `'`  la...@debian.org / chris-lamb.co.uk
   `-
--- a/debian/patches/0001-reproducible-build.patch  1970-01-01 
01:00:00.0 +0100
--- b/debian/patches/0001-reproducible-build.patch  2016-06-07 
20:38:57.258484217 +0100
@@ -0,0 +1,11 @@
+--- python-openstackclient-2.3.0.orig/doc/source/conf.py
 python-openstackclient-2.3.0/doc/source/conf.py
+@@ -80,7 +80,7 @@ release = version_info.release_string()
+ 
+ # List of patterns, relative to source directory, that match files and
+ # directories to ignore when looking for source files.
+-exclude_patterns = []
++exclude_patterns = ['**tests**']
+ 
+ # The reST default role (used for this markup: `text`) to use for all
+ # documents.
--- a/debian/patches/series 1970-01-01 01:00:00.0 +0100
--- b/debian/patches/series 2016-06-07 20:29:40.147804720 +0100
@@ -0,0 +1 @@
+0001-reproducible-build.patch
--- a/debian/source/include-binaries1970-01-01 01:00:00.0 +0100
--- b/debian/source/include-binaries2016-06-07 20:29:33.483723940 +0100
@@ -0,0 +1 @@
+python-openstackclient-build-deps_2.3.0-2_all.deb

Bug#826573: cme: drops build profiles on dependencies

[Dominique Dumont]

Ouch, I need to rework the internal representation of a dependency to properly 
support build profiles. This will take some time...

See also #702792 and https://wiki.debian.org/BuildProfileSpec

All the best

-- 
 https://github.com/dod38fr/   -o- http://search.cpan.org/~ddumont/
http://ddumont.wordpress.com/  -o-   irc: dod at irc.debian.org

Bug#826675: rapid-photo-downloader: Wrong sort order

[Christian von Kietzell]

Package: rapid-photo-downloader
Version: 0.4.11-1
Severity: normal

Dear Maintainer,

rpd sorts the files to import incorrectly, resulting in file numbering that
isn't chronological (with respect to the files to import). Its internally used
modification time, which files are sorted by, is only accurate to full
seconds. I checked this by printing the filename and modification time in
scan.py.
"touch"-ing all files in (filename) order and sleeping at least one second in
between calls makes rpd sort them correctly.

Usually, this isn't really a problem when photos are downloaded from a memory
card directly. If you bulk-copy them to a different directory first, it's
easily triggered, though. On the other hand I can see how the same behaviour
might come about with cameras with high framerates and photos shot in burst
mode.

Hope this can be fixed somehow as it is a little annoying.


Cheers,
  Chris


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

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

Versions of packages rapid-photo-downloader depends on:
ii  exiftran2.10-2+b2
ii  exiv2   0.25-3
ii  gnome-icon-theme3.12.0-2
ii  libimage-exiftool-perl  10.15-1
ii  librsvg2-common 2.40.15-1
ii  python-dbus 1.2.4-1
ii  python-gconf2.28.1+dfsg-1.1
ii  python-glade2   2.24.0-4
ii  python-gnome2   2.28.1+dfsg-1.1
ii  python-gtk2 2.24.0-4
ii  python-imaging  3.2.0-2
ii  python-notify   0.1.1-4
ii  python-pyexiv2  0.3.2-8+b1
ii  python2.7   2.7.11-11
pn  python:any  

Versions of packages rapid-photo-downloader recommends:
ii  ffmpegthumbnailer2.1.1-0.1+b2
ii  python-hachoir-metadata  1.3.3-2
ii  python-kaa-metadata  0.7.7+svn4596-4

rapid-photo-downloader suggests no packages.

-- no debconf information

Bug#823076: cryptmount: Fix LSB init output

[R.Penney]

Hello Guillem,
Thanks for your suggested improvement to the cryptmount init.d script,
and for your helpful patch.

I have just released version 5.2.1 of cryptmount, which incorporates
your improvements. I hope this will soon be available as a Debian
package.

Kind regards,
RW Penney

Bug#825214: u-boot-sunxi: Fails to properly boot Linux on A20-OLinuXino-Lime2

[Vagrant Cascadian]

Control: fixed 825214 2016.05+dfsg1-1

On 2016-06-01, Karsten Merker wrote:
>> > On 2016-05-24, Benedikt Wildenhain wrote:
>> > > The last version of u-boot-sunxi which enabled the system to boot
>> > > properly was 2015.10+dfsg1-3. Switching to Linux 4.6.0 from experimental
>> > > did not help.
> [...]
>> IIRC during the v2016.03 development cycle there was some issue with
>> enabling/disabling an unused voltage regulator or setting/not setting
>> the regulator to a specific voltage that resulted in kernel hangs on
>> certain boards while trying to load a certain kernel module (I2C driver?).
>> That could be the problem we are seeing here, although I would need
>> to look through the mailing list archives for more specific
>> information.

> cherry-picking affa020559bca31d6531e19cb1f009c22705a73d (which
> addresses the aforementioned regulator issues) from v2016.05 on
> top of v2015.03 solved the issue for me,

Thanks for tracking that down!


> but I am unsure whether
> uploading another v2015.03 package with that patch applied would
> make sense now.  V2016.05 is already packaged, includes this fix
> and in addition to that also has a number of phy handling fixes
> that should solve the network stability issues with gigabit
> ethernet links on the Lime2, so it probably makes more sense to
> aim at getting v2016.05 into unstable in the near future than at
> patching v2016.03 further.

I've hesitated uploading v2016.05 to unstable as I've been experiencing
regressions with other boards (am57xx_evm and firefly-rk3288). I just
uploaded 2016.07-rc1 to experimental, after testing on several boards,
and it fixes am57xx_evm at least. That will need some wider regression
testing, too...


live well,
  vagrant


signature.asc
Description: PGP signature

Bug#824582: [buildd-tools-devel] Bug#824582: wishlist: sbuild-setup testdrive example

[Johannes Schauer]

Hi,

Quoting Geert Stappers (2016-05-17 20:57:30)
> It would be nice that manual page get a testdrive example

I still don't fully understand what you find lacking, but would the following
section in the sbuild man page fix this bug:


EXAMPLES
   Before  you use sbuild for the first time, you have to do some setup de‐
   pending on the chroot backend you are using. The default backend is sch‐
   root.  To use sbuild with the schroot backend, you need to add your user
   to the sbuild group and create a schroot chroot. The latter can  be  ac‐
   complished by using sbuild-createchroot(8). If the chroot contains a De‐
   bian derivative with apt (<< 0.8.16~exp3), or a  Debian  release  before
   Wheezy,  then  it is also required to create gpg key pairs using sbuild-
   update --keygen. After this one time setup, you can now  use  sbuild  to
   build packages like this:

   % sbuild -d unstable bash

   Or on a .dsc:

   % sbuild -d unstable bash.dsc

   Or  from within an unpacked source package (the -d parameter is not nec‐
   essary here because the distribution is inferred from debian/copyright):

   % sbuild


Thanks!

cheers, josch


signature.asc
Description: signature

Bug#816667: www.debian.org: please make the documentation from dbconfig-common available

[Paul Gevers]

The world has turned a couple of times...

On Thu, 03 Mar 2016 20:43:08 +0100 Paul Gevers  wrote:
> As suggested by Paul Wise in a response to an e-mail to debian-admin@l.d.o, I
> would like to have the content that currently lives here:
> https://people.debian.org/~seanius/policy/dbapp-policy.html/
> https://people.debian.org/~seanius/policy/dbconfig-common.html/
> https://people.debian.org/~seanius/policy/dbconfig-common-design.html
> to be extracted from the dbconfig-common binary package and made available on
> https://www.debian.org/doc/devel-manuals or in the ../packaging-manuals. The
> current webpages are out-dated and seanius is retired from Debian so won't
> update anymore.

Do you think it is possible to fix this? If not on a short term, could I
get access to manually update the documentation, such that the old
documentation can be replaced?

Paul



signature.asc
Description: OpenPGP digital signature

Bug#752790: kexec-tools: Please support /etc/default/kexec.d facility

[Khalid Aziz]

On 06/03/2016 06:03 AM, intrigeri wrote:
> Hi Khalid,
> 
> Khalid Aziz wrote (19 Jun 2015 14:41:14 GMT) :
>> On 06/19/2015 04:08 AM, intrigeri wrote:
>>> a year later: ping regarding this request?
> 
>> I didn't want to make this change at the time when we were so close to 
>> jessie freeze.
> 
> Makes sense!
> 
>> Now that jessie is released, I am working on updating kexec-tools package and
>> addressing existing bug reports. I am testing new version of kexec-tools 
>> right now
>> and once it clears my tests, I will upload it. After that I will look into 
>> this as
>> well as other bug reports.
> 
> So, another year later: ping regarding this request? The patch I've
> initially provided still applies cleanly on top of current sid
> version.
> 
> If you don't mind, I could test this extensively on sid and NMU (I
> understand a NMU would be unusual for a wishlist bug, but this has
> been blocking other work I'm doing for almost two years now, that's
> why I'm proposing this course of action :)
> 
> Cheers,
> --
> intrigeri
> 

Hi Intrigeri,

Thanks for the reminder. I am working on it now.

--
Khalid

Bug#826651: mirror listing update for mirror.dkm.cz

[houmles]

Hi Donald,

I am new admin. Tomas Zvala, unfortunately, is already out of business.
You can leave /security/ as we still mirroring it directly from 
security.debian.org. You just don't have a column for it in your update form.
For now we will leave a mirror as leaf. Mayber later I will look into it but as 
there is already one primary-push mirror in CZ I think it's not necessary, 
right?

Lukas

On 07/06, Donald Norwood wrote:
> Hi Lukas,
> 
> To confirm:
> 
> Moving from Push-Secondary to Leaf.
> Dropping all /security/
> New upstream(s)
> Updates 4
> 
> Is the maintainer still Tomas Zvala?
> 
> Best regards,
> 
> Donald Norwood
> -Debian Mirrors Team
> 
> On Tue, 07 Jun 2016 13:42:56 + "Lukas Krudl"  wrote:
> > Package: mirrors
> > Severity: minor
> > User: mirr...@packages.debian.org
> > Usertags: mirror-list
> > 
> > Submission-Type: update
> > Site: mirror.dkm.cz
> > Type: leaf
> > Archive-architecture: ALL 
> > Archive-ftp: /debian/
> > Archive-http: /debian/
> > Archive-rsync: debian/
> > CDImage-ftp: /debian-cd/
> > CDImage-http: /debian-cd/
> > CDImage-rsync: debian-cd/
> > IPv6: yes
> > Archive-upstream: ftp.cz.debian.org
> > CDImage-upstream: ftp.cz.debian.org
> > Updates: four
> > Maintainer: Lukas Krudl 
> > Country: CZ Czech Republic
> > Location: Prague, Czech Republic
> > Sponsor: UPC Czech Republic s.r.o. https://www.upc.cz/
> > 
> > 
> 

Bug#826536: clarify SHA-1 support beyond 2016

[Stefan Fritsch]

On Monday 06 June 2016 08:24:50, Daniel Pocock wrote:
> CAs, browser vendors and other software developers are actively
> disabling SHA-1 support and shifting to the SHA-2 (SHA-256) digest
> algorithm.

There are two relevant uses of SHA-1 that I know of.

As MAC algorithm in the TLS cipher suite. There the current policy is 
to use whatever openssl offers as configuration alias "HIGH". 
Currently this includes ciphers with SHA1. Not sure if there is any 
plan to change this or if there are known attacks on these ciphers due 
to them using SHA1.

As signing algorithm for certificates. Here the declining collision 
resistance of SHA1 is relevant. I will concentrate on this in the rest 
of the mail.

> 
> How will Apache web server deal with this?

AFAIK, there has been no discussion about this, yet. But I am pretty 
sure that if upstream decides to act, there will be a longer period 
where only a config switch is needed to turn it on again.


> If not following upstream, how will it be done in the Debian
> packages? 

We depend on openssl not removing support for SHA1-signed 
certificates, of course. But I would also opt for either not changing 
anything or only changing the default configuration. Removing SHA1 
certificate support so that apache needs to be recompiled looks more 
like a possible approach for stretch+1, but not for stretch.

> For example, will Apache refuse to run with an SHA-1 server
> certificate?

I don't think so. If you have created a self-signed SHA1 certificate, 
and have imported that into your clients, that is still secure. Unless 
SHA1 pre-image attacks get much better.

> Will it refuse to validate SHA-1 client certificates that were
> accepted previously?
> 
> Will SHA-1 support simply be disabled by default but people can get
> it back through a trivial configuration change?
> 
> Or will people need to recompile if they still need to support any
> SHA1 certificates?
> 
> Will SHA-1 be deprecated in any security fix release to jessie and
> wheezy, or it will only disappear as part of the stretch release
> cycle?

That depends how much better the attacks get. I haven't really made up 
my mind, yet.


> Could the Apache maintainers please add some comments about it on
> the wiki? https://wiki.debian.org/SHA-1
> 
> One aspect of this problem is that there are many hardware devices
> out there with built-in client certificates using the SHA-1 digest.
>  When these devices make connections to an Apache server using
> client TLS (mutual TLS) authentication, they won't be able to send
> an SHA-256 certificate and they may not be able to verify an
> SHA-256 certificate on the server side.  People with hardware like
> that probably need to start planning their migration now if there
> will be no backwards-compatible support for them.
> 
> This has also been discussed on debian-security
> https://lists.debian.org/debian-security/2016/05/msg00039.html

Bug#825849: powerdns 100% CPU usage

[Martin]

Hi Markus,

It's a pretty basic Powerdns installation with a MySQL backend. We're 
using one cryptokey for our domain names to serve DNSSEC to the world. 
Keys are signed with RSASHA256, and Powerdns generates domain name 
specific keys using this global key on the fly.


You could start by installing the latest pdns-server and 
pdns-backend-mysql packages together with the latest libbotan package 
and see if pdns starts using 100% CPU.


Upgrading libbotan doesn't break pdns instantly, only after you restart 
pdns. That probably makes sense, but, just saying.


Thanks,

Martin


Hello,

pdns 3.4.1-4+deb8u5 was a no-change rebuild against botan1.10
1.10.8-2+deb8u1. If there is a regression it must be in botan1.10.

I have never used pdns before. Could you share you configuration with
us? How can we reproduce this issue?

Regards,

Markus

Bug#826651: mirror listing update for mirror.dkm.cz

[Donald Norwood]

Hi Lukas,

We generally don't advertise non DSA controlled /security/ archives, so
not having it there really is not that big of a deal, but I wanted to
ask and clarify.

Leaf servers are servers that update on a cron cycle, I.E. every x hours
(6 is our minimum), while Push-Secondary are servers that are pushed
from an upstream host.
It sounds as though you may be a leaf server. This is up to you, pushing
mirroring does provide that your copy of the archive is in sync with the
archive, there is no split or hierarchy for mirrors in the same area so
several can be leaf or pushed. We prefer pushed.

I'll update your entry and mark this as done, if you have corrections,
questions, or anything just reply and I'll take care of it.

Thank you for your support and for mirroring Debian!

Best regards,

Donald Norwood
-Debian Mirrors Team


On 06/07/2016 03:14 PM, houmles wrote:
> Hi Donald,
> 
> I am new admin. Tomas Zvala, unfortunately, is already out of business.
> You can leave /security/ as we still mirroring it directly from 
> security.debian.org. You just don't have a column for it in your update form.
> For now we will leave a mirror as leaf. Mayber later I will look into it but 
> as there is already one primary-push mirror in CZ I think it's not necessary, 
> right?
> 
> Lukas
> 
> On 07/06, Donald Norwood wrote:
>> Hi Lukas,
>>
>> To confirm:
>>
>> Moving from Push-Secondary to Leaf.
>> Dropping all /security/
>> New upstream(s)
>> Updates 4
>>
>> Is the maintainer still Tomas Zvala?
>>
>> Best regards,
>>
>> Donald Norwood
>> -Debian Mirrors Team
>>
>> On Tue, 07 Jun 2016 13:42:56 + "Lukas Krudl"  wrote:
>>> Package: mirrors
>>> Severity: minor
>>> User: mirr...@packages.debian.org
>>> Usertags: mirror-list
>>>
>>> Submission-Type: update
>>> Site: mirror.dkm.cz
>>> Type: leaf
>>> Archive-architecture: ALL 
>>> Archive-ftp: /debian/
>>> Archive-http: /debian/
>>> Archive-rsync: debian/
>>> CDImage-ftp: /debian-cd/
>>> CDImage-http: /debian-cd/
>>> CDImage-rsync: debian-cd/
>>> IPv6: yes
>>> Archive-upstream: ftp.cz.debian.org
>>> CDImage-upstream: ftp.cz.debian.org
>>> Updates: four
>>> Maintainer: Lukas Krudl 
>>> Country: CZ Czech Republic
>>> Location: Prague, Czech Republic
>>> Sponsor: UPC Czech Republic s.r.o. https://www.upc.cz/
>>>
>>>
>>
> 
> 



signature.asc
Description: OpenPGP digital signature

Bug#826674: gem2deb: FTBFS: test: running dh-make-ruby against a directory should get the package name correctly. :F

[Andreas Beckmann]

Source: gem2deb
Version: 0.30.2
Severity: serious
Justification: fails to build from source

Hi,

gem2deb FTBFS everywhere:
https://buildd.debian.org/status/package.php?p=gem2deb=unstable

  test: running dh-make-ruby against a directory should get the package name 
correctly. :F
===
Failure: test: running dh-make-ruby against a directory should get the package 
name correctly. (DhMakeRubyTest)
/«PKGBUILDDIR»/test/unit/dh_make_ruby_test.rb:109:in `block (2 levels) in 
'
<["ruby-simplegit"]> expected but was
<[]>

diff:
? ["ruby-simplegit"]
===
: (0.058675)


Andreas

Bug#814479: libbusiness-creditcard-perl: New upstream version 0.35 (including new MasterCard ranges)

[Ivan Kohler]

On Tue, Jun 07, 2016 at 11:58:19AM +0200, gregor herrmann wrote:
> In other words, there are no uploads to only stable-updates, just to
> stable(-proposed-updates) which may or may not also be copied over to
> stable-updates. That's why I'm talking about "uploading to stable".

I certainly don't have any current knowledge of the process and I am 
quite happy to take your word for it.  I didn't realize there were so 
many changes since it used to be "volatile".


> > > we'd need a minimal diff
> > > against the versions in wheezy/jessie (0.31 and 0.33), then we can
> > > talk to the release team about them accepting uploads.
> > I do not believe a "minimal diff" is necessary for -updates.  This is not 
> > a security backport.  This is an update for software which requires 
> > alignment to the real work to remain relevant and useful.
> 
> Sure but the release team has to inspect the changes, that's why they
> prefer minimal diffs with only the necessary changes, and also to
> avoid accidental breakage.
> 
> Cf. 
> https://www.debian.org/doc/manuals/developers-reference/ch05.en.html#upload-stable
> 
> Changing anything else in the package that isn't important is
> discouraged, because even trivial fixes can cause bugs later on.

I don't think this section applies (5.5.1 Special case: uploads to the 
stable and oldstable distributions).  This section is talking about the 
few non-security reasons to update a package in stable:

a truly critical functionality problem
the package becomes uninstallable
a released architecture lacks the package

In these cases, I agree, we should follow the same procedure as a 
security update and backport a minimal diff.

However, this isn't one of those cases.  This is a case not documented in 
the developer reference (yet?  elsewhere?), which is stable updates of 
the formerly-"volatile" things like spam and virus scanners, timezone 
updates, web scrapers/video downloaders, etc.

The crucial point is that _we do not backport changes and create new, 
un-QAed forks for any of this other "volatile" software like spam/virus 
scanners and video downloads, so it seems to me that asking for it in the 
case of libbusiness-creditcard-perl is out-of-line with our practices and 
procedures for comparable things.  We pull in new versions of e.g. 
spamassassin and ClamAV for the exact same reasons as this package needs 
to be updated.

Specifially in regard to the desire to "avoid accidental breakage": It 
seems that using the upstream 0.35 version, which has been QAed with my 
company's production customers and by CPAN users for half a year, is the 
more conservative, careful action and is the least likely to break 
anything.  Backporting updates to an old version and creating a new 
Debian-specific fork, which will be unable to get any kind of comparable 
real-world testing, seems to be the riskier action that is more likely to 
cause breakage.


> > We 
> > don't backport functionality to old versions of ClamAV or SpamAssassin - 
> > this would seem to be the same thing.
> 
> That's true for some packages where backporting fixes is non-trivial,
> and AFAIK noone is happy with that. In most cases the changes are
> small and targetted.

In this case, the changes are the _only changes in the package_, as its 
_sole purpose is identifying credit cards_.

WRT your assertion that noone is happy with that, FWIW, I would disagree.  
I'm very happy that my mail server gets updated versions of spamassassin 
and ClamAV.  I'm glad we don't use our limited volunteer resources trying 
to try to support older, less-functional, non-QAed/patched versions of 
those packages on my stable machines like they were stable security 
updates.


> > The sole purpose of libbusiness-creditcard-perl is to validate and 
> > identify credit cards.  Credit card issues are updating these rules and 
> > issuing new credit cards with new number ranges without regard to our 
> > release cycles.  We should be able to update this module through -updates 
> > like we do ClamAV, Spamassassin, timezones and so forth.
> 
> I totally agree that an update of libbusiness-creditcard-perl in
> jessie{,-updates} (wheezy is gone by now anyway) makes sense, I just
> want to prepare a proposal for the release team that doesn't make
> them cringe :) That's why I'd like to strip down
> https://metacpan.org/diff/file?target=IVAN%2FBusiness-CreditCard-0.35%2F=IVAN%2FBusiness-CreditCard-0.33%2F
> to the necessary part(s) before contacting them.

As the sole purpose of the module is to validate and identify credit 
cards, few (if any) would even be omitted.  Since 0.33, the version in 
jessie, _every change_ has been for the purpose of staying up-to-date 
with real world requirements such as recognizing new cards or processing 
agreements.  Here is the relevant section of the Changes file.

0.35  Tue Feb  9 14:43:38 PST 2016
- Fix bug identifying 49* Visa cards introduced in 0.34, patch from
  Ed J, 

Bug#825932: freeorion: Segfault on entry of dead_macron

[Markus Koschany]

On Tue, 7 Jun 2016 13:04:25 -0400 Thanasis Kinias
 wrote:
> Cool.
> 
> BTW, if you want to try to reproduce it, you could manually run a couple
> xmodmap commands:
> 
> $ xmodmap -e 'keycode 108 = Mode_switch'
> $ xmodmap -e 'keycode  20 = minus underscore dead_macron'


It seems upstream has the same problem with reproducing the issue than I
have. Unfortunately he uses Windows for development. I think he would
appreciate help in debugging the issue on this platform.

https://github.com/freeorion/freeorion/issues/701



signature.asc
Description: OpenPGP digital signature

Bug#826624: [Aptitude-devel] Bug#826624: aptitude can't be stopped with "Q" but only with ^T and going down there

[Albrecht Herzog]

On Tue, Jun 07, 2016 at 02:19:40PM +0200, Axel Beckert wrote:
> Hi Albrecht,
> Albrecht Herzog wrote:
> > On Tue, Jun 07, 2016 at 11:49:53AM +0200, Axel Beckert wrote:
> > > Hi Albert,
> Sorry for misspelling of your name in my previous mail.

Try to forget it ASAP :-D))
Or did you mix it with Einstein? ROTFL :)
 
> > > Did you press "q" or "Q" at least once before and cancelled it by
> > > pressing either Ctrl-G or Escape?
> > When presseing "q" to quit, there are still two lines staying there
> What kind of lines?

Well just two lines of te menue, white lessers on blue ground.
 
> > Oh!
> > OOHHH!
> Not these two lines, right? :-)

Sorry, just the two lines and nothing else.

> > Q works. q doesn't
> That sounds like a bug. So I'd be curious about where Q works, but q doesn't.

:-)

> > > And do you have dialogs in mini-buffers enabled?
> > No.
> Ok, so I've disabled mini-buffers temporarily in my setup, but found
> no occassion related to quitting aptitude where Q works, but q doesn't.

Curious, isn't it?
 
> > bugreport can be closed !
> I'm not yet convinced. You may have found something there. :-)

But I'm not proud of it.

Regards, Albrecht

Bug#826443: jessie-pu: package zabbix/1:2.2.7+dfsg-2+deb8u1

[Adam D. Barratt]

Control: tags -1 + pending

On Sun, 2016-06-05 at 17:36 +0100, Adam D. Barratt wrote:
> Control: tags -1 + confirmed
> 
> On Mon, 2016-06-06 at 01:45 +1000, Dmitry Smirnov wrote:
> > I'd like to upload fix for
> > 
> >   CVE-2016-4338 / ZBX-10741: mysql.size shell command injection
> >   in zabbix-agent (Closes: #823329).
> 
> Please go ahead.

Uploaded and flagged for acceptance.

Regards,

Adam

Bug#825572: Uploaded to DELAYED/2

[Mathieu Parent]

2016-06-07 0:16 GMT+02:00 David Prévot :
> Hi Mathieu,

Hi David,

> On Mon, Jun 06, 2016 at 09:50:21PM +0200, Mathieu Parent wrote:
>
>> I've uploaded php-sabre-vobject (2.1.7-3) to DELAYED/2. to fix this RC
>
> Thanks for your update! No need to wait IMHO, so I just ran:
>
> dcut reschedule \
> --file=php-sabre-vobject_2.1.7-3_amd64.changes --days=0

thanks.

> FYI, there is now a buildd available for arch:all, so you could have
> simply dput the _source.changes without any binary package.

Yes I know. But I don't have yet a simple way to build this
_source.changes from "gbp buildpackage". how to ?



> Regards
>
> David

Cheers

-- 
Mathieu

Bug#826335: jessie-pu: package e2fsprogs/1.42.12-2

[Adam D. Barratt]

On Tue, 2016-06-07 at 14:00 -0400, Theodore Ts'o wrote:
> Could I get some direction from the release team what you would
> prefer?  I can remove the Hurd diff if you like.

It's on my to-do list to review.

fwiw there's not been any need to formally acknowledge NMUs via closing
bugs in the changelog since the BTS gained version-tracking some years
ago, so long as the changelog for the subsequent upload incorporates the
stanza from the NMU.

> I guess if you want
> me to re-upload, since I uploaded first, would you need to reject the
> current upload so it exits the queue and then I can re-upload, with
> the preferred version number if that is what you would like?

No, multiple distinct versions of the package can happily co-exist in
the queue. If the package version is re-used then that can't occur until
after the initial version has been rejected, but an upload with a
different version is fine.

Regards,

Adam

Bug#599690: /usr/bin/nm-applet: Dies repeatedly during normal operation.

[Vladimir K]

In the last few days I can only run nm-applet with EN locales. 
If run with ru_RU.UTF-8 it segfaults immediately. Happens with versions 1.2.2-1 
and 1.2.2-2


$ gdb nm-applet 
GNU gdb (Debian 7.10-1+b1) 7.10
Copyright (C) 2015 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
.
Find the GDB manual and other documentation resources online at:
.
For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from nm-applet...(no debugging symbols found)...done.
(gdb) bt
No stack.
(gdb) run
Starting program: /usr/bin/nm-applet 
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".

** (nm-applet:28551): WARNING **: Error retrieving accessibility bus address: 
org.freedesktop.DBus.Error.ServiceUnknown: The name org.a11y.Bus was not 
provided by any .service files
[New Thread 0x7fffec9a6700 (LWP 28555)]
[New Thread 0x7fffe7fff700 (LWP 28556)]
[New Thread 0x7fffdfdf2700 (LWP 28557)]
[New Thread 0x7fffdf3eb700 (LWP 28558)]

Program received signal SIGSEGV, Segmentation fault.
g_hash_table_remove_all (hash_table=0x5) at 
/build/glib2.0-wnDt2X/glib2.0-2.48.1/./glib/ghash.c:1425
1425/build/glib2.0-wnDt2X/glib2.0-2.48.1/./glib/ghash.c: Нет такого файла 
или каталога.
(gdb) bt
#0  0x751270a6 in g_hash_table_remove_all (hash_table=0x5) at 
/build/glib2.0-wnDt2X/glib2.0-2.48.1/./glib/ghash.c:1425
#1  0x00413739 in  ()
#5  0x7542a08f in  
(instance=, signal_id=, detail=) 
at /build/glib2.0-wnDt2X/glib2.0-2.48.1/./gobject/gsignal.c:3441
#2  0x7540efa5 in g_closure_invoke (closure=0x7c10d0, 
return_value=return_value@entry=0x0, n_param_values=1, 
param_values=param_values@entry=0x7fffdc40, 
invocation_hint=invocation_hint@entry=0x7fffdbc0)
at /build/glib2.0-wnDt2X/glib2.0-2.48.1/./gobject/gclosure.c:804
#3  0x75420fc1 in signal_emit_unlocked_R (node=node@entry=0x750190, 
detail=detail@entry=0, instance=instance@entry=0x703f80, 
emission_return=emission_return@entry=0x0, 
instance_and_params=instance_and_params@entry=0x7fffdc40) at 
/build/glib2.0-wnDt2X/glib2.0-2.48.1/./gobject/gsignal.c:3629
#4  0x75429d5c in g_signal_emit_valist (instance=, 
signal_id=, detail=, 
var_args=var_args@entry=0x7fffddf0)
at /build/glib2.0-wnDt2X/glib2.0-2.48.1/./gobject/gsignal.c:3385
#6  0x76dc7fb4 in  () at /usr/lib/x86_64-linux-gnu/libgtk-3.so.0
#7  0x7692bb38 in  () at /usr/lib/x86_64-linux-gnu/libgdk-3.so.0
#8  0x7513805a in g_main_context_dispatch (context=0x6a1330) at 
/build/glib2.0-wnDt2X/glib2.0-2.48.1/./glib/gmain.c:3154
#9  0x7513805a in g_main_context_dispatch 
(context=context@entry=0x6a1330) at 
/build/glib2.0-wnDt2X/glib2.0-2.48.1/./glib/gmain.c:3769
#10 0x75138400 in g_main_context_iterate 
(context=context@entry=0x6a1330, block=block@entry=1, 
dispatch=dispatch@entry=1, self=) at 
/build/glib2.0-wnDt2X/glib2.0-2.48.1/./glib/gmain.c:3840
#11 0x751384ac in g_main_context_iteration 
(context=context@entry=0x6a1330, may_block=may_block@entry=1) at 
/build/glib2.0-wnDt2X/glib2.0-2.48.1/./glib/gmain.c:3901
#12 0x756ffcdd in g_application_run (application=0x6de0c0 [NMApplet], 
argc=1, argv=0x7fffe080) at 
/build/glib2.0-wnDt2X/glib2.0-2.48.1/./gio/gapplication.c:2381
#13 0x004119e7 in main ()

Bug#826335: jessie-pu: package e2fsprogs/1.42.12-2

[Theodore Ts'o]

Could I get some direction from the release team what you would
prefer?  I can remove the Hurd diff if you like.  I guess if you want
me to re-upload, since I uploaded first, would you need to reject the
current upload so it exits the queue and then I can re-upload, with
the preferred version number if that is what you would like?

Thanks,

- Ted

Bug#826667: biber: breaks with perl 5.20.2-3+deb8u5

[gregor herrmann]

On Tue, 07 Jun 2016 17:17:56 +0100, Dominic Hargreaves wrote:

> Test Summary Report
> ---
> t/dm-dateformats.t  (Wstat: 65280 Tests: 0 Failed: 0)
>   Non-zero exit status: 255
>   Parse errors: Bad plan.  You planned 33 tests but ran 0.
> Files=42, Tests=948, 135 wallclock secs ( 0.47 usr  0.37 sys + 125.12 cusr  
> 8.43 csys = 134.39 CPU)
> Result: FAIL
> 
> This appears to be related to this:
> 
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=796944#62
> 
> Right now, I can't spot which change in 5.20.2-3+deb8u5 caused the
> problem, but applying the change reference in that bug report, attached,
> fixes the FTBFS.

Confirmed, both the breakage and the fix.

I also don't understand what happens here. My investigations show:

The problem is (where the patch is :)) in
lib/Biber/Input/file/bibtex.pm in the _hack_month() sub.

This is called twice from t/dm-dateformats.t, once with "14" and once
with "january". And what actually breaks is, in the case with
"january", the call to
Unicode::GCString->new($1)->substr(0,3)->as_string

If I add "print $1;" or "my $foo = $1;" before or if I change the
call to ->new("$1") or ->new($1."") [yes I tried silly things], then
all is fine. Or with the patch which uses the new $m variable.

Unicode::GCString is not in core, and in perldebdelta I didn't find
anything obvious, but maybe the above gives someone else a clue.


Cheers,
gregor

-- 
 .''`.  Homepage https://info.comodo.priv.at/ - OpenPGP key 0xBB3A68018649AA06
 : :' : Debian GNU/Linux user, admin, and developer -  https://www.debian.org/
 `. `'  Member of VIBE!AT & SPI, fellow of the Free Software Foundation Europe
   `-   NP: David Bowie: Ground Control to Major Tom


signature.asc
Description: Digital Signature

Bug#826651: mirror listing update for mirror.dkm.cz

[Donald Norwood]

Hi Lukas,

To confirm:

Moving from Push-Secondary to Leaf.
Dropping all /security/
New upstream(s)
Updates 4

Is the maintainer still Tomas Zvala?

Best regards,

Donald Norwood
-Debian Mirrors Team

On Tue, 07 Jun 2016 13:42:56 + "Lukas Krudl"  wrote:
> Package: mirrors
> Severity: minor
> User: mirr...@packages.debian.org
> Usertags: mirror-list
> 
> Submission-Type: update
> Site: mirror.dkm.cz
> Type: leaf
> Archive-architecture: ALL 
> Archive-ftp: /debian/
> Archive-http: /debian/
> Archive-rsync: debian/
> CDImage-ftp: /debian-cd/
> CDImage-http: /debian-cd/
> CDImage-rsync: debian-cd/
> IPv6: yes
> Archive-upstream: ftp.cz.debian.org
> CDImage-upstream: ftp.cz.debian.org
> Updates: four
> Maintainer: Lukas Krudl 
> Country: CZ Czech Republic
> Location: Prague, Czech Republic
> Sponsor: UPC Czech Republic s.r.o. https://www.upc.cz/
> 
> 



signature.asc
Description: OpenPGP digital signature

Bug#825342: mips/mipsel: make sure all packages built with fpxx enabled

[YunQiang Su]

After the 1st step of binNMU of mipsel (mips is still running),

We still have these package having problem:

adasockets: build-dep problem
apq: build-dep problem
dbusada: build-dep problem
dico: ftbfs
dlz-ldap-enum: ftbfs
gccxml: still building with gcc-4.9 
geoclue: give up
libalog: ftbfs
libc++: clang not enable FPXX by default 
libcorelinux: ftbfs
libdbusmenu: ftbfs
libexplain: ftbfs
libflorist: build-dep problem
libgnatcoll: build-dep problem
libgtkada: build-dep problem
libhtp: give up
liblog4ada: build-dep problem
libncursesada: build-dep problem
libvisca: ftbfs
libxkbcommon: ftbfs
libxmlezout: ftbfs
linbox: ftbfs
lua-discount: ftbfs
mozjs24: build-dep problem
osptoolkit: ftbfs
pcscada: build-dep problem
polyorb: build-dep problem

Non of the above packages make big problems for the next step,
So that I think we can start rebuilding the other non-fpxx package.

The attachment is the list --- more than 3000 packages.
Sorry for the previous wrong estimation.


On Thu, Jun 2, 2016 at 1:52 AM, Emilio Pozuelo Monfort  wrote:
> On 01/06/16 11:27, YunQiang Su wrote:
>> On Wed, Jun 1, 2016 at 4:24 PM, Emilio Pozuelo Monfort  
>> wrote:
>>> On 28/05/16 14:31, YunQiang Su wrote:
 Oh, I need to remove gcc-4.9/gcc-5/gcc-6/gnat-4.9.
>>>
>>> Is gcc-snapshot needed?
>>
>> It is not needed. Sorry forget to exclude it.
>>
>>>
>>> BTW are these the ones with affected static libraries, or all of them? Per 
>>> your
>>> email, we should do the packages with static libraries first, and only then 
>>> do
>>> the rest, IIUC.
>>>
>>
>> These are all about static libraries, aka some static libraries from
>> them are still not
>> fpxx-enabled.
>>
>>> If that's too cumbersome to find, we can do all now and then rebuild the 
>>> ones
>>> that are still using the old ABI because of static linking. Those shouldn't 
>>> be
>>> too many anyway as we don't use static linking much.
>>
>> It is not difficult to detect static libraries.
>
> OK. I have scheduled them all, with a lower priority so other uploads can be
> built as well.
>
> There were some problems though:
>
> W: can't get version info for firedns/mips
> W: can't get version info for firedns/mipsel
> W: can't get version info for geoclue/mips
> W: can't get version info for geoclue/mipsel
> W: can't get version info for libhtp/mips
> W: can't get version info for libhtp/mipsel
>
> Are those the right package names? For geoclue you may have meant geoclue-2.
> src:geoclue is no longer in unstable/testing.
>
> Cheers,
> Emilio



-- 
YunQiang Su


mipsel.source
Description: Binary data

Bug#826261:

[John Paul Adrian Glaubitz]

Control: retitle -1 caja: Cannot rename some files in column view
Control: tags -1 -unreproducible
Control: tags -1 -moreinfo

On 06/06/2016 01:23 PM, Max wrote:
> yep! the slider at the below of window. But the window is not so smaller.

I can reproduce the issue by:

* switching caja to column view
* opening a folder which has enough files to display columns
* making the browser small enough to invoke the slider at the bottom

The preferences option "All columns have the same width" does not have any 
influence
on the erratic behavior. The problem can be resolved by enlarging the browser 
window
such that the slider at the bottom of the window vanishes.

Cheers,
Adrian

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Bug#822494: Time to remove? Unusable since 2014.

[Petter Reinholdtsen]

[Eric Beuque]
> Hi,
>
> i saw that freetuxtv_0.6.8~dfsg1.orig.tar.gz have been commited the same
> day of your message. Does it fix the problem?

Yes.

> For the database, all stream have to be cleaned from
> http://database.freetuxtv.net/. I don't have enough time to do it but i
> will try to do it.

I did not quite understand what you mean.  The streams seem to still be
included in the freetuxtv database.

-- 
Happy hacking
Petter Reinholdtsen

Bug#826672: linuxdcpp: FTBFS: /usr/share/cdbs/1/class/scons.mk:62: *** unterminated call to function 'if': missing ')'. Stop.

[Chris Lamb]

Source: linuxdcpp
Version: 1.1.0-1
Severity: serious
Justification: fails to build from source
User: reproducible-bui...@lists.alioth.debian.org
Usertags: ftbfs
X-Debbugs-Cc: reproducible-bui...@lists.alioth.debian.org

Dear Maintainer,

linuxdcpp fails to build from source in unstable/amd64:

  [..]

   from /usr/include/gtk-2.0/gtk/gtk.h:32,
   from linux/wulformanager.hh:25,
   from linux/wulformanager.cc:22:
  /usr/include/glib-2.0/glib/deprecated/gthread.h:231:11: note: declared here
   void  g_static_rw_lock_writer_unlock  (GStaticRWLock *lock);
 ^
  linux/wulformanager.cc:337:2: warning: 'void 
g_static_rw_lock_writer_unlock(GStaticRWLock*)' is deprecated: Use 
'g_rw_lock_writer_unlock' instead [-Wdeprecated-declarations]
g_static_rw_lock_writer_unlock();
^
  In file included from /usr/include/glib-2.0/glib.h:107:0,
   from /usr/include/glib-2.0/gobject/gbinding.h:28,
   from /usr/include/glib-2.0/glib-object.h:23,
   from /usr/include/glib-2.0/gio/gioenums.h:28,
   from /usr/include/glib-2.0/gio/giotypes.h:28,
   from /usr/include/glib-2.0/gio/gio.h:26,
   from /usr/include/gtk-2.0/gdk/gdkapplaunchcontext.h:30,
   from /usr/include/gtk-2.0/gdk/gdk.h:32,
   from /usr/include/gtk-2.0/gtk/gtk.h:32,
   from linux/wulformanager.hh:25,
   from linux/wulformanager.cc:22:
  /usr/include/glib-2.0/glib/deprecated/gthread.h:231:11: note: declared here
   void  g_static_rw_lock_writer_unlock  (GStaticRWLock *lock);
 ^
  linux/wulformanager.cc:337:44: warning: 'void 
g_static_rw_lock_writer_unlock(GStaticRWLock*)' is deprecated: Use 
'g_rw_lock_writer_unlock' instead [-Wdeprecated-declarations]
g_static_rw_lock_writer_unlock();
  ^
  In file included from /usr/include/glib-2.0/glib.h:107:0,
   from /usr/include/glib-2.0/gobject/gbinding.h:28,
   from /usr/include/glib-2.0/glib-object.h:23,
   from /usr/include/glib-2.0/gio/gioenums.h:28,
   from /usr/include/glib-2.0/gio/giotypes.h:28,
   from /usr/include/glib-2.0/gio/gio.h:26,
   from /usr/include/gtk-2.0/gdk/gdkapplaunchcontext.h:30,
   from /usr/include/gtk-2.0/gdk/gdk.h:32,
   from /usr/include/gtk-2.0/gtk/gtk.h:32,
   from linux/wulformanager.hh:25,
   from linux/wulformanager.cc:22:
  /usr/include/glib-2.0/glib/deprecated/gthread.h:231:11: note: declared here
   void  g_static_rw_lock_writer_unlock  (GStaticRWLock *lock);
 ^
  linux/wulformanager.cc: In member function 'DialogEntry* 
WulforManager::getDialogEntry_gui(const string&)':
  linux/wulformanager.cc:349:2: warning: 'void 
g_static_rw_lock_reader_lock(GStaticRWLock*)' is deprecated: Use 
'g_rw_lock_reader_lock' instead [-Wdeprecated-declarations]
g_static_rw_lock_reader_lock();
^
  In file included from /usr/include/glib-2.0/glib.h:107:0,
   from /usr/include/glib-2.0/gobject/gbinding.h:28,
   from /usr/include/glib-2.0/glib-object.h:23,
   from /usr/include/glib-2.0/gio/gioenums.h:28,
   from /usr/include/glib-2.0/gio/giotypes.h:28,
   from /usr/include/glib-2.0/gio/gio.h:26,
   from /usr/include/gtk-2.0/gdk/gdkapplaunchcontext.h:30,
   from /usr/include/gtk-2.0/gdk/gdk.h:32,
   from /usr/include/gtk-2.0/gtk/gtk.h:32,
   from linux/wulformanager.hh:25,
   from linux/wulformanager.cc:22:
  /usr/include/glib-2.0/glib/deprecated/gthread.h:216:11: note: declared here
   void  g_static_rw_lock_reader_lock(GStaticRWLock *lock);
 ^
  linux/wulformanager.cc:349:2: warning: 'void 
g_static_rw_lock_reader_lock(GStaticRWLock*)' is deprecated: Use 
'g_rw_lock_reader_lock' instead [-Wdeprecated-declarations]
g_static_rw_lock_reader_lock();
^
  In file included from /usr/include/glib-2.0/glib.h:107:0,
   from /usr/include/glib-2.0/gobject/gbinding.h:28,
   from /usr/include/glib-2.0/glib-object.h:23,
   from /usr/include/glib-2.0/gio/gioenums.h:28,
   from /usr/include/glib-2.0/gio/giotypes.h:28,
   from /usr/include/glib-2.0/gio/gio.h:26,
   from /usr/include/gtk-2.0/gdk/gdkapplaunchcontext.h:30,
   from /usr/include/gtk-2.0/gdk/gdk.h:32,
   from /usr/include/gtk-2.0/gtk/gtk.h:32,
   from linux/wulformanager.hh:25,
   from linux/wulformanager.cc:22:
  /usr/include/glib-2.0/glib/deprecated/gthread.h:216:11: note: declared here
   void  g_static_rw_lock_reader_lock(GStaticRWLock *lock);
   

Bug#826671: libvisca: FTBFS: dh_install: Cannot find (any matches for) "debian/tmp/usr/lib/*.so.*" (tried in "." and "debian/tmp")

[Chris Lamb]

Source: libvisca
Version: 1.0.1-1.1
Severity: serious
Justification: fails to build from source
User: reproducible-bui...@lists.alioth.debian.org
Usertags: ftbfs
X-Debbugs-Cc: reproducible-bui...@lists.alioth.debian.org

Dear Maintainer,

libvisca fails to build from source in unstable/amd64:

  [..]

  QUILT_REFRESH_ARGS=-p ab --no-timestamps --no-index
  DEBEMAIL=la...@debian.org
  DEBFULLNAME=Chris Lamb
  EDITOR=vim
  LESS=-cgiFx4M
  BLASTER=A220 I5 D1 H5 P330 T6
  _=/usr/bin/env
  
  
**
  ** Building libvisca 1.0.1-1.1 on amd64   
  **
  
**
  
   dpkg-buildpackage -rfakeroot -D -us -uc -b
  dpkg-buildpackage: info: source package libvisca
  dpkg-buildpackage: info: source version 1.0.1-1.1
  dpkg-buildpackage: info: source distribution unstable
  dpkg-buildpackage: info: source changed by Matthias Klose 
   dpkg-source --before-build libvisca-1.0.1
  dpkg-buildpackage: info: host architecture amd64
   fakeroot debian/rules clean
  test -x debian/rules
  rm -f debian/stamp-makefile-build debian/stamp-makefile-install
  /usr/bin/make -C . -k distclean
  make[1]: Entering directory 
'/home/lamby/temp/cdt.20160607172730.TkYAsYvyH6.libvisca/libvisca-1.0.1'
  make[1]: *** No rule to make target 'distclean'.
  make[1]: Leaving directory 
'/home/lamby/temp/cdt.20160607172730.TkYAsYvyH6.libvisca/libvisca-1.0.1'
  /usr/share/cdbs/1/class/makefile.mk:91: recipe for target 'makefile-clean' 
failed
  make: [makefile-clean] Error 2 (ignored)
  rm -f debian/stamp-autotools
  rmdir --ignore-fail-on-non-empty .
  rmdir: failed to remove '.': Invalid argument
  /usr/share/cdbs/1/class/autotools.mk:64: recipe for target 'makefile-clean' 
failed
  make: [makefile-clean] Error 1 (ignored)
  set -e;
  dh_clean 
  rm -f debian/stamp-autotools-files
   debian/rules build
  test -x debian/rules
  mkdir -p "."
  set -e;   mv ./config.guess ./config.guess.cdbs-orig; cp --remove-destination 
/usr/share/misc/config.guess ./config.guess;
  set -e;   mv ./config.sub ./config.sub.cdbs-orig; cp --remove-destination 
/usr/share/misc/config.sub ./config.sub;
  touch debian/stamp-autotools-files
  chmod a+x 
/home/lamby/temp/cdt.20160607172730.TkYAsYvyH6.libvisca/libvisca-1.0.1/./configure
  mkdir -p .
  cd . && CFLAGS="-g -O2 -fstack-protector-strong -Wformat 
-Werror=format-security" CXXFLAGS="-g -O2 -fstack-protector-strong -Wformat 
-Werror=format-security" CPPFLAGS="-Wdate-time -D_FORTIFY_SOURCE=2" 
LDFLAGS="-Wl,-z,relro" 
/home/lamby/temp/cdt.20160607172730.TkYAsYvyH6.libvisca/libvisca-1.0.1/./configure
 --build=x86_64-linux-gnu --prefix=/usr --includedir="\${prefix}/include" 
--mandir="\${prefix}/share/man" --infodir="\${prefix}/share/info" 
--sysconfdir=/etc --localstatedir=/var --libexecdir="\${prefix}/lib/libvisca" 
--srcdir=. --disable-maintainer-mode --disable-dependency-tracking 
--disable-silent-rules
  checking for a BSD-compatible install... /usr/bin/install -c
  checking whether build environment is sane... yes
  
/home/lamby/temp/cdt.20160607172730.TkYAsYvyH6.libvisca/libvisca-1.0.1/missing: 
Unknown `--run' option
  Try 
`/home/lamby/temp/cdt.20160607172730.TkYAsYvyH6.libvisca/libvisca-1.0.1/missing 
--help' for more information
  configure: WARNING: `missing' script is too old or missing
  checking for a thread-safe mkdir -p... /bin/mkdir -p
  checking for gawk... no
  checking for mawk... mawk
  checking whether make sets $(MAKE)... yes
  checking for gcc... gcc
  checking for C compiler default output file name... a.out
  checking whether the C compiler works... yes
  checking whether we are cross compiling... no
  checking for suffix of executables... 
  checking for suffix of object files... o
  checking whether we are using the GNU C compiler... yes
  checking whether gcc accepts -g... yes
  checking for gcc option to accept ISO C89... none needed
  checking for style of include used by make... GNU
  checking dependency style of gcc... none
  checking build system type... x86_64-pc-linux-gnu
  checking host system type... x86_64-pc-linux-gnu
  checking for a sed that does not truncate output... /bin/sed
  checking for grep that handles long lines and -e... /bin/grep
  checking for egrep... /bin/grep -E
  checking for ld used by gcc... /usr/bin/ld
  checking if the linker (/usr/bin/ld) is GNU ld... yes
  checking for /usr/bin/ld option to reload object files... -r
  checking for BSD-compatible nm... /usr/bin/nm -B
  checking whether ln -s works... yes
  checking how to recognise dependent libraries... pass_all
  checking how to run the C preprocessor... gcc -E
  checking for ANSI C header files... yes
  checking for sys/types.h... yes
  checking for sys/stat.h... yes
  checking for stdlib.h... yes
  checking for string.h... yes
  checking for memory.h... yes
  checking for strings.h... 

Bug#826673: mu-cade: FTBFS: src/abagames/util/ode/world.d:121:33: error: need 'this' for 'MAX_CONTACTS' of type 'const(int)'

[Chris Lamb]

Source: mu-cade
Version: 0.11.dfsg1-10
Severity: serious
Justification: fails to build from source
User: reproducible-bui...@lists.alioth.debian.org
Usertags: ftbfs
X-Debbugs-Cc: reproducible-bui...@lists.alioth.debian.org

Dear Maintainer,

mu-cade fails to build from source in unstable/amd64:

  [..]

  Selecting previously unselected package libsdl1.2debian:amd64.
  Preparing to unpack .../libsdl1.2debian_1.2.15+dfsg1-4_amd64.deb ...
  Unpacking libsdl1.2debian:amd64 (1.2.15+dfsg1-4) ...
  Selecting previously unselected package libmikmod3:amd64.
  Preparing to unpack .../libmikmod3_3.3.8-2_amd64.deb ...
  Unpacking libmikmod3:amd64 (3.3.8-2) ...
  Selecting previously unselected package libvorbisfile3:amd64.
  Preparing to unpack .../libvorbisfile3_1.3.5-3_amd64.deb ...
  Unpacking libvorbisfile3:amd64 (1.3.5-3) ...
  Selecting previously unselected package libsdl-mixer1.2:amd64.
  Preparing to unpack .../libsdl-mixer1.2_1.2.12-11+b1_amd64.deb ...
  Unpacking libsdl-mixer1.2:amd64 (1.2.12-11+b1) ...
  Selecting previously unselected package libogg-dev:amd64.
  Preparing to unpack .../libogg-dev_1.3.2-1_amd64.deb ...
  Unpacking libogg-dev:amd64 (1.3.2-1) ...
  Selecting previously unselected package libflac-dev:amd64.
  Preparing to unpack .../libflac-dev_1.3.1-4_amd64.deb ...
  Unpacking libflac-dev:amd64 (1.3.1-4) ...
  Selecting previously unselected package libmad0-dev.
  Preparing to unpack .../libmad0-dev_0.15.1b-8_amd64.deb ...
  Unpacking libmad0-dev (0.15.1b-8) ...
  Selecting previously unselected package libmikmod-config.
  Preparing to unpack .../libmikmod-config_3.3.8-2_amd64.deb ...
  Unpacking libmikmod-config (3.3.8-2) ...
  Selecting previously unselected package libmikmod-dev:amd64.
  Preparing to unpack .../libmikmod-dev_3.3.8-2_amd64.deb ...
  Unpacking libmikmod-dev:amd64 (3.3.8-2) ...
  Selecting previously unselected package libasound2-dev:amd64.
  Preparing to unpack .../libasound2-dev_1.1.1-1_amd64.deb ...
  Unpacking libasound2-dev:amd64 (1.1.1-1) ...
  Selecting previously unselected package libpng16-16:amd64.
  Preparing to unpack .../libpng16-16_1.6.21-5_amd64.deb ...
  Unpacking libpng16-16:amd64 (1.6.21-5) ...
  Selecting previously unselected package libpng-dev:amd64.
  Preparing to unpack .../libpng-dev_1.6.21-5_amd64.deb ...
  Unpacking libpng-dev:amd64 (1.6.21-5) ...
  Selecting previously unselected package libslang2-dev:amd64.
  Preparing to unpack .../libslang2-dev_2.3.0-2.3_amd64.deb ...
  Unpacking libslang2-dev:amd64 (2.3.0-2.3) ...
  Selecting previously unselected package libcaca-dev.
  Preparing to unpack .../libcaca-dev_0.99.beta19-2+b1_amd64.deb ...
  Unpacking libcaca-dev (0.99.beta19-2+b1) ...
  Selecting previously unselected package libpulse-mainloop-glib0:amd64.
  Preparing to unpack .../libpulse-mainloop-glib0_8.0-2+b2_amd64.deb ...
  Unpacking libpulse-mainloop-glib0:amd64 (8.0-2+b2) ...
  Selecting previously unselected package libelf1:amd64.
  Preparing to unpack .../libelf1_0.165-3_amd64.deb ...
  Unpacking libelf1:amd64 (0.165-3) ...
  Selecting previously unselected package libglib2.0-data.
  Preparing to unpack .../libglib2.0-data_2.48.1-1_all.deb ...
  Unpacking libglib2.0-data (2.48.1-1) ...
  Selecting previously unselected package libglib2.0-bin.
  Preparing to unpack .../libglib2.0-bin_2.48.1-1_amd64.deb ...
  Unpacking libglib2.0-bin (2.48.1-1) ...
  Selecting previously unselected package libpcre16-3:amd64.
  Preparing to unpack .../libpcre16-3_2%3a8.38-3.1_amd64.deb ...
  Unpacking libpcre16-3:amd64 (2:8.38-3.1) ...
  Selecting previously unselected package libpcre32-3:amd64.
  Preparing to unpack .../libpcre32-3_2%3a8.38-3.1_amd64.deb ...
  Unpacking libpcre32-3:amd64 (2:8.38-3.1) ...
  Selecting previously unselected package libpcrecpp0v5:amd64.
  Preparing to unpack .../libpcrecpp0v5_2%3a8.38-3.1_amd64.deb ...
  Unpacking libpcrecpp0v5:amd64 (2:8.38-3.1) ...
  Selecting previously unselected package libpcre3-dev:amd64.
  Preparing to unpack .../libpcre3-dev_2%3a8.38-3.1_amd64.deb ...
  Unpacking libpcre3-dev:amd64 (2:8.38-3.1) ...
  Selecting previously unselected package pkg-config.
  Preparing to unpack .../pkg-config_0.29-4_amd64.deb ...
  Unpacking pkg-config (0.29-4) ...
  Selecting previously unselected package libglib2.0-dev.
  Preparing to unpack .../libglib2.0-dev_2.48.1-1_amd64.deb ...
  Unpacking libglib2.0-dev (2.48.1-1) ...
  Selecting previously unselected package libpulse-dev:amd64.
  Preparing to unpack .../libpulse-dev_8.0-2+b2_amd64.deb ...
  Unpacking libpulse-dev:amd64 (8.0-2+b2) ...
  Selecting previously unselected package libsdl1.2-dev.
  Preparing to unpack .../libsdl1.2-dev_1.2.15+dfsg1-4_amd64.deb ...
  Unpacking libsdl1.2-dev (1.2.15+dfsg1-4) ...
  Selecting previously unselected package libvorbis-dev:amd64.
  Preparing to unpack .../libvorbis-dev_1.3.5-3_amd64.deb ...
  Unpacking libvorbis-dev:amd64 (1.3.5-3) ...
  Selecting previously unselected package libsdl-mixer1.2-dev:amd64.
  Preparing to unpack 

Bug#825932: freeorion: Segfault on entry of dead_macron

[Thanasis Kinias]

Cool.

BTW, if you want to try to reproduce it, you could manually run a couple
xmodmap commands:

$ xmodmap -e 'keycode 108 = Mode_switch'
$ xmodmap -e 'keycode  20 = minus underscore dead_macron'

That will map your right alt key to work like the European AltGr – then if
you to RightAlt + - (that’s keyboard minus, not the numeric kepad minus)
followed by a vowel you’ll get the vowel-with-macron.  If you do that in a
Freeorion text edit box, you should be able to reproduce the crash.

Logging out of your window manager and logging back in should reset your
keyboard mapping.


On Tue, Jun 7, 2016 at 12:27 PM, Markus Koschany  wrote:

> Control: forwarded -1 https://github.com/freeorion/freeorion/issues/701
>
> Hi,
>
> Thank you for the additional information. I have forwarded your bug
> report upstream to
>
> https://github.com/freeorion/freeorion/issues/701
>
> Cheers,
>
> Markus
>
>


-- 
Thanasis Kinias
Doctoral Student, Department of History
Northeastern University
kinia...@husky.neu.edu

Bug#826669: dump: writing QFA positions to (null)

[Vincent Smeets]

Package: dump
Version: 0.4b45-1
Severity: normal

Hallo,

using the option '-Q' to enable the Quick File Access doesn't work anymore
in version 0.4b45. It did work in the previous version 0.4b44. A simple
example of the error is shown here:

vincent@PC-Vincent:~$ mount | grep root
/dev/mapper/debian-root on / type ext4 
(rw,relatime,discard,errors=remount-ro,data=ordered)
vincent@PC-Vincent:~$ sudo dump -0 -f /tmp/root.dump -Q /tmp/root.qfa 
/dev/mapper/debian-root 
  DUMP: Date of this level 0 dump: Tue Jun  7 18:38:42 2016
  DUMP: Dumping /dev/mapper/debian-root (/) to /tmp/root.dump
  DUMP: Label: root
  DUMP: Writing 10 Kilobyte records
  DUMP: mapping (Pass I) [regular files]
  DUMP: mapping (Pass II) [directories]
  DUMP: estimated 531036 blocks.
  DUMP: writing QFA positions to (null)
  DUMP: can't open tapeposfile
  DUMP: The ENTIRE dump is aborted.
vincent@PC-Vincent:~$ 

At first, I thougth that this error was also caused by the bug #826398,
but at a closer investigation of the upstream source code changes, I
found that the filename is probably not communicated to the correct
variable. The NEWS file reports that the QFA code has been reorganized
as a plugin.

Check the diff in git at:

http://anonscm.debian.org/cgit/collab-maint/dump.git/commit/?id=4ae1cb7685eab029d6a182f76d839cf0dea825d3
and search for the string "create tapeposfile".


Regards,
Vincent Smeets

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

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

Versions of packages dump depends on:
ii  e2fslibs  1.43-3
ii  libblkid1 2.28-5
ii  libbz2-1.01.0.6-8
ii  libc6 2.22-9
ii  libcomerr21.43-3
ii  libreadline6  6.3-8+b4
ii  libselinux1   2.5-3
ii  tar   1.29-1
ii  zlib1g1:1.2.8.dfsg-2+b1

dump recommends no packages.

dump suggests no packages.

-- no debconf information

Bug#826649: ruby-activemodel-3.2: syntax error after security upgrade

[Antonio Terceiro]

On Tue, Jun 07, 2016 at 03:19:55PM +0200, adnet ghislain wrote:
> Package: ruby-activemodel-3.2
> Version: 3.2.6-3
> Severity: important
> 
> Dear Maintainer,
> 
> *** Please consider answering these questions, where appropriate ***
> 
>* What led up to the situation?
> 
> security upgrade of the package
> 
>* What exactly did you do (or not do) that was effective (or
>  ineffective)?
> 
> revert to the previous version fixed the issue
>  
>* What was the outcome of this action?
> 
> redmine crashed and showed
> /usr/lib/ruby/vendor_ruby/active_model/validations.rb:57: syntax error, 
> unexpected ':', expecting kEND class_attribute :_validators, instance_writer: 
> false ^
[...]
>Versions of packages ruby-activemodel-3.2 depends on:
> ii  ruby-activesupport-3.2  3.2.6-6+deb7u1
> ii  ruby1.8 [ruby-interpreter]  1.8.7.358-7.1+deb7u3

The syntax error is caused by the fact that you are using ruby1.8, which
indeed does not support the syntax used (and is also severily outdated).

Did you force ruby1.8, or stopped the installation of ruby1.9.1 (which
should be the default in Wheezy), in any way? You probably shouldn't.

Please try using ruby1.9.1. just installing the `ruby` package should do
it.

-- 
Antonio Terceiro 


signature.asc
Description: PGP signature

Bug#826668: ido: FTBFS: touch: cannot touch 'debian/stamp-makefile-check/gtk2': No such file or directory

[Chris Lamb]

Source: ido
Version: 0.3.4-1.1
Severity: serious
Justification: fails to build from source
User: reproducible-bui...@lists.alioth.debian.org
Usertags: ftbfs
X-Debbugs-Cc: reproducible-bui...@lists.alioth.debian.org

Dear Maintainer,

ido fails to build from source in unstable/amd64:

  [..]

  checking whether we are using the GNU C compiler... yes
  checking whether gcc accepts -g... yes
  checking for gcc option to accept ISO C89... none needed
  checking whether gcc understands -c and -o together... yes
  checking for style of include used by make... GNU
  checking dependency style of gcc... none
  checking build system type... x86_64-pc-linux-gnu
  checking host system type... x86_64-pc-linux-gnu
  checking how to print strings... printf
  checking for a sed that does not truncate output... /bin/sed
  checking for grep that handles long lines and -e... /bin/grep
  checking for egrep... /bin/grep -E
  checking for fgrep... /bin/grep -F
  checking for ld used by gcc... /usr/bin/ld
  checking if the linker (/usr/bin/ld) is GNU ld... yes
  checking for BSD- or MS-compatible name lister (nm)... /usr/bin/nm -B
  checking the name lister (/usr/bin/nm -B) interface... BSD nm
  checking whether ln -s works... yes
  checking the maximum length of command line arguments... 1572864
  checking how to convert x86_64-pc-linux-gnu file names to x86_64-pc-linux-gnu 
format... func_convert_file_noop
  checking how to convert x86_64-pc-linux-gnu file names to toolchain format... 
func_convert_file_noop
  checking for /usr/bin/ld option to reload object files... -r
  checking for objdump... objdump
  checking how to recognize dependent libraries... pass_all
  checking for dlltool... no
  checking how to associate runtime and link libraries... printf %s\n
  checking for ar... ar
  checking for archiver @FILE support... @
  checking for strip... strip
  checking for ranlib... ranlib
  checking command to parse /usr/bin/nm -B output from gcc object... ok
  checking for sysroot... no
  checking for a working dd... /bin/dd
  checking how to truncate binary pipes... /bin/dd bs=4096 count=1
  checking for mt... no
  checking if : is a manifest tool... no
  checking how to run the C preprocessor... gcc -E
  checking for ANSI C header files... yes
  checking for sys/types.h... yes
  checking for sys/stat.h... yes
  checking for stdlib.h... yes
  checking for string.h... yes
  checking for memory.h... yes
  checking for strings.h... yes
  checking for inttypes.h... yes
  checking for stdint.h... yes
  checking for unistd.h... yes
  checking for dlfcn.h... yes
  checking for objdir... .libs
  checking if gcc supports -fno-rtti -fno-exceptions... no
  checking for gcc option to produce PIC... -fPIC -DPIC
  checking if gcc PIC flag -fPIC -DPIC works... yes
  checking if gcc static flag -static works... yes
  checking if gcc supports -c -o file.o... yes
  checking if gcc supports -c -o file.o... (cached) yes
  checking whether the gcc linker (/usr/bin/ld -m elf_x86_64) supports shared 
libraries... yes
  checking whether -lc should be explicitly linked in... no
  checking dynamic linker characteristics... GNU/Linux ld.so
  checking how to hardcode library paths into programs... immediate
  checking whether stripping libraries is possible... yes
  checking if libtool supports shared libraries... yes
  checking whether to build shared libraries... yes
  checking whether to build static libraries... no
  checking for glib-mkenums... /usr/bin/glib-mkenums
  checking for pkg-config... /usr/bin/pkg-config
  checking pkg-config is at least version 0.9.0... yes
  checking for ANSI C header files... (cached) yes
  checking fcntl.h usability... yes
  checking fcntl.h presence... yes
  checking for fcntl.h... yes
  checking for stdlib.h... (cached) yes
  checking for string.h... (cached) yes
  checking for unistd.h... (cached) yes
  checking for an ANSI C-conforming const... yes
  checking for stdlib.h... (cached) yes
  checking for GNU libc compatible malloc... yes
  checking for stdlib.h... (cached) yes
  checking for unistd.h... (cached) yes
  checking for sys/param.h... yes
  checking for getpagesize... yes
  checking for working mmap... yes
  checking for memset... yes
  checking for munmap... yes
  checking for strcasecmp... yes
  checking for strdup... yes
  checking for GTK... yes
  checking for gtkdoc-check... /usr/bin/gtkdoc-check
  checking for gtkdoc-rebase... /usr/bin/gtkdoc-rebase
  checking for gtkdoc-mkpdf... /usr/bin/gtkdoc-mkpdf
  checking whether to build gtk-doc documentation... no
  checking that generated files are newer than configure... done
  configure: creating ./config.status
  config.status: creating Makefile
  config.status: creating src/Makefile
  config.status: creating example/Makefile
  config.status: creating libido.pc
  config.status: creating libido3.pc
  config.status: creating config.h
  config.status: executing depfiles commands
  config.status: executing libtool commands
  configure: WARNING: unrecognized 

Bug#825932: freeorion: Segfault on entry of dead_macron

[Markus Koschany]

Control: forwarded -1 https://github.com/freeorion/freeorion/issues/701

Hi,

Thank you for the additional information. I have forwarded your bug
report upstream to

https://github.com/freeorion/freeorion/issues/701

Cheers,

Markus



signature.asc
Description: OpenPGP digital signature

Bug#822494: Time to remove? Unusable since 2014.

[Eric Beuque]

Hi,

i saw that freetuxtv_0.6.8~dfsg1.orig.tar.gz have been commited the same
day of your message. Does it fix the problem?

For the database, all stream have to be cleaned from
http://database.freetuxtv.net/. I don't have enough time to do it but i
will try to do it.



2016-06-02 11:25 GMT+02:00 Petter Reinholdtsen :

> [Eric Beuque]
> > Hi, we are updating upstream package in debian, just waiting for some
> > review before to send it to debian repository.
> >
> > It will be soon avaliable.
>
> Very good.  I had a look and cleaned up some issues.  The most annoying
> issue left is that 'gbp buildpackage' do not work because of this:
>
>   fatal: Path 'freetuxtv_0.6.8~dfsg1.orig.tar.gz.delta' does not exist in
> 'refs/heads/pristine-tar'
>   pristine-tar: git show
> refs/heads/pristine-tar:freetuxtv_0.6.8~dfsg1.orig.tar.gz.delta failed
>   gbp:error: Couldn't checkout "freetuxtv_0.6.8~dfsg1.orig.tar.gz": it
> exited with 128
>
> Perhaps you can fix it?
>
> I've tested the package in Jessie (with a patch), and it seem to be
> working.  Unfortunately the database of video and audio sources seem to
> be horribly outdated, making it hard to find a stream to use for
> testing.
>
> Are you going to push the patches and manual page upstream?  Are you in
> touch with upstream?  He seem quite responsive.
>
> Btw, you should drop the menu file and use a desktop file instead.
>
> --
> Happy hacking
> Petter Reinholdtsen
>

Bug#825112: (no subject)

[Barry Warsaw]

On Jun 07, 2016, at 10:35 AM, Gordon Ball wrote:

>Packaging has been done and can be found in collab-maint [1]
>(git-buildpackage+pristine-tar format [2]). Current version is
>0.3.3+dfsg. Builds for xenial/yakkety can be found in a PPA [3].

Cool.  I grabbed and looked at the collab branch.

>The packaging and test suite appear to work, but I've held off trying to
>get it uploaded since there have been several minor versions in quick
>succession recently (0.3.0 .. 0.3.3 in the last two weeks) and I was
>waiting to see if it would settle.

Hopefully that will calm down after the rush of Pycon.

>Would you be willing to review and possibly sponsor?

For sure.  Would you consider adding me to Uploaders?

The packaging looks really good.  I noticed the setting of http_proxy in
override_dh_auto_build.  You probably don't strictly need that because I
believe pybuild does that automatically.  It can't hurt though and some
maintainers prefer to be explicit about that.

It might be good to add an autopkgtest that actually runs the installed xonsh
as a sanity check.  Maybe even just run a simple xonsh script?  See below.

Should debian/xonsh.1 be generated from help2man so it doesn't get out of
sync?

>[2]: This should probably be under DPMT and git-dpm, but I'm not (yet) a
>team member

You should definitely join debian-python!  However, as this is an application
and not a library, it would probably be best to put it under PAPT.  The
problem there of course is that PAPT hasn't switched to git yet :(.  I'm
hoping tumbleweed and others might make that happen at or after debconf2016.
Until that happens, collab-maint is fine.

>[3]: ppa:chronitis/misc (contains a variety of other stuff)

Cool!

/me builds

Love the logo output during `python3.5 setup.py clean` ;)

I think you need to explicitly depend on python3-pkg-resources, otherwise:

# xonsh
Traceback (most recent call last):
  File "/usr/bin/xonsh", line 5, in 
from pkg_resources import load_entry_point
ImportError: No module named 'pkg_resources'

I made a few of the suggested changes (adding the Depends and an autopkgtest)
and pushed it to the `review` branch on collab-maint.  Let me know what you
think.  Great work, and I'm happy to sponsor and/or comaintain xonsh!


pgpMA5iuifa1M.pgp
Description: OpenPGP digital signature