09:00:14 <Emperor> #startmeeting
09:00:14 <MeetBot> 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 <MeetBot> Useful Commands: #action #agreed #help #info #idea #link #topic.
09:00:24 <Emperor> Hi folks :)
09:00:28 <Emperor> #topic Roll Call
09:00:32 <Emperor> Matthew Vernon
09:00:32 <helmut> Helmut Grohne
09:00:43 <mjg59> Matthew Garrett
09:00:44 <Emperor> (we've had apologies from Stefano)
09:01:02 <Emperor> and Timo
09:02:25 <Emperor> Myon / tcs : you around?
09:04:20 <Emperor> 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 <seeS> Roll Call?
09:05:08 <mjg59> Ok, only missing myon?
09:05:21 <Emperor> 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 <seeS> Emperor, Craig Small, apologies for being late
09:06:22 <Emperor> #topic Review previous meeting's actions
09:07:16 <Emperor> 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 <Emperor> So I think let's carry that one over and I'll drop tumbleweed a line.
09:07:58 <Emperor> #action tumbleweed to seek explanation of waldi's concerns re linux-libc-dev Arch:any/all
09:08:09 <Emperor> #topic Bug #1091995: clarify authority of aliasing symbolic links
09:08:26 <helmut> I brought that up. Do you have any questions concerning the matter?
09:08:59 <Emperor> 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 <Emperor> 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 <mjg59> It doesn't seem like there's any more information to gain here
09:10:32 <Emperor> 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 <seeS> i was hoping for an answer
09:10:47 <Emperor> seeS: yeah, me too, I sent Luca a private email too and no response.
09:11:32 <helmut> yeah. I'll abstain from voting.
09:11:45 <mjg59> 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 <helmut> in principle, we could always add /usr/lib64 to base-files and then it would never trigger the bad code path
09:12:37 <seeS> 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 <mjg59> 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 <Emperor> seeS: my experience with Luca is that usually he's quite happy to tell me when I've got something wrong :)
09:13:37 <helmut> 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 <mjg59> 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 <helmut> how about adding it to the ballot for completeness sake?
09:15:48 <Emperor> 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 <mjg59> 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 <mjg59> It doesn't feel like it's providing an actual statement about how things should work
09:17:02 <Emperor> 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 <helmut> 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 <mjg59> ie, could the systemd code change such that they still carried out their documented behaviour and broke our expectations?
09:17:55 <mjg59> Emperor: I can as long as the end of next week is an acceptable timeframe
09:18:17 <Emperor> mjg59: yes, that's fine, thanks. I'm just really swamped this week and then away for a couple of weeks.
09:18:22 <helmut> mjg59: in case it is voted in my favour, I need to NMU before the toolchain freeze
09:18:40 <helmut> mjg59: I happen to not understand your question about systemd code change
09:19:37 <mjg59> 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 <mjg59> Or is that just an outcome of the current implementation?
09:19:49 <Emperor> 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 <helmut> mjg59: unsure, but the implementation is that if /usr/lib64 exists that it'll prefer pointing /lib64 there over /usr/lib
09:21:43 <Emperor> #action mjg59 to write ballot for #1091995
09:21:48 <helmut> anything else? or can we move on to the next item?
09:21:49 <mjg59> 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 <mjg59> But I don't think that's a big deal
09:22:22 <helmut> mjg59: systemd is mostly aligned to the kernel "never break abi", so chances are they cannot change that aspect anymore
09:22:22 <mjg59> 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 <Emperor> mjg59: thank you :)
09:22:38 <Emperor> #topic #1091864: Avahi and systemd-resolved cannot a run mDNS responder at the same time
09:22:40 <helmut> mjg59: thank you
09:23:21 <helmut> 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 <helmut> roughly speaking, we have two concurrent implementations  fighting over resolution and fighting over publishing
09:24:28 <helmut> 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 <mjg59> 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 <Emperor> 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 <helmut> we appear to have general consensus that avahi should be preferred when both are installed
09:25:32 <mjg59> My *mild* bias is to follow Fedora's lead because that's the less surprising outcome
09:25:36 <helmut> we disagree about the mechanism to implement that and we disagree about whether resolved should be enabled by default
09:25:57 <helmut> mjg59: that's what michael requests
09:26:33 <Emperor> I think I also felt that that (follow Fedora here) was likely the most sensible option.
09:26:45 <helmut> do you see a benefit in decoupling resolution from publishing in the ballot?
09:26:46 <mjg59> 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 <mjg59> (And Lennart was the original developer so it's not like resolved is written without awareness of potential issues here)
09:27:30 <helmut> my impression is that we have consensus among all parties that any decision should be time limited to trixie
09:27:36 <seeS_> i agree, i wish the systemd one did everything avahi does
09:28:32 <Emperor> helmut: I'm not sure I do see a benefit, but maybe that's just my desire for fewer options :)
09:29:01 <mjg59> In an abstract sense I do see value in that, but that's not the question that was brought to us
09:29:45 <helmut> 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 <Emperor> helmut: I think that looks good to me.
09:30:52 <mjg59> I slightly dislike (A) in that it defines the mechanism rather than just the policy
09:31:16 <mjg59> I don't know that there's a better policy, but if someone identified it what would the outcome be
09:31:17 <helmut> mjg59: sam critisized that already, I seem to not get it yet.
09:31:38 <Emperor> 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 <seeS_> ok so its either resolved disables its mDNS or avahi does it
09:31:45 <mjg59> 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 <helmut> mjg59: ok. I can turn it in an example
09:32:21 <seeS_> you cold have an out with "such as ...." or ".. or similiar mechanisms"
09:32:37 <mjg59> I don't think (z) exists but I dislike forcing mechanism if it's not strictly required
09:32:43 <helmut> mjg59: s/using/e.g. using/
09:32:59 <mjg59> helmut: That would answer my objection
09:33:07 <mjg59> As would Emperor's
09:33:10 <helmut> mjg59: thank you!
09:33:32 <helmut> any objections to calling for a vote on the updated ballot? (I can do)
09:33:40 <mjg59> No objection here
09:33:47 <Emperor> +1
09:33:51 <seeS_> Fine with me
09:34:12 <helmut> next topic?
09:34:16 <Emperor> #action helmut to call for a vote on #1091864
09:34:22 <Emperor> I'm getting there :)
09:34:37 <Emperor> #topic Bug #1065416: linux-libc-dev claims to provide linux-libc-dev-ARCH-cross, but it doesn't do that completely
09:34:56 <Emperor> This bug is getting me down, to be honest.
09:35:15 <helmut> heh. I've been dealing with it for more than a year!
09:35:47 <Emperor> tumbleweed seems hopeful that the parties are at the point of sorting it out themselves without further TC input.
09:35:49 <mjg59> helmut: We all owe you beer
09:36:28 <Emperor> he poked the bug on 27th Jan
09:37:08 <Emperor> 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 <seeS> 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 <Emperor> my concern is that the freeze is approaching and it's not (yet) resolved.
09:39:04 <mjg59> 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 <helmut> 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 <mjg59> And make it clear in the bug that we're going to intervene if it's not resolved by then?
09:40:10 <Emperor> 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 <helmut> I talked to Ben in november (toulouse) and he was also uneasy about representing the arguments
09:41:43 <Emperor> 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 <helmut> 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 <Emperor> 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 <helmut> 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 <Emperor> helmut: do you agree that it needs resolving one way or the other before the freeze?
09:44:35 <seeS> So its a matter of choosing one of those provide options? Or neither?
09:45:07 <helmut> 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 <Emperor> helmut: OK, put it another way - is there further cost to leaving it unresolved past the trixie freeze?
09:46:32 <helmut> 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 <helmut> kinda yes, we cannot change it between toolchain freeze and release
09:47:26 <Emperor> Sadness.
09:49:23 <helmut> 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 <helmut> part of waldi's request is not duplicating linux-libc-dev into linux-libc-dev-$arch-cross
09:50:31 <helmut> the arch:any vs arch:all matter is one that affects me, but not so much the reported dispute
09:52:39 <helmut> 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 <Emperor> 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 <Emperor> 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 <helmut> 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 <Emperor> helmut: OK. So leave the bug open for now, but no particular TC action at this time?
09:58:06 <Emperor> mjg59 / seeS any further thoughts on this bug?
09:58:12 <Emperor> we're nearly at time.
09:58:13 <mjg59> Seems fine
09:58:30 <helmut> Question: Do we have to decide on arch:any vs arch:all?
09:58:39 <seeS> no, i cant see any clear reason why to do one over the other
09:58:44 <helmut> (I did not formally forward that question)
09:59:12 <helmut> We are asked to decide about ownership of the linux-libc-dev-$arch-cross namespace. Can we answer that question already?
09:59:53 <helmut> 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 <Emperor> 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 <mjg59> I need to drop nowish (2AM here)
10:01:52 <mjg59> I'm ok leaving this longer but it does seem like we should try to resolve the issue
10:02:16 <mjg59> It's not the most urgent thing but letting this drag forever doesn't seem like it benefits anyone
10:02:23 <Emperor> I also have to drop soon.
10:02:31 <helmut> +1
10:02:52 <Emperor> helmut: would you be able to summarise the issue by email / to the bug report?
10:03:07 <helmut> I feel I'm way too biased on this matter to be objective
10:03:40 <Emperor> 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 <helmut> it's also one where I'd abstain voting
10:04:51 <Emperor> #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 <Emperor> (which is how we've ended up with tumbleweed trying to chase people for months to get some clarity)
10:05:54 <helmut> 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 <Emperor> OK, I'll email stefano.
10:06:31 <Emperor> #action Emperor to ask tumbleweed for a summary on #1065416
10:06:40 <Emperor> we're really out of time now
10:06:44 <Emperor> #topic AOB
10:06:50 <Emperor> any really pressing AOB?
10:07:11 <helmut> can we roughly agree on a week for the next meeting?
10:07:29 <helmut> I'm relatively busy in the second half of feb
10:07:45 <Myon> sorry I failed to note the date :-/
10:08:01 <Emperor> I'm away all of w/c 10 Feb and much of w/c 18 Feb
10:08:47 <Emperor> helmut: so maybe w/c 3 Mar?
10:09:06 <Emperor> (the following week is daylight confusion week, for bonus fun)
10:09:08 <seeS> Most weeks dont change for me, its the time that is the issue (GMT+11)
10:09:29 <helmut> late but ack
10:09:32 <mjg59> No particulra constraints on my side
10:09:52 <Emperor> OK, I'll maybe look at last week Feb or 1st March then
10:09:59 <Emperor> sorry, I've got to run now.
10:10:03 <Emperor> #endmeeting