17:59:25 #startmeeting 17:59:25 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 Useful Commands: #action #agreed #help #info #idea #link #topic. 17:59:28 #topic Roll Call 17:59:29 Sean Whitton 17:59:32 * gwolf is still Gunnar Wolf 17:59:36 Margarita Manterola 17:59:40 David Bremner (for 30 mins) 17:59:42 Niko Tyni 18:00:00 bremner: after which you will morph into Prof. Bremner presumably 18:00:06 exactly 18:00:37 Simon McVittie 18:00:37 We have a lot going on, so we might want to try to go as quickly as possible. 18:00:46 #topic Review of previous meetings AIs 18:00:46 oh hi 18:00:49 sorry I'm here 18:00:52 Elana Hashman 18:00:59 ehashman: I'm _glad_ you are here! 18:01:04 aww thank you gwolf 18:01:48 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 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 And then we don't even need a new #topic for it :) 18:02:27 I don't believe fil sent his e-mail? 18:02:41 And I guess the lack of bug closure means ehashman's AI is invalid. 18:02:49 hehehe 18:02:51 No, because it was not needed in the end, having NM been fixed IIRC 18:02:55 we are indeed drowning 18:03:12 gwolf: no, he has one about proposal #1. 18:03:16 fil did send some rough notes, if that's what you're referring to 18:03:21 oh, _that_ one 18:03:24 oh, hrm, I missed somehow 18:03:32 (right, I'm only now opening our previous meeting log) 18:03:34 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 smcv: oh, great news! 18:03:57 oh, was it? Great! I didn't read the latest changes. 18:04:18 marga: I am struggling to locate that mail somehow. Can you give me a hint? 18:04:22 fil's notes I Mean. 18:04:41 Uhm, not really, I just remember reading him here saying that he had sent it... Maybe he uploaded it to git? 18:04:46 oh, right 18:05:17 https://salsa.debian.org/debian/tech-ctte/-/commit/096c18b0707a81530f56435a921139b7aab80d32 18:05:36 It would be good to discuss that but perhaps not today. 18:05:42 Agreed :) 18:06:20 Alright, so on the topic of your AI, Sean, I think you can go ahead and close with that statement. 18:06:37 But I guess, that's actually the other topic, sorry, I'm a mess today. 18:06:48 #topic #971515 - kubernetes: excessive vendoring (private libraries) 18:07:05 marga: you are beautiful and great 18:07:11 I'll go ahead and close. 18:07:12 and we are all probably messes 18:07:18 #action spwhitton to send the drafted reply declining to overrule 18:07:26 thanks spwhitton 18:07:32 Yes, many thanks. 18:07:53 I think then we can move ahead to the next one which seems to come with good news as well 18:08:01 #topic #975075 - Should NetworkManager support elogind? 18:08:34 So, smcv, you say the same kind of fix for NM was applied to udisks2? 18:08:35 https://tracker.debian.org/news/1221865/accepted-udisks2-291-3-source-into-unstable/ 18:08:37 as our (only?) utopia-team member I should probably jump in here 18:08:45 yes, ^ that 18:09:21 So, this bug can also be closed with "no further action needed" from us? 18:09:29 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 Indeed. 18:09:46 but if the maintainer says it doesn't, *shrug* maybe it doesn't 18:09:51 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 I know we received an inquiring email on the private alias. 18:10:30 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 Yes. 18:10:37 I think we might want to say something a bit general about this issue 18:10:41 right 18:10:59 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 Could we say something about the procedural issues that led to so much consternation bout the upcoming freeze? 18:11:05 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 marga: ++ 18:11:18 At the least I hope we can say "people should engage with bug submitters earlier to avoid stuff reaching us" 18:11:34 "where at all possible" 18:11:36 and I don't think we want to incentivize maintainers just going silent and refusing to communicate 18:11:37 spwhitton, well, maintainers should indeed engage with bug submitters 18:11:48 or give the impression that we are incentivizing that behaviour 18:11:50 spwhitton, and it is pretty disappointing when they don't. 18:11:53 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 gwolf: "Yes" but you disagree about putting it in there? 18:12:23 ...or at least, phrased in a way that makes minimum offense for all of the involved 18:12:37 I disagree with _too much_ of it ;-) 18:12:40 on the other hand, I can understand people being entirely done with this whole argument 18:12:45 I can understand maintainer exhaustion for sure 18:12:50 yeah, that 18:12:55 I mean -- We can acknowledge "there were communication issues", also bremner's wording... 18:12:56 Right. I'm sure we can find something to say which takes account of all these concerns. 18:13:05 and I don't know how much abuse the maintainer in question has been getting privately 18:13:06 but not "actively boycotting communication" or somesuch 18:13:07 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 gwolf: right. 18:13:20 and also to point out that our domain is not really the communication problems? 18:13:43 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 bremner: I'm not sure you're right about that. we're the only maintainer-overruling body. 18:13:46 bremner:Right, although were it not for the communication problems, the issue would not have been escalated to us 18:13:50 Well, but in practice it kinda is. 18:14:02 I think we can consider working around communication problems as a successful outcome for the TC 18:14:24 but *shrug*. not so important. 18:14:43 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 so yay us for helping with the communication problems? 18:15:10 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 (assuming packages migrate, etc.) 18:15:31 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 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 We can probably assume the release team will accept migrations resulting from this... 18:15:52 perahps someone should just try to write something and then we can consider whether it achives everything we want it to. 18:16:03 thanks marga ! 18:16:09 thanks marga! 18:16:17 #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 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 as much as a statment can do taht. 18:16:39 ah, optimism of youth 18:16:45 If you want to drive the systemd maintainer away... 18:16:46 heh :) 18:17:03 #topic #975381 - libinih: drop Debian's custom vendorisation 18:17:22 This is a very odd bug... And I'm in favor of closing it without further action 18:17:41 perhaps confusingly, this bug is not about vendoring (see kubernetes), it's about downstream patching 18:17:49 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 It's been a month with no input from my requet for a better summary. 18:17:56 smcv: Right, that too 18:18:29 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 So.. probably the easiest way for this to be fixed is to... have it patched in Ubuntu..? 18:19:31 I think one moral of this story is, downstream delta is technical debt, downstream delta that alters interfaces doubly so 18:20:51 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 spwhitton: that sgtm 18:21:48 yes. If you want, I can take that one action 18:21:57 SGTM too 18:22:00 go gwolf ! 18:22:31 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 smcv: I had that same thought when I read the initial bug report... but that's not super uncommon :/ 18:22:50 we've been here before (libcurl!) and it usually ends badly 18:22:56 #action gwolf will close the bug presenting the TC's answer 18:22:56 yes. I'm not sure the submitter is technically wrong, if we were starting from scratch 18:23:26 perhaps encourage them to resubmit if they can rephrase in the context of Debian and with a better summary? 18:23:31 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 bremner: sounds good. 18:23:37 overrule 18:23:41 whatever verb we use 18:23:44 Yes... Probably we could read this from a more formal stance... but I don't really know how to 18:23:59 So, I agree with bremner's wording 18:24:10 yeah sgtm 18:24:15 and smcv, I also agree with you - the bug can be reopened and reevaluated with more complete information... 18:24:21 #action gwolf to encourage them to resubmit if they can rephrase in the context of Debian and with a better summary? 18:24:32 (shouldn't have copied the ?, sorry) 18:24:34 FWIW, I was a bit scared about lowering the soversion 18:25:05 am now joining a second meeting. I hope my pay doubles. 18:25:05 gwolf: when they suggest something coherent and debian-specific we can debate the merits of the solution at that point :) 18:25:17 Alright, let's move on, we have 2 more. 18:25:31 #topic #976462 - Should dbgsym files be compressed via objcopy --compress-debug-section or not? 18:25:47 This is another case where I requested some input but have not received any. 18:26:37 Given the lack of urgency, we could ping doko and wait more. 18:27:07 Agreed, this is not urgent. 18:27:13 I haven't read through this one. the summary is not particularly compelling 18:27:22 ehashman: what do you mean? 18:27:32 yes, I'm also going over it as I don't have it in the active part of my brain 18:27:35 perhaps if you are not emotionally invested and you lack spoons you should not simply dump the problem on someone else 18:27:55 ehashman, what should you do instead? 18:27:55 but that's just my 2c 18:28:04 marga: move on to greener pastures :D 18:28:14 Because, if you lack spoons you should definitely delegate 18:28:22 ehashman: this is one of the things the TC is meant to help avoid getting stuck forever, I think. 18:28:30 fair 18:28:47 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 marga: if you want to action me to ping doko I will do that and meeting can move on. 18:29:11 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 yes. I think more context will be helpful 18:29:19 I think it would be reasonable to take an action to ping people for more input/context 18:29:27 it's sort of impossible to rule on this otherwise 18:29:27 I don't really get yet what do we gain by not compressing... 18:29:27 marga: my mail to #922744 18:29:32 Ah, sorry. 18:29:46 #action spwhitton to ping doko for more input regarding this bug. 18:29:52 gwolf: Less problems with bugs in the toolchain? 18:30:10 gwolf, less things that need to support compressed symbols 18:30:24 right. Still going through the older mails 18:30:40 as I said - more information will be welcome 18:30:42 ansgar: if you know concrete examples, perhaps you could send them to the bug? 18:30:51 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 ah smcv read my mind 18:31:10 ehashman: there is a good example in #631985 18:31:20 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 someone wanting to debug KDE 18:31:29 spwhitton: that bug is from the stone age, is it still relevant? 18:31:54 lots of things can change in a decade :) 18:31:59 ehashman: good point, it would be good to see if still true. 18:32:00 I think dwz is a different thing 18:32:01 it seems Niels is amenable to removing the compression... but wants to rely on our opinion before doing so 18:32:02 well, anyway too late for bullseye. yes, "Less problems with bugs in the toolchain" 18:32:10 oh, hello doko 18:32:11 dwz is different 18:32:36 Hi! You can save Sean an action by giving us input here directly :) 18:32:45 ehashman: Well, huge packages might have got Huge by now... and some might be even Hugher. 18:32:59 gwolf: but disks have also gotten huger and faster 18:33:02 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 my argument was that compressed symbols don't make a difference for the size of a deb 18:33:28 whereas dwz is about optimizing and deduplicating the debugging info itself? which might then be stored gzip'd 18:33:29 oh, because of the double-compression? 18:33:29 right, it's about installed size 18:33:34 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 yes, but why would you care about the installed size for debug packages? 18:34:06 doko: well if you have to install a lot of the, to debug something like like gnome. 18:34:10 what about download size? 18:34:13 I would prefer emails on the bug for this one rather than needing to summarize the IRC discussion here 18:34:18 ok 18:34:23 bremner: Download size == deb size? 18:34:35 download size is .deb size, which is compressed in the data.tar.?z anyway 18:35:23 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 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 lol omg 18:35:56 next topic 18:36:10 or the semi-hypothetical fuse filesystem that magics debug symbols out of the archive and onto your disk 18:36:39 smcv: :D It does solve the compression... 18:36:54 spwhitton, were you volunteering for doing the pinging in the old bug? Or do we need a different volunteer? 18:37:00 but yes I agree, I should stop trolling and move to the next topic 18:37:02 marga: heh. I can do so. 18:37:14 seems I am the hermes of the committee 18:37:18 #action spwhitton to ping the old bug asking whether it's still relevant. 18:37:20 :) 18:37:27 Alright, next bug 18:37:34 doko: thanks for chiming in. 18:37:43 #topic #978636 - move to merged-usr-only? 18:37:46 smcv: Maybe if ext4 gains support as well. 18:38:11 There was some question over whether this bug makes sense given the previous ruling the TC made. 18:38:34 i.e. wasn't it already the case that we are dropping post-bullseye 18:39:01 Right, the ruling we made was in regards to bullseye, not after bullseye 18:39:18 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 well, it was about buster, and secondarily bullseye 18:39:41 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 Gunnar you're gaslighting me? 18:40:07 marga: ?? 18:40:35 I was the one with the casting vote. I'm now doubting my own reality 18:40:51 the original request on #914897 was about buster 18:41:01 Sorry, I took some notes pre-meeting, but I might be mistaken somehow 18:41:18 all of this predates me 18:41:29 Oh, sorry! 18:41:39 "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 marga: you are completely right -- I took this from a mail _quoted by_ odyx 18:41:43 the "... and for bullseye, ..." part is something the TC added during discussion 18:41:57 and you were the real author 18:42:44 so, indeed, the bug is valid, my apologies. 18:42:57 with the casting vote used to tiebreak between "middle" (status quo) and "hard" (building packages on merged /usr is mandatory) 18:42:58 #link https://lists.debian.org/debian-devel-announce/2019/03/msg00001.html 18:43:04 That's the ruling from 2019 18:44:14 that does seem entirely consistent with wanting to move in the direction of mandatory merged /usr for Debian 12 18:44:41 also consistent with retaining the status quo in Debian 12 18:45:08 I agree, but it would be good to know a bit more about the costs of supporting both. 18:45:30 the main cost of supporting both is that ... we're supporting both 18:45:38 refusing to make a decision is, itself, a decision 18:45:55 smcv: right. I mean specifically what extra work people are having to do to keep both supported. 18:46:25 it's pretty easy to accidentally build packages that work fine on merged-/usr but fail on split-/usr 18:46:28 Is there significant disagreement on the -devel thread? 18:46:41 Or also, what cool new things are impossible until we support only one. 18:46:48 smcv: ah, yes. 18:47:17 I haven't been following -devel lately - This bug has few interactions (three people saying, "yes we should do this" only) 18:47:20 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 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 ansgar: good example. 18:48:28 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 spwhitton: (There is a bug for at least one such rule, but I would need to search.) 18:49:04 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 Now... is this the right moment of Bullseye's life to push for this change? 18:49:33 gwolf: Last time wasn't a ctte bug; people complained 1/2 year later. 18:49:38 I am fine with affirming merged-usr only for bookworm 18:49:39 gwolf: It is not for Bullseye at all. 18:49:42 which is what the bug says 18:49:43 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 marga: our blessing? 18:49:53 gwolf: Only for bookworm/trixie. 18:49:55 I was aiming at letting this cool off until after release, for bookworm 18:50:06 ansgar / ehashman: OK, so I completely agree there 18:50:24 Alright, then we should just vote that we agree that this should be done for bookworm? 18:50:26 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 We won't rule a technical solution, though, as this is not what's being asked of us. 18:50:49 and that instead, we should get to merged /usr via changing every package that ships files outside /usr, individually 18:50:51 yes there's certainly disagreement about the symlink-based aliasing 18:51:16 that would be a different TC bug, however, which may yet get filed 18:51:29 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 if it is feasible, then it's a monumental amount of work 18:52:04 SuSE had /bin/{X} -> /usr/bin/{X} symlinks. 18:52:16 involving maintscripts in multiple packages that have to be carefully correct to avoid data loss 18:52:36 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 right, that's something I'm scared of 18:53:17 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 attempting a transition and getting stuck halfway is worse than either a transition, or no transition 18:53:28 is that something we can close out today? 18:54:00 smcv: I agree. That's why I don't want to follow SuSE's approach :) 18:54:22 ehashman, well, not today as a proper ruling requires a vote 18:54:23 FWIW when we debated in 2019 SuSE was brought up as a (non-)example 18:54:24 (Also that was discussed at buster time.) 18:54:28 But we could start the vote today. 18:54:39 marga: okay, should we have an action for that? 18:54:50 Yes, who wants to start the vote on this? 18:54:54 not it 18:55:06 I can do it. 18:55:11 :tada: 18:55:39 spwhitton, thanks, although you already have a bunch... Nobody else? 18:56:06 is there anyone other than gwolf who would prefer to put this decision off until the bookworm cycle has started? 18:56:06 I am up to my ears in this python thing (which I will discuss when we get to AOB) 18:56:18 fwiw I'm concerned that the only feasible usrmerge implementation available aiui is explicitly declared as broken by the dpkg maintainer 18:56:19 (gwolf I hope I'm not misrepresenting your suggestion?) 18:56:22 smcv: I am fine with deciding now 18:56:39 smcv: I only want this not to bring unstability to bullseye 18:57:31 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 marga: haven't started a vote before so wanted to familiarise myself with how it's done :) 18:57:51 Alright, then. 18:57:52 ntyni: When usrmerge is mandatory (trixie+), bash can just ship /usr/bin/bash. 18:58:16 And path in the *.deb and pyhsical installation path match again. 18:58:30 sounds like we have a path forward? 18:58:32 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 smcv: yes, that can be explicitly mentioned. 18:58:52 smcv++ 18:58:58 ntyni: do you think that should block us resolving the bug? 18:59:14 so options like (1) yes, but not until bullseye has been released; (2) no; (3) FD 18:59:21 #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 (or we can skip the "no" option if nobody would seriously vote for it) 19:00:19 spwhitton: no 19:00:35 as in should not block 19:00:39 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 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 smcv: what is FD? oh, wait, further discussion, derp 19:01:07 I'm like... fire department..? 19:01:08 ntyni: okay then, still useful to have that point of contention mentioned. 19:01:12 sorry yeah not a file descriptor or the front-desk either 19:01:14 I think we can move on. 19:01:24 #topic Possible future Python issue 19:01:27 ehashman, you have the floor 19:01:29 thanks marga ! 19:01:43 heh 19:01:52 summary: a couple of core python devs, acting independently, have raised some concerns with how Debian in Python is being maintained 19:02:20 they approached me for advice (per my role on TC) and I have engaged doko (Python maintainer) and tumbleweed (Python team) 19:02:22 Well, we should just kick Python out of the distribution. 19:02:37 What is the issue, actually? 19:02:43 one sec, let me link 19:03:20 https://archive.is/eqtdf here is an archive of the discussion on GitHub (which is not an official forum) 19:03:21 ln -s /usr/bin/perl /usr/bin/python 19:03:58 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 (sorry, probably shouldn't have said that in this meeting) 19:04:39 I've also spoken with highvoltage as there were tempers running high. hoping to cool things off and work through it! 19:04:56 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 ehashman, my question is: does it look like it might get resolved by people tending to the concerns raised? 19:05:35 marga: I sure hope so 19:06:06 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 it looks like there are some constructive suggestions in that bug 19:06:36 ehashman: have they written to d-python@? 19:06:40 spwhitton: no 19:07:04 I wonder how much of this would be solved by a bunch more Recommends 19:07:19 smcv: I suggested a Python metapackage ala python3-full 19:07:31 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 ehashman: do you think it would work to suggest that to them as a sensible next step? 19:07:39 doko prefers python3-batteries-included :) 19:07:46 yes part of it is docker images that aim to be minimal 19:07:48 spwhitton: I suggested it on that long gist thread 19:07:56 cool. 19:08:31 and they want python3 to be full and anything less full not to be called python3 19:08:36 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 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 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 so there's a difference in what we call "users of our thingy..." 19:09:18 smcv: huh. that is confusing. 19:09:22 perl has just perl-base and perl right? 19:09:34 spwhitton: I believe this is because python3-minimal is the bits of Python required just for bootstrapping Debian 19:09:38 python3-minimal is to perl-base as python3 is to perl 19:09:40 spwhitton: python-minimal == perl-base, python == perl 19:09:52 oh really? 19:10:06 yes; perl has had the same issues and upstream greatly prefers 'perl' to pull in the full package 19:10:11 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 either in Ubuntu, or in Debian as well 19:10:31 it sounds like perl has a lot more in it than python3 however. 19:10:51 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 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 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 ISTM that one obvious possible route would be: python3-minimal < python3 < a new python3-batteries-included (or -full or whatever) 19:12:01 smcv: indeed. 19:12:12 smcv: yup, that's my suggestion 19:12:16 Hard to see Debian people objecting to adding that additional package. 19:12:32 and that could be accomplished before bullseye freeze 19:12:50 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 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 right, although Python people could still complain that python3 does not mean python3-batteries-included 19:13:29 sorry if I was unclear 19:13:42 I meant: transitioning towards python3-interpreter meaning what python3 means today 19:13:42 I like python3-interpreter more than python3-batteries-included (also because batteries-included is an uncommon suffix and too long) 19:13:46 gwolf: I think that's an issue of documentation/education which can be addressed 19:13:48 (my "right" was before smcv's second set of package naming) 19:13:59 and python3 eventually meaning what python3-batteries-included means today 19:14:26 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 (well I know python3-batteries-included doesn't exist today but you know what I mean) 19:14:48 that would be a 1+ release cycle process, IMO 19:14:51 yeah. 19:14:54 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 ...but we have a _lot_ of python3-* dependencies to fix 19:15:13 it is a very large undertaking 19:15:15 * smcv looks sadly at the libgdk-pixbuf(-)2.0-0 transition 19:15:17 yes, for a full release cycle 19:15:27 but now is always a good time to brainstorm, going into the next release 19:15:38 and I think python3-full now, full fix later is a good transitional solution 19:15:50 that 19:15:57 ehashman: Yes. 19:16:04 good to hear we're on board :) 19:16:12 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 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 even if we would eventually prefer 2023 python3 to mean what 2021 python3-full meant 19:16:26 I think we would want to get there via python3-full 19:16:40 Can we offer our official insight to the Python people and see if they agree? 19:16:52 #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 Thanks! 19:17:31 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 FWIW tumbleweed suggested on the thread a "python3-system" package (this is, he suggested this same solution we are aiming at) 19:18:04 *nod* 19:18:07 ehashman: Well... It could be an excercise of "early involvement" of the TC before we are summoned 19:18:24 ...maybe we need to vote on it, to make it an official statement? 19:18:36 when we actually have something concrete to be blessed, you'll be be the first to know :) 19:18:46 procedurally, if we do want it to be an official statement, yes we need to vote on it 19:18:46 we have run way over today, oops 19:18:49 I think 19:19:02 but I'd be inclined to say that's premature at this stage 19:19:09 ehashman: Well, five bugs plus an extra... 19:19:30 It would be good to dsicuss recruitment. 19:19:33 Yes, I'm sorry about the run over 19:19:39 #topic Recruitment efforts 19:19:45 We are lacking a team member 19:19:56 We do have a nominee. 19:20:13 But did we ever reach out to ask them if they actually wanted to join? 19:20:20 No, shall we? 19:20:26 Yeah, we should do that. 19:20:31 it would be good to have multiple nominees if possible 19:20:47 should we send a reminder email to nominate people? have we sent one? 19:20:58 I think Sean sent one 19:21:02 maybe people will be more (or less..) motivated now seeing all our bugs 19:21:03 ehashman: I think we've sent two or maybe even three in the time that we've had that single nominee. 19:21:09 I think it would be good to get the seat filled tbh. 19:21:28 yes 19:21:50 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 so, yes, we have to reach out and get candidates... 19:22:16 gwolf: two thirds majorities are weird with too few people. 19:22:21 ...but it's not like we are acting against the constitution 19:22:24 btw I think our procedures say we need to have a chair election now that fil has left 19:22:33 I can try to use fil's script to send more emails 19:22:36 spwhitton: wouldn't it be ⅔ of the current membership? 19:22:37 I vote: marga 19:22:44 shall we action someone to write to the nominee? 19:22:54 Yes, I wanted to ask that, should we do the chair election now? Or wait until we have the 8th member? 19:23:01 ehashman: votes are cast by publicly archived mail, gpg-signed... 19:23:18 gwolf: are you saying my vote doesn't count?! :P 19:23:23 marga: also, do you want to continue? 19:23:38 and, are you willing? :) 19:23:45 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 gwolf: I am 100% Canadian who just happens to reside in this place 19:24:13 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 ah, right, forgot it! Sorry for mischaracterizing you 19:24:17 hehe 19:24:20 marga: SGTM. 19:24:36 I can write to the nominee 19:25:01 (unless marga wants to as chair of course) 19:25:04 Awesome, thanks ntyni ! 19:25:18 #action ntyni to write to the nominee asking if they are willing to join 19:25:28 #action marga to have a go at fil's script to ask for more nominees. 19:25:51 And let's close now, we are almost half an hour overtime 19:25:55 #endmeeting