Bug#738103: apt-get download: can't specify the same package twice

[Michael Vogt]

On Fri, Feb 07, 2014 at 07:52:35PM +0100, Jakub Wilk wrote:
> Package: apt
> Version: 0.9.15.1
> Severity: minor

Thanks for your bugreport.
 
> "apt-get download" normally silently ignores packages that are
> already downloaded. However, it doesn't behave that way if you
> specify the same package twice on the command line:
> 
> $ apt-get download dash dash
> Get:1 http://ftp.debian.org/debian/ unstable/main dash i386 0.5.7-4 [105 kB]
> Fetched 105 kB in 0s (9070 kB/s)
> E: Failed to fetch 
> http://ftp.debian.org/debian/pool/main/d/dash/dash_0.5.7-4_i386.deb

I can reproduce the issue here and the attached patch should fix the
problem (and adds a regression test). Thanks again for reporting!

Cheers,
 Michael
>From 8f3594c3487800edc2a97af1f3290049776dc556 Mon Sep 17 00:00:00 2001
From: Michael Vogt 
Date: Wed, 12 Feb 2014 07:59:07 +0100
Subject: [PATCH] Use a APT::VersionSet instead of a VersionList

Use a APT::VersionSet instead of a APT::VersionList in DoDownload()
to ensure that there is only one version in the set even if the
user passes multiple identical name/versions on the commandline
(Bug#738103)
---
 cmdline/apt-get.cc | 6 +++---
 test/integration/test-apt-get-download | 5 +
 2 files changed, 8 insertions(+), 3 deletions(-)

diff --git a/cmdline/apt-get.cc b/cmdline/apt-get.cc
index 1019ff3..4d60910 100644
--- a/cmdline/apt-get.cc
+++ b/cmdline/apt-get.cc
@@ -630,8 +630,8 @@ bool DoDownload(CommandLine &CmdL)
   return false;
 
APT::CacheSetHelper helper(c0out);
-   APT::VersionList verset = APT::VersionList::FromCommandLine(Cache,
-		CmdL.FileList + 1, APT::VersionList::CANDIDATE, helper);
+   APT::VersionSet verset = APT::VersionSet::FromCommandLine(Cache,
+		CmdL.FileList + 1, APT::VersionSet::CANDIDATE, helper);
 
if (verset.empty() == true)
   return false;
@@ -650,7 +650,7 @@ bool DoDownload(CommandLine &CmdL)
std::string const cwd = SafeGetCWD();
_config->Set("Dir::Cache::Archives", cwd);
int i = 0;
-   for (APT::VersionList::const_iterator Ver = verset.begin();
+   for (APT::VersionSet::const_iterator Ver = verset.begin();
 	 Ver != verset.end(); ++Ver, ++i)
{
   pkgAcquire::Item *I = new pkgAcqArchive(&Fetcher, SrcList, &Recs, *Ver, storefile[i]);
diff --git a/test/integration/test-apt-get-download b/test/integration/test-apt-get-download
index c2a5c3d..0d92283 100755
--- a/test/integration/test-apt-get-download
+++ b/test/integration/test-apt-get-download
@@ -39,3 +39,8 @@ aptget download apt
 aptget download apt
 testsuccess test -s apt_2.0_all.deb
 rm -f apt_1.0_all.deb
+
+# deb:738103 - apt-get download foo foo fails
+rm -f apt_*.deb
+aptget download apt apt
+testsuccess test -s apt_2.0_all.deb
-- 
1.8.3.2

Bug#734617: Compilation of 1.63 fails on cppcheck

[Octavio Alvarez]

Hi.

I tried compiling cppcheck 1.63 but I was not successful. A newer
version of TinyXML-2 is needed. I submitted a bug report to
libtinyxml2-0.0.0 maintainer with this request.

In the meanwhile, cppcheck 1.63 compiles if their own tinyxml2
implementation (included in externals/tinyxml2) is used.

Attached is a patch that lets me compile cppcheck 1.63 using its own
copy of tinyxml2.
--- cppcheck-1.61/debian/rules	2013-08-04 10:05:47.0 -0700
+++ cppcheck-1.63+dfsg/debian/rules	2014-02-11 11:34:06.399181350 -0800
@@ -14,7 +14,7 @@
 
 override_dh_auto_build:
 	sed -i.nocppflags -e 's/\$$(CXX) \$$(CXXFLAGS)/$$(CXX) $$(CPPFLAGS) $$(CXXFLAGS)/' Makefile
-	dh_auto_build -- HAVE_RULES=yes TINYXML=-ltinyxml2 INCLUDE_FOR_LIB=-Ilib INCLUDE_FOR_CLI=-Ilib INCLUDE_FOR_TEST="-Ilib -Icli"
+	dh_auto_build -- HAVE_RULES=yes INCLUDE_FOR_LIB="-Ilib -Iexternals/tinyxml" INCLUDE_FOR_CLI="-Ilib -Iexternals/tinyxml" INCLUDE_FOR_TEST="-Ilib -Icli -Iexternals/tinyxml"
 	$(XP) $(DB2MAN) man/cppcheck.1.xml
 
 override_dh_auto_clean:
@@ -22,10 +22,10 @@
 	[ ! -f Makefile.nocppflags ] || mv -f Makefile.nocppflags Makefile
 
 override_dh_auto_test:
-	dh_auto_test -- HAVE_RULES=yes TINYXML=-ltinyxml2 INCLUDE_FOR_LIB=-Ilib INCLUDE_FOR_CLI=-Ilib INCLUDE_FOR_TEST="-Ilib -Icli"
+	dh_auto_test -- HAVE_RULES=yes INCLUDE_FOR_LIB="-Ilib -Iexternals/tinyxml" INCLUDE_FOR_CLI="-Ilib -Iexternals/tinyxml" INCLUDE_FOR_TEST="-Ilib -Icli -Iexternals/tinyxml"
 
 override_dh_auto_install:
-	dh_auto_install -- HAVE_RULES=yes TINYXML=-ltinyxml2 INCLUDE_FOR_LIB=-Ilib INCLUDE_FOR_CLI=-Ilib INCLUDE_FOR_TEST="-Ilib -Icli"
+	dh_auto_install -- HAVE_RULES=yes INCLUDE_FOR_LIB="-Ilib -Iexternals/tinyxml" INCLUDE_FOR_CLI="-Ilib -Iexternals/tinyxml" INCLUDE_FOR_TEST="-Ilib -Icli -Iexternals/tinyxml"
 
 %:
 	dh $@

Bug#738508: python-coverage: Please split shared files into an arch:all package

[Dmitry Shachnev]

Hi Ben,

> Thank you for filing this at “wishlist” severity. What do you think this
> amount of storage is worth a new package? Bear in mind that new packages
> also require an additional overhead of storage.

> Currently I'm inclined to leave these files in the packages, until there is
> at least an order of magnitude greater duplication.

According to , this package
is currently built on 19 architectures, thus we have 38 .deb packages shipping
those files.

The benefit will be something like:

  (11229 + 3595 + 264 + 267 + 3585 + 5256) × 38 = 919448 bytes,
  minus size of files /usr/share/doc in the new package

… which is definitely small enough to not care about.

So feel free to close this bug. I should really have done this calculation
before filing this bug.

--
Dmitry Shachnev

signature.asc
Description: OpenPGP digital signature

Bug#738700: libtinyxml2-0.0.0: An update to libtinyxml2-0.0.0 is needed

[Octavio Alvarez]

Package: libtinyxml2-0.0.0
Version: 0~git20120518.1.a2ae54e-1
Severity: normal

Dear Maintainer,

Due to some updates to TinyXML-2, newer versions of cppcheck won't
build. Specifically, the XMLParser constructor has a new optional
parameter which is used by cppcheck.

Please consider packaging a newer version of TinyXML-2.

Thank you very much.


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

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

Versions of packages libtinyxml2-0.0.0 depends on:
ii  libc6  2.17-97
ii  libgcc11:4.8.2-10
ii  libstdc++6 4.8.2-10
ii  multiarch-support  2.17-97

libtinyxml2-0.0.0 recommends no packages.

libtinyxml2-0.0.0 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#584657: some additional parse/undefined object-group/... errors

[Rami Lehti]

This bug is still here.

You can also work around it by editing /var/lib/snmp/mib_indexes/* files
to not include the mibs giving errors and use

mibs +ALL

in snmp.conf

Kind regards,
Rami Lehti
--
Systems Manager
Bitwise oy


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

Bug#738583: libcglib-java - Uses jarjar without proper copyright or Built-Using

[tony mancill]

On 02/11/2014 10:58 PM, Emmanuel Bourg wrote:
> Le 12/02/2014 06:31, tony mancill a écrit :
> 
>> The attribution looks appropriate to me.  I changed the version number
>> to we're not uploading a new upstream source version just to switch to
>> XZ compression.  That'll take effect with the next upstream upload (or
>> repack, if that ends up being necessary).
> 
> Actually I changed the upstream tarball because it was missing the asm
> license in the lib directory. That's why I incremented the upstream part
> of the version.

Okay, I missed that.  I have to re-upload anyway, since the Built-Using
field must specify the source package - that is, "asm3" and not
"libasm3-java".  I'll use the repackaged source tarball for that.

Thank you,
tony




signature.asc
Description: OpenPGP digital signature

Bug#738583: libcglib-java - Uses jarjar without proper copyright or Built-Using

[Emmanuel Bourg]

Le 12/02/2014 06:31, tony mancill a écrit :

> The attribution looks appropriate to me.  I changed the version number
> to we're not uploading a new upstream source version just to switch to
> XZ compression.  That'll take effect with the next upstream upload (or
> repack, if that ends up being necessary).

Actually I changed the upstream tarball because it was missing the asm
license in the lib directory. That's why I incremented the upstream part
of the version.

Emmanuel Bourg


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

Bug#738695: Package: ipsec-tools (1:0.8.0-14) - IPSEC GRE Tunnel over IPv6

[Andrei POPESCU]

Control: reassign -1 ipsec-tools 1:0.8.0-14

On Ma, 11 feb 14, 21:48:49, Abhishek Dwivedi wrote:
> Package: ipsec-tools (1:0.8.0-14) 

Just for future reference, when you submit bugs the version information 
has to be in a dedicated field:

Version: x.x.x.x

Kind regards,
Andrei
-- 
http://wiki.debian.org/FAQsFromDebianUser
Offtopic discussions among Debian users and developers:
http://lists.alioth.debian.org/mailman/listinfo/d-community-offtopic
http://nuvreauspam.ro/gpg-transition.txt


signature.asc
Description: Digital signature

Bug#738699: RFS: shell-fm/0.8-1 [ITA]

[Micheal Waltz]

Package: sponsorship-requests
Severity: normal

Dear mentors,

I am looking for a sponsor for my package "shell-fm":

* Package name: shell-fm
  Version : 0.8-1
  Upstream Author : Jonas Kramer
* URL : http://nex.scrapping.cc/shell-fm/
* License : GPL-2+
  Section : sound

It builds those binary packages:

 shell-fm - console based player for last.fm radio streams

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

 http://mentors.debian.net/package/shell-fm

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

 dget -x 
http://mentors.debian.net/debian/pool/main/s/shell-fm/shell-fm_0.8-1.dsc

More information about shell-fm can be obtained from
http://nex.scrapping.cc/shell-fm/

Changes since the last upload:

  * New maintainer (Closes: #733534)
  * debian/watch
   - Add upstream watch file
  * debian/copyright
   - Change (C) to Copyright to match newer boileplate
  * debian/copyright
   - Point directly to GPL-2 instead of symlink-license
  * New Git Release - v0.8
- API v2 (closes: #695256)
- Correct use of memset count/value (closes: #609090)
- Handle chunked HTTP responses (closes: #668006)
  * debian/control
   - Updated maintainer field
   - Updated standards-version to 3.9.5
   - Updated debhelper to 9
  * debian/rules
   - Updated recommended target format
  * debian/patches
   - Removed modified CFLAGS since it matches upstream now
  * debian/rules
   - Add override_dh_installchangelogs for RELEASE
   - Run all dh scripts

Regards,
Micheal Waltz


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

Bug#738698: gretl: RPATH set to /build/gretl-XYa8PD/gretl-1.9.14/debian/gretl/usr/lib

[Niels Thykier]

Source: gretl
Version: 1.9.14-1
Severity: normal

Hi,

Lintian reports that the RPATH in 1.9.14-1[1] was set to:

usr/bin/gretl_x11 /build/gretl-XYa8PD/gretl-1.9.14/debian/gretl/usr/lib
usr/lib/gretl-gtk2/anova.so 
/build/gretl-XYa8PD/gretl-1.9.14/debian/gretl/usr/lib
usr/lib/gretl-gtk2/arbond.so 
/build/gretl-XYa8PD/gretl-1.9.14/debian/gretl/usr/lib
usr/lib/gretl-gtk2/arma.so 
/build/gretl-XYa8PD/gretl-1.9.14/debian/gretl/usr/lib
usr/lib/gretl-gtk2/arma_x12.so 
/build/gretl-XYa8PD/gretl-1.9.14/debian/gretl/usr/lib
usr/lib/gretl-gtk2/biprobit.so 
/build/gretl-XYa8PD/gretl-1.9.14/debian/gretl/usr/lib
usr/lib/gretl-gtk2/duration.so 
/build/gretl-XYa8PD/gretl-1.9.14/debian/gretl/usr/lib
usr/lib/gretl-gtk2/eviews_import.so 
/build/gretl-XYa8PD/gretl-1.9.14/debian/gretl/usr/lib
usr/lib/gretl-gtk2/excel_import.so 
/build/gretl-XYa8PD/gretl-1.9.14/debian/gretl/usr/lib
usr/lib/gretl-gtk2/fractals.so 
/build/gretl-XYa8PD/gretl-1.9.14/debian/gretl/usr/lib
usr/lib/gretl-gtk2/garch.so 
/build/gretl-XYa8PD/gretl-1.9.14/debian/gretl/usr/lib
usr/lib/gretl-gtk2/gnumeric_import.so 
/build/gretl-XYa8PD/gretl-1.9.14/debian/gretl/usr/lib
usr/lib/gretl-gtk2/gretlzip.so 
/build/gretl-XYa8PD/gretl-1.9.14/debian/gretl/usr/lib
usr/lib/gretl-gtk2/heckit.so 
/build/gretl-XYa8PD/gretl-1.9.14/debian/gretl/usr/lib
usr/lib/gretl-gtk2/interpolate.so 
/build/gretl-XYa8PD/gretl-1.9.14/debian/gretl/usr/lib
usr/lib/gretl-gtk2/interval.so 
/build/gretl-XYa8PD/gretl-1.9.14/debian/gretl/usr/lib
usr/lib/gretl-gtk2/jmulti_import.so 
/build/gretl-XYa8PD/gretl-1.9.14/debian/gretl/usr/lib
usr/lib/gretl-gtk2/johansen.so 
/build/gretl-XYa8PD/gretl-1.9.14/debian/gretl/usr/lib
usr/lib/gretl-gtk2/kernel.so 
/build/gretl-XYa8PD/gretl-1.9.14/debian/gretl/usr/lib
usr/lib/gretl-gtk2/leverage.so 
/build/gretl-XYa8PD/gretl-1.9.14/debian/gretl/usr/lib
usr/lib/gretl-gtk2/mailer.so 
/build/gretl-XYa8PD/gretl-1.9.14/debian/gretl/usr/lib
usr/lib/gretl-gtk2/mp_ols.so 
/build/gretl-XYa8PD/gretl-1.9.14/debian/gretl/usr/lib
usr/lib/gretl-gtk2/nistcheck.so 
/build/gretl-XYa8PD/gretl-1.9.14/debian/gretl/usr/lib
usr/lib/gretl-gtk2/odbc_import.so 
/build/gretl-XYa8PD/gretl-1.9.14/debian/gretl/usr/lib
usr/lib/gretl-gtk2/ods_import.so 
/build/gretl-XYa8PD/gretl-1.9.14/debian/gretl/usr/lib
usr/lib/gretl-gtk2/panurc.so 
/build/gretl-XYa8PD/gretl-1.9.14/debian/gretl/usr/lib
usr/lib/gretl-gtk2/pca.so 
/build/gretl-XYa8PD/gretl-1.9.14/debian/gretl/usr/lib
usr/lib/gretl-gtk2/poisson.so 
/build/gretl-XYa8PD/gretl-1.9.14/debian/gretl/usr/lib
usr/lib/gretl-gtk2/quantreg.so 
/build/gretl-XYa8PD/gretl-1.9.14/debian/gretl/usr/lib
usr/lib/gretl-gtk2/range-mean.so 
/build/gretl-XYa8PD/gretl-1.9.14/debian/gretl/usr/lib
usr/lib/gretl-gtk2/reprobit.so 
/build/gretl-XYa8PD/gretl-1.9.14/debian/gretl/usr/lib
usr/lib/gretl-gtk2/sas_import.so 
/build/gretl-XYa8PD/gretl-1.9.14/debian/gretl/usr/lib
usr/lib/gretl-gtk2/spss_import.so 
/build/gretl-XYa8PD/gretl-1.9.14/debian/gretl/usr/lib
usr/lib/gretl-gtk2/stata_import.so 
/build/gretl-XYa8PD/gretl-1.9.14/debian/gretl/usr/lib
usr/lib/gretl-gtk2/stats_tables.so 
/build/gretl-XYa8PD/gretl-1.9.14/debian/gretl/usr/lib
usr/lib/gretl-gtk2/sysest.so 
/build/gretl-XYa8PD/gretl-1.9.14/debian/gretl/usr/lib
usr/lib/gretl-gtk2/tramo-x12a.so 
/build/gretl-XYa8PD/gretl-1.9.14/debian/gretl/usr/lib
usr/lib/gretl-gtk2/urcdist.so 
/build/gretl-XYa8PD/gretl-1.9.14/debian/gretl/usr/lib
usr/lib/gretl-gtk2/vif.so 
/build/gretl-XYa8PD/gretl-1.9.14/debian/gretl/usr/lib
usr/lib/gretl-gtk2/xlsx_import.so 
/build/gretl-XYa8PD/gretl-1.9.14/debian/gretl/usr/lib

I suspect this to be a bug since /build looks like a build-time path.
Please note that the reports shown seems to be limited to either i386
or amd64 (sadly the Lintian HTML reports do not include architecture
information at the moment).

~Niels

[1] http://lintian.debian.org/full/e...@debian.org.html#gretl


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

Bug#724444: patch

[Eric Dorland]

Control: tags -1 patch

Patch attached.

-- 
Eric Dorland 
ICQ: #61138586, Jabber: ho...@jabber.com

diff -ruN whitedune-0.30.10.old/debian/control whitedune-0.30.10/debian/control
--- whitedune-0.30.10.old/debian/control	2014-02-12 00:33:37.388249031 -0500
+++ whitedune-0.30.10/debian/control	2014-02-12 01:08:34.235505313 -0500
@@ -3,7 +3,7 @@
 Priority: optional
 Maintainer: Debian Multimedia Maintainers 
 Uploaders: Philippe Coval 
-Build-Depends: debhelper (>= 5), autotools-dev, automake1.9, autoconf, bison, flex, gawk, libxmu-dev, libxi-dev, x11proto-core-dev, libmotif-dev, libpng-dev, libjpeg-dev, libglu1-mesa-dev, libgl1-mesa-dev, libgl1-mesa-dev | libgl-dev  | freeglut3-dev
+Build-Depends: debhelper (>= 5), autotools-dev, autoconf, bison, flex, gawk, libxmu-dev, libxi-dev, x11proto-core-dev, libmotif-dev, libpng-dev, libjpeg-dev, libglu1-mesa-dev, libgl1-mesa-dev, libgl1-mesa-dev | libgl-dev  | freeglut3-dev
 Standards-Version: 3.9.1
 Homepage: http://vrml.cip.ica.uni-stuttgart.de/dune/
 Vcs-Git: git://git.debian.org/git/pkg-multimedia/whitedune.git


signature.asc
Description: Digital signature

Bug#738697: few bugs in 1.4.3 which were fixed post-release upstream (blender effects, saving to Desktop)

[Yaroslav Halchenko]

Package: openshot
Version: 1.4.3-1.1
Severity: normal
Tags: patch

decided to do a little video editing and right away ran into few litle issues
which apparently not new and were fixed upstream in 

http://bazaar.launchpad.net/~openshot.code/openshot/main/changes/742?start_revid=742
740 Fix an error when saving a project when there is no /user/De...  Andy 
Finch  2013-07-02  DiffFiles
739 Fixed bug on Blender bug on dissolve animation (Blender Pyth...  
Jonathan Thomas 2013-06-28  DiffFiles
738 Fixed blender bug with 2.67, where background alpha_mode was...  
Jonathan Thomas 2013-06-28  DiffFiles


current upstream development is going full steam forward to 2.0 but it
might take awhile until that one released/stable enough.
So would you be so kind to include those post 1.4.3 patches in the Debian 
package in unstable?

Thank you very much in advance

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

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

Versions of packages openshot depends on:
ii  fontconfig   2.10.2-2
ii  gtk2-engines-pixbuf  2.24.20-1
ii  librsvg2-common  2.36.4-2
ii  melt 0.9.0-3
ii  python   2.7.5-5
ii  python-gtk2  2.24.0-3+b1
ii  python-httplib2  0.7.4-2
ii  python-imaging   2.2.1-2
ii  python-mlt   0.9.0-3
ii  python-pygoocanvas   0.14.1-1+b3
ii  python-support   1.0.15
ii  python-xdg   0.25-3

Versions of packages openshot recommends:
ii  frei0r-plugins  1.1.22git20091109-1.2
ii  openshot-doc1.4.3-1.1

Versions of packages openshot suggests:
ii  blender   2.69-3
ii  inkscape  0.48.4-3+b1

-- 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#738616: removing newer libasio-dev (v1.10) from unstable

[Markus Wanner]

On 02/12/2014 01:50 AM, Andreas Beckmann wrote:
> Control: reassign -1 asio 1.10.1-1
> Control: close -1 1:1.4.8-3
> 
> On 2014-02-11 22:26, Daniel Pocock wrote:
>> We should mark 738613 fixed in the new version I think
> 
> Done.

Just for the record: this is #738616. But it is okay to close as well.

I already marked #738613 as closed by 1:1.4.8-3.

Thanks

Markus Wanner




signature.asc
Description: OpenPGP digital signature

Bug#721618: Fix "schleuder" somehow

[Ondřej Surý]

It's not in testing, so it doesn't block the removal. Otherwise fill the 
removal bug, the package can be reintroduced later when fixed.

O.
-- 
Ondřej Surý 
Knot DNS (https://www.knot-dns.cz/) – a high-performance DNS server

> On 12. 2. 2014, at 1:41, Christian Hofstaedtler  wrote:
> 
> Hello everybody,
> 
> Please, if anyhow possible, fix schleuder so it no longer depends on
> ruby-tmail or ruby-actionmailer (2.3), so we can go ahead with the
> removal of ruby1.8.
> 
> Thank you,
> -- 
> ,''`.  Christian Hofstaedtler 
> : :' :  Debian Developer
> `. `'   7D1A CFFA D9E0 806C 9C4C  D392 5C13 D6DB 9305 2E03
>  `-
> 

Bug#738421: qtjsbackend-opensource-src: FTBFS: cp: cannot stat 'debian/tmp/usr/share/qt5/mkspecs/modules/qt_lib_v8.pri': No such file or directory

[Hideki Yamane]

control: severity -1 normal
control: block -1 by 737522

Hi,

>> This package is already waiting for being removed, see #737522

 So, just ignore it with normal severity and add blocking bug.



-- 
Hideki Yamane

Bug#738583: libcglib-java - Uses jarjar without proper copyright or Built-Using

[tony mancill]

On 02/11/2014 04:29 AM, Emmanuel Bourg wrote:
> I prepared an update of the cglib package on alioth:
> 
> - The Built-Using field has been added
> - debian/copyright now mentions the inclusion of the asm classes
> - the asm license file is now included in cglib-nodep.jar like the jar
> distributed by upstream
> 
> Tony, could you please upload this update if you think it addresses this
> issue properly?

Hi Emmanuel,

The attribution looks appropriate to me.  I changed the version number
to we're not uploading a new upstream source version just to switch to
XZ compression.  That'll take effect with the next upstream upload (or
repack, if that ends up being necessary).

Thank you for the update!  Uploaded.
tony



signature.asc
Description: OpenPGP digital signature

Bug#738283: RFS: rotix/0.83-4.1 RC, NMU

[Nicholas Breen]

On Sat, Feb 08, 2014 at 11:09:07PM +0100, Andreas Moog wrote:
> Package: sponsorship-requests
> Severity: important
> 
> Dear mentors,
> 
> I am looking for a sponsor for a NMU of the package "rotix"
> 
>  * Package name: rotix
>Version : 0.83-4.1
>Section : text

That package has subsequently been orphaned, #738336.  The next comment on that
bug asks whether it should be removed from the archive instead, as there are
other options.  Are you interested in either adopting it or encouraging its
removal?


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

Bug#738611: acpid: Mic mute button not recognized on Thinkpad again

[Lingzhu Xiang]

On Tue, Feb 11, 2014 at 10:44 PM, Ted Felix  wrote:
> On 02/11/2014 10:21 PM, Lingzhu Xiang wrote:
>>
>> I would suggest translating F20 backto MICMUTE.
>
>
>   The problem with this is that one day in the future, someone will need F20
> for something else.  And we'll have to either break those who use it for
> micmute, or we cannot meet this new requirement.

If now acpid users change rules to handle button/f20 for mic muting,
and in the future udev maps something else to f20 in your case, then
those rules will break again. If acpid maintains sane semantics then
users don't need to worry about this.

>   Will you be able to do what you need to do if you receive a button/f20
> event?  Can you explain in more detail exactly how you will be using this
> event?  Will you be using it via acpid config files?  Or will you be
> connecting to the acpid socket?  Or something else?

I can. Currently I override udev keymaps to map the micmute as micmute
and handle it with a acpid rule. I don't use gnome-settings-daemon,
but this way breaks it.

I originally thought this should really be a regression and a bad
workaround in udev, but apparently non-gnome users are minority.
https://bugs.freedesktop.org/show_bug.cgi?id=54171

>   Based on the particulars, I have a number of alternative solutions that
> should solve your current issue and future-proof acpid at the same time.

I can certainly help with my individual problem but I just wanted to
report about the regression from
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=701206 (archived,
couldn't post).

> Ted.
>
> PS: I'm having trouble sending email to bugs.debian.org.  If you could quote
> my entire email in your response, that would at least get it into the bug
> report.  Thanks.


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

Bug#679755: wkhtmltopdf: new upstream release

[Ashish Kulkarni]

Any update on what you think about the above rationale? I can
understand if you want to discuss it with the maintainers for QT..


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

Bug#738440: cups: new version contains Ubuntu Bug #1019662

[Randy Reitz]

It was an adventure, but I finally made a new foomatic-rip.  It works!!

Along the way, I picked up:
rreitz@sheevaplug:~/cups-filters-1.0.43$ dpkg -l cups-filters
Desired=Unknown/Install/Remove/Purge/Hold
| Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend
|/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad)
||/ Name  Version ArchitectureDescription
+++-=-===-===-===
ii  cups-filters  1.0.44-2armel   OpenPrinting CUPS 
Filters - Main Package

which does not work, but I guess you know that.

I look forward to 1.0.44-3.

Thanks,
Randy

On Feb 11, 2014, at 2:45 AM, Didier 'OdyX' Raboud  wrote:

> Le lundi, 10 février 2014, 23.34:23 Till Kamppeter a écrit :
>> I have fixed the problem upstream (BZR rev. 7159) now. I do not use
>> PATH+MAX any more for strings which are used to hold a command line.
>> Command lines have 65535 bytes now.
>> 
>> Please test and tell whether it solves the problem. If so, I will
>> release a new cups-filters version.
> 
> At least it doesn't cause obvious regressions for me.
> 
> Till: if you release a new version, can you include your fix for the 
> upstart job?
> 
> Randy: can you recompile cups-filters on your platform with the attached 
> patch and confirm that it works?
> 
> Cheers, 
> OdyX

Bug#738696: acpi-support-base: acpi-support CheckPolicy() should account for mate-power-manager and logind

[pasky]

Package: acpi-support-base
Version: 0.141-2
Severity: normal

Dear Maintainer,

as it stands, /usr/share/acpi-support/policy-funcs:CheckPolicy() will
not prevent scripts like /etc/acpi/sleep_suspendbtn.sh from acting
when logind or mate-power-manager is running. logind is already provided
by systemd in Debian and configured to handle power hotkeys by default;
mate-power-manger is not in Debian yet, but packaged externally, on its
way in and some Debian users are already using it.

I'm currently running systemd + Mate and in the a bit absurd situation
of having the system suspend *three* times after one keypress in default
configuration. :-)  Another issue is making Mate + logind work together,
but preventing a fallback action from acpi-support is probably a good
first start to resolve this.


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

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

Versions of packages acpi-support-base depends on:
ii  acpid  1:2.0.21-1

acpi-support-base recommends no packages.

Versions of packages acpi-support-base suggests:
ii  acpi-support  0.141-2
ii  consolekit0.4.6-3+b1

-- 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#421400: libsvn-java package broken with gcj jvm?

[Roberto C . Sánchez]

On Mon, Jan 02, 2012 at 02:57:09AM -0600, Jonathan Nieder wrote:
> tags 421400 + moreinfo
> quit
> 
> Roberto C. Sanchez wrote:
> 
> > When running with the default JVM, the subclipse plugin to eclipse
> > causes the excpetion below.  When running with the Sun JVM
> > `JAVA_HOME=/usr/lib/jvm/java-1.5.0-sun /usr/bin/eclipse`, everything
> > works correctly.
> [...]
> > $ /usr/bin/eclipse
> > searching for compatible vm...
> >   testing /usr/lib/jvm/java-gcj...found
> > java.lang.ClassNotFoundException: org.tigris.subversion.javahl.SVNClient 
> > not found in 
> > gnu.gcj.runtime.SystemClassLoader{urls=[file:/usr/lib/eclipse/startup.jar], 
> > parent=gnu.gcj.runtime.ExtensionClassLoader{urls=[], parent=null}}
> 
> Thanks.  Can you still reproduce this?  If not, do you remember
> approximately when and how it was resolved?  (E.g., was it a
> subversion or a gcj update that helped?  /var/log/dpkg.log* might help
> in remembering.)
> 
Hi Jonathan,

It is my turn to apologize for taking so long to follow up.  Basically,
I cannot reproduce the same behavior.  However, today, with eclipse,
libsvn-java (both from stable), and Subclipse installed from the Tigris
update site (http://subclipse.tigris.org/update_1.6.x) the Eclipse
interface is entirely non-responsive.  I tested this on a Wheezy system
with these two commands:

JAVA_HOME=/usr/lib/jvm/java-1.5.0-gcj-4.7 /usr/bin/eclipse
JAVA_HOME=/usr/lib/jvm/java-7-openjdk-i386/ /usr/bin/eclipse

Both exhibited the same behavior of a non-responsive interface and I had
to use Control-C in the terminal to terminate the application.  When I
remove the Subclipse plugin (i.e., remove the Subclipse JAR files from
~/.eclipse/org.eclipse.platform_3.8_155965261/plugins/ to some other
place), Eclipse worked perfectly.

I apologize that I cannot reproduce it exactly, as I have not used the
Sun JVM for quite some time and I don't use Subclipse anymore as I have
switched to Git.

Regards,

-Roberto

-- 
Roberto C. Sánchez
http://people.connexer.com/~roberto
http://www.connexer.com


signature.asc
Description: Digital signature

Bug#738695: Package: ipsec-tools (1:0.8.0-14) - IPSEC GRE Tunnel over IPv6

[Abhishek Dwivedi]

Package: ipsec-tools (1:0.8.0-14) 

I am trying to establish a GRE/IPSEC tunnel over v6. Following is the entry in 
/etc/ipsec-tools.conf file :

spdadd 2001:470:bb12:200::12 2001:4b8:1::288 gre -P out ipsec 
esp/transport//require;
spdadd 2001:4b8:1::288 2001:470:bb12:200::12 gre -P in ipsec 
esp/transport//require;
In the above case the entries are not getting added to SAD and racoon's phase 1 
negotiations are not happening.

If I change the protocol from "gre" to "any":

spdadd 2001:470:bb12:200::12 2001:4b8:1::288 any -P out ipsec 
esp/transport//require;
spdadd 2001:4b8:1::288 2001:470:bb12:200::12 any -P in ipsec 
esp/transport//require;
In this case SAD is populated and IPSEC tunnels is established.

2014-02-11 15:46:23: INFO: IPsec-SA established: ESP/Transport 
2001:4b8:1::288[500]->2001:470:bb12:200::12[500] spi=264498919(0xfc3eee7)
2014-02-11 15:46:23: INFO: IPsec-SA established: ESP/Transport 
2001:4b8:1::288[500]->2001:470:bb12:200::12[500] spi=138505741(0x8416e0d)

Looking forward to a positive response.

Cheers!

Abhishek

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

Bug#738683: RFS: hexchat/2.9.6.1-1 [ITP]

[Jesse Rhodes]

I've also filed an upstream bug due to the Lintian pedantic warning of
debian-watch-may-check-gpg-signature.

That bug can be found here: https://github.com/hexchat/hexchat/issues/895


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

Bug#738691: Please update Vendor/Ubuntu.pm for Ubuntu's ppc64el defaults

[Guillem Jover]

Hi!

On Tue, 2014-02-11 at 18:57:42 -0700, Adam Conrad wrote:
> Package: dpkg
> Version: 1.17.5
> Severity: wishlist
> Tags: patch
> User: ubuntu-de...@lists.ubuntu.com
> Usertags: origin-ubuntu trusty ubuntu-patch

> In Ubuntu, the attached patch was applied to achieve the following:
> 
>   * Update the ppc64 buildflags vendor overrides for ppc64el instead, and
> make the implementation respect DEB_BUILD_OPTIONS=noopt (LP: #1279128)
> 
> In bug #612472, Colin submitted a patch to set buildflags on ppc64 in
> Ubuntu to -O3.  This turns out to have two fundamental flaws:
> 
> 1) We never actually shipped a ppc64 distribution.
> 2) It failed to respect DEB_BUILD_OPTIONS=noopt.
> 
> This patch addresses both those issues, by changing ppc64 to ppc64el,
> which we are shipping, and falling through gracefully for the noopt case.
> 
> It would be lovely if this could be applied to dpkg trunk, so we can
> reduce our delta.  Thanks in advance.

Sure, applied locally, will be included in my next push targetting
1.17.7.

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#738694: grep: Behavior of --exclude-dir has changed

[Leandro Adamson]

Package: grep
Version: 2.12-2
Severity: normal

The behavior of --exclude-dir changed between squeeze
(2.6.3-3+squeeze1) and wheezy (2.12-2).  The new behavior is present
in the current unstable version as well (2.16-1).

A test script is attached.  Tests 4,6,7,8,11,12 produce different
results between squeeze's grep and the newer versions.  I can't see
any reason why the change in behavior would be desirable, and it makes
many (probably most) uses of --exclude-dir impossible.  In particular
the new behavior doesn't allow --exclude-dir patterns to match on
parent directories, so for example you can't distinguish between
/usr/share/doc and /usr/local/share/doc, you can only exclude "doc" or
"*doc*".

I'm assuming this is an unintentional bug, but if not then consider
this a wishlist item for the prior behavior, especially being able to
match on parent directories.  Also, the change should be documented
clearly in the Debian changelog and apt-listchanges since it can break
scripts relying on the prior behavior.



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

Kernel: Linux 2.6.32-5-686-bigmem (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/bash

Versions of packages grep depends on:
ii  dpkg  1.16.12
ii  install-info  4.13a.dfsg.1-10
ii  libc6 2.13-38+deb7u1

grep recommends no packages.

Versions of packages grep suggests:
ii  libpcre3  1:8.30-5

-- no debconf information


test_grep_exclude_dir.sh
Description: Bourne shell script

Bug#738611: acpid: Mic mute button not recognized on Thinkpad again

[Lingzhu Xiang]

On Tue, Feb 11, 2014 at 7:15 AM, Ted Felix  wrote:
>   F20 can be added to the event table (evtab) in acpid's input_layer.c.  It
> can be set up to return button/f20.  Would this solve the problem for you?
>
> /* F20 is used for micmute */
> {{{0,0}, EV_KEY, KEY_F20, 1}, "button/f20 F20 0080 "},

Dear Ted,

I would suggest translating F20 backto MICMUTE. Freedesktop people
found nobody is using F20 so they decided to use F20 to work around
Xorg limit, and to translate F20 back to XF86AudioMicMute for apps
above X, which probably do not handle ACPI events directly.

https://bugs.freedesktop.org/show_bug.cgi?id=54171

For apps below X, button/micmute ACPI events would make more sense.

Lingzhu


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

Bug#722396: graphviz: diff for NMU version 2.26.3-16.2

[Christian Hofstaedtler]

tags 722396 + patch
thanks

Dear maintainer,

I've prepared an NMU for graphviz (versioned as 2.26.3-16.2). The diff
is attached to this message.

As this fixes an RC bug that hasn't seen any activity in weeks, I'm
uploading this right away.

Regards.

diff -Nru graphviz-2.26.3/debian/changelog graphviz-2.26.3/debian/changelog
--- graphviz-2.26.3/debian/changelog2014-01-12 17:09:27.0 +0100
+++ graphviz-2.26.3/debian/changelog2014-02-12 04:04:10.0 +0100
@@ -1,3 +1,10 @@
+graphviz (2.26.3-16.2) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Build Ruby bindings for Ruby 1.9.1. (Closes: #722396)
+
+ -- Christian Hofstaedtler   Wed, 12 Feb 2014 04:03:17 +0100
+
 graphviz (2.26.3-16.1) unstable; urgency=medium
 
   * Non-maintainer upload.
diff -Nru graphviz-2.26.3/debian/control graphviz-2.26.3/debian/control
--- graphviz-2.26.3/debian/control  2014-01-12 17:09:27.0 +0100
+++ graphviz-2.26.3/debian/control  2014-02-12 04:03:15.0 +0100
@@ -27,8 +27,8 @@
  ghostscript,
  lua5.1,
  liblua5.1-0-dev,
- ruby1.8,
- ruby1.8-dev,
+ ruby,
+ ruby-dev,
  php5-dev,
  php5-cli,
  python-all-dev,
@@ -130,13 +130,12 @@
 Package: libgv-ruby
 Architecture: any
 Section: ruby
-Depends: ${shlibs:Depends}, ruby1.8, ${misc:Depends}
+Depends: ${shlibs:Depends}, ${misc:Depends}
 Description: Ruby bindings for graphviz
  Graphviz is a set of graph drawing tools. See the description of the graphviz
  package for a full description.
  .
- This package contains the Ruby (1.8) bindings.
-
+ This package contains the Ruby bindings.
 
 Package: libgv-tcl
 Architecture: any
diff -Nru graphviz-2.26.3/debian/libgv-ruby.install 
graphviz-2.26.3/debian/libgv-ruby.install
--- graphviz-2.26.3/debian/libgv-ruby.install   2014-01-12 17:09:27.0 
+0100
+++ graphviz-2.26.3/debian/libgv-ruby.install   2014-02-12 03:54:26.0 
+0100
@@ -1,2 +1,3 @@
 usr/lib/graphviz/ruby/libgv_ruby.so
 usr/share/man/man3/gv.3ruby
+usr/lib/ruby/*/*/*/gv.so
diff -Nru graphviz-2.26.3/debian/patches/ruby-multiarch 
graphviz-2.26.3/debian/patches/ruby-multiarch
--- graphviz-2.26.3/debian/patches/ruby-multiarch   1970-01-01 
01:00:00.0 +0100
+++ graphviz-2.26.3/debian/patches/ruby-multiarch   2014-02-12 
03:38:46.0 +0100
@@ -0,0 +1,38 @@
+Description: Make Ruby bindings multiarch aware
+
+Index: graphviz-2.26.3/config/config_ruby.rb
+===
+--- graphviz-2.26.3.orig/config/config_ruby.rb 2014-02-12 03:38:32.144657757 
+0100
 graphviz-2.26.3/config/config_ruby.rb  2014-02-12 03:38:44.012572418 
+0100
+@@ -5,12 +5,15 @@ CONFIG = Config::MAKEFILE_CONFIG
+ 
+ case ARGV[0]
+ when "INCLUDES"
+-puts Config::expand(CONFIG["archdir"])
++dirs = [Config::expand(CONFIG["rubyhdrdir"])]
++# multiarch before 2.1
++dirs << Config::expand("$(rubyhdrdir)/$(sitearch)")
++puts "-I"+dirs.join(" -I")
+ when "lib"
+ puts Config::expand(CONFIG["libdir"])
+ when "archsitelib"
+-puts Config::expand(CONFIG["sitearchdir"])
++puts Config::expand(CONFIG["vendorarchdir"])
+ when "sitelib"
+-puts Config::expand(CONFIG["sitedir"])
++puts Config::expand(CONFIG["vendordir"])
+ end
+ 
+Index: graphviz-2.26.3/configure.ac
+===
+--- graphviz-2.26.3.orig/configure.ac  2014-02-12 03:38:32.144657757 +0100
 graphviz-2.26.3/configure.ac   2014-02-12 03:38:32.140657786 +0100
+@@ -1461,7 +1461,7 @@ else
+   if test "x$RUBY" = "x"; then
+   use_ruby="No (ruby not available)"
+   else
+-RUBY_INCLUDES="-I`$RUBY $srcdir/config/config_ruby.rb INCLUDES`"
++RUBY_INCLUDES="`$RUBY $srcdir/config/config_ruby.rb INCLUDES`"
+   # hack for powerpc-darwin8 (10.4)
+   if test "x$DARWIN" = "xyes"; then
+ RUBY_INCLUDES=`echo $RUBY_INCLUDES | sed 's/powerpc/universal/'`
diff -Nru graphviz-2.26.3/debian/patches/series 
graphviz-2.26.3/debian/patches/series
--- graphviz-2.26.3/debian/patches/series   2014-01-12 17:09:27.0 
+0100
+++ graphviz-2.26.3/debian/patches/series   2014-02-12 03:21:04.0 
+0100
@@ -13,10 +13,10 @@
 fix-kfreebsd-chroots
 fix-hurd-autotools
 automake_1.11.2_fixes
-explicit_ruby_1.8
 kfreebsd-hang.patch
 use-system-ltdl.patch
 buffer_overflow.patch
 CVE-2014-1235.patch
 CVE-2014-1236.patch
 fix-missing-format-string.patch
+ruby-multiarch
diff -Nru graphviz-2.26.3/debian/rules graphviz-2.26.3/debian/rules
--- graphviz-2.26.3/debian/rules2014-01-12 17:09:27.0 +0100
+++ graphviz-2.26.3/debian/rules2014-02-12 03:45:51.0 +0100
@@ -33,7 +33,6 @@
 PYTHON_VERSIONS   = $(shell pyversions -r)
 PYTHON_PACKAGE= $(CURDIR)/debian/libgv-python
 
-RUBY_VERSION  = 1.8
 RUBY_PACKAGE  = $(CURDIR)/debian/libgv-ruby
 
 CONFIG_SCRIPTS=config/config.guess lib/gd/config/config.guess 
libltdl/config.guess \
@@ -205,12 +204,6 @@
dh_installman -plibgvc$(SO

Bug#738693: ssh -W causes "getsockname failed: Bad file descriptor" errors

[Marco d'Itri]

Package: openssh-client
Version: 1:6.5p1-2
Severity: normal

Client and server use the same version.

md@bongo:~$ ssh -vvv -a -x -W server2.example.net:22 localhost
OpenSSH_6.5, OpenSSL 1.0.1f 6 Jan 2014
debug1: Reading configuration data /home/md/.ssh/config
debug3: cipher ok: arcfour128 [arcfour128]
debug3: ciphers ok: [arcfour128]
debug1: /home/md/.ssh/config line 8: Applying options for *
debug1: /home/md/.ssh/config line 106: Applying options for *
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 19: Applying options for *
debug1: auto-mux: Trying existing master
debug1: Control socket "/home/md/.ssh/.control_localhost_22_md" does not exist
debug2: ssh_connect: needpriv 0
debug1: Connecting to localhost [::1] port 22.
debug1: Connection established.
debug3: Incorrect RSA1 identifier
debug3: Could not load "/home/md/.ssh/id_rsa" as a RSA1 public key
debug1: identity file /home/md/.ssh/id_rsa type 1
debug1: identity file /home/md/.ssh/id_rsa-cert type -1
debug1: identity file /home/md/.ssh/id_dsa type -1
debug1: identity file /home/md/.ssh/id_dsa-cert type -1
debug3: Incorrect RSA1 identifier
debug3: Could not load "/home/md/.ssh/id_ecdsa" as a RSA1 public key
debug1: identity file /home/md/.ssh/id_ecdsa type 3
debug1: identity file /home/md/.ssh/id_ecdsa-cert type -1
debug3: Incorrect RSA1 identifier
debug3: Could not load "/home/md/.ssh/id_ed25519" as a RSA1 public key
debug1: identity file /home/md/.ssh/id_ed25519 type 4
debug1: identity file /home/md/.ssh/id_ed25519-cert type -1
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_6.5p1 Debian-2
debug1: Remote protocol version 2.0, remote software version OpenSSH_6.5p1 
Debian-2
debug1: match: OpenSSH_6.5p1 Debian-2 pat OpenSSH* compat 0x0400
debug2: fd 3 setting O_NONBLOCK
debug3: load_hostkeys: loading entries for host "localhost" from file 
"/home/md/.ssh/known_hosts"
debug3: load_hostkeys: found key type RSA in file /home/md/.ssh/known_hosts:4
debug3: load_hostkeys: loaded 1 keys
debug3: order_hostkeyalgs: prefer hostkeyalgs: 
ssh-rsa-cert-...@openssh.com,ssh-rsa-cert-...@openssh.com,ssh-rsa
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
[...]
debug2: mac_setup: found hmac-md5-...@openssh.com
debug1: kex: server->client aes128-ctr hmac-md5-...@openssh.com none
debug2: mac_setup: found hmac-md5-...@openssh.com
debug1: kex: client->server aes128-ctr hmac-md5-...@openssh.com none
debug1: sending SSH2_MSG_KEX_ECDH_INIT
debug1: expecting SSH2_MSG_KEX_ECDH_REPLY
debug1: Server host key: RSA (elided)
debug3: load_hostkeys: loading entries for host "localhost" from file 
"/home/md/.ssh/known_hosts"
debug3: load_hostkeys: found key type RSA in file /home/md/.ssh/known_hosts:4
debug3: load_hostkeys: loaded 1 keys
debug1: Host 'localhost' is known and matches the RSA host key.
debug1: Found key in /home/md/.ssh/known_hosts:4
debug1: ssh_rsa_verify: signature correct
debug2: kex_derive_keys
debug2: set_newkeys: mode 1
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug2: set_newkeys: mode 0
debug1: SSH2_MSG_NEWKEYS received
debug1: Roaming not allowed by server
debug1: SSH2_MSG_SERVICE_REQUEST sent
debug2: service_accept: ssh-userauth
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug2: key: /home/md/.ssh/id_rsa (0xf8d02680),
debug2: key: /home/md/.ssh/id_rsa-xxx (0xf8d08dc8),
debug2: key: /home/md/.ssh/id_dsa ((nil)),
debug2: key: /home/md/.ssh/id_ecdsa (0xf8d06b48),
debug2: key: /home/md/.ssh/id_ed25519 (0xf8d08868),
debug1: Authentications that can continue: 
publickey,password,keyboard-interactive
debug3: start over, passed a different list 
publickey,password,keyboard-interactive
debug3: preferred publickey,keyboard-interactive,password
debug3: authmethod_lookup publickey
debug3: remaining preferred: keyboard-interactive,password
debug3: authmethod_is_enabled publickey
debug1: Next authentication method: publickey
debug1: Offering RSA public key: /home/md/.ssh/id_rsa
debug3: send_pubkey_test
debug2: we sent a publickey packet, wait for reply
debug1: Server accepts key: pkalg ssh-rsa blen 149
debug2: input_userauth_pk_ok: fp (elided)
debug3: sign_and_send_pubkey: RSA (elided)
debug1: Authentication succeeded (publickey).
Authenticated to localhost ([::1]:22).
debug3: ssh_init_stdio_forwarding: server2.example.net:22
debug1: channel_connect_stdio_fwd server2.example.net:22
debug1: channel 0: new [stdio-forward]
debug2: fd 4 setting O_NONBLOCK
debug3: fd 5 is O_NONBLOCK
getsockname failed: Bad file descriptor
debug1: getpeername failed: Bad file descriptor
debug1: setting up multiplex master socket
debug3: muxserver_listen: temporary control path 
/home/md/.ssh/.control_localhost_22_md.TEl3AzgzLahGgDZd
debug2: fd 6 setting O_NONBLOCK
debug3: fd 6 is O_NONBLOCK
debug3: fd 6 is O_NONBLOCK
debug1: channel 1: new [/home/md/.ssh/.control_localhost_22_md]
debug3: muxserver_listen: mux listener channel 1 fd 6
debug2: fd 3 setting TCP_NODELAY
de

Bug#734373: OpenCV: please build SIFT and SURF modules

[Matthieu Tourne]

Sorry, a little late to this conversation.

Could there be a package libopencv-nonfree-dev by any chance ?

SIFT and SURF are indeed patented, but there have been no patent disputes
so far.
Also there are a lot of other free invariant features detectors /
descriptors that one can use if patents become a real issue.

For now it is just convenient to use Sift as it works well in most cases.

Cheers,
Matthieu

Bug#738692: stat: unkown error 8216 when open IPv6 Samba Share

[张敬强]

Package: dolphin
Version: 4:4.11.5-1
Severity: normal
Tags: ipv6

Dear Maintainer,

When open a IPv6 samba share address like "\\[2001:10::1]" dolphin
will give out "stat: unkown error 8216".
I can use smbclient connect to that IPv6 share.
And I can use the IPv4 address to open the share in dolphin.


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

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

Versions of packages dolphin depends on:
ii  kde-runtime 4:4.11.5-1
ii  libc6   2.17-97
ii  libkactivities6 4:4.11.5-1
ii  libkcmutils44:4.11.5-1
ii  libkdecore5 4:4.11.5-1
ii  libkdeui5   4:4.11.5-1
ii  libkfile4   4:4.11.5-1
ii  libkio5 4:4.11.5-1
ii  libknewstuff3-4 4:4.11.5-1
ii  libkonq5abi14:4.11.5-1
ii  libkparts4  4:4.11.5-1
ii  libnepomukcore4 4:4.11.5-2+b1
ii  libnepomukwidgets4abi1  4:4.11.5-1
ii  libphonon4  4:4.7.1-1
ii  libplasma3  4:4.11.5-1
ii  libqt4-dbus 4:4.8.5+git209-g718fae5+dfsg-1
ii  libqt4-xml  4:4.8.5+git209-g718fae5+dfsg-1
ii  libqtcore4  4:4.8.5+git209-g718fae5+dfsg-1
ii  libqtgui4   4:4.8.5+git209-g718fae5+dfsg-1
ii  libsolid4   4:4.11.5-1
ii  libsoprano4 2.9.4+dfsg-1
ii  libstdc++6  4.8.2-15
ii  libxrender1 1:0.9.8-1
ii  phonon  4:4.7.1-1

Versions of packages dolphin recommends:
ii  ruby  1:1.9.3.3

Versions of packages dolphin suggests:
pn  kdesdk-dolphin-plugins  

-- 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#738592: /usr/bin/scanimage: Canon LiDE 30 not working on Jessie (is working on wheezy)

[Mark Buda]

Tuxicoman  writes:
>
> Unfortunately i don't have any usb2 hub

Even if you had a USB 2 hub, if you connected it to a USB 3 port it
would still have the same problem, from what I have read.

> I'm unable to scan on any of my USB port.
> I tested all USB ports on a new laptop which has Jessie up to date and I
> can't scan neither.

There is a kernel patch here which has been reported by some people to
fix the issue, but it is not well tested and apparently has some
problems:

http://www.mail-archive.com/linux-usb@vger.kernel.org/msg30015.html

Sarah Sharp on the linux-usb list seems to have taken on the task of
finishing it.
-- 
Mark Buda 
I get my monkeys for nothing and my chimps for free.


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

Bug#738691: Please update Vendor/Ubuntu.pm for Ubuntu's ppc64el defaults

[Adam Conrad]

Package: dpkg
Version: 1.17.5
Severity: wishlist
Tags: patch
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu trusty ubuntu-patch



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

  * Update the ppc64 buildflags vendor overrides for ppc64el instead, and
make the implementation respect DEB_BUILD_OPTIONS=noopt (LP: #1279128)

In bug #612472, Colin submitted a patch to set buildflags on ppc64 in
Ubuntu to -O3.  This turns out to have two fundamental flaws:

1) We never actually shipped a ppc64 distribution.
2) It failed to respect DEB_BUILD_OPTIONS=noopt.

This patch addresses both those issues, by changing ppc64 to ppc64el,
which we are shipping, and falling through gracefully for the noopt case.

It would be lovely if this could be applied to dpkg trunk, so we can
reduce our delta.  Thanks in advance.

... Adam


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

Kernel: Linux 3.13.0-7-generic (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
diff -Nru dpkg-1.17.5ubuntu3/scripts/Dpkg/Vendor/Ubuntu.pm dpkg-1.17.5ubuntu4/scripts/Dpkg/Vendor/Ubuntu.pm
--- dpkg-1.17.5ubuntu3/scripts/Dpkg/Vendor/Ubuntu.pm	2013-12-09 23:14:22.0 -0700
+++ dpkg-1.17.5ubuntu4/scripts/Dpkg/Vendor/Ubuntu.pm	2014-02-11 18:33:52.0 -0700
@@ -95,10 +95,13 @@
 
 } elsif ($hook eq 'update-buildflags') {
 	my $flags = shift @params;
+	my $build_opts = Dpkg::BuildOptions->new();
 
-	if (debarch_eq(get_host_arch(), 'ppc64')) {
-	for my $flag (qw(CFLAGS CXXFLAGS GCJFLAGS FFLAGS)) {
-		$flags->set($flag, '-g -O3', 'vendor');
+	if (!$build_opts->has('noopt')) {
+	if (debarch_eq(get_host_arch(), 'ppc64el')) {
+		for my $flag (qw(CFLAGS CXXFLAGS GCJFLAGS FFLAGS)) {
+		$flags->set($flag, '-g -O3', 'vendor');
+		}
 	}
 	}
 	# Per https://wiki.ubuntu.com/DistCompilerFlags
@@ -108,7 +111,6 @@
 	$self->SUPER::run_hook($hook, $flags);
 
 	# Allow control of hardening-wrapper via dpkg-buildpackage DEB_BUILD_OPTIONS
-	my $build_opts = Dpkg::BuildOptions->new();
 	my $hardening;
 	if ($build_opts->has('hardening')) {
 	$hardening = $build_opts->get('hardening') // 1;

Bug#738683: RFS: hexchat/2.9.6.1-1 [ITP]

[Jesse Rhodes]

Copying the bug as I neglected to do that
-- Forwarded message --
From: "Jesse Rhodes" 
Date: 2014-02-11 6:36 PM
Subject: Re: Bug#738683: RFS: hexchat/2.9.6.1-1 [ITP]
To: "Paul Wise" 
Cc:

>
> On 2014-02-11 6:18 PM, "Paul Wise"  wrote:
> >
> > On Wed, Feb 12, 2014 at 6:43 AM, sney wrote:
> >
> > > hexchat - IRC client for X based on X-Chat 2
> >
> > If this reaches Debian please ensure that it gets added to the
> > security team's embedded-code-copies file, they track forks too.
>
> OK, noted.
>
> > What is the plan for xchat? Will it be removed in favour of hexchat?
> > Are you co-ordinating with the Debian maintainers of xchat? Why was
> > there a fork, is xchat no longer developed upstream?
> Exactly right. Xchat upstream development stalled in 2010. Furthermore,
the last update in debian was a nmu and the most recent update by the
maintainer was in 2012. I emailed the xchat maintainer quite some time ago
asking if he had any plans to replace xchat with hexchat and never received
a response. As for whether hexchat will replace xchat as a result of my
packaging it, that's up in the air - they don't use the same dotfiles or
path names so they can coexist on the same system without issues. Perhaps
popcon can make that decision.
>
> Thanks for your feedback.
>
> sney

Bug#738690: Please, keep newline in description

[David Prévot]

Package: pkg-php-tools
Version: 1.12
Severity: normal
Tags: patch
Control: affects -1 php-texy

Hi,

Since the #717340, some newlines are not kept (e.g., in php-texy). The
attached workaround fixes the issue, maybe someone will propose
something less ugly.

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 pkg-php-tools depends on:
ii  debhelper  9.20131227
ii  php-pear   5.5.9+dfsg-1
ii  php5-cli   5.5.9+dfsg-1
ii  php5-json  1.3.3-1

pkg-php-tools recommends no packages.

Versions of packages pkg-php-tools suggests:
ii  dh-make  0.63

-- no debconf information
From 1d607bfec146237f2142e2a642160787c224ad20 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?David=20Pr=C3=A9vot?= 
Date: Tue, 11 Feb 2014 21:22:38 -0400
Subject: [PATCH] dh_phppear: Keep newline in description

The tabs handling introduced in 5e34fee was a bit too overwhelming.
---
 bin/dh_phppear | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/bin/dh_phppear b/bin/dh_phppear
index 257af94..acb7beb 100755
--- a/bin/dh_phppear
+++ b/bin/dh_phppear
@@ -119,7 +119,9 @@ foreach my $package (@{$dh{DOPACKAGES}}) {
 		$summary =~ s/\.$//;
 		addsubstvar($package, "phppear:summary", $summary);
 		my $description = _shell_exec('/usr/share/pkg-php-tools/scripts/phppkginfo -d description .');
+		$description =~ s/^$/—DELETEME—/mg;
 		$description =~ s/^\s*//mg;
+		$description =~ s/—DELETEME—//mg;
 		$description =~ s/^\*/ */mg;
 		local($Text::Wrap::separator) = '${Newline}';
 		# Wrap and replace empty lines with a dot
-- 
1.9.0.rc3



signature.asc
Description: Digital signature

Bug#738642: calibre: Conversion from DOCX to MOBI fails with error in lxml

[Gary Preston]

Also confirmed on 1.22 backport in Wheezy with python-lxml 2.3.2-1. 
Working with 1.22 in Jessie with python-lxml 3.2.0-1+b1.


The python-lxml change log mentions that the doctype option was added in 
2.3.5-1 
http://metadata.ftp-master.debian.org/changelogs//main/l/lxml/lxml_3.2.0-1_changelog 



  - Features added:
  * lxml.html.tostring() gained new serialisation options
``with_tail`` and ``doctype``.

The calibre package may want to add 2.3.5-1 as a minimum dependency. 
That said, the Calibre website lists python-lxml 3.2.1 as a dependency 
http://calibre-ebook.com/download_linux but that isn't yet an option as 
3.2.0-1 is the latest available in sid/jessie that the package could 
depend on.


I'll take a look at the possibility of backporting python-lxml for 
wheezy. In addition the unstable calibre package may want a version 
dependency adding for python-lxml. Either 2.3.5-1+ or 3.2.0-1 with a 
view to matching the 3.2.1 dependency when possible (3.3 is currently in 
experimental) in case there are other incompatibilities with older 
python-lxml versions.


Gary


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

Bug#722382: stfl: diff for NMU version 0.22-1.1

[Christian Hofstaedtler]

tags 722382 + patch
thanks

Dear maintainer,

I've prepared an NMU for stfl (versioned as 0.22-1.1). The diff
is attached to this message.

As this fixes an RC bug which has shown no activity for more than
three weeks, I'm going to upload right away.

Regards.

diff -Nru stfl-0.22/debian/changelog stfl-0.22/debian/changelog
--- stfl-0.22/debian/changelog  2011-10-25 16:22:53.0 +0200
+++ stfl-0.22/debian/changelog  2014-02-12 02:07:22.0 +0100
@@ -1,3 +1,11 @@
+stfl (0.22-1.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Convert Ruby build system to dh_ruby, to build for Ruby 1.9/2.0.
+(Closes: #722382)
+
+ -- Christian Hofstaedtler   Wed, 12 Feb 2014 02:06:19 +0100
+
 stfl (0.22-1) unstable; urgency=low
 
   * New upstream version:
diff -Nru stfl-0.22/debian/control stfl-0.22/debian/control
--- stfl-0.22/debian/control2011-10-25 16:22:53.0 +0200
+++ stfl-0.22/debian/control2014-02-12 02:20:58.0 +0100
@@ -1,10 +1,11 @@
 Source: stfl
 Priority: optional
 Maintainer: Nico Golde 
-Build-Depends: debhelper (>= 7), libncursesw5-dev, swig, python-all-dev (>= 
2.6.6-3~), ruby1.8, ruby1.8-dev, ruby1.9.1, ruby1.9.1-dev, spl-dev
+Build-Depends: debhelper (>= 7), libncursesw5-dev, swig, python-all-dev (>= 
2.6.6-3~), gem2deb, spl-dev
 Standards-Version: 3.9.2
 Section: libdevel
 X-Python-Version: all
+XS-Ruby-Versions: all
 Vcs-Svn: svn://svn.debian.org/svn/collab-maint/deb-maint/stfl/trunk/
 Vcs-Browser: http://svn.debian.org/wsvn/collab-maint/deb-maint/trunk/
 Homepage: http://www.clifford.at/stfl/
@@ -51,35 +52,35 @@
  This package contains the Python bindings to libstfl.
 
 Package: libstfl-ruby1.8
-Section: ruby
+Section: oldlibs
+Priority: extra
 Architecture: any
-Depends: ruby1.8, ${shlibs:Depends}, ${misc:Depends}
+Depends: ${shlibs:Depends}, ${misc:Depends}, libstfl-ruby
 Description: Ruby 1.8 bindings for the structured terminal forms 
language/library
  stfl is a library which implements a curses-based widget set for text
  terminals.
  .
- This package contains the ruby1.8 bindings to libstfl.
+ This is a transitional package and can be safely removed.
 
 Package: libstfl-ruby1.9.1
-Section: ruby
+Section: oldlibs
+Priority: extra
 Architecture: any
-Depends: ruby1.9.1, ${shlibs:Depends}, ${misc:Depends}
+Depends: ${shlibs:Depends}, ${misc:Depends}, libstfl-ruby
 Description: Ruby 1.9.1 bindings for the structured terminal forms 
language/library
  stfl is a library which implements a curses-based widget set for text
  terminals.
  .
- This package contains the ruby1.9 bindings to libstfl.
+ This is a transitional package and can be safely removed.
 
 Package: libstfl-ruby
 Section: ruby
-Architecture: all
-Depends: libstfl-ruby1.8, ${misc:Depends}
+Architecture: any
+Depends: ${shlibs:Depends}, ${misc:Depends}, ${ruby:Depends}
+X-DhRuby-Root: ruby
 Description: Ruby bindings for the structured terminal forms language/library
  stfl is a library which implements a curses-based widget set for text
  terminals.
- .
- This is a dependency package which depends on Debian's default Ruby version
- (currently 1.8.x).
 
 Package: libstfl-spl
 Section: devel
diff -Nru stfl-0.22/debian/libstfl-ruby1.8.dirs 
stfl-0.22/debian/libstfl-ruby1.8.dirs
--- stfl-0.22/debian/libstfl-ruby1.8.dirs   2011-10-25 16:22:53.0 
+0200
+++ stfl-0.22/debian/libstfl-ruby1.8.dirs   1970-01-01 01:00:00.0 
+0100
@@ -1 +0,0 @@
-/usr/lib/ruby/1.8/x86_64-linux
diff -Nru stfl-0.22/debian/libstfl-ruby1.8.examples 
stfl-0.22/debian/libstfl-ruby1.8.examples
--- stfl-0.22/debian/libstfl-ruby1.8.examples   2011-10-25 16:22:53.0 
+0200
+++ stfl-0.22/debian/libstfl-ruby1.8.examples   1970-01-01 01:00:00.0 
+0100
@@ -1 +0,0 @@
-ruby/example.rb
diff -Nru stfl-0.22/debian/libstfl-ruby1.8.install 
stfl-0.22/debian/libstfl-ruby1.8.install
--- stfl-0.22/debian/libstfl-ruby1.8.install2011-10-25 16:22:53.0 
+0200
+++ stfl-0.22/debian/libstfl-ruby1.8.install1970-01-01 01:00:00.0 
+0100
@@ -1 +0,0 @@
-debian/tmp/usr/lib/ruby/1.8/*/stfl.so
diff -Nru stfl-0.22/debian/libstfl-ruby1.9.1.dirs 
stfl-0.22/debian/libstfl-ruby1.9.1.dirs
--- stfl-0.22/debian/libstfl-ruby1.9.1.dirs 2011-10-25 16:22:53.0 
+0200
+++ stfl-0.22/debian/libstfl-ruby1.9.1.dirs 1970-01-01 01:00:00.0 
+0100
@@ -1 +0,0 @@
-/usr/lib/ruby/1.9.1/x86_64-linux
diff -Nru stfl-0.22/debian/libstfl-ruby1.9.1.examples 
stfl-0.22/debian/libstfl-ruby1.9.1.examples
--- stfl-0.22/debian/libstfl-ruby1.9.1.examples 2011-10-25 16:22:53.0 
+0200
+++ stfl-0.22/debian/libstfl-ruby1.9.1.examples 1970-01-01 01:00:00.0 
+0100
@@ -1 +0,0 @@
-ruby/example.rb
diff -Nru stfl-0.22/debian/libstfl-ruby1.9.1.install 
stfl-0.22/debian/libstfl-ruby1.9.1.install
--- stfl-0.22/debian/libstfl-ruby1.9.1.install  2011-10-25 16:22:53.0 
+0200
+++ stfl-0.22/debian/libstfl-ruby1.9.1.install  1970-01-01 01:00:00.0 
+0100
@@ -1 +0,0 @@
-debian/tmp/usr/lib/ruby/1.9.

Bug#729203: ffmpeg alongside libav

[Timothy Gu]

On Feb 11, 2014 4:09 PM, "Antoine Beaupré" @
debian.org > wrote:
>
> On 2014-02-11 19:00:45, Timothy Gu wrote:
> > On Feb 11, 2014 10:27 AM, "Antoine Beaupré" 
@ debian.org > wrote:
> >>
> >> On 2014-02-11 13:04:53, Timothy Gu wrote:

> >> > I have also tried to build http:// 
> >> > mpv.io/ with
ffmpeg instead of
> >> > libav, and I received success in doing tthat as well. Build script is
> >> > in the gist as well.
> >>
> >> Thanks for sharing! That will certainly be useful for others.
> >
> > It should work for all applications wishing to support FFmpeg, including
> > VLC. But the PKG_CONFIG_PATH is really not optimal.
>

> That, and -rpath is designed for private libraries, so I don't think
> that could end up in the archive legitimately.

To add ffmpeg to Debian, we have four options:

1. Make both programs and libraries available as a replacement for Libav.
This would require full ABI, API, and behavior compatibility. This is the
best if compatibilities are satisfied.

2. Use RPATH to make shared build libraries and programs and static
libraries available. This is my solution for incompatible libraries. This
way, ffmpeg programs can share libraries, and users who wish to use ffmpeg
for other programs can compile the apps *themselves*, either dynamically or
statically. The inconvenience of this method is mainly that a user must
compile apps themselves.

3. Make only static libraries and programs available. This is your
solution. This has several bad consequences comparing to #2:
  - ffmpeg programs would be too big.
  - a user cannot run two copies of a program that use either Libav/FFmpeg
alongside each other.

4. Make FFmpeg the default in Debian. This is way too controversial, and if
people still want Libav to be in Debian, #2 or #3 must be used because
Libav is not trying to maintain compatibility with FFmpeg at all.

>
> A static link, on the other hand, may have a legitimate purpose.

I don't see *any* advantages over RPATH except for silencing a few lintian
warnings. People who wants to use FFmpeg libs still need to compile the app
on their own. And if the static libs are installed to std locations it
would cause more confusion as the static and shared libs in one directories
are different.

Timothy

Bug#729203: ffmpeg alongside libav

[Antoine Beaupré]

On 2014-02-11 19:25:57, Anssi Hannula wrote:
> Well, statically linking all the four ff* executables of ffmpeg would
> quadruple the total size due to duplication, and the libraries already
> take over 10MB even without that...

Point taken, patches / pull requests / git send-email welcome. :P

Note that at this point, I have lost interest in this a little since my
peculiar bug is fixed in libav 10, available in experimental. :)

A.

-- 
Pour marcher au pas d'une musique militaire, il n'y a pas besoin de
cerveau, une moelle épinière suffit.
- Albert Enstein


pgp0wqGy6I8uw.pgp
Description: PGP signature

Bug#720190: (no subject)

[Jonas Baggett]

In /etc/GNUstep/GNUstep.conf, the GNUSTEP_USER_xxx variables define were 
the GNUstep directories

have to be created. Changing them fixed the problem for me.

Jonas


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

Bug#738683: RFS: hexchat/2.9.6.1-1 [ITP]

[Paul Wise]

On Wed, Feb 12, 2014 at 6:43 AM, sney wrote:

> hexchat - IRC client for X based on X-Chat 2

If this reaches Debian please ensure that it gets added to the
security team's embedded-code-copies file, they track forks too.

http://wiki.debian.org/EmbeddedCodeCopies

What is the plan for xchat? Will it be removed in favour of hexchat?
Are you co-ordinating with the Debian maintainers of xchat? Why was
there a fork, is xchat no longer developed upstream?

-- 
bye,
pabs

http://wiki.debian.org/PaulWise


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

Bug#738689: [gnustep-base-runtime] GNUstep applications crash if LANG is set to fr_CH.UTF-8

[Jonas Baggett]

Package: gnustep-base-runtime
Version: 1.22.1-4.2+b1
Severity: normal

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

Hello,

I did today an upgrade and removed some of the gnustep packages and 
since that, when I launch one of

the GNUstep applications (gorm, ...) it crashes with this message :

Uncaught exception NSInvalidArgumentException, reason: Tried to add 
nil to array


I tried to build a hello world application in GNUstep and I get this 
errors during compilation :


pl2link: Uncaught exception NSInvalidArgumentException, reason: Tried to 
add nil to array
chmod: impossible d'accéder à 
« ./HelloWorld.app/Resources/HelloWorld.desktop »: Aucun fichier ou 
dossier de ce type


The executable was nevertheless made but launching it results in a 
segmentation fault.


It seems like I have the same problem than reported here :
http://gnustep.8.n7.nabble.com/Problem-with-gnustep-trunk-td25268.html 
and as suggested, changing
the LANG variable fixed the problem. My LANG variable is set to 
fr_CH.UTF-8 and changing it to fr_CH,
fr_FR.UTF-8 or en_US.UTF-8 fixed the problem, even if the executable was 
made with LANG=fr_CH.UTF-8.


To reproduce the problem, I guess you can launch a GNUstep applications 
with LANG=fr_CH.UTF-8


Cheers,
Jonas

--- System information. ---
Architecture: i386
Kernel: Linux 3.12-1-686-pae

Debian Release: jessie/sid
900 testing security.debian.org
900 testing ftp.ch.debian.org
300 unstable ftp.ch.debian.org

--- Package information. ---
Depends (Version) | Installed
-+-
gnustep-base-common (>= 1.22.1-4.2) | 1.22.1-4.2
libc6 (>= 2.3.6-6~) | 2.17-97
libgcc1 (>= 1:4.1.1) | 1:4.8.2-14
libgnustep-base1.22 (>= 1.22.1) | 1.22.1-4.2+b1
libobjc4 (>= 4.2.1) | 4.8.2-14
gnustep-fslayout-fhs |
lsb-base | 4.1+Debian12


Package's Recommends field is empty.

Package's Suggests field is empty.


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

Bug#738671: RFS: whatmask/1.2-1 [ITP]

[Paul Wise]

On Wed, Feb 12, 2014 at 3:08 AM, Nick Trew wrote:

> Whatmask parses CIDR (Classless Inter-Domain Routing) IP address notation
> and displays the netmask, network address, broadcast address and
> the number of usable IP addresses, including the first and last
> usable IP addresses.

That sounds like what sipcalc, ipcalc, gip, subnetcalc etc do. Does
whatmask do anything more than the existing packages already in
Debian?

-- 
bye,
pabs

http://wiki.debian.org/PaulWise


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

Bug#727708: Both T and L are wrong, plea for something simpler

[Kurt Roeckx]

On Sat, Feb 08, 2014 at 03:13:36PM -0800, Steve Langasek wrote:
> 
> package maintenance is not
> something that I believe it's in the purview of the DPL to delegate.

I have to agree with this part.  I think this is a power that
belongs to the developers.

I think that in such delegation the policy editors should be seen
as upstream, but they might happen to be the same group that does
the packaging.


Kurt


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

Bug#738687: systemd does not mount /tmp as tmpfs (even if RAMTMP=yes in rcS)

[Petr Baudis]

On Wed, Feb 12, 2014 at 01:40:48AM +0100, Michael Biebl wrote:
> We do ship a tmp.mount unit though (disabled by default), which you can
> easily enable via "systemctl enable tmp.mount"

Oh, thanks for the pointer. I did that locally now.

> I'm not sure if we should read both /etc/default/rcS and
> /etc/default/tmpfs or if the latter only would be sufficient.

FWIW, my system had the configuration only in /etc/default/rcS and
it still took effect. My /etc/default/tmpfs has just #RAMTMP=no
(commented), apparently I missed this migration. :-)

Personally, I would find the outlined solution completely satisfying.

Petr "Pasky" Baudis


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

Bug#738616: removing newer libasio-dev (v1.10) from unstable

[Andreas Beckmann]

Control: reassign -1 asio 1.10.1-1
Control: close -1 1:1.4.8-3

On 2014-02-11 22:26, Daniel Pocock wrote:
> We should mark 738613 fixed in the new version I think

Done.


Andreas


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

Bug#738687: systemd does not mount /tmp as tmpfs (even if RAMTMP=yes in rcS)

[Michael Biebl]

Hello,

Am 12.02.2014 01:06, schrieb pa...@ucw.cz:
> Dear Maintainer,
> 
> even though I have RAMTMP=yes in /etc/default/rcS, recently (~2w ago?)
> installed systemd will not mount /tmp as tmpfs.
> 
> Of course, /etc/default/rcS is not a configuration file of systemd so I
> wouldn't consider a bug that it doesn't look there. However, I believe
> that to provide smooth upgrade experience, basic system configuration
> should be preserved during a switch to systemd.

You are right, /etc/default/rcS is not a systemd configuration file and
we deliberately don't read that file.

We do ship a tmp.mount unit though (disabled by default), which you can
easily enable via "systemctl enable tmp.mount"

That said, it seems those settings are stored in /etc/default/tmpfs
nowadays, not /etc/default/rcS

> Therefore, I think systemd install scripts should configure systemd
> according to settings specified in /etc/default/rcS, or at least query
> the user in case there'd be a good reason to switch away from /tmp as
> tmpfs during an upgrade to systemd.

We could do a one-time migration of that setting in postinst, similar to
how we handle the UTC or TMPTIME configuration. This is a simple patch,
something like that

# Do a on-time migration of the RAMTMP setting
if dpkg --compare-versions "$2" lt "204-8"; then
if [ -f /etc/default/rcS ]; then
. /etc/default/rcS
fi
if [ -f /etc/default/tmpfs ]; then
. /etc/default/tmpfs
fi
if [ "$RAMTMP" = "yes" ]; then
systemctl enable tmp.mount || true
fi
fi

I deliberately use systemctl here, and not _systemctl(). "systemctl
enable" should work even if systemd is not the active PID 1

I'm not sure if we should read both /etc/default/rcS and
/etc/default/tmpfs or if the latter only would be sufficient.

Tollef, Michael, thoughts?

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



signature.asc
Description: OpenPGP digital signature

Bug#721618: Fix "schleuder" somehow

[Christian Hofstaedtler]

Hello everybody,

Please, if anyhow possible, fix schleuder so it no longer depends on
ruby-tmail or ruby-actionmailer (2.3), so we can go ahead with the
removal of ruby1.8.

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



signature.asc
Description: Digital signature

Bug#506338: gnome-terminal: Fixed-10 font is borken

[Norbert Preining]

On Di, 11 Feb 2014, althaser wrote:
> I noticed #506124 is closed.
> 
> Is this fixed Norbert ?

I have no idea. I stopped using it.

I tried now to selected Fixed-10, and that font is not even
available anymore.

So, whatever it is, it might still be there, just that I don't care
anymore. 

One learns to live with the pain inflicted upon us.

Norbert


PREINING, Norbert   http://www.preining.info
JAIST, Japan TeX Live & Debian Developer
DSA: 0x09C5B094   fp: 14DF 2E6C 0307 BE6D AD76  A9C0 D2BF 4AA3 09C5 B094



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

Bug#735427: Orphaned

[Christian Hofstaedtler]

Follow-Up info:

eruby has been orphaned since 2012-06-06, see #676347.

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



signature.asc
Description: Digital signature

Bug#729203: ffmpeg alongside libav

[Anssi Hannula]

12.02.2014 02:09, Antoine Beaupré kirjoitti:
> On 2014-02-11 19:00:45, Timothy Gu wrote:
>> On Feb 11, 2014 10:27 AM, "Antoine Beaupré"  wrote:
>>>
>>> Besides, -rpath is actually a lintian warning:
>>>
>>> http://lintian.debian.org/tags/binary-or-shlib-defines-rpath.html
>>
>> The page states that:
>>
>> The only time a binary or shared library in a Debian package should set
>> RPATH is if it is linked to private shared libraries in the same package.
>> In that case, place those private shared libraries in /usr/lib/*package*.
>>
>> That's exactly what's happening here if we'd like to add the ffmpeg
>> programs but not use the libraries for other packages. Still, shared
>> libraries are better than statically linking the ffmpeg programs.
> 
> Ah, right, I see what you mean. I guess it would be better, but I think
> it's only a marginal gain over a statically linked binary: it would
> bring some confusion over the purpose of those libraries... Would other
> packages be allowed to link against them?

Well, statically linking all the four ff* executables of ffmpeg would
quadruple the total size due to duplication, and the libraries already
take over 10MB even without that...

-- 
Anssi Hannula


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

Bug#737527: subversion: Replace GCJ by OpenJDK in Subversion JavaHL build

[James McCoy]

On Fri, Feb 07, 2014 at 12:30:43PM +0400, Vitaliy Filippov wrote:
> >>subversion build still depends on GCJ. I think OpenJDK should be
> >>used instead,
> >>because GCJ is a very outdated compiler.
> >
> >Does the use of GCJ cause any actual problems?  Is the OpenJDK jre
> >unable to load the GCJ-built modules?
> 
> No, of course not! I think you'd already know if it would :)
> 
> But why do you use GCJ given that OpenJDK is available?

Why do you request the use of OpenJDK given that GCJ is availale? :)

> Are there
> any special concerns that force svn to be built with GCJ?

Peter provided his reasoning behind using GCJ in #710498.  Seeing as
using GCJ doesn't break anything and I don't have any compelling reasons
to do otherwise, I've deferred to Peter's reasoning.

Cheers,
-- 
James
GPG Key: 4096R/331BA3DB 2011-12-05 James McCoy 


signature.asc
Description: Digital signature

Bug#738688: RM: xul-ext-zotero -- RoQA; replaced by src:zotero-standalone-build

[Andreas Beckmann]

Package: ftp.debian.org
Severity: normal

Please remove the obsolete source package xul-ext-zotero (4.0.12-1) from
sid. The binary package xul-ext-zotero is now built from
zotero-standalone-build (4.0.17-2).

Shouldn't such packages show up in the cruft report?


Andreas


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

Bug#652008: gnome-terminal: lock up after medium period with much output

[althaser]

Hey,

I tried $ find / without scrollbar and unlimited lines with
gnome-terminal-3.10.1-1. I couldn't reproduce it.

Could you please try with newer version ? or tell us a suited test ?

thanks
regards
althaser

Bug#738599: fails to decode H264: "Different bit depth between chroma and luma is not implemented"

[Antoine Beaupré]

On 2014-02-11 09:11:58, Sebastian Ramacher wrote:
> Anyway, could you please test if the issues persists with libav 10 from
> experimental?

It doesn't, I marked the issue as fixed for the experimental version.

Thanks,

A.

-- 
Rock journalism is people who can't write, interviewing people who can't
talk, in order to provide articles for people who can't read.
- Frank Zappa


pgpivREX3h4ym.pgp
Description: PGP signature

Bug#729203: ffmpeg alongside libav

[Antoine Beaupré]

On 2014-02-11 19:00:45, Timothy Gu wrote:
> On Feb 11, 2014 10:27 AM, "Antoine Beaupré"  wrote:
>>
>> On 2014-02-11 13:04:53, Timothy Gu wrote:
>> > I have experimented with the new --enable-rpath configure option of
>> > FFmpeg, and found that it is even possible to install shared libraries
>> > alongside Libav, without interrupting Libav headers, programs, or
>> > libraries. See my gist: https://gist.github.com/TimothyGu/8533059
>>
>
>> Hum... isn't that because you install in /usr/local more than -rpath?
>
> I used /usr/local because if I mess up I can delete the installation
> completely. But it should work with /usr.

Understood.

>> Besides, -rpath is actually a lintian warning:
>>
>> http://lintian.debian.org/tags/binary-or-shlib-defines-rpath.html
>
> The page states that:
>
> The only time a binary or shared library in a Debian package should set
> RPATH is if it is linked to private shared libraries in the same package.
> In that case, place those private shared libraries in /usr/lib/*package*.
>
> That's exactly what's happening here if we'd like to add the ffmpeg
> programs but not use the libraries for other packages. Still, shared
> libraries are better than statically linking the ffmpeg programs.

Ah, right, I see what you mean. I guess it would be better, but I think
it's only a marginal gain over a statically linked binary: it would
bring some confusion over the purpose of those libraries... Would other
packages be allowed to link against them?

>> ... so we shouldn't use that, generally. I would rather try to check to
>> see if we could sync the packages to make them ABI-compatible.
>
> I'd be interested in the results.

Yeah, I'm not sure I'll get into that now, but I would welcome other
brave souls stepping into this.

I was merely scratching an itch to watch that silly video after all. :)

>> > I have also tried to build http://mpv.io/ with ffmpeg instead of
>> > libav, and I received success in doing tthat as well. Build script is
>> > in the gist as well.
>>
>> Thanks for sharing! That will certainly be useful for others.
>
> It should work for all applications wishing to support FFmpeg, including
> VLC. But the PKG_CONFIG_PATH is really not optimal.

That, and -rpath is designed for private libraries, so I don't think
that could end up in the archive legitimately.

A static link, on the other hand, may have a legitimate purpose.

A.

-- 
Advertisers, not governments, are the primary censors of media content 
in the United States today.
- C. Edwin Baker


pgppGMQg632nc.pgp
Description: PGP signature

Bug#729203: ffmpeg alongside libav

[Timothy Gu]

On Feb 11, 2014 10:27 AM, "Antoine Beaupré"  wrote:
>
> On 2014-02-11 13:04:53, Timothy Gu wrote:
> > I have experimented with the new --enable-rpath configure option of
> > FFmpeg, and found that it is even possible to install shared libraries
> > alongside Libav, without interrupting Libav headers, programs, or
> > libraries. See my gist: https://gist.github.com/TimothyGu/8533059
>

> Hum... isn't that because you install in /usr/local more than -rpath?

I used /usr/local because if I mess up I can delete the installation
completely. But it should work with /usr.

>
> Besides, -rpath is actually a lintian warning:
>
> http://lintian.debian.org/tags/binary-or-shlib-defines-rpath.html

The page states that:

The only time a binary or shared library in a Debian package should set
RPATH is if it is linked to private shared libraries in the same package.
In that case, place those private shared libraries in /usr/lib/*package*.

That's exactly what's happening here if we'd like to add the ffmpeg
programs but not use the libraries for other packages. Still, shared
libraries are better than statically linking the ffmpeg programs.

>
> ... so we shouldn't use that, generally. I would rather try to check to
> see if we could sync the packages to make them ABI-compatible.

I'd be interested in the results.

>
> > I have also tried to build http://mpv.io/ with ffmpeg instead of
> > libav, and I received success in doing tthat as well. Build script is
> > in the gist as well.
>
> Thanks for sharing! That will certainly be useful for others.

It should work for all applications wishing to support FFmpeg, including
VLC. But the PKG_CONFIG_PATH is really not optimal.

Timothy

Bug#738610: maven: Can't run mvn due to some bad java library dependency

[Rudy Godoy]

Package: maven
Version: 3.0.5-1
Followup-For: Bug #738610

I'm experiencing the same problem since I've upgraded my system's
packages last Monday.

thanks

-- 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/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 maven depends on:
ii  default-jre [java5-runtime]  2:1.7-51
ii  default-jre-headless [java5-runtime-headless]2:1.7-51
ii  libaether-java   1.13.1-2
ii  libcommons-cli-java  1.2-3
ii  libcommons-codec-java1.9-1
ii  libcommons-httpclient-java   3.1-10.2
ii  libcommons-logging-java  1.1.3-1
ii  libguava-java15.0-2
ii  libplexus-cipher-java1.5-4
ii  libplexus-classworlds2-java  2.5.1-2
ii  libplexus-containers1.5-java 1.5.5-6
ii  libplexus-interpolation-java 1.19-1
ii  libplexus-sec-dispatcher-java1.3.1-6
ii  libplexus-utils2-java2.0.5-1
ii  libsisu-guice-java   3.1.9+dfsg-1
ii  libsisu-ioc-java 2.3.0-4
ii  libwagon2-java   2.5-1
ii  openjdk-6-jre [java5-runtime]6b30-1.13.1-1
ii  openjdk-6-jre-headless [java5-runtime-headless]  6b30-1.13.1-1
ii  openjdk-7-jre [java5-runtime]7u51-2.4.5-2
ii  openjdk-7-jre-headless [java5-runtime-headless]  7u51-2.4.5-2

maven recommends no packages.

maven 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#590774: #590774,ITA: robocode -- Java programming game based on battle tanks

[Julian Göstl]

Because there isn't any work on this package for a long time I adopted it.

Best Regards
Julian Goestl


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

Bug#624122: hash sums mismatch

[David Kalnischkies]

On Wed, Feb 12, 2014 at 12:28:27AM +0100, Martin Ziegler wrote:
> Yes, I had
> 
>  APT::Get::List-Cleanup "false";
> 
> since a long time. But the problems started only two weeks ago.

Yes and ~2 weeks ago the new rred code entered unstable.
So it seems to be exactly what I thought.

Obvious question: Why do you have it disabled?
(just interested in the usecase)


> There are two strange things which have happend in the last two or
> three weeks
> 
> * apt-get does not longer remove pdiff-files from
>   /var/lib/apt/lists (this is new)

Actually, this isn't new. You had them lying around in the old code too
with no list-cleanup, just that it was just one "foobar.ed" file, so it
got overridden all the time …

> * apt-get reacts on stale pdiff-files in  /var/lib/apt/lists
>   with hash sum mismatch errors (this seems to be a mistake)

… but now we operate on multiple files at once, so they get a unique
name and are picked up by rred later on based on that name.
What should happen is that those files are removed after they there
used which is happening with the default configuration at the moment,
but not with list-cleanup disabled.

So, the next time you run the update rred will pick up the new as well
as the old patches and together they result in a file which isn't
correct anymore as it was patched with some patches two times… BOOM!


Best regards

David Kalnischkies
commit 34d6ece7566ea4fcda2286478b31641378aefc93
Author: David Kalnischkies 
Date:   Mon Feb 10 17:55:13 2014 +0100

always cleanup patchfiles at the end of rred call

With APT::Get::List-Cleanup disabled the ed-style patch files are
lingering in the lists/ directory otherwise. That was kinda okay in the
old none-client-merge as the filename was always the same so it was
constantly overridden, but now with different names for client-merge
quiet a few could pill up on the system and are used by the next call
as it picks them up based on the filename.

diff --git a/apt-pkg/acquire-item.cc b/apt-pkg/acquire-item.cc
index 1185908..60003c0 100644
--- a/apt-pkg/acquire-item.cc
+++ b/apt-pkg/acquire-item.cc
@@ -757,6 +757,7 @@ void pkgAcqIndexDiffs::Done(string Message,unsigned long long Size,string Md5Has
{
   // remove the just applied patch
   available_patches.erase(available_patches.begin());
+  unlink((FinalFile + ".ed").c_str());
 
   // move into place
   if(Debug) 
@@ -887,6 +888,14 @@ void pkgAcqIndexMergeDiffs::Done(string Message,unsigned long long Size,string M
   // otherwise lists cleanup will eat the file
   DestFile = FinalFile;
 
+  // ensure the ed's are gone regardless of list-cleanup
+  for (std::vector::const_iterator I = allPatches->begin();
+	I != allPatches->end(); ++I)
+  {
+	std::string patch = FinalFile + ".ed." + (*I)->patch.file + ".gz";
+	unlink(patch.c_str());
+  }
+
   // all set and done
   Complete = true;
   if(Debug)
diff --git a/test/integration/test-pdiff-usage b/test/integration/test-pdiff-usage
index ad31511..afe1ad4 100755
--- a/test/integration/test-pdiff-usage
+++ b/test/integration/test-pdiff-usage
@@ -31,6 +31,16 @@ wasmergeused() {
 		msgfail
 	fi
 
+	msgtest 'No intermediate patch files' 'still exist'
+	local EDS="$(find rootdir/var/lib/apt/lists -name '*.ed' -o -name '*.ed.*')"
+	if [ -z "$EDS" ]; then
+		msgpass
+	else
+		echo
+		echo "$EDS"
+		msgfail
+	fi
+
 	msgtest 'Check if the right pdiff merger was used'
 	if grep -q '^pkgAcqIndexMergeDiffs::Done(): rred' $OUTPUT; then
 		if echo "$*" | grep -q -- '-o Acquire::PDiffs::Merge=1'; then
@@ -46,7 +56,7 @@ wasmergeused() {
 }
 
 testrun() {
-	# setup the base
+	msgmsg "Testcase: setup the base with: $*"
 	find aptarchive -name 'Packages*' -type f -delete
 	cp ${PKGFILE} aptarchive/Packages
 	compressfile 'aptarchive/Packages'
@@ -59,7 +69,7 @@ testrun() {
 	testequal "$(cat ${PKGFILE})
 " aptcache show apt oldstuff
 
-	msgmsg 'Testcase: apply with one patch'
+	msgmsg "Testcase: apply with one patch: $*"
 	cp ${PKGFILE}-new aptarchive/Packages
 	compressfile 'aptarchive/Packages'
 	mkdir -p aptarchive/Packages.diff
@@ -82,13 +92,13 @@ SHA1-Patches:
 	testequal "$(cat ${PKGFILE}-new)
 " aptcache show apt newstuff
 
-	msgmsg 'Testcase: index is already up-to-date'
+	msgmsg "Testcase: index is already up-to-date: $*"
 	find rootdir/var/lib/apt/lists -name '*.IndexDiff' -type f -delete
 	testsuccess aptget update "$@"
 	testequal "$(cat ${PKGFILE}-new)
 " aptcache show apt newstuff
 
-	msgmsg 'Testcase: apply with two patches'
+	msgmsg "Testcase: apply with two patches: $*"
 	cp ${PKGFILE}-new aptarchive/Packages
 	echo '
 Package: futurestuff
@@ -129,7 +139,7 @@ SHA1-Patches:
 	testequal "$(cat Packages-future)
 " aptcache show apt newstuff futurestuff
 
-	msgmsg 'Testcase: patch applying fails, but successful fallback'
+	msgmsg "Testcase: patch applying fails, but successful fallback: $*"
 	rm -rf rootdir/var/lib/apt/lists
 	cp -a rootdir/var/lib/apt/

Bug#724222: Build patch

[Simone Vellei]

Here attached a patch that solve the bug.

Simone

-- 
Simone Vellei (henomis)

GPG KEYID: A3D37CF4
GPG FINGERPRINT: 5A79 3A3A 143E 9B37 9B38  FB86 8E45 8B62 A3D3 7CF4
diff -Naur a/Makefile b/Makefile
--- a/Makefile	2010-08-29 01:21:38.0 +0200
+++ b/Makefile	2014-02-12 00:25:40.991539099 +0100
@@ -66,5 +66,5 @@
 		| gzip --best > ../witalian-$(VER).tar.gz
 
 .PHONY: check
-check: build
+check: all
 	test -f $(LANG)

Bug#624122: hash sums mismatch

[Martin Ziegler]

Yes, I had

 APT::Get::List-Cleanup "false";

since a long time. But the problems started only two weeks 
ago.



There are two strange things which have happend in the last 
two or three weeks


* apt-get does not longer remove pdiff-files from
  /var/lib/apt/lists (this is new)

* apt-get reacts on stale pdiff-files in  /var/lib/apt/lists
  with hash sum mismatch errors (this seems to be a mistake)

These look like two unrelated things which together let 
apt-get fail. On the other hand, "rm 
/var/lib/apt/lists/*.gz"  before "apt-get" is an easy 
workaround


I am happy to supply more information.

Regards

Martin


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

Bug#738686: rsyslog-pgsql: Using imklog+ompgsql causes 100% CPU usage

[Christian Kastner]

Package: rsyslog-pgsql
Version: 7.4.4-1
Severity: important

Using a combination of imklog and ompgsql results in a 100% CPU load as
soon as something gets written to the kernel log. Furthermore, the
following message is continuously spammed to kern.*:

rsyslogd: imklog: error reading kernel log - shutting down: Bad file 
descriptor

I can successfully reproduce this problem by running rsyslogd with the
attached minimal config (just imuxsock+imklog+ompgsql), and then
triggering a write to the kernel log, in my case by plugging in a USB stick.

I initially noticed this with the backported package in wheezy, and I
assumed it had something to do with the backport. I was wrong, though,
as I can reproduce this issue here on jessie as well.

On wheezy, this problem does not occur with rsyslog v5.8.11 (both with
the default 3.2 kernel and the backported 3.12).

I don't know why it should make a difference, but in any case: the
Postgres database I'm connecting to with  ompgsql is connecting to is
a remote one (TCP).

Christian

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

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

Versions of packages rsyslog-pgsql depends on:
ii  dbconfig-common1.8.47+nmu1
ii  debconf [debconf-2.0]  1.5.52
ii  libc6  2.17-97
ii  libpq5 9.3.2-1
ii  rsyslog7.4.4-1
ii  ucf3.0027+nmu1

Versions of packages rsyslog-pgsql recommends:
ii  postgresql-client  9.3+152
ii  postgresql-client-9.3 [postgresql-client]  9.3.2-1

Versions of packages rsyslog-pgsql suggests:
pn  postgresql  

-- debconf information:
  rsyslog-pgsql/missing-db-package-error: abort
  rsyslog-pgsql/db/app-user: rsyslog
  rsyslog-pgsql/internal/skip-preseed: true
  rsyslog-pgsql/pgsql/authmethod-admin: ident
  rsyslog-pgsql/upgrade-error: abort
  rsyslog-pgsql/pgsql/authmethod-user:
  rsyslog-pgsql/pgsql/method: unix socket
  rsyslog-pgsql/upgrade-backup: true
  rsyslog-pgsql/passwords-do-not-match:
  rsyslog-pgsql/pgsql/manualconf:
  rsyslog-pgsql/install-error: abort
  rsyslog-pgsql/pgsql/changeconf: false
  rsyslog-pgsql/db/dbname: Syslog
* rsyslog-pgsql/dbconfig-install: false
  rsyslog-pgsql/remove-error: abort
  rsyslog-pgsql/remote/newhost:
  rsyslog-pgsql/pgsql/admin-user: postgres
  rsyslog-pgsql/dbconfig-reinstall: false
  rsyslog-pgsql/pgsql/no-empty-passwords:
  rsyslog-pgsql/internal/reconfiguring: false
  rsyslog-pgsql/dbconfig-upgrade: true
  rsyslog-pgsql/dbconfig-remove:
  rsyslog-pgsql/purge: false
  rsyslog-pgsql/database-type: pgsql
  rsyslog-pgsql/remote/host:
  rsyslog-pgsql/remote/port:
$ModLoad imuxsock
$ModLoad imklog

*.*;kern.none   /tmp/kern.none.log
# "Bad file descriptor" messages get spammed to this
kern.*  /tmp/kern.log

$ModLoad ompgsql
*.* :ompgsql:HOST,USER,DB,PASS

Bug#604287: Control/Alt key maps not updated when changing keyboard layout

[althaser]

Hey,

Could you please try to reproduce this issue with newer version
like 3.4.1.1-2 or 3.10.1-1 ?

thanks
regards
althaser

Bug#738685: weechat: Please Build-Depend on ruby-all-dev or gem2deb

[Christian Hofstaedtler]

Source: weechat
Severity: normal

Dear Maintainer,

Your package currently Build-Depends on ruby1.9.1, ruby1.9.1-dev. 
Please Build-Depend on ruby-all-dev or gem2deb instead.

Reasoning: ruby1.9.1 will be removed soon. By build-depending on the
metapackages, switching to a new Ruby version should only require an
binNMU.

Difference between ruby-all-dev and gem2deb:
gem2deb itself depends on ruby-all-dev (*), but gives you
  dh_ruby --print-supported
... which prints the list of all "current" Ruby versions.
This is useful if you want to build for all versions, thereby
minimizing breakage when the versions are switched.

Thank you,
Christian


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

Bug#737376: texlive-extra-utils: Debian pythontex can't use python3

[Norbert Preining]

Hi Julian,

>   python3 /usr/share/texlive/texmf-dist/scripts/pythontex/pythontex3.py \
> --interpreter python:python3 "$@"

Ok, changed the script.

Will rebuild later on with checkout from CTAN of today.

Is the same needed for depythontex3? I guess no?

Norbert


PREINING, Norbert   http://www.preining.info
JAIST, Japan TeX Live & Debian Developer
DSA: 0x09C5B094   fp: 14DF 2E6C 0307 BE6D AD76  A9C0 D2BF 4AA3 09C5 B094



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

Bug#738684: jack-audio-connection-kit: Patch to bootstrap without libffado

[Daniel Schepler]

Source: jack-audio-connection-kit
Version: 1:0.124.1+20140122git5013bed0-2
Severity: wishlist
Tags: patch

As the subject says: the attached patch adds a bootstrap build to
allow the package to build without libffado-dev available yet.  This
was the point I chose to break the following Build-Depends cycle:
jack-audio-connection-kit Build-Depends on libffado-dev (on Linux
builds); libffado Build-Depends on python-qt4; python-qt4
Build-Depends on libphonon-dev; phonon Build-Depends on libpulse-dev;
and pulseaudio Build-Depends on libjack-dev.
-- 
Daniel Schepler
diff -urN 
jack-audio-connection-kit-0.121.3+20120418git75e3e20b.old/debian/rules 
jack-audio-connection-kit-0.121.3+20120418git75e3e20b/debian/rules
--- jack-audio-connection-kit-0.121.3+20120418git75e3e20b.old/debian/rules  
2012-02-21 15:26:11.0 -0800
+++ jack-audio-connection-kit-0.121.3+20120418git75e3e20b/debian/rules  
2013-07-14 17:17:27.993092982 -0700
@@ -15,6 +15,10 @@
 DEB_AUTO_UPDATE_ACLOCAL = 1.11
 DEB_AUTO_UPDATE_AUTOMAKE = 1.11
 
+ifneq (,$(filter stage1,$(DEB_BUILD_PROFILES)))
+export DH_OPTIONS = -Njackd1-firewire
+endif
+
 include /usr/share/cdbs/1/class/autotools.mk
 include /usr/share/cdbs/1/rules/debhelper.mk
 -include /usr/share/cdbs/1/rules/upstream-tarball.mk

Bug#738583: libcglib-java - Uses jarjar without proper copyright or Built-Using

[Emmanuel Bourg]

Le 11/02/2014 21:22, Bastian Blank a écrit :

> Have you talked to the security team about this?  Where does Debian ship
> different versions of asm?

Debian has four versions of asm. Each version is incompatible with the
previous one, and they share the same namespace (org.objectweb.asm.*).
That means two versions can't coexist safely in the same classpath, this
is guaranteed to break at runtime. That's why widely used libraries like
cglib relocate the asm classes under a different namespace to avoid
conflicts (net.sf.cglib.asm.*).

I'm not sure to see why the security team would care about this though.

Emmanuel Bourg


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

Bug#737376: texlive-extra-utils: Debian pythontex can't use python3

[Julian Gilbey]

On Wed, Feb 12, 2014 at 07:33:01AM +0900, Norbert Preining wrote:
> > Much more interesting would be if the /usr/bin/pythontex3 were to
> > include the argument --interpreter python:python3 before "$@", for
> 
> Did you see the scripts I have added to the texlive-extra tree
> and that will be installed?
>   texlive-nonbin.git/texlive-extra-debian/pythontex3
> is nothing else but:
> if which python3 >/dev/null 2>&1
> then
>   python3 /usr/share/texlive/texmf-dist/scripts/pythontex/pythontex3.py "$@"
> else
>   echo "You need to have python3 installed to be able to use" >&2
>   echo "the Python 3 version of pythontex!" >&2
>   echo "Exiting." >&2
> fi
> 
> That is why I wrote in the last email that I used your script, but changed
> the exec to a call to python3 ...

Indeed.  I wrote that script before I understood what pythontex3 did.
Geoffrey wrote to me (but forgot to copy in the bug report):

>> Julian,
>> 
>> In the latest beta relase, I've modified the hashbangs in
>> `pythontex2.py` and `pythontex3.py` to `env python2` and `env
>> python3`.  If no bugs are found in the next several days, I will
>> release to CTAN and then it will be available for TeX Live.
>> 
>> One thing I forgot to mention.  The version of Python that launches
>> PythonTeX is primarily used to manage/oversee code execution...and
>> this version doesn't really matter (except for highlighting and
>> console emulation).  The version of Python that is actually used to
>> run user code from the document is determined by what `python` gives
>> on the command line.  This can be customized with the `--interpreter`
>> option.  For example, `pythontex --interpreter python:python3
>> file.tex` would call the temporary scripts that PythonTeX uses with
>> `python3 `.
>> 
>> Geoff

So...

> That should suffice, though, right?

So in its current form it doesn't actually achieve anything of value.
But changing the call to read:

  python3 /usr/share/texlive/texmf-dist/scripts/pythontex/pythontex3.py \
--interpreter python:python3 "$@"

would actually make it do what people would expect, which is to use
python3 to process the code in the LaTeX document.

   Julian


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

Bug#506338: gnome-terminal: Fixed-10 font is borken

[althaser]

Hey,

I noticed #506124 is closed.

Is this fixed Norbert ?

thanks
regards
althaser

Bug#738683: RFS: hexchat/2.9.6.1-1 [ITP]

[sney]

Package: sponsorship-requests
Severity: wishlist

Dear mentors,

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

   Package name : hexchat
   Version  : 2.9.6.1-1
   Upstream Author  : Berke Viktor
   URL  : http://hexchat.github.io
   License  : GPL-2 with OpenSSL exception
   Section  : net

It builds these binary packages:
hexchat - IRC client for X based on X-Chat 2
hexchat-common  - Common files for HexChat

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

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

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

dget -x
http://mentors.debian.net/debian/pool/main/h/hexchat/hexchat_2.9.6.1-1.dsc

More information about HexChat can be obtained from http://hexchat.github.io/
and http://hexchat.readthedocs.org/.

Please let me know if you need any more information.

Regards,
Jesse Rhodes (sney)



-- System Information:
Debian Release: jessie/sid
  APT prefers unstable
  APT policy: (990, 'unstable'), (1, 'experimental')
Architecture: i386 (x86_64)

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


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

Bug#737376: texlive-extra-utils: Debian pythontex can't use python3

[Norbert Preining]

Hi Julian,

> After numerous failed attempts to clone the git repository (alioth
> keeps dropping https connections :-( ) I finally gave up and looked at

Huu? Strange.

> I hadn't realised, but it's now been explained, that the
> (de)pythontex3.py scripts are just Python 3 "translations" of the
> (de)pythontex2.py scripts and they behave identically otherwise.  So
> it is almost pointless having the /usr/bin/(de)pythontex3 scripts, as

No.

> Much more interesting would be if the /usr/bin/pythontex3 were to
> include the argument --interpreter python:python3 before "$@", for

Did you see the scripts I have added to the texlive-extra tree
and that will be installed?
texlive-nonbin.git/texlive-extra-debian/pythontex3
is nothing else but:
if which python3 >/dev/null 2>&1
then
  python3 /usr/share/texlive/texmf-dist/scripts/pythontex/pythontex3.py "$@"
else
  echo "You need to have python3 installed to be able to use" >&2
  echo "the Python 3 version of pythontex!" >&2
  echo "Exiting." >&2
fi

That is why I wrote in the last email that I used your script, but changed
the exec to a call to python3 ...

That should suffice, though, right?

Norbert


PREINING, Norbert   http://www.preining.info
JAIST, Japan TeX Live & Debian Developer
DSA: 0x09C5B094   fp: 14DF 2E6C 0307 BE6D AD76  A9C0 D2BF 4AA3 09C5 B094



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

Bug#478478: gnome-terminal: copy/paste using the middle mouse button is broken.

[althaser]

Hey,

Could you try to reproduce this issue with newer version of gnome-terminal
like 3.4.1.1-2 or 3.10.1-1 ?

thanks
regards
althaser

Bug#692984: upstream binary / DAViCal / CardDAV problems on wheezy

[Carsten Schoenert]

Hello Daniel,

I imported the latest upstream version 24 of the sogo-connector and
rebuild the package. The current output of git-buildpackage will be
found on the links I posted earlier.

On Sat, Aug 31, 2013 at 05:36:18PM +0200, Daniel Pocock wrote:
> I found the solution to my problem using the connector
> 
> I can confirm that both the TB10 and TB17 connectors from upstream work
> with the respective icedove versions in wheezy against a DAViCal server
> on wheezy.
> 
> The reason it didn't work for me in the beginning is because the default
> config in DAViCal is for a calendar-only resource.
> 
> Somehow, Evolution was able to use the calendar-only resource to store
> vCards: that seems like a bug in both DAViCal and Evolution, they
> shouldn't allow that.  However, that left me thinking there was
> something wrong with the SOGo Connector because it couldn't see the
> contacts the Evolution could create and retrieve.
> 
> When I started looking around in the DAViCal settings, I realised I had
> to create another resource for my address book and DAViCal creates a
> different URL for that.  I put that new address book URL in the SOGo
> Connector and it is working.

I plan to write a wiki page if the package is once available thrue the
repositorys. Your summary above would be good to place then there.

> It would be useful if the connector could give users a helpful error if
> they misconfigure it like that, I had no useful error to help me and I
> was just guessing what was wrong.

Sadly true, maybe I can talk about that with Jeroen in the near future.

> One minor problem left, Icedove address book only allows up to 2 email
> addresses per contact but Evolution and Android allow more than 2.  It
> is not clear to me whether changing those contacts in Icedove's address
> book will result in the loss of the extra email addresses when they sync.

I don't believe Mozilla will work on such "minor" issues. We can be
happy if Mozilla is making some housekeeping inside the code and
implements some more core requirements like the TLS 1.2 implementation
in the near past.
We will see. :)

Regards
Carsten


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

Bug#448807: gnome-terminal memory management

[althaser]

Hey,

Could you please try to reproduce this issue with newer version
like 3.10.1-1 ?

thanks
althaser

Bug#738671: RFS: whatmask/1.2-1 [ITP]

[Nick Trew]

Hi Daniel,

Thank you for the kind words and for pointing out those lintian warnings -
I'll investigate and look at resolving them.

Thanks also for the watch file - I'll see if I can make any changes and
will incorporate that into the package :-)

Regards,
Nick
On 11 Feb 2014 21:37, "Daniel Lintott"  wrote:

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> Hi Nick,
>
> Disclaimer: I'm not a DD, so can't upload your package but have looked
> at it, as it is of interest to me.
>
> Generally the package seems to be in very good shape and builds in a
> clean chroot fine.
>
> Just touching on the couple of lintian warnings:
>
> > X: whatmask source: deprecated-configure-filename
>
> I would forward this to upstream for their attention [1]
>
> > I: whatmask source: debian-watch-file-is-missing
>
> I have attached a watch file that seems to work okay (other watch file
> guru's may be able to optimise it). As upstream sign their releases,
> you can get uscan to check [2] this as well. I have included the line
> to check this in the watch file (again, it might not be perfect)
>
> The releases have been signed with key ID: E8882FE3
>
> > I: whatmask: spelling-error-in-binary usr/bin/whatmask GNU PUBLIC
> > LICENSE GNU General Public License
>
> This will be easy enough to patch and again forward upstream. The
> error appears in usage.c:60
>
> Hope this review is helpful for you and aids you in finding a sponsor.
>
> [1] http://lintian.debian.org/tags/deprecated-configure-filename.html
> [2]
> https://wiki.debian.org/debian/watch/#Cryptographic_signature_verification
> -BEGIN PGP SIGNATURE-
> Version: GnuPG v1.4.11 (GNU/Linux)
> Comment: Using GnuPG with undefined - http://www.enigmail.net/
>
> iQEcBAEBAgAGBQJS+pgdAAoJEMw/9yOWzAkJg4AH/RiyxLX1IvkOCHGqfnAyhoED
> cLNI6BUp6TXHqa11//nySvrSoHrIhBgY+ZJvO+d1WmoUzMI0MShcTC91mUYKgOIi
> 2zJDOK9PapwK3e7PJGHnIJP9jGykD2OaeEvCIC4LMp2OeAw1sE5K1z2tBDHxCDHL
> ll6JU7pQsRPFBB/UpuaRvCUScyj+VVLbE1uX1XsK3TivI2naKOeQtuH/pKKiJcz+
> VFrNLx6TZFPQe3v96e+RK+yUnwdNjTEaurXPKyiV/Rbk/bEvDIY5CWPQZNGWzZ0c
> 3P0CdQNF2Ci8kxaGTDyR1+1cza4GwRS9iFlqXZ/BSby92y3zzYZ4EpQD0//UDC8=
> =OtT3
> -END PGP SIGNATURE-
>

Bug#683732: new upstream (2.4.39)

[Daniel Baumann]

retitle 683732 new upstream (2.4.39)
thanks

it would be nice if you could upgrade to the current stable release
(2.4.39 currently).

-- 
Address:Daniel Baumann, Donnerbuehlweg 3, CH-3012 Bern
Email:  daniel.baum...@progress-technologies.net
Internet:   http://people.progress-technologies.net/~daniel.baumann/


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

Bug#727534: security-tracker: Add tabular view listing all CVEs and version table for a source package

[Antonio Terceiro]

Control: tag -1 + patch

On Tue, Feb 11, 2014 at 04:00:45PM -0300, Antonio Terceiro wrote:
> On Sat, Feb 08, 2014 at 11:31:27AM +0100, Salvatore Bonaccorso wrote:
> > Hi Antonio,
> > 
> > On Thu, Oct 24, 2013 at 09:49:19AM -0300, Antonio Terceiro wrote:
> > > It would be nice if someone familiar with the codebase could write up
> > > instructions on how to do that.
> > 
> > Actually at the Security Team meeting we are working now on this.
> > Mainly if you want to set up a testinstance of the security tracker is
> > doing the three steps:
> > 
> > make update-packages
> > make all
> > make serve
> 
> that worked just fine, thanks! :-)

now the patches :-)

the first one just sets some whitespace right in bin/tracker_service.py,
and the second one is the actual implementation of a "Vulnerability
summary" for a given source package.

-- 
Antonio Terceiro 
From d3ac0a9682ebc1538a083fb92c5b7101a53646ca Mon Sep 17 00:00:00 2001
From: Antonio Terceiro 
Date: Tue, 11 Feb 2014 16:13:44 -0300
Subject: [PATCH 1/2] tracker_service: remove spurious whitespace

---
 bin/tracker_service.py | 12 +++-
 1 file changed, 7 insertions(+), 5 deletions(-)

diff --git a/bin/tracker_service.py b/bin/tracker_service.py
index 455ea9b..c0879a0 100644
--- a/bin/tracker_service.py
+++ b/bin/tracker_service.py
@@ -93,7 +93,8 @@ h3 { font-size : 100%; }
 
 table { padding-left : 1.5em }
 td, th { text-align : left;
-	 padding-left : 0.25em;
+ padding-left : 0.25em;
+ padding-left : 0.25em;
  padding-right : 0.25em; }
 td { vertical-align: baseline }
 span.red { color: red; }
@@ -1174,9 +1175,9 @@ Debian bug number.'''),
  "Testing Security Team"),
 " - ", A(url.absolute("http://www.debian.org/security/";),
  "Debian Security"),
-		" - ", A(url.absolute("http://anonscm.debian.org/viewvc/secure-testing/bin/tracker_service.py?view=markup";),
-		 "Source"),
-		" ", A(url.absolute("svn://anonscm.debian.org/secure-testing"), "(SVN)"),
+" - ", A(url.absolute("http://anonscm.debian.org/viewvc/secure-testing/bin/tracker_service.py?view=markup";),
+ "Source"),
+" ", A(url.absolute("svn://anonscm.debian.org/secure-testing"), "(SVN)"),
 ))
 if search_in_page:
 on_load = "selectSearch()"
@@ -1324,7 +1325,8 @@ Debian bug number.'''),
 return SPAN(contents, _class="red")
 
 def make_purple(self, contents):
-	return SPAN(contents, _class="purple")
+return SPAN(contents, _class="purple")
+return SPAN(contents, _class="purple")
 
 def make_dangerous(self, contents):
 return SPAN(contents, _class="dangerous")
-- 
1.9.0.rc3

From 8d31c637e78a9c224426e2baef5a7d094a6857c0 Mon Sep 17 00:00:00 2001
From: Antonio Terceiro 
Date: Tue, 11 Feb 2014 18:55:27 -0300
Subject: [PATCH 2/2] Vulnerabitily summary for packages

---
 bin/tracker_service.py | 43 +++
 1 file changed, 43 insertions(+)

diff --git a/bin/tracker_service.py b/bin/tracker_service.py
index c0879a0..5df25ba 100644
--- a/bin/tracker_service.py
+++ b/bin/tracker_service.py
@@ -99,6 +99,7 @@ td, th { text-align : left;
 td { vertical-align: baseline }
 span.red { color: red; }
 span.purple { color: purple; }
+span.green { color: green; }
 span.dangerous { color: rgb(191,127,0); }
 """), SCRIPT('''var old_query_value = "";
 
@@ -546,6 +547,34 @@ to improve our documentation and procedures, so feedback is welcome.""")])])
 for (bug, description) in lst:
 yield self.make_xref(url, bug), description
 
+suites = ()
+for (releases, version) in self.db.getSourcePackageVersions(
+self.db.cursor(), pkg):
+for r in releases:
+if r not in suites:
+suites = suites + (r,)
+
+def gen_summary(bugs):
+for (bug, description) in bugs:
+status = {}
+for (package, releases, version, vulnerable) \
+in self.db.getSourcePackages(self.db.cursor(), bug):
+for release in releases:
+if package == pkg:
+if vulnerable == 1:
+status[release] = self.make_red('vulnerable')
+elif vulnerable == 2:
+status[release] = self.make_purple('undetermined')
+else:
+status[release] = self.make_green('fixed')
+status_row = ()
+for release in suites:
+if release in status:
+status_row = status_row + (status[release],)
+else:
+status_row = status_row + (self.make_purple('unknown'),)
+yield (self.make_xref(url

Bug#737376: texlive-extra-utils: Debian pythontex can't use python3

[Julian Gilbey]

On Mon, Feb 10, 2014 at 08:33:21AM +0900, Norbert Preining wrote:
> tags 737376 + pending
> thanks
> 
> On So, 02 Feb 2014, Julian Gilbey wrote:
> > Create a copy of pythontex.py in
> > /usr/share/texlive/texmf-dist/scripts/pythontex, called say
> > pythontex3-init.py (pythontex3.py is already used), which has the
> > first line
> 
> THere is already a script pythontex3.py in the directory, but it
> still is called with evn python.
> 
> I have installed changes to the packaging that we instead install
> a script for (de)pythontex3 that warns if python3 is not available,
> otherwise runs the script with
>   python3 
> (yours had exec ...)
> 
> I hope that fits you? See git 914322d3f in texlive-nonbin repo

Thanks, Norbert!

After numerous failed attempts to clone the git repository (alioth
keeps dropping https connections :-( ) I finally gave up and looked at
the online version ;-)

I hadn't realised, but it's now been explained, that the
(de)pythontex3.py scripts are just Python 3 "translations" of the
(de)pythontex2.py scripts and they behave identically otherwise.  So
it is almost pointless having the /usr/bin/(de)pythontex3 scripts, as
they achieve nothing unless someone uninstalls all of their python2.x
packages and python-minimal and is left with only /usr/bin/python3 on
their system.  (This is unlikely to happen.)  And in that case,
/usr/bin/pythontex will fail, but /usr/bin/pythontex3 will succeed.
It's unlikely to be a real use-case.

Much more interesting would be if the /usr/bin/pythontex3 were to
include the argument --interpreter python:python3 before "$@", for
that way, the python interpreter used for the embedded python code
would be python3 rather than python=python2.  In that way,
/usr/bin/pythontex3 would actually have value.  There is no similar
argument for depythontex, so depythontex3 would be there for parallel
but has no significant use beyond it.

:-)

   Julian


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

Bug#738682: xserver-xorg-video-radeon: module ABI major version (14) doesn't match the server's version (15)

[Les Schaffer]

Package: xserver-xorg-video-radeon
Version: 1:7.3.0-1+b1
Severity: grave
Justification: renders package unusable

it appears that xserver-xorg-video-ati is compiled for the correct ABI, but
xserver-xorg-video-radeon is not, see attached snip of Xorg.0.log



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

lrwxrwxrwx 1 root root 13 Oct  2  2009 /etc/X11/X -> /usr/bin/Xorg
-rwxr-xr-x 1 root root 2323424 Feb  6 10:23 /usr/bin/Xorg

VGA-compatible devices on PCI bus:
--
05:00.0 VGA compatible controller [0300]: Advanced Micro Devices, Inc.
[AMD/ATI] RV710 [Radeon HD 4350/4550] [1002:954f]

Xorg X server configuration file status:

lrwxrwxrwx 1 root root 16 Nov  7 21:18 /etc/X11/xorg.conf -> xorg.conf.radeon

Contents of /etc/X11/xorg.conf:
---
# xorg.conf (X.Org X Window System server configuration file)
#
# This file was generated by dexconf, the Debian X Configuration tool, using
# values from the debconf database.
#
# Edit this file with caution, and see the xorg.conf manual page.
# (Type "man xorg.conf" at the shell prompt.)
#
# This file is automatically updated on xserver-xorg package upgrades *only*
# if it has not been modified since the last upgrade of the xserver-xorg
# package.
#
# If you have edited this file but would like it to be automatically updated
# again, run the following command:
#   sudo dpkg-reconfigure -phigh xserver-xorg

Section "ServerLayout"
Identifier  "Radeon"
Screen0   "DVI Screen"  0 0
Screen  "VGA Screen"  RightOf "DVI Screen"
InputDevice "Generic Keyboard"
InputDevice "Configured Mouse"
Option  "AIGLX"  "true"
EndSection


Section "Files"
ModulePath "/usr/lib64/xorg/modules"
ModulePath "/usr/lib/xorg/modules"
EndSection

Section "Extensions"
# compiz needs Composite, but it can cause bad (end even softreset-
resistant)
# effects in some graphics cards, especially nv.
Option "Composite" "Enable"
EndSection

Section "Module"
Load  "dbe" # Double Buffering Extension, very important.
Load  "dri" # This shouldn't be available choice if user has selected
driver vga, vesa or nv.
Load  "glx" # GLX Extension.
Load  "freetype" # Freetype fonts.
Load  "type1"  # Type 1 fonts
Load  "record" # Developer extension, usually not needed
Load  "extmod" # This is okay, but if you look into "man xorg.conf"
you'll find option NOT to include DGA extension with extmod, and for a good
reason.. DGA causes instability as it accesses videoram without consulting X
about it.
SubSection  "extmod"
Option  "omit xfree86-dga"
EndSubSection
#   Load  "speedo" # Speedo fonts, this module doesn't exist in Xorg 7.0.17
# The following are deprecated/unstable/unneeded in Xorg 7.0
#   Load  "ddc"  # ddc probing of monitor, this should be never present, as
it gets automatically loaded.
#   Load  "GLcore" # This should be never present, as it gets automatically
loaded.
#   Load  "bitmap" # Should be never present, as it gets automatically
loaded. This is a font module, and loading it in xorg.conf makes X try to load
it twice.
EndSection

Section "ServerFlags"
Option  "Xinerama" "on"
EndSection

Section "InputDevice"
Identifier  "Generic Keyboard"
Driver  "kbd"
Option  "XkbRules" "xorg"
Option  "XkbModel" "pc104"
Option  "XkbLayout" "us"
EndSection

Section "InputDevice"
Identifier  "Configured Mouse"
Driver  "mouse"
EndSection


Section "Monitor"
Identifier  "DVI-0"
Option  "DPMS" "true"
Option  "Primary" "true"
EndSection

Section "Monitor"
Identifier "HDMI"
EndSection
Section "DRI"
Mode 0666
EndSection

Section "Monitor"
Identifier  "VGA-0"
Option  "DPMS" "true"
Modeline"1280x1024"  108.75  1280 1368 1496 1712  1024 1027 1034
1062 -hsync +vsync
Option  "Primary" "false"
Option  "PreferredMode" "1280x1024"
EndSection


Section "Device"
Identifier  "DVI Device"
Driver  "ati"
Option  "Monitor-DVI-0" "DVI-0"
BusID   "PCI:5:0:0"
EndSection

Section "Device"
Identifier "HDMI Device"
EndSection

Section "Device"
Identifier  "VGA Device"
Driver  "ati"
Option  "Monitor-VGA-0" "VGA-0"
BusID   "PCI:5:0:0"
EndSection


Section "Screen"
Identifier "DVI Screen"
Device "DVI Device"
Monitor"DVI-0"
DefaultDepth 24
SubSection "Display"
#   Viewport   0 0
#   Virtual   3328 2048
Depth 24
Modes "2048x1152"
EndSubSection
EndSection

Section "Screen"
Identifier "VGA Screen"
Device   

Bug#720146: elmer: fails to remove: rmdir: failed to remove '/usr/share/ElmerGUI/edf': Directory not empty

[Boris Pek]

control: tags -1 + fixed pending

> during a test with piuparts I noticed your package fails to remove.

f8dc145


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

Bug#696123: partman-base: need progress wrapper for non-libparted-based filesystem operations

[Colin Watson]

On Tue, Feb 11, 2014 at 03:43:43PM -0500, Phillip Susi wrote:
> On 2/10/2014 4:36 PM, Colin Watson wrote:
> > Phillip, you've asked me about this a number of times.  I think the
> > work involved is fairly clear, although I don't seem to have
> > managed to make time for it personally.  Perhaps, rather than
> > continuing to ask me about this, you could have a go at the
> > necessary d-i integration?  I don't think it should be that hard
> > really.
> 
> Could you point me in the direction of how to test with my locally
> built parted3 udebs?  I tried using debian-installer and putting it in
> the local directory but it is ignored I guess because it doesn't go in
> the initrd, but is loaded later from the pool.

You're nearly there; in addition to having it in build/localudebs/, you
also need to add it to some appropriate file in build/pkg-lists/.  For
example build/pkg-lists/local would do.

Or you could just build a monolithic image, which is an image type
intended for this kind of testing.

> In the case of the netinst image, it just downloads the official 2.3
> udeb from the mirror since there is no pool, and when I tried make
> build_cdrom_isolinux, it just prepared the kernel and initrd in a
> directory rather than making an iso.

cdrom is mostly not a very convenient image type to use, since it needs
to be paired with debian-cd or similar to construct the actual CD.  Try
"make rebuild_netboot", or as I say "make rebuild_monolithic" to build
all plausible udebs into the image.

-- 
Colin Watson   [cjwat...@debian.org]


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

Bug#738480: exim4: Debian-exim group not match whith /etc/group

[Adam D. Barratt]

On Sun, 2014-02-09 at 23:07 +, Adam D. Barratt wrote:
> On Sun, 2014-02-09 at 23:42 +0200, Corcodel Marian wrote:
> > Run on terminal "id Debian-exim" and result is "uid=104(Debian-exim) gid=110
> > (Debian-exim) groups=110(Debian-exim)"
[...]
> The above is two different users with two different user IDs and two
> different groups. What exactly are you complaining about?

fwiw I got a bounce from the submitter's address in response to the
above mail.

Regards,

Adam


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

Bug#728371: RM: valgrind [armel] -- ROM; FTBFS

[Alessandro Ghedini]

On Mon, Jan 06, 2014 at 06:47:23PM +0100, Alessandro Ghedini wrote:
> On Tue, Nov 05, 2013 at 11:05:59AM +0100, Ansgar Burchardt wrote:
> > Alessandro Ghedini  writes:
> > > could you please remove valgrind from armel? It used to build there with a
> > > somewhat ugly hack (valgrind doesn't support armel baseline 
> > > architecture), but
> > > it stopped doing so a couple months ago, and there doesn't seem to be much
> > > interest in armel valgrind from arm porters (nor from me FWIW). Also see 
> > > #720409.
> > 
> > There are still quite a lot of packages build-depending on valgrind:
> 
> I wonder if we could go ahead with this. Right now the only packages build
> depending on valgrind on armel are jq (removed from testing) and abiword 
> (fixed
> in experimental). What do you think?

Ping?

AFAICT a fixed version of abiword has been uploaded to unstable as well, so the
only blocker is now jq, which doesn't seem to be maintained (and is not in
testing anymore). Time permitting I might be able to NMU it, but I wouldn't hold
my breath if I were you.

Cheers

-- 
perl -E '$_=q;$/= @{[@_]};and s;\S+;;eg;say~~reverse'


signature.asc
Description: Digital signature

Bug#738671: RFS: whatmask/1.2-1 [ITP]

[Daniel Lintott]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hi Nick,

Disclaimer: I'm not a DD, so can't upload your package but have looked
at it, as it is of interest to me.

Generally the package seems to be in very good shape and builds in a
clean chroot fine.

Just touching on the couple of lintian warnings:

> X: whatmask source: deprecated-configure-filename

I would forward this to upstream for their attention [1]

> I: whatmask source: debian-watch-file-is-missing

I have attached a watch file that seems to work okay (other watch file
guru's may be able to optimise it). As upstream sign their releases,
you can get uscan to check [2] this as well. I have included the line
to check this in the watch file (again, it might not be perfect)

The releases have been signed with key ID: E8882FE3

> I: whatmask: spelling-error-in-binary usr/bin/whatmask GNU PUBLIC
> LICENSE GNU General Public License

This will be easy enough to patch and again forward upstream. The
error appears in usage.c:60

Hope this review is helpful for you and aids you in finding a sponsor.

[1] http://lintian.debian.org/tags/deprecated-configure-filename.html
[2]
https://wiki.debian.org/debian/watch/#Cryptographic_signature_verification
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with undefined - http://www.enigmail.net/

iQEcBAEBAgAGBQJS+pgdAAoJEMw/9yOWzAkJg4AH/RiyxLX1IvkOCHGqfnAyhoED
cLNI6BUp6TXHqa11//nySvrSoHrIhBgY+ZJvO+d1WmoUzMI0MShcTC91mUYKgOIi
2zJDOK9PapwK3e7PJGHnIJP9jGykD2OaeEvCIC4LMp2OeAw1sE5K1z2tBDHxCDHL
ll6JU7pQsRPFBB/UpuaRvCUScyj+VVLbE1uX1XsK3TivI2naKOeQtuH/pKKiJcz+
VFrNLx6TZFPQe3v96e+RK+yUnwdNjTEaurXPKyiV/Rbk/bEvDIY5CWPQZNGWzZ0c
3P0CdQNF2Ci8kxaGTDyR1+1cza4GwRS9iFlqXZ/BSby92y3zzYZ4EpQD0//UDC8=
=OtT3
-END PGP SIGNATURE-
version=3
opts=pgpsigurlmangle=s/$/.asc/ \
http://downloads.laffeycomputer.com/current_builds/whatmask/ 
whatmask-([\d\.]+\d)\.(?:zip|tgz|tbz|txz|(?:tar\.(?:gz|bz2|xz)))

Bug#738662: wheezy-pu: package freeciv/2.3.2-1+deb7u1

[Adam D. Barratt]

Control: tags -1 + confirmed

On Tue, 2014-02-11 at 17:59 +0100, Markus Koschany wrote:
> I recently became one of the uploaders of Freeciv. I would like to ask
> for permission to update the version in stable and to address
> http://bugs.debian.org/696306.
> 
> The proposed update fixes two security vulnerabilities which were not
> deemed important enough by the security team to warrant a DSA
> but I think it should be fixed in a point release at least.

Please go ahead; thanks.

Regards,

Adam


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

Bug#738616: removing newer libasio-dev (v1.10) from unstable

[Daniel Pocock]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256



On 11/02/14 22:18, Markus Wanner wrote:
> Daniel,
> 
> On 02/11/2014 09:46 PM, Daniel Pocock wrote:
>> Has anybody else tried something else to deal with this package 
>> transition or reversion to 1.4.8?  Or did I do something wrong
>> when adding the epoch?
> 
> I think you did just fine, but PTS is lagging behind. See here: 
> http://metadata.ftp-master.debian.org/changelogs/main/a/asio/asio_1.4.8-3_changelog

I
> 
notice that everything seemed to fall into place shortly after
sending that email - my reSIProcate packages are building now


> Does this allow us to close this bug? And at least degrade #738613
> to non-serious? (Otherwise, your upload won't migrate to testing,
> either, I guess.)
> 

We should mark 738613 fixed in the new version I think

> On 02/11/2014 01:40 PM, Julien Cristau wrote:
>> Please try to avoid versioned -dev packages.  Unless you really
>> really have to keep both versions around for years.
> 
> Rethinking that, I agree. For effectively two debian packages
> (abiword and resiprocate, disregarding ball) that rely on
> libasio-dev, it's hardly worth the effort of maintaining two
> separate versions.
> 
> The other point being that (this variant of) asio being a
> headers-only library doesn't change the fact that any -dev package
> is only used during a build, but not when running any program
> (binary). In other words, just like any other -dev package, an
> upgrade of it won't ever break a compiled binary. At the worst, it
> leads to an FTBFS (as 1.10.1 does for both, BTW).
> 

It is an awkward question - if the API change is mild and the new
version is better in every way then killing of the old version (with
enough time for a transition) is fair enough

If there are any question marks over stability of the new version or
if it is so much work that the packagers of resiprocate and abiword
can't easily fix it, then the pain of keeping an old version
libasio1.4-dev may be much less

As a reSIProcate upstream,
* We just released 1.9.0 with a dependency on asio 1.4.x
* I'm happy to look at asio version for our 1.10.x release cycle.
* only one part of reSIProcate uses asio, so I could also split the
package upstream, reduce the scope for future conflicts like this





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

iQIcBAEBCAAGBQJS+pWGAAoJEOm1uwJp1aqDITYQALlGaQpOyNJw3Vz3JtXd+us/
JDUBV94PZqhZSC4KVZeNSMY6n1jQufHpvbkVapXJDO4GgiCp4yWU/NtEVjCP07sl
8+YjJcLep783kI2YVkjm1Fo+6JeVXdQfE827663/h58jEX1U9Lk7bEhdM26u7VdQ
n4JyY2GFS8BXO9sLAxopoo8xcT6RWW0GnZlvcjO0GuF1tXrLVII3BJBCCvxmSUkA
MWu7FL6fUFI/JgGejQbiOl60i7GtlzCHlwlp0o3uBSvU1s6rQMoR+0J0Dbw9c5Og
qi2mdF2N9dXeVA86EErWTvyobPcjI0Wg3uQSizIsLoK9uD79CKPqcA23bGfqie7x
5dv9ZOcY8Hpxm2S3V5UPmZvyKTNI4A6AbG1N+X2HnlUVK5++NkMsMb5QRW3y6oQ9
YD03EvFQfyAjIC8A1T4n0poTpxUM3rl9uyCqziZsEWOzbgjJaLOvwhsqAO7JHx3y
sRFpSWn1J24blji270PJx4w/b3ZBD0zbXj6lhZDCNW9R3uqoVvxKwB5LyPlQKvTe
bZ/z3/ZNByTlytlsN+ZVim9V3q/7tDsKqBL5QIqHcl1D+4ez5Nw9IPnE1iGtakBm
l4Wx4JkYxfRdSLEgtXVZCWsD6Pte2Ftsj8eGKm8EwkdXmWjp5hW7Xm9XDbXMgrTT
YKZ2l9NBfFqAdh6Ve8r+
=lMdP
-END PGP SIGNATURE-


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

Bug#738681: ITP: bosixnet -- Build Own IPv6 Network

[Boris Pek]

Package: wnpp
Severity: wishlist

* Package name: bosixnet
  Version: 1.6
  Upstream Contact: Boris Pek 
* URL: https://github.com/tehnick/bosixnet
* License: GPL-2+
  Programming Lang: C++, Shell
  Deb packages: https://github.com/tehnick/bosixnet-debian
  Description: Build Own IPv6 Network

Project should be useful when you have to administer many computers
distributed through different networks and connected via NAT. In most of cases
you may just install miredo, gogoc or any other tunnel broker's software and
these computers will be available via IPv6 addresses. BOSixNet includes the
collection of tools for automatic updating the list of such hosts.


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

Bug#738616: removing newer libasio-dev (v1.10) from unstable

[Markus Wanner]

Daniel,

On 02/11/2014 09:46 PM, Daniel Pocock wrote:
> Has anybody else tried something else to deal with this package
> transition or reversion to 1.4.8?  Or did I do something wrong when
> adding the epoch?

I think you did just fine, but PTS is lagging behind. See here:
http://metadata.ftp-master.debian.org/changelogs/main/a/asio/asio_1.4.8-3_changelog

Does this allow us to close this bug? And at least degrade #738613 to
non-serious? (Otherwise, your upload won't migrate to testing, either, I
guess.)

On 02/11/2014 01:40 PM, Julien Cristau wrote:
> Please try to avoid versioned -dev packages.  Unless you really really
> have to keep both versions around for years.

Rethinking that, I agree. For effectively two debian packages (abiword
and resiprocate, disregarding ball) that rely on libasio-dev, it's
hardly worth the effort of maintaining two separate versions.

The other point being that (this variant of) asio being a headers-only
library doesn't change the fact that any -dev package is only used
during a build, but not when running any program (binary). In other
words, just like any other -dev package, an upgrade of it won't ever
break a compiled binary. At the worst, it leads to an FTBFS (as 1.10.1
does for both, BTW).

Granted, I should still have started a proper transition, rather than
uploading (an API-incompatible) 1.10.1 without notice. Please accept my
apologies, I should have known better.

Regards

Markus Wanner




signature.asc
Description: OpenPGP digital signature

Bug#727708: call for votes on default Linux init system for jessie

[Adrian Bunk]

On Tue, Feb 11, 2014 at 08:22:19PM +0100, Kurt Roeckx wrote:
> On Tue, Feb 11, 2014 at 10:59:34AM -0800, Steve Langasek wrote:
> > On Tue, Feb 11, 2014 at 12:18:41PM -0500, Sam Hartman wrote:
> > > > "Bdale" == Bdale Garbee  writes:
> > 
> > > Bdale> Steve Langasek  writes:
> > > >> FWIW I have always assumed that the casting vote is implicit in
> > > >> the chair's ballot.  To require the chair to explicitly exercise
> > > >> their casting vote, as opposed to the chair's preferences as
> > > >> expressed on the ballot being applied automatically, opens up
> > > >> another set of vote gaming strategies that we really shouldn't
> > > >> get into.
> > 
> > > Bdale> I would have assumed that, too, but since others did not
> > > Bdale> share the assumption, it seemed prudent to be explicit about
> > > Bdale> it.
> > 
> > > This assumption does not make sense to me in the following cases:
> > 
> > > * Chair ranks multiple options equilly
> > 
> > If the chair ranked them equally in his ballot, why should he express a
> > different preference when it comes to the casting vote?
> 
> I think the vote should always result in something, and as such
> the person having the casting vote needs to pick one of the
> options that are left in the Schwartz set.  If there was no
> preference between them, a choise will still need to be made.
> 
> I've actually been wondering about this issue myself the past few
> days, and this seems to me the only good reason why the casting
> vote should be a different vote than the earlier vote.

Somewhere buried in this huge thread I had a discussion with Anthony 
regarding it, and in my opinion there is another possible good reason:

Assume in Ian's previous combined ballot where voting was aborted the 
two remaining members would have voted, and both had voted DT > DL > FD.

The result would have been:

DT > FD (5:3)
DL > FD (8:0)
DT = DL (4:4)

One can argue that the the chairman should simply pick whatever he 
personally prefers.

My point here is that the chairman should IMHO at least consider the 
fact that there is one option that is acceptable for all members, while 
the other option is vehemently opposed by 3 TC members.

And choosing a generally acceptable option over his personal preference 
would be a good reason for voting different in the casting vote.[1]

> Kurt

cu
Adrian

[1] The chairman has no obligation to change his vote in such a case,
but if he would there would be a good reason and not just random
erratic behaviour.

-- 

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


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

Bug#738680: RFA: libbsd-arc4random-perl -- CPAN's BSD::arc4random -- Perl bindings for arc4random

[Thorsten Glaser]

Package: wnpp
Severity: normal

I request an adopter for the libbsd-arc4random-perl package.
I’d like to put it under the Debian Perl umbrella, if possible,
as my Perl is very limited, and this package has been spitting
warnings recently for which more experienced people can write
patches (which I’d happily accept upstream).

The package description is:
 implemented-in::perl, interface::TODO, made-of::TODO, role::devel-lib,
 role::plugin, scope::utility, security::cryptography, suite::bsd,
 web::cgi


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

Bug#734164: console-data: should conflict with console-setup

[Michael Schutte]

On Mon, Feb 10, 2014 at 02:54:45PM +0200, Anton Zinoviev wrote:
> On Sun, Feb 09, 2014 at 12:12:31PM +0100, Michael Schutte wrote:
> > I'm not sure if I understand this point.  Would you like to keep these
> > old configuration files?
> 
> Not at all.  It's just that the idea of leaving behind the modified 
> legacy conffiles unowned never occurred to me.
> 
> Since there is some functionality which is supported by the legacy 
> scripts but currently unsupported by setupcon, it seemed to me that we 
> have to support (for a while) this functionality outside of setupcon.  
> In case we decide not to leave behind the modified legacy scripts the 
> only option seems to be to keep the legacy scripts (and conffiles) in 
> one place.  The reason I proposed to start with this change is because I 
> think it will be easier for us this way.

I see, thanks for elaborating.  This does sound appealing, but what
should happen in an upgrade if the package into which we move the
conffiles (IMHO this should be console-setup) is not installed on a
particular system?  Unless we add dependencies from console-common and
kbd (this one would be circular) to console-setup, or move all conffiles
to kbd instead (which is the one package that is sure to be present), we
are stuck with these dangling conffiles anyway.

What do you think of the plan that I've already hinted at: Drop
everything in /etc from the console-common and kbd binary packages.
dpkg will of course leave them behind on upgrade, and they are only
actively removed through maintainer scripts if they are all unmodified.
Systems which have been relying on the legacy features of kbd and
console-common can thereby continue to do so, whereas new installs are
unencumbered by the historical clutter.  This also means that we provide
less configuration options on new installs, but I assume that the lost
options are in fact very rarely used, and we can gradually reintroduce
(some of) them to /etc/init.d/console-setup and/or setupcon, configured
through /etc/default/{keyboard,console-setup}.

> > I do not like the idea of having an /etc/kbd/config owned by
> > console-setup, for example, when the same options can and should be
> > changed through /etc/default/console-setup.
> 
> /etc/kbd/config is not a problem.
> 
> Currently we have /etc/default/keyboard and /etc/default/console-setup 
> but the scripts of console-setup make no difference between these two 
> files.  For example, if one prefers, he can move the contents of 
> /etc/default/console-setup to /etc/default/keyboard and everything will 
> be OK.
> 
> Now, as far as I can tell there are no variable conflicts between the 
> variables of /etc/kbd/config and /etc/default/{console-setup,keyboard}. 
> So while it won't be possible to add all required functionality to 
> setupcon, we can get rid of /etc/kbd/config right now -- we only have to 
> make the legacy scripts in /etc/init.d/ source not only /etc/kbd/config 
> but also /etc/default/console-setup.

I like this idea.  The /etc/default/{keyboard,console-setup} variables
should have precedence in such a scheme, because even now, console-setup
overrides the configuration from console-common and kbd.

> Regarding /etc/init.d/{kbd,keymap.sh}, one option is to leave them as 
> they currently are (but both owned by one package).  Another option is 
> to merge them with /etc/init.d/{keyboard-setup,console-setup}.  While 
> I'd like to keep setupcon clean, I don't mind adding to these init.d 
> scripts as many legacy stuff as necessary.
> 
> Are there some other legacy conffiles we have to consider?

/etc/console/boottime.kmap.gz is the only other one I can think of at
the moment.

Cheers,
Michael


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

Bug#727708: call for votes on default Linux init system for jessie

[Russ Allbery]

Matthias Urlichs  writes:
> Steve Langasek:

>> "Obvious", but wrong.  We use Condorcet to enable fully expressing our
>> preferences among all the ballot options, not just our first-choice
>> preference.  The chair using a casting vote between two tied options
>> (or three, which is the problematic case) is expressing a preference
>> for one over the other; if such a preference exists, the non-strategic
>> vote is to express this same preference in the original ballot.

> The chair might desire to use their casting vote to select the more
> popular | less controversial | more- (or less-)vocally-supported option,
> as opposed to their personal opinion | preference.

Can I suggest that this discussion may be better placed in debian-project?
The procedural issue is really a concern for the project as a whole, and
any changes would be constitutional changes and would have to go through
the project as a whole.

-- 
Russ Allbery (r...@debian.org)   


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

Bug#738678: xul-ext-sage: broken with iceweasel 24 from stable-security

[Sébastien Villemot]

Package: xul-ext-sage
Version: 1.4.12-3+deb7u1
Severity: grave
Justification: renders package unusable
Control: fixed -1 1.5.2-2

Dear Maintainer,

iceweasel 24 recently hit stable-security (and is therefore expected to enter
stable at the next point release).

Unfortunately the version of xul-ext-sage currently in stable is unusable
with iceweasel 24 (clicking on a link in the left panel does nothing).

Cheers, 

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

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

xul-ext-sage depends on no packages.

Versions of packages xul-ext-sage recommends:
ii  iceweasel  24.3.0esr-1~deb7u1

xul-ext-sage suggests no packages.

-- no debconf information

-- 
 .''`.Sébastien Villemot
: :' :Debian Developer
`. `' http://www.dynare.org/sebastien
  `-  GPG Key: 4096R/381A7594


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

Bug#737845: cavezofphear: please provide a desktop and menu file and icons

[Markus Koschany]

Hi,

On 11.02.2014 21:26, Håkon Nessjøen wrote:
> Hi,
> 
> I could create a desktop and/or a menu file. But the game does not have
> any official logo or icon. What would I use as icon? Any ideas?
> I will contact the upstream author if thats the best solution.

You could depend on some icon package like the hicolor-icon-theme and
link to one of the standard icons. There are multiple image or icon
packages available for Debian. Check out "aptitude search icons" for
examples.

You could also take a screenshot, highlight some interesting aspect of
the game (persons, items, background) and crop the image until it fits
your needs. Please provide at least a 128x128 pixel image in png format
for your desktop file, so that it looks good on Gnome 3. Then you just
have to convert this image to a 32x32 pixel xpm file for your Debian menu.

I created a minimalistic M letter in ASCII letters on a black background
for the matanza package. Be creative. :)

Thanks for your help!

Regards,

Markus





signature.asc
Description: OpenPGP digital signature

Bug#738679: xul-ext-flashblock: broken with iceweasel 24 from stable-security

[Sébastien Villemot]

Package: xul-ext-flashblock
Version: 1.5.15-1
Severity: grave
Justification: renders package unusable
Control: fixed -1 1.5.17-1

Dear Maintainer,

iceweasel 24 recently hit stable-security (and is therefore expected to enter
stable at the next point release).

Unfortunately the version of xul-ext-flashblock currently in stable does not
work with iceweasel 24 (flash animations start automatically instead of waiting
for a click from the user).

Cheers,


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

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

xul-ext-flashblock depends on no packages.

Versions of packages xul-ext-flashblock recommends:
ii  iceweasel  24.3.0esr-1~deb7u1

xul-ext-flashblock suggests no packages.

-- no debconf information

-- 
 .''`.Sébastien Villemot
: :' :Debian Developer
`. `' http://www.dynare.org/sebastien
  `-  GPG Key: 4096R/381A7594


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

Bug#639984: [Pkg-xfce-devel] Bug#639984: lightdm: restart/reload fails if DISPLAY is set

[Yves-Alexis Perez]

On Tue, Feb 11, 2014 at 01:22:25PM +0100, Jens Reinsberger wrote:
> Nonetheless we were using the runlevel startup scripts to restart lightdm over
> a ssh connection which failed while other login managers (namely kdm) did
> not. That way you can restart remotely any display manager I know of without
> fiddling with the DISPLAY variable.
> 
> Thats why I ask you to accept this bug and maybe change the init script
> accordingly in order to ignore the DISPLAY variable. If wanted, I can write up
> a small patch which makes the behaviour configurable via 
> /etc/defaults/lightdm.

DISPLAY is used in legitimate cases. You're free to unset DISPLAY on
your specific uses cases, you're even free to edit /etc/init.d/lightdm
file, your modifications won't be overwritten by dpkg at the next
update.

Regards,
-- 
Yves-Alexis Perez


signature.asc
Description: Digital signature

Bug#738616: removing newer libasio-dev (v1.10) from unstable

[Daniel Pocock]

On 11/02/14 15:41, Daniel Pocock wrote:
> On 11/02/14 15:26, Andreas Beckmann wrote:
>> On 2014-02-11 13:10, Markus Wanner wrote:
>>> On 02/11/2014 01:01 PM, Andreas Beckmann wrote:
 Or if you want to avoid using epochs, reupload 1.4.8 using as 
 1.10.really.1.4.8 as the upstream version, and upload 1.10 as 1.10.release 
 to 
 experimental. Once you upload upstream 1.11 you are back to normal version 
 numbers without having used an epoch inbetween.
>>> Given that we are likely to switch to separate libasio1.4-dev and
>>> libasio1.10-dev packages, I think the epoch approach is less confusing,
>>> overall.
>> Since it seems you need to introduce libasio1.4-dev anyway, it should be
>> possible to fix this version mess without .really. versions and without
>> using epochs. All it needs is a trip through NEW.
>>
>> Let me know if I should look into preparing a patch ...
>>
>>
> 
> 
> I already made an upload using epoch
> 
> It is 1:1.4.8-3
> 
> 

I notice the upload hasn't actually built

   http://packages.qa.debian.org/a/asio.html

reports that it is still 1.10.1-1 in unstable and no link to the build logs

Has anybody else tried something else to deal with this package
transition or reversion to 1.4.8?  Or did I do something wrong when
adding the epoch?


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

Bug#727708: call for votes on default Linux init system for jessie

[Matthias Urlichs]

Hi,

Steve Langasek:
> "Obvious", but wrong.  We use Condorcet to enable fully expressing our
> preferences among all the ballot options, not just our first-choice
> preference.  The chair using a casting vote between two tied options (or
> three, which is the problematic case) is expressing a preference for one
> over the other; if such a preference exists, the non-strategic vote is to
> express this same preference in the original ballot.
> 
The chair might desire to use their casting vote to select the more popular |
less controversial | more- (or less-)vocally-supported option, as opposed
to their personal opinion | preference.

> The *only* use of a casting vote that is different from the original ballot
> is a strategic one, and we should never allow this.

I disagree.

-- 
-- Matthias Urlichs


signature.asc
Description: Digital signature

Bug#696123: partman-base: need progress wrapper for non-libparted-based filesystem operations

[Phillip Susi]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 2/10/2014 4:36 PM, Colin Watson wrote:
> Phillip, you've asked me about this a number of times.  I think the
> work involved is fairly clear, although I don't seem to have
> managed to make time for it personally.  Perhaps, rather than
> continuing to ask me about this, you could have a go at the
> necessary d-i integration?  I don't think it should be that hard
> really.

Could you point me in the direction of how to test with my locally
built parted3 udebs?  I tried using debian-installer and putting it in
the local directory but it is ignored I guess because it doesn't go in
the initrd, but is loaded later from the pool.  In the case of the
netinst image, it just downloads the official 2.3 udeb from the mirror
since there is no pool, and when I tried make build_cdrom_isolinux, it
just prepared the kernel and initrd in a directory rather than making
an iso.


-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.17 (MingW32)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQEcBAEBAgAGBQJS+ot+AAoJEI5FoCIzSKrwXb0H/16Zfn8tA4aZW59RphthGzsM
7r+WRJ2hW8fsdU7Xq8xzxy1W2caECYnqTm/+mKHRdLOcsEEdx+WwsRquGYSLEhyP
5eNQiBAHnjGajaPyEXioG/BUX9mP6x7DrbgtsswtQg5TD3DQCuOMWpx4LwRPLlvk
ZuQPwib3Qb+5l6c8ZVKPV4wFxV5N9xxCuXqt5uA6AUCLTYDhK22S8bustnRxiTt5
XK2TM0flD9kcc3w1pjAW1rhQVbRwgEP+GwOq77GvJhMJUUV7qLwQMclOefKIk0kQ
YYQnjnq0nqoOQ3P3AbLA2XwsresutRay/AEpAEL32fFcRKy2BX6gcKjO97LXpE0=
=yPlS
-END PGP SIGNATURE-


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