[02:37] Eickmeyer: just playing with -installer here. using -s seems to work for me with no other change even for an application I have installed and removed [02:38] not permanently removed (though that works too) [02:38] OvenWerks: Cool. If you think it's solid enough, that works. [02:39] On my end, falktx and I got Carla and all of its subpackages building perfectly. Working on packaging, then off to sponsorship. [02:39] with wine? [02:39] Yep. [02:39] \o/ [02:40] in other news there is now an aes67 ALSA driver available. [02:41] Interesting. I know Midas has AES50, so is this an iteration of that? [02:41] no [02:41] audio over ethernet [02:42] I think it is ip [02:42] AES50 is that, too, just proprietary to Midas/Behringer. [02:42] aes50 is not proprietary if it is aes anything [02:43] but it does not live well with switches so far as I know [02:44] aes67 is similar to avb but one level up and does not require special switches. It can connect to Dante devices with the aes upgrade [02:47] I thought I had the aes50 paper sitting around here but I don't seem to [02:57] Either way, AES67 sounds so much better. [02:57] I have to find out if it gives a udev message [02:59] actually, I pretty much need to have an endpoint to play with to see how the driver behaves [02:59] (two would be better) [02:59] I don't know if the alsa device is available before the user has set it up. [03:01] I think that if the ALSA device is available right away that it should not be opened until it is set up. [03:02] I think once an alsa device has been opened it is not possible to change the number of audio channels it has for example [03:03] if you have two devices the one aes67 device in alsa would be the agrigate of the two phisical devices [03:04] Eickmeyer: anyway, -installer is qued to build. See if you can test it in ways I can't. [03:05] If it doesn't work for you, I will add some debug statements and we can try again. [03:06] I did experience it not working after installing and removing an application and then it did work after the change. [03:06] OvenWerks: I'll try it out. Right now, it seems as if LP's build farm is incredibly backed-up. [03:06] 40 min [03:06] Yeah. I've had Carla sitting on 40 minutes the past two hours. I think something is stuck. [03:07] I was about to say the 40 min does not seem to change [03:07] I thinkt I have done my work for the day... [03:08] Yeah, same. I bet when the Canonical folks wake up and see what's going on there'll be some stuff moving through. [17:16] Ooof... two weeks from Feature Freeze. [17:16] https://wiki.ubuntu.com/DiscoDingo/ReleaseSchedule [20:32] Eickmeyer: just get the packages we have been working on released and that would already be a big step [20:33] Yeah, that's what I'm thinking, but I'm this || close to having Carla ready for Autobuilds. [20:34] Testing Installer as we speak, looking good so far. [20:36] Carla will be 1.9.13 which is 2.0-RC3. He might have an actual release, but he gave himself an end-of-March deadline, so I don't think that's going to make it. [20:37] We might have to keep Patchage with Carla, and have Carla there for testing purposes, with the official 2.0 release in 19.10 replacing Patchage. [20:39] Eickmeyer: we should add Carla to the installer if it is at least in the autobuilds [20:39] I was thinking of the seed along with -audio. [20:40] Eickmeyer: I am thinking we could add a button ti installer that adds/removes the autobuilds ppa [20:42] Not a bad idea, but I think it should be a backports ppa at that point. [20:42] Similar to Kubuntu's backports. [20:42] sure, the actual ppa is not as important, but one that has the "right" name is best ;) [20:43] Yes. Backports is less likely to scare people like our testing ppa "autobuilds" does. It would be as simple as making a separate PPA with manually-triggered recipes. [20:44] right [20:45] By the way, -installer's changes look good per my tests. [20:47] It would be nice if the relogin dialog only showed up when needed [20:48] probably all I need to do is see if the user is in the audio group. [20:54] So, the ppa would be "ppa:ubuntustudio-ppa/backports". [20:54] I'm working on the builds now. [20:55] OvenWerks: Yeah, that's a good idea. [20:55] I guess I need to add an add backports button... [21:01] Right now, I have it for Cosmic and Bionic, and I'll activate for Disco after feature freeze. [21:11] And like that, we have a backports PPA. [21:11] (OMG, what have we done...!) XD [21:20] I could only get the PPA to work for amd64. [21:20] That's frustrating. [21:20] Had i386 checked and everything. [21:24] Eickmeyer: which package? [21:24] All of them. [21:24] do any of them have binaries? [21:24] Nope. [21:25] Thats why [21:25] Ohhhhhh... [21:25] which ppa? [21:25] ubuntustudio-ppa/backports [21:25] I guess if the arch is all, it doesn't matter. [21:26] where do I find that? [21:26] http://launchpad.net/~ubuntustudio-ppa/backports [21:27] Oops, ignore that [21:27] https://launchpad.net/~ubuntustudio-ppa/+archive/ubuntu/backports/ [21:28] I'm hoping that if I, say, backport Carla that the i386 portions would get built since 32-bit VSTs (which are most common) would need the 32-bit bridges, both wine and otherwise. [21:28] Wait and see what the .deb looks like when published [21:28] Right. [21:38] Ya, they say _all.deb [21:38] so good for 32 bit [21:40] (and arm) [21:40] Yay [21:46] OvenWerks: BTW, added Ross to the core team because... well, why the heck wasn't he already??? lol [21:46] no problem. [21:46] So long as he is ok with it. [21:47] I'm sure he will be. If he's not, he can remove himself. [21:47] Just didn't make sense for it to be just you, me, and sakrecoer.