[02:05] <arraybolt3[m]> Just showing up, about to read backlog.
[02:08] <arraybolt3[m]> guiverc: Well that makes sense to me. Thank for the link, and for putting in a good word for me!
[04:05] <arraybolt3[m]> Simon Quigley (Developer): I'm about to try to hammer through a bunch of backports, ping me when you'd like a list of PRs to check through.
[04:06] <tsimonq2> arraybolt3[m]: Go crazy, I'll ping when I'm ready for your list :)
[04:06] <arraybolt3[m]> 👍️
[04:11] <arraybolt3[m]> Simon Quigley (Developer): I did just hit something a bit worrying - obconf-qt appears to have a well-updated copyright file, but looking through diffs, I'm seeing references to names and years that we don't have marked. I'm guessing that since obconf-qt is derived from obconf (I believe?) that these are copyright remnants from the old software and don't matter, but I'd like some confirmation about that.
[04:11] <arraybolt3[m]> https://github.com/lxqt/obconf-qt/compare/0.16.0...0.16.2.diff
[04:47] <tsimonq2> <arraybolt3[m]> "Simon Quigley (Developer): I did..." <- If it's in the source code but not referenced by the copyright file as a rule of thumb you should just add it 
[05:07] <arraybolt3[m]> OK.
[05:52] <arraybolt3[m]> Simon Quigley (Developer): Alright, so here's an interesting question. What do I do when the source code file literally has this as the copyright header:
[05:52] <arraybolt3[m]>     <one line to give the program's name and a brief idea of what it does.>
[05:52] <arraybolt3[m]>     Copyright (C) 2013  <copyright holder> <email>
[05:52] <arraybolt3[m]> (That is verbatim from src/maindialog.h in obconf-qt.)
[05:54] <arraybolt3[m]> I'm pretty sure that this is Hong Jen Yee (PCMan) since the other 2013 copyrights were from him, but I have no way of knowing for certain.
[05:57] <tsimonq2> Real life just hit me hard. afk until tomorrow at min
[05:58] <arraybolt3[m]> Simon Quigley (Developer): So sorry to hear that. Let me know if there's something I can help with.
[15:11] <kc2bez[m]> <arraybolt3[m]> "I'm pretty sure that this is..." <- I am going to say you have 2 options. You could skip over it since it isn't clear or give the person that committed that the credit. 
[18:58] <arraybolt3[m]> Dan Simmons: Good thinking. Currently I have a ridiculous-looking line in debian/copyright, but Hong Jen Yee was the committor, so it's probably him. I filed a bug report upstream last night, so I may have an answer already today.
[19:00] <arraybolt3[m]> Nope, no bug report. I'm certain it's PCMan, so I'll change it.
[20:40] <arraybolt3[m]> I had a potentially crazy idea that might make a lot of people happy. There's a number of computers out there where they have a 64-bit CPU, but the UEFI is 32-bit and requires a 32-bit bootloader to function. A quick look through Ubuntu packages reveals that we do indeed appear to package the 32-bit UEFI GRUB, perhaps we might consider including it on the ISO and adjusting our config to detect these sort of systems and install the
[20:40] <arraybolt3[m]> proper bootloader?
[20:41] <kc2bez[m]> arraybolt3[m]: Is it not there on a live image? It used to be.
[20:41] <arraybolt3[m]> Dunno. I've seen many complaints about this though - someone the other day was stuck having to go back to Xubuntu 18.04 on the #ubuntu IRC chat because they had to use a 32-bit distro despite having a 64-bit system due to this problem.
[20:42] <kc2bez[m]> Plus we run this little tiny script to detect that https://phab.lubuntu.me/source/calamares-settings-ubuntu/browse/ubuntu%252Fkinetic/common/modules/before_bootloader_context.conf%2415
[20:42] <arraybolt3[m]> Hmm. Maybe the problem was that someone was trying to use Xubuntu or Ubuntu and not Lubuntu then. I didn't know that.
[20:42] <arraybolt3[m]> (Can the Lubuntu USB even boot on such systems?)
[20:43] <kc2bez[m]> It should work, we did some testing in early days.
[20:43] <kc2bez[m]> 18.10 or 19.04
[20:43]  * arraybolt3[m] wishes I had one of these finicky laptops to verify, since the guy on #ubuntu seemed pretty sure that Lubuntu wasn't working...
[20:44] <kc2bez[m]> I don't have one either. It would make diagnosing the issue easier.
[20:45] <kc2bez[m]> There is a current thread that is of a similar situation and has me questioning things.
[20:45] <kc2bez[m]> https://discourse.lubuntu.me/t/vintage-laptop-asus-x205ta-supported/3424
[20:45] <arraybolt3[m]> It was looking at that thread that made me think about this.
[20:46] <arraybolt3[m]> (Looking at an eBay listing for that particular laptop and can't help but laugh when they describe 2 GB RAM and 1.33 GHz Intel Atom as "packing power where it counts")
[20:47] <kc2bez[m]> Yeah, whatever machine falls into this category is going to be woeful performance.
[20:48] <arraybolt3[m]> Which is fine for Lubuntu, not so great for Windows, thus why users want to switch.
[20:48] <kc2bez[m]> For sure
[20:49] <arraybolt3[m]> (But yeah, even my fanless ARM-based Chromebook x2 probably could run circles around that thing.)
[20:54] <arraybolt3[m]> aHA! I can compile TianoCore myself for IA32, I bet that will let me load it into an x86_64 VM and make myself a virtual "hybrid mess" VM to test in.
[20:55] <kc2bez[m]> arraybolt3[m]: Oh, that is spicy.
[20:55] <arraybolt3[m]> I wonder if IA32 OVMF packages already exist?
[20:56] <arraybolt3[m]> Looks like there is!
[20:56] <arraybolt3[m]> https://packages.ubuntu.com/jammy/ovmf-ia32
[20:56] <kc2bez[m]> nice
[20:56] <arraybolt3[m]> OK, now we can test it. I may do that right now.
[20:56] <kc2bez[m]> sounds good, I am interested in the results.
[21:10] <arraybolt3[m]> 32-bit UEFI support is borked. Tried to load it in QEMU, it just skipped right over the ISO, kicked me back to the UEFI setup screen if I tried to boot the ISO or any of the .efi files directly. 64-bit UEFI automatically booted from the ISO. Looks like we're only shipping the 64-bit bootloader on the ISO itself.
[21:11] <kc2bez[m]> That's unfortunate.
[21:11]  * arraybolt3[m] thinks we should add this to the testcases
[21:12] <kc2bez[m]> Well, not if it won't work ;)
[21:12] <arraybolt3[m]> but i mean can't we fix it by shipping the 32-bit bootloader too
[21:13] <kc2bez[m]> The live system build is a little different, we can't just add the package to our seed and have the image built with it persay.
[21:16] <arraybolt3[m]> Well crud. I guess bug report time then?
[21:18] <kc2bez[m]> Can you try a focal image and see if that works?
[21:22] <arraybolt3[m]> Easy.
[21:23] <arraybolt3[m]> No dice, exact same problem.
[21:24] <arraybolt3[m]> I could take 18.04 64-bit for a test drive, too.
[21:24] <kc2bez[m]> 🤔 i feel like that should have worked else we would have heard about it by now.
[21:25] <kc2bez[m]> 18.04 is ubiquity + lxde
[21:25] <arraybolt3[m]> Yeah but if this problem hits Lubuntu, it probably hits Ubuntu too, Ubuntu 18.04 is still supported, and if we can get a confirmed bug report and a fix, it will hopefully propagate to Lubuntu 22.04 and 22.10.
[21:26] <arraybolt3[m]> All the .efi files have "x64" at the end of their names, I think that's the problem.
[21:27] <arraybolt3[m]> (As in, they're all 64-bit EFI files, when a 32-bit EFI needs 32-bit files even on a 64-bit CPU.)
[21:29] <kc2bez[m]> We absolutely had this working, i remember the joy... er pain.
[21:30] <kc2bez[m]> It was 18.10, I looked at the commit.
[21:31] <arraybolt3[m]> I have unmetered data, I can download an 18.10 iso from Archive.org for a one-off test, no problem.
[21:32] <kc2bez[m]> It would be good to know.
[21:32] <kc2bez[m]> I am just wondering about the virtualization layer working as anticipated.
[21:33] <arraybolt3[m]> Good point, I am using a rather elegant^U^U^U^U^U^U^U hacky way of doing this...
[21:36] <arraybolt3[m]> Good grief, getting an ISO out of Archive.org can be like trying to eat crablegs for the first time...
[21:38] <arraybolt3[m]> Alright, download in progress, will report back when the test is complete.
[21:44] <kc2bez[m]> sounds good
[21:44] <kc2bez[m]> grub-efi-ia32 is still part of the grub2 package
[21:45] <kc2bez[m]> so in theory there should be a way as long as the thing boots
[21:47] <arraybolt3[m]> Makes sense to me. Probably something just got lost somewhere in the 32-bit support-removal process (18.10 existed when 32-bit Ubuntu support was still a thing for new editions).
[21:47] <kc2bez[m]> that is true
[21:48] <arraybolt3[m]> It should hopefully not be too much of a problem to get it added back, though - it isn't for making 32-bit systems work, it's for making strange 64-bit systems work (and Ubuntu just did a whole bunch to make strange 64-bit systems work with changing BIOS boot to GRUB on the ISO).
[21:54]  * kc2bez[m] uploaded an image: (32KiB) < https://libera.ems.host/_matrix/media/r0/download/matrix.org/PgXrdpWJqepwaByisWYgJvjE/2022-07-03_17-54.png >
[21:54] <kc2bez[m]> It is in the package list on the cdrom
[21:54] <kc2bez[m]> The command we have should work.
[21:55] <arraybolt3[m]> Yeah, but that would be in the squashfs, not in the EFI directory of the ISO file itself, right?
[21:56] <kc2bez[m]> No, that is a little mini repository outside the squashfs
[21:57] <kc2bez[m]> You are right about the EFI directory though
[21:57] <arraybolt3[m]> Right, but I'm saying, it doesn't matter if Ubuntu thinks the package is there or not, what matters is if there's a "whatever.efi" file in EFI/boot/ubuntu of the ISO file.
[21:57] <kc2bez[m]> Very true
[21:57] <arraybolt3[m]> Sorry, I missed the message you sent just before I sent mine.
[21:58] <kc2bez[m]> all good
[22:01] <arraybolt3[m]> 23% done downloading Lubuntu 18.10.
[23:11] <arraybolt3[m]> Tested with Lubuntu 18.10, there are only x64 efi files and they don't work with 64-bit CPU + 32-bit EFI.
[23:11] <arraybolt3[m]> Maybe it was in a daily not the main release?
[23:11] <arraybolt3[m]> Or a devel ISO?
[23:12] <kc2bez[m]> I wonder if they turned EFI off in the bios
[23:13] <kc2bez[m]> Or hacked the iso
[23:14] <kc2bez[m]> I would've bet your paycheck that it worked :P
[23:23] <arraybolt3[m]> I'll try 19.04 next. Worst case scenario, I've got an idea for how to hack an ISO to work on 32-bit EFI. It would have to be an unofficial tool, but it might work.
[23:23] <arraybolt3[m]> (The 64-bit EFI files were there, just not the 32-bit ones.)
[23:24] <kc2bez[m]> Right, I don't know what climby did to make it work then.
[23:25] <kc2bez[m]> He somehow got it booted.