| View previous topic :: View next topic |
| Author |
Message |
User7z
n00b
Joined: 01 Jul 2024
Posts: 17
|
 Posted: Mon Jul 15, 2024 11:03 pm Post subject: Get rid of power-profile-daemon |
 |
|
| hi users , i use plasma systemd profile ~amd64 , and i use tlp for my laptop so there is no need for the pkg above , it is pulled by powerdevil , this last one is needed but power-profile-daemon no!! , is there a way to git rid of it ? I tried unmerge , but after update it returned , tried use flags , but didnt help! is this related to gentoo devs decisions ?? Because thats problematics for tlp users |
|
| Back to top |
|
 |
kimchi_sg
Advocate
Joined: 26 Nov 2004
Posts: 3038
|
| Posted: Tue Jul 16, 2024 4:34 am Post subject: Re: Get rid of power-profile-daemon |
|
|
| User7z wrote: | | hi users , i use plasma systemd profile ~amd64 , and i use tlp for my laptop so there is no need for the pkg above , it is pulled by powerdevil , this last one is needed but power-profile-daemon no!! , is there a way to git rid of it ? I tried unmerge , but after update it returned , tried use flags , but didnt help! is this related to gentoo devs decisions ?? Because thats problematics for tlp users |
just mask the power-profiles-daemon systemd unit according to tlp faq: https://linrunner.de/tlp/faq/ppd.html |
|
| Back to top |
|
|
finoderi
Tux's lil' helper
Joined: 29 Oct 2021
Posts: 78
|
| Posted: Tue Jul 16, 2024 1:38 pm Post subject: Re: Get rid of power-profile-daemon |
|
|
| kimchi_sg wrote: | | just mask the power-profiles-daemon systemd unit... |
Can you give an instruction on how to disable it on OpenRC system? Dbus tries to activate it after logging in for some reason.
I agree with OP. This peace of totally unnecessary crap has no place in any system. |
|
| Back to top |
|
|
Hu
Administrator
Joined: 06 Mar 2007
Posts: 22715
|
| Posted: Tue Jul 16, 2024 2:08 pm Post subject: |
|
|
| Is dbus activating it by running its initscript or by starting it directly, outside the control of openrc? |
|
| Back to top |
|
|
finoderi
Tux's lil' helper
Joined: 29 Oct 2021
Posts: 78
|
| Posted: Thu Jul 18, 2024 10:31 am Post subject: |
|
|
| Hu wrote: | | Is dbus activating it by running its initscript or by starting it directly, outside the control of openrc? |
Sorry for the late response, I was rather busy.
The service power-profiles-daemon has its init file in /etc/init.d and can be enabled by adding it to default runlevel. And it's great for those who need it.
The problem is - even if it's not enabled, something in KDE really wants to start it anyway. And dbus tries to start it through systemd unit in /usr/share/dbus-1/system-services/net.hadess.PowerProfiles.service
And the unit has some kind of a placeholder in it: 'Exec=/bin/false'. So the start predictably fails. One can change that path to 'Exec=/usr/libexec/power-profiles-daemon' and the service will start successfully. And it's funny imho.
So is there a way to find what exactly tries to start the service and shut it up for good? |
|
| Back to top |
|
|
Hu
Administrator
Joined: 06 Mar 2007
Posts: 22715
|
| Posted: Thu Jul 18, 2024 2:12 pm Post subject: |
|
|
I hope dbus has a way to do that, but it's not something I've ever needed to find. Perhaps someone else can answer your question.
To me, it seems like a very strange design to provide a dbus service that is guaranteed to fail. I don't see why that is better than excluding the dbus service file entirely. |
|
| Back to top |
|
|
finoderi
Tux's lil' helper
Joined: 29 Oct 2021
Posts: 78
|
| Posted: Fri Jul 19, 2024 7:41 am Post subject: |
|
|
It was already discussed here - https://forums.gentoo.org/viewtopic-t-1165220.html
The service isn't meant to be activated that way on a non-systemd system, but it still is.
And this feature with a new service and a menu for choosing power profiles has been integrated into KDE right after the new amd_pstate driver appeared in a kernel. Someone wanted to shove it in ASAP really bad. KDE devs are so awesome. |
|
| Back to top |
|
|
GDH-gentoo
Veteran
Joined: 20 Jul 2019
Posts: 1719
Location: South America
|
| Posted: Sat Jul 20, 2024 3:37 pm Post subject: |
|
|
| finoderi wrote: | | So is there a way to find what exactly tries to start the service and shut it up for good? |
| Hu wrote: | | I hope dbus has a way to do that, but it's not something I've ever needed to find. |
Something like dbus-monitor interface=net.hadess.PowerProfiles or dbus-monitor interface=net.hadess.PowerProfiles interface=org.freedesktop.UPower.PowerProfiles (power-profiles-daemon 0.20 changed the well-known bus name and interface name) could give some clue. dbus-monitor runs until killed by a signal.
busctl from elogind can also show every process connected to the login session's message bus.
I don't know if the program that tries to contact power-profiles-daemon through D-Bus does so only once after session login, or more than once. In the former case, launching dbus-monitor from a shell could be too late to catch it.
_________________
| NeddySeagoon wrote: | I'm not a witch, I'm a retired electronics engineer  |
| Ionen wrote: | | As a packager I just don't want things to get messier with weird build systems and multiple toolchains requirements though |
|
|
| Back to top |
|
|
finoderi
Tux's lil' helper
Joined: 29 Oct 2021
Posts: 78
|
| Posted: Mon Jul 22, 2024 10:34 am Post subject: |
|
|
I tried 'dbus-monitor interface=net.hadess.PowerProfiles', it shows: | Code: | signal time=1721643159.347680 sender=org.freedesktop.DBus -> destination=:1.34 serial=2 path=/org/freedesktop/DBus; interface=org.freedesktop.DBus; member=NameAcquired
string ":1.34"
signal time=1721643159.347713 sender=org.freedesktop.DBus -> destination=:1.34 serial=4 path=/org/freedesktop/DBus; interface=org.freedesktop.DBus; member=NameLost
string ":1.34" |
- and crickets after that.
Same goes for 'dbus-monitor interface=org.freedesktop.UPower.PowerProfiles', just with different 'destinations'.
'# busctl status busctl status net.hadess.PowerProfiles' gives nothing.
When I changed path to executable in net.hadess.PowerProfiles.service, rebooted and tried '# busctl status net.hadess.PowerProfiles', I got this: | Code: | PID=2186
PPID=1
TTY=n/a
UID=0
EUID=0
SUID=0
FSUID=0
GID=0
EGID=0
SGID=0
FSGID=0
SupplementaryGIDs=0 1 2 3 4 6 10 11 26 27
Comm=power-profiles-
Exe=/usr/libexec/power-profiles-daemon
CommandLine=/usr/libexec/power-profiles-daemon
CGroup=/openrc.dbus
Session=openrc.dbus
UniqueName=:1.6
EffectiveCapabilities=cap_chown cap_dac_override cap_dac_read_search
cap_fowner cap_fsetid cap_kill cap_setgid
cap_setuid cap_setpcap cap_linux_immutable cap_net_bind_service
cap_net_broadcast cap_net_admin cap_net_raw cap_ipc_lock
cap_ipc_owner cap_sys_module cap_sys_rawio cap_sys_chroot
cap_sys_ptrace cap_sys_pacct cap_sys_admin cap_sys_boot
cap_sys_nice cap_sys_resource cap_sys_time cap_sys_tty_config
cap_mknod cap_lease cap_audit_write cap_audit_control
cap_setfcap cap_mac_override cap_mac_admin cap_syslog
cap_wake_alarm cap_block_suspend cap_audit_read cap_perfmon
cap_bpf cap_checkpoint_restore
PermittedCapabilities=cap_chown cap_dac_override cap_dac_read_search
cap_fowner cap_fsetid cap_kill cap_setgid
cap_setuid cap_setpcap cap_linux_immutable cap_net_bind_service
cap_net_broadcast cap_net_admin cap_net_raw cap_ipc_lock
cap_ipc_owner cap_sys_module cap_sys_rawio cap_sys_chroot
cap_sys_ptrace cap_sys_pacct cap_sys_admin cap_sys_boot
cap_sys_nice cap_sys_resource cap_sys_time cap_sys_tty_config
cap_mknod cap_lease cap_audit_write cap_audit_control
cap_setfcap cap_mac_override cap_mac_admin cap_syslog
cap_wake_alarm cap_block_suspend cap_audit_read cap_perfmon
cap_bpf cap_checkpoint_restore
InheritableCapabilities=
BoundingCapabilities=cap_chown cap_dac_override cap_dac_read_search
cap_fowner cap_fsetid cap_kill cap_setgid
cap_setuid cap_setpcap cap_linux_immutable cap_net_bind_service
cap_net_broadcast cap_net_admin cap_net_raw cap_ipc_lock
cap_ipc_owner cap_sys_module cap_sys_rawio cap_sys_chroot
cap_sys_ptrace cap_sys_pacct cap_sys_admin cap_sys_boot
cap_sys_nice cap_sys_resource cap_sys_time cap_sys_tty_config
cap_mknod cap_lease cap_audit_write cap_audit_control
cap_setfcap cap_mac_override cap_mac_admin cap_syslog
cap_wake_alarm cap_block_suspend cap_audit_read cap_perfmon
cap_bpf cap_checkpoint_restore |
And if I try to change power profile in KDE's system settings from 'Leave unchanged' to 'Performance', '# busctl monitor net.hadess.PowerProfiles' shows this output: | Code: | ‣ Type=method_call Endian=l Flags=0 Version=1 Cookie=89
Sender=:1.7 Destination=net.hadess.PowerProfiles Path=/net/hadess/PowerProfiles Interface=org.freedesktop.DBus.Properties Member=Set
UniqueName=:1.7
MESSAGE "ssv" {
STRING "net.hadess.PowerProfiles";
STRING "ActiveProfile";
VARIANT "s" {
STRING "performance";
};
};
‣ Type=method_call Endian=l Flags=0 Version=1 Cookie=20
Sender=:1.6 Destination=:1.5 Path=/org/freedesktop/PolicyKit1/Authority Interface=org.freedesktop.PolicyKit1.Authority Member=CheckAuthorization
UniqueName=:1.6
MESSAGE "(sa{sv})sa{ss}us" {
STRUCT "sa{sv}" {
STRING "system-bus-name";
ARRAY "{sv}" {
DICT_ENTRY "sv" {
STRING "name";
VARIANT "s" {
STRING ":1.7";
};
};
};
};
STRING "org.freedesktop.UPower.PowerProfiles.switch-profile";
ARRAY "{ss}" {
};
UINT32 0;
STRING "";
};
‣ Type=method_return Endian=l Flags=1 Version=1 Cookie=196 ReplyCookie=20
Sender=:1.5 Destination=:1.6
UniqueName=:1.5
MESSAGE "(bba{ss})" {
STRUCT "bba{ss}" {
BOOLEAN true;
BOOLEAN false;
ARRAY "{ss}" {
};
};
};
‣ Type=method_return Endian=l Flags=1 Version=1 Cookie=21 ReplyCookie=89
Sender=:1.6 Destination=:1.7
UniqueName=:1.6
MESSAGE "" {
}; |
- which is cool but doesn't look useful.
So I guess the service is some kind of an integral part of KDE now. If you need it, you can enable it, if you don't - it will fail silently after logging in. |
|
| Back to top |
|
|
GDH-gentoo
Veteran
Joined: 20 Jul 2019
Posts: 1719
Location: South America
|
| Posted: Mon Jul 22, 2024 9:34 pm Post subject: |
|
|
The command that lists processes connected to the system wide message bus, and the programs they are running, is just busctl, without any arguments. The list includes their unique connection name:
| finoderi wrote: | And if I try to change power profile in KDE's system settings from 'Leave unchanged' to 'Performance', '# busctl monitor net.hadess.PowerProfiles' shows this output: | Code: | ‣ Type=method_call Endian=l Flags=0 Version=1 Cookie=89
Sender=:1.7 Destination=net.hadess.PowerProfiles Path=/net/hadess/PowerProfiles Interface=org.freedesktop.DBus.Properties Member=Set
UniqueName=:1.7
MESSAGE "ssv" {
STRING "net.hadess.PowerProfiles";
STRING "ActiveProfile";
VARIANT "s" {
STRING "performance";
};
};
...
‣ Type=method_return Endian=l Flags=1 Version=1 Cookie=21 ReplyCookie=89
Sender=:1.6 Destination=:1.7
UniqueName=:1.6
MESSAGE "" {
}; |
- which is cool but doesn't look useful. |
It is useful. The process that has the unique connection name :1.7 in the output of busctl is one of those that talk to power-profiles-daemon (which itself has unique connection name :1.6). Use busctl without arguments to see what it is.
:1.5 is likely the Polkit daemon.
EDIT: power-profiles-daemon connects to the system wide bus, not the session bus.
_________________
| NeddySeagoon wrote: | | I'm not a witch, I'm a retired electronics engineer |
| Ionen wrote: | | As a packager I just don't want things to get messier with weird build systems and multiple toolchains requirements though |
|
|
| Back to top |
|
|
finoderi
Tux's lil' helper
Joined: 29 Oct 2021
Posts: 78
|
| Posted: Tue Jul 23, 2024 4:02 pm Post subject: |
|
|
| GDH-gentoo wrote: | It is useful. The process that has the unique connection name :1.7 in the output of busctl is one of those that talk to power-profiles-daemon (which itself has unique connection name :1.6). Use busctl without arguments to see what it is.
:1.5 is likely the Polkit daemon.
EDIT: power-profiles-daemon connects to the system wide bus, not the session bus. |
Here's what '$ busctl list' shows:
| Code: |
NAME PID PROCESS USER CONNECTION UNIT SESSION DESCRIPTION
:1.0 1151 elogind-daemon root :1.0 elogind - -
:1.10 2281 upowerd root :1.10 openrc.dbus - -
:1.11 2242 polkit-kde-auth mike :1.11 c1 - -
:1.19 2329 colord colord :1.19 openrc.dbus - -
:1.2 2070 startplasma-way mike :1.2 c1 - -
:1.23 2204 kded5 mike :1.23 c1 - -
:1.24 2420 udisksd root :1.24 openrc.dbus - -
:1.25 2300 kdeconnectd mike :1.25 c1 - -
:1.26 2241 plasmashell mike :1.26 c1 - -
:1.3 2089 xdg-desktop-por mike :1.3 c1 - -
:1.30 2582 busctl root :1.30 c1 - -
:1.4 2080 kwin_wayland mike :1.4 c1 - -
:1.5 2119 polkitd polkitd :1.5 openrc.dbus - -
:1.6 2188 power-profiles- root :1.6 openrc.dbus - -
:1.7 2244 org_kde_powerde mike :1.7 c1 - -
:1.8 2244 org_kde_powerde mike :1.8 c1 - -
:1.9 2244 org_kde_powerde mike :1.9 c1 - -
net.hadess.PowerProfiles 2188 power-profiles- root :1.6 openrc.dbus - -
org.freedesktop.Accounts - - - (activatable) - - -
org.freedesktop.ColorManager 2329 colord colord :1.19 openrc.dbus - -
org.freedesktop.DBus 1123 dbus-daemon root - openrc.dbus - -
org.freedesktop.PolicyKit1 2119 polkitd polkitd :1.5 openrc.dbus - -
org.freedesktop.UDisks2 2420 udisksd root :1.24 openrc.dbus - -
org.freedesktop.UPower 2281 upowerd root :1.10 openrc.dbus - -
org.freedesktop.UPower.PowerProfiles 2188 power-profiles- root :1.6 openrc.dbus - -
org.freedesktop.login1 1151 elogind-daemon root :1.0 elogind - -
org.kde.fontinst - - - (activatable) - - -
org.kde.kcontrol.kcmclock - - - (activatable) - - -
org.kde.kcontrol.kcmkwallet5 - - - (activatable) - - -
org.kde.kinfocenter.dmidecode - - - (activatable) - - -
org.kde.ksysguard.processlisthelper - - - (activatable) - - -
org.kde.ktexteditor.katetextbuffer - - - (activatable) - - -
org.kde.localegenhelper - - - (activatable) - - -
org.kde.powerdevil.backlighthelper - - - (activatable) - - -
org.kde.powerdevil.chargethresholdhelper - - - (activatable) - - -
org.kde.powerdevil.discretegpuhelper - - - (activatable) - - - |
:1.5 is indeed polkitd, :1.7 is PowerDevil.
I don't know where to find PowerDevil configuration file. There is powermanagementprofilesrc in /home/.../.config which corresponds to some Power Management settings in KDE's System Settings, but there is nothing about power profiles there. And power-profiles-daemon itself starts with root privileges anyway. |
|
| Back to top |
|
|
GDH-gentoo
Veteran
Joined: 20 Jul 2019
Posts: 1719
Location: South America
|
| Posted: Tue Jul 23, 2024 4:50 pm Post subject: |
|
|
| finoderi wrote: | | :1.7 is PowerDevil. |
Good. At least they say it:
| Quote: | PowerDevil
[...]
The service will:
[...]- Communicate with underlying services such as UPower, power-profiles-daemon, ddcutil, and/or systemd to implement some of the above.
|
(emphasis is mine)
I might have a look at code later...
_________________
| NeddySeagoon wrote: | | I'm not a witch, I'm a retired electronics engineer |
| Ionen wrote: | | As a packager I just don't want things to get messier with weird build systems and multiple toolchains requirements though |
|
|
| Back to top |
|
|
GDH-gentoo
Veteran
Joined: 20 Jul 2019
Posts: 1719
Location: South America
|
| Posted: Thu Jul 25, 2024 4:09 pm Post subject: |
|
|
Alright. It looks like the "PoweProfile" action plugin (or whatever Plasma calls that; I don't use it) does indeed the activation of power-profiles-daemon through D-Bus, and that was added in PowerDevil 5.22.90 and 5.23.0 (code is in daemon/actions/bundled/powerprofile.cpp).
However, objects of classes derived from PowerDevil::Action have an isSupported() member function, and class PowerDevil::BundledActions::PowerProfile's returns false if there's no activatable service with bus name net.hadess.PowerProfiles in the system wide message bus:
daemon/actions/bundled/powerprofile.cpp
| Code: | using namespace PowerDevil::BundledActions;
// ...
static const QString ppdName = QStringLiteral("net.hadess.PowerProfiles");
// ...
bool PowerProfile::isSupported()
{
return QDBusConnection::systemBus().interface()->activatableServiceNames().value().contains(ppdName);
} |
That is, if file /usr/share/dbus-1/system-services/net.hadess.PowerProfiles.service does not exist. Uninstalling package sys-power/power-profiles-daemon should do it.
As far as I can tell, an action plugin that declares itself usupported would simply not be considered. I don't know how that reflects on the user interface, but seems to be handled gracefully...
_________________
| NeddySeagoon wrote: | | I'm not a witch, I'm a retired electronics engineer |
| Ionen wrote: | | As a packager I just don't want things to get messier with weird build systems and multiple toolchains requirements though |
Last edited by GDH-gentoo on Thu Jul 25, 2024 5:46 pm; edited 1 time in total |
|
| Back to top |
|
|
pietinger
Moderator
Joined: 17 Oct 2006
Posts: 5144
Location: Bavaria
|
| Posted: Thu Jul 25, 2024 4:16 pm Post subject: |
|
|
| GDH-gentoo wrote: | | [...] Uninstalling package sys-power/power-profiles-daemon should do it. [...] |
Not easy if you have installed plasma-meta:
| Code: | ~ # emerge -cpv power-profiles-daemon
Calculating dependencies... done!
sys-power/power-profiles-daemon-0.21 pulled in by:
kde-plasma/powerdevil-5.27.11 requires sys-power/power-profiles-daemon
...
~ # emerge -cpv powerdevil
Calculating dependencies... done!
kde-plasma/powerdevil-5.27.11 pulled in by:
kde-plasma/plasma-meta-5.27.11-r1 requires >=kde-plasma/powerdevil-5.27.11:5
... |
_________________
https://wiki.gentoo.org/wiki/User:Pietinger |
|
| Back to top |
|
|
GDH-gentoo
Veteran
Joined: 20 Jul 2019
Posts: 1719
Location: South America
|
| Posted: Thu Jul 25, 2024 4:36 pm Post subject: |
|
|
| pietinger wrote: | | GDH-gentoo wrote: | | [...] Uninstalling package sys-power/power-profiles-daemon should do it. [...] |
Not easy if you have installed plasma-meta: |
Modifying PowerDevil's ebuild (e. g. in a local ebuild repository) to get rid of the unconditional RDEPEND, of course, otherwise Portage won't let you do the test indeed.
EDIT: the dependency is there because someone requested it (although conditionally on a USE flag). The description in the bug matches what I expect: you just lose (gracefully) the "Power management profile" function.
_________________
| NeddySeagoon wrote: | | I'm not a witch, I'm a retired electronics engineer |
| Ionen wrote: | | As a packager I just don't want things to get messier with weird build systems and multiple toolchains requirements though |
|
|
| Back to top |
|
|
finoderi
Tux's lil' helper
Joined: 29 Oct 2021
Posts: 78
|
| Posted: Fri Jul 26, 2024 9:45 am Post subject: |
|
|
| GDH-gentoo wrote: | | the dependency is there because someone requested it (although conditionally on a USE flag). |
But instead of adding it as an optional USE flag feature they just added it for everybody.
Anyway, thank you very much GDH-gentoo. |
|
| Back to top |
|
|
asturm
Developer
Joined: 05 Apr 2007
Posts: 9295
|
| Posted: Sat Nov 23, 2024 1:55 pm Post subject: |
|
|
| >=powerdevil-6.2.3-r2 has support for sys-power/tlp. |
|
| Back to top |
|
|
sam_
Developer
Joined: 14 Aug 2020
Posts: 1980
|
| Posted: Sat Nov 23, 2024 7:35 pm Post subject: |
|
|
| finoderi wrote: | | GDH-gentoo wrote: | | the dependency is there because someone requested it (although conditionally on a USE flag). |
But instead of adding it as an optional USE flag feature they just added it for everybody.
Anyway, thank you very much GDH-gentoo. |
Note that at the time, no upstream support existed for tlp.
We do a lot of work in the background that users never see to make things optional. We can't always do that, and then you get posts like this saying we "just" did something like it's an insult. Just keep in mind it's not always as simple as "someone lazily added it".
On top of whether support even exists for something, we also have to balance things upstream expectations and requirements for us to not be shipping a broken setup as well. |
|
| Back to top |
|
|
finoderi
Tux's lil' helper
Joined: 29 Oct 2021
Posts: 78
|
| Posted: Sun Nov 24, 2024 12:33 pm Post subject: |
|
|
| I agree that we should thank KDE developers team for this pile of useless crap first and foremost, although I can't help but notice you are a bit too sensitive for a developer of a rather big project. I haven't had any intentions to insult anybody. Yet. |
|
| Back to top |
|
|
asturm
Developer
Joined: 05 Apr 2007
Posts: 9295
|
| Posted: Sun Nov 24, 2024 12:36 pm Post subject: |
|
|
I didn't see you file a bug, so kindly shut the fuck up.
"I haven't had any intentions to insult anybody. Yet."
Do you want to go down that road? |
|
| Back to top |
|
|
pietinger
Moderator
Joined: 17 Oct 2006
Posts: 5144
Location: Bavaria
|
| Posted: Sun Nov 24, 2024 4:05 pm Post subject: |
|
|
| finoderi wrote: | | [...] although I can't help but notice you are a bit too sensitive [...] I haven't had any intentions to insult anybody. Yet. |
What I learned in school back then (I don't know what it's like today) to communicate as conflict-free as possible was:
Talk about yourself and not about others. Don't say: “You have ... You are ...” but ”I have a problem because ... I feel ...”. Statements about others can very quickly and very easily be taken as an insinuation or even an insult ... They can even be presumptuous if you think you know what the other person is like. Your own standards do not always apply to others. If you think someone is too sensitive, it could also be because you are too rude yourself.
| asturm wrote: | | Do you want to go down that road? |
I answer with No, because moderation doesn't want any escalation here!
_________________
https://wiki.gentoo.org/wiki/User:Pietinger |
|
| Back to top |
|
|
Hu
Administrator
Joined: 06 Mar 2007
Posts: 22715
|
| Posted: Sun Nov 24, 2024 4:47 pm Post subject: |
|
|
| finoderi wrote: | | I agree that we should thank KDE developers team for this pile of useless crap first and foremost, although I can't help but notice you are a bit too sensitive for a developer of a rather big project. I haven't had any intentions to insult anybody. Yet. |
I think that your post is inappropriate in multiple senses. First, while the package may not be suitable for your use case, calling it "useless crap" is a gross overstatement. It's suitable for someone's use case, and presumably works well for those use cases, or Gentoo would not continue to package it. Second, as sam_ had explained in the post to which you responded, doing it the way you would prefer would have been significantly more trouble than what was done. Presumably, closing the bug as WONTFIX would have aggravated someone too, so this looks like a no-win situation. What, exactly, do you think Gentoo should've done here? Close the bug as WONTFIX? Add it as a hard dependency? Add a USE flag, and do all the plumbing to make that work? Bug upstream to write that plumbing (delaying the whole effort until upstream chooses to write it, if they even agree to do so), and only then add it behind a USE flag?
Finally, if you don't intend to insult anybody, then you need to work on your writing style. Your posts come across as insulting, whether or not you intended them that way. |
|
| Back to top |
|
|
|
Desktop Environments
