19:00:08 #startmeeting 19:00:08 Meeting started Wed Feb 19 19:00:08 2020 UTC. The chair is marga. Information about MeetBot at http://wiki.debian.org/MeetBot. 19:00:08 Useful Commands: #action #agreed #help #info #idea #link #topic. 19:00:13 #topic Roll Call 19:00:20 Is there anybody out there? 19:00:34 * ntyni waves 19:00:40 Niko Tyni 19:00:54 Margarita Manterola 19:01:46 Uhm... 19:02:07 not a very good turnout tonight it seems 19:02:21 :-/ 19:02:22 * OdyX hides. 19:03:37 Maybe sending "same day" notices is not that bad. 19:04:07 Anyways... Let's proceed 19:04:15 #topic Review of previous meeting AIs 19:04:16 hi 19:04:27 Kudos to ntyni for completing his task :) 19:04:32 I failed at mine :(. 19:04:40 Philip Hands (just noticed the time) 19:04:58 yeah, mine was certainly easier :) 19:05:27 *But*, I have 3 free weeks coming up and I intend to do Debian work during them, so this goes to the top of my TODO list for that time 19:05:58 sounds good! 19:06:01 (I'm switching jobs and those are my "in-between" weeks) 19:06:16 #action marga to work on "The role of the TC" in the coming week. For real this time. 19:06:42 #topic #947847 - please install systemd-sysusers using update-alternatives 19:07:03 Alright, so we have a systemd controversy on our hands... Although traffic on the bug has pretty much died out by now. 19:07:50 #946456 is somewhat related too 19:08:32 ("systemd: Provide systemd-sysusers as an independent package") 19:10:59 Ok, I'm reading that bug, I hadn't read it before... 19:12:47 OdyX mentioned it in the #947847 bug log I think 19:13:54 Ok, so that bug is going in the direction of providing a package that ships this binaries with a Conflicts against systemd, so that it's used only in containers and not in systems running with systemd as init 19:15:19 yes, I think so too 19:15:23 Shipping the tools in a separate package that can be replaced by the other one seemed like a nice compromise, but the maintainers don't seem willing to do it given that there would be long term maintenance costs and very few benefits 19:15:24 which seems entirely reasonable 19:15:55 (on both sides, sadly) 19:16:40 I feel like providing sysusers and tmpfiles interfaces would be an acceptable compromise but it does have the disadvantage of it being Debian specific 19:17:18 I mean, having /bin/sysusers be an alternative to whichever implementation and have maintscripts use that instead of systemd-sysusers 19:19:33 yes, that seems to align with the traditional "Debian way" to me 19:19:37 but my reading of the recent GR result is that the cross-distro systemd interfaces should possibly be preferred 19:20:51 I might be speaking out of turn, but I wanted to point out that the people that make OpenRC also provide a tmpfiles implementation (it is not feature complete, but it covers most things that can actually be used by distro tmpfiles configs): https://github.com/openrc/opentmpfiles 19:20:56 But there isn't one, is there? 19:21:19 dwfreed, yeah, this issue covers both opensysusers and opentmpfiles 19:23:19 marga: not sure I get your question 19:23:35 Sorry... It was just wrong 19:23:56 np :) 19:24:06 I'll re-read the GR before I say more wrong things 19:24:35 just option B :-) 19:25:57 Yeah, yeah, that's what I meant. 19:26:06 there's not much point inflicting the inevitable bugs on our users caused by patching upstream's use of systemd-sysusers to use sysusers which in 99.99% of cases then ends up using systemd-sysusers anyway -- I think that sort of thing is best left to our systemd-intolerant downstreams 19:27:50 It's tricky because this isn't about systemd, but about one of the additional features. But yeah, the GR says that exploring alternatives is supported. So I think we need to find a way that supports this alternative for those that want to "explore" it, without infringing too much pain on normal users. 19:28:35 And yeah, I agree that if everybody else is using systemd-sysusers, it's just going to bring pain if we try to replace that with sysusers everywhere. 19:29:18 But I 100% agree with OdyX that using the alternative system for systemd-foo is wrong. 19:29:42 yes 19:30:31 agreed 19:30:59 So, is there some other option that we haven't considered? 19:31:22 the dpkg-divert thing 19:31:55 Right, that one was mentioned in the thread and I think the main objection was that things could break while it was happening? Or was there something else? 19:33:23 Ah, no, the main objection was "it's really ugly" 19:33:31 also some controversy about whether the running init should affect the behaviour of the diverted sysusers or not 19:33:58 I presume the feature-incompleteness is a problem if one diverts, and then tries to use such features, but if the user is told they can have all the pieces if they insist on doing this to themselves, that seems fine to me 19:34:01 as in "should exec systemd-sysusers anyway if we're running under systemd" 19:34:41 but it seems to me that some iteration of this should be enough to support exploring alternatives 19:34:47 I'm not sure that makes sense, yeah 19:34:55 But that might not be for us to decide. 19:35:39 Yeah, I tend to agree. 19:35:56 The easier way is to make sure these systemd utilities can be installed without systemd. Then Provides/Conflicts/Replaces can "just work". 19:36:56 Right, in the other bug it seems that they will work on making that possible, specifically for containers. 19:37:58 well, except that the people that want this don't seem to want to use those versions of the packages, and probably also object to naming anything in their preferred alternative systemd-anything, so the reasonable thing probably ends up having nobody to use it. 19:38:53 serving use case of containers is good though anyway 19:40:14 Alright... Is there an action item here? The traffic has died down, but we should still act on this... 19:40:34 the specific thing we're asked here is to override the systemd maintainers' rejection to use alternatives for systemd-sysusers 19:41:13 So, we decline to override and suggest they use dpkg-divert instead? 19:41:23 I suspect we have consensus not to override 19:41:30 works for me 19:41:50 Should we vote on this? Or just close as is? 19:42:27 I favour closing (with the option to reopen and vote if anyone objects) 19:43:23 works for me I think 19:44:03 Alright... I guess I'll take this AI, unless someone else feels like taking it? 19:45:15 #action marga to close the bug, declining to override and encouraging dpkg-divert for experimentation purposes 19:45:23 thanks 19:45:33 #topic Recruiting efforts 19:46:10 We've had one nomination come it... I guess we'd need to agree on how we want to proceed with any nominations we receive. 19:46:14 marga: it sounds like you're more likely to have time than me (for the bug closing above), but if you end up suddenly busy, prod me and I'll try to find time to deal with it 19:46:22 fil, thanks! 19:47:03 In the past, we've asked people to answer whether they would be up for joining the TC and then if they said yes, we asked them something... I don't recall what, to be honest 19:48:16 I probably have my version of such a mail somewhere :) 19:49:02 but sure, we should check first if they are willing or not 19:49:07 I guess they were Cc-ed to -private (/me looks ...) 19:50:21 Ok, would any of you be willing to take that AI? At least asking the one nomination we got whether they are interested... 19:50:55 I can do that 19:51:30 #action ntyni to ask the one nominee we got whether they are interested in being considered. 19:51:55 Alright. I think we need more people to discuss more regarding what we want to ask... Maybe makes sense to do this on the ML 19:52:10 #topic Any other business? 19:53:36 I guess not :) 19:53:39 #endmeeting