[07:27] <ochosi> morning everyone
[07:27] <elfy> hi ochosi 
[07:28] <ochosi> hey elfy 
[07:43] <elfy> that's the package tracker set up and the testers told :)
[08:03] <jhenke> morning folks, did anybody of you saw https://bugs.launchpad.net/ubuntu/+source/indicator-printers/+bug/1293606 already? just happened to me as well on the trusty work system
[08:03] <elfy> nope - but printer's nto working at all in unicorn
[08:06] <jhenke> okay, so it seems printing is in need of some attention
[10:00] <brainwash> but we use the printer-applet and not indicator-printers
[10:02] <brainwash> these extra unity indicators tend to be somewhat broken or badly integrated =S
[11:05] <jhenke> good to know, the unity indicators have a more speaking name though
[11:06] <brainwash> jhenke: I've reassigned the report, because after taking a closer look it seems to be clear, that indicator-printers is not being used in this case
[11:07] <jhenke> brainwash: sure, I just want to point out the obvious temptation to think it would be the other package
[11:09] <brainwash> I'm also pretty sure that someone has bothered me with this issue some time ago
[11:09] <brainwash> it's a python app after all, these are sometimes poorly coded :)
[11:13] <ochosi> hey Logan_ 
[13:08] <elfy> seem to be a lot of mails in the -devel list of late that are support issues
[13:11] <ochosi> yeah
[13:11] <ochosi> that sucks quite a bit
[13:11] <elfy> new XPL should stamp their mark on that list with a big foot on Friday
[13:12] <elfy> bluesabre: you can read that too ^^ 
[13:12] <elfy> :)
[13:12] <elfy> assuming we have a new one on Friday 
[13:17] <ochosi> yeah, otoh one angry mail won't change things quickly
[13:17] <ochosi> and more moderation is extra work
[13:19] <elfy> yep
[13:19] <elfy> there is that 
[13:19] <elfy> not easy to moderate m/l methinks
[13:27] <ochosi> that is actually one point for or against having a sub-list for -team
[13:27] <ochosi> less need to moderate dev as the really important stuff gets discussed/decided on -team
[13:28] <ochosi> so -team actually becomes the new -dev, but it's a closed list (in terms of who can write)
[13:29] <elfy> not sure that's a point against having a -team list
[13:30] <elfy> if we just kept -devel - then if something came along that needed -team to vote on and 200 replies turned up - would you want to count the -team votes?
[13:31] <elfy> imo we need something that's usable at any time - m/l being an option - that we know isn't going to have replies to it that are not needed
[13:33] <ochosi> well, what i meant was:
[13:33] <ochosi> yes, we will have a clean list because only we can write on it
[13:33] <ochosi> but ppl could consider it as elitism (i think knome mentioned that at some point) because the list is closed
[13:34] <ochosi> but personally, i think that doesn't matter, we could use a closed space to talk
[13:34] <ochosi> and ppl can still read
[13:34] <ochosi> and become team members or show up at meetings (which are open too)
[13:55] <elfy> well as far as elitism is concerned - team is :)
[13:55] <elfy> it's not closed though :)
[14:03] <knome> i personally think that it is at least highly annoying that there are non-development related posts in the -devel list
[14:03] <knome> and whether we actually created a new list or not, i *still* think those should be forwarded to users
[14:03] <knome> or simply make -devel only for team members to post
[14:04] <knome> people can always keep complaining how stuff is "exclusive"
[14:04] <knome> but that's not a valid point as long as the mail they are trying to send is unsuitable for the list
[14:06] <elfy> I'd have thought that forwarding to -devel would be more suitable
[14:06] <knome> yes, i'd rather have everything initially go to -users
[14:06] <elfy> why?
[14:06] <knome> well here's the thing
[14:07] <knome> i can't see any way we can make non-devel-related issues stop on -devel
[14:07] <knome> unless we block all mails except from those from team (and other explicitly trusted emails)
[14:08] <knome> it's much better to have a relatively devel-related issue on users
[14:08] <knome> than to have a firefox support issue on devel
[14:08] <elfy> so close -devel completely
[14:08] <elfy> ?
[14:08] <knome> no
[14:08] <knome> make -devel the "team" list
[14:08] <elfy> mmm
[14:08] <knome> and moderate all mails not from team
[14:08] <knome> and tell everybody to send to -users
[14:08] <knome> or in special cases, allow them to send to -devel
[14:09] <knome> that is, explicitly specify it's ok
[14:09] <elfy> ok - I can see that 
[14:09] <knome> the majority of the fuzzy mails are generated by threads started by non-team members
[14:09] <knome> eg. "i want libreoffice"
[14:09] <elfy> need more mods for list then
[14:09] <knome> then it turns into a flamewar or otherwise just an irrelevant thread
[14:09] <knome> we need more moderators anyway
[14:10] <elfy> I don't mind doing that
[14:10] <knome> i can list several people who i'm happy to give the mod access right away
[14:10] <elfy> if we go that way
[14:10] <knome> right, would you be willing to do it regardless what we decide about the lists?
[14:10] <knome> because if yes, i'll drop you in the moderator list right now
[14:10] <elfy> yea I don't mind doing that 
[14:11] <knome> ok
[14:11] <knome> let me get you the details soon
[14:11] <elfy> ok
[14:11] <elfy> I know how to - the FC list is closed 
[14:11] <elfy> everything to that is moderated
[14:11] <knome> yeah, i mean passwords and such ;)
[14:12] <elfy> yep 
[14:12]  * elfy hates m/l password - they all get confused with each other ... 
[14:12] <knome> heh
[14:15] <knome> so yay
[14:16] <knome> i'm really interestes how this mailing list stuff goes
[14:16] <knome> i want to cut down my influx of mail now that i don't actually need to monitor it all
[14:17] <elfy> :)
[14:18] <elfy> all that said - this won't help the need in my opinion for something like trello
[14:18] <knome> yeah, i understand
[14:18] <knome> they are two completely different things
[14:18] <elfy> what it will mean is I don't need to bother with forestpiskie 
[14:18] <knome> ;)
[14:18] <elfy> if it's important enough for me to know when I'm not here it should be elsewhere :)
[14:19] <knome> :)
[14:19]  * elfy is sitting here wondering why the testcase for xfdesktop settings is so completely wrong ... 
[14:20] <knome> is the testcase written for 4.10?
[14:20] <elfy> I think it's probably written for something older than Moses :p
[14:21] <elfy> anyway - good job we're going through them :p
[14:21] <knome> hehe
[14:21] <knome> yep
[14:28] <ochosi> hehe, i step away for a few mins and knome makes my point for me :)
[14:28] <elfy> :)
[14:28] <ochosi> so yeah, +1 on making -devel the new -team list
[14:29] <ochosi> simply because creating another list when we already have one blows
[14:37] <elfy> well stopping people who can currently post to it wasn't something I'd thought of doing tbh
[14:39]  * ochosi thinks it's a sane consequence
[14:39] <elfy> yea agree - if we want to do that rather than create a new one 
[15:51] <knome> elfy, we can send them a moderation message that explains the situation and suggests them to post the -users list
[15:54] <elfy> yep
[17:15] <slickymasterWork> https://code.launchpad.net/~elfy/ubuntu-manual-tests/XFCEOptional/+merge/218310 <- on it, elfy
[18:30] <ali1234> ochosi: wait, so i won't be able to post to -devel?
[18:40] <brainwash> ali1234: join the team, problem solved :)
[18:53] <amigamagic> sorry for the intrusion guys, but it's possible to "approve"/"disapprove" an user when he want to register for a devel mailing list?
[18:55] <amigamagic> I mean, if you can write to a mailing list without approval from anyone, then it's normal that you will have unwanted messages too
[18:56] <amigamagic> but if you should have to "approve" an user as developer before he could send its mails to the devel list, then the user would think more than 2 times, before send an email in that list
[18:57] <ochosi> ali1234: we haven't discussed this very deeply yet, but the goal of that other (new, additional) list we were discussing was actually designed to get us a cleaner -devel list
[18:57] <ochosi> instead of creating a new one, i personally think we should just clean up the devel list and make it more focussed again
[18:57] <ochosi> too many emails that are crypto-bugreports or wishlist-entries (or rants)
[18:58] <ochosi> so stuff that is not really helpful for or related to development
[18:58] <ali1234> okay but this doesn't answer my question :)
[18:58] <amigamagic> have you considered a forum?
[18:59] <ali1234> developers don't like forums
[18:59] <ochosi> ali1234: well, there is no single yes/no answer yet, i presume we'll discuss this more and maybe even take a vote on this
[19:00] <amigamagic> ali1234, why?
[19:02] <ali1234> they don't have threading, they are a pita to search, posting code requires using obscure escape codes, you need yet another login, forum warriors, mega-threads, stupid "don't post a new thread" rules,
[19:04] <ali1234> the annoying animated avatars and sigs, inability to reply inline easily, you have to use a web browser to access them
[19:04] <ali1234> you can't have any control over the user interface because you are stuck with whatever braindead html the creator chose
[19:05] <ochosi> hehe
[19:05] <ochosi> nicely said
[19:05] <ali1234> and of course don't forget that because it's html, you have to GET and POST which means the UI is guaranteed to suck and lose your post you spent half an hour writing
[19:05] <ali1234> eg if you accidentally click back, or another link
[19:09] <amigamagic> :O
[19:10] <amigamagic> I think you have been a little bit exaggerated on the matter, but I understand many things you said. :)
[19:18] <ochosi> ali1234: anyway, i guess this channel our primary form of communication either way
[19:20] <ochosi> and as brainwash suggested, you can always join the team ;)
[19:20] <amigamagic> what exactly means "join the team"? :)
[19:24] <ochosi> it means contribute consistently for a while, let the others in the team get to know you a bit, and take responsibility (or something like that)
[19:25] <sidi-valencia> it means there's a group of individuals bound by some sort of tacit social rule (usually a common objective), that causes them to identify themselves as being such a group, and joining the team refers to you abiding by the same tacit rules and identifying yourself in the same way as them and them accepting that you do so
[19:25]  * sidi-valencia is done trolling here.
[19:25] <ochosi> hehe
[19:27] <ochosi> bbl
[19:27]  * amigamagic is going to eat very much to restore its mental forces after sidi-valencia answer
[19:29] <sidi-valencia> It means you can kick people like out of the team's boundaries and on the other side of the geographical representation of said boundaries, too.
[19:29]  * sidi-valencia likes to say ******
[19:40] <ali1234> we got a breakthrough on that thunar bug... someone found steps to 100% reproduce it
[19:43] <elfy> ali1234: did you miss this bit of the m/l discussion "unless we block all mails except from those from team (and other explicitly trusted emails)"
[19:43] <ali1234> i didn't read any of that, just going on what i read here
[19:43] <elfy> that is here 
[19:44] <ali1234> oh, well i missed it then
[19:44] <elfy> I guessed so :)
[19:45] <knome> ali1234, if we decide to limit the -devel list for team members only, we can obviously allow non-team members too, with consideration
[19:46] <knome> ...and we probably should, because not everybody that can give us insightful messages is on the team
[19:46] <knome> we've allowed mails from non-subbed ubuntu/canonical employees through before, we can continue with the same mindset
[19:51] <jhenke> ali1234 do you mean the "fork before gkt_init()"?
[19:51] <ali1234> with thunar? no, that's definitely not it
[19:51] <ali1234> with the new method i can crash it without daemon mode
[19:53] <jhenke> okay, just saw that mail today on the xfce-dev ML and thought you might mean it
[20:18] <amigamagic> ali1234, what thunar bug?
[20:19] <ali1234> bug 1203296
[20:29] <amigamagic> yeah, I too can reproduce it
[20:29] <amigamagic> at first I couldn't reproduce it because if you click on the eject little icon it works
[20:37] <elfy> slickymaster: thanks :)
[20:48] <ali1234> hmm
[20:49] <ali1234> hmm.... okay... system has gone really strange
[20:56] <ali1234> okay, getting somewhere. it still crashes with G_SLICE=always-malloc
[20:57] <ali1234> G_SLICE=debug-blocks doesn't catch any early errors
[20:59] <sidi-valencia> is it 100% reproducible?
[20:59] <ali1234> it is for me
[20:59] <ali1234> i have not quite nailed down exactly which steps are required yet though
[21:00] <ali1234> the procedure is a bit long winded
[21:03] <ali1234> basically you need an unmounted drive eg a usb drive (and it might have to be a usb drive)
[21:04] <ali1234> then you mount it, open a file on it, attempt to unmount it twice, close the file, unmount it for real, then quit thunar. it will segfault
[21:04] <elfy> ali1234: that might be why I can't reproduce it now - usb sticks only
[21:04] <ali1234> what do you mean exactly?
[21:05] <elfy> "it might have to be a usb drive"
[21:05] <ali1234> did you try it with mounting a non-usb drive?
[21:06] <ali1234> wait, i can try it
[21:06] <elfy> I've got none 
[21:06] <elfy> oh - would a partition do it?
[21:06] <ali1234> i dunno, that's the question :)
[21:06] <ali1234> "eject" does not trigger the bug
[21:06] <elfy> not sure if I could umount the other drive completely
[21:06] <ali1234> only "unmount"
[21:07] <ali1234> okay confiit worked with a fixed SATA disk partition
[21:07] <elfy> ok
[21:08] <ali1234> probably it will happen with anything that gets mounted, eg gvfs network shares (seen reports of that)
[21:09] <elfy> so - mount - open something from it - unmount - close error dialogue - close opened file - unmount 
[21:11] <elfy> yep - crashed
[21:11] <ali1234> i always have to do it twice but i think "where thunar thinks it is" affects the result
[21:12] <ali1234> where is the highlight in the sidebar when you close thunar?
[21:12] <elfy> just did it the once and it's started apprt
[21:12] <elfy> hang on - I'll do it again
[21:13] <elfy> after closing the error dialogue the sidebar highlight has defaulted to my home in places
[21:13] <ali1234> and it crashes?
[21:13] <ali1234> hmm... well, so much for that theory
[21:13] <elfy> yep
[21:13] <elfy> twice now 
[21:14] <elfy> that's with an unmounted fixed drive partition
[21:14] <elfy> any point in me sending this bug report - it's in Unicorn
[21:15] <ali1234> none at all
[21:15] <elfy> thought as much :)
[21:17] <ali1234> uploading a video of me reproducing it
[21:17] <ali1234> it's easier than telling exactly every single step i do
[21:18] <elfy> ok - I'll follow it tomorrow when I'm more awake 
[21:18] <elfy> I'm notoriously bad at following video's ... 
[21:19] <ali1234> heh
[21:19] <ali1234> if i try to write every single step i'll just forget something important
[21:19] <elfy> :)
[21:19] <ali1234> how are you unmounting? with right click?
[21:19] <elfy> yea
[21:20] <ali1234> are you doing left click select then right click to open menu? or directly right clicking? i think that makes a difference?
[21:20] <ali1234> also i think click okay or cancel on each dialog might affect it too
[21:20] <elfy> right click on sidebar 
[21:20] <ali1234> well yes
[21:20] <ali1234> but do you left click the item first to select it?
[21:21] <elfy> no - not left click select - direct right click on sidebar
[21:21] <ali1234> okay
[21:21] <elfy> and cancel dialogue
[21:21] <ali1234> that's what i am doing, and i always have to do it twice
[21:21] <ali1234> i cancel the failed ones and okay the okay ones
[21:21] <elfy> I've not had an okay one to okay
[21:22] <ali1234> oh? when i do the successful unmount i still get one of the dialogues
[21:24] <ali1234> https://www.youtube.com/watch?v=Lz1haetybhc
[21:24] <elfy> I wasn't - also this time it didn't creash
[21:31] <brainwash> finally some progress :)
[21:31] <elfy> ali1234: I don't get that second busy dialogue here after the open file is closed
[21:34] <elfy> ali1234: http://pastebin.com/sQ5L6wKK
[21:39] <ali1234> so the weird thing about this is that it's not slice/malloc mismatch, and it's not double free - because those should be caught by the various debug switches
[21:39] <ali1234> so really this can only be a pointer getting corrupted somehow, so it eventually tries to free something it's never seen before
[21:40] <ali1234> i guess the next step is valgrind with every possible test
[21:42] <elfy> well ... happy to help where I can, but you'll need to give me pointers with that 
[21:42] <elfy> sounds like some Norse mythology ... 
[21:44] <ali1234> te only thing valgrind showed up was this: http://paste.ubuntu.com/7401227/
[21:45] <ali1234> and it does involve "shortcuts" so it's a possibility
[21:48] <elfy> hi GridCube - I hammered out the xfce ones today
[21:49] <GridCube> hi elfy yes, i got an email from trello because i suscribed to the task
[21:50] <elfy> :)
[21:50] <elfy> but no mails about anything else?
[21:53] <GridCube> P: no because i did not suscribed to anything else
[21:54] <elfy> yep - just checking - knome appeared to be worried about that I think
[21:56] <sidi-valencia> would a virtual volume do it? elfy 
[21:56] <elfy> not sure - I'm just following instructions :)
[21:57] <elfy> ali1234: I'm off now - if you think of anything you want me to try - tell forestpiskie and I'll read it with the first cuppa 
[21:57] <elfy> night all
[21:58] <sidi-valencia> ali1234, that invalid write on a gobject_dispose...
[21:58] <sidi-valencia> which gobjects are related to volumes?
[21:58] <sidi-valencia> is it possible that smth gets freed straight away on a fail unmount?
[21:58] <sidi-valencia> i'd be looking for that personally :P
[21:58] <ali1234> i dunno, but that looks like something to do with icons... and the volumes do have icons... and they change when you mount/unmount
[21:58] <ali1234> yes, so maybe the icon gets freed too early on unmount
[21:59] <ali1234> although that would cause a double free, and valgrind would surely catch that
[21:59] <sidi-valencia> https://chipx86.github.io/gtkparasite/ would that debugger help?
[21:59] <sidi-valencia> Disclaimer: never used it :P
[22:00] <sidi-valencia> not necessarily a double free methinks
[22:00] <sidi-valencia> say you have a foo object for your volumes
[22:00] <sidi-valencia> pointing to bar and ter
[22:00] <sidi-valencia> and bar got a ref to ter
[22:00] <sidi-valencia> say foo frees ter but not bar when failing to unmount (which would be a bug obviously)
[22:00] <sidi-valencia> then later on disposing bar might cause bar to write stuff to ter such as a g_object_unref (ter)
[22:00] <sidi-valencia> but ter is already gone
[22:01] <sidi-valencia> not a free but definitely an invalid write
[22:01] <sidi-valencia> you never free a gobject directly normally
[22:07] <ali1234> nah, that's just like a dom explorer
[22:07] <ali1234> i've used it a lot
[22:08] <ali1234> hmm yeah
[22:08] <ali1234> this is pretty much all i can think of too
[22:08] <ali1234> going to dig into the code and find exactly where it crashes
[22:10] <ochosi> sounds good though
[22:10] <ochosi> that crash happens very frequently to me
[22:10] <ochosi> i think i can reproduce it 100% with my ipod
[22:10] <ochosi> unmounting is quasi inpossible with thunar
[22:10] <ochosi> impossible
[22:10] <ochosi> with gigolo unmounting works as it should
[22:12] <ochosi> unmounting/ejecting
[22:12] <ochosi> network shares are (as you stated correctly) also quite a sure shot for crashing thunar here
[22:21] <ochosi> Logan_: hey there! think you could sponsor this to get the SRU process going? https://code.launchpad.net/~smd-seandavis/ubuntu/trusty/parole/gstreamer1.0-pulseaudio/+merge/216565
[22:21] <ochosi> it should be a fairly simple one, if you have any questions though, feel free to ping me or bluesabre 
[23:25] <bluesabre> thanks ochosi