To reproduce, create a new feed subscription where the source is a command which does not produce an RSS or ATOM feed. Any common command should display the behavior, say, /bin/ls or /bin/false.
On Wed, Apr 22, 2015 at 1:40 PM, Marcelo Lacerda <marceloslace...@gmail.com> wrote: > I'm curious, how do I reproduce this bug? > > On Fri, Mar 6, 2015 at 8:55 PM, Daniel Perelman <da...@cornell.edu> wrote: > > Package: liferea > > Version: 1.10.12-1 > > Severity: wishlist > > > > Dear Maintainer, > > > > When feeds generated by a command fail to produce a working feed, the > > error messages are both misleading and useless. Pretty much no matter > > what the problem is, it outputs: > > > >> The last update of this subscription failed! > >> There were errors while parsing this feed! > >> > >> Details > >> > >> Could not detect the type of this feed! Please check if the source > >> really points to a resource provided in one of the supported > >> syndication formats! > >> > >> XML Parser Output: > >> > >> The URL you want Liferea to subscribe to points to a webpage > >> and the auto discovery found no feeds on this page. Maybe this > >> webpage just does not support feed auto discovery.Source points > >> to HTML document. > >> > >> You may want to contact the author/webmaster of the feed about > >> this! > > > > (Strangely, that error even sometimes included saying that it got an > > HTTP 404 which makes no sense for a local resource.) > > > > My understanding is that once Liferea fails to parse an input as a feed, > > it tries to parse it as a webpage that has a link to a feed and it only > > reports the error for the second failure, despite the first failure > > almost always being the relevant one. > > > > As a workaround, using the same command as a conversion filter (not > > caring what the input being "filtered" is) gives more useful errors. In > > case that led to this bug report, telling me that the command was > > returning an exit code of 1 (although actually seeing the error message > > in output would have been more helpful). > > > > This is a very minor issue because in addition to the workaround just > > mentioned, I suspect this is a rarely used feature and except in edge > > cases like the one I ran into (it turned out the script worked with my > > bash environment variables but not with my X session's), simply running > > the command from a terminal would give the desired debugging > > information. > > > > > > -- System Information: > > Debian Release: 8.0 > > APT prefers unstable > > APT policy: (500, 'unstable'), (500, 'testing') > > Architecture: amd64 (x86_64) > > Foreign Architectures: i386 > > > > Kernel: Linux 3.16.0-4-amd64 (SMP w/4 CPU cores) > > Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) > > Shell: /bin/sh linked to /bin/dash > > Init: systemd (via /run/systemd/system) > > > > Versions of packages liferea depends on: > > ii dbus-x11 1.8.16-1 > > ii dconf-gsettings-backend [gsettings-backend] 0.22.0-1 > > ii gir1.2-gtk-3.0 3.14.5-1 > > ii gir1.2-peas-1.0 1.12.1-2 > > ii libatk1.0-0 2.14.0-1 > > ii libc6 2.19-15 > > ii libcairo2 1.14.0-2.1 > > ii libgdk-pixbuf2.0-0 2.31.1-2+b1 > > ii libgirepository-1.0-1 1.42.0-2.2 > > ii libglib2.0-0 2.42.1-1 > > ii libgtk-3-0 3.14.5-1 > > ii libindicate5 0.6.92-2 > > ii libjson-glib-1.0-0 1.0.2-1 > > ii libnotify4 0.7.6-2 > > ii libpango-1.0-0 1.36.8-3 > > ii libpeas-1.0-0 1.12.1-2 > > ii libsoup2.4-1 2.48.0-1 > > ii libsqlite3-0 3.8.7.4-1 > > ii libwebkitgtk-3.0-0 2.4.8-1 > > ii libxml2 2.9.1+dfsg1-4 > > ii libxslt1.1 1.1.28-2+b2 > > ii liferea-data 1.10.12-1 > > ii python-gi 3.14.0-1 > > pn python:any <none> > > > > Versions of packages liferea recommends: > > pn gir1.2-gnomekeyring-1.0 <none> > > ii gnome-icon-theme 3.12.0-1 > > ii gnome-keyring 3.14.0-1+b1 > > ii steadyflow 0.2.0-1.1 > > > > Versions of packages liferea suggests: > > pn network-manager <none> > > > > -- no debconf information > > >
