[07:14] <ShellcatZero> Out of an interest in bringing LTS up to date, I've been going through the packaging tutorial/example docs and I was just wondering how one creates an installable iso from there to test changes from. If there are some other relevant tutorials to go over, please share!
[17:49] <wxl> ShellcatZero: i would advise putting your updated package in a ppa, getting a fresh iso and running it in a vm, installing the package, and there you go
[17:49] <wxl> ShellcatZero: the release team is extremely unlikely to issue new iso versions for any arbitrary fix, so i would assume that's not going to happen
[18:21] <ShellcatZero> wxl: Thanks, will-do. Can you provide any documentation or description of how to generate the iso following the packaging procedure in the tutorial? The only documentation I seem to find is iso-remastering, which isn't very helpful.
[18:25] <wxl> ShellcatZero: what i'm saying is that's a lot of work for little value. also, we don't generate the iso. the ubuntu infrastructure does.
[18:27] <wxl> ShellcatZero: packaging really has nothing to do with the iso. at the very least they're not directly related.
[18:52] <ShellcatZero> wxl: Got it, I'll research the iso-build process a bit more before giving up on it then. In an ideal world you would like every Ubuntu version that hasn't reached EOL running the latest LXQt version, yes?
[18:59] <wxl> ShellcatZero: i mean, maybe in an ideal world, but that's not really how non-rolling release distros work. you have to get over the hurdle of stable release update requirements which is a rather big one, especially for an entire desktop environment. also, were such a thing to be implemented, it would NOT involve a new iso, so i'd stop worrying about the whole iso thing.
[19:04] <kc2bez[m]> I'll add a little bit to SRUs, they aren't intended to provide new versions, only bug fixes. Most of the time that means pulling in a commit or 2 as a patch to the current package. New application versions go in new releases. 
[19:14] <wxl> Eickmeyer[m]: re: bug 1898501 what sort of issues are you experiencing? we should have no geoip issues except ones that may relate to our little automirror module which is still using the old methodology
[19:15] <ShellcatZero> wxl: The big reason I would be interested in generating an iso would be to address those issues in Calamares, which, depending on your use-case, is an immediate show-stopper for adoption, as it requires (at minimum) some script to fix the issue that breaks /etc/sudoers, and the lack of ZFS support notwithstanding. I was also going to test some build/config scripts using LTS server as the base media to
[19:15] <ShellcatZero> circumvent stock Lubuntu iso installs, but haven't gotten there yet.
[19:18] <wxl> ShellcatZero: you can reconfigure it in situ.
[19:19] <wxl> ShellcatZero: zfs is a big issue problem that i'm not going to sweat too much. what is this "breaking" of sudoers though? where's the bug?
[19:25] <Eickmeyer[m]> wxl: Another bug was commented as a possible duplicate of it, but it's exactly the same issue as I have with being in North Idaho and being assumed to be in the wrong time zone. Narrowed it down to geoipdb.
[19:25] <Eickmeyer[m]> The geo IP we were using before with Calamares did it correctly, Canonical's geoIP server does it wrong.
[19:25] <wxl> Eickmeyer[m]: does it give you new york?
[19:26] <Eickmeyer[m]> wxl: No, it gives me Denver. Should be Los Angeles.
[19:26] <Eickmeyer[m]> Just points to a systemic problem.
[19:26] <Eickmeyer[m]> I was merely triaging that one as a possible GeoIP issue.
[19:27] <wxl> the default should be new york so that suggests it is indeed an issue with the server
[19:27] <wxl> that bug is more about doing json parsing correctly
[19:28] <wxl> technically canonical doesn't even serve json so that's probably not the right bugh
[19:29] <ShellcatZero> wxl: The /etc/sudoers issue has multiple threads online, but it appears that the installer is leaving /etc/sudoers.d/10-installer as an artifact post-install, which can override your changes to /etc/sudoers unless it is deleted. Fixes and threads:
[19:30] <ShellcatZero> https://askubuntu.com/questions/100051/why-is-sudoers-nopasswd-option-not-working/1294589#1294589, https://forum.kaosx.us/d/1502-trouble-with-etc-sudoers-d-10-installer-i-think
[19:30] <wxl> ShellcatZero: i mean a bug report.
[19:32] <ShellcatZero> wxl: https://github.com/calamares/calamares/issues/613
[19:34] <wxl> ShellcatZero: no one's going to pay attention to a bug from 2017 that's closed
[19:35] <wxl> in any case, i'd try the fix suggested
[19:35] <wxl> if it works, it's pretty trivial to fix in calamares-settings-ubuntu
[19:36] <ShellcatZero> wxl: My assumption was that an affected version of Calamares was used for Lubuntu 20.04
[19:37] <ShellcatZero> wxl: I'll take your advice and though and do some experimentation, thanks.
[19:37] <wxl> ShellcatZero: that's an unsafe assumption