Bug#623619: liferea: constant wasteful disk accesses kill system performance
On Sun, Mar 25, 2012 at 2:27 PM, Moray Allan mo...@sermisy.org wrote: While it's not a good solution, it seems relevant here that following Ben's suggestion in http://womble.decadent.org.uk/blog/feed-reading.html of running liferea with eatmydata indeed makes a huge difference for me, both increasing liferea's own responsiveness but more importantly reducing the drag on the rest of the system. From the upstream perspective fsync() disabling is not an option as it will lead to certain long term data loss. Note that the WAL journaling was added to 1.8.3 and seems to help with the performance issues on ext4. See also: http://liferea.blogspot.de/2012/03/for-everyone-wondering-about-bad.html http://liferea.blogspot.de/2012/03/morpheus-suggested-in-comment-to-check.html Regards, Lars -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#665391: smbclient: smbtree -h does not work as documented in manpage
Package: smbclient Version: 2:3.6.3-1 Severity: minor Steps to reproduce: 1.) Call smbtree --help 2.) Call smbtree -h 3.) Call smbtree -? Only 1.) and 3.) work. The manpage claims 1.) and 2.) should work: $ man smbtree |grep -A2 help -h|--help Print a summary of command line options. $ I suggest to fix the manpage. With Best Regards, Lars Lindner -- System Information: Debian Release: wheezy/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 2.6.32-5-amd64 (SMP w/4 CPU cores) Locale: LANG=de_DE.utf8, LC_CTYPE=de_DE.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages smbclient depends on: ii libc6 2.13-27 ii libcap2 1:2.22-1 ii libcomerr21.42.1-2 ii libgssapi-krb5-2 1.10+dfsg~beta1-2 ii libk5crypto3 1.10+dfsg~beta1-2 ii libkrb5-3 1.10+dfsg~beta1-2 ii libldap-2.4-2 2.4.28-1.1 ii libpopt0 1.16-3 ii libreadline6 6.2-8 ii libtalloc22.0.7+git20120207-1 ii libtdb1 1.2.9-4+b1 ii libtinfo5 5.9-4 ii libwbclient0 2:3.6.3-1 ii samba-common 2:3.6.3-1 ii zlib1g1:1.2.6.dfsg-2 smbclient recommends no packages. Versions of packages smbclient suggests: pn cifs-utils none -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#608241: fails to connect to hosts with an IPv6 address
As many other projects out there the Liferea developers decided to outsource networking complexity. The concept is called a library :-) Meddling with getaddrinfo() and similar stuff without having a degree in IPv4/v6 migration is just not an option... Cheers, Lars On Wed, Dec 29, 2010 at 4:57 AM, Marco d'Itri m...@linux.it wrote: Package: liferea Version: 1.6.4-1 Severity: important liferea tries to connect(2) to an IPv6 address, correctly gets back ENETUNREACH since here I do not have v6 connectivity nor v6 addresses configured on my interfaces and the reports a failure to the user without falling back on the IPv4 address. It works again if I close and reopen the program, which makes me think that it incorrectly checks in some way for IPv6 connectivity at startup. The program needs to be fixed to properly call getaddrinfo(3) in a loop (and then use the AI_ADDRCONFIG flag), if you need an example you can find a simple one in my whois package. For testing (and understanding why this needs to be fixed urgently), you can add http://ipv4depletion.com/?feed=rss2 to your feeds. -- System Information: Debian Release: squeeze/sid APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: i386 (x86_64) Kernel: Linux 2.6.32-5-amd64 (SMP w/2 CPU cores) Locale: lang=it...@euro, lc_ctype=it...@euro (charmap=ISO-8859-15) Shell: /bin/sh linked to /bin/dash Versions of packages liferea depends on: ii gconf2 2.28.1-6 GNOME configuration database syste ii libatk1.0-0 1.30.0-1 The ATK accessibility toolkit ii libc6 2.11.2-7 Embedded GNU C Library: Shared lib ii libcairo2 1.10.0-1 The Cairo 2D vector graphics libra ii libdbus-1-3 1.2.24-3 simple interprocess messaging syst ii libdbus-glib-1-2 0.88-2 simple interprocess messaging syst ii libgconf2-4 2.28.1-6 GNOME configuration database syste ii libglade2-0 1:2.6.4-1 library to load .glade files at ru ii libglib2.0-0 2.24.2-1 The GLib library of C routines ii libgtk2.0-0 2.20.1-2 The GTK+ graphical user interface ii libice6 2:1.0.7-1 X11 Inter-Client Exchange library ii liblua5.1-0 5.1.4-5 Simple, extensible, embeddable pro ii libnm-glib2 0.8.1-2+b1 network management framework (GLib ii libnotify1 [libnotify1-gtk2 0.5.0-2 sends desktop notifications to a n ii libpango1.0-0 1.28.3-1 Layout and rendering of internatio ii libsm6 2:1.2.0-1 X11 Session Management library ii libsoup2.4-1 2.30.2-1 an HTTP library implementation in ii libsqlite3-0 3.7.4-1 SQLite 3 shared library ii libwebkit-1.0-2 1.2.5-2.1 Web content engine library for Gtk ii libx11-6 2:1.3.3-4 X11 client-side library ii libxml2 2.7.8.dfsg-1 GNOME XML library ii libxslt1.1 1.1.26-6 XSLT 1.0 processing library - runt ii liferea-data 1.6.4-1 architecture independent data for Versions of packages liferea recommends: ii curl 7.21.2-3 Get a file from an HTTP, HTTPS or ii dbus 1.2.24-3 simple interprocess messaging syst ii dbus-x11 1.2.24-3 simple interprocess messaging syst ii wget 1.12-2.1 retrieves files from the web Versions of packages liferea suggests: pn network-manager none (no description available) -- no debconf information -- ciao, Marco -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) iEYEARECAAYFAk0ascUACgkQFGfw2OHuP7HZYACfQd/FMjbHnEx+5sWugJJoPxSw NO8AmwUFqXqwptwZh++vHInVxmv5JDM9 =fBSF -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#587555: liferea: controlling the number of feed items is confusing
On Thu, Jul 1, 2010 at 9:10 PM, Adrian Bunk b...@stusta.de wrote: On Thu, Jul 01, 2010 at 02:45:48PM -0400, Celejar wrote: On Thu, 1 Jul 2010 10:58:40 +0300 Adrian Bunk b...@stusta.de wrote: On Tue, Jun 29, 2010 at 03:20:10PM -0400, Celejar wrote: Package: liferea Version: 1.6.3-1 Severity: normal Under the main Preferences / Feeds is a setting labeled Feed cache handling - Default number of items per feed to save, and under an individual feed's Subscription properties / Archive is a setting labeled Number of items to save. Both these preferences and their accompanying descriptions and context seem to indicate that they just affect the caching behavior, but on my installation they actually seem to be the (only) way to control how many of a feed's items are actually displayed at all. I think that what these options actually do should be clarified. Liferea displays all items it has from this feed, and these are basically the cached items. What do you expect caching to do other than caching the items for displaying them? From Subscription Properties / Archives: The cache setting controls if the contents of feeds are saved when Liferea exits. Marked items are always saved to the cache. This implies that the cache settings are relevant to the saving of contents when Liferea exits, and not to the much more fundamental question of how many and which items are displayed initially. when Liferea exits might actually be wrong, and should perhaps be dropped. Obviously, if I mark an item, it's already displayed, which you are telling me means that it's already in the cache. What does the last line mean, then? Let me make an example: - cache limit 30 items for a feed - 30 items are already cached - the oldest cached item is marked - a feed update brings 20 new items Usually, the oldest 20 cached items would now be dropped from the cache. But since the oldest item is marked, this item will not be dropped. This is a correct description, but this is IMO no a sane use case. Why do you set such a small number of cached items? The only thing we could do to prevent such a misconfiguration is to warn each time you set such small values. But at least I do not want to start with confirmation hell... Best Regards, Lars -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#587555: liferea: controlling the number of feed items is confusing
On Thu, Jul 1, 2010 at 9:24 PM, Adrian Bunk b...@stusta.de wrote: On Thu, Jul 01, 2010 at 09:16:38PM +0200, Lars Lindner wrote: On Thu, Jul 1, 2010 at 9:10 PM, Adrian Bunk b...@stusta.de wrote: On Thu, Jul 01, 2010 at 02:45:48PM -0400, Celejar wrote: ... Obviously, if I mark an item, it's already displayed, which you are telling me means that it's already in the cache. What does the last line mean, then? Let me make an example: - cache limit 30 items for a feed - 30 items are already cached - the oldest cached item is marked - a feed update brings 20 new items Usually, the oldest 20 cached items would now be dropped from the cache. But since the oldest item is marked, this item will not be dropped. This is a correct description, but this is IMO no a sane use case. Why do you set such a small number of cached items? ... I even have valid use cases for low numbers in some of my feeds, but that's unrelated to what I wanted to explain. Replace the two occurences of 30 items with 1000 items and the number is no longer small, but the situation I wanted to show here stays the same. Even with a large itemset: how should we help the user? We do offer two distinct features: item caching (for offline reading, later reading, whatever...) and item flagging (which implies keeping items). Both features can be used together and shouldn't prevent each other. You say that you do not like the resulting effect (of flagged items keeping new items from appearing), which I understand. But could please please provide an expected behaviour? Regards, Lars -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#560201: liferea: (doesn't|no longer) remembers the font size across sessions
On Wed, Dec 9, 2009 at 5:34 PM, Willi Mann wi...@wm1.at wrote: Package: liferea Version: 1.6.0-1 Severity: normal I'm quite sure that previous versions of liferea did preserve the font size across sessions. At least the font size was appropriate for my screen with 128 dpi, probably because I set it. Please preserve the font size (again)? over sessions. Reproduced and fixed upstream in SVN. Fix will be included in 1.6.2. Thanks for reporting this regression! Best Regards, Lars -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#537478: liferea: about:config doesn't work anymore
On Sat, Jul 18, 2009 at 8:18 PM, Axel Beckerta...@sym.noone.org wrote: Package: liferea Version: 1.6.0~rc6-1 Severity: minor With 1.4 (and IIRC also 1.5, not sure though) it was possible to open some link in a Liferea tab, and then open about:config in that tab to e.g. edit the cookie handling of Liferea. With 1.6. entering about:config in a tab's location bar gets changed to http://about:config/; which is some kind of bogus. So there's no more possibility to edit the Gecko/XULRunner config for Liferea manually. Besides fixing that it would be even better to also have a button Detailed configuration like in Firefox or Thunderbird (if necessary even with the will void your warranty babble) somewhere in the preferences dialog or tools menu which then opens about:config in a tab (or even in the omnipresent headlines tab). 1.6 doesn't use Gecko for rendering anymore, it uses Webkit. Therefore there is no config:about that can be called anymore. Lars -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#537196: liferea: No longer possible to drag'n'drop entry titles
On Thu, Jul 16, 2009 at 12:26 AM, Andreas Bombea...@debian.org wrote: Package: liferea Version: 1.6.0~rc6-1 Severity: normal It used to be possible to drag the title of an open entry e.g. into an open browser window to conveniently have it load there. After the upgrade to 1.6.0~rc the dragging itself doesn't work anymore. Entry titles only have the right click menu and the left click that opens a new browser window still working. Starting with 1.6 Liferea replaced the HTML rendering widget. Previously we supported all types of Mozilla flavours, now it is Webkit-only. The DnD support was realized by the Mozilla widget and isn't by the current libwebkit widget. It might be worth asking the Webkit guys to implement the DnD source. From an upstream perspective: Won't fix. Best Regards, Lars -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#512108: Current item marked as read if new feed is added
On Sat, Jan 17, 2009 at 12:26 PM, Enrico Zini enr...@debian.org wrote: Package: liferea Version: 1.4.18-1+b1 Severity: normal Hello, thanks for maintaining liferea. Here's the annoyance scenario: 1. I'm reading a blog post, which at the beginning says This very interesting person just started blogging at URL 2. Excited, I open URL in a browser, have a look, and decide to add it to my feed 3. I click on new subscription, do the thing 4. Now I see the new feed, and the original blog post that I was reading is not in the Unread folder anymore. I want to finish reading it: in which of my 30 feeds was it? Oh my :( Please use a 3rd mouse button click in step 2.) or select Open in New Tab from the link context menu. Regards, Lars -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#509249: liferea: please provide a config item to disable browser-plugins
On Sat, Dec 20, 2008 at 11:58 AM, Helmut Grohne hel...@subdivi.de wrote: Package: liferea Version: 1.4.18-1+b1 Severity: wishlist I've got mozilla-plugin-gnash 0.8.4-2 and lifera uses the plugin in a way that makes it litter zombies (see #424171). I'd like to see a method to disable the plugin for lifera until the bug above is fixed. Currently I have 210 gtk-gnash zombies that are children of liferea. I spent some time looking for a method to disable plugins in Gecko, but gave up on it. It is not really possible. From the embedders perspective (with the exception of Java) you cannot even detect which plugins do exist or are active. Therefore: not possible. Lars -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#494741: liferea: crashes on exit after closing update monitor dialog with Esc
On Mon, Aug 11, 2008 at 9:36 PM, ygrek [EMAIL PROTECTED] wrote: Package: liferea Version: 1.4.16b-0.1 Severity: important StR: Start liferea, open Tools -- Update monitor. Dialog popups. Close it with Esc. Select Subscriptions -- Quit. Liferea crashes and gnome bug reporting tool starts. If started from console liferea prints (the same on normal exit without crash) : === libnm_glib_nm_state_cb: dbus returned an error. (org.freedesktop.DBus.Error.ServiceUnknown) The name org.freedesktop.NetworkManager was not provided by any .service files (liferea:14455): Gtk-CRITICAL **: gtk_style_detach: assertion `style-attach_count 0' failed === Also, if the update monitor dialog is closed with Esc, it doesn't appear again (when clicking in menu) unless liferea is restarted. WM is xmonad. Several stack traces attached (first two without symbols, just for completeness). I could reproduce the update monitor not being able to reopen when closed with ESC. There was a missing destroy callback. I fixed this in SVN upstream (will be included in 1.4.23). I could not reproduce the crash on exit, but I think it is also fixed now. Please retest! Best Regards, Lars -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#487927: liferea: uses 100% CPU, but stays usable, crashes at shutdown
On Wed, Jul 9, 2008 at 12:58 PM, Sven Hartge [EMAIL PROTECTED] wrote: Um 09:09 Uhr am 09.07.08 schrieb Lars Lindner: Thanks for the retest. This time it did help, the crash is now a line below in feedlist_free(). Now we could solve this second issue by another check, but I would like to ask you one thing first: can you please determine how many times feedlist_free() is really called? I'd suggest to set a breakpoint using gdb or to add a g_print(something) at the start of feedlist_free(). I think the method is called twice in your case and this is not correct. You are right. Output of my test (annotations by me): , | [EMAIL PROTECTED]:~$ liferea | libnm_glib_nm_state_cb: dbus returned an error. | (org.freedesktop.DBus.Error.ServiceUnknown) The name org.freedesktop.NetworkManager was not provided by any .service files start of: feedlist_free ^^^ - 1 | (liferea:14969): GLib-CRITICAL **: g_source_remove: assertion `tag 0' failed | | (liferea:14969): GLib-CRITICAL **: g_hash_table_lookup: assertion `hash_table != NULL' failed | | ** (liferea:14969): WARNING **: mozsupport_get_zoom(): Could not retrieve browser... | | (liferea:14969): Gtk-CRITICAL **: gtk_tree_view_get_selection: assertion `GTK_IS_TREE_VIEW (tree_view)' failed | | (liferea:14969): Gtk-CRITICAL **: gtk_tree_selection_unselect_all: assertion `GTK_IS_TREE_SELECTION (selection)' failed | | ** (liferea:14969): CRITICAL **: feedlist_schedule_save_cb: assertion `NULL != rootNode' failed start of: feedlist_free ^^^ - 2 | (liferea:14969): GLib-CRITICAL **: g_source_remove: assertion `tag 0' failed | ** | ** ERROR:(node.c:515):node_foreach_child_full: assertion failed: (NULL != node) | Aborted ` Thanks for this debugging info. I think we'll need the extra check to avoid the double free caused by calling feedlist_free() twice. This is the least invasive solution. Can you please retest using the attached patch? With Best Regards, Lars Lindner feedlist.c.patch Description: Binary data
Bug#501894: liferea: segfaults when closing a tab with embedded flash content
On Sat, Oct 11, 2008 at 6:00 PM, Rodrigo Gallardo [EMAIL PROTECTED] wrote: On Sat, Oct 11, 2008 at 12:37:34PM +0200, Hans-Juergen Becker wrote: liferea crashes when closing a tab with embedded flash content. To reproduce: a) configure liferea to open links in new tab b) open *exactly one* link with embedded flash in new tab c) close that tab If you open the link two or more times, bug won't show. Does this happen if the flash content was embedded in a feed entry and you open the entry in a tab, or would that count as opening two times? I can't seem to reproduce this, but I'm on amd64 and viewing flash with the nspluginwrapper so I'm pretty certain the environment is too different. I wasn't sure about the severity of this, as it causes data-loss of two different kinds: * Your metadata (read/flagged/deleted) get lost All your metadata, or what you had flagged in the session? If it's all of it this is definitely RC. * The latest headers have to be downloaded again Well, this is a bother but hardly data-loss. Normally i would say it's critical but didn't want to open more release-critical bugs without prior discussion, so this goes as important. Are you losing more than one or two minutes of metadata? If so, I'd say this is RC. Some additional info: Flash causes so many problems that I'll add a new preference option disabling Flash per default in one of the next releases upstream. Flash both tends to crash and freeze Liferea. Concerning data loss: there is a DB closing every 500 DB write actions to prevent loosing long term changes. But a crash will never go without data loss. Best Regards, Lars -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#501656: regression: Toggle Read Status lost from context menu
On Thu, Oct 9, 2008 at 12:15 PM, Helmut Grohne [EMAIL PROTECTED] wrote: Package: liferea Version: 1.4.18-1 Severity: normal The item Toggle Read Status in the context menu seems to be gone in recent releases. It is however still available from the Item menu. Fixed upstream in 1.4.20 Best Regards, Lars -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#487927: closed by Luis Rodrigo Gallardo Cruz [EMAIL PROTECTED] (Bug#487927: fixed in liferea 1.4.18-1)
On Tue, Aug 26, 2008 at 3:26 PM, Rodrigo Gallardo [EMAIL PROTECTED] wrote: On Tue, Aug 26, 2008 at 09:47:33AM +0200, Sven Hartge wrote: Debian Bug Tracking System wrote: #487927: liferea: uses 100% CPU, but stays usable It has been closed by Luis Rodrigo Gallardo Cruz [EMAIL PROTECTED]. I beg to differ. 1.4.18 fixes the 100%-CPU bug which has been introduced by the faulty database handling in 1.4.16b, but I am still seeing a different 100% CPU bug (i.e. this bug report here), which is related to xulrunner-1.9. If you don't mind, I will reopen this bug. Go ahead. Not having seen the bug myself, I got the conversations on the devel list confused and tought 1.4.18 solved both issues. It is like Sven Hartge explained. There is a separate issue triggered by XulRunner 1.9 (doesn't happen with 1.8) which causes 100% CPU effects. So technically this bug isn't fixed. Best Regards, Lars -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#489001: liferea: opens two tabs for links when using iceweasel as external browser in new tab mode
On Sat, Jul 12, 2008 at 4:22 PM, Heikki Hokkanen [EMAIL PROTECTED] wrote: On Mon, Jul 7, 2008 at 9:52 PM, Lars Lindner [EMAIL PROTECTED] wrote: This can be caused by the browser command returning an exit code != 0 despite launching the URL. In such a case Liferea tries to rerun the browser command again asynchronously. I think Liferea behaves correctly as the only way to know if the executed command did work is the exit code and relying on it is the only way. You are right, this was a problem with iceweasel. I upgraded xulrunner and the segfaults are gone: 2008-07-12 17:01:30 upgrade xulrunner-1.9 1.9~rc2-4 1.9~rc2-5 Both new-tab and default mode work properly now. I still don't know why I got Error: Failed to send command: 500 command not parseable when running the browser-remote command manually, but my guess would be that Liferea does some kind of escaping after printing the debug command. I'll leave closing the bug as invalid to you as you probably know how to do it properly :-) I'm not the package maintainer. I'm only expressing upstream opinions :-) Best Regards, Lars -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#487927: liferea: uses 100% CPU, but stays usable, crashes at shutdown
On Wed, Jul 9, 2008 at 12:50 AM, Sven Hartge [EMAIL PROTECTED] wrote: Lars Lindner wrote: Thanks for your quick retest! Now I'm not exactly sure what happens in your case and why during shutdown the feed list seems already to be deallocated. There must be some shutdown order problem. For now I think I'll solve the problem by using the attached patch. If you have time please retest! Sorry, crashed again, see attached backtrace. Thanks for the retest. This time it did help, the crash is now a line below in feedlist_free(). Now we could solve this second issue by another check, but I would like to ask you one thing first: can you please determine how many times feedlist_free() is really called? I'd suggest to set a breakpoint using gdb or to add a g_print(something) at the start of feedlist_free(). I think the method is called twice in your case and this is not correct. If you want to try my locally created debian package, please contact me for a download URL. Thanks, but I think this is not necessary. Best Regards, Lars -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#489001: liferea: opens two tabs for links when using iceweasel as external browser in new tab mode
On Tue, Jul 8, 2008 at 5:23 PM, Heikki Hokkanen [EMAIL PROTECTED] wrote: On Mon, Jul 7, 2008 at 9:52 PM, Lars Lindner [EMAIL PROTECTED] wrote: This can be caused by the browser command returning an exit code != 0 despite launching the URL. In such a case Liferea tries to rerun the browser command again asynchronously. I think Liferea behaves correctly as the only way to know if the executed command did work is the exit code and relying on it is the only way. If you want to see what happens run with --debug-gui and there will be traces of the command launch. To further analyze this try to run the failed command manually and check the exit code. You are right, with --debug-gui and new tab mode Liferea outputs the following: GUI: launch URL: false true 0 GUI: Running the browser-remote sync command 'firefox -a firefox -remote openURL(http://rss.slashdot.org/~r/Slashdot/slashdot/~3/329092553/article.pl,new-tab)' GUI: Running the browser-remote async command 'firefox http://rss.slashdot.org/~r/Slashdot/slashdot/~3/329092553/article.pl' When the commands are run manually: $ firefox -a firefox -remote 'openURL(http://rss.slashdot.org/~r/Slashdot/slashdot/~3/329092553/article.pl,new-tab)' Error: Failed to send command: 500 command not parseable Segmentation fault $ firefox http://rss.slashdot.org/~r/Slashdot/slashdot/~3/329092553/article.pl Segmentation fault Obviously there is something wrong with Firefox. However, the first command does not open a tab when I run it manually, maybe I'm missing something? Hmm... But it should because the second parameter of openURL() is new-tab. According to the openURL documentation this is the correct way to do it. Best Regards, Lars -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#489001: liferea: opens two tabs for links when using iceweasel as external browser in new tab mode
On Wed, Jul 2, 2008 at 6:55 PM, Heikki Hokkanen [EMAIL PROTECTED] wrote: Package: liferea Version: 1.4.16b-0.1 Severity: normal Hello, When external browser is set to Firefox and Open link in to new tab, Liferea seems to open two tabs for every link clicked. This includes the actual item links as well as any links in the body of the items, feed link and so on. When Open link in is set to Browser default only one tab is opened. iceweasel version is 3.0~rc2-2. This can be caused by the browser command returning an exit code != 0 despite launching the URL. In such a case Liferea tries to rerun the browser command again asynchronously. I think Liferea behaves correctly as the only way to know if the executed command did work is the exit code and relying on it is the only way. If you want to see what happens run with --debug-gui and there will be traces of the command launch. To further analyze this try to run the failed command manually and check the exit code. Best Regards, Lars -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#487927: liferea: uses 100% CPU, but stays usable, crashes at shutdown
On Wed, Jul 2, 2008 at 12:30 AM, Sven Hartge [EMAIL PROTECTED] wrote:
Lars Lindner wrote:
I think I have fixed the crash upstream with this on line change:
http://liferea.svn.sourceforge.net/viewvc/liferea?view=revrevision=3970
If you have time to retest please drop me a note if it works.
I tested your fix, but I still get the crash after/while closing liferea
with the attached backtrace from bug-buddy.
Thanks for your quick retest! Now I'm not exactly sure what happens
in your case and why during shutdown the feed list seems already to
be deallocated. There must be some shutdown order problem.
For now I think I'll solve the problem by using the attached patch.
If you have time please retest!
Best Regards,
Lars
Index: src/feedlist.c
===
--- src/feedlist.c (Revision 3970)
+++ src/feedlist.c (Arbeitskopie)
@@ -381,6 +381,8 @@
problems. Use feedlist_schedule_save() instead! */
static gboolean feedlist_schedule_save_cb(gpointer user_data) {
+ g_return_if_fail(NULL != rootNode);
+
/* step 1: request each node to save its state */
feedlist_foreach(node_save);
Bug#488757: liferea crashed randomly
On Tue, Jul 1, 2008 at 5:20 AM, Paul Wise [EMAIL PROTECTED] wrote: Package: liferea Version: 1.4.16b-0.1 Severity: normal I've attached the backtrace from a random crash. Please close this bug if it doesn't point to a specific issue that can be fixed, or reassign to xulrunner 1.9 if it is a problem there. This problem is Liferea specific. This is a random crash during shutdown caused by a race condition of feed list destruction and saving callback. Fixed in SVN: http://liferea.svn.sourceforge.net/viewvc/liferea?view=revrevision=3970 Fix to be released upstream with 1.4.17 Best Regards, Lars -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#487927: liferea: uses 100% CPU, but stays usable, crashes at shutdown
On Thu, Jun 26, 2008 at 12:16 PM, Sven Hartge [EMAIL PROTECTED] wrote: Some additional info: If I try to stop liferea while it is in 100%-mode, it crashes and bug-buddy collects the attached backtrace. Here is some general upstream feedback on this issue: From all the reports I've seen until now this affects every 1.4 version (starting with at least 1.4.12) that is run with recent XulRunner 1.9. I've had not a single report yet about this problem on XulRunner 1.8 or other Gecko providers. Despite this I cannot name an exact XulRunner version with which this effect happens. Best Regards, Lars -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#487927: liferea: uses 100% CPU, but stays usable, crashes at shutdown
On Mon, Jun 30, 2008 at 8:46 PM, Sven Hartge [EMAIL PROTECTED] wrote: Heikki Hokkanen wrote: However, I didn't notice a crash happening when quitting Liferea, so maybe that's a different bug? I am seeing this crash with an identical backtrace every time I try to close liferea while running at 100%. I can even reproduce this on different machines. Is your machine 64bit or 32bit? Heikki Hokkanen is right. The crash and the 100% CPU problem are independant. Though the high CPU might raise the propability of the crash... I think I have fixed the crash upstream with this on line change: http://liferea.svn.sourceforge.net/viewvc/liferea?view=revrevision=3970 If you have time to retest please drop me a note if it works. Fix will be included upstream in 1.4.17 Best Regards, Lars -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#487927: liferea: uses 100% CPU, but stays usable, crashes at shutdown
I have a suspicion about the possible cause. Could you please retry with the shopblogger.de RSS 0.91 feed? If I'm right it shouldn't happen with it... I myself could reproduce the problem with this feed, but I switching between the items very quickly becomes very slow the longer it is done and disk I/O increases. Best Regards, Lars -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#487927: liferea: uses 100% CPU, but stays usable, crashes at shutdown
On Sun, Jun 29, 2008 at 12:35 PM, Sven Hartge [EMAIL PROTECTED] wrote: Lars Lindner wrote: I have a suspicion about the possible cause. Could you please retry with the shopblogger.de RSS 0.91 feed? If I'm right it shouldn't happen with it... I'm sorry, but the RSS0.91 feed does show the same behavior. As an additional note: I can reproduce this on different computers, so this is no problem local to a single machine. That's interesting... So the only thing one can say is that fast switching of XulRunner browser content causes such CPU load. One thing I'd like to ask was: does the 100% CPU go away after some time (maybe 10s) once you stop doing anything in Liferea? Best Regards, Lars -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#487927: liferea: uses 100% CPU, but stays usable, crashes at shutdown
On Sat, Jun 28, 2008 at 8:24 PM, Sven Hartge [EMAIL PROTECTED] wrote: Some new findings: If I use webkit as engine for liferea, I am no longer able to reproduce this bug. So this seems to be some error inside xulrunner. I got several 100% CPU reports upstream and most of them were Flash related. So often when a Flash plugin was active in the rendered content something eats 100% CPU. But as Flash is an internal browser functionality I see nothing that the Liferea source code can do against this. For completeness: there was at least one other report that did experience this without Flash involved. Lars -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#480807: Don't build depend on libxul-dev
On Sun, May 25, 2008 at 10:44 AM, Mike Hommey [EMAIL PROTECTED] wrote: tag 480807 + patch thanks On Mon, May 12, 2008 at 09:07:26AM +0200, Mike Hommey wrote: Package: liferea Severity: wishlist User: [EMAIL PROTECTED] Usertags: xulrunner-transition With the upcoming xulrunner transition, libxul-dev is going to disappear. I already sent instructions on what you should be doing in http://lists.debian.org/debian-release/2008/05/msg9.html This bug report is mostly to help follow the transition going. FYI, I will start NMUing plugins and components next week, and will break the remaining packages by uploading xulrunner 1.9 in unstable on May 25. Though help will be appreciated, I'll also prepare updated packages for these during this week and next. Upstream added support for xulrunner-1.9 in (upcoming?) version 1.4.16. The changeset is here: http://liferea.svn.sourceforge.net/viewvc/liferea?view=revrevision=3849 There is a problem in this patch, though, since xulrunner-embedding doesn't exist. PKG_CHECK_MODULES(XULRUNNER, xulrunner-embedding, XULRUNNER_PROVIDER=xulrunner-embedding, XULRUNNER_PROVIDER=) should be replaced with PKG_CHECK_MODULES(XULRUNNER, libxul-embedding, XULRUNNER_PROVIDER=libxul-embedding, XULRUNNER_PROVIDER=) That's correct. My fault. I corrected this upstream too. Will be delivered with 1.4.16 and 1.5.4. Best Regards, Lars -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#474736: Solution in upcoming 1.5.4
I implemented a solution upstream that covers mixed-case iframe tags and solves this bug. Due to the lower Glib version (2.12) this solution cannot be backported to 2.14... Best Regards, Lars -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#475603: liferea: XML Parsing error in Search interface (in translation?)
On Sat, Apr 12, 2008 at 12:15 AM, Ulrik Sverdrup [EMAIL PROTECTED] wrote: Package: liferea Version: 1.4.14-1 Severity: minor When searching (ctrl-F), an XML Parsing error is displayed in the lower pane. Search results show up as normal in the upper pane. This might be related to my locale only, but the error comes from a true unmatched tag. Error message: --- XML Parsing Error: mismatched tag. Expected: /p. Location: file:/// Line Number 6, Column 294:bodydiv class='content'h20 sökresultat för epiphany/h2pArtikellistan innehåller nu alla artiklar som matchar det angivna sökmönstret. Om du vill spara dessa sökningresultat permanent kan du klicka på knappen Sökmapp i sökfönstret, så skapar Liferea en sökmapp i din kanallista./h2/p/div/body/html I fixed this upstream (to be released with 1.4.15). http://liferea.svn.sourceforge.net/viewvc/liferea?view=revrevision=3812 Best Regards, Lars
Bug#433393: liferea doesn't update any feeds after migration to new format
On Mon, Mar 17, 2008 at 4:33 PM, Luis Rodrigo Gallardo Cruz [EMAIL PROTECTED] wrote: On Mon, Mar 17, 2008 at 02:21:14PM +0200, Eddy Petrișor wrote: Luis Rodrigo Gallardo Cruz wrote: On Thu, Mar 13, 2008 at 02:33:54AM +0200, Eddy Petrișor wrote: On to more promising lands: Could you try running with --debug-update, please? I moved away the ~/.liferea_1.4 directory (safe copy) and ran: liferea --debug-update 21 | tee liferea_update The log is attached. I hate Heisenbugs. Not sure this is one. I see nothing obviously wrong in this log. Even worse, there are entries there about updating the feeds, mentioning relatively recent entries in, for example, Debian Planet. Did it keep failing after this update? Yes, for instance, Debian Planet is still stuck at that post, Sami Haahtinen: Installing Debian on NSLU2 from the 6th of March. Mmm. This makes me think it's reading them but then not commiting them to the database. Maybe something in the cache settings is malfunctioning. I can think of several scenarios you could be in: 1.) No updates saved to disk 2.) No updates executed at all 3.) No updates results processed 4.) No network connection. In case of 1.) you should see DB error messages on the command line. To verify this please run at least once on the command line and check for suspicious output. You might also run once with command line option --debug-db and check for errors. In case of 2.) you can check using the Update Monitor options in the Tools menu. This will open a dialog presenting a list of all subscriptions that are to be updated and all that are downloaded right now. Here you should check wether there are feeds in the queue at all and if those are processed after a while. In case of 3.) you should check the output of a run with command line option --debug-update for HTTP error codes. In case of 4.) please check if the online/offline icon in the lower left corner displays the online icon. Also you should check the icons in the feed list wether they symbolize an unreachable state (by being replaced with error symbols). In general you should check what the status bar says when you perform an update (of either single feeds or all feeds). To be honest your error report is pretty vague and one cannot really determine what you problem is. You really need to provide more details! For example I'm not sure you told how you trigger updates? Regards, Lars
Bug#433393: liferea doesn't update any feeds after migration to new format
On Mon, Mar 17, 2008 at 9:37 PM, Eddy Petrișor [EMAIL PROTECTED] wrote: Luis Rodrigo Gallardo Cruz wrote: On Mon, Mar 17, 2008 at 09:48:40PM +0200, Eddy Petrișor wrote: Lars Lindner wrote: Nonetheless I identified the problem. You do massively mark posts as important (flagged). Which is not forbidden, but was totally unexpected by me when I implemented the merging algorithm. Heh :-) . I usually do that so I can come back to them at any time I want to do read about the subject of the post. Is a way of archiving for me (since I saw is he only way to make liferea keep those posts from being lost into nothingness). Flagged items do have the property of never being dropped from Which is good :-), from my PoV. cache, but at the same moment we have a cache limit that the merging algorithm has to cope with. And the current calculation is simple: if the cache limit is 100 (like in your case and per default) and there are 100 (or more) flagged items that must never be dropped, then there is just no room to add new items. kaboom :-) As a temporary workaround you should increase the cache limit for all affected feeds (like the Debian Planet feed). I have, but it seems it already lost some of the items of the day... I'll probably change the limit first, then upgrade once more to the new format ;-) . If this works for you, please let me know. I'll then downgrade this report's severity but leave it open as a hint for others. Yes, it does, but why hide/bury it? Probably Lars will provide a fix soon and the problem will still be visible on an Etch-Lenny upgrade, if missed. I'd say there isn't a need for a severity downgrade, especially since the bug looks like is unreproducible at a first glance. I fixed this in SVN with this revision: http://liferea.svn.sourceforge.net/viewvc/liferea?view=revrevision=3766 Solution will be released upstream around next weekend with 1.4.15. I've tested the change for effectiveness with the cache files you provided some mails ago. I'll monitor it for stability some more days... But I think the change is not very intrusive, so it propably will be ok. Regards, Lars
Bug#433393: liferea doesn't update any feeds after migration to new format
On Mon, Mar 17, 2008 at 7:53 PM, Eddy Petrișor [EMAIL PROTECTED] wrote: Lars Lindner wrote: On Mon, Mar 17, 2008 at 4:33 PM, Luis Rodrigo Gallardo Cruz [EMAIL PROTECTED] wrote: On Mon, Mar 17, 2008 at 02:21:14PM +0200, Eddy Petrișor wrote: Luis Rodrigo Gallardo Cruz wrote: On Thu, Mar 13, 2008 at 02:33:54AM +0200, Eddy Petrișor wrote: On to more promising lands: Could you try running with --debug-update, please? I moved away the ~/.liferea_1.4 directory (safe copy) and ran: liferea --debug-update 21 | tee liferea_update The log is attached. I hate Heisenbugs. Not sure this is one. I see nothing obviously wrong in this log. Even worse, there are entries there about updating the feeds, mentioning relatively recent entries in, for example, Debian Planet. Did it keep failing after this update? Yes, for instance, Debian Planet is still stuck at that post, Sami Haahtinen: Installing Debian on NSLU2 from the 6th of March. Mmm. This makes me think it's reading them but then not commiting them to the database. Maybe something in the cache settings is malfunctioning. I can think of several scenarios you could be in: 1.) No updates saved to disk 2.) No updates executed at all 3.) No updates results processed 4.) No network connection. In case of 1.) you should see DB error messages on the command line. To verify this please run at least once on the command line and check for suspicious output. You might also run once with command line option --debug-db and check for errors. log attached, my untrained eye didn't spot any of those. In case of 2.) you can check using the Update Monitor options in the Tools menu. This will open a dialog presenting a list of all subscriptions that are to be updated and all that are downloaded right now. Here you should check wether there are feeds in the queue at all and if those are processed after a while. They are executed. I checked the Update Monitor and all the expected (I focused on Planet Debian) feeds appear and are processed rather quickly(didn't have to wait more than a few seconds) in front of my eyes. In case of 3.) you should check the output of a run with command line option --debug-update for HTTP error codes. The log for update is also attached (liferea-debug-upd.log) I won't pretend I know the http protocol enough to know what I'm talking about, but this looks odd: UPDATE: trying to merge Planet Debian to node id ymxftff UPDATE: - not adding Planet Debian to node id ymxftff... UPDATE: trying to merge Planet Debian to node id ymxftff UPDATE: - not adding Planet Debian to node id ymxftff... UPDATE: trying to merge The Linux Gang - Daily Top Blog Posts on Linux - Powered by SocialRank to node id ym xftff UPDATE: - not adding The Linux Gang - Daily Top Blog Posts on Linux - Powered by SocialRank to node id ymxf tff... UPDATE: trying to merge The Linux Gang - Daily Top Blog Posts on Linux - Powered by SocialRank to node id ym xftff UPDATE: - not adding The Linux Gang - Daily Top Blog Posts on Linux - Powered by SocialRank to node id ymxf tff... [...] This is also odd (why does it say the content didn't change?) UPDATE: trying to merge Planet Debian to node id ymxftff UPDATE: - not adding Planet Debian to node id ymxftff... UPDATE: 0 new items, cache limit is 100 - dropping 0 items UPDATE: merge itemset took 0,011s UPDATE: download result - HTTP status: 304, error: 1, netio error:0, data: 0 UPDATE: request (http:) finished UPDATE: processing request (http://www.debian.org/News/weekly/dwn.en.rdf) UPDATE: downloading http://www.debian.org/News/weekly/dwn.en.rdf UPDATE: download result - HTTP status: 200, error: 0, netio error:0, data: 19272560 UPDATE: request (http:) finished UPDATE: processing request (http://planet.debian.org/rss20.xml) UPDATE: downloading http://planet.debian.org/rss20.xml UPDATE: discovered feed format: rss UPDATE: old item set 0x2c282da0 of (node id=slgapfb): UPDATE: trying to merge Package Build Status to node id slgapfb UPDATE: - not adding Package Build Status to node id slgapfb... In case of 4.) please check if the online/offline icon in the lower left corner displays the online icon. Also you should check the icons in the feed list wether they symbolize an unreachable state (by being replaced with error symbols). Is online. All the feeds wear their individual logos. In general you should check what the status bar says when you perform an update (of either single feeds or all feeds). The status bar says explicitly Is updating the feeds, one by one, but also says that nothing changed. To be honest your error report is pretty vague and one cannot really determine what you problem is. You really need
Bug#470232: liferea: Filling out forms in tabs does not work
On Mon, Mar 10, 2008 at 3:44 AM, Daniel Jacobowitz [EMAIL PROTECTED] wrote: Package: liferea Version: 1.4.12-1 Severity: normal I opened a LiveJournal page in a tab (Open in New Tab) in liferea and tried to reply. I discovered that I can not use the space bar in a text box; the bottom status bar of the window displays There are no unread items every time I hit the space bar and no text is inserted. This is a limitation of the next-unread feature. If you bind it to Space you cannot use HTML forms. Please change the hotkey in the preferences to Ctrl-Space or Alt-Space to workaround this. This won't fix as there is no easy way to get Mozilla to tell if the Space was entered inside a form or not. Best Regards, Lars -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#470203: liferea: Error while startup
On Sun, Mar 9, 2008 at 10:29 PM, Frank Lanitz [EMAIL PROTECTED] wrote: Package: liferea Version: 1.4.12-1 Severity: minor While startup of liferea I'm receiving an error message: libnm_glib_nm_state_cb: dbus returned an error. (org.freedesktop.DBus.Error.ServiceUnknown) The name org.freedesktop.NetworkManager was not provided by any .service files It seems that there is no effect on functionality of Liferea. As you already suspected it has no effect on Liferea. This is a warning of DBUS that the NetworkManager service description does not exist. This isn't caused and cannot be fixed by Liferea. All programs using NetworkManager propably print this on startup. Best Regards, Lars -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#469907: liferea-webkit: Can't paste selected text
On Fri, Mar 7, 2008 at 9:34 PM, Martintxo [EMAIL PROTECTED] wrote: Package: liferea-webkit Version: 1.4.12-1 Severity: normal Tired for the recurse hungry of liferea with the xullrunner interface, I test the webkit one. All goes OK for now (only a one day test, but no crashes for now). Only one thing bother me: I can select the text in the news area (i see it in blue), but this text CAN'T be pasted in any other application (I test it even with xclipboard). However, if I uninstall the liferea-webkit package and therefore I start using the xull interface, i CAN paste the selected text in any application !!. So I think that the bug is in the webkit interface. My system is a Debian/Lenny that was updated yesterday. As window manager I use Icewm, and I not use any Gnome application (the paste test with gtk applications were made with abiword and sylpheed). There is a high propability that copypaste isn't implemented in the GTK implementation of WebKit. So IMO this should be a bug against WebKit itself. Best Regards, Lars -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#469245: liferea: slow and silent on first start after upgrade
On Tue, Mar 4, 2008 at 7:50 AM, Olivier Berger [EMAIL PROTECTED] wrote:
Package: liferea
Version: 1.4.12-1
Severity: normal
Hello.
On first start after upgrading to 1.4.12-1 (from 1.0* I think), it
starts but doesn't appear, as it is silently upgrading in the background it
seems.
No window appears to notify the user if there's a problem whatsoever.
I killed it and started it again from a terminal.
Now I could see :
libnm_glib_nm_state_cb: dbus returned an error.
(org.freedesktop.DBus.Error.ServiceUnknown) The name
org.freedesktop.NetworkManager was not provided by any .service files
Performing 1.0 - 1.4 cache migration...
copying /home/olivier/.liferea//cache
to /home/olivier/.liferea_1.4//cache
copying /home/olivier/.liferea//new_subscription
to /home/olivier/.liferea_1.4//new_subscription
However, it doesn't seem to do anything else.
The notification area contains an empty space, which seems to indicate
it was started, but the icon is not drawn yet.
Maybe a dialog script while it upgrades would be interesting at least ?
Also, tryng to strace -f -p on it I get :
[pid 16477] clock_gettime(CLOCK_REALTIME, {1204613303, 892974941}) = 0
[pid 16477] futex(0x80c6b8c, 0x80 /* FUTEX_??? */, 2133) = -1 ETIMEDOUT
(Connection timed out)
[pid 16477] futex(0x81dd5a8, 0x81 /* FUTEX_??? */, 1) = 0
[pid 16477] gettimeofday({1204613304, 393302}, NULL) = 0
[pid 16477] clock_gettime(CLOCK_REALTIME, {1204613304, 393413828}) = 0
[pid 16477] futex(0x80c6b8c, 0x80 /* FUTEX_??? */, 2135) = -1 ETIMEDOUT
(Connection timed out)
[pid 16477] futex(0x81dd5a8, 0x81 /* FUTEX_??? */, 1) = 0
[pid 16477] gettimeofday({1204613304, 893733}, NULL) = 0
[pid 16477] clock_gettime(CLOCK_REALTIME, {1204613304, 893843073}) = 0
[pid 16477] futex(0x80c6b8c, 0x80 /* FUTEX_??? */, 2137) = -1 ETIMEDOUT
(Connection timed out)
[pid 16477] futex(0x81dd5a8, 0x81 /* FUTEX_??? */, 1) = 0
[pid 16477] gettimeofday({1204613305, 394170}, NULL) = 0
[pid 16477] clock_gettime(CLOCK_REALTIME, {1204613305, 394282459}) = 0
You you please try to remove the file
/home/olivier/.liferea_1.4//new_subscription?
It is not need in 1.4 anymore (and was auto-deleted by 1.2 releases). It could
be that the process is reading the file as it were a real file. This
implies a bad
file type check in the migration routines. Argh...
Best Regards,
Lars
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#469245: liferea: slow and silent on first start after upgrade
On Tue, Mar 4, 2008 at 1:39 PM, Olivier Berger [EMAIL PROTECTED] wrote: Lars Lindner a écrit : You you please try to remove the file /home/olivier/.liferea_1.4//new_subscription? It is not need in 1.4 anymore (and was auto-deleted by 1.2 releases). It could be that the process is reading the file as it were a real file. This implies a bad file type check in the migration routines. Argh... Best Regards, Lars Hi. While you were answering, I thought of it myself and removed it from .liferea before starting it again, and this worked. That's the workaround, and confirms the bug. Thanks for the test! Fixed upstream [1]. Solution will be released upstream with 1.4.14 around next weekend. Best Regards, Lars [1] http://liferea.svn.sourceforge.net/viewvc/liferea?view=revrevision=3727
Bug#466879: liferea: date format still not quite right
On Tue, Feb 26, 2008 at 10:13 PM, Lars Lindner [EMAIL PROTECTED] wrote: On Sat, Feb 23, 2008 at 4:28 PM, Eric Cooper [EMAIL PROTECTED] wrote: Package: liferea Version: 1.4.11-1 Followup-For: Bug #466879 I have this setting: $ gconftool -g /apps/liferea/date-format %a %b %e %l:%M%P The %l should print the hour as 1 .. 12 with a leading space, but it prints a leading zero, as shown in the attached screenshot. Liferea reuses code from Evolution to solve certain locale problems that usually only US users experience because they don't set a locale. Without a set locale strftime format codes like %P and %l cannot work because they cannot decide wether 12 or 24h format is necessary. The workaround code from Evolution does automatically replace %P with AM and PM according to the current time and also replaces %l by %H which causes the leading zeros. This code is 1:1 copied from Evolution and due to it's complexity I don't intend to change it. I consider the leading zero only a minor glitch for a workaround due to a incorrect local setup caused by the user. Please check your locale and set it to a real one if necessary. IMO this is no bug. Sorry. I forgot to mention that this is an upstream opinion only. Also, is there any way to specify a different font for the date display? It would be nice to use a monospaced font so that the dates would line up. Liferea has no way to change the font of this column. But you can use GTK rc-files to set fonts of specific widget. I'm not sure if you can set only a single GtkTreeView column though. Best Regards, Lars Lindner -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#466879: liferea: date format still not quite right
On Tue, Feb 26, 2008 at 10:21 PM, Eric Cooper [EMAIL PROTECTED] wrote: On Tue, Feb 26, 2008 at 10:13:40PM +0100, Lars Lindner wrote: Please check your locale and set it to a real one if necessary. Here are my settings. Other locale-sensitive programs seem to work fine. $ locale LANG=en_US.UTF-8 LC_CTYPE=en_US.UTF-8 LC_NUMERIC=en_US.UTF-8 LC_TIME=en_US.UTF-8 LC_COLLATE=en_US.UTF-8 LC_MONETARY=en_US.UTF-8 LC_MESSAGES=en_US.UTF-8 LC_PAPER=en_US.UTF-8 LC_NAME=en_US.UTF-8 LC_ADDRESS=en_US.UTF-8 LC_TELEPHONE=en_US.UTF-8 LC_MEASUREMENT=en_US.UTF-8 LC_IDENTIFICATION=en_US.UTF-8 LC_ALL= :-) So my assumption might be incorrect. Here is what the Evolution code documentation says: /** * Function to do a last minute fixup of the AM/PM stuff if the locale * and gettext haven't done it right. Most English speaking countries * except the USA use the 24 hour clock (UK, Australia etc). However * since they are English nobody bothers to write a language * translation (gettext) file. So the locale turns off the AM/PM, but * gettext does not turn on the 24 hour clock. Leaving a mess. * * This routine checks if AM/PM are defined in the locale, if not it * forces the use of the 24 hour clock. * * The function itself is a front end on strftime and takes exactly * the same arguments. * * TODO: Actually remove the '%p' from the fixed up string so that * there isn't a stray space. **/ So it actually doesn't depend on the en_US locale to be set, but for a time format translation to be active. But I might be wrong in this understanding. The implementation is so that it if there is no locale time format code definition %l will be replaced with %H. If you are interested in veryifying this I'd suggest setting a breakpoint with gdb in src/e-date.c:105 (should be ffmt=g_strdup(fmt);). If the breakpoint triggers you have no locale translation installed which causes the problem. Regards, Lars -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#466879: liferea: date format still not quite right
On Sat, Feb 23, 2008 at 4:28 PM, Eric Cooper [EMAIL PROTECTED] wrote: Package: liferea Version: 1.4.11-1 Followup-For: Bug #466879 I have this setting: $ gconftool -g /apps/liferea/date-format %a %b %e %l:%M%P The %l should print the hour as 1 .. 12 with a leading space, but it prints a leading zero, as shown in the attached screenshot. Liferea reuses code from Evolution to solve certain locale problems that usually only US users experience because they don't set a locale. Without a set locale strftime format codes like %P and %l cannot work because they cannot decide wether 12 or 24h format is necessary. The workaround code from Evolution does automatically replace %P with AM and PM according to the current time and also replaces %l by %H which causes the leading zeros. This code is 1:1 copied from Evolution and due to it's complexity I don't intend to change it. I consider the leading zero only a minor glitch for a workaround due to a incorrect local setup caused by the user. Please check your locale and set it to a real one if necessary. IMO this is no bug. Also, is there any way to specify a different font for the date display? It would be nice to use a monospaced font so that the dates would line up. Liferea has no way to change the font of this column. But you can use GTK rc-files to set fonts of specific widget. I'm not sure if you can set only a single GtkTreeView column though. Best Regards, Lars -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#454184: liferea: having this issue with 1.4.11
On Feb 13, 2008 6:35 AM, Paul Wise [EMAIL PROTECTED] wrote: On Tue, 2008-02-12 at 23:29 -0600, Luis Rodrigo Gallardo Cruz wrote: On Wed, Feb 13, 2008 at 01:33:18PM +0900, Paul Wise wrote: [ Tracing the problem to the stored value of last-vpane-pos ] I did a bisect on this value using the following command and found that 635 was the magic value that caused crashes. 634 did not cause crashes. gconftool --type int --set /apps/liferea/last-vpane-pos 635 I removed all the gconf settings and ~/.liferea-1.4 then set last-vpane-pos to 635 and got the crash. I set it to 634 and did not get the crash. Hopefully I've provided enough information for this bug to be tracked down and fixed. Well, if you haven't that just means this is a *weird* bug. What size is the liferea main window when it starts up without crashing? Maximised. On my 1280x800 laptop LCD, I get this from xwininfo: xwininfo: Window id: 0x4600027 Liferea Absolute upper-left X: 0 Absolute upper-left Y: 41 Relative upper-left X: 0 Relative upper-left Y: 18 Width: 1280 Height: 738 Depth: 24 Visual Class: TrueColor Border width: 0 Class: InputOutput Colormap: 0x20 (installed) Bit Gravity State: NorthWestGravity Window Gravity State: NorthWestGravity Backing Store State: NotUseful Save Under State: no Map State: IsViewable Override Redirect State: no Corners: +0+41 -0+41 -0-21 +0-21 -geometry 1280x738+0-21 Looking at the code, last-vpane-pos is the size of the feedlist area. It would seem that making it too large gives too litle space to the item views. What I'd like to do is determine what's the minimum size those areas can have and not crash, and then change the code that sets the size from the stored pref to respect that minimum. I'll try to produce a patch to do that and a test package including it sometime this week. Cool, thanks. Thank you very much for this investigation. No problems. Just some additional information: I can reproduce it by using the gconf-tool command Paul suggested. But it doesn't crash immediately. I have to minimize the overall window size to totally hide the HTML widget. When I then exit the program and restart it again the following crash happens: Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 0x2b89c9d73a70 (LWP 11752)] mozsupport_set_zoom (embed=0x10aef30, aZoom=1) at mozsupport.cpp:120 120 mWebBrowser-GetContentDOMWindow(getter_AddRefs(mDOMWindow)); Current language: auto; currently c++ (gdb) bt #0 mozsupport_set_zoom (embed=0x10aef30, aZoom=1) at mozsupport.cpp:120 #1 0x004419b2 in ui_mainwindow_init (mainwindowState=0) at ui_mainwindow.c:679 #2 0x004316ef in main (argc=1, argv=0x7fffe9b27048) at main.c:290 (gdb) q So it seems that when the Gecko widget is not visible (realized) any operation on it causes a crash. I've tried to implement some simple fixes but was not successful so far. Regards, Lars -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#466879: liferea: timeformat broken
On Thu, Feb 21, 2008 at 5:51 PM, Eric Cooper [EMAIL PROTECTED] wrote: Package: liferea Version: 1.4.11-1 Severity: normal I have timeformat set to %a %b %e %l:%M%P, but a current headline is displayed with the date Today 11:07 AM, so the setting is not being followed. With 1.4.0 the gconf key to configure the time format was changed. The old name is /apps/liferea/date_format, the new one is /apps/liferea/date-format. This might be an explanation why your setting doesn't work anymore. More info on this can be found here: http://liferea.blogspot.com/2006/10/new-date-format.html Best Regards, Lars -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#466879: liferea: timeformat broken
On Thu, Feb 21, 2008 at 9:35 PM, Eric Cooper [EMAIL PROTECTED] wrote: On Thu, Feb 21, 2008 at 08:59:33PM +0100, Lars Lindner wrote: With 1.4.0 the gconf key to configure the time format was changed. The old name is /apps/liferea/date_format, the new one is /apps/liferea/date-format. This might be an explanation why your setting doesn't work anymore. More info on this can be found here: http://liferea.blogspot.com/2006/10/new-date-format.html Thanks, setting date-format did the right thing. (Note that the blog post refers to time-format, not date-format.) Oh, you are right. I corrected the mistake. I am puzzled why there are still gconf keys timeformat and timeformatmode, but not date-format. The old keys are not removed. This is for fallback to older Liferea versions and I see no way to easily remove those. I think this should go in a debian/NEWS file for the package. Best Regards Lars -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#454184: liferea: having this issue with 1.4.11
On Thu, Feb 21, 2008 at 11:07 PM, Luis Rodrigo Gallardo Cruz [EMAIL PROTECTED] wrote: On Thu, Feb 21, 2008 at 09:01:06PM +0100, Lars Lindner wrote: On Feb 13, 2008 6:35 AM, Paul Wise [EMAIL PROTECTED] wrote: On Tue, 2008-02-12 at 23:29 -0600, Luis Rodrigo Gallardo Cruz wrote: On Wed, Feb 13, 2008 at 01:33:18PM +0900, Paul Wise wrote: [ Tracing the problem to the stored value of last-vpane-pos ] I did a bisect on this value using the following command and found that 635 was the magic value that caused crashes. 634 did not cause crashes. I'll try to produce a patch to do that and a test package including it sometime this week. Cool, thanks. Just some additional information: I can reproduce it by using the gconf-tool command Paul suggested. But it doesn't crash immediately. I have to minimize the overall window size to totally hide the HTML widget. When I then exit the program and restart it again the following crash happens: Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 0x2b89c9d73a70 (LWP 11752)] mozsupport_set_zoom (embed=0x10aef30, aZoom=1) at mozsupport.cpp:120 120 mWebBrowser-GetContentDOMWindow(getter_AddRefs(mDOMWindow)); Current language: auto; currently c++ (gdb) bt #0 mozsupport_set_zoom (embed=0x10aef30, aZoom=1) at mozsupport.cpp:120 #1 0x004419b2 in ui_mainwindow_init (mainwindowState=0) at ui_mainwindow.c:679 #2 0x004316ef in main (argc=1, argv=0x7fffe9b27048) at main.c:290 (gdb) q So it seems that when the Gecko widget is not visible (realized) any operation on it causes a crash. I've tried to implement some simple fixes but was not successful so far. Indeed, that seems to be the problem. I sent a patch to the list a couple days ago? Did it get lost? It's in this bug's log, too. No. I received it. Just working through my inbox by oldest mails first :-) I've merged the patch [1] but do consider it only a workaround. In fact I could reproduce a situation where after starting with hidden Gecko widget I had an strange background color effect. Only parts of the CSS became active, some styles were completely black and thus rendering the output unusable. Best Regards, Lars [1] http://liferea.svn.sourceforge.net/viewvc/liferea?view=revrevision=3693 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#465202: Please make it possible to use liferea only with the keyboard
On Feb 11, 2008 2:18 PM, Cyril Brulebois [EMAIL PROTECTED] wrote: On 11/02/2008, Lars Lindner wrote: Please have a look at the shortcut list available under the Help - Short Reference menu option. Thanks, that helps, but still, it looks like a bug to me not being able to get back to say the toolbar, and select a button from there. Having a non-cycling selection of the different components of the interface is quite unusual at the very least. This is not an intended effect. It just happens and please don't ask me why, I do not understand what happens for the focus to get stuck at the GtkTreeView columns. It could even be that the keyboard shortcut handling is the culprit. We need some GTK+ professionals to look at this. I tried to debug it, but always failed. Best Regards, Lars -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#465202: Please make it possible to use liferea only with the keyboard
On Feb 11, 2008 9:44 AM, Cyril Brulebois [EMAIL PROTECTED] wrote: Package: liferea Version: 1.4.11-1 Severity: wishlist Hi, currently, once a folder has been selected on the left pane, it's only possible to reach with the tab key: the toolbar and its buttons, then the left pane with all subscriptions, and once one has been selected, the next tab press moves to the the headers of the item list on the right top pane, and it's no longer possible to cycle to the next item, nor to get back using shift-tab. I know there's Ctrl-N to work around that a bit, but that doesn't make it possible to skip this or that subscription so as to jump to another one, like one could do by using the arrows in the left pane. Please have a look at the shortcut list available under the Help - Short Reference menu option. Best Regards, Lars -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#461347: liferea: Crashes when trying to create new News Bin
On Jan 17, 2008 11:50 PM, rob [EMAIL PROTECTED] wrote: Package: liferea Version: 1.4.10-1 Severity: normal When trying to create News Bin from right-click options on sidebar program crashes after entering name and clicking OK Run from terminal: Liferea did receive signal 11 (Segmentation fault). Error in Xorg: An exit code of 1 was returned from liferea Known problem which is fixed upstream in 1.4.11 Best Regards, Lars -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#454333: liferea: Crashes on starting a search
On Dec 4, 2007 8:09 PM, Ingo Saitz [EMAIL PROTECTED] wrote: How to reproduce: Create a search folder with some hits, select an article in it, bring up the search (eithr via menu or c-f) and type something in. Upon starting the search liferea crashes. On the console it writes: ** ERROR **: file itemlist.c: line 259 (itemlist_load): assertion failed: (!itemlist_priv.guids) aborting... Abgebrochen Known issue of 1.4.9. Already fixed in SVN. Solution will be released upstream with 1.4.10. Regards, Lars -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#453521: Negative filters in search folders
On Nov 30, 2007 5:19 PM, Lars Lindner [EMAIL PROTECTED] wrote: On Nov 30, 2007 4:56 PM, Erich Schubert [EMAIL PROTECTED] wrote: Hi Lars, If possible please post the output of a run with $ liferea --debug-db | grep CREATE VIEW it could be that the DB view WHERE clause for the search folder is incorrect. WHERE (items.title LIKE '%Tango%' OR items.description LIKE '%Tango%') AND (items.title LIKE '%Gnome%' OR items.description LIKE '%Gnome%') AND items.comment != 1; I'm missing a NOT after the AND. Yes, it's clearly wrong. I promise to check the view generation logic. I found the code to be broken, ignoring the negative logic. I somehow dropped it during the last rewrite. I fixed this in SVN. Solution will be released upstream with 1.4.9 Regards, Lars -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#453521: Negative filters in search folders
On Nov 30, 2007 4:56 PM, Erich Schubert [EMAIL PROTECTED] wrote: Hi Lars, If possible please post the output of a run with $ liferea --debug-db | grep CREATE VIEW it could be that the DB view WHERE clause for the search folder is incorrect. WHERE (items.title LIKE '%Tango%' OR items.description LIKE '%Tango%') AND (items.title LIKE '%Gnome%' OR items.description LIKE '%Gnome%') AND items.comment != 1; I'm missing a NOT after the AND. Yes, it's clearly wrong. I promise to check the view generation logic. Best Regards, Lars -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#453521: Negative filters in search folders
On Nov 30, 2007 1:55 AM, Erich Schubert [EMAIL PROTECTED] wrote: Package: liferea Version: 1.4.6-1 Severity: normal Negative matches don't work in search folders. I tried to make a search folder for the Topic Tango, but not including GNOME. However, even when I select Post does not contain GNOME, I only get results which actually DO contain GNOME in them. Might be a translation issue though - I'm using it with the german locale. Maybe the filter messages are just incorrectly translated? If possible please post the output of a run with $ liferea --debug-db | grep CREATE VIEW it could be that the DB view WHERE clause for the search folder is incorrect. Best Regards, Lars -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#451548: CVE-2005-4791: Insecure LD_LIBRARY_PATH in liferea
On Nov 16, 2007 8:57 PM, Stefan Fritsch [EMAIL PROTECTED] wrote:
Package: liferea
Version: 1.0.27-2
Severity: important
Tags: security
Liferea 1.4.6-1 sets
LD_LIBRARY_PATH=/usr/lib/xulrunner:$LD_LIBRARY_PATH
in its start script. If LD_LIBRARY_PATH is empty, this will result in
LD_LIBRARY_PATH=/usr/lib/xulrunner:
which is equivalent to
LD_LIBRARY_PATH=/usr/lib/xulrunner:.
This means the current working directory is searched for libraries before /lib
and /usr/lib, which is of course a security problem.
Liferea 1.0.27-2 uses
LD_LIBRARY_PATH=:$LD_LIBRARY_PATH
which is even insecure if LD_LIBRARY_PATH was set.
Instead of :$LD_LIBRARY_PATH use
${LD_LIBRARY_PATH+:$LD_LIBRARY_PATH}, which expands to nothing (not
even a colon) if LD_LIBRARY_PATH is empty.
Please mention the CVE id in the changelog.
Upstream I implemented the following solution:
Index: src/liferea.in
===
--- src/liferea.in (Revision 3546)
+++ src/liferea.in (Arbeitskopie)
@@ -14,8 +14,18 @@
params=$@
[EMAIL PROTECTED]@:$LD_LIBRARY_PATH
-export LD_LIBRARY_PATH
+#
+# If we run with Gecko or XulRunner we need to set
+# LD_LIBRARY_PATH (WebKit and GtkHTML do not need this).
+#
+if [ @MOZILLA_LIB_ROOT@ != ]; then
+ if [ $LD_LIBRARY_PATH = ]; then
+ [EMAIL PROTECTED]@
+ else
+ [EMAIL PROTECTED]@:$LD_LIBRARY_PATH
+ fi
+ export LD_LIBRARY_PATH
+fi
if [ -z $DBUS_SESSION_BUS_ADDRESS ]; then
eval `dbus-launch`
Do you think this is sufficient?
Best Regards,
Lars
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#448850: CVE-2007-5751 insecure file permissions of feedlist.ompl backup file
On 11/1/07, Luis Rodrigo Gallardo Cruz [EMAIL PROTECTED] wrote: On Thu, Nov 01, 2007 at 01:30:45PM +0100, Nico Golde wrote: CVE-2007-5751[0]: | Liferea before 1.4.6 uses weak permissions (0644) for the | feedlist.opml backup file, which allows local users to | obtain credentials. It appears that the problem is not present in 1.0.*, as those versions do not create a backup for that file. At least, my local install has propper permissions on the file: $ ls -l ~/.liferea/fedlist.opml -rw--- 1 rodrigo users 5954 2007-06-03 21:31 /home/rodrigo/.liferea/feedlist.opml Lars, could you please confirm this? Yes, this is correct. Feed list backup was introduced with 1.2.x (but I'd have to check in SVN to tell the exact version). Regards, Lars -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#448272: liferea-webkit segfaults with embedded flash in feeds
On 10/27/07, Santiago Ruano Rincón [EMAIL PROTECTED] wrote: Package: liferea-webkit Version: 1.4.5-1 Severity: grave -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 liferea-webkit segfaults when I try to read the feed from [1], which has an embedded youtube video. [1] http://orsai.es/2007/10/el_sentido_del_olfato_en_los_trenes.php gdb output is attached to the mail. Thanks for maintaining liferea, WebKit is known to crash regularily in curl. It is usually reproducable within Liferea when the viewed headline contains images that are loaded asynchronously. IMO this is a problem in WebKit. Regards, Lars
Bug#445666: liferea: Does not sync updated feeds to disk?
On 10/10/07, Marco d'Itri [EMAIL PROTECTED] wrote: On Oct 09, Lars Lindner [EMAIL PROTECTED] wrote: That seems reasonable. Do you think it worthwhile to close and reopen the database forcibly every so often, to prevent this? Yes, I think it would. But it still would be a workaround. I'd rather have a simple workaround than the current state of brokeness, my computer crashed and I lost three days of updated feeds. For completeness: such a workaround was added with 1.4.5 Regards, Lars -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#446050: no UI on startup
On 10/11/07, Luis Rodrigo Gallardo Cruz [EMAIL PROTECTED] wrote: On Wed, Oct 10, 2007 at 08:54:57PM -0500, wrote: On Wed, Oct 10, 2007 at 09:46:32AM +0200, Thomas Morin wrote: I notice the following error on startup : *** glibc detected *** /usr/bin/liferea-bin: free(): invalid pointer: 0x08514040 *** libsqlite3-0 3.5.1-1 3.4.2-2 Found it! The error appears if I upgrade this lib to the experimental version. I'll try to see if the error is happening inside the lib. I got a similar report upstream. http://sourceforge.net/tracker/index.php?func=detailaid=1811055group_id=87005atid=581684 And I have no clue what could cause it. Lars -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#446050: Liferea dies with sqlite 3.5
* Luis Rodrigo Gallardo Cruz [EMAIL PROTECTED] [2007-10-11 11:54]: tag 446050 help thanks The current version of liferea in Debian unstable (1.4.3-1), as well as the latest upstream version (1.4.5) fail if used together with libsqlite3-0 from experimental (3.5.1-1). The program works correctly with the versions in testing and unstable (3.4.2-1, 3.4.2-2). The following error mesage is printed to the console: *** glibc detected *** /usr/bin/liferea-bin: free(): invalid pointer: 0x08514040 *** [...] The reason might be the change in sqlite3_free. In prior versions it did the same like free but now it does some additional mutex stuff for example. Maybe some free needs to be changed to sqlite3_free (you'll see in a backtrace). Thanks for this hint! I checked the code and found at least one place with this problem. Sadly it is not related to the hanging statement. If anyone wants to try: patch is attached. Lars Index: src/db.c === --- src/db.c (Revision 3481) +++ src/db.c (Arbeitskopie) @@ -1274,7 +1274,7 @@ res = sqlite3_step (itemCheckStmt); - sqlite3_free (sql); + g_free (sql); sqlite3_finalize (itemCheckStmt); return (SQLITE_ROW == res);
Bug#446050: Liferea dies with sqlite 3.5
On 10/11/07, Nico Golde [EMAIL PROTECTED] wrote: Hi, * Luis Rodrigo Gallardo Cruz [EMAIL PROTECTED] [2007-10-11 11:54]: tag 446050 help thanks The current version of liferea in Debian unstable (1.4.3-1), as well as the latest upstream version (1.4.5) fail if used together with libsqlite3-0 from experimental (3.5.1-1). The program works correctly with the versions in testing and unstable (3.4.2-1, 3.4.2-2). The following error mesage is printed to the console: *** glibc detected *** /usr/bin/liferea-bin: free(): invalid pointer: 0x08514040 *** [...] The reason might be the change in sqlite3_free. In prior versions it did the same like free but now it does some additional mutex stuff for example. Maybe some free needs to be changed to sqlite3_free (you'll see in a backtrace). This was the critical hint. Thanks again! Fixed upstream with Liferea release 1.4.5b. Patch against 1.4.5 is attached. Best Regards, Lars Index: src/db.c === --- src/db.c (Revision 3481) +++ src/db.c (Arbeitskopie) @@ -1304,7 +1304,7 @@ if (SQLITE_OK != res) debug2 (DEBUG_DB, Create view failed (%s) SQL: %s, err, sql); - g_free (select); + sqlite3_free (select); sqlite3_free (sql); sqlite3_free (err); }
Bug#445666: liferea: Does not sync updated feeds to disk?
On 10/9/07, Daniel Jacobowitz [EMAIL PROTECTED] wrote: On Sun, Oct 07, 2007 at 07:34:59PM +0200, Lars Lindner wrote: Known problem. No solution in sight. I already tried reproducing the effect with a test program using the same schema and similar SQL statements as Liferea, but it doesn't show the same problem. I have the feeling this might be caused by some threading effects in Liferea, but know nothing certain... That seems reasonable. Do you think it worthwhile to close and reopen the database forcibly every so often, to prevent this? Yes, I think it would. But it still would be a workaround. Lars -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#445666: liferea: Does not sync updated feeds to disk?
On 10/7/07, Daniel Jacobowitz [EMAIL PROTECTED] wrote: Package: liferea Version: 1.4.3-1 Severity: normal I never quit liferea. It runs until either it crashes or my entire system crashes. This used to be fine, but today I've discovered that it isn't caching updated feeds to disk. So after a crash I restart it and it has three hundred new articles that I've already read through liferea, plus five at the bottom that are new since the crash. Known problem. No solution in sight. I already tried reproducing the effect with a test program using the same schema and similar SQL statements as Liferea, but it doesn't show the same problem. I have the feeling this might be caused by some threading effects in Liferea, but know nothing certain... I don't have any useful debug output, just things like this which I don't think are related: ** (liferea:11306): WARNING **: Dropping view failed (no such table: view_gbqxdin) SQL: DROP VIEW view_gbqxdin; ** (liferea:11306): WARNING **: Dropping view failed (no such table: view_rlfnxtd) SQL: DROP VIEW view_rlfnxtd; These two messages are no real problem. But are fixed with upstream release 1.4.4 ** (gecko:11306): WARNING **: Fatal: no node with id cvvyivo found! ** (gecko:11306): WARNING **: Fatal: no node with id cvvyivo found! Also not really critical usually triggered by using comment feeds. I'll work on this in the future. Regards, Lars -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#445219: Clicking above or below thumb in item scrollbar does not scroll
On 10/4/07, Matt Kraai [EMAIL PROTECTED] wrote: Package: liferea-webkit Version: 1.4.3-1 If I click above or below the thumb on the item's scrollbar, the item is not scrolled. I would expect it to be scrolled. I can reproduce this. The scrollbars are realized by the WebKit GTK widget implementation. There is no code in Liferea for this. Regards, Lars -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#445218: Links opened in Liferea's window
On 10/4/07, Matt Kraai [EMAIL PROTECTED] wrote: Package: liferea-webkit Version: 1.4.3-1 When I click on a link in an item, the link is opened in Liferea's window. I have the Open links in Liferea's window option disabled. I would expect it to open the link in an external browser. Currently it is unclear how WebKit embedders should intercept WebKit context menues. From my understanding of the other backends (Win, Qt) I have the impression that WebKit will implement context menues for itself. Also the GdkLauncher example application has no such feature. I'd say it cannot be implemented at the moment until the GTK interface becomes clearer. Regards, Lars -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#445217: Space bar does not scroll articles
On 10/4/07, Matt Kraai [EMAIL PROTECTED] wrote: Package: liferea-webkit Version: 1.4.3-1 If I click somewhere in the article pane and press the Space bar, nothing happens. I'd expect it to scroll the article down. At the moment WebKit does not provide a scrolling interface (at least I know of no such interface) and does not implement the feature itself (like Gecko and gtkhtml2 do). Therefore IMO this should be a bug against WebKit. Regards, Lars -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#443751: liferea: Tries to run scripts to retrieve favicons
On 9/23/07, Daniel Jacobowitz [EMAIL PROTECTED] wrote: I have a feed which is generated by a local perl script. The subscription has the perl script set as a command to execute. When I click the Update all favicons button in the preferences dialog, I see on liferea's stderr: sh: /home/drow/livejournal: is a directory The script is in /home/drow/livejournal/ljfriendfeed-local.pl. At a guess, liferea has stripped off the last bit of the pathname and tried to execute it again to get a favicon. This is a bit silly. (Somehow, it's coming up with an icon from livejournal.com anyway. I don't know how, but it's nice...) Well, the favicon scanning is pretty sophisticated ;-) What it does is to look in five different places for the favicon. Two of them are the source URL and the source server URL. The others are derived from the feeds base URL if the feed provides one. The bug was caused by treating feed source commands like HTTP sources. I fixed this in SVN (to be released with 1.4.4). So now Liferea will not use the source URL for feed source commands but still do the feed base URL scan. Lars -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#430782: liferea: Please be more flexible with XML input
On 6/29/07, Daniel Jacobowitz [EMAIL PROTECTED] wrote: On Fri, Jun 29, 2007 at 10:37:38PM +0200, Lars Lindner wrote: For correctness LJ should provide Atom feeds which wrap everything in a div lj:ns=http://livejournal.com/something; Of course prefix lj and URL are fictional and should be replaced with the real values I do not know. Alternatively as you suggest we could have a filter adding it afterwards. Hmm, the header is: rss version='2.0' xmlns:lj='http://www.livejournal.org/rss/lj/1.0/' It's just when you go to parse the description that that namespace prefix is not applied; I presume the description is treated as a separate document. Is that at all useful? Yes, it is. I've thought a while over it and I think it is a good idea to treat global namespaces and add them to the extracted feed items content. What I'm missing at the moment is a LiveJournal example feed. I searched a bit but could not find any RSS feeds on LiveJournal. It seems like they per-default only advertise Atom feeds (which of course is a good idea). Maybe you could send me a copy of a feed? Or URLs of freely available feeds with the problem? Lars -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#430782: liferea: Please be more flexible with XML input
On 9/21/07, Daniel Jacobowitz [EMAIL PROTECTED] wrote: On Thu, Sep 20, 2007 at 11:57:50PM +0200, Lars Lindner wrote: Yes, it is. I've thought a while over it and I think it is a good idea to treat global namespaces and add them to the extracted feed items content. Great! Thanks for getting back to me. What I'm missing at the moment is a LiveJournal example feed. I searched a bit but could not find any RSS feeds on LiveJournal. It seems like they per-default only advertise Atom feeds (which of course is a good idea). Maybe you could send me a copy of a feed? Or URLs of freely available feeds with the problem? RSS feeds are at http://username.livejournal.com/data/rss. I picked one off the front page and here you go: http://community.livejournal.com/nflfans/data/rss Right at the moment the first and fifth items in the feed show this bug. Thanks for the link. It helped me to create a solution. Now Liferea copies all global namespace definitions to the generated XHTML root node. This solves the problem for me. Fix available in SVN to be released with 1.4.3 Lars -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#442798: Details
On 9/19/07, Yannick Palanque [EMAIL PROTECTED] wrote: In ~/.lifera_1.4/feedlist.opml updateInterval value isn't correctly updated. If you set for instance an update interval of 20 minutes for feed Planet debian you have: outline title=Planet Debian text=Planet Debian description=Planet Debian type=rss id=slsguir sortColumn=time viewMode=0 htmlUrl=http://planet.debian.org/; xmlUrl=http://planet.debian.org/rss20.xml; updateInterval=20/ You have as well updateInterval=20 for 20 hours or days. In GUI, the value isn't remembered when you leave the window of properties of a feed. Reproduced. Fix will be released upstream in 1.4.2b. Lars -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#368986: liferea: getting the spacebar to do something sensible
On 9/15/07, Marco d'Itri [EMAIL PROTECTED] wrote: reopen 368986 thanks I have the same problem. Since I upgraded ctrl+space works but just space does not anymore. This is fixed in upstream 1.4.2 Regards, Lars -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#439151: swig: malloc.h not available on all platforms
Package: swig Version: 1.3.31-1 Severity: normal The current swig version does generate code with an include to malloc.h which is not available on MacOS platform and therefore won't compile there. This is described upstream in https://sourceforge.net/tracker/?func=detailatid=301645aid=1640862group_id=1645 This link says a patch was already committed by the developers. But I'm not sure which is the exact version fixing it... Thanks in advance! Lars -- System Information: Debian Release: lenny/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 2.6.22-1-amd64 (SMP w/2 CPU cores) Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages swig depends on: ii libc6 2.6.1-1GNU C Library: Shared libraries ii libgcc1 1:4.2.1-4 GCC support library ii libstdc++64.2.1-4The GNU Standard C++ Library v3 swig recommends no packages. -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#439151: swig: malloc.h not available on all platforms
On 8/22/07, Torsten Landschoff [EMAIL PROTECTED] wrote: Hi Lars, On Wed, Aug 22, 2007 at 07:56:02PM +0200, Lars Lindner wrote: The current swig version does generate code with an include to malloc.h which is not available on MacOS platform and therefore won't compile there. This is described upstream in https://sourceforge.net/tracker/?func=detailatid=301645aid=1640862group_id=1645 This link says a patch was already committed by the developers. But I'm not sure which is the exact version fixing it... The next that will be released, I guess. I patched the Debian package and just sent the upload to the Debian archive. Great! Thanks for the fast reaction. Lars -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#430782: liferea: Please be more flexible with XML input
On 6/29/07, Daniel Jacobowitz [EMAIL PROTECTED] wrote: Package: liferea Version: 1.2.16b-1 Followup-For: Bug #430782 The error message is accurate: XML Parsing Error: prefix not bound to a namespace Location: file:/// Line Number 450, Column 119: The XML isn't valid, but many feeds seem to have this level of inaccuracy and it would be much more useful for liferea (or the renderer) to cope. LiveJournal seems to be pretty careless though; it also outputs some utf-8 XML files that are not valid utf-8 :-( I don't think the error message is comingf from liferea, but I don't know if it comes from libxml2 or xul. You are correct this is an error message given by libxml2. But you are totally wrong about handling invalid XML. The core idea of XML is to guarantee applications a correct content encoding by ensuring well-formedness and validity of the given data. So suggesting to have weak XML parsing invalidates the idea of XML itself. Also what should a parser do with a file that contains for example partly UTF-8 content and partly Latin-1? There is no way to decide what to do with the byte mess. With XML the rule is applications should *ALWAYS* refuse non-wellformed content. Also when using a library for parsing the application has no way to force tolerant parsing. As for libxml2 I know for sure that the author clearly disagrees with applications wanting to do tolerant parsing. Lars -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#430782: liferea: Please be more flexible with XML input
On 6/29/07, Daniel Jacobowitz [EMAIL PROTECTED] wrote: On Fri, Jun 29, 2007 at 08:59:37PM +0200, Lars Lindner wrote: You are correct this is an error message given by libxml2. But you are totally wrong about handling invalid XML. The core idea of XML is to guarantee applications a correct content encoding by ensuring well-formedness and validity of the given data. So suggesting to have weak XML parsing invalidates the idea of XML itself. Also what should a parser do with a file that contains for example partly UTF-8 content and partly Latin-1? There is no way to decide what to do with the byte mess. You'll note that I carefully did not suggest Liferea should be tolerant of the messed up UTF-8; I was just complaining about it. I fixed that elsewhere by judicious use of iconv and outside knowledge. An unbound prefix is a very different sort of error from invalid UTF-8. Well, it is still complaining :-) With XML the rule is applications should *ALWAYS* refuse non-wellformed content. Also when using a library for parsing the application has no way to force tolerant parsing. As for libxml2 I know for sure that the author clearly disagrees with applications wanting to do tolerant parsing. In any case, previous versions of liferea were able to display these common entries without trouble. I don't know if that means it did not push article bodies through libxml2; I think it somewhat likely, since this is the escaped contents of the description, not part of the RSS feed proper. Normally that's HTML, with all the attendant sloppiness, rather than well-formed XML. The reason is that the 1.0.x series did generate HTML for rendering. 1.2.x uses XHTML which automatically includes namespace checks. And to be honest I see no easy solution for embedded namespaces. Is the feed reader to be expected to extract and merge namespaces defined by the feed (and different ones over time!) into the XHTML generated to render items? I think it is technically possible, but also really troublesome. Lars -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#430782: liferea: Please be more flexible with XML input
On 6/29/07, Daniel Jacobowitz [EMAIL PROTECTED] wrote: On Fri, Jun 29, 2007 at 09:32:10PM +0200, Lars Lindner wrote: With XML the rule is applications should *ALWAYS* refuse non-wellformed content. Also when using a library for parsing the application has no way to force tolerant parsing. As for libxml2 I know for sure that the author clearly disagrees with applications wanting to do tolerant parsing. In any case, previous versions of liferea were able to display these common entries without trouble. I don't know if that means it did not push article bodies through libxml2; I think it somewhat likely, since this is the escaped contents of the description, not part of the RSS feed proper. Normally that's HTML, with all the attendant sloppiness, rather than well-formed XML. The reason is that the 1.0.x series did generate HTML for rendering. 1.2.x uses XHTML which automatically includes namespace checks. And to be honest I see no easy solution for embedded namespaces. Is the feed reader to be expected to extract and merge namespaces defined by the feed (and different ones over time!) into the XHTML generated to render items? I think it is technically possible, but also really troublesome. I see. We don't have any marker indicating what sort of data the description is, unfortunately. I think expecting it to be well-formed XHTML may be... a little overly optimistic, given the sorts of things that generate RSS feeds. Maybe there's some manual way to avoid this problem - allowing the user to manually bind a specific prefix? If there isn't, I can hack up a filter for my local LJ feeds. But it would be nice if it worked out of the box. For correctness LJ should provide Atom feeds which wrap everything in a div lj:ns=http://livejournal.com/something; Of course prefix lj and URL are fictional and should be replaced with the real values I do not know. Alternatively as you suggest we could have a filter adding it afterwards. Lars -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#426779: liferea: notification area icon not transparent anymore
On 6/28/07, Luis Rodrigo Gallardo Cruz [EMAIL PROTECTED] wrote: tag 426779 upstream fixed-upstream thanks On Wed, May 30, 2007 at 10:40:26PM +0200, Nicolas Évrard wrote: Those are transparent png files but does not seems transparent in the notification area. I wonder why ... Well, upstream has found the reason for this and has a fix, included in 1.2.17, which I'll be uploading soon(ish). http://liferea.blogspot.com/2007/06/transparent-tray-icon.html Please note that 1.2.17 in the post was incorrect. Fix will be in 1.2.18. Sorry about this. Lars
Bug#423839: wakes up too often (wastes power)
Am Montag, den 14.05.2007, 15:45 +0200 schrieb Steinar H. Gunderson:
Package: liferea
Version: 1.0.27-2
Severity: normal
Tags: upstream
Hi,
While playing around with PowerTOP, I noticed liferea-bin showed up on
the list. In short, it seems to wake up 10-15 times each second even
though it's totally idle:
poll([{fd=6, events=POLLIN}, {fd=8, events=POLLIN}, {fd=9, events=POLLIN},
{fd=12, events=POLLIN|POLLPRI}, {fd=14, events=POLLIN|POLLPRI}, {fd=15,
events=POLLIN|POLLPRI}, {fd=16, events=POLLIN|POLLPRI}, {fd=19,
events=POLLIN}, {fd=27, events=POLLIN}, {fd=20, events=POLLIN}], 10, 99) = 0
gettimeofday({1179150259, 840258}, NULL) = 0
ioctl(8, FIONREAD, [0]) = 0
gettimeofday({1179150259, 840346}, NULL) = 0
poll([{fd=6, events=POLLIN}, {fd=8, events=POLLIN}, {fd=9, events=POLLIN},
{fd=12, events=POLLIN|POLLPRI}, {fd=14, events=POLLIN|POLLPRI}, {fd=15,
events=POLLIN|POLLPRI}, {fd=16, events=POLLIN|POLLPRI}, {fd=19,
events=POLLIN}, {fd=27, events=POLLIN}, {fd=20, events=POLLIN}], 10, 99) = 0
gettimeofday({1179150259, 940423}, NULL) = 0
ioctl(8, FIONREAD, [0]) = 0
gettimeofday({1179150259, 940509}, NULL) = 0
I couldn't figure out offhand where all this polling taking place and
why, but I can't really figure out why it would happen either. For the
record, I also tried with 1.2.7-1 from experimental, and it has the same
issues.
There was a similar bug forwarded upstream from Fedora including a patch
to set up the timer only on demand instead of running periodically.
I think this will solve the issue. To be released with 1.2.15.
Lars
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#415951: Feed list export *does* work but outputs an error message
On 3/23/07, Julien Valroff [EMAIL PROTECTED] wrote: Hi, Sorry but I hadn't paid attention that my feed list is actually exported, and the generated opml file seems to be ok, containing all my feeds. However, this error message is quite misleading. This was fixed in 1.2.8 The feed list generation itself is not effected, it's just a wrong result code handling leading to the error message box. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#379900: liferea: Sporadic crashes on amd64 -- Please retest with 1.0.27-1
Am Samstag, den 10.02.2007, 14:33 -0800 schrieb Devin Carraway: On Fri, Feb 09, 2007 at 12:07:26PM +0100, Lars Lindner wrote: It could be worth to backport it. The simple patch is available from here (md5.patch): http://sourceforge.net/tracker/download.php?group_id=87005atid=581684file_id=213406aid=1636563 I also attached the file. Yugh. Why do people write arch-dependent code like that, anyway. :P I hand-applied the patch to 1.0.27-1, and it crashed within a few minutes in the same fashion as usual -- uncorrelated with a specific interaction, while the mouse was moving around between other unrelated windows. The stack trace shows it faulting in the same place as before: #0 0x2aea94511f64 in memcpy () from /lib/libc.so.6 #1 0x2aea92105268 in _gdk_x11_convert_to_format () from /usr/lib/libgdk-x11-2.0.so.0 #2 0x2aea921060c9 in ?? () from /usr/lib/libgdk-x11-2.0.so.0 #3 0x2aea920f7e0d in ?? () from /usr/lib/libgdk-x11-2.0.so.0 #4 0x2aea91da8153 in ?? () from /usr/lib/libgtk-x11-2.0.so.0 #5 0x2aea91dc864d in _gtk_marshal_BOOLEAN__BOXED () from /usr/lib/libgtk-x11-2.0.so.0 [...] When using GtkHTML2 or Gecko? From the reports upstream I got the impression that the problem is solved for everyone when Gecko rendering is used. But I got only feedback from a few users. Lars -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#379900: liferea: Sporadic crashes on amd64 -- Please retest with 1.0.27-1
Am Freitag, den 09.02.2007, 00:39 -0800 schrieb Devin Carraway:
FWIW, liferea 1.2.5 was released recently; its changelist cites the fixing of
a crash on 64-bit platforms. I've been using it for the past five or six days
and haven't crashed it yet, which is better than 1.0.27-1 ever did.
This deep in the Etch freeze it's probably not reasonable to try to do a major
update, but the fix itself might be easily backportable.
It could be worth to backport it. The simple patch is available from
here (md5.patch):
http://sourceforge.net/tracker/download.php?group_id=87005atid=581684file_id=213406aid=1636563
I also attached the file.
Index: src/net/md5.h
===
--- src/net/md5.h (Revision 2734)
+++ src/net/md5.h (Arbeitskopie)
@@ -30,12 +30,10 @@
#ifndef MD5_H
#define MD5_H
-#ifdef __alpha
-typedef unsigned int uint32;
-#else
-typedef unsigned long uint32;
-#endif
+#include glib.h
+#define uint32 guint32
+
struct MD5Context {
uint32 buf[4];
uint32 bits[2];
Bug#408475: liferea wrapper script is brittle, depends on $0
Am Donnerstag, den 25.01.2007, 18:26 -0800 schrieb [EMAIL PROTECTED]: Package: liferea Version: 1.0.27-1 Severity: minor *** Please type your report below this line *** liferea's wrapper startup script depends upon the shell passing in a full path for $0, which is not always the case. For example, when running under valgrind: [EMAIL PROTECTED]:~ valgrind liferea ==25483== Memcheck, a memory error detector. [...] /usr/bin/liferea: line 18: /home/jrodman/liferea-bin: No such file or directory /usr/bin/liferea: line 18: exec: /home/jrodman/liferea-bin: cannot execute: No such file or directory [...] Or when trying to see, for example, how the wrapper works: [EMAIL PROTECTED]:~ sh -x liferea ++ dirname liferea + dist_bin=. + params= + LD_LIBRARY_PATH=: + export LD_LIBRARY_PATH + '[' -z '' ']' ++ dbus-launch + eval DBUS_SESSION_BUS_ADDRESS=unix:abstract=/tmp/dbus-rGNlw7uW3u,guid=affb28b60b54567c91286f0045b964cd DBUS_SESSION_BUS_PID=25514 ++ DBUS_SESSION_BUS_ADDRESS=unix:abstract=/tmp/dbus-rGNlw7uW3u,guid=affb28b60b54567c91286f0045b964cd ++ DBUS_SESSION_BUS_PID=25514 + export DBUS_SESSION_BUS_ADDRESS + exec ./liferea-bin /usr/bin/liferea: line 18: /home/jrodman/liferea-bin: No such file or directory /usr/bin/liferea: line 18: exec: /home/jrodman/liferea-bin: cannot execute: No such file or directory If computing dist_bin is truly required, consider defaulting it to /usr/bin, in the case that $(basename $0) == $0 eg. --- liferea.orig2007-01-25 18:20:27.0 -0800 +++ liferea 2007-01-25 18:23:22.0 -0800 @@ -4,7 +4,13 @@ # This script should be used to start Liferea # to ensure a running DBUS session. -dist_bin=`dirname $0` +# default +dist_bin=/usr/bin + +# autodetect alternate location when $0 provides information +if [ `basename $0` != $0 ]; then + dist_bin=`dirname $0` +fi params=$@ LD_LIBRARY_PATH=:$LD_LIBRARY_PATH I added your solution upstream. I only exchanged /usr/bin with the configure variable for the installation prefix. Thanks for the patch, will be released with 1.2.5. Lars -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#361376: liferea still segfaults on amd64
Am Dienstag, den 23.01.2007, 22:39 +0100 schrieb Kurt Roeckx: On Tue, Jan 23, 2007 at 07:39:30PM +0100, Josselin Mouette wrote: reopen 361376 found 361376 1.0.27-1 found 361376 1.1.7c-1 thanks I'm still experiencing lots of segfaults with liferea-gtkhtml on amd64, and not on i386. It happens with both the unstable and the experimental version. Hi, You marked it as segfaulting in unstable and experimental. Does it also affect the version in testing (1.0.26-1)? No chance it is the same over all version. It is just unusable. I added a check in SVN trunk in configure.ac to disable the GtkHTML2 rendering module on x86_64 platforms. I'd suggest to drop the package for all 64bit platforms (if this is possible at all). Lars -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#361376: liferea still segfaults on amd64
Am Dienstag, den 23.01.2007, 23:41 +0100 schrieb Kurt Roeckx: found 1.0.26-1 thanks On Tue, Jan 23, 2007 at 11:14:54PM +0100, Lars Lindner wrote: Am Dienstag, den 23.01.2007, 22:39 +0100 schrieb Kurt Roeckx: On Tue, Jan 23, 2007 at 07:39:30PM +0100, Josselin Mouette wrote: reopen 361376 found 361376 1.0.27-1 found 361376 1.1.7c-1 thanks I'm still experiencing lots of segfaults with liferea-gtkhtml on amd64, and not on i386. It happens with both the unstable and the experimental version. Hi, You marked it as segfaulting in unstable and experimental. Does it also affect the version in testing (1.0.26-1)? No chance it is the same over all version. It is just unusable. So I'm tagging this as found in 1.0.26-1 too. I added a check in SVN trunk in configure.ac to disable the GtkHTML2 rendering module on x86_64 platforms. I'd suggest to drop the package for all 64bit platforms (if this is possible at all). If you want to drop support for 64 bit arches, this would be more than just amd64/x86_64. This would include atleast alpha and ia64 too. The reports I get upstream are all AMD64 related. I had somewhat good experiences on SPARC but cannot guarantee it to be stable on other 64bit platforms. Also the XHTML rendering in GtkHTML2 is somewhat ugly (spacings that cannot be avoided...) and so I think it is better not to use it. Anyway, you'll need to stop building the liferea-gtkhtml binary package on 64 bit arches, and then ask ftp-master to remove the binary packages on those arches. The good news seems to be that only liferea itself is making use of liferea-gtkhtml, so it shouldn't be that hard to get rid of it. Yes, liferea-gtkhtml missing won't hurt anyone. Lars -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#405432: Does not save state on Shut Down
Am Mittwoch, den 03.01.2007, 16:16 +0100 schrieb Matt Kraai: Package: liferea Version: 1.0.27-1 When I mark a read item as unread in Liferea and then shut down my computer, Liferea sometimes fails to have the item marked as unread. When I boot the system and start Liferea, the item is marked as read. Liferea 1.0.x has no SIGTERM handling. Therefore if you terminate it without using the session manager (e.g. a clean shutdown using GNOMEs gdm/KDEs kdm/xdm...) it won't save all state changes. This should be fixed in 1.2.x. Lars -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#320466: Warning messages from synaptic
Hi I experience the same problem with synaptic 0.57.11. It always reports this critical warning but works without problems otherwise: # synaptic (synaptic:1291): Gtk-CRITICAL **: gtk_tree_view_unref_tree_helper: assertion `node != NULL' failed # The question is wether this problem is really critical and if it should be exposed to the user. Lars -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#391112: liferea 1.1.6 packaging
Am Sonntag, den 15.10.2006, 22:14 -0500 schrieb Luis Rodrigo Gallardo Cruz: Package: liferea Followup-For: Bug #391112 I've done a first attempt. It was mostly a matter of adding build-depends. It seems to work propperly (as much as one can expect for a development version, anyways). Are you available for sponsoring? I do have a regular sponsor in case you're not. In any event, I won't try to do this upload until I try the package for a couple days. I attach the diff, in case you (or anyone else) wants to take a look. I suggest to upload 1.1.5 instead of 1.1.6 which has a annoying bug when unselecting feeds which are displayed in 2 pane mode. 1.1.7 (which will take some more days) will of course fix the problem. Lars -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#386331: Activate StartupNotify
Am Mittwoch, den 06.09.2006, 22:07 +0200 schrieb Frederic Peters: Package: liferea Version: 1.0.18-1 Severity: normal When switching desktop after liferea has been launched from its GNOME menu item, liferea will not appear on the initial desktop but on the current desktop. This is fixed by setting StartupNotify to true in its .desktop file, could this change be applied to Debian package ? No this must not be changed. Setting StartupNotify might appear to be working but it doesn't because an application must implement the startup notification protocol for it to work properly. And Liferea doesn't. Lars -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#378075: liferea: Bogus URL escaping affects slashdot links
I believe this to be fixed with the latest upstream releases (1.0.21 and 1.1.0). Lars -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#372763: liferea: Add support for StartupNotify in launcher
Am Freitag, den 21.07.2006, 05:05 +0200 schrieb Franz Pletz: severity 372763 wishlist thanks On Sun, Jun 11, 2006 at 08:17:25PM +0200, Lars Lindner wrote: On 6/11/06, Sven Arvidsson [EMAIL PROTECTED] wrote: Can you please add support for StartupNotify in the launcher for Liferea? Just adding the line StartupNotify=true to the .desktop file will activate the busy cursor during startup. This is especially important for slower systems to make the desktop experience seem more responsive. Sounds reasonable. I'll add this upstream. I noticed that this bug wasn't fixed in the latest upstream release. What are we going to do about it? ;) I should have explained that. Sorry. I applied the fix and later reverted it when I learned that it would be a bad thing to do. Just changing the StartupNotify= parameter seems to work, but is not correct according to the specification. An application who sets it to true must also implement a protocol to signalize the end of the startup. This is not given (or planned) for Liferea. I'd say won't fix. Lars -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#379003: Support for caching the full article associated with a headline.
Am Freitag, den 21.07.2006, 06:39 -0700 schrieb Daniel Burrows: On Fri, Jul 21, 2006 at 01:01:56PM +0200, Lars Lindner [EMAIL PROTECTED] was heard to say: On 7/21/06, Daniel Burrows [EMAIL PROTECTED] wrote: On Thu, Jul 20, 2006 at 06:44:02PM +0200, Lars Lindner [EMAIL PROTECTED] was heard to say: On 7/20/06, Daniel Burrows [EMAIL PROTECTED] wrote: Package: liferea Severity: wishlist A lot of RSS feeds seem to just be a blurb with a link to the full article (in a link tag, if I'm reading the XML correctly). Since I mostly use liferea for reading blogs while I'm disconnected from the Internet, it would be nice if it had the ability to cache the full article and associated images as well. How would you retrieve this missing information. The publisher of the feed explicitely does not deliver the content and will have no interest that a feed reader can easily collect the information from the website itself. Liferea has a feature to use external programs/scripts as a feed source. Writing a website scraping script is the only solution for this problem. I cannot be done automatically. Um, there's a link tag with that URL in the RSS feed. Here's a headling from the feed for the Beeb, for instance (with the formatting cleaned up): The link itself is rendered when displaying the item. Following the link and retrieving the relevant information from the website behind and presenting it without all website structure, layout and advertisments is not possible. But if you mean that Liferea should just load the link inside the HTML pane, so that you automatically surf the website the item link points to, that would be something that it is worth to consider to implement. But currently not planned. Saving the file at that link and viewing it in a Web browser works just fine, although obviously I lose embedded images if I'm not online. So, although I feel a bit silly having to make this point, it's clearly possible to download all the files associated with the Web page; and even just blindly downloading the file behind the link gets you most of the way there. It is possible. But I see no use case. The publisher clearly does not want you not to see the contents of the headline without going to his website. And also Liferea pre-downloading web content would make it an offline browser. But it is a feed reader and presents feed contents per definition. There are also technical reasons not to pre-download websites. First the space needed to do so, if such websites are single HTML pages. As soon as CSS or frames are used they will become useless without recursive downloads. Even when ignoring multi media contents. Further how long would such a webpage be valid, the online page might update regularily. Next how to integrate the content into the item view. How to signalize the user that this content is offline. And how to allow changing the display mode to online. And how to follow links. I don't want to say that those problems cannot be solved. But one can clearly see the additional complexity of such a simple request. Realizing complex features also mean setting a default way of using the program which won't suite many people, so such a feature would need a lot of consideration. The stated project goal is still a _simple_ news aggregator. Therefore: won't fix. PS: looks like I lost the BTS; sorry about that. Feel free to bounce my replies back there. No problem. Lars -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#378645: liferea: Random (?) Crash
Am Freitag, den 21.07.2006, 10:45 -0400 schrieb Carlos Moffat: On Tue, 2006-07-18 at 10:04 +0200, Lars Lindner wrote: Am Montag, den 17.07.2006, 20:06 -0400 schrieb Carlos Moffat: Package: liferea Version: 1.0.12-1 Severity: normal Hi, From time to time, liferea would crash. I can't really tell what exactly is going on, but this is what I got from gdb: [Thread -1323992144 (LWP 9802) exited] [Thread -1315599440 (LWP 9803) exited] [New Thread -1315599440 (LWP 10330)] [Thread -1315599440 (LWP 10330) exited] [New Thread -1315599440 (LWP 10536)] [New Thread -1323992144 (LWP 10537)] [New Thread -1307206736 (LWP 10538)] [Thread -1323992144 (LWP 10537) exited] [Thread -1315599440 (LWP 10536) exited] [Thread -1307206736 (LWP 10538) exited] Program received signal SIGSEGV, Segmentation fault. [Switching to Thread -1265087568 (LWP 28907)] 0xb75c4532 in strcat () from /lib/tls/i686/cmov/libc.so.6 and the backtrace: #0 0xb75c4532 in strcat () from /lib/tls/i686/cmov/libc.so.6 #1 0x0809d61f in NetIO () #2 0x0809e37a in DownloadFeed () #3 0x0809e529 in downloadlib_process_url () #4 0x0809aafb in download_process () #5 0x0809af0f in download_init () #6 0xb76e45df in g_thread_create_full () from /usr/lib/libglib-2.0.so.0 #7 0xb7694e60 in start_thread () from /lib/tls/i686/cmov/libpthread.so.0 #8 0xb76288ee in clone () from /lib/tls/i686/cmov/libc.so.6 Let me know if I can provide any other information. Often such such rare crashes are caused by the update of a specific feed where the network client has a bug or encounters some webserver incompatibility. So if you would run like this liferea --debug-update trace and send the last 50 lines of output ones it crashes again... Thanks Lars Ok, thanks for that. The problem seem to be a 'dead' feed I had in my list. Since I deleted the last feed (file attached), no crashes. Thanks for this debug output! I could not reproduce a crash, but using valgrind I found some bad memory access in the favicon image loading. I assume the crash was caused by the favicon image loading trying to read a returned advertisement website as an image. I added a content type check in the favicon image loading that avoids that mistake. I think this also solves the crash. The fix will be released soon. Lars -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#379003: Support for caching the full article associated with a headline.
On 7/20/06, Daniel Burrows [EMAIL PROTECTED] wrote: Package: liferea Severity: wishlist A lot of RSS feeds seem to just be a blurb with a link to the full article (in a link tag, if I'm reading the XML correctly). Since I mostly use liferea for reading blogs while I'm disconnected from the Internet, it would be nice if it had the ability to cache the full article and associated images as well. How would you retrieve this missing information. The publisher of the feed explicitely does not deliver the content and will have no interest that a feed reader can easily collect the information from the website itself. Liferea has a feature to use external programs/scripts as a feed source. Writing a website scraping script is the only solution for this problem. I cannot be done automatically. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#378645: liferea: Random (?) Crash
Am Montag, den 17.07.2006, 20:06 -0400 schrieb Carlos Moffat: Package: liferea Version: 1.0.12-1 Severity: normal Hi, From time to time, liferea would crash. I can't really tell what exactly is going on, but this is what I got from gdb: [Thread -1323992144 (LWP 9802) exited] [Thread -1315599440 (LWP 9803) exited] [New Thread -1315599440 (LWP 10330)] [Thread -1315599440 (LWP 10330) exited] [New Thread -1315599440 (LWP 10536)] [New Thread -1323992144 (LWP 10537)] [New Thread -1307206736 (LWP 10538)] [Thread -1323992144 (LWP 10537) exited] [Thread -1315599440 (LWP 10536) exited] [Thread -1307206736 (LWP 10538) exited] Program received signal SIGSEGV, Segmentation fault. [Switching to Thread -1265087568 (LWP 28907)] 0xb75c4532 in strcat () from /lib/tls/i686/cmov/libc.so.6 and the backtrace: #0 0xb75c4532 in strcat () from /lib/tls/i686/cmov/libc.so.6 #1 0x0809d61f in NetIO () #2 0x0809e37a in DownloadFeed () #3 0x0809e529 in downloadlib_process_url () #4 0x0809aafb in download_process () #5 0x0809af0f in download_init () #6 0xb76e45df in g_thread_create_full () from /usr/lib/libglib-2.0.so.0 #7 0xb7694e60 in start_thread () from /lib/tls/i686/cmov/libpthread.so.0 #8 0xb76288ee in clone () from /lib/tls/i686/cmov/libc.so.6 Let me know if I can provide any other information. Often such such rare crashes are caused by the update of a specific feed where the network client has a bug or encounters some webserver incompatibility. So if you would run like this liferea --debug-update trace and send the last 50 lines of output ones it crashes again... Thanks Lars -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#378075: liferea: Bogus URL escaping affects slashdot links
Am Mittwoch, den 12.07.2006, 23:09 -0400 schrieb Daniel Jacobowitz: Package: liferea Version: 1.0.12-1 Severity: normal Clicking on links from the Slashdot RSS feed (the Item: links) no longer works. I think this worked a few days ago, but I haven't upgraded liferea since, and I verified with one of the Slashdot support staff that the links in their feed appear to be correct. Here's the link from the slashdot RSS feed at http://rss.slashdot.org/slashdot/eqWf: link http://rss.slashdot.org/~r/slashdot/eqWf/~3/http%3A%2F%2Fgames.slashdot.org%2Farticle.pl%3Fsid%3D06%2F07%2F12%2F193225%26from%3Drss /link Here's the link from Liferea's cache file: sourcehttp://rss.slashdot.org/~r/slashdot/eqWf/~3/http%3A%2F%2Fgames.slashdot.org%2Farticle.pl%3Fsid%3D06%2F07%2F12%2F193225%26from%3Drss/source But when I click on it, the link has the %xx escapes already decoded. It tries to go to an http link containing the literal string http://;. This doesn't work. I'm using the gtkhtml2 plugin, if that matters. Upstream release 1.0.17 fixes this problem. Please note that it does not fix all cases. Relative links with escaped strings still won't work in GtkHTML2. The problem won't fix completely, but I assume it will work for most feeds. For feeds with relative URIs and escaped strings I suggest to use Gecko rendering as a workaround. Lars -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#329867: liferea: --mainwindow-state=hidden broken
Am Samstag, den 15.07.2006, 14:36 -0400 schrieb Stephen Touset:
Package: liferea
Version: 1.0.12-1
Followup-For: Bug #329867
This would be great if --mainwindow-state=hidden actually did anything.
I've got the notification area applet running, and Liferea is configured
to close to it. However, running it with
--mainwindow-state={hidden,iconified,*} seems to do absolutely nothing.
Running it with various levels of debugging verbosity doesn't even
indicate that it's looking at this parameter.
Please note that upstream 1.0.14 fixed a bug of this command line
parameter. Should work with newer versions.
Lars
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#378075: liferea: Bogus URL escaping affects slashdot links
Am Mittwoch, den 12.07.2006, 23:09 -0400 schrieb Daniel Jacobowitz: Package: liferea Version: 1.0.12-1 Severity: normal Clicking on links from the Slashdot RSS feed (the Item: links) no longer works. I think this worked a few days ago, but I haven't upgraded liferea since, and I verified with one of the Slashdot support staff that the links in their feed appear to be correct. Here's the link from the slashdot RSS feed at http://rss.slashdot.org/slashdot/eqWf: link http://rss.slashdot.org/~r/slashdot/eqWf/~3/http%3A%2F%2Fgames.slashdot.org%2Farticle.pl%3Fsid%3D06%2F07%2F12%2F193225%26from%3Drss /link Here's the link from Liferea's cache file: sourcehttp://rss.slashdot.org/~r/slashdot/eqWf/~3/http%3A%2F%2Fgames.slashdot.org%2Farticle.pl%3Fsid%3D06%2F07%2F12%2F193225%26from%3Drss/source But when I click on it, the link has the %xx escapes already decoded. It tries to go to an http link containing the literal string http://;. This doesn't work. I'm using the gtkhtml2 plugin, if that matters. I can reproduce it. Seems to happens since /. did the redesign. Lars -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#376849: liferea: leaks memory
Am Mittwoch, den 05.07.2006, 09:08 -0400 schrieb Daniel Jacobowitz: Package: liferea Version: 1.0.12-1 Severity: normal I'm using liferea with gtkhtml2. Something involved is leaking memory horribly: PID USER PR NI VIRT RES SHR S %CPU %MEMTIME+ COMMAND 7773 drow 15 0 781m 285m 7464 S0 14.2 3:49.29 liferea-bin That particular copy has been running for about three weeks. At a clean start it only uses: 7866 drow 20 5 133m 40m 8536 S0 2.0 0:01.31 liferea-bin Not very much, in comparison. But after reading a couple of messages and updating a few feeds, it's gone up to 142m/42m or so. Upstream 1.0.16 fixed a significant memory leak. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#374428: liferea: sessions stopped working
Am Montag, den 19.06.2006, 13:31 +0200 schrieb Håvard Moen: Package: liferea Version: 1.0.12-1 Severity: normal Xsession support seems to have stopped working in liferea. I usually use xsm as my session manager, and liferea is no longer listed in the 'Client List'. I also tried gnome-session, but when starting liferea it was not registered there either. Is the Debian package still compiled with session management? Please run with --debug-gui and look for output like this: GUI: Session Management: No SESSION_MANAGER found, aborting. Lars -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#374428: liferea: sessions stopped working
Am Montag, den 19.06.2006, 22:17 +0200 schrieb Håvard Moen: On Mon, Jun 19, 2006 at 21:32:59 +0200, Lars Lindner wrote: Am Montag, den 19.06.2006, 13:31 +0200 schrieb Håvard Moen: Package: liferea Version: 1.0.12-1 Severity: normal Xsession support seems to have stopped working in liferea. I usually use xsm as my session manager, and liferea is no longer listed in the 'Client List'. I also tried gnome-session, but when starting liferea it was not registered there either. Is the Debian package still compiled with session management? If not, why? The session management code is optional code. So it is the maintainers decision wether to include it or not. Please run with --debug-gui and look for output like this: GUI: Session Management: No SESSION_MANAGER found, aborting. [EMAIL PROTECTED]:~$ liferea --debug-gui Neither Mozilla nor Firefox is available... GUI: Available browser modules (/usr/lib/liferea): GUI: - GtkHTML2 (liblihtmlg.so) GUI: Loading configured browser module (liblihtmlg.so)! GUI: Registering with DBUS... GUI: Setting threePane mode: off GUI: Setting threePane mode: off No Session Management: output is an indication that the version you use was compiled without SM support. Lars -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#374530: liferea: outputs Unhandled property: 12 border-collapse on selecting any post
Am Montag, den 19.06.2006, 21:25 +0100 schrieb Jonathan McDowell: Package: liferea Version: 1.0.12-1 Severity: wishlist Every time I select a post in liferea it outputs: Unhandled property: 12 border-collapse to the xterm it was started in. There's no reason it should do this; it's a GUI app and if it has something to say it should output it in a dialog box and otherwise it should be quiet. Thanks for deciding to post a bug :-) I think this is a problem with libgtkhtml2 which outputs every unknown CSS tag it encounters. And Liferea relies on the border-collapse attribute to correctly render items with Mozilla. Lars -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#372733: liferea: Liferea launches *two* copies of dbus on start; they never exit.
On 6/11/06, Joshua Rodman [EMAIL PROTECTED] wrote: Package: liferea Followup-For: Bug #364084 Version: 1.0.10-1 X-Spam-Status: No, hits=-1.4 required=4.0 tests=BAYES_00,NO_REAL_NAME autolearn=no version=2.60-bugs.debian.org_2005_01_02 *** Please type your report below this line *** The liferea launch script contains the following text: if [ -z $DBUS_SESSION_BUS_ADDRESS ]; then eval `dbus-launch` export DBUS_SESSION_BUS_ADDRESS fi [...] echo 'Neither Mozilla nor Firefox is available...' eval `dbus-launch` export DBUS_SESSION_BUS_ADDRESS exec $dist_bin/liferea-bin $params Leaving aside that firefox is installed _and_ that I have configured liferea not to use the mozilla renderer, nor mozilla/firefox as an external browser (making this message unnecessary and bothersome), this results in dbus-launch being run twice. Further, in some manner I do not quite understand, the dbus sessions last forever and do not exit on liferea exit. The next run of liferea adds two more dbus-daemon processes to the pile. I removed the confusing output from the starter script upstream. Isn't really necessary and often lying. What's meant is of course that there is no rendering library support by any installed Mozilla-based browser. The double dbus_launch is a problem of the Debian package. I don't know of a problem with dbus-daemon running after program termination. Are you sure that the last Liferea instance is really gone. No hanging liferea-bin processes? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#372763: liferea: Add support for StartupNotify in launcher
On 6/11/06, Sven Arvidsson [EMAIL PROTECTED] wrote: Package: liferea Version: 1.0.12-1 Severity: minor Can you please add support for StartupNotify in the launcher for Liferea? Just adding the line StartupNotify=true to the .desktop file will activate the busy cursor during startup. This is especially important for slower systems to make the desktop experience seem more responsive. Sounds reasonable. I'll add this upstream. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
