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