[00:06] <pochu> asac: hey, I thought you were a bug contact for xulrunner-1.9 :) could you have a look at bug 203413 when you have some time? thanks
[00:06] <ubotu> Launchpad bug 203413 in xulrunner-1.9 "Liferea creates many corrupt copies of places.sqlite in its Mozilla profile folder" [Undecided,Triaged] https://launchpad.net/bugs/203413
[00:06] <pochu> fta: thanks for triaging that :)
[00:07] <fta> you're welcome
[00:07] <fta> pochu, now the question is, is liferea doing the right thing?
[00:08] <fta> firefox 3 doesn't have this problem
[00:08] <pochu> well, define "right thing" :)
[00:09] <pochu> liferea hasn't changed it's database code for a long time (1.4.x series)
[00:20] <fta> well, i haven't looked at the liferea code in a long while so i don't know.
[00:21] <fta> all those .corrupt files are correct but for some reason, InitDB() fails
[00:25] <fta> I'll investigate tomorrow
[00:25] <pochu> thanks
[00:25] <pochu> I'm off, good night
[15:22] <fta> pochu, the liferea issue could be caused by sqlite3. it seems our system libsqlite 3.4.2 does not support GROUP_CONCAT() while mozilla ships 3.5.4.1
[15:23] <pochu> hmm, I think Liferea is supposed to work fine with 3.5.x
[15:23] <fta> I say "could" because I see liferea is linked with our system libsqlite while our xulrunner 1.9 has in source libsqlite so I don't know which is used
[15:24] <fta> but hardy has 3.4.* and I think it's a bit late to change that
[15:24] <pochu> at least it didn't work but was fixed
[15:24] <pochu>         * Fixing wrong deallocation that prevents Liferea
[15:24] <pochu>           from working with sqlite 3.5.x (SF #1811055).
[15:25] <pochu> yeah, I think so too
[15:25] <fta> !info sqlite3 sid
[15:25] <pochu> but Lifereaii  libsqlite3-0                               3.4.2-2                       SQLite 3 shared library
[15:26] <fta> !info sqlite3 experimental
[15:26] <pochu> but Liferea is linked against /usr/lib/libsqlite3.so.0
[15:26] <fta> i think 3.5 is in experimental
[15:26] <pochu>    sqlite3 |    3.5.7-1 | http://ftp.de.debian.org unstable/main Sources
[15:26] <pochu> in unstable
[15:28] <fta> would be nice to have...
[15:29] <pochu> but I don't think 3 weeks before the release is a good moment ;)
[15:32] <fta> maybe we can trick liferea to use /usr/lib/xulrunner-1.9b5/libsqlite3.so
[15:34] <fta> er.. how come /usr/lib/xulrunner-devel-1.9b4/lib is hardcoded in /usr/bin/liferea ??? this is wrong
[15:37] <pochu> fta: from src/liferea.in
[15:37] <fta> yes but it is plain wrong
[15:37] <pochu> oh, right, it works
[15:37] <pochu> it was needed for 1.8
[15:37] <fta> 1st, it depends in xulrunner -dev and 2nd, this path will change with each version
[15:38] <pochu> I can't get the 1st point
[15:39] <fta> /usr/lib/xulrunner-devel-1.9b4   -devel- is the sdk so the -dev package, it will never be installed by users
[15:39] <pochu> err, when I said it was needed with 1.8, I meant with firefox-dev (gecko 1.8)
[15:43] <pochu> we could remove /usr/bin/liferea and symlink it to /usr/bin/liferea-bin as a workaround
[15:47] <fta> ? how will it improve the situation ?
[15:48] <pochu> because we don't need to set LD_LIBRARY_PATH anymore
[15:48] <pochu> and thus we can launch /usr/bin/liferea-bin directly
[15:49] <fta> there's the dbus thing
[15:49] <pochu> ouch, right
[15:50] <pochu> we can patch liferea.in then
[15:50] <fta> the problem is liferea is linked with libsqlite3.so.0 and moz provides libsqlite3.so
[15:51] <fta> so it's not easy to trick
[15:53] <slomo__> the dbus thing is not necessary anymore
[15:53] <slomo__> dbus will autospawn a session bus if none is there
[15:55] <fta> oh, good
[15:55] <pochu> for the sqlite issue, perhaps we could extend configure.in so that you can pass SQLITE_LIBS (or --with-sqlite=/PATH )
[16:00] <fta> but moz does not provide the headers so it won't work
[16:00] <fta> i'll think more about it later
[16:01] <pochu> fta: /usr/include/xulrunner-1.9b4/unstable/sqlite3.h
[16:01] <pochu> isn't that what we need?
[16:01] <pochu> src/db.c:#include <sqlite3.h>
[16:05] <fta> yes.
[16:06] <fta> maybe we can just drop the sqlite tests completely and rely on xulrunner sdk for that then.
[16:08] <slomo__> scary
[16:09] <slomo__> xul just shouldn't bundle it
[16:09] <slomo__> and link against the system one
[16:09] <slomo__> asac: ^--- :)
[16:11] <fta> we can't
[16:11] <fta> unless we add sqlite 3.5.* to hardy
[16:12] <fta> asac is aware of that too
[16:12] <pochu> $ apt-cache rdepends libsqlite3-0 | wc -l
[16:12] <pochu> 109
[16:13] <fta> i've added the detection code for sqlite 3.5 in xulrunner a while ago but in hardy, it falls back to in-source
[16:15] <slomo__> well, it brings this kind of problems so it should be done
[16:16] <fta> you mean sqlite 3.5 in hardy ?
[16:18] <slomo__> or some other way to link to the system sqlite
[16:19] <fta> reverting xul ?
[16:19] <fta> waoo
[16:20] <pochu> can't it use 3.4?
[16:22] <fta> no, unles we revert all the 'places' changes that make what ff3 is today
[16:23] <fta> bookmarks, toolbars, tags, history, etc.
[16:25] <fta> debian faced that too
[16:25] <fta> http://glandium.org/blog/?p=183
[16:30] <fta> pochu, well, I let you see with asac, i've done enough for this bug already.
[16:30] <pochu> thanks a bunch for your work so far
[17:44] <asac> pochu: we should like against sqlite in xuldir
[17:45] <asac> and startup with proper LD_LIBRARY_PATH
[17:45] <asac> done
[17:45] <asac> not perfect, but should work
[17:48] <fta> that was my proposal above
[17:48] <fta> but slomo__ doesn't seem to like it
[17:49] <asac> well... i don't like it either, but its an efficient and pragmatical solution
[17:49] <slomo__> no, i'm allergic against packages bundlign stuff ;)
[17:49] <asac> yeah ... but in this case ubuntu is outdated :)
[17:49] <slomo__> what's the problem with updating sqlite in hardy? seems to work fine without any problems so far in debian
[17:49] <pochu> well, ideally xulrunner should link against the system sqlite...
[17:49] <asac> and injecting a new sqlite is risky
[17:49] <pochu> but if we can't do that, then let's workaround this bug
[17:50] <pochu> right, and that means more work for the security team if there's a security bug
[17:50] <asac> pochu: i am talking about pragmatical solutions. i am aware about what the ideal solution would look like :)
[17:50] <pochu> asac: and I agree with the solution :)
[17:50] <pochu> as I think it's too late for including sqlite 3.5
[17:50] <asac> pochu: given that all the security work is on my behalf its not more load on the security team
[17:51] <asac> and mozilla will probably release a firefox update if sqlite has issues anyway ... so we roll a release in that case.
[17:51] <asac> which makes that argument void
[17:51] <pochu> unless we include it as different packages, and link both Xul and Liferea to it
[17:51] <asac> the real argument is that it sucks ;)
[17:51] <pochu> asac: oh, right
[17:51] <asac> hehe
[17:51] <asac> i think we should try this and see how far we get. if we fail we can consider to package sqlite3.5
[17:52] <pochu> but I'm fine with it as long as it fixes the bug (and doesn't introduce more regressions)
[17:52] <pochu> asac: ok, I use it on an hourly basis so I'll keep you updated if something breaks ;)
[17:53] <asac> yeah... the corrupted files are not that bad on their own ... but it means that other parts of gecko are probably broken in liferea as well :) ... so good that we found this
[17:54] <pochu> what I'm worried is whether this could affect other applications using both xulrunner 1.9 and sqlite
[17:57] <pochu> well that case doesn't seem to exists, except for liferea :)
[17:57] <pochu> (in the archive, of course)
[18:01] <reynaldo_> 4/quit