12:00:03 <Emperor> #startmeeting
12:00:03 <MeetBot> Meeting started Fri Nov 29 12:00:03 2024 UTC.  The chair is Emperor. Information about MeetBot at http://wiki.debian.org/MeetBot.
12:00:03 <MeetBot> Useful Commands: #action #agreed #help #info #idea #link #topic.
12:00:10 <Emperor> #topic roll call
12:00:11 <spwhitton> Sean Whitton
12:00:14 <Emperor> Matthew Vernon
12:00:39 <tumbleweed> Stefano Rivera
12:01:10 <helmut> Helmut Grohne
12:02:31 <Emperor> I'm also expecting Christoph, Craig, Timo from the whenisgood...
12:02:32 <Myon> Christoph Berg
12:03:31 <Emperor> seeS isn't on this channel, roehling is...
12:03:58 <roehling> Timo Röhling
12:04:14 <Emperor> hi :)
12:04:39 <Emperor> #topic Review previous actions
12:05:15 <tumbleweed> sorry for the delay, but I've picked up the actions on #1065416
12:05:29 <tumbleweed> I summarized where I saw the current state of discussion, and requested some replies from people
12:05:32 <helmut> I talked to prospective ctte members in Toulouse and -private has results
12:05:34 <tumbleweed> thanks helmut for replying
12:05:40 <Emperor> thanks both.
12:06:04 <Emperor> I saw spwhitton's suggestion on 1084924 and I think they did ping the person we talked about.
12:06:20 <spwhitton> yes, and they responded.
12:06:23 <Emperor> #topic Bug #1065416: linux-libc-dev claims to provide linux-libc-dev-ARCH-cross, but it doesn't do that completely
12:06:48 <Emperor> this saw a bit of activity yesterday/today, which I think means we need to see what responses result from that?
12:07:04 <tumbleweed> my summary: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1065416#299
12:07:27 <tumbleweed> yeah, I am glad to see some discussion in the arch:all sub-bug
12:07:39 <helmut> I talked to Ben in Toulouse and my impression is that he (like me) does not understand why linux-libc-dev cannot be Arch:any (i.e. what the motivation for the change is)
12:08:02 <tumbleweed> waldi did describe that in an earlier post, I'm going to ask him to expand on it ab it
12:08:03 <Emperor> that's #1084908 yes?
12:08:07 <tumbleweed> yes
12:08:30 <tumbleweed> unless anyone can explain to me the concern about arch any -> all deps deep in the toolchain
12:08:33 <helmut> doko also filed one about the installation size. that would also be solved by reverting back to arch:any
12:08:41 <tumbleweed> (they can be complex to express, but not impossible)
12:09:57 <helmut> tumbleweed: there is general issue with any->all dependencies within toolchain packages (not across): if the indep-only build finishes in a different mirror push that the arch-only build, the toolchain becomes uninstallable. I don't think that's relevant to linux-libc-dev though as that's built from a different source package
12:10:46 <tumbleweed> right, there is that
12:11:04 <Emperor> but it doesn't apply here, if I understand correctly
12:11:48 <Emperor> ISTM it'd be worth seeing if waldi can expand on their objection to reverting linux-libc-dev to Arch:any and if that's persuasive
12:12:12 <helmut> it would also help if he could expand on what problem is being solved by using arch:all
12:12:54 <helmut> the lack of such an understanding makes it difficult to propose patches as it is unclear what requirements they'd have to solve
12:13:08 <tumbleweed> I'll pry a bit at this
12:13:15 <Emperor> I'm mindful this bug has been open since March, too.
12:13:40 <Emperor> tumbleweed: thanks
12:14:12 <helmut> the conflict dates back earlier. january or something.
12:14:33 <tumbleweed> it has been very slow moving
12:14:52 <Emperor> #action tumbleweed to seek explanation of waldi's concerns re linux-libc-dev Arch:any/all
12:15:25 <Emperor> #topic Bug#1084924: The system-log-daemon virtual package
12:15:43 <Emperor> Feels to me like the various positions have been expounded sufficiently at this point.
12:15:57 <spwhitton> I had a proposal that wasn't responded to
12:16:33 <spwhitton> Emperor: I'm not sur eabout that.  I don't know what to think about these container use cases.  not sure whether they're real or theoretical.
12:16:58 <Emperor> That was to essentially use the Policy Change Process to address the question of whether packages should no longer be allowed to declare a dependency on system-log-daemon ?
12:17:15 <spwhitton> which is the whole bug, right?
12:17:27 <Emperor> [or to put it another way: whether Debian systems will always have same available]
12:17:41 <helmut> I am not sure that this is a sensible solution. The bug hinges on interpretation of a very short amount of text in policy.
12:18:05 <spwhitton> no, it would be about removing that text
12:18:16 <spwhitton> or replacing it.
12:18:16 <helmut> There is no doubt that policy needs clarification here, but I find both interpretations of the current wording sensible.
12:18:54 <Emperor> It seems clear to me that we have historically understood it to mean that depending on system-log-daemon is a reasonable thing to do if appropriate
12:19:07 <Emperor> [we == the project]
12:19:37 <spwhitton> yes, but the question is whether that is stil fit for purpose
12:19:50 <helmut> That may be as it may be, but given that the other interpretation is sensible, the proponents of the change may not have seen the need to update policy before effecting their change.
12:20:19 <spwhitton> helmut: I'm not sure I know what that other interpretation is.
12:20:47 <helmut> spwhitton: system-log-daemon package is managing the "there is only one logging daemon" using provides+conflicts
12:21:05 <spwhitton> ah.  aren't these both true?
12:21:05 <Emperor> I think we (the TC) could decide i) to affirm that packages can depend on s-l-g OR ii) to say that they can no longer do so
12:21:53 <Emperor> spwhitton: no, the people who advanced the change interpret policy as meaning the latter "s-l-d is only for provides/conflict" only, not "and also packages may depend on s-l-d"
12:22:01 <spwhitton> ahh right, thanks.
12:22:20 <helmut> Emperor: I concur. Deferring to policy process would merely shift the conflict. Deciding the matter in the variants you propose is what I see as an actionable resolution that will result in a policy update (either way).
12:22:55 <spwhitton> I don't know what to think about it yet, though.
12:23:16 <spwhitton> We haven't heard from the other side.  We would do so if we moved it to Policy because Ian is willing to engage there.
12:23:54 <spwhitton> helmut: it would indeeed merely shift the conflict, but that might be appropriate.
12:24:22 <roehling> it effectively doubles the amount of policy editors in the loop ;)
12:25:42 <Emperor> I'm having a grumpy day, but my take on this is that the argument that policy didn't need changing to make s-l-d provides/conflicts only is weak, and I'm not convinced of the need to change policy-as-was (but to clarify it perhaps).
12:26:13 <helmut> While we can in principle defer many decisions to policy, I don't think this is useful. Policy covers common things. It is (intentionally or not) ambiguous on whether system-log-daemon should be used in dependencies. As a result, the ctte may decide about it.
12:27:26 <tumbleweed> policy also tends to follow implementation
12:27:42 <Myon> afaict policy isn't meant to invent or set new policy
12:27:43 <tumbleweed> and given that it says almost nothing about this topic, it's not like it would be violating policy to change behaviour here
12:28:02 <helmut> tumbleweed: you put it better than I could. thanks.
12:29:08 <Emperor> right, and I think we had policy and implementation of s-l-d which some folk now want to change; but they're arguing that the lax wording of policy means it's not technically a policy change.
12:30:00 <helmut> I think we basically have three options now: a) Decline deciding and request a policy change to clarify system-log daemon b) Decide that system-log-daemon shall continue to be used in dependencies c) Decide that system-log-daemon shall only be used with provides/conflicts.
12:30:19 <Emperor> Yes
12:30:35 <Emperor> We could presumably just run a vote on all 3 options?
12:30:46 <Myon> ack
12:30:46 <spwhitton> I'd strengthen (a) a bit
12:31:01 <spwhitton> it's about delegating the decision back to the other process, not just declining.
12:31:28 <helmut> But then, who is supposed to drive that process?
12:31:48 <spwhitton> Ian, Luca, Ansgar
12:31:53 <helmut> And what should be done until process has resulted in a change?
12:32:14 <Emperor> helmut: status quo ante, which I think is that packages can continue to depend upon s-l-d
12:32:16 <helmut> Ian expressly wants to not drive that policy change (but he would interact with it)
12:32:37 <helmut> Emperor: but the status quo also is that most packages do not depend on s-l-d
12:32:43 <Emperor> bluca's original MBF email noted that "some packages declare a dependency on the virtual package system-log-daemon"
12:33:26 <helmut> It's a bit like /usr-merge in that the change has been made and we are now trying to decide whether to keep it.
12:33:45 <helmut> (or trying not to decide actually)
12:33:55 <spwhitton> helmut: but it's not up to the systemd maintainers to decide on that on behalf of the whole project.
12:34:24 <helmut> spwhitton: Why not? I decided that e2fsprogs should not be essential and created lots of bugs. How is that different?
12:34:38 <spwhitton> helmut: because they dont own the virtual package.  policy does.
12:35:06 <helmut> I am not an e2fsprogs maintainer.
12:35:17 <spwhitton> I'm not familiar with this case.  did you NMU it?
12:35:26 <Emperor> I think we're in danger of getting off track here.
12:35:42 <helmut> I did not, but I proposed the patch after effecting the change to all other packages and Ted accepted it then
12:36:12 <helmut> same thing, effect the change, then change policy (or essential flag)
12:36:25 <tumbleweed> helmut: I think that's somewhat more straightforward than this
12:36:41 <tumbleweed> the difference here is that we're changing expectations, not restructuring dependencies and priorities
12:37:01 <tumbleweed> (plus systemd is inherently radioactive to many Debian people, due to past behaviour)
12:37:06 <Myon> we should decide on how the solution should look like, figuring out who needs to move is then secondary
12:37:20 <roehling> Myon: +1
12:37:38 <Emperor> Myon: that position is expressible in the proposed 3-way ballot, I think (put refer to policy below FD)
12:38:38 <tumbleweed> There could be a 4th ballot option of recommending a policy change + allowing bugs to be filed to drop the dependency
12:38:57 <roehling> I remember we talked about the use-cases for depending on s-l-d, but I only remember one, packages which parse log files such as fail2ban
12:39:02 <tumbleweed> or that could be implicit in c
12:39:14 <Emperor> tumbleweed: how's that different from option c above?
12:39:18 <helmut> tumbleweed: I was about to say that it feels close to c
12:39:30 <Myon> roehling: packages that think their log messages are really important
12:39:57 <tumbleweed> the difference wolud be more in the messaging of not overriding policy, but saying: yes this looks OK, and we should write some policy to document it
12:40:04 <tumbleweed> I think a well worded c would achieve that
12:40:08 <spwhitton> Myon: I don't think that's right.  packages can put it in recommends.
12:40:25 <Emperor> https://lists.debian.org/debian-devel/2024/05/msg00425.html has at least a partial list
12:40:30 <Myon> spwhitton: yes that's the case I believe we should get rid of
12:40:39 <helmut> tumbleweed: I agree that (c) should be augmented with a recommendation to clarify policy
12:41:09 <Emperor> Any objections to a 3-way ballot, assuming it's well-drafted?
12:41:17 <Myon> fine with me
12:41:23 <tumbleweed> +1
12:41:24 <spwhitton> sounds good.
12:41:28 <roehling> +1
12:41:31 <helmut> +1
12:41:38 <Emperor> spwhitton: I don't suppose you'd be up for drafting it, would you?
12:41:49 <spwhitton> I'm afraid not.
12:42:01 <Emperor> OK, volunteers? I'm about the skip the country
12:42:36 <Emperor> #agreed proceed to a 3-way ballot on #1084924 as discussed
12:43:04 <Emperor> sigh, OK, I'll do it when I'm back :-/
12:43:12 <Emperor> #action Emperor to draft ballot for #1084924
12:43:33 <spwhitton> thank you.
12:43:33 <Emperor> I'm going to rudely take helmut's AOB now
12:43:56 <helmut> the systemd vs /usr-move one?
12:44:13 <Emperor> #topic #1079329: systemd(?) still creates /lib64 on arm64
12:44:16 <Emperor> helmut: yes
12:44:37 <helmut> Roughly speaking, booting systemd creates a /lib64 symlink that conflicts with what base-files installs and makes base-files.postinst fail
12:45:12 <helmut> It is a classical conflict of jurisdiction. Who owns /lib64? It is not yet escalated to ctte, but I see little ways forward at this time.
12:45:35 <spwhitton> has the base-files maintainer said anything though?
12:45:51 <helmut> The base-files maintainer basically defers all of /usr-move to me.
12:46:11 <spwhitton> ah I see.
12:46:20 <helmut> In particular, he sets me as bug owner for all /usr-move related bugs.
12:46:58 <helmut> And the failing postinst part is authored by me.
12:47:17 <helmut> s/postinst/preinst/ in all of this.
12:47:19 <Emperor> I think it'd be reasonable for you to bring that to the TC, then (maybe with a note to the above effect re the base-files maintainer)
12:47:55 <helmut> Do you see any pre-escalation avenues? I think NMU (deferred or not) would be consideres hostile given expressed opposition.
12:48:44 <spwhitton> I think I'd have to read the bug thoroughly to have a view on that
12:49:07 <helmut> If one ctte member volunteers to do that, that would help.
12:49:09 <Emperor> helmut: you could provide a patch?
12:49:17 <tumbleweed> ideally upstream
12:49:26 <helmut> Emperor: there is an upstream MR of course
12:50:52 <Emperor> Ah, you mean https://github.com/systemd/systemd/pull/34804 ?
12:50:57 <helmut> yes
12:51:46 <helmut> given the time, I recommend that we find one volunteer and then move on
12:52:20 <Emperor> helmut: you want someone to read through the bug and confirm that NMU wouldn't be appropriate?
12:52:43 <helmut> or suggest other avenues before actual ctte escalation
12:53:12 <Emperor> OK, any takers for this, please?
12:53:16 <helmut> imo, that bug really needs to be fixed before trixie. We cannot tell people that installing base-files randomly fails
12:53:32 <roehling> I can have a look and add my two cents
12:53:37 <Emperor> roehling: thanks
12:53:43 <helmut> (fixed may mean changing base-files, but I am not convinced yet)
12:54:01 <tumbleweed> helmut: what's blocking that upstream PR from being non-draft?
12:54:26 <Emperor> #action roehling to review #1079329 for appropriate NMU or pre-TC escalation actions
12:54:37 <Emperor> #topic recruitment
12:55:31 <helmut> tumbleweed: I can try undrafting it. I was imagining that I'd just disagree with bluca on github then
12:56:25 <Emperor> [see -private for the recruitment discussion]
13:02:20 <Emperor> #Agreed defer discussion on this
13:02:25 <Emperor> #topic AOB
13:02:44 <Emperor> I have to run imminently, any pressing OB?
13:02:53 <Myon> no, thanks, cheers :)
13:02:54 <spwhitton> not from me.
13:02:58 <roehling> me neither
13:03:05 <helmut> my aob is handled. thanks
13:03:26 <Emperor> #endmeeting