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