[00:16] <gnomefreak> Jazzva: ok im heading to bed let me know what you find out if anything, i was building on intrepid so maybe that is why?
[00:16] <gnomefreak> i think i was
[00:16] <gnomefreak> good night
[00:17] <Jazzva> hmm, i'm trying on intrepid too. it reports 1 new addon is installed, but it doesn't show up. I'll look into it more
[00:17] <Jazzva> Good night, gnomefreak
=== Admiral_laptop is now known as Admiral_Chicago
[08:58] <asac> hi.
[10:46] <armin76> asac: mozilla bug 436133 :)
[10:46] <ubottu> Mozilla bug 436133 in Networking: Cookies "Cookies build failure on hppa" [Normal,Assigned] http://bugzilla.mozilla.org/show_bug.cgi?id=436133
[11:03] <asac> armin76: so its ok to not complain about base aligned casts?
[11:04] <asac> s/base/bad/
[11:06] <armin76> asac: i have no clue
[11:28] <armin76> asac: with the patch i did? yeah, it compiles
[11:29] <asac> armin76: and starts?
[11:36] <armin76> asac: yeah
[13:25] <jeroen-> asac: I see that only xulrunner RC1 packages are in hardy-proposed, but not firefox RC1 packages. Will that not give problems; mixing b5 and rc1? For me it doiesnt matter because I have the rc1 packages from launchpad installed.
[13:31] <asac> jeroen-: upgrading should not be possible before both arrived
[13:31] <asac> if you can upgrade using update-manager or apt-get upgrade let me know
[13:32] <asac> dist-upgrade might remove your firefox packages though :/
[13:32] <jeroen-> asac: ah ok, thats why it was updating for me, because I have the rc1-packages from launchpad.
[13:32] <asac> jeroen-: the packages were just uploaded. will take another two hours or so until all is build
[13:32] <jeroen-> ok :-)
[13:32] <asac> jeroen-: yes, that should work
[13:32] <jeroen-> great
[13:34] <armin76> feature!
=== asac changed the topic of #ubuntu-mozillateam to: https://wiki.ubuntu.com/MozillaTeam | Mailing List: ubuntu-mozillateam@lists.ubuntu.com | Mozilla QA tracker https://mozilla.qa.stgraber.org/ => please subscribe to help out | firefox 3 rc1 in intrepid and hardy-proposed | firefox 3 blockers left: http://tinyurl.com/5cdqvp
[15:05] <jetsaredim> asac: what's the story with the firefox packages?
[15:05] <asac> jetsaredim: which packages?
[15:05] <asac> RC1?
[15:06] <jetsaredim> got a list of upgrades this morning for hardy and its set to remove firefox
[15:06] <asac> jetsaredim: where do you see that?
[15:07] <asac> jetsaredim: what are you running?
[15:07] <asac> apt-get dist-upgrade?
[15:07] <jetsaredim> just using the tray tool
[15:07] <jetsaredim> for kubuntu
[15:07] <jetsaredim> but yea - that's probably what its running
[15:07] <asac> update-manager shouldnt propose removal of packages, instead hide them as partial upgrades
[15:08] <asac> if kubuntu behaves differently then thats a problem
[15:08] <jetsaredim> i think its related to xulrunner update
[15:08] <asac> jetsaredim: well ... the _all package is not yet there as amd64 has finished to build i guess
[15:09] <asac> thus the firefox meta package is not yet available and a dist-upgrade might try to resolve this by removing firefox package
[15:09] <jetsaredim> fun
[15:09] <jetsaredim> ok
[15:09] <asac> but that shouldnt happen using the GUI tools nor the apt-get upgrade
[15:09] <asac> please dont remove, but wait another hour or so
[15:09] <asac> keep me updated if that goes away
[15:10]  * asac short break
[15:20] <jeroen-> is there a way I can find out what the difference are between the build  oof Fx3rc2 in ppa.launchpad and the one in the hardy-proposed repo?
[15:20] <jeroen-> just out of curiousity
[15:21] <jeroen-> Fx3rc2=Fx3rc1
[15:22] <asac> jeroen-: you need to inspect the upstream changes
[15:23] <jeroen-> asac: ok, and where do I do that?
[15:23] <asac> jeroen-: packaging changes should be rare, but documented in debian/changelog
[15:23] <asac> jeroen-: bonsai.mozilla.org?
[15:23] <jeroen-> ok
[15:23] <asac> there you can see what was checked in
[15:23] <jeroen-> great
[15:23] <asac> or diff the two orig.tar.gz balls
[15:23] <asac> maybe you can find RC1 changes upstream somewhere
[15:23] <asac> to get a prepared list of changes
[15:24] <asac> not sure though if that was drafted yet
[15:24] <asac> err, RC2 i mean
[15:24] <jeroen-> rc@?
[15:24] <jeroen-> rc2?
[15:24] <jeroen-> well there be a rc?
[15:24] <jeroen-> another rc
[15:24] <asac> yes
[15:24] <asac> rc2
[15:24] <jeroen-> ok
[15:24] <asac> next week
[16:07] <armin76> fta: apply my patch!
[16:14] <fta> ...
[16:33] <armin76> fta: noes?
[16:33] <fta> lack of context
[16:34] <armin76> mozilla bug 436133
[16:34] <ubottu> Mozilla bug 436133 in Networking: Cookies "Cookies build failure on hppa" [Normal,Assigned] http://bugzilla.mozilla.org/show_bug.cgi?id=436133
[18:01] <jimmy_> asac: ping
[18:05] <asac> jimmy_: hi
[18:05] <asac> currently chatting in #ubuntu-mobile
[18:06] <asac> jimmy_: what about?
[18:09] <asac> jimmy_: ill drop out for a few hours (i think 2-3) ... lets chat then. If my ssh keys are in already let me know, so i can update the packaging branches
[18:12] <jimmy_> asac: i'll ping the admin again
[18:12] <asac> thanks
[18:13] <asac> sorry, for the hurry, but i want the midbrowser bits go up to proposed asap. all other bits are already pushed there and wait for final ack before the whole ball gets rolled to -updates (aka the world masses)
[18:13] <asac> all this will hopefully become unnecessary once xulrunner 1.9 is final :/
[18:14] <asac> no more breakage during merges (well in theory), speak: paradise :)
[18:17] <jimmy_> asac: ok, i'll ping you later on the XDC directory stuff when you are back, I can't get it working :(
[18:20] <asac> jimmy_: yes. feel free to write the problem in the meantime ... ill read the backlog
[18:20]  * asac now out
[18:45] <jimmy_> asac:           var dirSvc = Components.classes["@mozilla.org/file/directory_service;1"]
[18:45] <jimmy_>                                  .getService(Components.interfaces.nsIProperties);
[18:45] <jimmy_>           var profileDir = null;
[18:45] <jimmy_>           try {
[18:45] <jimmy_>             profileDir = dirSvc.get("ProfD", Components.interfaces.nsIFile);
[18:45] <jimmy_>           } catch (e) { }
[18:45] <jimmy_> asac: i used the above code and I can get the profile directory without problems
[18:46] <jimmy_> but I couldn't get any of the XDC directories, what string literals should I put in?
=== jt1 is now known as jtv
[19:09] <asac> jimmy_: but didnt the same code work in the javascript case?
[19:11] <asac> jimmy_: what is needed to claim "xulrunner-1.9 support" ?
[19:11] <asac> available in hardy, hardy-updates, hardy-security or mobile PPA?
[19:12] <asac> jimmy_: point is xulrunner-1.9 RC1 is in hardy-proposed which your builds might not catch
[19:12] <asac> jimmy_: but without midbrowser in hardy-proposed it will not rolled to -updates
[19:12] <asac> so its a chicken egg thing
[19:12] <asac> jimmy_: once my keys are in I can merge to master, hardy then bake release and upload to -proposed
[19:13] <asac> i see no other way of doing this.
[19:13] <asac> jimmy_: we might face similar situations in future, so either you have to accept a few days breakage of hardy/master branch or we have to figure out how we can bring the -proposed packages to your build
[19:14] <asac> cwong1: ^^^ maybe intersting for you to read as well
[19:18] <asac> jimmy_: run xdg-user-dir VIDEOS on the system and see what it prints
[19:18] <asac> does it give you the right directory?
[20:30] <asac> ok nickserv fixed :-D
[20:45] <asac> rebooting my irssi server
[20:46] <asac> lets press thumbs that this old thing comes up again :)
[20:46] <gnomefreak> only reason it wouldnt is if your running intrepid and didnt respin it with new perl
[20:47]  * gnomefreak not really here working on an unbrella diagram
[20:47] <armin76> asac is having fun :D
[20:56] <asac_> james_w: is there a spec draft for distributed development in wiki yet?
[20:56] <asac_> james_w: maybe i can add the notes i have from our discussion to a scratchboard section so you can consider those thoughts while drafting?
[20:56] <james_w> https://wiki.ubuntu.com/DistributedDevelopment/ImporterSpecification
[20:56] <james_w> yes, please do.
[20:57] <asac_> james_w: to what extend does this cover the topics we talked about like "coupling of ubuntu releases with upstream revisions/branches"?
[20:58] <asac_> james_w: what is a "revision spec" ?
[20:58] <asac_> tag?
[20:58] <asac_> bzr diff -r package:0.3.2-1..package:0.3.2-1
[20:58] <asac_> ?
[20:58] <james_w> that's more advanced than this spec, but if you stick your thoughts in there I will make sure they are taken account of, and will move them to appropriate specs when they come along.
[20:58] <asac_> ok
[20:58] <james_w> a revisionspec is anything you can pass to the -r option, e.g. tag: revid: date: etc.
[20:59] <james_w> "bzr help revisionspec" lists them all
[20:59] <asac_> and in our case its just a tag with syntax?
[20:59] <asac_> or is that something more generic that wades through commits and picks the topmost commit with that changelog version
[20:59] <james_w> yeah, it will resolve to a revision via a tag.
[21:00] <james_w> no, that would be a lot slower, so if we can use tags we should, a tag is just a dictionary lookup.
[21:00] <asac_> james_w: ok but the tag could be set automatically during ubzr commit ;)
[21:00] <asac_> or maybe ubzr release
[21:00] <asac_> :)
[21:00] <james_w> yep, that's the idea
[21:01] <asac_> james_w: ok, from what i see there is not much specified about importing upstream branches
[21:01] <asac_> well not really upstream, but rather orig.tar.gz
[21:01] <asac_> branches if you want to track debian for instance
[21:02] <james_w> nope, Debian is the next stage, with upstreams some time after that.
[21:02] <asac_> james_w: but arent orig.tar.gz relevant independent from debian/upstream/ubuntu ?
[21:02] <asac_> or are we going native by default for now?
[21:02] <james_w> but for the extension stuff, which I imagine won't be in Debian for the most part, we could have something that does the upstream imports using these branches.
[21:03] <james_w> oh yeah, I see what you mean, I've ignored that, I should add it in, thanks.
[21:03] <asac_> james_w: yes, i think managing the orig.tar.gz + package branch is the most interesting part of that spec.
[21:03] <james_w> there are branches for the .orig.tar.gz imports (though they may not be accessible directly, but you can easily extract them from the packaging branch)
[21:04] <asac_> james_w: extract them from the packaging branch?
[21:04] <asac_> how?
[21:04] <james_w> there will be a command to extract the branch, add the new version, and then merge it in
[21:04] <james_w> you can extract them with "bzr branch", you just need to know the revision to grab
[21:04] <asac_> err, how can i get the pristine upstream branch out of a ubuntu branch?
=== asac_ is now known as asac
[21:07] <james_w> there will probably be some sort of "upstream:" revisionspec so you could do "bzr branch -r upstream:1.2" to get it.
[21:07] <asac> james_w: you say i can extract the upstream source merged into the https://code.edge.launchpad.net/~ubuntu-dev/firefox-extensions/firebug.ubuntu at revision 19 without looking at .upstream ?
[21:08] <asac> https://code.edge.launchpad.net/~jetsaredim/firefox-extensions/firebug.upstream
[21:08] <asac> i think thats the upstream branch
[21:08] <asac> how can i get it from the .ubuntu branch?
[21:08] <asac> james_w: wow. thats pleasent
[21:09] <asac> it really worked like bzr branch -r 1.1.2 firebug.ubuntu test.1234
[21:10] <james_w> yup
[21:10] <james_w> we just have to be careful to make it clear that the .upstream branches should not be committed to except for upstream releases/snapshots.
[21:11] <asac> james_w: ok, but in case the auto merge fails we wont have a chance to merge manually if we dont have the upstream branch on the net.
[21:11] <asac> james_w: yes, thats for sure
[21:11] <james_w> I don't want to make them too visible, and I want to handle them automatically, but I can certainly see the value in being able to access them
[21:11] <asac> james_w: but we should be able to read the "auto-imported" branches
[21:11] <asac> james_w: why hide them?
[21:11] <asac> if they are in a read-only area that should be fine imo
[21:12] <james_w> ah yeah, for auto merge you will need to make them public, that's true.
[21:12] <asac> james_w: s/auto/manual/ => i agree
[21:12] <asac> ok sounds promissing
[21:13] <james_w> they can't be read-only as you need to write to them for new upstream releases, but things like fixing bugs directly in the upstream branch is wrong.
[21:13] <asac> if we can do upstream branch maintenance outside the auto thing that would be even better ... e.g. we could do our own ~extension-upstream team that receives only auto updated .xpi's
[21:13] <james_w> oh yes, sorry, for manual merges if the auto merge fails.
[21:13] <asac> james_w: right. i thought that we get auto import of new origs right from the beginning
[21:13] <james_w> oh no, that requires too much of launchpad currently.
[21:14] <james_w> we could perhaps scripts something on the side using watch files
[21:14] <asac> james_w: ok, but can we provide hooks that the distro team can maintain on their own to pull in from different sources, using different code?
[21:14] <james_w> and I'd like to get it working for your .xpis which will be a good prototype.
[21:14] <asac> yes, something like watches ... but maybe more flexible
[21:14] <james_w> I'm not sure what you mean by hooks.
[21:14] <asac> awesome
[21:15] <asac> james_w: i think its what you propose: the ability to deploy new scripts
[21:15] <asac> easily
[21:15] <asac> at best inside the package (like watch files)
[21:16] <asac> so we dont need to request launchpad changes for each and every new upstream source
[21:16] <asac> no idea if thats possible by policy though
[21:16] <james_w> ah, what I meant by launchpad changes is that they want to have links to every upstream project, and a way to watch for new releases of that project.
[21:17] <james_w> in the long term we would hook in to that for notification.
[21:17] <asac> james_w: so is there anything we can start to do without having the auto-build in launchpad feature?
[21:17] <james_w> we can certainly do our own thing in the mean time.
[21:18] <james_w> I can see that the auto-build would be great for your large scale maintenance, in the mean time we can set up all the infrastructure and write some commands that act like it would be autobuilt, but instead dput to the archive.
[21:18] <asac> james_w: yes, thats what i mean
[21:19] <james_w> that's basically what's going to happen across the distro until the auto-build is available.
[21:19] <james_w> we will want to have a command that does it all, so when it's all available we just switch the dput part off.
[21:19] <asac> ack
[21:19] <asac> well ... maybe soyuz wants to run dput locally even ;)
[21:20] <asac> who knows
[21:20] <james_w> heh, yeah, but that's their problem.
[21:20] <james_w> one thing that we haven't solved yet (well, not that I've heard) is the trust thing
[21:21] <james_w> if a build is triggered by a push then it is just relying on ssh keys, rather than gpg keys.
[21:21] <asac> james_w: in our largescale thing design we require some kind of authoritive seed that enables extension auto import
[21:21] <asac> james_w: i guess we probably need somethign similar for the distro wide thing too
[21:22] <asac> e.g. some config branch where only archive-admins can commit to
[21:22] <james_w> you mean the list of extensions you want to package?
[21:22] <asac> james_w: yes, the extensions that were approved to get auto orig syncs and merge attempts ;)
[21:23] <asac> and in the meantime an authoritive list about what can be uploaded from where
[21:23] <james_w> ah, ok, we can probably just use a text file stored in bzr on launchpad that it pulls before working.
[21:23] <asac> james_w: i think we have two stages of approval here: 1st. upstream source import -> review license and general quality
[21:23] <asac> 2nd. packaging review before letting the initial package in
[21:24] <asac> 3rd. binary review, but that is properly served by the current binary NEW review process imo
[21:24] <james_w> yup, I think we can make that work.
[21:24] <asac> so three stages, out of which the first two ones need a new bzr driven model
[21:27] <asac> james_w: one step back. if i tag a release on a .upstream branch ... merge that into the .ubuntu branch, can i then get the upstream branch from .ubuntu branch by using that tag?
[21:28] <james_w> yep
[21:28] <james_w> "bzr branch -r tag:whatever . ../upstream"
[21:30] <asac> james_w: decent
[21:34] <jimmy_> asac: back from lunch
[21:38] <asac> jimmy_: ok
[21:38] <asac> go ahead
[21:39] <jimmy_> asac: i sent the admin another email already, but seem like he might be out on vacation or something
[21:39] <asac> jimmy_: unfortunate
[21:40] <asac> jimmy_: so whats the problem with XDG :) ?
[21:41] <jimmy_> asac: Carl doesn't want me to check anything major in the master branch while he's gone, :(  so I think it would be better for him to come back to do the upgrade to rc1, i think it would be fine to do the hardy branch tho
[21:41] <asac> jimmy_: when will he come back?
[21:41] <jimmy_> monday
[21:42] <jimmy_> he said he'll check his email tho and can respond if neccessary
[21:42] <jimmy_> because he's not really out of town
[21:42] <jimmy_> but he haven't responded yet
[21:43] <asac> ok lets hope he responds
[21:44] <jimmy_> asac: so with the XDG stuff, I thought that you said the XDG logic is already integrated in firefox, so that i can look up the XDG directories, i tried xdg-user-dir VIDEO, and it just prints my home directory, so how do you really enable XDG in firefox?
[21:45] <asac> jimmy_: try xdg-user-dir MUSIC
[21:45] <asac> if that works, it should work in general
[21:46] <jimmy_> asac: ok, MUSIC works
[21:46] <asac> jimmy_: could you show me the code you actually used?
[21:47] <asac> you only posted the ProfD code
[21:50] <jimmy_> asac: http://paste.ubuntu.com/15638/
[21:53] <jimmy_> am i not using the right string literals? something other than XDG_MUSIC_DIR?
[21:53] <asac> jimmy_: the macros are wrong
[21:54] <fta> asac, [reed], https://cube.sofaraway.org/gallery/main.php?g2_itemId=26
[21:54] <asac> jimmy_: to get the proper ones do a grep XDG_ xpcom/io/nsDirectoryServiceDefs.h
[21:54] <asac> fta: yeah ... are all pics from you?
[21:55] <fta> asac, yes, except the 2 group pics
[21:55] <asac> yeah
[21:55] <asac> cool
[21:56] <asac> jimmy_: ok, think thats going to work
[21:56] <asac> great
[21:56] <asac> :)
[21:57] <jimmy_> asac: ok, let me try those
[21:57] <asac> jimmy_: i think you need to #ifdef XP_UNIX your code additions to make them feasible for upstream
[21:58] <asac> ah you did ;)
[21:58] <asac> good
[21:59] <asac> jimmy_: why is the code to test "bymimetype" not in the same hunk as the other changes?
[21:59] <asac> jimmy_: ok. some nifty clean ups:
[22:02] <asac> maybe browser.download.autoXdgDir
[22:02] <jimmy_> asac: i can clean it up a bit after i get it working, because i just re-used the old code i did earlier
[22:02] <asac> ok fine
[22:02] <asac> its mostly that the variables should match the code style
[22:03] <asac> like bymimetype -> byMimeType
[22:03] <asac> and maybe useXdgTarget or somethign instead :)
[22:04] <asac> but thats micro thing ... upstream certainly will have their own ideas ;)
[22:08] <asac> james_w: ok i am scripting some skeletons; should we use debian/rules expose the API required to hook in upstream updates?
[22:08] <asac> james_w: like: ./debian/rules orig-stable-upgrade-available :)
[22:09] <james_w> how much do these vary across the extensions?
[22:09] <asac> james_w: well ... most come from addons.mozilla.org
[22:09] <asac> we have a script that parses that
[22:10] <asac> and we can certainly get the info about current packaged version, latest addons.mozilla.org release versino out of that
[22:10] <asac> the other case is that there are extensions packaged from svn. but for now i am fine to ignore them
[22:10] <james_w> the problem with putting it in debian/rules is if script was required to change for a new upstream release.
[22:11] <james_w> so, would you be able to write a script that got the any new .xpi given just the extension name?
[22:11] <james_w> or would it be too extension specific for that?
[22:12] <asac> james_w: yes.
[22:12] <fta> mozilla bug 435959
[22:12] <asac> james_w:  we could maintain "plugins" for certain upstream methods (e.g. debian, manual, AMO). the AMO script could then implement that.
[22:12] <ubottu> Mozilla bug 435959 in Security: PSM "Firefox 3 RC 2 should take NSS 3.12 RC 4" [Normal,Resolved: fixed] http://bugzilla.mozilla.org/show_bug.cgi?id=435959
[22:13] <asac> james_w: and packages could specify Xs-Upstream-Method: AMO
[22:13] <asac> in control
[22:13] <james_w> asac: if it's not one method per extension then I think keeping it out of the package would be good
[22:13] <james_w> ah, that could work well.
[22:13] <asac> james_w: yes. i like the idea to maintain a set of methods outside the package that can be used
[22:13] <asac> by packages
[22:14] <james_w> though if we have a file that lists the extensions that are approved, then it may make sense to put the information in there.
[22:14] <asac> james_w: hmm
[22:14] <james_w> so that we don't have to have a package already for the initial import
[22:14] <james_w> or is the initial import going to be done completely by hand?
[22:14] <asac> james_w: good point. however, i'd like to keep the "master list" as stupid as possible
[22:14] <asac> if you want to do things locally having that info in the control file would be helpful i guess
[22:15] <james_w> what are the chances of a plugin changing method?
[22:15] <james_w> would you for instance switch to svn if you wanted a snapshot?
[22:15] <asac> james_w: depends. if the upstream area is not writable for human beings we need to bootstrap through that master/seed file. otherwise doing by hand would be possible
[22:15] <asac> james_w: yes, a switch is unlikely, but we should consider this imo
[22:15] <asac> james_w: maybe put that information in the .upstream branch?
[22:16] <asac> so when we switch method we can just commit that change manually to .upstream branch?
[22:16] <james_w> I'm not sure where we could put it in .upstream, but it does make sense
[22:16] <asac> but cluttering upstream branch tree is not a good idea
[22:17] <asac> james_w: bzr should really be able to maintain meta info outside the file tree ;)
[22:17] <james_w> a text file would work, but yeah, it clutters it, and means you don't have exactly upstream.
[22:17] <asac> just like files, just not in the checkout tree ;)
[22:18] <james_w> asac: I agree. There is .bzr/branch/branch.conf, but it doesn't propagate all the values
[22:18] <asac> james_w: is that versioned?
[22:18] <james_w> nope
[22:18] <asac> question is if we the model we want can rely on bzr specifics
[22:18] <asac> or should it be implementable on top of other modern vcs soltuions?
[22:19] <james_w> for initial work on this I would just put it in the master file, for the simple reason that it's less code.
[22:19] <asac> james_w: right. makes sense imo
[22:19] <asac> james_w: i think archive admins that will probably maintain that list should see any change of upstream method and approve it manually
[22:20] <asac> so that would work
[22:20] <asac> but still the info isnt there in the branch. but well. we will figure something i guess
[22:20] <james_w> yeah, it's not great for doing it locally, so we may want to transition away when we have a good plan.
[22:22] <asac> james_w: ok, so i guess we will come up with a plugin script: 'amo-upstream' that allows you to do "./amo-upstream has-new $current_version" and "./amo-upstream fetch-new $target_dir"
[22:22] <james_w> that would be good
[22:22] <asac> 'amo-upstream' that allows you to do "./amo-upstream $package has-new $current_version" and "./amo-upstream $package fetch-new $target_dir"
[22:22] <asac> i guess the comment should be at $1 though
[22:22] <asac> command
[22:22] <asac> sorry
[22:25] <asac> jimmy_: where are we for the xdg patch :) ?
[22:28] <jimmy_> asac: ok, it is working :)
[22:28] <asac> jimmy_: awesome
[22:28] <jimmy_> asac: i just need to clean up a code a little bit
[22:28] <asac> jimmy_: yeah
[22:36] <fta> http://www.kaply.com/weblog/2008/05/28/the-browser-with-no-name/
[22:38] <asac> [reed]: mozilla bug 421977 lacks review? maybe ask someone != gavin?
[22:38] <ubottu> Mozilla bug 421977 in OS Integration "nsGNOMEShellService::GetDesktopBackgroundColor should support GConf's actual format" [Normal,Assigned] http://bugzilla.mozilla.org/show_bug.cgi?id=421977
[22:51] <fta> http://hackademix.net/2008/05/28/unpatched-flash-vulnerability-widely-exploited-in-the-wild/
[22:54] <asac> thx
[23:16] <jimmy_> asac: http://paste.ubuntu.com/15671/
[23:17] <jimmy_> asac: check if this patch is ok
[23:25] <asac> jimmy_: ok. i think to get this into upstream we have to come up with some research on whether those mime-type string matches make sense
[23:26] <asac> do we have a list of all "registered" mime-types so we can filter out if we catch most cases of audio/video?
[23:26] <asac> and images
[23:26] <asac> jimmy_: i dont like the idea to default to documents
[23:26] <asac> shouldnt the default be just "DOWNLOADS" dir?
[23:27] <jimmy_> asac: Dowloads or desktop would be fine
[23:27] <asac> and if you want those to go to documents in Moblin you can setup xdg-user.dirs to point to the proper directoy
[23:27] <asac> jimmy_: please use DOWNLOADS as default. if we can find a smart match for standard document types we might add those
[23:27] <asac> to DOCUMENTS
[23:28] <jimmy_> asac: ok
[23:29] <jimmy_> asac: i dun really know of a way to smartly diferentiate audio, video and image mimetypes besides those keywords, unless you actually do a string match of all available types
[23:30] <jimmy_> asac: there are always special cases like application/vnd.rn-realmedia-vbr, which is a realmedia video
[23:37] <asac> jimmy_: i think in order to decide what to do here, we first have to do some research on what mime type map to what download directory :)
[23:37] <asac> if there are just a few cases that are not covered, then we can probably keep the current match
[23:38] <asac> jimmy_: how is fingerscroll going?
[23:39] <asac> jimmy_: is fingerscroll just grabanddrag for text input fields?
[23:40] <jimmy_> are you talking about the moko stuff?
[23:44] <asac> jimmy_: i think so ... though i am not referring to moko in particular. What does it do?
[23:45] <asac> if its just grabanddragfor text input fields we can do it on our own i guess
[23:49] <jimmy_> i believe so
[23:50] <jimmy_> because the current grabanddrag is not working for scrollboxes other than the web pages
[23:51] <jimmy_> and Carl was trying to integrate moko libraries into the browser, but it has some complications where the browser is using multiple gtk windows, and moko does not support multiple gtk windows well in the current stage
[23:52] <jimmy_> so i think they decided to just stick with grabanddrag for now for navigations