19:00:26 #startmeeting 19:00:26 Meeting started Wed Jul 24 19:00:26 2024 UTC. The chair is bwh. Information about MeetBot at http://wiki.debian.org/MeetBot. 19:00:26 Useful Commands: #action #agreed #help #info #idea #link #topic. 19:00:57 o/ 19:01:09 Yes, who's here today? 19:01:13 i am 19:01:21 sorry about last week 19:01:57 Anyone else? 19:02:31 yeah, me ;) 19:02:37 Yes I saw you :-) 19:02:41 #topic Update to 6.10 19:03:08 We have successful builds on all main-archive architectures 19:04:00 as expected, I presume? 19:04:04 yes 19:04:05 I kind of wanted to go through and merge relevant feature update MRs before uploading 6.10 to unstable 19:04:55 I guess we still expect there to be a few 6.9 stable updates...? 19:05:34 probably ... after 6.11-rc1 is released then we probably get a 300+ patch update again 19:06:12 yes 19:06:35 not sure if that itself is a reason to stay on 6.9 though 19:07:03 otoh, a revert of the binutils workaround and possible the switch to gcc-14 seem interesting *to me* 19:07:15 for 6.10 ofc 19:08:07 I guess we are in a position where we are ready to switch whenever 6.9 goes EOL, and until then we can improve 6.10 in experimental 19:08:18 and target that for experimental to see how that goes and depending on those results, consider uploading it to Unstable 19:08:27 unless someone knows or blockers for 6.10? 19:08:45 not me 19:08:57 me neither 19:09:19 OK, so are you both happy with doing further merges and another upload to experimental? 19:09:52 yes 19:10:19 yep. If going for gcc-14 I'd recommend experimental first, but otherwise 6.10 seems ready for Unstable too 19:10:46 #agreed Continue handling MRs for linux/master and make another upload of 6.10 to experimental before unstable 19:11:07 #topic Bug #1076582 - initramfs-tools: duplicates nvidia firmware files 19:11:25 This is closed with the version in experimental. I really really need to do an unstable upload. 19:11:36 03firmware-nonfree 05master 06Ben Hutchings * [open] merge request !101: Update to 20240709 and remove some file exclusions * 14https://salsa.debian.org/kernel-team/firmware-nonfree/-/merge_requests/101 19:11:40 bug is fixed by initramfs-tools 0.143, but indeed an upload to Unstable would be welcome 19:12:11 Salsa really is going slow this evening... 19:12:35 #topic Bug #1076372 - linux-image-6.5.0-0.deb12.4-amd64: ext4 file corruption with newer kernels 19:12:36 the default for new installations is now 1G for /boot (in partman-auto) 19:13:00 diederik: That's also helpful 19:13:30 I responded earlier today and asked to test versions older then 6.5 (for 1076372) 19:13:57 I was supposed to ask for bisection and I haven't done that yet 19:14:12 thanks. Would've been better if that had been done years ago, but better now then not/later 19:14:34 You must be thinking of a different bug, as this is from 15/7 19:14:41 03firmware-nonfree 05master 06Ben Hutchings * [update] merge request !101: Update to 20240709 and remove some file exclusions * 14https://salsa.debian.org/kernel-team/firmware-nonfree/-/merge_requests/101 19:14:54 yeah, narrowing it down first via snapshot.d.o is what I usually recommend first to narrow down the range ... before bisecting 19:15:30 my previous remark was wrt 1G /boot 19:15:33 Sure, bisecting package versions is a useful first step before bisecting through git and actually rebuilding 19:16:16 #action bwh to request bisection of #1076372 19:16:31 #topic Bug #1063754 - fat-modules: SD corruption upon opening file on Linux desktop 19:16:59 I was also supposed to have another look at this and have not, so let me take that action again 19:17:19 #action bwh will look at and try to respond to #1063754 again 19:17:53 #topic Bug #1039883 - linux: ext4 corruption with symlinks 19:18:39 The fix for this is still on Linus's tree, so I propose to continue waiting 19:18:45 The fix for this is still *not in* Linus's tree, so I propose to continue waiting 19:19:12 seems sensible to me 19:19:27 Ah, actually it did land there now but is not in a release 19:19:42 so during the 6.11 merge window? 19:19:48 yes 19:20:24 and not marked for stable 19:21:07 It has a Fixes: so probably will get picked up 19:21:36 51ed42a8a135511f6d6f75b56e85e6586a06a93c is the merge commit I guess? (Merge tag 'ext4_for_linus-6.11-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/tytso/ext4) 19:22:15 yes 19:22:19 #topic Bug #1057282 - linux-image-6.5.0-0.deb12.1-arm64: arm64 kernel upgrade makes systems unresponsive 19:23:23 elbrus reported the updated kernel was working so far. I suggest we close the bug next week if the problem doesn't recur 19:23:27 Report from Paul on 2024-07-21: working fine with 6.9.10 and has upgraded all arm64 hosts. So probably fixed 19:24:53 Anyone think we should just close already? 19:25:07 yes 19:25:20 I'd wait a while longer 19:26:11 It's not blocking anything afaict? And it seems Paul usually responds periodically. 19:26:19 I guess there's no harm in closing; it can be reopened if the problem recurs 19:26:28 and if not we don't have to look it again 19:26:37 that works too 19:27:33 waldi: Could you send the close message? 19:27:37 Probably worth mentioning explicitly that Paul should just reopen if it occurs again 19:27:44 yes 19:27:45 sure 19:28:18 #action waldi will close #1057282 based on latest positive feedback 19:28:41 #topic Bug #1072063 - one of the external monitors randomly blank for 2-3 seconds with 6.8/6.9 Linux kernels (regression) 19:29:33 I guess this needs to be forwarded 19:30:06 https://drm.pages.freedesktop.org/intel-docs/how-to-file-i915-bugs.html seems applicable (again) 19:30:14 It might possibly be related to #1076708 19:30:32 diederik: Right 19:30:37 I should bookmark that 19:30:58 but lists an nvidia card 19:31:43 ah, I didn't check HW, just saw a link to fd.o/drm/i915 19:31:55 ah, both an intel and a nvidia card in that system 19:32:06 and no kernel log messages ... 19:32:25 Yes, and I think the i915 is usually responsible for the display in such systems 19:32:59 that's indeed often the default display afaik 19:33:07 oh, thunderbolt 19:33:30 Extra scope for things to go wrong :-) 19:33:32 because he talks about external displays connected via thunderbold 19:33:43 yep, problem could be directly related to that 19:33:59 Well, who will answer the report? 19:34:29 I won't have time to commit to any bug triaging (sorry) 19:34:36 OK 19:35:22 I suppose I can do it 19:35:39 #action bwh will answer #1072063 19:36:01 #topic Bug #1076483 - Call Trace on rt kernel, CPU Intel 13th Gen Intel(R) Core(TM) i5-1340P 19:36:50 ukleinek was supposed to handle this but has not yet 19:37:32 Shall we assume he'll do that, or would someone else like to handle it? 19:38:22 lets asume, because i'm also low on time 19:38:27 OK 19:38:40 #topic Bug #1076576 - linux - Backport changes to Microsoft Azure Network Adapter 19:38:55 waldi: This is your bug, and I think you already opened an MR for it, right? 19:39:05 i did 19:39:25 so this is handled, the bug is needed to fulfill stable uipdate rules 19:39:36 right 19:39:40 carnil will look at it hopefully before the next upload 19:40:01 I may find time to look at it 19:40:47 Is the subject supposed to be "Backport ... .from 6.10"? 19:41:05 because you're backporting to 6.1, not 6.10 19:41:23 but from 6.10 to 6.1 19:41:40 or most things between 6.4 and 6.10 19:41:48 yes, so please correct the commit message and MR title 19:42:24 #info waldi opened https://salsa.debian.org/kernel-team/linux/-/merge_requests/1129 to fix this 19:42:45 #topic Bug #1076555 - linux-image-6.9.9-amd64: boot crash RIP: 0010:kmem_cache_alloc 19:43:07 I'd have expected a stack trace, but I'm not seeing that? 19:43:29 There is a crash log attached but there were earlier WARN and BUG messages not included 19:44:07 I think the stack trace has a different log level 19:44:26 ah yeah, I see it now (but indeed seems incomplete) 19:44:50 In any case we need to see the first WARN and BUG messages 19:45:09 Who will follow up to request that information? 19:45:32 i will 19:45:37 Thank you 19:45:46 #action waldi will handle #1076555 19:45:53 and ask for a BIOS upgrade first 19:46:15 diederik: Any particular reason for suspecting the BIOS? 19:46:19 Critical BIOS update from 18 jun 19:46:45 No, the *critical* part with the BIOS update 19:46:51 https://www.dell.com/support/home/en-us/product-support/product/precision-15-7540-laptop/drivers 19:47:09 And I generally recommend people first update to the latest BIOS 19:47:19 OK 19:48:01 Dell thinks people in Belgium speak French 19:48:30 for me it was nicely in English ;-) 19:49:45 So that was all the important or higher bugs 19:50:10 There's a few others I would like input on before I go ahead with the changes 19:50:18 "it could be something related to some hardware failure" is also when I'd like to rule out BIOS issues 19:50:19 if people still have time? 19:50:49 sure 19:50:53 yeah 19:51:11 #topic Bug #1076629 - ethtool: Add Appstream metainfo announcing HW support 19:52:18 So I'm not totally sure how the AppStream stuff works but I guess this would cause ethtool to be automatically installed in some cases 19:52:40 I didn't decode the modalias but I guess it's matching PCI Ethernet devices 19:53:08 I'm just not sure this makes sense, because essentially everything has a network device and ethtool has (some) functionality for non-Ethernet devices too 19:53:12 I generally stay away from AppStream. I wonder why "Forwarded: no" though as this should not be specific to Debian? 19:53:13 i assume too. but is ethtool a tool for the arbitrary user? 19:53:49 I would find it mostly useful as an occasional diagnostic tool 19:54:16 and if you have to do network diagnostics it would certainly be good to already have it installed... 19:54:51 yeah 19:55:03 but in that case maybe it should be standard, rather than only installed on systems with certain sorts of network card 19:56:11 still ... send it upstream? Otherwise you'll carry this patch forever 19:56:46 Right, I wouldn't want to carry that as Debian-specificb 19:57:27 My point is if the intent is to have ethtool automatically installed on systems with network hardware, why not make it standard instead of trying to match network hardware generically? 19:58:11 that's not the intend afaiui 19:58:44 Sure, it's Ethernet, but it only matches PCI Ethernet 19:58:52 AppStream is about making it public to various tools (which I personally avoid) that that tool is *relevant* for network hardware 19:59:04 OK 20:00:12 I wouldn't be surprised if the patch itself could be improved upon ... 20:00:21 It certainly could 20:00:46 but mostly, redirect the bug to upstream and let them handle it 20:01:23 Well, thank you for your input. I'll bear that in mind when replying, and yes, I will redirect upstream 20:01:42 #topic Bug #1076510 - procps: "vm.max_map_count = 65530" : Value too small for gaming 20:01:43 03linux 05bookworm 06Bastian Blank * [update] merge request !1129: Backport Microsoft Azure Network Adapter from 6.10 * 14https://salsa.debian.org/kernel-team/linux/-/merge_requests/1129 20:02:41 This says the default is 1048576 on other distros. But I suspect it might need to be architecture-dependent (i.e. not so large on 32-bit). 20:03:07 those other distros don't support 32bit anymore 20:03:26 Well that would simplify things for them, yes 20:05:52 i try to look what those distros are doing and what they document on it 20:06:03 Upstream's default seems to be 65536, which is quite a bit smaller then suggested (https://kernel.org/doc/Documentation/sysctl/vm.txt) 20:07:04 Right. Well I will do that survey and work out how to change linux-sysctl-defaults to be arch:any 20:07:10 Thanks 20:07:20 #topic AOB 20:07:27 (upstream's default may be outdated ...) 20:07:40 nothing from me today 20:07:45 default is #define DEFAULT_MAX_MAP_COUNT (USHRT_MAX - MAPCOUNT_ELF_CORE_MARGIN) 20:08:04 that's "- 5" 20:08:05 what's AOB? 20:08:15 diederik: Any Other Business (or in this case Bugs) 20:08:51 thanks. I like urban dictionaries better though: "British acronym standing for Arrogant Obnoxious Bastard." ;-P 20:08:51 iam_tj[m]1: Oh, so maybe core dumps can't represent more maps than that 20:08:58 Heh 20:09:33 No other business from me either 20:09:57 OK, thanks for attending and for your patience 20:10:03 #endmeeting