20:00:34 <waldi> #startmeeting
20:00:34 <MeetBot> Meeting started Wed Nov 27 20:00:34 2024 UTC.  The chair is waldi. Information about MeetBot at http://wiki.debian.org/MeetBot.
20:00:34 <MeetBot> Useful Commands: #action #agreed #help #info #idea #link #topic.
20:00:41 <bwh> Hi
20:00:43 <waldi> #chair carnil bwh
20:00:43 <MeetBot> Current chairs: bwh carnil waldi
20:00:50 <carnil> \o
20:00:50 <waldi> welcome to todays meeting
20:00:52 <carnil> hello
20:01:03 <eamanu> hello!
20:01:13 <santiago> hi!
20:01:19 <waldi> let's start
20:01:31 * ukleinek looks at eamanu and santiago
20:01:33 <waldi> #topic Linux live-patching support in Debian
20:01:43 <waldi> eamanu, santiago: please
20:02:18 <santiago> waldi, thanks
20:02:42 <santiago> as we have mentioned, we are willing to work on introducing support for kernel live-patching
20:03:03 <santiago> there have been a couple of presentations about the idea, in debconf and in the last minidebconf
20:03:27 <ukleinek> santiago: I think the thing that interest me most: What is the impact on the kernel team. I guess we have to enable a few kconfig items?
20:03:31 <santiago> for now, we are looking for a place where to discuss about the design+development+etc
20:03:59 * ukleinek would think this irc channel and the d-kernel list is suiteable
20:04:08 <waldi> what parts exist and what parts needs development?
20:04:43 <santiago> regarding the kconfigs, I think there is nothing needed right now
20:05:45 <santiago> the PoCs that rely on kpatch "just work", without modifying the existing kernel config
20:06:19 <waldi> you talk about "central service and distribute them to the users"? this is the security archive, right?
20:07:18 <santiago> that said, we have an issue about the config to generate the modules, but I need to dig it further, and we can share details ASAP
20:07:45 <santiago> waldi, mmm, nop, we don't plan to rely on the security archive to distributed the modules
20:08:45 <bwh> What is it that you expect from us?
20:08:45 <ukleinek> But the plan is to provide kpatches for the official security updates, right?
20:09:49 <santiago> ukleinek, yes, for the offical security updates, but on a separate and specific "archive". we don't plan to distributed the as .debs
20:12:44 * ukleinek has the impression we're not in the way of each other but still it would be good to have some visibility of each other
20:13:10 <ukleinek> santiago: Did you see bwh's question?
20:13:41 <carnil> I thus think it would be perfectly fine to have the discussions on our mailinglist and in this IRC channel, they should not interfer or cause hassle. (so this for my point of view on santiagos quesiton for a home of the project)
20:13:49 <santiago> (sorry, I am having some network issues)
20:14:05 <santiago> bwh, right now, your agreement (or not) to use this channel and the mailing list :-)  it is verly likely that we will face questions during the development, and we will give you some visibility about what we plan to do
20:14:25 <ukleinek> santiago: My expection would be for you to be ready to assist with bug reports against src:linux with the live-patch-taint
20:15:01 <bwh> santiago: So long as we don't get overwhelmed with live patching conversations, I think it's fine to use these channels
20:15:24 <santiago> ukleinek, sure
20:15:43 <santiago> bwh, and in that case, we can create a separate channel
20:15:43 <santiago> and mailing list
20:15:47 <ukleinek> sounds good. Let's start with #d-kernel and d-kernel@l.d.o and if it should get unconfortable we reconsider.
20:16:04 <santiago> great!
20:17:29 <santiago> so for the moment, I think that is good enough
20:17:51 <carnil> perfect, welcome on board ;-)
20:19:02 * ukleinek nods and suggest to progress to the next agenda item
20:19:20 <ukleinek> santiago, eamanu: Thanks for your effort and cooperation
20:19:32 <waldi> just a remark: i would say that chaining such modules to the debian secure boot ca would be inappropriate, due to the different maintenance levels. but this will be not possible anyway, as signing this way requires security archive
20:20:00 <waldi> anything further on this topic?
20:20:22 <eamanu> not from my side :-)
20:20:55 <waldi> #topic #1087807
20:21:01 <waldi> no news from my side
20:21:14 <santiago> I had missed waldi's question. Amost everything is to be developed. What we have done are PoC of using kpatch to build livepatch modules, and dicussions about the livepatch packages format
20:21:20 <santiago> and that's all from my side too
20:21:45 <ukleinek> waldi: do you understand the problem? I didn't look.
20:22:07 <bwh> I don't know what's changed, but it looks like we have a jumbo packet that for some reason is not page-fragmented
20:22:37 <bwh> ...and so it doesn't fit into swiotlb buffers, and then something failed to handle the error
20:23:04 <ukleinek> do we need a bisect?
20:23:54 <bwh> There are some backported commits  with "xen/swiotlb" in the subject which are possibly related
20:24:28 <ukleinek> in the stable queue?
20:24:47 <bwh> no, between the last good and broken versions (6.1.112 and 6.1.115)
20:25:14 <ukleinek> ah, so possibly bad ones, not fixes
20:25:53 <bwh> So, I guess I should take an action to look at this a bit further (and probably forward upstream)
20:26:24 <waldi> okay. thx
20:26:36 <waldi> #action bwh to look at #1087807
20:26:39 * carnil cancels what he was writing
20:26:51 <ukleinek> 1bd4e5a74da9855af7a9c4a0ad9c715fe05a148f looks suspicious
20:28:57 <waldi> #topic #1076372
20:29:30 <ukleinek> I think nothing new here as with the bug you skipped.
20:31:07 <bwh> Well there were some more results posted yesterday. I guess we can forward the Lexar issue upstream at least...?
20:31:55 <ukleinek> carnil asked the reporter to do that, if we want to push that we should at least coordinate with them to not duplicate efforts
20:32:04 <bwh> OK
20:34:09 <bwh> waldi?
20:34:11 <waldi> #topic #1087616
20:34:39 <ukleinek> Ther was no action for #1076372 now, do we just wait a bit?
20:34:51 <carnil> I have two laptops which I sucessfully booted with several 6.11.y versions with at least the update of systemd inbeween which reporterss seem to indicate might influence the outcome
20:35:03 <carnil> the original reporter has in meanwihile a broken disk, so cannot do further tests
20:35:16 <carnil> but there are othe people which report they have the same issue
20:36:02 <ukleinek> maybe sysrq would give a nice indication?
20:37:15 <bwh> Would it make sense to add "debug" to the boot parameters? Or "-- debug" if we think it's actually systemd at fault?
20:38:04 * ukleinek nods
20:38:40 <carnil> yes make sense
20:39:40 <waldi> who wants to take this?
20:40:12 <carnil> aimed to get a boot log remotely at least from the reporter via netconsole, but did not mention to make the boot not quiet (in case it is) and adding debug we hopefully get enough information
20:40:40 <carnil> waldi: you can add an action for me
20:41:00 <waldi> #action carnil to respond to #1087616
20:41:18 <waldi> #topic #1087980
20:41:37 <bwh> Well this is bullseye so I think it's for me to handle
20:42:04 <waldi> #action bwh to respond to #1087980
20:42:41 * ukleinek adds some metadata
20:43:08 <waldi> anything else?
20:43:21 <waldi> #topic #1086520
20:43:40 <ukleinek> seems to be in good hands with upstream
20:43:51 <waldi> yes. so nothing to do right now
20:43:59 <ukleinek> ack
20:44:08 <bwh> agreed
20:44:21 <waldi> #topic #1087667
20:44:32 <waldi> ukleinek already answered
20:45:20 <waldi> #topic 1087940
20:45:24 <waldi> #topic #1087940
20:45:46 <waldi> reported as fixed in 6.11.10
20:46:16 <waldi> #action waldi to close #1087940
20:46:40 <waldi> #topic #1087981
20:47:16 <carnil> might have been related to the issues which are fixed in 6.1.119-1, asked the reporter already if he can re-test
20:47:41 <waldi> okay. so nothing to do
20:48:03 <ukleinek> #1088153 is also about being slow
20:48:20 <waldi> #topic #1088153
20:48:24 <ukleinek> (but havn't checked affected kernel version)
20:48:42 <carnil> yes but not related to the version in stable
20:48:46 <carnil> was reported for 6.11.9
20:49:45 <bwh> My guess is that #1088153 is either due to broken feature detection, or due to our not linking certain libraries because of license incompatibility
20:49:53 <bwh> I didn't investigate yet
20:50:44 <bwh> Or possibly the addr2line fallback regressed and is now spawning multiple processes rather than keeping one around and piping to and from it
20:51:03 <bwh> I suppose I should take this one
20:51:21 <waldi> #action bwh to investigate into #1088153
20:51:47 <waldi> #topic AOB
20:51:59 <waldi> we are almost out of time. anything you want to talk about still?
20:52:15 <bwh> I think we need to make contact with Greg and the RT people about 6.12 support lifetime
20:52:52 <bwh> Unless we are too late for that
20:53:18 <waldi> what do you mean with "too late"?
20:53:18 <ukleinek> has the rt patch for 6.12 still a relevant size?
20:53:50 <bwh> waldi: Well the stable-rt maintainers said they would not extend the lifetime once they'd announced it
20:54:29 <bwh> ukleinek: There are still some patches for arm (32-bit) and x86
20:54:43 <ukleinek> yeah, also a bit of powerpc
20:55:29 <bwh> But we don't build it for powerpc :-)
20:56:27 <ukleinek> While looking over todays agenda and comparing it to last weeks I wonder which bugs make it to the agenda and if we miss followups from one week to the next.
20:56:36 <bwh> but I take your point that there's less of a concern about RT maintenance if it's essentially all upstream
20:57:39 <bwh> The selection is: (bug is open) && ((severity is RC) || (bug was updated in last 7 days))
20:58:29 <bwh> So, we don't go back to bugs that we miss talking about, but those will be of lower severity
20:58:37 <ukleinek> Today we skipped over some of these bugs, so there is no time to talk about still more bugs in the same timeframe.
20:59:00 <ukleinek> That would either require more time, or better preparation
20:59:20 <waldi> one last point: who will be chairing next week?
20:59:30 <bwh> I think it's my turn?
21:00:09 <ukleinek> Do you consider the status column for the bug list useful? It's some effort to prepare that, but if it speeds up the meeting it's well invested?!
21:00:25 <waldi> #action bwh to chair next weeks meeting
21:00:27 <carnil> for fairness: or we swap, because I will likely not be available in 2 weeks. But if you are okay with me skipping possibly once chairing then bwh yes please
21:01:04 <bwh> ukleinek: That is helpful, yes
21:01:15 <waldi> thanks all for coming
21:01:25 <carnil> thanks waldi for chairing
21:01:26 <waldi> #endmeeting