[00:00] with --remember you can permanently change that [00:00] i hope your password was your sshkey passphrase ;) [00:00] * asac thought we dont allow non key auth [00:01] ccheney: so yes. we should upload a stripped libsoup package ;) [00:01] to ppa for bootstrap [00:01] and hope thats it [00:01] actually while we rename it ;) [00:02] but for now we can try without rename [00:02] ccheney: so soup w/o gnome .... then see what webkit needs from glib [00:14] * ccheney needs to get the rest of the glib functions into soup to get it to finish building, saw the proxy issue earlier and didn't finish porting the functions over yet [00:15] looks like ~ 21 functions to copy over [00:22] does that build? [00:26] 01:22 < jorlow> trimeta: can you disable extensions and try again? [00:26] 01:22 < jorlow> it'd be especially helpful if you knew which one put it over the edge [00:26] 01:22 < trimeta> Disabling AdThwart, Chrome Keyconfig, FlashBlock, RSS Subscription, and Select To Get Maps made them not crash. So yea. [00:26] lol [00:26] in #chromium ;) [00:26] thats bugabundo ;) [00:30] doesn't build without the functions but gets to the point of attempting to link all of libsoup together [00:30] so it probably will work once i get them ported [00:30] yeah [00:31] so when we have that we have to check ewbkit and port whatever is needed there ;) [00:36] yep [00:36] * ccheney going to get dinner, bbl === asac_ is now known as asac [08:42] fta: ping === ripps|sleep is now known as ripps [09:25] * BUGabundo_eyeswi yawns === BUGabundo_eyeswi is now known as BUGabundo_work [10:05] ripps, hi, did you read my answers? [10:06] yeah, I was bit confused, are you telling me to try and rename the orig.tar? [10:06] because doing that also changed the changelog version with the bot parses it. So it doesn't work either [10:08] look at the current version in the repo, the tarball doesn't have the epoch, yet the package has it [10:09] fta@ix:/tmp $ head -1 mplayer-1.0~rc3+svn20090426/debian/changelog [10:09] mplayer (2:1.0~rc3+svn20090426-1ubuntu10.1) karmic-proposed; urgency=low [10:09] -rw-r--r-- 1 fta fta 10029266 2009-06-07 16:04 mplayer_1.0~rc3+svn20090426.orig.tar.gz [10:09] -rw-r--r-- 1 fta fta 2673 2009-12-09 07:05 mplayer_1.0~rc3+svn20090426-1ubuntu10.1.dsc [10:09] -rw-r--r-- 1 fta fta 73589 2009-12-09 07:05 mplayer_1.0~rc3+svn20090426-1ubuntu10.1.diff.gz [10:10] my bot won't work for that just yet, i need to fix it, should be easy, but i didn't have time just yet [10:33] okay, I guess I'll have to manage my the coreavc ppa manally for now. [10:33] Lot of eager people want to try out the new coreavc-2.0 [10:49] ripps, i will try to fix it asap, i just need to setup a test project with an epoch [10:49] well, there's mplayer, but I suppose that's a bit too large... [11:54] [reed]: root certificates ... can admins add that somehow to firefox [11:54] for all users? [11:54] <[reed]> define "admins" [11:55] like X working in a company having root on linux boxes [11:56] so typical desktop sys administrator ... running around rolling out software to various machines etc. [11:57] from what i recall mozilla was scared that distros could mess up their root certificates too easily and hence there is no way to add root certs to /etc/... somehow [11:57] <[reed]> not easily... he could create a default firefox profile with the cert and push it out [11:57] ;) [11:57] hmm [11:57] <[reed]> but any new profile wouldn't have it [11:57] do you know about references that discussed why there is no way to add a /etc/ sec store for firefox? [11:58] or nss even [11:59] <[reed]> nope, not without searching [12:13] hi hjmf ;) happy new year! === Loki_ is now known as Loki [14:57] * BUGabundo_work picks asac up, and move him to #ubuntu+1 [14:57] topic? [14:57] sir, your presence is required [14:57] http://paste.ubuntu.com/351809/ [14:57] apparmor [14:58] apparmor. yes. [15:10] jdstrand: did you land all apparmore improvements on all branches? [15:10] or just 3.5? [15:11] asac: all [15:12] BUGabundo_work, asac: I've not seen /dev/shm/orbit-yofel/linc-dff-0-6e09a978f6b2 before-- what is this? [15:13] jdstrand: good question... lemme try to find out [15:13] hmm. he is here ;) ... why are we talking in #ubuntu+1 ;) [15:13] asac: that's where the discussion began ;) [15:13] * asac left that channel ;) [15:14] yofel: it might be we need to update an abstraction, rather than the firefox profile [15:14] kk [15:15] asac: xul193 failed a sqlite test that upstream moz added which I think was caused by a fix by upstream sqlite, I should open a new bug in bmo with the relavent info, rigt? [15:16] micahg: test? [15:16] you mean like in "make check" ? [15:16] or configure test? [15:16] no [15:16] http://hg.mozilla.org/mozilla-central/rev/06dd18a36470 [15:17] yeah, I guess it's a configure test [15:18] there was a debian bug for pretty much the same thing as the moz bug and the debian maintainer said it was fixed in the latest sqlite [15:19] hmmm, they already have a bug to upgrade to the latest sqlite... [15:20] * micahg thinks he should go as in #developers [15:20] *ask [15:22] whats the problem? [15:22] our sqlite isnt built with that flag? [15:22] asac: no, it is [15:22] but sqlite apparently changed the way the flag works [15:23] asac: this is the change that might have caused the issue: The SQLITE_SECURE_DELETE compile-time option fixed to make sure that content is deleted even when the truncate optimization applies. [15:24] hi, is bug 503107 a known issue for firefox in ubuntu? [15:24] Launchpad bug 503107 in firefox-3.5 "YouTube videos sometimes do not appear, sometimes do" [Undecided,New] https://launchpad.net/bugs/503107 [15:25] asac: #developers wants to know why we use system sqlite :) [15:34] nigel_nb: sorry, got a little distracted [15:35] micahg: no problem :) [15:35] nigel_nb: adblock plus can cause the issue that the user's having [15:35] micahg: I do encounter that bug often [15:35] I generally suggest a new profile [15:36] I can pastebin the text [15:36] and a new profile works too [15:36] but is it a bug, that the profile is getting corrupted? [15:36] nigel_nb: this is generally what I use: http://pastebin.ubuntu.com/351828/ [15:36] nigel_nb: no, abp is blocking flash [15:36] unless the user allows it [15:37] micahg: ohh [15:37] nigel_nb: people shouldn't be installing addons without understanding what they do [15:37] hold up, it happens to me too [15:37] but I dont think I have add block [15:37] nigel_nb: so I choose for people to have a eureka moment rather than have me tell them the issue [15:37] then once they discover it, I usually explain the problem === jtv is now known as jtv-zzz [15:38] micahg: but I dont have adblock installed, so what could be my issue? [15:38] nigel_nb: what issue? [15:38] you can't see videos? [15:38] I encouter the same thing, flash stops working often [15:39] then I have to create a new profile [15:39] (at least I'm learning all my passwords now) [15:39] nigel_nb: you shouldn't have to do that [15:39] nigel_nb: 64 bit or 32 bit? [15:40] 64-bit [15:40] * micahg hasn't really had a problem with flash since the upgrade to karmic [15:40] micahg: you use 32-bit? [15:40] nigel_nb: no, 64 bit [15:40] nigel_nb: bug 238606 [15:40] Launchpad bug 238606 in flashplugin-nonfree "[MASTER] Flash player doesn't work properly on Firefox 3 64bits (crash,gray square)" [Undecided,Confirmed] https://launchpad.net/bugs/238606 [15:40] is that your bug? [15:41] using 64 bit flash? [15:41] that sounds similar to mine [15:41] jdstrand, asac: it seems like I found the actual root cause... for some reason I had 'export TMPDIR=/dev/shm' at the end of my .bashrc, this causes orbit-yofel to be in /dev/shm instead of /tmp and this seems to break apparmor [15:42] sounds bad ;) [15:42] doesnt feellike a bug [15:42] micahg: oh, by the way, what status do u want me to set on those bugs? invalid? incomplete? [15:43] nigel_nb: which bugs? [15:43] people with addons they don't understand? [15:43] micahg: the flash not working on firefox bugs [15:43] nigel_nb: that can be a lot of things [15:43] micahg: oh oh [15:44] there are at least 2 master bugs for flash issues [15:44] yofel: cool. if you want to use /dev/shm as TMP, then update /etc/apparmor.d/abstractions/user-tmp [15:44] micahg: shall I link this one up as a dup of 238606? [15:45] nigel_nb: no, first you have to determine if it's a user issue or that bug or another [15:45] jdstrand: wouldn't it be somehow possible to make apparmor read $TMPDIR? [15:45] micahg: ok, how do I start? [15:45] nigel_nb: ask the user to test with a new profile [15:46] then you can rule out non-system addons [15:46] micahg: okay, I'll put in the pastebin you gave me and then set as incomplete [15:46] yofel: not easily, besides you wouldn't want to cause it could be used to circumvent apparmor. eg TMPDIR=/ [15:46] nigel_nb: yep [15:47] yofel: that is why the abstraction is there-- it is designed for people like you who need to define another tmp dir [15:47] jdstrand: ah, makes sense, thx anyway [15:47] micahg: thanks :) [15:47] nigel_nb: thank you for helping [15:48] happy to help micahg :) [15:48] asac: thank you too for your time [15:48] jdstrand: I wanted to comment out of that ff bug about /usr/local/lib, I would think if anything it should be commented out [15:48] jdstrand: but wanted to check with you first [15:49] yofel: welcome [15:50] micahg: sorry, I don't understand your question [15:50] apparmor? [15:50] jdstrand: the bug about /usr/local/lib in the apparmor profile [15:50] * jdstrand nods [15:50] we defintly want warnings in dmesg if users access /usr/local/lib [15:51] bug 501822 [15:51] Launchpad bug 501822 in firefox-3.5 "firefox apparmor profile blocks access to /usr/local/lib" [Undecided,Triaged] https://launchpad.net/bugs/501822 [15:51] would be a big win triaging bugs because users ran make install on ancient gtk or something [15:51] yeah. if we could misuse apparmore to just warn (even if enabled) i would be happy ;9 [15:51] well, wasn't there a bug to warn on apparmor failure [15:52] asac: not possible. the profile can be in complain, force or completely disabled [15:52] (it's a kernel thing) [15:53] jdstrand: can we have a complain profile and a force profile? [15:53] yeah. then i would prefer to not block /usr/local/lib ;K) [15:53] micahg: not loaded at the same time [15:53] jdstrand: I'm suggesting with separate rules [15:54] micahg: the profile attaches to the binary [15:54] * micahg was thinking from a seucrity perspective, /usr/local/lib could cause issues [15:54] micahg: so we can't do that [15:54] jdstrand: ah [15:54] well, actually, I might be able to play with 'audit' [15:55] actually no, that wouldn't work [15:55] and it would be confusing for the user [15:56] bug 489278 [15:56] Launchpad bug 489278 in apparmor "Apparmor should notify the user when it blocks access" [Undecided,New] https://launchpad.net/bugs/489278 [15:56] micahg: my feeling was that /usr/local/lib could cause issues, but overall, you need admin access for those directories anyway [15:56] if you have that, you can change the profile [15:56] jdstrand: yes, but regular users have sudo rights on ubuntu desktops :) [15:57] if they're following so blog post that's malicious, they won't know it [15:57] *some [15:57] micahg: well, we aren't protecting a user from him/herself. that is very difficult. we are protecting users from a misbehaving firefox [15:57] firefox can't write to /usr/local/lib [15:57] (due to apparmor) [15:57] even via sudo [15:57] that's why I figure if it's commented out like some of the other more permissive things it might be better [15:58] (cause apparmor denies it) [15:58] jdstrand: even firefox using libs in there might cause issues [15:58] micahg: oh, I think I understand your question-- you say add it to the profile, but have it commented out [15:58] yep :) [15:58] gotcha [15:58] since it's not a regular use case [15:58] as in most users using software from the repos won't need it [15:58] no it isn't, but I feel for that guy who spent months on it [15:59] yeah, that why bug 489278 would be nice [15:59] Launchpad bug 489278 in apparmor "Apparmor should notify the user when it blocks access" [Undecided,New] https://launchpad.net/bugs/489278 [15:59] but people use firefox differently than other apps [15:59] specifically, we try to support using extensions, etc [15:59] (not from the repo) [15:59] jdstrand: yes, but I don't think those go in /usr/local/lib do they? [16:00] this will be even more important moving forward when we aren't shipping extensions in the repo due to maintenance issues and the new mozilla security support [16:00] micahg: probably not, but a user may want to install stuff there, if they compile from source [16:01] * jdstrand was even considering adding /usr/local/lib/** mr, to abstractions/base [16:01] jdstrand: yes, but what if someone install a malicious deb package that installs in /usr/lib/local [16:02] micahg: a malicious deb can do far worse than install a lib in /usr/local/lib to be then later be used by the user in some random app [16:02] it runs as full root [16:02] that deb could install that lib in /usr/lib [16:02] jdstrand: yes, but wouldn't it be harder to find something in there? [16:03] it would be even harder to find it in /usr/lib [16:03] if you are installing random debs off the internet, all bets are off [16:03] they can disable apparmor entirely [16:03] install a rootkit [16:03] anything [16:03] hmm, ok, that's why I figure I'd talk to you since my concerns might not be valid [16:04] micahg: it is always valid to think about the security of adjusting the profile [16:04] micahg: so thank you :) [16:05] I'm still thinking about /usr/local/lib for firefox, and wanted to get discuss it more with the others from the security team [16:05] jdstrand: I also wanted to ask you about backporting some of the FF profile fixes to karmic [16:05] spcifically chromium [16:05] oops [16:05] micahg: iirc, you said you wanted to do an SRU [16:05] chromium was for something different [16:05] jdstrand: yeah, and then an SRU got uploaded without it [16:06] should I rebase it? [16:06] chromium was for browser abstractions [16:06] but I think there were a few profile fixes that would be nice for karmic, but I'd have to check [16:06] micahg: feel free to do an SRU with all the profile fixes you want, attach it to to one of the bugs and follow StableReleaseUpdates. ping me and I'll comment on the debdiff [16:07] jdstrand: great, thanks [16:07] np === \vish is now known as mac_v === mac_v is now known as \vish [16:50] asac: we don't want firefox displaying local php scripts in the browser as text, right? [16:53] micahg: i would think if there is a system handler for that, then not. otherwise yes. === \vish is now known as vish === ripps is now known as ripps|sleep [17:47] asac: ping [17:58] asac: is that something for ubuntu? (The idea, not the work itself :P) http://www.be-jo.net/de/2010/01/thunderbird-als-starter-ins-indicator-applet/ [18:20] last time i looked this was really hackish [18:21] asac: what's the difference between evolution and thunderbird? Evolution is a little bit more gnome integrated [18:23] sebner: the difference is that its a complete different code base [18:23] asac: but what's the difference difficulties for integrating TB into indicator? [18:25] the difference is that TB 3 was a huge effort and integrating with indicator applet is low prio for them [18:31] hi [18:31] asac: bah, I suppose more users are using TB than evolution to be honest [18:31] hiuhuhu fta [18:32] hi fta [18:32] * asac starts to pack things [18:33] ? [19:36] : just commuting ... with all the hardware stuff i have ;) [19:45] nigel_nb: you got a bite on the bug [19:45] ok out for a few hours ... travelling [19:45] micahg: he did reply [19:45] micahg: and he has ad block :) === yofel_ is now known as yofel [19:46] nigel_nb: that info was already in the bug :) [19:48] nigel_nb: firefox bugs reported with ubuntu-bug attach extensions list and plugins [22:39] ccheney: so lots of troubles ? [22:39] asac: did you spin 3.5.7 yet or do I have time tonight to try to get dh_xul in? [22:40] micahg: is it out yet? [22:40] ;) [22:40] supposed to release today [22:40] err ... wasnt dh_xul merged already? [22:40] or just approved? [22:40] asac: just approved [22:41] I saw your commnet [22:41] but wasn't able to merge [22:41] ok. thanks [22:41] the merge is just one command i would hope ;) [22:41] I kept getting errors [22:41] and now it's diverged [22:41] merge erros? [22:41] after the arm patch [22:41] that shouldnt collide except for changelog [22:41] so I'll just apply the diff from the merge [22:42] idk [22:42] please run bzr merge ... that should work [22:42] its expected to have conflicts in changelog [22:42] but applying the diff manually will have that too ;) [22:42] you need to resolve those in editor and run bzr resolve [22:43] ok, bzr merge lp:branch? [22:43] yeah.. go in current checkout of .head ... run bzr merge lp:....branch/to/merge [22:43] then all should work well ... except the changelog will have conflicts [22:44] go there with editor and shuffle bits until bzr diff looks reasonable ;) [22:44] usually its just moving the comment he made somewhere else and removing the markers [22:44] hmm [22:44] that went smoother than last time [22:44] * micahg doesn't know what changed [22:45] heh [22:46] hmm [22:46] my patch name isn't 80 character changelog safe [22:46] I can fix that afer [22:46] what should be my commit message for the merge? [22:47] asac: ? [22:48] i usually use: [22:48] debcommit -e [22:49] and then i add one line on top saying: [22:49] (merge lp....) [22:49] ?the branch name [22:49] yes [22:49] lp:.... [22:49] k [22:49] and below keep the thing debcommit suggests (e.g. basically the [22:49] changelog comment [22:49] remember to give credits to author by using [ Name ] [22:50] also, you're not spinning a 1.9.1.6, so should I update the docs to say minimum version for dh_xulrunner to 1.9.1.7 [22:50] asac: credit in the merge and changelog? [22:51] credit yes, email in merge and changelog? [22:51] no... changelog [22:51] credit is already in the merge source [22:51] debcommit removes that automatically [22:51] ok, so email and name in changelog? [22:52] why does dch not do that, it only adds the name [22:52] because the email is mozillateam invention [22:52] i wanted to update dch to do that at some point [22:52] but never came to it [22:52] asac: also, what about the xul-dev Q [22:53] basically we addewd it because launchpad parses the email and links to your profile [22:53] asac: ok, so I should do that manually? [22:53] which gives much better credit [22:53] yes [22:53] k [22:53] i always add it manually [22:53] and bump dh_xul docs to minumum >= 1.9.1.7 [22:53] or do I need the whole version string? [22:55] asac: in addition to ^^, do I need to list the files in either the merge comment or changelog for dh_xulrunner? [22:57] micahg: they should be in changelog as usual. if you use decommit -e that will be in the commit as well [22:58] asac: k, what about the version in teh dh_xul docs? [22:59] thats manpage, right? [22:59] yep [22:59] we should have the version where we first ship it in there [22:59] asac: so, it'll be 1.9.1.7? [23:00] asac: actually it's POD doc [23:03] POD? [23:03] yes 1.9.1.7 is ok [23:03] perl doc [23:03] k [23:03] I added all the filenames to the changelog [23:04] thx [23:04] thats usually the service we provide for contributors [23:04] they dont know about the syntax [23:05] we could comment so they know in future, but shouldnt reject a contribution because of changelog format (unless he wants to become mt member) [23:06] asac: I made my changes to the merge before commit, is that ok? I figured on adding a comment with the merge that I modified the version that it will first ship in [23:08] micahg: thats the right approach [23:08] run bzr merge [23:08] cool [23:08] adjust ... [23:08] commit [23:08] asac: am i allowed to drop the deprecated MOZ_XPI_MOZILLA_DIRS variable? [23:08] if nothing in the archive uses that [23:08] grep -r [23:08] ;) [23:08] does it cause any problem? [23:08] if not, keep it [23:09] asac: how do i get a list of all xul extensions? [23:10] asac: just push after? [23:10] dunno. grepping through all diff.gz will help ;) [23:10] bdrung: in any case. does it hurt? [23:10] if not ... dont remove it [23:11] asac: it needs some effort to support with the new design. [23:15] * micahg completed his first bzr merge :) [23:15] congrats [23:16] asac: now, about the patch name for arm...bz532198_lp488354_ns_invokebyindex_not_thumb2_safe.patch [23:16] is that a problem? [23:16] it's over 80 characters [23:17] - add debian/patches/bz532198_lp488354_ns_invokebyindex_not_thumb2_safe.patch [23:17] thats normal and the reason why we started to put filenames below the changelog [23:18] i would expect there are more than just that ;) [23:18] k, so if that line wraps I shouldn't worry [23:18] wraps? [23:18] keep it in one line ;) [23:18] >80 [23:18] right [23:18] one line [23:18] good. then it isnt wrapped ;) [23:19] it wraps in an 80 char terminal [23:19] heh [23:19] your standards are too high ;) [23:19] also 80 char is a bit old. 100 is better ;) [23:19] ripps|sleep, u there? i have a patch to support epochs in the bot [23:19] k, do I need to push the arm patch to 1.9.2 and 1.9.3 or just dh_xul? [23:20] micahg: just for 1.9.1 ... we dont want it to stay there that long [23:20] the upstream patch will get committed hopefully [23:20] k, I'll try to push it upstream [23:21] we are just not yet sure how to support debian ;) [23:21] a little later [23:21] micahg: upstream? ... it already was pushed upstream and they wanted clarfication. we are currently working on a better patch ;) [23:22] i will probably sumit that tomorrow [23:22] but for us that patch is perfect :) [23:22] asac: k, I thought you said before that upstream moz needed the arm patch [23:22] it needs to get committed ;) [23:22] updated [23:22] ah [23:22] sorry for not being clear [23:23] ok, so I can just merge the dh_xul rev from 1.9.1 into 1.9.2 and 1.9.3, right? [23:24] yep. and add the arm patch to xul 1.9.1 ... then make a release on .head [23:24] one second [23:24] jdstrand: there? usn's for ffox/xul update? [23:24] asac: arm is already in [23:24] good [23:24] I'll do dh_xul on the other branches later this wek [23:24] *week [23:24] asac: just about missed me-- you need a new usn? how many? [23:24] sure. thats fine [23:25] jdstrand: the usual set. [23:25] e.g. ffox 3.0 and 3.5 [23:25] (with the xuls) [23:25] my only question, is the version in the docs should still be 1.9.1.7 since that'll be the only one in an official archive? [23:25] asac: 877-1 and 878-1 [23:25] micahg: i think thats fine everywhere [23:25] jdstrand: thanks ... enjoy your evening ;) [23:26] asac: k [23:26] asac: thanks, you too :) [23:26] micahg: not sure what docs says, but i think they say what the first version was etc. [23:26] micahg: so after all is done, see how i document security/stability updates ... and do the same with the number from above [23:26] at best in the "bump" commit [23:27] use 878-1 for 1.9.1.7 and 3.5.7 [23:27] asac: you want me to spin the release? [23:27] USN-878-1 [23:27] on .head for sure [23:27] * micahg can't upload [23:27] since you did all i want to sponsore that [23:27] thats not a problem ;) [23:27]