[03:19] <OvenWerks> smartboyhw: -installer is all fixed up.
[03:19] <smartboyhw> OvenWerks, i.e./
[03:19] <smartboyhw> ？
[03:19] <OvenWerks> both in the branch and my ppa
[03:20] <OvenWerks> all gui now
[03:20] <smartboyhw> OvenWerks, oh great:)
[03:20] <smartboyhw> We can release it soon enough, just needs the power of micahg and another MOTU
[03:20] <OvenWerks> micah has already checked it, just waiting for second review.
[03:21] <smartboyhw> OvenWerks, ask in #ubuntu-motu might be a better idea.
[03:22] <OvenWerks> The needs packaging bug is still undecided, maybe it should be something more.
[06:12] <astraljava> xequence: Yeah, progress is nice. Been standing still for way too long. And thanks!
[06:18] <TheDrums> astraljava: Hello!
[06:20] <xequence> OvenWerks: what's the bug number?
[06:23] <astraljava> TheDrums: Hi!
[06:51] <xequence> OvenWerks: I asked for a reviewer on #ubuntu-motu, but if no one answers, I'll post to the ubuntu-motu mail list
[07:44] <smartboyhw> cub, welcome back:)
[07:44] <cub> thanks smartboyhw, it was difficult today. :P
[07:44] <smartboyhw> cub, why?
[07:44] <cub> Symantec antivirus had crapped up my work mac
[07:44] <cub> 1,5 later of reinstalling apps
[07:45] <smartboyhw> cub, hah
[07:45] <cub> had to change irc client even
[07:45] <cub> even after reinstalling and so on xchat remained broken *sigh*
[07:47] <cub> LimeChat to the rescue. Horrible fonts though..:D
[07:48] <cub> Still summer holiday, smartboyhw?
[07:56] <smartboyhw> cub, yes
[07:56] <smartboyhw> Until 1st September
[07:57] <smartboyhw> I will start school at 2nd
[12:27] <smartboyhw> Welcome xequence :)
[12:29] <xequence> smartboyhw: Thanks. I'm back att debconf.
[12:29] <xequence> We just took a group photo. The photographer stood on a hill, put the camera on, and then ran slowly down 50m to be in the photo himself
[12:32] <smartboyhw> ：O
[12:36] <xequence> good thing he didn't trip
[12:36] <smartboyhw> lol
[15:06] <smartboyhw> xequence, damn I forgotten, for 12.04.3 we should have a -lts-raring kernel ready:(
[15:06] <smartboyhw> I did say that before:(
[15:06] <xequence> smartboyhw: not your job to remember
[15:06] <xequence> so its ok
[15:07] <smartboyhw> xequence, we can have it for 12.04.4 I think (sigh)
[15:07] <xequence> I haven't yet looked at how that works
[15:08] <smartboyhw> xequence, alright, since you are the kernel maintenace guy, check it out someday:)
[15:08] <xequence> smartboyhw: I just asked about it on the kernel channel
[15:08] <smartboyhw> xequence, sure:)
[15:08] <xequence> smartboyhw: We don't have planning for the LTS at all. Thats a bit of a problem
[15:09] <smartboyhw> xequence, +1
[16:26] <OvenWerks> micahg: re: your remark about polkit, there is already a policy in place for apt. Also there seems to be a default policy in place as I can run pkexec cat file.
[16:27] <OvenWerks> micahg: if I was to set up a policy, it would have to be for apt-get, but I am not sure that is not already covered by org.debian.apt.install-or-remove-packages for example
[16:29] <OvenWerks> micahg: in fact setting up a policy for apt-get may break policy already in place
[16:29] <micahg> OvenWerks: ok, so it prompts for the superuser password?
[16:30] <micahg> not root?
[16:30] <OvenWerks> yes
[16:30] <micahg> sorry, current admin user
[16:30] <micahg> ok, great
[16:30] <OvenWerks> if I am logged in as a non-admin user it asked for the passwored of the admin user
[16:31] <micahg> great
[16:31]  * OvenWerks tested this on my wife's machine
[16:31] <micahg> and as an admin user, one's own password?
[16:31] <OvenWerks> yes
[18:09] <scott-work> zequence: you might consider applying for this: https://plus.google.com/u/0/116317370665849559569/posts/gEUnW2jsB3B
[18:17] <xequence> scott-work: Hey man :)
[18:17] <xequence> Someone just wishing for you to appear the other day
[18:17] <xequence> Well, all of us of course
[18:17] <xequence> but, I think it was smartboyhw - he's probably asleep right now
[18:18] <xequence> scott-work: That's not a bad idea, but unfortunately I haven't yet contributed to kernel code at all, so without reading I'm not sure if that applies to me
[18:18] <xequence> I would like to do that in the future though
[18:18] <xequence> scott-work: I'm at debconf at the moment, btw
[18:19] <xequence> in Switzerland
[18:19] <xequence> Joined the Debian Multimedia Team in May I think it was
[18:20] <xequence> There will be a meeting about a Debian blend for Multimedia, and since I'm most likely the only attending, plus the experience from US, I'm going to see if i can take a leading role in that
[18:21] <xequence> try to see about harmonizing Debian/Ubuntu a bit on the multimedia side of things
[18:23] <xequence> scott-work: How's things going for you. You said you were going to do some studying
[18:24] <xequence> astraljava is doing some of that as well, as it seems
[18:32] <xequence> time to leave for home - I'm again not saying at the camp, and have the luck of having a relative living nearby, in this case my sis, so going there over night. bb online in a few
[18:49] <madeinkobaia> Hi all : )
[19:12] <OvenWerks> madeinkobaia: Hello :)
[19:12] <madeinkobaia> OvenWerks: Hi mate :)
[19:13] <madeinkobaia> OvenWerks: Was fighting with gnome 3 those last days, what a hell !
[19:13] <OvenWerks> icons  I would like to get names finalized even if the art is not
[19:14] <madeinkobaia> OvenWerks: What do you mean ?
[19:14] <OvenWerks> I'll also pass this by zequence 
[19:15] <OvenWerks> right now they are using the standard names
[19:16] <OvenWerks> like applications-audio.png
[19:16] <madeinkobaia> I think I missed a part of the conversation...not sure to understand, I should take a look on dev-list mail...
[19:16] <OvenWerks> but what that means is that other icon themes override ours
[19:17] <OvenWerks> we were going to change them so they are unique
[19:17] <madeinkobaia> ok
[19:17] <OvenWerks> I think we are just going to take the applications and change that to ubuntustudio
[19:18] <OvenWerks> The main thing for you, I would guess, is that you know both names are talking about the same thing.
[19:19] <OvenWerks> I need to change all the *.desktop files to match. and so I would like to start on that soon as I can
[19:20] <OvenWerks> Also, it looks like the package they will end up in will be ubuntustudio-menu rather than ubuntustudio-icon-theme.
[19:22] <madeinkobaia> Ok I will check all that. Now I think I will be highly busy those next weeks too. 
[19:23] <OvenWerks> Life comes first.
[19:23] <OvenWerks> I hope it's a good busy :)
[19:23] <madeinkobaia> A great one :D
[19:24] <OvenWerks> Great! good to hear.
[19:24] <OvenWerks> I'm off work till sometime in sept.
[19:25] <madeinkobaia> Otherwise do you know who did the actual ubuntu studio desktop theme ?
[19:26] <madeinkobaia> It was grounded on a gtk 2 theme I guess
[19:26] <OvenWerks> Theme? We generally have been using what xubuntu has.
[19:26] <OvenWerks> we add our own BG and menu
[19:27] <madeinkobaia> Ok, I will start work on our new theme for the 14.04 soon.
[19:27] <OvenWerks> I liked it last release, but am not liking the newer one
[19:29] <OvenWerks> I like the whole bar of the window with focus to change, just changing the colour of the text (grey to black) does not make it obvious enough which window I should be looking at :)
[19:29] <madeinkobaia> Ok
[19:30] <OvenWerks> Just my pet peave with most new themes... others may not agree
[19:30] <OvenWerks> cub: hello.
[19:30] <madeinkobaia> cub: Hi
[19:30] <madeinkobaia> Bbl
[19:31] <cub> Hello OvenWerks and madeinkobaia 
[19:32] <OvenWerks> cub: in #xubuntu-devel "< texadactyl> Len, Mir could be safely released if LightDM was changed  slightly to decide whether or not to launch Mir based on a  lightdm.conf (new) parameter (switch).  By default, it  should probably be off.
[19:33] <OvenWerks> does that make sense to you?
[19:33] <cub> it would force the system to go to the fallback xorg?
[19:33] <cub> even if the HW would be able to run mir, no?
[19:34] <OvenWerks> I am thinking with a clear switch that having xmir on an ISO by default would be ok.
[19:34] <OvenWerks> Ya, apparently there is a config option that can be set on or not.
[19:35] <cub> I'm not sure I follow. You mean that the ISO would have the switch on to load xmir?
[19:35] <cub> or the other way around?
[19:36] <OvenWerks> texadactyl's comment seems to indicate off by default.
[19:37] <cub> yes
[19:37] <OvenWerks> That config file is unique to the flavour though, so it would be a flavour's choice.
[19:38] <OvenWerks> s/would/could
[19:38] <cub> exactly
[19:39] <OvenWerks> it would allow easy continued testing without having to keep a separate partition or drive.
[19:39] <cub> though if everyone could change to mir if they wanted to after boot that would be fine. Not to mess up too much for the users
[19:39] <cub> exactly
[19:39] <cub> win-win
[19:39] <OvenWerks> I think it still requires a reboot... but I could be wrong.
[19:40] <cub> hmm I don't know. Hopefully it would do with a log off/on but I'm just wishing
[19:41] <OvenWerks> lightdm is started by upstart... really it should be possible to just change run levels... shh, don't tell the upstart/systemd guys I said that word ;)
[19:42] <cub> tvoss_	texadactyl, so are you happy with commenting out type=unity in /etc/lightdm/lightdm.conf.d/10-unity-system-compositor.conf?
[19:43] <cub> One reboot for each test until 14.04, I could live with that. =)
[19:43] <OvenWerks> With two run levels lightdm could be run with a different config file for each.
[19:44] <cub> woudl that require much more resources from the pc?
[19:47] <OvenWerks> run levels? no.
[19:47] <OvenWerks> just checked and lightdm does not seem to have a respawn tag
[19:48] <OvenWerks> otherwise one could just kill it and it would restart
[19:49] <OvenWerks> Stock ubuntu/debian has runlevel 2-5 all the same right now.
[19:50] <OvenWerks> lightdm for example is set "stop on runlevel [016]"
[19:50] <cub> ok
[19:50] <OvenWerks> (from the upstart config file)
[19:52] <cub> On another note, I have totally missed that 12.04.3 is released soon. Is there anything we need to be on top for that, or is everyone already on top of it (except me)?
[19:52] <OvenWerks> It seems we missed it anyway.
[19:53] <OvenWerks> maybe a new kernel. but that is not a big DL
[20:15] <cub> I'm struggling with my laptop to shrink the win-partition to make room for a new test partition to run saucy
[20:16] <cub> after 1073 steps, it will let me shrink it 26 MB. Yay.
[20:31] <cub> it's getting late over here, so g'nite folks!
[20:50] <OvenWerks> xequence: what are the chances of adding a ubuntustudio-audio.preinst to our meta package?
[21:08] <xequence> OvenWerks: What sort of thing did you have in mind?
[21:09] <OvenWerks> debconf-set-selections jackd/tweak_rt_limits boolean true
[21:09] <OvenWerks> Not quite right, but close.
[21:10] <xequence> you mean that will say yes to installing the audio.conf file by default?
[21:10] <OvenWerks> The question is, does it affect things with a generic kernel?
[21:10] <xequence> realtime privilege is not kernel specific at all
[21:11] <OvenWerks> If a user is installing our audio meta on another flavour it should just work...]
[21:11] <xequence> They still need to add themselves to audio group
[21:11] <OvenWerks> :) Thats another problem for another day :)
[21:11] <xequence> it would be better actually to add a patch explaining this while installing jackd
[21:12] <xequence> the patch would just add some text - answer yes, then add yourself to audio group
[21:12] <xequence> ubuntustudio-controls will be administrating realtime privilege
[21:12] <xequence> I was working on that part today
[21:13] <OvenWerks> Ok
[21:13] <xequence> I used to have a script with it that checked the system at boot as well
[21:13] <xequence> and notified if something was not right
[21:13] <OvenWerks> That was the two things I ran across while installing our stuff on top of stock fresh xubuntu
[21:13] <xequence> like realitme privilege - then tell the user to use -controls
[21:14] <xequence> the reason why it's like this is cause Debian has users in audio group
[21:14] <xequence> so, installing jackd is enough to get rt privilege
[21:14] <xequence> and we only sync, we don't change
[21:14] <xequence> in reality, we should have created a new group
[21:14] <xequence> but, what I'm hearing is that devs dont want that
[21:14] <xequence> they'd rather quit using groups all together
[21:15] <xequence> and another solution is rt-kit
[21:15] <OvenWerks> Our preseed file suggests using polkit
[21:15] <OvenWerks> "jack is not PolicyKit aware yet"
[21:16] <xequence> I don't know the details. All I know is we need to fix this before 14.04
[21:16] <OvenWerks> The thing is we don't want root access.
[21:16] <OvenWerks> polkit may allow group access though.
[21:16] <OvenWerks> we could add a policykit action in our settings though.
[21:17] <xequence> HOw would that work?
[21:17] <OvenWerks> Not sure.
[21:18] <OvenWerks> normally things that use polkit that are not polkit aware have to be run pkexec appname
[21:18] <OvenWerks> That would be dbus painful.
[21:18] <xequence> For now, -controls will be an indicator app with a menu. Two lauchers - system settings (individual app, called ubuntustudio-system-settings), and ubuntustudio-installer, and maybe "exit". 
[21:19] <xequence> We should look through all the possibilies for that next cycle, choose one that works, and push for it
[21:19] <OvenWerks> That will work.
[21:20] <xequence> about realtime privilege, my last comment
[21:20] <xequence> I'll want for Debian and Ubuntu to use the same system too
[21:20] <OvenWerks> That would be best I agree
[21:21] <OvenWerks> even better if we can make jackd devs happy too.
[21:21] <xequence> mm :P
[21:21] <xequence> seems like there's one jack for every jack dev these days
[21:22] <OvenWerks> LOL
[21:22] <xequence> would be good to get them to agree too, yes
[21:24] <OvenWerks> I would think we only need to worry about jackd2 though
[21:24] <OvenWerks> I don't think jackd1 does dbus.
[21:24] <xequence> no, it doesn't
[21:25] <OvenWerks> we don't ship it anyway. (he said dissmissively)
[21:28] <xequence> jackd1 can have the old way. both don't need to use the same system for rt
[21:29] <OvenWerks> on another topic, our iso is not building again.
[21:30] <OvenWerks> the libav-extras agian.
[21:31] <OvenWerks> cups-filters : Conflicts: ghostscript-cups I can't figure, one is a dep of the other
[21:32] <xequence> HOw is that related to libav?
[21:32] <OvenWerks> Its the odd one out
[21:33] <OvenWerks> The rest are libav
[21:40] <xequence> seems like -extra packages confilct with non extra packages
[21:42] <xequence> OvenWerks: I think there are newer versions in -proposed
[21:43] <xequence> let me check
[21:46] <xequence> OvenWerks: Yep, newer libav is in -proposed
[21:47] <micahg> if no one beats me to it, I'll upload a new libav-extra tonright
[21:47] <micahg> *tonight
[21:53] <OvenWerks> micahg: thanks, Anything I need to do for installer?
[21:54] <micahg> no, I think I'm good now, just close the needs packaging bug in the changelog if it's not done already
[21:54] <OvenWerks> Ok, should I set it to saucy as well or do you do that?
[21:55] <OvenWerks> micahg: ^^
[21:55] <micahg> nah, let me do that after I test it one more time
[21:56] <micahg> that part is just something to keep in mind when you get upload rights :)
[21:56] <micahg> or making debdiffs
[21:57] <xequence> micahg: I'm about to totally rewrite code for a package - ubuntustudio-controls. Since it's a total rewrite, I'm thinking I just change it with one commit. Any thoughts?
[21:58] <micahg> xequence: well, if it's total, sure
[21:59] <micahg> if there are logical pieces to it, I would suggest doing those as individual commits
[22:00] <xequence> micahg: there will be two individual applications, each with their own desktop file
[22:01] <xequence> most of it will be python/GTK
[22:02] <micahg> xequence: I'd wipe out the old stuff and add each application with its contents separately if it's not too much work
[22:03] <OvenWerks> micahg: bugfix changelog entry commited and pushed
[22:04] <xequence> micahg: ok
[22:05] <OvenWerks> micahg: original bug marked fix commited. I guess the rellease will auto close the bug.
[22:05] <micahg> yeah
[22:12] <OvenWerks> xequence: icon names. Our desktop menu icons are all applications-category.png, can I rename the bunch in -menu (bad as they are) to ubuntustudio-*.*?
[22:12] <OvenWerks> That way I can work on fixing the desktop files.
[22:13] <OvenWerks> and directory files
[22:15] <OvenWerks> Then I can get -menu released in time for FF.
[22:16] <OvenWerks> Artwork freeze is later
[22:16] <OvenWerks> After that I have to redo settings to use all this stuff.
[22:37] <xequence> OvenWerks: Sure.
[22:41] <OvenWerks> xequence: I will work on that next