[06:47] <bombastick> Hi. Are there any plans to add a tool to pick a more appropriate apt mirror? Even from a 3rd world country it defaults to the US mirror, and I have to edit sources.list every time. The community has an assortment of unmaintained tools that tried to fill this void (apt-select, apt-smart, apt-mirror-updater, etc). I feel like such a tool should be part of apt itself.
[06:48] <bombastick> I'm also curious why mirrors.txt is not the default apt server. Is it an issue of reliability?
[12:12] <rbasak> Some apt pinning help please. Why is the priority here 501 and not 502? https://pastebin.ubuntu.com/p/ZGXqthszXq/
[12:12] <rbasak> juliank maybe please? ^
[12:15] <juliank> rbasak: the man page lies I guess and the first one wins
[12:16] <juliank> rbasak: well not lies exactly, the priority of the version is the maximum of the priorities of the files it is in, but the paragraph doesn't say how that priority is calculated
[12:19] <juliank> rbasak: so this needs some rewording :(
[12:20] <juliank> quite funny how sources.list and preferences, first match is used; whereas for apt.conf the last one wins :)
[12:24] <rbasak> juliank: even if in the same file it seems to use the first match?
[12:24] <juliank> rbasak: I meant per release file, not per preferences file
[12:25] <juliank> rbasak: like the stanza assigns the pin to the release file essentially
[12:25] <rbasak> Ah
[12:26] <rbasak> So how does the "maximum of all priorities" thing work?
[12:27] <rbasak> Oh, across multiple release files?
[12:27] <juliank> rbasak: Yeah max(pirority(rf) for rf in release files), more or less
[12:27] <rbasak> I think I follow. Thank you!
[12:29] <juliank> basically the paragraph talks about the function that determines the candidate version https://salsa.debian.org/apt-team/apt/-/blob/main/apt-pkg/policy.cc#L144
[12:30] <juliank> no wait
[12:30] <juliank> the GetPriority() function lol
[12:30] <juliank> Things got more complicated when we added the never pinning special handling and the pinning based phasing code
[12:31] <juliank> oh I think there's signed integer downcasts
[12:32] <juliank>    auto ceiling = std::numeric_limits<signed int>::max();
[12:32] <juliank>       return std::min(0, ceiling);
[12:32] <juliank> but return type is signed short :(
[12:32] <juliank> sigh
[12:35] <juliank> I don't think it can ever return ceiling unless ceiling is 1
[12:35] <juliank> *this is fine*
[13:45] <ahasenack> rbasak: hi, do you happen to know of a way to tell git (cli) to show the *revert* of a specific commit?
[13:45] <ahasenack> I have a commit hash, and I want to see the revert, to compare it to a revert patch that someone produced and claims is reverting that commit
[13:47] <rbasak> ahasenack: "git diff HEAD HEAD^" maybe?
[13:47] <rbasak> If you want the inverse?
[13:47] <ahasenack> they come from different repositories
[13:47] <ahasenack> and one is a debian patch
[13:47] <rbasak> Or you could run "git revert" in a different branch or a detached HEAD
[13:47] <rbasak> Sorry I don't think I understand your problem then.
[13:47] <ahasenack> so I want to compare the debian patch, which is reverting commit <foo>, with the revert of commit <foo> in the actual repo
[13:48] <ahasenack> I can run git revert, commit, and then git show that revert, yes
[13:48] <ahasenack> but I was wondering if there was a shortcut to `git show <commit>` to show the revert of <commit> directly
[13:48] <rbasak> Is that not what my git diff command above would do?
[13:49] <rbasak> Replace HEAD with your commit
[13:49] <ahasenack> no, one is a debian patch
[13:49] <ahasenack> the other is a commit to the actual source
[13:49] <rbasak> gbp pq import?
[13:49] <ahasenack> looks like there is no direct way then :)
[13:50] <rbasak> I still don't understsand what you want!
[13:50] <rbasak> You wanted a shortcut to `git show <commit>` to show the inverse, and that's `git diff <commit> <commit>^` except for metadata, no?
[13:51] <ahasenack> ah, replace both HEADs in your previous cmd line
[13:51] <ahasenack> rbasak: that worked, yes, and now in hindsight looks obvious
[13:52] <rbasak> \o/
[13:52] <ahasenack> git diff 1fd96e30f5f8a61d70d51f9012112e01818161a7 1fd96e30f5f8a61d70d51f9012112e01818161a7^
[14:08] <ahasenack> dbungert: well done in untangling ocaml \o/
[14:14] <ahasenack> rust-syscalls seems to be waiting on a test result, I'll check metview
[14:15] <ahasenack> hm, ftbfs
[16:34] <ahasenack> @pilot in
[17:38] <bdmurray> Isn't the installer supposed to select a country appropriate mirror and not US as bombastic mentioned?
[17:48] <dbungert> bdmurray: both subiquity and ubiquity have code along these lines, but I can't speak to if ubiquity is dtrt.  For Subiquity, if the geoip results didn't work you'd default to the main archive.
[20:43] <bluca> is the autopkgtest for jammy/amd64 clogged? https://autopkgtest.ubuntu.com/running#pkg-systemd-upstream shows jobs queued since early this morning
[20:47] <bluca> bdmurray: ^^
[20:53] <bdmurray> bluca: All of amd64 is clogged - I'm investigating
[20:53] <bluca> thanks, just wanted to check that it wasn't specific to the systemd jobs
[21:35] <ahasenack> @pilot out