[12:29] good. it worked [12:30] lol, bad email [12:31] please use your full name and a good email [12:31] so i can use that for credits et al [12:31] good now [12:31] it is [12:31] k [12:31] the "+" part is just a spam trap [12:31] so you want to b eknown as Fabien Tassin ? [12:32] well, more a triage part [12:32] well [12:32] so what is your email? [12:32] fta@ or what? [12:32] and don't you want your real email in credits? [12:32] anything fta@ or fta+.*@ [12:32] you can put that email [12:32] it works [12:32] yeah ... but do you really want to use that? [12:32] for credits? [12:33] i am fine with that but .... ;) [12:33] its launchpad in it :) [12:33] if I ever get spam to that adresse, I'll know it comes from LP or debs changelogs [12:33] which is useful info in which way? [12:34] I have hundreds of fta+xx so I eventually redirect to /dev/null when it's too heavily spamed without having to handle zillions of mailbox or change email every few weeks [12:34] I've been doing that for more than 10 years now [12:35] right so ftp+.... is probably not a good email to use as reference [12:35] why ? [12:35] it works just right. [12:35] well ... if people want to reach you through the email you use to maintain something they should be able to [12:35] try it :) [12:35] but if you pipe /dev/null its not a long term email [12:35] no [12:36] I'll probably never do that [12:36] so giving credits to patches needs a long term email imo ... in case somebody wants to get copyright permission or whatever [12:36] ok [12:38] I still receive tons of emails for CPAN perl modules I haven't touched in around 10 years [12:38] some are even in ubuntu :) [12:38] and debian [12:39] ans suse, redhat, solaris, mac os and who knows what else [12:39] enough of this, I have to commit the rest of it [12:44] asac: Hmm, I don't need the tabbrowser extensions for Firefox, since FF already has tabs, and stuff... Right? (Do I need it for Iceape?) [12:45] Jazzva: test it [12:45] maybe it gives you enhanced tabs for firefox [12:45] if its installable and works then we should add that extension as well [12:45] Yeah... I suppose... [12:46] What's Iceape? [12:47] I can't find the real package for it and both iceape and iceape-browser are metapackages... [12:48] Jazzva: he? [12:48] its in universe [12:48] iceape-browser is the browser package [12:48] not a meta one [12:48] I didn't say it right :)... I can't find the package info... iceape and iceape-browser... really? apt-cache show doesn't show anything [12:49] do you have universe in your sources.list? [12:49] or just main? [12:49] sure... [12:49] gutsy? [12:49] Feisty [12:49] its only in gutsy [12:49] well ... you should really setup a chroot and get the rdepends from there [12:49] we currently maintain this data for gutsy [12:50] what you see in feisty might be outdated [12:50] but most should still be the same [12:50] maybe a few new extensions [12:50] Ok, I'll check them later in chroot too :) [12:51] But I found about Iceape in extension description: "blabla for Iceweasel and Iceape", so I was wondering should I put "Blah extension for Firefox/Iceweasel/Iceape"? [12:51] yes at some point we might want iceape extensions as well [12:52] but it would just be addition of a new mime-type [12:52] so no new desktop file [12:52] unless its an iceape only extension of course [12:52] for now we want thunderbird+firefox [12:52] thats good enough [12:52] to begin with [12:53] Umm, ok... But I was wondering about the Name field. Should I put "Firefox/Iceweasel/Iceape" in Name field? Both Iceweasel and Iceape are mentioned in that extension description [12:55] asac, should be okay now. Did it in 3 commits [12:56] thanks [01:01] Ubulette: can't you usr/lib/firefox-granparadiso/firefox-granparadiso usr/bin/firefox-granparadiso ... create a link instead? [01:01] e.g. like it was before? [01:01] and install it to usr/lib/ for real? [01:02] it is [01:02] he? [01:02] then i misread [01:02] lrwxrwxrwx 1 root root 48 2007-08-08 23:26 /usr/bin/firefox-granparadiso -> ../lib/firefox-granparadiso/firefox-granparadiso [01:02] might be true ;) [01:02] did you use bzr mv ? [01:02] no [01:02] e.g. has the make_install patch history if yuo do bzr log on it [01:02] ok [01:03] bzr st [01:03] removed: [01:03] debian/patches/fix_make_install.patch [01:03] debian/patches/granparadiso-fsh [01:03] modified: [01:03] debian/firefox-granparadiso.install [01:03] debian/firefox-granparadiso.links [01:03] debian/patches/fix_toolkit_xre_install.patch [01:03] debian/patches/ftbfs-with-branding-dir [01:03] debian/patches/no-have-stdint-h-ftbfs.patch [01:03] debian/patches/series [01:03] unknown: [01:03] debian/patches/bz389673_fix_make_install.patch [01:03] debian/patches/granparadiso-appname [01:03] well you could bzr revert debian/patches/fix_make_install.patch [01:03] then [01:03] bzr mv debian/patches/fix_make_install.patch debian/patches/bz389673_fix_make_install.patch [01:03] then copy /tmp/bz389673_fix_make_install.patch debian/patches/bz389673_fix_make_install.patch [01:04] (which you backed up before) :) [01:04] anyway i can live without history for that file [01:04] after all it was broken i guess [01:04] I think so [01:05] have you verified that the modules are really just scripts that are platform indpendent? [01:05] hmm no [01:05] why is debian/patches/fix_toolkit_xre_install.patch modified in the diff? [01:05] ok its just a refresh ... but without much diff ;) [01:06] yep, sorry [01:06] quilt's fault [01:06] same for debian/patches/ftbfs-with-branding-dir [01:06] haha [01:06] review fault before commit i guess [01:07] anyway ... looks good ... cool. [01:07] many thanks [01:08] np [01:09] hmm [01:09] patch fails to apply [01:09] ? [01:09] fix make install patch fails [01:10] what kind of orig did you use? [01:10] interesting [01:10] the patch is empty here ;) [01:10] firefox-granparadiso_3.0~alpha7.orig.tar.gz containing just: [01:10] -rw-r--r-- bbot/bbot 35319889 2007-08-08 13:39 firefox-granparadiso-3.0~alpha7/granparadiso-alpha7-source.tar.bz2 [01:11] huh ... the patch is not there [01:11] what ? [01:11] its really missing [01:12] you forgot to add it :) [01:12] then maybe move while you are at it :) [01:12] sorry ... you need to explicitly add files to bzr ;) [01:12] unknown: [01:12] debian/patches/bz389673_fix_make_install.patch [01:12] debian/patches/granparadiso-appname [01:12] bzr add path/to/file [01:12] yeah [01:12] please uncommit [01:12] then mv the make install patch [01:12] and copy over the good/new one ;) [01:13] and add the granparadiso ... et al [01:13] sorry if i misread that above [01:13] is the bzr st what you are getting after commits? [01:14] before [01:14] ok ... yes do as above and we are happy ;) [01:14] or just add and commit ... your choice ;) [01:15] if you choose uncommit way you might want to revert the patches that are just timestamp refreshed as well [01:15] so they don't show up in diff [01:19] Woo :)... bzr+ssh works on Feisty :D... [01:19] Pushed new revisions in few seconds :D [01:22] BTW, how to run this in chroot? Log in, install gnome-app-install, then pull my branch, compile it and install it? [01:23] asac, [01:23] renamed: [01:23] debian/patches/fix_make_install.patch => debian/patches/bz389673_fix_make_install.patch [01:23] debian/patches/granparadiso-fsh => debian/patches/granparadiso-appname [01:23] modified: [01:23] debian/firefox-granparadiso.install [01:23] debian/firefox-granparadiso.links [01:23] debian/patches/series [01:23] debian/patches/bz389673_fix_make_install.patch [01:23] debian/patches/granparadiso-appname [01:26] looks good ... though i am unsure about fsh -> appname ... anyway ... this is getting close to religion so [01:26] go ahead ;) [01:31] done [01:40] thanks [01:41] does it apply now ? [01:41] its building now [01:41] so yes [01:41] lets see what comes next ;) [01:44] well, at least it worked on my side. I'm running it now, stable after ~2h [01:48] *sighs* pbuilder doesn't let me start X programs... Any link on how to setup a chroot that allows you that? [01:48] asac, Ubulette ^ [01:50] Jazzva: well [01:51] look in wiki.ubuntu.com [01:51] search for chroot ? [01:51] there should be instructions [01:51] Ok, I'll take a look... thanks :) [01:51] use schroot ... not dchroot [01:51] if you mount /proc and /tmp, that should do it [01:51] in case the wiki still refers to dchroot [01:52] Still refers to that... [01:53] google is your friend [01:53] http://danieldandrada.blogspot.com/2006/09/ubuntu-chroot-environments.html [01:53] Thanks, Ubulette :) === ubotu [n=ubotu@ubuntu/bot/ubotu] has joined #ubuntu-mozillateam [02:19] maybe we should ship a -dev package + sdk ? [02:20] i think i should get a xulrunner build done asap and see how to build paradiso against that ;) [02:21] well, I need ff-dev for some of my non-official packages. So far, it's messy [02:22] feel free to build xulrunner :) [02:22] packages are liferea, totem-mozilla, miro (ex democracy player), etc... [02:22] maybe just drop xulrunner snapshot in the firefox dir and see what happens [02:22] yes [02:23] isn't totem already prepared on trunk? [02:23] e.g. in terms of upstream configure.in ? [02:24] what kind of layout does totem assume for gecko 1.9 ? [02:25] let me see [02:26] checking whether to compile the browser plugins... autodetect [02:26] checking which gecko to use... firefox [02:26] checking for MOZILLA_NOT_LINKED... yes [02:26] checking for BROWSER_PLUGIN... yes [02:26] checking for DBUS... yes [02:26] checking for dbus-binding-tool... /usr/bin/dbus-binding-tool [02:26] checking for xpidl... /usr/lib/firefox/xpidl [02:26] checking for xpt_link... /usr/lib/firefox/xpt_link [02:26] checking for libxpcomglue_s... no [02:27] configure: WARNING: libxpcomglue_s not available; plugins may not be portable [02:27] please look in configure.in code [02:27] they test for 1.9 branch somehow [02:27] at least from what i remember [02:28] I need to tell my bot to fetch sources, I just preserve build logs [02:29] couple of sec.. [02:30] i am off ... its late :) [02:30] @time berlin [02:30] :) [02:30] ubotu: is asleep as well [02:30] night [02:30] lol [02:31] GECKOS="xulrunner firefox mozilla-firefox seamonkey mozilla" [02:31] case "$gecko" in [02:31] mozilla) MOZILLA_VERSION_MIN=1.7 ;; [02:31] seamonkey) MOZILLA_VERSION_MIN=1.0 ;; [02:31] *firefox) MOZILLA_VERSION_MIN=1.0 ;; [02:31] xulrunner) MOZILLA_VERSION_MIN=1.8 ;; [02:31] esac [02:35] btw, would be nice to support APNG with a7. I've been looking for that for a while :) [02:36] bug #122737 [02:44] night all === Admiral_Chicago [n=FreddyM@adsl-68-72-98-110.dsl.chcgil.ameritech.net] has joined #ubuntu-mozillateam [02:53] Current time in Europe/Berlin: August 09 2007, 02:53:47 - Next meeting: Ubuntu Development Team in 14 hours 6 minutes [02:54] Launchpad bug 122737 in firefox-granparadiso "No default search engines" [Undecided,Confirmed] https://launchpad.net/bugs/122737 === Admiral_laptop [n=Freddy@adsl-68-72-98-110.dsl.chcgil.ameritech.net] has joined #ubuntu-mozillateam === Admiral_laptop [n=Freddy@adsl-68-72-98-110.dsl.chcgil.ameritech.net] has joined #ubuntu-mozillateam [09:47] Ubulette: well we cannot *not* support apng :) [10:01] read: you cannot build trunk without apng anymore [11:05] Ubulette: ok i still experience some instabilities [11:05] with a7 [11:06] e.g. live-bookmarks are more or less broken ... and it crashes frequently === ubotu [n=ubotu@ubuntu/bot/ubotu] has joined #ubuntu-mozillateam [12:38] Morning :) [12:39] asac: I'm building the app-install-data in gutsy chroot... [12:41] Jazzva: morning [12:41] cool [01:01] asac: Hmm, doesn't seem to show up. Maybe I removed some important fireld from .desktop files. I'm gonna check it now and try to correct the .desktop files. [01:02] I think that I shouldn't remove the Type=Application and Categories=Application;... Field, since they're probably used to determine where to put the program/extension. [01:07] maybe [01:09] asac: It works :D... [01:09] Ok, I'm gonna correct all .desktop files I added and then push changes :) [01:09] Jazzva: thanks [01:09] asac: No prob... [01:36] asac: New revision is pushed :). [01:37] Jazzva: good [01:37] I suppose I could only fix categories for extensions later (for example, in my opinion mozilla-biofox (some bioinformatics thingie) should appear also in Education) [01:37] so lets wait for mime-types [01:37] (and Mime-types) [01:37] :) [01:41] Jazzva: application/x-debian-xul-extension-APPNAME [01:41] APPNAME=? Firefox or extension name? [01:42] firefox [01:43] no [01:43] just appname [01:43] And for thunderbird extension? [01:43] APPNAME=thunderbird [01:43] e.g. firefox extensions get: [01:43] application/x-debian-xul-extension-firefox [01:43] Ok, got it :) [01:43] thunderbird extensions get application/x-debian-xul-extension-thunderbird [01:43] And what if they're for both? [01:43] :) [01:43] and i think you start gnome-app-install with [01:44] --xul-extensions=firefox [01:44] get latest gnome-app-install from core-dev-branch [01:44] Ok [01:44] Umm, just that one question... What if the extension is both for firefox and thunderbird? [01:44] to just assign it to firefox? [01:44] *assign it just [01:45] no [01:45] add both mime-types [01:45] application/x-debian-xul-extension-firefox, application/x-debian-xul-extension-thunderbird [01:45] just play around a bit [01:46] K :) [01:46] ok lets use that for now ... later we might want to replace firefox with the application id [01:46] uuid [01:47] so it would work for compatible forks like iceweasel as well [01:47] but for now go what we discussed above [01:47] Ok... I'm on it... [01:47] ok please test gnome-app-install --xul-extensions=firefox with bazaar.launchpad.net/%7Eubuntu-core-dev/gnome-app-install/main/ [01:47] e.g. use that gnome-app-install branch [01:48] Sure :)... [01:48] have there been new extensions in gutsy? [01:48] did you take a look (be sure you have universe/multiverse/restricted in apt as well) [01:48] ? [01:49] Oh, I forgot about that... I'll take a look before adding mime-types then [01:49] that is, now :) [01:50] doesn't really matter ... we have to track if there are new extensions regularly anyways [01:50] so adding more later isn't a problem [01:50] of course having a complete list in the beginning is a good thing ;) [01:50] Sure :) [01:52] There are... also, some changed their names [01:53] I could just rename X-AppInstall-Package to new name, but I'll also rename .desktop and icon file, just to be easier to find later, if someone adds new corrections [01:54] maybe adjust desktop file name using 'bzr mv OLDFILE NEWFILE' [01:54] so we have in sync ones for initial release at least [01:54] bzr mv? [01:54] hmm ok :) [01:55] give it a try [01:55] better then rm + add [01:55] keeps history for the file [01:55] and even helps to merge changes if you have renamed files locally but another branch changes original filename [01:55] (though doesn't matter much for now) [01:55] Hmm, I wanted to do it with mv OLD NEW :) [01:55] But I'll give it a try :) [01:55] yeah use bzr mv [01:56] And if I make a typo or something, is there a "bzr unmv" or something? [01:58] Jazzva: just bzr revert [01:58] then bzr mv again [01:58] Ok :) === Ubulette [n=Ubulette@APuteaux-153-1-74-204.w81-249.abo.wanadoo.fr] has joined #ubuntu-mozillateam [02:37] asac: Should I include ubufox as extension? [02:38] hi [02:39] Hello Ubulette :) [02:40] Jazzva, how's your chroot ? [02:40] Pretty much good :)... [02:41] I managed to set it up, build app-install-data, install bzr, set my home dir... and stuff. :) [02:41] nice [02:42] Jazzva: yes [02:42] Ubulette: Much better than pbuilder :). Though, I'll keep pbuilder for checking deps. [02:42] asasc: Ok :). [02:44] asac: One notice about my a-i-d branch... As I added some MimeTypes I also noticed some typos, so I fixed them along. They're in the same commit, as they're not pretty big for a single commit... [02:45] Ubulette: well we cannot *not* support apng :) [02:45] read: you cannot build trunk without apng anymore [02:45] so what ? is there a #id open for libpng ? [02:51] Ubulette: no ... but your build should support apng [02:52] actually i don't know about the id for libpng [02:52] its known there, but they refuse to let the patch in [02:53] Jazzva: well typos should go to single commit [02:53] Jazzva: in this way you mix things [02:53] Jazzva: even one line change deserve its own commit if are tackling a distinct topic [02:53] asac: Ok... I will do that next time. [02:54] are the typos documente in commit log at least? [02:54] Yes :) [02:54] k [02:55] asac, right, it's okay: http://littlesvr.ca/apng/images/blend-1a.png [02:56] but I was refering to your comment [02:56] * debian/rules: drop --with-system-png configure option as [02:56] configure is now hard about the fact that we don't have apng [02:56] support in our system-png library; previously it just silently [02:56] used the in-source png, so now its more explicit - which is not [02:56] really bad. TODO: investigate if we want apng support in [02:56] system-png shipped by ubuntu. [03:08] yes [03:08] we don't use system png atm [03:08] most likely we will have to either add new lib: libapng [03:08] or patch png ... but the latter will not happen without upstream (png) following [03:09] ok [03:10] you said a7 still doesn't work for you ? [03:14] d'oh, 1st a7 crash [03:14] /usr/lib/firefox-granparadiso/firefox-granparadiso-bin: symbol lookup error: /usr/lib/totem/libtotem-gmp-plugin.so: undefined symbol: _ZN8nsMemory5CloneEPKvj [03:21] hm, that an xpcom issue [03:23] totem complains in configure [03:23] checking for libxpcomglue_s... no [03:23] configure: WARNING: libxpcomglue_s not available; plugins may not be portable [03:34] totem regression [04:11] well totem is broken of course [04:11] trunk now hides everything [04:11] so you need to compile against static glue [04:16] in the past, just adding -L/usr/lib/firefox -lxpcom fixed it [04:17] everything has changed [04:17] no shared libs anymore for you plugin implementros [04:17] :) [04:18] thank benjamin with his narrow minded view [04:18] note it's still using ff2 [04:18] he? [04:18] -L/usr/lib/firefox [04:18] ah [04:18] that is even worse [04:18] don't try to link against ff2 and run in ff3 [04:19] this is ubuntu's totem [04:19] and? [04:19] maybe see if latest upstream has gecko 1.9 configure.in [04:20] I'm don't know which FF users will be running [04:20] Idon't know which FF users will be running [04:20] yes of course not [04:20] either don't support ff3 then [04:20] or build twice: ff2 ... next run ff3 [04:20] e.g. independent plugins [04:20] of course totem build system has to support ff3 first [04:20] (and code as well) [04:21] I was assuming that FF3 will replace FF2 in a few months right ? [04:22] well ... not sure when [04:22] at some point it will [04:22] if you want to help getting totem prepared for that better start providing them soonish :) [04:22] maybe ask on #epiphany channel how well 1.9 support is working out [04:35] maybe see if latest upstream has gecko 1.9 configure.in [04:35] I'm running totem 2.19.6+svn20070809r4490 [04:36] in fact, I'm running all from HEAD [04:38] but doesn't work? [04:38] damn, /usr/lib/firefox-granparadiso/libxpcom.so is no longer exposing that symbol like /usr/lib/firefox/libxpcom.so [04:38] like i said [04:38] no shared libs for anyone [04:39] you have to link static glue [04:39] only [04:39] thats the only way its ment to work [04:39] its ment as a measure to prevent stupid folks from using shared libs [04:39] however, my opinion is that *this* is stupid [04:39] hmm, not sure what you mean as /usr/lib/firefox-granparadiso/libxpcom.so still exports: [04:39] undefined symbol: NS_CStringSetData (/usr/lib/totem/libtotem-gmp-plugin.so) [04:39] undefined symbol: NS_StringContainerFinish (/usr/lib/totem/libtotem-gmp-plugin.so) [04:39] undefined symbol: NS_Alloc (/usr/lib/totem/libtotem-gmp-plugin.so) [04:39] undefined symbol: NS_CStringCopy (/usr/lib/totem/libtotem-gmp-plugin.so) [04:39] undefined symbol: NS_CStringContainerInit (/usr/lib/totem/libtotem-gmp-plugin.so) [04:39] etc.. [04:40] just one is missing [04:40] undefined symbol: _ZN8nsMemory5CloneEPKvj (/usr/lib/totem/libtotem-gmp-plugin.so) [04:40] yes [04:40] but its in static glue [04:40] but I also need libxpcom.so [04:40] well ... you still can use shared libs right [04:40] but lot more has been hidden now [04:41] so I need libxpcomglue_s [04:41] yes [04:41] which is only available as static lib [04:41] Ubulette: iirc, you *just* should use that one [04:42] but i might be wrong about that [04:42] i think you have to link against -llibnspr4 and static glue [04:42] firefox-granparadiso-3.0~alpha7/build-tree/mozilla/dist/usr/lib/firefox-granparadiso-devel/sdk/lib/libxpcomglue_s.a [04:42] -lnspr4 obvioulsy [04:42] yes [04:42] that one ... which means we have to package the sdk [04:42] needs to go to -dev? [04:43] i think we will end up having firefox-granparadiso-headers == headers + idls [04:43] + firefox-granparadiso-sdk [04:43] or -sdk, right [04:43] maybe everything in one package right [04:43] but what should go in there and in which directory to place that is still open [04:44] further we should at least try to minimize transition pain [04:44] at best just require a respin [04:44] maybe the whole content of build-tree/mozilla/dist/sdk [04:44] anyway ... first and for most we have to understand the idea behind all this [04:45] its not so obvious because its somehow soaked with windowish attitude [04:45] Ubulette: well ... we should try to obey hierarchy standards [04:45] so headers should go to /usr/include/firefox-granparadiso [04:45] for instance [04:45] sdk has bin, lib, include and idl [04:46] yes ... we can install everything from sdk [04:46] and then add links to include et al [04:46] however ... the make install result of sdk is already linked ... so maybe it just works [04:46] try to just package up the -devel dir [04:46] maybe even keep the -devel name [04:47] so just one rule in -devel.install:: debian/tmp/usr/lib/firefox-granparadiso-devel-3.0a7 usr/lib/firefox-granparadiso-devel [04:47] and include dir as well [04:47] debian/tmp/usr/include .... if that exists [04:50] and tmp/usr/include/share [04:50] if that is all packaged we have to look whats going on with .pc files [04:50] honestly i would like to rather see xulrunner packaged than firefox-devel [04:50] e.g. xulrunner-trunk package [04:50] that ships sdk and xulrunner and all [04:50] then try to build firefox against that [04:50] and see whats left ;) [04:51] Ubulette: ^^^ [04:51] maybe think about it [04:54] will apps such as liferea and totem be able to link with xulrunner and still work ? (ie like totem-plugin withing ff2, ff3, mozilla) [04:54] -g [04:54] if ffox builds against xulrunner and we get those building then yes [04:55] hmm. someone needs to work on xul 1st :) [04:56] yeah [04:56] i will bootstrap it latest beginning next week [04:56] before I get a look at ff3 -dev again, you mentionned to see frequent crashes [04:56] s/to/you/ [04:56] well bookmarks on toolbar are broken [04:57] if i start ff2 with previously trunked profile, they are gone completely [04:57] ? [04:57] start trunk with ff2 profile [04:57] see that bookmarks in toolbar are somehow there, but somehow borken [04:58] then start with ff2 again and see that they are gone [04:58] ff3->ff2 is broken for sure, as this is now in .sqlite files [04:58] further on first start of trunk after ff2 usage it crashes on startup [04:58] and it will always crash on shutdown [04:58] and there's that "preplaces" stuff [04:59] ok have meeting now bbl [05:13] asac: The application/x-...-firefox mime-type is not working :/... I built gnome-app-install branch, run it with --xul-extensions=firefox and nothing. I'll see later what went wrong. BTW, fixed branch of app-install-data is pushed. [05:13] all: I'm off... See you tonight :)... === cwong1 [i=chatzill@nat/intel/x-4240c10a8b1e0926] has joined #ubuntu-mozillateam [05:31] asac: moring/afternoon [05:32] s/moring/morning/ [05:32] cwong1: hi [05:32] its almost evening :) [05:32] @time berlin [05:32] Current time in Europe/Berlin: August 09 2007, 17:32:48 - Current meeting: Ubuntu Development Team [05:33] :) [05:33] depends on how your definitions are aligned of course ;) [05:33] so how do hildon menus semantically work? any findings on that? [05:33] and what other hildon features would we need to put into a mozhildon component? [05:34] asac: I was playing around with a sample hildon app and learned how it work. [05:35] asac: I was trying to hildonize the beast and ran into the same crashing problem we had before. [05:35] cwong1: please explain what you tried [05:35] in detail [05:35] a bit [05:35] and then lets see [05:36] asac, why would we use usr/lib/firefox-granparadiso-devel instead of usr/lib/firefox-granparadiso ? (there's not usr/lib/firefox-devel in ff2-dev) [05:36] asac: Just 1 sec. [05:36] s/not/no [05:36] Ubulette: its ok for now ... its because -devel package is not just a -dev package but more an application [05:36] we can later change that et al [05:37] note: i am still in meeting ... so high latency [05:37] I'm concerned but configure scripts that would have to search for libs and includes [05:37] I'm concerned by configure scripts that would have to search for libs and includes [05:39] there's no overlap for libs anyway [05:39] don't be [05:39] all will work out well ;) [05:39] but ... as i said ... lets package xul [05:39] and do it right from the beginning [05:39] we might waste precious time otherwise [05:39] I'm almost done [05:40] cwong1: i really have to understand what you tried [05:40] cwong1: as i am pretty sure that we should just implement a mozilla hildon api ... e.g. not rely too much on libhildon at all [05:41] asac, I only put stable includes in usr/include/firefox-granparadiso and libs from sdk in usr/lib/firefox-granparadiso [05:41] no ... all please (if you do it) [05:41] unstable as well [05:42] Ubulette: don't put them in sdk ... link them ... e.g. just install complete sdk and see if all is properly linked [05:42] with 'in sdk' i mean below -devel folder [05:42] asac: I added a call to hildon_program_get_instance (requrired to be an hildon app). I then added the call to hildon_program_add_winodw (program, MShell) after the call to hildon_window_new(). But it still died in libhildon. [05:43] in mozilla? [05:43] asac: I can send you a simple hildon app if you want. [05:43] or just in an example app? [05:43] asac: in mozilla [05:44] what did you try to tackle with that? [05:44] make install is broken for sdk.. too many links to /usr/... [05:44] that could be a bug in libhildon. [05:44] cwong1: actually i am more interested on the hildon semantics ... e.g. what menu is accessible how [05:44] asac: I can send you the sample app. [05:45] well ... can't you just assemble the menu with xul you later wnat to become a hildon menu? [05:45] i will take care of the rest then [05:45] e.g. make this menu only appear when it would appear if build with libhildon [05:46] i haev meeting ... lets talk about that while mobile meeting ;) [05:46] cwong1: ^^ [05:46] ok [05:48] ok i think i can spare some cycles [05:48] cwong1: [05:49] so you really want to use libhildon? [05:49] asac: here is the link to a sample hildon app. [05:49] asac: http://maemo.org/development/documentation/tutorials/Maemo_tutorial_bora.html [05:50] asac: I dont think we have a choice here. [05:50] cwong1: there is no menu in that [05:50] asac: u mean in that url? [05:51] cwong1: did you find out what hildon does for us? [05:51] in that example code [05:51] scroll them further [05:51] cwong1: imo it doesn't do much [05:51] but correct me when i am wrong [05:52] asac: It make the app behave like a hildon application. I.e. The menu will look right. That's what was spec out by Bob. [05:54] cwong1: so does the menu look different than a normal gtk window atm? [05:54] e.g. from theming point of view? [05:54] yes [05:55] Have you tried running the image built using the image creator? [05:55] yes .. can't remember [05:55] how it looked like [05:55] have no visual memory [05:56] can you produce a screenshot? [05:56] of a midbrowser menu like atm and a context menu of a working app? [05:56] asac: I will send you a screen shot in a few menus [05:56] great [05:57] asac: Take a look at http://www.moblin.org/screenshot_mousepad.html [05:58] and how does midbrowser look like? [05:58] just plain grey? [05:58] asac: the menu will appear when user click on the "Mousepad-untilite" button. [05:58] asac: did you see the menu [05:58] yes i know about all that ;) [05:59] cwong1: i can't remember ... so its just grey or what? [05:59] otherwise plankton should be fixed imo [05:59] asac: did you see the file, edit... [05:59] ? [05:59] cwong1: read above ... i can't remember [05:59] :) [06:00] asac: the browser just grey and like normal app [06:00] asac: non hildon app [06:01] ok ... thats a theme issue then i guess ... unless hildon does something really wierd [06:01] we have 2 options: [06:01] asac: if we do it right the main menu will not appear until user click on that button. [06:01] 1. we can hack around and create handcrafted GtkMenus [06:01] ... and probably fix lots of hildon code that has never been exposed to low level gdk apps [06:02] 2. we can add libmozhildon component which makes *our* menu popups appear at right place when we receive the X events hildon listens to [06:03] obviously 2 is the right way and the way with much more benefit, as we will get real xul in menus et al [06:03] with all the benefits we hope to get from xul in the first place: [06:03] mainly: extensions can just overlay and extend everything of our browser [06:03] asac: 2 seems to be hard to do. [06:03] so for me its obvious: 2. is the final goal [06:03] question is if its harder than 1 [06:04] from what i saw in hildon code, hildon doesn't do a thing ... its pretty naive [06:04] which is why i currently think that 2 is ever much easier [06:04] asac: hildon has api for an app to call to manage the menu. [06:04] as we will probably run into lots of wierd things when forcing 1. into mozilla [06:04] cwong1: which doesn't map to xul at all [06:05] cwong1: so either we hard code GtkMenu and hope that we can fix all crashes in hildon [06:05] cwong1: or directly do it proper [06:05] e.g. just use xul menu which will only appear when that hildon button is pressed [06:05] asac: does Xre use gtk_menu call to create its menu or it uses pop up? [06:05] no [06:05] it doesn't [06:05] which is why 2 is final goal [06:06] which is why i asked you to get info whatelse hildon provides [06:06] if it doesnt uses gtk_menu_new then 2 sounds reasonable [06:06] if its just menu + toolbar then we should directly go 2 [06:06] it doesn't use gtk menus at all [06:06] its all done on its own [06:06] it takes theme from widget prototypes and just draw that [06:07] yikes [06:07] so if we can theme normal GtkMenus in the same way Hildon Menus are themed then we are done [06:08] ok i will lurk abit on mobile meeting ... then going sport ... lets talk later [06:08] asac: ok [06:36] asac, there's no clean solution to have totem plugin working with a7 at the moment. Either we go the --with-gecko=xulrunner way or we temporarily re-add the (now) missing symbol in libxpcom [06:58] asac, what sources should I start with to package xulrunner ? === JenFraggle [n=JenFragg@host86-134-14-106.range86-134.btcentralplus.com] has joined #ubuntu-mozillateam === asac_ [n=asac@debian/developer/asac] has joined #ubuntu-mozillateam === JenFraggle [n=JenFragg@host86-134-14-106.range86-134.btcentralplus.com] has joined #ubuntu-mozillateam [08:11] Ubulette: get them from cvs [08:11] Ubulette: we have a wiki page ...w ait [08:13] hmmm [08:13] Ubulette: just do: [08:14] cvs -d:pserver.... co mozilla/client.mk; cd mozilla; make -f client.mk checkout MOZ_CO_PROJECT=xulrunner [08:14] i think we don't need a special tag to do the packaging [08:14] i will care for upstream release tags later [08:14] Ubulette: look up the pserver using google [08:25] asac, I've modified totem to no longer use nsMemory::Clone but only things from libxpcom.. so glue is no longer needed to run totem-plugin on FF3. [08:26] meaning even if totem is compiled with ff2-dev, it can run under ff3