arraybolt3[m] | Just showing up, about to read backlog. | 02:05 |
---|---|---|
arraybolt3[m] | guiverc: Well that makes sense to me. Thank for the link, and for putting in a good word for me! | 02:08 |
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:05 |
tsimonq2 | arraybolt3[m]: Go crazy, I'll ping when I'm ready for your list :) | 04:06 |
arraybolt3[m] | 👍️ | 04:06 |
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:11 |
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 | 04:47 |
arraybolt3[m] | OK. | 05:07 |
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:52 |
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:54 |
tsimonq2 | Real life just hit me hard. afk until tomorrow at min | 05:57 |
arraybolt3[m] | Simon Quigley (Developer): So sorry to hear that. Let me know if there's something I can help with. | 05:58 |
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. | 15:11 |
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. | 18:58 |
arraybolt3[m] | Nope, no bug report. I'm certain it's PCMan, so I'll change it. | 19:00 |
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:40 |
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:41 |
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:42 |
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:43 | |
kc2bez[m] | I don't have one either. It would make diagnosing the issue easier. | 20:44 |
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:45 |
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:46 |
kc2bez[m] | Yeah, whatever machine falls into this category is going to be woeful performance. | 20:47 |
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:48 |
arraybolt3[m] | (But yeah, even my fanless ARM-based Chromebook x2 probably could run circles around that thing.) | 20:49 |
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:54 |
kc2bez[m] | arraybolt3[m]: Oh, that is spicy. | 20:55 |
arraybolt3[m] | I wonder if IA32 OVMF packages already exist? | 20:55 |
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. | 20:56 |
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:10 |
kc2bez[m] | That's unfortunate. | 21:11 |
* arraybolt3[m] thinks we should add this to the testcases | 21:11 | |
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:12 |
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:13 |
arraybolt3[m] | Well crud. I guess bug report time then? | 21:16 |
kc2bez[m] | Can you try a focal image and see if that works? | 21:18 |
arraybolt3[m] | Easy. | 21:22 |
arraybolt3[m] | No dice, exact same problem. | 21:23 |
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:24 |
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:25 |
arraybolt3[m] | All the .efi files have "x64" at the end of their names, I think that's the problem. | 21:26 |
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:27 |
kc2bez[m] | We absolutely had this working, i remember the joy... er pain. | 21:29 |
kc2bez[m] | It was 18.10, I looked at the commit. | 21:30 |
arraybolt3[m] | I have unmetered data, I can download an 18.10 iso from Archive.org for a one-off test, no problem. | 21:31 |
kc2bez[m] | It would be good to know. | 21:32 |
kc2bez[m] | I am just wondering about the virtualization layer working as anticipated. | 21:32 |
arraybolt3[m] | Good point, I am using a rather elegant^U^U^U^U^U^U^U hacky way of doing this... | 21:33 |
arraybolt3[m] | Good grief, getting an ISO out of Archive.org can be like trying to eat crablegs for the first time... | 21:36 |
arraybolt3[m] | Alright, download in progress, will report back when the test is complete. | 21:38 |
kc2bez[m] | sounds good | 21:44 |
kc2bez[m] | grub-efi-ia32 is still part of the grub2 package | 21:44 |
kc2bez[m] | so in theory there should be a way as long as the thing boots | 21:45 |
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:47 |
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:48 |
* 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:54 |
arraybolt3[m] | Yeah, but that would be in the squashfs, not in the EFI directory of the ISO file itself, right? | 21:55 |
kc2bez[m] | No, that is a little mini repository outside the squashfs | 21:56 |
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:57 |
kc2bez[m] | all good | 21:58 |
arraybolt3[m] | 23% done downloading Lubuntu 18.10. | 22:01 |
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:11 |
kc2bez[m] | I wonder if they turned EFI off in the bios | 23:12 |
kc2bez[m] | Or hacked the iso | 23:13 |
kc2bez[m] | I would've bet your paycheck that it worked :P | 23:14 |
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:23 |
kc2bez[m] | Right, I don't know what climby did to make it work then. | 23:24 |
kc2bez[m] | He somehow got it booted. | 23:25 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!