[12:31] Jazzva: i think so [12:31] can find out tomorrow [12:31] what size do other icons have [12:31] ? [12:32] Well, the smallest is 32x32 [12:33] Others are mostly 128x128 [12:33] asac ^ [12:33] In xpm [12:35] asac, help :) === cwong1 [i=chatzill@nat/intel/x-e9a5b786b6f70843] has joined #ubuntu-mozillateam [12:36] Jazzva: then using 32x32 is ok [12:36] Ubulette: how? [12:36] :) [12:36] (cd ../../dist/firefox && tar -cvhf - .) | \ [12:36] (cd /src/firefox-granparadiso-3.0~alpha7/debian/tmp//usr/lib/firefox-granparadiso && tar -xf -) [12:36] cd: 2: can't cd to /src/firefox-granparadiso-3.0~alpha7/debian/tmp//usr/lib/firefox-granparadiso [12:36] this is were my build fails [12:37] thought the 1st line was supposed to create the missing dir.. it didn't [12:37] yeah .. which probvably means that make install doesn't install things [12:37] oops [12:37] 1st line missing [12:37] we do make install DESTDIR=debian/tmp/ [12:37] /src/firefox-granparadiso-3.0~alpha7/build-tree/mozilla/config/nsinstall -D /src/firefox-granparadiso-3.0~alpha7/debian/tmp//usr/lib/firefox-granparadiso [12:37] Ubulette: what is in /src/firefox-granparadiso-3.0~alpha7/debian/tmp//usr/lib/ [12:37] ? [12:38] nothing at that point. debian/tmp is still empty [12:38] nsinstall -D is supposed to create it just before the tar | tar [12:38] well .. but the compile succeeded? [12:38] yep [12:38] or is this right in the beginning? [12:38] ok [12:39] nope, the end [12:39] it's make install [12:39] have you tried to run make install DESTDIR=/tmp/testinstall [12:39] and see if all is properly installed beneath /tmp/testinstall? [12:39] e.g. you can run make install in build-tree/mozilla [12:40] yep. worked [12:40] yes ... which is what i saw [12:40] question is why does it fail if its run through debian/rules [12:40] but not if manually [12:40] exactly [12:40] i managed to run exactly the same command that debian/rules runs manually [12:41] Ubulette: so it fails lik [12:41] 00:37 < Ubulette> /src/firefox-granparadiso-3.0~alpha7/build-tree/mozilla/config/nsinstall -D /src/firefox-granparadiso-3.0~alpha7/debian/tmp//usr/lib/firefox-granparadiso [12:41] ?? [12:41] is that the first command run if you run make install manually? [12:41] this did nothing apparently but manually, it works fine [12:41] I can post my full logs [12:41] the double / isn't a probloem, right? [12:42] Ubulette: well ... i am as smart as you are ... i just know that i ran into the same problem [12:42] manually, the double / is not a problem [12:42] and had no time to look into it [12:42] it looks like its an environment thing [12:42] asac, you seems to master this whole mozilla maze. I don't :) [12:42] if you can figure out what is different in environment when run through debian/rules compared to manually then you are a hero :) [12:43] well, env is the same, ie a very very limited chrooted bootstrap [12:44] well ... but if env is the same and everything else is the same then we should see same result [12:44] :) [12:44] but we don't ... which is why i guess that env is different [12:44] as i don't see whatelse might be different [12:45] Ubulette: oh [12:45] Ubulette: pleasae try this: [12:45] chose a different upstream version [12:45] maybe its some path expansion thing and ~ confuses something [12:46] (stupid guess ... but worth a try) [12:46] asac: I'm also making .desktop files, since none of these packages have one (I don't know why I expected they will (Oh, yeah... I wasn't looking forward to making a whole bunch of .desktops :)))... Hope that's ok with gnome-app-install. [12:46] so maybe try if building with upstream version name firefox-granparadiso-3.0a7 helps [12:46] Ubulette: i had some discussion with debian maintainer who had issues if upstream directory had a tilde in its name [12:47] though i think it was unrelated to mozilla build system ... but who knows :) [12:47] Jazzva: yes thats the idea [12:47] Jazzva: create .desktop files [12:47] inject .png [12:47] ...xpm :) [12:47] Jazzva: and finally add Mime-Type: ... to those desktop files [12:47] so we can search for firefox/thunderbird et al extensions by mime-type [12:48] yeah .xpm is good as well [12:48] asac: As soon as I talk to g... (have nick in logfile) about Mime-Type :). [12:48] i think good practice is to leave out file extension in desktop file [12:48] glatzor [12:48] ok, i'll debug the hard way. [12:48] Jazzva: if glatzor says that he hasn't hard-coded a mime-type so far, just let me know and I will give you one [12:49] Ubulette: cool :) [12:49] Ubulette: but how? [12:49] Ubulette: the patch applied cleanly, right? [12:49] let's insert a strace in rules.mk [12:49] the make install patch i mean [12:49] which patch ? [12:49] asac: Ok... Off for a while... Have fun debugging :). [12:49] Jazzva: thanks [12:50] :) [12:50] asac: I am having problem running the midbrowser built off of the WORKING branch. It takes a long long time before it comes up. And I see 2 tabs in the browser, one labeled with (Unttled) and the other is loading the home page. Do you have the same problem I do? [12:50] asac, I've created debian/patches/50_from_bugzilla_fix_make_install.patch which is bugzilla minus xulrunner patch [12:50] ok [12:51] cwong1: the two homepages are a feature [12:51] cwong1: its called milestone feature ... and you get that when you upgrade [12:51] cwong1: for taking long time before it comes up ... i don't see that [12:52] cwong1: in my chroot it always takes a bunch of time because of high X latency i guess [12:52] asac: hmmmm I thought the damn thing was hung [12:52] do you run in chroot? [12:53] asac: Yes. I am using the image that I created with image creator [12:53] and xephyr? [12:54] asac: yes [12:54] in general i don't see any reason why it would take longer to start up [12:54] remember that working still has hildon window [12:54] so maybe thats the difference [12:54] asac: I disabled that from nswindow.cpp [12:54] ok [12:54] how? [12:55] patched reverse? [12:55] yes [12:55] ok [12:55] so what do you test? starting from dist/bin ? [12:55] btw, what is the "Utitle"page points to? [12:55] yes [12:55] I cd to dist/bin and enter ./midbrowser [12:55] cwong1: are you sure it takes longer then previous midbrowser? [12:56] yes a lot longer. [12:56] hmm may be its because I dont have the proxy setup and it waited the page to time out [12:56] well .. sounds reasonable :) [12:57] cwong1: maybe compare startup time right after removing ~/.mozilla/midbrowser [12:57] ok I will play around with it and see.. thanks [12:57] e.g. with fresh profile [12:58] we can talk about the start pages on another day [12:58] yes [12:58] for now get the menu assembled :) [12:58] I do see the toolbar on the bottom.. looks good. [12:58] yeap [12:58] and strip what is currently excluded by localstore.rdf out of midbrowser.xul :) [12:58] will do [12:59] for the milestone pages: [12:59] everytime mozilla detects that you upgraded to another build it will try to display a release notes page [12:59] in addition to homepage [01:00] ok didnt know that [01:00] we have to discuss if we want that .... or what we want [01:00] in ubuntu we have turned this feature completely off for firefox [01:00] its a simple solution, but since we are real upstream we might want a bit more [01:00] that's what I was thinking. [01:00] disable it completely [01:01] yeah ... but it requires a patch against upstream firefox [01:01] which is not good [01:01] better: setup a release notes page on moblin.org :) [01:01] we can patch it for ubuntu package like we do for firefox [01:01] ... if we want [01:01] we can decide on this when Bob comes back next week [01:02] sure [01:02] its not really pressing i hope [01:02] no [01:02] after all its a simple thing to change [01:02] just remember to keep it on radar [01:02] y [01:02] back to working on menu..:) [01:02] cool :) [01:03] do'h, I have to recompile everything once again [01:05] Ubulette: why? [01:05] usually i just rerun dpkg-buildpackage -rfakeroot -nc [01:06] to retry make install [01:06] only [01:06] there's a clean at the beginning [01:06] no ? [01:06] no [01:06] dpkg-buildpackage -rfakeroot -nc [01:06] will just clean your make install [01:06] not the whole build [01:06] e.g. debian/tmp debian/PACKAGNAME wil be cleaned [01:06] and make install rerun [01:07] hmm [01:09] just give it a try [01:09] saves you 30-60 minutes [01:12] hmm, strace is interesting. [01:12] mkdir("/src/firefox-granparadiso-3.0~alpha7/debian/tmp", 0777) = 0 [01:12] stat64("/src/firefox-granparadiso-3.0~alpha7/debian/tmp", {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0 [01:13] it wants the dir in 777, it's created in 755, then nsinstall is lost [01:17] well [01:17] why would it get lost then? [01:17] Ubulette: when you run make install DESTDIR=... manually [01:18] is DESTDIR afterwards 777 ? [01:18] no [01:18] so thats not the issue then [01:19] Ubulette: try if make install DESTDIR=/tmp/test-1.0~4asda/ works [01:19] maybe its indeed the tilde [01:20] though i doubt that you would see any crazy expansion in bash [01:20] but maybe in the new install:: rule in config/rules.mk [01:21] I don't have tilde anywhere [01:21] I build in /src [01:22] http://pastebin.mozilla.org/182412 [01:22] see by yourself [01:24] Ubulette: e.g. /src/firefox-granparadiso-3.0~alpha7/debian/tmp//usr/lib/firefox-granparadiso [01:24] there is tilde: [01:24] adiso-3.0~alph [01:24] oh [01:24] please test the make install above [01:24] make install DESTDIR=/tmp/test-1.0~4asda/ [01:24] and see if /tmp/test-1.0~4asda/ is empty afterwards [01:25] or fails [01:25] bingo [01:25] fails [01:25] yeah cool [01:25] thats not nice ... but a direction [01:25] ok so look in the patch [01:25] the make_install one [01:26] there should be some place where the DESTDIR gets expanded [01:27] reading... [01:27] yes thats fine [01:27] anyway ... iam sure there is some code that chokes on tilde in DESTDIR in https://bugzilla.mozilla.org/attachment.cgi?id=274304 [01:29] Ubulette: maybe its NSINSTALL? [01:29] it's in C so no ~ expansion [01:30] welll i guess it happens before [01:31] asac: trunk is still FTBFS [01:32] same spot too [01:32] let me look at somehting [01:33] Ubulette: maybe $(NSINSTALL) -D $(DESTDIR)$(installdir) need to be something like $(NSINSTALL) -D '$(DESTDIR)$(installdir)' [01:33] ? === gnomefreak bets debian/tpm is empty [01:33] gnomefreak: yeah [01:33] we are working on it as you may read :) [01:33] yep empty [01:33] ah ok [01:35] asac, nope as strace shows the cmd line is ok [01:35] ie not expanded at the ~ [01:36] Ubulette: tmp is created ... but no dir below, right? [01:36] right [01:36] do you see any attempt to create or stat a dir below? [01:36] e.g. tmp/usr ? [01:36] or tmp/usr/lib/firefox* ... directly? [01:37] no. see my pastebin above [01:37] by the looks of the failure here it looks like what you have is it [01:37] gnomefreak, seems close now :) [01:38] it does but still this one has been bothering me for a while since the output doesnt match the error (sortof) [01:38] Ubulette: for me the strace looks like nsinstall fails to step down [01:38] (cd /home/gnomefreak/firefox/trunk/debian/tmp//usr/lib/firefox-trunk && tar -xf -) [01:38] Ubulette: e.g. it tries to mkdir for every level ... but always with just tmp [01:39] other than that it doesnt really play in tmp [01:39] Ubulette: does unix install -D ? [01:39] support -D i mean [01:39] if so ... try to replace NSINSTALL with SYSINSTALL in patch [01:41] i can only go so far up but rm -f -rf ../../dist/xpt is where the trouble seemed to have started, after that it lists paths /bin/..... and some have errors/warnings than when thats done it fails [01:41] 2 secs, debugging nsinstall.c [01:42] it has to doesnt it [01:43] i see a -DD before the failure (a while before it) [01:43] thought i saw a -D [01:44] Ubulette: does nsinstall alone fail as well? e.g. just nsinstall -D /tmp/test~123123/usr/lib [01:45] in shell, nsinstall -D is okay, not through dpkg-buildpackage [01:46] Ubulette: so ... not when run through make you mean [01:46] e.g. how about a simple make file ... with just [01:46] run: [01:46] nsinstall -D /tmp/test-1.2~123/usr/lib ? [01:46] does that work? [01:47] i mean we had make install DESTDIR=... fail ... so te problem probably appears in combination with make [01:47] i bet most likely with $(DESTDIR) expansion in make [01:47] e.g. so above make snipped will work while [01:47] run: [01:48] nsinstall -D $(XYZ) [01:48] will fail if run like [01:48] make XYZ=/tmp/test+1.x~123xca/usr/lib [01:48] well, I don't think so. nsinstall -D is just a mkdirs which is a reccursive function calling mkdir.. and it seems clearly wrong [01:49] ... if it doesn't happen in makefiles with the expansion above then i don't know [01:49] the call to mkdir in always debian/tmp instead of d/t/a d/t/a/b d/t/a/b/c etc. [01:49] yeah [01:50] it's all wrong within the C code [01:50] yeah the amount of mkdirs == depth of path below debian/ ? [01:50] yes [01:50] but why would it break in make and not from shell? [01:50] if its in C code? [01:51] it has to be something expansion'ish [01:51] that's what I'm trying to find out [01:51] well ... does the Makefile above fail on make run DESTDIR=... ? [01:51] that would clearly help to evaluate [01:53] Back and stuff... Off to those .desktops [01:54] Ubulette: what makes me feel scary is that mkdirs in nsinstall.c passes a non const char* down recursively [01:54] and even modifies this within recursion: [01:54] path[l - 2] = 0; [01:54] might be right ... but looks hard to manage :) [01:55] so it modifies the path ... passes modified path to mkdirs recursively and upon return it runs mkdir with the path it previously modified to pass down? [01:55] that looks wierd [01:55] found it. It's the double / [01:55] really? [01:56] you see that in code? [01:56] can you fix nsinstall.c ? [01:56] I'm working on it [01:56] ok so you have to cut of trailing // before recursing [01:57] ok [01:57] atm it only strips leading double / [02:11] Ubulette: good luck :) ... i am going to bed now. Let me know about your findings please ... i will read logs when i wake up [02:12] done. [02:12] it works now [02:13] Ubulette: how? [02:13] patch ;) ? [02:13] yep. 2 sec [02:13] sure [02:15] how ? pastebin ? [02:16] at best push a ready branch to launchpad :) [02:16] but pastebin is ok as well [02:16] at least let me take a look through pastebin [02:16] http://pastebin.mozilla.org/182420 [02:17] ok so it was in-recursion modification? [02:17] of path? [02:17] the idea is when the initial code see a //, it modify path, which is wrong for the inner mkdir [02:17] I just keep the oringinal path (opath) and free it later [02:18] Ubulette: maybe the bug is in line 20 ? [02:18] i mean is that needed? [02:18] yep [02:18] it should be zero because of while before [02:18] or because strend [02:19] oh i see [02:19] it does not restore all / before return [02:19] ok [02:19] ok thanks ... strdup looks like the more reasonable approach [02:20] assuming that nsinstall does not try to minimize memory usage for real of course [02:20] should not be a problem. strdup does its own allocation [02:21] it's basically malloc + strncpy [02:21] yeah [02:21] anyway ... its not as efficient as not duplicating mem :) [02:21] Ubulette: ok whats your lp id? [02:22] and name + email? [02:22] ubulette [02:22] my lp account is uptodate (email, ssh key, etc) [02:23] Ubulette: if you want you can push a paradiso alpha7 branch to launchpad [02:23] otherwise i will prepare it tomorrow [02:23] never done that before. I'm used to package debs on my side :P [02:23] I've designed a buildbot [02:24] https://launchpad.net/~ubulette [02:24] is "page not found" [02:24] oops [02:24] https://bugs.launchpad.net/~fta+launchpad [02:24] it's based on my email [02:25] don't see any email on that page [02:25] anyway [02:25] Ubulette: if you want to contribute on the long run, get used to bzr ... ok good night ;) [02:26] I'm used to cvs, svn, hg, git [02:26] why not bzr :) [02:26] well then bzr should be easy [02:26] just commit yuor changes locally [02:26] and if ready push to sftp://$USER@bazaar.launchpad.net/~$USER/firefox/granparadiso [02:27] bzr push URL [02:27] ok night [02:27] ok, I'll think about it. good night [02:27] ah ... start with my granparadiso branch of course [02:27] https://code.launchpad.net/~mozillateam/firefox/granparadiso [02:31] btw, that patch, or something similar should go upstream [03:17] I guess mozilla/nsprpub/config/nsinstall.c has to be patched too. It's a different version than mozilla/config/nsinstall.c but has the same flaw. [03:18] I still need to review the *.install files as my debs are still broken. [03:19] Got tons of "Warning: package error or possible missing or unnecessary file" since the make install patch. Got to figure out what that means too. [03:19] tomorrow. Bed time now. === Admiral_Chicago [n=FreddyM@adsl-68-72-81-177.dsl.chcgil.ameritech.net] has joined #ubuntu-mozillateam [05:29] im off to bed finally, i will try to get on tomorrow but i have alot of work if my aunts pc is still failing to grab her email but we will see, iceape is done afaik let me know if you need anything else feel free to email me if im not here ill try to check email tomorrow. [08:20] @schedule [08:20] Schedule for Etc/UTC: 08 Aug 12:00: Edubuntu | 09 Aug 15:00: Ubuntu Development Team | 10 Aug 04:00: MOTU Team | 11 Aug 17:00: Xubuntu Developers | 14 Aug 15:00: Ubuntu Server Team meeting | 14 Aug 19:00: Technical Board === hjmf is off [12:19] Ubulette: can we make the patch more memory-sensitive by just removing the while that zeros double / ? [12:19] Ubulette: e.g. without strdup? [01:41] Ubulette: would be cool if you could commit your update to granparadiso-fsh as well as the nsinstall.c patch to bzr [02:25] asac: Is it ok to take a logo of a service for it's extension icon? (for example StumbleUpon's logo) [02:26] Also, do I need to have a Generic name field in .desktop for gnome-app-install? If I need, would "Firefox extension" be enough? [02:32] hi [02:34] morning :) (well, good afternoon) [02:35] asac, for the double / patch, Iet me see what I can think of. [02:37] Jazzva: if the icon looks good and is not non-free then yes [02:43] asac: Ok, and if I cant find an icon should I leave it without it or use firefox logo? [02:48] Ubulette: i have a fix for that already [02:48] Ubulette: wait a sec [02:49] I have one too [02:49] Ubulette: http://people.ubuntu.com/~asac/patches/fix_nsinstall_on_double_slash.patch [02:50] Ubulette: please use bzr ... otherwise we will duplicate work [02:54] Ubulette: ok i am pushing what i have so far to the mozillateam granparadiso branch [02:54] my guess is that the code you remove is useful for some platforms [02:54] not for linux/unix [02:54] Ubulette: at best start with that one and commit your changes locally and then push it to bzr branch [02:54] so i can merge it for release [02:55] Ubulette: might be === Ubulette is on the phone. brb [02:56] Ubulette: however ... since the current code would break on any platform i doubt that the code was really tailored for needs of different platforms [02:56] i think it was just ment to be smart ... minimizing memory + minimizing recursion [03:11] back [03:12] asac, http://pastebin.mozilla.org/182527 [03:13] that does the work and still removes trailing slashes to mkdir [03:17] Ubulette: well [03:17] i don't think this will fix the issue for us [03:17] as it will still set / to zero further down the recursion [03:17] if you want to remove trailing / you have to remember all positions and set them back to / after recursion [03:18] no. tested on my tree. I works as good as my strdup [03:18] well it doesn't do anything as i see now [03:18] it just fast-forwards to the last / [03:18] ok [03:18] it does move backward [03:18] yes of course [03:19] ok [03:19] Ubulette: ok please start with current mozillateam branch ... update the patch i currently have and then see how far we get [03:19] afaict it should at least install all things [03:20] sftp://asac@bazaar.launchpad.net/~mozillateam/firefox/granparadiso/ [03:20] bzr branch https://code.launchpad.net/~mozillateam/firefox/granparadiso [03:20] then go [03:20] :) [03:20] i would refrain from working on that branch then for today ;) [03:21] how do I start ? bzr co or bzr branch ? [03:21] like above [03:21] then you commit for each change like you do in cvs [03:22] and when you are done you push it to your private branch in launchpad and let me know so i can merge it in release branch [03:22] e.g. when done do [03:22] bzr push sftp://ubulette@bazaar.launchpad.net/~ubulette/firefox/granparadiso/ [03:23] Ubulette: there is an example on how to build midbrowser using bzr builddeb [03:23] https://wiki.ubuntu.com/MozillaTeam/Build/Bzr?highlight=%28mozillateam%29%7C%28bzr%29 [03:23] i think you can easily adapt that ;) [03:23] otherwise you can build as usual ... just ensure that the tar.bz2 is in top level directory of branch when running dpkg-buildpackage -rfakeroot or whatever [03:24] if you want to use bzr builddeb just make tarballs directory next to where you checked out the bzr branch and put the orig.tar.gz in there [03:24] (like in wiki) [03:25]