date:20140102

Package: libodfgen
Version: 0.0.2-1
Severity: normal
Tags: patch
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu trusty ubuntu-patch

Dear Maintainer,

For the ppc64el architecture in Ubuntu, since this package uses libtool, a full
autoreconf is necessary. This is because we need new libtool macros for
ppc64el.

In Ubuntu, the attached patch was applied to achieve the following:

  * Use dh-autoreconf to fix FTBFS on ppc64el.

Thanks for considering the patch.

Logan Rosen



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

Kernel: Linux 3.12.0-7-generic (SMP w/1 CPU core)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
diff -Nru libodfgen-0.0.2/debian/control libodfgen-0.0.2/debian/control
--- libodfgen-0.0.2/debian/control	2013-05-02 19:21:40.0 -0400
+++ libodfgen-0.0.2/debian/control	2014-01-03 02:40:33.0 -0500
@@ -1,7 +1,7 @@
 Source: libodfgen
 Priority: optional
 Maintainer: Rene Engelhard 
-Build-Depends: autotools-dev,
+Build-Depends: dh-autoreconf,
debhelper (>= 9),
libboost-dev,
libwpd-dev (>= 0.9.0),
diff -Nru libodfgen-0.0.2/debian/rules libodfgen-0.0.2/debian/rules
--- libodfgen-0.0.2/debian/rules	2013-05-02 15:24:04.0 -0400
+++ libodfgen-0.0.2/debian/rules	2014-01-02 20:57:39.0 -0500
@@ -4,7 +4,7 @@
 #export DH_VERBOSE=1
 
 %:
-	dh $@
+	dh $@ --with autoreconf
 
 override_dh_auto_configure:
 	dh_auto_configure -- --disable-werror --libdir=/usr/lib \

Bug#734035: libnjb: use dh-autoreconf instead of autotools-dev to fix FTBFS on ppc64el

Package: libnjb
Version: 2.2.7~dfsg0-3
Severity: normal
Tags: patch
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu trusty ubuntu-patch

Dear Maintainer,

For the ppc64el architecture in Ubuntu, since this package uses libtool, a full
autoreconf is necessary instead of just config.{sub,guess} updates with
autotools-dev. This is because we need new libtool macros for ppc64el.

In Ubuntu, the attached patch was applied to achieve the following:

  * Use dh-autoreconf instead of autotools-dev to fix FTBFS on ppc64el.

Thanks for considering the patch.

Logan Rosen



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

Kernel: Linux 3.12.0-7-generic (SMP w/1 CPU core)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
diff -Nru libnjb-2.2.7~dfsg0/debian/control libnjb-2.2.7~dfsg0/debian/control
--- libnjb-2.2.7~dfsg0/debian/control	2012-01-16 13:58:01.0 -0500
+++ libnjb-2.2.7~dfsg0/debian/control	2014-01-03 02:39:12.0 -0500
@@ -2,7 +2,7 @@
 Section: libs
 Priority: optional
 Maintainer: Alessio Treglia 
-Build-Depends: autotools-dev,
+Build-Depends: dh-autoreconf,
  debhelper (>= 8.1.3~),
  libncurses5-dev,
  libusb-dev
diff -Nru libnjb-2.2.7~dfsg0/debian/rules libnjb-2.2.7~dfsg0/debian/rules
--- libnjb-2.2.7~dfsg0/debian/rules	2012-01-16 13:59:34.0 -0500
+++ libnjb-2.2.7~dfsg0/debian/rules	2014-01-02 20:40:19.0 -0500
@@ -1,7 +1,7 @@
 #!/usr/bin/make -f
 
 %:
-	dh $@ --with autotools_dev
+	dh $@ --with autoreconf
 
 override_dh_auto_clean:
 	dh_auto_clean

Bug#734034: libnfs: use dh-autoreconf to fix FTBFS on ppc64el

Package: libnfs
Version: 1.3.0-2
Severity: normal
Tags: patch
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu trusty ubuntu-patch

Dear Maintainer,

For the ppc64el architecture in Ubuntu, since this package uses libtool, a full
autoreconf is necessary. This is because we need new libtool macros for
ppc64el.

In Ubuntu, the attached patch was applied to achieve the following:

  * Use dh-autoreconf to get new libtool macros for ppc64el.
  * Build-depend on pkg-config to fix FTBFS.

Thanks for considering the patch.

Logan Rosen



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

Kernel: Linux 3.12.0-7-generic (SMP w/1 CPU core)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
diff -Nru libnfs-1.3.0/debian/control libnfs-1.3.0/debian/control
--- libnfs-1.3.0/debian/control	2012-05-05 15:17:54.0 -0400
+++ libnfs-1.3.0/debian/control	2014-01-03 02:35:51.0 -0500
@@ -2,7 +2,7 @@
 Section: libs
 Priority: optional
 Maintainer: Andres Mejia 
-Build-Depends: debhelper (>= 8.1.3~)
+Build-Depends: debhelper (>= 8.1.3~), dh-autoreconf, pkg-config
 Standards-Version: 3.9.3
 Homepage: https://github.com/sahlberg/libnfs
 Vcs-Git: git://anonscm.debian.org/collab-maint/libnfs.git
diff -Nru libnfs-1.3.0/debian/rules libnfs-1.3.0/debian/rules
--- libnfs-1.3.0/debian/rules	2011-07-24 14:15:43.0 -0400
+++ libnfs-1.3.0/debian/rules	2014-01-02 20:31:10.0 -0500
@@ -4,7 +4,7 @@
 CFLAGS=$(DEB_CFLAGS)
 
 %:
-	dh $@ --parallel
+	dh $@ --parallel --with autoreconf
 
 override_dh_clean:
 	dh_clean examples/Makefile

Bug#734033: ITP: libmoosex-app-perl

2014-01-02 Thread Stefan Hornburg (Racke)

Package: wnpp
Owner: Stefan Hornburg (Racke) 
Severity: wishlist
X-Debbugs-CC: debian-de...@lists.debian.org,debian-p...@lists.debian.org

* Package name: libmoosex-app-perl
  Version : 1.22
  Upstream Author : Maroš Kollár
* URL : https://metacpan.org/pod/MooseX::App
* License : Artistic or GPL-1+
  Programming Lang: Perl
  Description : Write user-friendly Perl/Moose command line apps with even 
less suffering

MooseX-App is a highly customizeable helper to write user-friendly command line 
applications
without having to worry about most of the annoying things usually involved. 
Just take any
existing Moose class, add a single line (use MooseX-App qw(PluginA PluginB 
...);)
and create one class for each command in an underlying namespace.

Needed for Git::CPAN::Patch.

Regards
 Racke

-- 
LinuXia Systems => http://www.linuxia.de/
Expert Interchange Consulting and System Administration
ICDEVGROUP => http://www.icdevgroup.org/
Interchange Development Team


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#734032: libnss-pgsql: use autotools-dev to update config.{sub,guess} for new arches

Package: libnss-pgsql
Version: 1.4.0debian-5
Severity: normal
Tags: patch
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu trusty ubuntu-patch

Dear Maintainer,

Please use autotools-dev to update config.{sub,guess} for new architectures.
For example, we needed these updates in Ubuntu for the new arm64 and ppc64el
architectures.

In Ubuntu, the attached patch was applied to achieve the following:
  * Use autotools-dev to update config.{sub,guess} for new arches.

Thanks for considering the patch.

Logan Rosen



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

Kernel: Linux 3.12.0-7-generic (SMP w/1 CPU core)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
diff -Nru libnss-pgsql-1.4.0debian/debian/control libnss-pgsql-1.4.0debian/debian/control
--- libnss-pgsql-1.4.0debian/debian/control	2011-02-06 08:59:03.0 -0500
+++ libnss-pgsql-1.4.0debian/debian/control	2014-01-03 02:34:06.0 -0500
@@ -3,7 +3,7 @@
 Priority: extra
 Maintainer: Debian Nss/Pgsql Developers 
 Uploaders: Christian Bayle , Stephen Gran , Martin Krafft , Jan Dittberner 
-Build-Depends: debhelper (>= 7.0.50~), libpq-dev, debiandoc-sgml, xmlto
+Build-Depends: debhelper (>= 7.0.50~), libpq-dev, debiandoc-sgml, xmlto, autotools-dev
 Standards-Version: 3.9.1
 Homepage: https://alioth.debian.org/projects/nsspampgsql/
 Vcs-Git: git://git.debian.org/nsspampgsl/nsspampgsql.git
diff -Nru libnss-pgsql-1.4.0debian/debian/rules libnss-pgsql-1.4.0debian/debian/rules
--- libnss-pgsql-1.4.0debian/debian/rules	2011-02-06 08:59:03.0 -0500
+++ libnss-pgsql-1.4.0debian/debian/rules	2014-01-02 20:50:59.0 -0500
@@ -21,4 +21,4 @@
 	rm -f $(CURDIR)/debian/libnss-pgsql2/lib/libnss_pgsql.so
 
 %:
-	dh $@
+	dh $@ --with autotools_dev

Bug#727418: libnetfilter-log: update config.{sub,guess} for the AArch64 port

Package: libnetfilter-log
Version: 1.0.0-1
Followup-For: Bug #727418
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu trusty ubuntu-patch

Dear Maintainer,

In Ubuntu, the attached patch was applied to achieve the following:

  * Use dh-autoreconf to get new libtool macros for ppc64el and update
config.{sub,guess} for new arches.

Thanks for considering the patch.

Logan Rosen



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

Kernel: Linux 3.12.0-7-generic (SMP w/1 CPU core)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
diff -u libnetfilter-log-1.0.0/debian/rules libnetfilter-log-1.0.0/debian/rules
--- libnetfilter-log-1.0.0/debian/rules
+++ libnetfilter-log-1.0.0/debian/rules
@@ -18,7 +18,7 @@
 build: build-stamp
 build-stamp:
 	dh_testdir
-
+	dh_autoreconf
 	# ./configure
 	CFLAGS="$(CFLAGS)" ./configure --host=$(DEB_HOST_GNU_TYPE) --build=$(DEB_BUILD_GNU_TYPE) \
 		--disable-dependency-tracking \
@@ -35,7 +35,7 @@
 	rm -f build-stamp install*-stamp
 
 	[ ! -f Makefile ] || $(MAKE) distclean
-
+	dh_autoreconf_clean
 	dh_clean
 
 install: install-stamp
diff -u libnetfilter-log-1.0.0/debian/control libnetfilter-log-1.0.0/debian/control
--- libnetfilter-log-1.0.0/debian/control
+++ libnetfilter-log-1.0.0/debian/control
@@ -2,7 +2,7 @@
 Section: libs
 Priority: extra
 Maintainer: Alexander Wirt 
-Build-Depends: debhelper (>= 5), libnfnetlink-dev (>= 0.0.41)
+Build-Depends: debhelper (>= 5), libnfnetlink-dev (>= 0.0.41), dh-autoreconf
 Standards-Version: 3.9.1
 
 Package: libnetfilter-log1

Bug#712841: qcontrol: Fan error reported on TS109

2014-01-02 Thread Martin Michlmayr

* Ian Campbell  [2014-01-03 00:19]:
> I suppose you never heard back?

Correct; I'll ask again.

-- 
Martin Michlmayr
http://www.cyrius.com/


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#734031: libnetfilter-cttimeout: use dh-autoreconf instead of autotools-dev to fix FTBFS on ppc64el

Package: libnetfilter-cttimeout
Version: 1.0.0-2
Severity: normal
Tags: patch
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu trusty ubuntu-patch

Dear Maintainer,

For the ppc64el architecture in Ubuntu, since this package uses libtool, a full
autoreconf is necessary instead of just config.{sub,guess} updates with
autotools-dev. This is because we need new libtool macros for ppc64el.

In Ubuntu, the attached patch was applied to achieve the following:

  * Use dh-autoreconf instead of autotools-dev to fix FTBFS on ppc64el.

Thanks for considering the patch.

Logan Rosen



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

Kernel: Linux 3.12.0-7-generic (SMP w/1 CPU core)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
diff -u libnetfilter-cttimeout-1.0.0/debian/control libnetfilter-cttimeout-1.0.0/debian/control
--- libnetfilter-cttimeout-1.0.0/debian/control
+++ libnetfilter-cttimeout-1.0.0/debian/control
@@ -4,7 +4,8 @@
 Build-Depends: debhelper (>= 9.0.0),
libmnl-dev (>= 1.0.0),
libtool,
-   pkg-config
+   pkg-config,
+   dh-autoreconf
 Standards-Version: 3.9.3
 Section: libs
 Homepage: http://www.netfilter.org/projects/libnetfilter_cttimeout
diff -u libnetfilter-cttimeout-1.0.0/debian/rules libnetfilter-cttimeout-1.0.0/debian/rules
--- libnetfilter-cttimeout-1.0.0/debian/rules
+++ libnetfilter-cttimeout-1.0.0/debian/rules
@@ -10,7 +10,7 @@
 #export DH_VERBOSE=1
 
 %:
-	dh $@ 
+	dh $@ --with autoreconf 
 
 override_dh_strip:
 	dh_strip --dbg-package=libnetfilter-cttimeout1-dbg

Bug#733910: ITP: ckon -- automatic build tool for ROOT analyses

2014-01-02 Thread Patrick Huck


Hi Andreas, Hi Debian-Science Team,

@Andreas: yes, I think working on the ckon package within the Debian 
Science team would make the most sense. Thank you for the suggestion. 
I'm forwarding the ITP to the debian-science-maintainers list, too.


I've been following the debian science policy [1] to start packaging 
ckon. Please find the binary packages (and the git-buildpackage 
repository) on github [2]. Unfortunately, I couldn't request membership 
in the Debian Science Team and create a package repository on 
git.debian.org due to alioth.debian.org throwing the error message 
"Alioth Could Not Connect to Database:". I tried all day to access 
Alioth after creating an account but no success.
Also, I compiled the package on a fresh ubuntu precise32 vagrant box. 
However, ckon depends on boost1.50 which is not part of the ubuntu 
precise release. Hence, I used
libboost1.50-all-dev from ppa:brainpower/testing [3] and added it to 
Build-Depends [4]. The name might have to be changed for an appropriate 
debian release.


Thank you for your help.
best,
Patrick

[1] http://debian-science.alioth.debian.org/debian-science-policy.html
[2] https://github.com/tschaume/ckon-deb-pkg/releases
[3] https://launchpad.net/~brainpower/+archive/testing
[4] https://github.com/tschaume/ckon-deb-pkg/blob/master/debian/control

Patrick Huck 
January 1, 2014 9:51 PM
Package: wnpp
Severity: wishlist
Owner: Patrick Huck 

* Package name : ckon
Version : 0.6.1
Upstream Author : Patrick Huck 
* URL : http://tschaume.github.com/ckon
* License : MIT
Programming Lang: C++
Description : ckon is an automatic build tool for C++ software 
developed within the CERN ROOT data analysis framework.


ckon is a C++ program/tool which automatically takes care of 
compilation, dictionary generation and linking of programs and 
libraries developed for data analyses within the CERN ROOT analysis 
framework. This includes parsing include headers to figure out which 
libraries the main programs need to be linked to. It uses 
automake/autoconf to be platform independent and GNU install 
compliant. In addition, m4 macros are automatically downloaded and the 
according compiler flags included based on a list of boost libraries 
provided in the config file. For the purpose of YAML database usage, a 
m4 macro can be downloaded during setup to link against the yaml-cpp 
library.



--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#608400: re-organize how to contribute documentation "per-profile"

2014-01-02 Thread sean

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Here's a formatted version, in wml, of my draft for the new Intro/Help
page.

I've incorporated many of the items on the original page into my
revision, while keeping the structure that was mentioned earlier in
the bug report.

Feel free to give me suggestions on what to improve!


Thanks,

Sean
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.12 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQEcBAEBAgAGBQJSxmZ5AAoJEC9ACRPRNMOU/aEH/2/QW3e3+Lnk6UcFHLDgqnrW
ELf8GPWW9fBdg4ysSt8E8tJ8Bdc5tqKMmX23FUdFGqOaoObYpR08gwIdbsKPAAt5
iKkO0nem10V4Fj4bDzRVIR3kIpUkDyXcT1oRwo+LDJvdleDivgEmZU2t+sy3LNO+
VYVgf4Fgh638qmuqvCynW7pbRt45sNoljKg51J9bgjTCHPbbLp2uDLhZ7fgzZjEh
1wwGWVpi+h5sR4/tpkfBu3k/4a5a4X4FSMzUzR4TrUTKyrThsl+WY17LJu03NqI8
xeBffhvH9uM6QTZDsgCkmMG92k4JQsnaI6bA/Twg18Y47LBzZHYmJdfXQJzLhg8=
=Eh6u
-END PGP SIGNATURE-
Title: Debian -- How can you help Debian? 





   
   
  
   
	
		
		

			
			
		
		
	   
  


Skip Quicknav

   About Debian
   Getting Debian
   Support
   Developers' Corner

 
Introduction to Debian
 /
How can you help Debian?
 


How can you help Debian?
 If you are considering helping in the development of Debian there are many areas in which both experienced and inexperienced users can assist.
there are many ways you can get involved with the project and only few of them require you to be a Debian Developer.
Many of the different projects have mechanisms to allow direct access to source code trees to contributors that have shown they are trustworthy and valuable.
Typically, people which find that they can get much more involved in Debian will join the project, but this is not always required.

 Finally, Debian provides many teams of developers working together on common tasks. Anybody can participate on a team, whether an official Debian Developer or not.


 Users & Developers 
 Bug Triaging 
You can simply test the operating system and the programs provided in it
and report any not yet known errata or bugs you find using the
Bug Tracking System. Try to browse also
the bugs associated with packages you use and provide further
information, if you can reproduce the issues described in them.
	While handling bugs can be considered part of the maintainer's job, your triaging contributions are welcome!
	For an introduction on the important steps to report bugs in the Debian Bug Tracking System (BTS) and general bug reporting information, see these documents on the Wiki:


	  Bugs  
	  Bug Triage  

 Helpful bug documents worth reading are:

	 How to use the Bug Tracking System 
	 Bugs Version Tracking, about how the BTS treat the version informations. 
	 Finally don't hesitate to refer to the BTS documentation whenever you need to write to cont...@bugs.debian.org! 

 Packaging 
You can help maintain applications that are already available in the Debian
operating system, specially those you use much and know about, by
contributing fixes (patches) or additional information in the Bug Tracking System for those packages. You
can also get involved directly in package maintenance by becoming a member of a
group maintenance team or get involved with software that is being developed
for Debian by joining a software project at Alioth.
You can help porting Debian to some architecture you are experienced with
either by starting a new port or contributing to existing ports. For more
information see the list of available ports.
You can package applications you have much experience with and consider
valuable for Debian and become the maintainer for those packages. For more
information read the Debian Developer's Corner.
You can help track,
find and
fix
security issues within the packages in Debian.


	 Help packaging new applications and maintaining orphaned packages: WNPP
	 Help teams
	 Debian ports

 Web Development 
You can help with the development of the public face of Debian and
contribute to the website or by
helping with the organisation of events
worldwide.

	Helping with the Debian website
	Recommended reading: How debian.org is made 

 Creative & Non-Developers 
 Artwork 
DebianArt is a place for high quality artwork and themes for the Debian Desktop.
The idea is use the website for contests, creating an archive of user contributed artwork that can be freely used and included in upcoming Debian releases.

	 Design new themes at DebianArt
	 Help in the maintainence of the fonts

 Documentation 
You can help writing documentation either by working with the official
documentation provided by the Debian Documentation
Project or by contributing at the Debian
Wiki.

	 Write manuals/howto/FAQ at the Debian Documentation Project
	 Help the Doc Team
	 Write Manpages
	 Contribute to the the Debian Wiki

 Translation 
You can help translating applications or Debian-related information
(web pages, documentation) to your own language by
getting involved in a translation project (discussion is generally handled
through the i18n mailing lis

Bug#734030: libnetfilter-cthelper: use dh-autoreconf instead of autotools-dev to also fix FTBFS on ppc64el

Package: libnetfilter-cthelper
Version: 1.0.0-1
Severity: normal
Tags: patch
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu trusty ubuntu-patch

Dear Maintainer,

For the ppc64el architecture in Ubuntu, since this package uses libtool, a full
autoreconf is necessary instead of just config.{sub,guess} updates with
autotools-dev. This is because we need new libtool macros for ppc64el.

In Ubuntu, the attached patch was applied to achieve the following:

  * Use dh-autoreconf instead of autotools-dev to fix FTBFS on ppc64el.

Thanks for considering the patch.

Logan Rosen



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

Kernel: Linux 3.12.0-7-generic (SMP w/1 CPU core)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
diff -Nru libnetfilter-cthelper-1.0.0/debian/control libnetfilter-cthelper-1.0.0/debian/control
--- libnetfilter-cthelper-1.0.0/debian/control	2013-05-19 02:37:38.0 -0400
+++ libnetfilter-cthelper-1.0.0/debian/control	2014-01-03 02:30:32.0 -0500
@@ -2,7 +2,7 @@
 Section: libs
 Priority: extra
 Maintainer: Alexander Wirt 
-Build-Depends: debhelper (>= 9), libmnl-dev (>= 1.0.1), pkg-config
+Build-Depends: debhelper (>= 9), libmnl-dev (>= 1.0.1), pkg-config, dh-autoreconf
 Standards-Version: 3.9.4
 Vcs-Git: git://github.com/formorer/pkg-libnetfilter-cthelper.git
 Vcs-Browser: https://github.com/formorer/pkg-libnetfilter-cthelper
diff -Nru libnetfilter-cthelper-1.0.0/debian/rules libnetfilter-cthelper-1.0.0/debian/rules
--- libnetfilter-cthelper-1.0.0/debian/rules	2013-05-19 02:25:14.0 -0400
+++ libnetfilter-cthelper-1.0.0/debian/rules	2014-01-02 20:09:54.0 -0500
@@ -10,7 +10,7 @@
 # export DH_VERBOSE=1
 
 %:
-	dh $@
+	dh $@ --with autoreconf
 
 override_dh_strip:
 	dh_strip --dbg-package=libnetfilter-cthelper0-dbg

Bug#730800: Pending fixes for bugs in the fonts-levien-museum package

2014-01-02 Thread pkg-fonts-devel

tag 730800 + pending
thanks

Some bugs in the fonts-levien-museum package are closed in revision
c4661e305c81106954962ca1b804e90a4f17905e in branch 'master' by
Christian Perrier

The full diff can be seen at
http://anonscm.debian.org/gitweb/?p=pkg-fonts/fonts-levien-museum.git;a=commitdiff;h=c4661e3

Commit message:

Fix typo in package description. Closes: #730800


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#734029: libnetfilter-acct: use dh-autoreconf instead of autotools-dev to also fix FTBFS on ppc64el

Package: libnetfilter-acct
Version: 1.0.2-1
Severity: normal
Tags: patch
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu trusty ubuntu-patch

Dear Maintainer,

For the ppc64el architecture in Ubuntu, since this package uses libtool, a full
autoreconf is necessary instead of just config.{sub,guess} updates with
autotools-dev. This is because we need new libtool macros for ppc64el.

In Ubuntu, the attached patch was applied to achieve the following:

  * Use dh-autoreconf instead of autotools-dev to fix FTBFS on ppc64el.

Thanks for considering the patch.

Logan Rosen



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

Kernel: Linux 3.12.0-7-generic (SMP w/1 CPU core)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
diff -Nru libnetfilter-acct-1.0.2/debian/control libnetfilter-acct-1.0.2/debian/control
--- libnetfilter-acct-1.0.2/debian/control	2013-07-21 14:41:51.0 -0400
+++ libnetfilter-acct-1.0.2/debian/control	2014-01-03 02:29:19.0 -0500
@@ -3,7 +3,7 @@
 Priority: extra
 Maintainer: Laurence J. Lane 
 Homepage: http://www.netfilter.org/projects/libnetfilter_acct/
-Build-Depends: debhelper (>= 9), libnfnetlink-dev (>= 1.0.0), libmnl-dev, autotools-dev, dh-autoreconf
+Build-Depends: debhelper (>= 9), libnfnetlink-dev (>= 1.0.0), libmnl-dev, dh-autoreconf
 Standards-Version: 3.9.4
 
 Package: libnetfilter-acct1
diff -Nru libnetfilter-acct-1.0.2/debian/rules libnetfilter-acct-1.0.2/debian/rules
--- libnetfilter-acct-1.0.2/debian/rules	2013-07-21 14:34:58.0 -0400
+++ libnetfilter-acct-1.0.2/debian/rules	2014-01-02 20:04:33.0 -0500
@@ -1,7 +1,7 @@
 #!/usr/bin/make -f
 
 %:
-	dh $@ --with autotools_dev # --with autoreconf 
+	dh $@ --with autoreconf 
 
 override_dh_strip:
 	dh_strip --dbg-package=libnetfilter-acct1-dbg

Bug#734028: gnat-mingw-w64-i686: Fails to link, missing __gnat_malloc

2014-01-02 Thread Stephen Kitt

Package: gnat-mingw-w64-i686
Version: 4.8.2-11+11
Severity: grave
Justification: renders package unusable

Dear Maintainer,

Ada programs now fail to link:

i686-w64-mingw32-gcc -c helloworld.adb
i686-w64-mingw32-gnatbind helloworld
i686-w64-mingw32-gnatlink helloworld -o ada32.exe
/usr/lib/gcc/i686-w64-mingw32/4.8/adalib/libgnat.a(s-finmas.o):(.text+0x1020): 
undefined reference to `__gnat_malloc'
/usr/lib/gcc/i686-w64-mingw32/4.8/adalib/libgnat.a(s-stposu.o):(.text+0x16ab): 
undefined reference to `__gnat_malloc'
/usr/lib/gcc/i686-w64-mingw32/4.8/adalib/libgnat.a(s-fileio.o):(.text+0x106b): 
undefined reference to `__gnat_malloc'
/usr/lib/gcc/i686-w64-mingw32/4.8/adalib/libgnat.a(s-fileio.o):(.text+0x13c1): 
undefined reference to `__gnat_malloc'
/usr/lib/gcc/i686-w64-mingw32/4.8/adalib/libgnat.a(s-fileio.o):(.text+0x1457): 
undefined reference to `__gnat_malloc'
/usr/bin/i686-w64-mingw32-ld: 
/usr/lib/gcc/i686-w64-mingw32/4.8/adalib/libgnat.a(s-fileio.o): bad reloc 
address 0x17c in section `.rdata'
collect2: error: ld returned 1 exit status
i686-w64-mingw32-gnatlink: error when calling 
/usr/lib/ccache/i686-w64-mingw32-gcc

Regards,

Stephen


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

Kernel: Linux 3.11-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

Versions of packages gnat-mingw-w64-i686 depends on:
ii  gcc-mingw-w64-base  4.8.2-11+11
ii  gcc-mingw-w64-i686  4.8.2-11+11
ii  libc6   2.17-97
ii  libcloog-isl4   0.18.1-3
ii  libgmp102:5.1.3+dfsg-1
ii  libisl100.12.1-2
ii  libmpc3 1.0.1-1
ii  libmpfr43.1.2-1
ii  zlib1g  1:1.2.8.dfsg-1

gnat-mingw-w64-i686 recommends no packages.

Versions of packages gnat-mingw-w64-i686 suggests:
pn  gcc-4.8-locales  

-- no debconf information
-- Hello World in Ada

with Text_IO;
procedure HelloWorld is

begin
  Text_IO.Put_Line("Hello World!");
end HelloWorld;

Bug#734027: libgetopt++: use dh-autoreconf to fix FTBFS on ppc64el

Package: libgetopt++
Version: 0.0.2-p22-3
Severity: normal
Tags: patch
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu trusty ubuntu-patch

Dear Maintainer,

For the ppc64el architecture in Ubuntu, since this package uses libtool, a full
autoreconf is necessary. This is because we need new libtool macros for
ppc64el.

In Ubuntu, the attached patch was applied to achieve the following:

  * Use dh-autoreconf to fix FTBFS on ppc64el.

Thanks for considering the patch.

Logan Rosen



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

Kernel: Linux 3.12.0-7-generic (SMP w/1 CPU core)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
diff -u libgetopt++-0.0.2-p22/debian/rules libgetopt++-0.0.2-p22/debian/rules
--- libgetopt++-0.0.2-p22/debian/rules
+++ libgetopt++-0.0.2-p22/debian/rules
@@ -40,7 +40,7 @@
 
 $(objdir)/config.status: configure $(QUILT_STAMPFN)
 	dh_testdir
-
+	dh_autoreconf
 	-mkdir $(objdir)
 	cd $(objdir) && \
 	env CFLAGS="$(CFLAGS)" CXXFLAGS="$(CFLAGS)" ../configure $(confflags)
@@ -64,7 +64,7 @@
 
 	rm -f build-stamp
 	rm -rf $(objdir)
-
+	dh_autoreconf_clean
 	dh_clean
 
 #
diff -u libgetopt++-0.0.2-p22/debian/control libgetopt++-0.0.2-p22/debian/control
--- libgetopt++-0.0.2-p22/debian/control
+++ libgetopt++-0.0.2-p22/debian/control
@@ -2,7 +2,7 @@
 Section: libs
 Priority: optional
 Maintainer: Robert Collins 
-Build-Depends: autotools-dev, debhelper, quilt
+Build-Depends: debhelper, quilt, dh-autoreconf
 Standards-Version: 3.7.2
 
 Package: libgetopt++1

Bug#727919: libgfshare: update config.{sub,guess} for the AArch64 port

Package: libgfshare
Version: 1.0.5-2
Followup-For: Bug #727919
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu trusty ubuntu-patch

Dear Maintainer,

In Ubuntu, the attached patch was applied to achieve the following:

  * Use dh-autoreconf to get new libtool macros for ppc64el and update
config.{sub,guess} for new arches.

Thanks for considering the patch.

Logan Rosen



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

Kernel: Linux 3.12.0-7-generic (SMP w/1 CPU core)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
diff -Nru libgfshare-1.0.5/debian/control libgfshare-1.0.5/debian/control
--- libgfshare-1.0.5/debian/control	2012-03-31 17:16:03.0 -0400
+++ libgfshare-1.0.5/debian/control	2014-01-03 02:00:31.0 -0500
@@ -3,7 +3,7 @@
 Priority: extra
 Maintainer: Simon McVittie 
 Standards-Version: 3.9.3
-Build-Depends: autotools-dev,
+Build-Depends: dh-autoreconf,
debhelper (>= 9),
dpkg-dev (>= 1.16.1),
dvipng,
diff -Nru libgfshare-1.0.5/debian/rules libgfshare-1.0.5/debian/rules
--- libgfshare-1.0.5/debian/rules	2012-03-31 17:16:03.0 -0400
+++ libgfshare-1.0.5/debian/rules	2014-01-02 00:07:02.0 -0500
@@ -3,7 +3,7 @@
 include /usr/share/dpkg/default.mk
 
 %:
-	dh $*
+	dh $* --with autoreconf
 
 override_dh_clean:
 	dh_clean

Bug#734026: libgconf-bridge: use dh-autoreconf instead of autotools-dev to also fix FTBFS on ppc64el

Package: libgconf-bridge
Version: 0.1-2.2
Severity: normal
Tags: patch
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu trusty ubuntu-patch

Dear Maintainer,

For the ppc64el architecture in Ubuntu, since this package uses libtool, a full
autoreconf is necessary instead of just config.{sub,guess} updates with
autotools-dev. This is because we need new libtool macros for ppc64el.

In Ubuntu, the attached patch was applied to achieve the following:

  * Use dh-autoreconf instead of autotools-dev to fix FTBFS on ppc64el.

Thanks for considering the patch.

Logan Rosen



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

Kernel: Linux 3.12.0-7-generic (SMP w/1 CPU core)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
diff -u libgconf-bridge-0.1/debian/rules libgconf-bridge-0.1/debian/rules
--- libgconf-bridge-0.1/debian/rules
+++ libgconf-bridge-0.1/debian/rules
@@ -3,6 +3,7 @@
 include /usr/share/cdbs/1/rules/debhelper.mk
 include /usr/share/cdbs/1/class/autotools.mk
 include /usr/share/cdbs/1/rules/utils.mk
+include /usr/share/cdbs/1/rules/autoreconf.mk
 
 
 DEB_CONFIGURE_EXTRA_FLAGS := --enable-gtk-doc
diff -u libgconf-bridge-0.1/debian/control libgconf-bridge-0.1/debian/control
--- libgconf-bridge-0.1/debian/control
+++ libgconf-bridge-0.1/debian/control
@@ -2,7 +2,7 @@
 Section: libs
 Priority: optional
 Maintainer: Ross Burton 
-Build-Depends: debhelper (>= 5), cdbs, autotools-dev, libgconf2-dev, libgtk2.0-dev, gtk-doc-tools
+Build-Depends: debhelper (>= 5), cdbs, dh-autoreconf, libgconf2-dev, libgtk2.0-dev, gtk-doc-tools
 Standards-Version: 3.7.2
 
 Package: libgconf-bridge0

Bug#734025: libfolia: use dh-autoreconf to fix FTBFS on ppc64el

Package: libfolia
Version: 0.10-4.2
Severity: normal
Tags: patch
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu trusty ubuntu-patch

Dear Maintainer,

For the ppc64el architecture in Ubuntu, since this package uses libtool, a full
autoreconf is necessary. This is because we need new libtool macros for
ppc64el.

In Ubuntu, the attached patch was applied to achieve the following:

  * Use dh-autoreconf to fix FTBFS on ppc64el.

Thanks for considering the patch.

Logan Rosen



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

Kernel: Linux 3.12.0-7-generic (SMP w/1 CPU core)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
diff -Nru libfolia-0.10/debian/control libfolia-0.10/debian/control
--- libfolia-0.10/debian/control	2013-12-26 23:24:18.0 -0500
+++ libfolia-0.10/debian/control	2014-01-03 01:55:15.0 -0500
@@ -1,10 +1,9 @@
 Source: libfolia
 Section: science
 Priority: extra
 Maintainer: Debian Science Team 
 Uploaders: Joost van Baal-Ilić , Ko van der Sloot 
-Build-Depends: cdbs, debhelper (>= 7), pkg-config, libicu-dev, libxml2-dev, libticcutils2-dev
+Build-Depends: cdbs, debhelper (>= 7), pkg-config, libicu-dev, libxml2-dev, libticcutils2-dev, dh-autoreconf
 Standards-Version: 3.9.3
 Homepage: http://ilk.uvt.nl/
 Vcs-Svn: svn://svn.debian.org/svn/debian-science/packages/libfolia/trunk
diff -Nru libfolia-0.10/debian/rules libfolia-0.10/debian/rules
--- libfolia-0.10/debian/rules	2013-06-15 02:09:52.0 -0400
+++ libfolia-0.10/debian/rules	2014-01-01 20:58:12.0 -0500
@@ -5,3 +5,4 @@
 
 include /usr/share/cdbs/1/rules/debhelper.mk
 include /usr/share/cdbs/1/class/autotools.mk
+include /usr/share/cdbs/1/rules/autoreconf.mk

Bug#734024: libassa: use dh-autoreconf instead of autotools-dev to also fix FTBFS on ppc64el

Package: libassa
Version: 3.5.1-3
Severity: normal
Tags: patch
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu trusty ubuntu-patch

Dear Maintainer,

For the ppc64el architecture in Ubuntu, since this package uses libtool, a full
autoreconf is necessary instead of just config.{sub,guess} updates with
autotools-dev. This is because we need new libtool macros for ppc64el.

In Ubuntu, the attached patch was applied to achieve the following:

  * Use dh-autoreconf instead of autotools-dev to fix FTBFS on ppc64el.

Thanks for considering the patch.

Logan Rosen



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

Kernel: Linux 3.12.0-7-generic (SMP w/1 CPU core)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
diff -Nru libassa-3.5.1/debian/control libassa-3.5.1/debian/control
--- libassa-3.5.1/debian/control	2013-11-11 21:50:35.0 -0500
+++ libassa-3.5.1/debian/control	2014-01-03 01:48:08.0 -0500
@@ -2,7 +2,7 @@
 Priority: optional
 Section: libs
 Maintainer: Eric Dorland 
-Build-Depends: debhelper (>= 9), autotools-dev , doxygen, libtirpc-dev,
+Build-Depends: debhelper (>= 9), dh-autoreconf, doxygen, libtirpc-dev,
  pkg-config
 Standards-Version: 3.9.4
 Homepage: http://libassa.sourceforge.net/
diff -Nru libassa-3.5.1/debian/rules libassa-3.5.1/debian/rules
--- libassa-3.5.1/debian/rules	2013-11-11 21:50:35.0 -0500
+++ libassa-3.5.1/debian/rules	2014-01-01 01:36:02.0 -0500
@@ -1,7 +1,7 @@
 #!/usr/bin/make -f
 
 %:
-	dh $@ --with autotools_dev
+	dh $@ --with autoreconf
 
 override_dh_auto_test:
 # Don't run the test suite, needs build fixes.

Bug#734022: libantlr3c: use dh-autoreconf instead of autotools-dev to also fix FTBFS on ppc64el

Package: libantlr3c
Version: 3.2-2
Severity: normal
Tags: patch
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu trusty ubuntu-patch

Dear Maintainer,

For the ppc64el architecture in Ubuntu, since this package uses libtool, a full
autoreconf is necessary instead of just config.{sub,guess} updates with
autotools-dev. This is because we need new libtool macros for ppc64el.

In Ubuntu, the attached patch was applied to achieve the following:

  * Use dh-autoreconf instead of autotools-dev to fix FTBFS on ppc64el.

Thanks for considering the patch.

Logan Rosen



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

Kernel: Linux 3.12.0-7-generic (SMP w/1 CPU core)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
diff -Nru libantlr3c-3.2/debian/control libantlr3c-3.2/debian/control
--- libantlr3c-3.2/debian/control	2011-06-13 05:48:18.0 -0400
+++ libantlr3c-3.2/debian/control	2014-01-03 01:44:54.0 -0500
@@ -3,7 +3,7 @@
 Priority: optional
 Maintainer: Julien BLACHE 
 Standards-Version: 3.9.2
-Build-Depends: debhelper (>= 8.1.3), dpkg-dev (>= 1.15.4), autotools-dev
+Build-Depends: debhelper (>= 8.1.3), dpkg-dev (>= 1.15.4), dh-autoreconf
 Homepage: http://www.antlr.org/wiki/display/ANTLR3/ANTLR3+Code+Generation+-+C
 
 Package: libantlr3c-dev
diff -Nru libantlr3c-3.2/debian/rules libantlr3c-3.2/debian/rules
--- libantlr3c-3.2/debian/rules	2011-06-13 06:32:26.0 -0400
+++ libantlr3c-3.2/debian/rules	2014-01-01 00:07:24.0 -0500
@@ -26,17 +26,10 @@
 ENABLE_64BIT = --enable-64bit
 endif
 
-autotools: autotools-stamp
-autotools-stamp:
-	-rm -f config.sub config.guess
-	ln -s /usr/share/misc/config.sub config.sub
-	ln -s /usr/share/misc/config.guess config.guess
-	touch autotools-stamp
-
 configure: configure-stamp
-configure-stamp: autotools-stamp
+configure-stamp:
 	dh_testdir
-
+	dh_autoreconf
 	# Configure with ANTLR remote debugger enabled
 	mkdir build-dbg
 	( cd build-dbg; \
@@ -66,13 +59,13 @@
 clean: 
 	dh_testdir
 	dh_testroot
-	rm -f autotools-stamp configure-stamp build-stamp
+	rm -f configure-stamp build-stamp
 
 	# Add here commands to clean up after the build process.
 	rm -rf build-dbg debian/tmp-dbg
 	rm -rf build-nodbg
 
-	rm -f config.sub config.guess
+	dh_autoreconf_clean
 
 	dh_clean

Bug#734023: libass: use dh-autoreconf instead of autotools-dev to also fix FTBFS on ppc64el

Package: libass
Version: 0.10.1-3
Severity: normal
Tags: patch
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu trusty ubuntu-patch

Dear Maintainer,

For the ppc64el architecture in Ubuntu, since this package uses libtool, a full
autoreconf is necessary instead of just config.{sub,guess} updates with
autotools-dev. This is because we need new libtool macros for ppc64el.

In Ubuntu, the attached patch was applied to achieve the following:

  * Use dh-autoreconf instead of autotools-dev to fix FTBFS on ppc64el.

Thanks for considering the patch.

Logan Rosen



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

Kernel: Linux 3.12.0-7-generic (SMP w/1 CPU core)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
diff -Nru libass-0.10.1/debian/control libass-0.10.1/debian/control
--- libass-0.10.1/debian/control	2013-10-15 12:41:49.0 -0400
+++ libass-0.10.1/debian/control	2014-01-03 01:47:20.0 -0500
@@ -3,7 +3,7 @@
 Maintainer: Debian Multimedia Maintainers 
 Uploaders: Christophe Mutricy 
 Build-Depends: debhelper (>= 8.1.3~),
-   autotools-dev,
+   dh-autoreconf,
libfreetype6-dev,
libenca-dev,
libfontconfig1-dev,
diff -Nru libass-0.10.1/debian/rules libass-0.10.1/debian/rules
--- libass-0.10.1/debian/rules	2013-10-15 12:41:16.0 -0400
+++ libass-0.10.1/debian/rules	2014-01-01 01:31:27.0 -0500
@@ -23,7 +23,7 @@
 
 config.status: configure
 	dh_testdir
-	dh_autotools-dev_updateconfig
+	dh_autoreconf
 	touch configure
 	./configure $(CONFFLAGS)
 
@@ -38,7 +38,7 @@
 	dh_testroot
 	rm -f build-stamp 
 	[ ! -f Makefile ] || $(MAKE) distclean
-	dh_autotools-dev_restoreconfig
+	dh_autoreconf_clean
 	dh_clean 
 
 install: build

Bug#666767: libnet-dns-perl: Please build with hardening flags

2014-01-02 Thread Florian Roscher

Hi intrigeri,

I am about to work on it, starting today and next week.

Am 02.01.14 22:34, schrieb intrigeri:

> How about joining us now? I'm happy to help you with the adoption
> procedure for this package.

I started to update and change other parts of my build
environment first and intended to head towards the Perl group
later, but I see there are good reasons not to delay
this again. So, yes, I will join you now.

Regards
Florian


-- 
  Florian Roscher private: m...@florian-roscher.de
   Debian: f...@debian.org
PGP Key / ID: 1024D/B4071A65
Fingerprint : F9AB 00C1 3E3A 8125 DD3F  DF1C DF79 A374 B407 1A65


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#734021: alembic: New upstream version 0.6.2

2014-01-02 Thread Thomas Bechtold

Package: alembic
Version: 0.4.2+ds-3.1
Severity: wishlist

Dear Maintainer,

there's a new upstream version available on pypi: 
https://pypi.python.org/pypi/alembic
Please consider packaging the new version.

Cheers,

Tom

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

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

Versions of packages alembic depends on:
ii  libjs-sphinxdoc1.2+dfsg-1
ii  python 2.7.5-5
ii  python-mako0.9.1-1
ii  python-sqlalchemy  0.8.4-1

Versions of packages alembic recommends:
ii  python-pkg-resources  2.0.2-1

alembic suggests no packages.

-- no debconf information


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#732670: segfault on loading of setting files

2014-01-02 Thread Adam Majer

On Mon, Dec 23, 2013 at 11:26:11PM +0100, Adrian Knoth wrote:
> On 12/20/13 06:42, Adam Majer wrote:
> 
> >Package: jack-rack
> >Version: 1.4.8~rc1-2
> >Severity: important
> >
> >1. Set some filters in jack-rack
> >2. save
> >3. load
> >4. [segfault]
> >
> >Attached is an example file that segfaults.
> >
> >[39022.436412] jack-rack[9415]: segfault at 0 ip   (null) sp
> >7fffa607eb38 error 14 in jack-rack[40+19000]
> >
> >[48599.653336] jack-rack[9513]: segfault at 10081 ip
> >7ffd45d15542 sp 7fffe3e0b130 error 4 in
> >libjack.so.0.1.0[7ffd45d02000+55000]
> 
> Works like a charm on my system, no such crash.

Hmm, it was working for me for a bit too, until today. Now it crashed
a few times before finally loading the settings...

[40718.814944] jack-rack[9552]: segfault at 10080 ip 7f71640e9542 sp 
7fff35acea30 error 4 in libjack.so.0.1.0[7f71640d6000+55000]

[40851.928753] traps: jack-rack[9673] general protection ip:7f120ea35542 
sp:7fff4160e1e0 error:0 in libjack.so.0.1.0[7f120ea22000+55000]

[40869.023503] jack-rack[9700]: segfault at 180 ip 7f953245f542 sp 
7fffeb3a0160 error 4 in libjack.so.0.1.0[7f953244c000+55000]


So I've tried to rebuild rack-jack with debug symbols and got a
FTBFS error. I've submitted another bug for that.


> Related: if you're just looking for a plugin host, maybe check
> lv2rack or calfhost.

Thanks for the tip. I'll definitely will look at those.

- Adam


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#733860: ITP: pond -- Forward secure, asynchronous messaging for the discerning.

Hi,

Kartik Mistry wrote (03 Jan 2014 04:45:02 GMT) :
> Suitable for experimental for sure. I'll be happy to help in
> packaging if needed.

Great, three candidate packagers for a single ITP :)

I'm re-adding the ITP bug to the Cc list. Please keep it copied so
that the discussion is archived there.

Cheers,
-- 
  intrigeri
  | GnuPG key @ https://gaffer.ptitcanardnoir.org/intrigeri/intrigeri.asc
  | OTR fingerprint @ https://gaffer.ptitcanardnoir.org/intrigeri/otr.asc


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#727042: pidgin-otr: Pidgin freezes while generating otr-keys

Control: tag -1 + moreinfo

Hi Martin,

> Pidgin freezes if creation of otr-keys gets started.

Is this the same problem as reported on #721659,
or is Pidgin actually crashing?

Cheers,
--
  intrigeri
  | GnuPG key @ https://gaffer.ptitcanardnoir.org/intrigeri/intrigeri.asc
  | OTR fingerprint @ https://gaffer.ptitcanardnoir.org/intrigeri/otr.asc


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#734020: FTBFS: error: unknown type name ‘GtkCallbackMarshal’

2014-01-02 Thread Adam Majer

Package: jack-rack
Version: 1.4.8~rc1-2
Severity: serious


adamm@mira:/tmp$ apt-get source jack-rack
Reading package lists... Done
Building dependency tree   
Reading state information... Done
NOTICE: 'jack-rack' packaging is maintained in the 'Git' version control system 
at:
git://anonscm.debian.org/pkg-multimedia/jack-rack.git
Need to get 140 kB of source archives.
Get:1 http://ftp.ca.debian.org/debian/ sid/main jack-rack 1.4.8~rc1-2 (dsc) 
[2,144 B]
Get:2 http://ftp.ca.debian.org/debian/ sid/main jack-rack 1.4.8~rc1-2 (tar) 
[122 kB]
Get:3 http://ftp.ca.debian.org/debian/ sid/main jack-rack 1.4.8~rc1-2 (diff) 
[15.9 kB]
Fetched 140 kB in 0s (7,200 kB/s)
dpkg-source: info: extracting jack-rack in jack-rack-1.4.8~rc1
dpkg-source: info: unpacking jack-rack_1.4.8~rc1.orig.tar.gz
dpkg-source: info: unpacking jack-rack_1.4.8~rc1-2.debian.tar.gz
dpkg-source: info: applying 01-desktop_file.patch
dpkg-source: info: applying 02-gcc45_binutils_gold.patch
dpkg-source: info: applying 03-remove_midi_when_replacing_plugin.patch


$ debuild

In file included from
/usr/include/libgnomeui-2.0/libgnomeui/libgnomeui.h:35:0,
 from ui_callbacks.c:34:
/usr/include/libgnomeui-2.0/libgnomeui/gnome-app-helper.h:620:2:
error: unknown type name ‘GtkCallbackMarshal’
  GtkCallbackMarshal relay_func;
  ^
/usr/include/libgnomeui-2.0/libgnomeui/gnome-app-helper.h:687:9:
error: unknown type name ‘GtkCallbackMarshal’
 GtkCallbackMarshal relay_func, gpointer data,
 ^
/usr/include/libgnomeui-2.0/libgnomeui/gnome-app-helper.h:725:11:
error: unknown type name ‘GtkCallbackMarshal’
   GtkCallbackMarshal relay_func, gpointer data,
   ^
/usr/include/libgnomeui-2.0/libgnomeui/gnome-app-helper.h:771:9:
error: unknown type name ‘GtkCallbackMarshal’
 GtkCallbackMarshal relay_func, gpointer data,
 ^
In file included from
/usr/include/libgnomeui-2.0/libgnomeui/libgnomeui.h:62:0,
 from ui_callbacks.c:34:
/usr/include/libgnomeui-2.0/libgnomeui/gnome-client.h:457:13: error:
unknown type name ‘GtkCallbackMarshal’
 GtkCallbackMarshal function,
 ^

Full log is attached. This *could* a problem with libgnomeui when
using GTK_DISABLE_DEPRECATED . See 

/usr/include/gtk-2.0/gtk/gtktypeutils.h

The symbol in question is on line 50. It probably would be re-enabled
if GTK_COMPILATION was defined, but I don't know what that means (I'm
not a Gnome person).

- Adam



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

Kernel: Linux 3.12-1-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_CA.UTF-8, LC_CTYPE=en_CA.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages jack-rack depends on:
ii  jackd 5
ii  libasound21.0.27.2-3
ii  libatk1.0-0   2.10.0-2
ii  libc6 2.17-97
ii  libcairo2 1.12.16-2
ii  libfontconfig12.11.0-2
ii  libfreetype6  2.5.1-1
ii  libgdk-pixbuf2.0-02.28.2-1+b1
ii  libglib2.0-0  2.36.4-1
ii  libgtk2.0-0   2.24.22-1
ii  libjack-jackd2-0 [libjack-0.116]  1.9.9.5+20130622git7de15e7a-1
ii  liblrdf0  0.4.0-5
ii  libpango-1.0-01.36.0-1+b1
ii  libpangocairo-1.0-0   1.36.0-1+b1
ii  libpangoft2-1.0-0 1.36.0-1+b1
ii  libxml2   2.9.1+dfsg1-3
ii  python2.7.5-5

Versions of packages jack-rack recommends:
ii  blop 0.2.8-6
ii  cmt  1.16-1
ii  swh-plugins  0.4.15+1-7

jack-rack suggests no packages.

-- no debconf information
 dpkg-buildpackage -rfakeroot -D -us -uc
dpkg-buildpackage: source package jack-rack
dpkg-buildpackage: source version 1.4.8~rc1-2
dpkg-buildpackage: source distribution unstable
dpkg-buildpackage: source changed by Alessio Treglia 
 dpkg-source --before-build jack-rack
dpkg-buildpackage: host architecture amd64
dpkg-source: info: using options from jack-rack/debian/source/local-options: 
--unapply-patches --abort-on-upstream-changes
dpkg-source: info: applying 01-desktop_file.patch
dpkg-source: info: applying 02-gcc45_binutils_gold.patch
dpkg-source: info: applying 03-remove_midi_when_replacing_plugin.patch
 fakeroot debian/rules clean
dh clean --with autoreconf
   dh_testdir
   dh_auto_clean
   dh_autoreconf_clean
   dh_clean
 dpkg-source -b jack-rack
dpkg-source: info: using options from jack-rack/debian/source/local-options: 
--unapply-patches --abort-on-upstream-changes
dpkg-source: info: using source format `3.0 (quilt)'
dpkg-source: info: building jack-rack using existing 
./jack-rack_1.4.8~rc1.orig.tar.gz
dpkg-source: info: building jack-rack in jack-rack_1.4.8~rc1-2.debian.tar.gz
dpkg-source: info: building jack-rack

Bug#727708: init system thoughts

Hi,

first, thank you for describing this problem in details.

I have never met it while using systemd on Debian Wheezy and sid for
18 months. Anyhow, with your indications at hand, I realize that my
use cases probably fall into the category that does not expose
this problem.

Steve Langasek wrote (03 Jan 2014 01:19:40 GMT) :
> Without an equivalent to failsafe.conf, server systems converted from
> sysvinit to systemd will find some of their (poorly-coded, but nevertheless
> common and supported in Debian) services randomly failing to start on boot
> where they started reliably before.

Just to check that I understood you correctly: this will be the case
"only" for services that do not provide systemd integration, right?

I'm obviously not saying we should disregard these, but I think it is
useful for this discussion to clearly state which packages would be
affected, and which would not.

> The kinds of race conditions that I'm highlighting here are ones
> that Ubuntu identified and resolved over the course of two years of
> experience with Upstart in the wild, at the cost of quite a bit of
> pain for Ubuntu's users in the meantime.

Trying to better evaluate the required effort, I am wondering to what
extend Debian would benefit from the "Ubuntu identified" part, even if
the fixes cannot be directly translated to systemd. So, I have a few
questions for you.

First, do you expect the list of race conditions identified and
resolved in Ubuntu to cover most of those that could hit Debian if we
were to use systemd?

Second, if we don't want to simply wait for the bugs to roll in, as
you put it, regardless of whether we go with systemd or upstart, we
will need to build this list at some point (to measure progress, to
start with the most critical issues, and in last resort to document
remaining ones in the release notes). The earlier, the better.
I wonder how spread out the information is. Does the resolution of
these problems live primarily in upstart jobs (easily gathered), or in
other kinds of Ubuntu-specific patches (flagged in a special way to
make upstreaming easier, I would hope), or elsewhere? If the answer is
"meld in various kinds of Ubuntu-specific patches", how do we identify
the relevant bits?

It seems to me that the answer to this last set of questions is not
only relevant in case we pick systemd, but also if we choose upstart:
if *gathering* this list of problems and (upstart-specific) solutions
is hard for Debian+systemd, then I fail to see why it would be easy
for Debian+upstart.

If we agree that compiling this list will be needed at some point
anyway, I'm now wondering if it would perhaps be useful input for the
current decision making process: not only it would help us assert the
scope of the problem, but it would avoid a potential outcome I am
personally scared about: after picking upstart in part because
integrating it would be so much easier, realizing later that, oh well,
the best we can do is often to go dig stuff from
https://patches.ubuntu.com/ as we see bug reports roll in.

> [...] no other distribution that has adopted systemd has dealt with
> these issues yet.

If I were among the ones who make the decision, I would want to see
this statement supported by a list of bugs caused by this fact, that
were reported against distributions that ship systemd by default.
Anyway, I'm curious, but if I'm the only one who cares, please don't
waste your time on it :)

Also, I suppose that Red Hat is actively tackling these issues, with
RHEL7 now in beta. It is not clear to me what amount of their fixes we
can (find and) take if we pick systemd. Same here, depends how broadly
the fixes are gathered, and how deeply they are meld in with changes
we do not care about, I guess.

> If we decide for systemd, what do you think is the right way to
> mitigate such problems for jessie?  Some of these issues are only going to
> be seen once people start making use of systemd in anger with their existing
> server configs (e.g., an ec2 VM with a simple disk and network config is not
> going to expose these problems), and I don't really think we want to do this
> by way of switching the default in unstable and waiting for the bugs to roll
> in.

I think that designing a good plan depends quite a bit on the answer
to questions above, wrt. reusing the list of race conditions
identified by Ubuntu, and the corresponding list of fixes.

Cheers,
-- 
  intrigeri
  | GnuPG key @ https://gaffer.ptitcanardnoir.org/intrigeri/intrigeri.asc
  | OTR fingerprint @ https://gaffer.ptitcanardnoir.org/intrigeri/otr.asc


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#733233: RFH: software-center -- Utility for browsing, installing, and removing software

2014-01-02 Thread Jordan Metzmeier

I had a quick look at the existing package. It appears to be a native package 
and the 
changes were made prior to repacking. Is there a vcs that shows the changes you 
had to 
make to upstream for the existing package?

Regards,
Jordan Metzmeier


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#734011: Can’t build a package using closure-compiler

2014-01-02 Thread Ben Finney

package wnpp
block 726171 by 734011
severity 734011 important
thanks

On 02-Jan-2014, David Prévot wrote:
> Calling closure-compiler inside pbuilder or sbuild (e.g. from d/rules)
> fails with:
> 
>   run-detectors: unable to find an interpreter for 
> /usr/bin/closure-compiler
> 
> It works fine with debuild, and closure-compiler can even be called
> without error in a minimal (pbuilder) chroot, but not during a “normal”
> build.

I get the same error in a PBuilder chroot:

run-detectors: unable to find an interpreter for /usr/bin/closure-compiler

And even when invoking the command from a plain prompt in the chroot:

# /usr/bin/closure-compiler 
run-detectors: unable to find an interpreter for /usr/bin/closure-compiler

Since this now breaks when using a number of package build tools, this bug
is IMO an “important” severity.

-- 
 \  “I find the whole business of religion profoundly interesting. |
  `\ But it does mystify me that otherwise intelligent people take |
_o__)it seriously.” —Douglas Adams |
Ben Finney 


signature.asc
Description: Digital signature

Bug#734019: RFS: python-nagiosplugin/1.2-1 -- Python class library for writing Nagios (Icinga) plugins

2014-01-02 Thread Jordan Metzmeier

Package: sponsorship-requests
Severity: wishlist

Dear mentors,

I am looking for a sponsor for my package "python-nagiosplugin":

dget  -x 
http://mentors.debian.net/debian/pool/main/n/nagiosplugin/nagiosplugin_1.2-1.dsc

It builds these binary packages:

  python-nagiosplugin - Python class library for writing Nagios (Icinga) plugins

More information about python-nagiosplugin can be obtained from 
https://pypi.python.org/pypi/nagiosplugin/

This upload will close the ITP #733822, The package is lintian clean.

Most administrators who work with nagios have had to write custom plugins for 
their 
specific environments. This module makes it easy. It has all the features you 
would expect, 
along with good documentation and examples.

Regards,
Jordan Metzmeier


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#721659: key generation hangs Pidgin for an extended period

Control: tag -1 + upstream

Hi Russ,

Russ Allbery wrote (02 Sep 2013 20:23:52 GMT) :
> The windows stop refreshing, there is no progress bar or other
> visual feedback on how long the process will take, all messages from
> other conversations are ignored, and the process takes long enough
> that it looks like Pidgin has locked up.

Thank you for reporting this bug; I am glad OTR is seeing more
widespread use, and I expect your report will be helpful for other
users who encounter this problem and may wonder if Pidgin is
permanently frozen, or if the process will finish eventually.

I'm tagging this "upstream" as this user experience problem is not
specific to Debian. At least one of the OTR upstream developers (Ian
Goldberg) is subscribed to this package in the Debian BTS.

Ian, any chance that the port to Pidgin 3 fixes this problem?

If it does not, well... I'm no HCI expert at all, and I Cc'd a fellow
Tails developer who clearly knows better than me, in case they want to
have a look. Still, here is my understanding of the GNOME HIG [1]
applied to this specific problem:

a. Ideally, the key generation should be generated in ahead and in the
background, before the user even needs it; failing that, allow
users to interact with other parts of Pidgin. As Russ noted, this
may very well not be possible in the current state of Pidgin
plugin API.

b. If the length of key generation can be approximately predicted
(depends on which one of /dev/{,u}random is used, I guess), use
a measured progress bar. Else, use an indeterminate-progress
indicator [2].

I suspect that the low-hanging fruit here is the
indeterminate-progress indicator, that probably has a pretty good
"effort / user experience improvement" ratio. My experience with GTK
development is limited to Perl and Python, so I'm afraid I cannot come
up with a patch here, but I would be surprised if adding this widget
was anything but trivial (the GTK main loop cannot be frozen during
the key generation, really?).

[1] https://developer.gnome.org/hig-book/stable/
[2]
https://developer.gnome.org/hig-book/stable/controls-progress-bars.html.en#indeterminate-progress

To end with, FWIW installing haveged mitigates this problem. I suspect
using an Entropy Key also does.

Cheers,
--
intrigeri
| GnuPG key @ https://gaffer.ptitcanardnoir.org/intrigeri/intrigeri.asc
| OTR fingerprint @ https://gaffer.ptitcanardnoir.org/intrigeri/otr.asc

--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#506369: Also with pidgin in exp

Hi Joachim,

Joachim Breitner wrote (21 Nov 2008 17:40:16 GMT) :
> same behavior happens when using the pidgin version in experimental.

Can you still reproduce this on current Debian stable or newer?

Cheers,
--
  intrigeri
  | GnuPG key @ https://gaffer.ptitcanardnoir.org/intrigeri/intrigeri.asc
  | OTR fingerprint @ https://gaffer.ptitcanardnoir.org/intrigeri/otr.asc


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#575461: finch: ability to use OTR-encryption

Hi,

at this point of the discussion (both here and with upstream), it
seems to me that this bug has nothing to do anymore on the pidgin-otr
bugs list. It should be converted into a RFP (request for package)
asking for purple-otr, right? I'm happy to do so if Thibaut or Howard
give me a go-ahead.

Cheers,
--
  intrigeri
  | GnuPG key @ https://gaffer.ptitcanardnoir.org/intrigeri/intrigeri.asc
  | OTR fingerprint @ https://gaffer.ptitcanardnoir.org/intrigeri/otr.asc


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#712451: apparmor not support network rule

Control: tag -1 upstream

intrigeri wrote (16 Jun 2013 13:26:27 GMT) :
> The action that should be taken now belongs upstream.

Flagging as such: IMO it is not Debian's responsibility to fix the
situation. AppArmor userspace has been depending on out-of-tree kernel
patches since at least Linux 2.6.36, and there is little we can do
about it.


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#712050: linux: Apparmor not working with kernels after wheezy

Control: fixed -1 2.8.0-1

Hi,

intrigeri wrote (15 Jun 2013 11:10:11 GMT) :
> falconbird, please do consider using a *working* email address in
> here. Otherwise, you're adding unnecessary noise to everyone
> involved's mailbox. Thanks in advance :)

Six months later, no info came in. I still cannot reproduce it on
current sid, and I think we can bet that 2.8 fixed it, given the
reporter has seen this working on Debian with Ubuntu's AppArmor 2.8 in
the past. Closing.

Cheers,
--
  intrigeri
  | GnuPG key @ https://gaffer.ptitcanardnoir.org/intrigeri/intrigeri.asc
  | OTR fingerprint @ https://gaffer.ptitcanardnoir.org/intrigeri/otr.asc


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#734018: [nm.debian.org] Debian Contributors page confused

2014-01-02 Thread Filipus Klutiero


Package: nm.debian.org
Severity: normal

https://contributors.debian.org/ lists Debian contributors. The page's 
description reads:

This is a list of all the people who contribute to Debian, to the best of our current knowledge . 


The description is followed by numerous lists (one per year). No one is labelled as a 
current contributor. Unless one takes the list of 6 people from 2014 as the list of 
current contributors, one can interpret than either no one contributes to Debian or that 
everyone on the page contributes to Debian. While there may be cases where it is 
difficult to say if someone "contributes to Debian", it is certainly hard to 
defend the latter interpretation when the lists contains contributors who have been 
resting in peace for years.


I am not a native English speaker, but I think changing "who contribute" to "who have 
contributed" would solve that. If not, a "different phrasing" could work around that:

This is a list of all Debian contributors, to the best of our current knowledge. 


That being said, I'm not sure splitting people by year (by default) is a good 
idea. It will already be hard enough to find someone via account names.

--
Filipus Klutiero
http://www.philippecloutier.com

Bug#733319: [psi-plus-plugins] OTR conversations between psi-plus and pidgin sometimes don't work

Ian Goldberg wrote (03 Jan 2014 00:33:27 GMT) :
> To be clear, it *could* still be a bug in libotr.

Ooops, my reassignment of this bug might be proven wrong then,
if someone debugs this far enough. Sorry if that's the case.

Cheers,
-- 
  intrigeri
  | GnuPG key @ https://gaffer.ptitcanardnoir.org/intrigeri/intrigeri.asc
  | OTR fingerprint @ https://gaffer.ptitcanardnoir.org/intrigeri/otr.asc


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#734017: texlive-base: Installation fails

2014-01-02 Thread John O'Hagan

Package: texlive-base
Version: 2013.20131219-1
Severity: grave
Justification: renders package unusable

Dear Maintainer,

Installation of the package fails, here is the output of aptitude:

root@mini:/home/john# aptitude install texlive-base
The following NEW packages will be installed:
  texlive-base
The following packages are RECOMMENDED but will NOT be installed:
  lmodern
0 packages upgraded, 1 newly installed, 0 to remove and 0 not upgraded.
Need to get 0 B/16.1 MB of archives. After unpacking 44.1 MB will be used.
Preconfiguring packages ...
Selecting previously unselected package texlive-base.
(Reading database ... 180342 files and directories currently installed.)
Preparing to unpack .../texlive-base_2013.20131219-1_all.deb ...
Unpacking texlive-base (2013.20131219-1) ...
Processing triggers for mime-support (3.54) ...
Processing triggers for menu (2.1.46) ...
Processing triggers for man-db (2.6.5-2) ...
Processing triggers for install-info (5.2.0.dfsg.1-2) ...
Setting up texlive-base (2013.20131219-1) ...
cp: ‘/var/lib/ucf/hashfile.6’ and ‘/var/lib/ucf/hashfile.7’ are the
same file
dpkg: error processing package texlive-base (--configure):
 subprocess installed post-installation script returned error exit status 1
Errors were encountered while processing:
 texlive-base
E: Sub-process /usr/bin/dpkg returned an error code (1)
A package failed to install.  Trying to recover:
Setting up texlive-base (2013.20131219-1) ...
cp: ‘/var/lib/ucf/hashfile.6’ and ‘/var/lib/ucf/hashfile.7’ are the
same file
dpkg: error processing package texlive-base (--configure):
 subprocess installed post-installation script returned error exit status 1
Errors were encountered while processing:
 texlive-base



-- Package-specific info:
IMPORTANT INFORMATION: We will only consider bug reports concerning
the packaging of TeX Live as relevant. If you have problems with
combination of packages in a LaTeX document, please consult your
local TeX User Group, the comp.text.tex user group, the author of
the original .sty file, or any other help resource. 

In particular, bugs that are related to up-upstream, i.e., neither
Debian nor TeX Live (upstream), but the original package authors,
will be closed immediately.

   *** The Debian TeX Team is *not* a LaTeX Help Desk ***

If you report an error when running one of the TeX-related binaries 
(latex, pdftex, metafont,...), or if the bug is related to bad or wrong
output, please include a MINIMAL example input file that produces the
error in your report.

Please run your example with
(pdf)latex -recorder ...
(or any other program that supports -recorder) and send us the generated
file with the extension .fls, it lists all the files loaded during
the run and can easily explain problems induced by outdated files in
your home directory.

Don't forget to also include minimal examples of other files that are 
needed, e.g. bibtex databases. Often it also helps
to include the logfile. Please, never send included pictures!

If your example file isn't short or produces more than one page of
output (except when multiple pages are needed to show the problem),
you can probably minimize it further. Instructions on how to do that
can be found at

http://www.minimalbeispiel.de/mini-en.html (english)

or 

http://www.minimalbeispiel.de/mini.html (german)

##
minimal input file


##
other files

##
 List of ls-R files

-rw-r--r-- 1 root root 320 Jan  3 12:36 /var/lib/texmf/ls-R
lrwxrwxrwx 1 root root 29 Jun 15  2013 /usr/share/texmf/ls-R -> 
/var/lib/texmf/ls-R-TEXMFMAIN
lrwxrwxrwx 1 root root 31 Dec 19 16:07 /usr/share/texlive/texmf-dist/ls-R -> 
/var/lib/texmf/ls-R-TEXLIVEDIST
lrwxrwxrwx 1 root root 31 Dec 19 16:07 /usr/share/texlive/texmf-dist/ls-R -> 
/var/lib/texmf/ls-R-TEXLIVEDIST
##
 Config files
-rw-r--r-- 1 root root 475 Oct  8 10:40 /etc/texmf/web2c/texmf.cnf
-rw-r--r-- 1 root root 2358 Jan  3 12:36 /var/lib/texmf/web2c/fmtutil.cnf
lrwxrwxrwx 1 root root 37 Dec 19 16:07 
/usr/share/texlive/texmf-dist/web2c/updmap.cfg -> 
/var/lib/texmf/updmap.cfg-TEXLIVEDIST
-rw-r--r-- 1 root root 504 Jan  3 12:36 
/var/lib/texmf/tex/generic/config/language.dat
##
 Files in /etc/texmf/web2c/
total 8
-rw-r--r-- 2 root root 283 Mar 23  2011 mktex.cnf
-rw-r--r-- 1 root root 475 Oct  8 10:40 texmf.cnf
##
 md5sums of texmf.d
ca40c66f144b4bafc3e59a2dd32ecb9c  /etc/texmf/texmf.d/00debian.cnf

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

Kernel: Linux 3.11-2-amd64 (SMP w/2 CPU cores)
Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages texlive-base depends on:
ii  debconf [debconf-2.0]  1.5.52
ii  dpkg   1.17.5
ii  libpaper-utils

Bug#734016: qgo: segmentation fault on Talk via double click on name

2014-01-02 Thread Linus Lüssing

Package: qgo
Version: 2.0~git-20131123-1
Severity: normal


When trying to open a talk via a double click on a name in the players
list, qgo crashes with a segmentation fault.

Opening a talk via a right click and selecting "Talk" works fine though.

Here's a backtrace created via gdb:


---
$ gdb qgo
GNU gdb (GDB) 7.6.1 (Debian 7.6.1-1)
Copyright (C) 2013 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".
For bug reporting instructions, please see:
...
Reading symbols from /usr/games/qgo...(no debugging symbols found)...done.
(gdb) run
Starting program: /usr/games/qgo
warning: Could not load shared library symbols for linux-vdso.so.1.
Do you need "set solib-search-path" or "set sysroot"?
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
[New Thread 0x7fffeb065700 (LWP 7258)]
Error:Key "" added to modifier map for multiple modifiers; Using 
Mod3, ignoring Mod5
Fontconfig warning: "/etc/fonts/conf.d/65-ttf-sil-andika.conf", line 14: Having 
multiple values in  isn't supported and may not work as expected
Fontconfig warning: "/etc/fonts/conf.d/65-ttf-sil-andika.conf", line 32: Having 
multiple  in  isn't supported and may not work as expected
Fontconfig warning: "/etc/fonts/conf.d/65-ttf-sil-andika.conf", line 32: Having 
multiple  in  isn't supported and may not work as expected
Fontconfig warning: "/etc/fonts/conf.d/65-ttf-sil-andika.conf", line 32: Having 
multiple  in  isn't supported and may not work as expected
Fontconfig warning: "/etc/fonts/conf.d/65-ttf-sil-andika.conf", line 32: Having 
multiple  in  isn't supported and may not work as expected
Fontconfig warning: "/etc/fonts/conf.d/65-ttf-sil-andika.conf", line 32: Having 
multiple  in  isn't supported and may not work as expected
Fontconfig warning: "/etc/fonts/conf.d/65-ttf-sil-andika.conf", line 32: Having 
multiple  in  isn't supported and may not work as expected
Fontconfig warning: "/etc/fonts/conf.d/65-ttf-sil-andika.conf", line 32: Having 
multiple  in  isn't supported and may not work as expected
Home Path : /new-home/linus
Current Path : /new-home/linus
defaultServiceProvider::requestService(): no service found for - 
"org.qt-project.qt.mediaplayer"
Connecting to igs.joyjoy.net ...

[New Thread 0x7fffdc66e700 (LWP 7259)]
rank spread : NR - 9p
Login found

:10 ??
1 1


Password prompt or 1 1 found
sendText: toggle looking  false

sendText: toggle open  false

sendText: join 0

Joining 0
Ready!

Creating Talk for

Program received signal SIGSEGV, Segmentation fault.
0x761ea12b in operator==(QString const&, QString const&) ()
   from /usr/lib/x86_64-linux-gnu/libQt5Core.so.5
(gdb) bt
#0  0x761ea12b in operator==(QString const&, QString const&) ()
   from /usr/lib/x86_64-linux-gnu/libQt5Core.so.5
#1  0x7731ea65 in QLabel::setText(QString const&) () from 
/usr/lib/x86_64-linux-gnu/libQt5Widgets.so.5
#2  0x0051665b in ?? ()
#3  0x00516910 in ?? ()
#4  0x0051069f in ?? ()
#5  0x005607c5 in ?? ()
#6  0x76348226 in QMetaObject::activate(QObject*, int, int, void**) ()
   from /usr/lib/x86_64-linux-gnu/libQt5Core.so.5
#7  0x77404955 in QAbstractItemView::doubleClicked(QModelIndex const&) 
()
   from /usr/lib/x86_64-linux-gnu/libQt5Widgets.so.5
#8  0x77412855 in 
QAbstractItemView::mouseDoubleClickEvent(QMouseEvent*) ()
   from /usr/lib/x86_64-linux-gnu/libQt5Widgets.so.5
#9  0x77221d84 in QWidget::event(QEvent*) () from 
/usr/lib/x86_64-linux-gnu/libQt5Widgets.so.5
#10 0x7731b81e in QFrame::event(QEvent*) () from 
/usr/lib/x86_64-linux-gnu/libQt5Widgets.so.5
#11 0x774122eb in QAbstractItemView::viewportEvent(QEvent*) ()
   from /usr/lib/x86_64-linux-gnu/libQt5Widgets.so.5
#12 0x763228e3 in 
QCoreApplicationPrivate::sendThroughObjectEventFilters(QObject*, QEvent*) ()
   from /usr/lib/x86_64-linux-gnu/libQt5Core.so.5
#13 0x771e7f2c in QApplicationPrivate::notify_helper(QObject*, QEvent*) 
()
   from /usr/lib/x86_64-linux-gnu/libQt5Widgets.so.5
#14 0x771ed89b in QApplication::notify(QObject*, QEvent*) ()
   from /usr/lib/x86_64-linux-gnu/libQt5Widgets.so.5
#15 0x763226bd in QCoreApplication::notifyInternal(QObject*, QEvent*) ()
   from /usr/lib/x86_64-linux-gnu/libQt5Core.so.5
#16 0x771ebbc1 in QApplicationPrivate::sendMouseEvent(QWidget*, 
QMouseEvent*, QWidget*, QWidget*, QWidget**, QPointer&, bool) () from 
/usr/lib/x86_64-linux-gnu/libQt5Widgets.so.5
#17 0x7723d86f in ?? () from 
/usr/lib/x86_64-linux-gnu/libQt5Widgets.so.5
#18 0x7723f583 in ?? () from 
/usr/lib/x86_64-linux-gnu/libQt5Widgets.so.5
#1

Bug#734015: test

package: foobarcatchall

please ignore - thanks


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#734010: qgo: Servers in "Connect" window vanished

2014-01-02 Thread Linus Lüssing

Ok, I figured that it's not actually the servers having vanished.
Instead the layout of the "Connect" menu changed.

However, my credentials on IGS were deleted in qgo and I had to
readd them manually in the new menu (luckily I could still
remember them).

A migration path would have been nicer.


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#670170: apparmor: should load profiles before networking is setup

Control: tag -1 - patch
Control: block -1 by 727708

Hi,

Kees Cook wrote (25 Apr 2012 00:07:50 GMT) :
> This init script is shared between Debian and Ubuntu, so we can't modify
> it as you've suggested. In fact, Debian's lack of caching means it's
> even more critical to use the "xargs -P" path to avoid big delays at boot.

> I'd like to find a way to handle early loading of profiles in some
> other way. Ubuntu's network bring-up via upstart will actually run
> apparmor_parser directly for any profiles that have been linked into a
> special directory. I think it would probably make sense to put this into
> the init scripts of any services that want to load a profile before the
> main AppArmor init script runs.

FTR, I've given up fixing this for sysvinit a while ago. I have
personally moved on to a modern init system for 18 months and never
felt the need to turn back. Since then, unsurprisingly, any interest
I might have had into investing time to work around deficiencies in
the sysvinit model has seriously dropped. I'm sorry I did not state
this clearly on this bug earlier.

So, I'm now postponing working on this any further until the Technical
Committee has made a decision regarding Jessie's default init system.
If they pick systemd or upstart, which seems highly likely now, then
we'll finally be able to fix this issue properly for the Linux
architectures, that are the only ones supporting AppArmor anyway.

To complete my analysis, I don't think this bug is important enough to
be worth fixing in the current stable release (Wheezy), that's why I'm
marking it as blocked by the TC one.

Cheers,
--
  intrigeri
  | GnuPG key @ https://gaffer.ptitcanardnoir.org/intrigeri/intrigeri.asc
  | OTR fingerprint @ https://gaffer.ptitcanardnoir.org/intrigeri/otr.asc


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#734014: poppler: Use autotools-dev to keep config.{sub, guess} up to date for portability

2014-01-02 Thread Wookey

Source: poppler
Version: 0.18.4-9
Severity: normal
Tags: patch
User: debian-...@lists.debian.org
Usertag: arm64

This package FTBFS on arm64 due to outdated config.{sub,guess} files.
Enabling the usage of the autotools-dev that it already depends on,
fixes this. This patch will keep it fixed for future new architectures too.

-- System Information:
Debian Release: 7.3
  APT prefers stable
  APT policy: (990, 'stable')
Architecture: i386 (i686)

Kernel: Linux 3.2.0-kvm-i386-20110111 (SMP w/1 CPU core)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash
diff -Nru poppler-0.18.4/debian/changelog poppler-0.18.4/debian/changelog
--- poppler-0.18.4/debian/changelog	2013-11-17 18:00:45.0 +
+++ poppler-0.18.4/debian/changelog	2013-12-28 03:53:31.0 +
@@ -1,3 +1,9 @@
+poppler (0.18.4-9arm64) unstable; urgency=low
+
+  * Update config.sub/guess to build on new architectures 
+
+ --Sat, 28 Dec 2013 03:52:28 +
+
 poppler (0.18.4-9) unstable; urgency=medium
 
   * Remove the custom RPATH handing on Hurd, since the issue does not affect
diff -Nru poppler-0.18.4/debian/rules poppler-0.18.4/debian/rules
--- poppler-0.18.4/debian/rules	2013-11-17 17:28:32.0 +
+++ poppler-0.18.4/debian/rules	2013-12-28 03:51:42.0 +
@@ -34,9 +34,11 @@
 
 override_dh_auto_clean:
 	dh_auto_clean
+	dh_autotools-dev_restoreconfig
 	rm -f glib/reference/html/*
 
 override_dh_auto_configure:
+	dh_autotools-dev_updateconfig
 	dh_auto_configure -- $(CONFIGURE_ARGS)
 
 override_dh_auto_install:

Bug#734013: usbredir: [PATCH] Enable ppc64el port compilation

2014-01-02 Thread Daniel T Chen

Package: usbredir
Version: 0.6-2
Severity: wishlist
Tags: patch
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu trusty ubuntu-patch

Dear Maintainer,

In Ubuntu 14.04, the attached patch was applied to achieve the following:

  * Use dh-autoreconf, resolving FTBFS on ppc64el.


This debdiff may contain extraneous metadata. If so, kindly please
ignore those portions. Thanks for considering the patch!


-- System Information:
Debian Release: wheezy/sid
  APT prefers precise-updates
  APT policy: (500, 'precise-updates'), (500, 'precise-security'), (500, 
'precise'), (100, 'precise-backports')
Architecture: amd64 (x86_64)

Kernel: Linux 3.11.0-14-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
diff -Nru usbredir-0.6/debian/changelog usbredir-0.6/debian/changelog
diff -Nru usbredir-0.6/debian/control usbredir-0.6/debian/control
--- usbredir-0.6/debian/control	2013-05-09 10:18:04.0 -0400
+++ usbredir-0.6/debian/control	2014-01-02 20:43:35.0 -0500
@@ -1,8 +1,9 @@
 Source: usbredir
 Section: libs
 Priority: optional
-Maintainer: Liang Guo 
-Build-Depends: debhelper (>= 9), autotools-dev, libusb-1.0-0-dev, pkg-config
+Maintainer: Ubuntu Developers 
+XSBC-Original-Maintainer: Liang Guo 
+Build-Depends: debhelper (>= 9), dh-autoreconf, libusb-1.0-0-dev, pkg-config
 Standards-Version: 3.9.3
 Homepage: http://www.spice-space.org/
 Vcs-Git: git://git.debian.org/collab-maint/usbredir.git
diff -Nru usbredir-0.6/debian/rules usbredir-0.6/debian/rules
--- usbredir-0.6/debian/rules	2012-12-30 09:05:46.0 -0500
+++ usbredir-0.6/debian/rules	2014-01-02 20:44:16.0 -0500
@@ -7,4 +7,4 @@
 
 
 %:
-	dh $@ 
+	dh $@ --with autoreconf

Bug#734012: RFS: mapserver/6.4.1-1

Package: sponsorship-requests
Severity: normal

Dear mentors,

I am looking for a sponsor for my package "mapserver"

 Package name: mapserver
 Version : 6.4.1-1
 Upstream Author : The MapServer team
 URL : http://www.mapserver.org
 License : MIT/X11
 Section : devel

It builds those binary packages:

 cgi-mapserver - CGI executable for MapServer
 libmapscript-perl - Perl MapServer module
 libmapscript-ruby - Transitional dummy package for ruby-mapscript
 libmapscript-ruby1.8 - Transitional package from libmapscript-ruby1.8 to 
ruby-mapscript
 libmapscript-ruby1.9.1 - Transitional package from libmapscript-ruby1.9.1 to 
ruby-mapscript
 libmapserver - Dummy package for libmapserver to libmapserver1 transition
 libmapserver-6.2.1 - Dummy package for libmapserver-6.2.1 to libmapserver1 
transition
 libmapserver-6.2.1-dev - Dummy package for libmapserver1-dev transition
 libmapserver-dev - Transitional dummy package for libmapserver1-dev
 libmapserver1 - Shared library for MapServer
 libmapserver1-dev - Shared library development files for MapServer
 mapserver-bin - MapServer utilities
 mapserver-doc - documentation for MapServer
 php5-mapscript - php5-cgi module for MapServer
 python-mapscript - Python library for MapServer
 ruby-mapscript - MapServer library for Ruby

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

http://mentors.debian.net/package/mapserver


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

  dget -x 
http://mentors.debian.net/debian/pool/main/m/mapserver/mapserver_6.4.1-1.dsc

More information about MapServer can be obtained from http://www.mapserver.org/.

Changes since the last upload:

 * New upstream release, fixes a vulnerability leading to potential leakage of
   information when using TIME filtering on postgis layers.
 * Refresh patches.
 * Drop freetype2-include-dir.patch, applied upstream in modified form.
 * Bump Standards-Version to 3.9.5, no changes required.
 * Add lintian override for debian-watch-may-check-gpg-signature,
   upstream doesn't provide signatures for verification.
 * Update copyright file.
 * Update symbols file.


Regards,
 Sebastiaan Couwenberg


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#727708: upstart and upgrading from sysvinit scripts

2014-01-02 Thread Steve Langasek

To wrap up this subthread, I want to state clearly for the record that the
answers that have been given here have addressed my concerns about the
raciness of systemd socket activation.  It appears that the state of the art
is rather substantially improved since the last time I had looked at
Fedora's systemd deployment - I suspect as a result of continued feature
development in systemd upstream that closed the gaps I'd previously
identified.  Whatever the cause, while I don't believe that socket-based
activation is strictly a necessary feature for the next generation init
solution, I am satisfied that the systemd implementation of it isn't
actively detrimental to the reliability or security of our systems.  (With
my upstream hat, I am also convinced that further development is warranted
on upstart's socket activation implementation, to bring it to feature parity
with systemd's.)

On Sun, Dec 29, 2013 at 10:37:10AM -0800, Russ Allbery wrote:
> > Indeed, when I looked at this problem on an earlier version of Fedora, I
> > found what I believe to be a latent security problem in the cups units,
> > because it was nondeterministic whether the service would start with
> > sockets passed from systemd, or a different set of sockets as defined in
> > the cups config!

> Did the cups service unit explicitly depend on its socket unit?

At this point, I certainly can't remember - bearing in mind that at the time
I was doing a comparative analysis for purposes of improving upstart, not to
evaluate systemd for adoption, so having identified a critical problem I
didn't dig very much farther to determine if this was fixable within the
constraints of systemd's dependency system.

Thanks,
-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developerhttp://www.debian.org/
slanga...@ubuntu.com vor...@debian.org

signature.asc
Description: Digital signature

Bug#723573: xterm occasionally forgets BackSpace translation

2014-01-02 Thread Thomas Dickey

On Thu, Jan 02, 2014 at 11:44:09AM +, Zefram wrote:
> retitle 723573 usual translations not applied when focus is on scrollbar
> thanks
> 
> I've managed to reliably reproduce the problem.  When the mouse pointer
> is located on the xterm's scrollbar, showing the up-and-down-arrow mouse
> cursor, none of the translations in the "XTerm.vt100.translations"

which translation was performing the backspace?

> resource get applied.  This doesn't only affect backspace, it also
> affects some scrolling keys that I've set up in the same resource.
> The translations are applied normally when the mouse pointer is in the
> text part of the xterm, showing the I-beam mouse cursor, and when the
> mouse pointer is on the window frame or titlebar, showing a mouse cursor
> determined by the window manager.  Toggling the backspace option fixed
> the problem merely by virtue of moving the mouse off the scrollbar.
> 
> The man page contains an oblique note about applying different
> translations in the scrollbar context.  (It talks about changing mouse
> button behaviour, not keys.)  It shows a resource name pattern of

yes... I added that a while back, because there was no documentation at
all on the scrollbar translations, aside from reading the code.

> "*VT100.scrollbar.translations".  Based on that, I've tried setting
> a resource under the name "XTerm.vt100.scrollbar.translations", and
> it turns out that the scrollbar context obeys translations that are
> placed there.  As a permanent change, I've changed my resource settings
> to specify the translations under a key of "XTerm.vt100*translations"
> instead of "XTerm.vt100.translations".  Empirically this fixes the issue:
> the translations now apply when focus is on the scrollbar as well as in
> the other focus states.

As long as the translations merge rather than override, that's a good solution.
 
> So it may possibly be a bug that, in the absence of an overriding
> XTerm.vt100.scrollbar.translations, XTerm.vt100.translations isn't applied
> when focus is on the scrollbar.  Don't know whether that's intentional.
> But it is certainly a bug that the names by which translation resources
> are looked up are inadequately documented.  The man page describes

thanks - I'll improve that part of the documention, taking your comments into 
account.

> "translations" only as a resource for the "vt100" widget, not for the
> "scrollbar" widget (except for the implication of the example in a
> different section of the doc), and has no mention of translations being
> applied differently depending on focus.

in addition to translations, the two (scrollbar and terminal window) have 
different
input-method contexts - no easy solution for that.

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


signature.asc
Description: Digital signature

Bug#734011: Can’t build a package using closure-compiler

2014-01-02 Thread David Prévot

Package: libclosure-compiler-java
Version: 20130227+dfsg1-4
Severity: normal
Control: block 733880 by -1

Hi,

Thanks Tony for uploading a package fixing #705565.

Calling closure-compiler inside pbuilder or sbuild (e.g. from d/rules)
fails with:

run-detectors: unable to find an interpreter for 
/usr/bin/closure-compiler

It works fine with debuild, and closure-compiler can even be called
without error in a minimal (pbuilder) chroot, but not during a “normal”
build.

Regards

David

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

Kernel: Linux 3.12-1-rt-amd64 (SMP w/1 CPU core; PREEMPT)
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages libclosure-compiler-java depends on:
ii  default-jre-headless  1:1.7-50
ii  jarwrapper0.45
ii  libandroid-json-org-java  20121204-20090211-1
ii  libargs4j-java2.0.25-1
ii  libguava-java 15.0-2

libclosure-compiler-java recommends no packages.

Versions of packages libclosure-compiler-java suggests:
pn  libclosure-compiler-java-doc  

-- no debconf information


signature.asc
Description: Digital signature

Bug#734010: qgo: Servers in "Connect" window vanished

2014-01-02 Thread Linus Lüssing

Package: qgo
Version: 2.0~git-20131123-1
Severity: grave
Justification: renders package unusable

Hi,

Since the upgrade of qgo a couple of days ago, version
2.0~git-20130914-1 to 2.0~git-20131123-1, I'm not able to connect to any
Go server anymore. After clicking on "Connect" the list of servers is
just empty now.

Cheers, Linus


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

Kernel: Linux 3.12-1-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash

Versions of packages qgo depends on:
ii  libc6 2.17-97
ii  libgcc1   1:4.8.2-11
ii  libgl1-mesa-glx [libgl1]  9.2.2-1
ii  libpulse0 4.0-6+b1
ii  libqt5core5   5.1.1+dfsg-6
ii  libqt5gui55.1.1+dfsg-6
ii  libqt5multimedia5 5.1.1-2
ii  libqt5network55.1.1+dfsg-6
ii  libqt5widgets55.1.1+dfsg-6
ii  libstdc++64.8.2-11

qgo recommends no packages.

Versions of packages qgo suggests:
ii  gnugo  3.8-7

-- no debconf information


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#733746: dpkg-source - can't build with source format '3.0 (quilt)' when version number is 1.0.0

2014-01-02 Thread Elvett Semic

Hi,

On 02.01.2014 23:49, Jonathan Nieder wrote:
> forcemerge 733746 719348
> # confusing error message
> severity 733746 minor
> quit
> 
> Hi,
> 
> Thomas Mayer wrote:
> 
>> pd-purest-json (1.0.0) UNRELEASED; urgency=low
> 
> Is this a native package?  (See [1] for what I mean.)

yes, it is a native package. Changing the format from quilt to native
fixes the issue.

Thanks,
Thomas


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#727708: init system thoughts

2014-01-02 Thread Steve Langasek

On Mon, Dec 30, 2013 at 09:52:04PM -0800, Russ Allbery wrote:
> Steve Langasek  writes:

> > Upstart (as implemented in Ubuntu) restores this guarantee (with
> > provisions for failsafe booting in the case of a wrong network config),
> > and it takes advantage of upstart's capability of sending arbitrary
> > signals to do so.  I can see how one could implement the equivalent of
> > upstart's static-network-up event on systemd, using generators.  But
> > what would the equivalent to /etc/init/failsafe.conf look like?  I think
> > this would be very difficult to express in systemd language, yet it's
> > altogether vital for providing a boot that is both reliably ordered, and
> > recoverable in the event of problems.

> I'm not sure I completely understand what failsafe.conf actually does,

The purpose of failsafe.conf is to ensure that services which have not been
converted to the native format, but instead provide initscripts that are
called upon reaching runlevel 2, are started at the right time - so that
they aren't unreliable due to racing the network stack.  This is an existing
bug on sysvinit systems, but the race is hit much less frequently there
because sysvinit is slower.

The failsafe.conf strikes a balance between never waiting for networks
(breaking services that assume the network is up) and always waiting for all
networks (breaking systems that have stale network configs in
/etc/network/interfaces), by ensuring services will start as soon as all the
static networks come up *if* they are present, and falling back to a
"reasonable" timed delay if they're not.

Without an equivalent to failsafe.conf, server systems converted from
sysvinit to systemd will find some of their (poorly-coded, but nevertheless
common and supported in Debian) services randomly failing to start on boot
where they started reliably before.

> So, in other words, assuming that I understand this correctly, the way
> that you implement this in systemd is that you add a Before= dependency to
> the network.target (hm, which implies that my assumption about things
> meddling with dependencies of core services being less likely is not as
> correct as I thought it was, although I still think it's less likely to be
> done by accident) that waits for the network to be configured, but
> implements a timeout to ensure that you don't stall forever.

From your answer and Tollef's, I'm satisfied that this requirement can be
represented in a reasonable fashion on top of systemd, probably with a
combination of an if-up.d hook (like for upstart) and a systemd unit that
wraps a script much like /etc/init/failsafe.conf to set a timeout.

I am left with the concern that I seem to be the first person to ask this
question, in discussions with the TC, six months after AIUI the systemd
maintainers considered systemd ready to be made the default.  The kinds of
race conditions that I'm highlighting here are ones that Ubuntu identified
and resolved over the course of two years of experience with Upstart in the
wild, at the cost of quite a bit of pain for Ubuntu's users in the meantime.
I fear that switching Debian to systemd by default would inflict the same
kind of pain on Debian's users, because the fixes available in Ubuntu will
not translate directly to systemd and no other distribution that has adopted
systemd has dealt with these issues yet.

Russ, the feature gaps that you rightly point out between systemd and
upstart, while they represent a significant amount of work, are all IMHO
solvable for jessie.  The integration work, in contrast, feels very
open-ended to me; I'm not worried that the work will be insurmountable, but
that we will fail to identify the issues in a timely fashion before the
jessie release.  I'm not saying this to deliberately engage in FUD by
pointing to an unquantifiable risk; I genuinely fear that this *is* a risk,
and the full extent of the risk is only becoming clear to me as a result of
these discussions.  Ifupdown integration was one of the very first things I
addressed after adopting the upstart package in Debian, and I would never
have proposed people run it on their systems without this in place.  So I
fear that switching to systemd by default is going to result in easier
package maintenance for early adopters, but a much buggier experience for
our users.  If we decide for systemd, what do you think is the right way to
mitigate such problems for jessie?  Some of these issues are only going to
be seen once people start making use of systemd in anger with their existing
server configs (e.g., an ec2 VM with a simple disk and network config is not
going to expose these problems), and I don't really think we want to do this
by way of switching the default in unstable and waiting for the bugs to roll
in.

Perhaps you're right that there is such a night and day difference between
systemd and upstart that it warrants us redoing the integration work on top
of systemd that has already been done on top of upstart in Ubuntu.  B

Bug#734009: auto-compile noise can't be avoided by script

2014-01-02 Thread Zefram

Package: guile-2.0
Version: 2.0.9+1-1
Severity: important

Guile 2.0 has a facility to automatically cache a compiled version of any
Scheme source file that it loads, and it wants the world to know about it!
If auto-compilation is enabled, which it is by default, then when guile
loads a file (that was not already compiled) it emits a banner describing
the auto-compilation.  This interferes with the proper functionality
of any program written as a guile script, by producing output that the
program did not intend.  I have tried to work around this, and although
a command-line switch can turn off the auto-compilation, it's a switch
that isn't recognised by earlier versions of guile, so there's no way for
a script to avoid the noise while being portable between guile versions
1.8 and 2.0.  There's also no way to avoid the noise and actually get
the auto-compilation behaviour.

I am mainly concerned about being portable between versions while
avoiding the noise.  In my particular case, my script uses the
read-eval (#.) feature, which means that the compilation process
actually can't work.  (I have good reason for this, and for related
reasons the auto-compilation is also of essentially no value for
this script.)  This means that *every* time the script is run, not
just the first time, guile emits the banner about auto-compilation,
followed by a rather misleading warning/error about compilation failure.
It's misleading because it then goes on to execute the script just fine.
I can demonstrate this with a minimal test case:

$ cat t0
#!/usr/bin/guile -s
!#
(fluid-set! read-eval? #t)
(display #."hello world")
(newline)
$ guile-1.8 -s t0
hello world
$ guile-2.0 -s t0
;;; note: auto-compilation is enabled, set GUILE_AUTO_COMPILE=0
;;;   or pass the --no-auto-compile argument to disable.
;;; compiling /home/zefram/usr/lucifex/on_guile/t0
;;; WARNING: compilation of /home/zefram/usr/lucifex/on_guile/t0 failed:
;;; ERROR: #. read expansion found and read-eval? is #f.
hello world
$

I can turn off the auto-compilation from within the script by using the
--no-auto-compile option, but that breaks compatibility to 1.8:

$ cat t1
#!/usr/bin/guile \
--no-auto-compile -s
!#
(fluid-set! read-eval? #t)
(display #."hello world")
(newline)
$ guile-2.0 '\' t1
hello world
$ guile-1.8 '\' t1
guile-1.8: Unrecognized switch `--no-auto-compile'
Usage: guile-1.8 OPTION ...
Evaluate Scheme code, interactively or from a script.
...

guile should not be emitting this banner by default.  It's really not
acceptable to damage the visible behaviour of a program that worked
fine on older guile versions.  It also, for this auto-compilation to
serve as the invisible optimising cache as which it's intended, ought to
keep quiet about compilation failure: the fallback to interpreting the
script should be silent.  But if such sensible behaviour is somehow not
possible, it absolutely needs to be possible for a script to turn off the
auto-compilation in a way that's compatible with guile-1.8 and earlier.
I have rated this bug "important" because of this lack of workaround.

-zefram


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#734005: error: git-svn died of signal 11 (at least doing git svn fetch/rebase)

2014-01-02 Thread Jonathan Nieder

Hi Sten,

Sten Heinze wrote:

> Running 'git svn fetch' or 'git svn rebase' results in the git-svn crashing 
> with the
> following: error: git-svn died of signal 11.

Yeah, that's no good.  Is this reproducible?

Please attach .git/config after censoring whatever seems appropriate.

[...]
> To obtain more details, I ran:
>   GIT_TRACE=1 git svn rebase
> and:
>   PERLDB_OPTS="NonStop frame=5" perl -d $(git --exec-path)/git-svn svn rebase
> and attached the output. I'm unsure about what to take from these, so any 
> information
> on how to interpret them is welcome.

I think you forgot to attach these.

Thanks,
Jonathan


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#734008: RM: haskell-hoogle [mips sparc] -- ROM; out-of-date due to haskell-src-exts

2014-01-02 Thread Clint Adams

Package: ftp.debian.org
Severity: normal

haskell-hoogle is also unable to update due to mips*/sparc buildds
failing to build haskell-src-exts


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#734007: document implicit After= of service on socket

2014-01-02 Thread Russ Allbery

Package: systemd
Version: 204-6
Severity: minor

As part of the discussion in the tech-ctte bug report, there seemed to
be general agreement (I haven't checked the source code) that systemd
automatically adds an implicit After= to a service unit on a socket
unit with the same name.  I don't think this is currently documented
in systemd.service(5).

There should probably also be a note under Sockets= saying whether
this implicit After= also applies to any units listed in Sockets=.

It may also be good to note in daemon(7) under Socket-Based Activation
(maybe, or maybe under Writing Systemd Unit Files) that service units
written to support socket activation should consider a Requires= on
the socket unit.  Without this, it's possible to get inconsistent
behavior if the service is not configured to start at boot and then
it's started manually, or if the admin disables the socket.  This may
be intentional flexibility in some cases, where the service unit is
explicitly written to support either service activation or binding its
own sockets, but I at least found the behavior without Requires= to be
surprising and unexpected.


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#734005: error: git-svn died of signal 11 (at least doing git svn fetch/rebase)

2014-01-02 Thread Sten Heinze

Package: git-svn
Version: 1:1.8.5.2-1
Severity: normal

Dear Maintainer,

(This might be a duplicate of #703524, but I don't have a backtrace, so I'm not 
sure.)

Running 'git svn fetch' or 'git svn rebase' results in the git-svn crashing 
with the
following: error: git-svn died of signal 11.

These commands were run on a checked out svn repository, which didn't exhibit 
this error
in the past.

It seems that the changesets are completely downloaded and applied to the git 
working
copy, b/c compiling succeeds; I have not compared every file to the original 
source
however.

To obtain more details, I ran:
  GIT_TRACE=1 git svn rebase
and:
  PERLDB_OPTS="NonStop frame=5" perl -d $(git --exec-path)/git-svn svn rebase
and attached the output. I'm unsure about what to take from these, so any 
information
on how to interpret them is welcome.


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

(The only packages not from testing are the kernel, mesa, and iceweasel.)

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

Versions of packages git-svn depends on:
ii  git   1:1.8.5.2-1
ii  libsvn-perl   1.7.14-1
ii  libterm-readkey-perl  2.31-1
ii  libyaml-perl  0.84-1

git-svn recommends no packages.

Versions of packages git-svn suggests:
pn  git-doc 
pn  subversion  

-- no debconf information


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#734006: document removal of PIDFile on daemon shutdown

2014-01-02 Thread Russ Allbery

Package: systemd
Version: 204-6
Severity: minor

This may already be addressed usptream, but just in case.

Zbigniew Jędrzejewski-Szmek  writes:

> systemd will unlink the pidfile after the daemon is stopped (and during
> restart, etc.). Stale files shouldn't be an issue.

This doesn't appear to be documented in systemd.service(5):

PIDFile=
Takes an absolute file name pointing to the PID file of this
daemon. Use of this option is recommended for services where Type=
is set to forking. systemd will read the PID of the main process of
the daemon after start-up of the service. systemd will not write to
the file configured here.

I think that would be a good thing to add.

-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#734004: network-manager-openvpn: NM-Openvpn ignores pushed IPV6 addresses/routes

2014-01-02 Thread Rajko Albrecht

Package: network-manager-openvpn
Version: 0.9.8.4-1
Severity: important
Tags: ipv6

Dear Maintainer,

   * What led up to the situation?
I'd try to connect to an openvpn server which is pushing ipv6 (and ipv4)
addresses to clients. When using openvpn on commandline ("openvpn --config
client.conf") the interface got a IPV6 address from server assigned which is
full working. When doing the same from within Network-Manager the ipv4 is
assigned but not the ipv6 address/route

   * What exactly did you do (or not do) that was effective (or
 ineffective)?
  Imported an existing working openvpn client configuration to network
manager openvpn module and created a config from scratch.
   * What was the outcome of this action?
  Working VPN with just an ipv4 address assigned from openvpn server. In
appended log you'll see, that it is real ignoring ipv6.

   * What outcome did you expect instead?
 A working openvpn connection having an IPV4 and an IPV6 address assigned
like running openvpn directly


Log:

Jan  3 00:43:17 NB0890-L dbus[2195]: [system] Successfully activated service
'org.freedesktop.nm_dispatcher'
Jan  3 00:43:22 NB0890-L NetworkManager[2548]:  Starting VPN service
'openvpn'...
Jan  3 00:43:22 NB0890-L NetworkManager[2548]:  VPN service 'openvpn'
started (org.freedesktop.NetworkManager.openvpn), PID 12173
Jan  3 00:43:22 NB0890-L NetworkManager[2548]:  VPN service 'openvpn'
appeared; activating connections
Jan  3 00:43:22 NB0890-L NetworkManager[2548]:  VPN plugin state changed:
starting (3)
Jan  3 00:43:22 NB0890-L NetworkManager[2548]:  VPN connection 'client-
noproxy' (Connect) reply received.
Jan  3 00:43:22 NB0890-L nm-openvpn[12176]: OpenVPN 2.3.2 x86_64-pc-linux-gnu
[SSL (OpenSSL)] [LZO] [EPOLL] [PKCS11] [eurephia] [MH] [IPv6] built on Nov 28
2013
Jan  3 00:43:22 NB0890-L nm-openvpn[12176]: WARNING: No server certificate
verification method has been enabled.  See http://openvpn.net/howto.html#mitm
for more info.
Jan  3 00:43:22 NB0890-L nm-openvpn[12176]: NOTE: the current --script-security
setting may allow this configuration to call user-defined scripts
Jan  3 00:43:22 NB0890-L nm-openvpn[12176]: UDPv4 link local: [undef]
Jan  3 00:43:22 NB0890-L nm-openvpn[12176]: UDPv4 link remote:
[AF_INET]188.40.43.245:1194
Jan  3 00:43:22 NB0890-L nm-openvpn[12176]: [] Peer Connection
Initiated with [AF_INET]XXX.XXX.XXX.245:1194
Jan  3 00:43:25 NB0890-L nm-openvpn[12176]: TUN/TAP device tun0 opened
Jan  3 00:43:25 NB0890-L nm-openvpn[12176]: /usr/lib/NetworkManager/nm-openvpn-
service-openvpn-helper tun0 1500 1542 10.8.0.4 255.255.255.0 init
Jan  3 00:43:25 NB0890-L NetworkManager[2548]: 
/sys/devices/virtual/net/tun0: couldn't determine device driver; ignoring...
Jan  3 00:43:25 NB0890-L NetworkManager[2548]:SCPlugin-Ifupdown: devices
added (path: /sys/devices/virtual/net/tun0, iface: tun0)
Jan  3 00:43:25 NB0890-L NetworkManager[2548]:SCPlugin-Ifupdown: device
added (path: /sys/devices/virtual/net/tun0, iface: tun0): no ifupdown
configuration found.
Jan  3 00:43:25 NB0890-L NetworkManager[2548]:  VPN connection 'client-
noproxy' (IP4 Config Get) reply received from old-style plugin.
Jan  3 00:43:25 NB0890-L NetworkManager[2548]:  VPN Gateway:
XXX.XXX.XXX.245
Jan  3 00:43:25 NB0890-L NetworkManager[2548]:  Tunnel Device: tun0
Jan  3 00:43:25 NB0890-L NetworkManager[2548]:  IPv4 configuration:
Jan  3 00:43:25 NB0890-L NetworkManager[2548]:Internal Gateway:
10.8.0.1
Jan  3 00:43:25 NB0890-L NetworkManager[2548]:Internal Address:
10.8.0.4
Jan  3 00:43:25 NB0890-L NetworkManager[2548]:Internal Prefix: 24
Jan  3 00:43:25 NB0890-L NetworkManager[2548]:Internal Point-to-Point
Address: 0.0.0.0
Jan  3 00:43:25 NB0890-L NetworkManager[2548]:Maximum Segment Size
(MSS): 0
Jan  3 00:43:25 NB0890-L NetworkManager[2548]:Static Route:
172.16.31.0/24   Next Hop: 172.16.31.0
Jan  3 00:43:25 NB0890-L NetworkManager[2548]:Static Route:
10.9.0.0/24   Next Hop: 10.9.0.0
Jan  3 00:43:25 NB0890-L NetworkManager[2548]:Forbid Default Route:
no
Jan  3 00:43:25 NB0890-L NetworkManager[2548]:Internal DNS:
172.16.31.1
Jan  3 00:43:25 NB0890-L NetworkManager[2548]:DNS Domain: '(none)'
Jan  3 00:43:25 NB0890-L NetworkManager[2548]:  No IPv6 configuration
Jan  3 00:43:25 NB0890-L nm-openvpn[12176]: Initialization Sequence Completed
Jan  3 00:43:26 NB0890-L NetworkManager[2548]:  VPN connection 'client-
noproxy' (IP Config Get) complete.



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

Kernel: Linux 3.11-2-amd64 (SMP w/4 CPU cores)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages network-manager-openvpn depends on:
ii  libc6 2.17-97
ii  libdbus-1-3   1.6.18-2
ii  libdbus-glib-1-2  0.100.2-1
ii  libglib2.0-0  2.36.4-1
ii  libnm-gli

Bug#733319: [psi-plus-plugins] OTR conversations between psi-plus and pidgin sometimes don't work

2014-01-02 Thread Ian Goldberg

On Fri, Jan 03, 2014 at 12:17:26AM +0100, intrigeri wrote:
> Control: reassign -1 psi-plus-plugins 0.16.262-1
> Control: retitle -1 Sends malformed OTRv3 messages
> 
> Hi,
> 
> Boris Pek wrote (28 Dec 2013 14:55:59 GMT) :
> > As I know this is the problem in libotr >= 4.0.0.
> 
> According to one of the lead OTR developers (who happens to know quite
> a bit about what a well-formed OTR message looks like, as you may
> guess), it was rather caused by a buggy implementation of the OTRv3
> protocol in Psi+:
> 
> Ian Goldberg wrote (28 Dec 2013 15:45:09 GMT) :
> > See
> > http://lists.cypherpunks.ca/pipermail/otr-users/2013-November/002392.html
> 
> => reassigning to psi-plus-plugins version that exposes this bug.
> I'll let you massage the found / fixed BTS metadata to indicate in
> which specific version workaround'ed this problem.
> 
> Note that Ian suggests that it might be useful to debug and fix this
> properly in Psi+, instead of disabling OTRv3 support:
> 
> Ian Goldberg wrote (28 Dec 2013 15:45:09 GMT) :
> > For some reason, psi+ (before the workaround that removes OTRv3 support)
> > was sending messages with a sender instance of 0.  If someone could do a
> > trace in psi+ to see why that was happening, it would pinpoint the
> > problem.

To be clear, it *could* still be a bug in libotr.  But since the only
client we've seen that has this "sender instance 0" issue is psi+,
regardless of where the flaw is, tracing the (pre-workaround) version of
psi+ to find what is failing to set the sender instance seems like the
right course of action.

What's *supposed* to happen is that when a message is received, and
otrl_message_receving is called by psi+, then inside libotr, the
appropriate ConnContext is found, and if there's no sender instance yet
set on it, the client's create_instag callback is called.  If there is
no such callback defined (which, looking at psi+, I don't see one), then
libotr will just create a random instance tag.  (This is the
populate_context_instag function in libotr:src/message.c)

So the question is: why, when the Commit message is received, is libotr
failing to create a sender instance value for the newly created child
context?  (This should be happening in libotr:src/message.c:965.)

A breakpoint in otrl_message_receiving when the bug gets triggered in
the old version of psi+ should be elucidating.

Thanks,

   - Ian

-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#734003: linux-image-3.13-rc6-amd64: Display manager fails to start, Intel graphics driver not loaded/used, brightness conrtols reversed

2014-01-02 Thread Alex Vanderpol

Package: src:linux
Version: 3.13~rc6-1~exp1
Severity: important

Dear Maintainer,

This package (version 3.13~rc6-1~exp1) is exhibiting some symptoms that lead me
to believe it's buggy, namely:

1: My display manager (GDM) fails to start when the system finishes booting.
2: The Intel graphics driver does not appear to be loaded/used (possibly the
reason for #1). Instead, the driver "Gallium 0.4 on llvmpipe (LLVM 3.3, 128
bits)" is used.
3: For some reason, the brightness controls end up reversed (trying to lower
the brightness raises it, and vice-versa), causing my display to be turned off
rather than turned up to full brightness when the system finishes booting
(possibly also related to #2).

If you could please look into these matters, I would be ever so grateful. For
the time being, I shall continue to run the 3.12 kernel, which does not
experience these issues.



-- Package-specific info:
** Version:
Linux version 3.13-rc6-amd64 (debian-ker...@lists.debian.org) (gcc version 
4.8.2 (Debian 4.8.2-10) ) #1 SMP Debian 3.13~rc6-1~exp1 (2013-12-30)

** Command line:
BOOT_IMAGE=/boot/vmlinuz-3.13-rc6-amd64 
root=UUID=376d5c13-85a6-476a-aa9e-1be9dc19d808 ro quiet splash

** Tainted: I (2048)
 * Working around severe firmware bug.

** Kernel log:
[   10.182746] systemd[1]: Starting udev Control Socket.
[   10.182842] systemd[1]: Listening on udev Control Socket.
[   10.182930] systemd[1]: Starting udev Coldplug all Devices...
[   10.183809] systemd[1]: Starting Arbitrary Executable File Formats File 
System Automount Point.
[   10.184038] systemd[1]: Set up automount Arbitrary Executable File Formats 
File System Automount Point.
[   10.184637] systemd[1]: Started Set Up Additional Binary Formats.
[   10.184655] systemd[1]: Starting Encrypted Volumes.
[   10.184722] systemd[1]: Reached target Encrypted Volumes.
[   10.225326] systemd[1]: Starting Apply Kernel Variables...
[   10.226160] systemd[1]: Expecting device 
dev-disk-by\x2duuid-360e320b\x2d691a\x2d4e31\x2dbcfb\x2d47b1059d7864.device...
[   10.226255] systemd[1]: Starting File System Check on Root Device...
[   10.227037] systemd[1]: Expecting device 
dev-disk-by\x2duuid-5405f114\x2de615\x2d4140\x2d8331\x2d6428d0b806d2.device...
[   10.227118] systemd[1]: Expecting device 
dev-disk-by\x2duuid-62eef65d\x2d32c0\x2d4c66\x2d81eb\x2dbcc97262b00a.device...
[   10.574194] fuse init (API version 7.22)
[   11.362490] loop: module loaded
[   11.475392] systemd-udevd[259]: starting version 204
[   13.684148] EXT4-fs (sda1): re-mounted. Opts: errors=remount-ro
[   14.206514] cfg80211: Calling CRDA to update world regulatory domain
[   14.221595] ACPI: AC Adapter [ACAD] (off-line)
[   14.231365] ACPI: Battery Slot [BAT1] (battery present)
[   14.403692] ACPI Warning: 0x0428-0x042f SystemIO 
conflicts with Region \PMBA 1 (20131115/utaddress-251)
[   14.403703] ACPI: If an ACPI driver is available for this device, you should 
use it instead of the native driver
[   14.403710] ACPI Warning: 0x0530-0x053f SystemIO 
conflicts with Region \GPIO 1 (20131115/utaddress-251)
[   14.403716] ACPI Warning: 0x0530-0x053f SystemIO 
conflicts with Region \_SB_.PCI0.LPC_.GPIO 2 (20131115/utaddress-251)
[   14.403722] ACPI: If an ACPI driver is available for this device, you should 
use it instead of the native driver
[   14.403725] ACPI Warning: 0x0500-0x052f SystemIO 
conflicts with Region \_SB_.PCI0.LPC_.GPIO 1 (20131115/utaddress-251)
[   14.403731] ACPI: If an ACPI driver is available for this device, you should 
use it instead of the native driver
[   14.403733] lpc_ich: Resource conflict(s) found affecting gpio_ich
[   14.502991] Monitor-Mwait will be used to enter C-1 state
[   14.503003] Monitor-Mwait will be used to enter C-2 state
[   14.503008] tsc: Marking TSC unstable due to TSC halts in idle
[   14.503017] ACPI: acpi_idle registered with cpuidle
[   14.503254] Switched to clocksource hpet
[   14.516545] input: PC Speaker as /devices/platform/pcspkr/input/input12
[   14.641617] i801_smbus :00:1f.3: SMBus using PCI Interrupt
[   14.668314] Intel(R) Wireless WiFi driver for Linux, in-tree:
[   14.668319] Copyright(c) 2003-2013 Intel Corporation
[   14.668520] iwlwifi :02:00.0: can't disable ASPM; OS doesn't have ASPM 
control
[   14.668706] iwlwifi :02:00.0: irq 44 for MSI/MSI-X
[   14.746313] acerhdf: Acer Aspire One Fan driver, v.0.5.26
[   14.944354] systemd-udevd[317]: renamed network interface eth0 to eth1
[   15.101133] acer_wmi: Acer Laptop ACPI-WMI Extras
[   15.105763] acer_wmi: Function bitmap for Communication Device: 0x10
[   15.105771] acer_wmi: Brightness must be controlled by acpi video driver
[   15.106072] input: Acer BMA150 accelerometer as 
/devices/virtual/input/input13
[   15.109883] iwlwifi :02:00.0: firmware: direct-loading firmware 
iwlwifi-1000-5.ucode
[   15.110112] iwlwifi :02:00.0: loaded firmware version 39.31.5.1 build 
35138 op

Bug#727708: Info received (Bug#727708: requirement of non-forking startup protocol)

2014-01-02 Thread Zbigniew Jędrzejewski-Szmek

> Yeah, most daemons that write external PID files have issues with external
> PID files left from other running instances of the same daemon.  (I assume
> that's what you're talking about.)  It's probably possible to avoid that
> with judicious use of file locking, but that's not common and is more
> complex.

systemd will unlink the pidfile after the daemon is stopped (and during
restart, etc.). Stale files shouldn't be an issue.

Zbyszek


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#734001: [gcc-4.6] Could you remove the dependency on newlib-spu

Package: gcc-4.6
Severity: normal

Could you please remove the dependency on newlib-spu. It is not provided any
more, from the version 2.0.

-- 
TiN



signature.asc
Description: OpenPGP digital signature

Bug#733977: boinc-app-milkyway: Please sync with upstream

2014-01-02 Thread Gianfranco Costamagna

Hi Ken
thanks for your report.

Unfortunately I tried some time ago to package again milkyway with the new code 
hosted here [1]

Code that I think is the official client one.

Anyway I'm just stuck with some errors when I run the package with boinc, and I 
get only "computation errors" messages.

I also asked two pull requests [2], to fix a build failure and a potential 
security issue.

Nobody replied so far.
What can I do? Fix everything without upstream support?
I can, but I don't have time and man power for making the package stable 
without looking really deeply at the code.

I'll try again with the last milkyway code, can you please try to have a better 
contact with upstream?

thanks

[1] https://github.com/Milkyway-at-home/milkywayathome_client

[2] https://github.com/Milkyway-at-home/milkywayathome_client/pulls

G.


> Il Giovedì 2 Gennaio 2014 20:48, Ken Sharp 
>  ha scritto:
> > Package: boinc-app-milkyway
> Version: 0.18d-4
> 
> The current version supplied by boinc-app-milkyway appears to run fine 
> on armel but:
> 
> 1. The estimated runtime is always way off.
> 2. The results are always invalid.
> 3. It's a really old version: there will be many changes between 0.18 
> and the current upstream 1.x branch which will fix a lot of bugs.
> 
> If there is anything further needed then please let me know.
> 
> Origin: http://milkyway.cs.rpi.edu/milkyway/forum_thread.php?id=3440#60666
> 
> -- 
> pkg-boinc-devel mailing list
> pkg-boinc-de...@lists.alioth.debian.org
> http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-boinc-devel
>


--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#734002: [gcc-4.7] Could you remove the dependency on newlib-spu

Package: gcc-4.7
Severity: normal

Could you please remove the dependency on newlib-spu. It is not provided any
more, from the version 2.0.

-- 
TiN



signature.asc
Description: OpenPGP digital signature

Bug#669292: gitweb: automatic configuration breaks with apache2 2.4

2014-01-02 Thread Jonathan Nieder

Jonathan Nieder wrote:

> As described at [1], apache's scheme for supporting webapps has
> changed a little.  [2] describes what we need to do.

Here's a start.  Thoughts welcome, as always.
From: Jonathan Nieder 
Date: Thu, 2 Jan 2014 16:22:17 -0800
Subject: debian/gitweb: adapt packaging for apache 2.4

Try to support both apache 2.2 and 2.4, following advice from

 https://lists.debian.org/debian-devel-announce/2012/03/msg00013.html
 https://lists.debian.org/debian-webapps/2012/03/msg7.html

NEEDSWORK:
 - prerm deconfigure does not clean up as much as it should
 - needs triggers to reconfigure when apache is updated?
 - untested

Signed-off-by: Jonathan Nieder 
---
 debian/changelog| 29 +++
 debian/control  |  1 +
 debian/gitweb.conffiles |  2 +-
 debian/gitweb.postinst  | 53 +++--
 debian/gitweb.postrm| 21 
 debian/gitweb.preinst   |  6 ++
 debian/rules|  4 ++--
 7 files changed, 94 insertions(+), 22 deletions(-)
 create mode 100644 debian/gitweb.postrm
 create mode 100644 debian/gitweb.preinst

diff --git a/debian/changelog b/debian/changelog
index 4ffa62c..2c2004f 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,32 @@
+git (1:1.8.5.2-1.1) unstable; urgency=low
+
+  * update gitweb configuration packaging for apache 2.4
+(closes: #669292).
+* rules, gitweb.conffiles: gitweb's Apache settings go in
+  /etc/apache2/conf-available, with .conf extension.
+* gitweb.preinst, gitweb.postinst, gitweb.postrm: use
+  dpkg-maintscript-helper to rename
+  /etc/apache2/conf.d/gitweb -> conf-available/gitweb.conf,
+  preserving local changes.
+* control: Pre-Depends: dpkg (>= 1.15.8) for
+  dpkg-maintscript-helper.
+* gitweb.postinst configure: use apache2-maintscript-helper
+  if present to enable gitweb configuration.  If
+  apache2-maintscript-helper is not available and
+  apache2.2-common is unpacked, install a symlink
+  conf.d/gitweb.conf -> ../conf-available/gitweb.conf for use
+  by apache 2.2.
+* gitweb.postinst configure: only use the apache2 init script
+  to reload configuration when apache2-maintscript-helper is
+  unavailable (otherwise, "apache2_invoke enconf gitweb"
+  takes care of that).
+* gitweb.postrm remove, purge: use apache2-maintscript-helper
+  if present to disable gitweb configuration.
+* gitweb.postrm remove, purge: remove conf.d/gitweb.conf ->
+  ../conf-available/gitweb.conf symlink if still present.
+
+ -- Jonathan Nieder   Thu, 02 Jan 2014 16:22:12 -0800
+
 git (1:1.8.5.2-1) unstable; urgency=low
 
   * new upstream point release.
diff --git a/debian/control b/debian/control
index aa180bb..da95ec3 100644
--- a/debian/control
+++ b/debian/control
@@ -353,6 +353,7 @@ Architecture: all
 Multi-Arch: foreign
 Depends: git (>> ${source:Upstream-Version}), git (<< 
${source:Upstream-Version}-.),
  perl, apache2 | httpd | lynx-cur
+Pre-Depends: dpkg (>= 1.15.8~)
 Recommends: libhttp-date-perl | libtime-modules-perl
 Suggests: httpd-cgi | libcgi-fast-perl, git-doc
 Description: fast, scalable, distributed revision control system (web 
interface)
diff --git a/debian/gitweb.conffiles b/debian/gitweb.conffiles
index 27a8287..8947bf6 100644
--- a/debian/gitweb.conffiles
+++ b/debian/gitweb.conffiles
@@ -1,2 +1,2 @@
 /etc/gitweb.conf
-/etc/apache2/conf.d/gitweb
+/etc/apache2/conf-available/gitweb.conf
diff --git a/debian/gitweb.postinst b/debian/gitweb.postinst
index b51381b..35f082a 100755
--- a/debian/gitweb.postinst
+++ b/debian/gitweb.postinst
@@ -1,24 +1,39 @@
 #!/bin/sh
 set -e
 
-case "$1" in
-configure)
-if [ -x /etc/init.d/apache2 ]
-then
-if which /usr/sbin/invoke-rc.d >/dev/null 2>&1
-then
-invoke-rc.d apache2 reload || true
-else
-/etc/init.d/apache2 reload || true
-fi
-fi
-;;
+dpkg-maintscript-helper mv_conffile \
+  /etc/apache2/conf.d/gitweb /etc/apache2/conf-available/gitweb.conf \
+  1:1.8.5.2-1.1~ -- "$@"
 
-abort-upgrade|abort-remove|abort-deconfigure)
-;;
+test "$1" = configure || exit 0
 
-*)
-echo "postinst called with unknown argument \`$1'" >&2
-exit 1
-;;
-esac
+# <4f6ef77f.6080...@toell.net>
+if [ -e /usr/share/apache2/apache2-maintscript-helper ]
+then
+  . /usr/share/apache2/apache2-maintscript-helper
+  apache2_invoke enconf gitweb || exit
+else
+  apache2_common_state=$(
+dpkg-query -f '${Status}' -W apache2.2-common 2>/dev/null |
+awk '{print $3}' || true
+  )
+  if [ "$apache2_common_state" = installed ] ||
+[ "$apache2_common_state" = unpacked ]
+  then
+if [ -d /etc/apache2/conf.d/ ] &&
+  [ ! -L /etc/apache2/conf.d/gitweb.conf ]
+then
+  ln -s ../conf-available/gitweb.conf /etc/apache2/conf.d/gitweb.conf
+fi
+  fi
+
+  if [ -x /etc/init.d/apache2 ]
+  then

Bug#733410: PTS: include backports uploads in news

On Samstag, 28. Dezember 2013, Russ Allbery wrote:
> Now that the backports archive has been integrated more completely
> into the regular Debian archive, it would be great to see uploads
> to backports show up in the news section of the PTS.

excellent idea!


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

Bug#730983: Adopting speech-dispatcher [Was: Festival Voices and Czech voices]

2014-01-02 Thread Luke Yelavich

On Fri, Jan 03, 2014 at 10:38:16AM EST, Samuel Thibault wrote:
> Paul Gevers, le Thu 02 Jan 2014 12:34:40 +0100, a écrit :
> > On 21-12-13 12:20, MENGUAL Jean-Philippe wrote:
> > > Moreover, I think that speech-dispatcher is more related to
> > > TTS than a11y.
> > 
> > I am fine with this analysis, but it seems most recent (Ubuntu?) work
> > has been done in the the git repro in the a11y realm [0].
> 
> Well, I don't think moving to tts will prevent Luke from working on it
> :) (I'm just waiting for alioth to get back online before adding him to
> the group).

Thanks in advance for taking care of this.

Luke


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#734000: [gcc] Could you remove the dependency on newlib-spu

Package: gcc-4.4
Severity: normal

Could you please remove the dependency on newlib-spu. It is not provided any
more, from the version 2.0.

-- 
TiN



signature.asc
Description: OpenPGP digital signature

Bug#733997: ibus-pinyin: Pinyin prompt displayed incomplete, no Mandarin numbered choices are shown

2014-01-02 Thread Yuri


Package: ibus-pinyin
Version: 1.4.0-2ubuntu2
Severity: important

Dear Maintainer,

There are two related problems:
1. Ctrl-Space causes the pinyin prompt to show up under the application 
(top-level) window, not under the edit box.
2. Intermittently (and very often) the top half of the prompt is 
displayed (showing typed ascii chars), and no bottom half is displayed 
(that shows the numbered Mandarin character choices).


Both problems, for example, are nonexistent in zh-ibus-pinyin-1.4.0_3 
package on FreeBSD. Over there the prompt is always complete and is 
located right under the edit box (not under the application window).


I am on the latest Mint Cinnamon.

-- System Information:
Debian Release: wheezy/sid
  APT prefers saucy-updates
  APT policy: (500, 'saucy-updates'), (500, 'saucy-security'), (500, 
'saucy')

Architecture: amd64 (x86_64)
Foreign Architectures: i386

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

Versions of packages ibus-pinyin depends on:
ii  ibus1.5.3-6ubuntu2.1
ii  ibus-pinyin-db-open-phrase  1.4.0-2ubuntu2
ii  libc6   2.17-93ubuntu4
ii  libgcc1 1:4.8.1-10ubuntu9
ii  libglib2.0-02.38.1-0ubuntu1
ii  libibus-1.0-5   1.5.3-6ubuntu2.1
ii  libopencc1  0.4.0-1
ii  libsqlite3-03.7.17-1ubuntu1
ii  libstdc++6  4.8.1-10ubuntu9
ii  libuuid12.20.1-5.1ubuntu9
pn  python:any  

ibus-pinyin recommends no packages.

ibus-pinyin suggests no packages.

-- no debconf information


--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#733998: clamav-unofficial-sigs: Script depends on bashisms for config file, but calls #!/bin/sh

2014-01-02 Thread Rachel McGregor Rawlings

Package: clamav-unofficial-sigs
Version: 3.6-1
Severity: important


The configuration instructions for clamav-unofficial-sigs.conf include the
following:

# If you would like to include medium and high risk databases, please read
# the comments in the upstream configuration file listed above. To modify the
# variables you would add something like this (the whitespace is important):
#
# ss_dbs+=" something.ndb"
# si_dbs+=" somethingelse.ndb"

This is a bashism which causes the program to kick errors and fail to download
the additional databases when it is run with /bin/dash, the default alias for
/bin/sh.

It is fixable at the package level by changing the shebang line in
/usr/sbin/clamav-unofficial-sigs to 
#!/bin/bash
and including bash as a dependency. 


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

Kernel: Linux 3.2.0-0.bpo.4-686-pae (SMP w/2 CPU cores)
Locale: LANG=en_US, LC_CTYPE=en_US (charmap=ISO-8859-1)
Shell: /bin/sh linked to /bin/dash

Versions of packages clamav-unofficial-sigs depends on:
ii  bind9-host [hos 1:9.7.3.dfsg-1~squeeze11 Version of 'host' bundled with BIN
ii  clamav  0.97.8+dfsg-1~squeeze1   anti-virus utility for Unix - comm
ii  clamav-daemon   0.97.8+dfsg-1~squeeze1   anti-virus utility for Unix - scan
ii  curl7.21.0-2.1+squeeze6  Get a file from an HTTP, HTTPS or 
ii  dnsutils1:9.7.3.dfsg-1~squeeze11 Clients provided with BIND
ii  gnupg   1.4.10-4+squeeze4GNU privacy guard - a free PGP rep
ii  rsync   3.0.7-2  fast remote file copy program (lik

clamav-unofficial-sigs recommends no packages.

clamav-unofficial-sigs suggests no packages.

-- Configuration Files:
/etc/clamav-unofficial-sigs.conf changed:
for f in /usr/share/clamav-unofficial-sigs/conf.d/*.conf ; do
if [ -s "$f" ] ; then
. $f
fi
done
unset msrbl_dbs
unset si_dbs
unset mbl_dbs
ss_dbs+=" blurl.ndb"
ss_dbs+=" spamattach.hdb"
ss_dbs+=" winnow_extended_malware.hdb"
ss_dbs+=" winnow.attachments.hdb"
ss_dbs+=" winnow_bad_cw.hdb"   
ss_dbs+=" bofhland_cracked_URL.ndb"   
ss_dbs+=" bofhland_malware_URL.ndb"  
ss_dbs+=" bofhland_phishing_URL.ndb"  
ss_dbs+=" bofhland_malware_attach.hdb"
ss_dbs+=" crdfam.clamav.hdb" 
ss_dbs+=" porcupine.ndb"
ss_dbs+=" phishtank.ndb"   
unset clamd_socket
max_sleep_time="1200"


-- no debconf information


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#712841: qcontrol: Fan error reported on TS109

2014-01-02 Thread Ian Campbell

On Sat, 2013-08-17 at 14:05 +0100, Martin Michlmayr wrote:
> * Ian Campbell  [2013-08-15 10:19]:
> > > I have a TS-209 and will try to find the time to check.  Unfortuntely,
> > > I cannot remember whether GPIO 44 also works on the Orion models.
> > 
> > Did you have any luck with this?
> 
> I sent an email to QNAP a few days ago but haven't received a reply
> yet.

I suppose you never heard back?

Looking back at the original report it occurs to me now (a bit late)
that even if we suppress the beep etc the fact that the PIC is
(apparently) generating 0x73  bytes (fan1 error) is still a bit
annoying/wasteful. I wonder if there is some way to stop it. Or is it
the fact that we have tried to set the fan which is the issue?

Dermon, does commenting out the content of temp_high and temp_low in
qcontrol.conf and rebooting still end up with fan_error getting called
lots?

Ian.

-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#727708: init system other points, and conclusion

2014-01-02 Thread Josselin Mouette

Le jeudi 02 janvier 2014 à 14:27 -0800, Steve Langasek a écrit : 
> For several years the GNOME Team ignored section 9.7 of Policy, concerning
> integration with the MIME handling system.  They did this in favor of
> implementing the related freedesktop.org on the grounds that the fd.o
> standard is technically superior (and less work, since it was already
> implemented upstream).
[snip] 
> What struck me in that discussion is that at no point did the GNOME
> maintainers raise this issue on debian-devel or debian-policy to ask for
> help with this integration problem.

You forgot to mention that the actual bug at hand affected only a small,
although quite vocal, number of users – vocal users with a lot of time
to spend on debian-devel (and now debian-ctte) being a recurrent issue
in Debian nowadays.

The maintainer for mime-support had been aware of the problem for more
than three years without any change happening. There was a failure of
Debian as a whole to have let this part of the policy rot for such a
long time, and I’ll admit to my share of responsibility in letting that
happen, but certainly not to the whole of it.

I still stand on the opinion that, after such a long time, aggressive
removal of legacy MIME files was a right course of action. 

> I'm
> merely giving voice to a view widely held among Debian developers who would
> in fact be more than happy to contribute to improving GNOME's integration in
> Debian, if only they believed this help would be welcomed by the current
> package maintainers.

Vague, unsubstantiated, false claims. Again.

I do not recall the members of the team rejecting the help proposed by
other contributors, apart from a handful of people who obviously failed
to meet the technical standards to contribute to any Debian package. If
there are any developers who would be happy to contribute to GNOME
packaging but are afraid their help will be refused, any member of the
team will be happy to soothe their fears. We have always been inclusive,
since, as a former DPL said, “what can’t you undo?”

Anyway, I have serious doubts about your allegation that manpower issues
are related to the current team members, unless you want to extend this
criticism to most core packaging teams. I might have to remind you that
the kernel, glibc, KDE, GNOME, Xfce and Xorg maintainers have all
repeatedly and publicly stated their lack of contributors and difficulty
to handle bug reports.

> I don't think it's a
> coincidence that over the past two years, over a quarter of all the issues
> decided by the TC have related to GNOME packages.

“Over a quarter” being three issues, two of them being the same. And
let’s not mention some TC member’s behavior regarding the handling of
that one, shall we?

> That's nothing more than hostage taking, especially when there would be no
> difficulty getting cycles for the integration bugs with GNOME and whatever
> init system Debian standardized on... *provided that* the GNOME maintainers
> showed themselves open to this work instead of blocking it.  From Joss's
> reply to my message, it seems altogether too likely that he *would* block
> such work.

This is not what I wrote. I implied that I would not contribute to it in
any way. I know this is the point of view of some other members of the
Debian GNOME team, but maybe not all of them. You’d have to ask them
individually.

Given the general tone of your message, I might have to remind you that
I am not the GNOME team, especially since I have not been providing much
packaging help during the last months. The reason why I’m the one doing
most of the talking is that other people have been so disinterested,
demotivated, or even disgusted, by the confrontational tone of any
public discussion about GNOME, freedesktop or systemd that they don’t
even want to talk about it anymore. Therefore, you should not think I am
the most likely person to block such changes or abandon the ship while
it is sinking.

This kind of attitude is making Debian the fun topic to talk about among
upstreams, not the major Linux player we should be. Debian as a whole
needs to rethink how it can be more friendly to some important upstream
projects, or we will simply stop being the “universal” operating system.

-- 
 .''`.  Josselin Mouette
: :' :
`. `'
  `-


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#733999: globus-scheduler-event-generator-progs: init script defaults are inconsistent with GRAM

2014-01-02 Thread Alexander Inyukhin

Package: globus-scheduler-event-generator-progs
Version: 4.6-1
Severity: normal

Hi,

I'm setting up a fresh globus-gatekeeper site on a cluster with torque.

I discovered that globus jobmanagers are expecting SEG log in the
/var/lib/globus directory, while it actually written to /var/log/globus.

GLOBUS_SEG_LOGFMT variable in /etc/default/globus-scheduler-event-generator
file seems to have /var/lib/ value, but it has no effect since init.d
script doesn't use it, and it set GLOBUS_SEG_LOGFMT to /var/log/.


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#733757: xkb-data: CTRL_R not existant anymore

2014-01-02 Thread Gabriel Corona

Hello,

I xkeyboard-config 2.6--2.10, the fr(oss) layout
use the level5(rctrl_switch) option for some [...] reason.
With this right control is quite useless.

It seems to be related to the nbsp character
but I can get it with AltGr+Shift+Space.

This can be disabled by commeting out the
level5(rctrl_switch) option in /usr/share/X11/xkb/symbols/fr.

-- 
Gabriel


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#733996: Generate a ‘closure-compiler’ binary package for the compiler program

2014-01-02 Thread Ben Finney

Package: src:closure-compiler
Version: 20130227+dfsg1-4
Severity: minor

Howdy, thank you for packaging the Closure compiler.

Searching APT for a package containing the Closure compiler command for
compiling ECMAScript, I expect to find the package in the “web” section by
the name ‘closure-compiler’.

I shouldn't need to care that it's implemented in Java, and am not
expecting a command-line program to be classified in the library packages.

The source package should produce separate binary packages:

* Package: libclosure-compiler-java
  Section: java
  Suggests: libclosure-compiler-java-doc
  Description: JavaScript optimizing compiler — runtime libraries

* Package: closure-compiler
  Section: web
  Depends: default-jre-headless, libclosure-compiler-java
  Description: JavaScript optimizing compiler

* Package: libclosure-compiler-java-doc
  Section: doc
  Suggests: libclosure-compiler-java
  Description: JavaScript optimizing compiler — API documentation

Since the ‘default-jre-headless’ dependency would then only be in a package
specifically for the command, this would allow removing the Lintian
override for “needless-dependency-on-jre”.

-- 
 \己所不欲、勿施于人。 |
  `\(What is undesirable to you, do not do to others.) |
_o__)—孔夫子 Confucius (551 BCE – 479 BCE) |
Ben Finney 


signature.asc
Description: Digital signature

Bug#733995: RFS: spatialite-gui/1.7.1-2

Package: sponsorship-requests
Severity: normal

Dear mentors,

As part of the upcoming SpatiaLite transition am I looking for a sponsor for
my package "spatialite-gui".

Please refer to the thread on debian-gis@ for more information on this
transition: https://lists.debian.org/debian-gis/2013/10/msg9.html

 Package name: spatialite-gui
 Version : 1.7.1-2
 Upstream Author : Alessandro Furieri 
 URL : https://www.gaia-gis.it/fossil/spatialite_gui/
 License : GPL-3.0+
 Section : utils

It builds those binary packages:

 spatialite-gui - user-friendly graphical user interface for SpatiaLite
 spatialite-gui-dbg - user-friendly graphical user interface for spatialite - 
debugging

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

http://mentors.debian.net/package/spatialite-gui


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

  dget -x 
http://mentors.debian.net/debian/pool/main/s/spatialite-gui/spatialite-gui_1.7.1-2.dsc

More information about spatialite-gui can be obtained from 
https://www.gaia-gis.it/fossil/spatialite_gui/.

Changes since the last upload:

 * Bump Standards-Version to 3.9.5, no changes required.
 * Require at least librasterlite version 1.1g-3.
 * Require at least libspatialite version 4.1.1-5 for libxml2 support.
 * Re-enable building with libxml2 support.


Regards,
 Sebastiaan Couwenberg


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#733920: src:speechd-up: hardcoded build dependency on libdotconf1.0 which will transition soon

2014-01-02 Thread Samuel Thibault

I have just uploaded the package with the 1.0 dep removed.

Samuel


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#733991: RFS: librasterlite/1.1g-3

Package: sponsorship-requests
Severity: normal

Dear mentors,

As part of the upcoming SpatiaLite transition am I looking for a sponsor for
my package "librasterlite".

Please refer to the thread on debian-gis@ for more information on this
transition: https://lists.debian.org/debian-gis/2013/10/msg9.html

 Package name: librasterlite
 Version : 1.1g-3
 Upstream Author : Alessandro Furieri 
 URL : https://www.gaia-gis.it/fossil/librasterlite
 License : MPL-1.1 or GPL-2.0+ or LGPL-2.1+
 Section : libs

It builds those binary packages:

 librasterlite-dev - library supporting raster data sources for spatialite - 
headers
 librasterlite2 - library supporting raster data sources for spatialite
 rasterlite-bin - command line tools for librasterlite
 rasterlite-dbg - library supporting raster data sources for spatialite - 
debugging

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

http://mentors.debian.net/package/librasterlite


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

  dget -x 
http://mentors.debian.net/debian/pool/main/libr/librasterlite/librasterlite_1.1g-3.dsc

More information about librasterlite can be obtained from 
https://www.gaia-gis.it/fossil/librasterlite.

Changes since the last upload:

 * Bump Standards-Version to 3.9.5, no changes required.
 * Require at least libspatialite version 4.1.1.


Regards,
 Sebastiaan Couwenberg


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#733992: RFS: spatialite-tools/4.1.1-2

Package: sponsorship-requests
Severity: normal

Dear mentors,

As part of the upcoming SpatiaLite transition am I looking for a sponsor for
my package "spatialite-tools".

Please refer to the thread on debian-gis@ for more information on this
transition: https://lists.debian.org/debian-gis/2013/10/msg9.html

 Package name: spatialite-tools
 Version : 4.1.1-2
 Upstream Author : Alessandro Furieri 
 URL : https://www.gaia-gis.it/fossil/spatialite-tools/
 License : GPL-3.0+
 Section : science

It builds those binary packages:

  spatialite-bin - Geospatial extension for SQLite - tools

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

http://mentors.debian.net/package/spatialite-tools


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

  dget -x 
http://mentors.debian.net/debian/pool/main/s/spatialite-tools/spatialite-tools_4.1.1-2.dsc

More information about spatialite-tools can be obtained from 
https://www.gaia-gis.it/fossil/spatialite-tools/.

Changes since the last upload:

 * Bump Standards-Version to 3.9.5, no changes required.
 * Require at least libspatialite version 4.1.1.


Regards,
 Sebastiaan Couwenberg


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#733993: loudmouth: please package github snapshot of loudmouth

2014-01-02 Thread Florian Schlichting

Source: loudmouth
Severity: wishlist

Hi,

the company originally behind loudmouth split up / dissolved years ago and 
loudmouth-project.org displays crap, but some continuing development can
be found on github, particularly at https://github.com/mcabber/loudmouth
where the people behind MCabber add features, fix bugs and do some
general housekeeping.

Please consider packaging a github snapshot of loudmouth.

Florian,
maintainer of irssi-plugin-xmpp


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#733994: RFS: pyspatialite/3.0.1-4

Package: sponsorship-requests
Severity: normal

Dear mentors,

As part of the upcoming SpatiaLite transition am I looking for a sponsor for
my package "pyspatialite".

Please refer to the thread on debian-gis@ for more information on this
transition: https://lists.debian.org/debian-gis/2013/10/msg9.html

 Package name: pyspatialite
 Version : 3.0.1-4
 Upstream Author : Lokkju Brennr 
 URL : http://pyspatialite.googlecode.com/
 License : zlib
 Section : python

It builds those binary packages:

  python-pyspatialite - Python interface to Spatialite

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

http://mentors.debian.net/package/pyspatialite


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

  dget -x 
http://mentors.debian.net/debian/pool/main/p/pyspatialite/pyspatialite_3.0.1-4.dsc

More information about pyspatialite can be obtained from 
http://pyspatialite.googlecode.com/.

Changes since the last upload:

 * Bump Standards-Version to 3.9.5, no changes required.
 * Require at least libspatialite version 4.1.1.


Regards,
 Sebastiaan Couwenberg


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#733674: libnewlib-arm-none-eabi: missing symlink causes arm-none-eabi-gcc to fail

On 12/29/2013 01:10 AM, Anders Hammarquist wrote:
> Package: libnewlib-arm-none-eabi
> Version: 2.0.0-1
> Severity: important
> 
> Dear Maintainer,
> 
> gcc-arm-none-eabi expects a /usr/lib/arm-none-eabi/include symlink
> pointing to /usr/include/newlib if libnewlib-arm-none-eabi is to 
> be usable. I think the package ought to provide the symlink.

Hi Anders,
  the main idea of gcc-arm-none-eabi is to allow choose the C standard
library that you want. With this in mind if you want to use newlib as C
standard library in your project then you need to add the path pointing to
newlib (the path that you mentioned above) in your list of include paths. For
clarify you can do this in gcc with "-I/usr/include/newlib".
I'm working to upload newlib-nano that is a fork of newlib project with some
improvements for bare metal development. So you can choose the C standard
library that best suits to your needs. And there are many other C standard
libraries that you could choose.

Cheers,

-- 
TiN

signature.asc
Description: OpenPGP digital signature

Bug#733987: RFS: dbab/1.0.1 [ITP] - dnsmasq-based ad-blocking using pixelserv

2014-01-02 Thread Michael Shuler


This has all sorts of problems.
1) incomplete source and debian packaging (symlinked to nowhere)
2) native package (version 1.0.1 and debian/ dir should be separate from 
upstream source)


--
Kind regards,
Michael
mshuler@mana:~/tmp/build$ dget -xu 
http://mentors.debian.net/debian/pool/main/d/dbab/dbab_1.0.1.dsc
dget: retrieving 
http://mentors.debian.net/debian/pool/main/d/dbab/dbab_1.0.1.dsc
  % Total% Received % Xferd  Average Speed   TimeTime Time  Current
 Dload  Upload   Total   SpentLeft  Speed
100  1526  100  15260 0   2724  0 --:--:-- --:--:-- --:--:--  2725
dget: retrieving 
http://mentors.debian.net/debian/pool/main/d/dbab/dbab_1.0.1.tar.gz
  % Total% Received % Xferd  Average Speed   TimeTime Time  Current
 Dload  Upload   Total   SpentLeft  Speed
100   565  100   5650 0   1015  0 --:--:-- --:--:-- --:--:--  1016
dpkg-source: info: extracting dbab in dbab-1.0.1
dpkg-source: info: unpacking dbab_1.0.1.tar.gz
dpkg-source: error: cannot write dbab-1.0.1/debian/source/format: No such file 
or directory
mshuler@mana:~/tmp/build$ ls -l dbab*
-rw-r--r-- 1 mshuler mshuler 1526 Jan  2 17:38 dbab_1.0.1.dsc
-rw-r--r-- 1 mshuler mshuler  565 Jan  2 17:38 dbab_1.0.1.tar.gz

dbab-1.0.1:
total 0
drwxr-xr-x 2 mshuler mshuler 122 Jan  2 14:39 assets
drwxr-xr-x 2 mshuler mshuler  87 Jan  2 13:34 bin
drwxr-xr-x 3 mshuler mshuler 101 Jan  2 14:39 debian
lrwxrwxrwx 1 mshuler mshuler  23 Jan  2 13:34 Makefile -> 
../../dbab/src/Makefile
lrwxrwxrwx 1 mshuler mshuler  24 Jan  2 13:34 README.md -> 
../../dbab/src/README.md
mshuler@mana:~/tmp/build$ ls -l dbab-1.0.1/debian/
total 0
drwxr-xr-x 2 mshuler mshuler 19 Jan  2 13:34 source
lrwxrwxrwx 1 mshuler mshuler 34 Jan  2 13:34 changelog -> 
../../../dbab/src/debian/changelog
lrwxrwxrwx 1 mshuler mshuler 31 Jan  2 13:34 compat -> 
../../../dbab/src/debian/compat
lrwxrwxrwx 1 mshuler mshuler 32 Jan  2 13:34 control -> 
../../../dbab/src/debian/control
lrwxrwxrwx 1 mshuler mshuler 34 Jan  2 13:34 copyright -> 
../../../dbab/src/debian/copyright
lrwxrwxrwx 1 mshuler mshuler 29 Jan  2 13:34 docs -> 
../../../dbab/src/debian/docs
lrwxrwxrwx 1 mshuler mshuler 30 Jan  2 13:34 rules -> 
../../../dbab/src/debian/rules
mshuler@mana:~/tmp/build$

Bug#706679: Missing Depends: file

2014-01-02 Thread Trent W. Buck

Stuart Pook wrote:
> I have the "expr: syntax error" as well

expr doesn't appear in the codebase as at debian/4.0_alpha30-1.
This appears to be the commit that fixes it.

The new version could probably use SUS parameter expansion:

$ busybox ash


BusyBox v1.18.4 (Ubuntu 1:1.18.4-2ubuntu2) built-in shell (ash)
Enter 'help' for a list of built-in commands.

$ DEVICE=/dev/sda1p1
$ DEVICE=${DEVICE#/dev/} DEVICE=${DEVICE%%[0-9]*}
$ echo "$DEVICE"
sda


commit 3ce6f9e8fe33cfdda99b0bffbb3fa69063014047
Author: Daniel Baumann 
Date:   Mon May 6 20:42:55 2013 +0200

Replacing expr usage in initscript for eject boot media with something less 
error prone.

diff --git a/bin/boot-init.sh b/bin/boot-init.sh
index 83f37bc..3027d28 100755
--- a/bin/boot-init.sh
+++ b/bin/boot-init.sh
@@ -80,10 +80,17 @@ get_boot_device()
 device_is_USB_flash_drive()
 {
# remove leading "/dev/" and all trailing numbers from input
-   DEVICE=$(expr substr ${1} 6 3)
+   DEVICE=$(echo ${1} | sed -e 's|/dev/||' -e 's|[0-9].*$||')

# check that device starts with "sd"
-   [ "$(expr substr ${DEVICE} 1 2)" != "sd" ] && return 1
+   case "${DEVICE}" in
+   sd*)
+   ;;
+
+   *)
+   return 1
+   ;;
+   esac

# check that the device is an USB device
if readlink /sys/block/${DEVICE} | grep -q usb


signature.asc
Description: Digital signature

Bug#730983: Adopting speech-dispatcher [Was: Festival Voices and Czech voices]

2014-01-02 Thread Samuel Thibault

Paul Gevers, le Thu 02 Jan 2014 12:34:40 +0100, a écrit :
> On 21-12-13 12:20, MENGUAL Jean-Philippe wrote:
> > Moreover, I think that speech-dispatcher is more related to
> > TTS than a11y.
> 
> I am fine with this analysis, but it seems most recent (Ubuntu?) work
> has been done in the the git repro in the a11y realm [0].

Well, I don't think moving to tts will prevent Luke from working on it
:) (I'm just waiting for alioth to get back online before adding him to
the group).

> Maybe somebody (Samuel?) could move the repro to the tts location?

I have done so and updated the url in control.

Samuel


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#733746: dpkg-source - can't build with source format '3.0 (quilt)' when version number is 1.0.0

2014-01-02 Thread Guillem Jover

Hi Jonathan!

On Thu, 2014-01-02 at 14:49:20 -0800, Jonathan Nieder wrote:
> forcemerge 733746 719348
> # confusing error message

Right, and I had already added a note to my TODO list to not forget to
fix the error message this time around for 1.17.6, as I mentioned on
the other bug report, just forgot to mention it on my reply.

> severity 733746 minor
> quit

Thanks,
Guillem

-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#733319: [psi-plus-plugins] OTR conversations between psi-plus and pidgin sometimes don't work

Control: reassign -1 psi-plus-plugins 0.16.262-1
Control: retitle -1 Sends malformed OTRv3 messages

Hi,

Boris Pek wrote (28 Dec 2013 14:55:59 GMT) :
> As I know this is the problem in libotr >= 4.0.0.

According to one of the lead OTR developers (who happens to know quite
a bit about what a well-formed OTR message looks like, as you may
guess), it was rather caused by a buggy implementation of the OTRv3
protocol in Psi+:

Ian Goldberg wrote (28 Dec 2013 15:45:09 GMT) :
> See
> http://lists.cypherpunks.ca/pipermail/otr-users/2013-November/002392.html

=> reassigning to psi-plus-plugins version that exposes this bug.
I'll let you massage the found / fixed BTS metadata to indicate in
which specific version workaround'ed this problem.

Note that Ian suggests that it might be useful to debug and fix this
properly in Psi+, instead of disabling OTRv3 support:

Ian Goldberg wrote (28 Dec 2013 15:45:09 GMT) :
> For some reason, psi+ (before the workaround that removes OTRv3 support)
> was sending messages with a sender instance of 0.  If someone could do a
> trace in psi+ to see why that was happening, it would pinpoint the
> problem.

Cheers,
--
  intrigeri
  | GnuPG key @ https://gaffer.ptitcanardnoir.org/intrigeri/intrigeri.asc
  | OTR fingerprint @ https://gaffer.ptitcanardnoir.org/intrigeri/otr.asc


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#733866: nyancat-server: drop reconf-inetd dependency

2014-01-02 Thread Serafeim Zanikolas

Hi Jon,

On Thu, Jan 02, 2014 at 02:33:22AM +, Jonathan McCrohan wrote:
> Can you please supply a patch for this. DEP9 provides no guidance on how
> correctly to migrate users away from reconf-inetd in the postinst.

Here's a list of instructions instead:

- don't ship anything under /usr/share/reconf-inetd/
- replace dependency on reconf-inetd with one on update-inetd
- revert postinst script to the one you had before, and put
  "reconf-inetd || true" before invoking "update-inetd --add ..."
  (the former will remove any entries added by reconf-inetd, for which there's
  no fragment under /usr/share/reconf-inetd)

Let me know if you run into any issues.

Cheers,

-- 
Every great idea is worthless without someone to do the work. --Neil Williams


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#716210: [Mayhem] Bug report on libotr2-bin: otr_sesskeys crashes with exit status 139

Control: tag -1 + fixed-upstream
Control: found -1 4.0.0-2.2

Ian Goldberg wrote (17 Jul 2013 14:24:24 GMT) :
> [...] It turns out it was a bug in libgcrypt.  We
> reported the bug, and it's been fixed upstream.  We also committed a
> workaround, shown below.  libotr itself was not affected; just the
> toolkit program otr_sesskeys needed the workaround.

Thanks for the prompt fix and clarification on this bug!
Flagging fixed-upstream accordingly.

Any plans to put out a new upstream release that integrates the few
bugfixes I've seen in Git? If it might help, I guess we could upload
a beta or something to Debian experimental, to give this code more
exposure to testing.

Cheers,
--
  intrigeri
  | GnuPG key @ https://gaffer.ptitcanardnoir.org/intrigeri/intrigeri.asc
  | OTR fingerprint @ https://gaffer.ptitcanardnoir.org/intrigeri/otr.asc


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#722654: [Packaging] Bug#722654: Munin's apache.conf isn't fully compatible with Apache 2.4

control: severity -1 important

On Montag, 30. Dezember 2013, Matthias Schmitz wrote:
> At the moment the configuration leads to "403 Forbidden" in the browser and
> "AH01630: client denied by server configuration: /var/cache/munin/www/"
> in apache's error.log.

or am I missing something why this shouldnt be important?

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

Bug#733990: gdm3: Pulseaudio fail to load auth key from /var/lib/gdm3/.config/pulse/cookie:no such file or directory instead of /var/lib/gdm3/.pulse-cookie

2014-01-02 Thread Marian

Package: gdm3
Version: 3.8.4-6
Severity: minor



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

Kernel: Linux 3.11-2-amd64 (SMP w/2 CPU cores)
Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages gdm3 depends on:
ii  accountsservice  0.6.34-2
ii  adduser  3.113+nmu3
ii  dconf-cli0.18.0-1
ii  dconf-gsettings-backend  0.18.0-1
ii  debconf [debconf-2.0]1.5.52
ii  gir1.2-gdm3  3.8.4-6
ii  gnome-session [x-session-manager]3.8.4-3
ii  gnome-session-bin3.8.4-3
ii  gnome-session-flashback [x-session-manager]  3.8.0-1
ii  gnome-settings-daemon3.8.5-2
ii  gnome-shell  3.8.4-5
ii  gnome-terminal [x-terminal-emulator] 3.10.1-1
ii  gsettings-desktop-schemas3.8.2-2
ii  kde-window-manager [x-window-manager]4:4.11.3-2
ii  konsole [x-terminal-emulator]4:4.11.3-1
ii  libaccountsservice0  0.6.34-2
ii  libatk1.0-0  2.10.0-2
ii  libaudit11:2.3.2-2
ii  libc62.17-97
ii  libcairo-gobject21.12.16-2
ii  libcairo21.12.16-2
ii  libcanberra-gtk3-0   0.30-2
ii  libcanberra0 0.30-2
ii  libgdk-pixbuf2.0-0   2.28.2-1+b1
ii  libgdm1  3.8.4-6
ii  libglib2.0-0 2.36.4-1
ii  libglib2.0-bin   2.36.4-1
ii  libgtk-3-0   3.8.6-1
ii  libpam-modules   1.1.3-9
ii  libpam-runtime   1.1.3-9
ii  libpam-systemd   204-5
ii  libpam0g 1.1.3-9
ii  libpango-1.0-0   1.36.0-1+b1
ii  libpangocairo-1.0-0  1.36.0-1+b1
ii  librsvg2-common  2.40.0-1
ii  libselinux1  2.2.1-1
ii  libwrap0 7.6.q-24
ii  libx11-6 2:1.6.2-1
ii  libxau6  1:1.0.8-1
ii  libxdmcp61:1.1.1-1
ii  libxrandr2   2:1.4.1-1
ii  lsb-base 4.1+Debian12
ii  metacity [x-window-manager]  1:2.34.13-1
ii  mutter [x-window-manager]3.8.4-2
ii  upower   0.9.23-2+b1
ii  x11-common   1:7.7+4
ii  x11-xserver-utils7.7+1
ii  xterm [x-terminal-emulator]  300-1

Versions of packages gdm3 recommends:
ii  at-spi2-core   2.10.1-1
ii  desktop-base   7.0.3
ii  gnome-icon-theme   3.10.0-1
ii  gnome-icon-theme-symbolic  3.10.1-1
ii  x11-xkb-utils  7.7~1
ii  xserver-xephyr 2:1.14.5-1
ii  xserver-xorg   1:7.7+4
ii  zenity 3.8.0-1

Versions of packages gdm3 suggests:
ii  gnome-orca3.4.2-2
ii  libpam-gnome-keyring  3.8.2-2

-- Configuration Files:
/etc/gdm3/greeter.gsettings changed:
[org.gnome.desktop.session]
session-name='gdm-shell'
[org.gnome.login-screen]
logo='/usr/share/icons/gnome/48x48/places/debian-swirl.png'
fallback-logo='/usr/share/icons/gnome/48x48/places/debian-swirl.png'


-- debconf information:
* shared/default-x-display-manager: gdm3
  gdm3/daemon_name: /usr/sbin/gdm3


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#733398: bowtie: FTBFS: diff_sample.h:532:27: error: call of overloaded 'popCount(uint32_t&)' is ambiguous

2014-01-02 Thread Andreas Tille

Hi,

when building the bowtie Debian package we were using the Debian
packaged seqan library which worked as long as we had seqan 1.3.1.
Since the migration to seqan 1.4.1 this stoped working (see below).  So
the question is:  Do we find some patch to comply with seqan 1.4.x
(preferable), do we consider maintaining a versioned seqan1.3-dev
package inside Debian to cope with bowtie and other packages with the
same problem (creates extra work) or do we go the wimpy trail and simply
revert to the seqan-1.1 convenience copy included inside the bowtie
source?

Kind regards

Andreas.

On Sat, Dec 28, 2013 at 06:28:45PM +0100, David Suárez wrote:
> Source: bowtie
> Version: 1.0.0-5
> Severity: serious
> Tags: jessie sid
> User: debian...@lists.debian.org
> Usertags: qa-ftbfs-20131226 qa-ftbfs
> Justification: FTBFS on amd64
> 
> Hi,
> 
> During a rebuild of all packages in sid, your package failed to build on
> amd64.
> 
> Relevant part (hopefully):
> > g++ -O3  \
> > -DCOMPILER_OPTIONS="\"-O3   -Wl,--hash-style=both 
> > -D_FORTIFY_SOURCE=2 -g -O2 -fstack-protector --param=ssp-buffer-size=4 
> > -Wformat -Werror=format-security  -g -O2 -fstack-protector 
> > --param=ssp-buffer-size=4 -Wformat -Werror=format-security  -Wl,-z,relro\"" 
> >  -Wl,--hash-style=both -D_FORTIFY_SOURCE=2 -g -O2 -fstack-protector 
> > --param=ssp-buffer-size=4 -Wformat -Werror=format-security  -g -O2 
> > -fstack-protector --param=ssp-buffer-size=4 -Wformat 
> > -Werror=format-security  -Wl,-z,relro \
> > -fno-strict-aliasing -DBOWTIE_VERSION="\"`cat VERSION`\"" 
> > -DBUILD_HOST="\"`hostname`\"" -DBUILD_TIME="\"`date`\"" 
> > -DCOMPILER_VERSION="\"`g++ -v 2>&1 | tail -1`\"" -D_LARGEFILE_SOURCE 
> > -D_FILE_OFFSET_BITS=64 -D_GNU_SOURCE  -DPREFETCH_LOCALITY=2 -DBOWTIE_MM 
> > -DBOWTIE_SHARED_MEM -Wall \
> > -I /usr/include/seqan -I . \
> > -o bowtie-inspect bowtie_inspect.cpp \
> > ccnt_lut.cpp ref_read.cpp alphabet.cpp shmem.cpp edit.cpp 
> > ebwt.cpp tinythread.cpp \
> > -lpthread
> > In file included from bowtie_inspect.cpp:8:0:
> > diff_sample.h: In constructor 
> > 'DifferenceCoverSample::DifferenceCoverSample(const TStr&, uint32_t, 
> > bool, bool, std::ostream&)':
> > diff_sample.h:532:27: error: call of overloaded 'popCount(uint32_t&)' is 
> > ambiguous
> >assert_eq(1, popCount(_v)); // must be power of 2
> >^
> > assert_helpers.h:52:16: note: in definition of macro 'assert_eq'
> >   if(!((ex) == (ac))) { \
> > ^
> > diff_sample.h:532:27: note: candidates are:
> >assert_eq(1, popCount(_v)); // must be power of 2
> >^
> > assert_helpers.h:52:16: note: in definition of macro 'assert_eq'
> >   if(!((ex) == (ac))) { \
> > ^
> > In file included from blockwise_sa.h:13:0,
> >  from ebwt.h:27,
> >  from bowtie_inspect.cpp:10:
> > diff_sample.h:482:21: note: unsigned int popCount(T) [with T = unsigned int]
> >  static unsigned int popCount(T i) {
> >  ^
> > In file included from 
> > /usr/include/seqan/index/index_fm_rank_support_bit_string.h:40:0,
> >  from /usr/include/seqan/index.h:167,
> >  from ebwt.h:16,
> >  from bowtie_inspect.cpp:10:
> > /usr/include/seqan/misc/misc_bit_twiddling.h:358:1: note: unsigned int 
> > seqan::popCount(TWord) [with TWord = unsigned int]
> >  popCount(TWord word)
> >  ^
> > In file included from bowtie_inspect.cpp:8:0:
> > diff_sample.h:532:27: error: call of overloaded 'popCount(uint32_t&)' is 
> > ambiguous
> >assert_eq(1, popCount(_v)); // must be power of 2
> >^
> > assert_helpers.h:53:107: note: in definition of macro 'assert_eq'
> >std::cout << "assert_eq: expected (" << (ex) << ", 0x" << std::hex << 
> > (ex) << std::dec << ") got (" << (ac) << ", 0x" << std::hex << (ac) << 
> > std::dec << ")" << std::endl; \
> > 
> >^
> > diff_sample.h:532:27: note: candidates are:
> >assert_eq(1, popCount(_v)); // must be power of 2
> >^
> > assert_helpers.h:53:107: note: in definition of macro 'assert_eq'
> >std::cout << "assert_eq: expected (" << (ex) << ", 0x" << std::hex << 
> > (ex) << std::dec << ") got (" << (ac) << ", 0x" << std::hex << (ac) << 
> > std::dec << ")" << std::endl; \
> > 
> >^
> > In file included from blockwise_sa.h:13:0,
> >  from ebwt.h:27,
> >  from bowtie_inspect.cpp:10:
> > diff_sample.h:482:21: note: unsigned int popCount(T) [with T = unsigned int]
> >  static unsigned int popCount(T i) {
> >  ^
> > In file included from 
> > /usr/include/seqan/index/index_fm_rank_support_bit_str

Bug#712185: at: add upstart init support

2014-01-02 Thread Ansgar Burchardt

Control: tag -1 moreinfo

Dmitrijs Ledkovs  writes:
> From my point of view, including/installing upstart job with
> dh_installinit is the only piece that is required to integrate your
> package correctly with both upstart & sysv init at the same time.
> Leaving out modifications to the init.d script.

Just installing the job file should cause no harm, but I'll probably
wait for the tech-ctte decision.

Also Colin Watson[1] and Ian Jackson[2] suggested that "expect fork"
might not be a good idea. The upstart job should probably do what
Type=simple in systemd[3] does, i.e. ask atd not to fork and don't
expect anything special to happen to signal readiness.

  [1] 
  [2] 
  [3] 

Ansgar

-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#723026: [Packaging] Bug#723026: munin uses deprecated defined(@array) from Log4Perl::Config