18:59:13 <spwhitton> #startmeeting
18:59:13 <MeetBot> Meeting started Tue Mar  8 18:59:13 2022 UTC.  The chair is spwhitton. Information about MeetBot at http://wiki.debian.org/MeetBot.
18:59:13 <MeetBot> Useful Commands: #action #agreed #help #info #idea #link #topic.
18:59:15 <spwhitton> #topic Roll Call
18:59:17 <spwhitton> Sean Whitton
18:59:19 <ehashman> Elana Hashman
18:59:21 <gwolf> Gunnar Wolf
18:59:24 <ntyni> Niko Tyni
18:59:27 <smcv> Simon McVittie
19:00:36 <helmut> Helmut Grohne
19:00:42 <spwhitton> Myon: others can hear me
19:01:10 <ehashman> oh, are we on jitsi?
19:01:25 <gwolf> ehashman: we are
19:02:22 <smcv> please could someone privmsg me the link? or just say it here if public
19:02:36 <Emperor> Matthew Vernon
19:02:41 <spwhitton> smcv: https://jitsi.debian.social/TechnicalCommittee
19:06:39 <spwhitton> #topic Review of previous meeting AIs
19:06:45 <Myon> Christoph Berg
19:06:50 <spwhitton> thanks helmut for sending your message.  I don't think you got a reply right?
19:07:05 <helmut> spwhitton: I confirm.
19:07:20 <spwhitton> ehashman: I was to follow up with you, now, about the private comms text
19:07:30 <spwhitton> ehashman: are you still up for getting that committed to git?
19:07:34 <ehashman> ah I knew I forgot something
19:07:36 <Myon> sorry for not sending mine, I didn't realize the "is the submitter still interested" part is interesting
19:07:38 <ehashman> yes but not this month
19:07:48 <Myon> but they replied somewhere around the end of the thread I think
19:07:54 <ehashman> and sorry for falling off the face of the earth the last ~6wks
19:08:19 <ehashman> I took some vacation and had a (minor) surgery and I have not been very with it :)
19:08:51 <spwhitton> ehashman: that's fine.  glad you are recovering.
19:09:06 <ehashman> (when I realized I failed to vote in the chair election I felt awful. apparently I hadn't checked my Debian email in 3 weeks)
19:09:25 <spwhitton> The task is to convert the private comms text from the slides, plus any feedback from the gobby/whatever notes, and put it under procedures/.
19:09:43 <ehashman> yeah, can carry forward
19:09:44 <gwolf> ehashman: It's always a priority to take care of your health over whatever is burning in Debian... Even more so if there are seven from us to take the load.
19:09:56 <spwhitton> ehashman: okay, but you said next month, right?
19:10:01 <gwolf> So I'd like you to retroactively feel better ;-)
19:10:06 <ehashman> gwolf: thank you!
19:10:30 <ehashman> spwhitton: I anticipate I might even be able to get it done today
19:10:49 <ehashman> not to overpromise and underdeliver :D
19:11:05 <spwhitton> ah okay then, I will reaction you
19:11:18 <spwhitton> #action ehashman to commit private-comms slides+gobby to git procedures/
19:11:42 <spwhitton> thanks.
19:11:43 <spwhitton> let's figure out what we want to do with the other bug in next topic.
19:11:56 <spwhitton> #topic Bug#1003653: Revision of removal of rename.ul from package util-linux
19:12:14 <spwhitton> not clear we are any further than last month with lack of input from zeha.
19:12:33 <spwhitton> we could just ping him?  or is there greater urgency?
19:12:35 <Emperor> they've been active on mailing lists (if I'm reading https://contributors.debian.org/contributor/zeha/ correctly)
19:12:50 <helmut> well. if zeha is silent, the default is to not take his opinion into account, right?
19:13:07 <Emperor> The TC is sometimes criticised for taking too long; I'm inclined to think we shouldn't wait indefinitely for zeha to respond
19:13:07 <helmut> on the other hand, we totally lack the urgency input from the submitter
19:13:28 <spwhitton> we could decide that we ping and set a time limit for it.
19:13:37 <spwhitton> no pings at all seems a bit unfair.
19:13:54 <Emperor> spwhitton: I think we pinged him after the last meeting?
19:14:05 <ntyni> hmm util-linux 2.38~rc1-1 "Introduce util-linux-extra binary package with Priority: standard, which I expect to move a number of programs from util-linux to in the future. For upgrade considerations, this is pseudo-Essential."
19:14:05 <helmut> Myon: why did you decide that outside-$PATH was not a relevant option?
19:14:17 <Emperor> there was an action for helmut
19:14:38 <Myon> helmut: because it doesn't solve the problem
19:14:46 <spwhitton> Emperor: helmut wrote his message with a number of questions since last meeting and we haven't pinged aobut that in particular.
19:14:54 <Myon> if people need to put in symlinks, they might as well copy that binary around
19:14:57 <helmut> Myon: I think it does.
19:15:20 <helmut> Myon: modifying $PATH is a very simple and common thing to do. e.g. /usr/lib/ccache
19:15:36 <Myon> it asking that question enough, without providing more context on why we are asking it?
19:15:58 <Myon> ccache is a command wrapper, rename is a plain program
19:16:15 <Emperor> ntyni: AFAICS that doesn't contain rename?
19:16:26 <Myon> frankly, my main question is, do we think that program is important enough so we should care?
19:16:30 <helmut> I think we have essentially consensus that the name rename is to be reserved to the perl API. Do you agree with this sentiment?
19:16:55 <Myon> yes
19:16:57 <gwolf> yes
19:17:03 <helmut> assuming that consensus, we cannot put u-l's rename on the default $PATH in any binary package.
19:17:12 <spwhitton> helmut: unless it's called rename.ul.
19:17:18 <Emperor> I _thought_ we were broadly of the view that u-l rename should be on $PATH under another name e.g. rename.ul
19:17:25 <Myon> which we also kind of agreed on
19:17:37 <helmut> we can only rename it or put it elsewhere.
19:18:02 <helmut> I believe that the people who want to use it want to use it by the name "rename" as it is available by that name on other distributions
19:18:25 <helmut> this renaming means you get to put up symlinks. putting it outside $PATH clearly seems better to me, but I may be biased here
19:18:26 <spwhitton> Looking at helmut's message, we thought that zeha isn't happy about calling it rename.ul.
19:18:26 <Myon> helmut: no, they have been using it as "rename.ul" for decade
19:18:27 <Emperor> Could we agree on "src: util-linux should have a binary package that ships rename.ul somewhere on $PATH under a suitable name?"
19:18:27 <ntyni> Emperor: indeed not
19:18:31 <Myon> renaming was not part of the bug
19:18:35 <ntyni> (re util-linux-extra)
19:19:02 <Myon> Emperor: I like the wording
19:19:08 <spwhitton> Emperor: surely if we are going to say that then we should also mandate 'rename.ul' be the name, otherwise it's disruptive to existing usage.
19:19:13 <helmut> Emperor: I would not agree to that at this point
19:19:42 <helmut> does any one have data on the rename.ul name used by other non-debian distributions?
19:19:48 <gwolf> I agree the name should _not_ be simply rename
19:19:52 <spwhitton> helmut: it's just 'rename' isn't it?
19:20:08 <gwolf> I don't think it MUST be rename.ul, but it can be changed to something different
19:20:10 <Emperor> it was rename.ul before it got removed. In RH it's "rename"
19:20:12 <smcv> having a different name in the PATH seems better than having the same name off-PATH, given that the CLI is sufficiently different that I don't think there's any non-trivial invocation that would be valid for both (ignoring stuff like --help)
19:20:30 <helmut> I think if it isn't "rename", it defeats the purpose intended by the submitter
19:20:43 <Emperor> So I agree with spwhitton that we should keep calling it rename.ul
19:20:48 <Emperor> helmut: I think you misread the submitter
19:20:49 <gwolf> it will remain incompatible with the name used in other distros, but we agreeed already it is not a candidate for using alternatives or anything like that
19:20:56 <Myon> the bug asks to restore the buster state
19:21:10 <Emperor> "I kindly request the technical committee to revise the removal of rename.ul from the package util-linux, hoping that this removal will be reversed."
19:21:34 <Emperor> [they don't ask us to revisit the "rename.ul is inappropriate as an alternatives for rename" decision]
19:22:00 <spwhitton> and they don't say it's a problem if it becomes non-essential
19:22:10 <Emperor> So I think "src: util-linux should have a binary package that ships rename.ul somewhere on $PATH" satisfies the submitter
19:22:30 <Emperor> And, IMO, seems like the right answer here.
19:22:31 <spwhitton> Yes, and we probably have a ctte majority in favour of that.
19:22:52 <spwhitton> But I think we should be more sure that the maintainer actually disagrees with that majority before we consider a ruling.
19:22:53 <helmut> hmm. I'm not sure I find that useful. however I do see consensus on three points: 1) u-l rename should not be called "rename" on $PATH 2) u-l rename should be shipped in some package as some name 3) u-l rename should not be essential
19:23:00 <Myon> on the idea, not necessarily on the question if that warrants overruling
19:23:25 <spwhitton> helmut: good, yes, there is agreement on all of those.
19:23:45 <Myon> 3) does not have to be essential
19:24:04 <Emperor> suggest we put exactly that proposal to the maintainer, and if they ignore us until our next meeting consider an override?
19:24:06 <smcv> have people seen Phil's mail to the bug?
19:24:09 <helmut> I concur with Myon's weaker version of 3)
19:24:26 <Myon> zeha might just put it back
19:24:42 <Myon> we should just drop 3), it's overly specific
19:24:46 <Emperor> smcv: it's a sensible suggestion, certainly. Not sure if that's drifting out of our remit
19:25:14 <helmut> do we need any more input or can we do a ruling on my points 1) + 2)?
19:25:29 <Emperor> I do think we should be asking for it to be called rename.ul in Debian, given that's what it was called before it was dropped (so our users will expect it there)
19:25:31 <spwhitton> helmut: let's not rule if the maintainer already agrees on (1) and (2).
19:25:35 <gwolf> 1 and 2 are uncontroversial for all of us, AIUI
19:25:49 <helmut> but 1+2 also resolve the submitters need, no?
19:26:14 <ntyni> not by my reading if it's going to be something else than rename.ul
19:26:21 <Emperor> ntyni: +1
19:26:30 <helmut> can we reconfirm that with the submitter?
19:26:54 <spwhitton> We can certainly ask more of the submitter but probably shouldn't block on that ,as they haven't been very responsive in general.
19:26:56 <Emperor> helmut: do you think it should be called something other than rename.ul?
19:27:20 <Emperor> (likewise, do you think whatever it is called should be on $PATH? it's not clear from your 1+2)
19:27:26 <spwhitton> Emperor: I think we should do as you suggest -- it's a follow-up to what helmut wrote, but not just a ping, so it's a nice way to obtain momentum without rushing the maintainer.
19:27:33 <helmut> Emperor: yes. I think that u-l's rename is most useful when it can be used exactly the same way it can be on other distributions.
19:28:05 <Myon> yes but that's not our decision
19:28:05 <Emperor> helmut: right, so we have a point of disagreement here, then.
19:28:32 <gwolf> helmut: But given Perl's rename, we _cannot_ have it the same way as other distributions
19:28:35 <helmut> so 1+2 may be sufficient for the submitter (or not), 1+2 are vaguely agreed by zeha. we have consensus on 1+2
19:28:47 <Emperor> I think "rename" on $PATH in Debian has to be the perl version because Debian (and derivitives) have had is thus for ages
19:28:53 <gwolf> If rename.ul is ugly, it could be renamed to changename or whatever... but _not_ to rename
19:28:54 <helmut> gwolf: you can change your script environment by changing $PATH
19:29:06 <gwolf> of course. And you can also set aliases or whatnot.
19:29:32 <helmut> I don't think we have to specify how rename is reintroduced.
19:29:58 <helmut> all we want to say is that the rename name on $PATH is reserved for the perl rename api
19:30:00 <Myon> .oO(as a downloader package that installs util-linux_buster.deb)
19:30:08 <Emperor> I think we should, though. And principle of least surprise argues for rename.ul ; and if the maintainer also wants to ship something like /usr/lib/util-linux/rename as well as a symlink fine
19:30:33 <helmut> rename.ul only makes sense to me, if going phil's route
19:30:39 <Myon> Emperor: ack
19:30:40 <spwhitton> helmut: that's fair, but I think a lot of people would disprefer that solution.  we do not have to be so tightly bound to the firs tmessage in the bug.
19:30:57 <Emperor> In particular, the bug was at least partly "Debian used to have rename.ul on $PATH, can we have that back?", and I think that's a good state to aim for.
19:31:01 <smcv> rename.ul is, at this point, *also* API
19:31:08 <Emperor> +1
19:31:44 <smcv> I'm not saying it's a *good* API, and if we had a time machine and could go back to 1998 or whatever, I'd be asking for something different - but we don't get to make that decision in 2022
19:31:46 <helmut> probably, the best ting would be rename.ul + $non_PATH/rename
19:32:02 <spwhitton> How about we write to the maintainer, ccing bug, saying "we have these two solutions supported by at least one ctte member, do you support either or both, if we don't hear from you we will consider voting for it"
19:32:59 <helmut> yes, but maybe also as the submitter about that?
19:33:14 <ntyni> if zeha wants to only ship /usr/lib/util-linux/rename or whatever then anybody else could make a binary package shipping the rename.ul symlink (even if that's a bit messy)
19:33:39 <Emperor> ntyni: I think that's a less good outcome, and I'd be reluctant to settle for that absent a convincing rationale from zeha
19:33:47 <ntyni> sure
19:33:50 <spwhitton> helmut: we can CC the submitter on that message.  or do you want to ask something specific of them?
19:33:52 <helmut> I suppose zeha would go with rename.ul :)
19:34:43 <helmut> spwhitton: I would specifically ask whether the proposed solutions "rename rename" and "move rename out of $PATH" both solve their problem.
19:35:18 <helmut> the former seems implicitly true as they asked for that
19:35:19 <Emperor> helmut: do you not think their problem as stated is "I want rename.ul to exist again"?
19:35:55 <spwhitton> okay.  we can do both these things.  but I suggest we tentatively agree that we do not block on hearing from submitter again.
19:36:05 <spwhitton> anyone disagree with me on that?
19:36:11 <Emperor> The submitter of #1003653 is not the person who asked for it to be in alternatives
19:36:21 <Emperor> spwhitton: placet
19:36:31 <Emperor> [err, means "OK with me", sorry for stupid jargon]
19:36:38 <helmut> I also suggest using a deadline for zeha
19:36:41 <Myon> spwhitton: ack
19:36:57 <spwhitton> yes.  shall I action myself to write and send that message?
19:37:10 <Emperor> helmut: deadline> before next cttee meeting? :)
19:37:13 <spwhitton> I will say "we will consider voting if we don't hear back by netx meeting" which is effectively a deadline but a gentle one.
19:37:17 <Emperor> spwhitton: well volunteered :)
19:37:35 <smcv> spwhitton: I like that phrasing
19:38:05 <spwhitton> #action spwhitton to write to maintainer with two resolutions which have ctte support, inc. gentle deadline
19:38:08 <gwolf> Sorry, I'll have to leave the meeting now
19:38:16 <spwhitton> helmut: would you like to write to the submitter, then?
19:38:17 <gwolf> Time to go fetch the kids from school...
19:38:24 <ehashman> o/
19:38:29 <spwhitton> bye gwolf!
19:38:33 <Emperor> gwolf: ~~~
19:38:37 <gwolf> o/ !
19:38:58 <Emperor> [in WMF-land o/ means "I have a question or point to raise"]
19:39:14 <helmut> spwhitton: I fear I'm not representing consenus on this issue anymore and would therefore like not to
19:39:14 <ehashman> I'm waving, not raising my hand :)
19:39:45 <smcv> spwhitton: would you mind writing to both submitter and maintainer? I think it would make most sense for both to come from the same one of us
19:39:46 <spwhitton> helmut: okay, cool, well, you can always do it anyway and if submitter does reply we will all read it and it will be useful.
19:40:00 <smcv> either one message or two separate messages
19:40:11 <spwhitton> I am happy to address the message to both of them, but make the deadline bit specific to zeha.
19:40:15 <spwhitton> that okay?
19:40:22 <Emperor> +1
19:40:22 <ntyni> sounds good
19:40:41 <smcv> +1
19:40:47 <spwhitton> #action spwhitton will also address submitter in his message.
19:40:48 <helmut> +1
19:40:54 <ehashman> sgtm
19:40:59 <spwhitton> okay then I think we are done iwth this topic for today
19:41:02 <spwhitton> #topic Any Other Business
19:41:22 <Emperor> [nothing from me]
19:42:16 <Myon> from me neither
19:42:47 <ntyni> likewise
19:42:56 <smcv> likewise
19:43:13 <spwhitton> #endmeeting