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