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