[00:32] <OvenWerks> Bug #1872250
[00:34] <OvenWerks> Eickmeyer: fix commited (like the rest of us?)
 is a fix committed for that OvenWerks?
[00:41] <OvenWerks> uploaded two minutes ago
[00:42] <OvenWerks> Maybe 8?
[00:43] <OvenWerks> change log needs to quick massage
[00:43] <OvenWerks> From unreleased to whatever and bump the version.
[00:44]  * OvenWerks wanders off to fix the next bug on the list (Ardour this time)
[00:50] <Eickmeyer> OvenWerks: Ok, I'll upload.
[01:03] <Eickmeyer> OvenWerks: Uploaded, version bumped to 1.12.4, targeted focal. Changes good on the github verison too?
[01:14] <Eickmeyer> OvenWerks: Nevermind, found out for myself.
[15:50] <Eickmeyer> Ok team. Final Freeze is Thursday. Here's the uploads in the queue that we're waiting on: darktable 3.0.1, carla 2.1 (final), and ubuntustudio-installer 0.08 (typo fix).
[15:51] <Eickmeyer> Getting the release team to simply ack these has been like talking to a brick wall. I'm getting nervous and frustrated, not gonna lie.
[16:11] <OvenWerks> LTS blues?
[16:12] <OvenWerks> so far 20.04 is a good release.... 18.04 I was ready to give up pretty much
[16:12] <Eickmeyer> I feel like we can't get rid of 18.04 fast enough.
[16:15] <OvenWerks> backports has also come a long way
[16:15] <OvenWerks> there has not been abackports since before I started
[16:16] <OvenWerks> (thankyou for fixing my typos)
[16:16] <Eickmeyer> Heh, you're welcome. Wasn't hard, just glad somebody saw it.
[16:16] <Eickmeyer> The other part of that bug is something we can't do anything about without a rewrite.
[16:18]  * OvenWerks didn't read the whole bug
[16:18] <OvenWerks> what was the other part?]
[16:18] <OvenWerks> (or a link)
[16:18] <Eickmeyer> bug 1872386
[16:22] <OvenWerks> To me the real bug is that the reboot message should not appear if it is not needed. The code in -controls should be used to check if the user has the access needed. I think if autojack is running that is probably enough even (maybe not)
[16:24] <Eickmeyer> Agreed, but in this case, the person who filed it was running Ubuntu (proper), so they were using GNOME.
[16:24] <Eickmeyer> So the message would pertain to them.
[16:24] <Eickmeyer> The scenario you brought up is if someone is already running Studio.
[16:24] <OvenWerks> yup.
[16:25] <OvenWerks> personally, for such a message, a "jarring" font and box is a good thing :)
[16:25] <Eickmeyer> Ha! Agreed.
[16:25] <Eickmeyer> Gets your attention, even if ugly.
[16:28] <OvenWerks> we could put a systemd service that removes a file that installer has created on shutdown so the next time installer runs it does not use that
[16:28] <OvenWerks> other way around
[16:28] <OvenWerks> renames a file?
[16:30] <OvenWerks> installer goes touch needs-reboot, systemd goes mv needs-reboot rebooted
[16:30] <Eickmeyer> That could work, at least in theory.
[16:30] <Eickmeyer> Or it could check to see if the current user is in @audio, which I believe is the goal anyhow.
[16:30] <OvenWerks> The only time a reboot is needed is first time run and after kernel install
[16:31] <OvenWerks> and to see if they have rt access
[16:32]  * OvenWerks thinks if there is anything else
[16:32] <OvenWerks> I guess most people will start it once choose what they want and never start it again
[16:33] <OvenWerks> when I was testing it, I was installing one bundle (get warning) then installing another bundle (another warning) etc.
[16:33] <OvenWerks> so my experience was atypical
[16:33] <OvenWerks> so leave it in there
[16:34] <Eickmeyer> Yeah. Besides that, we don't have the Ubiquity plugin anymore, so its point for Studio users is moot. It's basically strictly for adding Studio to another flavor now.
[16:35] <OvenWerks> Is thath how it was fixed?
[16:35] <OvenWerks>  :)
[16:35] <OvenWerks> some people won't like that
[16:35] <Eickmeyer> Yep. Turns out the Ubiquity plugin couldn't be maintained anymore. It was forked from an Edubuntu plugin, and we know what happened there.
[16:36] <Eickmeyer> Well, we can't do much about that. It was utterly broken.
[16:37] <OvenWerks> So things on my todo list:
[16:38] <OvenWerks> Ardour bugs/feature requests (OSC and foldback)
[16:38] <OvenWerks> kbmidi add ALSA
[16:38] <Eickmeyer> Fun. Mine is to pester the release team.
[16:39] <OvenWerks> idjc update
[16:39] <OvenWerks> -controls... stuff
[16:40] <Eickmeyer> Did they actually port idjc to Python3, or are you doing that yourself?
[16:40] <OvenWerks> I have not found anything for that
[16:40] <Eickmeyer> I haven't either.
[16:41] <OvenWerks> there are 2019 commits though
[16:41] <OvenWerks> so it is not dead
[16:42] <Eickmeyer> No, just not Python2 alive.
[16:42] <Eickmeyer> For all intents and purposes, anything still using Python2 at this point is dead.
[16:42] <OvenWerks> Yeah, but the author may (depending on which OS they use) update that for personal reasons
[16:43] <Eickmeyer> That means it can't be in Arch, Ubuntu, Debian, or Fedora at minimum. openSUSE might be in that too.
[16:44] <OvenWerks> I also have the repo for jack-mixer but I think rather than bringing that back to life, a new non-mixer like unit that uses LV2 might be better
[16:45] <OvenWerks> I would really like to add LV2 plugin hosting to the jackd ALSA back end
[16:45] <Eickmeyer> That would be nice. Though, some plugins have standalone binaries, like lsp-plugins.
[16:46] <OvenWerks> there would be no support for GUIs
[16:46] <OvenWerks> the plugins would have to be OSC or MIDI controled
[16:48] <OvenWerks> My purpose is not to add _any_ plugin but to be able to add an output volume control that can be controlled by the systray
[16:48] <OvenWerks> I may be better off just adding a level control and leaving it at that
[16:50] <OvenWerks> honestly, I would like to change the way jack works. The backend would be the dummy backend... any device would become a client.
[16:51] <OvenWerks> the backend is able to sync to one device client and to route i/o to that client
[16:51] <Eickmeyer> Just like zita-ajbridge.
[16:51] <OvenWerks> we could do that now
[16:52] <OvenWerks> but I want the dummy i/o to reflect the synced device client
[16:53] <OvenWerks> the user would be able to set up an i/o map so that (for example) dummy output 1&2 would be device output 9&10
[16:54] <Eickmeyer> Interesting concept.
[16:54] <OvenWerks> I do not know if the dummy back end would self sync to a zit-ajbridge that was set to hard sync or not
[16:54] <OvenWerks> I don't think so
[16:55] <Eickmeyer> The way it functions now? not likely.
[16:55] <OvenWerks> dummy gets sync from the CPU right now.
[16:56] <OvenWerks> I would like to see a system wide media clock
[16:57] <Eickmeyer> That would be nice, could be integrated into the transport.
[16:57] <OvenWerks> it would be able to be synced from: CPU, Network (AVB, Dante, AES67), any audio device
[16:58] <OvenWerks> The jackd dummy back end would sync from that
[16:58] <Eickmeyer> Dante support for Linux. There's something that would be nice.
[16:58] <OvenWerks> Dante uses the same meadia clocking as AES67 and AVB
[16:59] <OvenWerks> *media even
[17:00] <OvenWerks> So it is possible to set up AES67 that syncs to a Dante network and have that dante network talk to the AES67 linux endpoint... though near as controlable
[17:01] <OvenWerks> I don't know if a wine app could do the discovery and control part or not.
[17:03] <OvenWerks> I do think networked audio will trickle down to consumer levels in the next years.
[17:03] <OvenWerks> I think that probably AVB will be the one that does so first
[17:04]  * OvenWerks wanders off to breakfast with wife
[17:09] <Eickmeyer> Have a good breakfast.
[17:15] <Eickmeyer> Darktable is accepted. One down, two to go.
[17:38] <Eickmeyer> Carla is all that's left now.
[22:43] <OvenWerks> Eickmeyer: This throws a wrench in things... https://discourse.ardour.org/t/a-eq-and-a-comp-fail-on-manjaro-xfce/103122
[22:44] <OvenWerks> I just checked and yes this affects our Ardour package
[22:50] <OvenWerks> it will take at least a release note.
[22:50] <OvenWerks> The fix may be to import this directory: https://github.com/Ardour/ardour/tree/master/libs/plugins
[22:51] <OvenWerks>  I don't know if just cherry picking: https://github.com/Ardour/ardour/commit/3df530e7f6521a74d5184c6de04589cd762c5f12
[22:51] <OvenWerks> would do it.
[22:52] <OvenWerks> This has to do with the c compiler version in 18.04
[22:59] <OvenWerks> I notice that a-delay, and a-reverb are not a part of this fix and they don't work either
[23:13] <OvenWerks> Eickmeyer: I can confirm that https://nightly.ardour.org/ 64bit, optimized, free/demo, gcc5
[23:14] <OvenWerks> when installed then cp -r /opt/Ardour-6.0.pre1.294/lib/LV2/* /usr/lib/ardour5/LV2/
[23:14] <OvenWerks> does make them work.
[23:16] <Eickmeyer[m]> File a bug report, we might be able to upload. teward, might need upload powers.
[23:18] <Eickmeyer[m]> ERR:GroceryShopping
[23:21] <OvenWerks> right. rg says we should be able to just recompile
[23:22] <OvenWerks> as in when was the Ardour package last compiled?
[23:22] <OvenWerks> as compared to  the 2.31 version of the GNU C Library
[23:27] <OvenWerks> when you get home... is it possible to rebuild Ardour in our dayly or whatvere to see if that makes work ok?
[23:27] <OvenWerks> https://bugs.launchpad.net/ubuntu/+source/ardour/+bug/1872555
[23:46] <OvenWerks> Says it was built Mon, 23 Mar 2020 07:09:56 +0100
[23:47] <OvenWerks> the reason for build was: * No-change rebuild for libgcc-s1 package name change.
[23:48] <OvenWerks> I would think that should cover it... 
[23:52] <OvenWerks> nope, * GCC snapshot, taken from the trunk (20200411, f883c46b487). Matthias Klose <doko@ubuntu.com>  Sat, 11 Apr 2020 15:58:53 +0200
[23:53] <OvenWerks> This is from the changes list on the installed package. So maybe just a rebuild will work.
[23:58] <OvenWerks> added a comment to the bug report to this effect
[23:59] <OvenWerks> Eickmeyer: you may wish to boost the importance on the bug. I can't