19:00:02 #startmeeting 19:00:02 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 Useful Commands: #action #agreed #help #info #idea #link #topic. 19:00:13 #topic Roll Call 19:00:15 Sean Whitton 19:00:25 #link https://jitsi.debian.social/TechnicalCommittee 19:01:01 Christoph Berg 19:01:02 Apologies received from Matthew Vernon 19:01:04 Helmut Grohne 19:01:16 Niko Tyni 19:08:56 Gunnar Wolf -- late, but connecting :-) 19:13:13 #topic Review of previous meeting AIs 19:13:31 I did mine and nothing more to say. Myon did his and we will discuss in next agenda item. 19:13:41 I wanted to raise an AI that we accidentally dropped from December 19:14:09 "ehashman to commit final version of private communication to tech-ctte.git procedures/" 19:14:37 (where are ehashman and smcv ) 19:14:37 That's the last part of our "improve the TC" project that we did over past 1.5 yrs 19:14:55 ntyni: haven't heard from them 19:15:15 right 19:15:22 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 we should ask her if she could still do that 19:15:42 Yeah, we could just leave it until the next meeting she is present. 19:15:48 FWIW, the meeting schedule was finalized a bit late, maybe they were not able to join... 19:16:18 Okay then, I'll action myself to ask her about it next meeting I guess? 19:16:26 sounds good 19:16:37 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 or perhaps before the next meeting ;) 19:17:13 Myon: she'll see the minutes, so I was more thinking about a backstop. 19:17:23 ack 19:17:31 #action spwhitton to ask ehashman about status of private comms text next meeting 19:17:41 #topic Bug#1003653: Revision of removal of rename.ul from package util-linux 19:18:07 hopefully everyone is up-to-date. myon's most recent mail matches my understanding of the situation. 19:18:10 I'm in contact with zeha on that and I think I understand his pov quite well at this point. 19:18:26 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 helmut: can you explain why he is less keen than everyone else on just adding rename.ul back somewhere? 19:18:46 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 understandable, but that binary has been there forever 19:19:10 seems to me all other options are worse 19:19:16 He also is very much opposed to shipping readname.ul in essential and I share that view. 19:19:26 Right, I haven't spoken in the thread, but this matches my sentiment 19:19:26 it's probably less bad if it's in a separate package 19:19:30 yeah it makes no sense in essential 19:19:33 I proposed shipping rename in a /usr/libexec path that can be added to $PATH 19:19:39 yeah hence "linuxextrautils" or whatever 19:20:06 I don't recall zeha saying he was fine with that though -- else we'd be done. 19:20:16 non-PATH binaries seem like a non-Debian-typical solution 19:20:25 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 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 yeah I also had the feeling he wants to get it resolved some way 19:21:11 he even commented on the TC bug before I got around to ask him to do that 19:21:15 Myon: libexec> and perhaps not fhs compliant 19:21:35 libexec is FHS I think, just Debian isn't using it 19:21:40 vvverlrgfcrifbvedguifvtjnnjtgrijvngulikcnlfg 19:21:45 vvverlrgfcrivedlejifjvubcetfcnbvllfncrcvihtf 19:21:49 ccccccrjlgikguglgfrvcinekflggkjhdtncnkhdcgtb 19:21:56 that sounds like your yubikey talking..? 19:22:00 yubi key or rot13? 19:22:03 sorry. 19:22:07 or a cat walking on the keyboard? 19:22:14 a very disciplined cat! 19:22:20 heh 19:22:36 Myon: it's fhs for programs used by other installed programs, not utils for user scripts 19:22:42 I think we're getting into details here. There already is basic agreement with zeha to get rename back $somewhere. 19:22:55 spwhitton: right, I misunderstood you 19:22:55 Anyway -- I think this problem will end up unwinding itself even without our "formal" involvement 19:23:12 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 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 let's see how it goes and postpone any ruling to next meeting 19:23:34 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 helmut: the PATH issues matters, from a Policy POV 19:23:58 has he said publically about the PATH thing or is that based on your conversations? 19:24:14 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 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 gwolf: :) 19:24:48 helmut: ah, and did he reply to that? 19:24:57 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 in any case, I consider that details. if we have an intent to put it back somewhere, isn't that enough? 19:25:06 spwhitton: sleeping. 19:25:41 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 (not suggesting zeha would do that. or that the second bug is guaranteed. just that we can preempt at least somewhat) 19:26:19 spwhitton: would we really want to mandate the other implementation in $PATH? 19:26:54 I'm not sure. We should perhaps ask people like the original submitter? 19:26:55 it's been in PATH forever, and people are expecting it there, as rename.ul (as weird as that name is) 19:27:04 Now, I understand the suffix '.ul' means 'from the util-linux package' 19:27:35 yeah the suffix dates back to when it was briefly managed with alternatives 19:27:41 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 ntyni: how was it called before alternatives? 19:28:10 given the perl rename was also there? 19:28:17 not sure, I suspect it wasn't installed at alla 19:28:19 -a 19:28:19 gwolf: the suffix seems way less bad than the various other possible abuses on the table. 19:28:24 do we have to decide about that instead of leaving it at the discretion of zeha? 19:28:27 spwhitton: point. 19:28:36 helmut: I don't know. 19:28:45 helmut: we don't have to, we can just wait for it to resolve itself 19:29:03 helmut: I'd say we don't need to come up with a detailed solution, but maybe point it out 19:29:06 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 unless we see it's moving in a bad direction (to be determined what that means) 19:29:36 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 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 u-l, I guess you mean? 19:30:32 it wasn't my impression anyone is asking for it to be called "rename" 19:30:41 gwolf: update-alternatives 19:30:46 oh, right 19:30:46 we were only asked about 1) and I don't think we agree that 2) is a goal 19:31:01 (sorry for my word ordering that disregards English grammar...) 19:31:02 I think we already ruled out the "ideal" solution isn't going to happen because compat 19:31:13 yeah. I was thinking that find/replace rename->rename.ul was what we were expecting peple to do. 19:31:55 if people want it under other names, we can publish a "rename" command so they can rename it :D 19:31:59 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 helmut: the issue of whether or not it is on PATH remains. 19:32:48 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 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 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 i.e. mailman ships binaries in /usr/lib/mailman/bin, symlinked from /usr/sbin 19:33:59 gwolf: that counts as "in PATH" 19:34:21 right -- but I was starting to look into where the /usr/sbin symlink is created 19:34:54 I am almost sure at some point in the past it was not in the path... 19:35:10 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 why do you think that we have to resolve more details than we've been asked to resolve? 19:35:29 let's hear first what zeha is saying 19:35:44 But I agree with spwhitton -- explicitly asking zeha how he plans to resolve it, whether in the path or not 19:36:00 helmut: I'm thinking that teh PATH thing is /possibly/ implicit in the original submitter's request. 19:36:18 spwhitton: given that I disagree on that, maybe we should reconfirm with the submitter. 19:36:37 helmut: before asking zeha what he intends to do? or perhaps in parallel? 19:36:42 parallel 19:36:47 okay cool. 19:37:02 my last mail to the submitter when unanswered though 19:37:08 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 ok 19:37:29 * gwolf agrees with spwhitton 19:37:42 who could write those messages? 19:37:44 works for me 19:38:05 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 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 helmut: do you want to ask zeha or should I? 19:38:38 helmut: would you agree with leaving that answer in the maintainer's hands? 19:38:44 (oh, right, helmut is probably equally involved, sorry) 19:39:11 I can poke zeha, yes. 19:39:14 thanks 19:39:36 gwolf: that would be my preference, yes. 19:39:37 #action helmut to ask zeha exactly how he intends to re-provide rename.ul 19:39:48 Myon: would you like to take writing to submitter? 19:40:02 ok 19:40:13 #action Myon to ask original submitter if keeping rename.ul on PATH is implicit in the request 19:40:31 #info there might be FHS (and so Policy) implications of installing rename.ul not on PATH 19:40:49 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 shall we move on? 19:41:03 ack 19:41:15 ack 19:41:23 sure 19:41:25 yes 19:41:29 #topic Any Other Business 19:41:31 does anyone have anything? 19:42:26 not me 19:42:27 no 19:42:30 not here 19:43:44 not me 19:43:54 #endmeeting