08:00:43 #startmeeting 08:00:43 Meeting started Wed Jun 12 08:00:43 2024 UTC. The chair is spwhitton. Information about MeetBot at http://wiki.debian.org/MeetBot. 08:00:43 Useful Commands: #action #agreed #help #info #idea #link #topic. 08:00:55 #topic Roll Call 08:00:58 Sean Whitton 08:00:59 Christoph Berg 08:00:59 Timo Röhling 08:01:13 helmut and I are here: https://jitsi.debian.social/TechnicalCommittee 08:01:21 Helmut Grohne 08:01:34 Matthew Garrett 08:10:13 is this public, if not part can join read only? 08:21:16 #topic TC BoF at DebConf 08:21:21 we just discussed this on jitsi 08:22:00 #action mjg59 to determine some talking points regarding how we might have something a bit like Fedora's steering ctte 08:22:35 it was also noted that we should emphasise evne more than the slides s do already that the workload for being on the TC is not that bad. 08:22:56 #topic Bug#1065416 -- linux-libc-dev claims to provide linux-libc-dev-ARCH-cross, but it doesn't do that completely 08:23:14 we left off with this asking for more input from doko. we have not received anything. 08:23:59 also there have been uploads. does anyone know whether the problem still exists? 08:24:08 I've seen very little sign of life from doko in general (e.g. when I NMUed bash) but he seems to be uploading gcc still. Not sure what's up with him. 08:24:39 we could ask Bastian for an update. 08:24:44 c-t-b has dropped the conflicts iirc 08:24:58 but the underlying problem is not resolved 08:25:58 I am not sure we are going to get any more information. 08:26:17 I am not sure how to move this one forward. 08:26:23 the real question still is whether there should be a linux-libc-dev-*-cross and whether it belongs to doko or waldi 08:26:50 How much is this a technical decision and how much a social conflict? 08:27:27 I believe it's mostly technical. 08:27:29 I guess to rephrase that less confrontationally - is there any meaningful disagreement still about the shape of the problem or the potential solutions? 08:27:53 it would be technical if people were actually discussing it, but instead waldi threw it at the committee prematurely again 08:28:50 Maybe we should require that things pushed to ctte have a well formed problem statement rather than just being us Cc:ed on a bug 08:28:52 If we say it's premature, are we implicitly favouring one side? 08:29:03 I believe it's mostly social 08:29:06 we can of course discuss the technical part, but I have the feeling that neither side is willing to listen 08:29:21 Myon: in that case then maybe we ought to just decide. 08:30:07 (I mean waldi vs. doko - there's also helmut trying to mediate which I appreciate) 08:30:37 spwhitton: if we decline to say something, the status quo will stick and that is the virtual name linux-libc-dev-*-cross being taken over by src:linux 08:31:12 okay. that doesn't seem like a terrible status quo, socially or technically. 08:31:26 I am not entirely unbiased here and note that the change that caused this to spill to the ctte was actually proposed by me but now can no longer be reverted 08:31:37 do waldi and/or doko have a real interest in cross-compiling or is that mostly helmut trying to get either side to move? 08:32:28 is it fair to say that waldi actually has a solution to a problem he wants to implement/has impleemtned, whereas doko is just objecting to what he perceives as a hijack? 08:32:30 I don't think they have significant interest in cross building. Basic cross building support is part of doko's job description at Canonical I guess. 08:32:37 I have the feeling that the best outcome would be to let helmut decide on how the interaction between libc/kernel/etc should look like, and not the individual maintainers 08:33:00 ohi, sorry, missed this 08:33:27 (not in my calendar) 08:33:36 tumbleweed: np. 08:34:04 spwhitton: sounds like a reasonable characterization to me for now, but every time I actually get to talk to doko, I recognize that he does have relatable reasons very often 08:35:01 helmut: perhaps you could try to call him? 08:35:11 right, but it seems like we could apply a do-ocracy principle to this particular issue 08:35:17 doko clearly doesn't want to invest time in it. 08:35:43 he said he's going to write some docs 08:37:16 If I set the status quo aside and ignore the social conflict, my impression is that getting rid of linux-libc-dev-*-cross should be technically feasible (by moving over all of the uses to linux-libc-dev) with limited effort and that would remove the need of maintaining separate linux-libc-dev-*-cross packages. 08:37:59 helmut: do you think waldi would like to aim in that direction? and how about doko? 08:38:26 less moving parts sounds good 08:38:40 I actually proposed a change for dropping l-l-d-*-c from c-t-b (patch to the bts) before waldi added the provides that made the conflict rise 08:39:12 spwhitton: I am pretty certain that waldi agrees with this (and that was why he added the provides) 08:39:49 right okay. then I think we should resolve the binary package name conflict in favour of waldi, given that (i) he is doing work and (ii) it is going to become moot anyway, according to a plan he agrees with 08:40:08 spwhitton: I am pretty certain that doko does not agree and he has reasons related to architecture bootstrap that I cannot relate to well at this time and hence cannot represent in a useful way 08:40:27 helmut: it's on him to bring those up, and he hasn't. 08:40:41 well, yes. 08:41:03 we are one phone call away from an answer I think 08:41:15 Myon: phone call between who? 08:41:20 one argument is that adding a new port would formerly require patching c-t-b and rebuilding it. it now requires patching linux and rebuilding it. 08:41:23 doko and helmut 08:42:47 Myon: okay so do you think my suggested resolution is premature? 08:42:56 until now, doko could decide what architectures to cover with c-t-b and c-t-b-ports. in the new scheme, he has to coordinate with src:linux maintaiers and have them add architecture support to src:linux really early in the bootstrap process 08:43:24 so the move kinda causes a need for more communication/coordination between gcc and linux teams and as we know that doesn't work well currently 08:43:50 is it ever controversial what is to be added, though? 08:43:53 I realise this is going out on a tangent, but: is this purely an issue for Linux cross-compilation targets, or does it impact hurd as well? 08:43:56 (not trying to imply that it is good that this communication doesn't presently work) 08:44:06 if we replace this disagreement with necessary but boring communication, that seems like a win 08:44:06 spwhitton: ruling against him without hearing him first won't improve things 08:44:35 mjg59: no hurd impact ttbomk 08:45:26 Myon: people can't delay other people's work forever tho. 08:45:27 spwhitton: yes he could just have sent that email, but we should still try (realizing I'm not the one to reach out since I'm far from having the full picture) 08:45:42 Myon: I guess I feel like we have already tried. 08:45:52 helmut: do you want to call him? 08:46:01 I'm not convinced that phone call approach works out. I had one about this matter and felt like I got his reasons captured, but I no longer capture them well 08:46:07 helmut: In which case having this be part of src:linux doesn't feel conceptually bad 08:46:29 well you'd get "there are resons" or "there are none" at least 08:47:02 we could write another message to doko giving him a deadline, basically. 08:47:11 I know there are reasons. I just can no longer relate to them as I kinda feel like they could just talk to one another. 08:47:23 deadline +1 08:47:49 I could write "please let us know else we expect to say that the binary packages belong to src:linux" 08:48:02 two weeks? 08:48:45 Is there any way we can identify whether anyone involved would feel a hard deadline is either incompatible with anything else going on in their life or perceived as a threat? 08:49:04 sounds good. being biased (and personally affected) on this matter, I intend to abstain from voting 08:49:17 I think tech-ctte action can always feel like a threat 08:49:20 mjg59: we can invite htem to reply off-list if anything like that is true 08:49:26 but we also need to get input from people, to decide 08:49:47 the ctte is always too slow. setting deadlines is one of the few ways to not be too slow 08:49:57 spwhitton: Maybe indicate that we'd like to take action and would like to hear if that would cause problems for anyone in the near future? 08:49:59 yes 08:50:06 yes, good. 08:50:07 the call might just serve the purpose of getting the message "we want to proceed, please leave input there" across 08:50:27 alright, anyone want to write it? 08:50:42 I would appreciate that over an "two weeks or shut up" message... 08:51:11 Giving people the opportunity to object to the idea of a deadline also potentially means we can then set a shorter deadline 08:54:48 as we are running out of itme I shall action myself 08:54:58 #action spwhitton to write to #1065416 with deadline as discussed 08:55:04 #topic Any Other Business 08:55:10 anyone got anything? 08:58:46 okay! thanks all. productive meeting. 08:58:48 #endmeeting