Gentoo Forums
Gentoo Forums
Gentoo Forums
Quick Search: in
Get rid of power-profile-daemon
View unanswered posts
View posts from last 24 hours
View posts from last 7 days

 
Reply to topic    Gentoo Forums Forum Index Desktop Environments
View previous topic :: View next topic  
Author Message
User7z
n00b
n00b


Joined: 01 Jul 2024
Posts: 17

PostPosted: Mon Jul 15, 2024 11:03 pm    Post subject: Get rid of power-profile-daemon Reply with quote

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
View user's profile Send private message
kimchi_sg
Advocate
Advocate


Joined: 26 Nov 2004
Posts: 3038

PostPosted: Tue Jul 16, 2024 4:34 am    Post subject: Re: Get rid of power-profile-daemon Reply with quote

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
View user's profile Send private message
finoderi
Tux's lil' helper
Tux's lil' helper


Joined: 29 Oct 2021
Posts: 79

PostPosted: Tue Jul 16, 2024 1:38 pm    Post subject: Re: Get rid of power-profile-daemon Reply with quote

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
View user's profile Send private message
Hu
Administrator
Administrator


Joined: 06 Mar 2007
Posts: 22771

PostPosted: Tue Jul 16, 2024 2:08 pm    Post subject: Reply with quote

Is dbus activating it by running its initscript or by starting it directly, outside the control of openrc?
Back to top
View user's profile Send private message
finoderi
Tux's lil' helper
Tux's lil' helper


Joined: 29 Oct 2021
Posts: 79

PostPosted: Thu Jul 18, 2024 10:31 am    Post subject: Reply with quote

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
View user's profile Send private message
Hu
Administrator
Administrator


Joined: 06 Mar 2007
Posts: 22771

PostPosted: Thu Jul 18, 2024 2:12 pm    Post subject: Reply with quote

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
View user's profile Send private message
finoderi
Tux's lil' helper
Tux's lil' helper


Joined: 29 Oct 2021
Posts: 79

PostPosted: Fri Jul 19, 2024 7:41 am    Post subject: Reply with quote

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
View user's profile Send private message
GDH-gentoo
Veteran
Veteran


Joined: 20 Jul 2019
Posts: 1734
Location: South America

PostPosted: Sat Jul 20, 2024 3:37 pm    Post subject: Reply with quote

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
View user's profile Send private message
finoderi
Tux's lil' helper
Tux's lil' helper


Joined: 29 Oct 2021
Posts: 79

PostPosted: Mon Jul 22, 2024 10:34 am    Post subject: Reply with quote

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
View user's profile Send private message
GDH-gentoo
Veteran
Veteran


Joined: 20 Jul 2019
Posts: 1734
Location: South America

PostPosted: Mon Jul 22, 2024 9:34 pm    Post subject: Reply with quote

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
View user's profile Send private message
finoderi
Tux's lil' helper
Tux's lil' helper


Joined: 29 Oct 2021
Posts: 79

PostPosted: Tue Jul 23, 2024 4:02 pm    Post subject: Reply with quote

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
View user's profile Send private message
GDH-gentoo
Veteran
Veteran


Joined: 20 Jul 2019
Posts: 1734
Location: South America

PostPosted: Tue Jul 23, 2024 4:50 pm    Post subject: Reply with quote

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
View user's profile Send private message
GDH-gentoo
Veteran
Veteran


Joined: 20 Jul 2019
Posts: 1734
Location: South America

PostPosted: Thu Jul 25, 2024 4:09 pm    Post subject: Reply with quote

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
View user's profile Send private message
pietinger
Moderator
Moderator


Joined: 17 Oct 2006
Posts: 5184
Location: Bavaria

PostPosted: Thu Jul 25, 2024 4:16 pm    Post subject: Reply with quote

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
View user's profile Send private message
GDH-gentoo
Veteran
Veteran


Joined: 20 Jul 2019
Posts: 1734
Location: South America

PostPosted: Thu Jul 25, 2024 4:36 pm    Post subject: Reply with quote

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
View user's profile Send private message
finoderi
Tux's lil' helper
Tux's lil' helper


Joined: 29 Oct 2021
Posts: 79

PostPosted: Fri Jul 26, 2024 9:45 am    Post subject: Reply with quote

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
View user's profile Send private message
asturm
Developer
Developer


Joined: 05 Apr 2007
Posts: 9317

PostPosted: Sat Nov 23, 2024 1:55 pm    Post subject: Reply with quote

>=powerdevil-6.2.3-r2 has support for sys-power/tlp.
Back to top
View user's profile Send private message
sam_
Developer
Developer


Joined: 14 Aug 2020
Posts: 2002

PostPosted: Sat Nov 23, 2024 7:35 pm    Post subject: Reply with quote

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
View user's profile Send private message
finoderi
Tux's lil' helper
Tux's lil' helper


Joined: 29 Oct 2021
Posts: 79

PostPosted: Sun Nov 24, 2024 12:33 pm    Post subject: Reply with quote

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
View user's profile Send private message
asturm
Developer
Developer


Joined: 05 Apr 2007
Posts: 9317

PostPosted: Sun Nov 24, 2024 12:36 pm    Post subject: Reply with quote

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
View user's profile Send private message
pietinger
Moderator
Moderator


Joined: 17 Oct 2006
Posts: 5184
Location: Bavaria

PostPosted: Sun Nov 24, 2024 4:05 pm    Post subject: Reply with quote

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
View user's profile Send private message
Hu
Administrator
Administrator


Joined: 06 Mar 2007
Posts: 22771

PostPosted: Sun Nov 24, 2024 4:47 pm    Post subject: Reply with quote

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
View user's profile Send private message
finoderi
Tux's lil' helper
Tux's lil' helper


Joined: 29 Oct 2021
Posts: 79

PostPosted: Mon Nov 25, 2024 6:46 am    Post subject: Reply with quote

Filing a bug wouldn't change anything. Developers probably did best of what they could in this case. But it's not the first time sam_ reads 'insults' into rather innocuous statements of different users and because I'm particularly rude and obnoxious I decided to point that out.
Back to top
View user's profile Send private message
Display posts from previous:   
Reply to topic    Gentoo Forums Forum Index Desktop Environments All times are GMT
Page 1 of 1

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum