[06:00] Eickmeyer: was just wondering if you had repacked mcpdisp so I can test it. before releasing it. (built from latest git) [06:00] The big change is making it -o0 :) [06:01] The rest is spelling kinds of things. [06:01] 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] I want to make sure it works when packaged before I mark a release [06:03] 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] no problem [06:07] the problem was getting it to build while packaging... worked fine otherwise [06:19] Right. That's why I did it via my PPA before. [06:22] evrything is 0.1.2 except the tag. [06:36] Ok. I'll do it in the morning. Headed to bed now. [06:50] gn === meetingology` is now known as meetingology [17:21] 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] Give it a whirl. [18:56] Thankyou lets see if I can do this by remote :P [19:02] Eickmeyer: that looks old [19:02] Say june 21 [19:04] ok build log looks right though [19:09] Ok, that loads and runs [19:09] so setting -O0 worked [19:11] 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] 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] one more test to do. [19:19] Ok, it does actually display the info when hooked up to Ardour :) [19:21] 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] Looks pretty good: https://i.imgur.com/KenRrmX.png [19:33] somethings not right -V still shows 0.1.0 [20:27] 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] And if -V is wrong, it's a good thing you *haven't* done that. :D [20:31] except the -V, -h show the right version on a self build [20:39] 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] 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] The file name for the resulting package does not look like today however. [22:07] OvenWerks: So, the version number I used is 0.1.1+git20200621: the date of the commit. [22:07] right. [22:07] That's all I saw. I didn't see any newer commits. [22:07] Eickmeyer: I did remove the Makefile which should not be needed/used [22:08] 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] the makefile was left over from before meson, I thought I had removed it already. [22:09] It probably wasn't being used anyhow. [22:10] doing a grep 0.1.0 * shows nothing. [22:10] Weird. [22:11] so anyway, I am going to tag a release (bug fix) [22:11] Ok [22:11] The main thing is that it runs [22:11] maybe I would be better calling it 0.2.0? [22:12] but really it is a bugfix for 0.1.0 [22:13] so 0.1.2 is correct [22:22] Eickmeyer: here it is: https://github.com/ovenwerks/mcpdisp/releases/tag/mcpdisp-0.1.2 [22:23] OvenWerks: Ok. [22:49] 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] Latest from cit? [22:53] git [22:53] Yep. [22:53] yes [22:54] known problem [22:54] Oh? [22:54] fixed here already [22:54] git was not ready for use, but needed to be made so I could have a full install [22:55] (on 18.04 [22:55] Oh, I see. Yeah, I yeeted it into Groovy. My bad. [22:56] I can push to working (still not ready) [22:56] Of course. "1.99.x" implies not ready until 2.0. [22:57] Not much of a matter anyhow. I used qjackctl to test. [23:54] found out why -V might be 0.1.0... it seems there is an old copy in /usr/local/bin [23:56] when I run the one in /usr/bin/ everything works [23:58] fixed