Re: [gentoo-dev] rfc: noarch keyword

2020-03-19 Thread Thomas Deutschmann
On 2020-03-19 04:03, Kent Fredric wrote:
> Because that experiment basically failed.
> 
> Bugs with that flag, basically were treated (repeatedly) like that flag
> wasn't there.

Hehe, maybe because of missing tooling. Common tools like tatt don't
understand "ALLARCHES" :)


-- 
Regards,
Thomas Deutschmann / Gentoo Linux Developer
C4DD 695F A713 8F24 2AA1 5638 5849 7EE5 1D5D 74A5



signature.asc
Description: OpenPGP digital signature


[gentoo-dev] [PATCH] python-utils-r1.eclass: Make python_wrapper_setup private

2020-03-19 Thread Michał Górny
This function was never meant to be a part of the public API.  Correct
the mistake by renaming it to _python_wrapper_setup(), and adding a QA
warning under the old name.

Signed-off-by: Michał Górny 
---
 eclass/python-any-r1.eclass|  8 
 eclass/python-r1.eclass|  4 ++--
 eclass/python-single-r1.eclass |  4 ++--
 eclass/python-utils-r1.eclass  | 16 +++-
 4 files changed, 23 insertions(+), 9 deletions(-)

diff --git a/eclass/python-any-r1.eclass b/eclass/python-any-r1.eclass
index 66c6965c04ea..d16677debd2a 100644
--- a/eclass/python-any-r1.eclass
+++ b/eclass/python-any-r1.eclass
@@ -300,7 +300,7 @@ python_setup() {
ewarn "Dependencies won't be satisfied, and 
EPYTHON/eselect-python will be ignored."
 
python_export "${impls[0]}" EPYTHON PYTHON
-   python_wrapper_setup
+   _python_wrapper_setup
einfo "Using ${EPYTHON} to build"
return
fi
@@ -309,7 +309,7 @@ python_setup() {
if [[ ${EPYTHON} ]]; then
if _python_EPYTHON_supported "${EPYTHON}"; then
python_export EPYTHON PYTHON
-   python_wrapper_setup
+   _python_wrapper_setup
einfo "Using ${EPYTHON} to build"
return
fi
@@ -325,7 +325,7 @@ python_setup() {
break
elif _python_EPYTHON_supported "${i}"; then
python_export "${i}" EPYTHON PYTHON
-   python_wrapper_setup
+   _python_wrapper_setup
einfo "Using ${EPYTHON} to build"
return
fi
@@ -336,7 +336,7 @@ python_setup() {
for (( i = ${#_PYTHON_SUPPORTED_IMPLS[@]} - 1; i >= 0; i-- )); do
python_export "${_PYTHON_SUPPORTED_IMPLS[i]}" EPYTHON PYTHON
if _python_EPYTHON_supported "${EPYTHON}"; then
-   python_wrapper_setup
+   _python_wrapper_setup
einfo "Using ${EPYTHON} to build"
return
fi
diff --git a/eclass/python-r1.eclass b/eclass/python-r1.eclass
index 960fed8c451a..3ac35e401217 100644
--- a/eclass/python-r1.eclass
+++ b/eclass/python-r1.eclass
@@ -638,7 +638,7 @@ _python_multibuild_wrapper() {
local -x EPYTHON PYTHON
local -x PATH=${PATH} PKG_CONFIG_PATH=${PKG_CONFIG_PATH}
python_export "${MULTIBUILD_VARIANT}" EPYTHON PYTHON
-   python_wrapper_setup
+   _python_wrapper_setup
 
"${@}"
 }
@@ -784,7 +784,7 @@ python_setup() {
die "${FUNCNAME}: no enabled implementation satisfy 
requirements"
fi
 
-   python_wrapper_setup
+   _python_wrapper_setup
einfo "Using ${EPYTHON} in global scope"
 }
 
diff --git a/eclass/python-single-r1.eclass b/eclass/python-single-r1.eclass
index f9e26e7c334f..888db3631d9c 100644
--- a/eclass/python-single-r1.eclass
+++ b/eclass/python-single-r1.eclass
@@ -466,7 +466,7 @@ python_setup() {
ewarn "Dependencies won't be satisfied, and 
PYTHON_SINGLE_TARGET flags will be ignored."
 
python_export "${impls[0]}" EPYTHON PYTHON
-   python_wrapper_setup
+   _python_wrapper_setup
einfo "Using ${EPYTHON} to build"
return
fi
@@ -484,7 +484,7 @@ python_setup() {
fi
 
python_export "${impl}" EPYTHON PYTHON
-   python_wrapper_setup
+   _python_wrapper_setup
einfo "Using ${EPYTHON} to build"
fi
done
diff --git a/eclass/python-utils-r1.eclass b/eclass/python-utils-r1.eclass
index f144cbbb1279..d6fec6446320 100644
--- a/eclass/python-utils-r1.eclass
+++ b/eclass/python-utils-r1.eclass
@@ -950,6 +950,20 @@ python_doheader() {
 # @FUNCTION: python_wrapper_setup
 # @USAGE: [ []]
 # @DESCRIPTION:
+# Backwards compatibility function.  The relevant API is now considered
+# private, please use python_setup instead.
+python_wrapper_setup() {
+   debug-print-function ${FUNCNAME} "${@}"
+
+   eqawarn "python_wrapper_setup() is part of private eclass API."
+   eqawarn "Please call python_setup() instead."
+
+   _python_wrapper_setup "${@}"
+}
+
+# @FUNCTION: _python_wrapper_setup
+# @USAGE: [ []]
+# @DESCRIPTION:
 # Create proper 'python' executable and pkg-config wrappers
 # (if available) in the directory named by . Set up PATH
 # and PKG_CONFIG_PATH appropriately.  defaults to ${T}/${EPYTHON}.
@@ -961,7 +975,7 @@ python_doheader() {
 # be assumed to contain proper wrappers already and only environment
 # setup will be done. If wrapper update is requested, the directory
 # shall be removed first.
-python_wrapper_setup() {
+_python_wrapper_setup() {
debug-print-function ${FUNCNAME} "${@}"
 

Re: [gentoo-dev] rfc: noarch keyword

2020-03-19 Thread Mike Gilbert
On Wed, Mar 18, 2020 at 9:59 PM Kent Fredric  wrote:
>
> On Wed, 18 Mar 2020 17:52:25 +
> James Le Cuirot  wrote:
>
> > Not quite. Tools like repoman will need to be updated to understand
> > that an ebuild with KEYWORDS="amd64" can depend on another ebuild with
> > only KEYWORDS="noarch". I do think the idea has merit though.
>
> But the inverse is _not_ true, an ebuild with KEYWORDS="noarch"
> *cannot* depend on another ebuild with only KEYWORDS="amd64".
>
> Otherwise it breaks the entire stabilization graph.

I'm not sure what you mean by "stabilization graph". I'm guessing you
mean the dependency graph for stable keywords?

Valid dependency graphs are determined by whatever our tooling deems
valid. The tooling could be updated to permit amd64 packages to depend
on noarch packages, and vice-versa.



Re: [gentoo-dev] rfc: noarch keyword

2020-03-19 Thread Kent Fredric
On Thu, 19 Mar 2020 14:52:08 +0100
Gerion Entrup  wrote:

> Maybe I misunderstand something but shouldn't that be the normal case?
> Every single Python package (candidates for noarch) for example depends
> on the Python interpreter, which must have non noarch keywords.


Yeah. So Basically, this pans out to being practically useless unless
you have no dependencies at all, or all your dependencies are
themselves noarch.

And that excludes all of python, and all of perl, because python and
perl cannot ever be noarch.



pgpyMLaHnyTwp.pgp
Description: OpenPGP digital signature


[gentoo-dev] Last rites: net-ftp/pybootd

2020-03-19 Thread Michał Górny
# Michał Górny  (2020-03-19)
# Unmaintained.  Added in 2014 and not touched since.  Python 2 only.
# Removal in 30 days.  Bug #713506.
net-ftp/pybootd

-- 
Best regards,
Michał Górny



signature.asc
Description: This is a digitally signed message part


Re: [gentoo-dev] rfc: noarch keyword

2020-03-19 Thread Gordon Pettey
On Thu, Mar 19, 2020 at 9:47 AM Alec Warner  wrote:

> On Thu, Mar 19, 2020 at 6:52 AM Gerion Entrup 
> wrote:
>
>> Am Donnerstag, 19. März 2020, 02:59:56 CET schrieb Kent Fredric:
>> > On Wed, 18 Mar 2020 17:52:25 +
>> > James Le Cuirot  wrote:
>> >
>> > > Not quite. Tools like repoman will need to be updated to understand
>> > > that an ebuild with KEYWORDS="amd64" can depend on another ebuild with
>> > > only KEYWORDS="noarch". I do think the idea has merit though.
>> >
>> > But the inverse is _not_ true, an ebuild with KEYWORDS="noarch"
>> > *cannot* depend on another ebuild with only KEYWORDS="amd64".
>> Maybe I misunderstand something but shouldn't that be the normal case?
>> Every single Python package (candidates for noarch) for example depends
>> on the Python interpreter, which must have non noarch keywords.
>>
>>
>> > Otherwise it breaks the entire stabilization graph.
>> The condition would be: If the interpreter is stable for an arch, all
>> it's interpreted code is also stable for this arch.
>>
>
> Much of the concern is that this condition is not true for all interpreted
> code.
>
> -A
>
>
>>
>>
>> Best,
>> Gerion
>>
>
If noarch is an alias that includes all keywords, KEYWORDS="noarch -sparc"
works (in Portage, not sure what PMS says about keyword additivity) and
doesn't break your keyword dependency graph for a Python package that for
whatever reason doesn't function on sparc.

Semantically, noarch says it hasn't been tested on any arch, so Kent's
evidence follows. Once you get a negative test result from an arch, you add
-arch to that package. It's not called "allarches".


Re: [gentoo-dev] rfc: noarch keyword

2020-03-19 Thread Alec Warner
On Thu, Mar 19, 2020 at 6:52 AM Gerion Entrup 
wrote:

> Am Donnerstag, 19. März 2020, 02:59:56 CET schrieb Kent Fredric:
> > On Wed, 18 Mar 2020 17:52:25 +
> > James Le Cuirot  wrote:
> >
> > > Not quite. Tools like repoman will need to be updated to understand
> > > that an ebuild with KEYWORDS="amd64" can depend on another ebuild with
> > > only KEYWORDS="noarch". I do think the idea has merit though.
> >
> > But the inverse is _not_ true, an ebuild with KEYWORDS="noarch"
> > *cannot* depend on another ebuild with only KEYWORDS="amd64".
> Maybe I misunderstand something but shouldn't that be the normal case?
> Every single Python package (candidates for noarch) for example depends
> on the Python interpreter, which must have non noarch keywords.
>
>
> > Otherwise it breaks the entire stabilization graph.
> The condition would be: If the interpreter is stable for an arch, all
> it's interpreted code is also stable for this arch.
>

Much of the concern is that this condition is not true for all interpreted
code.

-A


>
>
> Best,
> Gerion
>
>


Re: [gentoo-dev] Re: [PATCH] profiles: Enable USE=user-session on systemd profiles

2020-03-19 Thread Mike Gilbert
On Thu, Mar 19, 2020 at 9:41 AM Mart Raudsepp  wrote:
>
> Ühel kenal päeval, K, 18.03.2020 kell 16:43, kirjutas Mike Gilbert:
> > Seems good to me in principle, but I'm not sure it is something we
> > > should do until we haven't promoted this into a global USE flag.
> >
> > An alternative would be to add entries in package.use.
>
> Yeah, that'd be what it is now, just done in systemd profile, not most
> of the separate systemd profiles.
>
> > > With the disclaimer of not knowing anything about dbus[user-
> > > session] on
> > > a non-systemd system - maybe it's just time to make user-session
> > > unconditionally enabled on dbus (and then bluez) instead?
> > > All it seems to do (on a very quick look) is install some extra
> > > systemd
> > > files - can't they just be always installed (by always passing --
> > > enable-user-session) and call it a day?
> >
> > It looks like user-session has no effect if systemd is not in use.
> >
> > On systems running systemd, having the units installed automatically
> > enables the systemd user bus, and the only way to disable it is to
> > mask the units. Having the user bus enabled generally prevents
> > display
> > managers and startx from starting individual session buses, since
> > they
> > will use the user bus instead. That's probably fine, but I wanted to
> > note it.
>
> So how about we try to just always enable this instead in dbus and
> bluez? Anyone got any objections, provided the below can be handled?
>
> I peeked at bluez, and there USE=user-session exists to apply a patch
> to unbreak things when user-session is disabled. Unfortunately it seems
> to be needed there for non-systemd systems as well. I think we should
> be able to figure things out to work in all situations there, or make
> it be applied for USE=-systemd only (that's already the case there,
> just it is not applied for USE="systemd -user-session" right now).

I think we can apply
0001-Allow-using-obexd-without-systemd-in-the-user-session-r2.patch
unconditionally.

The patched unit should work just fine with systemd, provided the user
bus is available.



Re: [gentoo-dev] rfc: noarch keyword

2020-03-19 Thread Gerion Entrup
Am Donnerstag, 19. März 2020, 02:59:56 CET schrieb Kent Fredric:
> On Wed, 18 Mar 2020 17:52:25 +
> James Le Cuirot  wrote:
> 
> > Not quite. Tools like repoman will need to be updated to understand
> > that an ebuild with KEYWORDS="amd64" can depend on another ebuild with
> > only KEYWORDS="noarch". I do think the idea has merit though.
> 
> But the inverse is _not_ true, an ebuild with KEYWORDS="noarch"
> *cannot* depend on another ebuild with only KEYWORDS="amd64".
Maybe I misunderstand something but shouldn't that be the normal case?
Every single Python package (candidates for noarch) for example depends
on the Python interpreter, which must have non noarch keywords.


> Otherwise it breaks the entire stabilization graph.
The condition would be: If the interpreter is stable for an arch, all
it's interpreted code is also stable for this arch.


Best,
Gerion



signature.asc
Description: This is a digitally signed message part.


Re: [gentoo-dev] Re: [PATCH] profiles: Enable USE=user-session on systemd profiles

2020-03-19 Thread Mart Raudsepp
Ühel kenal päeval, K, 18.03.2020 kell 16:43, kirjutas Mike Gilbert:
> Seems good to me in principle, but I'm not sure it is something we
> > should do until we haven't promoted this into a global USE flag.
> 
> An alternative would be to add entries in package.use.

Yeah, that'd be what it is now, just done in systemd profile, not most
of the separate systemd profiles.

> > With the disclaimer of not knowing anything about dbus[user-
> > session] on
> > a non-systemd system - maybe it's just time to make user-session
> > unconditionally enabled on dbus (and then bluez) instead?
> > All it seems to do (on a very quick look) is install some extra
> > systemd
> > files - can't they just be always installed (by always passing --
> > enable-user-session) and call it a day?
> 
> It looks like user-session has no effect if systemd is not in use.
> 
> On systems running systemd, having the units installed automatically
> enables the systemd user bus, and the only way to disable it is to
> mask the units. Having the user bus enabled generally prevents
> display
> managers and startx from starting individual session buses, since
> they
> will use the user bus instead. That's probably fine, but I wanted to
> note it.

So how about we try to just always enable this instead in dbus and
bluez? Anyone got any objections, provided the below can be handled?

I peeked at bluez, and there USE=user-session exists to apply a patch
to unbreak things when user-session is disabled. Unfortunately it seems
to be needed there for non-systemd systems as well. I think we should
be able to figure things out to work in all situations there, or make
it be applied for USE=-systemd only (that's already the case there,
just it is not applied for USE="systemd -user-session" right now).


Mart



signature.asc
Description: This is a digitally signed message part


Re: [gentoo-dev] rfc: noarch keyword

2020-03-19 Thread Michael Orlitzky
On 3/18/20 10:54 AM, William Hubbs wrote:
> 
> So, my question is, why can't we add a noarch/~noarch keyword and see
> how things go? If it gets abused we can always nuke it later.
> 

This is a good goal, but as others have pointed out, adding a new magic
keyword poses some workflow problems.

We already have the ability to fake this. Instead of KEYWORDS="~noarch",
if you really believe that your package is architecture-independent, you
can just add all ~arch keywords to it. If you're right, no one will ever
notice, and if you're wrong, you'll get shit for it -- just like you
would have if you marked it ~noarch incorrectly.

Maintainers can do their own stabilization (on all arches) for those
packages. I hesitate to invoke "common sense," but in cases where common
sense truly does prevail, you should have no problem keywording and
stabilizing a package on all arches that e.g. downloads a PDF of API
documentation.



[gentoo-dev] State of Cinnamon & Mate projects

2020-03-19 Thread Joonas Niilola
Hanno's previous message about the LXDE project made me think other
desktop projects that are facing a bad state in Gentoo: Cinnamon and
Mate. They are both outdated and last I tried, Cinnamon didn't even
build for me (bug open for a ~year now).

  https://repology.org/maintainer/cinnamon%40gentoo.org
    outdated: 86.7 %

  https://repology.org/maintainer/mate%40gentoo.org
    outdated: 97.4 %

Mate doesn't seem to be that much behind. Gentoo has 1.22 and latest
release is 1.24. 1.22 was released 2019-03-18, and 1.24 last month. Many
of the packages are outdated in a sense that these packages have minor
releases, which haven't been packaged in Gentoo. Ie 1.22.3.
There was a 1.23 release in-between, but looks like not many distros
packaged that either. (Might be some full-development version?)

Cinnamon on the other hand is _horribly_ outdated. Gentoo has 4.0 while
latest release is 4.4. And as noted, I couldn't even build it while
trying. 4.0.3 was released in Nov 2018, while the latest 4.4.8 Jan 2020.
The have been _numerous_ releases in between.

Should some general consensus be agreed on whether to keep them or
remove them? I feel like we are lying to any new users installing
Gentoo; When they setup their system and boot into installed DE, they
immediately have to resort to some overlay to update it. While they
should get it from the overlay in the first place. Saying, IF they even
manage to build it (Cinnamon). This came up and was discussed in the
Gentoo forums.

There could be more issues these non-maintained big projects cause, like
enabling elogind distrowide.

cinna...@gentoo.org has been assigned to 27 open bugs, m...@gentoo.org
to 33.

This message also works as a call-to-arms with these projects. Even if
people decide to rather keep them in ::gentoo, help and some action is
needed.



signature.asc
Description: OpenPGP digital signature


[gentoo-dev] State of the lxde Project

2020-03-19 Thread Hanno Böck
Hello,

I've been the only member of the lxde project for a while.

I recently stopped using lxde myself.

Currently lxde still works, the bug count is relatively low, but it's a
challenging situation. Upstream development has largely stopped and
people have moved to lxqt.

My personal issue why I stopped using lxde was that the latest version
of electron - and subsequently signal - switched its tray icon
implementation to a new API called StatusNotifier which is not
supported by lxde's panel.

There's also one issue where an lxde package depends on a deprecated
version of a library [1]. I assume such issues will become more over
time and it's unclear if there will be any upstream activity fixing
such issues.

If anyone is willing to take over I'm happy to give any guidance I can.
Likely within the next days I'll remove myself from the lxde project,
making it empty.

With approval from the lxqt project I have moved the openbox window
manager, which is shared by lxde and lxqt, to the lxqt project.


[1] https://bugs.gentoo.org/708188
-- 
Hanno Böck
https://hboeck.de/



Re: [gentoo-dev] rfc: noarch keyword

2020-03-19 Thread David Seifert
On Thu, 2020-03-19 at 14:57 +1300, Kent Fredric wrote:
> On Wed, 18 Mar 2020 11:59:25 -0500
> William Hubbs  wrote:
> 
> >  Sure, but if you run into something like that you just don't use the
> >  noarch keyword for those packages.
> 
> But as soon as this happens, all dependent packages that are noarch
> will need to also transition to not using no-arch.
> 
> So it turns into a lot of busywork without benefit.

Second this, it doesn't sound well though out at this point.




[gentoo-dev] Last rites: dev-ruby/haml:4

2020-03-19 Thread Hans de Graaff
# Hans de Graaff  (2020-03-19)
# Masked for security issues, bug #699840
# No reverse dependencies. Use dev-ruby/haml:5 instead.
# Removal in 30 days.
dev-ruby/haml:4


signature.asc
Description: This is a digitally signed message part