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