[00:00] <teward> Cala does not do this
[00:00] <teward> so it's impossible to debug
[00:01] <teward> *does a thing and manually executes calamares on the CLI with --debug*
[00:06] <teward> executing installation with full debug
[00:06] <teward> if it errors I'll have the full debug logs from Cala
[00:06] <teward> (the stuff Ubuntu's installer logs but also shows if you expand the details during the installer giving you full CLI logs and stuff)
[00:06] <teward> Eickmeyer: RikMills: don't consider the resolution change as a problem, it's just an oddity
[00:06] <teward> it's the least important thing, and might be impacted 'cause i'm running via qemu-kvm
[00:07] <Eickmeyer> Qemu is weird like thst sometimes.
[00:07] <teward> so it's not a straight bare metal install.  HOWEVER, the apt failure I did reproduce, so I'm running with full debug data to try and repro
[00:10] <teward> found the error
[00:10] <teward> "Unable to locate package: zram-config
[00:11] <teward> so this is pulled in as a result of apt attempting to remove zram-config but it doesn't exist at all in the apt data
[00:12] <teward> Eickmeyer: so, zram-config is NOT present on the image
[00:12] <teward> and not pulled in anywhere so if the system doesn't do an `apt update` it doesn't know zram-config is even a package
[00:12] <teward> it'd otherwise give a non-critical warning instead of a crash
[00:12] <teward> so fully-offline install is not possible in the current iteration of the ISO
[00:13] <teward> Eickmeyer: RikMills: OvenWerks:  ^^ there's your installation crash
[00:14] <teward> Eickmeyer: OvenWerks: `sudo calamares --debug 2>&1 > cala.log` in the CLI will execute Calamares and force debug output to a log file, that's how i found this data
[00:14] <teward> i'd do a pastebinit of the logs but it's large :P
[00:16] <teward> full logs: https://paste.ubuntu.com/p/KXG9JDCkrv/
[00:16] <Eickmeyer> teward: I'll take a look at why on earth it's even attempting to uninstall zram-config. We've never had that installed and this is the first time this is showing up.
[00:16] <teward> Eickmeyer: that's why i dumped the logs
[00:16] <teward> so you can see everything it idd
[00:16] <teward> did*
[00:17] <teward> it'll also show you the command it's running (line 849, error on 856 from apt)
[00:17] <teward> unrelated: I love how qemu-kvm has clipboard integration in *buntu images so I can copy paste links in/out of the VM xD
[00:20] <Eickmeyer> Oh, I do that with virtualbox all the time. Granted, it has to have a client-side module, but whatev.
[00:20] <teward> Eickmeyer: it could be a leftover from some python config somewhere that's referring to zram-config.  Because it is populated as part of one of the python tasks it seems
[00:21] <teward> 855 is a noncritical info but 856 with zram-config is why it's breaking in my qemu
[00:24] <teward> there also... seemed to be some "why is DNS failing here?" headscratching in the logs.  My guess is that zram-config SHOULD be picked up as 'not installed' and be like line 855
[00:24] <teward> but becasue of the prior dns resolution failures, I would surmise that it's failing exceptionally hard because it didn't get package info from apt sources that would indicate zram-config is a valid package but just isn't installed.
[00:25] <teward> that's beyond my ability to debug 'cause DNS works - i confirmed it :P
[00:25] <teward> so maybe chroot specific problems.
[00:25] <Eickmeyer> teward: It's actually explicitly stated in ubuntustudio/modules/packages.config to remove at the end of the installation, for reasons I'll never know. Either way, I'm a changelog/commit away from having it fixed.
[00:25] <Eickmeyer> In calamares-settings-ubuntu
[00:26] <teward> check.  the reason it's failing to be found is the DNS resolution issues i mentioned (see line 822+)
[00:26] <teward> lines 822 through 841)
[00:26] <teward> 'Temporary failure resolving' is a problem, because if it can't get apt data (and yes this VM has DHCP and valid DNS) then that's why it's hard erroring
[00:26] <Eickmeyer> That might be the reason for the hard failure, but we don't see zram-config, so no reason to remove it.
[00:26] <teward> s/841/847/
[00:27] <teward> Eickmeyer: it's probably there for a reason
[00:27] <teward> but probably still something to figure out.  temporary workaround, remove it from the tasks.  long term: figure out why it failed to resolve
[00:27] <Eickmeyer> teward: Probably because I copied it from the Lubuntu config of the same name.
[00:27] <teward> hah
[00:27] <teward> ah, but the Lubuntu installer currently in Impish doesn't have the same DNS resolution in chroot problem that I can tell
[00:28] <teward> actually i should test that
[00:28] <teward> *zsyncs the Lubuntu installer*
[00:31] <Eickmeyer> Well, I just pushed the short-term fix, hopefully that will do the trick for the most part, but yes, if DNS reso is weird, that might have to do with something deeper.
[00:36] <teward> i touched base with Dan on the Lubuntu side, and they said you're handling settings
[00:36] <teward> i'mma do a reinstall of Studio but with a different test
[00:36] <teward> `sudo -E` because i might've forgot something
[00:37] <Eickmeyer> Yeah, I'm handling settings for the Studio stuff only.
[00:38] <Eickmeyer> I'm only supposed to have permission to handle it for these types of cases.
[00:40] <teward> um
[00:40] <teward> Eickmeyer: that won't affect the Lubuntu settings right?
[00:40] <teward> 'cause... they use zram :P
[00:40] <Eickmeyer> Not at all. Separate subdirectories.
[00:40] <teward> check
[00:54] <teward> Eickmeyer: so, i did more pokings
[00:55] <teward> Lubuntu *does* have the same DNS resolution in chroot problem that we were seeing in the Studio ISOs.  but because Lubuntu includes zram-config in the image (yes they use zram and it needs removed for install), it doesn't error.  But it does see the same dns reso issue
[00:55] <teward> the failure in dns reso means apt update didn't work, and because zram-config isn't part of the image that's why it hardfailed
[00:55] <teward> so just removing it from the cala settings for Studio *should* solve the hard fail
[00:55] <teward> (the dns reso problem inside the chroot during the processes done by Cala seems persistent on all so)
[00:56] <Eickmeyer> Yeah, that seems like a cala bug for sure, or at least something weird in the chroot.
[00:59] <teward> indeed on both counts
[00:59] <teward> also
[00:59] <teward> the version strings're wrong in Cala (saying 21.04)
[00:59] <teward> Dan's fixing on the Lubuntu side but your job on the Studio side.
[00:59] <teward> but the dns reso problem is why yours hardfailed unexpectedly
[00:59] <teward> so that must be a recent problem
[00:59] <teward> (just update your settings :P
[00:59] <Eickmeyer> Well, it should be fixed on both sides since I just uploaded a 21.10.1 version to proposed.
[01:00] <Eickmeyer> The subdirectories divide the binary subpackages, not the source, so the version will propogate to both lubuntu and ubuntustudio.
[01:00] <Eickmeyer> teward ^
[01:01] <teward> check
[01:01] <teward> so, test the next ISO and the hard fails should go away.
[01:01] <teward> once it gets out of -proposed
[01:02] <Eickmeyer> Yep.
[01:05] <teward> Eickmeyer: as long as the settings that Lubuntu gets still include the zram-config remove then that's good.
[01:05] <teward> i'm still catching up on the cala stuff xD
[01:06] <Eickmeyer> Yeah, the binary package for lubuntu won't be affected. Think of it as akin to a no-change rebuild on that side of the source.
[01:06] <teward> (I usually avoid installer bugs like the plague except during testing, but I never actually deep dive heh)
[01:06] <teward> yepo
[01:06] <teward> ffs i can't type
[01:06] <Eickmeyer> haha
[01:32] <teward> Eickmeyer: i've enlisted an Lubuntu guy to see if they can repro the dns resolution notes we had during the chroot install, and then that's a task for next cycle if it is present.  Unless it causes chaos like it did today :p
[01:32] <teward> *goes to sleep mode*
[01:33] <teward> (but on the Lubuntu instaler of course)
[01:36] <Eickmeyer> Yep, I know Chris. Good guy.
[09:25] <RikMills> teward: https://bugs.kde.org/show_bug.cgi?id=407058
[09:27] <RikMills> BIG patch to fix it in master, which I don't feel confident backporting
[09:53] <RikMills> OvenWerks Eickmeyer FYI, konsole width thing is the same in Neon
[13:54] <teward> RikMills: thanks for the FYI
[15:13] <OvenWerks> RikMills: it did seem to be just konsole that had the trouble. all the other windows work fine.
[15:13]  * OvenWerks also notes the path to the profile files in the documentation does not agree with reality.
[15:17] <RikMills> no other apps have added such a silly toolbar ;)
[15:38] <OvenWerks> removing the toolbars works
[15:41] <OvenWerks> but... the menu item starts konsole with the last used profile instead of the default one :P
[16:17] <OvenWerks> The quick launch widget is frustrating
[16:31] <RikMills> you could use the konsole profile widget
[16:35] <RikMills> I don't think I have ever used multiple profiles with konsole
[16:52] <OvenWerks> RikMills: when the quick launch widget is used, and the item is edited, that effects the menu item. then I make a second quick launch and make it another konsole with a different command line... but because the quick launch basically copies the desktop file from system to ~/.local/share/applications/ and changes it... it has the same name etc. So I found that I need to create a separate 
[16:52] <OvenWerks> desktop file on my own then select that instead
[16:52] <OvenWerks> The konsole profile widget does work. but it is two click instead of one
[16:54] <RikMills> nice thing about linux is you can hack things like that, if the default is not to your liking :)
[16:54] <OvenWerks> The advantage of a separate wiget is also being able to use a different icon.
[16:55] <OvenWerks> my daily setup is still the last LTS so it has been a while since I went through this.
[17:11] <Eickmeyer> OvenWerks: We have a different default profile (called Profile 1) in order to use the Materia color scheme, otherwise it looks a little funny.
[17:12] <OvenWerks> Eickmeyer: default 1 is ok
[17:13] <OvenWerks> I think I make my own default of 80X25 instead of 110X25
[17:18] <Eickmeyer> The default profile has no size information (nor does konsolerc), so I don't know why it's going to that really wide size.
[17:18] <Eickmeyer> RikMills: ^
[17:18] <OvenWerks> the really wide size is to fit the toolbar
[17:18] <RikMills> ^that
[17:19] <OvenWerks> if you select different sets of toolbars the size changes
[17:19] <OvenWerks> there are two: main and session
[17:19] <OvenWerks> but main is the wide one
[17:19] <Eickmeyer> Ok, I'll disable the toolbar per the file RikMills showed us.
[17:20] <Eickmeyer> Just need to upload the fix to default-settings and we'll be good.
[17:23] <OvenWerks> Eickmeyer: it seems the problem with controls 2.2.1 has gone? see #ubuntustudio comment.
[17:24] <Eickmeyer> OvenWerks: Probably due to a build-time change I made to Jack with falktx's help (disabled LTO).
[17:25] <Eickmeyer> OvenWerks: Still doesn't fix the pulseaudio failing to yeild issue.
[17:25] <Eickmeyer> (hence the earlier merge we did)
[17:25] <OvenWerks> I think a reboot would fix it. I think for 2.3 (3.0?) I will rework the convert script and move some of that to both autojack and controls
[17:25] <OvenWerks> I am not having trouble with pulse that I can see
[17:26] <OvenWerks> (using 2.2.1 in iso)
[17:26] <Eickmeyer> Well, I am. Every time I try to start Jack, pulse doesn't restart and hogs the devices, causing autojack to default to internal audio (xrun city). Only solution was to 'systemctl --user restart pulseaudio' upon login.
[17:30] <OvenWerks> ok, I have some debugging lines added to convert to upload and then we can tag 2.2.2
[17:31] <Eickmeyer> Sweet.\
[17:32] <OvenWerks> Eickmeyer: 2.2.* is going to become a branch I think. It will be the last pulse/jack version(s). 3.* will be pw/jack
[17:32] <Eickmeyer> OvenWerks: Oh, cool!
[17:33] <Eickmeyer> Does that mean we should look at switching to PW for the LTS?
[17:34] <OvenWerks> any comments on setting ffado modules to be the default install?
[17:35] <OvenWerks> This allows people to try the ffado modules from the iso with no install and also the alsa modules are quite limiting
[17:35] <Eickmeyer> As long as it doesn't mess with USB or otherwise.
[17:36] <OvenWerks> It should have no effect on USB or internal devices (it doesn't here for sure)
[17:36] <Eickmeyer> Can we confirm that ffado works with all firewire devices?
[17:36] <OvenWerks> more devices than alsa
[17:37] <OvenWerks> alsa is based on the prior work done by ffado
[17:37] <Eickmeyer> Sweet. Then I say why not, but it's beyond FF so we'll have to wait for the next dev cycle to kick that in.
[17:37] <Eickmeyer> I'm not comfortable with either approving a FFe or asking for one in this case.
[17:42] <RikMills> fyi, there will be a new konsole upload coming. I am cherry picking the bugfixes from https://invent.kde.org/utilities/konsole/-/commits/release/21.08/
[17:42] <Eickmeyer> RikMills: Awesome. Maybe that will fix most of the issue?
[17:43] <RikMills> as 21.08.2 won't be out before release
[17:43] <Eickmeyer> Right, an SRU wouldn't be frowned-upon though.
[17:43] <RikMills> Eickmeyer: not the width issue sadly
[17:43] <Eickmeyer> Ohhhh Ok.
[19:26] <Eickmeyer> MauroGaspari[m]: To answer your question (sorry for the late reply) I don't quite have anything to talk about yet, but Studio Controls has quite a few enhancements, including the ability to do jack via network.
[19:58] <OvenWerks> RikMills Eickmeyer: for settings manager->devices->input->game controlers it would be nice to have a button: "this is a tablet"
[19:59] <Eickmeyer> OvenWerks: Not a bad suggestion. Probably a decent suggestion for the Plasma team.
[20:01] <OvenWerks> We have two tablets that show up as game controlers until I modify /usr/share/X11/xorg.conf.d/70-wacom.conf
[20:05] <Eickmeyer> That sounds like a bug more than a feature request.
[20:06] <Eickmeyer> Of course, feature development for kwin-x11 has ceased in favor of Wayland.
[21:52] <OvenWerks> sounds way to close to waste land