View previous topic :: View next topic |
Author |
Message |
asturm Developer
Joined: 05 Apr 2007 Posts: 8936
|
Posted: Sun Jan 18, 2015 10:43 am Post subject: |
|
|
Storm in a teacup. |
|
Back to top |
|
|
khayyam Watchman
Joined: 07 Jun 2012 Posts: 6227 Location: Room 101
|
Posted: Sun Jan 18, 2015 11:00 am Post subject: |
|
|
genstorm wrote: | Storm in a teacup. |
a bird in the hand is worth a gift horse in the mouth |
|
Back to top |
|
|
steveL Watchman
Joined: 13 Sep 2006 Posts: 5153 Location: The Peanut Gallery
|
Posted: Sun Jan 18, 2015 12:25 pm Post subject: |
|
|
genstorm wrote: | Storm in a teacup. |
khayyam wrote: | a bird in the hand is worth a gift horse in the mouth |
Lol, brilliant. |
|
Back to top |
|
|
F1r31c3r Tux's lil' helper
Joined: 31 Aug 2007 Posts: 107 Location: UK
|
Posted: Mon Feb 23, 2015 10:43 pm Post subject: |
|
|
I just recently got blatted with these messages when i enabled
ABI_X86="32 64"
so i did this to check if openrc-run actually existed
Code: | ls -l /sbin/openrc-run |
Then
and while in the init.d directory
Code: | sed -i -- 's/runscript/openrc-run/g' * |
then pick a module that loads and double check it updated with
Code: | cat /etc/init.d/alsasound |
and you should see it shows the changed runscript to openrc-run
Code: | #!/sbin/openrc-run
# $Header: /var/cvsroot/gentoo-x86/media-sound/alsa-utils/files/alsasound.initd-r6,v 1.1 2014/06/23 21:34:42 ssuominen Exp $
# Copyright 1999-2014 Gentoo Foundation
# Distributed under the terms of the GNU General Public License v2
|
I am almost certain someone else is gong to come across this problem and this thread but be totally lost as to what and how to sort it. _________________ A WikI, A collection of mass misinformation based on opinion and manipulation by a deception of freedom.
If we know the truth, then we should be free from deception (John 8:42-47 ) |
|
Back to top |
|
|
steveL Watchman
Joined: 13 Sep 2006 Posts: 5153 Location: The Peanut Gallery
|
Posted: Tue Feb 24, 2015 10:50 am Post subject: |
|
|
F1r31c3r wrote: | Code: | sed -i -- 's/runscript/openrc-run/g' * |
|
This is a bad idea; it would be saner if you added a 1 at the start of the command.
Nice idea; might prefer a small scriptlet that checks which ones actually require the change first, and tells the users that they've been changed. |
|
Back to top |
|
|
F1r31c3r Tux's lil' helper
Joined: 31 Aug 2007 Posts: 107 Location: UK
|
Posted: Tue Feb 24, 2015 6:51 pm Post subject: |
|
|
steveL wrote: | F1r31c3r wrote: | Code: | sed -i -- 's/runscript/openrc-run/g' * |
|
This is a bad idea; it would be saner if you added a 1 at the start of the command.
Nice idea; might prefer a small scriptlet that checks which ones actually require the change first, and tells the users that they've been changed. |
That is interesting, care to elaborate.
It was an all night challenge i was up with trying to build the system with the ABI_x86="32 64" and had to overcome this hurdle of warning messages.
I had checked that /sbin/openrc-run and /sbin/runscript are actually just a symbolic link linking to the same program /sbin/openrc
If the /etc/init.d directory has files running with runscript needing it to use openrc-run instead then those that were not complaining would still work with openrc-run either way. After all it is but the same program just symbolic linked to a different name.
I agree a scriptlet would have been a more better way to resolve the problem but i wanted quicker. After all it is far quicker to change directory and type the sed command.
That said i had boot ordering issues after this so i had to reshuffle some daemons from default run level to boot and so on. ConsoleKit being one of them as it was in the default runlevel. Moving it to the boot level sorted its issues out. I also had to move clamd out of the boot level and put it into the default run level as it was running before the FS had mounted correctly.
I just used the sed command as a find and on find replace command. _________________ A WikI, A collection of mass misinformation based on opinion and manipulation by a deception of freedom.
If we know the truth, then we should be free from deception (John 8:42-47 ) |
|
Back to top |
|
|
steveL Watchman
Joined: 13 Sep 2006 Posts: 5153 Location: The Peanut Gallery
|
Posted: Wed Feb 25, 2015 2:51 pm Post subject: |
|
|
F1r31c3r wrote: | Code: | sed -i -- 's/runscript/openrc-run/g' * |
|
steveL wrote: | This is a bad idea; it would be saner if you added a 1 at the start of the command.
Nice idea; might prefer a small scriptlet that checks which ones actually require the change first, and tells the users that they've been changed. |
F1r31c3r wrote: | That is interesting, care to elaborate. |
You only want it to do the substitution on the first line; in fact it's usually simpler to: Code: | { printf '#! %s\n' "$path"; sed 1d "$script"; } > "$outpath" | since there's no worry about what the content of that shebang is: you just set it correctly the once, in shell, and there are no regex quoting issues to deal with, ever.
One can also just use cat, if it doesn't have a shebang.
Checking what the first line is, is as simple as: Code: | read -r < "$script" && shebang=$REPLY || return 2 | for the whole thing, or: Code: | read -r shebang < "$script" || return 2 | to get rid of trailing and leading ws.
We're more likely just to do a case (works everywhere) after the read, in both situations. One can also use sed directly:
Code: | shebang() {
[ -n "$3" ] || die 'usage: shebang "$inscript" "$path" "$outpath"'
local script path
script=$1 path=$2
case $(sed 1q "$script") in '') return 2
;; "#! $path"|"#! $path "*) cat "$script" > "$3"
;; '#!'*) { printf '#! %s\n' "$path"; sed 1d "$script"; } > "$3"
;; *) { printf '#! %s\n' "$path"; cat "$script"; } > "$3"
esac || die "cannot write to: '$3'"
} | but that's an extra fork for no reason, which can be expensive on proprietary rubbish, and there's no point making the poor CPU do useless work.
Quote: | It was an all night challenge i was up with trying to build the system with the ABI_x86="32 64" and had to overcome this hurdle of warning messages. |
Yeah I really don't like that approach to multilib; it's like the python-nonsense on steroids. Feels more like someone exploring the limits of their bash than approaching the problem cleanly.
It's all very well to say "but I've reinvented it all in shell"; if that wasn't the best approach in the first place, irrespective of language, it makes no odds that you've shown that bash is Turing-complete.
We knew that already; you might as well start implementing apache and postfix in awk, because "C is buggy" (aka: "outside my comfort zone".)
Quote: | I had checked that /sbin/openrc-run and /sbin/runscript are actually just a symbolic link linking to the same program /sbin/openrc
If the /etc/init.d directory has files running with runscript needing it to use openrc-run instead then those that were not complaining would still work with openrc-run either way. After all it is but the same program just symbolic linked to a different name. |
Yup, another solution looking for a problem. Anyone would think openrc and Gentoo had no history, when for many of us it was a breath of relief, and instant sanity, which was a large part of why we stuck with Gentoo.
Quote: | I agree a scriptlet would have been a more better way to resolve the problem but i wanted quicker. After all it is far quicker to change directory and type the sed command. |
Yeah no worries; I always tend to think of scripting and automation first, when all you want is to get over a bump.
Quote: | That said i had boot ordering issues after this so i had to reshuffle some daemons from default run level to boot and so on. ConsoleKit being one of them as it was in the default runlevel. Moving it to the boot level sorted its issues out. I also had to move clamd out of the boot level and put it into the default run level as it was running before the FS had mounted correctly. |
Yeah there's some nutty ordering (as well as other idiocy) since UberLard (praise the Lard;) moved on to netbsd, and dhcpcd et al. None of it documented very well either; I mean why is alsa in boot runlevel?
It's hardly needed to bring up the rest of the machine; nor is adding it to nonetwork as well as default, going to annoy most people. Server admins typically want to tweak everything in any case, before they push it out, and have scripts etc to deal with all kinds of oddities, so it's not an issue for them (even if we didn't disable by default), whereas everyone else needs sound modules sorted, but not before they can even get localmount.
Quote: | I just used the sed command as a find and on find replace command. |
Yeah sure; that reminds me. 'Nother scripting tip (not for this issue); try: Code: | foo() { find "$@" -exec sh -c 'for f; do echo "${f##*/} in: ${f%/*}"; done' _ +; } | You can use bash -c (or mksh, or zsh..) instead of sh -c but you usually don't need to. |
|
Back to top |
|
|
<3 Veteran
Joined: 21 Oct 2004 Posts: 1081
|
Posted: Fri Mar 06, 2015 2:51 pm Post subject: |
|
|
I don't want to get involved in this Gentoo vs. Debian / systemd vs open-rc debate but can someone please tell me how to fix the original problem "runscript is depreciated please use openrc-run instead"? |
|
Back to top |
|
|
steveL Watchman
Joined: 13 Sep 2006 Posts: 5153 Location: The Peanut Gallery
|
Posted: Fri Mar 06, 2015 5:24 pm Post subject: |
|
|
Code: | sed -i -- '1s/runscript/openrc-run/' /etc/init.d/* |
|
|
Back to top |
|
|
<3 Veteran
Joined: 21 Oct 2004 Posts: 1081
|
Posted: Sat Mar 07, 2015 4:03 pm Post subject: |
|
|
So just replacing that one line will totally fix the problem? |
|
Back to top |
|
|
steveL Watchman
Joined: 13 Sep 2006 Posts: 5153 Location: The Peanut Gallery
|
Posted: Sat Mar 07, 2015 9:12 pm Post subject: |
|
|
Yup.
You can wait for it to happen naturally, or do it yourself to get rid of the warnings. |
|
Back to top |
|
|
miket Guru
Joined: 28 Apr 2007 Posts: 488 Location: Gainesville, FL, USA
|
Posted: Sat Mar 07, 2015 10:11 pm Post subject: |
|
|
A really pertinent question at this point is why the same people who took it upon themselves to rename the main executable of a popular package from ack to ack-grep could possibly allow themselves be the upstream of a minor package having a supplemental executable with such a generic name as runscript?
After all, minicom isn't the heavyweight that, say, imagemagick is. That one has all kinds of generic names as executables: convert, compare, display, identify, and stream are some of them. Those names are way too generic, but imagemagick has clout.
While I'm at it, I wonder why the maintainer of openrc gave zero pushback against Bug 494220. There was no discussion of the merits of the proposal. The only two commenters were the bug reporter and the package maintainer. There did seem to be some out-of-band discussion; I wish we could know more about it.
It does seem like a lot of moves hidden in the shadows. One thing I'll grant Lennart Poettering: he adverts to the things he wants to do. |
|
Back to top |
|
|
Ant P. Watchman
Joined: 18 Apr 2009 Posts: 6920
|
Posted: Sun Mar 08, 2015 2:53 pm Post subject: |
|
|
Debian isn't new to making decisions of questionable merit like this - they also knowingly ship broken software including a "ffmpeg" binary that spat out a ton of false messages about it being deprecated, which pissed off *a lot* of Ubuntu users who were kept totally in the dark. In some countries (and if ffmpeg itself were run by litigious assholes) that'd be a libel case waiting to happen. |
|
Back to top |
|
|
mv Watchman
Joined: 20 Apr 2005 Posts: 6747
|
Posted: Mon Aug 15, 2016 7:31 am Post subject: |
|
|
miket wrote: | imagemagick [...] has all kinds of generic names as executables: convert, compare, display, identify, and stream are some of them. Those names are way too generic |
I read this post only now. Indeed, these names of imagemagick are a nuisance. I am very glad that other projects fix this sort of bugs. |
|
Back to top |
|
|
Ant P. Watchman
Joined: 18 Apr 2009 Posts: 6920
|
Posted: Mon Aug 15, 2016 5:00 pm Post subject: |
|
|
It's for that reason I switched all my systems to graphicsmagick, which namespaces the commands like git does. |
|
Back to top |
|
|
cord Guru
Joined: 28 Apr 2007 Posts: 344
|
Posted: Sun Oct 30, 2016 5:28 pm Post subject: |
|
|
steveL wrote: | You can wait for it to happen naturally, or do it yourself to get rid of the warnings. |
Well, almost 2 years have passed but /etc/init.d/udev and /etc/init.d/net.lo are still use run-script |
|
Back to top |
|
|
Ant P. Watchman
Joined: 18 Apr 2009 Posts: 6920
|
Posted: Sun Oct 30, 2016 8:35 pm Post subject: |
|
|
That just tells us you haven't updated those packages in 2 years. They're not going to rewrite themselves. |
|
Back to top |
|
|
augustin Guru
Joined: 23 Feb 2015 Posts: 318
|
Posted: Mon Oct 31, 2016 8:00 am Post subject: |
|
|
cord wrote: | steveL wrote: | You can wait for it to happen naturally, or do it yourself to get rid of the warnings. |
Well, almost 2 years have passed but /etc/init.d/udev and /etc/init.d/net.lo are still use run-script |
I noticed this myself. I filed the bug report here:
https://bugs.gentoo.org/show_bug.cgi?id=598605
When we do emerge --update, the scripts in /etc/init.d/ get updated, right? If so, the problem has not been solved because my system is up to date and still has those deprecated shebangs. |
|
Back to top |
|
|
charles17 Advocate
Joined: 02 Mar 2008 Posts: 3664
|
Posted: Mon Oct 31, 2016 10:37 am Post subject: |
|
|
See bug 593604. |
|
Back to top |
|
|
Hu Moderator
Joined: 06 Mar 2007 Posts: 21624
|
Posted: Tue Nov 01, 2016 1:42 am Post subject: |
|
|
augustin wrote: | When we do emerge --update, the scripts in /etc/init.d/ get updated, right? If so, the problem has not been solved because my system is up to date and still has those deprecated shebangs. | When you (re)install a package, you get the current init.d files for that version of the package. So if you have rebuilt the package that owns the offending init.d file, and the maintainer of that package has modified its init.d file to follow the new convention, then the file should be fixed (or scheduled for a fix, if CONFIG_PROTECT blocked a direct overwrite). If you have not reinstalled the owning package, perhaps because no updates are available, then you would not have the fix, even if you have used emerge --update @world to update other packages. |
|
Back to top |
|
|
Fitzcarraldo Advocate
Joined: 30 Aug 2008 Posts: 2034 Location: United Kingdom
|
Posted: Tue Nov 01, 2016 8:38 am Post subject: |
|
|
If package maintainers updated the applicable init scripts, they should have changed the package revision (-r suffix). That would force a rebuild if the user updates @world. If maintainers updated the init script without changing the revision, that would be bad practice, wouldn't it? _________________ Clevo W230SS: amd64, VIDEO_CARDS="intel modesetting nvidia".
Compal NBLB2: ~amd64, xf86-video-ati. Dual boot Win 7 Pro 64-bit.
OpenRC udev elogind & KDE on both.
Fitzcarraldo's blog |
|
Back to top |
|
|
Hu Moderator
Joined: 06 Mar 2007 Posts: 21624
|
Posted: Wed Nov 02, 2016 1:51 am Post subject: |
|
|
Updating without changing the -rN suffix is a matter of debate. Generally, yes, the revision should be increased. In some cases, mostly related to situations where affected users cannot have installed the package, a silent bump is allowed. For example, if USE=foo enables a patch that causes the build to fail, you can assume that nobody installed successfully with USE=foo, so fixing that patch does not require a bump. I have also seen some cases where a package was modified without a bump for other reasons, but I cannot recall any of those where I thought it was a good idea. |
|
Back to top |
|
|
MMMMM Tux's lil' helper
Joined: 13 Jun 2011 Posts: 141 Location: Berlin
|
Posted: Sat Nov 19, 2016 11:36 am Post subject: |
|
|
Having these warnings I found this discussion.
Some scripts are already updated:
Code: |
init.d # grep openrc-run *|wc -l
69
init.d # grep runscript *|wc -l
46
|
Nevertheless I'll update the others. |
|
Back to top |
|
|
augustin Guru
Joined: 23 Feb 2015 Posts: 318
|
|
Back to top |
|
|
Hu Moderator
Joined: 06 Mar 2007 Posts: 21624
|
Posted: Tue Nov 22, 2016 3:23 am Post subject: |
|
|
I interpret the discussion in that bug to mean that this is not considered a problem with OpenRC (which started the problem by renaming one of its widely used programs), but with the individual packages. For each initscript which emits the warning, force Portage to reinstall the owning package. If you still get the warning from that initscript, then you should report a problem to the maintainer of that package. As discussed higher in this topic, it would have been convenient if every affected package was revision-bumped so that Portage would encourage you to rebuild it. In some cases, a package might have been fixed without a bump. |
|
Back to top |
|
|
|