[00:09] <Logan_> hi ochosi :)
[00:09] <ochosi> hey Logan_ 
[00:09] <ochosi> good to see you around :)
[00:14] <Logan_> bluesabre: any reason why this isn't in Utopic first?
[00:15] <bluesabre> Logan_: no particular reason, seemed more important to get it to trusty
[00:15] <bluesabre> but yeah, it should also make its way to utopic
[00:15] <bluesabre> so if you're up for uploading it... :-)
[00:15] <Logan_> > Check that the bug is fixed in the current development release, and that its bug task is "Fix Released". It is, in general, not appropriate to release bug fixes for stable systems without first testing them in the current development branch.
[00:16] <Logan_> I mean, this is just the adding of a Recommends, but it's still standard procedure :P
[00:16] <bluesabre> ah
[00:16] <Logan_> and does this change need to go to any other stable releases?
[00:16] <bluesabre> I filed the sru before utopic was open I think
[00:17] <bluesabre> no other stable releases
[00:17] <Logan_> ok
[00:18] <Logan_> I'll just change the target to utopic and upload to there (with you as the author in the changelog)
[00:18] <Logan_> and then I'll upload the SRU
[00:19] <ochosi> Logan_: actually we have a second SRU for you... :)
[00:19] <Logan_> link?
[00:20] <ochosi> i haven't filed the bugreport yet, but the lightdm-gtk-greeter 1.8.5 release
[00:20] <ochosi> https://launchpad.net/lightdm-gtk-greeter/1.8/1.8.5
[00:20] <ochosi> this is actually a good summary, as it is very short ^
[00:20] <Logan_> bluesabre: also, the "verification-needed" tag is generally only added by the SRU team after it's in proposed, so I'll remove that from the bug
[00:21] <bluesabre> thanks Logan_
[00:21] <ochosi> +^
[00:21] <ochosi> +1
[00:44] <ochosi> Logan_: if you can upload the greeter release to utopic too, that'd be a great start. i can try to get the paperwork ready tomorrow for the SRU
[01:10] <ali1234> okay, so the thunar crash changes depending on how many times you repeat the failed unmount
[01:10] <ali1234> and it also changes depending on whether it uses g_slice or malloc
[01:10] <ali1234> so there is definitely memory corruption of some kind
[01:12] <ali1234> so i figure repeating the unmount long enough will cause the crash without having to quit
[01:26] <ali1234> hmm well i fixed a gtk critical, but it wasn't the bug
[01:43] <ali1234> hmmmm
[01:43] <ali1234> so the crash changes depending on what view mode is in use, icons/list etc
[01:43] <ali1234> because each is a different component
[01:43] <ali1234> and it is this bit of memory that gets corrupted
[01:53] <ali1234> hmm
[02:01] <ali1234> getting somewhere... certainly looks like the early unref during failed unmount theory is correct
[02:02] <ali1234> the unmount operaton is done by glib and thunar passes in a bunch of callbacks
[02:09] <ali1234> wow... it's not the user callback
[02:18] <ali1234> it's not even the main callback... this makes no sense
[02:18] <ali1234> basically, calling g_mount_unmount_with_operation corrupts memory. the end
[02:23] <ali1234> hmmmmmmm okay
[02:23] <ali1234> the failed unmount part isn't even necessary
[02:24] <ali1234> all yohave to do is mount and unmount the same device 3 times then quit -> crash
[02:24] <ali1234> so i've been looking in the wrong place
[02:29] <ali1234> it has to be three times though
[02:31] <drc> " I have said it thrice: What i tell you three times is true."
[02:31] <ali1234> https://www.youtube.com/watch?v=xOrgLj9lOwk
[02:31] <drc> That was my second choice :)
[02:35] <ali1234> any three will work too. you can mount then unmount three different drives and it still crashes
[02:35] <ali1234> no wonder it happens so much
[02:39] <drc> I haven't been paying real close attention...this is mounting/unmounting drives in thunar with 14.04?
[02:39] <ali1234> yeah, or 13.10
[02:39] <ali1234> although not tested with 13.10 there's just as many error reports from there
[02:39] <ali1234> and other distros too
[02:39] <drc> and usb external drives count?
[02:39] <ali1234> yes
[02:40] <ali1234> seems like it happens with anything that you can mount
[02:40] <drc> ok, I've plugged in 2 external usb drives and a usb thumb drive.  Now use thunar to unmount them?
[02:40] <ali1234> you only need one
[02:40] <ali1234> start with them unmounted
[02:41] <ali1234> mount then unmount three times, then quit thunar
[02:41] <drc> bingo
[02:43] <ali1234> the only change i can make in the code that prevents the crash is to not call g_mount_unmount_with_operation
[02:44] <ali1234> it still crashes, even if i hand it a no-op callback
[02:45] <drc> huh, using 3 different drive does not crash.
[02:46] <ali1234> it does for me...
[02:46] <ali1234> it also depends on which type of file view you have selected
[02:46] <ali1234> icon view is easiest and most consistent
[02:47] <drc> That's what I was using...still no crash with 3 different drives.
[02:47] <ali1234> this is a memory corruption bug so results are pretty random
[02:48] <drc> well, they say that the memory is the second thing to go :)
[02:52] <drc> nope, can't make it crash with 3 different drives, one drive thrice, everytime.
[02:55] <ali1234> hmm well here's a thng, it only happens with the shortcuts sidepanel, not the tree sidepanel
[02:56] <drc> I use the shortcuts panel.
[02:56]  * drc has a feeling that he's messing up ali1234's thinking.
[02:58] <ali1234> HMM
[02:58] <ali1234> hmmmmmm... this is a tricky one
[02:59] <ali1234> commenting: thunar_shortcuts_model_set_busy (THUNAR_SHORTCUTS_MODEL (child_model), device, TRUE);
[02:59] <ali1234> seems to prevent the crash
[03:03] <ali1234> and now we hit some gdk_threads code...
[03:04] <drc> good hunting...bed time :)
[03:15] <ali1234> maybe it isn't anything to do withunmounting... maybe it is the mounting
[03:17] <ali1234> argh... neither works.
[03:26] <ali1234> lol... 3 times crashes... 2 times doesn't crash, and 4 times doesn't crash
[03:27] <ali1234> 5 is right out...
[03:27] <ali1234> 6 crashes
[03:28] <ali1234> 9 crashes
[03:29] <ali1234> 8 does not
[04:18] <ali1234> i think i've figured it out...
[04:23] <ali1234> well, i've at least narrowed it down
[04:42] <Unit193> Logan_: Nope.
[05:12] <ali1234> https://bugzilla.gnome.org/show_bug.cgi?id=723366
[05:12] <ali1234> pretty sure this is the problem
[05:17] <ali1234> aaaaaand... we don't have the fix in trusty
[05:20] <ali1234> yeah, they patched it in gtk3 and not gtk2
[05:33] <ali1234> this explains why i could not catch the memory corruption happening... the invalid signal causes corruption when you close the window
[05:33] <ali1234> ie the corruption did not happen until you quit thunar
[06:38] <ali1234> morning elfy. i figured out the thunar bug. it's a gtk bug :(
[06:40] <elfy> ali1234: yea read the backlog 
[06:40] <elfy> thanks for finding it :)
[06:53] <ochosi> ali1234: congrats
[07:01] <ochosi> so if it's a bug in gtk, we gotta SRU the patch/fix for trusty
[07:01] <ochosi> should be doable
[07:11] <ali1234> it's a trivial patch, we just need someone to upload it in gtk+2.0
[07:12] <ochosi> yup, already asked in -desktop, but there's a dead silence there
[07:12] <ali1234> it's a bit early for them still
[07:12] <ochosi> depends, during the "hot phase" of trusty they were around :)
[07:13] <ali1234> i mean early in the day. it's 8 AM, they're probably still eating breakfast
[07:14] <ochosi> sure
[07:14] <ochosi> mmm, breakfast
[07:14] <ochosi> i think you just gave me an idea
[08:18] <brainwash> ali1234: nice work :)
[08:19] <brainwash> does this mean that every other distro is affected too?
[08:22] <ali1234> yes
[08:24] <brainwash> and why does it not crash when the user clicks the unmount icon?
[08:24] <ali1234> because it is random memory corruption
[08:24] <brainwash> ah ok
[08:25] <ali1234> hence the monty python references
[08:25] <ali1234> you have to call a specific function exactly three times
[08:25] <ali1234> three is the number and the number shall be three
[08:26] <ali1234> probably if you called eject the right number of times it would also crash
[08:27] <brainwash> I see
[08:27] <ali1234> essentially what happens is that when you do a mount or unmount operation, you register a parent window for any dialogues that will get opened (like password stuff)
[08:27] <brainwash> but only gtk3 has been patched? the upstream report was filed against gtk2
[08:27] <ali1234> gtk registers a signal on that window
[08:28] <ali1234> when the operation finishes it deletes the operation object, but doesn't unregister the signal
[08:28] <ali1234> when the window gets deleted (when you quit thunar) it calls that signal, which trashes memory
[08:28] <ali1234> so the corruption never happens until you quit
[08:28] <ali1234> which is why it was so hard to debug
[08:28] <brainwash> thanks for explaining this :)
[08:28] <ali1234> and yes only gtk2 was patched
[08:29] <ali1234> i mean gtk3
[08:29] <brainwash> but gtk2 should be still somewhat maintained.. or?
[08:30] <brainwash> I don't quite understand why they skipped gtk2 in this case
[08:30] <ochosi> just talked to seb128 in -desktop, we can file a bugreport, attach the patch and go for SRU
[08:31] <ochosi> ali1234: so there's no patch for gtk2 yet? i presume it will be pretty much the same though, right?
[08:31] <ali1234> it's identical
[08:31] <ali1234> the original bug report patch was against gtk2, but mclasen only applied it on gtk3 anyway
[08:32] <ochosi> right
[08:32] <ochosi> very nice...
[08:32] <ochosi> anyway, let's get that going
[08:32] <ochosi> gotta get some late breakfast, then i can write up that bugreport
[08:32] <ochosi> i guess the patch needs to be slightly altered (comment removed?)?
[08:32] <brainwash> mmh, so we have to do the sru work :D
[08:32] <ochosi> well, we need it
[08:33] <ochosi> as opposed to practically all others
[08:33] <ochosi> (apart from lxde maybe)
[08:33] <ochosi> (and studio)
[09:14] <slickymasterWork> elfy, you around?
[09:14] <elfy> yep
[09:15] <slickymasterWork> good morning
[09:15] <elfy> good morning to you :)
[09:15] <slickymasterWork> one thing about your xfce4 Mouse Settings proposal
[09:16] <elfy> yep
[09:17] <slickymasterWork> you're just proposing to change the designation of each step, right?
[09:17] <elfy> yep
[09:17] <slickymasterWork> ok, just want to confirm that
[09:17] <slickymasterWork> I'll have a review for you in about 30 minutes
[09:18] <elfy> only actually doing it because I had some real ones to do - otherwise I'd not have bothered :)
[09:19] <slickymasterWork> well, some of them really need some rewording, which it's mainly what your MP seems to be about
[09:20] <slickymasterWork> one other thing elfy, presently the test ask to <dt>Click the "Devices" tab</dt> -> <dt>Click the "Device:" menu</dt>
[09:21] <slickymasterWork> I think it should be changed to <dt>Click the "Devices" tab</dt> -> <dt>Click the "Device:" drop down list</dt>
[09:22] <elfy> write things on the MP - I'll read them there - otherwise I'll get confused - just working through the other optional stuff here 
[09:24] <slickymasterWork> ok, will do
[09:48] <ochosi> ali1234: do you have an overview of the related thunar bugreports on launchpad?
[09:48] <ali1234> overview?
[09:48] <ali1234> there's like 50 of them
[09:48] <ochosi> all marked as duplicates?
[09:49] <ali1234> yeah, and even more not marked probably
[09:49] <ochosi> i'd like to link to a list or include them somehow in the SRU report
[09:49] <ochosi> i've written that one up now
[09:49] <ochosi> and am going to follow it up in -desktop
[09:49] <ali1234> https://bugs.launchpad.net/ubuntu/+source/thunar/+bug/1203296
[09:50] <ochosi> launchpad is killing me today
[09:50] <ali1234> i've already marked that against gtk+2.0 and the upstream gnome bug
[09:50] <ochosi> i had to submit that bugreport 5 times because it kept timing out
[09:50] <ali1234> yeah i've been getting that all night too
[09:50] <ali1234> bank holiday, everything falls apart
[09:50] <ali1234> they're probably putting out the fires about now
[09:51] <ochosi> mhm
[09:51] <ali1234> so anyway, that's the meta report for all this junk
[09:52] <ali1234> the explanation given on the gnome bug is the most concise though
[09:52] <ali1234> https://bugzilla.gnome.org/show_bug.cgi?id=723366
[09:52] <ochosi> yup
[09:53] <ochosi> already added that to my report
[09:53] <ochosi> here it is btw: https://bugs.launchpad.net/gtk/+bug/1316509
[09:54] <ali1234> mark 1203296 as duplicate :)
[09:54] <ochosi> so ubuntu sponsors are processing this now, we just have to monitor it a bit
[09:54] <ali1234> nice work :)
[09:54] <brainwash> why didn't you reuse the existing bug report?
[09:55] <brainwash> just curious
[09:55] <ali1234> it's a bit messy after i added loads of bug watches and it imported the comments
[09:55] <brainwash> ah, makes sense
[09:55] <ochosi> yeah, for sru you want something cleaner
[09:55] <ochosi> so it gets processed faster
[09:56] <ochosi> darn, lp times out again on setting the duplicates...
[09:56] <ali1234> well, i suggest actually marking the other duplicate after it gets fixed
[09:56] <ali1234> to keep out "me too" noise
[09:56] <ali1234> that's assuming it gets fixed relatively quickly of course
[09:57] <ochosi> yeah
[09:57] <ochosi> i already linked to the bugreport anyway
[09:57] <ochosi> so i guess we can leave it at that for now
[09:58] <ochosi> btw, i took the patch directly from upstream
[09:58] <ochosi> i hope it applies on gtk2 in ubuntu
[09:58] <ochosi> had no time to look at that
[09:58] <ochosi> but if not, it should be fairly straight-forward to modify it accordingly
[09:59] <ali1234> yeah in gtk3 they removed the comment
[09:59] <ali1234> https://git.gnome.org/browse/gtk+/commit/gtk/gtkmountoperation.c?h=gtk-3-12&id=05f2f634260519b5448ffd53e8883412c0251443
[10:00] <ali1234> looks like he quietly fixed a load of other bugs at the same time :(
[10:01] <ochosi> maybe he felt ashamed because of them and hence tried to sneak the fixes in ;)
[10:07] <ali1234> yeah that patch also fixes a memory leak in set_parent
[10:08] <ali1234> we can put a workaround in thunar to call set_parent(NULL) before unref'ing the mountoperation
[10:08] <ali1234> this will prevent the crash, but cause a harmless memory leak, when gtk is not patched
[10:09] <ochosi> i asked in the upstream bugreport about getting the patch to gtk2 as well
[10:09] <ochosi> since folks in -desktop got all defensive about this being a simple oversight :)
[10:09] <elfy> lol
[10:09] <ali1234> heh
[10:10] <ali1234> that would be the best resolution. get a patched gtk2 in U and then SRU it back from there
[10:10] <ali1234> we might get the memory leak fixed then too
[10:11] <ochosi> yup
[10:11] <ochosi> that's the plan
[10:12] <ali1234> man, i chased this bug all over the code
[10:12] <ali1234> i ended up implementing a menu item labelled "crash" with the minimum code required to trigger it
[10:13] <ochosi> hehe
[10:13] <ochosi> well, nice work though!
[10:13] <ochosi> for the first time it looks like this will be fixed in due time
[10:14] <ali1234> got it down to this: http://paste.ubuntu.com/7403729/ and i was like, "well, this has to be a Gtk bug." then i found the report
[10:14] <ochosi> holy crap, that's quite condensed :)
[10:21] <slickymasterWork> elfy, enlighten me something. In the 1575_Xfce4 Appearance Settings test you kept <dt>From the launcher panel, click on the "Settings Manager" icon.</dt>
[10:22] <slickymasterWork> this is not valid anymore, or am I crazy?
[10:22] <ochosi> ali1234: have you tested the gtk patch btw?
[10:22] <ali1234> no :P
[10:22] <ali1234> but i am 99.999% certain it is the cause
[10:23] <ochosi> wanna join the discussion on -desktop
[10:23] <ochosi> ?
[10:23] <ali1234> okay
[10:23] <ochosi> ty
[10:24] <elfy> slickymasterWork: if it looks like I missed something - note it :)
[11:19] <slickymasterWork> elfy, https://code.launchpad.net/~elfy/ubuntu-manual-tests/XFCEOptional/+merge/218310 <- done
[11:19] <elfy> slickymasterWork: thanks :)
[11:20] <slickymasterWork> not sure if you'll agree with some of the suggestions elfy :P
[11:20] <elfy> I just did the catfish MP - that's all from the batch I just checked \o/ 
[11:21] <slickymasterWork> elfy, do you want me to also review the catfish MP?
[11:21] <elfy> slickymasterWork: you can when you've time :)
[11:22] <slickymasterWork> past me the link, please
[11:22] <elfy> https://code.launchpad.net/~elfy/ubuntu-manual-tests/1315491/+merge/218389
[11:22] <slickymasterWork> ok, thanks
[11:33] <slickymasterWork> elfy, https://code.launchpad.net/~elfy/ubuntu-manual-tests/1315491/+merge/218389 <- done
[11:34] <elfy> awesome slickymasterWork :)
[12:06] <elfy> slickymasterWork: pushed the big one back with the changes - if you want to doublecheck 
[12:24] <elfy> o/ amigamagic 
[12:24] <amigamagic> \o elfy
[12:38] <ali1234> thunar crash fix is now available at: https://launchpad.net/~a-j-buxton/+archive/gtk2mountop
[12:38] <ali1234> works for me, please test :)
[12:57] <elfy> ali1234: do I really need to boot into trusty to test it :(
[12:57] <ali1234> i guess so
[12:57] <ali1234> utopic would also work, if you force install the debs
[12:58] <ali1234> because the gtk version is identical
[12:58] <elfy> ok
[12:58] <elfy> will try and get a look a bit later today 
[12:58] <ali1234> i don't know how you build for different versions in a ppa
[13:04] <amigamagic> it works
[13:04] <amigamagic> I just tried
[13:06] <amigamagic> btw, when I click on the triangle near the usb device, it will be completely removed so that I cannot mount it anymore unless I unplug and replug the device. Is this the expected behaviour?
[13:08] <ali1234> yes
[13:08] <amigamagic> ok
[13:09] <ochosi> ali1234: fix works
[13:09] <amigamagic> the unmount from the contextual menu doesn't crash thunar anymore
[13:10] <amigamagic> good job :)
[13:10] <ali1234> ಠ◡ಠ
[13:11] <ochosi> ali1234: well i added your ppa and upgraded the gtk2 packages and now everything unmounts/ejects again as it should
[13:12] <ochosi> added a comment to the bugreport to be sure
[13:31] <slickymasterWork> https://code.launchpad.net/~elfy/ubuntu-manual-tests/XFCEOptional/+merge/218310 <- Approved elfy
[13:31] <slickymasterWork> forestpiskie: ^^^
[13:54] <elfy> slickymasterWork: thanks - all done and synced now
[13:55] <elfy> ali1234: a +1 from me as well in trusty
[13:57] <ochosi> elfy: mind adding your +1 to the bugreport too?
[13:57] <slickymasterWork> thanks for all that work elfy boss ;)
[13:58] <ochosi> just to get this on the record for the sponsors
[13:58] <elfy> ochosi: was just doing that :)
[13:58] <ochosi> oh great :)
[13:58] <elfy> slickymasterWork: thanks for you checking them :)
[13:59]  * elfy thinks that by the time he writes the QA blueprint he can either not write anything at all - or write them and include :DONE :p
[14:00] <elfy> GridCube: hi - pressure is now off of the optional tests - all done and synced up to the tracker \o/
[14:00] <slickymasterWork> eh eh that's what I call being really pro-active elfy 
[14:00] <GridCube> :) sorry i was of no help elfy :(
[14:00] <elfy> GridCube: that's ok - there will be more to do :)
[14:01] <elfy> and you can help with bzr too
[14:03] <elfy> GridCube: justhaving someone to write testcase edits - so that I don't have to write them, find someone to approve, then merge and sync will be an enormous help
[14:03] <elfy> and someone watching the trackers - bugs will need to be checked and added to the eventual bug blueprint
[14:04] <elfy> all stuff that slickymasterWork helped me with - but while he's happy to help - he's got Docs to worry about now :)
[14:05] <GridCube> elfy, alright, ill try to do some of those tasks
[14:05] <elfy> thanks GridCube - I need to add you into the QA team I think 
[14:32] <amigamagic> I don't know if it could help but I too added a comment for the bug 1316509
[14:34] <ochosi> amigamagic: thanks, it's certainly good to show them that ppl have tested the patch successfully
[14:35] <amigamagic> I'm glad to help :)
[15:33] <elfy> lderan:  we need to look at the autopilot list - sort out those that are optional so we can ignore them and then decide which we should try and target this cycle
[15:38] <lderan> sounds like a plan
[15:44] <elfy> cool
[15:46] <elfy> as soon as I've sorted the blueprint out I'll get hold of you then :)
[15:54] <lderan> cool :)
[15:55] <sidi-valencia> http://blog.martin-graesslin.com/blog/2014/05/screenlocker-architecture-in-plasma-next/
[16:09] <ochosi> sidi-valencia: good read, i think i read something on this issue by martin before
[16:09] <ochosi> actually their solution is not so different from ours
[16:10] <ochosi> we also have three separate processes, if the greeter crashes, lightdm will bring it back
[16:10] <ochosi> lightdm handles the authentication
[16:10] <ochosi> and light-locker handles the grabs and toplevel window
[16:11] <ochosi> the only nuisance is the VT switching
[16:21] <sidi-valencia> ochosi, read my comment when it shows up
[16:21] <sidi-valencia> they can do even better with 3 processes ;P