[00:00] <fta_> yep
[00:00] <mconnor> nspr_flags_by_pkg_config_hack
[00:00] <mconnor> is there an upstream bug, or a better explanation of what that's trying to fix?
[00:03] <fta> mconnor, it is needed because our tarball for firefox 3.0 is not full, it doesn't have nspr sources
[00:03] <mconnor> you guys and your wacky tarball
[00:06] <fta> mconnor, the goal is to have less bits to upload, it's 10M vs 40M for the full one
[00:06] <mconnor> what all do you take out?
[00:07] <mconnor> that seems like you're tossing a lot of code out of the tarball
[00:07] <fta> hold on
[00:07] <mconnor> I wish you could just point at the mozilla tarball + your patches... seems like it'd be saner than anything
[00:08] <mconnor> oh, yeah, are you guys pulling the know your rights patch in 3.0.5?
[00:11] <fta> http://bazaar.launchpad.net/~mozillateam/mozilla-devscripts/mozilla-devscripts/annotate/head:/src/mozclient/patches/xulbrowser_target.patch
[00:12] <fta> i guess, with 3.0.5, our know-your-rights patch will conflict so it will probably go away
[00:12] <mconnor> oh, right, because you build the app package separate from the xulrunner package
[00:12] <mconnor> it'll definitely conflict :)
[00:14] <mconnor> hmm
[00:15] <mconnor> the don't depend on NSPR sources, couldn't you copy that file from the nspr location when building the source tarball?
[00:16] <mconnor> I'm mildly worried about us making changes to the original that you don't pick up
[00:17] <fta> everything is possible
[00:17] <mconnor> yeah
[00:17] <mconnor> I know
[00:18] <mconnor> I'm just treating this like I treat code reviews
[00:18] <mconnor> if there's a potential for stuff to go wrong, it will almost certainly go wrong
[00:18] <fta> the point here is that when system nspr is requested, configure should not depend on the in-source version of nspr-config, even if it's in the tree, it may have diverged from the real system libs/headers
[00:34] <mconnor> fta: the patch means that configure depends on a specific version of make-system-wrappers.pl from the time of patch creation
[00:34] <mconnor> I'm not sure how that's better
[00:44] <mconnor> mmm
[00:56] <mconnor> fta: what are the jemalloc patches doing?
[00:58] <fta> are they still applied ?
[01:00] <mconnor> oh, I missed that they're commented out of the series patch
[01:00] <mconnor> ok!
[01:00] <mconnor> s/series patch/series file/
[01:01] <fta> i should clean that up
[01:01] <mconnor> bz436133_att322801.patch should be replaced with the patch that landed on 3.1 :P
[01:58] <mconnor> man, this default prefs patch is weird
[05:52] <mconnor> uh.
[05:55] <mconnor> fta / asac : I am confused by how/if part of one of these patches works...
[05:57] <mconnor> oh, nm
[05:57] <mconnor> man I hate this code
[09:57] <asac> mconnor: ok i am back from leave.
[09:59] <asac> mconnor: have to catch up on mail and stuff and then will focus on getting the patches upstreamed to bugs
[10:51] <asac> fta: wanna take a look at one or two extensions from gnomefreak ;)
[10:51] <asac> i think he asked for a merge of firegpg
[10:51] <asac> and has two more new packages in pipeline
[14:38] <asac> @time
[14:39] <asac> @time central
[14:39] <asac> @time US/central
[14:59] <asac> @time
[16:20] <mconnor> asac: http://people.mozilla.com/~mconnor/trademark-review/Ubuntu/Round%201/
[16:21] <mconnor> asac: the "3.0 only" are stuff we have or should upstream
[16:21] <mconnor> the "Needs Discssion" we should talk about :)
[16:42] <[reed]> mconnor: #16 is wrong on your list
[16:42] <[reed]> the prefs are in Firefox's prefs upstream
[16:43] <[reed]> not in Toolkit's
[16:43] <[reed]> that's the problem
[16:45] <fta2> damn, i can't send emails using my corporate address using thunderbird (or evolution), while i can with mutt.
[16:46] <fta2> smtp+auth with tb and evo, NOK. evo with sendmail, NOK. mutt with sendmail, OK.
[16:53] <mconnor> [reed]: mmm, I hate how that's split
[16:53] <mconnor> we need that toolkit prefs file
[16:54] <[reed]> you just hate XULRunner
[16:54] <[reed]> ;)
[16:55] <mconnor> I hate that its something everyone's hacking around stuff
[16:55] <[reed]> instead of filing upstream?
[16:55] <[reed]> I agree with you there
[16:55] <mconnor> it made me sad that only like 1/3 of things were filed
[16:55] <mconnor> and that you'd been the one to file them :_/
[16:56] <mconnor> I mean, this is like 18 months of not bothering...
[16:57] <mconnor> as for 16, well
[16:57] <mconnor> does it need its own prefs file?
[16:57] <mconnor> because, well
[16:57] <[reed]> yeah
[16:57] <[reed]> well
[16:57] <[reed]> we should split out anything in toolkit to a separate prefs file
[16:57] <[reed]> right now, all our apps have to duplicate the same prefs
[16:58] <mconnor> I said that, what, four minutes ago?
[16:58] <mconnor> why are you repeating my bitching? :P
[16:58] <[reed]> I didn't see where you said something like "all our apps have to duplicate the same prefs"
[17:07] <mconnor> [reed]: I said we need to do the toolkit prefs file
[17:07] <mconnor> and, no, we can just stick stuff in all.js
[17:07] <mconnor> that's the current standard
[17:07] <[reed]> we do have non-toolkit apps
[17:08] <[reed]> they might not appreciate that
[17:09] <mconnor> why?
[17:09] <mconnor> you think a few dozen prefs in all.js will impact those embeddors?
[17:10] <[reed]> I dunno
[17:10] <[reed]> maybe?
[17:10] <mconnor> it'd be cleaner, but meh
[17:10] <[reed]> I'll concede I'm making this up as I go.
[17:10] <mconnor> don't do that
[17:10] <mconnor> there's been enough of that to date :P
[17:11] <[reed]> I blame you.
[17:11] <[reed]> anyway
[17:11] <[reed]> :)
[17:11] <[reed]> so, are you coming to UDS? :P
[17:11] <mconnor> don't think so
[17:12] <[reed]> sad
[17:12] <mconnor> eh
[17:12] <mconnor> where's the next one?
[17:12] <[reed]> no idea... will be announced on Friday of this one
[17:12] <mconnor> ah
[17:12] <mconnor> I just don't want to travel any more this year
[17:13] <mconnor> my 40k miles of flying was my limit
[17:13] <fta2> you're not local ?
[17:13] <[reed]> hey, I've done 25k this year, not including this upcoming trip
[17:13] <[reed]> :)
[17:14] <[reed]> Thanks Mozilla and Canonical for footing my travel bills! :)
[17:14] <[reed]> fta2: he's Toronto-based
[17:14] <fta2> oh
[17:14] <[reed]> all the Mikes save one are Toronto-based
[17:15] <[reed]> I don't think we have any Mikes in MV now
[17:15] <mconnor> mmm
[17:15] <mconnor> Mikael Rogers?
[17:15] <[reed]> oh, true
[17:15] <[reed]> but he doesn't go by Mike, afaik
[17:15] <[reed]> could be wrong
[17:15]  * fta2 is throwing thunderbird 3 and evolution through the window
[17:16] <mconnor> 3?
[17:16] <mconnor> bold
[17:16] <fta2> 3 & 2, all the same
[17:16] <[reed]> [10:45:33AM] <fta2> damn, i can't send emails using my corporate address using thunderbird (or evolution), while i can with mutt.
[17:16] <[reed]> [10:46:54AM] <fta2> smtp+auth with tb and evo, NOK. evo with sendmail, NOK. mutt with sendmail, OK.
[17:16] <fta2> out
[17:16] <[reed]> France Telecom doesn't like open source.
[17:16] <[reed]> ;)
[17:16] <mconnor> [reed]: why'd you repaste that?
[17:17] <mconnor> I was just noting that trusting your mail to Tb3 is bold :)
[17:17] <[reed]> ah
[17:17] <[reed]> ok
[17:17] <fta2> i trust ff3.1 for the web
[17:17] <mconnor> yeah, but that's different
[17:18] <mconnor> if I nuke my mail, I can't do my job really
[17:20] <fta2> all the same to me. and i have logs, backups and even copies of my corporate emails.
[17:21] <fta2> i'm going back to mutt for now
[17:21] <fta2> now i remember why i've been using it exclusively since 1996
[17:22] <mconnor> hehe
[17:22] <[reed]> I personally use Sylpheed, as I'm dependent on a GUI-based mail client for some reason... though, Sylpheed is about the only thing that can handle my mail
[17:22] <[reed]> Thunderbird fails miserably
[17:23] <[reed]> considering the amount of e-mail I get faily
[17:23] <[reed]> daily
[17:27] <mconnor> isn't your quantity of mail faily regardless of  your mail client? ;)
[17:28] <fta2> 99.5% of my incoming emails are spam. thanks to greylist/spamd/spamassassin/clamav, i'm just getting ~5% of spam at the end, 5% of 200~300 emails a day, 2/3 of mailing lists & bug tickets. procmail sorts those out, mutt can easily manage the rest.
[17:30] <fta2> asac, the new cairo is in. the next upload of xul will fail to build miserably
[17:31] <fta2> assuming 3.0 has the same problem as 3.1
[18:59] <huayra> hi
[18:59] <huayra> asac
[18:59] <huayra> as I was saying
[18:59] <asac> hi huayra
[18:59] <huayra> I am interested in getting the swahili translation for ff3 going
[18:59] <huayra> I got resources and time for this
[18:59] <huayra> resources as in company backing
[19:00] <huayra> and I have a friend who is going to work with me on this
[19:00] <asac> oh cool
[19:00] <huayra> my question is if it is better to use rosetta or to go the l10n patrh?
[19:00] <asac> is there an official team for that language somewhere?
[19:00] <huayra> there is one, but they have not done anything since 1.0.3
[19:00] <huayra> at least nothing is been released
[19:00] <huayra> a mozilla team
[19:01] <asac> huayra: have you tried to talk to them?
[19:01] <huayra> I have contact with the lead, yes, but it seems to be lots of fractions in that team and nothing constructive coming out
[19:01] <huayra> https://bugzilla.mozilla.org/show_bug.cgi?id=300754
[19:02] <asac> huayra: if the team is somewhat active, it doesnt make much sense to use rosetta. unless the current team would be willing to do that
[19:02] <asac> huayra: how do they maintain their translations?
[19:02] <mconnor> huayra: you should email l10n@mozilla.com and sethb@mozilla.com for help getting things unbusted, IMO
[19:02] <huayra> basically no release has been done since 1.0.3
[19:02] <asac> do they have an (outdated) repository or something?
[19:02] <huayra> that's ages ago
[19:03] <huayra> yeah, I have a link, let me find it
[19:03] <asac> huayra: do what mconnor said. once you know that you can take over the lead you can choose the tool you use to edit the stuff
[19:03] <mconnor> there's a number of good translation tools for Mozilla
[19:03] <asac> i think a requirement is to have a complete translation
[19:04] <mconnor> yes, that is a requirement for being shipped as official, for obvious reasons
[19:04] <huayra> what should we use if we want the ubuntu community to contribute but also make upstream happy?
[19:04] <asac> huayra: rosetta as a tool would helpful if you want to tap the ubuntu translator community
[19:04] <asac> which sounds reasonable if the language is not a "major" one (excuse this word ;))
[19:05] <mconnor> mmm
[19:05] <mconnor> I don't know why you'd translate for Ubuntu only
[19:05] <asac> mconnor: well
[19:05] <huayra> but, if we want to make anyone happy and probably find a "framework" for such *minor* languages
[19:05] <huayra> ?
[19:05] <asac> mconnor: we have lots of translators
[19:05] <asac> mconnor: they all use rosetta. so if you put things in there it gets automatically done ... e.g. you dont need to build your own community
[19:06] <mconnor> asac: that's not really an answer to "why translate only for Ubuntu"
[19:06] <huayra> I want to translate for everyone, not only Ubuntu, but rosetta (lp translations) has its adventages
[19:06] <huayra> so how can we get momentum and make everyone happy?
[19:06] <mconnor> huayra: Axel and Seth can help here
[19:06] <asac> mconnor: most likely a matter of interest
[19:06] <huayra> I want a translated ff3 in all platforms and tap the ubuntu community for its momentum too in the effort
[19:07] <asac> mconnor: people just have to focus on something
[19:07] <asac> like you focus on firefox
[19:07] <mconnor> they're trying in the bug to resolve things, give them a shout, see what they can do
[19:07] <huayra> they have been discussing since 2005. I want some real work done
[19:07] <huayra> not just talking
[19:07]  * mconnor sighs
[19:08] <huayra> I am to use resources so I want results
[19:08] <mconnor> yes, because that localization team is being weird
[19:08] <mconnor> I'm not asking you to talk to to the existing team
[19:08] <huayra> if that means a one man show in rosetta so be it
[19:08] <asac> mconnor: the idea is to do translations in rosetta and find a way to get that shoved over to "official" tree
[19:08] <huayra> but how can we fix things?
[19:08] <mconnor> I'm asking you to ask Seth and Axel for help
[19:08] <huayra> we have contact with the team
[19:08] <mconnor> because that's their job
[19:08] <asac> huayra: yeah. talk to them ... about requirements and stuff
[19:08] <huayra> I am just asking you guys that know the real deal to find a solution
[19:09] <huayra> ok
[19:09] <mconnor> huayra: reading the bug, they've laid everything out
[19:09] <huayra> I will then talk to Seth and Axel
[19:09] <mconnor> the existing "team" doesn't seem to be doing anything
[19:09] <asac> huayra: from rosetta point of view it would be interesting to get input on the exact formatting they require the translations to be done
[19:09] <huayra> yeah, I noticed that
[19:09] <huayra> they just own the team, but no progress is been done
[19:09] <mconnor> so talk to them about restarting with a new team
[19:09] <mconnor> they == who?
[19:10] <mconnor> Seth and Axel are the l10n drivers for Mozilla, they coordinate l10n across all locales
[19:10] <huayra> I was thinking of the team, not of S & A ;)
[19:10] <huayra> so in conclusion
[19:10] <asac> mconnor: they == Seth + Axel (and mozilla in general)
[19:11] <asac> (if you asked for my they ;))
[19:11] <huayra> is it possible to use rosetta and still get a usable translation for the upstream mozilla guys, or not?
[19:11] <asac> huayra: it is possible. if there are things that need to be fixed, we will certainly do that
[19:11] <huayra> isn't rosetta just handling the PO files anyway?
[19:11] <asac> its quite important for us to make things suitable for that
[19:12] <asac> huayra: firefox doesnt have po files
[19:12] <mconnor> heh
[19:12] <huayra> ok
[19:12] <huayra> I reckon I will just talk to Axel and Seth and find out
[19:12] <mconnor> ok
[19:13] <huayra> thank you very much guys
[19:13] <asac> huayra: its using xpi ... which is why its a bit more difficult. but rosetta has (beta) support for that. its just that we need more real-life
[19:13] <asac> to streamline stuff ;)
[19:13] <huayra> so this could be a nice opportunity?
[19:13] <asac> huayra: welcome
[19:13] <asac> huayra: for sure.
[19:13] <huayra> I mean to test the xpi support?
[19:14] <asac> huayra: right.
[19:14] <mconnor> er
[19:14] <huayra> ok, interesting
[19:14] <mconnor> it uses XPI for langpacks, yeah
[19:14] <mconnor> but that's the package format, not the output format
[19:15] <asac> mconnor: yeah. thats understood. its used as a synonym here.
[19:15] <huayra> yeah, xpi like in add-ons files
[19:15] <mconnor> as long as it outputs something that matches the in-tree format so we can get it upstream, great
[19:15] <huayra> so, what do we do?
[19:15] <mconnor> huayra: that's your call
[19:15] <mconnor> huayra: talk to the experts though :)
[19:16] <huayra> shall I try to get thing s working with the team and see if we vcan use rosetta, or just import the whole thing from mozilla when the translation in their terms is done?
[19:16] <asac> huayra: first sort out the admin stuff. then review the tools available on the market and decide
[19:16] <huayra> what are thos e tools?
[19:16] <mconnor> huayra: Axel and Seth can give better recommendations
[19:17] <huayra> can you maybe point me to the tools that are used by other localization teams please
[19:17] <huayra> ok
[19:17] <huayra> where do I find those guys?
[19:17] <huayra> #mozilla ?
[19:18] <mconnor> I'd email them
[19:18] <mconnor> and they're not likely on freenode
[19:18] <mconnor> sethb@mozilla.com and l10n@mozilla.com
[19:18] <mconnor> Axel's in Germany, Seth's in California
[19:19] <huayra> thnks so much :)
[19:19] <asac> omg ... my mailqueue was down again :(
[19:19] <asac> thats scary when you dont know which mails didnt go out for how long :(
[19:32] <huayra> do you guys know how many string FF3 has?
[19:33] <asac> huayra: i can look ;)
[19:33] <mconnor> asac: focus on looking at the big set of patches I have issues with, please :)
[19:33] <mconnor> huayra: around 2k, at last check
[19:34] <asac> 1893 messages + 3821 messages
[19:34] <mconnor> 5k?
[19:34] <mconnor> 6k?
[19:34] <asac> yeah
[19:34] <mconnor> huh
[19:34] <mconnor> maybe
[19:34] <mconnor> I don't remember it being that high
[19:35] <mconnor> but I don't translate :)
[19:35] <mconnor> asac: you saw my link?
[19:35] <asac> mconnor: yes.
[19:36] <asac> mconnor: i will start to push bugs tomorrow. 2h a day ... should be just a few days.
[19:36] <asac> mconnor: needs discussion should then be done in bugs
[19:37] <asac> mconnor: good enough?
[19:37] <asac> mconnor: [reed] already pointed out that 16 is required to move some classifier settings to toolkit
[19:40] <mconnor> asac: there's better ways to do that than adding another file to parse, fwiw
[19:41] <huayra> so 3800 strings?
[19:41] <huayra> or just 2k?
[19:41] <huayra> kind of fell off the conversation... ;)
[19:42] <asac> huayra: 3800 (toolkit) + 1600 (browser)
[19:42] <asac> er 1800
[19:43] <huayra> asac excuse my ignorance. I want FF3 translated and all translators speak English. Do I need to strictly translate just 1600 or do I need the toolkit translated as well?
[19:44] <asac> huayra: toolkit is required
[19:44] <huayra> so 5400 strings is the translation requirement?
[19:44] <asac> yes about that amount
[19:44] <huayra> thx
[19:44] <huayra> :)
[19:44] <asac> 5600
[19:46] <armin76> lol
[19:47] <mconnor> asac: filing upstream bugs is the good first step, yeah
[19:47] <mconnor> asac: some of this stuff is, well, unnecessary
[19:49] <mconnor> asac: my biggest question was that in a couple of the patches you changed stuff inside of OSX #ifdefs, what was up there?
[19:50] <asac> mconnor: most likely i tried to make the patch complete ... if that completely doesnt make sense for OSX i was just wrong ;)
[19:51] <mconnor> asac: also, having a patch start with "supposedly this does X" is not ever something I want to see
[19:51] <mconnor> ever
[19:51] <mconnor> either it works or it doesn't :P
[19:51] <asac> mconnor: which patch is that?
[19:51] <asac> the debian compatibility thing?
[19:52] <mconnor> yeah
[19:54] <asac> mconnor: i wanted to write "i hate debian for this" there ;) ... and ended up with a more political wording.
[19:54] <asac> mconnor: the patch obviously works ... otherwise it wouldnt be in there ;)
[19:54] <mconnor> why take it then?
[19:54] <asac> mconnor: background: we packaged xulrunner 1.9 and firefox 3.0 more than 6 month before debian did it.
[19:55] <asac> mconnor: then they started to make life miserable by doing some slightly different decisions
[19:55] <mconnor> asac: so, fun fact
[19:56] <asac> mconnor: problem is that when debian says we install stuff at place X ... then all the packages that we automatically sync would either not work
[19:56] <asac> or we would have to maintain a diff for them
[19:56] <mconnor> man
[19:56] <mconnor> you guys should stop depending on Debian
[19:56] <asac> mconnor: and thats what debian guy did ;)
[19:56] <mconnor> would make life so much easier
[19:56] <asac> mconnor: after he noticed that i work for canonical :)
[19:57] <asac> mconnor: previously debian xulrunner (1.8) had a patch system ... for 1.9 he eliminated that and now maintains stuff in a private git archive
[19:57] <mconnor> man
[19:57] <asac> mconnor: so when i want to understand what they did i have to look at the monolithic diff.gz
[19:57] <mconnor> I'm having flashbacks
[19:58] <mconnor> to the monolithic firefox-1.5 diff
[19:58] <mconnor> :P
[19:58] <asac> mconnor: firefox 3 is still monolithic. but thats eric as you might remember
[19:58] <asac> mike agreed for ages that we want individual patches
[19:58] <asac> until i started on ubuntu ;)
[19:58] <mconnor> man...
[19:58] <mconnor> those guys
[19:59] <mconnor> so Mike has a private git repo, with a monolithic diff
[19:59] <mconnor> and Eric has a private SVN repo, or something, with a monolithic diff
[19:59] <asac> mconnor: yeah ;)
[19:59] <asac> mconnor: i think eric has a public git now
[19:59] <asac> ;)
[19:59] <mconnor> quality software practices there
[19:59] <mconnor> lots of transparency
[20:00]  * mconnor mumbles something about openssl under his breath
[20:00] <asac> mconnor: eric doesnt understand. mike does, but wants to pretend he doesnt understand :)
[20:00] <asac> mconnor: yeah. definitly a good example that we need to be much more skeptical about what debian does
[20:01] <asac> mconnor: of course its somehow unique. the majority of debian folks are quite good
[20:01] <directhex> pkg-mono are nice!
[20:01] <asac> problem is that they are no team players
[20:01] <asac> everybody focusses on his pet-package
[20:01] <mconnor> asac: yeah, I've noticed
[20:01] <mconnor> and they think they're experts
[20:01] <asac> and only cares about other things when it becomes a pain to locally workaround
[20:02] <mconnor> that's my real worry with downstream
[20:02] <mconnor> especially with mozilla, where we have too many dark corners
[20:03] <mconnor> its just not sane to assume that 1-2 maintainers will know the right way to implement something
[20:03] <mconnor> "Just because it works, doesn't mean its the right solution."
[20:04] <mconnor> and stuff where you're adding features that only work in Ubuntu is sadmaking
[21:09] <wiki> fta: Hi
[21:16] <fta> wiki, hi
[21:16] <wiki> the patches in the debian/patches dir,how are they made ?using quilt ?
[21:19] <fta> quilt new my_new_patch.patch
[21:19] <fta> quilt add mozilla/some/file1
[21:19] <fta> quilt add mozilla/some/file2
[21:19] <fta> quilt diff
[21:19] <fta> quilt refresh
[21:19] <fta> that's the basics
[21:20] <wiki> :)
[21:20] <wiki> fta: we released spicebird on 21st
[21:21] <fta> excellent
[21:23] <fta> of course, you need to edit your files *after* the corresponding add and *before* the refresh
[21:26] <wiki> fta: once i upload the files in lp via dput ,they get built themselves ?
[21:26] <fta> do you mean in a ppa ?
[21:26] <wiki> yeah
[21:27] <fta> then yes
[21:40] <wiki> fta: how long do these virtual monsters take ?40~45 minutes ?
[21:47] <paran> hi. I have for my personal use patched the flashplugin-nonfree package to download and install the new naitive 64bit plugin on amd64.
[21:48] <paran> i will send my patch to bug 299146, but what do you think would be a good version number?
[21:48] <paran> right now I use 10.0.12.36ubuntu2~10.0.d20.7 (where 10.0.d20.7 is the amd64 version)
[21:51] <asac> wiki: they start to build quite instantly
[21:52] <asac> wiki: then the take the time they need and then it takes about 30 minutes until you can access the .debs
[21:52] <wiki> asac: cool
[21:52] <asac> paran: we will discuss during UDS how to properly package stuff up
[21:52] <asac> paran: we still want the nspluginwrapper option as we also use that for i386 to prevent crashes of core firefox
[21:53] <wiki> asac: we use ccache and disctcc on dual core debian etch with j8 flags to build our moz builds. It takes around 10 minutes :)
[21:54] <asac> wiki: if its more or less a full mozilla the builds usually take 25-30 minutes
[21:54] <asac> if you do more... add something on top ;)
[21:55] <wiki> asac: to make a deb for hardy,will it be called a backport ?
[21:56] <paran> asac: you mean use nspluginwrapper for all plugins on al arches then?
[21:56] <wiki> what if I mention as hardy in the changelog ,how will ppa interpret it ?
[21:56] <asac> paran: yes ... (optional for user)
[21:57] <asac> paran: so when amd64 is final we will not use nspluginwrapper for cross-arch ... only for out-of-process stuff
[21:57] <asac> paran: but what we want in the long run will be discussed during UDS
[21:57] <asac> (and how to achive that)
[21:57] <asac> paran: so atm if you install flashplugin-nonfree and have nspluginwrapper installed on i386 it will use nspluginwrapper
[21:58] <paran> asac: ok. if you do that then please make it on a per plugin basis. the current code always uses nspluginwrapper if it is installed
[21:58] <asac> if you dont have nspluginwrapper it will not use it
[21:58] <asac> paran: thats one of the points that is not yet clear
[21:58] <paran> asac: I will want naitive flash, but might need the wrapper for other 32bit only plugins
[21:58] <asac> paran: any ideas how the user is supposed to manage that?
[21:59] <asac> we will discuss, but getting more ideas up-front will be helpful i guess
[22:00] <paran> you could install both wrapped and unwrapped as alternatives
[22:00] <paran> so you could use update-alternative to select
[22:03] <paran> asac: I will put the nspluginwrapper code I ripped out back into my package. :) did you have any idea about the version name?
[22:04] <asac> paran: depends on where this will end up
[22:04] <asac> paran: update-alternative has to die imo :)
[22:04] <asac> paran: but the idea of having both installed is nice
[22:08] <paran> asac: hehe, why? I think alternatives is really useful, once you learn how to use it.
[22:09] <paran> asac: I just want to put some sort of sane version number before I send the patch in.
[22:11] <paran> even if you decide to change how stuff work some of my (small) patch might be usefull, like downloading different tarballs dependin on arch
[22:13] <asac> paran: we dont need alternatives anymore. you can currently pick one out of many available plugins in ubufox ... this will hopefully later go into the main firefox UI
[22:13] <asac> paran: like: http://people.ubuntu.com/~asac/tmp/alt1.png
[22:13] <asac> paran: http://people.ubuntu.com/~asac/tmp/alt2.png
[22:14] <asac> paran: we would get two entries there for adobe: 1) adobe (native) 2) adobe (nspluginwrapped)
[22:17] <paran> asac: that would be nice.
[22:18] <asac> paran: yeah. i like it too. only problem we have to sort is that when you install nspluginwrapper post-mortem we would have to wrap already installed plugins too
[22:18] <asac> but that can be done quite diligently i think
[22:19] <asac> (currently the wrapped stuff is only generated when you install flash after nspluginwrapper)
[22:19] <paran> yeah, I know :)
[22:19] <paran> however I would recommend keeping the alternatives link in addition to ubufox. there are other browsers that would need that
[22:20] <asac> paran: not sure. its really just clutter. konqueror does that on their own anyway
[22:20] <asac> epiphany is a use-case agreed
[22:20] <asac> but then ... thats a missing feature in epiphany i guess and in the long run it will use nspluginwrapper
[22:21] <asac> err
[22:21] <asac> it will use webkit ;)
[22:21] <asac> thats what i wanted to say
[22:21] <asac> but well
[22:21] <asac> alternatives dont hurt for this mechanism
[22:21] <asac> its just that they regularly break on users system
[22:29] <paran> would have been better if it were more integrated with dpkg, is is easy to mess it up with postinst/prerm scripts
[22:32] <asac> paran: maybe. but dpkg is from hell ... so fixing that there isnt easy either ;)
[22:32] <paran> anyway, please don't remove the alternative for plugins unless you at least get the plugin chooser into the "normal" firefox package.
[22:32] <asac> paran: also even if you do it right, alternatives have strange behaviour
[22:32] <asac> for instance if you --remove the last option it will remember that you selected nothing and when -install a new alternative it will not select the only one that exists then.
[22:32] <paran> I don't install ubufox because it pulls in a ton of gnome stuff
[22:33] <asac> paran: thats a different issue
[22:33] <asac> apturl needs to be fixed
[22:33] <asac> but yeah
[22:33] <asac> but as i said. this stuff is so cool that it belongs in the main firefox UI anyway
[22:35] <paran> :)