=== tonyy is now known as tonyyarusso === tonyy is now known as tonyyarusso === asac_ is now known as asac === \sh_away is now known as \sh [08:57] hi [09:19] !info prism [09:20] Package prism does not exist in gutsy [09:20] !info prism hardy [09:20] Package prism does not exist in hardy [09:21] well ... it exists [09:53] Ubulette: i asked something on the valgrind bug [09:54] Ubulette: if there is no upstream release the debdiff looks good [11:40] hi [11:40] asac, answered === \sh is now known as \sh_away [12:31] Ubulette: gnome-python-extras is in mt ppa [12:52] !info prism hardy [12:52] Package prism does not exist in hardy [12:53] http://archive.ubuntu.com/ubuntu/pool/universe/p/prism/ [12:53] at last [13:03] bot appears to be buggy [13:28] asac, so, valgrind ? [13:36] will up it after lunch [13:47] mozilla bug 405290 [13:47] Mozilla bug 405290 in Build Config "Implement version checking for nspr and nss" [Normal,Assigned] http://bugzilla.mozilla.org/show_bug.cgi?id=405290 [13:53] <[reed]> yep [13:53] <[reed]> nspr is restricted [13:53] <[reed]> I can't check-in there, so need somebody else to land [13:53] <[reed]> only about 10-15 folks have access [14:38] * asac break === \sh_away is now known as \sh [16:12] + Install .1d libraries in -1d packages. [16:12] + Add .0d links to .1d libraries. [16:12] + debian/libnss3-0d.dirs: Renamed to libnss3-1d.dirs. [16:13] nss_3.12.0~1.9b1-1_i386.changes is NEW [16:13] Ubulette: ^^^ [16:24] hi [16:25] I'm trying to package a firefox extension for Ubuntu, but I can't get the browser (midbrowser - for UME) to recognize the extension when I install the deb [16:25] smagoun: where do you install it? [16:25] (midbrowser is based on firefox) [16:25] asac: /usr/lib/midbrowser/extensions/grabAndDrag@ubuntu.com [16:26] thats right ... you just have to take care that the dirname you choose in the extensions directory matches your em:id in the extensions install.rdf [16:26] I looked at the ubufox + greasemonkey extensions, they install things the same way (just dump the files there - no postinst that I saw) [16:26] yeah its just extracting the .xpi in that dir ... but the id has to match :) [16:26] try firefox first [16:26] for midbrowser you need to add a new targetApplication id [16:27] asac: aha! The em:id doesn't match in my case [16:27] but otherwise its the same [16:27] The extension works fine when installed from an .xpi, but in that case midbrowser creates the directory in ../extensions. That's the piece I was missing. [16:28] * smagoun tries a fix [16:29] smagoun: fine [16:30] asac: That was it. I sync'ed the em:id with the installation directory, and it works now. Thank you for the help! [16:30] smagoun: welcome [16:31] smagoun: if you need a package sponsor for anything mozilla related, feel free to ask here [16:32] asac: Will do. Thanks. === \sh is now known as \sh_away [16:45] EOpbuilder [18:15] back [18:15] asac, "add .1d" is good news. "add .0d links to .1d" may not be so good [18:16] but it's needed as he reused the same pkg name :( [18:28] reused it? [18:28] isnt it just a transitional package? [18:28] hmm [18:28] why? [18:28] he used a new source [18:36] i hate simple patch system :) [18:46] i hate dpatch [18:51] i hate both ;) [18:51] did you re-push valgrind ? [18:54] no, but python + miro are now in porting branch + hardy ppa :) i wasted too much of the day on that [18:54] i will now take a break and then go ahead and do valgrind [18:56] Ubulette: do you know the svn revisions combined in that patch? [18:56] i would like to add the numbers to changelog before upload (if possible) [18:57] 7181 7182 7226 but not complete as they merged another project since. I just took what is needed for us. [18:58] (Helgrind) [18:58] asac, ^^ [18:59] lol [19:00] asac, what ? [19:01] Helgrind [19:11] http://valgrind.org/docs/manual/hg-manual.html [19:11] ah [19:11] ok valgrind is up [19:12] but that's for 3.3.0 (soon), not our 3.2.3. [19:12] but please up this one, i hate to keep a ftbfs unfixed [19:13] read [19:13] :) [19:13] oh, thnaks [19:13] thanks [19:13] if you have a chance, please test miro from ppa ... let me know about any fine regressions (because i never used it and don't know any feature) [19:14] well ... probably takes an hour till binaries are avail [19:14] * asac taking some rest now [19:15] did you reuse my patch or not at all ? [19:16] no ... i started from scratch today ... maybe check if the parts are similar :) [19:17] the patching didn't take that long ... it was the crashes i got last time i tried that caused a hell of pain [19:19] i think only thing left in main (except a fixed epiphany) is csharp binding [19:20] oh there is even a ruby binding :) [19:21] i think in the long run all bindings want two modules: gtkmozembed (standalone glue) and gtkmozembed_dependent (dependent glue) [19:22] then miro could have implemented standalone glue in its own python module and use gtkmozembed_dependent ... but well, in the end you have to think anyway [20:00] there's a huge backlog for all builders. i wonder why they lock 1 builder per arch for live-cd & security even when there's nothing to do [20:00] live-cd? [20:01] security makes sense because its somehow a separate infrastructure [20:03] "NOT OK : LiveCD / Security (MANUAL)" [20:04] amd64 287 [20:04] hppa 1717 [20:04] i386 120 [20:04] ia64 247 [20:04] lpia 13 [20:04] powerpc 188 [20:04] sparc 287 [20:04] yeah thts most likely just security [20:04] 1717? [20:04] sources? [20:04] hppa will take forever. [20:04] those are the queues per arch [20:04] well ... a few days [20:05] freeze will happen on thu [20:05] in a week, not even 200 for hppa [20:05] so the normal rush before the door closes [20:06] you mean debian sync freeze or whole freeze ? [20:06] its sync freeze [20:06] (and initial merges) [20:06] i think the deadline is to have on thu every package merged/synched at least once [20:07] for me its more like a goal than a freeze though :) [20:07] its just that auto-syncs will stop [20:07] then we will have plenty of time to do fixed et al :) [20:08] merge list is still long. I'm only interested by some, all in main :O [20:09] btw, mozclient rewrite nearly complete [20:09] rewrite? [20:10] in which are you interested in main? [20:12] hmm why is network-manager under "Updated Merges" [20:16] mozclient is now like cdbs [20:19] so prepared to be shipped as a dev-package ? [20:19] and used in debian/rules to implement the new-orig rule? [20:19] yep [20:20] include /usr/share/blablalba/firefox.mk and you gain get-new-orig doing everything (embedded tarball or not) [20:21] same for {xulrunner,seamonkey,nss,nspr}.mk [20:38] asac : Hi! Did you have time to look at bug #53387 ? [20:38] Launchpad bug 53387 in wpasupplicant "Manual WPA networks doesn't connect at boot" [High,Triaged] https://launchpad.net/bugs/53387 [20:45] Ubulette: the .mk file is named after the app? [20:45] not a generic one? [20:46] saivann: maybe ask siretart first ... he is the wpasupplicant maintainer in debian an usually does it here as well [20:47] if he cannot help i can take a look [20:47] saivann: is that good enough for now? [20:47] so far, it's like before (all my previous -orig targets s/-orig/.mk/). but i'm open to suggestions :) [20:47] asac : Okay thanks, this problem can be fixed by removing a udev rules that affect network, do you still think that siretart is the right person? [20:48] saivann: well ... I am not really sure why and what is going on. maybe its a bug that can be fixed elsewhere? [20:48] saivann: you can explain the reasoning behind this? [20:49] asac : It seems to be a matter of a udev rule, but I can't explain it. I'm not very sure that the problem is really in wpasupplicant itself [20:49] saivann: yes, right ... thats why i would like a comment of siretart ... maybe he knows right away whats going on [20:49] asac : I'll do this, thanks for this [20:49] if he is not available soon, I can take it on my plate to evaluate [20:50] asac : Okay [20:51] asac : I'm also working on lightning-extension-locales and sunbird-locales 0.7 for Hardy, what would you think if these two packages were merged into one package? After all, sunbird and lightning-extension have the same source package [20:52] yeah ... sounds good ... just remember that maybe the mozilla locale packages will be provided by launchpad translation in the end of hardy cycle [20:52] but for now it would be good to have at least locales :) [20:53] asac : you mean that soonly all Mozilla apps will be automatically translated with rosetta? [20:53] unfortunately the guy doing this is on holiday till mid of january [20:54] so i am not really up-to-date what is going on [20:54] but in the end it should happen automatically from what i understood [20:54] (but given that i haven't seen a single package it might as well just be idealistic to assume that we can use it in hardy) [20:54] asac : Okay, I'll drop the idea of the "all-in-one" package, but I'll finish both sunbird-locales and lightning-extension-locales in a few days [20:54] cool [20:56] asac : Who's working to put mozilla apps translation in rosetta? Perhaps that I can help on this [20:58] carlos [20:58] but he is gone till mid january ... at best ping me then [20:59] asac : Ok thanks again [21:02] asac, http://stompbox.typepad.com/blog/2007/12/prism-is-neat.html [21:11] Ubulette: rock! [21:51] 40, 10 isn't exactly under the marque [21:51] it's off [21:53] ? [22:13] jimmy_: does pressing F4 still bring up the popup? [22:14] jimmy_: the ported tarball fails like this: http://paste.ubuntu.com/2651/ [22:14] (to build) [22:14] asac: yes, it does, but again, only after i right click on the page, it won't popup for the 1st time [22:15] ok ... the build failure needed a -lX11 [22:16] build is going on [22:17] the X11 problem was probably due to new gtk in hardy [22:17] i don't remember anything related to x11, i am using gutsy [22:18] ok [22:26] jimmy_: how did you port all this? [22:26] did you read my notes? [22:27] carl emailed a copy to you [22:28] jimmy_: ok ... i will fix these issues and try to clean up the whole patch then start the 3.0 branch in git [22:28] i basically diff the 2.0.0.6 FF source, and the MID Browser, then ported those changes over to the FF 3.0 source [22:29] what did you do with the midbrowser/ tree? [22:29] copied it or 3-way diffed midbrowser.xul with browser.xul? [22:29] i clone it over, and then did a 3-way diff [22:29] yeah [22:30] ok fine ... thanks for all the work on this [22:30] i had to, because midbrowser was derived from browser [22:30] it was good it didn't copied everything over, so it wasn't too bad [22:30] i will go through and move things around where appropriate [22:30] there are two things that are important now: [22:30] support system-xul => mega-startup-booster [22:31] (without we probably startup in 1/3 of time of ffox 2) ... but if we use system-xul it will be 100x [22:31] because the home screen will already load xul for us (i guess) [22:31] 2. gconf backend => [22:32] there is 0.5 MB patch in bugzilla ... you think you can clean that up (against upstream ffox-3.0 so we can submit it upstream)? [22:32] is that the same gconf patch we had for the MID browser, or a different 1? [22:32] jimmy_: yes ... reusing as much as possible unmodified is the primary goal we currently have (with the small number of devs) [22:32] jimmy_: no the one you had is a hack :) [22:33] well ... maybe you really had that [22:33] but i think you used the suse one [22:33] https://bugzilla.mozilla.org/show_bug.cgi?id=321315 [22:33] Mozilla bug 321315 in Preferences: Backend "New gconf preferences backend" [Normal,New] [22:33] yes, i use the suse one [22:33] jimmy_: ^^ [22:33] "The existing gconf system-pref code is kinda nasty and is also quite limited in [22:33] the preferences it maps over to Firefox. I've cleaned up Novell's internal [22:33] gconf pref-mapping code (which was even more nasty!) and it's ready for [22:33] submission to the trunk." [22:34] ^^ so thats the cleaned up thing ... and i want this to finally land upstream (even though the redhat guy raised that gconf might not be for the future, but well we live now imo) :) [22:35] there are 3 patches, i need all of them? [22:35] or just the gconf_backend? [22:35] all i think ... the big patch isn't that big ... it includes the configure diff as well [22:36] and read comment #13 [22:36] the patches should probabyl apply pretty cleanly [22:36] (read comments) [22:37] ok [22:38] I'll see if I can patch it to the 2.0.0.6 source, then port it over [22:38] jimmy_: please not [22:38] just do it on 3.0 ... against ffox [22:39] everything else is really wasted time [22:39] the patch is for 3.0? [22:39] read the comments :) ... thats what i asked roc ;) [22:39] comment #12 [22:39] shouldn't be too hard from what i read from roc [22:40] if you run into too many diverges let me know ... i can do that then [22:40] because i know that the gconf source changed in FF3.0, that's why i am afraid i won't patch cleanly [22:40] :( you really replaced the build system :( [22:41] jimmy_: well it should be just bit-unthrottling :) [22:41] give it a try [22:41] ok [22:41] (i mean replaced the debian/ directory) [22:41] i didn't touch anything in the debian directory [22:42] yeah it was cwong :( [22:42] i don't even think i included the debian directory in the port i gave you [22:43] what's wrong with the build system? [22:43] no you didn't ... but you gave me CVS directories from firefox 2 mixed with sources from firefox 3 :) ... which was rather confusing [22:44] ok ... great. [22:44] then lets see to get gconf going [22:44] i will open the ffox 3 branch in git and try to untagle the monolithic diff i currently have a bit [22:45] and fix the menu [22:45] are all things that are currently committed to the stable branch already in that -ported thing? [22:45] jimmy_: http://www.moblin.org/repos/?p=projects/mobile-browser.git;a=shortlog [22:48] no, carl pushed more changes after i ported it [22:49] the latest fix i have integrated was the gfx/src/gtk/gtk2drawing.c fix that was 11 days ago [22:49] anything newer than that, i didn't integrate those [22:51] ok ... what is that gtk2drawing.c fix about? [22:53] there was a bug on the certificate dialog box, that whenever we access a site that requires you to accept a certificate, if you move the mouse around the certificate dialog randomly, it will crash the browser [22:53] ouch ... ok [22:53] we should investigate the root cause [22:53] (just to keep in mind) [22:53] we originally thought it was related to some hildon theme stuff, because it cannot be reproduced outside the hildonized enviroment [22:54] jimmy_: thats likely [22:54] but Carl later said it was some gtk issue [22:54] and he commited a fix for it, and seem to work [22:55] ok putted it on radar [22:56] asac, why did you commit ppa stuff in xul.dev ? [22:56] he? [22:57] because its the pre-release of an official release? [22:57] or did i mess up completely? [22:58] well, ok. on my side, I now put all my ppa stuff into a ppa branch and I collapse the corresponding changelog in the .dev branch [22:58] Ubulette: ok ... its just to uphold the luxury that we can still have both branches in sync atm [22:58] <[reed]> I need to link with nspr for a program I'm writing [22:58] <[reed]> $ g++ -o wordCount -Wall -pedantic -lnspr4 -I/usr/include/nspr -Wno-long-long wordCount.cpp [22:58] <[reed]> /tmp/ccftoep4.o: In function `main': [22:58] <[reed]> wordCount.cpp:(.text+0x1c4): undefined reference to `PL_CompareValues' [22:58] <[reed]> ... [22:58] <[reed]> (more errors) [22:58] <[reed]> what am I doing wrong? [22:59] <[reed]> n/m [22:59] <[reed]> biesi helped me [22:59] <[reed]> thanks [22:59] [reed]: try $(pkg-config --cflags --libs nspr) [22:59] ok [22:59] <[reed]> ah [22:59] <[reed]> that works, too! [22:59] <[reed]> $ g++ -o wordCount -Wall -pedantic $(pkg-config --cflags --libs nspr) -Wno-long-long wordCount.cpp [22:59] <[reed]> cool [23:00] thats the idea ... .pc files give you the right flags :) [23:00] <[reed]> :) [23:00] <[reed]> thanks [23:00] np [23:01] [reed], the 2 cairo / xrender patches are still waiting, right ? [23:01] <[reed]> dunno, haven't looked [23:02] Ubulette: i think its ok if we merge from your .ppa branch when we get close to release ... is that what you mean? [23:02] you don't even have to collapse changelog when merging that way ... as long as all entries are _not_ UNRELEASED its ok to have them in there [23:04] no. ppa changelogs are not welcome on the motu side.. and indeed, it look weird from the outside [23:05] ok ... i have no strong opion on that [23:06] i now just pile up all the new stuff in .dev (or .head), merge in a ppa branch with only a more granual changelog (containing all the ppa rlz) [23:06] in fact, i'm not even pushing my own (~fta) ppa branches. yet i can. [23:07] what do you pile up? [23:07] firefox-3.0.dev.ppa kazehakase.ppa libcairo.ppa nspr.ppa nss.head.ppa ppa prism.ppa seamonkey-1.1.dev.ppa seamonkey-2.0.dev.ppa xulrunner-1.9.dev.ppa miro.ppa [23:07] changelogs [23:08] look at xul.head [23:08] no (recent) ppa [23:08] hmm [23:08] xul.haed is beta 3 already, right? [23:08] not yet [23:09] the patch bumping the versions just landed but as long as I don't change anything, .head will stay b2 [23:09] ok ... so lets say xul.head would be ready ... we could then merge it over and just join the changelogs [23:09] untill I merge (or pull) in .dev [23:09] -l [23:10] Ubulette: just to summarize what i understood for a few weeks now: [23:10] merge should work. [23:10] 1. .head: tracks trunk [23:10] 2. .dev tracks current development branch (hardy) [23:10] yep [23:10] ... in dev there can eventually be uploads to mozillateam ppa [23:12] hm, that I would like to change. ppa should stay out of the picture [23:12] ok, i think it was really not smart to pull to the gutsy branch [23:12] indeed :) [23:12] i should have done that in a merge and change the changelog only on gutsy brnch [23:12] (in the merge i guess) [23:12] yes. it's still possible [23:16] Ubulette: i am not sure how smart bzr is ... will bzr try to merge back the changelog changes even if i do them in the same commit as the merge? [23:16] or will it consider such changes "adaptions" needed for the branch ... no changes [23:16] e.g. [23:16] bzr merge xul.dev xul.stable [23:17] edit xul.stable/debian/changelog to point to gutsy et al [23:17] bzr commit [23:17] then work on .sable and try to merge back ;) [23:17] that will work [23:17] i do that all the time between head and dev [23:18] hmm ... i remember that my changes returned to me :) [23:18] I hope to just merge head into dev for final b2 [23:19] what changes do exist on head? [23:19] when was it last merged? [23:20] ok so ... will merging work even to get fixes from stable over dev to head? [23:21] Ubulette: hmm so how far do i need to uncommit the stable branch? [23:22] 58 or something i guess :) [23:22] lol [23:22] ok 107 is relase to universe, right? [23:23] stupid me ... looking at firefox-3 [23:24] i haven't touch main xul branch in ages: http://paste.ubuntu.com/2652/ [23:25] mozilla bug 407077 [23:25] Mozilla bug 407077 in Build & Release "Version/config bump up for Gecko 1.9b2" [Normal,New] http://bugzilla.mozilla.org/show_bug.cgi?id=407077 [23:25] Ubulette: strange [23:26] what ? [23:26] http://developer.mozilla.org/devnews/index.php/2007/12/11/ensuring-compatibility-of-add-ons-and-themes-for-firefox-3/ [23:27] Ubulette: so has your xulrunner-1.9 branch from which you have the paste diverged from the mt one? [23:27] if so, please keep it :) [23:29] i don't know if it's diverged [23:30] can you push what you have to xulrunner-1.9.old? [23:31] i think launchpad should get a switch that disallows to uncommit from branches [23:42] done [23:42] thanks a lot :) [23:43] I remember I uncommited your 50. [23:43] ah ... ok ... so maybe its just that commit? [23:43] ' Revert version change from last commit. We're not at a9 yet. ' [23:43] i just wonder how hard it is to not forget any needed adaption in the one-and-only merge commit :) [23:46] uhh ... there is still galeon in hardy [23:46] i think i won't port that [23:52] i've used galeon for many years, and dropped it when debian refused to fix crashers [23:59] asac, do you really really really want to keep all ppa in .dev ? (especially gutsy/ppa in .dev#80)