Bug#736142: Missing "Conflict" or "Replaces" on old libwine-dev

[Max Kellermann]

Package: wine
Version: 1.6.2-2

Unpacking wine (1.6.2-2) over (1.4.1-4) ...
Replacing files in old package libwine-bin:i386 (1.4.1-4) ...
Replacing files in old package libwine (1.4.1-4) ...
dpkg: error processing archive /var/cache/apt/archives/wine_1.6.2-2_amd64.deb 
(--unpack):
 trying to overwrite '/usr/share/man/de.UTF-8/man1/winemaker.1.gz', which is 
also in package libwine-dev 1.4.1-4


I expect dpkg to be clever enough to uninstall/upgrade the old
libwine-dev before trying to overwrite its files.


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

Bug#732389: fixed in git

[Rebecca N. Palmer]

Control: tags -1 patch

Fixed in alioth git 
(http://anonscm.debian.org/gitweb/?p=pkg-grass/osmium.git;a=commitdiff;h=1a547fffc31cd036315fd7702f9adf5538ffca8c); 
since this is a build-time-only dependency, uploading the package just 
for this would only waste time.



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

Bug#736115: lynis: Minor egrep misconfiguration checking for crontab jobs

[Francisco Manuel Garcia Claramonte]

Hi Dave,
Thank you for your report,

I'll review it and fix it in next release (probably in some days).

Regards,
Francisco

El dom, 19-01-2014 a las 13:56 -0700, Dave Vehrs escribió:
> Package: lynis
> Version: 1.3.9-1
> Severity: normal
> 
> Dear Maintainer,
> 
> I've encountered a small misconfiguration in an egrep search in a lynis 
> script.  When checking for crontab jobs, the script tests_scheduling 
> checks for lines that start with [0-9], and while this is appropriate 
> for most cases, it misses two that may still be an issue.  Both cases 
> involve when the crontab line starts with an '*'.
> 
> If the job in question should run every minute (so is just '*'), then 
> the line will be missed by the egrep test.
> 
> The second issue is if the job in question should run at a specified 
> interval, such as every 15 minutes.  That will be specified a */15 and 
> will also be missed.
> 
> I've been able to fix this issue by simply adding an '*' to the 
> characters to be searched by egrep.  (patch attached)  With that simple 
> change, it catches both of the missed crontab lines.
> 
> Thank you for your attention to this minor issue,
> 
> Dave Vehrs
> 
> 
> -- System Information:
> Debian Release: jessie/sid
>APT prefers testing-updates
>APT policy: (500, 'testing-updates'), (500, 'testing'), (1, 
> 'experimental')
> Architecture: amd64 (x86_64)
> Foreign Architectures: i386
> 
> Kernel: Linux 3.12-1-amd64 (SMP w/2 CPU cores)
> Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
> Shell: /bin/sh linked to /bin/dash
> 
> lynis depends on no packages.
> 
> Versions of packages lynis recommends:
> ii  menu  2.1.46
> 
> Versions of packages lynis suggests:
> ii  dnsutils  1:9.8.4.dfsg.P1-6+nmu3
> 
> -- no debconf information
> 

-- 
Francisco M. García Claramonte 
Debian GNU/Linux Developer 
GPG: public key ID 556ABA51
http://people.debian.org/~francisco/


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

Bug#734760: xserver-xorg-input-evdev: ps2 keyboard maniacally retypes keys after one press. sometimes drops keys.

[Julien Cristau]

Control: severity -1 important
Control: reassign -1 src:linux 3.12.6-1

On Thu, Jan  9, 2014 at 12:11:46 -0500, Mitchell Laks wrote:

> Package: xserver-xorg-input-evdev
> Version: 1:2.8.2-1
> Severity: grave
> Tags: upstream
> Justification: renders package unusable
> 
> Dear Maintainer,
> 
> I recently upgraded my motherboard to a ASUS M4a77td motherboard with a 6core 
> amd processor and 
> radeon card. 
> 
> I use a PS2 m$ft internet keyboard and a usb mouse.
> 
> 
> 
> I am having repeated episodes of the various keys, such as the enter key
> (and  other keys as well) suddenly typing over and over again. I have to hit 
> 'any' key 
> to stop it.  
> Thus it will type keyboarddd etc.
>  
> I replaced the keyboard with another keyboard and it was not a keyboard 
> hardware problem.
> Does not happen when I plug in a usb keyboard.
> 
Doesn't sound like an X issue...

Cheers,
Julien


signature.asc
Description: Digital signature

Bug#734371: Solution already available

[Thomas Goirand]

Hi,

FYI, we are currently evaluating this new implementation of lsb.pl:
https://github.com/xaionaro/openrc-lsb

As soon as our tests are conclusive, it will replace the old lsb.pl and
there should be no problem anymore to boot with a separated partition
for /usr.

Cheers,

Thomas


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

Bug#736140: 736140 is not a bug in Bash

[Martin Kealey]

This is simply a misunderstanding of file-descriptors.

The dup2() system call links multiple file-descriptors to the same "open
file" object in the kernel, with a single common read-write pointer.

However opening the /dev/stderr device, at least in Linux, do not do this;
they create a new "open file" object in the kernel pointing at the original
file, with a separate read-write pointer.

All that is happening is that the output written to fd#2 is opened without
O_APPEND, and is overwriting the output written to /dev/stderr (which is
opened with O_APPEND).

So this isn't really a Bash bug at all.


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

Bug#722148: I'm waiting for scala 2.10 to enter debian, instead

[Martin Quinson]

package plm
tag 722148 wontfix
thanks

Hello,

Actually, porting PLM to scala v2.9 is too complicated. Instead, I'm
currently helping scala 2.10 to enter debian, it seems easier and more
profitable to anyone.

Bye, Mt.

-- 
Le monde est dangereux à vivre! Non pas tant à cause de ceux qui font le
mal, mais à cause de ceux qui regardent et laissent faire.
  -- Albert Einstein


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

Bug#418199: Fwd: Re: segfault with exceedingly long path [origin: schae...@brasslantern.com]

[Goswin von Brederlow]

On Sat, Jan 18, 2014 at 10:19:39AM +0100, Axel Beckert wrote:
> Control: tag -1 + wontfix
> 
> Hi,
> 
> upstream said, this is an issue which is "unlikely ever to be fixed".
> Marking as such.
> 
> - Forwarded message from Bart Schaefer  -
> Date: Fri, 17 Jan 2014 17:49:02 -0800
> From: Bart Schaefer 
> To: zsh-work...@zsh.org
> Subject: Re: segfault with exceedingly long path
> 
> On Jan 18,  1:20am, Axel Beckert wrote:
> }
> } this is a forward of http://bugs.debian.org/418199
> 
> This is a known issue and unlikely ever to be fixed.  Various parts
> of the shell rely on system limits such as PATH_MAX which cannot be
> dynamically changed.  There's a comment with some explanation around
> lines 109-137 of Src/compat.c.
> 
> The upshot is that if you try hard enough you can always create a path
> that will exceed some limit or other.
> - End forwarded message -
> 
> (Online archived at
> http://www.zsh.org/cgi-bin/mla/redirect?WORKERNUMBER=32277)
> 
>   Regards, Axel

Could you fix that in Debian even if upstream doesn't care? A segfault
is never right. If zsh can't handle the long path then it must check
the length and give an error. Not fixing a segfault is imho
unacceptable.

MfG
Goswin


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

Bug#735873: zathura: Scrollbar settings do not work

[Markus Demleitner]

On Sat, Jan 18, 2014 at 07:51:10PM +0100, Sebastian Ramacher wrote:
> On 2014-01-18 07:30:05, Martin Demleitner wrote:
> > In that situation, the show-scrollbars, show-h-scrollbar, and
> > show-v-scrollbar settings have no effect, either in .zathurarc or
> > interactively; scrollbars do not appear or disappear.
> Could please test if the scrollbars appear if you set all three settings
> to true, set guioptions to an empty value and then open a document and
> zoom in so that not everything is visible. The scrollbars should appear
> in this case.

They are.  My problem is that they don't disappear when the settings
are false.

> The problem seems to be that the statusbar hides the horizontal
> scrollbar. However, the vertical scrollbar should appear if you're
> zoomed in enough that there is something to scroll.

I can confirm that the statusbar hides the horizontal scrollbar here,
too, but that's just an aside.

Thanks,

   Markus


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

Bug#733272: uscan: Clarify options syntax

[Kurt Roeckx]

On Sun, Jan 19, 2014 at 08:13:33PM -0500, James McCoy wrote:
> On Sat, Dec 28, 2013 at 12:20:32AM +0100, Kurt Roeckx wrote:
> > Reading the uscan manpage, it says:
> > | PER-SITE OPTIONS
> > |  A watch file line may be prefixed with `opts=options',
> > |  where options is a comma-separated list of options.  The
> > |  whole options string may be enclosed in double quotes,
> > |  which is necessary if options contains any spaces.  The
> > |  recognised options are as follows:
> > 
> > But having something as:
> > opts=pasv
> > 
> > will result in:
> > uscan warning: malformed opts=... in watchfile, skipping line:
> > opts=pasv
> > 
> > The problem is that you need to add the site after that, and
> > that's not clear from the documentation.
> 
> You're right that we don't explicitly define that the file is parsed
> line-wise, but we do use that sort of wording in the description of the
> file format, and specify that opts is the first field (emphasis added):
> 
> There  are  two  possibilities  for the syntax of an HTTP watch file
> __line__, and only one for an FTP __line__.  We begin with the
> common (and simpler) format.  We describe the __optional opts=...
> first field__ below, and ignore it in what follows.
> 
> Would it have helped to have something the accepted formats shown
> (something like below) in addition to the existing descriptions?
> 
> [opts=...]   
> [opts=...]

Yes, that would clearly make it more obvious.


Kurt


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

Bug#736143: anki: Crashes at startup with AttributeError

[Albin]

Package: anki
Version: 2.0.20+dfsg-2
Severity: important

Dear Maintainer,
When launching Anki, I get the following traceback  as a pop-up dialog (I
believe that's the actual error that was blocked by bug #734465):
Error during startup:
Traceback (most recent call last):
  File "/usr/share/anki/aqt/main.py", line 54, in __init__
self.setupAddons()
  File "/usr/share/anki/aqt/main.py", line 552, in setupAddons
import aqt.addons
  File "/usr/share/anki/aqt/addons.py", line 13, in 
from aqt.downloader import download
  File "/usr/share/anki/aqt/downloader.py", line 7, in 
from anki.sync import httpCon
  File "/usr/share/anki/anki/sync.py", line 32, in 
_proxy_info_from_environment = httplib2.ProxyInfo.from_environment
AttributeError: type object 'ProxyInfo' has no attribute 'from_environment'

additionally, the following traceback is printed in the running terminal:
Traceback (most recent call last):
  File "/usr/bin/anki", line 8, in 
aqt.run()
  File "/usr/share/anki/aqt/__init__.py", line 247, in run
mw = aqt.main.AnkiQt(app, pm, args)
  File "/usr/share/anki/aqt/main.py", line 57, in __init__
sys.exit(1)
NameError: global name 'sys' is not defined



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

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

Versions of packages anki depends on:
ii  libjs-jquery  1.7.2+dfsg-3
ii  libjs-jquery-flot 0.8.1+dfsg-2
ii  libjs-jquery-ui   1.10.1+dfsg-1
ii  python-beautifulsoup  3.2.1-1
ii  python-httplib2   0.8-2
ii  python-pyaudio0.2.7-2
ii  python-qt44.10.3+dfsg1-1
ii  python-simplejson 3.3.1-2
ii  python-sqlalchemy 0.8.4-1
pn  python:any

Versions of packages anki recommends:
ii  python-matplotlib  1.3.1-1

Versions of packages anki suggests:
ii  dvipng  1.14-2


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

Bug#727708: The tech ctte isn't considering OpenRC at all

[Thomas Goirand]

On 01/19/2014 08:15 PM, Ian Jackson wrote:
> How mature a system is and how well-developed in Debian are relevant
> factors

If we're making a competition of how long has an given init system been
in Debian, then for sure, OpenRC looses. However, on all the tests I
did, I see no major issue with OpenRC. Could you point to specific
issues that you've encountered? Otherwise, what do you have in mind
exactly, apart from "this is too new, so I don't trust it and therefore
refuse to even try it"?

> and it's not unreasonable to set a deadline, at which the
> state of the system in Debian will be the basis of our technical
> evaluation.

What's difficult for the TC, is that your decision also impacts the
future, not only the present. Only considering what we have right now
isn't unfortunately enough.

I do hope that you are also considering the possible outcomes of current
developments, and paths which has been taken by upstream. I believe it
has been the case already, for example, logind, udev, gnome, etc. and
their future support (using this or that init system) has been part of
this discussion.

It doesn't seem reasonable to just ignore future plans, and incoming
features which are currently in active development (see below about
s-vision patch, which I believe is a very good example illustrating what
I'm saying here).

On 01/19/2014 08:15 PM, Ian Jackson wrote:
>  * The daemon does not double-fork; it runs in the foreground of
>of its initial process.

Something like start-stop-daemon then? :)

See also the command_background directive (in the man openrc-run).

On 01/19/2014 08:15 PM, Ian Jackson wrote:
>  * The daemon's parent process (part of the init system) keeps
>track of it, so the init system knows whether the process
>is still running.

First, OpenRC isn't stateless like sysv-rc to begin with (try
"rc-status" to see what daemon is running). Status are kept in
/run/openrc/started using symlinks to /etc/init.d, and OpenRC uses
(optionally) cgroups to shutdown daemons, if that's what you ask.

Then, the answer to this question is even more definitively "yes", if
you use this patch:
https://github.com/qnikst/openrc/compare/s-vision

which uses monit for the process supervision. If you don't know monit,
well this probably means you haven't played much with servers. Monit has
been in Debian since 2002. It is a very mature tool which is great on
the server side. One of the very cool feature of Monit, is that it
includes email reports (so you know a daemon actually crashed), and
actual service functionality testing (like, is apache returning "hello
world!" when querying this URL, for example...), which none of the other
init system (to the best of my knowledge) implements yet. It is to me a
far more superior approach than just checking for a daemon to be just
"running" (but maybe crashed in a CPU-burn loop...).

I'm talking about a *working patch* here, not just "future plans". If I
didn't add it as a debian/patches add-on, this is because version 0.13
of OpenRC is supposed to be out soon, and it's my understanding that it
would be including it. So I do prefer to wait for the new upstream
release, but it's going to be there soon. Not taking this into account
isn't, IMO, reasonable.

On 01/19/2014 08:15 PM, Ian Jackson wrote:
>  * The daemon's stderr goes somewhere reasonable.

Hum... By default, I honestly don't know what would be the behavior of a
daemon doing some output to stderr. However, I believe it'd be really
trivial to do in the command= statement of a runscript. Something like:

command="foo >/var/log/foo.log 2>&1"

or using the command_arg directive should be enough (I haven't tested,
but this seems reasonable).

Thomas Goirand (zigo)


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

Bug#735742: circular dependency with libav (libavformat-dev)

[Fabian Greffrath]

Am Freitag, den 17.01.2014, 16:40 +0100 schrieb Helge Deller: 
> Package x264 has a circular build-dependency with libav (libavformat-dev).
> I mean, the libav package build-depends on x264, and vice versa.
> This prevented building x264 and libav on a new debian platform.
> I fixed it manually for the hppa platform, but nevertheless, I think this 
> should be fixed.

This is already known and documented in libav's README.source. However,
as long as we don't have staged Build-Depends or Build-Recommends in
Debian, we see little chance to fix this. :/

- Fabian


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

Bug#711383: texmacs is non redistribuable even under non freeea

[François Poulain]

Hi,

I am a TeXmacs developper, and I discover this bug. I will make the
needed stuffs in order to distribute properly these fonts.

François

-- 
François Poulain 


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

Bug#418199: Fwd: Re: segfault with exceedingly long path

[Richard Hartmann]

Not done yet but it's being addressed.

Richard

Sent by mobile; excuse my brevity.
-- Forwarded message --
From: "Bart Schaefer" 
Date: Jan 20, 2014 2:11 AM
Subject: Re: segfault with exceedingly long path
To: 
Cc:

On Jan 19,  4:02pm, Bart Schaefer wrote:
}
} I don't think we want to let this can of worms out of Pandora's box,
} or we'll be chasing geese until the cows come home to roost.

In spite of that ... we could at least not dump core in this specific
case.  There are probably many other core dumps waiting to be exposed.

Behavior becomes undefined once the path gets too long, but:

diff --git a/Src/utils.c b/Src/utils.c
index c6d178c..705d2c4 100644
--- a/Src/utils.c
+++ b/Src/utils.c
@@ -725,32 +725,36 @@ xsymlinks(char *s)
 char **pp, **opp;
 char xbuf2[PATH_MAX*2], xbuf3[PATH_MAX*2];
 int t0, ret = 0;
+zulong xbuflen = strlen(xbuf);

 opp = pp = slashsplit(s);
-for (; *pp; pp++) {
-   if (!strcmp(*pp, ".")) {
-   zsfree(*pp);
+for (; xbuflen < sizeof(xbuf) && *pp; pp++) {
+   if (!strcmp(*pp, "."))
continue;
-   }
if (!strcmp(*pp, "..")) {
char *p;

-   zsfree(*pp);
if (!strcmp(xbuf, "/"))
continue;
if (!*xbuf)
continue;
-   p = xbuf + strlen(xbuf);
-   while (*--p != '/');
+   p = xbuf + xbuflen;
+   while (*--p != '/')
+   xbuflen--;
*p = '\0';
continue;
}
sprintf(xbuf2, "%s/%s", xbuf, *pp);
t0 = readlink(unmeta(xbuf2), xbuf3, PATH_MAX);
if (t0 == -1) {
-   strcat(xbuf, "/");
-   strcat(xbuf, *pp);
-   zsfree(*pp);
+   zulong pplen = strlen(pp) + 1;
+   if ((xbuflen += pplen) < sizeof(xbuf)) {
+   strcat(xbuf, "/");
+   strcat(xbuf, *pp);
+   } else {
+   *xbuf = 0;
+   break;
+   }
} else {
ret = 1;
metafy(xbuf3, t0, META_NOALLOC);
@@ -759,10 +763,9 @@ xsymlinks(char *s)
xsymlinks(xbuf3 + 1);
} else
xsymlinks(xbuf3);
-   zsfree(*pp);
}
 }
-free(opp);
+freearray(opp);
 return ret;
 }

@@ -779,8 +782,10 @@ xsymlink(char *s)
return NULL;
 *xbuf = '\0';
 xsymlinks(s + 1);
-if (!*xbuf)
+if (!*xbuf) {
+   zwarn("path expansion failed, using root directory");
return ztrdup("/");
+}
 return ztrdup(xbuf);
 }


--
Barton E. Schaefer

Bug#736144: python-webm: needs update for libwebp5

[Julien Cristau]

Source: python-webm
Version: 0.2.2-2
Severity: serious
Control: block 731168 with -1

Hi,

libwebp changed SONAMEs again, libwebp4 is being replaced by libwebp5,
so python-webm needs a rebuild (and possibly an update to take the ABI
changes into account).

Cheers,
Julien


signature.asc
Description: Digital signature

Bug#731168: transition: libwebp

[Julien Cristau]

On Mon, Dec  2, 2013 at 10:32:38 -0800, Jeff Breidenbach wrote:

> Package: release.debian.org
> Severity: normal
> User: release.debian@packages.debian.org
> Usertags: transition
> 
> Upstream is releasing a new version of webp soon that has an expanded
> API, and therefore will bump soname and package from libwebp4 to
> libwebp5. Reverse dependency list appended; I think they will require
> nothing more than binNMU.
> 
FWIW this "therefore" doesn't make much sense.  If the API was only
expanded, then the SONAME wouldn't need a bump.

Cheers,
Julien


signature.asc
Description: Digital signature

Bug#418199: Fwd: Re: segfault with exceedingly long path [origin: schae...@brasslantern.com]

[Frank Terbeck]

Goswin von Brederlow wrote:
> On Sat, Jan 18, 2014 at 10:19:39AM +0100, Axel Beckert wrote:
[...]
>> upstream said, this is an issue which is "unlikely ever to be fixed".
>> Marking as such.
[...]
> From: Bart Schaefer :
>> [...]  Various parts
>> of the shell rely on system limits such as PATH_MAX which cannot be
>> dynamically changed.  There's a comment with some explanation around
>> lines 109-137 of Src/compat.c.
[...]
> Could you fix that in Debian even if upstream doesn't care? A segfault

Fixing it in debian and not upstream is very unlikely. It is not like
upstream doesn't care. It's much more that the underlying problem is
quite hard to fix correctly in the current code. If we had a proper fix,
they would take it faster than you can say "ouch, that was a segfault.".

> is never right. If zsh can't handle the long path then it must check

Yes, they are never right. Bart Schaefer from upstream (who said that is
unlikely to be fixed) knows that as well. He also send a patch that
should stop the shell from segfaulting in this particular case:

  http://www.zsh.org/mla/workers/2014/msg00085.html

But this is currently more like plucking holes than fixing the
underlying problem; i.e. the reliance on static system limits like
PATH_MAX.

> the length and give an error. Not fixing a segfault is imho
> unacceptable.

As always, send patches.

Regards, Frank


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

Bug#655106: [hpijs-ppds] margins for F4280 are wrong - calling make-duplex-page-sizes-default.sh

[Mark Purcell]

forwarded 655106 https://bugs.launchpad.net/hplip/+bug/487695

On Sun, 19 Jan 2014 14:11:59 Francesco Muzio wrote:
> here http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=655106#47 I have 
> found what cause the problem, this is a debianized-only patch that 
> screws totally the borders on printed pages for most HP printers.
> 
> I would like to know from you if this bug can be fixed

Francesco,

This patch is also installed on the Ubuntu install as well, so it isn't just a 
Debian issue. As we sync with Ubuntu & upstream that is where this change has 
come from.

Till can you comment on the ongoing need to call 
debian/local/make-duplex-page-sizes-default.sh

To address the issues identified at:
 https://bugs.launchpad.net/hplip/+bug/487695

Mark


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

Bug#706895: transition: db5.3

[Julien Cristau]

Control: tag -1 confirmed

On Sun, Oct 27, 2013 at 13:56:34 +0100, Ondřej Surý wrote:

> And could we talk about the schedule of this transition? Seems like this
> will be last Berkeley DB transition ever :).
> 
I guess if you want to switch db-defaults to 5.3 and are confident it
won't break too many reverse deps you can go ahead.

Cheers,
Julien


signature.asc
Description: Digital signature

Bug#727708: The tech ctte isn't considering OpenRC at all

[Russ Allbery]

Thomas Goirand  writes:

> Then, the answer to this question is even more definitively "yes", if
> you use this patch:
> https://github.com/qnikst/openrc/compare/s-vision

> which uses monit for the process supervision. If you don't know monit,
> well this probably means you haven't played much with servers. Monit has
> been in Debian since 2002. It is a very mature tool which is great on
> the server side.

monit is a fine tool, but it's really orthogonal to the question of what
an init system should do.  It's essentially an event-based monitoring tool
that, as you say, can monitor various aspects of a service apart from just
whether it's running and trigger arbitrary actions on that basis.  It will
work with any init system; in fact, normally it's configured to run init
scripts.

I don't see it as a substitute for the init system tracking accurate state
and PID of its daemons.  The point of knowing the state of daemons isn't
only to be able to restart them when they die, although that's certainly
important and one gets that effectively for free once one has state
tracking.  It's to ensure that everything else the init system is managing
stays consistent and is in a known state for features such as
dependencies.  If service A depends on service B, and you try to start
service B, you want the init system to know that service A has crashed and
isn't currently running so that it can take the correct actions.  And, of
course, the init system needs to know the correct PID to send various
signals to for such things as stop and refresh actions.

Now, you could possibly use monit as the component that does that.  But it
just moves the problem to figuring out how to do proper non-forking
startup and startup notification to monit instead of the init system.

I didn't recall monit having direct support for that, and I just now
reviewed the documentation and still don't see that documented.  Does
monit now support something like the systemd startup notification protocol
or the upstart expect stop protocol?

> One of the very cool feature of Monit, is that it includes email reports
> (so you know a daemon actually crashed), and actual service
> functionality testing (like, is apache returning "hello world!" when
> querying this URL, for example...), which none of the other init system
> (to the best of my knowledge) implements yet. It is to me a far more
> superior approach than just checking for a daemon to be just "running"
> (but maybe crashed in a CPU-burn loop...).

Service functionality testing is a nice feature for what monit is trying
to do, but it's somewhat less helpful in the context of the init system.

When configured by the local sysadmin, deciding that Apache is running if
something is responding on port 80 is fine, since the sysadmin knows
that's the only thing they're running on port 80.  But the init system
needs to have more accurate tracking than that, for exactly the same
reason that Debian Policy says that init scripts should not stop random
other processes that happen to have the same executable name as the daemon
the init script is supposed to be managing.  (Something that a lot of our
init scripts currently probably don't handle correctly, since doing this
properly without starting processes in the foreground using the strategies
used by either upstart or systemd can be quite tricky, although
start-stop-daemon tries to provide proper tools.)

There's definitely a place for monit in an overall systems architecture,
along with a way for monit to tell the init system "hey, you might think
this thing is running, but based on the additional probes I've been
configured to try, I think it's actually hosed."  But it's not solving
quite the same problem.

> On 01/19/2014 08:15 PM, Ian Jackson wrote:
>>  * The daemon's stderr goes somewhere reasonable.

> Hum... By default, I honestly don't know what would be the behavior of a
> daemon doing some output to stderr. However, I believe it'd be really
> trivial to do in the command= statement of a runscript. Something like:

> command="foo >/var/log/foo.log 2>&1"

> or using the command_arg directive should be enough (I haven't tested,
> but this seems reasonable).

The problem with just redirecting output to a log file is that now that
log file is impossible to rotate safely, since you can't rename foo.log
and tell the daemon to re-open a new file by that name.  In other words,
this is a great way to run a production server out of disk space, as I
have done multiple times in the past by using a technique like this and
not thinking it through.

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


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

Bug#669348: transition: openjpeg

[Julien Cristau]

Control: block -1 with 735847

On Thu, Apr 19, 2012 at 11:47:45 +0200, Mathieu Malaterre wrote:

> Package: release.debian.org
> Severity: normal
> User: release.debian@packages.debian.org
> Usertags: transition
> 
> 
> I'd like to request a transition slot for openjpeg 1.5. the main reason for 
> 1.5 is that it fixes JPEG 2000 support in PDF file, see #659226 & #667708
> 
This is now going to block on #735847 (or on getting rid of freeimage,
if possible...).

Cheers,
Julien


signature.asc
Description: Digital signature

Bug#733443: mini-buildd: should include apt-transport-https if https:// sources are in use

[Stephan Sürken]

Hi Klee,

On Sat, 2013-12-28 at 16:19 -0500, Klee Dienes wrote:
(...)
>sudo apt-get --option=Acquire::Languages=none update
>
> 
>E: The method driver /usr/lib/apt/methods/https could not be found.
> 
>E: Command 'sudo apt-get --option=Acquire::Languages=none update' failed 
> to run.
(...)
> Since the 'apt-get update' runs before the custom chroot setup script,
> this is not easy to work around.
> 
> It would be good to either make this part of the default behavior, or
> done automatically if a https: source is in use, or at minimum provide
> a way to run a pre-apt-get-update script.

thanks for the report. I actually already ran into this myself (i.e., on
a feature branch using SSL in mini-buildd itself).

It should be possible quite easily doing this automatically, I guess,
doing it before all other setups, with the untainted sources list of the
chroot. Let's see if this is simple enough to go to RC, but I will
provide a patch soon...

Afaiu, we would also need ca-certificates then, to make "some" archives
acually work out of the box. Certificates not covered by
ca-certificates, or self-signed, would still not work, right?

Hth,

Stephan


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

Bug#735742: circular dependency with libav (libavformat-dev)

[Jonas Smedegaard]

Quoting Fabian Greffrath (2014-01-20 09:43:49)
> Am Freitag, den 17.01.2014, 16:40 +0100 schrieb Helge Deller: 
>> Package x264 has a circular build-dependency with libav 
>> (libavformat-dev).
>> I mean, the libav package build-depends on x264, and vice versa.
>> This prevented building x264 and libav on a new debian platform.
>> I fixed it manually for the hppa platform, but nevertheless, I think 
>> this should be fixed.
> 
> This is already known and documented in libav's README.source. 
> However, as long as we don't have staged Build-Depends or 
> Build-Recommends in Debian, we see little chance to fix this. :/

Progress on implementing such staged builds is tracked here: 
https://wiki.debian.org/BuildProfileSpec

I believe the "Build-Profiles" approach is the most realistic approach 
to implement (and can even be applied already now - Wookie probably 
knows best so ask him if interested in helping test it).

 - Jonas

-- 
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/

 [x] quote me freely  [ ] ask before reusing  [ ] keep private


signature.asc
Description: signature

Bug#719227: transition: poppler 0.22

[Julien Cristau]

On Fri, Aug  9, 2013 at 15:45:19 +0200, Pino Toscano wrote:

> Package: release.debian.org
> Severity: normal
> User: release.debian@packages.debian.org
> Usertags: transition
> Control: block -1 by 679896 719224 712688
> 
> Hi,
> 
> I would like to ask a slot for a Poppler 0.22.x transition.
> Currently there is Poppler 0.22.x in experimental already. Please note
> that there are still few issues that prevents it to be started,
> so I'm filing this at this time to have this transition considered
> by the release team.
> 
Is this only blocking on us now?  If so please feel free to upload.

Cheers,
Julien


signature.asc
Description: Digital signature

Bug#736145: nvidia-detect gives no senseful output

[Karsten Malcher]

Package: nvidia-detect
Version: 319.76-1
Severity: important

Hello,

the upgrade from wheezy to jessie failed. Please refer to bug 
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=735424

When i run nvidia-detect i get this output:

Detected NVIDIA GPUs:
02:00.0 VGA compatible controller [0300]: NVIDIA Corporation GF108 [GeForce GT 
430] [10de:0de1] (rev a1)
Your card is supported by the default drivers and version 304.
It is recommended to install the
nvidia-driver

package.


That's wrong!
Correct should be 319.76 and this is installed:


ii  glx-alternative-nvidia0.4.1  amd64allows the selection of NVIDIA as 
GLX provider
rc  libgl1-nvidia-alternatives-ia32   304.88-1+deb7u1amd64simplifies replacing MESA libGL 
with GPU vendor libraries (32-bit)

ii  libgl1-nvidia-glx:amd64   319.76-1   amd64  
  NVIDIA binary OpenGL libraries
ii  libgl1-nvidia-glx:i386319.76-1   i386   
  NVIDIA binary OpenGL libraries
ii  libgl1-nvidia-glx-i386319.76-1   i386   
  NVIDIA binary OpenGL 32-bit libraries
ii  libnvidia-compiler:amd64  319.76-1   amd64  
  NVIDIA runtime compiler library
ii  libnvidia-ml1:amd64   319.76-1   amd64NVIDIA Management Library (NVML) 
runtime library

rc  libxvmcnvidia1:amd64  304.88-1+deb7u1amd64  
  NVIDIA binary XvMC library
ii  nvidia-alternative319.76-1   amd64allows the selection of NVIDIA as 
GLX provider

ii  nvidia-detect 319.76-1   amd64  
  NVIDIA GPU detection utility
ii  nvidia-driver 319.76-1   amd64  
  NVIDIA metapackage
ii  nvidia-glx319.76-1   amd64  
  transition to nvidia-driver
ii  nvidia-installer-cleanup  20131102+1 amd64cleanup after driver installation 
with the nvidia-installer
ii  nvidia-kernel-common  20131102+1 amd64NVIDIA binary kernel module 
support files
ii  nvidia-kernel-dkms319.76-1   amd64NVIDIA binary kernel module DKMS 
source

ii  nvidia-opencl-common  319.76-1   amd64  
  NVIDIA OpenCL driver
ii  nvidia-opencl-icd:amd64   319.76-1   amd64  
  NVIDIA OpenCL ICD
ii  nvidia-settings   319.72-1   amd64tool for configuring the NVIDIA 
graphics driver
ii  nvidia-support20131102+1 amd64NVIDIA binary graphics driver 
support files

ii  nvidia-vdpau-driver:amd64 319.76-1   amd64  
  NVIDIA vdpau driver
ii  nvidia-xconfig319.72-1   amd64X configuration tool for non-free 
NVIDIA drivers

ii  xserver-xorg-video-nvidia 319.76-1   amd64  
  NVIDIA binary Xorg driver


Regards
Karsten


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

Bug#736126: /dev/random entropy depletion on a fresh install

[Jérémy Bobbio]

Control: reassign -1 tasksel

Jeffrey Walton:
> It would probably be very beneficial to install an entropy gatherer by
> default.

I am unconvinced that haveged is the answer here, but reassigning to the
proper package.

-- 
Jérémy Bobbio.''`.
jeremy.bob...@irq7.fr   : :   : lu...@debian.org
`. `'`  lu...@torproject.org
  `-


signature.asc
Description: Digital signature

Bug#725951: libgphoto2 2.5.2 uploaded to experimental

[Julien Cristau]

Control: tag -1 confirmed

On Mon, Jan  6, 2014 at 03:06:03 +0100, Laurent Bigonville wrote:

> Le Sun, 5 Jan 2014 01:54:07 +0100,
> Laurent Bigonville  a écrit :
> 
> > Hi,
> > 
> > I've uploaded libgphoto2 2.5.2 to experimental and it's now in the
> > archive.
> > 
> > The following packages are failing and will require a new upstream
> > release, I didn't look at this yet:
> > 
> > gphoto2_2.4.14-1
> > gphotofs_0.4.0-6
> 
> And I just uploaded the updated version of these 2 packages.
> 
Thanks.  If experimental builds haven't turned up any new issues, please
feel free to move this to sid.

Cheers,
Julien


signature.asc
Description: Digital signature

Bug#735424: nvidia-driver: needed option x for additional information

[Karsten Malcher]

Am 19.01.2014 19:00, schrieb Andreas Beckmann:

On 2014-01-15 17:54, Karsten wrote:

Here are the automatic collected informations.

So far I don't see any errors ...
X starts ... and after 30 seconds cleanly shuts down.
Please check the logfile of login manager (gdm3, kdm, xdm or whatever)


That's what i can't understand too.
After boot X does not start and i land on the basic text shell.
So i can log in as user and startx.

Without xorg.conf i only get the error "no screens found".
With an xorg.conf i only get an blank black screen.
It seems that the graphic card is not initialized correctly or something else.
Shutdown is with CTRL-C by the user.



Please try the new driver releases 319.82 in unstable and 331.38 in
experimental.


How can i install this driver in jessie?


  And try a minimal config file as decribed in
/usr/share/doc/nvidia-driver/README.Debian.gz


I tried to use nvidia-xconfig with the same result of this black blank screen.
The xorg.conf is attached.

Karsten

# nvidia-xconfig: X configuration file generated by nvidia-xconfig
# nvidia-xconfig:  version 319.72  (pbuilder@cake)  Sat Nov  9 14:15:48 UTC 2013


Section "ServerLayout"
Identifier "Layout0"
Screen  0  "Screen0" 0 0
InputDevice"Keyboard0" "CoreKeyboard"
InputDevice"Mouse0" "CorePointer"
EndSection

Section "Files"
EndSection

Section "InputDevice"

# generated from default
Identifier "Mouse0"
Driver "mouse"
Option "Protocol" "auto"
Option "Device" "/dev/psaux"
Option "Emulate3Buttons" "no"
Option "ZAxisMapping" "4 5"
EndSection

Section "InputDevice"

# generated from default
Identifier "Keyboard0"
Driver "kbd"
EndSection

Section "Monitor"
Identifier "Monitor0"
VendorName "Unknown"
ModelName  "Unknown"
HorizSync   28.0 - 33.0
VertRefresh 43.0 - 72.0
Option "DPMS"
EndSection

Section "Device"
Identifier "Device0"
Driver "nvidia"
VendorName "NVIDIA Corporation"
EndSection

Section "Screen"
Identifier "Screen0"
Device "Device0"
Monitor"Monitor0"
DefaultDepth24
SubSection "Display"
Depth   24
EndSubSection
EndSection

Bug#677446: g15stats cannot display CPU usage

[Aleksi Suhonen]

Hello,

I can confirm that the following bug exists in Debian too and would like 
to see this package updated from upstream:



https://bugs.launchpad.net/ubuntu/+source/g15stats/+bug/749834

--
Aleksi Suhonen

() ascii ribbon campaign
/\ support plain text e-mail


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

Bug#734271: segfaults (often, but not always) after resume

[Stéphane Glondu]

I wrote:
> Xorg still segfaults after switching to nouveau (log attached).

Actually, X does not work at all with nouveau, after suspend/resume. I
see a picture of the screensaver, but "graphical seat" does not seem
responsive at all (no Alt-F1, not even Num Lock LED switching).

Worse, in this state, the system cannot be rebooted anymore (in
software, with "shutdown").

And even a hard reboot doesn't fix things: I still still the boot
messages (BIOS, sysv), but when X starts, the screen stays black and no
way to switch to console (Alt-F1). In dmesg, I get the following
suspicious messages:

> [   47.912532] nouveau E[  PGRAPH][:02:00.0] TRAP_MP_EXEC - TP 0 MP 0: 
> (unknown enum 0x0002) at 00 warp 6, opcode  22882831
> [   47.912551] nouveau E[  PGRAPH][:02:00.0]  TRAP
> [   47.912561] nouveau E[  PGRAPH][:02:00.0] ch 2 [0x0007b45000 
> Xorg[3463]] subc 2 class 0x502d mthd 0x08dc data 0x
> [   48.081476] nouveau E[  PGRAPH][:02:00.0] TRAP_MP_EXEC - TP 0 MP 0: 
> (unknown enum 0x0002) at 00 warp 6, opcode  22882831
> [   48.081491] nouveau E[  PGRAPH][:02:00.0]  TRAP
> [   48.081500] nouveau E[  PGRAPH][:02:00.0] ch 4 [0x000797f000 
> gnome-session-c[4148]] subc 3 class 0x8397 mthd 0x1b0c data 0x1000f010
> [   54.303084] nouveau E[  PGRAPH][:02:00.0] PGRAPH TLB flush idle 
> timeout fail
> [   54.303091] nouveau E[  PGRAPH][:02:00.0] PGRAPH_STATUS  : 0x0081 
> BUSY MP
> [   54.303095] nouveau E[  PGRAPH][:02:00.0] PGRAPH_VSTATUS0: 0x
> [   54.303098] nouveau E[  PGRAPH][:02:00.0] PGRAPH_VSTATUS1: 0x1000 
> MP
> [   54.303100] nouveau E[  PGRAPH][:02:00.0] PGRAPH_VSTATUS2: 0x
> [   56.305363] nouveau E[  PGRAPH][:02:00.0] PGRAPH TLB flush idle 
> timeout fail
> [   56.305367] nouveau E[  PGRAPH][:02:00.0] PGRAPH_STATUS  : 0x0081 
> BUSY MP
> [   56.305370] nouveau E[  PGRAPH][:02:00.0] PGRAPH_VSTATUS0: 0x
> [   56.305372] nouveau E[  PGRAPH][:02:00.0] PGRAPH_VSTATUS1: 0x1000 
> MP
> [   56.305374] nouveau E[  PGRAPH][:02:00.0] PGRAPH_VSTATUS2: 0x
> [   58.306263] nouveau E[  PGRAPH][:02:00.0] PGRAPH TLB flush idle 
> timeout fail
> [   58.306265] nouveau E[  PGRAPH][:02:00.0] PGRAPH_STATUS  : 0x0081 
> BUSY MP
> [   58.306268] nouveau E[  PGRAPH][:02:00.0] PGRAPH_VSTATUS0: 0x
> [   58.306270] nouveau E[  PGRAPH][:02:00.0] PGRAPH_VSTATUS1: 0x1000 
> MP
> [   58.306272] nouveau E[  PGRAPH][:02:00.0] PGRAPH_VSTATUS2: 0x
> [   60.308417] nouveau E[  PGRAPH][:02:00.0] PGRAPH TLB flush idle 
> timeout fail
> [   60.308428] nouveau E[  PGRAPH][:02:00.0] PGRAPH_STATUS  : 0x0081 
> BUSY MP
> [   60.308436] nouveau E[  PGRAPH][:02:00.0] PGRAPH_VSTATUS0: 0x
> [   60.308440] nouveau E[  PGRAPH][:02:00.0] PGRAPH_VSTATUS1: 0x1000 
> MP
> [   60.308445] nouveau E[  PGRAPH][:02:00.0] PGRAPH_VSTATUS2: 0x
> [   61.266253] RPC: AUTH_GSS upcall timed out.
> [   61.266253] Please check user daemon is running.
> [   62.309417] nouveau E[  PGRAPH][:02:00.0] PGRAPH TLB flush idle 
> timeout fail
> [   62.309426] nouveau E[  PGRAPH][:02:00.0] PGRAPH_STATUS  : 0x0081 
> BUSY MP
> [   62.309435] nouveau E[  PGRAPH][:02:00.0] PGRAPH_VSTATUS0: 0x
> [   62.309439] nouveau E[  PGRAPH][:02:00.0] PGRAPH_VSTATUS1: 0x1000 
> MP
> [   62.309444] nouveau E[  PGRAPH][:02:00.0] PGRAPH_VSTATUS2: 0x
> [   64.319439] nouveau E[  PGRAPH][:02:00.0] TRAP_MP_EXEC - TP 0 MP 0: 
> (unknown enum 0x0002) at 00 warp 6, opcode  22882831
> [   64.319454] nouveau E[  PGRAPH][:02:00.0]  TRAP
> [   64.319463] nouveau E[  PGRAPH][:02:00.0] ch 4 [0x000797f000 
> gnome-shell[4357]] subc 3 class 0x8397 mthd 0x1b0c data 0x1000f010
> [  171.412133] nouveau E[ DRM] GPU lockup - switching to software fbcon

In this state, NumLock and shutdown work, though.

The only way I've found to get a working system back is to switch back
to the nvidia driver.

Cheers,

-- 
Stéphane


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

Bug#728178: GDCM 2.4.1 in shape for transition

[Julien Cristau]

On Mon, Jan  6, 2014 at 10:10:32 +0100, Mathieu Malaterre wrote:

> FYI, GDCM 2.4.1 builds on all archs as can be seen:
> 
> https://buildd.debian.org/status/package.php?p=gdcm&suite=experimental
> 
> It is thus in shape for transition.
> 
Are there any API changes affecting the reverse deps?

Cheers,
Julien


signature.asc
Description: Digital signature

Bug#735384: signing-party: caff leaks signing activity to other local users

[Peter Palfrader]

On Wed, 15 Jan 2014, Christoph Berg wrote:

> Re: Daniel Kahn Gillmor 2014-01-15 
> <20140115032817.1954.22404.report...@alice.fifthhorseman.net>
> >   tempdir("caff-$keyid-X", DIR => '/tmp/', CLEANUP => 1);
> > 
> > But in general, there is no reason to expose this information directly
> > to the rest of the system.  Perhaps the tmpdir could be in another
> > directory with limited permissions?

Just like anybody on the system can list the running processes to see
that you are running gpg --edit .

> I think the better fix is to change the template to caff-XX.
> Trying to use a different tmpdir is just not the "Unix" way. (Having
> said that, it should honor $TMPDIR...)

Not worth it imho.

Cheers,
-- 
   |  .''`.   ** Debian **
  Peter Palfrader  | : :' :  The  universal
 http://www.palfrader.org/ | `. `'  Operating System
   |   `-http://www.debian.org/


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

Bug#735424: nvidia-driver: needed option x for additional information

[Andreas Beckmann]

On 2014-01-20 10:39, Karsten Malcher wrote:
>>   And try a minimal config file as decribed in
>> /usr/share/doc/nvidia-driver/README.Debian.gz
> 
> I tried to use nvidia-xconfig with the same result of this black blank
> screen.
> The xorg.conf is attached.

Did you try the minimal one? I.e. only these 4 lines should be enough.

But lets try the vesa driver first:

* apt-get install xserver-xorg-video-vesa

* update-alternatives --config glx
  select "mesa-diverted"

* use this Xorg.conf:
Section "Device"
Identifier "My GPU"
Driver "vesa"
EndSection

* reboot

If this does not work either, something else is messed up in your system
that is not related to the nvidia driver.

Thereafter run again reportbug -N 735424 and mention whether this was
run after the X (not) started at boot or after manual use of startx.


Andreas


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

Bug#691346: mfi in 9.1

[Tiziano Zito]

On Wed 15 Jan, 11:12, Robert Millan  wrote:
> On Mon, Nov 12, 2012 at 01:56:38PM +0100, Mathieu Simon wrote:
> > G'day
> > 
> > Actually FreBSD 9.1 will contain update 'mfi' driver code which
> > largely expands the support for MegaRAID drivers. (confirmed witha
> > 9.1-RC3 media)
> > It might be interesting for you to boo a native FreeBSD ISO of
> > this version to see if your controller is recognized by this mfi module.
> > (use "pciconf -lvb | grep mfi" and "mfiutil show adapter" to check)
> 
> Tiziano, did you try with 9.1 kernel as suggested? Actually, you could
> try 10.0~rc from unstable, it might give better results.
> 
> Please let us know if it works for you.

Hi, 

sorry for not following up on this sooner. Last year I decided to go
the FreeBSD route and updated the kernel module as specified on the
LSI website. It worked fine.
The upgrade to 9.1 brought the new mfi module, which indeed supports
the controller, so from kernel 9.1 onwards there is no need to
compile any additional module. 

The server is now running a 9.2-RELEASE kernel and everything works
fine. As the server is in production I can not really test a
Debian+kfreebsd installation, but I have no reason to think that it
would make any difference, so for me the bug can be closed :)

Thanks for pinging me about this!
Tiziano


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

Bug#736146: ITP: libnftnl -- nftables low-level userspace library

[Arturo Borrero Gonzalez]

Package: wnpp
Severity: wishlist
Owner: Arturo Borrero Gonzalez 

* Package name: libnftnl
  Version : 0.1
  Upstream Author : Pablo Neira Ayuso 
* URL : http://www.netfilter.org
* License : GPL-2+
  Programming Lang: C
  Description : nftables low-level userspace library

libnftables was renamed upstream to libnftnl.

Previous ITP of libnftables: 
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=708102


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

Bug#735424: nvidia-driver: needed option x for additional information

[Diederik de Haas]

On Monday 20 January 2014 10:39:11 Karsten Malcher wrote:
> > Please try the new driver releases 319.82 in unstable and 331.38 in
> > experimental.
> 
> How can i install this driver in jessie?

Add the following line to your /etc/apt/sources.list:
deb http://ftp.debian.org/debian/ unstable main contrib non-free

You probably also want to create /etc/apt/apt.conf.d/50-default-release with 
the following contents:
Apt {   
  
Default-Release "testing";  
  
}; 

If your /etc/apt/sources.list has "jessie" lines instead of testing, use 
jessie instead.
This will make sure you install packages from testing/jessie by default and 
only install packages from other archives (unstable) when you explicitly say 
so.

To install the nvidia package from unstable, do the following:
aptitude install nvidia-driver -t unstable

This should pull in that package from unstable including it's dependencies.
If it reports dependency issues, let aptitude offer you other suggestions until 
the issues are resolved.
Another useful parameter for aptitude is "-s" which stands for simulate, so 
you can experiment as much as you want (also as normal user) without actually 
committing the changes.

To install the driver from experimental, add another line to your sources, but 
use experimental instead of unstable and to install use '-t experimental' 
instead of '-t unstable'.

> >   And try a minimal config file as decribed in
> > /usr/share/doc/nvidia-driver/README.Debian.gz
> 
> I tried to use nvidia-xconfig with the same result of this black blank
> screen. The xorg.conf is attached.

That's not a minimal config file ;-)
This is:


Section "Device"
Identifier "Device0"
Driver "nvidia"
VendorName "NVIDIA Corporation"
EndSection


So remove all the other lines, so your xorg.conf only contains the part above.

HTH,
  Diederik

-- 
GPG: 0x138E41915C7EFED6

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

Bug#736147: phpunit: Needs to be updated to support new php-codecoverage

[Roland Mas]

Package: phpunit
Version: 3.6.10-1
Severity: normal

phpunit ships /usr/share/php/PHPUnit/Util/GlobalState.php, which has a
function that calls php_codecoverage_autoload().  This function doesn't
exist in the current version of php-codecoverage; if it's in another
package, then there's at least a dependency missing :-)

In any case, it ends up with my testsuites randomly failing with
messages like the following:

1) CreateProject::testEmptyProject
PHP Fatal error:  Call to undefined function php_codecoverage_autoload() in 
/usr/share/php/PHPUnit/Util/GlobalState.php on line 380

Roland.

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

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

Versions of packages phpunit depends on:
ii  pear-channels [pear-phpunit-channel]  0~20131124-1
ii  php-codecoverage  1.2.13+dfsg1-1
ii  php-file-iterator 1.3.1-2
ii  php-pear  5.5.8+dfsg-2
ii  php-symfony-yaml  1.0.6-1
ii  php-text-template 1.1.1-2
ii  php-timer 1.0.2-2
ii  php5-cli  5.5.8+dfsg-2
ii  phpunit-mock-object   1.1.1-2

Versions of packages phpunit recommends:
ii  php-invoker   1.1.0-1
ii  php-token-stream  1.1.3-2
ii  phpunit-story 1.0.0-3

Versions of packages phpunit suggests:
pn  phpunit-dbunit
ii  phpunit-selenium  1.2.6-3

-- no debconf information

-- 
Roland Mas

C   c ee lm  re q   j  l   a l  l  iè e  .
  -- Signatures à collectionner, série n°1, partie 3/3.


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

Bug#728919: freebsd-libs transition

[Julien Cristau]

Control: tag -1 confirmed

On Wed, Nov  6, 2013 at 22:44:53 +0100, Robert Millan wrote:

> Package: release.debian.org
> Severity: normal
> User: release.debian@packages.debian.org
> Usertags: transition
> 
> There are a couple of ABI changes coming to freebsd-libs. They're in
> soon-to-be-released 10.x branch, so it may yet take a while until we get
> them through upstream release upgrade.
> 
> However, as they're highly isolated from the codebase, it is trivial to
> cherry-pick them. I'm sending this request now so that you have more
> room to select the most appropiate time for the transition.
> 
Feel free to upload the new version to sid.

Cheers,
Julien


signature.asc
Description: Digital signature

Bug#736061: libnss3: system shared db enabled leads to local overrides being ignored

[Yves-Alexis Perez]

On Sun, Jan 19, 2014 at 11:08:24AM +0100, Yves-Alexis Perez wrote:
> Package: libnss3
> Version: 2:3.15.4-1
> Severity: important
> 
> Hi,
> 
> I use evolution which uses the shared db in ~/.pki since a long time.
> I've added my own root AC there, and disabled pretty much every other AC
> since I won't use them (and actually receiving a certificate chain
> leading to a common AC would mean someone is trying to MITM me…).
> 
> With the 2:3.15.4-1 nss upload (which apparently enable the system
> shared db) my local AC is gone from the authority and all the other
> trust bits have been reset to the default.
> 
> I've not set it RC, but it's really pretty annoying and can be
> dangerous. I'm unsure if the problem lies in nss or in the way evolution
> loads the DB.

Actually, it might be an ABI issue with evolution or something like
that. On the system where I've not added back my certificates (and thus
I can't access my mails from evolution), here's the output from
evolution startup:


corsac@scapa: evolution

(evolution:29460): camel-WARNING **: Failed to initialize NSS SQL database in 
sql:/etc/pki/nssdb: NSS error -8187

(evolution:29460): camel-WARNING **: Unable to load store summary: Expected 
version (1), got (0)

(evolution:29460): camel-WARNING **: Cannot load summary file: Success

(evolution:29460): camel-WARNING **: Unable to load store summary: Expected 
version (1), got (0)

(evolution:29460): camel-WARNING **: Cannot load summary file: Success


Same output on the one where I did add back my local AC, but it still
manages to initialize NSS since it'll later correctly connect to my mail
server.

If you need more information, please ask.

Regards,
-- 
Yves-Alexis Perez


signature.asc
Description: Digital signature

Bug#531809: Fixed in recent release

[Guillaume Beraudo]

Hi,

It is possible to choose default identity in the dialer since
at least linphone 3.3/squeeze.


Guillaume Beraudo


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

Bug#736147: [pkg-php-pear] Bug#736147: phpunit: Needs to be updated to support new php-codecoverage

[Prach Pongpanich]

control: tags 736147 + pending

On Mon, Jan 20, 2014 at 4:53 PM, Roland Mas  wrote:
> Package: phpunit
> Version: 3.6.10-1
> Severity: normal
>
> phpunit ships /usr/share/php/PHPUnit/Util/GlobalState.php, which has a
> function that calls php_codecoverage_autoload().  This function doesn't
> exist in the current version of php-codecoverage; if it's in another
> package, then there's at least a dependency missing :-)
>
> In any case, it ends up with my testsuites randomly failing with
> messages like the following:
>
> 1) CreateProject::testEmptyProject
> PHP Fatal error:  Call to undefined function php_codecoverage_autoload() in 
> /usr/share/php/PHPUnit/Util/GlobalState.php on line 380
>

Thank you for your report, we plan to upload it (3.7.28) within a week.

Regards,
 Prach


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

Bug#716796: JSHint is optional

[Daniel Pocock]

JSHint is optional, as noted earlier, it is just a tool to spot mistakes

We can still build a valid jQuery package without running JSHint during
the build

Any calls to JSHint can be replaced with a call to /bin/true


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

Bug#718805: Re: Bug#718805: /usr/bin/avconv: avconv cannot grab video4linux2 device

[Nikolay Shaplov]

On Sunday 19 January 2014 11:24:57 Reinhard Tartler wrote:

> When looking at the upstream commits, can you please apply this patch
> to your tree, and tell me if it makes the segfault go away?
> 
> http://git.libav.org/?p=libav.git;a=commitdiff;h=838b849e70f11dc242399da8d19
> c5795fe90913b

I've apllied this patch to src package, built it, and installed the result deb 
files:

same effect.

> 
> 
> Also, if this still persists, please also check the avconv binary
> I''ve uploaded yesterday to debian/experimental. It is pretty close to
> current libav/master right now.


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

Bug#708181: Workaround

[Colin Watson]

On Sun, Jan 19, 2014 at 11:36:17PM +0100, Francesco Poli wrote:
> On Sat, 11 Jan 2014 17:34:50 +0100 Kim Rydhof Thor Hansen wrote:
> > I was also bitten by this bug, the problem it that the default
> > behaviour for menus with no security defined has changed from being
> > unrestricted to being restricted if some users are defined.
> > 
> > My workaround is to make the "Simple" default selection unrestricted like 
> > this:
> [...]
> 
> I prepared a more general patch (against grub2/2.00-22) that lets the
> user add options to the simple menu entry and to the advanced submenu
> and menu entries.

Please rebase your patch against current upstream git and send it
upstream first; I don't think it's a good idea to apply configuration
patches of this kind that haven't been accepted upstream, as it might
well lead to compatibility problems in future.

Thanks,

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


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

Bug#732118: Confirmed working

[VALETTE Eric OLNC/OLPS]

  
  
Just tested after manually rebuilding xserver-xorg-input-evdev and
xserver-xorg-input-synaptics => works. 

Thanks.
-- eric
  



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

Bug#736148: cloud-init: please upgrade to 0.7.5 for OpenNebula support

[Olivier Sallou]

Package: cloud-init
Version: 0.7.2-3
Severity: wishlist

Dear Maintainer,
please upgrade in unstable and backports to v0.7.5 that integrates OpenNebula 
support in cloud-init.
I expect to use it in build-debian-cloud to generate OpenNebula virtual 
machines.

Thanks


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

Kernel: Linux 2.6.32-5-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


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

Bug#728178: GDCM 2.4.1 in shape for transition

[Mathieu Malaterre]

On Mon, Jan 20, 2014 at 10:41 AM, Julien Cristau  wrote:
> On Mon, Jan  6, 2014 at 10:10:32 +0100, Mathieu Malaterre wrote:
>
>> FYI, GDCM 2.4.1 builds on all archs as can be seen:
>>
>> https://buildd.debian.org/status/package.php?p=gdcm&suite=experimental
>>
>> It is thus in shape for transition.
>>
> Are there any API changes affecting the reverse deps?

No API changes. ABI in incompatible, thus all reverse deps needs to be rebuild.

Thanks,


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

Bug#735743: [Python-apps-team] Bug#735743: pylint fails to install in emacs : ERROR: pylint is broken

[Agustin Martin]

On Sat, Jan 18, 2014 at 04:53:52PM +0100, Sandro Tosi wrote:
> Hello,
> what version of emacs23 do you have?

Recently had this issue in dictionaries-common.

Is emacsen-common version what matters here,

emacsen-common (2.0.6) unstable; urgency=low

  [...]
  * Complain loudly if an add-on package appears to be broken.  Add
validate_add_on_pkg() to verify that an add-on package's invocations
match its "style", and call it from emacs-package-install and
emacs-package-remove.
  [...]

If you use dh_installemacsen, just need to add something like 

debian/emacsen-compat

containing a plain 0. See emasen-common policy, look for emacsen-common
compatibility level.

Hope this helps,

Regards,

-- 
Agustin


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

Bug#701772: iso-scan: Loads wrong iso from usb drive

[Martín Ferrari]

Package: iso-scan
Followup-For: Bug #701772

I am experiencing the same problem here, trying to prepare a USB stick with
many installer images (i386, amd64, stable, testing..).

Looking at iso-scan code I can see a few problems here:

1. Even if more than one ISO is found, the first pass will choose by default
one image instead of asking, because of medium debconf priority. I think this
is a problem, as I cannot raise that question priority without raising all
other questions.

2. When choosing an ISO without asking the user, it is not taking into account
the release of the ISO file. If it at least preferred the matching ISO, this
wouldn't be a problem.

3. iso-scan does not accept any input on the location of the ISO file. Having
this functionality (for example, by checking the iso-scan/filename variable
before starting), it would save time and avoid all these problems.


For now, the only workaround I've found is to put all ISO images outside of the
first pass' reach (i.e. in 2rd level directories), and then preseed
iso-scan/ask_second_pass=true but this is far from optimal.

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

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


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

Bug#736149: Empathy screenshots for debian.org SIP accounts

[Daniel Pocock]

Package: telepathy-rakia

Could you please suggest a recommended configuration for debian.org SIP
users to use Empathy?

I've tried it myself but it fails to register (using 0.7.4-1 from wheezy)

https://wiki.debian.org/UnifiedCommunications/DebianDevelopers/Empathy

Also, we don't want people to manually configure the SIP proxy name in
the config panel.  Can you let me know if Empathy can discover the proxy
using NAPTR and SRV lookups in DNS?  That is how Jitsi is finding it.


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

Bug#735883: python-csb's autopkg test never succeeds

[Tomás Di Domenico]

I cannot reproduce this error on my machines, neither when building the
package nor when running the tests manually.

I've asked for help on the Debian Med list, and will update the package
as soon as I figure out a solution.


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

Bug#736150: transition: libexosip2

[Mark Purcell]

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

Hi,

Request a transition slot for libexosip2.

Thanks,
Mark

libexosip2-10
Reverse Depends:
  libexosip2-10:i386
  sipwitch
  linphone-nogtk
  linphone
  liblinphone5
  libexosip2-dev


Ben file:

title = "libexosip2";
is_affected = .depends ~ "libexosip2-10" | .depends ~ "libexosip2-11";
is_good = .depends ~ "libexosip2-11";
is_bad = .depends ~ "libexosip2-10";


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

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


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

Bug#735923: piuparts: maybe --pbuilder should also set --tmpdir?

[Andreas Beckmann]

On 2014-01-18 17:44, Helmut Grohne wrote:
> When using piuparts --pbuilder I noticed that it feels slow. Now that's
> not the fault of piuparts, but instead an artifact of my setup that made
> me ponder whether piuparts' defaults are good. It happens that I mounted
> /var/cache/pbuilder/build as an fs tuned for performance. I was kind of
> expecting piuparts to use pbuilders build directory. So maybe setting
> --pbuilder should also set --tmpdir?

I don't think so ... anyway I don't like the --pbuilder option as this
is not a minimal chroot and therefore may hide errors. We might migitate
this a bit with --minimize, but there is also the bug report about
pbuilder+cdebootstrap+piuparts conflicts ...

I'm a user of pbuilder myself with /tmp/pbuilder/build as build
directory on a 24GB tmpfs on /tmp :-)

We should make it more easy to create/update dedicted piuparts chroot
traballs ...


Andreas


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

Bug#736151: youtube-dl: Should not recommend mplayer

[Salvo 'LtWorf' Tomaselli]

Package: youtube-dl
Version: 2013.12.04-1
Severity: normal

Dear Maintainer,
the package should not recommend mplayer | mplayer2. There is a huge amount
of players able to play videos, it's not reasonable to list them all in 
recommends.

Moreover mplayer does not add any functionality to the package, if you check the
debian policy about depends/recommends/suggests, that should at best be a 
suggests
or disappear completely.

Regards


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

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

Versions of packages youtube-dl depends on:
ii  python2.7.5-5
ii  python-pkg-resources  2.0.2-1

Versions of packages youtube-dl recommends:
ii  libav-tools 6:9.10-2
ii  mplayer2 [mplayer]  2.0-701-gd4c5b7f-2
ii  rtmpdump2.4+20121230.gitdf6c518-1

youtube-dl suggests no packages.

-- no debconf information


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

Bug#733900: piuparts-report: use final version number for upgrade reports

[Andreas Beckmann]

On 2014-01-10 03:28, Andreas Beckmann wrote:
> ... that probably won't work ... I would expect a crash on a
> disappearing package.

OK, it didn't crash. But it does no longer update the source summaries
for removed source packages, e.g.

https://piuparts.debian.org/wheezy2jessie/source/n/nana.html

BTW, please reschedule

*{jessie,sid}*/pass/{nana,opt,trueprint,elib,bison++,jargon}_*.log

Andreas


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

Bug#736152: /usr/bin/wine: 11: /usr/bin/wine: /usr/bin/wine32: not found

[Eerste Laatste]

Package: wine
Version: 1.6.2-2
Severity: important

Dear Maintainer,
*** Please consider answering these questions, where appropriate ***

   * What led up to the situation?

$ apt-get install wine

   * What exactly did you do (or not do) that was effective (or
 ineffective)?

$ wine

   * What was the outcome of this action?

/usr/bin/wine: 11: /usr/bin/wine: /usr/bin/wine32: not found

   * What outcome did you expect instead?

Wine to start.


Possibly useful additional info:
$ which wine
/usr/bin/wine
$ ls -lh /usr/bin/wine32
lrwxrwxrwx 1 root root 37 Jan 15 05:07 /usr/bin/wine32 -> 
../lib/i386-linux-gnu/wine/bin/wine32
$ ls -lh /usr/lib/i386-linux-gnu/wine/bin/wine32
lrwxrwxrwx 1 root root 4 Jan 15 05:07 /usr/lib/i386-linux-gnu/wine/bin/wine32 
-> wine


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


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

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

Versions of packages wine depends on:
ii  file1:5.14-2
ii  wine32  1.6.2-2
ii  wine64  1.6.2-2

wine recommends no packages.

Versions of packages wine suggests:
pn  avscan | klamav | clamav   
ii  binfmt-support 2.1.1-1
ii  ttf-mscorefonts-installer  3.5
pn  winbind
pn  wine-doc   

-- no debconf information


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

Bug#727708: init system discussion status

[Ian Jackson]

Keith Packard writes ("Re: Bug#727708: init system discussion status"):
> I feel that having the Debian community endorse software where a CLA is
> involved will tacitly encourage developers to enter into those
> agreements so that their work can be published as widely as possible.

I can see the force of this point.

Could we address this by adding something explicit to the TC
resolution ?

  N. We are firmly opposed to Canonical's upstart Contributor Licence
 Agreement.

 As with any other program in Debian whose upstream has
 controversial copyright practices, the Debian project will
 continue accept and deploy useful patches whose contributors
 decline to enter into unfair copyright agreements.

 We recommend that Debian contributors do not sign the CLA, even
 when contributing changes which might be widely useful.

Ian.


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

Bug#728178: GDCM 2.4.1 in shape for transition

[Julien Cristau]

Control: tag -1 confirmed

On Mon, Jan 20, 2014 at 11:44:27 +0100, Mathieu Malaterre wrote:

> On Mon, Jan 20, 2014 at 10:41 AM, Julien Cristau  wrote:
> > On Mon, Jan  6, 2014 at 10:10:32 +0100, Mathieu Malaterre wrote:
> >
> >> FYI, GDCM 2.4.1 builds on all archs as can be seen:
> >>
> >> https://buildd.debian.org/status/package.php?p=gdcm&suite=experimental
> >>
> >> It is thus in shape for transition.
> >>
> > Are there any API changes affecting the reverse deps?
> 
> No API changes. ABI in incompatible, thus all reverse deps needs to be 
> rebuild.
> 
OK.  Feel free to upload then.

Cheers,
Julien


signature.asc
Description: Digital signature

Bug#727708: The tech ctte isn't considering OpenRC at all

[Ian Jackson]

Nikolaus Rath writes ("Bug#727708: The tech ctte isn't considering OpenRC at 
all"):
> Ian Jackson  writes:
> > Thomas, does OpenRC provide a means for do non-forking daemon
> > startup ?
> [...]
> 
> Ian, quoting from your previous evaluation of upstart
> (http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=727708#1499):
...
> I don't see how this is consistent with what you say about
> OpenRC. Either the lack of features isn't a problem if they can in
> principle be implemented in the future (in that case, upstart and OpenRC
> are both viable candidates), or hypothetical features do not matter (in
> that case this should also hold for upstart).

Firstly, non-forking daemon startup and supervision is less of a
feature and more of a design decision.  I think that doing it from
scratch in a system which doesn't have it at all involves a lot of
design decisions and a fair amount of programming work.

Secondly, the features I list as missing for upstart are not IMO
anywhere near as important.

If you think OpenRC will soon have non-forking daemon startup, then
excellent.  Can you explain to me how it will work ?

Thanks,
Ian.


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

Bug#727708: On diversity

[Ian Jackson]

Steve Langasek writes ("Bug#727708: On diversity"):
> On Mon, Jan 20, 2014 at 01:17:13AM +1000, Anthony Towns wrote:
> > I think (a) and (b) are pretty non-controversial. (c) and (d) are
> > required if we want to deal with new GNOME stuff and anything other
> > than systemd probably, and don't seem very hard to either do or
> > document. (e), (f) and (g) seem like a fairly straightforward of
> > allowing for multiple init systems in Debian. I think something like
> > (i) might be a good way of sunsetting tech ctte decisions so if
> > there's an actual consensus in future, there's no need to get a
> > pro-forma vote from the ctte to make changes in future. YMMV of
> > course.
> 
> For my part I think this is generally a good idea, but I have the impression
> that at least Russ would be strongly opposed to this because it's too
> prescriptive.  Probably not much sense in fleshing out such a reolution if
> there's not a consensus for it.

I lost track of all these (a)..(i).  But I wouldn't say that it's not
worth fleshing something out just because there's a lack of consensus.
The final resolution is not going to be a consensus decision anyway.

Ian.


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

Bug#734499: gtimelog won't start

[Marius Gedminas]

I replied to this a couple of weeks ago from my Android phone, but I
don't see my message on the BTS, so trying again.

On Tue, Jan 07, 2014 at 05:53:54PM +0100, vojtech wrote:
> Package: gtimelog
> Version: 0.9.1-1
> Severity: grave
> Justification: renders package unusable
> 
> gtimelog does not start. This error message is printed out:
> 
> Traceback (most recent call last):
>   File "/usr/bin/gtimelog", line 5, in 
> from pkg_resources import load_entry_point
> ImportError: No module named 'pkg_resources'

It seems that the package is missing a Depends: python3-setuptools:

> Versions of packages gtimelog depends on:
> ii  gir1.2-appindicator3-0.1  0.4.92-3
> ii  gir1.2-gtk-3.03.8.6-1
> ii  gir1.2-pango-1.0  1.36.0-1+b1
> ii  python3   3.3.2-17
> ii  python3-gi3.10.2-1
> pn  python3:any   

Marius Gedminas
-- 
Those who don't understand Linux are doomed to reinvent it, poorly.


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

Bug#727708: Thoughts on Init System Debate

[Ian Jackson]

Steve Langasek writes ("Bug#727708: Thoughts on Init System Debate"):
> On Fri, Jan 17, 2014 at 08:41:32PM -0800, Don Armstrong wrote:
...
> > I should point out that I have not extensively examined openrc, nor have
> > I taken into account planned features and development in either systemd
> > or upstart which could sway my opinion.
> 
> As you say that planned features or development could sway your opinion: are
> there particular features that you have in mind, here?  For instance,
> correcting upstart's socket-based activation interface is on the upstart
> roadmap in the jessie timeframe.

This is a very good question.

Don, seriously, if there is something I could go and implement or fix
in upstart that would convince you, that would be a lot easier and
more fun than arguing on the internet.

It might also demonstrate how easy it is to work on.  (NB at the time
of writing I have not looked at the upstart code other than to glance
at a couple of screenfuls' worth to estimate the code density when I
did a wc.)

Ian.


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

Bug#735898: pavucontrol segmentation fault

[Vlad Orlov]

Can't reproduce it.

Run dmesg after that and check the last lines of the output for the hints about
the cause of segfault. If it says something about libgtk-3.so then you've 
probably
been hit by a known bug in gtk3-engines-unico [1] and need to change your
GTK+ theme to something not using unico.

If not, posting the relevant lines here won't hurt anyway.

[1] http://bugs.debian.org/706330

Bug#637543: libpam-ldap: pam_template_login not working as documented in manpage

[Hermann Lauer]

Package: libpam-ldap
Version: 184-8.6
Followup-For: Bug #637543

Dear Maintainer,
the patch send in for squeeze is needed to fix this issue also in wheezy.
It was running on squeeze over 2 years and on wheezy 2 weeks now 
without any problems.

Please consider inclusion,
thanks & greetings
  Hermann

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

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

Versions of packages libpam-ldap depends on:
ii  debconf [debconf-2.0]  1.5.49
ii  libc6  2.13-38
ii  libldap-2.4-2  2.4.31-1+nmu2
ii  libpam-runtime 1.1.3-7.1
ii  libpam0g   1.1.3-7.1

libpam-ldap recommends no packages.

Versions of packages libpam-ldap suggests:
ii  libnss-ldap  264-2.5

-- debconf information:
* shared/ldapns/base-dn: dc=example,dc=net
* shared/ldapns/ldap-server: 127.0.0.1
  libpam-ldap/pam_password: crypt
  libpam-ldap/binddn: cn=proxyuser,dc=example,dc=net
* libpam-ldap/rootbinddn: cn=manager,dc=example,dc=net
* libpam-ldap/dbrootlogin: true
* libpam-ldap/override: false
* shared/ldapns/ldap_version: 3
* libpam-ldap/dblogin: false


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

Bug#736153: failed clone should (optionally) remove destination

[Ian Jackson]

Package: dgit
Version: 0.21

zealot:d> dgit clone openrc experimental
openrc File exists at /usr/bin/dgit line 1170.
zealot:d> rm -rf openrc
zealot:d> dgit clone openrc experimental
starting new git history
...

This is annoying.

Ian.


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

Bug#736154: cantata: Information disclosure (no CVE assigned yet)

[Moritz Muehlenhoff]

Package: cantata
Severity: grave
Tags: security
Justification: user security hole

Hi,
the following was reported on oss-security:
https://code.google.com/p/cantata/issues/detail?id=356

Cheers,
Moritz


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

Bug#736155: RM: nvidia-graphics-drivers [armhf] -- ROM; upstream didn't release a 319.82 armhf blob

[Andreas Beckmann]

Package: ftp.debian.org
Severity: normal

Please remove the outdated armhf binaries from nvidia-graphics-drivers
in unstable. Upstream did no 319.82 release for armhf. armhf support is
available in the newer upstream 331.38 in experimental.


Andreas


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

Bug#735630: nvidia-kernel-dkms: fails to work with kernel 3.13

[Adam Borowski]

On Sun, Jan 19, 2014 at 06:13:25PM +0100, Andreas Beckmann wrote:
> On 2014-01-17 05:20, Adam Borowski wrote:
> > Hi!  I'm running a -rc kernel (as 3.12 doesn't work for me due to #730863),
> > and the module builds but fails to insert with the following message:
> > 
> > nvidia: Unknown symbol acpi_os_wait_events_complete (err 0)
> 
> That symbol should be present in your kernel, it is present in the
> packaged 3.13-rc6 in experimental. Check with
> 
>   grep acpi_os_wait_events_complete /boot/System.map-*

/boot/System.map-3.11.0-x32+:8137fa0f T acpi_os_wait_events_complete
/boot/System.map-3.11.0-x32+:81777000 r 
__ksymtab_acpi_os_wait_events_complete
/boot/System.map-3.11.0-x32+:8178caa0 r 
__kcrctab_acpi_os_wait_events_complete
/boot/System.map-3.11.0-x32+:817a5ed4 r 
__kstrtab_acpi_os_wait_events_complete
/boot/System.map-3.13-rc6-amd64:812d7e76 T acpi_os_wait_events_complete
/boot/System.map-3.13.0-rc8-x32+:81386097 T acpi_os_wait_events_complete

So the symbol is there, what might be going wrong...?

> If it is missing, compare the kernel .configs

diff|grep -i acpi
+ CONFIG_ACPI_DEBUG=y
- CONFIG_ACPI_HOTPLUG_MEMORY=y
- a bunch of drivers (Toshiba, Thinkpad, etc)

I'll recompile 3.13.0 with these options, to make sure.

-- 
A tit a day keeps the vet away.


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

Bug#707596: maxima: 1000!^0.01 produces i.nfE+142498684

[Sanjoy Mahajan]

The problem is also present in the latest maxima (5.32.1-1):

$ maxima
Maxima 5.32.1 http://maxima.sourceforge.net
using Lisp GNU Common Lisp (GCL) GCL 2.6.10 (a.k.a. GCL)
...
(%i1) 1000!^0.01;
(%o1)i.nfE+6166368

I am happy to report it upstream.  Actually, I just did:

https://sourceforge.net/p/maxima/bugs/2680/

-Sanjoy


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

Bug#736156: backupninja: Add possibility to ignore failing connection

[Olivier Berger]

Package: backupninja
Version: 1.0.1-2
Severity: wishlist

Hi.

I'd like to have the option to ignore failures to connect, and only report an 
error when the host is there but we couldn't ssh to it.

When the host doesn't resolve, for instance because we're not on the right LAN, 
maybe we could just ignore the backup and not send an error report by mail.

At the moment, I for instance have :
Debug: ssh  -o PasswordAuthentication=no remoteback.local -l backup 'echo -n 1'
ssh: Could not resolve hostname remoteback.local: Name or service not known
Fatal: Can't connect to remoteback.local as backup.

In the case when there's no 'remoteback' system on my LAN (not at home, for 
instance), then it could just ignore the backup.

By default, this wouldn't be enabled, as it is risky if one misconfigures, or 
the mdns won't work, or other issues occur, but would save the mboxes of some 
folks in situations like mine.

Hope this helps.

Best regards,


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

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

Versions of packages backupninja depends on:
ii  bash   4.2+dfsg-1
ii  bsd-mailx [mailx]  8.1.2-0.20131005cvs-1
ii  dialog 1.2-20130928-1
ii  gawk   1:4.0.1+dfsg-2.1
ii  mawk   1.3.3-17

backupninja recommends no packages.

Versions of packages backupninja suggests:
ii  bzip2  1.0.6-5
ii  debconf-utils  1.5.52
ii  duplicity  0.6.22-2
ii  genisoimage9:1.1.11-2
ii  hwinfo 16.0-2.2
pn  mdadm  
ii  rdiff-backup   1.2.8-7
ii  rsync  3.1.0-2
ii  subversion 1.7.14-1+b1
pn  trickle
ii  wodim  9:1.1.11-2

-- debconf-show failed


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

Bug#727708: The tech ctte isn't considering OpenRC at all

[Ian Jackson]

Thomas Goirand writes ("Bug#727708: The tech ctte isn't considering OpenRC at 
all"):
> On 01/19/2014 08:15 PM, Ian Jackson wrote:
> >  * The daemon does not double-fork; it runs in the foreground of
> >of its initial process.
> 
> Something like start-stop-daemon then? :)

Err, no, becase...

> See also the command_background directive (in the man openrc-run).

(http://manpages.debian.net/cgi-bin/man.cgi?query=openrc-run&apropos=0&sektion=0&manpath=Debian+experimental&format=html&locale=en
  => Sorry, no data found for `openrc-run'.
I dgit cloned the package from experimental and used `man -l'.
Perhaps manpages.debian.net isn't working or hasn't updated yet.)

> On 01/19/2014 08:15 PM, Ian Jackson wrote:
> >  * The daemon's parent process (part of the init system) keeps
> >track of it, so the init system knows whether the process
> >is still running.
> 
> First, OpenRC isn't stateless like sysv-rc to begin with (try
> "rc-status" to see what daemon is running). Status are kept in
> /run/openrc/started using symlinks to /etc/init.d, and OpenRC uses
> (optionally) cgroups to shutdown daemons, if that's what you ask.

Having looked at the FM for openrc-run, no, this is not what I meant
by a non-forking daemon startup.

I meant that the long-running process's parent is some kind of
supervisor process which will respond to information about its child's
process lifecycle (using SIGCHLD, waitpid).  (And that the
long-running process inherits, and does not close, a sensible stderr.)

And I don't think cgroups is the right answer.

> Then, the answer to this question is even more definitively "yes", if
> you use this patch:
> https://github.com/qnikst/openrc/compare/s-vision

You're suggesting then to use monit.  Are you saying that all of the
daemons in Debian ought to be converted to run under monit and that
this should be the default mode of operation ?

I just read the monit(1) manpage and saw this:

 | Monit detaches from the console, puts itself in the background and
 | runs continuously, monitoring each specified service and then goes
 | to sleep for the given poll interval, wakes up and start monitoring
 | again in an endless cycle.

This is probably great for a server system monitoring setup.  But it's
not really how an init system has to work.  Also, monit has a lot of
functionality which has nothing to do with init system.

Also I saw this in the section on service entry keywords:

 | pidfile Specify the  process pidfile. Every
 | process must create a pidfile with its
 | current process id. This statement should only
 | be used in a process service entry.

Are you _sure_ monit doesn't expect daemons to fork ?  Why does it
need a pidfile ?

> On 01/19/2014 08:15 PM, Ian Jackson wrote:
> >  * The daemon's stderr goes somewhere reasonable.
> 
> Hum... By default, I honestly don't know what would be the behavior of a
> daemon doing some output to stderr. However, I believe it'd be really
> trivial to do in the command= statement of a runscript. Something like:
> 
> command="foo >/var/log/foo.log 2>&1"
> 
> or using the command_arg directive should be enough (I haven't tested,
> but this seems reasonable).

Oh god, please no more of this kind of thing.  My inittabs are already
full of it and this is what I'm trying to get rid of.

Ian.


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

Bug#733505: CVE-2013-6889: Allows reading arbitrary files

[Sergey Poznyakoff]

Hello,

Thanks for noticing.  The bug is fixed in the rush repository (commit
00bdccd4).

Regards,
Sergey


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

Bug#669348: transition: openjpeg

[Mathieu Malaterre]

On Mon, Jan 20, 2014 at 10:18 AM, Julien Cristau  wrote:
> Control: block -1 with 735847
>
> On Thu, Apr 19, 2012 at 11:47:45 +0200, Mathieu Malaterre wrote:
>
>> Package: release.debian.org
>> Severity: normal
>> User: release.debian@packages.debian.org
>> Usertags: transition
>>
>>
>> I'd like to request a transition slot for openjpeg 1.5. the main reason for 
>> 1.5 is that it fixes JPEG 2000 support in PDF file, see #659226 & #667708
>>
> This is now going to block on #735847 (or on getting rid of freeimage,
> if possible...).

AFAIK openjpeg 1.5.1 does not depends on freeimage anymore to build:

http://packages.debian.org/source/experimental/openjpeg

What exactly is holding openjpeg 1.5.1 transition ?

Thanks,


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

Bug#727708: Thoughts on Init System Debate

[Andres Freund]

On 2014-01-19 23:18:26 -0800, Steve Langasek wrote:
> As you say that planned features or development could sway your opinion: are
> there particular features that you have in mind, here?  For instance,
> correcting upstart's socket-based activation interface is on the upstart
> roadmap in the jessie timeframe.

Showing some progress on issues like
https://bugs.launchpad.net/upstart/+bug/447654 would excite me far much
more than promises about future features. Not fixing issues described as
"a fundamental design flaw" by upstart's original author for several
years, without an inkling of progress, is what's causing doubts about
upstarts health, at least for me.

Greetings,

Andres Freund


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

Bug#735975: Dpkg::Control::Hash: would like more subtle pgp check

[Ian Jackson]

Guillem Jover writes ("Re: Bug#735975: Dpkg::Control::Hash: would like more 
subtle pgp check"):
> Yes, you could rely on this, but there's actually another option, in
> this case you could use Dpkg::Source::Package instead which has a
> is_signed() method since its inception (it only got documented as a
> public interface in 1.16.1, but that interface has never changed).
> The drawback is that your code might need to end up parsing the .dsc
> file twice, but that should not be such a performance issue.

I think I'd prefer to use my idea because I use the same snippet to
parse various different kinds of 822-format files.

> > perl -e 'use Data::Dumper; use Dpkg::Control::Hash; my $h = new
> >  Dpkg::Control::Hash; $h->load("debian/control") or die; my $y =
> >  $h->get_option("is_pgp_signed"); print Dumper($y);'
> 
> BTW, you might want to use instead, something like:
> 
> ,---
> my $dsc = Dpkg::Control->new(type => CTRL_PKG_SRC);
> `---
> 
> which will set a correct name for error messages and similar, and
> field ordering for that type.

I already set the error messages myself.  Field ordering isn't
critical AIUI.  (The files I write out are .dsc and .changes;
everything else is readonly.)

Thanks,
Ian.


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

Bug#736157: fusionforge-plugin-scmgit: forge_run_job gather_scm_stats.php exhibits PHP Notice in GitPlugin.class.php

[Olivier Berger]

Package: fusionforge-plugin-scmgit
Version: 5.2.2+20130802-1
Severity: minor
Tags: upstream

Hi.

I'm getting the following errors reported by the forge_run_job 
gather_scm_stats.php cronjob :

PHP Notice:  Undefined index: mode in 
/usr/share/gforge/plugins/scmgit/common/GitPlugin.class.php on line 556
PHP Notice:  Undefined index: mode in 
/usr/share/gforge/plugins/scmgit/common/GitPlugin.class.php on line 559
PHP Notice:  Undefined index: mode in 
/usr/share/gforge/plugins/scmgit/common/GitPlugin.class.php on line 562

Hth.

Best regards,

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

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


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

Bug#736147: [pkg-php-pear] Bug#736147: phpunit: Needs to be updated to support new php-codecoverage

[Thomas Goirand]

On Mon Jan 20 2014 05:53:33 PM HKT, Roland Mas  wrote:

> Package: phpunit
> Version: 3.6.10-1
> Severity: normal
> 
> phpunit ships /usr/share/php/PHPUnit/Util/GlobalState.php, which has a
> function that calls php_codecoverage_autoload().   This function doesn't
> exist in the current version of php-codecoverage; if it's in another
> package, then there's at least a dependency missing :-)
> 
> In any case, it ends up with my testsuites randomly failing with
> messages like the following:
> 
> 1) CreateProject::testEmptyProject
> PHP Fatal error:   Call to undefined function php_codecoverage_autoload()
> in /usr/share/php/PHPUnit/Util/GlobalState.php on line 380
> 
> Roland.

Without looking (since you aren't even telling what
package we are talking about), and because I've
seen this many times, I'd say it is a pb in your
package which needs to be adapted to newer versions
of PHPUnit.

Thomas (from my phone)


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

Bug#669348: transition: openjpeg

[Julien Cristau]

On Mon, Jan 20, 2014 at 12:59:52 +0100, Mathieu Malaterre wrote:

> On Mon, Jan 20, 2014 at 10:18 AM, Julien Cristau  wrote:
> > Control: block -1 with 735847
> >
> > On Thu, Apr 19, 2012 at 11:47:45 +0200, Mathieu Malaterre wrote:
> >
> >> Package: release.debian.org
> >> Severity: normal
> >> User: release.debian@packages.debian.org
> >> Usertags: transition
> >>
> >>
> >> I'd like to request a transition slot for openjpeg 1.5. the main reason 
> >> for 1.5 is that it fixes JPEG 2000 support in PDF file, see #659226 & 
> >> #667708
> >>
> > This is now going to block on #735847 (or on getting rid of freeimage,
> > if possible...).
> 
> AFAIK openjpeg 1.5.1 does not depends on freeimage anymore to build:
> 
> http://packages.debian.org/source/experimental/openjpeg
> 
> What exactly is holding openjpeg 1.5.1 transition ?
> 
The other way around.  freeimage depends on openjpeg, which means an
openjpeg transition involves getting a new freeimage in to testing,
which is not possible if freeimage in sid is broken.

Cheers,
Julien


signature.asc
Description: Digital signature

Bug#736158: random FTBFS: test_graceful_shutdown_waits_for_clients_to_stop

[Adam Borowski]

Package: src:bzr
Version: 2.6.0-3
Severity: serious
Justification: fails to build from source (but built successfully in the past)


I'm afraid that bzr randomly (7/8 tries) FTBFSes due to a failure of one
test on speedier machines:

==
FAIL: 
bzrlib.tests.test_smart_transport.TestSmartTCPServer.test_graceful_shutdown_waits_for_clients_to_stop
--
_StringException: log: {{{
INFO  Requested to stop gracefully
305.285  Stopping SmartServerSocketStreamMedium(client=('127.0.0.1', 60256))
INFO  Waiting for 1 client(s) to finish
INFO  Requested to stop gracefully
}}}

Traceback (most recent call last):
  File 
"/tmp/buildd/bzr-2.6.0/build/lib.linux-x86_64-2.7/bzrlib/tests/test_smart_transport.py",
 line 1458, in test_graceful_shutdown_waits_for_clients_to_stop
self.assertFalse(server._fully_stopped.isSet())
  File "/usr/lib/python2.7/unittest/case.py", line 418, in assertFalse
raise self.failureException(msg)
AssertionError: True is not false

--

I repeated the build on an armhf box, all 3 tries succeeded.  So did it on
all buildds for first-class architectures, while on the x32 buildd there
were two failures out of two attempts.  It seems that the x32 buildd runs on
a good deal faster machine than i386 and amd64 ones: looking at some random
package, I see 25s:x32 vs 1m50s:i386.  All other architectures are,
unsuprisingly, slower.

So it's some timing issue.  I have a strong hunch it's a bug in the test
suite rather than in the code being tested, so if it's tricky to debug,
disabling that test wouldn't be as bad an idea as papering over test
failures usually is.

(Not sure what's the right severity for "FTBFSes on too fast".  As my home
machines are not so hot, I went with "serious" as hardware only goes faster,
but you probably know better.)


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

Kernel: Linux 3.13.0-rc8-x32+ (SMP w/6 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash


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

Bug#733087: [LCFC] templates://apt-cacher-ng/{apt-cacher-ng.templates}

[Justin B Rye]

Christian PERRIER wrote:
> This is the last call for comments for the review of debconf
> templates for apt-cacher-ng.

Sorry, I somehow missed the RFR for this!  But I remember reading the
package description and seeing nothing I would change there, so for
once I can't blame Gmail.

> Template: apt-cacher-ng/gentargetmode
[...]
>  Apt-Cacher NG can download packages from repositories other than those
>  requested by the clients. This allows it to cache content effectively,
>  and makes it easy for an administrator to switch to another mirror later.
>  .
>  This remapping of URLs can be configured now in an automated way based on the
>  current state of /etc/apt/sources.list. Optionally, this process can be
>  repeated on every package update (modifying the configuration files each
>  time).
>  .
>  Selecting "No automated setup" will leave the existing configuration
>  unchanged. It will need to be updated manually.
 
The confusing part is that this tells the admin about two lots of
things AC-NG "can" do without making it immediately obvious that we're
asking for input on whether it should do the _second_ thing.  It's not:

   Please specify whether Apt-Cacher NG should download packages [...]

It's:

   Apt-Cacher NG can download packages [...]
   .
   Please specify whether this remapping of URLs should be configured [...]

But that approach gives a badly overstretched sentence in the second
paragraph.  How about splitting it slightly differently:

   Apt-Cacher NG can download packages from repositories other than those
   requested by the clients. This allows it to cache content effectively,
   and makes it easy for an administrator to switch to another mirror later.
   The URL remapping can be set up automatically, using a configuration
   based on the current state of /etc/apt/sources.list.
   .
   Please specify whether the remapping should be configured once now, or
   reconfigured on every update of Apt-Cacher NG (modifying the
   configuration files each time), or left unconfigured.
   .
   Selecting "No automated setup" will leave the existing configuration
   unchanged. It will need to be updated manually.

> Template: apt-cacher-ng/bindaddress
> Type: string
> Default: keep
> _Description: Address(es) for apt-cacher-ng to listen to:

Wait, it doesn't listen *to* these addresses.  They're local network
interfaces that it listens *on*.  And shouldn't it be "Apt-Cacher NG"?

Perhaps to match the following prompt:
   _Description: Listening address(es) for Apt-Cacher-NG:

>  Please enter the addresses or hostnames which should be used by
>  apt-cacher-ng (multiple entries must be separated by spaces).

Make that

   Please specify the local addresses that Apt-Cacher NG should listen on
   (multiple entries must be separated by spaces).

>  .
>  Each entry must be an exact address (IP or hostname) which is
>  associated with a local network interface. Generic protocol specific 
> addresses
>  are supported, such as 0.0.0.0 for listening on all IPv4 enabled interfaces.

I don't like "an exact address (IP or hostname)" - for a start, how
would an interface's IP address be anything but "exact"?  Asking for
an "exact" hostname sounds as if it wants the FQDN.  And it turns out
that it's happy to accept 0.0.0.0, which hardly seems very "exact".

Besides which, there's no such thing as an IP.  Just say:

   Each entry must be an IP address or hostname associated with a local
   network interface. Generic protocol-specific addresses are also
   supported, such as 0.0.0.0 for listening on all IPv4-enabled interfaces.

(Note added hyphens.)

>  .
>  If this field is left empty, apt-cacher-ng wille listen on all
>  interfaces, with all supported protocols.

Typo.

>  .
>  The special word "keep" keeps the value from the current (or default)
>  configuration unchanged.
> 
> Template: apt-cacher-ng/port
> Type: string
> Default: keep
> _Description: Listening TCP port:
>  Please configure the TCP port where Apt-Cacher NG should listen for incoming 
> HTTP
>  (proxy) requests. The default value is port 3142, and it can be set to  
> to emulate
>  apt-proxy.

I don't like the "where".  Or the "and".

   Please specify the TCP port that Apt-Cacher NG should listen on for
   incoming HTTP (proxy) requests. The default value is port 3142, but it
   can be set to  to emulate apt-proxy.

>  .
>  If left empty, the value from the current configuration remains unchanged.

Make that "If this field is left empty" again.
 
> Template: apt-cacher-ng/cachedir
> Type: string
> Default: keep
> _Description: Top level directory for packages cache:
   ^
I probably wouldn't add plural marking in this noun stack.  And while
I'm here I'll add a hyphen to "top-level". 

>  The main cache storage directory should be located on a file system without
>  file name restrictions.

No "Please specify"?  Well, it makes a change, I suppose.

(A file with a name consisting of a billion null

Bug#736157: fusionforge-plugin-scmgit: forge_run_job gather_scm_stats.php exhibits PHP Notice in GitPlugin.class.php

[Olivier Berger]

Control: tags -1 + patch

Olivier Berger  writes:

>
> I'm getting the following errors reported by the forge_run_job 
> gather_scm_stats.php cronjob :
>
> PHP Notice:  Undefined index: mode in 
> /usr/share/gforge/plugins/scmgit/common/GitPlugin.class.php on line 556
> PHP Notice:  Undefined index: mode in 
> /usr/share/gforge/plugins/scmgit/common/GitPlugin.class.php on line 559
> PHP Notice:  Undefined index: mode in 
> /usr/share/gforge/plugins/scmgit/common/GitPlugin.class.php on line 562
>

Obviously, the following patch gets rid of the problem, even though this may be 
a
symptom of something nastier (haven't checked what this is supposed to
do exactly) :

root@fusionforge:/usr/share/gforge/plugins/scmgit/common# diff -u 
GitPlugin.class.php.orig GitPlugin.class.php
--- GitPlugin.class.php.orig2014-01-20 13:11:57.0 +0100
+++ GitPlugin.class.php 2014-01-20 13:14:04.0 +0100
@@ -553,14 +553,16 @@
if (!isset 
($usr_adds[$last_user])) $usr_adds[$last_user] = 0;
if (!isset 
($usr_updates[$last_user])) $usr_updates[$last_user] = 0;
if (!isset 
($usr_deletes[$last_user])) $usr_deletes[$last_user] = 0;
-   if ($matches['mode'] == 'A') {
+   if( isset($matches['mode']) ) {
+   if ($matches['mode'] == 
'A') {
$usr_adds[$last_user]++;
$adds++;
-   } elseif ($matches['mode'] == 
'M') {
+   } elseif ($matches['mode'] 
== 'M') {

$usr_updates[$last_user]++;
$updates++;
-   } elseif ($matches['mode'] == 
'D') {
+   } elseif ($matches['mode'] 
== 'D') {

$usr_deletes[$last_user]++;
+   }
}
}
}

Hope this helps.

Best regards,
-- 
Olivier BERGER 
http://www-public.telecom-sudparis.eu/~berger_o/ - OpenPGP-Id: 2048R/5819D7E8
Ingenieur Recherche - Dept INF
Institut Mines-Telecom, Telecom SudParis, Evry (France)


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

Bug#735932: [grub2-common] Computer does not boot

[Bernhard Schmidt]

Hi,

I have the same problem, which is a symptom of #724756. Unfortunately it is 
quite hard to recover from that, especially when the system is remote.

Bernhard

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

Bug#735927: general: X *always* crashes when ram is full

[Kevin Chadwick]

previously on this list Roger Leigh contributed:

> With an SSD, you really
> don't want /tmp or swap on it;

Why?, due to limited write cycles?

As long as it is a modern SSD (years) or one of the old ones one with a
sandforce controller (OpenBSD dev let me know about that) then it has a
good 20% extra space above it's listed gigabytes reserved unusable for
wear levelling meaning this is a non issue even when full?

Unless he's worried about not being able to wipe the swap?

-- 
___

'Write programs that do one thing and do it well. Write programs to work
together. Write programs to handle text streams, because that is a
universal interface'

(Doug McIlroy)

In Other Words - Don't design like polkit or systemd
___


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

Bug#732956: [debian-reference-en] "The apt-get and apt-cache commands are the most basic package management tool."

[Osamu Aoki]

Hi,


As for your comment on ":", YES.  It is a productive comment and I thank
you for that.  It is fixed.

On Sun, Jan 19, 2014 at 12:13:04PM -0500, Filipus Klutiero wrote:
> On 2014-01-19 11:34, Osamu Aoki wrote:
> It depends on what exactly the problem is.
...

Problem should affects not just unstable but other situations
(stable-to-stable, testing) as I know.  I do not care if this is
reported or no.  I do not know why you are still asking without doing
your homework.  Please check it yourself.

This is general guide so I should not describe too much in detail.
There is space for my editorial choice.

Quite frankly, I am not comfortable with the way BTS is going with
non-productive statements.  This BTS is not a free tutoring session or
debating platform.  This is volunteer work and we expect your
contribution with good efforts.  Let's stop it here.

Regards,

Osamu

PS: Just like Emacs vs. Vi, we can not describe something impartially as
Debian.  Then the right thing is to state it clearly identifying with
the author.


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

Bug#735424: nvidia-driver: Test with minimal NVIDIA xorg.conf

[Karsten]

Package: nvidia-driver
Version: 319.76-1
Followup-For: Bug #735424

Thank you for your help and your suggestions!
The first test is to boot with the suggested minimal xorg.conf for NVidia.
Result is a text console after boot!
I logged in as user and startx - result is the blank screen.

I opened a second text console and send this message with reportbug -N,
Following up with the next test (vesa).

Karsten


-- Package-specific info:
uname -a:
Linux PC10 3.12-1-amd64 #1 SMP Debian 3.12.6-2 (2013-12-29) x86_64 GNU/Linux

/proc/version:
Linux version 3.12-1-amd64 (debian-ker...@lists.debian.org) (gcc version 4.8.2 
(Debian 4.8.2-10) ) #1 SMP Debian 3.12.6-2 (2013-12-29)

/proc/driver/nvidia/version:
NVRM version: NVIDIA UNIX x86_64 Kernel Module  319.76  Fri Nov 22 13:33:19 PST 
2013
GCC version:  gcc version 4.8.2 (Debian 4.8.2-12) 

lspci 'VGA compatible controller [0300]':
02:00.0 VGA compatible controller [0300]: NVIDIA Corporation GF108 [GeForce GT 
430] [10de:0de1] (rev a1) (prog-if 00 [VGA controller])
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B- DisINTx-
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- 
Kernel driver in use: nvidia

dmesg:
[0.00] No AGP bridge found
[0.00] No AGP bridge found
[0.00] Console: colour VGA+ 80x25
[0.382826] vgaarb: device added: 
PCI::02:00.0,decodes=io+mem,owns=io+mem,locks=none
[0.382828] vgaarb: loaded
[0.382829] vgaarb: bridge control possible :02:00.0
[1.067815] PCI-DMA: Disabling AGP.
[1.067899] PCI-DMA: Reserving 64MB of IOMMU area in the AGP aperture
[1.147011] Linux agpgart interface v0.103
[5.275911] hda-intel :02:00.1: Handle VGA-switcheroo audio client
[5.516103] nvidia: module license 'NVIDIA' taints kernel.
[6.139085] input: HDA NVidia HDMI/DP,pcm=9 as 
/devices/pci:00/:00:02.0/:02:00.1/sound/card1/input16
[6.139285] input: HDA NVidia HDMI/DP,pcm=8 as 
/devices/pci:00/:00:02.0/:02:00.1/sound/card1/input15
[6.139439] input: HDA NVidia HDMI/DP,pcm=7 as 
/devices/pci:00/:00:02.0/:02:00.1/sound/card1/input14
[6.139582] input: HDA NVidia HDMI/DP,pcm=3 as 
/devices/pci:00/:00:02.0/:02:00.1/sound/card1/input13
[6.141016] vgaarb: device changed decodes: 
PCI::02:00.0,olddecodes=io+mem,decodes=none:owns=none
[6.142218] NVRM: loading NVIDIA UNIX x86_64 Kernel Module  319.76  Fri Nov 
22 13:33:19 PST 2013

OpenGL and NVIDIA library files installed:
lrwxrwxrwx 1 root root   15 Jan 14 11:03 /etc/alternatives/glx -> 
/usr/lib/nvidia
lrwxrwxrwx 1 root root   41 Jan 14 11:03 
/etc/alternatives/glx--libGL.so.1-i386-linux-gnu -> 
/usr/lib/i386-linux-gnu/nvidia/libGL.so.1
lrwxrwxrwx 1 root root   41 Jan 14 11:03 
/etc/alternatives/glx--libGL.so.1-i386-linux-gnu -> 
/usr/lib/i386-linux-gnu/nvidia/libGL.so.1
lrwxrwxrwx 1 root root   43 Jan 14 11:03 
/etc/alternatives/glx--libGL.so.1-x86_64-linux-gnu -> 
/usr/lib/x86_64-linux-gnu/nvidia/libGL.so.1
lrwxrwxrwx 1 root root   43 Jan 14 11:03 
/etc/alternatives/glx--libGL.so.1-x86_64-linux-gnu -> 
/usr/lib/x86_64-linux-gnu/nvidia/libGL.so.1
lrwxrwxrwx 1 root root   49 Jan 14 11:03 
/etc/alternatives/glx--libnvidia-cfg.so.1-i386-linux-gnu -> 
/usr/lib/i386-linux-gnu/nvidia/libnvidia-cfg.so.1
lrwxrwxrwx 1 root root   51 Jan 14 11:03 
/etc/alternatives/glx--libnvidia-cfg.so.1-x86_64-linux-gnu -> 
/usr/lib/x86_64-linux-gnu/nvidia/libnvidia-cfg.so.1
lrwxrwxrwx 1 root root   25 Jan 14 11:03 
/etc/alternatives/glx--linux-libglx.so -> /usr/lib/nvidia/libglx.so
lrwxrwxrwx 1 root root   42 Jan 14 11:03 
/etc/alternatives/glx--nvidia-blacklists-nouveau.conf -> 
/etc/nvidia/nvidia-blacklists-nouveau.conf
lrwxrwxrwx 1 root root   36 Jan 14 11:03 
/etc/alternatives/glx--nvidia-bug-report.sh -> 
/usr/lib/nvidia/nvidia-bug-report.sh
lrwxrwxrwx 1 root root   29 Jan 14 11:03 
/etc/alternatives/glx--nvidia_drv.so -> /usr/lib/nvidia/nvidia_drv.so
lrwxrwxrwx 1 root root   23 Jan 14 11:03 /etc/alternatives/nvidia -> 
/usr/lib/nvidia/current
lrwxrwxrwx 1 root root   49 Jan 14 11:03 
/etc/alternatives/nvidia--libGL.so.1-i386-linux-gnu -> 
/usr/lib/i386-linux-gnu/nvidia/current/libGL.so.1
lrwxrwxrwx 1 root root   49 Jan 14 11:03 
/etc/alternatives/nvidia--libGL.so.1-i386-linux-gnu -> 
/usr/lib/i386-linux-gnu/nvidia/current/libGL.so.1
lrwxrwxrwx 1 root root   51 Jan 14 11:03 
/etc/alternatives/nvidia--libGL.so.1-x86_64-linux-gnu -> 
/usr/lib/x86_64-linux-gnu/nvidia/current/libGL.so.1
lrwxrwxrwx 1 root root   51 Jan 14 11:03 
/etc/alternatives/nvidia--libGL.so.1-x86_64-linux-gnu -> 
/usr/lib/x86_64-linux-gnu/nvidia/current/libGL.so.1
lrwxrwxrwx 1 root root   33 Jan 14 11:03 
/etc/alternatives/nvidia--libglx.so -> /usr/lib/nvidia/current/libglx.so
lrwxrwxrwx 1 root root   57 Jan 14 11:03 
/etc/alternatives/nvidia--libnvidia-cfg.so.1-i386-linux-gnu -> 
/usr/li

Bug#718805: Re: Bug#718805: /usr/bin/avconv: avconv cannot grab video4linux2 device

[Nikolay Shaplov]

On Sunday 19 January 2014 11:24:57 Reinhard Tartler wrote:

> Also, if this still persists, please also check the avconv binary
> I''ve uploaded yesterday to debian/experimental. It is pretty close to
> current libav/master right now.

I've built current experemental package on my computer and installed it: 
Camera works well with it.


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

Bug#717862: dma package leaves behind /etc/mailname after purge

[Brian Potkin]

On Thu 25 Jul 2013 at 11:05:41 -0700, Forest wrote:

> The dma package creates an /etc/mailname file during install, but does not
> register it as belonging to the package, and does not remove it when the
> package is purged.  Nobody likes packages that leave behind junk like this,
> and I'm pretty sure it violates Debian policy.

I'm pretty sure it would violate Debian policy for a purge of dma to
remove /etc/mailname.

   
http://www.debian.org/doc/debian-policy/ch-customized-programs.html#s-mail-transport-agents

#400292 contains a similar request.

   http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=400292

The response was:

  That is because /etc/mailname is a shared configuration file. Multiple
  installed programs are using it, removing just *one* of them (exim)
  must not break the others.

and

  I do not think exim should ever remove this file. The actual breakage
  you encontered needs to be fixed in a different way.
  cu and- I would suggest closing this bug on the basis of
  policy 11.6 -reas

Regards,

Brian.


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

Bug#735424: nvidia-driver: Test with vesa xorg.conf

[Karsten]

Package: nvidia-driver
Version: 319.76-1
Followup-For: Bug #735424

This time i booted with the suggested xorg.conf with vesa.
Result is the same.
I land on the text console
After login and startx i got "no screens found"
Trying now to install driver from unstable ...

Karsten

-- Package-specific info:
uname -a:
Linux PC10 3.12-1-amd64 #1 SMP Debian 3.12.6-2 (2013-12-29) x86_64 GNU/Linux

/proc/version:
Linux version 3.12-1-amd64 (debian-ker...@lists.debian.org) (gcc version 4.8.2 
(Debian 4.8.2-10) ) #1 SMP Debian 3.12.6-2 (2013-12-29)

/proc/driver/nvidia/version:
NVRM version: NVIDIA UNIX x86_64 Kernel Module  319.76  Fri Nov 22 13:33:19 PST 
2013
GCC version:  gcc version 4.8.2 (Debian 4.8.2-12) 

lspci 'VGA compatible controller [0300]':
02:00.0 VGA compatible controller [0300]: NVIDIA Corporation GF108 [GeForce GT 
430] [10de:0de1] (rev a1) (prog-if 00 [VGA controller])
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B- DisINTx-
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- 
Kernel driver in use: nvidia

dmesg:
[0.00] No AGP bridge found
[0.00] No AGP bridge found
[0.00] Console: colour VGA+ 80x25
[0.386397] vgaarb: device added: 
PCI::02:00.0,decodes=io+mem,owns=io+mem,locks=none
[0.386399] vgaarb: loaded
[0.386400] vgaarb: bridge control possible :02:00.0
[1.070997] PCI-DMA: Disabling AGP.
[1.071086] PCI-DMA: Reserving 64MB of IOMMU area in the AGP aperture
[1.150122] Linux agpgart interface v0.103
[7.159490] nvidia: module license 'NVIDIA' taints kernel.
[7.175092] vgaarb: device changed decodes: 
PCI::02:00.0,olddecodes=io+mem,decodes=none:owns=none
[7.175347] NVRM: loading NVIDIA UNIX x86_64 Kernel Module  319.76  Fri Nov 
22 13:33:19 PST 2013
[7.267428] hda-intel :02:00.1: Handle VGA-switcheroo audio client
[8.074148] input: HDA NVidia HDMI/DP,pcm=9 as 
/devices/pci:00/:00:02.0/:02:00.1/sound/card1/input16
[8.074343] input: HDA NVidia HDMI/DP,pcm=8 as 
/devices/pci:00/:00:02.0/:02:00.1/sound/card1/input15
[8.074488] input: HDA NVidia HDMI/DP,pcm=7 as 
/devices/pci:00/:00:02.0/:02:00.1/sound/card1/input14
[8.074630] input: HDA NVidia HDMI/DP,pcm=3 as 
/devices/pci:00/:00:02.0/:02:00.1/sound/card1/input13

OpenGL and NVIDIA library files installed:
lrwxrwxrwx 1 root root   15 Jan 14 11:03 /etc/alternatives/glx -> 
/usr/lib/nvidia
lrwxrwxrwx 1 root root   41 Jan 14 11:03 
/etc/alternatives/glx--libGL.so.1-i386-linux-gnu -> 
/usr/lib/i386-linux-gnu/nvidia/libGL.so.1
lrwxrwxrwx 1 root root   41 Jan 14 11:03 
/etc/alternatives/glx--libGL.so.1-i386-linux-gnu -> 
/usr/lib/i386-linux-gnu/nvidia/libGL.so.1
lrwxrwxrwx 1 root root   43 Jan 14 11:03 
/etc/alternatives/glx--libGL.so.1-x86_64-linux-gnu -> 
/usr/lib/x86_64-linux-gnu/nvidia/libGL.so.1
lrwxrwxrwx 1 root root   43 Jan 14 11:03 
/etc/alternatives/glx--libGL.so.1-x86_64-linux-gnu -> 
/usr/lib/x86_64-linux-gnu/nvidia/libGL.so.1
lrwxrwxrwx 1 root root   49 Jan 14 11:03 
/etc/alternatives/glx--libnvidia-cfg.so.1-i386-linux-gnu -> 
/usr/lib/i386-linux-gnu/nvidia/libnvidia-cfg.so.1
lrwxrwxrwx 1 root root   51 Jan 14 11:03 
/etc/alternatives/glx--libnvidia-cfg.so.1-x86_64-linux-gnu -> 
/usr/lib/x86_64-linux-gnu/nvidia/libnvidia-cfg.so.1
lrwxrwxrwx 1 root root   25 Jan 14 11:03 
/etc/alternatives/glx--linux-libglx.so -> /usr/lib/nvidia/libglx.so
lrwxrwxrwx 1 root root   42 Jan 14 11:03 
/etc/alternatives/glx--nvidia-blacklists-nouveau.conf -> 
/etc/nvidia/nvidia-blacklists-nouveau.conf
lrwxrwxrwx 1 root root   36 Jan 14 11:03 
/etc/alternatives/glx--nvidia-bug-report.sh -> 
/usr/lib/nvidia/nvidia-bug-report.sh
lrwxrwxrwx 1 root root   29 Jan 14 11:03 
/etc/alternatives/glx--nvidia_drv.so -> /usr/lib/nvidia/nvidia_drv.so
lrwxrwxrwx 1 root root   23 Jan 14 11:03 /etc/alternatives/nvidia -> 
/usr/lib/nvidia/current
lrwxrwxrwx 1 root root   49 Jan 14 11:03 
/etc/alternatives/nvidia--libGL.so.1-i386-linux-gnu -> 
/usr/lib/i386-linux-gnu/nvidia/current/libGL.so.1
lrwxrwxrwx 1 root root   49 Jan 14 11:03 
/etc/alternatives/nvidia--libGL.so.1-i386-linux-gnu -> 
/usr/lib/i386-linux-gnu/nvidia/current/libGL.so.1
lrwxrwxrwx 1 root root   51 Jan 14 11:03 
/etc/alternatives/nvidia--libGL.so.1-x86_64-linux-gnu -> 
/usr/lib/x86_64-linux-gnu/nvidia/current/libGL.so.1
lrwxrwxrwx 1 root root   51 Jan 14 11:03 
/etc/alternatives/nvidia--libGL.so.1-x86_64-linux-gnu -> 
/usr/lib/x86_64-linux-gnu/nvidia/current/libGL.so.1
lrwxrwxrwx 1 root root   33 Jan 14 11:03 
/etc/alternatives/nvidia--libglx.so -> /usr/lib/nvidia/current/libglx.so
lrwxrwxrwx 1 root root   57 Jan 14 11:03 
/etc/alternatives/nvidia--libnvidia-cfg.so.1-i386-linux-gnu -> 
/usr/lib/i386-linux-gnu/nvidia/current/libnvidia-cfg.so.1
lrwxrwxrwx 1 root root   59 Jan 14 11:03 
/etc/alternatives/nvidia--libnvidia

Bug#731447: Fwd: mupdf (was: xpdf removed from testing?)

[Mathieu Malaterre]

Control: block -1 719351


-- Forwarded message --
From: Sebastian Ramacher 
Date: Mon, Jan 20, 2014 at 1:35 PM
Subject: Re: mupdf (was: xpdf removed from testing?)
To: debian-de...@lists.debian.org


On 2014-01-20 12:54:30, Mathieu Malaterre wrote:
> On Mon, Jan 20, 2014 at 4:34 AM, Jens Oliver John  wrote:
> >> $ apt-cache show mupdf
> >> MuPDF is a lightweight PDF viewer and toolkit written in portable C.
> >> (...)
> >
> > The mupdf PDF reader is supposed to be minimal and makes on me the 
> > impression of
> > being more a reference implementation using the mupdf library.
> >
> > A more featureful but still light PDF reader, which is able to utilize 
> > mupdf as
> > the rendering backend, is zathura (in Debian) with the mupdf rendering 
> > backend
> > (not in Debian [1]).
> >
> > The zathura upstream is very lively and is constantly gaining features.
> >
> > It may be my personal perception, but the fidelity of the PDF rendering in 
> > mupdf
> > is *vastly* superior to xpdf and all the PDF readers (evince, okular ...) 
> > which
> > use libpoppler at this point, resulting in mupdf/libmupdf being AFIK the 
> > only
> > native and free PDF reader available for Linux with a rendering engine that 
> > can
> > rival the proprietary ones like acrobat (in quality, not feature parity).
> >
> > I therefore suggest packaging zathura with the zathura-pdf-mupdf plugin.
>
> aka #731447

This is blocked by a proper fix for #617253. Ideally, mupdf would start
to provide a shared library (#719351) and commit to a somewhat stable
API. mupdf needs to get in a better shape before zathura-pdf-mupdf can
be packaged.

Regards
--
Sebastian Ramacher


signature.asc
Description: PGP signature

Bug#735424: nvidia-driver: Test of unstable driver

[Karsten]

Package: nvidia-driver
Version: 319.82-1
Followup-For: Bug #735424

Now i installed the driver of the unstable package.
I put the minimum xorg.conf for NVidia into /etc/X11 and tried startx as user.
It says "no screens found"

Now i rerun the xorg configuration tool and try to reboot ...

Karsten

-- Package-specific info:
uname -a:
Linux PC10 3.12-1-amd64 #1 SMP Debian 3.12.6-2 (2013-12-29) x86_64 GNU/Linux

/proc/version:
Linux version 3.12-1-amd64 (debian-ker...@lists.debian.org) (gcc version 4.8.2 
(Debian 4.8.2-10) ) #1 SMP Debian 3.12.6-2 (2013-12-29)

/proc/driver/nvidia/version:
NVRM version: NVIDIA UNIX x86_64 Kernel Module  319.76  Fri Nov 22 13:33:19 PST 
2013
GCC version:  gcc version 4.8.2 (Debian 4.8.2-12) 

lspci 'VGA compatible controller [0300]':
02:00.0 VGA compatible controller [0300]: NVIDIA Corporation GF108 [GeForce GT 
430] [10de:0de1] (rev a1) (prog-if 00 [VGA controller])
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B- DisINTx-
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- 
Kernel driver in use: nvidia

dmesg:
[0.00] No AGP bridge found
[0.00] No AGP bridge found
[0.00] Console: colour VGA+ 80x25
[0.386397] vgaarb: device added: 
PCI::02:00.0,decodes=io+mem,owns=io+mem,locks=none
[0.386399] vgaarb: loaded
[0.386400] vgaarb: bridge control possible :02:00.0
[1.070997] PCI-DMA: Disabling AGP.
[1.071086] PCI-DMA: Reserving 64MB of IOMMU area in the AGP aperture
[1.150122] Linux agpgart interface v0.103
[7.159490] nvidia: module license 'NVIDIA' taints kernel.
[7.175092] vgaarb: device changed decodes: 
PCI::02:00.0,olddecodes=io+mem,decodes=none:owns=none
[7.175347] NVRM: loading NVIDIA UNIX x86_64 Kernel Module  319.76  Fri Nov 
22 13:33:19 PST 2013
[7.267428] hda-intel :02:00.1: Handle VGA-switcheroo audio client
[8.074148] input: HDA NVidia HDMI/DP,pcm=9 as 
/devices/pci:00/:00:02.0/:02:00.1/sound/card1/input16
[8.074343] input: HDA NVidia HDMI/DP,pcm=8 as 
/devices/pci:00/:00:02.0/:02:00.1/sound/card1/input15
[8.074488] input: HDA NVidia HDMI/DP,pcm=7 as 
/devices/pci:00/:00:02.0/:02:00.1/sound/card1/input14
[8.074630] input: HDA NVidia HDMI/DP,pcm=3 as 
/devices/pci:00/:00:02.0/:02:00.1/sound/card1/input13
[  455.350352] NVRM: API mismatch: the client has the version 319.82, but
[  455.350352] NVRM: this kernel module has the version 319.76.  Please
[  455.350352] NVRM: make sure that this kernel module and all NVIDIA driver
[  455.350352] NVRM: components have the same version.

OpenGL and NVIDIA library files installed:
lrwxrwxrwx 1 root root   15 Jan 20 13:50 /etc/alternatives/glx -> 
/usr/lib/nvidia
lrwxrwxrwx 1 root root   41 Jan 20 13:50 
/etc/alternatives/glx--libGL.so.1-i386-linux-gnu -> 
/usr/lib/i386-linux-gnu/nvidia/libGL.so.1
lrwxrwxrwx 1 root root   41 Jan 20 13:50 
/etc/alternatives/glx--libGL.so.1-i386-linux-gnu -> 
/usr/lib/i386-linux-gnu/nvidia/libGL.so.1
lrwxrwxrwx 1 root root   43 Jan 20 13:50 
/etc/alternatives/glx--libGL.so.1-x86_64-linux-gnu -> 
/usr/lib/x86_64-linux-gnu/nvidia/libGL.so.1
lrwxrwxrwx 1 root root   43 Jan 20 13:50 
/etc/alternatives/glx--libGL.so.1-x86_64-linux-gnu -> 
/usr/lib/x86_64-linux-gnu/nvidia/libGL.so.1
lrwxrwxrwx 1 root root   49 Jan 20 13:50 
/etc/alternatives/glx--libnvidia-cfg.so.1-i386-linux-gnu -> 
/usr/lib/i386-linux-gnu/nvidia/libnvidia-cfg.so.1
lrwxrwxrwx 1 root root   51 Jan 20 13:50 
/etc/alternatives/glx--libnvidia-cfg.so.1-x86_64-linux-gnu -> 
/usr/lib/x86_64-linux-gnu/nvidia/libnvidia-cfg.so.1
lrwxrwxrwx 1 root root   25 Jan 20 13:50 
/etc/alternatives/glx--linux-libglx.so -> /usr/lib/nvidia/libglx.so
lrwxrwxrwx 1 root root   42 Jan 20 13:50 
/etc/alternatives/glx--nvidia-blacklists-nouveau.conf -> 
/etc/nvidia/nvidia-blacklists-nouveau.conf
lrwxrwxrwx 1 root root   36 Jan 20 13:50 
/etc/alternatives/glx--nvidia-bug-report.sh -> 
/usr/lib/nvidia/nvidia-bug-report.sh
lrwxrwxrwx 1 root root   29 Jan 20 13:50 
/etc/alternatives/glx--nvidia_drv.so -> /usr/lib/nvidia/nvidia_drv.so
lrwxrwxrwx 1 root root   23 Jan 20 13:50 /etc/alternatives/nvidia -> 
/usr/lib/nvidia/current
lrwxrwxrwx 1 root root   49 Jan 20 13:50 
/etc/alternatives/nvidia--libGL.so.1-i386-linux-gnu -> 
/usr/lib/i386-linux-gnu/nvidia/current/libGL.so.1
lrwxrwxrwx 1 root root   49 Jan 20 13:50 
/etc/alternatives/nvidia--libGL.so.1-i386-linux-gnu -> 
/usr/lib/i386-linux-gnu/nvidia/current/libGL.so.1
lrwxrwxrwx 1 root root   51 Jan 20 13:50 
/etc/alternatives/nvidia--libGL.so.1-x86_64-linux-gnu -> 
/usr/lib/x86_64-linux-gnu/nvidia/current/libGL.so.1
lrwxrwxrwx 1 root root   51 Jan 20 13:50 
/etc/alternatives/nvidia--libGL.so.1-x86_64-linux-gnu -> 
/usr/lib/x86_64-linux-gnu/nvidia/current/libGL.so.1
lrwxrwxrwx 1 root root   33 Jan 20 13:50 
/etc/alternatives/nvidia

Bug#731956: RFH: logcheck

[Jonathan Wiltshire]

X-I-am-subscribed: no
X-CC-me-please: yes

On 11/12/13 15:55, Sylvestre Ledru wrote:
> I am tagging logcheck as RFH because it seems that it could
> need some love.
> The PTS says:
> The BTS contains patches fixing 36 bugs, consider including or untagging 
> them. 
> 
> And no upload has been done for the last year and half.

My employer will sponsor[1] a mini-BSP/sprint targetting logcheck and
related packages (e.g. those which ship or should ship logcheck snippets).

Monday 27th January 2014 14:00-17:00 UTC

You're welcome to join us virtually:
http://wiki.debian.org/BSP/2014/01/gb/Monmouth

1: my time and that of my colleagues, that is; nothing material

-- 
Jonathan Wiltshire
Tiger Computing Ltd
"Linux for Business"

Tel: 01600 483 484
Web: http://www.tiger-computing.co.uk
Follow us on Facebook: http://www.facebook.com/TigerComputing

Registered in England. Company number: 3389961
Registered address: Wyastone Business Park,
 Wyastone Leys, Monmouth, NP25 3SR


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

Bug#735630: nvidia-kernel-dkms: fails to work with kernel 3.13

[Adam Borowski]

On Mon, Jan 20, 2014 at 12:46:02PM +0100, Adam Borowski wrote:
> On Sun, Jan 19, 2014 at 06:13:25PM +0100, Andreas Beckmann wrote:
> > If it is missing, compare the kernel .configs
> 
> diff|grep -i acpi
> + CONFIG_ACPI_DEBUG=y
> - CONFIG_ACPI_HOTPLUG_MEMORY=y
> - a bunch of drivers (Toshiba, Thinkpad, etc)
> 
> I'll recompile 3.13.0 with these options, to make sure.

Now this is interesting... I tried vanilla 3.13.0 with exact Debian's
config, and it fails without the patch (and works with it).

So what else differs from kernels that you say work for you unpatched?
* Debian patches vs vanilla Linus' tree
* build scheme (external kbuild vs make-kpkg)

My exact invocation was:
make-kpkg --rootcmd fakeroot --initrd linux-image linux-headers
in a pristine Linus' 3.13.0 tree from git, with config copied from the
package from experimental.

The linux-kbuild-3.13 is missing, and procuring it myself would require a
long ritual which I've forgotten, so I haven't checked the experimental
package myself.

-- 
A tit a day keeps the vet away.


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

Bug#735424: nvidia-driver: Test of unstable driver

[Karsten Malcher]

Hello,

i am sorry, at least nothing has worked.
With the driver from unstable i get no running X.

All the configurations of xorg.conf i testes result in "no screens found".
I attach the last configuration.
The first one was the minimal configuration.file:///sda/etc/X11/xorg.conf

What is to do now?

Regards
Karsten
# nvidia-xconfig: X configuration file generated by nvidia-xconfig
# nvidia-xconfig:  version 319.72  (pbuilder@cake)  Sat Nov  9 14:15:48 UTC 2013


Section "ServerLayout"
Identifier "Layout0"
Screen  0  "Screen0" 0 0
InputDevice"Keyboard0" "CoreKeyboard"
InputDevice"Mouse0" "CorePointer"
EndSection

Section "Files"
EndSection

Section "InputDevice"

# generated from default
Identifier "Mouse0"
Driver "mouse"
Option "Protocol" "auto"
Option "Device" "/dev/psaux"
Option "Emulate3Buttons" "no"
Option "ZAxisMapping" "4 5"
EndSection

Section "InputDevice"

# generated from default
Identifier "Keyboard0"
Driver "kbd"
EndSection

Section "Monitor"
Identifier "Monitor0"
VendorName "Unknown"
ModelName  "Unknown"
HorizSync   28.0 - 33.0
VertRefresh 43.0 - 72.0
Option "DPMS"
EndSection

Section "Device"
Identifier "Device0"
Driver "nvidia"
VendorName "NVIDIA Corporation"
EndSection

Section "Screen"
Identifier "Screen0"
Device "Device0"
Monitor"Monitor0"
DefaultDepth24
SubSection "Display"
Depth   24
EndSubSection
EndSection

Bug#698795: GPS information are shown without decimal values

[althaser]

Sandro can you still reproduce this issue with newer version like
eog-3.10.1-1 ?

there are two representative ways of coordinates:
http://andrew.hedges.name/experiments/convert_lat_long/ or
http://itouchmap.com/latlong.html

I can't find an image that eog fails in coordinates.

thanks
regards
althaser

Bug#736149: [Pkg-telepathy-maintainers] Bug#736149: Empathy screenshots for debian.org SIP accounts

[Simon McVittie]

On 20/01/14 10:49, Daniel Pocock wrote:
> Also, we don't want people to manually configure the SIP proxy name in
> the config panel.  Can you let me know if Empathy can discover the proxy
> using NAPTR and SRV lookups in DNS?  That is how Jitsi is finding it.

Empathy doesn't, and shouldn't, do networking - protocol backends are
responsible for that. telepathy-rakia uses sofia-sip, which (according
to git grep) appears to have support for NAPTR and SRV records, although
I have no idea how/whether that works.

telepathy-gabble does the analogous SRV lookups for _xmpp-client._tcp,
although I think SRV lookups for an associated STUN or TURN server might
still be an open feature request.

S


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

Bug#735561: [cgroup-tools] RE: [cgroup-tools] Unable to install on Debian Testing due to unsatisfiable libcgroup1 dependency

[Omega Weapon]

Sorry, I have testing as the default and expect aptitude to only pull 
from testing unless I specify a different version (which it obviously 
doesnt, a usability bug for me).


cgroup-tools isn't on testing currently.

--
Libre software on Github: https://github.com/OmegaPhil
FSF member #9442


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

Bug#735309: libconfig-model-dpkg-perl: Please support canonical Vcs fields

[Dominique Dumont]

On Saturday 18 January 2014 14:52:26 you wrote:
> I'd recommend that if you find something like
> 
>git\.debian\.org/\?p=debian-med

Yes. I was quite close: the '\' before '?' is missing in the regexp I 
use. I'll fix this soon (and improve the test cases).

Thanks

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

Bug#736159: ben: Requires no-longer provided Sources.bz2 files

[Christian Hofstaedtler]

Package: ben
Version: 0.6.6+b1
Severity: important

Dear Maintainer,

`ben download` attempts to download Sources.bz2 files, but apparently
these have been replaced by Sources.xz files on the main Debian archive.

As there does not seem to be a fallback, this makes `ben download`
unusable, incl. - for me - the other parts of ben, as now there's
no data source.

Example call:

% ben download --verbose --mirror http://http.at.debian.org/debian --suite sid
  % Total% Received % Xferd  Average Speed   TimeTime Time  Current
 Dload  Upload   Total   SpentLeft  Speed
100   322  100   3220 0294  0  0:00:01  0:00:01 --:--:--   294
bzcat: (stdin) is not a bzip2 file.
Uncaught exception: ben-specific error: curl exited with return code 2



tcpdump of this:

19:30:55.519615 IP 192.168.234.128.35917 > 213.129.232.18.80: Flags [P.], seq 
1:123, ack 1, win 29200, length 122
.P.r.iR..GET /debian/dists/sid/main/source/Sources.bz2 HTTP/1.1
User-Agent: curl/7.34.0
Host: http.at.debian.org
Accept: */*


19:30:55.519846 IP 213.129.232.18.80 > 192.168.234.128.35917: Flags [.], ack 
123, win 64240, length 0
E..(...1.P.M...FP...c.
19:30:55.781341 IP 213.129.232.18.80 > 192.168.234.128.35917: Flags [P.], seq 
1:507, ack 123, win 64240, length 506
E.."...5.P.M...FP...HTTP/1.1 404 Not Found
Date: Mon, 20 Jan 2014 13:22:55 GMT
Server: Apache/2.2.22 (Debian)
Vary: Accept-Encoding
Content-Length: 322
Content-Type: text/html; charset=iso-8859-1



404 Not Found

Not Found
The requested URL /debian/dists/sid/main/source/Sources.bz2 was not found on 
this server.

Apache/2.2.22 (Debian) Server at http.at.debian.org Port 80




Thank you,
Christian


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

Bug#698795: GPS information are shown without decimal values

[althaser]

I forgot to mention that all images I tried have Dº M' S'' format.

I couldn't get an image with decimal degree format.

If you can please share here.

thanks
regards
althaser