>=sys-process/procps-4.0.4 is missing 'pwait' binary, which gentoo-pipewire-launcher script depends on to issue 'restart'. Reproducible: Always Steps to Reproduce: 1. Upgrade to procps 4x 2. run $ gentoo-pipewire-launcher restart 3. observe failure Actual Results: $ gentoo-pipewire-launcher restart Terminating PipeWire processes ... /usr/bin/gentoo-pipewire-launcher: line 37: pwait: command not found PipeWire terminated. PipeWire already running, exiting. (Use 'gentoo-pipewire-launcher restart' to restart PipeWire and WirePlumber.) Expected Results: Service restarts
Yeah, it's now 'pidwait'. Good find.
(In reply to Sam James from comment #1) > Yeah, it's now 'pidwait'. Good find. Gotta love upstream making arbitrary name changes that break things :) Thanks team, easy fix thankfully.
It's not an entirely easy fix at this particular point in time, because version 4 is only available in testing; those of us running procps in stable are still on version 3. So the g-p-l script needs to check, in a cross-shell manner, which binary is actually available. Surely this script is not the only one that's going to be broken by this change? Are there any plans to provide a symlink from the old name to the new name, to facilitate the transition, rather than forcing every script that uses pwait(1) to separately implement the sort of logic i've described above? If not, why not? Given everything on my plate in my life at the moment, i'd rather not have to immediately deprioritise other things to fix this rather wanton breakage ....
(This reminds me of the recent GNU Grep debacle, as described at https://utcc.utoronto.ca/~cks/space/blog/linux/GNUGrepVersusEcology: "To repair this breakage, all of these packages need to be changed to use 'grep -F' and 'grep -E' instead of fgrep and egrep. This change is pointless make-work inflicted on the broad open source ecology by GNU Grep. GNU Grep's decision to cause these long-standing commands to emit new messages requires everyone else to go through making changes in order to return to the status quo. This is exactly the same kind of make work as other pointless API changes, and just like them it's hostile to the broad open source ecology.")
(In reply to Alexis from comment #3) > It's not an entirely easy fix at this particular point in time, because > version 4 is only available in testing; those of us running procps in stable > are still on version 3. So the g-p-l script needs to check, in a cross-shell > manner, which binary is actually available. > Uh, isn't it? command -v ... || command -v ... That's POSIX and it should be fine. I'll do that now. > Surely this script is not the only one that's going to be broken by this > change? Are there any plans to provide a symlink from the old name to the > new name, to facilitate the transition, rather than forcing every script > that uses pwait(1) to separately implement the sort of logic i've described > above? If not, why not? > Nothing else seemed to have broke and I assumed upstream made the change for a reason. It came up briefly in bug 835813.
The bug has been closed via the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=8b6eb8028f4a0ff0457b47ea418dbce617d05d9f commit 8b6eb8028f4a0ff0457b47ea418dbce617d05d9f Author: Sam James <sam@gentoo.org> AuthorDate: 2023-09-12 00:43:02 +0000 Commit: Sam James <sam@gentoo.org> CommitDate: 2023-09-12 00:43:02 +0000 media-video/pipewire: handle procps-4 rename of pwait->pidwait Closes: https://bugs.gentoo.org/914030 Signed-off-by: Sam James <sam@gentoo.org> .../pipewire/files/gentoo-pipewire-launcher.in-r3 | 84 ++++ media-video/pipewire/pipewire-0.3.79-r3.ebuild | 475 +++++++++++++++++++++ media-video/pipewire/pipewire-9999.ebuild | 2 +- 3 files changed, 560 insertions(+), 1 deletion(-)
Yes, i was assuming `command` would have to used, but it's still more complicated logic than simply renaming the command. i'm glad to hear that the change hasn't caused much breakage so far, although i can't help but wonder if that will change once 4 appears in stable; sysadmins running their own scripts relying on pwait might be less likely to be running procps from testing. i know that pgrep and pkill originally appeared on Solaris years ago, but i don't know whether that's also the case for pwait; i assume it's still been around for a long time nonetheless. i'll have to go read upstream's rationale, because although there are _usually_ good reasons for breaking changes to things, there are times when i disagree with the rationales, and after many years of such things, i'm finding my tolerance for such things decreasing when they're contributing to the "death of a thousand cuts" issues at my end.
(In reply to Alexis from comment #7) > Yes, i was assuming `command` would have to used, but it's still more > complicated logic than simply renaming the command. It's still a very easy fix. > > i'm glad to hear that the change hasn't caused much breakage so far, > although i can't help but wonder if that will change once 4 appears in > stable; sysadmins running their own scripts relying on pwait might be less > likely to be running procps from testing. > Anyway, renaming isn't simple because it introduces variance between distributions. I waited a good while before packaging procps for Gentoo because I was worried about other breakage as well (its library changed). > i know that pgrep and pkill originally appeared on Solaris years ago, but i > don't know whether that's also the case for pwait; i assume it's still been > around for a long time nonetheless. i'll have to go read upstream's > rationale, because although there are _usually_ good reasons for breaking > changes to things, there are times when i disagree with the rationales, and > after many years of such things, i'm finding my tolerance for such things > decreasing when they're contributing to the "death of a thousand cuts" > issues at my end. Yes, do let me know if you find it. I haven't found anything but I didn't look too hard. I'm also not totally against a symlink in procps, but I don't see much point at the moment either.
(In reply to Sam James from comment #8) > It's still a very easy fix. Okay, but as i indicated, for me, the issue is that _multiple_ such "very easy fixes" to deal with upstream changes which don't have a very direct benefit to me personally - instead being necessary for me to simply try to maintain something like the status quo on my system - are becoming increasingly annoying. Particularly when the situation is such that (unlike in this case) the _actual required change_ might be small, but it still takes me a while to learn various things to get me to that point. (Even assuming there aren't blocks along the way, as in the case of the "large changes" involved in my recent experiences moving from i3+polybar to sway+waybar, which i noted in the Waybar page i created on the wiki.) > Anyway, renaming isn't simple because it introduces variance between > distributions. I waited a good while before packaging procps for Gentoo > because I was worried about other breakage as well (its library changed). *nod* > Yes, do let me know if you find it. I haven't found anything but I didn't > look too hard. Based on procps commit 52afb3a8, the change seems to have been made on the basis that 'extrace' has a 'pwait' binary: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=982391 which seems ridiculous to me. Sure, examining the commit logs, extrace's pwait appeared in 2014, whereas procps's appeared in 2020, but how many people use 'extrace' as their 'pwait' provider - which isn't even in the main Gentoo repo, nor in GURU - compared to 'procps'? Sorry for ranting about this (upstream) issue here, but this just happens to be the straw breaking this camel's back. > I'm also not totally against a symlink in procps, but I don't see much point > at the moment either. Okay, fair enough.
(In reply to Alexis from comment #9) > (In reply to Sam James from comment #8) > > > It's still a very easy fix. > > Okay, but as i indicated, for me, the issue is that _multiple_ such "very > easy fixes" to deal with upstream changes which don't have a very direct > benefit to me personally - instead being necessary for me to simply try to > maintain something like the status quo on my system - are becoming > increasingly annoying. Particularly when the situation is such that (unlike > in this case) the _actual required change_ might be small, but it still > takes me a while to learn various things to get me to that point. (Even > assuming there aren't blocks along the way, as in the case of the "large > changes" involved in my recent experiences moving from i3+polybar to > sway+waybar, which i noted in the Waybar page i created on the wiki.) > I understand. It's just not my fault, not super helpful to the poor guy reporting a problem (who is also going to be frustrated), and it's not really relevant to the issue at hand other than you being frustrated. I get it, it's just not really for the bug tracker. > > Anyway, renaming isn't simple because it introduces variance between > > distributions. I waited a good while before packaging procps for Gentoo > > because I was worried about other breakage as well (its library changed). > > *nod* > > > Yes, do let me know if you find it. I haven't found anything but I didn't > > look too hard. > > Based on procps commit 52afb3a8, the change seems to have been made on the > basis that 'extrace' has a 'pwait' binary: > > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=982391 > What's especially frustrating is, while I'm sure the procps maintainer is nice enough, he ended up adding the new procps to Debian (in his other role as its maintainer in Debian) pretty early, which felt a bit like dumping it for more testing. > which seems ridiculous to me. Sure, examining the commit logs, extrace's > pwait appeared in 2014, whereas procps's appeared in 2020, but how many > people use 'extrace' as their 'pwait' provider - which isn't even in the > main Gentoo repo, nor in GURU - compared to 'procps'? I'd never heard of it, even. I see it's https://github.com/leahneukirchen/extrace, and no disrespect to Leah, but I feel like it would've been worth extrace considering changing its name given procps installing it would've meant it prolifterated quite far. Not really clear they considered the impact either :(
> I understand. It's just not my fault, not super helpful to the poor guy > reporting a problem (who is also going to be frustrated), and it's not > really relevant to the issue at hand other than you being frustrated. I get > it, it's just not really for the bug tracker. You're right, and i'm sorry that i wasn't clearer that my issues were with upstream, and that i was trying to work out why upstream wasn't providing a symlink so that individual scripts wouldn't be immediately broken and have to be changed. The bottom line is that this is why i'm actively moving away from doing volunteer ICT stuff. Given the significant issues i'm having to deal with elsewhere in my life, i don't have the resources to appropriately handle this sort of thing. Sorry. > What's especially frustrating is, while I'm sure the procps maintainer is > nice enough, he ended up adding the new procps to Debian (in his other role > as its maintainer in Debian) pretty early, which felt a bit like dumping it > for more testing. Yeah. :-/ > I'd never heard of it, even. I see it's > https://github.com/leahneukirchen/extrace, and no disrespect to Leah, but I > feel like it would've been worth extrace considering changing its name given > procps installing it would've meant it prolifterated quite far. > > Not really clear they considered the impact either :( Yep. :-/
