Bug#804127: mp4v2-utils: mp4tags -picture option corrupts album artist

[Leigh Dyer]

Package: mp4v2-utils
Version: 2.0.0~dfsg0-3
Severity: normal
Tags: upstream

Dear Maintainer,

Due to a misplaced "break;" statement, when you use the -picture flag to
mp4tags to specify the path to a cover art file, it also sets the album artist
field (eg: as if using the -albumartist flag) to the path of the file given to
the -picture flag.

This bug has actually been previously reported:

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=709127

but the applied fix was wrong; rather than applying the supplied patch as-is,
the "break" was put inside the "else" clause just above, so the bug persists
in any case where the cover art is successfully set (and that "else" clause
is not triggered).

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

Kernel: Linux 3.16.0-4-amd64 (SMP w/32 CPU cores)
Locale: LANG=en_US, LC_CTYPE=en_US (charmap=ISO-8859-1)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages mp4v2-utils depends on:
ii  libc6   2.19-18+deb8u1
ii  libgcc1 1:4.9.2-10
ii  libmp4v2-2  2.0.0~dfsg0-3
ii  libstdc++6  4.9.2-10

mp4v2-utils recommends no packages.

mp4v2-utils suggests no packages.

-- no debconf information

Bug#769889: workaround

[Piviul]

I don't know why but seems you have wrong permissions on some of the
subfolders of /run/user/1000. Have you tried to add right permissions tu
gvfs?

# chmod u+rx /run/user/1000/gvfs

Furthermore what are permissions for /run/user/1000/glib/user? In other
word please send us the output of the command

$ ls -l /run/user/1000/glib/user

This is the output in my debian testing:

$ ls -l /run/user/1000/dconf/user
-rw--- 1 piviul piviul 2 nov  5 08:04 /run/user/1000/dconf/user


Piviul

Bug#804018: dpkg: provide options to avoid service startup on package installation

[Patrick Schönfeld]

Hi,

2015-11-05 2:38 GMT+01:00 Guillem Jover :
>
> That's really what policy-rc.d is for.
>

and I think that is not the right interface for such cases or at least it's
not the best interface we can can provide for such cases. It's certainly
good enough for the admin who wants to overrule our policy permanently,
although letting the admin write a script for such a simple decision still
feels kind of clumsy. IMHO it has probably been designed for build chroots
and that's absolutely the purpose it fits best.

But let's have a deeper look at the configuration management case. If they
wanted to provide a way to say "install that package, but make sure that
the service is not started afterwards", they could either

a) Permanently install a policy-rc.d layer, letting it interface with the
package install (e.g. by the env variable you said and another one set by
the configuration management to tell the policy-layer which service the
policy applies to)

b) Install a policy-rc.d layer before each package installation, removing
it afterwards

c) Let each user handle installing a policy-rc.d layer either permanently
or before each package installation

Each of this option has several disadvantages:
With a) the admin is no longer able to install another policy-rc.d script,
apart from that it's a quiet invasive from a configuration management
system to put a script in place that is permanently interfered with for
every service that is ever started.

With b) the door is widely opened for all kind of trouble, e.g. leaving
mess around after package installation. Sure there can be put safety
measures into place to avoid that, but overall it increases complexicity -
for a Debian specific solution, since other distributions just don't start
services after installation.

With c) everything applies which applies to b), additionally each user has
to implement this himselves and need to workaround the fact, that the
configuration management system is not aware of his implementation. Thats
where we are today: Some people employ exec-handlers to kill the service
after install, some put a policy-rc.d layer in place.

All of these solutions have in common that they workaround a decision that
we as a project have made (to provide "default" configurations for services
and start them after package installations), which is fine in some cases
(e.g. software I *want* to be running after installation like sshd) and not
so fine in others (installing services I want to manage via a clusterstack
for example). Feels somewhat like giving the user some nails, but expect
him to build the hammer on his own.



> dpkg has no idea nor control over what happens inside maintainer scripts,
> those are exclusively under the package domain. Starting services is
> just one of the actions that can be done there, if any other policy
> would require making dpkg aware of it, then dpkg would suddenly have
> to know about tons of things it has no control over. But that place
> already exists anyway, per above. :)
>
>
And it does not have to have an idea what happens inside maintainer
scripts.

But since it's responsible for installation of those packages, it is also
responsible for providing the environment in which the maintainer scripts
run. Seems absolutely legit to restrict what the maintainer scripts are
allowed to do, even if that restriction is soft, in a way that could be
ignored by the maintainer scripts.

In that specific case, however, we absolutely do have control over what
happens. We have a policy in place that maintainer scripts have to
interface with invoke-rc.d, so if we'd decide on a flag, we could very well
set it in dpkg and let invoke-rc.d respect it. It would be cheap and
solving a problem in a way that other tools (like configuration management)
can rely on. And if the maintainer script does not run an init script at
all, this flag does no harm either.

Best Regards,
Patrick

Bug#780957: pos vars

[Nicholas Bamber]

tag 780957 +wontfix
severity 780957 minor
thanks

I can confirm that this behaviour is happening in ksh93, (though I 
personally cannot confirm it is not in ksh88).
I looked in the POSIX spec 
(http://pubs.opengroup.org/onlinepubs/9699919799/utilities/V3_chap02.html#tag_18_05_01 
), and I could not see a clear definition of expected behaviour.
The source contains a file, src/cmd/ksh93/COMPATIBILITY, supposedly 
listing differences between 88 and 93. It does not list this one, but it 
does say there could be more.


I don't see this as a big issue because you can find out equivalent 
information since the information needed to avoid accessing undefined 
positional variables is available in $*, $#, etc.

Bug#804125: #804125 ITP: golang-github-kr-pty -- PTY interface for Go

[Dmitry Smirnov]

Hi Tim,

Which version of Kubernetes needs this package? It is not in Godeps.
Or is this an indirect dependency?

Anyway it is already in Debian as "golang-pty-dev".

-- 
All the best,
 Dmitry Smirnov
 GPG key : 4096R/53968D1B

---

Democracy is a pathetic belief in the collective wisdom of individual
ignorance.
-- H. L. Mencken


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

Bug#801356: ITP: python-acme -- ACME protocol library for Python 2

[Johannes Schauer]

Hi,

Quoting Harlan Lieberman-Berg (2015-11-05 04:54:58)
> Johannes Schauer  writes:
> > Segmentation fault
> > E: pybuild pybuild:274: test: plugin distutils failed with: exit code=139: 
> > python2.7 setup.py test 
> > dh_auto_test: pybuild --test -i python{version} -p 2.7 --dir . returned 
> > exit code 13
> 
> Interesting.  I haven't seen this error at all, actually.  Was it
> reproducible, or was it transient?
> 
> Also, what suite were you building on?  I've, admittedly, only tested on sid.

I'm testing on sid with a sid sbuild schroot. Unfortunately the error seems to
be random. I tested three times and only once did it segfault...

If this never happens for you, I guess there's nothing you can do about it :)

Thanks!

cheers, josch


signature.asc
Description: signature

Bug#793094: pjproject: FTBFS: some symbols or patterns disappeared in the symbols file

[Tzafrir Cohen]

On Fri, Oct 30, 2015 at 03:52:56PM +0100, Emilio Pozuelo Monfort wrote:
> This a is friendly ping wrt the libstdc++ ABI transition. Your package is 
> listed
> as needing a transition but has seen no action. It'd be good to get things 
> going
> so we can finish the transition soon.

Thanks for the reminder.

I pushed some changes to the git repo. I hope to upload a package this
weekend.

pjproject is largely a C library with a single C++ library (libsua2 -
the binary package libsua2-2). I decided to bump the soname of that
lirary alone (libpjsua2-2v5).

-- 
Tzafrir Cohen | tzaf...@jabber.org | VIM is
http://tzafrir.org.il || a Mutt's
tzaf...@cohens.org.il ||  best
tzaf...@debian.org|| friend

Bug#803855: pjproject: FTBFS with FFmpeg 2.9

[Tzafrir Cohen]

On Mon, Nov 02, 2015 at 10:08:19PM +0100, Andreas Cadhalpun wrote:
> Package: pjproject
> Version: 2.4~dfsg-1
> Severity: important
> Tags: patch
> User: pkg-multimedia-maintain...@lists.alioth.debian.org
> Usertags: ffmpeg2.9
> 
> Dear Maintainer,
> 
> your package fails to build with the upcoming ffmpeg 2.9.
> This bug will become release-critical at some point when the
> ffmpeg2.9 transition gets closer.
> 
> Attached is a patch replacing the deprecated functionality.
> It also works with ffmpeg 2.8.
> Please apply this patch and forward it upstream, if necessary.
> 
> These changes have little regression potential.
> 
> Best regards,
> Andreas

Thanks. Merged in git and seems to work fine at first glance.

-- 
Tzafrir Cohen | tzaf...@jabber.org | VIM is
http://tzafrir.org.il || a Mutt's
tzaf...@cohens.org.il ||  best
tzaf...@debian.org|| friend

Bug#733586: closure-compiler: new upstream version available

[tony mancill]

On 2015-11-04 14:21, Christoph Biedl wrote:

Source: closure-compiler
Version: 20130227+dfsg1-8
Followup-For: Bug #733586

Gentle ping? The latest upstream release is 20151015 as far as I can
see. There have been some changes so the present Debianisation cannot
simply be forwarded. My skills in Java packaging are however somewhat
limited.

Christoph, on behalf of another person who is interested in using
closure-compiler


Hi Christoph,

Thank you for the reminder on this.

I took a look at the 20151015 release and so far it appears that we only 
need to package one additional reverse dependency - "truth" 
(http://google.github.io/truth).  We may also take advantage of this 
opportunity to switch from ant to the maven-based build system.  I'll 
try to get the new r-dep packaged this weekend and then see how quickly 
we can get the rest of it ready to go.


Cheers,
tony

Bug#782441: rkt -- some progress

[Dmitry Smirnov]

Hi Matthias, Tim,

Let's make it official -- at least for some time I'll coordinate "rkt" 
packaging. Tim, who did all the preliminary work in the repository [1] kindly 
gave me permission to take over. It is my understanding that earlier Tim took 
over the packaging from Matthias.

Packaging "rkt" was quite challenging but it seems that I've managed to 
overcome most of the technical problems. Now package is ready for trial but 
there are still ~20 unpackaged bundled 3rd party components that needs to be 
packaged separately -- a help is very much appreciated (feel free ask me for 
sponsorship and remember to check existing WNPP bugs).
If time allows I might take care of packages in "github.com/cznic" so please 
consider packaging other dependencies first.

See the "rkt" package repository for progress:

[1]: http://anonscm.debian.org/cgit/pkg-go/packages/rkt.git

-- 
Regards,
 Dmitry Smirnov.

---

Truth — Something somehow discreditable to someone.
-- H. L. Mencken, 1949


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

Bug#803914: fixed in ejabberd-contrib 0.2015.10.26~dfsg0-1

[Philipp Huebner]

Am 05.11.2015 um 04:47 schrieb Andreas Beckmann:
> This fixes only one half of the problem. ejabberd still needs to add 
> Breaks+Replaces against ejabberd-mod-http-upload.

I filed #804008, so ejabberd-mod-http-upload will be gone from the
archive soon. Why would I need to add Breaks+Replaces then?

As Ralf wrote:
"An optimal solution would
consist in only one of the packages installing that file, and renaming
or removing the file in the other package. Depending on the
circumstances you might also consider Replace relations or file
diversions. If the conflicting situation cannot be resolved then, as a
last resort, the two packages have to declare a mutual
Conflict. Please take into account that Replaces, Conflicts and
diversions should only be used when packages provide different
implementations for the same functionality."

So why should I add Breaks+Replaces towards a soon non-existent package?

Regards,
-- 
 .''`.   Philipp Huebner 
: :'  :  pgp fp: 6719 25C5 B8CD E74A 5225  3DF9 E5CA 8C49 25E4 205F
`. `'`
  `-



signature.asc
Description: OpenPGP digital signature

Bug#804126: magnum: Please re-use debconf translations from another OpenStack-related package

[Christian Perrier]

Source: magnum
Severity: normal
Tags: l10n

You know the drill:-)

New package popping up, with 32 new untranslated templates that are
similar to the 32 templates in a dozen (or two, or three) of other
OpenStack-related packages.

Dropping translations from one of these (debian/po/*po) in debian/po
for magnum and running debconf-updatepo and then uploading the new
package would help, instead of having us, translators, doing the very
same by randomly picking another OpenStack-realted package. Something
I now refuse to do for French translations, sorry. For once, *I* want
to be the one to be lazy.


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

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

Bug#748533: Processed: Re: still unable to print

[Scott Kitterman]

On Wednesday, November 04, 2015 09:43:25 PM Jameson Graef Rollins wrote:
> On Wed, Nov 04 2015, Scott Kitterman  wrote:
> > Okular already Recommends cups-bsd, so reopening the bug that suggests it
> > be added makes no sense.
> Hi, Scott.  I appreciate the response, but I still think we're missing
> the point.  The real question is, if the bug was fixed, why am I still
> suffering from it?  Just saying "install cups-bsd" is not actually a
> good solution to the problem.  If for whatever reason the user doesn't
> have cups-bsd installed, they have no way to know that the problem is
> the lack of that package.  In the interest of user it would be a lot
> more generous to provide a notification that printing is not possible
> without the cups-bsd package installed.

If you don't have cups-bsd installed, it's presumably because you have 
installation of recommend disabled.  If that's the case, then it's not at all 
surprising things don't work.

What you're asking for is not generally how Debian packages work.

Scott K

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

Bug#799685: dyfi: General update after the debconf review process

[Christian PERRIER]

Dear Debian maintainer,

On Saturday, September 26, 2015, I sent you a notification about the beginning 
of a review
action on debconf templates for dyfi.

Then, I sent you a bug report with rewritten templates and announcing
the beginning of the second phase of this action: call for translation
updates.

Translators have been working hard and here is now the result of their efforts.

Please consider using it EVEN if you committed files to your
development tree as long as they were reported.

The attached tarball contains:

- debian/changelog with the list of changes
- debian/control with rewrites of packages' descriptions
- debian/ with all the rewritten templates file(s)
- debian/po/*.po with all PO files (existing ones and new ones)

As said, please use *at least* the PO files as provided here,
preferrably over those sent by translators in their bug reports. All
of them have been checked and reformatted. In some cases, formatting
errors have been corrected.

The patch.rfr file contains a patch for the templates and control
file(s) alone.

Please note that this patch applies to the templates and control
file(s) of your package as of Saturday, September 26, 2015. If your package was 
updated
in the meantime, I may have updated my reference copybut I also
may have missed that. This is indeed why I suggested you do not
modified such files while the review process was running,
remember..:-)

It is now safe to upload a new package version with these changes.

Please notify me of your intents with regards to this. 

There is of course no hurry to update your package but feel free to
contact me in case you would need sponsoring or any other action to
fix this.



-- 




patch.tar.gz
Description: application/gzip
--- dyfi.old/debian/templates   2015-09-21 15:57:09.673240136 +0200
+++ dyfi/debian/templates   2015-10-13 07:26:58.817145639 +0200
@@ -1,11 +1,26 @@
+# These templates have been reviewed by the debian-l10n-english
+# team
+#
+# If modifications/additions/rewording are needed, please ask
+# debian-l10n-engl...@lists.debian.org for advice.
+#
+# Even minor modifications require translation updates and such
+# changes should be coordinated with translators and reviewers.
+
 Template: dyfi/username
 Type: string
-_Description: username:
+_Description: Username on dy.fi:
+ Please provide the username that should be used to log in to dy.fi
+ services and update dynamic hostname mappings.
 
 Template: dyfi/password
 Type: password
-_Description: password:
+_Description: Password on dy.fi:
+ Please provide the password that should be used to log in to dy.fi
+ services and update dynamic hostname mappings.
 
 Template: dyfi/hosts
 Type: string
-_Description: hostnames registered (space separated):
+_Description: Registered hostnames on dy.fi:
+ Please provide a space-separated list of hostnames that should be
+ dynamically updated by dy.fi services.
--- dyfi.old/debian/control 2015-09-21 15:57:09.673240136 +0200
+++ dyfi/debian/control 2015-10-02 18:42:27.835930881 +0200
@@ -12,11 +12,10 @@
 Depends: ${misc:Depends}, ${perl:Depends}, adduser, libwww-perl
 Pre-Depends: debconf
 Architecture: all
-Description: Client for updating dynamic hostname mappings for dy.fi
- This is a client software (which runs as daemon) for automatically updating
- dynamic hostname mappings at dy.fi - free dynamic DNS service offered
- exclusively for Finnish users.
+Description: client for updating dynamic hostname mappings for dy.fi
+ This package provides a client (which runs as a daemon) for
+ automatically updating dynamic hostname mappings at dy.fi - a free
+ dynamic DNS service offered exclusively for Finnish users.
  .
- This client software lets you configure your credentials and hostname(s)
- upon install. These credentials and hostname(s) must be registered at dy.fi
- website beforehand.
+ On install, this client lets you configure your credentials and
+ hostname(s), which must be registered at the dy.fi website beforehand.
--- dyfi.old/debian/changelog   2015-09-21 15:57:09.673240136 +0200
+++ dyfi/debian/changelog   2015-11-02 14:19:58.320320033 +0100
@@ -1,3 +1,19 @@
+dyfi (1.2.0-3) UNRELEASED; urgency=low
+
+  * Debconf templates and debian/control reviewed by the debian-l10n-
+english team as part of the Smith review project. Closes: #799685
+  * [Debconf translation updates]
+  * German (Mario Blättermann).  Closes: #802152
+  * Czech (Michal Simunek).  Closes: #802486
+  * Russian (Yuri Kozlov).  Closes: #803168
+  * Spanish; (Camaleón).  Closes: #803309
+  * Dutch; (Frans Spiesschaert).  Closes: #803506
+  * Danish (Joe Hansen).  Closes: #803581
+  * Portuguese ().  Closes: #803637
+  * French (Julien Patriarca).  Closes: #803751
+
+ -- Christian Perrier   Mon, 21 Sep 2015 18:42:07 +0200
+
 dyfi (1.2.0-2) unstable; urgency=medium
 
   * Add Vcs URL's


signature.asc
Description: PGP signature

Bug#804125: ITP: golang-github-kr-pty -- PTY interface for Go

[Potter, Tim (Converged Cloud)]

X-Debbugs-CC: debian-de...@lists.debian.org, 
pkg-go-maintain...@lists.alioth.debian.org
Package: wnpp
Severity: wishlist
Owner: Tim Potter 

* Package name: golang-github-kr-pty
  Version : 0.0~git20151007.29.f7ee69f-1
  Upstream Author : Keith Rarick
* URL : https://github.com/kr/pty
* License : Expat
  Programming Lang: Go
  Description : PTY interface for Go

 Pty is a Go package for using UNIX pseudo-terminals.

Bug#804124: xfce4-smartbookmark-plugin: plugin flashing in panel1

[おとめ座 ひなたぼっこ]

Package: xfce4-smartbookmark-plugin
Version: 0.4.6-2
Severity: normal

Dear Maintainer,

*** Reporter, please consider answering these questions, where appropriate ***

   * What led up to the situation?
add the plugin to panel1
   * What exactly did you do (or not do) that was effective (or
 ineffective)?
enter text in to input box
   * What was the outcome of this action?
the whole panel1 flashing
   * What outcome did you expect instead?
enter text then automatically open browser

*** End of the template - remove these template lines ***



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

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

Versions of packages xfce4-smartbookmark-plugin depends on:
ii  libatk1.0-0  2.18.0-1
ii  libc62.19-22
ii  libcairo21.14.2-2
ii  libfontconfig1   2.11.0-6.3
ii  libfreetype6 2.6-2
ii  libgdk-pixbuf2.0-0   2.32.1-1
ii  libglib2.0-0 2.46.1-1
ii  libgtk2.0-0  2.24.28-1
ii  libpango-1.0-0   1.38.1-1
ii  libpangocairo-1.0-0  1.38.1-1
ii  libpangoft2-1.0-01.38.1-1
ii  libxfce4ui-1-0   4.12.1-2
ii  libxfce4util74.12.1-2
ii  xfce4-panel  4.12.0-3

xfce4-smartbookmark-plugin recommends no packages.

xfce4-smartbookmark-plugin suggests no packages.

-- no debconf information

Bug#804123: ITP: golang-github-beorn7-perks -- effective computation of things

[Dmitry Smirnov]

Package: wnpp
Severity: wishlist
X-Debbugs-CC: debian-de...@lists.debian.org 
pkg-go-maintain...@lists.alioth.debian.org

   Package name: golang-github-beorn7-perks
Version: 0.0~git20150223.0.b965b61
Upstream Author: Blake Mizerany
License: Expat
URL: https://github.com/beorn7/perks
Description: effective computation of things
 Perks contains the Go package quantile that computes approximate quantiles
 over an unbounded data stream within low memory and CPU bounds.


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

Bug#804122: FTBFS on hurd-i386 due to test breakages

[Tom Lee]

Package: capnproto
Version: 0.5.3-1

A few tests breaking due to EMIG_REPLY_MISMATCH:

[ RUN  ] AsyncUnixTest.SignalsNoWait
unknown file: Failure
C++ exception with description "src/kj/async-unix.c++:667: failed:
poll(): (ipc/mig) wrong reply message ID" thrown in the test body.
[  FAILED  ] AsyncUnixTest.SignalsNoWait (10 ms)

[ RUN  ] AsyncUnixTest.Wake
unknown file: Failure
C++ exception with description "src/kj/async-unix.c++:667: failed:
poll(): (ipc/mig) wrong reply message ID" thrown in the test body.
[  FAILED  ] AsyncUnixTest.Wake (0 ms)


Other tests busted due to unsupported socket options:

[--] 6 tests from SerializeAsyncTest
[ RUN  ] SerializeAsyncTest.ParseAsync
unknown file: Failure
C++ exception with description
"src/capnp/serialize-async-test.c++:111: unimplemented:
setsockopt(fds[0], SOL_SOCKET, SO_RCVBUF, &small, sizeof(small)):
Protocol not available" thrown in the test fixture's constructor.
[  FAILED  ] SerializeAsyncTest.ParseAsync (0 ms)
[ RUN  ] SerializeAsyncTest.ParseAsyncOddSegmentCount
unknown file: Failure
C++ exception with description
"src/capnp/serialize-async-test.c++:111: unimplemented:
setsockopt(fds[0], SOL_SOCKET, SO_RCVBUF, &small, sizeof(small)):
Protocol not available" thrown in the test fixture's constructor.
[  FAILED  ] SerializeAsyncTest.ParseAsyncOddSegmentCount (0 ms)
[ RUN  ] SerializeAsyncTest.ParseAsyncEvenSegmentCount
unknown file: Failure
C++ exception with description
"src/capnp/serialize-async-test.c++:111: unimplemented:
setsockopt(fds[0], SOL_SOCKET, SO_RCVBUF, &small, sizeof(small)):
Protocol not available" thrown in the test fixture's constructor.
[  FAILED  ] SerializeAsyncTest.ParseAsyncEvenSegmentCount (0 ms)
[ RUN  ] SerializeAsyncTest.WriteAsync
unknown file: Failure
C++ exception with description
"src/capnp/serialize-async-test.c++:111: unimplemented:
setsockopt(fds[0], SOL_SOCKET, SO_RCVBUF, &small, sizeof(small)):
Protocol not available" thrown in the test fixture's constructor.
[  FAILED  ] SerializeAsyncTest.WriteAsync (0 ms)
[ RUN  ] SerializeAsyncTest.WriteAsyncOddSegmentCount
unknown file: Failure
C++ exception with description
"src/capnp/serialize-async-test.c++:111: unimplemented:
setsockopt(fds[0], SOL_SOCKET, SO_RCVBUF, &small, sizeof(small)):
Protocol not available" thrown in the test fixture's constructor.
[  FAILED  ] SerializeAsyncTest.WriteAsyncOddSegmentCount (0 ms)
[ RUN  ] SerializeAsyncTest.WriteAsyncEvenSegmentCount
unknown file: Failure
C++ exception with description
"src/capnp/serialize-async-test.c++:111: unimplemented:
setsockopt(fds[0], SOL_SOCKET, SO_RCVBUF, &small, sizeof(small)):
Protocol not available" thrown in the test fixture's constructor.
[  FAILED  ] SerializeAsyncTest.WriteAsyncEvenSegmentCount (0 ms)

Haven't seen these errors manifest on other archs yet, though still waiting
on buildd for some.

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

Bug#748533: Processed: Re: still unable to print

[Jameson Graef Rollins]

On Wed, Nov 04 2015, Scott Kitterman  wrote:
> Okular already Recommends cups-bsd, so reopening the bug that suggests it be 
> added makes no sense.

Hi, Scott.  I appreciate the response, but I still think we're missing
the point.  The real question is, if the bug was fixed, why am I still
suffering from it?  Just saying "install cups-bsd" is not actually a
good solution to the problem.  If for whatever reason the user doesn't
have cups-bsd installed, they have no way to know that the problem is
the lack of that package.  In the interest of user it would be a lot
more generous to provide a notification that printing is not possible
without the cups-bsd package installed.

jamie.


signature.asc
Description: PGP signature

Bug#804121: ITP: golang-github-coreos-go-oidc -- Go libraries for implementing OIDC clients and servers

[Potter, Tim (Converged Cloud)]

X-Debbugs-CC: debian-de...@lists.debian.org, 
pkg-go-maintain...@lists.alioth.debian.org
Package: wnpp
Severity: wishlist
Owner: Tim Potter 

* Package name: golang-github-coreos-go-oidc
  Version : 0.0~git20151022.0.e9c0807-1
  Upstream Author : CoreOS
* URL : https://github.com/coreos/go-oidc
* License : Apache-2.0
  Programming Lang: Go
  Description : Go libraries for implementing OIDC clients and servers

 This package provides a comprehensive collection of golang libraries
 for other projects to implement OpenID Connect (OIDC) server and
 client components.

Bug#748533: Processed: Re: still unable to print

[Scott Kitterman]

On November 4, 2015 11:48:17 PM EST, Jameson Graef Rollins 
 wrote:
>On Wed, Nov 04 2015, Maximiliano Curia  wrote:
>> Please avoid reopening old bugs, it's better to ask in the debian-kde
>users
>> list or in the #debian-kde irc channel, if that wouldn't help then
>open a new
>> one. The issue that was reported here was fixed: cups-bsd was added
>as a
>> recommends.
>
>Hi, Max.  Thanks for the response.
>
>I don't see the problem with re-opening old bugs if that is what is
>called for.  If the problem persists, then clearly the problem was not
>fully addressed, which is the situation here.  I was experiencing a
>failure to print from okular.  I did due diligence in searching for an
>existing bug that addressed the issue, rather than blindly filing a new
>report.  I found the bug that I referenced, and since the closing of
>that report didn't describe how the problem was fixed I reopened it as
>not fixed.  I think that was all completely justified.
>
>> Also, when you send a message to control your mail is not shown in
>the bug,
>> you need to cc the bug for that.
>
>I tried cc'ing the bug, but the message was bounced because the bug had
>been archived.
>
>> okular uses the lpr from cups, if you have a different lpr it needs
>to accept
>> the same parameters. You could try:
>> apt install cups-bsd lpr- lprng- gnuspool-
>
>This might be a fix, but I don't think it's actually a suitable
>solution
>to the overall problem.  Without cups-bsd installed, okular just
>silently fails to print.  There is no notification to the user other
>than a cryptic message to the terminal that would only ever be seen if
>you were to launch okular from the terminal (which certainly most
>people
>don't do).  It seems like a better solution could be devised.

Okular already Recommends cups-bsd, so reopening the bug that suggests it be 
added makes no sense.

Scott K

Bug#804120: pulseaudio: iceweasel->Tools->Add-ons ... (silence)

[Kingsley G. Morse Jr.]

Package: pulseaudio
Version: 7.0-1+b1
Severity: important

I seem to have found a bug.

Here's how:

1.) Use Debian's unstable repository

2.) $ apt-get dist-upgrade  # On November 4, 2015

3.) Edit /etc/pulse/client.conf to not autospawn pulseaudio

#; autospawn = yes
; autospawn = no

4.) Reboot.

5.) Run pulseaudio with verbose diagnostics as
a normal user on an xterm's command line
with

$ pulseaudio -vv --log-time 

6.) Launch iceweasel.

7.) Play sound with

$ echo "hello world" | festival --language americanenglish -b --tts

8.) Here's where the bug happens. 

Use your mouse to access iceweasel's add-on manager

iceweasel->Tools->Add-ons

Pulseaudio says

( 123.846|   5.004) I: [pulseaudio] module-suspend-on-idle.c: Sink 
alsa_output.pci-_03_05.0.analog-stereo idle for too long, suspending ...
( 123.846|   0.000) D: [pulseaudio] sink.c: Suspend cause of sink 
alsa_output.pci-_03_05.0.analog-stereo is 0x0004, suspending
( 123.846|   0.000) I: [alsa-sink-ES1371/1] alsa-sink.c: Device 
suspended...
( 123.846|   0.000) D: [pulseaudio] core.c: Hmm, no streams around, 
trying to vacuum.
( 123.847|   0.000) D: [pulseaudio] module-udev-detect.c: 
/dev/snd/controlC0 is accessible: yes
( 123.847|   0.000) D: [pulseaudio] module-udev-detect.c: Resuming 
all sinks and sources of card alsa_card.pci-_03_05.0.
( 125.621|   1.774) I: [pulseaudio] client.c: Created 5 "Native 
client (UNIX socket client)"
( 125.622|   0.000) D: [pulseaudio] protocol-native.c: Protocol 
version: remote 30, local 30
( 125.622|   0.000) I: [pulseaudio] protocol-native.c: Got 
credentials: uid=1000 gid=1000 success=1
( 125.622|   0.000) D: [pulseaudio] protocol-native.c: SHM 
possible: yes
( 125.622|   0.000) D: [pulseaudio] protocol-native.c: Negotiated 
SHM: no
( 125.622|   0.000) D: [pulseaudio] protocol-native.c: Disabling 
srbchannel, reason: No SHM support
( 125.624|   0.002) D: [pulseaudio] module-augment-properties.c: 
Looking for .desktop file for iceweasel
( 125.624|   0.000) D: [pulseaudio] module-augment-properties.c: 
Found /usr/share/applications/iceweasel.desktop.
( 125.624|   0.000) D: [pulseaudio] conf-parser.c: Parsing 
configuration file '/usr/share/applications/iceweasel.desktop'

9.) Try to play sound again

$ echo "hello world" | festival --language americanenglish -b --tts

Silence!

festival says

ALSA lib pulse.c:243:(pulse_connect) PulseAudio: Unable to connect: 
Protocol error

aplay: main:722: audio open error: Connection refused

I 

a.) expected to hear festival say "hello world", and

b.) am surprised pulseaudio's module-augment-properties.c:
looked for a .desktop file for iceweasel.

I hope that helps,
Kingsley


-- Package-specific info:
File '/etc/default/pulseaudio' does not exist


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

Kernel: Linux 4.2.0-1-686-pae (SMP w/2 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash
Init: systemd (via /run/systemd/system)

Versions of packages pulseaudio depends on:
ii  adduser   3.113+nmu3
ii  libasound21.0.29-1
ii  libasound2-plugins1.0.29-1
ii  libc6 2.19-22
ii  libcap2   1:2.24-12
ii  libdbus-1-3   1.10.2-1
ii  libfftw3-single3  3.3.4-2
ii  libgcc1   1:5.2.1-23
ii  libice6   2:1.0.9-1+b1
ii  libltdl7  2.4.2-1.11
ii  liborc-0.4-0  1:0.4.24-1
ii  libpulse0 7.0-1+b1
ii  libsm62:1.2.2-1+b1
ii  libsndfile1   1.0.25-9.1
ii  libspeexdsp1  1.2~rc1.2-1
ii  libstdc++65.2.1-23
ii  libsystemd0   227-2
ii  libtdb1   1.3.7-1
ii  libudev1  227-2
ii  libwebrtc-audio-processing-0  0.1-3
ii  libx11-6  2:1.6.3-1
ii  libx11-xcb1   2:1.6.3-1
ii  libxcb1   1.11.1-1
ii  libxtst6  2:1.2.2-1+b1
ii  lsb-base  9.20150917
ii  pulseaudio-utils  7.0-1+b1
ii  udev  227-2

Versions of packages pulseaudio recommends:
ii  pulseaudio-module-x11  7.0-1+b1
ii  rtkit  0.11-4

Versions of packages pulseaudio suggests:
pn  paman
pn  paprefs  
ii  pavucontrol  3.0-3+b2
pn  pavumeter

-- no debconf information
# This file is part of PulseAudio

Bug#804119: Package 1.9.1

[Matt Kraai]

Package: unar

Hi,

I noticed that upstream has released unar 1.9.1.  It should be
packaged.

-- 
Matt   https://ftbfs.org/~kraai/

Bug#804118: Please add Michael Lustfield (MTecknology) as a Debian Maintainer

[Michael Lustfield]

Package: debian-maintainers
Severity: normal

Please add Michael Lustfield (MTecknology)  to the
Debian Maintainers keyring. I have attached the jetstring changeset.

Thanks!
-- 
Michael Lustfield


pgpyvInxdFQCh.pgp
Description: OpenPGP digital signature

Bug#769751: ekiga: Ekiga segfaults as soon as SIP call connects

[John Sullivan]

Eugen Dedu  writes:

> On 16/11/14 05:50, John Sullivan wrote:
>> Whether I'm placing or receiving the call, Ekiga segfaults as soon as
>> a SIP connection starts. It's been doing this for some months for me,
>> but prior to that it was working on this system (which has been
>> through many changes, being unstable).
>>
>> I've tested with video on and off, and with two different SIP servers.
>>
>> When I place the call, as soon as the other person answers, it
>> crashes. Sometimes I can see the video for a moment first.
>>
>> When I receive the call, as soon as I click answer, it crashes.
>
> Hi Sullivan, and thank you for the bug report!
>
> I need a gdb stack, cf.
> http://wiki.ekiga.org/index.php/Debugging_Ekiga#How_to_get_a_stack_backtrace_from_a_crash_or_freeze,
> and better with -d 4 included.  If you have confidentiality concerns,
> you can send them to me privately.
>
> Kind regards,

I can no longer reproduce this with ekiga 4.0.1-6+b1. So as far as I'm
concerned, this can be closed. :)

-john

Bug#803013: systemd should not destroy application created cgroups

[paul . szabo]

Dear Michael,

> I'm not able to reproduce the issue either.
> ... this looks like something specific to your system configuration, a
> default jessie system doesn't seem to be affected.

I found what causes reproducibility: editing the file
  /etc/pam.d/common-session
and removing or commenting out the optional(?!!) line
  session   optionalpam_systemd.so
makes the issue reproducible. - Curiously, removing that line also
causes GDM3 to become unusable (and I was thinking it was just too buggy
to be used... which it is, really).

I wonder how that line came to be missed on my machines: I upgraded from
wheezy (which was upgraded from previous releases).

So, to reproduce the issue, on a "plain jessie" machine (e.g. freshly
installed from debian-8.2.0-amd64-netinst.iso):
 - Edit the file
 /etc/pam.d/common-session
   and remove or comment out the line
 session optional pam_systemd.so
   then reboot.
 - Log in to the machine; probably not via GDM3 as that might not work
   at all; not via getty as then the issue will not show(?!!); but log
   in via XDM, or via telnetd or sshd. (Wonder if sshd login with keys
   would bypass PAM and then not need the editing above.)
 - Become root (log in as such, or use su).
 - As root, do commands:
 # Set things up
 mkdir /sys/fs/cgroup/cpu/mytest
 echo $$ > /sys/fs/cgroup/cpu/mytest/tasks
 # Check it is there
 grep . /sys/fs/cgroup/cpu/mytest/tasks
 # Do the systemd thing
 systemctl daemon-reload
 systemctl start anacron
 # See it gone
 grep . /sys/fs/cgroup/cpu/mytest/tasks

Cheers, Paul

Paul Szabo   p...@maths.usyd.edu.au   http://www.maths.usyd.edu.au/u/psz/
School of Mathematics and Statistics   University of SydneyAustralia

Bug#804117: sysv-rc: invoke-rc.d shuts down and does not restart daemons started by systemd targets

[Karl O. Pinc]

Package: sysv-rc
Version: 2.88dsf-59
Severity: normal

Hi,

When a daemon is started by a systemd target, and not by
the sysV runlevel, upgrading the package (which I presume
runs invoke-rc.d to restart the daemon) stops the daemon
and does not restart it.

As an example, I do not want to start MariaDB until
the cryptfs it uses is manually unlocked.  The sysV
system is configured to not start MariaDB, so that at
boot it does not try to start and fail because the cryptfs
is locked.   After the cryptfs is unlocked MariaDB
(and some other stuff) is started via a systemd
target.  The MariaDB package is supposed
to restart the daemon, but instead with
this configuration an upgrade stops the daemon
and never restarts it.  (So, something like
cron-apt or unattended-upgrades is ungood.)

I can't tell if this has to do with bug #768450 or not.

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

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

Versions of packages sysv-rc depends on:
ii  debconf [debconf-2.0]  1.5.56
ii  insserv1.14.0-5
ii  startpar   0.59-3
ii  sysvinit-utils 2.88dsf-59

Versions of packages sysv-rc recommends:
ii  lsb-base  4.1+Debian13+nmu1

Versions of packages sysv-rc suggests:
pn  bum  

-- debconf information:
  sysv-rc/unable-to-convert:

Bug#804116: ruby-mousetrap-rails: unhandled symlink to directory conversion: /usr/share/ruby-mousetrap-rails/vendor/assets/javascripts/mousetrap

[Andreas Beckmann]

Package: ruby-mousetrap-rails
Version: 1.4.6-3
Severity: serious
User: debian...@lists.debian.org
Usertags: piuparts

Hi,

an upgrade test with piuparts revealed that your package installs files
over existing symlinks and possibly overwrites files owned by other
packages. This usually means an old version of the package shipped a
symlink but that was later replaced by a real (and non-empty)
directory. This kind of overwriting another package's files cannot be
detected by dpkg.

This was observed on the following upgrade paths:

  stretch -> sid

For /usr/share/doc/PACKAGE this may not be problematic as long as both
packages are installed, ship byte-for-byte identical files and are
upgraded in lockstep. But once one of the involved packages gets
removed, the other one will lose its documentation files, too,
including the copyright file, which is a violation of Policy 12.5:
https://www.debian.org/doc/debian-policy/ch-docs.html#s-copyrightfile

For other overwritten locations anything interesting may happen.

Note that dpkg intentionally does not replace directories with symlinks
and vice versa, you need the maintainer scripts to do this.
See in particular the end of point 4 in
https://www.debian.org/doc/debian-policy/ch-maintainerscripts.html#s-unpackphase

It is recommended to use the dpkg-maintscript-helper commands
'dir_to_symlink' and 'symlink_to_dir' (available since dpkg 1.17.14)
to perform the conversion, ideally using d/$PACKAGE.maintscript.
Do not forget to add 'Pre-Depends: ${misc:Pre-Depends}' in d/control.
See dpkg-maintscript-helper(1) and dh_installdeb(1) for details.


>From the attached log (usually somewhere in the middle...):

3m16.4s ERROR: FAIL: silently overwrites files via directory symlinks:
  
/usr/share/ruby-mousetrap-rails/vendor/assets/javascripts/mousetrap/dictionary.js
 (ruby-mousetrap-rails) != /usr/share/javascript/mousetrap/dictionary.js 
(libjs-mousetrap)
/usr/share/ruby-mousetrap-rails/vendor/assets/javascripts/mousetrap -> 
../../../../javascript/mousetrap
  /usr/share/ruby-mousetrap-rails/vendor/assets/javascripts/mousetrap/global.js 
(ruby-mousetrap-rails) != /usr/share/javascript/mousetrap/global.js 
(libjs-mousetrap)
/usr/share/ruby-mousetrap-rails/vendor/assets/javascripts/mousetrap -> 
../../../../javascript/mousetrap
  /usr/share/ruby-mousetrap-rails/vendor/assets/javascripts/mousetrap/pause.js 
(ruby-mousetrap-rails) != /usr/share/javascript/mousetrap/pause.js 
(libjs-mousetrap)
/usr/share/ruby-mousetrap-rails/vendor/assets/javascripts/mousetrap -> 
../../../../javascript/mousetrap
  
/usr/share/ruby-mousetrap-rails/vendor/assets/javascripts/mousetrap/plugins.js 
(ruby-mousetrap-rails) != /usr/share/javascript/mousetrap/plugins.js 
(libjs-mousetrap)
/usr/share/ruby-mousetrap-rails/vendor/assets/javascripts/mousetrap -> 
../../../../javascript/mousetrap
  /usr/share/ruby-mousetrap-rails/vendor/assets/javascripts/mousetrap/record.js 
(ruby-mousetrap-rails) != /usr/share/javascript/mousetrap/record.js 
(libjs-mousetrap)
/usr/share/ruby-mousetrap-rails/vendor/assets/javascripts/mousetrap -> 
../../../../javascript/mousetrap
3m16.4s DEBUG: Starting command: ['debsums', '--root', 
'/tmp/piupartss/tmplyxaro', '-ac']

3m17.2s ERROR: FAIL: debsums reports modifications inside the chroot:
  debsums: missing file /usr/share/javascript/mousetrap/dictionary.js (from 
libjs-mousetrap package)
  debsums: missing file /usr/share/javascript/mousetrap/global.js (from 
libjs-mousetrap package)
  debsums: missing file /usr/share/javascript/mousetrap/pause.js (from 
libjs-mousetrap package)
  debsums: missing file /usr/share/javascript/mousetrap/plugins.js (from 
libjs-mousetrap package)
  debsums: missing file /usr/share/javascript/mousetrap/record.js (from 
libjs-mousetrap package)


cheers,

Andreas


ruby-mousetrap-rails_1.4.6-3.log.gz
Description: application/gzip

Bug#801356: ITP: python-acme -- ACME protocol library for Python 2

[Harlan Lieberman-Berg]

Johannes Schauer  writes:
> Segmentation fault
> E: pybuild pybuild:274: test: plugin distutils failed with: exit code=139: 
> python2.7 setup.py test 
> dh_auto_test: pybuild --test -i python{version} -p 2.7 --dir . returned exit 
> code 13

Interesting.  I haven't seen this error at all, actually.  Was it
reproducible, or was it transient?

Also, what suite were you building on?  I've, admittedly, only tested on sid.

Sincerely,
-- 
Harlan Lieberman-Berg
~hlieberman

Bug#804115: python3-ndg-httpsclient not installable with python-ndg-httpsclient

[Harlan Lieberman-Berg]

Package: python3-ndg-httpsclient
Severity: normal

Dear Maintainer,

Thanks for distributing python3-ndg-httpsclient!  Unfortunately, I need both of
them to be co-installable in order to satisfy the build-depends for this
package (since I'm trying to build python2 and python3 versions of it, I need
all of the python2 and all of the python3 deps installed at the same time.
Oy.)

Would it be possible for you to only ship the binary scripts in one of the two,
and remove the Conflicts?

Thanks!



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

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

-- 
Harlan Lieberman-Berg
~hlieberman

Bug#803914: fixed in ejabberd-contrib 0.2015.10.26~dfsg0-1

[Andreas Beckmann]

Control: clone -1 -2
Control: reassign -1 ejabberd-mod-http-upload 0.2015.10.02~dfsg0-1
Control: fixed -1 ejabberd-contrib/0.2015.10.26~dfsg0-1
Control: reassign -2 ejabberd 15.10-1
Control: reopen -2
Control: retitle -1 ejabberd: needs Breaks+Replaces: ejabberd-mod-http-upload

On Tue, 03 Nov 2015 19:49:03 + Philipp Huebner  wrote:
> Changes:
>  ejabberd-contrib (0.2015.10.26~dfsg0-1) unstable; urgency=medium
>* Disabled building of mod_http_upload, it's now part of ejabberd
>  (Closes: 803914)

This fixes only one half of the problem. ejabberd still needs to add 
Breaks+Replaces against ejabberd-mod-http-upload.


Andreas

Bug#804113: cme: conffiles not removed

[Paul Wise]

Package: cme
Version: 1.007-1
Severity: normal
User: debian...@lists.debian.org
Usertags: obsolete-conffile adequate

The recent upgrade did not deal with obsolete conffiles properly.
Please use the dpkg-maintscript-helper support provided by dh_installdeb
to remove these obsolete conffiles on upgrade.

https://www.debian.org/doc/debian-policy/ch-files.html#s-config-files
http://manpages.debian.org/man/1/dh_installdeb

This bug report brought to you by adequate:

http://bonedaddy.net/pabs3/log/2013/02/23/inadequate-software/

$ pkg=cme ; adequate $pkg ; dpkg-query -W -f='${Conffiles}\n' $pkg | grep 
obsolete
cme: obsolete-conffile /etc/bash_completion.d/cme
$ /etc/bash_completion.d/cme 35091cd4cd9f0926a172252453bb8a84 obsolete

-- System Information:
Debian Release: stretch/sid
  APT prefers testing
  APT policy: (900, 'testing'), (860, 'testing-proposed-updates'), (850, 
'buildd-testing-proposed-updates'), (800, 'unstable'), (790, 
'buildd-unstable'), (700, 'experimental'), (690, 'buildd-experimental')
Architecture: amd64 (x86_64)

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

Versions of packages cme depends on:
ii  libapp-cmd-perl   0.330-1
ii  libconfig-model-perl  2.074-1
ii  libpath-tiny-perl 0.072-1
ii  libpod-pom-perl   0.29-2
ii  perl  5.20.2-6

Versions of packages cme recommends:
pn  libconfig-model-approx-perl   
ii  libconfig-model-dpkg-perl 2.069
pn  libconfig-model-lcdproc-perl  
pn  libconfig-model-openssh-perl  
pn  libconfig-model-tkui-perl 

Versions of packages cme suggests:
pn  libconfig-model-cursesui-perl  
pn  libconfig-model-itself-perl

-- no debconf information

-- 
bye,
pabs

https://wiki.debian.org/PaulWise




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

Bug#804112: FTBS due to test failure in AsyncUnixTest.SignalWith{,Pointer}Value on some archs

[Tom Lee]

Package: capnproto
Version: 0.5.3-1

mips, powerpc, hppa appear to be affected, possibly others -- still waiting
on buildds after the most recent upload. Suspect it's related to
https://lkml.org/lkml/2015/2/10/159 but yet to confirm.

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

Bug#804111: lava-server: fails to install: The name 'physical-group' is invalid related_name for field Device.physical_group

[Andreas Beckmann]

Package: lava-server
Version: 2015.11-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...):

  Selecting previously unselected package lava-server.
  (Reading database ... 
(Reading database ... 26380 files and directories currently installed.)
  Preparing to unpack .../lava-server_2015.11-1_all.deb ...
  Unpacking lava-server (2015.11-1) ...
  Processing triggers for systemd (227-2) ...
  Setting up lava-server (2015.11-1) ...
  
WARNING:py.warnings:/usr/lib/python2.7/dist-packages/dashboard_app/models.py:36:
 RemovedInDjango19Warning: django.contrib.contenttypes.generic is deprecated 
and will be removed in Django 1.9. Its contents have been moved to the fields, 
forms, and admin submodules of django.contrib.contenttypes.
from django.contrib.contenttypes import generic
  
  
Error: System check identified some issues:
  

AndreaRORS:
  va_scheduler_app.Device.physical_group: (fields.E306) The name 
'physical-group' is invalid related_name for field Device.physical_group
HINT: Related name must be a valid Python identifier or end with a 
'+'va_scheduler_app.Device.physical_owner: (fields.E306) The name 
'physical-owner' is invalid related_name for field Device.physical_owner
HINT: Related name must be a valid Python identifier or end with a 
'+'RNINGS:
  
ogle_analytics.Analytic.site: (fields.W342) Setting unique=True on a ForeignKey 
has the same effect as using a OneToOneField.
HINT: ForeignKey(unique=True) is usually better served by a 
OneToOneField.va_scheduler_app.Device.current_job: (fields.W342) Setting 
unique=True on a ForeignKey has the same effect as using a OneToOneField.
HINT: ForeignKey(unique=True) is usually better served by a 
OneToOneField.va_scheduler_app.Device.last_health_report_job: (fields.W342) 
Setting unique=True on a ForeignKey has the same effect as using a 
OneToOneField.
HINr: ForeignKey(unique=True) is usually better served by a 
OneToOneField.va_scheduler_app.DeviceType.cores: (fields.W340) null has no 
effect on ManyToManyField.va_scheduler_app.TestJob.viewing_groups: 
(fields.W340) null has no effect on ManyToManyField.
r processing package lava-server (--configure):
   subprocess installed post-installation script returned error exit status 1
  Processing triggers for systemd (227-2) ...
  Errors were encountered while processing:
   lava-server


lava-server_2015.11-1.log.gz
Description: application/gzip

Bug#804110: xserver-xorg-video-nouveau: fresh install debian-8.2.0-amd64, Xfce yields black screen at login

[David Christensen]

Package: xserver-xorg-video-nouveau
Version: 1:1.0.11-1
Severity: important

Dear Maintainer,

Today I did a fresh install of debian-8.2.0-amd64 on a Dell Latitude E6520
with an Nvidia NVS-4200M (N12P-NS2) graphics adapter.

After rebooting, the login screen briefly flashes on the screen and then the
 screen goes black.

STFW I see various similar bugs/issues, but not an exact match.

David



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

lrwxrwxrwx 1 root root 13 Nov  4 12:57 /etc/X11/X -> /usr/bin/Xorg
-rwxr-xr-x 1 root root 2401376 Feb 10  2015 /usr/bin/Xorg

VGA-compatible devices on PCI bus:
--
01:00.0 VGA compatible controller [0300]: NVIDIA Corporation GF119M [NVS 4200M] 
[10de:1056] (rev a1)

/etc/X11/xorg.conf does not exist.

/etc/X11/xorg.conf.d does not exist.

/etc/modprobe.d contains no KMS configuration files.

Kernel version (/proc/version):
---
Linux version 3.16.0-4-amd64 (debian-ker...@lists.debian.org) (gcc version 
4.8.4 (Debian 4.8.4-1) ) #1 SMP Debian 3.16.7-ckt11-1+deb8u5 (2015-10-09)

Xorg X server log files on system:
--
-rw-r--r-- 1 root root 79357 Nov  4 18:31 /var/log/Xorg.0.log

Contents of most recent Xorg X server log file (/var/log/Xorg.0.log):
-
[45.976] 
X.Org X Server 1.16.4
Release Date: 2014-12-20
[45.976] X Protocol Version 11, Revision 0
[45.976] Build Operating System: Linux 3.16.0-4-amd64 x86_64 Debian
[45.976] Current Operating System: Linux i72720qm 3.16.0-4-amd64 #1 SMP 
Debian 3.16.7-ckt11-1+deb8u5 (2015-10-09) x86_64
[45.976] Kernel command line: BOOT_IMAGE=/vmlinuz-3.16.0-4-amd64 
root=/dev/mapper/sda3_crypt ro quiet
[45.977] Build Date: 11 February 2015  12:32:02AM
[45.977] xorg-server 2:1.16.4-1 (http://www.debian.org/support) 
[45.977] Current version of pixman: 0.32.6
[45.977]Before reporting problems, check http://wiki.x.org
to make sure that you have the latest version.
[45.977] Markers: (--) probed, (**) from config file, (==) default setting,
(++) from command line, (!!) notice, (II) informational,
(WW) warning, (EE) error, (NI) not implemented, (??) unknown.
[45.977] (==) Log file: "/var/log/Xorg.0.log", Time: Wed Nov  4 18:31:19 
2015
[45.978] (==) Using system config directory "/usr/share/X11/xorg.conf.d"
[45.980] (==) No Layout section.  Using the first Screen section.
[45.980] (==) No screen section available. Using defaults.
[45.980] (**) |-->Screen "Default Screen Section" (0)
[45.980] (**) |   |-->Monitor ""
[45.980] (==) No monitor specified for screen "Default Screen Section".
Using a default monitor configuration.
[45.980] (==) Automatically adding devices
[45.980] (==) Automatically enabling devices
[45.980] (==) Automatically adding GPU devices
[45.981] (WW) The directory "/usr/share/fonts/X11/cyrillic" does not exist.
[45.981]Entry deleted from font path.
[45.983] (==) FontPath set to:
/usr/share/fonts/X11/misc,
/usr/share/fonts/X11/100dpi/:unscaled,
/usr/share/fonts/X11/75dpi/:unscaled,
/usr/share/fonts/X11/Type1,
/usr/share/fonts/X11/100dpi,
/usr/share/fonts/X11/75dpi,
built-ins
[45.983] (==) ModulePath set to "/usr/lib/xorg/modules"
[45.983] (II) The server relies on udev to provide the list of input 
devices.
If no devices become available, reconfigure udev or disable 
AutoAddDevices.
[45.983] (II) Loader magic: 0x7f9c03639d80
[45.983] (II) Module ABI versions:
[45.983]X.Org ANSI C Emulation: 0.4
[45.983]X.Org Video Driver: 18.0
[45.983]X.Org XInput driver : 21.0
[45.983]X.Org Server Extension : 8.0
[45.985] (--) PCI:*(0:1:0:0) 10de:1056:1028:0494 rev 161, Mem @ 
0xe300/16777216, 0xd000/268435456, 0xe000/33554432, I/O @ 
0x3000/128, BIOS @ 0x/524288
[45.985] (II) LoadModule: "glx"
[45.985] (II) Loading /usr/lib/xorg/modules/extensions/libglx.so
[46.000] (II) Module glx: vendor="X.Org Foundation"
[46.000]compiled for 1.16.4, module version = 1.0.0
[46.000]ABI class: X.Org Server Extension, version 8.0
[46.000] (==) AIGLX enabled
[46.000] (==) Matched nouveau as autoconfigured driver 0
[46.000] (==) Matched nv as autoconfigured driver 1
[46.000] (==) Matched modesetting as autoconfigured driver 2
[46.000] (==) Matched fbdev as autoconfigured driver 3
[46.000] (==) Matched vesa as autoconfigured driver 4
[46.000] (==) Assigned the driver to the xf86ConfigLayout
[46.000] (II) LoadModule: "nouveau"
[46.002] (II) Loading /usr/lib/xorg/modules/drivers/nouveau_drv.so
[46.005] (II) Module nouveau: vendor="X.Org Foundation"
[46.005]compiled for 1.16.0, module version = 1.0.11
[46.005]Module class: X.Org Vide

Bug#804109: libvirtuoso5.5-cil: fails to install: E: installing Assembly /usr/lib/cli/virtuoso-5.5/OpenLink.Data.Virtuoso.dll failed

[Andreas Beckmann]

Package: libvirtuoso5.5-cil
Version: 6.1.6+dfsg2-2
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 libvirtuoso5.5-cil.
  (Reading database ... 
(Reading database ... 9474 files and directories currently installed.)
  Preparing to unpack .../libvirtuoso5.5-cil_6.1.6+dfsg2-2+b1_amd64.deb ...
  Unpacking libvirtuoso5.5-cil (6.1.6+dfsg2-2+b1) ...
  Setting up libvirtuoso5.5-cil (6.1.6+dfsg2-2+b1) ...
  * Installing 1 assembly from libvirtuoso5.5-cil into Mono
  E: installing Assembly /usr/lib/cli/virtuoso-5.5/OpenLink.Data.Virtuoso.dll 
failed
  E: Installation of libvirtuoso5.5-cil with 
/usr/share/cli-common/runtimes.d/mono failed
  dpkg: error processing package libvirtuoso5.5-cil (--configure):
   subprocess installed post-installation script returned error exit status 29
  Errors were encountered while processing:
   libvirtuoso5.5-cil


cheers,

Andreas


libvirtuoso5.5-cil_6.1.6+dfsg2-2+b1.log.gz
Description: application/gzip

Bug#804108: ITP: golang-github-coreos-pkg -- a collection of Go utility packages

[Potter, Tim (Converged Cloud)]

X-Debbugs-CC: debian-de...@lists.debian.org, 
pkg-go-maintain...@lists.alioth.debian.org
Package: wnpp
Severity: wishlist
Owner: Tim Potter 

* Package name: golang-github-coreos-pkg
  Version : 0.0~git20151028.0.2c77715-1
  Upstream Author : CoreOS
* URL : https://github.com/coreos/pkg
* License : Apache-2.0
  Programming Lang: Go
  Description : a collection of go utility packages

This package contains a collection of Go utility libraries for use
 in projects written by CoreOS Inc.

Bug#804107: magnum-common: missing Depends: dbconfig-common

[Andreas Beckmann]

Package: magnum-common
Version: 1.0.0~b1-3
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 magnum-common.
  (Reading database ... 
(Reading database ... 16671 files and directories currently installed.)
  Preparing to unpack .../magnum-common_1.0.0~b1-3_all.deb ...
  Unpacking magnum-common (1.0.0~b1-3) ...
  Setting up magnum-common (1.0.0~b1-3) ...
  /var/lib/dpkg/info/magnum-common.postinst: 702: .: Can't open 
/usr/share/dbconfig-common/dpkg/postinst
  dpkg: error processing package magnum-common (--configure):
   subprocess installed post-installation script returned error exit status 2
  Errors were encountered while processing:
   magnum-common


cheers,

Andreas


magnum-common_1.0.0~b1-3.log.gz
Description: application/gzip

Bug#804106: ITP: golang-github-codegangsta-negroni -- idiomatic HTTP Middleware for Golang

[Potter, Tim (Converged Cloud)]

X-Debbugs-CC: debian-de...@lists.debian.org, 
pkg-go-maintain...@lists.alioth.debian.org
Package: wnpp
Severity: wishlist
Owner: Tim Potter 

* Package name: golang-github-codegangsta-negroni
  Version : 0.0~git20140530.0.46a638d-1
  Upstream Author : Jeremy Saenz
* URL : https://github.com/codegangsta/negroni
* License : Expat
  Programming Lang: Go
  Description : idiomatic HTTP Middleware for Golang

 Negroni is an idiomatic approach to web middleware in Go. It is
 tiny, non-intrusive, and encourages use of net/http Handlers.
 .
 Negroni is not a framework. It is a library that is designed to
 work directly with net/http.

Bug#802396: plymouth: Boot stalls since update to Plymouth 0.9.2

[Tom Maneiro]

Package: plymouth
Followup-For: Bug #802396

After upgrading to Plymouth releases with the "I/O multiplexing" feature
enabled, this issue went away.

Please close this bug, everything is working fine here again.



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

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

Versions of packages plymouth depends on:
ii  init-system-helpers  1.24
ii  initramfs-tools  0.120
ii  libc62.19-22
ii  libdrm2  2.4.65-3
ii  libplymouth4 0.9.2-2

plymouth recommends no packages.

Versions of packages plymouth suggests:
ii  desktop-base 8.0.2
ii  plymouth-themes  0.9.2-2

-- Configuration Files:
/etc/plymouth/plymouthd.conf changed:
[Daemon]
Theme=lines


-- no debconf information

Bug#654633: XFCE4-VOLUMED: mute and set the volume to 0, when I unmute it, it leave the volume in 0

[Nate TeGrotenhuis]

I also experienced this bug in testing.
#55s workaround worked for me.

Bug#804018: dpkg: provide options to avoid service startup on package installation

[Guillem Jover]

Hi!

On Wed, 2015-11-04 at 18:31:28 +0100, Patrick Schönfeld wrote:
> 2015-11-04 13:19 GMT+01:00 Holger Levsen :
> > you are aware of
> >
> > echo -e '#!/bin/sh\nexit 101' > /usr/sbin/policy-rc.d
> 
> yes, I'am aware of the policy-rc.d mechanism, see my naive implementation
> proposal (it's what I meant with policy.d layer - a misnomer of mine).
> However, that would effect all service starts, not only the start after the
> package installation, which my proposal aims at.

invoke-rc.d and policy-rc.d are precisely interfaces expected to be used
only by maintainer scripts. Anything else done during run-time should
be using some other interface, such as service(8) for example or an init
specific one, otherwise that should be considered a bug.

> Of course I could write some policy-rc.d script checking an environment
> variable, blacklist or a like and set it before the package installation,
> but that somehow feels like a hack, considering that this is just a
> distribution decision I want to overrule as an admin (on a case-by-case
> basis).

In case this is a local problem where you have deployed non-maintainer
scripts using invoke-rc.d, then while you fix those, you could check in
policy-rc.d if you are running inside dpkg by checking if the environment
variable DPKG_RUNNING_VERSION is defined (documented in dpkg(1)).

> Providing a standard way to not start a certain service after package
> installation seems a lot of cleaner. And that is what my proposal aims at.
> Apart from that our distribution decision to start services after
> installation is quiet controversial to some people anyway and my proposal
> would provide a standard way for those people to opt-out from this choice.

That's really what policy-rc.d is for.

> 2015-11-04 14:08 GMT+01:00 Guillem Jover :
> > This all feels very out of scope for dpkg. More so when policy-rc.d
> > already supports what you seem to be asking for (as Holger also
> > pointed out)?
> 
> I don't think so, because after all its the package manager which starts
> the maintainer scripts which in turn starts the service. Apart from that
> it's _the_ place where I consciously choose to install a package and if I
> want it to be running afterwards. And in case of configuration management
> systems: the interface it communicates with.

dpkg has no idea nor control over what happens inside maintainer scripts,
those are exclusively under the package domain. Starting services is
just one of the actions that can be done there, if any other policy
would require making dpkg aware of it, then dpkg would suddenly have
to know about tons of things it has no control over. But that place
already exists anyway, per above. :)

> > > Possible implementation:
> > > Per policy 9.3.3.2 have to interface with init via invoke-rc.d for
> > service
> > > startup. A possible (and admittedly naive) implementation which does not
> > > involve changes in each and every package, could possibly just let dpkg
> > > install a policy.d layer and ensure its absence on process end. Though
> > some
> > > sort of IPC between invoke-rc.d and dpkg that does not involve filesystem
> > > modifications would probably be better.
> >
> > Something like this would mean encoding extremely system specific
> > policy into the dpkg C codebase, when dpkg has no knowledge whatsoever
> > on what is happening on maintainer scripts or how init scripts are
> > invoked or managed etc. It does not feel right.
> 
> Yeah, I admit that the implementation idea has all sorts of problems (which
> is why I called it naive in the first place).
> But I really think dpkg is the right place for the flag (to start services
> or not), while invoke-rc.d is the tool called by the maintainer scripts and
> therefore responsible for the actual doing. What's missing is the glue
> between these components.
> 
> Maybe a better implementation would be an environment variable respected by
> invoke-rc.d and passed-thru by dpkg?

As mentioned before and above, I still think this is the wrong way to
look at this. And in principle I'm going to close this bug in a bit,
if no other compelling arguments are put forward.

Thanks,
Guillem

Bug#804105: retweet: Missing Build-Depends on python3-setuptools

[Chris Lamb]

Source: retweet
Version: 0.4-2
Severity: serious
Justification: fails to build from source
User: reproducible-bui...@lists.alioth.debian.org
Usertags: ftbfs
X-Debbugs-Cc: reproducible-bui...@lists.alioth.debian.org
Tags: patch

Dear Maintainer,

retweet fails to build from source in unstable/amd64 due to missing
Build-Depends on python3-setuptools:

  [..]

  dh clean --with python3 --buildsystem=pybuild
 dh_testdir -O--buildsystem=pybuild
 dh_auto_clean -O--buildsystem=pybuild
  I: pybuild base:170: python3.5 setup.py clean 
  Traceback (most recent call last):
File "setup.py", line 19, in 
  from setuptools import setup
  ImportError: No module named 'setuptools'
  E: pybuild pybuild:262: clean: plugin distutils failed with: exit
  code=1: python3.5 setup.py clean 
  dh_auto_clean: pybuild --clean -i python{version} -p 3.5 3.4 --dir .
  returned exit code 13
  debian/rules:4: recipe for target 'clean' failed
  make: *** [clean] Error 25
  dpkg-buildpackage: error: fakeroot debian/rules clean gave error exit
  status 2

  [..]

The full build log is attached or can be viewed here:


https://reproducible.debian.net/logs/unstable/amd64/retweet_0.4-2.build1.log.gz


Regards,

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


retweet.0.4-2.unstable.amd64.log.txt.gz
Description: application/gzip

Bug#804102: Update on host/platform configuration

[Jeffrey Walton]

Here's an update since using clang++ with -stdlib-libstdc++ (GNU's
runtime) may seem odd or cause confusion. I just used whatever the
host platform provided.

The machine is an old Athlon system I use for testing. This test
system happens to include Clang, so the Sanitizer test under Clang
gets invoked.

**

$ uname -a
Linux athlon 3.16.0-4-amd64 #1 SMP Debian 3.16.7-ckt11-1+deb8u5
(2015-10-09) x86_64 GNU/Linux

$ lsb_release
No LSB modules are available.
jwalton@athlon:~/cryptopp$ apt-cache show clang++
Package: libclang1-3.5
Source: llvm-toolchain-3.5
Version: 1:3.5-10
Installed-Size: 12499
Maintainer: LLVM Packaging Team 
Architecture: amd64
Depends: libc6 (>= 2.14), libedit2 (>= 2.11-20080614), libffi6 (>=
3.0.4), libgcc1 (>= 1:4.1.1), libllvm3.5, libstdc++6 (>= 4.9),
libtinfo5, zlib1g (>= 1:1.1.4), libstdc++-4.9-dev, libgcc-4.9-dev,
libobjc-4.9-dev
Pre-Depends: multiarch-support
Description-en: C interface to the clang library
 Clang project is a C, C++, Objective C and Objective C++ front-end
 for the LLVM compiler. Its goal is to offer a replacement to the GNU Compiler
 Collection (GCC).
 ...
Description-md5: f4859e1dbd607e9cc7031ab5aa4279a7
Multi-Arch: same
Homepage: http://www.llvm.org/
Tag: role::shared-lib
Section: devel
Priority: optional
Filename: pool/main/l/llvm-toolchain-3.5/libclang1-3.5_3.5-10_amd64.deb
Size: 3654130
MD5sum: 8b870af6965fb2bbc575f332ff2c998d
SHA1: 58a95f34d64dce4f1b9091b2f2313baa071e9901
SHA256: f2a9c27372ceef091ec8c58461517952ed4cbffe0d6e924e350b1047489d4e48

Bug#803589: FTBFS with ruby2.2 (only)

[James McCoy]

On Sun, Nov 01, 2015 at 02:16:10PM -0200, Antonio Terceiro wrote:
> Hello James,
> 
> On Sun, Nov 01, 2015 at 01:06:03AM -0400, James McCoy wrote:
> > On Sat, Oct 31, 2015 at 04:45:54PM +0100, Christian Hofstaedtler wrote:
> > > During a test build your package FTBFS in a ruby2.2-only
> > > environment, as availble in experimental right now. We'd like to
> > > switch to ruby2.2 really soon now, please see the transition bug
> > > #789077 for details.
> > > 
> > > Unfortunately the build output didn't give me a hint on what's going
> > > wrong.
> > 
> > This is because ruby-test-unit (the now standalone package) has
> > completely different behavior than the test/unit.rb that's in ruby2.1.
> > 
> > The subversion build runs, essentially, “ruby -I /path/to/include/files
> > /path/to/test/run-test.rb”.
> > 
> > With ruby2.2 + ruby-test-unit, this doesn't find any tests to run and
> > silently exits with return code 1, causing the build to fail.  If I
> > explicitly add “--collector=dir”, then tests run but various tests fail.
> >
> > With ruby2.1 (and ruby-test-unit not installed separately), tests are
> > discovered automatically and all pass fine.
> > 
> > It looks like ruby2.1's test/unit.rb is really just a compatibility
> > wrapper, exposing an old test-unit API but using minitest underneath.
> > I'm not sure how easy it will be to port the test suite to either newer
> > test-unit or minitest.
> > 
> > This change in behavior is a bit surprising though, especially the
> > silent failure.
> 
> I get your frustration, but that is not under our control.

Yeah, I understand.

> The upstream
> interpreter maintainers decided to stop bundling test-unit and use the
> external package instead.

The odd thing is that I still see both the test/unit wrapper and
minitest 4.x API in the git repo and the Ruby 2.2 tarball (under
test/lib).

I also see the newer versions listed in gems/bundled_gems.

> I have found the following discussion started by one of the main Fedora
> Ruby guys, which touches exactly on having the subversion Ruby bindings
> work under Ruby 2.1:
> https://github.com/test-unit/test-unit/issues/99
> 
> Can you please try the attached patch? I tried to test it myself but for
> some reason subversion fails to build from source with sbuild here (even
> the version from the archive - log attached).

Thanks.  I came up with a similar patch, with a small modification for
the failure you noted, and it seems to work.  I've also ported the test
suite to minitest, since that seems (from my limited Ruby knowledge and
searching over the past few days) to be a preferred test tool.

I'll see what upstream thinks and try to get this resolved in a few
days, even if it's not what upstream ultimately goes with.

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

Bug#791754: initramfs-tools: / on LVM gets mounted by initrd with kernel device name /dev/dm-X instead of /dev/mapper/XXX name

[Phillip Susi]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Found this on Ubuntu 15.10 as well:

http://launchpad.net/bugs/1513272


-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQEcBAEBCgAGBQJWOq2ZAAoJEBB5UWFcu6UWpoUH/19pkbrkOTIjvpGN8Bs9IlR2
28hc3Q/XC8RmwWcMBloSf6j0AkEYrLCJhsAU0eddl5vymwIxApKo35252Xszlv55
+NO09OkHXpqn0Ep6sKVU8FRnlE20rlNwe7Hbi4UXvdaW9HI/RVimAiDTj45q+YkG
V3qhx30iUyEBsXOY/BBLPD0/FVWDKmaxtqMSiHOHQxTvm2DNzsYFW08eEnoP7fi2
C4mALYGUDmYpoxSvJrJ+n8Y36pP3UP/v8/zeQKjkdLOppkK1QyiQ2ZUqs5WZS4Qw
EgtZ7cjQFBeqaXwMxZ4mts4xdq4Awge8dZruzU+jhaHfIY+4dAZhnpgdpwilteI=
=OgTS
-END PGP SIGNATURE-

Bug#592985: pragha: changing back from RFP to ITP

[Paulo]

retitle 592985 ITP: pragha -- Lightweight GTK+ Music Player
owner 592985 !
thanks


I made the package already, just resolving lintians.
 

Bug#803662: marked as pending

[Daniele Tricoli]

Hello Stein,

On Wednesday, November 04, 2015 11:14:18 PM Stein Magnus Jodal wrote:
> I have to admit I chose an RC bug with DPMT as Maintainer mostly at
> random to bribe Piotr into quickly accepting my join request ;-)

Welcome to the DPMT! \o/
I read your email on debian-python@ few hours later my first reply here!

I'm fine with team work: this is because I put my packages on teams! :)
My only concern is to start working on a package when the maintainer is 
working on it: this is because I always ping, but again, this was not a 
problem! ;-)

> It's uploaded now.

Thanks!

Cheers,

--
 Daniele Tricoli 'eriol'
 https://mornie.org

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

Bug#741046: python-pdfminer: Please package latest upstream

[Daniele Tricoli]

[Adding Stefano Rivera since he already reviewed the package: I'm sure that
with the git migration and all other stuff he simply forgot this upload. :)] 

Hello Gianfranco,
thanks for the ping!

On Wednesday, November 04, 2015 01:46:33 PM Gianfranco Costamagna wrote:
> Hi, ping again
> this is the last blocker for w3af.

The package is now on git[¹] and it builds twice in a row inside a pbuilder 
chroot.
It seems to be lintian clean except for:
P: pdfminer source: debian-watch-may-check-gpg-signature
X: python-pdfminer: library-package-name-for-application usr/bin/dumppdf 
usr/bin/latin2ascii usr/bin/pdf2txt
X: python-pdfminer: application-in-library-section python usr/bin/dumppdf 
usr/bin/latin2ascii usr/bin/pdf2txt

But I will simply ignore experimental tags for now: I did not use a lintian 
override.

Right now the package does not use pybuild, my original plan was to switch to 
it after this upload. This because I tested switching to pybuild but there 
were several paths to change, so I thought to postpone the switch.

> I can sponsor the package if needed.

I don't think Stefano will be disappointed if you sponsor pdfminer, so thanks 
if you can look at it and sponsor me.

Kind regards,

[¹] https://anonscm.debian.org/cgit/python-modules/packages/pdfminer.git

-- 
 Daniele Tricoli 'eriol'
 https://mornie.org

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

Bug#786942: upgrade-reports: wheezy -> jessie boot lock up "A start job is running for udev wait for Complete Device Initialization"

[Andreas Beckmann]

Hi Nicolas,

do you have any nvidia driver packages installed?
dpkg -l '*nvidia*'
may give a starting list ...


Andreas

Bug#804104: broccoli: FTBFS: undefined reference to `SSLv3_method'

[Aaron M. Ucko]

Source: broccoli
Version: 1.97-2
Severity: serious
Justification: fails to build from source

Builds of broccoli against current OpenSSL (1.0.2d-3) have been failing:

  ../src/libbroccoli.so.5.1.0: undefined reference to `SSLv3_method'
  collect2: error: ld returned 1 exit status

Per https://bugs.debian.org/768476, Debian's OpenSSL packages have
gone TLS-only, dropping support for the legacy SSL protocol.  Please
account for this change.

Thanks!

Bug#801433: all the images and containers are gone upon upgrade to backported kernel and reboot

[Tianon Gravi]

On 4 November 2015 at 05:56, Yaroslav Halchenko  wrote:
> Oct 09 22:49:46 smaug docker[3981]: time="2015-10-09T22:49:46-04:00" 
> level=warning msg="Graphdriver devicemapper selected. Your graphdriver 
> directory /var/lib/docker already contains data managed by other 
> graphdrivers: aufs"

Ah!  This line looks like the culprit (and confirms my guess at what
the issue was).

♥,
- Tianon
  4096R / B42F 6819 007F 00F8 8E36  4FD4 036A 9C25 BF35 7DD4

Bug#804103: say how to unforbid without trying to install the package

[積丹尼 Dan Jacobson]

Package: aptitude
Version: 0.7.4-1
Severity: wishlist
File: /usr/share/man/man8/aptitude-curses.8.gz

We read

   forbid-version
   Forbid a package from being upgraded to a particular version. This
   will prevent aptitude from automatically upgrading to this version,
   but will allow automatic upgrades to future versions. By default,
   aptitude will select the version to which the package would
   normally be upgraded; you may override this selection by appending
   "=" to the package name: for instance, "aptitude
   forbid-version vim=1.2.3.broken-4".

   This command is useful for avoiding broken versions of packages
   without having to set and clear manual holds. If you decide you
   really want the forbidden version after all, "aptitude install
   " will remove the ban.


However what if the user just wants to remove the ban without (trying
to) install the package. Mention the exact steps to do that too. Or
mention if that is not possible.

E.g., there is an 'unhold' command (antidote of 'hold') that doesn't
necessarily try to install the package. But no analog for
forbid-version.

Bug#799386: dpkg: error processing package docker.io (--configure)

[Diederik de Haas]

On Tuesday 03 November 2015 23:15:11 Tianon Gravi wrote:
> I'd love to hear suggestions for what we could do at the src:docker.io
> package level WRT this, but I don't see many options.

Change /etc/default/docker as Eric Cooper indicated:
DOCKER_OPTS="--storage-driver overlay"

With that, the docker service does start.
And since AUFS is 'history' it makes sense to not use it.

Anyway, an error in post-install as I reported and even expected as all 
testing/sid users should have a 4.0+ kernel is just wrong and afaic RC.

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

Bug#795103: freedombox-setup: Package USB Wifi AR9271 Wireless Firmware

[James Valleroy]

There is an open RFP (#751339) with some more discussion.



signature.asc
Description: OpenPGP digital signature

Bug#804102: Undefined Behavior in .../include/c++/4.9/bits/ios_base.h

[Jeffrey Walton]

Package: libstdc++6
Source: gcc-4.9
Version: 4.9.2-10

**

I believe the fix is to cast from an Ios_Fmtflags to an unsigned type,
perform the bit operations, and then cast back to a Ios_Fmtflags
before returning it.

I recall seeing this one in some Apple headers. Also see
http://lists.llvm.org/pipermail/cfe-dev/2015-January/040945.html .

**

$ cat tt.cxx
#include 
using namespace std;
int main(int argc, char* argv[])
{
  cout << std::hex << argc << std::dec << argc << endl;
  return 0;
}

$ clang++ -fsanitize=undefined tt.cxx -o tt.exe

$ ./tt.exe
/usr/bin/../lib/gcc/x86_64-linux-gnu/4.9/../../../../include/c++/4.9/bits/ios_base.h:96:24:
runtime error: load of value 4294967221, which is not a valid value
for type 'std::_Ios_Fmtflags'
/usr/bin/../lib/gcc/x86_64-linux-gnu/4.9/../../../../include/c++/4.9/bits/ios_base.h:76:67:
runtime error: load of value 4294967221, which is not a valid value
for type 'std::_Ios_Fmtflags'
...

**

$ apt-cache show libstdc++
Package: libstdc++6
Source: gcc-4.9
Version: 4.9.2-10
Installed-Size: 1319
Maintainer: Debian GCC Maintainers 
Architecture: amd64
Replaces: libstdc++6-4.9-dbg (<< 4.9.0-3)
Depends: gcc-4.9-base (= 4.9.2-10), libc6 (>= 2.18), libgcc1 (>= 1:4.1.1)
Pre-Depends: multiarch-support
Conflicts: scim (<< 1.4.2-1)
Breaks: gcc-4.3 (<< 4.3.6-1), gcc-4.4 (<< 4.4.6-4), gcc-4.5 (<< 4.5.3-2)
Description-en: GNU Standard C++ Library v3
 This package contains an additional runtime library for C++ programs
 built with the GNU compiler.
 .
 libstdc++-v3 is a complete rewrite from the previous libstdc++-v2, which
 was included up to g++-2.95. The first version of libstdc++-v3 appeared
 in g++-3.0.
Description-md5: 724ab84919e0e220afb960e36463914d
Multi-Arch: same
Homepage: http://gcc.gnu.org/
Tag: implemented-in::c++, role::shared-lib
Section: libs
Priority: important
Filename: pool/main/g/gcc-4.9/libstdc++6_4.9.2-10_amd64.deb
Size: 272946
MD5sum: 391ae724457378c71fb16fb5d8eb232c
SHA1: 234c8593643d0e3bcfd36302f48edeaa4ca01fe5
SHA256: f1509bbabd78e89c861de16931aec5988e1215649688fd4f8dfe1af875a7fbef

Bug#804101: Table 'phpmyadmin.pma__column_info' doesn't exist

[積丹尼 Dan Jacobson]

Severity: grave
Package: phpmyadmin
Version: 4:4.5.1-1
X-debbusg-Cc: elb...@debian.org

Even if one remembers to start the mysql server,

the upgrade fails with: Table 'phpmyadmin.pma__column_info' doesn't exist.

http://stackoverflow.com/questions/25198923/1146-table-phpmyadmin-pma-column-info-doesnt-exist
http://stackoverflow.com/questions/28543851/1146-table-phpmyadmin-pma-tracking-doesnt-exist-how-to-disable-manually

Bug#804100: RFS: rhythmbox-plugin-alternative-toolbar/0.14.0-1~debian [ITP]

[foss.freedom]

Package: sponsorship-requests
Severity: wishlist

Dear Mentors,

I am looking for a sponsor for my package
"rhythmbox-plugin-alternative-toolbar"

* Package name: rhythmbox-plugin-alternative-toolbar
  Version : 0.14.0-1~debian
  Upstream Author : fossfreedom 
* URL : https://github.com/fossfreedom/alternative-toolbar
* License : GPL3+
  Section : gnome

It builds those binary packages:

rhythmbox-plugin-alternative-toolbar - Show or hide the main toolbar
for Rhythmbox

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

  http://mentors.debian.net/package/rhythmbox-plugin-alternative-toolbar


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

dget -x
http://mentors.debian.net/debian/pool/main/r/rhythmbox-plugin-alternative-toolbar/rhythmbox-plugin-alternative-toolbar_0.14.0-1~debian.dsc

  More information about rhythmbox-plugin-alternative-toolbar can be
obtained from https://github.com/fossfreedom/alternative-toolbar.
  Additionally I have a blog post about this work here:


https://xpressubuntu.wordpress.com/2015/11/02/rhythmbox-alternative-toolbar-updated/

  Apologies if there are any wrong details here.  A bit about me.  I'm a
python developer mainly dealing with rhythmbox-plugins

  I maintain for Ubuntu a personal package archive of 30+ ubuntu (debian
based) packages:

  https://launchpad.net/~fossfreedom/+archive/ubuntu/rhythmbox-plugins

  This is my first Debian upload.  I note that since I uploaded the package
to mentors.debian.net in "my packages" there was one warning lintian error.

I have fixed this in git - what do i have to do to revise the package on
mentors.debian.net?

Changes since the last upload:

  * initial Debian package

Regards,
David Mohammed (fossfreedom)

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

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

Bug#804099: apt-xapian-index: Port to Python 3

[Barry Warsaw]

Package: apt-xapian-index
Version: 0.47
Severity: wishlist
File: apt-xapian-index

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Dear Maintainer,

Since Python 3 is awesome, apt-xapian-index should be ported to it.  I
have a branch that passes the test suite in Python 3.5 when importing
the Xapian 1.3 Python 3 bindings.  I'll contact the maintainers to
arrange for a code review of the branch, but for now I wanted to get a
bug in the system.


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

Kernel: Linux 4.2.0-1-amd64 (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
Init: systemd (via /run/systemd/system)

Versions of packages apt-xapian-index depends on:
ii  python 2.7.9-1
ii  python-apt 1.0.1
ii  python-debian  0.1.27
pn  python-xapian  
pn  python:any 

apt-xapian-index recommends no packages.

Versions of packages apt-xapian-index suggests:
pn  app-install-data  
ii  python-xdg0.25-4

-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQIcBAEBCAAGBQJWOpiFAAoJEBJutWOnSwa/2xIP/0g9YkBrWvBGd2G28kZL8iZ/
G5VDNxX3fbb3vGSL//G4jXj9P+cdZxuavPCoX+r4GkD5N0t9sjI7FAVM3xzNWfR7
ImP5K07JBxNrxOAenZyKgjV+RlHKnnVoV+QacaXRV199EhALVGGdSFkIZWCBzxff
e2W2TbFy5OWpE49y0vQ/rz69Pv9v06FtW1gR7lVYXu6pamNVw8L0Ean09I9DBm1C
ZlFonGfdShoMJBfQfcD96rJDZSokhdpWc7gmmxnNE9Bo2oHwi7PId+M01AAGcV9K
tI5ECwLykuIiyBT+6UsoKVEZ/GuWsAY/xaeCm1OqaTk+xjNxDJtcLBr34otC6e75
da1Cvsa/7Fy1KdTWdTqdeJggxlqAL8tNlLCPoTQjIndd5iO4Zyd8BqTtk5ZxfGno
Zwdn/fA8g3lcB3+oaCDyyF5B6abq+PPD66FXsExDzN6TjCAVSfJAQF512sq5lJD1
VIywYQF8T9YcQPAEHgfD1ykRsa+vbF2s0oB/cmeOgtNOXOsH0DEujS1YzqbJwBap
p609NAJ+u2DfU/7HUivmC7pMP6cJBn6pNrlpvV72di9+hV7QmwCYbfVjm2l+tKoj
6NX3+CB/q3/YabODECXjoPOfXiU7mxzE6BMZLjTdowTy5VX76GhHLQHRUv6RuqnH
Ne2dqBGT6WMivbbDDFsw
=9348
-END PGP SIGNATURE-

Bug#804097: date stamp is wrong

[積丹尼 Dan Jacobson]

retitle 804097 changelog datestamp wrong
thanks

Ah! you copied the datestamp

 -- Hilko Bengen   Mon, 24 Nov 2014 21:35:22 +0100
 -- amd64 / i386 Build Daemon (x86-csail-01) 
  Mon, 24 Nov 2014 21:35:22 +0100

instead of making a fresh one!

Bug#804097: changelogs don't mention what changed for this upgrade

[積丹尼 Dan Jacobson]

Package: android-tools-adb
Version: 4.2.2+git20130529-5.1+b1
Severity: minor

The changelogs don't mention what changed for this upgrade.

I had to use debdiff to find out.

Bug#804098: barbican: [INTL:pt] Updated Portuguese translation for debconf messages

[Américo Monteiro]

Package: barbican
version: 1:1.0.0-5
Tags: l10n, patch
Severity: wishlist

Updated Portuguese translation for barbican's debconf messages.
Translator: Américo Monteiro 
Feel free to use it.

For translation updates please contact 'Last Translator' or the
Portuguese Translation Team .

-- 
Melhores cumprimentos/Best regards,

Américo Monteiro


barbican_1:1.0.0-5_pt.po.gz
Description: GNU Zip compressed data

Bug#781659: konsole: Console cursor loses focus after switching between windows

[Александр Берсенев]

Hello, I filled a bug in Qt against this:
https://bugreports.qt.io/browse/QTBUG-49071. It contains patch. Please,
feel free to test it.

Best,
Alexander Bersenev

Bug#803662: marked as pending

[Stein Magnus Jodal]

On Wed, Nov 04, 2015 at 04:49:11PM +0100, Daniele Tricoli wrote:
> Thanks for your work on sphinxcontrib-spelling!
> My plan was to work on #803662 this evening! :)

I have to admit I chose an RC bug with DPMT as Maintainer mostly at
random to bribe Piotr into quickly accepting my join request ;-)

I did a couple of blounders since this was my first time using git-dpm,
but I believe the end result is good.

> Can you also upload it? Or should I manage the upload?

It's uploaded now.

-- 
Stein Magnus Jodal


signature.asc
Description: Digital signature

Bug#796635: Systemd job

[Felipe Sateler]

On 3 November 2015 at 20:19, Felipe Sateler  wrote:
> On 3 November 2015 at 18:15, Bryan Quigley  
> wrote:
>>> You need to remove the -- "$@" part: it is being added twice to the
>>> resulting scripts (check debian/nvi/DEBIAN/{pre,post}* after a build):
>>>
>>> dpkg-maintscript-helper rm_conffile /etc/init.d/nviboot 1.81.6-12 nvi
>>> -- "$@" -- "$@"
>>>
>>
> Thanks for your work!
 Thanks for all your work reviewing this!  I learned a bunch.
>>>
>>> After the above change I think this would be ready for upload. Can you
>>> upload or do you need sponsoring? I can do the actual upload.
>>
>> I need sponsoring.
>
> OK, I will take a look at uploading over the weekend.

Uploaded with minor changelog edit:

 * QA upload
 * Add systemd job (Closes: #796635)
 * Make recover script complete enough for use in init process
   - Rename init script from nviboot to nvi, move out of runlevel S
 * Cleanup


-- 

Saludos,
Felipe Sateler

Bug#804017: cafeobj-mode: Package short description mentions scala code and not cafeobj code

[Norbert Preining]

forcemerge 803955 804017
thanks

> «Emacs major mode for editing scala source code»

Fixed in git repo already.

Norbert


PREINING, Norbert   http://www.preining.info
JAIST, Japan TeX Live & Debian Developer
GPG: 0x860CDC13   fp: F7D8 A928 26E3 16A1 9FA0  ACF0 6CAC A448 860C DC13

Bug#804096: byobu: [INTL:pt_BR] Brazilian Portuguese debconf templates translation

[Adriano Rafael Gomes]

Package: byobu
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.


pt_BR.po.gz
Description: application/gzip


signature.asc
Description: Digital signature

Bug#804070: texlive-bin: FTBFS when built with dpkg-buildpackage -A

[Norbert Preining]

tags 804070 + pending
thanks

Hi Santiago,

thanks for your email

On Wed, 04 Nov 2015, Santiago Vila wrote:
> Needless to say, this is bad because source-only uploads have their
> own "Arch: all" autobuilder, which means this package may not be
> uploaded as source-only in its current state.

Ok. I didn't know that this is something that can be done at all.
(source only uploads). I am not reading flamy d-d, due to - lets 
say - personal reasons.

> Moreover, according to sbuild, the (failed) build needed 30 minutes
> and 1 GB of disk space. That's certainly suboptimal considering that
> the only architecture-independent package generated by this source
> package has just three files:

Well, but this is what is supposed to do when we have to 
provide upgrade path, so that is not a reason to complain, but
a failure - or problem with the separate arch=all builder, and
not a bug in the package.

> This could be avoided by using build-arch and build-indep.

Again, isn't that a problem of dh itself? We are using normal dh:
%:
dh $@ --with autoreconf --builddirectory Work

So if there is something wrong, my guess is that it is with 
the dh scripts!

> I see, however, that luatex is a dummy package, and a stable release
> (jessie) has already happened, so my recommendation is that the luatex
> package is just dropped. The attached (untested) patch might work.

Indeed, that is what I am doing. COmmitted already to the repo.

But you might check up with debhelper devs to see whether there
is a dh problem wrt build_(*.

Thanks a lot

Norbert


PREINING, Norbert   http://www.preining.info
JAIST, Japan TeX Live & Debian Developer
GPG: 0x860CDC13   fp: F7D8 A928 26E3 16A1 9FA0  ACF0 6CAC A448 860C DC13

Bug#772031: Please allow SSL cert and key to be read from different files

[martin f krafft]

also sprach Holger Weiß  [2015-11-05 09:57 +1300]:
> I haven't played with Let's Encrypt yet, but I guess you could just run
> $ cat key.pem cert.pem chain.pem > ejabberd.pem
> after doing whatever has to be done to maintain their certificates, no?

Yes, of course, but that's an additional step that can be forgotten,
and it's quite normal to have cert and key split between files, so
I'd urge ejabberd to do the same…

-- 
 .''`.   martin f. krafft  @martinkrafft
: :'  :  proud Debian developer
`. `'`   http://people.debian.org/~madduck
  `-  Debian - when you have better things to do than fixing systems


digital_signature_gpg.asc
Description: Digital signature (see http://martin-krafft.net/gpg/sig-policy/999bbcc4/current)

Bug#802272: ImportError: No module named z3

[Anders Kaseorg]

The package tries to create 
/usr/lib/python2.7/dist-packages/z3/__init__.py, but fails to install it 
because it is not listed in debian/python-z3.install.  Creating 
/usr/lib/python2.7/dist-packages/z3/__init__.py allows ‘import z3.z3’ to 
work.

But that’s not really good enough.  The upstream scripts install *.py 
directly into /usr/lib/python2.7/dist-packages, not 
/usr/lib/python2.7/dist-packages/z3, because the user expects to be able 
to ‘import z3’, not ‘import z3.z3’.  We ought to be consistent with 
upstream here, or scripts using this API won’t be portable between Debian 
and non-Debian systems.

Anders

Bug#804095: RFP: coveralls-python -- submit coverage results to coveralls.io

[Daniel Stender]

Package: wnpp
Severity: wishlist

* Package name: coveralls-python
  Version : 1.0
  Upstream Author : Ilya Baryshev 
* URL : https://github.com/coagulant/coveralls-python
* License : Expat
  Programming Lang: Python
  Description : submit coverage results to coveralls.io

coveralls.io is a web service for displaying testing coverage data of projects
online. This tool is used to submit coverage data (generated e.g. by 
coverage.py)
to the online API of coveralls.io (compare package ruby-coveralls). It could
be easily integrated into different continuous integration environments like
Travis CI. python-coveralls would be a great addition to Debian as a development
platform for Python projects.

Bug#804083: jed: FTBFS: /usr/bin/ld.bfd.real: cannot find -ltermcap

[Wookey]

+++ Sven Joachim [2015-11-04 19:46 +0100]:
> Source: jed
> Version: 1:0.99.19-4
> 
> 
> This is an unexpected fallout from the fix for bug #745479[1], I did not
> really consider it possible that packages use the ncurses5-config script
> without a build dependency on libncurses5-dev.  Anyway, here's the
> analysis:
> 
> The configure script tries to run "ncurses5-config --terminfo", and if
> this does not succeed, uses a hardcoded list of terminfo directories
> which unfortunately does not include the directories /etc/terminfo and
> /lib/terminfo which we ship in ncurses-base.  Failing to find a terminfo
> directory, it then concludes that the system must be using termcap and
> adds "-ltermcap" to the linker line which fails.
> 
> I will work around that by shipping an /usr/share/terminfo directory in
> ncurses-base, but jed might still FTBFS on the buildds until they
> upgrade their base system.
> 
> Properly fixing this bug requires patching the buggy test in
> autoconf/aclocal.m4 and regenerating configure, but since jed does not
> currently build-depend on autoconf and uses dpatch which I haven't used
> for years I can't really come up with a patch.

OK, thanks for the analysis. Sounds like jed should build-dep on
libncurses5-dev, or am I misunderstanding here?

Or even better I could teach it to use pkgconfig and generally be less
crufty and ancient.

Wookey
-- 
Principal hats:  Linaro, Debian, Wookware, ARM
http://wookware.org/


signature.asc
Description: Digital signature

Bug#733586: closure-compiler: new upstream version available

[Christoph Biedl]

Source: closure-compiler
Version: 20130227+dfsg1-8
Followup-For: Bug #733586

Gentle ping? The latest upstream release is 20151015 as far as I can
see. There have been some changes so the present Debianisation cannot
simply be forwarded. My skills in Java packaging are however somewhat
limited.

Christoph, on behalf of another person who is interested in using 
closure-compiler

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

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



signature.asc
Description: Digital signature

Bug#804093: krb5-clients: Error message from telnet.krb5 is strange

[Sam Hartman]

You should be aware that Debian 7.x is the last version of Debian that
has krb5-clients.
The package has been desupported and is no longer maintained and has
been removed from future versions of Debian.
The Kerberos telnet application is insecure.  While I don't know of
specific security problems with the rlogin application when used
properly, ssh tends to give much better usage.

--Sam

Bug#804094: gnome-software: Fails to remove applications

[Marcus Lundblad]

Package: gnome-software
Version: 3.18.2-2
Severity: normal

Dear Maintainer,

Trying to remove an application has no effect.
The package is still installed.
Running g-s with Glib debug logging reveals the following:

(org.gnome.Software:8473): Gs-DEBUG: remove lshw-gtk.desktop
(org.gnome.Software:8473): Gs-DEBUG: run 
0x25bd4a0~GsPlugin::packagekit(gs_plugin_app_remove)
(org.gnome.Software:8473): Gs-DEBUG: not supported for plugin packagekit: no 
packages to remove
(org.gnome.Software:8473): Gs-DEBUG: run 
0x25bd4a0~GsPlugin::epiphany(gs_plugin_app_remove)

(org.gnome.Software:8473): Gs-WARNING **: State change on lshw-gtk.desktop from 
installed to available is not OK

Regard,
Marcus

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

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

Versions of packages gnome-software depends on:
ii  dconf-gsettings-backend [gsettings-backend]  0.24.0-2
ii  gnome-software-common3.18.2-2
ii  gsettings-desktop-schemas3.18.1-1
ii  libappstream-glib8   0.5.1-1
ii  libatk1.0-0  2.18.0-1
ii  libc62.19-22
ii  libcairo-gobject21.14.2-2
ii  libcairo21.14.2-2
ii  libgdk-pixbuf2.0-0   2.32.1-1
ii  libglib2.0-0 2.46.1-1
ii  libgnome-desktop-3-123.18.1-1
ii  libgtk-3-0   3.18.2-1
ii  liblimba00.5.2-1
ii  libpackagekit-glib2-18   1.0.10-1
ii  libpango-1.0-0   1.38.1-1
ii  libpangocairo-1.0-0  1.38.1-1
ii  libpolkit-gobject-1-00.105-13
ii  libsoup2.4-1 2.52.1-1
ii  libsqlite3-0 3.9.1-2
ii  packagekit   1.0.10-1

gnome-software recommends no packages.

gnome-software suggests no packages.

-- no debconf information

Bug#784070: mdadm: diff for NMU version 3.3.2-5.1

[Bryan Christ]

I just tested with a Debian Testing from 11/2 and it's still not working.

On Wed, Nov 4, 2015 at 3:36 PM, Francesco Poli 
wrote:

> On Wed, 28 Oct 2015 17:34:42 +0100 Yann-externe SOUBEYRAND wrote:
>
> > You can find two packages on http://mentors.debian.net/package/mdadm :
> one
> > for jessie and one for sid. Can you upload these if you think they are
> > good, please?
>
> Dear Dimitri,
> is there any progress on this?
>
> Please let us know whether there's something blocking you from taking
> over mdadm Debian package maintenance and/or from fixing the annoying
> bug #784070.
>
> Thanks for your time.
> Bye!
>
>
> --
>  http://www.inventati.org/frx/
>  There's not a second to spare! To the laboratory!
> . Francesco Poli .
>  GnuPG key fpr == CA01 1147 9CD2 EFDF FB82  3925 3E1C 27E1 1F69 BFFE
>



-- 
Bryan
<><

Bug#804093: krb5-clients: Error message from telnet.krb5 is strange

[Harka Gyozo]

Package: krb5-clients
Version: 1:1.0.1-4
Severity: minor

Dear Maintainer,
Just installed the krb5-clients, and debian using the telnet from it,
instead of the plain netkit telnet.
While using telnet, I saw a strange double line error (paranoia on).
After a quick security check I got the answer, this is the behavior
of telnet.krb. But why?
Example:

netkit#  telnet.netkit 127.0.0.1 25
Trying 127.0.0.1...
telnet: Unable to connect to remote host: Connection refused

krb5#  telnet 127.0.0.1 25
Trying 127.0.0.1...
telnet: connect to address 127.0.0.1: Connection refused
telnet: Unable to connect to remote host: Connection refused

Why is that second line there? It just horrifies me, that a simple
program acts strange...


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

Kernel: Linux 3.9.0-sietch2014 (SMP w/2 CPU cores)
Locale: LANG=hu_HU, LC_CTYPE=hu_HU (charmap=ISO-8859-2)
Shell: /bin/sh linked to /bin/dash

Versions of packages krb5-clients depends on:
ii  krb5-config   2.3
ii  libc6 2.19-18+deb8u1
ii  libcomerr21.42.5-1.1
ii  libgssapi-krb5-2  1.10.1+dfsg-5+deb7u1
ii  libk5crypto3  1.10.1+dfsg-5+deb7u1
ii  libkrb5-3 1.10.1+dfsg-5+deb7u1
ii  libtinfo5 5.9-10

krb5-clients recommends no packages.

Versions of packages krb5-clients suggests:
ii  openssh-client [rsh-client]  1:5.5p1-6+squeeze2

-- no debconf information

Bug#784070: mdadm: diff for NMU version 3.3.2-5.1

[Francesco Poli]

On Wed, 28 Oct 2015 17:34:42 +0100 Yann-externe SOUBEYRAND wrote:

> You can find two packages on http://mentors.debian.net/package/mdadm : one 
> for jessie and one for sid. Can you upload these if you think they are 
> good, please?

Dear Dimitri,
is there any progress on this?

Please let us know whether there's something blocking you from taking
over mdadm Debian package maintenance and/or from fixing the annoying
bug #784070.

Thanks for your time.
Bye!


-- 
 http://www.inventati.org/frx/
 There's not a second to spare! To the laboratory!
. Francesco Poli .
 GnuPG key fpr == CA01 1147 9CD2 EFDF FB82  3925 3E1C 27E1 1F69 BFFE


pgppnNPIMgdPi.pgp
Description: PGP signature

Bug#804092: fish: History can be wiped accidentally

[Bertrand Bonnefoy-Claudet]

Package: fish
Version: 2.2.0-2~bpo8+1
Severity: important

Dear Maintainer,

Using `sudo -E` while using fish can lead to the wipe of the history, or of part
of it.  The bug was reported, confirmed and fixed upstream:

https://github.com/fish-shell/fish-shell/issues/2335

Would you consider applying the corresponding patch [1]?

Thanks,

[1]: 
https://github.com/fish-shell/fish-shell/commit/871a2088dbfe89f8d2dabfd07b6cb42f88a042c6

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

Kernel: Linux 3.16.0-4-amd64 (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
Init: systemd (via /run/systemd/system)

Versions of packages fish depends on:
ii  bc 1.06.95-9
ii  dpkg   1.17.25
ii  fish-common2.2.0-2~bpo8+1
ii  libc6  2.19-18+deb8u1
ii  libgcc11:4.9.2-10
ii  libncurses55.9+20140913-1+b1
ii  libstdc++6 4.9.2-10
ii  libtinfo5  5.9+20140913-1+b1
ii  w3m [www-browser]  0.5.3-19

Versions of packages fish recommends:
ii  xsel  1.2.0-2

Versions of packages fish suggests:
pn  doc-base  

-- no debconf information

Bug#392564: rubber: crashes when latex does not produce a dvi file

[Nicolas Boulenguez]

On Tue, Nov 03, 2015 at 10:31:37AM +0100, Hilmar Preusse wrote:
> Can we assume your problem to be solved?

I guess so. Thanks.

Bug#804091: artemis: FTBFS with Java 8: FastVector.sort(Comparator) cannot implement List.sort(Comparator)

[Emmanuel Bourg]

Package: artemis
Version: 16.0.0+dfsg-1
Severity: important
User: debian-j...@lists.debian.org
Usertags: openjdk-8-transition

Dear Maintainer,

artemis fails to build with OpenJDK 8, there is a conflict with the sort()
method in FastVector and the newly added sort() method in the java.util.List
interface in Java 8 (the return type isn't the same):


/home/ebourg/packaging/artemis/uk/ac/sanger/artemis/util/FastVector.java:94: 
error: sort(Comparator) in FastVector cannot implement sort(Comparator) in List
  public FastVector sort(final Comparator cmp)
^
  return type FastVector is not compatible with void
  where E is a type-variable:
E extends Object declared in interface List
/home/ebourg/packaging/artemis/uk/ac/sanger/artemis/io/KeyVector.java:37: 
error: sort(Comparator) in FastVector cannot implement sort(Comparator) in List
public class KeyVector extends FastVector
   ^
  return type FastVector is not compatible with void
  where E is a type-variable:
E extends Object declared in interface List


You can test the build with OpenJDK 8 by installing default-jdk/0.53 from 
experimental.

Emmanuel Bourg

Bug#756766: Initial work-patch on this bug

[Raphael Hertzog]

Hello Orestis,

sorry that I did not find the time to get back to you earlier.

On Mon, 19 Oct 2015, Orestis Ioannou wrote:
> I reworked most of the patch, using the ListView and factorising most of
> the code.

The code looks clean and slick. Good work!

> Let me know if this needs more work :)

But I don't see any test. I would suggest to test:

1/ that the package page contains a link to the package news page (the
link you added in the header of the panel)
2/ that the package page contains a link to the "?page=2" version of the
package news page when you have more news than the configured limit (and
possibly that you don't have any such link when you're below)
3/ the package news page does return the expected content for "?page=2"
just to ensure that pagination works and that we display something that
looks OK

Just a few comments still:

> diff --git a/distro_tracker/core/panels.py b/distro_tracker/core/panels.py
> index 8c2cd82..668cb64 100644
> --- a/distro_tracker/core/panels.py
> +++ b/distro_tracker/core/panels.py
> @@ -805,9 +805,11 @@ class NewsPanel(BasePanel):
>  def context(self):
>  news = News.objects.prefetch_related('signed_by')
>  news = 
> news.filter(package=self.package).order_by('-datetime_created')
> +more_pages = True if len(news) > self.NEWS_LIMIT else False

This will force the evaluation of the full query. We don't want to
retrieve everything here... one way is to use news.count() but we can
possibly avoid that query altogether if we evaluate the length of the
result after the truncation to NEWS_LIMIT.

If we are on the limit, chances are high that we have more entries... 
So that would give:

news = list(news[:self.NEWS_LIMIT])
more_pages = len(news) == self.NEWS_LIMIT

The first line forces the evaluation of the queryset with the appropriate
LIMIT SQL clause. And then we check how many lines we got back.

>  return {
> -'news': news
> +'news': news,
> +'has_more': more_pages
>  }

> --- a/distro_tracker/core/views.py
> +++ b/distro_tracker/core/views.py
> @@ -176,6 +176,35 @@ def news_page(request, news_id):
>  })
>  
>  
> +class PackageNews(ListView):
[...]
> +def get_queryset(self):
> +news = News.objects.prefetch_related('signed_by')
> +return(news.filter(package=self.package)
> +   .order_by('-datetime_created'))

Or more cleanly:
news = self.package.news_set.prefetch_related('signed_by')
return news.order_by('-datetime_created')

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

Support Debian LTS: http://www.freexian.com/services/debian-lts.html
Learn to master Debian: http://debian-handbook.info/get/

Bug#653103: Please add binary packages for i386

[Jose Martinez]

On Sun, 14 Jul 2013 11:41:18 +0200 "Andrea D'Amore"  
wrote:
> The ngspice package for i386 architecture is still missing as of
> Wheezy while the amd64 is present.
> Is there any specific reason preventing the building of the i386 package?
> 
> 
> --
> Andrea
> 
> 
I use the ngspice package extensively.  I have been using the old
version 20 from the Squeeze distribution for quite some time.  Recently,
I downloaded the most current version (26) from sourceforge, and
successfully compiled to binary for i386, and have been running it on my
ancient Gateway laptop.

I am new to the debian community and am willing to do anything I can to
help provide this package for the i386 architecture.

Please advise

--
Que te vaya bien
JM

Bug#772031: Please allow SSL cert and key to be read from different files

[Holger Weiß]

* Paul Muster  [2015-11-04 21:21]:
> It's especially _necessary_ to split key, cert and chain to different
> files to be able to use Let's Encrypt certificates.

I haven't played with Let's Encrypt yet, but I guess you could just run

$ cat key.pem cert.pem chain.pem > ejabberd.pem

after doing whatever has to be done to maintain their certificates, no?

Bug#351174: Unsuccessful attempts to access your email

[Webmaster]

Recently, there were too many unsuccessful attempts to access your email and 
your email account has been disabled.
 Please click here to reactivate full access to your email.

Bug#804073: nvidia-detect: Does not work with multiple Nvidia cards

[Floris]

Op Wed, 04 Nov 2015 19:29:05 +0100 schreef Andreas Beckmann  
:



On 2015-11-04 18:00, floris wrote:

$ nvidia-detect
Detected NVIDIA GPUs:
01:00.0 VGA compatible controller [0300]: NVIDIA Corporation G92  
[GeForce GTS

250] [10de:0615] (rev a2)
02:00.0 VGA compatible controller [0300]: NVIDIA Corporation GF119  
[GeForce GT

610] [10de:104a] (rev a1)
Several NVIDIA GPUs detected. Checking only the first.
Usage: lspci []


Fixed in SVN.
Without a multi-gpu system available this code path was untested until
now ...


Andreas


I made a little modification to the nvidia-detect script. Now it can check
multiple cards. The only problem is it can report two different versions
to the user.

floris

nvidia-detect
Description: Binary data

Bug#804087: ITP: ruby-svn2git -- Ruby tool for importing existing svn projects into git.

[Antonio Terceiro]

On Wed, Nov 04, 2015 at 08:57:01PM +0100, Sascha Girrulat wrote:
> Package: wnpp
> Severity: wishlist
> Owner: Sascha Girrulat 
> 
> * Package name: ruby-svn2git
>   Version : 2.3.2 
>   Upstream Author : Kevin Menard  
> * URL : https://github.com/nirvdrum/svn2git
> * License : MIT
>   Programming Lang: Ruby
>   Description : Ruby tool for importing existing svn projects into git.
> 
> Svn2git is a tiny utility for migrating projects from Subversion to Git
> while keeping the trunk, branches and tags where they should be. It uses
> git-svn to clone an svn repository and does some clean-up to make sure
> branches and tags are imported in a meaningful way, and that the code
> checked into master ends up being what's currently in your svn trunk
> rather than whichever svn branch your last commit was in.

if the package is not a Ruby library, but instead is just an application
that happens to be written in Ruby, you want to call the package by its
original name (i.e. svn2git) instead of ruby-svn2git.

-- 
Antonio Terceiro 


signature.asc
Description: PGP signature

Bug#772031: Please allow SSL cert and key to be read from different files

[Paul Muster]

Dear Ejabberd-Team,

On Thu, 4 Dec 2014 15:11:41 +0100 martin f krafft wrote:
> Package: ejabberd
> Version: 14.07-3
> Severity: wishlist
> Tags: upstream
> 
> SSL cert and key usually are not in the same file. The key usually
> has tighter security. Please let me poit ejabberd to a separate
> keyfile, not just the certfile, such that it then loads the key from
> there.

Is there any point one could assist you with on this bug?

Do you know if upstream already has an issue open for this (I cannot
find one)?

It's especially _necessary_ to split key, cert and chain to different
files to be able to use Let's Encrypt certificates.


Thanks & Greetings,

Paul

Bug#671672: openssl s_client -starttls xmpp burn cpu with broken server

[Paul Muster]

Dear OpenSSL-Maintainers,

On Wed, 3 Jun 2015 11:25:41 +1000 Brian May wrote:
> On Fri, Apr 25, 2014 at 06:03:00PM +0200, gp wrote:

> > Attached you'll find a patch that supposedly fixes this issue. It is
> > patch 2/4 of this series of patches
> > http://rt.openssl.org/Ticket/Display.html?id=2860.
> > 
> > [openssl.org #2860] [PATCH 2/4] Fix infinite loop on s_client starttls
> > xmpp
> 
> I can confirm that this patch works.
> 
> Any chance of getting this fixed before Stretch is released?

any news on this?

Shouldn't be a big thing since patch is available and confirmed...


Thanks & Greetings,

Paul

Bug#789463: testcase

[Alex Ugarte]

I am having a problem with this library and I think it might be related to
this bug.
To reproduce my problem simply compile the following program:

#include 
#include 
int main() {
  UnitTest::DeferredTestResult s("a", "b");
  std::cout << s.suiteName << ":"<< s.testName<< std::endl;
}
//g++ unittest++segfault.cpp -lunittest++ -o /tmp/unittestsegfault &&
/tmp/unittestsegfault


I have tested this in two computers running Debian Stretch, one 32 bits and
the other 64 bits.
The readelf command in the 64 bit machine shows:
readelf -p .comment /usr/lib/libUnitTest++.a | grep GCC | uniq
  [ 1]  GCC: (Debian 4.3.3-13) 4.3.3

After executing these commands, the above test program works fine:
apt-get source libunittest++-dev
cd unittest++-1.4.0/
make
cp libUnitTest++.a /usr/lib/

Bug#804010: New version 1.0.1 available

[Guillaume Delacour]

On Wed, Nov 04, 2015 at 09:16:04AM +0100, Sebastien Bacher wrote:
> Package: gdisk
> Version: 1.0.0-3
> 
> There is a new 1.0.1 version available that fixes some EFI issues and
> potential segfaults on some architectures, it would be nice to have that
> update in Debian

Sure, i've prepared this package a few days ago on mentors:

http://mentors.debian.net/debian/pool/main/g/gdisk/gdisk_1.0.1-1.dsc

My main sponsor doesn't reply me yet, you can review the package and upload it
if you have some time. Thanks in advance.

-- 
Guillaume Delacour


signature.asc
Description: Digital signature

Bug#803822: gst-libav1.0: FTBFS with FFmpeg 2.9

[Sebastian Dröge]

On Di, 2015-11-03 at 21:14 +0100, Andreas Cadhalpun wrote:
> 
> OK, split patches attached.

And also forwarded these upstream for review now, thanks again :) I
hope I find some time to review them myself soonish, but otherwise I'm
sure someone else will do it soon

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

Bug#804089: Ruby: FTBFS: Uses SSLv3 methods

[Kurt Roeckx]

Source: ruby2.2
Severity: serious

Hi,

I've removed the SSLv3_* methods in OpenSSL and as result ruby is
now failing to build.  I opened a ticket about this upstream some
time ago, and you should be able to find a patch for it there:
https://bugs.ruby-lang.org/issues/11376


Kurt

Bug#804090: imapcopy: login fails with period in username

[Mark Hedges]

Package: imapcopy
Version: 1.04-2
Severity: normal

Trying to use imapcopy to migrate one gmail account to another.

Used the following stunnel.conf:

==
cert = stunnel.pem
foreground=yes
socket = l:TCP_NODELAY=1
socket = r:TCP_NODELAY=1
debug = 7
client = yes

[imap-in]
accept = 127.0.0.1:1143
connect = imap.gmail.com:993
retry = yes

[imap-out]
accept = 127.0.0.2:2143
connect = imap.gmail.com:993
retry = yes
==
... or just ...
==
cert = stunnel.pem
foreground=yes
socket = l:TCP_NODELAY=1
socket = r:TCP_NODELAY=1
debug = 7
client = yes

[imap]
accept = 127.0.0.1:1143
connect = imap.gmail.com:993
retry = yes
==

... with matching entries in the SourceServer, SourcePort,
DestServer and DestPort lines of ImapCopy.cfg.

Business uses gmail so username at imap.gmail.com is the
full e-mail address.

Login does not work where there is a dot in the username,
i.e. when username is "foo@qux.com".

I tried changing my passwords to all alphanumeric,
and re-verified them over and over, but it never worked.

It logged in fine with the source address, which does not
have a "." in the username.

I tried switching source/dest in the Copy line in ImapCopy.cfg
and then tested with the -t switch, but it still failed on
the one with the "." in the username.

Thanks.

Mark


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

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

Versions of packages imapcopy depends on:
ii  libc6  2.19-18+deb8u1

imapcopy recommends no packages.

imapcopy suggests no packages.

-- no debconf information

Bug#804088: smc: New upstream version: 2.0.0

[ZenWalker]

Package: smc
Severity: wishlist

Dear Maintainer, new upstream available, can you package for Debian?

http://www.secretchronicles.de/en/news/2015/08/17/2/



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

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

Bug#803388: [pkg-go] Bug#803388: golang-gopkg-mgo.v2-dev: over-aggressive depends

[Alexandre Viau]

Hello Tianon,

Feel free to make a team upload.

Supervisor was in the dependencies as it is needed for tests, but it
should be in Build-Deps. Since we are not running tests, you should
just remove it, or maybe put it in comments in Build-Deps. The same
thing goes for mongodb-server.

This also prevented InfluxDB from building on arm64 and armel I think,
so that will be a good thing to solve.

Cheers,

--
Alexandre Viau
alexan...@alexandreviau.net


On Wed, Nov 4, 2015 at 12:04 AM, Tianon Gravi  wrote:
> Alexandre,
>
> On 29 October 2015 at 12:51, Tianon Gravi  wrote:
>> On 29 October 2015 at 07:35, Tianon Gravi  wrote:
>>> Currently, the -dev package depends on both mongodb-server and
>>> supervisor.  I can't see a reason for supervisor to be in any of the
>>> relations of this package, but mongodb-server really ought to be in
>>> Suggests instead since it's not necessary for it to be installed for
>>> the proper user of the -dev package. :)
>>
>> I'd also add that I'm happy to make the modification myself if you'd prefer. 
>> :)
>
> Mind if I make a fix for this and do a "Team Upload"?  Was there a
> particular reason for these packages to be in Depends instead of just
> Suggests?  Was there a reason for supervisor to be listed at all?  I'm
> having trouble seeing rationale but I don't want to step on toes. :)
>
> ♥,
> - Tianon
>   4096R / B42F 6819 007F 00F8 8E36  4FD4 036A 9C25 BF35 7DD4

Bug#804087: ITP: ruby-svn2git -- Ruby tool for importing existing svn projects into git.

[Sascha Girrulat]

Package: wnpp
Severity: wishlist
Owner: Sascha Girrulat 

* Package name: ruby-svn2git
  Version : 2.3.2 
  Upstream Author : Kevin Menard  
* URL : https://github.com/nirvdrum/svn2git
* License : MIT
  Programming Lang: Ruby
  Description : Ruby tool for importing existing svn projects into git.

Svn2git is a tiny utility for migrating projects from Subversion to Git
while keeping the trunk, branches and tags where they should be. It uses
git-svn to clone an svn repository and does some clean-up to make sure
branches and tags are imported in a meaningful way, and that the code
checked into master ends up being what's currently in your svn trunk
rather than whichever svn branch your last commit was in.

Bug#804086: [INTL:da] Danish translation of the debconf templates unattended-upgrades

[Joe Dalton]

Package: unattended-upgrades
Severity: wishlist
Tags: l10n patch

Please include the attached Danish unattended-upgrades translation

joe@pc:~/over/debian/unattended-upgrades$ msgfmt --statistics -c -v -o 
/dev/null da.po
da.po: 5 oversatte tekster.

bye
Joe

da.po.tar.gz
Description: application/gzip

Bug#804073: nvidia-detect: Does not work with multiple Nvidia cards

[Floris]

Op Wed, 04 Nov 2015 19:29:05 +0100 schreef Andreas Beckmann  
:



On 2015-11-04 18:00, floris wrote:

$ nvidia-detect
Detected NVIDIA GPUs:
01:00.0 VGA compatible controller [0300]: NVIDIA Corporation G92  
[GeForce GTS

250] [10de:0615] (rev a2)
02:00.0 VGA compatible controller [0300]: NVIDIA Corporation GF119  
[GeForce GT

610] [10de:104a] (rev a1)
Several NVIDIA GPUs detected. Checking only the first.
Usage: lspci []


Fixed in SVN.
Without a multi-gpu system available this code path was untested until
now ...


Andreas


I confirm that the  SVN version is fixed.

Thanks,

floris

Bug#803641: [pkg-horde] Bug#803641: Aw: Re: Bug#803641: php-horde: Multiple CSRF Vulnerabilities

[Philip Frei]

On Tue, 3 Nov 2015 21:24:33 +0100 Mathieu Parent
 wrote:


> I have tested and uploaded the fix to
> security-master-unembargoed, in coordination with the security team.
> If I understand correctly, it will go to the security mirrors soon.

It's already there. So this bug report can be closed.

Again: thanks a lot for your ongoing work on the Horde packages.

regards, Philip.