Bug#699215: vlc: segfaults while opening certain videos.
Output from avplay... Video plays just fine. david@Aya:~/temp$ avplay -v verbose ./My\ Movie_2.mp4 avplay version 0.8.5-6:0.8.5-1, Copyright (c) 2003-2012 the Libav developers built on Jan 13 2013 12:05:48 with gcc 4.7.2 configuration: --arch=amd64 --enable-pthreads --enable-runtime-cpudetect --extra-version='6:0.8.5-1' --libdir=/usr/lib/x86_64-linux-gnu --prefix=/usr --enable-bzlib --enable-libdc1394 --enable-libdirac --enable-libfreetype --enable-frei0r --enable-gnutls --enable-libgsm --enable-libmp3lame --enable-librtmp --enable-libopencv --enable-libopenjpeg --enable-libpulse --enable-libschroedinger --enable-libspeex --enable-libtheora --enable-vaapi --enable-vdpau --enable-libvorbis --enable-libvpx --enable-zlib --enable-gpl --enable-postproc --enable-swscale --enable-libcdio --enable-x11grab --enable-libx264 --enable-libxvid --shlibdir=/usr/lib/x86_64-linux-gnu --enable-shared --disable-static avcodec configuration: --arch=amd64 --enable-pthreads --enable-runtime-cpudetect --extra-version='6:0.8.5-1' --libdir=/usr/lib/x86_64-linux-gnu --prefix=/usr --enable-bzlib --enable-libdc1394 --enable-libdirac --enable-libfreetype --enable-frei0r --enable-gnutls --enable-libgsm --enable-libmp3lame --enable-librtmp --enable-libopencv --enable-libopenjpeg --enable-libpulse --enable-libschroedinger --enable-libspeex --enable-libtheora --enable-vaapi --enable-vdpau --enable-libvorbis --enable-libvpx --enable-zlib --enable-gpl --enable-postproc --enable-swscale --enable-libcdio --enable-x11grab --enable-libx264 --enable-libxvid --shlibdir=/usr/lib/x86_64-linux-gnu --enable-shared --disable-static --enable-libopencore-amrnb --enable-version3 --enable-libopencore-amrwb --enable-version3 --enable-libvo-aacenc --enable-version3 --enable-libvo-amrwbenc --enable-version3 libavutil51. 22. 1 / 51. 22. 1 libavcodec 53. 35. 0 / 53. 35. 0 libavformat 53. 21. 1 / 53. 21. 1 libavdevice 53. 2. 0 / 53. 2. 0 libavfilter 2. 15. 0 / 2. 15. 0 libswscale2. 1. 0 / 2. 1. 0 libpostproc 52. 0. 0 / 52. 0. 0 Input #0, mov,mp4,m4a,3gp,3g2,mj2, from './My Movie_2.mp4': Metadata: major_brand : mp42 minor_version : 0 compatible_brands: mp41isom Duration: 00:06:47.74, start: 0.00, bitrate: 383 kb/s Stream #0.0(und): Video: h264 (Constrained Baseline), yuv420p, 426x240, 282 kb/s, 29.97 fps, 29.97 tbr, 29970 tbn, 59940 tbc Stream #0.1(und): Audio: aac, 44100 Hz, stereo, s16, 98 kb/s ^C80.53 A-V: -0.019 s:0.0 aq= 320KB vq= 467KB sq=0B f=0/0 f=0/0 david@Aya:~/temp$ Better gdb output from vlc (2.0.3-4) with vaapi enabled. david@Aya:~/temp$ MALLOC_CHECK_=2 gdb vlc GNU gdb (GDB) 7.4.1-debian Copyright (C) 2012 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later http://gnu.org/licenses/gpl.html This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type show copying and show warranty for details. This GDB was configured as x86_64-linux-gnu. For bug reporting instructions, please see: http://www.gnu.org/software/gdb/bugs/... Reading symbols from /usr/bin/vlc...Reading symbols from /usr/lib/debug/usr/bin/vlc...done. done. (gdb) thread apply all bt full (gdb) start Temporary breakpoint 1 at 0x401180: file vlc.c, line 97. Starting program: /usr/bin/vlc [Thread debugging using libthread_db enabled] Using host libthread_db library /lib/x86_64-linux-gnu/libthread_db.so.1. Temporary breakpoint 1, main (i_argc=1, ppsz_argv=0x7fffe7b8) at vlc.c:97 97 vlc.c: No such file or directory. (gdb) continue Continuing. VLC media player 2.0.3 Twoflower (revision 2.0.2-93-g77aa89e) [New Thread 0x703de700 (LWP 7754)] [0x6051a8] main libvlc: Running vlc with the default interface. Use 'cvlc' to use vlc without interface. [New Thread 0x7fffef431700 (LWP 7755)] [New Thread 0x7fffda164700 (LWP 7758)] [New Thread 0x7fffd9784700 (LWP 7759)] [New Thread 0x7fffd9963700 (LWP 7769)] [New Thread 0x7fffd7654700 (LWP 7770)] [New Thread 0x7fffd7553700 (LWP 7771)] [Thread 0x7fffd9963700 (LWP 7769) exited] [Thread 0x7fffd7553700 (LWP 7771) exited] [New Thread 0x7fffcfb0d700 (LWP 7772)] [New Thread 0x7fffcf30c700 (LWP 7773)] [New Thread 0x7fffceb0b700 (LWP 7774)] [New Thread 0x7fffce30a700 (LWP 7775)] [New Thread 0x7fffd7553700 (LWP 7776)] [New Thread 0x7fffd9963700 (LWP )] libva: VA-API version 0.32.0 libva: va_getDriverName() returns 0 libva: Trying to open /usr/lib/x86_64-linux-gnu/dri/i965_drv_video.so libva: va_openDriver() returns 0 [0xf42d98] avcodec decoder: Using VA API version 0.32 for hardware decoding. [New Thread 0x7fffcade0700 (LWP 7779)] [New Thread 0x7fffc9da9700 (LWP 7780)] Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 0x7fffd7553700 (LWP 7776)] 0x7fffd2a9cf37 in CopyFromUswc ( dst=0x122ab10 \020\020\020\020\020\020\020\020\020\020\336\377\002z\366\377\002\202\366\377\002j\336\377,
Bug#699215: vlc: segfaults while opening certain videos.
tags 699215 patch
thanks
I can confirm that applying the patch from upstream to the version of
VLC in Debian Wheezy fixes the crash.
Patch from upstream attached.
Thanks for your time.
-David
On 01/29/2013 11:39 PM, Reinhard Tartler wrote:
Tags 699215 moreinfo
Severity 699215 minor
stop
On Tue, Jan 29, 2013 at 7:11 AM, David Smithsidic...@gmail.com wrote:
notfound 699215 2.0.5-1
thanks
On 01/29/2013 01:50 PM, David M Smith wrote:
Package: vlc
Version: 2.0.3-4
Severity: important
vlc segfaults while opening some H.264 videos.
gdb output below.
This crash does not happen while using the version of VLC in Debian unstable
2.0.5-1. The video files open just fine.
See http://wiki.debian.org/HowToGetABacktrace for more information how
to get nicer backtraces.
I notice that you have configured VAAPI in the vlc preferences. Does
the problem still appear if you disable hardware acceleration via
VAAPI?
Can you reproduce the crashes with the avplay utility found in the
libav-tools package?
Description: Fix crash when opening some videos with vaapi enabled.
Origin: upstream, http://git.videolan.org/gitweb.cgi/vlc.git/?p=vlc.git;a=commitdiff;h=39dc439cf5e3fe83b87078bcf93c13d07fd02dac;hp=44819779f94086ea1f21a9649af8d41754fa9ccf#patch1
Bug: https://trac.videolan.org/vlc/ticket/6333
Bug-Debian: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=699215
Last-Update: 2012-01-30
--- a/modules/codec/avcodec/copy.c
+++ b/modules/codec/avcodec/copy.c
@@ -70,10 +70,10 @@
ASM_SSE2(cpu, mfence);
for (unsigned y = 0; y height; y++) {
-const unsigned unaligned = (intptr_t)src 0x0f;
-unsigned x;
+const unsigned unaligned = (-(uintptr_t)src) 0x0f;
+unsigned x = 0;
-for (x = 0; x unaligned; x++)
+for (; x unaligned; x++)
dst[x] = src[x];
#ifdef CAN_COMPILE_SSE4_1
Bug#699502: ktouchpadenabler: Only Disables touchpad until touchpad is touched
On 02/01/2013 11:30 AM, David M Smith wrote: When I trigger the touchpad disable, the cursor disappears. However, if I touch anywhere on the touchpad, it becomes active again. I want to disable the touchpad until I toggle it enabled again and ktouchpadenabler doesn't seem to work for that. Forgot to mention, according to synaptiks my touchpad is a ETPS/2 Elantech Touchpad Also, if I install synaptiks and tell it to disable the touchpad while I'm typing, it works. (except for the LED light which doesn't work in synaptiks or ktouchpadenabler and will be a different bug report). ktouchpadenabler just seems to make the cursor disappear, and then if I touch the touchpad anywhere, it reappears and the touchpad is still enabled. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#696523: apt-cacher: apt-cacher-precache.pl help is not architecture aware.
If you install libdpkg-perl is this better?
perl -MDpkg::Arch -ne '$arch=Dpkg::Arch::get_host_arch;
if(/^(i.|.i)\s+(\S+)\s+(\S+)/) { print
$2_$3_$arch.deb\n$2_$3_all.deb\n}'
Mark
Yes, definitely seems to work.
Thanks.
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#701148: linux-image-3.7-trunk-amd64: Regression - brightness controls do not work.
Summary: 3.2.0-4-amd64 (Wheezy): Brightness controls work, get a popup indicator showing the brightness should be changing, dmesg says ACPI fails to switch the brightness. 3.6-trunk: Brightness controls work, get a popup indicator showing the brightness should be changing, dmesg says ACPI fails to switch the brightness. 3.7-trunk: Brightness controls do nothing, no popup indicator, no ACPI failures about brightness in dmesg. 3.7-trunk+video.allow_duplicate=1: Brightness controls cause a popup indicator showing brightness should be changing, but the brightness doesn't change. no ACPI failures about brightness in dmesg. 3.6-trunk+video.allow_duplicate=1: Brightness controls cause a popup indicator showing brightness should be changing, but the brightness doesn't change. dmesg says ACPI fails to switch the brightness. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#694863: liferea: Asks for login credentials while in offline mode
Package: liferea Version: 1.8.6-1.1 Severity: normal Liferea pops up login credentials for Google Reader while in offline mode and there is no internet connection available. It would make sense that if you put liferea into offline mode then it wouldn't try to synchronize any feeds, but apparently it still tries when you click on a feed. -- System Information: Debian Release: wheezy/sid APT prefers testing APT policy: (500, 'testing') Architecture: i386 (i686) Kernel: Linux 3.2.0-4-686-pae (SMP w/1 CPU core) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages liferea depends on: ii gconf-service 3.2.5-1+build1 ii gconf2 3.2.5-1+build1 ii libatk1.0-0 2.4.0-2 ii libc6 2.13-37 ii libcairo2 1.12.2-2 ii libgconf-2-43.2.5-1+build1 ii libgdk-pixbuf2.0-0 2.26.1-1 ii libglib2.0-02.33.12+really2.32.4-3 ii libgtk2.0-0 2.24.10-2 ii libice6 2:1.0.8-2 ii libjson-glib-1.0-0 0.14.2-1 ii libnotify4 0.7.5-1 ii libpango1.0-0 1.30.0-1 ii libsm6 2:1.2.1-2 ii libsoup2.4-12.38.1-2 ii libsqlite3-03.7.13-1 ii libunique-1.0-0 1.1.6-4 ii libwebkitgtk-1.0-0 1.8.1-3.3 ii libxml2 2.8.0+dfsg1-6 ii libxslt1.1 1.1.26-14 ii liferea-data1.8.6-1.1 Versions of packages liferea recommends: ii curl 7.26.0-1 ii dbus 1.6.8-1 ii dbus-x11 1.6.8-1 ii kget 4:4.8.4-1+b1 ii wget 1.13.4-3 Versions of packages liferea suggests: ii network-manager 0.9.4.0-6 -- 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#694918: supertuxkart: crash on resolution change while in fullscreen mode
Package: supertuxkart Version: 0.7.3-2+exp1 Severity: important supertuxkart crashes on resolution change. 1. Put supertuxkart into fullscreen mode and apply the changes. 2. Change resolution to 1024x768 and apply changing. If it doesn't crash, try changing resolution to something higher (in my case, 1280x800 which is my native res). 3. Then supertuxkart crashes. This happens in the version of supertuxkart in Wheezy and in Experimental. I've installed the dbg packages for supertuxkart in experimental to produce a usable backtrace. I've also installed the dbg libs for my radeon graphics driver. david@Miho:~$ supertuxkart Irrlicht Engine version 1.8.0 Linux 3.2.0-4-686-pae #1 SMP Debian 3.2.32-1 i686 [FileManager] Data files will be fetched from: '/usr/share/games/supertuxkart' [FileManager] Addons files will be stored in '/home/david/.local/share/supertuxkart/addons'. [IrrDriver] Trying OpenGL rendering. startMusic : m_normal_filename=/usr/share/games/supertuxkart/data//music/MayDayMayhem.ogg, gain=0.7 [IrrDriver] Trying OpenGL rendering. WARNING: Music not playing when it should be. Source state: 4116 [IrrDriver] Trying OpenGL rendering. WARNING: Music not playing when it should be. Source state: 4116 [IrrDriver] Trying OpenGL rendering. WARNING: Music not playing when it should be. Source state: 4116 *** glibc detected *** supertuxkart: double free or corruption (!prev): 0x0b2473d8 *** === Backtrace: = /lib/i386-linux-gnu/i686/cmov/libc.so.6(+0x70f01)[0xb6c69f01] /lib/i386-linux-gnu/i686/cmov/libc.so.6(+0x72768)[0xb6c6b768] /lib/i386-linux-gnu/i686/cmov/libc.so.6(cfree+0x6d)[0xb6c6e81d] /usr/lib/i386-linux-gnu/dri/r300_dri.so(+0x194739)[0xb579e739] === Memory map: 08048000-08383000 r-xp 08:01 533596 /usr/games/supertuxkart 08383000-08384000 r--p 0033a000 08:01 533596 /usr/games/supertuxkart 08384000-08386000 rw-p 0033b000 08:01 533596 /usr/games/supertuxkart 08386000-0838c000 rw-p 00:00 0 0a2b6000-0f0b1000 rw-p 00:00 0 [heap] b0da-b0fa1000 rw-p 00:00 0 b10a1000-b11a2000 rw-p 00:00 0 b16a9000-b18aa000 rw-p 00:00 0 b19aa000-b1aab000 rw-p 00:00 0 b1cad000-b20ae000 rw-p 00:00 0 b21ad000-b22ae000 rw-p 00:00 0 b24fd000-b26fe000 rw-p 00:00 0 b27fe000-b2d0 rw-p 00:00 0 b2e3a000-b303b000 rw-p 00:00 0 b313b000-b323c000 rw-p 00:00 0 b3401000-b39b5000 rw-p 00:00 0 b3ac6000-b3ba4000 rw-p 00:00 0 b3bf4000-b3d15000 rw-p 00:00 0 b3da8000-b3db2000 r-xp 08:01 262360 /lib/i386-linux- gnu/i686/cmov/libnss_files-2.13.so b3db2000-b3db3000 r--p 9000 08:01 262360 /lib/i386-linux- gnu/i686/cmov/libnss_files-2.13.so b3db3000-b3db4000 rw-p a000 08:01 262360 /lib/i386-linux- gnu/i686/cmov/libnss_files-2.13.so b3db4000-b3ea7000 r-xp 08:01 532095 /usr/lib/i386-linux- gnu/libasound.so.2.0.0 b3ea7000-b3eab000 r--p 000f2000 08:01 532095 /usr/lib/i386-linux- gnu/libasound.so.2.0.0 b3eab000-b3eac000 rw-p 000f6000 08:01 532095 /usr/lib/i386-linux- gnu/libasound.so.2.0.0 b3eb-b3ec rw-s 00:04 2850879/SYSV0056a4d6 (deleted) b3ec-b3ed rw-s 00:05 5018 /dev/snd/pcmC0D0p b3ed-b3ed1000 ---p 00:00 0 b3ed1000-b46d1000 rw-p 00:00 0 b485-b4951000 rw-p 00:00 0 b4ad6000-b4ed7000 rw-p 00:00 0 b4ed7000-b503d000 r-xp 08:01 532630 /usr/lib/i386-linux- gnu/libvorbisenc.so.2.0.8 b503d000-b504e000 r--p 00165000 08:01 532630 /usr/lib/i386-linux- gnu/libvorbisenc.so.2.0.8 b504e000-b504f000 rw-p 00176000 08:01 532630 /usr/lib/i386-linux- gnu/libvorbisenc.so.2.0.8 b510-b5121000 rw-p 00:00 0 -- System Information: Debian Release: wheezy/sid APT prefers testing APT policy: (500, 'testing'), (1, 'experimental') Architecture: i386 (i686) Kernel: Linux 3.2.0-4-686-pae (SMP w/1 CPU core) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages supertuxkart depends on: ii libc6 2.13-37 ii libcurl3-gnutls 7.26.0-1 ii libenet1a 1.3.3-2 ii libfribidi0 0.19.2-3 ii libgcc1 1:4.7.2-4 ii libgl1-mesa-glx [libgl1] 8.0.4-2 ii libglu1-mesa [libglu1]8.0.4-2 ii libirrlicht1.81.8+dfsg1-1 ii libogg0 1.3.0-4 ii libopenal11:1.14-4 ii libstdc++64.7.2-4 ii libvorbis0a 1.3.2-1.3 ii libvorbisfile31.3.2-1.3 ii libx11-6 2:1.5.0-1 ii libxext6 2:1.3.1-2 ii supertuxkart-data 0.7.3-2+exp1 supertuxkart recommends no packages. supertuxkart suggests no packages. -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact
Bug#695092: kde-workspace: krunner crash if user types too quickly
Package: kde-workspace Version: 4:4.8.4-4 Severity: important Tags: upstream It seems that krunner often crashes on me if I press alt+f2, type in the name of the application and press enter before krunner is even able to bring up any search results.. Crash report available in the upstream bugreport: https://bugs.kde.org/show_bug.cgi?id=311089 Upstream has marked this bug report as a duplicate of another upstream bugreport found in KDE 4.9.80Beta1: https://bugs.kde.org/show_bug.cgi?id=225779 -- System Information: Debian Release: wheezy/sid APT prefers testing APT policy: (500, 'testing') Architecture: i386 (i686) Kernel: Linux 3.2.0-4-686-pae (SMP w/1 CPU core) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages kde-workspace depends on: ii freespacenotifier 4:4.8.4-4 ii kde-window-manager 4:4.8.4-4 ii kde-workspace-bin 4:4.8.4-4 ii klipper 4:4.8.4-4 ii ksysguard 4:4.8.4-4 ii systemsettings 4:4.8.4-4 Versions of packages kde-workspace recommends: ii kdm 4:4.8.4-4 ii kinfocenter 4:4.8.4-4 ii kmenuedit4:4.8.4-4 kde-workspace 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#695142: supertuxkart: SegFault on quit
Package: supertuxkart Version: 0.7.3-2+exp1 Severity: normal After completing a race or two, the game segfaults when trying to quit.. Irrlicht Engine version 1.8.0 Linux 3.2.0-4-686-pae #1 SMP Debian 3.2.32-1 i686 [FileManager] Data files will be fetched from: '/usr/share/games/supertuxkart' [FileManager] Addons files will be stored in '/home/david/.local/share/supertuxkart/addons'. [IrrDriver] Trying OpenGL rendering. [New Thread 0xb4e0eb70 (LWP 6835)] [Thread 0xb4e0eb70 (LWP 6835) exited] [New Thread 0xb4e0eb70 (LWP 6836)] startMusic : m_normal_filename=/usr/share/games/supertuxkart/data//music/MayDayMayhem.ogg, gain=0.7 startMusic : m_normal_filename=/usr/share/games/supertuxkart/data/music///Origin.ogg, gain=0.7 WARNING: Music not playing when it should be. Source state: 4116 WARNING: Music not playing when it should be. Source state: 4116 startMusic : m_normal_filename=/usr/share/games/supertuxkart/data/music///race_summary.ogg, gain=0.7 startMusic : m_normal_filename=/usr/share/games/supertuxkart/data/music///Origin.ogg, gain=0.7 startMusic : m_normal_filename=/usr/share/games/supertuxkart/data/music///race_summary.ogg, gain=0.7 startMusic : m_normal_filename=/usr/share/games/supertuxkart/data//music/MayDayMayhem.ogg, gain=0.7 [Thread 0xb4e0eb70 (LWP 6836) exited] Program received signal SIGSEGV, Segmentation fault. 0xb780c0f6 in _XIsEventCookie () from /usr/lib/i386-linux-gnu/libX11.so.6 (gdb) bt #0 0xb780c0f6 in _XIsEventCookie () from /usr/lib/i386-linux-gnu/libX11.so.6 #1 0xb77f932d in _XFreeDisplayStructure () from /usr/lib/i386-linux- gnu/libX11.so.6 #2 0xb77e6689 in XCloseDisplay () from /usr/lib/i386-linux-gnu/libX11.so.6 #3 0xb7d4c44e in irr::CIrrDeviceLinux::~CIrrDeviceLinux (this=this@entry=0x83a8a78, __in_chrg=optimized out, __vtt_parm=optimized out) at CIrrDeviceLinux.cpp:193 #4 0xb7d4c4b2 in irr::CIrrDeviceLinux::~CIrrDeviceLinux (this=0x83a8a78, __in_chrg=optimized out, __vtt_parm=optimized out) at CIrrDeviceLinux.cpp:210 #5 0x0813576a in IrrDriver::~IrrDriver() () #6 0x081357f0 in IrrDriver::~IrrDriver() () #7 0x081d7d6e in cleanSuperTuxKart() () #8 0x080e401a in main () (gdb) #0 0xb780c0f6 in _XIsEventCookie () from /usr/lib/i386-linux-gnu/libX11.so.6 #1 0xb77f932d in _XFreeDisplayStructure () from /usr/lib/i386-linux- gnu/libX11.so.6 #2 0xb77e6689 in XCloseDisplay () from /usr/lib/i386-linux-gnu/libX11.so.6 #3 0xb7d4c44e in irr::CIrrDeviceLinux::~CIrrDeviceLinux (this=this@entry=0x83a8a78, __in_chrg=optimized out, __vtt_parm=optimized out) at CIrrDeviceLinux.cpp:193 #4 0xb7d4c4b2 in irr::CIrrDeviceLinux::~CIrrDeviceLinux (this=0x83a8a78, __in_chrg=optimized out, __vtt_parm=optimized out) at CIrrDeviceLinux.cpp:210 #5 0x0813576a in IrrDriver::~IrrDriver() () #6 0x081357f0 in IrrDriver::~IrrDriver() () #7 0x081d7d6e in cleanSuperTuxKart() () #8 0x080e401a in main () (gdb) #0 0xb780c0f6 in _XIsEventCookie () from /usr/lib/i386-linux-gnu/libX11.so.6 #1 0xb77f932d in _XFreeDisplayStructure () from /usr/lib/i386-linux- gnu/libX11.so.6 #2 0xb77e6689 in XCloseDisplay () from /usr/lib/i386-linux-gnu/libX11.so.6 #3 0xb7d4c44e in irr::CIrrDeviceLinux::~CIrrDeviceLinux (this=this@entry=0x83a8a78, __in_chrg=optimized out, __vtt_parm=optimized out) at CIrrDeviceLinux.cpp:193 #4 0xb7d4c4b2 in irr::CIrrDeviceLinux::~CIrrDeviceLinux (this=0x83a8a78, __in_chrg=optimized out, __vtt_parm=optimized out) at CIrrDeviceLinux.cpp:210 #5 0x0813576a in IrrDriver::~IrrDriver() () #6 0x081357f0 in IrrDriver::~IrrDriver() () #7 0x081d7d6e in cleanSuperTuxKart() () #8 0x080e401a in main () (gdb) #0 0xb780c0f6 in _XIsEventCookie () from /usr/lib/i386-linux-gnu/libX11.so.6 #1 0xb77f932d in _XFreeDisplayStructure () from /usr/lib/i386-linux- gnu/libX11.so.6 #2 0xb77e6689 in XCloseDisplay () from /usr/lib/i386-linux-gnu/libX11.so.6 #3 0xb7d4c44e in irr::CIrrDeviceLinux::~CIrrDeviceLinux (this=this@entry=0x83a8a78, __in_chrg=optimized out, __vtt_parm=optimized out) at CIrrDeviceLinux.cpp:193 #4 0xb7d4c4b2 in irr::CIrrDeviceLinux::~CIrrDeviceLinux (this=0x83a8a78, __in_chrg=optimized out, __vtt_parm=optimized out) at CIrrDeviceLinux.cpp:210 #5 0x0813576a in IrrDriver::~IrrDriver() () #6 0x081357f0 in IrrDriver::~IrrDriver() () #7 0x081d7d6e in cleanSuperTuxKart() () #8 0x080e401a in main () (gdb) bt full #0 0xb780c0f6 in _XIsEventCookie () from /usr/lib/i386-linux-gnu/libX11.so.6 No symbol table info available. #1 0xb77f932d in _XFreeDisplayStructure () from /usr/lib/i386-linux- gnu/libX11.so.6 No symbol table info available. #2 0xb77e6689 in XCloseDisplay () from /usr/lib/i386-linux-gnu/libX11.so.6 No symbol table info available. #3 0xb7d4c44e in irr::CIrrDeviceLinux::~CIrrDeviceLinux (this=this@entry=0x83a8a78, __in_chrg=optimized out, __vtt_parm=optimized out) at CIrrDeviceLinux.cpp:193 No locals. #4 0xb7d4c4b2 in irr::CIrrDeviceLinux::~CIrrDeviceLinux (this=0x83a8a78, __in_chrg=optimized out, __vtt_parm=optimized out) at
Bug#694918: supertuxkart: crash on resolution change while in fullscreen mode
Unreproducible here using an Intel HD graphics card (with the i915 driver). I've forwarded this upstream for input, but this is more than likely a bug somewhere in mesa/radeon. Regards, Vincent OK, I filed a bug report against mesa/radeon here: https://bugs.freedesktop.org/show_bug.cgi?id=57977 Using the binary from upstream, it looks like the output from dbg is a little bit different, but it does still crash. (gdb output) david@Miho:~/temp/supertuxkart-0.7.3-linux-glibc2.11-i386/bin$ gdb ./supertuxkart GNU gdb (GDB) 7.4.1-debian Copyright (C) 2012 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later http://gnu.org/licenses/gpl.html This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type show copying and show warranty for details. This GDB was configured as i486-linux-gnu. For bug reporting instructions, please see: http://www.gnu.org/software/gdb/bugs/... Reading symbols from /mnt/320GB/home/david/temp/supertuxkart-0.7.3-linux-glibc2.11-i386/bin/supertuxkart...(no debugging symbols found)...done. (gdb) start Temporary breakpoint 1 at 0x8054851 Starting program: /mnt/320GB/home/david/temp/supertuxkart-0.7.3-linux-glibc2.11-i386/bin/supertuxkart [Thread debugging using libthread_db enabled] Using host libthread_db library /lib/i386-linux-gnu/i686/cmov/libthread_db.so.1. Temporary breakpoint 1, 0x08054851 in main () (gdb) continue Continuing. Irrlicht Engine version 1.8.0-alpha Linux 3.2.0-4-686-pae #1 SMP Debian 3.2.32-1 i686 [FileManager] Data files will be fetched from: '..' [FileManager] Addons files will be stored in '/home/david/.local/share/supertuxkart/addons'. [IrrDriver] Trying OpenGL rendering. [New Thread 0xb5282b70 (LWP 8400)] [Thread 0xb5282b70 (LWP 8400) exited] [New Thread 0xb5282b70 (LWP 8401)] Error messages and other text output will be logged to /home/david/.config/supertuxkart/stdout.log and /home/david/.config/supertuxkart/stderr.log *** glibc detected *** /mnt/320GB/home/david/temp/supertuxkart-0.7.3-linux-glibc2.11-i386/bin/supertuxkart: double free or corruption (!prev): 0x0b058ef8 *** === Backtrace: = /lib/i386-linux-gnu/i686/cmov/libc.so.6(+0x70f01)[0xb7c82f01] /lib/i386-linux-gnu/i686/cmov/libc.so.6(+0x72768)[0xb7c84768] /lib/i386-linux-gnu/i686/cmov/libc.so.6(cfree+0x6d)[0xb7c8781d] /usr/lib/i386-linux-gnu/dri/r300_dri.so(+0x27c64b)[0xb67b064b] === Memory map: 08048000-0872f000 r-xp 00:15 8963889 /mnt/320GB/home/david/temp/supertuxkart-0.7.3-linux-glibc2.11-i386/bin/supertuxkart 0872f000-0873 r--p 006e6000 00:15 8963889 /mnt/320GB/home/david/temp/supertuxkart-0.7.3-linux-glibc2.11-i386/bin/supertuxkart 0873-08735000 rw-p 006e7000 00:15 8963889 /mnt/320GB/home/david/temp/supertuxkart-0.7.3-linux-glibc2.11-i386/bin/supertuxkart 08735000-0d6c2000 rw-p 00:00 0 [heap] b0a7a000-b0a81000 r--s 08:01 556247 /usr/lib/i386-linux-gnu/gconv/gconv-modules.cache b0b1f000-b1d23000 rw-p 00:00 0 b1e23000-b1f24000 rw-p 00:00 0 b210-b2121000 rw-p 00:00 0 b2121000-b220 ---p 00:00 0 b2229000-b252b000 rw-p 00:00 0 b262b000-b272c000 rw-p 00:00 0 b282e000-b2e3 rw-p 00:00 0 b2f2f000-b303 rw-p 00:00 0 b303c000-b323e000 rw-p 00:00 0 b324-b3441000 rw-p 00:00 0 b3541000-b3a43000 rw-p 00:00 0 b3abd000-b3c3f000 rw-p 00:00 0 b3d4-b4656000 rw-p 00:00 0 b46c5000-b4966000 rw-p 00:00 0 b4966000-b4a59000 r-xp 08:01 532095 /usr/lib/i386-linux-gnu/libasound.so.2.0.0 b4a59000-b4a5d000 r--p 000f2000 08:01 532095 /usr/lib/i386-linux-gnu/libasound.so.2.0.0 b4a5d000-b4a5e000 rw-p 000f6000 08:01 532095 /usr/lib/i386-linux-gnu/libasound.so.2.0.0 b4a82000-b4a83000 ---p 00:00 0 b4a83000-b5283000 rw-p 00:00 0 b5303000-b5404000 rw-p 00:00 0 b5409000-b580a000 rw-p 00:00 0 b5888000-b5a0a000 rw-p 00:00 0 b5b0b000-b5c71000 r-xp 08:01 532630 /usr/lib/i386-linux-gnu/libvorbisenc.so.2.0.8 b5c71000-b5c82000 r--p 00165000 08:01 532630 /usr/lib/i386-linux-gnu/libvorbisenc.so.2.0.8 b5c82000-b5c83000 rw-p 00176000 08:01 532630 /usr/lib/i386-linux-gnu/libvorbisenc.so.2.0.8 b5d73000-b5f75000 rw-p 00:00 0 b5f75000-b5f85000 rw-s 00:04 17039435 /SYSV0056a4d6 (deleted) b5f85000-b5f95000 rw-s 00:05 5151 /dev/snd/pcmC0D0p b5f95000-b5fbf000 r-xp 08:01 532627 /usr/lib/i386-linux-gnu/libvorbis.so.0.4.5 b5fbf000-b5fc r--p 00029000 08:01 532627 /usr/lib/i386-linux-gnu/libvorbis.so.0.4.5 b5fc-b5fc1000 rw-p 0002a000 08:01 532627 /usr/lib/i386-linux-gnu/libvorbis.so.0.4.5 b5fc1000-b600f000 r-xp 08:01 532724 /usr/lib/i386-linux-gnu/libFLAC.so.8.2.0 b600f000-b601 r--p 0004d000 08:01 532724 /usr/lib/i386-linux-gnu/libFLAC.so.8.2.0 b601-b6011000 rw-p 0004e000 08:01 532724 /usr/lib/i386-linux-gnu/libFLAC.so.8.2.0
Bug#712961: liferea crashes on read of 2nd item
I'm not very good at reading crash logs, but this crash doesn't appear to originate from liferea's source code. Can you try installing libwebkit-dbg and libjavascriptcoregtk-1.0-0-dbg and then posting another crash report? I haven't been able to reproduce here, but i've heard people mention this crash before. Thanks for your time. -David
Bug#638885: Liferea crash when adding new subscription
It still happens when you add to your Google Account. You need it in Liferea, and try to add to it those subscriptions, that makes crash. Pure Liferea will not crash. The 1.8.6-1.1 NMU contains a patch from upstream that should fix that. Try liferea in Debian stable and let me know if you're still able to reproduce. If not, I'll close this bug out as fixed in 1.8.6-1.1. -David -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#583990: liferea: reproducibly dumps core after 20 minutes to a few hours of running
retitle 583990 liferea: memory leak with lots of feeds. found 1.8.6-1.1 notfound 1.10~rc4 thanks. On Jul 12, 2013 6:03 PM, Axel Beckert a...@debian.org wrote: Indeed, these kind of crashes are gone. Liferea in Wheezy though seldomly runs longer than a few days for me. Usually it gets killed in less than a day by OOM on a laptop with 4 GB of RAM and 5 GB of swap. No need to make a new bug report. I've retitled this one. To be honest, i've never used liferea with more than a hundred feeds, so your feedback is appreciated. -David
Bug#717028: liferea should depend on gnome-icon-theme
tags 717028 confirmed found 717028 1.10~rc4-1 thanks. On 07/16/2013 03:27 PM, Adrian Bunk wrote: This should be fixed by depending on gnome-icon-theme. Thanks for reporting. This also impacts 1.10~rc4-1. -David -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#717028: liferea should depend on gnome-icon-theme
On 07/16/2013 06:53 PM, Adrian Bunk wrote: The common practice in GNOME packages (e.g. evolution, totem, brasero, epiphany-browser, network-manager-gnome) is a dependency on gnome-icon-theme. For non-GNOME users of GNOME applications a dependency on gnome-icon-theme can prevent serious problems. When you have a full GNOME installed, gnome-icon-theme is anyway always installed. Unless I'm missing something, that doesn't seem to help epiphany-browser.Even with the gnome-icon-theme installed, if you're running another desktop environment (ie: KDE), you get this in Wheezy for epiphany-browser: http://imgur.com/iBM7FEc (Note the red X in the icons) Without the gnome-icon-theme in liferea, I get magnifying glass icons instead of the folder icons. Although I've only done about 5 minutes of testing of liferea without the gnome-icon-theme package. I'm not that familiar with gnome, but is it possible Gnome users can create / install their own icon themes and not use the gnome-icon-theme package at all? If so, a recommends might be the way to go. -David -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#705665: epiphany-browser seems to lack a dependency on gnome-icon-theme-symbolic
can you confirm that installing gnome-icon-theme-symbolic fixes your problem epiphany-browser is missing button icons!? Sorry for the late reply. Yes, installing gnome-icon-theme-symbolic package fixes the missing icons in epiphany-browser. (Tested with Wheezy). -David -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#717028: liferea should depend on gnome-icon-theme
On 07/16/2013 11:38 PM, Adrian Bunk wrote: On Tue, Jul 16, 2013 at 04:45:03PM +0200, Paul Gevers wrote: I am also no GNOME user. But lets look at the Debian policy [1]. (below). To me it says that suggests is very reasonable if liferea works with only red crosses at the location of the icons, which seems to be the case. Depends is definitely overkill. I could be persuaded to believe that recommends is good enough, but you have to give better arguments than merely some red crosses. ... Depends is definitely required. After an apt-get install package a user can expect a package to work correctly, even when recommended packages are not installed by default. Just going through the source code in the latest release, it seems to me that liferea gets icons from three locations. 1. Most of Liferea's core icons come from GTK_STOCK (ie: GTK_STOCK_REFRESH). Especially the ICONS related to the functionality of the program (Toolbar: New subscription, Mark Items Read, Back, Forward, Next Unread Item, Update All, Search All Feeds, etc.) 2. Some (4-5?) of Liferea's icons come from the GNOME theme that you're using. The key thing is, if it doesn't exist in the GNOME theme that you're using, you'll get a warning in the console and it will just use a generic GTK_STOCK icon instead. So it's not actually required that you have a gnome icon theme. 3. The rest of Liferea's icons are bundled with the package in /pixmaps. You don't get the blank / red X buttons in liferea that you get in epiphany-browser because of the GTK_STOCK icon fallback code in liferea (tested and works for me!). So it's a completely different situation. Consider that a depends on gnome-icon-theme is added, then liferea isn't going to be installable unless the default gnome-icon-theme is installed. This doesn't make any sense as some people might want to use gnome-icon-theme-nuovo or gnome-icon-theme-suede or gnome-icon-theme-yasis or gnome-icon-theme-gartoon instead which do *NOT* provide gnome-icon-theme. Using these alternative gnome themes without the default gnome-icon-theme would make liferea uninstallable, if a depends on gnome-icon-theme is added, even though liferea would work just fine :( So then when looking at a recommends on gnome-icon-theme, it only makes sense to add it if the functionality of liferea is enhanced by using the gnome-icon-theme. Since the fallback to GTK_STOCK icons seems to be working for me when you don't have a gnome-icon-theme, I just can't see how liferea is really enhanced by using gnome-icon-theme. Then finally... Liferea is *NOT* showing you the wrong icons if you don't have gnome-icon-theme installed. Rather, it's just using the GTK_STOCK icons instead of gnome theme icons. This appears to be intentional / planned by upstream. So Suggests on any of the gnome-icon-themes does seem to be the best way to go here. Mainly because liferea does a fallback to GTK_STOCK icons which seems to work just fine. But anyway, this isn't my decision to make. Just my 2 cents. -David -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#717028: liferea should depend on gnome-icon-theme
On 07/17/2013 02:12 PM, Adrian Bunk wrote: Let me repeat something I already wrote in this bug: -- snip -- For non-GNOME users of GNOME applications a dependency on gnome-icon-theme can prevent serious problems. What serious problems are you referring to? That's what I'm not understanding.. Without the gnome-icon-theme dependency, it appears to me that liferea falls back to the generic GTK icons and all is just fine other than a couple of warnings tossed out into the console log. If you're not getting what I'm getting then then let me know. http://imgur.com/ZHDvUdy -David -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#714033: mirrors.163.com: No longer available?
On 06/27/2013 03:46 PM, mirror wrote: Ok, but use proxy method instead of redirect which will be more suitable for apt-get. 于 13-6-27 上午5:00, Simon Paillard 写道: Hi, On Wed, Jun 26, 2013 at 10:47:38PM +0800, mirror wrote: 于 13-6-25 下午7:33, Simon Paillard 写道: On Tue, Jun 25, 2013 at 08:21:40AM +0800, David M Smith wrote: It is, and forwarded to the administrator in charge of mirrors.163.com. As critical hardware failure, our machine is down and lost all data on it a few days ago. We are rebuilding debian mirror now. http://mirrors.163.com/debian/ will be come back few days later. In the mean time, could you please redirect http://mirrors.163.com/debian/* to http://ftp.cn.debian.org/debian/* ? Best regards. It was up for over a week, but the mirrors.163.com/debian is down again :(. -David -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#726089: liferea: Crashes on font decrease.
On 10/12/2013 02:38 PM, Sthu wrote: Package: liferea Version: 1.10.2-1 Severity: normal Dear Maintainer, On font decrease from view menu entry the program crashes. In terminal from which i ran it i get: ERROR:itemview.c:484:itemview_do_zoom: assertion failed: (itemview-priv-htmlview != NULL) Haven't been able to reproduce. From the description of the error it sounds like your htmlview pane isn't initializing properly. Are you able to open or read any feeds at all? Are you using a different view mode? -David -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#725896: liferea: Upper right panel in normal view is always at minimum size when opening liferea
tags 725896 confirmed thanks. On 10/10/2013 03:00 AM, Alejandro Carrazzoni wrote: Package: liferea Version: 1.10.2-1 Severity: normal When I open liferea the upper right panel with the headlines is always at minimum size so I have to resize the panel every time I open Liferea. It would be nice if liferea would remember the size of the panel like in the GTK2 version. Just for the record, what desktop environment are you using? It looks like this starts happening right after the fix for the white fonts on a white background on DE's other than Gnome3. I remember that something about how liferea's window panes were initialized was changed to fix that other bug and I think that change may have also caused this bug. I'm going to try packaging 1.10.3 to see if it's fixed there, and if not, I'll report this bug upstream. Thanks for reporting. -David -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#726089: liferea: Crashes on font decrease.
tags 726089 upstream forwarded 726089 https://sourceforge.net/p/liferea/bugs/1119/ thanks. With a little bit of tinkering I'm now able to reproduce this bug so I've send it upstream along with a full crash trace. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#726091: liferea: Does not connect through proxy anymore.
forwarded 726091 https://sourceforge.net/p/liferea/bugs/1120/ thanks. On 10/12/2013 03:10 PM, Sthu wrote: I have tried both nets ip4 and ip6 on local interface for proxy connection type, manual option: # privoxy server [::1] port 8118 # tor server 127.0.0.1 port 9050 both does not work: the program does not fetch feeds. Did this work before? There's already a bug report from years ago about liferea not working with a proxy running on localhost. See: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=555199 Can you tell me if this worked in the 1.8 series? If not, then this is probably a duplicate bug report of 555199. In the mean time, I've created a bug report upstream for you. https://sourceforge.net/p/liferea/bugs/1120/ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#726091: Processed: Re: Bug#726091: liferea: Does not connect through proxy anymore.
notforwarded 726091 retitle 726091 libsoup: Cannot connect to proxy on localhost. reassign 726091 libsoup2.4-1 thanks. On 10/13/2013 01:33 AM, Debian Bug Tracking System wrote: Processing commands for cont...@bugs.debian.org: forwarded 726091 https://sourceforge.net/p/liferea/bugs/1120/ Bug #726091 [liferea] liferea: Does not connect through proxy anymore. Set Bug forwarded-to-address to 'https://sourceforge.net/p/liferea/bugs/1120/'. Upstream has closed this bug out as being due to the library libsoup. I'm reassigning this bug report to the libsoup package. -David -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#555199: liferea: 'localhost' doesn't work as proxy host
retitle 555199 libsoup: 'localhost' doesn't work as proxy host reassign 555199 libsoup2.4-1 thanks. When I enter 'localhost' as the proxy host, Lifera fails with the message: HTTP error code 0: Unable to connect to proxy Liferea Upstream has determined that this is an issue with libsoup. Reference: http://sourceforge.net/p/liferea/bugs/1120/ -David -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#726089: Processed: Re: Bug#726089: liferea: Crashes on font decrease.
tag 726089 fixed-upstream thanks. Thank you for reporting this bug report. Upstream has fixed this bug in their git repository. The fix will be included in the next release. -David -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#727536: liferea: crash when clicking on last unread item,version graph
forwarded 727536 https://sourceforge.net/p/liferea/bugs/1127/ thanks. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#731664: liferea: Segmentation fault during startup (gdb info)
forwarded 731664 https://sourceforge.net/p/liferea/bugs/1121/ severity 731664 important thanks. On 12/09/2013 08:50 AM, Andrzej Filip wrote: On 12/08/2013 02:03 PM, tinytinyrss.serv...@gmail.com wrote: Can you try running: dconf write /org/gnome/liferea/last-item-selected 0 and let me know if that fixes it? It fixed no start at once. There has been one or two 'segmentation faults AFTER startup but liferea seems to be back to normal. Upstream reported this issue fixed in 1.10.2, but it looks like this bug is still around. Arch linux users have also reported getting this bug. Thanks again for the bug report, it's been sent upstream and we're waiting for a fix. -David -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#705093: pmacct cannot create postgres table
On 04/22/2013 03:15 PM, Jamie Wilkinson wrote: I suppose postgres has restricted what a timestamp can be since this was created. However that doesn't make sense to make the insertion date default to the year . stamp_inserted timestamp without time zone NOT NULL DEFAULT '-01-01 00:00:00', That line is straight from /usr/share/doc/pmacct/sql/pmacct-create-table_v7.pgsql in the installed package. It's also in the other pmacct-create-table .pgsql files for different table versions. I set it to '2001-01-01 00:00:00' for my table creation and postgres took it without any complaints. Perhaps now() would be more appropriate? Maybe then, the stamp_inserted field will default to the time that the record is actually inserted into the table? I've just started using postgres myself and I'm loving it. The pmacct package is also extremely useful to me. Thanks for your time, -David -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#712961: liferea crashes on read of 2nd item
forwarded 712961 https://sourceforge.net/p/liferea/bugs/1114/ tags 712961 confirmed upstream thanks. Related discussionpatch: https://sourceforge.net/mailarchive/message.php?msg_id=31041040 Thank you for reporting this bug. -David -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#707212: tt-rss: Wrong syntax in logrotate script
Without the patch, I was getting daily e-mails to root as follows: /etc/cron.daily/logrotate: error: tt-rss:prerotate or postrotate without endscript error: found error in file tt-rss, skipping Now with this endscript patch, I'm getting daily e-mails to root as follows: /etc/cron.daily/logrotate: Restarting Tiny Tiny RSS update daemon: tt-rss. I think both e-mails to the root account are equally annoying :). It doesn't appear that restarts of the tt-rss daemon are getting logged in the tt-rss log file, so would it make sense to just push this restart message into the tt-rss log file instead of having it being sent as an e-mail to root? With or without the patch, the logrotates are working, so this seems to be mostly a cosmetic thing. -David -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#707212: tt-rss: Wrong syntax in logrotate script
On 06/06/2013 04:37 PM, David Smith wrote: With or without the patch, the logrotates are working, so this seems to be mostly a cosmetic thing. Spoke too soon there... Just realized that without the patch the logrotate is running but generates nothing but 20 byte empty compressed log files and let's the tt-rss log file keep growing in size... After the patch, the logrotate actually compresses the tt-rss logfile properly. So the patch is definitely an improvement... Although I get an e-mail to root about the tt-rss daemon restarting everyday :). -David -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#707212: tt-rss: Wrong syntax in logrotate script
After the patch, the logrotate actually compresses the tt-rss logfile properly. So the patch is definitely an improvement... Although I get an e-mail to root about the tt-rss daemon restarting everyday :). -David Also, when running tt-rss with the update2 daemon (forking) as configued in /etc/default/tt-rss. I get an additional warning from logrotate about the file size changing while zipping. /etc/cron.daily/logrotate: Forking! Restarting Tiny Tiny RSS update daemon: tt-rss. gzip: stdin: file size changed while zipping -David -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#738099: O: liferea -- news aggregator for online news feeds
On 02/08/2014 02:29 AM, Emilio Pozuelo Monfort wrote: On 07/02/14 18:59, Rodrigo Gallardo wrote: I have not been acting as a responsible developer for several years now. I am orphaning all my packages and will be submitting my resignation soon. I'm taking over this, likely with the rest of the co-maintainers. Thanks Rodrigo for all your work! Regards, Emilio Thank you Emilio for taking over this package. I want to continue helping out with the packaging as much as I can. -David -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#736073: liferea: problem adding https url
On 01/19/2014 09:02 PM, Kevin Walke wrote: Package: liferea Version: 1.10.3-1 Severity: important Dear Maintainer, * What led up to the situation? I was adding some new feeds to liferea * What exactly did you do (or not do) that was effective (or ineffective)? I added the rss feed: https://fsfe.org/news/news.en.rss * What was the outcome of this action? recieved the error: The last update of this subscription failed! HTTP error code 0: Unable to resolve destination host name and the url was parsed as: http:/https:/fsfe.org/news/news.en.rss (try clicking the link!!) and then it clearly failed to add the feed Hello! How did you add this feed? Did you click the New Subscription button or did you use some other way? I tried clicking the new subscription button and I pasted in https://fsfe.org/news/news.en.rss And it result in no problems or errors and the feed loaded ok. Also, do you have an HTTP proxy configured in your settings? -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#736073: liferea: problem adding https url
forwarded 736073 https://sourceforge.net/p/liferea/bugs/1135/ tag 736073 confirmed thanks. On 01/20/2014 02:12 AM, Kevin Walke wrote: On 19/01/14 16:47, David Smith wrote: Hello! Hey, I forgot to say this was using the 'liferea-add-feed' script as called by iceweasel, no HTTP Proxy. I've done some investigation and this is what I've found... Iceweasel sends a normal unencrypted http url to `liferea-add-feed` with 'feed:' syntax : e.g. http://silentcircle.wordpress.com/feed/; becomes: feed://silentcircle.wordpress.com/feed/ BUT an https:// URL is badly formatted: https://fsfe.org/news/news.en.rss; becomes: feed:https://fsfe.org/news/news.en.rss; ...which liferea doesn't handle well. Hello again. Thank you for your investigative work in figuring out the source of your problem. According to RFC-3986, as weird as it may seem, feed:https:// is in fact the correct formatting for feed URIs through HTTPS. I managed to change the liferea-add-feed script to support the https URL's, though it seems it is actually iceweasel providing a strange URL? Attached is new version of liferea-add-feed which makes it work how I expect if you're interested. Just to be clear, this isn't an iceweasel bug, it's a liferea bug. I have created a bug report here: https://sourceforge.net/p/liferea/bugs/1135/ Thanks for such a quick response! And thank you for your investigative work and your patch! -David -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#720767: pulseaudio: Crackling sound on startup until module-suspend-on-idle kicks in
I've also had crackling and popping problems with pulseaudio ever since I started using it about a year ago. I've got a regular Intel sound card in an Ivy Bridge laptop. After about a year of ripping my hair out, I finally tracked my problem down. /etc/pulse/default.pa Try setting load-module module-udev-detect tsched=0 Then rebooting. That completely fixed it for me and it's been weeks and I haven't heard a single crackle or pop. I was hoping if you could give it a try and report back to see if that was your problem as well. It looks like this is a very common problem. -David -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#687045: pulseaudio: Audio delay and crackling at startup
I've also had crackling and popping problems with pulseaudio ever since I started using it about a year ago. I've got a regular Intel sound card in an Ivy Bridge laptop. After about a year of ripping my hair out, I finally tracked my problem down. /etc/pulse/default.pa Try setting load-module module-udev-detect tsched=0 Then rebooting. That completely fixed it for me and it's been weeks and I haven't heard a single crackle or pop. I was hoping if you could give it a try and report back to see if that was your problem as well. It looks like this is a very common problem. -David -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#739262: Liferea always crashes when i try to watch embedded videos
On 02/17/2014 03:52 AM, Thibaut wrote: Package: liferea Version: 1.10.3-1 Hi, Liferea always crashes when I try to watch videos. In terminal I get this message : (process:19311): GLib-CRITICAL **: g_slice_set_config: assertion 'sys_page_size == 0' failed Erreur de segmentation See this page for an exemple http://korben.info/promouvoir-defendre-le-logiciel-libre.html I'm running Debian GNU/Linux 64 bits Sid with GNOME : Linux debian 3.12-1-amd64 #1 SMP Debian 3.12.8-1 (2014-01-19) x86_64 GNU/Linux libc6 2.17-97 libglib2.0-0 2.38.2-5 liferea 1.10.3-1 Thanks Hello, I wasn't able to reproduce the problem. Here's what I tried.. 1. Right clicked on an article and chose to open in browser 2. In the URL, I put in the URL that you gave me. 3. Went down to the youtube video and clicked play Youtube video played just fine. Since it's a youtube video, it might be possible this is a flash or webm plugin problem. If you're still getting this problem, a gdb trace would be helpful. Or if you could be more specific about how you're getting the crash (internal vs. external browser), that would be helpful as well. I don't believe that the Glib-CRITICAL error is particularly helpful as it seems to be just saying that the browser isn't returning any data. As to why that may be the case, it's going to take a bit of a work to figure it out. Best regards, David Smith -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#739262: Liferea always crashes when i try to watch embedded videos
On 02/18/2014 06:18 PM, David Smith wrote: On 02/17/2014 03:52 AM, Thibaut wrote: Hello, I wasn't able to reproduce the problem. Also, make sure you check the liferea preferences to make sure liferea is opening the page in a browser that you're expecting it to. A google search suggests this particular Glib-CRITICAL error might be coming from firefox. Try starting the browser you're trying to use by itself and see if it works. Hope this helps. -David -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#668031: liferea: Fails to read/convert old (1.6) database and aborts
** (liferea:9708): WARNING **: Unexpected status on SQL execution: 11 (database disk image is malformed) Can you try doing an apt-get install sqlite3.. Then run sqlite3 ~/.liferea_1.6/liferea.db pragma integrity_check Then report back if it's ok or not? It's been 6 months and I haven't heard back. This is an old bug report and it might be caused by a corrupted file. If you want to work with me to figure out the cause of this, let me know. Otherwise, I'll close it out. -David -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#725896: liferea: Upper right panel in normal view is always at minimum size when opening liferea
On 04/15/2014 02:14 AM, Simone wrote: I reported this problem upstream and it seems it has been accepted as a bug https://github.com/lwindolf/liferea/issues/9 The real question is, if you run Gnome3, does this happen? I keep meaning to test that out. Upstream fixed the bug with the background colors a while back in the 1.10RC on desktops other than Gnome3. This started happening as a result of that patch. It has something to do with how the window panes are initialized and I'm guessing it's happening the way it is, because we're not running Gnome3. Upstream runs Gnome3 so upstream may not be able to easily reproduce this problem. Regards, -David -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#725896: liferea: Upper right panel in normal view is always at minimum size when opening liferea
On 04/15/2014 05:03 AM, David Smith wrote: On 04/15/2014 02:14 AM, Simone wrote: I reported this problem upstream and it seems it has been accepted as a bug https://github.com/lwindolf/liferea/issues/9 The real question is, if you run Gnome3, does this happen? I keep meaning to test that out. Upstream fixed the bug with the background colors a while back in the 1.10RC on desktops other than Gnome3. This started happening as a result of that patch. It has something to do with how the window panes are initialized and I'm guessing it's happening the way it is, because we're not running Gnome3. Upstream runs Gnome3 so upstream may not be able to easily reproduce this problem. Regards, -David Alright so I went ahead and installed Gnome3 and it seems that's exactly the case. With Gnome3 installed, the bug doesn't happen at all. Let me know if you get a different result. You know what's really bizarre? After I installed Gnome, the bug no longer happens on KDE or XFCE either, as a regular user. So even if upstream installed XFCE or KDE and tried to reproduce it, they wouldn't be able to. Maybe it has something to do with the existance of some Debian desktop configuration files? I'm betting it's got to have something to do with a gnome configuration file somewhere that gets created when gnome is installed and liferea is trying to use it. -David -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#725896: liferea: Upper right panel in normal view is always at minimum size when opening liferea
On 04/15/2014 05:26 AM, Simone wrote: I've tried with XFCE, MATE and GNOME Shell on Debian Testing and the problem remains. Moreover, if I run the program as root the problem does not occur. Can you try checking the permissions of ~/.config/liferea? Make sure that it isn't owned/controlled by root. I don't believe the window positions are actually stored in this location though. They *might* be stored in ~/.config/dconf So check the permissions in there too. I'm now at a point where the bug isn't happening and I can't reproduce it. I removed gnome desktop and the bug is still gone.. In short, installing gnome desktop, running it, and then removing gnome desktop seems to have fixed it. I tried installing Debian Unstable in a VM and the bug doesn't even show up there with a vanilla install which make me to think that maybe it was a problem with my home dir? Possibly caused by an old config file from liferea 1.8? Not sure. I'd suggest to try creating a new user account and see what happens. -David -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#744887: liferea: subscription prop/source: not all fields and buttons visible
forwarded 744887 https://sourceforge.net/p/liferea/bugs/1150/ thanks. On 04/15/2014 02:24 PM, Paul Gevers wrote: Package: liferea Version: 1.10.8-1~bpo70+1 Severity: minor While browsing through the options of liferea, I noticed that in the Subscription Properties window in the Source tab, I don't see what I assume are the bottom text, fill in field and button. Please see the attached screenshot. This wouldn't be so bad if I could resize the window, but that seems not to be possible. Just eyeballing it, it looks like your font is slightly larger than mine and you need 3 lines of text below the conversion filter checkbox and the whole dialog box looks like it's hardcoded to a specific height. I've sent it upstream.
Bug#687045: pulseaudio: Audio delay and crackling at startup
On 04/18/2014 06:01 PM, Felipe Sateler wrote: This may be a problem of too high CPU usage. Can you try changing the resample-method key in daemon.pa? I think the 'trivial' resampler should be the less cpu-hungry, so you should probably try that first. That doesn't make any sense though, my laptop is an 8-core laptop that's sitting idle almost all the time when the crackling/popping happens. It *COULD* be something related to the frequency of my CPU changing.. I realized that the new intel power management stuff is clocking my CPU all over the place.. In the old days it would only cycle between 3 or 4 different frequencies and it would be very slow about reclocking.. Now it's almost instantaneous reclocking of the CPU to save power and it's got a lot of different frequencies it can clock to.. If I set my CPU to a fixed frequency, either the lowest or the highest possible frequency the CPU supports, the entire problem disappears. But I'm not going to run my CPU on a fixed frequency like that because it's always either inconveniently slow or a power hog. So I need to use the configuration change to pulseaudio described above which seems to fix the problem entirely. -David -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#666145: Displays Fatal: cannot retrieve browser command! when a link is clicked
On 04/19/2014 07:05 PM, Carnë Draug wrote: Package: liferea Version: 1.10.8-1 Followup-For: Bug #666145 Dear maintainer, The original report and all comments are related to the version in Debian Wheezy (currently stable). This comment is just to report the issue is still present in Jessie with liferea version 1.10.8. Can you please check Tools - Preferences - Browser - Browser If you have a browser set there that isn't installed then you're going to get an error. We've tried to suggest to upstream that maybe they should only list browsers installed on the system but they think it makes the browser configuration unnecessarily complicated and it also makes sense in a way, because they want to make sure they only list browsers there that they've confirmed to work with liferea (as far as passing urls to the browser and such, it isn't as standardized as it should be). You can use the generic x-www-browser option and then configure which browser to use with update-alternatives --config x-www-browser. As you add/remove browsers from the system, dpkg will automatically update the x-www-browser option so if you set that in liferea it *should* always work. If it doesn't, let me know. Last I checked, x-www-browser is the default.. And so long as you have a web browser on your system installed from the debian repos, x-www-browser should point to it. Otherwise, you will need to configure it manually. Let me know what browser you have configured in liferea and whether or not you have that browser installed. Keep in mind that Firefox is not the same as Iceweasel because the app specifically expects the firefox bin to be in your user's path. -David -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#666145: Displays Fatal: cannot retrieve browser command! when a link is clicked
On 04/19/2014 08:26 PM, David Smith wrote: Can you please check Tools - Preferences - Browser - Browser And naturally I forgot to mention that the Default Browser listed in Liferea refers *SPECIFICALLY* to the Gnome desktop default browser.. ie: It would require the desktop-file-utils package to be installed. That's why we go with the x-www-browser option as the default for liferea in Debian as the x-www-browser is automatically updated by dpkg while the Default Gnome desktop browser is not automatically updated since it's a user config that you set in Gnome. If you have Default Browser listed there, it might be a user configuration that's left over from a previous version and you're just going to have to change it to x-www-browser or something else. I mean, we could always migrate Default Browser user setting to the x-www-browser user setting in liferea to be sure they don't get this error but that's screwing around with user's configurations that they've already set or was set by a previous version of liferea installed on the system and that's probably bad practice. Hope that helps. -David -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#666145: Displays Fatal: cannot retrieve browser command! when a link is clicked
On 04/21/2014 09:53 AM, Carnë Draug wrote: On 20 April 2014 02:35, David Smith sidic...@gmail.com wrote: Indeed, I have upgraded from Debian Wheezy and kept the same home directory. Changing the browser from Default browser to x-www-browser as you mentioned fixed the problem. However, my default browser is Iceweasel, and Gnome is configured to use Iceweasel as default. Going to Settings Details Default applications Web I have Iceweasel selected there. I would expect this default to be used. Carnë The command that liferea uses is gtk_show_uri because it needs to use it for all web links. So try using gnome-open http://www.google.com from a command-line and report back what happens. Also try using gnome-open mailto:666...@bugs.debian.org and see if that works too. If you don't have gnome-open on your system, use xdg-open instead. Should give you the same results. The configuration for your mime types is in ~/.local/share/applications/mimeapps.list Try running cat ~/.local/share/applications/mimeapps.list | grep http If you see anything in there that is no longer installed in your system you're going to have to fix it. You could always backup to another location and delete ~/.local/share/applications/mimeapps.list which should cause your desktop environment to regenerate it. Let me know if this doesn't help. -David -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#742009: liferea: New upstream release 1.10.7
On 03/23/2014 04:50 AM, Christian Marillat wrote: David Smith sidic...@gmail.com writes: On 03/18/2014 08:10 AM, Christian Marillat wrote: David Smith sidic...@gmail.com writes: Should be all set now. No problems that I've found.. Although I've only tested 1.10.7 for a little over 40 minutes now :D. Good news then. I hope you can upload a new package quickly. Christian Unfortunately it didn't last long.. I got 1.10.7-1 compiled and installed. It ran perfectly fine for about 24 hours.. When I booted up today, it's not running.. Worse, it's Segfaulting everytime I try to start it up.. Then the amd64 package work for me installed from scratch without configuration. I see only these warning messages. I created a more detailed way to reproduce the problem here: https://sourceforge.net/p/liferea/bugs/1142/#f50c But the potential for it to always segfault on startup seems like a pretty nasty bug. Even though technically it might not have happened on previous versions due to flaws in previous versions not even being able to add this feed at all. When I run liferea 1.10.4, the feed disappears and I can't seem to add it no matter what I do. 1.10.7 seems to allow it to be added if you try hard enough, but then just crashes later. -David -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#742411: Segmentation fault when Ctrl+Space pressed after startup
On 03/23/2014 09:01 AM, Matt Kraai wrote: Package: liferea Version: 1.10.3-1 Hi, If I start up liferea and immediately press Ctrl+Space, it crashes. Here's the backtrace: #0 liferea_htmlview_scroll (htmlview=0x0) at liferea_htmlview.c:490 #1 0x0044c1c0 in itemview_scroll () at itemview.c:319 #2 0x004500fc in on_key_press_event (widget=0x5a41b0, event=0x5b34d0, #data=optimized out) at liferea_shell.c:575 #3 0x75b270b8 in ?? () from /usr/lib/mipsel-linux-gnu/libgtk-3.so.0 Sounds like a duplicate of https://sourceforge.net/p/liferea/bugs/1142/. If the htmlview is updated by subscription_process_update before htmlview is finished being created, it crashes. It sounds to me like a threading problem. Also seeing this on the latest version 1.10.7 with my testing done for Debian unstable packaging. Thanks for the report. -David -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#667973: liferea: Custom date format doesn't work anymore
tags 667973 wontfix done. On 03/23/2014 08:09 PM, Marcelo Lacerda wrote: Considering that the upstream maintainer have adamantly stated that he will not implement the requested feature, should this bug be marked as wontfix? Yes. In short, it appears that the upstream maintainer doesn't believe that every software application ever made should go out of it's way to present a configuration option to the user to change how that one application presents date and time to the user. I can't blame him. In my opinion, applications would be user friendly if they had more consistency about these kinds of things. From what I read above it seems that liferea will continue displaying date/time based on language/locale settings. So marking as wontfix seems appropriate. I'd assume that now with GTK3 there would be a way to specify custom date/time formatting and have it applied across all GTK3 applications. Is that not the case? -David -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#677696: liferea: default date format doesn't give the right date information
The default date format (currently the only one due to bug 667973) doesn't give correct information. For instance, for some item, it was saying Aujourd'hui 22:00 (Today 22:00) instead of Yesterday 22:00. I suppose that the reason is that the date information is not updated after midnight. I just saw with my own eyes a bunch of Todays turn into Yesterdays in Liferea 1.10.7 so I'll mark this bug as closed out in the 1.10.7 changelog.. -David -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#742009: liferea: New upstream release 1.10.7
On 03/23/2014 02:35 PM, Paul Gevers wrote: On 23-03-14 17:31, Christian Marillat wrote: David Smith sidic...@gmail.com writes: [...] I created a more detailed way to reproduce the problem here: https://sourceforge.net/p/liferea/bugs/1142/#f50c But the potential for it to always segfault on startup seems like a pretty nasty bug. Even though technically it might not have happened on previous versions due to flaws in previous versions not even being able to add this feed at all. When I run liferea 1.10.4, the feed disappears and I can't seem to add it no matter what I do. 1.10.7 seems to allow it to be added if you try hard enough, but then just crashes later. Adding this feed doesn't crash i386 or amd64 liferea. I think you have miscompiled liferea. Hi David, I also tried to reproduce your test case. For what it is worth, after adding intltoolize to the override_dh_autoreconf target and compiling the package from the Alioth git (targeting wheezy-amd64) also I can't reproduce your test case. Paul Hmm.. Have you tried moving ~/.config/liferea out of the way to reset your configuration to the defaults and then try loading up liferea again? For me, It's crashing when it's trying to save an Etag and it says the Etag is out of bounds. The ETag comes from the HTTP header (which you can check with wget -S --spider url).. So it really sounded to me like it's something wrong with specific feeds.. Looking at it further, liferea uses libsoup to grab the Etag and according to libsoup's documentation the value will always be either null or the etag. Liferea checks for null and it's not null.. It's just out-of-bounds when it tries to store it internally. Upstream has suggested that startup crashes like this might be a race condition.. Where it's going out and getting the feed's HTTP header in a separate thread and then returning it back to the application so fast that the object that stores it, inside of the application, hasn't even been initialized yet. I guess that would require a very fast Internet connection and a very slow CPU to crash there if that was the case. I've got the fast internet connection 1000Mbit but I didn't think my CPU was particularly slow. On another note, I believe I've got 1.10.7-1 in the git repo all set for a review for upload into unstable. Let me know if you find any problems. Respectfully, -David -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#742009: liferea: New upstream release 1.10.7
On 03/25/2014 03:40 PM, Emilio Pozuelo Monfort wrote: On 25/03/14 21:31, Paul Gevers wrote: So you want me to upload? This means that you consider the bug we have been discussing so far as not the regression you thought it to be? To be honest, I think it does have a regression starting in 1.10.7 related to etags (new feature). I made a bug report upstream about it and then I was going to contact Lars (upstream) about it but then I realized that all the etags stuff wasn't even written by Lars at all. I'm not really in a position to guess how big or little the etags crash is.. For me, it happens enough to be very annoying. The only thing 1.10.7 adds is the etags stuff so I think I should be able to just dig through that and figure out what's happening. I'm going to be contacting the etags dev for liferea and hoping that I can get a quick response. If 1.10.7 seems to be working ok for you guys then I'd say just go ahead and do the upload and I'll do an update as soon as upstream makes a patch for it. On 03/25/2014 03:40 PM, Emilio Pozuelo Monfort wrote: On 25/03/14 21:31, Paul Gevers wrote: Yes, I like to fix bug 738099. David, I assume you want to claim maintainership of liferea. I think you deserve it, so please do (unless Emilio now starts complaining). I'm fine with that. David, you've done an amazing job at taking care of liferea. Best regards, Emilio Sure. I haven't gotten around to reading all the documentation that I need to be a maintainer, but I'll start reading it in the next few days. I'd be more than happy to maintain liferea. Respectfully, -David -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#742009: liferea: New upstream release 1.10.7
On 03/26/2014 04:47 AM, Emilio Pozuelo Monfort wrote: On 26/03/14 08:08, David Smith wrote: On 03/25/2014 03:40 PM, Emilio Pozuelo Monfort wrote: On 25/03/14 21:31, Paul Gevers wrote: So you want me to upload? This means that you consider the bug we have been discussing so far as not the regression you thought it to be? To be honest, I think it does have a regression starting in 1.10.7 related to etags (new feature). I made a bug report upstream about it and then I was going to contact Lars (upstream) about it but then I realized that all the etags stuff wasn't even written by Lars at all. I'm not really in a position to guess how big or little the etags crash is.. For me, it happens enough to be very annoying. The only thing 1.10.7 adds is the etags stuff so I think I should be able to just dig through that and figure out what's happening. I'm going to be contacting the etags dev for liferea and hoping that I can get a quick response. If 1.10.7 seems to be working ok for you guys then I'd say just go ahead and do the upload and I'll do an update as soon as upstream makes a patch for it. I think you've been right in your concerns. If liferea crashes for you 100% of the time on startup, it'll probably crash the same way for a few users. Since this new feature is not critically needed, we could upload 1.10.6 instead until this crash is analyzed and fixed. Emilio 1.10.6 is packaged in git and ready for upload to unstable. -David -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#742009: liferea: New upstream release 1.10.7
On 03/26/2014 01:54 PM, Paul Gevers wrote: On 26-03-14 18:10, David Smith wrote: On 03/26/2014 04:47 AM, Emilio Pozuelo Monfort wrote: On 26/03/14 08:08, David Smith wrote: On 03/25/2014 03:40 PM, Emilio Pozuelo Monfort wrote: On 25/03/14 21:31, Paul Gevers wrote: So you want me to upload? This means that you consider the bug we have been discussing so far as not the regression you thought it to be? To be honest, I think it does have a regression starting in 1.10.7 related to etags (new feature). I made a bug report upstream about it and then I was going to contact Lars (upstream) about it but then I realized that all the etags stuff wasn't even written by Lars at all. I'm not really in a position to guess how big or little the etags crash is.. For me, it happens enough to be very annoying. The only thing 1.10.7 adds is the etags stuff so I think I should be able to just dig through that and figure out what's happening. I'm going to be contacting the etags dev for liferea and hoping that I can get a quick response. If 1.10.7 seems to be working ok for you guys then I'd say just go ahead and do the upload and I'll do an update as soon as upstream makes a patch for it. I think you've been right in your concerns. If liferea crashes for you 100% of the time on startup, it'll probably crash the same way for a few users. Since this new feature is not critically needed, we could upload 1.10.6 instead until this crash is analyzed and fixed. Emilio 1.10.6 is packaged in git and ready for upload to unstable. Hi David, First, (don't get me wrong, I only try to teach here) please read http://www.git-scm.com/book/en/Git-Branching-Rebasing and especially the line: Do not rebase commits that you have pushed to a public repository. No big harm, but the current history looks slightly messy. Yeah, it didn't end up at all like I expected. On my side it looked like I was moving commits in my local branch but when it finally got to the point of pushing it into the server, it wouldn't let me push the rebase.. It said I had to do a pull first, and that ended up recalculating all the work I did and putting it after the last commit in the master branch. Needless to say the end result in the git history didn't look at all like what I had in my git log but it accomplished the same thing. I google searched it and saw a lot of people saying to just do a rebase in my situation, but I guess I probably should have just created a branch at 1.10.5, brought in 1.10.6 and then merged in the changes from 1.10.7 I needed applied to 1.10.6 too... And left the master branch alone at 1.10.7. If I knew the git summary would look the way it does, I wouldn't have done it. Furthermore, I saw Lars released 1.10.8 today to fix/work around you issue. Wouldn't you rather have that version? If not, I will probably upload tomorrow. It's not a fix for my crash, it's a fix for another crash related to hitting a scroll button before the GUI loads. Lars told me to try it anyway, and it's the next thing I'm going to do. Lars said he's looking for some help on rewriting some of the GUI so that it checks dependencies better to reduce crashes on startup. I guess if there's anybody that's really good at programming, maybe they can give upstream some help. I deal mostly with higher level languages so I'm not too experienced with C. -David -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#742009: liferea: New upstream release 1.10.7
On 03/26/2014 01:54 PM, Paul Gevers wrote: Furthermore, I saw Lars released 1.10.8 today to fix/work around you issue. Wouldn't you rather have that version? If not, I will probably upload tomorrow. I must have missed something because 1.10.8 does seem to fix it as I haven't had a crash at all and I've been using it since 1.10.8 came out (about a full day now) and I've been actively trying to reproduce the crash without success. I think I remember some time ago that Luis Rodrigo wanted to give up maintainership of liferea. So I replaced his name with mine. If that wasn't the right thing to do, let me know and I'll fix it. 1.10.8 is packaged and ready on the git repo. Respectfully, -David Smith -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#745842: liferea: description is too geeky
On 05/05/2014 01:58 PM, Mattia Rizzolo wrote: On Mon, May 5, 2014 at 4:36 AM, David Smith sidic...@gmail.com wrote: How's this look? Looks (and sounds, the sound is important :) ) fine to me too. Maybe would be better to capitalize Linux Feed Reader to highlight the fact that liferea is it's short, but this is a quibble ;) Well, I'll believe that I should probably capitalize Linux. Since Linux is a trademark and should be capitalized. [1] Feed Reader I think I'll leave it as it is. It's in the same boat as words like website where there are a lot of different websites out there so you wouldn't capitalize it. 1: http://en.wikipedia.org/wiki/Wikipedia:Manual_of_Style/Trademarks -David -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#692284: Option for x-www-browser
On 05/10/2014 03:57 PM, Daniel Leidert wrote: Hi, Indeed, bluefish does not come with a command string for x-www-browser. Of course, x-www-browser (probably) exists only on Debian-based systems. Therefor there won't be such a command string in bluefish upstream source. There are also differences in the browser commands used to show a page. Of course we can use x-www-browser '%p' But what is the benefit to add this to the Debian package? Regards, Daniel The external command I'm using in Bluefish: x-www-browser -remote 'openURL(%p)' || x-www-browser '%p' As far as the benefit, bluefish is opening a web browser by default that isn't configured as the user's default web browser. I've got Chromium set as the default web browser in KDE, I've got Chromium set as the default web browser with update-alternatives --config x-www-browser. And yet, a fresh install of bluefish with no configuration files launches iceweasel/firefox. What happens when you install bluefish without the iceweasel / firefox package? Well, Bluefish doesn't launch *ANYTHING* then because Bluefish keeps it's own separate config file for which web browser to use and it doesn't even get that information from anywhere, it just makes it up and if you don't have iceweasel/firefox then the configuration it makes up will be flatly wrong and the application won't work as the user expects it to. The worst part is, clicking on the globe/web browser / Preview in Browser button does absolutely nothing at all by default if you don't have iceweasel/firefox installed.It doesn't even give you an error message that the reason it's not working is because you don't have iceweasel/firefox installed. Instead, you sit there wondering if the application is completely busted or you need to go digging through screens and screens of configuration to find the one option that will allow you to launch a web browser.. Then when you find that option, you set it to a web browser you have installed.. And then a week later you uninstall that web browser and you get to go through the whole thing all over again. I highly doubt that's any user's idea of having a good time. That seems rather silly.. Since: update-alternatives will always keep x-www-browser pointed to a browser installed on the system no matter what you install/uninstall. (ie: Your Preview in browser button in your application will never be broken if you point the app to use x-www-browser by default, so long as the user has at least one X compatible web browser installed on the system. Again, it's just my 2 cents. But I'm getting tired of seeing so many applications have their own configuration option for which web browser to use and everytime I open the applications up it seems like I have to go digging through configuration files to change it... That's part of the reason why x-www-browser is the default option in my liferea package.. To make sure the application just works after it's installed without forcing the user to find the configuration option to properly configure the browser. It might launch a browser that's not the default configured for the desktop environment (because every desktop environment crams that config in a different location somewhere and it's a pain to go checking for them all). But at least when a user starts the app, it works and they can go and configure it later. It is of my opinion that applications should be properly configured when they're installed.. This doesn't mean you have to create some fancy script to figure out what browser the user likes or what desktop environment they're running or what the configured web browser for that desktop environment is.. Rather just use something that works all the time so the user doesn't take one look at the application and think it's broken.. I'm one of the people that is of the belief that if you freshly install and application and something doesn't work right out of the box because of a configuration error, then there's something wrong with the installation / default configuration of the package. For Bluefish, it won't work properly out of the box if iceweasel/firefox is not installed and it won't even tell the user what's wrong in a message box. -David -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#748456: liferea: crashes when selecting any feed
On 05/17/2014 07:30 AM, Johannes Schauer wrote:
Package: liferea
Version: 1.10.8-1
Severity: grave
Justification: renders package unusable
Hi,
steps to reproduce:
--%---
$ sudo debootstrap --variant=minbase sid debian-sid
http://127.0.0.1:3142/http.us.debian.org/debian
[...]
$ sudo chroot debian-sid apt-get update
[...]
$ sudo chroot debian-sid apt-get install liferea
[...]
$ sudo chroot debian-sid liferea
(process:28562): Gtk-WARNING **: Locale not supported by C library.
Using the fallback 'C' locale.
(liferea:28562): libnotify-WARNING **: Failed to connect to proxy
--%---
Then, click on any feed on the left hand side. The result will be a
crash of liferea with the following printed on the terminal:
If you go into liferea's preferences and uncheck the checkbox that says
enable javascript. It will stop the crash from happening.
To me, this sounds like a problem with
/usr/lib/x86_64-linux-gnu/libjavascriptcoregtk-3.0.so.0 since that is
where the execution is ended up right before it crashes.
Unless you disagree, I'm going to move this bug report to the
libjavascriptcoregtk-3.0 package.
Attached is the bt full gdb trace that I obtained to reproduce the
crash using your instrucitons.
-David
bt full
#0 0x715ca55c in WTFCrash () at ../Source/WTF/wtf/Assertions.cpp:333
No locals.
#1 0x714d100b in JSC::VMEntryScope::requiredCapacity
(this=this@entry=0x7fffcd50)
at ../Source/JavaScriptCore/runtime/VMEntryScope.cpp:91
interpreter = optimized out
requiredCapacity = 131072
#2 0x714d10b7 in JSC::VMEntryScope::VMEntryScope (this=0x7fffcd50,
vm=..., globalObject=0x7fffcc0ff970)
at ../Source/JavaScriptCore/runtime/VMEntryScope.cpp:57
No locals.
#3 0x7135bf1e in JSC::Interpreter::execute (this=0x7fffcca9fcf0,
program=program@entry=0x7fffcc03fef0,
callFrame=callFrame@entry=0x7fffcc0ff9b0, thisObj=0x7fffcc13ffb0)
at ../Source/JavaScriptCore/interpreter/Interpreter.cpp:770
entryScope = {m_vm = @0x7fffccae8000, m_stackCheckPoint = {No data
fields}, m_stack = {
static s_defaultAvailabilityDelta = 65536, m_origin = 0x0, m_bound
= 0x0}, m_globalObject = 0x7fffcc0ff970,
m_prev = 0x0, m_prevStackLimit = 0x1, m_recompilationNeeded =
false}
JSONPData = {WTF::VectorBufferJSC::JSONPData, 0ul =
{WTF::VectorBufferBaseJSC::JSONPData = {
m_buffer = 0xbadbeef7, m_capacity = 3758986912, m_size = 32767},
No data fields}, No data fields}
programSource = {m_impl = {m_ptr = 0x7fffce68}}
parseResult = optimized out
protoCallFrame = {codeBlockValue = {u = {value = -8574853690035138576,
callFrame = 0x89001c820ff0, codeBlock =
0x89001c820ff0, encodedValue = {asInt64 = -8574853690035138576, ptr =
0x89001c820ff0, asBits = {
payload = 478285808, tag = -1996488704}}, number =
-2.4810405218124427e-265,
integer = -8574853690035138576}}, scopeChainValue = {u = {value =
-992678403661674304,
callFrame = 0xf2394c40558b48c0, codeBlock = 0xf2394c40558b48c0,
encodedValue = {asInt64 = -992678403661674304,
ptr = 0xf2394c40558b48c0, asBits = {payload = 1435191488, tag =
-231125952}},
---Type return to continue, or q return to quit---
number = -1.6868647333863707e+242, integer =
-992678403661674304}}, calleeValue = {u = {
value = -3276087253930376689, callFrame = 0xd289004b820f,
codeBlock = 0xd289004b820f, encodedValue = {
asInt64 = -3276087253930376689, ptr = 0xd289004b820f,
asBits = {payload = 4948495, tag = -762773504}},
number = -3.978585894076128e+89, integer =
-3276087253930376689}}, argCountAndCodeOriginValue = {u = {
value = -8410208381381202161, callFrame = 0x8b48f0094cc2af0f,
codeBlock = 0x8b48f0094cc2af0f, encodedValue = {
asInt64 = -8410208381381202161, ptr = 0x8b48f0094cc2af0f,
asBits = {payload = 1287827215,
tag = -1958154231}}, number = -2.6573518219715629e-254,
integer = -8410208381381202161}}, thisArg = {u = {
value = 5276043427988045933, callFrame = 0x4938458b48c3006d,
codeBlock = 0x4938458b48c3006d, encodedValue = {
asInt64 = 5276043427988045933, ptr = 0x4938458b48c3006d, asBits
= {payload = 1220739181, tag = 1228424587}},
number = 5.4127602845995064e+44, integer = 5276043427988045933}},
paddedArgCount = 2215626373,
args = 0x9820ff0394c}
samplingScope = {m_interpreter = 0x7fffcca9fcf0}
codeBlock = 0x7fffd670
result = optimized out
#4 0x7148f39b in JSC::evaluate (exec=exec@entry=0x7fffcc0ff9b0,
source=..., thisValue=...,
Bug#748456: liferea: crashes when selecting any feed
retitle 748456 WTFCrash+0x17 when javascript is enabled (base install) reassign 748456 libjavascriptcoregtk-3.0-0 2.4.2-1 thanks. Note: This only happens with a minimal debian install. Installing a regular DE (such as icewm) this crash doesn't happen. Also, disabling javascript in liferea also makes this crash not happen. -David -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#745842: liferea: description is too geeky7
On 04/25/2014 01:32 PM, Mattia Rizzolo wrote: Package: liferea Version: 1.10.8-1 Severity: wishlist Dear Maintainer, The liferea package long description is too hard to be understanded by anyone but a feed expertise. There are too many technical words, that may misguide a user. Please follow the devref [0] and simplify the long description. Originally submitted as an Ubuntu bug: https://launchpad.net/bugs/602815 Ya, I tweaked it a while ago to include talking about support for TinyTinyRSS synchronization but I should have also removed the part about Google Reader completely since it's long since dead. I never liked the part about being a FeedReader clone because it seems a little irrelevant and confusing to me. That's something that looks like it was just copypasted right off of the liferea website. I've never even heard of FeedReader myself. I'm also not too fond of having acronyms everywhere in the description but the fact remains that people use those acronyms in searches and so they need to be there. I guess I could expand them out to make the long description a bit less geeky. If you have any other suggestions in particular, I'm all ears. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#745842: liferea: description is too geeky7
On 04/25/2014 11:53 PM, David Smith wrote: On 04/25/2014 01:32 PM, Mattia Rizzolo wrote: I never liked the part about being a FeedReader clone because it seems a little irrelevant and confusing to me. That's something that looks like it was just copypasted right off of the liferea website. I've never even heard of FeedReader myself. Apparently it's open source windows software that hasn't had a new release in over 5 years. I really doubt that many people use it anymore so I guess I'll remove that part from the description as well. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#687045: pulseaudio: Audio delay and crackling at startup
On 04/24/2014 08:17 AM, Felipe Sateler wrote: Good to know newer versions might be fixed. I'll wait for your report! Well I've thrown everything I've got at it, games, movies, music, etc. for days and haven't heard a single crackle. So it looks like 4.0-6~bpo7+1 fixes the problem for me. -David -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#745842: liferea: description is too geeky
On 04/27/2014 10:43 AM, Mattia Rizzolo wrote: Liferea is a reader for RSS and Atom feeds. Advanced feeds are also supported, such as RDF, Echo and PIE feeds, CDF channels and OCS directories. . TinyTinyRSS synchronization is supported so that you can synchronize your feeds and (un)read items across multiple devices automatically. It also supports social networking and integration with Facebook, Google+, Reddit, Twitter, Slashdot, Digg, Yahoo and many more, so you can share your favorite news articles. . Liferea is an abbreviation for Linux Feed Reader. Notes: Dropped ECHO/PIE because these are just different names to call the format which became ATOM before it was known as ATOM. Liferea is a linux feed reader that brings together all of the content from your favorite news feeds into an interface that's easy to organize and browse. Supported news formats include Rich Site Summary (RSS), Atom Syndication (Atom), Resource Description Framework (RDF), Channel Definition Format (CDF), and... Does anybody know what an OCS directory is? I know it as an acronym for Microsoft's Office Communications Server, and I know it connects to Active Directories but I really doubt that's what is being referred to here. A google search didn't reveal much. Although there were some hints of an application called OCS Inventory NG making and using .OCS files.. Again, that doesn't make any sense to me since that doesn't seem to have anything to do with news feeds. I tried checking the demo website of OCS Inventory NG but it's down. Then i found something that referred to these .OCS files as being in XML format which then would make sense since it'd be similar to the other file formats liferea supports. I guess that's part of the problem of getting some of these clarified. Lars, any insight would be appreciated. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#746610: liferea: fails to build with clang instead of gcc
forwarded 746610 https://sourceforge.net/p/liferea/bugs/1152/ thanks. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#745842: liferea: description is too geeky
On 05/02/2014 02:25 PM, Lars Windolf wrote: OCS is totally lost these days (it was an OPML alternative for a while). Actually support was removed upstream quite some while ago. So please do not mention it. IMO mentioning RSS and Atom is probably enough for most users. More interesting should be the supported online accounts (TheOldReader and TinyTinyRSS). Cheers, Lars How's this look? Liferea is a linux feed reader that brings together all of the content from your favorite news feeds into an interface that's easy to organize and browse. TinyTinyRSS and TheOldReader connections are supported so that you can synchronize your feeds and (un)read items across multiple devices. Supported news formats include Rich Site Summary (RSS), Atom Syndication (Atom), Resource Description Framework (RDF), and Channel Definition Format (CDF). -David -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#748752: Reopened
On 06/24/2014 08:41 AM, Andreas Glaeser wrote: The problem seemed to be solved, but in fact is is not, the situation with liferea is unchanged, so the report was reopened. Can you make sure you have dbus-x11 installed and if not, install it and see if the problem persists? I'm adding a depend on dbus-x11 to close out #748087 and it might fix this issue as well. That's just a guess since I saw in your bug report that you were getting warnings about not being able to register with the accessibility bus. -David -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#748742: liferea: Crashes some seconds after launch even without user interaction (segfault in libpthread)
On 05/20/2014 06:37 AM, Andrea Lusuardi wrote: Package: liferea Version: 1.10.8-1 Severity: grave Justification: renders package unusable Hi, the package liferea crashes predictably after 3 to 10 seconds from launch, in the dmesg i can see the problem as follows: [46072.157858] pool[8262]: segfault at 10 ip 7f80fc8fa224 sp 7f80ecb8e540 error 4 in libpthread-2.18.so[7f80fc8f+18000] i tried removing the config ($HOME/.liferea*) but the problem persists as soon as i add the first feed. This makes the package mostly unusable. If there are other information you need or ways i can assist in triaging the bug please let me know, thanks Please install the liferea-dbg package and then start liferea as follows: gdb liferea ... ... [crash] bt full Make sure you crab the result of bt full after the crash and post it here as an attachment. -David -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#748742: liferea: Crashes some seconds after launch even without user interaction (segfault in libpthread)
severity 748742 important thanks. On 05/21/2014 02:54 AM, Andrea Lusuardi wrote: On Tue, 20 May 2014 18:22:20 -0500 David Smith sidic...@gmail.com wrote: Please install the liferea-dbg package and then start liferea as follows: gdb liferea ... ... [crash] bt full i had to run the run command to gdb or it would stay blocked indefinitely, hope that does not mess up the backtrace. You can find the trace attached, tia. Can you install the libgnutls28-dbg or libgnutls26-dbg or whichever libgnutlsXX-dbg package depending on which libgnutls you're running? Also can you install your linux kernel's dbg package as well? The crash doesn't seem to be originating from the liferea application and it's just getting forwarded along unless I'm not reading it right. Are you sure there isn't any more pages of text to the bt full output? -David -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#748742: liferea: Crashes some seconds after launch even without user interaction (segfault in libpthread)
On 05/23/2014 05:47 PM, Andrea Lusuardi wrote:\ Note how some of those frames are from libgnutls 26 and some are from 28. That's doomed to fail. See the comments in #748535. will upgrade and try to fix, anything else i can try in the meantime? thanks in advance I'm tempted to just reassign this whole bug report to the libgnutls package. Do you have any objection to that Emilio? -David -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#748742: liferea: Crashes some seconds after launch even without user interaction (segfault in libpthread)
reassign 748742 libgnutls28 thanks. On 05/23/2014 06:36 PM, Emilio Pozuelo Monfort wrote: On 24/05/14 01:26, David Smith wrote: On 05/23/2014 05:47 PM, Andrea Lusuardi wrote:\ Note how some of those frames are from libgnutls 26 and some are from 28. That's doomed to fail. See the comments in #748535. will upgrade and try to fix, anything else i can try in the meantime? thanks in advance I'm tempted to just reassign this whole bug report to the libgnutls package. Do you have any objection to that Emilio? Not at all. This needs to be fixed in gnutls, or everything needs to move to gnutls28 (and gnutls28 should then conflict/break gnutls26). Nothing that we can do from liferea, so reassigning sounds good. Emilio -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#748752: Reopened
On 07/04/2014 05:56 AM, Andreas Glaeser wrote: Yes dbus-x11 package is installed, I recently re-installed the whole system, so everything should be pretty much in factory-default state. Can you check if this still happens with 1.10.9 in unstable? -David -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#750786: liferea crashes on favicon update
On 06/06/2014 05:17 PM, Slosh wrote: I just noticed despite my apt policy some packages were being sourced from deb-multimedia.org that the official repositories supplied. I converted them back and the problem has disappeared. Sorry I don't know exactly which library was creating the problem. It might also be something that's a bit random since liferea schedules actions on timers. I'll keep the bug report open for at least a week. Be sure to report back if you get any more crashes. -David -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#745842: Review package description for liferea (Bug #745842)
On 06/10/2014 05:33 PM, Sidicas . wrote: * downloading articles to read while offline; Just realized how silly this sounds. That's some real magic there. I guess I'll go with: downloading articles for reading offline; -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#739262: Here is the needed information + something strange in the way Liferea is launched and runs
http://lists.cairographics.org/archives/cairo/2014-March/025089.html https://bugs.freedesktop.org/show_bug.cgi?id=76272 Hopefully the Cairo devs will take a look at it at one of the above URLs and give some feedback. -David -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#742009: liferea: New upstream release 1.10.7
On 03/18/2014 01:54 AM, Christian Marillat wrote: Package: liferea Version: 1.10.3-1 Severity: normal Dear Maintainer, Would be nice to know why the latest release isn't packaged... Sorry for the delays, my Internet has been down for days. I spent hours trying to figure out why the new version of liferea wasn't compiling. Apparently release 1.10.7 no longer contained a ./po/Makefile.in.in file which is required since It's referenced by the ./configure.ac. I tried removing the reference in configure.ac with no luck so it's definitely required. In the end, I had to write a patch that basically adds in the po/Makefile.in.in from the previous version into 1.10.7 to get it to compile and run. I have no idea if that's really the correct thing to do and I'll be contacting upstream about it. I'm guessing that the move to github has been a bumpy ride for upstream and for some reason this file might have gotten left out of the github packaging. Rest assured, I have every intention of packaging the latest versions of liferea, ASAP. -David -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#742009: liferea: New upstream release 1.10.7
On 03/18/2014 04:07 AM, Emilio Pozuelo Monfort wrote: I think autoreconf or intltoolize should add it. If so, we can run those before the build. Ya, you're right.. For some reason my pbuilder setup wasn't running autoconf.sh. It never was a problem before, but it does correctly generate the missing file when it's run. I've removed the po/Makefile.in.in patch that I added since it's redundant. Should be all set now. No problems that I've found.. Although I've only tested 1.10.7 for a little over 40 minutes now :D. Thanks for the quick reply, -David Smith -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#742009: liferea: New upstream release 1.10.7
On 03/18/2014 08:10 AM, Christian Marillat wrote: David Smith sidic...@gmail.com writes: Should be all set now. No problems that I've found.. Although I've only tested 1.10.7 for a little over 40 minutes now :D. Good news then. I hope you can upload a new package quickly. Christian Unfortunately it didn't last long.. I got 1.10.7-1 compiled and installed. It ran perfectly fine for about 24 hours.. When I booted up today, it's not running.. Worse, it's Segfaulting everytime I try to start it up.. I went to report a bug about it, but it turns out.. Somebody from Red Hat already did. http://sourceforge.net/p/liferea/bugs/1142/ -David Smith -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#764103: White text on white background when using GNOMEs (adwaitas) built in dark theme
On 10/05/2014 08:40 AM, Guido Günther wrote: since the upgrade to GNOME 3.14 (in sid) liferea displays the current posts content as white text on white background. The feed list and the list of posts are displayed properly though. To reproduce: Thanks for the report, I remember running into a very similar issue in the past when we brought in 1.10 on Wheezy with GTK3. I think it had something to do with liferea reading GTK3 theme data from the user's profile and not getting anything valid. Possibly because the user was using GTK3 apps without ever logging into a Gnome desktop. Something about logging into a Gnome desktop was creating profile data that liferea was trying to read. I'll have to dig it up and figure out why it would still be an issue in Sid. Could you please clarify if you're running Gnome as your DE or not? That would be helpful, thanks! -David -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#764103: White text on white background when using GNOMEs (adwaitas) built in dark theme
On 10/05/2014 09:56 AM, David Smith wrote: Thanks for the report, I remember running into a very similar issue in the past when we brought in 1.10 on Wheezy with GTK3. Hmm, my testing at the time showed that this bug had been fixed http://sourceforge.net/p/liferea/bugs/1095/?page=2 (Page 2) Perhaps it's back again in Sid, I'll have to do some testing in Sid. -David -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#764103: White text on white background when using GNOMEs (adwaitas) built in dark theme
On 10/05/2014 10:14 AM, David Smith wrote: Hmm, my testing at the time showed that this bug had been fixed http://sourceforge.net/p/liferea/bugs/1095/?page=2 (Page 2) Perhaps it's back again in Sid, I'll have to do some testing in Sid. Ah, ok.. Just to be clear, this is a problem with a specific theme then? If you use a different gnome theme, then it works? I noticed that some of the Gnome themes would leave parts of the user's profile blank and liferea still pulls in these blank profile bits and assumes it's valid theme data along with the rest of the theme data and uses it. Resulting in white-on-white or other kinds of visual problems. Honestly, I would say it's probably a bug in the theme that it is missing GTK3 theme data that it's supposed to have, but I'll have to confirm. I remember spending a lot of time doing a lot of testing on this with a lot of different DEs including KDE's themes and they worked fine after the 1.10 release but some themes were missing chunks of GTK3 data for some reason. Possibly because they were originally GTK2 themes that hadn't been fully transitioned to GTK3? I have no idea. -David -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#764103: White text on white background when using GNOMEs (adwaitas) built in dark theme
On 10/05/2014 10:38 AM, Guido Günther wrote: Yes this happens with a specific theme but it's the _build_in_ GTK+ dark theme so no other fancy theme stuff installed besides gnome-themes-standard: Hmm, that's interesting.. As far as I know, Liferea 1.10 and up no longer uses any GTK+ themes, but there are some GTK+ themes that have been remade into GTK3 themes with the same name, which makes for a good bit of confusion. Just out of curiosity, what theme do you have set in ~/.config/gtk-3.0/settings.ini? Here is the testing I just did with the GTK3 Adwaita (dark) and it works: [Settings] gtk-theme-name = Adwaita gtk-application-prefer-dark-theme = true Is it possible that you have a GTK3 theme defined but no longer have any GTK3 themes installed? -David -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#802431: liferea: crashes when viewing properties of subscriptions
> > If I create a new user and run liferea for the first time and > right-clicked a subscription and clicked properties, liferea crashes > with SIGTRAP and the below gdb backtrace. I've reproduced this issue and I am taking a look at it. Thanks for the report. -David
Bug#802431: liferea: crashes when viewing properties of subscriptions
> > If I create a new user and run liferea for the first time and > right-clicked a subscription and clicked properties, liferea crashes > with SIGTRAP and the below gdb backtrace. I've reproduced this issue and I'm taking a look at it. Thanks for the report. -David
Bug#800895: liferea: Over 60 seconds before Liferea application window appears
On 10/04/2015 12:26 PM, Stephen Allen wrote: > > Once the application icon is "clicked" it takes anywhere from 60 to 80 > seconds to launch. Same thing happened on Jessie with Jessie's Liferea > package too. > If you launch it from a console, do you get any interesting output in regards to errors or warnings while you're waiting? I'm not able to reproduce this, can you try moving your .liferea folder out of the way (mv ./.liferea ./.liferea_old ) and starting liferea up again to see if it is something related to the feeds/user configuration/content? To return back to normal, you would: mv ./.liferea ./.liferea.clean mv ./.liferea_old ./.liferea -David
Bug#740432: liferea ask for not existent users/passwords reading feeds if you have a proxy with password
Reproduced on version 1.10.12-1. I'm looking into it. Thanks for the bug report. -David
Bug#750821: sweethome3d crashes when selecting "Preferences"
Setting this also fixes the issue for me as well. I'm also using the Gallium driver.
Bug#547186: g15daemon: Random crashes
Nov 5 08:55:20 Skuld g15daemon: Process died - removing pidfile Nov 5 08:55:21 Skuld g15daemon[4326]: Booting plugin "Clock" Nov 5 08:55:21 Skuld g15daemon[4326]: Plugin "Clock" boot successful. Nov 5 08:55:21 Skuld g15daemon[4326]: Booting plugin "Linux UINPUT Keyboard Output" Nov 5 08:55:21 Skuld g15daemon[4326]: Plugin "Linux UINPUT Keyboard Output" boot successful. Nov 5 08:55:21 Skuld g15daemon[4326]: Booting plugin "LCDServer" Nov 5 08:55:21 Skuld g15daemon[4326]: Plugin "LCDServer" boot successful. Nov 5 09:03:39 Skuld g15daemon[452]: Booting plugin "Clock" Nov 5 09:03:39 Skuld g15daemon[452]: Plugin "Clock" boot successful. Nov 5 09:03:39 Skuld g15daemon[452]: Booting plugin "Linux UINPUT Keyboard Output" Nov 5 09:03:39 Skuld g15daemon[452]: Plugin "Linux UINPUT Keyboard Output" boot successful. Nov 5 09:03:39 Skuld g15daemon[452]: Booting plugin "LCDServer" Nov 5 09:03:39 Skuld g15daemon[452]: Plugin "LCDServer" boot successful. Nov 5 09:03:39 Skuld g15daemon[666]: Starting g15daemon: Nov 5 09:03:39 Skuld systemd[1]: g15daemon.service: control process exited, code=exited status=1 Nov 5 09:03:39 Skuld systemd[1]: Unit g15daemon.service entered failed state. Nov 5 09:05:22 Skuld g15daemon: Process died - removing pidfile Nov 5 09:05:22 Skuld g15daemon[1724]: Starting g15daemon: g15daemon. Nov 5 09:05:22 Skuld g15daemon[1726]: Booting plugin "Clock" Nov 5 09:05:22 Skuld g15daemon[1726]: Plugin "Clock" boot successful. Nov 5 09:05:23 Skuld g15daemon[1726]: Booting plugin "Linux UINPUT Keyboard Output" Nov 5 09:05:23 Skuld g15daemon[1726]: Plugin "Linux UINPUT Keyboard Output" boot successful. Nov 5 09:05:23 Skuld g15daemon[1726]: Booting plugin "LCDServer" root@Skuld:/home/david# dmesg | grep G15 [3.141971] usb 3-2: Product: G15 Keyboard Hub [3.859959] usb 3-2.1: Product: G15 Gaming Keyboard [3.871812] input: G15 Gaming Keyboard as /devices/pci:00/:00:02.0/usb3/3-2/3-2.1/3-2.1:1.0/0003:046D:C226.0008/input/input17 [3.944498] hid-generic 0003:046D:C226.0008: input,hidraw7: USB HID v1.10 Keyboard [G15 Gaming Keyboard] on usb-:00:02.0-2.1/input0 [3.959826] input: G15 Gaming Keyboard as /devices/pci:00/:00:02.0/usb3/3-2/3-2.1/3-2.1:1.1/0003:046D:C226.0009/input/input18 [4.015946] hid-generic 0003:046D:C226.0009: input,hiddev0,hidraw8: USB HID v1.10 Device [G15 Gaming Keyboard] on usb-:00:02.0-2.1/input1 [4.214942] usb 3-2.4: Product: G15 GamePanel LCD [4.242145] input: G15 GamePanel LCD as /devices/pci:00/:00:02.0/usb3/3-2/3-2.4/3-2.4:1.0/0003:046D:C227.000A/input/input26 [4.296217] hid-generic 0003:046D:C227.000A: input,hiddev0,hidraw9: USB HID v1.11 Keypad [G15 GamePanel LCD] on usb-:00:02.0-2.4/input0 [5.236808] input: G15 Extra Keys as /devices/virtual/input/input27 [ 109.722558] input: G15 Extra Keys as /devices/virtual/input/input28
Bug#857789: xboxdrv grabs connected Stream Controller and prevents it from working
Package: xboxdrv Version: 0.8.5-1+b1 Severity: important Had a fully functioning steam controller and all of a sudden one day it stopped functioning as a mouse anymore on the desktop. Took me a long time to track it down to this package, where after I removed it and rebooted it, the Steam controller started functioning as it is supposed to. I installed this package for use with my Wireless Logitech controllers and didn't realize that it would grab onto my Steam Controllers. I couldn't find any way to prevent this from happening. -- System Information: Debian Release: 8.7 APT prefers stable APT policy: (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.6.0-0.bpo.1-amd64 (SMP w/6 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages xboxdrv depends on: ii libc6 2.19-18+deb8u7 ii libdbus-1-3 1.8.22-0+deb8u1 ii libdbus-glib-1-2 0.102-1 ii libgcc1 1:4.9.2-10 ii libglib2.0-0 2.42.1-1+b1 ii libstdc++64.9.2-10 ii libudev1 215-17+deb8u6 ii libusb-1.0-0 2:1.0.19-1 ii libx11-6 2:1.6.2-3 Versions of packages xboxdrv recommends: ii python 2.7.9-1 ii python-dbus 1.2.0-2+b3 xboxdrv suggests no packages. -- no debconf information
Bug#864008: pcsx2: Audio is crackling badly with ALSA and Pulseaudio
Package: pcsx2 Version: 1.4.0+dfsg-2 Severity: important -- System Information: Debian Release: 9.0 APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.9.0-3-amd64 (SMP w/6 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages pcsx2 depends on: ii libaio1 0.3.110-3 ii libasound21.1.3-5 ii libc6 2.24-10 ii libgcc1 1:6.3.0-18 ii libgdk-pixbuf2.0-02.36.5-2 ii libgl1-mesa-glx [libgl1] 13.0.6-1+b2 ii libglib2.0-0 2.50.3-2 ii libgtk2.0-0 2.24.31-2 ii liblzma5 5.2.2-1.2+b1 ii libpng16-16 1.6.28-1 ii libportaudio2 19.6.0-1 ii libsdl2-2.0-0 2.0.5+dfsg1-2 ii libsoundtouch11.9.2-2+b1 ii libstdc++66.3.0-18 ii libwxbase3.0-0v5 3.0.2+dfsg-4 ii libwxgtk3.0-0v5 3.0.2+dfsg-4 ii libx11-6 2:1.6.4-3 ii zlib1g1:1.2.8.dfsg-5 Versions of packages pcsx2 recommends: ii libasound2-plugins 1.1.1-1 ii libc6 [libc6-i686] 2.24-10 pcsx2 suggests no packages. -- no debconf information It appears this is a known issue since 2016 where there was an SDL patch that broke the audio in pcsx2. https://bugzilla.libsdl.org/show_bug.cgi?id=3228 As per the above, the SDL team did not fix the bug because the fix would have required a change in the API functionality. As such, the PCSX2 team addressed the issue themselves and pushed a fix out to the development branch https://github.com/PCSX2/pcsx2/issues/1095 Note the comment here saying it's fixed in PCSX2 Git https://github.com/PCSX2/pcsx2/issues/1402 I compiled PCSX2 1.5.0-dev and it fixed the issue without any changes to SDL. Just adding this in because PCSX2 was very much unusable with crackling/popping audio when using ALSA+Pulseaudio (recommended) settings.
Bug#792223: mesa-utils: looking for a way to have glxinfo (end friends) installed for both amd64 and i386 at the same time
I agree. I am constantly flipping back and forth between mesa-utils and mesa-utils:i386. I run a combination of games that are i386 and AMD64. Sometimes when I upgrade for one reason or another, I lose GL acceleration on either i386 or AMD64 due to a package conflict or some random package problem in testing, or for some reason aptitude or apt-get choosing a strange upgrade path that leaves me without hardware acceleration on one or the other. I need both a 64 bit and a 32 bit Mesa-utils so I can verify hardware acceleration on both GL libraries. Currently, mesa-utils conflicts with itself on a different architecture which doesn't make much sense to me.
Bug#875498: upgrade-reports: systemd : Breaks: rdnssd (< 1.0.1-5) but 1.0.1-1+deb8u1 is to be installed
root@Belldandy:/home/david# apt-cache rdepends rdnssd rdnssd Reverse Depends: ifupdown systemd:i386 rdnssd:i386 systemd ifupdown
