Since OpenRC 0.13.x one can expect a lot of messages in rc.log that look like this: ``` runscript is deprecated; please use openrc-run instead. ``` This is because of this - https://bugs.gentoo.org/show_bug.cgi?id=494220 . Currently there are at least 794 packages affected. Command used to get this list is: ``` comm -13 <( find /usr/portage -type f -not -name "*eclass*" | xargs awk 'FNR==1&&/^#!\/sbin\/openrc-run/{match(FILENAME, "/usr/portage/([^/]*/[^/]*)/", a); print a[1];}' | sort -u ) <( find /usr/portage -type f -not -name "*eclass*" | xargs awk 'FNR==1&&/^#!\/sbin\/runscript/{match(FILENAME, "/usr/portage/([^/]*/[^/]*)/", a); print a[1];}' | sort -u ) | wc -l ``` I haven't found any bug dedicated to this problem so I'm creating one now.
Hi Rindeal, thanks for reporting. However it would be better to report each package separately so the maintainers can take care of it.
Hi Tomas, the change happened >2 years ago and since then only ~20 packages migrated to openrc-run, while another ~800 did not. With this tempo we'll all be dead sooner then all packages migrate. This is a global issue and as such needs a global change across whole tree rather then atomic changes by package maintainers.
I would guess that the lack of movement on this has to do with the message only showing up in verbose mode, so you don't see it unless you go looking for it. I had it showing initially but received complaints about it being spammy. I don't plan to drop runscript until I can figure out a way to get the messages to show so that people make the move and don't complain about them.
Well, as you can see, unless you enforce it, nothing happens. Gentoo has some consortium or committee or something like that, which decides what to do with things of this scope. So maybe we could gather them to have a vote? When Gentoo migrates, you can restore the message to always show up. Then, after a few months, remove runscipt completely and you should be done with this thing.
Well, my plan is to start nagging people again with the .21 release and at the same time either migrate packages myself or see if we can get folks to do the migration. It is a harmless change that could, on its own, go straight to stable at this point since openrc-run is part of stable openrc.
I've added the tracker keyword here, but I'm not sure yet if we are going to open individual bugs for all the packages involved. When OpenRC 0.21 comes out, I'll figure out that process.
Ok, looking forward to it. If you'll need some help afterwards, feel free to ask.
sshd init script still uses 'runscript'
This bug is now a tracker. If you find packages that still use runscript, file bugs against those packages and make them block this bug.
(In reply to William Hubbs from comment #5) > Well, my plan is to start nagging people again with the .21 release and > at the same time either migrate packages myself or see if we can get > folks to do the migration. It is a harmless change that could, on its > own, go straight to stable at this point since openrc-run is part of > stable openrc. I'm happy to help with this. I ran some numbers: # of affected files: austin@austin2:~/src/gentoo$ git grep '#!/sbin/runscript' | wc -l 1262 # of affected packages: austin@austin2:~/src/gentoo$ git grep '#!/sbin/runscript' | cut -d / -f1-2 | sort -u | wc -l 800 I'll take a stab at updating the unmaintained packages. (In reply to William Hubbs from comment #9) > This bug is now a tracker. If you find packages that still use > runscript, file bugs against those packages and make them block this bug. Should this be confirmed/in_progress then?
Those numbers are highly motivational. Like: One eternity later...: "Oh look, only 254 packages remaining!"
Don't have ebuilds migrated to openrc-run have to block <sys-apps/openrc-0.18.4? Remember that people could have openrc-{0.13.11,0.16.4,0.17} which should not support openrc-run.
(In reply to Jan Chren (rindeal) from comment #11) > Those numbers are highly motivational. Like: > > One eternity later...: "Oh look, only 254 packages remaining!" I've cleaned up most of the maintainer-needed packages, things have improved a bit: austin@austin2:~/src/gentoo$ git grep '#!/sbin/runscript' | wc -l 1103 austin@austin2:~/src/gentoo$ git grep '#!/sbin/runscript' | cut -d / -f1-2 | sort -u | wc -l 683 I don't really want to have to file a ton of bugs, to get this fixed. Will start a thread on gentoo-dev@ soonish.
(In reply to Thomas Deutschmann from comment #12) > Don't have ebuilds migrated to openrc-run have to block > <sys-apps/openrc-0.18.4? Remember that people could have > openrc-{0.13.11,0.16.4,0.17} which should not support openrc-run. OpenRC-0.16.4 does support openrc-run, and it was stabilized on Gentoo well before the git conversion happened, so we don't need to worry about blocking older versions of OpenRC. If people are running older versions than this they should upgrade.
(In reply to Jan Chren (rindeal) from comment #11) > Those numbers are highly motivational. Like: > > One eternity later...: "Oh look, only 254 packages remaining!" http://article.gmane.org/gmane.linux.gentoo.devel/100815 I'll take care of it in two weeks.
(In reply to Austin English from comment #15) > (In reply to Jan Chren (rindeal) from comment #11) > > Those numbers are highly motivational. Like: > > > > One eternity later...: "Oh look, only 254 packages remaining!" > > http://article.gmane.org/gmane.linux.gentoo.devel/100815 > > > I'll take care of it in two weeks. It's not even clear what the task is. Everybody's supposed to run the command themselves, perhaps with various results? Why don't you attach the list of suspect packages right here?
Also, since you've been breaking packages left and right, maybe you want some guidance here from experienced developers?
Created attachment 433348 [details] affected packages
Created attachment 433350 [details] affected files
Created attachment 433352 [details, diff] proposed patch This would be committed one patch per category/package.
I've created a mapping of maintainers->packages, which may come handy for some. https://gist.github.com/rindeal/1ee42c6b8bb4cd7daf683eea8d6f3af0
(In reply to Jan Chren (rindeal) from comment #21) > I've created a mapping of maintainers->packages, which may come handy for > some. https://gist.github.com/rindeal/1ee42c6b8bb4cd7daf683eea8d6f3af0 Thanks Jan
As one of Austin's mentors, I feel that I need to respond. (In reply to Jeroen Roovers from comment #16) > (In reply to Austin English from comment #15) > > (In reply to Jan Chren (rindeal) from comment #11) > > > Those numbers are highly motivational. Like: > > > > > > One eternity later...: "Oh look, only 254 packages remaining!" > > > > http://article.gmane.org/gmane.linux.gentoo.devel/100815 > > > > > > I'll take care of it in two weeks. > > It's not even clear what the task is. Everybody's supposed to run the > command themselves, perhaps with various results? Why don't you attach the > list of suspect packages right here? The task is actually very clear. #!/sbin/runscript should be changed to #!/sbin/openrc-run in service scripts. This was also mentioned by him on the -dev list. (In reply to Jeroen Roovers from comment #17) > Also, since you've been breaking packages left and right, maybe you want > some guidance here from experienced developers? Six packages out of well over 100 were broken and fixed again within 24 hours. That does not count as "breaking packages left and right". Stop trolling.
(In reply to William Hubbs from comment #23) > Stop trolling. That doesn't mean what you think it means?
All init scripts in the tree have been transitioned to #!/sbin/openrc-run. Last commit was https://github.com/gentoo/gentoo/commit/fc1d0dfe80203fa9c2b0e1cd6ecbcae244ddb4e0
(In reply to Austin English from comment #25) > All init scripts in the tree have been transitioned to #!/sbin/openrc-run. So that's part of the work done and you're not even tracking blocking bugs yet or bundled init.d scripts.
(In reply to Jeroen Roovers from comment #26) > (In reply to Austin English from comment #25) > > All init scripts in the tree have been transitioned to #!/sbin/openrc-run. > > So that's part of the work done and you're not even tracking blocking bugs > yet or bundled init.d scripts. A) All blocking bugs were fixed in the codebase when I marked this bug as fixed (and the bugs themselves now are as well). B) I'm not sure what you mean by bundled init.d scripts. You may mean bundled in upstream releases, in which case, it's not exactly something Gentoo can fix..
I am closing this since I do not know of any other work that needs to be done. Please feel free to re-open if I have missed something.
Actually, what would have been helpful to end-users of Gentoo would have been a Gentoo news item (eselect news ...) indicating this was coming, so it wasn't a complete surprise to those of us who aren't active Gentoo developers. The issue with package maintainers not migrating their init scripts is understandable, but putting loads of messages in front of end-users to address the issue is poor form from a QA perspective. Now, to convert my own personal ebuilds, now that I know about this... :-)
still using runscript $> grep '^#!/sbin/runscript' /etc/init.d/* # sys-process/atop /etc/init.d/atop:#!/sbin/runscript /etc/init.d/atopacct:#!/sbin/runscript # sys-libs/gpm /etc/init.d/gpm:#!/sbin/runscript # app-admin/metalog /etc/init.d/metalog:#!/sbin/runscript # net-misc/rsync /etc/init.d/rsyncd:#!/sbin/runscript # sys-fs/zfs /etc/init.d/zfs-import:#!/sbin/runscript /etc/init.d/zfs-mount:#!/sbin/runscript /etc/init.d/zfs-share:#!/sbin/runscript /etc/init.d/zfs-zed:#!/sbin/runscript --- My last emerge -vuUND @world was 2017-05-01 I'm using the ~amd64 ebuilds.
(In reply to Attila Stehr from comment #30) None of the packages in tree were revbumped when their initscripts were fixed, so if you haven't rebuilt the packages since the change, you'd still have the old initscript. Portage will rebuild a package given a filename owned by that package, so something like this would work: emerge -1 $(grep -l '^#!/sbin/runscript') If any remain afterward, please file a new bug for them.