[01:49] <skellat> micahg: You want me to open the bug for SRU paperwork to get started for killing off the indicators issue?
[02:15] <skellat> ali1234: Are you still around at this hour?
[02:15] <ali1234> yeah
[02:15] <skellat> Have you started an SRU bug already?
[02:15] <ali1234> no
[02:15] <skellat> Crud
[02:16] <skellat> Let me see if I can get one started so we can fill in the blanks for micahg
[02:16] <skellat> ali1234: What's the package we would be updating?
[02:16] <ali1234> indicator-sound-gtk2
[02:17] <ali1234> do we really need a new bug? what's wrong with the existing one?
[02:18] <skellat> ali1234: I thought about using the existing one
[02:18] <skellat> I don't want the current commentators messing with the SRU stuff
[02:18] <skellat> But, we can still use the current bug
[02:19] <skellat> http://pad.lv/1208204
[02:19] <ali1234> fair enough
[02:20] <ali1234> so, random question
[02:21] <ali1234> in my ppa the debdiff only shows the difference between the current version and the previous one i uploaded, which i deleted
[02:21] <ali1234> why?
[02:21] <Unit193> Because it's a diff from "this version to previous"
[02:21] <ali1234> but previous no longer exists
[02:23] <Unit193> And when you upload a newer version, the older one will also no longer exist.
[02:24] <skellat> ali1234: Here's what I've got so far for the SRU paperwork: http://paste.ubuntu.com/6538478/
[02:24] <ali1234> Unit193: that's the thing: when i uploaded a new version, the old ones stayed and i had to manually delete them
[02:25] <Unit193> ali1234: They will until the new ones are fully built and published, yes.
[02:27] <ali1234> skellat: so the biggest regression potential is if it cnflicts with the gtk3 indicator somehow
[02:27] <skellat> How would we know?
[02:28] <ali1234> "try it"
[02:28] <ali1234> the only way i can think of is if the two services both use the same dconf keys or something
[02:28] <skellat> Lets shift to this Etherpad to edit perhaps: http://pad.ubuntu.com/spiE1k9rME
[02:28] <ali1234> which they do
[02:28] <ali1234> but i don't know if it matters
[02:38] <skellat> ali1234: Does it look somewhat decent now?
[02:39] <ali1234> yeah, i didn't want you to delete the whole paragraph. i think we should mention we only want to fix the gtk2 indicator because landing gtk3 would be huge
[02:40] <skellat> Sorry
[02:40] <skellat> Just hit Control-Z on my end
[02:45] <skellat> ali1234: It looks like all three derive from the same source project: https://bugs.launchpad.net/indicators-gtk2
[02:45] <ali1234> yes, that project was set up to maintain the gtk2 versions after upstream dropped them
[02:46] <ali1234> ido-gtk2 is a support library which draws widgets
[03:03] <skellat> ali1234: You satisfied with the way the SRU paperwork looks?
[03:03] <ali1234> yes
[03:03] <skellat> Should we go ahead and use the existing bug still?
[03:04] <skellat> It is triaged so I actually can just change the description then assign it to micahg and be done with it
[03:04] <ali1234> up to your judgement
[03:04] <skellat> There are risks with the commentators though
[03:04] <ali1234> yeah
[03:04] <ali1234> i can watch the bug for silly changes
[03:04] <skellat> Screw it, LP Bug #1208204 it is!
[03:04] <ali1234> otoh at least it looks like we're doing something
[03:04] <ali1234> rather than hiding it
[03:07] <ali1234> so... shall i post a debdiff then?
[03:08] <skellat> ali1234: We should leave that for micahg
[03:08] <ali1234> how do you mean?
[03:10] <skellat> He's supposed to do his own build and upload
[03:11] <ali1234> yeah, but won't he need the debdiff to know what to actually fix?
[03:11] <skellat> True
[03:11] <skellat> Go for it
[03:11] <skellat> I had to make a request in #ubuntu-bugs for somebody to assign the bug to him since I lack that power
[03:17] <ali1234> hmm... attachment seems to have got lost somewhere... i don't see it
[03:17] <ali1234> oh well
[03:17] <skellat> It is moving on the right path
[03:23] <Unit193> ali1234: I see the debdiff on the right side, under "Patches"
[03:24] <ali1234> ah yes
[09:38] <Unit193> bluesabre: /var/lib/dpkg/info/lightdm-gtk-greeter.postinst: 20: /var/lib/dpkg/info/lightdm-gtk-greeter.postinst: /usr/lib/lightdm/lightdm-set-defaults: not found  [09:43] <Unit193> lightdm (1.9.4-0ubuntu1): - Remove lightdm-set-defaults and gdmflexiserver.
[09:53] <Unit193> "New" method: http://bazaar.launchpad.net/~ubuntu-branches/ubuntu/trusty/unity-greeter/trusty/view/head:/debian/50-unity-greeter.conf
[09:57] <Unit193> I could propose 10-xubuntu.conf for xubuntu-default-settings, if that's actually needed (very easy.)
[09:59] <Unit193> Anywho: http://bazaar.launchpad.net/~ubuntu-branches/ubuntu/trusty/unity-greeter/trusty/revision/57 - http://bazaar.launchpad.net/~ubuntu-branches/ubuntu/trusty/ubuntu-settings/trusty/revision/10
[10:31] <knome> http://status.ubuntu.com/ubuntu-t/group/topic-t-flavor-xubuntu.html
[10:42] <elfy> nice - glad to see that -qa has things listed and not just me :p
[10:42] <knome> heh
[10:43] <elfy> leave it a little while and then move things from -qa to ~Unit193 
[10:47] <knome> yep
[10:47] <knome> sounds fair
[11:03] <knome> elfy, was there anybody who responded to the mail sent to -testers, or did you see new testers pop up in the tracker?
[11:05] <bluesabre> ah, Unit193: please do :)
[11:12] <elfy> knome: no replies to me - and I've not been in any fit state to check if we've got any new names
[11:12] <knome> oki
[11:52] <brainwash> ali1234: you should inform these users about the recent upstream changes http://forum.xfce.org/viewtopic.php?id=8481
[11:52] <ali1234> i don't have a forum account
[11:53] <brainwash> I do, but I would need to recover my password
[11:54] <brainwash> and the affected package "xfwm4 (ubuntu)" should be changed to "xfwm4" or? bug 1232804
[11:55] <ali1234> yes
[11:56] <ali1234> i'm looking at tearing and opengl
[11:56] <ali1234> opengl compositing is an order of magnitude slower on nvidia
[11:56] <ali1234> but it fixes the tearing that you get with Xrender
[11:56] <brainwash> so opengl instead of xrender as backend?
[11:57] <brainwash> what about the recent addition of vsync to xfwm4?
[11:57] <ali1234> so i'm wondering why we can't just render everything to a buffer with Xrender (like we do now) and then copy that buffer into the opengl backbuffer one time
[11:57] <ali1234> the vsync code doesn't work on nvidia
[11:57] <ali1234> nvidia drivers are crap for anything but games
[11:57] <brainwash> doesn't the driver offer a vsync option?
[11:58] <ali1234> yes, for opengl
[11:58] <brainwash> like the AMD one does
[11:58] <brainwash> oh
[11:58] <brainwash> sounds a bit complicated
[11:58] <ali1234> yes it is a bit
[11:59] <brainwash> how about copying the code of some other compositing manager? :)
[12:00] <brainwash> like compton
[12:00] <brainwash> still, not an easy task
[12:01] <brainwash> so xfwm4 could run with both backends, xrender or opengl
[12:03] <ali1234> compton compositor is almost identical to xfwm4
[12:03] <ali1234> they are both copied directly from xcompmgr
[12:03] <ali1234> compton even still has some of the bugs i've fixed in xfwm4
[12:04] <brainwash> but it can use opengl
[12:04] <ali1234> yes, which means it's slow on nvidia
[12:04] <ali1234> like 15FPS slow
[12:04] <brainwash> ok, mmh, blame nvidia?
[12:05] <ali1234> i don't see a reason to render every window using opengl
[12:05] <ali1234> do it all with xrender and the copy it using opengl at the end
[12:05] <ali1234> we already render everything in an offscreen buffer
[12:05] <ali1234> this should be easy
[12:05] <brainwash> yes, sounds easy
[12:07] <brainwash> I could test it on my AMD powered system, if you come up with a patch :)
[16:15] <slickymaster> afternoon all
[16:16] <knome> hey slickymaster 
[16:16] <slickymaster> hi knome 
[16:16] <slickymaster> just finished reading -meeting logs for last friday
[16:17] <slickymaster> but still got update myself on the dozen of mails from the mailing 
[16:17] <knome> that'll take some time
[16:18] <slickymaster> :)
[16:20] <slickymaster> knome, congrats. Just saw the new https://help.ubuntu.com/community/ page
[16:21] <slickymaster> Is https://help.ubuntu.com/community/OtherResources finished or are you still working on it?
[16:22] <knome> pretty much finished. but it's of course always a WIP
[16:22] <slickymaster> yes
[16:22] <slickymaster> nice work knome 
[16:22] <slickymaster> . kudos
[16:23] <knome> ta
[16:38] <elfy> hi slickymaster knome 
[16:39] <knome> hullo elfy 
[16:39] <elfy> better today - been driving :)
[16:39] <slickymaster> hi elfy
[16:39] <slickymaster> glad to hear that
[16:39] <knome> cool
[16:39] <elfy> :)
[16:39] <slickymaster> elfy, saw the mail from -qa
[16:39] <elfy> ok 
[16:40] <elfy> it's not from -qa ;)
[16:40] <elfy> it's from me :)
[16:40] <elfy> not everyone in the -qa team actaully got the mail :p
[16:40] <slickymaster> will answer it today. Trying to catch up with all the mail knome presented me this weekend
[16:41] <slickymaster> noticed that now ;)
[16:41] <elfy> slickymaster: no rush on it at all 
[16:41] <elfy> I've got a whole week to try and catch up on
[16:41] <slickymaster> did you saw the mugshot manual test?
[16:41] <knome> i don't think i'm on ubuntu-qa if that's something in there;)
[16:43] <elfy> knome: you are on -qa, but I didn't bother CC'ing you in to it - if anything comes of it you will get a fait accompli :D
[16:44] <knome> goodie
[16:45] <elfy> :)
[19:03] <Unit193> bluesabre: Did the one.
[19:06] <Unit193> Uhh, that so did not work, I hate bzr.
[19:09] <Unit193> There.
[22:03] <slickymaster> knome, as you were on the xubuntu subject, how is https://bugs.launchpad.net/bugs/1213933 going to be dealt with, directly in ubiquity?
[22:04] <knome> slickymaster, we need to review the slideshow
[22:04] <slickymaster> yes, there's also the reference to 13.10 in the first slide that has to be changed
[22:05] <knome> https://code.launchpad.net/~ubiquity-slideshow/ubiquity-slideshow-ubuntu/html
[22:07] <slickymaster> I can assign myself to both and propose a merge? what do you think?
[22:07] <knome> we probably need to look at the slideshow at large, but works for me
[22:07] <knome> are you familiar with the slideshow branch or want a brief introduction?
[22:08] <slickymaster> it's very similar to other branches on other LP teams, or am I wrong?
[22:08] <slickymaster> I will just be working on http://bazaar.launchpad.net/~ubiquity-slideshow/ubiquity-slideshow-ubuntu/html/files/head:/slideshows/xubuntu/slides/
[22:08] <knome> the pulling and stuff is similar, i was referring to the contents
[22:08] <slickymaster> knome,  ^^
[22:08] <knome> yep.
[22:09] <knome> you can test the slideshow as well though
[22:09] <slickymaster> yeah, I think i can manage
[22:09] <knome> in the root directory for the branch, type: ./test-slideshow.sh xubuntu
[22:09] <slickymaster> anyway, I'm assuming that you'll be one of the reviewers, right?
[22:09] <knome> yep.
[22:10] <slickymaster> you mean to run it and test it locally
[22:10] <knome> yep
[22:10] <slickymaster> will do
[22:10] <knome> after you've made your changes, just run that command
[22:10] <knome> and you'll see your changes
[22:10] <slickymaster> ok
[22:10] <slickymaster> I'll assign myself
[22:10] <knome> and can play around in a fake slideshow environment
[22:10] <knome> cheers :)
[22:11] <slickymaster> you do keep us busy
[22:12] <knome> and myself ;)
[22:12] <slickymaster> very true ;)
[22:34] <slickymaster> knome, I getting: bzr: ERROR: Invalid url supplied to transport: "lp:~slickymaster/ubuntu/ubiquity-slideshow-ubuntu/": No such distribution series ubiquity-slideshow-ubuntu. when pushing my branch
[22:34] <slickymaster> can it be a permissions iusse?
[22:51] <slickymaster> nevermind knome I figured it out
[22:53] <slickymaster> knome, available for your review and merge https://code.launchpad.net/~slickymaster/ubiquity-slideshow-ubuntu/ubiquity-slideshow-ubuntu/+merge/198184
[23:10] <knome> slickymaster, cheers, will get to that later
[23:10] <slickymaster> okie dokie, knome