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