17:59:38 #startmeeting 17:59:38 Meeting started Wed Aug 19 17:59:38 2020 UTC. The chair is marga. Information about MeetBot at http://wiki.debian.org/MeetBot. 17:59:38 Useful Commands: #action #agreed #help #info #idea #link #topic. 17:59:52 #topic Roll Call 18:00:00 Philip Hands 18:00:01 Good Wednesday, everyone! Who's around? 18:00:04 Margarita Manterola 18:00:11 David Bremner 18:00:32 Niko Tyni 18:00:35 Gunnar Wolf 18:00:38 Sean Whitton 18:01:53 #topic Review of previous meeting's AIs 18:01:59 Meeting notes at: http://meetbot.debian.net/debian-ctte/2020/debian-ctte.2020-07-15-18.58.html 18:02:01 * smcv Simon McVittie 18:02:03 (sorry) 18:02:42 I seem to have done everything assigned to me. That must be a first :). I closed the node-katex bug and sent the text for the DebConf discussion. 18:03:04 Sean also sent the email after that, and we have the new time set. 18:03:20 I did not make slides for the BoF. Should I? if so, what should go on them? perhaps a discussion item for later in the meeting. 18:03:26 I sent the dudle results, and as a result, we are meeting a bit earlier :-] 18:03:28 Ack 18:03:47 Let's jump into the DebConf topic then 18:04:01 #topic DC20 virtual presentation 18:04:22 So, I think we need to decide what we want in the slides (if we want slides at all) and how we want to structure the discussion. 18:05:00 I think I have a conflict of interest :P 18:05:24 haha, it's fine. Let's discuss what we want to do, regardless of who does it. 18:05:48 One option is to simply re-use the slides that we've used last year, just updating them to this year. I think that should take less than an hour of work 18:06:06 how long does it take to present them? 18:06:23 15 minutes? Maybe less 18:06:41 How "deep" do we want to go into the topics we want to discuss? 18:06:41 I would suggest we keep the recap part as short as possible 18:06:42 should we just edit the video from a previous year? ;-) 18:06:56 I mean, the recap would then take ⅓ of our available time 18:07:07 yeah, that's my worry 18:07:39 unless we think there is benefit from the recap to the other discussion 18:07:41 Ok, one suggestion was to put out a "Bits from the Technical Committee" thing, instead of the recap at DebConf 18:07:55 I'm not sure it's as important. FWIW we would anyway go to the bugs' history to comment on them... which is open to anybody 18:08:37 yeah, I suggested the bits thing. I feel like if given the choice between watching 15minutes of video or skimming an email, I prefer the skimming 18:08:50 but I'm a literal greybeard, so... 18:08:55 Yeah, makes sense. 18:08:59 * spwhitton just lost battery power; reading baclog 18:09:01 bremner: your choice would rather be between talking and typing ;-) 18:09:20 We can send out the bits and see if we get any feedback (positive or negative) about it. 18:10:02 So, assuming we do the bits for the "what we did since last DebConf", the rest of the slides would be a mini-intro. Maybe 5 minutes? 18:10:14 I agree that given our particular goals this year we should make the intro as short as possible, and a Bits mail seems like a good way to do that. 18:10:42 I guess we would want to say who we are, why the tech ctte even exists, and then jump into the issues that we're trying to discuss and improve upon? 18:11:16 OK. I can cut the existing slides down, does that seem like a reasonable approach? 18:11:24 bremner: I think so. be ruthless. 18:11:32 Yup 18:11:34 I'd say reasonable. 18:11:35 where _are_ the existing slides? 18:11:43 should we be trying to pre-record that? I probably have some spare time in the next days, but don't know the tools for that sort of thing, so not sure how long it takes 18:11:45 Pretty sure last year's are in git 18:11:45 screenshot them out of last year's presentation 18:12:00 I can pre-record a narration if desired. 18:12:04 I think that would be good 18:12:09 https://salsa.debian.org/debian/tech-ctte/-/tree/master/talks 18:12:23 fil: If we aim for ~5min, I don't think we need to pre-record 18:12:38 besides, video-team will be unhappy at late-delivered videos (deadline was three days ago) 18:12:42 gwolf: one advantage of recording is that we *know* it is short 18:12:50 avoids uniuntentional rambling 18:13:46 well, if it's more hassle for video team to have a late submission, I guess not. I didn't imagine doing this before this weekend 18:14:09 Let's just aim for 5 minutes-ish 18:14:16 ok. 18:14:19 gwolf: I can always ask the video team 18:14:19 How do we want to structure the discussion? 18:14:58 Presumably around the document marga prepared. but maybe we want to not discuss options we already know we aren't on board with, unless an audience member brings itup. 18:15:23 Right, I won't argue against it 18:15:38 We can even play the prerecorded video via any of our Jitsi sessions 18:16:32 * fil suspects that the video team would be grumpy if we did that and it turned out crappy, when we could have just given them the video 18:16:46 OK. So I will make slides by sunday, and we'll consider pre-recorded video once we have something to record? 18:17:10 I think we should decide whether we're going to prereord now 18:17:22 I don't mind doing it. 18:17:35 I need to work out the bugs before september 9 18:18:14 I'm happy to spend time on it, but we need to ask the video folks if they are happy to get more videos at this stage 18:18:41 I think we should focus on deciding how we want to structure the rest of the time 18:18:48 ack. 18:19:03 There's 8 of us, so the amount of time per person is going to be short. 5 minutes per person on average. 18:19:10 So, we want to make the most out of that 18:19:19 marga: also we want audience participation 18:19:25 marga: add some audience questions and comments 18:19:43 Ok, then it's 3 minutes per person on avg? Anyway, the point is, we need to have a plan 18:19:43 I would say, nominate one person to lead each main topic 18:20:03 s/topic/proposal/ 18:20:04 ahh I am the worst 18:20:12 hi I'm here I got super distracted by work 18:20:14 \o/ I am no longer the worst 18:20:21 ehashman, o/ Hey there! 18:20:22 bremner: good idea 18:20:28 late roll call from me: Elana Hashman 18:20:37 bremner, I like that, yes. 18:20:39 welcome! 18:21:18 can we pick 3 or 4 topics / proposals and then carve up the time? 18:21:47 And I think we need to start with a "point of order" of not spending time explaining that we agree if we agree. i.e. if I'm just going to agree with Gunnar on something, instead of saying "I agree with Gunnar because of X, Y, Z", just saying "I agree with Gunnar". 18:21:52 * fil asks about pre-recording on #debconf-video 18:22:00 or maybe 2 if we have favourites, and an "any other business" section 18:22:12 * ehashman is caught up on backscroll now 18:22:47 marga: yes. 18:22:52 I think there's agreement among committee members that Prop 5 is not desired, so we shouldn't discuss that one 18:23:30 marga: for the minutes, would you mind linking the reference doc so people can look up prop 5? 18:23:32 marga: Agree, just the proposals that can be seen as potential improvements 18:23:37 Regarding the other 4, I think I'd be interested in hearing opinions and ideas. 18:23:44 (also so I can review it quickly to +/-1 that) 18:23:47 what about sam's delegation proposal? is that in the original document? 18:24:01 * bremner <- lazy 18:24:04 #info The doc is here: https://salsa.debian.org/debian/tech-ctte/-/blob/master/talks/rethinking-the-tc.md 18:24:37 so, no. 18:24:41 bremner, it's not in the original doc, no. 18:24:56 thank you! I agree that I don't think proposal 5 ("Abolish the TC and split it into separate roles.") makes sense and don't want to dedicate much time to discussing it. 18:25:21 w.r.t. several proposals, there are some points to clarify when introducing them -- see e-mail I sent today 18:25:38 #info responses to request for input: https://lists.debian.org/debian-ctte/2020/08/msg00004.html 18:25:39 bremner, I think in the end his proposal is a way to achieve the necessary changes (by lifting the constitution restriction, which still requires a constitution change). I'm personally more interested in what changes we want to achieve rather than how we vote for them. 18:25:58 marga: I have to re-read the proposal + discussion... sorry, I have had many things on my head and am not very clear on anyghing right now 18:26:10 marga: OK, maybe we could mention we want to focus on the what more than the how due to time limitations 18:26:23 bremner: yes. 18:26:36 (my answer, as to your "I'd be interested in hearing opinions and ideas") 18:26:54 gwolf, sure, well, you still got a week and a half :) 18:27:03 * fil is against allowing TC (as a body) to do design, which seems to be bundled up with #4 in part 18:28:42 bremner, I think that makes sense. Because once we know what we want to achieve it's easier to figure out the how 18:28:46 It's probably for the best that #4 is the last iutem because it is probably the most controversial. 18:29:03 Sorry, I meant #3. Shall we swap #3 and #4? 18:29:26 Sure 18:29:30 We can swap them 18:30:01 It would be good to get a lot of agreement and forward momentum from the easier ones, I would hope. 18:30:10 so the order would be "can raise issues privately", "mediation body", "allow invoking early", "allow design work", and then don't discuss "split responsibilities" 18:30:39 sounds good 18:30:52 Done. 18:31:05 And I think we should first present the four parts, and only after that open for discussion 18:31:11 I might suggest bundling "allow invoking early" near "can raise issues privately" because I suspect they are related 18:31:23 but otherwise I agree with the order 18:31:39 I think elana is probably right 18:31:56 they should at least be ordered after one another 18:32:03 so swap 2 and 3? 18:32:07 Sure :) 18:32:45 I know this algorithm. Luckily n is small 18:32:59 lol 18:33:31 any volunteers to lead discussions? 18:33:53 I can volunteer for any topic, so whichever one doesn't get a volunteer. 18:33:53 We are eight, there are four points (plus the discussion) 18:34:02 I can... same as marga said :-] 18:34:25 There are four topics; probably best not Elana and me 18:34:38 (no offense to elana!!!) 18:34:41 should we pre-record the presentation of each point, or aim for doing it online and hope for the best? 18:34:42 I'm happy to present the case against us doing design work 18:34:52 :) 18:35:07 I am an experienced community leader, spwhitton, just (relatively) new to Debian ;) 18:35:21 gwolf: if we're only allowing three minutes then starting/stopping video is non-negligible 18:35:24 I think either ehashman or spwhitton could do a good job as presenter 18:35:25 ehashman: sorry, yes, forgot about this. 18:35:34 I'm happy to volunteer for the topic of private discussions 18:36:13 spwhitton: any are with particular overlap with policy-editor? 18:36:15 given that I'm the only person I can remember "asking the TC for advice", which is the closest thing we can constitutionally do aiui, perhaps I should talk about invoking the TC early... 18:36:52 spwhitton: but we can prepare a video with recap+1+2+3+4, 17 minutes long 18:36:53 bremner: design work and the technical/non-technical division 18:37:03 (not that I've got round to acting on that advice yet, the resulting shell script is scary) 18:37:23 Alright, so we have: Prop 1 (private discussions): ehashman. Prop 2 (invoke early): smcv. Prop 3: (mediation body): marga. Prop 4: (design work): fil. 18:37:33 we don't have someone to speak in favour of design work 18:37:57 I think the pro is in the original discussion 18:37:57 I can talk a bit for design work... but it's not that I'm convinced 18:38:01 Well, fil can present the case / lead the discussion and then we can say if we disagree? 18:38:01 it's wher we get stuck 18:38:13 I mean - Each of us as individuals should be allowed to do design 18:38:15 I'll happily say why people like the idea, if you want to tell me, so it doesn't have to turn adversarial 18:38:23 that seems fine 18:38:28 but I also am not a fan of "design by committee" - Which is literally what we'd be discussing 18:39:26 I'm going to have to leave at UTC1855, fwiw 18:39:40 my work of volunteering other people is done though :P 18:40:03 should we try to talk about systemd a little, so seldom before us? 18:40:24 Alright, so we have the moderators. I'm not sure where the 17 minute mark from above came... I'm not convinced that we want a long presentation first and only then discussion. I think I'd rather have each proposal presented and discussed. 18:40:30 * gwolf sighs and agrees 18:40:30 But ok. Let's jump to the other topic 18:40:32 marga: i agree 18:40:39 marga: interleave presentation and discussion. 18:40:41 marga: 5 (recap) + 3 *4 (for each proposal) 18:40:50 Ok. 18:41:04 let's action the presenters of each item? 18:41:10 #agreed 5 minutes (intro+recap) + 3 *4 (for each proposal). 18:41:11 to think about how they're going to do it 18:41:11 OK, I won't insist on the 17min at the beginning 18:41:26 #action ehashman to present Prop 1 (private discussions) 18:41:39 #action smcv to present Prop 2 (invoke early) 18:41:53 #action marga to present Prop 3 (mediation body) 18:42:05 #action fil to present Prop 4 (design work) 18:42:09 #agreed Prop 5 not to be brought up by us. 18:42:15 And where it says present, it should be present+lead the discussion 18:42:58 #action bremner to make slides for recap, possibly record 18:43:00 #topic #959828 - systemctl: `Provides: systemd`, but doesn't provide what systemd does 18:43:17 https://bugs.debian.org/959828 18:43:36 OK... If you see the currently last message on this bug, I have already given my personal opinion on it 18:43:43 to me, this feels like an abuse of Provides 18:44:11 OTOH, bremner also mentioned the stable release managers have basically told systemctl's maintainers to desist 18:44:35 Dmitry's solution is clearly wrong. OTOH, maybe the underlying problem might be fixable with some goodwill from the systemd maintainers 18:44:38 RMs, not SRMs 18:44:48 (aiui) 18:44:52 smcv: right 18:44:58 anyone disagree that the provides is clearly wrong? 18:45:07 anyone on the ctte :P 18:45:25 bremner: Provides: systemd in particular right? 18:45:30 that, yes 18:45:41 bremner: Provides:systemd is clearly wrong. 18:45:43 I didn't read all 134 messages to have a full opinion :-/. But if something Provides systemd it should be a drop in replacement. 18:45:49 bremner: no disagreement, provides:systemd is clearly wrong. 18:45:56 (catching up on the discussion right now) 18:46:09 honestly, I don't think there will be any package that can Provides: systemd and is not systemd 18:46:18 (oh, my message is now next-to-last. Thanks Sean!) 18:46:50 if you implement systemd API, either the result is the systemd implementation, or something remarkably close to it 18:47:11 smcv: Which would, of course, a moving goalpost and impossible to attain... 18:47:29 and in particular so close to it that there would be no point in choosing this hypothetical thing and not systemd 18:47:33 eh, maybe not impossible (i.e. maybe someone decides to independently implement systemd in rust, idk) 18:47:47 hypothetically you could do it, but that is not what is happening here 18:47:51 because in any situation where systemd is unsuitable for some reason, the reimpl would be too 18:48:21 I can't help thinking that Provides: systemctl is not really appropriate either 18:48:52 smcv, why? 18:48:57 systemctl remote-controls systemd (or "system services" or "the system" if you prefer), the clue's in the name 18:49:15 well, the name is "controls the system" 18:49:23 (and yes, it happens through the system daemon) 18:49:30 having a thing called systemctl run the service as a child process of itself , rather than "tell that thing over there to run the service", seems badly expectation-breaking 18:49:47 to me, at least 18:49:57 Uhm, I'm not sure I follow, can you explain? 18:50:54 smcv: I guess (spwhitton, correct me if I'm wrong) that if we add the virtual package to Policy, it would be via agreeing what each of them is supposed to do 18:51:03 gwolf: yes 18:51:06 if you do "service start avahi", it's undefined whether avahi inherits some of the execution environment of where you are now, or whether you're doing IPC to systemd or Upstart or equivalent to tell it "go and run this thing please" 18:51:10 the problem is presumably when systemctl inevitably grows some extra functionality -- does a package that Provides: systemctl offer that functionality or not? 18:51:16 because service(8) is an abstraction layer 18:51:28 or "service avahi start" or however you spell it 18:51:45 possily helpful context is https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=968514 18:52:15 if you do "systemctl start avahi", that means something more concrete 18:52:16 So, it can be either commanding systemd-the-PID1-daemon, or it can be the user-viewable results (starting/stopping/querying specific services) 18:52:47 But service got deprecated 18:52:59 And now everyone needs to hardcode systemctl in their scripts 18:53:23 did it? I thought it was how sysadmins (can) start services if they have forgotten which init system this machine is using 18:53:51 * bremner sneaks out of the meeting 18:53:56 me too -- that's tiresome 18:53:57 bremner: o/ ! 18:54:19 (replying to smcv) 18:54:20 smcv, it was, and then someone decided that it wasn't a good idea for some reason. I have a buster installation on my machine and there's no service 18:54:22 marga: do you have a reference for the deprecation? 18:54:31 oh, it not being there, I see 18:54:43 If it's not installed by default, then scripts can't depend on it. 18:54:44 hmm, I'm on buster too, and I have it. 18:54:52 init-system-helpers: /usr/sbin/service 18:54:57 I thought that was Essential 18:55:12 Ah, ok, then I'm just wrong because of PATH issues. Sorry! 18:55:14 smcv: It is in Sid 18:55:24 required + essential 18:55:25 okay, so it doesn't seem to be deprecated. 18:55:34 maybe the solution to dmitry's bug involves service(8) then? 18:55:35 But I did hear it was deprecated, so when I got the "command not found" error I assumed that was it. 18:55:42 I thought one of the major reasons it's Essential is *because* it took over service, invoke-rc.d and friends from sysvinit :-P 18:56:00 marga: maybe other distros have deprecated it. seems we haven't. 18:56:15 it would make sense for a distro that only supports systemd to deprecate it 18:56:18 but we are not that 18:56:20 okay so I have just done a bunch of reading and I'm not sure I'm following this discussion 18:56:34 Sorry, that was my fault for adding tons of noise :-/ 18:56:37 the package in question is called "systemctl" but isn't actually systemctl. 18:56:46 its upstream name is docker-systemctl-replacement 18:56:49 and it also has a Provides: systemd 18:56:53 which is clearly wrong 18:56:59 Yup, both things are wrong. 18:57:22 ehashman: Right, it is *a* systemctl, but it's not *the* systemctl, and it's definitively not what a user would expect 18:57:22 so is what we are discussing now whether it's appropriate for the package to say e.g. provides: systemctl? 18:57:25 the idea is you do "systemctl start nginx" and it translates that into essentially the equivalent of what "/etc/init.d/nginx start" would have done in sysvinit-land 18:57:34 upstream: https://github.com/gdraheim/docker-systemctl-replacement 18:57:38 ehashman: that plus other options involving service(8)[5~ 18:57:53 for containers where a full-fat init system (including sysvinit/sysv-rc in this case) is too much 18:57:54 tagline: "This script may be used to overwrite "/usr/bin/systemctl". It will execute the systemctl commands without SystemD!" 18:57:54 It would be much less wrong to do the provides if the package was called docker-systemctl-replacement, since nobody would be very surprised with the results then 18:58:14 ehashman, yeah. The discussion was whether it made sense at all for a package to provide systemctl given the expectation from users that systemctl will be controlling systemd and not a random other init system 18:58:21 fil: yes, and presumably that's why #968514 was filed 18:58:54 which is related to #959828 but not quite the same 18:58:55 Could Dmitry's bug have been fixed with Depends: systemd | docker-systemctl-replacement? 18:59:21 If so that seems like obviously the best thing to do. But perhaps things are more complciated. 18:59:42 spwhitton: The php-fpm package in question that triggered this needs systemd-tmpfiles 19:00:25 spwhitton: And that maintainer does not like the idea of making things easier for Dmitry 19:00:36 I don't think you get to claim to be an implementation of systemd service files without having an implementation of systemd-tmpfiles, tbh 19:00:58 it's pretty common for service files to assume that their corresponding tmpfiles have already been processed 19:01:30 So the urgent thing to do for this would be to define the breadth of systemctl's functionality 19:01:49 if it makes sense to have it separated from systemd as a whole 19:02:04 I think the real dispute is in the package metadata for php-fpm. 19:02:13 That is what we could possibly be asked to rule on. 19:02:17 I don't think this is a good place to put an abstraction layer 19:02:45 systemctl wasn't designed to be an abstraction layer between different ways to start services 19:03:13 FWIW Dmitry's use case makes sense; having systemd in a container is a bit too much. But I agree with smcv's points all in all. 19:03:24 ...and php-fpm makes sense to be a package installed in a container 19:04:11 I think it makes sense to have "container versions" of the systemd tools, like tmpfiles or systemctl 19:04:13 spwhitton: you are referring to php7.4-fpm Depends systemd | systemd-tmpfiles? 19:04:36 They should be clearly identified as such... 19:04:37 I think it makes sense to have "container versions" of tmpfiles, sysusers 19:04:38 smcv: yes. 19:04:51 OpenRC already has those, aiui 19:05:04 And I think ideally we would want to have virtual packages so that it's easy for maintainers to put the right deps in their packages 19:05:05 either as part of it or as adjacent projects 19:05:34 marga: hmm, so the systemd (real) binary package would get split into providing tmpfiles as a separate binary package? 19:05:53 Then php-fpm could depend on that? 19:06:05 It doesn't need to be separate to provide it 19:06:19 It needs to be separate to let dmitry do what he wants though 19:06:20 spwhitton: why not just have it also build the tempfiles bit as a separate package 19:06:33 fil: I think that's what I meant. 19:06:34 or what marga said 19:06:49 fil, this was discussed last year, I think? There were issues with size, but I thought they were going to do it. 19:07:10 I think it's relevant that https://systemd.io/PORTABILITY_AND_STABILITY/ calls out tmpfiles.d and sysusers.d as "independently reimplementable: yes", "systemd impl is portable: partially" 19:07:26 spwhitton: OK, sounded like inflicting a death by a thousand cuts on the systemd maintainers ;-) 19:08:00 so the designers of the "API" clearly intend it to be something you could split out, or reimplement 19:08:22 systemctl, not so much 19:08:34 fil: I'm a bit lost; where did you think marga and I are disagreeing? 19:09:09 now, not -- don't worry :-) 19:09:23 (was my misinterpretation) 19:09:42 spwhitton, I think there was a misunderstanding with the overloading of the word "providing". It took me a few reads to get what you meant. 19:10:02 Anyway, do we want to take some kind of action here? 19:10:48 marga: The bug has not yet been forwarded to us formally 19:11:04 Sure, we can't use constitutional powers 19:11:11 We can still act as developers and what not 19:11:13 ... Would it make sense for one of us (that could be me) to file a bug on the issue? 19:11:39 ...Otherwise, we'd just be defering the action until somebody™ does it 19:11:48 having literally just looked at the constitution as a result of the other topic: we can "offer advice" unsolicited, although in this case it might just make everyone angrier 19:12:03 (I have to leave shortly) 19:12:20 I think we've established what the advice would be 19:12:24 That is perhaps enough for now 19:12:50 So, someone comments on the bug with our advice? 19:13:13 Well, that would be a ste further 19:13:22 But, it would be an example of being more proactive 19:14:02 I am inclined to go ahead and issue the advice because it would move things forward, but there is a risk of just increaisng anger. 19:14:23 Ok... Does anybody here feel like they can offer advice without raising anger? 19:14:25 spwhitton: Then we invoke the Community Team! \o/ 19:14:43 I'd have thought this discussion clearly demonstrates that we're sympathetic with the quest for having less systemd in containers, but not convinced by the way it's been attempted with the provides and package naming -- is that something to get angry about? 19:14:44 marga: as an individual, you mean? 19:15:12 fil, I think it depends on how it's framed. 19:15:14 (in a more serious tone - I sent my mail earlier today as an individual, but in order to do so as the Committee... wouldn't we have to vote on said advice?) 19:15:34 spwhitton, sure, but I'd include a paragraph saying that this was discussed during our meeting or something. 19:15:41 I like how fil put it :) 19:15:43 fil: good summary IMO 19:15:44 both sides could have assumed worse, so this is probably progress :-) 19:16:06 Yes, an individual essentially reporting the meeting sounds like a good idea. 19:16:23 * gwolf quietly disappears. I am being required Elsewhere™ 19:16:34 I can take that #action if you want 19:16:40 Ok! 19:16:42 having less/no systemd in your container seems a fine goal to have, but I don't think pretending to be systemd is the right way to achieve it 19:16:42 Just tell me later :-] 19:16:48 * gwolf AFK 19:16:55 #gwolf to follow up with advice from this meeting. 19:17:12 #action gwolf to follow up with advice from this meeting. 19:17:12 smcv, indeed 19:17:22 thanks. Sorry. It's been a long day 19:17:31 Shall we end the meeting here? 19:17:44 Okay with me. 19:17:58 gwolf: one thing I don't agree with from your earlier mail is: I don't think journalctl, loginctl, systemctl are likely to be a good "API" to provide 19:18:48 maaaaaaybe loginctl, as part of Provides: logind, which we already have for elogind 19:19:16 I've gotta run, so yes let's end it 19:19:19 but probably not the others 19:19:25 Alright! Thanks everybody! 19:19:28 #endmeeting