08:00:43 <spwhitton> #startmeeting
08:00:43 <MeetBot> 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 <MeetBot> Useful Commands: #action #agreed #help #info #idea #link #topic.
08:00:55 <spwhitton> #topic Roll Call
08:00:58 <spwhitton> Sean Whitton
08:00:59 <Myon> Christoph Berg
08:00:59 <roehling> Timo Röhling
08:01:13 <spwhitton> helmut and I are here: https://jitsi.debian.social/TechnicalCommittee
08:01:21 <helmut> Helmut Grohne
08:01:34 <mjg59> Matthew Garrett
08:10:13 <tarzeau> is this public, if not part can join read only?
08:21:16 <spwhitton> #topic TC BoF at DebConf
08:21:21 <spwhitton> we just discussed this on jitsi
08:22:00 <spwhitton> #action mjg59 to determine some talking points regarding how we might have something a bit like Fedora's steering ctte
08:22:35 <spwhitton> 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 <spwhitton> #topic Bug#1065416 -- linux-libc-dev claims to provide linux-libc-dev-ARCH-cross, but it doesn't do that completely
08:23:14 <spwhitton> we left off with this asking for more input from doko.  we have not received anything.
08:23:59 <spwhitton> also there have been uploads.  does anyone know whether the problem still exists?
08:24:08 <helmut> 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 <spwhitton> we could ask Bastian for an update.
08:24:44 <helmut> c-t-b has dropped the conflicts iirc
08:24:58 <helmut> but the underlying problem is not resolved
08:25:58 <spwhitton> I am not sure we are going to get any more information.
08:26:17 <spwhitton> I am not sure how to move this one forward.
08:26:23 <helmut> 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 <mjg59> How much is this a technical decision and how much a social conflict?
08:27:27 <spwhitton> I believe it's mostly technical.
08:27:29 <mjg59> 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 <Myon> it would be technical if people were actually discussing it, but instead waldi threw it at the committee prematurely again
08:28:50 <mjg59> 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 <spwhitton> If we say it's premature, are we implicitly favouring one side?
08:29:03 <helmut> I believe it's mostly social
08:29:06 <Myon> we can of course discuss the technical part, but I have the feeling that neither side is willing to listen
08:29:21 <spwhitton> Myon: in that case then maybe we ought to just decide.
08:30:07 <Myon> (I mean waldi vs. doko - there's also helmut trying to mediate which I appreciate)
08:30:37 <helmut> 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 <spwhitton> okay.  that doesn't seem like a terrible status quo, socially or technically.
08:31:26 <helmut> 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 <Myon> 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 <spwhitton> 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 <helmut> 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 <Myon> 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 <tumbleweed> ohi, sorry, missed this
08:33:27 <tumbleweed> (not in my calendar)
08:33:36 <spwhitton> tumbleweed: np.
08:34:04 <helmut> 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 <Myon> helmut: perhaps you could try to call him?
08:35:11 <spwhitton> right, but it seems like we could apply a do-ocracy principle to this particular issue
08:35:17 <spwhitton> doko clearly doesn't want to invest time in it.
08:35:43 <tumbleweed> he said he's going to write some docs
08:37:16 <helmut> 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 <spwhitton> helmut: do you think waldi would like to aim in that direction?  and how about doko?
08:38:26 <Myon> less moving parts sounds good
08:38:40 <helmut> 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 <helmut> spwhitton: I am pretty certain that waldi agrees with this (and that was why he added the provides)
08:39:49 <spwhitton> 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 <helmut> 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 <spwhitton> helmut: it's on him to bring those up, and he hasn't.
08:40:41 <helmut> well, yes.
08:41:03 <Myon> we are one phone call away from an answer I think
08:41:15 <spwhitton> Myon: phone call between who?
08:41:20 <helmut> 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 <Myon> doko and helmut
08:42:47 <spwhitton> Myon: okay so do you think my suggested resolution is premature?
08:42:56 <helmut> 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 <helmut> 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 <spwhitton> is it ever controversial what is to be added, though?
08:43:53 <mjg59> 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 <helmut> (not trying to imply that it is good that this communication doesn't presently work)
08:44:06 <spwhitton> if we replace this disagreement with necessary but boring communication, that seems like a win
08:44:06 <Myon> spwhitton: ruling against him without hearing him first won't improve things
08:44:35 <helmut> mjg59: no hurd impact ttbomk
08:45:26 <spwhitton> Myon: people can't delay other people's work forever tho.
08:45:27 <Myon> 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 <spwhitton> Myon: I guess I feel like we have already tried.
08:45:52 <spwhitton> helmut: do you want to call him?
08:46:01 <helmut> 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 <mjg59> helmut: In which case having this be part of src:linux doesn't feel conceptually bad
08:46:29 <Myon> well you'd get "there are resons" or "there are none" at least
08:47:02 <spwhitton> we could write another message to doko giving him a deadline, basically.
08:47:11 <helmut> 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 <helmut> deadline +1
08:47:49 <spwhitton> I could write "please let us know else we expect to say that the binary packages belong to src:linux"
08:48:02 <spwhitton> two weeks?
08:48:45 <mjg59> 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 <helmut> sounds good. being biased (and personally affected) on this matter, I intend to abstain from voting
08:49:17 <tumbleweed> I think tech-ctte action can always feel like a threat
08:49:20 <spwhitton> mjg59: we can invite htem to reply off-list if anything like that is true
08:49:26 <tumbleweed> but we also need to get input from people, to decide
08:49:47 <helmut> the ctte is always too slow. setting deadlines is one of the few ways to not be too slow
08:49:57 <mjg59> 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 <tumbleweed> yes
08:50:06 <spwhitton> yes, good.
08:50:07 <Myon> the call might just serve the purpose of getting the message "we want to proceed, please leave input there" across
08:50:27 <spwhitton> alright, anyone want to write it?
08:50:42 <Myon> I would appreciate that over an "two weeks or shut up" message...
08:51:11 <mjg59> 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 <spwhitton> as we are running out of itme I shall action myself
08:54:58 <spwhitton> #action spwhitton to write to #1065416 with deadline as discussed
08:55:04 <spwhitton> #topic Any Other Business
08:55:10 <spwhitton> anyone got anything?
08:58:46 <spwhitton> okay!  thanks all.  productive meeting.
08:58:48 <spwhitton> #endmeeting