[gentoo-dev] Last rites: media-sound/lastfm-desktop
# Michael Palimaka (01 Oct 2017) # Fails to build (bug #622632). Requires dead and vulnerable qtwebkit4 # (bug #620710). Masked for removal in 30 days. media-sound/lastfm-desktop
Re: [gentoo-dev] Providing a `service` scripts that speaks OpenRC and systemd
On Sat, Sep 30, 2017 at 12:20 AM, Walter Dnes wrote:
> On Thu, Sep 28, 2017 at 04:27:31PM -0500, Austin English wrote
>> While having the pleasure of working with some proprietary software
>> recently, I was asked to run `service foo restart`, and was surprised to
>> see:
>> foobar ~ # service foo restart
>> * service: service `foo' does not exist
>
> Ridiculous! We need to develop one universal standard that covers
> everyone's use cases. https://xkcd.com/927/
>
> But if you insist, why not just set up a short bash script called
> "service" rather than monkeying with every init system's internals?
>
> #!/bin/bash
> if [[ ]] ; then
>systemctl ${2} ${1}
> elif [[ ]] ; then
>/etc/init.d/${1} ${2}
> elif [[ ]] ; then
>
> else
>echo "ERROR: Unsupported init system; 'service' call failed"
> fi
With a "[ $# -eq 2 ]" test and with "env -i set_some_envvars
/etc/init.d/${1} ${2}" (and use "rc-service ${1} ${2}" instead of
"/etc/init.d/${1} ${2}")
> This can handle a large number of different inits, with as many "elif"
> lines as you care to add. But, how do we reliably detect the currently
> running init system? Are there running processes, or entries in /sys/
> or /proc/ or /dev that are unique to to each init system?
It's not init that you want to check, it's rc.
For openrc, "[ -d /run/openrc ]" should do the trick.
For systemd, the canonical way is "[ -d /run/systemd/system ]".
Re: [gentoo-dev] Re: Providing a `service` scripts that speaks OpenRC and systemd
On Sat, Sep 30, 2017 at 5:32 PM, Duncan <1i5t5.dun...@cox.net> wrote: > Walter Dnes posted on Sat, 30 Sep 2017 00:20:31 -0400 as excerpted: > >> But, how do we reliably detect the currently running init system? Are >> there running processes, or entries in /sys/ or /proc/ or /dev that are >> unique to to each init system? > > In theory at least, that's easy enough, just check the kernel > commandline's (/proc/cmdline) init= if present, and fall back to matching > against the path (canonical, to take care of symlink-based init- > switching) of PID 1 if init= isn't present or points to the default > /sbin/init. > Using the command line would give the wrong answer inside a container, as it would tell you what init the host is using, and not what init the container is using (which is what you want if you're running in a container that actually has a service manager running). Also, starting/stopping services requires identifying the service manager, not init. You could be running sysvinit without running openrc. Sure, systemd is both an init and a service manager, but it doesn't have to be that way. I'm not sure what runit runs as PID 1. Certainly distinguishing between the old baselayout-1 and openrc would not be possible just by looking at PID 1. Of course, assuming sysvinit=openrc might be a reasonable interim design if somebody doesn't suggest a better approach. I suspect that inspecting /run might be your best bet here. It seems like the world would benefit from some kind of standard for service managers to identify themselves when they're running. In an ideal world they might even expose an API of sorts via a set of scripts in /run (likely symlinked). That would also potentially eliminate the need for a generic service script in the first place. I point these out as issues to be resolved, not a reason to give up. If somebody thinks a generic service script would be useful they should write one. The fact that it isn't trivial actually suggests that a dedicated utility is the right solution vs just having everybody embed their own logic in their own scripts, likely also not thinking of the above issues. -- Rich
Re: [gentoo-dev] Checking if a package respects LDFLAGS
On Sat, Sep 30, 2017 at 08:05:50PM +0200, Andreas K. Huettel wrote: > Am Samstag, 30. September 2017, 19:03:59 CEST schrieb Keri Harris: > > Hi, > > > > Is there a recommended method for testing if a package respects LDFLAGS? > > > > Arch testers are encouraged to add -Wl,--hash-style=gnu to LDFLAGS > > [1],[2] and portage uses scanelf to check for .hash sections. However it > > appears that ld defaults to using a .gnu.hash section: > That test used to work, but it's broken now. We need a new one. How about something similar to Fedora's binary annotations work, or injecting a .note.gentoo section into binaries (containing literal C/CXX/LDFLAGS would be useful). -- Robin Hugh Johnson Gentoo Linux: Dev, Infra Lead, Foundation Asst. Treasurer E-Mail : robb...@gentoo.org GnuPG FP : 11ACBA4F 4778E3F6 E4EDF38E B27B944E 34884E85 GnuPG FP : 7D0B3CEB E9B85B1F 825BCECF EE05E6F6 A48F6136
[gentoo-dev] Re: Providing a `service` scripts that speaks OpenRC and systemd
Walter Dnes posted on Sat, 30 Sep 2017 00:20:31 -0400 as excerpted:
> But, how do we reliably detect the currently running init system? Are
> there running processes, or entries in /sys/ or /proc/ or /dev that are
> unique to to each init system?
In theory at least, that's easy enough, just check the kernel
commandline's (/proc/cmdline) init= if present, and fall back to matching
against the path (canonical, to take care of symlink-based init-
switching) of PID 1 if init= isn't present or points to the default
/sbin/init.
In practice I suspect one would need to arrange for each supported init
system to drop its own detection executable in place, making the script
something like this:
#!/bin/bash
initdetectpath=/lib/initdetect
if ${initdetectpath}/issystemd ; then
...
elif ${initdetectpath}/isopenrc ; then
...
But, once you're having the initsystems package their own detection
files, you might as well simply make them their own service scripts
designed to do the detection as well, returning a specified error code if
it's not that initsystem, making it as simple as:
#!/bin/bash
notme=
for $servicefile in /lib/initservicedir/* ; do
$servicefile "$@"
code=$?
[[ $code = $notme ]] || break
done
[[ $code = $notme ]] && /
echo "No supported initsystem claimed to be running" > /dev/stderr
exit $code
Then it's up to the initsys packagers whether they want to support the
scheme or not, what sort of detection they do if they support it, and how
they translate the passed parameters if necessary, and bugs in how they
do any of it become the bugs of that initsystem.
--
Duncan - List replies preferred. No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master." Richard Stallman
Re: [gentoo-dev] Checking if a package respects LDFLAGS
Am Samstag, 30. September 2017, 19:03:59 CEST schrieb Keri Harris: > Hi, > > Is there a recommended method for testing if a package respects LDFLAGS? > > Arch testers are encouraged to add -Wl,--hash-style=gnu to LDFLAGS > [1],[2] and portage uses scanelf to check for .hash sections. However it > appears that ld defaults to using a .gnu.hash section: That test used to work, but it's broken now. We need a new one. -- Andreas K. Hüttel dilfri...@gentoo.org Gentoo Linux developer (council, perl, libreoffice)
[gentoo-dev] Checking if a package respects LDFLAGS
Hi, Is there a recommended method for testing if a package respects LDFLAGS? Arch testers are encouraged to add -Wl,--hash-style=gnu to LDFLAGS [1],[2] and portage uses scanelf to check for .hash sections. However it appears that ld defaults to using a .gnu.hash section: $ touch test.c $ gcc -o libtest.so -shared test.c $ scanelf -qyRF '#k%p' -k .hash libtest.so $ scanelf -qyRF '#k%p' -k .gnu.hash libtest.so libtest.so Maybe I'm missing something obvious. Thanks Keri [1] https://wiki.gentoo.org/wiki/Project:AMD64_Arch_Testers [2] https://wiki.gentoo.org/wiki/Project:X86/Arch_Testers_FAQ
[gentoo-dev] [PATCH 3/3] eclass/enlightenment.eclass: Move HOMEPAGE to https://
Update DESCRIPTION while at there since DR17 is from the past.
---
eclass/enlightenment.eclass | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/eclass/enlightenment.eclass b/eclass/enlightenment.eclass
index c374af34cb1d..8e4cc5a7a241 100644
--- a/eclass/enlightenment.eclass
+++ b/eclass/enlightenment.eclass
@@ -88,8 +88,8 @@ case "${EAPI:-0}" in
esac
EXPORT_FUNCTIONS ${ENLIGHTENMENT_EXPF}
-DESCRIPTION="A DR17 production"
-HOMEPAGE="http://www.enlightenment.org/";
+DESCRIPTION="An Enlightenment Foundation production"
+HOMEPAGE="https://www.enlightenment.org";
if [[ -z ${SRC_URI} ]] ; then
case ${EURI_STATE:-${E_STATE}} in
release) SRC_URI="mirror://sourceforge/enlightenment/${P}.tar.gz";;
[gentoo-dev] [PATCH 2/3] eclass/enlightenment.eclass: Remove svn references
SVN for E is long gone.
---
eclass/enlightenment.eclass | 16 ++--
1 file changed, 2 insertions(+), 14 deletions(-)
diff --git a/eclass/enlightenment.eclass b/eclass/enlightenment.eclass
index 23b6ffcc9f54..c374af34cb1d 100644
--- a/eclass/enlightenment.eclass
+++ b/eclass/enlightenment.eclass
@@ -37,7 +37,7 @@ E_ECONF=()
#
# live $PV has a marker
# KEYWORDS ""
-# SRC_URI svn/etc... up
+# SRC_URI git/etc... up
# S$WORKDIR/$E_S_APPEND
#
# Overrides:
@@ -45,7 +45,6 @@ E_ECONF=()
# SRC_URI EURI_STATE
# S EURI_STATE
-E_LIVE_SERVER_DEFAULT_SVN="http://svn.enlightenment.org/svn/e/trunk";
E_LIVE_SERVER_DEFAULT_GIT="https://git.enlightenment.org";
E_STATE="release"
@@ -58,15 +57,6 @@ if [[ ${PV} == ** ]] ; then
E_S_APPEND=${EGIT_URI_APPEND}
E_LIVE_SOURCE="git"
inherit git-2
- else
- E_LIVE_SERVER=${E_LIVE_SERVER:-${E_LIVE_SERVER_DEFAULT_SVN}}
-
- ESVN_URI_APPEND=${ESVN_URI_APPEND:-${PN}}
- ESVN_PROJECT="enlightenment/${ESVN_SUB_PROJECT}"
-
ESVN_REPO_URI=${ESVN_SERVER:-${E_LIVE_SERVER_DEFAULT_SVN}}/${ESVN_SUB_PROJECT}/${ESVN_URI_APPEND}
- E_S_APPEND=${ESVN_URI_APPEND}
- E_LIVE_SOURCE="svn"
- inherit subversion
fi
E_STATE="live"
WANT_AUTOTOOLS="yes"
@@ -126,7 +116,6 @@ esac
enlightenment_src_unpack() {
if [[ ${E_STATE} == "live" ]] ; then
case ${E_LIVE_SOURCE} in
- svn) subversion_src_unpack;;
git) git-2_src_unpack;;
*) die "eek!";;
esac
@@ -147,7 +136,6 @@ enlightenment_src_prepare() {
# autotools require README, when README.in is around, but README
# is created later in configure step
[[ -f README.in ]] && touch README
- export SVN_REPO_PATH=${ESVN_WC_PATH}
eautoreconf
fi
epunt_cxx
@@ -178,7 +166,7 @@ enlightenment_src_compile() {
enlightenment_src_install() {
V=1 emake install DESTDIR="${D}" || die
- find "${D}" '(' -name CVS -o -name .svn -o -name .git ')' -type d -exec
rm -rf '{}' \; 2>/dev/null
+ find "${D}" '(' -name CVS -o -name -o -name .git ')' -type d -exec rm
-rf '{}' \; 2>/dev/null
for d in AUTHORS ChangeLog NEWS README TODO ${EDOCS}; do
[[ -f ${d} ]] && dodoc ${d}
done
[gentoo-dev] [PATCH 1/3] eclass/enlightenment.eclass: Use https:// git URI
git:// are now prohibited on git.enlightenment.org
---
eclass/enlightenment.eclass | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/eclass/enlightenment.eclass b/eclass/enlightenment.eclass
index ae7bb396590c..23b6ffcc9f54 100644
--- a/eclass/enlightenment.eclass
+++ b/eclass/enlightenment.eclass
@@ -46,7 +46,7 @@ E_ECONF=()
# S EURI_STATE
E_LIVE_SERVER_DEFAULT_SVN="http://svn.enlightenment.org/svn/e/trunk";
-E_LIVE_SERVER_DEFAULT_GIT="git://git.enlightenment.org"
+E_LIVE_SERVER_DEFAULT_GIT="https://git.enlightenment.org";
E_STATE="release"
if [[ ${PV} == ** ]] ; then
[gentoo-dev] [PATCH] vala.eclass: Check for vala compiler in the right location
it should be installed into /, not into ${ROOT}
---
eclass/vala.eclass | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/eclass/vala.eclass b/eclass/vala.eclass
index f8a45cdebed6..4227a64c394b 100644
--- a/eclass/vala.eclass
+++ b/eclass/vala.eclass
@@ -81,7 +81,7 @@ vala_best_api_version() {
local u v
[[ ${VALA_USE_DEPEND} ]] && u="[${VALA_USE_DEPEND}(+)]"
for v in $(vala_api_versions); do
- has_version "dev-lang/vala:${v}${u}" && echo "${v}" && return
+ ROOT=/ has_version "dev-lang/vala:${v}${u}" && echo "${v}" &&
return
done
}
@@ -115,7 +115,7 @@ vala_src_prepare() {
fi
if [[ ${version} ]]; then
- has_version "dev-lang/vala:${version}" || die "No installed
vala:$
{version}"
+ ROOT=/ has_version "dev-lang/vala:${version}" || die "No
installed vala:
${version}"
else
version=$(vala_best_api_version)
[[ ${version} ]] || die "No installed vala in $(vala_depend)"
Re: [gentoo-dev] [PATCH] eutils.eclass: Document optfeature suggests packages not installed
Hi Chris
Sunday 03 Sep 2017 16:56:08, Chris Mayo wrote :
> ---
> Please consider this clarification of optfeature.
>
> Chris
>
> eclass/eutils.eclass | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/eclass/eutils.eclass b/eclass/eutils.eclass
> index fe4339f6b89..f35fa5980d7 100644
> --- a/eclass/eutils.eclass
> +++ b/eclass/eutils.eclass
> @@ -827,8 +827,8 @@ use_if_iuse() {
> # @FUNCTION: optfeature
> # @USAGE: [other atoms]
> # @DESCRIPTION:
> -# Print out a message suggesting an optional package (or packages) which
> -# provide the described functionality
> +# Print out a message suggesting an optional package (or packages)
> +# not currently installed which provides the described functionality.
> #
> # The following snippet would suggest app-misc/foo for optional foo support,
> # app-misc/bar or app-misc/baz[bar] for optional bar support
> --
> 2.13.5
>
>
We (Michal Gorny and I) have reviewed your patch and merged it.
Thanks!
--
Patrice Clement
Gentoo Linux developer
http://www.gentoo.org
Re: [gentoo-dev] Providing a `service` scripts that speaks OpenRC and systemd
On 30 September 2017 08:19:36 BST, "Michał Górny" wrote:
>W dniu sob, 30.09.2017 o godzinie 00∶20 -0400, użytkownik Walter Dnes
>napisał:
>> On Thu, Sep 28, 2017 at 04:27:31PM -0500, Austin English wrote
>> > (Note: serious discussion, please take systemd trolling elsewhere).
>> >
>> > While having the pleasure of working with some proprietary software
>> > recently, I was asked to run `service foo restart`, and was
>surprised to
>> > see:
>> > foobar ~ # service foo restart
>> > * service: service `foo' does not exist
>>
>> Ridiculous! We need to develop one universal standard that covers
>> everyone's use cases. https://xkcd.com/927/
>>
>> But if you insist, why not just set up a short bash script called
>> "service" rather than monkeying with every init system's internals?
>>
>>
>> #!/bin/bash
>> if [[ ]] ; then
>>systemctl ${2} ${1}
>> elif [[ ]] ; then
>>/etc/init.d/${1} ${2}
>> elif [[ ]] ; then
>>
>> else
>>echo "ERROR: Unsupported init system; 'service' call failed"
>> fi
>>
>>
>> This can handle a large number of different inits, with as many
>"elif"
>> lines as you care to add. But, how do we reliably detect the
>currently
>> running init system? Are there running processes, or entries in
>/sys/
>> or /proc/ or /dev that are unique to to each init system?
>>
>
>You forgot the huge mapping between different service names. Then
>complex mapping from services that are split/merged. Next we need a
>tool
>that will update conf.d for OpenRC services which are split in systemd,
>to allow people controlling them independently.
Names aren't consistent between Debian and Red Hat either so that isn't really
an issue.
--
Sent from my Android device with K-9 Mail. Please excuse my brevity.
Re: [gentoo-dev] Providing a `service` scripts that speaks OpenRC and systemd
W dniu sob, 30.09.2017 o godzinie 00∶20 -0400, użytkownik Walter Dnes
napisał:
> On Thu, Sep 28, 2017 at 04:27:31PM -0500, Austin English wrote
> > (Note: serious discussion, please take systemd trolling elsewhere).
> >
> > While having the pleasure of working with some proprietary software
> > recently, I was asked to run `service foo restart`, and was surprised to
> > see:
> > foobar ~ # service foo restart
> > * service: service `foo' does not exist
>
> Ridiculous! We need to develop one universal standard that covers
> everyone's use cases. https://xkcd.com/927/
>
> But if you insist, why not just set up a short bash script called
> "service" rather than monkeying with every init system's internals?
>
>
> #!/bin/bash
> if [[ ]] ; then
>systemctl ${2} ${1}
> elif [[ ]] ; then
>/etc/init.d/${1} ${2}
> elif [[ ]] ; then
>
> else
>echo "ERROR: Unsupported init system; 'service' call failed"
> fi
>
>
> This can handle a large number of different inits, with as many "elif"
> lines as you care to add. But, how do we reliably detect the currently
> running init system? Are there running processes, or entries in /sys/
> or /proc/ or /dev that are unique to to each init system?
>
You forgot the huge mapping between different service names. Then
complex mapping from services that are split/merged. Next we need a tool
that will update conf.d for OpenRC services which are split in systemd,
to allow people controlling them independently.
--
Best regards,
Michał Górny
