19:00:02 <spwhitton> #startmeeting
19:00:02 <MeetBot> Meeting started Tue Feb  8 19:00:02 2022 UTC.  The chair is spwhitton. Information about MeetBot at http://wiki.debian.org/MeetBot.
19:00:02 <MeetBot> Useful Commands: #action #agreed #help #info #idea #link #topic.
19:00:13 <spwhitton> #topic Roll Call
19:00:15 <spwhitton> Sean Whitton
19:00:25 <spwhitton> #link https://jitsi.debian.social/TechnicalCommittee
19:01:01 <Myon> Christoph Berg
19:01:02 <spwhitton> Apologies received from Matthew Vernon
19:01:04 <helmut> Helmut Grohne
19:01:16 <ntyni> Niko Tyni
19:08:56 <gwolf> Gunnar Wolf -- late, but connecting :-)
19:13:13 <spwhitton> #topic Review of previous meeting AIs
19:13:31 <spwhitton> I did mine and nothing more to say.  Myon did his and we will discuss in next agenda item.
19:13:41 <spwhitton> I wanted to raise an AI that we accidentally dropped from December
19:14:09 <spwhitton> "ehashman to commit final version of private communication to tech-ctte.git procedures/"
19:14:37 <ntyni> (where are ehashman and smcv )
19:14:37 <spwhitton> That's the last part of our "improve the TC" project that we did over past 1.5 yrs
19:14:55 <spwhitton> ntyni: haven't heard from them
19:15:15 <ntyni> right
19:15:22 <spwhitton> Elana was going to do it because she presented on it at debconf and the text in the slides was written by her.
19:15:32 <Myon> we should ask her if she could still do that
19:15:42 <spwhitton> Yeah, we could just leave it until the next meeting she is present.
19:15:48 <gwolf> FWIW, the meeting schedule was finalized a bit late, maybe they were not able to join...
19:16:18 <spwhitton> Okay then, I'll action myself to ask her about it next meeting I guess?
19:16:26 <ntyni> sounds good
19:16:37 <gwolf> a bad thing about the dudle-mandated meetings is that... since we filled the date availability, without having fixed schedules, it's hard to reserve the slots as availabel
19:16:38 <Myon> or perhaps before the next meeting ;)
19:17:13 <spwhitton> Myon: she'll see the minutes, so I was more thinking about a backstop.
19:17:23 <Myon> ack
19:17:31 <spwhitton> #action spwhitton to ask ehashman about status of private comms text next meeting
19:17:41 <spwhitton> #topic Bug#1003653: Revision of removal of rename.ul from package util-linux
19:18:07 <spwhitton> hopefully everyone is up-to-date.  myon's most recent mail matches my understanding of the situation.
19:18:10 <helmut> I'm in contact with zeha on that and I think I understand his pov quite well at this point.
19:18:26 <Myon> I accidentally sent the last mail to that bug before I had read the latest sub-thread, but I think the question was still the correct one
19:18:44 <spwhitton> helmut: can you explain why he is less keen than everyone else on just adding rename.ul back somewhere?
19:18:46 <helmut> He takes issue with rename.ul in $PATH, because it is something non-standard and doesn't really make sense to embrace.
19:19:06 <Myon> understandable, but that binary has been there forever
19:19:10 <ntyni> seems to me all other options are worse
19:19:16 <helmut> He also is very much opposed to shipping readname.ul in essential and I share that view.
19:19:26 <gwolf> Right, I haven't spoken in the thread, but this matches my sentiment
19:19:26 <Myon> it's probably less bad if it's in a separate package
19:19:30 <ntyni> yeah it makes no sense in essential
19:19:33 <helmut> I proposed shipping rename in a /usr/libexec path that can be added to $PATH
19:19:39 <spwhitton> yeah hence "linuxextrautils" or whatever
19:20:06 <spwhitton> I don't recall zeha saying he was fine with that though -- else we'd be done.
19:20:16 <Myon> non-PATH binaries seem like a non-Debian-typical solution
19:20:25 <helmut> I do think that we can work out a solution with zeha (without a ctte ruling) such that util-linux rename binary is included in some binary package somewhere.
19:20:37 <gwolf> spwhitton: right. Although we could end up having so many mini-extra-utils packages. But it makes sense to get it out of the essential set FWIW
19:20:55 <Myon> yeah I also had the feeling he wants to get it resolved some way
19:21:11 <Myon> he even commented on the TC bug before I got around to ask him to do that
19:21:15 <spwhitton> Myon: libexec> and perhaps not fhs compliant
19:21:35 <Myon> libexec is FHS I think, just Debian isn't using it
19:21:40 <spwhitton> vvverlrgfcrifbvedguifvtjnnjtgrijvngulikcnlfg
19:21:45 <spwhitton> vvverlrgfcrivedlejifjvubcetfcnbvllfncrcvihtf
19:21:49 <spwhitton> ccccccrjlgikguglgfrvcinekflggkjhdtncnkhdcgtb
19:21:56 <gwolf> that sounds like your yubikey talking..?
19:22:00 <Myon> yubi key or rot13?
19:22:03 <spwhitton> sorry.
19:22:07 <ntyni> or a cat walking on the keyboard?
19:22:14 <gwolf> a very  disciplined cat!
19:22:20 <ntyni> heh
19:22:36 <spwhitton> Myon: it's fhs for programs used by other installed programs, not utils for user scripts
19:22:42 <helmut> I think we're getting into details here. There already is basic agreement with zeha to get rename back $somewhere.
19:22:55 <Myon> spwhitton: right, I misunderstood you
19:22:55 <gwolf> Anyway -- I think this problem will end up unwinding itself even without our "formal" involvement
19:23:12 <helmut> in the past, I've been of the opinion that the ctte is acting too slowly. I am wondering whether we can speed this up:
19:23:25 <gwolf> I think that, given zeha is OK with following through, we can end up not ruling about it, which is the best IMO
19:23:31 <Myon> let's see how it goes and postpone any ruling to next meeting
19:23:34 <helmut> if we get a confirmation of intent from zeha to put rename back, can we then wind down the bug and decline to overrule?
19:23:34 <spwhitton> helmut: the PATH issues matters, from a Policy POV
19:23:58 <spwhitton> has he said publically about the PATH thing or is that based on your conversations?
19:24:14 <gwolf> spwhitton: In this regard, I think we are lucky to have you on the ctte -- that is, for suggesting policy issues, and possibly, to help hint ftp-masters to accept the potential NEW package
19:24:34 <helmut> spwhitton: putting it outside $PATH was a private reply of mine in an answer to his reluctance to use the rename.ul name.
19:24:39 <spwhitton> gwolf: :)
19:24:48 <spwhitton> helmut: ah, and did he reply to that?
19:24:57 <Myon> another thought I wanted to drop: perhaps abusing alternatives is actually better than abusing other mechanisms, so this might actally work since the situation isn't nice to start with
19:25:00 <helmut> in any case, I consider that details. if we have an intent to put it back somewhere, isn't that enough?
19:25:06 <helmut> spwhitton: sleeping.
19:25:41 <spwhitton> helmut: I don't think that's just details tbh.  if it goes to a non-PATH place in another binary package, then we potentially just get another TC bug asking for it to be moved back into PATH.
19:25:57 <spwhitton> (not suggesting zeha would do that.  or that the second bug is guaranteed.  just that we can preempt at least somewhat)
19:26:19 <helmut> spwhitton: would we really want to mandate the other implementation in $PATH?
19:26:54 <spwhitton> I'm not sure.  We should perhaps ask people like the original submitter?
19:26:55 <Myon> it's been in PATH forever, and people are expecting it there, as rename.ul (as weird as that name is)
19:27:04 <gwolf> Now, I understand the suffix '.ul' means 'from the util-linux package'
19:27:35 <ntyni> yeah the suffix dates back to when it was briefly managed with alternatives
19:27:41 <gwolf> should it remain with that suffix? Policy does not like using language-specific suffixes (which this is not, granted,but... sounds like it were :-/ )
19:27:59 <Myon> ntyni: how was it called before alternatives?
19:28:10 <Myon> given the perl rename was also there?
19:28:17 <ntyni> not sure, I suspect it wasn't installed at alla
19:28:19 <ntyni> -a
19:28:19 <spwhitton> gwolf: the suffix seems way less bad than the various other possible abuses on the table.
19:28:24 <helmut> do we have to decide about that instead of leaving it at the discretion of zeha?
19:28:27 <gwolf> spwhitton: point.
19:28:36 <spwhitton> helmut: I don't know.
19:28:45 <Myon> helmut: we don't have to, we can just wait for it to resolve itself
19:29:03 <gwolf> helmut: I'd say we don't need to come up with a detailed solution, but maybe point it out
19:29:06 <spwhitton> I think we should get zeha to confirm he is okay putting it in another package, and ask where he wants to install it, and ask the original submitter what they think about it not being on PATH.  And mention the FHS issue.
19:29:11 <Myon> unless we see it's moving in a bad direction (to be determined what that means)
19:29:36 <helmut> as far as I understand the bug, there are two major issues: 1) get back the rename.ul binary somewhere 2) make it easy to resolve rename in $PATH as util-linux' rename.
19:30:16 <helmut> we basically agree that 1) yes, it should be put back somehwere (and that includes zeha) 2) we have rough consensus that u-a is the wrong tool for that job
19:30:32 <gwolf> u-l, I guess you mean?
19:30:32 <Myon> it wasn't my impression anyone is asking for it to be called "rename"
19:30:41 <helmut> gwolf: update-alternatives
19:30:46 <gwolf> oh, right
19:30:46 <ntyni> we were only asked about 1) and I don't think we agree that 2) is a goal
19:31:01 <gwolf> (sorry for my word ordering that disregards English grammar...)
19:31:02 <Myon> I think we already ruled out the "ideal" solution isn't going to happen because compat
19:31:13 <spwhitton> yeah.  I was thinking that find/replace rename->rename.ul was what we were expecting peple to do.
19:31:55 <Myon> if people want it under other names, we can publish a "rename" command so they can rename it :D
19:31:59 <helmut> so if we agree to not change the rename api, we effectively delcine to overrule zeha. and if he agrees to get it back somewhere, there is nothing else to resolve right?
19:32:14 <spwhitton> helmut: the issue of whether or not it is on PATH remains.
19:32:48 <helmut> spwhitton: I'm of the opinion that this does not have to be decided. zeha can come up with a solution and discuss it with the submitter
19:33:01 <spwhitton> how about we just ask zeha "I understand you are happy to put it back in a non-essetial package, great, can you say exactly how you are going to put it back, i.e. on PATH or not on PATH?"
19:33:08 <Myon> imho if we decide rename.ul should be put back, it has to be in PATH, or else people could just wget it or use oder workarounds
19:33:45 <gwolf> i.e. mailman ships binaries in /usr/lib/mailman/bin, symlinked from /usr/sbin
19:33:59 <Myon> gwolf: that counts as "in PATH"
19:34:21 <gwolf> right -- but I was starting to look into where the /usr/sbin symlink is created
19:34:54 <gwolf> I am almost sure at some point in the past it was not in the path...
19:35:10 <ntyni> I also personally think it should stay in PATH as rename.ul but I'm not sure we as ctte need or should mandate that at this point
19:35:22 <helmut> why do you think that we have to resolve more details than we've been asked to resolve?
19:35:29 <Myon> let's hear first what zeha is saying
19:35:44 <gwolf> But I agree with spwhitton -- explicitly asking zeha how he plans to resolve it, whether in the path or not
19:36:00 <spwhitton> helmut: I'm thinking that teh PATH thing is /possibly/ implicit in the original submitter's request.
19:36:18 <helmut> spwhitton: given that I disagree on that, maybe we should reconfirm with the submitter.
19:36:37 <spwhitton> helmut: before asking zeha what he intends to do?  or perhaps in parallel?
19:36:42 <helmut> parallel
19:36:47 <spwhitton> okay cool.
19:37:02 <helmut> my last mail to the submitter when unanswered though
19:37:08 <spwhitton> anyone disagree with asking zeha exactly how he intends to install it in the new package and asking original submitter if they agree iwth ntyni and myon that it has to be in PATH?
19:37:22 <Myon> ok
19:37:29 * gwolf agrees with spwhitton
19:37:42 <spwhitton> who could write those messages?
19:37:44 <ntyni> works for me
19:38:05 <spwhitton> Myon: as you have already been the most involved, could you do the one to zeha?  and the other too if you like?
19:38:06 <helmut> I agree with both questions, but personally I'm not convinced of requiring it to be in $PATH regardless of whether the submitter wants that
19:38:34 <Myon> helmut: do you want to ask zeha or should I?
19:38:38 <gwolf> helmut: would you agree with leaving that answer in the maintainer's hands?
19:38:44 <spwhitton> (oh, right, helmut is probably equally involved, sorry)
19:39:11 <helmut> I can poke zeha, yes.
19:39:14 <Myon> thanks
19:39:36 <helmut> gwolf: that would be my preference, yes.
19:39:37 <spwhitton> #action helmut to ask zeha exactly how he intends to re-provide rename.ul
19:39:48 <spwhitton> Myon: would you like to take writing to submitter?
19:40:02 <Myon> ok
19:40:13 <spwhitton> #action Myon to ask original submitter if keeping rename.ul on PATH is implicit in the request
19:40:31 <spwhitton> #info there might be FHS (and so Policy) implications of installing rename.ul not on PATH
19:40:49 <spwhitton> okay then, thank you everyone, this is good progress.  and thanks to helmut and myon for following up on it over the past few weeks.
19:40:52 <spwhitton> shall we move on?
19:41:03 <Myon> ack
19:41:15 <helmut> ack
19:41:23 <ntyni> sure
19:41:25 <gwolf> yes
19:41:29 <spwhitton> #topic Any Other Business
19:41:31 <spwhitton> does anyone have anything?
19:42:26 <ntyni> not me
19:42:27 <Myon> no
19:42:30 <gwolf> not here
19:43:44 <helmut> not me
19:43:54 <spwhitton> #endmeeting