[gentoo-dev] Last rites: media-sound/lastfm-desktop

2017-09-30 Thread Michael Palimaka
# 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



[gentoo-portage-dev] [PATCH] want_restart_for_use_change: backtrack only if needed (bug 632598)

2017-09-30 Thread Zac Medico
Only backtrack if changes break a USE dependency. Prior
to this fix, the included test case succeeded only with
a --backtrack setting of 3 or more, but now it succeeds
with a --backtrack setting of 2.

X-Gentoo-bug: 632598
X-Gentoo-bug-url: https://bugs.gentoo.org/632598
---
 pym/_emerge/depgraph.py| 13 +++-
 .../resolver/test_autounmask_use_backtrack.py  | 86 ++
 2 files changed, 95 insertions(+), 4 deletions(-)
 create mode 100644 pym/portage/tests/resolver/test_autounmask_use_backtrack.py

diff --git a/pym/_emerge/depgraph.py b/pym/_emerge/depgraph.py
index b0149c4dc..0b9b98dbb 100644
--- a/pym/_emerge/depgraph.py
+++ b/pym/_emerge/depgraph.py
@@ -5972,11 +5972,16 @@ class depgraph(object):
 
new_use, changes = 
self._dynamic_config._needed_use_config_changes.get(pkg)
for ppkg, atom in parent_atoms:
-   if not atom.use or \
-   not any(x in atom.use.required for x in 
changes):
+   if not atom.use:
continue
-   else:
-   return True
+
+   # Backtrack only if changes break a USE 
dependency.
+   enabled = atom.use.enabled
+   disabled = atom.use.disabled
+   for k, v in changes.items():
+   want_enabled = k in enabled
+   if (want_enabled or k in disabled) and 
want_enabled != v:
+   return True
 
return False
 
diff --git a/pym/portage/tests/resolver/test_autounmask_use_backtrack.py 
b/pym/portage/tests/resolver/test_autounmask_use_backtrack.py
new file mode 100644
index 0..83edeafa4
--- /dev/null
+++ b/pym/portage/tests/resolver/test_autounmask_use_backtrack.py
@@ -0,0 +1,86 @@
+# Copyright 2017 Gentoo Foundation
+# Distributed under the terms of the GNU General Public License v2
+
+from portage.tests import TestCase
+from portage.tests.resolver.ResolverPlayground import (
+   ResolverPlayground,
+   ResolverPlaygroundTestCase,
+)
+
+class AutounmaskUseBacktrackTestCase(TestCase):
+
+   def testAutounmaskUseBacktrack(self):
+   ebuilds = {
+   'dev-libs/A-1': {
+   'EAPI': '6',
+   'RDEPEND': 'dev-libs/C',
+   },
+   'dev-libs/A-2': {
+   'EAPI': '6',
+   'RDEPEND': 'dev-libs/C[y]',
+   },
+   'dev-libs/A-3': {
+   'EAPI': '6',
+   'RDEPEND': 'dev-libs/C',
+   },
+   'dev-libs/B-1': {
+   'EAPI': '6',
+   'RDEPEND': '=dev-libs/A-2 dev-libs/C[x]',
+   },
+   }
+
+   installed = {
+   'dev-libs/A-1': {
+   'EAPI': '6',
+   'RDEPEND': 'dev-libs/C',
+   },
+   'dev-libs/B-1': {
+   'EAPI': '6',
+   'RDEPEND': '

Re: [gentoo-dev] Providing a `service` scripts that speaks OpenRC and systemd

2017-09-30 Thread Tom H
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] Checking if a package respects LDFLAGS

2017-09-30 Thread Robin H. Johnson
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

2017-09-30 Thread Duncan
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

2017-09-30 Thread Andreas K. Huettel
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

2017-09-30 Thread 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:


$ 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://

2017-09-30 Thread Bertrand Jacquin
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

2017-09-30 Thread Bertrand Jacquin
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

2017-09-30 Thread Bertrand Jacquin
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

2017-09-30 Thread Matija Skala
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

2017-09-30 Thread Patrice Clement
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

2017-09-30 Thread James Le Cuirot
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

2017-09-30 Thread Michał Górny
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




[gentoo-dev] Last rites: net-misc/dnetstats

2017-09-30 Thread Michael Palimaka
# Michael Palimaka  (30 Sep 2017)
# Depends on dead qt4. Dead upstream.
# Masked for removal in 30 days.
net-misc/dnetstats



[gentoo-dev] Last rites: app-office/qcharselect

2017-09-30 Thread Michael Palimaka
# Michael Palimaka  (30 Sep 2017)
# Depends on dead qt4. Dead upstream.
# Masked for removal in 30 days.
app-office/qcharselect