[00:03] [telegram] Received (re @tsimonq2: @Roberalz You may have received an email... I merged your PR adding translations to the .desktop file. Long overdue, thank you!) [00:04] [telegram] Nice :D [00:04] [telegram] Let me know once you get the chance to work on those followup translations :) [00:05] [telegram] No. Hopefully, I do translations in Spanish, Galician and Basque. (re @lubuntu_bot: (irc) I think Roberalz said he knows Estonian the other day (could be wrong?). As for Japanese...) [00:06] [telegram] Ok, I'll do that (re @tsimonq2: Let me know once you get the chance to work on those followup translations :)) [00:07] [telegram] Thank you!!! :) [00:08] [telegram] Thank you all for your work, it is impressive. [00:26] [telegram] Of course, and you certainly play an important role in that! [00:46] [telegram] @Roberalz I'll also bring https://translations.launchpad.net/ubuntu-release-upgrader to your attention - that's probably worth blasting out too [00:48] [telegram] https://translations.launchpad.net/ubuntu-release-upgrader/trunk/+pots/ubuntu-release-upgrader/es/+translate?start=0&batch=10&show=untranslated&field.alternative_language=&field.alternative_language-empty-marker=1&old_show=all [00:54] [telegram] Different topic: https://github.com/lxqt/lxqt-config/blob/master/lxqt-config-locale/main.cpp [00:54] [telegram] The inner dialog itself is a public class [00:55] [telegram] I honestly think we should just depend on that and use it within the installer prompt [00:57] [telegram] Instead of connecting reset and exit buttons like that linked file does though, we could simply have a save and reset. If save is ran, it should automatically restart SDDM (but beforehand should cleanly prompt, so the user knows the screen will flicker) [00:57] [telegram] At that point, we should make sure that session language is then picked up by Calamares and automatically set as the default [00:58] Oh that sounds like a great idea. [01:00] [telegram] Also, instead of mucking around with casper and adding an extra boot entry, let's just throw like an "OEM mode" or a "distributor mode" button in the installer prompt, launching it with different XDG settings (OEM mode indicates just the first stage install, distributor mode enables extra automation bits/advanced settings, maybe call it advanced mode) and just go from there. [01:00] [telegram] Here's the only issue with all of this... [01:01] [telegram] LXQt is still on Qt 5. The installer prompt is pure Qt 6. If we wanted to use that function, we really have two options... [01:03] [telegram] A) wholesale copy the dialog code over and port it to Qt 6, removing/replacing specific LXQt dependencies as possible [01:03] [telegram] B) pop up an entirely separate dialog box that can't be minimized/use some sort of iframe to incorporate that purely Qt 5 part into Qt 6 [01:03] [telegram] I'm leaning towards A but B is really the "most compliant" option, believe it or not [01:03] Or port lubuntu-installer-prompt to Qt5. [01:04] That would be my option - having one Qt6 component of Lubuntu in a not-quite-Qt6-ready world seems a bit odd. [01:05] also if we go that route, we can remove the buttons and header that are currently on the background image (which kinda look weird IMO at this point) and put them all *in the window*, which would look more like Ubuntu Desktop's way of doing things where there's a wallpaper and then a window that pops up on top. [01:06] speaking of which I added some architectural things to that prompt that make it so it can run in its own session rather than autostarting over the top of an already-running LXQt session (which looks weird because then the desktop flashes for a second before the prompt appears over the top). [01:24] [telegram] Ok, thanks for commenting, I'll look at it too. (re @tsimonq2: @Roberalz I'll also bring https://translations.launchpad.net/ubuntu-release-upgrader to your attention - that's probably worth blasting out too) [05:57] * arraybolt3 upends my whole entire package building architecture [05:58] got sick and tired of having package builds go awry just because I'm on Jammy, so I'm nuking my whole local package build infra and setting it all up again from scratch in an LXD container. [06:01] going to take the time to clean out some of my horribly messy Projects directory that's an assorted mess of source code, packaging trees, archives, log files, virtual machines (?!), chroots, and other assorted junk [06:36] alright, so much for that, VM it is. LXC has once again gotten me too confused :P [08:06] and my build system is finally up-and-running! [08:06] only took me a couple hours :P [08:07] :) [17:25] arraybolt3: network-manager-openconnect [17:43] tsimonq2: ? [17:44] arraybolt3: ! [17:44] ah, context likely found [17:44] lol [19:04] [telegram] @Roberalz @tsimonq2 I am willing to help with translations so Spanish if needed. Somebody just has to show me exactly how. [20:00] tsimonq2: I'm still not sure what I'm supposed to do with network-manager-openconnect :P [20:04] arraybolt3: connection-editor [20:04] @Rodrigo: Sounds good! I'd like to work with @Roberalz to get some instructions for that. [20:04] We have translations all over, we should have some clear steps for doing them! :) [20:07] tsimonq2: ah [20:08] [telegram] Rodrigo Please don't go too far while we're working this out :) we'd really be interested in your help! [20:09] [telegram] (And you also did the right thing by saying something here too) [20:39] As a heads-up for those who aren't in #xubuntu-devel, it appears the Xubuntu devs are considering potentially switching to Calamares as their installer. No hard decisions, and they are aware of Cala's downsides like localization in the live ISO, so it's not guaranteed, but it's a real possibility. If it happens, we'll want to cooperate with them [20:39] before making big installer changes. [20:40] *they are aware of some of Cala's downsides, I should say - not sure if they know about the /boot encryption keyboard layout issue [20:51] [telegram] arraybolt3: All of the issues @Eickmeyer brought up before will be addressed this cycle. Feel free to quote me on that. [20:51] [telegram] OEM, installer/live l10n, etc. [20:51] woot! [20:52] I'm right now, breathing orifaces deep in https://launchpad.net/~ubuntustudio-dev/ubuntustudio-system-installer/+snap/ubuntustudio-system-installer [20:54] [telegram] To be fair, this isn't actually a Calamares issue, it just a side effect. The environment that is available at that stage is too small to have multiple keyboard layouts. It's more of a grub problem even though that is working as designed. (re @lubuntu_bot: (irc) *they are aware of some of Cala's downsides, I should say - not sure if they know about the /boot encryption keyboard layout issue) [20:54] [telegram] We encrypt /boot which no one else does. [20:54] Eickmeyer: Sounds fun :) [20:54] [telegram] Working on that too. It'll be a workaround. [20:54] [telegram] (With some fancy UX to compliment it) [20:55] [telegram] We could have unencrypted boot but I feel meh about that. [20:55] [telegram] Seems like a regression [20:55] Yeah, I don't like encrypted /boot. Bad UX. [20:55] [telegram] But good security [20:55] [telegram] If Xubuntu wants something totally stable and usable before they switch, I'd tell them wait a month. But, it will be before Feature Freeze. [20:55] [telegram] I get it though [20:56] I like the idea of encrypted /boot but it always feels just a little bit silly to me. I mean yeah, no one can just modify the initramfs anymore... but what about the bootloader image itself? [20:56] There's always something decrypted that could be modified. I guess Secure Boot avoids that last bit, but most people don't use that. [20:56] anyway, I'm fine if we keep it, but I'm not attached to it. [20:57] [telegram] But you can't get to anything even if you modify it [20:57] Except the user's passphrase. [20:57] Meh, it would be a much more complicated attack for sure, dealing with things at that low of a level, and Secure Boot would stymie that. [20:58] [telegram] Not really. That hasn't been unlocked yet [20:58] So I see how it does offer a significant security boost in at least some situations. [20:58] kc2bez: I was referring to modifying the bootloader itself, not the remainder of the disk. [20:58] [telegram] It gains nothing [20:59] [telegram] It doesn't have access to the kernel yet [20:59] [telegram] If you modify it the drive will never be unlocked [21:00] [telegram] We just need to decide which compromise is acceptable. I may very well be in the minority and I can accept that. [21:00] tsimonq2: Check Matrix DMs whenever you get a bit [21:01] kc2bez: Being in the more secure minority isn't a bad thing, and trying to get others on board with it isn't a bad thing either :) [21:02] [telegram] Fair point. I don't want to seem like an obstacle to progress either. [21:05] [telegram] It looks like we have a few options... [21:06] [telegram] A) Just default to unencrypted /boot by default [21:06] [telegram] B) Create a third keyslot with the password converted to the American layout, specifically denying characters that are inaccessible from the US layout. This provides a translation layer [21:07] [telegram] C) Somehow convince juliank to ship the extra keyboard layouts [21:07] [telegram] mkukri: ^^^^ [21:30] i was not aware of the lack of extra keyboard layouts in grub, but not against advocating for shipping extras in principle if it really makes people's lives easier [21:31] however i dont think encrypted /boot is a good idea in general, and i would personally advocate for killing it, and definitely wouldn't ship it by default [21:32] [telegram] Could you elaborate on why encrypted /boot is a bad idea? [21:32] i don't see any security benefits over just signing binaries on /boot and only encrypting root [21:32] and it adds a bunch of code complexity to grub [21:32] which is now suddenly part of our secure boot attacks surface, meaning any exploitable bugs in grub crypto code needs security fixes and secure boot revocations [21:33] (btw i know its a contentious topic and there has been no decision made in this direction, this is a personal opinion, but it's probably shared by a few people) [21:35] with the exception being the removal of luks2 support in grub on secure boot which was never really supported [21:49] [telegram] I just received a +1 on that from my Security Team contact. [21:49] [telegram] @kc2bez After the additional context, do you still have reservations? [22:01] [telegram] Admittedly it seems like less of an issue. I do think we can set the luks type we use however we have it set to luks1 currently. I am unsure if any testing has been done from a manual partitioning standpoint or not. [22:03] [matrix] a larger attack surface—even if it promises more security—seems like a bad idea. i'm sure i've advocated for encrypted /boot in the past but that's a consideration i hadn't taken into account. that coupled with the obvious UX issues makes me think unencrypted /boot is probably the best of all worlds. [22:03] [telegram] Thanks wxl [22:04] plus sticking with the status quo will mean more support when the inevitable issues crop up [22:05] [telegram] I agree with that as well. Too much custom can lead to technical debt. [22:06] [telegram] My mind can be changed. I am good with option A) [22:06] [telegram] Thanks for hearing me out. [22:07] is there any usecase for non-us keyboard layouts in grub outside unlocking boot partitions? [22:07] none that i'm aware of but unfortunately i don't use a non-us layout so that doesn't help with perspective any XD [22:07] [telegram] Maybe if you ended up at a grub prompt but you likely have some other problem at that point. [22:09] [telegram] fstab misconfiguration, bad disk, etc. [23:21] [telegram] There are pending translations in lxqt, although they are few, I would say that in Spanish we have no problem, but there are other languages in which translations are missing. (re @Rodrigo: @Roberalz @tsimonq2 I am willing to help with translations so Spanish if needed. Somebody just has to show me exactly how.) [23:26] @wxl: Always good to get your two cents. <3 [23:32] [telegram] Would you say upstream is particularly slow in accepting those translations? If they are, would you be interested in helping with that/can I make the connection? (re @Roberalz: There are pending translations in lxqt, although they are few, I would say that in Spanish we have no problem, but there are other languages in which translations are missing.) [23:35] tsimonq2: np. [23:36] [telegram] Ok, I am not proficient in other languages 🙃 [23:36] [telegram] I'll stick around in case I can be of any help in the future (re @Roberalz: There are pending translations in lxqt, although they are few, I would say that in Spanish we have no problem, but there are other languages in which translations are missing.) [23:42] [telegram] https://translate.lxqt-project.org/ (re @Rodrigo: Ok, I am not proficient in other languages 🙃 [23:42] [telegram] I'll stick around in case I can be of any help in the future) [23:42] [telegram] This is the first place to do the translations.