For some time now, I've found rawhide liferea (x86-64) to be broken almost to the point of uselessness. It runs for something between ten minutes and a few hours before going into a loop where it no longer responds to any sort of input events. Instead, it occupies itself with the vital task of printing
(gecko:13277): GThread-CRITICAL **: g_cond_timed_wait_posix_impl: assertion `end_time.tv_nsec < G_NSEC_PER_SEC' failed
over and over again until put out of its misery.
I filed this bug a month or two ago (https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=231073) but not much seems to be happening there. Releasing F7 with a broken liferea seems like a bad idea...but maybe it's only broken for me? Anybody else seeing this or have any ideas?
Thanks,
jon
On 4/30/07, Jonathan Corbet lwn-ft@lwn.net wrote:
I filed this bug a month or two ago (https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=231073) but not much seems to be happening there. Releasing F7 with a broken liferea seems like a bad idea...but maybe it's only broken for me? Anybody else seeing this or have any ideas?
It's pretty much unusable on x86_64 on FC6 as well.
icon@rakta:[~]$ dmesg | grep liferea | grep segfault | wc -l 12
I was hoping it would be more stable in FC7, but it looks like I might have to look for an alternative RSS reader that actually lets me read stuff.
Regards,
On Mon, 30 Apr 2007 19:33:05 -0400, Konstantin Ryabitsev wrote:
On 4/30/07, Jonathan Corbet wrote:
I filed this bug a month or two ago (https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=231073) but not much seems to be happening there. Releasing F7 with a broken liferea seems like a bad idea...but maybe it's only broken for me? Anybody else seeing this or have any ideas?
It's pretty much unusable on x86_64 on FC6 as well.
icon@rakta:[~]$ dmesg | grep liferea | grep segfault | wc -l 12
Can you get a stacktrace with the liferea-debuginfo package installed and submit it as a bug report?
On 5/1/07, Michael Schwendt mschwendt.tmp0701.nospam@arcor.de wrote:
It's pretty much unusable on x86_64 on FC6 as well.
icon@rakta:[~]$ dmesg | grep liferea | grep segfault | wc -l 12
Can you get a stacktrace with the liferea-debuginfo package installed and submit it as a bug report?
The reason I haven't done that is because FC6 has an older version of liferea (1.0.26), while upstream lists 1.2.x as the stable branch. I was fairly certain their answer would be "please upgrade to the latest stable."
On Tue, 1 May 2007 09:37:23 -0400, Konstantin Ryabitsev wrote:
It's pretty much unusable on x86_64 on FC6 as well.
icon@rakta:[~]$ dmesg | grep liferea | grep segfault | wc -l 12
Can you get a stacktrace with the liferea-debuginfo package installed and submit it as a bug report?
The reason I haven't done that is because FC6 has an older version of liferea (1.0.26), while upstream lists 1.2.x as the stable branch. I was fairly certain their answer would be "please upgrade to the latest stable."
bugzilla.redhat.com because the Fedora package doesn't work for you.
On Mon, 30 Apr 2007 17:13:19 -0600, Jonathan Corbet wrote:
For some time now, I've found rawhide liferea (x86-64) to be broken almost to the point of uselessness. It runs for something between ten minutes and a few hours before going into a loop where it no longer responds to any sort of input events. Instead, it occupies itself with the vital task of printing
(gecko:13277): GThread-CRITICAL **: g_cond_timed_wait_posix_impl: assertion `end_time.tv_nsec < G_NSEC_PER_SEC' failed
over and over again until put out of its misery.
Is this reproducible with GtkHTML2 as the internal browser?
Michael Schwendt mschwendt.tmp0701.nospam@arcor.de wrote:
Is this reproducible with GtkHTML2 as the internal browser?
Is that the "open links in Liferea's window" option? If so, I'm trying it now, we'll see.
Thanks,
jon
Jonathan Corbet / LWN.net / corbet@lwn.net
On Tue, 01 May 2007 06:55:13 -0600, Jonathan Corbet wrote:
Is this reproducible with GtkHTML2 as the internal browser?
Is that the "open links in Liferea's window" option? If so, I'm trying it now, we'll see.
It's menu "Program > Preferences > Browser"
View Headlines With GtkHTML2 <--
instead of "Mozilla".
Michael Schwendt mschwendt.tmp0701.nospam@arcor.de wrote:
Is this reproducible with GtkHTML2 as the internal browser?
Is that the "open links in Liferea's window" option? If so, I'm trying it now, we'll see.
It's menu "Program > Preferences > Browser"
View Headlines With GtkHTML2 <--
In my liferea, "Mozilla" is the only option on that pulldown. My system has both gtkhtml2 and gtkhtml3 packages installed...might I be missing something else?
Thanks,
jon
On Tue, 01 May 2007 08:03:28 -0600, Jonathan Corbet wrote:
Is this reproducible with GtkHTML2 as the internal browser?
Is that the "open links in Liferea's window" option? If so, I'm trying it now, we'll see.
It's menu "Program > Preferences > Browser"
View Headlines With GtkHTML2 <--
In my liferea, "Mozilla" is the only option on that pulldown. My system has both gtkhtml2 and gtkhtml3 packages installed...might I be missing something else?
That's another bug which needs to be examined. Just as in the i386 package, the x86_64 package ought to have both plugins:
/usr/lib64/liferea/liblihtmlg.so <-- missing! /usr/lib64/liferea/liblihtmlm.so
The one with 'g' is GtkHTML, the one with 'm' Mozilla.
On Tue, 2007-05-01 at 08:03 -0600, Jonathan Corbet wrote:
Michael Schwendt mschwendt.tmp0701.nospam@arcor.de wrote:
Is this reproducible with GtkHTML2 as the internal browser?
Is that the "open links in Liferea's window" option? If so, I'm trying it now, we'll see.
It's menu "Program > Preferences > Browser"
View Headlines With GtkHTML2 <--
In my liferea, "Mozilla" is the only option on that pulldown. My system has both gtkhtml2 and gtkhtml3 packages installed...might I be missing something else?
Upstream Liferea has disabled the gtkhtml plugin for x86_64 builds.
/B
On Tue, 2007-05-01 at 18:29 +0200, Michael Schwendt wrote:
On Tue, 01 May 2007 12:06:05 -0400, Brian Pepple wrote:
Upstream Liferea has disabled the gtkhtml plugin for x86_64 builds.
:) That would have killed the old plan to split off the mozilla plugin into a sub-package.
Yeah, upstream barely supports x86_64, so I'm actively looking for x86_64 maintainers that want to co-maintain this package since I don't have a x86_64 machine. If anyone is interested please contact me.
/B
On Tue, 01 May 2007 12:45:11 -0400 bpepple@fedoraproject.org (Brian Pepple) wrote:
On Tue, 2007-05-01 at 18:29 +0200, Michael Schwendt wrote:
On Tue, 01 May 2007 12:06:05 -0400, Brian Pepple wrote:
Upstream Liferea has disabled the gtkhtml plugin for x86_64 builds.
:) That would have killed the old plan to split off the mozilla plugin into a sub-package.
Yeah, upstream barely supports x86_64, so I'm actively looking for x86_64 maintainers that want to co-maintain this package since I don't have a x86_64 machine. If anyone is interested please contact me.
Well, I use liferea on x86_64 and have also been seeing the crashes.
Looking at the upstream list I see this thread:
http://sourceforge.net/mailarchive/forum.php?thread_name=1177945223.29795.89...
Which basically says that upstream can't reproduce it, so they have no idea on how to fix it. ;(
There is a bug in the sf tracker about it:
http://sourceforge.net/tracker/index.php?func=detail&aid=1675822&gro...
I have built the latest one here, and am going to try and grab a stack trace.
kevin
I was able to get a pretty useless looking trace when it was off into tight loop land here:
(gdb) where #0 0x0000003ab82c71c6 in poll () from /lib64/libc.so.6 #1 0x0000003abca2fe7e in g_free () from /lib64/libglib-2.0.so.0 #2 0x0000003abca3033a in g_main_loop_run () from /lib64/libglib-2.0.so.0 #3 0x0000003ac2b2d0d3 in gtk_main () from /usr/lib64/libgtk-x11-2.0.so.0 #4 0x000000000043ce08 in main (argc=2, argv=0x7fff63f38308) at main.c:286
Dunno if that helps at all. I was going to add it to the sourceforge bug I listed above, but sourceforge isn't allowing me to login right now for some reason. ;(
kevin
On Tue, 2007-05-01 at 12:45 -0400, Brian Pepple wrote:
Yeah, upstream barely supports x86_64, so I'm actively looking for x86_64 maintainers that want to co-maintain this package since I don't have a x86_64 machine. If anyone is interested please contact me.
I really like Blam, but (as I discovered soon after picking up its maintainership) since it uses pre-built Atom.Net and RSS.Net libraries (whose upstreams are themselves quite inactive, it seems) and doesn't play well with multilib (as well as being a generally misbehaving application), I've recently been giving up on it a lot and using Liferea instead (Rawhide/x86_64 on an Intel Core2 Duo). If you need some testing/debugging help, just tell me what to do :) - though I won't be able to do anything *too* invasive or time-consuming until this semester of class lets out at the end of the month due to procrastination of projects and whatnot. T_T
[As an aside - though I'm happy to continuing maintaining it, does anyone actively use/test Blam stuff that would like to comaintain it with me or take it over fully? Alas, version 1.8.4 has a nasty crasher bug that neither myself or upstream has been able to track down and appropriately squish, so that's why the Fedora package is still at 1.8.3 (plus some backported fixes from 1.8.4).]
Thanks.