20:00:04 #startmeeting 20:00:04 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 Useful Commands: #action #agreed #help #info #idea #link #topic. 20:00:11 #chair waldi bwh 20:00:11 Current chairs: bwh carnil waldi 20:00:23 Hello, welcome to today kernel team meeting 20:00:25 hmm, irc only today? 20:00:36 i'm here 20:00:44 ukleinek: IRC only today, it is alternating between IRC and Jitsi 20:01:07 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 Hello 20:01:41 apart the regular agenda points I have added two "info gathering" items as well 20:01:51 #topic Followup work and plans after linux packaging repo migrating to new branch layout 20:02:36 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 Existing merge requests have been updated by waldi as well 20:03:09 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 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 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 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 I woul be in favour that we try to align those asap in the other packaging repositories as well 20:05:42 though not forgetting to focus on toward the freeze for trixie ;-) 20:06:26 Do we have other work which we forgot about as followup of the new branch layout namings? 20:07:01 Where can I read about the motivation behind the branch rename? 20:07:06 I think you had some concerns about updating the status of sid in kernel-sec 20:09:09 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 the changes done in debian/6.11/trixie (which might have already contained a specific commit and fix for a CVE) 20:09:18 I'm not sure how we can deal with that 20:09:57 would it make sense to merge debian/6.11/trixie into debian/6.12/trixie (maybe with -s ours)? 20:10:31 What problem does that solve? 20:10:43 the "forget" part 20:11:06 (but take my suggestion with a grain of salt as I don't understand the new scheme yet) 20:11:33 Well it doesn't ensure that a security fix applied to 6.11 actually is present in the 6.12 branch 20:12:22 carnil: if you store that information, where do you want to track it? 20:13:07 I really need to prioritise finishing the work I did to (more) automatically update status in kernel-sec 20:15:32 Are we in agreement to merge the changes to scripts? 20:16:11 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 https://salsa.debian.org/kernel-team/kernel-sec/-/blob/master/active/00boilerplate#L11 sid field 20:17:03 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 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 yes 20:18:08 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 bwh: if you are fine with the changes and modulo the pending requested change is done, then let's go ahead 20:19:23 Right 20:20:16 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 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 okay this gave I guess some ideas to think about, which we can ponder on 20:22:40 switch to the next topic? 20:22:48 Yes please 20:23:22 #topic Question on debugfs mounts on debian-security mailinglists 20:23:34 We had on debian-security the following question: 20:23:41 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 about mounting debugfs by default (non systemd init notabene) when supported by kernel 20:24:28 It is mounted by default, and restricted to root 20:24:32 I don't see a problem 20:24:38 systemd seems to do that already, so does have anyone enought ensights in debugfs to answer the question there? 20:24:42 me neither 20:24:47 non systemd init because systemd automounts it even when not listed in fstab? 20:25:24 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 I also don't care what initscripts does, it's irrelevant to Debian default behaviour 20:26:05 +1 for being not very interesting 20:26:10 question 20:26:34 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 #topic #1063754 - fat-modules: SD corruption upon opening file on Linux desktop 20:26:56 AFAIK no news on that front, correct? 20:27:02 we intended to wait on that IIRC? 20:27:37 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 I was hoping to come up with a policy for how long we keep bugs open in moreinro+unreproducible state 20:28:02 ukleinek: there were some doubts on on which suites there is actually a problem 20:28:51 Did I have an action to ask about that? In any case I haven't touched it yet 20:29:43 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 Ah yes, that was it 20:30:07 but we indeed have bugs in moreinfo+unreproducible which we might go ahead and close and do some BTS housekeeping 20:30:16 so we wait here 20:30:21 yeah, noone was assigned an action on that one last week 20:31:02 ukleinek: well implicitly on bwh after the next bullseye-security upload 20:31:06 #topic #1076372 Corruption of Longsys/Lexar NM790 NVMe drive with Linux 6.5+ 20:31:14 no news from reporter 20:31:29 #topic #1069301 - linux-image-6.1.0-20-amd64: bluetooth causes kernel BUG - list_del corruption, (address)->prev is LIST_POISON2 20:31:35 Status update: 20:32:02 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 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 I can take an action here to ping the people once the patches are out for review 20:32:47 sounds great 20:32:49 Thank you 20:33:05 #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 #topic #1086793 - linux-image-6.10.11-amd64: Wifi not working with kernel 6.11 (working with 6.10) 20:33:23 #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 s/1086447/1086793/ 20:33:55 thank you ukleinek 20:34:24 ukleinek: I think we should reassign it to src:firmware-nonfree and close it then with the fixing version identified. 20:34:59 if that's the agreed on action, I can take care for that 20:35:16 Sounds right to me 20:35:53 * ukleinek nods, next! 20:36:04 #action ukleinek reassigns 1086793 to src:firmware-nonfree and closes it with the fixing version 20:36:18 #topic #1085762 - linux-image-6.1.0-26-amd64: Random crashes during pbuilder compile runs 20:36:45 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 do you have capacity for it in this week to see if we get more information on the issue? 20:37:22 alternatively was anybody able to reproduce the issue? 20:37:34 I am quite busy until at least Monday 20:38:26 I can ask the reporter to reproduce without the vbox stuff 20:38:37 I think the second message from the reporter answers the questions we had anyway 20:39:13 ukleinek: Sure 20:39:27 thanks 20:40:13 #action ukleinek will ask reporter for #1085762 about to reproduce issue without vbox stuff loaded and running 20:40:14 so he compiles ARM stuff on amd64, either using cross compiling or in a virtual arm machine 20:41:04 Can we move on? 20:41:34 I skip the next bug, is waiting for moreinfo 20:41:42 #topic #1086638 - linux-image-6.11.5: usbguard-daemon invalid opcode: 0000, usb's not usable 20:42:18 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 I would appreicate if someone can jump on the train and have a look as well at the followups 20:43:25 I think this bug report has been well and truly derailed 20:45:11 I could have a look through the logs but can't promise to do that soon 20:45:13 Have I asked the wrong question and is there anything which could help bringing it back on track? 20:45:38 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 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 carnil: OK 20:47:27 * ukleinek nods. good intentions sometimes is the counterpart to good 20:47:32 so not specific action, if someone has time look through the backlog of the bug 20:47:46 #topic #1038313 - acpi: mensage on boot: acpi bios error, pci0, acpi not found, x509 and sgx error 20:48:28 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 Two things to include: (1) we need an actual boot log (2) turning off ACPI is a terrible diea 20:50:05 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 +1 on what bwh said 20:51:53 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 this is easy action, I can take it and do it just later 20:52:51 so, out of time 20:52:56 #topic AOB 20:53:06 anything for the last minutes? 20:53:15 not from me 20:54:01 Well we have to respond to the live patching questions 20:54:09 I saw a MR about repairing cross compilation. Did someone notice an issue there? 20:54:49 Yes objtool was still slightly broken 20:55:07 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 carnil: Yes I think that's fine 20:55:35 the livepatching thread is on d-kernel? 20:55:47 yes 20:56:02 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 "secure boot support", well, non with a debian key 20:56:27 okay next meeting, on Jitsi, who wants to chair it? 20:57:11 it should be my turn. or would ukleinek try his hand? 20:57:29 * ukleinek checks calendar, should be fine. 20:57:43 What is to be done? Prepare the agenda and lead through the meeting? 20:57:47 awesome if we have a new person in the turnus :) 20:57:54 ukleinek: exactly 20:58:02 ok, I'll try. 20:58:03 ukleinek: prepare the agenda, send a reminder (asking for additional points) + leading through the meeting 20:58:07 perfect :) 20:58:44 #agreed ukleinek be the chair for next kernel-team meeting on 2024-11-20 20:58:47 :) 20:58:56 thanks a lot to all for partecipating 20:59:10 and providng input to various topics 20:59:13 Thanks for chairing 20:59:25 #endmeeting