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