[17:27] <OvenWerks> krytarik: done. I shold have added to the comment that this fixes lp: #1672412
[17:27] <OvenWerks> Or allows anyway.
[17:28] <OvenWerks> also lp: #1182604
[17:29] <OvenWerks> well not really, it fixes it for us though :)
[17:31] <OvenWerks> krytarik: the whole windows vst (as compared to lxvst) thing is a mess. There are at least 4 kinds of windows vsts floating around that are not mutually compatible
[17:32] <OvenWerks> So far as I know, lmms supports only 32 bit vst2s. The GPLed vst3 headers have just within the past month been released although vst3s have been around for a while.
[17:34] <OvenWerks> there are also 64bit win vsts which will not work already with lmms... I am not sure of the state of wine with 64bit binaries either. I do know some work has been done though.
[17:36] <OvenWerks> krytarik: so the end of this is that lmms at best only supports 1 kind of winvst out of 4. I don't expect lmms to include vst3 or 64bit code real soon now as the lead dev has left and there is some dissarry in the project. I do not think it will die, it seems those left are still well involved, but it may take some time to move forward again.
[17:37] <OvenWerks> there is also the deal of lmms including support for LV2 which I would think is more important right now.
[18:28] <OvenWerks> krytarik: something to look for next cycle is that in debian jack-tools has been renamed to jack-plumbing. Not in ubuntu ... yet, but we would want this package whatever the name.
[19:37] <krytarik> OvenWerks: 1.) Thanks for the commit, let's see if it works.  2.) Thanks for the verbose extra info. :)  3.) I only see an executable called jack-plumbing, in the jack-tools package; and that's at the same version in Debian and Ubuntu.
[19:46] <krytarik> OvenWerks: "I think the meta packages have to be regenerated to go with it" - luckily not in this case.
[19:56] <OvenWerks> cool. I have sent some emails as well, so that others can know why
[20:45] <krytarik> OvenWerks: Well, that didn't work.
[20:46] <OvenWerks> What did it do? I haven't seen failed emails yet.
[20:47] <krytarik> I mean it still pulls the Wine stuff.
[20:47] <OvenWerks> That is normally the effect of not rebuilding the metas
[20:48] <OvenWerks> did it pull in lmms-vst-server?
[20:49] <krytarik> Yes.
[20:49] <OvenWerks> So our understanding of how to do things is flawed.
[20:50] <krytarik> No, just blacklisting more often doesn't work than it does.
[20:53] <krytarik> OvenWerks: So I suggest for now you just ACK the Wine FFe, and then we'll have to see later.
[20:53] <OvenWerks> Hmm, I may have to try a 32 bit install
[20:53] <OvenWerks> Then I can lookup reverse deps
[21:06] <OvenWerks> I did I think
[21:06]  * OvenWerks hopes his comment was clear
[21:07] <OvenWerks> krytarik: maybe if we blacklist wine as well?
[21:07] <OvenWerks> (we may have to blacklist specific wine as well)
[21:09] <OvenWerks> krytarik: after looking at my last few lines of comment :P  I did leave a comment on https://bugs.launchpad.net/ubuntu/+source/wine-development/+bug/1672412
[21:16] <krytarik> OvenWerks: Yes, figured I'll just reload the bug report page and see if you added one there. :P  Also, one thing we could still try is to blacklist it the way Kubuntu did it just recently: http://bazaar.launchpad.net/~kubuntu-dev/ubuntu-seeds/kubuntu.zesty/revision/1358 - and in that context, we might blacklist that one right away too, even though the package doesn't exist in the repos ...
[21:16] <krytarik> ... yet.
[21:16] <krytarik> lol
[21:18] <OvenWerks> krytarik: I can do that, but I am pretty sure it would require a meta rebuild to work.
[21:19] <krytarik> Nope, that one neither.
[21:22] <OvenWerks> I am guessing it needs to come before lmms itself
[21:23] <OvenWerks> So the two lines are:
[21:23] <OvenWerks>  * !lmms-vst-server
[21:23] <OvenWerks>  * (lmms)
[21:24] <krytarik> Yup, that's sensible.
[21:25] <OvenWerks> commited please check
[21:27] <OvenWerks> http://bazaar.launchpad.net/~ubuntustudio-dev/ubuntu-seeds/ubuntustudio.zesty/revision/1506
[21:29] <OvenWerks> krytarik: if that doesn't work we will put it just after. I am not sure of the logic, but programacically it would be easier to remove a program from the list after it has been added rather than saving the name to check each new adition against...
[21:33] <OvenWerks> krytarik: the network-manager-config-connectivity package is troublesome also because low latency audio operation is sensitive to network activity.
[21:35] <krytarik> Well, following the 'above' logic, you should have done the same for the NM one too - but as I was about to say, I'd have to look at the code of germinate again to confirm either way.
[21:36] <krytarik> Ah, good to know.
[23:23] <krytarik> OvenWerks: So looks like it doesn't really matter in what order they are - https://git.launchpad.net/germinate/tree/germinate/germinator.py   Also, I'd suggest we do a respin now, since it's RC day.