Bug#742603: exp-sgcheck: sg_main.c:560 (add_blocks_to_StackTree): Assertion '!already_present' failed.

[Mathieu Malaterre]

Package: valgrind
Version: 1:3.9.0-5

I have extracted a section of code from openjpeg which seems to be
driving valgrind/exp-sgcheck nuts. See attached demo.c file.

Steps (dwarf-4 and stack-protector are important):

$ gcc  -gdwarf-4  -fstack-protector   demo.c
$ valgrind --tool=exp-sgcheck  ./a.out
==17451== exp-sgcheck, a stack and global array overrun detector
==17451== NOTE: This is an Experimental-Class Valgrind Tool
==17451== Copyright (C) 2003-2013, and GNU GPL'd, by OpenWorks Ltd et al.
==17451== Using Valgrind-3.9.0 and LibVEX; rerun with -h for copyright info
==17451== Command: ./a.out
==17451==

exp-sgcheck: sg_main.c:560 (add_blocks_to_StackTree): Assertion
'!already_present' failed.
==17451==at 0x380278CC: report_and_quit (m_libcassert.c:260)
==17451==by 0x38027A26: vgPlain_assert_fail (m_libcassert.c:340)
==17451==by 0x3801EE00: add_blocks_to_StackTree (sg_main.c:560)
==17451==by 0x38020321: shadowStack_new_frame.isra.12 (sg_main.c:1875)
==17451==by 0x806427FDC: ???
==17451==by 0x8034DBECF: ???

sched status:
  running_tid=1

Thread 1: status = VgTs_Runnable
==17451==at 0x4005B7: main (demo.c:39)


Note: see also the FAQ in the source distribution.
It contains workarounds to several common problems.
In particular, if Valgrind aborted or crashed after
identifying problems in your program, there's a good chance
that fixing those problems will prevent Valgrind aborting or
crashing, especially if it happened in m_mallocfree.c.

If that doesn't help, please report this bug to: www.valgrind.org

In the bug report, send all the above text, the valgrind
version, and what OS and version you are using.  Thanks.


Where:

$ gcc --version
gcc (Debian 4.7.2-5) 4.7.2
Copyright (C) 2012 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
$ uname -a
Linux larcenet 3.12-0.bpo.1-amd64 #1 SMP Debian 3.12.6-2~bpo70+1
(2014-01-07) x86_64 GNU/Linux
#include 
#include 

typedef uint32_t OPJ_UINT32;
typedef int OPJ_COLOR_SPACE;
typedef void opj_image_comp_t;
typedef uint8_t OPJ_BYTE;

typedef struct opj_image_comptparm {
	OPJ_UINT32 dx;
	OPJ_UINT32 dy;
	OPJ_UINT32 w;
	OPJ_UINT32 h;
	OPJ_UINT32 x0;
	OPJ_UINT32 y0;
	OPJ_UINT32 prec;
	OPJ_UINT32 bpp;
	OPJ_UINT32 sgnd;
} opj_image_cmptparm_t;

typedef struct opj_image {
	OPJ_UINT32 x0;
	OPJ_UINT32 y0;
	OPJ_UINT32 x1;
	OPJ_UINT32 y1;
	OPJ_UINT32 numcomps;
	OPJ_COLOR_SPACE color_space;
	opj_image_comp_t *comps;
	OPJ_BYTE *icc_profile_buf;
	OPJ_UINT32 icc_profile_len;
} opj_image_t;

int main(int argc, char *argv[])
{
  opj_image_t *image;
  opj_image_cmptparm_t cmptparm[4];
  unsigned char sigbuf[8];

  memset(cmptparm, 0, sizeof(cmptparm));

  return 0;
}

Bug#742572: asc: Please update to use wxwidgets3.0

[Markus Koschany]

control: tags -1 pending

Hi Olly,

thanks for your report. I've already prepared a new upstream version of
asc that will switch to wxwidgets3.0. I'm currently waiting for a reply
of my sponsor but I suppose the upload will happen in the course of this
week.

Regards,

Markus



signature.asc
Description: OpenPGP digital signature

Bug#721420: Pending fixes for bugs in the libdevel-bt-perl package

[pkg-perl-maintainers]

tag 721420 + pending
thanks

Some bugs in the libdevel-bt-perl package are closed in revision
72cb3fb7b11292e1cde7f62c61500e1787e2256f in branch 'master' by Daniel
Lintott

The full diff can be seen at
http://anonscm.debian.org/gitweb/?p=pkg-perl/packages/libdevel-bt-perl.git;a=commitdiff;h=72cb3fb

Commit message:

Add patch to fix FTBFS on hurd

Closes: #721420


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

Bug#742603: Acknowledgement (exp-sgcheck: sg_main.c:560 (add_blocks_to_StackTree): Assertion '!already_present' failed.)

[Mathieu Malaterre]

Control: forwarded -1 https://bugs.kde.org/show_bug.cgi?id=332577


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

Bug#742606: cross-ma-install-location.diff: src/libmudflap/configure.ac No file to patch

[Yunqiang Su]

Package: gcc-4.9
Version: 4.9-20140322-1

In the source of gcc-4.9, it seems that it have no src/libmudflap any more,
while in cross-ma-install-location.diff, there is still some snap about it.

Please consider drop it.

-- 
Yunqiang Su


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

Bug#742513: [PATCH] Attempt SSHFP lookup even if server presents a certificate

[matthew]

From: Matthew Vernon 

If an ssh server presents a certificate to the client, then the client
does not check the DNS for SSHFP records. This means that a malicious
server can essentially disable DNS-host-key-checking, which means the
client will fall back to asking the user (who will just say "yes" to
the fingerprint, sadly).

This patch means that the ssh client will, if necessary, extract the
server key from the proffered certificate, and attempt to verify it
against the DNS. The patch was written by Mark Wooding
. I modified it to add one debug2 call, reviewed
it, and tested it.

Signed-off-by: Matthew Vernon 
Bug-Debian: http://bugs.debian.org/742513
---
 sshconnect.c |   67 --
 1 file changed, 47 insertions(+), 20 deletions(-)

diff --git a/sshconnect.c b/sshconnect.c
index 87c3770..b8510d2 100644
--- a/sshconnect.c
+++ b/sshconnect.c
@@ -1218,36 +1218,63 @@ fail:
return -1;
 }
 
+static int
+check_host_key_sshfp(char *host, struct sockaddr *hostaddr, Key *host_key)
+{
+   int rc = -1;
+   int flags = 0;
+   Key *raw_key = NULL;
+
+   if (!options.verify_host_key_dns)
+   goto done;
+
+   /* XXX certs are not yet supported for DNS; try looking the raw key
+* up in the DNS anyway.
+*/
+   if (key_is_cert(host_key)) {
+ debug2("Extracting key from cert for SSHFP lookup");
+   raw_key = key_from_private(host_key);
+   if (key_drop_cert(raw_key))
+   fatal("Couldn't drop certificate");
+   host_key = raw_key;
+   }
+
+   if (verify_host_key_dns(host, hostaddr, host_key, &flags))
+   goto done;
+
+   if (flags & DNS_VERIFY_FOUND) {
+
+   if (options.verify_host_key_dns == 1 &&
+   flags & DNS_VERIFY_MATCH &&
+   flags & DNS_VERIFY_SECURE) {
+   rc = 0;
+   } else if (flags & DNS_VERIFY_MATCH) {
+   matching_host_key_dns = 1;
+   } else {
+   warn_changed_key(host_key);
+   error("Update the SSHFP RR in DNS with the new "
+ "host key to get rid of this message.");
+   }
+   }
+
+done:
+   if (raw_key)
+   key_free(raw_key);
+   return rc;
+}
+
 /* returns 0 if key verifies or -1 if key does NOT verify */
 int
 verify_host_key(char *host, struct sockaddr *hostaddr, Key *host_key)
 {
-   int flags = 0;
char *fp;
 
fp = key_fingerprint(host_key, SSH_FP_MD5, SSH_FP_HEX);
debug("Server host key: %s %s", key_type(host_key), fp);
free(fp);
 
-   /* XXX certs are not yet supported for DNS */
-   if (!key_is_cert(host_key) && options.verify_host_key_dns &&
-   verify_host_key_dns(host, hostaddr, host_key, &flags) == 0) {
-   if (flags & DNS_VERIFY_FOUND) {
-
-   if (options.verify_host_key_dns == 1 &&
-   flags & DNS_VERIFY_MATCH &&
-   flags & DNS_VERIFY_SECURE)
-   return 0;
-
-   if (flags & DNS_VERIFY_MATCH) {
-   matching_host_key_dns = 1;
-   } else {
-   warn_changed_key(host_key);
-   error("Update the SSHFP RR in DNS with the new "
-   "host key to get rid of this message.");
-   }
-   }
-   }
+   if (check_host_key_sshfp(host, hostaddr, host_key) == 0)
+   return 0;
 
return check_host_key(host, hostaddr, options.port, host_key, RDRW,
options.user_hostfiles, options.num_user_hostfiles,
-- 
1.7.10.4


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

Bug#623634: libnet-rawip-perl: miscalculates header checksums

[Christoph Pleger]

My perl script works if libnet-rawip-perl is compiled with gcc 4.6 .


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

Bug#742602: [DPkg::Post-Invoke] needrestart should run before how-can-i-help

[Axel Beckert]

Hi,

a minor correction:

Axel Beckert wrote:
> localepurge runs before needsrestart as run-parts seem to use C-locale
> ordering.
[...]
> 99-localepurge only outputs a few lines, so it's only a minor issue if
> it runs after how-can-i-help. Feel free to clone this bug report against
> localepurge,how-can-i-help if think this is worth being fixed, too.

Forget that latter paragraph. I wrote before I noticed that the
sorting order of run-parts is not the same as the one of ls in my
default locale.

Regards, Axel
-- 
 ,''`.  |  Axel Beckert , http://people.debian.org/~abe/
: :' :  |  Debian Developer, ftp.ch.debian.org Admin
`. `'   |  1024D: F067 EA27 26B9 C3FC 1486  202E C09E 1D89 9593 0EDE
  `-|  4096R: 2517 B724 C5F6 CA99 5329  6E61 2FF9 CD59 6126 16B5


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

Bug#738955: same here

[Klaumi Klingsporn]

Hi folks,

I had the same problem here after the upgrade of freedict packages,
and yes Nikolay, you're right: goldendict should recognize the change
of dictionary-files an reindex them. 

But there's no need to delete the whole personal configuration in
~/.goldendict, you only need to delete the goldendict indices in
~/.goldendict/index. Goldendict will rebuild them at the next start
and voilá: all dictionaries will work again :-)

klaumi

--- 
Klaumi Klingsporn
mail: klaumi...@gmx.de
web: www.klaumikli.de


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

Bug#741543: When build for mips64el, the default target is mipsn32el

[Richard Sandiford]

Yunqiang Su  writes:
> s/gnuabin64/gnuabi64/
>
> just a typo.
>
> --- gcc-4.9-4.9-20140322.orig/src/gcc/config.gcc2014-03-25
> 11:06:44.935298703 +
> +++ gcc-4.9-4.9-20140322/src/gcc/config.gcc 2014-03-25
> 11:07:39.087774543 +
> @@ -1963,6 +1963,9 @@
> tmake_file="${tmake_file} mips/t-linux64"
> tm_defines="${tm_defines} MIPS_ABI_DEFAULT=ABI_N32"
> case ${target} in
> +   *gnuabi64*)
> +   tm_defines=$(echo ${tm_defines}| sed
> 's/MIPS_ABI_DEFAULT=ABI_N32/MIPS_ABI_DEFAULT=ABI_64/g')
> +   ;;
> mips64el-st-linux-gnu)
> tm_file="${tm_file} mips/st.h"
> tmake_file="${tmake_file} mips/t-st"

I think the new code should be in a separate case statement, since it's
orthogonal to the mips64octeon/mipsisa64r2 choice.  With that change it
looks good though.

Thanks,
Richard


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

Bug#735940: Sourceless file

[Zooko Wilcox-OHearn]

I'm a maintainer of Tahoe-LAFS. I just opened a ticket to track this
issue in our issue tracker:

https://tahoe-lafs.org/trac/tahoe-lafs/ticket/2208

Regards,

Zooko Wilcox-O'Hearn

Founder, CEO, and Customer Support Rep
https://LeastAuthority.com
Freedom matters.


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

Bug#742607: icecc: add clang and clang++ symbolic links to /usr/lib/icecc/bin

[Alberto Garcia]

Package: icecc
Version: 1.0.1-1
Severity: wishlist

Hi!

The /usr/lib/icecc/bin contains symlinks for cc, gcc, c++ and g++. It
would be nice to have clang and clang++ as well if that compiler is
available in the system.

I use clang often and at the moment I have to use "icecc clang" as my
compiler, which does not always work with all build systems.

Berto

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

Kernel: Linux 3.11-2-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 icecc depends on:
ii  adduser 3.113+nmu3
ii  clang-3.4 [c-compiler]  1:3.4-2
ii  file1:5.17-1
ii  g++ [c++-compiler]  4:4.8.2-2
ii  g++-4.8 [c++-compiler]  4.8.2-16
ii  gcc [c-compiler]4:4.8.2-2
ii  gcc-4.8 [c-compiler]4.8.2-16
ii  libc6   2.18-4
ii  libgcc1 1:4.8.2-16
ii  libstdc++6  4.8.2-16
ii  lsb-base4.1+Debian12

Versions of packages icecc recommends:
ii  logrotate  3.8.7-1

Versions of packages icecc suggests:
ii  icecc-monitor  2.9.90~git20140222-1

-- Configuration Files:
/etc/icecc/icecc.conf changed [not included]

-- 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#735940:

[Zooko Wilcox-OHearn]

Would it satisfy the Debian policy if those Javascript files were
stored in source form instead of minified form?

Regards,

Zooko Wilcox-O'Hearn

Founder, CEO, and Customer Support Rep
https://LeastAuthority.com
Freedom matters.


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

Bug#742608: Critical bug fixes for be2net driver

[Suresh Kumar Reddy Reddygari]

Package:src:linux
Version:3.13.6
Severity:important

Opening Bug to submit certain 17 fixes to be2net driver


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

Bug#742015: Seeing this bug, too

[Jan-Benedict Glaw]

Hi!

Using `duply' as a frontend, we're experiencing this bug in recent
weeks, too.  Duplicity used to work, automatically using user's
~/.ssh/id_rsa key without further config.

  Out of curiosity, we added
--ssh-options=-oIdentityFile=/.../.ssh/id_rsa, but it seems (using
`duply') this strangely breaks GPG encryption when it's really used,
though it works initially when it tests to sign and encrypt with that
very key.

  What's even more interesting is that, as said, is just used to work
and then gradually failed more often in a timespan of, say, three or
four weeks. It's now at about 100% failure. I see that it seems there
was an auto-update of Python 2.7 in that timespan, though
python-paramiko wasn't updated.

MfG, JBG

-- 
Getslash GmbH, Bahnhofstraße 16, 59302 Oelde
Tel: +49-2522-834349-5Fax:   +49-2522-834349-1
http://www.getslash.deMobil: +49-152-33822499
Sitz der Gesellschaft: Oelde
Handelsregister: Amtsgericht Münster, HRB 11911
Ust-Id-Nr.: DE 815060326
Geschäftsführung: Andre Peitz, Tobias Hanisch


signature.asc
Description: Digital signature

Bug#741221: Need more (legal) information

[Charles Plessy]

Le Tue, Mar 25, 2014 at 12:06:53PM +0100, Thibaut Varène a écrit :
> 
> The kanjidic documentation states (emphasis is mine):
> 
> > The following people have granted permission for material for which they
> > hold copyright to be included in the files, _and distributed under the
> > above conditions_, while retaining their copyright over that material:
> > 
> > Jack HALPERN: The SKIP codes in the KANJIDIC file.
> 
> As I understand this, kanjidic and the SKIP codes it embeds are freely
> redistributable under the licensing terms of kanjidic.
> 
> That other licensing provisions for the SKIP codes may be made in other use
> cases (as detailed in Appendix F of the same document) seems quite irrelevant
> to me: you are questioning the DFSG-compliance of kanjidic (and by extension
> the package that includes it: tagainijisho) and as far as I can see, the
> whole content of the file `tagainijisho-[version
> number]/3rdparty/kanjidic2.xml', including the SKIP codes, are covered by the
> license stated at the top of the file: CC-BY-SA, which is DFSG-compliant.

Hi Thibaut,

looking at the link you sent, it seems that the “above conditions” are
“KANJIDIC can be freely used provided satisfactory acknowledgement is made, and
a number of other conditions are met”, which is quite vague.  In addition, just
below the part that you cited (“Jack HALPERN: The SKIP codes in the KANJIDIC
file.”), there is “With regard to the SKIP codes, Mr Halpern draws your
attention to the statement he has prepared on the matter, which is included at
Appendix F.”

To me, it appears that Appendix F, which has non-Free clauses, applies.

Have you tried to contact the authors of KANJIDIC ?

Have a nice day,

-- 
Charles Plessy
Tsurumi, Kanagawa, Japan


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

Bug#737982: oneko: please provide a desktop file and icons

[Markus Koschany]

Control: tags -1 patch

Dear maintainer,

please find attached a patch that achieves the following:

* Add oneko.desktop file.
* Update menu file and add icon entries.
* Add imagemagick to Build-Depends and create new icons for the desktop
  and menu file. Add the newly created images to the clean file.
  (Closes: #737982)

The new desktop file also provides Action entries with whom you can
quickly execute the same commands that are already provided in the menu
file. Users of Gnome3 just need to install

https://extensions.gnome.org/extension/322/quicklists/

for example so that those actions can be accessed from Gnome Shell with
a right-click on the desktop icon.

Regards,

Markus
From 8c1a138473bf3304382d1fbdefd3c33fca86b38e Mon Sep 17 00:00:00 2001
From: Markus Koschany 
Date: Tue, 25 Mar 2014 13:23:56 +0100
Subject: [PATCH] fix 737982

---
 debian/changelog | 11 +++
 debian/clean |  3 +++
 debian/control   |  2 +-
 debian/install   |  6 +-
 debian/menu  | 21 +++--
 debian/oneko.desktop | 22 ++
 debian/rules |  3 +++
 7 files changed, 60 insertions(+), 8 deletions(-)
 create mode 100644 debian/oneko.desktop

diff --git a/debian/changelog b/debian/changelog
index 615c2d9..c10e131 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,14 @@
+oneko (1.2.sakura.6-9.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Add oneko.desktop file.
+  * Update menu file and add icon entries.
+  * Add imagemagick to Build-Depends and create new icons for the desktop and
+menu file. Add the newly created images to the clean file.
+(Closes: #737982)
+
+ -- Markus Koschany   Tue, 25 Mar 2014 13:21:28 +0100
+
 oneko (1.2.sakura.6-9) unstable; urgency=low
 
   * debian/control, debian/compat, debian/rules
diff --git a/debian/clean b/debian/clean
index a3ee268..8ee9437 100644
--- a/debian/clean
+++ b/debian/clean
@@ -1 +1,4 @@
 oneko
+oneko_cat.xpm
+oneko_dog.xpm
+oneko_stop.xpm
diff --git a/debian/control b/debian/control
index 8d8cb99..3c34b6d 100644
--- a/debian/control
+++ b/debian/control
@@ -2,7 +2,7 @@ Source: oneko
 Section: games
 Priority: optional
 Maintainer: Ricardo Mones 
-Build-Depends: debhelper (>= 9), libx11-dev, libxext-dev
+Build-Depends: debhelper (>= 9), libx11-dev, libxext-dev, imagemagick
 Standards-Version: 3.9.4
 Homepage: http://www.daidouji.com/oneko/
 Vcs-Git: git://anonscm.debian.org/users/mones/oneko.git
diff --git a/debian/install b/debian/install
index 98bd6c9..b902ced 100644
--- a/debian/install
+++ b/debian/install
@@ -1 +1,5 @@
-oneko usr/games
+oneko   usr/games
+oneko_cat.xpm   usr/share/pixmaps
+oneko_dog.xpm   usr/share/pixmaps
+oneko_stop.xpm  usr/share/pixmaps
+debian/oneko.desktopusr/share/applications
diff --git a/debian/menu b/debian/menu
index 77b784b..47c33fb 100644
--- a/debian/menu
+++ b/debian/menu
@@ -1,6 +1,15 @@
-?package(oneko):needs="X11" section="Games/Toys" \
-  title="oneko/cat" command="oneko -fg black -bg white"
-?package(oneko):needs="X11" section="Games/Toys" \
-  title="oneko/dog" command="oneko -dog -fg black -bg white"
-?package(oneko):needs="X11" section="Games/Toys" \
-  title="oneko/stop" command="killall -TERM oneko"
+?package(oneko):needs="X11" \
+  section="Games/Toys" \
+  title="oneko/cat" \
+  command="oneko -fg black -bg white" \
+  icon="/usr/share/pixmaps/oneko_cat.xpm"
+?package(oneko):needs="X11" \
+  section="Games/Toys" \
+  title="oneko/dog" \
+  command="oneko -dog -fg black -bg white" \
+  icon="/usr/share/pixmaps/oneko_dog.xpm"
+?package(oneko):needs="X11" \
+  section="Games/Toys" \
+  title="oneko/stop" \
+  command="killall -TERM oneko" \
+  icon="/usr/share/pixmaps/oneko_stop.xpm"
diff --git a/debian/oneko.desktop b/debian/oneko.desktop
new file mode 100644
index 000..383480d
--- /dev/null
+++ b/debian/oneko.desktop
@@ -0,0 +1,22 @@
+[Desktop Entry]
+Version=1.0
+Type=Application
+Name=Oneko Cat
+Comment=a cat chases the cursor around the screen
+Comment[de]=eine Katze verfolgt den Cursor über den Bildschirm
+Exec=oneko -fg black -bg white
+Icon=oneko_cat
+Terminal=false
+Categories=Game;ActionGame;
+Keywords=neko;cat;dog;chase;cursor;mouse;
+Actions=Dog;Stop;
+
+[Desktop Action Dog]
+Exec=oneko -dog -fg black -bg white
+Name=Oneko Dog
+Icon=oneko_dog
+
+[Desktop Action Stop]
+Exec=killall -TERM oneko
+Name=Oneko STOP
+Icon=oneko_stop
diff --git a/debian/rules b/debian/rules
index fe0cbf3..3d0d3c4 100755
--- a/debian/rules
+++ b/debian/rules
@@ -17,6 +17,9 @@ build-stamp:
 		-L/usr/X11R6/lib -I/usr/include/X11 \
 		-lX11 -lXext -lm -DSHAPE \
 		-o oneko
+	convert -monitor bitmaps/neko/awake.xbm oneko_cat.xpm
+	convert -monitor bitmaps/dog/awake_dog.xbm oneko_dog.xpm
+	convert -monitor bitmaps/neko/sleep1.xbm oneko_stop.xpm
 	touch build-stamp
 
 override_dh_auto_install:
-- 
1.9.1



signature.asc
Description: OpenPGP digital signature

Bug#742563: linux: Black screen for internal laptop display on Intel HD Graphics 4400

[Julien Cristau]

Control: found -1 3.14~rc7-1~exp1
Control: notfound -1 3.14-rc7

On Mon, Mar 24, 2014 at 21:20:09 -0400, Matthew Horan wrote:

> Source: linux
> Version: 3.14-rc7

This is not a debian package version.

Cheers,
Julien


signature.asc
Description: Digital signature

Bug#742610: pmtools: "Null filename used" and "Use of uninitialized value" in pmvers tab completion

[Axel Beckert]

Package: pmtools
Version: 2.0.0-1
Severity: normal

Dear myself,

on Sid:

$ pmvers ModuUse of uninitialized value $_ in -e at (eval 1) line 1.
Use of uninitialized value in require at (eval 1) line 1.
/usr/bin/pmvers: Null filename used
le::
$ 

on Wheezy (1.10+ds1-2) at least the "Null filename used" is present,
too:

$ pmvers Modu/usr/bin/pmvers: Null filename used
le::

This are possibly different issues, cloning this issue for
tracking them separately may makes sense.

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

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

Versions of packages pmtools depends on:
ii  perl  5.18.2-2+b1

pmtools recommends no packages.

pmtools 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#742611: apt-cache: showsrc non-existent returning 0

[Maximiliano Curia]

Package: apt
Version: 0.9.16.1
Severity: normal
Tags: patch

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Hi,

apt-cache showsrc non-existent shows a W and a N message and returns 0, while
apt-cache show non-existent shows a W and an E message and returns 100.

The show approach makes it easier for scripts that rely on apt-cache, so I'm
attaching a simple patch for showsrc for this.

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

Kernel: Linux 3.14-rc7-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/bash

Versions of packages apt depends on:
ii  debian-archive-keyring  2012.4
ii  gnupg   1.4.16-1.1
ii  libapt-pkg4.12  0.9.16.1
ii  libc6   2.18-4
ii  libgcc1 1:4.8.2-17
ii  libstdc++6  4.8.2-17

apt recommends no packages.

Versions of packages apt suggests:
ii  apt-doc 0.9.16.1
ii  aptitude0.6.10-1
ii  dpkg-dev1.17.6
ii  python-apt  0.9.3.4
ii  synaptic0.81

- -- no debconf information

-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQIcBAEBCAAGBQJTMYU5AAoJEMcZdpmymyMqWwQP/Rkg4Jz3PtBWE+fjVrntnpdf
jar+BGAaZV54vGMI+YCjBv+yXNXedO3pJgNQXnxyPW0bezB4cVv1hCoX5fpv7d7e
kYzc0KyLnTwMqqYBcr+MB8ayvLxdsm9WDgo+rh4TgWKRBlaNp2MViHvMRSjCcE2i
FC1FrslWHKkAAWSpga902rjhxdp3+nmHLhRbMrEO1UrgCYPn4AKl6/Q8FZoMkrEV
jA6QJQ9csl3wBljkoXdh+FSxyKLlmZURrQr57mO4YzJ0XVj8IgCZrGL77q87MJlC
FTwSNXunh0ubPp4DVUNeFJ9dX798e5C8rCPfMKROli11NhbTNJuFyEE9nEJKFUPr
lBk+xjW0u+zC0gIIhjYiKRqFEGSL6uUO6RmZqkTV8st0ZitnQF7NlQNC7nyiLesS
gpvSVpqKmnRY5YIGaoUswmSUdZvH7uVe8gdLeFlP3L3k7Hm/ZtqQREesXvO0IfSr
7n6Ul5SJYwv7o+Z0peCQqELUdXA5viNprMTOLeILCNsCedOP0YwYPnkNl/78Uidb
FogRc1wRa9Gv1XFUjwSjHOQ1uKH4gt1ZzAvlVknfcNR6kWyJ7wt2BRxzqOCx27zP
d9vYLq57MIT0EfYS7M7ug+/y6qCQuhAki5i5szoTqOC637K7AQtAEMdwPZWT+mdi
AgL9Ls+Gv4hfO/GqK9jQ
=8HFg
-END PGP SIGNATURE-
commit cb67f44517d3861b24706fd7a122fe2f696e9090
Author: Maximiliano Curia 
Date:   Tue Mar 25 14:16:28 2014 +0100

apt-cache showsrc non-existent return code

Raise the message to error, and exit with a return code !=0
to make scripting easier.

diff --git a/cmdline/apt-cache.cc b/cmdline/apt-cache.cc
index 84b7753..97d01f4 100644
--- a/cmdline/apt-cache.cc
+++ b/cmdline/apt-cache.cc
@@ -1517,7 +1517,7 @@ static bool ShowSrcPackage(CommandLine &CmdL)
   }
}
if (found == 0)
-  _error->Notice(_("No packages found"));
+  return _error->Error(_("No packages found"));
return true;
 }
 	/*}}}*/

Bug#742245: how-can-i-help should have --gift interface esp. for newbies.

[shirish शिरीष]

in-line :-

On 3/24/14, Tomasz Nitecki  wrote:
> Hey,



> I will use existing filtering methods. Just change them a bit so
> everything works nicely (and -- can be called to temporarily
> override opportunities that are configured to be hidden).

That is good enough.



> I think that --show:, might be a little more
> readable. What do you think?

That is cool as well. Looking forward to the new release. I do hope
that you do include some query examples of the new functions in the
man-page so it's easier for people as well.

> Regards,
> T.

Looking forward to the new release.

Till l8er.
-- 
  Regards,
  Shirish Agarwal  शिरीष अग्रवाल
  My quotes in this email licensed under CC 3.0
http://creativecommons.org/licenses/by-nc/3.0/
http://flossexperiences.wordpress.com
065C 6D79 A68C E7EA 52B3  8D70 950D 53FB 729A 8B17


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

Bug#742612: cups: error updating cups on AMD64 wheezy machine

[Brent S. Elmer Ph.D.]

Package: cups
Version: 1.5.3-5+deb7u1
Severity: normal

I get the following errors when updateing cups on my AMD64 wheezy computer:

Setting up cups (1.5.3-5+deb7u1) ...
insserv: warning: script 'K99modelersrv' missing LSB tags and overrides
insserv: warning: script 'rc.modeler' missing LSB tags and overrides
insserv: There is a loop at service modelersrv if started
insserv: There is a loop between service minissdpd and mountnfs if started
insserv:  loop involving service mountnfs at depth 10
insserv:  loop involving service nfs-common at depth 9
insserv: Starting rc.modeler depends on minissdpd and therefore on system
facility `$all' which can not be true!
insserv: Starting rc.modeler depends on minissdpd and therefore on system
facility `$all' which can not be true!
insserv: Starting rc.modeler depends on minissdpd and therefore on system
facility `$all' which can not be true!
insserv: Starting rc.modeler depends on minissdpd and therefore on system
facility `$all' which can not be true!
insserv: Starting rc.modeler depends on minissdpd and therefore on system
facility `$all' which can not be true!
insserv: Starting rc.modeler depends on minissdpd and therefore on system
facility `$all' which can not be true!
insserv: Starting rc.modeler depends on minissdpd and therefore on system
facility `$all' which can not be true!
insserv: Starting rc.modeler depends on minissdpd and therefore on system
facility `$all' which can not be true!
insserv: Starting rc.modeler depends on minissdpd and therefore on system
facility `$all' which can not be true!
insserv: Starting rc.modeler depends on minissdpd and therefore on system
facility `$all' which can not be true!
insserv: Starting rc.modeler depends on minissdpd and therefore on system
facility `$all' which can not be true!
insserv: Starting rc.modeler depends on minissdpd and therefore on system
facility `$all' which can not be true!
insserv: Starting rc.modeler depends on minissdpd and therefore on system
facility `$all' which can not be true!
insserv: Starting rc.modeler depends on minissdpd and therefore on system
facility `$all' which can not be true!
insserv: Starting rc.modeler depends on minissdpd and therefore on system
facility `$all' which can not be true!
insserv: Starting rc.modeler depends on minissdpd and therefore on system
facility `$all' which can not be true!
insserv: Starting rc.modeler depends on minissdpd and therefore on system
facility `$all' which can not be true!
insserv: Starting rc.modeler depends on minissdpd and therefore on system
facility `$all' which can not be true!
insserv: Starting rc.modeler depends on minissdpd and therefore on system
facility `$all' which can not be true!
insserv: Starting rc.modeler depends on minissdpd and therefore on system
facility `$all' which can not be true!
insserv: Starting rc.modeler depends on minissdpd and therefore on system
facility `$all' which can not be true!
insserv: Starting rc.modeler depends on minissdpd and therefore on system
facility `$all' which can not be true!
insserv: Starting rc.modeler depends on minissdpd and therefore on system
facility `$all' which can not be true!
insserv: Starting rc.modeler depends on minissdpd and therefore on system
facility `$all' which can not be true!
insserv: Starting rc.modeler depends on minissdpd and therefore on system
facility `$all' which can not be true!
insserv: Starting rc.modeler depends on minissdpd and therefore on system
facility `$all' which can not be true!
insserv: Starting rc.modeler depends on minissdpd and therefore on system
facility `$all' which can not be true!
insserv: Starting rc.modeler depends on minissdpd and therefore on system
facility `$all' which can not be true!
insserv: Starting rc.modeler depends on minissdpd and therefore on system
facility `$all' which can not be true!
insserv: Starting rc.modeler depends on minissdpd and therefore on system
facility `$all' which can not be true!
insserv: Starting rc.modeler depends on minissdpd and therefore on system
facility `$all' which can not be true!
insserv: Starting rc.modeler depends on minissdpd and therefore on system
facility `$all' which can not be true!
insserv: Starting rc.modeler depends on minissdpd and therefore on system
facility `$all' which can not be true!
insserv: Starting rc.modeler depends on minissdpd and therefore on system
facility `$all' which can not be true!
insserv: Starting rc.modeler depends on minissdpd and therefore on system
facility `$all' which can not be true!
insserv: Starting rc.modeler depends on minissdpd and therefore on system
facility `$all' which can not be true!
insserv: Starting rc.modeler depends on minissdpd and therefore on system
facility `$all' which can not be true!
insserv: Starting rc.modeler depends on minissdpd and therefore on system
facility `$all' which can not be true!
insserv: Starting rc.modeler depends on minissdpd and therefore on system
facility `$all' which can not be true!
insserv: Starting rc.modeler depends on

Bug#735940:

[Olivier Schwander]

Le 25 Mar 2014 13:07, Zooko Wilcox-OHearn a écrit:
> Would it satisfy the Debian policy if those Javascript files were
> stored in source form instead of minified form?

The Debian policy is to avoid shipping external libraries inside a
source package. Since libjs-jquery (1.7.2+dfsg-1) and libjs-d3
(3.3.13-1) are available in sid, the best is to use the minified js
files provided by these two packages. Before doing that, we should check
tahoe-lafs is really working with these version, since they are
different from the ones provided with tahoe-lafs.

Best,

Olivier


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

Bug#736481: nettoe: FTBFS due to test suite failures

[Dejan Latinovic]

Hello,

It seems that libncurses5-dev is added as build dependency
at latest version (1.5-1) of nettoe.
Due to that, libncurses5-dev and libtinfo-dev
were installed.
On configuration, term.h and libtermcap.so
were found and it is guessed that TERM environment variable is defined.
That was not the case in previous version (1.4.2-1),
so nettoe has been built successfully.

I have not figured out why TERM is defined on some 
build machines, and on others is not.

However, it is possible to build nettoe
without terminfo if TERM environment variable
is not defined.

A patch that contains these changes is attached.

Could you consider applying this patch?


Regards,
Dejan
--- nettoe-1.5.orig/debian/rules	2013-11-29 16:26:18.0 +
+++ nettoe-1.5/debian/rules	2014-03-19 17:34:36.0 +
@@ -4,11 +4,16 @@
 
 include /usr/share/dpkg/buildflags.mk
 
+ifndef TERM
+CONFIG_EXTRA=--without-terminfo
+endif
+
 %:
 	dh $@ --with autoreconf
 
 override_dh_auto_configure:
-	./configure --prefix=/usr \
+	./configure $(CONFIG_EXTRA) \
+		--prefix=/usr \
 		--bindir=/usr/games \
 		--mandir=/usr/share/man \
 		--enable-desktop

Bug#742613: ITP: ocaml-ctypes -- library for binding to C libraries using pure OCaml

[Stéphane Glondu]

Package: wnpp
Severity: wishlist
Owner: Stéphane Glondu 

* Package name: ocaml-ctypes
  Version : 0.2.3
  Upstream Author : Jeremy Yallop
* URL : https://github.com/ocamllabs/ocaml-ctypes
* License : Expat
  Programming Lang: C, OCaml
  Description : library for binding to C libraries using pure OCaml

 The ocaml-ctypes library makes it possible to call C functions
 directly from OCaml without writing or generating C code.  The core
 of the library is a set of combinators for describing C types --
 scalars, functions, structs, unions, arrays, and pointers to values
 and functions.  Type descriptions can then be used to bind native
 functions and values.


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

Bug#742615: make runsystem.sysv honor init=something

[Justus Winter]

Package: sysvinit
Version: 2.88dsf-51
Severity: wishlist
Tags: patch
Usertags: hurd

Dear maintainer :)

attached is a patch that makes runsystem.sysv honor init=something in
the kernel command line. This makes it possible to spawn a shell early
in the Hurd bootstrap very much like it is possible on Debian/Linux.

Thanks,
Justus
From 9ecdb676b9b3ae316ab43303084f6bfe84b04027 Mon Sep 17 00:00:00 2001
From: Justus Winter <4win...@informatik.uni-hamburg.de>
Date: Tue, 25 Mar 2014 14:51:21 +0100
Subject: [PATCH] Make runsystem.sysv honor init=something in the kernel
 command line

This makes it possible to spawn a shell early in the Hurd bootstrap
very much like it is possible on Debian/Linux.
---
 debian/src/initscripts/etc/hurd/runsystem.sysv | 10 +-
 1 file changed, 9 insertions(+), 1 deletion(-)

diff --git a/debian/src/initscripts/etc/hurd/runsystem.sysv b/debian/src/initscripts/etc/hurd/runsystem.sysv
index 943d443..cb448d7 100755
--- a/debian/src/initscripts/etc/hurd/runsystem.sysv
+++ b/debian/src/initscripts/etc/hurd/runsystem.sysv
@@ -19,6 +19,11 @@ fallback_shells='/bin/sh /bin/dash /bin/bash /bin/csh /bin/ash /bin/shd'
 # Shell used for normal single-user startup.
 SHELL=/bin/sh
 
+# The init program to call.
+#
+# Can be overridden using init=something in the kernel command line.
+init=/sbin/init
+
 ###
 
 # If we get a SIGLOST, attempt to reopen the console in case
@@ -82,6 +87,9 @@ while [ $# -gt 0 ]; do
   shift
   case "$arg" in
   --*) ;;
+  init=*)
+eval "${arg}"
+;;
   *=*) ;;
   -*)
 flags="${flags}${arg#-}"
@@ -111,4 +119,4 @@ for i in `seq 1 10` ; do : ; done
 fsysopts / --update --readonly
 
 # Finally, start the actual SysV init.
-exec /sbin/init ${single} -a
+exec ${init} ${single} -a
-- 
1.9.0

Bug#742617: Please downgrade optimize for mips64/n32 to mips3/mips64(32)

[Yunqiang Su]

Package: gcc-4.9
Version: 4.9-20140322-1

Hi,
After talk with lots of mips folks, now I believe that compatible is
quilt import even more than some performance improve.

diff -ur gcc-4.9-4.9-20140322/debian/rules2
gcc-4.9-4.9-20140322-new/debian/rules2

--- gcc-4.9-4.9-20140322/debian/rules2  2014-03-25 12:55:13.0 +
+++ gcc-4.9-4.9-20140322-new/debian/rules2  2014-03-25
12:57:57.425930186 +
@@ -552,8 +552,8 @@
   ifeq ($(multilib),yes)
 ifeq ($(biarchn32)-$(biarch32),yes-yes)
   CONFARGS += --enable-targets=all
-  CONFARGS += --with-arch-64=mips64r2 --with-tune-64=loongson3a
-  CONFARGS += --with-arch-32=mips32 --with-tune-32=mips32r2
+  CONFARGS += --with-arch-64=mips3 --with-tune-64=mips64
+  CONFARGS += --with-arch-32=mips2 --with-tune-32=mips32
 endif
   endif
 endif
@@ -563,15 +563,15 @@
   ifeq ($(multilib),yes)
 ifeq ($(biarchn32)-$(biarch32),yes-yes)
   CONFARGS += --enable-targets=all
-  CONFARGS += --with-arch-64=mips64r2 --with-tune-64=octeon+
-  CONFARGS += --with-arch-32=mips32 --with-tune-32=mips32r2
+  CONFARGS += --with-arch-64=mips3 --with-tune-64=mips64
+  CONFARGS += --with-arch-32=mips2 --with-tune-32=mips32
 endif
   endif
 endif

 ifneq (,$(findstring mips64el-linux-gnuabi64,$(DEB_TARGET_GNU_TYPE)))
   CONFARGS += --with-mips-plt
-  CONFARGS += --with-arch-64=mips64r2 --with-tune-64=loongson3a
+  CONFARGS += --with-arch-64=mips3 --with-tune-64=mips64
   ifeq ($(multilib),yes)
 ifeq ($(biarchn32)-$(biarch32),yes-yes)
   CONFARGS += --enable-targets=all
@@ -582,7 +582,7 @@

 ifneq (,$(findstring mips64-linux-gnuabi64,$(DEB_TARGET_GNU_TYPE)))
   CONFARGS += --with-mips-plt
-  CONFARGS += --with-arch-64=mips64r2 --with-tune-64=octeon+
+  CONFARGS += --with-arch-64=mips3 --with-tune-64=mips64
   ifeq ($(multilib),yes)
 ifeq ($(biarchn32)-$(biarch32),yes-yes)
   CONFARGS += --enable-targets=all


-- 
Yunqiang Su
diff -ur gcc-4.9-4.9-20140322/debian/rules2 
gcc-4.9-4.9-20140322-new/debian/rules2
--- gcc-4.9-4.9-20140322/debian/rules2  2014-03-25 12:55:13.0 +
+++ gcc-4.9-4.9-20140322-new/debian/rules2  2014-03-25 12:57:57.425930186 
+
@@ -552,8 +552,8 @@
   ifeq ($(multilib),yes)
 ifeq ($(biarchn32)-$(biarch32),yes-yes)
   CONFARGS += --enable-targets=all
-  CONFARGS += --with-arch-64=mips64r2 --with-tune-64=loongson3a
-  CONFARGS += --with-arch-32=mips32 --with-tune-32=mips32r2
+  CONFARGS += --with-arch-64=mips3 --with-tune-64=mips64
+  CONFARGS += --with-arch-32=mips2 --with-tune-32=mips32
 endif
   endif
 endif
@@ -563,15 +563,15 @@
   ifeq ($(multilib),yes)
 ifeq ($(biarchn32)-$(biarch32),yes-yes)
   CONFARGS += --enable-targets=all
-  CONFARGS += --with-arch-64=mips64r2 --with-tune-64=octeon+
-  CONFARGS += --with-arch-32=mips32 --with-tune-32=mips32r2
+  CONFARGS += --with-arch-64=mips3 --with-tune-64=mips64
+  CONFARGS += --with-arch-32=mips2 --with-tune-32=mips32
 endif
   endif
 endif

 ifneq (,$(findstring mips64el-linux-gnuabi64,$(DEB_TARGET_GNU_TYPE)))
   CONFARGS += --with-mips-plt
-  CONFARGS += --with-arch-64=mips64r2 --with-tune-64=loongson3a
+  CONFARGS += --with-arch-64=mips3 --with-tune-64=mips64
   ifeq ($(multilib),yes)
 ifeq ($(biarchn32)-$(biarch32),yes-yes)
   CONFARGS += --enable-targets=all
@@ -582,7 +582,7 @@

 ifneq (,$(findstring mips64-linux-gnuabi64,$(DEB_TARGET_GNU_TYPE)))
   CONFARGS += --with-mips-plt
-  CONFARGS += --with-arch-64=mips64r2 --with-tune-64=octeon+
+  CONFARGS += --with-arch-64=mips3 --with-tune-64=mips64
   ifeq ($(multilib),yes)
 ifeq ($(biarchn32)-$(biarch32),yes-yes)
   CONFARGS += --enable-targets=all

Bug#735940:

[Olivier Schwander]

Le 25 Mar 2014 14:10, Zooko Wilcox-OHearn a écrit:
> I would like for Tahoe-LAFS v1.10 to be included in Debian, but I
> don't understand how to make it use the Debian packages of jquery and
> d3. That doesn't sound like something that could be done by changing
> the upstream source of Tahoe-LAFS. How can I help?

Hum, I just gave a quick look at the debian package and I do not
understand how these files are produced for the binary package.

Do you know where these 3 files come from ? Some magic inside setup.py
or something like that ?


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

Bug#741543: When build for mips64el, the default target is mipsn32el

[Yunqiang Su]

--- gcc-4.9-4.9-20140322-new.orig/src/gcc/config.gcc2014-03-25
13:03:45.948992657 +
+++ gcc-4.9-4.9-20140322-new/src/gcc/config.gcc 2014-03-25
13:06:12.314278663 +
@@ -1963,6 +1963,11 @@
tmake_file="${tmake_file} mips/t-linux64"
tm_defines="${tm_defines} MIPS_ABI_DEFAULT=ABI_N32"
case ${target} in
+   *gnuabi64*)
+   tm_defines=$(echo ${tm_defines}| sed
's/MIPS_ABI_DEFAULT=ABI_N32/MIPS_ABI_DEFAULT=ABI_64/g')
+   ;;
+   esac
+   case ${target} in
mips64el-st-linux-gnu)
tm_file="${tm_file} mips/st.h"
tmake_file="${tmake_file} mips/t-st"



On Tue, Mar 25, 2014 at 8:23 PM, Richard Sandiford
 wrote:
> Yunqiang Su  writes:
>> s/gnuabin64/gnuabi64/
>>
>> just a typo.
>>
>> --- gcc-4.9-4.9-20140322.orig/src/gcc/config.gcc2014-03-25
>> 11:06:44.935298703 +
>> +++ gcc-4.9-4.9-20140322/src/gcc/config.gcc 2014-03-25
>> 11:07:39.087774543 +
>> @@ -1963,6 +1963,9 @@
>> tmake_file="${tmake_file} mips/t-linux64"
>> tm_defines="${tm_defines} MIPS_ABI_DEFAULT=ABI_N32"
>> case ${target} in
>> +   *gnuabi64*)
>> +   tm_defines=$(echo ${tm_defines}| sed
>> 's/MIPS_ABI_DEFAULT=ABI_N32/MIPS_ABI_DEFAULT=ABI_64/g')
>> +   ;;
>> mips64el-st-linux-gnu)
>> tm_file="${tm_file} mips/st.h"
>> tmake_file="${tmake_file} mips/t-st"
>
> I think the new code should be in a separate case statement, since it's
> orthogonal to the mips64octeon/mipsisa64r2 choice.  With that change it
> looks good though.
>
> Thanks,
> Richard



-- 
Yunqiang Su


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

Bug#742618: missing cups enable in configure, so xfe dont have printing support if recompile

[PICCORO McKAY Lenz]

Package: fox1.6
Version: 1.6.45-1
Severity: important

The new version of xfe says that cups already hav been enabled in fox libs,
but cups flags are not parse in configure!

see that line in rules not have --enable-cups:

http://anonscm.debian.org/gitweb/?p=collab-maint/fox16.git;a=blob;f=debian/rules;hb=16563d9c31d8e34b481ca56b0f5bc7f1854423e4

and for wheeze either:

http://anonscm.debian.org/gitweb/?p=collab-maint/fox16.git;a=blob;f=debian/rules;h=f923a734bbf703c1b392d2df3319f0e2233ec3ce;hb=86d934e03b703b4de9464f843c1c051c452d2d7e

the --enalbe-cups are missing and in some archs dont build property

i have rebuild the fox package in my debian unstable system and the
results dependency dont have the libcups2 package listed

so in consecuence xfe builds dont have printing support

---

Lenz McKAY Gerardo (PICCORO)
http://qgqlochekone.blogspot.com


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

Bug#742616: Mark libraries packages as multi arch when with_multiarch_lib=yes

[Yunqiang Su]

Package: gcc-4.9

This the the same with the 4.8 one.
I refreshed it with gcc-4.9.

In this patch, I also enable gcc-4.9-base and mark it as Mulit-Arch: same.

If you do not like it, ignore it please.
I think that this may be very useful for people working on cross complier with
multiarch support, especially for unofficial architectures.

-- 
Yunqiang Su
--- gcc-4.9-4.9-20140322/debian/control.m4  2014-03-25 12:55:13.0 
+
+++ gcc-4.9-4.9-20140322-new/debian/control.m4  2014-03-25 13:50:54.769849629 
+
@@ -125,7 +125,6 @@
 define(`SOFTBASEDEP', `gnat`'PV-base (>= ${gnat:SoftVersion})')
 ')
 
-ifdef(`TARGET', `', `
 ifenabled(`gccbase',`
 
 Package: gcc`'PV-base
@@ -147,7 +146,6 @@
  Please use the compilers from the gcc-snapshot package for testing.
 ')`'dnl
 ')`'dnl
-')`'dnl native
 
 ifenabled(`gccxbase',`
 dnl override default base package dependencies to cross version
@@ -224,11 +222,10 @@
 Section: ifdef(`TARGET',`devel',`libs')
 Priority: ifdef(`TARGET',`extra',required)
 Depends: BASEDEP, ${shlibs:Depends}, ${misc:Depends}
-ifdef(`TARGET',`Provides: libgcc1-TARGET-dcv1',
 ifdef(`MULTIARCH', `Multi-Arch: same
 Pre-Depends: multiarch-support
 Breaks: ${multiarch:breaks}
-')`Provides: libgcc1-armel [armel], libgcc1-armhf [armhf]')
+')`Provides: libgcc1-armel [armel], libgcc1-armhf [armhf]' ifdef(`TARGET',`, 
libgcc1-TARGET-dcv1')
 BUILT_USING`'dnl
 Description: GCC support library`'ifdef(`TARGET)',` (TARGET)', `')
  Shared version of the support library, a library of internal subroutines
@@ -245,11 +242,9 @@
 Section: debug
 Priority: extra
 Depends: BASEDEP, libdep(gcc1,,=,${gcc:EpochVersion}), ${misc:Depends}
-ifdef(`TARGET',`',`dnl
 ifdef(`MULTIARCH',`Multi-Arch: same
 ')dnl
 Provides: libgcc1-dbg-armel [armel], libgcc1-dbg-armhf [armhf]
-')dnl
 BUILT_USING`'dnl
 Description: GCC support library (debug symbols)`'ifdef(`TARGET)',` (TARGET)', 
`')
  Debug symbols for the GCC support library.
@@ -264,11 +259,11 @@
 Section: ifdef(`TARGET',`devel',`libs')
 Priority: ifdef(`TARGET',`extra',required)
 Depends: BASEDEP, ${shlibs:Depends}, ${misc:Depends}
-ifdef(`TARGET',`Provides: libgcc2-TARGET-dcv1
-',ifdef(`MULTIARCH', `Multi-Arch: same
+ifdef(`TARGET',`Provides: libgcc2-TARGET-dcv1')
+ifdef(`MULTIARCH', `Multi-Arch: same
 Pre-Depends: multiarch-support
 Breaks: ${multiarch:breaks}
-'))`'dnl
+')`'dnl
 BUILT_USING`'dnl
 Description: GCC support library`'ifdef(`TARGET)',` (TARGET)', `')
  Shared version of the support library, a library of internal subroutines
@@ -285,8 +280,8 @@
 Section: debug
 Priority: extra
 Depends: BASEDEP, libdep(gcc2,,=,${gcc:Version}), ${misc:Depends}
-ifdef(`TARGET',`',ifdef(`MULTIARCH', `Multi-Arch: same
-'))`'dnl
+ifdef(`MULTIARCH', `Multi-Arch: same
+')`'dnl
 BUILT_USING`'dnl
 Description: GCC support library (debug symbols)`'ifdef(`TARGET)',` (TARGET)', 
`')
  Debug symbols for the GCC support library.
@@ -307,8 +302,8 @@
  ${dep:libatomic}, ${dep:libbtrace}, ${dep:libasan}, ${dep:liblsan},
  ${dep:libtsan}, ${dep:libubsan}, ${dep:libcilkrts}, ${dep:libvtv},
  ${dep:libqmath}, ${dep:libunwinddev}, ${shlibs:Depends}, ${misc:Depends}
-ifdef(`TARGET',`',ifdef(`MULTIARCH', `Multi-Arch: same
-'))`'dnl
+ifdef(`MULTIARCH', `Multi-Arch: same
+')`'dnl
 BUILT_USING`'dnl
 Description: GCC support library (development files)
  This package contains the headers and static library files necessary for
@@ -318,10 +313,10 @@
 ifenabled(`lib4gcc',`
 Package: libgcc4`'LS
 Architecture: ifdef(`TARGET',`CROSS_ARCH',`hppa')
-ifdef(`TARGET',`',ifdef(`MULTIARCH', `Multi-Arch: same
+ifdef(`MULTIARCH', `Multi-Arch: same
 Pre-Depends: multiarch-support
 Breaks: ${multiarch:breaks}
-'))`'dnl
+')`'dnl
 Section: ifdef(`TARGET',`devel',`libs')
 Priority: ifdef(`TARGET',`extra',required)
 Depends: ifdef(`STANDALONEJAVA',`gcj`'PV-base (>= ${gcj:Version})',`BASEDEP'), 
${shlibs:Depends}, ${misc:Depends}
@@ -338,8 +333,8 @@
 
 Package: libgcc4-dbg`'LS
 Architecture: ifdef(`TARGET',`CROSS_ARCH',`hppa')
-ifdef(`TARGET',`',ifdef(`MULTIARCH', `Multi-Arch: same
-'))`'dnl
+ifdef(`MULTIARCH', `Multi-Arch: same
+')`'dnl
 Section: debug
 Priority: extra
 Depends: BASEDEP, libdep(gcc4,,=,${gcc:Version}), ${misc:Depends}
@@ -694,7 +689,6 @@
 ')`'dnl x32dev
 ')`'dnl cdev
 
-ifdef(`TARGET', `', `
 ifenabled(`libgmath',`
 Package: libgccmath`'GCCMATH_SO`'LS
 Architecture: i386
@@ -726,7 +720,6 @@
 Description: GCC math support library (64bit)
  Support library for GCC.
 ')`'dnl
-')`'dnl native
 
 ifenabled(`cdev',`
 Package: gcc`'PV`'TS
@@ -883,7 +876,6 @@
 ')`'dnl c++dev
 ')`'dnl c++
 
-ifdef(`TARGET', `', `
 ifenabled(`ssp',`
 Package: libssp`'SSP_SO`'LS
 Architecture: any
@@ -970,16 +962,15 @@
  The protection is realized by buffer overflow detection and reordering of
  stack variables to avoid pointer corruption.
 ')`'dnl
-')`'dnl native
 
 ifenabled(`libgomp',`
 Package: libgomp`'GOMP_SO`'LS
 Section: ifdef(`TARGET',`devel',`libs')
 Architecture: ifdef(`TARGET',`CROSS_ARCH',`any')
-ifdef(`TARGET',`

Bug#742272: ITP: ocserv -- OpenConnect VPN Server

[Mike Miller]

On Mon, Mar 24, 2014 at 13:42:21 +0800, Liang Guo wrote:
> I'm glad that you have worked on it,  would you like upload your
> ocserv package and close this bug?
>
> I compiled it from source and it works in Debian, but have not
> packaging it yet.

I do have a start, but not fully suitable for uploading to the archive
yet (not lintian clean, copyright needs work, clean up default
configuration for a fresh install).

You can certainly grab what I have so far, I just updated to the 0.3.2 version:
  http://people.debian.org/~mtmiller/ocserv_0.3.2-1~local1.dsc

I just noticed a segfault while quickly testing this latest version,
I'll have to look into that.

It's up to you, since you have the ITP if you want feel free to take
my work and finish and upload it. But I'm certainly willing to finish
it as well if you'd rather I finish what I started :)

Cheers,

-- 
mike


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

Bug#735940:

[Zooko Wilcox-OHearn]

I would like for Tahoe-LAFS v1.10 to be included in Debian, but I
don't understand how to make it use the Debian packages of jquery and
d3. That doesn't sound like something that could be done by changing
the upstream source of Tahoe-LAFS. How can I help?

Regards,

Zooko


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

Bug#742620: wrong information in debian/copyright

[Thorsten Alteholz]

Package: testresources
Version: 0.2.4-1
Severity: serious
User: alteh...@debian.org
Usertags: ftp
X-Debbugs-CC: ftpmas...@ftp-master.debian.org
thanks

Dear Maintainer,

your information in debian/coypright seem to be wrong. Only
  lib/testresources/tests/TestUtil.py
is licensed under GPLv2. The rest is licensed under Apache 2.0
or BSD-3.
Unfortunately this also affects the versions in stable and
old-stable as well.

Thanks!
  Thorsten


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

Bug#735940:

[Olivier Schwander]

Le 25 Mar 2014 14:41, Zooko Wilcox-OHearn a écrit:
> Yes, all files in src/allmydata/web/static ¹ get included into the
> package built by "setup.py", because it is marked in setup.py as being
> "package_data" ².
>
> Does that answer your question?

Oh, ok, I made a mess with my find invocation and missed the js files
inside src/allmydata/web/static.

So, a first solution would be to remove the .min.js upstream, add
original .js and to do the minification at build time.

Since the two js libraries are shipped in Debian the best would be to
remove these js files completely (at least in the debian version of the
sources) and to use the files provided by the debian packages.

Creating a symlink between /usr/share/javascript/d3/d3.min.js (and
others) and the static directory of tahoe-lafs (which seems to be
/usr/lib/python2.7/dist-packages/allmydata/web/static/ right now) would
do the job. Another solution (as found in the libjs-rickshaw package)
would be to replace all the references to a local foobar.min.js file in
html files by the absolute path of the debian-provided js file with a
quick and dirty sed -i in the debian rules (I have no idea of why is
file is publicly accessible through a web server). I don't know how the
webserver part of tahoe works, but it may also be possible to the
directory /usr/share/javascript/ to the search path.

By the way, it's just some ideas, I do not have any experience with js
in debian packages and I do not have any time to work precisely on it
these days.

Best,

Olivier


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

Bug#742618: Acknowledgement (missing cups enable in configure, so xfe dont have printing support if recompile)

[PICCORO McKAY Lenz]

ah. please when tkae a package and put "in moda", please verify all
functionality are done! quality relies on it!

the current fox package in "stable" and "sid" lacks of printing support
Lenz McKAY Gerardo (PICCORO)
http://qgqlochekone.blogspot.com


On Tue, Mar 25, 2014 at 10:03 AM, Debian Bug Tracking System
 wrote:
> Thank you for filing a new Bug report with Debian.
>
> This is an automatically generated reply to let you know your message
> has been received.
>
> Your message is being forwarded to the package maintainers and other
> interested parties for their attention; they will reply in due course.
>
> Your message has been sent to the package maintainer(s):
>  Joachim Wiedorn 
>
> If you wish to submit further information on this problem, please
> send it to 742...@bugs.debian.org.
>
> Please do not send mail to ow...@bugs.debian.org unless you wish
> to report a problem with the Bug-tracking system.
>
> --
> 742618: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=742618
> Debian Bug Tracking System
> Contact ow...@bugs.debian.org with problems


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

Bug#742621: waagent: please add to backport

[Olivier Sallou]

Package: waagent
Severity: wishlist

Dear Maintainer,

I am trying to create image for windows azure for bootstrap-vz (ex 
build-debian-cloud). To do so, I need the waagent to be available.

Getting it in wheezy-backports would allow to create Debian stable images for 
Azure.

thanks

Olivier

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

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


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

Bug#742015: Possible workaround

[Jan-Benedict Glaw]

Hi!

On Tue, 2014-03-25 14:02:17 +0100, Jan-Benedict Glaw  wrote:
>   Out of curiosity, we added
> --ssh-options=-oIdentityFile=/.../.ssh/id_rsa, but it seems (using
> `duply') this strangely breaks GPG encryption when it's really used,
> though it works initially when it tests to sign and encrypt with that
> very key.

Actually, explicitely supplying the key file (instead of letting
Paramiko find it automatically) seems to be a proper workaround for
this issue. The GPG error seems to be unrelated and is also gone by
now.

  As a workaround, this does the job. However, I'm not sure how to
actually fix it, because there's so little debugging aid in Paramiko.
Would have been nice to have lots of logging all over the place... If
somebody who's deeper "into" the code wants to do in-depth debugging,
I'll help!

  As another note, it *seems* that with Debian's current "unstable"
version (1.10.1-1), I cannot trigger this bug on my desktop system,
while it does trigger in Ubuntu's lucid version, 1.7.7.1-2ubuntu1.
However, since this authentication error used to come and go for some
extended period of time, this may or may not be a red herring.

MfG, JBG

-- 
Getslash GmbH, Bahnhofstraße 16, 59302 Oelde
Tel: +49-2522-834349-5Fax:   +49-2522-834349-1
http://www.getslash.deMobil: +49-152-33822499
Sitz der Gesellschaft: Oelde
Handelsregister: Amtsgericht Münster, HRB 11911
Ust-Id-Nr.: DE 815060326
Geschäftsführung: Andre Peitz, Tobias Hanisch


signature.asc
Description: Digital signature

Bug#616290: isc-dhcp: Updated patches for GNU/Hurd

[Svante Signell]

notforwarded 616290
found 616290 4.3.0a1-2
tags 616290 + experimental
tags 616290 - upstream
thanks

Hi,

Attached are updated patches to enable a successful build of isc-dhcp
from experimental on GNU/Hurd. The first two, patch-bind and
patch-osdep, are upstream material, while the remaining four are
debian-specific.

Hoping for a final closing of this long-lasting bug report.

Thanks!

--- a/bind/bind-9.9.5b1/configure.in.orig	2013-12-12 06:59:59.0 +0100
+++ b/bind/bind-9.9.5b1/configure.in	2014-03-25 09:33:41.0 +0100
@@ -352,7 +352,7 @@ case "$host" in
 	# as it breaks how the two halves (Basic and Advanced) of the IPv6
 	# Socket API were designed to be used but we have to live with it.
 	# Define _GNU_SOURCE to pull in the IPv6 Advanced Socket API.
-	*-linux* | *-kfreebsd*-gnu)
+	*-linux* | *-kfreebsd*-gnu | *-gnu*)
 		STD_CDEFINES="$STD_CDEFINES -D_GNU_SOURCE"
 		CPPFLAGS="$CPPFLAGS -D_GNU_SOURCE"
 		;;
--- a/bind_bind-9.9.5b1/lib/isc/unix/net.c.orig	2013-12-12 06:59:59.0 +0100
+++ b/bind/bind-9.9.5b1/lib/isc/unix/net.c	2014-03-25 10:21:08.0 +0100
@@ -130,6 +130,9 @@ try_proto(int domain) {
 #ifdef EAFNOSUPPORT
 		case EAFNOSUPPORT:
 #endif
+#ifdef EPFNOSUPPORT
+		case EPFNOSUPPORT:
+#endif
 #ifdef EPROTONOSUPPORT
 		case EPROTONOSUPPORT:
 #endif
--- a/includes/osdep.h.orig	2013-12-11 01:01:03.0 +0100
+++ b/includes/osdep.h	2014-03-25 10:43:26.0 +0100
@@ -108,7 +108,7 @@
 #  define USE_SOCKET_RECEIVE
 #  if defined(HAVE_DLPI)
 #define USE_DLPI_HWADDR
-#  elif defined(HAVE_LPF)
+#  elif defined(HAVE_LPF) || defined(__GNU__)
 #define USE_LPF_HWADDR
 #  elif defined(HAVE_BPF)
 #define USE_BPF_HWADDR
--- a/debian/rules.orig	2013-12-22 04:36:57.0 +0100
+++ b/debian/rules	2014-03-25 10:26:24.0 +0100
@@ -19,8 +19,15 @@ CFLAGS+=-D_PATH_DHCPD_CONF='"/etc/dhcp/d
 CFLAGS+=-D_PATH_DHCLIENT_CONF='"/etc/dhcp/dhclient.conf"'
 CFLAGS+=-DNOMINUM
 
+ifeq ($(DEB_HOST_ARCH_OS), hurd)
+CONFIG=--enable-use-sockets
+else
+CONFIG=
+endif
+
 CONFFLAGS=--prefix=/usr \
   --sysconfdir=/etc/dhcp \
+  $(CONFIG) \
   --with-srv-lease-file=/var/lib/dhcp/dhcpd.leases \
 	  --with-srv6-lease-file=/var/lib/dhcp/dhcpd6.leases \
 	  --with-cli-lease-file=/var/lib/dhcp/dhclient.leases \
:


dhclient-script.hurd.udeb
Description: application/shellscript


dhclient-script.hurd
Description: application/shellscript

Bug#737982: oneko: please provide a desktop file and icons

[Markus Koschany]

Hi Ricardo,

On 25.03.2014 15:32, Ricardo Mones wrote:
[...]
>   It's simpler to add the png icons to packaging directory. They're not
> going to change anytime soon. Adding a dependency and converting on every
> build is an unnecesary waste of network and cpu time.

It depends on the maintainer. :) Other maintainers had requested the
exact opposite in the past and they prefer to build everything from
source. It's completely up to you if you want to add the icons to your
debian directory or if you want to build them from source. Since I can't
foresee what kind of solution the maintainer prefers, I provide a patch
for the "more complex" and time-consuming solution.

Many games are accompanied by a data package which is arch:all. I
usually use dh_auto_build-indep to build the icons and install them in
the arch-independent package. In case of oneko that was not possible.

Also please note that your package only ships xbm files which are not
supported by desktop files, so I had to convert your icons to the xpm
file format hence these icons can be used with Debian's menu files as
well as with desktop files.


[...]
>   And what does happen on non-GNOME3 desktops?
>   Also, are GNOME3 users supposed to already know that info?

My patch makes oneko visible on all desktops. So KDE, Xfce or LXDE users
will see exactly the same as GNOME3 users thanks to the new
oneko.desktop file. Users of Debian's menu will now see icons in
addition to their usual menu entries too.

The Action entries are just a "bonbon" for all those users who have the
corresponding extensions installed. Users of Gnome3 should be aware of

https://packages.debian.org/sid/gnome-shell-extensions

and

https://extensions.gnome.org/#

KDE supports this standard by default. You don't have to install further
extensions here.

Regards,

Markus




signature.asc
Description: OpenPGP digital signature

Bug#741543: When build for mips64el, the default target is mipsn32el

[Richard Sandiford]

Yunqiang Su  writes:
> --- gcc-4.9-4.9-20140322-new.orig/src/gcc/config.gcc2014-03-25
> 13:03:45.948992657 +
> +++ gcc-4.9-4.9-20140322-new/src/gcc/config.gcc 2014-03-25
> 13:06:12.314278663 +
> @@ -1963,6 +1963,11 @@
> tmake_file="${tmake_file} mips/t-linux64"
> tm_defines="${tm_defines} MIPS_ABI_DEFAULT=ABI_N32"
> case ${target} in
> +   *gnuabi64*)
> +   tm_defines=$(echo ${tm_defines}| sed
> 's/MIPS_ABI_DEFAULT=ABI_N32/MIPS_ABI_DEFAULT=ABI_64/g')
> +   ;;
> +   esac
> +   case ${target} in
> mips64el-st-linux-gnu)
> tm_file="${tm_file} mips/st.h"
> tmake_file="${tmake_file} mips/t-st"

Sorry, should have noticed this last time, but for compatibility reasons
we need to use `...` rather than $(...).  No need to repost the patch with
that change -- I'll just make it locally before committing -- but please
give an idea how it's been tested.

Thanks,
Richard


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

Bug#742595: Update valgrind supp file

[Alessandro Ghedini]

On mar, mar 25, 2014 at 11:08:05 +0100, Mathieu Malaterre wrote:
> Package: valgrind
> Version: 1:3.9.0-5
> Tags: patch
> 
> It would be nice if supp file was updated (see attached file).

Well, your suppression basically suppresses every "still reachable" leaks from
malloc(), and not just in ls, but in every program run through valgrind.

Also, I'm not sure if it's actually worth fixing, since ls seems to be the only
program showing this behaviour (that is, it may not be a false positive).

Cheers

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


signature.asc
Description: Digital signature

Bug#742603: exp-sgcheck: sg_main.c:560 (add_blocks_to_StackTree): Assertion '!already_present' failed.

[Alessandro Ghedini]

On Tue, Mar 25, 2014 at 12:28:51PM +0100, Mathieu Malaterre wrote:
> Package: valgrind
> Version: 1:3.9.0-5
> 
> I have extracted a section of code from openjpeg which seems to be
> driving valgrind/exp-sgcheck nuts. See attached demo.c file.
> 
> Steps (dwarf-4 and stack-protector are important):
> 
> $ gcc  -gdwarf-4  -fstack-protector   demo.c
> $ valgrind --tool=exp-sgcheck  ./a.out
> ==17451== exp-sgcheck, a stack and global array overrun detector
> ==17451== NOTE: This is an Experimental-Class Valgrind Tool
> ==17451== Copyright (C) 2003-2013, and GNU GPL'd, by OpenWorks Ltd et al.
> ==17451== Using Valgrind-3.9.0 and LibVEX; rerun with -h for copyright info
> ==17451== Command: ./a.out
> ==17451==
> 
> exp-sgcheck: sg_main.c:560 (add_blocks_to_StackTree): Assertion
> '!already_present' failed.
> ==17451==at 0x380278CC: report_and_quit (m_libcassert.c:260)
> ==17451==by 0x38027A26: vgPlain_assert_fail (m_libcassert.c:340)
> ==17451==by 0x3801EE00: add_blocks_to_StackTree (sg_main.c:560)
> ==17451==by 0x38020321: shadowStack_new_frame.isra.12 (sg_main.c:1875)
> ==17451==by 0x806427FDC: ???
> ==17451==by 0x8034DBECF: ???
> 
> sched status:
>   running_tid=1
> 
> Thread 1: status = VgTs_Runnable
> ==17451==at 0x4005B7: main (demo.c:39)

The gcc version seems to be relevant as well (i.e. I can't reproduce with
gcc-4.8). Maybe a bug in gcc? There seems to be a whole bunch of (apparently)
dwarf-related bugs fixed in gcc-4.8 [0] (also, DWARF4 is the default since
gcc-4.8).

Cheers

[0] 
http://gcc.gnu.org/bugzilla/buglist.cgi?bug_status=RESOLVED&limit=0&order=bug_status%2Cpriority%2Cassigned_to%2Cbug_id&query_format=advanced&resolution=FIXED&target_milestone=4.8.0

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


signature.asc
Description: Digital signature

Bug#742498: RM: davical -- RoQA; RC-buggy, no maintainer activity, not in testing

[Florian Schlichting]

> Please remove davical from sid.

While I agree that Davical in Debian is not in a good state at all, I
notice that the upstream project is in the process of converting itself
from a one man (same as Debian maintainer) show to a more
community-based project, and updating the Debian packages is one of
their priorities, as can be seen from the minutes of their second IRC
meeting at
http://davical.dhits.nl/index.php?title=Community_Support/Minutes_11Mar2014

>From browsing Davical's RC bugs, my impression is that most if not all
may be solved by simply packaging a new upstream version, so I'd say why
not give them a chance to get organized and provide an update to the
existing package over the next month or two?

Florian


Davical community: I may have time to review and sponsor the upload of
an updated Debian package, please get in touch if interested!


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

Bug#486211: Squid3 crashed with Segfault

[Marco Gaiarin]

Package: squid3
Version: 3.1.20-2.2
Followup-For: Bug #486211


I've just upgraded two servers from squeeze to wheezy, and i've hit this
bug in one of that. I repeatedlt receive:

 Mar 25 12:33:02 kaa kernel: [943353.343797] squid3[16919]: segfault at 58 ip 
7fd34cea2396 sp 7fff192e1b60 error 4 in squid3[7fd34ccaf000+301000]
 Mar 25 12:33:02 kaa squid[40048]: Squid Parent: child process 16919 exited due 
to signal 11 with status 0

roughly 5-10 time at distance of some minutes, then nothing for hour... and
happens roughly 10-50 times at day.

Both server (kaa and lupus) are 64bit debian wheezy. lupus seems does not
have that trouble; configuration are roughly the same.

The only difference between kaa and lupus, is that kaa is a
medium-heavy-loaded server, while lupus does little job, so seems
''load-related''.


Say me if more info are needed... thanks.

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

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

Versions of packages squid3 depends on:
ii  adduser   3.113+nmu3
ii  libc6 2.13-38+deb7u1
ii  libcap2   1:2.22-1.2
ii  libcomerr21.42.5-1.1
ii  libdb5.1  5.1.29-5
ii  libexpat1 2.1.0-1+deb7u1
ii  libgcc1   1:4.7.2-5
ii  libgssapi-krb5-2  1.10.1+dfsg-5+deb7u1
ii  libk5crypto3  1.10.1+dfsg-5+deb7u1
ii  libkrb5-3 1.10.1+dfsg-5+deb7u1
ii  libldap-2.4-2 2.4.31-1+nmu2
ii  libltdl7  2.4.2-1.1
ii  libpam0g  1.1.3-7.1
ii  libsasl2-22.1.25.dfsg1-6+deb7u1
ii  libstdc++64.7.2-5
ii  libxml2   2.8.0+dfsg1-7+nmu2
ii  logrotate 3.8.1-4
ii  lsb-base  4.1+Debian8+deb7u1
ii  netbase   5.0
ii  squid3-common 3.1.20-2.2

squid3 recommends no packages.

Versions of packages squid3 suggests:
pn  resolvconf   
ii  smbclient2:3.6.6-6+deb7u2
pn  squid-cgi
ii  squidclient  3.1.20-2.2
pn  ufw  

-- Configuration Files:
/etc/squid3/squid.conf changed [not included]

-- 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#737982: oneko: please provide a desktop file and icons

[Ricardo Mones]

  Hi Markus,

On Tue, Mar 25, 2014 at 04:04:15PM +0100, Markus Koschany wrote:
> Hi Ricardo,
> 
> On 25.03.2014 15:32, Ricardo Mones wrote:
> [...]
> >   It's simpler to add the png icons to packaging directory. They're not
> > going to change anytime soon. Adding a dependency and converting on every
> > build is an unnecesary waste of network and cpu time.
> 
> It depends on the maintainer. :) Other maintainers had requested the
> exact opposite in the past and they prefer to build everything from
> source. It's completely up to you if you want to add the icons to your
> debian directory or if you want to build them from source. Since I can't
> foresee what kind of solution the maintainer prefers, I provide a patch
> for the "more complex" and time-consuming solution.

  Indeed, but you can also ask before consuming time :-) I wasn't even
aware you had intentions to submit a patch (which is very appreciated).

> Many games are accompanied by a data package which is arch:all. I
> usually use dh_auto_build-indep to build the icons and install them in
> the arch-independent package. In case of oneko that was not possible.
> 
> Also please note that your package only ships xbm files which are not
> supported by desktop files, so I had to convert your icons to the xpm
> file format hence these icons can be used with Debian's menu files as
> well as with desktop files.

  Yes, I'm aware of that, the plan is to convert them to PNG, which I
think has better transparency support than XPM (and is more compact).

> [...]
> >   And what does happen on non-GNOME3 desktops?
> >   Also, are GNOME3 users supposed to already know that info?
> 
> My patch makes oneko visible on all desktops. So KDE, Xfce or LXDE users
> will see exactly the same as GNOME3 users thanks to the new
> oneko.desktop file. Users of Debian's menu will now see icons in
> addition to their usual menu entries too.
> 
> The Action entries are just a "bonbon" for all those users who have the
> corresponding extensions installed. Users of Gnome3 should be aware of
> 
> https://packages.debian.org/sid/gnome-shell-extensions
> 
> and
> 
> https://extensions.gnome.org/#
> 
> KDE supports this standard by default. You don't have to install further
> extensions here.

  Allright, questions were just to be sure nothing needs to be added to
oneko README.Debian file :)

  Thanks for the detailed explanations,
-- 
  Ricardo Mones 
  ~
  Absence of evidence is not evidence of absence.  Carl Sagan



signature.asc
Description: Digital signature

Bug#742622: ITP: maxflow - a library implementing a minimum cut/maximum flow algorithm

[Gert Wollny]

Package: wnpp
Severity: wishlist

* Package name: maxflow
   Version : 3.03
   Upstream Author : Vladimir Kolmogorov and Yuri Boykov

* URL  : http://pub.ist.ac.at/~vnk/software.html

* License : GPL3+
   Programming Lang: C++
   Description : This library implements the maxflow algorithm.

This library implements an efficient minimum cut/maximum flow
algorithms on graphs that can be used for exact or approximate
energy minimization in low-level vision. The algorithm provides a high 
performance that makes near real-time performance possible.



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

Bug#742623: Please show the whole git repository directory of a project instead of just one repository

[Bernhard R. Link]

Package: gforge-plugin-scmgit
Version: 5.2.3-1

Currently https://alioth.debian.org/scm/browser.php?group_id=
shows an iframe with the git repository named like the project in the
project's directory for git repositories.

It would be nicer if it could instead show the list of all git
repositories in that directory. That's one more click if there is
only one but much better visibility of other repositories
(and even allows to have no repository there named like the project
itself).

Needs at least gitweb 1.7.10-rc0. (wheezy has already 1.7.10.4)

Index: fusionforge-5.2.3/plugins/scmgit/common/GitPlugin.class.php
===
--- fusionforge-5.2.3.orig/plugins/scmgit/common/GitPlugin.class.php
2014-03-25 16:14:29.341835604 +0100
+++ fusionforge-5.2.3/plugins/scmgit/common/GitPlugin.class.php 2014-03-25 
16:15:28.949835377 +0100
@@ -212,7 +212,7 @@
 
if ($project->usesPlugin($this->name)) {
if ($this->browserDisplayable($project)) {
-   print '' ;
+   print '' ;
}
}
}


Bernhard R. Link
-- 
F8AC 04D5 0B9B 064B 3383  C3DA AFFC 96D1 151D FFDC


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

Bug#721421: Additional build failure

[Daniel Lintott]

With the help of a hurd porterbox I have fixed bug #721420 enabling
libdevel-bt-perl to build on hurd.

Unfortunately the build still fails on hurd, due the the output from the
backtrace not matching what is expected by the test, this due to it
receiving the stack trace for the signal-handling thread [0].

I have included a copy of my build log from the porterbox.

[0] https://lists.debian.org/debian-hurd/2014/03/msg00061.html
-- 
Daniel Lintott
GPG Key: 4096R/5D73EC6E
 dpkg-buildpackage -rfakeroot -D -us -uc
dpkg-buildpackage: source package libdevel-bt-perl
dpkg-buildpackage: source version 0.06-1
dpkg-buildpackage: source distribution unstable
dpkg-buildpackage: source changed by gregor herrmann 
 dpkg-source --before-build libdevel-bt-perl-0.06
dpkg-buildpackage: host architecture hurd-i386
 fakeroot debian/rules clean
dh clean
   dh_testdir
   dh_auto_clean
   dh_clean
 dpkg-source -b libdevel-bt-perl-0.06
dpkg-source: info: using source format `3.0 (quilt)'
dpkg-source: info: building libdevel-bt-perl using existing ./libdevel-bt-perl_0.06.orig.tar.gz
dpkg-source: info: building libdevel-bt-perl in libdevel-bt-perl_0.06-1.debian.tar.xz
dpkg-source: info: building libdevel-bt-perl in libdevel-bt-perl_0.06-1.dsc
 debian/rules build
dh build
   dh_testdir
   dh_auto_configure
Checking if your kit is complete...
Looks good
Writing Makefile for Devel::bt
Writing MYMETA.yml and MYMETA.json
   dh_auto_build
make[1]: Entering directory `/home/dlintott-guest/libdevel-bt-perl-0.06'
cp lib/Devel/bt.pm blib/lib/Devel/bt.pm
/usr/bin/perl /usr/share/perl/5.18/ExtUtils/xsubpp  -typemap /usr/share/perl/5.18/ExtUtils/typemap  bt.xs > bt.xsc && mv bt.xsc bt.c
cc -c   -D_GNU_SOURCE -DDEBIAN -fstack-protector -fno-strict-aliasing -pipe -I/usr/local/include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -g -O2 -fstack-protector --param=ssp-buffer-size=4 -Wformat -Werror=format-security -D_FORTIFY_SOURCE=2   -DVERSION=\"0.06\" -DXS_VERSION=\"0.06\" -fPIC "-I/usr/lib/perl/5.18/CORE"   bt.c
bt.xs: In function 'stack_trace':
bt.xs:67:26: warning: ignoring return value of 'dup', declared with attribute warn_unused_result [-Wunused-result]
 close(0); dup(in_fd[0]);
  ^
bt.xs:68:26: warning: ignoring return value of 'dup', declared with attribute warn_unused_result [-Wunused-result]
 close(1); dup(out_fd[1]);
  ^
bt.xs:69:26: warning: ignoring return value of 'dup', declared with attribute warn_unused_result [-Wunused-result]
 close(2); dup(out_fd[1]);
  ^
bt.xs:72:18: warning: ignoring return value of 'write', declared with attribute warn_unused_result [-Wunused-result]
 write(1, buf, strlen(buf));
  ^
bt.xs:94:10: warning: ignoring return value of 'write', declared with attribute warn_unused_result [-Wunused-result]
 write(in_fd[1], "thread apply all backtrace\n", 27);
  ^
bt.xs:95:10: warning: ignoring return value of 'write', declared with attribute warn_unused_result [-Wunused-result]
 write(in_fd[1], "quit\n", 5);
  ^
bt.xs:141:30: warning: ignoring return value of 'write', declared with attribute warn_unused_result [-Wunused-result]
 write(1, buffer, strlen(buffer));
  ^
Running Mkbootstrap for Devel::bt ()
chmod 644 bt.bs
rm -f blib/arch/auto/Devel/bt/bt.so
cc -g -O2 -fstack-protector --param=ssp-buffer-size=4 -Wformat -Werror=format-security -Wl,-z,relro  -shared -L/usr/local/lib -fstack-protector bt.o  -o blib/arch/auto/Devel/bt/bt.so 	\
	 	\
	  
chmod 755 blib/arch/auto/Devel/bt/bt.so
cp bt.bs blib/arch/auto/Devel/bt/bt.bs
chmod 644 blib/arch/auto/Devel/bt/bt.bs
Manifying blib/man3/Devel::bt.3pm
make[1]: Leaving directory `/home/dlintott-guest/libdevel-bt-perl-0.06'
   dh_auto_test
make[1]: Entering directory `/home/dlintott-guest/libdevel-bt-perl-0.06'
PERL_DL_NONLAZY=1 /usr/bin/perl "-MExtUtils::Command::MM" "-e" "test_harness(0, 'blib/lib', 'blib/arch')" t/*.t

#   Failed test 'perl backtrace for SIGABRT'
#   at t/basic.t line 26.
#   '#0  0x01108a4c in mach_msg_trap () at /build/eglibc-LR0xsz/eglibc-2.18/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2
# #1  0x0110922e in __mach_msg (msg=msg@entry=0x17fdf20, option=option@entry=3, send_size=32, rcv_size=rcv_size@entry=4096, rcv_name=rcv_name@entry=115, timeout=timeout@entry=0, notify=notify@entry=0) at msg.c:110
# #2  0x011098ef in __mach_msg_server_timeout (demux=demux@entry=0x1119ce0 , max_size=max_size@entry=4096, rcv_name=rcv_name@entry=115, option=option@entry=0, timeout=timeout@entry=0) at msgserver.c:150
# #3  0x011099db in __mach_msg_server (demux=demux@entry=0x1119ce0 , max_size=4096, rcv_name=115) at msgserver.c:195
# #4  0x01119dcd in _hurd_msgport_receive () at msgportdemux.c:67
# #5  0x010aba86 in entry_point (self=0x81c28f8, start_routine=0x1119d70 <_hurd_msgport_receive>, arg=0x0) at ./pthread/pt-create.c:63
# #6  0x

Bug#554167: Upgrading mawk to 1.3.4

[Riku Voipio]

Hi,

Some xen people just bumped into this bug:

xxx: I dug into the issue yesterday night, the issue come from mawk which is a 
silly version on Debian Jessie and Ubuntu

All the other major distributions (fedora, suse, ...) have switched to mawk
1.3.4. Five years since opening the bug, Debian/Ubuntu sticking to 1.3.3 is now 
causing
headeach to people rather than saving from regressions, it seems...

Riku


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

Bug#737982: oneko: please provide a desktop file and icons

[Ricardo Mones]

Control: tags -1 moreinfo

  Hi Markus,

On Tue, Mar 25, 2014 at 02:13:25PM +0100, Markus Koschany wrote:
> Dear maintainer,
> 
> please find attached a patch that achieves the following:

  First, thanks for the patch!

> * Add oneko.desktop file.
> * Update menu file and add icon entries.
> * Add imagemagick to Build-Depends and create new icons for the desktop
>   and menu file. Add the newly created images to the clean file.
>   (Closes: #737982)

  It's simpler to add the png icons to packaging directory. They're not
going to change anytime soon. Adding a dependency and converting on every
build is an unnecesary waste of network and cpu time.

> The new desktop file also provides Action entries with whom you can
> quickly execute the same commands that are already provided in the menu
> file. Users of Gnome3 just need to install
> 
> https://extensions.gnome.org/extension/322/quicklists/
> 
> for example so that those actions can be accessed from Gnome Shell with
> a right-click on the desktop icon.

  And what does happen on non-GNOME3 desktops?
  Also, are GNOME3 users supposed to already know that info?

  best regards,
-- 
  Ricardo Mones 
  ~
  You have the capacity to learn from mistakes. You'll learn a lot 
  today.   /usr/games/fortune



signature.asc
Description: Digital signature

Bug#742624: vym: The installation of VYM does not create a matching file extension

[Gerrit Kruse]

Package: vym
Version: 2.3.20-1
Severity: normal

Dear Maintainer,

   * What led up to the situation?
I installed vym and tried do open a matching file direct from the file manager
   * What exactly did you do (or not do) that was effective (or
 ineffective)?
   * What was the outcome of this action?
vym Files are identified as normal zip files
   * What outcome did you expect instead?


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

Kernel: Linux 3.13-1-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 vym depends on:
ii  libc6   2.18-4
ii  libgcc1 1:4.8.2-16
ii  libqt4-dbus 4:4.8.5+git242-g0315971+dfsg-2
ii  libqt4-network  4:4.8.5+git242-g0315971+dfsg-2
ii  libqt4-svg  4:4.8.5+git242-g0315971+dfsg-2
ii  libqt4-xml  4:4.8.5+git242-g0315971+dfsg-2
ii  libqtcore4  4:4.8.5+git242-g0315971+dfsg-2
ii  libqtgui4   4:4.8.5+git242-g0315971+dfsg-2
ii  libstdc++6  4.8.2-16
ii  unzip   6.0-11
ii  xsltproc1.1.28-2
ii  zip 3.0-8

vym recommends no packages.

Versions of packages vym suggests:
ii  ruby  1:1.9.3.4
ii  ruby1.9.1 [ruby-interpreter]  1.9.3.484-2

-- 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#742269: [feed2omb] reconnect after any message fix

[Slavko]

Hi,

Dňa Tue, 25 Mar 2014 11:56:07 +0100 Raphael Hertzog
 napísal:

> Can you submit those on the upstream tracker
> http://projects.ciarang.com/p/feed2omb/ ?

Yes, i can, but i don't want to create account there (i prefer don't
have accounts everywhere) and they have not allowed anonymous posting.
I will appreciate, if someone who has an account in their issue tracker
can post it.

> Would you like to take over this package ? I maintained it because
> I wanted it to post to identi.ca, now that identi.ca is no longer
> status.net based, I have no interest in this package any more.

Thanks, i have no interest in this now.

regards

-- 
Slavko
http://slavino.sk


signature.asc
Description: PGP signature

Bug#733735: (no subject)

[Barry Warsaw]

This is becoming more important now since a pip upgrade will require distlib.


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

Bug#738093: stunnel4 maintenance

[Peter Pentchev]

On Sun, Mar 23, 2014 at 02:56:40PM +0100, László Böszörményi (GCS) wrote:
> Hi Peter,
> 
> How does the adoption of stunnel4 goes? More than one and half months
> passed. Upstream released version 5.00 since then and 5.01 is on its
> way. I've a package ready, but can hold off if you need time.

Hi,

I'm actually almost ready with a 5.00 package myself, with a lot of
packaging updates.  It should be done and up for sponsorship in
two or three days at most.

G'luck,
Peter

-- 
Peter Pentchev  r...@ringlet.net r...@freebsd.org p.penc...@storpool.com
PGP key:http://people.FreeBSD.org/~roam/roam.key.asc
Key fingerprint 2EE7 A7A5 17FC 124C F115  C354 651E EFB0 2527 DF13
What would this sentence be like if it weren't self-referential?


signature.asc
Description: Digital signature

Bug#554167: Upgrading mawk to 1.3.4

[Steve Langasek]

On Tue, Mar 25, 2014 at 05:30:50PM +0200, Riku Voipio wrote:

> Some xen people just bumped into this bug:

> xxx: I dug into the issue yesterday night, the issue come from mawk which
> is a silly version on Debian Jessie and Ubuntu

> All the other major distributions (fedora, suse, ...) have switched to mawk
> 1.3.4. Five years since opening the bug, Debian/Ubuntu sticking to 1.3.3 is 
> now causing
> headeach to people rather than saving from regressions, it seems...

This is the bug about requesting a new upstream version.  I'm pretty sure
that's not the bug your users were running into.

-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developerhttp://www.debian.org/
slanga...@ubuntu.com vor...@debian.org


signature.asc
Description: Digital signature

Bug#742589: edk2: copyright file does not include reasons for being in non-free (Policy 2.5)

[Steve Langasek]

On Tue, Mar 25, 2014 at 05:12:08PM +0800, Paul Wise wrote:
> Source: edk2
> Version: 0~20131112.2590861a-2
> Severity: normal

> According to Debian Policy section 2.5:

> Packages in the contrib or non-free archive areas should state in the
> copyright file that the package is not part of the Debian distribution
> and briefly explain why.

I don't think I knew about this policy "should" (probably because I've
managed to avoid maintaining contrib/non-free packages).  Is there a
recommended way to encode this in copyright-format-1.0?  Should we clone
this bug against policy, to codify this as part of the format?

> As far as I can tell the edk2 copyright file doesn't state that parts of
> it are non-free, which parts are non-free and why they are non-free. I
> am guessing that it is due to the Intel-Fat-Driver license though.

Correct.

-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developerhttp://www.debian.org/
slanga...@ubuntu.com vor...@debian.org


signature.asc
Description: Digital signature

Bug#623634: libnet-rawip-perl: miscalculates header checksums

[gregor herrmann]

On Mon, 24 Mar 2014 17:33:15 +0100, Christoph Pleger wrote:

> I am not sure if that problem is really caused by libnet-rawip-perl - the
> package source is almost the same as in wheezy, only debian/changelog and
> debian/control are different. 

I just had a look, and there are more changes. Most of them
irrelevant, but one is interesting:
0.25-2 uses debhelper compatibility level 9 in order to enable all
hardening flags.

Besides that I see the following warning in the build log for -2:

RawIP.xs: In function 'XS_Net__RawIP_timem':
RawIP.xs:614:9: warning: format '%u' expects argument of type 'unsigned int', 
but argument 2 has type '__time_t' [-Wformat=]
 RETVAL = newSVpvf("%u.%06u",tv.tv_sec,tv.tv_usec);
 ^
RawIP.xs:614:9: warning: format '%u' expects argument of type 'unsigned int', 
but argument 3 has type '__suseconds_t' [-Wformat=]


BTW: I'm confused which package version built under which environment
works or fails under which environment :)


Cheers,
gregor

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


signature.asc
Description: Digital Signature

Bug#719329: vlc: Crackling sound at the begining of anything that VLC plays.

[Rémi Denis-Courmont]

tags 719329 + moreinfo unreproducible
severity 719329 normal
thanks

Hello,

It would be more helpful to post verbose VLC logs of the playback problem than 
to troll the developers. In the mean time, I could be as (in)constructive as 
you and simply blame PulseAudio or your ALSA driver.

Regards,

-- 
Rémi Denis-Courmont
http://www.remlab.net/


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

Bug#734100: vlc: Video stuttering with ALSA output

[Rémi Denis-Courmont]

tags 734100 + moreinfo
thanks

Hello,

Le vendredi 3 janvier 2014, 23:52:48 Vitaliy Filippov a écrit :
> [0x87a0a30] main audio output warning: playback way too early (-563272):
> playing silence [0x87a0a30] main audio output debug: inserting 27037 zeroes
> [0xf4c11150] main input error: ES_OUT_SET_(GROUP_)PCR  is called too late
> (pts_delay increased to 300 ms) [0xf4c11150] main input error:
> ES_OUT_RESET_PCR called
> [0xf4c11150] main input debug: Buffering 0%
> ...
> [0xf0c45bc0] main decoder debug: End of audio preroll
> ...
> [0xf4c11150] main input debug: Stream buffering done (334 ms in 3 ms)
> [0xf4c11150] main input debug: Decoder buffering done in 0 ms
> [0x87a0a30] main audio output debug: inserting 9553 zeroes
> [0xebc00c58] main vout display debug: auto hiding mouse cursor
> [0xf0c36aa8] main decoder debug: End of video preroll
> [0xf4c11150] main input error: ES_OUT_SET_(GROUP_)PCR  is called too late
> (pts_delay increased to 320 ms) [0xf4c11150] main input error:
> ES_OUT_RESET_PCR called
> ...

Please provide the complete logs, especially the audio output part. I'm afraid 
this small excerpt is not particularly helpful; it just shows your system is 
somehow too slow.

-- 
Rémi Denis-Courmont
http://www.remlab.net/


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

Bug#742625: vlc: please package new upstream release of vlc 2.1.4

[shirish शिरीष]

Package: vlc
Version: 2.1.2-2+b2
Severity: wishlist

Dear Maintainer,
Please package new upstream release of vlc either 2.1.3 or
2.1.4 . The changes are as under :-

Changes between 2.1.3 and 2.1.4:


Demuxers:
 * Fix issue in WMV with multiple compressed payload and empty payloads

Video Output:
 * Fix subtitles size rendering on Windows

Mac OS X:
 * Fix DVD playback regression
 * Fix misleading error message during video playback on OS X 10.9
 * Fix hardware acceleration memleaks


Changes between 2.1.2 and 2.1.3:


Core:
 * Fix broken behaviour with SOCKSv5 proxies
 * Fix integer overflow on error when using vlc_readdir

Access:
 * Fix DVB-T2 tuning on Linux
 * Fix encrypted DVD playback
 * Fix v4l2 frequency conversion

Decoders:
 * Fix numerous issues (M2TS, VC1 interlaced, Lagarith, FFv1.3, Xvid)
   by updating codec libraries
 * Bring fluidsynth back on Mac OS X
 * Fix some Opus crashes with some filters
 * Fix teletext crash on Windows

Demuxers:
 * Avoid an infinite recursion in MKV tags parsing
 * Fix an issue with some Vobsub tracks
 * Fix missing samples at the end of some wav files
 * Fix divide by 0 on ASF/WMV parsing

Audio output:
 * Fix audio device selection via command line on Mac OS X
 * Fix audio crashes on Mac OS X

Video Output:
 * Fix selection of DirectDraw as the default output for XP
 * Fix transform off-by-one issue
 * Fix screensaver disabling on Windows outputs
 * Fix DirectDraw device enumeration and multi-display output
 * Fix a potential crash when playing a fullscreen game at the same time as VLC

Stream output:
 * Fix 24bits audio MTU alignment in RTP
 * Fix record file names

Qt interface:
 * Fix minimal size possible on start
 * Fix a crash with the simple volume widget
 * Fix a crash in the audio menu building
 * Fix multimedia keys issues on Windows
 * Fix opening of DVD and BD folders on Windows

HTTP interface:
 * Fix album art display on Windows

Translations:
 * Update of Bulgarian, Catalan, Czech, Danish, German, Modern Greek,
   Spanish, Basque, Finnish, French, Scottish Gaelic, Galician, Hebrew,
   Hungarian, Italian, Japanese, Korean, Malay, Norwegian Bokmål, Nepali,
   Dutch, Polish, Brazilian Portuguese, Portuguese, Romanian, Russian,
   Sinhala, Slovak, Slovenian, Swedish, Telugu, Thai, Turkish, Ukrainian
   and Simplified Chinese translations
 * Fix encoding for Windows installer translations

As can be seen 2.1.3 is particularly interesting, especially the :-

Decoders:
 * Fix numerous issues (M2TS, VC1 interlaced, Lagarith, FFv1.3, Xvid)
   by updating codec libraries

Looking forward to an updated binary in the archive.

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

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

Versions of packages vlc depends on:
ii  dpkg  1.17.6
ii  fonts-freefont-ttf20120503-4
ii  libaa11.4p5-42
ii  libavcodec-extra-54   6:9.11-3
ii  libavutil52   6:9.11-3
ii  libc6 2.18-4
ii  libcaca0  0.99.beta18-1.1
ii  libfreetype6  2.5.2-1
ii  libfribidi0   0.19.6-1
ii  libgcc1   1:4.8.2-16
ii  libgl1-mesa-glx [libgl1]  9.2.2-1
ii  libice6   2:1.0.8-2
ii  libqtcore44:4.8.5+git242-g0315971+dfsg-2
ii  libqtgui4 4:4.8.5+git242-g0315971+dfsg-2
ii  libsdl-image1.2   1.2.12-5+b2
ii  libsdl1.2debian   1.2.15-9
ii  libsm62:1.2.1-2
ii  libstdc++64.8.2-16
ii  libtar0   1.2.20-3
ii  libva-x11-1   1.2.1-2
ii  libva11.2.1-2
ii  libvlccore7   2.1.2-2+b2
ii  libx11-6  2:1.6.2-1
ii  libxcb-composite0 1.10-2
ii  libxcb-keysyms1   0.3.9-1
ii  libxcb-randr0 1.10-2
ii  libxcb-render01.10-2
ii  libxcb-shape0 1.10-2
ii  libxcb-shm0   1.10-2
ii  libxcb-xfixes01.10-2
ii  libxcb-xv01.10-2
ii  libxcb1   1.10-2
ii  libxext6  2:1.3.2-1
ii  libxinerama1  2:1.1.3-1
ii  libxpm4   1:3.5.10-1
ii  vlc-nox   2.1.2-2+b2
ii  zlib1g1:1.2.8.dfsg-1

Versions of packages vlc recommends:
ii  vlc-plugin-notify  2.1.2-2+b2
ii  vlc-plugin-pulse   2.1.2-2+b2
ii  xdg-utils  1.1.0~rc1+git20111210-7

Versions of packages vlc suggests:
pn  videolan-doc  

Versions of packages vlc-nox depends on:
ii  dpkg   1.17.6
ii  liba52-0.7.4   0.7.4-17
ii  libasound2 1.0.27.2-3
ii  libass40.10.1-3
ii  libavahi-client3   0.

Bug#719496: freeorion: input textfields doesn't work after a while.

[Markus Koschany]

Control: retitle -1 Install OISInput.cfg to ~./freeorion
Control: tags -1 pending

I'm going to fix this issue soon.

Markus



signature.asc
Description: OpenPGP digital signature

Bug#738093: stunnel4 maintenance

[GCS]

On Tue, Mar 25, 2014 at 5:19 PM, Peter Pentchev  wrote:
> On Sun, Mar 23, 2014 at 02:56:40PM +0100, László Böszörményi (GCS) wrote:
>> How does the adoption of stunnel4 goes? More than one and half months
>> passed. Upstream released version 5.00 since then and 5.01 is on its
>> way. I've a package ready, but can hold off if you need time.
> I'm actually almost ready with a 5.00 package myself, with a lot of
> packaging updates.  It should be done and up for sponsorship in
> two or three days at most.
 Cool! May we do it together? Anyway, will sponsor your upload.

Laszlo/GCS


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

Bug#741240: vlc segfaults while playing MKV files

[Rémi Denis-Courmont]

tags 741240 + unreproducible moreinfo
thanks

Hello,

Le lundi 10 mars 2014, 11:11:56 Evgeni Golov a écrit :
> vlc currently segfaults on me, when I try to play some MKV file with
> 720p h264 (High) in it.

It seems to work fine here. We will need a sample file.

-- 
Rémi Denis-Courmont
http://www.remlab.net/


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

Bug#735447: vlc: in vlc audio is sometimes there, sometimes not there.

[Rémi Denis-Courmont]

Hello,

Le mercredi 15 janvier 2014, 19:35:28 shirish शिरीष a écrit :
> In vlc sometimes the audio is there, sometimes not. This is from a vlc
> - session of a media file I was playing :-

PulseAudio keeps going into underflow. Do you hear any audio at all (with 
silences) or do you hear nothing? It seems like the PulseAudio daemon is 
acting up, but it could also be something wrong with the source file.

-- 
Rémi Denis-Courmont
http://www.remlab.net/


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

Bug#742537: Pending fixes for bugs in the libaudio-mixer-perl package

[pkg-perl-maintainers]

tag 742537 + pending
thanks

Some bugs in the libaudio-mixer-perl package are closed in revision
9262c946bc0e3fb66edfd31d857933aaa77859b0 in branch 'master' by gregor
herrmann

The full diff can be seen at
http://anonscm.debian.org/gitweb/?p=pkg-perl/packages/libaudio-mixer-perl.git;a=commitdiff;h=9262c94

Commit message:

Add patch to fix build failure with clang.

Thanks: Nicolas Sévelin-Radiguet for the bug report and the patch.
Closes: #742537


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

Bug#742614: RM: bowtie2 [i386 hurd-i386 kfreebsd-i386] -- ANAIS; new release does not build on architectures other than amd64

[Alex Mestiashvili]

Package: ftp.debian.org
Severity: normal

Dear FTP Masters,

New upstream release of bowtie2 doesn't build on mentioned in the 
subject architectures.
In order to force transition from unstable to testing could you please 
consider removal of packages in testing with non amd64 architectures ?
Also even if we could provide i386 builds in the past, it seems that 
nobody is using it on i386 because normally it requires big amounts of 
memory.


Thank you,
Alex

Note: this was a request for a partial removal from testing, converted 
in one for unstable



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

Bug#742619: linux: Please reenable CONFIG_SCSI_PROC_FS

[Christian Seiler]

Package: linux
Version: 3.2.54-2
Severity: wishlist

Some hardware vendor tools (e.g. HP Library and Tape Tools) still rely 
on the

existence of /proc/scsi.

In Squeeze /proc/scsi was re-enabled in linux-2.6 (2.6.32-32) see also 
#618258

and it is still default upstream:

path: root/drivers/scsi/Kconfig
blob: c8bd092fc945fd5a1a407b170c398e126beaa0e4 (plain)

config SCSI_PROC_FS
bool "legacy /proc/scsi/ support"
depends on SCSI && PROC_FS
default y
---help---
  This option enables support for the various files in
  /proc/scsi.  In Linux 2.6 this has been superseded by
  files in sysfs but many legacy applications rely on this.

  If unsure say Y.

Many other distributions, for example Ubuntu and Fedora, activate it by
default in all recent versions.

Unfortunately, in Wheezy it is disabled again:
  /boot/config-3.2.0-4-amd64:# CONFIG_SCSI_PROC_FS is not set

To re-enable /proc/scsi is an unobtrusive change which would help a lot
if one depends on one of these vendor applications.

Please consider this small change for both Wheezy and Jessie.

Thank you.

Regards,
Christian


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

Bug#735940:

[Zooko Wilcox-OHearn]

On Tue, Mar 25, 2014 at 2:26 PM, Olivier Schwander
 wrote:
> Hum, I just gave a quick look at the debian package and I do not understand 
> how these files are produced for the binary package.
>
> Do you know where these 3 files come from ? Some magic inside setup.py or 
> something like that ?

Yes, all files in src/allmydata/web/static ¹ get included into the
package built by "setup.py", because it is marked in setup.py as being
"package_data" ².

Does that answer your question?

¹ https://tahoe-lafs.org/trac/tahoe-lafs/browser/trunk/src/allmydata/web/static

² 
https://tahoe-lafs.org/trac/tahoe-lafs/browser/trunk/setup.py?annotate=blame&rev=37c8b733a57dbbc4f9db0b3c8427f4e07994c3fa#L454

Regards,

Zooko Wilcox-O'Hearn

Founder, CEO, and Customer Support Rep
https://LeastAuthority.com
Freedom matters.


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

Bug#403359: vlc: Ogg muxing crashes on PowerPC

[Rémi Denis-Courmont]

tags 403359 + moreinfo
thanks

Hello,

This was filed against an ancient version. Does the problem still exist? If so, 
can you please provide a stack trace from gdb?

Regards,

-- 
Rémi Denis-Courmont
http://www.remlab.net/


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

Bug#742626: transmission-daemon: SEGFAULT on first run, breaks installation

[Antoine]

Package: transmission-daemon
Version: 2.82-1.1
Severity: grave

Dear Maintainer,

When installing transmission-daemon from APT on a Jessie/Sid with
systemd enabled,
dpkg fails with:

Setting up transmission-daemon (2.82-1.1) ...
Job for transmission-daemon.service failed. See 'systemctl status
transmission-daemon.service' and 'journalctl -xn' for details.
invoke-rc.d: initscript transmission-daemon, action "start" failed.
dpkg: error processing package transmission-daemon (--configure):
 subprocess installed post-installation script returned error exit status 1
Errors were encountered while processing:
 transmission-daemon
E: Sub-process /usr/bin/dpkg returned an error code (1)

---
systemctl status transmission-daemon.service:

transmission-daemon.service - Transmission BitTorrent Daemon
   Loaded: loaded (/lib/systemd/system/transmission-daemon.service; enabled)
   Active: failed (Result: signal) since Tue 2014-03-25 18:00:02 CET; 3s ago
  Process: 21567 ExecStart=/usr/bin/transmission-daemon -f --log-error
(code=killed, signal=SEGV)

Mar 25 18:00:02 HAL9000 systemd[1]: transmission-daemon.service: main
process exited, code=killed, status=11/SEGV
Mar 25 18:00:02 HAL9000 systemd[1]: Failed to start Transmission
BitTorrent Daemon.
Mar 25 18:00:02 HAL9000 systemd[1]: Unit transmission-daemon.service
entered failed state.

---
journalctl -xn:

Mar 25 18:00:02 HAL9000 systemd[1]: Starting Transmission BitTorrent
Daemon...
-- Subject: Unit transmission-daemon.service has begun with start-up
-- Defined-By: systemd
-- Support: http://lists.freedesktop.org/mailman/listinfo/systemd-devel
--
Mar 25 18:00:02 HAL9000 systemd[1]: ^[[1;39mtransmission-daemon.service:
main process exited, code=killed, status=11/SEGV
Mar 25 18:00:02 HAL9000 systemd[1]: Failed to start Transmission
BitTorrent Daemon.
-- Subject: Unit transmission-daemon.service has failed
-- Defined-By: systemd
-- Support: http://lists.freedesktop.org/mailman/listinfo/systemd-devel
-- Documentation:
http://www.freedesktop.org/wiki/Software/systemd/catalog/be02cf6855d2428ba40df7e9d022f03d
--
-- Unit transmission-daemon.service has failed.
--
-- The result is failed.
Mar 25 18:00:02 HAL9000 systemd[1]: ^[[1;39mUnit
transmission-daemon.service entered failed state.
Mar 25 18:00:02 HAL9000 kernel: transmission-da[21568]: segfault at 4 ip
7f33820e50d9 sp 7f337f427c70 error 6 in
libc-2.18.so[7f3382032000+1a]

---
dmesg:

[696101.280302] transmission-da[14197]: segfault at 4 ip
7ffaa88090d9 sp 7ffaa5b4bc70 error 6 in
libc-2.18.so[7ffaa8756000+1a]
[696196.961054] transmission-da[14308]: segfault at 4 ip
7f216f1860d9 sp 7f216c4c8c70 error 6 in
libc-2.18.so[7f216f0d3000+1a]
[696784.801122] systemd-journald[5761]: Received SIGTERM
[697205.962314] transmission-da[15326]: segfault at 4 ip
7f6da8bde0d9 sp 7f6da5f20c70 error 6 in
libc-2.18.so[7f6da8b2b000+1a]
[697398.874194] transmission-da[15705]: segfault at 4 ip
7f31d3b170d9 sp 7f31d0e59c70 error 6 in
libc-2.18.so[7f31d3a64000+1a]
[697422.107965] transmission-da[16045]: segfault at 4 ip
7fc1c3d870d9 sp 7fc1c10c9c70 error 6 in
libc-2.18.so[7fc1c3cd4000+1a]
[697624.112075] transmission-da[16442]: segfault at 4 ip
7fab065a70d9 sp 7fab038e9c70 error 6 in
libc-2.18.so[7fab064f4000+1a]
[697950.096000] transmission-da[16822]: segfault at 4 ip
7f13591070d9 sp 7f1356449c70 error 6 in
libc-2.18.so[7f1359054000+1a]
[698149.121412] nr_pdflush_threads exported in /proc is scheduled for
removal
[698149.121487] sysctl: The scan_unevictable_pages sysctl/node-interface
has been disabled for lack of a legitimate use case.  If you have one,
please send an email to linux...@kvack.org.
[698230.071983] transmission-da[17870]: segfault at 4 ip
7f99817940d9 sp 7f997ead6c70 error 6 in
libc-2.18.so[7f99816e1000+1a]
[698714.851039] transmission-da[20764]: segfault at 4 ip
7f9afecaf0d9 sp 7f9afbff1c70 error 6 in
libc-2.18.so[7f9afebfc000+1a]



With Wheezy version (2.52-3+nmu1) everything goes fine.

Tell me if you need any further details.

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

Kernel: Linux 3.13-1-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 transmission-daemon depends on:
ii  adduser  3.113+nmu3
ii  init-system-helpers  1.18
ii  libc62.18-4
ii  libcurl3-gnutls  7.35.0-1
ii  libevent-2.0-5   2.0.21-stable-1
ii  libminiupnpc81.6-3
ii  libnatpmp1   20110808-3
ii  libssl1.0.0  1.0.1f-1
ii  libsystemd-daemon0   204-8
ii  lsb-base 4.1+Debian12
ii  transmission-common  2.82-1.1
ii  zlib1g   1:1.2.8.dfsg-1

Versions of packages transmissi

Bug#730801: Pending fixes for bugs in the fonts-migmix package

[pkg-fonts-devel]

tag 730801 + pending
thanks

Some bugs in the fonts-migmix package are closed in revision
1ed8a7c7b2891fa1abaf4c32c34e687c8e07b6c2 in branch 'master' by Youhei
SASAKI

The full diff can be seen at
http://anonscm.debian.org/gitweb/?p=pkg-fonts/fonts-migmix.git;a=commitdiff;h=1ed8a7c

Commit message:

Fix short description (Closes: #730801)

Signed-off-by: Youhei SASAKI 


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

Bug#742627: mutt-patched: full text search (l + ~b ) is extremely slow

[Tomasz Buchert]

Package: mutt-patched
Version: 1.5.23-1
Severity: important

Dear Maintainer,

   * What led up to the situation?
 I installed mutt-patched recently to get a sidebar. Everything was fine
 till I tried to search in my all messages (17k of them) using "l" + "~b
"
 as I often do.

   * What exactly did you do (or not do) that was effective (or
 ineffective)?
 Mutt-patched is EXTREMELY slow when doing full message search
 and checks roughly 20 mails per second. In plain mutt the whole search
 finishes in less then 4 seconds.
  I thought that my SSD is dying, but then I reinstalled a standard mutt
 package and everything went back to normal state.

   * What outcome did you expect instead?
  I would expect mutt-patched search speed to be similar to mutt.
  It so much worse that I wonder what the problem may be.

I reverted to a plan mutt for the reason above.

Cheers,
Tomasz



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

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

Versions of packages mutt-patched depends on:
ii  libassuan02.1.1-1
ii  libc6 2.18-4
ii  libcomerr21.42.9-3
ii  libgnutls26   2.12.23-13
ii  libgpg-error0 1.12-0.2
ii  libgpgme111.4.3-0.1
ii  libgssapi-krb5-2  1.12.1+dfsg-1
ii  libidn11  1.28-1
ii  libk5crypto3  1.12.1+dfsg-1
ii  libkrb5-3 1.12.1+dfsg-1
ii  libncursesw5  5.9+20140118-1
ii  libsasl2-22.1.26.dfsg1-9
ii  libtinfo5 5.9+20140118-1
ii  libtokyocabinet9  1.4.48-2
ii  mutt  1.5.23-1

mutt-patched recommends no packages.

mutt-patched 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#742587: tificc man page: wtpt ?

[Thomas Weber]

Hi Mathieu, 
On Tue, Mar 25, 2014 at 09:57:00AM +0100, Mathieu Malaterre wrote:
> Package: liblcms2-utils
> Version: 2.5-1
> 
> man page for tificc still refers to wtpt which does not seems to be
> distributed in lcms2 anymore.

Well, the source for both the wtpt binary and the wtpt man page are
still distributed in the upstream tarball in utils/samples/, but they
are not built by default anymore. 

Do you think it would be helpful to include the samples (there are
several of them) in the documentation of the -dev package?

Thomas


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

Bug#742609: warn_alloc_failed+0x11f/0x134 linux-image-3.2.0-4-amd64 3.2.54-2

[Ben Hutchings]

Control: tag -1 moreinfo

It's very hard to read this log due to word-wrapping.

It looks like you've enabled jumbo frames with a network driver that
doesn't support scatter/gather.  This is bound to fail under memory
pressure.  (mlx4_en was changed to avoid this problem in Linux 3.11, but
this is unlikely to be backported to wheezy.)

It also appears that memory usage is very unbalanced between the
multiple NUMA nodes (i.e. processor packages).  Are you using explicit
NUMA placement of application memory?

Ben.

-- 
Ben Hutchings
Make three consecutive correct guesses and you will be considered an expert.


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

Bug#742547: vlan: Fixing #705456 introduces a regression

[ard]

Hi,

On Tue, Mar 25, 2014 at 08:12:14AM +0100, ard wrote:
> Hmmm, actually I am a little bit surprised that the mere
> mentioning of eth1.20 in the bridge configuration automagically
> creates eth1.20.

A look into the bridge code:
if [ "$MODE" = "start" ] && [ ! -d /sys/class/net/$IFACE/brif/$port ]; then
  if [ -x /etc/network/if-pre-up.d/vlan ]; then
env IFACE=$port /etc/network/if-pre-up.d/vlan
  fi

the magic you describes seems to happen and removing this broke the bridge
utils package.

> I would suspect that the first 2 lines should be:
> 
> auto eth1.20
> iface eth1.20 inet manual

This still stands: I didn't know the bridge scripts were using the vlan
scripts.
Just using these two lines for every port you use in the bridge will fix your
current problem.

As for the regression: I am not sure what to do about it.
Even if it was not NMU'd I would have removed the vlan part...

Let me think

-- 
.signature not found


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

Bug#742462: kde-workspace-bin: ksystraycmd has no man page

[Maximiliano Curia]

Control: tag -1 + gift upstream

In article 
 
you wrote:
> Package: kde-workspace-bin
> Version: 4:4.8.4-6
> Severity: normal

> According to http://www.debian.org/doc/debian-policy/ch-docs.html:
> "Each program, utility, and function should have an associated
> manual page included in the same package. [...] If no manual page is
> available, this is considered as a bug and should be reported to the
> Debian Bug Tracking System".

The bug is reported to stable, which won't get an update for a manpage, but
the claim is still valid in upstream head.

A manpage written in docbook would be welcome, (it needs to be in docbook so
upstream accepts it).

Feel free to forward the bug upstream [1], if you do, please, add the
forwarded info [2] so we get notified if the status changes.

[1]: http://bugs.kde.org
[2]: http://pkg-kde.alioth.debian.org/btslink.html

Thanks,
-- 
"If a pickpocket meets a saint, he sees only his pockets."
-- Kegley's Law
Saludos /\/\ /\ >< `/


signature.asc
Description: Digital signature

Bug#742628: gvfs mount list duplicate entries

[Liken Wolf]

Package: gvfs
Version: 1.16.3-2
Severity: normal

Dear Maintainer,

Every time I eject and insert a CF card through a PCMCIA Adapter
the device is duplicated in the list 'gvfs-mount -l', and also in the sidebar
of thunar file manager. The same effect when suspending/resuming.
So, I have about 20 CF cards  in this moment, and you have to figure out which
one is the true CF card in order to mount it.

As you can see:

gvfs-mount -l

Drive(1): SMI MODEL
  Type: GProxyDrive (GProxyVolumeMonitorUDisks2)
  Volume(0): CF16GB
Type: GProxyVolume (GProxyVolumeMonitorUDisks2)
  Volume(1): CF16GB
Type: GProxyVolume (GProxyVolumeMonitorUDisks2)
  Volume(2): CF16GB
Type: GProxyVolume (GProxyVolumeMonitorUDisks2)
  Volume(3): CF16GB
Type: GProxyVolume (GProxyVolumeMonitorUDisks2)
  Volume(4): CF16GB
Type: GProxyVolume (GProxyVolumeMonitorUDisks2)
  Volume(5): CF16GB
Type: GProxyVolume (GProxyVolumeMonitorUDisks2)
  Volume(6): CF16GB
Type: GProxyVolume (GProxyVolumeMonitorUDisks2)
  Volume(7): CF16GB
Type: GProxyVolume (GProxyVolumeMonitorUDisks2)


*** Reporter, 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 template lines ***



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

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

Versions of packages gvfs depends on:
ii  gvfs-common   1.16.3-2
ii  gvfs-daemons  1.16.3-2
ii  gvfs-libs 1.16.3-2
ii  libc6 2.18-4
ii  libglib2.0-0  2.38.2-5
ii  libudev1  204-8

gvfs recommends no packages.

Versions of packages gvfs suggests:
ii  gvfs-backends  1.16.3-2

-- 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#685506: Problem with *.zip archives

[Andreas Tille]

Hi,

On Sat, Mar 22, 2014 at 12:01:37AM +0100, Joachim Breitner wrote:
> $ tar taf ../Mothur.1.33.3.tar.xz|wc -l
> $ tar taf ../mothur_1.33.3+dfsg.orig.tar.xz|wc -l
> 
> what do you get?

the mothur issue is settled but I think there is a new problem with
ordinary *.tgz files now:  Please try:

  apt-get source gnumed-client
  cd 
  debian/rules get-orig-source

I get:

$ debian/rules get-orig-source
uscan --verbose --force-download --repack-compression xz
-- Scanning for watchfiles in .
-- Found watchfile in ./debian
-- In debian/watch, processing watchfile line:
   opts="dversionmangle=s/\+dfsg//g" 
http://www.gnumed.de/downloads/gnumed-versions.txt
http://www.gnumed.de/downloads/client/[\d\.]+/gnumed-client\.([\d\.]+)\.tgz
-- Found the following matching hrefs:
 http://www.gnumed.de/downloads/client/1.4/gnumed-client.1.4.7.tgz (1.4.7)
Newest version on remote site is 1.4.7, local version is 1.4.6+dfsg
 (mangled local version number 1.4.6)
 => Forcing download as requested
-- Downloading updated package gnumed-client.1.4.7.tgz
Cannot determine compression method of gnumed-client.1.4.7.tgz at 
/home/andreas/bin/uscan line 1969.
make: *** [get-orig-source] Fehler 255


I also got the message 

  Cannot determine compression method of ... at /home/andreas/bin/uscan line 
1969.   
  

for an ordinary *.tgz without any attempt to unpack (for gnumed-server 
actually).

Any clue what might went wrong?

Kind regards

   Andreas.

-- 
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#656719: R: Bug#656719: Please provide xvmc and vdpau Gallium3D video acceleration drivers (libg3dvl-mesa package)

[Fabio Pedretti]

>2014-03-23 21:19 GMT+01:00 Julien Cristau :
>> On Sat, Mar 22, 2014 at 19:03:52 +0100, Pali Rohár wrote:
>>
>>> Hello!
>>>
>>> It looks like nouveau, r600 and radeonsi vdpau drivers are already in
>>> debian repository. But not xvmc libraries. See:
>>>
>> Correct, we're probably not going to be enabling xvmc.
>>
>> Cheers,
>> Julien
>
>Can I ask for reason why not to enable also xvmc?
>
>-- 
>Pali Rohár
>pali.ro...@gmail.com

There are apparently only two Debian packages that can leverage XvMC support: 
mplayer and gxine. Other not packaged software may also use it anyway. Other 
packages (not many, however) can use VDPAU (supported by open source mesa 
drivers).

However the current status doesn't make a lot of sense: some software could 
use XvMC but free mesa drivers are not provided. Since xvmc library is 
supported in Debian I suppose free mesa drivers should also be provided. If we 
don't want to support open source XvMC drivers we should also consider 
deprecating libxvmc and recompiling software packages without it.

There may be also other technical (bugs or missing features) or non technical 
(no developer care enough to do it or is able to test it or whatever was the 
reason VDPAU took over 2 years to be packaged or glamor is still not) reasons 
not to provide xvmc mesa drivers but I don't know them.


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

Bug#742587: tificc man page: wtpt ?

[Mathieu Malaterre]

On Tue, Mar 25, 2014 at 6:18 PM, Thomas Weber  wrote:
> Hi Mathieu,
> On Tue, Mar 25, 2014 at 09:57:00AM +0100, Mathieu Malaterre wrote:
>> Package: liblcms2-utils
>> Version: 2.5-1
>>
>> man page for tificc still refers to wtpt which does not seems to be
>> distributed in lcms2 anymore.
>
> Well, the source for both the wtpt binary and the wtpt man page are
> still distributed in the upstream tarball in utils/samples/, but they
> are not built by default anymore.
>
> Do you think it would be helpful to include the samples (there are
> several of them) in the documentation of the -dev package?
>
> Thomas

Clearly wtpt should not be referenced anymore:

https://sourceforge.net/p/lcms/mailman/message/32141849/


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

Bug#741573: On menu systems.

[Matthew Vernon]

Charles Plessy  writes:

> Over almost one year of work and discussion, including a call for comments on
> the debian-devel mailing list, we have shaped a modification to the Debian
> Policy that 1) incorporates the description of the FreeDesktop menu system and
> its use in Debian for listing program in desktop menus and associating them
> with media types, and 2) softens the wording on the Debian Menu system to
> reflect that in Jessie it will be neither displayed nor installed by default 
> on
> standard Debian installations.

I'm rather non-plussed by the proposal to devalue the Debian Menu
system. I use fvwm, and while for frequently-used apps I don't use the
menu (instead launching them from particular keys), the Debian menu is
how I both launch apps I use less frequently, and explore what I've
got installed. Its comprehensive coverage means that if I'm not quite
sure what application I want, I can have a bit of a browse and try
things out. Any proposal that reduces the coverage of the Debian Menu
seems a bad idea for me...

Regards,

Matthew

-- 
"At least you know where you are with Microsoft."
"True. I just wish I'd brought a paddle."
http://www.debian.org


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

Bug#741304: add FHS exception for arch-indep in /usr/lib

[Michael Biebl]

Am 20.03.2014 23:58, schrieb Bill Allombert:
> On Mon, Mar 17, 2014 at 12:39:17AM +0100, Michael Biebl wrote:
>> On Mon, Mar 10, 2014 at 06:39:20PM -0400, Joey Hess wrote:
>>> So, I propse adding to the list of exceptions in policy section 9.1.1:
>>>
>>>The FHS requirement that architecture-independent application-specific
>>>static files be located in /usr/share is relaxed to a suggestion.
>>>
>>>In particular, a subdirectory of /usr/lib may be used by a package
>>>(or a collection of packages) to hold a mixture of 
>>> architecture-independent
>>>and architecture-dependent files. However, when a directory is
>>>entirely composed of architecture-independent files, it should be
>>>located in /usr/share.
>>
>> Seconded.
> 
> So I have created a branch 'bug741304-bill' with this change.
> Please check the diff (in attachment).

lgtm, thanks


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



signature.asc
Description: OpenPGP digital signature

Bug#741573: On menu systems.

[Paul Tagliamonte]

On Tue, Mar 25, 2014 at 05:40:27PM +, Matthew Vernon wrote:
> I'm rather non-plussed by the proposal to devalue the Debian Menu
> system. I use fvwm, and while for frequently-used apps I don't use the
> menu (instead launching them from particular keys), the Debian menu is
> how I both launch apps I use less frequently, and explore what I've
> got installed. Its comprehensive coverage means that if I'm not quite
> sure what application I want, I can have a bit of a browse and try
> things out. Any proposal that reduces the coverage of the Debian Menu
> seems a bad idea for me...

Since DE/WMs are coming up, let me put on my Fluxbox (as the Debian
maintainer, not as upstream) hat.


Fluxbox is one of the larger consumers of the menu system. There have been
murmers for the last fre years in the fluxbox dev rooms about eventually
adding XDG Menu stuff into fluxbox, to replace the home-brew menu files
in ~/.fluxbox

A statement that the menu system in Debian is out-of-date and other systems
(which, frankly, work better) are the prefered system to use would likely be
the kick that we need to exorcise menu from Fluxbox (likely upstream as
well, but I'm not speaking to that right now).


Cheers,
  Paul

-- 
 .''`.  Paul Tagliamonte   |   Proud Debian Developer
: :'  : 4096R / 8F04 9AD8 2C92 066C 7352  D28A 7B58 5B30 807C 2A87
`. `'`  http://people.debian.org/~paultag
 `- http://people.debian.org/~paultag/conduct-statement.txt


signature.asc
Description: Digital signature

Bug#718434: fixed in ca-certificates 20140223

[Bas Wijnen]

On Mon, Mar 24, 2014 at 03:16:51PM +0100, Christoph Anton Mitterer wrote:
> I just agreed to Ivan's opinion... right now many people say "it's
> better to do crypto, even if it's anonymous and you have no idea who
> you're talking to"... their reason is usually on of
> - the attacker may miss the point where the communication starts and
> therefore the point where he could do an MitM
> - even if the attacker does MitM, he would need more computing power
> (and therefore money) to decrypt everything.

No, the point is that an attacker is detectable.  Do you think the NSA
does MITM attacks on all connections?  I seriously thought that they
might.  So when I traveled from the US to the Netherlands, I took a copy
of the key of my machine in the Netherlands, as seen from my browser in
the US.  I compared that copy when I was in the Netherlands, and it
matched.

If the NSA starts doing this, someone will catch them.  That will be big
news and everyone will start checking their keys.  And if none of them
match, things will be fixed.  As long as they don't do it, checks like
the one I did will confirm that nothing is wrong.

Well, not exactly, of course.  It is still very likely that they are
trying to (and also that they succeeded to) put back doors into the
encryption protocols, or at least their implementations.

> But that's just the point...  When an attacker sits on the line
> between A and B,.. and they don't encrypt... than obviously he can
> read/tamper with everything.

Depending on what you mean by "sitting on the line".  They can always
read, but to tamper they need to sit "in" the line, not just on it.
They have to make sure the original packets don't reach their
destination.  I take it that's what you mean.

(Note that this is a much smaller group of machines; for example, I can
read all traffic on the subnet of my block of houses, but I can't
effectively tamper with it.)

> If the attacker sits on the line between Alice and Bob (which he
> apparently does, since he was able to read the unencrypted stuff)... and
> if Alice and Bob don't verify their identities... then he can to MitM...
> just as you explained it above.

But if they start to doubt, they can check if they have been attacked,
by comparing their keys through an independent channel.  There will have
been a small window where their communication was intercepted, but
that's still much better than having everything always public.

> So I'd say... anonymous encryption does not really help that much...
> at least not against someone who constantly sits on the line and
> watches all traffic (which NSA&friends surely do) It gives rather a
> wrong sense of security.

Anonymous encryption is better than no encryption.  And it gives actual
security.  Certainly against people who are only listening (of which
there are many), and (with a small delay where you might send sensitive
data to the NSA) also against MITM attacks, because some people will
check some keys every now and then.  If any of them is found to be under
attack, more checks will be done; if many of those will fail, all hell
will break loose.

And the NSA is not stupid.  They know this.  So they aren't going to
try.  Instead, they are claiming that "it doesn't really help anything"
and "it only gives a false sense of security", to convince people that
not encrypting is better than encrypting with unchecked keys.  Sure they
like it when the entire internet is unencrypted, it makes their work
easier.  It does not however provide any benefit to us or our users.

> > A certificate authority does not provide the encryption keys.  It only
> > puts signatures on them.  Without any CA, you can still encrypt if you
> > have the target's public key.
> Well sure.. but what do you want to tell us? Of course you can.. but
> nobody usually manually trusts X.509 certs (i.e. non-CA-certs)

You're claiming that having an evil CA in the list means that my
communication is in danger of being eavesdropped.  I'm saying that this
is nonsense, because:

> > An evil CA cannot read your traffic (unless they are in
> > the path of your communication).

You are saying that the NSA has control over evil CAs, and also is in
the path of communication.  So they can eavesdrop.  Technically this is
true.  But there are two things to consider:

1. Due to the fact that they would be detected if they tried this on a
   large scale, they won't actually do this.
2. Your conclusion that because the NSA can eavesdrop, we should allow
   everyone else too (by not encrypting at all) is beyond ridiculous.

Thanks,
Bas


signature.asc
Description: Digital signature

Bug#741304: add FHS exception for arch-indep in /usr/lib

[Michael Biebl]

Am 25.03.2014 18:56, schrieb Michael Biebl:
> Am 20.03.2014 23:58, schrieb Bill Allombert:
>> On Mon, Mar 17, 2014 at 12:39:17AM +0100, Michael Biebl wrote:
>>> On Mon, Mar 10, 2014 at 06:39:20PM -0400, Joey Hess wrote:
 So, I propse adding to the list of exceptions in policy section 9.1.1:

The FHS requirement that architecture-independent application-specific
static files be located in /usr/share is relaxed to a suggestion.

In particular, a subdirectory of /usr/lib may be used by a package
(or a collection of packages) to hold a mixture of 
 architecture-independent
and architecture-dependent files. However, when a directory is
entirely composed of architecture-independent files, it should be
located in /usr/share.
>>>
>>> Seconded.
>>
>> So I have created a branch 'bug741304-bill' with this change.
>> Please check the diff (in attachment).


I'm not a native speaker, but

+The FHS requirement that architecture-independent
+application-specific static files be located in

I'd probably change that to
"application-specific static files must be located"
to emphasize that a must directive was relaxed to should.


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



signature.asc
Description: OpenPGP digital signature

Bug#742629: libvtk6-dev package should depend on libjsoncpp-dev

[Daniele E. Domenichelli]

Package: libvtk6-dev
Version: 6.0.0-5
Severity: normal

Dear Maintainer,

In /usr/lib/cmake/vtk-6.0/VTKTargets-none.cmake lines 991-997 you can find

 # Import target "vtkIOGeometry" for configuration "None"
 set_property(TARGET vtkIOGeometry APPEND PROPERTY IMPORTED_CONFIGURATIONS NONE)
 set_target_properties(vtkIOGeometry PROPERTIES
   IMPORTED_LINK_INTERFACE_LIBRARIES_NONE "[...];jsoncpp"
   [...]
   )

Since the IMPORTED_LINK_INTERFACE_LIBRARIES_NONE property includes
jsoncpp any CMake project linking to vtkIOGeometry (or the VTK_LIBRARIES
variable that includes vtkIOGeometry) will try to link with -ljsoncpp,
therefore the libjsoncpp-dev is required.

Please consider adding it to the dependencies of the libvtk6-dev package.


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

Kernel: Linux 3.13-1-amd64 (SMP w/8 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 libvtk6-dev depends on:
ii  libavcodec-dev 6:10-1
ii  libavformat-dev6:10-1
ii  libavutil-dev  6:10-1
ii  libc6-dev  2.18-4
ii  libexpat1-dev [libexpat-dev]   2.1.0-4
ii  libfreetype6-dev   2.5.2-1
ii  libgdal-dev1.10.1+dfsg-4
ii  libgl1-mesa-dev [libgl-dev]9.2.2-1
ii  libgl2ps-dev   1.3.8-1
ii  libglu1-mesa-dev [libglu-dev]  9.0.0-2
ii  libjpeg8-dev [libjpeg-dev] 8d-2
ii  libmysqlclient-dev 5.5.35+dfsg-2
ii  libnetcdf-dev  1:4.1.3-7
ii  libpng12-dev [libpng-dev]  1.2.50-1
ii  libpq-dev  9.3.3-2
ii  libqt4-dev 4:4.8.5+git242-g0315971+dfsg-2
ii  libswscale-dev 6:10-1
ii  libtiff5-dev [libtiff-dev] 4.0.3-8
ii  libvtk66.0.0-5
ii  libvtk6-java   6.0.0-5
ii  libx11-dev 2:1.6.2-1
ii  libxft-dev 2.3.1-2
ii  libxml2-dev2.9.1+dfsg1-3
ii  libxss-dev 1:1.2.2-1
ii  libxt-dev  1:1.1.4-1
ii  mpi-default-dev1.0.2+nmu1
ii  python-vtk66.0.0-5
ii  tcl-vtk6   6.0.0-5
ii  tcl8.6-dev 8.6.1-6
ii  tk8.6-dev  8.6.1-5
ii  vtk6   6.0.0-5
ii  x11proto-core-dev  7.0.24-1
ii  zlib1g-dev 1:1.2.8.dfsg-1

libvtk6-dev recommends no packages.

Versions of packages libvtk6-dev suggests:
pn  vtk6-doc   
pn  vtk6-examples  

-- 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#741573: On menu systems.

[Russ Allbery]

Matthew Vernon  writes:

> I'm rather non-plussed by the proposal to devalue the Debian Menu
> system. I use fvwm, and while for frequently-used apps I don't use the
> menu (instead launching them from particular keys), the Debian menu is
> how I both launch apps I use less frequently, and explore what I've got
> installed. Its comprehensive coverage means that if I'm not quite sure
> what application I want, I can have a bit of a browse and try things
> out. Any proposal that reduces the coverage of the Debian Menu seems a
> bad idea for me...

(Speaking with my Policy hat on, per my previous message to this bug.)

There are two different issues here, which unfortunately are currently
linked.

The first issue is the file format and, more generally, the data model.
While there are some features in the Debian menu file format that are not
present in desktop files, I don't believe any of them are particularly
vital.  There are more features in desktop files that are not currently
representable in the Debian menu file format.  And, more importantly, the
desktop file format is a general standard, the files are often shipped by
upstream, and the format is being actively developed and improved by other
people whose work we can take advantage of.

While there are some transition headaches, I think the file format and
data model of desktop files is generally better, and that aligning with it
will reduce our maintenance and integration burden going forward.  I think
we should be working towards a long-term goal of adopting desktop files
and phasing out menu files.  (Note that, by this, I mean the files in
/usr/share/menu that are shipped by individual packages, not the files in
/etc/menu-methods that provide integration with window managers.)

The second issue is integration of the menu into Debian packages.  Right
now, the Debian native menu system has better integration, particularly
into the non-DE window managers.  (Putting aside for the moment that the
DEs largely disable the Debian native menu because it mostly duplicates
the menu generated from desktop files and they believe it to be less
useful.)  If we abandon menu files right now and switch entirely to
desktop files, we lose several integrations that we currently have.

I think the ideal long-term outcome would be for someone to do the work
that Charles did for the MIME registry and either convert from desktop
files to menu files for the benefit of our existing integrations or redo
those integrations to support desktop files, whichever makes the most
sense in any particular case.  That would let us switch to a more
broadly-used and widely-developed format and data model without losing any
features.

The problem at the moment is that no one has stepped forward to do that
work, and the desktop environment packaging teams are voting with their
feet towards using the desktop files instead of the Debian menu system for
a variety of reasons, mostly related to the additional features and better
integration in desktop environments offered by desktop files.  So, right
now, if you want complete integration of your package into all of the menu
systems, you have to provide configuration for both systems.

This is obviously rather annoying for packagers, and it would be nice to
avoid the duplicate work.

For most, but definitely not all, of our users, providing the desktop file
is more important than providing the menu configuration.  If we do
nothing, the likely outcome is that more and more packagers who are using,
e.g., GNOME or KDE will install or provide desktop files, find that their
program appears in the menus, assume they're done, and move on, and the
menu quality in other integrations like fvwm will keep declining.  I
believe this has been happening for the past couple of years, although
that's based on a gut feeling and I've not tried to acquire actual data.

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


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

Bug#742630: transition: tracker 1.0

[Michael Biebl]

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

Hi,

seeing that the gnome-desktop and cogl transitions were acked by the
release team, I think it would make sense to piggy-back a small tracker
transition.

The API version was finally declared stable and now uses 1.0.
Unfortunately this means sourceful changes for all affected packages.
I've notified those packages a while ago [0] and uploaded tracker 1.0 to
experimental (to get some build testing).

Quite a few of the packages are already affected by the cogl and
gnome-desktop transition, so imho it makes sense to just do them
together.

Please let me know if I'm ok to upload tracker 1.0 to unstable.

[0] 
https://bugs.debian.org/cgi-bin/pkgreport.cgi?users=bi...@debian.org;tag=tracker-0.18

Ben file:

title = "tracker";
is_affected = .depends ~ "libtracker-sparql-0.16-0" | .depends ~ 
"libtracker-sparql-1.0-0";
is_good = .depends ~ "libtracker-sparql-1.0-0";
is_bad = .depends ~ "libtracker-sparql-0.16-0";


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

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


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

Bug#742531: keyword.URL preference ignored after upgrade to version 23+

[E Taylor]

Hi Sylvestre,

Thank you for your clear explanation.  Hopefully I can explain my
position better this time.

>> As I see it, this is just a case of a config file format change, and
>> typically a Debian package would try to help the user preserve any
>> user-set value after upgrade.  Also, as in the example I gave, this
>> unannounced change of behaviour could lead to someone leaking sensitive
>> search terms out to an unintended third party, which has
>> privacy/security implications.
> Well, I haven't looked into the source code but if the preference has
> been removed from
> the configuration, I don't think the feature is still available.
> Having Debian taking care of bringing back features removed by upstream
> is a huge work.

Absolutely, and I wouldn't expect Debian to independently write and
maintain an extra configuration option which upstream didn't want.

In my original bug report I gave the steps for a manual workaround to
this problem, but perhaps I should have made explicit that I see this
workaround as evidence that the preference still exists, just in a
different form.  Mozilla have, quite wisely, decided that it doesn't
make sense for most people to have two different default search engines
(one for searches in the address bar and one for searches from the
search widget), so they now use the search widget preference for both. 
What I'm saying is, if a user has gone to the trouble of setting a value
for keyword.URL then this value should be used to set the default search
engine after the upgrade.

>> This issue seems similar to:
>> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=720968
>> ...
> I don't see that as a packaging bug. I don't think it is the goal of
> Debian to manage that.

As a precedent for Debian creating packages which automatically deal
with configuration format changes (which I hope you'll agree based on
the above is the situation here), please consider this documentation of
the apache2 package:
http://sources.debian.net/src/apache2/2.4.7-1/debian/apache2.NEWS#L45

> If you think it should be managed, you should push the change upstream
> (or look if there is an extension
> doing it):
> http://bugzilla.mozilla.org/

As you're probably aware, Mozilla are somewhat hesitant at applying
platform- (and certainly distro-) specific changes, for example:
https://bugzilla.mozilla.org/show_bug.cgi?id=620373
and I imagine that the handling of the config files related to this bug
is tightly bound to iceweasel/Debian.  Also I think it is unreasonable
to expect a user to wait until the upgrade has trampled their settings,
and sent their private data to a third party, before they go and search
for an extension which takes more effort to install than just fixing the
setting manually.

> Otherwise, expect if you provide a patch and commit to maintain it, yeh,
> I will probably close
> it like #720968

Well it seems to me that one benefit of having bugs open in a bug
tracker is so that people can be kept aware of what issues affect the
software they use, and potentially step forward to fix them if they have
the skill or resources to do so.  Closing a wishlist bug because a
volunteer hasn't yet been found seems counterproductive from that point
of view.  In any case, this bug only affects the wheezy -> jessie stable
transition, so feel free to close this after wheezy EOL.

Best regards,
Edwin


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

Bug#742536: Re: Bug#742536: lists.debian.org: New mailing list: debian-ppc64el

[Breno Leitao]

> tbh I don't think another list is needed for this subarch. We also only have
> one arm list. debian-ppc (which I still read) isn't very high traffic, so a
> little bit more traffic would be good for the list.
Right. I tend to agree with you. So, we will start to track this new port into
debian-powerpc mailing list.


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

Bug#741573: On menu systems.

[Cyril Brulebois]

Russ Allbery  (2014-03-25):
> For most, but definitely not all, of our users, providing the desktop
> file is more important than providing the menu configuration.  If we
> do nothing, the likely outcome is that more and more packagers who are
> using, e.g., GNOME or KDE will install or provide desktop files, find
> that their program appears in the menus, assume they're done, and move
> on, and the menu quality in other integrations like fvwm will keep
> declining.  I believe this has been happening for the past couple of
> years, although that's based on a gut feeling and I've not tried to
> acquire actual data.

The following won't reflect packages possibly moving from menu to fdo,
but should give some idea (the {main/,} bit is there because stuff was
moved around on the archive side). Also, as you know, the archive keeps
growing.


Packages with menu files:
  $ for i in squeeze wheezy jessie; do printf "$i: ";  zgrep -h 
'^usr/share/menu/' $i/{main/,}Contents-amd64.gz 2>/dev/null | awk '{print $2}' 
| sort -u | wc -l; done
  squeeze: 2363
  wheezy: 2290
  jessie: 2306

=> stable

Menu files;
  $ for i in squeeze wheezy jessie; do printf "$i: ";  zgrep -h 
'^usr/share/menu/' $i/{main/,}Contents-amd64.gz 2>/dev/null | sort -u | wc -l; 
done
  squeeze: 2363
  wheezy: 2290
  jessie: 2306

=> stable


Packages with desktop files:
  $ for i in squeeze wheezy jessie; do printf "$i: ";  zgrep -h 
'^usr/share/applications/.*\.desktop\b' $i/{main/,}Contents-amd64.gz 
2>/dev/null | awk '{print $2}' | sort -u | wc -l; done
  squeeze: 1976
  wheezy: 2186
  jessie: 2324

=> +17% between squeeze and jessie.

Desktop files:
  $ for i in squeeze wheezy jessie; do printf "$i: ";  zgrep -h 
'^usr/share/applications/.*\.desktop\b' $i/{main/,}Contents-amd64.gz 
2>/dev/null | sort -u | wc -l; done
  squeeze: 2592
  wheezy: 2814
  jessie: 3010

=> +16% between squeeze and jessie.


Mraw,
KiBi.


signature.asc
Description: Digital signature

Bug#742631: iceweasel: Recently closed tabs list is always empty

[Pierre Rudloff]

Package: iceweasel
Version: 30.0~a2+20140321004003-1~bpo70+1
Severity: normal

Dear Maintainer,

In the last IceWeasel Aurora, the recently closed tabs list is always empty.
I can't reproduce with upstream Aurora (30.0a2).

Regards,



-- Package-specific info:


-- Addons package information

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

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

Versions of packages iceweasel depends on:
ii  debianutils 4.3.2
ii  fontconfig  2.9.0-7.1
ii  libc6   2.13-38+deb7u1
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  libsqlite3-03.7.13-1+deb7u1
ii  libstdc++6  4.7.2-5
ii  procps  1:3.3.3-3
ii  xulrunner-3030.0~a2+20140321004003-1~bpo70+1

iceweasel recommends no packages.

Versions of packages iceweasel suggests:
pn  fonts-mathjax  
pn  fonts-oflb-asana-math  
ii  fonts-stix [otf-stix]  1.1.0-1
ii  libgssapi-krb5-2   1.10.1+dfsg-5+deb7u1
pn  mozplugger 

Versions of packages xulrunner-30 depends on:
ii  libasound21.0.25-4
ii  libatk1.0-0   2.4.0-2
ii  libbz2-1.01.0.6-4
ii  libc6 2.13-38+deb7u1
ii  libcairo2 1.12.2-3
ii  libdbus-1-3   1.6.8-1+deb7u1
ii  libdbus-glib-1-2  0.100.2-1
ii  libevent-2.0-52.0.19-stable-3
ii  libffi5   3.0.10-3
ii  libfontconfig12.9.0-7.1
ii  libfreetype6  2.4.9-1.1
ii  libgcc1   1:4.7.2-5
ii  libgdk-pixbuf2.0-02.26.1-1
ii  libglib2.0-0  2.33.12+really2.32.4-5
ii  libgtk2.0-0   2.24.10-2
ii  libhunspell-1.3-0 1.3.2-4
ii  libpango1.0-0 1.30.0-1
ii  libstartup-notification0  0.12-1
ii  libstdc++64.7.2-5
ii  libx11-6  2:1.5.0-1+deb7u1
ii  libxext6  2:1.3.1-2+deb7u1
ii  libxrender1   1:0.9.7-1+deb7u1
ii  libxt61:1.1.3-1+deb7u1
ii  zlib1g1:1.2.7.dfsg-13

Versions of packages xulrunner-30 suggests:
ii  libcanberra0  0.28-6
ii  libgnomeui-0  2.24.5-2

-- 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#742633: obnam: program chokes and abort on files containing % in name

[Alberto Fuentes]

Package: obnam
Version: 1.7.2-1
Severity: normal

my bet is in the % in the name of the file... if it isnt, i can investage
further

Traceback:
01h48m59s 680 files 652.20 MiB scanned: /home/admin/.vim/undo/%var%tmp%tt-
rss.XXNOiCLMTraceback (most recent call last):
  File "/usr/lib/python2.7/dist-packages/cliapp/app.py", line 190, in _run
self.process_args(args)
  File "/usr/lib/python2.7/dist-packages/obnamlib/app.py", line 186, in
process_args
cliapp.Application.process_args(self, args)
  File "/usr/lib/python2.7/dist-packages/cliapp/app.py", line 539, in
process_args
method(args[1:])
  File "/usr/lib/python2.7/dist-packages/obnamlib/plugins/backup_plugin.py",
line 370, in backup
self.backup_roots(roots)
  File "/usr/lib/python2.7/dist-packages/obnamlib/plugins/backup_plugin.py",
line 531, in backup_roots
metadata)
  File "/usr/lib/python2.7/dist-packages/obnamlib/plugins/backup_plugin.py",
line 840, in backup_file_contents
f = self.fs.open(filename, 'r')
  File "/usr/lib/python2.7/dist-packages/obnamlib/plugins/sftp_plugin.py", line
562, in open
return self.sftp.file(pathname, mode, bufsize=bufsize)
  File "/usr/lib/python2.7/dist-packages/paramiko/sftp_client.py", line 232, in
open
self._log(DEBUG, 'open(%r, %r)' % (filename, mode))
  File "/usr/lib/python2.7/dist-packages/paramiko/sftp_client.py", line 114, in
_log
super(SFTPClient, self)._log(level, "[chan %s] " + msg, *([
self.sock.get_name() ] + list(args)))
  File "/usr/lib/python2.7/dist-packages/paramiko/sftp.py", line 132, in _log
self.logger.log(level, msg, *args)
  File "/usr/lib/python2.7/logging/__init__.py", line 1216, in log
self._log(level, msg, args, **kwargs)
  File "/usr/lib/python2.7/logging/__init__.py", line 1271, in _log
self.handle(record)
  File "/usr/lib/python2.7/logging/__init__.py", line 1281, in handle
self.callHandlers(record)
  File "/usr/lib/python2.7/logging/__init__.py", line 1321, in callHandlers
hdlr.handle(record)
  File "/usr/lib/python2.7/logging/__init__.py", line 749, in handle
self.emit(record)
  File "/usr/lib/python2.7/logging/handlers.py", line 842, in emit
msg = self.format(record) + '\000'
  File "/usr/lib/python2.7/logging/__init__.py", line 724, in format
return fmt.format(record)
  File "/usr/lib/python2.7/logging/__init__.py", line 464, in format
record.message = record.getMessage()
  File "/usr/lib/python2.7/logging/__init__.py", line 328, in getMessage
msg = msg % self.args
TypeError: not enough arguments for format string

from log:
tachikoma obnam: INFO Backing up /home/admin/.vim/undo/%var%tmp%tt-rss.XXNOiCLM
obnam: INFO Attempting to unlock client because of error



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

Kernel: Linux 3.13-1-amd64 (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 obnam depends on:
ii  libc6 2.18-4
ii  python2.7.5-5
ii  python-cliapp 1.20130808-1
ii  python-fuse   2:0.2.1-9
ii  python-larch  1.20131130-1
ii  python-paramiko   1.10.1-1
ii  python-tracing0.8-1
ii  python-ttystatus  0.23-1

obnam recommends no packages.

obnam suggests no packages.

-- debconf-show failed


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

Bug#742632: iceweasel: addon-sdk not working at launch

[Pierre Rudloff]

Package: iceweasel
Version: 30.0~a2+20140321004003-1~bpo70+1
Severity: normal

Dear Maintainer,

In the last IceWeasel Aurora, one my addons
(https://addons.mozilla.org/fr/firefox/addon/alltube-download/) that uses the
addon-sdk does not work correctly. Neither the toolbar button nor the context
menu is added. But if I disable then enable again the addon, it works
correctly, until the next time I start IceWeasel.
I can't reproduce this bug with upstream Aurora (30.0a2).

Regards,



-- Package-specific info:


-- Addons package information

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

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

Versions of packages iceweasel depends on:
ii  debianutils 4.3.2
ii  fontconfig  2.9.0-7.1
ii  libc6   2.13-38+deb7u1
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  libsqlite3-03.7.13-1+deb7u1
ii  libstdc++6  4.7.2-5
ii  procps  1:3.3.3-3
ii  xulrunner-3030.0~a2+20140321004003-1~bpo70+1

iceweasel recommends no packages.

Versions of packages iceweasel suggests:
pn  fonts-mathjax  
pn  fonts-oflb-asana-math  
ii  fonts-stix [otf-stix]  1.1.0-1
ii  libgssapi-krb5-2   1.10.1+dfsg-5+deb7u1
pn  mozplugger 

Versions of packages xulrunner-30 depends on:
ii  libasound21.0.25-4
ii  libatk1.0-0   2.4.0-2
ii  libbz2-1.01.0.6-4
ii  libc6 2.13-38+deb7u1
ii  libcairo2 1.12.2-3
ii  libdbus-1-3   1.6.8-1+deb7u1
ii  libdbus-glib-1-2  0.100.2-1
ii  libevent-2.0-52.0.19-stable-3
ii  libffi5   3.0.10-3
ii  libfontconfig12.9.0-7.1
ii  libfreetype6  2.4.9-1.1
ii  libgcc1   1:4.7.2-5
ii  libgdk-pixbuf2.0-02.26.1-1
ii  libglib2.0-0  2.33.12+really2.32.4-5
ii  libgtk2.0-0   2.24.10-2
ii  libhunspell-1.3-0 1.3.2-4
ii  libpango1.0-0 1.30.0-1
ii  libstartup-notification0  0.12-1
ii  libstdc++64.7.2-5
ii  libx11-6  2:1.5.0-1+deb7u1
ii  libxext6  2:1.3.1-2+deb7u1
ii  libxrender1   1:0.9.7-1+deb7u1
ii  libxt61:1.1.3-1+deb7u1
ii  zlib1g1:1.2.7.dfsg-13

Versions of packages xulrunner-30 suggests:
ii  libcanberra0  0.28-6
ii  libgnomeui-0  2.24.5-2

-- 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#742632: Log

[Pierre Rudloff]

Here is the cfx log with a clean profile :

Using binary at '/usr/bin/firefox'.
Using profile at '/tmp/tmp7eFZen.mozrunner'.
JavaScript error: chrome://browser/content/browser.js, line 9402:
NS_ERROR_FILE_NOT_FOUND: Component returned failure code: 0x80520012
(NS_ERROR_FILE_NOT_FOUND) [nsIXPCComponents_Utils.import]
JavaScript strict warning: chrome://browser/content/urlbarBindings.xml,
line 669: reference to undefined property this._value
JavaScript error: chrome://browser/content/urlbarBindings.xml, line 651:
aUrl is undefined


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

Bug#742563: linux: Black screen for internal laptop display on Intel HD Graphics 4400

[Ben Hutchings]

On Mon, 2014-03-24 at 23:46 -0400, Matt Horan wrote:
> On Tue, Mar 25, 2014 at 02:58:28AM +, Ben Hutchings wrote:
> > On Mon, 2014-03-24 at 21:20 -0400, Matthew Horan wrote:
> > > Source: linux
> > > Version: 3.14-rc7
> > > Severity: important
> > > Tags: upstream
> > > 
> > > Dear Maintainer,
> > > 
> > > When testing the linux-image-3.14-rc7-amd64 package from experimental, I
> > > discovered an issue with the handling of the internal laptop display.
> > > 
> > > The system boots but shortly after the kernel has loaded, the internal 
> > > laptop
> > > display goes blank. If an external display is connected, the system 
> > > displays
> > > boot messages on the external display instead of the internal display. If 
> > > xorg
> > > is started, only the external displplay is usable -- the internal display
> > > remains black. Closing the laptop lid and opening it reactivates the 
> > > internal
> > > display.
> > > 
> > > I was able to find an upstream bug [1] which may be relevant.
> > > 
> > > I do not experience this issue with the 3.13 kernel.
> > 
> > You didn't include the link.
> > 
> > Ben.
> > 
> > -- 
> > Ben Hutchings
> > Make three consecutive correct guesses and you will be considered an expert.
> 
> [1] https://bugs.freedesktop.org/show_bug.cgi?id=76103

Thanks, we'll track that bug report.

Ben.

-- 
Ben Hutchings
Make three consecutive correct guesses and you will be considered an expert.


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

Bug#742597: ITP: casperjs

[Julian Taylor]

some information on what it is and why its useful is in a corresponding
RFP bug 738827 (I guess we should merge these two bugs?)

thanks for checking the intent on packaging, I'll need it in near future
for ipython 2.0 :)


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

Bug#574947: Working on upgrading to 6.2.11

[Punit Agrawal]

I have a local version of the package that upgrades to the latest
upstream version - 6.2.11. While installing I seem to be hitting a bug
in emacsen-common (736062). Since this is my first time working on a
debian package any help resolving this issue will be appreciated.

I am hoping I can update the debian package once it's ready. In the
meanwhile if there's interest I could make the package available
somewhere.


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

Bug#742634: "pkgconf --libs foo" does not strip all -Lsystem_lib_dir fragments from its output

[Roderich Schupp]

Package: pkgconf
Version: 0.9.5-3
Severity: normal

"pkgconf --libs foo" only strips "-L/usr/lib" from its output, but not the
multiarch "-L/usr/lib/x86_64-linux-gnu" (as is done by pkg-config).

Example /usr/lib/x86_64-linux-gnu/pkgconfig/x264.pc
--- snip ---
prefix=/usr
exec_prefix=${prefix}
libdir=/usr/lib/x86_64-linux-gnu
includedir=${prefix}/include

Name: x264
Description: H.264 (MPEG4 AVC) encoder library
Version: 0.142.2389 956c8d8
Libs: -L/usr/lib/x86_64-linux-gnu -lx264
Libs.private: -lpthread -lm -ldl
Cflags: -I${prefix}/include
--- snip ---

$ pkgconf --libs x264
-L/usr/lib/x86_64-linux-gnu -lx264

$ pkg-config --libs x264
-lx264

This causes strange FTBFS when privately (i.e. not on a buildd) building a
multiarch package with library libfoo which is already installed (in another
version). If the linking of any shared library or executable in the package
uses another library libbar with "-L/usr/lib/x86_64-linux-gnu" in its pkg-
config Libs variable, the linker will prefer
the installed libfoo over the just built one.

pkgconf eliminates just a single system lib directory, but pkg-config
eliminates any directory in the search path for system libs. Indeed, in Debian
pkg-config is configured with /lib:/lib32:/usr/lib:/usr/lib/x86_64-linux-
gnu:/usr/lib32.



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

Kernel: Linux 3.13.6 (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 pkgconf depends on:
ii  libc6  2.18-4

pkgconf recommends no packages.

pkgconf 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