date:20131106

reassign 728782 release.debian.org
retitle 728782 nmu: libgxps2 0.2.2-2
thanks

On 05/11/13 14:22, Jenny Hopkins wrote:
 Package: libgxps2
 Version: 0.2.2-2
 Severity: important
 User: multiarch-de...@lists.alioth.debian.org
 Usertags: multiarch
 
 Packages is marked as Multi-Arch: same, but the file
 /usr/share/doc/libgxps2/changelog.Debian.gz is architecture-dependent.
  The diff between i386 and amd64 is attached.
 
 The problem can be resolved by binNMU.

Let's do that then.

Please binnmu libgxps2 0.2.2-2 on every arch to fix changelog.Debian.gz with
recent debhelper.

Emilio


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

Bug#728826: vamp-plugin-sdk: broken pkg-config file

2013-11-06 Thread Jaromír Mikeš

Hi,

thank you for reporting.

Would be some thing like this solution?

libdir=${prefix}/$(LIBDIR)

mira



2013/11/5 Benjamin Drung bdr...@debian.org

 Package: vamp-plugin-sdk
 Version: 2.5-2
 Severity: normal

 Dear Maintainer,

 vamp-hostsdk.cp and vamp-sdk.pc contain:

 libdir=${prefix}%LIBDIR%

 This leads to a wrong include directory: /usr\%LIBDIR\%

 ___
 pkg-multimedia-maintainers mailing list
 pkg-multimedia-maintain...@lists.alioth.debian.org

 http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers

Bug#727009: FTBFS on kfreebsd-i386: FAIL: test-pangocairo-threads

On 29/10/13 00:46, Emilio Pozuelo Monfort wrote:
 On 28/10/13 23:49, Steven Chamberlain wrote:
 On 28/10/13 14:33, Emilio Pozuelo Monfort wrote:
 The test is trying to create 100 threads, but pthread_create returns EAGAIN
 because it hits some limit, which makes g_thread_new() abort (as stated in 
 the
 docs, g_thread_try_new() wouldn't abort but return NULL).

 The question is, why are we hitting the limit so soon here?

 Not sure yet but this reminds me of bug #725516:
 lbzip2: unable to create a POSIX thread: Resource temporarily unavailable
 
 Indeed, looks very similar. It's also failing consistently when ran as `make
 check' but works most of the time when invoked directly.
 
 FWIW we run autoreconf at the beginning of the build so we're using latest
 automake as available in Debian (1.14 in this case).

Any news here? This is blocking pango's migration and the harfbuzz transition.

Emilio


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

Bug#727792: libindicator7 is broken

2013-11-06 Thread Alexei Sorokin


Severity: important

This little correction of deprecation fix patch makes libindicator7 
working as good as libindicator3-7.Description: Fix FTBFS due to gtk_icon_info_free () deprecated since Gtk 3.8
Author: Andrea Colangelo war...@ubuntu.com  Sorokin Alexei sor.ale...@meowr.ru
Bug-Debian: http://bugs.debian.org/713475
Last-Update: 2013-11-06

--- libindicator-0.5.0.orig/libindicator/indicator-image-helper.c
+++ libindicator-0.5.0/libindicator/indicator-image-helper.c
@@ -69,7 +69,11 @@ refresh_image (GtkImage * image)
 	GdkPixbuf * pixbuf = gdk_pixbuf_new_from_file(icon_filename, error);
 
 	if (icon_info != NULL) {
+#if GTK_MAJOR_VERSION == 2
 		gtk_icon_info_free(icon_info);
+#else
+		g_object_unref(icon_info);
+#endif
 	}
 
 	if (pixbuf == NULL) {

Bug#728775: apt-get unwarrantedly consumes input

2013-11-06 Thread Steve Cotton

On Tue, Nov 05, 2013 at 11:40 +, Zefram wrote:
 When apt-get is invoked in a way that involves actually installing a
 package, it reads any available data from standard input, regardless of
 actual need.  This breaks the usual ability, at an interactive shell,
 to type the next command while the current one is running: apt-get
 consumes input that was intended for the shell.

Hi Zefram,

It's to avoid someone typing their next command while packages are
downloading, but then that input being used as the answer to a
prompt during installation.

There is an undocumented control flag DPkg::FlushSTDIN.  It was
added for the use case of scripted responses to dpkg's prompts
(bug #63991), before debconf existed.  Also the fix added for bug
#192228 should also work for #63991's use-case.  So that flag
should possibly be removed rather than documented.

But for your use-case of an interactive shell, wouldn't it be
safer to just open another terminal?

Cheers,
Steve


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

Bug#728842: libtag1c2a: tag display messed up with mpd clients

2013-11-06 Thread Modestas Vainius

Hello,

Trečiadienis 06 Lapkritis 2013 08:43:01 rašė:
 Dear Maintainer,
 After editing tags in ncmpcpp or sonata, the tag display is messed up for
 the files edited. The tag itself remains right (reverting back to Jessie
 version of the lib gives back the correct display), but it is displayed
 with Chinese characters instead of Latin ones.

Could you attach or post a link to such a corrupted FLAC file?

-- 
Modestas Vainius mo...@debian.org

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

Bug#728838: gvfs-udisks2-volume-monitor: two random crashes (SIGSEGV)

Hi Paul,

On 06/11/13 05:17, Paul Wise wrote:
 Package: gvfs-daemons
 Version: 1.16.3-1+b2
 Severity: normal
 File: /usr/lib/gvfs/gvfs-udisks2-volume-monitor
 
 I had gvfs-udisks2-volume-monitor crash twice. I only found out about it
 because I have core dumps enabled using corekeeper so I don't know what
 I was doing at the time. I've attached the two backtraces, they are
 similar but not identical.

Looks like:

https://bugs.launchpad.net/ubuntu/+source/gvfs/+bug/1033248
https://bugzilla.redhat.com/show_bug.cgi?id=929436

And seems to happen when ejecting a device.

There's 1.18 in experimental, would be good to know if it still happens with
that version. Please install gvfs-dbg to get a better backtrace if it still
happens. If so we should forward this upstream as I couldn't find a bug report
there.

Regards,
Emilio


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

Bug#728838: gvfs-udisks2-volume-monitor: two random crashes (SIGSEGV)

2013-11-06 Thread Paul Wise

On Wed, 2013-11-06 at 10:24 +0100, Emilio Pozuelo Monfort wrote:

 There's 1.18 in experimental, would be good to know if it still
 happens with that version.

Unfortunately I can't do that, there is some sort of dependency issue
with libgoa-1.0-0b and libgoa-1.0-0 conflicting against each other but
other stuff wanting both to be installed at the same time:

The following packages will be REMOVED:
  empathy gir1.2-zpj-0.0 gnome gnome-control-center gnome-core gnome-documents 
libgoa-1.0-0 libzapojit-0.0-0

 Please install gvfs-dbg to get a better backtrace if it still happens.

Installed the one from unstable, attached new backtraces with that.

-- 
bye,
pabs

http://wiki.debian.org/PaulWise
+ gdb -batch -n -ex bt -ex 'thread apply all bt full' --core 
/var/crash/1000/3311-1000-1000-11-1383645686-chianamo--usr-lib-gvfs-gvfs-udisks2-volume-monitor.core
 /usr/lib/gvfs/gvfs-udisks2-volume-monitor

warning: core file may not match specified executable file.
[New LWP 3311]
[New LWP 3312]
[New LWP 5250]

warning: Could not load shared library symbols for linux-vdso.so.1.
Do you need set solib-search-path or set sysroot?
[Thread debugging using libthread_db enabled]
Using host libthread_db library /lib/x86_64-linux-gnu/libthread_db.so.1.
Core was generated by `/usr/lib/gvfs/gvfs-udisks2-volume-monitor'.
Program terminated with signal 11, Segmentation fault.
#0  0x00411bbc in unmount_cb (source_object=optimized out, 
res=0x8a8b40, user_data=0x8e4ba0) at gvfsudisks2mount.c:844
844 gvfsudisks2mount.c: No such file or directory.
#0  0x00411bbc in unmount_cb (source_object=optimized out, 
res=0x8a8b40, user_data=0x8e4ba0) at gvfsudisks2mount.c:844
#1  0x7f777ee9b627 in g_simple_async_result_complete (simple=0x8a8b40) at 
/tmp/buildd/glib2.0-2.36.4/./gio/gsimpleasyncresult.c:777
#2  0x7f777eef3d2d in reply_cb (connection=optimized out, res=optimized 
out, user_data=0x8a8b40) at /tmp/buildd/glib2.0-2.36.4/./gio/gdbusproxy.c:2632
#3  0x7f777ee9b627 in g_simple_async_result_complete (simple=0x8ff570) at 
/tmp/buildd/glib2.0-2.36.4/./gio/gsimpleasyncresult.c:777
#4  0x7f777eee94aa in g_dbus_connection_call_done (source=optimized out, 
result=optimized out, user_data=0x7f777401b150) at 
/tmp/buildd/glib2.0-2.36.4/./gio/gdbusconnection.c:5339
#5  0x7f777ee9b627 in g_simple_async_result_complete (simple=0x8ff490) at 
/tmp/buildd/glib2.0-2.36.4/./gio/gsimpleasyncresult.c:777
#6  0x7f777ee9b689 in complete_in_idle_cb (data=optimized out) at 
/tmp/buildd/glib2.0-2.36.4/./gio/gsimpleasyncresult.c:789
#7  0x7f777e928ea6 in g_main_dispatch (context=0x887cc0) at 
/tmp/buildd/glib2.0-2.36.4/./glib/gmain.c:3054
#8  g_main_context_dispatch (context=context@entry=0x887cc0) at 
/tmp/buildd/glib2.0-2.36.4/./glib/gmain.c:3630
#9  0x7f777e9291f8 in g_main_context_iterate (context=0x887cc0, 
block=block@entry=1, dispatch=dispatch@entry=1, self=optimized out) at 
/tmp/buildd/glib2.0-2.36.4/./glib/gmain.c:3701
#10 0x7f777e9295fa in g_main_loop_run (loop=0x887de0) at 
/tmp/buildd/glib2.0-2.36.4/./glib/gmain.c:3895
#11 0x00418dd8 in g_vfs_proxy_volume_monitor_daemon_main 
(argc=optimized out, argv=optimized out, dbus_name=optimized out, 
volume_monitor_type=8944464) at gvfsproxyvolumemonitordaemon.c:2009
#12 0x7f777e103995 in __libc_start_main (main=0x40a8a0 main, argc=1, 
ubp_av=0x74732948, init=optimized out, fini=optimized out, 
rtld_fini=optimized out, stack_end=0x74732938) at libc-start.c:260
#13 0x0040a90d in _start ()

Thread 3 (Thread 0x7f777a7d4700 (LWP 5250)):
#0  0x7f777e1bf24d in poll () at ../sysdeps/unix/syscall-template.S:81
No locals.
#1  0x7f777e929194 in g_main_context_poll (priority=2147483647, n_fds=1, 
fds=0x7f7764003890, timeout=-1, context=0x900920) at 
/tmp/buildd/glib2.0-2.36.4/./glib/gmain.c:3995
poll_func = 0x7f777e937dd0 g_poll
#2  g_main_context_iterate (context=context@entry=0x900920, 
block=block@entry=1, dispatch=dispatch@entry=1, self=optimized out) at 
/tmp/buildd/glib2.0-2.36.4/./glib/gmain.c:3696
max_priority = 2147483647
timeout = -1
some_ready = optimized out
nfds = 1
allocated_nfds = 1
fds = 0x7f7764003890
#3  0x7f777e92929c in g_main_context_iteration (context=0x900920, 
may_block=may_block@entry=1) at /tmp/buildd/glib2.0-2.36.4/./glib/gmain.c:3762
retval = optimized out
#4  0x7f777e9292e9 in glib_worker_main (data=optimized out) at 
/tmp/buildd/glib2.0-2.36.4/./glib/gmain.c:5427
No locals.
#5  0x7f777e94d1d5 in g_thread_proxy (data=0x898a30) at 
/tmp/buildd/glib2.0-2.36.4/./glib/gthread.c:798
thread = 0x898a30
#6  0x7f777e495e0e in start_thread (arg=0x7f777a7d4700) at 
pthread_create.c:311
__res = optimized out
pd = 0x7f777a7d4700
now = optimized out
unwind_buf = {cancel_jmp_buf = {{jmp_buf = {140151132866304, 
-3238383142126317586, 0, 140737294574064, 17, 140151132866304, 
3305650144742117358,

Bug#728858: mirror submission for debian.softcastdns.com

2013-11-06 Thread Konstantin

Package: mirrors
Severity: wishlist

Submission-Type: new
Site: debian.softcastdns.com
Type: leaf
Archive-architecture: ALL amd64 armel armhf hurd-i386 i386 ia64 kfreebsd-amd64 
kfreebsd-i386 mips mipsel powerpc s390x sparc 
Archive-http: /debian/
Backports-http: /debian-backports/
CDImage-http: /debian-cd/
Old-http: /debian-archive/
IPv6: no
Archive-upstream: ftp.de.debian.org
Backports-upstream: ftp.de.debian.org
CDImage-upstream: ftp.de.debian.org
Updates: push
Maintainer: Konstantin k...@gmx.net
Country: DE Germany
Location: Nurnberg
Sponsor: KRED http://gerasimenko.de/
Comment: es ist eine http-proxy und cache (1Tb)


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

Bug#608583: Bug#640206: barnowl: please stop using libnet-irc-perl

2013-11-06 Thread Damyan Ivanov

Control: retitle -1 barnowl: uses libnet-irc-perl, which is abandoned upstream
Control: tag -1 fixed-upstream
Control: severity 608583 serious

-=| Ansgar Burchardt, 03.09.2011 13:43:21 +0200 |=-
 Package: barnowl
 Version: 1.6.2-1+b2
 Severity: important
 
 As libnet-irc-perl has been unmaintained since 2004, we would like to
 remove the package from Debian before the wheezy release.  Please 
 switch to an alternative library such as libpoe-component-irc-perl.

Net::IRC dependency is removed upstream in version 1.8, released 
October 2011.

Since barnowl is the only remaining package with a hard dependency on 
libnet-irc-perl, and since there is a fix upstream, I am raising the 
severity of #608583 to make libnet-irc-perl get out of jessie. This 
will remove barnowl too, unless the package is upgraded to a newer 
upstream release.

On a side note, adding Homepage to barnowl's control file would be 
nice. The upstream project is at http://barnowl.mit.edu/ . Ditto for 
debian/watch and debian/copyright.


signature.asc
Description: Digital signature

Bug#727595: Raise severity

severity 727595 serious
thanks


Raising severity, as dependencies will be removed for ia64 and sparc.


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

Bug#718394: ITP: buck -- Facebook's build system for large Java projects

2013-11-06 Thread Sylvestre Ledru

Le 22/10/2013 14:47, Sylvestre Ledru a écrit :
 Hello

 What is the status of this ITP ? Do you need help ?
 As Thomas said, please package it under the pkg-java umbrella. :)

 Thanks,
 Sylvestre

Ping ?


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

Bug#728859: ITP: gnome-online-miners -- Crawls through your online content

2013-11-06 Thread Dennis Ruhe

Package: wnpp
Severity: wishlist
Owner: Dennis Ruhe den...@amazingsystems.nl

* Package name: gnome-online-miners
  Version : 3.10.0
  Upstream Author : Debarshi Ray debars...@gnome.org
* URL : http://www.gnome.org/
* License : GPL
  Programming Lang: C
  Description : Crawls through your online content

GNOME Online Miners provides a set of crawlers that go through
your online content and index them locally in Tracker. It has miners for
Flickr, Google, ownCloud and SkyDrive.


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

Bug#728860: lxc-clone used rsync but lxc package not depend it

2013-11-06 Thread Shell Xu

Package: lxc
Status: install ok installed
Priority: optional
Section: admin
Installed-Size: 648
Maintainer: Daniel Baumann m...@daniel-baumann.ch

Architecture: amd64
Version: 0.9.0~alpha3-2+deb8u1
Depends: libapparmor1 (= 2.6~devel), libc6 (= 2.15), libcap2 (= 2.10)
Pre-Depends: multiarch-support
Recommends: debootstrap, libcap2-bin
Conflicts: cgroup-bin

$ grep -n rsync `which lxc-clone`

237:rsync -Hax ${rootfs}_snapshot/ ${rootfs}/ || { echo $(basename
$0): copying data to new lv failed 2; false; }
264:rsync -Hax $oldroot/ $rootfs/

-- 
彼節者有間，而刀刃者無厚；以無厚入有間，恢恢乎其於游刃必有餘地矣。
blog: http://shell909090.com/blog/
about.me: http://about.me/shell909090

Bug#728838: gvfs-udisks2-volume-monitor: two random crashes (SIGSEGV)

On 06/11/13 10:40, Paul Wise wrote:
 On Wed, 2013-11-06 at 10:24 +0100, Emilio Pozuelo Monfort wrote:
 
 There's 1.18 in experimental, would be good to know if it still
 happens with that version.
 
 Unfortunately I can't do that, there is some sort of dependency issue
 with libgoa-1.0-0b and libgoa-1.0-0 conflicting against each other but
 other stuff wanting both to be installed at the same time:

Oh yeah, 1.18.2-2 was forced against the new goa, but 1.18.2-1 (from snapshot)
should be fine if you want to try it.

 The following packages will be REMOVED:
   empathy gir1.2-zpj-0.0 gnome gnome-control-center gnome-core 
 gnome-documents libgoa-1.0-0 libzapojit-0.0-0
 
 Please install gvfs-dbg to get a better backtrace if it still happens.
 
 Installed the one from unstable, attached new backtraces with that.

It's the definitely that umount bug.

Cheers,
Emilio


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

Bug#725983: pmacct: uacctd not working - compiled without ulog

2013-11-06 Thread Jamie Wilkinson

Sure!  Sorry for the oversight.


On 11 October 2013 04:02, Jan-Kaspar Muennich j...@dotplex.de wrote:

 Package: pmacct
 Version: 0.14.0-1.1
 Severity: important

 The uacct daemon does not work since pmacct was compiled without ulog
 (--enable-ulog). Could you please add this?

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

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

Bug#727253: Build-depend on autotools-dev

2013-11-06 Thread Jamie Wilkinson

Thanks for the patch.  Will apply it soon.


On 24 October 2013 06:07, Matthias Klose d...@ubuntu.com wrote:

 Package: gle
 Version: 3.1.0-7
 Severity: important
 Tags: patch
 User: debian-...@lists.debian.org
 Usertags: arm64

 Build-depend on autotools-dev, or else the package will ftbfs on arm64.
 patch at: https://patches.ubuntu.com/g/gle/gle_3.1.0-7ubuntu1.patch

Bug#728859: Packaged v3.10.0

2013-11-06 Thread Dennis Ruhe

I packaged version v3.10.0, this being the first package I have created
I have no idea what to do with it now.

I am currently waiting for my virtual box to complete installation so I
can test the package without breaking my computer.


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

Bug#728861: ardesia: Does not display UI elements and crashes

2013-11-06 Thread Michael Hanke

Package: ardesia
Version: 1.1-1
Severity: important

Hi,

Running ardesia yields a uniform gray screen with the mouse pointer
changes to the edit pen. Other than that I can perform any action.
Stopping ardesia in this state only works by Ctrl-C in a terminal, upon
which ardesia segfaults.

This is on Debian jessie + GNOME3.

Please let me know if I can contribute more information.


Thanks!


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

Kernel: Linux 3.10-3-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 ardesia depends on:
ii  libatk1.0-0 2.10.0-2
ii  libc6   2.17-93
ii  libcairo-gobject2   1.12.16-2
ii  libcairo2   1.12.16-2
ii  libgdk-pixbuf2.0-0  2.28.2-1
ii  libglib2.0-02.36.4-1
ii  libgsf-1-1141.14.28-1
ii  libgsl0ldbl 1.16+dfsg-1
ii  libgtk-3-0  3.8.4-1
ii  libpango1.0-0   1.32.5-5+b1
ii  libxml2 2.9.1+dfsg1-3
ii  vlc 2.0.8-1+b2
ii  xdg-utils   1.1.0~rc1+git20111210-7

ardesia recommends no packages.

ardesia 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#722821: qdbm link with -L/usr/lib

2013-11-06 Thread Satoru KURASHIKI

hi,

On Sat, Sep 14, 2013 at 12:32 PM, YunQiang Su wzss...@gmail.com wrote:

 This package has one or more -L/usr/lib in its build system,
 which will make it ftbfs if there is libraries under /usr/lib,
 while is not the default architecture, mips* for example.

 On mips* systems, /usr/lib is defined as place to hold O32
 libraries, and /usr/lib32 for N32, and /usr/lib64 is for N64.

 Beside the way, on the multiarch system like Debian, user may install
 libraries under /usr/lib by hand.

 Please use the default search path if you can, and please consider fix
 this.

 I will try to fix this bug, while if you can help to fix it,
 It will be very appreciative.


I'm considering to start working for qdbm multiarch support.
On the way I will have to dealt with /usr/lib issues.

Sole multiarch support doesn't help your problem?
If so, I'm glad to hear what is needed to do, or patch :-)

regards,
-- 
KURASHIKI Satoru

Bug#728862: python-oerplib: New version available (0.8.0)

2013-11-06 Thread W. Martin Borgert


Package: python-oerplib
Version: 0.7.0-1
Severity: wishlist

It has a bunch of nice new features, see:
http://bazaar.launchpad.net/~oerplib/oerplib/0.8/view/head:/CHANGES.txt


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

Bug#728823: Fails to start: Running without the SUID sandbox!

2013-11-06 Thread Sergio Fernández

For me the solution pointed by Wolfgang Walter solves the issue:

ln -s /usr/lib/chromium/chromium-sandbox /usr/lib/chromium/chrome-sandbox

-- 

Sergio Fernández ser...@wikier.org


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

Bug#727582: RM: gtk-sharp2 [ia64] -- ANAIS; ia64 support removed from Mono

According to dak, it seems these rdep source packages still have
binaries for ia64 and sparc:
 * cairo-dock-plug-ins
 * gmime
 * libappindicator
 * libgpod
 * libgwibber
 * libindicate


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

Bug#698920: fvwm: In FvwmWinList, the list shows the title names instead of the icon names

2013-11-06 Thread Arne Wichmann

begin  quotation  from Schaaf, Jonathan P (GE Healthcare) (in 
c2dddb22b0ae094db5f3ce04cb9e2f2615a20...@cinurcna02.e2k.ad.ge.com):
  Ok, doing some tests it seems that the logic of setting window/icon names 
  in fvwm is broken. 
  The behavior depends on the ability of the client  to do set 
  UTF8-properties, but it is broken in any case. Tests follow:
 
 Just on a hunch, you might want to try this version:
 
ftp://ftp.fvwm.org/pub/fvwm/version-2/fvwm-2.6.3.tar.gz
 
 A patch was added in 2.6.4 that seems really suspicious to me.  For my
 own purposes, I've been reverting the patch to event.c that relates to
 icon names because it's been causing segfaults for me.  

The problem doesn't seem to appear with this version.

cu

AW
-- 
[...] If you don't want to be restricted, don't agree to it. If you are
coerced, comply as much as you must to protect yourself, just don't support
it. Noone can free you but yourself. (crag, on Debian Planet)
Arne Wichmann (a...@linux.de)


signature.asc
Description: Digital signature

Bug#620334: fai-cd: grub-install to USB device fails

2013-11-06 Thread Jeroen Akershoek

I think he means that the grub-probe now outputs information differently.

Line 278 in /usr/sbin/fai-cd is now:
 device=$(grub-probe -tdrive $usbdir | perl -ane 'm#(/dev/\w+),#  print
$1\n')

But with -tdrive you currently get something like:
# grub-probe -tdrive
(hd2,msdos1)

With the current grub -tdevice should be used, which returns the partition
device that is mounted, like this:
# grub-probe -tdevice
/dev/sdc1

Also, in order to correctly install grub we need to use the disk-device,
not the partition. So we take off the partition number with something like
this:
 device=$(grub-probe -tdevice $usbdir | perl -ane 'm#(/dev/\D+)#  print
$1\n')

Now the 'device' variable is properly formatted for use in grub-install

Kind regards,
Jeroen

Bug#722821: qdbm link with -L/usr/lib

2013-11-06 Thread YunQiang Su

On Wed, Nov 6, 2013 at 6:19 PM, Satoru KURASHIKI lur...@gmail.com wrote:
 hi,

 On Sat, Sep 14, 2013 at 12:32 PM, YunQiang Su wzss...@gmail.com wrote:

 This package has one or more -L/usr/lib in its build system,
 which will make it ftbfs if there is libraries under /usr/lib,
 while is not the default architecture, mips* for example.

 On mips* systems, /usr/lib is defined as place to hold O32
 libraries, and /usr/lib32 for N32, and /usr/lib64 is for N64.

 Beside the way, on the multiarch system like Debian, user may install
 libraries under /usr/lib by hand.

 Please use the default search path if you can, and please consider fix
 this.

 I will try to fix this bug, while if you can help to fix it,
 It will be very appreciative.


 I'm considering to start working for qdbm multiarch support.
 On the way I will have to dealt with /usr/lib issues.

 Sole multiarch support doesn't help your problem?
 If so, I'm glad to hear what is needed to do, or patch :-)
Multiarch will fix this problem also. As the pkgconfig file will be
/usr/lib/${triple} in it instead of /usr/lib

 regards,
 --
 KURASHIKI Satoru



-- 
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#728422: [buildd-tools-devel] Bug#728422: sbuild: fails to getent group sbuild when running with init=/bin/systemd

2013-11-06 Thread Roger Leigh

On Fri, Nov 01, 2013 at 03:14:05AM +0100, Cyril Brulebois wrote:
 The last bit failed with:
 | D: Running command: schroot -d / -c 
 sid-amd64-sbuild-59d745d4-bd00-4c4d-82cb-1b21032d8205 --run-session -q -u 
 root -p -- getent group sbuild
 | /bin/sh: 1: cannot create 
 /var/lib/schroot/mount/sid-amd64-sbuild-59d745d4-bd00-4c4d-82cb-1b21032d8205/etc/group:
  Permission denied
 | E: Failed to create group sbuild
 | Failed to set up chroot
 
 Looking at the mount output, that reminded me I was running under
 systemd, so I wondered whether switching it off would help. And it
 helped indeed!
 
 I suspect there's some interference between some schroot things and
 systemd, but filing it against sbuild for now, since that's where I
 hit the bug so far.

The failure is trying to run

  getent group sbuild  ${chroot}/etc/group

However, this only works as root, and it's only used as a fallback
in the unusual case that the passwd/group databases in the chroot
are out of sync with the base system.  The real question here is
why the system databases weren't copied over during the session
setup.

I would suggest trying to run schroot without sbuild and see that
if you start a new session with

  schroot -b -n test -c sid-amd64-sbuild -v --debug=notice

and see if there is anything group-related in the output.
After this completes, is there a group file in the schroot
directory?  Does

  schroot -r -c test -- getent group sbuild

succeed or fail?

Does getent group sbuild work correctly on the base system when
systemd is running?  How about getent group?

sbuild and schroot don't really do anything which should be
affected by the init system in use.  Both just make use of
standard POSIX interfaces, and if systemd causes changes in
how these basic libc calls function, that's a bit worrying.
The schroot db copy is as simple as

  getent $db  $chroot/etc/$db

Any more information you could provide regarding the above would
be much appreciated.


Regards,
Roger

-- 
  .''`.  Roger Leigh
 : :' :  Debian GNU/Linuxhttp://people.debian.org/~rleigh/
 `. `'   schroot and sbuild  http://alioth.debian.org/projects/buildd-tools
   `-GPG Public Key  F33D 281D 470A B443 6756 147C 07B3 C8BC 4083 E800


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

Bug#727583: RM: mono [ia64] -- ANAIS; ia64 support removed from Mono

According to dak, it seems these rdep source packages still have
binaries for ia64 and sparc:
 gtk-sharp2
 gtk-sharp3
 kamailio
 mod-mono
 zeroc-ice


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

Bug#717918: Bug#717917: RM: libnss-ldap -- RoQA; orphaned, RC buggy, alternatives exist

Hi,

what's the status of libpam-ldap removal?
Should we process this or close the bug?


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

Bug#728866: samba: please package libnetapi

2013-11-06 Thread Hans Leidekker

Package: samba
Version: 2:3.6.19-1
Severity: wishlist

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

   * What led up to the situation?

 I'm implementing support for accessing remote machines in Wine on top of 
Samba's libnetapi.
 This is my request to package this library on Debian.
 
   * What exactly did you do (or not do) that was effective (or
 ineffective)?
   * What was the outcome of this action?
   * What outcome did you expect instead?

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


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

Kernel: Linux 3.10-3-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

Versions of packages samba depends on:
ii  adduser   3.113+nmu3
ii  dpkg  1.16.12
ii  libacl1   2.2.52-1
ii  libattr1  1:2.4.47-1
ii  libc6 2.17-93
ii  libcap2   1:2.22-1.2
ii  libcomerr21.42.8-1
ii  libcups2  1.6.3-1
ii  libgssapi-krb5-2  1.11.3+dfsg-3
ii  libk5crypto3  1.11.3+dfsg-3
ii  libkrb5-3 1.11.3+dfsg-3
ii  libldap-2.4-2 2.4.31-1+nmu2+b1
ii  libpam-modules1.1.3-9
ii  libpam-runtime1.1.3-9
ii  libpam0g  1.1.3-9
ii  libpopt0  1.16-7
ii  libtalloc22.1.0-1
ii  libtdb1   1.2.12-1
ii  libtevent00.9.19-1
ii  libwbclient0  2:3.6.19-1
ii  lsb-base  4.1+Debian12
ii  procps1:3.3.4-2
ii  samba-common  2:3.6.19-1
ii  sysv-rc   2.88dsf-43
ii  update-inetd  4.43
ii  zlib1g1:1.2.8.dfsg-1

Versions of packages samba recommends:
ii  logrotate  3.8.6-1
ii  tdb-tools  1.2.12-1

Versions of packages samba suggests:
pn  ctdb  none
pn  ldb-tools none
pn  openbsd-inetd | inet-superserver  none
pn  smbldap-tools none
ii  winbind   2:3.6.19-1

-- debconf information:
  samba-common/title:
  samba/run_mode: daemons
  samba/generate_smbpasswd: false


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

Bug#616180: Old GCC bug affecting postgresql error handling

2013-11-06 Thread Ian Jackson

Tom Lane writes (Re: Old GCC bug affecting postgresql error handling):
 Ian Jackson ijack...@chiark.greenend.org.uk writes:
  Alex Deiter appears to have tried to report this to gcc upstream:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29968
  However, the test program in that bugzilla report is indeed broken.
  The gcc maintainers were right to reject the bug.
 
 Hm --- it's a bit questionable.  The test execution appears to show
 that the side-effect of program abort happens before the printf call;
 but depending on how much buffering of stdout is happening, it might
 not really prove that.

As it happens in actual fact in the example program, the stdout output
is indeed buffered so the observed behaviour is exactly what one would
expect if the program had been compiled naively without any
optimisation.

However, also, undefined behaviour doesn't respect causality.  If your
program's behaviour is ever undefined, the whole behaviour is
undefined.  (C99 3.4.3.)  So even if you made stdout unbuffered, or
wrote to stderr, the same observed behaviour is permissible.

  Your version is a lot more conclusive, at least
 as far as Postgres' issue is concerned, because in our case we know
 the ereport() function won't return.

Right.

  I have tried to reproduce the original problem with a smaller test
  program (see below) than postgresql, but failed (on 32-bit sparc with
  gcc 4.4.5-8, Debian squeeze).
 
 I wonder whether the gcc folk reconsidered and fixed the problem
 somewhere between 4.1.x and 4.4.x.  I've seen them reverse course
 before on what was or wasn't a bug.

I wasn't able to do a test of the actual current postgresql with a
current Debian compiler.  The original report is on sparc64 which is a
bit difficult as I can't find any sparc64 porter box.

Ian.


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

Bug#728867: O: penguin-command

2013-11-06 Thread Karl Bartel

Package: wnpp
Severity: normal

I'm orphaning penguin-command. If I spend any time on this game, it would be
better spent fixing bugs upstream than improving the debian package.

The package is pretty low on maintenance, so feel free to adopt it.


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

Bug#728866: [Pkg-samba-maint] Bug#728866: samba: please package libnetapi

2013-11-06 Thread Jelmer Vernooij

On Wed, Nov 06, 2013 at 12:15:21PM +0100, Hans Leidekker wrote:
 Package: samba
 Version: 2:3.6.19-1
 Severity: wishlist
 
 Dear Maintainer,
 *** Please consider answering these questions, where appropriate ***
 
* What led up to the situation?
 
  I'm implementing support for accessing remote machines in Wine on top of 
 Samba's libnetapi.
  This is my request to package this library on Debian.

Please see the samba-dev package that is available in sid.

If that is not sufficient somehow, please specify what files
exactly you need.

Cheers,

Jelmer


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

Bug#728757: Apparently it is a problem I caused myself

2013-11-06 Thread Peter Allin

I have just tried making a fresh wheezy installl in a VM, and it works fine
there. So it must be something I have messed up myself. Sorry for the noise.

Bug#728868: O: black-box

2013-11-06 Thread Karl Bartel

Package: wnpp
Severity: normal

I'm orphaning black-box. If I spend any time on this game, it would be better
spent fixing bugs upstream than improving the debian package.

The package is pretty low on maintenance, so feel free to adopt it.


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

Bug#728869: gammaray FTBFS: build failed on post-compile-test on mips/mipsel

2013-11-06 Thread Dejan Latinovic

Package: gammaray
Version: 1.2.2-1
Severity: serious
Tags: jessie sid
Justification: FTBFS

In an attempt to rebuild the package on mips/mipsel, build failed on testing:

 Running tests...
 /usr/bin/ctest --force-new-ctest-process -j6
 Test project 
/build/buildd2-gammaray_1.2.2-1-mips-r9OCsw/gammaray-1.2.2/obj-mips-linux-gnu
 Start 1: connectiontest-preload
 Start 2: connectiontest-style
 Start 3: connectiontest-gdb
 Start 4: attachtest-gdb
 1/4 Test #1: connectiontest-preload ...***Failed2.43 sec
 Failed to launch injector preload
 Exit code: 1
 Error: Symbol is not marked as relocatable: qt_startup_hook
 
 2/4 Test #2: connectiontest-style .   Passed6.98 sec
 3/4 Test #3: connectiontest-gdb ...   Passed   13.83 sec
 4/4 Test #4: attachtest-gdb ...   Passed   33.19 sec
 
 75% tests passed, 1 tests failed out of 4
 
 Total Test time (real) =  33.30 sec
 
 The following tests FAILED:
 1 - connectiontest-preload (Failed)


The full build logs are available from:
https://buildd.debian.org/status/fetch.php?pkg=gammarayarch=mipsver=1.2.2-1stamp=1356200075
https://buildd.debian.org/status/fetch.php?pkg=gammarayarch=mipselver=1.2.2-1stamp=1356200317



GammaRay uses preloading to overwrite specific function calls in QtCore to
hook into its target application.

To be sure that the overwriting for qt_startup_hook will work,
test connectiontest-preload with readelf --relocs --wide checks if sybmbol
qt_startup_hook is marked as relocatable with JUMP_SLOT relocation, which
means that symbol will be resolved by dynamic linker and called at run
time through the plt.

The problem for Mips is that it has, besides the plt, another method of
calling functions from .so files, and this method doesn't need JUMP_SLOT
relocations (in fact, it doesn't need any relocations). This method uses .got
entries and lazy binding stubs. For example, if we call printf function, the
typical code is (gp register here points at the .got section):

lw t9, offset(gp)   // load in t9 function pointer from the address gp + offset
jalr t9 // call the function in t9

Initially, the memory at gp + offset will contain the address of the lazy
binding stub for printf. Lazy binding stubs look like:

lw  t9, 0(gp)
movet7,ra
li  t8,7
jalrt9

First instruction loads in t9 the address of the function _dl_runtime_resolve
from the predefined place in .got (it is located in first .got entry).
_dl_runtime_resolve is dynamic linker's function which resolves calls to
functions from .so files (printf in this case). Second and third instructions
load registers t7 and t8 with arguments that _dl_runtime_resolve needs. The key
argument here is 7 - it is dynamic symbol table index of printf, so that dynamic
linker knows which function to search for. Last instruction calls
_dl_runtime_resolve. After _dl_runtime_resolve finds printf in some .so file, it
will overwrite the .got entry for printf with found printf address, so that next
calls to printf will not go through lazy binding stub, but directly call printf.

All this doesn't need any relocations (below will be explained why). There is a
method how it can be determined whether a call to function will go through .got
and lazy binding stub.

First, Mips ABI specifies that .got is divided in two parts - local and global.
Dynamic linker only resolves symbols from the global part of the .got (that is,
only symbols from global part of the .got have lazy binding stubs. Entries from
the local part of the .got are filled with final values during static linking).
Mips ABI also specifies that the order of symbols in global part of the .got
must match the order of symbols in dynamic symbol table. In the .dynamic section
(obtained with readelf -d command), there is a Mips-specific dynamic tag
DT_MIPS_GOTSYM which gives the dynamic symbol index of the first symbol that has
entry in global part of the .got. So, the symbol with dynamic symbol index of
DT_MIPS_GOTSYM will be placed in the first entry in the global part of the .got.
The symbol with dynamic symbol index of DT_MIPS_GOTSYM+1 will be placed in the
second entry in the global part of the .got and so on.

For the previous example, lets suppose that DT_MIPS_GOTSYM is 6. Since the
dynamic symbol index of printf is 7, printf will be placed in the global part of
the .got (in the second entry of the global part of the got), and call to printf
will go through .got and lazy binding stub, and will be resolved by dynamic
linker.

From the previous explanation, it should be clear why calling functions through
.got on Mips doesn't need any relocations. Dynamic linker knows which .got entry
corresponds to which symbol, based on matching between .got and dynamic symbol
table. For the plt, on the other hand, there is no matching between the .got.plt
entry and the dynamic symbol table - function addresses in .got.plt can come in
arbitrary order. This is why every .got.plt entry

Bug#727708: tech-ctte: Decide which init system to default to in Debian.

2013-11-06 Thread Thijs Kinkhorst

On Wed, November 6, 2013 09:10, Russ Allbery wrote:
 Thijs Kinkhorst th...@debian.org writes:
 On Wed, November 6, 2013 01:16, Russ Allbery wrote:

 We'll want to look at both sides of that question, and try to
 understand how much work like that is potentially on the horizon with
 the various choices.

 Do you? In the past Debian has not shied away from making the choice
 that it considers technically (or philosophically) the most sound, not
 the one that implies the least amount of work. The choice will probably
 be made on just a few high-level factors, such as the chosen approach
 (dependency vs event based), best user experience and/or licensing.

 Well, my choice won't be made on just those few high-level factors, for
 whatever that matters.  And I seem to have one.  :)

 Technically the most sound and implying the least amount of work are not
 two unrelated factors.  Apply reductio ad absurdum: vaporware is not
 technicallly sound, regardless of what lofty design principles underlie
 it.

 We need to be realistic here about what we, as a project, can accomplish.
 The ideal init system for Debian is, almost by definition, the one we
 write ourselves from scratch to do exactly what we want it to do.  There's
 a good reason why no one has proposed that.  We have certain realistic
 limitations about what we can and can't do as a project, which in this
 space, among other things, require us to adopt an existing project rather
 than writing our ideal implementation from scratch.

I doubt that Debian writing something from scratch would not be realistic:
Debian actually has chosen to go the self-implementing route in key
infrastructures the past, for example for the installer or package
managers.

Nonetheless, that's not relevant here. There are several likely candidates
in existence, so the choice will not be to use something existing versus
implementing from scratch; the choice will be between existing projects,
and given that, the amount of work per system may differ but the
difference will not likely be that great that it's unsurmountable, as they
exist, they have active upstreams and they have successfully been used in
other distributions.

 That metric is trying to get at something that we do care about, namely is
 a particular upstream project going to be excessively buggy (poorly
 documented code implies harder to understand code implies people make
 mistakes when they change it) and can we understand it well enough to make
 whatever integration changes we need to make to it.

I do agree that it's nice to have the very best code quality available,
but in the long run, having underdocumented code is annoying and may lead
to bugs, but bugs can be fixed and documentation improved; changing the
basic architecture of the system is unlikely to be fixed. I really believe
we are going to regret it if Debian chooses the architecture it likes less
for the reason that it has more documentation.

Which system has better code documentation is not relevant. The relevant
question is whether a system has adequate documentation, regardless of the
documentation of other systems.

I think I would like it better if the choice process was split in two.
First, for each candidate system assess the supportability in Debian. Code
quality can be a factor here. Can we reasonably run this? (Given that the
two major choices have been used by several other distributions probably
qualifies them, but Debian can make its own assessment here.) Then, from
the shortlist of candidates, choose the 'best' one based on high-level but
fundamental criteria, like architecture, licensing etc.

Currently, it seems these two steps (is it supportable vs what should be
the default) are conflated and a big matrix of facts of the different
systems is built.


Cheers,
Thijs


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

Bug#728775: apt-get unwarrantedly consumes input

2013-11-06 Thread Zefram

Steve Cotton wrote:
It's to avoid someone typing their next command while packages are
downloading, but then that input being used as the answer to a
prompt during installation.

That can be used as an argument for all sorts of programs to clear stdin.
The Unix convention is that one does not.  For the purposes of this bug
report, I'm confident that the installation will not get interactive.
(I have debconf configured to non-interactive mode, which doesn't cover
all cases in which installation can get interactive, but does cover most.)

There is an undocumented control flag DPkg::FlushSTDIN.

Setting that to false in /etc/apt/apt.conf.d doesn't make any practical
difference.

Looking at the source, I do see flushing cod controlled by that
flag, but it doesn't match the behaviour that I saw through strace.
It's in pkgDPkgPM::Go() in apt-pkg/deb/dpkgpm.cc.  Further down the
same function, there's a pselect loop which does match what I saw
with strace.  It reads from stdin conditional only upon (master = 0 
!d-stdin_is_dev_null), not looking at configuration at all.  I expect
that both of these instances of stdin consumption need to be modified
for things to actually work as I want.

But for your use-case of an interactive shell, wouldn't it be
safer to just open another terminal?

Maybe; it depends on the circumstances.  (Again, it's an argument that
applies to all sorts of commands; apt-get is not a beautiful and unique
snowflake.)  Opening a fresh shell would avoid typeahead problems,
but would mean that the shells could differ in state such as current
directory, environment variables, and shell functions that I've just
written for the job at hand.  There's a risk of doing the wrong thing
simply due to failing to correctly keep two sets of shell state in my
head.  On the whole, running a command as root in the wrong directory
seems more dangerous than interpreting a command as a reply to a keep
old config file? question.

What's really optimal will depend on the individual.  It's a matter
between the human and eir shell; it is not apt-get's place to interfere
with that relationship.

-zefram


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

Bug#650747: w3m https://non-existent.example reliably segfaults on some systems

2013-11-06 Thread NOKUBI Takatsugu

Package: w3m
Version: 0.5.3-8
Followup-For: Bug #650747

It seems fixed in wheezy/sid.

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

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

Versions of packages w3m depends on:
ii  libc62.13-38
ii  libgc1c2 1:7.1-9.1
ii  libgpm2  1.20.4-6
ii  libssl1.0.0  1.0.1e-2
ii  libtinfo55.9-10
ii  zlib1g   1:1.2.7.dfsg-13

Versions of packages w3m recommends:
ii  ca-certificates  20130119

Versions of packages w3m suggests:
ii  man-db  2.6.2-1
ii  menu2.1.46
ii  migemo  20110227-7
ii  migemo-el [migemo]  20110227-7
ii  mime-support3.52-1
ii  w3m-el  1.4.4-11
ii  w3m-img 0.5.3-8

-- 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#723503: [Pkg-postgresql-public] Bug#723503: postgresql-9.3 link with -L/usr/lib

2013-11-06 Thread Peter Eisentraut

On Tue, 2013-09-17 at 18:52 +0800, YunQiang Su wrote:
 This package has one or more -L/usr/lib in its build system,
 which will make it ftbfs if there is libraries under /usr/lib,
 while is not the default architecture, mips* for example.

The occurrence of -L/usr/lib that is making your build fail is the
directory where to find the Python library, which is obtained by

python -c import distutils.sysconfig; print(' 
'.join(filter(None,distutils.sysconfig.get_config_vars('LIBDIR'

I don't know how this is supposed to work when you have libraries for
multiple architectures on the system but only one python binary.


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

Bug#388585: closed by Phillip Susi ps...@ubuntu.com (mount: vfat vs. chmod)

OK but maybe there could be more interactive warnings ...


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

Bug#320272: closed by Phillip Susi ps...@ubuntu.com (mount: -o posix,shortname=mixed working?)

OK thanks.


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

Bug#463758: closed by Phillip Susi ps...@ubuntu.com (MP3 players: can mount(1) fine, but [cs]fdisk say unknown partition table)

Well maybe fdisk etc. can now handle such devices now anyway...


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

Bug#726265: grub-editenv delete

 V'S == Vladimir 'φ-coder/phcoder' Serbinenko phco...@gmail.com writes:
 There is create, but no delete.
 
V'S Just use rm. There is no need to have such a command
OK wish the man page mentioned that.
 P.S., the info page mentioned is missing.


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

Bug#728870: ITP: mate-themes -- Official themes for the MATE desktop

2013-11-06 Thread Mike Gabriel

Package: wnpp
Severity: wishlist
Owner: Mike Gabriel mike.gabr...@das-netzwerkteam.de

* Package name: mate-themes
  Version : 1.6.1
  Upstream Author : Stefano Karapetsas stef...@karapetsas.com
* URL : http://www.mate-desktop.org/
* License : LGPL, CC-BY-SA
  Programming Lang: Artwork
  Description : Official themes for the MATE desktop

 This package contains the official desktop themes of the MATE desktop
 environment.


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

Bug#728871: fookebox: bogus secret value in config

2013-11-06 Thread Jonas Smedegaard

Package: fookebox
Version: 0.6.1-2
Severity: grave
Tags: security
Justification: user security hole

Default config installed as /etc/fookebox/config.ini contains this line:

  beaker.session.secret = somesecret

According to [Pylons documentation] that secret should be a secret,
ideally randomly generated value on production environments.


 - Jonas


[Pylons documentation]: 
http://docs.pylonsproject.org/projects/pylons-webframework/en/latest/sessions.html


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

Bug#728872: No SOVERSION in SONAME

Package: amd-opencl-icd

For some reason there is no SOVERSION in the SONAME in two libs:

$ readelf -d /usr/lib/libSlotMaximizerAg.so
[...]
 0x000e (SONAME) Library soname: [libSlotMaximizerAg.so]

$ readelf -d /usr/lib/libSlotMaximizerBe.so
[...]
 0x000e (SONAME) Library soname: [libSlotMaximizerBe.so]

I am guessing that:
1. This is an error from upstream, or
2. Those are private libs, and as such should not be found in public
directories /usr/lib

Thanks.


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

Bug#728860: lxc-clone used rsync but lxc package not depend it

2013-11-06 Thread Daniel Baumann

reopen 728860
close 728860 1.0.0~alpha2-5
thanks

sorry, that was too fast. i mixed this issue up with #721605; for this
bug, indeed, rsync should recommend rsync. this is done in version
1.0.0~alpha2-5.

thanks for reporting the bug.

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


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

Bug#728601: ampache-common uninstallable in sid

2013-11-06 Thread Charlie Smotherman

http://mentors.debian.net/debian/pool/main/a/ampache/ampache_3.6-rzb2752+dfsg-3.dsc


-- 
Charlie Smotherman
Debian Contributor
Ubuntu Developer

Bug#722548: piuparts failure

2013-11-06 Thread Charlie Smotherman

http://mentors.debian.net/debian/pool/main/a/ampache/ampache_3.6-rzb2752+dfsg-3.dsc

-- 
Charlie Smotherman
Debian Contributor
Ubuntu Developer

Bug#707681: your gvfs/gphoto2 backtrace

2013-11-06 Thread Andreas Henriksson

Hello Felipe Reyes!

Thanks for the backtrace you supplied in debian bug #707681.

It seems the crash is caused by libusb being called with invalid arguments
(dev=0x40) from libgphoto2. Unfortunately your backtrace only includes
debugging information for gvfs and not for gphoto2 (and libusb).

Could you please rebuild libgphoto2 with debugging symbols and get
another backtrace? (extra bonus points if you also include libusb
debugging symbols, but that hopefully shouldn't be needed).

To rebuild gphoto2 with debugging symbols, hopefully something like this
should get you there:

mkdir /tmp/debug-build
cd /tmp/debug-build
apt-get source libgphoto2
cd libgphoto2-*
DEB_BUILD_OPTIONS=noopt debug nostrip dpkg-buildpackage -uc -us
sudo dpkg -i ../*.deb

Then get another backtrace which hopefully includes more information.

PS. If this makes the crash go away, please drop the noopt option.

-- 
Andreas Henriksson


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

Bug#728874: [INTL:tr] Turkish debconf templates translation

2013-11-06 Thread Atila KOÇ

Package: strongswan
Version: N/A
Severity: wishlist
Tags: l10n patch

Please find attached the Turkish translation of the strongswan package.

Thanks,
Atila KOÇ

# SOME DESCRIPTIVE TITLE.
# Copyright (C) YEAR THE PACKAGE'S COPYRIGHT HOLDER
# This file is distributed under the same license as the PACKAGE package.
# Atila KOÃ k...@artielektronik.com.tr, 2012, 2013.
#
msgid
msgstr
Project-Id-Version: strongswan\n
Report-Msgid-Bugs-To: strongs...@packages.debian.org\n
POT-Creation-Date: 2013-02-07 13:28+0100\n
PO-Revision-Date: 2013-10-24 11:17+0200\n
Last-Translator: Atila KOÃ k...@artielektronik.com.tr\n
Language-Team: TÃ¼rkÃ§e debian-l10n-turk...@lists.debian.org\n
MIME-Version: 1.0\n
Content-Type: text/plain; charset=UTF-8\n
Content-Transfer-Encoding: 8bit\n
X-Generator: Poedit 1.5.4\n
Language: tr\n

#. Type: note
#. Description
#: ../strongswan-starter.templates:2001
msgid Old runlevel management superseded
msgstr Eski Ã§alÄ±Åma dÃ¼zeyi yÃ¶netimi yerine yenisi geÃ§ti

#. Type: note
#. Description
#: ../strongswan-starter.templates:2001
msgid
Previous versions of the strongSwan package gave a choice between three
different Start/Stop-Levels. Due to changes in the standard system startup
procedure, this is no longer necessary or useful. For all new installations
as well as old ones running in any of the predefined modes, sane default
levels will now be set. If you are upgrading from a previous version and
changed your strongSwan startup parameters, then please take a look at NEWS.
Debian for instructions on how to modify your setup accordingly.
msgstr
strongSwan paketinin Ã¶nceki sÃ¼rÃ¼mleri Ã¼Ã§ farklÄ± BaÅlama/Durma-Seviyesi
arasÄ±nda seÃ§im ÅansÄ± tanÄ±rdÄ±. Bu, olaÄan sistem baÅlatma yordamÄ±ndaki
deÄiÅiklikler nedeni ile artÄ±k gerekli ya da faydalÄ± deÄildir. Åimdi tÃ¼m
yeni kurulumlar ve herhangi bir Ã¶ntanÄ±mlÄ± kipte Ã§alÄ±Åan eskiler iÃ§in aynÄ±
Ã¶ntanÄ±mlÄ± seviyeler ayarlanacaktÄ±r. EÄer eski bir sÃ¼rÃ¼mÃ¼ yÃ¼kseltiyorsanÄ±z ya
da strongSwan baÅlatma deÄiÅkenlerinizi deÄiÅtirdiyseniz, kurulumunuzu nasÄ±l
uyumlandÄ±racaÄÄ±nÄ±zÄ± anlamak iÃ§in NEWS.Debian'a gÃ¶z atÄ±nÄ±z.

#. Type: boolean
#. Description
#: ../strongswan-starter.templates:3001
msgid Restart strongSwan now?
msgstr strongSwan Åimdi yeniden baÅlatÄ±lsÄ±n mÄ±?

#. Type: boolean
#. Description
#: ../strongswan-starter.templates:3001
msgid
Restarting strongSwan is recommended, since if there is a security fix, it
will not be applied until the daemon restarts. Most people expect the daemon
to restart, so this is generally a good idea. However, this might take down
existing connections and then bring them back up, so if you are using such a
strongSwan tunnel to connect for this update, restarting is not recommended.
msgstr
YapÄ±lan gÃ¼venlik iyileÅtirmesi artalan sÃ¼reci yeniden baÅlatÄ±lmadan
uygulanamayacaÄÄ±ndan, strongSwan'Ä± yeniden baÅlatmanÄ±z Ã¶nerilir. ÃoÄu kiÅi
artalan sÃ¼recinin tekrar baÅlayacaÄÄ±nÄ± dÃ¼ÅÃ¼nÃ¼r ve bu genellikle aldatÄ±cÄ±dÄ±r.
Oysa, yeniden baÅlatma, varolan baÄlantÄ±larÄ± koparÄ±p yeniden yapar ki, eÄer
bu gÃ¼ncellemeyi bir strongSwan tÃ¼neli baÄlantÄ±sÄ±nÄ± kullanarak yapÄ±yorsanÄ±z
yeniden baÅlatma Ã¶nerilmez.

#. Type: boolean
#. Description
#: ../strongswan-starter.templates:4001
#| msgid Start strongSwan's IKEv1 daemon?
msgid Start strongSwan's charon daemon?
msgstr strongSwan'Ä±n 'charon' artalan sÃ¼reci baÅlatÄ±lsÄ±n mÄ±?

#. Type: boolean
#. Description
#: ../strongswan-starter.templates:4001
#| msgid
#| The charon daemon must be running to support version 2 of the Internet
#| Key Exchange protocol.
msgid
The charon daemon must be running to support the Internet Key Exchange
protocol.
msgstr
Internet Anahtar DeÄiÅimi (IKE) protokolÃ¼nÃ¼n desteklenmesi iÃ§in 'charon'
artalan sÃ¼reci Ã§alÄ±ÅÄ±yor olmalÄ±dÄ±r.

#. Type: boolean
#. Description
#: ../strongswan-starter.templates:5001
msgid Use an X.509 certificate for this host?
msgstr Bu makine iÃ§in bir X.509 sertifikasÄ± kullanÄ±lsÄ±n mÄ±?

#. Type: boolean
#. Description
#: ../strongswan-starter.templates:5001
msgid
An X.509 certificate for this host can be automatically created or imported.
It can be used to authenticate IPsec connections to other hosts and is the
preferred way of building up secure IPsec connections. The other possibility
would be to use shared secrets (passwords that are the same on both sides of
the tunnel) for authenticating a connection, but for a larger number of
connections, key based authentication is easier to administer and more
secure.
msgstr
Bu makine iÃ§in bir X.509 sertifikasÄ± kendiliÄinden yaratÄ±labilir ya da iÃ§e
aktarÄ±labilir. Bu sertifika diÄer makinelerle IPsec baÄlantÄ±larÄ±nÄ±
yetkilendirmek iÃ§in kullanÄ±lacaktÄ±r ve bu yÃ¶ntem gÃ¼venli IPsec baÄlantÄ±larÄ±
iÃ§in yeÄlenen seÃ§enektir. BaÅka bir seÃ§enek de baÄlantÄ±yÄ± yetkilendirmek
iÃ§in paylaÅÄ±lan gizlerin (tÃ¼nelin her iki tarafÄ±nda da aynÄ± olan parolalar)

Bug#728873: No SOVERSION in SONAME

Package: mono-devel

For some reason the following shared object does not set a SOVERSION
in the SONAME:

$ readelf -d /usr/lib/libMonoPosixHelper.so
[...]
 0x000e (SONAME) Library soname: [libMonoPosixHelper.so]

This may not be a public library, and should maybe moved to a private dir.


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

Bug#726786: O: libtext-vfile-asdata-perl -- generic perl module to read and write vfile files

2013-11-06 Thread Petter Reinholdtsen


The libtext-vfile-asdata-perl package is used by libical-parser-perl,
which I use for www.nuug.no and other places, so I hope it will stay
maintained in Debian. :)

Just mentioning it in case anyone wonder if it is still useful to keep
in Debian. :)

-- 
Happy hacking
Petter Reinholdtsen


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

Bug#728682: reassign to logrotate

2013-11-06 Thread Henrique de Moraes Holschuh

reassign 728682 rsyslog
thanks

On Tue, 05 Nov 2013, Erwan David wrote:
 On Tue, Nov 05, 2013 at 08:38:57AM CET, Paul Martin p...@debian.org said:
  This does not belong on logrotate, but on the package including an
  /etc/logrotate.d/ script which contains the invoke-rc.d  rotate
  command.
  
  Please find that script and reassign this bug to the appropriate
  package.
  
  Logrotate itself does not contain any such call to invoke-rc.d.
 
 Ok, so the bug belongs to rsyslog...
 I do not know how to reassign it myself, so thanks to the person who will do 
 it.

Done.

-- 
  One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie. -- The Silicon Valley Tarot
  Henrique Holschuh


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

Bug#727708: tech-ctte: Decide which init system to default to in Debian.

2013-11-06 Thread Andreas Barth

* Thijs Kinkhorst (th...@debian.org) [131106 12:51]:
 Nonetheless, that's not relevant here. There are several likely candidates
 in existence, so the choice will not be to use something existing versus
 implementing from scratch; the choice will be between existing projects,
 and given that, the amount of work per system may differ but the
 difference will not likely be that great that it's unsurmountable, as they
 exist, they have active upstreams and they have successfully been used in
 other distributions.

I'm not sure we are all convinced about that. And the question is not
only do they have active upstreams, but also would upstream
(continue to) develop things in a direction that's also useful for
us. Taking an example (and this one is made-up, so please don't use
the flame-key on me), if systemd would start to only work with the
gnome desktop chooser this might be considered inacceptable, and
wouldn't be too helpful for us I'd expect. Same example would work
with upstart and unity. Or whatever else.


 I do agree that it's nice to have the very best code quality available,
 but in the long run, having underdocumented code is annoying and may lead
 to bugs, but bugs can be fixed and documentation improved; changing the
 basic architecture of the system is unlikely to be fixed. I really believe
 we are going to regret it if Debian chooses the architecture it likes less
 for the reason that it has more documentation.

In the end (at least from my perspective) we need to choose on a set
of advantages and disadvantages. There are different sets available
(or at least there is no consensus in Debian at large that only one of
them works).

First of all, we need to check which ones would be working at all. If
we notice that one of them won't allow us to properly release jessie,
I think we don't need to check if that architecture might be a bit
nicer. Also, if we notice that one architecture is unbearable broken,
the same applies. If we however notice that a set might only work if
Debian spends quite some effort, and we also notice that there are
enough people in Debian willing to do the work - well, that returns
this set in the group of sets we could choose from.

Of course it still could happen that after this pre-check we end up
with examples where we say no, really not because and we have to
re-evaluate what other optins we have. But also we're not there yet.


Andi


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

Bug#728875: Keep kwwidgets in debian ?

Package: kwwidgets
Severity: important

Since 3D Slicer is only available in squeeze:

http://packages.debian.org/squeeze/slicer

should we still keep kwwidgets in debian ?


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

Bug#728866: [Pkg-samba-maint] Bug#728866: samba: please package libnetapi

2013-11-06 Thread Hans Leidekker

On Wed, 2013-11-06 at 12:36 +0100, Jelmer Vernooij wrote:
 On Wed, Nov 06, 2013 at 12:15:21PM +0100, Hans Leidekker wrote:
  Package: samba
  Version: 2:3.6.19-1
  Severity: wishlist
  
  Dear Maintainer,
  *** Please consider answering these questions, where appropriate ***
  
 * What led up to the situation?
  
   I'm implementing support for accessing remote machines in Wine on top 
  of Samba's libnetapi.
   This is my request to package this library on Debian.
 
 Please see the samba-dev package that is available in sid.
 
 If that is not sufficient somehow, please specify what files
 exactly you need.

Is see libnetapi.so is included in Samba 4 on sid. Any chance this can be
back-ported to a 3.6.x release?


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

Bug#728875: Keep kwwidgets in debian ?

2013-11-06 Thread Dominique Belhachemi

Isn't it a dependency for volview?



On Wed, Nov 6, 2013 at 7:38 AM, Mathieu Malaterre ma...@debian.org wrote:

 Package: kwwidgets
 Severity: important

 Since 3D Slicer is only available in squeeze:

 http://packages.debian.org/squeeze/slicer

 should we still keep kwwidgets in debian ?

Bug#728876: qemu: smbd forked by qemu uses global directory /var/run/samba/ncalrpc

2013-11-06 Thread Michael Büsch

Package: qemu
Version: 1.6.0+dfsg-2
Severity: normal
Tags: patch

The smbd forked by qemu still uses the default ncalrpc directory
in /var/run/samba. This may lead to problems, if the directory
does not exist (for example if /var/run is a tmpfs and the host
smbd was not started).

This leads to the following error message from samba
and an unworkable smbd:
Failed to create pipe directory /var/run/samba/ncalrpc - No such file
or directory

The attached patch fixes this by pointing smbd to /tmp/qemu-smb.%d.%d/ncalrpc
as ncalrpc directory.
Smbd will create the actual ncalrpc subdirectory on its own.

Using a private directory also avoids possible clashes with the system-smbd.



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

Kernel: Linux 3.11-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 qemu depends on:
ii  qemu-system  1.6.0+dfsg-2
ii  qemu-user1.6.0+dfsg-2
ii  qemu-utils   1.6.0+dfsg-2

qemu recommends no packages.

Versions of packages qemu suggests:
pn  qemu-user-static  none

-- no debconf information
From: Michael Buesch m...@bues.ch
Subject: [PATCH] slirp/smb: Move ncalrpc directory to tmp

The smbd forked by qemu still uses the default ncalrpc directory
in /var/run/samba. This may lead to problems, if /var/run/samba
does not exist (for example if /var/run is a tmpfs and the host
smbd was not started).

This leads to the following error message from samba
and an unworkable smbd:
	Failed to create pipe directory /var/run/samba/ncalrpc - No such file or directory

Fix this by pointing smbd to /tmp/qemu-smb.%d.%d/ncalrpc as ncalrpc directory.
Smbd will create the actual ncalrpc subdirectory on its own.

Signed-off-by: Michael Buesch m...@bues.ch

---

Index: qemu-1.6.0+dfsg/net/slirp.c
===
--- qemu-1.6.0+dfsg.orig/net/slirp.c
+++ qemu-1.6.0+dfsg/net/slirp.c
@@ -527,6 +527,7 @@ static int slirp_smb(SlirpState* s, cons
 pid directory=%s\n
 lock directory=%s\n
 state directory=%s\n
+ncalrpc dir=%s/ncalrpc\n
 log file=%s/log.smbd\n
 smb passwd file=%s/smbpasswd\n
 security = user\n
@@ -539,6 +540,7 @@ static int slirp_smb(SlirpState* s, cons
 s-smb_dir,
 s-smb_dir,
 s-smb_dir,
+s-smb_dir,
 s-smb_dir,
 s-smb_dir,
 s-smb_dir,

Bug#728846: chromium: FATAL:browser_main_loop.cc(160)

2013-11-06 Thread Ben Whyall

Package: chromium
Version: 30.0.1599.101-2
Followup-For: Bug #728846

Dear Maintainer,

I am getting the same error whether starting the app from command line or 
fluxbox menu.

Ben


-- 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.11-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 chromium depends on:
ii  chromium-inspector   30.0.1599.101-2
ii  gconf-service3.2.6-1
ii  libasound2   1.0.27.2-3
ii  libatk1.0-0  2.10.0-2
ii  libc62.17-93
ii  libcairo21.12.16-2
ii  libcups2 1.6.3-1
ii  libdbus-1-3  1.6.18-1
ii  libexpat12.1.0-4
ii  libfontconfig1   2.11.0-1
ii  libfreetype6 2.4.9-1.1
ii  libgcc1  1:4.8.2-1
ii  libgconf-2-4 3.2.6-1
ii  libgcrypt11  1.5.3-2
ii  libgdk-pixbuf2.0-0   2.28.2-1
ii  libglib2.0-0 2.36.4-1
ii  libgnome-keyring03.8.0-2
ii  libgtk2.0-0  2.24.22-1
ii  libjpeg8 8d-1
ii  libnspr4 2:4.10.1-1
ii  libnss3  2:3.15.2-1
ii  libnss3-1d   2:3.15.2-1
ii  libpango-1.0-0   1.36.0-1
ii  libpangocairo-1.0-0  1.36.0-1
ii  libspeechd2  0.7.1-6.2
ii  libstdc++6   4.8.2-1
ii  libudev1 204-5
ii  libx11-6 2:1.6.2-1
ii  libxcomposite1   1:0.4.4-1
ii  libxdamage1  1:1.1.4-1
ii  libxext6 2:1.3.2-1
ii  libxfixes3   1:5.0.1-1
ii  libxml2  2.9.1+dfsg1-3
ii  libxrender1  1:0.9.8-1
ii  libxslt1.1   1.1.28-2
ii  libxss1  1:1.2.2-1
ii  xdg-utils1.1.0~rc1+git20111210-7

chromium recommends no packages.

Versions of packages chromium suggests:
pn  chromium-l10n  none

-- no debconf information


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

Bug#728866: [Pkg-samba-maint] Bug#728866: samba: please package libnetapi

2013-11-06 Thread Jelmer Vernooij

On Wed, Nov 06, 2013 at 01:49:14PM +0100, Hans Leidekker wrote:
 On Wed, 2013-11-06 at 12:36 +0100, Jelmer Vernooij wrote:
  On Wed, Nov 06, 2013 at 12:15:21PM +0100, Hans Leidekker wrote:
   Package: samba
   Version: 2:3.6.19-1
   Severity: wishlist
   
   Dear Maintainer,
   *** Please consider answering these questions, where appropriate ***
   
  * What led up to the situation?
   
I'm implementing support for accessing remote machines in Wine on 
   top of Samba's libnetapi.
This is my request to package this library on Debian.
  
  Please see the samba-dev package that is available in sid.
  
  If that is not sufficient somehow, please specify what files
  exactly you need.
 
 Is see libnetapi.so is included in Samba 4 on sid. Any chance this can be
 back-ported to a 3.6.x release?

No, a backport to 3.6.x is not likely. 4.x will soon be available in testing
as well as sid.

This is not a change that would be appropriate for backporting into
a stable Debian release (e.g. wheezy).

Cheers,

Jelmer


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

Bug#728877: weboob: comparoob v0.g with backend prixcarburants triggers an error _change_location

2013-11-06 Thread Carl Chenet

Package: weboob
Version: 0.g-1
Severity: important

Hi,

comparoob v0.g with backend prixcarburants triggers an error _change_location 
as displayed below:

comparoob prices
2013-11-06 
11:57:40,621:WARNING:backend.prixcarburants.browser:browser.py:700:_change_location
 There isn't any page corresponding to URL 
http://www.prix-carburants.economie.gouv.fr/
Debug data will be saved in this directory: /tmp/weboob_session_xden_v
2013-11-06 
11:57:40,660:WARNING:backend.prixcarburants.browser:browser.py:350:save_response
 Response saved to /tmp/weboob_session_xden_v/0.html
Bug(prixcarburants): 
=== [  0%] Getting http://updates.weboob.org/0.g/main/
Use logging debug option to print backtraces.
comparoob

Regards,
Carl Chenet

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

Kernel: Linux 3.2.0-4-amd64 (SMP w/2 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 weboob depends on:
ii  python  2.7.3-4
ii  python-html2text3.200.3-2
ii  python-prettytable  0.7.2-2
ii  python-weboob-core  0.g-1

weboob recommends no packages.

weboob 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#728878: RM: ttf-wqy-zenhei -- RoQA; superseded by fonts-wqy-zenhei

Package: ftp.debian.org
User: ftp.debian@packages.debian.org
Usertags: remove


As per subject.


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

Bug#728882: RFP: wdb -- An improbable python web debugger through WebSockets

2013-11-06 Thread Michael Fladischer

Package: wnpp
Severity: wishlist

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

* Package name: wdb
  Version : 1.1.0
  Upstream Author : Florian Mounier florian.moun...@kozea.fr
* URL : https://github.com/Kozea/wdb
* License : GPL
  Programming Lang: Python
  Description : An improbable python web debugger through WebSockets

wdb is a full featured web debugger based on a client-server architecture.

The wdb server which is responsible of managing debugging instances along with
browser connections (through websockets) is based on Tornado. The wdb clients
allow step by step debugging, in-program python code execution, code edition
(based on CodeMirror) setting breakpoints...

Due to this architecture, all of this is fully compatible with multithread and
multiprocess programs.

wdb works with python 2 (2.6, 2.7), python 3 (3.2, 3.3, 3.4α) and pypy. Even
better, it is possible to debug a python 2 program with a wdb server running on
python 3 and vice-versa or debug a program running on a computer with a
debugging server running on another computer inside a web page on a third
computer!

In other words it's a very enhanced version of pdb directly in your browser with
nice features.

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

iQIcBAEBCgAGBQJSekGpAAoJEGlMre9Rx7W2wc4P/jALip6WZV5m7px1W1IFsdEy
5M9N0N2GBcjfxRVvD0Hy7qBdwv+/nN0stqawuh4tgz08RI5nL70X72AL9Su7OjR8
DHVlsdMDJ1pT+OZjDWJyqk4B1giHYzllt9VXaOmUALhYrLLaCkrO5EN+CllCvrm2
rFyGwm5OVAe5FQuT34+VilttQO0OuEhPmyyaoCLfxPjAi3BAXff0kr+hRyI3NSZG
NUEbDK7nlkIXa/e9FWHRVc5HTtQKWeGMJcjlL8yWl0L26e4UJ+9qh9vLWuGy3217
dzUuuFn2xBSr+Dt58bCBtNB+r9bHvjcZUMpU6qQx2enxnN/3+LPyVfRnhUYy41Lx
mCM6ipxT6w6uDckaGrHx1Uf4rqJYQDbhGD3IkA0q+zKZWXuejYoN5XhjYE9jSk1l
3u5efzKtQ160HyQaWduMS79qt33KPVLIlbQsk6iucmK3/CYTOldSD+jVEx1ciyZh
Lvr4LxlZEjWhooqFMeAV8sPVMHWZsXzflCp6sEvRwhrdTYXmlh5jXHH5uRLluPEC
nEZyeUpfe0n/40ff4kBAr8Of44sIXXOgapYAhUcTvjT4FZILOBN1Hu8GUdSZHKzd
gqEzhkzan+bvDYmUJI3Vaqt+e4hmmDNrgI83DUn181ZpwT5cjbw+D6pKkAbiz637
WsQaQOzKbjrQXJsl8jSq
=S31I
-END PGP SIGNATURE-


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

Bug#728881: RM: automake1.13 -- RoQA; superseded by automake1.14

Package: ftp.debian.org
User: ftp.debian@packages.debian.org
Usertags: remove


As per subject.


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

Bug#728879: RM: libfusioninventory-agent-task-deploy-perl -- RoQA; superseded by fusioninventory-agent

Package: ftp.debian.org
User: ftp.debian@packages.debian.org
Usertags: remove


As per subject, from both unstable and experimental.


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

Bug#728880: RM: libfusioninventory-agent-task-esx-perl -- RoQA; superseded by fusioninventory-agent

Package: ftp.debian.org
User: ftp.debian@packages.debian.org
Usertags: remove


As per subject, from both unstable and experimental.


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

Bug#728884: wine-unstable: FTBFS due to missing install files (not generated)

2013-11-06 Thread Marc Dequènes (Duck)


Source: wine-unstable
Version: 1.5.31-1
Severity: important


Coin,

While trying to build this version from git i ran into the following error:
…
install -d debian/wine32-dev-unstable/usr/share/doc/libwine-dev
cp -a ./debian/README.winedump
debian/wine32-dev-unstable/usr/share/doc/libwine-dev/
dh_install: cannot run debian/libwine-dev-unstable.install: Permission denied
make[1]: *** [override_dh_install] Error 13
…

I applied the attached patch to solve this problem.

Regards.

--
Marc Dequènes (Duck)

diff --git a/debian/rules b/debian/rules
index 06bc40f..ce556b2 100755
--- a/debian/rules
+++ b/debian/rules
@@ -17,6 +17,7 @@ CONFLAGS=--without-hal \
 
 INSTALLS=$(shell ls debian/*-common | sed s/-common// | sed s/\\./$(VERSUFFIX)\\./)
 INSTALLS+=$(shell ls debian/wine*.install-common | sed s/\\.install-common/$(VERSUFFIX)\\.postinst/)
+INSTALLS+=$(shell ls debian/libwine*.install-common | sed s/\\.install-common/$(VERSUFFIX)\\.postinst/)
 INSTALLS+=debian/substvars
 
 # 32-bit parameters


pgprH0lBNj86g.pgp
Description: PGP Digital Signature

Bug#728836: evolution: imapx messages vanish

2013-11-06 Thread Brent S. Elmer Ph.D.

The gnome upstream bug report I filed is 711549.

On Tue, 2013-11-05 at 22:37 -0500, Brent wrote:
 Package: evolution
 Version: 3.8.5-2
 Severity: important
 
 I have evolution set up to use Imapx.  Starting this week, Evolution does not
 show all messages in my Imap Inbox and then the ones that are there go away.
 
 Steps:
 1. Start evolution
 The Inbox will show 0 messages.  After a while it will show the oldest 
 500,
 then 1000, then 1507, then 1666.  There are a few more messages on the server
 that are never shown.  The 1666 messages are as of up to 5 days ago.
 2. Click on another of the Imap folders Sent for example.
 All of the messages in sent will be shown.
 3.  Click on the Inbox again.
  The 1666 messages that were there will go away and they will be reloaded
 again 500, then 1000, then 1507 then 1666.  But still not show them all.
 4.  Click on Send and Receive or just wait until  the automatic refresh
 happens.
  The 1666 messages will go away and then be reloaded the same as before 
 and
 still not load all of them.
 
 This loading and unloading will just continue forever until evolution is shut
 down.
 
 When I run with CAMAL_DEBUG=all I see this in the log which looks suspicious:
 
 [imapx:B] token '*'
 [imapx:B] got untagged response
 [imapx:B] token TOKEN '1667'
 [imapx:B] token TOKEN 'FETCH'
 [imapx:B] Have token 'FETCH' id 1667
 [imapx:B] token '('
 [imapx:B] token TOKEN 'UID'
 [imapx:B] token TOKEN '31456101'
 [imapx:B] token TOKEN 'RFC822.SIZE'
 [imapx:B] token TOKEN '12769'
 [imapx:B] token TOKEN 'RFC822.HEADER'
 [imapx:B] token '*'
 [imapx:B] token TOKEN 'NO'
 [imapx:E] Scanning from start in INBOX
 [imapx:B] adding command, format = 'UID FETCH %s:* (UID FLAGS)'
 [imapx:B] got string '1'
 [imapx:B] completing command buffer is [25] 'UID FETCH 1:* (UID FLAGS)'
 [imapx:B] enqueue job 'UID FETCH 1:* (UID FLAGS)'
 [imapx:B] refuse to queue job on disconnected server
 [imapx:B] Message 20975073 vanished
 [imapx:B] Message 21063871 vanished
 [imapx:B] Message 21098033 vanished
 [imapx:B] Message 21104017 vanished
 [imapx:B] Message 21121092 vanished
 [imapx:B] Message 21121181 vanished
 [imapx:B] Message 21139065 vanished
 
 [imapx:B] Message 31456061 vanished
 [imapx:B] Message 31456062 vanished
 [imapx:B] Message 31456100 vanished
 0xb8687020: 0 0 0 | 99 1666 1666
 0xb8687020: 0 0 0 | 99 1665 1665
 0xb8687020: 0 0 0 | 99 1665 1665
 0xb8687020: 0 0 0 | 99 1664 1664
 0xb8687020: 0 0 0 | 99 1664 1664
 0xb8687020: 0 0 0 | 99 1663 1663
 0xb8687020: -1 0 0 | 99 1663 1663
 0xb8687020: -1 0 0 | 98 1662 1662
 
 0xb8687020: 0 0 0 | 0 5 5
 0xb8687020: 0 0 0 | 0 5 5
 0xb8687020: 0 0 0 | 0 4 4
 0xb8687020: 0 0 0 | 0 4 4
 0xb8687020: 0 0 0 | 0 3 3
 0xb8687020: 0 0 0 | 0 3 3
 0xb8687020: 0 0 0 | 0 2 2
 0xb8687020: 0 0 0 | 0 2 2
 0xb8687020: 0 0 0 | 0 1 1
 0xb8687020: 0 0 0 | 0 1 1
 0xb8687020: 0 0 0 | 0 0 0
 
 
 
 -- System Information:
 Debian Release: jessie/sid
   APT prefers testing
   APT policy: (500, 'testing')
 Architecture: i386 (i686)
 
 Kernel: Linux 3.11.5.131027 (PREEMPT)
 Locale: LANG=en_US, LC_CTYPE=en_US (charmap=ISO-8859-1)
 Shell: /bin/sh linked to /bin/bash
 
 Versions of packages evolution depends on:
 ii  dbus   1.6.16-1
 ii  debconf [debconf-2.0]  1.5.51
 ii  evolution-common   3.8.5-2
 ii  evolution-data-server  3.8.5-2
 ii  gnome-icon-theme   3.10.0-1
 ii  libatk1.0-02.10.0-2
 ii  libc6  2.17-93
 ii  libcamel-1.2-433.8.5-2
 ii  libecal-1.2-15 3.8.5-2
 ii  libedataserver-1.2-17  3.8.5-2
 ii  libevolution   3.8.5-2
 ii  libglib2.0-0   2.36.4-1
 ii  libgtk-3-0 3.8.4-1
 ii  libical0   0.48-2
 ii  libnotify4 0.7.6-1
 ii  libsoup2.4-1   2.44.1-1
 ii  libwebkitgtk-3.0-0 2.2.0-2
 ii  libxml22.9.1+dfsg1-3
 ii  psmisc 22.20-1
 
 Versions of packages evolution recommends:
 pn  evolution-plugins  none
 ii  spamassassin   3.3.2-7
 ii  yelp   3.10.1-1
 
 Versions of packages evolution suggests:
 pn  evolution-ews   none
 pn  evolution-plugins-experimental  none
 ii  gnupg   1.4.15-1.1
 ii  network-manager 0.9.8.0-5
 
 -- debconf information:
   evolution/kill_processes:
   evolution/needs_shutdown:


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

Bug#570709: packaging hhvm

2013-11-06 Thread GCS

On Tue, Nov 5, 2013 at 11:26 PM, Paul Tarjan p...@fb.com wrote:
Can Facebook do the fork then?

 Sure. How do you want us to fork it? Our current method is pinning to a
 tag in their branch and a .patch file.
 You have access to upstream source VCS? If not, an own Git repository
under the hood of GitHub would be nice. It has the advantage that
users may report bugs directly to FB.
But let me rewind first. You can create a basic Debian chroot environment with:
debootstrap --arch selected_arch sid /place/the/chroot/dir/here/
http://http.debian.net/debian/
Where selected_arch can be i386 or amd64 (or any architecture FB may use).
Then download, build and install my patched libevent 1.4.x to that
chroot environment.
The following build dependencies are identified for HHVM 2.0:
cmake
binutils-dev
libevent-dev
libreadline-dev
libedit-dev
libncurses5-dev
libbz2-dev
libxml2-dev
libmemcached-dev
libicu-dev
libgd-dev
libcap-dev
libmcrypt-dev
libcurl4-gnutls-dev
libtbb-dev
libc-client2007e-dev
libpcre3-dev
libinotifytools0-dev
libmysqld-dev
libboost1.54-dev
libboost-system1.54-dev
libboost-program-options1.54-dev
libboost-filesystem1.54-dev
libboost-regex1.54-dev
libgoogle-glog-dev
libelf-dev
libdwarf-dev
libonig-dev

 We haven¹t put the effort into any other event library. Our web server is
 already a pretty small proportion of our request time so inventing time in
 it is less impactful than HHVM optimizations.
 Still, I've read somewhere that FB has its own C event library.

 Yes, at some point we will switch our server to us it and open source it.
 No ETA on that project though and I¹d rather not gate the packaging of
 this on it.
 Sure, no problem with this.

 My main problem is getting the compile to be automatic and clean up
 correctly. Starting from your working copy would help me understand the
 correct way to do it. I was originally following [4] but then I was told
 it was outdated so I¹m fighting through another version.

 [4] https://github.com/facebook/hhvm/wiki/Build-Packages-for-Debian
 Yes, that page is highly outdated. I think Standards-Version 3.9.2 is
obsoloted now (the current one is 3.9.5) and that page uses 3.8.1!
Debhelper level should be 9 and not 7, debian/rules may use the short
debhelper format. Last but not least that wiki forces HHVM to be amd64
only. Any reason to do that? Any known problem to run HHVM on
kfreebsd-*, mips{,el}, sparc or any other archs that Debian supports?
To answer your question, the proper package build is using pbuilder or
sbuild (I prefer the former). But until I can't build HHVM by hand, I
don't want to put time into packaging. I've just realized that HHVM
embeds other codes under hphp/third_party/ , even folly which is an
other FB FOSS software and should be packaged separately. Especially
that now (for me) building HHVM fails with:
Linking CXX executable gen-class-map
CMakeFiles/gen-class-map.dir/gen-class-map.cpp.o: In function
`folly::TypeError::TypeError(std::string const,
folly::dynamic::Type)':
gen-class-map.cpp:(.text._ZN5folly9TypeErrorC2ERKSsNS_7dynamic4TypeE[_ZN5folly9TypeErrorC5ERKSsNS_7dynamic4TypeE]+0x2a):
undefined reference to
`folly::dynamic::TypeInfostd::vectorfolly::dynamic,
std::allocatorfolly::dynamic  ::name'
[...and so on...].

But the embedded folly was compiled normally (the problem can be that
it's a static library but gen-class-map linking may look for a dynamic
one):
Linking CXX static library ../../../bin/libfolly.a
[  3%] Built target folly

This further emphasize that folly[1] should be packaged separately.
System libsqlite3-dev should be used as well, instead of embedding it
and so on. An other library which is in my hand in Debian and some
extra compilation options may be discussed if needed.

Regards,
Laszlo/GCS
[1] https://github.com/facebook/folly


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

Bug#728885: publican: Publican fails to start

2013-11-06 Thread Petr Vanek

Package: publican
Version: 3.2.1-2
Severity: important
Tags: upstream

Publican fails to run. Last document i as able to sucesfully build was on Oct 
2nd.

Error message:

publican create --name New_Book

No such file or directory at /usr/lib/perl5/XML/Parser/Expat.pm line 470.
 at line 123, column 0, byte 4432
Handler couldn't resolve external entity at line 123, column 0, byte 4432
error in processing external entity reference at line 123, column 0, byte 4432
error in processing external entity reference at line 3, column 1, byte 163 at 
/usr/lib/perl5/XML/Parser.pm line 187.



-- 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.12-rc7-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 publican depends on:
ii  docbook-xml  4.5-7.2
ii  docbook-xsl  1.78.1+dfsg-1
ii  fop  1:1.1.dfsg-2
ii  gettext  0.18.3.1-1
ii  libarchive-zip-perl  1.30-7
ii  libconfig-simple-perl4.59-6
ii  libdatetime-format-dateparse-perl0.05-1
ii  libdatetime-perl 2:1.03-1+b1
ii  libdbd-sqlite3-perl  1.40-2
ii  libdbi-perl  1.630-1
ii  libfile-copy-recursive-perl  0.38-1
ii  libfile-find-rule-perl   0.33-1
ii  libfile-homedir-perl 1.00-1
ii  libfile-inplace-perl 0.20-1
ii  libfile-pushd-perl   1.005-1
ii  libfile-which-perl   1.09-1
ii  libhtml-format-perl  2.11-1
ii  libhtml-formattext-withlinks-andtables-perl  0.02-1
ii  libhtml-formattext-withlinks-perl0.14-1
ii  libhtml-template-perl2.95-1
ii  libhtml-tree-perl5.03-1
ii  libimage-size-perl   3.232-1
ii  libio-string-perl1.08-2
ii  liblist-moreutils-perl   0.33-1+b2
ii  liblocale-maketext-gettext-perl  1.28-1
ii  liblocale-po-perl0.23-1
ii  libmakefile-parser-perl  0.215-2
ii  librsvg2-bin 2.40.0-1
ii  libsort-versions-perl1.5-4
ii  libstring-similarity-perl1.04-1+b1
ii  libsyntax-highlight-engine-kate-perl 0.08+dfsg-1
ii  libtemplate-perl 2.24-1.1+b1
ii  libtext-csv-xs-perl  1.01-1+b1
ii  libxml-libxml-perl   2.0106+dfsg-1
ii  libxml-libxslt-perl  1.81-1+b1
ii  libxml-simple-perl   2.20-1
ii  libxml-treebuilder-perl  5.1-1
ii  perl 5.18.1-4
ii  perlmagick   8:6.7.7.10-6

publican recommends no packages.

publican 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#707681: gvfs-backends: backtrace with debugging symbols

2013-11-06 Thread Felipe Reyes

Package: gvfs-backends
Version: 1.16.3-1+b2
Followup-For: Bug #707681

Hi Andreas,

Here is the full backtrace using a recompiled version of libgphoto2 with
debugging symbols, let me know if there is something else I can do.

(gdb) thread apply all bt full
Thread 3 (Thread 0x7489b700 (LWP 16736)):
#0  0x769ab24d in poll () at ../sysdeps/unix/syscall-template.S:81
No locals.
#1  0x74abc6f8 in poll (__timeout=-1, __nfds=2, __fds=0x7489adc0) 
at /usr/include/x86_64-linux-gnu/bits/poll2.h:46
No locals.
#2  linux_udev_event_thread_main (arg=optimized out) at 
../../libusb/os/linux_udev.c:175
dummy = 0 '\000'
r = optimized out
udev_dev = optimized out
fds = {{fd = 10, events = 1, revents = 0}, {fd = 9, events = 1, revents 
= 0}}
__FUNCTION__ = linux_udev_event_thread_main
#3  0x76c81e0e in start_thread (arg=0x7489b700) at 
pthread_create.c:311
__res = optimized out
pd = 0x7489b700
now = optimized out
unwind_buf = {cancel_jmp_buf = {{jmp_buf = {140737296054016, 
-5096703996898259577, 1, 140737333734624, 16, 140737296054016, 
5096728583908412807, 5096723649524583815}, mask_was_saved = 
0}}, priv = {pad = {0x0, 0x0, 0x0, 0x0}, data = {prev = 0x0, 
  cleanup = 0x0, canceltype = 0}}}
not_first_call = 0
pagesize_m1 = optimized out
sp = optimized out
freesize = optimized out
__PRETTY_FUNCTION__ = start_thread
#4  0x769b69ed in clone () at 
../sysdeps/unix/sysv/linux/x86_64/clone.S:113
No locals.

Thread 1 (Thread 0x77fd0800 (LWP 16731)):
#0  libusb_get_bus_number (dev=0x3a30303a30303030) at ../../libusb/core.c:741
No locals.
#1  0x74cc81c7 in gp_port_usb_find_device_lib (port=0x6375a0, 
idvendor=1193, idproduct=12526) at libusb1.c:788
ret = 979530613
config = -1
interface = -1
confdesc = 0x3930302c313030
altsetting = -1
s = 0x6375c3 :001,009
d = 3
busnr = 1
devnr = 9
#2  0x7794f739 in gp_port_usb_find_device (port=0x6375a0, 
idvendor=1193, idproduct=12526) at gphoto2-port.c:808
r = -52
#3  0x77b5b215 in gp_abilities_list_detect_usb (list=0x636fa0, 
ability=0x7fffaf48, port=0x6375a0) at gphoto2-abilities-list.c:348
v = 1193
p = 12526
c = 0
s = 0
i = 134
count = 1451
res = -52
#4  0x77b5b5ab in gp_abilities_list_detect (list=0x636fa0, 
info_list=0x62a220, l=0x73e9a010, context=0x63d030)
at gphoto2-abilities-list.c:442
ability = -1
res = -52
info = {type = GP_PORT_USB, 
  name = Universal Serial Bus, '\000' repeats 32 times, 
\270\216c\000\000\000\000\000\257\001\235, incomplete sequence \303, 
  path = usb:001,009\000\000\000\001\000\001\000\001\000 
\266\377\377\377\177\000\000\377\377\377\377\000\000\000\000\340\023d\000\000\000\000\000pV\314\364\377\177\000\000\060\213c\000\000\000\000\000P\263\377\377,
 
  library_filename = 
/usr/lib/x86_64-linux-gnu/libgphoto2_port/0.8.0/usb1\000sc, '\000' repeats 
13 times, 
\220\264\377\377\377\177\000\000\002\000\000\000\000\000\000\000\230\n\220\366\377\177\000\000\001\000\000\000\000\000\000\000\000\314\377\367\377\177\000\000\360\320\377\367\377\177\000\000`\320\377\367\377\177\000\000\000p\375\367\377\177\000\000̳l\366\377\177\000\000P\264\377\377\377\177\000\000\234Ӟ\366\377\177\000\000\002\000\000\000\377\177,
 '\000' repeats 14 times, \001\000\000\000 
\344\243\366\377\177\000\000\000\000\000\000\000\000\000\000@F\307\366\002, 
'\000' repeats 11 times...}
port = 0x6375a0
i = 6
info_count = 8
#5  0x77b5f8b0 in gp_camera_init (camera=0x63d0c0, context=0x63d030) at 
gphoto2-camera.c:692
m = 32767
info = {type = GP_PORT_NONE, name = '\000' repeats 63 times, path = 
'\000' repeats 63 times, 
  library_filename = '\000' repeats 308 times...}
list = 0x73e9a010
al = 0x636fa0
pinfo = {type = GP_PORT_USB, 
  name = Universal Serial Bus, '\000' repeats 32 times, 
\070Wc\000\000\000\000\000\257\001\235, incomplete sequence \303, 
  path = 
usb:001,009\000\000\000\000\000^ser`\323\377\377\377\177\000\000\377\377\377\377\000\000\000\000\060\241\354\364\377\177\000\000pV\314\364\377\177\000\000\260Sc\000\000\000\000\000\270\235\354,
 incomplete sequence \364, 
  library_filename = 
/usr/lib/x86_64-linux-gnu/libgphoto2_port/0.8.0/usb1\000\330c, '\000' 
repeats 13 times, 
\320\321\377\377\377\177\000\000\002\000\000\000\000\000\000\000\230\n\220\366\377\177\000\000
 
L\366\377\177\000\000\000\314\377\367\377\177\000\000\360\320\377\367\377\177\000\000`\320\377\367\377\177\000\000\000p\375\367\377\177\000\000̳l\366\377\177\000\000\220\321\377\377\377\177\000\000\234Ӟ\366\377\177\000\000\002\000\000\000\377\177,
 '\000' repeats 14 times, \001\000\000\000

Bug#728834: doesn't know how to open http links by default

2013-11-06 Thread Peter Eisentraut

On 11/6/13, 1:06 AM, Carsten Schoenert wrote:
 Hello Peter,
 
 On Tue, Nov 05, 2013 at 09:51:36PM -0500, Peter Eisentraut wrote:
 Package: icedove
 Version: 24.0-1
 Severity: normal

 I fresh icedove installation doesn't know how to open http links in
 emails.  Instead, it requires me to use a file system dialog to dig my
 way down to /usr/bin/something, which is very unfriendly and slow.
 Given that Debian has a standard for this (x-www-browser), this could
 be configured by default.
 
 what kind of window manager do you use?
 What's your system?  A fresh install from unstable or experiemental?
 What else do you have done?

Window manager is GNOME.  The system is running testing.  The icedove
package was from experimental (see version number).  I had never used
icedove on this system before.


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

Bug#616180: Old GCC bug affecting postgresql error handling

2013-11-06 Thread Tom Lane

Ian Jackson ijack...@chiark.greenend.org.uk writes:
 Tom Lane writes (Re: Old GCC bug affecting postgresql error handling):
 I wonder whether the gcc folk reconsidered and fixed the problem
 somewhere between 4.1.x and 4.4.x.  I've seen them reverse course
 before on what was or wasn't a bug.

 I wasn't able to do a test of the actual current postgresql with a
 current Debian compiler.  The original report is on sparc64 which is a
 bit difficult as I can't find any sparc64 porter box.

Well, I certainly hope current Postgres would not show the bug, regardless
of gcc's whims ;-).  We have those extra return statements in there now,
and also in current sources there's been an attempt to teach the compiler
that ereport(ERROR) doesn't return anyway, via __builtin_unreachable()
or local equivalent.  I remain concerned that there may be other places
exhibiting bugs with the same cause, but I'm pretty sure we've masked the
division-by-zero symptom.

regards, tom lane


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

Bug#728573: supercollider: FTBFS on sparc and ppc but built there in the past

2013-11-06 Thread Felipe Sateler

On Sun, Nov 3, 2013 at 7:44 AM, Dan S danstowell+de...@gmail.com wrote:

 Thanks. As discussed previously on pkg-multimedia-maintainers, I
 propose that we restrict archs for one package
 supercollider-supernova. The package is optional for users (it's a
 non-default drop-in alternative to supercollider-server) and there
 is very little upstream support for getting it working across archs.
 It uses some fancy coding and boost libs that I'm not familiar with,
 and these are what incur these build fails. I know it would be great
 to avoid having to special-case any archs, but I don't see where the
 expertise will come from to do this, and supercollider is
 fully-functional without that package.

I thought sc used the problematic boost libs elsewhere so this was not
really a workable solution...


-- 

Saludos,
Felipe Sateler


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

Bug#616180: Old GCC bug affecting postgresql error handling

2013-11-06 Thread Ian Jackson

Tom Lane writes (Re: Old GCC bug affecting postgresql error handling):
 Ian Jackson ijack...@chiark.greenend.org.uk writes:
  I wasn't able to do a test of the actual current postgresql with a
  current Debian compiler.  The original report is on sparc64 which is a
  bit difficult as I can't find any sparc64 porter box.
 
 Well, I certainly hope current Postgres would not show the bug, regardless
 of gcc's whims ;-).  We have those extra return statements in there now,
 and also in current sources there's been an attempt to teach the compiler
 that ereport(ERROR) doesn't return anyway, via __builtin_unreachable()
 or local equivalent.  I remain concerned that there may be other places
 exhibiting bugs with the same cause, but I'm pretty sure we've masked the
 division-by-zero symptom.

Indeed.  If I had the time and resources I might try seeing if current
postgresql can be persuaded to re-exhibit this bug with a modern
compiler by reverting some of the return statements put in as a
workaround for this bug.  But I don't.

Regards,
Ian.


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

Bug#680341: works in evince 3.8.3-2 correctly

2013-11-06 Thread Andreas Cadhalpun


Hi Joachim,

I tried to reproduce the problem in current Debian testing (evince 
3.8.3-2), but for me it worked as expected. Also the pdf file attached 
to your email was shown correctly.


Would you please try it with evince 3.8.3-2?

Best regards,
Andreas


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

Bug#676618: remove /usr/lib/jni from java.library.path ?