20:00:04 <carnil> #startmeeting
20:00:04 <MeetBot> Meeting started Wed Nov 13 20:00:04 2024 UTC.  The chair is carnil. Information about MeetBot at http://wiki.debian.org/MeetBot.
20:00:04 <MeetBot> Useful Commands: #action #agreed #help #info #idea #link #topic.
20:00:11 <carnil> #chair waldi bwh
20:00:11 <MeetBot> Current chairs: bwh carnil waldi
20:00:23 <carnil> Hello, welcome to today kernel team meeting
20:00:25 <ukleinek> hmm, irc only today?
20:00:36 <waldi> i'm here
20:00:44 <carnil> ukleinek: IRC only today, it is alternating between IRC and Jitsi
20:01:07 <carnil> and we try to not forget which one will be on the respective agenda page
20:01:07 * ukleinek opens https://salsa.debian.org/kernel-team/meetings/-/wikis/20241113
20:01:12 <bwh> Hello
20:01:41 <carnil> apart the regular agenda points I have added two "info gathering" items as well
20:01:51 <carnil> #topic Followup work and plans after linux packaging repo migrating to new branch layout
20:02:36 <carnil> First of all, thanks to waldi implementing the discussed change in the linux packaging repo. It looks things have worked, and there was a experimental upload from bwh based on the debian/latest branch , and a unstable upload on top of the debian/6.11/trixie branch.
20:02:49 <carnil> Existing merge requests have been updated by waldi as well
20:03:09 <carnil> and there is a MR for the d-k-prerelease and d-k-tag tools in https://salsa.debian.org/kernel-team/kernel-team/-/merge_requests/6
20:03:33 <carnil> I had not yet time to look at those, but is at least one missing bit yet which we need to handle to make things smooth to work on
20:03:38 <bwh> We currently have a mixture of branch naming conventions across our other package repos. We didn't discuss this before but I was always intending to move them to DEP-14 branch names
20:04:58 <carnil> This, right is one of the items which opened now and we can at least get some imput from the team on where we want to go.
20:05:15 <carnil> I woul be in favour that we try to align those asap in the other packaging repositories as well
20:05:42 <carnil> though not forgetting to focus on toward the freeze for trixie ;-)
20:06:26 <carnil> Do we have other work which we forgot about as followup of the new branch layout namings?
20:07:01 <ukleinek> Where can I read about the motivation behind the branch rename?
20:07:06 <bwh> I think you had some concerns about updating the status of sid in kernel-sec
20:09:09 <carnil> bwh: correct, I can summarize: in kernel-sec we track for the sid field, the first version of an unstable upload which contained a specific fix. I have not yet a complete idea and might be wrong, but I think we loose an easy way to track this information with the new layout, given once 6.12 moves to unstable, we branch of a debian/6.12/trixie branch from debian/latest and forget in the history about
20:09:15 <carnil> the changes done in debian/6.11/trixie (which might have already contained a specific commit and fix for a CVE)
20:09:18 <carnil> I'm not sure how we can deal with that
20:09:57 <ukleinek> would it make sense to merge debian/6.11/trixie into debian/6.12/trixie (maybe with -s ours)?
20:10:31 <bwh> What problem does that solve?
20:10:43 <ukleinek> the "forget" part
20:11:06 <ukleinek> (but take my suggestion with a grain of salt as I don't understand the new scheme yet)
20:11:33 <bwh> Well it doesn't ensure that a security fix applied to 6.11 actually is present in the 6.12 branch
20:12:22 <waldi> carnil: if you store that information, where do you want to track it?
20:13:07 <bwh> I really need to prioritise finishing the work I did to (more) automatically update status in kernel-sec
20:15:32 <bwh> Are we in agreement to merge the changes to scripts?
20:16:11 <carnil> waldi: maybe I get things wrong (as said, I'm not yet too fluent working iwth the new layout), but in the previous case I had in sid branch all the tags in the history which ever hit unstable, with the new one in debian/6.12/trixie I would not have those tagged versions released after the debian/6.11/trixie branch off. This information is then used in the
20:16:16 <carnil> https://salsa.debian.org/kernel-team/kernel-sec/-/blob/master/active/00boilerplate#L11 sid field
20:17:03 <carnil> bwh: about automating changes, my own very hackisch and depending on local checkouts scriipts seem to work quite good in recent updates, but I would defintively welcome if we get it properly done with your python variants in kernel sec, so ack :)
20:17:38 <carnil> bwh: Are we in agreement to merge the changes to scripts? <- is this relating to https://salsa.debian.org/kernel-team/kernel-team/-/merge_requests/6 ?
20:18:01 <bwh> yes
20:18:08 <waldi> carnil: then i don't know what you mean. because at any one point only one branch is active and references all the tags
20:19:15 <carnil> bwh: if you are fine with the changes and modulo the pending requested change is done, then let's go ahead
20:19:23 <bwh> Right
20:20:16 <bwh> It seems like maybe we should track latest in kernel-sec, and then we can copy that status to x.y-unstable (or whatever) when uploading to unstable
20:22:03 <carnil> bwh: yes that maybe could work that we switch to a new format which is more inline with our branching layout and track debian/latest additionally and when they exist a x.y-unstable: version
20:22:27 <carnil> okay this gave I guess some ideas to think about, which we can ponder on
20:22:40 <carnil> switch to the next topic?
20:22:48 <bwh> Yes please
20:23:22 <carnil> #topic Question on debugfs mounts on debian-security mailinglists
20:23:34 <carnil> We had on debian-security the following question:
20:23:41 <carnil> https://lists.debian.org/debian-security/2024/11/msg00018.html
20:24:13 * ukleinek doesn't have security concerns as it's only accessible by root IIRC.
20:24:14 <carnil> about mounting debugfs by default (non systemd init notabene) when supported by kernel
20:24:28 <bwh> It is mounted by default, and restricted to root
20:24:32 <bwh> I don't see a problem
20:24:38 <carnil> systemd seems to do that already, so does have anyone enought ensights in debugfs to answer the question there?
20:24:42 <waldi> me neither
20:24:47 <ukleinek> non systemd init because systemd automounts it even when not listed in fstab?
20:25:24 <ukleinek> you could argue that it takes some memory (but I'm not sure if this is relevantly more than with it unmounted)
20:25:33 <bwh> I also don't care what initscripts does, it's irrelevant to Debian default behaviour
20:26:05 <ukleinek> +1 for being not very interesting
20:26:10 <ukleinek> question
20:26:34 <carnil> so I hear nobody has concerns aout debugsfs beeing mounted by default in non-systemd inits as well, and will reply that to the list
20:26:47 <carnil> #topic #1063754 - fat-modules: SD corruption upon opening file on Linux desktop
20:26:56 <carnil> AFAIK no news on that front, correct?
20:27:02 <ukleinek> we intended to wait on that IIRC?
20:27:37 <KGB> 03linux 05debian/latest 06Johannes Schauer Marin Rodrigues * [close] merge request !1258: Draft: Fix FTCBFS amd64->arm64 by not setting KBUILD_HOSTCFLAGS * 14https://salsa.debian.org/kernel-team/linux/-/merge_requests/1258
20:27:51 <bwh> I was hoping to come up with a policy for how long we keep bugs open in moreinro+unreproducible state
20:28:02 <carnil> ukleinek: there were some doubts on on which suites there is actually a problem
20:28:51 <bwh> Did I have an action to ask about that? In any case I haven't touched it yet
20:29:43 <carnil> bwh: from memory I think we said to wait until the next bullseye-security upload, ask the reporter to retest with that version, and explicitly say if it's a problem with the latest 5.10.y upload and then close if nothing comes back
20:29:56 <bwh> Ah yes, that was it
20:30:07 <carnil> but we indeed have bugs in moreinfo+unreproducible which we might go ahead and close and do some BTS housekeeping
20:30:16 <carnil> so we wait here
20:30:21 <ukleinek> yeah, noone was assigned an action on that one last week
20:31:02 <carnil> ukleinek: well implicitly on bwh after the next bullseye-security upload
20:31:06 <carnil> #topic #1076372 Corruption of Longsys/Lexar NM790 NVMe drive with Linux 6.5+
20:31:14 <carnil> no news from reporter
20:31:29 <carnil> #topic #1069301 - linux-image-6.1.0-20-amd64: bluetooth causes kernel BUG - list_del corruption, (address)->prev is LIST_POISON2
20:31:35 <carnil> Status update:
20:32:02 <carnil> there is some progress now. Greg has a series of reverts for the 6.1.y branch which he will queue after the 6.1.117 release for review
20:32:26 <carnil> I hope we can have the people having he problem explicitly test those reverts and report back in time before the 6.1.118 release then
20:32:39 <carnil> I can take an action here to ping the people once the patches are out for review
20:32:47 <ukleinek> sounds great
20:32:49 <bwh> Thank you
20:33:05 <carnil> #action carnil pings affected users of #1069301 to test the series of reverts once they are out for review for 6.1.118
20:33:20 <carnil> #topic #1086793 - linux-image-6.10.11-amd64: Wifi not working with kernel 6.11 (working with 6.10)
20:33:23 <ukleinek> #1086447 is solved for the reporter. I didn't close because I was unsure how (reassign to firmware-iwlwifi?) and wondered if there is a way to prevent such problems. (OTOH there are loud warnings when the initramfs is generated?!)
20:33:48 <ukleinek> s/1086447/1086793/
20:33:55 <carnil> thank you ukleinek
20:34:24 <carnil> ukleinek: I think we should reassign it to src:firmware-nonfree  and close it then with the fixing version identified.
20:34:59 <ukleinek> if that's the agreed on action, I can take care for that
20:35:16 <bwh> Sounds right to me
20:35:53 * ukleinek nods, next!
20:36:04 <carnil> #action ukleinek reassigns 1086793 to src:firmware-nonfree and closes it with the fixing version
20:36:18 <carnil> #topic #1085762 -  linux-image-6.1.0-26-amd64: Random crashes during pbuilder compile runs
20:36:45 <carnil> bwh: we had an action here from last week, that you might be able to ask some relevant questions to narrow down more on the environment of the reporter
20:37:12 <carnil> do you have capacity for it in this week to see if we get more information on the issue?
20:37:22 <carnil> alternatively was anybody able to reproduce the issue?
20:37:34 <bwh> I am quite busy until at least Monday
20:38:26 <ukleinek> I can ask the reporter to reproduce without the vbox stuff
20:38:37 <bwh> I think the second message from the reporter answers the questions we had anyway
20:39:13 <bwh> ukleinek: Sure
20:39:27 <carnil> thanks
20:40:13 <carnil> #action ukleinek will ask reporter for #1085762 about to reproduce issue without vbox stuff loaded and running
20:40:14 <ukleinek> so he compiles ARM stuff on amd64, either using cross compiling or in a virtual arm machine
20:41:04 <bwh> Can we move on?
20:41:34 <carnil> I skip the next bug, is waiting for moreinfo
20:41:42 <carnil> #topic #1086638 - linux-image-6.11.5: usbguard-daemon invalid opcode: 0000, usb's not usable
20:42:18 <carnil> need some helping hands here, I did run out of time for kernel-team work and reporter has provided additional information on reproducing the issue as followup on what we agreed on last time
20:42:34 <carnil> I would appreicate if someone can jump on the train and have a look as well at the followups
20:43:25 <bwh> I think this bug report has been well and truly derailed
20:45:11 <bwh> I could have a look through the logs but can't promise to do that soon
20:45:13 <carnil> Have I asked the wrong question and is there anything which could help bringing it back on track?
20:45:38 <carnil> should we postpone it to the next meeting and have a look then again?
20:45:39 * ukleinek only sees good intentions
20:46:48 <bwh> ukleinek: Yes I don't mean deliberate derailing, but I see the submitter starting to notice a lot of (probably unrelated) problems with their nvidia driver
20:47:06 <bwh> carnil: OK
20:47:27 * ukleinek nods. good intentions sometimes is the counterpart to good
20:47:32 <carnil> so not specific action, if someone has time look through the backlog of the bug
20:47:46 <carnil> #topic #1038313 - acpi: mensage on boot: acpi bios error, pci0, acpi not found, x509 and sgx error
20:48:28 <carnil> no idea here, but given it was a report for under 6.1.25 I'm tempted to just close the bug *but* ask if it's still aproblem with the current version and then reopen accordingly.
20:49:31 <bwh> Two things to include: (1) we need an actual boot log (2) turning off ACPI is a terrible diea
20:50:05 <bwh> I suspect these are actually just common complaints from the kernel about broken firmware
20:50:34 * ukleinek also has a metric ton of ACPI warnings at boot, and the machine works fine.
20:51:04 <ukleinek> +1 on what bwh said
20:51:53 <carnil> so expand the action: close bug, ask if reporters still thinks to a problem with current version and reopen the bugreport but provide actual boot logs.
20:52:08 * ukleinek fixed the typo in the bug title
20:52:41 <carnil> this is easy action, I can take it and do it just later
20:52:51 <carnil> so, out of time
20:52:56 <carnil> #topic AOB
20:53:06 <carnil> anything for the last minutes?
20:53:15 <waldi> not from me
20:54:01 <bwh> Well we have to respond to the live patching questions
20:54:09 <ukleinek> I saw a MR about repairing cross compilation. Did someone notice an issue there?
20:54:49 <bwh> Yes objtool was still slightly broken
20:55:07 <carnil> bwh: suggest we try to have a look at the next meeting as agenda point fo the livepatching questions (if that's not too late to have deferred by one week)
20:55:17 <bwh> carnil: Yes I think that's fine
20:55:35 <ukleinek> the livepatching thread is on d-kernel?
20:55:47 <bwh> yes
20:56:02 <carnil> ukleinek: https://lists.debian.org/debian-kernel/2024/11/msg00116.html
20:56:02 * ukleinek notes to read that for next week.
20:56:27 <waldi> "secure boot support", well, non with a debian key
20:56:27 <carnil> okay next meeting, on Jitsi, who wants to chair it?
20:57:11 <waldi> it should be my turn. or would ukleinek try his hand?
20:57:29 * ukleinek checks calendar, should be fine.
20:57:43 <ukleinek> What is to be done? Prepare the agenda and lead through the meeting?
20:57:47 <carnil> awesome if we have a new person in the turnus :)
20:57:54 <waldi> ukleinek: exactly
20:58:02 <ukleinek> ok, I'll try.
20:58:03 <carnil> ukleinek: prepare the agenda, send a reminder (asking for additional points) + leading through the meeting
20:58:07 <carnil> perfect :)
20:58:44 <carnil> #agreed ukleinek be the chair for next kernel-team meeting on 2024-11-20
20:58:47 <carnil> :)
20:58:56 <carnil> thanks a lot to all for partecipating
20:59:10 <carnil> and providng input to various topics
20:59:13 <bwh> Thanks for chairing
20:59:25 <carnil> #endmeeting