18:58:27 <marga> #startmeeting
18:58:27 <MeetBot> Meeting started Wed Nov 21 18:58:27 2018 UTC.  The chair is marga. Information about MeetBot at http://wiki.debian.org/MeetBot.
18:58:27 <MeetBot> Useful Commands: #action #agreed #help #info #idea #link #topic.
18:58:42 <marga> Hello everybody, welcome to our October meeting
18:58:49 <marga> #topic Roll call
18:58:51 <OdyX> November :-)
18:58:55 <marga> Margarita Manterola
18:58:56 <OdyX> Didier Raboud
18:59:00 <bremner> David Bremner
18:59:08 <Mithrandir> Tollef Fog Heen
18:59:09 <ntyni> Niko Tyni
18:59:11 <marga> Yes, november... That shows how my mind is working... lol
18:59:39 <gwolf> Gunnar Wolf
19:00:04 <marga> #topic Review of previous meeting's AIs
19:00:48 <marga> For reference, the log is here: http://meetbot.debian.net/debian-ctte/2018/debian-ctte.2018-10-17-19.00.html
19:01:14 <OdyX> Pff. I've had open email drafts for a month.
19:01:20 <bremner> phew. I did all the things I said I would
19:01:33 <marga> Tollef sent out the vote and closed #904302 (vendor specific patches). Yay!
19:01:45 <OdyX> Ah yes, Nice!
19:01:59 <gwolf> yes!
19:02:00 <bremner> there was also action from policy and lintian on that one
19:02:33 <marga> Yes, good that there was progress on all fronts there.
19:02:41 <marga> I had two action items and failed to deliver on both of them (summarize the discussion on #904558 and send mail to d-d-a to encourage nominations)
19:02:44 <smcv> here, sorry for the delay
19:02:49 * smcv Simon McVittie
19:03:11 <Mithrandir> I failed to nominate. Will reaction that.
19:03:22 <marga> Simon did send an email about the whole invoke-rc.d thing, which left me more confused than before on this matter
19:03:37 <OdyX> Same.
19:03:47 <gwolf> I also thought about some possible nominations. Will send to ctte-private.
19:03:51 <marga> I think fil fulfilled his nomination duties during the same meeting, but nothing came out of it.
19:04:04 <marga> Alrigh, I'll re-action this to put it in the list
19:04:20 <marga> #action marga to email d-d-a to encourage self-nominations
19:04:35 <marga> #action Mithrandir, OdyX and gwolf to nominate people
19:04:53 <marga> And let's discuss the other thing under its topic
19:04:55 <OdyX> Ack.
19:05:05 <marga> #topic #904558 What should happen when maintscripts fail to restart a service
19:05:19 <marga> So, I failed to send my part of the summary to the list :-/ Sorry about that.
19:05:35 <marga> Last time we had a lot of discussion but it felt like it was mostly going in circles.
19:05:52 <marga> Does anybody have an opinion on how we can make progress instead of re-hashing the discussion?
19:06:47 <bremner> there was some "technical solution" discussion in mail/bts. Did anyone follow that closely?
19:07:02 <gwolf> Re-reading Sean's original mail... He specifically asks he is "not seeking a decision" but seeking advice
19:07:36 <gwolf> I think this issue could be contentious enough for us to advise him that "there are different viewpoints based on the varied scenarios where Debian is installed"...
19:08:01 <bremner> I think a concensus emerged that whatever the default is, there could be good reasons for exceptions?
19:08:21 <gwolf> bremner: right, that's ± what I was trying to put in words
19:08:28 <OdyX> Not for how to end the discussion, but it became clearer to me that the intermediate ground where Debian is positionned (keeping "offline" track of service status and guaranteeing that this status is guaranteed to be kept accross upgrades), is weird.
19:08:57 <smcv> do you mean keeping "offline" track of what we believe the status ought to be?
19:09:20 <OdyX> And we might want to push in one direction or the other (tighten the service status MORE with dpkg/apt, or LESS so)
19:09:26 <smcv> maintscripts generally use restart, not something equivalent to systemctl try-restart
19:09:52 <smcv> so if we believe the status ought to be "running", but the service has crashed or been stopped or is otherwise not running, the practical result is we start it
19:10:05 <smcv> or try to, at least
19:10:51 <OdyX> Taken from the other viewpoint, it seems to me that _any_ upgrade should leave the affected services in the same status as before.
19:11:16 <OdyX> (thanks captain obvious)
19:11:21 <gwolf> OdyX: I'd love for that to happen
19:11:40 <smcv> in the old arrangement where prerm stopped the service and postinst started it, that wsn't even *implementable*, let alone implemented
19:12:12 <smcv> recent debhelpers default to doing nothing in prerm and restarting in postinst, which at least makes the try-restart behaviour implementable
19:12:23 <OdyX> so either dpkg / apt / maintscripts need to grow better service understanding (bye bye sysvinit anyone?) or get further away and stick to upgrading the binaries, but delegate restart to higher tools.
19:12:36 <OdyX> smcv: which is good.
19:13:09 <smcv> OdyX: to be clear: the old arrangement is good, or recent debhelpers' default is good?
19:13:18 <OdyX> recent…
19:13:27 <smcv> that's what I hoped you meant
19:13:33 <marga> As discussed during last meeting, the tech ctte shouldn't be designing solutions.  I believe we could encourage people to do that, though
19:13:44 <OdyX> Could "service status alteration should really only ever happen after unpack, but exceptions" be a consensus-able position?
19:14:19 <marga> I think so, but that's not really what we are being asked
19:14:22 <gwolf> def exceptions(): anything_goes()
19:14:36 <marga> Like, if the service DID get broken by the upgrade, what should happen then?
19:15:09 <gwolf> Right - he base issue is whether dpkg/apt should die or "just" the service
19:15:26 <gwolf> Of course, once broken, it's up to a human to unbreak it
19:15:53 <Mithrandir> while I think my position is the right one, I think having something consistent is more important than having it one particular way or the other.
19:15:56 <OdyX> I think we also bring value by taking a step back/higher.
19:17:22 <marga> OdyX, what would that be?
19:17:51 <OdyX> marga: I'm saying that as long as we "provide advice", saying "thanks for the apt/dpkg question,
19:18:09 <OdyX> but it triggered larger thoughts that we hereafter share"
19:18:13 <OdyX> is fin.
19:18:19 <OdyX> (sorry for the typos)
19:18:34 <marga> Sure, yes. I guess we can include other thoughts.
19:18:57 <smcv> what Ian seems to be asking for is that we say "here is a thing that should exist, someone please do the detailed design and implementation?"
19:19:02 <marga> I agree with Tollef's comment of consistency is better than no-consistency, but whatever the recommended way, there need to be exceptions anyway.
19:19:24 <Mithrandir> marga: that I also agree with.
19:19:39 <smcv> so... in that spirit, what would be the ideal thing to happen when a service fails to restart?
19:19:43 <gwolf> smcv: right - But that's not the ctte's tasl
19:19:59 <gwolf> smcv: In that case, we have had different valid expectations from different people
19:20:02 <smcv> presumably the answer is "a clear notification"
19:20:16 <marga> I think someone needs to design a notification system
19:20:21 <gwolf> My take is that apt should not get broken if at all possible... But "a clear notification" is hard to define
19:20:24 <marga> That maintscripts and daemons can use
19:20:26 <smcv> and the bug is that we don't have a clear notification mechanism
19:20:32 <gwolf> Right, smcv
19:20:39 <OdyX> Ah, that's a direction I like.
19:20:59 <ntyni> agreed
19:21:00 <gwolf> Of course, we will not require every server to have a libnotify or stuff...
19:21:18 <Mithrandir> where "notification" can also be something that fleet deploy systems hook into?
19:21:41 <smcv> what I absolutely do not want to happen here is that we sit in our ivory tower and design an elaborate Debian-specific notification mechanism, probably based on arbitrary hooks executing shell scripts in whatever.d that randomly escalate and de-escalate privileges,
19:22:01 <OdyX> We kinda roll back to the policy-rc.d toggle: BREAK_APT_ON_FAILED_RESTART = false.
19:22:03 <smcv> and then in 5 years time we expend a lot of effort in removing it in favour of something that can be used in non-Debian
19:22:36 <marga> smcv, is there a non-Debian mechanism out there that could be adopted?
19:23:08 <smcv> (see also: the Debian menu vs. fd.o; doc-base vs. anything else)
19:23:26 <bremner> mostly kidding, but email used to be that mechanism. It doesn't work for many use cases now of course
19:23:33 <smcv> well, a general-purpose event log with metadata springs to mind immediately
19:23:44 <Mithrandir> smcv: since you probably know, is there a concept of system notifications in libnotify?
19:23:45 <smcv> but only one of our supported init systems has it
19:23:50 <smcv> Mithrandir: no there is not
19:23:59 <marga> I mean, I agree wholeheartedly. But I'm not aware of a system like this existing.  We could strongly recommend that such a system be distro-agnostic
19:24:04 <smcv> I mean, I could design a "system notifications" interface in about 10 minutes
19:24:10 <smcv> (for D-Bus, I mean)
19:24:13 <Mithrandir> smcv: would it be welcomed?
19:24:17 <smcv> dunno
19:24:27 <smcv> I suspect the major push back would be
19:24:52 <smcv> from the @1990sLinuxUser side of the community: "but I don't want D-Bus"
19:25:03 <bremner> ack
19:25:24 <gwolf> yup. But people should™ be able to opt out
19:25:26 <OdyX> Could it not be a simpler "concept" just in apt/dpkg?
19:25:33 <gwolf> and get the default behavior :)
19:25:39 <smcv> and from people who like UX design: why are you wasting your time on ways to display notifications that users won't understand or be able to take informed action on anyway
19:25:51 <bremner> smcv: doesn't "the thing" need to notify remotely anyway?
19:25:58 <OdyX> (the resistance of the dpkg maintainer to any advice we would provide is another problem)
19:26:13 <Mithrandir> bremner: we could have an email/remote-thingabob listener that tied into it
19:26:24 <smcv> bremner: not having tried to do any requirements capture on this, I honestly don't know
19:26:51 <bremner> smcv: well, if large fleets of machines / containers aren't an issue, then the discussion would be over by now, I think
19:26:57 <marga> Point of order: we are once again trying to design the thing, which is what we shouldn't do
19:27:32 <bremner> ok, what can we do? say what it needs and what would be nice?
19:28:17 <bremner> and, since currently the magic notification box doesn't exist, is there anything we can advise now?
19:28:27 <marga> It seems that we have consensus on: 1) we need a better notification system in Debian, but it's not up to tech-ctte to design this. We do want someone to do it. 2) maintscripts should have a consistent behavior when possible.
19:28:54 <bremner> agree
19:29:01 <smcv> straw man: the notification system is "bad things cause high-severity messages in the Journal"
19:29:06 <marga> Less clear where the consensus stands: A) maintscripts shouldn't try to start a service that isn't running B) [the actual question] what should maintscripts do when starting a service fails
19:29:18 <smcv> (but then of course sysvinit)
19:29:46 <marga> Should we maybe hold an actual vote for B?
19:30:22 <bremner> "maintscripts should mostly not fail, unless the maintainer has excellent reasons for them doing so"?
19:30:29 <OdyX> And a drafting session with multiple of us?
19:30:48 <marga> OdyX, what do you mean?
19:31:29 <OdyX> I mean collaborative editing to draft 1) and 2) , and probably a ballot for A)/B)
19:31:47 <gwolf> I don't like this...
19:31:58 <gwolf> *Everything* should "mostly not fail"
19:32:23 <marga> gwolf, well, I think this is the part where we need to have a vote because there are different positions
19:32:33 <gwolf> I think it's perfectly valid to say, "we refrain to decide - but we agree that somebody☞☞☞ should work on implementing this"
19:32:42 <gwolf> marga: We keep falling into design work
19:32:50 <bremner> gwolf: I mean, should mostly ignore the failure of services to restart
19:32:57 <bremner> you can still not like it ;)
19:33:02 <gwolf> (-:
19:33:38 <marga> Uhm, I would prefer we decided something...
19:34:01 <gwolf> But back to marga's latest statements... I also feel we have a consensus on A.
19:34:16 <OdyX> to start or restart yes
19:34:38 <gwolf> umh... As I said a bit pre-meeting, I have to elave now
19:34:42 <bremner> where did A come from? just popped out of the discussion
19:34:43 <gwolf> *leave
19:35:01 <gwolf> bremner: Well, because a restart won't fail if it's not attempted :-]
19:35:05 <gwolf> Anyway, have to go now
19:35:07 <gwolf> o/ !
19:35:21 <marga> systemd has try-restart and things that are systemd specific use that, but the non systemd specific just try to start things regardless of current status
19:35:49 <OdyX> I'm fine with recommending that to change.
19:36:00 <marga> And yeah, the context was that if the service was already broken / stopped, it doesn't make sense to break apt/dpkg when trying to start it back up.
19:36:11 <bremner> ok.
19:36:15 <OdyX> service apache2 stop; apt upgrade (apache) ; shouldn't start apache.
19:36:17 <smcv> factual point: even dh_installsystemd currently uses restart
19:36:30 <bremner> I agree A is fine.
19:36:36 <OdyX> because it mimicks sysvinit?
19:36:42 <smcv> *shrug*
19:36:52 <marga> Right, so this would be a change in debhelper and due to how dh_installinit works this needs packages to be rebuilt with the latest debhelper
19:37:33 <smcv> probably at least partly because it would be perverse for a service with a systemd unit and an init script (dh_installinit) and a service with only a systemd unit (dh_installsystemd) to behave differently in this respect
19:37:45 <marga> BTW, I think that last point is broken and should be fixed as well... (copying code instead of calling a function that can be updated outside of the packages)
19:38:13 <OdyX> "someone" could take over lsb :-)
19:38:23 <marga> ...
19:38:36 <marga> Ok, so apparently we have consensus on A and the only controversy is B
19:38:45 <marga> Should we draft a ballot with options for it and vote?
19:39:02 <bremner> sure. we can always FD
19:39:11 <smcv> it would be great if dh_install{init,systemd} were more declarative, yes; now that we have init-system-helpers, we have a natural place to put that sort of thing
19:39:14 <bremner> and we can discuss concrete options
19:40:33 <OdyX> Yes
19:41:01 <marga> Alright... Shall I take this or does someone else want it?
19:41:39 <OdyX> My bandwidth is not what I wish it were.
19:42:25 <bremner> I am also feeling a bit overwhelmed for the rest of the year
19:43:19 <marga> Ok, I'll take this.  Hopefully I won't be too distracted by the magic of spring and sunshine (I'm in the southern hemisphere til end of January)
19:43:43 <OdyX> Cool.
19:44:12 <marga> #action marga to draft a proposal including the parts where we have agreement and ballot options for the parts where we don't.
19:44:21 <marga> #topic #911225 Advice on stale libraries in a higher-precedence path entry
19:44:30 <marga> This is smcv request for comments.
19:44:56 <marga> I re-read it today, and I think that OdyX's suggestion sounds sensible.
19:46:11 <bremner> I just re-read it, and agree
19:46:39 <OdyX> I just re-read it and found myself surprisingly clear :-)
19:46:44 <OdyX> I still agree. .-)
19:47:09 <smcv> it seems reasonable, if rather more complexity cost in the glib package than I was hoping for
19:47:50 <Mithrandir> you're asking for advice, though, so you are free to actually do what you prefer if you like something else.
19:47:56 <OdyX> It's a dozen of dash lines in preinst, but yeah.
19:48:07 <OdyX> smcv: do you want a TC ruling or is my proposal enough of advice?
19:48:16 <smcv> no that's fine as advice
19:48:39 <OdyX> (without a TC advice, you'll be entitled to just blame OdyX :-P )
19:48:40 <bremner> should somebody close the bug with a quick note ?
19:48:43 <smcv> I think we can close that bug, or reassign it to glib2.0 as "ensure stale libraries from jessie get deleted"
19:49:00 <OdyX> smcv would be the best suspect to do this yes.
19:49:05 <smcv> will do
19:49:06 <bremner> ah, reassign makes sense, but can we leave it to you smcv ?
19:49:12 <OdyX> Yay
19:49:17 <ntyni> the suggested logic seems good to me too fwiw
19:49:19 <bremner> redundant bremner is redundant
19:49:49 <marga> Ok, good, we are done with that one!
19:49:56 <marga> #topic Recruiting efforts
19:50:02 <smcv> does anyone see a serious problem with doing it in postinst rather than preinst?
19:50:24 <bremner> smcv: not I
19:50:25 <smcv> that would mean I could use a script/data files from the package rather than having to open-code it in the maintscript
19:51:05 <bremner> smcv: nothing should try to use the lib before the postinst is run?
19:51:07 <OdyX> smcv: feels awkward, but not wrong; you have a good argument.
19:51:52 <smcv> bremner: hmm I suppose if a different maintscript runs a GLib-based program, it might fail
19:52:11 <smcv> and then we're back to "what happens when a maintscript can't run stuff" :-P
19:52:32 <OdyX> :-P
19:52:34 <marga> But those are already broken anyway, right?
19:52:46 <bremner> marga: unless the pre-depend?
19:52:51 <bremner> *they
19:53:03 <marga> #topic #911225 Advice on stale libraries in a higher-precedence path entry
19:53:11 <bremner> dunno, I haven't really thought it though
19:53:16 <smcv> they aren't broken until buster's glib is unpacked, because jessie's and stretch's glib are in the same directory, so stretch's glib wins the version comparison
19:53:20 <marga> I mean, people that have upgraded from Jessie are already broken
19:53:38 <smcv> but buster's glib is in a less favoured directory than those
19:54:08 <smcv> of course the /usr merge would make all this mess entirely irrelevant
19:54:30 <bremner> yes, well, that hasn't reached the TC yet...
19:55:17 <marga> Alright, is that it or do we want to discuss this more?
19:55:17 <OdyX> Yeah; let's not :-)
19:56:16 <bremner> yeah, we gave some advice. It's up to smcv to figure out the details
19:56:23 <marga> #topic Recruiting efforts
19:56:28 <OdyX> or ask for a proper resolution.
19:56:32 <marga> So, we have some action items on this already
19:56:45 <marga> Is there anything else we want to do?
19:57:05 <marga> Maybe ask fil to run his thing until we get at least 2 replies?
19:57:30 <bremner> or fil gets blacklisted
19:58:36 <bremner> I've kindof got to drop out.
19:58:59 <marga> yeah, me too
19:59:05 <OdyX> Same.
19:59:07 <marga> Ok, let's just see how it goes with the current AIs
19:59:10 <marga> Thanks everybody
19:59:14 <marga> #endmeeting