[01:45] <OvenWerks> Eickmeyer: um, ok, so long as it runs after the ondemand one on ubuntu.
[03:00] <Eickmeyer[m]> OvenWerks: It won't even run unless it's enabled, which it's not by default.
[15:59] <OvenWerks> Eickmeyer: ok, Im confused. I am not sure "what" won't run unless its enabled"
[16:01] <Eickmeyer[m]> OvenWerks: So, a systemd service file does nothing unless called upon. By sitting in /lib/systemd/system it does nothing unless someone calls "systemctl start *.service". Additionally, it does nothing at boot unless it's enabled by "systemctl enable *.service".
[16:01] <OvenWerks> not true
[16:02] <OvenWerks> at least that has not been my experience
[16:02] <Eickmeyer[m]> Any systemd document I have ever read says what I wrote.
[16:02] <OvenWerks> enable *.service just drops a link in the right place
[16:03] <Eickmeyer[m]> The file simply "exists" until called upon.
[16:03] <OvenWerks> if the link is pre installed it runs
[16:03] <Eickmeyer[m]> Exactly, enabling it to be called-upon at boot.
[16:03] <Eickmeyer[m]> In this case, I'm not doing that.
[16:04] <Eickmeyer[m]> (not creating the link)
[16:04] <OvenWerks> all of the scripts in /lib/systemd/ do nothing unless there is service that calls them.
[16:05] <OvenWerks> From a package?
[16:05] <Eickmeyer[m]> Correct, and that service must be in /lib/systemd/system and either A) linked in /etc/systemd/system or B) manually run.
[16:05] <OvenWerks> a package should create all needed links
[16:05] <OvenWerks> Are we still talking about -controls/ondemand?
[16:05] <Eickmeyer[m]> That's correct, but if it's a systemd link it needs to be created the systemd way.
[16:06] <OvenWerks> no that is not true.
[16:06] <Eickmeyer[m]> Yes, but controls/ondemand is diferent.
[16:06] <OvenWerks> the package can create the link just fine.
[16:06] <Eickmeyer[m]> Ok, I'll rephrase that. A systemd link should be created the systemd way.
[16:06] <OvenWerks> not for a package install
[16:07] <Eickmeyer[m]> Which isn't hard (postinst: systemd enable foo.system)
[16:07] <Eickmeyer[m]> *systemctl enable foo.system
[16:07] <OvenWerks> I still disagree... but whatever.
[16:08] <OvenWerks> the enable tends to put the links in /etc not in /lib/systemd/system/
[16:08] <Eickmeyer[m]> As it should.
[16:08] <Eickmeyer[m]> Enable simply makes it run at boot.
[16:08] <OvenWerks>  the /etc/ should only be used for local config not package config
[16:09] <Eickmeyer[m]> There are exceptions to that, in this case, systemd services.
[16:09] <OvenWerks> that is so the system admin can modify the operation of the system without making package upgrade fail
[16:09] <Eickmeyer[m]> Systemd throws that old rule out the window.
[16:09] <OvenWerks> not very smart
[16:10] <OvenWerks> not old rule but correct rule
[16:10] <Eickmeyer[m]> But it is the way that it is. systemd is smarter at handling that situation than you think.
[16:10] <OvenWerks> systemd also runs correctly puts in links in the correct places too.
[16:11] <Eickmeyer[m]> Yes, but not unless it's told.
[16:11] <OvenWerks> putting a link in the right place "tells" systemd what to do with it
[16:12] <Eickmeyer[m]> That's correct. Such as when systemd is told to enable a .system file, it makes a link in /etc/systemd/system/{target.wants}.
[16:13] <Eickmeyer[m]> It bases that link on the systemd file saying "WantedBy = *.target".
[16:13] <OvenWerks> or even if the link is in /lib/systemd/system or a sub directory
[16:13] <OvenWerks> I have tested this rather a lot
[16:14] <OvenWerks> it does work even without use the "enable" command even with no link in /etc
[16:14] <Eickmeyer[m]> Yes, but it doesn't automatically run in anything in /lib/systemd/system unless it's enabled. ondemand.service is an exception because it's enabled on Ubuntu systems already (there's a symlink in /etc/systemd/system/multi-user.target/) and it looks for anything in its directory called .conf.
[16:15] <OvenWerks> There are rather a lot of commands/files in /lib/systemd/system and /lib/systemd/user that just run with no link what so ever in /etc
[16:15] <Eickmeyer[m]> Yes, but the systemd file I made does not. It cannot unless it's "enabled".
[16:15] <OvenWerks> wrong totallly wrong I have seen things run with out any enabling done
[16:16] <OvenWerks> Then you have not put the link in the right place
[16:16] <Eickmeyer[m]> Then those things have a link somewhere in /etc/systemd.
[16:16] <OvenWerks> no they don't
[16:16] <Eickmeyer[m]> No, I don't want the systemd file I made to run on Ubuntu. I only want it to run on Fedora.
[16:17] <Eickmeyer[m]> Hence, I don't have Ubuntu enable it.
[16:17] <Eickmeyer[m]> If it makes you feel better, I can have .postinst delete it during install.
[16:17] <OvenWerks> unless systemd is totally different on fedora it likely works much the same way
[16:18] <OvenWerks> so how many files are in /etc/systemd/system/*/ ?
[16:18] <Eickmeyer[m]> Fine, I'll have postinst delete it, but it needs to be there for non-Ubuntu systems otherwise you can't even launch -controls.
[16:19] <OvenWerks> wierd
[16:19] <OvenWerks> it sounds like a really really bad design]
[16:20] <OvenWerks> just like hard linking /lib/systemd to /usr/lib/systemd
[16:20] <Eickmeyer[m]> Non-Ubuntu systems don't have ondemand.service. That's an ubuntu-only thing made to replace init.d/ondemand. So, nothing creates the cpufreq files that -controls reads when it starts. In order to fix that, I needed something to run a systemd service on boot.
[16:21] <OvenWerks> That much I can see
[16:23] <Eickmeyer[m]> And that is why I did what I did. I wouldn't want it to run at boot on Ubuntu since that conflicts with the operation of ondemand.service (not so much conflicts as runs the /systemd/ubuntustudio service twice). So, I made it "WantedBy=multi-user.target" so that it only gets called if it is seen in /etc/systemd/system/multi-user.target" as a symlink.
[16:24] <OvenWerks> so create another *.service file in /lib/systemd/system/ called whatever.service. It should have in it:
[16:24] <OvenWerks> [Unit]
[16:24] <Eickmeyer[m]> Yes, that's exactly what this has.
[16:24] <OvenWerks> Description=Set the CPU Frequency Scaling governor
[16:24] <OvenWerks> ConditionVirtualization=no
[16:24] <OvenWerks> ConditionPathExists=/sys/devices/system/cpu/online
[16:25] <OvenWerks> [Service]
[16:25] <OvenWerks> Type=idle
[16:25] <OvenWerks> ExecStart=/lib/systemd/studio
[16:25] <Eickmeyer[m]> It's much simpler than that: https://git.launchpad.net/ubuntustudio-controls/tree/lib/systemd/system/studio-system.service
[16:25] <OvenWerks> That one does have an install segment
[16:26] <Eickmeyer[m]> Yes, but that is for "systemctl enable" reference to make the symlink. The packaging file for rpms calls that as a postinst.
[16:27] <Eickmeyer[m]> Otherwise it sits there and does nothing. I verified it already.
[16:27] <OvenWerks> you can remove the Install section and just put a link in /lib/systemd/system/multi-user.target.wants/ too
[16:28] <OvenWerks> but yes it could just be enabled
[16:29] <Eickmeyer[m]> Exactly. Fedora (and openSUSE) like to do things the "systemd way" as opposed to Debian and Ubuntu that make a lot of compromises for people who objected to using systemd in the first place.
[16:29] <OvenWerks> but looking at the system folder it looks like even ubuntu has put everyth8ing in /etc
[16:30] <Eickmeyer[m]> Yep. That's done during the postinst scripts by way of "systemctl enable".
[16:31] <OvenWerks> so, I guess we couold change all of the systemd stuff to do that. Its fine if not very "Linuxy" (or Unixy"
[16:31] <OvenWerks> next question is does it work?
[16:32] <Eickmeyer[m]> Yes, it works.
[16:32] <OvenWerks> it may need ConditionPathExists=/sys/devices/system/cpu/online
[16:33] <Eickmeyer[m]> It doesn't.
[16:33] <Eickmeyer[m]> It just works the way it is. I have tested it.
[16:33] <OvenWerks> maybe it is fixed then
[16:34] <Eickmeyer[m]> Must be, but I do know I had to have kernel-tools installed since we change the cpu governor.
[16:34] <Eickmeyer[m]> brb, kid to school.
[16:35] <OvenWerks> when ubuntu first switched to systemd, and they were still using ondemand in /etc/init.d/ there were problems with it running too soon
[16:35] <OvenWerks> in fact, so far as I know cpufreq still had that problem last I looked
[16:36] <OvenWerks> (we don't use it anymore)
[16:43] <OvenWerks> Eickmeyer[m]: it is probably ok to have both ways of running that installed.
[16:43] <OvenWerks> it should not matter if it gets run twice (in ubuntu/debian)
[16:45] <OvenWerks> or we could set up ubuntu so that ondemand is merely turned off and use the second method to actually do the work.
[16:45] <OvenWerks> It sounds like in debian/buntu land, system is done one way and user another way.
[16:46] <OvenWerks>  it is also quite possible that debian/buntu basically ignores systemd in user land except for packages like pulse that come from and upstream that does systemd by default
[16:48] <OvenWerks> (except for gnome which kind of messes things up)
[16:52] <OvenWerks> I think that perhaps the debian packaging setup requires a multilevel config system for better stability when updating software... 
[16:53] <Eickmeyer[m]> And that's very possible. I think, for consistency sake, I'll have postinst remove the systemd service I created, but the packaging for Fedora keep it.
[16:54] <Eickmeyer[m]> OvenWerks: For reference, here's the .spec file used to build the .rpm package: https://pagure.io/studio-controls/raw/master/f/studio-controls.spec
[16:54] <OvenWerks> Eickmeyer[m]: The main thing in ubuntu is that ondemand has a delay in it (60 sec)
[16:54] <OvenWerks> so it has to be "repaced"
[16:54] <Eickmeyer[m]> In that, I remove the ondemand-service stuff.
[16:55] <OvenWerks> *replaced
[16:55] <Eickmeyer[m]> So, there's no reason why in Ubuntu I couldn't remove studio-system.service.
[16:55] <Eickmeyer[m]> Just different ways of doing things. ¯\_(ツ)_/¯
[16:56] <Eickmeyer[m]> And, no, systemd isn't very unix-like. That was, and is, the biggest objection people have with it.
[16:58] <OvenWerks> It would be nice to have one set of files that just works... but then it would not work with a system that still uses /etc/init.d for everything :P
[16:59] <OvenWerks> There are somethings I like about systemd... 
[17:00] <Eickmeyer[m]> I think, at this point, we have a run-time dependency on systemd for -controls, tbh.
[17:02] <OvenWerks> yup I don't think we nee to worry about making it work for slackware :)
[17:03] <Eickmeyer[m]> Hahaha
[17:03] <Eickmeyer[m]> Or Gentoo.
[17:05] <Eickmeyer[m]> So, do we start working on unbranding it next cycle?
[17:05] <OvenWerks> yes
[17:05] <Eickmeyer[m]> Cool.
[17:06] <Eickmeyer[m]> Either way, it runs and works on Fedora, haven't tried openSUSE yet.
[17:08] <Eickmeyer[m]> Though, for Fedora, I did have to package python-jack and zita-ajbridge.
[17:08] <OvenWerks> :)
[17:08] <OvenWerks> they are both worth having anyway
[17:09] <Eickmeyer[m]> Exactly. I was surprised they weren't there already. python-jack is undergoing review as we speak, and zita-ajbridge has been approved for release.
[17:10] <Eickmeyer[m]> I'm waiting for those both to hit RawHide. Once those hit, submitting studio-controls will be the next step.
[17:13] <Eickmeyer[m]> BTW, Fedora's default kernel (the only one they have, really) is very nicely optimized for lowlatency.