Re: [gentoo-dev] rfc: noarch keyword
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
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
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
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
# 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
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
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
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
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
Ü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
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
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
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
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
# 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
