| OvenWerks | I must be odd I have never had the screen blanking fail. But then I don't use the locking part. | 00:38 |
|---|---|---|
| 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. | 00:46 |
| OvenWerks | Eickmeyer: I have my machine set to never go to sleep, blank screen only | 02:39 |
| Eickmeyer | OvenWerks: Mine is a laptop. | 02:50 |
| 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:21 |
| 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:23 |
| OvenWerks | So when did they move that? /usr is not guaranteed to be mounted at boot even. | 14:24 |
| OvenWerks | (from days of old and small drives) | 14:25 |
| * OvenWerks probably doesn't know what he is talking about... | 15:02 | |
| 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:42 |
| Eickmeyer | OvenWerks: It's /usr/share. If you look at the code for the default Ubuntu theme, that's where it goes. | 15:48 |
| Eickmeyer | Steve said it's completley correct, just the reason it's causing problems is because livecd-rootfs isn't handling it gracefully. | 15:49 |
| OvenWerks | Eickmeyer: it has changed since 16.04 then. No problem. | 16:24 |
| OvenWerks | Probably a systemd change | 16:25 |
| Eickmeyer | Something. I honestly don't know, but that's likely since plymouth, systemd, etc. came from Red Hat/Fedora. | 16:26 |
| 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:04 |
| 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:05 |
| 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:06 |
| 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:07 |
| OvenWerks | Right so maybe I have ano old -settings | 20:08 |
| Eickmeyer | Probably. | 20:08 |
| 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:10 |
| 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:12 |
| OvenWerks | That can wait till april | 20:13 |
| 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:14 |
| OvenWerks | Sure. | 20:15 |
| OvenWerks | I down graded -settings then -menu worked. | 20:18 |
| OvenWerks | (and settings doesn't even show up) | 20:19 |
| Eickmeyer | Weird. | 20:19 |
| Eickmeyer | Are you pulling settings from autobuild? | 20:19 |
| 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:20 |
| OvenWerks | And the version that was causing problems no longer shows up as available either | 20:21 |
| 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:22 |
| 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:24 |
| 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:25 |
| Eickmeyer | Back later | 20:26 |
| OvenWerks | Eickmeyer: so B & C will require their own recipe... D will have a new recipe when we actually need it | 20:42 |
| 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. | 21:53 |
| Eickmeyer | OvenWerks: Backports are all rebuilding with actual release versions. | 22:55 |
| 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:56 |
| 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 | 22:59 | |
| 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:23 |
| * OvenWerks needs more sleep... | 23:24 | |
| Eickmeyer | OvenWerks: HAHAHAHA! I was just about to ask if you needed more sleep! | 23:24 |
| 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:25 |
| * 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:26 |
| 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:27 |
| 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:28 |
| Eickmeyer | Which, I believe, is the 25th. Probably just need minimal changes from here until then. | 23:29 |
| * 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:30 |
| 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:31 |
| 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:32 |
| 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:33 |
| 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:34 |
| 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:35 |
| OvenWerks | Eickmeyer: if I feel energetic, I may play more with the pulse-jack bridge. | 23:36 |
| OvenWerks | I think jack should look like a pulse device and use the same kind of code. | 23:37 |
| 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:38 |
| OvenWerks | pipewire is a long way from there. More likely is pipewire replacing pulse and still needing a bridge for jack. | 23:39 |
| 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:40 |
| 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:41 |
| OvenWerks | Generally the same thing applies for both firewire and USB... use a dedicated card for it. Hard to do with a laptop | 23:42 |
| 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:43 |
| 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:44 |
| 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:45 |
| 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:46 |
| OvenWerks | (or the equiv Broadcom that apple uses) | 23:47 |
| * OvenWerks wanders off for a nap (feeling old) | 23:48 | |
| Eickmeyer | Do it. :) | 23:48 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!