[00:00] It may not work with a generic thrown in [00:01] 28% :( [00:02] I don't know how far to go with setting up this 19.10 partition to my liking. It will probably get over written [00:05] I never keep my test partitions around for long. [00:06] Ya, but I kept typing in the wrong terminal because.... focus follows mouse= off [00:06] * OvenWerks wonders how anyone could work like that [00:09] Eickmeyer: is there a known bug for the power manager showing up (battery icon in the panel) on a non-battery system? [00:09] OvenWerks: I don't think that's a bug, I think it's just the default icon, but I don't know. bluesabre^ [00:09] I am not sure I like the network Icon. [00:10] it looks too much like firefox pocket [00:10] as in not very obvious what it is. [00:11] I'll look when I get back to 18.04 not worried till then [00:15] when I first opened patchage everything was dancing :) [00:16] The network icon looks like a network connector to me. [00:16] Wireless looks like a wireless cone. [00:17] I don't see Firefox Pocket in that at all. [00:17] I don't have that (or wireless) [00:17] once I know what it is, it stops mattering anyway. [00:17] Bear in mind, this is Xfce 4.14-pre1, so there are bugs. [00:18] Icon theming hasn't changed from 19.04, FYI. [00:19] I don't have 1904 [00:22] Ah, patchage was set to "sprung layout" I couldn't move anything without it bouncing back to where it came from. [00:22] Must be the default? [00:23] I guess. [00:23] I use Carla for all of that functionality anyhow. [00:23] bad default IMO, if it decides to put things inthe wrong place, everything bounces all over [00:24] I agree. I'm not a fan of Patchage. A lot of people love it, though. [00:24] qjackctl has a similar screen now. [00:25] Not the version we carry, which is sadly out of date. [00:29] aeolus could use a nicer icon. I think it is using the alsa one now. [00:29] zyn should be moved to a submenu [00:30] (instruments) [00:30] I agree with that. aeolus appears to be using some sort of a default icon. [00:30] zyn should have the new gui too but I guess not in debian yet? [00:31] It's not in Debian yet. Also a complete pain to get to work. Reminded me of the NON-tools with getting it to work. [00:31] We should at least hide the OSS version. [00:33] audio-x-generic for aeolus icon [00:36] Just made the change in -default-settings to hide the OSS version. [00:36] (not pushed) [00:41] OvenWerks: I am witing for teward to sponsor raysession before dropping LADI. [00:41] OK. I don't really care one way or tuther [00:42] but it makes sense [01:02] * OvenWerks workflow seems not to be normal [01:31] So far so good. two lowlatency kernels work fine [01:32] DL generic now [01:35] coo [01:39] two steps forward and one step back or something. [01:40] The main grub menu now displays two entries with correct labels, one lowlatency and the second generic... [01:41] the sub menu displays the old lowlatency at the bottom (two entries) good [01:41] Oof [01:41] above that I have three double entries but all for the latest lowlatency and none for the generic [01:42] Okay, well, that's at least correctible. [01:42] yes. [01:42] at least the main menu works as expected [01:45] Cool. [01:50] Eickmeyer: unlikely to be tonight [01:50] got home and was beat instantly [01:50] phone's repaired tho :p [01:50] but err:deadtired [01:50] teward: No worries. Thanks for the willingness. [04:40] Eickmeyer: pushed change to default settings, I am guessing it will create a number of packages, but the grub one needs testing [04:42] It needs testing with generic only... in xubuntu? lowlatency only, and of course both [04:42] Look for duplicate entries for the same kernel :) [04:45] I have to download some ISOs I guess. I will test on a Studio ISO and maybe a kubuntu ISO [05:03] new build queued [05:04] Eickmeyer: I would not suggest the lowlatency-settings be backported. I built it around the 1910 version of grub [05:07] It may be possible to backport via a git branch by using a diff, But I have noticed that some of the variable names have changed as well, so the diff will not just fit, it would need rewarping to work... it is of course possible the file would just work as is... [05:08] Studio ISO at 67% and kubuntu at 35.6% [05:08] off to bed I think [14:06] Both my ISO DL failed :( I guess a new ISO got rolled or something [16:04] OvenWerks: The old version of the lowlatency settings probably hadn't been edited since 16.04 or prior, so I'm willing to bet whatever you did will work when backported. [16:39] Eickmeyer: ubuntustudio-lowlatency-settings conflicts with -default-settings [16:40] OvenWerks: -default-settings provides -lowlatency-settings, so it's not a conflicts so much as it is -lowlatency-settings isn't necessary if -default-settings is installed. [16:40] Eickmeyer: I think it would be better for -default-settings to depend on -lowlatency-settings [16:40] Let me see what I can do. [16:41] I understand that, but that means both packages have to have the same install. [16:41] I guess changing -default-settings might cause trouble at this point? [16:43] Nah, it should be fine. Seems as if apt knows that the files come from the same place. [16:43] when I tried to install lowlatency, dpkg said it conflicted but not that default-settings provides [16:43] If I move lowlatency-settings from a provides to a recommends, that should solve a few things. [16:43] er, to a depends. [16:44] So anyway, I will just change the settings install. and we can leave it alone [16:44] Well, -performance-tweaks is set-up the same way (this was early when I was figuring out packaging). [16:45] Eickmeyer: if we want them truely separate, we can change the install for default settings to install /etc/sub directories rather than /etc like now [16:45] Yeah, that's what I'm working on. Then make them both deps. [16:45] ok [16:46] don't build yet though [16:47] I would like to try things as is in kubuntu first [16:49] Actually it might not matter, that shouldn't change lowlatency-settings [16:49] Right. [16:49] grub-emu [16:49] focus doesn't follow my mouse :P [16:53] * OvenWerks reboots... again [16:56] Eickmeyer: which package do we file a bug against for no prompt to remove install media? [16:57] (the new grub looks good BTW, just need to make it install correctly) [16:57] OvenWerks: I honestly don't know, probably livecd-rootfs, but I'd want to make sure the bug exists in other flavors first. [16:58] ok [16:59] Interesting, double click on a disk icon doesn't seem to mount it. selecting it in thunar works fine. [16:59] Remember, you're looking at xfce 4.14-pre1, so it's not done yet. [17:00] No worries, I normally have those set to not display, so I don't even know if that is normal :) [17:06] hmm, maybe I single or right clicked, worked the next time [17:10] OvenWerks: Just pushed my changes to ubuntustudio-default-settings [17:10] Really, just messed with the way it's packaged and installed. [17:12] ok [17:15] reboot... [17:23] installing kubuntu [17:24] The installer seems more inteligent [17:24] It didn't try to resize the partition to the same size like ours did [17:25] That's strange because it's just the qt version of ubiquity. [17:26] Unless they changed to Calamares. [17:26] We need an additional module before we can go to Calamares, which is why I haven't touched it. [17:33] Oof... experiencing major failure-to-boot issues with kernel 5.2 [17:40] Huh, lowlatency-settings depends on linux-lowlatency [17:41] Well, yeah. What's the point in installing it unless you have the lowlatency kernel installed? [17:42] I guess that is ok, it just won't allow me to test no lowlatency operation, but if it depends on lowlatency, I guess it doesn't matter [17:43] Interesting. Kernel 5.2 (in eoan) breaks amdgpu.dc. [17:43] not nice. [17:44] Yeah. Had to set my kernel parameters to disable it. [17:48] konsole seems to be "fixed", when I resize one terminal it does apply to the next one I open. (good) [17:48] Maybe the defaults are just better [17:49] we will see when I close this window (which is 40 lines rather than 25) [18:00] Somebody filed a bug against all of Ubuntu Studio when it was clear the issue was initramfs-tools, and that they probably screwed-up their config somehow. [18:03] filing a bug is confusing at the best of times [18:04] There is no gui for ubuntu-bug... and even if there was, how does one know which package to blame [18:05] Then if someone installs sw from our backport ppa, ubuntu-bug won't work anyway. [18:07] This is true, but we have bug reports enabled for the backport ppa. [18:08] For the? or for our? That is I think there is an "official" backports PPA too? [18:08] Also, it may have been auto I tried on. [18:09] Anyway, my install strategy for grub seems to have worked. [18:10] My only thing is that probably I should be forcing a update-grub as well [18:10] back to 1804... [18:15] Cool. [18:15] OvenWerks: Today was 18.10's EOL, I just removed all 18.10 packages from the backports PPA. [18:15] Autobuild will be next. [18:22] And done. Cosmic is now dead. [18:24] left at light speed... [18:32] dpf-plugins is now in Eoan, adding to our seed. [19:06] OvenWerks: Did you say that you're comfortable with releasing the changes you made for grub? [19:11] I need to look at what changes you have made first [19:11] lowlatency-settings is fine though, it is just defaultsettings [19:12] All I did was change -default-settings to only install everything -lowlatency-settings and -performance-tweaks doesn't install, but to depend on them both. [19:14] Meaning that -default-settings does nothing different in terms of what it installs because it needs what the others have. [19:14] the default-settings.postinstall now needs to be moved to lowlatency-settings [19:14] I'll do that next [19:15] Oh, I just did it. Simple copy/paste. [19:15] Unless you have a better way. [19:15] * Eickmeyer leaves it alone [19:17] Copy and paste yes... The part that is already in lowlatency.postinstall should come first, followed by the part from default... [19:17] Thought so, but I'll let you make the changes and I'll just pull. [19:17] Let me know when you've pushed so I can pull. I'd like to get this stuff in eoan. [19:18] Yes, will do [19:19] I don't think we need a default-settings.postinstall now. [19:19] Well, considering it would be nothing but comments, that's correct. [19:23] there it be [19:24] building [19:27] Pulled [19:27] I'll wait for the autobuild to finish and update from that to test it myself before getting it all into eoan. [19:28] thank you [20:12] cfdisk [20:14] cfdisk? [20:15] OvenWerks: Confirmed, the fixes you made to the grub menu work. I'll go ahead and push this to eoan, if you feel it's ready. [20:15] yup [20:22] Done [20:27] What we have in Eoan, I'd say, is very close to what we'll ship. [20:28] I just want raysession in and ladish out. [20:28] I saw objections to raysession in #lad, but idc that much. [20:37] Eickmeyer: don't worry about that. [20:37] I just thought if nsm could be built with fltk, that may get it into debian [20:37] ntk is built off of fltk [20:39] falktx assertion that nsm only needs to work with jack makes sense but may not be correct. [20:41] more audio programs use alsa dirrectly. If one adds some sort of control aplications along side, nsm could still be useful... maybe. [20:42] however, he is right that many desktops now have their own session management [20:42] So we may see a session manager built into jack/carla [20:55] That would be nice. [20:55] But the raysession+carla option meets all of the sweet spots anyhow. [21:02] OvenWerks: Do you feel like -controls is where it's going to be for release, or do you have more tweaking to do? [21:05] I think for this release it is good. [21:06] Anything I might like to work on would be major. [21:06] Some things I would like to see: [21:06] better help [21:07] -zita calls checking the device and selecting closest available SR [21:09] setting piority. [21:11] Tabblet stuff... wait and see if the DEs do more with that [21:11] Ok, any of that you think could make it into 19.10? [21:14] Not at this point. I am happy with what it is. bugs I would like to know about :) [21:14] feature requests that are small [21:15] Ok. I'll get this uploaded then. [21:15] I thought -controls was already uploaded? [21:16] Not your latest changes as I look at it. [21:17] Such as input only, backends only getting parameters they can handle, setting i/o channel count, subprocesses from strings to array... [21:18] OK [21:21] OvenWerks: How about installer? [21:23] I shall look to see if back to main page is possible/practical [21:23] One idea I had was including ppa-purge which will completely remove the backports PPA and downgrade the packages instead of simply removing the PPA. [21:24] OvenWerks: What do you think about that idea (I could implement it myself)? [21:26] That would be fine, it is the way it is because those were the commands I knew about. [21:27] Cool. [21:29] I think return to list page is doable. [21:29] There is a call that populates it. [21:31] Cool. Unrelated: I'm pushing the ppa-purge change. [21:34] I'll pull when you are done [21:38] OvenWerks: I noticed that the script doesn't apt-get full-upgrade, when you add the PPA. Should we add that as well? [21:39] whats full-upgrade [21:39] full-upgrade upgrades packages and removes any conflicts as well. [21:40] none of the PPA instructions suggest that [21:40] or does that install stuff? [21:41] So, for instance, calf 0.90.2 conflicts with calf-ladspa. However, 0.60 (in bionic) does not. So, when upgrading with a simple "apt upgrade", it would hold-back from upgrading. With "apt full-upgrade" it would remove calf-ladspa while upgrading calf to 0.90.2. [21:42] Ya, but we don't do an upgrade even, do we? [21:42] should be an update if anything [21:42] No, we don't, but we should. Update just updates the repo lists, it doesn't actually switch to the packages in the PPA. [21:42] The idea of a PPA is not to install everything so much as install what you want [21:43] Unfortunately, what will happen is the update manager will catch it as updated packages and instruct the user to upgrade anyway. This would save them the step. [21:44] For example, I have an Adour project part way through, I add PPAs to get the new controls and I can no longer load my Ardour session [21:44] It would only upgrade packages that are already installed, nothing that's not installed. [21:44] Yes, Ardour 5.12 to 6.0 could kill someone's project [21:45] or leave them asking how to downgrade [21:45] best use of a PPA is to enable, get wanted sw, disable. [21:46] Nobody does that. If people add PPAs, they usually do it wholesale. [21:46] Ok, so we'll leave it as-is and have the update manager do it anyway? Because that's exactly what will happen. [21:47] Not sure where to go with that one. [21:47] Ya, if they leave it on it will get updated [21:48] I guarantee people will leave it on. [21:48] If we were to add update we would have to warn the user we were doing that with a list of what we were updating and leave a way to say no [21:49] Then let's leave it as-is, because update-manager will handle that anyhow. [21:49] Add PPA does not suggest to me I am installing sw [21:49] Now, this change I'm making with ppa-purge _will_ downgrade software. [21:50] Really? why? [21:50] If I dpkg install something the next update doesn't remove it [21:53] Most people don't add PPAs for just one thing and then remove it. Maybe that's why PPAs were initially created, but that's not how they're practically used. [21:54] The motivation for why I'm doing this is to allow people to upgrade from disco to eoan cleanly. Upgrading with the ppa's packages in-place could (not saying will) cause problems. [21:54] ppa-purge's operation removes the PPAs and downgrades the packages to whatever is in the repo. [21:54] I think installer is not the place for that [21:55] what if the package only exists in the PPA, it vanishes? [21:56] Yes, it would remove anything that isn't in the PPA. However, it would get added if it's part of the seed on the upgrade. Case in point: lsp-plugins [21:56] In software & updates->Other Software: I can remove a PPA (not just disable) and I don't loose or downgrade sw [21:56] That's correct. However, the Kubuntu folk have had issues with that in the past and that's why they have people ppa-purge their backports before upgrading the distro. [21:57] I think installer is not the place for that [21:58] Ok, then I'll leave it alone. [21:58] If done there, the user would need a popup telling them. [21:59] or it should be a separate button "upgrade to *" [21:59] OR, we could add another button ("Purge PPA"). [21:59] at least [22:00] probably, "Remove Backports PPA" should be renamed to "disable Backports PPA" [22:00] and add to enable [22:01] True. [22:02] Note about adding another button: The size of the app is set by the number of buttons x the width of the package list [22:02] I think... [22:02] Shouldn't be an issue. [22:04] If we changed the order with the exit at the right side, the list could span two col. [22:06] So are you goin to add anything to installer right now? or should I start playing with it? [22:08] Nah, go ahead. I'm prepping to add lsp-plugins and dpf-plugins to the list, but that's it. [22:09] Shouldn't conflict with anything you're doing. [22:10] So, I am going to restyle so the list box remains, and the install stuff is always there if hidden. I will try to see if I can disable the PPA add if the PPA is already enabled. [22:10] Ok