[00:38] I must be odd I have never had the screen blanking fail. But then I don't use the locking part. [00:46] Yeah, it was apparently a problem since several bugs were found and never even acknowleged. Unmaintained code like that, especially when desktop security is involved, is kinda dodgy. [02:39] Eickmeyer: I have my machine set to never go to sleep, blank screen only [02:50] OvenWerks: Mine is a laptop. [14:21] Eickmeyer: With regaurd to the plymouth theme. I don't think it can be in /usr/share/* it has to be in /lib/plymouth? or has this changed? [14:23] usr/share is not a part of initrd so unless plymouth is forced to start after root is mounted it won't work... except it does right now. [14:24] So when did they move that? /usr is not guaranteed to be mounted at boot even. [14:25] (from days of old and small drives) [15:02] * OvenWerks probably doesn't know what he is talking about... [15:42] OvenWerks: Steve Langasek told us not to worry about it, and that he's confident that our grub/plymouth themes simply revealed a bug in livecd-rootfs that needs to be addressed. He has code up for review now: https://code.launchpad.net/~ubuntu-core-dev/livecd-rootfs/+git/livecd-rootfs/+merge/364206 [15:48] OvenWerks: It's /usr/share. If you look at the code for the default Ubuntu theme, that's where it goes. [15:49] Steve said it's completley correct, just the reason it's causing problems is because livecd-rootfs isn't handling it gracefully. [16:24] Eickmeyer: it has changed since 16.04 then. No problem. [16:25] Probably a systemd change [16:26] Something. I honestly don't know, but that's likely since plymouth, systemd, etc. came from Red Hat/Fedora. [20:04] Eickmeyer: I have 18.04, adding backports... install -menu fails because "trying to overwrite '/usr/share/ubuntustudio/applications/hdspmixer.desktop'" - which is also in package ubuntustudio-default-settings 0.65 [20:05] OvenWerks: Eek! Lemme see what needs to happen there. [20:05] I am not sure if that is because I have _settings from auto or not. [20:06] Anyway we should make sure That file is not in both packages. [20:06] Doing that right now, I'll be pinging someone to reupload that. [20:07] Might mean a version bump. [20:07] Well, like I say it may be a mixup in auto which I have now turned off [20:07] It's not in -default-settings, at least not in my local git. [20:08] Right so maybe I have ano old -settings [20:08] Probably. [20:10] OvenWerks: Yeah, not good to mix autobuild and backports. [20:10] backports is a new thing... [20:10] Yeah. Autobuild is for our testing, backports is for users. [20:12] That said, I need to delete everything in backport and rebuild without the date numbers, since we're at a stable build right now in prep for disco. I might have to branch for that purpose since the debhelper version is causing nothing to build. [20:13] That can wait till april [20:14] Yeah. Not urgent. [20:14] Probably the best thing to do is remove everything in there, make a new recipe then build [20:14] Yeah, that's the plan. [20:14] Should I remove everything now, you think? [20:15] Sure. [20:18] I down graded -settings then -menu worked. [20:19] (and settings doesn't even show up) [20:19] Weird. [20:19] Are you pulling settings from autobuild? [20:20] I am pretty sure the -settings I had came from auto which is now truned off [20:20] Ah, that explains it then. [20:21] And the version that was causing problems no longer shows up as available either [20:22] backports should have the same version as a release would have. [20:22] Okay, backports is empty. I'll be working on branching and redoing the recipes. [20:24] That of course means backports should only get built when there is a new version number released. So that the version number is greater than what is in the repos for that cycle. [20:24] Yup, it's all clean [20:25] Yes. Backports is set to only build on command, and I'll be modifying the build recipes to keep them from showing a date in the version. Right now is the perfect time to do it since everything is uploaded to Disco. I'll be making a branch for Cosmic and Bionic to build from since it requires a lower debhelper verison. [20:25] Oh, ok. [20:26] Back later [20:42] Eickmeyer: so B & C will require their own recipe... D will have a new recipe when we actually need it [21:53] OvenWerks: Correct. As it stands, B & C just need a minor modification, D can build from that as well, even though it wouldn't pass the Lintian tests if it were in the actual repo. [22:55] OvenWerks: Backports are all rebuilding with actual release versions. [22:56] I'll just have to merge the master branch into the backport branch for each package every 6 months. [22:56] I'll probably delete Cosmic from the PPA after July. [22:59] Once Disco releases we should change the compat & debhelper back to >=11 so that the autobuilds will start working again, but I want to proceed with caution. [22:59] * Eickmeyer is considering getting calf & lmms pulled from Debian and backported as well [23:23] Cosmic is 18.04? Lots of people will still use that for LTS length. This is very true for those who do Studio over [23:23] Cosmic is 18.10 [23:23] Bionic is 18.04 [23:23] Ah, so you would keep B and loose C, OK [23:23] Yes. [23:24] * OvenWerks needs more sleep... [23:24] OvenWerks: HAHAHAHA! I was just about to ask if you needed more sleep! [23:25] My YF has not been sleeping well at night and has been waking me up to tell me so... frequently [23:25] So it is less of a joke than normal... [23:26] * OvenWerks checks to see what the new PPA does to his system ;) [23:26] Yeah, my YF and I do that but only when one of us is tossing & turning. [23:26] OvenWerks: You might have to do a PPA Purge first, but it won't matter if you have autobuilds. [23:27] The following packages will be upgraded: [23:27] numix-blue-gtk-theme plymouth-theme-ubuntustudio ubuntustudio-look [23:27] ubuntustudio-wallpapers [23:27] Ah, that's because vorlon (Steve) and I had to force a new version number. [23:27] Thats not bad then [23:28] Nah. I would revert the debhelper version in master for all of those packages, but that's not a good idea if we're about to hit beta freeze. [23:28] It seems to be updating with no error anyway. [23:29] Which, I believe, is the 25th. Probably just need minimal changes from here until then. [23:30] * OvenWerks was taking a quick look through Cadence... [23:30] It does not look easy to modify/fix [23:30] Cadence isn't being actively developed right now. [23:31] He's put all of his effort into Carla. [23:31] Eickmeyer: we have for 19.04 what we should have had for 18.04 [23:31] Carla is well worth while [23:31] OvenWerks: This is true. [23:32] I think he is thinking about removing ladish from kxstudio/cadence [23:32] For bit rot [23:32] Yeah. I think he's taking the code and integrating it directly into Claudia. [23:33] But he has that on hold for now. He's been telling people in bug reports that the entire Cadence suite isn't in his sights at this time, but perhaps mid-year he'll look at it again. [23:33] Linux audio is changing, unless someone uses non-stuff jack is not really needed. Plugins have taken over [23:34] Right. Session management has gone into the DAWs themselves for the most part. [23:34] Jack is only needed for those who need more than one audio device or more than one program... [23:35] usb devices are a thing, but multi-applications less so any more [23:35] Right. When I'm doing live production and round-tripping audio through my DAW, I typically also need something to playback spotify or amazon music, which is when I have to use the Pulse bridge, which, unfortunately, introduces latency due to buffer requirements. [23:36] Eickmeyer: if I feel energetic, I may play more with the pulse-jack bridge. [23:37] I think jack should look like a pulse device and use the same kind of code. [23:38] Jack completely taking-over and using Pulse as a device is backwards indeed. [23:38] Of course, then pipewire is supposed to solve everything. /meme [23:38] I think with the right buffering in the bridge, jackd could run at any latency without dragging pulse along for the ride [23:39] pipewire is a long way from there. More likely is pipewire replacing pulse and still needing a bridge for jack. [23:40] Right now, the lowest latency I can get with a USB device and Pulse is about 128/3, and even then get about an xrun/hour. WIthout pulse? 64/3. [23:40] -controls should allow for driver = forewire [23:40] *firewire [23:41] Yeah. I think that's where people have run into issues. [23:41] Unfortunately, I don't have a firewire device to test with, nor do I have a computer with firewire. [23:41] Odd, I can get below that here... but pci device [23:42] Generally the same thing applies for both firewire and USB... use a dedicated card for it. Hard to do with a laptop [23:43] Exactly. All I have are laptops. I have an old Mac Mini that I use as a server, but I'm not about to reformat that to use as a guinea pig. [23:43] * Eickmeyer might be able to repurpose an old MacBook Pro at the end of this month [23:43] But then I still don't have a Firewire audio device. [23:44] It depends where the computer audio world goes in the next while, AVB or aes67 could take over the whole works from USB... [23:45] It would be cheaper to add a better enet chip than just about anything else. [23:45] I can see AES67 being huge. I mean, we can already drive audio over a network with NetJack, but to standardize on AES67 would be awesome. I can even see that taking out Dante. [23:46] the car manufatures seem to be going AVB... that could make HW cheap. [23:46] For Linux both aes67 and avb need the same thing... an intel i210. [23:47] (or the equiv Broadcom that apple uses) [23:48] * OvenWerks wanders off for a nap (feeling old) [23:48] Do it. :)