[06:00] <OvenWerks> Eickmeyer: was just wondering if you had repacked mcpdisp so I can test it. before releasing it. (built from latest git)
[06:00] <OvenWerks> The big change is making it -o0 :)
[06:01] <OvenWerks> The rest is spelling kinds of things.
[06:01] <Eickmeyer> OvenWerks: I packaged it, but the version I have is kinda not working, and I haven't rebuilt it since. Do you have a new release?
[06:02] <OvenWerks> I want to make sure it works when packaged before I mark a release
[06:03] <Eickmeyer> Ok, I'll see if I can do a git pull and push that in, but I probably won't get to it until tomorow.
[06:03] <OvenWerks> no problem
[06:07] <OvenWerks> the problem was getting it to build while packaging... worked fine otherwise
[06:19] <Eickmeyer> Right. That's why I did it via my PPA before.
[06:22] <OvenWerks> evrything is 0.1.2 except the tag.
[06:36] <Eickmeyer> Ok. I'll do it in the morning. Headed to bed now.
[06:50] <OvenWerks> gn
[17:21] <Eickmeyer> OvenWerks: Here's my build of mcpdsp: https://launchpad.net/~eeickmeyer/+archive/ubuntu/ppa/+build/19533996/+files/mcpdisp_0.1.1+git20200621-0ubuntu1_amd64.deb
[17:21] <Eickmeyer> Give it a whirl.
[18:56] <OvenWerks> Thankyou lets see if I can do this by remote :P
[19:02] <OvenWerks> Eickmeyer: that looks old
[19:02] <OvenWerks> Say june 21
[19:04] <OvenWerks> ok build log looks right though
[19:09] <OvenWerks> Ok, that loads and runs
[19:09] <OvenWerks> so setting -O0 worked
[19:11] <OvenWerks> That probably means in the long run I need to explicitly manage memory differently because something in -O1 is trying to put all my buffers (well some the ring buffer will be right) on the stack
[19:14] <OvenWerks> firefox seems to explicity open nauty-lis instead of the DE default file manager. There are so many things one cannot do with naughty-lis that Thunar can do... like open remote locations (at least it is hard to find)
[19:15] <OvenWerks> one more test to do.
[19:19] <OvenWerks> Ok, it does actually display the info when hooked up to Ardour :)
[19:21] <OvenWerks> Eickmeyer: So if I tag it as a 0.1.2 release will that work for packaging? is there anything else I need to do?
[19:22]  * OvenWerks hates "naughty loss of functionality"
[19:31] <OvenWerks> Looks pretty good: https://i.imgur.com/KenRrmX.png
[19:33] <OvenWerks> somethings not right -V still shows 0.1.0
[20:27] <Eickmeyer> OvenWerks: If you tag for 0.1.2, it has very little impact on packaging except the version number that gets submitted at this point.
[20:28] <Eickmeyer> And if -V is wrong, it's a good thing you *haven't* done that. :D
[20:31] <OvenWerks> except the -V, -h show the right version on a self build
[20:39] <OvenWerks> also looking at the build log: Project version: 0.1.2 and: -DVERSION="0.1.2"... let me try downloading the file again.
[20:50] <OvenWerks> Eickmeyer: I do not know how the Version 0.1.0 ends up in the package. The build log shows 0.1.2, the build from the same package shows right version here.
[20:51] <OvenWerks> The file name for the resulting package does not look like today however.
[22:07] <Eickmeyer> OvenWerks: So, the version number I used is 0.1.1+git20200621: the date of the commit.
[22:07] <OvenWerks> right.
[22:07] <Eickmeyer> That's all I saw. I didn't see any newer commits.
[22:07] <OvenWerks> Eickmeyer: I did remove the Makefile which should not be needed/used
[22:08] <Eickmeyer> Yes, if it's a meson build. Debhelper is smart enough to figure out how to build with what the package build deps are.
[22:09] <OvenWerks> the makefile was left over from before meson, I thought I had removed it already.
[22:09] <Eickmeyer> It probably wasn't being used anyhow.
[22:10] <OvenWerks> doing a grep 0.1.0 * shows nothing.
[22:10] <Eickmeyer> Weird.
[22:11] <OvenWerks> so anyway, I am going to tag a release (bug fix)
[22:11] <Eickmeyer> Ok
[22:11] <OvenWerks> The main thing is that it runs
[22:11] <OvenWerks> maybe I would be better calling it 0.2.0?
[22:12] <OvenWerks> but really it is a bugfix for 0.1.0
[22:13] <OvenWerks> so 0.1.2 is correct
[22:22] <OvenWerks> Eickmeyer: here it is: https://github.com/ovenwerks/mcpdisp/releases/tag/mcpdisp-0.1.2
[22:23] <Eickmeyer> OvenWerks: Ok.
[22:49] <Eickmeyer> OvenWerks: So, I'm trying to test it, but I'm in a pickle: I can't get studio controls to start Jack.
[22:53] <OvenWerks> Latest from cit?
[22:53] <OvenWerks> git
[22:53] <Eickmeyer> Yep.
[22:53] <OvenWerks> yes
[22:54] <OvenWerks> known problem
[22:54] <Eickmeyer> Oh?
[22:54] <OvenWerks> fixed here already
[22:54] <OvenWerks> git was not ready for use, but needed to be made so I could have a full install
[22:55] <OvenWerks> (on 18.04
[22:55] <Eickmeyer> Oh, I see. Yeah, I yeeted it into Groovy. My bad.
[22:56] <OvenWerks> I can push to working (still not ready)
[22:56] <Eickmeyer> Of course. "1.99.x" implies not ready until 2.0.
[22:57] <Eickmeyer> Not much of a matter anyhow. I used qjackctl to test.
[23:54] <OvenWerks> found out why -V might be 0.1.0... it seems there is an old copy in /usr/local/bin
[23:56] <OvenWerks> when I run the one in /usr/bin/ everything works
[23:58] <OvenWerks> fixed