[01:23] <OvenWerks> Eickmeyer: in your comment on the - no remove install media - bug, you did not indicate if the test install was to metal or a virtual setup. The remove media message seems to show up in the virtual case where it is not needed, but not on a hw install. so if it worked on a hw install, great fixed! otherwise... probably still broken
[01:24] <Eickmeyer> OvenWerks: It was a hardware install, so definitely fixed.
[01:27] <OvenWerks> great! I think I saw a similar report for xubuntu as well
[01:28] <Eickmeyer> OvenWerks: Well, it seems that Ubuntu proper and Ubuntu MATE are affected, so there are likely to be more spins.
[16:34] <wonko> The use of globals in autojack makes me sad
[16:34] <wonko> I don't think I want to address that right now, however
[16:45] <OvenWerks> wonko: the idea of giving each call the whole list has it's drawbacks too.
[16:46] <wonko> That's what classes are for. :)
[16:46] <OvenWerks> wonko: however, it is a good idea to keep each commit to small spaces
[16:46] <OvenWerks> hmm small changes maybe?
[16:47] <wonko> not just commit, but block of work. I'm trying to maintain the scope of just adding configparser support and nothing else (and maybe cleaning up some formatting/PEP8 nonsense as I go along)
[16:47] <OvenWerks> maybe so the pep stuff first
[16:48] <OvenWerks> that way the next change is just that
[16:48] <OvenWerks> That is get any formatting changes over with in one commit before doing anything else
[16:48] <OvenWerks> it makes the diff a lot easier to read
[16:48] <wonko> Yeah, that probably would have been best. PyCharm does all the heavy lifting though so maybe if I do a quick branch to update that and merge the changes into configparser we'll get a more accurate showing of changes
 heheh fun fact about Pycharm
 you can make many commits :P
 if it has git integration ;)
 so when you're done iwth say formatting, you just commit *that*
 then you make more changes, then commit *those*
 *uses PyCharm religiously for major Python projects*
 ... you can do all this manually too but :P
 anyways I digress :)  *lurks*
[16:51] <wonko> teward001: It's not just commits though (and yes, I hit the commit checkmark button *constantly* in PyCharm)
[16:52] <wonko> It's trying to keep the scope of the change in control
[16:52] <wonko> this branch is for adding configparser support, so it should really only have commits related to that
 ah.  well i'd still fix formatting things *first* ;)
 but i digress
[16:53] <wonko> right, which is what we were just talking about. I'll do a separate branch to handle that
[16:53] <wonko> then merge it into my configparser branch to get back on track with scope
[16:53] <wonko> Also I'm going to start calling you jayztwocents now Mr. I Digress. :-P
 lol
 be glad you caught me when i'm caffeinated
[16:54] <OvenWerks> of course from my POV it is "break" formatiing first. Python formatting is  :P
 Erich has seen me when i have NO caffeine, and can attest to the evil there :)
[16:55] <wonko> OvenWerks: python formatting is worse than that. It's one of the things that kept me from Python in the first place and it's something I still hate.
[16:55] <teward> ... though tsimonq2 can be equally well aware of my evil uncaffeinated state :P
[17:23] <wonko> OvenWerks: https://code.launchpad.net/~ubuntustudio-dev/ubuntustudio-controls/+git/ubuntustudio-controls/+merge/374098
[17:24] <wonko> Nothing should have changed, but I'd like you to eyeball this real quick just to make sure it looks ok before we merge it.
 erm
 why is `.idea` not in your gitignore?
[17:25] <wonko> it is
 then your git is broken
 because it included .idea/codeStyles/* and such
 in the diff
[17:25] <wonko> oh crap, I commited before adding the .gitignore. Let me clean tha tup
 .idea/.gitignore (+3/-0)  .idea/codeStyles/codeStyleConfig.xml (+5/-0)  .idea/inspectionProfiles/profiles_settings.xml (+5/-0)  .idea/misc.xml (+7/-0)  .idea/modules.xml (+8/-0)  .idea/ubuntustudio-controls.iml (+11/-0)  .idea/vcs.xml (+6/-0)
 that's the stuff that was still included :P
 NACK on the diff as is, because BadFilesIncluded
[17:27] <wonko> yeah, PyCharm added that before I added the gitignore
[17:27] <OvenWerks> wonko: it looks like you would like to do a reset?
 yeah i'd start the diffset over again
[17:28] <wonko> Yeah, let me nuke and start over. Didn't actaully spend effort coding, so it's not hard. :)
[17:28] <OvenWerks> wonko: it doesn't look like you starting at where master is now?
[17:29] <wonko> it was a branch of master, so it had better be
[17:29] <OvenWerks> Yup
[17:30] <OvenWerks> Sorry I was looking at configparser from last week
 ah, right, that's why it lets me reject the proposal... I forgot taht Erick added me to the Ubuntu Studio Dev team, and my Core Dev status also gets me in the team.  Was wondering why LP let me do that xD
 Erich*
[17:32] <Eickmeyer> Because reasons.
 lol
 true.  This said, i forgot that that gives me elevated access xD
[17:33] <Eickmeyer> smdh
 ... well Core Dev would've gotten me that too
[17:33] <OvenWerks> left over from zequence a lot of it.
[17:33] <Eickmeyer> ^
[17:33] <Eickmeyer> I'm STILL cleaning up his mess.
 OvenWerks: I hope you don't mind me stepping in and ursurping the requested review on the merge proposal because of the cruft in it xD
 i usually don't like doing that but in *this case*... :)
[17:34] <wonko> I'm all for it
[17:34] <wonko> catch my nonsense, please. :)
 that's what Erich told me to do when he added me to the dev team xD
[17:35] <OvenWerks> not a problem... I am waiting for the dust to settle before I do anything more at all
[17:36] <OvenWerks> @teward001 FYI, none of these changes are for this cycle (should be obvious) but for next cycle.
[17:37] <wonko> https://code.launchpad.net/~ubuntustudio-dev/ubuntustudio-controls/+git/ubuntustudio-controls/+merge/374100
[17:37] <wonko> that should be better
 OvenWerks: Yep!
 we're waaaay past the point of getting things in :P
 eww those subprocess.run calls could use some `shlex` refactoring >.<
 just saying :P
 wonko: as a pythoner, LGTM, but it's up to OvenWerks to ack the merge :P
 i just step in to deny things when it makes sense to xD
 BRB work meeting.
[17:41] <wonko> teward and his ban hammer
[17:42] <teward> lol
[17:42] <teward> you asked for the review ;)
[17:42] <teward> *returns to work*
[17:43] <wonko> https://i.redd.it/iy4iri8m63r21.jpg <-- actual picture of teward
[17:44] <OvenWerks> have no idea what he means by "subprocess.run calls could use some `shlex` 
[17:44] <OvenWerks>                    refactoring"
[17:45] <OvenWerks> getting the things to work was already painful. They all used to be single string commands sent to bash or sh.
[17:45] <OvenWerks> (which just worked)
[17:46] <teward> OvenWerks: the way it's currently split into bits in the array can be done as a single string passed to `shlex.split(...)` but that's for later consideration :)
[17:46] <teward> just things about how SP calls are in there tahat irk me ;)
[17:46] <teward> but not critical :)
[17:46] <OvenWerks> what is SP calls?
[17:47] <teward> SP = subprocess
[17:47] <teward> subprocess.run(["command", "here", "with", "args"]) == subprocess.run(shlex.split("command here with args"))
[17:47] <teward> i'm just picky and annoyingly so :P
[17:47] <teward> but as i said
[17:47] <teward> not critical nor does it really need refactoring to be Good 2 Go
[17:47] <OvenWerks> That would mean making the string first so same difference.
[17:48] <teward> but the no-op PEP8 changes look good as is to me :)
[17:48] <teward> but again, that one's not my call :)
[17:48] <OvenWerks> So long it still runs is all I care
[17:48] <teward> ... jeez my boss is late to the meeting xD
[17:48] <OvenWerks> Thats what bosses are for
[17:49] <OvenWerks> (making the little people wait...)
[17:51] <wonko> OvenWerks: I pushed those to files to /usr/bin on my machine and everything is working as expected (un-surprisingly)
[17:51] <wonko> s/to/two/
[17:51] <OvenWerks> So this is now before config parser?
[17:51] <wonko> yes
[17:51] <wonko> this is without config parser changes
[17:52] <wonko> this is just formatting changes branch
[17:52] <wonko> so that should be good for a merge as far as I know
[17:53] <wonko> teward: Also, this is why I don't like doing straight merges to master. You caught a mistake. Merge request system FTW. :)
[17:53] <OvenWerks> Ya I think so
[17:56] <OvenWerks> probably for mere formatting changes a changelog entry was not needed. But leave it in anyway.
[17:57] <wonko> Probably, but it seemed like the right thing to do
[18:01] <OvenWerks> Ok so how do I merge (online)? Or do I just clone and merge offline?
[18:06] <wonko> I've never used launchpad before, so I don't really know, but there should be a way for you to approve the merge
[18:06] <wonko> and then there should be a way for you or I to apply the merge within launchpad itself.
[18:07] <wonko> I can click on the pencil next to Needs review and get the list of options, maybe that's where you do it?
[18:07] <wonko> not gonna lie, launchpad is hella janky and I don't like it. :)
[18:07] <OvenWerks> I can't find it... and the command they give doesn't work either... give me a minute or two. I am used to working with the PR method...
[18:08] <wonko> This is a PR
[18:08] <wonko> just with a different name
[18:08] <wonko> https://imgur.com/kCPGDrk.png
[18:08] <wonko> There, where it says Status
[18:08] <wonko> I think that's where you change it?
[18:08]  * wonko dreams of gitlab
[18:13] <OvenWerks> Actually I should be able to just switch to the remote branch
[18:15] <wonko> don't do it outside of the merge system, that defeats the purpose. :)
[18:16] <wonko> Ok, it shows as approved
[18:16] <wonko> but now I'm not sure what to do.
[18:21] <OvenWerks> It says merged
[18:22] <OvenWerks> I had to do a pull first so My system knew of the new branch, then I could do checkout branch
[18:22] <OvenWerks> merge and push
[18:23] <wonko> hmm, ok
[18:23] <wonko> like I said. Hella Janky. :)
[18:24] <OvenWerks> so if you look at: https://code.launchpad.net/~ubuntustudio-dev/ubuntustudio-controls/+git/ubuntustudio-controls/+ref/master
[18:24] <OvenWerks> under recent commits?
[18:24] <OvenWerks> it says merged from branch....
[18:24] <wonko> yeah, guess it does some behind the scenes tracking
[18:24] <wonko> ok, at least we know how that works now
[18:24] <OvenWerks> So yu can remove that branch now.
[18:25] <wonko> deleted
[18:25] <OvenWerks> is configparser finished now or does it need redoing?
[18:26] <wonko> I need to merge the new master into it and finish up the work on autojack
[18:26] <OvenWerks> ok
[18:38] <wonko> Ok, master merged into configparser branch, now, where was I? :)
[19:14] <wonko> OvenWerks: don't know if you know the answer to this or not, but in get_dev_info() is that usb variable supposed to be the global one?
[19:15] <OvenWerks> wonko: no
[19:16] <OvenWerks> in get dev info I think it is about if that device is a usb device
[19:16] <wonko> The use of global variable names as local variable names is really, really bad. :(
[19:17] <OvenWerks> I would have to look... but not right now, the friendly mail lady just dropped off a 1394a PCIe board so I am part way through shutting down... back in a bit
[19:17] <wonko> no rush
[19:17] <wonko> just verifying what I was pretty sure I already knew
[19:24] <wonko> Ugh, not I'm not sure if I overwrote local variables or not. I should probably go back and start over. bleh.
[19:36] <wonko> Ok, I'm back to before I started today. And looking at this code again with the new vision of poor variable naming I have to say I'm surprised this shit works at all. :)
 REWRITE ALL THE THINGS! :P
[19:47] <OvenWerks> wonko:  there is that
[19:49] <OvenWerks> wonko one step at a time.
[19:57] <wonko> So, I don't use globals often. If you declare something global in one spot but not about what happens? The one function is using pulse_in etc without declaring it global.
[19:57] <OvenWerks> Ya, There are some things like that which need fixing
[20:00] <OvenWerks> python has this thing where if you read a variable that has not been set in scope it looks in higher scopes. However, if you write to it, it becomes local.
[20:01] <OvenWerks>  Fun, yes?
[20:04] <wonko> Yeah, fun. Totally the word I'd use. 🤣
[20:05] <OvenWerks> In my last pass through things, I did add a number of "global <varname>" lines, but obviously not all. You are fixing this for a large part with config which stores most of the globals anyway.
[20:07] <wonko> Yeah, I just need to make sure I don't use that where it shouldn't be
[20:58] <OvenWerks> So I have three items... at least one of them does not work but I do not know which item it is :P
[21:24] <wonko> Ok, I think I've found all occurences of local variables that shadow globals and have renamed them with a l_ prefix.
[21:24] <wonko> which should keep me from squishing them (which, as it turns out, I totally was)
[21:28] <wonko> OvenWerks: I have a question about this: https://gist.github.com/bhechinger/f8b4468234411fcd6f11ca2c0412561b
[21:28] <wonko> I don't remember seeing that in controls. What really should I be doing here?
[21:30] <wonko> Yeah, checking master, in controls it was this: https://gist.github.com/bhechinger/f13b718aa2057b743b9debfa5a60b59c
[21:30] <wonko> And right there is the danger in having the same code copied all over. :)
[21:52] <OvenWerks> that is an error which should be fixed to read dev = "0,0,0" because it should be a string
[21:52] <wonko> but which is right?
[21:52] <wonko> setting that to 0,0,0 or not?
[21:52] <wonko> because it goes both ways
[21:52] <wonko> controls doesn't change it to 0,0,0 if it's set to default and autojack does
[21:53] <OvenWerks> auto jack has to because it has to be a device we can get from parsing /proc/asound
[21:54] <OvenWerks> controls wants to show "default" to the user... so they know they havn't change it from whatever the value was we tried.
[21:54] <wonko> ah, ok, that makes sense
[21:54] <wonko> thanks
[21:54] <OvenWerks> but in any case they are both strings
[21:54] <wonko> yet another anomaly to deal with. :)
[21:55] <wonko> yeah, that not having quotes was my next question but you already answered that. :)
[21:56] <wonko> Another thing I noticed. In reconfig() there is this:
[21:56] <wonko>         if pulse == "True":
[21:56] <wonko>             connect_pa()
[21:56] <wonko> but pulse won't normally get set to true
[21:56] <OvenWerks> wonko it would be ok to deal with it by using one varialbe for the config value and another for the massaged value or do the change at the point it is used.
[21:56] <wonko> so, uhm, what?
[21:57] <wonko> OvenWerks: I think it makes sense to do like we're doing with zdev. It only matters in the scope of the internals of autojack, so let's do the needful there if we need to.
[21:58] <OvenWerks> pulse should be a string "True" as it is read from the config.
[21:58] <OvenWerks> it is not a bool
[21:58] <wonko> except that is legacy config that shouldn't exist anymore
[21:59] <wonko> that gets converted into PULSE-IN/PULSE-OUT = 0/1
[21:59] <OvenWerks> do we set it close by?
[22:00] <wonko> it's only set if reading in the config sees PULSE, which it turns into those other two and then doesn't write PULSE back out
[22:01] <OvenWerks> that looks like an error
[22:02] <OvenWerks> I assume you mean autojack line 348
[22:02] <wonko> yes
[22:03] <OvenWerks> That will have to be changed... or reused
[22:03] <OvenWerks> I would suggest reusing it
[22:04] <wonko> set it to true if either PULSE-IN or PULSE-OUT aren't 0?
[22:04] <OvenWerks> yes
[22:04] <wonko> ok, i'll tweak that then
[22:05] <OvenWerks> also when we add naming it will have see that neither pulse_in or pulse_out are [].
[22:05] <wonko> right
[22:05] <OvenWerks> which may work out to bool of sorts.
[22:06] <wonko>         if def_config['PULSE-IN'] == "0" && def_config['PULSE-OUT'] == "0":
[22:06] <wonko>             pulse = "False"
[22:07] <wonko> uh, and
[22:07] <wonko> not &&
[22:07] <wonko> :-D
[22:07] <OvenWerks> sure so long as it is already is True
[22:07] <wonko> Yes, true is the default
[22:08] <OvenWerks> That way, only the one call really needs to know what pulse_in/out are.
[22:11] <OvenWerks> I want to change the config call so we only do it once. Is there a way to copy/rename the current config.* to oldconfig.*?
[22:15] <wonko> That should be possible, yes
[22:15] <wonko> but let's not change stuff like that just yet
[22:15] <wonko> because I need to make sure I don't break things as it is. :)
[22:15] <wonko> which isn't easy with this code
[22:15] <OvenWerks> ya :) just thinking out loud
[22:16] <wonko> At this point I can't promise I didn't break anything. ;)
[22:17] <OvenWerks> This is a good time to break things
[22:24] <OvenWerks> I normally start autojack from the commandline and add print() statements in many places to check things are doing what I think they should be when testing.
[22:33] <wonko> Ok, so I think I managed to do this without breaking things. Maybe. :)
[22:33] <wonko> Do you have a set of regression tests you use? Or is it just seat of the pants sort of stuff?
[22:36] <wonko> Ok, well it explodes immediately. I'll fix that. :)
[22:43] <wonko> Ok, explosion fixed
[22:44] <wonko> it doesn't create the pa bridges though
[22:44] <wonko> so that's the next thing to deal with, but that's for tomorrow
[22:44] <wonko> code is checked in if you want to poke at it yourself