Gentoo Forums
Gentoo Forums
Gentoo Forums
Quick Search: in
"runscript is deprecated; please use openrc-run instead."
View unanswered posts
View posts from last 24 hours

Goto page Previous  1, 2  
Reply to topic    Gentoo Forums Forum Index Other Things Gentoo
View previous topic :: View next topic  
Author Message
asturm
Developer
Developer


Joined: 05 Apr 2007
Posts: 8935

PostPosted: Sun Jan 18, 2015 10:43 am    Post subject: Reply with quote

Storm in a teacup.
Back to top
View user's profile Send private message
khayyam
Watchman
Watchman


Joined: 07 Jun 2012
Posts: 6227
Location: Room 101

PostPosted: Sun Jan 18, 2015 11:00 am    Post subject: Reply with quote

genstorm wrote:
Storm in a teacup.

a bird in the hand is worth a gift horse in the mouth
Back to top
View user's profile Send private message
steveL
Watchman
Watchman


Joined: 13 Sep 2006
Posts: 5153
Location: The Peanut Gallery

PostPosted: Sun Jan 18, 2015 12:25 pm    Post subject: Reply with quote

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
View user's profile Send private message
F1r31c3r
Tux's lil' helper
Tux's lil' helper


Joined: 31 Aug 2007
Posts: 107
Location: UK

PostPosted: Mon Feb 23, 2015 10:43 pm    Post subject: Reply with quote

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

Code:
cd /etc/init.d


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
View user's profile Send private message
steveL
Watchman
Watchman


Joined: 13 Sep 2006
Posts: 5153
Location: The Peanut Gallery

PostPosted: Tue Feb 24, 2015 10:50 am    Post subject: Reply with quote

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
View user's profile Send private message
F1r31c3r
Tux's lil' helper
Tux's lil' helper


Joined: 31 Aug 2007
Posts: 107
Location: UK

PostPosted: Tue Feb 24, 2015 6:51 pm    Post subject: Reply with quote

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
View user's profile Send private message
steveL
Watchman
Watchman


Joined: 13 Sep 2006
Posts: 5153
Location: The Peanut Gallery

PostPosted: Wed Feb 25, 2015 2:51 pm    Post subject: Reply with quote

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
View user's profile Send private message
<3
Veteran
Veteran


Joined: 21 Oct 2004
Posts: 1081

PostPosted: Fri Mar 06, 2015 2:51 pm    Post subject: Reply with quote

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
View user's profile Send private message
steveL
Watchman
Watchman


Joined: 13 Sep 2006
Posts: 5153
Location: The Peanut Gallery

PostPosted: Fri Mar 06, 2015 5:24 pm    Post subject: Reply with quote

Code:
sed -i -- '1s/runscript/openrc-run/' /etc/init.d/*
Back to top
View user's profile Send private message
<3
Veteran
Veteran


Joined: 21 Oct 2004
Posts: 1081

PostPosted: Sat Mar 07, 2015 4:03 pm    Post subject: Reply with quote

So just replacing that one line will totally fix the problem?
Back to top
View user's profile Send private message
steveL
Watchman
Watchman


Joined: 13 Sep 2006
Posts: 5153
Location: The Peanut Gallery

PostPosted: Sat Mar 07, 2015 9:12 pm    Post subject: Reply with quote

Yup.

You can wait for it to happen naturally, or do it yourself to get rid of the warnings.
Back to top
View user's profile Send private message
miket
Guru
Guru


Joined: 28 Apr 2007
Posts: 488
Location: Gainesville, FL, USA

PostPosted: Sat Mar 07, 2015 10:11 pm    Post subject: Reply with quote

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
View user's profile Send private message
Ant P.
Watchman
Watchman


Joined: 18 Apr 2009
Posts: 6920

PostPosted: Sun Mar 08, 2015 2:53 pm    Post subject: Reply with quote

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
View user's profile Send private message
mv
Watchman
Watchman


Joined: 20 Apr 2005
Posts: 6747

PostPosted: Mon Aug 15, 2016 7:31 am    Post subject: Reply with quote

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
View user's profile Send private message
Ant P.
Watchman
Watchman


Joined: 18 Apr 2009
Posts: 6920

PostPosted: Mon Aug 15, 2016 5:00 pm    Post subject: Reply with quote

It's for that reason I switched all my systems to graphicsmagick, which namespaces the commands like git does.
Back to top
View user's profile Send private message
cord
Guru
Guru


Joined: 28 Apr 2007
Posts: 344

PostPosted: Sun Oct 30, 2016 5:28 pm    Post subject: Reply with quote

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 :roll:
Back to top
View user's profile Send private message
Ant P.
Watchman
Watchman


Joined: 18 Apr 2009
Posts: 6920

PostPosted: Sun Oct 30, 2016 8:35 pm    Post subject: Reply with quote

That just tells us you haven't updated those packages in 2 years. They're not going to rewrite themselves.
Back to top
View user's profile Send private message
augustin
Guru
Guru


Joined: 23 Feb 2015
Posts: 318

PostPosted: Mon Oct 31, 2016 8:00 am    Post subject: Reply with quote

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 :roll:

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
View user's profile Send private message
charles17
Advocate
Advocate


Joined: 02 Mar 2008
Posts: 3664

PostPosted: Mon Oct 31, 2016 10:37 am    Post subject: Reply with quote

See bug 593604.
Back to top
View user's profile Send private message
Hu
Moderator
Moderator


Joined: 06 Mar 2007
Posts: 21602

PostPosted: Tue Nov 01, 2016 1:42 am    Post subject: Reply with quote

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
View user's profile Send private message
Fitzcarraldo
Advocate
Advocate


Joined: 30 Aug 2008
Posts: 2034
Location: United Kingdom

PostPosted: Tue Nov 01, 2016 8:38 am    Post subject: Reply with quote

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
View user's profile Send private message
Hu
Moderator
Moderator


Joined: 06 Mar 2007
Posts: 21602

PostPosted: Wed Nov 02, 2016 1:51 am    Post subject: Reply with quote

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
View user's profile Send private message
MMMMM
Tux's lil' helper
Tux's lil' helper


Joined: 13 Jun 2011
Posts: 141
Location: Berlin

PostPosted: Sat Nov 19, 2016 11:36 am    Post subject: Reply with quote

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
View user's profile Send private message
augustin
Guru
Guru


Joined: 23 Feb 2015
Posts: 318

PostPosted: Tue Nov 22, 2016 2:14 am    Post subject: Reply with quote

Bug 598605 - /etc/init.d/** uses runscript, please convert to openrc-run.
https://bugs.gentoo.org/show_bug.cgi?id=598605
Status: RESOLVED INVALID
Back to top
View user's profile Send private message
Hu
Moderator
Moderator


Joined: 06 Mar 2007
Posts: 21602

PostPosted: Tue Nov 22, 2016 3:23 am    Post subject: Reply with quote

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
View user's profile Send private message
Display posts from previous:   
Reply to topic    Gentoo Forums Forum Index Other Things Gentoo All times are GMT
Goto page Previous  1, 2
Page 2 of 2

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum