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