[11:56] <maxb> Anyone around who remembers that thing that happened once before in natty with all but one of the Firefox search plugin disappearing because the .xml files had been mislaid in a natty update?
[11:56] <maxb> Well, it seems to have regressed in oneiric
[11:59] <maxb> hmm, but only on one of the two computers I have upgraded
[12:05] <maxb> firefox -ProfileManager no longer works?
[12:19] <knome> hmm, there seems to be a bug in TB
[12:20] <knome> can somebody confirm?
[12:20] <knome> start writing a message, and type in a "attachment keyword" so you get the notification about the issue
[12:20] <knome> then start writing an another message, and do the same, and TB should soon start throwing errors that a script is already in use
[15:55] <micahg> maxb: that happened on the upgrade to 7.0 in oneiric, should be fixed in 7.0.1
[15:55] <maxb> micahg: Am on 7.0.1, it's still broken
[15:56] <micahg> please don't tell me that a week before release :(
[15:56] <micahg> maxb: did you have any interrupted updates?
[15:56] <maxb> much to my confusion, I upgraded two natty machines today at the same time, and it's only broken on one of them
[15:56] <maxb> yes.... on the machine which it's working on :-)
[15:56] <micahg> ah, upgrade from naty....
[15:57] <micahg> that would make sense...
[15:57] <micahg> well, no is shouldn't still...
[15:57] <micahg> *it, the new script should DTRT
[15:58] <micahg> maxb: what's the status of /usr/lib/firefox-7.0/distribution on the broke machine
[15:58] <maxb> So, on the working machine, I upgraded natty's 6.0.2 to oneiric's 7.0.1;  and on the broken machine I upgraded natty's 7.0.1 to oneiric's 7.0.1
[15:59] <maxb> I don't have a /usr/lib/firefox-7.0 - I have a -7.0.1, though
[15:59] <micahg> yes, sorry, 7.0.1
[15:59] <micahg> brb
[15:59] <maxb> It's an empty directory
[15:59] <maxb> oh, and on the working machine it's a symlink
[16:02] <maxb> OK, so I've mv-ed aside the directory and created a symlink like on the working machine, and it's working fine now
[16:02] <maxb> Unfortunately, sounds like the migration isn't working properly :-/
[16:03] <micahg> right, that's the problem, I"ll need a bug to fix, let me see if I have one
[16:04] <maxb> launchpad is not showing me anything obvious
[16:05] <micahg> maxb: please file a bug, I"ll let the release manager know..thanks
[16:05] <maxb> filing
[16:14] <maxb> bug 869311
[16:14] <ubot2> Launchpad bug 869311 in firefox "searchplugins installation damaged after natty->oneiric upgrade" [Undecided,New] https://launchpad.net/bugs/869311
[16:16] <micahg> maxb: thanks, we have a fix that I"ll be uploading shortly
[16:24] <debfx> is it possible to confine firefox plugins without modifying the firefox apparmor profile?
[16:26] <jdstrand> debfx: you mean as in to avoid conffile changes?
[16:26] <debfx> jdstrand: yes, as it changes with every upstream version
[16:26] <jdstrand> debfx: yes, modify /etc/apparmor.d/local/usr.bin.firefox
[16:27] <debfx> jdstrand: the problem is that firefox has the rule "/usr/lib/firefox-7.0.1/** ixr,"
[16:27] <debfx> I'm not sure how to override that for /usr/lib/firefox-7.0.1/plugin-container
[16:28] <jdstrand> debfx: that's ok, just be more specific. I recommend something like this in local/usr.bin.firefox:
[16:28] <jdstrand> /usr/lib/firefox-7.0.1/plugin-container Cx -> plugincontainer,
[16:28] <jdstrand> profile plugincontainer {
[16:28] <jdstrand>   ...
[16:28] <jdstrand> }
[16:29] <jdstrand> debfx: I do something like that for gedit
[16:30] <jdstrand> debfx: I'm also curious about what you come up with for plugin_container. when you have something working, can you file a bug on it and assign it to me?
[16:30] <micahg> hi chrisccoulson, I'm about to upload your fix for the symlink issue since we just got a report one it
[16:31] <debfx> jdstrand: that hardcodes the upstream version
[16:31]  * micahg just discovered yet another branch he's not subscribed to
[16:31] <jdstrand> debfx: fyi, you will actuall probably want to use globbing in local/usr.bin.firefox
[16:31] <jdstrand> debfx: heh, yes :)
[16:31] <jdstrand> /usr/lib/firefox-*/plugin-container Cx -> plugincontainer,
[16:32] <debfx> jdstrand: does that still work? how does apparmor determine which rule is more specific?
[16:33] <jdstrand> debfx: that should work. how it decides is actually pretty complicated and based on DFA and hybrid DFA theory. I'll direct you to #apparmor on OFTC and http://wiki.apparmor.net/index.php/Documentation if you are really interested
[16:39] <chrisccoulson> micahg, i already talked to pitti about that yesterday, we're going to do a SRU for that rather than squeeze it in to final
[16:39] <micahg> chrisccoulson: why?  people upgrade from the live media
[16:40] <chrisccoulson> they will still get the latest version after the upgrade
[16:40] <chrisccoulson> pitti didn't raise that as an issue, anyway
[16:40] <micahg> yes, but they lose their search engines
[16:41] <debfx> jdstrand: yeah, sounds complicated :)
[16:42] <debfx> jdstrand: the problem with a general plugin-container profile is that it would apply to all firefox plugins
[16:42] <jdstrand> debfx: I like to think of it as "the most specific rule wins". it is not necessarily totally accurate, but it gets me through the day :)
[16:43] <micahg> chrisccoulson: where was the conversation (I'd like to look at the discussion if possible)
[16:43] <jdstrand> debfx: well, I'm still interested with what you come up with. I'd like to be able to lock it down, even if it is opt in
[16:44] <jdstrand> maybe using Px for some things
[16:44] <jdstrand> it will be more complicated, but it is something I'd like to have
[16:45] <jdstrand> debfx: re most specific> I thinking if the basename is specified, that'll take precedence over a glob
[16:51] <debfx> jdstrand: this is the profile I currently use for nspluginwrapper: http://paste.ubuntu.com/703496/
[16:51] <debfx> it's very strict though
[16:52] <jdstrand> thanks
[16:59] <debfx> jdstrand: the apparmor parser complains about the plugin-container rule: "profile has merged rule with conflicting x modifiers"
[17:00] <jdstrand> debfx: can you bring that up in #ubuntu-hardened?
[17:01] <debfx> jdstrand: yep