19:00:12 <roehling> #startmeeting
19:00:12 <MeetBot> Meeting started Wed Feb  4 19:00:12 2026 UTC.  The chair is roehling. Information about MeetBot at https://wiki.debian.org/MeetBot.
19:00:12 <MeetBot> Useful Commands: #action #agreed #help #info #idea #link #topic.
19:00:33 <roehling> Welcome to our TC meeting!
19:00:38 <roehling> #topic Roll Call
19:00:40 <helmut> Helmut Grohne
19:00:45 <roehling> Timo Röhling
19:00:46 <tumbleweed> Stefano Rivera
19:01:00 <Emperor> Matthew Vernon
19:01:01 <taffit> David Prévot
19:03:55 <mjg59> Matthew Garrett
19:04:30 <paultag> Paul Tagliamonte
19:04:57 <roehling> Does anyone know if seeS can make it today?
19:05:57 <roehling> Alright, let's begin.
19:06:01 <Emperor> roehling: did they reply to the poll? If not, I'd assume no
19:06:13 <roehling> They did.
19:06:33 <Emperor> Oh, OK, in which case if they said they could do this time I'd drop them an email later
19:07:00 <roehling> #topic Welcome to taffit
19:07:20 <roehling> For the first topic, we'll meet in the Jitsi channel for a personal meet & greet
19:07:20 <helmut> \o/
19:07:34 <taffit> o/
19:17:17 <roehling> Back from Jitsi
19:17:41 <roehling> #topic Bug #1106402 dpkg-source, native source package format with non-native version
19:17:59 <roehling> I have been moderator for this bug, and it is *almost* done.
19:18:27 <helmut> Did anyone follow up on the hard deprecations impacting backportability of dgit?
19:19:02 <roehling> After the latest dpkg upload, I reached out to Ian to confirm that dpkg the version handling works as intended.
19:19:19 <roehling> I haven't gotten a reply yet, though.
19:19:21 <Emperor> that's #1123630 et al?
19:20:52 <roehling> That is the follow-up bug, yes.
19:21:16 <helmut> I am with both Guillem here in that the naming is now unfortunate and with Ian that the deprecation cycle is too fast.
19:22:25 <Emperor> I must confess it felt rather that the deprecation cycle was more about signalling displeasure at the TC decision.
19:24:11 <roehling> I think there is some fundamental disagreement whether or not a native version number should also imply a native package.
19:24:24 <Emperor> (but that's more a community team issue than a TC one)
19:25:25 <roehling> I agree with Helmut on both counts. The naming is misleading, but the deprecation could have been handled more gracefully
19:25:39 <helmut> The naming has become misleading as a result of our decision.
19:25:51 <Emperor> We didn't issue a ruling on the question because Guillem made a change that rendered the question somewhat moot
19:26:13 <helmut> How about asking him kindly to support the old function in forky without stderr output?
19:27:16 <roehling> Sounds good to me
19:27:30 <tumbleweed> his suggested backwards-compatibility option (API consumers supporting both new and old methods) *is* workable, if ugly
19:28:06 <Emperor> helmut: +1
19:28:36 <Emperor> that makes the deprecation cycle rather easier for folk to manage, but stil gets it done reasonably rapidly.
19:28:40 <tumbleweed> +1
19:29:04 <tumbleweed> I have hard time imagining he'd deprecate APIs this quickly for other changes
19:29:11 <helmut> exactly
19:29:18 <roehling> I also wouldn't mind if the documentation had a big fat warning that is_native is no longer a proxy for native package detection
19:30:59 <roehling> helmut, can you email Guillem and ask for this change?
19:31:12 <roehling> (the function alias, not the documentation bit)
19:31:50 <tumbleweed> and acknowledge that his suggested workarounds do work, but centralizing this in dpkg for one cycle makes things easier for everyone
19:32:04 <helmut> roehling: can I turn that down?
19:32:51 <tumbleweed> I can volunteer if that helps
19:33:03 <roehling> In that case, yes, helmut, you can turn it down :)
19:33:49 <roehling> #action tumbleweed to ask Guillem for a more relaxed Version->is_native deprecation re #1123630
19:33:58 <tumbleweed> ack
19:34:23 <roehling> Any other comments regarding this bug?
19:35:05 <roehling> #topic Bug #1125411 tech-ctte: Unbound resolvconf hook default breaks recursive resolution
19:35:29 <helmut> I am a moderator on this. Given that I very much share view with mjt, I talked with lrob a lot.
19:35:57 <helmut> His position roughly is that unbound is described as a recursive resolver and should not be turned into a forwarding one by installing another package.
19:36:06 <mjg59> I feel like the conversation maybe got a little disconected here. Helmut is saying that he would not be inclined to overrule the maintainer, but the maintainer is free to change behaviour if desired?
19:36:26 <helmut> mjg59: yes, if we decline, mjt can still agree with lrob
19:36:44 <tumbleweed> we should reply and make that clear
19:37:00 <taffit> +1
19:37:02 <mjg59> I agree that the behaviour is consistent with the goals of resolvconf, and also potentially unexpected, and I think both positions are sufficiently valid that this isn't obviously a ctte matter
19:37:04 <Emperor> someone should also tell lrob that their most recent contribution was not really acceptable
19:37:25 <mjg59> I can take that
19:37:28 <helmut> The arguments in favor of his position mainly relate to the connection between resolvconf and forwarding not being obvious, resolvconf being preinstalled and forwarding being a privacy risk
19:37:36 <Emperor> mjg59: thanks :)
19:37:49 <tumbleweed> I think both positions are sufficiently valid to all of us, but lrob doesn't appear to see the other side
19:38:00 <tumbleweed> they're taking a very principled view on it
19:38:35 <paultag> as someone who has operated a lot of unbounds, I was suprised, although, I do very much understand both angles here. lrob's last email wasn't helpful for sure.
19:38:50 <tumbleweed> yeah, was suprised too
19:39:00 <paultag> i'm mostly suprised unbound was used for local resolution with resolvconf tbh
19:39:03 <Emperor> Making the operation of resolvconf in this regard a bit clearer wouldn't be bad
19:39:06 <paultag> yeah
19:39:20 <tumbleweed> Emperor: the problem is that we have no good way to make this clearer to a user
19:39:23 <helmut> How would you feel about my drafting a ballot that declines overruling mjt indicating 1. we do not prevent mjt from agreeing with lrob 2. we see resolvconf as opting in and suggest improving its package description
19:39:30 <tumbleweed> when the API is: when both packages are installed, behavior is X
19:39:46 <tumbleweed> I mean, postinst could print a warning...
19:40:25 <Emperor> I think that would be suitable if "most people who have unbound installed probably do not want resolvconf as well" were true
19:40:32 <roehling> Should we involve the resolvconf maintainers in this discussion?
19:40:59 <helmut> roehling: good idea. andrew shadura usually is responsive
19:41:07 <Emperor> (I've only used unbound in situations where I wanted the DNSSEC validation, but I don't know what folks' usual usecases are)
19:41:19 <paultag> the fact opinions have shifted during this discussion makes me think it came to us too early, and could use a lot of "ok talk about it first y'all, you may actually agree"
19:41:36 <paultag> this seems like a "fix this", "no", "ok ctte time"
19:41:41 <tumbleweed> yep
19:41:43 <mjg59> Yeah, it's not clear that there's anything for us to overrule at this stage
19:42:22 <mjg59> I think let's just make clear that we are not imposing anything on the maintainer, that discussion should continue, and that the tone of the most recent mail was inappropriate
19:42:44 <mjg59> I don't think we should go for a ballot at this stage
19:43:10 <paultag> yeah, agree
19:43:15 <helmut> That's a lot of useful feedback and I agree with your views.
19:44:12 <roehling> #agreed We let the discussion ripen further before deciding on any official TC act
19:45:18 <roehling> #action mjg59 to respond to lrob's latest mail
19:45:33 <helmut> Shall I reach out to Andrew?
19:45:48 <Emperor> seems a good idea
19:45:59 <roehling> yes, good idea
19:46:12 <roehling> #action helmut to solicit the resolvconf maintainer's view
19:46:54 <helmut> Is anyone aware of particular other packages that influence other packages in similar ways? blends such as freedombox come to mind, but it is not exactly the same
19:47:39 <helmut> also note that systemd-resolved having taken over resolvconf's API also means that the resolvconf package is becoming less popular
19:49:00 <helmut> linux-sysctl-defaults does influence systemwide behavior (e.g. the way /tmp can be used)
19:49:44 <tumbleweed> one package altering config for another package is something that should probably only happen when both maintainers are in agreement
19:50:05 <tumbleweed> (the systemd-resolved + avahi thing recently was an example of this, that didn't happen in the end, due to our decision)
19:50:29 <Emperor> agreement> definitely (I suspect policy says as much)
19:50:58 <helmut> well, mjt did install the resolvconf integration into unbound. it's not like that aspect was part of resolvconf
19:51:42 <tumbleweed> right
19:52:11 <helmut> debianutils /usr/share/debianutils/shells.d is an interface for managing /etc/shells
19:52:25 <tumbleweed> and there are other ways they could have dealt with accessing captive portals through unbound
19:52:32 <roehling> Given that there is no obviously right solution, I'm wondering if this should become a debconf question.
19:52:49 <roehling> It's annoying, but at least removes the element of surprise
19:52:52 <tumbleweed> yeah
19:53:02 <paultag> that would definitely solve the awareness issue
19:53:09 <helmut> maybe gnome-keyring taking over the agent functionality upon installation is more similar
19:53:55 <helmut> roehling: I don't think so, because there is no point in installing resolvconf with unbound unless you want the forwarding behavior
19:54:27 <roehling> ack
19:54:28 <helmut> though debconf can be preseeded with puppet/ansible/chef at least
19:54:29 <tumbleweed> or... it's already installed
19:54:32 <tumbleweed> (like lrob)
19:54:52 <roehling> Anyway, I think we should move on to the next topic, we are almost out of time
19:54:55 <tumbleweed> I wouldn't be suprised if there were clouds that had resolveconf in their images (as legacy)
19:55:04 <helmut> I anticipate that resolvconf will be more rarely installed as cloud-init uses resolved
19:55:19 <tumbleweed> yeah, it's on the way out these days
19:55:23 <tumbleweed> but older installs could have it
19:55:39 <tumbleweed> roehling: +1
19:55:42 <roehling> #topic Meeting schedule for 2026
19:56:43 <roehling> Currently, we are scheduling our meetings on a case-by-case basis. I'd like to solicit opinions on whether or not it would be easier to return to a fixed schedule
19:56:58 <roehling> Upside: it's easier to plan
19:57:08 <roehling> Downside: we seem to be very spread out over different timezones
19:57:09 <tumbleweed> I think we are currently too spread out over timezones to have one slot that fits everyone
19:57:15 <tumbleweed> but we could alternate between two slots
19:57:45 <helmut> I suspect it'll be european evenings in general, because european mornings are impossible for america.
19:57:45 <Emperor> When I was chair, I couldn't find a slot that suited everyone, hence the questionnaire every time (and trying to rotate who couldn't make a meeting)
19:58:24 <Emperor> At work, we have a lot of meetings in the 15:00-18:00 UTC window, as that overlaps for EU and Americas, but is not ideal for Australia
19:59:34 <mjg59> I'm good with early AM, but that works less well for Paul
19:59:57 <roehling> My idea is to collect suitable time ranges via email, and see if there is a "golden" timeslot.
20:00:08 <paultag> this is true, but I'm OK if we have an alternating schedule, and I can try to feed any burning thoughts I have beforehand
20:01:15 <roehling> or two workable slots for alternating schedules
20:02:08 <tumbleweed> roehling: sounds reasonable
20:02:15 <roehling> I'll see what I can do, and until then, we keep scheduling ad-hoc meetings using crab.fit, which seems to be working nicely
20:02:40 <roehling> #action roehling to determine potential timeslots for a fixed meeting schedule
20:02:47 <helmut> If the ics is maintained well, it's easier to not miss meetings for me ;)
20:03:16 <roehling> I think we can manage that :)
20:03:19 <roehling> #topic AOB
20:03:41 <roehling> We are a little bit over time, is there anything else anyone would like to bring up?
20:04:49 <helmut> How many of us show up in Hamburg?
20:05:37 * taffit should be there (hopefully)
20:05:41 * Emperor won't be, sorry
20:05:42 * roehling as well
20:05:53 <paultag> nack, will have fomo
20:06:12 <helmut> well, I wasn't expecting more than taffit and roehling really. that's three. cool
20:06:20 * tumbleweed will not
20:07:03 <roehling> I briefly considered submitting a "Meet the TC" talk for Hamburg, but I don't think that we should do this when the majority of TC members are unavailable
20:07:24 * tumbleweed doesn't have a problem with that
20:07:29 <paultag> ==
20:07:33 <tumbleweed> we've had meet the TC at DebConf with 1 TC member
20:07:46 <helmut> and with 7 :)
20:09:15 <roehling> You have a point, but our new format is very discussion focused. But we still have time to decide on that.
20:10:02 <roehling> Alright, if there's nothing else, I'd like to thank everyone for their time!
20:10:17 <roehling> #endmeeting