Add February's meeting to the repo

[debian-ctte.git] / meetings / 20190220 / debian-ctte.2019-02-20-18.58.log.txt

18:58:15 <marga> #startmeeting
18:58:15 <MeetBot> Meeting started Wed Feb 20 18:58:15 2019 UTC.  The chair is marga. Information about MeetBot at http://wiki.debian.org/MeetBot.
18:58:15 <MeetBot> Useful Commands: #action #agreed #help #info #idea #link #topic.
18:58:20 <marga> #topic Roll Call
18:58:27 <marga> Who's around?
18:58:28 <OdyX> Didier 'OdyX' Raboud
18:58:30 <fil> Philip Hands
18:58:32 <marga> Margarita Manterola
18:58:53 <Mithrandir> Tollef Fog Heen; not here, since I'm in another meeting. Apologies about the late notice.
18:58:57 <marga> Simon said that he's out on sick leave and David said that he was double-booked.
18:59:27 <ntyni> Niko Tyni
19:00:08 <marga> #topic Review of Previous meetings AIs
19:00:44 <marga> So, I had an AI for drafting a proposal for when maintscripts fail to restart a service, but I've failed to do it :-(
19:01:10 <marga> OdyX instead has carried out his AI and drafted an excellent proposal for the /usr merge issue.
19:01:26 <marga> I guess we should probably switch into that topic :)
19:01:38 <marga> #topic #914897 - should debootstrap disable merged /usr by default?
19:02:36 <marga> I think the current text is great in summarizing the background and the problems.  I was a bit confused about the options at the end.
19:03:17 <marga> Basically I don't see how not overriding debootstrap maintainers implies we want the "hard" outcome.
19:03:35 <OdyX> Fair enough. I had a limited time slot to push it through, so figured I'd spit the options that made sense on the ballot for me, and hoped you lot would comment / suggest / add/remove options :-)
19:05:12 <OdyX> #info A rebuttal and suggestion of a "weaker" path was sent by Guillem on d-devel: https://lists.debian.org/20190219044924.GB21901@gaara.hadrons.org
19:06:44 <OdyX> I understand he's saying that the symlinked "merged-/usr" should not exist, and that the longterm desireable outcome is to move everything to /usr (emptying / and /lib)
19:06:45 <fil> yeah, I had to read it twice, but as I read it it settles on either "yes" or "no", and it seems to make sense that if we don't tell them to stop we'll end up with hard (which strikes me as the right answer anyway, so I'm fine with that)
19:07:35 <OdyX> Should I (or one of us) be adding this "weaker" path on the table / ballot?
19:07:37 <fil> (that was about OdyX's summary BTW)
19:07:41 <marga> Well, I guess I'm also fine with hard, but the "middle" one would also be an ok outcome of not overriding.
19:07:56 <marga> What would the weaker path look like?
19:08:13 <marga> Is it "none"+extra work done to move binaries out of / ?
19:08:29 <OdyX> that's my understanding yes.
19:08:45 <fil> isn't that the "get every maintainer to fix every package, and live with the pain for a decade" option?
19:08:50 <marga> I personally don't see how /bin/sh can just "not exist". Ever.
19:09:35 <OdyX> by making itself a symlink ? It's putting everything in /usr.
19:10:13 <marga> Yeah, but then /bin is not empty, it has symlinks to /usr/bin ?
19:10:34 <OdyX> The important point / agreement I think we converged to is that "merged-/usr" systems _exist_, whether we like it or not.
19:10:43 <OdyX> Either through usrmerge, or recent debootstrap.
19:11:00 <marga> Sure, that's a fact of life.
19:11:05 <fil> yup
19:11:15 <OdyX> That mere fact makes anything "lower" than "weak" an unrealistic option.
19:11:27 <OdyX> (more so, now)
19:12:10 <fil> I concur
19:12:14 <marga> Yeah, I agree
19:12:40 <marga> And I mostly think it will be fine to switch (i.e. I'm not inclined to override the debootstrap change).
19:14:01 <fil> quite, since the reproducible effort didn't reveal that many problematic packages, it seems entirely reasonable to expect those to be fixed in a release
19:14:23 <marga> My remaining concern there is that people building on machines that are not using the buildd variant may introduce packages that break on non-usr-merged systems (either by doing a binary+source upload to Debian, or by having internal/derivative packages)
19:14:26 <ansgar> OdyX: But emptying /bin, /lib and /sbin is impossible...
19:14:41 <ansgar> (re. what you understand as Guillem's proposal)
19:15:00 <OdyX> ansgar: so what did I get wrong?
19:15:10 <marga> However, given the low amount of bugs that was discovered by the reproducible builds project, I think I can live with that concern.
19:15:48 <ansgar> OdyX: I'm not sure what Guillem proposes; his idea of what debhelper could maybe do results in a different layout (where /bin/sh is a symlink to /usr/bin/sh)
19:18:39 <OdyX> hrm. So.
19:18:56 <OdyX> a) do we want that "weaker" option on the explanation email?
19:19:15 <OdyX> b) could we vote on the options, or do you want/need another option?
19:19:31 <marga> We are being asked to either overrule or not.  So I'm fine with two options that represent that.
19:20:19 <ntyni> do we want an FD option for the sake of completeness?
19:20:21 <gwolf> Sorry for lateness... I can finally sit at my desk
19:20:23 <marga> I'm not sure what the desired outcome for bullseye should be. i.e. why "hard" and not "middle"?
19:20:31 * gwolf reads backlog...
19:20:43 <ansgar> ntyni: I think there is always FD according to the rules?
19:20:55 <ntyni> well, it wasn't there on the draft ballot
19:21:34 <OdyX> I'll add FD to make sure its clear.
19:21:50 <ntyni> thanks
19:21:53 <OdyX> marga: "middle" imposes that packages built on either, don't break on either.
19:22:06 <marga> Yeah, and I actually think that's a good idea
19:22:12 <OdyX> #action OdyX to add FD to #914897
19:22:19 <fil> marga: I was under the impression that middle was considered by consensus as a way of maximising the pain, and that either weak or hard was just much less effort
19:22:19 <marga> At least for some transition period
19:22:37 <OdyX> (and that official packages can be built on either, which really feels fragile)
19:23:02 <gwolf> I concur with what I read - I am also not inclined to override debootstrap anymore (at some point, I was)
19:23:25 <ansgar> Ah, different things can be made the default option (which further discussion usually is).  I wonder if that ever happened in Debian.
19:23:52 <gwolf> FWIW I think this has been discussed enough that the next step could be voting...
19:24:04 <marga> Ok. I guess that as long as we are just offering advice, I'm ok with saying we think "hard" is the way to go, and then it might end up that bullseye is still weak or middle.
19:24:53 <ntyni> I'm a bit unclear why 'packages ought to only be built on classical directory schemes' == 'override debootstrap maintainers'
19:25:04 <OdyX> A refinement/expansion on the 3 bullet points of option B could be worthwhile.
19:25:15 <ntyni> given --variant=buildd is not usr-merged
19:25:39 <OdyX> I am also considering just dropping option A, unless someone of us wants to have it above FD.
19:26:45 <marga> I'm not.  As Gunnar said, at some point I thought it might make sense, but I've since changed my mind
19:27:29 <marga> And I agree with Niko's remark. The state for bulleye might well still be "weak".
19:28:23 <gwolf> FWIW I doubt we will ever reach "all". That is, we might reach it asymptotically within the half-life of an iron nucleus :-Þ
19:29:13 <OdyX> I'm still somewhat worried of a later dpkg maintainer vs merged-/usr proponents conflict, basically no matter what option we choos.
19:29:25 <marga> :-/
19:29:26 <OdyX> I don't see a good way to avoid this though :-(
19:29:28 <gwolf> For Buster, "weak" is perfectly acceptable. And for Bullseye, I'd be happy by trying to advance. Now... I don't know how reachable "middle" is.
19:30:08 <gwolf> OdyX: Right. Some conflicts will... probably just erupt no matter how/what we do :-/
19:30:11 <ntyni> I'm not inclined to override debootstrap maintainers either but I'm uneasy with recommending "hard" at this point
19:30:46 <OdyX> We could have two variants of current-B as options.
19:31:09 <ansgar> I don't think there is any disadvantage of buildds to continue non-merged-/usr as long as that is still supported (aka the "weak" option)?
19:31:19 <marga> It seems like that would make sense, given that we seem to have consensus on not overriding the debootstrap change.
19:31:33 <fil> Overriding seems pointless now that we have a mixed population in the wild.  hard seems like the least effort in the long run, but I don't see that as very strongly related to the question of whether we should override or not.
19:31:40 <gwolf> fil++
19:31:44 <ntyni> yes
19:31:52 <OdyX> The point is  that if we do not override, buster _stable_ users who setup using debootstrap will constitute a _large_ cohort of users who will _have_ to either be very careful when building locally, or only build in chroots.
19:32:26 <gwolf> OdyX: So we will have to request Release Notes to include some bits on this...
19:32:40 <OdyX> suggest, but yes :-)
19:32:50 <ansgar> gwolf: You can use my bug from a few years ago for it ;-)
19:32:59 <OdyX> There's no good way to "un-merge" currently.
19:33:27 <gwolf> Not that I'm downplaying the importance of supporting downstream distributions - But I think it's acceptable for us to announce loudly enough that if you are building for a large userbase you should set up your build machines as $foo
19:33:41 <gwolf> OdyX: no, no way to unmerge.
19:33:59 <gwolf> ansgar: We should look at it, of course :) Sorry if I lack the context right now.
19:34:46 <ansgar> gwolf: I filed a bug against release-notes about usrmerge two years ago.
19:35:00 <ansgar> (Before it was reverted for Stretch)
19:35:05 <gwolf> Perfect timing! 😉
19:35:32 <marga> Ok, we seem to have stalled. OdyX do you think it makes sense to replace the current Option A, with a non-overriding "weak" outcome?
19:36:35 <OdyX> I'm likely to vote current-B, but would welcome any other option.
19:36:44 <OdyX> I am not going to push it :-)
19:37:23 <marga> Ok, does someone want to submit it as an amendment?
19:38:13 <ntyni> I suppose I should try but not sure how soon I can get to that
19:38:34 <marga> OdyX intended for the voting to start on Friday
19:38:42 <OdyX> well. Let me not be stubborn. I'll rephrase the ballot with the two options.
19:39:02 <ntyni> thanks
19:39:04 <gwolf> I'm happy with the ballot as it is. Maybe just specify as an extra bullet in B."Given that", «For effective purposes, we are already in "weak"»
19:39:44 <marga> #action OdyX to replace the current option A with a non-overriding version, given that there seems to be consensus for not overriding
19:39:52 <gwolf> ppl, as I said earlier (before my network issue erupted and made me be late for the meeting)... I have to leave at :45, so will soon depart.
19:39:55 <OdyX> I'm not really happy with the bullets, and will completely remove them.
19:40:05 <gwolf> OK
19:40:05 <marga> Alright, let's move on to dune...
19:40:24 <gwolf> In the 3 minutes of discussion I'll be on this...
19:40:31 <marga> #topic #919951 ocaml builder must not be called `dune' or provide /usr/bin/dune
19:41:03 <fil> they seem to have sorted it out amongst themselves, have they not?
19:41:15 <gwolf> I understand Dune's situation is basically settled, right? AIUI we should basically acknowledge the ocaml builder is allowed to use the name
19:42:43 <marga> Right, then someone needs to close the bug as "No resolution needed"
19:42:49 <ansgar> fil: It came only to the ctte as some people ignored 6.3.6...
19:42:57 <gwolf> I can do it - #action me
19:43:03 <marga> k, tnx
19:43:08 <gwolf> I will now leave. kthxbye!
19:43:09 <ansgar> marga: AFAIU the ctte used to close all things with a resolution?
19:43:10 <OdyX> ansgar: are you asking us to remind these people ? :->
19:43:23 <marga> #action gwolf to close as no resolution needed.
19:43:43 <marga> We resolve not to resolve or something like that, we've done this in the past :)
19:43:53 <fil> (while I sympathise with Ian's urge to slap their wrists for their foolishness, or some such, given that everyone actually involved seems to be happy, they should probably be allowed to get away with it)
19:44:08 <OdyX> ansgar: nah, we have declined to do so some times in the recent years, saying "we agree it needs no resolution, but if you want us to go through a formal vote, we will)
19:44:10 <ansgar> OdyX: A friendly reminder.  But closing it as "This doesn't need a resolution; please talk to people first" or so.
19:44:56 <ansgar> But only because I found it very frustrating (I happen to both maintain the dune-* packages in Debian and upstream too...)
19:45:22 <ansgar> (The C++ library one.)
19:45:34 <marga> Alright, let's move on to the bug that's still open because of my failure to act
19:45:35 <marga> #topic #904558 What should happen when maintscripts fail to restart a service
19:45:55 <marga> So, my AI last time was to "draft a proposal including the parts where we have agreement and ballot options for the parts where we don't."
19:46:00 <marga> And I failed to do this.
19:46:01 <OdyX> gaah. That one is _HARD_
19:46:31 <OdyX> Everytime I chat about it with Debian-familiar people, I get different opinions.
19:46:40 <ansgar> OdyX: Maintainer scripts must never fail; just as Apple computers must never crash as that would inconvinience the user :)
19:47:11 <marga> I can take the AI yet again, but I'm happy to let someone else take it instead
19:49:11 <fil> If I had a clear idea about which bits where we have agreement, I'd be OK with doing it, but I've lost track a bit -- I can do some reading, and am certainly happy to do a collaborative effort
19:49:44 <marga> Yeah, I also don't remember by now, I was planning on reading the Meetbot logs and re-reading was sent to the mailing list
19:50:24 <marga> fil, can you try to get that started and ping me to collaborate with you?
19:50:32 <fil> sure :-)
19:50:57 <marga> #action fil and marga to collaborate on drafting a proposal including the parts where we have agreement and ballot options for the parts where we don't.
19:51:42 <marga> Ok, then the last one is Simon's bug about library precedence, which has been silent since October
19:51:54 <marga> We agreed already that this should be closed
19:52:18 <marga> #topic #911225: Advice on stale libraries in a higher-precedence path entry
19:52:39 <marga> The problem is that we don't have a procedure for closing a bug opened by a TC member :)
19:53:44 <marga> I guess I'll action myself here and get this closed.
19:54:13 <marga> #action marga to close this one as there doesn't seem to be any more actionable items for us.
19:54:27 <marga> #topic Any other business?
19:56:15 <fil> nothing from me -- do we have a timeout?
19:56:23 <OdyX> 1h usually
19:56:31 <marga> I guess we are done :)
19:56:35 <marga> #endmeeting