[00:25] <robert_ancell> thomi, this patch seems to fix it for me: http://paste.ubuntu.com/1039976/.  Not sure if I'm missing anything there, seems to be simple
[00:25] <robert_ancell> to be too simple
[00:25] <thomi> hahaaaa!
[00:26] <thomi> So what do we do now?
[00:27] <robert_ancell> thomi, open an upstream bug and see what they say, patch the ubuntu package if they take too long and we think it's a good patch
[00:27] <thomi> cool.
[00:43] <robert_ancell> thomi, https://bugzilla.gnome.org/show_bug.cgi?id=678059
[00:43] <ubot2> Gnome bug 678059 in general "memory leak in pango_layout_get_extents" [Normal,Unconfirmed]
[00:53] <thomi> robert_ancell: wonderful, thanks. I'll keep ane ye on it
[01:09] <robert_ancell> thomi, does this effect precise?
[01:11] <thomi> robert_ancell: yes
[01:12] <robert_ancell> thomi, are you familiar with https://wiki.ubuntu.com/StableReleaseUpdates?
[01:13] <thomi> robert_ancell: uhhh, I am now
[01:15] <thomi> robert_ancell: I guess that gets done by whoever manages the pango packages for us?
[01:16] <robert_ancell> thomi, well, for it to qualify as an SRU we need to know how severe the problem is, can you describe how much of a problem it is in precise?  i.e. is it just a few k here and there or does it bring unity to a halt over time
[01:16] <robert_ancell> I can do the rest
[01:18] <robert_ancell> brb
[01:21] <thomi> robert_ancell: that's hard to say with certainly. I don't think anyone has reported that unity dies because of this leak, but it certainly shows up in our valgrind logs a lot. By my estimate, at least 20% of all the leaks reported by valgrind  are this pango issue
[01:21] <robert_ancell> thomi, so is it worth backporting?
[01:21] <thomi> I think so. We should probably see what thumper thinks
[01:26] <robert_ancell> oh, he's gone offline
[01:27] <robert_ancell> ok, well prod him some and he can get back to me if he thinks it is worth it
[01:27] <robert_ancell> it's in quantal now
[01:27] <robert_ancell> and upstream accepted the patch
[01:30] <thomi> robert_ancell: awesome, thanks. He should be abck online soon, I'll ask him
[01:46] <RAOF> robert_ancell: You're the proud owner of a radeon card in your devel rig, right?
[01:51] <thumper> robert_ancell: have you fixed that bug already?
[02:06] <thomi> thomas
[02:06] <thomi> oops, entirely the wrong window
[03:58] <robert_ancell> RAOF, nah, I got rid of that machine
[03:58] <RAOF> robert_ancell: Ah, so you're an intel man now? Superb.
[03:58] <RAOF> Or, indeed nouveau. Both of those have less crackful xwayland patches ;)
[03:59] <robert_ancell> RAOF, so we can be blissfully unaware of problems?
[03:59] <RAOF> No, so I can unblock you without rewriting the radeon patch first.
[03:59] <robert_ancell> cool
[06:03] <didrocks> good morning
[06:08] <micahg> hi didrocks, just the person I need :)
[06:09] <micahg> didrocks: http://paste.ubuntu.com/1040330/
[06:09] <micahg> that's in natty
[06:13] <didrocks> micahg: hey, this is the package sil2100 gave to you?
[06:13] <micahg> didrocks:  yep
[06:14] <didrocks> hum, let's see with him, when he's around
[06:14] <didrocks> micahg: I'm not even sure what was used
[06:14] <didrocks> micahg: has this been uploaded?
[06:14] <micahg> didrocks: it built fine on oneiric and precise
[06:14] <didrocks> well, the branches are different ;)
[06:15] <micahg> didrocks: http://bazaar.launchpad.net/~sil2100/unity-2d/natty-security/revision/549
[06:15] <didrocks> micahg: thanks, I'll check with him
[08:16] <seb128> hey
[08:18] <didrocks> salut seb128 :)
[08:18] <seb128> didrocks, lut, en forme ?
[08:18] <didrocks> seb128: ça va bien, et toi? :)
[08:18] <seb128> nickel ;-)
[08:23] <pitti> bonjour seb128
[08:23]  * pitti waves to the desk-TOP!-ers
[08:23] <seb128> pitti, hey, wie gehts?
[08:23] <pitti> gut, danke!
[08:24] <seb128> pitti, how is QA doing? ;-)
[08:24] <pitti> was a bit tired this morning, went to bed late
[08:24] <pitti> but the game was great to watch
[08:24] <seb128> pitti, 2 wins in 2 games, not bad ;-)
[08:24] <pitti> seb128: fairly well indeed! I'm posting my progress to G+ (QA team policy), if you are intested
[08:24] <pitti> seb128: I just finished my remaining "desktop backlog" work items, ported more stuff to python3 (language-selector, ubuntu-drivers-common, etc.)
[08:25] <pitti> great to see aptdaemon-py3 in quantal now
[08:25] <seb128> great
[08:25] <pitti> seb128: so I concentrate on the autopkgtests now
[08:25] <pitti> I worked on udisks2's test suite upstream, and now want to make it succeed in jenkins
[08:25] <pitti> it already uncovered two real and nontrivial bugs, so it's so worth having
[08:25] <pitti> once udisks is covered, I go "up" to gvfs
[08:25] <pitti> that's my current plan, anyway
[08:26] <pitti> seb128: yeah, Gomez is on fire :)
[08:26] <seb128> cool, I'm looking forward that ;-)
[08:27] <Sweetshark> moin!
[08:27] <seb128> hey Sweetshark
[08:27] <didrocks> hey pitti ;)
[08:27] <seb128> pitti, jenkins says that udisk2 testing is red? first step set it up, next step make it work...? ;-)
[08:27] <Sweetshark> seb128, didrocks, pitti: heya
[08:28] <didrocks> good morning Sweetshark
[08:32] <pitti> seb128: right; need to find out why "modprobe scsi_debug" fails in that VM
[08:32] <pitti> seb128: same problem as in the old udisks 1 adt
[08:32] <seb128> oh, ok
[08:32] <pitti> it says "memory error", but that has 4 GB of RAM
[09:02] <glatzor> mvo, mpt hello michael, is there an easy way to get a package -> application from software-center?
[09:03] <seb128> hey glatzor, how are you?
[09:03] <glatzor> mvo, mpt would like to merge error notification dialogs ("your cache is broken") and resolution confirmation dialog ("do you want to remove the following packages to repair your cache?") into a single dialog
[09:04] <glatzor> seb128, hello, I am fine! and yourself?
[09:04] <seb128> glatzor, I'm good thanks
[09:04] <mvo> glatzor: yes, you can use something like db=softwarecenter.db.database.StoreDatabase(); db.get_apps_for_pkgname("foo") and that will give you a bunch of docids that you can then use to get the real application object
[09:05] <seb128> glatzor, thanks for the aptdaemon SRU, could you make the bugs SRU compliant though (impact, test case, regression potential), the SRU team will not review it until that's done, they started being strict on that because we had too many SRUs not testable or tested without those infos and they were never moving to -updates
[09:07] <chrisccoulson> good morning desktop team
[09:08] <seb128> chrisccoulson, good morning firefox team ;-)
[09:08] <chrisccoulson> lol
[09:08] <seb128> chrisccoulson, how are you today?
[09:09] <chrisccoulson> seb128, yeah, not too bad thanks. how are you?
[09:09] <seb128> chrisccoulson, a bit tired but good otherwise
[09:09] <seb128> looking forward the end of week :p
[09:09] <glatzor> mvo, so a possible way could be to add an optional argument to AptErrorDialog. I would like to avoid a software-center dependency on python3-gtk3widgets :)
[09:09] <mvo> glatzor: I'm adding testcases now if you could double check them once I'm done, that would be awsome
[09:09] <mvo> glatzor: haha, understandable
[09:09] <glatzor> mvo, if the package_app_mapper is specified the error dialog will show applications instead of packages
[09:10] <mvo> glatzor: sounds good
[09:10] <mvo> glatzor: building r840 gives me test failures, that is known, right?
[09:11] <glatzor> mvo, aptdaemon is now aware of the internet connection (a side effect of the pkcompat) so I could improve the download failed dialogs on the daemon side
[09:12] <glatzor> mvo, 845 is the way to go
[09:12] <glatzor> mvo,  the test suite is now in a good shape.
[09:13] <mvo> glatzor: aha, so I was just outdated
[09:13] <glatzor> mvo, funnily packagekit will in the futrure support parallel transactions. I think about enabling this already now in pkcompat :)
[09:16] <mvo> glatzor: http://paste.ubuntu.com/1040491/ is what I get from r845 in bzr-buildpackage
[09:20] <mvo> glatzor: I added testcases to the bugs in the SRU now, please double check if you have time
[09:25] <mvo> glatzor: aha, that seems to be something in quantal, looking at this now
[09:25] <mvo> glatzor: nothing releated to your code :)
[09:26] <mvo> glatzor: so are we good to upload? I will update the changelog (if you are not on it already)
[09:29] <glatzor> mvo, should I invite ubuntu-core-dev to aptdaemon-developers?
[09:29] <mvo> glatzor: sounds good
[09:29] <mvo> glatzor: I will also fix the lintian*tags* rename in the .install file
[09:36] <mvo> glatzor: ubuntu-quantal branch is updated, so I can upload whenever you want
[09:41] <mvo> glatzor: one file overwrite issue in fake-polkit.py, so python3-aptdaemon.test and python-aptdaemon.test can not be installed at the same time, should that go to aptdaemon instead?
[09:47] <glatzor> mvo, sorry I am away for some time. see you then
[09:47] <mvo> glatzor: so I fix it in whatever way I see fit? or shall I wait ;) ?
[10:03] <didrocks> waow, crash inside the intel driver
[10:04] <seb128> go intel ;-)
[10:05] <didrocks> seb128: it's all because of you! I took intel because you never had issues with it :)
[10:05] <seb128> I still don't have issues! ;-)
[10:05] <didrocks> and one small crash to completely changed my mind, of course :p
[10:27] <glatzor> hello mvo
[10:27] <glatzor> mvo, I am on the train now so the connection could be a little bit flanky
[10:27] <glatzor> mvo, I updated ubuntu-quantal since we can now drop the test_suite_fixes
[10:28] <mvo> glatzor: aha, ok
[10:28] <mvo> glatzor: I updated it as well :)
[10:28] <mvo> glatzor: so the delay from 0.5s -> 2.5s  is no longer needed?
[10:29] <mvo> glatzor: I don't see a (new) commit in ubuntu-quantal, did you push this yet?
[10:30] <glatzor> mvo, it is still required. But I changed it in upstream
[10:31] <mvo> glatzor: ok
[10:31] <mvo> glatzor: thanks, I updated the quantal branch to point to r846 now
[10:39] <Sweetshark> seb128: https://lists.ubuntu.com/archives/technical-board/2012-June/001310.html heh, Ubuntu/Canonical will just grow itself some mor people comfortable to review LibreOffice commits ;->
[10:39] <seb128> Sweetshark, lol
[10:39] <seb128> good luck to them ;-)
[10:40] <Sweetshark> riight
[10:42] <glatzor> mvo, I haven't tried the simulate test on a build daemon. so this issue could still exist. but perhaps it was just a side effect of another patch
[10:42] <glatzor> test
[10:46] <mvo> glatzor: oh, good to know, lets see
[10:46] <mvo> glatzor: I can alway add it back if it ftbfs
[10:50] <glatzor> mvo, mpt, so what do you think about a aptdaemon.gtk3widgets.SmartErrorDialog ?
[10:50] <glatzor> thanks mvo
[10:53] <glatzor> mvo, I would like to make this re-usable by sessioninstaller and update-manager
[10:57] <glatzor> mvo see you
[11:01] <chrisccoulson> oh, that gnome-settings-daemon crash is i386 only?
[11:01] <chrisccoulson> fun ;)
[11:02] <seb128> chrisccoulson, is it?
[11:03] <seb128> i386 users are nice people, why so much hate :p
[11:03] <chrisccoulson> seb128, yeah, it looks like it
[11:03] <seb128> indeed
[11:06] <chrisccoulson> ok, i'll ask for someone to get a valgrind log whilst i set up a more appropriate environment
[11:06] <chrisccoulson> just in case something tramples over the GOT :)
[11:09] <seb128> chrisccoulson, GOT?
[11:09] <seb128> chrisccoulson, you can grab mterry when he gets online, he was complaining about how annoying the issue is the other day
[11:09] <seb128> chrisccoulson, he can probably get you a valgrind ;-)
[11:09] <chrisccoulson> seb128, the global offset table. the GOT entry will either have a pointer back to the plt (to call in to the linker), or a pointer to the real function
[11:10] <chrisccoulson> but if that gets overwritten, then it will go quite wrong :)
[11:10] <seb128> oh ok
[11:21] <chrisccoulson> seb128, also, rebuilding gnome-settings-daemon with LDFLAGS=-Wl,-z,relro,-z,now would expose if the issue is memory corruption
[11:22] <chrisccoulson> as that would make it crash where the error occurs :)
[11:36] <didrocks> chrisccoulson: FYI, I juts got bug #196058, had to edit the file manually to get it back to not fullscreen
[11:36] <ubot2> Launchpad bug 196058 in thunderbird "Thunderbird starts in a full-screen mode and cannot be restored" [Undecided,Confirmed] https://launchpad.net/bugs/196058
[11:39] <chrisccoulson> didrocks, oh, fun ;)
[11:39] <didrocks> chrisccoulson: I wouldn't use that term TBH ;)
[11:40] <chrisccoulson> didrocks, no, i meant it is fun for me ;)
[11:40] <didrocks> chrisccoulson: you have weird ways of enjoying bugs ;)
[11:43] <seb128> didrocks, heh, he was on my g-s-d plt "fun" first, keep your party for later ;-)
[11:44] <didrocks> seb128: I don't care, I edited the file and it's fine for me. Seems the issue isn't new though (from 2008)
[11:44] <seb128> k ;-)
[12:19] <chrisccoulson> DENIED!
[12:19] <chrisccoulson> "PPA exceeded its size limit (4452.00 of 4096.00 MiB)"
[12:21] <chrisccoulson> oh, fantastic! no crash on i386 for me here ;)
[12:21] <chrisccoulson> i guess mterry will need to feed me information :)
[13:18] <seb128> chrisccoulson, you got a mterry!
[13:19] <seb128> mterry, hey ;-) how are you ?
[13:19] <chrisccoulson> hi mterry!
[13:19] <mterry> uh oh
[13:19] <seb128> mterry, too late to pretend not being here :p
[13:20] <seb128> lol
[13:20] <mterry> What's up?
[13:20] <seb128> mterry, chrisccoulson is looked at the plt g-s-d issue
[13:20] <seb128> mterry, he needs debug infos from you
[13:20] <seb128> mterry, since you get the issue
[13:20] <mterry> seb128, ah yeah, I saw his comment go by.  chrisccoulson, you want valgrind output?
[13:21] <chrisccoulson> mterry, yes please :)
[13:21] <chrisccoulson> i can't seem to recreate it here
[13:46] <seb128> mterry, are you on the valgrind thing or should I give it a try (I can but I don't want to dup work if you started)
[13:46] <mterry> chrisccoulson, really? interesting.  I uploaded a valgrind
[13:46] <mterry> seb128, sorry, I got delayed, but it's there now
[13:47] <seb128> mterry, np, you are on i386 right?
[13:47] <mterry> seb128, yup
[13:47] <mterry> i386 4 eva
[13:48] <seb128> ;-)
[13:48] <seb128> ==26228== Invalid read of size 4
[13:48] <seb128> ==26228==    at 0x1027EF00: ??? (in /usr/lib/gnome-settings-daemon-3.0/libmouse.so)
[13:48] <seb128> ==26228==    by 0x10281EC4: gsd_mouse_manager_idle_cb (gsd-mouse-manager.c:1124)
[13:48] <seb128> tadada
[13:49] <seb128> I wonder why the first frame lacks symbols when the second one has the infos
[14:00] <desrt> wow.  as if you need more than 3 lines in order to know exactly what the problem is there
[14:01] <mterry> seb128, because the first frame is the plt magic.  probably doesn't correspond to a given line
[14:01] <seb128> mterry, could be yes
[14:02] <seb128> desrt, the log is longer than that, I didn't want to flood the channel ;-) https://bugs.launchpad.net/ubuntu/+source/gnome-settings-daemon/+bug/1007588/+attachment/3189382/+files/valgrind.log
[14:02] <ubot2> Ubuntu bug 1007588 in gnome-settings-daemon "[mouse]: gnome-settings-daemon SIGSEGV in gdk_device_manager_list_devices@plt()" [High,Confirmed]
[14:02] <desrt> seb128: i wasn't being sarcastic. totally classic class of problem
[14:02] <desrt> and it always has exactly one of two solutions
[14:03] <desrt> the problem is that someone dispatches an idle then destroys the object before the idle has a chance to run
[14:03] <desrt> the solutions:
[14:03] <desrt> 1) have the idle itself hold a ref on the object and free it from the handler function
[14:03] <desrt> 2) when scheduling the idle, save the source ID number and cancel it from the finalize of the object, if pending
[14:04] <seb128> desrt, weird think is that this issue just happens on i386 when building with gcc 4.7
[14:04] <seb128> desrt, precise with gcc 4.6 with the same gtk and g-s-d has no bug
[14:04] <desrt> seb128: it's probably an issue on the other platforms too, but you 'get lucky'
[14:04] <seb128> chrisccoulson, ^
[14:04] <desrt> these kinds of errors are so common all over GNOME that i'd hesitate quite a lot to finger gcc
[14:06] <seb128> desrt, well, we got 0 of those issues in precise, the code didn't change and we get a lot of this in quantal after a rebuild, and people said that rebuilding on gcc 4.6 "fixes" it
[14:06] <chrisccoulson> mterry, seb128, thanks. will look in a few moments
[14:06] <seb128> but yeah, maybe for some reason we get "lucky" and the code generated by gcc 4.6 is on the right side of the race :p
[14:07] <desrt> huh
[14:07] <desrt> http://git.gnome.org/browse/gnome-settings-daemon/commit/?id=e98c9079eec9cd9f6f27dd7813d96d6ba536e6c2
[14:07] <desrt> ^ should have fixed that bug
[14:08] <mterry> desrt, I don't think this is a classic idle callback bug.  It's dying in the plt code for handling shared libraries
[14:08] <desrt> ya...
[14:08] <desrt> i'm starting to agree
[14:08] <desrt> now that i see that the bug got fixed over a year ago
[14:08] <desrt> it used to be a classic idle bug ;)
[14:09] <seb128> ;-)
[14:11] <chrisccoulson> yeah, i don't think it's that either
[14:11] <chrisccoulson> although, i was hoping to see an invalid write in the valgrind log
[14:11] <chrisccoulson> damn ;)
[14:12] <chrisccoulson> mterry, this is easy for you to reproduce?
[14:13] <desrt> one more possibility
[14:13] <desrt> this is a plugin, right?
[14:14] <desrt> is it possible that the plugin is unloaded when the idle fires?
[14:14]  * desrt takes that back because of the proper cancelling...
[14:16] <mterry> chrisccoulson, every time
[14:17] <chrisccoulson> mterry, and the trigger is changing your monitor resolution?
[14:18] <mterry> chrisccoulson, no, the trigger is just doing nothing.  The bug has some misleading data about monitors, but it has nothing to do with that
[14:18] <mterry> chrisccoulson, if I just wait a few seconds, it will crash
[14:18] <chrisccoulson> mterry, oh, that makes more sense
[14:18] <chrisccoulson> thanks!
[14:18] <mterry> I've been living unthemed for a while.  :(
[14:18] <chrisccoulson> ok, i'll try again in a second
[14:19]  * desrt thinks chrisccoulson and mterry get to spend the next 3 days performing the fun task of reducing this crash to an irrefutable testcase to present to doko
[14:20] <desrt> (or finding the real bug on the way...)
[14:20] <chrisccoulson> heh
[14:20]  * chrisccoulson fires up kvm again
[14:51] <chrisccoulson> mterry, it still isn't crashing here. could you make it crash again in gdb please, and show me the output of "info registers"? :)
[14:51] <mterry> chrisccoulson, yup!
[14:53] <mterry> chrisccoulson, http://pastebin.ubuntu.com/1040903/
[14:53] <chrisccoulson> mterry, thanks
[14:56] <chrisccoulson> oh my
[14:56] <chrisccoulson> ebx            0x0
[14:56] <chrisccoulson> that's meant to be the base address of the got :)
[14:57] <chrisccoulson> i guess that's where the "invalid read at address 0x38" comes from in your valgrind log
[14:57] <chrisccoulson> this is going to be fun
[15:05] <chrisccoulson> mterry, ok, could you try again please, but this time do "watch $ebx == 0x0"?
[15:05] <mterry> chrisccoulson, sure
[15:05] <chrisccoulson> hopefully you will hit that once, be able to get a stacktrace, and when you continue you should hopefully see it crash
[15:05] <chrisccoulson> fingers crossed :)
[15:06] <mterry> ok, I hit the breakpoint
[15:06] <chrisccoulson> excellent
[15:07] <mterry> chrisccoulson, do you want a dump of registers every time I hit the watch point?
[15:07] <chrisccoulson> mterry, just a stacktrace. are you hitting it more than once?
[15:07] <chrisccoulson> i was hoping it would just be once :)
[15:07] <mterry> chrisccoulson, oh, I see your above comment
[15:08] <mterry> chrisccoulson, yah, all over the place
[15:08] <chrisccoulson> mterry, and it's always a different call stack?
[15:09] <mterry> chrisccoulson, yeah mostly
[15:09] <chrisccoulson> hmmm, that's a shame
[15:09] <mterry> chrisccoulson, I can send some of them to you?
[15:09] <chrisccoulson> yeah, i can take a look
[15:09] <chrisccoulson> thanks
[15:10] <mterry> chrisccoulson, http://pastebin.ubuntu.com/1040940/
[15:11] <chrisccoulson> mterry, oh, of course. it might be better to first break on main, and then set up the watch
[15:11] <chrisccoulson> to get all of the linker stuff out of the way first :)
[15:11] <mterry> chrisccoulson, k, will do
[15:13] <mterry> chrisccoulson, now I'm going through a bunch of locale loading.  hopefully it will end soon
[15:13] <seb128> mterry, restart it, break on main, once you hit it, add the break on ebx
[15:14] <seb128> that should be easier
[15:14] <mterry> seb128, that's what I did
[15:14] <mterry> setlocale is after main
[15:15] <mterry> parse args also does some similar things...
[15:15] <chrisccoulson> hmmm, that's a pain :(
[15:24] <mpt> mvo, do you know what glatzor meant by "aptdaemon.gtk3widgets.SmartErrorDialog"?
[15:28] <mterry> chrisccoulson, now I'm getting some from the plugin loads
[15:33] <mvo> mpt: I think he means that apps need removing when fixing broken dependencies
[15:33] <mvo> mpt: i.e. instead of saying "the package gedit-foo needs rmoeval" he wants to show reall appname and icon
[15:35] <mpt> mvo, that would be nifty. I sketched that dialog at <https://wiki.ubuntu.com/SoftwarePackageOperations#broken>, but showing real application names would be a great improvement.
[15:35] <seb128> chrisccoulson, mterry: can't you script gdb to bt, c automatically when it reach those b?
[15:35] <seb128> chrisccoulson, and look at the log what was the last bt before the segfault?
[15:36] <mterry> seb128, ooh
[15:36] <seb128> mterry, http://stackoverflow.com/questions/2388799/automate-gdb-show-backtrace-at-every-call-to-function-puts
[15:36] <mterry> I forgot gdb could do that
[15:37] <seb128> mterry, something like that?
[15:37] <mterry> yah, just a simple bt; c should do
[15:37]  * mterry waits for next natural break
[15:39] <chrisccoulson> heh, i should remember how to do that too :)
[15:40] <mterry> chrisccoulson, OK, commands set.  It will still take some time to get results.  It's really slow when it has to watch that register
[15:40] <chrisccoulson> yeah, i can imagine :)
[15:53]  * mpt wonders idly about dropping the "Statistics" tab from Software Sources
[15:57] <seb128> mpt, move it to the privacy panel in system settings?
[15:57] <mpt> seb128, ooh, good idea
[16:00] <mpt> If we're not careful, though, soon we'll end up with people sending their software inventory in three different ways: USC recommendations, metrics, and popcon
[16:01] <Laney> I wonder if that panel shouldn't be protected by your password
[16:01] <seb128> mpt, that's a good point, I'm not sure popcon has ever been a good metric, we should perhaps just drop it
[16:01] <Laney> it's likely to be a place where you note down stuff you'd rather other people not see
[16:01] <seb128> Laney, your keyring is not protected by your password, why would that panel be?
[16:01] <seb128> Laney, if somebody got physical access to your user account you are screwed anyway
[16:02] <mpt> Oh, not three ways. Four. With the fourth being OneConf. :-)
[16:02] <seb128> Laney, same for i.e your firefox passwords
[16:02] <Laney> I'm not talking about the sophisticated attacker here
[16:02] <Laney> but yes, those could be protected too
[16:02] <Laney> but creating a false sense of security is probably a valid argument against doing it
[16:02] <seb128> Laney, I don't need to be a sophisticated attacker, if I've access to your email I can read your email, user your webbrowser to connect to any of the site you stored credential for, etc
[16:03] <seb128> if I've access to your account*
[16:03] <seb128> Laney, I don't think the infos in that panel are sensitive over i.e emails
[16:04] <seb128> mpt, yeah, let's drop popcon ... want to email ubuntu-devel to suggest that?
[16:05] <chrisccoulson> mterry, is it still going?
[16:06] <mterry> chrisccoulson, yes
[16:06] <chrisccoulson> mterry, oh, i didn't expect it to take this long :)
[16:06] <chrisccoulson> i hope this turns out to be worthwhile
[16:07] <chrisccoulson> i wouldn't want to waste your time ;)
[16:07] <chrisccoulson> micahg, what's happening with bug 1010466?
[16:07] <ubot2> Launchpad bug 1010466 in unity-2d "dropdown boxes on sites stop working" [Medium,In progress] https://launchpad.net/bugs/1010466
[16:07] <micahg> chrisccoulson: natty didn't build, waiting to hear back
[16:07] <chrisccoulson> micahg, hear back from?
[16:08] <micahg> chrisccoulson: didrocks or sil2100
[16:08] <didrocks> micahg: sil2100 told me that he saw that with you
[16:08] <micahg> didrocks: ah, yeah, he fixed it already :)
[16:09]  * micahg will get that uploaded
[16:09] <micahg> should go out today then
[16:09] <chrisccoulson> thanks
[16:10] <mpt> seb128, yep. That would get it from four down to three. I just discussed it briefly with ev, and he has vague ideas to get from three down to one. :-)
[16:58] <mterry> chrisccoulson, still not done.  :(
[16:59] <chrisccoulson> mterry, oh :(
[17:00] <chrisccoulson> that is taking much longer than i thought it would ;)
[17:00] <mterry> dconf reads also trigger the read...
[17:00] <mterry> the watch I mean
[17:01] <chrisccoulson> it's all desrt's fault!
[17:01] <chrisccoulson> :)
[17:08]  * didrocks waves good evening
[17:08]  * desrt wonders what's going on
[17:23] <seb128> desrt, don't pretend it's not your fault! ;-)
[18:31] <bcurtiswx> hey kenvandine , i have a friend who changed their default group to be 'users' and now empathy has write permission errors for items that allow for logging and saving connections
[18:32] <bcurtiswx> bug #1013921
[18:37]  * kenvandine wonders where the url is from the bot
[18:39] <kenvandine> bcurtiswx, ubot2 must be upset with us
[18:39] <bcurtiswx> ok, so it isn't my machine.. thought it was
[18:39] <kenvandine> bcurtiswx, oh... i can't find a bug with that number
[18:40] <bcurtiswx> bug #1013291
[18:40] <ubot2> Launchpad bug 1013291 in empathy "changing users default group causes file write permissions" [Undecided,New] https://launchpad.net/bugs/1013291
[18:40] <bcurtiswx> i see what I did there
[18:42] <bcurtiswx> file write permission errors**
[18:46] <kenvandine> oh
[18:48] <bcurtiswx> anyways, the user changed their default group in /etc/group to 'users' and it seems to have caused empathy issues in saving items
[18:48] <kenvandine> bcurtiswx, that is apparmor related
[18:48] <kenvandine> i don't think it is the group
[18:49] <kenvandine> it is the homedir
[18:49] <kenvandine> look at /etc/apparmor.d/tunables/home
[18:50] <kenvandine> bcurtiswx, you can edit /etc/apparmor.d/tunables/home.d/ubuntu
[18:50] <bcurtiswx> kenvandine, so that should be @{HOMEDIRS}=/heise1/ ?
[18:50] <kenvandine> yeah
[18:51] <kenvandine> @{HOMEDIRS}=/home/ /heise1/
[18:51] <kenvandine> i guess
[18:51] <kenvandine> it is a space separated list
[18:51] <bcurtiswx> in home.d/ubuntu or just home ?
[18:52] <kenvandine> you put overrides in /etc/apparmor.d/tunables/home.d/ubuntu
[18:52] <bcurtiswx> ok
[18:52] <kenvandine> the packaged defaults are in the other
[18:52] <kenvandine> this is probably breaking more than telepathy
[18:52] <bcurtiswx> so should we worry about this not changing if a user changes their home directory and doesn't know to change anything else?
[18:53] <kenvandine> not sure what we can do to help them :/
[18:53] <bcurtiswx> hmm
[18:54] <bcurtiswx> that just seems bad though...
[18:54] <bcurtiswx> brb
[18:55] <kenvandine> bcurtiswx, pretty much everything that ships an apparmor profile relies on @{HOME}
[18:55] <kenvandine> users shouldn't really change their homedir without knowing the implications... but there isn't really a good way to warn them
[19:00] <bcurtiswx> they used the command 'usermod'
[19:02] <bcurtiswx> kenvandine, you'd think if thats the case then using usermod would know to change that value as well
[19:03] <kenvandine> or warn them that it probably isn't a good idea :/
[19:05] <bcurtiswx> either way there needs to be something done so basic desktop functionality isn't lost with a change of the homedir. IDK how often this happens or not though...
[19:15] <seb128> bcurtiswx, change user directory doesn't seem a real usecase but rather a "what can I do to break my system" thing
[19:16] <seb128> bcurtiswx, the users who know how to do that should know better
[19:22] <bcurtiswx> seb128, can't disagree, just wanted to make sure it wasn't something we should fix that we are not.
[19:27] <bcurtiswx> kenvandine, thanks :)
[19:27] <kenvandine> bcurtiswx, np
[22:05] <thumper> robert_ancell: morning
[22:05] <thumper> robert_ancell: how can I test out your new pango fix?
[22:05] <robert_ancell> thumper, hello
[22:05] <robert_ancell> thumper, install quantal?
[22:05] <thumper> robert_ancell: I'd like to run valgrind again and see if it is good
[22:05] <thumper> robert_ancell: so... about precise...
[22:05] <robert_ancell> thumper, it's not too hard to do a precise package
[22:06] <thumper> robert_ancell: I think it would me nice to SRU, as it effects every app that uses pango to draw text
[22:06] <thumper> robert_ancell: which is a lot (I think)
[22:06] <robert_ancell> thumper, can you write out the SRU for it?
[22:06] <robert_ancell> I can see the bug, but I don't know how severe it is
[22:07] <thumper> hmm.. I wonder if I can convince a minion to do it :)
[22:16] <robert_ancell> thumper, ok, I did all the SRU stuff in bug 837145, you just need to write the test case for it
[22:16] <ubot2> Launchpad bug 837145 in pango1.0 "Memory leak in pango_layout_get_extents" [Undecided,Fix released] https://launchpad.net/bugs/837145
[22:17] <thumper> robert_ancell: ok, thanks... I'll try to get to this this afternoon
[22:31] <robert_ancell> RAOF, do you do SRUs?
[22:36] <thumper> robert_ancell: do you know what type of details are needed for a test-case?
[22:36] <thumper> so far we just use valgrind
[22:40] <robert_ancell> thumper, yeah, I was just going to check with someone like RAOF how detailed they need to be.
[22:40] <thumper> robert_ancell: ok, cool
[22:40] <robert_ancell> They normally need to be pretty clear, i.e. "run these commands"
[22:40] <thumper> :)
[22:41] <robert_ancell> the program needs a bit of specialised valgrind knowledge to know how to test.  And at least for me it shows so many errors it's not clear which one is being fixed!
[22:41] <thumper> robert_ancell: I'd like to run valgrind locally (precise) with the fixed version
[22:42] <RAOF> We'd really like the test case to be detailed enough that an educated non-expert could run and verify it.
[22:44] <RAOF> Well, what we *really* want is some assurance that it'll *actually* get verified. A test case that anyone can run is one way of helping to ensure that.
[22:47] <robert_ancell> thumper, ^
[22:48] <thumper> ok
[22:48] <thumper> if I can work out how to run the test locally, that'd be as start :)
[22:48] <thumper> robert_ancell: what is the easiest way for me to get a precise version that is fixed?
[22:48] <thumper> robert_ancell: compile it myself? or can we get something in a ppa?
[22:49] <robert_ancell> thumper, bzr-buildpackage from lp:~robert-ancell/pango/precise-lp-837145
[22:50] <robert_ancell> will do it, then dpkg -i
[22:50] <thumper> ok, thanks, I'll try this shortly
[22:50] <robert_ancell> I've uploaded it to precise-proposed, but that's no use until the test case is there and it is approved right RAOF?
[23:00] <RAOF> robert_ancell: You can get the source out of the unapproved queue, but you're right; it won't build until it's accepted, and it won't be accepted until it's got a test case.
[23:01] <robert_ancell> a vicious circle!
[23:06]  * micahg would think it's more like a rainbow leading to a pot of build time :)
[23:22]  * thumper builds in an attempt to determine a good test case
[23:23] <thumper> robert_ancell: ok, so I'm building your pango package now
[23:23] <thumper> robert_ancell: I trust that dpkg -i will install the package
[23:23] <thumper> robert_ancell: how can I switch between them?
[23:23] <thumper> robert_ancell: just dpkg -i the existing deb?
[23:23] <thumper> you can tell I'm not really an ubuntu dev
[23:23] <robert_ancell> yeah, you need to get the old debs to do that
[23:24] <robert_ancell> I just download them from https://launchpad.net/ubuntu/+source/pango1.0, but I think you can do it cleverly through apt
[23:25] <robert_ancell> or they may be in /var/cache/apt/archives/ still
[23:25]  * thumper needs build-dep for pango1.0
[23:25] <thumper> grabbing
[23:26] <thumper> robert_ancell: I see a libpango1.0 in /var/cache/apt/archives
[23:26] <thumper> that's probably it...
[23:44] <thumper> robert_ancell: the builddeb failed on the signing at the end ('cause I don't have your key), but I'm guessing that is the last step?
[23:44] <thumper> robert_ancell: there is a buildir that has debs in it
[23:45] <thumper> robert_ancell: I'm assuming they are ok?
[23:45] <thumper> robert_ancell: also, there is a gir1.2-pango-1.0_1.30.0-0ubuntu3.1_amd64.deb package, do I need that for your memleak fix?
[23:45] <TheMuso> thumper: if using bzr-builddeb to build a package, add -- -uc -us at the end of the command line arguments so that no attempt is made to sign the package.
[23:45] <thumper> TheMuso: thanks for that
[23:46] <TheMuso> I use that a lot when testing packages, and only sign, or build/sign when I'm satisfied with the results.
[23:46] <TheMuso> Useful when working on sponsoring other people's work too.
[23:48] <TheMuso> And np.
[23:54] <thumper> the -dbg package, is that just the symbols?
[23:54] <RAOF> Yup.
[23:54] <RAOF> You might want them, for valgrind's benefit. Or not.
[23:57] <thumper> yeah, was going to :)
[23:59]  * RAOF resists the urge to complain about Debian's backward-arse debugging infrastructure.
[23:59] <RAOF> But does so unsuccessfully!