| Eickmeyer | OvenWerks: I'm back from vacation. Looks like krytarik helped you with your last ping. | 16:16 |
|---|---|---|
| Eickmeyer | How close are we on studio-controls? | 16:17 |
| OvenWerks | ya. I think I am pretty close to done with controls for this cycle | 16:17 |
| Eickmeyer | Sweet. | 16:18 |
| Eickmeyer | Just let me know. | 16:18 |
| OvenWerks | There is one item left on my todo which may be complete. It is at least part done... it has to do with making devices that are available when not using the alsa back end (alsa jack master) available as an extra device etc.. | 16:20 |
| OvenWerks | and making sure the jack master device is not used as an extra device ... | 16:21 |
| OvenWerks | bluetooth headphones will not get there I think as I have other things to get to. | 16:22 |
| OvenWerks | firewire is back in, with a switch to turn alsa-firewire off (needs reboot) | 16:23 |
| OvenWerks | I have gotten it reliably restarting wth different buffer sizes now. I don't know if the work around I use is even needed with all FW devices but it shouldn't hurt. | 16:25 |
| OvenWerks | ffado mixer does have some problems still. I may need to restart ffado-dbus-server at each jack restart (which uses a busreset) | 16:27 |
| * OvenWerks is thinking out loud and now has a solution to try | 16:28 | |
| OvenWerks | I also need to retest using a FW device with the alsa drivers. | 16:29 |
| OvenWerks | Eickmeyer: in the long run, I may switch from jackdbus to jackd. I do not think jackdbus allows usng more than one FW device at a time. | 16:31 |
| OvenWerks | but that is for another cycle, If I can get one device running well I will be happy. | 16:32 |
| OvenWerks | Eickmeyer: for 20.10 release notes: Controls adds firewire support (one of our devs got a fireiwre device) :) | 16:33 |
| * OvenWerks is sure Eickmeyer can write it better | 16:33 | |
| OvenWerks | Eickmeyer: different subject: The kde/plasma sw update tool (Discover) does not seem to auto remove old kernels. | 16:44 |
| OvenWerks | The one we use in xfce does this (or tries to, it misses whatever kernel was on the install media or the last kernel from the old version in an upgrade) | 16:45 |
| Eickmeyer | OvenWerks: Yeah, that's as easy as a "sudo apt autoremove" to get rid of the old kernels. Definitely something to make the Kubuntu team aware of. (RikMills might have more insight/this is a ping haha). | 16:51 |
| OvenWerks | Eickmeyer: I also noticed while removing linux-generic kept the sw updater from installing the new generic kernel, it did not mark the actuall kernel images as non-dependants (autoremovable) | 16:51 |
| OvenWerks | actually no, the autoremove did not work | 16:51 |
| Eickmeyer | Yeah, I don't know how that works. You might have to use muon to go in and individually remove the old kernels. | 16:52 |
| * OvenWerks has been doing that the few minutes | 16:52 | |
| * RikMills has zero additional insight | 16:55 | |
| Eickmeyer | RikMills: Perhaps that's a bug in Discover that it doesn't remove old kernels? | 16:56 |
| Eickmeyer | Or, maybe a missing feature? | 16:56 |
| OvenWerks | if the /boot directory is in a small partition, it is a bug | 16:57 |
| RikMills | feature I would guess. then again, you can argue how good an idea autoremove is, unless (as implied) space is running out | 16:58 |
| OvenWerks | 14 kernels is a bit much | 16:59 |
| OvenWerks | I actually thin this may be a linux-generic linux-lowlatency thing | 17:00 |
| RikMills | I had someone in the Neon chat running out of space in /boot the other day, so it is a concern | 17:00 |
| RikMills | but honestly it does not come up in 'help' topics much | 17:01 |
| RikMills | the idea of managing kernels with discover makes me queasy.... :P | 17:03 |
| Eickmeyer | RikMills: If one uses LVM at all, it's a concern as the default is only something like 300-500 MB for /boot. | 17:05 |
| RikMills | well will have to disagree. I dislike the idea of an updater deciding to remove kernels | 17:06 |
| Eickmeyer | RikMills: It's unselectable in update-manager, so I imagine it could be just as much opt-out in Discover. | 17:07 |
| RikMills | as discover is multidistro, I doubt KDE would want to implement it and maintain the data on what each distro calls its kernels packages | 17:14 |
| RikMills | feel free to ask thye discover dev Aleix Pol | 17:16 |
| RikMills | *the | 17:16 |
| Eickmeyer | RikMills: Ok. Thanks for the info. :) | 17:18 |
| Eickmeyer | OvenWerks: Ardour 6.2 headed to backports. | 17:25 |
| OvenWerks | RikMills: the updater being muti-distro is the right answer to the question | 17:35 |
| RikMills | you could have a distro supplied config file with the correct patterns... | 17:36 |
| * RikMills runs | 17:36 | |
| OvenWerks | Eickmeyer: I think all kernel images are depends of something... this should mean that any one image (and co) should show up for auto remove when there dep is removed. | 17:37 |
| OvenWerks | *their | 17:37 |
| Eickmeyer | OvenWerks: Yeah, I would think. The thing is, update-manager is more intelligent in that it knows to remove all but the two most recent kernels. | 17:38 |
| Eickmeyer | I think it's hard-coded. | 17:38 |
| OvenWerks | so in theory... a depend on kernel + -1 and -2 should do it... except if the person has not upgraded for a year... | 17:39 |
| OvenWerks | A better hack would be for a new kernel package to create a meta package that replaces an old one with just depends on the last available kernel :) | 17:41 |
| Eickmeyer | linux-lowlatency and linux-generic anre both metas, so I don't know why they're doing that. | 17:47 |
| Eickmeyer | rather, why they're *not* doing that. | 17:47 |
| OvenWerks | RikMills: it would actually be better for ubuntu to have script that gets called (or can get called) as part of a new kernel install | 17:52 |
| OvenWerks | /etc/default/ could have a file with Clean_kernels=True/False or one line for each kernel | 17:54 |
| OvenWerks | however, there is no percieved reason to do this because ubuntu is gnome. | 17:55 |
| Eickmeyer | OvenWerks: That would make this something for the kernel team. | 18:08 |
| Eickmeyer | teward might have insight. (shameless ping) | 18:11 |
| OvenWerks | Eickmeyer: it does look like the depends in the kernel have some extra stuff. | 19:30 |
| OvenWerks | they have one more bit | 19:30 |
| OvenWerks | for example, I have 5.4.0-40 but the dep is 5.4.0.35.40 or something like that. | 19:31 |
| OvenWerks | actually (=5.4.0.42.45) | 19:32 |
| OvenWerks | My guess is that apt does not deal with this they way the sw-updater does | 19:33 |
| Eickmeyer | Must be. | 19:36 |
| Eickmeyer | Either way, my job just got a little easier. lsp-plugins is upstreamed to Debian. \o/ | 19:36 |
| OvenWerks | :) | 19:50 |
| OvenWerks | Eickmeyer: ok, controls is ready for feature freeze. just bug fixes anymore | 19:51 |
| OvenWerks | testing would be great:) | 19:51 |
| OvenWerks | when I say bug fixes I mean bugs I am not aware of, I do not have a list to fix | 19:52 |
| Eickmeyer | OvenWerks: Sounds great. So, that means a 2.0.0 release Awesome. | 19:53 |
| OvenWerks | Eickmeyer: when adding release notes about the reintroduction of firewire, it may be a good idea to note that this is only for single FW devices at this time. I don't think alsa can do that though the multi plugin may work. and I am not sure if jackdbus can either | 19:54 |
| Eickmeyer | Ok, good to know. | 19:54 |
| OvenWerks | yes, unless we want to do 1.9* for bug testing first. | 19:55 |
| OvenWerks | but whatever you feel is fine by me. | 19:55 |
| OvenWerks | Eickmeyer: Question, should this be announced in Linux Audio Announce? | 19:55 |
| OvenWerks | (after you tag the release) | 19:56 |
| Eickmeyer | Here's what I see: you have nothing left on your to-do list for this cycle. Because of that, that sounds to me like a new major release for the rebranding. So, yes, I think an announcement on Linux Audio Announce would be appropriate. | 19:57 |
| Eickmeyer | It'll also get backported. | 19:57 |
| Eickmeyer | 2.0.x would be bugfixes. | 19:58 |
| Eickmeyer | OvenWerks: Also, nice to see it done a month in advance! | 20:16 |
| * OvenWerks has other things he needs to work on. | 20:21 | |
| OvenWerks | even if someone nees to use qjackctl or command line because they have three fw devices, The part I added to controls will be helpful | 20:22 |
| OvenWerks | I may try to modify ffado-mixer or fork it if upstream is not interested. | 20:24 |
| OvenWerks | I have found I need a bus reset every time I open a FW device... after which ffado-mixer no longer works. I have this working with controls but not for people starting jackd from CL | 20:26 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!