[09:26] <trippeh> now that the noble repos have been rolled back - will the t64 transition still happen for 24.04?
[09:31] <juliank> trippeh: the noble repos have not been rolled back and the transition already happened.
[09:32] <juliank> trippeh: only the amd64 binaries were rolled back
[09:32] <juliank> by removing them from the release pocket, copying in the old ones into -updates, and then doing no-change rebuilds uploads for the already-transitioned packages in release to proposed
[09:33] <juliank> From the perspective of armhf, which is the only t64 transitioner so to speak, it's a non-event
[09:36] <trippeh> right. so if I wait a few days the t64 lib packages on amd64 will come back?
[09:40] <juliank> sure
[09:40] <juliank> they should all be there in proposed
[09:41] <trippeh> ack
[10:13] <rbasak> cpaelzer_: the MIR request should be for bpfcc-tools please. I've explained in https://bugs.launchpad.net/ubuntu/+source/bpfcc/+bug/2052813/comments/19
[10:13] -ubottu:#ubuntu-devel- Launchpad bug 2052813 in bpfcc (Ubuntu) "[MIR] bpfcc" [Undecided, Incomplete]
[11:01] <rbasak> s/MIR request/MIR/
[11:38] <mwhudson> jbicha: i have no impulse control, i think this might fix the folks build https://paste.ubuntu.com/p/5DjxGx6x4P/
[11:39] <mwhudson> heh well not completely
[13:35] <Trevinho> vorlon: Hey are we getting https://salsa.debian.org/ssh-team/openssh/-/commit/f01545e3f9350c080a525c246b9d46ba71cb0d09 in ubuntu too?
[13:35] -ubottu:#ubuntu-devel- Commit f01545e in ssh-team/openssh "Support systemd socket activation"
[13:38] <ogra_> Trevinho, dont we have that since jammy already ?
[13:38] <ogra_> ah, not jammy ...
[13:38] <Trevinho> ogra_: It's the refactor not to use libsystemd... as per the xz backdoor. Indeed it's not a problem anymore, but it implies way less deps
[13:38] <ogra_> https://discourse.ubuntu.com/t/sshd-now-uses-socket-based-activation-ubuntu-22-10-and-later/30189
[13:39] <cjwatson> right, the refactor only happened this week
[13:39] <cjwatson> just a confusing commit reference
[13:39] <Trevinho> Sorry, I posted the wrong link
[13:39] <Trevinho> yes
[13:39] <Trevinho> I meant https://salsa.debian.org/ssh-team/openssh/-/commit/cc5f37cb8405cba624a133f4b8f464fbe381c5c8
[13:39] -ubottu:#ubuntu-devel- Commit cc5f37c in ssh-team/openssh "Avoid linking against libsystemd"
[13:43] <cjwatson> Just bear in mind it's new and only relatively lightly tested.
[14:08] <Trevinho> cjwatson yeah, that's clear... But code is basically the same that is inside libsystemd so I don't expect many surprises.
[14:29] <enr0n> Trevinho: I was just gonna wait until next cycle to do the merge. It's been an on-going effort to re-align Ubuntu's socket activation patches with Debian
[14:51] <Trevinho> enr0n I see, however for this specific change I've prepared it in https://code.launchpad.net/~3v1n0/ubuntu/+source/openssh/+git/openssh/+merge/463604
[14:56] <cjwatson> Trevinho: that drops some Ubuntu changes to the socket activation patch that haven't been merged yet.  compare https://salsa.debian.org/ssh-team/openssh/-/merge_requests/23
[14:56] -ubottu:#ubuntu-devel- Merge 23 in ssh-team/openssh "Enable ssh.socket by default and add a systemd generator to configure ListenStream= based on /etc/sshd_config entries" [Opened]
[14:56] <cjwatson> that's part of why I was saying it needed a somewhat careful merge
[14:56] <cjwatson> Trevinho: and you no longer need --with-systemd*
[14:57] <Trevinho> cjwatson: Yeah, I noticed... I was about to consider including such changes too
[14:58] <cjwatson> (I don't mean all of !23, it's just that your patch actually drops the bits of systemd-socket-activation.patch that were different in Ubuntu
[14:58] <cjwatson> )
[15:20] <adrien> cpaelzer: you mention using memory tests in the MIR for libtracefs ( https://bugs.launchpad.net/ubuntu/+source/libtracefs/+bug/2051925/comments/3 ) but I can't find this in the MIR documents
[15:20] -ubottu:#ubuntu-devel- Launchpad bug 2051925 in libtracefs (Ubuntu) "[MIR] promote libtracefs as a trace-cmd dependency" [Undecided, Incomplete]
[15:21] <adrien> is it maybe some older template?
[15:50] <Trevinho> enr0n: that's fixed now, I didn't notice the delta initially as the debian side contained the original patch from Steve and I thought they were matching... But the diff in lp looked too big indeed, so that's fixed now and re-tested.
[15:55] <Trevinho> cjwatson: sure thing, I didn't notice initially there was an extra delta; as at first I had worked only on the ubuntu side of things, then seeing the debian side I thought they were using the same patches. But the final diff made it clearer it was not the case.
[16:08] <cjwatson> Thanks.  Not an exhaustive review, but I've left a few comments.
[16:09] <cjwatson> Hm, possibly on a slightly older version - you might need to click "Show diff comments" on my comment to see them.
[16:35] <Trevinho> cjwatson: Yeah, thanks I had re-pushed since I noticed I forgot to remove the `--with-systemd` (weird, since I thought I did on first version... but since you noticed early maybe I didn't)
[16:36] <Trevinho> cjwatson: however I dropped also the other `--with-*` as you suggested, the reason i was keeping them was to make things more explicit, but I guess it's not needed
[16:36] <cjwatson> They're still there though?
[16:42] <bluca> cjwatson: I want to send you a MR for openssh on salsa, but I can't figure out the git-dpm incantation... any chance you can provide some pointers? have a git commit to apply as a patch
[16:42] <Trevinho> cjwatson: No... Unless you checked a previous version?
[16:42] <bluca> the command man/help is not helpful, and I can't see a debian/README.source or so
[16:43] <cjwatson> Trevinho: ugh, sorry, I needed to shift-reload
[16:44] <cjwatson> bluca: in general: "git-dpm co" to switch to the patched branch, "git commit" or "git rebase -i upstream" or otherwise manipulate the patch queue relative to upstream, "git-dpm up" to switch back to the packaging branch with the new patched branch merged
[16:45] <cjwatson> (sometimes "git-dpm up --amend" if you have to go through the cycle a few times)
[16:46] <Trevinho> cjwatson: as I mentioned, indentation should be fixed too, but I preferred not to do it here, while I left a comment in the debian side to remember it at reconciliation time.
[16:46] <bluca> thank you!
[16:46] <cjwatson> Trevinho: I didn't notice anything wrong with indentation, but I was just looking at it in the browser
[16:47] <Trevinho> cjwatson I was also thinking... Maybe it would be sane to have a compile-time only dependency on libsystemd to get the value of `SD_LISTEN_FDS_START` so that we don't have to hardcode it?
[16:47] <cjwatson> Trevinho: I guess we _could_, but 3 doesn't seem bad as hardcodings go
[16:47] <cjwatson> not sure that's worth a whole build-dep
[16:47] <cjwatson> I don't think that's any worse than the rest of the inlining really
[16:47] <Trevinho> cjwatson: My fear is if that changes...
[16:48] <cjwatson> I think it's part of the protocol in the same way that the rest of the inlined code is
[16:48] <Trevinho> upstream code has even `assert_cc(SD_LISTEN_FDS_START < INT_MAX);` which seems even too cautious for something that is 3 now...
[16:49] <cjwatson> https://systemd.io/PORTABILITY_AND_STABILITY/ says that it's covered by the interface stability promise, linking to https://www.freedesktop.org/software/systemd/man/latest/sd_listen_fds.html which specifically says it's 3
[16:49] <cjwatson> so I'm not worried about it
[16:50] <Trevinho> ok, fair enough... also still getting it from header wouldn't make it saner when it comes to have mismatching versions (if that would have changed)
[16:50] <cjwatson> and I don't want to have a #include for this, because I want to be able to send this patch upstream once we reconcile things, and I guarantee you they'll reject it if the #include is there
[16:50] <Trevinho> indeed
[16:51] <bluca> --> https://salsa.debian.org/ssh-team/openssh/-/merge_requests/25
[16:51] -ubottu:#ubuntu-devel- Merge 25 in ssh-team/openssh "Only set PAM_RHOST if the remote host is not 'UNKNOWN'" [Opened]
[16:51] <bluca> would be good to have that in ubuntu too btw
[17:17] <enr0n> bluca: if you create a quick bug report explaining it I can take a look at including it in the next openssh upload
[17:17] <enr0n> (or point me to the bug if there already is one)
[17:18] <bluca> can do that
[17:24] <bluca> https://bugs.launchpad.net/ubuntu/+source/openssh/+bug/2060150
[17:24] -ubottu:#ubuntu-devel- Launchpad bug 2060150 in openssh (Ubuntu) "openssh sets PAM_RHOST to UNKNOWN causing slow logins" [Undecided, New]
[17:26] <enr0n> bluca: thanks!
[20:55] <mwhudson> is there a way to disable the log filtering sbuild does?
[20:55] <mwhudson> i mean the "I: NOTICE: Log filtering will replace 'build/folks-RHx64z/folks-0.15.9' with '<<PKGBUILDDIR>>'" stuff
[21:28] <sergiodj> mwhudson: unfortunately not
[21:31] <mwhudson> jbicha: does that "gimp crashes on closing a window" affect us too?
[21:31] <sergiodj> mwhudson: ah, there actually _is_: LOG_FILTER
[21:31] <jbicha> mwhudson: probably, I put it on my backlog to look later
[21:32] <mwhudson> sergiodj: huh how did i not find that!
[21:32] <sergiodj> its buried inside sbuild.conf(5)
[21:34] <mwhudson> sergiodj: ah so no command line for it? sad
[21:34] <sergiodj> yeah, that's a bummer
[21:51] <john-cabaj> Does pbuilder (or pbuilder-dist for that matter) support creating noble chroots yet?
[22:06] <vorlon> john-cabaj: sbuild is the recommended tool; does the kernel team standardize on pbuilder instead for some reason? (sbuild is in main, pbuilder is in universe)
[22:06] <vorlon> john-cabaj: creating noble chroots at the moment is dicey however, things are in flux due to xz-utils
[22:10] <john-cabaj> Yeah, I was wondering if the xz issue could be holding things up in tooling.
[22:11] <john-cabaj> I see pbuilder-dist referenced quite a bit, and wanted to try that. If sbuild accomplishes the same thing, I'll go that route.
[22:14] <jbicha> john-cabaj: a lot of docs are out of date, most people use sbuild these days
[22:14] <john-cabaj> Ack. Will give that a shot, thanks all