09:00:14 #startmeeting 09:00:14 Meeting started Tue Feb 4 09:00:14 2025 UTC. The chair is Emperor. Information about MeetBot at http://wiki.debian.org/MeetBot. 09:00:14 Useful Commands: #action #agreed #help #info #idea #link #topic. 09:00:24 Hi folks :) 09:00:28 #topic Roll Call 09:00:32 Matthew Vernon 09:00:32 Helmut Grohne 09:00:43 Matthew Garrett 09:00:44 (we've had apologies from Stefano) 09:01:02 and Timo 09:02:25 Myon / tcs : you around? 09:04:20 That's a bit vexing, there are currently 7 members of the committee, 6 of whom said they could make this slot; we had apologies from 1 of those six, but there should still be 5 of us here. 09:04:38 Roll Call? 09:05:08 Ok, only missing myon? 09:05:21 seeS: ah, hello. It's where people who are here say they're here for the minutes (and so I know who is here) :) 09:05:41 Emperor, Craig Small, apologies for being late 09:06:22 #topic Review previous meeting's actions 09:07:16 3 actions, all of which did get done, although we didn't actually get anything useful out of tumbleweed's poke. He said he'd try talking to individuals rather than just pinging the bug. 09:07:45 So I think let's carry that one over and I'll drop tumbleweed a line. 09:07:58 #action tumbleweed to seek explanation of waldi's concerns re linux-libc-dev Arch:any/all 09:08:09 #topic Bug #1091995: clarify authority of aliasing symbolic links 09:08:26 I brought that up. Do you have any questions concerning the matter? 09:08:59 I'm going to assume my summary of Luca's objections in https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1091995#25 is correct 09:09:49 At which point I'm inclined to think they're not really very convincing. In any case, I think this bug is probably at the point where we should vote on it. 09:10:28 It doesn't seem like there's any more information to gain here 09:10:32 So, err, any objections to trying to move this one to a vote? And volunteer to write the ballot? obviously that can't be helmut who has to sit the vote out 09:10:33 i was hoping for an answer 09:10:47 seeS: yeah, me too, I sent Luca a private email too and no response. 09:11:32 yeah. I'll abstain from voting. 09:11:45 It doesn't look like there's a path to a negotiated settlement here so I agree that we're looking at a vote 09:12:25 in principle, we could always add /usr/lib64 to base-files and then it would never trigger the bad code path 09:12:37 Damn, because my issue is that I read it and go ok I think Matthew's nicely summarised it, but maybe we've missed something 09:13:10 helmut: Ugh yeah we *could* and half my professional life has been implementing bodges to avoid someone else's breakage, and that just doesn't seem necessary in this case 09:13:34 seeS: my experience with Luca is that usually he's quite happy to tell me when I've got something wrong :) 09:13:37 mjg59: I'm not a fan of that but I wanted to mention it as a possible alternative 09:14:00 * Emperor also unkeen on that idea 09:14:04 helmut: I appreciate the commitment to providing the complete set of options, and I've actually been carrying that over to my day job 09:14:44 how about adding it to the ballot for completeness sake? 09:15:48 that doesn't seem unreasonable (I'd rather not overly-complex ballots, but this seems like an option someone might want to vote for). 09:15:59 I'm ok with that, but I'd kind of like a mechanism to provide the context that this is a hack based on the precise implementation of the relevant code 09:16:40 It doesn't feel like it's providing an actual statement about how things should work 09:17:02 mjg59: would you mind drafting a ballot for this? You could include some note to that effect with the relevant ballot option :) 09:17:18 and yet another option would be to just leave it broken and fix it up whenever base-files.preinst is run (which is what bluca seems to favour) 09:17:32 ie, could the systemd code change such that they still carried out their documented behaviour and broke our expectations? 09:17:55 Emperor: I can as long as the end of next week is an acceptable timeframe 09:18:17 mjg59: yes, that's fine, thanks. I'm just really swamped this week and then away for a couple of weeks. 09:18:22 mjg59: in case it is voted in my favour, I need to NMU before the toolchain freeze 09:18:40 mjg59: I happen to not understand your question about systemd code change 09:19:37 helmut: Ah, sorry, I mean if we add /usr/lib64 to base-files is the documented behaviour of the systemd code that that will never be overwritten? 09:19:48 Or is that just an outcome of the current implementation? 09:19:49 votes last for a week. End of next week would be 14th Feb. That plus a week is 21 Feb, which should be time to NMU before freeze on 15 March 09:20:28 mjg59: unsure, but the implementation is that if /usr/lib64 exists that it'll prefer pointing /lib64 there over /usr/lib 09:21:43 #action mjg59 to write ballot for #1091995 09:21:48 anything else? or can we move on to the next item? 09:21:49 helmut: Yeah, my concern is that simply doing something that aligns with the current implementation doesn't necessarily guarantee that it'll work forever 09:21:54 But I don't think that's a big deal 09:22:22 mjg59: systemd is mostly aligned to the kernel "never break abi", so chances are they cannot change that aspect anymore 09:22:22 I'll try to draft the ballot this week, get internal feedback, and we can post towards the end of next week 09:22:35 mjg59: thank you :) 09:22:38 #topic #1091864: Avahi and systemd-resolved cannot a run mDNS responder at the same time 09:22:40 mjg59: thank you 09:23:21 I've acted as moderator her and sought feedback from michael and jeremy. no feedback from bluca, but his position seems reasonably clear 09:23:47 roughly speaking, we have two concurrent implementations fighting over resolution and fighting over publishing 09:24:28 the publishing causes a service start failure (as both attempt to bind the same port) and the resolution is ordered such that avahi doesn't resolve when resolved is enabled 09:24:38 I don't have a strong feeling about any outcome here, except that I don't want us to accidentally do anything that prevents a technical decision to have .local resolution work out of the box 09:25:17 I think we should make a decision in time for the trixie freeze, and that decision should probably limit itself to trixie 09:25:18 we appear to have general consensus that avahi should be preferred when both are installed 09:25:32 My *mild* bias is to follow Fedora's lead because that's the less surprising outcome 09:25:36 we disagree about the mechanism to implement that and we disagree about whether resolved should be enabled by default 09:25:57 mjg59: that's what michael requests 09:26:33 I think I also felt that that (follow Fedora here) was likely the most sensible option. 09:26:45 do you see a benefit in decoupling resolution from publishing in the ballot? 09:26:46 My other long term mild bias is that Avahi is an almost two decade old codebase without the original developers involved and that's not necessarily the correct long term bet 09:27:28 (And Lennart was the original developer so it's not like resolved is written without awareness of potential issues here) 09:27:30 my impression is that we have consensus among all parties that any decision should be time limited to trixie 09:27:36 i agree, i wish the systemd one did everything avahi does 09:28:32 helmut: I'm not sure I do see a benefit, but maybe that's just my desire for fewer options :) 09:29:01 In an abstract sense I do see value in that, but that's not the question that was brought to us 09:29:45 there is a proposed ballot (for unified resolve/publish) in https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1091864#64 objections? 09:30:44 helmut: I think that looks good to me. 09:30:52 I slightly dislike (A) in that it defines the mechanism rather than just the policy 09:31:16 I don't know that there's a better policy, but if someone identified it what would the outcome be 09:31:17 mjg59: sam critisized that already, I seem to not get it yet. 09:31:38 mjg59: would you prefer 'To achieve this, avahi-daemon should disable systemd-resolved using a resolved configuration file (or some other suitable mechanism).' ? 09:31:38 ok so its either resolved disables its mDNS or avahi does it 09:31:45 If we say "Fix (x) by doing (y)" and someone figures out that they can fix (x) by doing (z), would that satisfy the ballot? 09:32:14 mjg59: ok. I can turn it in an example 09:32:21 you cold have an out with "such as ...." or ".. or similiar mechanisms" 09:32:37 I don't think (z) exists but I dislike forcing mechanism if it's not strictly required 09:32:43 mjg59: s/using/e.g. using/ 09:32:59 helmut: That would answer my objection 09:33:07 As would Emperor's 09:33:10 mjg59: thank you! 09:33:32 any objections to calling for a vote on the updated ballot? (I can do) 09:33:40 No objection here 09:33:47 +1 09:33:51 Fine with me 09:34:12 next topic? 09:34:16 #action helmut to call for a vote on #1091864 09:34:22 I'm getting there :) 09:34:37 #topic Bug #1065416: linux-libc-dev claims to provide linux-libc-dev-ARCH-cross, but it doesn't do that completely 09:34:56 This bug is getting me down, to be honest. 09:35:15 heh. I've been dealing with it for more than a year! 09:35:47 tumbleweed seems hopeful that the parties are at the point of sorting it out themselves without further TC input. 09:35:49 helmut: We all owe you beer 09:36:28 he poked the bug on 27th Jan 09:37:08 He was going to mail people individually after a bit if that produced no response; I propose asking him to do so in the next week or so. 09:37:48 It does look like it might be ok possibly, I agree just ask them. If not try to find what the residual issues are 09:38:27 my concern is that the freeze is approaching and it's not (yet) resolved. 09:39:04 Should we give them another week and a half and look for an emergency meeting on this topic only if no movement? 09:39:23 to this date, I still fail to understand the benefits of having an arch:all linux-libc-dev and appreciate someone writing them down. the biggest part I see is fewer packages and mirror space being saved. 09:39:26 And make it clear in the bug that we're going to intervene if it's not resolved by then? 09:40:10 helmut: AFAICT (and I may be wrong), it is waldi who has previously advanced that position and is now declining to expand on their reasoning. 09:40:56 I talked to Ben in november (toulouse) and he was also uneasy about representing the arguments 09:41:43 I'm starting to feel limited sympathy for a position that is causing a lot of hassle but no-one seems to want to actually put together a coherent argument in favour of 09:42:55 let me note that due to all the refactoring that waldi did, it is not a simple switch back to arch:any anymore. it requires real effort to provide such a patch 09:43:02 helmut: of the people here you've been most involved in understanding this issue; what do you feel about mjg59's suggestion of saying we will intervene if there's not progress soon? 09:43:52 putting up a deadline is good, however it now feels unclear what kind of intervening that could be as there is no code that could readily be NMUed (or uploaded by Ben) 09:44:26 helmut: do you agree that it needs resolving one way or the other before the freeze? 09:44:35 So its a matter of choosing one of those provide options? Or neither? 09:45:07 Emperor: it needed resolving way earlier. to me what happens in a stable release does not matter much. it is unstable I care about when it comes to cross/bootstrap 09:46:22 helmut: OK, put it another way - is there further cost to leaving it unresolved past the trixie freeze? 09:46:32 it does matter to others. people more and more approach me about cross bugs in stable, but I tend to call that unsupported 09:46:52 kinda yes, we cannot change it between toolchain freeze and release 09:47:26 Sadness. 09:49:23 it also is more nuanced that you picture it now. doko's request is not switching back to arch:any. doko's request is not interfering with linux-libc-dev-$arch-cross afaiui 09:50:07 part of waldi's request is not duplicating linux-libc-dev into linux-libc-dev-$arch-cross 09:50:31 the arch:any vs arch:all matter is one that affects me, but not so much the reported dispute 09:52:39 coming back to your earlier question about timing. personally, I prefer a sound solution over a quick solution I guess. I do have work arounds for the status quo now. 09:53:21 helmut: so you'd rather we just keep getting tumbleweed to try and get the participants to actually give the TC and update? 09:54:47 If that's so, I'd defer to you since you know this issue much better than I do, it just feels like we're not making any headway (or adding much of value) to this issue. 09:55:38 I don't see that happening in any way. I suspect that design work may be required. I'll add it to https://wiki.debian.org/Sprints/2025/BootstrapCrossbuild in any case 09:57:32 helmut: OK. So leave the bug open for now, but no particular TC action at this time? 09:58:06 mjg59 / seeS any further thoughts on this bug? 09:58:12 we're nearly at time. 09:58:13 Seems fine 09:58:30 Question: Do we have to decide on arch:any vs arch:all? 09:58:39 no, i cant see any clear reason why to do one over the other 09:58:44 (I did not formally forward that question) 09:59:12 We are asked to decide about ownership of the linux-libc-dev-$arch-cross namespace. Can we answer that question already? 09:59:53 We asked Waldi to temporarily release that name until we would come up with a decision and he complied. It feels fair to get him a decision before trixie on that particular question. 10:01:01 I don't know is the short answer; I kindof feel we circled that question months ago and then got lost in the weeds of trying to get answers out of the various parties, and now here we are 10:01:23 I need to drop nowish (2AM here) 10:01:52 I'm ok leaving this longer but it does seem like we should try to resolve the issue 10:02:16 It's not the most urgent thing but letting this drag forever doesn't seem like it benefits anyone 10:02:23 I also have to drop soon. 10:02:31 +1 10:02:52 helmut: would you be able to summarise the issue by email / to the bug report? 10:03:07 I feel I'm way too biased on this matter to be objective 10:03:40 I think in the circumstances, I'd take a biased summary. I worry the alternative is we have a meeting in a month and start from 0 again 10:03:41 it's also one where I'd abstain voting 10:04:51 #1065416 has 309 updates, at least two linked bugs with lengthy discussion, and I doubt I'm the only TC member who feels a bit lost as to where the key issues outstanding are 10:05:11 (which is how we've ended up with tumbleweed trying to chase people for months to get some clarity) 10:05:54 arguably stefano is moderator there and I'd hope him to have a high level view. I am happy to review a summary on technical grounds. 10:06:12 OK, I'll email stefano. 10:06:31 #action Emperor to ask tumbleweed for a summary on #1065416 10:06:40 we're really out of time now 10:06:44 #topic AOB 10:06:50 any really pressing AOB? 10:07:11 can we roughly agree on a week for the next meeting? 10:07:29 I'm relatively busy in the second half of feb 10:07:45 sorry I failed to note the date :-/ 10:08:01 I'm away all of w/c 10 Feb and much of w/c 18 Feb 10:08:47 helmut: so maybe w/c 3 Mar? 10:09:06 (the following week is daylight confusion week, for bonus fun) 10:09:08 Most weeks dont change for me, its the time that is the issue (GMT+11) 10:09:29 late but ack 10:09:32 No particulra constraints on my side 10:09:52 OK, I'll maybe look at last week Feb or 1st March then 10:09:59 sorry, I've got to run now. 10:10:03 #endmeeting