Bug#630313: kopete: Crash at closing the application.
Hi, it seems to be debian or maybe som other distros problem, but my colleague has Fedora 15 and there is no such problem, kopete is closing without crash. So please fix it, it's really annoying. Best regards Martin -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#639841: Sudo bugs
It bit me - until I saw this discussion I went into my /etc/profile and added the needed directories to ensure all needed programs could be found. -- ---Frank McCormick--- ---Montreal--- -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#639847: the guilt-* commands are not avaible
Package: guilt Version: 0.35-1 Severity: normal The commands like guilt-init, guilt-add, etc. are unavailable. The guilt command is ok I think that the commands are not in the correct directory (/usr/lib/guilt/guilt-add for exemple). The guilt command is in /usr/bin/ Thanks -- System Information: Debian Release: wheezy/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 3.0.0-1-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 guilt depends on: ii git [git-core] 1:1.7.5.4-1 fast, scalable, distributed revisi ii git-core 1:1.7.5.4-1 fast, scalable, distributed revisi guilt recommends no packages. guilt 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#628040: Re[2]: Bug#628040: Patch to fix cgroup issue
yes it works.
Bug#639848: libicu4j-java: Synopsis typo
Package: libicu4j-java Severity: minor -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi, Just to warn you that there is a typo in the synopsis: s/internalisation/internationalization/ Cheers, Vincent - -- System Information: Debian Release: 6.0.2 APT prefers stable-updates APT policy: (800, 'stable-updates'), (800, 'stable'), (96, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 2.6.32-5-amd64 (SMP w/1 CPU core) Locale: LANG=fr_FR.utf8, LC_CTYPE=fr_FR.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages libicu4j-java depends on: ii default-jre-headle 1:1.6-40 Standard Java or Java compatible R ii openjdk-6-jre-head 6b18-1.8.7-2~squeeze1 OpenJDK Java runtime, using Hotspo libicu4j-java recommends no packages. libicu4j-java suggests no packages. - -- no debconf information -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) iEYEARECAAYFAk5dcw8ACgkQbO4uEp7kOBORQwCeO7+pVJd6QOr0QRhWD0FgY8cN iKEAoKb2iTwy92n2Xm48JBzRTe5fsUMc =W/ZC -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#637829: Warning: failed to launch javaldx
FWIW, I resolved the problem this way, in Ubuntu 11.10. From the command line, I ran: strace -f -o localc.trace localc When the spreadsheet app started, I immediately closed it. Then I searched through the localc.trace file for the string javaldx and found the following line: execve(/usr/lib/libreoffice/program/../ure/bin/javaldx, [/usr/lib/libreoffice/program/../..., -env:INIFILENAME=vnd.sun.star.pa...], [/* 60 vars */]) = -1 ENOENT (No such file or directory) Apparently, libreoffice is searching for the javaldx binary in /usr/lib/libreoffice/ure/bin/javaldx but it isn't there. So I looked for it: locate javaldx The locate program found it in /usr/lib/ure/bin/javaldx So I symlinked the directory as follows: cd /usr/lib/libreoffice ln -s ../ure . Problem solved, or worked-around at least.
Bug#639830: mdadm: alternative md-device names
On Tue, 30 Aug 2011, martin f krafft wrote: also sprach Cristian Ionescu-Idbohrn cristian.ionescu-idbo...@axis.com [2011.08.30.1922 +0200]: My experience is that everything boils down to device names. /dev/md0 and /dev/md/0 is the same device, AFAICT. They should be handled as equaly. This trivial patch: These are handled the same by mdadm already. Please try to narrow down the bug more. I'd very much like to do so. Any ideas what I should look for? $INITRDSTART is empty and the output I see comming out of 'update-initramfs' is: warn I am supposed to start $i from the initial ramdisk, warn yet I cannot find the array in the configuration file. warn I am thus reverting to starting all arrays. $INITRDSTART gets set to 'all' and I see: info will start all available MD arrays from the initial ramdisk. Still, 'lsmod' does not show modules 'md_mod' and 'raid1' loaded. Without actively adding/uncommenting the /etc/initramfs-tools/modules line: raid1 I get the 'initramfs' prompt. At that prompt, if I execute: mdadm --assemble --scan and ^D after that, the named modules are loaded (directory /dev/disk/by-uuid shows up) and the boot process continues and finishes as expected. Where should I look, what should I look for? Cheers, -- Cristian -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#638887: udev: cdrom_id process can not be killed
Hello there, On Mon, Aug 22, 2011 at 10:30:32AM -0700, Jameson Graef Rollins wrote: Occasionally I find a cdrom_id process stuck in the D (uninterruptible sleep) state that can not be killed. I'm not exactly sure what's causing this (possibly detaching from my dock?) but this causes multiple problems on my system. First of all, my syslog starts filling with the following lines, appearing approximately once per second: Aug 22 08:55:26 servo udevd[31950]: timeout: killing 'cdrom_id --lock-media /dev/sr0' [32017] More frustratingly, my system becomes unable to sleep, because the cdrom_id process can't be frozen [0]. Same happens here. Right after undocking my laptop (Thinkpad X220, more info below) from an Ultrabase I'm unable to put it to sleep. When I hit the sleep button (Fn+F4) the screen goes blank but after some seconds the desktop comes back. Debug messages I've found in system logs are very similar to the ones that you've attached to your bug report. There is a dvd drive in my dock, so I'm assuming it must be somehow related to that. Mine also has one. Please let me know if I can provide any more useful info. Please reply to the bug if you need more information from my side too, I'm subscribed. Kernel log snippet and some misc system information follows: [35236.009031] INFO: task cdrom_id:15645 blocked for more than 120 seconds. [35236.009041] echo 0 /proc/sys/kernel/hung_task_timeout_secs disables this message. [35236.009047] cdrom_idD 880212283590 0 15645 2154 0x0004 [35236.009058] 880212283590 0082 880212283948 00ff88020001 [35236.009070] 8801f1be4300 00012800 8801f0c65fd8 8801f0c65fd8 [35236.009080] 00012800 880212283590 00012800 00012800 [35236.009090] Call Trace: [35236.009109] [81335939] ? schedule_timeout+0x2d/0xd7 [35236.009120] [81038189] ? test_tsk_need_resched+0xe/0x17 [35236.009130] [81335713] ? wait_for_common+0x9d/0x116 [35236.009138] [8103f0a4] ? try_to_wake_up+0x199/0x199 [35236.009148] [8105b266] ? start_flush_work+0xec/0x103 [35236.009156] [8105b57c] ? flush_work+0x24/0x2c [35236.009163] [8105ae8f] ? do_work_for_cpu+0x1b/0x1b [35236.009173] [811994be] ? disk_clear_events+0x86/0xe4 [35236.009184] [81121c0e] ? check_disk_change+0x22/0x50 [35236.009196] [a04b6051] ? cdrom_open+0x45/0x4aa [cdrom] [35236.009206] [811a4c79] ? kobject_get+0x12/0x17 [35236.009213] [81198079] ? get_disk+0x6d/0x8d [35236.009221] [8103840a] ? should_resched+0x5/0x24 [35236.009229] [8133565f] ? _cond_resched+0x9/0x20 [35236.009240] [8124b9df] ? kobj_lookup+0x13a/0x174 [35236.009248] [811a4c79] ? kobject_get+0x12/0x17 [35236.009257] [a04bd7c3] ? sr_block_open+0x93/0xbc [sr_mod] [35236.009265] [811229b1] ? __blkdev_get+0xe3/0x380 [35236.009275] [810cf775] ? set_pte_at+0x5/0x8 [35236.009283] [81122ef5] ? blkdev_get+0x2a7/0x2a7 [35236.009290] [81122e15] ? blkdev_get+0x1c7/0x2a7 [35236.009298] [81122ef5] ? blkdev_get+0x2a7/0x2a7 [35236.009309] [810fa32e] ? __dentry_open+0x182/0x29c [35236.009319] [811035df] ? dget+0x12/0x1e [35236.009326] [81105861] ? do_last+0x46d/0x584 [35236.009333] [81106bea] ? path_openat+0xc7/0x349 [35236.009342] [810d0312] ? tlb_flush_mmu+0x37/0x50 [35236.009350] [81106e98] ? do_filp_open+0x2c/0x72 [35236.009358] [8133565f] ? _cond_resched+0x9/0x20 [35236.009366] [811ac741] ? __strncpy_from_user+0x19/0x4a [35236.009374] [81110208] ? alloc_fd+0x69/0x110 [35236.009383] [810fb138] ? do_sys_open+0x5f/0xe6 [35236.009394] [8133ba92] ? system_call_fastpath+0x16/0x1b Linux lrrr 3.0.0-1-amd64 #1 SMP Sun Jul 24 02:24:44 UTC 2011 x86_64 GNU/Linux processor : 0 vendor_id : GenuineIntel cpu family : 6 model : 42 model name : Intel(R) Core(TM) i7-2620M CPU @ 2.70GHz stepping: 7 cpu MHz : 800.000 cache size : 4096 KB physical id : 0 siblings: 4 core id : 0 cpu cores : 2 apicid : 0 initial apicid : 0 fpu : yes fpu_exception : yes cpuid level : 13 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx rdtscp lm constant_tsc arch_perfmon pebs bts nopl xtopology nonstop_tsc aperfmperf pni pclmulqdq dtes64 monitor ds_cpl vmx smx est tm2 ssse3 cx16 xtpr pdcm sse4_1 sse4_2 x2apic popcnt aes xsave avx lahf_lm ida arat epb xsaveopt pln pts dts tpr_shadow vnmi flexpriority ept vpid bogomips: 5382.54 clflush size: 64 cache_alignment : 64 address sizes : 36 bits physical, 48 bits virtual power management: processor : 1 vendor_id : GenuineIntel
Bug#639848: libicu4j-java: Synopsis typo
On Tue, Aug 30, 2011 at 11:32 PM, Vincent Blut vincent.deb...@free.fr wrote: internalisation This is the UK spelling (as an American, I agree with your spelling, but internalisation is actually correct) Hooray Irony! Cheers, Paul -- All programmers are playwrights, and all computers are lousy actors. #define sizeof(x) rand() :wq -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#639849: rpcbind: Startup Errors on Debian
Package: rpcbind Version: 0.2.0-6 Severity: normal Rpcbind has some errors on Debian startup. -- System Information: Debian Release: wheezy/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 3.0.4.atom (SMP w/2 CPU cores; PREEMPT) Locale: LANG=pt_BR.utf8, LC_CTYPE=pt_BR.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages rpcbind depends on: ii insserv 1.14.0-2.1 Tool to organize boot sequence usi ii libc6 2.13-16Embedded GNU C Library: Shared lib ii libtirpc1 0.2.2-5transport-independent RPC library ii libwrap0 7.6.q-21 Wietse Venema's TCP wrappers libra ii lsb-base 3.2-27 Linux Standard Base 3.2 init scrip rpcbind recommends no packages. rpcbind 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#639748: chromium: please add a side pane for bookmarks (like the one in Galeon)
On Mon, 29 Aug 2011 17:15:31 -0500 Jonathan Nieder wrote: [...] Hi Francesco! Hi Jonathan! Francesco Poli (wintermute) wrote: While trying out Chromium, I noticed that the way to access bookmarks is terribly slow and uncomfortable: the bookmarks bar shown in the new tab page (or always shown, if you check Always show the bookmarks bar in the preferences) only makes the first few bookmark folders visible; [...] All this is really slow and unpractical, especially if you have a good number of bookmarks. If you hit Ctrl+Shift+O, I tried to hit [Ctrl+Shift+O], but nothing happened... then you get access to a bookmark manager with search and everything. I saw the bookmark manager (even though it does not seem to show up, when I hit [Ctrl+Shift+O]), but it's no real substitute for the bookmark side pane. It takes one whole tab, rather than a side portion of the window, and it's not visible when you visit a web site on one of the active tabs. But practically speaking, what I would encourage is to put the permanent bookmarks that need to be nicely organized on a webpage (either local or public) and use the Bookmark this page feature just as a way to save a few interesting pages that you were reading recently or that you frequently need to open in a new tab. This would be a huge step back with respect to all the other modern web browsers I've seen around. I tried to do that back in the 1990s, when I was still a sad Windows user (!) and browsed the web with Internet Explorer (!): well, it doesn't scale! As soon as you collect a good number of bookmarks, which you have to update and expand, the manual modification of the HTML code is unpractical and time consuming. One could set up some more automated system, sure. But, hey, this should be the job of the web browser! And it is, for every modern web browser that I know of. Except for Chromium, which seems to still be at the stone age of bookmark access... :-( In other words, these aren't necessarily the kind of bookmark you are used to. :) OK, then Chromium basically lacks the modern (and useful) kind of bookmarks. I think that this is a very embarrassing gap for a modern web browser. [...] What I would really love seeing implemented in Chromium is a side pane Chromium doesn't currently have any side panes. Even the developer tools open in a separate window, so I guess that would be more consistent with what you are looking for. Please feel free to report this at http://crbug.com/ and let us know the bug number if you want to pursue it. It seems that I am required to create a Google account to report bugs at http://crbug.com/ : I am not going to create one, as I am too concerned for its privacy issues. Normally I would ask you to forward my bug upstream, but here the situation is different. I've done a quick web search and it seems that there are lots of users that lack this feature and most of them won't switch to Google Chrome or Chromium until this feature is implemented. http://www.thechromesource.com/the-people-want-a-chrome-bookmarks-side-bar/ http://www.google.com/support/forum/p/Chrome/thread?tid=4c5bdb5b16092e68hl=en http://code.google.com/p/chromium/issues/detail?id=20785 http://code.google.com/p/chromium/issues/detail?id=45365 You can probably consider either of the last two URLs as a good approximation of a forwarded version of my bug report. This feature request has already been re-iterated many many times to the upstream developers, but, surprisingly, they seem to refuse to implement it. If this is how Chromium upstream developers deal with very popular feature requests, I do not dare imagine how they deal with minority ones. Maybe I must search for another (primary) web browser to switch to... :-( -- http://www.inventati.org/frx/frx-gpg-key-transition-2010.txt New GnuPG key, see the transition document! . Francesco Poli . GnuPG key fpr == CA01 1147 9CD2 EFDF FB82 3925 3E1C 27E1 1F69 BFFE pgpuolADXUyD6.pgp Description: PGP signature
Bug#639850: gimp-gap version 2.6.0+dfsg-1 failed to build on amd64 with GCC-4.6
Package: gimp-gap Version: 2.6.0+dfsg-1 Severity: important Tags: patch User: ubuntu-de...@lists.ubuntu.com Usertags: origin-ubuntu oneiric ubuntu-patch In Ubuntu, the attached patch was applied to achieve the following: * Update implicit-pointer-conversion.patch to include another missing header. Fixes FTBFS on amd64/ia64. (LP: #770934) * Add broken-comment-delimiter.patch to resolve a misplaced comment delimiter that broken the build. Fixes FTBFS. Thanks for considering the patch. -- System Information: Debian Release: wheezy/sid APT prefers oneiric-updates APT policy: (500, 'oneiric-updates'), (500, 'oneiric-security'), (500, 'oneiric-proposed'), (500, 'oneiric') Architecture: amd64 (x86_64) Kernel: Linux 3.0.0-9-generic (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 diff -u gimp-gap-2.6.0+dfsg/debian/patches/implicit-pointer-conversion.patch gimp-gap-2.6.0+dfsg/debian/patches/implicit-pointer-conversion.patch --- gimp-gap-2.6.0+dfsg/debian/patches/implicit-pointer-conversion.patch +++ gimp-gap-2.6.0+dfsg/debian/patches/implicit-pointer-conversion.patch @@ -1,6 +1,6 @@ -diff -urpN gimp-gap-2.6.0.orig/gap/gap_story_dialog.h gimp-gap-2.6.0/gap/gap_story_dialog.h gimp-gap-2.6.0.orig/gap/gap_story_dialog.h 2009-06-04 14:38:03.0 -0600 -+++ gimp-gap-2.6.0/gap/gap_story_dialog.h 2009-07-10 13:30:35.833743151 -0600 +diff -Nur -x '*.orig' -x '*~' gimp-gap-2.6.0+dfsg//gap/gap_story_dialog.h gimp-gap-2.6.0+dfsg.new//gap/gap_story_dialog.h +--- gimp-gap-2.6.0+dfsg//gap/gap_story_dialog.h 2009-06-04 16:38:03.0 -0400 gimp-gap-2.6.0+dfsg.new//gap/gap_story_dialog.h 2011-08-30 17:07:43.0 -0400 @@ -32,6 +32,8 @@ #include gap_story_main.h #include gap_story_properties.h @@ -10,9 +10,9 @@ voidgap_storyboard_dialog(GapStbMainGlobalParams *gpp); voidgap_story_dlg_attw_render_all(GapStbAttrWidget *attw); -diff -urpN gimp-gap-2.6.0.orig/gap/gap_story_properties.c gimp-gap-2.6.0/gap/gap_story_properties.c gimp-gap-2.6.0.orig/gap/gap_story_properties.c 2009-06-04 14:38:03.0 -0600 -+++ gimp-gap-2.6.0/gap/gap_story_properties.c 2009-07-10 13:31:59.424583981 -0600 +diff -Nur -x '*.orig' -x '*~' gimp-gap-2.6.0+dfsg//gap/gap_story_properties.c gimp-gap-2.6.0+dfsg.new//gap/gap_story_properties.c +--- gimp-gap-2.6.0+dfsg//gap/gap_story_properties.c 2009-06-04 16:38:03.0 -0400 gimp-gap-2.6.0+dfsg.new//gap/gap_story_properties.c 2011-08-30 17:07:43.0 -0400 @@ -55,6 +55,7 @@ #include gap_timeconv.h #include gap_thumbnail.h @@ -21,9 +21,9 @@ #include gap_story_vthumb.h -diff -urpN gimp-gap-2.6.0.orig/libgapvidutil/gap_gve_misc_util.c gimp-gap-2.6.0/libgapvidutil/gap_gve_misc_util.c gimp-gap-2.6.0.orig/libgapvidutil/gap_gve_misc_util.c 2009-06-04 14:38:03.0 -0600 -+++ gimp-gap-2.6.0/libgapvidutil/gap_gve_misc_util.c 2009-07-10 13:33:22.379426254 -0600 +diff -Nur -x '*.orig' -x '*~' gimp-gap-2.6.0+dfsg//libgapvidutil/gap_gve_misc_util.c gimp-gap-2.6.0+dfsg.new//libgapvidutil/gap_gve_misc_util.c +--- gimp-gap-2.6.0+dfsg//libgapvidutil/gap_gve_misc_util.c 2009-06-04 16:38:03.0 -0400 gimp-gap-2.6.0+dfsg.new//libgapvidutil/gap_gve_misc_util.c 2011-08-30 17:07:43.0 -0400 @@ -34,6 +34,7 @@ #include sys/stat.h #include errno.h @@ -34,0 +35,11 @@ +diff -Nur -x '*.orig' -x '*~' gimp-gap-2.6.0+dfsg//vid_enc_avi/gap_enc_avi_main.c gimp-gap-2.6.0+dfsg.new//vid_enc_avi/gap_enc_avi_main.c +--- gimp-gap-2.6.0+dfsg//vid_enc_avi/gap_enc_avi_main.c 2009-06-04 16:38:03.0 -0400 gimp-gap-2.6.0+dfsg.new//vid_enc_avi/gap_enc_avi_main.c 2011-08-30 17:09:07.0 -0400 +@@ -57,6 +57,7 @@ + + #include gap_gve_story.h /* for STORYBOARD support */ + ++#include gap_gve_png.h + #include gap_gve_jpeg.h /* for the builtin JPEG support */ + #include gap_gve_raw.h /* for raw CODEC support */ + #include gap_gve_xvid.h /* for XVID CODEC support */ only in patch2: unchanged: --- gimp-gap-2.6.0+dfsg.orig/debian/patches/broken-comment-delimiter.patch +++ gimp-gap-2.6.0+dfsg/debian/patches/broken-comment-delimiter.patch @@ -0,0 +1,12 @@ +diff -Nur -x '*.orig' -x '*~' gimp-gap-2.6.0+dfsg//libgapvidutil/gap_gve_png.h gimp-gap-2.6.0+dfsg.new//libgapvidutil/gap_gve_png.h +--- gimp-gap-2.6.0+dfsg//libgapvidutil/gap_gve_png.h 2009-06-04 16:38:03.0 -0400 gimp-gap-2.6.0+dfsg.new//libgapvidutil/gap_gve_png.h 2011-08-30 17:26:26.0 -0400 +@@ -23,7 +23,7 @@ +app0_length: the length of the APP0-marker. +out:PNG_size: The size of the buffer that is returned. +returns: guchar *: A buffer, allocated by this routines, which contains +- the compressed PNG, NULL on error. */ ++ the compressed PNG, NULL on error. + */ + + guchar *gap_gve_png_drawable_encode_png(GimpDrawable *drawable, gint32 png_interlaced, gint32 *PNG_size,
Bug#637688: [mercurial] unable to reproduce bug
On Thu, Aug 18, 2011 at 3:31 PM, Julien Cristau jcris...@debian.org wrote: On Thu, Aug 18, 2011 at 14:12:17 -0400, Simon wrote: On 2011-08-16 03:49, Javi Merino wrote: Hi Chris, BTW in case this may help, I'm including the output of the following command: $ ls -ld /usr/lib/python2.6/site-packages ls: cannot access /usr/lib/python2.6/site-packages: No such file or directory a symlink to dist-packages/ That's utterly broken. Did you create that symlink? Cheers, Julien yes, and removed it when i sent you the previous email ;). -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#639848: libicu4j-java: Synopsis typo
Le 30/08/2011 21:36, Paul Tagliamonte a écrit : On Tue, Aug 30, 2011 at 11:32 PM, Vincent Blut vincent.deb...@free.fr wrote: internalisation This is the UK spelling (as an American, I agree with your spelling, but internalisation is actually correct) Hooray Irony! Cheers, Paul Ok but why you don't use it in the long description? That could avoid this kind of crappy bug report ;-) Anyway, sorry for the noise! -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#630031: Isn't it another sign of problems with D865GBF motherboards?
I found this bug, when I was looking for solution for my problem related to the newest kernels and a machine based on D865GBF motherboard. I was striked by the fact, that problem reported here occured in a machine with the same motherboard and the newest kernel. My problem (macine not starting when HT is on) is reported as Debian bug http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=631597 and was later redirected to https://bugzilla.kernel.org/show_bug.cgi?id=38262 Maybe this two problems are correlated? -- Regards, WZab -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#639748: chromium: please add a side pane for bookmarks (like the one in Galeon)
forwarded 639748 http://crbug.com/20785 tags 639748 + wontfix quit Francesco Poli wrote: If this is how Chromium upstream developers deal with very popular feature requests, I do not dare imagine how they deal with minority ones. Yes, upstream responds much better to well explained patches than to feature requests. Thanks for the pointers. Jonathan -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#404497: stty reports bogus error.
Package: coreutils Version: 8.5-1 Followup-For: Bug #404497 Hi, Any news on this bug? I just have been hit by it and it tooks me time to understand what happens. Regards, Vincent -- System Information: Debian Release: wheezy/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing'), (500, 'stable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 3.0.0-1-amd64 (SMP w/2 CPU cores) Locale: LANG=fr_FR.utf8, LC_CTYPE=fr_FR.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages coreutils depends on: ii libacl1 2.2.51-3 Access control list shared library ii libattr1 1:2.4.46-3 Extended attribute shared library ii libc6 2.13-18Embedded GNU C Library: Shared lib ii libselinux1 2.0.98-1.1 SELinux runtime shared libraries coreutils recommends no packages. coreutils 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#639848: libicu4j-java: Synopsis typo
retitle 639848 Description uses inconsistent English-es kthxbye On Tue, Aug 30, 2011 at 11:44 PM, Vincent Blut vincent.deb...@free.fr wrote: Le 30/08/2011 21:36, Paul Tagliamonte a écrit : On Tue, Aug 30, 2011 at 11:32 PM, Vincent Blut vincent.deb...@free.fr wrote: internalisation This is the UK spelling (as an American, I agree with your spelling, but internalisation is actually correct) Hooray Irony! Cheers, Paul Ok but why you don't use it in the long description? I avoided closing the bug it for just this reason! I secretly hoped there was another reason :) P.S. I did not write it, just saw the bug. That could avoid this kind of crappy bug report ;-) No bug report is a crappy bug report :) Anyway, sorry for the noise! Not at all! Fixed the report! :) -- All programmers are playwrights, and all computers are lousy actors. #define sizeof(x) rand() :wq -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#639851: symbol lookup error _restgpr_28_x
Package: xulrunner-6.0 Version: 6.0-4 Severity: important Hi, I can't start xulrunner-6.0 anymore: % xulrunner-6.0 /usr/lib/xulrunner-6.0/xulrunner-bin: symbol lookup error: /usr/lib/xulrunner-6.0/libxul.so: undefined symbol: _restgpr_28_x Version 6.0-2 worked fine. Bye, Jörg. -- System Information: Debian Release: unstable/experimental APT prefers unstable APT policy: (900, 'unstable'), (700, 'experimental') Architecture: powerpc (ppc) Kernel: Linux 3.1.0-rc3.ledtest-00161-g671ee7f-dirty Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages xulrunner-6.0 depends on: ii libasound21.0.24.1-3 ii libatk1.0-0 2.0.1-2 ii libbz2-1.01.0.5-6 ii libc6 2.13-18 ii libcairo2 1.10.2-6.1 ii libdbus-1-3 1.4.14-1 ii libevent-1.4-21.4.14b-stable-1 ii libfontconfig12.8.0-3 ii libfreetype6 2.4.6-2 ii libgcc1 1:4.6.1-8 ii libgdk-pixbuf2.0-02.23.5-3 ii libglib2.0-0 2.28.6-1 ii libgtk2.0-0 2.24.5-4 ii libhunspell-1.2-0 1.2.14-4 ii libjpeg8 8c-2 ii libmozjs6d6.0-4 ii libnspr4-0d 4.8.9-1 ii libnss3-1d3.12.11-1 ii libpango1.0-0 1.28.4-3 ii libpixman-1-0 0.22.2-1 ii libreadline6 6.2-4 ii libsqlite3-0 3.7.7-2 ii libstartup-notification0 0.12-1 ii libstdc++64.6.1-8 ii libvpx0 0.9.7.p1-1 ii libx11-6 2:1.4.4-1 ii libxext6 2:1.3.0-3 ii libxrender1 1:0.9.6-2 ii libxt61:1.1.1-2 ii zlib1g1:1.2.5.dfsg-1 xulrunner-6.0 recommends no packages. Versions of packages xulrunner-6.0 suggests: pn libcanberra0 0.28-1 pn libdbus-glib-1-2 0.94-4 pn libgconf2-4 2.32.4-1 pn libgnomeui-0 2.24.5-1 pn libgnomevfs2-01:2.24.4-1 pn libnotify4none -- no debconf information signature.asc Description: Digital signature http://en.wikipedia.org/wiki/OpenPGP
Bug#639341: dh: cannot override binary-arch and binary-indep selectively
Yann Dirson wrote: I tried things like: build-arch: dh_auto_build -a docbook-to-man debian/tulip.sgml debian/tulip.1 You're not running dh_auto_configure which dh would normally run here. Why not just run dh build-arch in the build-arch target? -- see shy jo signature.asc Description: Digital signature
Bug#630031: Isn't it another sign of problems with D865GBF motherboards?
forwarded 630031 https://bugzilla.kernel.org/show_bug.cgi?id=38262 merge 631597 630031 quit wzab wrote: I found this bug, when I was looking for solution for my problem related to the newest kernels and a machine based on D865GBF motherboard. I was striked by the fact, that problem reported here occured in a machine with the same motherboard and the newest kernel. My problem (macine not starting when HT is on) is reported as Debian bug http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=631597 and was later redirected to https://bugzilla.kernel.org/show_bug.cgi?id=38262 Maybe this two problems are correlated? Thanks, WZab. I suspect you're right (and we can unmerge them later if they turn out to have different causes). -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#639828: FTBFS: POM 'org.apache.maven.plugins:maven-plugin-plugin' not found in repository
tag 639828 + pending thanks On Tue, Aug 30, 2011 at 06:41:11PM +0200, Laurent Fousse wrote: Package: access-modifier-checker Version: 1.0-1 Severity: serious Justification: fails to build from source Your package fails to build from source: It is already fixed in git. -- Miguel Landaeta, miguel at miguel.cc secure email with PGP 0x7D8967E9 available at http://keyserver.pgp.com/ Faith means not wanting to know what is true. -- Nietzsche signature.asc Description: Digital signature
Bug#639848: libicu4j-java: Synopsis typo
Le 30/08/2011 21:49, Paul Tagliamonte a écrit : retitle 639848 Description uses inconsistent English-es kthxbye On Tue, Aug 30, 2011 at 11:44 PM, Vincent Blut vincent.deb...@free.fr wrote: Le 30/08/2011 21:36, Paul Tagliamonte a �crit : On Tue, Aug 30, 2011 at 11:32 PM, Vincent Blut vincent.deb...@free.fr wrote: internalisation This is the UK spelling (as an American, I agree with your spelling, but internalisation is actually correct) Hooray Irony! Cheers, Paul Ok but why you don't use it in the long description? I avoided closing the bug it for just this reason! I secretly hoped there was another reason :) P.S. I did not write it, just saw the bug. That could avoid this kind of crappy bug report ;-) No bug report is a crappy bug report :) You should take a look at #54 :-o Anyway, sorry for the noise! Not at all! Fixed the report! :) Thanks Paul! -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#630730: linux-image-2.6.32: GSO IPv6 issues
On Fri, Aug 26, 2011 at 01:10:25AM +0300, Faidon Liambotis wrote: After talking with Ben on IRC, I've prepared and sent a -longterm tree submission for the two commits. I'll update the bug report when I get a reply. I just got a reply that the patches were accepted to the stable review queue. Regards, Faidon -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#615998: linux-image-2.6.32-5-xen-amd64: Repeatable kernel BUG at fs/jbd2/commit.c:534 from Postfix on ext4
Hi, On Fri 26-08-11 16:03:32, Moffett, Kyle D wrote: Ping? Any more ideas for debugging this issue? Sorry for not getting to you earlier. I can still trigger it on my VM snapshot very easily, so if you have anything you think I should test I would be very happy to give it a shot. OK, so in the meantime I found a bug in data=journal code which could be related to your problem. It is fixed by commit 2d859db3e4a82a365572592d57624a5f996ed0ec which is in 3.1-rc1. Have you tried that or newer kernel as well? If the problem still is not fixed, I can provide some debugging patch to you. We spoke with Josef Bacik how errors like yours could happen so I have some places to watch... Honza On Jun 24, 2011, at 16:51, Kyle Moffett wrote: On Jun 24, 2011, at 16:02, Jan Kara wrote: On Fri 24-06-11 11:03:52, Moffett, Kyle D wrote: On Jun 24, 2011, at 09:46, Jan Kara wrote: On Thu 23-06-11 16:19:08, Moffett, Kyle D wrote: Besides which, line 534 in the Debian 2.6.32 kernel I am using is this one: J_ASSERT(commit_transaction-t_nr_buffers = commit_transaction-t_outstanding_credits); The trouble is that the problem is likely in some journal list shuffling code because if just some operation wrongly estimated the number of needed buffers, we'd fail the assertion in jbd2_journal_dirty_metadata(): J_ASSERT_JH(jh, handle-h_buffer_credits 0); Hmm, ok... I'm also going to turn that failing J_ASSERT() into a WARN_ON() just to see how much further it gets. I have an easy script to recreate this data volume even if it gets totally hosed anyways, so... OK, we'll see what happens. Ok, status update here: I applied a modified version of your patch that prints out the values of both t_outstanding_credits and t_nr_buffers when the assertion triggers. I replaced the J_ASSERT() that was failing with the exact same WARN_ON() trigger too. The end result is that postfix successfully finished delivering all the emails. Afterwards I unmounted both filesystems and ran fsck -fy on them, it reported no errors at all. Looking through the log, the filesystem with the issues is the 32MB one mounted on /var/lib/postfix: total 61 drwxr-x--- 3 postfix postfix 1024 Jun 16 21:02 . drwxr-xr-x 46 rootroot 4096 Jun 20 17:19 .. d- 2 rootroot12288 Jun 16 18:35 lost+found -rw--- 1 postfix postfix33 Jun 24 16:34 master.lock -rw--- 1 postfix postfix 1024 Jun 24 16:44 prng_exch -rw--- 1 postfix postfix 2048 Jun 24 16:34 smtpd_scache.db -rw--- 1 postfix postfix 41984 Jun 24 16:36 smtp_scache.db In particular, it's the tlsmgr program accessing the smtp_scache file when it dies. Full log below. Cheers, Kyle Moffett Jun 24 16:36:05 i-38020f57 kernel: [5369326.385234] transaction-t_outstanding_credits = 8 Jun 24 16:36:05 i-38020f57 kernel: [5369326.385247] transaction-t_nr_buffers = 9 Jun 24 16:36:05 i-38020f57 kernel: [5369326.385251] [ cut here ] Jun 24 16:36:05 i-38020f57 kernel: [5369326.385278] WARNING: at /tmp/kdm-deb-kernel/linux-2.6-2.6.32/debian/build/source_amd64_xen/fs/jbd2/transaction.c:1329 jbd2_journal_stop+0x189/0x25d [jbd2]() Jun 24 16:36:05 i-38020f57 kernel: [5369326.385287] Modules linked in: ip6table_filter ip6_tables act_police cls_flow cls_fw cls_u32 sch_htb sch_hfsc sch_ingress sch_sfq xt_time xt_connlimit xt_realm iptable_raw xt_comment xt_recent xt_policy ipt_ULOG ipt_REJECT ipt_REDIRECT ipt_NETMAP ipt_MASQUERADE ipt_ECN ipt_ecn ipt_CLUSTERIP ipt_ah ipt_addrtype nf_nat_tftp nf_nat_snmp_basic nf_nat_sip nf_nat_pptp nf_nat_proto_gre nf_nat_irc nf_nat_h323 nf_nat_ftp nf_nat_amanda ts_kmp nf_conntrack_amanda nf_conntrack_sane nf_conntrack_tftp nf_conntrack_sip nf_conntrack_proto_sctp nf_conntrack_pptp nf_conntrack_proto_gre nf_conntrack_netlink nf_conntrack_netbios_ns nf_conntrack_irc nf_conntrack_h323 nf_conntrack_ftp xt_TPROXY nf_tproxy_core xt_tcpmss xt_pkttype xt_physdev xt_owner xt_NFQUEUE xt_NFLOG nfnetlink_log xt_multiport xt_MARK xt_mark xt_mac xt_limit xt_length xt_iprange xt_helper xt_hashlimit xt_DSCP xt_dscp xt_dccp xt_conntrack xt_CONNMARK xt_connmark xt_CLASSIFY ipt_LOG xt_tcpudp xt_state iptable_nat nf_nat n f_conntrac Jun 24 16:36:05 i-38020f57 kernel: k_ipv4 nf_defrag_ipv4 nf_conntrack iptable_mangle nfnetlink iptable_filter ip_tables x_tables ext3 jbd loop snd_pcm snd_timer snd soundcore snd_page_alloc pcspkr evdev ext4 mbcache jbd2 crc16 dm_mod xen_netfront xen_blkfront Jun 24 16:36:05 i-38020f57 kernel: [5369326.385440] Pid: 3817, comm: tlsmgr Not tainted 2.6.32-5-xen-amd64 #1 Jun 24 16:36:05 i-38020f57 kernel: [5369326.385445] Call Trace: Jun 24 16:36:05 i-38020f57 kernel: [5369326.385458] [a0032c81] ? jbd2_journal_stop+0x189/0x25d
Bug#632734: Isn't it another sign of problems with D865GBF motherboards?
I found this bug, when I was looking for solution for my problem related to the newest kernels and a machine based on D865GBF motherboard. I was striked by the fact, that problem reported here occured in a machine with the same motherboard and the newest kernel. My problem (machine not starting when HT is on) is reported as Debian bug http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=631597 and was later redirected to https://bugzilla.kernel.org/show_bug.cgi?id=38262 Maybe these two problems are correlated? (The same applies also to Debian bug 630031 ) -- Regards, WZab -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#639841: sudo: secure_path change needs a NEWS entry
On Tue, 30 Aug 2011 13:46:54 -0600, Bob Proulx b...@proulx.com wrote: Alternatively the sudo package could include a new conffile file in the package /etc/sudoers.d/00-secure_path or some such that includes the new secure_path setting. Being a new file it would be installed by default without dialog and become available. The problem with this idea is that the include directive was only recently added to the default Debian sudoers file, and so many systems with customized sudoers files might remain broken. The solution I'd like best but haven't made time to try and work out yet is for the binary to have a default secure_path, but still allow secure_path to be overridden in the sudoers file. I'm about to head out the door for a week in which I'm unlikely to have time to work on this, so if you or anyone else want to figure out if some combination of existing configure arguments or a simple patch might allow this to be implemented, that'd be great! Oh, and thanks for the proposed NEWS entry text, I agree that given the reaction to this change so far, some notice is warranted, and will plan to merge this or something like it for the next upload. Bdale pgpFb0FN019n9.pgp Description: PGP signature
Bug#487201: MPL in common-licenses and convenience of packaging mozilla extensions
On 29/08/11 17:48, Russ Allbery wrote: Jonathan Nieder jrnie...@gmail.com writes: Allowing debian/copyright to rely on files _other_ than the common licenses in base-files would be a larger and different change, so off-topic for this bug. Unless done carefully, I don't think it's a good idea. It's important to remember that Debian has a basic legal requirement to provide the licensing terms with the packages that we distribute, and those packages are potentially independent of each other from a legal perspective. Just because one package has a dependency on another doesn't mean that someone is required to download both packages, and when we distribute packages that do not include required legal texts, we're on shaky ground. The project decided to say that our packages are intended for use on a Debian system with the essential Debian packages installed and hence not duplicate licenses that are in base-files, which I think is a bit of a hand-wave, but which lets us avoid shipping 20,000 copies of the GPL. The legal requirements are generally quite clear, and the ideal legal position to be in is inclusion of relevant license texts in every package so that the individual object that we distribute is legally complete. OK, this is understandable. I suppose we can't get around the fact that each source package should have the full text of a license. However, this doesn't mean that we must include them in debian/copyright specifically - is this restriction really necessary for policy? (I know this is off-topic for the bug but it's a continuation of the discussion.) It would be less trouble if you could point to license files. Normally, those files exist with the upstream source already, and also not re-formatted, so you can verify their contents more easily. It would also support more powerful automation tools. For example, we can have a dh script dereference these pointers and install all the license texts into the package's /doc/. And maybe have a licenses-helper program which could detect dangling pointers, and fill the common ones in automatically, to save the maintainer having to find them if they weren't included with upstream. X -- GPG: 4096R/5FBBDBCE https://github.com/infinity0 https://bitbucket.org/infinity0 https://launchpad.net/~infinity0 signature.asc Description: OpenPGP digital signature
Bug#585433: Sid also broken
dm4:~# aptitude install fglrx-driver
The following NEW packages will be installed:
fglrx-driver{b}
The following packages are RECOMMENDED but will NOT be installed:
fglrx-atieventsd fglrx-glx fglrx-glx-ia32
0 packages upgraded, 1 newly installed, 0 to remove and 0 not upgraded.
Need to get 21.2 MB of archives. After unpacking 67.7 MB will be used.
The following packages have unmet dependencies:
fglrx-driver: Depends: xorg-video-abi-10 which is a virtual package. or
xorg-video-abi-8 which is a virtual package. or
xorg-video-abi-6.0 which is a virtual package.
The following actions will resolve these dependencies:
Keep the following packages at their current version:
1) fglrx-driver [Not Installed]
Accept this solution? [Y/n/q/?]
No packages will be installed, upgraded, or removed.
0 packages upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
Need to get 0 B of archives. After unpacking 0 B will be used.
Please fix it.
regards,
Levy SantAnna
Bug#626808: pxe-e1000.bin missing on Debian
Not sure this has been fixed; any help appreciated. *root@phlefevx:/usr/src/linux-source-3.0.0* *# qemu -s -S -hda /dev/zero -kernel /home/pat/workspace/kbuild/3.0.0-1/vmlinux * *qemu: **pci_add_option_rom: failed to find romfile pxe-e1000.bin* *# ls -l /usr/share/qemu/pxe-e1000.bin * *lrwxrwxrwx 1 root root 30 Jul 23 03:55 /usr/share/qemu/pxe-e1000.bin - ../../lib/ipxe/e1000_82540.rom * *ipxe is empty; * *# uname -a Linux phlefevx 3.0.0-1-rt-amd64 #1 SMP PREEMPT RT Wed Aug 17 05:18:11 UTC 2011 x86_64 GNU/Linux *
Bug#632396: rsyslog: terminates instead of logging anything past starting up
Am 02.07.2011 03:40, schrieb Thorsten Glaser: Michael Biebl dixit: Try -n That gives me (startup excluded): […] 0340.178347252:c09df4c0: main Q:Reg/w0: worker IDLE, waiting for work. 0346.258093052:c11df4c0: imuxsock calling select, active file descriptors (max 3): 3 After about 5 repeats (wc on the log, cut and uniq) of the 'calling select' line I ^C’d it, which spewed normal-looking shutdown messages. The call to logger returned normally, but nothing showed up in the logs. Looks like a m68k specific problem to me, probably libc/kernel related. I suggest you contact the m68k porters about this problem. Michael -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? signature.asc Description: OpenPGP digital signature
Bug#639841: sudo: secure_path change needs a NEWS entry
Bdale Garbee wrote: Bob Proulx wrote: Alternatively the sudo package could include a new conffile file in the package /etc/sudoers.d/00-secure_path or some such that includes the new secure_path setting. Being a new file it would be installed by default without dialog and become available. The problem with this idea is that the include directive was only recently added to the default Debian sudoers file, and so many systems with customized sudoers files might remain broken. Sorry but I don't understand. How would setting secure_path in a new sudoers.d file create a situation where a system would remain broken? Could you list an example of what you are talking about in order to make it concrete? It isn't really a solution I prefer. But any method to keep secure_path set by default but allow a local admin to unset it would be fine. I just couldn't think of any better way than a new file. There doesn't seem to be a way to !secure_path with it defaulted unless I missed something. That was Bug#85123 of course. But note that the NEWS entry is my first choice. Personally I am okay with it as long as I know about it. Of course I would prefer not to have to take action to keep the status quo but sometimes it is necessary and I will go with the flow if this is one of them. But I just know that users will be bitten by this and I just helped on such user on debian-user who ran headlong into this problem so there will be others. The solution I'd like best but haven't made time to try and work out yet is for the binary to have a default secure_path, but still allow secure_path to be overridden in the sudoers file. I'm about to head out the door for a week in which I'm unlikely to have time to work on this, so if you or anyone else want to figure out if some combination of existing configure arguments or a simple patch might allow this to be implemented, that'd be great! I already gave it my brain cells and was unable to propose any better solution. But I will think about it and respond if I can produce any better suggestion. Oh, and thanks for the proposed NEWS entry text, I agree that given the reaction to this change so far, some notice is warranted, and will plan to merge this or something like it for the next upload. Thanks! Bob signature.asc Description: Digital signature
Bug#639853: openjdk-6-jre = 6b23~pre8-2 breaks josm
Package: josm Version: 0.0.svn4064-3 Severity: grave Justification: renders package unusable The latest version of openjdk-6-jre is multiarch aware, which means the path of the jre has changed. This breaks /usr/bin/josm: + set -e ++ readlink -n -f /etc/alternatives/java + ALTERNATIVE_JDK=/usr/lib/jvm/java-6-openjdk-i386/jre/bin/java + dpkg --get-selections openjdk-6-jre + grep 'install$' + JAVA_CMDS='/bin/java /usr/lib/jvm/java-6-openjdk/bin/java /usr/lib/jvm/java-6-sun/bin/java' + JAVA_OPTS=' -Djava.net.preferIPv4Stack=true -Djava.net.useSystemProxies=true' + for jcmd in '$JAVA_CMDS' ++ readlink -n -f /bin/java + '[' z/usr/lib/jvm/java-6-openjdk-i386/jre/bin/java = z/bin/java ']' + for jcmd in '$JAVA_CMDS' ++ readlink -n -f /usr/lib/jvm/java-6-openjdk/bin/java + '[' z/usr/lib/jvm/java-6-openjdk-i386/jre/bin/java = z ']' + for jcmd in '$JAVA_CMDS' ++ readlink -n -f /usr/lib/jvm/java-6-sun/bin/java + '[' z/usr/lib/jvm/java-6-openjdk-i386/jre/bin/java = z ']' + for jcmd in '$JAVA_CMDS' + '[' -x /bin/java -a -z '' ']' + for jcmd in '$JAVA_CMDS' + '[' -x /usr/lib/jvm/java-6-openjdk/bin/java -a -z '' ']' + for jcmd in '$JAVA_CMDS' + '[' -x /usr/lib/jvm/java-6-sun/bin/java -a -z '' ']' + '[' '' ']' + echo 'No valid JVM found to run JOSM.' + exit 1 -- System Information: Debian Release: wheezy/sid APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: i386 (i686) Kernel: Linux 3.0.0-1-686-pae (SMP w/2 CPU cores) Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages josm depends on: ii libgettext-commons-java 0.9.6-2 Java classes for internationalizat ii libmetadata-extractor-j 2.3.1+dfsg-2 JPEG metadata extraction framework ii liboauth-signpost-java 1.2.1.1-1simple OAuth message signing for J ii openjdk-6-jre 6b23~pre8-2 OpenJDK Java runtime, using Hotspo ii openstreetmap-map-icons 1:0.0.svn23763-1 Collection of map icons (classic s Versions of packages josm recommends: ii josm-plugins 0.0.svn25935-1 Plugins for JOSM ii webkit-image-gtk 0.0.svn25399-2 generate images from webpages - GT josm 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#624062: upstream fix seems to exist: claws-mail 3.7.10cvs11
Hi, just found this patch: http://www.colino.net/claws-mail/index.php?len=4ver=3.7.10cvs11#3.7.10cvs11 2011-08-30 [colin]: 3.7.10cvs11 * configure.ac * src/common/ssl.c Don't use deprecated functions for GnuTLS priorities. Require GnuTLS 2.2 that is the first version with the new function. It looks like this fixes Debian Bug #624062. Thought mentioning this could be helpful, as there maybe is no firm connection between claws-mail development and Debian BTS... Thomas -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#639854: mutt-patched: crash on startup
Package: mutt-patched Version: 1.5.21-4~bpo60+1 Severity: important Hi, today I installed mutt-patched from backports, and it segfaults on startup. After the crash, the terminal is not in a sane state (ie, no cursor is being displayed). Core was generated by `mutt'. Program terminated with signal 11, Segmentation fault. #0 0x7f64b85bdb52 in ?? () from /lib/libc.so.6 (gdb) bt #0 0x7f64b85bdb52 in ?? () from /lib/libc.so.6 #1 0x0047ad51 in draw_sidebar (menu=1) at ../sidebar.c:275 #2 0x00440d0a in menu_redraw_index (menu=0x20335c0) at ../menu.c:211 #3 0x00441550 in menu_redraw (menu=0x20335c0) at ../menu.c:843 #4 0x0044162e in mutt_menuLoop (menu=0x20335c0) at ../menu.c:879 #5 0x004987ff in tls_check_one_certificate (certdata=0x201e920, certstat=value optimized out, hostname=0x1d97c40 imap.oeko.net, idx=value optimized out, len=value optimized out) at ../mutt_ssl_gnutls.c:883 #6 0x00498f7a in tls_check_certificate (conn=value optimized out) at ../mutt_ssl_gnutls.c:1020 #7 tls_negotiate (conn=value optimized out) at ../mutt_ssl_gnutls.c:346 #8 0x004993cc in tls_socket_open (conn=0x1d97b80) at ../mutt_ssl_gnutls.c:162 #9 0x00496eb2 in mutt_socket_open (conn=0x1d97b80) at ../mutt_socket.c:66 #10 0x004a1a04 in imap_open_connection (idata=0x1d92db0) at ../../imap/imap.c:407 #11 0x004a1d3d in imap_conn_find (account=0x7fff8db13570, flags=value optimized out) at ../../imap/imap.c:371 #12 0x004a2df9 in imap_get_mailbox (path=0x1d906c0 imaps://usern...@imap.oeko.net/INBOX, hidata=0x7fff8db14308, buf=0x7fff8db13f00 \377\377\377\377, blen=value optimized out) at ../../imap/imap.c:1456 #13 0x004a2f95 in imap_buffy_check (force=value optimized out) at ../../imap/imap.c:1498 #14 0x0040fb25 in mutt_buffy_check (force=1) at ../buffy.c:458 #15 0x0042039a in mutt_index_menu () at ../curs_main.c:460 #16 0x0043d4a1 in main (argc=1, argv=0x7fff8db159e8) at ../main.c:1026 The same problem happens with mutt-patched on squeeze (also amd64), but it doesn't happen on squeeze with mutt-patched on i386. Kind regards, --Toni++ -- System Information: Debian Release: 6.0.2 APT prefers stable APT policy: (990, 'stable'), (450, 'testing'), (250, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 3.0.0-rc6-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/bash Versions of packages mutt-patched depends on: ii libc6 2.11.2-10Embedded GNU C Library: Shared lib ii libcomerr2 1.41.12-4stable1 common error description library ii libgnutls26 2.8.6-1 the GNU TLS library - runtime libr ii libgpg-error0 1.6-1library for common error values an ii libgpgme11 1.2.0-1.2GPGME - GnuPG Made Easy ii libgssapi-krb5-21.8.3+dfsg-4squeeze1 MIT Kerberos runtime libraries - k ii libidn111.15-2 GNU Libidn library, implementation ii libk5crypto31.8.3+dfsg-4squeeze1 MIT Kerberos runtime libraries - C ii libkrb5-3 1.8.3+dfsg-4squeeze1 MIT Kerberos runtime libraries ii libncursesw55.7+20100313-5 shared libraries for terminal hand ii libsasl2-2 2.1.23.dfsg1-7 Cyrus SASL - authentication abstra ii libtokyocabinet81.4.37-6 Tokyo Cabinet Database Libraries [ ii mutt1.5.21-4~bpo60+1 text-based mailreader supporting M mutt-patched recommends no packages. mutt-patched suggests no packages. -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#638147: rsyslog: lost microseconds in timestamps
tags 638147 + confirmed forwarded 638147 http://bugzilla.adiscon.com/show_bug.cgi?id=281 thanks Am 17.08.2011 07:45, schrieb Kenyon Ralph: Package: rsyslog Version: 5.8.3-1 Severity: normal When I enable high-precision timestamps by commenting the line #$ActionFileDefaultTemplate RSYSLOG_TraditionalFileFormat in /etc/rsyslog.conf, I only get high-precision timestamps on messages that the kernel logs. The rest of logged messages only have 1-second precision. In the squeeze and previous versions of rsyslog, simply commenting the above line would give high-precision timestamps. I don't see anything in the changelog that indicates this should have changed. Examples: 2011-08-16T21:15:54.085150-07:00 gauss kernel: [ 17.369462] ppdev: user-space parallel port driver 2011-08-16T21:15:54-07:00 gauss racoon: INFO: 127.0.0.1[500] used as isakmp port (fd=6) Thanks for the bug report. I can reproduce the issue and have forwarded it upstream. Cheers, Michael -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? signature.asc Description: OpenPGP digital signature
Bug#604895: please add SNMP module output support for rsyslog
tags 604895 + wontfix thanks Am 21.02.2011 13:44, schrieb Michael Biebl: Am 25.11.2010 08:47, schrieb Raphaël 'SurcouF' Bordet: Can you add support for SNMP output module for rsyslog ? This support just need to add libsnmp-dev to build-deps and --enable-snmp options to configure. Unfortunately it is not as simple as that. libsnmp links against openssl which makes it not possible for rsyslog to use libsnmp, unless all (GPL) libraries rsyslog links against would have an openssl exemption. See [1] for more details. Michael [1] http://people.gnome.org/~markmc/openssl-and-the-gpl.html Marking it wontfix for now because of this issue. -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? signature.asc Description: OpenPGP digital signature
Bug#639855: snoopy: Some package history has been lost
Package: snoopy Version: 1.8.0-2 Severity: important It seems that during the handoff the new maintainer, something weird happened regarding the package's history. More specifically, debian/changelog lists version 1.8.0-1 with the previous changelog entry being 1.3-13. However, lenny included 1.3-15, with -14, -14.1 and -15 including various fixes, some of them being re-done in 1.8.0-1 (like the removal of linda overrides). What's worse, though, is that most were not, resulting in having the current version missing various fixes, mostly translations (a *lot* of them). What's *even* worse, is that someone did the Russian translation back then (#488133), it was uploaded with -14.1, was dropped with the handoff and someone did it *again*, from scratch, for the latest version (#637754), wasting the efforts of the translators. You can also see the effects of this on the BTS' graphs where you can easily see the fork to the two versions and how bugs are still open on the current version, although resolved/archived. Regards, Faidon -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#639341: dh: cannot override binary-arch and binary-indep selectively
On Tue, Aug 30, 2011 at 05:59:21PM -0400, Joey Hess wrote: Yann Dirson wrote: I tried things like: build-arch: dh_auto_build -a docbook-to-man debian/tulip.sgml debian/tulip.1 You're not running dh_auto_configure which dh would normally run here. Why not just run dh build-arch in the build-arch target? Ah, I think I'm starting to understand the big picture - that seems to be OK for build-arch. Now I'm still unclear about build-indep. The original package (3.6.0dfsg-1) does not separate them, and uses: |override_dh_auto_build: |build-arch: | dh_auto_build | dh_auto_build -- doc | docbook-to-man debian/tulip.sgml debian/tulip.1 Intuitively, I'd like to use something like the following, which does not appear to be possible AFAIU: |override_dh_auto_build_indep: | dh_auto_build -- doc And something similar is going to happen with install, with the following I'd like to split in a similar way: |override_dh_auto_install: | dh_auto_install | dh_auto_install -- -C docs What do you think ? -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#639712: [Pkg-lyx-devel] Bug#639712: elyxer: Croaks when I use --title with non-ascii characters
On Mon, Aug 29, 2011 at 6:12 PM, Torquil Macdonald Sørensen torq...@gmail.com wrote: Package: elyxer Version: 1.2.2-1 Severity: normal Hi! When I use the --title option together with non-ascii characters, elyxer fails. I get the following error message: Reproduced, thanks! I will add a test case, try to solve it and release an updated version ASAP. Alex. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#639737: xserver-xorg-video-nvidia: Please update ABI compatibility and add abi 11 for video
On Tuesday 30 August 2011 15:54:41 Eric Valette wrote:
On 08/30/2011 03:45 PM, Julien Cristau wrote:
On Mon, Aug 29, 2011 at 21:35:46 +0200, Eric Valette wrote:
Package: xserver-xorg-video-nvidia
Version: 285.03-1
Severity: normal
The new .11 xorg driver ABI has been updated to 11. As the nvidia driver
supports it at least enough to be useable via kde4, please add the
xorg-video-abi- compatibility.
There's a known issue with nvidia's libglx with that version, so I'm not
sure it's a good idea quite yet.
http://lists.x.org/pipermail/xorg-devel/2011-August/024752.html
I broke my X system with a bogus dist-upgrade and was forced to
reinstall libglx and nvidei xorg driver :-(
Hi,
I did a safe-upgrade, which upgraded nvidia-graphics-drivers to 280.13-2, and
after reboot, X didn't
start (properly).
In /var/log/Xorg.0.log I found a/the message about mismatching ABI version.
Since I'm subscribed to this list, I was aware of a potential problem (hence
the reboot) and
therefor was able to quickly find the relevant bug report (639737).
That bug report describes how to fix/workaround it ('therefore the IgnoreABI
option needs to be
enabled, see xorg.conf(5)'). (Haven't tried if it worked yet)
I do have apt-listbugs installed, but since this bug was/is severity normal
(and marked as done)
I didn't get a warning or sth like that.
I got X working again by downgrading (and holding) to the testing versions of
nvidia-kernel-dkms and
xserver-xorg-video-nvidia which caused those and related packages to be
downgraded:
partly snippet from /var/log/aptitude:
=
[DOWNGRADE] libgl1-nvidia-glx 280.13-2 - 280.13-1
[DOWNGRADE] nvidia-alternative 280.13-2 - 280.13-1
[DOWNGRADE] nvidia-glx 280.13-2 - 280.13-1
[DOWNGRADE] nvidia-vdpau-driver 280.13-2 - 280.13-1
[DOWNGRADE] xserver-xorg-core 2:1.11.0-1 - 2:1.10.4-1
[DOWNGRADE] xserver-xorg-input-evdev 1:2.6.0-2+b2 - 1:2.6.0-2+b1
[DOWNGRADE] xserver-xorg-video-nvidia 280.13-2 - 280.13-1
[DOWNGRADE] xserver-xorg-video-vesa 1:2.3.0-7+b1 - 1:2.3.0-7
[HOLD] nvidia-kernel-dkms
=
But if I wasn't subscribed to this list, I probably wouldn't have found this
bug report and therefor
wouldn't have found the workaround.
And since this bug is closed and doesn't (didn't) have a high enough severity,
apt-listbug didn't
issue a warning that the upgrade would make X stop working and/or alerted me to
the bug report
describing the workaround.
Shouldn't there be a warning or sth like that mentioning the workaround when
upgrading to 280.13-2?
And/or shouldn't this bug be reopened (or sth like that) with a higher
severity, so ppl with apt-
listbug will get notified and prevents the current version from entering
testing?
Regards,
Diederik
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#639856: xf86-video-glamo: please consider enabling armhf
Package: xf86-video-glamo
Version: 0.0.0+20100630.git16af3c00-3
Severity: normal
Tags: patch
Hello,
Please consider enabling armhf in debian/control file.
diff -Nru xf86-video-glamo-0.0.0+20100630.git16af3c00/debian/changelog
xf86-video-glamo-0.0.0+20100630.git16af3c00/debian/changelog
--- xf86-video-glamo-0.0.0+20100630.git16af3c00/debian/changelog
2011-06-04 22:15:14.0 +0100
+++ xf86-video-glamo-0.0.0+20100630.git16af3c00/debian/changelog
2011-08-31 00:37:23.0 +0100
@@ -1,3 +1,9 @@
+xf86-video-glamo (0.0.0+20100630.git16af3c00-4) unstable; urgency=low
+
+ * Add armhf support
+
+ -- Hector Oron zu...@debian.org Wed, 31 Aug 2011 00:37:05 +0100
+
xf86-video-glamo (0.0.0+20100630.git16af3c00-3) unstable; urgency=low
* Source format: 3.0 (quilt)
diff -Nru xf86-video-glamo-0.0.0+20100630.git16af3c00/debian/control
xf86-video-glamo-0.0.0+20100630.git16af3c00/debian/control
--- xf86-video-glamo-0.0.0+20100630.git16af3c00/debian/control 2011-06-03
13:03:04.0 +0100
+++ xf86-video-glamo-0.0.0+20100630.git16af3c00/debian/control 2011-08-31
00:36:54.0 +0100
@@ -10,7 +10,7 @@
Vcs-Browser: http://git.debian.org/?p=pkg-fso/xf86-video-glamo.git;a=summary
Package: xserver-xorg-video-glamo
-Architecture: amd64 armel i386
+Architecture: amd64 armel armhf i386
Depends: ${shlibs:Depends}, ${misc:Depends}, ${xviddriver:Depends}
Provides: ${xviddriver:Provides}
Description: X.Org X server -- SMedia Glamo display driver
With best regards,
-- Hector Oron
-- System Information:
Debian Release: wheezy/sid
APT prefers unstable
APT policy: (500, 'unstable'), (500, 'stable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Kernel: Linux 2.6.32-5-amd64 (SMP w/2 CPU cores)
Locale: LANG=ca_ES.UTF-8, LC_CTYPE=ca_ES.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#639857: nvidia-cg-toolkit: Fails to install with libc6 (= 2.13-17)
Package: nvidia-cg-toolkit Version: 2.1.0017.deb1+nmu3 Severity: important Dear Maintainer, Recently I noticed that with libc6 (= 2.13-17), the amd64 version of this package fails to completely install with the following error: Installing NVIDIA Cg Toolkit components: Cg compiler, header files, libraries, Failed to copy file /tmp/HI3zhWHHMr/usr/lib64/libCg.so to /usr/lib64/libCg.so: No such file or directory at /usr/bin/nvidia-cg-toolkit-installer line 321. The problem is that libc6 removed the /usr/lib64 symlink that was used by the nvidia-cg-toolkit-installer script. The package is then left in an inconsistent state since some files like the headers seem to get installed but the libraries and other files don't get installed while the file is marked as installed by dpkg. The i386 version seems to still install fine. Cheers, Miguel -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#639858: xserver-xorg-video-tga: Please add armhf support in architecture list
Package: xserver-xorg-video-tga
Version: 1:1.2.1-4+b1
Severity: normal
Tags: patch
Hello,
Please consider adding armhf to list of supported architectures in
debian/control:
Perhaps Architecture: any ?
sparc, kfreebsd-amd64, sh4, ... seem to be missing
diff -u xserver-xorg-video-tga-1.2.1/debian/control
xserver-xorg-video-tga-1.2.1/debian/control
--- xserver-xorg-video-tga-1.2.1/debian/control
+++ xserver-xorg-video-tga-1.2.1/debian/control
@@ -22,7 +22,7 @@
Vcs-Browser:
http://git.debian.org/?p=pkg-xorg/driver/xserver-xorg-video-tga.git
Package: xserver-xorg-video-tga
-Architecture: alpha amd64 arm armeb armel hppa hurd-i386 i386 ia64
kfreebsd-i386 m68k mips mipsel netbsd-i386 powerpc
+Architecture: alpha amd64 arm armeb armel armhf hppa hurd-i386 i386 ia64
kfreebsd-i386 m68k mips mipsel netbsd-i386 powerpc
Depends:
${shlibs:Depends},
${misc:Depends},
diff -u xserver-xorg-video-tga-1.2.1/debian/changelog
xserver-xorg-video-tga-1.2.1/debian/changelog
--- xserver-xorg-video-tga-1.2.1/debian/changelog
+++ xserver-xorg-video-tga-1.2.1/debian/changelog
@@ -1,3 +1,9 @@
+xserver-xorg-video-tga (1:1.2.1-5) unstable; urgency=low
+
+ * Add armhf support
+
+ -- Hector Oron zu...@debian.org Wed, 31 Aug 2011 00:50:22 +0100
+
xserver-xorg-video-tga (1:1.2.1-4) unstable; urgency=low
* Switch to dh:
With best regards,
-- Hector Oron
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#638654: configure.in
I would appreciate it if you could write a patch for configure.in to check for the version. I've already put an ifdef around the code in question, but it'll still get a useless link. Thanks. -- My Main Blog http://etbe.coker.com.au/ My Documents Bloghttp://doc.coker.com.au/ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#639815: libfile-slurp-perl: Newer upstream versions and sub-optimal debian/watch file
On Tue, 30 Aug 2011 16:34:14 +0200, gregor herrmann writes: I guess the releases went unnoticed because the watch file contains an author-specific URL, and the maintainer seems to have changed. sorry for that; file-slurp has changed upstream a few times now and this time i missed it. watch file updated, upload is on the way. regards az -- + Alexander Zangerl + DSA 42BD645D + (RSA 5B586291) REAL*8 RESPONSE(8) DATA /RESPONSE/ 8HYOU EVER,8H DONE IT,8H IN FORT,8HRAN IV?$ -- Peter da Silva about the joys of string handling signature.asc Description: Digital Signature
Bug#639859: apt-build fails to build packages ; it conflicts with apt
Package: apt-build Version: 0.12.38 Severity: grave Tags: sid wheezy patch Justification: renders package unusable Trying to install a package with apt-build, for example: # apt-build install hello it fails with: W: Failed to fetch file:/var/cache/apt-build/repository/dists/apt-build/Release Unable to find expected entry 'main/binary-amd64/Packages' in Release file (Wrong sources.list entry or malformed file) E: Some index files failed to download. They have been ignored, or old ones used instead. Reading package lists... Done E: The value 'apt-build' is invalid for APT::Default-Release as such a release is not available in the sources Subsequently, 'apt-get update' gives: W: Failed to fetch file:/var/cache/apt-build/repository/dists/apt-build/Release Unable to find expected entry 'main/binary-amd64/Packages' in Release file (Wrong sources.list entry or malformed file) E: Some index files failed to download. They have been ignored, or old ones used instead. I erased /var/cache/apt-build and applied the following patch to get rid of this problem: --- diff -Naur apt-build-0.12.38.orig/apt-build apt-build-0.12.38/apt-build --- apt-build-0.12.38.orig/apt-build2008-07-01 08:29:43.0 +0200 +++ apt-build-0.12.38/apt-build 2011-08-30 23:55:39.0 +0200 @@ -101,9 +101,9 @@ update-source - Update all sources and rebuild them remove- Remove packages build-repository - Rebuild the repository - clean-sources - Clean up all object files in source directories clean-build - Erase downloaded packages and temporary build files - clean-repository - Erase downloaded packages and temporary build files + clean-repository - Erase built packages + clean-sources - Clean up all object files in source directories world - Rebuild and reinstall all packages on your system info - Build-related package information @@ -337,10 +337,10 @@ chdir $conf-repository_dir; my $arch = $_config-get(APT::Architecture); -system ln -s . main unless -e main; -system ln -s . apt-build unless -e apt-build; -system ln -s . dists unless -e dists; -system ln -s . binary-$arch unless -e binary-$arch; +system mkdir dists unless -e dists; +system mkdir dists/apt-build unless -e dists/apt-build; +system mkdir dists/apt-build/main unless -e dists/apt-build/main; +system ln -s ../../.. dists/apt-build/main/binary-$arch unless -e dists/apt-build/main/binary-$arch; make_release_file() unless -e Release; system apt-ftparchive packages . | gzip -9 Packages.gz; diff -Naur apt-build-0.12.38.orig/debian/postinst apt-build-0.12.38/debian/postinst --- apt-build-0.12.38.orig/debian/postinst 2011-03-13 16:55:00.0 +0100 +++ apt-build-0.12.38/debian/postinst 2011-08-31 01:19:41.0 +0200 @@ -79,13 +79,8 @@ # Create repository_dir if [ ! -e $repository_dir ]; then - mkdir -p $repository_dir - cd $repository_dir - ln -s . stable - ln -s . dists - ln -s . apt-build - ln -s . main - ln -s . binary-`dpkg --print-architecture` + mkdir -p $repository_dir/dists/apt-build/main + ln -s ../../.. $repository_dir/dists/apt-build/main/binary-`dpkg --print-architecture` fi sed s/__arch__/`dpkg --print-architecture`/ /usr/share/apt-build/Release $repository_dir/Release --- Unfortunately, it doesn't solve the problem. apt-get update keeps saying: E: The value 'apt-build' is invalid for APT::Default-Release as such a release is not available in the sources Maybe an apt bug rather than an apt-build bug ? -- System Information: Debian Release: wheezy/sid APT prefers testing APT policy: (800, 'testing'), (750, 'stable'), (500, 'oldstable'), (50, 'experimental'), (50, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 3.0.0-1-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/bash Versions of packages apt-build depends on: ii apt 0.8.15.6 Advanced front-end for dpkg ii apt-utils 0.8.15.6 APT utility programs ii debconf [debconf-2.0] 1.5.40 Debian configuration management sy ii devscripts2.11.0 scripts to make the life of a Debi ii dpkg-dev 1.16.0.3 Debian package development tools ii g++ 4:4.6.1-2 GNU C++ compiler ii gcc 4:4.6.1-2 GNU C compiler ii libappconfig-perl 1.56-2 Perl module for configuration file ii libapt-pkg-perl 0.1.24+b2 Perl interface to libapt-pkg ii libc6 2.13-16Embedded GNU C Library: Shared
Bug#639712: [Pkg-lyx-devel] Bug#639712: Bug#639712: elyxer: Croaks when I use --title with non-ascii characters
On Wed, Aug 31, 2011 at 1:03 AM, Alex Fernandez ely...@gmail.com wrote: On Mon, Aug 29, 2011 at 6:12 PM, Torquil Macdonald Sørensen torq...@gmail.com wrote: Package: elyxer Version: 1.2.2-1 Severity: normal Hi! When I use the --title option together with non-ascii characters, elyxer fails. I get the following error message: Reproduced, thanks! I will add a test case, try to solve it and release an updated version ASAP. Verified, solved and tested in commit: http://git.savannah.gnu.org/cgit/elyxer.git/commit/?id=74176b11cc823bcace0bee1ceb764b6db537e1fb I have just released an (overdue anyway) new version to solve the bug, 1.2.3. It would be nice if you could test if it solves the bug. Thanks, Alex. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#639860: open-vm-tools: vmware-toolbox and vmware-user binaries are missing
Package: open-vm-tools Version: 2:8.4.2+2011.08.21-471295-1 Severity: grave Justification: renders package unusable The new open-vm-tools package omits, ironically, the vmware tools. Specifically, at the very least, /usr/bin/vmware-toolbox /usr/bin/vmware-user are missing. Without the ability to control the vmware tools, there's not much point in having them. -- System Information: Debian Release: wheezy/sid APT prefers unstable APT policy: (990, 'unstable') Architecture: i386 (i686) Kernel: Linux 3.0.0-1-686-pae (SMP w/1 CPU core) Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968) Shell: /bin/sh linked to /bin/bash Versions of packages open-vm-tools depends on: ii libc6 2.13-18Embedded GNU C Library: Shared lib ii libfuse2 2.8.5-4Filesystem in Userspace (library) pn libgcc1 none (no description available) ii libglib2.0-0 2.28.6-1 The GLib library of C routines ii libicu44 4.4.2-2International Components for Unico pn libstdc++6none (no description available) Versions of packages open-vm-tools recommends: ii ethtool 1:3.0-1 display or change Ethernet device ii open-vm-sour 2:8.4.2+2011.08.21-471295-1 Source for VMware guest systems dr ii zerofree 1.0.1-2 zero free blocks from ext2/3 file- Versions of packages open-vm-tools suggests: ii open-vm-tool 2:8.4.2+2011.08.21-471295-1 tools and components for VMware gu -- Configuration Files: /etc/vmware-tools/tools.conf changed: /etc/xdg/autostart/vmware-user.desktop [Errno 2] No such file or directory: u'/etc/xdg/autostart/vmware-user.desktop' -- 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#615998: linux-image-2.6.32-5-xen-amd64: Repeatable kernel BUG at fs/jbd2/commit.c:534 from Postfix on ext4
On Aug 30, 2011, at 18:12, Jan Kara wrote: On Fri 26-08-11 16:03:32, Moffett, Kyle D wrote: Ping? Any more ideas for debugging this issue? Sorry for not getting to you earlier. That's ok, I have a workaround so it's been on my back burner for a while. I can still trigger it on my VM snapshot very easily, so if you have anything you think I should test I would be very happy to give it a shot. OK, so in the meantime I found a bug in data=journal code which could be related to your problem. It is fixed by commit 2d859db3e4a82a365572592d57624a5f996ed0ec which is in 3.1-rc1. Have you tried that or newer kernel as well? If the problem still is not fixed, I can provide some debugging patch to you. We spoke with Josef Bacik how errors like yours could happen so I have some places to watch... I have not tried anything more recent; I'm actually a bit reluctant to move away from the Debian squeeze official kernels since I do need the security updates. I took a quick look and I can't find that function in 2.6.32, so I assume it would be a rather nontrivial back-port. It looks like the relevant code used to be in ext4_clear_inode somewhere? Out of curiosity, what would happen in data=journal mode if you unlinked a file which still had buffers pending? That case does not seem to be handled by that commit you mentioned, was it already handled elsewhere? Thanks again! Cheers, Kyle Moffett -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#639856: [pkg-fso-maint] Bug#639856: xf86-video-glamo: please consider enabling armhf
On Wed, Aug 31, 2011 at 01:45:01AM +0200, Hector wrote: Package: xf86-video-glamo [...] Please consider enabling armhf in debian/control file. Hi Hector, Do you know any armv7 system, which uses the glamo? I only know of two devices having a glamo graphic chip: Openmoko GTA01 and Openmoko GTA02 (also known as Freerunner). Both of them are armv5 based. -- Sebastian signature.asc Description: Digital signature
Bug#639861: xserver-xorg-video-nouveau: no backlight control for NV34 (GeForce 5200) on PPC
Package: xserver-xorg-video-nouveau Version: 1:0.0.16+git20110411+8378443-1+b1 Severity: normal There is no control of the backlight with the nouveau drivers on a 12 Aluminium G4 PowerBook (PPC). /sys/class/backlight/ is empty. I believe this is why hibernation using the kernel's built-in facility isn't working for me - the laptop does resume but the backlight, which is switched off before shutdown, cannot be restarted and there is no manual control of this, brightness etc. Before switching to nouveau, I did have control of the backlight. (Unusable graphics but I could display them at any brightness!) That was with an earlier kernel but makes me think this is specific to nouveau. (Definitely not a hardware issue as works under OS X.) This machine has a nVIDIA GeForce FX Go5200 graphics card with AGP bus, 64MB vram and 32 bit colour. -- Package-specific info: X server symlink status: lrwxrwxrwx 1 root root 13 Apr 25 00:39 /etc/X11/X - /usr/bin/Xorg -rwxr-xr-x 1 root root 1876124 Aug 24 10:56 /usr/bin/Xorg VGA-compatible devices on PCI bus: -- :00:10.0 VGA compatible controller [0300]: nVidia Corporation NV34M [GeForce FX Go5200] [10de:0329] (rev a1) /etc/X11/xorg.conf does not exist. /etc/X11/xorg.conf.d does not exist. /etc/modprobe.d contains no KMS configuration files. Kernel version (/proc/version): --- Linux version 3.0.0-1-powerpc (Debian 3.0.0-1) (b...@decadent.org.uk) (gcc version 4.5.3 (Debian 4.5.3-3) ) #1 Sun Jul 24 13:59:10 UTC 2011 Xorg X server log files on system: -- -rw-r--r-- 1 root root 28135 Jul 5 23:11 /var/log/Xorg.1.log -rw-r--r-- 1 root root 28992 Aug 30 23:21 /var/log/Xorg.0.log Contents of most recent Xorg X server log file (/var/log/Xorg.0.log): - [24.932] X.Org X Server 1.10.4 Release Date: 2011-08-19 [24.932] X Protocol Version 11, Revision 0 [24.932] Build Operating System: Linux 2.6.32-5-powerpc64 ppc Debian [24.932] Current Operating System: Linux CyfrifiadurCFR 3.0.0-1-powerpc #1 Sun Jul 24 13:59:10 UTC 2011 ppc [24.932] Kernel command line: root=UUID=18970ccd-6bfd-482f-9474-e15f7894edf4 ro video=nvidiafb:off [24.932] Build Date: 24 August 2011 09:38:35AM [24.932] xorg-server 2:1.10.4-1 (Cyril Brulebois k...@debian.org) [24.932] Current version of pixman: 0.22.2 [24.932]Before reporting problems, check http://wiki.x.org to make sure that you have the latest version. [24.932] Markers: (--) probed, (**) from config file, (==) default setting, (++) from command line, (!!) notice, (II) informational, (WW) warning, (EE) error, (NI) not implemented, (??) unknown. [24.933] (==) Log file: /var/log/Xorg.0.log, Time: Tue Aug 30 23:06:14 2011 [24.966] (==) Using system config directory /usr/share/X11/xorg.conf.d [24.989] (==) No Layout section. Using the first Screen section. [24.989] (==) No screen section available. Using defaults. [24.989] (**) |--Screen Default Screen Section (0) [24.989] (**) | |--Monitor default monitor [24.989] (==) No monitor specified for screen Default Screen Section. Using a default monitor configuration. [24.989] (==) Automatically adding devices [24.990] (==) Automatically enabling devices [25.057] (WW) The directory /usr/share/fonts/X11/cyrillic does not exist. [25.057]Entry deleted from font path. [25.149] (==) FontPath set to: /usr/share/fonts/X11/misc, /usr/share/fonts/X11/100dpi/:unscaled, /usr/share/fonts/X11/75dpi/:unscaled, /usr/share/fonts/X11/Type1, /usr/share/fonts/X11/100dpi, /usr/share/fonts/X11/75dpi, /var/lib/defoma/x-ttcidfont-conf.d/dirs/TrueType, built-ins [25.149] (==) ModulePath set to /usr/lib/xorg/modules [25.149] (II) The server relies on udev to provide the list of input devices. If no devices become available, reconfigure udev or disable AutoAddDevices. [25.149] (II) Loader magic: 0x101d6af8 [25.149] (II) Module ABI versions: [25.149]X.Org ANSI C Emulation: 0.4 [25.149]X.Org Video Driver: 10.0 [25.149]X.Org XInput driver : 12.2 [25.149]X.Org Server Extension : 5.0 [25.151] (--) PCI:*(0:0:16:0) 10de:0329:10de:0010 rev 161, Mem @ 0x9100/16777216, 0xa000/134217728, BIOS @ 0x/131072 [25.151] (II) LoadModule: extmod [25.208] (II) Loading /usr/lib/xorg/modules/extensions/libextmod.so [25.219] (II) Module extmod: vendor=X.Org Foundation [25.219]compiled for 1.10.4, module version = 1.0.0 [25.219]Module class: X.Org Server Extension [25.219]ABI class: X.Org Server Extension, version 5.0 [25.219] (II) Loading extension SELinux [25.219] (II) Loading extension MIT-SCREEN-SAVER [25.219] (II) Loading extension
Bug#608512: icedove-3.0.11: Error getting mail password.
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hello, As the problem still persists with the newest version of thunderbird (icedove 3.1.12-1) I searched again for a solution to finally unpin the icedove package. The migration assistant incorrectly replaced my username with an empty string as it contains an umlaut. To make mail fetching work again the empty string has to be filled in once more. Edit-Preferences-Advanced-Config Editor-Filter: username ... mail.server.server1.userName The new value can again contain umlauts as only the migration assistant, but not icedove in general seems to have problems with non ascii-characters. Source: http://getsatisfaction.com/mozilla_messaging/topics/_error_getting_mail_password Regards, Karl -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk5diGAACgkQu9bAvV0An+nEWQCfTsWT7AcawtdH3jdgHE0ZM1wT FdUAnjeulXVB8TbG9b/BXLWcSLa7m//m =+V6D -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#638932: [Evolution] Bug#638932: evolution: Folder sent doesn't missing.
It's NOT a bug, I SOLVED it with the following command: mkdir /home/mohsen/.local/share/evolution/mail/local/send On Wed, Aug 24, 2011 at 4:32 PM, Yves-Alexis Perez cor...@debian.org wrote: On mer., 2011-08-24 at 15:38 +0430, Mohsen Pahlevanzadeh wrote: From my own email account : moh...@pahlevanzadeh.org. Then check in that account properties (“Defaults” tab) where does it want to save sent messages. -- Yves-Alexis -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#639862: Patch to build using c++0x
Package: libboost-mpi1.46-dev Version: 1.46.1-7 Severity: normal File: boost Tags: upstream - Forwarded message from Christophe Prud'homme prudh...@debian.org - Date: Tue, 30 Aug 2011 14:51:40 +0200 From: Christophe Prud'homme prudh...@debian.org To: pkg-boost-de...@lists.alioth.debian.org Subject: [pkg-boost-devel] Fwd: miscompilation: boost.mpi, gcc 4.6 and c++0x Steve, I still haven't had any feedback concerning the issue with boost.mpi and gcc4.6 here what I just sent to boost devel list. could you add the attached patch please to 1.46 (it should apply to 1.47 without problems) ? Best regards C. -- Forwarded message -- From: Christophe Prud'homme prudh...@debian.org Date: Tue, Aug 30, 2011 at 2:34 PM Subject: miscompilation: boost.mpi, gcc 4.6 and c++0x To: bo...@lists.boost.org Dear Boost Developers I created the ticket [1] several month ago regarding an issue between g++-4.6 with option -std=c++0x and boost.mpi I haven't had any feedback yet. Any idea wether boost or gcc is at fault here ? it is easy to fix this by adding the right member function. �1. https://svn.boost.org/trac/boost/ticket/5538 let me recap what is going on consider the following code in t.cpp: #include boost/mpi.hpp compile it with g++ -std=c++0x -c -I/usr/include/mpi t.cpp and you get in Debian unstable In file included from /usr/include/c++/4.6/memory:67:0, � � � � � � � � from /usr/include/boost/mpi/allocator.hpp:18, � � � � � � � � from /usr/include/boost/mpi.hpp:22, � � � � � � � � from t.cpp:1: /usr/include/c++/4.6/bits/stl_uninitialized.h: In function 'void std::__uninitialized_default_n_a(_ForwardIterator, _Size, _Allocator) [with _ForwardIterator = char*, _Size = long unsigned int, _Allocator = boost::mpi::allocatorchar]': /usr/include/c++/4.6/bits/vector.tcc:474:8: � instantiated from 'void std::vector_Tp, _Alloc::_M_default_append(std::vector_Tp, _Alloc::size_type) [with _Tp = char, _Alloc = boost::mpi::allocatorchar, std::vector_Tp, _Alloc::size_type = long unsigned int]' /usr/include/c++/4.6/bits/stl_vector.h:592:4: � instantiated from 'void std::vector_Tp, _Alloc::resize(std::vector_Tp, _Alloc::size_type) [with _Tp = char, _Alloc = boost::mpi::allocatorchar, std::vector_Tp, _Alloc::size_type = long unsigned int]' /usr/include/boost/mpi/detail/packed_oprimitive.hpp:96:46: instantiated from here /usr/include/c++/4.6/bits/stl_uninitialized.h:576:6: error: no matching function for call to 'boost::mpi::allocatorchar::construct(char*)' /usr/include/c++/4.6/bits/stl_uninitialized.h:576:6: note: candidate is: /usr/include/boost/mpi/allocator.hpp:168:8: note: void boost::mpi::allocatorT::construct(boost::mpi::allocatorT::pointer, const T) [with T = char, boost::mpi::allocatorT::pointer = char*] /usr/include/boost/mpi/allocator.hpp:168:8: note: � candidate expects 2 arguments, 1 provided note that if you remove -std=c++0x, it compiles fine. Best regards C. -- Debian Developer - member of Debian Science http://wiki.debian.org/DebianScience Prof. at Univ. Grenoble in Applied Math. http://ljk.imag.fr/membres/Christophe.Prudhomme/ -- Debian Developer - member of Debian Science http://wiki.debian.org/DebianScience Prof. at Univ. Grenoble in Applied Math. http://ljk.imag.fr/membres/Christophe.Prudhomme/ ___ pkg-boost-devel mailing list pkg-boost-de...@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-boost-devel - End forwarded message - -- System Information: Debian Release: wheezy/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 3.0.0-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 libboost-mpi1.46-dev depends on: ii libboost-mpi1.46.1 1.46.1-7 ii libboost-serialization1.46-dev 1.46.1-7 ii libboost1.46-dev1.46.1-7 ii mpi-default-dev 0.6 libboost-mpi1.46-dev recommends no packages. Versions of packages libboost-mpi1.46-dev suggests: ii libboost-graph1.46-dev 1.46.1-7 -- 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#592085: debsums: excessive cpu use after update of package(s) via aptitude
Ryan Niebur wrote, on 31/08/11 05:22: Hi Arthur, On Sat, Aug 07, 2010 at 11:08:52PM +0930, Arthur Marsh wrote: Package: debsums Version: 2.0.48+nmu1 Severity: normal After updating a single small package (subnetcalc) on this machine with aptitude, debsums consumed 3 minutes of cpu time. Surely it shouldn't take 3 minutes of cpu time to calculate the changed md5 sums as a result of updating one small package? Yes, that is odd. I compared situations where debsums is disabled, debsums is doing nothing, and debsums is generating md5sums for a single package (including subnetcalc). I've tried using apt-get and aptitude. My results were pretty much the same between those different situations. Was this the first install you made after enabling debsums? If so it would have generated missing md5sums for everything it could find a .deb file for in your apt cache, so that could explain it taking a little bit longer than expected. That probably isn't a good enough explanation, though, because I also removed the md5sums files of 7 packages that were still in my apt cache, ran the debsums hook manually, and compared the timing. It made a difference of a second or two. And all of these tests were on a pretty old 500 MHz P3 machine, so I don't think it had any advantages. Can you still reproduce this problem? If so, can you think of anything that would lead to an explanation of why it takes longer on your machine? I'm not sure what else I can try to reproduce the problem. I'll let you know if I come up with any successful ideas, though. Cheers, Ryan Thanks for the investigation. My guess is that due to this machine having prelink installed, debsums was having to reverse the prelink process for a large number of binaries in order to correct the correct md5sums. Regards, Arthur. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#487201: MPL in common-licenses and convenience of packaging mozilla extensions
Ximin Luo infini...@gmx.com writes: On 29/08/11 17:48, Russ Allbery wrote: The project decided to say that our packages are intended for use on a Debian system with the essential Debian packages installed and hence not duplicate licenses that are in base-files, which I think is a bit of a hand-wave, but which lets us avoid shipping 20,000 copies of the GPL. The legal requirements are generally quite clear, and the ideal legal position to be in is inclusion of relevant license texts in every package so that the individual object that we distribute is legally complete. OK, this is understandable. I suppose we can't get around the fact that each source package should have the full text of a license. And every binary package. They're usually the same case as far as legal requirements go, and it's definitely possible to download the binary packages as independent distributions from the source packages. However, this doesn't mean that we must include them in debian/copyright specifically - is this restriction really necessary for policy? (I know this is off-topic for the bug but it's a continuation of the discussion.) You don't need to include them in debian/copyright in the source package, but you normally need to arrange for them to end up in the copyright file in the binary package, and that's probably the easiest way. Now, this is not true of all licenses. Some licenses don't require inclusion of the licensing terms in the binary package; the MPL is one of them, in fact. But nearly all of them do, so it's a good default to stick with. I suppose we could have a separate discussion about whether to make special rules for the licenses like the MPL that don't require this. It would be less trouble if you could point to license files. See, for example, the GPL v3: 4. Conveying Verbatim Copies. You may convey verbatim copies of the Program's source code as you receive it, in any medium, provided that you [...] give all recipients a copy of this License along with the Program. and: 6. Conveying Non-Source Forms. You may convey a covered work in object code form under the terms of sections 4 and 5, provided that [...] So it's up to a legal interpretation of the term give all recipients a copy of this License along with the Program. Obviously, including the license in the package satisfies this trivially without requiring anyone to think about it or get a legal opinion. Debian has concluded that shipping a copy of the license in common-licenses and including a pointer to it in each package is sufficient in this case (although I'm a little leery of whether Debian really sought legal advice on this point before including additional licenses in common-licenses). It would also support more powerful automation tools. For example, we can have a dh script dereference these pointers and install all the license texts into the package's /doc/. And maybe have a licenses-helper program which could detect dangling pointers, and fill the common ones in automatically, to save the maintainer having to find them if they weren't included with upstream. Note that there are some substantial advantages to having all legal information in a single file, not just in terms of complexity and possible bugs in not including the right files, but also for ease of extracting that file and displaying it alongside the package or making it available independently from the package, which we already do in some cases (for QA purposes, for instance). -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#639824: ibus: new upstream version 1.3.99.20110817
Hi, Harshula Thanks. I will handle it this weekend. -- Best Regards, Asias He -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#635321: Unable to reproduce with soundtouch 1.6.0-1 or 1.6.0-2
Hello: Today I tried to reproduce this bug but I could not do it. I also could not find a change in soundtouch BPM routines from 1.5.0 to 1.6.0 that could have caused it. Here is a log of what I did but I cut out some of the verbose: $ apt-cache policy libsoundtouch0 | grep Installed Installed: 1.6.0-2 $ sudo apt-get install banshee -qq $ apt-cache policy banshee | grep Installed Installed: 2.0.1-4+b2 $ banshee [Info 21:06:18.659] Running Banshee 2.0.1: [Debian GNU/Linux unstable (sid) (linux-gnu, x86_64) @ 2011-08-28 13:30:52 UTC] snip $ sudo apt-get install -t experimental banshee -qq $ apt-cache policy banshee | grep Installed Installed: 2.1.3-1 $ banshee [Info 21:07:13.017] Running Banshee 2.1.3: [Debian GNU/Linux unstable (sid) (linux-gnu, x86_64) @ 2011-08-25 13:36:14 BST] snip $ rm -rf ~/.config/banshee-1/ I went to http://snapshot.debian.org/package/soundtouch/1.6.0-1/#libsoundtouch0_1.6.0-1 and installed the 1.6.0-1 as originally reported. $ sudo dpkg -i libsoundtouch0_1.6.0-1_amd64.deb $ sudo apt-get install banshee/sid -qq $ apt-cache policy libsoundtouch0 | grep Installed Installed: 1.6.0-1 $ apt-cache policy banshee | grep Installed Installed: 2.0.1-4+b2 $ banshee [Info 21:08:58.164] Running Banshee 2.0.1: [Debian GNU/Linux unstable (sid) (linux-gnu, x86_64) @ 2011-08-28 13:30:52 UTC] snip $ sudo apt-get install -t experimental banshee -qq $ apt-cache policy banshee | grep Installed Installed: 2.1.3-1 $ banshee [Info 21:09:59.268] Running Banshee 2.1.3: [Debian GNU/Linux unstable (sid) (linux-gnu, x86_64) @ 2011-08-25 13:36:14 BST] snip $ apt-cache policy libsoundtouch0 | grep Installed Installed: 1.6.0-1 $ apt-cache policy banshee | grep Installed Installed: 2.1.3-1 Both soundtouch 1.6.0-1 and 1.6.0-2 worked fine with Banshee from sid and experimental. For a final test I tried the version that was originally reported: $ rm -rf ~/.config/banshee-1/ $ sudo dpkg -i libgdata1.7-cil_1.7.0.1-1_all.deb banshee_2.1.0-1_amd64.deb libmtp8_1.0.6-7_amd64.deb $ banshee [Info 21:32:02.028] Running Banshee 2.1.0: [Debian GNU/Linux unstable (sid) (linux-gnu, x86_64) @ 2011-05-17 11:03:27 UTC] snip $ apt-cache policy libsoundtouch0 | grep Installed Installed: 1.6.0-1 $ apt-cache policy banshee | grep Installed Installed: 2.1.0-1 So the current 2.0.1, the reported 2.1.0-1 and the current version from experimental seem to work with a current and up to date system. I guess that there was a different package that caused the original crash and that package got updated again and the original issue was resolved. If the original submitter could confirm it would help. Hope this helps, Miguel -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#639863: shotwell: new upstream version (0.11.0) available
Package: shotwell
Version: 0.10.1-1
Severity: wishlist
Hi.
There is a new upstream version of shotwell available that contains some
good-to-have fixes. It would be nice to have it available, even in
experimental.
Thanks.
-- System Information:
Debian Release: wheezy/sid
APT prefers unstable
APT policy: (500, 'unstable'), (500, 'testing'), (500, 'stable'), (101,
'experimental')
Architecture: i386 (x86_64)
Kernel: Linux 3.0.0-1-amd64 (SMP w/2 CPU cores)
Locale: LANG=en_US.utf-8, LC_CTYPE=pt_BR.utf-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Versions of packages shotwell depends on:
ii dbus-x111.4.14-1
ii libatk1.0-0 2.0.1-2
ii libc6 2.13-18
ii libcairo2 1.10.2-6.1
ii libexif12 0.6.20-1
ii libexiv2-9 0.20-2.1
ii libfontconfig1 2.8.0-3
ii libfreetype62.4.6-2
ii libgcc1 1:4.6.1-8
ii libgconf2-4 2.32.4-1
ii libgdk-pixbuf2.0-0 2.23.5-3
ii libgee2 0.6.1-2
ii libgexiv2-0 0.2.2-5
ii libglib2.0-02.28.6-1
ii libgomp14.6.1-8
ii libgphoto2-22.4.11-3
ii libgphoto2-port02.4.11-3
ii libgstreamer0.10-0 0.10.35-1
ii libgtk2.0-0 2.24.5-4
ii libgudev-1.0-0 172-1
ii libjson-glib-1.0-0 0.13.4-2
ii libpango1.0-0 1.28.4-3
ii librsvg2-common 2.34.0-2
ii libsoup2.4-12.34.3-1
ii libsqlite3-03.7.7-2
ii libstdc++6 4.6.1-8
ii libunique-1.0-0 1.1.6-2
ii libusb-0.1-42:0.1.12-19
ii libwebkitgtk-1.0-0 1.4.2-2
ii libxml2 2.7.8.dfsg-4
shotwell recommends no packages.
shotwell suggests no packages.
-- no debconf information
--
Rogério Brito : rbrito@{ime.usp.br,gmail.com} : GPG key 4096R/BCFC
http://rb.doesntexist.org : Packages for LaTeX : algorithms.berlios.de
DebianQA: http://qa.debian.org/developer.php?login=rbrito%40ime.usp.br
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#193061: adopting lgeneral?
Hi, You mentioned you were planning to adopt lgeneral after squeeze's release and squeeze has been out for a couple of months now. I was just curious about the status of this. Thanks, Drew Daniels http://www.boxheap.net/ddaniels/blog -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#639744: Compromised certificates for *.google.com issued by DigiNotar Root CA
On Tuesday 30 August 2011 15:48:11 Mike Hommey wrote: On Tue, Aug 30, 2011 at 09:58:18PM +0200, Yves-Alexis Perez wrote: On mar., 2011-08-30 at 12:29 -0500, Raphael Geissert wrote: What I can't tell for sure from the documentation is whether OpenSSL and GnuTLS do check the CRL's validity (signature and time.) It doesn't seem like they do. This is relevant if we were to ship them in ca-certificates. Mike, without digging into the documentation I found this reference [2] regarding NSS and its CRL support. Do you know if any of what is said on that email has changed? namely how 'next update' dates are handled. [2]http://www.mail-archive.com/mozilla-crypto@mozilla.org/msg00890.html Yves, do you know how the CRL stuff is handled in nss? (my first name is Yves-Alexis :) Oops, sorry. Please accept my apologies. That being said, there is a huge problem with mitigation in basically all the SSL libraries. There simply is no way to handle the current situation[1] without modifying applications. [...] 1. Several fraudulent certificates whose fingerprint is unknown signed with several different intermediate certs that are cross-signed by other safe CAs (aiui). Oh. Well, first thing first, I've NMUed ca-certs to remove the DigiNotar Root CA and will probably release a DSA with the change too (I'm afraid it will give a false sense of security.) What is to be done next should probably be discussed in -devel and have input from external people. Cheers, -- Raphael Geissert - Debian Developer www.debian.org - get.debian.net -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#639744: Compromised certificates for *.google.com issued by DigiNotar Root CA
On Tue, Aug 30, 2011 at 10:48:11PM +0200, Mike Hommey wrote: On Tue, Aug 30, 2011 at 09:58:18PM +0200, Yves-Alexis Perez wrote: On mar., 2011-08-30 at 12:29 -0500, Raphael Geissert wrote: On Tuesday 30 August 2011 01:08:29 Yves-Alexis Perez wrote: On lun., 2011-08-29 at 20:24 -0700, Josh Triplett wrote: I understand that they'd have to manually load the lists, but perhaps it would make sense to standardize a location from which they should load them? Does OpenSSL or GnuTLS have any concept of a revocation store format, similar to a certificate store, or would this need some special-purpose custom format? AFAIR they only know about CRL (Certificate Revocation List,) which only allows for one issuer per-file. What I can't tell for sure from the documentation is whether OpenSSL and GnuTLS do check the CRL's validity (signature and time.) It doesn't seem like they do. This is relevant if we were to ship them in ca-certificates. And it'd be nice if nss could share that store... [...] By the way, shouldn't this bug be clone to libnss3-1d (and maybe iceweasel and icedove if they ship the certificates themselves)? Perhaps it's time to start a discussion as to how we can properly deal with all this mess: * Multiple packages shipping their own certificates list * Probably no app except web browsers support CRLs and/or OCSP * configuration Yves, do you know how the CRL stuff is handled in nss? (my first name is Yves-Alexis :) I have no idea. There's a crlutil (http://www.mozilla.org/projects/security/pki/nss/tools/crlutil.html) but it works on previous database version (bdb, cert8.db and key3.db) while at least evolution now uses the shared sqlite db (cert9.db and key4.db, see https://wiki.mozilla.org/NSS_Shared_DB). The NSS tools are supposed to work with whatever database version you use, since they use NSS ;) That being said, there is a huge problem with mitigation in basically all the SSL libraries. There simply is no way to handle the current situation[1] without modifying applications. Mike 1. Several fraudulent certificates whose fingerprint is unknown signed with several different intermediate certs that are cross-signed by other safe CAs (aiui). So, I'll put that on tiredness. That'd be several fraudulent certificates which fingerprint is unknown (thus even CRL, OCSP and blacklists can't do anything), and the mitigation involves several different intermediate certs that are cross-signed, which makes it kind of hard. Plus, there is the problem that untrusting the DigiNotar root untrusts a separate PKI used by the Dutch government. Add to the above that untrusting a root still allows users to override in applications, and we have no central way to not allow that. Aiui, the mozilla update is going to block overrides as well, but that involves the application side. NSS won't deal with that. Mike -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#639744: Compromised certificates for *.google.com issued by DigiNotar Root CA
On Wed, Aug 31, 2011 at 06:26:26AM +0200, Mike Hommey wrote: On Tue, Aug 30, 2011 at 10:48:11PM +0200, Mike Hommey wrote: On Tue, Aug 30, 2011 at 09:58:18PM +0200, Yves-Alexis Perez wrote: On mar., 2011-08-30 at 12:29 -0500, Raphael Geissert wrote: On Tuesday 30 August 2011 01:08:29 Yves-Alexis Perez wrote: On lun., 2011-08-29 at 20:24 -0700, Josh Triplett wrote: I understand that they'd have to manually load the lists, but perhaps it would make sense to standardize a location from which they should load them? Does OpenSSL or GnuTLS have any concept of a revocation store format, similar to a certificate store, or would this need some special-purpose custom format? AFAIR they only know about CRL (Certificate Revocation List,) which only allows for one issuer per-file. What I can't tell for sure from the documentation is whether OpenSSL and GnuTLS do check the CRL's validity (signature and time.) It doesn't seem like they do. This is relevant if we were to ship them in ca-certificates. And it'd be nice if nss could share that store... [...] By the way, shouldn't this bug be clone to libnss3-1d (and maybe iceweasel and icedove if they ship the certificates themselves)? Perhaps it's time to start a discussion as to how we can properly deal with all this mess: * Multiple packages shipping their own certificates list * Probably no app except web browsers support CRLs and/or OCSP * configuration Yves, do you know how the CRL stuff is handled in nss? (my first name is Yves-Alexis :) I have no idea. There's a crlutil (http://www.mozilla.org/projects/security/pki/nss/tools/crlutil.html) but it works on previous database version (bdb, cert8.db and key3.db) while at least evolution now uses the shared sqlite db (cert9.db and key4.db, see https://wiki.mozilla.org/NSS_Shared_DB). The NSS tools are supposed to work with whatever database version you use, since they use NSS ;) That being said, there is a huge problem with mitigation in basically all the SSL libraries. There simply is no way to handle the current situation[1] without modifying applications. Mike 1. Several fraudulent certificates whose fingerprint is unknown signed with several different intermediate certs that are cross-signed by other safe CAs (aiui). So, I'll put that on tiredness. That'd be several fraudulent certificates which fingerprint is unknown (thus even CRL, OCSP and blacklists can't do anything), and the mitigation involves several different intermediate certs that are cross-signed, which makes it kind of hard. Plus, there is the problem that untrusting the DigiNotar root untrusts a separate PKI used by the Dutch government. Add to the above that untrusting a root still allows users to override in applications, and we have no central way to not allow that. Aiui, the mozilla update is going to block overrides as well, but that involves the application side. NSS won't deal with that. See https://bugzilla.mozilla.org/show_bug.cgi?id=682927 which is now open. Mike -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#624354: Processed: Re: Bug#624354: ./xpcshell: error while loading shared libraries: ./libxul.so: R_PPC_REL24 relocation at 0x0f9f0148 for symbol `_restgpr_29_x' out of range
On Mon, Aug 29, 2011 at 06:48:49PM +0200, Michel Dänzer wrote: Fast forward four months... On Sam, 2011-04-30 at 20:04 +0200, Mike Hommey wrote: On Sat, Apr 30, 2011 at 12:00:41PM +0200, Mike Hommey wrote: On Thu, Apr 28, 2011 at 02:17:15PM +0200, Gabriel Paubert wrote: On Thu, Apr 28, 2011 at 12:10:54PM +0200, Mike Hommey wrote: On Thu, Apr 28, 2011 at 12:04:42PM +0200, Mike Hommey wrote: Let me write it again: - The R_PPC_REL24 relocations are all over libxul.so on objects that are built -fPIC. - libcrmf.a is also linked into libxul.so, and it also contains R_PPC_REL24 relocations, but all the objects it contains are built -fPIC. And this is a -Os bug, apparently. Building with -O2 doesn't seem to yield these relocations. That's because the out-of-line prologue/epilogue register save and restore functions are only used at -Os (they save size). Now I believe, but don't quote me on that, that the linker should insert a copy of these functions in every shared library since these functions have non standard linkage and probably would not survive crossing shared library boundaries. I can see a bug if the shared library text size is above 32M or so (needs several copies of these functions), but I don't think the libraries are that big. The linker actually normally does that, because it compiles with -lgcc, which will link libgcc.a, which contains these functions. However, for some reason, in libxul.so case, gcc uses -shared-libgcc, which I fail to see where it collects it from (thanks KiBi for the verbose build, see below). OTOH, I still can't reproduce with a simple test case. The linker still seems to do the right thing. Even if I use the same build flags. I really don't know what makes the libxul.so case so special. Its size? So, the problem is its compile line, containing -lstartup-notification-1, and has nothing to do with -shared-libgcc. It looks like startup-notification was built with a broken toolchain in 2009 (will ask for a binNMU), and exported the _rest* symbols that libgcc.a also contains. As -lstartup-notification-1 appears before -lgcc on the link line, ld wrongly picks the versions in startup-notification-1. So it looks to me like there were and are several problems: - The original problem that made startup-notification export these symbols, that is gone. - gcc, that doesn't mark _rest* symbols as hidden in object files (they are in libgcc.a) I guess fixing the latter would either force ld to use the libgcc.a symbols or fail to link with the startup-notification symbols. /usr/lib/xulrunner-6.0/libxul.so still has lots of these R_PPC_REL24 relocations, and today this prevented iceweasel from starting at all for me, as one of them ended up unresolvable. AFAICT the libstartup-notification0 problem should be fixed now. Is this just a gcc -Os / binutils bug that should be worked around at least for now by building with -O2? I'm successfully running iceweasel with libxul.so rebuilt with -O2, it's 100% R_PPC_REL24 free. (I wonder if it's worth trying to use -Os at all, given all the trouble it's caused; AFAIK it's also known to result in generally rather bad code generation...) Interestingly, according to bug #639851, 6.0-2 didn't have the problem. Which suggests something else broke. Mike -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#639830: mdadm: alternative md-device names
Can you add 'set -x' to the top of the hook, remake the initramfs, and put it somewhere for me to download (or ftp://ftp.madduck.net/incoming)? Thanks, -- .''`. martin f. krafft madduck@d.o Related projects: : :' : proud Debian developer http://debiansystem.info `. `'` http://people.debian.org/~madduckhttp://vcs-pkg.org `- Debian - when you have better things to do than fixing systems writing a book is like washing an elephant: there no good place to begin or end, and it's hard to keep track of what you've already covered. -- anonymous digital_signature_gpg.asc Description: Digital signature (see http://martin-krafft.net/gpg/sig-policy/999bbcc4/current)
Bug#639864: ITP: libpoe-component-syndicator-perl -- POE component base class which implements the Observer pattern
Package: wnpp Severity: wishlist Owner: Jotam Jr. Trejo jota...@debian.org.sv * Package name: libpoe-component-syndicator-perl Version : 0.06 Upstream Author : Hinrik Örn Sigurðsson hinrik@gmail.com * URL : http://search.cpan.org/dist/POE-Component-Syndicator/ * License : (GPL, Artistic) Programming Lang: (Perl) Description : POE component base class which implements the Observer pattern POE::Component::Syndicator is a base class for POE components which need to handle a persistent resource (e.g. a connection to an IRC server) for one or more sessions in an extendable way. POE::Component::Syndicator (as well as Object::Pluggable, which this module inherits from) was born out of POE::Component::IRC, the guts of which quickly spread to other POE components. Now they can all inherit from this module instead. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#624354: Processed: Re: Bug#624354: ./xpcshell: error while loading shared libraries: ./libxul.so: R_PPC_REL24 relocation at 0x0f9f0148 for symbol `_restgpr_29_x' out of range
On Wed, Aug 31, 2011 at 06:35:09AM +0200, Mike Hommey wrote: Interestingly, according to bug #639851, 6.0-2 didn't have the problem. Which suggests something else broke. Actually, it must have worked by luck in 6.0-2 for that user, because the binary is affected the same way. So, it would be interesting to find what particular library is exporting the _rest* symbols this time, since libstartup-notification doesn't anymore. Mike -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#639744: Compromised certificates for *.google.com issued by DigiNotar Root CA
On Tue, Aug 30, 2011 at 10:49:04PM -0500, Raphael Geissert wrote: On Tuesday 30 August 2011 15:48:11 Mike Hommey wrote: On Tue, Aug 30, 2011 at 09:58:18PM +0200, Yves-Alexis Perez wrote: On mar., 2011-08-30 at 12:29 -0500, Raphael Geissert wrote: What I can't tell for sure from the documentation is whether OpenSSL and GnuTLS do check the CRL's validity (signature and time.) It doesn't seem like they do. This is relevant if we were to ship them in ca-certificates. Mike, without digging into the documentation I found this reference [2] regarding NSS and its CRL support. Do you know if any of what is said on that email has changed? namely how 'next update' dates are handled. [2]http://www.mail-archive.com/mozilla-crypto@mozilla.org/msg00890.html I think CRL handling is still mostly manual work. I don't know much more though. Mike -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#639771: fritzing: FTBFS: src/partsbinpalette/graphicsflowlayout.cpp:83:63: error: no matching function for call to 'qMax(double, qreal)'
Hi,
I added old patch. I add new patch to this mail.
Best regards,
Nobuhiro
2011/8/30 Nobuhiro Iwamatsu iwama...@nigauri.org:
Source: fritzing
Version: 0.6.3b-2
Severity: wishlist
Tags: patch
User: debian-...@superh.org
Usertags: sh4
Justification: FTBFS
User: debian-...@lists.debian.org
Usertags: eabi
X-Debbugs-CC: debian-sup...@lists.debian.org
Hi,
fritzing FTBFS on armel and sh4. Probably this will FTBFS in armhf.
armel:
https://buildd.debian.org/status/fetch.php?pkg=fritzingarch=armelver=0.6.3b-2stamp=1314423039
sh4:
http://buildd.debian-ports.org/status/fetch.php?pkg=fritzingarch=sh4ver=0.6.3b-2stamp=1314462968
-
/usr/include/qt4/QtCore/qstring.h: At global scope:
/usr/include/qt4/QtCore/qstring.h:187:17: note: the mangling of
'va_list' has changed in GCC 4.4
g++ -c -pipe -g -O2 -g -O2 -Wall -Wall -W -D_REENTRANT -DQT_WEBKIT
-DLINUX_32 -DQT_NO_DEBUG -DQT_SVG_LIB -DQT_SQL_LIB -DQT_XML_LIB
-DQT_GUI_LIB -DQT_NETWORK_LIB -DQT_CORE_LIB -DQT_SHARED
-I/usr/share/qt4/mkspecs/linux-g++ -I. -I/usr/include/qt4/QtCore
-I/usr/include/qt4/QtNetwork -I/usr/include/qt4/QtGui
-I/usr/include/qt4/QtXml -I/usr/include/qt4/QtSql
-I/usr/include/qt4/QtSvg -I/usr/include/qt4 -Isrc/lib/boost_1_43_0
-Irelease -o release/graphicsflowlayout.o
src/partsbinpalette/graphicsflowlayout.cpp
src/partsbinpalette/graphicsflowlayout.cpp: In member function 'int
GraphicsFlowLayout::doLayout(const QRectF)':
src/partsbinpalette/graphicsflowlayout.cpp:83:63: error: no matching
function for call to 'qMax(double, qreal)'
src/partsbinpalette/graphicsflowlayout.cpp:83:63: note: candidate is:
/usr/include/qt4/QtCore/qglobal.h:1116:17: note: templateclass T
const T qMax(const T, const T)
make[2]: *** [release/graphicsflowlayout.o] Error 1
make[2]: Leaving directory
`/build/buildd-fritzing_0.6.3b-2-armel-ctm7HT/fritzing-0.6.3b'
make[1]: *** [release] Error 2
-
I made a patch which revised this problem.
Could you apply this patch?
Best regards,
Nobuhiro
--
Nobuhiro Iwamatsu
iwamatsu at {nigauri.org / debian.org}
GPG ID: 40AD1FA6
--
Nobuhiro Iwamatsu
iwamatsu at {nigauri.org / debian.org}
GPG ID: 40AD1FA6
diff --git a/src/autoroute/cmrouter/cmrouter.cpp b/src/autoroute/cmrouter/cmrouter.cpp
index 21b4a3f..76c4681 100644
--- a/src/autoroute/cmrouter/cmrouter.cpp
+++ b/src/autoroute/cmrouter/cmrouter.cpp
@@ -1747,14 +1747,14 @@ void CMRouter::hookUpWires(QListPathUnit * fullPath, QListWire * wires)
viewLayerIDs.insert(w-viewLayerID());
QPointF p1 = w-pos();
QPointF p2 = w-line().p2() + p1;
- l = qMin(p1.x(), l);
- r = qMax(p1.x(), r);
- l = qMin(p2.x(), l);
- r = qMax(p2.x(), r);
- t = qMin(p1.y(), t);
- b = qMax(p1.y(), b);
- t = qMin(p2.y(), t);
- b = qMax(p2.y(), b);
+ l = qMin(p1.x(), qreal(l));
+ r = qMax(p1.x(), qreal(r));
+ l = qMin(p2.x(), qreal(l));
+ r = qMax(p2.x(), qreal(r));
+ t = qMin(p1.y(), qreal(t));
+ b = qMax(p1.y(), qreal(b));
+ t = qMin(p2.y(), qreal(t));
+ b = qMax(p2.y(), qreal(b));
}
TileRect searchRect;
diff --git a/src/partsbinpalette/graphicsflowlayout.cpp b/src/partsbinpalette/graphicsflowlayout.cpp
index b93fa41..c22a92b 100644
--- a/src/partsbinpalette/graphicsflowlayout.cpp
+++ b/src/partsbinpalette/graphicsflowlayout.cpp
@@ -80,7 +80,7 @@ int GraphicsFlowLayout::doLayout(const QRectF rect) {
item-setGeometry(QRectF(QPoint(x, y), item-preferredSize()));
x = nextX;
- lineHeight = qMax(lineHeight, item-preferredSize().height());
+ lineHeight = qMax(qreal(lineHeight), item-preferredSize().height());
}
m_lastWidth = rect.width();
Bug#639865: auditd: new upstream release available
Package: auditd Version: 1.7.18-1 Severity: normal http://people.redhat.com/sgrubb/audit/ The above URL has release 2.1.3. Among other things it uses /proc/self/oom_score_adj which stops recent kernels from whinging. -- System Information: Debian Release: wheezy/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 3.0.0-1-amd64 (SMP w/2 CPU cores) Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages auditd depends on: ii libaudit01.7.18-1Dynamic library for security audit ii libc62.13-16 Embedded GNU C Library: Shared lib ii libgssapi-krb5-2 1.9.1+dfsg-1+b1 MIT Kerberos runtime libraries - k ii libkrb5-31.9.1+dfsg-1+b1 MIT Kerberos runtime libraries ii libpam-runtime 1.1.3-2 Runtime support for the PAM librar ii libwrap0 7.6.q-21Wietse Venema's TCP wrappers libra ii lsb-base 3.2-27 Linux Standard Base 3.2 init scrip auditd recommends no packages. Versions of packages auditd suggests: pn audispd-plugins none (no description available) -- Configuration Files: /etc/audisp/audispd.conf [Errno 13] Permission denied: u'/etc/audisp/audispd.conf' /etc/audisp/plugins.d/af_unix.conf [Errno 13] Permission denied: u'/etc/audisp/plugins.d/af_unix.conf' /etc/audisp/plugins.d/syslog.conf [Errno 13] Permission denied: u'/etc/audisp/plugins.d/syslog.conf' /etc/audit/audit.rules [Errno 13] Permission denied: u'/etc/audit/audit.rules' /etc/audit/auditd.conf [Errno 13] Permission denied: u'/etc/audit/auditd.conf' -- 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#624354: Processed: Re: Bug#624354: ./xpcshell: error while loading shared libraries: ./libxul.so: R_PPC_REL24 relocation at 0x0f9f0148 for symbol `_restgpr_29_x' out of range
On Wed, Aug 31, 2011 at 07:05:04AM +0200, Mike Hommey wrote: On Wed, Aug 31, 2011 at 06:35:09AM +0200, Mike Hommey wrote: Interestingly, according to bug #639851, 6.0-2 didn't have the problem. Which suggests something else broke. Actually, it must have worked by luck in 6.0-2 for that user, because the binary is affected the same way. So, it would be interesting to find what particular library is exporting the _rest* symbols this time, since libstartup-notification doesn't anymore. And the winner is libevent. Mike -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#624354: Processed: Re: Bug#624354: ./xpcshell: error while loading shared libraries: ./libxul.so: R_PPC_REL24 relocation at 0x0f9f0148 for symbol `_restgpr_29_x' out of range
On Wed, Aug 31, 2011 at 07:26:10AM +0200, Mike Hommey wrote: On Wed, Aug 31, 2011 at 07:05:04AM +0200, Mike Hommey wrote: On Wed, Aug 31, 2011 at 06:35:09AM +0200, Mike Hommey wrote: Interestingly, according to bug #639851, 6.0-2 didn't have the problem. Which suggests something else broke. Actually, it must have worked by luck in 6.0-2 for that user, because the binary is affected the same way. So, it would be interesting to find what particular library is exporting the _rest* symbols this time, since libstartup-notification doesn't anymore. And the winner is libevent. iceweasel built against 1.4.13-stable-1 which was built a long time ago, like libstartup-notification had, and 1.4.14b-stable-1 currently in unstable doesn't export the symbols. Same conclusion as with libstartup-notification: old toolchain bug. Still, I think it's wrong that a random library can highjack symbols that gcc uses to call its own stuff from libgcc. Are there actual legitimate uses of that feature? Mike -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#632920: Related to 605268
Presumably this is related to http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=605268 in OpenOffice.org -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#639341: dh: cannot override binary-arch and binary-indep selectively
On Tue, Aug 30, 2011 at 05:59:21PM -0400, Joey Hess wrote: Yann Dirson wrote: I tried things like: build-arch: dh_auto_build -a docbook-to-man debian/tulip.sgml debian/tulip.1 You're not running dh_auto_configure which dh would normally run here. Why not just run dh build-arch in the build-arch target? Well, I am tempted to think my problems come from the manpage example not doing that in the first place :) Another thing that I feel lacks in the manpage is a user-level description of what the debhelper log tries to achieve. Its details are mentionned in INTERNALS, which is probably not intended to be necessary to read for an understanding of what happenned ?. That is, the dh manpage should probably mentions earlier that dh remembers what dh_* commands have been run. This would allow to explain that one can run things like the following without package-specific actions being overridden with general ones: override_dh_foo: dh_foo -ppblurb whatever dh_foo OTOH I got surprised (although I think I understand what happenned behind the scenes) that running build-arch runs auto_configure only for arch packages, whereas it is for most packages a generic thing, so that running build-indep afterwards cause cmake to be run again. I guess this can cause unwanted rebuilds when one then runs build-arch again. Best regards, -- Yann -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
