[02:29] <arraybolt3[m]> For some reason, sometimes when I "pull-lp-source" a package, it tells me "Public key not found, could not verify signature". Other times it seems to be able to GPG-verify the package. For instance, pulling SDDM, I get the "public key not found" message. I even tried using gpg to import Eickmeyer's public key into my system just to see if that was the problem, and no luck. Any clue what's going on here?
[02:30] <arraybolt3[m]> (For reference, when pulling an LXQt package, it seems to properly GPG-verify it and displays Simon's key on it, even though I don't have Simon's public key imported here, so idk what it's doing or where it's getting its key info.)
[02:31] <arraybolt3[m]> And does it even matter? If it's pulling from LP (preferably over HTTPS), I have nothing to worry about, but if it's pulling via plain HTTP, that's worrying to me. I try to stay security conscious and don't like building or running code that could have been MITM'd on my system.
[02:32] <Eickmeyer[m]> arraybolt3: My key is kinda weird like that, it'll say "public key not found" with "Error: 0" basically saying there is no error.
[02:32] <arraybolt3[m]> Oh, funny. I get the same problem with other people's packages too sometimes, fwiw.
[02:33] <arraybolt3[m]> Hah! It does the same thing with my key!
[02:33] <sarnold> ha :)
[02:33]  * arraybolt3[m] shakes LP vigorously
[02:33] <arraybolt3[m]> Welp, great. Wonder what Simon did to make his key work all fancy and stuff.
[02:34] <sarnold> I bet you could get similar messages with dpkg-source -x without pull-lp-source in the chain at all
[02:34] <sarnold> that might simplify tracking down the cause, if my guess is right
[02:40] <arraybolt3[m]> Sorry, went afk, trying now.
[02:42] <arraybolt3[m]> sarnold: OK, downloaded the source package over HTTPS with wget, then used dpkg-source -x on it, and I got:
[02:42] <arraybolt3[m]> https://dpaste.com/5JMVHGHKQ
[02:42] <arraybolt3[m]> TL;DR: "dpkg-source: warning: cannot verify inline signature for ./sddm_0.19.0-2ubuntu2.2.dsc: no acceptable signature found"
[02:43] <arraybolt3[m]> BUT, if I "gpg --keyid-format=long --verify sddm_0.19.0-2ubuntu2.2.dsc", it tells me "Good signature".
[02:44] <arraybolt3[m]> Soooo... something somewhere is failing to store the keys I need I guess?
[02:46] <arraybolt3[m]> Oh. I bet I just found it. One of the keyrings in use is the Debian Maintainer's keyring. I bet Simon is a Debian Maintainer (I know he's a Debian Developer), and so his key works. I am not a Debian anything-official, so my key doesn't work. That's probably what's "wrong" (though not really wrong) with Erich's key. So I guess I just need to add his key into the right keyring and it should work.
[02:48] <arraybolt3[m]> Eh, I didn't find Simon's key in the Debian Maintainer keyring, but I did find te-ward's, so I think this hunch is right, one of those keyrings probably has Simon's key.
[02:49] <arraybolt3[m]> Found him. Alright, mystery solved.
[02:57] <arraybolt3> So now the question is, how do I get my and Eickmeyer's key added to my trustedkeys.gpg file? But that should be easy enough to do.
[03:16] <arraybolt3[m]> Lovely. Well now pull-lp-source still isn't happy, but dpkg-source -x is! :-/
[03:18] <arraybolt3[m]> Anyway, this is enough for me. Thank you guys for your help!
[03:19] <sarnold> hehehehe
[03:33] <bricker> is ubuntu 22.04 lts going to be x86-64-v2 only or will is continue to support see4.1 cpus?
[03:33] <bricker> meant 22.04
[03:33] <bricker> 24.04
[03:34] <sarnold> I haven't seen conversations on that in a while; the last time I tried to find the conversations, I failed :( heh
[03:34] <bricker> Wondering if the next lts release is going to be see4.2 only and above or not
[03:34] <sarnold> I have a vague feeling that it might be added as a new arch, and not taking away anything, but I sure can't promise that
[03:34] <bricker> Yikes
[03:35] <bricker> Well hopefully its just another added branch
[03:35] <bricker> I have a few core two duo servers and laptops which I run ubuntu on
[03:35] <bricker> mainly worried about the macbook pro 7.1
[03:35] <bricker> aka 2010 macbook
[03:45] <amurray> mwhudson was looking at all that - but I also don't recall what the status was - I am pretty sure we have no plans to stop supporting older amd64 variants as we recognise there is quite a lot of that still around that we want to be able to support
[03:47] <sarnold> but in 26.04 or 28.04 it might feel like an obvious choice
[03:47] <sarnold> it's funny how those things happen.. I'm shocked we still do x86 and armhf, but here we are :)
[03:58] <arraybolt3[m]> I mean I don't see any reason to not keep supporting x86-64, the Linux kernel supports it and probably will support it for years or maybe even decades, and all modern software builds and runs on it, right?
[03:59] <arraybolt3[m]> We only dropped i386 because of lack of testers, otherwise we'd still support that, IIUC.
[03:59] <sarnold> arraybolt3[m]: the question is, do we build *only* for 2006-era x86-64 systems, and hamstring the capabilities of today's brand new processors?
[04:00] <sarnold> arraybolt3[m]: there's a ton of new features on modern processors and we might be able to run faster, more efficiently, more securely, etc, if we built for eg 2015-era processors or 2018-era processors ..
[04:00] <arraybolt3[m]> I don't know if we have the resources to build for older and newer processors. But I desperately hope we don't go the way of Windows 11 and start killing off tons of old hardware.
[04:01] <arraybolt3[m]> We have at least one high-profile Lubuntu tester who runs core2duo and similar hardware as his main machines.
[04:02] <sarnold> heh, that's one way to find pain points quick
[04:04] <arraybolt3> IMO, killing older x64 CPUs was the single worst mistake Microsoft ever made in all of Windows. Even Windows ME was tolerable in comparison. One of my main hopes for Ubuntu is to be able to fill that otherwise vacant niche when Win10 goes EOL. If we follow suit... that will be severely painful for me, who will have to then find a different OS for some of my own machines (one of which is a
[04:04] <arraybolt3> main machine).
[04:05] <sarnold> I suspect you're not alone there
[04:05] <sarnold> will you still feel strongly about it 2024?
[04:05] <sarnold> 2026? 2028?
[04:05] <arraybolt3> Anyway, lol, yeah, now you know my main pain point. :P At any rate, I do see the advantages of building for x86-64-v2 (or even v3+). It would be awesome if we could support all the arches.
[04:06] <sarnold> we just killed off power8!
[04:06] <arraybolt3> sarnold: 2024, almost without question. 2026, probably. 2028? By then my main machine that is still lagging behind will be about 14 or 16 years old, so I guess it would make sense to me by then, though I'd be unhappy.
[04:07] <arraybolt3> (power8 isn't a desktop architecture, you're not killing off vast swaths of consumer hardware by getting rid of it like removing x86-64-v1 would do. People on servers that still use power8 can probably afford to upgrade, and may already have done so.)
[04:08] <sarnold> I'd have stronger opinions if I knew which of mymachines would fall behind the curve, hehe
[04:09] <arraybolt3> Actually, I just looked it up, I misunderstood x86-64-v2. guiverc would probably be unhappy if that fell behind, but I probably could actually live with that. If we were talking x86-64-v3, I can pinpoint at least four systems around here that would be dead wrt Ubuntu if that happened.
[04:11] <arraybolt3> Anyway, I'll calm down. I misunderstood what was happening. :P I should probably Google stuff before getting worked up...
[04:20] <arraybolt3> I'd still prefer to not get rid of core2duo-era hardware, since that kind of hardware is floating around quite a bit, but anyway, I'll stop yammering and get back to bug fixing and other stuff.
[04:24] <murmel> arraybolt3: ms never removed support for the old hardware, as you can circumvent the checks. it's about official support and manufacturers wanting to sell new hw
[04:26] <arraybolt3> murmel: True. I have a lot to say on that topic, but I already said too much over a misunderstanding, so I'll probably keep it out of here (especially since this is the wrong room for my opinions on MS's decisions).
=== ginggs_ is now known as ginggs
[12:54] <ahasenack> hm, what kind of debian versioning scheme is this:
[12:54] <ahasenack> libmemcached | 1.0.18+-1     | unstable        | source
[14:00] <kanashiro[m]> a wrong one :)
[15:45] <enr0n> Can a core dev please retrigger these autopkgtests which are blocking systemd in lunar? retry-autopkgtest-regressions --blocks systemd -s lunar |grep -v prometheus-ipmi-exporter
[15:54] <kanashiro[m]> enr0n: done
[15:54] <enr0n> kanashiro[m]: thanks!
[16:54] <rbasak> Why doesn't anything default to using sensible-editor? For example, git or "lxc edit ...". It means select-editor isn't useful. Am I missing something?
[16:56] <rbasak> Like shouldn't sensible-editor be the highest priority for update-alternatives "editor"?
[16:56] <rbasak> But it doesn't seem to be registered there at all.
[17:16] <ahasenack_> bdmurray: I think you missed jammy in the evince SRU accept (https://launchpad.net/ubuntu/jammy/+queue?queue_state=1&queue_text=evince)
[17:21] <bdmurray> ahasenack_: ack
=== sem2peie- is now known as sem2peie
[19:40] <sarnold> rbasak: because sensible-utils is a debian-specific package -- applications that wanted to work everywhere would just use $EDITOR or $VISUAL and avoid tying themselves to debian and derivatives. if I'm reading this correctly, it didn't really exist in the redhat ecosystem until 2014 https://src.fedoraproject.org/rpms/sensible-utils/blob/epel7/f/sensible-utils.spec
[20:07] <rbasak> sarnold: I think it's been in our required seed since forever
[20:07] <rbasak> I'd have to pull down bzr blame to check exactly when and I can't be bothered right now, but it's in "required" in our platform seed.
[20:08] <rbasak> The package itself first appeared in Karmic in 2013.
[20:08] <rbasak> https://launchpad.net/ubuntu/+source/sensible-utils/0.0.1ubuntu1 suggests that sensible-editor is older than that.
[20:09] <rbasak> In Ubuntu, AFAICT EDITOR and VISUAL remain unset by default.
[20:09] <sarnold> https://launchpad.net/ubuntu/+source/debianutils/+publishinghistory?batch=75&direction=backwards&start=75
[20:09] <rbasak> I don't know what the ecosystem convention is doing when they're unset.
[20:10] <rbasak> But it ends up calling nano, and select-editor doesn't change it.
[20:10] <rbasak> I think everything is going via update-alternatives against /usr/bin/editor, ie. falling back to /usr/bin/editor if EDITOR and VISUAL are unset.
[20:10] <sarnold> I'd expect a lot of programs to do something like char* editor=getenv("VISUAL") || getenv("EDITOR") || "vi";
[20:11] <rbasak> But in that case, shouldn't /usr/bin/sensible-editor be provided as a default (high priority) alternative against /usr/bin/editor?
[20:11] <rbasak> In practice I keep falling into nano and being annoyed. I mean I totally agree with nano being the default on Ubuntu, but also that select-editor should work.
[20:12] <sarnold> hah, I solve that by purging nano the first time I see it
[20:12] <sarnold> I realize that won't work everywhere but it's worked for me so far :)
=== vogelfrei5 is now known as vglfrei_
=== vglfrei_ is now known as vglfrei__
[20:12] <rbasak> I'd like one command to switch my _user_ to vim. select-editor seems like it should be it :)
[20:12] <sarnold> *nod*
[20:14] <vpa1977> I keep falling into nano, typing either `i` or `/`, become confused for a second and then type `:q!` that confuses me even more =)
=== vglfrei__ is now known as xedniv
[20:24] <sarnold> :D