=== dantalizing_ is now known as dantalizing === doko_ is now known as doko [08:05] good morning [10:40] asac: So I'm looking at dropping the nss/nspr deps when moz's version is >= 1.8 in tinymail; checking for existing usage, it seems nss / nspr is used in "libtinymail-camel" conditionally; it looks like the API is used directly [10:41] asac: If HAVE_NSS is set, some structures get PRFileDesc members or things like this [10:41] asac: I don't quite see how this should be pulled over xpcom; do you think this is improper use? [10:42] asac: Hmm nevermind, I see nspr.h is in /usr/include/xulrunner-1.9b1/unstable/nspr.h [10:43] asac: Still not sure this should be enabled or not [10:54] asac: Argh, and MOZILLA_HOME isn't found; I don't see it in libxul-embedding-1.9.pc (tinymail uses libdir, but I see no alternative to that in the .pc either) [11:07] lool: we will eventually migrate to use system nspr/nss [11:08] asac: Ok, it's quite easy with the AC_ARG_WITH() flags I added [11:08] lool: you should test for either mozilla-nspr-1.9 or nspr [11:09] -1.9 will be dropped soon too [11:09] (the versioning) [11:09] lool: how do they use MOZILLA_HOME? [11:12] asac: for gtk_moz_embed_set_path() [11:13] Which seems related to libxul-embedding to me [11:13] asac: It seems to build without nspr/nss .pc files (unless it's dragged by libxul-embedding-1.9's requires or something) [11:14] lool: gtk_moz_embed_set_path is done in glue initialization code now ... so no need for MOZILLA_HOME for you [11:17] asac: Cool, thanks [11:19] widgets/.libs/libmodest-widgets.a(modest-mozembed-msg-view.o): In function `set_message': [11:19] /home/lool/scratch/modest/modest-1.0/src/widgets/modest-mozembed-msg-view.cpp:673: undefined reference to `modest_tny_msg_find_body_part(_TnyMsg*, int)' [11:19] Cool, I think I get the errors StevenK was getting now [11:19] :) [11:21] That'd be them [11:21] Any help gratefully received [11:24] StevenK: It's a circular dep between src/ and src/widgets I'm afraid [11:25] lool: so is the nss/nspr issue mentioned in mail now resolved? [11:25] src/widgets/modest-mozembed-msg-view.cpp uses modest_tny_msg_find_body_part() which is in src/modest-tny-msg.c and src/Makefile.am asks to link modest against widgets/libmodest-widgets.la [11:26] asac: Well theoritically I don't use nss/nspr modules as I pass --with-mozilla-nss-pc=no, but technically there are many refs to nss/nspr and I didn't review them al [11:26] all [11:27] asac: It looks like some extensive work to properly review and cleanup the whole tree to me :-/ [11:28] Eh modest is Copyright (c) 2006, Nokia Corporation [11:29] lool: you can use nspr [11:29] and nss [11:29] asac: You think I should if it builds withoutN [11:29] ? [11:30] right ... its better to not do that, but if its needed it should be possible :) [11:30] asac: Sure; for now it seems it builds without, it's trivial to add the b-deps and pass the proper --with if necessary [11:30] StevenK: dpatch updated for tinymail BTW (pub/~lool) [11:30] err p.u.c/~lool [11:32] StevenK: So looking at it, it's no fun: 32 widgets sources, not an option to move, src/modest-tny-msg.c depends on -folder and -text-utils which probably depend on other stuff => might be movable, and modest itself is clearly not movable [11:33] StevenK: about helix, do you think there is any development work we need to do about it, or is it just getting the integration working? [11:33] StevenK: I'm trying to make up my mind wrt minispecs/a full spec for it. [11:37] lool: Don't bother with moving, I just want it to compile. [11:38] Mithrandir: Um. If I could remember the mail that said what needed to be done for helix [11:38] StevenK: Moving is usually the long term way to fix circular deps across automake dirs AFAIK [11:40] Blah SVN modest needs SVN libwp [11:40] Right === dholbach_ is now known as dholbach [11:41] lool: I saw your mail about tinymail, let's see what Philip says [11:42] StevenK: Can you confirm where the libwpeditor SVN is? [11:42] ATM I'm guessing in garage along modest [11:42] https://garage.maemo.org/svn/modest/libwpeditor-plus/trunk [11:43] Ok, that's what I found as well, thanks [11:45] wp_text_buffer_replace_image isn't even in libwp SVN, sigh [11:48] And source is missing at repository.maemo.org, cool [11:50] Right. I commented that bit out [11:54] I'll write the Nokia guy who wrote the change that he didn't update libwp [11:56] lool, StevenK, welcome to the wonderfull world of maemo repos hell :) [11:56] Haha [11:59] agoliveira: Hehe [11:59] lool: i think mozilla_xpcom_includetype needs to be empty when $mozilla_xpcom version is < 1.9 [12:00] lool: what about the GLUE patch? [12:01] asac: That one I wanted to think more about it and rework, it's a bit ugly ATM [12:01] asac: You mean the one in configure.ac, right? [12:01] asac: I'd like the flags to be pulled cleanly :-/ [12:02] no the one in code ... mozembed_init [12:02] or something like that [12:02] but the one in configure.ac needs to be fixed as well [12:02] #ifdef XPCOM_GLUE should be clean enough imo [12:04] asac: Oh yeah, also a separate fix, but didn't send it yet indeed [12:04] ah ok [12:04] asac: You want to send it? [12:04] I didn't have to change it in anyway since your version [12:06] haha the Nokia guy is running gutsy :) [12:06] He commits his debian/changelog with +modest (1.0-maemo21) gutsy; urgency=low [12:06] makes sense to use gutsy ;) [12:06] Jan-Dirk or somebody else? [12:07] Yeah, this guy [12:07] Right [12:09] Another mail sent for the second error [12:09] modest-mozembed-msg-view.c:49:40: error: widgets/modest-scroll-area.h: No such file or directory [12:09] And then modest-mozembed-msg-view.c:373: warning: implicit declaration of function 'modest_scroll_area_new' [12:09] lool: imo the trunk branch is broken [12:09] and obvious failure after that [12:09] i ran into the same issues [12:09] but could build with gnomeui [12:09] asac: You had to build tinymail with gnome-desktop stuff though, right? [12:10] It really looks like modest is in constant flux and quite rough in SVN [12:10] hmm ... no idea ... the gnomeui was just a joke :) ... no functionality, mostly dialogs saying "Hello" opened when activating some menu/button [12:10] asac: ah :-( [12:11] why do you want trunk= [12:11] ? [12:12] In file included from ../../src/widgets/modest-mozembed-mime-part-view.h:40, from modest-mozembed-msg-view.c:48: [12:12] /usr/include/libtinymailui-mozembed-1.0/tny-moz-embed-html-mime-part-view.h:28:25: error: gtkmozembed.h: No such file or directory [12:12] asac: Why search for bugs which might be fixed in trunk or for which the fixes might not apply to trunk? [12:12] I usually try reproducing stuff with trunk/head, if I do I fix it there, then backport downstream [12:13] Pff the -I flags when building tinymail take two xterm screens, it's ridiculous [12:13] I think half of our problems with modest are because of xul embedding requiring that evil evil hack of .c -> .cpp [12:14] asac: Ah, I have an issue for you here [12:14] MODEST_MOZEMBED_CFLAGS ends up with -I/usr/include/xulrunner-1.9b1/stable [12:14] It should be unstable [12:15] So I guess libtinymail should be setting includetype? [12:15] The thing is that pkg-config var are in a common namespace, so it's a bit ugly to set includetype in tinymail's .pc [12:15] yes [12:16] he? [12:16] Would it make sense to rename includetype to libxul-embedding-includetype? [12:16] lool: that would need to be done upstream [12:16] asac: That's what I was suggesting :) [12:17] asac: Unlikely to ever happen? [12:17] well ... i will ask :) [12:17] It's a concrete example: a lib exposing it's gtkmozembed implementation needs to set this var [12:17] asac: Cool, thanks :) [12:17] but he isn't awake yet ... so later [12:18] I need to get some food before 2pm & [12:24] agoliveira: I'm pondering renaming mobile-applications to mobile-core-applications and make mobile-applications the full set of apps from the SoW, using the minispec idea. Thoughts on that? [12:25] Mithrandir: I guess it's ok. [12:25] Mithrandir: and actually makes sense if we want to consider the whole lot of applications. [13:32] Mithrandir: Do you know whether a .pc can define vars to be used in another one? [13:32] lool: I don't believe that is supported, no. [13:32] Mithrandir: Like libtinymailui-mozembed-1.0 would set includetype=unstable so that the require would use it [13:32] Mithrandir: Ok, thanks [13:32] ship two .pc files. [13:32] Mithrandir: Exactly what I was about to write to asac :) [13:32] asac: ^ [13:33] asac: Would be nice to have libxul-embedding-unstable and libxul-unstable [13:33] asac: Because I can't set the var in libtinymailui-mozembed-1.0, I tried it's not honoured [13:33] to me, it looks like the mozilla people are trying to bend pkg-config to do something it's not designed to do (and which it isn't easily extended to do) [13:34] Mithrandir: Eh, it's Mozilla! :-P [13:34] pkg-config can do it ... the macros can't though :) ... which doesn't make much a difference [13:34] ... i will ask if they accept a patch for -unstable :) [13:35] oh ... misread. nm [13:39] lool: http://pastebin.mozilla.org/255146 ... appears to use unstable [13:39] asac: Yes, but not if I put it in libtinymailui-mozembed-1.0.pc [13:39] asac: But it's of course fine if I set it on the command line [13:39] what do you mean? i run pkg-config on libtinymailui-mozembed-1.0 in that paste [13:39] asac: It's just unpractical to change all PKG_CHECK_MODULES() in other packages into $PKG_CONFIG calls [13:39] ah [13:40] ok [13:40] It kind of defeats the pkg-config concept :-/ [13:40] well but why is it inherited when using --define-variable ... but not if you define the variable in the .pc file itself? [13:40] sounds like a bug as well [13:40] if anything, it should be something like Requires: libxul-embedding-1.9 [includetype=unstable] in the .pc file [13:41] asac: no, that's not a bug. There's nothing which implies that a .pc has a way of reaching out of its own scope. [13:43] yes right. bad thought :) [13:57] Ok, passed one more failure in modest SVN, now at modest-mozembed-msg-view.c:385: warning: implicit declaration of function 'gtk_widget_tap_and_hold_setup' [14:00] lool: its a #define gtk_widget_tap_and_hold_setup(a,b,c,d) [14:00] and might be excluded because of #ifndef MODEST_HAVE_HILDON_GTK [14:01] * asac out for lunch [14:01] lool: that one we need to patch around, since we don't have tap-and-hold yet. [14:03] Mithrandir: Yup, i'm adding an ac_check_decl in modest [14:03] asac: good lunch [14:04] asac: I think I prefer changing their #ifdef maemo_chages which is set for some reason to a more specific check [14:14] Cool, fails to link now [14:15] Damn modest [14:20] Hmm if a C file calls gtk_moz_embed_find_text(), I do need to link to -lxul, no? === cprov is now known as cprov-lunch [14:38] lool: no [14:41] lool: well ... i can't tell for sure, epiphany, devhelp, yelp ... all use typeaheadfind not the mozembed function [14:42] but i would guess that its provided by gtkmozembed_glue.cpp [15:16] smagoun: Heya, around? [15:16] smagoun: I read about your freetype1 changes, but couldn't see the difference between your package in the ppa and the one in hardy (apart of the build-conflicts); is this fixed in hardy? [15:16] lool: hi [15:17] lool: I think it's fixed in hardy, yup. [15:17] smagoun: You told me it was [15:17] I didn't see any sign of a fix for gutsy, even though it was clearly broken - hence the upload to the PPA [15:17] StevenK: The bug (let me find it...) mentioned a Hardy fix [15:19] smagoun: Ok, everything is fine then [15:19] smagoun: I just wanted to make sure that it was fixed in hardy, I couldn't see any difference between hardy and ppa build-deps, so it's fine [15:20] Here's the bug: https://bugs.edge.launchpad.net/ubuntu/+source/freetype1/+bug/135663 [15:20] Launchpad bug 135663 in acton "FTBFS: wrong build-dependency on libkpathsea4-dev" [Undecided,Fix committed] [15:20] Ah yes, I remember that one [15:20] Anyway, I'm going to bed, since it's 2:20 [15:20] StevenK: 'night [15:20] Night [15:21] Is there a way to see all packages that failed to build for gutsy/LPIA? We've run into this problem a couple times now. [15:21] It'd be nice to know what else is broken [15:21] launchpad.net/ubuntu/gutsy/lpia/+builds [15:22] 485 build failures. Hmm. [15:22] Enjoy :-P [15:22] Presumably some were superseded by working builds? [15:22] Right [15:22] ugh [15:22] Hence the enjoy. :-P [15:22] Anyway, night [15:23] smagoun: Better to fix them when you need to ;) [15:23] smagoun: Ok, thanks for the bug id [15:23] lool: The problem is that we don't even know what's broken/out-of-date! [15:25] grep -v kde isn't a valid input to the package filter on that page....bummer [15:25] smagoun: Ah you want to compare the lpia versions with the i386 versions? [15:25] lool: yeah [15:25] smagoun: You can script that over the Packages file easily [15:26] grep-dctrl provides tools to extract any field you like out of the files, but even awk should be enough I guess [15:26] no kidding. I'll have to take a look, I didn't know about grep-dctrl [15:26] * smagoun is allergic to awk [15:27] Thanks! [15:29] Try perl! [15:29] :) [15:29] Actually sort / uniq would be enough :) === cprov-lunch is now known as cprov [16:32] asac: Do I understand correctly that it should be libtinymailui-mozembed-1.0 which should #include gtkmozembed_glue.cpp? [16:34] Hmm no that's currently fine [16:38] asac: If I #include just before gtkmozembed.h, just like in the yelp example in the wiki, I get a /usr/include/xulrunner-1.9b1/unstable/nscore.h:117:1: error: "NS_HIDDEN" redefined [16:41] Oh it's actually a problem with gtkmozembed_glue.cpp alone, the two includes are from gtkmozembed_glue.cpp [16:52] lool: you have to compile with g++ ... are you doing that? [16:52] lool: otherwise you have wrong CFLAGS [16:52] asac: Ah no [16:52] asac: Is there a solution to build with gcc? [16:53] (repeated: in the end the zooming should encapsulated in libtinymailui-mozembed) [16:53] asac: Or do you have pointers to build with g++? [16:53] lool: just rename the file extension of the .c file that now includes the .cpp file to [16:53] asac: I don't understand your last sentence [16:53] .cpp [16:53] "repeated: ..." => what do you mean? [16:54] lool: libtinymailui-mozembed implements the whole gecko business :) [16:54] now modest people hacked because they wanted zoom [16:54] Oh you mean modest should do gecko directly? [16:54] no ... it shouldn't ... but it currently does :) [16:54] Ok [17:16] asac: Hmm I renamed the .c file including tny-moz-embed to .cpp, finally got g++ to build it, but it fails in the same way [17:16] Ah, it's not the same file I think, sorry [17:33] asac: I'm giving up, can I hand you the ball? [17:34] whats happening now? [17:34] Same thing [17:34] Except I'm building with g++ [17:34] is -DXPCOM_GLUE defined? [17:34] It is [17:35] lool: did you include the _glue.cpp in two files? [17:35] I'll copy the last lines of build to you [17:35] asac: I did [17:35] lool: that won't work [17:35] lool: just once [17:35] it just exists to make the symbols available during linking [17:36] http://paste.debian.net/44079 [17:36] asac: Ah [17:36] gtkmozembed.h is enough for just the headers [17:37] asac: Looks better; *sigh* thanks a lot [17:37] asac: How shoud I pick the file where to include the cpp? [17:38] lool: usually the right place is to do it wherever the previous code intiialized gecko [17:38] asac: And am I supposed to rename all files including mozembed to cpp? [17:38] e.g. gtk_moz_embed_set_path [17:39] Should I protect with ifdef XPCOM_GLUE? [17:39] yes [17:39] Am I supposed to rename all files including mozembed.h to .cpp? [17:40] no ... I think just the file with the _glue.cpp [17:41] lool: anyway, if you want to hand it over, just open a xulrunner 1.9 bug to track this. and tell me the svn branch, the build-depends and the configure flags of modest and tinymail + whatever patches you already have :) [17:42] Ok, I will [17:42] asac: If I don't rename the other file, I get the error [17:42] Ah no wait, automake needs a distclean again grrr [17:43] autotools have been very painful when switching a file with the same name from C to CPP [17:43] yes :) ... run sh autogen.sh [17:43] It's not enough, I have to cleanup some dependency files manually [17:43] (To properly cleanup, I'd have to distclean before renaming) [17:44] oh right .. if you forgot to clean before you run into issues [17:45] lool: if you ask for help on xul 1.9 could you at least try if the modest trunk really works fine with 1.8? [17:45] asac: Ok [17:46] i just fear to work against something that doesn't work at all [17:47] asac: http://paste.debian.net/44080 [17:47] XPCOM_GLUE is defined; this only cpp fiel is where the init is supposed to happen, and it produces this despite the mozembed.cpp include [17:48] lool: isn't that just a warning? [17:48] asac: It is, shall I ignore that? [17:48] yes [17:48] thats fine [17:49] Wow, I've been fighting such warnings most of this afternoon thinking these were the issue [17:49] (well fine is something else, but i never had issues because of that) [17:49] oh sorry ... i thought the paste before was an error: [17:50] asac: It was, but I also got warnings oh well [19:59] Wouah SVN built after the last error I fixed before dinner === cprov is now known as cprov-out === asac_ is now known as asac [20:32] StevenK: So, SVN builds for me now \o/ [20:33] StevenK: The circular dep must have been temporary and fixed upstream (would not be surprizing); I'm sending my patches upstream and I shall prepare an updated snapshot tomorrow, with the fixes [20:33] StevenK: How could I easily extract your changes to reapply them to the snapshot as to not lose any of them? [20:35] asac: Thanks for your help BTW, I think I was losing patience at the end of the day with the many Mozilla issues which are really me learning how to use their stuff properly [20:56] Wow, serious bug we have since a long while: Variable 'datarootdir' not defined in '/usr/lib/pkgconfig/osso-af-settings.pc' [20:59] Cool, saw my first modest window before it crashed \o/ === sabotage is now known as sabotage_afk