[05:46] <Eickmeyer> OvenWerks: That nasty dialog box for jackd came back when installing via -installer.
[05:46] <Eickmeyer> Except it never shows.
[06:02] <Eickmeyer> Looks like pkexec can't keep environment variables it's set. Means we might have to change the .desktop file to run a pkexec instead of keeping it in the -installer script itself.
[07:41] <OvenWerks> Eickmeyer: That was the way I started out, but there has been a push to do things "properly" and not run the GUI as root.
[07:42] <OvenWerks> Eickmeyer: almost better to install as as if "no" had been selected and then fix it...
[07:45] <OvenWerks> Eickmeyer: just have -installer check for the .disabled and pkexec mv to right name.
[07:46] <OvenWerks> the thing is, even installing jackd right does not give a the same as installing studio experience anyway.
[07:46] <OvenWerks> -controls would have to be run first after reboot and then logout/in
[07:47] <OvenWerks> The user has to be added to the audio group too.
[16:20] <OvenWerks> Eickmeyer: on farther thought. If there is already a package you have been working on for audio/RT tweaks, It should get run after jack2 is installed and could include an install script.
[16:22] <OvenWerks> That package would have jackd2 as a depend. This would force /etc/security/limits.d/audio.conf.disabled to be installed (if installed with -q) and then the script could do: if [ -f /etc/security/limits.d/audio.conf.disabled ]; then
[16:23] <OvenWerks>  mv /etc/security/limits.d/audio.conf.disabled /etc/security/limits.d/audio.conf
[16:23] <OvenWerks> /usr/sbin/adduser `id -nu ${PKEXEC_UID}` audio
[16:47] <OvenWerks> Eickmeyer: Farther thinking... We can't shouldn't really install a file that another package would have to write over. The /etc/security/limits.d/audio.conf
[16:47] <OvenWerks> thing is not something we should play with
[16:48] <OvenWerks> instead we should add our own file /etc/security/limits.d/something.config
[16:56] <OvenWerks> I should probably look at the jack package installer first. It may not be upset at finding audio.conf already installed
[16:57] <Eickmeyer> OvenWerks: In my experience, it won't even prompt if audio.conf is already there.
[16:57] <OvenWerks> In which case we can just install it.
[16:57] <Eickmeyer> Is audio.conf installed automatically with -controls?
[16:58] <OvenWerks> Eickmeyer: no it takes a mouse click
[16:58] <Eickmeyer> If that's the case, making -controls a dependency of -installer would solve the problem.
[16:58] <Eickmeyer> Oh.
[16:58] <Eickmeyer> Could we add it to -controls as part of the install script?
[16:59] <OvenWerks> however, if controls is a depend, install could call the fix part before it shows anything :)
[16:59] <OvenWerks> The part that does the actual fixing is not a part of the -controls gui because it has to be run pkexec
[17:00] <Eickmeyer> I see.
[17:00] <OvenWerks> so -install could pkexec /usr/sbin/ubuntustudio-system fix
[17:01] <Eickmeyer> OvenWerks: Couldn't -controls have a postinstall script calling that?
[17:01] <OvenWerks> That would install audio.conf as well as add the user to the audio group
[17:01] <Eickmeyer> Doesn't need pkexec at that point.
[17:03] <OvenWerks> a post install could better just include the few lines needed directly
[17:04] <Eickmeyer> Seems like that would make it even simpler than having to run -controls once.
[17:04] <OvenWerks> The user does need to know they have to logout and back in to gain the permisions.
[17:05] <OvenWerks> -controls will tell them so if they run it...
[17:06] <Eickmeyer> Well, then documentation, or if they fail to RTM then running -controls will get it across.
[17:09] <OvenWerks> -install could check for locked memory access and drop a dialog or message on the screen too.
[17:11] <OvenWerks> My thought is that if the person installs -controls, they will run it and get the message that way, but if it is installed as a dep of -install then -install should tell them after installing all they ask for.
[17:11] <Eickmeyer> Not a bad idea. Redundancy is good in this case.
[17:14] <OvenWerks> Ok, so the plan is to add rt setup to -controls postinstall and then add a permision check to -install
[17:14] <Eickmeyer> OvenWerks: Yes.
[17:28] <Eickmeyer> OvenWerks: Make sure you do another pull for -installer. I just updated for -controls dependency, but I don't know how to write the dialog box.
[17:30] <OvenWerks> Eickmeyer: I will look at it later... I will have to fix -controls first. Then -controls will need to be test installed as a dep by installing -install on a non-studio base
[17:30] <OvenWerks> I will probably have to do a git clone of install anyway.
[17:31] <OvenWerks> I haven't pulled sinse bzr
[17:31] <OvenWerks> (Bizzar!)
[17:32]  * OvenWerks needs to have more coffee
[17:34] <Eickmeyer> OvenWerks: I've got a non-studio base, so we'll use my system to test. It's a minimal Ubuntu install right now.
[17:38]  * Eickmeyer also gets more coffee
[17:39]  * OvenWerks realizes he has no idea how to write a .postinstall
[17:42] <Eickmeyer> I'll get the .postinstall.
[17:43] <OvenWerks> It just has to run /usr/sbin/ubuntustudio.system fix
[17:53] <Eickmeyer> This is weird. I've got it, but it's not letting me push.
[17:54] <OvenWerks> did you pull rebase master etc?
[17:54] <OvenWerks> I generally keep two branches: master and a work branch
[17:55] <OvenWerks> make the change in work.
[17:55] <OvenWerks> git pull to master
[17:55] <OvenWerks> change to work do git rebase master
[17:55] <Eickmeyer> I had to reclone the thing.
[17:55] <OvenWerks> switch to master 
[17:55] <Eickmeyer> What I did worked.
[17:56] <OvenWerks> do the local merge then push
[17:56] <Eickmeyer> All I did was clone, add the postinst, then push. Worked like a charm. It was asking me to sign-in, so must've been something weird with git.
[19:26] <Eickmeyer> OvenWerks: Did you get the postinst?
[19:26] <OvenWerks> yes
[19:26] <Eickmeyer> Cool.
[19:26] <OvenWerks> does it work?
[19:31] <Eickmeyer> I'll try it.
[19:32] <OvenWerks> it needs to be tried without installing jack first
[19:33] <Eickmeyer> Grr.... it pulls jackd2 and asks to install /etc/security/limits.d/audio.conf, which I guess is okay considering this step would be installed either via command line, synaptic, software center, or otherwise.
[19:34] <OvenWerks> Oh, Ya. I guess that would be true, jackd is a dep
[19:36] <Eickmeyer> Really, that alone solves the problem: making -controls a dependency of -installer. ¯\_(ツ)_/¯
[19:36] <OvenWerks> So long as the user logs out and back in.
[19:37] <Eickmeyer> Yes, so perhaps we just need to add that to -installer when it's done doing its thing.
[19:37] <Eickmeyer> That dialog you were talking about.
[19:37] <OvenWerks> Ya, I will take a look soon.
[19:37] <Eickmeyer> Cool.
[19:39] <Eickmeyer> OvenWerks: When the postinstall script runs, it adds user "root" to audio... not the user that called the sudo.
[19:39] <OvenWerks> Seems I don't have a copy of install anyway...
[19:40] <OvenWerks> Eickmeyer: Ah, it uses sudo instead of pkexec inside?
[19:41] <Eickmeyer> Yes, because sudo is required to run apt or apt-get. It doesn't even use sudo since sudo was already called by whoever installed.
[19:42] <OvenWerks> the user is based on a variable that pkexec passes
[19:42] <Eickmeyer> Yes. Unfortunately, one can't pkexec in a dpkg -i.
[19:43] <Eickmeyer> So, it might have to be something that -installer calls.
[19:43] <OvenWerks> sudo also passes the user in some manner
[19:43] <Eickmeyer> Not a huge deal since it could be called as part of installing anything else.
[19:44] <OvenWerks> Maybe check for both, obviously $user returns "" so check if pkuser = "" then test for whatever sudo uses
[19:45] <OvenWerks> if one of them has a user in it, use that. Actually pkuser is userid so an empty variable is probably 0 or root
[19:46] <OvenWerks> I think this is fixable.
[19:46] <Eickmeyer> Right. Sudo acts as root.
[19:46] <Eickmeyer> Honestly, I don't even think we need the postinst if -controls is a dependency of -installer since it calls that dialog, which is what we're avoiding.
[19:46] <Eickmeyer> Takes care of the dialog so that -installer doesn't have to.
[19:47] <OvenWerks> we have to install jackd with quite don't ask any questions
[19:48] <Eickmeyer> Well, if -controls is already installed before -installer runs, then jackd will be quiet since it will see that 1) it's already installed, and 2) audio.conf already exists.
[19:48] <Eickmeyer> Basically, that yes/no will already be answered.
[19:49] <Eickmeyer> And dpkg knows this.
[19:50] <Eickmeyer> We can then have installer run "pkexec ubuntustudio-system fix".
[19:50] <Eickmeyer> Takes care of if they answered "no".
[19:51] <OvenWerks> Ok
[19:52] <Eickmeyer> I'm going to give it a whirl.
[19:52] <OvenWerks> installer should do that at startup
[19:53] <Eickmeyer> I would agree, except what if the user doesn't want to use Studio for audio?
[19:54] <Eickmeyer> Actually, that's beside the point.
[19:54] <Eickmeyer> It might be bad to give the impression that the entire interface is running in root.
[19:56] <OvenWerks> I will also fix the bug in -controls, group will only be joined if user id > 999
[19:56] <OvenWerks> (interactive users start at 1000)
[19:57] <Eickmeyer> Okay, just pushed the removal of the postinst.
[20:02] <OvenWerks> Oh... this is the wish version... 
[20:02] <Eickmeyer> wish version?
[20:04] <OvenWerks> tk/tcl
[20:05] <OvenWerks> It was never released when I did it.
[20:05] <Eickmeyer> This was the code I pulled from bzr.
[20:05] <OvenWerks> yes, I uploaded it, but noone wanted to do the release work.
[20:06] <Eickmeyer> Well, it's about time we got that moving then.
[20:07] <OvenWerks> I think I decided that tk/tcl pulled in the fewest deps
[20:08] <Eickmeyer> I saw that in the changelog, the switch to tk/tcl.
[20:08] <OvenWerks> and the old dep on zenity
[20:09] <OvenWerks> zenity is getting bit rot
[20:09] <Eickmeyer> So, you got the changes in, but nobody did the release work.
[20:09] <OvenWerks> It used to be everything had zenity as there was both a qt and gnome version
[20:10] <OvenWerks> Ya.
[20:10] <Eickmeyer> Well, I see no reason why we can't move forward with it.
[20:13] <OvenWerks> tk can do a lot more than zenity. It used to be my gui of choice when I was developing on Linux for windows at work (15 - 20 years ago)
[20:14] <OvenWerks> Eickmeyer: would you like to change installer to include the package list inside the script rather than on the commandline?
[20:15] <OvenWerks> would you like to add uninstall? anything like that?
[20:15] <Eickmeyer> OvenWerks: That's not a bad idea. After all, what else would we be using this script for?
[20:16] <Eickmeyer> Well, we could add uninstall, I suppose. 
[20:16] <Eickmeyer> As long as it's not too much work.
[20:16] <OvenWerks> for that matter it would be possible to switch to python like -controls if it is easier to maintain that way.
[20:17] <Eickmeyer> If we switch to Python, it might look better too since then we coulld use a toolkit.
[20:17] <OvenWerks> I originally thought it could be used as a generic install script GUI.
[20:20] <OvenWerks> even in tk it could look a lot different
[20:20] <OvenWerks> Ardour originally used tk
[20:20] <Eickmeyer> Well, I think using it for a post-install "I want this set of packages that I didn't install at install time" combined with a "I want Ubuntu Studio on my {insert flavor} installation" solution. Doesn't need to be generic.
[20:21] <OvenWerks> No, we have never used it genericly
[20:21] <Eickmeyer> If someone wants to use it for their own purpose, they can feel free to fork it.
[20:21] <OvenWerks> Oh, maybe we did
[20:22] <Eickmeyer> What else was it used for?
[20:23] <OvenWerks> We used to have one desktop file for each sub menu
[20:23] <Eickmeyer> Oh, I see.
[20:23] <Eickmeyer> Maybe we do just keep the command-line then.
[20:24] <Eickmeyer> Unless we've done away with that.
[20:24] <OvenWerks> So under audio production there was an install item that would install the audio meta or other applications we didn't ship but we liked to provide a way of installing.
[20:25] <OvenWerks> there is only one desktop file in there now
[20:25] <Eickmeyer> Okay, so we've done away with that then. No reason why we can't re-tool it.
[20:26] <OvenWerks> we could do both, if no cl params use internal list
[20:26] <OvenWerks> It does need someone to keep up with it
[20:27] <Eickmeyer> I'd have no problem with that, since while I'm no coder it's easy for me to parse.
[20:28] <OvenWerks> Maybe we should add a python branch
[20:29] <Eickmeyer> Yeah. Maybe transition to Python with 19.10?
[20:29] <OvenWerks> That way, Install can be released as is. And there is no pressure to get it done
[20:29] <Eickmeyer> Yeah.
[20:31] <Eickmeyer> Confirmed: having -controls as a dep for -installer did the trick, installation is proceeding without a hitch (or a hang, as the case was).
[20:31] <Eickmeyer> OvenWerks: ^
[20:42] <OvenWerks> Cool
[20:43]  * OvenWerks is realizing how painful it was to make something follow another process running as root.
[20:44] <OvenWerks> Does the process bar still work right?
[20:46] <Eickmeyer> Yes, it still works.
[20:51] <OvenWerks> cool
[20:53] <OvenWerks> I think the package name needs to be in a bigger column
[20:54] <Eickmeyer> Yeah. "ubuntustudio-" takes quite a bit of room to begin with.
[21:00] <OvenWerks> Ya, I don't set the list box width, what size should I try?
[21:01] <Eickmeyer> 150px to start?
[21:01] <OvenWerks> in charactors
[21:02] <Eickmeyer> Oh. go for 25.
[21:04] <OvenWerks> grub2-themes-ubuntustudio fits
[21:05] <Eickmeyer> Perfect. Is that the longest one?
[21:06] <OvenWerks> Mine only shows three becasue the rest are already installed
[21:06] <OvenWerks> I can push it though
[21:06] <Eickmeyer> plymouth-theme-ubuntustudio is longer.
[21:06] <Eickmeyer> (I might consolidate those two into "ubuntustudio-branding")
[21:07] <OvenWerks> So make it 30
[21:07] <Eickmeyer> ok
[21:07] <OvenWerks> I want to play with the grub one too at some time
[21:07] <Eickmeyer> Yeah. The grub one was fun. Forked the Ubuntu MATE grub theme, I think it looks good.
[21:08] <Eickmeyer> I just need to get it up and sponsored since it's a new package.
[21:11] <OvenWerks> does the grub one include the 09-grub or is that still in something else?
[21:11] <OvenWerks> the /etc/grub.d/
[21:12] <OvenWerks> 09_lowlatency
[21:14] <Eickmeyer> That's something else.
[21:14] <OvenWerks> Right now 09_lowlatency just adds the lowlatency entry at the top then calls 10_linux
[21:14] <Eickmeyer> Yeah. that's in ubuntustudio-default-settings and ubuntustudio-lowlatency-settings.
[21:14] <OvenWerks> I would like to change it so that it replaces 10_linux
[21:14] <Eickmeyer> grub2-themes- only themes grub.
[21:14] <OvenWerks> Ah.
[21:15] <Eickmeyer> Replacing 10_linux would work if it wasn't directly installed by another package. That gets sticky with file conflicts.
[21:16] <OvenWerks> I think it would be nice to list the latest RT as default (if it exists) followed by the latest lowlatency and then the latest generic all with labels.
[21:16] <Eickmeyer> There's no RT in Ubuntu.
[21:16] <Eickmeyer> Was too problematic to maintain iirc.
[21:16] <OvenWerks> My thought was to have 09_lowlatency chmod -x 10_linux
[21:17] <OvenWerks> Ya, there is no RT but if someone builds one, it should be auto default]
[21:18] <Eickmeyer> OvenWerks: So, then one would have to do a postinst in -default-settings and -lowlatency-settings. 
[21:18] <OvenWerks> no, the 09 could do that on the fly every time it runs :)
[21:19] <Eickmeyer> Ohhhhh! I seee!
[21:19] <Eickmeyer> If that's the case, and it works, then have at it!
[21:19] <Eickmeyer> I mean, are we being redundant by keeping 10 at +x?
[21:19] <OvenWerks> The proper way would be to make a ubuntustudio-grub package that "replaces" one of the main grub packages
[21:20] <OvenWerks> better yet would be to push a change upstream
[21:20] <Eickmeyer> Muh head a splode with that idea.
[21:22] <OvenWerks> If I added a kernel_order=this,that,the_other to the user config file, the standard one could have generic at the front
[21:22] <OvenWerks> then I could push it up stream
[21:23] <OvenWerks> I think there is a file that can be added by a distro to preset those variables and the user config comes after
[21:23] <OvenWerks> the user config would not have that line so the default would be used
[21:23] <OvenWerks>  This is quite a long way down my list of things to do...
[21:24] <Eickmeyer> Yeah, sounds great, but yeah, low priority, and getting that upstream in Debian would be painstaking.
[21:24] <OvenWerks> not debian, grub
[21:25] <OvenWerks> debian would then just take it...
[21:25] <Eickmeyer> Oh. You think the grub folks would want that?
[21:25] <Eickmeyer> That would affect every distro.
[21:26] <OvenWerks> not really
[21:26] <OvenWerks> they would be able to do that and for most people it would do nothing
[21:26] <Eickmeyer> That's true.
[21:26] <OvenWerks> The default would be no change
[21:27] <OvenWerks> it would not be something that would make a new grub version, but it would be included in whatever the next version was
[21:30] <Eickmeyer> Right.
[21:35] <OvenWerks> ok thats odd, https://code.launchpad.net/~ubuntustudio-dev/ubuntustudio-installer/+git/ubuntustudio-installer says master was updated 4 hours ago.
[21:35] <OvenWerks> but :https://git.launchpad.net/ubuntustudio-installer/commit/ shows later
[21:36] <Eickmeyer> OvenWerks: Happened to me before. I had to delete my local repo, re-clone, pull (merge) with the commit comment "Launchpad git error" on the merge, then push.
[21:37] <Eickmeyer> It's annoying.
[21:38] <Eickmeyer> I think it's a launchpad bug with its git hosting implementation.
[21:44] <OvenWerks> I think I will leave it over night and see if it updates on its own
[21:47] <Eickmeyer> Cool