20:00:00 <Emperor> #startmeeting
20:00:00 <MeetBot> Meeting started Mon Mar  3 20:00:00 2025 UTC.  The chair is Emperor. Information about MeetBot at http://wiki.debian.org/MeetBot.
20:00:00 <MeetBot> Useful Commands: #action #agreed #help #info #idea #link #topic.
20:00:05 <Emperor> hi folks
20:00:11 <Emperor> #topic Roll call
20:00:14 <Emperor> Matthew Vernon
20:00:19 <seeS> Craig Small
20:00:24 <Myon> Christoph Berg
20:00:33 <tumbleweed> Stefano Rivera
20:01:36 <Emperor> mjg59 / roehling ?
20:02:17 <mjg59> Matthew Garrett
20:02:50 <Emperor> let's give roehling another couple of minutes, then get going
20:04:20 <Emperor> #topic Review actions from previous meeting
20:04:21 <helmut> Helmut Grohne
20:04:29 <Emperor> hi :)
20:04:53 <Emperor> mjg59 wrote the ballot for #1091995 and helmut called for a vote on #1091864
20:05:19 <helmut> avahi vs systemd has been cloned as a bug to systemd and reported to #d-devel
20:05:24 <helmut> err d-devel@l.d.o
20:05:27 <Emperor> I asked tumbleweed for a summary of #1065416 (and there was a reply, thanks)
20:05:44 <Emperor> ...and we'll come back to that bug later.
20:05:49 <tumbleweed> OK
20:06:45 <Emperor> Both #1091995 and #1091864 are overrules of the systemd maintainers. Given the lack of response to the avahi issue and the pending freeze, I think an NMU is likely in order?
20:07:23 <helmut> I'd appreciate a review of how avahi vs systemd went process/moderation wise, but that feedback can be outside the meeting
20:07:47 <Emperor> I think that's a good question, but not sure we'll have time today.
20:07:55 <Myon> (imho it went well)
20:08:00 <Emperor> maybe people should mail you and/or the committee list about that
20:08:26 <Emperor> Any views on next steps for the two bugs we've just concluded voting on?
20:09:04 <helmut> base-files vs systemd needs to be communicated to d-d or d-d-a
20:09:41 <Emperor> yes, I think d-d (and I can write that email)
20:10:08 <helmut> ideally $someone who is not me pings luca about uploading the requested changes. failing that, I am happy to coordinate a NMU with michael
20:10:41 <Emperor> helmut: shall I ping bluca, and if I don't hear anything in the next few days, you can co-ordinate the NMU for both bugs with michael?
20:10:47 <helmut> #action Emperor to report systemd vs base-files to d-d@l.d.o
20:11:18 <helmut> a few days seems rude to me.
20:11:38 <Emperor> I'm torn between seeming rude and making sure we don't interfere with the freeze process
20:12:06 <Emperor> I guess the soft freeze is 2025-04-15 so as long as the upload is done in March we should be OK.
20:12:15 <helmut> I can seek feedback from the release team. neither is a transition though
20:12:38 <helmut> from a release process, both changes should be simple rc bugs
20:12:59 <Emperor> helmut: if I wait 2 weeks, that would be ~17 March, seem a reasonable period?
20:13:29 <helmut> how about seeking feedback from release team? and deferring the timing decision for tomorrow?
20:13:48 <helmut> you may action me about the feedback
20:13:54 <seeS> Hmm, transistion freeze is 15th. I think asking release team is a good idea for timing. I don't think it will impact them but..
20:14:48 <Emperor> seeS: as helmut says neither change is a transition, and systemd isn't a "tootlchain" package per https://release.debian.org/testing/essential-and-build-essential.txt
20:14:52 <Emperor> toolchain
20:15:28 <seeS> I agree, so its not one of those "hard nos" but more does it impact the release team in another way
20:15:34 <Myon> given the freeze and bluca's usual activity level, 2 weeks seem very long
20:15:43 <Myon> he should be able to at least say something faster
20:16:22 <Emperor> [I did email one of the release managers last week, but didn't get a response]
20:16:45 <helmut> one of them kinda is a coworker for me :)
20:16:58 <Emperor> OK
20:17:13 <Emperor> #action helmut to check with Release Team about timescales for systemd bugfixes
20:17:20 <seeS> I got an answer on a different non-TC matter in about 2 weeks.
20:17:40 <Emperor> #action Emperor to mail bluca re systemd fix implementation
20:18:01 <Emperor> #action helmut to work on NMU for systemd fixes if relevant given previous actions
20:18:05 <helmut> proposal: set 17th as deadline indicating that we may push the deadline forward if the release team recommends that
20:18:13 <Emperor> +1
20:18:34 <mjg59> Sounds good to me
20:19:27 <Emperor> seeS / Myon / tumbleweed: happy with that as a proposal?
20:19:36 <Myon> ack
20:19:39 <seeS> Yes, it seems like a reasonable way forward
20:19:43 <tumbleweed> yep
20:20:05 <Emperor> #Agreed take 17th as deadline subject to release team feedback
20:20:15 <Emperor> #topic Recruitment
20:20:38 <Emperor> we'll do this on jitsi as usual - see #debian-ctte-private for the URL
20:20:57 <Emperor> (or /msg me if that's not convenient)
20:40:54 <Emperor> #action Emperor to email the private list per jitsi discussion
20:41:35 <Emperor> #topic Bug #1065416: linux-libc-dev claims to provide linux-libc-dev-ARCH-cross, but it doesn't do that completely
20:41:50 <tumbleweed> right
20:42:16 <doko> o/
20:42:27 <Emperor> hi doko
20:42:39 <tumbleweed> so in early Feb I gave things a push again and spoke to doko and waldi privately too
20:43:02 <tumbleweed> doko and I have been chatting on the side in the last hour, too
20:43:28 <tumbleweed> I think I have a better idea of where the red lines are, and we can try to push things forward
20:44:10 <Emperor> Cool. Do you want to talk more about that now? or see how that pans out and come back to the next meeting?
20:44:19 <tumbleweed> doko: I see that you want to continue to maintain linux-libc-dev-*-cross, so different provides names should be used in linux-libc-dev
20:45:14 <tumbleweed> I *think* that won't be too contentious, but let's see...
20:45:50 <doko> that's what I suggest, yes. Let's say, there's also a social component to that issue. Plus providing these symlinks in linux-libc-dev would pollute not only the name space in /usr/include, but also in /usr
20:46:19 <tumbleweed> I note that the arch:all linux-libc-dev package continues to cause issues for people, but that wasn't strictly the issue that was raised to us, and mitigations for some of it is being figured out
20:46:36 <doko> the worst thing that can happen is, that these headers can be out of date for a bit of time. but I didn't see any issues with that in the past
20:47:10 <tumbleweed> I assume in helmut's rebootstrapping case, he'll be using linux-libc-dev rather than the cross-toolchain-base -cross packages, anyway
20:47:25 <helmut> I concur with tumbleweed and doko, but I note that waldi takes issue with the duplication caused by c-t-b and l-l-d-*-c
20:48:03 <helmut> tumbleweed: there are presently two bootstrapping variants one of which uses l-l-d and the other uses dpkg-cross and l-l-d-*-c
20:48:29 <tumbleweed> ok
20:49:13 <doko> well, I could merge these into libc6-dev-cross-<arch>. then he cannot provide that package ...
20:49:39 <helmut> in principle, there could be an arch:all linux-libc-dev-cross package providing linux-libc-dev-*-cross and putting up the /usr/<triplet>/include/* symlinks
20:51:02 <tumbleweed> which wouldn't be duplicating anything, just providing scaffoling
20:51:06 <doko> and again, even more polluting the namespace for 99% of our users
20:51:31 <helmut> only cross builders would ever install linux-libc-dev-cross
20:51:53 <Emperor> [I'm going to gently note here that the TC shouldn't be doing detailed design work itself]
20:53:23 <doko> how many crosses do you use at the same time?
20:54:00 <helmut> afaiui, the duplication (into packages built from multiple source packages) aspect is one of the main disagreements. what I understand from waldi is that he wants src:linux to own those files and doko wants src:c-t-b to own those files.
20:55:41 <tumbleweed> although, waldi doesn't really want to own /usr/<triplet>/include/ (because insufficiently documented)
20:55:50 <Emperor> 4 minutes
20:56:04 <helmut> doko: it's 1, but I don't think the answer matters. if you take issue with that pollution, you take issue with linux-libc-dev being arch:all in the first place.
20:56:12 <tumbleweed> and I think doko wants to own the -cross namespace
20:57:16 <tumbleweed> Emperor: I assume there's nothing else we need to cover?
20:57:23 <helmut> is linux-libc-dev arch:all vs arch:any a disagreement that the ctte should decide upon? thus far my understanding was that whilst there is disagreement about it, that question was not referred.
20:57:47 <Emperor> unless anyone has an AOB, no - if you do, /msg me and I'll try and make sure we squeeze it in [but otherwise, I'll let this discussion run]
20:58:24 <doko> mehh, maybe we should ban -dev packages being arch:all in policy ...
20:58:38 <tumbleweed> I think there's probably a useful policy discussion to be had there
20:59:02 <tumbleweed> there are cases where arch:all -dev are prolbematic (esp. deep in the toolchain)
20:59:19 <tumbleweed> doko: thanks for coming to cover this issue in the meeting
20:59:27 <helmut> doko: I have an argument with rene about that for libmdds-dev #843023
21:00:24 <doko> according to the bug number, that seems to be a long going argument ;)
21:00:42 <Emperor> I have to vanish quite soon, sorry.
21:00:57 <doko> another one is the cmake/cmake-data dependency, but offtopic here
21:01:17 <helmut> doko: did/do you refer the arch:all vs arch:any question to the ctte?
21:02:40 <doko> does it need to go to the ctte? not to debian-policy first?
21:03:34 <Emperor> the question referred to the cttee is laid out by waldi in https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1065416#118
21:03:38 <tumbleweed> helmut's point is that we are explicitly not trying to get involved in that question
21:03:49 <doko> ahh, ok
21:03:57 <tumbleweed> I dug into it a bit because I saw it was a sticking point in the discussion
21:04:14 <tumbleweed> but I wasn't trying to change anything, just understand the reasons behind the change
21:04:37 <Emperor> "Please decide who is going to provide linux-libc-dev and all the associated cross stuff and how it should look like."
21:05:22 <helmut> apt-cache show "*" |  grep-dctrl -FArchitecture all --and -FPackage --regex '.*-dev$' --and --not -FSection golang # 700 packages
21:06:21 <helmut> I don't think policy maintainers are going to make 700 packages rc buggy
21:06:45 <tumbleweed> I reasonable policy transition there would probably start as a recommendation
21:06:50 <Emperor> the cowards ;)
21:06:51 <tumbleweed> s/I/A/
21:07:11 <tumbleweed> but policy tends to follow consensus, so yes we'd have to have some project consensus first
21:07:48 <Myon> lots of golang/rust/php in that list, though
21:09:04 <seeS> I've got to head off now. Work's starting
21:09:08 <seeS> seeyou all lateer
21:09:26 <Emperor> sorry, I do have to vanish now. I'm going to end the meeting (otherwise it'll run until I'm next in front of a keyboard), but do feel free to continue this discussion as long as it's constructive. Do note any conclusions / next steps somewhere though.
21:09:28 <Emperor> #endmeeting