08:00:00 <Emperor> #startmeeting
08:00:00 <MeetBot> Meeting started Thu Sep 25 08:00:00 2025 UTC.  The chair is Emperor. Information about MeetBot at http://wiki.debian.org/MeetBot.
08:00:00 <MeetBot> Useful Commands: #action #agreed #help #info #idea #link #topic.
08:00:07 <Emperor> Hi folks :)
08:00:12 <Emperor> #topic Roll Call
08:00:13 <Myon> Christoph Berg
08:00:15 <Emperor> Matthew Vernon
08:00:19 <roehling> Timo Röhling
08:00:36 <Emperor> I've had apologies from helmut, paultag, and (probably) seeS
08:01:03 <mjg59> Matthew Garrett
08:01:08 <tumbleweed> Stefano Rivera
08:01:19 <Emperor> #topic Review actions from previous meeting
08:01:23 <helmut> Helmut Grohne
08:01:37 <Emperor> oh, hi helmut :)
08:02:08 <Emperor> I think these all got done, thanks everyone. I think the revised format Debconf session worked reasonably well.
08:02:17 <tumbleweed> +1
08:02:21 <Myon> +1
08:02:29 <helmut> +1
08:02:31 <roehling> +1
08:03:04 * Emperor spots the typo in the agenda, sigh
08:03:30 <Emperor> #topic Bug #1106402 dpkg-source, native source package format with non-native version
08:03:53 <Emperor> I think nothing to do here, beyond making sure the pending upload to dpkg actually happens at some point. I think if it's still pending next meeting, we should chase?
08:04:28 <mjg59> Sounds good to me
08:05:18 <Emperor> #topic Bug #1065416: linux-libc-dev claims to provide linux-libc-dev-ARCH-cross, but it doesn't do that completely
08:05:52 <tumbleweed> So, we met at DebConf and had a fruitful discussion
08:06:08 <tumbleweed> paultag has prepared a statement and asked both sides to ack it
08:06:11 <Emperor> Yes, which is really good, so thanks again for making that happen
08:06:24 <Myon> more of that
08:07:04 <Myon> inviting people involved in such issues to debconf is about the best way we can spend Debian money
08:07:07 <Emperor> Again, if that's not happened by next meeting, we should chase, but I don't think anything else needs doing here now?
08:07:18 <mjg59> ack
08:07:19 <tumbleweed> probably just prodding people to review the text
08:07:37 <tumbleweed> and we expect this to be resolved by consent, without any TC ruling
08:07:44 <Emperor> Indeed.
08:07:59 <Emperor> OK, so onto the items I think will take more time
08:08:10 <Emperor> #topic Bug #1113774: Disabling -fcf-protection in sudo for bookworm
08:08:27 <Emperor> Thanks for the summary you sent round Myon
08:08:29 <Myon> I summarized the issue (sorry that it was only yesterday evening)
08:08:31 <mjg59> +1
08:08:46 <mjg59> Do we, as a project, have an explicit definition of what "i686" is?
08:08:57 <tumbleweed> it evolves over time
08:09:03 <mjg59> Yeah that was my concern
08:09:20 <mjg59> I'm impressed that there's an x86 of that era I hadn't heard of previously
08:09:34 <helmut> I would like to raise a consensus call on the statement "We do not see any technical downsides in disabling the half of -fcf-protection concerned with endbr instructions for i386 before forky." We may eaven reach broader consensus on even for forky or for other architectures before forky, but this seems pretty minimal.
08:09:43 <Myon> there is the option of accepting the request even if the CPU isn't strictly i686-conformant since the compiler flag seems to be a no-op on i386
08:09:58 <mjg59> I think there's two issues here:
08:10:11 <mjg59> Ok, let me say three
08:10:26 <mjg59> 1) Is Vortex86DX3 an i686 chip?
08:10:51 <mjg59> 2) Was excluding Vortex86DX3 from Bookworm a deliberate technical choice?
08:11:20 <mjg59> 3) Ignoring (1) and (2) does this option do anything in this context?
08:11:48 <Myon> 2) is probably "no" since it does work, just not for sudo (which uses non-default compiler flags)
08:11:57 <tumbleweed> (an nobody had heard of it)
08:12:22 <mjg59> (1) I think is unclear, given the lack of a clear definition. We have evidence that this opcode is supposed to be reserved on authentic Intel CPUs of this vintage, even if the authentic Intel chips treat it as a nop
08:12:48 <Emperor> FWIW, I agree with helmut's statement. For mjg59's questions, I think my answers are 1) I don't know 2) I don't think so 3) no
08:12:49 <mjg59> But as far as I can tell i686 is whatever people want it to be
08:13:01 <mjg59> (Other than that it has cmov)
08:13:21 <tumbleweed> our release notes tended to define i686 by the instructions we required support for
08:13:22 <mjg59> (2) seems like a "This was not considered" situation rather than a deliberate one
08:13:35 <tumbleweed> and these instructions were not something on anybody's radar
08:13:43 <mjg59> So from that perspective this feels like an accident rather than a deliberate choice
08:13:47 <Myon> the question helmut is raising is interesting, but I think not relevant here since trixie went on to require SSE2 which this CPU does not support, so it's much more broken than just sudo. I think we are solely discussing bookworm here
08:14:16 <Myon> +1 on accident
08:14:29 <mjg59> And (3) well if it does nothing then I think the obvious ideal outcome is that we don't break something for no benefit
08:14:55 <mjg59> But: there's also 4) does this impact enough people to justify a change to oldstable
08:15:36 <tumbleweed> yeah...
08:15:48 <mjg59> My *feeling* is that TC should advise that there is no technical benefit to this option being enabled and that Bookworm was not intended to rely on these instructions, but that the decision is on the maintainer
08:15:59 <Myon> fwiw I only realized after sending the mail that the submitter (who is also the author of the "make it x86_64-only in sudo upstream") filed the exact same patch as https://salsa.debian.org/sudo-team/sudo/-/merge_requests/24/diffs which looks rather unobtrusive
08:16:13 <tumbleweed> this is a bit of a special case because bookworm is the last release that supports i686 as a full platform (32bit kernel)
08:16:34 <Emperor> 4) it's unusual (exactly how early this problem was first reported is unclear to me), but ISTM that the proposed fix is very small in scope and easy to review, and that this would justify an upload for bookworm.
08:16:45 <helmut> I think I should raise a conflict-of-interest for me. I work with Freexian and Freexian has an interest in selling ELTS support for bookworm i386. Hence, there is an interest to make this work to broaden the customer base.
08:17:09 <Emperor> helmut: noted, thanks for mentioning that
08:17:14 <Myon> helmut: I would call that a useful data point
08:17:29 <tumbleweed> hah. I have that conflict of interest too. I don't know if the pool of vortex86 users is big enough to use our services, though :P
08:17:51 <mjg59> How about we provide advice on this, see what happens, and revisit if nothing happens and the reporter still cares?
08:17:55 <Myon> I tend to recommend Marc to accept that patch and upload to bookworm, but not make a strict ruling
08:17:59 <Emperor> I think my view is we should offer advice to the sudo maintainer to apply this change and upload for bookworm.
08:18:12 <Emperor> heh, that feels quite like consensus :)
08:18:20 <mjg59> Shockingly!
08:18:21 <helmut> Can we recommend the mild patch that only disables the relevant half of -fcf-protection?
08:18:33 <Myon> mjg59: I would not want to give the reporter that power
08:18:48 <mjg59> helmut: I feel ok with that if it's demonstrated to fix the bug, but I think that diverges us from upstream?
08:18:54 <helmut> The other half might still be meaningless, but not changing what we don't have to change is the minizmizing risk of regression.
08:18:58 <Myon> helmut: I have no seen that patch
08:19:04 <roehling> I concur with Myon and mjg59: advise that the option does nothing and can be disabled without negative impact and leave it up to Marc for now.
08:19:35 <helmut> Myon: upstream completely dropped -fcf-protection while I propose disabling only the half that breaks vortex users
08:20:03 <Myon> helmut: I understand, but that patch does not exist and is less trivial than https://salsa.debian.org/sudo-team/sudo/-/merge_requests/24/diffs
08:20:27 <helmut> If we ask Marco to produce that patch, he readily will.
08:20:31 <roehling> helmut: at least in my tests, I was unable to gain any meaningful CET protection even on amd64 userland.
08:20:39 <tumbleweed> +1 I think there's no risk here, and following upstream sounds sensible. I also see helmut's argument, but I'm not convinced
08:20:42 <roehling> so maybe upstream decided it was not worth the hassle?
08:20:48 <Myon> ok we can do that an tell Marc that either version would be ok
08:21:23 <Myon> but using the same patch that went into current upstream makes more sense (and that is that !24 patch plus indentation)
08:21:24 <helmut> Marc wants fewer changes and the bare minimum change here (that Marcos would be ok with as he explicitly stated) is disabling half of it.
08:21:48 <Emperor> helmut: are you OK with leaving that choice to Marc?
08:21:52 <helmut> I am.
08:22:22 <helmut> I also am fine with disablingt it entirely, but want to offer an alternative that has an even smaller risk of regression to Marc.
08:22:31 <Myon> is consensus enough for advice or do we vote on that?
08:22:51 <Emperor> Myon: I think we should vote on providing that advice.
08:23:20 <helmut> Can we include the fact that bookworm probably is the last release supporting those processors?
08:23:39 <Myon> helmut: imho the risk is greater, see last night 0:11
08:23:43 <Emperor> Myon: would you mind both asking the submitter to write the alternative patch and drafting a ballot to provide advice as agreed here?
08:23:55 <Myon> helmut: yes that is undisputed
08:24:05 <Myon> Emperor: yes to both
08:24:37 <helmut> if people could upgrade to trixie, I think the case for fixing sudo in bookworm now would be smaller
08:24:50 <Emperor> fair point
08:25:15 <Myon> any other options besides this one for the ballot (and FD)?
08:25:35 <Emperor> I don't think so, but if you write that anyone else can add an option if they want.
08:25:36 <mjg59> Marc buys everyone with a Vortex86DX3 a better CPU
08:25:40 <Emperor> lol
08:25:49 <Myon> +1
08:26:17 <Emperor> #action Myon to ask submitter for alternative patch; and to draft ballot for #1113774
08:26:29 <Emperor> #topic Bug #1115317: advice for using /var/lock (which is a link to /run/lock) (#1110981)
08:26:56 <Emperor> I've not had a response from the systemd maintainers to the mail I sent (but it was only yesterday)
08:27:38 <helmut> (late vortex followup): Cern noted that upgrading machines may be difficult as they have a need for lots of PCI slots and no machines are produced with those now. It's sometimes not as simple as replacing the CPU.
08:27:45 <Emperor> I think my view on this bug is that systemd is currently in violation of policy in a way that is breaking other software. Even if the end state of everything using flock() is desirable, this is not how to proceed.
08:28:02 <Myon> ack
08:28:26 <mjg59> I agree. /var/lock is a pretty poor solution for modern systems, but unilaterally breaking a bunch of existing code isn't appropriate in our context.
08:28:46 <Myon> it might be ok for systemd upstream to do that (they want to move there and hence have to move), but in Debian, they need to follow procedures
08:28:56 <mjg59> This should be a coordinated transition, not enforced breakage
08:29:05 <helmut> To me this is a patter. systemd regularly deprecates stuff without doing proper transitions in Debian
08:29:12 <helmut> system-log-daemon
08:29:16 <helmut> /usr-merge
08:29:36 <helmut> init scripts (are deprecated, but kinda did have a transition)
08:29:41 <tumbleweed> doing those transitions is probably more than the package maintainers have capacity for
08:29:44 <Myon> are we back at discussing one particular systemd maintainer?
08:29:54 <helmut> taking over avahi is also not going well
08:30:04 <tumbleweed> I do see that there was some effort to do this transition, early on, but it petered off
08:32:18 <helmut> On the flip side, if we push back here, how are we going to get to the desirable flock state?
08:32:43 <mjg59> Policy update, eventual TC intervention on any packages that don't transition?
08:33:09 <Emperor> MBF and some help to maintainers/upstreams to write the necessary code changes
08:33:16 <helmut> Policy maintainers will push back and say that applications should be updated first.
08:33:30 <helmut> So upfront it is a pile of work sending tons of patches.
08:33:30 <tumbleweed> policy can say that it's deprecated, surely
08:33:31 <Myon> some packages using /var/lock are mostly very old and not moving at all, this is going to be a long tail
08:34:01 <tumbleweed> what this needs is somebody to take it and drive the transition, so we'd probably have to request that marco or systemd maintainers do that
08:34:19 <Emperor> helmut: right, it is a pile of work, but we can do that if we have people willing to drive the transition. Look at pcre3 -> pcre2 ...
08:34:24 <helmut> To me, pushing back here amounts to asking Luca to do all that work. We might not say that, but that's what he reads.
08:34:44 <mjg59> Well, no, the status quo could remain
08:35:00 <Emperor> helmut: not necessarily, we could continue supporting the FHS-compliant status quo until someone or some people decide it's worth the effort of doing the transition
08:35:08 <mjg59> There are many cases where we can say "There is a better way" and not actually do anything because it's too much work to be worth it
08:35:12 <helmut> Do we have consensus on the statement that flock is the more desirable long-term state assuming we might get there?
08:35:22 <Myon> are only talking about the permissions of a single directory on the technical level? How bad would it be to just not change them?
08:35:36 <themill> Potentially useful factoid - In 87ldtk1cld.fsf@melete.silentflame.com the policy editors indicated that policy can lead standard practice.
08:35:46 <Emperor> helmut: I think I would offer advice that agrees with that but not say anything firmer at this point
08:36:07 <mjg59> Myon: At present, whether systemd ends up making any technical decisions that break that at some later point is probably not guaranteed
08:36:10 <Myon> helmut: long-term in a ideal world...
08:36:56 * helmut now imagines fuse.varlock
08:37:03 <Myon> so maybe /var/lock should just not be a symlink, then legacy software can use that and systemd can do whatever it wants with /run/lock
08:37:07 <Emperor> the policy bug opened apropos this could certainly result in a "deprecate old-style locks" outcome
08:37:09 <mjg59> helmut: Straight to jail
08:37:30 <mjg59> Are we being asked for a long term answer here?
08:37:48 <mjg59> Short term I think we're agreed that Debian should just diverge from upstream in the manner upstream envisages
08:38:00 <tumbleweed> +1
08:38:04 <Myon> I think the short term answer is to revert, and devise a long-term plan
08:38:10 <mjg59> We'd want to know whether this is something that systemd intends to support long term
08:38:10 <roehling> agree
08:38:15 <helmut> I am inclined to +1 if we can somehow limit the duration of the decision
08:38:35 <mjg59> And we'd also ideally want a migration away from this lockfile approach
08:38:43 <tumbleweed> give the project a release to transition and request help?
08:38:44 <mjg59> But whether the latter part is a TC thing is unclear to me
08:38:49 <Myon> "until there is at least a plan", so they can't just break again
08:39:14 <helmut> "until a transition plan has been proposed to d-devel@l.d.o"?
08:39:18 <mjg59> And yeah I agree that the default here is basically that bluca is left dealing with it
08:39:22 <mjg59> And that's not ideal
08:39:43 <Myon> helmut: has been agreed on
08:39:50 <Emperor> helmut: I think the transition plan needs to have been broadly agreed (and as necessary implemented) and policy updated
08:39:52 <helmut> agreement is difficult to measure
08:39:57 <mjg59> But, well, if you're going to attempt to push distributions to make a bunch of changes, and you're also going to choose to maintain that package in a major distribution, you need to accept some responsibility there
08:40:23 <Myon> helmut: practically not. There was either a discussion or an uncoordinated break. We can tell the difference
08:40:33 <Emperor> helmut: policy will need to be modified before systemd can do this without violating that, is that a reasonable end-point?
08:41:03 <helmut> With experience from /usr-move, I note that discussing these things with d-devel@l.d.o and telling people where and how quickly you want to go there, tends to elicit broad support.
08:41:04 <Emperor> or we could leave it that we will explicitly reconsider in future after such a transition plan
08:41:50 <tumbleweed> we could post a call to help to -devel (presumably somebody cares about old serial software)
08:41:58 <Emperor> [since we don't usually revisit previous decisions, but we could say here "we expect to allow this change in future after a suitable transition plan has been agreed", which lets us decide what agreement looks like]
08:42:02 <tumbleweed> anyway, I need to run. -> tumblingweed
08:42:13 <helmut> Emperor: +1
08:42:13 <Emperor> tumbleweed: thanks for your time!
08:42:16 <mjg59> +1 emperor
08:42:34 <Myon> do we really want to put that on our future agenda? Just yelling "stop, not like this" now seems good enough to me
08:43:14 <Emperor> Myon: I see your point, but I think we need to have some bound on this, because we don't (I think) want to say "systemd can never do this"
08:43:30 <Myon> "you need to do a proper transition"
08:43:41 <Myon> and if that goes wrong, we are back in the loop anyway
08:44:20 <Emperor> I could put both options on a ballot and see how we feel about them?
08:44:27 <Myon> nod
08:44:30 <helmut> +1
08:44:46 <Myon> the TC color of bikeshedding :)
08:45:22 <Emperor> OK, are we agreed we want a ballot to vote to require the change in systemd reverted, with a couple of options about what we say about a transition plan / timescale ?
08:45:54 <helmut> Would someone happen to understand why we need to lock serial consoles in the first place? In my experience, they tend to be connected to unique resources and I'd never get to the point where applications compete for a single console as they're statically assigned.
08:46:37 <Emperor> I'm afraid I've not actually used a real serial device in a decade (all my serial consoles are virtual/emulated now)
08:46:40 <Myon> helmut: if you have a modem on /dev/ttyS0, you might have several terminal programs that shouldn't be fighting over it
08:47:01 <mjg59> Does the kernel not enforce single open on the interfaces?
08:47:09 <Myon> I don't think so
08:47:16 <helmut> Myon: but why? (maybe we can defer that question until after the meeting)
08:47:21 <mjg59> I mean it's somewhat irrelevant, ripping out the code that does the locking is probably not much less work than using flock()
08:47:52 <Emperor> Would anyone like to draft said ballot, or should I?
08:48:04 <helmut> mjg59: it kinda is relevant for the transition, because when some applications use /var/lock and others use flock, we're in for bad stuff
08:48:07 <mjg59> But yes it would be nice to know that this happens for a reason rather than us just carrying forward 1984 best practices
08:48:25 <mjg59> helmut: Ah yeah fair
08:49:40 <Emperor> helmut: that feels like design work that should happen as part of any transition process
08:49:57 <helmut> Emperor: I cannot deny that
08:50:30 <Emperor> #action Emperor draft ballot (with suitable options) for #1115317
08:51:11 <Emperor> #topic AOB
08:51:41 <Emperor> anything else for today?
08:51:49 <Myon> </>
08:52:03 <helmut> How urgently do we need to start looking into ctte candidates?
08:52:04 <Emperor> (we'll need to start talking about recruitment, probably at our next meeting)
08:52:22 <helmut> Myon's term ends nobody elses, right?
08:52:51 <Emperor> indeed
08:53:22 <Emperor> So we'll need one new person, and I intend to not stand again as chair when we appoint them, to allow for handover during next year
08:54:30 <Emperor> last call for AOB
08:55:00 <Emperor> #endmeeting