[00:38] <OvenWerks> I must be odd I have never had the screen blanking fail. But then I don't use the locking part.
[00:46] <Eickmeyer> 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] <OvenWerks> Eickmeyer: I have my machine set to never go to sleep, blank screen only
[02:50] <Eickmeyer> OvenWerks: Mine is a laptop.
[14:21] <OvenWerks> 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] <OvenWerks> 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] <OvenWerks> So when did they move that? /usr is not guaranteed to be mounted at boot even.
[14:25] <OvenWerks> (from days of old and small drives)
[15:02]  * OvenWerks probably doesn't know what he is talking about...
[15:42] <Eickmeyer> 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] <Eickmeyer> OvenWerks: It's /usr/share. If you look at the code for the default Ubuntu theme, that's where it goes. 
[15:49] <Eickmeyer> Steve said it's completley correct, just the reason it's causing problems is because livecd-rootfs isn't handling it gracefully.
[16:24] <OvenWerks> Eickmeyer: it has changed since 16.04 then. No problem.
[16:25] <OvenWerks> Probably a systemd change
[16:26] <Eickmeyer> Something. I honestly don't know, but that's likely since plymouth, systemd, etc. came from Red Hat/Fedora.
[20:04] <OvenWerks> 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] <Eickmeyer> OvenWerks: Eek! Lemme see what needs to happen there.
[20:05] <OvenWerks> I am not sure if that is because I have _settings from auto or not.
[20:06] <OvenWerks> Anyway we should make sure That file is not in both packages.
[20:06] <Eickmeyer> Doing that right now, I'll be pinging someone to reupload that.
[20:07] <Eickmeyer> Might mean a version bump.
[20:07] <OvenWerks> Well, like I say it may be a mixup in auto which I have now turned off
[20:07] <Eickmeyer> It's not in -default-settings, at least not in my local git.
[20:08] <OvenWerks> Right so maybe I have ano old -settings
[20:08] <Eickmeyer> Probably.
[20:10] <Eickmeyer> OvenWerks: Yeah, not good to mix autobuild and backports.
[20:10] <OvenWerks> backports is a new thing...
[20:10] <Eickmeyer> Yeah. Autobuild is for our testing, backports is for users.
[20:12] <Eickmeyer> 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] <OvenWerks> That can wait till april
[20:14] <Eickmeyer> Yeah. Not urgent.
[20:14] <OvenWerks> Probably the best thing to do is remove everything in there, make a new recipe then build
[20:14] <Eickmeyer> Yeah, that's the plan.
[20:14] <Eickmeyer> Should I remove everything now, you think?
[20:15] <OvenWerks> Sure.
[20:18] <OvenWerks> I down graded -settings then -menu worked.
[20:19] <OvenWerks> (and settings doesn't even show up)
[20:19] <Eickmeyer> Weird.
[20:19] <Eickmeyer> Are you pulling settings from autobuild?
[20:20] <OvenWerks> I am pretty sure the -settings I had came from auto which is now truned off
[20:20] <Eickmeyer> Ah, that explains it then.
[20:21] <OvenWerks> And the version that was causing problems no longer shows up as available either
[20:22] <OvenWerks> backports should have the same version as a release would have.
[20:22] <Eickmeyer> Okay, backports is empty. I'll be working on branching and redoing the recipes.
[20:24] <OvenWerks> 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] <OvenWerks> Yup, it's all clean
[20:25] <Eickmeyer> 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] <OvenWerks> Oh, ok.
[20:26] <Eickmeyer> Back later
[20:42] <OvenWerks> Eickmeyer: so B & C will require their own recipe... D will have a new recipe when we actually need it
[21:53] <Eickmeyer> 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] <Eickmeyer> OvenWerks: Backports are all rebuilding with actual release versions.
[22:56] <Eickmeyer> I'll just have to merge the master branch into the backport branch for each package every 6 months.
[22:56] <Eickmeyer> I'll probably delete Cosmic from the PPA after July.
[22:59] <Eickmeyer> 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] <OvenWerks> Cosmic is 18.04? Lots of people will still use that for LTS length. This is very true for those who do Studio over <other flavour>
[23:23] <Eickmeyer> Cosmic is 18.10
[23:23] <Eickmeyer> Bionic is 18.04
[23:23] <OvenWerks> Ah, so you would keep B and loose C, OK
[23:23] <Eickmeyer> Yes.
[23:24]  * OvenWerks needs more sleep...
[23:24] <Eickmeyer> OvenWerks: HAHAHAHA! I was just about to ask if you needed more sleep!
[23:25] <OvenWerks> My YF has not been sleeping well at night and has been waking me up to tell me so... frequently
[23:25] <OvenWerks> 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] <Eickmeyer> Yeah, my YF and I do that but only when one of us is tossing & turning.
[23:26] <Eickmeyer> OvenWerks: You might have to do a PPA Purge first, but it won't matter if you have autobuilds.
[23:27] <OvenWerks> The following packages will be upgraded:
[23:27] <OvenWerks>   numix-blue-gtk-theme plymouth-theme-ubuntustudio ubuntustudio-look
[23:27] <OvenWerks>   ubuntustudio-wallpapers
[23:27] <Eickmeyer> Ah, that's because vorlon (Steve) and I had to force a new version number.
[23:27] <OvenWerks> Thats not bad then
[23:28] <Eickmeyer> 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] <OvenWerks> It seems to be updating with no error anyway.
[23:29] <Eickmeyer> 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] <OvenWerks> It does not look easy to modify/fix
[23:30] <Eickmeyer> Cadence isn't being actively developed right now.
[23:31] <Eickmeyer> He's put all of his effort into Carla.
[23:31] <OvenWerks> Eickmeyer: we have for 19.04 what we should have had for 18.04
[23:31] <OvenWerks> Carla is well worth while
[23:31] <Eickmeyer> OvenWerks: This is true.
[23:32] <OvenWerks> I think he is thinking about removing ladish from kxstudio/cadence
[23:32] <OvenWerks> For bit rot
[23:32] <Eickmeyer> Yeah. I think he's taking the code and integrating it directly into Claudia.
[23:33] <Eickmeyer> 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] <OvenWerks> Linux audio is changing, unless someone uses non-stuff jack is not really needed. Plugins have taken over
[23:34] <Eickmeyer> Right. Session management has gone into the DAWs themselves for the most part.
[23:34] <OvenWerks> Jack is only needed for those who need more than one audio device or more than one program... 
[23:35] <OvenWerks> usb devices are a thing, but multi-applications less so any more
[23:35] <Eickmeyer> 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] <OvenWerks> Eickmeyer: if I feel energetic, I may play more with the pulse-jack bridge.
[23:37] <OvenWerks> I think jack should look like a pulse device and use the same kind of code.
[23:38] <Eickmeyer> Jack completely taking-over and using Pulse as a device is backwards indeed.
[23:38] <Eickmeyer> Of course, then pipewire is supposed to solve everything. /meme
[23:38] <OvenWerks> I think with the right buffering in the bridge, jackd could run at any latency without dragging pulse along for the ride
[23:39] <OvenWerks> pipewire is a long way from there. More likely is pipewire replacing pulse and still needing a bridge for jack.
[23:40] <Eickmeyer> 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] <OvenWerks> -controls should allow for driver = forewire
[23:40] <OvenWerks> *firewire
[23:41] <Eickmeyer> Yeah. I think that's where people have run into issues.
[23:41] <Eickmeyer> Unfortunately, I don't have a firewire device to test with, nor do I have a computer with firewire.
[23:41] <OvenWerks> Odd, I can get below that here... but pci device
[23:42] <OvenWerks> Generally the same thing applies for both firewire and USB... use a dedicated card for it. Hard to do with a laptop
[23:43] <Eickmeyer> 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] <Eickmeyer> But then I still don't have a Firewire audio device.
[23:44] <OvenWerks> 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] <OvenWerks> It would be cheaper to add a better enet chip than just about anything else.
[23:45] <Eickmeyer> 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] <OvenWerks> the car manufatures seem to be going AVB... that could make HW cheap.
[23:46] <OvenWerks> For Linux both aes67 and avb need the same thing... an intel i210.
[23:47] <OvenWerks> (or the equiv Broadcom that apple uses)
[23:48]  * OvenWerks wanders off for a nap (feeling old)
[23:48] <Eickmeyer> Do it. :)