Liferea creates many corrupt copies of places.sqlite in its Mozilla profile folder

[Grey Nicholson]

Binary package hint: liferea

Liferea 1.4.12-0ubuntu2 on Hardy creates many corrupt copies of places.sqlite in its Mozilla profile folder.

These appear as ~/.liferea_1.4/mozilla/liferea/places.sqlite.corrupt ; ~/.liferea_1.4/mozilla/liferea/places.sqlite-1.corrupt ; ~/.liferea_1.4/mozilla/liferea/places.sqlite-2.corrupt etc.

Each is ~ 100 kB in size; several hundred can accumulate over a couple of days. Obviously, this is a waste of disc space and probably processor power.

I'm not sure what exactly causes each copy to be created: simply loading a new item in Liferea just now produced 6 more copies; loading another produced 2.

[Dietrich-mozilla (dietrich-mozilla)]

morphing to describe the actual fix, and because it'll fix all searches using the places query system, not just the Library.

[Erwan (erwan)]

If we do that at the query level, let's make sure that in the Library "copy" will still copy an encoded URL. Just like the URL bar (show decoded but copy encoded).

Decoded URLs are not properly handled in any software that involve analyzing text to detect URLs (IRC Clients, Bugzilla...)

[Edilee-mozilla (edilee-mozilla)]

Created an attachment (id=305229)
v1

This fixes P1 bug 415460 and P3 bug 415397 for new URLs that the user visits or bookmarks.

With this patch, you can search for "ぽ" in the Library and find urls that match. The locations listed in the Library are also correctly unencoded. (However, the editBookmarks dialog at the bottom still shows encoded.)

URLs can still be searched and are decoded in the location bar autocomplete.

For new URLs that are visited, they can be consistently deleted (for bug 415397). Before, the user would visit say.. http://site/%40 and later select the url from the autocomplete and visit http://site/@ causing 2 entries. With the patch, the DB will always keep track of http://site/@.

[Edilee-mozilla (edilee-mozilla)]

FYI, still passes Erwan's unit test that landed for bug 407973 (originally for bug 413784).

[Shawn Wilsher (sdwilsh)]

ug - I was working on this bug right now. I'll attach a test I wrote...

[Shawn Wilsher (sdwilsh)]

Created an attachment (id=305233)
test

[Dietrich-mozilla (dietrich-mozilla)]

(From update of attachment 305229)
shawn, can you do first-r please?

[Shawn Wilsher (sdwilsh)]

(From update of attachment 305229)
>+ nsCAutoString charset;
>+ rv = aURI->GetOriginCharset(charset);
>+ NS_ENSURE_SUCCESS(rv, rv);
This could be empty - in which case it's assumed to be UTF-8

>+ nsAutoString uriSpec;
>+ (void)textToSubURI->UnEscapeURIForUI(charset, utf8URISpec, uriSpec);
So, I don't particularly like this because of
* escaping back the result (unescaped string) is not guaranteed to give the original escaped string
I don't think that that is how we want to store the information at least.
I think that calling unEscapeNonAsciiURI and maybe UnEscapeAndConvert (not necessarily in that order) would be better here.

>+ rv = statement->BindStringParameter(index,
>+ StringHead(uriSpec, HISTORY_URI_LENGTH_MAX));
I know you didn't change this, but I don't understand why we need StringHead...

I do believe that if we are changing how we store information in the database that we also need to migrate existing data. This is an interesting use case because technically we aren't changing any of the schema...

Also a test showing that this works with a database that already has this stuff in it would be good.

[Edilee-mozilla (edilee-mozilla)]

(In reply to comment #8)
> (From update of attachment 305229 [details])
> >+ nsCAutoString charset;
> >+ rv = aURI->GetOriginCharset(charset);
> >+ NS_ENSURE_SUCCESS(rv, rv);
> This could be empty - in which case it's assumed to be UTF-8
>
> >+ nsAutoString uriSpec;
> >+ (void)textToSubURI->UnEscapeURIForUI(charset, utf8URISpec, uriSpec);
> So, I don't particularly like this because of
> * escaping back the result (unescaped string) is not guaranteed to give the
> original escaped string
> I don't think that that is how we want to store the information at least.
> I think that calling unEscapeNonAsciiURI and maybe UnEscapeAndConvert (not
> necessarily in that order) would be better here.
>
> >+ rv = statement->BindStringParameter(index,
> >+ StringHead(uriSpec, HISTORY_URI_LENGTH_MAX));
> I know you didn't change this, but I don't understand why we need StringHead...
>
> I do believe that if we are changing how we store information in the database
> that we also need to migrate existing data. This is an interesting use case
> because technically we aren't changing any of the schema...
>
> Also a test showing that this works with a database that already has this stuff
> in it would be good.
>

[Edilee-mozilla (edilee-mozilla)]

You can continue working on it Shawn. I'll just keep unbitrotting stuff.

[Shawn Wilsher (sdwilsh)]

Feel free to take it - the scope is larger than I originally intended, and I don't know if I have the cycles for it before b4.

[Edilee-mozilla (edilee-mozilla)]

Created an attachment (id=305310)
v1.1

(In reply to comment #8)
> >+ rv = aURI->GetOriginCharset(charset);
> This could be empty - in which case it's assumed to be UTF-8
Ok. Defaulted to "UTF-8" if empty.

> >+ (void)textToSubURI->UnEscapeURIForUI(charset, utf8URISpec, uriSpec);
> * escaping back the result (unescaped string) is not guaranteed to give the
> original escaped string
E.g., escape(unescape("hi there")) -> hi%20there
But that's fine because we're showing this to the user which s/he could have typed in without us unescaping.

> >+ StringHead(uriSpec, HISTORY_URI_LENGTH_MAX));
See bug 319004.

> I do believe that if we are changing how we store information in the database
> that we also need to migrate existing data.
Added migration code and migration testcase. This should also fix bug 391691.

[Shawn Wilsher (sdwilsh)]

(From update of attachment 305310)
>+ for (PRInt32 i = urisToUnescape.Count(); --i >= 0; ) {
ug that's a confusing loop

>+ rv = fixURI->BindUTF8StringParameter(0, *urisToUnescape[i]);
>+ NS_ENSURE_SUCCESS(rv, rv);
>+
>+ (void)textToSubURI->UnEscapeURIForUI(charset, *urisToUnescape[i], uriSpec);
>+
>+ rv = fixURI->BindStringParameter(1, uriSpec);
>+ NS_ENSURE_SUCCESS(rv, rv);
>+
>+ rv = fixURI->Execute();
>+ NS_ENSURE_SUCCESS(rv, rv);
I think it'd probably be best here to do
if (NS_FAILED(rv)) continue;

r=sdwilsh for what it's worth

[Edilee-mozilla (edilee-mozilla)]

Created an attachment (id=305418)
v1.2

(In reply to comment #13)
> r=sdwilsh for what it's worth
>
> >+ rv = fixURI->BindUTF8StringParameter(0, *urisToUnescape[i]);
> >+ NS_ENSURE_SUCCESS(rv, rv);
> >+
> >+ (void)textToSubURI->UnEscapeURIForUI(charset, *urisToUnescape[i], uriSpec);
> >+
> >+ rv = fixURI->BindStringParameter(1, uriSpec);
> >+ NS_ENSURE_SUCCESS(rv, rv);
> >+
> >+ rv = fixURI->Execute();
> >+ NS_ENSURE_SUCCESS(rv, rv);
> I think it'd probably be best here to do
> if (NS_FAILED(rv)) continue;
Switched both loops to use NS_SUCCEEDED then append string or NS_SUCCEEDED for both binding and then execute.

Additionally, changed the BindStatementURI to if (NS_FAILED() || empty) use UTF8.

[Edilee-mozilla (edilee-mozilla)]

(From update of attachment 305418)
>+ while (NS_SUCCEEDED(getURIs->ExecuteStep(&hasMore)) && hasMore) {
>+ if (NS_SUCCEEDED(getURIs->GetUTF8String(0, utf8URISpec)))
>+ urisToUnescape.AppendCString(utf8URISpec);
>+ }
Oh, I got rid of the braces for the while {}.

[Edilee-mozilla (edilee-mozilla)]

Created an attachment (id=305440)
v1.3

Added unescaping for live/incremental bookmark updates and updated the testcase to check for it. See bug 419324 commment 3.

[Edilee-mozilla (edilee-mozilla)]

(From update of attachment 305440)
Mmm.. I'm not quite liking the patch anymore. There's several consumers that are expecting strings to be passed around as nsIURI.spec strings or just nsIURIs. E.g., nsNavHistory::IsVisited(nsIURI *aURI, PRBool *_retval).

We should try to keep that invariant. Strings are passed around as nsIURI.spec nsACString UTF8 Strings. Only when they're displayed show them with UnEscapeURIForUI.

[Mano-mozilla (mano-mozilla)]

Any reason we shouldn't just do it in the view?

[Edilee-mozilla (edilee-mozilla)]

Created an attachment (id=305699)
v2

This also bug 419366. Basically, I do the same thing I did for autocomplete multi-word out-of-order search.

[Edilee-mozilla (edilee-mozilla)]

Created an attachment (id=305702)
v2.1

Readded shawn's testcase.

[Dietrich-mozilla (dietrich-mozilla)]

(From update of attachment 305702)

>-
>- if (!allTermsFound && !URIHasAnyTagFromTerms(aSet[nodeIndex]->mURI, tagTerms))
>- continue;
>+ // Load up the title, url, tags for the current node as UTF16 strings
>+ NS_ConvertUTF8toUTF16 nodeTitle(aSet[nodeIndex]->mTitle);
>+ // Unescape the URL for search term matching
>+ nsCAutoString cNodeURL(aSet[nodeIndex]->mURI);
>+ NS_ConvertUTF8toUTF16 nodeURL(NS_UnescapeURL(cNodeURL));
>+ // Fetch the tags
>+ nsAutoString nodeTags;
>+ rv = aSet[nodeIndex]->GetTags(nodeTags);

no conversion needed?

also, iirc the direct db access in URIHasTag was originally due to poor performance of the tag service (not to mention level xpconnect traversals), and i believe GetTags() does exactly that.

please test, and if this is still a problem, maybe we should instead have GetTags() use URIHasTag()?

>+ NS_ENSURE_SUCCESS(rv, rv);
>+
>+ // Determine if every search term matches anywhere in the title, url, tag
>+ PRBool matchAll = PR_TRUE;
>+ for (PRInt32 termIndex = terms[queryIndex]->Count(); --termIndex >= 0 &&
>+ matchAll; ) {

nit: weird indent, please line up with parens contents

[Edilee-mozilla (edilee-mozilla)]

Created an attachment (id=305830)
v2.2

(In reply to comment #21)
> also, iirc the direct db access in URIHasTag was originally due to poor
> performance of the tag service (not to mention level xpconnect traversals), and
> i believe GetTags() does exactly that.
Yeah, turns out it was pretty slow.. 100+ms instead of the 10-15ms from before this patch. (I timed the start to end time of FilterResultSet.)

So instead, I use a separate query to get the tags strings back to do out-of-order multi-word matching. Now it's going at 9-12ms for queries.

> >+ for (PRInt32 termIndex = terms[queryIndex]->Count(); --termIndex >= 0 &&
> >+ matchAll; ) {
> nit: weird indent, please line up with parens contents
Shifted to under PRInt32.

[Edilee-mozilla (edilee-mozilla)]

Created an attachment (id=305934)
v2.3

Unbitrot changes from bug 385245.

[Dietrich-mozilla (dietrich-mozilla)]

(From update of attachment 305934)
thanks, r=me. can you please file a followup to fix nsNavHistoryResultNode.tags to use this?

[Edilee-mozilla (edilee-mozilla)]

Checking in toolkit/components/places/src/nsNavHistory.cpp;
/cvsroot/mozilla/toolkit/components/places/src/nsNavHistory.cpp,v <-- nsNavHistory.cpp
new revision: 1.264; previous revision: 1.263
done
Checking in toolkit/components/places/src/nsNavHistory.h;
/cvsroot/mozilla/toolkit/components/places/src/nsNavHistory.h,v <-- nsNavHistory.h
new revision: 1.145; previous revision: 1.144
done
RCS file: /cvsroot/mozilla/toolkit/components/places/tests/unit/test_415460.js,v
done
Checking in toolkit/components/places/tests/unit/test_415460.js;
/cvsroot/mozilla/toolkit/components/places/tests/unit/test_415460.js,v <-- test_415460.js
initial revision: 1.1
done

[Grey Nicholson (greytheearthling)]

Binary package hint: liferea

Liferea 1.4.12-0ubuntu2 on Hardy creates many corrupt copies of places.sqlite in its Mozilla profile folder.

These appear as ~/.liferea_1.4/mozilla/liferea/places.sqlite.corrupt ; ~/.liferea_1.4/mozilla/liferea/places.sqlite-1.corrupt ; ~/.liferea_1.4/mozilla/liferea/places.sqlite-2.corrupt etc.

Each is ~ 100 kB in size; several hundred can accumulate over a couple of days. Obviously, this is a waste of disc space and probably processor power.

I'm not sure what exactly causes each copy to be created: simply loading a new item in Liferea just now produced 6 more copies; loading another produced 2.

[Michael Kuhn (suraia)]

I can confirm this behavior.
I guess that this was caused by the recent upgrade of xulrunner-1.9.

[Lars Ljung (larslj)]

Me too, changing status to Confirmed.

[Emilio Pozuelo Monfort (pochu)]

Upstream has suggested to me this could be Xulrunner's fault. It doesn't have when using Xulrunner 1.8, but he said it could be a different thing, such as locking or threading issues, or even memory corruption...

Alexander, do you know whether this could be Xulrunner's fault? I could try downgrading to an older beta release of xul to see whether this was happening by that time.

[Fta+bugzilla (fta+bugzilla)]

liferea, built with xulrunner 1.9 is dumping tons of places.sqlite-\d+.corrupt files. Even with a fresh profile, all those ".corrupt" files appear at startup.
This is 100% reproducible. A dump shows they are not corrupted at all.

It's a regression introduced when bug 415460 landed, between b3 and b4, and it's still there in 1.9pre.

Those ".corrupt" files are created when InitDB() fails.
I've traced it down to mDBGetTags:

http://mxr.mozilla.org/mozilla/source/toolkit/components/places/src/nsNavHistory.cpp#1140

1140 // mDBGetTags
1141 rv = mDBConn->CreateStatement(NS_LITERAL_CSTRING(
1142 "SELECT GROUP_CONCAT(t.title, ' ') "
1143 "FROM moz_places h "
1144 "JOIN moz_bookmarks b ON b.type = ") +
1145 nsPrintfCString("%d", nsINavBookmarksService::TYPE_BOOKMARK) +
1146 NS_LITERAL_CSTRING(" AND b.fk = h.id "
1147 "JOIN moz_bookmarks t ON t.parent = ?1 AND t.id = b.parent "
1148 "WHERE h.url = ?2"),
1149 getter_AddRefs(mDBGetTags));
1150 NS_ENSURE_SUCCESS(rv, rv);

[Fabien Tassin (fta)]

Emilio, I've tracked it down to the patch that landed in xulrunner with this bug: http://bugzilla.mozilla.org/show_bug.cgi?id=415460

[Emilio Pozuelo Monfort (pochu)]

Great, thanks a lot Fabien.

I'm closing the Liferea task then.

[Fabien Tassin (fta)]

This is were the root cause is: http://mxr.mozilla.org/mozilla/source/toolkit/components/places/src/nsNavHistory.cpp#1140
I've filed a bug upstream: https://bugzilla.mozilla.org/show_bug.cgi?id=425993

[Bruce Cowan (bruce89-deactivatedaccount)]

Could this be the cause of Liferea using 100% of the CPU time?

[Emilio Pozuelo Monfort (pochu)]

Bruce Cowan wrote:
> Could this be the cause of Liferea using 100% of the CPU time?
>

Probably not, as I have many many .corrupt files and haven't noticed Liferea
killing my CPU.

Furthermore, that bug was first reported on 2008-02-11 but xulrunner 1.9 beta4
was uploaded on 2008-03-13

[Alexander Sack (asac)]

this turned out to be due to a lower versioned (system-)sqlite loaded by liferea. Though it reveals that the standalone glue approach is not perfect, I close this issue as invalid as I cannot imagine a pragmatic solution on xulrunner side.

We will work around on distro side.

[Alexander Sack (asac)]

this happens because of xulrunner shipping its own sqlite ... liferea links agianst the system sqlite whose version is too low to support all the features of places. This makes the statement state in the mozilla bug fail and finally create the corrupted things.

The xulrunner-1.9 task is still valid and should be interpreted as "use system sqlite", but liferea should work around this in hardy. reopeing liferea task and setting to triaged.

[Alexander Sack (asac)]

milestoning xulrunner-1.9 part as "later".

[Alexander Sack (asac)]

sqlite3 needs to be upgraded to >= 3.5

[Alexander Sack (asac)]

... but not in hardy.

[Fta+bugzilla (fta+bugzilla)]

To complement Alexander's comment, it happened to be GROUP_CONCAT() not supported by sqlite 3.4.
Our liferea was built with system sqlite (= 3.4.*) while our xulrunner was using in-source sqlite (= 3.5.*). At runtime, liferea uses 3.4.

Liferea doesn't have an Error console to report the assert so it was silently ignored. Moving the db to ".corrupt" is definitely wrong here, I would have preferred a real assert() with a reason.

Now that we know that it's this, we can indeed fix it on distro side.

[Alexander Sack (asac)]

ok, I'll upload the liferea side now. The fix will become effective once we uploaded next xulrunner.

[Alexander Sack (asac)]

here the debdiff that will go up for liferea:

diff -u liferea-1.4.14/debian/patches/xul1.9.dpatch liferea-1.4.14/debian/patches/xul1.9.dpatch
--- liferea-1.4.14/debian/patches/xul1.9.dpatch
+++ liferea-1.4.14/debian/patches/xul1.9.dpatch
@@ -5,10 +5,10 @@
 ## DP: implement configure option to choose --with-gecko=xulrunner-1.9

 @DPATCH@
-diff -urNad liferea-1.4.9~/configure liferea-1.4.9/configure
---- liferea-1.4.9~/configure 2007-12-12 20:32:43.000000000 +0100
-+++ liferea-1.4.9/configure 2007-12-12 20:37:30.000000000 +0100
-@@ -1616,7 +1616,7 @@
+diff -urNad liferea-1.4.14~/configure liferea-1.4.14/configure
+--- liferea-1.4.14~/configure 2008-03-12 00:43:44.000000000 +0100
++++ liferea-1.4.14/configure 2008-03-31 17:42:29.000000000 +0200
+@@ -1619,7 +1619,7 @@
    --disable-xulrunner don't compile the xulrunner backend
    --disable-gecko don't compile the Gecko backend
    --enable-gecko=ARG specify which Gecko provider to use ("mozilla",
@@ -17,7 +17,7 @@
    --enable-gnutls Attempt to use GNUTLS for SSL support [default=yes]
    --disable-libnotify don't compile the libnotify plugin
    --disable-lua don't compile with LUA scripting support
-@@ -24604,158 +24604,22 @@
+@@ -25119,158 +25119,22 @@

  if test "x$enable_gecko" = "xyes" -o "x$enable_gecko" = "xmozilla" ; then
     gecko_provider=mozilla
@@ -185,7 +185,7 @@

  pkg_failed=no
  { echo "$as_me:$LINENO: checking for MOZILLA" >&5
-@@ -24766,12 +24630,12 @@
+@@ -25281,12 +25145,12 @@
          pkg_cv_MOZILLA_CFLAGS="$MOZILLA_CFLAGS"
      else
          if test -n "$PKG_CONFIG" && \
@@ -201,7 +201,7 @@
  else
    pkg_failed=yes
  fi
-@@ -24784,12 +24648,12 @@
+@@ -25299,12 +25163,12 @@
          pkg_cv_MOZILLA_LIBS="$MOZILLA_LIBS"
      else
          if test -n "$PKG_CONFIG" && \
@@ -217,7 +217,7 @@
  else
    pkg_failed=yes
  fi
-@@ -24808,9 +24672,9 @@
+@@ -25323,9 +25187,9 @@
          _pkg_short_errors_supported=no
  fi
          if test $_pkg_short_errors_supported = yes; then
@@ -229,7 +229,7 @@
          fi
   # Put the nasty error message in config.log where it belongs
   echo "$MOZILLA_PKG_ERRORS" >&5
-@@ -24827,7 +24691,7 @@
+@@ -25342,7 +25206,7 @@
  echo "${ECHO_T}yes" >&6; }
   enable_mozilla=yes
  fi
@@ -238,7 +238,7 @@
  echo "${ECHO_T}$gecko_provider: $enable_mozilla" >&6; }
  fi

-@@ -25313,9 +25177,9 @@
+@@ -25828,9 +25692,9 @@

@@ -250,9 +250,9 @@

        MOZILLA_CFLAGS="$MOZILLA_CFLAGS \
  -I$MOZILLA_INCLUDE_ROOT \
-diff -urNad liferea-1.4.9~/configure.ac liferea-1.4.9/configure.ac
---- liferea-1.4.9~/configure.ac 2007-12-12 20:32:43.000000000 +0100
-+++ liferea-1.4.9/configure.ac 2007-12-12 20:37:25.000000000 +0100
+diff -urNad liferea-1.4.14~/configure.ac liferea-1.4.14/configure.ac
+--- liferea-1.4.14~/configure.ac 2008-02-29 00:45:05.000000000 +0100
++++ liferea-1.4.14/configure.ac 2008-03-31 17:42:29.000000000 +0200
 @@ -36,7 +36,7 @@
  AC_ARG_ENABLE(webkit, AS_HELP_STRING([--disable-webkit],[don't compile the webkit backend]),,enable_webkit=yes)
  AC_ARG_ENABLE(xulrunner, AS_HELP_STRING([--disable-xulrunner],[...

[Launchpad Janitor (janitor)]

This bug was fixed in the package liferea - 1.4.14-0ubuntu3

---------------
liferea (1.4.14-0ubuntu3) hardy; urgency=low

  * fix generation of corrupted places by setting up
    LD_LIBRARY_PATH properly (LP: #203413)
    - update debian/patches/xul1.9.dpatch

 -- Alexander Sack <email address hidden> Mon, 31 Mar 2008 17:41:42 +0200

[Artem Popov (artfwo)]

places.sqlite*corrupt still appear after updating to 1.4.14-0ubuntu3, and running liferea from the terminal shows the following:

art-devel@teaquetzl:~$ LANG=C liferea
ls: cannot access /usr/lib/xulrunner-1.9*/libsqlite3.so.0: No such file or directory
dirname: missing operand
Try `dirname --help' for more information.

[Jeff Fortin Tam (kiddo)]

indeed, this has not been solved with the latest updates yet

[Matti Lindell (mlind)]

Confirming that 1.4.14-0ubuntu3 is causing the following message in ~/.xsession-errors

ls: cannot access /usr/lib/xulrunner-1.9*/libsqlite3.so.0: No such file or directory
dirname: missing operand
Try `dirname --help' for more information.

[Matti Lindell (mlind)]

This is actually quite bad as I have over 500MB of orphaned .corrupt files which won't be automatically removed.

[Emilio Pozuelo Monfort (pochu)]

We need the new Xulrunner in order that this bug is fixed.

It will be uploaded in the following days (hopefully this week).

[Launchpad Janitor (janitor)]

This bug was fixed in the package xulrunner-1.9 - 1.9~b5+nobinonly-0ubuntu1

---------------
xulrunner-1.9 (1.9~b5+nobinonly-0ubuntu1) hardy; urgency=low

  [ Fabien Tassin <email address hidden> ]
  * Drop patch applied upstream
    - drop debian/patches/bz333308_attXXXX_make_clean_cleaner.patch
    - update debian/patches/series
  * Set LDFLAGS so dpkg-buildpackage doesn't use -Wl,-Bsymbolic-functions
    - update debian/rules
  * Add support for a defaults/syspref directory containing system wide
    preferences that will not be silently overwritten at each upgrade
    (LP: #207281, #203538).
    It works for both libxul apps such as firefox 3 and xulrunner
    applications such as prism
    - add debian/patches/add_syspref_dir.patch
    - update debian/patches/series
  * Fix broken RSS subscription
    - add debian/patches/bz423060_att312807_fix_rss_subscription.patch
    - update debian/patches/series
  * Bump depends to libnspr4-dev >= 4.7.1~beta2 and libnss3-dev >= 3.12.0~beta3
    - update update debian/control
  * Hook up mozilla-devscript's compare module to binary-post-install
    - update debian/rules

  [ Alexander Sack <email address hidden> ]
  * switch to in-source jpeg to fix rendering issues at zoom levels
    (LP: #182038); this measure should give us some performance
    improvements.
    - update debian/rules
  * make pref extensions read defaults/autoconfig from NS_GRE_DIR instead
    of NS_APP_DEFAULTS_50_DIR. If it turns out to be a bad decision, we should
    reconsider this patch.
    - add debian/patches/bzXXX_autoconfig_in_gre.patch
    - update debian/patches/series
  * install system-greprefs in /etc/xulrunner-1.9/ and create the proper
    link in $pkglibdir/greprefs to it (LP: #139543)
    - add debian/system-greprefs.js
    - update debian/rules
  * ship versioned link libsqlite3.so.0 => libsqlite3.so in $pkglibdir to
    allow liferea workaround for LP: #203413 - "Liferea creates many corrupt
    copies of places.sqlite in" by setting LD_LIBRARY_PATH properly
    - update debian/rules
  * ship .autoreg file in pkglibdir to allow autoreg touches by
    plugins/extensions et al.
    - update debian/rules
  * touch .autoreg in xulrunner-1.9.postinst and
    xulrunner-1.9-gnome-support.postinst
    - update debian/xulrunner-1.9.postinst
    - add debian/xulrunner-1.9-gnome-support.postinst
  * hook in lp-export-xpi.mk from mozilla-devscript to export en-US
    translation templates to debian/lp-export-xpis/; in turn, make
    mozilla-devscripts a hard build-depends
    - update debian/rules
    - update debian/control
  * consider NS_GRE_DIR/.autoreg to trigger component registry upgrades.
    - add debian/patches/bzXXX_gre_autoreg.patch
    - update debian/control/series
  * Fix "Dom Inspector not compatible" by bumping maxVersion field in
    extension install.rdf
    - add debian/patches/inspector_maxversion_bump.patch
    - update debian/patches/series
  * Fix xulrunner side for bug "firefox needs restart after plugin install to
    detect and activate them"; we scan for new plugins in GRE at startup runtime
    - update debian/patches/bzXXX_gre_extension_plugin_support.patch

 -- Fabien Tassin <email address hidden> ...

[Emilio Pozuelo Monfort (pochu)]

Looks fixed now, closing the Liferea task

[Emilio Pozuelo Monfort (pochu)]

Closing sqlite3 task

[Jonh Wendell (wendell)]

This issue came over again. I'm using hardy up-to-date.

Lots of corrupt files...

[Emilio Pozuelo Monfort (pochu)]

Jonh Wendell wrote:
> This issue came over again. I'm using hardy up-to-date.
>
> Lots of corrupt files...
>

I haven't had this since the update. It happens if you start Liferea from
/usr/bin/liferea-bin instead of /usr/bin/liferea (if you don't have the proper
LD_LIBRARY_PATH).

Did you by change started it that way, or changed LD_LIBRARY_PATH, or didn't use
the latest xulrunner-1.9 (which has the sqlite symlink) ?

[sam tygier (samtygier)]

is it safe to delete all the .corrupt files? should liferea (or something else) do this automatically

[Emilio Pozuelo Monfort (pochu)]

sam tygier wrote:
> is it safe to delete all the .corrupt files?

Yes. The Liferea database is in a different place (~/.liferea_1.4/liferea.db),
so you can safely remove them.

> should liferea (or
> something else) do this automatically

I don't think so. The problem is now fixed so only people launching liferea from
/usr/bin/liferea-bin will have this issue, but that's not the correct way to
launch it.

[sam tygier (samtygier)]

deleting them took my .liferea_1.4 from 837MB to 35MB

[Gervase Markham (gerv-mozilla)]

Bug 451915 - move Firefox/Places bugs to Firefox/Bookmarks and History. Remove all bugspam from this move by filtering for the string "places-to-b-and-h".

In Thunderbird 3.0b, you do that as follows:
Tools | Message Filters
Make sure the correct account is selected. Click "New"
Conditions: Body contains places-to-b-and-h
Change the action to "Delete Message".
Select "Manually Run" from the dropdown at the top.
Click OK.

Select the filter in the list, make sure "Inbox" is selected at the bottom, and click "Run Now". This should delete all the bugspam. You can then delete the filter.

Gerv