17:59:25 <marga> #startmeeting
17:59:25 <MeetBot> Meeting started Wed Jan 20 17:59:25 2021 UTC.  The chair is marga. Information about MeetBot at http://wiki.debian.org/MeetBot.
17:59:25 <MeetBot> Useful Commands: #action #agreed #help #info #idea #link #topic.
17:59:28 <marga> #topic Roll Call
17:59:29 <spwhitton> Sean Whitton
17:59:32 * gwolf is still Gunnar Wolf
17:59:36 <marga> Margarita Manterola
17:59:40 <bremner> David Bremner (for 30 mins)
17:59:42 <ntyni> Niko Tyni
18:00:00 <spwhitton> bremner: after which you will morph into Prof. Bremner presumably
18:00:06 <bremner> exactly
18:00:37 <smcv> Simon McVittie
18:00:37 <marga> We have a lot going on, so we might want to try to go as quickly as possible.
18:00:46 <marga> #topic Review of previous meetings AIs
18:00:46 <ehashman> oh hi
18:00:49 <ehashman> sorry I'm here
18:00:52 <ehashman> Elana Hashman
18:00:59 <gwolf> ehashman: I'm _glad_ you are here!
18:01:04 <ehashman> aww thank you gwolf
18:01:48 <spwhitton> I've drafted my statement.  People seem fine with it so I can go ahead and close the bug if no objections.
18:02:03 <marga> We thought we had dealt with the NM issue, those AIs got "done". Although we now have a different issue in our hands.
18:02:08 <spwhitton> And then we don't even need a new #topic for it :)
18:02:27 <spwhitton> I don't believe fil sent his e-mail?
18:02:41 <spwhitton> And I guess the lack of bug closure means ehashman's AI is invalid.
18:02:49 <ehashman> hehehe
18:02:51 <gwolf> No, because it was not needed in the end, having NM been fixed IIRC
18:02:55 <ehashman> we are indeed drowning
18:03:12 <spwhitton> gwolf: no, he has one about proposal #1.
18:03:16 <marga> fil did send some rough notes, if that's what you're referring to
18:03:21 <gwolf> oh, _that_ one
18:03:24 <spwhitton> oh, hrm, I missed somehow
18:03:32 <gwolf> (right, I'm only now opening our previous meeting log)
18:03:34 <smcv> the scope-creep from the NM issue to udisks2 has apparently also been fixed, in the same way (dropping it to Recommends)
18:03:54 <spwhitton> smcv: oh, great news!
18:03:57 <gwolf> oh, was it? Great! I didn't read the latest changes.
18:04:18 <spwhitton> marga: I am struggling to locate that mail somehow.  Can you give me a hint?
18:04:22 <spwhitton> fil's notes I Mean.
18:04:41 <marga> Uhm, not really, I just remember reading him here saying that he had sent it... Maybe he uploaded it to git?
18:04:46 <spwhitton> oh, right
18:05:17 <marga> https://salsa.debian.org/debian/tech-ctte/-/commit/096c18b0707a81530f56435a921139b7aab80d32
18:05:36 <spwhitton> It would be good to discuss that but perhaps not today.
18:05:42 <marga> Agreed :)
18:06:20 <marga> Alright, so on the topic of your AI, Sean, I think you can go ahead and close with that statement.
18:06:37 <marga> But I guess, that's actually the other topic, sorry, I'm a mess today.
18:06:48 <marga> #topic #971515 - kubernetes: excessive vendoring (private libraries)
18:07:05 <ehashman> marga: you are beautiful and great
18:07:11 <spwhitton> I'll go ahead and close.
18:07:12 <ehashman> and we are all probably messes
18:07:18 <marga> #action spwhitton to send the drafted reply declining to overrule
18:07:26 <ehashman> thanks spwhitton
18:07:32 <marga> Yes, many thanks.
18:07:53 <marga> I think then we can move ahead to the next one which seems to come with good news as well
18:08:01 <marga> #topic #975075 - Should NetworkManager support elogind?
18:08:34 <gwolf> So, smcv, you say the same kind of fix for NM was applied to udisks2?
18:08:35 <marga> https://tracker.debian.org/news/1221865/accepted-udisks2-291-3-source-into-unstable/
18:08:37 <smcv> as our (only?) utopia-team member I should probably jump in here
18:08:45 <smcv> yes, ^ that
18:09:21 <gwolf> So, this bug can also be closed with "no further action needed" from us?
18:09:29 <smcv> I find this a bit odd because there had been a suggestion on the -ctte bug that udisks2 (unlike NM) genuinely requires logind
18:09:44 <marga> Indeed.
18:09:46 <smcv> but if the maintainer says it doesn't, *shrug* maybe it doesn't
18:09:51 <ehashman> I think yes, but we should probably summarize our last meeting's discussion and timeline of events publicly on the bug for transparency?
18:10:07 <ehashman> I know we received an inquiring email on the private alias.
18:10:30 <marga> Exactly, I think we need to close it with some summary, because people are rightfully complaining that too much happened in private and now making assumptions about stuff
18:10:34 <spwhitton> Yes.
18:10:37 <smcv> I think we might want to say something a bit general about this issue
18:10:41 <gwolf> right
18:10:59 <smcv> on one hand, I am not a fan of people who happen to maintain high-profile packages getting to use them as a lever
18:11:00 <spwhitton> Could we say something about the procedural issues that led to so much consternation bout the upcoming freeze?
18:11:05 <marga> So, I think we need to say that after some private discussion with the maintainer the compromise of demoting the dependency to a Recommends, thus allowing other setups was achieved.
18:11:14 <ehashman> marga: ++
18:11:18 <spwhitton> At the least I hope we can say "people should engage with bug submitters earlier to avoid stuff reaching us"
18:11:34 <spwhitton> "where at all possible"
18:11:36 <smcv> and I don't think we want to incentivize maintainers just going silent and refusing to communicate
18:11:37 <marga> spwhitton, well, maintainers should indeed engage with bug submitters
18:11:48 <smcv> or give the impression that we are incentivizing that behaviour
18:11:50 <marga> spwhitton, and it is pretty disappointing when they don't.
18:11:53 <gwolf> Yes. I would _not_ like to have too much in the official statement about a maintainer not willing to communicate with others...
18:12:20 <spwhitton> gwolf: "Yes" but you disagree about putting it in there?
18:12:23 <gwolf> ...or at least, phrased in a way that makes minimum offense for all of the involved
18:12:37 <gwolf> I disagree with _too much_ of it ;-)
18:12:40 <smcv> on the other hand, I can understand people being entirely done with this whole argument
18:12:45 <bremner> I can understand maintainer exhaustion for sure
18:12:50 <smcv> yeah, that
18:12:55 <gwolf> I mean -- We can acknowledge "there were communication issues", also bremner's wording...
18:12:56 <spwhitton> Right.  I'm sure we can find something to say which takes account of all these concerns.
18:13:05 <smcv> and I don't know how much abuse the maintainer in question has been getting privately
18:13:06 <gwolf> but not "actively boycotting communication" or somesuch
18:13:07 <marga> It's a very fine line to walk. I think we want to highlight that we encourage people to talk and to find agreement before reaching the TC. But we need to explain what happened.
18:13:15 <spwhitton> gwolf: right.
18:13:20 <bremner> and also to point out that our domain is not really the communication problems?
18:13:43 <ehashman> my read of what happened is that there was definitely maintainer exhaustion and it took multiple attempts from the ctte to even get their side of the story
18:13:44 <spwhitton> bremner: I'm not sure you're right about that.  we're the only maintainer-overruling body.
18:13:46 <gwolf> bremner:Right, although were it not for the communication problems, the issue would not have been escalated to us
18:13:50 <marga> Well, but in practice it kinda is.
18:14:02 <bremner> I think we can consider working around communication problems as a successful outcome for the TC
18:14:24 <bremner> but *shrug*. not so important.
18:14:43 <ehashman> and I get it... it is really hard to keep up with and participate on these long, impassioned bugs. when honestly, a quarter of the message volume would probably suffice
18:15:09 <ehashman> so yay us for helping with the communication problems?
18:15:10 <smcv> the time-sensitive part, at least, is solved - people who want to use NM and udisks2, but not systemd, can do so in bullseye
18:15:19 <smcv> (assuming packages migrate, etc.)
18:15:31 <marga> I agree, but I think that was not the issue here, as we saw the maintainer refusing to communicate on their own bugs, on anything that was "non-systemd" related.
18:15:49 <marga> Anyway, I can take the action of closing the bug. I'll draft a statement and share it here before sending it.
18:15:49 <gwolf> We can probably assume the release team will accept migrations resulting from this...
18:15:52 <spwhitton> perahps someone should just try to write something and then we can consider whether it achives everything we want it to.
18:16:03 <ehashman> thanks marga !
18:16:09 <gwolf> thanks marga!
18:16:17 <marga> #action marga to draft a closing statement, explaining what happened and why we are declining to overrule, but encouraging people to talk to each other as much as possible.
18:16:22 <spwhitton> marga: okay, please do allow everyone to review, as I am quite keen to ensure it is strong enough to avoid something like this happennig again.
18:16:33 <spwhitton> as much as a statment can do taht.
18:16:39 <bremner> ah, optimism of youth
18:16:45 <ansgar> If you want to drive the systemd maintainer away...
18:16:46 <marga> heh :)
18:17:03 <marga> #topic #975381 - libinih: drop Debian's custom vendorisation
18:17:22 <gwolf> This is a very odd bug... And I'm in favor of closing it without further action
18:17:41 <smcv> perhaps confusingly, this bug is not about vendoring (see kubernetes), it's about downstream patching
18:17:49 <gwolf> It was dropped on us, by a non-Debian person (an Ubuntu maintainer, if I understood right), and does not really affect Debian
18:17:53 <spwhitton> It's been a month with no input from my requet for a better summary.
18:17:56 <gwolf> smcv: Right, that too
18:18:29 <gwolf> The submitter said "it irks me because a b c and nobody else will care", and two people in Debian answered, "well, actually I would care"
18:18:50 <gwolf> So.. probably the easiest way for this to be fixed is to... have it patched in Ubuntu..?
18:19:31 <smcv> I think one moral of this story is, downstream delta is technical debt, downstream delta that alters interfaces doubly so
18:20:51 <spwhitton> We could close saying "no response to request for a better summary and it seems to us that this might be better fixed in Ubuntu anyway".
18:21:03 <ehashman> spwhitton: that sgtm
18:21:48 <gwolf> yes. If you want, I can take that one action
18:21:57 <marga> SGTM too
18:22:00 <ehashman> go gwolf !
18:22:31 <smcv> it does seem kinda bad that we're shipping something in Debian that claims to be the upstream project, but has an interface that is not compatible with upstream's
18:22:50 <ehashman> smcv: I had that same thought when I read the initial bug report... but that's not super uncommon :/
18:22:50 <smcv> we've been here before (libcurl!) and it usually ends badly
18:22:56 <gwolf> #action gwolf will close the bug presenting the TC's answer
18:22:56 <bremner> yes. I'm not sure the submitter is technically wrong, if we were starting from scratch
18:23:26 <bremner> perhaps encourage them to resubmit if they can rephrase in the context of Debian and with a better summary?
18:23:31 <smcv> so if the submitter had a better summary of what is being patched and why it's undesirable, I might be inclined to vote to override
18:23:35 <spwhitton> bremner: sounds good.
18:23:37 <smcv> overrule
18:23:41 <smcv> whatever verb we use
18:23:44 <gwolf> Yes... Probably we could read this from a more formal stance... but I don't really know how to
18:23:59 <gwolf> So, I agree with bremner's wording
18:24:10 <smcv> yeah sgtm
18:24:15 <gwolf> and smcv, I also agree with you - the bug can be reopened and reevaluated with more complete information...
18:24:21 <marga> #action gwolf to encourage them to resubmit if they can rephrase in the context of Debian and with a better summary?
18:24:32 <marga> (shouldn't have copied the ?, sorry)
18:24:34 <gwolf> FWIW, I was a bit scared about lowering the soversion
18:25:05 <bremner> am now joining a second meeting. I hope my pay doubles.
18:25:05 <ehashman> gwolf: when they suggest something coherent and debian-specific we can debate the merits of the solution at that point :)
18:25:17 <marga> Alright, let's move on, we have 2 more.
18:25:31 <marga> #topic #976462 - Should dbgsym files be compressed via objcopy --compress-debug-section or not?
18:25:47 <spwhitton> This is another case where I requested some input but have not received any.
18:26:37 <spwhitton> Given the lack of urgency, we could ping doko and wait more.
18:27:07 <marga> Agreed, this is not urgent.
18:27:13 <ehashman> I haven't read through this one. the summary is not particularly compelling
18:27:22 <spwhitton> ehashman: what do you mean?
18:27:32 <gwolf> yes, I'm also going over it as I don't have it in the active part of my brain
18:27:35 <ehashman> perhaps if you are not emotionally invested and you lack spoons you should not simply dump the problem on someone else
18:27:55 <marga> ehashman, what should you do instead?
18:27:55 <ehashman> but that's just my 2c
18:28:04 <ehashman> marga: move on to greener pastures :D
18:28:14 <marga> Because, if you lack spoons you should definitely delegate
18:28:22 <spwhitton> ehashman: this is one of the things the TC is meant to help avoid getting stuck forever, I think.
18:28:30 <ehashman> fair
18:28:47 <marga> Yeah, I'm really not against dealing with this, just maybe not right now, while we still have a couple of other matters to deal with.
18:28:57 <spwhitton> marga: if you want to action me to ping doko I will do that and meeting can move on.
18:29:11 <marga> Sean, you said that your request for input didn't work, but I don't read your reply as a request for input...
18:29:12 <gwolf> yes. I think more context will be helpful
18:29:19 <ehashman> I think it would be reasonable to take an action to ping people for more input/context
18:29:27 <ehashman> it's sort of impossible to rule on this otherwise
18:29:27 <gwolf> I don't really get yet what do we gain by not compressing...
18:29:27 <spwhitton> marga: my mail to #922744
18:29:32 <marga> Ah, sorry.
18:29:46 <marga> #action spwhitton to ping doko for more input regarding this bug.
18:29:52 <ansgar> gwolf: Less problems with bugs in the toolchain?
18:30:10 <marga> gwolf, less things that need to support compressed symbols
18:30:24 <gwolf> right. Still going through the older mails
18:30:40 <gwolf> as I said - more information will be welcome
18:30:42 <smcv> ansgar: if you know concrete examples, perhaps you could send them to the bug?
18:30:51 <ehashman> I would appreciate some actual numbers if it's possible to dig that up - what sort of savings do we actually get from the compression
18:31:09 <ehashman> ah smcv read my mind
18:31:10 <spwhitton> ehashman: there is a good example in #631985
18:31:20 <ansgar> smcv: I'm not sure if that is the problem, but I sometimes saw bug reports about `dwz` which says "DWARF decompression tool"
18:31:23 <spwhitton> someone wanting to debug KDE
18:31:29 <ehashman> spwhitton: that bug is from the stone age, is it still relevant?
18:31:54 <ehashman> lots of things can change in a decade :)
18:31:59 <spwhitton> ehashman: good point, it would be good to see if still true.
18:32:00 <smcv> I think dwz is a different thing
18:32:01 <gwolf> it seems Niels is amenable to removing the compression... but wants to rely on our opinion before doing so
18:32:02 <doko> well, anyway too late for bullseye. yes, "Less problems with bugs in the toolchain"
18:32:10 <spwhitton> oh, hello doko
18:32:11 <doko> dwz is different
18:32:36 <marga> Hi! You can save Sean an action by giving us input here directly :)
18:32:45 <gwolf> ehashman: Well, huge packages might have got Huge by now... and some might be even Hugher.
18:32:59 <ehashman> gwolf: but disks have also gotten huger and faster
18:33:02 <smcv> if I understand correctly, #922744 and friends are about (something similar to) transparently gzip'ing the section that contains the debugging info?
18:33:11 <doko> my argument was that compressed symbols don't make a difference for the size of a deb
18:33:28 <smcv> whereas dwz is about optimizing and deduplicating the debugging info itself? which might then be stored gzip'd
18:33:29 <ehashman> oh, because of the double-compression?
18:33:29 <spwhitton> right, it's about installed size
18:33:34 <gwolf> yes... but some things don't go linearly. Again, I'd prefer having a bit more explanation on this. But I think we will end up removing said compression
18:33:54 <doko> yes, but why would you care about the installed size for debug packages?
18:34:06 <spwhitton> doko: well if you have to install a lot of the, to debug something like like gnome.
18:34:10 <bremner> what about download size?
18:34:13 <ehashman> I would prefer emails on the bug for this one rather than needing to summarize the IRC discussion here
18:34:18 <doko> ok
18:34:23 <ansgar> bremner: Download size == deb size?
18:34:35 <smcv> download size is .deb size, which is compressed in the data.tar.?z anyway
18:35:23 <spwhitton> we should probably give the people on the old bug a chance to say "this is still helpful" or "that use case doesn't exist anymore as my didsks are bigger"
18:35:43 <smcv> I suppose "put /usr/lib/debug on btrfs, then you can compress the uncompressed debug symbols at the filesystem level" would be considered unconstructive? :-)
18:35:54 <ehashman> lol omg
18:35:56 <ehashman> next topic
18:36:10 <smcv> or the semi-hypothetical fuse filesystem that magics debug symbols out of the archive and onto your disk
18:36:39 <ansgar> smcv: :D  It does solve the compression...
18:36:54 <marga> spwhitton, were you volunteering for doing the pinging in the old bug? Or do we need a different volunteer?
18:37:00 <smcv> but yes I agree, I should stop trolling and move to the next topic
18:37:02 <spwhitton> marga: heh.  I can do so.
18:37:14 <spwhitton> seems I am the hermes of the committee
18:37:18 <marga> #action spwhitton to ping the old bug asking whether it's still relevant.
18:37:20 <marga> :)
18:37:27 <marga> Alright, next bug
18:37:34 <spwhitton> doko: thanks for chiming in.
18:37:43 <marga> #topic #978636 - move to merged-usr-only?
18:37:46 <ansgar> smcv: Maybe if ext4 gains support as well.
18:38:11 <spwhitton> There was some question over whether this bug makes sense given the previous ruling the TC made.
18:38:34 <spwhitton> i.e. wasn't it already the case that we are dropping post-bullseye
18:39:01 <marga> Right, the ruling we made was in regards to bullseye, not after bullseye
18:39:18 <marga> I think we assumed that after bullseye this would be a non-issue and we were just ruling for a transition period
18:39:21 <smcv> well, it was about buster, and secondarily bullseye
18:39:41 <gwolf> Well, OdyX's mail when closing the previous bug mentioned he used his casting vote (...) "consider that the desirable situation at the time of bullseye is that both directory schemes are allowed"
18:40:00 <marga> Gunnar you're gaslighting me?
18:40:07 <gwolf> marga: ??
18:40:35 <marga> I was the one with the casting vote. I'm now doubting my own reality
18:40:51 <smcv> the original request on #914897 was about buster
18:41:01 <gwolf> Sorry, I took some notes pre-meeting, but I might be mistaken somehow
18:41:18 <ehashman> all of this predates me
18:41:29 <gwolf> Oh, sorry!
18:41:39 <marga> "Furthermore, using its §6.1.5 "Offering advice" power, the Technical Committee considers that the desirable solution at the time of `bullseye` is `middle`: both directory schemes are allowed, and packages (including official packages) can be built on hosts with either classical or "merged `/usr`" directory schemes."
18:41:43 <gwolf> marga: you are completely right -- I took this from a mail _quoted by_ odyx
18:41:43 <smcv> the "... and for bullseye, ..." part is something the TC added during discussion
18:41:57 <gwolf> and you were the real author
18:42:44 <spwhitton> so, indeed, the bug is valid, my apologies.
18:42:57 <smcv> with the casting vote used to tiebreak between "middle" (status quo) and "hard" (building packages on merged /usr is mandatory)
18:42:58 <marga> #link https://lists.debian.org/debian-devel-announce/2019/03/msg00001.html
18:43:04 <marga> That's the ruling from 2019
18:44:14 <smcv> that does seem entirely consistent with wanting to move in the direction of mandatory merged /usr for Debian 12
18:44:41 <smcv> also consistent with retaining the status quo in Debian 12
18:45:08 <spwhitton> I agree, but it would be good to know a bit more about the costs of supporting both.
18:45:30 <smcv> the main cost of supporting both is that ... we're supporting both
18:45:38 <smcv> refusing to make a decision is, itself, a decision
18:45:55 <spwhitton> smcv: right.  I mean specifically what extra work people are having to do to keep both supported.
18:46:25 <smcv> it's pretty easy to accidentally build packages that work fine on merged-/usr but fail on split-/usr
18:46:28 <marga> Is there significant disagreement on the -devel thread?
18:46:41 <spwhitton> Or also, what cool new things are impossible until we support only one.
18:46:48 <spwhitton> smcv: ah, yes.
18:47:17 <gwolf> I haven't been following -devel lately - This bug has few interactions (three people saying, "yes we should do this" only)
18:47:20 <smcv> the other big cost is that as long as merged /usr is supported but not mandatory, things like dpkg have to be able to deal with aliased trees
18:47:40 <ansgar> spwhitton: You get to enjoy looking at every upstream place that uses /usr/bin/{X} where it is /bin/{X} in Debian, like udev rules, ...
18:48:03 <spwhitton> ansgar: good example.
18:48:28 <spwhitton> it's been almost a month since the TC bug was filed and the -devel thread and no dissenting voices.  so maybe we can just rule.
18:48:54 <ansgar> spwhitton: (There is a bug for at least one such rule, but I would need to search.)
18:49:04 <gwolf> if there is no disagreement, I don't see why not -- I don't even see why this needed to become a TC bug in the first place!
18:49:23 <gwolf> Now... is this the right moment of Bullseye's life to push for this change?
18:49:33 <ansgar> gwolf: Last time wasn't a ctte bug; people complained 1/2 year later.
18:49:38 <ehashman> I am fine with affirming merged-usr only for bookworm
18:49:39 <ansgar> gwolf: It is not for Bullseye at all.
18:49:42 <ehashman> which is what the bug says
18:49:43 <marga> Right, I'm a bit confused about this being a TC bug. If there's no disagreement, why are we even involved?
18:49:51 <ehashman> marga: our blessing?
18:49:53 <ansgar> gwolf: Only for bookworm/trixie.
18:49:55 <gwolf> I was aiming at letting this cool off until after release, for bookworm
18:50:06 <gwolf> ansgar / ehashman: OK, so I completely agree there
18:50:24 <marga> Alright, then we should just vote that we agree that this should be done for bookworm?
18:50:26 <smcv> the disagreement is likely to come from people who have not noticed this bug (yet?) and feel strongly that the migration path via symlink-based aliasing is Bad And Wrong
18:50:46 <marga> We won't rule a technical solution, though, as this is not what's being asked of us.
18:50:49 <smcv> and that instead, we should get to merged /usr via changing every package that ships files outside /usr, individually
18:50:51 <ntyni> yes there's certainly disagreement about the symlink-based aliasing
18:51:16 <spwhitton> that would be a different TC bug, however, which may yet get filed
18:51:29 <smcv> it is not clear to me that that approach is even feasible, because of hard-coded paths that are part of the ABI, like /lib64/ld-linux-x86-64.so.2
18:51:46 <smcv> if it is feasible, then it's a monumental amount of work
18:52:04 <ansgar> SuSE had /bin/{X} -> /usr/bin/{X} symlinks.
18:52:16 <smcv> involving maintscripts in multiple packages that have to be carefully correct to avoid data loss
18:52:36 <ansgar> But that is (a) half of usrmerge (would need /usr/bin/{Y} -> /bin/{Y} symlinks too) and (b) they got stuck and never completed the transition AFAIK.
18:53:13 <smcv> right, that's something I'm scared of
18:53:17 <ehashman> to avoid getting too far into the weeds on this one: the bug is asking us to rule whether we move to merged-usr-only in bookworm+, without any particular implementation
18:53:28 <smcv> attempting a transition and getting stuck halfway is worse than either a transition, or no transition
18:53:28 <ehashman> is that something we can close out today?
18:54:00 <ansgar> smcv: I agree.  That's why I don't want to follow SuSE's approach :)
18:54:22 <marga> ehashman, well, not today as a proper ruling requires a vote
18:54:23 <gwolf> FWIW when we debated in 2019 SuSE was brought up as a (non-)example
18:54:24 <ansgar> (Also that was discussed at buster time.)
18:54:28 <marga> But we could start the vote today.
18:54:39 <ehashman> marga: okay, should we have an action for that?
18:54:50 <marga> Yes, who wants to start the vote on this?
18:54:54 <ehashman> not it
18:55:06 <spwhitton> I can do it.
18:55:11 <ehashman> :tada:
18:55:39 <marga> spwhitton, thanks, although you already have a bunch... Nobody else?
18:56:06 <smcv> is there anyone other than gwolf who would prefer to put this decision off until the bookworm cycle has started?
18:56:06 <ehashman> I am up to my ears in this python thing (which I will discuss when we get to AOB)
18:56:18 <ntyni> fwiw I'm concerned that the only feasible usrmerge implementation available aiui is explicitly declared as broken by the dpkg maintainer
18:56:19 <smcv> (gwolf I hope I'm not misrepresenting your suggestion?)
18:56:22 <gwolf> smcv: I am fine with deciding now
18:56:39 <gwolf> smcv: I only want this not to bring unstability to bullseye
18:57:31 <ansgar> ntyni: As far as I understand the dpkg maintaienr doesn't like /bin/bash (as known to dpkg) being installed to /usr/bin/bash (as /bin is a symlink)
18:57:37 <spwhitton> marga: haven't started a vote before so wanted to familiarise myself with how it's done :)
18:57:51 <marga> Alright, then.
18:57:52 <ansgar> ntyni: When usrmerge is mandatory (trixie+), bash can just ship /usr/bin/bash.
18:58:16 <ansgar> And path in the *.deb and pyhsical installation path match again.
18:58:30 <ehashman> sounds like we have a path forward?
18:58:32 <smcv> sounds like we want a TC resolution that says any action/implementations on this should happen in experimental/otherwise outside the critical path for bullseye
18:58:48 <spwhitton> smcv: yes, that can be explicitly mentioned.
18:58:52 <gwolf> smcv++
18:58:58 <spwhitton> ntyni: do you think that should block us resolving the bug?
18:59:14 <smcv> so options like (1) yes, but not until bullseye has been released; (2) no; (3) FD
18:59:21 <marga> #action spwhitton to start a vote on us agreeing to usrmerge being mandatory for bookworm+, without ruling on the technical details, assuming a technical migration can be agreed on. any action/implementations on this should happen in experimental/otherwise outside the critical path for bullseye
18:59:36 <smcv> (or we can skip the "no" option if nobody would seriously vote for it)
19:00:19 <ntyni> spwhitton: no
19:00:35 <ntyni> as in should not block
19:00:39 <marga> If you want more than 1 option, it should be "usrmerge mandatory for bookworm+", "maintain status-quo of supporting both", "FD". But I think we don't really need the second one.
19:00:48 <gwolf> smcv: It won't hurt having it there, just to be able to show to any oponents that it was considered fairly
19:00:50 <ehashman> smcv: what is FD? oh, wait, further discussion, derp
19:01:07 <ehashman> I'm like... fire department..?
19:01:08 <spwhitton> ntyni: okay then, still useful to have that point of contention mentioned.
19:01:12 <smcv> sorry yeah not a file descriptor or the front-desk either
19:01:14 <spwhitton> I think we can move on.
19:01:24 <marga> #topic Possible future Python issue
19:01:27 <marga> ehashman, you have the floor
19:01:29 <ehashman> thanks marga !
19:01:43 <gwolf> heh
19:01:52 <ehashman> summary: a couple of core python devs, acting independently, have raised some concerns with how Debian in Python is being maintained
19:02:20 <ehashman> they approached me for advice (per my role on TC) and I have engaged doko (Python maintainer) and tumbleweed (Python team)
19:02:22 <gwolf> Well, we should just kick Python out of the distribution. </troll>
19:02:37 <marga> What is the issue, actually?
19:02:43 <ehashman> one sec, let me link
19:03:20 <ehashman> https://archive.is/eqtdf here is an archive of the discussion on GitHub (which is not an official forum)
19:03:21 <spwhitton> ln -s /usr/bin/perl /usr/bin/python
19:03:58 <ehashman> I (and also Stefano) emphasized that we should be working towards designing a feasible technical solution for the problems and not simply escalate to TC because TC in Debian is a last resort.
19:04:02 <spwhitton> (sorry, probably shouldn't have said that in this meeting)
19:04:39 <ehashman> I've also spoken with highvoltage as there were tempers running high. hoping to cool things off and work through it!
19:04:56 <ehashman> that is all, just wanted to make sure it went into the public record and offer to answer any questions you might have
19:05:24 <marga> ehashman, my question is: does it look like it might get resolved by people tending to the concerns raised?
19:05:35 <ehashman> marga: I sure hope so
19:06:06 <smcv> this looks to me like the classic anti-pattern: I want a minimal system where everything (that I care about) works as expected, and nothing unimportant (that I don't care about) is installed
19:06:09 <spwhitton> it looks like there are some constructive suggestions in that bug
19:06:36 <spwhitton> ehashman: have they written to d-python@?
19:06:40 <ehashman> spwhitton: no
19:07:04 <smcv> I wonder how much of this would be solved by a bunch more Recommends
19:07:19 <ehashman> smcv: I suggested a Python metapackage ala python3-full
19:07:31 <smcv> possibly none, because they're talking about the UX of installing python3 into a minimal Debian or Ubuntu Docker image, and I think those turn off Recommends?
19:07:37 <spwhitton> ehashman: do you think it would work to suggest that to them as a sensible next step?
19:07:39 <ehashman> doko prefers python3-batteries-included :)
19:07:46 <ntyni> yes part of it is docker images that aim to be minimal
19:07:48 <ehashman> spwhitton: I suggested it on that long gist thread
19:07:56 <spwhitton> cool.
19:08:31 <ntyni> and they want python3 to be full and anything less full not to be called python3
19:08:36 <ehashman> re: "have they written to X mailing list" -- the Python community doesn't use a ton of email for things. there has been reluctance both to use the BTS (which lacks a non-email UI) and mailing lists
19:08:40 <gwolf> yes, their requirements as Python devs are different from the requirements for many distribution users (who don't care much even that a program is written in Python or whatever)
19:09:06 <smcv> it's slightly confusing that we also have python3-minimal, which is python with not only no batteries included, but (continuing the analogy) half the circuit board also missing
19:09:08 <gwolf> so there's a difference in what we call "users of our thingy..."
19:09:18 <spwhitton> smcv: huh.  that is confusing.
19:09:22 <spwhitton> perl has just perl-base and perl right?
19:09:34 <ehashman> spwhitton: I believe this is because python3-minimal is the bits of Python required just for bootstrapping Debian
19:09:38 <smcv> python3-minimal is to perl-base as python3 is to perl
19:09:40 <ansgar> spwhitton: python-minimal == perl-base, python == perl
19:09:52 <spwhitton> oh really?
19:10:06 <ntyni> yes; perl has had the same issues and upstream greatly prefers 'perl' to pull in the full package
19:10:11 <smcv> I think (and conveniently doko is here so can probably correct me) that the idea was that python(3?)-minimal could eventually become Essential, possibly replacing perl-base
19:10:20 <smcv> either in Ubuntu, or in Debian as well
19:10:31 <spwhitton> it sounds like perl has a lot more in it than python3 however.
19:10:51 <ehashman> generally I would characterize this issue as "there has been a lot of friction between upstream CPython devs and Debian maintainers for many years. Python doesn't really know how to engage with Debian, and there is lots of frustration all around"
19:11:10 <smcv> but I don't think that ever happened, and there tends to be a movement away from adding things to Essential and towards kicking them out
19:11:47 <ehashman> I think there is also a separate issue here, which is that the official Debian/Ubuntu docker images, which are not actually maintained by us, are buggy and I have no idea where to even report a bug
19:11:51 <smcv> ISTM that one obvious possible route would be: python3-minimal < python3 < a new python3-batteries-included (or -full or whatever)
19:12:01 <spwhitton> smcv: indeed.
19:12:12 <ehashman> smcv: yup, that's my suggestion
19:12:16 <spwhitton> Hard to see Debian people objecting to adding that additional package.
19:12:32 <ehashman> and that could be accomplished before bullseye freeze
19:12:50 <smcv> and another possible route would be python3-minimal < python3-interpreter < python3, and random packages that happen to be written in Python moving to Depends: python3-interpreter
19:13:17 <smcv> which would be a huge amount of churn, so much that I hesitate to even suggest it, but is probably what Python upstream would prefer to see
19:13:19 <gwolf> right, although Python people could still complain that python3 does not mean python3-batteries-included
19:13:29 <smcv> sorry if I was unclear
19:13:42 <smcv> I meant: transitioning towards python3-interpreter meaning what python3 means today
19:13:42 <ansgar> I like python3-interpreter more than python3-batteries-included (also because batteries-included is an uncommon suffix and too long)
19:13:46 <ehashman> gwolf: I think that's an issue of documentation/education which can be addressed
19:13:48 <gwolf> (my "right" was before smcv's second set of package naming)
19:13:59 <smcv> and python3 eventually meaning what python3-batteries-included means today
19:14:26 <marga> yeah, that would be a tough call. Without thinking about the churn, having python3 be the full package sounds nicer. But the churn would be big.
19:14:35 <smcv> (well I know python3-batteries-included doesn't exist today but you know what I mean)
19:14:48 <smcv> that would be a 1+ release cycle process, IMO
19:14:51 <ehashman> yeah.
19:14:54 <gwolf> I think making python3 be "the full thing" would better match the Python devs expectations. And most Debian users should be happy with python-interpreter
19:15:05 <gwolf> ...but we have a _lot_ of python3-* dependencies to fix
19:15:13 <ehashman> it is a very large undertaking
19:15:15 * smcv looks sadly at the libgdk-pixbuf(-)2.0-0 transition
19:15:17 <gwolf> yes, for a full release cycle
19:15:27 <ehashman> but now is always a good time to brainstorm, going into the next release
19:15:38 <ehashman> and I think python3-full now, full fix later is a good transitional solution
19:15:50 <smcv> that
19:15:57 <gwolf> ehashman: Yes.
19:16:04 <ehashman> good to hear we're on board :)
19:16:12 <marga> Alright, I think there's no further action needed for us now. If people are currently talking to each other, let's let them talk to each other. Hopefully we don't need to intervene.
19:16:12 <gwolf> Now, it's a weird setting -- we have a good solution to a bug that has not yet been presented to us :-)
19:16:17 <smcv> even if we would eventually prefer 2023 python3 to mean what 2021 python3-full meant
19:16:26 <smcv> I think we would want to get there via python3-full
19:16:40 <gwolf> Can we offer our official insight to the Python people and see if they agree?
19:16:52 <ehashman> #info ehashman to continue working with doko and tumbleweed to address upstream concerns about Python packaging in Debian for bullseye and bookworm+ cycles
19:17:12 <marga> Thanks!
19:17:31 <ehashman> gwolf: would you like that to be formal as TC or are you comfortable with me continuing to work on this as an individual and reporting back?
19:17:51 <gwolf> FWIW tumbleweed suggested on the thread a "python3-system" package (this is, he suggested this same solution we are aiming at)
19:18:04 <ehashman> *nod*
19:18:07 <gwolf> ehashman: Well... It could be an excercise of "early involvement" of the TC before we are summoned
19:18:24 <gwolf> ...maybe we need to vote on it, to make it an official statement?
19:18:36 <ehashman> when we actually have something concrete to be blessed, you'll be be the first to know :)
19:18:46 <smcv> procedurally, if we do want it to be an official statement, yes we need to vote on it
19:18:46 <ehashman> we have run way over today, oops
19:18:49 <smcv> I think
19:19:02 <smcv> but I'd be inclined to say that's premature at this stage
19:19:09 <gwolf> ehashman: Well, five bugs plus an extra...
19:19:30 <spwhitton> It would be good to dsicuss recruitment.
19:19:33 <marga> Yes, I'm sorry about the run over
19:19:39 <marga> #topic Recruitment efforts
19:19:45 <marga> We are lacking a team member
19:19:56 <spwhitton> We do have a nominee.
19:20:13 <marga> But did we ever reach out to ask them if they actually wanted to join?
19:20:20 <spwhitton> No, shall we?
19:20:26 <marga> Yeah, we should do that.
19:20:31 <ehashman> it would be good to have multiple nominees if possible
19:20:47 <ehashman> should we send a reminder email to nominate people? have we sent one?
19:20:58 <marga> I think Sean sent one
19:21:02 <ehashman> maybe people will be more (or less..) motivated now seeing all our bugs
19:21:03 <spwhitton> ehashman: I think we've sent two or maybe even three in the time that we've had that single nominee.
19:21:09 <spwhitton> I think it would be good to get the seat filled tbh.
19:21:28 <ntyni> yes
19:21:50 <gwolf> FWIW the TC has usually kept its eight seats in use - but we are not _urged_ to do this (TC can shrink as much as to four people)
19:22:00 <gwolf> so, yes, we have to reach out and get candidates...
19:22:16 <spwhitton> gwolf: two thirds majorities are weird with too few people.
19:22:21 <gwolf> ...but it's not like we are acting against the constitution
19:22:24 <ntyni> btw I think our procedures say we need to have a chair election now that fil has left
19:22:33 <marga> I can try to use fil's script to send more emails
19:22:36 <gwolf> spwhitton: wouldn't it be ⅔ of the current membership?
19:22:37 <ehashman> I vote: marga
19:22:44 <spwhitton> shall we action someone to write to the nominee?
19:22:54 <marga> Yes, I wanted to ask that, should we do the chair election now? Or wait until we have the 8th member?
19:23:01 <gwolf> ehashman: votes are cast by publicly archived mail, gpg-signed...
19:23:18 <ehashman> gwolf: are you saying my vote doesn't count?! :P
19:23:23 <spwhitton> marga: also, do you want to continue?
19:23:38 <spwhitton> and, are you willing? :)
19:23:45 <gwolf> ehashman: Well, you are a USA-ian, aren't you? You should be used to it by now ;-)    (BTW, congrats on the change!)
19:24:01 <ehashman> gwolf: I am 100% Canadian who just happens to reside in this place
19:24:13 <marga> I would be ok to continue until we have the 8th person, to avoid wasted time on two rounds of voting... After that, maybe other people would like to volunteer? :)
19:24:14 <gwolf> ah, right, forgot it! Sorry for mischaracterizing you
19:24:17 <ehashman> hehe
19:24:20 <spwhitton> marga: SGTM.
19:24:36 <ntyni> I can write to the nominee
19:25:01 <ntyni> (unless marga wants to as chair of course)
19:25:04 <marga> Awesome, thanks ntyni !
19:25:18 <marga> #action ntyni to write to the nominee asking if they are willing to join
19:25:28 <marga> #action marga to have a go at fil's script to ask for more nominees.
19:25:51 <marga> And let's close now, we are almost half an hour overtime
19:25:55 <marga> #endmeeting