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