date:20130408

On Fri, 5 Apr 2013, Philippe Cloutier wrote:

  And, for what’s worth, I’m obviously against any
  non-backwards-compatible changes in that manner…

 I don't see which backwards-incompatibility you have in mind.

Such as requiring changes to existing LocalSettings-esque files
by moving the inclusion of the Debian-specific configuration
away from those.

 I didn't mean Special:Interwiki couldn't work. I'm just saying we're
 missing a symlink to the new (although outdated) version. I'm not aware of
 actual problems keeping the old version would cause, but if we have the new
 version, we should at least have a symlink to it.

What new version? I don’t understand.

bye,
//mirabilos
-- 
tarent solutions GmbH
Rochusstraße 2-4, D-53123 Bonn • http://www.tarent.de/
Tel: +49 228 54881-393 • Fax: +49 228 54881-314
HRB 5168 (AG Bonn) • USt-ID (VAT): DE122264941
Geschäftsführer: Boris Esser, Sebastian Mancke


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

Bug#704954: colortest-python: New version available

2013-04-08 Thread John Eikenberry

Package: colortest-python
Version: 1.4-2
Severity: wishlist

Just released version 1.5 which adds Python 3 compatibility.
Thanks.

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

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

Versions of packages colortest-python depends on:
ii  python  2.7.3-4

colortest-python recommends no packages.

Versions of packages colortest-python suggests:
ii  colortest  20110624-1

-- no debconf information


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

Bug#704955: RFP: php-horde-lz4 -- Horde LZ4 Compression Extension

2013-04-08 Thread Mathieu Parent

Package: wnpp
Severity: wishlist
Owner: Mathieu Parent math.par...@gmail.com

 Package name: horde_lz4
 Version : 1.0.0
 Upstream Author : Michael Slusarz
 URL : http://horde.org/
 License : PHP 3.01
 Programming Lang: PHP
 Description : Horde LZ4 Compression Extension
PHP extension that implements the LZ4 compression algorithm - an extremely fast 
lossless compression algorithm.

I'm requesting this as part of Horde5 packaging.


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

Bug#704939: python-ldap: ldaps connections fail

2013-04-08 Thread Michael Ströder

Is the set of trusted CA certs exactly the same on both systems?

Note that on Debian libldap is linked against GnuTLS. In this case the
ldap.SERVER_DOWN exception does not contain a useful diagnostic message.
When linking libldap against OpenSSL a message generated by OpenSSL is
returned by libldap as diagnostic message.

Ciao, Michael.

Gareth Walters (2K Australia) wrote:
 
 Package: python-ldap
 Version: 2.4.10-1
 Severity: important
 
 Dear Maintainer,
 While trying to get a python scrip tof mine to work in Wheezy (have it
 running in Squeeze and several other OSs)
 I come across this error when using ldaps://
 
 ldap.SERVER_DOWN: {'desc': Can't contact LDAP server}
 The server is up and the same script is working on the Squeeze machine.
 
 Its talking to Windows AD 2008 R2
 
 the minimal code to reproduce is;
 import ldap
 myldap=ldap.initialize(ldaps://xx.xx.xx.100)
 myldap.bind_s('bindDN','bindPASS')
 
 but this works
 import ldap
 myldap=ldap.initialize(ldap://xx.xx.xx.100;)
 myldap.bind_s('bindDN','bindPASS')
 
 Does not even get far enough to give a certificate error as would
 notmally happen without allow unverified/trusted SSL cert.
 
 
 Output when setting ldap debug on;
 
 ldap_create
 ldap_url_parse_ext(ldaps://xx.xx.xx.105)
 ldap_url_parse_ext(ldaps://xx.xx.xx.100)
 ldap_sasl_bind
 ldap_send_initial_request
 ldap_new_connection 1 1 0
 ldap_int_open_connection
 ldap_connect_to_host: TCP xx.xx.xx.100:636
 ldap_new_socket: 3
 ldap_prepare_socket: 3
 ldap_connect_to_host: Trying xx.xx.xx.100:636
 ldap_pvt_connect: fd: 3 tm: -1 async: 0
 ldap_int_open_connection
 ldap_connect_to_host: TCP xx.xx.xx.105:636
 ldap_new_socket: 5
 ldap_prepare_socket: 5
 ldap_connect_to_host: Trying xx.xx.xx.105:636
 ldap_pvt_connect: fd: 5 tm: -1 async: 0
 ldap_err2string
 Traceback (most recent call last):
   File ./adauth.py, line 71, in module
  
 myldap.bind_s(config.get('ldap','bindDN'),config.get('ldap','bindPASS'))
   File /usr/lib/python2.7/dist-packages/ldap/ldapobject.py, line 222,
 in bind_s
 msgid = self.bind(who,cred,method)
   File /usr/lib/python2.7/dist-packages/ldap/ldapobject.py, line 216,
 in bind
 return self.simple_bind(who,cred)
   File /usr/lib/python2.7/dist-packages/ldap/ldapobject.py, line 201,
 in simple_bind
 return
 self._ldap_call(self._l.simple_bind,who,cred,RequestControlTuples(server
 ctrls),RequestControlTuples(clientctrls))
   File /usr/lib/python2.7/dist-packages/ldap/ldapobject.py, line 99,
 in _ldap_call
 result = func(*args,**kwargs)
 ldap.SERVER_DOWN: {'desc': Can't contact LDAP server}
 
 
 
 -- System Information:
 Debian Release: 7.0
   APT prefers testing
   APT policy: (500, 'testing')
 Architecture: amd64 (x86_64)
 
 Kernel: Linux 3.2.0-4-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
 
 Versions of packages python-ldap depends on:
 ii  libc6  2.13-38
 ii  libldap-2.4-2  2.4.31-1
 ii  python 2.7.3-4
 ii  python2.7  2.7.3-6
 
 python-ldap recommends no packages.
 
 Versions of packages python-ldap suggests:
 pn  python-ldap-doc  none
 pn  python-pyasn1none
 
 -- no debconf information



smime.p7s
Description: S/MIME Cryptographic Signature

Bug#704956: ITP: libtext-string-hexconvert-perl -- Converts ASCII strings to hexadecimal and reverse

2013-04-08 Thread Cyril Bouthors

Package: wnpp
Severity: wishlist

* Package name: libtext-string-hexconvert-perl
  Version : 0.01-1
  Upstream Author : Andreas Hernitscheck aher...@cpan.org
* URL or Web page : http://search.cpan.org/~ahernit/String-HexConvert/
* License : LGPL
  Description : Converts ASCII strings to hexadecimal and reverse

Wrapper around pack and unpack of Perl to convert a string of hex digits to
ASCII and other way around.
-- 
 ,''`.
: :' :  Cyril Bouthors
`. `' Debian.org
  `- Debian-Packaging.com


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

Bug#704957: git-annex: git annex fsck reports bad file content for intact files

2013-04-08 Thread Henrik Ahlgren

Package: git-annex
Version: 3.20120629
Severity: normal

Dear Maintainer,

The annex-fsck command appears to think some files are bad, even though
there appears to be nothing wrong with them.

What I did: I ran git annex fsck on two separate annex repositories (on the 
same machine), both
containing some few hundred annexed files of various sizes, plus thousands of 
smaller non-annexed
objects. git fsck for the normal objects succeeded without any errors.

Outcome: Both repositories reported Bad file content errors on seemingly 
random files,
and the number of bad files was 46 and 47. Example (filenames censored - they 
don't contain
any special char except spaces):

fsck XXX/YYY.psd.gz (checksum...) 
  Bad file content; moved to 
/home/pablo/Documents/private/.git/annex/bad/SHA256E-s10392194--82ffa5dcee1460a0aaf2e6ee0d6361dc0efcd67881d786feae805f7a55c7d228.psd.gz
failed

(...)
fsck AAA/BBB/CCC.pdf (checksum...) 
  Bad file content; moved to 
/home/pablo/Documents/private/.git/annex/bad/SHA256E-s175727--a71185f5778152394dced031a66094bd1553b3b8d2ea23cd539cd3b93bfe304e.1999.pdf
failed
(Recording state in git...)
git-annex: fsck: 47 failed

However when I check the integrity of the objects moved to .git/annex/bad, the 
SHA256 sums match:

$ sha256sum 
SHA256E-s10392194--82ffa5dcee1460a0aaf2e6ee0d6361dc0efcd67881d786feae805f7a55c7d228.psd.gz
 
82ffa5dcee1460a0aaf2e6ee0d6361dc0efcd67881d786feae805f7a55c7d228  
SHA256E-s10392194--82ffa5dcee1460a0aaf2e6ee0d6361dc0efcd67881d786feae805f7a55c7d228.psd.gz

I also ran sha256sum .git/annex/bad/* and all the bad files seem to be just 
fine.

This problem seems to be reproducible: I copied the objects back from another 
repository
(residing on an SD card) with git annex copy --from=8gbmicrosd, and ran the 
same fsck
command again, and got the exact same results (i.e. diffed the logged output of 
stdout/stderr).

After that I ran annex-fsck on the repository on the SD card, and once again, 
the same thing happened,
so we can rule out a hardware problem on the main SSD drive of the machine. I 
also ran a test
sript that creates 1000 files of 100 MB in size from /dev/unrandom, takes an 
SHA256 hash of them,
saves them using the hash as their filename, and then checks the SHA256 sum of 
all files, and
repeats this cycle 100 times. No integrity errors were observed on this test, 
so both the hardware
and filesystem/kernel appears to work reliably (note: I'm using self-compiled 
3.8.5, haven't yet tried
reproducing this with stock Wheezy kernel).

Best regards and thanks for the great tool.

Henrik

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

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

Versions of packages git-annex depends on:
ii  curl7.26.0-1+wheezy1
ii  git 1:1.7.10.4-1+wheezy1
ii  libc6   2.13-38
ii  libffi5 3.0.10-3
ii  libgmp102:5.0.5+dfsg-2
ii  libpcre31:8.30-5
ii  openssh-client  1:6.0p1-4
ii  rsync   3.0.9-4
ii  uuid1.6.2-1.3
ii  wget1.13.4-3

Versions of packages git-annex recommends:
ii  lsof  4.86+dfsg-1

Versions of packages git-annex suggests:
pn  bup   none
ii  gnupg 1.4.12-7
pn  graphviz  none

-- 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#628843: login: tty hijacking - suggested solution inclusive patch but now solved

2013-04-08 Thread Wolfgang Zarre

Hello,

As Alexander pointed out correctly the first suggested solution was not good 
enough
to solve the issue, but thanks to You @Alexander I could figure out the real 
issue.

Neither permission handling nor controlling the child process would resolve this
issue and also not assumed fixes in the implementation of TTY's Unix/Linux 
because
the issue it is simply the way how files are handled in a Unix system and a TTY 
is
just simply a file.

To demonstrate this just create a small program which is writing several text 
lines
to a file and change during execution ownership and permissions or even remove 
the
file and there will be no failure as long as the file handle is open.

In other words, if once a file descriptor is open and also if inherit from a 
forked
process, this process has all rights to do whatever it wants to do except if it
closes itself the file handle.

And that is exactly the issue with stdin in 'su' because after calling execve it
is out of our control if stdin gets closed or not.

In fact we need is the possibility to open a 'new' stdin just with the 
permissions
of the new session which we can close ourself at exit and this can be realised 
in
utilising pseudo terminal devices as implemented with the following patch.

Further the following patch was just tested roughly on Linux with PAM because 
of lack
of time but worked for me.


@Alexander:
I was using Your test procedure as You suggested but now if You want to have an
output You would have to redirect stdout and stderr to a file to see the result.


Another issue I realised during testing was the fact that the child process
cannot be killed with SIGTERM according to the blocked signal coded but which
might be a nice-to-have IMHO but I'm not sure if this behaviour is intentional
or not.

BTW: The patch is against shadow_4.1.5.1.orig.tar.gz which means without the
Debian patches.


___BEGIN_PATCH___
--- shadow-4.1.5.1.orig/src/su.c2012-05-25 13:51:55.0 +0200
+++ shadow-4.1.5.1/src/su.c 2013-04-08 00:14:15.500412395 +0200
@@ -62,12 +62,10 @@
 #include stdio.h
 #include sys/types.h
 #include unistd.h
-#ifndef USE_PAM
 #include sys/ioctl.h
+#include fcntl.h
 #include sys/types.h
 #include sys/stat.h
-#include fcntl.h
-#endif /* !USE_PAM */
 #include prototypes.h
 #include defines.h
 #include pwauth.h
@@ -85,6 +83,7 @@ const char *Prog;
 static /*@observer@*/const char *caller_tty = NULL;/* Name of tty SU is 
run from */
 static bool caller_is_root = false;
 static uid_t caller_uid;
+static bool have_tty = false;
 #ifndef USE_PAM
 static bool caller_on_console = false;
 #ifdef SU_ACCESS
@@ -106,10 +105,10 @@ static bool change_environment = true;

 #ifdef USE_PAM
 static pam_handle_t *pamh = NULL;
+#endif
 static int caught = 0;
 /* PID of the child, in case it needs to be killed */
 static pid_t pid_child = 0;
-#endif

 /*
  * External identifiers
@@ -123,10 +122,9 @@ extern size_t newenvc; /* libmisc/env.c
 static void execve_shell (const char *shellname,
   char *args[],
   char *const envp[]);
-#ifdef USE_PAM
 static RETSIGTYPE kill_child (int unused(s));
-static void prepare_pam_close_session (void);
-#else  /* !USE_PAM */
+static void handle_session (void);
+#ifndef USE_PAM
 static RETSIGTYPE die (int);
 static bool iswheel (const char *);
 #endif /* !USE_PAM */
@@ -177,7 +175,7 @@ static bool iswheel (const char *usernam
}
return is_on_list (grp-gr_mem, username);
 }
-#else  /* USE_PAM */
+#endif /* USE_PAM */
 static RETSIGTYPE kill_child (int unused(s))
 {
if (0 != pid_child) {
@@ -189,7 +187,6 @@ static RETSIGTYPE kill_child (int unused
}
exit (255);
 }
-#endif /* USE_PAM */

 /* borrowed from GNU sh-utils' su.c */
 static bool restricted_shell (const char *shellname)
@@ -260,7 +257,6 @@ static void execve_shell (const char *sh
}
 }

-#ifdef USE_PAM
 /* Signal handler for parent process later */
 static void catch_signals (int sig)
 {
@@ -268,19 +264,108 @@ static void catch_signals (int sig)
 }

 /*
- * prepare_pam_close_session - Fork and wait for the child to close the session
+ * handle_session - Fork and handle the session
  *
- * Only the child returns. The parent will wait for the child to
+ * Only the child returns. The parent will handle the session
+ * or if not a controlling terminal then wait for the child to
  * terminate and exit.
  */
-static void prepare_pam_close_session (void)
+static void handle_session (void)
 {
sigset_t ourset;
int status;
int ret;
+   int fd_ptmx = -1;
+   int fd_pts = -1;
+   char *pts_name = NULL;  
+   struct termios termset_save;
+   struct termios termset_new;
+   fd_set inp_fds;
+   struct timeval sel_to;
+   char trbuf[BUFSIZ];
+   ssize_t

Bug#704872: libpango1.0-0: latest version no longer supplies modules, breaks initramfs with Plymouth, often pops up warnings

2013-04-08 Thread Emilio Pozuelo Monfort


reassign 704872 plymouth

Hi Alex,

On 04/07/2013 02:44 AM, Alex Vanderpol wrote:

Package: libpango1.0-0
Version: 1.32.5-3
Severity: important

Dear Maintainer,

The latest version of Pango appears to be fairly problematic, first with i386
packages not recognizing the transitional package for all architectures
(already filed a separate bug about that),


I'll look into that soon.


and now I discover that the module
files that used to be shipped with the older version no longer exist, breaking
initramfs with Plymouth (meaning no new kernel installs or upgrades) and
throwing up warnings for anything else looking for them.


This may be a bug in plymouth. I see in its hook that it tries to copy a module 
to the ramdisk:


copy_exec /usr/lib/@DEB_HOST_MULTIARCH@/pango/1.6.0/modules/pango-basic-fc.so

but the modules are now built in, so this souldn't be necessary anymore. And 
even if we still shipped the modules like before, it would still fail because 
the module ABI is 1.8.0 in pango = 1.32.


plymouth maintainers: pango from experimental builds the modules into the shared 
library. The plymouth hook needs to be updated to cope with this (perhaps you 
can do this in experimental for the time being).


Thanks,
Emilio


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

Bug#702278: busybox upload

Michael Tokarev m...@tls.msk.ru (08/04/2013):
 I'm pinging this bug, as we're getting seriously out of time.

Well, if you had Cc'd the right people in the first place…

  Let me start from scratch please.  I wasn't aware of this
  bugreport/discussion, and I made a mistake by not filing a proper
  unblock request when I uploaded the busybox package with all the
  fixes.  So here are descriptions of every change.

I'm not sure a whole essay was needed…

  So, any bug in busybox which does not affect basic initramfs or
  d-i functionality directly can't be important enough for whole
  debian system, so to say.

Indeed.

  On the other hand, sometimes, since busybox is almost always
  installed and available on any debian system, it gets used by
  users in various much less restricted environments, which leads to
  situations where the bugs are actually gets hit.  This is minority
  of users (again, so to say).
  
  So this is about whenever we really care about this minority
  or not, _plus_ about _possible_ issues in d-i or initramfs.

Gotcha! If it isn't triggering a bug in d-i which landed on our radar,
better not touch busybox.

  As has been said before, this is a feature fix.  It is not.  The
  problem initially has been raized in some other package which had
  initramfs hook which didn't work.  I don't remember which package
  it was, the context was that it tried to find some CPU feature by
  grepping /proc/cpuinfo with -w flag to grep, used to remove false
  positives, and it didn't work.  (/proc/cpuinfo is just an example,
  I don't really remember what it was).  This is one of these bugs
  which makes other, unrelated components fails in unexpected and
  difficult to debug ways.

If you can't find which component it was, surely that isn't as
important as you pretend it to be. Worst case, that component can be
adjusted. Especially when logic gets rewritten, and when the fix is
“somewhat large”, and when test cases aren't run.

  The fix is somewhat large, because it had to deal with logic of
  operations in grep applet.  On the plus side, it comes with
  additional testcases which checks for this issue, and there are
  lots of other grep-related testcases already present.
  Unfortunatly busybox debian package still does not run any
  testcases during build (this is on my TODO list of first things to
  do for jessie), but having in mind the situation (deep freeze) and
  importance of the applet I ran provided and a few more testcases
  against the resulting grep on x86, ppc and mips platforms (on
  debian porterboxes) manually to ensure the fix does not break
  anything else and actually fixes the bug.

I can't wait to see tests enabled. :)

  If you ask me, this is about the same importance as #686502, but
  it is less obvious.  This grep-w bug does not lead to data loss
  directly, the problem is that we can't rely on grep doing the
  right thing when we use it in a familiar, natural way - like when
  we try to fix a false positive by adding -w _somewhere else_ (in
  some other package that is), and it stops working.
  
  That's why it isn't a feature fix, busybox claimed to support
  grep-w but it does not work.

That's exactly what I'd call a “feature fix”.

  What we're fixing here mostly is about _further_ d-i or initramfs
  changes (including possibility to have these changes in wheezy
  too) which looks completely correct and obvious but don't work in
  practice.  Plus some random rare end-users usage of busybox grep,
  of these are exists.  What we risk here is almost nothing, at
  least according to my tests on several platforms.

Possible, possibility, random, rare. → Not enough to fix at this
point.

* xz-support-concatenated-xz-streams.patch (Closes: #686502)
  
  This is the main RC bug currently filed against busybox.  The
  rationale for it being RC is because it causes _silent_ data loss
  when decompressing certain kinds of XZ streams.
  
  Again, the severuty can be argued for sure, due to whole nature of
  busybox as a second-kind sitizen as mentioned at the beginning
  of this mail.  First, not everyone is using busybox unxz (which is
  used in busybox tar and other archivers too), second, concatenaed
  xz streams aren't frequent either (but this becomes more and more
  of a problem, because such streams are produced by parallel xz,
  and this already seen in the wild - in particular, recent kernel
  sources on kernel.org are of this kind).
  
  We're unlikely to met all the conditions for this bug in d-i or
  initramfs during wheezy lifetime, -- _provided_ that some future
  _wheeze_ update will not contain such concatenated xz streams
  produced by, say, an improved version of dpkg (which utilizes
  multiple cores for compression), -- but this is an unlikely
  situation.

Agreed, and unlikely means I'm not going to approve of such a chance
at this point.

  What we _also_ fixing here is a possible silent data loss for
  end-users who may use buzybox to uncompress their

Bug#702278: busybox upload

Forgot to mention one thing:

Cyril Brulebois k...@debian.org (08/04/2013):
 My take is: until we hit real bugs in real situations, we keep busybox
 as it is. If release managers want to cherry-pick a few fixes, I won't
 stop them from requesting so. But as far as I'm concerned, I'd really
 like to see practical issues before getting busybox updated.

Nonetheless, I do appreciate your efforts in trying to get things
fixed, especially when done by cherry-picking things from upstream,
instead of insisting for our moving to latest master. It's just too
late for that, for bugs that don't seem to be hit in real life©®™.

Mraw,
KiBi.


signature.asc
Description: Digital signature

Bug#704958: iceowl-extension: calendar caching not working

2013-04-08 Thread Benoit Panizzon

Package: iceowl-extension
Version: 10.0.12-1
Severity: important

Dear Maintainer,

In our company we have a centralized caldav server. Mac users connect to it 
with iCal and can also created and read appointments on notebooks when not 
connected.

Non Mac users use iceowl, as it supposely also supports calendar caching while 
offline.

Now I found out that the in this version (10.0.12-1) you can enable caching 
which allows you to read calendar entries while offline. If you try to create 
or modify an entry, this leads to an error telling the server
is not reachable. But the changes then are not cached and syncronized back when 
the server becomes online.

Also if you untick a calendar apparently the cache is emptied so if you tick it 
again while offline, you don't even seen the appointments.

Is this expected behaviour or a bug in the caching management?

Are there other caldav clients you could recommend for Debian users which work 
better on portable devices?

Kind regards
-Benoit-


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

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

Versions of packages iceowl-extension depends on:
ii  calendar-timezones  10.0.12-1
ii  icedove 10.0.12-1
ii  libc6   2.13-38
ii  libnspr42:4.9.2-1
ii  libnspr4-0d 2:4.9.2-1
ii  libstdc++6  4.7.2-5

Versions of packages iceowl-extension recommends:
ii  calendar-google-provider  10.0.12-1

Versions of packages iceowl-extension suggests:
ii  fonts-lyx  2.0.3-3

-- 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#704939: python-ldap: ldaps connections fail

2013-04-08 Thread Michael Ströder

Gareth Walters (2K Australia) wrote:
 Neither system(s) have any extra ca certs trusted. The code sets  the ldap
 options to disable cert verification.

As this is bad practice anyway:
Could you please test with explictly the trusted CA certs?

Also note that if you really want to disable all libldap config processing you
would have to set the env var LDAPNOINIT=1.

Add this line to the beginning of your Python code:

os.environ['LDAPNOINIT']='1'

Ciao, Michael.



smime.p7s
Description: S/MIME Cryptographic Signature

Bug#704959: git-bzr: missing file after cloning the lp:foxtrotgps repo

2013-04-08 Thread Paul Wise

Package: git-bzr
Version: 1:1.8.2-1
Severity: normal

When I clone the foxtrotgps bzr repository using git-bzr, there is one
file missing from the resulting working directory.

In the bzr log, I see that the missing file was replaced by a new
version of itself. Based on the bzr and git log information, it looks
like git-bzr is adding the new version of the file and deleting it
instead of deleting it and adding the new version (replacing it).

pabs@chianamo ~ $ mkdir git-bzr-bug-missing-files
pabs@chianamo ~ $ cd git-bzr-bug-missing-files/
pabs@chianamo ~/git-bzr-bug-missing-files $ bzr branch lp:foxtrotgps 
foxtrotgps-bzr
You have not informed bzr of your Launchpad ID, and you must do this to
write to Launchpad or access private data.  See bzr help launchpad-login.
Branched 232 revisions.   
pabs@chianamo ~/git-bzr-bug-missing-files $ cd foxtrotgps-bzr/
pabs@chianamo ~/git-bzr-bug-missing-files/foxtrotgps-bzr $ find ! -iname .bzr ! 
-iwholename '*/.bzr/*' | sort  ../foxtrotgps-bzr-files
pabs@chianamo ~/git-bzr-bug-missing-files/foxtrotgps-bzr $ cd ..
pabs@chianamo ~/git-bzr-bug-missing-files $ git clone bzr::lp:foxtrotgps 
foxtrotgps-git
Cloning into 'foxtrotgps-git'...
You have not informed bzr of your Launchpad ID, and you must do this to
write to Launchpad or access private data.  See bzr help launchpad-login.
progress revision roz...@geekspace.com-20100507043653-unbq6ldi2j7virgw (100/567)
progress revision roz...@geekspace.com-20100602051627-2xt9jsdpojcxbo47 (200/567)
progress revision roz...@geekspace.com-20101017210852-ltxtt1htxqs0v5uh (300/567)
progress revision roz...@geekspace.com-20110413003604-9su7poyse1t1ajsf (400/567)
progress revision roz...@geekspace.com-20120206041904-5derbaceszb4r824 (500/567)
pabs@chianamo ~/git-bzr-bug-missing-files $ cd foxtrotgps-git/
pabs@chianamo ~/git-bzr-bug-missing-files/foxtrotgps-git (master =) $ find ! 
-iname .git ! -iwholename '*/.git/*' | sort  ../foxtrotgps-git-files
pabs@chianamo ~/git-bzr-bug-missing-files/foxtrotgps-git (master =) $ cd ..
pabs@chianamo ~/git-bzr-bug-missing-files $ diff -u foxtrotgps-bzr-files 
foxtrotgps-git-files
--- foxtrotgps-bzr-files2013-04-08 15:53:24.706619204 +0800
+++ foxtrotgps-git-files2013-04-08 15:53:53.478618930 +0800
@@ -35,7 +35,6 @@
 ./pixmaps/foxtrotgps-friend.png
 ./pixmaps/foxtrotgps-myposition.png
 ./pixmaps/foxtrotgps-photo.png
-./pixmaps/foxtrotgps.png
 ./pixmaps/foxtrotgps-poi.png
 ./pixmaps/foxtrotgps-wp.png
 ./pixmaps/Makefile.am

pabs@chianamo ~/git-bzr-bug-missing-files/foxtrotgps-bzr $ bzr log -p 
pixmaps/foxtrotgps.png 

revno: 71 [merge]
committer: Joshua Judson Rosen roz...@geekspace.com
branch nick: trunk
timestamp: Mon 2010-05-31 02:54:04 -0400
message:
  New main application icon, specifically created for FoxtrotGPS.
diff:
=== added file 'pixmaps/foxtrotgps.png'
Binary files pixmaps/foxtrotgps.png 1970-01-01 00:00:00 + and 
pixmaps/foxtrotgps.png2010-05-31 06:38:02 + differ
=== removed file 'pixmaps/foxtrotgps.png'
Binary files pixmaps/foxtrotgps.png 2010-04-14 01:13:14 + and 
pixmaps/foxtrotgps.png1970-01-01 00:00:00 + differ

Use --include-merged or -n0 to see merged revisions.

pabs@chianamo ~/git-bzr-bug-missing-files/foxtrotgps-bzr $ bzr log 
--include-merged -p pixmaps/foxtrotgps.png 

revno: 71 [merge]
committer: Joshua Judson Rosen roz...@geekspace.com
branch nick: trunk
timestamp: Mon 2010-05-31 02:54:04 -0400
message:
  New main application icon, specifically created for FoxtrotGPS.
diff:
=== added file 'pixmaps/foxtrotgps.png'
Binary files pixmaps/foxtrotgps.png 1970-01-01 00:00:00 + and 
pixmaps/foxtrotgps.png2010-05-31 06:38:02 + differ
=== removed file 'pixmaps/foxtrotgps.png'
Binary files pixmaps/foxtrotgps.png 2010-04-14 01:13:14 + and 
pixmaps/foxtrotgps.png1970-01-01 00:00:00 + differ

revno: 14.1.4
committer: Joshua Judson Rosen roz...@geekspace.com
branch nick: project-rename
timestamp: Mon 2010-05-31 02:38:02 -0400
message:
  New foxtrotgps icon, actually distinct from the tangogps one.
diff:
=== added file 'pixmaps/foxtrotgps.png'
Binary files pixmaps/foxtrotgps.png 1970-01-01 00:00:00 + and 
pixmaps/foxtrotgps.png2010-05-31 06:38:02 + differ
=== removed file 'pixmaps/foxtrotgps.png'
Binary files pixmaps/foxtrotgps.png 2010-04-14 01:13:14 + and 
pixmaps/foxtrotgps.png1970-01-01 00:00:00 + differ

pabs@chianamo ~/git-bzr-bug-missing-files/foxtrotgps-git (master =) $ git log 
-p -- pixmaps/foxtrotgps.png 
commit 2373bdd86384f240f7987a830f0cf78e0fae4e3a
Author: Joshua Judson Rosen roz...@geekspace.com
Date:   Mon May 31 02:38:02 2010 -0400

New foxtrotgps icon, actually distinct

Bug#704946: polarssl: CVE-2009-3555

2013-04-08 Thread Roland Stigge

Hi!

Thanks for the note!

On 04/08/2013 04:34 AM, Michael Gilbert wrote:
 This issue is still being tracked as affecting polarssl in the
 security tracker.  It's old, so it's likely been fixed, but it's
 important to be thorough, so please check that it is and adjust the
 affected versions appropriately.
 
 CVE-2009-3555[0]:
 | The TLS protocol, and the SSL protocol 3.0 and possibly earlier, as
 | used in Microsoft Internet Information Services (IIS) 7.0, mod_ssl in
 | the Apache HTTP Server 2.2.14 and earlier, OpenSSL before 0.9.8l,
 | GnuTLS 2.8.5 and earlier, Mozilla Network Security Services (NSS)
 | 3.12.4 and earlier, multiple Cisco products, and other products, does
 | not properly associate renegotiation handshakes with an existing
 | connection, which allows man-in-the-middle attackers to insert data
 | into HTTPS sessions, and possibly other types of sessions protected by
 | TLS or SSL, by sending an unauthenticated request that is processed
 | retroactively by a server in a post-renegotiation context, related to
 | a plaintext injection attack, aka the Project Mogul issue.
 
 For further information see:
 
 [0] http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2009-3555
 http://security-tracker.debian.org/tracker/CVE-2009-3555

At the polarssl's upstream tracker, I found the following similar issue:

https://polarssl.org/tech-updates/security-advisories/polarssl-security-advisory-2011-01
regarding CVE-2011-1923

Is CVE-2011-1923 related to CVE-2009-3555?

For CVE-2011-1923, they have a patch that applies to Debian's version in
squeeze (fixed upstream in squeeze), which I can adapt easily and
prepare as a security fix.

Nothing found directly for CVE-2009-3555 - will ask upstream.

Thanks,

Roland


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

Bug#704960: gnomeradio: Use Gnomeradio as desktop file Name

2013-04-08 Thread Triniton Adam

Package: gnomeradio
Version: 1.8-2
Severity: normal

Actually the name of application is displayed as FM-Radio Tuner :)
See screenshot

As discussed in various places we shouldn't use the generic name in the name
field in the desktop files:
http://lists.freedesktop.org/archives/xdg/2009-July/010807.html

We should also have consistency between the Name field, the name used in the
titlebar, the name used in the application menu (gnome-shell), the
about box, and the documentation.

Can we change the name in the desktop file to reflect this?

current gnomeradio desktop file:

-

[Desktop Entry]
Name=FM-Radio Tuner
Comment=Listen to FM-radio
Exec=gnomeradio
Icon=gnomeradio
Categories=AudioVideo;Audio;Tuner
StartupNotify=true
Terminal=false
Type=Application
X-GNOME-Bugzilla-Bugzilla=GNOME
X-GNOME-Bugzilla-Product=gnomeradio
X-GNOME-Bugzilla-Component=general
X-GNOME-DocPath=gnomeradio/gnomeradio.xml
X-Ubuntu-Gettext-Domain=gnomeradio

--

Any suggestion to change this would be welcome

Thanks


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

Bug#702278: busybox upload

2013-04-08 Thread Michael Tokarev

08.04.2013 11:57, Cyril Brulebois wrote:
 Forgot to mention one thing:
 
 Cyril Brulebois k...@debian.org (08/04/2013):
 My take is: until we hit real bugs in real situations, we keep busybox as it 
 is. If release managers want to cherry-pick a few fixes, I won't stop them 
 from requesting so. But as far as I'm concerned, I'd really like to see 
 practical issues before getting busybox updated.
 
 Nonetheless, I do appreciate your efforts in trying to get things fixed, 
 especially when done by cherry-picking things from upstream, instead of 
 insisting for our moving to latest master. It's just too late for that, for 
 bugs that don't seem to be hit in real life©®™.

We've at least two bugs which do hit us in real life - this is the
xz multi-stream issue (already seen on kernel.org) and non-working
grep -w.  But I repeat myself.

FWIW.

Thanks,

/mjt


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

Bug#684769: New upstream release (0.8.4)

2013-04-08 Thread Daniel Baumann

retitle 684769 new upstream release (0.8.6)
retitle 699354 new upstream release (0.8.6)
thanks

any news on this?

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


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

Bug#704946: CVE-2009-3555 and CVE-2011-1923

2013-04-08 Thread Roland Stigge

Hi,

at
https://polarssl.org/tech-updates/security-advisories/polarssl-security-advisory-2011-01

I found that CVE-2011-1923 is fixed in PolarSSL 0.14.2.

Haven't found anything about PolarSSL and CVE-2009-3555. So wondering if
it affects PolarSSL at all, if it's related to CVE-2011-1923 and if it's
fixed in PolarSSL already, if applicable.

See also http://bugs.debian.org/704946

Thanks in advance,

Roland


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

Bug#704802: plperl crashes immediately on kfreebsd

2013-04-08 Thread Christoph Berg

Re: Peter Eisentraut 2013-04-06 
20130406030939.14051.80312.report...@vanquo.pezone.net
 Package: postgresql-plperl-9.1
 Version: 9.1.9-1
 Severity: important
 
 Creating a plperl function on kfreebsd (amd64) immediately crashes the
 PostgreSQL server in the plperl.so module.  You can see this either by
 running the built-in regression tests (should probably be done during
 the build anyway) or by running the tests from
 t/020_create_sql_remove.t in the postgresql-common package.

Unfortunately the postgresql-common tests need root, so we can't run
these at build time.

I'd favor activating as many regression tests as possible at build
time. I was looking into that some time ago but somehow got lost
between the isolation tests and similar more academic tests.

Christoph
-- 
c...@df7cb.de | http://www.df7cb.de/


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

Bug#704939: python-ldap: ldaps connections fail

2013-04-08 Thread Gareth Walters (2K Australia)

Neither system(s) have any extra ca certs trusted. The code sets  the ldap  
options to disable cert verification.





- Original Message -
From: Michael Ströder [mailto:mich...@stroeder.com]
Sent: Monday, April 08, 2013 05:29 PM
To: Gareth Walters (2K Australia); 704...@bugs.debian.org 
704...@bugs.debian.org
Subject: Re: Bug#704939: python-ldap: ldaps connections fail

Is the set of trusted CA certs exactly the same on both systems?

Note that on Debian libldap is linked against GnuTLS. In this case the
ldap.SERVER_DOWN exception does not contain a useful diagnostic message.
When linking libldap against OpenSSL a message generated by OpenSSL is
returned by libldap as diagnostic message.

Ciao, Michael.

Gareth Walters (2K Australia) wrote:
 
 Package: python-ldap
 Version: 2.4.10-1
 Severity: important
 
 Dear Maintainer,
 While trying to get a python scrip tof mine to work in Wheezy (have it
 running in Squeeze and several other OSs)
 I come across this error when using ldaps://
 
 ldap.SERVER_DOWN: {'desc': Can't contact LDAP server}
 The server is up and the same script is working on the Squeeze machine.
 
 Its talking to Windows AD 2008 R2
 
 the minimal code to reproduce is;
 import ldap
 myldap=ldap.initialize(ldaps://xx.xx.xx.100)
 myldap.bind_s('bindDN','bindPASS')
 
 but this works
 import ldap
 myldap=ldap.initialize(ldap://xx.xx.xx.100;)
 myldap.bind_s('bindDN','bindPASS')
 
 Does not even get far enough to give a certificate error as would
 notmally happen without allow unverified/trusted SSL cert.
 
 
 Output when setting ldap debug on;
 
 ldap_create
 ldap_url_parse_ext(ldaps://xx.xx.xx.105)
 ldap_url_parse_ext(ldaps://xx.xx.xx.100)
 ldap_sasl_bind
 ldap_send_initial_request
 ldap_new_connection 1 1 0
 ldap_int_open_connection
 ldap_connect_to_host: TCP xx.xx.xx.100:636
 ldap_new_socket: 3
 ldap_prepare_socket: 3
 ldap_connect_to_host: Trying xx.xx.xx.100:636
 ldap_pvt_connect: fd: 3 tm: -1 async: 0
 ldap_int_open_connection
 ldap_connect_to_host: TCP xx.xx.xx.105:636
 ldap_new_socket: 5
 ldap_prepare_socket: 5
 ldap_connect_to_host: Trying xx.xx.xx.105:636
 ldap_pvt_connect: fd: 5 tm: -1 async: 0
 ldap_err2string
 Traceback (most recent call last):
   File ./adauth.py, line 71, in module
  
 myldap.bind_s(config.get('ldap','bindDN'),config.get('ldap','bindPASS'))
   File /usr/lib/python2.7/dist-packages/ldap/ldapobject.py, line 222,
 in bind_s
 msgid = self.bind(who,cred,method)
   File /usr/lib/python2.7/dist-packages/ldap/ldapobject.py, line 216,
 in bind
 return self.simple_bind(who,cred)
   File /usr/lib/python2.7/dist-packages/ldap/ldapobject.py, line 201,
 in simple_bind
 return
 self._ldap_call(self._l.simple_bind,who,cred,RequestControlTuples(server
 ctrls),RequestControlTuples(clientctrls))
   File /usr/lib/python2.7/dist-packages/ldap/ldapobject.py, line 99,
 in _ldap_call
 result = func(*args,**kwargs)
 ldap.SERVER_DOWN: {'desc': Can't contact LDAP server}
 
 
 
 -- System Information:
 Debian Release: 7.0
   APT prefers testing
   APT policy: (500, 'testing')
 Architecture: amd64 (x86_64)
 
 Kernel: Linux 3.2.0-4-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
 
 Versions of packages python-ldap depends on:
 ii  libc6  2.13-38
 ii  libldap-2.4-2  2.4.31-1
 ii  python 2.7.3-4
 ii  python2.7  2.7.3-6
 
 python-ldap recommends no packages.
 
 Versions of packages python-ldap suggests:
 pn  python-ldap-doc  none
 pn  python-pyasn1none
 
 -- 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#704961: ITP: libnet-google-safebrowsing2-perl -- Perl extension for the Google Safe Browsing v2 API

2013-04-08 Thread Cyril Bouthors

Package: wnpp
Severity: wishlist

* Package name: libnet-google-safebrowsing2-perl
  Version : 1.07-1
  Upstream Author : Julien Sobrier jul...@sobrier.net
* URL or Web page : http://search.cpan.org/~jsobrier/Net-Google-SafeBrowsing2/
* License : Perl
  Description : Perl extension for the Google Safe Browsing v2 API

The library passes most of the unit tests listed in the API documentation. See
the documentation
(http://code.google.com/apis/safebrowsing/developers_guide_v2.html) for more
details about the failed tests.

The Google Safe Browsing database must be stored and managed locally.
Net::Google::SafeBrowsing2::Sqlite uses Sqlite as the storage back-end,
Net::Google::SafeBrowsing2::MySQL uses MySQL. Other storage mechanisms
(databases, memory, etc.) can be added and used transparently with this module.

You may want to look at Google Safe Browsing v2: Implementation Notes
(http://www.zscaler.com/research/Google%20Safe%20Browsing%20v2%20API.pdf), a
collection of notes and real-world numbers about the API. This is intended for
people who want to learn more about the API, whether as a user or to make their
own implementation.

The source code is available on github at
https://github.com/juliensobrier/Net-Google-SafeBrowsing2.

If you do not need to inspect more than 10,000 URLs a day, you can use
Net::Google::SafeBrowsing2::Lookup with the Google Safe Browsing v2 Lookup API
which does not require to store and maintain a local database.

IMPORTANT: If you start with an empty database, you will need to perform several
updates to retrieve all the Google Safe Browsing information. This may require
up to 24 hours. This is a limitation of the Google API, not of this module. See
Google Safe Browsing v2: Implementation Notes at
http://www.zscaler.com/research/Google%20Safe%20Browsing%20v2%20API.pdf.
-- 
 ,''`.
: :' :  Cyril Bouthors
`. `' Debian.org
  `- Debian-Packaging.com


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

Bug#529178: xserver-xorg-video-ati: Suffering from this bug + Possible mitigation

2013-04-08 Thread Pablo Oliveira

Dear Alex,

  On Wed, Apr 3, 2013 at 3:34 PM, Alex Deucher alexdeuc...@gmail.com wrote:
  [...]
  Does a newer kernel help?  3.2 is pretty old.  There were
  a number of display related fixes that went into 3.7 for example.

Before trying with 3.7, to have a conclusive report, I tried to
reproduce on 3.2.
Sadly, I'm unable to reproduce the bug anymore on 3.2 kernel.

Last week, when I first reported on this bug ticket, the flickering
persisted both after a X server restart and a system restart. Only
when I performed a dpms cycle did it went away. Nevertheless, today
I'm unable to reproduce the flickering.

I have not installed or updated x-server packages since last week and
have not changed my video configuration, so I have no specific idea
about why I cannot reproduce anymore.

If in the future, I get the bug back, I will report here.

Thanks,

Pablo.


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

Bug#704957: maybe a problem with filenames containing many dots?

2013-04-08 Thread Henrik Ahlgren

After investigating a bit further, I noticed that a common thing with
the files that fail the consistency check is that their names contains
multiple dots, e.g. Fanni Joulukortti 2006.psd.gz and
16.01.1997-15.02.1997.pdf, something.tar.gz. The annex file
contain two parts of the filename, e.g. SHA256E-.1997.gz.


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

Bug#695961: It boots in graphics mode

2013-04-08 Thread Damjan Zemljič

After installing Wheezy RC1, Aspire One 725 boots in GNOME (fallback
option) by default. No tweaks needed.

Bug#701831: im-config: Please add Mallit input method framework support to im-config

2013-04-08 Thread Iain Lane

Hi Osamu,

On Sat, Mar 02, 2013 at 02:58:30AM +0900, Osamu Aoki wrote:
 Hi,
 
 Thanks.  I guess this patch merging can wait for the next release.
 
 Do we have Maliit related package in testing?

They just got accepted into experimental. It'd be nice to have this in
im-config so that we (both in Debian and Ubuntu) can use im-config to
select Maliit, so any review of this patch would be appreciated.

If you want to test it, rebuilding maliit-framework and maliit-plugins
from Ubuntu on Debian would probably be wise — they've had some upstream
and packaging changes that I haven't yet put into experimental because
it was in NEW already (and might hold off on for now since they will
require another round of binNEW).

Cheers,

-- 
Iain Lane  [ i...@orangesquash.org.uk ]
Debian Developer   [ la...@debian.org ]
Ubuntu Developer   [ la...@ubuntu.com ]


signature.asc
Description: Digital signature

Bug#704744: pbuilder: umounts /{dev,run}/shm of the host system

2013-04-08 Thread Stéphane Glondu

tags 704744 + patch
thanks

Le 08/04/2013 01:32, Thorsten Glaser a écrit :
 My idea to fix this is:
 
 Move the “umount_on_exit /dev/shm” line away from
 /usr/share/debootstrap/functions and into the files under
 /usr/share/debootstrap/scripts/ and then change it to use
 /run/shm from wheezy onwards (this also involves breaking
 up the symlink from etch, etch-m68k, lenny, oldstable,
 squeeze and stable to sid, and then, for the wheezy release,
 reintroducing the symlink from stable to sid).
 
 Unless you’ve got a better one, that is.

Why not just do nothing if /dev/shm is a symlink?

Are there cases where umount_on_exit is called on a symlink that should
be followed? If not, I would just kill the problem directly there, as in
the attached patch (untested).


Cheers,

-- 
Stéphane

diff -Nru debootstrap-1.0.48/debian/changelog debootstrap-1.0.48+nmu1/debian/changelog
--- debootstrap-1.0.48/debian/changelog	2013-04-04 16:18:04.0 +0200
+++ debootstrap-1.0.48+nmu1/debian/changelog	2013-04-08 10:27:16.0 +0200
@@ -1,3 +1,11 @@
+debootstrap (1.0.48+nmu1) UNRELEASED; urgency=low
+
+  * Non-maintainer upload.
+  * Do not follow symbolic links when unmounting filesystems in target
+(Closes: #704744)
+
+ -- StÃ©phane Glondu glo...@debian.org  Mon, 08 Apr 2013 10:26:29 +0200
+
 debootstrap (1.0.48) unstable; urgency=low
 
   * Team upload
diff -Nru debootstrap-1.0.48/functions debootstrap-1.0.48+nmu1/functions
--- debootstrap-1.0.48/functions	2013-03-25 16:25:14.0 +0100
+++ debootstrap-1.0.48+nmu1/functions	2013-04-08 10:26:24.0 +0200
@@ -954,7 +954,7 @@
 
 umount_exit_function () {
 	for dir in $UMOUNT_DIRS; do
-		( cd / ; umount $TARGET/${dir#/} ) || true
+		( cd / ; test -l $TARGET/${dir#/} || umount $TARGET/${dir#/} ) || true
 	done
 }

Bug#704872: libpango1.0-0: latest version no longer supplies modules, breaks initramfs with Plymouth, often pops up warnings

2013-04-08 Thread Alex Vanderpol

I probably should have mentioned I applied a patch for Plymouth that 
updated the hook to work with the newer versions of Pango (at least, the 
ones that still supplied separate modules). I don't think the patch was 
done properly though as it relies on pango-querymodules from the 
development package to find the modules, something I don't believe 
should be necessary in a normal setup, but at least it worked. The patch 
doesn't seem to work with the modules built-in though, so a proper fix 
is definitely in order.


At any rate, thanks for the information. For the time being I'll 
continue using the previous version (since it seems to work best for 
now) and keep an eye out for an update that will hopefully fix that 
other problem I seem to be having... (Silly multiarch, y u no like all 
arch libpango1.0-0 package for i386 on amd64 system?)



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

Bug#704949: [Openstack-devel] Bug#704949: cinder: [debconf_rewrite] Debconf templates and debian/control review proposal

2013-04-08 Thread Christian PERRIER

Quoting Thomas Goirand (z...@debian.org):

 So, in all of the above packages, we have a huge redundancy in
 templates. I thought that best would be to have a system to avoid this
 redundancy, like having a package holding (most of) the templates, and
 we would do dynamic replacements of variables. This way, translations
 would need to happen only once, which would be a very good thing.

That seems to be a good idea, at first glance. Something like
openstack-debconfig, or openstack-config.

Using dbconfig-common for all database-related stuff is also a good
idea. I'm not sure how well it is maintained but it's anyway better
than reinventing the very same templates to prompt users about
databases, database users, password, etc.

You mention you have concerns about itthey probably come because
the package is not that actively maintained, I'm afraid.

 But I'm really not sure how to do that. Do you know what my options are?
 How to implement something like this? Could you point at a set of
 package which has such kind of implementation already? Please don't
 point at dbconfig-common, it is quite complicated, and its
 implementation is wrong (eg: it can't be pre-seeded like normal
 packages), and very complicated to understand (I've dug into it, and
 it's quite hard to understand).

Well, how about using it for *some* stuff, at least?

 Also, note that all packages above are currently in Debian experimental
 due to the freeze. Only Cinder isn't, because it's not in testing
 anyway, so it's not a problem to have it in SID.
 
 Last, of course, I think that only until the above is addressed, a
 translation effort should start. Do you agree?


Sure. Let's hold the translation effort as of now. My recommendation
would be to make templates non translatable (drop the leading _) in
the meantime, so that cinder moves away from our radar (having too
many packages in a kinda pending state doesn't help tracking down
stuff).




signature.asc
Description: Digital signature

Bug#704962: florence: Some buttons words are not showing eg. Shift, Enter, Backspace.

2013-04-08 Thread Khurram Mahmood

Package: florence
Version: 0.5.1-1
Severity: normal

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

   * What led up to the situation?
   * What exactly did you do (or not do) that was effective (or
 ineffective)?
   * What was the outcome of this action?
   * What outcome did you expect instead?

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


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

Kernel: Linux 3.2.0-4-686-pae (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

Versions of packages florence depends on:
ii  gconf2  3.2.5-1+build1
ii  libatk1.0-0 2.4.0-2
ii  libatspi2.0-0   2.5.3-2
ii  libc6   2.13-38
ii  libcairo2   1.12.2-3
ii  libdbus-1-3 1.6.8-1
ii  libfontconfig1  2.9.0-7.1
ii  libfreetype62.4.9-1.1
ii  libgconf2-4 3.2.5-1+build1
ii  libgdk-pixbuf2.0-0  2.26.1-1
ii  libglib2.0-02.33.12+really2.32.4-5
ii  libgtk2.0-0 2.24.10-2
ii  libnotify4  0.7.5-1
ii  libpango1.0-0   1.30.0-1
ii  librsvg2-2  2.36.1-1
ii  libx11-62:1.5.0-1
ii  libxml2 2.8.0+dfsg1-7+nmu1
ii  libxtst62:1.2.1-1

florence recommends no packages.

florence 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#699242: weboob: new upstream release: 0.e

2013-04-08 Thread Stefano Zacchiroli

Control: retitle 699242 weboob: new upstream release: 0.f

On Tue, Jan 29, 2013 at 02:16:04PM +0100, Lucas Nussbaum wrote:
 A new upstream release is available.
 Do you plan to upload it to experimental?

Yes, please :) It'd be very nice to be able to try it out from
experimental.

Thanks for maintaining weboob!
Cheers.
-- 
Stefano Zacchiroli  . . . . . . .  z...@upsilon.cc . . . . o . . . o . o
Maître de conférences . . . . . http://upsilon.cc/zack . . . o . . . o o
Debian Project Leader . . . . . . @zack on identi.ca . . o o o . . . o .
« the first rule of tautology club is the first rule of tautology club »


signature.asc
Description: Digital signature

Bug#704950: logrotate: Errors last rotated in the future -- rotation forced

2013-04-08 Thread Paul Martin

On Sun, Apr 07, 2013 at 11:40:17PM -0500, Vincent Lefevre wrote:

 Note that the timezone was changed from Europe/Paris to US/Central
 earlier this day. This may be related. But I'd expect logrotate to
 obviously consider UTC time when comparing dates; if it does, this
 cannot explain the above errors.

Sorry, no.  It uses local time, to match how cron(8) works.

Gandi hosting, perhaps?

-- 
Paul Martin p...@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#701081: debian-policy: mandate an encoding for filenames in binary packages

2013-04-08 Thread Helmut Grohne

On Sat, Apr 06, 2013 at 08:20:15PM +0900, Charles Plessy wrote:
   sec id=filenames
 headingFile names/heading
 
 p
   The name of the files installed by binary packages in the system 
 PATH 
   (namely tt/bin/tt, tt/sbin/tt, tt/usr/bin/tt,
   tt/usr/sbin/tt and tt/usr/games//tt) must be encoded in
   ASCII.
 /p
 
 p
   The name of the files and directories installed by binary packages
   outside the system PATH must be encoded in UTF-8 and should be
   restricted to ASCII when they can be represented in that character
   set.
 /p
   /sec
 
 
 What do you think ?

Thanks to all involved parties for your work on this issue. I am very
much satisfied with the result and happy that it is met with consensus.
The suggestions of Julian Gilbey appear sensible, but do not touch the
general direction.

Helmut


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

Bug#704744: pbuilder: umounts /{dev,run}/shm of the host system

Thorsten Glaser t...@mirbsd.de (07/04/2013):
 reassign 704744 debootstrap
 found 704744 debootstrap/1.0.48
 retitle 704744 debootstrap: umounts /{dev,run}/shm of the *host* system
 thanks

Next time, can you please put the right people in the loop?!

Cc-ing:
 debian-bugs-dist@lists.debian.org

instead of:
  debian-b...@lists.debian.org

is just plain stupid. Maintainers of the package you're reassigning to
don't get your control mail. Way to communicate!

 Dixi quod…
 
 Okay, I just run “sudo env DIST=sid cowbuilder --create” and
 it happened again. I micro-tested this and can point out where:
 
 Nevermind, it’s debootstrap not pbuilder.
 
 I changed to include “set -x”, run “mount | fgrep shm” using
 the DEBUG trap, and commented out the call to debootstrap as
 I had it already… and it kept my shm.
 
 Turns out this looks like being the culprit:
 
 tglase@tglase:~ $ fgrep -ri shm /usr/share/debootstrap/*
 /usr/share/debootstrap/functions:   umount_on_exit /dev/shm
 
 The problem here is:
 
 lrwxrwxrwx 1 root root 8 Apr  8 01:03 
 /var/cache/pbuilder/base.cow-sid/dev/shm - /run/shm/
 
 The symlink is then, of course, followed.
 
 Reassigning this RC bug to debootstrap thusly.
 Sorry folks, but this does break unrelated software.
 
 My idea to fix this is:
 
 Move the “umount_on_exit /dev/shm” line away from
 /usr/share/debootstrap/functions and into the files under
 /usr/share/debootstrap/scripts/ and then change it to use
 /run/shm from wheezy onwards (this also involves breaking
 up the symlink from etch, etch-m68k, lenny, oldstable,
 squeeze and stable to sid, and then, for the wheezy release,
 reintroducing the symlink from stable to sid).
 
 Unless you’ve got a better one, that is.

Well, wild guess, a consequence of the change introduced in
pbuilder/0.215 without actually checking what happens?

Surely, coordinating such a change with debootstrap people would have
been a better idea than implementing it blindly?

Not sure I agree that's an RC bug in debootstrap. I'd rather call it a
wishlist in debootstrap to support the new thing pbuilder imposes, and
an RC bug in pbuilder not to depend on a debootstrap version
implementing said improved behaviour.

Mraw,
KiBi.


signature.asc
Description: Digital signature

Bug#704962: florence: Some buttons words are not showing eg. Shift, Enter, Backspace.

2013-04-08 Thread Jérémy Bobbio

Control: tags -1 + moreinfo

Hi Khurram,

Khurram Mahmood:
 *** Please consider answering these questions, where appropriate ***
 
* What led up to the situation?
* What exactly did you do (or not do) that was effective (or
  ineffective)?
* What was the outcome of this action?
* What outcome did you expect instead?

Could you please answer these questions? I am not sure I understand the
problems you are facing.

-- 
Jérémy Bobbio.''`. 
lu...@debian.org: :Ⓐ  :  # apt-get install anarchism
`. `'` 
  `-   


signature.asc
Description: Digital signature

Bug#674539: ITP: beanstalkc -- beanstalkc is a simple beanstalkd client library for Python

2013-04-08 Thread Apollon Oikonomopoulos

owner 674539 !
tags 674539 pending
thanks

Hi,

after talking with Alex I will be taking over the beanstalkc package in 
a friendly manner. An upload is pending.

Regards,
Apollon


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

Bug#704073: [multipath-tools-boot] error when update-initramfs

2013-04-08 Thread Guy Roussin

 Just to re-confirm, is the actual bug, that was initially reported by
 Guy, is that also resolved?

Yes the bug is resolved. No more errors when update-initramfs -u

Thank you,

-- 
Guy


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

Bug#704580: closed by Jonathan Nieder jrnie...@gmail.com (Bug#704580: fixed in git 1:1.8.2.1-1)

2013-04-08 Thread Helmut Grohne

On Mon, Apr 08, 2013 at 09:06:05AM +, Debian Bug Tracking System wrote:
* debian/README.source: point to git.README.source (thx Helmut
  Grohne; closes: #704580)

Oh, silly me didn't notice the git.README.source. Thanks for quickly
adding the canonical location.

Helmut


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

Bug#704963: Odd output in xchm

2013-04-08 Thread Mathieu Malaterre

Package: xchm
Version: 2:1.21-1
Severity: normal

It looks like the following chm file is hardly supported by xchm:

$ sudo apt-get install openmcdf
$ xchm /usr/share/OpenMCDF/help/OpenMCDF.chm 

I am getting some weird symbols fonts, and on the shell:

(xchm:17647): Gtk-WARNING **: gtk_widget_size_allocate(): attempt to allocate 
widget with width -5 and height 15

(xchm:17647): Gtk-WARNING **: gtk_widget_size_allocate(): attempt to allocate 
widget with width -5 and height 15

(xchm:17647): Gtk-WARNING **: gtk_widget_size_allocate(): attempt to allocate 
widget with width -5 and height 15

(xchm:17647): Gtk-WARNING **: gtk_widget_size_allocate(): attempt to allocate 
widget with width -5 and height 15

** (xchm:17647): CRITICAL **: clearlooks_style_draw_shadow: assertion `width = 
-1' failed

** (xchm:17647): CRITICAL **: clearlooks_style_draw_shadow: assertion `width = 
-1' failed

(xchm:17647): Gtk-WARNING **: gtk_widget_size_allocate(): attempt to allocate 
widget with width -5 and height 15

** (xchm:17647): CRITICAL **: clearlooks_style_draw_shadow: assertion `height 
= -1' failed


Thanks

-- System Information:
Debian Release: 6.0.7
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable'), (200, 'testing'), (100, 
'unstable')
Architecture: amd64 (x86_64)

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

Versions of packages xchm depends on:
ii  libc6  2.11.3-4  Embedded GNU C Library: Shared lib
ii  libchm12:0.40-3  library for dealing with Microsoft
ii  libgcc11:4.4.5-8 GCC support library
ii  libstdc++6 4.4.5-8   The GNU Standard C++ Library v3
ii  libwxbase2.8-0 2.8.10.1-3+b1 wxBase library (runtime) - non-GUI
ii  libwxgtk2.8-0  2.8.10.1-3+b1 wxWidgets Cross-platform C++ GUI t

xchm recommends no packages.

xchm 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#704964: grub-pc: GRUB-2 does not handle /dev/disk/by-path/*

2013-04-08 Thread Kyle Moffett

Package: grub-pc
Version: 1.99-27
Severity: important
Tags: upstream

As far as I can tell, GRUB-2 doesn't support any kind of symlinks to
/dev/sd*, such as /dev/disk/by-path/*

Specifically, consider the following setup:

* GRUB Root:  /boot/pci-:07:00.0-sas-0x12210300-lun-0
  (AKA: /dev/disk/by-path/pci-:07:00.0-sas-0x1221-lun-0-part1)

* Boot partition:  /boot
  (AKA: /dev/disk/by-path/pci-:07:00.0-sas-0x1221-lun-0-part2)

* Symlinks:
/boot/pci-:07:00.0-sas-0x12210300-lun-0/boot = .
/boot/pci-:07:00.0-sas-0x12210300-lun-0/grub = .

* Device mapping ($GRUB_ROOT/device.map):
(hd0) /dev/disk/by-path/pci-:07:00.0-sas-0x1221-lun-0
(hd1) /dev/disk/by-path/pci-:07:00.0-sas-0x12210100-lun-0
(hd2) /dev/disk/by-path/pci-:07:00.0-sas-0x12210200-lun-0
(hd3) /dev/disk/by-path/pci-:07:00.0-sas-0x12210300-lun-0

* Auto-generated GRUB-2 config file ($GRUB_ROOT/grub.cfg), whose
  actual contents are irrelevant, but which loads GRUB modules from
  the first partition and kernels/initrds from the second partition.

* Valid device symlinks from udev:
/dev/disk/by-path/pci-:07:00.0-sas-0x12210300-lun-0 = ../../sde
/dev/disk/by-path/pci-:07:00.0-sas-0x12210300-lun-0-part1 = 
../../sde1
/dev/disk/by-path/pci-:07:00.0-sas-0x12210300-lun-0-part2 = 
../../sde2
/dev/disk/by-path/pci-:07:00.0-sas-0x12210300-lun-0-part3 = 
../../sde3
/dev/disk/by-path/pci-:07:00.0-sas-0x12210300-lun-0-part4 = 
../../sde4


Now, with that set up, I run:
  grub-install --no-floppy \
--root-directory=/boot/pci-:07:00.0-sas-0x12210300-lun-0 \
/dev/disk/by-path/pci-:07:00.0-sas-0x12210300-lun-0

And it dies with an error:
  /usr/sbin/grub-probe: error: cannot find a GRUB drive for
/dev/disk/by-path/pci-:07:00.0-sas-0x12210300-lun-0.
Check your device.map.

If I edit the device.map file and replace it with /dev/sde (which it
is a symlink to, by the way), then run:
  grub-install --no-floppy \
--root-directory=/boot/pci-:07:00.0-sas-0x12210300-lun-0 \
/dev/disk/by-path/pci-:07:00.0-sas-0x12210300-lun-0
/dev/sde
 
Then it works flawlessly.  Unfortunately, this is not useful because
those device names change on boot, depending on whether or not I have
USB devices attached to the system.

Even worse, with my configs:
  grub-probe -m /boot/pci-\:07\:00.0-sas-0x12210300-lun-0 \
 -t drive '(hd3)'
  Segmentation fault

Cheers,
Kyle Moffett


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

Bug#691449: Improve dpkg-buildflags manpage

2013-04-08 Thread Jonathan Nieder

Guillem Jover wrote:

 Ok, I've merged these two patches with some modifications

Looks good.  Thanks for taking care of it.

Regards,
Jonathan


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

Bug#704413: UDD: Debian Maintainer Dashboard improvements

2013-04-08 Thread Prach Pongpanich

Hi Lucas,

On Thu, Apr 4, 2013 at 9:19 PM, Lucas Nussbaum lu...@debian.org wrote:

 I don't understand your patch. actually, looking at the DMD code now,
 I'm wondering if this was not fixed already. the code you patched was
 already correctly distinguishing unstable and experimental status.

 What was the goal of your patch?


This patch's purpose does't show  new upstream version available, if
already in experimental.

Regrads,

-- 

 Prach Pongpanich


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

Bug#704815: Would it be possible to reenable CONFIG_ACPID

2013-04-08 Thread Guido Trotter

On Mon, Apr 8, 2013 at 8:30 AM, Michael Tokarev m...@tls.msk.ru wrote:
 06.04.2013 16:02, Guido Trotter wrote:
 On Sat, Apr 6, 2013 at 11:05 AM, Michael Tokarev m...@tls.msk.ru wrote:
 06.04.2013 12:56, Guido Trotter wrote:
 Package: busybox-static

 I know that acpid was disabled on purpose, but would it be possible to
 reenable it? It is useful on VMs running with busybox only, for example.

 For many years, i've the following replacement for acpid:
 []
 while read x  /proc/acpi/event; do
 []
 CONFIG_ACPI_PROC_EVENT is deprecated and unset in most modern kernels

 I know it's been deprecated, but I always used local builds of kernel
 (together with my initramfs and a few other infrastructure), so I
 didn't know it's been turned off.  That's a pity.

 (I know, I can always build my own kernel, but then again, I could
 also build busybox, so that defeats the purpose). acpid in busybox can
 read /dev/input/event* and at least under Xen does the right thing
 (shuts down the system, with the proper config).

 Do you aware that any keyboard/mouse/etc event will be read by acpid
 using this /dev/input/event* interface?  That was my main complain
 when this interface has been introduced - there's no way to filter
 out things to stop kernel to wake all readers for every and all input
 event even if 99.99% the readers aren't interested in it.  At least
 acpid can be a bit smarter and only open those devices which actually
 provide buttons we're interested in, like pwrbtn/lidbtn, instead of
 reading every mouse and force-feedback device out there.  Oh well.


Is there a way to find out which event provides what?
Right now acpid in busybox can only open all of them, or a single
socket which expects the old format (and segfaults on the new one,
sic). So perhaps there can be a few upstream bugs to ask to:
1) not segfault when the wrong protocol is used (segfaulting is never nice)
2) ability to filter which event* to open

 Fortunately it might be not as bad for a VM where you don't work at
 the console.

 But this is just, well, complaining, I understand that the whole
 (linux) world already works like that.

Indeed, but I'm sure busybox acpi can be improved as well, by
upstream, if we ask nicely. :)
(Or by us, having time, it seems easy c code).

 Is it not sufficient for you?

 If you talk about VMs, I found it is much easier to use Ctrl+Alt+Del
 from inittab to signal shutdown, and don't bother with acpi at all.
 For this to work, just change cad action in /etc/inittab to do
 power down instead of reboot.

 Under kvm I can always go for the ctrl+alt+del option you suggest,
 but that still requires special knowledge that the machine does the
 right thing, while acpi is supposed to be more standard. Anyway I am
 not sure I could easily do that under Xen too.

 I see.  This, together with ACPI_PROC_EVENT, are both good points.

 As for enabling this applet for wheezy, it definitely is not possible
 at this time because of the freeze.

 Understood, I only mentioned it because it was enabled in squeeze
 before, but then again probably busybox is too important to allow
 exceptions. Well, maybe it can still be discussed and updated in
 wheezy+1 and backports, perhaps?

 Backports - sure.  For wheezy, I'll have to explain to the release
 team why fixing this bugreport is important for wheezy, and I'm
 afraid I can't do that even to myself ;)


No problem at all, backports is perfect for me.

 Your usage is very specific.  There's absolutely no reason why it
 should be forbidden, obviously, and I will, most likely, turn this
 options back on for jessie - for both regular and static builds -
 but this wont be for wheezy.  I'm sorry to say that.

 Thank you for the feedback and the bugreport!  Seriously, it is
 always nice to know which applets people use for real and which
 are dummies.


Thanks a lot for your packaging work and your responsiveness!

Guido


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

Bug#677968: Fwd: Re: Log for attempted build of cpl_6.1.1-2 on m68k (dist=unstable)

2013-04-08 Thread Ole Streicher

 Original-Nachricht 
Betreff: Re: Log for attempted build of cpl_6.1.1-2 on m68k (dist=unstable)
Datum: Sun, 7 Apr 2013 12:32:11 + (UTC)
Von: Thorsten Glaser t...@mirbsd.de
An: deb...@liska.ath.cx, debian-science-maintain...@lists.alioth.debian.org

fail

/bin/bash: line 5: 21442 Segmentation fault  MAKE=make CC=gcc
CFLAGS=-D_LARGEFILE_SOURCE=1 -D_FILE_OFFSET_BITS=64 -D_REENTRANT -g -O2
-fstack-protector --param=ssp-buffer-size=4 -Wformat
-Werror=format-security -std=c99 -fno-builtin -fno-common -fopenmp
CPPFLAGS=-D_FORTIFY_SOURCE=2 -D_POSIX_C_SOURCE=200112L
LD=/usr/bin/ld LDFLAGS=-Wl,-z,relro -fopenmp LIBS=-lm -lgomp -ldl
-lnsl LN_S=ln -s NM=/usr/bin/nm -B RANLIB=ranlib OBJEXT=o
EXEEXT= ${dir}$tst
FAIL: cpl_polynomial-test

/bin/bash: line 5: 21605 Segmentation fault  MAKE=make CC=gcc
CFLAGS=-D_LARGEFILE_SOURCE=1 -D_FILE_OFFSET_BITS=64 -D_REENTRANT -g -O2
-fstack-protector --param=ssp-buffer-size=4 -Wformat
-Werror=format-security -std=c99 -fno-builtin -fno-common -fopenmp
CPPFLAGS=-D_FORTIFY_SOURCE=2 -D_POSIX_C_SOURCE=200112L
LD=/usr/bin/ld LDFLAGS=-Wl,-z,relro -fopenmp LIBS=-lm -lgomp -ldl
-lnsl LN_S=ln -s NM=/usr/bin/nm -B RANLIB=ranlib OBJEXT=o
EXEEXT= ${dir}$tst
FAIL: cpl_matrix-test

2 of 28 tests failed
probably #677968


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

Bug#688100: unblock: fglrx-driver/1:12-6+point-3

2013-04-08 Thread Andreas Beckmann

On 2013-02-16 20:59, Andreas Beckmann wrote:
 On 2012-12-02 22:17, Andreas Beckmann wrote:
 On 2012-12-02 21:37, Michael Gilbert wrote:
 The package in wheezy contains incorrect (outdated) information w.r.t.
 to support for legacy hardware (as it was written before AMD released
 the beta driver) and is therefore misleading the users on upgrades.

 There are also some (partial) upgrade issues with the 32-bit stuff on amd64

 Could you implement those fixes as a minimal tpu?

 I don't see any non-documentation change that would be worth stripping
 out from -2/-3 without reintroducing some bug.
 
 Ping.
 
 I still think that wheezy would be served much better with 1:12-6+point-3

Ping.

There was recently some discussion about this in
  Bug#704565: release-notes: warning for fglrx-driver users
and having -3 in wheezy should improve that situation as well.


Andreas


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

Bug#704413: UDD: Debian Maintainer Dashboard improvements

2013-04-08 Thread Lucas Nussbaum

On 08/04/13 at 16:36 +0700, Prach Pongpanich wrote:
 Hi Lucas,
 
 On Thu, Apr 4, 2013 at 9:19 PM, Lucas Nussbaum lu...@debian.org wrote:
 
  I don't understand your patch. actually, looking at the DMD code now,
  I'm wondering if this was not fixed already. the code you patched was
  already correctly distinguishing unstable and experimental status.
 
  What was the goal of your patch?
 
 
 This patch's purpose does't show  new upstream version available, if
 already in experimental.

but currently it shows new upstream version available:
#{v['upstream'][:version]} (already in experimental, but not in
unstable).
I think that's fine, no?

Lucas


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

Bug#704964: Fwd: grub-pc: GRUB-2 does not handle /dev/disk/by-path/*

2013-04-08 Thread Kyle Moffett

On Mon, Apr 8, 2013 at 2:24 AM, Kyle Moffett k...@moffetthome.net wrote:
 If I edit the device.map file and replace it with /dev/sde (which it
 is a symlink to, by the way), then run:
   grub-install --no-floppy \
 --root-directory=/boot/pci-:07:00.0-sas-0x12210300-lun-0 \
 /dev/sde

Actually, I don't even have to edit device.map.  I just have to give
it the non-symlink path on the command-line and it works fine.

I guess grub just needs an extra realpath() in there somewhere?

Cheers,
Kyle Moffett


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

Bug#696385: RFS: astromenace/1.3.1+ds-1 [ITP] -- hardcore 3D space shooter with spaceship upgrade possibilities

2013-04-08 Thread Thibaut Paumard

Le 07/04/2013 23:52, Boris Pek a écrit :
 Hi Thibaut,
 
 I have updated packages astromenace and astromenace-data. Now all issues
 should be solved.
 
 Links for download:
   
 http://mentors.debian.net/debian/pool/contrib/a/astromenace/astromenace_1.3.1+ds-1.dsc
   
 http://mentors.debian.net/debian/pool/non-free/a/astromenace-data/astromenace-data_1.3.1+ds-1.dsc
 
 Git repos:
   http://anonscm.debian.org/gitweb/?p=pkg-games/astromenace.git
   http://anonscm.debian.org/gitweb/?p=pkg-games/astromenace-data.git
 
 Please have in mind that `cp AstroMenace AstroMenaceFS2VFS` in debian/rules in
 package astromenace is temporary. As you can see in SVN repo [1], special
 separate utility AstroMenaceFS2VFS will be available in next release. But new
 version of program will be released only at summer.
 
 [1] http://sourceforge.net/p/openastromenace/code/261/#diff-8
 
 Best regards,
 Boris


Hi Boris,

We are almost there, but not quite.

Just thinking aloud: the problem with the current scheme is that the
game data file will be present twice in the user system: on real FS and
in VFS. That could be avoided only by copying the fonts in
astromenace-data source, so I guess we'll have to live with that. I'm
wondering whether you could ship the data in a tar.xz archive to at
least save some space?

At least you could avoid duplicating AstroMenace as AstroMenaceFS2VFS:
simply move the postinst/prerm logic in astromenace instead of
astromenace-data. Note that as is, AstroMenace indirectly depends on
AstroMenaceFS2VFS, so you get the two exact same executables twice on
the system. Or you could make AstroMenace a link pointing to
AstroMenaceFS2VFS for the time being.

Typo in astromenace's control:
 - you can skip the line This package contains game executable file.
If you keep it, you need an article in front of game: the game...
 - This package contains utility which generates AstroMenace date
file.: date - data. Here again, you're missing an article: a utility
or the utility.

Thanks for you continued efforts.

Kind regards, Thibaut.



signature.asc
Description: OpenPGP digital signature

Bug#704650: Gem2deb should read uploader email from a variable

2013-04-08 Thread Praveen A

2013/4/5 Antonio Terceiro terce...@debian.org:
 Control: tag -1 + unreproducible

 On Thu, Apr 04, 2013 at 05:12:02PM +0530, Praveen A wrote:
 2013/4/4 Ondřej Surý ond...@sury.org:
  Version: 0.3.0
 
  gem2deb does correctly use DEBEMAIL and DEBFULLNAME (same with other Debian
  tools).

 I just tested it again now, and it does not fill Uploaders field in
 debian/control or changed by line in debian/changelog

 I works for me as well.

 Can you reproduce the problem in a clean environment (i.e. a clean user
 account, or a clean chroot)?

hmm it is working in a clean chroot. Does environment variables have
highest priority or does it gets overridden by some configuration
files?

--
പ്രവീണ്‍ അരിമ്പ്രത്തൊടിയില്‍
You have to keep reminding your government that you don't get your
rights from them; you give them permission to rule, only so long as
they follow the rules: laws and constitution.


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

Bug#704565: release-notes: warning for fglrx-driver users

2013-04-08 Thread Andreas Beckmann

On 2013-04-07 21:18, Julien Cristau wrote:
 On Wed, Apr  3, 2013 at 09:59:38 +0900, Hideki Yamane wrote:
  Upgrading from Squeeze to Wheezy with fglrx-driver will break their 
  graphical environment since fglrx upstream dropped such old video card
  support from it, and now package maintainers provide such legacy support
  as fglrx-legacy-driver package(*).

 Sounds to me like fglrx should fix up the xorg config on upgrade on
 hardware it doesn't support anymore...

Fixing up a config that was created by the user (fglrx-driver never
creates xorg.conf, users usually use aticonfig) is not an easy thing.

But the wheezy version does display a debconf error giving hints and
instructions upon upgrades if unsupported hardware is found (and the sid
version, see unblock #688100, also mentions the availability of the
legacy driver.)

The wheezy and sid versions also display a debconf error if the package
is being removed, but still enabled in xorg.conf(.d).

So noone should run into problems w.r.t. fglrx without having seen a
warning.


Andreas


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

Bug#704949: [Openstack-devel] Bug#704949: Bug#704949: cinder: [debconf_rewrite] Debconf templates and debian/control review proposal

2013-04-08 Thread Thomas Goirand

On Mon Apr   8 2013 04:39:10 PM CST, Christian PERRIER bubu...@debian.org 
wrote:

 Quoting Thomas Goirand (z...@debian.org):
 
  So, in all of the above packages, we have a huge redundancy in
  templates. I thought that best would be to have a system to avoid this
  redundancy, like having a package holding (most of) the templates, and
  we would do dynamic replacements of variables. This way, translations
  would need to happen only once, which would be a very good thing.
 
 That seems to be a good idea, at first glance. Something like
 openstack-debconfig, or openstack-config.
 
 Using dbconfig-common for all database-related stuff is also a good
 idea. I'm not sure how well it is maintained but it's anyway better
 than reinventing the very same templates to prompt users about
 databases, database users, password, etc.

Yeah, we use it already for all packages that need
a db!

 You mention you have concerns about itthey probably come because
 the package is not that actively maintained, I'm afraid.

You missunderstood me. I have no problem to actualy
*use* dbconfig-common, I have problems to read its
code as an example, and would like to find something
more easy to understand.

So, do you have another package in mind which I
could use as an example?

 Sure. Let's hold the translation effort as of now. My recommendation
 would be to make templates non translatable (drop the leading _) in
 the meantime, so that cinder moves away from our radar (having too
 many packages in a kinda pending state doesn't help tracking down
 stuff).

I think I will reupload it in Experimental and ask
for its removal from SID in fact. This wouldn't be
the only reason why I would ask that in fact.

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#704965: Segmentation fault when opening Views - Categorical Browser

2013-04-08 Thread Marco

Package: aptitude
Version: 0.6.8.2-1
Severity: normal

Dear Maintainer,

   * What led up to the situation?

Selecting a particular menu item.

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

Run aptitude as normal user. Then open the menu Views → New Categorical
Browser

   * What was the outcome of this action?

Ouch!  Got SIGSEGV, dying..

   * What outcome did you expect instead?

No segmentation fault and a new browser window.



-- Package-specific info:
$TERM not set.
$DISPLAY is set.
which aptitude: /usr/bin/aptitude

aptitude version information:
aptitude 0.6.8.2 compiled at Nov  7 2012 07:08:03
Compiler: g++ 4.7.2
Compiled against:
  apt version 4.12.0
  NCurses version 5.9
  libsigc++ version: 2.2.10
  Ept support enabled.
  Gtk+ support disabled.
  Qt support disabled.

Current library versions:
  NCurses version: ncurses 5.9.20110404
  cwidget version: 0.5.16
  Apt version: 4.12.0

aptitude linkage:
linux-vdso.so.1 =  (0x7bbc8000)
libapt-pkg.so.4.12 = /usr/lib/x86_64-linux-gnu/libapt-pkg.so.4.12 
(0x7fbc38107000)
libncursesw.so.5 = /lib/x86_64-linux-gnu/libncursesw.so.5 
(0x7fbc37ed7000)
libtinfo.so.5 = /lib/x86_64-linux-gnu/libtinfo.so.5 
(0x7fbc37cad000)
libsigc-2.0.so.0 = /usr/lib/x86_64-linux-gnu/libsigc-2.0.so.0 
(0x7fbc37aa8000)
libcwidget.so.3 = /usr/lib/libcwidget.so.3 (0x7fbc377a8000)
libept.so.1.aptpkg4.12 = /usr/lib/libept.so.1.aptpkg4.12 
(0x7fbc37507000)
libxapian.so.22 = /usr/lib/libxapian.so.22 (0x7fbc37122000)
libz.so.1 = /lib/x86_64-linux-gnu/libz.so.1 (0x7fbc36f0b000)
libsqlite3.so.0 = /usr/lib/x86_64-linux-gnu/libsqlite3.so.0 
(0x7fbc36c5b000)
libboost_iostreams.so.1.49.0 = /usr/lib/libboost_iostreams.so.1.49.0 
(0x7fbc36c4)
libpthread.so.0 = /lib/x86_64-linux-gnu/libpthread.so.0 
(0x7fbc36a24000)
libstdc++.so.6 = /usr/lib/x86_64-linux-gnu/libstdc++.so.6 
(0x7fbc3671c000)
libm.so.6 = /lib/x86_64-linux-gnu/libm.so.6 (0x7fbc3649a000)
libgcc_s.so.1 = /lib/x86_64-linux-gnu/libgcc_s.so.1 
(0x7fbc36284000)
libc.so.6 = /lib/x86_64-linux-gnu/libc.so.6 (0x7fbc35ef9000)
libutil.so.1 = /lib/x86_64-linux-gnu/libutil.so.1 (0x7fbc35cf6000)
libdl.so.2 = /lib/x86_64-linux-gnu/libdl.so.2 (0x7fbc35af2000)
libbz2.so.1.0 = /lib/x86_64-linux-gnu/libbz2.so.1.0 
(0x7fbc358e1000)
libuuid.so.1 = /lib/x86_64-linux-gnu/libuuid.so.1 (0x7fbc356dc000)
librt.so.1 = /lib/x86_64-linux-gnu/librt.so.1 (0x7fbc354d3000)
/lib64/ld-linux-x86-64.so.2 (0x7fbc38aa2000)

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

Kernel: Linux 3.8.0-rc7 (SMP w/4 CPU cores)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages aptitude depends on:
ii  aptitude-common   0.6.8.2-1
ii  libapt-pkg4.120.9.7.8
ii  libboost-iostreams1.49.0  1.49.0-3.2
ii  libc6 2.13-38
ii  libcwidget3   0.5.16-3.4
ii  libept1.4.12  1.0.9
ii  libgcc1   1:4.7.2-5
ii  libncursesw5  5.9-10
ii  libsigc++-2.0-0c2a2.2.10-0.2
ii  libsqlite3-0  3.7.16.1-1
ii  libstdc++64.7.2-5
ii  libtinfo5 5.9-10
ii  libxapian22   1.2.12-2
ii  zlib1g1:1.2.7.dfsg-13

Versions of packages aptitude recommends:
ii  apt-xapian-index0.45
pn  aptitude-doc-en | aptitude-doc  none
pn  libparse-debianchangelog-perl   none
ii  sensible-utils  0.0.7

Versions of packages aptitude suggests:
pn  debtags  none
ii  tasksel  3.14+nmu1

-- 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#657627: Improve dpkg-buildflags manpage

2013-04-08 Thread Matthijs Kooijman

  Ok, I've merged these two patches with some modifications
 
 Looks good.  Thanks for taking care of it.
They look good to me too. Thanks for spotting the small details I missed
:-)

Gr.

Matthijs


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

Bug#704197: Please review: systemd checks

2013-04-08 Thread Niels Thykier

On 2013-04-06 20:44, Michael Stapelberg wrote:
 Hi Niels,
 
 Niels Thykier ni...@thykier.net writes:
 I think you are missing a return here?
 Indeed, thanks.
 
 New files are attached, here is the list of things that I know need to
 be fixed:
 
 1) We don’t have any documentation references in the .desc file yet.
 2) I need to switch to lab_data_path in check_maintainer_scripts().
 
 Could you please also say a few words on how the usual inclusion process
 works? I.e., what are the next steps after there are no more things left
 to fix?

Tests!  Once there are tests for all the new tags (and none of the
existing tests breaks) we are usually ready to accept the checks.

On test writing:  We don't have a tutorial for writing tests atm.  There
is a bit of help (although a bit outdated) in t/tests/README.

To give you a rough idea of what you are working with, a test case in
t/tests basically follows this pattern:

 mkdir -p rundir/test/
 rsync t/templates/tests/skel/ rundir/test/
 # note t/tests/testcase/debian/ is the root of the source package
 # thus, t/tests/testcase/debian/debian/ is the debian dir.
 rsync t/tests/testcase/debian/ rundir/test/

 for file in changelog control ; do
subst rundir/test/debian/${file}.in  rundir/test/debian/${file}
 done

 cd rundir/test  dpkg-buildpackage -us -uc
 lintian -IE rundir/*.changes | sort  actual
 diff -u t/tests/testcase/tags actual

The test should be named after the check (i.e. systemd-name in this
case) and have a sequence of 6000 (in t/tests/testcase/desc).  A
template for the desc:

  Testname: name of test
  Sequence: 6000
  Description: 1-line description
  Test-For:
   tag1
   tag2

Note: Testname must match the (base)name of the directory[1].  The
description will always be used as synopsis for the package (so it
should follow the same rules).  There are more fields you can use (see
t/tests/README).
  If you want to test for false-positives, replace Test-For with
Test-Against[2].

The full test suite takes over 30 minutes (user time).  Have a look at
Lintian::Tutorial::TestSuite to run only the tests you need while you
work on the tests/check[3].  When you are done, please do a full run of
all tests.  Some of the other tests do some funny checks that may
trigger bugs in your check[4].
  If the full test suite is too heavy for your machine (my laptop
doesn't like it either), just let me know and I will do the run for you.


 Also, do I need to mark the checks as experimental because they are new?
 

Depends on your level of confidence in your tags and how well-defined
the problem is[5].  Most tags never had the experimental marker on them.

~Niels

[1] Not checked, but can cause hard to debug test failures...
especially if it matches the name of another test (copy-waste ftl).

[2] Test-For requires the test to emit the tag for it to pass.
Test-Against causes it to fail unconditionally if the tag was emitted.
Both fields may be used at the same time.

[3] To test your check for syntax errors (etc.), you may want to run:

  debian/rules onlyrun=check-load

After that:

  debian/rules onlyrun=testcase
  debian/rules onlyrun=check
  debian/rules onlyrun=suite:scripts

When they pass, you might be ready for the full test suite.  If you got
cores to spare, throw a DEB_BUILD_OPTIONS=parallel=n.

[4] e.g. suite:debs builds some really interesting debs. The legacy test
filenames also got some fun filenames in it.

[5] If there are a lot of corner cases (etc.), the check may need
several iterations to mature.


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

Bug#704966: ruby-systemtimer: unusable with ruby1.9 but partially installed as cross-version library

2013-04-08 Thread duck


Package: ruby-systemtimer
Version: 1.2.3-2


Coin,

I did not realize this library was 1.8-only, but instead of being 
unknown to the 1.9 interpreter, it just looks like broken:

require 'system_timer'

LoadError: cannot load such file -- system_timer_native

While system_timer_native.so is installed in 
/usr/lib/ruby/vendor_ruby/1.8, other files are installed in the parent 
directory available to all Ruby version. I think they should be moved in 
the 1.8 directory.


Regards.

--
Marc Dequènes


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

Bug#704413: UDD: Debian Maintainer Dashboard improvements

2013-04-08 Thread Prach Pongpanich

On Mon, Apr 8, 2013 at 4:46 PM, Lucas Nussbaum lu...@debian.org wrote:
 but currently it shows new upstream version available:
 #{v['upstream'][:version]} (already in experimental, but not in
 unstable).
 I think that's fine, no?

 Lucas

In my opinion, TODO list don't show a new upstream version, if it's
already in experimental.

-- 
 Prach Pongpanich


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

Bug#704968: O: ispell-lt -- ispell dictionary for Lithuanian (LT)

Package: wnpp
Severity: normal

The current maintainer of ispell-lt, Kęstutis Biliūnas ke...@kaunas.init.lt,
is apparently not active anymore.  Therefore, I orphan this package now.

Maintaining a package requires time and skills. Please only adopt this
package if you will have enough time and attention to work on it.

If you want to be the new maintainer, please see
http://www.debian.org/devel/wnpp/index.html#howto-o for detailed
instructions how to adopt a package properly.

Some information about this package:

Package: ispell-lt
Binary: ilithuanian, myspell-lt, aspell-lt, openoffice.org-hyphenation-lt
Version: 1.2.1-3.1
Maintainer: Kęstutis Biliūnas ke...@kaunas.init.lt
Build-Depends: debhelper ( 7.0.0)
Build-Depends-Indep: locales, dictionaries-common-dev (= 1.11.2), ispell, 
python (= 2.3), aspell (= 0.60.3-2)
Architecture: all
Standards-Version: 3.8.3
Format: 3.0 (quilt)
Files:
 a664257f92bbb88715b6374bcd7ab872 1346 ispell-lt_1.2.1-3.1.dsc
 538b3e3d35a87397233f18027180eff8 577981 ispell-lt_1.2.1.orig.tar.gz
 2b03e598670e45b91dca4a771874ae9e 27942 ispell-lt_1.2.1-3.1.debian.tar.gz
Dm-Upload-Allowed: yes
Checksums-Sha1:
 6bc6fb84438d2c49eac063bbb35d1085321f61ea 1346 ispell-lt_1.2.1-3.1.dsc
 9b6273153f87586e29dc52b57542717f9b98563f 577981 ispell-lt_1.2.1.orig.tar.gz
 64a729622248669d3ee2a3585d73662938a5f68c 27942 
ispell-lt_1.2.1-3.1.debian.tar.gz
Checksums-Sha256:
 6e9e847fb88f55b42f22fc981ecee37c2529772df927c019f8e39bdcb3ea668b 1346 
ispell-lt_1.2.1-3.1.dsc
 41ef2f33eb7163ec9cf3a3a6cdd9f3a2f179d91d1dc8b16d7abb1ff65bfe13fa 577981 
ispell-lt_1.2.1.orig.tar.gz
 3a7ad8c3987d7ca1d55aea2db372786bf168a2aa6d0ccd8e7ca078d13667ace2 27942 
ispell-lt_1.2.1-3.1.debian.tar.gz
Package-List: 
 aspell-lt deb text optional
 ilithuanian deb text optional
 myspell-lt deb text optional
 openoffice.org-hyphenation-lt deb text optional
Directory: pool/main/i/ispell-lt
Priority: source
Section: text

Package: ilithuanian
Source: ispell-lt
Version: 1.2.1-3.1
Installed-Size: 546
Maintainer: Kęstutis Biliūnas ke...@kaunas.init.lt
Architecture: all
Provides: ispell-dictionary
Depends: debconf (= 0.5) | debconf-2.0, ispell, dictionaries-common (= 0.25)
Conflicts: ispell ( 3.1.18-2)
Description-en: ispell dictionary for Lithuanian (LT)
 This is the Lithuanian dictionary, to be used with ispell
 to check and correct spelling in Lithuanian texts.
Description-md5: 234999fd9d308a0b956a37e56a9ca06a
Tag: culture::TODO, made-of::dictionary, role::app-data, use::checking
Section: text
Priority: optional
Filename: pool/main/i/ispell-lt/ilithuanian_1.2.1-3.1_all.deb
Size: 383626
MD5sum: 27ad745e5af344a939024733a19a75fe
SHA1: e09d9bb4f91a9d10c539f852bffcaea5ec6f6e07
SHA256: 9c2dc9b1053cbb311bb611db12759e8202f50c35cb965b050d2e05eb6809f2e3

Package: myspell-lt
Source: ispell-lt
Version: 1.2.1-3.1
Installed-Size: 1401
Maintainer: Kęstutis Biliūnas ke...@kaunas.init.lt
Architecture: all
Provides: myspell-dictionary, myspell-dictionary-lt
Depends: dictionaries-common (= 0.10) | openoffice.org-updatedicts
Conflicts: openoffice.org (= 1.0.3-2)
Description-en: myspell dictionary for Lithuanian (LT)
 This is the Lithuanian dictionary for  use with the myspell
 spellchecker which is currently used within OpenOffice.org
 and the mozilla spellchecker.
Description-md5: 346973dc2246f468f7fa08afec8f19c1
Tag: culture::lithuanian, made-of::dictionary, role::app-data, use::checking
Section: text
Priority: optional
Filename: pool/main/i/ispell-lt/myspell-lt_1.2.1-3.1_all.deb
Size: 376664
MD5sum: 05ae981fd136b505f02de36e4220c037
SHA1: 4f664d771392e5b716d16715bf9ee4607529a1ae
SHA256: 4ec66f8e90722cdf81ab8411a55ea45c321b33e825f7c54899f60ce42c9f1a98

Package: aspell-lt
Source: ispell-lt
Version: 1.2.1-3.1
Installed-Size: 480
Maintainer: Kęstutis Biliūnas ke...@kaunas.init.lt
Architecture: all
Provides: aspell-dictionary
Depends: dictionaries-common (= 0.50), aspell (= 0.60.3-2)
Description-en: aspell dictionary for Lithuanian (LT)
 This package contains all the required files to add support for Lithuanian
 language to the GNU Aspell spell checker.
Description-md5: 6c51f0dac54c00ecc9a5713716c74849
Tag: culture::lithuanian, made-of::dictionary, role::app-data, suite::gnu,
 use::checking
Section: text
Priority: optional
Filename: pool/main/i/ispell-lt/aspell-lt_1.2.1-3.1_all.deb
Size: 302320
MD5sum: b1dcaaf913a7187585d238d951b4cff8
SHA1: e1e7314b460c2a5b795d3e26492eda749558b854
SHA256: 7cf2a0d61c59e49f91c7b04e12f8b5867d87c544f163bb009c9bda5e0e40cec8

Package: openoffice.org-hyphenation-lt
Source: ispell-lt
Version: 1.2.1-3.1
Installed-Size: 69
Maintainer: Kęstutis Biliūnas ke...@kaunas.init.lt
Architecture: all
Provides: openoffice.org-hyphenation
Depends: dictionaries-common (= 0.10) | openoffice.org-updatedicts
Recommends: openoffice.org (= 1.1.4) | openoffice.org-writer
Description-en: Lithuanian hyphenation pattern for OpenOffice.org
 This is the Lithuanian hyphenation pattern for use with OpenOffice.org
Description-md5: 26d08b72c6af42ab7d0fe4e721686b4a
Tag:

Bug#704967: O: freedict -- Dict package for Afrikaans-German Freedict dictionary

Package: wnpp
Severity: normal

The current maintainer of freedict, Kęstutis Biliūnas ke...@kaunas.init.lt,
is apparently not active anymore.  Therefore, I orphan this package now.

Maintaining a package requires time and skills. Please only adopt this
package if you will have enough time and attention to work on it.

If you want to be the new maintainer, please see
http://www.debian.org/devel/wnpp/index.html#howto-o for detailed
instructions how to adopt a package properly.

Some information about this package:

Package: freedict
Binary: dict-freedict-afr-deu, dict-freedict-cro-eng, dict-freedict-cze-eng, 
dict-freedict-dan-eng, dict-freedict-deu-eng, dict-freedict-deu-fra, 
dict-freedict-deu-ita, dict-freedict-deu-nld, dict-freedict-deu-por, 
dict-freedict-eng-ara, dict-freedict-eng-cro, dict-freedict-eng-cze, 
dict-freedict-eng-deu, dict-freedict-eng-fra, dict-freedict-eng-hin, 
dict-freedict-eng-hun, dict-freedict-eng-iri, dict-freedict-eng-ita, 
dict-freedict-eng-lat, dict-freedict-eng-nld, dict-freedict-eng-por, 
dict-freedict-eng-rom, dict-freedict-eng-rus, dict-freedict-eng-scr, 
dict-freedict-eng-spa, dict-freedict-eng-swa, dict-freedict-eng-swe, 
dict-freedict-eng-tur, dict-freedict-eng-wel, dict-freedict-fra-deu, 
dict-freedict-fra-eng, dict-freedict-fra-nld, dict-freedict-hin-eng, 
dict-freedict-hun-eng, dict-freedict-iri-eng, dict-freedict-ita-deu, 
dict-freedict-ita-eng, dict-freedict-jpn-deu, dict-freedict-lat-deu, 
dict-freedict-lat-eng, dict-freedict-nld-deu, dict-freedict-nld-eng, 
dict-freedict-nld-fra, dict-freedict-por-deu, dict-freedict-por-eng, 
dict-freedict-gla-deu, dict-freedict-scr-eng, dict-freedict-slo-eng, 
dict-freedict-spa-eng, dict-freedict-swa-eng, dict-freedict-swe-eng, 
dict-freedict-tur-deu, dict-freedict-tur-eng, dict-freedict-wel-eng
Version: 1.3-4
Maintainer: Kęstutis Biliūnas ke...@kaunas.init.lt
Build-Depends: debhelper ( 5.0.0)
Build-Depends-Indep: dictfmt ( 1.10.0), dictzip
Architecture: all
Standards-Version: 3.7.3
Format: 1.0
Files:
 18bc3be72a6fd94c344dcc506fa8de34 1886 freedict_1.3-4.dsc
 753646d800762d8b5f49c5e56809b3e7 32036518 freedict_1.3.orig.tar.gz
 25eb3579067a509627b27fa92f4cf544 1173597 freedict_1.3-4.diff.gz
Checksums-Sha1:
 1780624ea79ffad79356c3b521308fd0ca57804e 1886 freedict_1.3-4.dsc
 07cb1d23991d6203a757c48f6eb0462ea6b2f3b9 1173597 freedict_1.3-4.diff.gz
 cbc205ca390fbcddf2e291dec4a31f06da303000 32036518 freedict_1.3.orig.tar.gz
Checksums-Sha256:
 a962e8148396424ea087b7c595059567eaac232f9b944ac7fb1f87f7042573d5 1886 
freedict_1.3-4.dsc
 5909fc418c951d1232989d81855d9714dcc2495ab61c7b58099a5c2592d3afd5 1173597 
freedict_1.3-4.diff.gz
 ebfaca9368a4ff050274ee3d6bb5b61a107d359479361624a9976fd2049c04d2 32036518 
freedict_1.3.orig.tar.gz
Homepage: http://freedict.org/
Directory: pool/main/f/freedict
Priority: source
Section: text

Package: dict-freedict-afr-deu
Source: freedict
Version: 1.3-4
Installed-Size: 128
Maintainer: Kęstutis Biliūnas ke...@kaunas.init.lt
Architecture: all
Provides: dictd-dictionary
Suggests: dict | opendict | kdict, dictd | serpento
Description-en: Dict package for Afrikaans-German Freedict dictionary
 This is a package of the Afrikaans-German Freedict dictionary, formatted
 for the dictionary server and client which uses the DICT Protocol.
Homepage: http://freedict.org/
Description-md5: cc8be4ee571db33d528aca447f12ded6
Tag: culture::afrikaans, culture::german, made-of::dictionary,
 role::app-data, use::converting
Section: text
Priority: optional
Filename: pool/main/f/freedict/dict-freedict-afr-deu_1.3-4_all.deb
Size: 84566
MD5sum: 003d10e89f5d0a12d5b6ae04aaa76773
SHA1: 765651a06ca1bf0011ea52e0f5e30053801828f5
SHA256: 1ccd2b32255704994cf5029de4975f5e0d2ba15da5e2e80e86ee05fcd80a43af

Package: dict-freedict-cro-eng
Source: freedict
Version: 1.3-4
Installed-Size: 2836
Maintainer: Kęstutis Biliūnas ke...@kaunas.init.lt
Architecture: all
Provides: dictd-dictionary
Suggests: dict | opendict | kdict, dictd | serpento
Description-en: Dict package for Croatian-English Freedict dictionary
 This is a package of the Croatian-English Freedict dictionary, formatted
 for the dictionary server and client which uses the DICT Protocol.
Homepage: http://freedict.org/
Description-md5: c8bca6b16f88a97e5b9bc1608e929cb6
Tag: culture::TODO, culture::croatian, made-of::dictionary, role::app-data
Section: text
Priority: optional
Filename: pool/main/f/freedict/dict-freedict-cro-eng_1.3-4_all.deb
Size: 1825706
MD5sum: 64daf59739117fad2b2d568792679a69
SHA1: a82c2563b7c70de382843df20c1758c714f0cd4f
SHA256: 018749d32aadd21de57cbdefd5956011dd76b33f94b6309bc7cb773280e5fd6f

Package: dict-freedict-cze-eng
Source: freedict
Version: 1.3-4
Installed-Size: 40
Maintainer: Kęstutis Biliūnas ke...@kaunas.init.lt
Architecture: all
Provides: dictd-dictionary
Suggests: dict | opendict | kdict, dictd | serpento
Description-en: Dict package for Czech-English Freedict dictionary
 This is a package of the Czech-English Freedict dictionary, formatted
 for the dictionary

Bug#704969: O: libuninameslist -- a library of Unicode annotation data (development files)

Package: wnpp
Severity: normal

The current maintainer of libuninameslist, Kęstutis Biliūnas 
ke...@kaunas.init.lt,
is apparently not active anymore.  Therefore, I orphan this package now.

Maintaining a package requires time and skills. Please only adopt this
package if you will have enough time and attention to work on it.

If you want to be the new maintainer, please see
http://www.debian.org/devel/wnpp/index.html#howto-o for detailed
instructions how to adopt a package properly.

Some information about this package:

Package: libuninameslist
Binary: libuninameslist-dev, libuninameslist0
Version: 0.0.20091231-1.1
Maintainer: Kęstutis Biliūnas ke...@kaunas.init.lt
Build-Depends: debhelper (= 7.0.0), autotools-dev, libtool, automake
Architecture: any
Standards-Version: 3.8.3
Format: 3.0 (quilt)
Files:
 76c03cd511300958efb8afd1d22a5775 1918 libuninameslist_0.0.20091231-1.1.dsc
 14f47d50fb0e05c5029298847437feab 568820 
libuninameslist_0.0.20091231.orig.tar.bz2
 15e043a9f04be483c2baf905ef36c909 4584 
libuninameslist_0.0.20091231-1.1.debian.tar.gz
Dm-Upload-Allowed: yes
Checksums-Sha1:
 e9ccfa6487d29c8786429cc55b8674cacabe13dd 1918 
libuninameslist_0.0.20091231-1.1.dsc
 8711f617600a5a975007f8ebdf8047c84f66235f 568820 
libuninameslist_0.0.20091231.orig.tar.bz2
 6908f5991f1d502a68edc4d0b491f57eabc0803c 4584 
libuninameslist_0.0.20091231-1.1.debian.tar.gz
Checksums-Sha256:
 1cafb9711eb7171c65cc55ae4c5b0cafc8d403473e0d4b5a278d7ac56ae5e411 1918 
libuninameslist_0.0.20091231-1.1.dsc
 ea401c625d849a0b554abf9800289ad38eb63817fafc277fe7301e454ab3fec7 568820 
libuninameslist_0.0.20091231.orig.tar.bz2
 65b7b6755c28c765a230b89f46d725e4148585488c0edf8e287b113aff02024d 4584 
libuninameslist_0.0.20091231-1.1.debian.tar.gz
Package-List: 
 libuninameslist-dev deb libdevel optional
 libuninameslist0 deb libs optional
Directory: pool/main/libu/libuninameslist
Priority: source
Section: libs

Package: libuninameslist-dev
Source: libuninameslist
Version: 0.0.20091231-1.1
Installed-Size: 2612
Maintainer: Kęstutis Biliūnas ke...@kaunas.init.lt
Architecture: armel
Depends: libuninameslist0 (= 0.0.20091231-1.1)
Description-en: a library of Unicode annotation data (development files)
 The library contains a large array with one entry for each unicode code
 point (U+ - U+10). Each entry contains two strings, a name and
 an annotation. The library also contains a list of all the Unicode blocks.
 .
 This package contains the runtime library's development files.
Description-md5: 3836013bf33b17ebe560be6de1e7cc14
Tag: devel::library, role::devel-lib
Section: libdevel
Priority: optional
Filename: 
pool/main/libu/libuninameslist/libuninameslist-dev_0.0.20091231-1.1_armel.deb
Size: 524920
MD5sum: 66e585b43729770254275363a173598b
SHA1: 675d3bd543e200ec469212ae402e91e8d064a40e
SHA256: 8fe343c37bafa57670cfd7396338c8d298d21aa2608d914bf4954ddcb8ca0807

Package: libuninameslist0
Source: libuninameslist
Version: 0.0.20091231-1.1
Installed-Size: 2596
Maintainer: Kęstutis Biliūnas ke...@kaunas.init.lt
Architecture: armel
Depends: libc6 (= 2.4)
Description-en: a library of Unicode annotation data
 The library contains a large array with one entry for each unicode code
 point (U+ - U+10). Each entry contains two strings, a name and
 an annotation. The library also contains a list of all the Unicode blocks.
 .
 This package contains the runtime library.
Description-md5: 2ca2878041447687b36b5e3550f0b9ce
Tag: role::shared-lib
Section: libs
Priority: optional
Filename: 
pool/main/libu/libuninameslist/libuninameslist0_0.0.20091231-1.1_armel.deb
Size: 521038
MD5sum: ad723ddfda4c2c4f52b241411f08ebdd
SHA1: 09d40c0cae8026df0504d9bcc7b5a2a054dba489
SHA256: d4a53a500f82e900ae736c993b9e0ac5e856cfb792117ac197a9100b609b6501


-- 
 Ricardo Mones, on behalf of Debian QA/MIA team
 http://people.debian.org/~mones
 «Never send a human to do a machine's job.» ~ Agent Smith


signature.asc
Description: Digital signature

Bug#676392: Please include test in github repo in the gem itself

2013-04-08 Thread Praveen A

Hi Josh,

Can you add test files in the gem itself like most gems do? It will
help me packaging the gem file for debian.

Thanks
Praveen

PS: I'm writing to you directly because issues were not activated in
this repo, if possible do that too.

--
പ്രവീണ്‍ അരിമ്പ്രത്തൊടിയില്‍
You have to keep reminding your government that you don't get your
rights from them; you give them permission to rule, only so long as
they follow the rules: laws and constitution.


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

Bug#704970: O: opendict -- computer dictionary for several dictionary formats

Package: wnpp
Severity: normal

The current maintainer of opendict, Kęstutis Biliūnas ke...@kaunas.init.lt,
is apparently not active anymore.  Therefore, I orphan this package now.

Maintaining a package requires time and skills. Please only adopt this
package if you will have enough time and attention to work on it.

If you want to be the new maintainer, please see
http://www.debian.org/devel/wnpp/index.html#howto-o for detailed
instructions how to adopt a package properly.

Some information about this package:

Package: opendict
Binary: opendict
Version: 0.6.3-3.1
Maintainer: Kęstutis Biliūnas ke...@kaunas.init.lt
Build-Depends: debhelper ( 6.0.0), quilt (= 0.40)
Build-Depends-Indep: python-all-dev (= 2.3.5-11), python-central (= 0.5)
Architecture: all
Standards-Version: 3.8.0
Format: 1.0
Files:
 c092eaa6fef2878fbb2c469208079609 1812 opendict_0.6.3-3.1.dsc
 2426a1de1131d0279dcea0cded43b063 132515 opendict_0.6.3.orig.tar.gz
 16511c06301d3db7eeaf60bbc45f5e73 25683 opendict_0.6.3-3.1.diff.gz
Checksums-Sha1:
 6772a7cddc6fb8509a4ad3d6992dc1241f4e2700 1812 opendict_0.6.3-3.1.dsc
 fca2857fe9a764d7b5b07ebd6eb069494e6b3768 132515 opendict_0.6.3.orig.tar.gz
 c926aa88f7410726d62f69b7bd1bc1d1b9abd127 25683 opendict_0.6.3-3.1.diff.gz
Checksums-Sha256:
 ffc9952ee9494218854d341ca47945780493801a114127feda9ef073ad1f4c54 1812 
opendict_0.6.3-3.1.dsc
 dad7723512768aeae65fead0f06a3c973b161a86658b94a66c4945beb12f45dc 132515 
opendict_0.6.3.orig.tar.gz
 5d72882b0d472a34b40fe3b47bc15c4cd5872ba51f474c165c882476503565fc 25683 
opendict_0.6.3-3.1.diff.gz
Homepage: http://opendict.sourceforge.net/
Package-List: 
 opendict deb text optional
Python-Version: all
Directory: pool/main/o/opendict
Priority: source
Section: text

Package: opendict
Version: 0.6.3-3.1
Installed-Size: 431
Maintainer: Kęstutis Biliūnas ke...@kaunas.init.lt
Architecture: all
Depends: python, python-central (= 0.6.11), python-wxgtk2.8
Suggests: dictd, festival
Description-en: computer dictionary for several dictionary formats
 OpenDict is free cross-platform dictionary program. It works with
 DICT, Slowo and Mova dictionaries. It also supports plug-in
 dictionaries that may be created for almost any data source.
 OpenDict is a client for DICT servers.
Homepage: http://opendict.sourceforge.net/
Description-md5: 6ccd1bbbd605d45d4a3e4fc5cb539e89
Python-Version: all
Tag: accessibility::speech, field::linguistics, implemented-in::python,
 interface::x11, network::client, role::program, scope::application,
 sound::speech, uitoolkit::gtk, uitoolkit::wxwidgets, use::browsing,
 use::editing, use::learning, use::searching, works-with-format::TODO,
 works-with::dictionary, x11::application
Section: text
Priority: optional
Filename: pool/main/o/opendict/opendict_0.6.3-3.1_all.deb
Size: 146532
MD5sum: 9fc07547f5c55eeabf85e0fdc4a66c92
SHA1: 487a8311535096644d0829ead8855a4a6b774b1d
SHA256: 0dfecbd44c6a661183a7c79b59d98fac7a2ff7f3e3358277212538c4d1ba90bb


-- 
 Ricardo Mones, on behalf of Debian QA/MIA team
 http://people.debian.org/~mones
 «Never send a human to do a machine's job.» ~ Agent Smith


signature.asc
Description: Digital signature

Bug#704971: lio-utils - service restarted without asking questions to user

2013-04-08 Thread Félix Defrance


Package: lio-utils
Version: 3.1+git2.fd0b34fd-2
Severity: normal

Hello,

I upgraded lio-utils this morning and i was surprised when my iscsi 
initiators was deleted !


We got a big problems on many targets. IO Errors, systems remount fs in 
read only mode, many services doesn't wanted to restart, etc..


To avoid this case, i think it should be better if the upgrade notify me 
with a debconf question before deleted it !


You can found my apt log below.

Regards,

-- Apt log term

Log started: 2013-04-08  09:55:04
(Reading database ... ^M(Reading database ... 5%^M(Reading database ... 
10%^M(Reading database ... 15%^M(Reading database ... 20%^M(Reading 
database ... 2$
Preparing to replace linux-image-3.2.0-4-amd64 3.2.39-2 (using 
.../linux-image-3.2.0-4-amd64_3.2.41-2_amd64.deb) ...

Unpacking replacement linux-image-3.2.0-4-amd64 ...
Examining /etc/kernel/postrm.d .
run-parts: executing /etc/kernel/postrm.d/initramfs-tools 3.2.0-4-amd64 
/boot/vmlinuz-3.2.0-4-amd64
run-parts: executing /etc/kernel/postrm.d/zz-update-grub 3.2.0-4-amd64 
/boot/vmlinuz-3.2.0-4-amd64
Preparing to replace lio-utils 3.1+git2.fd0b34fd-1 (using 
.../lio-utils_3.1+git2.fd0b34fd-2_amd64.deb) ...
Unloading fabric/configfs: Successfully released fabric: 
/sys/kernel/config/target/loopback

Successfully released fabric: /sys/kernel/config/target/fc
  [OK]
Unloading LIO-Target/ConfigFS fabric: Successfully released network 
portal: 192.168.48.32:3260 created 
iqn.2003-01.org.linux-iscsi.srvnas05.x8664:sn.37c3d$
Successfully released network portal: 192.168.47.32:3260 created 
iqn.2003-01.org.linux-iscsi.srvnas05.x8664:sn.37c3dc1c6c46 TPGT: 1
Successfully deleted iSCSI Initiator Mapped LUN: 13 ACL 
iqn.1993-08.org.debian:01:16e8e5adc455 for iSCSI Target Portal Group: 
iqn.2003-01.org.linux-iscsi.$
Successfully deleted iSCSI Initiator Mapped LUN: 12 ACL 
iqn.1993-08.org.debian:01:16e8e5adc455 for iSCSI Target Portal Group: 
iqn.2003-01.org.linux-iscsi.$
Successfully deleted iSCSI Initiator Mapped LUN: 11 ACL 
iqn.1993-08.org.debian:01:16e8e5adc455 for iSCSI Target Portal Group: 
iqn.2003-01.org.linux-iscsi.$
Successfully deleted iSCSI Initiator Mapped LUN: 10 ACL 
iqn.1993-08.org.debian:01:16e8e5adc455 for iSCSI Target Portal Group: 
iqn.2003-01.org.linux-iscsi.$
Successfully deleted iSCSI Initiator Mapped LUN: 9 ACL 
iqn.1993-08.org.debian:01:16e8e5adc455 for iSCSI Target Portal Group: 
iqn.2003-01.org.linux-iscsi.s$
Successfully deleted iSCSI Initiator Mapped LUN: 0 ACL 
iqn.1993-08.org.debian:01:16e8e5adc455 for iSCSI Target Portal Group: 
iqn.2003-01.org.linux-iscsi.s$
Successfully deleted iSCSI Initiator Mapped LUN: 1 ACL 
iqn.1993-08.org.debian:01:16e8e5adc455 for iSCSI Target Portal Group: 
iqn.2003-01.org.linux-iscsi.s$
Successfully deleted iSCSI Initiator Mapped LUN: 2 ACL 
iqn.1993-08.org.debian:01:16e8e5adc455 for iSCSI Target Portal Group: 
iqn.2003-01.org.linux-iscsi.s$
Successfully deleted iSCSI Initiator Mapped LUN: 3 ACL 
iqn.1993-08.org.debian:01:16e8e5adc455 for iSCSI Target Portal Group: 
iqn.2003-01.org.linux-iscsi.s$
Successfully deleted iSCSI Initiator Mapped LUN: 4 ACL 
iqn.1993-08.org.debian:01:16e8e5adc455 for iSCSI Target Portal Group: 
iqn.2003-01.org.linux-iscsi.s$
Successfully deleted iSCSI Initiator Mapped LUN: 5 ACL 
iqn.1993-08.org.debian:01:16e8e5adc455 for iSCSI Target Portal Group: 
iqn.2003-01.org.linux-iscsi.s$
Successfully deleted iSCSI Initiator Mapped LUN: 6 ACL 
iqn.1993-08.org.debian:01:16e8e5adc455 for iSCSI Target Portal Group: 
iqn.2003-01.org.linux-iscsi.s$
Successfully deleted iSCSI Initiator Mapped LUN: 7 ACL 
iqn.1993-08.org.debian:01:16e8e5adc455 for iSCSI Target Portal Group: 
iqn.2003-01.org.linux-iscsi.s$
Successfully deleted iSCSI Initiator Mapped LUN: 8 ACL 
iqn.1993-08.org.debian:01:16e8e5adc455 for iSCSI Target Portal Group: 
iqn.2003-01.org.linux-iscsi.s$
Successfully deleted iSCSI Initaitor ACL 
iqn.1993-08.org.debian:01:16e8e5adc455 for iSCSI Target Portal Group: 
iqn.2003-01.org.linux-iscsi.srvnas05.x8664:$
Successfully deleted iSCSI Initiator Mapped LUN: 13 ACL 
iqn.1993-08.org.debian:01:1f4f7554eda6 for iSCSI Target Portal Group: 
iqn.2003-01.org.linux-iscsi.$
Successfully deleted iSCSI Initiator Mapped LUN: 12 ACL 
iqn.1993-08.org.debian:01:1f4f7554eda6 for iSCSI Target Portal Group: 
iqn.2003-01.org.linux-iscsi.$
Successfully deleted iSCSI Initiator Mapped LUN: 11 ACL 
iqn.1993-08.org.debian:01:1f4f7554eda6 for iSCSI Target Portal Group: 
iqn.2003-01.org.linux-iscsi.$
Successfully deleted iSCSI Initiator Mapped LUN: 10 ACL 
iqn.1993-08.org.debian:01:1f4f7554eda6 for iSCSI Target Portal Group: 
iqn.2003-01.org.linux-iscsi.$
Successfully deleted iSCSI Initiator Mapped LUN: 9 ACL 
iqn.1993-08.org.debian:01:1f4f7554eda6 for iSCSI Target Portal Group: 
iqn.2003-01.org.linux-iscsi.s$
Successfully deleted iSCSI Initiator Mapped LUN: 0 ACL 
iqn.1993-08.org.debian:01:1f4f7554eda6 for iSCSI Target Portal Group: 
iqn.2003-01.org.linux-iscsi.s$
Successfully deleted iSCSI

Bug#704668: RFS: woff-tools/0:2009.10.04-1 [ITP]

2013-04-08 Thread Dmitry Shachnev

On Sun, Apr 7, 2013 at 10:44 PM, Jakub Wilk jw...@debian.org wrote:
 (I don't intend to sponsor this. Sorry!)

Thanks for the review anyway!

 * Dmitry Shachnev mity...@gmail.com, 2013-04-07, 16:48:

 FTR, the repository is here:
 svn://anonscm.debian.org/pkg-fonts/packages/woff-tools/trunk

 Please fix the Vcs-Svn field. :)


 Done, thanks! I should probably have mentioned it when I was filing the
 bug…


 Who was .orig.tar created? You can answer in README.source or by writing
 get-orig-source target. :)

Added get-orig-source.

 cppcheck says:
 [woff.c:281]: (error) Common realloc mistake: 'woffData' nulled but not
 freed upon failure
 [woff.c:301]: (error) Common realloc mistake: 'woffData' nulled but not
 freed upon failure

I’ll report a bug to Mozilla, but I don't think it’s worth a downstream patch.

 lintian should have emitted hyphen-used-as-minus-sign, but for some reason
 didn't...

Fixed, thank you!

 According to man-pages(7), the DESCRIPTION sections should be between
 SYNOPSIS and OPTIONS. It also advices against the AUTHOR(S) section.

Fixed.

 The package description and manual pages mention only OpenType fonts, but
 upstream homepage says TrueType fonts are supported too.

The manpages are based on output of upstream “-h” option, which only
says about OpenType. The code also doesn’t mention TrueType, so I
would prefer to keep my current descriptions.

--
Dmitry Shachnev


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

Bug#704888: gpodder: Causes 100% cpu load for several minutes

2013-04-08 Thread Thomas Perl

Hi,

Can you reproduce this with gPodder 3.5.0 from Debian unstable after
removing your database and downloads? If so, do the logfiles
(~/gPodder/Logs/) show anything unusual?

Thanks,
Thomas


2013/4/7 Johannes Rohr jor...@gmail.com

 Package: gpodder
 Version: 2.20.1-1
 Severity: normal

 Recently, feed updates and downloads of episodes have started causing 100%
 for
 several minutes, during which the programme becomes unresponsive. I first
 observed this behaviour on gpodder 3.5 from sid. Therefore I downgraded to
 the
 version from Wheezy, deleted the entire configuration and re-synced with
 gpodder.net, but to no avail.

 This makes the programme unusable for any practical purpose. Please let me
 know
 what specific debug information is needed and how it can be extracted.



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

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

 Versions of packages gpodder depends on:
 ii  python  2.7.3-4
 ii  python-dbus 1.1.1-1
 ii  python-feedparser   5.1.2-1
 ii  python-gtk2 2.24.0-3+b1
 ii  python-mygpoclient  1.4-1
 ii  python-support  1.0.15

 Versions of packages gpodder recommends:
 ii  dbus-x11   1.6.8-1
 ii  python-gpod0.8.2-7
 ii  python-gst0.10 0.10.22-3
 ii  python-pymtp   0.0.4-4
 ii  python-simplejson  2.5.2-1
 ii  python-webkit  1.1.8-2

 Versions of packages gpodder suggests:
 ii  gnome-bluetooth  3.4.2-1
 ii  mplayer  3:1.1-dmo9
 ii  python-eyed3 0.6.18-1

 -- no debconf information

Bug#668332: Info received (Bug#643337: dpkg: start-stop-daemon can't handle script daemon)

2013-04-08 Thread Jérôme

Update.

I removed the --name argument, and I use following values:

NAME=script_name
DAEMON=path_to_script/$NAME
DAEMON_ARGS=--args

do_start()
{
# Return
#   0 if daemon has been started
#   1 if daemon was already running
#   2 if daemon could not be started
start-stop-daemon --start --quiet --background --make-pidfile
--chuid=$DAEMONUSER --pidfile $PIDFILE --startas $DAEMON --test 
/dev/null \
|| return 1
start-stop-daemon --start --quiet --background --make-pidfile
--chuid=$DAEMONUSER --pidfile $PIDFILE --startas $DAEMON -- \
$DAEMON_ARGS \
|| return 2

[...]

do_stop()
{
# Return
#   0 if daemon has been stopped
#   1 if daemon was already stopped
#   2 if daemon could not be stopped
#   other if a failure occurred
start-stop-daemon --stop --quiet --retry=INT/30/KILL/5
--pidfile $PIDFILE


[...]

Now, I get expected behaviour. That is, the script won't launch two
instances of the application, and I have an explicit status message.

Yet, the name of the executable is not checked, which means that if it
dies somehow, and a new process gets its PID, the script will stop the
new process.

I suppose a nicer way would be to get s-s-d to write the name of the
script itself ($NAME) in /proc/PID/stat, instead of the name of the
interpreter (python). I couldn't achieve this.

Am I misunderstanding something ?

-- 
Jérôme


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

Bug#704954: colortest-python: New version available

2013-04-08 Thread jari

On 2013-04-08 00:14, John Eikenberry wrote:
| Package: colortest-python
| Version: 1.4-2
| Severity: wishlist
| 
| Just released version 1.5 which adds Python 3 compatibility.
| Thanks.

Hi John,

The version is still 1.4 at 

  http://zhar.net/projects/shell/terminal-colors

Likewise

  http://freecode.com/projects/terminal_colors

Could you point me to the latest,
Jari


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

Bug#704844: [wiki.debian.org] French interface: broken links for edit help (HelpOnEditing, HelpOnMoinWikiSyntax)

2013-04-08 Thread Paul Wise

Control: reassign -1 wiki.debian.org
Control: affects -1 - wiki.debian.org
Control: tags -1 - upstream
Control: retitle -1 wiki.debian.org: underlay translations not installed

On Sun, 2013-04-07 at 10:04 -0400, Filipus Klutiero wrote:

 This suggests the main problem could be one of setup (only English help pages 
 on some installs). 

Looks like you were correct here, I discovered the LanguageSetup page
and installed the French underlay translations and now the link works.

I'll close this bug once I've installed all the translations.

-- 
bye,
pabs

http://wiki.debian.org/PaulWise


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

Bug#704977: calibre: embedded copy of non-free unrar

2013-04-08 Thread Jakub Wilk


Source: calibre
Version: 0.9.18+dfsg-1
Severity: serious
Justification: Policy 2.2.1

src/unrar/ is an embedded copy of unrar. This software is non-free.

Dmitry Shachnev asked me to include pointer to this:
https://code.launchpad.net/~mitya57/debian/sid/calibre/remove-embedded-libraries/+merge/157195https://code.launchpad.net/~mitya57/debian/sid/calibre/remove-embedded-libraries/+merge/157195

--
Jakub Wilk


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

Bug#704978: bitcoin: Please upload bitcoin 0.8.1 in unstable before the 15th May 2013

2013-04-08 Thread Laurent Bigonville

Source: bitcoin
Version: 0.7.2-3
Severity: important

Hi,

Please upload bitcoin 0.8.1 in unstable before the 15th May 2013.

At this date, the network will requires that version.

More information:
http://bitcoin.org/may15.html

Cheers

Laurent Bigonville

-- System Information:
Debian Release: 7.0
  APT prefers unstable
  APT policy: (500, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 3.8-trunk-amd64 (SMP w/8 CPU cores)
Locale: LANG=fr_BE.utf8, LC_CTYPE=fr_BE.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#696841: libsbuild-perl: fails to parse configuration: uses undef as HASH ref (MAILTO_HASH)

Matthias Klumpp dixit:

What is the progress on this bug? The issue is highly annoying, and it
would be great if it could be fixed soon. The patch from the wiki page

It’s applied and fixed in git, and my Atari buildd VM is churning
happily (we got needs-build down to ca. 1000 source packages).

Here’s my last status mail (the last one I found in sent-mail on
the go, anyway):

From: Thorsten Glaser t...@mirbsd.de
Message-ID: pine.bsm.4.64l.1301061439210.11...@herc.mirbsd.org
To: Roger Leigh rle...@codelibre.net
Cc: 696...@bugs.debian.org, debian-...@lists.debian.org
Date: Sun, 6 Jan 2013 14:41:50 + (UTC)
Subject: Re: [buildd-tools-devel] Bug#696840: same for upload_queues

Roger Leigh dixit:

In both sbuild and buildd, we changed the internal configuration
(Buildd::Conf and Sbuild::Conf classes) to *only* use scalars,

Okay, with the latest patches, this actually works.

I’m using
• 
http://anonscm.debian.org/gitweb/?p=buildd-tools/sbuild.git;a=commitdiff;h=fbd76de128aefe983eb8d981e061fc4051432c7f
• 
http://anonscm.debian.org/gitweb/?p=buildd-tools/sbuild.git;a=commitdiff;h=134223e35d4bea3c58a4764d5ee4944598f67e25
• 
http://anonscm.debian.org/gitweb/?p=buildd-tools/sbuild.git;a=commitdiff;h=b0b469da801b54c4441fd16a9c85faa6a6b2362d
on top of the sid version (0.63.2-1.1).

bye,
//mirabilos
-- 
☎ Natureshadow Ich glaub ich hab mir grad mit dem [Ham]Burger die Nase abge‐
putzt… mirabilos Ich glaub ich hab ne neue eMail-Signatur
Natureshadow Scheiße, warum passiert mir sowas immer, wenn ich mit dir spre‐
che? *hust* Das war Schnodderburger… *hust*


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

Bug#704950: logrotate: Errors last rotated in the future -- rotation forced

2013-04-08 Thread Vincent Lefevre

On 2013-04-08 09:38:17 +0100, Paul Martin wrote:
 On Sun, Apr 07, 2013 at 11:40:17PM -0500, Vincent Lefevre wrote:
  Note that the timezone was changed from Europe/Paris to US/Central
  earlier this day. This may be related. But I'd expect logrotate to
  obviously consider UTC time when comparing dates; if it does, this
  cannot explain the above errors.
 
 Sorry, no.  It uses local time, to match how cron(8) works.

I don't see why this is necessary. Note that cron doesn't do
time stamp comparisons, AFAIK. At least cron has never thought
that some file has been created in the future.

 Gandi hosting, perhaps?

No, just a laptop, which comes with me when I travel.

-- 
Vincent Lefèvre vinc...@vinc17.net - Web: http://www.vinc17.net/
100% accessible validated (X)HTML - Blog: http://www.vinc17.net/blog/
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)


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

Bug#688754: Add alternatives for nvidia-settings and nvidia-settings-legacy-173xx

2013-04-08 Thread Gaudenz Steinlin

Package: nvidia-graphics-drivers-legacy-173xx
Followup-For: Bug #688754

Currently the package libgl1-nvidia-legacy-173xx-glx has a Breaks
relationship with nvidia-settings. If all the patches in this bug report
are applied this is no longer needed as the settings can be co-installed
and managed by the alternative. Attached to this mail is an updated
patch for nvidia-graphics-drivers-legacy-173xx which also removes that
Breaks.

Gaudenz

-- System Information:
Debian Release: 7.0
  APT prefers testing
  APT policy: (800, 'testing'), (700, 'unstable'), (50, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 3.8-trunk-amd64 (SMP w/2 CPU cores)
Locale: LANG=de_CH.UTF-8, LC_CTYPE=de_CH.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
From 4aac9cc4e2fcf2c095a7d23813b04dfc65fc1da1 Mon Sep 17 00:00:00 2001
From: Gaudenz Steinlin gaud...@debian.org
Date: Tue, 25 Sep 2012 12:32:36 +0200
Subject: [PATCH] Add alternatives for nvidia-settings

---
 debian/control|1 -
 debian/nvidia-alternative.postinst.in |5 +
 debian/nvidia-alternative.triggers.in |5 +
 debian/rules  |1 +
 4 files changed, 11 insertions(+), 1 deletion(-)

diff --git a/debian/control b/debian/control
index 585b867..828a7b1 100644
--- a/debian/control
+++ b/debian/control
@@ -150,7 +150,6 @@ Breaks:
 # libgl1-nvidia-legacy-173xx-glx ( 173.14.30-2),
  fglrx-glx ( 1:11-6-~),
  ia32-libs ( 1:0) [i386],
- nvidia-settings (= 302),
 Replaces:
  nvidia-glx${nvidia:Legacy} ( 173.14.27),
  libgl1-nvidia${nvidia:Legacy}-dev,
diff --git a/debian/nvidia-alternative.postinst.in b/debian/nvidia-alternative.postinst.in
index 17ba10b..931d516 100644
--- a/debian/nvidia-alternative.postinst.in
+++ b/debian/nvidia-alternative.postinst.in
@@ -52,6 +52,11 @@ if [ $1 = triggered ]; then
 		$(add_slave /usr/lib/nvidia/libglx.so libglx.so /usr/lib/#PRIVATE#/libglx.so)
 		$(add_slave /usr/lib/nvidia/nvidia_drv.so nvidia_drv.so /usr/lib/#PRIVATE#/nvidia_drv.so)
 		$(add_slave /usr/lib/nvidia/nvidia-bug-report.sh nvidia-bug-report.sh /usr/lib/#PRIVATE#/nvidia-bug-report.sh)
+		$(add_slave /usr/bin/nvidia-settings nvidia-settings /usr/bin/nvidia-settings#LEGACY_OR_CURRENT#)
+		$(add_slave /usr/bin/nv-control-dpy nv-control-dpy /usr/bin/nv-control-dpy#LEGACY_OR_CURRENT#)
+		$(add_slave /usr/share/applications/nvidia-settings.desktop nvidia-settings.desktop /usr/share/applications/nvidia-settings.desktop#LEGACY_OR_CURRENT#)
+		$(add_slave /usr/share/pixmaps/nvidia-settings.png nvidia-settings.png /usr/share/pixmaps/nvidia-settings.png#LEGACY_OR_CURRENT#)
+		$(add_slave /usr/share/man/man1/nvidia-settings.1.gz nvidia-settings.1.gz /usr/share/man/man1/nvidia-settings#LEGACY_OR_CURRENT#.1.gz)
 
 	if echo $slaves | grep -q slave ; then
 		update-alternatives --install /usr/lib/nvidia/nvidia nvidia /usr/lib/#PRIVATE# #MAJOR# $slaves
diff --git a/debian/nvidia-alternative.triggers.in b/debian/nvidia-alternative.triggers.in
index 57cd16d..eb6d528 100644
--- a/debian/nvidia-alternative.triggers.in
+++ b/debian/nvidia-alternative.triggers.in
@@ -3,3 +3,8 @@ interest register-nvidia-alternative#LEGACY#
 interest /usr/lib/#PRIVATE#
 interest /usr/lib/i386-linux-gnu/#PRIVATE#
 interest /usr/lib/x86_64-linux-gnu/#PRIVATE#
+interest /usr/bin/nvidia-settings#LEGACY_OR_CURRENT#
+interest /usr/bin/nv-control-dpy#LEGACY_OR_CURRENT#
+interest /usr/share/applications/nvidia-settings.desktop#LEGACY_OR_CURRENT#
+interest /usr/share/pixmaps/nvidia-settings.png#LEGACY_OR_CURRENT#
+interest /usr/share/man/man1/nvidia-settings#LEGACY_OR_CURRENT#.1.gz
diff --git a/debian/rules b/debian/rules
index 72c196e..a18b64a 100755
--- a/debian/rules
+++ b/debian/rules
@@ -285,6 +285,7 @@ override_dh_builddeb:
 	-e 's{#VERSION#}{$(version)}g;' \
 	-e 's{#MAJOR#}{$(firstword $(subst ., ,$(version)))}g;' \
 	-e 's{#LEGACY#}{$(legacy)}g;' \
+	-e 's{#LEGACY_OR_CURRENT#}{$(if $(legacy),$(legacy),-current)}g;' \
 	-e 's{#WATCH_PATTERN#}{$(subst \,\\,$(watch_pattern))}g;' \
 	-e 's{#LIBDIR#}{$(libdir)}g;' \
 	-e 's{#PRIVATE#}{$(nvidia_private)}g;' \
-- 
1.7.10.4

Bug#676392: needs multimap for running tests

2013-04-08 Thread Praveen A

waiting for multimap package

--
പ്രവീണ്‍ അരിമ്പ്രത്തൊടിയില്‍
You have to keep reminding your government that you don't get your
rights from them; you give them permission to rule, only so long as
they follow the rules: laws and constitution.

Bug#704980: please ship python module

2013-04-08 Thread Stefano Zacchiroli

Package: ledger
Version: 3.0.0~20130313+b608ed2-1
Severity: normal

As far as I understand from

  https://groups.google.com/forum/#!msg/ledger-cli/1Jeizqr9A7M/Irum7QIfHvIJ

(John Wiegley's explanation of how the Python bindings work) it is possible to
install the ledger/Python bindings as a regular Python library, so that one can
use import ledger as usual in Python scripts instead of relying on ledger
python foo.py.

For Debian, that probably means that a new python-ledger binary package
should be built off the ledger should package, shipping only the C++/Python
ledger bindings.  Can you consider doing that? It'd be awesome ;)

Thanks for maintaining ledger in Debian!
Cheers.

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

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

Versions of packages ledger depends on:
ii  dpkg   1.16.10
ii  install-info   4.13a.dfsg.1-10
ii  libboost-filesystem1.49.0  1.49.0-3.2
ii  libboost-iostreams1.49.0   1.49.0-3.2
ii  libboost-regex1.49.0   1.49.0-3.2
ii  libboost-system1.49.0  1.49.0-3.2
ii  libc6  2.13-38
ii  libgcc11:4.7.2-5
ii  libgmp10   2:5.0.5+dfsg-2
ii  libicu48   4.8.1.1-12
ii  libmpfr4   3.1.1-1
ii  libstdc++6 4.7.2-5

ledger recommends no packages.

ledger 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#444026: use multiple terminals instead

2013-04-08 Thread martin f krafft

The --timeout option no longer exists.

By now, grub supports setting

  GRUB_TERMINAL=serial console

and will show the Grub menu on both, allowing both to be used.
I think this should become the default when a serial console is
detected during install.

-- 
 .''`.   martin f. krafft madduck@d.o  Related projects:
: :'  :  proud Debian developer   http://debiansystem.info
`. `'`   http://people.debian.org/~madduckhttp://vcs-pkg.org
  `-  Debian - when you have better things to do than fixing systems


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

Bug#698769: Seconded (was: RFP: caldavzap)

2013-04-08 Thread Jan-Pascal van Best

I second this RFP. Very useful piece of software for which there is no
real alternative, AFAIK.

Copyright situation looks clear, dependencies nicely contained in the /lib
folder. I would package it myself but I know I won't be able to support it
on the long term.

Jan-Pascal


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

Bug#704981: Append console= parameters to Linux kernel conditional on terminal_input interaction

2013-04-08 Thread martin f krafft

Package: grub-pc
Version: 1.99-27
Severity: wishlist
Tags: upstream

With delight I noticed that grub2 now accepts multiple terminals for
terminal_input and terminal_output and mirrors the menu on all in
real-time. This now let's me put the Grub menu on both, the serial
port and the local console.

Grub then starts the Linux kernel (most of the time anyway) and
passes the following parameters (typically) to the kernel:

… console=tty0 console=ttyS0,38400n8

Unfortunately, the Linux kernel cannot output everything to two
consoles and the above will have all information from /sbin/init and
/etc/init.d/rc reach only the serial port.

In most cases this is what I want, but when I am sitting at the
console itself, this isn't ideal.

What would be ideal is if Grub only appended the above kernel
parameter unless I interacted with the Grub menu over the console.
If I do that, then it should either switch the two console=
parameters, or just leave it off entirely.

I have looked everywhere, but I don't think this is possible. It
would be really nice, however, if Grub could learn how to do that.

[reporting via debbugs e-mail as I am on a very very very bad
connection…]

--
.''`. martin f. krafft madduck@d.o Related projects:
: :' : proud Debian developer http://debiansystem.info
`. `'` http://people.debian.org/~madduckhttp://vcs-pkg.org
`- Debian - when you have better things to do than fixing systems

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

Bug#704941: vlc: Clicking the Playlist-Internet-Icecast pick causes Lua error messages

2013-04-08 Thread Benjamin Drung

Am Sonntag, den 07.04.2013, 20:45 -0400 schrieb Michael O'Donnell:
 Package: vlc
 Version: 2.0.5-2

 [...]

   VLC media player 2.0.3 Twoflower (revision 2.0.2-93-g77aa89e)

Are you really using vlc 2.0.5-2?

-- 
Benjamin Drung
Debian  Ubuntu Developer


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

Bug#704982: php-horde-cache: Class 'Horde_Compress_Fast' not found

2013-04-08 Thread Michael Fladischer

Package: php-horde-cache
Version: 2.0.3-1
Severity: normal

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Dear Maintainer,

it seems that Cache.php is referencing a compression library that is not 
shipped by php-horde-compress:

PHP Fatal error:  Class 'Horde_Compress_Fast' not found in 
/usr/share/php/Horde/Cache.php on line 103
PHP Fatal error:  Class 'Horde_Compress_Fast' not found in 
/usr/share/php/Horde/Cache.php on line 120

There is no package to satisfy Recommends:php-horde-compress-fast rigth now.
I would not consider this important if it would only impact caching, but right 
now, it breaks horde installations that have caching enabled.

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

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

Versions of packages php-horde-cache depends on:
ii  php-horde-exception  2.0.3-1
ii  php-horde-util   2.0.3-1
ii  php-pear 5.4.4-15
ii  php5 5.4.4-15

Versions of packages php-horde-cache recommends:
pn  php-horde-compress-fast  none
ii  php-horde-db 2.0.2-1
ii  php-horde-log2.0.1-2
ii  php-horde-memcache   2.0.2-1
pn  php5-apc none
pn  php5-eacceleratornone

php-horde-cache suggests no packages.

- -- no debconf information

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.12 (GNU/Linux)

iQIcBAEBAgAGBQJRYq5MAAoJEGlMre9Rx7W20Q4P/jRrmtm9Ij3hcCwVq9yQgrfy
JK2Y536+ABV7YzDbLc4KomKtdVIJKV4NI5k+alpO8ty2VbzGuerGJZPz0XRj+qii
v/yFvrBTakhij4AK9toAVXpSqoarDDMQP/i54aAcob6QM2CXznYZTYwCdjHBKkjV
059YhwLmgS7eg1HhBZlRvwZsA9V5J0ozKTidFM6E0EiiBcz5aBMDL62/WCt3oaJj
iXBvpWZFzeokDgPpD0Q093Phyca176EVDVzo64or2jnVdXVPHPmeNgcUrCXu1yw3
4EUh5cAqKyCjSdSm4W/eEn/ToWG8HttAemYSe4ZAE+jJaFsyP2UeW25ly/ViMa/d
aLbbCJWULmxYQMxMkUKGwwkpcRmYRh1K7v1RqigTzlNELXVhykgcmrMF/yPpboXH
Q8R16s3BptCK0XuwE7JXvBh/pctf0It3oD1aTT/Zcn4JWHKqrF6v35klBKCXtB+m
Na4wgTHXA9Y3xvJGymxjqdzIcJkJJ/cIIakLwHa3pt3mIWr6RaPQn1IAuyY8Gay5
jiTjfaJvWiPiWnRcPjmzlFUjeDzQYvJKc5kJN+yr38TRD5su1GaDe+kTNhaRS/Ps
TIGpPsR4QUntebljtfRs/tXN0n3vxmEwrHveTIi5A+vGRZlrHXSHEuf9nKXpTmKs
TIOguldYUi5jFH4Abbd0
=WVyE
-END PGP SIGNATURE-


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

Bug#704744: pbuilder: umounts /{dev,run}/shm of the host system

Stéphane Glondu dixit:

Why not just do nothing if /dev/shm is a symlink?

A $chroot/run/shm should probably be umounted.

Are there cases where umount_on_exit is called on a symlink that should
be followed? If not, I would just kill the problem directly there, as in

I was thinking about this a bit, and tonight wondered whether/why
things like readlink/realpath (the shell utilities, not the syscalls
or libc functions) do not offer the functionality of resolving symlinks
(should they encounter any) relative to some (emulated) chroot path.

That would probably help…

Cyril Brulebois dixit:

Next time, can you please put the right people in the loop?!

Cc-ing:
 debian-bugs-dist@lists.debian.org

I did a reply-to-all on the mail.

is just plain stupid. Maintainers of the package you're reassigning to
don't get your control mail. Way to communicate!

I did not know that. I think this is a debbugs bug; it’s inconsistent
to require of the bug submitter to manually look up maintainers (for
example, I wasn’t aware debootstrap has anything to do with booting
Debian…) when reassigning, when one doesn’t have to do so normally.

Not sure I agree that's an RC bug in debootstrap. I'd rather call it a

If debootstrap tries to umount a symlink that points to outside
the chroot, I’d call it an issue with debootstrap, independent of…

wishlist in debootstrap to support the new thing pbuilder imposes, and
an RC bug in pbuilder not to depend on a debootstrap version
implementing said improved behaviour.

… this one.

Yes, the maintainers of debootstrap (and possibly cdebootstrap),
pbuilder and cowbuilder should probably talk to each other.
Ideally.

But right now, we have a bug that breaks unrelated software,
by umounting my /run/shm every time I create a chroot, and
thus deleting every piece of data that was put there. In this
particular instance, I’m the user who doesn’t really care
about where the bug is, or whose fault it is – this is one
of the major problems with a system based on packages of
separate maintainers…

bye,
//mirabilos
-- 
Sorry,  I’m annoyed today and you came by as an Arch user. These are the
perfect victims for any crime against humanity, like  systemd,  feminism
or social democracy.
-- Christoph Lohmann on d...@suckless.org


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

Bug#703479: [Packaging] Bug#703479: munin: Huge munin-graph log with cron graph_strategy

2013-04-08 Thread Michael Shuler

Hi Holger,

I just did a squeeze-wheezy dist-upgrade on one of my primary servers a
few days ago, and I started receiving cron.daily emails of:

Subject: Cron root@linode test -x /usr/sbin/anacron || ( cd / 
run-parts --report /etc/cron.daily )
/etc/cron.daily/logrotate:
gzip: stdin: file size changed while zipping

I included '-v' in the logratate job and found that is was
munin-graph.log generating the above error, and it appears that I am
missing several minutes of log lines between the end of
munin-graph.log.1.gz and the beginning of munin-graph.log.

Could delaycompress be added to the /etc/logrotate.d/munin (munin-node,
perhaps, too) sections to prevent the log loss? (or should this be a
separate bug report?)

Thanks!
-- 
Kind regards,
Michael Shuler


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

Bug#704983: git-daemon-sysvinit: needless option --home when creating system user with --no-create-home

2013-04-08 Thread Alexander Dahl

Package: git-daemon-sysvinit
Version: 1:1.7.10.4-2
Severity: minor

Dear Maintainer,

when installing I get these:

Vormals nicht ausgewähltes Paket git-daemon-sysvinit wird gewählt.
(Lese Datenbank ... 30169 Dateien und Verzeichnisse sind derzeit 
installiert.)
Entpacken von git-daemon-sysvinit (aus 
.../git-daemon-sysvinit_1%3a1.7.10.4-2_all.deb) ...
git-daemon-sysvinit (1:1.7.10.4-2) wird eingerichtet ...
Warnung: Auf das von Ihnen angegebene Home-Verzeichnis /nonexistent 
kann nicht zugegriffen werden: Datei oder Verzeichnis nicht gefunden
Lege Systembenutzer »gitdaemon« (UID 104) an ...
Lege neuen Benutzer »gitdaemon« (UID 104) mit Gruppe »nogroup« an ...
Erstelle Home-Verzeichnis »/nonexistent« nicht.

The warning is caused by the paramater --home=/nonexistent when
calling add-user in postinst. This is needless because add-user is
correctly called with --no-create-home anyway. Removing the --home
option from the call would remove the warning with same functionality.

HTH  Greets

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

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

Versions of packages git-daemon-sysvinit depends on:
ii  adduser  3.113+nmu3
ii  git  1:1.7.10.4-2

git-daemon-sysvinit recommends no packages.

git-daemon-sysvinit suggests no packages.

-- no debconf information


pgpJ_Au8ynrNx.pgp
Description: PGP signature

Bug#699471: Bug#704748: task-gnome-desktop: uninstallable on kfreebsd-*

2013-04-08 Thread Steven Chamberlain

Control: tags -1 = d-i patch

Hi,

On 05/04/13 13:31, Steven Chamberlain wrote:
 Package has a Depends on network-manager-gnome which cannot be satisfied
 on kfreebsd-amd64.
 Package has a Depends on network-manager-gnome which cannot be satisfied
 on kfreebsd-i386.

On 25/02/13 06:19, Christian PERRIER wrote:
 I committed a fix in the master branch.

What about the wheezy branch, was that missed by accident?  (Patch
attached).

Also the [linux-any] needs to be dropped I think, which is okay since it
is being downgraded from Depends-Recommends.

Thanks,
Regards,
-- 
Steven Chamberlain
ste...@pyro.eu.org
From: Steven Chamberlain ste...@pyro.eu.org

Downgrade network-manager-gnome to Recommends, because a Depends
relation could only be satisfied on [linux-any] (Closes: #699471)
---
 debian/control |6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/debian/control b/debian/control
index 1459820..9a4fe34 100644
--- a/debian/control
+++ b/debian/control
@@ -72,9 +72,7 @@ Description: GNOME desktop environment
 Depends: ${misc:Depends}, 
 	task-desktop,
 # only depend on a very minimal gnome desktop, to ensure it fits on CD1
-	gnome-core,
-# but we need a working network setup at least
-	network-manager-gnome
+	gnome-core
 Recommends:
 # The full gnome desktop environment should be included if possible
 # even if the larger gnome metapackage doesn't fit.
@@ -100,6 +98,8 @@ Recommends:
 	hunspell-en-us,
 # make hyphenation work
 	hyphen-en-us,
+# we need a working network setup at least
+	network-manager-gnome
 
 Package: task-kde-desktop
 Architecture: all
-- 
1.7.10.4

Bug#704984: debbugs: does not inform maintainers when reassigning bugs

Package: bugs.debian.org

Dixi quod…

Cyril Brulebois dixit:

Next time, can you please put the right people in the loop?!
[…]
is just plain stupid. Maintainers of the package you're reassigning to
don't get your control mail. Way to communicate!

I did not know that. I think this is a debbugs bug; it’s inconsistent
to require of the bug submitter to manually look up maintainers (for
example, I wasn’t aware debootstrap has anything to do with booting
Debian…) when reassigning, when one doesn’t have to do so normally.

Please, when bugs are reassigned, inform both maintainer sets, those
of the old and those of the new package.

Thanks,
//mirabilos
-- 
ch you introduced a merge commit│mika % g rebase -i HEAD^^
mika sorry, no idea and rebasing just fscked │mika Segmentation
ch should have cloned into a clean repo  │  fault (core dumped)
ch if I rebase that now, it's really ugh │mika:#grml wuahh


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

Bug#703479: [Packaging] Bug#703479: munin: Huge munin-graph log with cron graph_strategy

2013-04-08 Thread Michael Shuler

On 04/08/2013 07:14 AM, Michael Shuler wrote:
 it appears that I am missing several minutes of log lines between the
 end of munin-graph.log.1.gz and the beginning of munin-graph.log.

Clarification: it appears that I'm missing most of the log line entries
of one graph run (not several minutes). The first couple graphs are
logged, then the rest of the 25-ish graph log lines are gone during
rotation/gzip.

-- 
Kind regards,
Michael


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

Bug#704985: git-daemon-sysvinit: GIT_DAEMON_BASE_PATH missing in /etc/default/git-daemon

2013-04-08 Thread Alexander Dahl

Package: git-daemon-sysvinit
Version: 1:1.7.10.4-2
Severity: minor

Dear Maintainer,

when changing GIT_DAEMON_DIRECTORY in the /etc/default/git-daemon
coming with the package to e.g. /srv/repos/git the git-daemon is still
called with --base-path=/var/cache because GIT_DAEMON_BASE_PATH has
the default value from /etc/init.d/git-daemon but is not included in
/etc/default/git-daemon which leads to a path not found error. I could
fix this by adding GIT_DAEMON_BASE_PATH='/srv/repos' to my
/etc/default/git-daemon so I guess it would be nice to deliver a
better template or default /etc/default/git-daemon containg
GIT_DAEMON_BASE_PATH or improve /usr/share/doc/git-daemon/README*

HTH  Greets
Alex

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

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

Versions of packages git-daemon-sysvinit depends on:
ii  adduser  3.113+nmu3
ii  git  1:1.7.10.4-2

git-daemon-sysvinit recommends no packages.

git-daemon-sysvinit suggests no packages.

-- no debconf information


pgpejKng8tNeK.pgp
Description: PGP signature

Bug#557879: graphicsmagick: please build with --with-quantum-depth=16

2013-04-08 Thread Andreas Tille

On Sun, 14 Oct 2012, Daniel Kobras kob...@debian.org wrote:

 Am 10.08.2012 um 17:19 schrieb Bob Friesenhahn bfrie...@simple.dallas.tx.us:
  This does not solve the problem.  The easiest way to solve the problem is 
  to use different library names for the Q16 build of GraphicsMagick. The 
  modules are not a problem since they are already in a specific directory.

 In upstream version 1.3.17, Bob has implemented a way to encode the quantum 
 depth into the library SONAME. This gives us with a clean way to provide Q8 
 and Q16 packages in parallel. (Post-wheezy, though.)

Are you able to propose a patch for the Build system.  I'd be interested
to test it because I'm considering packaging photivo[1] where this is a
known bug[2] as well.

BTW, I'd consider to bump the severity of this bug from wishlist to normal
because it affects several dependencies.

Kind regards

   Andreas.

[1] http://photivo.org
[2] http://photivo.org/photivo/download_and_setup/linux#graphicsmagick_16_bit

-- 
http://fam-tille.de


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

Bug#703209: linux: Please Add multiplatform flavour to armhf

2013-04-08 Thread Hector Oron

Hello,

2013/4/2 Nobuhiro Iwamatsu iwama...@nigauri.org:

 Then, the two candidates have come armmp and armv7.
 Which do you like?
 if there is no other opinions, I would want to decide on armmp.

armmp ++


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

Bug#704982: [pkg-horde] Bug#704982: php-horde-cache: Class 'Horde_Compress_Fast' not found

2013-04-08 Thread Mathieu Parent

2013/4/8 Michael Fladischer fladischermich...@fladi.at:
 Package: php-horde-cache
 Version: 2.0.3-1
 Severity: normal

 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA1

 Dear Maintainer,

 it seems that Cache.php is referencing a compression library that is not 
 shipped by php-horde-compress:

 PHP Fatal error:  Class 'Horde_Compress_Fast' not found in 
 /usr/share/php/Horde/Cache.php on line 103
 PHP Fatal error:  Class 'Horde_Compress_Fast' not found in 
 /usr/share/php/Horde/Cache.php on line 120

Horde_Compress_Fast is in the NEW queue.

 There is no package to satisfy Recommends:php-horde-compress-fast rigth now.
 I would not consider this important if it would only impact caching, but 
 right now, it breaks horde installations that have caching enabled.

Yes, it should probably disable caching in this case. I will ask upstream.

Regards
--
Mathieu


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

Bug#691144: same here, testing amd64 3.2.0-4-amd64 #1 SMP Debian 3.2.41-2 x86_64 GNU/Linux

2013-04-08 Thread Jamil Djadala


Hi,
I see same messages in dmesg, debian testing, see attached file.

-- 
Jamil Djadala
[ 3336.437544] BUG: Bad page map in process /usr/share/muni  
pte:8001d5a44067 pmd:186506067
[ 3336.437548] page:ea00066bbee0 count:3 mapcount:-128 
mapping:8801c3dcb708 index:0x0
[ 3336.437550] page flags: 
0x200087c(referenced|uptodate|dirty|lru|active|private)
[ 3336.437555] addr:7fb3a4f03000 vm_flags:080100fb anon_vma:  
(null) mapping:8801c3dcb708 index:0
[ 3336.437560] vma-vm_ops-fault: filemap_fault+0x0/0x33e
[ 3336.437587] vma-vm_file-f_op-mmap: btrfs_file_mmap+0x0/0x45 [btrfs]
[ 3336.437590] Pid: 19833, comm: /usr/share/muni Tainted: P   O 
3.2.0-4-amd64 #1 Debian 3.2.41-2
[ 3336.437591] Call Trace:
[ 3336.437596]  [810ce1f1] ? print_bad_pte+0x1a5/0x1bd
[ 3336.437598]  [810cde51] ? pte_pfn+0x5/0xe
[ 3336.437601]  [810cfe58] ? unmap_vmas+0x4d5/0x6ca
[ 3336.437604]  [810d3e18] ? unmap_region+0x9f/0xf1
[ 3336.437606]  [810d4ee8] ? do_munmap+0x292/0x2f3
[ 3336.437608]  [810d5077] ? sys_munmap+0x3c/0x52
[ 3336.437612]  [81352952] ? system_call_fastpath+0x16/0x1b
[ 3350.904806] BUG: Bad page map in process munin-graph  pte:8001d5a44025 
pmd:186f85067
[ 3350.904810] page:ea00066bbee0 count:3 mapcount:-128 
mapping:8801c3dcb708 index:0x0
[ 3350.904812] page flags: 
0x200087c(referenced|uptodate|dirty|lru|active|private)
[ 3350.904817] addr:7f7e64bb2000 vm_flags:08210071 anon_vma:  
(null) mapping:8801c3dcb708 index:0
[ 3350.904822] vma-vm_ops-fault: filemap_fault+0x0/0x33e
[ 3350.904849] vma-vm_file-f_op-mmap: btrfs_file_mmap+0x0/0x45 [btrfs]
[ 3350.904852] Pid: 20596, comm: munin-graph Tainted: PB  O 
3.2.0-4-amd64 #1 Debian 3.2.41-2
[ 3350.904854] Call Trace:
[ 3350.904858]  [810ce1f1] ? print_bad_pte+0x1a5/0x1bd
[ 3350.904861]  [810cde51] ? pte_pfn+0x5/0xe
[ 3350.904863]  [810cfe58] ? unmap_vmas+0x4d5/0x6ca
[ 3350.904866]  [810d3e18] ? unmap_region+0x9f/0xf1
[ 3350.904869]  [810bd1b9] ? force_page_cache_readahead+0x5f/0x83
[ 3350.904871]  [810d4ee8] ? do_munmap+0x292/0x2f3
[ 3350.904873]  [810d5077] ? sys_munmap+0x3c/0x52
[ 3350.904877]  [81352952] ? system_call_fastpath+0x16/0x1b
[ 3350.908725] BUG: Bad page map in process munin-graph  pte:8001d5a44025 
pmd:186f85067
[ 3350.908727] page:ea00066bbee0 count:3 mapcount:-128 
mapping:8801c3dcb708 index:0x0
[ 3350.908729] page flags: 
0x200087c(referenced|uptodate|dirty|lru|active|private)
[ 3350.908732] addr:7f7e64bb2000 vm_flags:08210071 anon_vma:  
(null) mapping:8801c3dcb708 index:0
[ 3350.908737] vma-vm_ops-fault: filemap_fault+0x0/0x33e
[ 3350.908752] vma-vm_file-f_op-mmap: btrfs_file_mmap+0x0/0x45 [btrfs]
[ 3350.908754] Pid: 20596, comm: munin-graph Tainted: PB  O 
3.2.0-4-amd64 #1 Debian 3.2.41-2
[ 3350.908755] Call Trace:
[ 3350.908758]  [810ce1f1] ? print_bad_pte+0x1a5/0x1bd
[ 3350.908760]  [810cde51] ? pte_pfn+0x5/0xe
[ 3350.908762]  [810cfe58] ? unmap_vmas+0x4d5/0x6ca
[ 3350.908766]  [810d3e18] ? unmap_region+0x9f/0xf1
[ 3350.908769]  [810bd1b9] ? force_page_cache_readahead+0x5f/0x83
[ 3350.908773]  [810d4ee8] ? do_munmap+0x292/0x2f3
[ 3350.908776]  [810d5077] ? sys_munmap+0x3c/0x52
[ 3350.908780]  [81352952] ? system_call_fastpath+0x16/0x1b
[ 3350.908798] BUG: Bad page map in process munin-graph  pte:8001d5a44025 
pmd:186f85067
[ 3350.908801] page:ea00066bbee0 count:3 mapcount:-128 
mapping:8801c3dcb708 index:0x0
[ 3350.908804] page flags: 
0x200087c(referenced|uptodate|dirty|lru|active|private)
[ 3350.908808] addr:7f7e64bb2000 vm_flags:08210071 anon_vma:  
(null) mapping:8801c3dcb708 index:0
[ 3350.908812] vma-vm_ops-fault: filemap_fault+0x0/0x33e
[ 3350.908823] vma-vm_file-f_op-mmap: btrfs_file_mmap+0x0/0x45 [btrfs]
[ 3350.908825] Pid: 20596, comm: munin-graph Tainted: PB  O 
3.2.0-4-amd64 #1 Debian 3.2.41-2
[ 3350.908826] Call Trace:
[ 3350.908828]  [810ce1f1] ? print_bad_pte+0x1a5/0x1bd
[ 3350.908830]  [810cde51] ? pte_pfn+0x5/0xe
[ 3350.908831]  [810cfe58] ? unmap_vmas+0x4d5/0x6ca
[ 3350.908835]  [810d3e18] ? unmap_region+0x9f/0xf1
[ 3350.908838]  [810bd1b9] ? force_page_cache_readahead+0x5f/0x83
[ 3350.908841]  [810d4ee8] ? do_munmap+0x292/0x2f3
[ 3350.908844]  [810d5077] ? sys_munmap+0x3c/0x52
[ 3350.908848]  [81352952] ? system_call_fastpath+0x16/0x1b
[ 3350.908866] BUG: Bad page map in process munin-graph  pte:8001d5a44025 
pmd:186f85067
[ 3350.908868] page:ea00066bbee0 count:3 mapcount:-128 
mapping:8801c3dcb708 index:0x0
[ 3350.908869] page flags: 
0x200087c(referenced|uptodate|dirty|lru|active|private)
[ 3350.908872] addr:7f7e64bb2000 vm_flags:08210071 anon_vma:  
(null) mapping:8801c3dcb708

Bug#704744: pbuilder: umounts /{dev,run}/shm of the host system