17:59:38 <marga> #startmeeting
17:59:38 <MeetBot> 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 <MeetBot> Useful Commands: #action #agreed #help #info #idea #link #topic.
17:59:52 <marga> #topic Roll Call
18:00:00 <fil> Philip Hands
18:00:01 <marga> Good Wednesday, everyone! Who's around?
18:00:04 <marga> Margarita Manterola
18:00:11 <bremner> David Bremner
18:00:32 <ntyni> Niko Tyni
18:00:35 <gwolf> Gunnar Wolf
18:00:38 <spwhitton> Sean Whitton
18:01:53 <marga> #topic Review of previous meeting's AIs
18:01:59 <marga> 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 <smcv> (sorry)
18:02:42 <marga> 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 <marga> Sean also sent the email after that, and we have the new time set.
18:03:20 <bremner> 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 <gwolf> I sent the dudle results, and as a result, we are meeting a bit earlier :-]
18:03:28 <marga> Ack
18:03:47 <marga> Let's jump into the DebConf topic then
18:04:01 <marga> #topic DC20 virtual presentation
18:04:22 <marga> 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 <bremner> I think I have a conflict of interest :P
18:05:24 <marga> haha, it's fine. Let's discuss what we want to do, regardless of who does it.
18:05:48 <marga> 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 <bremner> how long does it take to present them?
18:06:23 <marga> 15 minutes? Maybe less
18:06:41 <gwolf> How "deep" do we want to go into the topics we want to discuss?
18:06:41 <bremner> I would suggest we keep the recap part as short as possible
18:06:42 <fil> should we just edit the video from a previous year? ;-)
18:06:56 <gwolf> I mean, the recap would then take ⅓ of our available time
18:07:07 <bremner> yeah, that's my worry
18:07:39 <bremner> unless we think there is benefit from the recap to the other discussion
18:07:41 <marga> Ok, one suggestion was to put out a "Bits from the Technical Committee" thing, instead of the recap at DebConf
18:07:55 <gwolf> 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 <bremner> 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 <bremner> but I'm a literal greybeard, so...
18:08:55 <marga> Yeah, makes sense.
18:08:59 * spwhitton just lost battery power; reading baclog
18:09:01 <gwolf> bremner: your choice would rather be between talking and typing ;-)
18:09:20 <marga> We can send out the bits and see if we get any feedback (positive or negative) about it.
18:10:02 <marga> 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 <spwhitton> 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 <marga> 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 <bremner> OK. I can cut the existing slides down, does that seem like a reasonable approach?
18:11:24 <spwhitton> bremner: I think so.  be ruthless.
18:11:32 <marga> Yup
18:11:34 <gwolf> I'd say reasonable.
18:11:35 <bremner> where _are_ the existing slides?
18:11:43 <fil> 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 <marga> Pretty sure last year's are in git
18:11:45 <spwhitton> screenshot them out of last year's presentation
18:12:00 <bremner> I can pre-record a narration if desired.
18:12:04 <spwhitton> I think that would be good
18:12:09 <marga> https://salsa.debian.org/debian/tech-ctte/-/tree/master/talks
18:12:23 <gwolf> fil: If we aim for ~5min, I don't think we need to pre-record
18:12:38 <gwolf> besides, video-team will be unhappy at late-delivered videos (deadline was three days ago)
18:12:42 <spwhitton> gwolf: one advantage of recording is that we *know* it is short
18:12:50 <spwhitton> avoids uniuntentional rambling
18:13:46 <bremner> 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 <marga> Let's just aim for 5 minutes-ish
18:14:16 <bremner> ok.
18:14:19 <fil> gwolf: I can always ask the video team
18:14:19 <marga> How do we want to structure the discussion?
18:14:58 <spwhitton> 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 <gwolf> Right, I won't argue against it
18:15:38 <gwolf> 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 <bremner> OK. So I will make slides by sunday, and we'll consider pre-recorded video once we have something to record?
18:17:10 <spwhitton> I think we should decide whether we're going to prereord now
18:17:22 <bremner> I don't mind doing it.
18:17:35 <bremner> I need to work out the bugs before september 9
18:18:14 <fil> 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 <marga> I think we should focus on deciding how we want to structure the rest of the time
18:18:48 <bremner> ack.
18:19:03 <marga> 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 <marga> So, we want to make the most out of that
18:19:19 <bremner> marga: also we want audience participation
18:19:25 <gwolf> marga: add some audience questions and comments
18:19:43 <marga> Ok, then it's 3 minutes per person on avg? Anyway, the point is, we need to have a plan
18:19:43 <bremner> I would say, nominate one person to lead each main topic
18:20:03 <bremner> s/topic/proposal/
18:20:04 <ehashman> ahh I am the worst
18:20:12 <ehashman> hi I'm here I got super distracted by work
18:20:14 <bremner> \o/ I am no longer the worst
18:20:21 <marga> ehashman, o/ Hey there!
18:20:22 <spwhitton> bremner: good idea
18:20:28 <ehashman> late roll call from me: Elana Hashman
18:20:37 <marga> bremner, I like that, yes.
18:20:39 <gwolf> welcome!
18:21:18 <bremner> can we pick 3 or 4 topics / proposals and then carve up the time?
18:21:47 <marga> 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 <bremner> 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 <spwhitton> marga: yes.
18:22:52 <marga> I think there's agreement among committee members that Prop 5 is not desired, so we shouldn't discuss that one
18:23:30 <ehashman> marga: for the minutes, would you mind linking the reference doc so people can look up prop 5?
18:23:32 <gwolf> marga: Agree, just the proposals that can be seen as potential improvements
18:23:37 <marga> Regarding the other 4, I think I'd be interested in hearing opinions and ideas.
18:23:44 <ehashman> (also so I can review it quickly to +/-1 that)
18:23:47 <bremner> what about sam's delegation proposal? is that in the original document?
18:24:01 * bremner <- lazy
18:24:04 <marga> #info The doc is here: https://salsa.debian.org/debian/tech-ctte/-/blob/master/talks/rethinking-the-tc.md
18:24:37 <bremner> so, no.
18:24:41 <marga> bremner, it's not in the original doc, no.
18:24:56 <ehashman> 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 <spwhitton> w.r.t. several proposals, there are some points to clarify when introducing them -- see e-mail I sent today
18:25:38 <spwhitton> #info responses to request for input: https://lists.debian.org/debian-ctte/2020/08/msg00004.html
18:25:39 <marga> 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 <gwolf> 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 <bremner> marga: OK, maybe we could mention we want to focus on the what more than the how due to time limitations
18:26:23 <spwhitton> bremner: yes.
18:26:36 <gwolf> (my answer, as to your "I'd be interested in hearing opinions and ideas")
18:26:54 <marga> 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 <marga> 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 <spwhitton> It's probably for the best that #4 is the last iutem because it is probably the most controversial.
18:29:03 <spwhitton> Sorry, I meant #3.  Shall we swap #3 and #4?
18:29:26 <marga> Sure
18:29:30 <marga> We can swap them
18:30:01 <spwhitton> It would be good to get a lot of agreement and forward momentum from the easier ones, I would hope.
18:30:10 <smcv> 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 <gwolf> sounds good
18:30:52 <marga> Done.
18:31:05 <gwolf> And I think we should first present the four parts, and only after that open for discussion
18:31:11 <ehashman> I might suggest bundling "allow invoking early" near "can raise issues privately" because I suspect they are related
18:31:23 <ehashman> but otherwise I agree with the order
18:31:39 <spwhitton> I think elana is probably right
18:31:56 <spwhitton> they should at least be ordered after one another
18:32:03 <spwhitton> so swap 2 and 3?
18:32:07 <marga> Sure :)
18:32:45 <bremner> I know this algorithm. Luckily n is small
18:32:59 <fil> lol
18:33:31 <bremner> any volunteers to lead discussions?
18:33:53 <marga> I can volunteer for any topic, so whichever one doesn't get a volunteer.
18:33:53 <gwolf> We are eight, there are four points (plus the discussion)
18:34:02 <gwolf> I can... same as marga said :-]
18:34:25 <spwhitton> There are four topics; probably best not Elana and me
18:34:38 <spwhitton> (no offense to elana!!!)
18:34:41 <gwolf> should we pre-record the presentation of each point, or aim for doing it online and hope for the best?
18:34:42 <fil> I'm happy to present the case against us doing design work
18:34:52 <marga> :)
18:35:07 <ehashman> I am an experienced community leader, spwhitton, just (relatively) new to Debian ;)
18:35:21 <spwhitton> gwolf: if we're only allowing three minutes then starting/stopping video is non-negligible
18:35:24 <bremner> I think either ehashman or spwhitton could do a good job as presenter
18:35:25 <spwhitton> ehashman: sorry, yes, forgot about this.
18:35:34 <ehashman> I'm happy to volunteer for the topic of private discussions
18:36:13 <bremner> spwhitton: any are with particular overlap with policy-editor?
18:36:15 <smcv> 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 <gwolf> spwhitton: but we can prepare a video with recap+1+2+3+4, 17 minutes long
18:36:53 <spwhitton> bremner: design work and the technical/non-technical division
18:37:03 <smcv> (not that I've got round to acting on that advice yet, the resulting shell script is scary)
18:37:23 <marga> 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 <spwhitton> we don't have someone to speak in favour of design work
18:37:57 <bremner> I think the pro is in the original discussion
18:37:57 <gwolf> I can talk a bit for design work... but it's not that I'm convinced
18:38:01 <marga> Well, fil can present the case / lead the discussion and then we can say if we disagree?
18:38:01 <bremner> it's wher we get stuck
18:38:13 <gwolf> I mean - Each of us as individuals should be allowed to do design
18:38:15 <fil> 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 <spwhitton> that seems fine
18:38:28 <gwolf> but I also am not a fan of "design by committee" - Which is literally what we'd be discussing
18:39:26 <bremner> I'm going to have to leave at UTC1855, fwiw
18:39:40 <bremner> my work of volunteering other people is done though :P
18:40:03 <bremner> should we try to talk about systemd a little, so seldom before us?
18:40:24 <marga> 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 <marga> But ok. Let's jump to the other topic
18:40:32 <spwhitton> marga: i agree
18:40:39 <spwhitton> marga: interleave presentation and discussion.
18:40:41 <gwolf> marga: 5 (recap) + 3 *4 (for each proposal)
18:40:50 <marga> Ok.
18:41:04 <spwhitton> let's action the presenters of each item?
18:41:10 <marga> #agreed 5 minutes (intro+recap) + 3 *4 (for each proposal).
18:41:11 <spwhitton> to think about how they're going to do it
18:41:11 <gwolf> OK, I won't insist on the 17min at the beginning
18:41:26 <marga> #action ehashman to present Prop 1 (private discussions)
18:41:39 <marga> #action smcv to present Prop 2 (invoke early)
18:41:53 <marga> #action marga to present Prop 3 (mediation body)
18:42:05 <marga> #action fil to present Prop 4 (design work)
18:42:09 <spwhitton> #agreed Prop 5 not to be brought up by us.
18:42:15 <marga> And where it says present, it should be present+lead the discussion
18:42:58 <bremner> #action bremner to make slides for recap, possibly record
18:43:00 <marga> #topic #959828 - systemctl: `Provides: systemd`, but doesn't provide what systemd does
18:43:17 <marga> https://bugs.debian.org/959828
18:43:36 <gwolf> OK... If you see the currently last message on this bug, I have already given my personal opinion on it
18:43:43 <smcv> to me, this feels like an abuse of Provides
18:44:11 <gwolf> OTOH, bremner also mentioned the stable release managers have basically told systemctl's maintainers to desist
18:44:35 <bremner> Dmitry's solution is clearly wrong. OTOH, maybe the underlying problem might be fixable with some goodwill from the systemd maintainers
18:44:38 <smcv> RMs, not SRMs
18:44:48 <smcv> (aiui)
18:44:52 <gwolf> smcv: right
18:44:58 <bremner> anyone disagree that the provides is clearly wrong?
18:45:07 <bremner> anyone on the ctte :P
18:45:25 <spwhitton> bremner: Provides: systemd in particular right?
18:45:30 <bremner> that, yes
18:45:41 <gwolf> bremner: Provides:systemd is clearly wrong.
18:45:43 <marga> 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 <ehashman> bremner: no disagreement, provides:systemd is clearly wrong.
18:45:56 <ehashman> (catching up on the discussion right now)
18:46:09 <smcv> honestly, I don't think there will be any package that can Provides: systemd and is not systemd
18:46:18 <gwolf> (oh, my message is now next-to-last. Thanks Sean!)
18:46:50 <smcv> if you implement systemd API, either the result is the systemd implementation, or something remarkably close to it
18:47:11 <gwolf> smcv: Which would, of course, a moving goalpost and impossible to attain...
18:47:29 <smcv> and in particular so close to it that there would be no point in choosing this hypothetical thing and not systemd
18:47:33 <ehashman> eh, maybe not impossible (i.e. maybe someone decides to independently implement systemd in rust, idk)
18:47:47 <ehashman> hypothetically you could do it, but that is not what is happening here
18:47:51 <smcv> because in any situation where systemd is unsuitable for some reason, the reimpl would be too
18:48:21 <smcv> I can't help thinking that Provides: systemctl is not really appropriate either
18:48:52 <marga> smcv, why?
18:48:57 <smcv> systemctl remote-controls systemd (or "system services" or "the system" if you prefer), the clue's in the name
18:49:15 <gwolf> well, the name is "controls the system"
18:49:23 <gwolf> (and yes, it happens through the system daemon)
18:49:30 <smcv> 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 <smcv> to me, at least
18:49:57 <marga> Uhm, I'm not sure I follow, can you explain?
18:50:54 <gwolf> 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 <spwhitton> gwolf: yes
18:51:06 <smcv> 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 <fil> 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 <smcv> because service(8) is an abstraction layer
18:51:28 <smcv> or "service avahi start" or however you spell it
18:51:45 <ehashman> possily helpful context is https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=968514
18:52:15 <smcv> if you do "systemctl start avahi", that means something more concrete
18:52:16 <gwolf> 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 <marga> But service got deprecated
18:52:59 <marga> And now everyone needs to hardcode systemctl in their scripts
18:53:23 <smcv> 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 <fil> me too -- that's tiresome
18:53:57 <gwolf> bremner: o/ !
18:54:19 <fil> (replying to smcv)
18:54:20 <marga> 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 <spwhitton> marga: do you have a reference for the deprecation?
18:54:31 <spwhitton> oh, it not being there, I see
18:54:43 <marga> If it's not installed by default, then scripts can't depend on it.
18:54:44 <spwhitton> hmm, I'm on buster too, and I have it.
18:54:52 <smcv> init-system-helpers: /usr/sbin/service
18:54:57 <smcv> I thought that was Essential
18:55:12 <marga> Ah, ok, then I'm just wrong because of PATH issues. Sorry!
18:55:14 <gwolf> smcv: It is in Sid
18:55:24 <gwolf> required + essential
18:55:25 <spwhitton> okay, so it doesn't seem to be deprecated.
18:55:34 <spwhitton> maybe the solution to dmitry's bug involves service(8) then?
18:55:35 <marga> But I did hear it was deprecated, so when I got the "command not found" error I assumed that was it.
18:55:42 <smcv> 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 <spwhitton> marga: maybe other distros have deprecated it.  seems we haven't.
18:56:15 <smcv> it would make sense for a distro that only supports systemd to deprecate it
18:56:18 <smcv> but we are not that
18:56:20 <ehashman> okay so I have just done a bunch of reading and I'm not sure I'm following this discussion
18:56:34 <marga> Sorry, that was my fault for adding tons of noise :-/
18:56:37 <ehashman> the package in question is called "systemctl" but isn't actually systemctl.
18:56:46 <smcv> its upstream name is docker-systemctl-replacement
18:56:49 <ehashman> and it also has a Provides: systemd
18:56:53 <ehashman> which is clearly wrong
18:56:59 <marga> Yup, both things are wrong.
18:57:22 <gwolf> 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 <ehashman> so is what we are discussing now whether it's appropriate for the package to say e.g. provides: systemctl?
18:57:25 <smcv> 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 <ehashman> upstream: https://github.com/gdraheim/docker-systemctl-replacement
18:57:38 <spwhitton> ehashman: that plus other options involving service(8)[5~
18:57:53 <smcv> for containers where a full-fat init system (including sysvinit/sysv-rc in this case) is too much
18:57:54 <ehashman> tagline: "This script may be used to overwrite "/usr/bin/systemctl". It will execute the systemctl commands without SystemD!"
18:57:54 <fil> 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 <marga> 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 <ehashman> fil: yes, and presumably that's why #968514 was filed
18:58:54 <ehashman> which is related to #959828 but not quite the same
18:58:55 <spwhitton> Could Dmitry's bug have been fixed with Depends: systemd | docker-systemctl-replacement?
18:59:21 <spwhitton> If so that seems like obviously the best thing to do.  But perhaps things are more complciated.
18:59:42 <gwolf> spwhitton: The php-fpm package in question that triggered this needs systemd-tmpfiles
19:00:25 <gwolf> spwhitton: And that maintainer does not like the idea of making things easier for Dmitry
19:00:36 <smcv> 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 <smcv> it's pretty common for service files to assume that their corresponding tmpfiles have already been processed
19:01:30 <gwolf> So the urgent thing to do for this would be to define the breadth of systemctl's functionality
19:01:49 <gwolf> if it makes sense to have it separated from systemd as a whole
19:02:04 <spwhitton> I think the real dispute is in the package metadata for php-fpm.
19:02:13 <spwhitton> That is what we could possibly be asked to rule on.
19:02:17 <smcv> I don't think this is a good place to put an abstraction layer
19:02:45 <smcv> systemctl wasn't designed to be an abstraction layer between different ways to start services
19:03:13 <gwolf> 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 <gwolf> ...and php-fpm makes sense to be a package installed in a container
19:04:11 <marga> I think it makes sense to have "container versions" of the systemd tools, like tmpfiles or systemctl
19:04:13 <smcv> spwhitton: you are referring to php7.4-fpm Depends systemd | systemd-tmpfiles?
19:04:36 <marga> They should be clearly identified as such...
19:04:37 <smcv> I think it makes sense to have "container versions" of tmpfiles, sysusers
19:04:38 <spwhitton> smcv: yes.
19:04:51 <smcv> OpenRC already has those, aiui
19:05:04 <marga> 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 <smcv> either as part of it or as adjacent projects
19:05:34 <spwhitton> marga: hmm, so the systemd (real) binary package would get split into providing tmpfiles as a separate binary package?
19:05:53 <spwhitton> Then php-fpm could depend on that?
19:06:05 <marga> It doesn't need to be separate to provide it
19:06:19 <spwhitton> It needs to be separate to let dmitry do what he wants though
19:06:20 <fil> spwhitton: why not just have it also build the tempfiles bit as a separate package
19:06:33 <spwhitton> fil: I think that's what I meant.
19:06:34 <fil> or what marga said
19:06:49 <marga> 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 <smcv> 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 <fil> spwhitton: OK, sounded like inflicting a death by a thousand cuts on the systemd maintainers ;-)
19:08:00 <smcv> so the designers of the "API" clearly intend it to be something you could split out, or reimplement
19:08:22 <smcv> systemctl, not so much
19:08:34 <spwhitton> fil: I'm a bit lost; where did you think marga and I are disagreeing?
19:09:09 <fil> now, not -- don't worry :-)
19:09:23 <fil> (was my misinterpretation)
19:09:42 <marga> 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 <marga> Anyway, do we want to take some kind of action here?
19:10:48 <gwolf> marga: The bug has not yet been forwarded to us formally
19:11:04 <marga> Sure, we can't use constitutional powers
19:11:11 <marga> We can still act as developers and what not
19:11:13 <gwolf> ... Would it make sense for one of us (that could be me) to file a bug on the issue?
19:11:39 <gwolf> ...Otherwise, we'd just be defering the action until somebody™ does it
19:11:48 <smcv> 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 <gwolf> (I have to leave shortly)
19:12:20 <spwhitton> I think we've established what the advice would be
19:12:24 <spwhitton> That is perhaps enough for now
19:12:50 <marga> So, someone comments on the bug with our advice?
19:13:13 <spwhitton> Well, that would be a ste further
19:13:22 <spwhitton> But, it would be an example of being more proactive
19:14:02 <spwhitton> 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 <marga> Ok... Does anybody here feel like they can offer advice without raising anger?
19:14:25 <gwolf> spwhitton: Then we invoke the Community Team! \o/
19:14:43 <fil> 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 <spwhitton> marga: as an individual, you mean?
19:15:12 <marga> fil, I think it depends on how it's framed.
19:15:14 <gwolf> (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 <marga> spwhitton, sure, but I'd include a paragraph saying that this was discussed during our meeting or something.
19:15:41 <marga> I like how fil put it :)
19:15:43 <smcv> fil: good summary IMO
19:15:44 <fil> both sides could have assumed worse, so this is probably progress :-)
19:16:06 <spwhitton> 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 <gwolf> I can take that #action if you want
19:16:40 <marga> Ok!
19:16:42 <smcv> 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 <gwolf> Just tell me later :-]
19:16:48 * gwolf AFK
19:16:55 <marga> #gwolf to follow up with advice from this meeting.
19:17:12 <spwhitton> #action gwolf to follow up with advice from this meeting.
19:17:12 <marga> smcv, indeed
19:17:22 <marga> thanks. Sorry. It's been a long day
19:17:31 <marga> Shall we end the meeting here?
19:17:44 <spwhitton> Okay with me.
19:17:58 <smcv> 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 <smcv> maaaaaaybe loginctl, as part of Provides: logind, which we already have for elogind
19:19:16 <ehashman> I've gotta run, so yes let's end it
19:19:19 <smcv> but probably not the others
19:19:25 <marga> Alright! Thanks everybody!
19:19:28 <marga> #endmeeting