[11:56] 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] Well, it seems to have regressed in oneiric [11:59] hmm, but only on one of the two computers I have upgraded [12:05] firefox -ProfileManager no longer works? [12:19] hmm, there seems to be a bug in TB [12:20] can somebody confirm? [12:20] start writing a message, and type in a "attachment keyword" so you get the notification about the issue [12:20] then start writing an another message, and do the same, and TB should soon start throwing errors that a script is already in use === m_conley_away is now known as m_conley [15:55] maxb: that happened on the upgrade to 7.0 in oneiric, should be fixed in 7.0.1 [15:55] micahg: Am on 7.0.1, it's still broken [15:56] please don't tell me that a week before release :( [15:56] maxb: did you have any interrupted updates? [15:56] 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] yes.... on the machine which it's working on :-) [15:56] ah, upgrade from naty.... [15:57] that would make sense... [15:57] well, no is shouldn't still... [15:57] *it, the new script should DTRT [15:58] maxb: what's the status of /usr/lib/firefox-7.0/distribution on the broke machine [15:58] 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] I don't have a /usr/lib/firefox-7.0 - I have a -7.0.1, though [15:59] yes, sorry, 7.0.1 [15:59] brb [15:59] It's an empty directory [15:59] oh, and on the working machine it's a symlink [16:02] 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] Unfortunately, sounds like the migration isn't working properly :-/ [16:03] right, that's the problem, I"ll need a bug to fix, let me see if I have one [16:04] launchpad is not showing me anything obvious [16:05] maxb: please file a bug, I"ll let the release manager know..thanks [16:05] filing [16:14] bug 869311 [16:14] Launchpad bug 869311 in firefox "searchplugins installation damaged after natty->oneiric upgrade" [Undecided,New] https://launchpad.net/bugs/869311 [16:16] maxb: thanks, we have a fix that I"ll be uploading shortly [16:24] is it possible to confine firefox plugins without modifying the firefox apparmor profile? [16:26] debfx: you mean as in to avoid conffile changes? [16:26] jdstrand: yes, as it changes with every upstream version [16:26] debfx: yes, modify /etc/apparmor.d/local/usr.bin.firefox [16:27] jdstrand: the problem is that firefox has the rule "/usr/lib/firefox-7.0.1/** ixr," [16:27] I'm not sure how to override that for /usr/lib/firefox-7.0.1/plugin-container [16:28] debfx: that's ok, just be more specific. I recommend something like this in local/usr.bin.firefox: [16:28] /usr/lib/firefox-7.0.1/plugin-container Cx -> plugincontainer, [16:28] profile plugincontainer { [16:28] ... [16:28] } [16:29] debfx: I do something like that for gedit [16:30] 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] hi chrisccoulson, I'm about to upload your fix for the symlink issue since we just got a report one it [16:31] jdstrand: that hardcodes the upstream version [16:31] * micahg just discovered yet another branch he's not subscribed to [16:31] debfx: fyi, you will actuall probably want to use globbing in local/usr.bin.firefox [16:31] debfx: heh, yes :) [16:31] /usr/lib/firefox-*/plugin-container Cx -> plugincontainer, [16:32] jdstrand: does that still work? how does apparmor determine which rule is more specific? [16:33] 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] 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] chrisccoulson: why? people upgrade from the live media [16:40] they will still get the latest version after the upgrade [16:40] pitti didn't raise that as an issue, anyway [16:40] yes, but they lose their search engines [16:41] jdstrand: yeah, sounds complicated :) [16:42] jdstrand: the problem with a general plugin-container profile is that it would apply to all firefox plugins [16:42] 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] chrisccoulson: where was the conversation (I'd like to look at the discussion if possible) [16:43] 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] maybe using Px for some things [16:44] it will be more complicated, but it is something I'd like to have [16:45] debfx: re most specific> I thinking if the basename is specified, that'll take precedence over a glob [16:51] jdstrand: this is the profile I currently use for nspluginwrapper: http://paste.ubuntu.com/703496/ [16:51] it's very strict though [16:52] thanks [16:59] jdstrand: the apparmor parser complains about the plugin-container rule: "profile has merged rule with conflicting x modifiers" [17:00] debfx: can you bring that up in #ubuntu-hardened? [17:01] jdstrand: yep === m_conley is now known as m_conley_away