date:20141202

Package: wnpp
Severity: normal

I'm orphaning mpclib3.

Laurent.


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

Bug#771883: O: mpfi -- multiple precision floating-point interval computation library

Package: wnpp
Severity: normal

I'm orphaning mpfi.

Laurent.


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

Bug#771884: O: mpfr4 -- multiple precision floating-point computation

Package: wnpp
Severity: normal

I'm orphaning mpfr4 (one of the co-maintainers may consider adopting
it :-).

Laurent.


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

Bug#771881: O: mpclib -- multiple precision complex floating-point library

Package: wnpp
Severity: normal

I'm orphaning mpclib (which should probably me removed anyway, it's
obsoleted by mpclib3).

Laurent.


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

Bug#771880: O: gmp-ecm -- Factor integers using the Elliptic Curve Method

Package: wnpp
Severity: normal

I'm orphaning gmp-ecm.

Laurent.


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

Bug#771879: unblock: s3ql/2.11.1+dfsg-2

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

Please unblock package s3ql. This version fixes bug #771452
(severity important). There are no other changes to the version
currently in testing.

The package is not yet uploaded because I'm waiting for my sponsor.
I'm sending the unblock request now in the hope that this will
ensure that it's in time for the December 5 deadline for important
bugs.

Changelog:

s3ql (2.11.1+dfsg-2) unstable; urgency=medium

  * Fixed a problem with fsck.s3ql aborting with an
"apsw.ConstraintError" or incorrectly considering storage
objects as missing when the connection to remote server is
interrupted. Closes: #771452.

 -- Nikolaus Rath   Tue, 02 Dec 2014 21:44:27 -0800


Debdiff is attached.


unblock s3ql/2.11.1+dfsg-2
diff -Nru s3ql-2.11.1+dfsg/debian/changelog s3ql-2.11.1+dfsg/debian/changelog
--- s3ql-2.11.1+dfsg/debian/changelog	2014-09-05 13:31:29.0 -0700
+++ s3ql-2.11.1+dfsg/debian/changelog	2014-12-02 21:46:52.0 -0800
@@ -1,3 +1,12 @@
+s3ql (2.11.1+dfsg-2) unstable; urgency=medium
+
+  * Fixed a problem with fsck.s3ql aborting with an
+"apsw.ConstraintError" or incorrectly considering storage
+objects as missing when the connection to remote server is
+interrupted. Closes: #771452.
+
+ -- Nikolaus Rath   Tue, 02 Dec 2014 21:44:27 -0800
+
 s3ql (2.11.1+dfsg-1) unstable; urgency=medium
 
   * New upstream release.
diff -Nru s3ql-2.11.1+dfsg/debian/patches/bug_771452.diff s3ql-2.11.1+dfsg/debian/patches/bug_771452.diff
--- s3ql-2.11.1+dfsg/debian/patches/bug_771452.diff	1969-12-31 16:00:00.0 -0800
+++ s3ql-2.11.1+dfsg/debian/patches/bug_771452.diff	2014-12-02 21:49:27.0 -0800
@@ -0,0 +1,28 @@
+Description: Fix bug 771452
+Origin: upstream commit 8e563c49
+Forwarded: not-needed
+Last-Update: <2014-12-02>
+Author: Nikolaus Rath 
+
+--- a/src/s3ql/backends/s3c.py
 b/src/s3ql/backends/s3c.py
+@@ -209,7 +209,7 @@
+ log.debug('list(%s, %s): start', prefix, start_after)
+ 
+ keys_remaining = True
+-marker = start_after
++marker = self.prefix + start_after
+ prefix = self.prefix + prefix
+ ns_p = self.xml_ns_prefix
+ 
+--- a/src/s3ql/backends/swift.py
 b/src/s3ql/backends/swift.py
+@@ -495,7 +495,7 @@
+ log.debug('list(%s, %s): start', prefix, start_after)
+ 
+ keys_remaining = True
+-marker = start_after
++marker = self.prefix + start_after
+ prefix = self.prefix + prefix
+ 
+ while keys_remaining:
diff -Nru s3ql-2.11.1+dfsg/debian/patches/series s3ql-2.11.1+dfsg/debian/patches/series
--- s3ql-2.11.1+dfsg/debian/patches/series	2014-09-04 19:07:59.0 -0700
+++ s3ql-2.11.1+dfsg/debian/patches/series	2014-12-02 21:47:01.0 -0800
@@ -1,3 +1,4 @@
 proc_mount.diff
 clock-granularity.diff
 check_dev_fuse_perms.diff
+bug_771452.diff

Bug#771847: debconf: [INTL:es] Updated program translation to Spanish

2014-12-02 Thread Christian PERRIER

Quoting Javier Fernández-Sanguino Peña (j...@debian.org):
> Package: debconf
> Version: 1.5.54
> Severity: wishlist
> Tags: l10n patch
> 
> Please find attached an updated translation of this program
> into Spanish.
> 
> Thanks for including it in your next package upload,

Hello Javier,

It seems that a fuzzy marker is left:


> 
> Javier
> 
> #: ../dpkg-reconfigure:99
> #, fuzzy
> msgid ""
> "Usage: dpkg-reconfigure [options] packages\n"
> "  -u,  --unseen-only\t\tShow only not yet seen questions.\n"
> "   --default-priority\tUse default priority instead of low.\n"
> "   --force\t\t\tForce reconfiguration of broken packages.\n"
> "   --no-reload\t\tDo not reload templates. (Use with caution.)"
> msgstr ""
> "Modo de uso: dpkg-reconfigure [opciones] paquetes\n"
> "  -u,  --unseen-only\t\tMostrar sólo las preguntas que no se han mostrado 
> aún.\n"
> "   --default-priority\tUtilizar la prioridad por omisión en lugar de la 
> más baja.\n"
> "   --force\t\t\tFuerza la reconfiguración de los paquetes rotos.\n"
> "   --no-reload\t\tNo recarga las plantillas (utilizar con precaución)."

My poor Spanish skills lead me to think that the translation is indeed
correct, but I prefer asking first. If you confirm, no need to resend
the translation: I'll just remove the fuzzy marker.




signature.asc
Description: Digital signature

Bug#771878: O: canlock -- library for creating and verifying Usenet cancel locks

Package: wnpp
Severity: normal

I'm orphaning canlock.

Laurent.


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

Bug#771452: Duplicate object check

severity 771452 important
thanks

On 12/02/2014 01:50 PM, Shannon Dealy wrote:
> On Mon, 1 Dec 2014, Nikolaus Rath wrote:
> 
>> severity -1 normal
>> retitle -1 fsck.s3ql sporadically crashes when checking objects
>> thanks
>>
>> Retitling this bug and lowering severity for now. I don't think that the
>> mount.s3ql crash is related to the fsck.s3ql crashes, or that there is
>> any data corruption.
> 
> While I understand your assessment, I don't think I would characterize
> this bug as "normal".  Based on my understanding, the Debian guidelines
> would rate this bug at the very least as "important", and frankly I
> would still argue for "critical" given that it effectively "causes
> serious data loss" (one of the possible criteria for "critical").
> 
> My reasoning is that even assuming the file system data has not actually
> been lost or corrupted (and I believe you are likely correct in this), I
> ran fsck.s3ql roughly 30 times before getting a successful run.  There
> is nothing to indicate that someone else with similar circumstances
> would not have to run it 1000 or 100,000 more times in order to recover
> the file system.  For such a case, their data is unavailable to them and
> effectively 100% lost until they have a fixed version of fsck.s3ql

I think the crucial difference is that the data is inaccessible, not
lost. It can easily be retrieved by upgrading S3QL, and chances are that
enabling/disabling SSL or using a different network connection may also
help. A data *loss* means that data is destroyed, not that it's
unavailable. Putting it differently, anything that is "lost until x" is
not lost.

But there's little point in arguing about severity. I'll set it to
important, that's still enough to get an update into jessie.


Best,
Nikolaus

-- 
GPG encrypted emails preferred. Key id: 0xD113FCAC3C4E599F
Fingerprint: ED31 791B 2C5C 1613 AF38 8B8A D113 FCAC 3C4E 599F

 »Time flies like an arrow, fruit flies like a Banana.«


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

Bug#771792: [Pkg-mozext-maintainers] Bug#771792: xul-ext-gcontactsync: gContactSync fails with "Please login before trying to sync contacts"

2014-12-02 Thread L. Guruprasad

On 03-12-2014 10:59, L. Guruprasad wrote:
> The xul-ext-gnome-keyring package was automatically installed without me
> explicitly choosing it for installation. So I guess it might be
> automatically installed for many other users as well. I will try to find
> out which dependency caused the xul-ext-gnome-keyring package to be
> automatically installed.

guruprasad@debby:~$ apt-cache rdepends xul-ext-gnome-keyring
xul-ext-gnome-keyring
Reverse Depends:
  gnome

Thanks & Regards,
Guruprasad



signature.asc
Description: OpenPGP digital signature

Bug#771452: Duplicate object check

Now (most likely) fixed in 
https://bitbucket.org/nikratio/s3ql/commits/8e563c492228a4d0669277d1b45a89955b68

Best,
-Nikolaus

-- 
GPG encrypted emails preferred. Key id: 0xD113FCAC3C4E599F
Fingerprint: ED31 791B 2C5C 1613 AF38 8B8A D113 FCAC 3C4E 599F

 »Time flies like an arrow, fruit flies like a Banana.«


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

Bug#771792: [Pkg-mozext-maintainers] Bug#771792: xul-ext-gcontactsync: gContactSync fails with "Please login before trying to sync contacts"

2014-12-02 Thread L. Guruprasad

Hi,

On 02-12-2014 21:15, Michael Meskes wrote:
> severity 771792 important
> thanks
> 
> On Tue, Dec 02, 2014 at 06:25:17PM +0530, L. Guruprasad wrote:
>> Severity: grave
>> Justification: renders package unusable
>> ...
>> xul-ext-gnome-keyring: 0.6.11-3
>> icedove: 31.2.0-1
> 
> As you're saying yourself the problem appears only when another add-on is
> installed, that means the package is not unusable by itself and thus the bug 
> is
> not grave.
> 
> And yes, there are people like myself who do not use xul-ext-gnome-keyring
> together with xul-ext-gcontactsync.

The xul-ext-gnome-keyring package was automatically installed without me
explicitly choosing it for installation. So I guess it might be
automatically installed for many other users as well. I will try to find
out which dependency caused the xul-ext-gnome-keyring package to be
automatically installed.

Thansk & Regards,
Guruprasad

signature.asc
Description: OpenPGP digital signature

Bug#718596: [Pkg-bluetooth-maintainers] Bug#718596: (no subject)

2014-12-02 Thread Habib Seifzadeh


Dear Nobuhiro,

Thanks a lot,

Bluez-obexd solved the problem. Both send and receive works perfectly,

Cheers,
Habib


On 12/03/2014 04:19 AM, Nobuhiro Iwamatsu wrote:

Hi,

obexd is already obsolete. Also different because API can not be used
in GNOME, KDE and other.
Please use the bluez-obexd instead.

Best regards,
   Nobuhiro

2014-11-25 20:13 GMT+09:00 Habib Seifzadeh :

Hi,

I want to confirm that downgrading to 0.46 version did not solve the problem
in my Debian Jessie. To downgrade, I downloaded the deb file of the 0.46
version and installed it using "dpkg -i packagename". Is it right?

Thanks,
Habib

___
Pkg-bluetooth-maintainers mailing list
pkg-bluetooth-maintain...@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-bluetooth-maintainers






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

Bug#771877: libdb5.3-java: trailing slash makes dpkg-maintscript-helper symlink_to_dir call useless

Package: libdb5.3-java
Version: 5.3.28-6
Severity: serious

Hi,

libdb5.3-java.maintscript contains a bug, rendering it useless:

  symlink_to_dir /usr/share/doc/libdb5.3-java/ /usr/share/doc/libdb5.3 
5.3.28-6~ -- "$@"
 ^

The trailing slash on the PATHNAME argument is wrong because

  test -h /path/to/link/

will never succeed - it always resolves to an underlying directory -
while

  test -h /path/to/link

will work as expected.

Do not forget to bump the LASTVERSION when fixing this - the symlink
would have survived into the current version.


Andreas


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

Bug#771876: src:libcwd: FTBFS on all architectures due to function that "may not have default arguments"

2014-12-02 Thread Logan Rosen

Package: src:libcwd
Version: 1.0.4-1
Severity: serious
Justification: fails to build from source (but built successfully in the past)

Dear Maintainer,

libcwd previously built properly from source on most archiectures, but now it 
fails due to a function that "may not have default arguments." I was able to 
reproduce this failure in a local unstable amd64 pbuilder. Here is the 
applicable tail end of the log:

---

/bin/bash ./libtool  --tag=CXX   --mode=compile x86_64-linux-gnu-g++ 
-DHAVE_CONFIG_H  -I./include -I./include-DCWDEBUG -g -c -o 
libcwd_la-demangle3.lo `test -f 'demangle3.cc' || echo './'`demangle3.cc
libtool: compile:  x86_64-linux-gnu-g++ -DHAVE_CONFIG_H -I./include -I./include 
-DCWDEBUG -g -c demangle3.cc  -fPIC -DPIC -o .libs/libcwd_la-demangle3.o
In file included from demangle3.cc:112:0:
../include/demangle.h:465:35: error: redeclaration of 'void 
__gnu_cxx::demangler::session::add_substitution(int, 
__gnu_cxx::demangler::substitution_nt, int)' may not have default arguments 
[-fpermissive]
 int number_of_prefixes = 0)
   ^
../include/demangle.h:1739:53: error: redeclaration of 'void 
__gnu_cxx::demangler::qualifier_list::decode_qualifiers(__gnu_cxx::demangler::qualifier_list::string_type&,
 __gnu_cxx::demangler::qualifier_list::string_type&, bool) const' 
may not have default arguments [-fpermissive]
bool member_function_pointer_qualifiers = false) const
 ^
Makefile:646: recipe for target 'libcwd_la-demangle3.lo' failed

---

This also occurred on all architectures in Ubuntu after applying an irrelevant 
patch:  https://launchpad.net/ubuntu/+source/libcwd/1.0.4-1ubuntu1

Thanks,
Logan Rosen

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

Kernel: Linux 3.16.0-25-generic (SMP w/1 CPU core)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash


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

Bug#771874: xmonad: User xmonad.hs unable to locate haskell modules

2014-12-02 Thread Danny O'Brien

Package: xmonad
Version: 0.11-9
Severity: normal

Dear Maintainer,

Since dist-upgrading to the current jessie, xmonad's ghc was unable to
compile the xmonad.hs installed in my $HOME/.xmonad directory.

Deleting the ~/.ghc directory seems to have fixed this, but I wonder if
this might be a problem that others upgrading to jessie might find.

(Unsure as to whether to report this as a ghc or xmonad bug -- I didn't
find any problems with other modules.)


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

Kernel: Linux 3.16.0-4-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 xmonad depends on:
ii  libc6 2.19-13
ii  libffi6   3.1-2
ii  libgmp10  2:6.0.0+dfsg-6
ii  libx11-6  2:1.6.2-3
ii  libxext6  2:1.3.3-1
ii  libxinerama1  2:1.1.3-1+b1
ii  libxrandr22:1.4.2-1+b1
ii  x11-utils 7.7+2

Versions of packages xmonad recommends:
ii  libghc-xmonad-dev  0.11-9
ii  libghc-xmonad-doc  0.11-9
ii  xfonts-base1:1.0.3

Versions of packages xmonad suggests:
ii  suckless-tools [dmenu]  40-1

-- 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#771875: unblock: chromium-browser/39.0.2171.71-2

2014-12-02 Thread Michael Gilbert

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

Please unblock chromium-browser.  It fixes some security issues and
fixes two RC issues: removing some non-free files and displaying info
about lack of support for < sse2.

Also a couple important issues were fixed: API keys for google
services were reenabled and some icon problems were corrected.

New upstream version because security updates for chromium in jessie
will stay in sync with upstream releases.

unblock chromium-browser/39.0.2171.71-2


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

Bug#771752: dpkg-maintscript-helper symlink_to_dir fails if PATHNAME argument contains a trailing /

On 2014-12-02 06:01, Guillem Jover wrote:
> I guess you set the severity to important, because it would avoid
> having to fix the affected package? How many packages are we talking
> about? Is it just that one?

No, I filed #771753 immediately afterwards.

There are probably only two source packages buggy:
http://codesearch.debian.net/search?q=symlink_to_dir\s%2B\S%2B%2F\s%2B

let me file another bug against db5.3 :-)

I haven't checked dir_to_symlink

> I guess I could use your proposed fix (for both symlink_to_dir and
> dir_to_symlink) or use «realphat -m» over the symlink or pathname, but
> I'd need to carefully ponder about the consequences. I'd rather do this
> if at all for 1.18.x, but that would defeat your bug report I guess. :)

If you don't want to fix it in dpkg, please reassign to lintian to add a
check that performs argument validation on these calls.

Andreas


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

Bug#674916: s3cmd: changing from ITA to O

2014-12-02 Thread Robinson Sathaseevan

My apologies everyone that I have dropped the ball on this. Please feel
free to pick this up so that the package gets the love it deserves.
Hopefully I can contribute to Debian via much simpler tasks in future.
Thanks.

On Tue, Dec 2, 2014 at 2:36 PM, Jay Berkenbilt  wrote:

> "Nicholas Robinson-Wall"  wrote:
>
> > I'm still interested in maintaining s3cmd - I assume there is no longer
> > any interest from the parties previously involved, given that this has
> > been gathering dust for the past year? If not I'll take a crack at this
> > shortly.
>
> I realistically don't have the bandwidth but if you need sponsorship and
> the python apps team is not available, I could still help with
> sponsorship. I still use s3cmd every day and was wondering where this
> was. So I guess my position is unchanged.
>
> > Jackson - you mentioned this might be better suited being maintained by
> > the python apps team. Is this something one can participate in without
> > being a full DD? I have another package which was sponsored into Debian,
> > but not as part of a team.
>
> I'll let someone in the team answer, but I'll point out that before I
> was a DD, I participated in the maintenance of team-maintained package
> and got sponsorship sometimes from the team and sometimes from outside
> the team. It shouldn't really make a difference.
>
> --
> Jay Berkenbilt 
>

Bug#771794: [Python-modules-team] Bug#771794: pip silently removes/updates system provided python packages

2014-12-02 Thread Daniel Kahn Gillmor

On 12/02/2014 10:38 PM, Scott Kitterman wrote:
> On Tuesday, December 02, 2014 19:28:20 Donald Stufft wrote:
>> So what if Debian just patched python-pip so that it doesn’t remove the
>> files from /usr/lib (but it would remove files from /usr/local etc). This
>> would have the effect of pip not touching dpkg owned files which would
>> bring it in line with that easy_install does. /usr/local/lib takes
>> precedence over /usr/lib so it won’t break things for people actually
>> trying to install things to /usr/local.
>>
>> There *might* be some edge cases that occurs with having two versions of a
>> package on sys.path, but I can’t think of any offhand (and either way,
>> those edge cases already exist if someone does
>> ``apt-get install python-requests && pip install —upgrade requests`` and
>> then later on Debian releases a new update to python-requests since those
>> files that pip removed will get reinstalled in that situation.
>>
>> That should fix the immediate problem this bug addresses and then we can
>> figure out a longer term “real” fix in upstream pip that can go into
>> Jessie+1.
> 
> Speaking only for myself, I think that sounds reasonable.

fwiw, I also think this sounds reasonable.  The issue is mainly that pip
removes stuff from under dpkg's nose, and this would address that problem.

So, where do we get the patch from?

--dkg



signature.asc
Description: OpenPGP digital signature

Bug#771873: trove-common: fails to purge: Association belongs to trove-common, not nova-common

Package: trove-common
Version: 2014.1.3-2
Severity: serious
User: debian...@lists.debian.org
Usertags: piuparts
Control: affects -1 + trove-taskmanager

Hi,

during a test with piuparts I noticed your package failed to purge.

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

  Removing trove-common (2014.1.3-2) ...
  Purging configuration files for trove-common (2014.1.3-2) ...
  ucfr: Association belongs to trove-common, not nova-common
  ucfr: Aborting
  dpkg: error processing package trove-common (--purge):
   subprocess installed post-removal script returned error exit status 5


Setting the severity to serious since that cannot be worked around (like
having ucf installed at purge time which obviously is the case here).

cheers,

Andreas


trove-taskmanager_2014.1.3-2.log.gz
Description: application/gzip

Bug#771794: pip silently removes/updates system provided python packages

2014-12-02 Thread Scott Kitterman

On Tuesday, December 02, 2014 19:28:20 Donald Stufft wrote:
> > On Dec 2, 2014, at 6:32 PM, Scott Kitterman  wrote:
> > 
> > Assuming the maintainer doesn't decide to downgrade the bug (which I think
> > is unlikely and a number of people would object to, so I think we can
> > ignore it as a possibility), the decision to ignore the bug for Jessie
> > belongs with the release team.  If we choose not to fix it (and there's
> > no Non-Maintainer Upload), then they will decide to either remove the
> > package or ignore the bug.
> > 
> > Since this particular issue is release critical, the December 5th deadline
> > isn't relevant to a targeted fix just for this issue.
> > 
> > Scott K
> 
> So the issue here is that pip is removing apt “owned” files implicitly
> during an upgrade right? Looking at easy_install there’s no Serious bug
> there and the primary difference between what will happen if you
> easy_install something and pip install something is that pip might remove
> files from /usr/lib. In both cases the items installed by both solutions
> will be in /usr/local/lib.
> 
> So what if Debian just patched python-pip so that it doesn’t remove the
> files from /usr/lib (but it would remove files from /usr/local etc). This
> would have the effect of pip not touching dpkg owned files which would
> bring it in line with that easy_install does. /usr/local/lib takes
> precedence over /usr/lib so it won’t break things for people actually
> trying to install things to /usr/local.
> 
> There *might* be some edge cases that occurs with having two versions of a
> package on sys.path, but I can’t think of any offhand (and either way,
> those edge cases already exist if someone does
> ``apt-get install python-requests && pip install —upgrade requests`` and
> then later on Debian releases a new update to python-requests since those
> files that pip removed will get reinstalled in that situation.
> 
> That should fix the immediate problem this bug addresses and then we can
> figure out a longer term “real” fix in upstream pip that can go into
> Jessie+1.

Speaking only for myself, I think that sounds reasonable.

It's well established I believe in Debian Python usage that if a user installs 
packages in /usr/local and break their system, they are on their own, so I'm 
not particularly worried about the edge cases for having the same python 
package installed in /usr/lib and /usr/local, it's on whoever installed stuff 
in /usr/local.

Being no more broken than easy_install seems like a reasonable compromise to 
me.

Scott K


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

Bug#771872: doxymacs: fails to install: ERROR: doxymacs is broken - called emacs-package-install as a new-style add-on, but has no compat file.

Package: doxymacs
Version: 1.8.0-6.1
Severity: serious
User: debian...@lists.debian.org
Usertags: piuparts

Hi,

during a test with piuparts I noticed your package failed to install. As
per definition of the release team this makes the package too buggy for
a release, thus the severity.

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

  Setting up doxymacs (1.8.0-6.1) ...
  ERROR: doxymacs is broken - called emacs-package-install as a new-style 
add-on, but has no compat file.
  Install doxymacs for emacs
  install/doxymacs: Handling install of emacsen flavor emacs
  Install doxymacs for emacs24
  install/doxymacs: Handling install of emacsen flavor emacs24
  install/doxymacs: byte-compiling for emacs24
  cp: cannot stat 'doxymacs.el': No such file or directory
  cp: cannot stat 'xml-parse.el': No such file or directory
  ERROR: install script from doxymacs package failed
  dpkg: error processing package doxymacs (--configure):
   subprocess installed post-installation script returned error exit status 1
  Setting up manpages-dev (3.74-1) ...
  Processing triggers for libc-bin (2.19-13) ...
  Errors were encountered while processing:
   doxymacs


cheers,

Andreas


doxymacs_1.8.0-6.1.log.gz
Description: application/gzip

Bug#771871: netscript: fails to install due to insserv rejecting the script header: There is a loop between service networking and netscript if started

Package: netscript
Version: 2.4_5.4.5
Severity: serious
User: debian...@lists.debian.org
Usertags: piuparts

Hi,

during a test with piuparts I noticed your package failed to install due
to insserv rejecting the script header. Some notes are
available from at https://wiki.debian.org/LSBInitScripts

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

  Selecting previously unselected package netscript-2.4.
  (Reading database ... 7753 files and directories currently installed.)
  Preparing to unpack .../netscript-2.4_5.4.5_all.deb ...
  Unpacking netscript-2.4 (5.4.5) ...
  Setting up netscript-2.4 (5.4.5) ...
  update-rc.d: warning: start and stop actions are no longer supported; falling 
back to defaults
  insserv: There is a loop between service networking and netscript if started
  insserv:  loop involving service netscript at depth 4
  insserv:  loop involving service networking at depth 3
  insserv:  loop involving service procps at depth 2
  insserv:  loop involving service mountnfs at depth 8
  insserv:  loop involving service mountall at depth 6
  insserv:  loop involving service urandom at depth 7
  insserv: There is a loop between service networking and netscript if started
  insserv: exiting now without changing boot order!
  update-rc.d: error: insserv rejected the script header
  dpkg: error processing package netscript-2.4 (--configure):
   subprocess installed post-installation script returned error exit status 1
  Errors were encountered while processing:
   netscript-2.4


cheers,

Andreas


netscript-2.4_5.4.5.log.gz
Description: application/gzip

Bug#771870: bareos-database-common: fails to install: bareos-database-common.config: /usr/sbin/bareos-dbcheck: not found

Package: bareos-database-common
Version: 14.2.1+20141017gitc6c5b56-4
Severity: serious
User: debian...@lists.debian.org
Usertags: piuparts

Hi,

during a test with piuparts I noticed your package failed to install. As
per definition of the release team this makes the package too buggy for
a release, thus the severity.

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

  Selecting previously unselected package bareos-database-common.
  (Reading database ... 9220 files and directories currently installed.)
  Preparing to unpack 
.../bareos-database-common_14.2.1+20141017gitc6c5b56-4_amd64.deb ...
  Unpacking bareos-database-common (14.2.1+20141017gitc6c5b56-4) ...
  Setting up bareos-database-common (14.2.1+20141017gitc6c5b56-4) ...
  /var/lib/dpkg/info/bareos-database-common.config: 1: 
/var/lib/dpkg/info/bareos-database-common.config: /usr/sbin/bareos-dbcheck: not 
found
  Warning: failed to get "dbname" from config, using default value "bareos", 
see /tmp/bareos-config.11958.log
  /var/lib/dpkg/info/bareos-database-common.config: 1: 
/var/lib/dpkg/info/bareos-database-common.config: /usr/sbin/bareos-dbcheck: not 
found
  Warning: failed to get "dbuser" from config, using default value "bareos", 
see /tmp/bareos-config.11958.log
  (config) dbc_go() bareos-database-common configure.
  dbc_config() bareos-database-common configure.
  dbc_set_dbtype_defaults() .
  dbc_register_debconf() .
  dbc_read_package_config() .
  dbc_preseed_package_debconf() .
  dbc_get_admin_pass() .
  dpkg: error processing package bareos-database-common (--configure):
   subprocess installed post-installation script returned error exit status 10
  Errors were encountered while processing:
   bareos-database-common

(Recommends are not installed, DEBIAN_FRONTEND=noninteractive)


cheers,

Andreas


bareos-database-common_14.2.1+20141017gitc6c5b56-4.log.gz
Description: application/gzip

Bug#771869: nouveau PROTECTION FAULT

2014-12-02 Thread Jerry Quinn


Package: src:linux
Version: 3.16.3-2
Severity: important
File: nouveau

Dear Maintainer,

System becomes unresponsive with blank screen.  After forcing reboot, I find
the following kernel messages from before the reboot:




Nov 22 19:17:24 cerberus kernel: [22339.268881] nouveau E[
PGRAPH][:01:00.0]  ERROR nsource: LIMIT_ZETA nstatus: PROTECTION_FAULT
Nov 22 19:17:24 cerberus kernel: [22339.268893] nouveau E[
PGRAPH][:01:00.0] ch 3 [0x00164b40 jigsaw[7590]] subc 7 class 0x4097 mthd
0x1d94 data 0x00f1
Nov 22 19:22:24 cerberus kernel: [22639.450040] nouveau E[ DRM] GPU lockup
- switching to software fbcon
Nov 22 19:22:39 cerberus kernel: [22654.460008] nouveau E[Xorg[1004]] failed
to idle channel 0x0001 [Xorg[1004]]
Nov 22 19:22:54 cerberus kernel: [22669.460006] nouveau E[Xorg[1004]] failed
to idle channel 0x0001 [Xorg[1004]]
Nov 22 19:23:09 cerberus kernel: [22684.460016] nouveau E[Xorg[1004]] failed
to idle channel 0x [Xorg[1004]]
Nov 22 19:23:24 cerberus kernel: [22699.460006] nouveau E[Xorg[1004]] failed
to idle channel 0x [Xorg[1004]]
Nov 22 19:23:39 cerberus kernel: [22714.588006] nouveau E[glschool[7591]]
failed to idle channel 0x [glschool[7591]]
Nov 22 19:23:54 cerberus kernel: [22729.588006] nouveau E[glschool[7591]]
failed to idle channel 0x [glschool[7591]]
Nov 22 19:24:09 cerberus kernel: [22744.596005] nouveau E[jigsaw[7590]] failed
to idle channel 0x [jigsaw[7590]]
Nov 22 19:24:24 cerberus kernel: [22759.604014] nouveau E[jigsaw[7590]] failed
to idle channel 0x [jigsaw[7590]]
Nov 22 19:24:26 cerberus kernel: [22759.852001] nouveau E[
PGRAPH][:01:00.0] idle timed out with status 0x0881
Nov 22 19:24:28 cerberus kernel: [22761.853429] nouveau E[
PGRAPH][:01:00.0] idle timed out with status 0x0881
Nov 22 19:24:30 cerberus kernel: [22763.853477] nouveau E[
PGRAPH][:01:00.0] idle timed out with status 0x0881
Nov 22 19:24:32 cerberus kernel: [22765.876885] nouveau E[
PGRAPH][:01:00.0] idle timed
 out with status 0x0881
Nov 22 19:31:03 cerberus kernel: [23158.88] nouveau E[Xorg[7602]] failed
to idle channel 0x0001 [Xorg[7602]]
Nov 22 19:31:09 cerberus kernel: [23164.807999] INFO: rcu_sched detected
stalls on CPUs/tasks: {} (detected by 3, t=5252 jiffies, g=852539, c=852538,
q=166)
Nov 22 19:31:09 cerberus kernel: [23164.808001] INFO: Stall ended before state
dump start
Nov 22 19:31:18 cerberus kernel: [23173.804006] nouveau E[Xorg[7602]] failed
to idle channel 0x0001 [Xorg[7602]]
Nov 22 19:31:18 cerberus kernel: [23173.812254] [sched_delayed] sched: RT
throttling activated
Nov 22 19:31:29 cerberus kernel: [23184.127999] BUG: soft lockup - CPU#3 stuck
for 22s! [Xorg:7602]
Nov 22 19:31:29 cerberus kernel: [23184.128001] Modules linked in: tcp_diag
inet_diag tun cfg80211 rfkill cpufreq_powersave cpufreq_conservative
cpufreq_userspace binfmt_misc cpufreq_stats nfsd auth_rpcgss oid_registry
nfs_acl nfs lockd fscache sunrpc adt7475 iTCO_wdt iTCO_vendor_support nouveau
snd_hda_codec_realtek snd_hda_codec_generic snd_hda_codec_hdmi mxm_wmi wmi
video ttm drm_kms_helper drm snd_hda_intel snd_hda_controller snd_hda_codec
snd_hwdep snd_pcm_oss snd_mixer_oss snd_pcm snd_timer kvm_intel kvm snd evdev
i2c_algo_bit serio_raw pcspkr i2c_i801 soundcore i2c_core button lpc_ich
shpchp mfd_core processor thermal_sys coretemp it87 hwmon_vid firewire_sbp2
loop fuse parport_pc ppdev lp parport autofs4 ext4 crc16 mbcache jbd2 raid1
md_mod sg sd_mod crc_t10dif sr_mod crct10dif_generic cdrom crct10dif_common
ata_generic hid_generic usbhid hid ahci libahci pata_jmicron firewire_ohci
firewire_core r8169 crc_itu_t mii uhci_hcd ehci_pci libata ehci_hcd scsi_mod
usbcore usb_common
Nov 22 19:31:29 cerberus kernel: [23184.128001] CPU: 3 PID: 7602 Comm: Xorg
Not tainted 3.16-2-amd64 #1 Debian 3.16.3-2
Nov 22 19:31:29 cerberus kernel: [23184.128001] Hardware name: Gigabyte
Technology Co., Ltd. G33M-S2H/G33M-S2H, BIOS F4H 07/29/2008
Nov 22 19:31:29 cerberus kernel: [23184.128001] task: 88020854e250 ti:
88021382 task.ti: 88021382
Nov 22 19:31:29 cerberus kernel: [23184.128001] RIP: 0010:[]
[] ioread32+0x3a/0x40
Nov 22 19:31:29 cerberus kernel: [23184.128001] RSP: 0018:880213823b58
EFLAGS: 0292
Nov 22 19:31:29 cerberus kernel: [23184.128001] RAX:  RBX:
8801ef18c9c0 RCX: 4d57
Nov 22 19:31:29 cerberus kernel: [23184.128001] RDX: 4d57 RSI:
c90017806048 RDI: c90017806048
Nov 22 19:31:29 cerberus kernel: [23184.128001] RBP: 8801ee84de40 R08:
0007 R09: 8801ef18c9c0
Nov 22 19:31:29 cerberus kernel: [23184.128001] R10: 8800b7563950 R11:
000f R12: 8800cb95ad71
Nov 22 19:31:29 cerberus kernel: [23184.128001] R13: 8800cb95ad00 R14:
88022fff5000 R15: 
Nov 22 19:31:29 cerberus kernel: [23184.128001] FS:  7f2f45507980()
GS:88022fd8() knlGS:
Nov 22 19:31:29 cer

Bug#770534: icinga2-common: fails to install: icinga2-common.postinst: icinga2: not found

Followup-For: Bug #770534
Control: found -1 2.2.1-1

The problem has now moved to icinga2-classicui. Well, it probably was
there before, but could not be tested with piuparts since -common
already had failed.

  Selecting previously unselected package icinga2-classicui.
  (Reading database ... 10882 files and directories currently installed.)
  Preparing to unpack .../icinga2-classicui_2.2.1-1_all.deb ...
  Unpacking icinga2-classicui (2.2.1-1) ...
  Setting up icinga2-classicui (2.2.1-1) ...
  enabling icinga2 features for classicui
  /var/lib/dpkg/info/icinga2-classicui.postinst: 40: 
/var/lib/dpkg/info/icinga2-classicui.postinst: icinga2: not found
  dpkg: error processing package icinga2-classicui (--configure):
   subprocess installed post-installation script returned error exit status 127
  Errors were encountered while processing:
   icinga2-classicui


Andreas


icinga2-classicui_2.2.1-1.log.gz
Description: application/gzip

Bug#771797: liblldb-3.5: does not ship SONAME link /usr/lib//liblldb.so.1 -> liblldb-3.5.so.1

Control: tag -1 patch

On 2014-12-02 15:51, Sylvestre Ledru wrote:
> On 02/12/2014 06:13, Andreas Beckmann wrote:
>> Setting the severity to serious since this file was previously shipped
>> by at least one other package (lldb-3.3) but liblldb-3.5 misses
>> appropriate Breaks/Conflicts+Replaces. (#769113)
> Not sure I understand the severity. This is a different package from
> lldb-3.3.

lldb-3.3 shipped /usr/lib/x86_64-linux-gnu/liblldb.so.1

liblldb-3.5 should ship /usr/lib/x86_64-linux-gnu/liblldb.so.1
because it is the soname link expected by ldconfig (and created if missing)

two packages shipping the same file are not co-installable and need
breaks+repalces (and there seems to be nothing in place that ensures the
obsolete lldb-3.3 is gone when installing 3.5)

If there were other packages shipping liblldb.so.1, they should get
Breaks/Replaces, too. What about lldb-3.4 or liblldb-3.4?

Hmm,
* liblldb-3.4 ships a library with SONAME liblldb-3.4.so
* liblldb-3.5 ships a library with SOANME liblldb.so.1
* liblldb-3.6 ships a libarry with SONAME liblldb-3.6.so

Attached is an untested patch (just started compiling).

You may consider removing the Multi-Arch:same for a (Closes: #765591)
Since the package ships symlinks in /usr/lib/llvm* that point to
/usr/lib//, the package cannot be multi-arch co-installable.


Andreas
diff -Nru llvm-toolchain-3.5-3.5/debian/changelog 
llvm-toolchain-3.5-3.5/debian/changelog
--- llvm-toolchain-3.5-3.5/debian/changelog 2014-10-15 18:16:59.0 
+0200
+++ llvm-toolchain-3.5-3.5/debian/changelog 2014-12-03 03:31:29.0 
+0100
@@ -1,3 +1,12 @@
+llvm-toolchain-3.5 (1:3.5-7) UNRELEASED; urgency=medium
+
+  * liblldb-3.5: Ship SONAME link liblldb.so.1 -> liblldb-3.5.so.1
+(Closes: #771797)
+  * liblldb-3.5: Breaks+Replaces: lldb-3.3 due to file conflict on
+liblldb.so.1.  (Closes: #769113)
+
+ -- Andreas Beckmann   Wed, 03 Dec 2014 03:12:29 +0100
+
 llvm-toolchain-3.5 (1:3.5-6) unstable; urgency=medium
 
   * Ignore a test failing under i386.
diff -Nru llvm-toolchain-3.5-3.5/debian/control 
llvm-toolchain-3.5-3.5/debian/control
--- llvm-toolchain-3.5-3.5/debian/control   2014-10-04 17:35:18.0 
+0200
+++ llvm-toolchain-3.5-3.5/debian/control   2014-12-03 03:19:40.0 
+0100
@@ -401,8 +401,8 @@
 Depends: ${shlibs:Depends}, ${misc:Depends}, libllvm3.5 (= ${binary:Version})
 Pre-Depends: ${misc:Pre-Depends}
 Section: libs
-Replaces: lldb-3.5 (<< 1:3.5~+rc4-2~)
-Breaks: lldb-3.5 (<< 1:3.5~+rc4-2~)
+Replaces: lldb-3.5 (<< 1:3.5~+rc4-2~), lldb-3.3
+Breaks: lldb-3.5 (<< 1:3.5~+rc4-2~), lldb-3.3
 Description: Next generation, high-performance debugger, library
  LLDB is a next generation, high-performance debugger. It is built as a set of
  reusable components which highly leverage existing libraries in the larger 
LLVM
diff -Nru llvm-toolchain-3.5-3.5/debian/liblldb-X.Y.links.in 
llvm-toolchain-3.5-3.5/debian/liblldb-X.Y.links.in
--- llvm-toolchain-3.5-3.5/debian/liblldb-X.Y.links.in  2014-09-01 
21:11:16.0 +0200
+++ llvm-toolchain-3.5-3.5/debian/liblldb-X.Y.links.in  2014-12-03 
03:14:56.0 +0100
@@ -1,5 +1,5 @@
 usr/lib/@DEB_HOST_MULTIARCH@/liblldb-@LLVM_VERSION@.so.1   
usr/lib/@DEB_HOST_MULTIARCH@/liblldb-@LLVM_VERSION@.so
 usr/lib/@DEB_HOST_MULTIARCH@/liblldb-@LLVM_VERSION@.so.1   
usr/lib/@DEB_HOST_MULTIARCH@/liblldb-@LLVM_VERSION@.so.1
+usr/lib/@DEB_HOST_MULTIARCH@/liblldb-@LLVM_VERSION@.so.1   
usr/lib/@DEB_HOST_MULTIARCH@/liblldb.so.1
 usr/lib/@DEB_HOST_MULTIARCH@/liblldb-@LLVM_VERSION@.so 
usr/lib/python2.7/dist-packages/lldb-@LLVM_VERSION@/_lldb.so
 usr/lib/@DEB_HOST_MULTIARCH@/liblldb-@LLVM_VERSION@.so.1   
usr/lib/llvm-@LLVM_VERSION@/lib/liblldb.so.1
-

Bug#771452: Duplicate object check

Hi,

Could you try if the attached patch fixes the problem? (You could do
that at the same time as the fsck.s3ql --debug run).

Best,
-Nikolaus

-- 
GPG encrypted emails preferred. Key id: 0xD113FCAC3C4E599F
Fingerprint: ED31 791B 2C5C 1613 AF38 8B8A D113 FCAC 3C4E 599F

 »Time flies like an arrow, fruit flies like a Banana.«
diff --git a/src/s3ql/backends/s3c.py b/src/s3ql/backends/s3c.py
--- a/src/s3ql/backends/s3c.py
+++ b/src/s3ql/backends/s3c.py
@@ -209,7 +209,7 @@
 log.debug('list(%s, %s): start', prefix, start_after)
 
 keys_remaining = True
-marker = start_after
+marker = self.prefix + start_after
 prefix = self.prefix + prefix
 ns_p = self.xml_ns_prefix

Bug#771868: evolution: CalDAV calendars marked "read-only" incorrectly, fixed upstream (bug #721712)

2014-12-02 Thread Rob Tomsick

Package: evolution
Version: 3.12.7-1
Severity: important

Dear Maintainer,

Currently, Evolution suffers from a bug whereby CalDAV calendars can be 
incorrectly marked as read-only, thus rendering them pretty much useless
for anyone who wants to add or modify events on a shared event.

This has been fixed upstream (bug #721712)  The actual fix can be
found at https://git.gnome.org/browse/evolution-data-server/commit/?id=8b2746f

Unfortunately, that fix has not been backported to jessie.

This is a serious problem for anyone who wants to use CalDAV on their
GNOME desktop with Jessie!

Thanks in advance!

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

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

Versions of packages evolution depends on:
ii  dbus   1.8.12-1
ii  debconf [debconf-2.0]  1.5.54
ii  evolution-common   3.12.7-1
ii  evolution-data-server  3.12.7.1-2
ii  gnome-icon-theme   3.12.0-1
ii  libatk1.0-02.14.0-1
ii  libc6  2.19-13
ii  libcamel-1.2-493.12.7.1-2
ii  libclutter-gtk-1.0-0   1.6.0-1
ii  libecal-1.2-16 3.12.7.1-2
ii  libedataserver-1.2-18  3.12.7.1-2
ii  libevolution   3.12.7-1
ii  libglib2.0-0   2.42.0-2
ii  libgtk-3-0 3.14.4-2
ii  libical1   1.0-1.1
ii  libnotify4 0.7.6-2
ii  libsoup2.4-1   2.48.0-1
ii  libwebkitgtk-3.0-0 2.4.7-2
ii  libxml22.9.1+dfsg1-4
ii  psmisc 22.21-2

Versions of packages evolution recommends:
ii  bogofilter 1.2.4+dfsg1-3
ii  evolution-plugins  3.12.7-1
ii  yelp   3.14.1-1

Versions of packages evolution suggests:
ii  evolution-ews   3.12.7-1
pn  evolution-plugins-experimental  
ii  gnupg   1.4.18-4
ii  network-manager 0.9.10.0-3

-- debconf information:
  evolution/needs_shutdown:
  evolution/kill_processes:


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

Bug#771391: libqt5multimedia5: QAudioDeviceInfo provides no audio devices on an alsa-only system without pulseaudio

2014-12-02 Thread Chris Ruvolo

tags 771391 + patch
thanks

I was able to track down the source of the problem and get alsa working.
The problem is that the plugins/alsa directory is not descended into and
built. This is an upstream problem as well.

I'm not sure if there is any negative consequence for pulseaudio users when
the alsa plugin is present, but after building and installing the alsa
plugin, audio now works when pulseaudio is not present.  If there ends up
being a negative consequence for pulseaudio users, there might be a need to
have separate pulseaudio and alsa plugin packages.

I had previously read that alsa is handled as "internal" and not a plugin.
That is not true for 5.3.2 at least.  There is no fallback in the code.
Every audio driver is loaded as a plugin.

Please see the attached patch and let me know if you have any questions.

Cheers.
-Chris
diff -ur qtmultimedia-opensource-src-5.3.2/debian/changelog qtmultimedia-opensource-src-5.3.2-patched/debian/changelog
--- qtmultimedia-opensource-src-5.3.2/debian/changelog	2014-11-09 21:16:04.0 -0500
+++ qtmultimedia-opensource-src-5.3.2-patched/debian/changelog	2014-12-02 17:22:45.902075641 -0500
@@ -1,3 +1,9 @@
+qtmultimedia-opensource-src (5.3.2-2~bpo70+2.1) wheezy-backports; urgency=medium
+
+  * Build alsa plugin in addition to pulseaudio.
+
+ -- Chris Ruvolo   Tue, 02 Dec 2014 17:22:12 -0500
+
 qtmultimedia-opensource-src (5.3.2-2~bpo70+2) wheezy-backports; urgency=medium
 
   * Update symbols files with buildds' logs.
diff -urN qtmultimedia-opensource-src-5.3.2/debian/patches/771391-build-alsa-plugin qtmultimedia-opensource-src-5.3.2-patched/debian/patches/771391-build-alsa-plugin
--- qtmultimedia-opensource-src-5.3.2/debian/patches/771391-build-alsa-plugin	1969-12-31 19:00:00.0 -0500
+++ qtmultimedia-opensource-src-5.3.2-patched/debian/patches/771391-build-alsa-plugin	2014-12-02 17:26:21.573750924 -0500
@@ -0,0 +1,28 @@
+Description: Build alsa plugin in addition to pulseaudio.
+ Even if pulse audio is present, we still want to build the alsa plugin.
+ .
+ qtmultimedia-opensource-src (5.3.2-2~bpo70+2.1) wheezy-backports; urgency=medium
+ .
+   * Build alsa plugin in addition to pulseaudio.
+Author: Chris Ruvolo 
+
+Bug-Debian: http://bugs.debian.org/771391
+Last-Update: 2014-12-02
+
+--- qtmultimedia-opensource-src-5.3.2.orig/src/plugins/plugins.pro
 qtmultimedia-opensource-src-5.3.2/src/plugins/plugins.pro
+@@ -38,7 +38,8 @@ unix:!mac:!android {
+ 
+ config_pulseaudio {
+ SUBDIRS += pulseaudio
+-} else:config_alsa {
++}
++config_alsa {
+ SUBDIRS += alsa
+ }
+ 
diff -ur qtmultimedia-opensource-src-5.3.2/debian/patches/series qtmultimedia-opensource-src-5.3.2-patched/debian/patches/series
--- qtmultimedia-opensource-src-5.3.2/debian/patches/series	2014-11-09 21:11:31.0 -0500
+++ qtmultimedia-opensource-src-5.3.2-patched/debian/patches/series	2014-12-02 17:24:38.437906259 -0500
@@ -1 +1,2 @@
 rpath_nonlinux.diff
+771391-build-alsa-plugin
diff -ur qtmultimedia-opensource-src-5.3.2/debian/libqt5multimedia5-plugins.install qtmultimedia-opensource-src-5.3.2-patched/debian/libqt5multimedia5-plugins.install
--- qtmultimedia-opensource-src-5.3.2/debian/libqt5multimedia5-plugins.install	2014-11-09 21:11:31.0 -0500
+++ qtmultimedia-opensource-src-5.3.2-patched/debian/libqt5multimedia5-plugins.install	2014-12-02 17:41:55.032341107 -0500
@@ -1,11 +1 @@
-usr/lib/*/qt5/plugins/audio/libqtmedia_pulse.so
-usr/lib/*/qt5/plugins/audio/libqtmedia_pulse.so
-usr/lib/*/qt5/plugins/mediaservice/libgstaudiodecoder.so
-usr/lib/*/qt5/plugins/mediaservice/libgstaudiodecoder.so
-usr/lib/*/qt5/plugins/mediaservice/libgstcamerabin.so
-usr/lib/*/qt5/plugins/mediaservice/libgstmediacapture.so
-usr/lib/*/qt5/plugins/mediaservice/libgstmediacapture.so
-usr/lib/*/qt5/plugins/mediaservice/libgstmediaplayer.so
-usr/lib/*/qt5/plugins/mediaservice/libgstmediaplayer.so
-usr/lib/*/qt5/plugins/playlistformats/libqtmultimedia_m3u.so
-usr/lib/*/qt5/plugins/playlistformats/libqtmultimedia_m3u.so
+usr/lib/*/qt5/plugins/*/*.so
diff -ur qtmultimedia-opensource-src-5.3.2/debian/qtmultimedia5-dev.install qtmultimedia-opensource-src-5.3.2-patched/debian/qtmultimedia5-dev.install
--- qtmultimedia-opensource-src-5.3.2/debian/qtmultimedia5-dev.install	2014-11-09 21:12:15.0 -0500
+++ qtmultimedia-opensource-src-5.3.2-patched/debian/qtmultimedia5-dev.install	2014-12-02 18:04:02.962408070 -0500
@@ -183,16 +183,7 @@
 usr/include/*/qt5/QtMultimediaWidgets/qtmultimediawidgetsversion.h
 usr/include/*/qt5/QtMultimediaWidgets/qvideowidget.h
 usr/include/*/qt5/QtMultimediaWidgets/qvideowidgetcontrol.h
-usr/lib/*/cmake/Qt5Multimedia/Qt5MultimediaConfig.cmake
-usr/lib/*/cmake/Qt5Multimedia/Qt5MultimediaConfigVersion.cmake
-usr/lib/*/cmake/Qt5Multimedia/Qt5Multimedia_CameraBinServicePlugin.cmake
-usr/lib/*/cmake/Qt5Multimedia/Qt5Multimedia_QGstreamerAudioDecoderServicePlugin.cmake
-usr/lib/*/cmake/Qt5Multimedia/Qt5Multimedia_QGstreamerCaptureServicePlugi

Bug#771867: nsd3 new version 3.2.16 - solves restart bugs

2014-12-02 Thread lambda

Package: nsd3
Version: 3.2.12-3+deb7u1

related to: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=660419
and https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=723639

I am experiencing sporadic restart failures on wheezy.

https://www.nlnetlabs.nl/bugs-script/show_bug.cgi?id=357

in combination with https://www.nlnetlabs.nl/bugs-script/show_bug.cgi?id=494

which lead to service nsd3 restart with exit code 0 but no running nsd.



These bugs are fixed in 3.2.16 but this version has not arrived in wheezy.

Is there any source for a .deb for this version or hope that it will arrive in 
wheezy?
(or maybe even 3.2.18)

Thanks :)

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

Bug#767037: Grub EFI fallback - patches for review

2014-12-02 Thread Steve McIntyre

On Tue, Dec 02, 2014 at 08:51:24AM +, Ian Campbell wrote:
>On Mon, 2014-12-01 at 13:57 +, Steve McIntyre wrote:
>
>grub-installer-rescue-UEFI-removable.patch:
>
>> diff --git a/debian/grub-installer.templates 
>> b/debian/grub-installer.templates
>> index e439ad0..a6af2ec 100644
>> --- a/debian/grub-installer.templates
>> +++ b/debian/grub-installer.templates
>> @@ -209,6 +209,21 @@ Type: text
>>  # :sl1:
>>  _Description: Updating /etc/kernel-img.conf...
>>  
>> +Template: grub-installer/progress/step_force_efi
>
>Perhaps add _removable at the end of the name?

Yeah, fair point.

>I didn't review the text since that seems to have been done already.
>
>> diff --git a/rescue.d/81grub-efi-force-removable 
>> b/rescue.d/81grub-efi-force-removable
>
>I don't know much about rescue mode, is this offering an automatic fixup
>for this issue? Does it appear in a menu to be selected rather than
>asking everyone booting rescue on an EFI system? 

The .tst file is run as a test:

[ -f /target/boot/grub/grub.cfg ] && ( grep -q /boot/efi /target/etc/fstab )

So, the target system must have grub installed and a mention of
/boot/efi in /etc/fstab. Assuming that it does, an extra rescue option
of "Force GRUB installation to the EFI removable media path" will show
up as an option for the user. If the user selects it, the help text in
grub-installer/force-efi-extra-removable is shown, then they can
select to set the option.

>
>> +mountvirtfs () {
>> +   fstype="$1"
>> +   path="$2"
>> +   if grep -q "[[:space:]]$fstype\$" /proc/filesystems && \
>> +  ! grep -q "^[^ ]\+ \+$path " /proc/mounts; then
>> +   mkdir -p "$path" || \
>> +   die grub-installer/mounterr "Error creating $path"
>> +   mount -t "$fstype" "$fstype" "$path" || \
>> +   die grub-installer/mounterr "Error mounting $path"
>> +   trap "umount $path" HUP INT QUIT KILL PIPE TERM EXIT
>
>trap doesn't stack, does it? You call mountvirtfs twice, so only the
>second umount will actually happen on error.

True. This (buggy) code is already in use elsewhere in grub-installer,
I've just borrowed it. :-/

>Also you umount explicitly on the exit path, but don't cancel this trap,
>so I guess you'll see some noise from umount the second time.

True; I've not seen any such errors, as it seems they're hidden at
that point.

>I know we've established that in-target isn't widely used in this
>particular bit of code -- but it does take care of all this sort of
>thing automatically and (presumably!) correctly, as well as being only a
>single place to fix if it is wrong (e.g. in-target handles BSD
>explicitly too).

Right. I've absolutely *no* idea how well any of the existing EFI
stuff will work with BSD...!

>> +log "Mounting filesystems"
>> +# If we're installing grub-efi, it wants /sys mounted in the
>> +# target. Maybe /proc too?
>> +mountvirtfs proc /target/proc
>> +mountvirtfs sysfs /target/sys
>> +chroot /target mount /boot/efi || true
>> +
>> +db_progress STEP 1
>> +db_progress INFO grub-installer/progress/step_install_loader
>> +# Do the installation now
>> +log "Running grub-install"
>> +if ! chroot /target grub-install --force-extra-removable; then
>
>The main invocation would invoke this with a --target="foo-efi". Not
>sure if this matters or not.

Nope, the code in grub-install already picks up on the right platform
by default. I could add this too, but I'm not convinved it's necessary.

>In order to avoid having to repeat all the logic twice perhaps you could
>arrange to do the debconf-set-selections thing first and then run
>dpkg-reconfigure or something in the target to force the main postinst
>to rerun and reinstall?

Maybe, yeah. I'll take a look.

>> +   db_input critical grub-installer/grub-install-failed || true
>> +   db_go || true
>> +   db_progress STOP
>> +   exit 1
>
>You don't umount /target/boot/efi on this path.

Correct, and that's definitely wanted.

-- 
Steve McIntyre, Cambridge, UK.st...@einval.com
< Aardvark> I dislike C++ to start with. C++11 just seems to be
handing rope-creating factories for users to hang multiple
instances of themselves.


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

Bug#767037: Grub EFI fallback - patches for review

2014-12-02 Thread Steve McIntyre

On Tue, Dec 02, 2014 at 08:36:31AM +, Ian Campbell wrote:
>On Mon, 2014-12-01 at 13:57 +, Steve McIntyre wrote:
>
>Starting with grub-install-fallback.patch:
>
>> >From e384e597914b6e1b1dcbf96ef6782cf9bcc2313b Mon Sep 17 00:00:00 2001
>>  debian/patches/grub-install-extra-removable.patch | 115 
>> ++
>
>Could you send this to grub-de...@gnu.org? Or at least provide a commit
>log for the upstream bit inline in the patch for whoever does end up
>forwarding it.

Sure, no problem. I've added a header for now. As my stuff is
intermingled with other changes in the Debian tree, I'm not sure how
well that will work upstream...

>> +@@ -829,6 +838,27 @@ fill_core_services (const char *core_ser
>> +   free (sysv_plist);
>> + }
>> + 
>> ++static void
>> ++also_install_removable(const char *src, const char *base_efidir, const 
>> char *efi_suffix_upper)
>> ++{
>> ++  char *efi_file = NULL;
>> ++  char *dst = NULL;
>> ++  char *dir = NULL;
>> ++  
>> ++  if (!efi_suffix_upper)
>> ++grub_util_error ("%s", _("You've found a bug"));
>
>There are one or two of these in the upstream code base already, but it
>is a bit unfriendly to the bug-reported/triagger.
>
>I see an existing instance of
>_("you found a bug ... (%s:%d)\n"), file, line)
>which is a bit nicer at least. Plain old assert() sees some usage too.

OK. Again, I was just following the surrounding (grotty) style. :-)
I'll tweak.

>The Debian-specific bits all look sensible to me, FWIW. There will be a
>minor conflict with the patches in #770412 but nothing insurmountable.

Cool, ta!

>> [...]
>> + also depend on this path. If so, uou will need to ensure that GRUB is
>
>Typo: "uou".

ACK, already fixed after KiBi's feedback.

Rebased patch V2 against current git master attached...

-- 
Steve McIntyre, Cambridge, UK.st...@einval.com
"The problem with defending the purity of the English language is that
 English is about as pure as a cribhouse whore. We don't just borrow words; on
 occasion, English has pursued other languages down alleyways to beat them
 unconscious and rifle their pockets for new vocabulary."  -- James D. Nicoll
>From a863157a9020edfb6d1fa8379703026cd86c45c9 Mon Sep 17 00:00:00 2001
From: Steve McIntyre 
Date: Wed, 3 Dec 2014 01:51:57 +
Subject: [PATCH] Add support for forcing EFI installation to the removable
 media path

Add an extra option to grub-install "--force-extra-removable". On EFI
platforms, this will cause an extra copy of the grub-efi image to be
written to the appropriate removable media patch
/boot/efi/EFI/BOOT/BOOT$ARCH.EFI as well. This will help with broken
UEFI implementations where the firmware does not work when configured
with new boot paths.

Also added new debconf logic to add this extra option to grub-install
calls when grub2/force_efi_extra_removable is set true. This allows
other programs like d-i / grub-installer to configure this for general
use.

Provides part of the fix for #767037
---
 debian/changelog  |   8 ++
 debian/config.in  |   1 +
 debian/patches/grub-install-extra-removable.patch | 133 ++
 debian/patches/series |   1 +
 debian/postinst.in|   6 +-
 debian/templates.in   |  11 ++
 6 files changed, 159 insertions(+), 1 deletion(-)
 create mode 100644 debian/patches/grub-install-extra-removable.patch

diff --git a/debian/changelog b/debian/changelog
index f0eac36..70dd9aa 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,11 @@
+grub2 (2.02~beta2-18) UNRELEASED; urgency=medium
+
+  [ Steve McIntyre ]
+  * Add support for forcing an extra copy of grub-efi to the removable
+media path /boot/efi/EFI/BOOT/BOOT$ARCH.EFI (#767037)
+
+ -- Steve McIntyre <93...@debian.org>  Wed, 03 Dec 2014 01:23:18 +
+
 grub2 (2.02~beta2-17) unstable; urgency=medium
 
   [ Colin Watson ]
diff --git a/debian/config.in b/debian/config.in
index fcc0dd4..d2afbcb 100644
--- a/debian/config.in
+++ b/debian/config.in
@@ -73,4 +73,5 @@ esac
 
 db_input ${priority} grub2/linux_cmdline || true
 db_input medium grub2/linux_cmdline_default || true
+db_input low grub2/force_efi_extra_removable || true
 db_go
diff --git a/debian/patches/grub-install-extra-removable.patch b/debian/patches/grub-install-extra-removable.patch
new file mode 100644
index 000..693e885
--- /dev/null
+++ b/debian/patches/grub-install-extra-removable.patch
@@ -0,0 +1,133 @@
+From: Steve McIntyre <93...@debian.org>
+Date: Wed, 3 Dec 2014 01:25:12 +
+Subject: Add support for forcing EFI installation to the removable media path
+
+Add an extra option to grub-install "--force-extra-removable". On EFI
+platforms, this will cause an extra copy of the grub-efi image to be
+written to the appropriate removable media patch
+/boot/efi/EFI/BOOT/BOOT$ARCH.EFI as well. This will help with broken
+UEFI imp

Bug#771604: tracker.debian.org: short description contains long description

2014-12-02 Thread Paul Wise

On Wed, Dec 3, 2014 at 2:24 AM, Christophe Siraut wrote:

> You are right, we should use the escape template filter (or possibly
> an autoescape tag on the first part of that template).

Django does that automatically according to this:

https://docs.djangoproject.com/en/dev/topics/templates/

-- 
bye,
pabs

https://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#760314: #760314: RFH: zoneminder maintenance in Debian

2014-12-02 Thread Vagrant Cascadian

On 2014-11-25, Vagrant Cascadian wrote:
> On 2014-11-25, Peter Howard wrote:
>> we should start using a git repo for the debian-specific work.
>> Vagrant - can you set up a git repo for ZM and clone from ZM upstream?
>> We can then bring over the debian directory, apply the recent NMU
>> patches, and make that the basis for further work.
>
> Yeah, I can migrate it over to git, and at least preserve some of the
> history. I've actually been using git-remote-hg lately, but the
> histories of the repositories are different... but I can probably get
> them both into one repository, even if I have to use a hammer.

Ok, hammered them together using "git merge -X theirs v1.28.0" followed
up with removing files not present upstream (other than the debian dir,
obviously), and uploaded the repository to collab-maint git. There were
a few upstream tags that conflicted with the tags generated from
mercurial, I kept the upstream ones.

Isaac, you'll want to get an alioth account and get yourself added to
the collab-maint group:

  https://alioth.debian.org/account/register.php
  https://wiki.debian.org/Alioth/PackagingProject

When you've got an account, I can send the mail to NM.

Information about accessing alioth git repositories:

  https://wiki.debian.org/Alioth/Git

The repository should be available here, once it's done syncing:

  git clone git://git.debian.org/git/collab-maint/zoneminder.git

Web frontend:

  https://anonscm.debian.org/cgit/collab-maint/zoneminder.git/  

>> I'd say we branch from the 1.28 release and then make a _quick_ upload
>> of that, then work on a "nice" version.  Vagrant, if you're around to do
>> the actual upload, I'll coordinate with Isaac to get him going with the
>> debian-specific builds.
>
> I'm also happy to help with packaging and sponsoring the occasional
> upload.

I didn't update the packaging to 1.28.0, but the master branch on alioth
has 1.28.0 upstream merged in. Not sure how much work it will be to
update the packaging, but happy to help.

Also, might want to consider some of the proposed naming conventions
laid out in:

  http://dep.debian.net/deps/dep14/

Thanks for helping out with zoneminder!

live well,
  vagrant

signature.asc
Description: PGP signature

Bug#771866: megaglest-data: orig-source.tar.xz is missing from the source package

2014-12-02 Thread Paul Wise

Source: megaglest-data
Version: 3.9.1-1
Severity: serious

The previous version of megaglest-data (3.7.1-1) included an
orig-source.tar.xz tarball but this version does not.

http://snapshot.debian.org/package/megaglest-data/3.7.1-1/
http://snapshot.debian.org/package/megaglest-data/3.9.1-1/

The orig-source.tar.xz corresponded to the upstream
megaglest-data-source tarball and repository.

https://github.com/MegaGlest/megaglest-data-source
https://github.com/MegaGlest/megaglest-data-source/releases/download/3.7.1/megaglest-data-source-3.7.1.tar.xz
https://github.com/MegaGlest/megaglest-data-source/releases/download/3.9.1/megaglest-data-source-3.9.1.tar.xz

The megaglest-data-source repository contains the source data needed to
build the pre-built data in the megaglest-data repository. We don't
rebuild from the source data because the process consumes a lot of
resources/time but we should be distributing the source data for users
who want to customise and rebuild the data from source.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise



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

Bug#767367: nvidia-opencl-icd dependencies

On 2014-12-02 22:36, Rebecca N. Palmer wrote:
>> what would happen to
>> an Nvidia-hardware-only system with nvidia kernel module (which
>> blacklists the nouveau kernel module) + nouveau graphics userspace,
>> which under [nvidia-kernel-dkms Recommends: nvidia-driver | libcuda1]
>> would be the result of trying to install OpenCL on
>> a previously nouveau-using system.
> 
> Did you test this (i.e. "apt-get install nvidia-opencl-icd libcuda1"
> with Nvidia hardware but no already-installed *nvidia* packages)?
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=751082#27 suggests the
> result is no graphics.
> 
> (Having it be a Recommends: nvidia-driver rather than a hard Depends
> already allows the "headless GPGPU" case, and cutting nvidia-opencl-icd
> -> libcuda1 is enough to fix the original "accidental nvidia-opencl-icd
> on inappropriate hardware" problem.)
> 
> ___
> pkg-nvidia-devel mailing list
> pkg-nvidia-de...@lists.alioth.debian.org
> http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-nvidia-devel

# apt-get install --install-recommends nvidia-opencl-icd libcuda1
Reading package lists... Done
Building dependency tree   
Reading state information... Done
The following extra packages will be installed:
  cpp-4.8 dkms gcc-4.8 glx-alternative-mesa glx-alternative-nvidia 
glx-diversions kmod libasan0 libgcc-4.8-dev libkmod2 libnvidia-compiler 
libnvidia-ml1 linux-compiler-gcc-4.8-x86 linux-headers-3.16.0-4-amd64
  linux-headers-3.16.0-4-common linux-headers-amd64 linux-kbuild-3.16 menu 
nvidia-alternative nvidia-installer-cleanup nvidia-kernel-common 
nvidia-kernel-dkms nvidia-modprobe nvidia-opencl-common nvidia-smi
  nvidia-support ocl-icd-libopencl1
Suggested packages:
  gcc-4.8-locales gcc-4.8-multilib gcc-4.8-doc libgcc1-dbg libgomp1-dbg 
libitm1-dbg libatomic1-dbg libasan0-dbg libtsan0-dbg libquadmath0-dbg 
libgl1-mesa-glx libgl1 nvidia-driver nvidia-cuda-mps menu-l10n gksu
  kde-runtime ktsuss opencl-icd
Recommended packages:
  linux-image libcuda1-i386
The following NEW packages will be installed:
  cpp-4.8 dkms gcc-4.8 glx-alternative-mesa glx-alternative-nvidia 
glx-diversions kmod libasan0 libcuda1 libgcc-4.8-dev libkmod2 
libnvidia-compiler libnvidia-ml1 linux-compiler-gcc-4.8-x86
  linux-headers-3.16.0-4-amd64 linux-headers-3.16.0-4-common 
linux-headers-amd64 linux-kbuild-3.16 menu nvidia-alternative 
nvidia-installer-cleanup nvidia-kernel-common nvidia-kernel-dkms nvidia-modprobe
  nvidia-opencl-common nvidia-opencl-icd nvidia-smi nvidia-support 
ocl-icd-libopencl1
0 upgraded, 29 newly installed, 0 to remove and 0 not upgraded.
Need to get 20.3 MB/37.4 MB of archives.
After this operation, 136 MB of additional disk space will be used.

@@@ doing this in a sid chroot ...

# update-alternatives --display nvidia 
nvidia - auto mode
  link currently points to /usr/lib/nvidia/current
/usr/lib/nvidia/current - priority 340
  slave nvidia--libcuda.so-x86_64-linux-gnu: 
/usr/lib/x86_64-linux-gnu/nvidia/current/libcuda.so
  slave nvidia--libcuda.so.1-x86_64-linux-gnu: 
/usr/lib/x86_64-linux-gnu/nvidia/current/libcuda.so.1
  slave nvidia--libnvidia-ml.so.1-x86_64-linux-gnu: 
/usr/lib/x86_64-linux-gnu/nvidia/current/libnvidia-ml.so.1
  slave nvidia--libnvidia-opencl.so.1-x86_64-linux-gnu: 
/usr/lib/x86_64-linux-gnu/nvidia/current/libnvidia-opencl.so.1
  slave nvidia--nvidia-modprobe.conf: /etc/nvidia/nvidia-modprobe.conf
  slave nvidia--nvidia-smi: /usr/lib/nvidia/current/nvidia-smi
  slave nvidia--nvidia-smi.1.gz: /usr/lib/nvidia/current/nvidia-smi.1.gz
Current 'best' version is '/usr/lib/nvidia/current'.

@@@ as expected

# update-alternatives --display glx
update-alternatives: error: no alternatives for glx

@@@ Oops, let's install X, too

# apt-get install --install-recommends xserver-xorg

# update-alternatives --display glx
glx - auto mode
  link currently points to /usr/lib/mesa-diverted
/usr/lib/mesa-diverted - priority 5
  slave glx--libEGL.so.1-x86_64-linux-gnu: 
/usr/lib/mesa-diverted/x86_64-linux-gnu/libEGL.so.1
  slave glx--libGL.so.1-x86_64-linux-gnu: 
/usr/lib/mesa-diverted/x86_64-linux-gnu/libGL.so.1
Current 'best' version is '/usr/lib/mesa-diverted'.

@@@ as expected

nouveau is not blacklisted ... the kernel module would probably get loaded by a 
cuda application

Interesting testcase, need to think more about it. For stretch :-)

There is a lever missing here to enable/disable nvidia.
/etc/modules-load.d/ may be useful :-)

And probably a new utility needs to be written to switch the system into any of 
these (proprietary) gpu modes:
* none (xorg,mesa only)
* nvidia native
* nvidia optimus
* fglrx native
* fglrx the-thing-that-is-equivalent-to-optimus
* bumblebee whatever

It must be possible to have *all* installed at the same time and to switch 
between them without package removal (since only one can be active at a time).
(and we have at least 2 different nvidia drivers available, more likely 3: 
current, 340xx, 304

Bug#770636: RFS: gitinspector/0.3.2+dfsg-1 [ITP]

2014-12-02 Thread Christian Kastner

On 2014-12-02 18:42, Andrey Rahmatullin wrote:
> On Sat, Nov 22, 2014 at 09:56:33PM +0100, Christian Kastner wrote:
>>   dget -x
>> http://mentors.debian.net/debian/pool/main/g/gitinspector/gitinspector_0.3.2+dfsg-1.dsc
>>
>> Changes since the last upload:
>>
>>   * Initial release. Closes: #768508
> Uploaded, thanks! I didn't tag this in SVN because
> Add-missing-HTML-footer-to-htmlembedded-output.patch is newer in the
> mentors package, please commit it and tag.

Ow. Apparently I added an Applied-Upstream header to the patch, but
forgot to commit that.

Corrected, then tagged.

Thank you very much for sponsoring gitinspector and python-cachetools!

Christian


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

Bug#718596: [Pkg-bluetooth-maintainers] Bug#718596: (no subject)

2014-12-02 Thread Nobuhiro Iwamatsu

Hi,

obexd is already obsolete. Also different because API can not be used
in GNOME, KDE and other.
Please use the bluez-obexd instead.

Best regards,
  Nobuhiro

2014-11-25 20:13 GMT+09:00 Habib Seifzadeh :
> Hi,
>
> I want to confirm that downgrading to 0.46 version did not solve the problem
> in my Debian Jessie. To downgrade, I downloaded the deb file of the 0.46
> version and installed it using "dpkg -i packagename". Is it right?
>
> Thanks,
> Habib
>
> ___
> Pkg-bluetooth-maintainers mailing list
> pkg-bluetooth-maintain...@lists.alioth.debian.org
> http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-bluetooth-maintainers



-- 
Nobuhiro Iwamatsu
   iwamatsu at {nigauri.org / debian.org}
   GPG ID: 40AD1FA6


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

Bug#764863: kino: theora export fails with "ffmpeg2theora: invalid option -- 'S'"

2014-12-02 Thread Paul Brossier

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On 11/10/2014 13:28, Julien Cristau wrote:
> Package: kino Version: 1.3.4-2.1+b1 Severity: important
> 
> I can't seem to export to theora, getting the error from $subject
> on stderr, followed by: WARNING: Only one input file supported,
> others will be ignored
> 
> File `1' does not exist or has an unknown format.
> 
> To make things worse the gui doesn't give any indication that 
> something's gone wrong, just says "Export finished".

hi,

unfortunately, it seems that I wont be able to look at this in the
next few weeks.

it would be great if someone could NMU it.

cheers, Paul
-BEGIN PGP SIGNATURE-

iQJ8BAEBCgBmBQJUflaqXxSAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w
ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRCODhBNTA3MkQ0OTE1QUVDRjgxQTI0MzQ2
QTQ5QjE5NzI4QUJERDkyAAoJEGpJsZcoq92S+IkP/1q6sYXsUCqI9a8airJve05t
ayXM1fwO//pq9SNSmEGKKkIkLUK2k1XGH2KvMKMJVCbrF1sPv2H/KQtwQlL/ivb3
+jTL0OEWbtcrOjLy71WBNI2+Sp6AB3M444rvlLvnx6nckimC0Pvz5sj2Tgg01Ej/
nEleLTKlSNH+sK+xtUybQ0j/+aNYwfuvAQpgopOxUgGPKIkb6tj5OqTJjBZ6/Vlo
hLCMkQHmFdOTbAwfRLQUnhVn77f5vbvHnMr0eLq851sO0l6/aH9OeJ3ESbDzGI1A
8oKniYqMKKjYk3ehn4tcUr21/vq76kgylVX9f3ofSnIxrsw2UuCOBYqXhReMPMKt
vU4UUShabYT6pIGpsrANzZBjDcopxEwyjzgcCmGZAIkPupri/6f4IlEO6RSZjGcm
mcxl2EzoZbbx0fDAw9MQmkgR4oI4FIYEFGeZW4nLNNBUQ6dE7rXA2+ijqXZZLTIx
LyGfmZH/jKYK6dXSo6NTNC897fl4HnYDxqW09PJVP1im9etu7EoWPcSCNeQzhmb0
JMniXRfhx69ffgZVb65522CFhQ8UkELuCxdficbUaZPVPmfNyOgNLBfLauH4QUwl
XmFs3HBLxLtNkgn4d4+xS6CrOLMzZyvVL9FaiO+xKzBr8gjoNJRdKCjw269CYTU9
+91GgwW2BMSNI9AZFD3d
=BebP
-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#771084: Unblock: pcl/1.7.2-4/1.7.2-5/1.7.2-6

2014-12-02 Thread Nobuhiro Iwamatsu

Hi,

I just upload.

Best regards,
  Nobuhiro

2014-12-02 21:34 GMT+09:00 Leopold Palomo-Avellaneda :
> A Dilluns, 1 de desembre de 2014, Niels Thykier va escriure:
>>
>> Can you have it done by the end of the week?
>
> Nobuhiro,
>
> please, new version without the --parallel
>
> Could you make a new upload?
>
> http://mentors.debian.net/package/pcl
>
> Leo
>
> --
> --
> Linux User 152692 GPG: 05F4A7A949A2D9AA
> Catalonia
> -
> A: Because it messes up the order in which people normally read text.
> Q: Why is top-posting such a bad thing?
> A: Top-posting.
> Q: What is the most annoying thing in e-mail?



-- 
Nobuhiro Iwamatsu
   iwamatsu at {nigauri.org / debian.org}
   GPG ID: 40AD1FA6


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

Bug#771452: Duplicate object check

On 12/02/2014 03:35 PM, Nikolaus Rath wrote:
> Not to fsck.s3ql, but the attached patch should enable traffic dumping
> on the lower-level dugong library. It creates files "raw_stream_xx.dat"
> in the current directory. Could you give that a shot and attach both the
> results for an ssl and no-ssl run?

Got the dump file via separate mail, thanks!

I think I have found the bug. When using SSL, S3QL has to re-establish the 
connection while retrieving objects. After reconnecting, it starts retrieving 
from wrong key.

The last requests with the first connection are:

GET 
/?prefix=server-externals3ql_data_&marker=server-externals3ql_data_188293&max-keys=1000
 HTTP/1.1
GET 
/?prefix=server-externals3ql_data_&marker=server-externals3ql_data_189193&max-keys=1000
 HTTP/1.1
GET 
/?prefix=server-externals3ql_data_&marker=server-externals3ql_data_190092&max-keys=1000
 HTTP/1.1

but then the new connection continues with

GET /?prefix=server-externals3ql_data_&marker=s3ql_data_190092&max-keys=1000 
HTTP/1.1

In contrast, when not using SSL the connection does not have to be 
re-established, so everything works fine.

I should be able to fix the bug now.

I'm curious why the connection has to be re-established when using SSL though. 
Would you mind to run fsck.s3ql one more time, this time with --debug, and 
attach the entries from ~/.s3ql/fsck.log? 

Best,
-Nikolaus

-- 
GPG encrypted emails preferred. Key id: 0xD113FCAC3C4E599F
Fingerprint: ED31 791B 2C5C 1613 AF38 8B8A D113 FCAC 3C4E 599F

 »Time flies like an arrow, fruit flies like a Banana.«

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

Bug#771794: pip silently removes/updates system provided python packages

2014-12-02 Thread Donald Stufft

> On Dec 2, 2014, at 6:32 PM, Scott Kitterman  wrote:
> 
> Assuming the maintainer doesn't decide to downgrade the bug (which I think is 
> unlikely and a number of people would object to, so I think we can ignore it 
> as a possibility), the decision to ignore the bug for Jessie belongs with the 
> release team.  If we choose not to fix it (and there's no Non-Maintainer 
> Upload), then they will decide to either remove the package or ignore the bug.
> 
> Since this particular issue is release critical, the December 5th deadline 
> isn't relevant to a targeted fix just for this issue.
> 
> Scott K

So the issue here is that pip is removing apt “owned” files implicitly during
an upgrade right? Looking at easy_install there’s no Serious bug there and the
primary difference between what will happen if you easy_install something and
pip install something is that pip might remove files from /usr/lib. In both
cases the items installed by both solutions will be in /usr/local/lib.

So what if Debian just patched python-pip so that it doesn’t remove the files
from /usr/lib (but it would remove files from /usr/local etc). This would have
the effect of pip not touching dpkg owned files which would bring it in line
with that easy_install does. /usr/local/lib takes precedence over /usr/lib so
it won’t break things for people actually trying to install things to 
/usr/local.

There *might* be some edge cases that occurs with having two versions of a 
package
on sys.path, but I can’t think of any offhand (and either way, those edge cases
already exist if someone does
``apt-get install python-requests && pip install —upgrade requests`` and then 
later
on Debian releases a new update to python-requests since those files that pip
removed will get reinstalled in that situation.

That should fix the immediate problem this bug addresses and then we can figure 
out
a longer term “real” fix in upstream pip that can go into Jessie+1.

---
Donald Stufft
PGP: 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA

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

Bug#771857: 771857

On Tue, 02 Dec 2014 at 19:20:22 -0500, Brian Minton wrote:
> Update: That did not in fact fix the problem.  I had removed the gpg2 line
> from the config file.  When I put it back in, it still gives the message.

I just pushed a fix (r741) for the branches 1.4 and 2.0 of GnuPG.  The
2.1 branch has a different keystore and will have to wait :-P

-- 
Guilhem.

signature.asc
Description: Digital signature

Bug#771857: 771857

2014-12-02 Thread Brian Minton

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Update: That did not in fact fix the problem.  I had removed the gpg2 line
from the config file.  When I put it back in, it still gives the message.
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iF4EARYIAAYFAlR+VxoACgkQN7lQes/yAW69ugEAY2cc3vqW6ao2M0vi7aFXFm0V
9OnzT69PDIfIBqsRv/cBAPs3JPpT1Lf3ZpU9lWu7JjFcKc9seiOCdFved4mzfwMC
iF4EAREIAAYFAlR+VxoACgkQa46zoGXPuql0nQD8DXEjInQ8iSFsdcG6JjZ/T5m/
qtoT4nPWppmsHWU3rpcA/2PdNQqtjF8udd0ApFRDcLpzNaXmqNFc610kJe6uZsgS
=RHsl
-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#771857: signing-party: using gpg2, signing is skipped with 'No secret key'

2014-12-02 Thread Brian Minton

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256


On Tue, Dec 2, 2014 at 6:30 PM, Guilhem Moulin  wrote:
> caff uses the default secret keyring (configurable with
> $CONFIG{'secret-keyring'}) but has its own public keyring.  Right now
> only $CONFIG{'keyid'} is imported from the normal public keyring.  Is
> 0424DC19B678A1A9 the key used as $CONFIG{'keyid'} in your .caffrc?

yes

> If
> not, can you try
>
> gpg --export 0424DC19B678A1A9 | gpg --homedir=$HOME/.caff/gnupghome
- --import
>

That did indeed fix the problem.

> If that fixes the problem, I've got a proper fix ready ;-)
>
> Cheers,
> --
> Guilhem.
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iF4EARYIAAYFAlR+U/0ACgkQN7lQes/yAW6+cQEAEhHB3+Lkc2wiDbGiUUkXyxLU
y4PaDJ5W4oBPErNL20EBAFENz+RxyIjvEOJfu7oQGtx1RZGK7ut/KLcX81Q623gJ
iF4EAREIAAYFAlR+U/0ACgkQa46zoGXPuqmDugD+IQcTwu6MmF5mVYOjq4Y3kkgq
Lwyl6FrGTmKZtpnLUGcA/3VMzVm46SxLNYMg6muUhU/aPZNWofumtNsYeEQI/xNp
=8WIU
-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#771461: /var/state/samhain/

2014-12-02 Thread Javier Fernández-Sanguino Peña

On Tue, Dec 02, 2014 at 01:23:13AM +0100, Andrea Claudi wrote:
> Hi,
> This patch should fix the problem, moving the non-volatile state for the 
> samhain package to /var/lib/samhain.

The patch creates the directory for new installations but it is worth
noticing that the /var/state/samhain/ contains valid information that
has to be preserved over upgrades (otherwise, the integrity database would be
regenerated and not kept).

> Please, tell me if I need to fix something to make this acceptable.

I'm committing your patch to Samhain's GIT but have made some adjustments. I
will test upgrades from previous versions and if all goes well I'll upload
a new package soon.

Regards

Javier

signature.asc
Description: Digital signature

Bug#771834: [PKG-OpenRC-Debian] Bug#771834: [openrc] Frightening warning in README.Debian

2014-12-02 Thread Manolo Díaz

On Wednesday, Dec 3 2014 at 00:31 (UTC+1),
Thomas Goirand wrote:

>On 12/03/2014 02:07 AM, Manolo Díaz wrote:
>> Package: openrc
>> Version: 0.13.1-4
>> Severity: normal
>> 
>> Dear maintainer,
>> 
>> README.Debian file reads:
>> 
>>  "This package is EXPERIMENTAL.  Installing it could make your
>>  system UNBOOTABLE.  Only use this package for testing purposes
>>  in a virtual machine, unless you are very brave!"
>> 
>> If still valid, that frightening warning should be available before
>> installing the package. In the package description, e.g. 
>> 
>> Otherwise, please update that file.
>
>Hi,
>
>I don't think this is still valid, and a recent Git commit has already
>removed it on our repository.
>
>Thomas Goirand (zigo)


All right. Thanks a lot for your quick response.

-- 
Manolo Díaz


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

Bug#771865: unblock: eztrace/1.0.6-3

2014-12-02 Thread Samuel Thibault

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

unblock eztrace/1.0.6-3

Hello,

I have uploaded to unstable the attached changes, which quite obviously
fix a very likely crash of eztrace, notably when MALLOC_PERTURB_ is set:
in that case the allocated buffer is full of non-zeroes, and thus the
first strcat below will overrun the buffer.

Samuel

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

Kernel: Linux 3.17.0 (SMP w/8 CPU cores)
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash

-- 
Samuel
"I don't know why, but first C programs tend to look a lot worse than
first programs in any other language (maybe except for fortran, but then
I suspect all fortran programs look like `firsts')"
(By Olaf Kirch)
diff -Nru eztrace-1.0.6/debian/changelog eztrace-1.0.6/debian/changelog
--- eztrace-1.0.6/debian/changelog  2014-11-24 14:44:10.0 +0100
+++ eztrace-1.0.6/debian/changelog  2014-12-02 22:56:58.0 +0100
@@ -1,3 +1,9 @@
+eztrace (1.0.6-3) unstable; urgency=medium
+
+  * patches/git-ebe444a: Cherry-pick from upstream to fix uninitialized value.
+
+ -- Samuel Thibault   Tue, 02 Dec 2014 22:56:57 +0100
+
 eztrace (1.0.6-2) unstable; urgency=medium
 
   [ Peter Michael Green ]
diff -Nru eztrace-1.0.6/debian/patches/git-ebe444a 
eztrace-1.0.6/debian/patches/git-ebe444a
--- eztrace-1.0.6/debian/patches/git-ebe444a1970-01-01 01:00:00.0 
+0100
+++ eztrace-1.0.6/debian/patches/git-ebe444a2014-12-02 22:55:48.0 
+0100
@@ -0,0 +1,18 @@
+commit ebe444a2b5f1e5e9dabee2f4c3c8dd1db866e826
+Author: François Trahay 
+Date:   Tue Dec 2 17:10:03 2014 +0100
+
+fix a possible memory corruption bug
+
+diff --git a/src/core/eztrace.c.in b/src/core/eztrace.c.in
+index 00d53d2..be4fffb 100644
+--- a/src/core/eztrace.c.in
 b/src/core/eztrace.c.in
+@@ -170,6 +170,7 @@ int main(int argc, char **argv) {
+ arg_length += strlen(argv[nb_opts + 2 + i]) + 10;
+   }
+   char *args_concat = malloc(sizeof(char) * (arg_length + 1));
++  args_concat[0]='\0';
+ 
+   for (i = 0; i < nb_args; i++) {
+ strcat(args_concat, argv[nb_opts + 2 + i]);
diff -Nru eztrace-1.0.6/debian/patches/series 
eztrace-1.0.6/debian/patches/series
--- eztrace-1.0.6/debian/patches/series 2014-11-24 13:23:57.0 +0100
+++ eztrace-1.0.6/debian/patches/series 2014-12-02 22:57:08.0 +0100
@@ -5,3 +5,4 @@
 git-8be2d52dfe03a75160aa33531a52d5f2257a
 git-0cb79edc3411c0e04e411d7c8f60a6596632a4ea
 no-armv7.patch
+git-ebe444a

Bug#728345: dianara: Memory usage (leak?)

2014-12-02 Thread Jan

Hola! Thanks for investigating this! However...

On Tue, Dec 02, 2014 at 07:47:44PM +0100, gregor herrmann wrote:
> >   PID USER  PRI  NI  VIRT   RES   SHR S CPU% MEM%   TIME+  Command
> > 23560 gregoa 20   0 1738M 1055M 13332 S  0.0 27.4  0:16.46 dianara
> > 20806 gregoa 20   0 1268M  382M 58028 S  0.0 10.0 48:56.15 iceweasel
> 
> ¡Hola Mònica, hola Jan!
> 
> This looks better, doesn't it :)
> 
>   PID USER  PRI  NI  VIRT   RES   SHR S CPU% MEM%   TIME+  Command
> 31723 gregoa 20   0  556M 60748 19616 S  0.0  1.5 12:30.11 ./dianara
>  5789 gregoa 20   0 1752M  628M 44124 S  4.8 16.4  2h13:06 iceweasel
> 

It looks a lot better! 
Does this difference apply to similar usage, with same number of posts
per page, same update interval and running for a similar amount of time?
Even so, memory usage depends greatly on what's in the posts, of course.

But you also say that now the memory usage stays constant, so it sounds
very promising =)

> With the help of a friend and qtcreator's nice valgrind integration I
> created a patch which adds parents to some objects (so that they are
> auto-reaped) or manually deletes them.
> 
> No guarantees that all parts of the patch are necessary or correct
> but with it dianara is "valgrind clean" and the memory usage stays
> constant even after running for several days.
> 
> The patch applies against git HEAD as of now (d520e57); I hope it
> serves as a starting point to get the memory leaks fixed.
> 

I find it a little strange that it really fixes things, mainly because,
from what I've seen by giving it a quick look, the fixes are mostly
specifying the parents of several objects, and manually deleting others.

The reason those objects (at least, most of them) don't have a parent
set, is because they're re-parented when they're managed by a QLayout.
There's of course, the possibility of Qt bugs and that not being handled
correctly. The same applies to the manual deletion of some widgets in
Comment(); those are supposed to be properly deleted automatically when
the parent Comment() object is destroyed.

There are also a few objects which will live as long as the program does,
so those are not really a concern either way (tray icon, menus, qoauth
handler...).

I'll investigate, thanks again!

Cheers! o/

> 
> Cheers,
> gregor
> 
> -- 
>  .''`.  Homepage: http://info.comodo.priv.at/ - OpenPGP key 0xBB3A68018649AA06
>  : :' : Debian GNU/Linux user, admin, and developer  -  http://www.debian.org/
>  `. `'  Member of VIBE!AT & SPI, fellow of the Free Software Foundation Europe
>`-   

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

Bug#771789: [pcp] Bug#771789: libpcp-pmda-perl: uninstallable on i386: depends on perlapi-5.18.2

2014-12-02 Thread Nathan Scott

Hi Jakub,

- Original Message -
> [...]
> The following packages have unmet dependencies:
>  libpcp-pmda-perl : Depends: perlapi-5.18.2 but it is not installable
> E: Unable to correct problems, you have held broken packages.

Oh, I have an outdated perl installation here - have upgraded it now,
will be fixed by the next upload.  Thanks!

--
Nathan


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

Bug#771452: Duplicate object check

On 12/02/2014 02:20 PM, Shannon Dealy wrote:
> On Tue, 2 Dec 2014, Shannon Dealy wrote:
> 
> [snip]
>> I performed a capture as requested, ...
> 
> Sorry Nikolaus,
> 
> I have deleted that file from where I posted it.
> 
> I made a mistake, that file was captured with ssl enabled.  In fact, it
> appears based on a limited sample, that fsck.s3ql fails 100% of the time
> when ssl is enabled (35+ runs), and succeeds 100% of the time when ssl
> is disabled (6 runs so far).  I don't know if this is a generic work
> around, or if it just happens to work this way for my particular data set.

Looks like a pattern, thanks a lot for all the tests!

> Given the above, there is no way I can provide you with a "no-ssl"
> version of the captured data (since it always succeeds).  Could you make
> a patch to fsck.s3ql which would provide you with the required data?  

Not to fsck.s3ql, but the attached patch should enable traffic dumping
on the lower-level dugong library. It creates files "raw_stream_xx.dat"
in the current directory. Could you give that a shot and attach both the
results for an ssl and no-ssl run?

Best,
-Nikolaus

-- 
GPG encrypted emails preferred. Key id: 0xD113FCAC3C4E599F
Fingerprint: ED31 791B 2C5C 1613 AF38 8B8A D113 FCAC 3C4E 599F

 »Time flies like an arrow, fruit flies like a Banana.«
diff --git a/dugong/__init__.py b/dugong/__init__.py
--- a/dugong/__init__.py
+++ b/dugong/__init__.py
@@ -17,7 +17,9 @@
 import ssl
 import hashlib
 from inspect import getdoc
+from itertools import count
 import textwrap
+import os
 from base64 import b64encode
 from collections import deque
 from collections.abc import MutableMapping, Mapping
@@ -424,6 +426,11 @@
 self._in_remaining = None
 self._pending_requests = deque()
 
+for i in count():
+if not os.path.exists('raw_stream_%d.dat' % i):
+break
+self.dumpfh = open('raw_stream_%d.dat' % i, 'wb')
+
 log.debug('done')
 
 def _co_tunnel(self):
@@ -573,7 +580,7 @@
 '''Send *buf* to server'''
 
 log.debug('trying to send %d bytes', len(buf))
-
+
 if not isinstance(buf, memoryview):
 buf = memoryview(buf)
 
@@ -608,6 +615,7 @@
 continue
 
 log.debug('sent %d bytes', len_)
+self.dumpfh.write(buf[:len_])
 buf = buf[len_:]
 if len(buf) == 0:
 log.debug('done')
@@ -922,6 +930,7 @@
 buf2 = self._sock.recv(size - len(buf))
 if not buf2:
 break
+self.dumpfh.write(buf2)
 buf += buf2
 else:
 buf += rbuf.exhaust()
@@ -1062,6 +1071,7 @@
 raise ConnectionClosed('connection closed unexpectedly')
 
 log.debug('got %d bytes', read)
+self.dumpfh.write(buf[pos:pos+read])
 self._in_remaining -= read
 pos += read
 if pos == len_:
@@ -1213,6 +1223,7 @@
 assert rbuf.e < len(rbuf.d)
 raise ConnectionClosed('connection closed unexpectedly')
 
+self.dumpfh.write(rbuf.d[rbuf.e:rbuf.e+len_])
 rbuf.e += len_
 log.debug('done (got %d bytes)', len_)
 return len_
@@ -1288,6 +1299,7 @@
 self._sock.close()
 self._sock = None
 self._rbuf.clear()
+self.dumpfh.close()
 else:
 log.debug('already closed')

Bug#771864: libdebian-installer - dependency resolver support excluding packages

2014-12-02 Thread Asbjørn Sloth Tønnesen

Package: libdebian-installer
Severity: wishlist

Not tagging patch, as the patch is obviously not finished,
feel free to extend it, just did enough now so that I could
get cdebootstrap working with jessie. I don't think I will
have time to implement the plumbing for the full exclude
functionality, but the patch below is enough to prove that
excluding packages isn't that hard or intrusive to add.

IMHO jessie is effectively systemd only, when jessie sysvinit
images are only buildable with a custom libdebian-installer
package.


diff --git a/src/package_parser.c b/src/package_parser.c
index 6d6a5e7..990cd03 100644
--- a/src/package_parser.c
+++ b/src/package_parser.c
@@ -265,7 +265,7 @@ void di_package_parser_read_dependency (
   internal_di_package_parser_data *parser_data = user_data;
   di_package *p = *data, *q;
   char *cur = value->string, *end = value->string + value->size;
-  char *namebegin, *fieldend;
+  char *namebegin, *fieldend, *fieldpipe;
   size_t namelen;
   di_package_dependency *d, *d1;
 
@@ -278,6 +278,24 @@ void di_package_parser_read_dependency (
 namebegin = cur;
 namelen = strcspn (cur, " \t\n(,|");
 
+/* XXX hardcoded to only and always exclude systemd-sysv
+ * TODO expose an exclude API that cdebootstrap can use */
+
+/* check if package should be excluded */
+if (namelen == sizeof("systemd-sysv") - 1
+&& memcmp(cur, "systemd-sysv", namelen) == 0) {
+  /* take next option */
+  fieldpipe = cur + strcspn(cur, "|");
+  fieldend = cur + strcspn (cur, "\n,");
+  if (fieldpipe < fieldend) {
+   printf("alternative exists\n");
+/* only obey if an alternative exists */
+while (isspace(*++fieldpipe));
+cur = fieldpipe;
+continue;
+  }
+}
+
 d = di_package_dependency_alloc (parser_data->allocator);
 
 if (parser_data->packages)

-- 
Best regards
Asbjørn Sloth Tønnesen

Bug#771793: [pcp] Bug#771793: pcp: insecure use of /var/tmp in postinst

2014-12-02 Thread Nathan Scott

Hi Jakub,

- Original Message -
> [...]
> I'd suggest using stat(1) to check the file type and ownership
> atomically, and without following symlinks. Something like this should
> work:
> 
> [ "$(LC_ALL=C stat -c '%u %g %F' $dir)" = "0 0 directory" ] && mv $dir
> /var/lib/pcp/tmp

Yep, looks good - will get this included in the next update, thanks.

cheers.

--
Nathan


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

Bug#771862: fixed

2014-12-02 Thread 積丹尼 Dan Jacobson

Seems fixed now.


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

Bug#771794: pip silently removes/updates system provided python packages

2014-12-02 Thread Scott Kitterman

On Tuesday, December 02, 2014 05:17:48 PM Donald Stufft wrote:
> > On Dec 2, 2014, at 5:03 PM, Scott Kitterman  wrote:
> > 
> > On Tuesday, December 02, 2014 04:54:37 PM Donald Stufft wrote:
> >>> On Dec 2, 2014, at 4:47 PM, Scott Kitterman 
> >>> wrote:
> >>> 
> >>> On Tuesday, December 02, 2014 04:15:05 PM Donald Stufft wrote:
> >>> ...
> >>> 
>  I have another question. If we fix this in the upcoming pip 6 release
>  what
>  is the chances of getting an exception for pip 6 in the freeze? If I
>  can
>  solve the problem in pip proper and keep the delta between different
>  platforms smaller I can juggle around priorities and push the other big
>  ticket thing I was working on till another release.
> >>> 
> >>> ...
> >>> The deadline for getting Important (i.e. not Serious/Grave/Critical) bug
> >>> fixes unblocked for Jessie is December 5th (that's uploaded to Debian
> >>> and
> >>> the release team has reviewed and unblocked it).
> >>> 
> >>> Unless the next release is ~nothing but fixes for important/release
> >>> critical bugs, the chance is approximately zero.
> >>> 
> >>> Scott K
> >> 
> >> This bug is marked “Serious” right? So if I understand correctly a new
> >> version isn’t acceptable, even to fix a Serious issue, unless it only
> >> fixes
> >> items that are allowed within whatever phase the release process is in?
> > 
> > A new release would be acceptable if it only fixed release critical stuff.
> >  The problem comes in where a new release fixes something serious and
> > other stuff.
> > 
> > Scott K
> 
> Ok, so anything from upstream will need to be backported to 1.5.x then,
> which might be a pain but I don’t think undoable. We reorganized some stuff
> but it shouldn’t be impossible.
> 
> Would a patch for this issue need to be done and uploaded and unblocked by
> the Dec 5th? Or Since it’s a “Serious” issue is there a longer deadline?
> 
> What’s the chances of accepting the status quo for Jessie and having an
> upstream fix in Jessie+1? This isn’t a *new* problem, it exists in stable
> and oldstable as well and it wasn’t unknown to be a problem previously
> (there’s another ticket about making —user the default in BTS which
> references this fact over a year ago). I’m not sure what would make it all
> of a sudden a dire problem in Jesse, so if we can wait till Jesse+1 and I
> can get a stakeholder to sit down with me and sort out what a solution
> *needs* from the Debian side of things I can make sure a fix does land in
> the next pip release which will be out far in advance of Jessie+1.

Assuming the maintainer doesn't decide to downgrade the bug (which I think is 
unlikely and a number of people would object to, so I think we can ignore it 
as a possibility), the decision to ignore the bug for Jessie belongs with the 
release team.  If we choose not to fix it (and there's no Non-Maintainer 
Upload), then they will decide to either remove the package or ignore the bug.

Since this particular issue is release critical, the December 5th deadline 
isn't relevant to a targeted fix just for this issue.

Scott K


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

Bug#771857: signing-party: using gpg2, signing is skipped with 'No secret key'

On Tue, 02 Dec 2014 at 17:23:21 -0500, Brian Minton wrote:
> If I have the gpg config entry set to gpg2 (with or without the path)
> version 2.1, I get the following message:
> 
> gpg: skipped "0424DC19B678A1A9": No secret key
> 
> 0424DC19B678A1A9 is my key, the private key of which is usable by gpg2
> and gpg.

On second thought, this might be an issue with the 2.0 and 1.4 branches
as well.  gpg exits the edit prompt with return value 2 whenever some
secret key doesn't have its public part in the public keyring.

Really sign all user IDs? (y/N) y
gpg: error checking usability status of 
gpg: key : secret key without public key - skipped
gpg> q
$ echo $?
2

caff uses the default secret keyring (configurable with
$CONFIG{'secret-keyring'}) but has its own public keyring.  Right now
only $CONFIG{'keyid'} is imported from the normal public keyring.  Is
0424DC19B678A1A9 the key used as $CONFIG{'keyid'} in your .caffrc?  If
not, can you try

gpg --export 0424DC19B678A1A9 | gpg --homedir=$HOME/.caff/gnupghome --import

If that fixes the problem, I've got a proper fix ready ;-)

Cheers,
-- 
Guilhem.

signature.asc
Description: Digital signature

Bug#771834: [PKG-OpenRC-Debian] Bug#771834: [openrc] Frightening warning in README.Debian

2014-12-02 Thread Thomas Goirand

On 12/03/2014 02:07 AM, Manolo Díaz wrote:
> Package: openrc
> Version: 0.13.1-4
> Severity: normal
> 
> Dear maintainer,
> 
> README.Debian file reads:
> 
>   "This package is EXPERIMENTAL.  Installing it could make your
>   system UNBOOTABLE.  Only use this package for testing purposes
>   in a virtual machine, unless you are very brave!"
> 
> If still valid, that frightening warning should be available before
> installing the package. In the package description, e.g. 
> 
> Otherwise, please update that file.

Hi,

I don't think this is still valid, and a recent Git commit has already
removed it on our repository.

Thomas Goirand (zigo)


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

Bug#769951: [Pkg-mpd-maintainers] Bug#769951: Bug#769951: mpd: `update-rc.d mpd disable' is not enough to be able to run mpd as normal user

2014-12-02 Thread Clément B .


All right, I asked around a bit, to get to the following
conclusion: update-rc.d is a systemvinit tool, and is thus
inappropriate for systemd jobs such as disabling this
service. The correct way is to use systemctl.

I don't know what to do next. There is obviously a dependency
problem, it makes no sense to keep the mpd socket around once the
service is disabled, and it is hard to guess that you have to
disable both to run mpd as normal user. I am actually not sure
that the socket unit file is necessary at all, I think mpd is
capable of opening its own socket.

Should this bug be closed and another one opened regarding the
dependency? Who is in charge of writing the init scripts?


Clément


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

Bug#771436: caff: Support e-mail subject customization

Control: tags -1 + pending

Hi Nelson,

On Sat, 29 Nov 2014 at 13:17:35 -0200, Nelson A. de Oliveira wrote:
> caff has a hardcoded e-mail subject.
> It would be good if we could also customize it (in .caffrc)

Done in r739:
https://anonscm.debian.org/viewvc/pgp-tools?view=revision&revision=739

There is only one extension defined at the moment: "%k", which expands
to the long key ID.  More can be added if needed, feel free to reopen
and/or to file another bug.

Cheers,
-- 
Guilhem.

signature.asc
Description: Digital signature

Bug#770069: Bug#769672: hdapsd: Doesn't start at boot

2014-12-02 Thread Roger Lynn

On 02/12/14 14:01, Roger Lynn wrote:
> On 02/12/2014 13:47, Evgeni Golov wrote:
>> On 11/26/2014 08:28 AM, Evgeni Golov wrote:
>>> Thanks. Could you please test the following patched version:
>>>  https://people.debian.org/~evgeni/tmp/hdapsd_20141024-3~test1_amd64.deb
>>>
>>> What I do not really understand: read() should be interrupted on
>>> SIGTERM/SIGUSR1, so we already should jump out of the loop!?
> 
> As far as I remember from when I looked at the code, a signal will interrupt 
> the read() to call the signal handler. The signal handler sets a global 
> variable and returns, which means the read() continues to wait. When the 
> read() eventually returns the global variable is checked at the end of the 
> main while loop which means that the program can finish.
> 
>> Could any one of you confirm the package as working (properly stoping)
>> now, compared to the -2 version currently found in Debian?
>> I'd like to get it into Jessie, but can't test properly w/o the hardware.
> 
> Sorry, I missed your previous email. I'll try to test it in the next day or 
> two.

It stops immediately now, although the ordering of the logs is a little
strange. Here are the syslogs after starting and stopping it. Note the last
line and timings:

Dec  2 23:00:50 brahms hdapsd[15249]: Selected interface: FREEFALL
Dec  2 23:00:50 brahms hdapsd[15249]: Uses hardware logic from /dev/freefall

Dec  2 23:01:09 brahms hdapsd[15249]: Terminating hdapsd
Dec  2 23:01:09 brahms systemd[1]: hdapsd.service: main process exited,
code=exited, status=255/n/a
Dec  2 23:01:09 brahms systemd[1]: Unit hdapsd.service entered failed state.
Dec  2 23:01:09 brahms hdapsd[15249]: Tue Dec  2 23:00:50 2014: Starting hdapsd

Thanks,

Roger


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

Bug#771509: gnome shouldn't recommend xul-ext-adblock-plus

2014-12-02 Thread Andreas Schneider

Hi,

many thanks for your speedy reply!

> > are still valid. The most important one to me continues to be that a
desktop
> > environment and this browser extension have absolutely nothing to do
with each
> > other.
>
> The âgnomeâ metapackage defines what is installed on a desktop or
laptop
> with the GNOME selection. So it has everything to do with installing
> what is required to properly use the machine.

The policy regarding "Recommends" says:
"
This declares a strong, but not absolute, dependency.
The Recommends field should list packages that would be found together
with this one in all but unusual installations.
"
and from that perspective I still think my point is very valid: An
installation of gnome without adblock-plus is not exactly unusual. Now I'm
not aware of a comparable guideline for metapackages and if one existed it
would likely be not worded as strongly. But even going with your "required
to properly use the machine" I can't see why an adblocker would fall into
this camp. I am using exclusively using Debian on all my computers with
different DEs since a number of years and I never felt like one of them was
not properly usable without an adblocker.

> > Users who think they want an adblocker should conciously decide to
install it
> > and not having it sneaked into their install by a recommends.
>
> This particular package is certainly worth discussing, and the
> dependency is not set in stone. But you donât have to use deliberately
> confrontational words such as âsneaked intoâ to make your point. The
> contents of the default installation is public.

Whoops! I am deeply sorry if you found my wording offending or
confrontational!
I felt that the package was "sneaked into" my install when I did a habitual
dist-upgrade and while reviewing the list of packages to be newly installed
I ran across adblock-plus.
Looks like my recent overdose of reading confrontational emails on d-d@l.d.o
lowered my rudeness filter but that can't be an excuse. Sincerest apologies.

I don't understand what you mean with the "contents of the default
installation is public".

> > Somewhat off-topic and more on the more philosophical front: "the
internet" is
> > largely paid for by ads and if you don't like how ads are used by some
websites
> > then you are free to not visit them.
>
> Letâs get real: âthe internetâ is not usable without an ad blocker,
and
> it has gotten much worse in the two years that passed since the last
> time we had this discussion.

Well, and this is where I respectfully disagree. If someone feels offended
by the use of ads on websites he visits then he has a number of options to
choose from: either he refrains from visiting them, or he bears it, or he
installs an adblocker.

> I agree that it should be the userâs choice, but the idea was to avoid
> the extra action of installing the extension.
> Maybe we could ship it disabled by default if it is possible.

Honestly that doesn't sound like it's an easy fix. Plus it confuses those
who deliberately want the extension installed and see that it's not working
despite being installed.

Best,

Andreas

Bug#771863: openvswitch-switch: Open vSwitch configuration through /etc/network/interfaces does not work

2014-12-02 Thread lubot

Package: openvswitch-switch
Version: 2.3.0+git20140819-2
Severity: normal
Tags: patch

Dear Maintainer,

i used one of the simple example configurations from the file README.Debian.gz
to configure an Open vSwitch in /etc/network/interfaces.


allow-ovs br0
iface br0 inet dhcp
ovs_type OVSBridge
ovs_ports eth0

allow-br0 eth0
iface eth0 inet manual
ovs_bridge br0
ovs_type OVSPort


The physical interface eth0 does exist.
After boot the vSwitch is not configured and the br0 interface is not created.

# ovs-vsctl show
de102b28-6a22-4fbb-ba5c-670e2916a1e3
ovs_version: "2.3.0"

# ip l
1: lo:  mtu 65536 qdisc noqueue state UNKNOWN mode
DEFAULT group default
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
2: eth0:  mtu 1500 qdisc pfifo_fast state UP
mode DEFAULT group default qlen 1000
link/ether 3c:97:0e:61:12:f9 brd ff:ff:ff:ff:ff:ff
4: ovs-system:  mtu 1500 qdisc noop state DOWN mode
DEFAULT group default
link/ether a2:7a:df:81:6d:ba brd ff:ff:ff:ff:ff:ff

Analyzing the problem shows, that /etc/init.d/openvswitch-switch checks if the
variable $RUNLEVEL is empty, before configuring the vSwitch. Since it is empty
it cancels the configuration. Commenting the check fixes the problem.

Thanks for your help.
Regards lubot



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

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

Versions of packages openvswitch-switch depends on:
ii  kmod   18-3
ii  libatomic1 4.9.1-19
ii  libc6  2.19-13
ii  libpython2.7-stdlib [python-argparse]  2.7.8-11
ii  libssl1.0.01.0.1j-1
ii  netbase5.3
ii  openvswitch-common 2.3.0+git20140819-2
ii  procps 2:3.3.9-8
pn  python:any 
ii  uuid-runtime   2.25.2-3

openvswitch-switch recommends no packages.

openvswitch-switch suggests no packages.

-- no debconf information
--- openvswitch-switch	2014-12-03 00:09:38.304557848 +0100
+++ openvswitch-switch.new	2014-12-03 00:10:16.496558951 +0100
@@ -31,7 +31,7 @@
 test -e /etc/default/openvswitch-switch && . /etc/default/openvswitch-switch
 
 network_interfaces () {
-[ -z "${RUNLEVEL}" ] && return
+# [ -z "${RUNLEVEL}" ] && return
 INTERFACES="/etc/network/interfaces"
 [ -e "${INTERFACES}" ] || return
 bridges=`awk '{ if ($1 == "allow-ovs") { print $2; } }' "${INTERFACES}"`

Bug#688556: O: sane-frontends -- scanner graphical frontends

2014-12-02 Thread Jörg Frings-Fürst

retitle 688556 ITA: sane-frontends -- scanner graphical frontends
owner 688556 !
thanks

Hello,

I want to adopt sane-frontends.

CU
Jörg

-- 
New:
GPG Fingerprint: 63E0 075F C8D4 3ABB 35AB  30EE 09F8 9F3C 8CA1 D25D
GPG Key: 8CA1D25D
CAcert Key S/N: 0E:D4:56

Old (will be revoked after 2014-12-31):
pgp Fingerprint: 7D13 3C60 0A10 DBE1 51F8  EBCB 422B 44B0 BE58 1B6E
pgp Key: BE581B6E

Jörg Frings-Fürst
D-54526 Niederkail

Threema: SYR8SJXB

IRC: j_...@freenode.net
 j_...@oftc.net




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

Bug#771862: /var/lib/dpkg/tmp.ci/preinst: line 6: upgrade: command not found

2014-12-02 Thread 積丹尼 Dan Jacobson

Package: chromium
Version: 39.0.2171.71-1

Preparing to unpack .../chromium_39.0.2171.71-1_i386.deb ...
/var/lib/dpkg/tmp.ci/preinst: line 6: upgrade: command not found
Unpacking chromium (39.0.2171.71-1) over (38.0.2125.101-3) ...


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

Bug#771825: release-notes: Update information on non-systemd Jessie upgrades and installations

2014-12-02 Thread Javier Fernández-Sanguino Peña

On Tue, Dec 02, 2014 at 11:01:16PM +0100, Svante Signell wrote:
> >  * The second "hunk" of the patch seems better suited for the
> >installation-guide.  The release notes concerns itself with upgrades
> >and does not cover the debian-installer.
> 
> Somebody was complaining that changing the installation-guide was a lot
> of work, e.g. translations work, and did not want the changes to be made
> there https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=765803#40
> I don't mind getting the second part included there instead.

Translators (and I'm one of them) will have to update the installation-guide
before the release. 

I think it's better to have the document where it should be and also agree
that the Release Notes is not the place for that chunk.

Best regards

Javier


signature.asc
Description: Digital signature

Bug#771861: RFP: procyon -- suite of Java metaprogramming tools focused on code generation and analysis

2014-12-02 Thread Rogério Brito

Package: wnpp
Severity: wishlist

* Package name: procyon
  Version : 0.5.27
  Upstream Author : Mike Strobel 
* URL : https://bitbucket.org/mstrobel/procyon
* License : Apache License 2.0
  Programming Lang: Java
  Description : suite of Java metaprogramming tools focused on code 
generation and analysis

Procyon is a suite of Java metaprogramming tools focused on code generation
and analysis. It includes the following libraries:

 * Core Framework
 * Reflection Framework
 * Expressions Framework
 * Compiler Toolset (Experimental)
 * Java Decompiler

---

Debian doesn't have a Java Decompiler and this one, besides being Free
Software, is actively maintained.

-- 
Rogério Brito : rbrito@{ime.usp.br,gmail.com} : GPG key 4096R/BCFC
http://cynic.cc/blog/ : github.com/rbrito : profiles.google.com/rbrito
DebianQA: http://qa.debian.org/developer.php?login=rbrito%40ime.usp.br


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

Bug#771860: RFS: gnucheese/1.00-1

2014-12-02 Thread Michel Van den Bergh


Package: sponsorship-requests
Severity: wishlist

Dear mentors,

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

 * Package name: gnucheese
   Version : 1.00-1
   Upstream Author : Michel Van den Bergh
 * URL : http://hardy.uhasselt.be/GnuCheese
 * License : GPL
   Section : games

It builds those binary packages:

gnucheese  - Modern chess engine based on GNU Chess 5.07.

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

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


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

dget -x 
http://mentors.debian.net/debian/pool/main/g/gnucheese/gnucheese_1.00-1.dsc

More information about gnucheese can be obtained from 
http://hardy.uhasselt.be/GnuCheese .

Changes since the last upload:

* Initial release (Closes: #771853)

Regards,
Michel Van den Bergh


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

Bug#771857: signing-party: using gpg2, signing is skipped with 'No secret key'

Control: severity -1 wishlist
Control: retitle -1 Please support GnuPG 2.1

Hi Brian,

On Tue, 02 Dec 2014 at 17:23:21 -0500, Brian Minton wrote:
> If I have the gpg config entry set to gpg2 (with or without the path)
> version 2.1, I get the following message:

(I'm assuming you're talking about caff here.)  At the very last support
for the 2.1 branch of GnuPG will be added when it enters sid, but
hopefully before that.  (GnuPG 2.1 is only available in experimental
right now.)

Cheers,
-- 
Guilhem.

signature.asc
Description: Digital signature

Bug#771859: openssh: [INTL:pt_BR] Brazilian Portuguese debconf templates translatio

2014-12-02 Thread José de Figueiredo

Package: openssh
Tags: l10n patch
Severity: wishlist

Hello,

Please, Could you update the Brazilian Portuguese Translation?

Attached you will find the file pt_BR.po. It is UTF-8 encoded and it is
tested with msgfmt and podebconf-display-po.

Kind regards.

--
José de Figueiredo
Seja Livre, use GNU/Linux. Use Debian !!!

Antes de autorizar um aborto, pense que poderia ser vc lá dentro,
esperando alguém decidir se vc morre ou não...
http://www.brasilsemaborto.com.br/

Venha estudar no IFSul - é público, federal e de qualidade.
# Debconf translations for openssh.
# Copyright (C) 2014 THE openssh'S COPYRIGHT HOLDER
# This file is distributed under the same license as the openssh package.
# JosÃ© de Figueiredo , 2014.
#
#
msgid ""
msgstr ""
"Project-Id-Version: openssh\n"
"Report-Msgid-Bugs-To: open...@packages.debian.org\n"
"POT-Creation-Date: 2014-03-20 02:06+\n"
"PO-Revision-Date: 2014-11-23 23:49-0200\n"
"Last-Translator: JosÃ© de Figueiredo \n"
"Language-Team: Brazilian Portuguese \n"
"Language: pt_BR\n"
"MIME-Version: 1.0\n"
"Content-Type: text/plain; charset=UTF-8\n"
"Content-Transfer-Encoding: 8bit\n"

#. Type: boolean
#. Description
#: ../openssh-server.templates:1001
msgid "Disable SSH password authentication for root?"
msgstr "Desabilitar autenticaÃ§Ã£o por senha do SSH para root?"

#. Type: boolean
#. Description
#: ../openssh-server.templates:1001
msgid ""
"Previous versions of openssh-server permitted logging in as root over SSH "
"using password authentication. The default for new installations is now "
"\"PermitRootLogin without-password\", which disables password authentication "
"for root without breaking systems that have explicitly configured SSH public "
"key authentication for root."
msgstr ""
"VersÃµes anteriores do openssh-server permitiam login como root sobre SSH "
"usando autenticaÃ§Ã£o por senha. O padrÃ£o para as novas instalaÃ§Ãµes agora Ã© "
"\"PermitRootLogin without-password\", que desabilita a autenticaÃ§Ã£o por "
"senha para root sem quebrar sistemas que tenham configurado explicitamente o "
"SSH para autenticaÃ§Ã£o por chave pÃºblica para root."

#. Type: boolean
#. Description
#: ../openssh-server.templates:1001
msgid ""
"This change makes systems more secure against brute-force password "
"dictionary attacks on the root user (a very common target for such attacks). "
"However, it may break systems that are set up with the expectation of being "
"able to SSH as root using password authentication. You should only make this "
"change if you do not need to do that."
msgstr ""
"Esta alteraÃ§Ã£o torna sistemas mais seguros contra ataques de forÃ§a bruta por "
"dicionÃ¡rio de senhas no usuÃ¡rio root (um alvo muito comum destes ataques). "
"Entretanto, ela pode quebrar sistemas que foram configurados com a "
"expectativa de acesso SSH com root usando autenticaÃ§Ã£o por senha. VocÃª deve "
"fazer esta mudanÃ§a somente se vocÃª nÃ£o precisa fazer isso."

signature.asc
Description: OpenPGP digital signature

Bug#771126: Bug#771191: Bug#771126: libav/tests/lena.pnm: also not mentioned in debian/copyright

2014-12-02 Thread Bastien ROUCARIES

Le 2 déc. 2014 14:15, "Reinhard Tartler"  a écrit :
>
> On Fri, Nov 28, 2014 at 1:34 AM, Niels Thykier  wrote:
> > Control: tags -1 -wheezy-ignore
> >
> > On 2014-11-27 23:23, Jonas Smedegaard wrote:
> >> Quoting Niels Thykier (2014-11-27 22:14:25)
> >>> [...]
> >>
> >> In prior similar bugreport  -
> >> referenced from  - distribution is
> >> documented as permitted only "for research and education" which I
> >> interpret as unacceptable for Debian.
> >>
> >> [...]
> >>
> >>  - Jonas
> >>
>
> FTR, this whole business feel incredibly silly. lena.pnm  has become
> the *de-facto* standard image for every CS student to do his graphics
> courses homework on, and is generally considered to public domain,

And offencive (sexist) for 50% of the population the women...

Bastien
> even without proper documentation. The copyright holder is going to
> have a very hard time enforcing his right if he wanted to prevent
> distribution of the image, in particular the low-quality scan that is
> being used in the Libav source package. Also, even according to
> https://en.wikipedia.org/wiki/File:Lenna.png#Licensing, the holder is
> not interested in that to begin with. - I mean, really, don't we have
> more important things to do?
>
> Nevertheless, lena.pnm lacks proper licensing and some argue it
> violates the DFSG, so I've taken the effort (and ridicule!) to replace
> lena.pnm upstream with a new image reference.pnm, which I have
> personally taken this summer and upon Jonas' suggestion provide it
> under the expat license. This required to update all test reference
> patterns, which took  most of the effort and is basically not
> verifiable.
>
> Jonas, would you mind taking over from here and upload
> https://libav.org/releases/libav-11.1.tar.xz
>
> to unstable?
>
> Otherwise I can see if I can get to that this weekend.
>
> Regarding stable: I've backported this change back to release/0.8
> upstream. In the past, the security team has accepted libav point
> releases in wheezy-security, and I trust that this is also an
> acceptable change. It will be part of the next upload to
> stable-security. (this may take some more weeks, as libav has been
> notified about a couple of more CVEs, which need to be tested, fixed
> and verified, which is incredibly laborsome to do correctly).
>
> Does this plan work for everyone?
>
> --
> regards,
> Reinhard
>

Bug#771858: llvm-3.5-dev: Invalid path set to LLVM_CMAKE_DIR into /usr/share/llvm-3.5/cmake/LLVMConfig.cmake

2014-12-02 Thread Agustin Henze

Package: llvm-3.5-dev
Version: 1:3.5-6
Severity: normal

Hi LLVM Team, I found this when I was trying to use the cmake configuration
delivered with llvm-3.5-dev.
You can reproduce it following these commands:

cd /tmp
cat > CMakeLists.txt << EOF
project(test)

find_package(LLVM REQUIRED CONFIG)
EOF

mkdir build; cd build; cmake ..

-- 
TiN



signature.asc
Description: OpenPGP digital signature

Bug#686447: [Pkg-zfsonlinux-devel] Summary of ZFS on Linux for Debian

2014-12-02 Thread Carlos Alberto Lopez Perez

Hi Lucas,

It has been already 3 months since you requested ftp-masters to ACK the
mail quoted below.

I have already requested several times on the IRC (#debian-ftp) to the
ftp-team to ACK your mail, and they ignored my requests.

I think that 3 months of waiting for an ACK is more than enough.

At this point, I kindly ask you to pass our mail regarding the license
issues about ZoL to the SFLC lawyer in the next couple of days if you
don't get an ACK or a reply from ftp-masters about this issue.

Thanks.

On 31/08/14 01:28, Lucas Nussbaum wrote:
> Hi,
> 
> On 29/08/14 at 09:42 +0800, Aron Xu wrote:
>> Dear DPL and FTP Masters,
>>
>> As agreed at DebConf 14, Debian ZFS on Linux Maintainers have concluded
>> into the following summary for the situation, please see as follows.
> 
> Thanks a lot for this work.
> 
> I think that adding an actual question to our legal counsel would help
> focus their work. If I understand correctly, that question should be:
> Does this summary accurately represents your understanding of the
> question?
> Can Debian distribute a ZoL package using (1) Source code and (2)
> Binary Linux LKM?
> 
> In any case, I'll wait for comments or ACK from ftpmasters before
> forwarding your mail to SFLC.
> 
> Lucas
> 
> 
> 
> ___
> Pkg-zfsonlinux-devel mailing list
> pkg-zfsonlinux-de...@lists.alioth.debian.org
> http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-zfsonlinux-devel
> 

signature.asc
Description: OpenPGP digital signature

Bug#771857: signing-party: using gpg2, signing is skipped with 'No secret key'

2014-12-02 Thread Brian Minton

Package: signing-party
Version: 1.1.11-1
Severity: normal

-BEGIN PGP SIGNED MESSAGE-
Hash: RIPEMD160

Dear Maintainer,

If I have the gpg config entry set to gpg2 (with or without the path)
version 2.1, I get the following message:

gpg: skipped "0424DC19B678A1A9": No secret key

0424DC19B678A1A9 is my key, the private key of which is usable by gpg2
and gpg.

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

Kernel: Linux 3.14-2-amd64 (SMP w/4 CPU cores)
Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968)
Shell: /bin/sh linked to /bin/dash

Versions of packages signing-party depends on:
ii  gnupg  1.4.18-4
ii  libc6  2.19-13
ii  libclass-methodmaker-perl  2.21-1+b1
ii  libgnupg-interface-perl0.50-3
ii  libmailtools-perl  2.13-1
ii  libmime-tools-perl 5.505-1
ii  libnet-idn-encode-perl 2.201-1
ii  libterm-readkey-perl   2.32-1+b1
ii  libtext-template-perl  1.46-1
ii  perl   5.20.1-2
pn  python:any 
ii  qprint 1.0.dfsg.2-2

Versions of packages signing-party recommends:
ii  dialog 1.2-20140911-1
ii  exim4-daemon-heavy [mail-transport-agent]  4.84-3
ii  libgd-gd2-perl 1:2.46-3.1+b2
ii  libpaper-utils 1.1.24+nmu3
ii  whiptail   0.52.17-1

Versions of packages signing-party suggests:
ii  fonts-droid1:4.4.4r2-4
iu  imagemagick8:6.8.9.6-4+b1
ii  mutt   1.5.23-1.1
ii  qrencode   3.4.3-1
ii  texlive-font-utils 2014.20140821-1
ii  texlive-latex-recommended  2014.20140821-1
ii  texlive-xetex  2014.20140821-1
ii  wipe   0.22-1

- -- no debconf information

-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iEYEAREDAAYFAlR+O9AACgkQ2/alund99IdVYgCdEdcaecxa3LfqBFMC4TK23KG7
xvsAn0qAi026SWjgvDXqya/Ek8q+htzJ
=pqIy
-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#771795: systemd keep starting a service disabled with "disable" and even "mask"

2014-12-02 Thread Vincent Danjean

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 02/12/2014 15:11, Michael Biebl wrote:
> Am 02.12.2014 um 14:58 schrieb Vincent Danjean:
>> If you need more information, please ask.
> 
> wicd seems to ship SysV init script only. I assume you haven't created your 
> own native wicd.service file in /etc/systemd/system?

No, I did not create any service file for now.

> What's the output of systemctl status wicd.service

currently :

root@eyak:/home/vdanjean# systemctl status wicd.service
● wicd.service
   Loaded: masked (/dev/null)
   Active: inactive (dead)

> and
> 
> ls -la /etc/rc?.d/???wicd

root@eyak:/home/vdanjean# ls -la /etc/rc?.d/???wicd
lrwxrwxrwx 1 root root 14 nov.  23  2011 /etc/rc0.d/K01wicd -> ../init.d/wicd
lrwxrwxrwx 1 root root 14 nov.  23  2011 /etc/rc1.d/K01wicd -> ../init.d/wicd
lrwxrwxrwx 1 root root 14 nov.  23 16:34 /etc/rc2.d/K01wicd -> ../init.d/wicd
lrwxrwxrwx 1 root root 14 nov.  23 16:34 /etc/rc3.d/K01wicd -> ../init.d/wicd
lrwxrwxrwx 1 root root 14 nov.  23 16:34 /etc/rc4.d/K01wicd -> ../init.d/wicd
lrwxrwxrwx 1 root root 14 nov.  23 16:34 /etc/rc5.d/K01wicd -> ../init.d/wicd
lrwxrwxrwx 1 root root 14 nov.  23  2011 /etc/rc6.d/K01wicd -> ../init.d/wicd

> The systemd-analyze dump which is attached to this bug report doesn't contain 
> any information about wicd, so I assume you filed the bug report on a 
> different machine.

No, it was done on the same machine. And I did not remove anything
in the generated reportbug template.

  Regards,
Vincent

PS: I will upgrade to the lattest systemd version in experimental
to see if it fixes my problem.

- -- 
Vincent Danjean   GPG key ID 0xD17897FA vdanj...@debian.org
GPG key fingerprint: 621E 3509 654D D77C 43F5  CA4A F6AE F2AF D178 97FA
Unofficial pkgs: http://moais.imag.fr/membres/vincent.danjean/deb.html
APT repo:  deb http://people.debian.org/~vdanjean/debian unstable main

-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQIVAwUBVH46hJZH3mN+x7dRAQh8HQ//eLtuO2at+csdzT4lmvPd02DHL1kIeCL5
f8Q8+3EjKrRo0A4Ux86MdeZJicUxP901Xj4EFXK2+3SuXgLXIzxfRxgwf1Ovjggr
iSL8SwcqzfeenKr/v/+ZRVI4SNUqvxNNki7+4SBPmInJxRqa45U1IDFvFI286aoQ
r0VuPMPTeB+Coh8SL+Cd6Ihmyk43kyONZAejFCEDawgx9sxsZbjcBV1NX0qPzEpt
xbBdCGrnR3bqHjAUjY/P9+o1LaljiFepaMTkRc6u05cJQj50UyINm8Ik+mmX5L0q
r4JA7xrFx8elLDp6cu3prMFM2xGUZ7xV0XTQPbFJ8hzxIuAwEKtYko/U0fs2TWFy
jOZmEfxzCFBTfJDxOWLc8RPMajaj2Q/hb8xjazBzjpswOCJ5IpUyvn6I/cGtYLhy
Kdlulftm/T6fBGDyeAwleCacuDrqml90O96Cduk6AnwUrwfFjuGXoYTXencTo5/n
DwOJoiihMT7y2HVuk6pW4njVlJn5e/Lde4gSQHZD8GXyTtsHEb3H3yf5BJvvK+NQ
i4zJUYZgGepzUEw8kvy/N9qh/WMmbU7+4E4EKapUHiZDtDCfAgIDQskEWYpUpGVA
mo4c0sBM82KC9e8D2Y7tJ8SYbhPH5oAUIK5N1lLLrxYtBbAuQMROMnuq5oN8G8rk
GlMHfhBuI4U=
=iJ3c
-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#771452: Duplicate object check

2014-12-02 Thread Shannon Dealy


On Tue, 2 Dec 2014, Shannon Dealy wrote:

[snip]

I performed a capture as requested, ...


Sorry Nikolaus,

I have deleted that file from where I posted it.

I made a mistake, that file was captured with ssl enabled.  In fact, it 
appears based on a limited sample, that fsck.s3ql fails 100% of the time 
when ssl is enabled (35+ runs), and succeeds 100% of the time when ssl is 
disabled (6 runs so far).  I don't know if this is a generic work around, 
or if it just happens to work this way for my particular data set.


Given the above, there is no way I can provide you with a "no-ssl" version 
of the captured data (since it always succeeds).  Could you make a patch 
to fsck.s3ql which would provide you with the required data?  Or does the 
difference between ssl and no-ssl behavior give you some ideas?


Regards,

Shannon C. Dealy   | DeaTech Research Inc.
de...@deatech.com  |- Custom Software Development -
USA Phone: +1 800-467-5820 |- Natural Building Instruction -
numbers  : +1 541-929-4089 |www.deatech.com


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

Bug#752230:

2014-12-02 Thread Lisandro Damián Nicanor Pérez Meyer

On Tuesday 02 December 2014 13:36:03 Rene Engelhard wrote:
> On Tue, Dec 02, 2014 at 01:19:42PM +0100, Bugtracker wrote:
> > Is there any chance get this bug fixed for the upcoming Jessie
> > release?
> 
> Probably not. it's too late I think. And yes, I don't like it either.

Neither I, but the patches have never been pushed to Qt4 but to Qt5 (and even 
Qt 5.4, so not even in Jessie).

Rene: looking at [0] and if I'm not mistaken there is a fix for this one. But 
I might be mistaken the bug.

Kinds regards, Lisandro.

[0] 

-- 
Una vez que hemos eliminado lo imposible, lo que queda, por improbable que
parezca, es la verdad.
  Sherlock Holmes

Lisandro Damián Nicanor Pérez Meyer
http://perezmeyer.com.ar/
http://perezmeyer.blogspot.com/

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

Bug#771794: pip silently removes/updates system provided python packages

2014-12-02 Thread Donald Stufft

> On Dec 2, 2014, at 5:03 PM, Scott Kitterman  wrote:
> 
> On Tuesday, December 02, 2014 04:54:37 PM Donald Stufft wrote:
>>> On Dec 2, 2014, at 4:47 PM, Scott Kitterman  wrote:
>>> 
>>> On Tuesday, December 02, 2014 04:15:05 PM Donald Stufft wrote:
>>> ...
>>> 
 I have another question. If we fix this in the upcoming pip 6 release
 what
 is the chances of getting an exception for pip 6 in the freeze? If I can
 solve the problem in pip proper and keep the delta between different
 platforms smaller I can juggle around priorities and push the other big
 ticket thing I was working on till another release.
>>> 
>>> ...
>>> The deadline for getting Important (i.e. not Serious/Grave/Critical) bug
>>> fixes unblocked for Jessie is December 5th (that's uploaded to Debian and
>>> the release team has reviewed and unblocked it).
>>> 
>>> Unless the next release is ~nothing but fixes for important/release
>>> critical bugs, the chance is approximately zero.
>>> 
>>> Scott K
>> 
>> This bug is marked “Serious” right? So if I understand correctly a new
>> version isn’t acceptable, even to fix a Serious issue, unless it only fixes
>> items that are allowed within whatever phase the release process is in?
> 
> A new release would be acceptable if it only fixed release critical stuff.  
> The 
> problem comes in where a new release fixes something serious and other stuff.
> 
> Scott K

Ok, so anything from upstream will need to be backported to 1.5.x then, which
might be a pain but I don’t think undoable. We reorganized some stuff but it
shouldn’t be impossible.

Would a patch for this issue need to be done and uploaded and unblocked by the
Dec 5th? Or Since it’s a “Serious” issue is there a longer deadline?

What’s the chances of accepting the status quo for Jessie and having an upstream
fix in Jessie+1? This isn’t a *new* problem, it exists in stable and oldstable
as well and it wasn’t unknown to be a problem previously (there’s another ticket
about making —user the default in BTS which references this fact over a year 
ago).
I’m not sure what would make it all of a sudden a dire problem in Jesse, so if 
we
can wait till Jesse+1 and I can get a stakeholder to sit down with me and sort
out what a solution *needs* from the Debian side of things I can make sure a
fix does land in the next pip release which will be out far in advance of 
Jessie+1.

---
Donald Stufft
PGP: 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA

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

Bug#771721: unblock: filler/1.02-6.2